[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Interactions between IPSEC and NAT

Alex,

>>> This is what bothers me about the direction IPSEC has taken.  The
>>> addition of security should not break things like trusted NATs.
>>
>>The function of IPsec is to keep a packet from being touched or read
>>in transit.
>
>IP packets are designed with routing in mind.  There are fields which
>need to be adjusted between hops.  This means IP security can only be
>designed with a single hop in mind.  This also means that IP security
>must be part of a complete security system, of which IP security is
>just one component, the component which protects inter-router hops.
>A secure, trusted NAT can certainly be part of that system.

Not really true. Use of tunnel mode allows for modification of an outer IP
header without violating the security of the encapsulated packet.  AH is
explicitly design to exempt the mutable fields in an IP header, while
providing integrity and authenticity for the remainder of the datagram.  IP
S/D addresses were not intended to be modified en route (except in the case
of source routing, a case that AH knows to accommodate), and it is the
assumption of immutability for these addresses that NAT violates and causes
problems for IPsec.

>>> If not, then encrypt the IP header, since all the trusted routers
>>> can decrypt it, decide how to route it, and then re-encrypt before
>>> transmitting it.
>>
>>We don't do that, actually. You can't bring all the routers on the
>>internet into your security perimeter -- that simply won't work. Thus,
>>we don't try. IPsec works via encapsulation -- the outer IP address is
>>in the clear, as it must be for routing to work.
>
>This is realistic, I stated this as my alternative.  However the outer IP
>address must be at least be verified somehow, either via a MAC over it or
>duplicate routing information inside the protected encapsulation area.

Trusting (intermediate) routers in terms or confidentiality, integrity,
etc, is a violation of the principle of least privilege, making a
hop-by-hop approach generally less desirable.

>>For stuff like NAT to work you would need to include all NAT boxes and
>>routers in your security perimeter, and I fundamentally cannot think
>>of a design for this stuff that will work and will involve arbitrary
>>numbers of intermediate nodes on the global internet -- I belive that
>>it just can't be done in practice. Maybe I'm just not bright enough,
>>but I think that instead its an issue of having enough arrows in my
>>back to know better.
>>
>
>I absolutely agree.  In fact, regardless of NAT, all the routers must
>be part of the security system (or security perimeter).  For an
>arbitrary number of insecure routers, then I think only a transport
>or application level security will work.

In general, routers have a secruity role only with regard to denial of
service, and, to a lesser extent, traffic flow confidentiality.

>>> The really difficult issues of how to establish and control the
>>> network of trusted nodes, and how to implement and enforce
>>> network-wide policy can then be tackled.
>>
>>When you come up with a functioning protocol, let us know. I don't
>>believe one is possible, but I'm more than willing to listen.
>>
>
>Admittedly it is a tough problem to solve, given the datagram nature of
>IP and its high performance requirements for routing.  It's much easier
>to do it at the TCP level.

Security protocols at the transport and higher layers are simpler, but they
require end system deployment, which introduces a different set of
problems, e.g., management of desktop security.  Firewalls are an
attractive technology in part because they centralize security
administration.  IPsec is attractive because it can be deployed on either
desktops or in security gateways, and interoperates between both types of
implementations, so that one can choose the granularity for deployment.

Steve
References: