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

Re: (NAT) Re: Interactions between IPSEC and NAT

-----BEGIN PGP SIGNED MESSAGE-----


>>>>> "bound" == bound  <bound@zk3.dec.com> writes:
    bound> I have already figured out to avoid NAT in most cases with IPv6
    bound> and now working on an NNAT for IPv4 if I can find someone who
    bound> wants to do the writing?  At first I thought DHCPv4 could not do
    bound> NNAT but now I think it can though it does not have the
    bound> Reconfigure msg of DHCPv6 I think we can do it with Multicast
    bound> packets.  The other option is to use DHCPv6 for IPv4 nodes too,
    bound> which is possible.

  I think, what you are suggesting, is that: if an end host is going to
modified to do IPsec (on board or off board), then it can be modified to
do the appropriate NAT as well. This is distributed NAT. IPv6 with its use
of DHCP and site local addresses, practically mandates that hosts support
using different addresses depending on where the other end of the connection
is going to be.

  The only problem is getting the "external" address allocated, and letting
the centralized NAT box know about this so that it can route and/or tunnel
packets that match the appropriate "external" address (may include port
and SPI in its decision in the case of many-to-one NAT) to the internal
box.

  The solution, I must agree, is not to break IPsec, but to build smarter
NAT systems. The Internet was built around stateless routers (some say this
is part of its success), while NAT boxes and firewalls are stateful, so they
are violating the design architecture. Until one deploys IPsec on the end
nodes, NAT and IPsec will have to live on the same box and will have to share
state.
 
  In my drafts involving multiple firewall (or NAT) traversal, I didn't
say where exactly NAT was done, although I was trying to arrange the SA's
such that the firewall would be able to audit the packets in one mode, and
modify them in another mode. It involve transitive trust, which is hard.

   :!mcr!:            |  Sandelman Software Works Corporation, Ottawa, ON  
   Michael Richardson |Network and security consulting and contract programming
 Personal: <A HREF="http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/Bio.html">mcr@sandelman.ottawa.on.ca</A>. PGP key available.
 Corporate: <A HREF="http://www.sandelman.ottawa.on.ca/SSW/">sales@sandelman.ottawa.on.ca</A>. 


-----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
Charset: latin1
Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface

iQB1AwUBNNnXqdiXVu0RiA21AQFU2gL/Xv6W1aixBSIQs9wj5P0npaz4Gm1+cmoC
HrkGBvH967XBv0laXQJoZtdvk36huHo06Buxc3X1vnjpWO+7x8LI8QEbkpbRQKYF
QPxsmX3c+pZb56TLSQgJdHmJvwp+PInR
=pKf6
-----END PGP SIGNATURE-----
References: