view Side-By-Side changes

Date: Mon, 08 Apr 2002 22:24:06 GMT
Server: Apache/1.3.20 (Unix)
Last-Modified: Fri, 26 May 2000 09:40:00 GMT
ETag: "2e7c93-3772-392e4670"
Accept-Ranges: bytes
Content-Length: 14194
Connection: close
Content-Type: text/plain


NATNetwork Working Group                                      Bernard Aboba
INTERNET-DRAFT                                                 Microsoft
Category: Informational
<draft-aboba-nat-ipsec-01.txt>
26 May
<draft-aboba-nat-ipsec-02.txt>
11 July 2000

                             NAT and IPSEC


1.  Status of this Memo

This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026.

Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups.  Note that other groups
may also distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time.  It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as "work in progress."

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.

2.  Copyright Notice

Copyright (C) The Internet Society (2000).  All Rights Reserved.

3.  Abstract

Perhaps the most common use of IPSEC is in providing virtual private
networking capabilities. One very popular use of VPNs is to provide
tele-commuter access to the corporate Intranet.  With NATs being
increasingly deployed in home gateways, NAT-IPSEC incompatibilities have
become a major barrier to deployment of IPSEC in one of its principal
uses. This draft discusses the describes known incompatibilities between NAT and IPSEC
and suggests how IPSEC might be made more NAT friendly. discusses alternatives for addressing them.

4.  Requirements language

In this document, the key words "MAY", "MUST,  "MUST  NOT",  "optional",
"recommended",  "SHOULD",  and  "SHOULD  NOT",  are to be interpreted as
described in [2].



Aboba                         Informational                     [Page 1]

INTERNET-DRAFT               NAT and IPSEC                   26 May                  11 July 2000


5.  Introduction

Perhaps the most common use of IPSEC [6] is in providing virtual private
networking capabilities. One very popular use of VPNs is to provide
tele-commuter access to the corporate Intranet.  With NATs [8]-[9] being
increasingly deployed in home gateways, NAT-IPSEC incompatibilities have
become a major barrier to deployment of IPSEC in one of its principal
uses. This draft discusses the describes known incompatibilities between NAT and IPSEC
and suggests how IPSEC might be made more NAT friendly. discusses alternatives for addressing them.

6.  NAT/IPSEC  Known incompatibilities between NAT and IPSEC

The known incompatibilities between NAT and IPSEC are as follows: numerous, ranging from
the obvious to the subtle. Some of the known incompatibilities include:

a) Incompatibility between IPSEC AH [3] will not go through the NAT, because and NAT. Since the AH header
   incorporates the IP source and destination fields addresses in the
   authentication hash.

b)
   keyed message integrity check, NAT or reverse NAT devices making changes
   to address fields will invalidate the message integrity check.
   Since IPSEC ESP [4] does not incorporate the IP source and
   destination
   fields addresses in its authentication hash. However, there is an
   implicit keyed message integrity check,
   this issue does not arise for ESP.

b) Incompatibility between checksums and NAT. TCP/UDP/SCTP
   checksums have a dependency on the IP source and destination
   addresses within
   TCP/UDP/SCTP checksums which cover through inclusion of the "pseudo-header" in the "pseudo-header."
   Therefore
   calculation. As a result, where checksums are calculated and
   checked on receipt, they will be invalidated by passage through
   a NAT or reverse NAT device.

   As a result, IPSEC ESP will only go pass unimpeded through the a NAT if
   TCP/UDP/SCTP protocols are not involved (as in IPSEC tunnel
   mode or IPSEC/GRE), UDP checksums are turned off (TCP
   checksums are required), or if TCP/UDP/SCTP checksums are
   ignored by the receiving party. not calculated (as is
   possible with UDP). As described in [13], TCP checksum
   calculation and verification is required.

