Subject: RE: Netmeeting - NAT issue

From: "Peter Ford" <[email-masked]>
Date: Sun, 17 Mar 2002 18:51:48 -0800

If one really believes in end to end architectures, then one probably
would want generalized protocols for supporting hosts telling the
network what to do wrt opening holes at NATs/Firewalls for inbound
traffic.  Doing this form of traversal mapping on a protocol by protocol
basis (e.g. H.323 gateway, SIP proxies, etc.) does create an interesting
market niche for the firewall vendors, but it is not clear this is the
right model for the long term.

Microsoft has recently addressed the NAT traversal issue for multimedia
scenarios by shipping Messenger in Windows XP and it uses universal plug
and play protocols (www.upnp.org) to open holes on upnp capable internet
gateways. There are many vendors building upnp capable NATs in 2002.

Even if the *AT* in NATs go away, the reason people buy them won't.
There needs to be a way for applications and firewalls to coordinate -
perhaps in the same way that highway designers and car designers usually
agree on the basic design parameters of on/off ramps.

Regards, peter

-----Original Message-----
From: Andrew McGregor [mailto:[email-masked]] 
Sent: Sunday, March 17, 2002 5:34 PM
To: Joe Touch; Vivek Gupta
Cc: [email-masked]
Subject: Re: Netmeeting - NAT issue

Or, get a NAT which *does* connection-track H.323.  They do exist, 
open-source and not, and work just fine.

Better, get a proper H.323 gateway (which will work behind an H.323
aware 
NAT if done properly) so people can call in as well as out.

However, NAT is still brokenness. (and so is H.323)

Andrew

--On Tuesday, March 12, 2002 15:17:35 -0800 Joe Touch <[email-masked]>
wrote:

> NAT doesn't support Netmeeting. It uses H.323 encoding, which uses IP
> addresses and dynamically assigned ports in-band (inside the
connection).
> The NAT is translating the outer IP addresses, but because your NAT
> doesn't understand H.323, it doesn't know it would have to also
translate
> the inner addresses and ports. Netmeeting expects that it can
dynamically
> select a port to use to connect back to your machine, but that defeats
> what a NAT "thinks" the Internet looks like (notably because it's
> incorrect).
>
> The best solution: get real IP addresses. It's cheaper than wasting
your
> time figuring out why things don't work.
>
> Joe
>
>

---

From: Andrew McGregor <[email-masked]>
Date: Mon, 18 Mar 2002 15:36:54 +1200

> right model for the long term.

I don't think it is; my suggestion below was merely practical.

> gateways. There are many vendors building upnp capable NATs in 2002.

Nice.
> agree on the basic design parameters of on/off ramps.

I agree; it's going to be hard to secure, but I guess that's what makes it 
interesting.

---

From: "Melinda Shore" <[email-masked]>
Date: Mon, 18 Mar 2002 10:14:22 -0500

> > gateways. There are many vendors building upnp capable NATs in 2002.

Not really.  It's just midcom, which solves some problems
and introduces other.  It restores one kind of end-to-end
function (addressing) while damaging another (routing
transparency).

Melinda

---

From: Joe Touch <[email-masked]>
Date: Mon, 18 Mar 2002 08:08:23 -0800

Peter Ford wrote:
> traffic.

Actually, if one believes in the E2E arch (more specifically, the STD 
documents), we should admit that:

	- NATs are _designed_ to make everything behind them
	look like a single host

	- they work fine exactly where that's sufficient

	- they break very badly for EVERY new protocol that
	coordinates ports or IP addresses in-band, and in any
	other case where everything behind them does NOT
	want to work like a single host

A generalized protocol for opening holes would fundamentally alter the 
Internet architecture (as specified in the STD docs) to _require_ path 
setup, which defeats dynamic routing, and, more specifically, the 
fundamentally connection-free property of datagram service.

Joe