idnits 2.17.1 draft-ietf-hip-native-nat-traversal-19.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 1547 has weird spacing: '...eserved zero...' == Line 1587 has weird spacing: '... Min Ta the ...' == Line 1618 has weird spacing: '...eserved rese...' == Line 1620 has weird spacing: '...Address an ...' == Line 1810 has weird spacing: '...eserved reser...' == (5 more instances...) == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The document date (March 27, 2017) is 2587 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'Data' is mentioned on line 364, but not defined ** Downref: Normative reference to an Experimental RFC: RFC 5770 ** Obsolete normative reference: RFC 5389 (Obsoleted by RFC 8489) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) == Outdated reference: A later version (-20) exists of draft-ietf-ice-rfc5245bis-08 ** Downref: Normative reference to an Informational RFC: RFC 2475 -- Obsolete informational reference (is this intentional?): RFC 4423 (Obsoleted by RFC 9063) -- Obsolete informational reference (is this intentional?): RFC 5201 (Obsoleted by RFC 7401) -- Obsolete informational reference (is this intentional?): RFC 5766 (Obsoleted by RFC 8656) Summary: 4 errors (**), 0 flaws (~~), 11 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 HIP Working Group A. Keranen 3 Internet-Draft J. Melen 4 Intended status: Standards Track M. Komu, Ed. 5 Expires: September 28, 2017 Ericsson 6 March 27, 2017 8 Native NAT Traversal Mode for the Host Identity Protocol 9 draft-ietf-hip-native-nat-traversal-19 11 Abstract 13 This document specifies a new Network Address Translator (NAT) 14 traversal mode for the Host Identity Protocol (HIP). The new mode is 15 based on the Interactive Connectivity Establishment (ICE) methodology 16 and UDP encapsulation of data and signaling traffic. The main 17 difference from the previously specified modes is the use of HIP 18 messages for all NAT traversal procedures. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on September 28, 2017. 37 Copyright Notice 39 Copyright (c) 2017 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 3. Overview of Operation . . . . . . . . . . . . . . . . . . . . 6 57 4. Protocol Description . . . . . . . . . . . . . . . . . . . . 7 58 4.1. Relay Registration . . . . . . . . . . . . . . . . . . . 7 59 4.2. Transport Address Candidate Gathering . . . . . . . . . . 10 60 4.3. NAT Traversal Mode Negotiation . . . . . . . . . . . . . 12 61 4.4. Connectivity Check Pacing Negotiation . . . . . . . . . . 13 62 4.5. Base Exchange via HIP Relay Server . . . . . . . . . . . 14 63 4.6. Connectivity Checks . . . . . . . . . . . . . . . . . . . 17 64 4.6.1. Connectivity Check Procedure . . . . . . . . . . . . 17 65 4.6.2. Rules for Connectivity Checks . . . . . . . . . . . . 20 66 4.6.3. Rules for Concluding Connectivity Checks . . . . . . 22 67 4.7. NAT Traversal Alternatives . . . . . . . . . . . . . . . 23 68 4.7.1. Minimal NAT Traversal Support . . . . . . . . . . . . 23 69 4.7.2. Base Exchange without Connectivity Checks . . . . . . 23 70 4.7.3. Initiating a Base Exchange both with and without UDP 71 Encapsulation . . . . . . . . . . . . . . . . . . . . 24 72 4.8. Sending Control Packets after the Base Exchange . . . . . 25 73 4.9. Mobility Handover Procedure . . . . . . . . . . . . . . . 26 74 4.10. NAT Keepalives . . . . . . . . . . . . . . . . . . . . . 28 75 4.11. Closing Procedure . . . . . . . . . . . . . . . . . . . . 28 76 4.12. Relaying Considerations . . . . . . . . . . . . . . . . . 29 77 4.12.1. Forwarding Rules and Permissions . . . . . . . . . . 29 78 4.12.2. HIP Data Relay and Relaying of Control Packets . . . 30 79 4.12.3. Handling Conflicting SPI Values . . . . . . . . . . 30 80 5. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 31 81 5.1. HIP Control Packets . . . . . . . . . . . . . . . . . . . 32 82 5.2. Connectivity Checks . . . . . . . . . . . . . . . . . . . 32 83 5.3. Keepalives . . . . . . . . . . . . . . . . . . . . . . . 33 84 5.4. NAT Traversal Mode Parameter . . . . . . . . . . . . . . 33 85 5.5. Connectivity Check Transaction Pacing Parameter . . . . . 34 86 5.6. Relay and Registration Parameters . . . . . . . . . . . . 35 87 5.7. LOCATOR_SET Parameter . . . . . . . . . . . . . . . . . . 36 88 5.8. RELAY_HMAC Parameter . . . . . . . . . . . . . . . . . . 38 89 5.9. Registration Types . . . . . . . . . . . . . . . . . . . 38 90 5.10. Notify Packet Types . . . . . . . . . . . . . . . . . . . 38 91 5.11. ESP Data Packets . . . . . . . . . . . . . . . . . . . . 38 92 5.12. RELAYED_ADDRESS and MAPPED_ADDRESS Parameters . . . . . . 39 93 5.13. PEER_PERMISSION Parameter . . . . . . . . . . . . . . . . 40 94 5.14. HIP Connectivity Check Packets . . . . . . . . . . . . . 41 95 5.15. NOMINATE parameter . . . . . . . . . . . . . . . . . . . 42 96 6. Security Considerations . . . . . . . . . . . . . . . . . . . 42 97 6.1. Privacy Considerations . . . . . . . . . . . . . . . . . 42 98 6.2. Opportunistic Mode . . . . . . . . . . . . . . . . . . . 43 99 6.3. Base Exchange Replay Protection for HIP Relay Server . . 43 100 6.4. Demultiplexing Different HIP Associations . . . . . . . . 43 101 6.5. Reuse of Ports at the Data Relay . . . . . . . . . . . . 44 102 6.6. Amplification attacks . . . . . . . . . . . . . . . . . . 44 103 6.7. Attacks against Connectivity Checks and Candidate 104 Gathering . . . . . . . . . . . . . . . . . . . . . . . . 44 105 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 45 106 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 45 107 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 45 108 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 46 109 10.1. Normative References . . . . . . . . . . . . . . . . . . 46 110 10.2. Informative References . . . . . . . . . . . . . . . . . 47 111 Appendix A. Selecting a Value for Check Pacing . . . . . . . . . 48 112 Appendix B. Differences with respect to ICE . . . . . . . . . . 49 113 Appendix C. Differences to Base Exchange and UPDATE procedures . 50 114 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 52 116 1. Introduction 118 The Host Identity Protocol (HIP) [RFC7401] is specified to run 119 directly on top of IPv4 or IPv6. However, many middleboxes found in 120 the Internet, such as NATs and firewalls, often allow only UDP or TCP 121 traffic to pass [RFC5207]. Also, especially NATs usually require the 122 host behind a NAT to create a forwarding state in the NAT before 123 other hosts outside of the NAT can contact the host behind the NAT. 124 To overcome this problem, different methods, commonly referred to as 125 NAT traversal techniques, have been developed. 127 The HIP experiment report [RFC6538] mentions that Teredo based NAT 128 traversal for HIP and related ESP traffic (with double tunneling 129 overhead). Two HIP specific NAT traversal techniques for HIP are 130 specified in [RFC5770]. One of them uses only UDP encapsulation, 131 while the other uses also the Interactive Connectivity Establishment 132 (ICE) [I-D.ietf-ice-rfc5245bis] protocol, which in turn uses Session 133 Traversal Utilities for NAT (STUN) [RFC5389] and Traversal Using 134 Relays around NAT (TURN) [RFC5766] protocols to achieve a reliable 135 NAT traversal solution. 137 The benefit of using ICE and STUN/TURN is that one can re-use the NAT 138 traversal infrastructure already available in the Internet, such as 139 STUN and TURN servers. Also, some middleboxes may be STUN-aware and 140 may be able to do something "smart" when they see STUN being used for 141 NAT traversal. However, implementing a full ICE/STUN/TURN protocol 142 stack results in a considerable amount of effort and code which could 143 be avoided by re-using and extending HIP messages and state machines 144 for the same purpose. Thus, this document specifies an alternative 145 NAT traversal mode that uses HIP messages instead of STUN for the 146 connectivity check keepalives and data relaying. This document also 147 specifies how mobility management works in the context of NAT 148 traversal, which was missing from [RFC5770]. 150 2. Terminology 152 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 153 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 154 document are to be interpreted as described in [RFC2119]. 156 This document borrows terminology from [RFC5770], [RFC7401], 157 [RFC8046], [RFC4423], [I-D.ietf-ice-rfc5245bis], and [RFC5389]. The 158 following terms recur in the text: 160 HIP relay server: 161 A host that forwards any kind of HIP control packets between the 162 Initiator and the Responder. 164 HIP data relay: 165 A host that forwards HIP data packets, such as Encapsulating 166 Security Payload (ESP) [RFC7402], between two hosts. 168 Registered host: 169 A host that has registered for a relaying service with a HIP data 170 relay. 172 Locator: 173 As defined in [RFC8046]: "A name that controls how the packet is 174 routed through the network and demultiplexed by the end-host. It 175 may include a concatenation of traditional network addresses such 176 as an IPv6 address and end-to-end identifiers such as an ESP SPI. 177 It may also include transport port numbers or IPv6 Flow Labels as 178 demultiplexing context, or it may simply be a network address." 180 LOCATOR_SET (written in capital letters): 181 Denotes a HIP control packet parameter that bundles multiple 182 locators together. 184 ICE offer: 185 The Initiator's LOCATOR_SET parameter in a HIP I2 control packet. 186 Corresponds to the ICE offer parameter, but is HIP specific. 188 ICE answer: 189 The Responder's LOCATOR_SET parameter in a HIP R2 control packet. 190 Corresponds to the ICE answer parameter, but is HIP specific. 192 HIP connectivity checks: 193 In order to obtain a non-relayed communication path, two 194 communicating HIP hosts try to "punch holes" through their NAT 195 boxes using this mechanism. Similar to the ICE connectivity 196 checks, but implemented using HIP return routability checks. 198 Controlling host: 199 The controlling host nominates the candidate pair to be used with 200 the controlled host. 202 Controlled host: 203 The controlled host waits for the controlling to nominate an 204 address candidate pair. 206 Checklist: 207 A list of address candidate pairs that need to be tested for 208 connectivity. 210 Transport address: 211 Transport layer port and the corresponding IPv4/v6 address. 213 Candidate: 214 A transport address that is a potential point of contact for 215 receiving data. 217 Host candidate: 218 A candidate obtained by binding to a specific port from an IP 219 address on the host. 221 Server reflexive candidate: 222 A translated transport address of a host as observed by a HIP 223 relay server or a STUN/TURN server. 225 Peer reflexive candidate: 226 A translated transport address of a host as observed by its peer. 228 Relayed candidate: 229 A transport address that exists on a HIP data relay. Packets that 230 arrive at this address are relayed towards the registered host. 232 Permission: 233 In the context of HIP data relay, permission refers to a concept 234 similar to TURN's channels. Before a host can use a relayed 235 candidate to forward traffic through a HIP data relay, the host 236 must activate the relayed candidate with a specific peer host. 238 Base: 240 The base of an candidate is the local source address a host uses 241 to send packets for the associated candidate. For example, the 242 base of a server reflexive address is the local address the host 243 used for registering itself to the associated HIP relay. The base 244 of a host candidate is equal to the host candidate itself. 246 3. Overview of Operation 248 +-------+ 249 | HIP | 250 +--------+ | Relay | +--------+ 251 | Data | +-------+ | Data | 252 | Relay | / \ | Relay | 253 +--------+ / \ +--------+ 254 / \ 255 / \ 256 / \ 257 / <- Signaling -> \ 258 / \ 259 +-------+ +-------+ 260 | NAT | | NAT | 261 +-------+ +-------+ 262 / \ 263 / \ 264 +-------+ +-------+ 265 | Init- | | Resp- | 266 | iator | | onder | 267 +-------+ +-------+ 269 Figure 1: Example Network Configuration 271 In the example configuration depicted in Figure 1, both Initiator and 272 Responder are behind one or more NATs, and both private networks are 273 connected to the public Internet. To be contacted from behind a NAT, 274 the Responder must be registered with a HIP relay server reachable on 275 the public Internet, and we assume, as a starting point, that the 276 Initiator knows both the Responder's Host Identity Tag (HIT) and the 277 address of one of its relay servers (how the Initiator learns of the 278 Responder's relay server is outside of the scope of this document, 279 but may be through DNS or another name service). The Responder may 280 have also registered to a data relay that can forward the data plane 281 in case NAT penetration fails. It is worth noting that the HIP relay 282 and data relay functionality may be offered by two separate servers 283 or the same one. 285 The first steps are for both the Initiator and Responder to register 286 with a relay server (need not be the same one) and gather a set of 287 address candidates. The hosts may use HIP relay servers (or even 288 STUN or TURN servers) for gathering the candidates. Next, the HIP 289 base exchange is carried out by encapsulating the HIP control packets 290 in UDP datagrams and sending them through the Responder's relay 291 server. As part of the base exchange, each HIP host learns of the 292 peer's candidate addresses through the HIP offer/answer procedure 293 embedded in the base exchange, which follows closely the ICE 294 [I-D.ietf-ice-rfc5245bis] protocol. 296 Once the base exchange is completed, two HIP hosts have established a 297 working communication session (for signaling) via a HIP relay server, 298 but the hosts still have to find a better path, preferably without a 299 HIP data relay, for the ESP data flow. For this, connectivity checks 300 are carried out until a working pair of addresses is discovered. At 301 the end of the procedure, if successful, the hosts will have 302 established a UDP-based tunnel that traverses both NATs, with the 303 data flowing directly from NAT to NAT or via a HIP data relay server. 304 At this point, also the HIP signaling can be sent over the same 305 address/port pair, and is demultiplexed from IPsec as described in 306 the UDP encapsulation standard for IPsec [RFC3948]. Finally, the two 307 hosts send NAT keepalives as needed in order keep their UDP-tunnel 308 state active in the associated NAT boxes. 310 If either one of the hosts knows that it is not behind a NAT, hosts 311 can negotiate during the base exchange a different mode of NAT 312 traversal that does not use HIP connectivity checks, but only UDP 313 encapsulation of HIP and ESP. Also, it is possible for the Initiator 314 to simultaneously try a base exchange with and without UDP 315 encapsulation. If a base exchange without UDP encapsulation 316 succeeds, no HIP connectivity checks or UDP encapsulation of ESP are 317 needed. 319 4. Protocol Description 321 This section describes the normative behavior of the protocol 322 extension. Most of the procedures are similar to what is defined in 323 [RFC5770] but with different, or additional, parameter types and 324 values. In addition, a new type of relaying server, HIP data relay, 325 is specified. Also, it should be noted that HIP version 2 [RFC7401] 326 (instead of [RFC5201] used in [RFC5770]) is expected to be used with 327 this NAT traversal mode. 329 4.1. Relay Registration 331 In order for two hosts to communicate over NATted environments, they 332 need a reliable way to exchange information. HIP relay servers as 333 defined in [RFC5770] support relaying of HIP control plane traffic 334 over UDP in NATted environments. A HIP relay server forwards HIP 335 control packets between the Initiator and the Responder. 337 To guarantee also data plane delivery over varying types of NAT 338 devices, a host MAY also register for UDP encapsulated ESP relaying 339 using Registration Type RELAY_UDP_ESP (value [TBD by IANA: 3]). This 340 service may be coupled with the HIP relay server or offered 341 separately on another server. If the server supports relaying of UDP 342 encapsulated ESP, the host is allowed to register for a data relaying 343 service using the registration extensions in Section 3.3 of 344 [RFC8003]). If the server has sufficient relaying resources (free 345 port numbers, bandwidth, etc.) available, it opens a UDP port on one 346 of its addresses and signals the address and port to the registering 347 host using the RELAYED_ADDRESS parameter (as defined in Section 5.12 348 in this document). If the relay would accept the data relaying 349 request but does not currently have enough resources to provide data 350 relaying service, it MUST reject the request with Failure Type 351 "Insufficient resources" [RFC8003]. 353 A HIP relay server MUST silently drop packets to a HIP relay client 354 that has not previously registered with the HIP relay. The 355 registration process follows the generic registration extensions 356 defined in [RFC8003]. The HIP control plane relaying registration 357 follows [RFC5770], but the data plane registration is different. It 358 is worth noting that if the HIP control and data plane relay services 359 reside on different hosts, the relay client has to register 360 separately to each of them. In the example shown in Figure 2, the 361 two services are coupled on a single host. 363 HIP HIP 364 Relay [Data] Relay 365 Client Server 366 | 1. UDP(I1) | 367 +---------------------------------------------------------------->| 368 | | 369 | 2. UDP(R1(REG_INFO(RELAY_UDP_HIP,[RELAY_UDP_ESP]))) | 370 |<----------------------------------------------------------------+ 371 | | 372 | 3. UDP(I2(REG_REQ(RELAY_UDP_HIP),[RELAY_UDP_ESP])) | 373 +---------------------------------------------------------------->| 374 | | 375 | 4. UDP(R2(REG_RES(RELAY_UDP_HIP,[RELAY_UDP_ESP]), REG_FROM, | 376 | [RELAYED_ADDRESS])) | 377 |<----------------------------------------------------------------+ 378 | | 380 Figure 2: Example Registration with a HIP Relay 382 In step 1, the relay client (Initiator) starts the registration 383 procedure by sending an I1 packet over UDP to the relay. It is 384 RECOMMENDED that the Initiator select a random port number from the 385 ephemeral port range 49152-65535 for initiating a base exchange. 386 Alternatively, a host MAY also use a single fixed port for initiating 387 all outgoing connections. However, the allocated port MUST be 388 maintained until all of the corresponding HIP Associations are 389 closed. It is RECOMMENDED that the HIP relay server listen to 390 incoming connections at UDP port 10500. If some other port number is 391 used, it needs to be known by potential Initiators. 393 In step 2, the HIP relay server (Responder) lists the services that 394 it supports in the R1 packet. The support for HIP control plane over 395 UDP relaying is denoted by the Registration Type value RELAY_UDP_HIP 396 (see Section 5.9). If the server supports also relaying of ESP 397 traffic over UDP, it includes also Registration type value 398 RELAY_UDP_ESP. 400 In step 3, the Initiator selects the services for which it registers 401 and lists them in the REG_REQ parameter. The Initiator registers for 402 HIP relay service by listing the RELAY_UDP_HIP value in the request 403 parameter. If the Initiator requires also ESP relaying over UDP, it 404 lists also RELAY_UDP_ESP. 406 In step 4, the Responder concludes the registration procedure with an 407 R2 packet and acknowledges the registered services in the REG_RES 408 parameter. The Responder denotes unsuccessful registrations (if any) 409 in the REG_FAILED parameter of R2. The Responder also includes a 410 REG_FROM parameter that contains the transport address of the client 411 as observed by the relay (Server Reflexive candidate). If the 412 Initiator registered to ESP relaying service, the Responder includes 413 RELAYED_ADDRESS paramater that describes the UDP port allocated to 414 the Initiator for ESP relaying. It is worth noting that this client 415 must first activate this UDP port by sending an UPDATE message to the 416 relay server that includes a PEER_PERMISSION parameter as described 417 in Section 4.12.1 both after base exchange and handover procedures. 419 After the registration, the relay client sends periodically NAT 420 keepalives to the relay server in order to keep the NAT bindings 421 between the initiator and the relay alive. The keepalive extensions 422 are described in Section 4.10. 424 The registered host MUST maintain an active HIP association with the 425 data relay as long as it requires the data relaying service. When 426 the HIP association is closed (or times out), or the registration 427 lifetime passes without the registered host refreshing the 428 registration, the data relay MUST stop relaying packets for that host 429 and close the corresponding UDP port (unless other registered hosts 430 are still using it). 432 The data relay MAY use the same relayed address and port for multiple 433 registered hosts, but since this can cause problems with stateful 434 firewalls (see Section 6.5) it is NOT RECOMMENDED. 436 When a registered client sends an UPDATE (e.g., due to host movement 437 or to renew service registration), the relay server MUST follow the 438 general guidelines defined in [RFC8003], with the difference that all 439 UPDATE messages are delivered on top of UDP. In addition to this, 440 the relay server MUST include the REG_FROM parameter in all UPDATE 441 responses sent to the client. This applies both renewals of service 442 registration but also to host movement, where especially the latter 443 requires the client to learn its new server reflexive address 444 candidate. 446 4.2. Transport Address Candidate Gathering 448 A host needs to gather a set of address candidates before contacting 449 a non-relay host. The candidates are needed for connectivity checks 450 that allow two hosts to discover a direct, non-relayed path for 451 communicating with each other. One server reflexive candidate can be 452 discovered during the registration with the HIP relay server from the 453 REG_FROM parameter. 455 The candidate gathering can be done at any time, but it needs to be 456 done before sending an I2 or R2 in the base exchange if ICE-HIP-UDP 457 mode is to be used for the connectivity checks. It is RECOMMENDED 458 that all three types of candidates (host, server reflexive, and 459 relayed) are gathered to maximize the probability of successful NAT 460 traversal. However, if no data relay is used, and the host has only 461 a single local IP address to use, the host MAY use the local address 462 as the only host candidate and the address from the REG_FROM 463 parameter discovered during the relay registration as a server 464 reflexive candidate. In this case, no further candidate gathering is 465 needed. 467 If a host has more than one network interface, additional server 468 reflexive candidates can be discovered by sending registration 469 requests with Registration Type CANDIDATE_DISCOVERY (value [TBD by 470 IANA: 4]) from each of the interfaces to a HIP relay server. When a 471 HIP relay server receives a registration request with 472 CANDIDATE_DISCOVERY type, it MUST add a REG_FROM parameter, 473 containing the same information as if this were a relay registration, 474 to the response. This request type SHOULD NOT create any state at 475 the HIP relay server. 477 ICE guidelines for candidate gathering MUST be followed as described 478 in section 4.1.1 in [I-D.ietf-ice-rfc5245bis]. A number of host 479 candidates (loopback, anycast and others) should excluded as 480 described in section 4.1.1.1 of the ICE specification 481 [I-D.ietf-ice-rfc5245bis]. Relayed candidates SHOULD be gathered in 482 order to guarantee successful NAT traversal. It is RECOMMENDED for 483 implementations to support this functionality even if it will not be 484 used in deployments in order to enable it by software configuration 485 update if needed at some point. A host SHOULD employ only a relay 486 server for gathering the candidates for a single HIP association; 487 either a one server providing both HIP and data relay functionality, 488 or one HIP relay server and another one for data relaying if the 489 functionality is offered by another server. When the relay service 490 is split between two hosts, the server reflexive candidate from the 491 HIP relay SHOULD be used instead of the one provided by the data 492 relay. If a relayed candidate is identical to a host candidate, the 493 relayed candidate must be discarded. NAT64 considerations in section 494 4.1.1.2 of [I-D.ietf-ice-rfc5245bis] apply as well. 496 HIP based connectivity can be utilized by IPv4 applications using 497 LSIs and by IPv6 based applications using HITs. The LSIs and HITs of 498 the local virtual interfaces MUST be excluded in the candidate 499 gathering phase as well to avoid creating unnecessary loopback 500 connectivity tests. 502 Gathering of candidates MAY also be performed as specified in 503 Section 4.2 of [RFC5770] if STUN servers are available, or if the 504 host has just a single interface and no STUN or HIP data relay 505 servers are available. 507 Each local address candidate MUST be assigned a priority. The 508 recommended formula in [I-D.ietf-ice-rfc5245bis] SHOULD be used: 510 priority = (2^24)*(type preference) + (2^8)*(local preference) + 511 (2^0)*(256 - component ID) 513 In the formula, type preference follows the ICE specification section 514 4.1.2.2 guidelines: the RECOMMENDED values are 126 for host 515 candidates, 100 for server reflexive candidates, 110 for peer 516 reflexive candidates, and 0 for relayed candidates. The highest 517 value is 126 (the most preferred) and lowest is 0 (last resort). For 518 all candidates of the same type, the preference type value MUST be 519 identical, and, correspondingly, the value MUST be different for 520 different types. For peer reflexive values, the type preference 521 value MUST be higher than for server reflexive types. It should be 522 noted that peer reflexive values are learned later during 523 connectivity checks, so a host cannot employ it during candidate 524 gathering stage yet. 526 Following the ICE specification, the local preference MUST be an 527 integer from 0 (lowest preference) to 65535 (highest preference) 528 inclusive. In the case the host has only a single address candidate, 529 the value SHOULD be 65535. In the case of multiple candidates, each 530 local preference value MUST be unique. Dual-stack considerations for 531 IPv6 in section 4.1.2.2 in ICE apply also here. 533 Unlike ICE, this protocol only creates a single UDP flow between the 534 two communicating hosts, so only a single component exists. Hence, 535 the component ID value MUST always be set to 1. 537 As defined in ICE (in section 11.3), the retransmission timeout (RTO) 538 for address gathering from a relay SHOULD be calculated as follows: 540 RTO = MAX (500ms, Ta * (Num-Of-Pairs)) 542 where Ta is the value used for Ta is the value used for the 543 connectivity check pacing and Num-Of-Pairs is number of pairs of 544 candidates with relay servers (e.g. in the case of a single relay 545 server, it would be 1). A smaller value than 500 ms for the RTO MUST 546 NOT be used. 548 4.3. NAT Traversal Mode Negotiation 550 This section describes the usage of a new non-critical parameter 551 type. The presence of the parameter in a HIP base exchange means 552 that the end-host supports NAT traversal extensions described in this 553 document. As the parameter is non-critical (as defined in 554 Section 5.2.1 of [RFC7401]), it can be ignored by an end-host, which 555 means that the host is not required to support it or may decline to 556 use it. 558 With registration with a HIP relay, it is usually sufficient to use 559 the UDP-ENCAPSULATION mode of NAT traversal since the relay is 560 assumed to be in public address space. Thus, the relay SHOULD 561 propose the UDP-ENCAPSULATION mode as the preferred or only mode. 562 The NAT traversal mode negotiation in a HIP base exchange is 563 illustrated in Figure 3. It is worth noting that the HIP relay could 564 be located between the hosts, but is omitted here for simplicity. 566 Initiator Responder 567 | 1. UDP(I1) | 568 +--------------------------------------------------------------->| 569 | | 570 | 2. UDP(R1(.., NAT_TRAVERSAL_MODE(ICE-HIP-UDP), ..)) | 571 |<---------------------------------------------------------------+ 572 | | 573 | 3. UDP(I2(.., NAT_TRAVERSAL_MODE(ICE-HIP-UDP), LOC_SET, ..)) | 574 +--------------------------------------------------------------->| 575 | | 576 | 4. UDP(R2(.., LOC_SET, ..)) | 577 |<---------------------------------------------------------------+ 578 | | 580 Figure 3: Negotiation of NAT Traversal Mode 582 In step 1, the Initiator sends an I1 to the Responder. In step 2, 583 the Responder responds with an R1. As specified in [RFC5770], the 584 NAT_TRAVERSAL_MODE parameter in R1 contains a list of NAT traversal 585 modes the Responder supports. The mode specified in this document is 586 ICE-HIP-UDP (value [TBD by IANA: 3]). 588 In step 3, the Initiator sends an I2 that includes a 589 NAT_TRAVERSAL_MODE parameter. It contains the mode selected by the 590 Initiator from the list of modes offered by the Responder. If ICE- 591 HIP-UDP mode was selected, the I2 also includes the "Transport 592 address" locators (as defined in Section 5.7) of the Initiator in a 593 LOCATOR_SET parameter (denoted here LOC_SET). The locators in I2 are 594 the "ICE offer". 596 In step 4, the Responder concludes the base exchange with an R2 597 packet. If the Initiator chose ICE NAT traversal mode, the Responder 598 includes a LOCATOR_SET parameter in the R2 packet. The locators in 599 R2, encoded like the locators in I2, are the "ICE answer". If the 600 NAT traversal mode selected by the Initiator is not supported by the 601 Responder, the Responder SHOULD reply with a NOTIFY packet with type 602 NO_VALID_NAT_TRAVERSAL_MODE_PARAMETER and abort the base exchange. 604 4.4. Connectivity Check Pacing Negotiation 606 As explained in [RFC5770], when a NAT traversal mode with 607 connectivity checks is used, new transactions should not be started 608 too fast to avoid congestion and overwhelming the NATs. For this 609 purpose, during the base exchange, hosts can negotiate a transaction 610 pacing value, Ta, using a TRANSACTION_PACING parameter in R1 and I2 611 packets. The parameter contains the minimum time (expressed in 612 milliseconds) the host would wait between two NAT traversal 613 transactions, such as starting a new connectivity check or retrying a 614 previous check. The value that is used by both of the hosts is the 615 higher of the two offered values. 617 The minimum Ta value SHOULD be configurable, and if no value is 618 configured, a value of 50 ms MUST be used. Guidelines for selecting 619 a Ta value are given in Appendix A. Hosts SHOULD NOT use values 620 smaller than 5 ms for the minimum Ta, since such values may not work 621 well with some NATs, as explained in [I-D.ietf-ice-rfc5245bis]. The 622 Initiator MUST NOT propose a smaller value than what the Responder 623 offered. If a host does not include the TRANSACTION_PACING parameter 624 in the base exchange, a Ta value of 50 ms MUST be used as that host's 625 minimum value. 627 4.5. Base Exchange via HIP Relay Server 629 This section describes how the Initiator and Responder perform a base 630 exchange through a HIP relay server. Connectivity pacing (denoted as 631 TA_P here) was described in Section 4.4 and is neither repeated here. 632 Similarly, the NAT traversal mode negotiation process (denoted as 633 NAT_TM in the example) was described in Section 4.3 and is neither 634 repeated here. If a relay receives an R1 or I2 packet without the 635 NAT traversal mode parameter, it MUST drop it and SHOULD send a 636 NOTIFY error packet with type NO_VALID_NAT_TRAVERSAL_MODE_PARAMETER 637 to the sender of the R1 or I2. 639 It is RECOMMENDED that the Initiator send an I1 packet encapsulated 640 in UDP when it is destined to an IPv4 address of the Responder. 641 Respectively, the Responder MUST respond to such an I1 packet with a 642 UDP-encapsulated R1 packet, and also the rest of the communication 643 related to the HIP association MUST also use UDP encapsulation. 645 Figure 4 illustrates a base exchange via a HIP relay server. We 646 assume that the Responder (i.e. a HIP relay client) has already 647 registered to the HIP relay server. The Initiator may have also 648 registered to another (or the same relay server), but the base 649 exchange will traverse always through the relay of the Responder. 651 Initiator HIP relay Responder 652 | 1. UDP(I1) | | 653 +--------------------------------->| 2. UDP(I1(RELAY_FROM)) | 654 | +------------------------------->| 655 | | | 656 | | 3. UDP(R1(RELAY_TO, NAT_TM, | 657 | | TA_P)) | 658 | 4. UDP(R1(RELAY_TO, NAT_TM, |<-------------------------------+ 659 | TA_P)) | | 660 |<---------------------------------+ | 661 | | | 662 | 5. UDP(I2(LOC_SET, NAT_TM, | | 663 | TA_P)) | | 664 +--------------------------------->| 6. UDP(I2(LOC_SET, RELAY_FROM, | 665 | | NAT_TM, TA_P)) | 666 | +------------------------------->| 667 | | | 668 | | 7. UDP(R2(LOC_SET, RELAY_TO)) | 669 | 8. UDP(R2(LOC_SET, RELAY_TO)) |<-------------------------------+ 670 |<---------------------------------+ | 671 | | | 673 Figure 4: Base Exchange via a HIP Relay Server 675 In step 1 of Figure 4, the Initiator sends an I1 packet over UDP via 676 the relay server to the Responder. In the HIP header, the source HIT 677 belongs to the Initiator and the destination HIT to the Responder. 678 The initiator sends the I1 packet from its IP address to the IP 679 address of the HIP relay over UDP. 681 In step 2, the HIP relay server receives the I1 packet. If the 682 destination HIT belongs to a registered Responder, the relay 683 processes the packet. Otherwise, the relay MUST drop the packet 684 silently. The relay appends a RELAY_FROM parameter to the I1 packet, 685 which contains the transport source address and port of the I1 as 686 observed by the relay. The relay protects the I1 packet with 687 RELAY_HMAC as described in [RFC8004], except that the parameter type 688 is different (see Section 5.8). The relay changes the source and 689 destination ports and IP addresses of the packet to match the values 690 the Responder used when registering to the relay, i.e., the reverse 691 of the R2 used in the registration. The relay MUST recalculate the 692 transport checksum and forward the packet to the Responder. 694 In step 3, the Responder receives the I1 packet. The Responder 695 processes it according to the rules in [RFC7401]. In addition, the 696 Responder validates the RELAY_HMAC according to [RFC8004] and 697 silently drops the packet if the validation fails. The Responder 698 replies with an R1 packet to which it includes RELAY_TO and NAT 699 traversal mode parameters. The responder MUST include ICE-HIP-UDP in 700 the NAT traversal modes. The RELAY_TO parameter MUST contain the 701 same information as the RELAY_FROM parameter, i.e., the Initiator's 702 transport address, but the type of the parameter is different. The 703 RELAY_TO parameter is not integrity protected by the signature of the 704 R1 to allow pre-created R1 packets at the Responder. 706 In step 4, the relay receives the R1 packet. The relay drops the 707 packet silently if the source HIT belongs to an unregistered host. 708 The relay MAY verify the signature of the R1 packet and drop it if 709 the signature is invalid. Otherwise, the relay rewrites the source 710 address and port, and changes the destination address and port to 711 match RELAY_TO information. Finally, the relay recalculates 712 transport checksum and forwards the packet. 714 In step 5, the Initiator receives the R1 packet and processes it 715 according to [RFC7401]. The Initiator MAY use the address in the 716 RELAY_TO parameter as a local peer-reflexive candidate for this HIP 717 association if it is different from all known local candidates. The 718 Initiator replies with an I2 packet that uses the destination 719 transport address of R1 as the source address and port. The I2 720 packet contains a LOCATOR_SET parameter that lists all the HIP 721 candidates (ICE offer) of the Initiator. The candidates are encoded 722 using the format defined in Section 5.7. The I2 packet MUST also 723 contain a NAT traversal mode parameter that includes ICE-HIP-UDP 724 mode. 726 In step 6, the relay receives the I2 packet. The relay appends a 727 RELAY_FROM and a RELAY_HMAC to the I2 packet similarly as explained 728 in step 2, and forwards the packet to the Responder. 730 In step 7, the Responder receives the I2 packet and processes it 731 according to [RFC7401]. It replies with an R2 packet and includes a 732 RELAY_TO parameter as explained in step 3. The R2 packet includes a 733 LOCATOR_SET parameter that lists all the HIP candidates (ICE answer) 734 of the Responder. The RELAY_TO parameter is protected by the HMAC. 736 In step 8, the relay processes the R2 as described in step 4. The 737 relay forwards the packet to the Initiator. After the Initiator has 738 received the R2 and processed it successfully, the base exchange is 739 completed. 741 Hosts MUST include the address of one or more HIP relay servers 742 (including the one that is being used for the initial signaling) in 743 the LOCATOR_SET parameter in I2 and R2 if they intend to use such 744 servers for relaying HIP signaling immediately after the base 745 exchange completes. The traffic type of these addresses MUST be "HIP 746 signaling" and they MUST NOT be used as HIP candidates. If the HIP 747 relay server locator used for relaying the base exchange is not 748 included in I2 or R2 LOCATOR_SET parameters, it SHOULD NOT be used 749 after the base exchange. Instead, further HIP signaling SHOULD use 750 the same path as the data traffic. 752 4.6. Connectivity Checks 754 When the Initiator and Responder complete the base exchange through 755 the HIP relay, both of them employ the IP address of the relay as the 756 destination address for the packets. This address MUST NOT be used 757 as a destination for ESP traffic unless the HIP relay supports also 758 ESP data relaying. When NAT traversal mode with ICE-HIP-UDP was 759 successfully negotiated and selected, the Initiator and Responder 760 MUST start the connectivity checks in order to attempt to obtain 761 direct end-to-end connectivity through NAT devices. It is worth 762 noting that the connectivity checks MUST be completed even though no 763 ESP_TRANSFORM would be negotiated and selected. 765 The connectivity checks MUST follow the ICE methodology [MMUSIC-ICE], 766 but UDP encapsulated HIP control messages are used instead of ICE 767 messages. Only normal nomination MUST be used for the connectivity 768 checks, i.e., aggressive nomination MUST NOT be employed. As stated 769 in the ICE specification, the basic procedure for connectivity checks 770 has three phases: sorting the candidate pairs according their 771 priority, sending checks in the prioritized order and acknowledging 772 the checks from the peer host. 774 The Initiator MUST take the role of controlling host and the 775 Responder acts as the controlled host. The roles MUST persist 776 throughout the HIP associate lifetime (to be reused in the possibly 777 mobility UPDATE procedures). In the case both communicating nodes 778 are initiating the communications to each other using an I1 packet, 779 the conflict is resolved as defined in section 6.7 in [RFC7401]: the 780 host with the "larger" HIT changes to its Role to Responder. In such 781 a case, the host changing its role to Responder MUST also switch to 782 controlling role. 784 The protocol follows standard HIP UPDATE sending and processing rules 785 as defined in section 6.11 and 6.12 in [RFC7401], but some new 786 parameters are introduced (CANDIDATE_PRIORITY, MAPPED_ADDRESS and 787 NOMINATE). 789 4.6.1. Connectivity Check Procedure 791 Figure 5 illustrates connectivity checks in a simplified scenario, 792 where the Initiator and Responder have only a single candidate pair 793 to check. Typically, NATs drop messages until both sides have sent 794 messages using the same port pair. In this scenario, the Responder 795 sends a connectivity check first but the NAT of the Initiator drops 796 it. However, the connectivity check from the Initiator reaches the 797 Responder because it uses the same port pair as the first message. 798 It is worth noting that the message flow in this section is 799 idealistic, and, in practice, more messages would be dropped, 800 especially in the beginning. For instance, connectivity tests always 801 start with the candidates with the highest priority, which would be 802 host candidates (which would not reach the recipient in this 803 scenario). 805 Initiator NAT1 NAT2 Responder 806 | | 1. UDP(UPDATE(SEQ, CAND_PRIO, | | 807 | | ECHO_REQ_SIGN)) | | 808 | X<-----------------------------------+----------------+ 809 | | | | 810 | 2. UDP(UPDATE(SEQ, ECHO_REQ_SIGN, CAND_PRIO)) | | 811 +-------------+------------------------------------+--------------->| 812 | | | | 813 | 3. UDP(UPDATE(ACK, ECHO_RESP_SIGN, MAPPED_ADDR)) | | 814 |<------------+------------------------------------+----------------+ 815 | | | | 816 | 4. UDP(UPDATE(SEQ, ECHO_REQ_SIGN, CAND_PRIO)) | | 817 |<------------+------------------------------------+----------------+ 818 | | | | 819 | 5. UDP(UPDATE(ACK, ECHO_RESP_SIGN, MAPPED_ADDR)) | | 820 +-------------+------------------------------------+--------------->| 821 | | | | 822 | 6. Other connectivity checks using UPDATE over UDP | 823 |<------------+------------------------------------+----------------> 824 | | | | 825 | 7. UDP(UPDATE(SEQ, ECHO_REQ_SIGN, CAND_PRIO, NOMINATE)) | 826 +-------------+------------------------------------+--------------->| 827 | | | | 828 | 8. UDP(UPDATE(SEQ, ACK, ECHO_REQ_SIGN, ECHO_RESP_SIGN, | 829 | NOMINATE)) | | 830 |<------------+------------------------------------+----------------+ 831 | | | | 832 | 9. UDP(UPDATE(ACK, ECHO_RESP_SIGN)) | | 833 +-------------+------------------------------------+--------------->+ 834 | | | | 835 | 10. ESP data traffic over UDP | | 836 +<------------+------------------------------------+--------------->+ 837 | | | | 839 Figure 5: Connectivity Checks 841 In step 1, the Responder sends a connectivity check to the Initiator 842 that the NAT of the Initiator drops. The message includes a number 843 of parameters. As specified in [RFC7401]), the SEQ parameter 844 includes a running sequence identifier for the connectivity check. 845 The candidate priority (denoted "CAND_PRIO" in the figure) describes 846 the priority of the address candidate being tested. The 847 ECHO_REQUEST_SIGNED (denoted ECHO_REQ_SIGN in the figure) includes a 848 nonce that the recipient must sign and echo back as it is. 850 In step 2, the Initiator sends a connectivity check, using the same 851 address pair candidate as in the previous step, and the message 852 traverses successfully the NAT boxes. The message includes the same 853 parameters as in the previous step. It should be noted that the 854 sequence identifier is locally assigned by the Responder, so it can 855 be different than in the previous step. 857 In step 3, the Responder has successfully received the previous 858 connectivity check from the Initiator and starts to build a response 859 message. Since the message from the Initiator included a SEQ, the 860 Responder must acknowledge it using an ACK parameter. Also, the 861 nonce contained in the echo request must be echoed back in an 862 ECHO_REQUEST_SIGNED (denoted ECHO_REQUEST_SIGN) parameter. The 863 Responder includes also a MAPPED_ADDRESS parameter (denoted 864 MAPPED_ADDR in the figure) that contains the transport address of the 865 Initiator as observed by the Responder (i.e. peer reflexive 866 candidate). This message is successfully delivered to the Initiator, 867 and upon reception the Initiator marks the candidate pair as valid. 869 In step 4, the Responder retransmits the connectivity check sent in 870 the first step, since it was not acknowledged yet. 872 In step 5, the Initiator responds to the previous connectivity check 873 message from the Responder. The Initiator acknowledges the SEQ 874 parameter from the previous message using ACK parameter and the 875 ECHO_REQUEST_SIGN parameter with ECHO_RESPONSE_SIGNED. In addition, 876 it includes MAPPED_ADDR parameter that includes the peer reflexive 877 candidate. This response message is successfully delivered to the 878 Responder, and upon reception the Initiator marks the candidate pair 879 as valid. 881 In step 6, despite the two hosts now having valid address candidates, 882 the hosts still test the remaining address candidates in a similar 883 way as in the previous steps (due to the use of normal nomination). 884 It should be noted that each connectivity check has a unique sequence 885 number in the SEQ parameter. 887 In step 7, the Initiator has completed testing all address candidates 888 and nominates one address candidate to be used. It sends an UPDATE 889 message using the selected address candidates that includes a number 890 of parameters: SEQ, ECHO_REQUEST_SIGN, CANDIDATE_PRIORITY and the 891 NOMINATE parameter. 893 In step 8, the Responder receives the message with NOMINATE parameter 894 from the Initiator. It sends a response that includes the NOMINATE 895 parameter in addition to a number of other parameters. The ACK and 896 ECHO_RESPONSE_SIGNED parameters acknowledge the SEQ and 897 ECHO_REQUEST_SIGN parameters from previous message from the 898 Initiator. The Responder includes SEQ and ECHO_REQUEST_SIGN 899 parameters in order to receive an acknowledgment from the Responder. 901 In step 9, the Initiator completes the candidate nomination process 902 by confirming the message reception to the Responder. In the 903 confirmation message, the ACK and ECHO_RESPONSE_SIGNED parameters 904 correspond to the SEQ and ECHO_REQUEST_SIGN parameters in the message 905 sent by the Responder in the previous step. 907 In step 10, the Initiator and Responder can start sending application 908 payload over the successfully nominated address candidates. 910 It is worth noting that if either host has registered a relayed 911 address candidate from a data relay, the host MUST activate the 912 address before connectivity checks by sending an UPDATE message 913 containing PEER_PERMISSION parameter as described in Section 4.12.1. 914 Otherwise, the relay drops ESP packets using the relayed address. 916 4.6.2. Rules for Connectivity Checks 918 The HITs of the two communicating hosts MUST be used as credentials 919 in this protocol (in contrast to ICE which employs username-password 920 fragments). A HIT pair uniquely identifies the corresponding HIT 921 association, and a SEQ number in an UPDATE message identifies a 922 particular connectivity check. 924 All of the connectivity check packets MUST be protected with HMACs 925 and signatures (even though the illustrations omitted them for 926 simplicity). Each connectivity check sent by a host MUST include a 927 SEQ parameter and ECHO_REQUEST_SIGN parameter, and correspondingly 928 the peer MUST respond to these using ACK and ECHO_RESPONSE_SIGNED 929 according to the rules specified in [RFC7401]. 931 The host sending a connectivity check MUST validate that the response 932 uses the same pair of UDP ports, and drop the packet if this is not 933 the case. 935 A host may receive a connectivity check before it has received the 936 candidates from its peer. In such a case, the host MUST immediately 937 generate a response, and then continue waiting for the candidates. A 938 host MUST NOT select a candidate pair until it has verified the pair 939 using a connectivity check as defined in section Section 4.6.1. 941 [RFC7401] states that UPDATE packets have to include either a SEQ or 942 ACK parameter (or both). According to the RFC, each SEQ parameter 943 should be acknowledged separately. In the context of NATs, this 944 means that some of the SEQ parameters sent in connectivity checks 945 will be lost or arrive out of order. From the viewpoint of the 946 recipient, this is not a problem since the recipient will just 947 "blindly" acknowledge the SEQ. However, the sender needs to be 948 prepared for lost sequence identifiers and ACKs parameters that 949 arrive out of order. 951 As specified in [RFC7401], an ACK parameter may acknowledge multiple 952 sequence identifiers. While the examples in the previous sections do 953 not illustrate such functionality, it is also permitted when 954 employing ICE-HIP-UDP mode. 956 In ICE-HIP-UDP mode, a retransmission of a connectivity check SHOULD 957 be sent with the same sequence identifier in the SEQ parameter. Some 958 tested address candidates will never produce a working address pair, 959 and thus may cause retransmissions. Upon successful nomination an 960 address pair, a host MAY immediately stop sending such 961 retransmissions. 963 ICE procedures for prioritizing candidates, eliminating redundant 964 candidates and forming check lists (including pruning) MUST be 965 followed as specified in [I-D.ietf-ice-rfc5245bis], with the 966 exception that the foundation, frozen candidates and default 967 candidates are not used. From viewpoint of the ICE specification 968 [I-D.ietf-ice-rfc5245bis], the protocol specified in this document 969 operates using Component ID of 1 on all candidates, and the 970 foundation of all candidates is unique. This specification defines 971 only "full ICE" mode, and the "lite ICE" is not supported. The 972 reasoning behind the missing features is described in Appendix B. 974 The connectivity check messages MUST be paced by the Ta value 975 negotiated during the base exchange as described in Section 4.4. If 976 neither one of the hosts announced a minimum pacing value, a value of 977 20 ms SHOULD be used. 979 Both hosts MUST form a priority ordered checklist and begin to check 980 transactions every Ta milliseconds as long as the checks are running 981 and there are candidate pairs whose tests have not started. The 982 retransmission timeout (RTO) for the connectivity check UPDATE 983 packets SHOULD be calculated as follows: 985 RTO = MAX (500ms, Ta * (Num-Waiting + Num-In-Progress)) 987 In the RTO formula, Ta is the value used for the connectivity check 988 pacing, Num-Waiting is the number of pairs in the checklist in the 989 "Waiting" state, and Num-In-Progress is the number of pairs in the 990 "In-Progress" state. This is identical to the formula in 991 [I-D.ietf-ice-rfc5245bis] when there is only one checklist. A 992 smaller value than 500 ms for the RTO MUST NOT be used. 994 Each connectivity check request packet MUST contain a 995 CANDIDATE_PRIORITY parameter (see Section 5.14) with the priority 996 value that would be assigned to a peer reflexive candidate if one was 997 learned from the corresponding check. An UPDATE packet that 998 acknowledges a connectivity check request MUST be sent from the same 999 address that received the check and delivered to the same address 1000 where the check was received from. Each acknowledgment UPDATE packet 1001 MUST contain a MAPPED_ADDRESS parameter with the port, protocol, and 1002 IP address of the address where the connectivity check request was 1003 received from. 1005 Following ICE guidelines [I-D.ietf-ice-rfc5245bis], it is RECOMMENDED 1006 to restrict the total number of connectivity checks to 100 for each 1007 host association. This can be achieved by limiting the connectivity 1008 checks to the 100 candidate pairs with the highest priority. 1010 4.6.3. Rules for Concluding Connectivity Checks 1012 The controlling agent may find multiple working candidate pairs. To 1013 conclude the connectivity checks, it SHOULD nominate the pair with 1014 the highest priority. The controlling agent MUST nominate a 1015 candidate pair essentially by repeating a connectivity check using an 1016 UPDATE message that contains a SEQ parameter (with new sequence 1017 number), a ECHO_REQUEST_SIGN parameter, the priority of the candidate 1018 in a CANDIDATE_PRIORITY parameter and NOMINATE parameter to signify 1019 conclusion of the connectivity checks. Since the nominated address 1020 pair has already been tested for reachability, the controlled host 1021 should be able to receive the message. Upon reception, the 1022 controlled host SHOULD select the nominated address pair. The 1023 response message MUST include a SEQ parameter with a new sequence id, 1024 acknowledgment of the sequence from the controlling host in an ACK 1025 parameter, a new ECHO_REQUEST_SIGNED parameter, ECHO_RESPONSE_SIGNED 1026 parameter corresponding to the ECHO_REQUEST_SIGNED parameter from the 1027 controlling host and the NOMINATE parameter. After sending this 1028 packet, the controlled host can create IPsec security associations 1029 using the nominated address candidate for delivering application 1030 payload to the controlling host. Since the message from the 1031 controlled host included a new sequence id and echo request for 1032 signature, the controlling host MUST acknowledge this with a new 1033 UPDATE message that includes an ACK and ECHO_RESPONSE_SIGNED 1034 parameters. After this final concluding message, the controlling 1035 host also can create IPsec security associations for delivering 1036 application payload to the controlled host. 1038 It is possible that packets are delayed by the network. Both hosts 1039 MUST continue to respond to any connectivity checks despite an 1040 address pair having been nominated. 1042 If all the connectivity checks have failed, the hosts MUST NOT send 1043 ESP traffic to each other but MAY continue communicating using HIP 1044 packets and the locators used for the base exchange. Also, the hosts 1045 SHOULD notify each other about the failure with a 1046 CONNECTIVITY_CHECKS_FAILED NOTIFY packet (see Section 5.10). 1048 4.7. NAT Traversal Alternatives 1050 4.7.1. Minimal NAT Traversal Support 1052 If the Responder has a fixed and publicly reachable IPv4 address and 1053 does not employ a HIP relay, the explicit NAT traversal mode 1054 negotiation MAY be omitted, and thus even the UDP-ENCAPSULATION mode 1055 does not have to be negotiated. In such a scenario, the Initiator 1056 sends an I1 message over UDP and the Responder responds with an R1 1057 message over UDP without including any NAT traversal mode parameter. 1058 The rest of the base exchange follows the procedures defined in 1059 [RFC7401], except that the control and data plane use UDP 1060 encapsulation. Here, the use of UDP for NAT traversal is agreed 1061 implicitly. This way of operation is still subject to NAT timeouts, 1062 and the hosts MUST employ NAT keepalives as defined in Section 4.10. 1064 4.7.2. Base Exchange without Connectivity Checks 1066 It is possible to run a base exchange without any connectivity checks 1067 as defined in section 4.8 in [RFC5770]. The procedure is applicable 1068 also in the context of this specification, so it is repeated here for 1069 completeness. 1071 In certain network environments, the connectivity checks can be 1072 omitted to reduce initial connection set-up latency because a base 1073 exchange acts as an implicit connectivity test itself. For this to 1074 work, the Initiator MUST be able to reach the Responder by simply UDP 1075 encapsulating HIP and ESP packets sent to the Responder's address. 1076 Detecting and configuring this particular scenario is prone to 1077 failure unless carefully planned. 1079 In such a scenario, the Responder MAY include UDP-ENCAPSULATION NAT 1080 traversal mode as one of the supported modes in the R1 packet. If 1081 the Responder has registered to a HIP relay server, it MUST also 1082 include a LOCATOR_SET parameter in R1 that contains a preferred 1083 address where the Responder is able to receive UDP-encapsulated ESP 1084 and HIP packets. This locator MUST be of type "Transport address", 1085 its Traffic type MUST be "both", and it MUST have the "Preferred bit" 1086 set (see Table 1). If there is no such locator in R1, the source 1087 address of R1 is used as the Responder's preferred address. 1089 The Initiator MAY choose the UDP-ENCAPSULATION mode if the Responder 1090 listed it in the supported modes and the Initiator does not wish to 1091 use the connectivity checks defined in this document for searching 1092 for a more optimal path. In this case, the Initiator sends the I2 1093 with UDP-ENCAPSULATION mode in the NAT traversal mode parameter 1094 directly to the Responder's preferred address (i.e., to the preferred 1095 locator in R1 or to the address where R1 was received from if there 1096 was no preferred locator in R1). The Initiator MAY include locators 1097 in I2 but they MUST NOT be taken as address candidates, since 1098 connectivity checks defined in this document will not be used for 1099 connections with UDP-ENCAPSULATION NAT traversal mode. Instead, if 1100 R2 and I2 are received and processed successfully, a security 1101 association can be created and UDP-encapsulated ESP can be exchanged 1102 between the hosts after the base exchange completes. However, the 1103 Responder SHOULD NOT send any ESP to the Initiator's address before 1104 it has received data from the Initiator, as specified in Sections 1105 4.4.3. and 6.9 of [RFC7401] and in Sections 3.2.9 and 5.4 of 1106 [RFC8046]. 1108 Since an I2 packet with UDP-ENCAPSULATION NAT traversal mode selected 1109 MUST NOT be sent via a relay, the Responder SHOULD reject such I2 1110 packets and reply with a NO_VALID_NAT_TRAVERSAL_MODE_PARAMETER NOTIFY 1111 packet (see Section 5.10). 1113 If there is no answer for the I2 packet sent directly to the 1114 Responder's preferred address, the Initiator MAY send another I2 via 1115 the HIP relay server, but it MUST NOT choose UDP-ENCAPSULATION NAT 1116 traversal mode for that I2. 1118 4.7.3. Initiating a Base Exchange both with and without UDP 1119 Encapsulation 1121 It is possible to run a base exchange in parallel both with and 1122 without UDP encapsulation as defined in section 4.9 in [RFC5770]. 1123 The procedure is applicable also in the context of this 1124 specification, so it is repeated here for completeness. 1126 The Initiator MAY also try to simultaneously perform a base exchange 1127 with the Responder without UDP encapsulation. In such a case, the 1128 Initiator sends two I1 packets, one without and one with UDP 1129 encapsulation, to the Responder. The Initiator MAY wait for a while 1130 before sending the other I1. How long to wait and in which order to 1131 send the I1 packets can be decided based on local policy. For 1132 retransmissions, the procedure is repeated. 1134 The I1 packet without UDP encapsulation may arrive directly, without 1135 any relays, at the Responder. When this happens, the procedures in 1136 [RFC7401] are followed for the rest of the base exchange. The 1137 Initiator may receive multiple R1 packets, with and without UDP 1138 encapsulation, from the Responder. However, after receiving a valid 1139 R1 and answering it with an I2, further R1 packets that are not 1140 retransmissions of the original R1 message MUST be ignored. 1142 The I1 packet without UDP encapsulation may also arrive at a HIP- 1143 capable middlebox. When the middlebox is a HIP rendezvous server and 1144 the Responder has successfully registered with the rendezvous 1145 service, the middlebox follows rendezvous procedures in [RFC8004]. 1147 If the Initiator receives a NAT traversal mode parameter in R1 1148 without UDP encapsulation, the Initiator MAY ignore this parameter 1149 and send an I2 without UDP encapsulation and without any selected NAT 1150 traversal mode. When the Responder receives the I2 without UDP 1151 encapsulation and without NAT traversal mode, it will assume that no 1152 NAT traversal mechanism is needed. The packet processing will be 1153 done as described in [RFC7401]. The Initiator MAY store the NAT 1154 traversal modes for future use, e.g., in case of a mobility or 1155 multihoming event that causes NAT traversal to be used during the 1156 lifetime of the HIP association. 1158 4.8. Sending Control Packets after the Base Exchange 1160 The same considerations of sending control packets after the base 1161 exchange described in section 5.10 in [RFC5770] apply also here, so 1162 they are repeated here for completeness. 1164 After the base exchange, the end-hosts MAY send HIP control packets 1165 directly to each other using the transport address pair established 1166 for a data channel without sending the control packets through the 1167 HIP relay server. When a host does not get acknowledgments, e.g., to 1168 an UPDATE or CLOSE packet after a timeout based on local policies, 1169 the host SHOULD resend the packet through the relay, if it was listed 1170 in the LOCATOR_SET parameter in the base exchange. 1172 If control packets are sent through a HIP relay server, the host 1173 registered with the relay MUST utilize the RELAY_TO parameter as in 1174 the base exchange. The HIP relay server SHOULD forward HIP packets 1175 to the registered hosts and forward packets from a registered host to 1176 the address in the RELAY_TO parameter. The relay MUST add a 1177 RELAY_FROM parameter to the control packets it relays to the 1178 registered hosts. 1180 If the HIP relay server is not willing or able to relay a HIP packet, 1181 it MAY notify the sender of the packet with MESSAGE_NOT_RELAYED error 1182 notification (see Section 5.10). 1184 4.9. Mobility Handover Procedure 1186 A host may move after base exchange and connectivity checks. 1187 Mobility extensions for HIP [RFC8046] define handover procedures 1188 without NATs. In this section, we define how two hosts interact with 1189 handover procedures in scenarios involving NATs. The specified 1190 extensions define only simple mobility using a pair of security 1191 associations, and multihoming extensions are left to be defined in 1192 later specifications. The procedures in this section offer the same 1193 functionality as "ICE restart" specified in 1194 [I-D.ietf-ice-rfc5245bis]. The example described in this section 1195 shows only a relay server for the peer host for the sake of 1196 simplicity, but also the mobile host may also have a relay server. 1198 The assumption here is that the two hosts have successfully 1199 negotiated and chosen the ICE-HIP-UDP mode during the base exchange 1200 as defined in Section 4.3. The Initiator of the base exchange MUST 1201 store information that it was the controlling host during the base 1202 exchange. Similarly, the Responder MUST store information that it 1203 was the controlled host during the base exchange. 1205 Prior to starting the handover procedures with all peer hosts, the 1206 mobile host SHOULD first send UPDATE messages to its HIP and data 1207 relays if it has registered to such. It SHOULD wait for all of them 1208 to respond for two minutes and then continue with the handover 1209 procedure without information from the relays that did not respond. 1210 As defined in section Section 4.1, a response message from a relay 1211 includes a REG_FROM parameter that describes the server reflexive 1212 candidate of the mobile host to be used in the candidate exchange 1213 during the handover. Similarly, an UPDATE to a data relay is 1214 necessary to make sure the data relay can forward data to the correct 1215 IP address after a handoff. 1217 The mobility extensions for NAT traversal are illustrated in 1218 Figure 6. The mobile host is the host that has changed its locators, 1219 and the peer host is the host it has a host association with. The 1220 mobile host may have multiple peers and it repeats the process with 1221 all of its peers. In the figure, the HIP relay belongs to the peer 1222 host, i.e., the peer host is a relay client for the HIP relay. Next, 1223 we describe the procedure in the figure in detail. 1225 Mobile Host HIP relay Peer Host 1226 | 1. UDP(UPDATE(ESP_INFO, | | 1227 | LOC_SET, SEQ)) | | 1228 +--------------------------------->| 2. UDP(UPDATE(ESP_INFO, | 1229 | | LOC_SET, SEQ, | 1230 | | RELAY_FROM)) | 1231 | +------------------------------->| 1232 | | | 1233 | | 3. UDP(UPDATE(ESP_INFO, ACK, | 1234 | | ECHO_REQ_SIGN)) | 1235 | 4. UDP(UPDATE(ESP_INFO, ACK, |<-------------------------------+ 1236 | ECHO_REQ_SIGN, | | 1237 | RELAY_TO)) | | 1238 |<---------------------------------+ | 1239 | | | 1240 | 5. connectivity checks over UDP | 1241 +<----------------------------------------------------------------->+ 1242 | | | 1243 | 6. ESP data over UDP | 1244 +<----------------------------------------------------------------->+ 1245 | | | 1247 Figure 6: HIP UPDATE procedure 1249 In step 1, the mobile host has changed location and sends a location 1250 update to its peer through the HIP relay of the peer. It sends an 1251 UPDATE packet with source HIT belonging to itself and destination HIT 1252 belonging to the peer host. In the packet, the source IP address 1253 belongs to the mobile host and the destination to the HIP relay. The 1254 packet contains an ESP_INFO parameter, where, in this case, the OLD 1255 SPI and NEW SPI parameters both contain the pre-existing incoming 1256 SPI. The packet also contains the locators of the mobile host in a 1257 LOCATOR_SET parameter. The packet contains also a SEQ number to be 1258 acknowledged by the peer. As specified in [RFC8046], the packet may 1259 also include a HOST_ID (for middlebox inspection) and DIFFIE_HELLMAN 1260 parameter for rekeying. 1262 In step 2, the HIP relay receives the UPDATE packet and forwards it 1263 to the peer host (i.e. relay client). The HIP relay rewrites the 1264 destination IP address and appends a RELAY_FROM parameter to the 1265 message. 1267 In step 3, the peer host receives the UPDATE packet, processes it and 1268 responds with another UPDATE message. The message is destined to the 1269 HIT of mobile host and to the IP address of the HIP relay. The 1270 message includes an ESP_INFO parameter where, in this case, the OLD 1271 SPI and NEW SPI parameters both contain the pre-existing incoming 1272 SPI. The peer includes a new SEQ and ECHO_REQUEST_SIGNED parameters 1273 to be acknowledged by the mobile host. The message acknowledges the 1274 SEQ parameter of the earlier message with an ACK parameter. After 1275 this step, the peer host can initiate the connectivity checks. 1277 In step 4, the HIP relay receives the message, rewrites the 1278 destination IP address, appends an RELAY_TO parameter and forwards 1279 the modified message to the mobile host. When mobile host has 1280 processed the message successfully, it can initiate the connectivity 1281 checks. 1283 In step 5, the two hosts test for connectivity across NATs according 1284 to procedures described in Section 4.6. The original Initiator of 1285 the communications is the controlling and the original Responder is 1286 the controlled host. 1288 In step 6, the connectivity checks are successfully completed and the 1289 controlling host has nominated one address pair to be used. The 1290 hosts set up security associations to deliver the application 1291 payload. 1293 If either host has registered a relayed address candidate from a data 1294 relay, the host MUST reactivate the address before connectivity 1295 checks by sending an UPDATE message containing PEER_PERMISSION 1296 parameter as described in Section 4.12.1. Otherwise, the relay drops 1297 ESP packets using the relayed address. 1299 4.10. NAT Keepalives 1301 To prevent NAT states from expiring, communicating hosts send 1302 periodic keepalives to other hosts with which they have established a 1303 host associating. Both a registered client and relay server SHOULD 1304 send HIP NOTIFY packets to each other every 15 seconds (the so called 1305 Tr value in ICE) unless they have exchange some other traffic over 1306 the used UDP ports. Other values MAY be used, but a Tr value smaller 1307 than 15 seconds MUST NOT be used. The keepalive message encoding 1308 format is defined in Section 5.3. If the base exchange or mobility 1309 handover procedure occurs during an extremely slow path, a host MAY 1310 also send HIP NOTIFY packet every 15 seconds to keep the path active 1311 with the recipient. 1313 4.11. Closing Procedure 1315 The two-way procedure for closing a HIP association and the related 1316 security associations is defined in [RFC7401]. One host initiates 1317 the procedure by sending a CLOSE message and the recipient confirms 1318 it with CLOSE_ACK. All packets are protected using HMACs and 1319 signatures, and the CLOSE messages includes a ECHO_REQUEST_SIGNED 1320 parameter to protect against replay attacks. 1322 The same procedure for closing HIP associations applies also here, 1323 but the messaging occurs using the UDP encapsulated tunnel that the 1324 two hosts employ. A host sending the CLOSE message SHOULD first send 1325 the message over a direct link. After a number of retransmissions, 1326 it MUST send over a HIP relay of the recipient if one exists. The 1327 host receiving the CLOSE message directly without a relay SHOULD 1328 respond directly. If CLOSE message came via a relay, the host SHOULD 1329 respond using the same relay. 1331 4.12. Relaying Considerations 1333 4.12.1. Forwarding Rules and Permissions 1335 The HIP data relay uses a similar permission model as a TURN server: 1336 before the data relay forwards any ESP data packets from a peer to a 1337 registered host (or the other direction), the client MUST set a 1338 permission for the peer's address. The permissions also install a 1339 forwarding rule for each direction, similar to TURN's channels, based 1340 on the Security Parameter Index (SPI) values in the ESP packets. 1342 Permissions are not required for HIP control packets. However, if a 1343 relayed address (as conveyed in the RELAYED_ADDRESS parameter from 1344 the data relay) is selected to be used for data, the registered host 1345 MUST send an UPDATE message to the data relay containing a 1346 PEER_PERMISSION parameter (see Section 5.13) with the address of the 1347 peer, and the outbound and inbound SPI values the registered host is 1348 using with this particular peer. To avoid packet dropping of ESP 1349 packets, the registered host SHOULD send the PEER_PERMISSION 1350 parameter before connectivity checks both in the case of base 1351 exchange and a mobility handover. It is worth noting that the UPDATE 1352 message includes a SEQ parameter (as specified in [RFC7401]) that the 1353 data relay must acknowledge, so that the registered host can resend 1354 the message with PEER_PERMISSION parameter if it gets lost. 1356 When a data relay receives an UPDATE with a PEER_PERMISSION 1357 parameter, it MUST check if the sender of the UPDATE is registered 1358 for data relaying service, and drop the UPDATE if the host was not 1359 registered. If the host was registered, the relay checks if there is 1360 a permission with matching information (address, protocol, port and 1361 SPI values). If there is no such permission, a new permission MUST 1362 be created and its lifetime MUST be set to 5 minutes. If an 1363 identical permission already existed, it MUST be refreshed by setting 1364 the lifetime to 5 minutes. A registered host SHOULD refresh 1365 permissions 1 minute before the expiration when the permission is 1366 still needed. 1368 When a data relay receives an UPDATE from a registered client but 1369 without a PEER_PERMISSION parameter and with a new locator set, the 1370 relay can assume that the mobile host has changed its location and, 1371 thus, is not reachable in its previous location. In such an event, 1372 the data relay SHOULD deactivate the permission and stop relaying 1373 data plane traffic to the client. 1375 The relayed address MUST be activated with the PEER_PERMISSION 1376 parameter both after a base exchange and after a handover procedure 1377 with another ICE-HIP-UDP capable host. Unless activated, the data 1378 relay MUST drop all ESP packets. It is worth noting that a relay 1379 client does not have to renew its registration upon a change of 1380 location UPDATE, but only when the lifetime of the registration is 1381 close to end. 1383 4.12.2. HIP Data Relay and Relaying of Control Packets 1385 When a HIP data relay accepts to relay UDP encapsulated ESP between a 1386 registered host and its peer, the relay opens a UDP port (relayed 1387 address) for this purpose as described in Section 4.1. This port can 1388 be used for delivering also control packets because connectivity 1389 checks also cover the path through the data relay. If the data relay 1390 receives a UDP encapsulated HIP control packet on that port, it MUST 1391 forward the packet to the registered host and add a RELAY_FROM 1392 parameter to the packet as if the data relay were acting as a HIP 1393 relay server. When the registered host replies to a control packet 1394 with a RELAY_FROM parameter via its relay, the registered host MUST 1395 add a RELAY_TO parameter containing the peer's address and use the 1396 address of its data relay as the destination address. Further, the 1397 data relay MUST send this packet to the peer's address from the 1398 relayed address. 1400 If the data relay receives a UDP packet that is not a HIP control 1401 packet to the relayed address, it MUST check if it has a permission 1402 set for the peer the packet is arriving from (i.e., the sender's 1403 address and SPI value matches to an installed permission). If 1404 permissions are set, the data relay MUST forward the packet to the 1405 registered host that created the permission. The data relay MUST 1406 also implement the similar checks for the reverse direction (i.e. 1407 ESP packets from the registered host to the peer). Packets without a 1408 permission MUST be dropped silently. 1410 4.12.3. Handling Conflicting SPI Values 1412 The inbound SPI values of the registered clients should be unique so 1413 that a data relay can properly demultiplex incoming packets from peer 1414 hosts to the correct registered clients. Likewise, the inbound SPIs 1415 of the peer hosts should be unique for the same reason. These two 1416 cases are discussed in this section separately. 1418 In first case, the SPI collision problem occurs when two Initiators 1419 run a base exchange to the same Responder (i.e. registered host), and 1420 both the Initiators claim the same inbound SPI. This is not a 1421 problem for Responder since the two Initiators can be distinguished 1422 by their transport addresses. However, it is an issue for the data 1423 relay because the it cannot demultiplex packets from the Initiator to 1424 the correct Responder. Thus, upon receiving an I2 with a colliding 1425 SPI, the Responder MUST NOT include the relayed address candidate in 1426 the R2 message because the data relay would not be able demultiplex 1427 the related ESP packet to the correct Initiator. The same applies 1428 also the handover procedure; the registered host MUST NOT include the 1429 relayed address candidate when sending its new locator set in an 1430 UPDATE to its peer if it would cause a SPI conflict with another 1431 peer. Since the SPI space is 32 bits and the SPI values should be 1432 random, the probability for a conflicting SPI value is fairly small. 1433 However, a registered host with many peers MAY proactively decrease 1434 the odds of a conflict by registering to multiple data relays. The 1435 described collision scenario can be avoided if the Responder delivers 1436 a new relayed address candidate upon SPI collisions. Each relayed 1437 address has a separate UDP port reserved to it, so the relay can 1438 demultiplex properly conflicting SPIs of the Initiators based on the 1439 SPI and port number towards the correct Responder. 1441 In the second case, the SPI collision problems occurs if two hosts 1442 have registered to the same data relay and a third host initiates 1443 base exchange with both of them. In this case, the data relay has 1444 allocated separate UDP ports for the two registered hosts acting now 1445 as Responders. When the Responders send identical SPI values in 1446 their I2 messages via the relay, the relay can properly deliver the 1447 message to the correct Responder because the UDP ports are different. 1449 5. Packet Formats 1451 The following subsections define the parameter and packet encodings 1452 for the HIP and ESP packets. All values MUST be in network byte 1453 order. 1455 It is worth noting that most of the parameters are shown for the sake 1456 of completeness even though they are specified already in [RFC5770]. 1457 New parameters are explicitly described as new. 1459 5.1. HIP Control Packets 1461 Figure 7 illustrates the packet format for UDP-encapsulated HIP. The 1462 format is identical to [RFC5770]. 1464 0 1 2 3 1465 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 1466 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1467 | Source Port | Destination Port | 1468 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1469 | Length | Checksum | 1470 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1471 | 32 bits of zeroes | 1472 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1473 | | 1474 ~ HIP Header and Parameters ~ 1475 | | 1476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1478 Figure 7: Format of UDP-Encapsulated HIP Control Packets 1480 HIP control packets are encapsulated in UDP packets as defined in 1481 Section 2.2 of [RFC3948], "IKE Header Format for Port 4500", except 1482 that a different port number is used. Figure 7 illustrates the 1483 encapsulation. The UDP header is followed by 32 zero bits that can 1484 be used to differentiate HIP control packets from ESP packets. The 1485 HIP header and parameters follow the conventions of [RFC7401] with 1486 the exception that the HIP header checksum MUST be zero. The HIP 1487 header checksum is zero for two reasons. First, the UDP header 1488 already contains a checksum. Second, the checksum definition in 1489 [RFC7401] includes the IP addresses in the checksum calculation. The 1490 NATs that are unaware of HIP cannot recompute the HIP checksum after 1491 changing IP addresses. 1493 A HIP relay server or a Responder without a relay SHOULD listen at 1494 UDP port 10500 for incoming UDP-encapsulated HIP control packets. If 1495 some other port number is used, it needs to be known by potential 1496 Initiators. 1498 5.2. Connectivity Checks 1500 HIP connectivity checks are HIP UPDATE packets. The format is 1501 specified in [RFC7401]. 1503 5.3. Keepalives 1505 The RECOMMENDED encoding format for keepalives is HIP NOTIFY packets 1506 as specified in [RFC7401] with Notify message type field set to 1507 NAT_KEEPALIVE [TBD by IANA: 16384] and with an empty Notification 1508 data field. It is worth noting that sending of such a HIP NOTIFY 1509 message MAY be omitted if the host is actively (or passively) sending 1510 other traffic to the peer host over the UDP tunnel associate with the 1511 host association (and IPsec security associations since the same port 1512 pair is reused) during the Tr period. For instance, the host MAY 1513 actively send ICMPv6 requests (or respond with an ICMPv6 response) 1514 inside the ESP tunnel to test the health of the associated IPsec 1515 security associations. Alternatively, the host MAY use UPDATE 1516 packets as a substitute. A minimal UPDATE packet would consist of a 1517 SEQ and ECHO_REQ_SIGN parameters, and a more complex would involve 1518 rekeying procedures as specified in section 6.8 in [RFC7402]. It is 1519 worth noting that a host actively sending periodic UPDATE packets to 1520 a busy server may increase the computational load of the server since 1521 it has to verify HMACs and signatures in UPDATE messages. 1523 5.4. NAT Traversal Mode Parameter 1525 The format of NAT traversal mode parameter is borrowed from 1526 [RFC5770]. The format of the NAT_TRAVERSAL_MODE parameter is similar 1527 to the format of the ESP_TRANSFORM parameter in [RFC7402] and is 1528 shown in Figure 8. This specification defines the traversal mode 1529 identifier for ICE-HIP-UDP and reuses the UDP-ENCAPSULATION mode from 1530 [RFC5770]. The identifier named RESERVED is reserved for future use. 1531 Future specifications may define more traversal modes. 1533 0 1 2 3 1534 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 1535 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1536 | Type | Length | 1537 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1538 | Reserved | Mode ID #1 | 1539 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1540 | Mode ID #2 | Mode ID #3 | 1541 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1542 | Mode ID #n | Padding | 1543 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1545 Type 608 1546 Length length in octets, excluding Type, Length, and padding 1547 Reserved zero when sent, ignored when received 1548 Mode ID defines the proposed or selected NAT traversal mode(s) 1550 The following NAT traversal mode IDs are defined: 1552 ID name Value 1553 RESERVED 0 1554 UDP-ENCAPSULATION 1 1555 ICE-HIP-UDP 3 1557 Figure 8: Format of the NAT_TRAVERSAL_MODE Parameter 1559 The sender of a NAT_TRAVERSAL_MODE parameter MUST make sure that 1560 there are no more than six (6) Mode IDs in one NAT_TRAVERSAL_MODE 1561 parameter. Conversely, a recipient MUST be prepared to handle 1562 received NAT traversal mode parameters that contain more than six 1563 Mode IDs by accepting the first six Mode IDs and dropping the rest. 1564 The limited number of Mode IDs sets the maximum size of the 1565 NAT_TRAVERSAL_MODE parameter. The modes MUST be in preference order, 1566 most preferred mode(s) first. 1568 Implementations conforming to this specification MUST implement UDP- 1569 ENCAPSULATION and SHOULD implement ICE-HIP-UDP modes. 1571 5.5. Connectivity Check Transaction Pacing Parameter 1573 The TRANSACTION_PACING is a new parameter, and it shown in Figure 9 1574 contains only the connectivity check pacing value, expressed in 1575 milliseconds, as a 32-bit unsigned integer. 1577 0 1 2 3 1578 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 1579 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1580 | Type | Length | 1581 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1582 | Min Ta | 1583 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1585 Type 610 1586 Length 4 1587 Min Ta the minimum connectivity check transaction pacing 1588 value the host would use (in milliseconds) 1590 Figure 9: Format of the TRANSACTION_PACING Parameter 1592 5.6. Relay and Registration Parameters 1594 The format of the REG_FROM, RELAY_FROM, and RELAY_TO parameters is 1595 shown in Figure 10. All parameters are identical except for the 1596 type. REG_FROM is the only parameter covered with the signature. 1598 0 1 2 3 1599 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 1600 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1601 | Type | Length | 1602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1603 | Port | Protocol | Reserved | 1604 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1605 | | 1606 | Address | 1607 | | 1608 | | 1609 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1611 Type REG_FROM: 950 1612 RELAY_FROM: 63998 1613 RELAY_TO: 64002 1614 Length 20 1615 Port transport port number; zero when plain IP is used 1616 Protocol IANA assigned, Internet Protocol number. 1617 17 for UDP, 0 for plain IP 1618 Reserved reserved for future use; zero when sent, ignored 1619 when received 1620 Address an IPv6 address or an IPv4 address in "IPv4-Mapped 1621 IPv6 address" format 1623 Figure 10: Format of the REG_FROM, RELAY_FROM, and RELAY_TO 1624 Parameters 1626 REG_FROM contains the transport address and protocol from which the 1627 HIP relay server sees the registration coming. RELAY_FROM contains 1628 the address from which the relayed packet was received by the relay 1629 server and the protocol that was used. RELAY_TO contains the same 1630 information about the address to which a packet should be forwarded. 1632 5.7. LOCATOR_SET Parameter 1634 This specification reuses the format for UDP-based locators specified 1635 in [RFC5770] to be used for communicating the address candidates 1636 between two hosts. The generic and NAT-traversal-specific locator 1637 parameters are illustrated in Figure 11. 1639 0 1 2 3 1640 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 1641 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1642 | Type | Length | 1643 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1644 | Traffic Type | Locator Type | Locator Length| Reserved |P| 1645 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1646 | Locator Lifetime | 1647 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1648 | Locator | 1649 | | 1650 | | 1651 | | 1652 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1653 . . 1654 . . 1655 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1656 | Traffic Type | Loc Type = 2 | Locator Length| Reserved |P| 1657 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1658 | Locator Lifetime | 1659 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1660 | Transport Port | Transp. Proto| Kind | 1661 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1662 | Priority | 1663 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1664 | SPI | 1665 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1666 | Address | 1667 | | 1668 | | 1669 | | 1670 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1672 Figure 11: LOCATOR_SET Parameter 1674 The individual fields in the LOCATOR_SET parameter are described in 1675 Table 1. 1677 +-----------+----------+--------------------------------------------+ 1678 | Field | Value(s) | Purpose | 1679 +-----------+----------+--------------------------------------------+ 1680 | Type | 193 | Parameter type | 1681 | Length | Variable | Length in octets, excluding Type and | 1682 | | | Length fields and padding | 1683 | Traffic | 0-2 | Is the locator for HIP signaling (1), for | 1684 | Type | | ESP (2), or for both (0) | 1685 | Locator | 2 | "Transport address" locator type | 1686 | Type | | | 1687 | Locator | 7 | Length of the fields after Locator | 1688 | Length | | Lifetime in 4-octet units | 1689 | Reserved | 0 | Reserved for future extensions | 1690 | Preferred | 0 or 1 | Set to 1 for a Locator in R1 if the | 1691 | (P) bit | | Responder can use it for the rest of the | 1692 | | | base exchange, otherwise set to zero | 1693 | Locator | Variable | Locator lifetime in seconds | 1694 | Lifetime | | | 1695 | Transport | Variable | Transport layer port number | 1696 | Port | | | 1697 | Transport | Variable | IANA assigned, transport layer Internet | 1698 | Protocol | | Protocol number. Currently only UDP (17) | 1699 | | | is supported. | 1700 | Kind | Variable | 0 for host, 1 for server reflexive, 2 for | 1701 | | | peer reflexive or 3 for relayed address | 1702 | Priority | Variable | Locator's priority as described in | 1703 | | | [I-D.ietf-ice-rfc5245bis]. It is worth | 1704 | | | noting that while the priority of a single | 1705 | | | locator candidate is 32-bits, but an | 1706 | | | implementation should use a 64-bit integer | 1707 | | | to calculate the priority of a candidate | 1708 | | | pair for the ICE priority algorithm. | 1709 | SPI | Variable | Security Parameter Index (SPI) value that | 1710 | | | the host expects to see in incoming ESP | 1711 | | | packets that use this locator | 1712 | Address | Variable | IPv6 address or an "IPv4-Mapped IPv6 | 1713 | | | address" format IPv4 address [RFC4291] | 1714 +-----------+----------+--------------------------------------------+ 1716 Table 1: Fields of the LOCATOR_SET Parameter 1718 5.8. RELAY_HMAC Parameter 1720 As specified in [RFC5770], the RELAY_HMAC parameter value has the TLV 1721 type 65520. It has the same semantics as RVS_HMAC [RFC8004]. 1723 5.9. Registration Types 1725 The REG_INFO, REG_REQ, REG_RESP, and REG_FAILED parameters contain 1726 Registration Type [RFC8003] values for HIP relay server registration. 1727 The value for RELAY_UDP_HIP is 2 as specified in [RFC5770]. 1729 5.10. Notify Packet Types 1731 A HIP relay server and end-hosts can use NOTIFY packets to signal 1732 different error conditions. The NOTIFY packet types are the same as 1733 in [RFC5770]. 1735 The Notify Packet Types [RFC7401] are shown below. The Notification 1736 Data field for the error notifications SHOULD contain the HIP header 1737 of the rejected packet and SHOULD be empty for the 1738 CONNECTIVITY_CHECKS_FAILED type. 1740 NOTIFICATION PARAMETER - ERROR TYPES Value 1741 ------------------------------------ ----- 1743 NO_VALID_NAT_TRAVERSAL_MODE_PARAMETER 60 1745 If a HIP relay server does not forward a base exchange packet due 1746 to missing NAT traversal mode parameter, or the Initiator selects 1747 a NAT traversal mode that the Responder did not expect, the relay 1748 or the Responder may send back a NOTIFY error packet with this 1749 type. 1751 CONNECTIVITY_CHECKS_FAILED 61 1753 Used by the end-hosts to signal that NAT traversal connectivity 1754 checks failed and did not produce a working path. 1756 MESSAGE_NOT_RELAYED 62 1758 Used by a HIP relay server to signal that is was not able or 1759 willing to relay a HIP packet. 1761 5.11. ESP Data Packets 1763 The format for ESP data packets is identical to [RFC5770]. 1765 [RFC3948] describes the UDP encapsulation of the IPsec ESP transport 1766 and tunnel mode. On the wire, the HIP ESP packets do not differ from 1767 the transport mode ESP, and thus the encapsulation of the HIP ESP 1768 packets is same as the UDP encapsulation transport mode ESP. 1769 However, the (semantic) difference to Bound End-to-End Tunnel (BEET) 1770 mode ESP packets used by HIP is that IP header is not used in BEET 1771 integrity protection calculation. 1773 During the HIP base exchange, the two peers exchange parameters that 1774 enable them to define a pair of IPsec ESP security associations (SAs) 1775 as described in [RFC7402]. When two peers perform a UDP-encapsulated 1776 base exchange, they MUST define a pair of IPsec SAs that produces 1777 UDP-encapsulated ESP data traffic. 1779 The management of encryption/authentication protocols and SPIs is 1780 defined in [RFC7402]. The UDP encapsulation format and processing of 1781 HIP ESP traffic is described in Section 6.1 of [RFC7402]. 1783 5.12. RELAYED_ADDRESS and MAPPED_ADDRESS Parameters 1785 While the type values are new, the format of the RELAYED_ADDRESS and 1786 MAPPED_ADDRESS parameters (Figure 12) is identical to REG_FROM, 1787 RELAY_FROM and RELAY_TO parameters. This document specifies only the 1788 use of UDP relaying, and, thus, only protocol 17 is allowed. 1789 However, future documents may specify support for other protocols. 1791 0 1 2 3 1792 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 1793 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1794 | Type | Length | 1795 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1796 | Port | Protocol | Reserved | 1797 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1798 | | 1799 | Address | 1800 | | 1801 | | 1802 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1804 Type [TBD by IANA; 1805 RELAYED_ADDRESS: 4650 1806 MAPPED_ADDRESS: 4660] 1807 Length 20 1808 Port the UDP port number 1809 Protocol IANA assigned, Internet Protocol number (17 for UDP) 1810 Reserved reserved for future use; zero when sent, ignored 1811 when received 1812 Address an IPv6 address or an IPv4 address in "IPv4-Mapped 1813 IPv6 address" format 1815 Figure 12: Format of the RELAYED_ADDRESS and MAPPED_ADDRESS 1816 Parameters 1818 5.13. PEER_PERMISSION Parameter 1820 The format of the new PEER_PERMISSION parameter is shown in 1821 Figure 13. The parameter is used for setting up and refreshing 1822 forwarding rules and the permissions for data packets at the data 1823 relay. The parameter contains one or more sets of Port, Protocol, 1824 Address, Outbound SPI (OSPI), and Inbound SPI (ISPI) values. One set 1825 defines a rule for one peer address. 1827 0 1 2 3 1828 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 1829 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1830 | Type | Length | 1831 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1832 | Port | Protocol | Reserved | 1833 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1834 | | 1835 | Address | 1836 | | 1837 | | 1838 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1839 | OSPI | 1840 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1841 | ISPI | 1842 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1843 | | 1844 | ... | 1845 | | 1846 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1848 Type [TBD by IANA; 4680] 1849 Length length in octets, excluding Type and Length 1850 Port the transport layer (UDP) port number of the peer 1851 Protocol IANA assigned, Internet Protocol number (17 for UDP) 1852 Reserved reserved for future use; zero when sent, ignored 1853 when received 1854 Address an IPv6 address, or an IPv4 address in "IPv4-Mapped 1855 IPv6 address" format, of the peer 1856 OSPI the outbound SPI value the registered host is using for 1857 the peer with the Address and Port 1858 ISPI the inbound SPI value the registered host is using for 1859 the peer with the Address and Port 1861 Figure 13: Format of the PEER_PERMISSION Parameter 1863 5.14. HIP Connectivity Check Packets 1865 The connectivity request messages are HIP UPDATE packets containing a 1866 new CANDIDATE_PRIORITY parameter (Figure 14). Response UPDATE 1867 packets contain a MAPPED_ADDRESS parameter (Figure 12). 1869 0 1 2 3 1870 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 1871 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1872 | Type | Length | 1873 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1874 | Priority | 1875 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1877 Type [TBD by IANA; 4700] 1878 Length 4 1879 Priority the priority of a (potential) peer reflexive candidate 1881 Figure 14: Format of the CANDIDATE_PRIORITY Parameter 1883 5.15. NOMINATE parameter 1885 Figure 15 shows the NOMINATE parameter that is used to conclude the 1886 candidate nomination process. 1888 0 1 2 3 1889 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 1890 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1891 | Type | Length | 1892 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1893 | Reserved | 1894 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1896 Type [TBD by IANA; 4710] 1897 Length 4 1898 Reserved Reserved for future extension purposes 1900 Figure 15: Format of the NOMINATE Parameter 1902 6. Security Considerations 1904 The security considerations are the same as in [RFC5770], but are 1905 repeated here for the sake of completeness. 1907 6.1. Privacy Considerations 1909 The locators are in plain text format in favor of inspection at HIP- 1910 aware middleboxes in the future. The current document does not 1911 specify encrypted versions of LOCATOR_SETs, even though it could be 1912 beneficial for privacy reasons to avoid disclosing them to 1913 middleboxes. 1915 It is also possible that end-users may not want to reveal all 1916 locators to each other. For example, tracking the physical location 1917 of a multihoming end-host may become easier if it reveals all 1918 locators to its peer during a base exchange. Also, revealing host 1919 addresses exposes information about the local topology that may not 1920 be allowed in all corporate environments. For these two reasons, an 1921 end-host may exclude certain host addresses from its LOCATOR_SET 1922 parameter. However, such behavior creates non-optimal paths when the 1923 hosts are located behind the same NAT. Especially, this could be 1924 problematic with a legacy NAT that does not support routing from the 1925 private address realm back to itself through the outer address of the 1926 NAT. This scenario is referred to as the hairpin problem [RFC5128]. 1927 With such a legacy NAT, the only option left would be to use a 1928 relayed transport address from a TURN server. 1930 The use of HIP and data relays can be also useful for privacy 1931 purposes. For example, a privacy concerned Responder may reveal only 1932 its HIP relay server and Relayed candidates to Initiators. This same 1933 mechanism also protects the Responder against Denial-of-Service (DoS) 1934 attacks by allowing the Responder to initiate new connections even if 1935 its relays would be unavailable due to a DoS attack. 1937 6.2. Opportunistic Mode 1939 A HIP relay server should have one address per relay client when a 1940 HIP relay is serving more than one relay client and supports 1941 opportunistic mode. Otherwise, it cannot be guaranteed that the HIP 1942 relay server can deliver the I1 packet to the intended recipient. 1944 6.3. Base Exchange Replay Protection for HIP Relay Server 1946 In certain scenarios, it is possible that an attacker, or two 1947 attackers, can replay an earlier base exchange through a HIP relay 1948 server by masquerading as the original Initiator and Responder. The 1949 attack does not require the attacker(s) to compromise the private 1950 key(s) of the attacked host(s). However, for this attack to succeed, 1951 the Responder has to be disconnected from the HIP relay server. 1953 The relay can protect itself against replay attacks by becoming 1954 involved in the base exchange by introducing nonces that the end- 1955 hosts (Initiator and Responder) are required to sign. One way to do 1956 this is to add ECHO_REQUEST_M parameters to the R1 and I2 packets as 1957 described in [HIP-MIDDLE] and drop the I2 or R2 packets if the 1958 corresponding ECHO_RESPONSE_M parameters are not present. 1960 6.4. Demultiplexing Different HIP Associations 1962 Section 5.1 of [RFC3948] describes a security issue for the UDP 1963 encapsulation in the standard IP tunnel mode when two hosts behind 1964 different NATs have the same private IP address and initiate 1965 communication to the same Responder in the public Internet. The 1966 Responder cannot distinguish between two hosts, because security 1967 associations are based on the same inner IP addresses. 1969 This issue does not exist with the UDP encapsulation of HIP ESP 1970 transport format because the Responder uses HITs to distinguish 1971 between different Initiators. 1973 6.5. Reuse of Ports at the Data Relay 1975 If the data relay uses the same relayed address and port (as conveyed 1976 in the RELAYED_ADDRESS parameter) for multiple registered hosts, it 1977 appears to all the peers, and their firewalls, that all the 1978 registered hosts using the relay are at the same address. Thus, a 1979 stateful firewall may allow packets pass from hosts that would not 1980 normally be able to send packets to a peer behind the firewall. 1981 Therefore, a HIP data relay SHOULD NOT re-use the port numbers. If 1982 port numbers need to be re-used, the relay SHOULD have a sufficiently 1983 large pool of port numbers and select ports from the pool randomly to 1984 decrease the chances of a registered host obtaining the same address 1985 that a another host behind the same firewall is using. 1987 6.6. Amplification attacks 1989 A malicious host may send an invalid list of candidates for its peer 1990 that are used for targeting a victim host by flooding it with 1991 connectivity checks. To mitigate the attack, this protocol adopts 1992 the ICE mechanism to cap the total amount of connectivity checks as 1993 defined in section Section 4.7. 1995 6.7. Attacks against Connectivity Checks and Candidate Gathering 1997 Section 13.1 in [I-D.ietf-ice-rfc5245bis] discusses about attacks 1998 against ICE connectivity checks. HIP bases its control plane 1999 security on Diffie-Hellman key exchange, public keys and Hashed 2000 Message Authentication codes, meaning that the mentioned security 2001 concerns do not apply to HIP either. The mentioned section discusses 2002 also of man-in-the-middle replay attacks that are difficult to 2003 prevent. The connectivity checks in this protocol are immune against 2004 replay attacks because a connectivity request includes a random nonce 2005 that the recipient must sign and send back as a response. 2007 Section 13.2 in [I-D.ietf-ice-rfc5245bis] discusses attacks on server 2008 reflexive address gathering. Similarly here, if the DNS, a HIP relay 2009 or a HIP data relay server has been compromised, not much can be 2010 done. However, the case where attacker can inject fake messages 2011 (located on a shared network segment like Wifi) does not apply here. 2013 HIP messages are integrity and replay protected, so it is not 2014 possible inject fake server reflexive address candidates. 2016 Section 13.3 in [I-D.ietf-ice-rfc5245bis] discusses attacks on 2017 relayed candidate gathering. Similarly to ICE TURN servers, data 2018 relays require an authenticated base exchange that protects relayed 2019 address gathering against fake requests and responses. Further, 2020 replay attacks are not possible because the HIP base exchange (and 2021 also UPDATE procedure) is protected against replay attacks. 2023 7. IANA Considerations 2025 This section is to be interpreted according to [RFC5226]. 2027 This document updates the IANA Registry for HIP Parameter Types 2028 [RFC7401] by assigning new HIP Parameter Type values for the new HIP 2029 Parameters: RELAYED_ADDRESS, MAPPED_ADDRESS (defined in 2030 Section 5.12), and PEER_PERMISSION (defined in Section 5.13). 2032 This document updates the IANA Registry for HIP NAT traversal modes 2033 [RFC5770] by assigning value for the NAT traversal mode ICE-HIP-UDP 2034 (defined in Section 5.4) This specification introduces a new 2035 keepalive Notify message type field NAT_KEEPALIVE. 2037 This document defines additional registration types for the HIP 2038 Registration Extension [RFC8003] that allow registering with a HIP 2039 relay server for ESP relaying service: RELAY_UDP_ESP (defined in 2040 Section 4.1; and performing server reflexive candidate discovery: 2041 CANDIDATE_DISCOVERY (defined in Section 4.2). 2043 ICE specifications discuss "Unilateral Self-Address Fixing" in 2044 section 17 in [I-D.ietf-ice-rfc5245bis]. This protocol is based on 2045 ICE, and thus the same considerations apply also here with one 2046 exception: this protocol does not hide binary IP addresses from 2047 application-level gateways. 2049 8. Contributors 2051 Marcelo Bagnulo, Philip Matthews and Hannes Tschofenig have 2052 contributed to [RFC5770]. This document leans heavily on the work in 2053 the RFC. 2055 9. Acknowledgments 2057 Thanks to Jonathan Rosenberg and the rest of the MMUSIC WG folks for 2058 the excellent work on ICE. In addition, the authors would like to 2059 thank Andrei Gurtov, Simon Schuetz, Martin Stiemerling, Lars Eggert, 2060 Vivien Schmitt, and Abhinav Pathak for their contributions and Tobias 2061 Heer, Teemu Koponen, Juhana Mattila, Jeffrey M. Ahrenholz, Kristian 2062 Slavov, Janne Lindqvist, Pekka Nikander, Lauri Silvennoinen, Jukka 2063 Ylitalo, Juha Heinanen, Joakim Koskela, Samu Varjonen, Dan Wing, Tom 2064 Henderson, Alex Elsayed and Jani Hautakorpi for their comments to 2065 [RFC5770], which is the basis for this document. 2067 This work has been partially funded by CyberTrust programme by 2068 Digile/Tekes in Finland. 2070 10. References 2072 10.1. Normative References 2074 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2075 Requirement Levels", BCP 14, RFC 2119, 2076 DOI 10.17487/RFC2119, March 1997, 2077 . 2079 [RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T. 2080 Henderson, "Host Identity Protocol Version 2 (HIPv2)", 2081 RFC 7401, DOI 10.17487/RFC7401, April 2015, 2082 . 2084 [RFC8003] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) 2085 Registration Extension", RFC 8003, DOI 10.17487/RFC8003, 2086 October 2016, . 2088 [RFC8004] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) 2089 Rendezvous Extension", RFC 8004, DOI 10.17487/RFC8004, 2090 October 2016, . 2092 [RFC8046] Henderson, T., Ed., Vogt, C., and J. Arkko, "Host Mobility 2093 with the Host Identity Protocol", RFC 8046, 2094 DOI 10.17487/RFC8046, February 2017, 2095 . 2097 [RFC5770] Komu, M., Henderson, T., Tschofenig, H., Melen, J., and A. 2098 Keranen, Ed., "Basic Host Identity Protocol (HIP) 2099 Extensions for Traversal of Network Address Translators", 2100 RFC 5770, DOI 10.17487/RFC5770, April 2010, 2101 . 2103 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 2104 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 2105 DOI 10.17487/RFC5389, October 2008, 2106 . 2108 [RFC7402] Jokela, P., Moskowitz, R., and J. Melen, "Using the 2109 Encapsulating Security Payload (ESP) Transport Format with 2110 the Host Identity Protocol (HIP)", RFC 7402, 2111 DOI 10.17487/RFC7402, April 2015, 2112 . 2114 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 2115 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 2116 2006, . 2118 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 2119 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 2120 DOI 10.17487/RFC5226, May 2008, 2121 . 2123 [I-D.ietf-ice-rfc5245bis] 2124 Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive 2125 Connectivity Establishment (ICE): A Protocol for Network 2126 Address Translator (NAT) Traversal", draft-ietf-ice- 2127 rfc5245bis-08 (work in progress), December 2016. 2129 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 2130 and W. Weiss, "An Architecture for Differentiated 2131 Services", RFC 2475, DOI 10.17487/RFC2475, December 1998, 2132 . 2134 10.2. Informative References 2136 [RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol 2137 (HIP) Architecture", RFC 4423, DOI 10.17487/RFC4423, May 2138 2006, . 2140 [RFC5201] Moskowitz, R., Nikander, P., Jokela, P., Ed., and T. 2141 Henderson, "Host Identity Protocol", RFC 5201, 2142 DOI 10.17487/RFC5201, April 2008, 2143 . 2145 [RFC5207] Stiemerling, M., Quittek, J., and L. Eggert, "NAT and 2146 Firewall Traversal Issues of Host Identity Protocol (HIP) 2147 Communication", RFC 5207, DOI 10.17487/RFC5207, April 2148 2008, . 2150 [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using 2151 Relays around NAT (TURN): Relay Extensions to Session 2152 Traversal Utilities for NAT (STUN)", RFC 5766, 2153 DOI 10.17487/RFC5766, April 2010, 2154 . 2156 [RFC6538] Henderson, T. and A. Gurtov, "The Host Identity Protocol 2157 (HIP) Experiment Report", RFC 6538, DOI 10.17487/RFC6538, 2158 March 2012, . 2160 [MMUSIC-ICE] 2161 Rosenberg, J., "Guidelines for Usage of Interactive 2162 Connectivity Establishment (ICE) by non Session Initiation 2163 Protocol (SIP) Protocols", Work in Progress, July 2008. 2165 [RFC5128] Srisuresh, P., Ford, B., and D. Kegel, "State of Peer-to- 2166 Peer (P2P) Communication across Network Address 2167 Translators (NATs)", RFC 5128, DOI 10.17487/RFC5128, March 2168 2008, . 2170 [HIP-MIDDLE] 2171 Heer, T., Wehrle, K., and M. Komu, "End-Host 2172 Authentication for HIP Middleboxes", Work in Progress, 2173 February 2009. 2175 [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. 2176 Stenberg, "UDP Encapsulation of IPsec ESP Packets", 2177 RFC 3948, DOI 10.17487/RFC3948, January 2005, 2178 . 2180 Appendix A. Selecting a Value for Check Pacing 2182 Selecting a suitable value for the connectivity check transaction 2183 pacing is essential for the performance of connectivity check-based 2184 NAT traversal. The value should not be so small that the checks 2185 cause network congestion or overwhelm the NATs. On the other hand, a 2186 pacing value that is too high makes the checks last for a long time, 2187 thus increasing the connection setup delay. 2189 The Ta value may be configured by the user in environments where the 2190 network characteristics are known beforehand. However, if the 2191 characteristics are not known, it is recommended that the value is 2192 adjusted dynamically. In this case, it is recommended that the hosts 2193 estimate the round-trip time (RTT) between them and set the minimum 2194 Ta value so that only two connectivity check messages are sent on 2195 every RTT. 2197 One way to estimate the RTT is to use the time that it takes for the 2198 HIP relay server registration exchange to complete; this would give 2199 an estimate on the registering host's access link's RTT. Also, the 2200 I1/R1 exchange could be used for estimating the RTT, but since the R1 2201 can be cached in the network, or the relaying service can increase 2202 the delay notably, this is not recommended. 2204 Appendix B. Differences with respect to ICE 2206 The protocol specified in this document follows the semantics of ICE 2207 as close as possible, and most of the differences are syntactical due 2208 to the use of a different protocol. In this section, we describe the 2209 differences to the ICE protocol. 2211 o ICE operates at the application layer, whereas this protocol 2212 operates between transport and network layers, thus hiding the 2213 protocol details from the application. 2215 o The STUN protocol is not employed. Instead, this protocol reuses 2216 the HIP control plane format in order simplify demultiplexing of 2217 different protocols. For example, the STUN binding response is 2218 replaced with a HIP UPDATE message containing an ECHO_REQUEST_SIGN 2219 parameter and the STUN binding response with a HIP UPDATE message 2220 containing an ECHO_RESPONSE_SIGNED parameter as defined in section 2221 Section 4.6. 2223 o The TURN protocol is not utilized. Instead, this protocol reuses 2224 HIP relay servers for the same purpose. 2226 o ICMP errors may be used in ICE to signal failure. In this 2227 protocol, HIP NOTIFY messages are used instead. 2229 o Instead of the ICE username fragment and password mechanism for 2230 credentials, this protocol uses the HIT, derived from a public 2231 key, for the same purpose. The username fragments are "transient 2232 host identifiers, bound to a particular session established as 2233 part of the candidate exchange" [I-D.ietf-ice-rfc5245bis]. In 2234 HIP, a local public key and the derived HIT are considered long- 2235 term identifiers, and invariant across different host associations 2236 and different transport-layer flows. 2238 o In ICE, the conflict when two communicating end-points take the 2239 same controlling role is solved using random values (so called 2240 tie-breaker value). In this protocol, the conflict is solved by 2241 the standard HIP base exchange procedure, where the host with the 2242 "larger" HIT switches to Responder role, thus changing also to 2243 controlled role. 2245 o The ICE-CONTROLLED and ICE-CONTROLLING attributes are not included 2246 in the connectivity checks. 2248 o The foundation concept is unnecessary in this protocol because 2249 only a single UDP flow for the IPsec tunnel will be negotiated. 2251 o Frozen candidates are omitted for the same reason as foundation 2252 concept is excluded. 2254 o Components are omitted for the same reason as foundation concept 2255 is excluded. 2257 o This protocol supports only "full ICE" where the two communicating 2258 hosts participate actively to the connectivity checks, and the 2259 "lite" mode is not supported. This design decision follows the 2260 guidelines of ICE which recommends full ICE implementations. 2261 However, it should be noted that a publicly reachable Responder 2262 may refuse to negotiate the ICE mode as described in 2263 Section 4.7.2. This would result in a [RFC7401] based HIP base 2264 exchange tunneled over UDP followed ESP traffic over the same 2265 tunnel, without the connectivity check procedures defined in this 2266 document (in some sense, this mode corresponds to the case where 2267 two ICE lite implementations connect since no connectivity checks 2268 are sent). 2270 o As the "ICE lite" is not adopted here and both sides are capable 2271 of ICE-HIP-HIP mode (negotiated during the base exchange), default 2272 candidates are not employed here. 2274 o If the agent is using Diffserv Codepoint markings [RFC2475] in its 2275 media packets, it SHOULD apply those same markings to its 2276 connectivity checks. 2278 o Unlike in ICE, the addresses are not XOR-ed in this protocol in 2279 order to avoid middlebox tampering. 2281 o This protocol does not employ the ICE related address and related 2282 port attributes (that are used for diagnostic or SIP purposes). 2284 Appendix C. Differences to Base Exchange and UPDATE procedures 2286 This section gives some design guidance for implementers how the 2287 extensions in this protocol extends and differs from [RFC7401] and 2288 [RFC8046]. 2290 o Both control and data plane are operated on top of UDP, not 2291 directly on IP. 2293 o A minimal implementation would conform only to Section 4.7.1 or 2294 Section 4.7.2, thus merely tunneling HIP control and data traffic 2295 over UDP. The drawback here is that it works only in the limited 2296 cases where the Responder has a public address. 2298 o It is worth noting that while a rendezvous server [RFC8004] has 2299 not been designed to be used in NATted scenarios because it just 2300 relays the first I1 packet and does not employ UDP encapsulation, 2301 the HIP relay forwards all control traffic and, hence, is more 2302 suitable in NATted environments. Further, the data relay concept 2303 guarantees forwarding of data plane traffic also in the cases when 2304 the NAT penetration procedures fail. 2306 o Registration procedures with a relay server are similar as with 2307 rendezvous server. However, a relay has different registration 2308 parameters than rendezvous because it offers a different service. 2309 Also, the relay includes also a REG_FROM parameter that informs 2310 the client about its server reflexive address. In the case of a 2311 data relay, it includes also a RELAYED_ADDRESS containing the 2312 relayed address for the client. 2314 o In [RFC7401], the Initiator and Responder can start to exchange 2315 application payload immediately after the base exchange. While 2316 exchanging data immediately after a base exchange via a data relay 2317 would be possible also here, we follow the ICE methodology to 2318 establish a direct path between two hosts using connectivity 2319 checks. This means that there will be some additional delay after 2320 the base exchange before application payload can be transmitted. 2321 The same applies for the UPDATE procedure as the connectivity 2322 checks introduce some additional delay. 2324 o In HIP without NAT traversal support, the base exchange acts as an 2325 implicit connectivity check, and the mobility and multihoming 2326 extensions support explicit connectivity checks. After a base 2327 exchange or UPDATE based connectivity checks, a host can use the 2328 associated address pair for transmitting application payload. In 2329 this extension, we follow the ICE methodology, where one end-point 2330 acting in the controlled role chooses the used address pair also 2331 on behalf of the other end-point acting in controlled role, which 2332 is different from HIP without NAT traversal support. Another 2333 difference is that the process of choosing an address pair is 2334 explicitly signaled using the nomination packets. The nomination 2335 process in this protocol supports only single address pair, and 2336 multihoming extensions are left for further study. 2338 o The UPDATE procedure resembles the mobility extensions defined in 2339 [RFC8046]. The first UPDATE message from the mobile host is 2340 exactly the same as in the mobility extensions. The second UPDATE 2341 message from the peer host and third from the mobile host are 2342 different in the sense that they merely acknowledge and conclude 2343 the reception of the candidates through the relay. In other 2344 words, they do not yet test for connectivity (besides reachability 2345 through the HIP relay) unlike in the mobility extensions. The 2346 idea is that connectivity check procedure follows the ICE 2347 specification, which is somewhat different from the HIP mobility 2348 extensions. 2350 o The connectivity checks as defined in the mobility extensions 2351 [RFC8046] are triggered only by the peer of the mobile host. 2352 Since successful NAT penetration requires that both end-points 2353 test connectivity, both the mobile host and its peer host have to 2354 test for connectivity. In addition, this protocol validates also 2355 the UDP ports; the ports in the connectivity check must match with 2356 the response, as required by ICE. 2358 o In HIP mobility extensions [RFC8046], an outbound locator has some 2359 associated state: UNVERIFIED mean that the locator has not been 2360 tested for reachability, ACTIVE means that the address has been 2361 verified for reachability and is being used actively, and 2362 DEPRECATED means that the locator lifetime has expired. In the 2363 subset of ICE specifications used by this protocol, an individual 2364 address candidate has only two properties: type and priority. 2365 Instead, the actual state in ICE is associated with candidate 2366 pairs rather than individual addresses. The subset of ICE 2367 specifications utilized by this protocol require the following 2368 attributes for a candidate pair: valid bit, nominated bit, base 2369 and the state of connectivity check. The connectivity checks have 2370 the following states: Waiting, In-progress, Succeeded and Failed. 2371 Handling of this state attribute requires some additional logic 2372 when compared to the mobility extensions since the state is 2373 associated with a local-remote address pair rather just a remote 2374 address, and, thus, the mobility and ICE states do not have an 2375 unambiguous one-to-one mapping. 2377 o Credit-based authorization as defined in [RFC8046] could be used 2378 before candidate nomination has been concluded upon discovering 2379 working candidate pairs. However, this may result in the use of 2380 asymmetric paths for a short time period in the beginning of 2381 communications (similarly as in aggressive ICE nomination). Thus, 2382 support of credit-based authorization is left for further study. 2384 Authors' Addresses 2386 Ari Keranen 2387 Ericsson 2388 Hirsalantie 11 2389 02420 Jorvas 2390 Finland 2392 Email: ari.keranen@ericsson.com 2393 Jan Melen 2394 Ericsson 2395 Hirsalantie 11 2396 02420 Jorvas 2397 Finland 2399 Email: jan.melen@ericsson.com 2401 Miika Komu (editor) 2402 Ericsson 2403 Hirsalantie 11 2404 02420 Jorvas 2405 Finland 2407 Email: miika.komu@ericsson.com