c) Incompatibility between IKE address identifiers and NAT.
   Where IP addresses are used as identifiers in IKE MM [7]
   or QM, IKE will only go through the NAT if modification of the parties do not
   check or use IP source or destination
   addresses by NATs or reverse NATs will result in IKE MM a
   mismatch between the identifiers (several
   current implementations don't do this) AND if and the addresses in addition
   they don't check or use the
   IP addresses header. As described in [7], IKE QM identifiers
   (most implementations DO are
   required to discard such packets.

   While use addresses of userIDs or FQDNs as identifiers is possible
   within IKE, there are usage scenarios (e.g. SPD entries
   describing subnets) that cannot be accomodated this way.




Aboba                         Informational                     [Page 2]

INTERNET-DRAFT               NAT and check them). IPSEC                  11 July 2000


d) Because of Incompatibility between fixed IKE re-keying behavior, destination ports and NAPT.
   Where multiple hosts behind the NAPT initiate
   IKE SAs to the same responder, a mechanism is needed
   to allow the NAPT to demultiplex the incoming IKE
   packets. This is typically accomplished by translating
   the IKE UDP source port. While it is necessary for
   implementations permissible to float their
   the IKE UDP source port in order port, this can result in unpredictable
   behavior during rekeys. Unless the floated source port is
   used as the destination port for the rekey, the NAT may
   not be able to enable NATs send the re-key packets to de-multiplex incoming the correct
   destination.

   Alternatives to source port de-multiplexing, such
   as IKE cookie de-multiplexing, also result in problems with
   rekeying, since re-keys which may typically will not use the same
   cookies as the earlier traffic. Otherwise
   it is possible for

e) Incompatibilities between overlapping SPD entries and NAT.
   Where hosts behind a NAT negotiate overlapping SPD entries
   with the re-key to same destination in IKE QM, packets may be sent to
   down the wrong SA
   by the NAT.

e) In order to enable an IPSEC implementation SA. This occurs because to send traffic
   down the correct
   sender, the IPSEC SA, it is necessary for those SAs appear to be differentiated in some way. In practice this implies
   negotiation of non-overlapping SPD entries. For example, if
   two clients behind a NAT were to negotiate equivalent, since they
   exist between the same SPD
   entries, then there would be no way to decide which SA



Aboba                         Informational                     [Page 2]

INTERNET-DRAFT               NAT endpoints and IPSEC                   26 May 2000


   to use can be used to protect a given packet. pass
   the same traffic.

f) Incompatibilities between IPSEC SPI selection and NAT.
   Since IPSEC ESP traffic is encrypted and thus opaque to the NAT,
   the NAT must use elements of the IP and IPSEC header to
   demultiplex incoming IPSEC traffic. The combination of the
   source IP address, security protocol (AH/ESP) and IPSEC SPI
   is typically used for this purpose. As noted in [6]:

   "The receiver-orientation of the Security Association implies that,
   in the case of unicast traffic, the destination system will normally
   select the SPI value.  By having the destination select

   However, since the SPI
   value, outgoing and incoming SPIs are chosen
   independently, there is no potential way for manually configured Security
   Associations the NAT to conflict with automatically configured (e.g., via a
   key management protocol) Security Associations or for Security
   Associations from multiple sources determine
   what incoming SPI corresponds to conflict with each other."

   This implies that if the source is located behind a NAT, but the what destination is not, then the combination of host
   merely by inspecting outgoing traffic. Thus, were two
   hosts behind the destination address,
   security protocol and SPI will be unique. However, if NAT to attempt to bring up IPSEC SAs to
   the same destination is located behind a NAT, then simultaneously, it is possible
   (though unlikely) that
   the same SPI value may be chosen by
   two or more destinations behind the NAT. In this case the NAT could will send the incoming IPSEC packets to the
   wrong destination.

g) Incompatibilities between embedded IP addresses and NAT.
   Since the payload is integrity protected, any IP addresses
   enclosed within the payload IPSEC packets will not be translatable by the a
   NAT. There are many protocols Protocols that utilize embedded IP
   addresses, including addresses include
   FTP, IRC, SNMP, LDAP, H.323
   SIP, H.323, SIP and many games.





Aboba                         Informational                     [Page 3]

INTERNET-DRAFT               NAT and IPSEC                  11 July 2000


7.  Recommendations

It is recommended that the  Alternatives

The following actions be taken to improve alternatives have been proposed for addressing the
NAT-friendliness of
incompatibilities between NAT and IPSEC:

a) Since IPSEC ESP null provides much

   UDP encapsulation
   RSIP
   Changes to IKE

We discuss the same security
   services as pros and cons of each alternative in turn.

7.1.  UDP encapsulation

In this approach, IKE and IPSEC AH, but without explicitly covering packets are encapsulated in UDP prior to
being sent. The receiver then discards the outer IP header in its authentication hash, it is
   recommended and UDP
encapsulation, thus disregarding any changes that may have been made by
intervening NAPTs.

