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

IPSEC Security Gateways & NAT

We've come up against a number of situations where the network service
provider has used NAT and the customer wants to add IP security by adding
Security Gateways between their networks and the service provider's access
points.

RFC2401 says that a Security Gateway must use tunnel mode unless it is
acting as a host (eg management).  The negates the service provider's use of
NAT by preventing it from translating client addresses - which in some cases
overlap across across multiple private networks.

Some vendors offer non-standard encryption modes - eg transport or
proprietary - that do pass the IP (and even TCP/UDP) headers through in
clear too.  This exposes the client IP address for NAT but means that the
encryption end-points probably won't agree on the selectors for the security
association - as they will see different addresses for the same client.

Even assuming that the management issues associated with agreeing SAs
(possibly with dynamic NAT) can be fixed, there appears to be a deeper
issue:  Some protocols, most notably FTP, pass IP socket addresses at the
application level.  These need to be translated by Application Level
Gateways (ALGs).  However, once IP traffic has been enrypted, this
information cannot be available to the ALG.

This appears to imply that NAT, in general, must be performed before
encryption.  This is at odds with the models that a number of service
providers are trying to apply.  Are there any solutions to these problems?
Or any papers detailing the sort of problems that occur when mixing NAT with
IPSEC.

Thanks,
Chris


-----------------------------------------------------------------------------------------------------------------
The information contained in this message is confidential and is intended 
for the addressee(s) only.  If you have received this message in error or 
there are any problems please notify the originator immediately.  The 
unauthorized use, disclosure, copying or alteration of this message is 
strictly forbidden. Baltimore Technologies plc will not be liable for direct, 
special, indirect or consequential damages arising from alteration of the 
contents of this message by a third party or as a result of any virus being 
passed on.

In addition, certain Marketing collateral may be added from time to time to 
promote Baltimore Technologies products, services, Global e-Security or 
appearance at trade shows and conferences.
 
This footnote confirms that this email message has been swept by 
Baltimore MIMEsweeper for Content Security threats, including
computer viruses.
Follow-Ups: