Subject: Re: NATs *ARE* evil!

From: [email-masked] (Sean Doran)
Date: Sun, 17 Dec 2000 03:42:11 +0100 (CET)

I looked again.  Perry Metzger still writes:

| > So, I have to wonder, why is it that they have no option?
|
| Maybe because I hear from folks like you and others that you're
| ideologically opposed to deploying v6 instead of against it for
| technical reasons?

Wait, it's because of *me* that IPv6 isn't a stunning success compared to NAT?

I didn't realize that, when I asked the IAB to use their technical insights
as a market predictor, that behind the invisible hand of the marketplace
lurks little ol' me.  Maybe someone should tell Paul Krugman.

	Sean.
- --
Sean Doran, Pagan God of Market Forces
<[email-masked]>

---

From: Jon Crowcroft <[email-masked]>
Date: Sun, 17 Dec 2000 14:57:20 +0000

>>lurks little ol' me.  Maybe someone should tell Paul Krugman.

 Pagan God of Market Forces...

oh thats no good - i want to speak to the 21st century god of market
forces....and of course, she retired as uk primeminsiter a while
back...

so NATs address a user requirement as WELL as a network provider
requirement - for example, asymwetric nats let the user get away with
sloppier security (not just think they can ) by reducing the available
services

of course you could argue the same for ipv6 given your view that
noones useing it in that unlike an asymetric nat (i can reach you but
you can't reac me) v6 is symettreic in its ability to disable people
:-)

but fantasy aside, ipv6 involves _routing_ as well as addressing - NAT
reduces the problem space for providers and users by reducing the
number of services reachable - so? thats not exactly comparing things
on a level playing field is it?

to make v6 work tarks end users more work than v4 (they have to
(re(re)-number) and worry about security policies properly) and takes
router vendors some work to write some working code (something they
have few people left able to do - sure everyone else has fewer
still)).

so it isnt surprising that one has seen more deploym,ent than the
other 
, but it is not a measure of the releative (de)merits
of NATs and ipv6

thats just in yr. head....

 cheers

   jon

i'd like to think we could talk about technical things we CAN do to
maintain and increase connectivity, as well as retaining or decreasing
the ease of config for an end user - to some extent, its one of those
threshold things - despite its shortcomings, if people can get over
the v6 threshold, it might sort things out provided a half way decent
addressing plan AND retaining  NAT type functionality for various
reasons.....of course there's multihomeing to worry about, but nothing
in any other scheme 	've seen sorts this - its an inherently hard
problem to provide "always on" addresses, aggregation/hierarchy for scaling, 
and multihomeing - some sort of set theory #101 makes this obvious...
j.

p.p.s
why has noone addressed my replace the DNS comment ? :-)

---

From: Keith Moore <[email-masked]>
Date: Sun, 17 Dec 2000 12:36:19 -0500

> to make v6 work tarks end users more work than v4 

if "v4" includes dealing with an increasingly severe shortage of
address space (which sooner or later implies forced renumbering)
and/or tying together multiple NATted networks, it's not at all 
clear that this takes less work than v6.

Keith

---

From: "Perry E. Metzger" <[email-masked]>
Date: 17 Dec 2000 13:32:03 -0500

> clear that this takes less work than v6.

It certainly takes more. The amount of NAT equipment out there is
astonishing, and as I said at the plenary, people are starting to pay
Real Money (as in millions a year) in large organizations to keep the
NATs working properly. Several layers of NAT has become common, and
NATs are stateful, which means they are necessarily more of a
reliability problem than routers.

v6 is really no harder to use than the old v4 pre-NAT network was.

It is true that v6 qua v6 does not solve the route explosion
problem. It is also true that the route explosion problem is a real
problem. However, it doesn't make it worse, either.

Perry

---

From: RJ Atkinson <[email-masked]>
Date: Sun, 17 Dec 2000 14:24:16 -0500

At 13:32 17/12/00, Perry E. Metzger wrote:
>problem. It is also true that the route explosion problem is 
>a real problem. However, it doesn't make it worse, either.

        From an operator perspective, supporting *2* IP protocols
is much harder than supporting just one.  If one looks around,
very few NOCs on the planet today could reasonably be called
"fully successful" just managing IPv4.

        So, if one wanted IPv6 to be promoted by operators,
one might spend time listening to operators and devising
clever ways to make multi-homing and routing work visibly
*better* with IPv6, to compensate for the much increased
operational burden.  Oddly enough, some folk are doing just
this.

Ran
[email-masked]

---

From: Jon Crowcroft <[email-masked]>
Date: Mon, 18 Dec 2000 08:20:07 +0000

In message <[email-masked]>, RJ Atkinson type

 >>"fully successful" just managing IPv4.

lets not forget that supporting IP at all is counter intuitive - the
business case for providing interconnectivity to _other_ peoples
services is not there, unless they are already - it requires socialist
(i.e. government subsidy) to make the internet what it is now - i am
betting that most telco-child ISPs love NATs and simialr technology
coz they promote walled gardens (like wap etc) and lock in and all
that old stuff, BUT the only way out of this deadend that is IP v4
requires either OneBigIsp to take the plunge as a way of getting more
check marks on their service, or as a way of getting an even bigger
wall aroudn their garden (e.g. 3G guys might consider this:-),
OR it requires some sort of socially responsible behaviour (e.g. most
the 6bone is probably subsidized) to glop it all together and just
make it inevitable....(this is not specially a v6 plug, just a plea
for connectivity)
 
 >>operational burden.  Oddly enough, some folk are doing just

indeed - we might as well work with what we have - hey, there's a lot
of stuff one can do with the code still, including just re-writing a
lot of cruft in routing code - btw, the way 3G access networks work,
one ought to be able to mandate for really good aggregation - i think
a lot of people forget that the exponential growth curve of the internet 
is not made out of homogeneous pieces - its actually a series of
technology changes - the phases from government and unviersity and
dial up, and dsl, and cable modem, and now mobile are all subtly
different (as witness they have their own ISP cultures and own address
allocation and routing headaches) - while datagram is one size fits
all as a way of communicating, we need a range of address alloc and
routing techniques for the different and future access and core
networks....i thought most this was discussed in the whole ipng debate
and was why we solicited input so widely....so now lets go (finish)
coding it

 cheers

   jon

---

From: [email-masked] (Claus Färber)
Date: 18 Dec 2000 13:24:00 +0100

>> to make v6 work tarks end users more work than v4
                         ^^^^^^^^^
> clear that this takes less work than v6.

You missed the most important part: If I, as an end user, want to  
have more devices than my ISP gives me IPv4 addresses, switching  
to IPv6 does not help at all: I'd only be able to talk to other  
IPv6 hosts. NAT _does_ help.

What's missing for IPv6 is a large number of other sites that  
support - or require - it.

Claus
-- 
http://www.faerber.muc.de

---

From: "Theodore Y. Ts'o" <[email-masked]>
Date: Mon, 18 Dec 2000 13:07:03 -0500

From: "Perry E. Metzger" <[email-masked]>
   Date: 17 Dec 2000 13:32:03 -0500

Perry, 

The flaw in your argument is that you're assuming that the only reason
to do NAT is because of the address space problem.   My concern is that
it may turn out that some transport/routing people may conclude that we
may also need to do NAT to solve the routing problem.   In which case,
we're back to where we started.

I'd feel a lot better if we could get key routing/transport people to
sign some contract in blood stating that the IPV6 address is guaranteed
to be invariant, and that any attempt to design boxes which muck with
the IPV6 address in transit is architecturally out of bounds.  That may
seem to you to be obviously true, but I 10 years ago we assumed the same
would be true for IPV4 addresses.

If it turns out that we need some kind of routing identifier in the IPV6
address, whether it's the dreaded 8+8 scheme, or adding another 16 byte
value in the header which router are free to muck with to our heart's
content, at some level, whatever, I don't care.  I'm security guy, not a
routing guy, so I don't know what will work the best, and at some level,
I don't care --- just so long as it works, and that we have something
which *everyone* agrees will be an invariant end-point identifier, now
and forever, world without end, Amen.

Otherwise, 5-7 years from now, we'll be using IPV6, and there will be a
need for some kind of routiing-gw/NAT boxes, and people will *still* be
complaning that it's all IPSEC's fault that IPSEC doesn't work through
NAT boxes, and the anti-NAT people will be complaining that the NAT
folks have changed the rules again.  And all that work which the IPV6
rollout folks have put into that project will in the end be for naught.

							- Ted

---

From: Geoff Huston <[email-masked]>
Date: Tue, 19 Dec 2000 05:39:45 +1100

>would be true for IPV4 addresses.

I'm not sure that this is possible - part of the characteristics of today's 
Internet is that its is flattening out. The concept of hierarchical 
connectivity with 'upstreams' and 'downstreams' is one which appears to 
have relied on a high marginal cost of communications services. Now as I 
understand the current deployment plan there are TLAs and sub TLAs, and an 
apparent hierarchical view of the world again.

Imagine, for a second, what the topology of the Internet would be if 
communications services were free. Now turn up the unit cost knob an little 
and do the same thought experiment.

Part of the issue we faced in the Big Internet discussions, and part of the 
issue we face now is the semantics of the address and the level to which 
these semantics are overloaded. Is an address an identification of 
identity? A key to absolute location? A key to relative location? An 
encoding of the local topology? My concern, and the reason why I'm chiming 
on Ted's signing blood proposal is that in looking at the structure of V6 
addresses, at least the structure of the immediate deployment 1/4 or so of 
the addresses, we appear to have adopted an approach which is not far 
removed from the provider address hierarchy structure of V4 today. My 
lurking concern is that it is not working in the V4 routing system given 
the large percentage of table entries which are more specific 
advertisements of aggregate announcments (approx 40%) and it won't work for 
V6 either (using the term 'work' very loosely in terms of being able to 
route accurately, efficiently and with a clear scaling property).

It appears that the intended address structure and deployment structure 
appear to be at variance, and when that happens the temptation to alter the 
address in flight to suit each local region's environment may well be 
overwhelming. So I'd prefer to keep my blood to myself, thanks as its a 
contract I suspect we'll break within the operations environment. (and no I 
don't think that this would be a clever move, and yes, we will regret it 
afterwards.)

---

From: Mike Fisk <[email-masked]>
Date: Mon, 18 Dec 2000 14:45:08 -0800 (PST)

On Mon, 18 Dec 2000, Theodore Y. Ts'o wrote:
> My concern is that it may turn out that some transport/routing people
> may conclude that we may also need to do NAT to solve the routing
> problem.  In which case, we're back to where we started.
> 

Gateways that surreptitiously modify packets can break ANY end-to-end
protocol no matter what layer it's at.  Assume that we sacrifice IP
addresses as not necessarily end-to-end.  Fine, there are gateways that
need to modify your TCP ports too.  Okay, sacrifice make it so ports
aren't covered by e2e assumptions like IPsec.  Fine, there are gateways
that do ACK spoofing.  Okay, sacrifice all header data and assume that
only payload is e2e.  Whoops, even the payload has to be modified by some
gateways.  The hypothesis that you can have these gateways and have
any part of the packet be guaranteed to be e2e is false.

But I don't think these gateways are evil and should (or could) be
forbidden.  My hypothesis is that end applications have to know that these
gateways exist.  They shouldn't be surreptitiously transparent; they
should be discoverable and applications should be aware of how high   
in the protocol stack that gateway reaches.

Take the hardest problem, a gateway that reaches all the way up to the
application layer to do content inspection.  The application has to make a
trust decision about whether or not it is willing to negotiate a key with
that gateway that will let it decrypt the data.  Otherwise, the gateway
may refuse to pass the traffic.  So the application consents, a protocol
library provides the gateway with a decryption key, and the application
annotates the little padlock in the corner of the user's screen
appropriately.  If so desired, the application can implement a policy that
the decrypted form of the user's credit card number won't be provided to
any proxy or endpoint that doesn't have a certificate signed by Visa's
credit card practices review authority.
  
Take an intermediate problem.  Assume that only address and port
translation are required by the gateway.  The application can therefore
assume e2e payload authenticity and privacy, but cannot assume e2e privacy
of its ports.

So that means that the coverage and keying of IPsec and TLS needs to be
negotiable based on the policies of intervening gateways (middleboxes).  
And that, of course, if predicated on the ability to locate middleboxes.

Given our inability to rule out the need for gateways that change IP
addresses (or other routing headers), this leads to the conclusion that
applications shouldn't use any header field (IP address, port, etc.) for
authentication.

> rollout folks have put into that project will in the end be for naught.

As far as naming (who) versus routing (where) is concerned, endpoint
naming seems as problematic as user naming is for X.509, etc.  Why not
apply the theory that a participant can be uniquely identified (but not
necessarily located) by its key(s) and that no fixed mapping to or from a
globally unique name (IP address) is necessary?

Let's say a user sees a billboard and wants to communicate with what the
billboard calls "www.cheapwidgets.com".  Given a uniformly accepted DNS
root or .com TLD, I would argue that DNSSEC can provide the verifiable
chain to the key known as (.com's cheapwidgets's www).  It will also
provide a mapping to the current routing address (which could be a point
of aggregation that knows a better local address).

More sophisticated directory services (or SIP servers) can provide the
same secure mapping to a key and/or DNS name.

-- 
Mike Fisk, RADIANT Team, Network Engineering Group, Los Alamos National Lab
See http://home.lanl.gov/mfisk/ for contact information

---

From: "Theodore Y. Ts'o" <[email-masked]>
Date: Tue, 19 Dec 2000 01:08:40 -0500

Date: Mon, 18 Dec 2000 14:45:08 -0800 (PST)
   From: Mike Fisk <[email-masked]>

OK, in that case, we've completely thrown out the end-to-end principle,
and completely wiped out any possibility of IPSEC.  If that's the world
we live in, where any part of the IP header can be subject to attack by
an intermediate attacker.... err, "service provider", then you shouldn't
be using IPSEC.  You should be using TLS instead.

It of course also means that no part of the IP header can be
authenticated in anyway, since it's of course all subject to change by
such gateways.

Is that really the architecture that we should be building in the
Internet.  I know some extremists would say yes, absolutely, and others
would be say that this would be a horror.  The problem though is that
we're designing that assume (and depend upon) both architectural 
philosophies.  Is it any wonder that we're having disconnects?

						- Ted

---

From: Dave Crocker <[email-masked]>
Date: Tue, 19 Dec 2000 06:54:31 -0800

At 01:08 AM 12/19/00 -0500, Theodore Y. Ts'o wrote:
>... then you shouldn't

Unfortunately, the production Internet (ie, since 1983) has never been 
fully end-to-end at the IP layer.  Never.

Arguably it has never been end-to-end at the application layer, either, nor 
even application-layer data.

Gateways have always been a part of the Internet.  We have simply chosen to 
ignore them, except for the case of email (smtp/x.400).

It's fine to create a clean architecture, but not very helpful to ignore or 
complain about market-driven extensions (or work-arounds, or...) to it.

Folks -- people would not be making those extensions unless they 
experienced benefit in them.

We claim to believe that the market is the ultimate venue for resolving 
choice among standards.  We need to acknowledge that that applies to 
missing standards, as well as competing standards.

=-=-=-=-=
Dave Crocker  <[email-masked]>
Brandenburg Consulting  <www.brandenburg.com>
Tel: +1.408.246.8253,  Fax: +1.408.273.6464

---

From: Mike Fisk <[email-masked]>
Date: Tue, 19 Dec 2000 09:47:42 -0800 (PST)

On Tue, 19 Dec 2000, Theodore Y. Ts'o wrote:

> OK, in that case, we've completely thrown out the end-to-end principle

It's an argument of semantics, but I prefer to say that we're separating
transport-layer end-to-end from application-layer end-to-end.  Make
applications explicitly terminate transport connections at gateways.  So
what is now a connection from me to you across a NAT and a proxy-ing
firewall would be come a session-layer connection from me to you served by
transport connections from me to the NAT, from the NAT to the proxy, and
from the proxy to you.

Just as layer two frames don't cross routers, layer three and four frames
don't cross these upper-layer gateways.  I want to get rid of
surreptitious proxies and gateways, but to get there you have to provide
similar services somewhere in the stack.  Today we maintain route tables,
ARP for the router's layer two addresses, and form a packet.  We need
something equivalent to handle the discovery and addressing of upper-layer
gateways.

The presentation I gave at the midcom BOF covers some of this:
http://public.lanl.gov/mfisk/papers/midcom-bof.pdf

> be using IPSEC.  You should be using TLS instead.

That's the crux.  If I live in an institution with a NAT or firewall,
there is a policy that I will use that network "service".  There may be
other policies regarding what other intermediate gateways you trust.  
Many people will favor trusting as few (zero) gateways as possible.  
Hopefully these policies will drive people away from the use of these
gateways, but I don't think we can assume that gateways will never exist.  
We need good protocol mechanisms that allow those policies.

The marginal value I see in IPsec is that it is useful for protocols other
than TCP.  For TCP applications, I confess that I don't see much value in
IPsec (not that TLS has any particular merits, it just became more common
first).

> authenticated in anyway, since it's of course all subject to change by

Yes, I assert that that is an architectural assumption (concession) that
needs to be made.  You might be able to authenticate the IP header of the
gateway, but that doesn't help you much with application-level e2e
authentication.

> philosophies.  Is it any wonder that we're having disconnects?

Agreed.  We have to agree on what assumptions we can make.  We need more
questions like "can we sign in blood that the IP address will not be
modified".  Unfortunately, I don't think we can make that particular
assumption (between application end-points).

Yes, some of us are proposing a departure from some current architectural
assumptions, but I think that there is sufficient evidence that there are
legitimate (if unfortunate and messy) needs for this agility.  You're
correct in fearing that we can't just put a stake in the sand and swear
them away.

---

From: Keith Moore <[email-masked]>
Date: Tue, 19 Dec 2000 14:47:02 -0500

> fully end-to-end at the IP layer.  Never.

this depends largely on what you call "the Internet".  
 
> complain about market-driven extensions (or work-arounds, or...) to it.

so we should pretend that everything is rosy then?

(I can see it now...
"Doctor Strangenet, or How I Learned to Stop Worrying and Love the NAT")

> experienced benefit in them.

understood.  there is no question that NATs provide some localized,
short-term benefit.  just like burning rainforests, or producing toxic waste.

> missing standards, as well as competing standards.

The market may be the ultimate venue, but it isn't exactly blessed with 
foresight.  We most certainly need to acknowledge that when markets
develop "solutions" which damage the net, that it's often due to a lack
of facilities in what the net provides.  But that doesn't mean that we
should axiomatically accept "market-driven 'solutions'" as viable in
the long term.

Keith

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 21 Dec 2000 10:11:45 +0100

>transport connections from me to the NAT, from the NAT to the proxy, and

these are called "application layer gateways", and exist in droves already.
Most firewalls implement them, in addition to NAT and packet filters.

--
Harald Tveit Alvestrand, [email-masked]
+47 41 44 29 94
Personal email: [email-masked]

---

From: Mike Fisk <[email-masked]>
Date: Thu, 21 Dec 2000 09:50:06 -0800 (PST)

> Most firewalls implement them, in addition to NAT and packet filters.

Yes, I was being slightly more general to include other gateways that
don't necessarily operate at the application layer:  
TCP-splicing/spoofing, NAT, SOCKS, etc.

The problem is that the protocol mechanisms to discover and use these
gateways are piecemeal and inadequate.  That leads many of them to be
implemented "transparently" which breaks protocols that don't know there's
a gateway.

---

From: V Guruprasad <[email-masked]>
Date: Thu, 21 Dec 2000 14:37:16 -0500

> implemented "transparently" which breaks protocols that don't know there's

One way to let higher protocols transparently cross such gateways is described
both in Cheritan's Triad project and my I-D on addressless networking. The
cut is made just above the IP layer - Triad shows that higher protocols like
TCP can be made happy with pretending there's an IP address below. I more
specifically propose a 32b switch path termination - as long as the 32b number
serves to identify an e2e path, whether or not it is an e2e destination
address and/or transits gateways would be irrelevant to the e2e operability
of the TCP layer. In the limit of fine-granularity, NAT'ing becomes no different
from label switching, so what I'm suggesting is that we take the bull by
the horns once and for all and run MPLS over IP instead of under it... That
way, you'd obsolete NATs and SOCKS in the longish run, but that's another story.

-p.

---

From: Sam Liang <[email-masked]>
Date: Thu, 21 Dec 2000 14:02:24 -0800 (PST)

> both in Cheritan's Triad project and my I-D on addressless networking. The
         
  Thanks for citing the TRIAD project.  The principal investigator is
Prof. David Cheriton at Stanford.  For details, see
http://www-dsg.stanford.edu/triad/index.html.

Sam