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

From: Vinod Valloppillil <[email-masked]>
Date: Wed, 4 Feb 1998 15:26:10 -0800

that's a pretty large overstatement, IMHO.  

fundamentals of IPSEC/NAT aside, it doesn't seem theoretically impossible to
separate IP addressing from end-to-end payload security.

HTTPS through a NAT, for example, is perfectly reasonable and I believe
works almost all the time (only breakage to be found is the handful of sites
out there that embed IP addrs in cookies)

> -----Original Message-----
> From:	Perry E. Metzger [SMTP:[email-masked]]
> Sent:	Wednesday, February 04, 1998 1:00 PM
> To:	Dan Nessett
> Cc:	[email-masked]; [email-masked]
> Subject:	(NAT) Re: Interactions between IPSEC and NAT 
> 
> 
> Dan Nessett writes:
> > Anyone thought about this so that they can provide us with a nice clean
> > answer :-) ?
> 
> Yes. If you want security, you can't use NAT, because by definition
> the thing NAT is trying to do (peek in and/or alter your packets) is
> what security is designed to prevent. Protocols like SSL have exactly
> the same issue, btw. Any protocol that protects the contents of your
> data will have the same issue.
> 
> This is not fixable -- any "fixes" someone could propose to this would
> be so horrible as to make the entire point of security moot.
> 
> Perry
> -
> To unsubscribe, email [email-masked]' with
> 'unsubscribe nat' in the body of the message.
-
To unsubscribe, email [email-masked]' with
'unsubscribe nat' in the body of the message.

---

From: Steve Bellovin <[email-masked]>
Date: Wed, 04 Feb 1998 22:02:33 -0500

>> 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".)
-
To unsubscribe, email [email-masked]' with
'unsubscribe nat' in the body of the message.

---

From: "Alexei V. Vopilov" <[email-masked]>
Date: Thu, 5 Feb 1998 22:51:12 +0300

-----Original Message-----
From: Ben Rogers <[email-masked]>
To: [email-masked] <[email-masked]>
Cc: Alex Alten <[email-masked]>; [email-masked] <[email-masked]>;
Dan Nessett <[email-masked]>; [email-masked] <[email-masked]>;
[email-masked] <[email-masked]>
Date: 5 февраля 1998 г. 20:51
Subject: Re: (NAT) Re: Interactions between IPSEC and NAT

[ . . .]

:Which makes it sound as if they're planning to be handling such issues.
:I know that one of the important points mentioned in the Washington was
:that if NAT were going to fly as a WG it would need to work around the
:security interactions by modifications to the way we do NAT instead of
:modifications to the way we do security.
:
:ben

If this is a 'hint', it makes NAT people to just give up with
IPsec since they have nothing to do after an IPsec transform is done.
If IPsec wg ignores the NAT one, that actually would affect the customer
base for both technologies.

--Alexei

-