require special processing of TCP and UDP traffic on the host.
Bringing up SCTP connections to another host with one or more NA(P)Ts
between them may present special challenges. SCTP supports multi-
homing. If more than one IP address is used, these addresses are
transported as part of the SCTP packet during the association setup
(in the INIT and INIT-ACK chunks). If only single homed SCTP end-
points are used, [RFC2960] section 3.3.2.1 states:
Note that not using any IP address parameters in the INIT and
INIT-ACK is an alternative to make an association more likely
to work across a NAT box.
This implies that IP addresses should not be put into the SCTP packet
unless necessary. If NATs are present and IP addresses are included,
then association setup will fail. Recently [AddIP] has been proposed
which allows the modification of the IP address once an association
is established. The modification messages have also IP addresses in
the SCTP packet, and so will be adversely affected by NATs.
Firewall Compatibility
Since firewalls are widely deployed, a NAT-IPsec compatibility
solution MUST enable a firewall administrator to create simple,
static access rule(s) to permit or deny IKE and IPsec NA(P)T
traversal traffic. This implies, for example, that dynamic
allocation of IKE or IPsec destination ports is to be avoided.
Scaling
An IPsec-NAT compatibility solution should be capable of being
deployed within an installation consisting of thousands of
telecommuters. In this situation, it is not possible to assume
that only a single host is communicating with a given destination
at a time. Thus, an IPsec-NAT compatibility solution MUST address
the issue of overlapping SPD entries and de-multiplexing of
incoming packets.
Mode Support
At a minimum, an IPsec-NAT compatibility solution MUST support
traversal of the IKE and IPsec modes required for support within
[RFC2409] and [RFC2401]. For example, an IPsec gateway MUST
support ESP tunnel mode NA(P)T traversal, and an IPsec host MUST
support IPsec transport mode NA(P)T traversal. The purpose of AH
is to protect immutable fields within the IP header (including
addresses), and NA(P)T translates addresses, invalidating the AH
integrity check. As a result, NA(P)T and AH are fundamentally
incompatible and there is no requirement that an IPsec-NAT
compatibility solution support AH transport or tunnel mode.
Backward Compatibility and Interoperability
An IPsec-NAT compatibility solution MUST be interoperable with
existing IKE/IPsec implementations, so that they can communicate
where no NA(P)T is present. This implies that an IPsec-NAT
compatibility solution MUST be backwards-compatible with IPsec as
defined in [RFC2401] and IKE as defined in [RFC2409]. In
addition, it SHOULD be able to detect the presence of a NA(P)T, so
that NA(P)T traversal support is only used when necessary. This
implies that it MUST be possible to determine that an existing IKE
implementation does not support NA(P)T traversal, so that a
standard IKE conversation can occur, as described in [RFC2407],
[RFC2408], and [RFC2409]. Note that while this implies initiation
of IKE to port 500, there is no requirement for a specific source
port, so that UDP source port 500 may or may not be used.
Security
An IPsec-NAT compatibility solution MUST NOT introduce additional
IKE or IPsec security vulnerabilities. For example, an acceptable
solution must demonstrate that it introduces no new denial of
service or spoofing vulnerabilities. IKE MUST be allowed to re-
key in a bi-directional manner as described in [RFC2408].
4. Existing Solutions
4.1. IPsec Tunnel Mode
In a limited set of circumstances, it is possible for an IPsec tunnel
mode implementation, such as that described in [DHCP], to traverse
NA(P)T successfully. However, the requirements for successful
traversal are sufficiently limited so that a more general solution is
needed:
1) IPsec ESP. IPsec ESP tunnels do not cover the outer IP header
within the message integrity check, and so will not suffer
Authentication Data invalidation due to address translation.
IPsec tunnels also need not be concerned about checksum
invalidation.
2) No address validation. Most current IPsec tunnel mode
implementations do not perform source address validation so that
incompatibilities between IKE identifiers and source addresses
will not be detected. This introduces security vulnerabilities as
described in Section 5.
3) "Any to Any" SPD entries. IPsec tunnel mode clients can negotiate
"any to any" SPDs, which are not invalidated by address
translation. This effectively precludes use of SPDs for the
filtering of allowed tunnel traffic.
4) Single client operation. With only a single client behind a NAT,
there is no risk of overlapping SPDs. Since the NAT will not need
to arbitrate between competing clients, there is also no risk of
re-key mis-translation, or improper incoming SPI or cookie
de-multiplexing.
5) No fragmentation. When certificate authentication is used, IKE
fragmentation can be encountered. This can occur when certificate
chains are used, or even when exchanging a single certificate if
the key size, or the size of other certificate fields (such as the
distinguished name and other extensions), is large enough.
However, when pre-shared keys are used for authentication,
fragmentation is less likely.
6) Active sessions. Most VPN sessions typically maintain ongoing
traffic flow during their lifetime so that UDP port mappings are
less likely be removed due to inactivity.
4.2. RSIP
RSIP, described in [RSIP] and [RSIPFrame], includes mechanisms for
IPsec traversal, as described in [RSIPsec]. By enabling host-NA(P)T
communication, RSIP addresses issues of IPsec SPI de-multiplexing, as
well as SPD overlap. It is thus suitable for use in enterprises, as
well as home networking scenarios. By enabling hosts behind a NAT to
share the external IP address of the NA(P)T (the RSIP gateway), this
approach is compatible with protocols including embedded IP
addresses.
By tunneling IKE and IPsec packets, RSIP avoids changes to the IKE
and IPsec protocols, although major changes are required to host 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).
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.
RSIP does not satisfy the deployment requirements for an IPsec-NAT
compatibility solution because an RSIP-enabled host requires a
corresponding RSIP-enabled gateway in order to establish an IPsec SA
with another host. Since RSIP requires changes only to clients and
routers and not to servers, it is less difficult to deploy than IPv6.
However, for vendors, implementation of RSIP requires a substantial
fraction of the resources required for IPv6 support. Thus, RSIP
solves a "transitional" problem on a long-term time scale, which is
not useful.
4.3. 6to4
6to4, as described in [RFC3056] can form the basis for an IPsec-NAT
traversal solution. In this approach, the NAT provides IPv6 hosts
with an IPv6 prefix derived from the NAT external IPv4 address, and
encapsulates IPv6 packets in IPv4 for transmission to other 6to4
hosts or 6to4 relays. This enables an IPv6 host using IPsec to
communicate freely to other hosts within the IPv6 or 6to4 clouds.
While 6to4 is an elegant and robust solution where a single NA(P)T
separates a client and VPN gateway, it is not universally applicable.
Since 6to4 requires the assignment of a routable IPv4 address to the
NA(P)T in order to allow formation of an IPv6 prefix, it is not
usable where multiple NA(P)Ts exist between the client and VPN
gateway. For example, an NA(P)T with a private address on its
external interface cannot be used by clients behind it to obtain an
IPv6 prefix via 6to4.
While 6to4 requires little additional support from hosts that already
support IPv6, it does require changes to NATs, which need to be
upgraded to support 6to4. As a result, 6to4 may not be suitable for
deployment in the short term.
5. Security Considerations
By definition, IPsec-NAT compatibility requires that hosts and
routers implementing IPsec be capable of securely processing packets
whose IP headers are not cryptographically protected. A number of
issues arise from this that are worth discussing.
Since IPsec AH cannot pass through a NAT, one of the side effects of
providing an IPsec-NAT compatibility solution may be for IPsec ESP
with null encryption to be used in place of AH where a NAT exists
between the source and destination. However, it should be noted that
ESP with null encryption does not provide the same security
properties as AH. For example, there are security risks relating to
IPv6 source routing that are precluded by AH, but not by ESP with
null encryption.
In addition, since ESP with any transform does not protect against
source address spoofing, some sort of source IP address sanity
checking needs to be performed. The importance of the anti-spoofing
check is not widely understood. There is normally an anti-spoofing
check on the Source IP Address as part of IPsec_{esp,ah}_input().
This ensures that the packet originates from the same address as that
claimed within the original IKE Phase 1 and Phase 2 security
associations. When a receiving host is behind a NAT, this check
might not strictly be meaningful for unicast sessions, whereas in the
Global Internet this check is important for tunnel-mode unicast
sessions to prevent a spoofing attack described in [AuthSource],
which can occur when access controls on the receiver depend upon the
source IP address of verified ESP packets after decapsulation.
IPsec-NAT compatibility schemes should provide anti-spoofing
protection if it uses source addresses for access controls.
Let us consider two hosts, A and C, both behind (different) NATs, who
negotiate IPsec tunnel mode SAs to router B. Hosts A and C may have
different privileges; for example, host A might belong to an employee
trusted to access much of the corporate Intranet, while C might be a
contractor only authorized to access a specific web site.
If host C sends a tunnel mode packet spoofing A’s IP address as the
source, it is important that this packet not be accorded the
privileges corresponding to A. If authentication and integrity
checking is performed, but no anti-spoofing check (verifying that the
originating IP address corresponds to the SPI) then host C may be
allowed to reach parts of the network that are off limits. As a
result, an IPsec-NAT compatibility scheme MUST provide some degree of
anti-spoofing protection.
6. References
6.1. Normative References
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791,
September 1981.
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC
793, September 1981.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2401] Atkinson, R. and S. Kent, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[RFC2402] Kent, S. and R. Atkinson, "IP Authentication Header",
RFC 2402, November 1998.
[RFC2406] Kent,S. and R. Atkinson, "IP Encapsulating Security
Payload (ESP)", RFC 2406, November 1998.
[RFC2407] Piper, D., "The Internet IP Security Domain of
Interpretation for ISAKMP", RFC 2407, November 1998.
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange
(IKE)", RFC 2409, November 1998.
[RFC2663] Srisuresh, P. and M. Holdredge, "IP Network Address
Translator (NAT) Terminology and Considerations", RFC
2663, August 1999.
[RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network
Address Translator (Traditional NAT)", RFC 3022, January
2001.
6.2. Informative References
[RFC2408] Maughan, D., Schertler, M., Schneider, M. and J. Turner,
"Internet Security Association and Key Management
Protocol (ISAKMP)", RFC 2408, November 1998.
[RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C.,
Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M.,
Zhang, M. and V. Paxson, "Stream Control Transmission
Protocol", RFC 2960, October 2000.
[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains
via IPv4 Clouds", RFC 3056, February 2001.
[RFC3193] Patel, B., Aboba, B., Dixon, W., Zorn, G. and S. Booth,
"Securing L2TP using IPsec", RFC 3193, November 2001.
[RFC3309] Stone, J., Stewart, R. and D. Otis, "Stream Control
Transmission Protocol (SCTP) Checksum Change", RFC 3309,
September 2002.
[RSIPFrame] Borella, M., Lo, J., Grabelsky, D. and G. Montenegro,
"Realm Specific IP: Framework", RFC 3102, October 2001.
[RSIP] Borella, M., Grabelsky, D., Lo, J. and K. Taniguchi,
"Realm Specific IP: Protocol Specification", RFC 3103,
October 2001.
[RSIPsec] Montenegro, G. and M. Borella, "RSIP Support for End-
to-End IPsec", RFC 3104, October 2001.
[DHCP] Patel, B., Aboba, B., Kelly, S. and V. Gupta, "Dynamic
Host Configuration Protocol (DHCPv4) Configuration of
IPsec Tunnel Mode", RFC 3456, January 2003.
[AuthSource] Kent, S., "Authenticated Source Addresses", IPsec WG
Archive (ftp://ftp.ans.net/pub/archive/IPsec), Message-
Id: <v02130517ad121773c8ed@[128.89.0.110]>, January 5,
1996.
[AddIP] Stewart, R., et al., "Stream Control Transmission
Protocol (SCTP) Dynamic Address Reconfiguration", Work
in Progress.
7. Acknowledgments
Thanks to Steve Bellovin of AT&T Research, Michael Tuexen of Siemens,
Peter Ford of Microsoft, Ran Atkinson of Extreme Networks, and Daniel
Senie for useful discussions of this problem space.
8. Authors’ Addresses
Bernard Aboba
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
Phone: +1 425 706 6605
Fax: +1 425 936 7329
EMail: bernarda@microsoft.com
William Dixon
V6 Security, Inc.
601 Union Square, Suite #4200-300
Seattle, WA 98101
EMail: ietf-wd@v6security.com
9. Full Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78 and
except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM 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.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights 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; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.