diff options
Diffstat (limited to 'doc/rfc/rfc5770.txt')
| -rw-r--r-- | doc/rfc/rfc5770.txt | 1907 |
1 files changed, 1907 insertions, 0 deletions
diff --git a/doc/rfc/rfc5770.txt b/doc/rfc/rfc5770.txt new file mode 100644 index 0000000..a0f2a09 --- /dev/null +++ b/doc/rfc/rfc5770.txt @@ -0,0 +1,1907 @@ + + + + + + +Internet Engineering Task Force (IETF) M. Komu +Request for Comments: 5770 HIIT +Category: Experimental T. Henderson +ISSN: 2070-1721 The Boeing Company + H. Tschofenig + Nokia Siemens Networks + J. Melen + A. Keranen, Ed. + Ericsson Research Nomadiclab + April 2010 + + + Basic Host Identity Protocol (HIP) Extensions for + Traversal of Network Address Translators + +Abstract + + This document specifies extensions to the Host Identity Protocol + (HIP) to facilitate Network Address Translator (NAT) traversal. The + extensions are based on the use of the Interactive Connectivity + Establishment (ICE) methodology to discover a working path between + two 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 a 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. + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for examination, experimental implementation, and + evaluation. + + This document defines an Experimental Protocol for the Internet + community. This document is a product of the Internet Engineering + Task Force (IETF). It represents the consensus of the IETF + community. It has received public review and has been approved for + publication by the Internet Engineering Steering Group (IESG). Not + all documents approved by the IESG are a candidate for any level of + Internet Standard; see Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc5770. + + + + + +Komu, et al. Experimental [Page 1] + +RFC 5770 Basic NAT Traversal for HIP April 2010 + + +Copyright Notice + + Copyright (c) 2010 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + + This document may contain material from IETF Documents or IETF + Contributions published or made publicly available before November + 10, 2008. The person(s) controlling the copyright in some of this + material may not have granted the IETF Trust the right to allow + modifications of such material outside the IETF Standards Process. + Without obtaining an adequate license from the person(s) controlling + the copyright in such materials, this document may not be modified + outside the IETF Standards Process, and derivative works of it may + not be created outside the IETF Standards Process, except to format + it for publication as an RFC or to translate it into languages other + than English. + + + + + + + + + + + + + + + + + + + + + + + + + +Komu, et al. Experimental [Page 2] + +RFC 5770 Basic NAT Traversal for HIP April 2010 + + +Table of Contents + + 1. Introduction ....................................................4 + 2. Terminology .....................................................6 + 3. Overview of Operation ...........................................7 + 4. Protocol Description ............................................8 + 4.1. Relay Registration .........................................8 + 4.2. ICE Candidate Gathering ...................................10 + 4.3. NAT Traversal Mode Negotiation ............................10 + 4.4. Connectivity Check Pacing Negotiation .....................12 + 4.5. Base Exchange via HIP Relay Server ........................12 + 4.6. ICE Connectivity Checks ...................................15 + 4.7. NAT Keepalives ............................................16 + 4.8. Base Exchange without ICE Connectivity Checks .............16 + 4.9. Initiating a Base Exchange Both with and without + UDP Encapsulation .........................................17 + 4.10. Sending Control Packets after the Base Exchange ..........18 + 5. Packet Formats .................................................18 + 5.1. HIP Control Packets .......................................19 + 5.2. Connectivity Checks .......................................19 + 5.3. Keepalives ................................................20 + 5.4. NAT Traversal Mode Parameter ..............................21 + 5.5. Connectivity Check Transaction Pacing Parameter ...........22 + 5.6. Relay and Registration Parameters .........................22 + 5.7. LOCATOR Parameter .........................................23 + 5.8. RELAY_HMAC Parameter ......................................25 + 5.9. Registration Types ........................................25 + 5.10. Notify Packet Types ......................................26 + 5.11. ESP Data Packets .........................................26 + 6. Security Considerations ........................................27 + 6.1. Privacy Considerations ....................................27 + 6.2. Opportunistic Mode ........................................27 + 6.3. Base Exchange Replay Protection for HIP Relay Server ......28 + 6.4. Demuxing Different HIP Associations .......................28 + 7. IANA Considerations ............................................28 + 8. Contributors ...................................................29 + 9. Acknowledgments ................................................29 + 10. References ....................................................29 + 10.1. Normative References .....................................29 + 10.2. Informative References ...................................30 + Appendix A. Selecting a Value for Check Pacing ....................32 + Appendix B. Base Exchange through a Rendezvous Server .............33 + + + + + + + + + +Komu, et al. Experimental [Page 3] + +RFC 5770 Basic NAT Traversal for HIP April 2010 + + +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 and other + middleboxes [RFC5207]. This document defines 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 a network + that is behind one or more NATs. + + Using the extensions defined in this document, HIP end-hosts use + techniques drawn from the Interactive Connectivity Establishment + (ICE) methodology [RFC5245] to find operational paths 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 them. However, with some legacy NATs, + utilizing the shortest path between two end-hosts located behind NATs + is not possible without relaying the traffic through a relay, such as + a Traversal Using Relay NAT (TURN) server [RFC5128]. Because + relaying traffic increases the roundtrip delay and consumes resources + from the relay, with the extensions described in this document, hosts + try to avoid using the TURN server whenever 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 extensions to the rendezvous server that solve the + same problems, but for both NATed and non-NATed networks. The + extended rendezvous server, called a "HIP relay server", forwards HIP + control packets between an Initiator and a Responder, allowing hosts + to be located behind NATs. This behavior is in contrast to the HIP + rendezvous service that forwards only the initial I1 packet of the + base exchange; an approach that is less likely to work in a NATed + environment [RFC5128]. Therefore, when using relays to traverse + NATs, HIP uses a HIP relay server for the control traffic and a TURN + server for the data traffic. + + The basis for the connectivity checks is ICE [RFC5245]. [RFC5245] + describes ICE as follows: + + + +Komu, et al. Experimental [Page 4] + +RFC 5770 Basic NAT Traversal for HIP April 2010 + + + 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 [Simple + Traversal of the UDP Protocol through NAT (STUN)] specification + [RFC5389], now renamed to Session Traversal Utilities for NAT. + + The standard ICE [RFC5245] is specified with SIP in mind and it has + some features that are not necessary or suitable as such for other + protocols. [MMUSIC-ICE] gives instructions and recommendations on + how ICE can be used for other protocols and this document follows + those guidelines. + + Two HIP hosts that implement this specification communicate their + locators to each other in the HIP base exchange. The locators are + then paired with the locators of the other endpoint and prioritized + according to recommended and local policies. These locator pairs are + then tested sequentially by both of the end-hosts. The tests may + result in multiple operational pairs but ICE procedures determine a + single preferred address pair to be used for subsequent + communication. + + In summary, the extensions in this document define: + + o UDP encapsulation of HIP packets + + o UDP encapsulation of IPsec ESP packets + + o registration extensions for HIP relay 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 omitted) + + + + + + + + + +Komu, et al. Experimental [Page 5] + +RFC 5770 Basic NAT Traversal for HIP April 2010 + + +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], [RFC5245], and [RFC5389]. Additionally, the following + terms are used: + + Rendezvous server: + A host that forwards I1 packets to the Responder. + + HIP relay server: + A host that forwards any kind of HIP control packets between the + Initiator and the Responder. + + TURN server: + A server that forwards data traffic between two end-hosts as + defined in [RFC5766]. + + Locator: + As defined in [RFC5206]: "A name that controls how the packet is + routed through the network and demultiplexed by the 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." + + LOCATOR (written in capital letters): + Denotes a HIP control packet parameter that bundles multiple + locators together. + + ICE offer: + The Initiator's LOCATOR parameter in a HIP I2 control packet. + + ICE answer: + The Responder's LOCATOR parameter in a HIP R2 control packet. + + Transport address: + Transport layer port and the corresponding IPv4/v6 address. + + Candidate: + A transport address that is a potential point of contact for + receiving data. + + + + + + +Komu, et al. Experimental [Page 6] + +RFC 5770 Basic NAT Traversal for HIP April 2010 + + + Host candidate: + A candidate 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 + relay server or a STUN/TURN server. + + Peer reflexive candidate: + A translated transport address of a host as observed by its peer. + + Relayed candidate: + 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 the 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 Host Identity Tag (HIT) and the + + + + + +Komu, et al. Experimental [Page 7] + +RFC 5770 Basic NAT Traversal for HIP April 2010 + + + 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. The hosts may use TURN and STUN servers for + gathering the 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. + +4.1. 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 server, for operating in + NATed environments. A HIP relay server forwards HIP control packets + between the Initiator and the Responder. + + + + +Komu, et al. Experimental [Page 8] + +RFC 5770 Basic NAT Traversal for HIP April 2010 + + + End-hosts cannot use the HIP relay service for forwarding the ESP + data plane. Instead, they use TURN servers [RFC5766]. + + A HIP relay server MUST silently drop packets to a HIP relay client + that has not previously registered with the HIP relay. The + registration process follows the generic registration extensions + defined in [RFC5203] and is illustrated in Figure 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 2: Example Registration with a HIP Relay + + In step 1, the relay client (Initiator) starts the registration + procedure by sending an I1 packet over UDP. It is RECOMMENDED that + the Initiator select a random port number from the ephemeral port + range 49152-65535 for initiating a base exchange. Alternatively, a + host MAY also use a single fixed port for initiating all outgoing + connections. However, the allocated port MUST be maintained until + all of the corresponding HIP Associations are closed. It is + RECOMMENDED that the HIP relay server listen to incoming connections + at UDP port 10500. If some other port number is used, it needs to be + known by potential Initiators. + + In step 2, the HIP relay server (Responder) lists the services that + it supports in the R1 packet. The support for HIP-over-UDP relaying + is denoted by the Registration Type value RELAY_UDP_HIP (see + Section 5.9). + + In step 3, the Initiator selects the services for which it registers + and lists them in the REG_REQ parameter. The Initiator registers for + HIP relay service by listing the RELAY_UDP_HIP value in the request + parameter. + + + + + +Komu, et al. Experimental [Page 9] + +RFC 5770 Basic NAT Traversal for HIP April 2010 + + + 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 of R2. The Responder also includes a + REG_FROM parameter that contains the transport address of the client + as observed by the relay (Server Reflexive candidate). After the + registration, the client sends NAT keepalives, as described in + Section 4.7, periodically to the relay to keep possible NAT bindings + between the client and the relay alive. The relay client maintains + the HIP association with the relay server as long as it requires + relaying service from it. + +4.2. ICE Candidate Gathering + + If a host is going to use ICE, it needs to gather a set of address + candidates. The candidate gathering SHOULD be done as defined in + Section 4.1 of [RFC5245]. Candidates need to be gathered for the + UDP-encapsulated flow of HIP and ESP traffic. This flow corresponds + to one ICE media stream and component. Since ICE component IDs are + not needed, they are not explicitly signaled and ID value of 1 SHOULD + be used for ICE processing, where needed. The Initiator takes the + role of the ICE controlling agent. + + The candidate gathering can be done at any time, but it needs to be + done before sending an I2 or R2 in the base exchange if ICE is to be + used for the connectivity checks. It is RECOMMENDED that all three + types of candidates (host, server reflexive, and relayed) are + gathered to maximize the 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 the + only host candidate and the address from the REG_FROM parameter + discovered during the relay registration as a server reflexive + candidate. In this case, no further candidate gathering is needed. + +4.3. NAT Traversal Mode Negotiation + + This section describes the usage of a new non-critical parameter + type. The presence of the parameter in a HIP base exchange means + that the end-host supports NAT traversal extensions described in this + document. As the parameter is non-critical (as defined in Section + 5.2.1 of [RFC5201]), it can be ignored by an end-host, which means + that the host does not support or is not willing to use these + extensions. + + With registration with a HIP relay, it is usually sufficient to use + the UDP-ENCAPSULATION mode of NAT traversal since the relay is + assumed to be in public address space. Thus, the relay SHOULD + propose the UDP-ENCAPSULATION mode as the preferred or only mode. + + + +Komu, et al. Experimental [Page 10] + +RFC 5770 Basic NAT Traversal for HIP April 2010 + + + The NAT traversal mode negotiation in a HIP base exchange is + illustrated in Figure 3. + + Initiator Responder + | 1. UDP(I1) | + +--------------------------------------------------------------->| + | | + | 2. UDP(R1(.., NAT_TRAVERSAL_MODE(list of modes), ..)) | + |<---------------------------------------------------------------+ + | | + | 3. UDP(I2(.., NAT_TRAVERSAL_MODE(selected mode), LOCATOR, ..)) | + +--------------------------------------------------------------->| + | | + | 4. UDP(R2(.., LOCATOR, ..)) | + |<---------------------------------------------------------------+ + | | + + Figure 3: Negotiation of NAT Traversal Mode + + In step 1, the Initiator sends an I1 to the Responder. In step 2, + the Responder responds with an R1. The NAT_TRAVERSAL_MODE parameter + in R1 contains a list of NAT traversal modes the Responder supports. + The modes specified in this document are shown in Table 1 and their + values are specified in Section 5.4. + + +-------------------+-----------------------------------------------+ + | 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 ICE-based connectivity checks using STUN | + | | messages | + +-------------------+-----------------------------------------------+ + + Table 1: NAT Traversal Modes + + In step 3, the Initiator sends an I2 that includes a + NAT_TRAVERSAL_MODE parameter. It contains the mode selected by the + Initiator from the list of modes offered by the Responder. If ICE + mode was selected, the I2 also includes the "Transport address" + locators (as defined in Section 5.7) of the Initiator in a LOCATOR + parameter. The locators in I2 are the "ICE offer". + + + + +Komu, et al. Experimental [Page 11] + +RFC 5770 Basic NAT Traversal for HIP April 2010 + + + In step 4, the Responder concludes the base exchange with an R2 + packet. If the Initiator chose ICE NAT traversal mode, the Responder + includes a LOCATOR parameter in the R2 packet. The locators in R2, + encoded like the locators in I2, are the "ICE answer". If the NAT + traversal mode selected by the Initiator is not supported by the + Responder, the Responder SHOULD reply with a NOTIFY packet with type + NO_VALID_NAT_TRAVERSAL_MODE_PARAMETER and abort the base exchange. + +4.4. Connectivity Check Pacing Negotiation + + As explained in [RFC5245], 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 + R1 and I2 packets. 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 500 ms 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 20 ms for the minimum Ta, + since such values may not work well with some NATs, as explained in + [RFC5245]. The Initiator MUST NOT propose a smaller value than what + the Responder offered. + + The minimum Ta value SHOULD be configurable, and if no value is + configured, a value of 500 ms MUST be used. Guidelines for selecting + a Ta value are given in Appendix A. Currently this feature applies + only to the ICE-STUN-UDP NAT traversal mode, but any other mode using + connectivity checks SHOULD utilize this feature. + +4.5. Base Exchange via HIP Relay Server + + This section describes how the Initiator and Responder perform a base + exchange through a HIP relay server. The NAT traversal mode + negotiation (denoted as NAT_TM in the example) was described in + Section 4.3 and is not repeated here. If a relay receives an R1 or + I2 packet without the NAT traversal mode parameter, it MUST drop it + and SHOULD send a NOTIFY error packet with type + NO_VALID_NAT_TRAVERSAL_MODE_PARAMETER to the sender of the R1/I2. + + + + + + + +Komu, et al. Experimental [Page 12] + +RFC 5770 Basic NAT Traversal for HIP April 2010 + + + It is RECOMMENDED that the Initiator send 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 a + UDP-encapsulated R1 packet and the rest of the base exchange, I2 and + R2, MUST also use UDP encapsulation. + + Initiator HIP relay Responder + | 1. UDP(I1) | | + +----------------------------->| 2. UDP(I1(RELAY_FROM)) | + | +------------------------------->| + | | | + | | 3. UDP(R1(RELAY_TO, NAT_TM)) | + | 4. UDP(R1(RELAY_TO, NAT_TM)) |<-------------------------------+ + |<-----------------------------+ | + | | | + | 5. UDP(I2(LOCATOR, NAT_TM)) | | + +----------------------------->| 6. UDP(I2(LOCATOR, RELAY_FROM, | + | | NAT_TM)) | + | +------------------------------->| + | | | + | | 7. UDP(R2(LOCATOR, RELAY_TO)) | + | 8. UDP(R2(LOCATOR, RELAY_TO))|<-------------------------------+ + |<-----------------------------+ | + | | | + + Figure 4: Base Exchange via a HIP Relay Server + + In step 1 of Figure 4, the Initiator sends an I1 packet over the + transport layer to the HIT of the Responder and IP address and port + of the HIP relay server. The source address is one of the locators + of the Initiator. + + In step 2, the HIP relay server receives the I1 packet. If the + destination HIT belongs to a registered Responder, the relay + processes the packet. Otherwise, the relay MUST drop the packet + silently. The relay 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. The relay protects the I1 packet with + RELAY_HMAC as described in [RFC5204], except that the parameter type + is different (see Section 5.8). The relay changes the source and + destination ports and IP addresses of the packet to match the values + the Responder used when registering to the relay, i.e., the reverse + of the R2 used in the registration. The relay MUST recalculate the + transport checksum and forward the packet to the Responder. + + + + + + + +Komu, et al. Experimental [Page 13] + +RFC 5770 Basic NAT Traversal for HIP April 2010 + + + 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 RELAY_TO and NAT + traversal mode parameters. The RELAY_TO parameter MUST contain the + same information as the RELAY_FROM parameter, i.e., the Initiator's + transport 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-created R1 packets at the Responder. + + In step 4, the relay receives the R1 packet. The relay drops the + packet silently if the source HIT belongs to an unregistered host. + The relay MAY verify the signature of the R1 packet and drop it if + the signature is invalid. Otherwise, the relay rewrites the source + address and port, and changes the destination address and port to + match RELAY_TO information. Finally, the relay recalculates + transport checksum and forwards the packet. + + In step 5, the Initiator receives the R1 packet and processes it + according to [RFC5201]. The Initiator MAY use the address in the + RELAY_TO parameter as a local peer-reflexive candidate for this HIP + association if it is different from all known local candidates. The + Initiator replies with an I2 packet that uses the destination + transport address of R1 as the source address and port. The I2 + packet 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 5.7. The I2 packet MUST also contain a NAT + traversal mode parameter with the mode the Initiator selected. + + In step 6, the relay receives the I2 packet. The relay appends a + RELAY_FROM and a RELAY_HMAC to the I2 packet as explained in step 2. + + In step 7, the Responder receives the I2 packet and processes it + according to [RFC5201]. It replies with an R2 packet and includes a + RELAY_TO parameter as explained in step 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 relay processes the R2 as described in step 4. The + relay forwards the packet to the Initiator. After the Initiator has + received the R2 and processed it successfully, the base exchange is + completed. + + Hosts MUST include the address of one or more HIP relay servers + (including the one that is being used for the initial signaling) in + the LOCATOR parameter in I2/R2 if they intend to use such servers for + relaying HIP signaling immediately after the base exchange completes. + + + +Komu, et al. Experimental [Page 14] + +RFC 5770 Basic NAT Traversal for HIP April 2010 + + + The traffic type of these addresses MUST be "HIP signaling" and they + MUST NOT be used as ICE candidates. If the HIP relay server locator + used for the base exchange is not included in I2/R2 LOCATOR + parameters, it SHOULD NOT be used after the base exchange, but + further HIP signaling SHOULD use the same path as the data traffic. + +4.6. ICE Connectivity Checks + + If a HIP relay server was used, the Responder completes the base + exchange with the R2 packet through the relay. However, the + destination address the Initiator and Responder used for the base + exchange packets belongs to the HIP relay server. Therefore, that + address MUST NOT be used as a destination for ESP traffic. Instead, + if a NAT traversal mode with ICE connectivity checks was selected, + the Initiator and Responder MUST start the connectivity checks. + + Creating the checklist for the ICE connectivity checks should be + performed as described in Section 5.7 of [RFC5245] 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 the same + component ID value). The actual connectivity checks MUST be + performed as described in Section 7 of [RFC5245]. Regular mode + SHOULD be used for the candidate nomination. Section 5.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 pair was found. The end-hosts MUST + use this address pair for the ESP traffic. + + 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, a value of 500 ms MUST + be used. + + For retransmissions, the retransmission timeout (RTO) value SHOULD be + calculated as follows: + + RTO = MAX (500ms, Ta * (Num-Waiting + Num-In-Progress)) + + In the RTO formula, Ta is the value used for the connectivity check + pacing, Num-Waiting is the number of pairs in the checklist in the + "Waiting" state, and Num-In-Progress is the number of pairs in the + "In-Progress" state. This is identical to the formula in [RFC5245] + if there is only one checklist. + + + + + + + + +Komu, et al. Experimental [Page 15] + +RFC 5770 Basic NAT Traversal for HIP April 2010 + + + If the ICE connectivity checks failed, the hosts MUST NOT send ESP + traffic to each other but MAY continue communicating using HIP + packets and the locators used for the base exchange. Also, the hosts + SHOULD notify each other about the failure with a + CONNECTIVITY_CHECKS_FAILED NOTIFY packet (see Section 5.10). + +4.7. NAT Keepalives + + To prevent NAT states from expiring, communicating hosts send + periodic keepalives to each other. HIP relay servers MAY refrain + from sending keepalives if it's known that they are not behind 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 a shorter keepalive period. + + The keepalives are STUN Binding Indications if the hosts have agreed + on ICE-STUN-UDP NAT traversal mode during the base exchange. + Otherwise, HIP NOTIFY packets MAY be used as keepalives. + + The communicating hosts MUST send keepalives to each other using the + transport locators they agreed to use for data and signaling when + they are in the ESTABLISHED state. Also, the Initiator MUST send a + NOTIFY packet to the relay to keep the NAT states alive on the path + between the Initiator and relay when the Initiator has not received + any response to its I1 or I2 from the Responder in 15 seconds. + +4.8. 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 a base + exchange acts as an implicit connectivity test itself. For this to + work, the Initiator MUST be able to reach the Responder by simply UDP + encapsulating HIP and ESP packets sent to the Responder's address. + Detecting and configuring this particular scenario is prone to + failure unless carefully planned. + + In such a scenario, the Responder MAY include UDP-ENCAPSULATION NAT + traversal mode as one of the supported modes in the R1 packet. If + the Responder has registered to a HIP relay server, it MUST also + include a LOCATOR parameter in R1 that contains a preferred address + where the Responder is able to receive UDP-encapsulated ESP and HIP + packets. This locator MUST be of type "Transport address", its + Traffic type MUST be "both", and it MUST have the "Preferred bit" set + (see Table 2). If there is no such locator in R1, the source address + of R1 is used as the Responder's preferred address. + + + + + +Komu, et al. Experimental [Page 16] + +RFC 5770 Basic NAT Traversal for HIP April 2010 + + + The Initiator MAY choose the UDP-ENCAPSULATION mode if the Responder + listed it in the supported modes and the Initiator does not wish to + use ICE for searching for a more optimal path. In this case, the + Initiator sends the I2 with UDP-ENCAPSULATION mode in the NAT + traversal mode parameter directly to the Responder's preferred + address (i.e., to the preferred locator in R1 or to the address where + R1 was received from if there was no preferred locator in R1). The + Initiator MAY include locators in I2 but they MUST NOT be taken as + ICE candidates, since ICE will not be used for connections with UDP- + ENCAPSULATION NAT traversal mode. Instead, if R2 and I2 are received + and processed successfully, a security association can be created and + UDP-encapsulated ESP can be exchanged between the hosts after the + base exchange completes. However, the Responder SHOULD NOT send any + ESP to the Initiator's address before it has received data from the + Initiator, as specified in Sections 4.4.2. and 6.9 of [RFC5201] and + in Sections 3.2.9 and 5.4 of [RFC5206]. + + Since an I2 packet with UDP-ENCAPSULATION NAT traversal mode selected + MUST NOT be sent via a relay, the Responder SHOULD reject such I2 + packets and reply with a NO_VALID_NAT_TRAVERSAL_MODE_PARAMETER NOTIFY + packet (see Section 5.10). + + If there is no answer for the I2 packet sent directly to the + Responder's preferred address, the Initiator MAY send another I2 via + the HIP relay server, but it MUST NOT choose UDP-ENCAPSULATION NAT + traversal mode for that I2. + +4.9. Initiating a Base Exchange Both with and without UDP Encapsulation + + The Initiator MAY also try to simultaneously perform a base exchange + with the Responder without UDP encapsulation. In such a case, the + Initiator sends two I1 packets, one without and one with UDP + encapsulation, to the Responder. The Initiator MAY wait for a while + before sending the other I1. How long to wait and in which order to + send the I1 packets can be decided based on local policy. For + retransmissions, the procedure is repeated. + + The I1 packet without UDP encapsulation may arrive directly, without + any relays, at the Responder. When this happens, the procedures in + [RFC5201] are followed for the rest of the base exchange. The + Initiator may receive multiple R1 packets, with and without UDP + encapsulation, from the Responder. However, after receiving a valid + R1 and answering it with an I2, further R1 packets that are not + retransmits of the original R1 MUST be ignored. + + + + + + + +Komu, et al. Experimental [Page 17] + +RFC 5770 Basic NAT Traversal for HIP April 2010 + + + The I1 packet without UDP encapsulation may also arrive at a HIP- + capable middlebox. When the middlebox is a HIP rendezvous server and + the Responder has successfully registered with the rendezvous + service, the middlebox follows rendezvous procedures in [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., in case of a mobility or + multihoming event that causes NAT traversal to be used during the + lifetime of the HIP association. + +4.10. Sending Control Packets after the Base Exchange + + After the base exchange, the end-hosts MAY send HIP control packets + directly to each other using the transport address pair established + for a data channel without sending the control packets through the + HIP relay server. When a host does not get acknowledgments, e.g., to + an UPDATE or CLOSE packet after a timeout based on local policies, + the host SHOULD resend the packet through the relay, if it was listed + in the LOCATOR parameter in the base exchange. + + If control packets are sent through a HIP relay server, the host + registered with the relay MUST utilize the RELAY_TO parameter as in + the base exchange. The HIP relay server SHOULD forward HIP packets + to the registered hosts and forward packets from a registered host to + the address in the RELAY_TO parameter. The relay MUST add a + RELAY_FROM parameter to the control packets it relays to the + registered hosts. + + If the HIP relay server is not willing or able to relay a HIP packet, + it MAY notify the sender of the packet with MESSAGE_NOT_RELAYED error + notification (see Section 5.10). + +5. Packet Formats + + The following subsections define the parameter and packet encodings + for the HIP, ESP, and ICE connectivity check packets. All values + MUST be in network byte order. + + + + + + + + +Komu, et al. Experimental [Page 18] + +RFC 5770 Basic NAT Traversal for HIP April 2010 + + +5.1. 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 5: Format of UDP-Encapsulated HIP Control Packets + + HIP control packets are encapsulated in UDP packets as defined in + Section 2.2 of [RFC3948], "IKE Header Format for Port 4500", except a + different port number is used. Figure 5 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 + already contains 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 relay server or a Responder without a relay SHOULD listen at + UDP port 10500 for incoming UDP-encapsulated HIP control packets. If + some other port number is used, it needs to be known by potential + Initiators. + +5.2. Connectivity Checks + + The connectivity checks are performed using STUN Binding requests as + defined in [RFC5245]. This section describes the details of the + parameters in the STUN messages. + + The Binding requests MUST use STUN short-term credentials with the + last 32 bits of the HITs of the Initiator and Responder as the + username fragments. The username is formed from the username + fragments as defined in Section 7.1.1.3 of [RFC5245]. The 32-bit + username fragments are expressed using lowercase hexadecimal ASCII + characters. The leading zeroes MUST NOT be omitted so that the + + + +Komu, et al. Experimental [Page 19] + +RFC 5770 Basic NAT Traversal for HIP April 2010 + + + username's size is fixed (8 characters); for example, if the local + HIT is 2001:15:8ebe:1aa7:42f5:b413:7237:6c0a and the remote HIT is + 2001:18:46fa:97c0:ba5:cd77:51:47b, the local username would be + 72376c0a and the remote username 0051047b. + + The STUN password is drawn from the Diffie-Hellman (DH) keying + material. Drawing of HIP keys is defined in [RFC5201], Section 6.5 + and drawing of ESP keys in [RFC5202], Section 7. Correspondingly, + the hosts MUST draw symmetric keys for STUN according to [RFC5201], + Section 6.5. The hosts draw the STUN key after HIP keys, or after + ESP keys if ESP transform was successfully negotiated in the base + exchange. Both hosts draw a 128-bit key from the 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 the PRIORITY attribute. They + MAY contain the USE-CANDIDATE attribute as defined in Section 7.1.1.1 + of [RFC5245]. + + The Initiator is always in the controlling role during a base + exchange. When two hosts are initiating a connection to each other + simultaneously, the HIP state machine detects it and assigns the host + with the larger HIT as the Responder as explained in Sections 4.4.2 + and 6.7 in [RFC5201]. Hence, the ICE-CONTROLLED and ICE-CONTROLLING + attributes are not needed to resolve role conflicts. However, the + attributes SHOULD be added to the connectivity check messages to + ensure interoperability with different ICE stacks, and they can be + safely ignored on received connectivity checks. + +5.3. Keepalives + + The keepalives for HIP associations that are created with ICE are + STUN Binding Indications, as defined in [RFC5389]. In contrast to + the UDP-encapsulated HIP header, the 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 packets using the + STUN markers, such as the magic cookie value and the FINGERPRINT + attribute. + + + + + +Komu, et al. Experimental [Page 20] + +RFC 5770 Basic NAT Traversal for HIP April 2010 + + + Keepalives for HIP associations created without ICE are HIP control + packets that have NOTIFY as the packet type. The keepalive NOTIFY + packets do not contain any parameters. + +5.4. NAT Traversal Mode Parameter + + The format of the NAT_TRAVERSAL_MODE parameter is similar to the + format of the ESP_TRANSFORM parameter in [RFC5202] and is shown in + 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 608 + Length length in octets, excluding Type, Length, and padding + Reserved zero when sent, ignored when received + Mode ID defines the proposed or selected NAT traversal mode(s) + + The following NAT traversal mode IDs are defined: + + ID name 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 no more than six (6) Mode IDs in one NAT_TRAVERSAL_MODE + parameter. Conversely, a recipient MUST be prepared to handle + received NAT traversal mode parameters that contain more than six + Mode IDs by accepting the first six Mode IDs and dropping the rest. + The limited number of Mode IDs sets the maximum size of the + NAT_TRAVERSAL_MODE parameter. The modes MUST be in preference order, + most preferred mode(s) first. + + + + +Komu, et al. Experimental [Page 21] + +RFC 5770 Basic NAT Traversal for HIP April 2010 + + +5.5. Connectivity Check Transaction Pacing Parameter + + The TRANSACTION_PACING parameter shown in Figure 7 contains only the + connectivity check pacing value, expressed in milliseconds, as a 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 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Min Ta | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type 610 + Length 4 + Min Ta the minimum connectivity check transaction pacing + value the host would use + + Figure 7: Format of the TRANSACTION_PACING Parameter + +5.6. Relay and Registration Parameters + + The 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 | Reserved | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + | Address | + | | + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type REG_FROM: 950 + RELAY_FROM: 63998 + RELAY_TO: 64002 + Length 20 + Port transport port number; zero when plain IP is used + Protocol IANA assigned, Internet Protocol number. + 17 for UDP, 0 for plain IP + + + + +Komu, et al. Experimental [Page 22] + +RFC 5770 Basic NAT Traversal for HIP April 2010 + + + Reserved reserved for future use; zero when sent, ignored + when received + Address an IPv6 address or an IPv4 address in "IPv4-Mapped + IPv6 address" format + + Figure 8: Format of the REG_FROM, RELAY_FROM, and RELAY_TO Parameters + + REG_FROM contains the transport address and protocol from which the + HIP relay server sees the registration coming. RELAY_FROM contains + the address from which the relayed packet was received by the relay + server and the protocol that was used. RELAY_TO contains the same + information about the address to which a packet should be forwarded. + +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 9. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Komu, et al. Experimental [Page 23] + +RFC 5770 Basic NAT Traversal for HIP April 2010 + + + 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 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Address | + | | + | | + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 9: LOCATOR Parameter + + The individual fields in the LOCATOR parameter are described in + Table 2. + + + + + + + + + + + + + + +Komu, et al. Experimental [Page 24] + +RFC 5770 Basic NAT Traversal for HIP April 2010 + + + +-----------+----------+--------------------------------------------+ + | 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 | + | Length | | Lifetime in 4-octet units | + | Reserved | 0 | Reserved for future extensions | + | Preferred | 0 or 1 | Set to 1 for a Locator in R1 if the | + | (P) bit | | Responder can use it for the rest of the | + | | | base exchange, otherwise set to zero | + | Locator | Variable | Locator lifetime in seconds | + | Lifetime | | | + | Transport | Variable | Transport layer port number | + | Port | | | + | Transport | Variable | IANA 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 | + | | | [RFC5245] | + | SPI | Variable | Security Parameter Index (SPI) value that | + | | | the host expects to see in incoming ESP | + | | | packets that use this locator | + | Address | Variable | IPv6 address or an "IPv4-Mapped IPv6 | + | | | address" format IPv4 address [RFC4291] | + +-----------+----------+--------------------------------------------+ + + Table 2: Fields of the LOCATOR Parameter + +5.8. RELAY_HMAC Parameter + + The RELAY_HMAC parameter value has the TLV type 65520. It has the + same semantics as RVS_HMAC [RFC5204]. + +5.9. Registration Types + + The REG_INFO, REG_REQ, REG_RESP, and REG_FAILED parameters contain + Registration Type [RFC5203] values for HIP relay server registration. + + The value for RELAY_UDP_HIP is 2. + + + + +Komu, et al. Experimental [Page 25] + +RFC 5770 Basic NAT Traversal for HIP April 2010 + + +5.10. Notify Packet Types + + A HIP relay server and end-hosts can use NOTIFY packets to signal + different error conditions. The new Notify Packet Types [RFC5201] + defined in this document are shown below. The Notification Data + field for the error notifications SHOULD contain the HIP header of + the rejected packet and SHOULD be empty for the + CONNECTIVITY_CHECKS_FAILED type. + + NOTIFICATION PARAMETER - ERROR TYPES Value + ------------------------------------ ----- + + NO_VALID_NAT_TRAVERSAL_MODE_PARAMETER 60 + + If a HIP relay server does not forward a base exchange packet due + to missing NAT traversal mode parameter, or the Initiator selects + a NAT traversal mode that the Responder did not expect, the relay + or the Responder may send back a NOTIFY error packet with this + type. + + + CONNECTIVITY_CHECKS_FAILED 61 + + Used by the end-hosts to signal that NAT traversal connectivity + checks failed and did not produce a working path. + + + MESSAGE_NOT_RELAYED 62 + + Used by a HIP relay server to signal that is was not able or + willing to relay a HIP packet. + +5.11. ESP Data Packets + + [RFC3948] describes the 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 Bound End-to-End Tunnel (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. + + + + +Komu, et al. Experimental [Page 26] + +RFC 5770 Basic NAT Traversal for HIP April 2010 + + + 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]. + +6. Security Considerations + +6.1. Privacy Considerations + + The locators are in plain text format in favor of inspection at HIP- + aware middleboxes in the future. The current document does not + specify encrypted versions of LOCATORs, even though it could be + beneficial for privacy reasons to avoid disclosing them to + middleboxes. + + It is also possible that end-users may not want to reveal all + locators to each other. For example, tracking the physical location + of a multihoming end-host may become easier if it reveals all + locators to its peer during a base exchange. Also, revealing host + addresses exposes information about the local topology that may not + be allowed in all corporate environments. For these two reasons, an + end-host may exclude certain host addresses from its LOCATOR + parameter. However, such behavior creates non-optimal paths when the + hosts are located behind the same NAT. Especially, this could be + problematic 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. + + The use of HIP relay servers and TURN relays can be also useful for + privacy purposes. For example, a privacy concerned Responder may + reveal only its HIP relay server and Relayed candidates to + Initiators. This same mechanism also protects the Responder against + Denial-of-Service (DoS) attacks by allowing the Responder to initiate + new connections even if its relays would be unavailable due to a DoS + attack. + +6.2. Opportunistic Mode + + A HIP relay server should have one address per relay client when a + HIP relay is serving more than one relay client and supports + opportunistic mode. Otherwise, it cannot be guaranteed that the HIP + relay server can deliver the I1 packet to the intended recipient. + + + + + + + + +Komu, et al. Experimental [Page 27] + +RFC 5770 Basic NAT Traversal for HIP April 2010 + + +6.3. Base Exchange Replay Protection for HIP Relay Server + + In certain scenarios, it is possible that an attacker, or two + attackers, can replay an earlier base exchange through a HIP 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 HIP relay server. + + The relay can protect itself against replay attacks by becoming + involved in the base exchange by introducing nonces that the end- + hosts (Initiator and Responder) are required to sign. One way to do + this is to add ECHO_REQUEST_M parameters to the R1 and I2 packets as + described in [HIP-MIDDLE] and drop the I2 or R2 packets if the + corresponding ECHO_RESPONSE_M parameters are not present. + +6.4. 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 uses HITs to distinguish + between different Initiators. + +7. IANA Considerations + + This section is to be interpreted according to [RFC5226]. + + This document updates the IANA Registry for HIP Parameter Types + [RFC5201] by assigning new HIP Parameter Type values for the new HIP + Parameters: RELAY_FROM, RELAY_TO, and REG_FROM (defined in + Section 5.6), RELAY_HMAC (defined in Section 5.8), TRANSACTION_PACING + (defined in Section 5.5), and NAT_TRAVERSAL_MODE (defined in + Section 5.4). + + This document defines an additional registration type for the HIP + Registration Extension [RFC5203] that allows registering with a HIP + relay server for relaying service: RELAY_UDP_HIP (defined in + Section 5.9). + + This document also defines NO_VALID_NAT_TRAVERSAL_MODE_PARAMETER, + CONNECTIVITY_CHECKS_FAILED, and MESSAGE_NOT_RELAYED Notify Packet + Types [RFC5201] in Section 5.10. + + + +Komu, et al. Experimental [Page 28] + +RFC 5770 Basic NAT Traversal for HIP April 2010 + + + The NAT_TRAVERSAL_MODE parameter has 16-bit unsigned integer fields + for different modes, for which IANA has created and maintains a new + sub-registry entitled "HIP NAT Traversal Modes" under the "Host + Identity Protocol (HIP) Parameters". Initial values for the NAT + traversal mode registry are given in Section 5.4; future assignments + are to be made through IETF Review [RFC5226]. Assignments consist of + a NAT traversal mode identifier name and its associated value. + +8. Contributors + + This RFC is a product of a design team that also included Marcelo + Bagnulo and Philip Matthews, who both have made major contributions + to this document. + +9. Acknowledgments + + Thanks to 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, and Abhinav Pathak for their contributions and Tobias + Heer, Teemu Koponen, Juhana Mattila, Jeffrey M. Ahrenholz, 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 has been working in the Networking Research group at + Helsinki Institute for Information Technology (HIIT). The work has + been funded by Tekes, Telia-Sonera, Elisa, Nokia, the Finnish Defence + Forces, Ericsson and Birdstep in InfraHIP I and II projects. + +10. References + +10.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing + Architecture", RFC 4291, February 2006. + + [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. + + + + + +Komu, et al. Experimental [Page 29] + +RFC 5770 Basic NAT Traversal for HIP April 2010 + + + [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. + + [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing + an IANA Considerations Section in RFCs", BCP 26, + RFC 5226, May 2008. + + [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment + (ICE): A Protocol for Network Address Translator (NAT) + Traversal for Offer/Answer Protocols", RFC 5245, + April 2010. + + [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, + "Session Traversal Utilities for NAT (STUN)", RFC 5389, + October 2008. + + [RFC5766] Rosenberg, J., Mahy, R., and P. Matthews, "Traversal + Using Relays around NAT (TURN): Relay Extensions to + Session Traversal Utilities for NAT (STUN)", RFC 5766, + April 2010. + +10.2. Informative References + + [HIP-MIDDLE] Heer, T., Wehrle, K., and M. Komu, "End-Host + Authentication for HIP Middleboxes", Work in Progress, + February 2009. + + [MMUSIC-ICE] Rosenberg, J., "Guidelines for Usage of Interactive + Connectivity Establishment (ICE) by non Session + Initiation Protocol (SIP) Protocols", 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. + + + +Komu, et al. Experimental [Page 30] + +RFC 5770 Basic NAT Traversal for HIP April 2010 + + + [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. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Komu, et al. Experimental [Page 31] + +RFC 5770 Basic NAT Traversal for HIP April 2010 + + +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 so small that the checks + cause network congestion or overwhelm the NATs. On the other hand, a + pacing value that is too high makes the checks last for a long time, + thus increasing 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 known, it is recommended that the value is + adjusted dynamically. In this case, it's recommended that the hosts + estimate the round-trip time (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 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. + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Komu, et al. Experimental [Page 32] + +RFC 5770 Basic NAT Traversal for HIP April 2010 + + +Appendix B. Base Exchange through a Rendezvous Server + + When the Initiator looks up the information of the Responder from + DNS, it's possible that it discovers a rendezvous server (RVS) record + [RFC5204]. In this case, if the Initiator uses NAT traversal methods + described in this document, it MAY use its own HIP relay server to + forward HIP traffic to the rendezvous server. The Initiator will + send the I1 packet using its HIP relay server, which will then + forward it to the RVS server of the 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 Responder will send the R1 packet directly to the Initiator's HIP + relay server and the following I2 and R2 packets are also sent + directly using the relay. + + In case the Initiator is not able to distinguish which records are + RVS address records and which are Responder's address records (e.g., + if the DNS server did not support HIP extensions), the Initiator + SHOULD first try to contact the Responder directly, without using a + HIP relay server. If none of the addresses are reachable, it MAY try + them out using its own HIP relay server as described above. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Komu, et al. Experimental [Page 33] + +RFC 5770 Basic NAT Traversal for HIP April 2010 + + +Authors' Addresses + + Miika Komu + Helsinki Institute for Information Technology + Metsanneidonkuja 4 + Espoo + Finland + Phone: +358503841531 + Fax: +35896949768 + EMail: miika@iki.fi + URI: http://www.hiit.fi/ + + Thomas Henderson + The Boeing Company + P.O. Box 3707 + Seattle, WA + USA + EMail: thomas.r.henderson@boeing.com + + Hannes Tschofenig + Nokia Siemens Networks + Linnoitustie 6 + Espoo 02600 + Finland + Phone: +358 (50) 4871445 + EMail: Hannes.Tschofenig@gmx.net + URI: http://www.tschofenig.priv.at/ + + Jan Melen + Ericsson Research Nomadiclab + Hirsalantie 11 + 02420 Jorvas + Finland + Phone: +358 9 2991 + EMail: jan.melen@ericsson.com + + Ari Keranen (editor) + Ericsson Research Nomadiclab + Hirsalantie 11 + 02420 Jorvas + Finland + Phone: +358 9 2991 + EMail: ari.keranen@ericsson.com + + + + + + + + +Komu, et al. Experimental [Page 34] + |