This approach has several advantages. It does not require any changes to
either the IKE or IPSEC ESP null be used instead of AH.

b) Since transport mode protocols, and is compatible with all IPSEC traffic
protocols (AH/ESP) and modes (transport/tunnel), although some changes
to IKE implementations are required.  Since it relies only on NAPT
support for UDP, this approach is integrity protected likely to work with the vast majority
of existing NAT implementations.

In terms of disadvantages, this proposal requires changes to existing
hosts, and authenticated adds 28 octets of additional overhead.  By adding a NAT
compatibility mode to IKE/IPSEC, the total time to negotiate an IPSEC SA
may be increased significantly.  For example, when an IKE initiator
fails to receive a response, it will typically need to try again using strong cryptography, there is little
UDP encapsulation, since the lack of response may have been due to gained by having the receiver check TCP/UDP/SCTP checksums
   on traffic protected by
presence of intervening NATs.

7.2.  RSIP

RSIP, described in [10]-[11], includes mechanisms for IPSEC transport mode SAs. traversal,
as described in [12]. By enabling host-gateway communication, RSIP
addresses issues of IPSEC SPI de-multiplexing as well as SPD overlap. It
is
   therefore recommended that checksum verification be made
   optional thus suitable for use in this case.




Aboba                         Informational                     [Page 3]

INTERNET-DRAFT               NAT enterprise as well as home networking
scenarios.

By tunneling IKE and IPSEC                   26 May 2000


c) Since proper de-multiplexing of packets, RSIP avoids changes to the IKE and
IPSEc protocols, although major changes are required to IKE and IPSEC
implementations to retrofit them for RSIP-compatibility. It is thus
compatible with all existing protocols (AH/ESP) and modes (transport and
tunnel).





Aboba                         Informational                     [Page 4]

INTERNET-DRAFT               NAT and IPSEC                  11 July 2000


In order to handle de-multiplexing of IKE re-keys, RSIP requires
floating of the IKE source port, as well as re-keying to the floated
port. As a result, interoperability with existing IPSEC implementations
is not assured.

Disadvantages of RSIP include that it requires major changes to both
host implementations as well as to gateways. As a result, an RSIP-
enabled host requires a corresponding RSIP-enabled gateway in order to
establish an IPSEC SA with another host.

7.3.  IKE and checksum processing changes

In this approach, a number of changes are made in IKE usage and checksum
processing. The advantage of this approach is that it does not add
additional overhead as does the encapsulation approach. In addition,
minimal changes are required to the IKE or IPSEC protocols.

However, this approach offers only limited compatibility with IPSEC
tunnel mode (only enabling negotiation of "me" and "any" SPD entries),
and may only be used to allow transport of IPSEC ESP through a NAT, not
AH.

This approach also requires changes to host implementations as well as
modest changes to existing NATs.  As a result, it can be expected to
work with a substantial fraction of existing NATs, although by no means
all of them.

Another disadvantage of this approach is that it does not address issues
of SPD conflict or incoming IPSEC SPI de-multiplexing. As a result,
unless it is combined with a host-gateway communication protocol such as
RSIP, this approach cannot be applied to enterprise scenarios where
multiple hosts behind the NAT may establish IPSEC SAs to the same
destination.

In this approach, the following changes are required:

a) Use of IPSEC ESP null instead of AH.
   Since IPSEC ESP null provides integrity protection and
   authentication services without covering the IP header
   in the message integrity check, IPSEC ESP null is
   used in preference to IPSEC AH.

b) Optional checksum verification for IPSEC transport mode SAs.
   Since transport mode IPSEC traffic is integrity protected
   and authenticated using strong cryptography, modifications
   to the packet can be detected prior to checking UDP/TCP/SCTP
   checksums. Thus, checksum verification only provides assurance
   against errors made in internal processing. In order to



Aboba                         Informational                     [Page 5]

INTERNET-DRAFT               NAT and IPSEC                  11 July 2000


   remove the  incompatibility between checksum processing and
   NAT, checksum verification is made optional on packets
   covered by IPSEC transport mode SAs.

c) Floating IKE source ports.
   To enable NATs to easily de-multiplex IKE traffic, it is
   more convenient to float IKE source ports than it is to
   de-multiplex using cookies. Assuming source ports are floated,
   to enable de-multiplexing of IKE re-keys, the initiator will need
   to send the re-key packets to the IKE re-keys is dependent on
   initiators floating their source port used in the
   original negotiation. Use of floated IKE source ports, it ports is recommended
   that already
   allowed within IKE implementations float their source ports. [7].

d) It is recommended that Use of userIDs and FQDNs as IKE MM and QM identifiers.
   In order to avoid use of IP addresses not be used as identifiers
   in IKE MM or QM, where this can be avoided. and QM identifiers,
   userIDs and FQDNs are used instead. Where user authentication
   is desired, an ID type of ID_USER_FQDN can be used, as described in
   [5]. Where machine authentication is desired, an ID type of ID_FQDN
   can be used. In practice, use of IP addresses as identifiers in IKE
   provides little security value, since assuming either case it is necessary to verify that the integrity
   of the IKE packets is verified, it can be assumed
   proposed identity matches that enclosed in the
   correspondent has possession of certificate.

8.  Security considerations

Since the negotiated keys. Note that
   restricting identifiers to ID_USER_FQDN or ID_FQDN would prevent
   use UDP encapsulation approach requires the additional work of subnet or address range identifiers, which
decapsulation prior to IPSEC processing, it may be required
   for gateway result in increased
susceptibility to gateway communications. Thus this denial of service attacks. However, since no changes
are made in IKE or IPSEC usage, no other vulnerabilities are introduced.

The RSIP approach is not
   universally applicable.

e) In tele-commuter scenarios, introduces major changes to both hosts and gateways so
that it is expected likely that both IPSEC
   transport mode (for L2TP/IPSEC as well as other UDP and TCP)
   and IPSEC tunnel mode additional bugs will be commonly used. In these
   cases, introduced as a result of
the SPD entries typically only need to protect traffic
   between scale of the two endpoints. In such circumstances, ID_USER_FQDN
   or ID_FQDN identifiers should be used within required changes.  However, the SPD negotiation
   in IKE QM. Since restricting identifiers to ID_USER_FQDN or ID_FQDN
   would prevent use of subnet or address range identifiers, this
   approach may RSIP does not be applicable in gateway introduce
changes to gateway communications.

f) If IPSEC and IKE processing other than the above techniques use of floating
source ports, so that no new protocol vulnerabilities are not feasible, alternative approaches
   should be considered. One currently popular technique is to
   encapsulate IP/IPSEC within a TCP or UDP payload, created.

Changes in IKE usage and then remove checksum processing introduce changes on both
the outermost IP host and transport header at gateways so that new implementation bugs may be introduced
as a result. Of the receiver, thus
   reconstructing usage changes, the original packet without modification. While this
   method does introduce extra overhead, it does not require any
   modifications to IPSEC/IKE or checksum verification procedures.

8.  Security considerations

It most significant from a security
point of view is not believed that the changes described above will impact IPSEC
security adversely. change in usage of IKE MM and QM identifiers.
There is no security value to TCP/UDP/SCTP checksums, so not checking
them does not decrease security. Similarly, use of IPSEC ESP null
instead of AH does not introduce any security vulnerabilities.

Where certificate-based authentication is possible, it is believed that
the use of ID_USER_FQDN or ID_FQDN in IKE MM instead of addresses will
not introduce additional security vulnerabilities, as long as the
presented identity is verified to correspond to that in the certificate.





Aboba                         Informational                     [Page 6]

INTERNET-DRAFT               NAT and IPSEC                  11 July 2000


Use of ID_FQDN or ID_USER_FQDN identifiers in IKE QM does raise raises the issue as
to what traffic will be accepted in the IPSEC SA. Since packets will be
integrity protected, it is possible to verify that the source is in
posession of the negotiated keys. Thus Thus, for transport mode SAs, it
does not appear strictly necessary may
be sufficient to filter by address, require that traffic originate only from a single IP
address (such as as the address used in the IKE QM negotiation), and to
verify



Aboba                         Informational                     [Page 4]

INTERNET-DRAFT               NAT and IPSEC                   26 May 2000 packet integrity.

However,

Things are somewhat trickier for IPSEC tunnel mode, where restricting
identifiers to ID_USER_FQDN or ID_FQDN would prevent use of subnet or
address range identifiers, which may be required for gateway to gateway
communications.  Thus this approach is not universally applicable.

However, in client to gateway communications with IPSEC tunnel mode SAs, if
these restrictions may be more workable.  If subnet or IP address range
identifiers are not used, it is reasonable to assume that only traffic
from a single IP address is permitted inside the tunnel. A reasonable
assumption would be that this IP address corresponds to the source
address used when setting up the IKE QM SA.

