This section describes the normative behavior of the "Native ICE-HIP" protocol extension. Most of the procedures are similar to what is defined in [RFC 5770
] but with different, or additional, parameter types and values. In addition, a new type of relaying server, Data Relay Server, is specified. Also, it should be noted that HIP version 2 [RFC 7401
be used instead of HIPv1 with this NAT traversal mode.
In order for two hosts to communicate over NATed environments, they need a reliable way to exchange information. To achieve this, "HIP Relay Server" is defined in [RFC 5770
]. It supports the relaying of HIP control plane traffic over UDP in NATed environments and forwards HIP control packets between the Initiator and the Responder. In this document, the HIP Relay Server is denoted as "Control Relay Server" for better alignment with the rest of the terminology. The registration to the Control Relay Server can be achieved using the RELAY_UDP_HIP parameter as explained later in this section.
To also guarantee data plane delivery over varying types of NAT devices, a host MAY
also register for UDP-encapsulated ESP relaying using Registration Type RELAY_UDP_ESP (value 3). This service may be coupled with the Control Relay Server or offered separately on another server. If the server supports relaying of UDP-encapsulated ESP, the host is allowed to register for a data-relaying service using the registration extensions in Section 3.3
of RFC 8003
. If the server has sufficient relaying resources (free port numbers, bandwidth, etc.) available, it opens a UDP port on one of its addresses and signals the address and port to the registering host using the RELAYED_ADDRESS parameter (as defined in Section 5.12
in this document). If the Data Relay Server would accept the data-relaying request but does not currently have enough resources to provide data-relaying service, it MUST
reject the request with Failure Type "Insufficient resources" [RFC 8003
The registration process follows the generic registration extensions defined in [RFC 8003
]. The HIP control plane relaying registration follows [RFC 5770
], but the data plane registration is different. It is worth noting that if the HIP control and data plane relay services reside on different hosts, the client has to register separately to each of them. In the example shown in Figure 2
, the two services are coupled on a single host. The text uses "Relay Client" and "Relay Server" as a shorthand when the procedures apply both to control and data cases.
Relay Client (Initiator) Relay Server (Responder)
| 1. UDP(I1) |
| 2. UDP(R1(REG_INFO(RELAY_UDP_HIP,[RELAY_UDP_ESP]))) |
| 3. UDP(I2(REG_REQ(RELAY_UDP_HIP),[RELAY_UDP_ESP])) |
| 4. UDP(R2(REG_RES(RELAY_UDP_HIP,[RELAY_UDP_ESP]), REG_FROM, |
| [RELAYED_ADDRESS])) |
In step 1, the Relay Client (Initiator) starts the registration procedure by sending an I1 packet over UDP to the Relay Server. It is RECOMMENDED
that the Relay Client select a random source 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 Relay Server listen to incoming connections at UDP port 10500. If some other port number is used, it needs to be known by potential Relay Clients.
In step 2, the Relay Server (Responder) lists the services that it supports in the R1 packet. The support for HIP control plane over UDP relaying is denoted by the Registration Type value RELAY_UDP_HIP (see Section 5.9
). If the server also supports the relaying of ESP traffic over UDP, it also includes the Registration Type value RELAY_UDP_ESP.
In step 3, the Relay Client selects the services for which it registers and lists them in the REG_REQ parameter. The Relay Client registers for the Control Relay service by listing the RELAY_UDP_HIP value in the request parameter. If the Relay Client also requires ESP relaying over UDP, it lists also RELAY_UDP_ESP.
In step 4, the Relay Server concludes the registration procedure with an R2 packet and acknowledges the registered services in the REG_RES parameter. The Relay Server denotes unsuccessful registrations (if any) in the REG_FAILED parameter of R2. The Relay Server also includes a REG_FROM parameter that contains the transport address of the Relay Client as observed by the Relay Server (server-reflexive candidate). If the Relay Client registered to ESP-relaying service, the Relay Server includes a RELAYED_ADDRESS parameter that describes the UDP port allocated to the Relay Client for ESP relaying. It is worth noting that the Data Relay Client must first activate this UDP port by sending an UPDATE message to the Data Relay Server that includes a PEER_PERMISSION parameter as described in Section 4.12.1
both after base exchange and handover procedures. Also, the Data Relay Server should follow the port allocation recommendations in Section 7.5
After the registration, the Relay Client periodically sends NAT keepalives to the Relay Server in order to keep the NAT bindings between the Relay Client and the relay alive. The keepalive extensions are described in Section 4.10
The Data Relay Client MUST
maintain an active HIP association with the Data Relay Server as long as it requires the data-relaying service. When the HIP association is closed (or times out), or the registration lifetime passes without the Data Relay Client refreshing the registration, the Data Relay Server MUST
stop relaying packets for that host and close the corresponding UDP port (unless other Data Relay Clients are still using it).
The Data Relay Server SHOULD
offer a different relayed address and port for each Data Relay Client because not doing so can cause problems with stateful firewalls (see Section 7.5
When a Control Relay Client sends an UPDATE (e.g., due to host movement or to renew service registration), the Control Relay Server MUST
follow the general guidelines defined in [RFC 8003
], with the difference that all UPDATE messages are delivered on top of UDP. In addition to this, the Control Relay Server MUST
include the REG_FROM parameter in all UPDATE responses sent to the Control Relay Client. This applies to both renewals of service registration and to host movement. It is especially important for the case of host movement, as this is the mechanism that allows the Control Relay Client to learn its new server-reflexive address candidate.
A Data Relay Client can request multiple relayed candidates from the Data Relay Server (e.g., for the reasons described in Section 4.12.3
). After the base exchange with registration, the Data Relay Client can request additional relayed candidates similarly as during the base exchange. The Data Relay Client sends an UPDATE message REG_REQ parameter requesting for the RELAY_UDP_ESP service. The UPDATE message MUST
also include a SEQ and an ECHO_REQUEST_SIGNED parameter. The Data Relay Server MUST
respond with an UPDATE message that includes the corresponding response parameters: REG_RES, ACK and ECHO_REQUEST_SIGNED. In case the Data Relay Server allocated a new relayed UDP port for the Data Relay Client, the REG_RES parameter MUST
list RELAY_UDP_ESP as a service and the UPDATE message MUST
also include a RELAYED_ADDRESS parameter describing the relayed UDP port. The Data Relay Server MUST
also include the server-reflexive candidate in a REG_FROM parameter. It is worth mentioning that the Data Relay Client MUST
activate the UDP port as described in Section 4.12.1
before it can be used for any ESP relaying.
A Data Relay Client may unregister a relayed candidate in two ways. It can wait for its lifetime to expire or it can explicitly request it with zero lifetime using the UPDATE mechanism. The Data Relay Client can send a REG_REQ parameter with zero lifetime to the Data Relay Server in order to expire all relayed candidates. To expire a specific relayed candidate, the Data Relay Client MUST
also include a RELAYED_ADDRESS parameter as sent by the server in the UPDATE message. Upon closing the HIP association (CLOSE-CLOSE-ACK procedure initiated by either party), the Data Relay Server MUST
also expire all relayed candidates.
Please also refer to Section 7.8
for protection against cross-protocol attacks for both Control Relay Client and Server.
An Initiator needs to gather a set of address candidates before contacting a (non-relay) Responder. The candidates are needed for connectivity checks that allow two hosts to discover a direct, non-relayed path for communicating with each other. One server-reflexive candidate can be discovered during the registration with the Control Relay Server from the REG_FROM parameter (and another from Data Relay Server if one is employed).
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-HIP-UDP mode 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 Data Relay 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 Control Relay Server registration as a server-reflexive candidate. In this case, no further candidate gathering is needed.
A Data Relay Client MAY
register only a single relayed candidate that it uses with multiple other peers. However, it is RECOMMENDED
that a Data Relay Client registers a new server relayed candidate for each of its peers for the reasons described in Section 4.12.3
. The procedures for registering multiple relayed candidates are described in Section 4.1
If a Relay Client has more than one network interface, it can discover additional server-reflexive candidates by sending UPDATE messages from each of its interfaces to the Relay Server. Each such UPDATE message MUST
include the following parameters: the registration request (REG_REQ) parameter with Registration Type CANDIDATE_DISCOVERY (value 4) and the ECHO_REQUEST_SIGNED parameter. When a Control Relay Server receives an UPDATE message with registration request containing a CANDIDATE_DISCOVERY type, it MUST
include a REG_FROM parameter, containing the same information as if this were a Control Relay Server registration, to the response (in addition to the mandatory ECHO_RESPONSE_SIGNED parameter). This request type SHOULD NOT
create any state at the Control Relay Server.
The rules in Section 5.1.1
of RFC 8445
for candidate gathering are followed here. A number of host candidates (loopback, anycast and others) should be excluded as described in the ICE specification (Section 188.8.131.52
of RFC 8445
). Relayed candidates SHOULD
be gathered in order to guarantee successful NAT traversal, and implementations SHOULD
support this functionality even if it will not be used in deployments in order to enable it by software configuration update if needed at some point. Similarly, as explained in the ICE specification (Section 184.108.40.206
of RFC 8445
), if an IPv6-only host is in a network that utilizes NAT64 [RFC 6146
] and DNS64 [RFC 6147
] technologies, it may also gather IPv4 server-reflexive and/or relayed candidates from IPv4-only Control or Data Relay Servers. IPv6-only hosts SHOULD
also utilize IPv6 prefix discovery [RFC 7050
] to discover the IPv6 prefix used by NAT64 (if any) and generate server-reflexive candidates for each IPv6-only interface, accordingly. The NAT64 server-reflexive candidates are prioritized like IPv4 server-reflexive candidates.
HIP-based connectivity can be utilized by IPv4 applications using Local Scope Identifiers (LSIs) and by IPv6-based applications using HITs. The LSIs and HITs of the local virtual interfaces MUST
be excluded in the candidate gathering phase as well to avoid creating unnecessary loopback connectivity tests.
Gathering of candidates MAY
also be performed by other means than described in this section. For example, the candidates could be gathered as specified in Section 4.2
of RFC 5770
if STUN servers are available, or if the host has just a single interface and no STUN or Data Relay Server are available.
Each local address candidate MUST
be assigned a priority. The following recommended formula (as described in [RFC 8445
priority = (224
)*(type preference) + (28
)*(local preference) + (20
)*(256 - component ID)
In the formula, the type preference follows the ICE specification (as defined in Section 220.127.116.11
of RFC 8445
): the RECOMMENDED
values are 126 for host candidates, 100 for server-reflexive candidates, 110 for peer-reflexive candidates, and 0 for relayed candidates. The highest value is 126 (the most preferred) and lowest is 0 (last resort). For all candidates of the same type, the preference type value MUST
be identical, and, correspondingly, the value MUST
be different for different types. For peer-reflexive values, the type preference value MUST
be higher than for server-reflexive types. It should be noted that peer-reflexive values are learned later during connectivity checks.
Following the ICE specification, the local preference MUST
be an integer from 0 (lowest preference) to 65535 (highest preference) inclusive. In the case the host has only a single address candidate, the value SHOULD
be 65535. In the case of multiple candidates, each local preference value MUST
be unique. Dual-stack considerations for IPv6 also apply here as defined in Section 18.104.22.168
of RFC 8445
Unlike with SDP used in conjunction with ICE, this protocol only creates a single UDP flow between the two communicating hosts, so only a single component exists. Hence, the component ID value MUST
always be set to 1.
As defined in Section 14.3
of RFC 8445
, the retransmission timeout (RTO) for address gathering from a Control/Data Relay Server SHOULD
be calculated as follows:
RTO = MAX (1000 ms, Ta * (Num-Of-Cands))
where Ta is the value used for the connectivity check pacing and Num-Of-Cands is the number of server-reflexive and relay candidates. A smaller value than 1000 ms for the RTO MUST NOT
This section describes the usage of a non-critical parameter type called NAT_TRAVERSAL_MODE with a new mode called ICE-HIP-UDP. The presence of the new mode in the NAT_TRAVERSAL_MODE 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 RFC 7401
), it can be ignored by an end host, which means that the host is not required to support it or may decline to use it.
With registration with a Control/Data Relay Server, it is usually sufficient to use the UDP-ENCAPSULATION mode of NAT traversal since the Relay Server is assumed to be in public address space. Thus, the Relay Server SHOULD
propose the UDP-ENCAPSULATION mode as the preferred or only mode. The NAT traversal mode negotiation in a HIP base exchange is illustrated in Figure 3
. It is worth noting that the Relay Server could be located between the hosts, but is omitted here for simplicity.
| 1. UDP(I1) |
| 2. UDP(R1(.., NAT_TRAVERSAL_MODE(ICE-HIP-UDP), ..)) |
| 3. UDP(I2(.., NAT_TRAVERSAL_MODE(ICE-HIP-UDP), ENC(LOC_SET), ..))|
| 4. UDP(R2(.., ENC(LOC_SET), ..)) |
In step 1, the Initiator sends an I1 to the Responder.
In step 2, the Responder responds with an R1. As specified in [RFC 5770
], the NAT_TRAVERSAL_MODE parameter in R1 contains a list of NAT traversal modes the Responder supports. The mode specified in this document is ICE-HIP-UDP (value 3).
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-HIP-UDP mode was selected, the I2 also includes the "Transport address" locators (as defined in Section 5.7
) of the Initiator in a LOCATOR_SET parameter (denoted here with LOC_SET). With ICE-HIP-UDP mode, the LOCATOR_SET parameter MUST
be encapsulated within an ENCRYPTED parameter (denoted here with ENC) according to the procedures in Sections 5.2.18
in [RFC 7401
]. The locators in I2 are the "HIP offer".
In step 4, the Responder concludes the base exchange with an R2 packet. If the Initiator chose ICE-HIP-UDP traversal mode, the Responder includes a LOCATOR_SET parameter in the R2 packet. With ICE-HIP-UDP mode, the LOCATOR_SET parameter MUST
be encapsulated within an ENCRYPTED parameter according to the procedures in Sections 5.2.18
in [RFC 7401
]. 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.
As explained in Legacy ICE-HIP [RFC 5770
], 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. The value that is used by both of the hosts is the higher of the two offered values.
The minimum Ta value SHOULD
be configurable, and if no value is configured, a value of 50 ms MUST
be used. Guidelines for selecting a Ta value are given in Appendix A
. Hosts MUST NOT
use values smaller than 5 ms for the minimum Ta, since such values may not work well with some NATs (as explained in [RFC 8445
]). The Initiator MUST NOT
propose a smaller value than what the Responder offered. If a host does not include the TRANSACTION_PACING parameter in the base exchange, a Ta value of 50 ms MUST
be used as that host's minimum value.
This section describes how the Initiator and Responder perform a base exchange through a Control Relay Server. Connectivity pacing (denoted as TA_P here) was described in Section 4.4
and is not repeated here. Similarly, the NAT traversal mode negotiation process (denoted as NAT_TM in the example) was described in Section 4.3
and is also not repeated here. If a Control Relay Server 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 or I2.
It is RECOMMENDED
that the Initiator send an I1 packet encapsulated in UDP when it is destined to an IP address of the Responder. Respectively, the Responder MUST
respond to such an I1 packet with a UDP-encapsulated R1 packet, and also the rest of the communication related to the HIP association MUST
also use UDP encapsulation.
illustrates a base exchange via a Control Relay Server. We assume that the Responder (i.e., a Control Relay Client) has already registered to the Control Relay Server. The Initiator may have also registered to another (or the same Control Relay Server), but the base exchange will traverse always through the Control Relay Server of the Responder.
Initiator Control Relay Server Responder
| 1. UDP(I1) | |
+--------------------------------->| 2. UDP(I1(RELAY_FROM)) |
| | |
| | 3. UDP(R1(RELAY_TO, NAT_TM, |
| | TA_P)) |
| 4. UDP(R1(RELAY_TO, NAT_TM, |<-------------------------------+
| TA_P)) | |
| | |
| 5. UDP(I2(ENC(LOC_SET)), | |
| NAT_TM, TA_P)) | |
+--------------------------------->| 6. UDP(I2(ENC(LOC_SET), |
| | RELAY_FROM, NAT_TM, TA_P))|
| | |
| | 7. UDP(R2(ENC(LOC_SET), |
| 8. UDP(R2(ENC(LOC_SET), | RELAY_TO)) |
| RELAY_TO)) |<-------------------------------+
| | |
In step 1 of Figure 4
, the Initiator sends an I1 packet over UDP via the Control Relay Server to the Responder. In the HIP header, the source HIT belongs to the Initiator and the destination HIT to the Responder. The Initiator sends the I1 packet from its IP address to the IP address of the Control Relay Server over UDP.
In step 2, the Control Relay Server receives the I1 packet. If the destination HIT belongs to a successfully registered Control Relay Client (i.e., the host marked "Responder" in Figure 4
), the Control Relay Server processes the packet. Otherwise, the Control Relay Server MUST
drop the packet silently. The Control Relay Server appends a RELAY_FROM parameter to the I1 packet, which contains the transport source address and port of the I1 as observed by the Control Relay Server. The Control Relay Server protects the I1 packet with RELAY_HMAC, except that the parameter type is different as described in Section 5.8
. The Control Relay Server changes the source and destination ports and IP addresses of the packet to match the values the Responder used when registering to the Control Relay Server, i.e., the reverse of the R2 used in the registration. The Control Relay Server MUST
recalculate the transport checksum and forward the packet to the Responder.
In step 3, the Responder receives the I1 packet. The Responder processes it according to the rules in [RFC 7401
]. In addition, the Responder validates the RELAY_HMAC according to Section 5.8
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 Responder MUST
include ICE-HIP-UDP in the NAT traversal modes. 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 Control Relay Server receives the R1 packet. The Control Relay Server drops the packet silently if the source HIT belongs to a Control Relay Client that has not successfully registered. The Control Relay Server MAY
verify the signature of the R1 packet and drop it if the signature is invalid. Otherwise, the Control Relay Server rewrites the source address and port, and changes the destination address and port to match RELAY_TO information. Finally, the Control Relay Server recalculates the transport checksum and forwards the packet.
In step 5, the Initiator receives the R1 packet and processes it according to [RFC 7401
]. 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_SET parameter inside an ENCRYPTED parameter that lists all the HIP candidates (HIP 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 that includes ICE-HIP-UDP mode. The ENCRYPTED parameter along with its key material generation is described in detail in Sections 5.2.18
in [RFC 7401
In step 6, the Control Relay Server receives the I2 packet. The Control Relay Server appends a RELAY_FROM and a RELAY_HMAC to the I2 packet similar to that explained in step 2, and forwards the packet to the Responder.
In step 7, the Responder receives the I2 packet and processes it according to [RFC 7401
]. The Responder validates the RELAY_HMAC according to Section 5.8
and silently drops the packet if the validation fails. It replies with an R2 packet and includes a RELAY_TO parameter as explained in step 3. The R2 packet includes a LOCATOR_SET parameter inside an ENCRYPTED parameter that lists all the HIP candidates (ICE answer) of the Responder. The RELAY_TO parameter is protected by the Hashed Message Authentication Code (HMAC). The ENCRYPTED parameter along with its key material generation is described in detail in Sections 5.2.18
in [RFC 7401
In step 8, the Control Relay Server processes the R2 as described in step 4. The Control Relay Server forwards the packet to the Initiator. After the Initiator has received the R2 and processed it successfully, the base exchange is completed.
include the address of one or more Control Relay Servers (including the one that is being used for the initial signaling) in the LOCATOR_SET parameter in I2 and R2 messages if they intend to use such servers for relaying HIP signaling immediately after the base exchange completes. The traffic type of these addresses MUST
be "HIP signaling" (see Section 5.7
) and they MUST NOT
be used for the connectivity tests described in Section 4.6
. If the Control Relay Server locator used for relaying the base exchange is not included in I2 or R2 LOCATOR_SET parameters, it SHOULD NOT
be used after the base exchange. Instead, further HIP signaling SHOULD
use the same path as the data traffic. It is RECOMMENDED
to use the same Control Relay Server throughout the lifetime of the host association that was used for forwarding the base exchange if the Responder includes it in the locator parameter of the R2 message.
When the Initiator and Responder complete the base exchange through the Control Relay Server, both of them employ the IP address of the Control Relay Server as the destination address for the packets. The address of the Control Relay Server MUST NOT
be used as a destination for data plane traffic unless the server also supports Data Relay Server functionality, and the Client has successfully registered to use it. When NAT traversal mode with ICE-HIP-UDP was successfully negotiated and selected, the Initiator and Responder MUST
start the connectivity checks in order to attempt to obtain direct end-to-end connectivity through NAT devices. It is worth noting that the connectivity checks MUST
be completed even though no ESP_TRANSFORM would be negotiated and selected.
The connectivity checks follow the ICE methodology [ICE-NONSIP
], but UDP-encapsulated HIP control messages are used instead of ICE messages. As stated in the ICE specification, the basic procedure for connectivity checks has three phases: sorting the candidate pairs according to their priority, sending checks in the prioritized order, and acknowledging the checks from the peer host.
The Initiator MUST
take the role of controlling host, and the Responder acts as the controlled host. The roles MUST
persist throughout the HIP associate lifetime (to be reused even during mobility UPDATE procedures). In the case in which both communicating nodes are initiating communication to each other using an I1 packet, the conflict is resolved as defined in Section 6.7
of RFC 7401
; the host with the "larger" HIT changes its role to Responder. In such a case, the host changing its role to Responder MUST
also switch to the controlled role.
The protocol follows standard HIP UPDATE sending and processing rules as defined in Sections 6.11
in [RFC 7401
], but some new parameters are introduced (CANDIDATE_PRIORITY, MAPPED_ADDRESS, NOMINATE, PEER_PERMISSION, and RELAYED_ADDRESS).
illustrates connectivity checks in a simplified scenario where the Initiator and Responder have only a single candidate pair to check. Typically, NATs drop messages until both sides have sent messages using the same port pair. In this scenario, the Responder sends a connectivity check first but the NAT of the Initiator drops it. However, the connectivity check from the Initiator reaches the Responder because it uses the same port pair as the first message. It is worth noting that the message flow in this section is idealistic, and, in practice, more messages would be dropped, especially in the beginning. For instance, connectivity tests always start with the candidates with the highest priority, which would be host candidates (which would not reach the recipient in this scenario).
Initiator NAT1 NAT2 Responder
| | 1. UDP(UPDATE(SEQ, CAND_PRIO, | |
| | ECHO_REQ_SIGN)) | |
| | | |
| 2. UDP(UPDATE(SEQ, ECHO_REQ_SIGN, CAND_PRIO)) | |
| | | |
| 3. UDP(UPDATE(ACK, ECHO_RESP_SIGN, MAPPED_ADDR)) | |
| | | |
| 4. UDP(UPDATE(SEQ, ECHO_REQ_SIGN, CAND_PRIO)) | |
| | | |
| 5. UDP(UPDATE(ACK, ECHO_RESP_SIGN, MAPPED_ADDR)) | |
| | | |
| 6. Other connectivity checks using UPDATE over UDP |
| | | |
| 7. UDP(UPDATE(SEQ, ECHO_REQ_SIGN, CAND_PRIO, NOMINATE)) |
| | | |
| 8. UDP(UPDATE(SEQ, ACK, ECHO_REQ_SIGN, ECHO_RESP_SIGN, |
| NOMINATE)) | |
| | | |
| 9. UDP(UPDATE(ACK, ECHO_RESP_SIGN)) | |
| | | |
| 10. ESP data traffic over UDP | |
| | | |
In step 1, the Responder sends a connectivity check to the Initiator that the NAT of the Initiator drops. The message includes a number of parameters. As specified in [RFC 7401
], the SEQ parameter includes a running sequence identifier for the connectivity check. The candidate priority (denoted CAND_PRIO in the figure) describes the priority of the address candidate being tested. The ECHO_REQUEST_SIGNED (denoted ECHO_REQ_SIGN in the figure) includes a nonce that the recipient must sign and echo back as it is.
In step 2, the Initiator sends a connectivity check, using the same address pair candidate as in the previous step, and the message successfully traverses the NAT boxes. The message includes the same parameters as in the previous step. It should be noted that the sequence identifier is locally assigned by the Initiator, so it can be different than in the previous step.
In step 3, the Responder has successfully received the previous connectivity check from the Initiator and starts to build a response message. Since the message from the Initiator included a SEQ, the Responder must acknowledge it using an ACK parameter. Also, the nonce contained in the echo request must be echoed back in an ECHO_RESPONSE_SIGNED (denoted ECHO_RESP_SIGN) parameter. The Responder also includes a MAPPED_ADDRESS parameter (denoted MAPPED_ADDR in the figure) that contains the transport address of the Initiator as observed by the Responder (i.e., peer-reflexive candidate). This message is successfully delivered to the Initiator; upon reception, the Initiator marks the candidate pair as valid.
In step 4, the Responder retransmits the connectivity check sent in the first step, since it was not acknowledged yet.
In step 5, the Initiator responds to the previous connectivity check message from the Responder. The Initiator acknowledges the SEQ parameter from the previous message using an ACK parameter and the ECHO_REQUEST_SIGNED parameter with ECHO_RESPONSE_SIGNED. In addition, it includes the MAPPED_ADDR parameter that includes the peer-reflexive candidate. This response message is successfully delivered to the Responder; upon reception, the Initiator marks the candidate pair as valid.
In step 6, despite the two hosts now having valid address candidates, the hosts still test the remaining address candidates in a similar way as in the previous steps. It should be noted that each connectivity check has a unique sequence number in the SEQ parameter.
In step 7, the Initiator has completed testing all address candidates and nominates one address candidate to be used. It sends an UPDATE message using the selected address candidates that includes a number of parameters: SEQ, ECHO_REQUEST_SIGNED, CANDIDATE_PRIORITY, and the NOMINATE parameter.
In step 8, the Responder receives the message with the NOMINATE parameter from the Initiator. It sends a response that includes the NOMINATE parameter in addition to a number of other parameters. The ACK and ECHO_RESPONSE_SIGNED parameters acknowledge the SEQ and ECHO_REQUEST_SIGNED parameters from the previous message from the Initiator. The Responder includes SEQ and ECHO_REQUEST_SIGNED parameters in order to receive an acknowledgment from the Responder.
In step 9, the Initiator completes the candidate nomination process by confirming the message reception to the Responder. In the confirmation message, the ACK and ECHO_RESPONSE_SIGNED parameters correspond to the SEQ and ECHO_REQUEST_SIGNED parameters in the message sent by the Responder in the previous step.
In step 10, the Initiator and Responder can start sending application payload over the successfully nominated address candidates.
It is worth noting that if either host has registered a relayed address candidate from a Data Relay Server, the host MUST
activate the address before connectivity checks by sending an UPDATE message containing the PEER_PERMISSION parameter as described in Section 4.12.1
. Otherwise, the Data Relay Server drops ESP packets using the relayed address.
It should be noted that in the case in which both the Initiator and Responder are advertising their own relayed address candidates, it is possible that the two hosts choose the two relayed addresses as a result of the ICE nomination algorithm. While this is possible (and even could be desirable for privacy reasons), it can be unlikely due to low priority assigned for the relayed address candidates. In such an event, the nominated address pair is always symmetric; the nomination algorithm prevents asymmetric address pairs (i.e., each side choosing different pair) such as a Data Relay Client using its own Data Relay Server to send data directly to its peer while receiving data from the Data Relay Server of its peer.
The HITs of the two communicating hosts MUST
be used as credentials in this protocol (in contrast to ICE, which employs username-password fragments). A HIT pair uniquely identifies the corresponding HIT association, and a SEQ number in an UPDATE message identifies a particular connectivity check.
All of the connectivity check messages MUST
be protected with HIP_HMAC and signatures (even though the illustrations in this specification omit them for simplicity) according to [RFC 7401
]. Each connectivity check sent by a host MUST
include a SEQ parameter and ECHO_REQUEST_SIGNED parameter; correspondingly, the peer MUST
respond to these using ACK and ECHO_RESPONSE_SIGNED according to the rules specified in [RFC 7401
The host sending a connectivity check MUST
validate that the response uses the same pair of UDP ports, and drop the packet if this is not the case.
A host may receive a connectivity check before it has received the candidates from its peer. In such a case, the host MUST
immediately queue a response by placing it in the triggered-check queue and then continue waiting for the candidates. A host MUST NOT
select a candidate pair until it has verified the pair using a connectivity check as defined in Section 4.6.1
of RFC 7401
states that UPDATE packets have to include either a SEQ or ACK parameter (but can include both). In the connectivity check procedure specified in Section 4.6.1
, each SEQ parameter should be acknowledged separately. In the context of NATs, this means that some of the SEQ parameters sent in connectivity checks will be lost or arrive out of order. From the viewpoint of the recipient, this is not a problem since the recipient will just "blindly" acknowledge the SEQ. However, the sender needs to be prepared for lost sequence identifiers and ACK parameters that arrive out of order.
As specified in [RFC 7401
], an ACK parameter may acknowledge multiple sequence identifiers. While the examples in the previous sections do not illustrate such functionality, it is also permitted when employing ICE-HIP-UDP mode.
In ICE-HIP-UDP mode, a retransmission of a connectivity check SHOULD
be sent with the same sequence identifier in the SEQ parameter. Some tested address candidates will never produce a working address pair and may thus cause retransmissions. Upon successful nomination of an address pair, a host SHOULD
immediately stop sending such retransmissions.
Full ICE procedures for prioritizing candidates, eliminating redundant candidates, forming checklists (including pruning), and triggered-check queues MUST
be followed as specified in Section 6.1
of RFC 8445
, with the exception being that the foundation, frozen candidates, and default candidates are not used. From the viewpoint of the ICE specification [RFC 8445
], the protocol specified in this document operates using a component ID of 1 on all candidates, and the foundation of all candidates is unique. This specification defines only "full ICE" mode, and the "lite ICE" is not supported. The reasoning behind the missing features is described in Appendix B
The connectivity check messages MUST
be paced by the Ta 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 50 ms MUST
Both hosts MUST
form a priority ordered checklist and begin to check transactions every Ta milliseconds as long as the checks are running and there are candidate pairs whose tests have not started. The retransmission timeout (RTO) for the connectivity check UPDATE packets SHOULD
be calculated as follows:
RTO = MAX (1000 ms, 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 [RFC 8445
] when there is only one checklist. A smaller value than 1000 ms for the RTO MUST NOT
Each connectivity check request packet MUST
contain a CANDIDATE_PRIORITY parameter (see Section 5.14
) with the priority value that would be assigned to a peer-reflexive candidate if one was learned from the corresponding check. An UPDATE packet that acknowledges a connectivity check request MUST
be sent from the same address that received the check and delivered to the same address where the check was received from. Each acknowledgment UPDATE packet MUST
contain a MAPPED_ADDRESS parameter with the port, protocol, and IP address of the address where the connectivity check request was received from.
Following the ICE guidelines [RFC 8445
], it is RECOMMENDED
to restrict the total number of connectivity checks to 100 for each host association. This can be achieved by limiting the connectivity checks to the 100 candidate pairs with the highest priority.
The controlling agent may find multiple working candidate pairs. To conclude the connectivity checks, it SHOULD
nominate the pair with the highest priority. The controlling agent MUST
nominate a candidate pair essentially by repeating a connectivity check using an UPDATE message that contains a SEQ parameter (with a new sequence number), an ECHO_REQUEST_SIGNED parameter, the priority of the candidate in a CANDIDATE_PRIORITY parameter, and a NOMINATE parameter to signify conclusion of the connectivity checks. Since the nominated address pair has already been tested for reachability, the controlled host should be able to receive the message. Upon reception, the controlled host SHOULD
select the nominated address pair. The response message MUST
include a SEQ parameter with a new sequence identifier, acknowledgment of the sequence from the controlling host in an ACK parameter, a new ECHO_REQUEST_SIGNED parameter, an ECHO_RESPONSE_SIGNED parameter corresponding to the ECHO_REQUEST_SIGNED parameter from the controlling host, and the NOMINATE parameter. After sending this packet, the controlled host can create IPsec security associations using the nominated address candidate for delivering application payload to the controlling host. Since the message from the controlled host included a new sequence identifier echo request for the signature, the controlling host MUST
acknowledge this with a new UPDATE message that includes an ACK and ECHO_RESPONSE_SIGNED parameters. After this final concluding message, the controlling host also can create IPsec security associations for delivering application payload to the controlled host.
It is possible that packets are delayed by the network. Both hosts MUST
continue to respond to any connectivity checks despite an address pair having been nominated.
If all the connectivity checks have 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
If the Responder has a fixed and publicly reachable IPv4 address and does not employ a Control Relay Server, the explicit NAT traversal mode negotiation MAY
be omitted; thus, even the UDP-ENCAPSULATION mode does not have to be negotiated. In such a scenario, the Initiator sends an I1 message over UDP and the Responder responds with an R1 message over UDP without including any NAT traversal mode parameter. The rest of the base exchange follows the procedures defined in [RFC 7401
], except that the control and data plane use UDP encapsulation. Here, the use of UDP for NAT traversal is agreed upon implicitly. This way of operation is still subject to NAT timeouts, and the hosts MUST
employ NAT keepalives as defined in Section 4.10
When UDP-ENCAPSULATION mode is chosen either explicitly or implicitly, the connectivity checks as defined in this document MUST NOT
be used. When hosts lose connectivity, they MUST
instead utilize [RFC 8046
] or [RFC 8047
] procedures, but with the difference being that UDP-based tunneling MUST
be employed for the entire lifetime of the corresponding HIP association.
It is possible to run a base exchange without any connectivity checks as defined in Legacy ICE-HIP (Section 4.8
of RFC 5770
). The procedure is also applicable in the context of this specification, so it is repeated here for completeness.
In certain network environments, the connectivity checks can be omitted to reduce initial connection setup 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 Control Relay Server in order to discover its address candidates, it MUST
also include a LOCATOR_SET parameter encapsulated inside an ENCRYPTED parameter in an R1 message 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 Initiator MUST
use the source address of the R1 as the Responder's preferred address.
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 the connectivity checks defined in this document 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 address candidates, since connectivity checks defined in this document 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 according to the rules in Section 4.4
of RFC 7401
The Control Relay Server can be used for discovering address candidates but it is not intended to be used for relaying end-host packets using the UDP-ENCAPSULATION NAT mode. Since an I2 packet with UDP-ENCAPSULATION NAT traversal mode selected MUST NOT
be sent via a Control Relay Server, 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 Control Relay Server, but it MUST NOT
choose UDP-ENCAPSULATION NAT traversal mode for that I2.
It is possible to run a base exchange in parallel both with and without UDP encapsulation as defined in Legacy ICE-HIP (Section 4.9
of RFC 5770
). The procedure is also applicable in the context of this specification, so it is repeated here for completeness.
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 passing a Control Relay Server, at the Responder. When this happens, the procedures in [RFC 7401
] 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 retransmissions of the R1 message received first MUST
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 [RFC 8004
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 [RFC 7401
]. 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.
The same considerations with regard to sending control packets after the base exchange as described in Legacy ICE-HIP (Section 5.10
of RFC 5770
) also apply here, so they are repeated here for completeness.
After the base exchange, the two 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 any Control Relay Servers. When a host does not receive acknowledgments, e.g., to an UPDATE or CLOSE packet after a timeout based on local policies, a host SHOULD
resend the packet through the associated Data Relay Server of the peer (if the peer listed it in its LOCATOR_SET parameter in the base exchange according to the rules specified in Section 4.4.2
of RFC 7401
If a Control Relay Client sends a packet through a Control Relay Server, the Control Relay Client MUST
always utilize the RELAY_TO parameter. The Control Relay Server SHOULD
forward HIP control packets originating from a Control Relay Client to the address denoted in the RELAY_TO parameter. In the other direction, the Control Relay Server SHOULD
forward HIP control packets to the Control Relay Clients and MUST
add a RELAY_FROM parameter to the control packets it relays to the Control Relay Clients.
If the Control Relay Server is not 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
A host may move after base exchange and connectivity checks. Mobility extensions for HIP [RFC 8046
] define handover procedures without NATs. In this section, we define how two hosts interact with handover procedures in scenarios involving NATs. The specified extensions define only simple mobility using a pair of security associations, and multihoming extensions are left to be defined in later specifications. The procedures in this section offer the same functionality as "ICE restart" specified in [RFC 8445
]. The example described in this section shows only a Control Relay Server for the peer host for the sake of simplicity, but the mobile host may also have a Control Relay Server.
The assumption here is that the two hosts have successfully negotiated and chosen the ICE-HIP-UDP mode during the base exchange as defined in Section 4.3
. The Initiator of the base exchange MUST
store information that it was the controlling host during the base exchange. Similarly, the Responder MUST
store information that it was the controlled host during the base exchange.
Prior to starting the handover procedures with all peer hosts, the mobile host SHOULD
first send its locators in UPDATE messages to its Control and Data Relay Servers if it has registered to such. It SHOULD
wait for all of them to respond for a configurable time, by default two minutes, and then continue with the handover procedure without information from the Relay Server that did not respond. As defined in Section 4.1
, a response message from a Control Relay Server includes a REG_FROM parameter that describes the server-reflexive candidate of the mobile host to be used in the candidate exchange during the handover. Similarly, an UPDATE to a Data Relay Server is necessary to make sure the Data Relay Server can forward data to the correct IP address after a handover.
The mobility extensions for NAT traversal are illustrated in Figure 6
. The mobile host is the host that has changed its locators, and the peer host is the host it has a host association with. The mobile host may have multiple peers, and it repeats the process with all of its peers. In the figure, the Control Relay Server belongs to the peer host, i.e., the peer host is a Control Relay Client for the Control Relay Server. Note that the figure corresponds to figure 3 in [RFC 8046
], but the difference is that the main UPDATE procedure is carried over the relay and the connectivity is tested separately. Next, we describe the procedure of that figure in detail.
Mobile Host Control Relay Server Peer Host
| 1. UDP(UPDATE(ESP_INFO, | |
| ENC(LOC_SET), SEQ)) | |
+--------------------------------->| 2. UDP(UPDATE(ESP_INFO, |
| | ENC(LOC_SET), SEQ, |
| | RELAY_FROM)) |
| | |
| | 3. UDP(UPDATE(ESP_INFO, SEQ, |
| | ACK, ECHO_REQ_SIGN, |
| | RELAY_TO)) |
| 4. UDP(UPDATE(ESP_INFO, SEQ, |<-------------------------------+
| ACK, ECHO_REQ_SIGN, | |
| RELAY_TO)) | |
| | |
| 5. UDP(UPDATE(ACK, | |
| ECHO_RESP_SIGNED)) | |
+--------------------------------->| 6. UDP(UPDATE(ACK, |
| | ECHO_RESP_SIGNED, |
| | RELAY_FROM)) |
| | |
| 7. connectivity checks over UDP |
| | |
| 8. ESP data over UDP |
| | |
In step 1, the mobile host has changed location and sends a location update to its peer through the Control Relay Server of the peer. It sends an UPDATE packet with the source HIT belonging to itself and destination HIT belonging to the peer host. In the packet, the source IP address belongs to the mobile host and the destination to the Control Relay Server. The packet contains an ESP_INFO parameter where, in this case, the OLD SPI and NEW SPI parameters both contain the pre-existing incoming SPI. The packet also contains the locators of the mobile host in a LOCATOR_SET parameter, encapsulated inside an ENCRYPTED parameter (see Sections 5.2.18
in [RFC 7401
] for details on the ENCRYPTED parameter). The packet also contains a SEQ number to be acknowledged by the peer. As specified in [RFC 8046
], the packet may also include a HOST_ID (for middlebox inspection) and DIFFIE_HELLMAN parameter for rekeying.
In step 2, the Control Relay Server receives the UPDATE packet and forwards it to the peer host (i.e., Control Relay Client). The Control Relay Server rewrites the destination IP address and appends a RELAY_FROM parameter to the message.
In step 3, the peer host receives the UPDATE packet, processes it, and responds with another UPDATE message. The message is destined to the HIT of the mobile host and to the IP address of the Control Relay Server. The message includes an ESP_INFO parameter where, in this case, the OLD SPI and NEW SPI parameters both contain the pre-existing incoming SPI. The peer includes a new SEQ and ECHO_REQUEST_SIGNED parameter to be acknowledged by the mobile host. The message acknowledges the SEQ parameter of the earlier message with an ACK parameter. The RELAY_TO parameter specifies the address of the mobile host where the Control Relay Server should forward the message.
In step 4, the Control Relay Server receives the message, rewrites the destination IP address and UDP port according to the RELAY_TO parameter, and then forwards the modified message to the mobile host.
In step 5, the mobile host receives the UPDATE packet and processes it. The mobile host concludes the handover procedure by acknowledging the received SEQ parameter with an ACK parameter and the ECHO_REQUEST_SIGNED parameter with an ECHO_RESPONSE_SIGNED parameter. The mobile host sends the packet to the HIT of the peer and to the address of the HIP relay. The mobile host can start connectivity checks after this packet.
In step 6, the HIP relay receives the UPDATE packet and forwards it to the peer host (i.e., Relay Client). The HIP relay rewrites the destination IP address and port, and then appends a RELAY_FROM parameter to the message. When the peer host receives this concluding UPDATE packet, it can initiate the connectivity checks.
In step 7, the two hosts test for connectivity across NATs according to procedures described in Section 4.6
. The original Initiator of the communications is the controlling host and the original Responder is the controlled host.
In step 8, the connectivity checks are successfully completed and the controlling host has nominated one address pair to be used. The hosts set up security associations to deliver the application payload.
It is worth noting that the Control and Data Relay Client do not have to reregister for the related services after a handover. However, if a Data Relay Client has registered a relayed address candidate from a Data Relay Server, the Data Relay Client MUST
reactivate the address before the connectivity checks by sending an UPDATE message containing the PEER_PERMISSION parameter as described in Section 4.12.1
. Otherwise, the Data Relay Server drops ESP packets sent to the relayed address.
In the so-called "double jump" or simultaneous mobility scenario, both peers change their location simultaneously. In such a case, both peers trigger the procedure described earlier in this section at the same time. In other words, both of the communicating hosts send an UPDATE packet carrying locators at the same time or with some delay. When the locators are exchanged almost simultaneously (reliably via Control Relay Servers), the two hosts can continue with connectivity checks after both have completed separately the steps in Figure 6
. The problematic case occurs when one of the hosts (referred to here as host "M") moves later during the connectivity checks. In such a case, host M sends a locator to the peer, which is in the middle of connectivity checks. Upon receiving the UPDATE message, the peer responds with an UPDATE with ECHO_REQ_SIGN as described in step 3 in Figure 6
. Upon receiving the valid response from host M as described in step 6, the peer host MUST
restart the connectivity checks with host M. This way, both hosts start the connectivity checks roughly in a synchronized way. It is also important that the peer host does not restart the connectivity checks until step 6 is successfully completed, because the UPDATE message carrying locators in step 1 could be replayed by an attacker.
To prevent NAT states from expiring, communicating hosts MUST
send periodic keepalives to other hosts with which they have established a HIP association every 15 seconds (the so-called Tr value in ICE). Other values MAY
be used, but a Tr value smaller than 15 seconds MUST NOT
be used. Both a Control/Data Relay Client and Control/Data Relay Server, as well as two peers employing UDP-ENCAPSULATION or ICE-HIP-UDP mode, SHOULD
send HIP NOTIFY packets unless they have exchanged some other traffic over the used UDP ports. However, the Data Relay Client and Data Relay Server MUST
employ only HIP NOTIFY packets in order to keep the server-reflexive candidates alive. The keepalive message encoding format is defined in Section 5.3
. If the base exchange or mobility handover procedure occurs during an extremely slow path, a host (with a HIP association with the peer) MAY
also send HIP NOTIFY packets every 15 seconds to keep the path active with the recipient.
The two-way procedure for closing a HIP association and the related security associations is defined in [RFC 7401
]. One host initiates the procedure by sending a CLOSE message and the recipient confirms it with CLOSE_ACK. All packets are protected using HMACs and signatures, and the CLOSE messages include an ECHO_REQUEST_SIGNED parameter to protect against replay attacks.
The same procedure for closing HIP associations also applies here, but the messaging occurs using the UDP-encapsulated tunnel that the two hosts employ. A host sending the CLOSE message SHOULD
first send the message over a direct link. After a number of retransmissions, it MUST
send over a Control Relay Server of the recipient if one exists. The host receiving the CLOSE message directly without a Control Relay Server SHOULD
respond directly. If the CLOSE message came via a Control Relay Server, the host SHOULD
respond using the same Control Relay Server.
The Data Relay Server uses a similar permission model as a TURN server: before the Data Relay Server forwards any ESP data packets from a peer to a Data Relay Client (or the other direction), the client MUST
set a permission for the peer's address. The permissions also install a forwarding rule for each direction, similar to TURN's channels, based on the Security Parameter Index (SPI) values in the ESP packets.
Permissions are not required for HIP control packets. However, if a relayed address (as conveyed in the RELAYED_ADDRESS parameter from the Data Relay Server) is selected to be used for data, the Control Relay Client MUST
send an UPDATE message to the Data Relay Server containing a PEER_PERMISSION parameter (see Section 5.13
) with the following information: the UDP port and address for the server-reflexive address, the UDP port and address of the peer, and the inbound and outbound SPIs used for ESP. The packet MUST
be sent to the same UDP tunnel the Client employed in the base exchange to contact the Server (i.e., not to the port occupied by the server-reflexive candidate). To avoid packet dropping of ESP packets, the Control Relay Client SHOULD
send the PEER_PERMISSION parameter before connectivity checks both in the case of base exchange and a mobility handover. It is worth noting that the UPDATE message includes a SEQ parameter (as specified in [RFC 7401
]) that the Data Relay Server must acknowledge, so that the Control Relay Client can resend the message with the PEER_PERMISSION parameter if it gets lost.
When a Data Relay Server receives an UPDATE with a PEER_PERMISSION parameter, it MUST
check if the sender of the UPDATE is registered for data-relaying service, and drop the UPDATE if the host was not registered. If the host was registered, the Data Relay Server checks if there is a permission with matching information (protocol, addresses, ports, and SPI values). If there is no such permission, a new permission MUST
be created and its lifetime MUST
be set to 5 minutes. If an identical permission already existed, it MUST
be refreshed by setting the lifetime to 5 minutes. A Data Relay Client SHOULD
refresh permissions 1 minute before the expiration when the permission is still needed.
When a Data Relay Server receives an UPDATE from a registered client but without a PEER_PERMISSION parameter and with a new locator set, the Data Relay Server can assume that the mobile host has changed its location and is thus not reachable in its previous location. In such an event, the Data Relay Server SHOULD
deactivate the permission and stop relaying data plane traffic to the client.
The relayed address MUST
be activated with the PEER_PERMISSION parameter both after a base exchange and after a handover procedure with another ICE-HIP-UDP-capable host. Unless activated, the Data Relay Server MUST
drop all ESP packets. It is worth noting that a Data Relay Client does not have to renew its registration upon a change of location UPDATE, but only when the lifetime of the registration is close to end.
When a Data Relay Server accepts to relay UDP-encapsulated ESP between a Data Relay Client and its peer, the Data Relay Server opens a UDP port (relayed address) for this purpose as described in Section 4.1
. This port can be used for also delivering control packets because connectivity checks also cover the path through the Data Relay Server. If the Data Relay Server receives a UDP-encapsulated HIP control packet on that port, it MUST
forward the packet to the Data Relay Client and add a RELAY_FROM parameter to the packet as if the Data Relay Server were acting as a Control Relay Server. When the Data Relay Client replies to a control packet with a RELAY_FROM parameter via its Data Relay Server, the Data Relay Client MUST
add a RELAY_TO parameter containing the peer's address and use the address of its Data Relay Server as the destination address. Further, the Data Relay Server MUST
send this packet to the peer's address from the relayed address.
If the Data Relay Server receives a UDP packet that is not a HIP control packet to the relayed address, it MUST
check if it has a permission set for the peer the packet is arriving from (i.e., the sender's address and SPI value matches to an installed permission). If permissions are set, the Data Relay Server MUST
forward the packet to the Data Relay Client that created the permission. The Data Relay Server MUST
also implement the similar checks for the reverse direction (i.e., ESP packets from the Data Relay Client to the peer). Packets without a permission MUST
be dropped silently.
From the viewpoint of a host, its remote peers can have overlapping inbound SPI numbers because the IPsec also uses the destination IP address to index the remote peer host. However, a Data Relay Server can represent multiple remote peers, thus masquerading the actual destination. Since a Data Relay Server may have to deal with a multitude of Relay Clients and their peers, a Data Relay Server may experience collisions in the SPI namespace, thus being unable to forward datagrams to the correct destination. Since the SPI space is 32 bits and the SPI values should be random, the probability for a conflicting SPI value is fairly small but could occur on a busy Data Relay Server. The two problematic cases are described in this section.
In the first scenario, the SPI collision problem occurs if two hosts have registered to the same Data Relay Server and a third host initiates base exchange with both of them. Here, the two Responders (i.e., Data Relay Clients) claim the same inbound SPI number with the same Initiator (peer). However, in this case, the Data Relay Server has allocated separate UDP ports for the two Data Relay Clients acting now as Responders (as recommended in Section 7.5
). When the third host sends an ESP packet, the Data Relay Server is able to forward the packet to the correct Data Relay Client because the destination UDP port is different for each of the clients.
In the second scenario, an SPI collision may occur when two Initiators run a base exchange to the same Responder (i.e., Data Relay Client), and both of the Initiators claim the same inbound SPI at the Data Relay Server using the PEER_PERMISSION parameter. In this case, the Data Relay Server cannot disambiguate the correct destination of an ESP packet originating from the Data Relay Client because the SPI could belong to either of the peers (and the destination IP and UDP port belonging to the Data Relay Server are not unique either). The recommended way and a contingency plan to solve this issue are described below.
The recommend way to mitigate the problem is as follows. For each new HIP association, a Data Relay Client acting as a Responder SHOULD
register a new server-reflexive candidate as described in Section 4.2
. Similarly, the Data Relay Server SHOULD NOT
reuse the port numbers as described in Section 7.5
. This way, each server-reflexive candidate for the Data Relay Client has a separate UDP port that the Data Relay Server can use to disambiguate packet destinations in case of SPI collisions.
When the Data Relay Client is not registering or failed to register a new relay candidate for a new peer, the Data Relay Client MUST
follow a contingency plan as follows. Upon receiving an I2 with a colliding SPI, the Data Relay Client acting as the Responder MUST NOT
include the relayed address candidate in the R2 message because the Data Relay Server would not be able to demultiplex the related ESP packet to the correct Initiator. The same also applies to the handover procedures; the Data Relay Client MUST NOT
include the relayed address candidate when sending its new locator set in an UPDATE to its peer if it would cause an SPI conflict with another peer.