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

Re: Towards closure on NAT traversal.



Greg Bailey wrote:
> 
> 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.

Doesn't passive mode FTP solve that problem?
 
> 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?

How large a subset of the problem can a reasonably simple solution
handle? Even if all it handled was web browsing, it might still be
worth doing.

Yes, there are things like some of the stranger H323 or gaming
protocols that might be quite problematic. I cann see, though,
that such exceptions matter a lot, let alone that their existence
would invalidate a proposal that provided useful services.