RE: Towards closure on NAT traversal.

["Greg Bailey" <greg@minerva.com>]

Yet there are some things that seem to me logically impossible in
the presence of a NAT.  Consider an ESP encrypted, or even just
authenticated, FTP control channel.  In order for the NAT to function
"transparently" it must assemble, parse, and alter the TCP stream
when necessary (PORT command).  How can this possibly work using
straight IP with IPSec unless the NAT cracks the keys et cetera?  Not
to mention that a NAT box with such capabilities would be an even
more powerful assault weapon than is a plain old NAT box...

I would submit FTP as a proof of existence of insoluble problems in
*transparently* traversing a NAT with IPSec.

Even adding Security Gateway code to a NAT, which in many respects
would seem the best form of "IPSec pass-through", would still leave
the problems caused by uncoordinated use of private address space
on the other side of the NAT in non VPN environments.

How long a list of exceptions can any "solution" to this charter
item tolerate and still deserve to be called a solution?

    Greg Bailey     |  ATHENA Programming, Inc  |  503-295-7703  |
  ----------------  |  310 SW 4th Ave  Ste 530  |  fax 295-6935  |
  greg@minerva.com  |  Portland, OR  97204  US  |




> -----Original Message-----
> From: owner-ipsec@lists.tislabs.com
> [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Srinivasa Addepalli
> Sent: Fri 01 Mar 02 11:14
> To: Hallam-Baker, Phillip
> Cc: ipsec mailling list
> Subject: Re: Towards closure on NAT traversal.
> 
> 
> 
> AH can't be passed through NAT.  ESP works, but some intelligence
> is needed in the NAT/firewall boxes. If NAT friendly IPSEC/IKE is 
> required (which solves many problems), then both IKE and ESP have to be
> fixed or encapsulated within UDP packet.
> 
> NAT traversal, outside IPSEC/IKE seems to be a good solution to me.
> This does not require changes to already deployed IPSEC and NAT solutions.
> L2TP is one such solution. This can encapsulate packets in UDP which
> is understood by NAT. But, it adds lot of baggage to the packets and
> since NAT discovery is not part of L2TP, it encapsulates all packets.
> Other solution is to come out with some standard which is lightweight
> and does NAT discovery and encapsulates packets of required services
> (based on local configuration and NAT discovery results).
> 
> Thanks
> Srini