Subject: RE: IP network address assignments/allocations information?

From: "Tony Hain (Exchange)" <[email-masked]>
Date: Tue, 30 Nov 1999 13:37:33 -0800

Valdis,

This is the kind of BS that keeps these debates running. NAT problems exist
anytime a connection originates on the public side and there is not a
preexisting clear mapping to the private side. I didn't pick on Real Player
at random. My house is connected through a NATPT, and my wife couldn't get a
video stream opened back to her machine. If I had pre-mapped those ports to
her machine, then my son would not have been able to get them on his. If I
pre-map them, all the bogus security arguments about NAT become invalid.
Clearly NAT has allowed me to create an environment which is not
sustainable, but at least I know enough to know what the problem is, the
average guy on the street doesn't stand a chance.

Yes there are problems with protocols that carry addresses, but ignoring
encrypted traffic that really amounts to acquiring and synchronizing
deployments of ALGs. In the early stages this doesn't sound hard, but will
vendors be willing to add new ALGs to 3 year old NAT hardware? Will they
create an update process that is easy enough for the average user? Will the
average user be able to figure out which NAT needs updating, and what
version it needs? Add the fact that people want to encrypt their traffic for
privacy, and one wonders why so much effort is spent on this dead-end
technology. 

Tony 

 -----Original Message-----
From: 	[email-masked] [mailto:[email-masked]] 
Sent:	Tuesday, November 30, 1999 12:05 AM
To:	Ian King
Cc:	[email-masked]
Subject:	Re: IP network address assignments/allocations information? 

On Mon, 29 Nov 1999 22:45:17 PST, Ian King said:
> any "lack" because of it.  I don't play UDP-based games or employ any of
the
> other relatively new protocols that are so sensitive to end-to-end-ness
> (should they be? was that a valid assumption?), so a NAT is a great
solution

Well.. Urm... TCP and UDP both assume that one endpoint is talking
directly in real time to another endpoint.  The NAT problems only
start when the protocol carries IP address/port information (such
as the FTP 'PORT' command), and the NAT isn't aware of that protocol's
translation requirements (If you see *this* at offset 80 of *that*
packet, smash it to read *foobar* instead).

I'll grant FTP an exemption, it came well before NAT units became
prevalent (Was there an FTP-over-NCP before The Great IP Deployment?).
However, I do agree that anybody designing a protocol in the last 3-4
years *should* have designed it to be firewall and NAT friendly.
(Yes, I know that can be difficult in practice.  I guess that's today's
"Welcome to Reality").

				Valdis Kletnieks
				Operating Systems Analyst
				Virginia Tech

---

From: [email-masked]
Date: Tue, 30 Nov 1999 18:25:24 -0500

> packet, smash it to read *foobar* instead).

I think we're actually saying the same thing here, and are violently
in agreement, from different viewpoints. A 'pre-existing clear
mapping' is what the NAT needs in order to do the datastream
manipulations needed.  Of course, if there exists such a mapping, but
your NAT is older or for other reasons doesn't understand/implement
it, you're still stuck.

I meant "the problems only start" in the context of the breakage a NAT
renders on a single connection that is assuming it's able to make an
unmangled, unmodified end-to-end connection.  If the NAT is able to
handle the translation, the connection still suceeds.  If the NAT
doesn't do it, the connection loses.  As Keith Moore pointed out in
http://www.cs.utk.edu/~moore/what-nats-break.html there are other
contexts *outside* that context that NAT has an impact on...

-- 
				Valdis Kletnieks

---

From: [email-masked]
Date: Tue, 30 Nov 1999 18:25:24 -0500