Professional Documents
Culture Documents
Aboba
Request for Comments: 3715 W. Dixon
Category: Informational Microsoft
March 2004
Copyright Notice
Abstract
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language. . . . . . . . . . . . . . . . . . 2
2. Known Incompatibilities between NA(P)T and IPsec . . . . . . . 3
2.1. Intrinsic NA(P)T Issues. . . . . . . . . . . . . . . . . 3
2.2. NA(P)T Implementation Weaknesses . . . . . . . . . . . . 7
2.3. Helper Incompatibilities . . . . . . . . . . . . . . . . 8
3. Requirements for IPsec-NAT Compatibility . . . . . . . . . . . 8
4. Existing Solutions . . . . . . . . . . . . . . . . . . . . . . 12
4.1. IPsec Tunnel Mode. . . . . . . . . . . . . . . . . . . . 12
4.2. RSIP . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.3. 6to4 . . . . . . . . . . . . . . . . . . . . . . . . . . 13
5. Security Considerations. . . . . . . . . . . . . . . . . . . . 14
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
6.1. Normative References . . . . . . . . . . . . . . . . . . 15
6.2. Informative References . . . . . . . . . . . . . . . . . 16
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
8. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 17
9 . Full Copyright Statement . . . . . . . . . . . . . . . . . . . 18
1. Introduction
In this document, the key words "MAY", "MUST, "MUST NOT", "optional",
"recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as
described in [RFC2119].
Note that this is not an incompatibility with IPsec per se, but
rather with the way it is typically implemented. With both AH and
ESP, the receiving host specifies the SPI to use for a given SA, a
choice which is significant only to the receiver. At present, the
combination of Destination IP, SPI, and Security Protocol (AH,
ESP) uniquely identifies a Security Association. Also, SPI values
in the range 1-255 are reserved to IANA and may be used in the
future. This means that, when negotiating with the same external
host or gateway, the internal hosts behind the same NAPT can
select the same SPI value, such that one host inbound SA is
(SPI=470, Internal Dest IP=192.168.0.4)
and a different host inbound SA is
(SPI=470, Internal Dest IP=192.168.0.5).
The receiving NAPT will not be able to determine which internal
host an inbound IPsec packet with SPI=470 should be forwarded to.
k) NAT mapping timeouts. NA(P)Ts vary in the time for which a UDP
mapping will be maintained in the absence of traffic. Thus, even
where IKE packets can be correctly translated, the translation
state may be removed prematurely.
Deployment
Protocol Compatibility
Security
Telecommuter Scenario
The client may have a routable address and the VPN gateway may be
behind at least one NA(P)T, or alternatively, both the client and
the VPN gateway may be behind one or more NA(P)Ts. Telecommuters
may use the same private IP address, each behind their own NA(P)T,
or many telecommuters may reside on a private network behind the
same NA(P)T, each with their own unique private address,
connecting to the same VPN gateway. Since IKE uses UDP port 500
as the destination, it is not necessary to enable multiple VPN
gateways operating behind the same external IP address.
Gateway-to-Gateway Scenario
End-to-End Scenario
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
Scaling
Mode Support
Security
4. Existing Solutions
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.
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.2. RSIP
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).
4.3. 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
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.
6. References
[RFC3193] Patel, B., Aboba, B., Dixon, W., Zorn, G. and S. Booth,
"Securing L2TP using IPsec", RFC 3193, November 2001.
7. Acknowledgments
8. Authors' Addresses
Bernard Aboba
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
William Dixon
V6 Security, Inc.
601 Union Square, Suite #4200-300
Seattle, WA 98101
EMail: ietf-wd@v6security.com
Intellectual Property
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