ietf
[Top] [All Lists]

Re: NATs *ARE* evil!

2000-12-19 11:30:02
On Tue, 19 Dec 2000, Theodore Y. Ts'o wrote:

   Date: Mon, 18 Dec 2000 14:45:08 -0800 (PST)
   From: Mike Fisk <mfisk(_at_)lanl(_dot_)gov>

   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.

   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.

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

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.

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).

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.

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.

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?

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.

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



<Prev in Thread] Current Thread [Next in Thread>