HIP Working Group V. Schmitt Internet-Draft NEC Expires: August 31, 2006 A. Pathak IIT Kanpur M. Komu HIIT L. Eggert M. Stiemerling NEC February 27, 2006 HIP Extensions for the Traversal of Network Address Translators draft-schmitt-hip-nat-traversal-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. This document may not be modified, and derivative works of it may not be created, except to publish it as an RFC and to translate it into languages other than English. 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. This Internet-Draft will expire on August 31, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract Schmitt, et al. Expires August 31, 2006 [Page 1] Internet-Draft HIP Extensions for NAT Traversal February 2006 This document specifies extensions to Host Identity Protocol (HIP) to support traversal of Network Address Translator (NAT) middleboxes. The traversal mechanism tunnels HIP control and data traffic over UDP and enables HIP initiators behind NATs to contact HIP responders in the global Internet. Future revisions of this document will describe mechanisms to contact HIP responders behind NATs. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. HIP Across NATs . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Packet Formats . . . . . . . . . . . . . . . . . . . . . . 4 2.1.1. Control Traffic . . . . . . . . . . . . . . . . . . . 5 2.1.2. Control Channel Keep-Alives . . . . . . . . . . . . . 5 2.1.3. Data Traffic . . . . . . . . . . . . . . . . . . . . . 6 2.1.4. Data Channel Keep-Alives . . . . . . . . . . . . . . . 7 2.2. NAT Traversal of HIP Control Traffic . . . . . . . . . . . 7 2.3. NAT Traversal of HIP Data Traffic . . . . . . . . . . . . 10 2.3.1. UDP Encapsulation of IPsec BEET-Mode ESP . . . . . . . 11 2.3.2. UDP Decapsulation of IPsec BEET-Mode ESP . . . . . . . 12 2.3.3. IPsec BEET-Mode Security Associations . . . . . . . . 13 2.4. NAT Keep-Alives . . . . . . . . . . . . . . . . . . . . . 16 2.5. HIP Mobility . . . . . . . . . . . . . . . . . . . . . . . 17 2.6. HIP Multihoming . . . . . . . . . . . . . . . . . . . . . 18 2.7. Firewall Traversal . . . . . . . . . . . . . . . . . . . . 18 3. Security Considerations . . . . . . . . . . . . . . . . . . . 19 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 6.1. Normative References . . . . . . . . . . . . . . . . . . . 20 6.2. Informative References . . . . . . . . . . . . . . . . . . 21 Appendix A. Document Revision History . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 Intellectual Property and Copyright Statements . . . . . . . . . . 23 Schmitt, et al. Expires August 31, 2006 [Page 2] Internet-Draft HIP Extensions for NAT Traversal February 2006 1. Introduction The Host Identity Protocol (HIP) describes a new communication mechanism for Internet hosts [I-D.ietf-hip-arch]. It introduces a new namespace and protocol layer between the network and transport layers that decouples the identifier and locator roles that the IP address fulfill in the current Internet architecture. The HIP protocol [I-D.ietf-hip-base] cannot operate across Network Address Translator (NAT) middleboxes, as described in [I-D.irtf-hiprg-nat]. Several different flavors of NATs exist [RFC2663]. This document describes HIP extensions for the traversal of both Network Address Translator (NAT) and Network Address and Port Translator (NAPT) middleboxes. It generally uses the term NAT to refer to both types of middleboxes, unless it needs to distinguish between the two types. Three basic cases exist for NAT traversal. In the first case, only the initiator of a HIP base exchange is located behind a NAT. In the second case, only the responder of a HIP base exchange is located behind a NAT. The respective peer host is assumed to be in the global Internet in both cases. Complementary HIP extensions for these two cases should support a third case where both parties are located behind NATs. This document currently describes extensions for the first case only; future revisions will describe extensions for the second case and third case. The mechanisms described this document are based on encapsulating both the control and data traffic in UDP in order to traverse NAT(s). The data traffic is assumed to be ESP. Other types of data traffic are out of scope. Note that due to the mobility and multihoming mechanisms of HIP [I-D.ietf-hip-mm], HIP hosts may change network location during the lifetime of a HIP association. Either host of an established HIP association may move from the global Internet to behind a NAT and vice versa many times during the lifetime of the association. Consequently, hosts need to start using the proposed NAT traversal mechanisms after a mobility event relocates one or both peers behind a NAT. They may also stop using the proposed mechanisms if they both relocate to the public Internet. Note that in order to determine whether to use the proposed NAT traversal mechanisms, HIP hosts need to detect the presence and type of NAT middleboxes between them. STUN [RFC3489] offers a generic mechanism for this purpose. This document therefore does not describe a NAT detection mechanism and assumes that existing mechanisms, such as STUN, are in use. Schmitt, et al. Expires August 31, 2006 [Page 3] Internet-Draft HIP Extensions for NAT Traversal February 2006 Finally, 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. HIP Across NATs HIP communication has two distinct phases. During the first phase, the "base exchange", HIP establishes synchronized state at the initiator and responder of the communication. During the second phase, the "data exchange", HIP uses this state to encrypt data traffic using IPsec ESP. NAT traversal for HIP communication requires mechanisms for handling both the base exchange and the following IPsec ESP traffic. This document describes methods for encapsulating both types of traffic inside of UDP [RFC0768], similar to other NAT traversal mechanisms. One unique aspect of the proposed solution is the use of UDP- encapsulated IPsec BEET mode [I-D.nikander-esp-beet-mode] instead of the more common UDP-encapsulated IPsec transport mode [RFC3948]. The main advantage of UDP-encapsulated IPsec BEET mode over UDP- encapsulated IPsec transport mode for HIP is the explicit definition of inner and outer addresses in BEET mode. The inner addresses of BEET associations are used for processing at all layers of the stack, whereas the outer addresses are only used to transmit the final packets on the wire. This explicit distinction between addresses matches the identifier/locator differentiation in HIP, i.e., HITs as identifiers are inner addresses and IP addresses as locators are outer addresses. [RFC3948] describes UDP encapsulation of IPsec ESP transport and tunnel mode. This document only describes the changes required for UDP encapsulation of BEET mode. A HIP implementation that supports the proposed NAT traversal extensions MUST listen on UDP ports 50500 and 54500 for arriving packets. When packets arrive on these two UDP ports, the implementation MUST accept them regardless of their source port. Port 50500 is used for UDP-encapsulated HIP base exchange and other control traffic, port 54500 is used for UDP-encapsulated ESP data traffic. 2.1. Packet Formats This section defines the UDP-encapsulation packet format for HIP base exchange and control traffic, IPsec ESP BEET-mode traffic and NAT Schmitt, et al. Expires August 31, 2006 [Page 4] Internet-Draft HIP Extensions for NAT Traversal February 2006 keep-alives. 2.1.1. Control Traffic 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ HIP Header ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: Format for UDP-encapsulated HIP control traffic. Figure 1 shows how HIP control packets are encapsulated within UDP. A minimal UDP packet carries a complete HIP packet in its payload. Contents of the UDP source and destination ports are described below. The UDP length and checksum field MUST be computed as described in [RFC0768]. 2.1.2. Control Channel Keep-Alives The keep-alives for control channel are basically UPDATE packets [I-D.ietf-hip-base]. The UPDATE packets MAY contain HIP parameters. The NAT traversal mechanisms encapsulate these UPDATE packets within the payload of UDP packets, as shown in Figure 2. Schmitt, et al. Expires August 31, 2006 [Page 5] Internet-Draft HIP Extensions for NAT Traversal February 2006 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Header | Header Length |0| Packet Type | VER. | RES.|1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Checksum | Controls | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Sender's Host Identity Tag (HIT) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Receiver's Host Identity Tag (HIT) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ HIP Parameters ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: Format for UDP NAT control channel keep-alive packets. Contents of the UDP source and destination ports are described below. The UDP length and checksum field MUST be computed as described in [RFC0768]. The HIP packet header fields are filled in as described in [I-D.ietf-hip-base], except for the HIP checksum, which is always set to zero. The type of the HIP header is 16 (UPDATE). 2.1.3. Data Traffic 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 ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: Format for UDP-encapsulated IPsec ESP BEET-mode traffic. Schmitt, et al. Expires August 31, 2006 [Page 6] Internet-Draft HIP Extensions for NAT Traversal February 2006 Figure 3 shows how IPsec ESP BEET-mode packets are encapsulated within UDP. Again, a minimal UDP packet carries the ESP packet in its payload. Contents of the UDP source and destination ports are described below. The UDP length and checksum field MUST be computed as described in [RFC0768]. 2.1.4. Data Channel Keep-Alives 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 | +-+-+-+-+-+-+-+-+ Figure 4: Format for UDP NAT data channel keep-alive packets. The keep-alive packets to refresh NAT state for the ESP channel are minimal UDP packets that carry a dummy payload of a single octet, as illustrated in Figure 4. The single-octet payload value MUST be 0xFF. The format is the same as in [RFC3948]. Contents of the UDP source and destination ports are described below. The UDP length and checksum field MUST be computed as described in [RFC0768]. 2.2. NAT Traversal of HIP Control Traffic This section describes the details of enabling NAT traversal for HIP control traffic, such as the base exchange [I-D.ietf-hip-base], through UDP encapsulation. As pointed out in Section 1, this document currently assumes that only the initiator is located behind one or more NATs whereas the responder is in the global Internet. UDP-encapsulated HIP control traffic MUST use the packet formats described in Section 2.1. When sending UDP-encapsulated HIP control traffic, a HIP implementation that supports the proposed NAT traversal extensions MUST zero the HIP header checksum before calculating the UDP checksum. Receivers MUST only verify the correctness of the UDP checksum and MUST NOT verify the checksum of the HIP header. The reason why HIP checksum is not used is that it is redundant and requires the use of inner addresses (extra complexity for NAT transformation). The initiator of a UDP-encapsulated HIP base exchange MUST use the UDP destination port 50500 for all control packets it sends. It MAY use 50500 as the source port as well, or it MAY use a random, Schmitt, et al. Expires August 31, 2006 [Page 7] Internet-Draft HIP Extensions for NAT Traversal February 2006 unoccupied source port. If it uses a random source port, it MUST listen for and accept arriving HIP control packets on this port until the corresponding HIP association is torn down. A random source port MUST be in the range of the dynamic and private ports (49152-65535). Using a random source port instead of a fixed one makes it possible to have multiple clients behind a NAT middlebox that does only address translation but no port translation. The responder of a UDP-encapsulated HIP base exchange MUST use 50500 as the source port for all UDP-encapsulated control packets it sends. As a source IP address, it MUST use the IP address that prior packets from the initiator of this HIP association arrived on. Similarly, it MUST use the source IP address and source UDP port of prior packets from the initiator of the respective HIP association as the destination IP address and destination UDP port. The responder MUST NOT respond to any arriving UDP-encapsulated control message with an unencapsulated reply. Whether or not HIP control packets are UDP-encapsulated MUST NOT affect the HIP state machine. HIP implementations that implement the NAT traversal mechanisms generally MUST process all UDP-encapsulated control messages equivalently to unencapsulated control messages, i.e., according to [I-D.ietf-hip-base]. The single exception to this rule is that if the base exchange was UDP-encapsulated, implementations MUST establish a UDP-encapsulated BEET-mode ESP IPsec association (see Section 2.3) for subsequent data traffic instead of the regular transport-mode ESP association specified in [I-D.ietf-hip-esp]. The remainder of this section clarifies this process through an example, illustrated in Figure 5. It shows an initiator I with the private IP address IP(I) behind a NAT. The NAT has the private IP address IP(NAT1) and the public IP address IP(NAT2). The responder is located in the public Internet at the IP address IP(R). Schmitt, et al. Expires August 31, 2006 [Page 8] Internet-Draft HIP Extensions for NAT Traversal February 2006 +---+ Private Network +---+ Public Internet +---+ | I |----------------------|NAT|----------------------| R | +---+ +---+ +---+ | IP(I) IP(NAT1) | IP(NAT2) IP(R) | | | | |>>>>>>>>>>>>>>>>>>>>>>>>>>|>>>>>>>>>>>>>>>>>>>>>>>>>>| | I1: IP(I):P(I) -> | I1: IP(NAT2):P(NAT-A) -> | | IP(R):P(50500) | IP(R):P(50500) | | | | |<<<<<<<<<<<<<<<<<<<<<<<<<<|<<<<<<<<<<<<<<<<<<<<<<<<<<| | R1: IP(R):P(50500) -> | R1: IP(R):P(50500) -> | | IP(I):P(I) | IP(NAT2):P(NAT-A) | | | | |>>>>>>>>>>>>>>>>>>>>>>>>>>|>>>>>>>>>>>>>>>>>>>>>>>>>>| | I2: IP(I):P(I) -> | I2: IP(NAT2):P(NAT-B) -> | | IP(R):P(50500) | IP(R):P(50500) | | | | |<<<<<<<<<<<<<<<<<<<<<<<<<<|<<<<<<<<<<<<<<<<<<<<<<<<<<| | R2: IP(R):P(50500) -> | R2: IP(R):P(50500) -> | | IP(I):P(I) | IP(NAT2):P(NAT-B) | Figure 5: Example of a UDP-encapsulated HIP base exchange (initiator behind a NAT, responder on the public Internet). The initiator I begins the base exchange by sending a UDP- encapsulated I1 packet to the responder. According to the rules specified above, the source IP address of this I1 packet is IP(I) and its source UDP port is P(I). It is addressed to IP(R) on port P(50500). The NAT in Figure 5 forwards the I1 but substitutes the source IP(I) with its own public IP address IP(NAT2) and substitutes the source UDP port P(I) with P(NAT-A), which will usually be different from P(I). When the responder R in Figure 5 receives the UDP-encapsulated I1 packet on the UDP port 50500, it processes it according to [I-D.ietf-hip-base]. According to the rules specified above, if it replies with an R1 packet, the R1 uses the destination IP address and UDP port from the previous I1 packet as the source IP address and UDP port, i.e., IP(R) and P(50500). Thus R1 packet is destined to the source IP address and UDP port of the I1, i.e., IP(NAT2) and P(NAT-A). The NAT substitutes the destination of this packet, replacing IP(NAT2):P(NAT-A) with IP(I):P(I). When the initiator receives a UDP-encapsulated R1 packet from the responder, it processes it according to [I-D.ietf-hip-base]. When it responds with a UDP-encapsulated I2 packet, it uses the same IP source and destination addresses and UDP source and destination ports that it used for sending the corresponding I1 packet, i.e., the Schmitt, et al. Expires August 31, 2006 [Page 9] Internet-Draft HIP Extensions for NAT Traversal February 2006 packet is addressed as IP(I):P(I) -> IP(R):P(50500). The NAT again substitutes the source information, replacing it with IP(NAT2): P(NAT-B). When a responder receives a UDP-encapsulated I2 packet destined to UDP port 50500, it MUST use the UDP source port contained in this packet for further HIP communications with the initiator. It then processes the I2 packet according to [I-D.ietf-hip-base]. When it responds with an R2 message, it UDP-encapsulates it, using the UDP source port of the I2 packet as the destination UDP port, and sends it to the source IP address of the I2 packet, i.e., it addresses the R2 packet as IP(R):P(50500) -> IP(NAT2):P(NAT-B). The NAT again replaces the destination information in the R2 with IP(I):P(I). Usually, the I1-R1 and I2-R2 exchanges occur fast enough for the NAT state to not time out. This means that the NAT uses the state established during the I1-R1 exchange to translate the I2-R2 exchange, i.e., the ports P(NAT-A) and P(NAT-B) will be identical. Note that the mechanism can handle the case where the NAT state times out between the two exchanges and the I1 and I2 arrive from different UDP source ports and/or IP addresses, as shown in Figure 5. It is important as the responder may be busy and also because the responder can remain stateless until receives an I2. 2.3. NAT Traversal of HIP Data Traffic This section describes the details of enabling NAT traversal of HIP data traffic. As described in Section 2, HIP data traffic is carried in UDP-encapsulated IPsec BEET-mode ESP packets. Section 2.3.1 and Section 2.3.2 describe the UDP encapsulation and decapsulation procedure for IPsec BEET-mode ESP for HIP. Section 2.3.3 describes how hosts configure BEET-mode security associations for HIP communication as part of a UDP-encapsulated base exchange. [I-D.nikander-esp-beet-mode] defines two types of addresses for IPsec BEET mode: inner and outer addresses. Because this document focuses on traversal of legacy IPv4 NATs, the outer BEET-mode address family MUST be IPv4. For HIP communication, the 128-bit Host Identity Tags (HIT) of the the local host and its peer MUST be used as inner BEET- mode addresses. Consequently, the inner BEET-mode address family in the IPsec stack MUST be IPv6. Note that legacy applications MAY use IPv4 local scope identifiers (LSIs) translated to the corresponding HITs by the HIP layer. Such usage is however implementation specific and out of scope of this document. Schmitt, et al. Expires August 31, 2006 [Page 10] Internet-Draft HIP Extensions for NAT Traversal February 2006 2.3.1. UDP Encapsulation of IPsec BEET-Mode ESP An IPv6 packet targeted for UDP BEET-mode encapsulation MUST contain HITs as source and destination IP address. Any present transport- layer checksums in the payload data are consequently based on the HITs. The packet MUST then undergo BEET-mode ESP cryptographic processing as defined in Section 5.3 of [I-D.nikander-esp-beet-mode]. The resulting BEET-mode packet is then UDP encapsulated. For this purpose, a UDP header MUST be inserted between the existing IPv6 and ESP headers. The UDP checksum MUST be calculated based on an IPv4 pseudo-header that contains the outer addresses defined in the corresponding security association (see Section 2.3.3). The source and destination ports MUST also be set according to the security association. The other fields of the UDP header are computed as described in [RFC0768]. The resulting UDP packet MUST then undergo BEET IP header processing as defined in Section 5.4 of [I-D.nikander-esp-beet-mode]. Figure 6 illustrates the BEET-mode UDP encapsulation procedure for a TCP packet. Schmitt, et al. Expires August 31, 2006 [Page 11] Internet-Draft HIP Extensions for NAT Traversal February 2006 ORIGINAL TCP PACKET: -------------------------------------------- | inner IPv6 hdr | ext hdrs | | | | with HITs | if present | TCP | Data | -------------------------------------------- PACKET AFTER BEET-MODE ESP PROCESSING: ------------------------------------------------------------ | inner IPv6 hdr | ESP | dest | | | ESP | ESP | | with HITs | hdr | opts.| TCP | Data | Trailer | ICV | ------------------------------------------------------------ |<------- encryption -------->| |<----------- integrity ----------->| PACKET AFTER UDP ENCAPSULATION: ------------------------------------------------------------------ | inner IPv6 hdr | UDP | ESP | dest | | | ESP | ESP | | with HITs | hdr | hdr | opts.| TCP | Data | Trailer | ICV | ------------------------------------------------------------------ |<------- encryption -------->| |<----------- integrity ----------->| FINAL PACKET AFTER BEET_MODE IP HEADER PROCESSING: -------------------------------------------------------------- | outer IPv4 | UDP | ESP | dest | | | ESP | ESP | | hdr | hdr | hdr | opts.| TCP | Data | Trailer | ICV | -------------------------------------------------------------- |<------- encryption -------->| |<----------- integrity ----------->| Figure 6: UDP Encapsulation of an IPsec BEET-mode ESP packet containing a TCP segment. 2.3.2. UDP Decapsulation of IPsec BEET-Mode ESP An incoming UDP-encapsulated IPsec BEET-mode ESP packet is decapsulated as follows. First, the packet MUST be verified as defined in Section 5.6 of [I-D.nikander-esp-beet-mode]. The packet MUST be dropped if the UDP checksum is invalid. Otherwise, the ESP data contained in the payload of the UDP packet MUST be decrypted as described in Section 5.6 of [I-D.nikander-esp-beet-mode]. Next, the IPv4 header containing the outer addresses MUST be discarded. The UDP header MUST also be discarded. Then, a new IPv6 header MUST be constructed, which includes the HITs as IP addresses. This header MUST be prepended to the decrypted data as specified in Section 5.6 of [I-D.nikander-esp-beet-mode]. Schmitt, et al. Expires August 31, 2006 [Page 12] Internet-Draft HIP Extensions for NAT Traversal February 2006 2.3.3. IPsec BEET-Mode Security Associations During the HIP base exchange, the two peers exchange parameters that enable them to define a pair of IPsec ESP security associations (SAs), as described in [I-D.ietf-hip-esp]. As mentioned in Section 2.2, if two peers perform a UDP-encapsulated base exchange, they MUST define a pair of IPsec SAs that result in UDP-encapsulated BEET-mode ESP data traffic. The management of encryption and authentication protocols and of security parameter indices (SPIs) occurs as defined in [I-D.ietf-hip-esp]. Additional SA parameters, such as IP addresses and UDP ports, MUST be defined according to the following specification. Two SAs MUST be defined on each host for one HIP association; one for outgoing data and another one for incoming data. The initiator of the base exchange MUST also initiate the IPsec BEET- mode ESP exchange, by either sending a UDP-encapsulated ESP data packet or a keep-alive packet (see Section 2.1.4) if it has no data to send. This MUST occur immediately after the base exchange has succeeded, after the initiator has defined its two SAs for the HIP association. The responder can only set up its SAs after receiving and verifying the first packet from the initiator, because it needs to learn the outer IP address and UDP port used by the NAT. The initiator MUST use UDP destination port 54500 for all UDP- encapsulated ESP packets it sends. It MAY also use port 54500 as source port or it MAY use a random source port. If it uses a random source port, it MUST listen for and accept arriving UDP-encapsulated ESP packets on this port until the corresponding HIP association is torn down. A random source port MUST be in the range of the dynamic and private ports (49152-65535). The responder of a UDP-encapsulated IPsec BEET-mode ESP exchange MUST use 54500 as the source port for all UDP-encapsulated ESP packets it sends. It MUST use the source UDP port of prior UDP-encapsulated ESP packets from the initiator of the respective HIP association as the destination port of the UDP tunnel. 2.3.3.1. Security Associations at the Initiator The initiator of a UDP-encapsulated base exchange MUST define its outbound SA as follows: IPsec ESP mode: BEET mode with UDP encapsulation Schmitt, et al. Expires August 31, 2006 [Page 13] Internet-Draft HIP Extensions for NAT Traversal February 2006 Inner source address: the same local HIT used during the base exchange Inner destination address: the same responder HIT used during the base exchange Outer source address: the same local IP address from which the base exchange packets were transmitted Outer destination address: the same peer IP address to which base exchange packets were transmitted UDP source port: the initiator MAY use source port 54500 or it MAY use a random port in the range of 49152-65535 UDP destination port: port 54500 Similarly, the initiator of a UDP-encapsulated base exchange MUST define its inbound SA as follows: IPsec ESP mode: BEET mode with UDP encapsulation Inner source address: the same responder HIT used during the base exchange Inner destination address: the same local HIT used during the base exchange Outer source address: the same peer IP address to which base exchange packets were transmitted Outer destination address: the same local IP address from which the base exchange packets were transmitted UDP source port: port 54500 UDP destination port: the initiator MUST use the UDP source port it uses in the outbound SA as the UDP destination port here Schmitt, et al. Expires August 31, 2006 [Page 14] Internet-Draft HIP Extensions for NAT Traversal February 2006 2.3.3.2. Security Associations at the Responder The responder of a UDP-encapsulated base exchange MUST define its SAs after the first UDP-encapsulated ESP packet from the initiator that has been received has been correctly processed, using the SPI defined during the base exchange. When it sets up its SAs, it MUST use the source IP address and source UDP port of that packet as outer destination address and destination UDP port. Note that NATs may modify this address and port and they usually will not match the values used at the initiator. The responder of a UDP-encapsulated base exchange MUST define its outbound SA as follows: IPsec ESP mode: BEET mode with UDP encapsulation Inner source address: the same local HIT used during the base exchange Inner destination address: HIT of the initiator used during the base exchange Outer source address: the same local IP address from which the base exchange packets were transmitted Outer destination address: source IP address of the first correctly processed UDP- encapsulated ESP packet received from the initiator UDP source port: port 54500 UDP destination port: source UDP port of the first correctly processed UDP-encapsulated ESP packet received from the initiator Similarly, the initiator of a UDP-encapsulated base exchange MUST define its inbound SA as follows: IPsec ESP mode: BEET mode with UDP encapsulation Inner source address: HIT of the initiator used during the base exchange Schmitt, et al. Expires August 31, 2006 [Page 15] Internet-Draft HIP Extensions for NAT Traversal February 2006 Inner destination address: the same local HIT used during the base exchange Outer source address: source IP address of the first correctly processed UDP- encapsulated ESP packet received from the initiator Outer destination address: the same local IP address from which the base exchange packets were transmitted UDP source port: source UDP port of the first correctly processed UDP-encapsulated ESP packet received from the initiator UDP destination port: port 54500 2.4. NAT Keep-Alives Typically, NATs cache an established binding and time it out if they have not used it to relay traffic for a given period of time. This timeout is different for different NAT implementations. The BEHAVE working group is discussing recommendations for standardized timeout values. To prevent NAT bindings that support the traversal of UDP- encapsulated HIP traffic from timing out during times when there is no control or data traffic, HIP hosts SHOULD send periodic keep-alive messages, similar to [RFC3948]. Typically, NATs only act on keep-alives received from hosts in the private network they connect to the public Internet, for security reasons. Consequently, those hosts SHOULD send periodic keep-alives for the control and data channels of all their established HIP associations if the respective channel has been idle for a specific period of time. Keep-alive intervals for control and data channels SHOULD be separately configurable parameters of a HIP association. For the control channel, keep-alives MUST be UDP-encapsulated HIP UPDATE packets as defined in Section 2.1.2. The packets MUST use the same source and destination ports and IP addresses as the corresponding UDP tunnel. The default keep-alive interval for control channels MUST be 20 seconds. For the data channel, keep-alives MUST be UDP packets defined in Section 2.1.4. The packets MUST use the same source and destination ports and IP addresses as the corresponding UDP tunnel. The receiver Schmitt, et al. Expires August 31, 2006 [Page 16] Internet-Draft HIP Extensions for NAT Traversal February 2006 of a UDP keep-alive packet MUST discard it. The default keep-alive interval for data channels MUST be 20 seconds. 2.5. HIP Mobility This draft assumes that the initiator and responder do not change their network location during base exchanges. After a base exchange has succeeded, either host can change its network location using the mechanisms defined in [I-D.ietf-hip-mm]. This document currently only describes the case where the host behind a NAT changes its location. The case when the host in the public Internet changes its location is currently not described. This section only discusses mobility events of single SA pairs between the peers; it does not currently describe mobility events of multiple SA pairs and multihoming. In addition, all privacy issues are out of scope even though it is possible that the host behind the NAT reveals its private address during a mobility event. When a host behind a NAT changes its location, it SHOULD detect the presence of NATs along the new paths to its peers using some external mechanism before sending any UPDATE messages. Alternatively, it MAY use some heuristics to conclude that it is behind a NAT rather than incur the latency of running NAT detection first. If the host does not detect a NAT along a new path to a peer, it MAY start to use unencapsulated HIP traffic for the association with that peer. The host sends a regular, unencapsulated UPDATE packet to its peer to announce its new location. When the peer receives and verifies the UPDATE, it detects that no UDP header is present. Consequently, the peer MUST check the HIP header checksum and drop the packet if the validation fails. In addition, the peer MUST not use UDP encapsulation for communication with the host any longer, i.e., it must set up regular ESP SAs to the host. The host MUST do the same. The peer MUST also send further HIP control packets without UDP encapsulation. However, when the host does detect a NAT along the new path to a peer, it MUST continue to use UDP encapsulation both for HIP and ESP packets, using the same ports it used along the old path. The host MUST send a UDP-encapsulated UPDATE packet to the peer. In addition, it MUST also send an ESP keep-alive to reactivate the UDP encapsulation of ESP traffic. The UDP source ports for both control and data channel MUST remain the same and the destination ports MUST be the ports 50500 for HIP and 54500 for ESP, respectively. Upon receiving a HIP UPDATE packet from a peer, a host first validates the UDP checksum and then actual HIP packet. If either validation fails, the host MUST drop the packet. After successful Schmitt, et al. Expires August 31, 2006 [Page 17] Internet-Draft HIP Extensions for NAT Traversal February 2006 validation, it MUST check if the source port in the UDP packet has changed. If there are no changes, nothing needs to be done for the UDP tunnel. However, if the source port has changed, this indicates that the peer has moved behind a NAT. In this case, the receiver MUST stop using the earlier UDP tunnel. It MUST open a new UDP tunnel for HIP control packets based on the addresses and ports contained in the received UDP packet and MUST start using it for further communication with the peer. An additional issue can occur due to NAT timeouts. Because an UPDATE exchange consist of at least three HIP control packets, it is possible that UPDATE packets can arrive from unexpected UDP ports at the host in the public Internet. As a consequence, the receiving host MUST start using the new UDP port for further communication with the sender, after successful HIP packet validation. It is important that UPDATE packet validation MUST occur before tearing down a UDP tunnel. In the worst case, an attacker could cause a DoS attack by sending a replayed UPDATE packet with incorrected UDP source port information. 2.6. HIP Multihoming Multiple security associations can exists between the same hosts. They may be connected through several paths, some of which may include a NAT and others may not. Implementations that support multihoming MUST support concurrent HIP associations between the same host pair in a way that allows some of them to use UDP encapsulation while others use basic HIP. Implementations MAY distinguish HIP associations based on the SPI instead of a HIT pair for this purpose. 2.7. Firewall Traversal When the initiator or the responder of a HIP association is behind a firewall, additional issues arise. When the initiator is behind a firewall, the NAT traversal mechanisms described in Section 2 depend on the ability to initiate communication via UDP to destination ports 50500 and 54500 from arbitrary source ports and to receive UDP response traffic from those ports to the chosen source port. Most firewall implementations support "UDP connection tracking", i.e., after a host behind a firewall has initiated a UDP communication to the public Internet, the firewall relays UDP response traffic in the return direction. If no such return traffic arrives for a specific period of time, the firewall stops relaying the given IP address and port pair. The mechanisms described in Schmitt, et al. Expires August 31, 2006 [Page 18] Internet-Draft HIP Extensions for NAT Traversal February 2006 Section 2 already enable traversal of such firewalls, if the keep- alive interval used is less than the refresh interval of the firewall. If the initiator is behind a firewall that does not support "UDP connection tracking", the NAT traversal mechanisms described in Section 2 can still be supported, if the firewall allows permanently inbound UDP traffic from ports 50500 and 54500 and destined to arbitrary source IP addresses and UDP ports. When the responder is behind a firewall, the NAT traversal mechanisms described in Section 2 depend on the ability to receive UDP traffic on ports 50500 and 54500 from arbitrary source IP addresses and ports. The NAT traversal mechanisms described in Section 2 require that the firewall - stateful or not - allow inbound UDP traffic to ports 50500 and 54500 and allow outbound UDP traffic to arbitrary UDP ports. 3. Security Considerations Section 5.1 of [RFC3948] describes a security issue for the UDP encapsulation of standard IP tunnel mode when two hosts behind different NATs have the same private IP address and initiate communication to the same responder in the public Internet. The responder cannot distinguish between the two hosts, because security associations are based on the same inner IP addresses. This issue does not exist with the UDP encapsulation of IPsec BEET mode as described in Section 2, because the responder use the HITs to distinguish between different communication instances. 4. IANA Considerations This section is to be interpreted according to [RFC2434]. This draft currently uses two UDP ports in the "Dynamic and/or Private Port" range, i.e., 50500 and 54500. Upon publication of this document, IANA is requested to register two UDP ports and the RFC editor is requested to change all occurrences of ports 50500 and 54500 to the two ports IANA has registered. 5. Acknowledgements The authors would like to thank Tobias Heer, Teemu Koponen, Juhana Schmitt, et al. Expires August 31, 2006 [Page 19] Internet-Draft HIP Extensions for NAT Traversal February 2006 Mattila, Jeffrey M. Ahrenholz, Thomas Henderson, Kristian Slavov, Janne Lindqvist and Pekka Nikander for their comments on this document. [I-D.nikander-hip-path] presented some initial ideas for NAT traversal of HIP communication. This document describes significantly different mechanisms that, among other differences, use external NAT discovery and do not require encapsulation servers. Lars Eggert and Martin Stiemerling are partly funded by Ambient Networks, a research project supported by the European Commission under its Sixth Framework Program. The views and conclusions contained herein are those of the authors and should not be interpreted as necessarily representing the official policies or endorsements, either expressed or implied, of the Ambient Networks project or the European Commission. Miika Komu is working for InfraHIP research group at Helsinki Institute for Information Technology (HIIT). The InfraHIP project is funded by Tekes, Elisa, Nokia, The Finnish Defence Forces and Ericsson. 6. References 6.1. Normative References [I-D.ietf-hip-arch] Moskowitz, R. and P. Nikander, "Host Identity Protocol Architecture", draft-ietf-hip-arch-03 (work in progress), August 2005. [I-D.ietf-hip-base] Moskowitz, R., "Host Identity Protocol", draft-ietf-hip-base-04 (work in progress), October 2005. [I-D.ietf-hip-esp] Jokela, P., "Using ESP transport format with HIP", draft-ietf-hip-esp-01 (work in progress), October 2005. [I-D.ietf-hip-mm] Nikander, P., "End-Host Mobility and Multihoming with the Host Identity Protocol", draft-ietf-hip-mm-02 (work in progress), July 2005. [I-D.nikander-esp-beet-mode] Melen, J. and P. Nikander, "A Bound End-to-End Tunnel (BEET) mode for ESP", draft-nikander-esp-beet-mode-04 Schmitt, et al. Expires August 31, 2006 [Page 20] Internet-Draft HIP Extensions for NAT Traversal February 2006 (work in progress), November 2005. [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. [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. 6.2. Informative References [I-D.irtf-hiprg-nat] Stiemerling, M., "Middlebox Traversal Issues of Host Identity Protocol (HIP) Communication", draft-irtf-hiprg-nat-01 (work in progress), January 2006. [I-D.nikander-hip-path] Nikander, P., "Preferred Alternatives for Tunnelling HIP (PATH)", draft-nikander-hip-path-00 (work in progress), February 2005. [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999. [RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, "STUN - Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs)", RFC 3489, March 2003. [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. Stenberg, "UDP Encapsulation of IPsec ESP Packets", RFC 3948, January 2005. Appendix A. Document Revision History To be removed upon publication +----------+-------------------------------------------------------+ | Revision | Comments | +----------+-------------------------------------------------------+ | 00 | Initial version. | +----------+-------------------------------------------------------+ Schmitt, et al. Expires August 31, 2006 [Page 21] Internet-Draft HIP Extensions for NAT Traversal February 2006 Authors' Addresses Vivien Schmitt NEC Network Laboratories Kurfuerstenanlage 36 Heidelberg 69115 Germany Phone: +49 6221 90511 0 Fax: +49 6221 90511 55 Email: schmitt@netlab.nec.de URI: http://www.netlab.nec.de/ Abhinav Pathak IIT Kanpur B204, Hall - 1, IIT Kanpur Kanpur 208016 India Phone: +91 9336 20 1002 Email: abhinav.pathak@hiit.fi URI: http://www.iitk.ac.in/ Miika Komu Helsinki Institute for Information Technology Tammasaarenkatu 3 Helsinki Finland Phone: +358503841531 Fax: +35896949768 Email: miika@iki.fi URI: http://www.hiit.fi/ Lars Eggert NEC Network Laboratories Kurfuerstenanlage 36 Heidelberg 69115 Germany Phone: +49 6221 90511 43 Fax: +49 6221 90511 55 Email: lars.eggert@netlab.nec.de URI: http://www.netlab.nec.de/ Schmitt, et al. Expires August 31, 2006 [Page 22] Internet-Draft HIP Extensions for NAT Traversal February 2006 Martin Stiemerling NEC Network Laboratories Kurfuerstenanlage 36 Heidelberg 69115 Germany Phone: +49 6221 90511 13 Fax: +49 6221 90511 55 Email: stiemerling@netlab.nec.de URI: http://www.netlab.nec.de/ Full Copyright Statement Copyright (C) The Internet Society (2006). 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 Schmitt, et al. Expires August 31, 2006 [Page 23] Internet-Draft HIP Extensions for NAT Traversal February 2006 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Schmitt, et al. Expires August 31, 2006 [Page 24]