North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: end2end? (was: RE: Where NAT disenfranchises the end-user ...)

  • From: Dickson, Brian
  • Date: Fri Sep 07 20:21:06 2001

Leo Bicknell wrote:
> On Fri, Sep 07, 2001 at 05:09:43PM -0400, Andy Dills wrote:
>> One is content, the other a content-delivery mechanism. Think about the
>> post office. It's perfectly acceptable for them to stamp a forwarded
>> address on the envelope to ensure it's delivery, but perfectly
>> unacceptable to modify the content inside.

> But NAT goes further.  Consider if the post office opened up your
> letter, looked at the return address on it, saw that was wrong and
> stuck the new one on it, put it back in the envelope and then sent
> it on its way.  That's exactly what NAT does with some protocols.

Funny story (with a NAT analogy):
The US post office will forward mail within the USA for free, but won't
redirect mail to outside the USA for free.

My roommate moved back to Canada. Rather than re-address (and pay)
per-letter, I saved a bunch of his mail up, boxed it, and sent it via the
post office.

International mail generally gets inspected, which is to say, opened.

The package contained a bunch of mail, with valid postmarks and addresses.
Somehow, the *contents* got re-injected into the mail system.
The mail returned to its original (ie old) address, thus defeating my
attempt to bulk-forward it to my ex-roommate. ;-)

The moral is, if I wanted my package to survive the broken forwarding
mechanism, I should have re-addressed the contents, too.

Or, if it absolutely, positively needs to get where you want it to go...
don't mail it.
(end funny story)

IP is the transport layer. While many programs may let us type IP addresses
at them, any protocol higher up the stack which involves or relies on IP
addresses is, IMHO, badly broken. It would be just as bad to involve MAC
addresses. At the very least, it defeats the whole purpose of having a

smd is correct in his observation of the overloading (network location and
ID) being a problem.

Generic NAT (1:1 or many:fewer, no special handling of ports or protocols)is
incompatible with things that put IP addresses in the payload and expect
them to match the headers.

If brand X of NAT is messing with the contents, it's probably to work around
this incompatibility, or rather to try and fix a broken protocol.
(Leo - you are complaining about a NAT box *fixing* a problem for you! Did
that occur to you?)

Anything that needs to assure identity, even using local knowledge of IP
addresses, should at a minimum do so by tunneling, so that the NAT affects
on the encasulation, not the encapsulated header+data. (Hello, IPsec.)  Or
better yet, use some other identity mechansim.

Fundamentally, TCP (which is the real issue) is client-server. (E.g.: Syn,
syn-ack, ack.) The server must be known; who the client is arbitrary and
irrelevant. (Not unlike NANOG. :-) )

It's really this simple: If you need to do non-TCP, server-server stuff, you
need a static IP. It doesn't matter whether dynamic IP and port comes from
NAT or DHCP - there will always be things you can't do behind those. If you
want to do those things, don't go behind one of them.

Or implement better protocols that don't break when NAT is used, or place
ridulous burdens on ports that need to be opened on firewalls (H.323 ?!?),
or better yet, use some kind of 3-way, 3-party handshake to establish
peer-peer between NAT'd client-type boxes (for programs that facilitate
copyright violations.) And by the way, whatever happened to the notion that
the firewall should also be a proxy at the application layer rather than a
mere packet-forwarding-and-munging box?

Brian Dickson
(now at Velocita, but speaking for himself.)