RFC 5770
Basic Host Identity Protocol (HIP) Extensions for Traversal of Network Address Translators
Basic Host Identity Protocol (HIP) Extensions for Traversal of Network Address Translators 🎀
Okay bestie, this is RFC 5770 💖 It's an Experimental doc from the IETF, not a Standards Track spec, so it's for trying things out and evaluating them 🧪 It's dated April 2010 and it has the ISSN 2070-1721 ✨ It doesn't list anything it obsoletes or updates.
The authors are M. Komu (HIIT), T. Henderson (The Boeing Company), H. Tschofenig (Nokia Siemens Networks), J. Melen (Ericsson Research Nomadiclab), and A. Keranen, Ed. (Ericsson Research Nomadiclab) 🫶
Abstract
okay so this doc adds extensions to the Host Identity Protocol (HIP) so it can get through Network Address Translators (NATs) 🦋 It uses Interactive Connectivity Establishment (ICE) to find a working path between two end-hosts, and it uses standard ways of wrapping Encapsulating Security Payload (ESP) packets inside the User Datagram Protocol (UDP) 🌸 It also defines parts of a NAT traversal procedure, including the optional use of a HIP relay server 🧚 With all this, HIP can work in networks that have NATs and gives a generic NAT traversal solution to higher-layer networking apps. literally slay 💅
Status of This Memo
okay this section is the official fine print 📜 This document is not an Internet Standards Track spec. It's published so people can look at it, try it out as an experiment, and evaluate it 🔬
It defines an Experimental Protocol for the Internet community ✨ It's a product of the Internet Engineering Task Force (IETF) and it represents the consensus of the IETF community 🫶 It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). Not every doc the IESG approves is a candidate for any level of Internet Standard, so check Section 2 of RFC 5741 if you're curious 🙈
If you want the latest status, errata, or a way to send feedback, go to http://www.rfc-editor.org/info/rfc5770 🌈
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) as they stand on the date this document was published 📜 Please actually read these, because they explain your rights and restrictions. Code Components pulled out of this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty as described in the Simplified BSD License 🍓
heads up: this doc may contain material from IETF Documents or IETF Contributions that were published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of that material may not have granted the IETF Trust the right to allow modifications outside the IETF Standards Process. Unless you get an adequate license from those copyright holders, 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. The only exceptions are formatting it for publication as an RFC or translating it into languages other than English. 🚨
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 .............331. Introduction ✨
okay so HIP [RFC5201] is a protocol that runs directly over IPv4 or IPv6 💅 HIP sets up ESP security associations [RFC5202], and those also run over IPv4 or IPv6. The thing is, this setup is known to have problems getting through NATs and other middleboxes [RFC5207] 😭 This doc adds HIP extensions so it can traverse both Network Address Translator (NAT) and Network Address and Port Translator (NAPT) middleboxes. It just uses the term NAT for all of these 🦋
Deployed NAT devices don't all behave the same way, even though [RFC4787] describes a recommended behavior 🙃 So the HIP extensions here make as few assumptions as possible about how NATs act, so NAT traversal can still work with legacy NAT devices 🍓 The whole point is to let two HIP-enabled hosts talk to each other even when one or both of them sit behind one or more NATs 💜
With these extensions, HIP end-hosts borrow techniques from the Interactive Connectivity Establishment (ICE) methodology [RFC5245] to find working paths for the HIP control protocol and for ESP encapsulated data traffic 🔥 The hosts test connectivity between different locators and try to find a direct end-to-end path. But with some legacy NATs, the shortest path between two end-hosts behind NATs isn't possible without relaying traffic through a relay, like a Traversal Using Relay NAT (TURN) server [RFC5128] 🥺 Relaying adds roundtrip delay and eats up the relay's resources, so with these extensions, hosts try to avoid the TURN server whenever they can 🫶
HIP already defines a rendezvous server [RFC5204] so mobile HIP hosts can have a stable point of contact on the Internet ✨ This doc extends the rendezvous server to solve the same problems, but for both NATed and non-NATed networks 🌸 The extended rendezvous server is called a "HIP relay server". It forwards HIP control packets between an Initiator and a Responder, which lets hosts sit behind NATs 🧚 That's different from the HIP rendezvous service, which only forwards the initial I1 packet of the base exchange. That approach is less likely to work in a NATed environment [RFC5128] 🙈 So when relays are used to traverse NATs, HIP uses a HIP relay server for the control traffic and a TURN server for the data traffic 💅
The connectivity checks are based on ICE [RFC5245] 🦋 Here's how [RFC5245] describes ICE:
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.
Standard ICE [RFC5245] is written with SIP in mind, and it has some features that aren't necessary or suitable for other protocols 🤷♀️ [MMUSIC-ICE] gives instructions and recommendations on using ICE with other protocols, and this document follows those guidelines 🎀
So two HIP hosts that implement this spec tell each other their locators during the HIP base exchange 💖 Those locators get paired with the other endpoint's locators and prioritized according to recommended and local policies ✨ Both end-hosts then test these locator pairs one at a time 🔥 Some tests might work out to multiple operational pairs, but ICE procedures pick a single preferred address pair for the rest of the communication 👑
In summary, the extensions in this doc define:
- UDP encapsulation of HIP packets 🦋
- UDP encapsulation of IPsec ESP packets 🌸
- registration extensions for HIP relay services 🧚
- how the ICE "offer" and "answer" are carried in the base exchange 💜
- interaction with ICE connectivity check messages 🫶
- backwards compatibility issues with rendezvous servers 🙈
- a number of optimizations (such as when the ICE connectivity tests can be omitted) 💅
- Terminology 🦋
okay so bestie, first things first, 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]. 💅 that's the whole vibe check for the requirement words, so pay attention to them 🫶
this doc borrows terminology from [RFC5201], [RFC5206], [RFC4423], [RFC5245], and [RFC5389]. 🌸 on top of that, these 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. main character energy, literally.
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.
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. ngl this one is iconic.
3. Overview of Operation ✨
okay picture this, bestie 🎀 here's the example network we're working with:
+-------+
| HIP |
+--------+ | Relay | +--------+
| TURN | +-------+ | STUN |
| Server | / \ | Server |
+--------+ / \ +--------+
/ \
/ \
/ \
/ <- Signaling -> \
/ \
+-------+ +-------+
| NAT | | NAT |
+-------+ +-------+
/ \
/ \
+-------+ +-------+
| Init- | | Resp- |
| iator | | onder |
+-------+ +-------+
Figure 1: Example Network Configurationso in this setup, both the Initiator and the Responder are stuck 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 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 it 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. periodt 💅
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 🎀
okay so 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. ✨
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 Relayin 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. 🌈
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 ✨
okay so this section is about a brand new non-critical parameter type 🎀 If that parameter shows up in a HIP base exchange, it basically means "hey, I speak NAT traversal extensions!" 💖 Since it's non-critical (see Section 5.2.1 of [RFC5201]), an end-host is allowed to just ignore it, which means that host doesn't support these extensions or isn't willing to use them 🙈
ngl, registering with a HIP relay is kinda the easy mode 🦋 The relay is assumed to be sitting in public address space, so UDP-ENCAPSULATION is usually more than enough. So the relay SHOULD propose UDP-ENCAPSULATION as the preferred or only mode 🫶
The NAT traversal mode negotiation in a HIP base exchange looks like this 👑
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 ModeIn step 1, the Initiator sends an I1 to the Responder. In step 2, the Responder replies with an R1. The NAT_TRAVERSAL_MODE parameter in R1 holds a list of the 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 ModesIn step 3, the Initiator sends an I2 that includes a NAT_TRAVERSAL_MODE parameter. It carries the mode the Initiator picked from the list the Responder offered. 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" 🧚
In step 4, the Responder wraps up 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 the Initiator selected isn't 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, so we don't cause congestion or overwhelm the NATs 🌸
So 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, like starting a new connectivity check or retrying a previous one ⭐ If a host doesn't include this parameter in the base exchange, a Ta value of 500 ms MUST be used as that host's minimum value. The value both hosts end up using is the higher of the two offered values 🔥
Hosts SHOULD NOT use values smaller than 20 ms for the minimum Ta, since those 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. If no value is configured, a value of 500 ms MUST be used. Guidelines for picking a Ta value are in Appendix A. Right now this feature only applies 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 do a base exchange through a HIP relay server. The NAT traversal mode negotiation (shown as NAT_TM in the example) was covered in Section 4.3, so we're not repeating it here. If a relay receives an R1 or I2 packet without the NAT traversal mode parameter, it MUST drop it, and it SHOULD send a NOTIFY error packet with type NO_VALID_NAT_TRAVERSAL_MODE_PARAMETER back to the sender of the R1/I2 🙈
It is RECOMMENDED that the Initiator send an I1 packet encapsulated in UDP when it's destined for 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 🎀
Here's the whole flow 👀
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 ServerIn step 1 of Figure 4, the Initiator sends an I1 packet over the transport layer to the Responder's HIT, and to the IP address and port of the HIP relay server. The source address is one of the Initiator's locators 🧚
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 the relay saw them. 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 with 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 💖
In step 3, the Responder receives the I1 packet and processes it according to the rules in [RFC5201]. On top of that, the Responder validates the RELAY_HMAC according to [RFC5204] and silently drops the packet if validation fails. The Responder replies with an R1 packet that 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 parameter type is different. The RELAY_TO parameter is not integrity protected by the signature of the R1, which allows 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 the RELAY_TO information. Finally, the relay recalculates the 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's different from all known local candidates 🦋 The Initiator replies with an I2 packet that uses the destination transport address of R1 as its source address and port. The I2 packet contains a LOCATOR parameter that lists all the ICE candidates (the "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 (the "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, and forwards the packet to the Initiator. Once the Initiator has received the R2 and processed it successfully, the base exchange is complete 🎉
Hosts MUST include the address of one or more HIP relay servers (including the one used for the initial signaling) in the LOCATOR parameter in I2/R2 if they plan to use those servers for relaying HIP signaling right after the base exchange completes 🧚
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 isn't included in the I2/R2 LOCATOR parameters, it SHOULD NOT be used after the base exchange. Further HIP signaling SHOULD use the same path as the data traffic 💅
4.6. ICE Connectivity Checks 💅
okay so if a HIP relay server was involved, the Responder finishes the base exchange with the R2 packet through the relay 🧚. but here's the tea 😭: the destination address the Initiator and Responder used for the base exchange packets belongs to the HIP relay server. so that address MUST NOT be used as a destination for ESP traffic. instead, if a NAT traversal mode with ICE connectivity checks was picked, the Initiator and Responder MUST start the connectivity checks 🦋.
creating the checklist for the ICE connectivity checks should be done like Section 5.7 of [RFC5245] says, bearing in mind that we only need one media stream and component 💖 (so there's 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 spells out 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 like this:
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 🧠.
if the ICE connectivity checks failed, the hosts MUST NOT send ESP traffic to each other 💀. they MAY keep chatting using HIP packets and the locators used for the base exchange, but no ESP. also, the hosts SHOULD let each other know about the failure with a CONNECTIVITY_CHECKS_FAILED NOTIFY packet (see Section 5.10) 🫶.
4.7. NAT Keepalives 🌈
okay so to keep 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're not behind a middlebox that needs them. 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 handle failure tolerance, an end-host SHOULD have a shorter keepalive period, bestie 🙈.
the keepalives are STUN Binding Indications if the hosts 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're 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, but only when the Initiator hasn't gotten 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 skipped to cut down initial connection set-up latency, because a base exchange acts as an implicit connectivity test all by 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 scenario is prone to failure unless it's carefully planned 💀.
in this kind of setup, the Responder MAY include UDP-ENCAPSULATION NAT traversal mode as one of its supported modes in the R1 packet 🧚. if the Responder has registered with a HIP relay server, it MUST also include a LOCATOR parameter in R1 that contains a preferred address where the Responder can 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's no such locator in R1, the source address of R1 is used as the Responder's preferred address.
the Initiator MAY choose UDP-ENCAPSULATION mode if the Responder listed it in the supported modes and the Initiator doesn't want to use ICE for hunting down 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 R1 came 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 won't 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's no answer to the I2 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 run a base exchange with the Responder at the same time, without UDP encapsulation 👑. in that case, the Initiator sends two I1 packets to the Responder, one without UDP encapsulation and one with it 💖. the Initiator MAY wait a little before sending the other I1. how long to wait and which order to send the I1 packets in can be decided by local policy. for retransmissions, the whole procedure gets repeated 🔁.
the I1 packet without UDP encapsulation may arrive directly at the Responder, no relays needed ✨. when that 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 aren't retransmits of the original R1 MUST be ignored 🙅♀️.
the I1 packet without UDP encapsulation may also land 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 the rendezvous procedures in [RFC5204] 🌸.
if the Initiator gets a NAT traversal mode parameter in R1 without UDP encapsulation, the Initiator MAY ignore that parameter and send an I2 without UDP encapsulation and without any selected NAT traversal mode 🫶. when the Responder receives an I2 without UDP encapsulation and without a NAT traversal mode, it will assume no NAT traversal mechanism is needed. packet processing is done as described in [RFC5201] 💅. the Initiator MAY store the NAT traversal modes for future use, e.g., in case a mobility or multihoming event 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 doesn't get acknowledgments (for example, to an UPDATE or CLOSE packet) after a timeout based on local policies, the host SHOULD resend the packet through the relay, if the relay was listed in the LOCATOR parameter in the base exchange 😭.
if control packets go through a HIP relay server, the host registered with the relay MUST use the RELAY_TO parameter, just like 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 isn't willing or able to relay a HIP packet, it MAY notify the sender of the packet with a 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 🧠.
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 PacketsHIP 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 tell HIP control packets apart 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. NATs unaware of HIP can't 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, potential Initiators need to know about it 🫶.
5.2. Connectivity Checks ✨
okay so the connectivity checks are done with STUN Binding requests, as defined in [RFC5245] 💅 this bit spells out the details of the parameters inside those STUN messages 🎀
Binding requests MUST use STUN short-term credentials, and the username fragments are the last 32 bits of the HITs of the Initiator and the Responder. The username gets built from those fragments as defined in Section 7.1.1.3 of [RFC5245]. The 32-bit fragments are written as lowercase hexadecimal ASCII characters. The leading zeroes MUST NOT be dropped, so the username is always the same size (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, then the local username is 72376c0a and the remote username is 0051047b 🦋
The STUN password comes from the Diffie-Hellman (DH) keying material 🔑 HIP key drawing is defined in [RFC5201], Section 6.5, and ESP key drawing is in [RFC5202], Section 7. So the hosts MUST draw symmetric keys for STUN according to [RFC5201], Section 6.5. The hosts draw the STUN key after the HIP keys, or after the ESP keys if the ESP transform was successfully negotiated in the base exchange. Both hosts draw a 128-bit key from the DH keying material, write it in hexadecimal ASCII using only lowercase letters (resulting in 32 numbers or lowercase letters), and use it as both the local and the peer password. [RFC5389] describes how hosts use the password for message integrity of STUN messages 💜
Both the username and the password are in ASCII hexadecimal format, so nobody has to run them through SASLPrep as defined in [RFC5389] 🙈 no extra steps, no drama ✨
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 start connecting to each other at the same time, the HIP state machine notices and assigns the host with the larger HIT as the Responder, as explained in Sections 4.4.2 and 6.7 in [RFC5201] 👑 so the ICE-CONTROLLED and ICE-CONTROLLING attributes aren't needed to sort out role conflicts. Still, the attributes SHOULD be added to the connectivity check messages to make sure they play nice 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]. Unlike the UDP-encapsulated HIP header, the non-ESP-marker between the UDP header and the STUN header is left out 🦋 Keepalives MUST contain the FINGERPRINT STUN attribute, but they SHOULD NOT contain any other STUN attributes and SHOULD NOT utilize any authentication mechanism. STUN messages are told apart from ESP and HIP control packets using the STUN markers, like the magic cookie value and the FINGERPRINT attribute 🔍
Keepalives for HIP associations created without ICE are HIP control packets whose packet type is NOTIFY 💖 the keepalive NOTIFY packets don't contain any parameters at all 🍓
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 it's shown in Figure 6 ✨ This specification defines the 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Here's what each field means 📝
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 2Figure 6: Format of the NAT_TRAVERSAL_MODE Parameter
The sender of a NAT_TRAVERSAL_MODE parameter MUST make sure 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, with the most preferred mode(s) first 👑
5.5. Connectivity Check Transaction Pacing Parameter ⭐
The TRANSACTION_PACING parameter, shown in Figure 7, contains only the connectivity check pacing value. That value is 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 useFigure 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 of these 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
Reserved reserved for future use; zero when sent, ignored
when received
Address an IPv6 address or an IPv4 address in "IPv4-Mapped
IPv6 address" formatFigure 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, along with the protocol that was used 📦 And RELAY_TO contains the same information about the address to which a packet should be forwarded 🦋
5.7. LOCATOR Parameter 📍
okay so the generic LOCATOR parameter format is literally the same as in [RFC5206] 💅 but presenting ICE candidates needs a brand new locator type 🦋 here's the generic and NAT-traversal-specific locator layout in Figure 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 9: LOCATOR Parameter
the individual fields are explained 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 |
| 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 🍓
5.10. Notify Packet Types 🚨
okay so 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 below. the Notification Data field for the error notifications SHOULD contain the HIP header of the rejected packet, and it SHOULD be empty for the CONNECTIVITY_CHECKS_FAILED type 💅
NOTIFICATION PARAMETER - ERROR TYPES Value
------------------------------------ -----
NO_VALID_NAT_TRAVERSAL_MODE_PARAMETER 60
CONNECTIVITY_CHECKS_FAILED 61
MESSAGE_NOT_RELAYED 62NO_VALID_NAT_TRAVERSAL_MODE_PARAMETER (60) is the one for when a HIP relay server doesn't forward a base exchange packet because the NAT traversal mode parameter is missing, or when the Initiator picks a NAT traversal mode the Responder wasn't expecting. then the relay or the Responder may send back a NOTIFY error packet with this type 🙈
CONNECTIVITY_CHECKS_FAILED (61) is used by the end-hosts to say that NAT traversal connectivity checks failed and didn't produce a working path 💀
MESSAGE_NOT_RELAYED (62) is used by a HIP relay server to say that it 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 modes. on the wire, HIP ESP packets look exactly like transport mode ESP, so their encapsulation is the same as UDP encapsulation transport mode ESP 🌈 the (semantic) difference from Bound End-to-End Tunnel (BEET) mode ESP packets, which HIP uses, is that the IP header isn't used in the BEET integrity protection calculation 🔥
during the HIP base exchange, the two peers swap parameters that let them define a pair of IPsec ESP security associations (SAs) as described in [RFC5202]. when two peers do 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] ✨
6. Security Considerations 🛡️
6.1. Privacy Considerations 🔒
the locators are in plain text so HIP-aware middleboxes can inspect them in the future 👀 this document doesn't specify encrypted versions of LOCATORs, even though it could be really good for privacy to keep them away from middleboxes 💜
it's also possible that end-users don't want to reveal every locator to each other 🌸 for example, tracking the physical location of a multihoming end-host could get easier if it reveals all its locators to its peer during a base exchange. revealing host addresses also exposes info about the local topology, which might not be allowed in every corporate environment 🏢 for those two reasons, an end-host may leave certain host addresses out of its LOCATOR parameter. however, that behavior creates non-optimal paths when the hosts sit behind the same NAT 😬 this is especially a problem with a legacy NAT that doesn't support routing from the private address realm back to itself through the outer address of the NAT. this is called the hairpin problem [RFC5128] 🌀 with a legacy NAT like that, the only option left is a relayed transport address from a TURN server 🫠
HIP relay servers and TURN relays can also be useful for privacy 🧚 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, since the Responder can still start new connections even if its relays become unavailable because of a DoS attack 🛡️✨
6.2. Opportunistic Mode 🎭
a HIP relay server should have one address per relay client when it's serving more than one relay client and supports opportunistic mode 💅 otherwise, it can't be guaranteed that the HIP relay server can deliver the I1 packet to the intended recipient 😭
6.3. Base Exchange Replay Protection for HIP Relay Server 🚫
⚠️ okay this one is a little scary bestie. in certain scenarios, an attacker (or two attackers) can replay an earlier base exchange through a HIP relay server by pretending to be the original Initiator and Responder 💀
the attack doesn't need the attacker(s) to compromise the private key(s) of the attacked host(s) 🙈 but for it to work, the Responder has to be disconnected from the HIP relay server.
the relay can protect itself against replay attacks by getting involved in the base exchange and 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 then drop the I2 or R2 packets if the corresponding ECHO_RESPONSE_M parameters aren't present 🧚
6.4. Demuxing Different HIP Associations 🌷
Section 5.1 of [RFC3948] describes a security issue with UDP encapsulation in standard IP tunnel mode, when two hosts behind different NATs have the same private IP address and start talking to the same Responder on the public Internet 😱 the Responder can't tell the two hosts apart, because the security associations are based on the same inner IP addresses.
this issue doesn't exist with UDP encapsulation of the HIP ESP transport format, because the Responder uses HITs to tell different Initiators apart 👑🌈
7. IANA Considerations ✨
okay bestie, time for the IANA stuff 📋 this section is to be interpreted according to [RFC5226], so that's the rulebook we're using 💅
this doc 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). so many new parameters, we're eating 🍓🔥
it also defines an extra registration type for the HIP Registration Extension [RFC5203] that lets you register with a HIP relay server for relaying service: RELAY_UDP_HIP (defined in Section 5.9) 🦋
and then there are the Notify Packet Types [RFC5201] this doc adds in Section 5.10: NO_VALID_NAT_TRAVERSAL_MODE_PARAMETER, CONNECTIVITY_CHECKS_FAILED, and MESSAGE_NOT_RELAYED 🙈
the NAT_TRAVERSAL_MODE parameter has 16-bit unsigned integer fields for the different modes, and IANA has created and maintains a brand new sub-registry called "HIP NAT Traversal Modes" under the "Host Identity Protocol (HIP) Parameters" registry 👑 the initial values for that registry are in Section 5.4. future assignments go through IETF Review [RFC5226]. each assignment is a NAT traversal mode identifier name plus its associated value. main character registry energy 🌸
8. Contributors 🫶
this RFC came out of a design team that also included Marcelo Bagnulo and Philip Matthews, who both made major contributions to the document. they're the real MVPs 💜
9. Acknowledgments ✨
thanks to Jonathan Rosenberg and the rest of the MMUSIC WG folks for the excellent work on ICE 🙌 the authors also want to thank Andrei Gurtov, Simon Schuetz, Martin Stiemerling, Lars Eggert, Vivien Schmitt, and Abhinav Pathak for their contributions. and a big shoutout to 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. iconic crew 🎀
Miika Komu has been working in the Networking Research group at Helsinki Institute for Information Technology (HIIT). the work was funded by Tekes, Telia-Sonera, Elisa, Nokia, the Finnish Defence Forces, Ericsson and Birdstep in the 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.
[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.
[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 🦋
picking the right value for connectivity check transaction pacing is essential for the performance of connectivity check-based NAT traversal 🔥 it should not be so small that the checks cause network congestion or overwhelm the NATs. but also, a pacing value that's too high makes the checks last forever, which means a longer connection setup delay. so it's a vibe balance 🥲
the Ta value may be configured by the user in environments where the network characteristics are known beforehand. but if the characteristics aren't known, it is recommended that the value is adjusted dynamically. in that 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 ⏱️ big brain stuff 🧠
one way to estimate the RTT is to use the time it takes for the HIP relay server registration exchange to complete. that gives you an estimate of the registering host's access link's RTT 🌈 the I1/R1 exchange could also 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 💀 not the move.
Appendix B. Base Exchange through a Rendezvous Server 💜
okay so when the Initiator looks up the Responder's info in DNS, it's possible it finds a rendezvous server (RVS) record [RFC5204]. in that case, if the Initiator uses the NAT traversal methods from this doc, it MAY use its own HIP relay server to forward HIP traffic to the rendezvous server. the Initiator sends the I1 packet through its HIP relay server, which then forwards it to the RVS of the Responder. in this setup, the value of the protocol field in the RELAY_TO parameter MUST be IP, since RVS doesn't support UDP-encapsulated base exchange packets 🙅♀️ the Responder sends 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 🦋
heads up!! if the Initiator can't tell which records are RVS address records and which are Responder's address records (for example, if the DNS server didn't 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 🫣
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.comthat's the whole RFC, bestie 🌈✨💖
📦 where this page comes from
- ietf: rfc5770 2010-04
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms