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

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



-----Original Message-----
From: Michael C. Richardson <mcr@sandelman.ottawa.on.ca>
To: bound@zk3.dec.com <bound@zk3.dec.com>; ipsec@tis.com <ipsec@tis.com>;
nat@livingston.com <nat@livingston.com>
Date: 5 февраля 1998 г. 20:35
Subject: Re: (NAT) Re: Interactions between IPSEC and NAT


[ . . .]
:  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.

Once you have centralized NAT BOX _and_ the wish to have NAT on end node
IPsec the problem can be solved:
- End Node NAT requests from BOX a public address allocation
- End Node does NAT, then IPsec, then IPinIP tunnel to BOX.
- BOX either strip tunnel or does one more NAT and IPsec for the
  outer header.
- BOX send data out

If BOX runs IPsec, the end node can get address allocation secured
with ISAKMP SA (requires ISAKMP modification) or with an app level SA
(a job for NAT guys).
Since an end node will have NAT on it, the last can be smart enough to
release allocated addresses from BOX after using.

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

How do you consider an IPsec box then, stateless or stateful?

[ . . .]
--Alexei