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

Re: Interactions between IPSEC and NAT



At 03:59 PM 2/4/98 -0500, Perry E. Metzger wrote:
>
>Dan Nessett writes:
>> Anyone thought about this so that they can provide us with a nice clean
>> answer :-) ?
>
>Yes. If you want security, you can't use NAT, because by definition
>the thing NAT is trying to do (peek in and/or alter your packets) is
>what security is designed to prevent. Protocols like SSL have exactly
>the same issue, btw. Any protocol that protects the contents of your
>data will have the same issue.
>
>This is not fixable -- any "fixes" someone could propose to this would
>be so horrible as to make the entire point of security moot.
>
>Perry
>
>

This is what bothers me about the direction IPSEC has taken.  The
addition of security should not break things like trusted NATs.  If you
define an IP "trusted node" as all hosts, routers, firewalls, NATs, etc., 
that want to interoperate securely as a secure network. Then the only thing 
IPSEC should do is secure IP packets, the IP header and payload, between 
two trusted nodes (actually between two trusted interfaces).  The question 
that remains is whether or not to allow untrustworthy nodes to handle the 
IP packets.  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.  If so, then just MAC the IP header (but still encrypt & 
MAC the payload).  In this latter case insecure NATs (and routers which 
fragment) will not be able to work with the secure nodes, but any insecure 
node that doesn't adjust the IP packet will work as-is.  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.

- Alex


Alex Alten
Andrade@Andrade.Com
P.O. Box 11406
Pleasanton, CA  94588  USA
(510) 417-0159



Follow-Ups: References: