summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc3948.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc3948.txt')
-rw-r--r--doc/rfc/rfc3948.txt843
1 files changed, 843 insertions, 0 deletions
diff --git a/doc/rfc/rfc3948.txt b/doc/rfc/rfc3948.txt
new file mode 100644
index 0000000..b232751
--- /dev/null
+++ b/doc/rfc/rfc3948.txt
@@ -0,0 +1,843 @@
+
+
+
+
+
+
+Network Working Group A. Huttunen
+Request for Comments: 3948 F-Secure Corporation
+Category: Standards Track B. Swander
+ Microsoft
+ V. Volpe
+ Cisco Systems
+ L. DiBurro
+ Nortel Networks
+ M. Stenberg
+ January 2005
+
+
+ UDP Encapsulation of IPsec ESP Packets
+
+Status of this Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2005).
+
+Abstract
+
+ This protocol specification defines methods to encapsulate and
+ decapsulate IP Encapsulating Security Payload (ESP) packets inside
+ UDP packets for traversing Network Address Translators. ESP
+ encapsulation, as defined in this document, can be used in both IPv4
+ and IPv6 scenarios. Whenever negotiated, encapsulation is used with
+ Internet Key Exchange (IKE).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Huttunen, et al. Standards Track [Page 1]
+
+RFC 3948 UDP Encapsulation of IPsec ESP Packets January 2005
+
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
+ 2. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 2.1. UDP-Encapsulated ESP Header Format . . . . . . . . . . . 3
+ 2.2. IKE Header Format for Port 4500 . . . . . . . . . . . . 4
+ 2.3. NAT-Keepalive Packet Format . . . . . . . . . . . . . . 4
+ 3. Encapsulation and Decapsulation Procedures . . . . . . . . . . 5
+ 3.1. Auxiliary Procedures . . . . . . . . . . . . . . . . . . 5
+ 3.1.1. Tunnel Mode Decapsulation NAT Procedure . . . . 5
+ 3.1.2. Transport Mode Decapsulation NAT Procedure . . . 5
+ 3.2. Transport Mode ESP Encapsulation . . . . . . . . . . . . 6
+ 3.3. Transport Mode ESP Decapsulation . . . . . . . . . . . . 6
+ 3.4. Tunnel Mode ESP Encapsulation . . . . . . . . . . . . . 7
+ 3.5. Tunnel Mode ESP Decapsulation . . . . . . . . . . . . . 7
+ 4. NAT Keepalive Procedure . . . . . . . . . . . . . . . . . . . 7
+ 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8
+ 5.1. Tunnel Mode Conflict . . . . . . . . . . . . . . . . . . 8
+ 5.2. Transport Mode Conflict . . . . . . . . . . . . . . . . 9
+ 6. IAB Considerations . . . . . . . . . . . . . . . . . . . . . . 10
+ 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
+ 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
+ 8.1. Normative References . . . . . . . . . . . . . . . . . . 11
+ 8.2. Informative References . . . . . . . . . . . . . . . . . 11
+ A. Clarification of Potential NAT Multiple Client Solutions . . . 12
+ Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 14
+ Full Copyright Statement . . . . . . . . . . . . . . . . . . . 15
+
+1. Introduction
+
+ This protocol specification defines methods to encapsulate and
+ decapsulate ESP packets inside UDP packets for traversing Network
+ Address Translators (NATs) (see [RFC3715], section 2.2, case i). The
+ UDP port numbers are the same as those used by IKE traffic, as
+ defined in [RFC3947].
+
+ The sharing of the port numbers for both IKE and UDP encapsulated ESP
+ traffic was selected because it offers better scaling (only one NAT
+ mapping in the NAT; no need to send separate IKE keepalives), easier
+ configuration (only one port to be configured in firewalls), and
+ easier implementation.
+
+ A client's needs should determine whether transport mode or tunnel
+ mode is to be supported (see [RFC3715], Section 3, "Telecommuter
+ scenario"). L2TP/IPsec clients MUST support the modes as defined in
+ [RFC3193]. IPsec tunnel mode clients MUST support tunnel mode.
+
+
+
+
+
+Huttunen, et al. Standards Track [Page 2]
+
+RFC 3948 UDP Encapsulation of IPsec ESP Packets January 2005
+
+
+ An IKE implementation supporting this protocol specification MUST NOT
+ use the ESP SPI field zero for ESP packets. This ensures that IKE
+ packets and ESP packets can be distinguished from each other.
+
+ As defined in this document, UDP encapsulation of ESP packets is
+ written in terms of IPv4 headers. There is no technical reason why
+ an IPv6 header could not be used as the outer header and/or as the
+ inner header.
+
+ Because the protection of the outer IP addresses in IPsec AH is
+ inherently incompatible with NAT, the IPsec AH was left out of the
+ scope of this protocol specification. This protocol also assumes
+ that IKE (IKEv1 [RFC2401] or IKEv2 [IKEv2]) is used to negotiate the
+ IPsec SAs. Manual keying is not supported.
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in [RFC2119].
+
+2. Packet Formats
+
+2.1. UDP-Encapsulated ESP Header Format
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Source Port | Destination Port |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Length | Checksum |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | ESP header [RFC2406] |
+ ~ ~
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ The UDP header is a standard [RFC0768] header, where
+
+ o the Source Port and Destination Port MUST be the same as that used
+ by IKE traffic,
+ o the IPv4 UDP Checksum SHOULD be transmitted as a zero value, and
+ o receivers MUST NOT depend on the UDP checksum being a zero value.
+
+ The SPI field in the ESP header MUST NOT be a zero value.
+
+
+
+
+
+
+
+
+Huttunen, et al. Standards Track [Page 3]
+
+RFC 3948 UDP Encapsulation of IPsec ESP Packets January 2005
+
+
+2.2. IKE Header Format for Port 4500
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Source Port | Destination Port |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Length | Checksum |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Non-ESP Marker |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | IKE header [RFC2409] |
+ ~ ~
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ The UDP header is a standard [RFC0768] header and is used as defined
+ in [RFC3947]. This document does not set any new requirements for
+ the checksum handling of an IKE packet.
+
+ A Non-ESP Marker is 4 zero-valued bytes aligning with the SPI field
+ of an ESP packet.
+
+2.3. NAT-Keepalive Packet Format
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Source Port | Destination Port |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Length | Checksum |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | 0xFF |
+ +-+-+-+-+-+-+-+-+
+
+ The UDP header is a standard [RFC0768] header, where
+
+ o the Source Port and Destination Port MUST be the same as used by
+ UDP-ESP encapsulation of Section 2.1,
+ o the IPv4 UDP Checksum SHOULD be transmitted as a zero value, and
+ o receivers MUST NOT depend upon the UDP checksum being a zero
+ value.
+
+ The sender MUST use a one-octet-long payload with the value 0xFF.
+ The receiver SHOULD ignore a received NAT-keepalive packet.
+
+
+
+
+
+
+Huttunen, et al. Standards Track [Page 4]
+
+RFC 3948 UDP Encapsulation of IPsec ESP Packets January 2005
+
+
+3. Encapsulation and Decapsulation Procedures
+
+3.1. Auxiliary Procedures
+
+3.1.1. Tunnel Mode Decapsulation NAT Procedure
+
+ When a tunnel mode has been used to transmit packets (see [RFC3715],
+ section 3, criteria "Mode support" and "Telecommuter scenario"), the
+ inner IP header can contain addresses that are not suitable for the
+ current network. This procedure defines how these addresses are to
+ be converted to suitable addresses for the current network.
+
+ Depending on local policy, one of the following MUST be done:
+
+ 1. If a valid source IP address space has been defined in the policy
+ for the encapsulated packets from the peer, check that the source
+ IP address of the inner packet is valid according to the policy.
+ 2. If an address has been assigned for the remote peer, check that
+ the source IP address used in the inner packet is the assigned IP
+ address.
+ 3. NAT is performed for the packet, making it suitable for transport
+ in the local network.
+
+3.1.2. Transport Mode Decapsulation NAT Procedure
+
+ When a transport mode has been used to transmit packets, contained
+ TCP or UDP headers will have incorrect checksums due to the change of
+ parts of the IP header during transit. This procedure defines how to
+ fix these checksums (see [RFC3715], section 2.1, case b).
+
+ Depending on local policy, one of the following MUST be done:
+
+ 1. If the protocol header after the ESP header is a TCP/UDP header
+ and the peer's real source and destination IP address have been
+ received according to [RFC3947], incrementally recompute the
+ TCP/UDP checksum:
+
+ * Subtract the IP source address in the received packet from the
+ checksum.
+ * Add the real IP source address received via IKE to the
+ checksum (obtained from the NAT-OA)
+ * Subtract the IP destination address in the received packet
+ from the checksum.
+ * Add the real IP destination address received via IKE to the
+ checksum (obtained from the NAT-OA).
+ Note: If the received and real address are the same for a given
+ address (e.g., say the source address), the operations cancel and
+ don't need to be performed.
+
+
+
+Huttunen, et al. Standards Track [Page 5]
+
+RFC 3948 UDP Encapsulation of IPsec ESP Packets January 2005
+
+
+ 2. If the protocol header after the ESP header is a TCP/UDP header,
+ recompute the checksum field in the TCP/UDP header.
+
+ 3. If the protocol header after the ESP header is a UDP header, set
+ the checksum field to zero in the UDP header. If the protocol
+ after the ESP header is a TCP header, and if there is an option
+ to flag to the stack that the TCP checksum does not need to be
+ computed, then that flag MAY be used. This SHOULD only be done
+ for transport mode, and if the packet is integrity protected.
+ Tunnel mode TCP checksums MUST be verified. (This is not a
+ violation to the spirit of section 4.2.2.7 in [RFC1122] because a
+ checksum is being generated by the sender and verified by the
+ receiver. That checksum is the integrity over the packet
+ performed by IPsec.)
+
+ In addition an implementation MAY fix any contained protocols that
+ have been broken by NAT (see [RFC3715], section 2.1, case g).
+
+3.2. Transport Mode ESP Encapsulation
+
+ BEFORE APPLYING ESP/UDP
+ ----------------------------
+ IPv4 |orig IP hdr | | |
+ |(any options)| TCP | Data |
+ ----------------------------
+
+ AFTER APPLYING ESP/UDP
+ -------------------------------------------------------
+ IPv4 |orig IP hdr | UDP | ESP | | | ESP | ESP|
+ |(any options)| Hdr | Hdr | TCP | Data | Trailer |Auth|
+ -------------------------------------------------------
+ |<----- encrypted ---->|
+ |<------ authenticated ----->|
+
+ 1. Ordinary ESP encapsulation procedure is used.
+ 2. A properly formatted UDP header is inserted where shown.
+ 3. The Total Length, Protocol, and Header Checksum (for IPv4) fields
+ in the IP header are edited to match the resulting IP packet.
+
+3.3. Transport Mode ESP Decapsulation
+
+ 1. The UDP header is removed from the packet.
+ 2. The Total Length, Protocol, and Header Checksum (for IPv4) fields
+ in the new IP header are edited to match the resulting IP packet.
+ 3. Ordinary ESP decapsulation procedure is used.
+ 4. Transport mode decapsulation NAT procedure is used.
+
+
+
+
+
+Huttunen, et al. Standards Track [Page 6]
+
+RFC 3948 UDP Encapsulation of IPsec ESP Packets January 2005
+
+
+3.4. Tunnel Mode ESP Encapsulation
+
+ BEFORE APPLYING ESP/UDP
+ ----------------------------
+ IPv4 |orig IP hdr | | |
+ |(any options)| TCP | Data |
+ ----------------------------
+
+ AFTER APPLYING ESP/UDP
+ --------------------------------------------------------------
+ IPv4 |new h.| UDP | ESP |orig IP hdr | | | ESP | ESP|
+ |(opts)| Hdr | Hdr |(any options)| TCP | Data | Trailer |Auth|
+ --------------------------------------------------------------
+ |<------------ encrypted ----------->|
+ |<------------- authenticated ------------>|
+
+ 1. Ordinary ESP encapsulation procedure is used.
+ 2. A properly formatted UDP header is inserted where shown.
+ 3. The Total Length, Protocol, and Header Checksum (for IPv4) fields
+ in the new IP header are edited to match the resulting IP packet.
+
+3.5. Tunnel Mode ESP Decapsulation
+
+ 1. The UDP header is removed from the packet.
+ 2. The Total Length, Protocol, and Header Checksum (for IPv4) fields
+ in the new IP header are edited to match the resulting IP packet.
+ 3. Ordinary ESP decapsulation procedure is used.
+ 4. Tunnel mode decapsulation NAT procedure is used.
+
+4. NAT Keepalive Procedure
+
+ The sole purpose of sending NAT-keepalive packets is to keep NAT
+ mappings alive for the duration of a connection between the peers
+ (see [RFC3715], Section 2.2, case j). Reception of NAT-keepalive
+ packets MUST NOT be used to detect whether a connection is live.
+
+ A peer MAY send a NAT-keepalive packet if one or more phase I or
+ phase II SAs exist between the peers, or if such an SA has existed at
+ most N minutes earlier. N is a locally configurable parameter with a
+ default value of 5 minutes.
+
+ A peer SHOULD send a NAT-keepalive packet if a need for it is
+ detected according to [RFC3947] and if no other packet to the peer
+ has been sent in M seconds. M is a locally configurable parameter
+ with a default value of 20 seconds.
+
+
+
+
+
+
+Huttunen, et al. Standards Track [Page 7]
+
+RFC 3948 UDP Encapsulation of IPsec ESP Packets January 2005
+
+
+5. Security Considerations
+
+5.1. Tunnel Mode Conflict
+
+ Implementors are warned that it is possible for remote peers to
+ negotiate entries that overlap in an SGW (security gateway), an issue
+ affecting tunnel mode (see [RFC3715], section 2.1, case e).
+
+ +----+ \ /
+ | |-------------|----\
+ +----+ / \ \
+ Ari's NAT 1 \
+ Laptop \
+ 10.1.2.3 \
+ +----+ \ / \ +----+ +----+
+ | |-------------|----------+------| |----------| |
+ +----+ / \ +----+ +----+
+ Bob's NAT 2 SGW Suzy's
+ Laptop Server
+ 10.1.2.3
+
+ Because SGW will now see two possible SAs that lead to 10.1.2.3, it
+ can become confused about where to send packets coming from Suzy's
+ server. Implementors MUST devise ways of preventing this from
+ occurring.
+
+ It is RECOMMENDED that SGW either assign locally unique IP addresses
+ to Ari's and Bob's laptop (by using a protocol such as DHCP over
+ IPsec) or use NAT to change Ari's and Bob's laptop source IP
+ addresses to these locally unique addresses before sending packets
+ forward to Suzy's server. This covers the "Scaling" criteria of
+ section 3 in [RFC3715].
+
+ Please see Appendix A.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Huttunen, et al. Standards Track [Page 8]
+
+RFC 3948 UDP Encapsulation of IPsec ESP Packets January 2005
+
+
+5.2. Transport Mode Conflict
+
+ Another similar issue may occur in transport mode, with 2 clients,
+ Ari and Bob, behind the same NAT talking securely to the same server
+ (see [RFC3715], Section 2.1, case e).
+
+ Cliff wants to talk in the clear to the same server.
+
+ +----+
+ | |
+ +----+ \
+ Ari's \
+ Laptop \
+ 10.1.2.3 \
+ +----+ \ / +----+
+ | |-----+-----------------| |
+ +----+ / \ +----+
+ Bob's NAT Server
+ Laptop /
+ 10.1.2.4 /
+ /
+ +----+ /
+ | |/
+ +----+
+ Cliff's
+ Laptop
+ 10.1.2.5
+
+ Now, transport SAs on the server will look like this:
+
+ To Ari: Server to NAT, <traffic desc1>, UDP encap <4500, Y>
+
+ To Bob: Server to NAT, <traffic desc2>, UDP encap <4500, Z>
+
+ Cliff's traffic is in the clear, so there is no SA.
+
+ <traffic desc> is the protocol and port information. The UDP encap
+ ports are the ports used in UDP-encapsulated ESP format of section
+ 2.1. Y,Z are the dynamic ports assigned by the NAT during the IKE
+ negotiation. So IKE traffic from Ari's laptop goes out on UDP
+ <4500,4500>. It reaches the server as UDP <Y,4500>, where Y is the
+ dynamically assigned port.
+
+ If the <traffic desc1> overlaps <traffic desc2>, then simple filter
+ lookups may not be sufficient to determine which SA has to be used to
+ send traffic. Implementations MUST handle this situation, either by
+ disallowing conflicting connections, or by other means.
+
+
+
+
+Huttunen, et al. Standards Track [Page 9]
+
+RFC 3948 UDP Encapsulation of IPsec ESP Packets January 2005
+
+
+ Assume now that Cliff wants to connect to the server in the clear.
+ This is going to be difficult to configure, as the server already has
+ a policy (from Server to the NAT's external address) for securing
+ <traffic desc>. For totally non-overlapping traffic descriptions,
+ this is possible.
+
+ Sample server policy could be as follows:
+
+ To Ari: Server to NAT, All UDP, secure
+
+ To Bob: Server to NAT, All TCP, secure
+
+ To Cliff: Server to NAT, ALL ICMP, clear text
+
+ Note that this policy also lets Ari and Bob send cleartext ICMP to
+ the server.
+
+ The server sees all clients behind the NAT as the same IP address, so
+ setting up different policies for the same traffic descriptor is in
+ principle impossible.
+
+ A problematic example of configuration on the server is as follows:
+
+ Server to NAT, TCP, secure (for Ari and Bob)
+
+ Server to NAT, TCP, clear (for Cliff)
+
+ The server cannot enforce his policy, as it is possible that
+ misbehaving Bob sends traffic in the clear. This is
+ indistinguishable from when Cliff sends traffic in the clear. So it
+ is impossible to guarantee security from some clients behind a NAT,
+ while allowing clear text from different clients behind the SAME NAT.
+ If the server's security policy allows this, however, it can do
+ best-effort security: If the client from behind the NAT initiates
+ security, his connection will be secured. If he sends in the clear,
+ the server will still accept that clear text.
+
+ For security guarantees, the above problematic scenario MUST NOT be
+ allowed on servers. For best effort security, this scenario MAY be
+ used.
+
+ Please see Appendix A.
+
+6. IAB Considerations
+
+ The UNSAF [RFC3424] questions are addressed by the IPsec-NAT
+ compatibility requirements document [RFC3715].
+
+
+
+
+Huttunen, et al. Standards Track [Page 10]
+
+RFC 3948 UDP Encapsulation of IPsec ESP Packets January 2005
+
+
+7. Acknowledgments
+
+ Thanks to Tero Kivinen and William Dixon, who contributed actively to
+ this document.
+
+ Thanks to Joern Sierwald, Tamir Zegman, Tatu Ylonen, and Santeri
+ Paavolainen, who contributed to the early documents about NAT
+ traversal.
+
+8. References
+
+8.1. Normative References
+
+ [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
+ August 1980.
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the
+ Internet Protocol", RFC 2401, November 1998.
+
+ [RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security
+ Payload (ESP)", RFC 2406, November 1998.
+
+ [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange
+ (IKE)", RFC 2409, November 1998.
+
+ [RFC3947] Kivinen, T., "Negotiation of NAT-Traversal in the IKE",
+ RFC 3947, January 2005.
+
+8.2. Informative References
+
+ [RFC1122] Braden, R., "Requirements for Internet Hosts -
+ Communication Layers", STD 3, RFC 1122, October 1989.
+
+ [RFC3193] Patel, B., Aboba, B., Dixon, W., Zorn, G., and S. Booth,
+ "Securing L2TP using IPsec", RFC 3193, November 2001.
+
+ [RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral
+ Self-Address Fixing (UNSAF) Across Network Address
+ Translation", RFC 3424, November 2002.
+
+ [RFC3715] Aboba, B. and W. Dixon, "IPsec-Network Address Translation
+ (NAT) Compatibility Requirements", RFC 3715, March 2004.
+
+ [IKEv2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
+ Work in Progress, October 2004.
+
+
+
+Huttunen, et al. Standards Track [Page 11]
+
+RFC 3948 UDP Encapsulation of IPsec ESP Packets January 2005
+
+
+Appendix A. Clarification of Potential NAT Multiple Client Solutions
+
+ This appendix provides clarification about potential solutions to the
+ problem of multiple clients behind the same NAT simultaneously
+ connecting to the same destination IP address.
+
+ Sections 5.1 and 5.2 say that you MUST avoid this problem. As this
+ is not a matter of wire protocol, but a matter local implementation,
+ the mechanisms do not belong in the protocol specification itself.
+ They are instead listed in this appendix.
+
+ Choosing an option will likely depend on the scenarios for which one
+ uses/supports IPsec NAT-T. This list is not meant to be exhaustive,
+ so other solutions may exist. We first describe the generic choices
+ that solve the problem for all upper-layer protocols.
+
+ Generic choices for ESP transport mode:
+
+ Tr1) Implement a built-in NAT (network address translation) above
+ IPsec decapsulation.
+
+ Tr2) Implement a built-in NAPT (network address port translation)
+ above IPsec decapsulation.
+
+ Tr3) An initiator may decide not to request transport mode once NAT
+ is detected and may instead request a tunnel-mode SA. This may be a
+ retry after transport mode is denied by the responder, or the
+ initiator may choose to propose a tunnel SA initially. This is no
+ more difficult than knowing whether to propose transport mode or
+ tunnel mode without NAT. If for some reason the responder prefers or
+ requires tunnel mode for NAT traversal, it must reject the quick mode
+ SA proposal for transport mode.
+
+ Generic choices for ESP tunnel mode:
+
+ Tn1) Same as Tr1.
+
+ Tn2) Same as Tr2.
+
+ Tn3) This option is possible if an initiator can be assigned an
+ address through its tunnel SA, with the responder using DHCP. The
+ initiator may initially request an internal address via the
+ DHCP-IPsec method, regardless of whether it knows it is behind a NAT.
+ It may re-initiate an IKE quick mode negotiation for DHCP tunnel SA
+ after the responder fails the quick mode SA transport mode proposal.
+ This happens either when a NAT-OA payload is sent or because it
+
+
+
+
+
+Huttunen, et al. Standards Track [Page 12]
+
+RFC 3948 UDP Encapsulation of IPsec ESP Packets January 2005
+
+
+ discovers from NAT-D that the initiator is behind a NAT and its local
+ configuration/policy will only accept a NAT connection when being
+ assigned an address through DHCP-IPsec.
+
+ There are also implementation choices that offer limited
+ interoperability. Implementors should specify which applications or
+ protocols should work if these options are selected. Note that
+ neither Tr4 nor Tn4, as described below, are expected to work with
+ TCP traffic.
+
+ Limited interoperability choices for ESP transport mode:
+
+ Tr4) Implement upper-layer protocol awareness of the inbound and
+ outbound IPsec SA so that it doesn't use the source IP and the source
+ port as the session identifier (e.g., an L2TP session ID mapped to
+ the IPsec SA pair that doesn't use the UDP source port or the source
+ IP address for peer uniqueness).
+
+ Tr5) Implement application integration with IKE initiation so that it
+ can rebind to a different source port if the IKE quick mode SA
+ proposal is rejected by the responder; then it can repropose the new
+ QM selector.
+
+ Limited interoperability choices for ESP tunnel mode:
+
+ Tn4) Same as Tr4.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Huttunen, et al. Standards Track [Page 13]
+
+RFC 3948 UDP Encapsulation of IPsec ESP Packets January 2005
+
+
+Authors' Addresses
+
+ Ari Huttunen
+ F-Secure Corporation
+ Tammasaarenkatu 7
+ HELSINKI FIN-00181
+ FI
+
+ EMail: Ari.Huttunen@F-Secure.com
+
+
+ Brian Swander
+ Microsoft
+ One Microsoft Way
+ Redmond, WA 98052
+ US
+
+ EMail: briansw@microsoft.com
+
+
+ Victor Volpe
+ Cisco Systems
+ 124 Grove Street
+ Suite 205
+ Franklin, MA 02038
+ US
+
+ EMail: vvolpe@cisco.com
+
+
+ Larry DiBurro
+ Nortel Networks
+ 80 Central Street
+ Boxborough, MA 01719
+ US
+
+ EMail: ldiburro@nortelnetworks.com
+
+
+ Markus Stenberg
+ FI
+
+ EMail: markus.stenberg@iki.fi
+
+
+
+
+
+
+
+
+Huttunen, et al. Standards Track [Page 14]
+
+RFC 3948 UDP Encapsulation of IPsec ESP Packets January 2005
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (2005).
+
+ 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 IETF's procedures with respect to rights in IETF 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.
+
+
+
+
+
+
+
+Huttunen, et al. Standards Track [Page 15]
+