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

RE: Towards closure on NAT traversal.



> From:  Sandy Harris  Sent: Sat 02 Mar 02 14:42
> 
> 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?

Not if the FTP server doesn't implement PASV (it is not required).  This
may seem to be niggling but if people are going to make fundamental
changes such as NAT which change the requirements for interoperability
it would be nice to at least publish those requirements in an RFC.

More relevantly, not if the FTP server is itself behind a NAT box.
Don't laugh, I have customers who are inflicting this sort of thing
on themselves.  Since PASV elicits a reply with IP address and port,
the same problems exist with respect to ESP auth and/or encryption
when traversing the server's NAT box ... unless I am missing something
embarassingly obvious.



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

I figure that FTP is a pretty darn basic entitlement, and is also
one that benefits greatly from the availability of IPSec.  As long
as NAT boxes are successfully pitched to people with no IPv4 address
space problems as "security" devices, it seems ironic that their
presence tends to interfere with actual end to end security.


Is there a well defined mandatory form of ID for an IKE agent that
is not based on its IP address and will universally interoperate?
I do not see it in the current set of RFC's.  If IKEv2 is supposed
to be aware of the existence of NATs, I certainly hope a non IP based
interoperable unique ID is required as part of it.


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