RE: Thomas Narten's DISCUSS vote

[Stephen Waters <[e-mail]>]

NAT is a many-flavoured thing.  I can think of a couple of useful NAT
setups while using IPSEC:

1) Hosts are armed with IPSEC and use transport mode to chat.  When a
security gateway gets in the way, this transport mode ESP packet will
need to be re-ESPed with tunnel mode.  If a remote site is using a
private numbering scheme (private in that it is not part of the
companies Intranet address space),  NAT will need to be applied to the
IP header on the host's packet before it is tunneled:

Host 10.1.1.1------ SG1-----Internet----SG2-------Home LAN 17.0.0.0

In this example, SG1 will have allocated (dynamically or statically) and
address from the 17.0.0.0 numbering plan.  This Intranet address will
then need to be imposed on any packets carrying 10.1.1.1 that SG1
forwards.

Once the NAT function has been performed on the 'LAN' side of SG1,  the
packet will need to be tunneled (EPS tunnel) over the Internet.  If you
are using a new-style VPN carrier with whom you share your address
space, the tunnel may not be needed (depending of whether you wish to
enforce encryption or not).

In this configuration, it is a MUST to NOT use AH on the hosts. There is
nothing stopping the SGs using AH to protect the tunneled packet's outer
IP header.

2) As for 1), but hosts have no IPSEC

This is the same as 1) as far as the SGs are concerned:  map the host's
address and tunnel using any transport you fancy.

 
These two examples use NAT to translate between Intranet addresses and
local/private adresses.  NAT can of course be used to translate between
Internet addresses and Intranet/local addresses, but IPSEC is unlikely
to be involved.

NAT could be quite useful at a SOHO site.  If you model a SOHO site as a
remote-access client (say using dial-in ISDN to connect to the
Internet), then you can use the same dynamic address assignment
techniques as for a remote laptop and allow the SOHO router to NAT the
address for the various systems on the SOHO LAN.

Probably all discussed to death elsewhere,  but It may help - provided
I'm right :)

Cheers, Steve. 






-----Original Message-----
From:	Steve Bellovin [SMTP:[e-mail]]
Sent:	Tuesday, May 26, 1998 3:34 PM
To:	Theodore Y. Ts'o
Cc:	[e-mail]
Subject:	Re: Thomas Narten's DISCUSS vote 

	 The text is valid; ESP includes integrity protection, although
	 ESP doesn't cover the IP header.  In the new IPSEC scheme, it
	 is extremely unlikely that someone will use both ESP and AH.
	 ESP-NULL provides no data confidentiality, but it does provide
	 integrity over the packet data (but not of the IP headers),
	 thus allowing NAT boxes to muck with the IP headers.

	 Whether or not this is a horrible abstraction violation is
	 besides the point; if the goal is to allow NAT boxes to work,
	 while still providing data integrity services for the packet
	 contents, ESP NULL is one way of accomplishing that goal.

The objection is valid -- because of the transport checksum, which
is protected by ESP-NULL's integrity algorithm, the IP addresses
can't be tinkered with in a useful fashion.  (Well, I suppose that
a NAT box could change the source port number to offset the changes
to the addresses -- but I don't really regard that as useful...)

ESP-NULL has a lot of advantages -- but enabling NAT isn't one of them.
(Well, I suppose that one could argue that defeating NAT is itself
a nice feature, but that's out of bounds for this WG...)