Subject: arguments against NAT?

From: Zefram <[email-masked]>
Date: Tue, 2 Dec 2003 12:07:21 +0000

A new sysadmin has recently joined the company where I work (I am a
software engineer and part-time sysadmin).  As he's the only full-time
sysadmin here, the network now falls under his purview.  Today he
showed me his plans for reorganisation of the network, and they involve
introducing NAT on a big scale.  His main arguments in favour of NAT
are security (which I debunked), address shortage (which we don't have),
and administrative convenience (which he never explained enough for me
to see).

I've argued strongly against NAT, but he's one of those people who seem
to be willing to accept arbitrary amounts of pain ("we don't need to
use [protocols that put IP addresses in payload]", "timeouts aren't
a problem").  I'm now pointing him at some relevant RFCs.  My question
for the list is is there a web page or other document anywhere that
comprehensively states the case against NAT?

-zefram

---

From: "Anthony G. Atkielski" <[email-masked]>
Date: Tue, 2 Dec 2003 13:55:29 +0100

Zefram writes:

> My question for the list is is there a web page or
> other document anywhere that comprehensively states
> the case against NAT?

If your new administrator is of the type who fixes things that aren't
broken, it may be the admininistrator that needs replacement, not the
network configuration.

As you point out, you aren't short on address space (the primary reason
for NAT). Security is not a problem for NAT, since any good netadmin is
going to know how to block and route traffic with routers, firewalls,
proxies, etc., to avoid problems. Too bad if it is time-consuming ...
that's what he is being paid for, so he can't complain.

Admininstrative convenience is not a reason, either.  If admininstration
were that convenient, his position would be redundant.  In any case,
restructuring an entire network so that one can spend more time playing
Doom in one's cube is a very poor justification for the operation.

NAT has obvious disadvantages. The Internet is not designed to address
multiple machines with one IP address, and lots of things will break
when NAT is in place. Incoming machine-specific traffic is the major
problem. Chat and instant messaging services will fail, and there is no
way to get them to work with NAT. Streaming services may fail as well.
NAT can compromise point-to-point security. Overall it's a clever but
nasty kludge that I cannot see implementing if it isn't required.  It
works for SOHO configurations with just one public IP address and the
like, but it seems like a very poor idea for any organization that
doesn't have an address shortage.

---

From: "Spencer Dawkins" <[email-masked]>
Date: Tue, 2 Dec 2003 07:22:20 -0600

Yeah, but this was the point. Where is the community consensus
document that says all this?

Spencer

----- Original Message ----- 
From: "Anthony G. Atkielski" <[email-masked]>
To: "IETF Discussion" <[email-masked]>
Sent: Tuesday, December 02, 2003 6:55 AM
Subject: Re: arguments against NAT?

> _______________________________________________
> This message was passed through [email-masked],
which is a sublist of [email-masked]. Not all messages are passed.
Decisions on what to pass are made solely by IETF_CENSORED ML
Administrator ([email-masked]).

---

From: "Spencer Dawkins" <[email-masked]>
Date: Tue, 2 Dec 2003 07:55:13 -0600

And, to follow up on my own posting (sigh), RFC 3235 and 3027 are
Informational... we have no STD, and no BCP, that come up when you
search for NAT or Network Address Translator, so... perhaps there is
no community consensus document that says what the community consensus
appears to be, and the best thing to do is to Google "NAT end-to-end"
and leave the result as an exercise for the reader?

Sigh.

Spencer

---

From: Melinda Shore <[email-masked]>
Date: Tue, 2 Dec 2003 09:11:36 -0500

> document that says all this?

3235 goes into some of it, albeit from an application perspective.
2993 does as well, but at three years old it's already slightly
outdated.  One thing that hasn't been discussed and needs to be is
that NAT workarounds have become a growth industry and they introduce
a bunch of new security and other problems.

I'm not sure if you're arguing that there should be a comprehensive
document presenting the technical problems introduced by NATs.  I
suspect there should be, although frankly this is one particular
area where there's a clear and growing divide between this community
and the network administrator community (particularly enterprise
and residential).  We've known about these problems for a very
long time and the argument that these problems are a serious impediment
to network {stability,robustness,whathaveyou} have not been accepted
by the people who deploy real networks.

At this point I really don't think it's the case that we haven't
made the argument well, or at sufficient volume.  People who put NATs
in their networks are usually responding to immediate or perceived
needs, and I think it's frequently, if not mostly, the case that they
understand what they're doing and simply don't have the luxury of
being able to worry about the longer-term implications.  In that
context our arguments are sometimes perceived as condescending and
out-of-touch.  Because of that it becomes difficult for the "NATs
cause problems" position to become sufficiently widely accepted to
overcome the conventional wisdom that NATs provide security, etc.
I imagine we're going to be running into a similar situation with the
mad use of tunnels in the not-too-distant future.

Melinda

---

From: Zefram <[email-masked]>
Date: Tue, 2 Dec 2003 14:22:07 +0000

>document that says all this?

RFC 2993 is the closest thing I could find to what I want, and it's
rather good (thanks Tony), so it's at the top of the reading list I've
sent to the new sysadmin.  I'll be interested to see his reaction to it.

Looks like disaster may be averted in my case: the responsible manager,
in a rare fit of technical eptitude, has spotted that the new sysadmin is
interfering in things that already work.  Strangely, address allocation
is just about the only thing on this network that *isn't* broken.

-zefram

---

From: Eliot Lear <[email-masked]>
Date: Tue, 02 Dec 2003 06:34:32 -0800

> comprehensively states the case against NAT?

This organization makes its opinions known through not only standards 
but RFCs that have been reviewed by IETF working groups, the community, 
and the IESG.  RFC 2663 is the one you want.   See in particular scaling 
issues, multihoming, DNS, and IPsec, just to name a few.

Eliot

---

From: "Anthony G. Atkielski" <[email-masked]>
Date: Tue, 2 Dec 2003 16:14:51 +0100

Spencer Dawkins writes:

> ... perhaps there is no community consensus document
> that says what the community consensus appears to be ...

I don't believe there is any consensus.  I'm among those who don't like
NAT, considering it only an occasional, necessary evil.

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 03 Dec 2003 00:45:45 +0900

Spencer Dawkins;

> and leave the result as an exercise for the reader?

There was a discussion on IETF ML in April and May of 2000 on

	draft-ietf-nat-protocol-complications-02.txt

and, vint, for example, wrote:

	Date: Sun, 30 Apr 2000 06:20:48 -0400
	From: "vinton g. cerf" <[email-masked]>
	Subject: Re: draft-ietf-nat-protocol-complications-02.txt

	that's right - they use iMODE on the DOCOMO mobiles. iMODE and
	WAP seem to have that in common: a non-IP radio link protocol
	and an application gateway. Of course, this limits the applications
	to those that can be "translated" in the gateway, while an end to
	end system (such as the Ricochet from Metricom) would allow 
	essentially any application on an Internet server to interact
	directly with the mobile device because the gateway would merely
	be an IP level device, possibly with NAT functionality.

So, according to vint, NAT is less evil than gateway translation.

Of course, the technical reality not tainted by commercialism is
that NAT translate protocols at the IP, transport and application
layers.

But, you can't expect much help against NAT from IETF.

							Masataka Ohta

---

From: [email-masked]
Date: Tue, 02 Dec 2003 10:48:03 -0500

> and leave the result as an exercise for the reader?

You want "no consensus", wander over to the NANOG list and suggest that any ISP
who isn't aggressively filtering RFC1918 source-address packets is violating
the RFCs.. ;)  You want a *flamestorm*, mention it to the Tier-1 which numbers
their point-to-points between their POPs out of 1918 space, causing blackholes
when they send ICMP messages to someplace that DOES ingress filter them ;)

---

From: Joe Touch <[email-masked]>
Date: Tue, 02 Dec 2003 08:55:20 -0800

Zefram,

Our take on why NATs are bad is at:
http://dsonline.computer.org/0207/departments/wp4icon.htm

And our method for undoing what a NAT does, called "TetherNet" is at:
http://www.isi.edu/tethernet and paper about it is at: 
http://www.isi.edu/touch/pubs/discex03-tethernet/
(Contact me if you want to try one out.)

It's been difficult to understand how the IETF has for several years 
worked to develop "NAT standards" - notably since NATs themselves break 
what few standards the Internet has (RFCs 1122 & 1123 - aka STD-3 and 
RFC 1812 - aka STD-4). As I've said in many WGs, NAT standards are 'laws 
for the lawless'.

As others have observed, this is hardly community consensus, however.

Joe

Zefram wrote:

> This message was passed through [email-masked], which is a sublist of [email-masked]. Not all messages are passed. Decisions on what to pass are made solely by IETF_CENSORED ML Administrator ([email-masked]).

---

From: Keith Moore <[email-masked]>
Date: Tue, 2 Dec 2003 12:17:44 -0500

> My question

Because until recently there was a widespread belief that we were stuck with
NAT and might as well make the best of it, and that we couldn't make the best
of it if we were criticizing it.  Also there was a naive hope that NAT's 
problems could somehow be solved and that the internet could function without
a coherent address space.  Finally there was a NAT working group that worked
hard to legitimize NAT (its charter notwithstanding), and the existence of 
this working group precluded any constructive effort to discourage NAT.

---

From: Paul Vixie <[email-masked]>
Date: 02 Dec 2003 18:25:03 +0000

> ...
> use [protocols that put IP addresses in payload]",

how about DNS?  two of the extra years that got tacked onto the decade
of DNSSEC were due specifically to "middleboxes" who intercept/regenerate
DNS transactions.  this has also slowed the deployment of EDNS.  anyone
who deploys NAT is freezing their DNS protocol competence at "today's"
level, which is not only bad for the people behind that particular NAT
but will be bad for the standards people who are trying to evolve the DNS.

(or did folks generally just not know that DNS includes IP addresses in
its payload, and that a successful NAT box has to intercept/regenerate DNS,
and that NAT boxes who don't understand EDNS just cause timeouts due to
improper end-to-end signalling of feature levels, and that this regeneration
activity has been absolutely fatal to several proposed DNSSEC designs?)

> ...  I'm now pointing him at some relevant RFCs.  My question for the
> list is is there a web page or other document anywhere that

eliot's answer to this part was so good that it bears repeating:

        "This organization makes its opinions known through not only
        standards but RFCs that have been reviewed by IETF working groups,
        the community, and the IESG.  RFC 2663 is the one you want.  See in
        particular scaling issues, multihoming, DNS, and IPsec, just to
        name a few."

my own summary of the issues is that the internet's architecture has a
number of constraints and that if we want to continue to "scale the design"
we all have to operate within those constraints.  operating outside of the
generally accepted constraints, or adding new constraints that aren't
generally accepted (or even generally known) makes evolution just stop.
(this issue came up during the verisign sitefinder debates, and i'd like
to thank klensin and bellovin for clarifying my thoughts on this topic.)
-- 
Paul Vixie

---

From: Doug Royer <[email-masked]>
Date: Tue, 02 Dec 2003 11:43:36 -0700

Anthony G. Atkielski wrote:

>NAT has obvious disadvantages.  ...
>

>... Chat and instant messaging services will fail, and there is no
>way to get them to work with NAT.
>

So far I have not been able to get chat or instant messages services to 
fail because
of NAT. (Not that I am saying that NAT is valuable or a problem)

Perhaps it is more accurate to say that some NAT implementations break 
chat and IM?

> Streaming services may fail as well.
>

-- 

Doug Royer                     |   http://INET-Consulting.com
-------------------------------|-----------------------------
[email-masked]                 | Office: (208)520-4044
http://Royer.com/People/Doug   |    Fax: (866)594-8574
                               |   Cell: (208)520-4044

               We Do Standards - You Need Standards

---

From: Joe Touch <[email-masked]>
Date: Tue, 02 Dec 2003 11:17:03 -0800

> Perhaps it is more accurate to say that some NAT implementations break 

Some NAT implementations break (your favorite protocol here). The 
problem isn't whether a particular NAT breaks a particular protocol; the 
larger problem is what to do when you have a protocol you need and 
you're behind a NAT you can't control.

>> Streaming services may fail as well.

Agreed.

Joe

---

From: Joe Touch <[email-masked]>
Date: Tue, 02 Dec 2003 11:17:08 -0800

Melinda Shore wrote:
...
> mad use of tunnels in the not-too-distant future.

One of the arguments in favor of NATs has been efficacy - we have them, 
they're cheap, and when they work they work well and with no configuration.

Since we've been lacking a similar non-NAT solution, we (ISI) built one 
called TetherNet, as posted earlier:
http://www.isi.edu/tethernet

The other argument in favor of NATs is that they already exist, so we 
have to live with them. TetherNet takes a contrary approach, undoing the 
NAT-ing instead.

FWIW, the "seriousness of the impediments" (Michael Py) are felt 
wherever NATs are deployed. Things break - in various NATs, these 
'things' include L2TP to secure email access, VoIP/teleconferencing, 
FTP, and many services that rely on servers on the local machine (e.g., 
Compaq's automated software update system). Other, less serious problems 
include stalled or very slow web and telnet connections. These breakages 
are often misattributed to host, router or DNS misconfiguration, OS 
glitches, or the network being down. Those who don't know better just 
live with a flakey or slow network.

Joe