HIP Working Group M. Komu Internet-Draft HIIT Intended status: Experimental T. Henderson Expires:
January 16,May 4, 2009 The Boeing Company P. Matthews (Unaffiliated) H. Tschofenig Nokia Siemens Networks A. Keraenen,Keranen, Ed. Ericsson Research Nomadiclab July 15,October 31, 2008 Basic HIP Extensions for Traversal of Network Address Translators draft-ietf-hip-nat-traversal-04.txtdraft-ietf-hip-nat-traversal-05.txt 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. 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 January 16,May 4, 2009. Abstract TheThis document specifies extensions to the Host Identity Protocol (HIP) provides a new namespace that can be used for uniquely identifying hosts. Existing HIP experimental specifications do not specify protocol operations acrossto facilitate Network Address Translators (NATs). This document specifies basic NAT traversal extensions for HIP. The HIP shim layer is located between the network and transport layer, the extensions can also provide a more general-purpose NAT traversal support for higher-layer networking applications.Translator (NAT) traversal. The extensions are based on the use of the TheInteractive Connectivity Establishment (ICE) methodology to discover a working path between two end-hosts.end-hosts, and on standard techniques for encapsulating Encapsulating Security Payload (ESP) packets within the User Datagram Protocol (UDP). This document also defines elements of procedure for NAT traversal, including the optional use of a HIP relay server. With these extensions HIP is able to work in environments that have NATs and provides a generic NAT traversal solution to higher-layer networking applications. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 34 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 56 3. Overview of Operation . . . . . . . . . . . . . . . . . . . . 7 4. Protocol Description . . . . . . . . . . . . . . . . . . . . . 6 3.1.8 4.1. Relay Registration . . . . . . . . . . . . . . . . . . . . 6 3.2.8 4.2. ICE Candidate Gathering . . . . . . . . . . . . . . . . . 10 4.3. NAT TransformationTraversal Mode Negotiation . . . . . . . . . . . . . . 8 3.3.10 4.4. Connectivity Check Pacing Negotiation . . . . . . . . . . 12 4.5. Base Exchange via HIP Relay Server . . . . . . . . . . . . . . . 9 3.4.12 4.6. ICE Connectivity Checks . . . . . . . . . . . . . . . . . 11 3.5.14 4.7. NAT Keepalives . . . . . . . . . . . . . . . . . . . . . . 12 3.6.15 4.8. Base Exchange without ICE Connectivity Checks . . . . . . 12 3.7.16 4.9. Simultaneous Base Exchange with and without UDP Encapsulation . . . . . . . . . 13 3.8.. . . . . . . . . . . . . 16 4.10. Sending Control Messages usingafter the Data Plane .Base Exchange . . . . . 13 4.17 5. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . . 13 4.1.17 5.1. HIP Control Packets . . . . . . . . . . . . . . . . . . . 14 4.2.18 5.2. Connectivity Checks . . . . . . . . . . . . . . . . . . . 14 4.3.18 5.3. Keepalives . . . . . . . . . . . . . . . . . . . . . . . . 15 4.4. Relay and Registration Parameters19 5.4. NAT Traversal Mode Parameter . . . . . . . . . . . . 16 4.5. LOCATOR Parameter. . . 20 5.5. Connectivity Check Transaction Pacing Parameter . . . . . 20 5.6. Relay and Registration Parameters . . . . . . . . . . . . 17 4.6. RELAY_HMAC21 5.7. LOCATOR Parameter . . . . . . . . . . . . . . . . . . . . 22 5.8. RELAY_HMAC Parameter . . . . 19 4.7.. . . . . . . . . . . . . . . 23 5.9. Registration Types . . . . . . . . . . . . . . . . . . . . 19 4.8.23 5.10. ESP Data Packets . . . . . . . . . . . . . . . . . . . . . 20 5.24 6. Security Considerations . . . . . . . . . . . . . . . . . . . 20 5.1.24 6.1. Privacy Considerations . . . . . . . . . . . . . . . . . . 20 5.2.24 6.2. Opportunistic Mode . . . . . . . . . . . . . . . . . . . . 21 5.3.25 6.3. Base Exchange Replay Protection for HIP Relay Server . . . 21 5.4.25 6.4. Demuxing Different HIP Associations . . . . . . . . . . . 21 6.25 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 7.25 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 22 8.26 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22 9.26 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 9.1.26 10.1. Normative References . . . . . . . . . . . . . . . . . . . 22 9.2.26 10.2. Informative References . . . . . . . . . . . . . . . . . . 2427 Appendix A. Selecting a Value for Check Pacing . . . . . . . . . 28 Appendix B. IPv4-IPv6 Interoperability . . . . . . . . . . . . . 2429 Appendix B.C. Base Exchange through a Rendezvous Server . . . . . . 2429 Appendix C.D. Document Revision History . . . . . . . . . . . . . . 2529 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 2530 Intellectual Property and Copyright Statements . . . . . . . . . . 2732 1. Introduction HIP [RFC5201] is defined as a protocol that runs directly over IPv4 or IPv6, and HIP coordinates the setup of ESP security associations [RFC5202] that are also specified to run over IPv4 or IPv6. This approach is known to have problems traversing NATs. A detailed description of HIP problems with traversing legacyNATs and other middleboxes is documented in [I-D.irtf-hiprg-nat].[RFC5207]. This document describesdefines HIP extensions for the traversal of both Network Address Translator (NAT) and Network Address and Port Translator (NAPT) middleboxes. The document generally uses the term NAT to refer to these types of middleboxes. Currently deployed NAT devices do not operate consistently even though a recommended behavior is described in [RFC4787]. The HIP protocol extensions in this document make as few assumptions as possible about the behavior of the NAT devices so that NAT traversal will work even with legacy NAT devices. The purpose of these extensions is to allow two HIP-enabled hosts to communicate with each other even if one or both of the communicating hosts are in private address realms.a network that is behind one or more NATs. Using the extensions defined in this draft,document, HIP end-hosts use techniques drawn from the HIP control channel to communicate their current locators to each otherInteractive Connectivity Establishment (ICE) methodology [I-D.ietf-mmusic-ice] to find aoperational pathpaths for the HIP control protocol and for ESP encapsulated data traffic. The hosts test connectivity between different locators and try to discover a direct end-to-end path between the end-hosts.them. However, Withwith some legacy NATs, utilizing the shortest path between two end hostsend-hosts located behind NATs is not possible without relaying the traffic through a relay, such as a TURN server [RFC5128]. As a consequence, the TURN serverBecause relaying traffic increases the roundtrip delay and may become a point of network congestion. Withconsumes resources from the relay, with the extensions described in this document, hosts try to avoid the useusing the TURN server whenwhenever possible. HIP has defined a Rendezvous Server [RFC5204] to allow for mobile HIP hosts to establish a stable point-of-contact in the Internet. This document defines new middleboxextensions to allow NAT traversalthe Rendezvous Server that solve the same problems but for HIP control plane.both NATed and non-NATed networks. The HIP Relay extensions define mechanisms to forwardextended Rendezvous Server, called a "HIP relay server," forwards all HIP control plane. A distinction must be made herepackets between a HIP rendezvous services [RFC5204]) and HIP Relay services. HIP rendezvous servers solve initial contactan Initiator and mobility related problems in networks without NATs. HIP Relay servers solve the same problems, in additionResponder, allowing Responders to NAT traversal problems. HIP Relay servers canbe used both in NATed and non-NATed networks. Both rendezvous and relay services forward HIP control packets, but the main differencelocated behind NATs. This behavior is thatin contrast to the HIP rendezvous service that forwards only the initial I1 packet of the base exchange while all other HIP control packets are sent directly between the communicating hosts. In contrast, the relay serviceexchange, which is less likely to work in a NATed environment [RFC5128]. Therefore, when using relays allto traverse NATs, HIP uses a HIP relay server for the control packets because NATs can droptraffic and a TURN server for the packets otherwise [RFC5128].data traffic. The basis for the connectivity checks is ICE [I-D.ietf-mmusic-ice]. [I-D.ietf-mmusic-ice] describes ICE as follows: "The Interactive Connectivity Establishment (ICE) methodology is a technique for NAT traversal for UDP-based media streams (though ICE can be extended to handle other transport protocols, such as TCP) established by the offer/answer model. ICE is an extension to the offer/answer model, and works by including a multiplicity of IP addresses and ports in SDP offers and answers, which are then tested for connectivity by peer-to-peer connectivity checks. The IP addresses and ports included in the SDP and the connectivity checks are performed using the revised STUN specification [I-D.ietf-behave-rfc3489bis],[RFC5389], now renamed to Session Traversal Utilities for NAT." The standard ICE for SIP[I-D.ietf-mmusic-ice] is specified with SIP in [I-D.ietf-mmusic-ice]mind and it has some features that are not necessary or suitable as such for other protocols. [I-D.rosenberg-mmusic-ice-nonsip] gives instructions and recommendations on how ICE can be used for non-SIPother protocols is specified in [I-D.rosenberg-mmusic-ice-nonsip].and this document follows those guidelines. Two HIP hosts that implement this specification communicate their locators to each other in the HIP base exchange. TheyThe locators are then paired with the locally operational addresslocators of the other endpoint and prioritized according local andto recommended and local policies. These address setslocator pairs are then tested sequentially based on the procedures specified in ICE. Both sides participate inby both of the connectivity checks.end hosts. The tests may also discoverresult in multiple operational addresspairs but ICE procedures determine a single preferred address pair to be used for subsequent communication. In a nutshell,summary, the extensions in this document defines:define: o encapsulatationUDP encapsulation of HIP packets in UDPo UDP encapsulation of IPsec ESP packets o registration extensions for HIP Relayrelay services o how the ICE "offer" and "answer" are carried in the base exchange o interaction with ICE connectivity check messages o backwards compatibility issues with rendezvous servers o a number of optimizations (such as when the ICE connectivity tests can be excluded)omitted) 2. Terminology 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]. This document borrows terminology from [RFC5201], [RFC5206], [RFC4423], [I-D.ietf-mmusic-ice], and [I-D.ietf-behave-rfc3489bis].[RFC5389]. Additionally, the following terms are used: Rendezvous server: A host that forwards I1 packets to the ResponderResponder. HIP Relay:relay server: A host that forwards all HIP control packets between anthe Initiator and Responderthe Responder. TURN server: A server that forwards data traffic between two end-hosts as defined in [I-D.ietf-behave-turn]. Locator: As defined in [RFC5206]: "A name that controls how the packet is routed through the network and demultiplexed by the end host.end-host. It may include a concatenation of traditional network addresses such as an IPv6 address and end-to-end identifiers such as an ESP SPI. It may also include transport port numbers or IPv6 Flow Labels as demultiplexing context, or it may simply be a network address." It should noticednoted that "address" is used in this document as a synonym for locator. HIP Relay:LOCATOR (written in capital letters) denotesletters): Denotes a HIP control message parameter that bundles multiple locators togethertogether. ICE Offer:offer: The Initiator's LOCATOR parameter in a HIP I2 control message. ICE Answer:answer: The Responder's LOCATOR parameter in a HIP R2 control messagemessage. Transport address: Transport layer port and the corresponding IPv4/v6 addressaddress. Candidate: A transport address that has not been verified yet for reachability using ICE Host candidate: An IPv4 or IPv6 address ofis a network interfacepotential point of a host Server reflexive transportcontact for receiving data. Host candidate: A translated transport address of acandidate obtained by binding to a specific port from an IP address on the host. Server reflexive candidate: A translated transport address of a host as observed by a HIP Relayrelay server or a STUN serverSTUN/TURN server. Peer reflexive transportcandidate: A translated transport address of a host as observed by its peerpeer. Relayed transportcandidate: A transport address that exists on a TURN server. Packets that arrive at this address are relayed towards the TURN client. 3. Overview of Operation +-------+ | HIP | +--------+ | Relay | +--------+ | TURN | +-------+ | STUN | | Server | / \ | Server | +--------+ / \ +--------+ / \ / \ / \ / <- Signaling -> \ / \ +-------+ +-------+ | NAT | | NAT | +-------+ +-------+ / \ / \ +-------+ +-------+ | Init- | | Resp- | | iator | | onder | +-------+ +-------+ Figure 1: Example network configuration In an example configuration depicted in Figure 1, both Initiator and Responder are behind one or more NATs, and both private networks are connected to the public Internet. To be contacted from behind a NAT, the Responder must be registered with a HIP relay server reachable on the public Internet, and we assume as a starting point that the Initiator knows both the Responder's HIT and the address of one of its relay servers (how the Initiator learns of the Responder's relay server is outside of the scope of this document, but may be through DNS or another name service). The first steps are for both the Initiator and Responder to register with a relay server (need not be the same one) and gather a set of address candidates. Next, the HIP base exchange is carried out by encapsulating the HIP control packets in UDP datagrams and sending them through the Responder's relay server. As part of the base exchange, each HIP host learns of the peer's candidate addresses through the ICE offer/answer procedure embedded in the base exchange. Once the base exchange is completed, HIP has established a working communication session (for signaling) via a relay server, but the hosts still work to find a better path, preferably without a relay, for the ESP data flow. For this, ICE connectivity checks are carried out until a working pair of addresses is discovered. At the end of the procedure, if successful, the hosts will have enabled a UDP-based flow that traverses both NATs, with the data flowing directly from NAT to NAT or via a TURN server. Further HIP signaling can be sent over the same address/port pair and is demultiplexed from data traffic via a marker in the payload. Finally, NAT keepalives will be sent as needed. If either one of the hosts knows that it is not behind a NAT, hosts can negotiate during the base exchange a different mode of NAT traversal that does not use ICE connectivity checks, but only UDP encapsulation of HIP and ESP. Also, it is possible for the Initiator to simultaneously try a base exchange with and without UDP encapsulation. If a base exchange without UDP encapsulation succeeds, no ICE connectivity checks or UDP encapsulation of ESP are needed. 4. Protocol Description This section describes the normative behavior of the protocol extension. Examples of packet exchanges are provided for illustration purposes. 18.104.22.168. Relay Registration HIP rendezvous servers operate in non-NATed environments and their use is described in [RFC5204]. This section specifies a new middlebox extension, called the HIP Relay, to peraterelay server, for operating in NATtedNATed environments. A HIP Relay servers forwardrelay server forwards all HIP control packets between the Initiator and the Responder over UDP.Responder. End-hosts cannot use the HIP Relay service for forward ESP data plane. Instead, they use TURN servers [I-D.ietf-behave-turn] for relaying the ESP traffic. A HIP end-host SHOULD register to a TURN server before registering to a HIP Relay to guarantee thatrelay service for forwarding the host can acceptESP traffic immediately after HIP Relay registration.data plane. Instead, they use TURN servers [I-D.ietf-behave-turn] for that. A HIP Relayrelay server MUST silently drop packets to a HIP Relay Clientrelay client that has not previously registered with the HIP Relay.relay. The registration process follows the generic registration extensions defined in [RFC5203] and is illustrated in Figure 1.2. HIP HIP Relay Relay Client Server | 1. UDP(I1) | +------------------------------------------------------->| | | | 2. UDP(R1(REG_INFO(RELAY_UDP_HIP))) | |<-------------------------------------------------------+ | | | 3. UDP(I2(REG_REQ(RELAY_UDP_HIP))) | +------------------------------------------------------->| | | | 4. UDP(R2(REG_RES(RELAY_UDP_HIP), REG_FROM)) | |<-------------------------------------------------------+ Figure 1:2: Example Registration to a HIP Relay In step 1, the Relay Clientrelay client (Initiator) starts the registration procedure by sending an I1 packet over UDP. It is RECOMMENDED that the Initiator selects a random port number from the ephemeral port range 49152-65535 for initiating a base exchange. However, the allocated port MUST be maintained until all of the corresponding HIP Associations are closed. Alternatively, a host MAY also use a single fixed port for initiating all outgoing connections. The HIP relay server MUST listen to incoming connections at UDP port HIPPORT. In step 2, the Relay ServerHIP relay server (Responder) lists the services that it supports in the R1 packet. The support for HIP-over-UDP relaying is denoted by the RELAY_UDP_HIP value. The R1 SHOULD not contain any NAT transform parameter.In step 3, the Initiator selects the services it registers for and lists them in the REG_REQ parameter. In this example, theThe Initiator registers for HIP Relay service.relay service by listing the RELAY_UDP_HIP value in the request parameter. In step 4, the Responder concludes the registration procedure with an R2 packet and acknowledges the registered services in the REG_RES parameter. The Responder denotes unsuccessful registrations (if any) in the REG_FAILED parameter inof R2. The Responder also includes a REG_FROM parameter that contains the transport address of the client as observed by the Relayrelay (Server Reflexive candidate). After the registration, the Initiatorclient sends periodicallyNAT keepalives. There are different ways for an Initiatorkeepalives periodically to learn it's publicly visible IP address and port that are referredthe relay to askeep possible NAT bindings between the "server reflexive transport candidate" in this document. Itclient and the relay alive. 4.2. ICE Candidate Gathering If a host is going to use ICE, it needs to gather a local decision on how the end-host learndsset of address candidates. The candidate gathering SHOULD be done as defined in Section 4.1 of [I-D.ietf-mmusic-ice]. Candidates need to be gathered for only one media stream and component. Component ID 1 should be used for ICE processing, where needed. Initiator takes the candidate, but eitherrole of the following methods is RECOMMENDED: oICE controlling agent. The Relay client may use STUN serverscandidate gathering can be done at any time, but it needs to detectbe done before sending an I2 or R2 if ICE is used for the connectivity checks. It is RECOMMENDED that all three types of candidates (host, server reflexive locator,and relayed) are gathered to maximize probability of successful NAT traversal. However, if no TURN server is used, and the host has only a single local IP address to use, the host MAY use the local address as described in [RFC5128]. o Alternatively,the Relay Client can learn itonly host candidate and the address from the REG_FROM parameter when registering todiscovered during the relay registration as a Relay. 3.2.server reflexive candidate. In this case, no further candidate gathering is needed. 4.3. NAT TransformationTraversal Mode Negotiation This section describes the usage of a new non-critical transformparameter type. The presence of the parameter in a HIP base exchange means that the end-host supports ICE connectivity checks.NAT traversal extensions described in this document. As the parameter is non-critical, it can be ignored by an end-host which means that the host does not support or is not willing to use ICE connectivity checks.these extensions. The NAT transformtraversal mode parameter applies to a base exchange between end- hosts,end-hosts, but currently does not apply to witha registration with a HIP Relayrelay server. The NAT transform applies only to a base exchange with transport layer encapsulation and MUST not be included without transport layer encapsulation. The NAT transformtraversal mode negotiation in base exchange is illustrated in Figure 2.3. Initiator Responder | 1. UDP(I1) | +------------------------------------------------------------->| | | | 2. UDP(R1(.., NAT_TRANSFORM(listNAT_TRAVERSAL_MODE(list of transforms),modes), ..)) | |<-------------------------------------------------------------+ | | | 3. UDP(I2(.., NAT_TRANSFORM(selected transform),NAT_TRAVERSAL_MODE(selected mode), LOCATOR..)) | +------------------------------------------------------------->| | | | 4. UDP(R2(.., LOCATOR, ..)) | |<-------------------------------------------------------------+ | .... | Figure 2:3: Negotiation of NAT TransformsTraversal Mode In step 1, the Initiator sends an I1 to the Responder. In step 2, the Responder responds with an R1. The R1 contains a list of transformsNAT traversal modes the Responder supports in NAT_TRANSFORMthe NAT_TRAVERSAL_MODE parameter as shown in Table 1. +--------------+----------------------------------------------------+ | Transform | Purpose |+-------------------+-----------------------------------------------+ | Type | Purpose | +--------------+----------------------------------------------------++-------------------+-----------------------------------------------+ | RESERVED | Reserved for future use | | UDP-ENCAPSULATION | Use only UDP encapsulation of the HIP | | | signaling traffic and ESP (no ICE | | | connectivity checks) | | ICE-STUN-UDP | UDP encapsulated control and data traffic with| | | with ICE-based connectivity checks using STUN | | | messages | +--------------+----------------------------------------------------++-------------------+-----------------------------------------------+ Table 1: Locator TransformationsNAT Traversal Modes In step 3, the Initiator sends an I2 that includes a NAT_TRANSFORMNAT_TRAVERSAL_MODE parameter. It contains the transform typemode selected by the Initiator from the list of transformsmodes offered by the Responder. The I2 also includes the locators of the Initiator in a LOCATOR parameter. The locator parameter in I2 is the "ICE offer". In step 4, the Responder concludes the base exchange with an R2 packet. The Responder includes a LOCATOR parameter in the R2 packet. The locatorslocator parameter in R2 is the "ICE answer". 22.214.171.124. Connectivity Check Pacing Negotiation As explained in [I-D.ietf-mmusic-ice], when a NAT traversal mode with connectivity checks is used, new transactions should not be started too fast to avoid congestion and overwhelming the NATs. For this purpose, during the base exchange, hosts can negotiate a transaction pacing value, Ta, using a TRANSACTION_PACING parameter in I2 and R2 messages. The parameter contains the minimum time (expressed in milliseconds) the host would wait between two NAT traversal transactions, such as starting a new connectivity check or retrying a previous check. If a host does not include this parameter in the base exchange, a Ta value of 500ms MUST be used as that host's minimum value. The value that is used by both of the hosts is the higher out of the two offered values. Hosts SHOULD NOT use values smaller than 20ms for the minimum Ta, since such values may not work well with some NATs, as explained in [I-D.ietf-mmusic-ice]. The minimum Ta value SHOULD be configurable. Guidelines for selecting a Ta value are given in Appendix A. Currently this feature applies only to the ICE-STUN-UDP NAT traversal mode. 4.5. Base Exchange via HIP Relay Server This section describes how Initiator and Responder establishperform a base exchange through a HIP Relay.relay server. The NAT transformtraversal mode negotiation (denoted as NAT_TFMNAT_TM in the example) was described in the previous section and shall not be repeated here. WhenIf a Relayrelay receives an R1 or I2 packet without the NAT transform packet,traversal mode parameter, it drops it and sends a NOTIFY error message to the originator.sender of the R1/I2. It is RECOMMENDED that the Initiator sends an I1 packet encapsulated in UDP when it is destined to an IPv4 address of the Responder. Respectively, the Responder MUST respond to such an I1 packet with an R1 packet over the transport layer and using the same transport protocol. The rest of the base exchange, I2 and R2, MUST also use the same transport layer.protocol. I HIP Relayrelay R | 1. UDP(I1) | | +----------------------------->| 2. UDP(I1(RELAY_FROM)) | | +------------------------------->| | | | | | 3. UDP(R1(RELAY_TO, NAT_TFM))NAT_TM)) | | 4. UDP(R1(RELAY_TO),NAT_TFM)UDP(R1(RELAY_TO),NAT_TM ) |<-------------------------------+ |<-----------------------------+ | | | | | 5. UDP(I2(LOCATOR),NAT_TFM)UDP(I2(LOCATOR),NAT_TM) | | +----------------------------->| 6. UDP(I2(LOCATOR,RELAY_FROM),| | | NAT_TFM)NAT_TM) | | +------------------------------->| | | | | | 7. UDP(R2(LOCATOR,RELAY_TO)) | | 8. UDP(R2(LOCATOR,RELAY_TO)) |<-------------------------------+ |<-----------------------------+ | | | | Figure 3:4: Base Exchange via a HIP Relay Server In step 1 of Figure 3,4, the Initiator sends an I1 packet over the transport layer to the HIT of the Responder.Responder (and IP address of the relay). The source address is one of the locators of the host. The locators belonging to the end- hosts are referred as "host candidates" in this document.Initiator. In step 2, the HIP Relayrelay server receives the I1 packet at port HIPPORT. If the destination HIT belongs to a registered Responder, the Relayrelay processes the packet. Otherwise, the Relayrelay MUST drop the packet silently. The Relayrelay appends a RELAY_FROM parameter to the I1 packet which contains the transport source address and port of the I1 as observed by the Relay.relay. The Relayrelay protects the I1 packet with RELAY_HMAC as described in [RFC5204], except that the parameter type is different.different (see Section 5.8). The Relayrelay changes the source and destination ports and IP addresses of the packet to match the values the Responder used when registering to the Relay,relay, i.e., the reverse of the R2 used in the registration. The Relayrelay MUST recalculate the transport checksum and forward the packet to the Responder. In step 3, the Responder receives the I1 packet. The Responder processes it according to the rules in [RFC5201]. In addition, the Responder validates the RELAY_HMAC according to [RFC5204] and silently drops the packet if the validation fails. The Responder replies with an R1 packet to which it includes a RELAY_TO parameter. The RELAY_TO parameter MUST contain same information as the RELAY_FROM parameter, i.e., the Initiator's transport address and the nonce,address, but the type of the parameter is different. The RELAY_TO parameter is not integrity protected by the signature of the R1 to allow pre-createdpre- created R1 packets at the Responder. In step 4, the Relayrelay receives the R1 packet. The Relayrelay drops the packet silently if the source HIT belongs to an unregistered host. The Relayrelay MAY verify the signature of the R1 packet and drop it if the signature is invalid. Otherwise, the Relayrelay rewrites the source address and port, and changes the destination address and port to match RELAY_TO information. Finally, the Relayrelay recalculates transport checksum and forwards the packet. In step 5, the Initiator receives the R1 packet and processes it according to [RFC5201]. It replies with an I2 packet that uses the destination transport address of R1 as the source address and port. The I2 contains a LOCATOR parameter that lists all the ICE candidates (ICE offer) of the Initiator. The candidates are encoded using the format defined in Section 126.96.36.199. The I2 packet MUST also contain the NAT transformtraversal mode parameter with ICE-STUN-UDP or some other transformselected because otherwise the Relay may drop the I2 packet.mode. In step 6, the Relayrelay receives the I2 packet. The relay appends a RELAY_FROM and a RELAY_HMAC to the I2 packet as explained in the second step.step 2. In step 7, the Responder receives the I2 packet and processes it according to [RFC5201]. It replies with aan R2 packet and includes a RELAY_TO parameter as explained in step three.3. The R2 packet includes a LOCATOR parameter that lists all the ICE candidates (ICE answer) of the Responder. The RELAY_TO parameter is protected by the HMAC. In step 8, the Relayrelay processes the R2 as described in step four.4. The Relayrelay forwards the packet to the Responder. 3.4.Initiator. Hosts MAY include the address of their HIP relay server in the LOCATOR parameter in I2/R2. The traffic type of this address MUST be "HIP signaling" and it MUST NOT be used as an ICE candidate. This address MAY be used for HIP signaling also after the base exchange. If the HIP relay server locator is not included in I2/R2 LOCATOR parameters, it SHOULD NOT be used after the base exchange, but the HIP signaling SHOULD use the same path as the data traffic. 4.6. ICE Connectivity Checks TheIf a HIP relay server was used, the Responder completes the base exchange with the R2 packet through the Relay.relay. When the Initiator successfully receives and processes the R2, both hosts have transitioned to ESTABLISHED state. However, the destination address the Initiator and Responder used for delivering base exchange packets belonged to the Relay as indicated by the RELAY_FROM and RELAY_TO parameters.HIP relay server. Therefore, the address of the Relayrelay MUST notNOT be used for sending ESP traffic unless it was listed as a TURN server in the offer/answer.traffic. Instead, if a NAT traversal mode with ICE connectivity checks was selected, the Initiator and Responder MUST start ICE connectivity tests after they have transitioned to ESTABLISHED state after the base exchange when they do notResponder MUST start the connectivity checks. Creating the check list for the ICE connectivity checks should be performed as described in Section 5.7 of [I-D.ietf-mmusic-ice] bearing in mind that only one media stream and component is needed (so there will be only a single checklist and all candidates should have valid locator pair for ESP traffic andthe NAT transform parameter was negotiated successfully.same component ID value). The ICEactual connectivity checks are definedMUST be performed as described in [I-D.ietf-mmusic-ice].Section 7 of [I-D.ietf-mmusic-ice]. Regular mode SHOULD be used for the candidate nomination. Section 4.25.2 defines the details of the STUN control packets. As a result of the ICE connectivity checks, ICE nominates a single transport address pair to be used if an operational address could bepair was found. The end-hosts MUST use this address pair for the ESP traffic. 3.5.The connectivity check messages MUST be paced by the value negotiated during the base exchange as described in Section 4.4. If neither one of the hosts announced a minimum pacing value, value of 500ms MUST be used. For retransmissions, the RTO value should be calculated as follows: RTO = MAX (500ms, Ta * P) In the RTO formula, Ta is the value used for the connectivity check pacing and P is the number of pairs in the checklist when the connectivity checks begin. This is identical to the formula in [I-D.ietf-mmusic-ice] if there is only one checklist. 4.7. NAT Keepalives To prevent NAT statestates from expiring, communicating end-hostshosts send periodically keepalives to each other. NAT Relays MUSTHIP relay servers MAY refrain from sending keepalives if it's known that they are not send anybehind a middlebox that requires keepalives. An end-host MUST send keepalives every 15 seconds to refresh the UDP port mapping at the NAT(s) when the control or data channel is idle. To implement failure tolerance, an end-host SHOULD have shorter keepalive period. The keepalives are STUN Binding Indications if the hosts have agreed on NAT_TRANSFORMICE-STUN-UDP NAT traversal mode during the base exchange, orexchange. Otherwise, HIP NOTIFY messages otherwise.MAY be used. A HIP Relayrelay server MUST notNOT forward the NOTIFY messages. The communicating hosts MUST send keepalives to each other using the transport locators exchanged in the base exchangethey agreed to use for data and signaling when they are in ESTABLISHED state. Also, the Initiator MUST send a NOTIFY message to the Relayrelay to refreshkeep the NAT statestates alive on the path between the Initiator and Relayrelay when the Initiator has not received any response to its I1 or I2 from the Responder in 15 seconds. The Relayrelay MUST notNOT forward the NOTIFY messages. 188.8.131.52. Base Exchange without ICE Connectivity Checks In certain network environments, the ICE connectivity checks can be omitted to reduce initial connection set up latency because base exchange acts as an implicit connectivity test itself. There are three assumptions about such as environments. First, the Responder should have a long-term, fixed locator in the network. Second, the Responder should not have a HIP Relayrelay server configured for itself. Third, the Initiator can reach the Responder by simply UDP encapsulating HIP and ESP packets to the host. Detecting and configuring this particular scenario is prone to administrative failure unless carefully planned. In such a scenario, the Initiator sends an I1 packet over UDP to the Responder. TheResponder replies with a R1 packet that does not containMAY include only the UDP- ENCAPSULATION NAT transform parameter. The Initiator receivestraversal mode in the R1 packetmessage. Likewise, if the Initiator knows that it can receive ESP and determines fromHIP signaling traffic by using simply UDP encapsulation, it can choose the UDP-ENCAPSULATION mode in the absence ofI2 message, if the NAT transform and RELAY_TO parameters that ICE connectivity checks can be omitted. Finally,Responder listed it in the hosts can start to usesupported modes. In both of these cases the locators from the concludingI2 and R2 packets of the base exchangewill be used also for ESP withoutthe UDP encapsulated ESP. When no ICE connectivity checks. 3.7.checks are used, locator exchange and return routability tests for mobility and multihoming are done as specified in [RFC5206] with the exception that UDP encapsulation is used. 4.9. Simultaneous Base Exchange with and without UDP Encapsulation The Initiator MAY also try to establishsimultaneously perform a base exchange with the Responder without UDP encapsulation. In such a case, the Initiator sends first antwo I1 packetpackets, one without and one with UDP encapsulationencapsulation, to the Responder. After 100 ms, theThe Initiator MUST thenMAY wait for a while before sending the other I1. How long to wait and in which order to send an UDP-encapsulatedthe I1 packet.packets can be decided based on local policy. For retransmissions, the procedure is repeated. The I1 packet without UDP encapsulation may arrive directly at the Responder. When the recipient is the Responder, the proceducesprocedures in [RFC5201] are followed for the rest of the base exchange. The Initiator may receive multiple R1 messagesmessages, with and without UDP encapsulation, from the Responder, but uponResponder. However, after receiving a valid R1 without UDP encapsulation, the Initiator MUST ignoreand answering to it with an I2, further R1 messages with UDP encapsulation encapsulation. The end-hosts dothat are not trigger ICE connectivity checks after the base exchange sinceretransmits of the UDP encapsulation was excluded.original R1 MUST be ignored. The I1 packet without UDP encapsulation may also arrive at a HIP-capableHIP- capable middlebox. When the middlebox is a HIP rendezvous server and the Responder has successfully registered to the rendezvous service, the middlebox follows rendezvous procedures in [RFC5204]. If[RFC5204]. If the Initiator receives a NAT traversal mode parameter in R1 without UDP encapsulation, the Initiator MAY ignore this parameter and send an I2 without UDP encapsulation and without any selected NAT traversal mode. When the Responder receives the I2 without UDP encapsulation and without NAT traversal mode, it will assume that no NAT traversal mechanism is needed. The packet processing will be done as described in [RFC5201]. The Initiator MAY store the NAT traversal modes for future use e.g., to be used in case of mobility or multihoming event which causes NAT traversal to be taken in to use during the middlebox is a HIP Relay server, it dropslifetime of the I1 packet silently. 3.8.HIP association. 4.10. Sending Control Messages usingafter the Base Exchange After the base exchange, the Data Plane Theend-hosts MAY send HIP control messages directly to each other using the transport address pair established for data channel without sending the control packets through the Relay.HIP relay server. When a host does not get acknowledgements e.g.acknowledgments, e.g., to an UPDATE or CLOSE message after a timeout based on local policies, the host SHOULD resend the packet through the Relay. This optimization requires further experimentation. 4.relay, if it was listed in the LOCATOR parameter in the base exchange. If control messages are sent through a HIP relay server, the sender MUST include a RELAY_TO parameter to them. Also the HIP relay server MUST add a RELAY_FROM parameter to the control messages it relays. 5. Packet Formats The following subsections define the parameter and packet encodings.encodings for the HIP, ESP and ICE connectivity check packets. All values MUST be in network byte order. 184.108.40.206. HIP Control Packets 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 32 bits of zeroes | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ HIP Header and Parameters ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4:5: Format forof UDP-encapsulated HIP Control Packets HIP control packets are encapsulated in UDP packets as defined in Section 2.2 of [RFC3948], "rules for encapsulating IKE messages"messages", except fora different port number.number is used. Figure 45 illustrates the encapsulation. The UDP header is followed by 32 zero bits that can be used to differentiate HIP control packets from ESP packets. The HIP header and parameters follow the conventions of [RFC5201] with the exception that the HIP header checksum MUST be zero. The HIP header checksum is zero for two reasons. First, the UDP header contains already a checksum. Second, the checksum definition in [RFC5201] includes the IP addresses in the checksum calculation. The NATs unaware of HIP cannot recompute the HIP checksum after changing IP addresses. A HIP Relayrelay server or a Responder without a relay MUST listen at transportUDP port HIPPORT for incoming UDP-encapsulatedUDP encapsulated HIP control packets. 220.127.116.11. Connectivity Checks The connectivity checks are performed using STUN Binding Requests.Requests as defined in [I-D.ietf-mmusic-ice]. This section describes the details of the parameters in the STUN messages. The Binding Requests MUST use STUN short term credentials with HITs of the Initiator and Responder as the username fragments. The username is formed from the username fragments as defined in sectionSection 18.104.22.168 of [I-D.ietf-mmusic-ice]. The requests MUST use STUN short term credentials[I-D.ietf-mmusic-ice] with HITs ofthe Initiator being the "offerer" and the Responder concatenated as a username fragment.being the "answerer". The HITs are concatenated according to the Sort(HIT-I, HIT-R) algorithm definedused as usernames by expressing them in [RFC5201] section 6.5. TheIPv6 hexadecimal ASCII format [RFC1884], using lowercase letters, each 16 bit HIT usernamefragment MUST containseparated by a UTF-8 [RFC3629] encoded sequence and MUST have been processed using SASLPrep [RFC4013] as defined section 15.3 of [I-D.ietf-behave-rfc3489bis].one byte colon (hex 0x3a). The concatenated HIT pairleading zeroes MUST have a fixed sizeNOT be omitted so that is accomplished by includingthe leading zeroes forusername's size is fixed. The STUN password is drawn from the HITs.DH keying material. Drawing of HIP keys is defined in [RFC5201] sectionSection 6.5 and drawing of ESP keys in [RFC5202] sectionSection 7. Correspondingly, the hosts MUST draw symmetric keys for STUN according to [RFC5201] sectionSection 6.5. The hosts draw the STUN keyskey after HIP keys, or after ESP keys if ESP transform was successfully negotiated in the base exchange. The hosts draw two keys which they MUST use to generate the STUN password. As the STUN password is the same at both ends, the two drawn keys MUST be concatenated with theBoth hosts draw a 128 bit key forfrom the greater HIT first. Section 15.4 of [I-D.ietf-behave-rfc3489bis]DH keying material, express that in hexadecimal ASCII format using only lowercase letters (resulting in 32 numbers or lowercase letters), and use that as both the local and peer password. [RFC5389] describes how hosts use the password for message integrity of STUN messages. Both the username and password are expressed in ASCII hexadecimal format to prevent the need to run them through SASLPrep as defined in [RFC5389]. The connectivity checks MUST contain PRIORITY attribute. They MAY contain USE-CANDIDATE attributesattribute as defined in sectionSection 22.214.171.124 of [I-D.ietf-mmusic-ice]. The Initiator is always in the controller role during a base exchange. Hence, the ICE-CONTROLLED and ICE-CONTROLLING attributes are not needed and SHOULD NOT be used. When two hosts are initiating a connection to each other simultaneously, HIP state machine detects it and assigns the host with the larger HIT as the Responder as explained in sectionsSections 4.4.2 and and6.7 in [RFC5201]. 126.96.36.199. Keepalives The keepalives for HIP associations agreedthat are NAT_TRANSFORM capablecreated with ICE are STUN Binding Indications, as defined in [I-D.ietf-behave-rfc3489bis]. The source and destination ports are in the UDP header are the same as used for HIP (50500). However, in[RFC5389]. In contrast to the UDP encapsulated HIP header, therethe non-ESP-marker between the UDP header and the STUN header is excluded. Keepalives MUST contain the FINGERPRINT STUN attribute but SHOULD NOT contain any other STUN attributes and SHOULD NOT utilize any authentication mechanism. STUN messages are demultiplexed from ESP and HIP control messages using the STUN markers, such as the magic cookie value and the FINGERPRINT attribute. Keepalives for aHIPHIP associations created without ICE are HIP control messages that have NOTIFY as the packet type. The NOTIFY messages do not contain any parameters. 5.4. NAT Traversal Mode Parameter Format of the NAT_TRAVERSAL_MODE parameter is similar to the format of the ESP_TRANSFORM parameter in [RFC5202] and is shown in the Figure 6. This specification defines traversal mode identifiers UDP- ENCAPSULATION and ICE-STUN-UDP. The identifier RESERVED is reserved for future use. Future specifications may define more traversal modes. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Mode ID #1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mode ID #2 | Mode ID #3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mode ID #n | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type [ TBD by IANA: 608 ] Length length in octets, excluding Type, Length, and padding Reserved zero when sent, ignored when received Mode ID defines the NAT traversal mode to be used The following NAT traversal mode IDs are defined: ID Value RESERVED 0 UDP-ENCAPSULATION 1 ICE-STUN-UDP 2 Figure 6: Format of the NAT_TRAVERSAL_MODE parameter The sender of a NAT_TRAVERSAL_MODE parameter MUST make sure that there are not NAT_TRANSFORM capable are HIP control messages that have NOTIFY asno more than six (6) Mode IDs in one NAT_TRAVERSAL_MODE parameter. The limited number of Mode IDs sets the packet type.maximum size of the NAT_TRAVERSAL_MODE parameter. 5.5. Connectivity Check Transaction Pacing Parameter The NOTIFY messages do not contain any parameters. 4.4. Relay and Registration ParametersTRANSACTION_PACING parameter shown in Figure 7 contains only the connectivity check pacing value, expressed in milliseconds, as 32 bit unsigned integer. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Address | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Port | TransportMin Ta | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type [ TBD by IANA: REG_FROM: (64010 = 2^16 - 2^11 + 2^9 + 10)610 ] Length 20 Address An IPv6 address or an IPv4 addresslength in "IPv4-compatible IPv6 address" format Port Transport port number; zero when plain IP is used Transport Transport protocol type; zero for UDPoctets, excluding Type and Length Min Ta the minimum connectivity check transaction pacing value the host would use Figure 5:7: Format of the TRANSACTION_PACING parameter 5.6. Relay and Registration Parameters Format of the REG_FROM, RELAY_FROM and RELAY_TO parameters is shown in Figure 8. All parameters are identical except for the type. REG_FROM is the only parameter covered with the signature. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Port | Protocol | Address |Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Address | Port| Transport| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Nonce| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type [ TBD by IANA: Critical parameters:REG_FROM: 950 RELAY_FROM: (63998 = 2^1663998 (2^16 - 2^11 + 2^9 - 2) RELAY_TO: (64002 = 2^1664002 (2^16 - 2^11 + 2^9 + 2) ] Length 2420 Port transport port number; zero when plain IP is used Protocol IANA assigned, Internet Protocol number. 17 for UDP, 0 for plain IP. Reserved reserved for future use; zero when sent, ignored when received Address Anan IPv6 address or an IPv4 address in "IPv4-compatible"IPv4-Mapped IPv6 address" format Port Transport port number; zero when plain IP is used Transport Transport protocol type; zero for UDP Nonce A nonce assigned by the Relay server.Figure 6:8: Format forof the REG_FROM, RELAY_FROM and RELAY_TO parameters Format for theREG_FROM parameter is shown in Figure 5, and RELAY_FROM and RELAY_TO in Figure 6. Parameters are identical except forcontains the type and nonce fields. The nonce field is an experimental field fortransport address and protocol where the HIP relay server sees the registration coming from. RELAY_FROM and RELAY_TO parameters. It allowscontains the Relay to have constant state towardsaddress where the Initiators without allowingrelayed packet was received from by the Responder to send R1 or R2 packets to arbitrary hosts throughrelay server and the Relay. 4.5.protocol that was used. The RELAY_TO contains same information about the address where a packet should be forwarded to. 5.7. LOCATOR Parameter The generic LOCATOR parameter format is the same as in [RFC5206]. However, presenting ICE candidates requires a new locator type. The generic and NAT traversal specific locator parameters are illustrated in Figure 7.9. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Traffic Type | Locator Type | Locator Length| Reserved |P| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Locator Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Locator | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Traffic Type | Loc Type = 2 | Locator Length| Reserved |P| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Locator Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Transport Port | Transp. Proto| Kind | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Priority | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SPI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Locator | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 7:9: LOCATOR parameter The individual fields in the LOCATOR parameter are described in Table 2. +-----------+----------+--------------------------------------------+ | Field | Value(s) | Purpose | +-----------+----------+--------------------------------------------+ | Type | 193 | Parameter type | | Length | Variable | Length in octets, excluding Type and | | | | Length fields and padding | | Traffic | 0-2 | Is the locator for HIP signaling (1), for | | Type | | ESP (2), or for both (0) | | Locator | 2 | "Transport address" locator type | | Type | | | | Locator | 7 | Length of the fields after Locator field in 4-octet| | Length | | Lifetime in 4-octet units | | Reserved | 0 | Reserved for future extensions | | Preferred | 0 | Not used for transport address locators; | | (P) bit | | MUST be ignored by the receiver. | | Locator | Variable | Locator lifetime in seconds | | Lifetime | | | | Transport | Variable | Transport layer port number | | Port | | | | Transport | 0Variable | 0 for UDPIANA Assigned, transport layer Internet | | Protocol | | Protocol number. Currently only UDP (17) | | | | is supported. | | Kind | Variable | 0 for host, 1 for server reflexive, 2 for | | | | peer reflexive or 3 for relayed address | | Priority | Variable | Locator's priority as described in | | | | [I-D.ietf-mmusic-ice] | | SPI | Variable | SPI value which the host expects to see in | | | | incoming ESP packets that use this locator | | Locator | Variable | IPv6 address or an "IPv4-compatible"IPv4-Mapped IPv6 | | | | address" format IPv4 address [RFC3513], | | | | obfuscated by XORing it with the owner's | | | | HIT[RFC3513] | +-----------+----------+--------------------------------------------+ Table 2: Fields of the LOCATOR parameter 188.8.131.52. RELAY_HMAC Parameter The RELAY_HMAC parameter value has the TLV type 65520 (2^16 - 2^5 + 2^4). It has the same semantics as RVS_HMAC [RFC5204]. 184.108.40.206. Registration Types The REG_INFO, REQ_REQ,REG_REQ, REG_RESP and REG_FAILED parameters contain values for HIP Relayrelay server registration. The value for RELAY_UDP_HIP is 2. The value for RELAY_UDP_ESP is 3. 220.127.116.11. ESP Data Packets [RFC3948] describes UDP encapsulation of the IPsec ESP transport and tunnel mode. On the wire, the HIP ESP packets do not differ from the transport mode ESP and thus the encapsulation of the HIP ESP packets is same as the UDP encapsulation transport mode ESP. However, the (semantic) difference to BEET mode ESP packets used by HIP is that IP header is not used in BEET integrity protection calculation. 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 [RFC5202]. When two peers perform a UDP-encapsulated base exchange, they MUST define a pair of IPsec SAs that produces UDP-encapsulated ESP data traffic. The management of encryption/authentication protocols and SPIs is defined in [RFC5202]. The UDP encapsulation format and processing of HIP ESP traffic is described in Section 6.1 of [RFC5202]. 5.6. Security Considerations 18.104.22.168. Privacy Considerations The locators are in XORed format inplain text format in favor of inspection at HIP-awareHIP- aware middleboxes in the future. The current draft does not specify encrypted versions of LOCATORs even though it could be beneficial for privacy reasons. It is possible that an Initiator or Responder may not want to reveal all of its locators to its peer. For example, a host may not want to reveal the internal topology of the private address realm and it discards host addresses. Such behavior creates non-optimal paths when the hosts are located behind the same NAT. Especially, this could be a problem with a legacy NAT that does not support routing from the private address realm back to itself through the outer address of the NAT. This scenario is referred to as the hairpin problem [RFC5128]. With such a legacy NAT, the only option left would be to use a relayed transport address from a TURN server. As a consequence, a host may support locator-based privacy by leaving out the reflexive candidates. However, the trade-off in using only host candidates can produce suboptimal paths that can congest the TURN server. The use of HIP Relaysrelay servers or TURN Relaysrelays can be also useful for protection against Denial-of-Service attacks. If a Responder reveals only its HIP Relayrelay server addresses and Relayed transportcandidates to Initiators, the Initiators can only attack the relays thatrelays. That does not prevent the Responder from initiating new outgoing connections if a path around the relay exists. 22.214.171.124. Opportunistic Mode A HIP Relayrelay server should have one address per Relay Clientrelay client when a HIP Relayrelay is serving more than one Relay Clientsrelay clients and supports opportunistic mode. Otherwise, it cannot be guaranteed that the RelayHIP relay server can deliver the I1 packet to the intended recipient. 126.96.36.199. Base Exchange Replay Protection for HIP Relay Server OnIn certain scenarios, it is possible that an attacker, or two attackers, can replay an earlier base exchange through a RelayHIP relay server by masquerading as the original Initiator and Responder. The attack does not require the attacker(s) to compromise the private key(s) of the attacked host(s). However, for this attack to succeed, the Responder has to be disconnected from the Relay in order to masquarade successfully as the Responder.HIP relay server. The Relayrelay can protect itself against Replayreplay attacks by involving in the base exchange by introducing nonces that the end-hosts (Initiator and Responder) have to sign. The Relay MAYOne way to do this is to add ECHO_REQUEST_M parameters to the R1 and I2 messages as described in [I-D.heer-hip-middle-auth] and dropsdrop the I2 or R2 messages if the corresponding ECHO_RESPONSE_M parameters are not present. 188.8.131.52. Demuxing Different HIP Associations Section 5.1 of [RFC3948] describes a security issue for the UDP encapsulation in the 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 two hosts, because security associations are based on the same inner IP addresses. This issue does not exist with the UDP encapsulation of HIP ESP transport format because the Responder useuses HITs to distinguish between different Initiators. 6.7. IANA Considerations This section is to be interpreted according to [RFC2434]. This draft currently uses a UDP port in the "Dynamic and/or Private Port" and HIPPORT. Upon publication of this document, IANA is requested to register a UDP port and the RFC editor is requested to change all occurrences of port HIPPORT to the port IANA has registered. The HIPPORT number 50500 should be used for initial experimentation. This document updates the IANA Registry for HIP Parameter Types by assigning new HIP Parameter Type values for the new HIP Parameters: RELAY_FROM, RELAY_TO and REG_FROM (defined in Section 4.4) and5.6), RELAY_HMAC (defined in Section 4.6). NAT_TRANSFORM is also a new parameter. 7.5.8), TRANSACTION_PACING (defined in Section 5.5), and NAT_TRAVERSAL_MODE (defined in Section 5.4). 8. Contributors This draft is a product of a design team which also included Marcelo Bagnulo and Jan Melen who both have made major contributions to this document. 8.9. Acknowledgments Thanks for Jonathan Rosenberg and the rest of the MMUSIC WG folks for the excellent work on ICE. In addition, the authors would like to thank Andrei Gurtov, Simon Schuetz, Martin Stiemerling, Lars Eggert, Vivien Schmitt, Abhinav Pathak for their contributions and Tobias Heer, Teemu Koponen, Juhana Mattila, Jeffrey M. Ahrenholz, Thomas Henderson,Kristian Slavov, Janne Lindqvist, Pekka Nikander, Lauri Silvennoinen, Jukka Ylitalo, Juha Heinanen, Joakim Koskela, Samu Varjonen, Dan Wing and Jani Hautakorpi for their comments on this document. Miika Komu is working in the Networking Research group at Helsinki Institute for Information Technology (HIIT). The InfraHIP project was funded by Tekes, Telia-Sonera, Elisa, Nokia, the Finnish Defence Forces, and Ericsson and Birdstep. 9.10. References 184.108.40.206. Normative References [I-D.ietf-behave-rfc3489bis] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session Traversal Utilities for (NAT) (STUN)", draft-ietf-behave-rfc3489bis-16 (work in progress), July 2008.[I-D.ietf-behave-turn] Rosenberg, J., Mahy, R., and P. Matthews, "Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)", draft-ietf-behave-turn-08draft-ietf-behave-turn-11 (work in progress), JuneOctober 2008. [I-D.ietf-mmusic-ice] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", draft-ietf-mmusic-ice-19 (work in progress), October 2007. [I-D.rosenberg-mmusic-ice-nonsip] Rosenberg, J., "NICE: Non Session Initiation Protocol (SIP) usage of Interactive Connectivity Establishment (ICE)", draft-rosenberg-mmusic-ice-nonsip-00Offer/Answer Protocols", draft-ietf-mmusic-ice-19 (work in progress), February 2008.October 2007. [RFC1884] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 1884, December 1995. [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. [RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) Addressing Architecture", RFC 3513, April 2003. [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003. [RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User Names and Passwords", RFC 4013, February 2005.[RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol (HIP) Architecture", RFC 4423, May 2006. [RFC5201] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson, "Host Identity Protocol", RFC 5201, April 2008. [RFC5202] Jokela, P., Moskowitz, R., and P. Nikander, "Using the Encapsulating Security Payload (ESP) Transport Format with the Host Identity Protocol (HIP)", RFC 5202, April 2008. [RFC5203] Laganier, J., Koponen, T., and L. Eggert, "Host Identity Protocol (HIP) Registration Extension", RFC 5203, April 2008. [RFC5204] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) Rendezvous Extension", RFC 5204, April 2008. [RFC5206] Nikander, P., Henderson, T., Vogt, C., and J. Arkko, "End- Host Mobility and Multihoming with the Host Identity Protocol", RFC 5206, April 2008. 9.2.[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session Traversal Utilities for NAT (STUN)", RFC 5389, October 2008. 10.2. Informative References [I-D.heer-hip-middle-auth] Heer, T., Wehrle, K., and M. Komu, "End-Host Authentication for HIP Middleboxes", draft-heer-hip-middle-auth-01 (work in progress), July 2008. [I-D.irtf-hiprg-nat] Stiemerling, M., "NAT and Firewall Traversal Issues of Host Identity Protocol (HIP) Communication", draft-irtf-hiprg-nat-04 (work in progress), March 2007. [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. Stenberg, "UDP Encapsulation of IPsec ESP Packets", RFC 3948, January 2005. [RFC4787] Audet, F. and C. Jennings, "Network Address Translation (NAT) Behavioral RequirementsMiddleboxes", draft-heer-hip-middle-auth-01 (work in progress), July 2008. [I-D.rosenberg-mmusic-ice-nonsip] Rosenberg, J., "Guidelines for Usage of Interactive Connectivity Establishment (ICE) by non Session Initiation Protocol (SIP) Protocols", draft-rosenberg-mmusic-ice-nonsip-01 (work in progress), July 2008. [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. Stenberg, "UDP Encapsulation of IPsec ESP Packets", RFC 3948, January 2005. [RFC4787] Audet, F. and C. Jennings, "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP", BCP 127, RFC 4787, January 2007. [RFC5128] Srisuresh, P., Ford, B., and D. Kegel, "State of Peer-to- Peer (P2P) Communication across Network Address Translators (NATs)", RFC 5128, March 2008. [RFC5207] Stiemerling, M., Quittek, J., and L. Eggert, "NAT and Firewall Traversal Issues of Host Identity Protocol (HIP) Communication", RFC 5207, April 2008. Appendix A. Selecting a Value for Check Pacing Selecting a suitable value for the connectivity check transaction pacing is essential for the performance of connectivity check-based NAT traversal. The value should not be too small so that the checks do not cause congestion in the network or overwhelm the NATs. On the other hand, too high pacing value makes the checks last for a long time and thus increase the connection setup delay. The Ta value may be configured by the user in environments where the network characteristics are known beforehand. However, if the characteristics are not know, it is recommended that the value is adjusted dynamically. In this case it's recommended that the hosts estimate the RTT between them and set the minimum Ta value so that only two connectivity check messages are sent on every RTT. One way to estimate the RTT is to use the time it takes for the HIP relay server registration exchange to complete; this would give an estimate on the registering host's access link's RTT. Also the I1/R1 exchange could be used for Unicast UDP", BCP 127, RFC 4787, January 2007. [RFC5128] Srisuresh, P., Ford, B., and D. Kegel, "State of Peer-to- Peer (P2P) Communication across Network Address Translators (NATs)", RFC 5128, March 2008.estimating the RTT, but since the R1 can be cached in the network, or the relaying service can increase the delay notably, it is not recommended. Appendix A.B. IPv4-IPv6 Interoperability Currently Relay Clientrelay client and Serverserver do not have to run any ICE connectivity tests as described in Section 220.127.116.11. However, it could be useful for IPv4-IPv6 interoperability when the Relay ServerHIP relay server actually includes both the NAT transformtraversal mode parameter and multiple locators in R2. The interoperability benefit is that the Relayrelay could support IPv4-based Initiators and IPv6-based Responders by converting the network headers and recalculating UDP checksums. Such an approach is underspecified in this document currently. It is not yet recommended because it may consume resources at the Relayrelay and requires also similar conversion support at the TURN relay for data packets. Appendix B.C. Base Exchange through a Rendezvous Server This section describes handling for a scenario whereWhen the Initiator looks up the information of the Responder from DNS andDNS, it's possible that it discovers aan RVS record [RFC5204]. In such athis case, if the Initiator uses NAT traversal methods described in this document, it uses its own HIP Relayrelay server to forward HIP traffic to the Rendezvous server. The Initiator will send the I1 message using theits HIP Relayrelay server which will then forward it to the RVS server of the responder.Responder. In this case, the value of the protocol field in the RELAY_TO parameter MUST be IP since RVS does not support UDP encapsulated base exchange packets. The responderResponder will send the R1 packet directly to the Initiator's HIP Relayrelay server and the following I2 and R2 packets are also sent directly using the Relay.relay. In case the Initiator is not able to distinguish which records are RVS address records and which are RespondersResponder's address records, thenrecords (e.g., if the DNS server did not support HIP extensions), the Initiator SHOULD first try to contact the Responder directly and ifdirectly, without using a HIP relay server. If none of the addresses is reachablereachable, it MAY try out them using its own HIP Relayrelay server as described in theabove. Appendix C.D. Document Revision History To be removed upon publication +-----------------------------+-------------------------------------+ | Revision | Comments | +-----------------------------+-------------------------------------+ | draft-ietf-nat-traversal-00 | Initial version. | | draft-ietf-nat-traversal-01 | Draft based on RVS. | | draft-ietf-nat-traversal-02 | Draft based on Relay proxies and | | | ICE concepts. | | draft-ietf-nat-traversal-03 | Draft based on STUN/ICE formats. | | draft-ietf-nat-traversal-04 | Issues 25-27,29-36 | | draft-ietf-nat-traversal-05 | Issues 28,40-43,47,49,51 | +-----------------------------+-------------------------------------+ Authors' Addresses Miika Komu Helsinki Institute for Information Technology Metsanneidonkuja 4 Espoo Finland Phone: +358503841531 Fax: +35896949768 Email: email@example.com URI: http://www.hiit.fi/ Thomas Henderson The Boeing Company P.O. Box 3707 Seattle, WA USA Email: firstname.lastname@example.org Philip Matthews (Unaffiliated) Email: email@example.com Hannes Tschofenig Nokia Siemens Networks Linnoitustie 6 Espoo 02600 Finland Phone: +358 (50) 4871445 Email: Hannes.Tschofenig@gmx.net URI: http://www.tschofenig.com Ari KeraenenKeranen (editor) Ericsson Research Nomadiclab Hirsalantie 11 02420 Jorvas Finland Phone: +358 9 2991 Email: firstname.lastname@example.org Full Copyright Statement Copyright (C) The IETF Trust (2008). 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, THE IETF TRUST 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 email@example.com.