Subject: FW: MBONE access?

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Wed, 3 Mar 2004 20:35:33 -0800

>> I think it is time to accept that the MBONE technology is
>> fatally flawed and is not going to be deployable.

>There is nothing wrong with Mbone, per se--though, as someone mentioned,
>it might be nice to have better codecs. The problem is that multicast is
>flawed, and not going to be globally deployable.

Well that was my real point, it is a bogus concept. The fact it still
does not work for all but a tiny fraction of the net shows that.

If the IETF put a tenth the effort that has gone into multicast into
fixing the spam problem, or something the end users (not geeks) care
about...

>> Equally flawed and useless are the H.323 protocols that do not
>> tunnel through NAT or even work with a firewall in a remotely 
>> acceptable fashion.

>There is nothing wrong with h323.  There are good reasons for the IP
>address of the client to be embedded in some h323 control messages.  In
>most cases, this is a good thing, and an advantage for call control and
>call routing systems.  Indeed, this is what gives h323 its scalability and
>ability to compete and work in tandem with the PSTN.

This design feature seems to be a work arround the rule that 
reserved ports can only be accessed with system privileges.
There are much better work arrounds.

If you think about it the port number is utterly irrelevant 
bandwidth wise.

> But when passing
>through a NAT, those addresses and port numbers have to be properly and
>statefully translated---That's what a proxy does.  The problem is that
>your NAT doesn't (or most likely, /didn't/ until the last year or two or
>three) support h323 proxy.  You need h323 proxy support just like you need
>proxy support for many non-trivial protocols.  Either upgrade your NAT
>software, or if you run linux/bsd/etc, install an open source h323 proxy
>on your NAT gateway.

Schemes that require NAT boxes to implement ad hoc kludges for each
protocol are not a good plan. I would much rather have one protocol
that gives my machine to request a port be opened on the NAT box.

The problem with NAT is the need for ad hoc kludges. Deal with the
fact that NAT is here to stay and the problems can be eliminated 
trivially.

This could be done with a trivial mod to DHCP (hey buddy, this IP address
I just gave you is behind a NAT) and a very simple UDP request/response
protocol (give me an external port in the range 3000 to 3050) (OK
you have 3002, the IP address is 10.2.2.2).

There was a group looking at this type of idea, seems that it is a
feature that is going to be deliberately withheld to make sure
that the incentive to upgrade to IPv6 does not get lost accidentally.

So the current state of play is that this is proposed for the IPv6
NAT boxes.

		Phill

---

From: Joel Jaeggli <[email-masked]>
Date: Wed, 3 Mar 2004 21:21:30 -0800 (PST)

> fixing the spam problem, or something the end users (not geeks) care

Comparing one apparently intractable problem to another doesn't seem 
productive or useful.

-- 
-------------------------------------------------------------------------- 
Joel Jaeggli  	       Unix Consulting 	       [email-masked]    
GPG Key Fingerprint:     5C6E 0104 BAF0 40B0 5BD3 C38B F000 35AB B67F 56B2

---

From: Dean Anderson <[email-masked]>
Date: Thu, 4 Mar 2004 01:47:25 -0500 (EST)

> fixing the spam problem, or something the end users (not geeks) care

Hmm.  That would be real work... ;-) ;-)

> There are much better work arrounds.

???  It has nothing to do with reserved ports.  The "normal" ports are 
1720 and 1721. The problem is that the client's IP and port are embedded 
in the setup messages, so that they can be passed to several intervening 
gatekeepers which may (or may not) handle the stream themselves, or 
arrange for the two endpoints to communicate directly.

Do you mean the feature of having gatekeepers for distributed call 
control/call routing?

> fact that NAT is here to stay and the problems can be eliminated 

These two statements are contradictory.  'Schemes that require NAT to
implement ad hoc kludges' / 'The problem with NAT is the need for ad hoc
kludges.'

Anything that requires state on the part of the NAT, and the NAT to look
inside the protocol to make changes for external/internal translations is
going to require a proxy.  Clearly, there is a need for protocols to have
IP addresses and port numbers inside the protocol payload, and there is no
generic way to describe that to the NAT. Proxies are unavoidable in NATing
non-trivial protocols.

> you have 3002, the IP address is 10.2.2.2).

This is clever and I think it could be useful for some things, and I
wouldn't argue against it being standardized, but it doesn't solve the
problem for h323 because the h323 client doesn't know if the eventual
remote endpoint will be an external or internal address.  The gatekeepers
(and proxy's) need to figure that out, and similarly for the other client.
The client can't do it, except in the trivial case without gatekeepers.  
The client can only say "I'm listening on this IP and port".  Only in the
trivial case, going through a NAT, does it look like an unnecessary
complication.

But we don't want to give up our distributed call routing and call control
capabilities, so we aren't going to optimize for the trivial case which is
basically only used in proof of concept "2 cups and string"
demonstrations, anyway. Though, basically, that's exactly what the SIP
group did, and has been adding 'necessary complication' ever since.

People always groan about the complexity of h323 but the basic complexity
is there for good reason, and there are rational points of optional
additional complexity (such as h.450x extensions). Certainly, there has
been optimization between version 1 and version 4, and there may even be
room for optimization still.  But the basic requirements are, well, 'basic
requirements'.  To throw some platitudes out: "Make things as simple as
possible, but no simpler".  And really, most of the problem plaguing h323
had been the lack of good, free asn1 tools, but that is changing, too.

		--Dean>