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

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

	 
	 >> HTTPS through a NAT, for example, is perfectly reasonable
	 
	 >HTTPS doesn't embed things like ports into the communications stream,
	 >so it can be NATed. SSL is the security layer HTTPS uses, but SSL !=
	 >HTTPS -- other protocols over SSL will not behave so nicely.
	 
	 
	 But my example of HTTPS through NAT is a case where you both both NAT
	 features and end-to-end security.  My point was to demonstrate the
	 independance of IP addr/ports from end-end security.

As always, there are tradeoffs.  Every form of encryption has its own
advantages and disadvantages.  Some forms play more nicely with NAT
than do others; by the same token, they have their own peculiar limitations.

IPsec operates below the transport layer.  This means that it protects
the entire transport packet -- for TCP or UDP -- including the header.
As noted by others, that provides protection against SYN flooding,
spurious RST packets, and a host of other ills.  Among the interesting
fields protected is the transport checksum -- which, in the case of
TCP and UDP, would include the pseudo-header.  And that, of course, has
the source and destination IP addresses.  This is a fundamental
incompatibility with NAT -- you can't diddle *any* IPsec-protected
packet, even if the protocol in question doesn't contain embedded IP
addresses.

On the other hand, IPsec generally requires kernel-level changes; an
application can't implement it for itself on most systems.  That's why
Netscape introduced SSL -- it was something that an application could
do, without modification to the operating system.

SSL operates above TCP.  This means that you can pass it through a NAT
gateway for protocols that don't use embedded IP addresses.  The Web
is usually clean, though some sites are foolish enough to use IP addresses
in URLs or cookies.

A more serious drawback to SSL is that in general, one does have to touch
every application.  While one could conceivably tinker with the libraries
-- say, a funky DLL on Windows, or a shared library on UNIX systems --
most protocols don't know how to decline SSL if they weren't designed
for such things.  Even if they were -- telnet comes to mind -- the
negotiation is inherently protocol-specific; a hack that might work
for SMTP (say, via ELHO) wouldn't work for NNTP.  Web browsers don't
even try negotiating at this level, for the obvious reason that it's
too messy -- they just use a different port number.  And there's no
fallback (at least, not in any browser I've seen) -- if no one is hope
on port 443, the connection attempt simply fails.

Which is better, IPsec or SSL?  I don't know; which is better, blue or
red?  Oranges or apples?  Compact or tasty?  As always, it's wise to
look at our middle name:  "engineering".  There are tradeoffs; what's
best for one situation is not best for another.  In general, I like
IPsec better, especially because it's so well-suited to gateway-to-gateway
or host-to-gateway encryption.  That let's a site make its own tradeoffs
between economy of deployment and granularity of protection.  But
there's no doubt that SSL (and ssh, which operates at a similar layer)
are protecting far more sessions (and probably bytes) in today's Internet,
because they're easier to deploy.  Furthermore, they provide even
finer-grained protection -- to the level of the individual user.  IPsec
is supposed to be able to do that, but it's relatively hard to do.

I strongly doubt that there are any magic NAT fixes that can make it
play more nicely with IPsec.  The purpose of NAT is to make unpleasant
(but hopefully useful) changes to packets; however, a design goal of IPsec
was to prevent any changes, pleasant or not, useful or not.  If you
must have both, you'll probably have to do both on the same box, in
an integrated fashion.  That may mean the end systems, of course.

(As a teaser, that's not a ridiculous statement.  In fact, there are
characteristics of IPsec that make co-resident NAT work quite nicely.
In my copious free time, I'm trying draft an RFC entitled "IPsec, EIDs,
and HostNAT", where EID is "endpoint identifier".)