9.  Acknowledgments

Thanks to Steve Bellovin of AT&T Research, William Dixon of Microsoft,
and Daniel Senie for useful discussions of this problem space.

10.  References

[1]  Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G., and
     Palter, B., "Layer Two Tunneling Protocol L2TP", RFC 2661, August
     1999.

[2]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
     Levels", BCP 14, RFC 2119, March 1997.

[3]  Kent,S., Atkinson, R., "IP Authentication Header", RFC 2402,
     November 1998.

[4]  Kent,S., Atkinson, R., "IP Encapsulating Security Payload (ESP)",
     RFC 2406, November 1998.

[5]  Piper, D., "The Internet IP Security Domain of Interpretation of
     ISAKMP", RFC 2407, November 1998.

[6]  Atkinson, R., Kent, S., "Security Architecture for the Internet
     Protocol", RFC 2401, November 1998.

[7]  Harkins, D., Carrel, D., "The Internet Key Exchange (IKE)", RFC
     2409, November 1998.



Aboba                         Informational                     [Page 7]

INTERNET-DRAFT               NAT and IPSEC                  11 July 2000


[8]  Srisuresh, P.,  and Egevang, K., "Traditional IP Network Address
     Translator (Traditional NAT)", Internet draft (work in progress),
     draft-ietf-nat-traditional-03.txt, September 1999.

[9]  Srisuresh, P. and Holdredge, M., "IP Network Address Translator
     (NAT) Terminology and Considerations," RFC 2663, August 1999.

[10] Borella, M., Lo, J., Grabelsky, D., Montenegro, G., "Realm Specific
     IP: A Framework", Internet draft (work in progress), draft-ietf-
     nat-rsip-framework-04.txt, March 2000.

[11] Borella, M., Grabelsky, D., Lo, J., Taniguchi, K., "Realm Specific
     IP: Protocol Specification", Internet draft (work in progress),
     draft-ietf-nat-rsip-protocol-05.txt, January 2000.

[12] Montenegro, G., Borella, M., "RSIP Support for End-to-End IPSEC",
     Internet draft (work in progress), draft-ietf-nat-rsip-
     ipsec-03.txt, March 2000.

[13] Information Sciences Institute, "Transmission Control Protocol",
     RFC 793, September 1981.

11.  Authors' Addresses

Bernard Aboba
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052

Phone: 425-936-6605
EMail: bernarda@microsoft.com





Aboba                         Informational                     [Page 5]

INTERNET-DRAFT               NAT and IPSEC                   26 May 2000

12.  Intellectual Property Statement

The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to pertain
to the implementation or use of the technology described in this
document or the extent to which any license under such rights might or
might not be available; neither does it represent that it has made any
effort to identify any such rights.  Information on the IETF's
procedures with respect to rights in standards-track and standards-
related documentation can be found in BCP-11.  Copies of claims of
rights made available for publication and any assurances of licenses to
be made available, or the result of an attempt made to obtain a general
license or permission for the use of such proprietary rights by
implementors or users of this specification can be obtained from the
IETF Secretariat.




Aboba                         Informational                     [Page 8]

INTERNET-DRAFT               NAT and IPSEC                  11 July 2000


The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary rights
which may cover technology that may be required to practice this
standard.  Please address the information to the IETF Executive
Director.


13.  Full Copyright Statement

Copyright (C) The Internet Society (2000).  All Rights Reserved.

This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it or
assist in its implementation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are included
on all such copies and derivative works.  However, this document itself
may not be modified in any way, such as by removing the copyright notice
or references to the Internet Society or other Internet organizations,
except as needed for the purpose of developing Internet standards in
which case the procedures for copyrights defined in the Internet
Standards process must be followed, or as required to translate it into
languages other than English.  The limited permissions granted above are
perpetual and will not be revoked by the Internet Society or its
successors or assigns.  This document and the information contained
herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE
INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."





Aboba                         Informational                     [Page 6]

INTERNET-DRAFT               NAT and IPSEC                   26 May 2000


14.  Expiration Date

This memo is filed as <draft-aboba-ipsec-nat-00.txt>, <draft-aboba-ipsec-nat-02.txt>, and expires
January
February 1, 2001.















Aboba                         Informational                     [Page 7] 9]

----