idnits 2.17.1 draft-ietf-hip-native-nat-traversal-28.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 1802 has weird spacing: '...eserved zero...' == Line 1844 has weird spacing: '... Min Ta the ...' == Line 1875 has weird spacing: '...eserved rese...' == Line 1877 has weird spacing: '...Address an ...' == Line 2082 has weird spacing: '...eserved reser...' == (5 more instances...) -- The document date (March 5, 2018) is 2236 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) ** Obsolete normative reference: RFC 5389 (Obsoleted by RFC 8489) == Outdated reference: A later version (-20) exists of draft-ietf-ice-rfc5245bis-15 -- Obsolete informational reference (is this intentional?): RFC 4423 (Obsoleted by RFC 9063) Summary: 1 error (**), 0 flaws (~~), 8 warnings (==), 2 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 6, 2018 Ericsson 6 March 5, 2018 8 Native NAT Traversal Mode for the Host Identity Protocol 9 draft-ietf-hip-native-nat-traversal-28 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 6, 2018. 37 Copyright Notice 39 Copyright (c) 2018 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 . . . . . . . . . . . . . . . . . . . . . . . . . 5 56 3. Overview of Operation . . . . . . . . . . . . . . . . . . . . 7 57 4. Protocol Description . . . . . . . . . . . . . . . . . . . . 9 58 4.1. Relay Registration . . . . . . . . . . . . . . . . . . . 9 59 4.2. Transport Address Candidate Gathering at the Relay Client 13 60 4.3. NAT Traversal Mode Negotiation . . . . . . . . . . . . . 15 61 4.4. Connectivity Check Pacing Negotiation . . . . . . . . . . 17 62 4.5. Base Exchange via Control Relay Server . . . . . . . . . 17 63 4.6. Connectivity Checks . . . . . . . . . . . . . . . . . . . 20 64 4.6.1. Connectivity Check Procedure . . . . . . . . . . . . 21 65 4.6.2. Rules for Connectivity Checks . . . . . . . . . . . . 24 66 4.6.3. Rules for Concluding Connectivity Checks . . . . . . 26 67 4.7. NAT Traversal Optimizations . . . . . . . . . . . . . . . 27 68 4.7.1. Minimal NAT Traversal Support . . . . . . . . . . . . 27 69 4.7.2. Base Exchange without Connectivity Checks . . . . . . 27 70 4.7.3. Initiating a Base Exchange both with and without UDP 71 Encapsulation . . . . . . . . . . . . . . . . . . . . 29 72 4.8. Sending Control Packets after the Base Exchange . . . . . 29 73 4.9. Mobility Handover Procedure . . . . . . . . . . . . . . . 30 74 4.10. NAT Keepalives . . . . . . . . . . . . . . . . . . . . . 34 75 4.11. Closing Procedure . . . . . . . . . . . . . . . . . . . . 34 76 4.12. Relaying Considerations . . . . . . . . . . . . . . . . . 35 77 4.12.1. Forwarding Rules and Permissions . . . . . . . . . . 35 78 4.12.2. HIP Data Relay and Relaying of Control Packets . . . 36 79 4.12.3. Handling Conflicting SPI Values . . . . . . . . . . 37 80 5. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 38 81 5.1. HIP Control Packets . . . . . . . . . . . . . . . . . . . 38 82 5.2. Connectivity Checks . . . . . . . . . . . . . . . . . . . 39 83 5.3. Keepalives . . . . . . . . . . . . . . . . . . . . . . . 39 84 5.4. NAT Traversal Mode Parameter . . . . . . . . . . . . . . 39 85 5.5. Connectivity Check Transaction Pacing Parameter . . . . . 40 86 5.6. Relay and Registration Parameters . . . . . . . . . . . . 41 87 5.7. LOCATOR_SET Parameter . . . . . . . . . . . . . . . . . . 42 88 5.8. RELAY_HMAC Parameter . . . . . . . . . . . . . . . . . . 44 89 5.9. Registration Types . . . . . . . . . . . . . . . . . . . 45 90 5.10. Notify Packet Types . . . . . . . . . . . . . . . . . . . 45 91 5.11. ESP Data Packets . . . . . . . . . . . . . . . . . . . . 46 92 5.12. RELAYED_ADDRESS and MAPPED_ADDRESS Parameters . . . . . . 46 93 5.13. PEER_PERMISSION Parameter . . . . . . . . . . . . . . . . 47 94 5.14. HIP Connectivity Check Packets . . . . . . . . . . . . . 48 95 5.15. NOMINATE parameter . . . . . . . . . . . . . . . . . . . 49 96 6. Security Considerations . . . . . . . . . . . . . . . . . . . 49 97 6.1. Privacy Considerations . . . . . . . . . . . . . . . . . 49 98 6.2. Opportunistic Mode . . . . . . . . . . . . . . . . . . . 50 99 6.3. Base Exchange Replay Protection for Control Relay Server 50 100 6.4. Demultiplexing Different HIP Associations . . . . . . . . 51 101 6.5. Reuse of Ports at the Data Relay Server . . . . . . . . . 51 102 6.6. Amplification attacks . . . . . . . . . . . . . . . . . . 51 103 6.7. Attacks against Connectivity Checks and Candidate 104 Gathering . . . . . . . . . . . . . . . . . . . . . . . . 51 105 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 52 106 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 53 107 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 53 108 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 53 109 10.1. Normative References . . . . . . . . . . . . . . . . . . 53 110 10.2. Informative References . . . . . . . . . . . . . . . . . 55 111 Appendix A. Selecting a Value for Check Pacing . . . . . . . . . 56 112 Appendix B. Differences with respect to ICE . . . . . . . . . . 56 113 Appendix C. Differences to Base Exchange and UPDATE procedures . 58 114 Appendix D. Multihoming Considerations . . . . . . . . . . . . . 60 115 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 61 117 1. Introduction 119 The Host Identity Protocol (HIP) [RFC7401] is specified to run 120 directly on top of IPv4 or IPv6. However, many middleboxes found in 121 the Internet, such as NATs and firewalls, often allow only UDP or TCP 122 traffic to pass [RFC5207]. Also, especially NATs usually require the 123 host behind a NAT to create a forwarding state in the NAT before 124 other hosts outside of the NAT can contact the host behind the NAT. 125 To overcome this problem, different methods, commonly referred to as 126 NAT traversal techniques, have been developed. 128 As one solution, the HIP experiment report [RFC6538] mentions that 129 Teredo based NAT traversal for HIP and related ESP traffic (with 130 double tunneling overhead). Another solution is specified in 131 [RFC5770], which will be referred as "Legacy ICE-HIP" in this 132 document. The experimental Legacy ICE-HIP specification combines 133 Interactive Connectivity Establishment (ICE) protocol 134 [I-D.ietf-ice-rfc5245bis] with HIP, so that basically ICE is 135 responsible of NAT traversal and connectivity testing, while HIP is 136 responsible of end-host authentication and IPsec key management. The 137 resulting protocol uses HIP, STUN and ESP messages tunneled over a 138 single UDP flow. The benefit of using ICE and its STUN/TURN 139 messaging formats is that one can re-use the NAT traversal 140 infrastructure already available in the Internet, such as STUN and 141 TURN servers. Also, some middleboxes may be STUN-aware and may be 142 able to do something "smart" when they see STUN being used for NAT 143 traversal. 145 Implementing a full ICE/STUN/TURN protocol stack as specified in 146 Legacy ICE-HIP results in a considerable amount of effort and code 147 which could be avoided by re-using and extending HIP messages and 148 state machines for the same purpose. Thus, this document specifies 149 an alternative NAT traversal mode referred as "Native ICE-HIP" that 150 employs HIP messaging format instead of STUN or TURN for the 151 connectivity checks, keepalives and data relaying. Native ICE-HIP 152 also specifies how mobility management works in the context of NAT 153 traversal, which is missing from the Legacy ICE-HIP specification. 154 The native specification is also based on HIPv2, whereas legacy 155 specification is based on HIPv1. 157 Similarly as Legacy ICE-HIP, also this specification builds on the 158 HIP registration extensions [RFC8003] and the base exchange procedure 159 [RFC7401] and its closing procedures, so the reader is recommended to 160 get familiar with the relevant specifications. In a nutshell, the 161 registration extensions allow a HIP Initiator (usually a "client" 162 host) to ask for specific services from a HIP Responder (usually a 163 "server" host). The registration parameters are included in a base 164 exchange, which is essentially a four-way Diffie-Hellman key exchange 165 authenticated using the public keys of the end-hosts. When the hosts 166 negotiate support for ESP [RFC7402] during the base exchange, they 167 can deliver ESP protected application payload to each other. When 168 either of the hosts moves and changes its IP address, the two hosts 169 re-establish connectivity using the mobility extensions [RFC8046]. 170 The reader is also recommended to get familiar with the mobility 171 extensions, but basically it is a three-way procedure, where the 172 mobile host first announces its new location to the peer, and then 173 the peer tests for connectivity (so called return routability check), 174 for which the mobile hosts must respond in order to activate its new 175 location. This specification builds on the mobility procedures, but 176 modifies it to be compatible with ICE. The differences to the 177 mobility extensions specified in Appendix C. It is worth noting that 178 multihoming support as specified in [RFC8047] is left for further 179 study. 181 This specification builds heavily on the ICE methodology, so it is 182 recommended that the reader is familiar with the ICE specification 183 [I-D.ietf-ice-rfc5245bis] (especially the overview). However, native 184 ICE-HIP does not implement all the features in ICE, and, hence, the 185 different features of ICE are cross referenced using [RFC2119] 186 terminology for clarity. Appendix B explains the differences to ICE, 187 and it is recommended that the reader would read also this section in 188 addition to the ICE specification. 190 2. Terminology 192 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 193 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 194 document are to be interpreted as described in [RFC2119]. 196 This document borrows terminology from [RFC5770], [RFC7401], 197 [RFC8046], [RFC4423], [I-D.ietf-ice-rfc5245bis], and [RFC5389]. The 198 following terms recur in the text: 200 ICE: 201 Interactive Connectivity Establishment (ICE) protocol as specified 202 in [I-D.ietf-ice-rfc5245bis] 204 Legacy ICE-HIP: 205 Refers to the "Basic Host Identity Protocol (HIP) Extensions for 206 Traversal of Network Address Translators" as specified in 207 [RFC5770]. The protocol specified in this document offers an 208 alternative to Legacy ICE-HIP. 210 Native ICE-HIP: 211 The protocol specified in this document (Native NAT Traversal Mode 212 for HIP). 214 Initiator: 215 The Initiator is the host that initiates the base exchange using 216 I1 message. 218 Responder: 219 The Responder is the host that receives the I1 packet from the 220 Initiator. 222 Control Relay Server 223 A registrar host that forwards any kind of HIP control plane 224 packets between the Initiator and the Responder. This host is 225 critical because it relays the locators between the Initiator and 226 the Responder, so that they can try to establish a direct 227 communication path with each other. This host is used to replace 228 HIP rendezvous servers [RFC8004] for hosts operating in private 229 address realms. In the Legacy ICE-HIP specification, this host is 230 denoted as "HIP Relay Server". 232 Control Relay Client: 233 A requester host that registers to a Control Relay Server 234 requesting it to forward control-plane traffic (i.e. HIP control 235 messages). In the Legacy ICE-HIP specification, this is denoted 236 as "HIP Relay Client". 238 Data Relay Server: 239 A registrar host that forwards HIP related data plane packets, 240 such as Encapsulating Security Payload (ESP) [RFC7402], between 241 two hosts. This host implements similar functionality as TURN 242 servers. 244 Data Relay Client: 245 A requester host that registers to a Data Relay Server requesting 246 it to forward data-plane traffic (e.g. ESP traffic). 248 Locator: 249 As defined in [RFC8046]: "A name that controls how the packet is 250 routed through the network and demultiplexed by the end-host. It 251 may include a concatenation of traditional network addresses such 252 as an IPv6 address and end-to-end identifiers such as an ESP 253 Security Parameter Index (SPI). It may also include transport 254 port numbers or IPv6 Flow Labels as demultiplexing context, or it 255 may simply be a network address." 257 LOCATOR_SET (written in capital letters): 258 Denotes a HIP control packet parameter that bundles multiple 259 locators together. 261 ICE offer: 262 The Initiator's LOCATOR_SET parameter in a HIP I2 control packet. 263 Corresponds to the ICE offer parameter, but is HIP specific. 265 ICE answer: 266 The Responder's LOCATOR_SET parameter in a HIP R2 control packet. 267 Corresponds to the ICE answer parameter, but is HIP specific. 269 HIP connectivity checks: 270 In order to obtain a direct end-to-end communication path (without 271 employing a Data Relay Server), two communicating HIP hosts try to 272 "punch holes" through their NAT boxes using this mechanism. It is 273 similar to the ICE connectivity checks, but implemented using HIP 274 return routability checks. 276 Controlling host: 277 The controlling host is the Initiator. It nominates the candidate 278 pair to be used with the controlled host. 280 Controlled host: 281 The controlled host is the Responder. It waits for the 282 controlling to nominate an address candidate pair. 284 Checklist: 286 A list of address candidate pairs that need to be tested for 287 connectivity. 289 Transport address: 290 Transport layer port and the corresponding IPv4/v6 address. 292 Candidate: 293 A transport address that is a potential point of contact for 294 receiving data. 296 Host candidate: 297 A candidate obtained by binding to a specific port from an IP 298 address on the host. 300 Server reflexive candidate: 301 A translated transport address of a host as observed by a Control 302 or Data Relay Server. 304 Peer reflexive candidate: 305 A translated transport address of a host as observed by its peer. 307 Relayed candidate: 308 A transport address that exists on a Data Relay Server. Packets 309 that arrive at this address are relayed towards the Data Relay 310 Client. 312 Permission: 313 In the context of Data Relay Server, permission refers to a 314 concept similar to TURN's channels. Before a host can use a 315 relayed candidate to forward traffic through a Data Relay Server, 316 the host must activate the relayed candidate with a specific peer 317 host. 319 Base: 320 The base of a candidate is the local source address a host uses to 321 send packets for the associated candidate. For example, the base 322 of a server reflexive address is the local address the host used 323 for registering itself to the associated Control or Data Relay 324 Server. The base of a host candidate is equal to the host 325 candidate itself. 327 3. Overview of Operation 328 +--------------+ 329 | Control | 330 +--------+ | Relay Server | +--------+ 331 | Data | +----+-----+---+ | Data | 332 | Relay | / \ | Relay | 333 | Server | / \ | Server | 334 +--------+ / \ +--------+ 335 / \ 336 / \ 337 / \ 338 / <- Signaling -> \ 339 / \ 340 +-------+ +-------+ 341 | NAT | | NAT | 342 +-------+ +-------+ 343 / \ 344 / \ 345 +-------+ +-------+ 346 | Init- | | Resp- | 347 | iator | | onder | 348 +-------+ +-------+ 350 Figure 1: Example Network Configuration 352 In the example configuration depicted in Figure 1, both Initiator and 353 Responder are behind one or more NATs, and both private networks are 354 connected to the public Internet. To be contacted from behind a NAT, 355 at least the Responder must be registered with a Control Relay Server 356 reachable on the public Internet. The Responder may have also 357 registered to a Data Relay Server that can forward the data plane in 358 case NAT traversal fails. While, strictly speaking, the Initiator 359 does not need any Relay Servers, it may act in the other role with 360 other hosts, and connectivity with the Data Relay Server of the 361 Responder may fail, so the Initiator may also need to register to a 362 Cotrol and/or Data Relay Server. It is worth noting that a Control 363 and Data Relay does not forge the source address of a passing packet, 364 but always translates the source address and source port of a packet 365 to be forwarded (to its own). 367 We assume, as a starting point, that the Initiator knows both the 368 Responder's Host Identity Tag (HIT) and the address(es) of the 369 Responder's Control Relay Server(s) (how the Initiator learns of the 370 Responder's Control Relay Server is outside of the scope of this 371 document, but may be through DNS or another name service). The first 372 steps are for both the Initiator and Responder to register with a 373 Control Relay Server (need not be the same one) and gather a set of 374 address candidates. The hosts use either Control Relay Servers or 375 Data Relay Servers for gathering the candidates. Next, the HIP base 376 exchange is carried out by encapsulating the HIP control packets in 377 UDP datagrams and sending them through the Responder's Control Relay 378 Server. As part of the base exchange, each HIP host learns of the 379 peer's candidate addresses through the HIP offer/answer procedure 380 embedded in the base exchange. 382 Once the base exchange is completed, two HIP hosts have established a 383 working communication session (for signaling) via a Control Relay 384 Server, but the hosts still have to find a better path, preferably 385 without a Data Relay Server, for the ESP data flow. For this, 386 connectivity checks are carried out until a working pair of addresses 387 is discovered. At the end of the procedure, if successful, the hosts 388 will have established a UDP-based tunnel that traverses both NATs, 389 with the data flowing directly from NAT to NAT or via a Data Relay 390 Server. At this point, also the HIP signaling can be sent over the 391 same address/port pair, and is demultiplexed from IPsec as described 392 in the UDP encapsulation standard for IPsec [RFC3948]. Finally, the 393 two hosts send NAT keepalives as needed in order keep their UDP- 394 tunnel state active in the associated NAT boxes. 396 If either one of the hosts knows that it is not behind a NAT, hosts 397 can negotiate during the base exchange a different mode of NAT 398 traversal that does not use HIP connectivity checks, but only UDP 399 encapsulation of HIP and ESP. Also, it is possible for the Initiator 400 to simultaneously try a base exchange with and without UDP 401 encapsulation. If a base exchange without UDP encapsulation 402 succeeds, no HIP connectivity checks or UDP encapsulation of ESP are 403 needed. 405 4. Protocol Description 407 This section describes the normative behavior of the "Native ICE-HIP" 408 protocol extension. Most of the procedures are similar to what is 409 defined in [RFC5770] but with different, or additional, parameter 410 types and values. In addition, a new type of relaying server, Data 411 Relay Server, is specified. Also, it should be noted that HIP 412 version 2 [RFC7401] instead of HIPv1 is expected to be used with this 413 NAT traversal mode. 415 4.1. Relay Registration 417 In order for two hosts to communicate over NATted environments, they 418 need a reliable way to exchange information. To achieve this, "HIP 419 Relay Server" is defined in [RFC5770]. It supports relaying of HIP 420 control plane traffic over UDP in NATted environments, and forwards 421 HIP control packets between the Initiator and the Responder. In this 422 document, the HIP Relay Server is denoted as "Control Relay Server" 423 for better alignment with the rest of the terminology. The 424 registration to the Control Relay Server can be achieved using 425 RELAY_UDP_ESP parameter as explained later in this section. 427 To guarantee also data plane delivery over varying types of NAT 428 devices, a host MAY also register for UDP encapsulated ESP relaying 429 using Registration Type RELAY_UDP_ESP (value [TBD by IANA: 3]). This 430 service may be coupled with the Control Relay Server or offered 431 separately on another server. If the server supports relaying of UDP 432 encapsulated ESP, the host is allowed to register for a data relaying 433 service using the registration extensions in Section 3.3 of 434 [RFC8003]). If the server has sufficient relaying resources (free 435 port numbers, bandwidth, etc.) available, it opens a UDP port on one 436 of its addresses and signals the address and port to the registering 437 host using the RELAYED_ADDRESS parameter (as defined in Section 5.12 438 in this document). If the Data Relay Server would accept the data 439 relaying request but does not currently have enough resources to 440 provide data relaying service, it MUST reject the request with 441 Failure Type "Insufficient resources" [RFC8003]. 443 A Control Relay Server MUST silently drop packets to a Control Relay 444 Client that has not previously registered with the HIP relay. The 445 registration process follows the generic registration extensions 446 defined in [RFC8003]. The HIP control plane relaying registration 447 follows [RFC5770], but the data plane registration is different. It 448 is worth noting that if the HIP control and data plane relay services 449 reside on different hosts, the client has to register separately to 450 each of them. In the example shown in Figure 2, the two services are 451 coupled on a single host. The text uses "Relay Client" and "Relay 452 Server" as a shorthand when the procedures apply both to control and 453 data cases. 455 Control/Data Control/Data 456 Relay Client (Initiator) Relay Server (Responder) 457 | 1. UDP(I1) | 458 +---------------------------------------------------------------->| 459 | | 460 | 2. UDP(R1(REG_INFO(RELAY_UDP_HIP,[RELAY_UDP_ESP]))) | 461 |<----------------------------------------------------------------+ 462 | | 463 | 3. UDP(I2(REG_REQ(RELAY_UDP_HIP),[RELAY_UDP_ESP])) | 464 +---------------------------------------------------------------->| 465 | | 466 | 4. UDP(R2(REG_RES(RELAY_UDP_HIP,[RELAY_UDP_ESP]), REG_FROM, | 467 | [RELAYED_ADDRESS])) | 468 |<----------------------------------------------------------------+ 469 | | 471 Figure 2: Example Registration with a HIP Relay 473 In step 1, the Relay Client (Initiator) starts the registration 474 procedure by sending an I1 packet over UDP to the Relay Server. It 475 is RECOMMENDED that the Relay Client select a random port number from 476 the ephemeral port range 49152-65535 for initiating a base exchange. 477 Alternatively, a host MAY also use a single fixed port for initiating 478 all outgoing connections. However, the allocated port MUST be 479 maintained until all of the corresponding HIP Associations are 480 closed. It is RECOMMENDED that the Relay Server listen to incoming 481 connections at UDP port 10500. If some other port number is used, it 482 needs to be known by potential Relay Clients. 484 In step 2, the Relay Server (Responder) lists the services that it 485 supports in the R1 packet. The support for HIP control plane over 486 UDP relaying is denoted by the Registration Type value RELAY_UDP_HIP 487 (see Section 5.9). If the server supports also relaying of ESP 488 traffic over UDP, it includes also Registration type value 489 RELAY_UDP_ESP. 491 In step 3, the Relay Client selects the services for which it 492 registers and lists them in the REG_REQ parameter. The Relay Client 493 registers for the Control Data Relay service by listing the 494 RELAY_UDP_HIP value in the request parameter. If the Relay Client 495 requires also ESP relaying over UDP, it lists also RELAY_UDP_ESP. 497 In step 4, the Relay Server concludes the registration procedure with 498 an R2 packet and acknowledges the registered services in the REG_RES 499 parameter. The Relay Server denotes unsuccessful registrations (if 500 any) in the REG_FAILED parameter of R2. The Relay Server also 501 includes a REG_FROM parameter that contains the transport address of 502 the Relay Client as observed by the Relay Server (Server Reflexive 503 candidate). If the Relay Client registered to ESP relaying service, 504 the Relay Server includes RELAYED_ADDRESS parameter that describes 505 the UDP port allocated to the Relay Client for ESP relaying. It is 506 worth noting that the Data Relay Client must first activate this UDP 507 port by sending an UPDATE message to the Data Relay Server that 508 includes a PEER_PERMISSION parameter as described in Section 4.12.1 509 both after base exchange and handover procedures. Also, the Data 510 Relay Server should follow the port allocation recommendations in 511 Section 6.5. 513 After the registration, the Relay Client sends periodically NAT 514 keepalives to the Relay Server in order to keep the NAT bindings 515 between the Relay Client and the relay alive. The keepalive 516 extensions are described in Section 4.10. 518 The Data Relay Client MUST maintain an active HIP association with 519 the Data Relay Server as long as it requires the data relaying 520 service. When the HIP association is closed (or times out), or the 521 registration lifetime passes without the Data Relay Client refreshing 522 the registration, the Data Relay Server MUST stop relaying packets 523 for that host and close the corresponding UDP port (unless other Data 524 Relay Clients are still using it). 526 The Data Relay Server SHOULD offer a different relayed address and 527 port for each Data Relay Client because this can cause problems with 528 stateful firewalls (see Section 6.5). 530 When a Control Relay Client sends an UPDATE (e.g., due to host 531 movement or to renew service registration), the Control Relay Server 532 MUST follow the general guidelines defined in [RFC8003], with the 533 difference that all UPDATE messages are delivered on top of UDP. In 534 addition to this, the Control Relay Server MUST include the REG_FROM 535 parameter in all UPDATE responses sent to the Control Relay Client. 536 This applies both renewals of service registration but also to host 537 movement, where especially the latter requires the Control Relay 538 Client to learn its new server reflexive address candidate. 540 A Data Relay Client can request multiple relayed candidates from the 541 Data Relay Server (e.g., for the reasons described in 542 Section 4.12.3). After the base exchange with registration, the Data 543 Relay Client can request additional relayed candidates similarly as 544 during the base exchange. The Data Relay Client sends an UPDATE 545 message REG_REQ parameter requesting for the RELAY_UDP_ESP service. 546 The UPDATE message MUST also include a SEQ and a ECHO_REQUEST_SIGNED 547 parameter. The Data Relay Server MUST respond with an UPDATE message 548 that includes the corresponding response parameters: REG_RES, ACK and 549 ECHO_REQUEST_SIGNED . In case the Data Relay Server admitted a new 550 relayed UDP port for the Data Relay Client, the REG_RES parameter 551 MUST list RELAY_UDP_ESP as a service and the UPDATE message MUST also 552 include a RELAYED_ADDRESS parameter describing the relayed UDP port. 553 The Data Relay Server MUST also include the Server Reflexive 554 candidate in a REG_FROM parameter. It is worth mentioning that Data 555 Relay Client MUST activate the UDP port as described in 556 Section 4.12.1 before it can be used for any ESP relaying. 558 A Data Relay Client may unregister a relayed candidate in two ways. 559 It can wait for its lifetime to expire or it can explicitly request 560 it with zero lifetime using the UPDATE mechanism. The Data Relay 561 Client can send an REG_REQ parameter with zero lifetime to the Data 562 Relay Server in order to expire all relayed candidates. To expire a 563 specific relayed candidate, the Data Relay Client MUST also include 564 RELAYED_ADDRESS parameter as sent by the server in the UPDATE 565 message. Upon closing the HIP association (CLOSE-CLOSE-ACK procedure 566 initiated by either party), the Data Relay Server MUST also expire 567 all relayed candidates. 569 4.2. Transport Address Candidate Gathering at the Relay Client 571 An Initiator needs to gather a set of address candidates before 572 contacting a (non-relay) Responder. The candidates are needed for 573 connectivity checks that allow two hosts to discover a direct, non- 574 relayed path for communicating with each other. One server reflexive 575 candidate can be discovered during the registration with the Control 576 Relay Server from the REG_FROM parameter (and another from Data Relay 577 Server if one is employed). 579 The candidate gathering can be done at any time, but it needs to be 580 done before sending an I2 or R2 in the base exchange if ICE-HIP-UDP 581 mode is to be used for the connectivity checks. It is RECOMMENDED 582 that all three types of candidates (host, server reflexive, and 583 relayed) are gathered to maximize the probability of successful NAT 584 traversal. However, if no Data Relay Server is used, and the host 585 has only a single local IP address to use, the host MAY use the local 586 address as the only host candidate and the address from the REG_FROM 587 parameter discovered during the Control Relay Server registration as 588 a server reflexive candidate. In this case, no further candidate 589 gathering is needed. 591 A Data Relay Client MAY register only a single relayed candidate to 592 be used with multiple other peers. However, it is RECOMMENDED that a 593 Data Relay Client registers a new server reflexive candidate for each 594 of its peer for the reasons described in Section 4.12.3. The 595 procedures for registering multiple relayed candidates are described 596 in Section 4.1. 598 If a Relay Client has more than one network interface, it can 599 discover additional server reflexive candidates by sending UPDATE 600 messages from each of its interfaces to the Relay Server. Each such 601 UPDATE message MUST include the following parameters: registration 602 request (REG_REQ) parameter with Registration Type 603 CANDIDATE_DISCOVERY (value [TBD by IANA: 4]) and ECHO_REQUEST_SIGNED 604 parameter. When a Control Relay Server receives an UPDATE message 605 with registration request containing a CANDIDATE_DISCOVERY type, it 606 MUST include a REG_FROM parameter, containing the same information as 607 if this were a Control Relay Server registration, to the response (in 608 addition to the mandatory ECHO_RESPONSE_SIGNED parameter). This 609 request type SHOULD NOT create any state at the Control Relay Server. 611 ICE guidelines [I-D.ietf-ice-rfc5245bis] for candidate gathering are 612 followed here. A number of host candidates (loopback, anycast and 613 others) should be excluded as described in the ICE specification 614 [I-D.ietf-ice-rfc5245bis]. Relayed candidates SHOULD be gathered in 615 order to guarantee successful NAT traversal, and implementations 616 SHOULD support this functionality even if it will not be used in 617 deployments in order to enable it by software configuration update if 618 needed at some point. A host SHOULD employ only a single server for 619 gathering the candidates for a single HIP association; either one 620 server providing both Control and Data Relay Server functionality, or 621 one Control Relay Server and also Data Relay Server if the 622 functionality is offered by another server. When the relay service 623 is split between two hosts, the server reflexive candidate from the 624 Control Relay Server SHOULD be used instead of the one provided by 625 the Data Relay Server. If a relayed candidate is identical to a host 626 candidate, the relayed candidate must be discarded. NAT64 627 considerations in [I-D.ietf-ice-rfc5245bis] apply as well. 629 HIP based connectivity can be utilized by IPv4 applications using 630 Local Scope Identifiers (LSIs) and by IPv6 based applications using 631 HITs. The LSIs and HITs of the local virtual interfaces MUST be 632 excluded in the candidate gathering phase as well to avoid creating 633 unnecessary loopback connectivity tests. 635 Gathering of candidates MAY also be performed by other means than 636 described in this section. For example, the candidates could be 637 gathered as specified in Section 4.2 of [RFC5770] if STUN servers are 638 available, or if the host has just a single interface and no STUN or 639 Data Relay Server are available. 641 Each local address candidate MUST be assigned a priority. The 642 following recommended formula (as described in 643 [I-D.ietf-ice-rfc5245bis]) SHOULD be used: 645 priority = (2^24)*(type preference) + (2^8)*(local preference) + 646 (2^0)*(256 - component ID) 648 In the formula, type preference follows the ICE specification 649 guidelines: the RECOMMENDED values are 126 for host candidates, 100 650 for server reflexive candidates, 110 for peer reflexive candidates, 651 and 0 for relayed candidates. The highest value is 126 (the most 652 preferred) and lowest is 0 (last resort). For all candidates of the 653 same type, the preference type value MUST be identical, and, 654 correspondingly, the value MUST be different for different types. 655 For peer reflexive values, the type preference value MUST be higher 656 than for server reflexive types. It should be noted that peer 657 reflexive values are learned later during connectivity checks, so a 658 host cannot employ it during candidate gathering stage yet. 660 Following the ICE specification, the local preference MUST be an 661 integer from 0 (lowest preference) to 65535 (highest preference) 662 inclusive. In the case the host has only a single address candidate, 663 the value SHOULD be 65535. In the case of multiple candidates, each 664 local preference value MUST be unique. Dual-stack considerations for 665 IPv6 in ICE apply also here. 667 Unlike ICE, this protocol only creates a single UDP flow between the 668 two communicating hosts, so only a single component exists. Hence, 669 the component ID value MUST always be set to 1. 671 As defined in ICE , the retransmission timeout (RTO) for address 672 gathering from a Control/Data Relay Server SHOULD be calculated as 673 follows: 675 RTO = MAX (500ms, Ta * (Num-Of-Pairs)) 677 where Ta is the value used for the connectivity check pacing and Num- 678 Of-Pairs is number of pairs of candidates with Control and Data Relay 679 Servers (e.g. in the case of a single server, it would be 1). A 680 smaller value than 500 ms for the RTO MUST NOT be used. 682 4.3. NAT Traversal Mode Negotiation 684 This section describes the usage of a new non-critical parameter 685 type. The presence of the parameter in a HIP base exchange means 686 that the end-host supports NAT traversal extensions described in this 687 document. As the parameter is non-critical (as defined in 688 Section 5.2.1 of [RFC7401]), it can be ignored by a end-host, which 689 means that the host is not required to support it or may decline to 690 use it. 692 With registration with a Control/Data Relay Server, it is usually 693 sufficient to use the UDP-ENCAPSULATION mode of NAT traversal since 694 the Relay Server is assumed to be in public address space. Thus, the 695 Relay Server SHOULD propose the UDP-ENCAPSULATION mode as the 696 preferred or only mode. The NAT traversal mode negotiation in a HIP 697 base exchange is illustrated in Figure 3. It is worth noting that 698 the Relay Server could be located between the hosts, but is omitted 699 here for simplicity. 701 Initiator Responder 702 | 1. UDP(I1) | 703 +--------------------------------------------------------------->| 704 | | 705 | 2. UDP(R1(.., NAT_TRAVERSAL_MODE(ICE-HIP-UDP), ..)) | 706 |<---------------------------------------------------------------+ 707 | | 708 | 3. UDP(I2(.., NAT_TRAVERSAL_MODE(ICE-HIP-UDP), LOC_SET, ..)) | 709 +--------------------------------------------------------------->| 710 | | 711 | 4. UDP(R2(.., LOC_SET, ..)) | 712 |<---------------------------------------------------------------+ 713 | | 715 Figure 3: Negotiation of NAT Traversal Mode 717 In step 1, the Initiator sends an I1 to the Responder. In step 2, 718 the Responder responds with an R1. As specified in [RFC5770], the 719 NAT_TRAVERSAL_MODE parameter in R1 contains a list of NAT traversal 720 modes the Responder supports. The mode specified in this document is 721 ICE-HIP-UDP (value [TBD by IANA: 3]). 723 In step 3, the Initiator sends an I2 that includes a 724 NAT_TRAVERSAL_MODE parameter. It contains the mode selected by the 725 Initiator from the list of modes offered by the Responder. If ICE- 726 HIP-UDP mode was selected, the I2 also includes the "Transport 727 address" locators (as defined in Section 5.7) of the Initiator in a 728 LOCATOR_SET parameter (denoted here LOC_SET). The locators in I2 are 729 the "ICE offer". 731 In step 4, the Responder concludes the base exchange with an R2 732 packet. If the Initiator chose ICE NAT traversal mode, the Responder 733 includes a LOCATOR_SET parameter in the R2 packet. The locators in 734 R2, encoded like the locators in I2, are the "ICE answer". If the 735 NAT traversal mode selected by the Initiator is not supported by the 736 Responder, the Responder SHOULD reply with a NOTIFY packet with type 737 NO_VALID_NAT_TRAVERSAL_MODE_PARAMETER and abort the base exchange. 739 4.4. Connectivity Check Pacing Negotiation 741 As explained in Legacy ICE-HIP [RFC5770], when a NAT traversal mode 742 with connectivity checks is used, new transactions should not be 743 started too fast to avoid congestion and overwhelming the NATs. For 744 this purpose, during the base exchange, hosts can negotiate a 745 transaction pacing value, Ta, using a TRANSACTION_PACING parameter in 746 R1 and I2 packets. The parameter contains the minimum time 747 (expressed in milliseconds) the host would wait between two NAT 748 traversal transactions, such as starting a new connectivity check or 749 retrying a previous check. The value that is used by both of the 750 hosts is the higher of the two offered values. 752 The minimum Ta value SHOULD be configurable, and if no value is 753 configured, a value of 50 ms MUST be used. Guidelines for selecting 754 a Ta value are given in Appendix A. Hosts SHOULD NOT use values 755 smaller than 5 ms for the minimum Ta, since such values may not work 756 well with some NATs (as explained in [I-D.ietf-ice-rfc5245bis]). The 757 Initiator MUST NOT propose a smaller value than what the Responder 758 offered. If a host does not include the TRANSACTION_PACING parameter 759 in the base exchange, a Ta value of 50 ms MUST be used as that host's 760 minimum value. 762 4.5. Base Exchange via Control Relay Server 764 This section describes how the Initiator and Responder perform a base 765 exchange through a Control Relay Server. Connectivity pacing 766 (denoted as TA_P here) was described in Section 4.4 and is not 767 repeated here. Similarly, the NAT traversal mode negotiation process 768 (denoted as NAT_TM in the example) was described in Section 4.3 and 769 is neither repeated here. If a Control Relay Server receives an R1 770 or I2 packet without the NAT traversal mode parameter, it MUST drop 771 it and SHOULD send a NOTIFY error packet with type 772 NO_VALID_NAT_TRAVERSAL_MODE_PARAMETER to the sender of the R1 or I2. 774 It is RECOMMENDED that the Initiator send an I1 packet encapsulated 775 in UDP when it is destined to an IPv4 address of the Responder. 776 Respectively, the Responder MUST respond to such an I1 packet with a 777 UDP-encapsulated R1 packet, and also the rest of the communication 778 related to the HIP association MUST also use UDP encapsulation. 780 Figure 4 illustrates a base exchange via a Control Relay Server. We 781 assume that the Responder (i.e. a Control Relay Client) has already 782 registered to the Control Relay Server. The Initiator may have also 783 registered to another (or the same Control Relay Server), but the 784 base exchange will traverse always through the Control Relay Server 785 of the Responder. 787 Initiator Control Relay Server Responder 788 | 1. UDP(I1) | | 789 +--------------------------------->| 2. UDP(I1(RELAY_FROM)) | 790 | +------------------------------->| 791 | | | 792 | | 3. UDP(R1(RELAY_TO, NAT_TM, | 793 | | TA_P)) | 794 | 4. UDP(R1(RELAY_TO, NAT_TM, |<-------------------------------+ 795 | TA_P)) | | 796 |<---------------------------------+ | 797 | | | 798 | 5. UDP(I2(LOC_SET, NAT_TM, | | 799 | TA_P)) | | 800 +--------------------------------->| 6. UDP(I2(LOC_SET, RELAY_FROM, | 801 | | NAT_TM, TA_P)) | 802 | +------------------------------->| 803 | | | 804 | | 7. UDP(R2(LOC_SET, RELAY_TO)) | 805 | 8. UDP(R2(LOC_SET, RELAY_TO)) |<-------------------------------+ 806 |<---------------------------------+ | 807 | | | 809 Figure 4: Base Exchange via a HIP Relay Server 811 In step 1 of Figure 4, the Initiator sends an I1 packet over UDP via 812 the Control Relay Server to the Responder. In the HIP header, the 813 source HIT belongs to the Initiator and the destination HIT to the 814 Responder. The initiator sends the I1 packet from its IP address to 815 the IP address of the Control Relay Server over UDP. 817 In step 2, the Control Relay Server receives the I1 packet. If the 818 destination HIT belongs to a registered Responder, the Control Relay 819 Server processes the packet. Otherwise, the Control Relay Server 820 MUST drop the packet silently. The Control Relay Server appends a 821 RELAY_FROM parameter to the I1 packet, which contains the transport 822 source address and port of the I1 as observed by the Control Relay 823 Server. The Control Relay Server protects the I1 packet with 824 RELAY_HMAC as described in [RFC8004], except that the parameter type 825 is different (see Section 5.8). The Control Relay Server changes the 826 source and destination ports and IP addresses of the packet to match 827 the values the Responder used when registering to the Control Relay 828 Server, i.e., the reverse of the R2 used in the registration. The 829 Control Relay Server MUST recalculate the transport checksum and 830 forward the packet to the Responder. 832 In step 3, the Responder receives the I1 packet. The Responder 833 processes it according to the rules in [RFC7401]. In addition, the 834 Responder validates the RELAY_HMAC according to [RFC8004] and 835 silently drops the packet if the validation fails. The Responder 836 replies with an R1 packet to which it includes RELAY_TO and NAT 837 traversal mode parameters. The responder MUST include ICE-HIP-UDP in 838 the NAT traversal modes. The RELAY_TO parameter MUST contain the 839 same information as the RELAY_FROM parameter, i.e., the Initiator's 840 transport address, but the type of the parameter is different. The 841 RELAY_TO parameter is not integrity protected by the signature of the 842 R1 to allow pre-created R1 packets at the Responder. 844 In step 4, the Control Relay Server receives the R1 packet. The 845 Control Relay Server drops the packet silently if the source HIT 846 belongs to a Control Relay Client that has not successfully 847 registered. The Control Relay Server MAY verify the signature of the 848 R1 packet and drop it if the signature is invalid. Otherwise, the 849 Control Relay Server rewrites the source address and port, and 850 changes the destination address and port to match RELAY_TO 851 information. Finally, the Control Relay Server recalculates the 852 transport checksum and forwards the packet. 854 In step 5, the Initiator receives the R1 packet and processes it 855 according to [RFC7401]. The Initiator MAY use the address in the 856 RELAY_TO parameter as a local peer-reflexive candidate for this HIP 857 association if it is different from all known local candidates. The 858 Initiator replies with an I2 packet that uses the destination 859 transport address of R1 as the source address and port. The I2 860 packet contains a LOCATOR_SET parameter that lists all the HIP 861 candidates (ICE offer) of the Initiator. The candidates are encoded 862 using the format defined in Section 5.7. The I2 packet MUST also 863 contain a NAT traversal mode parameter that includes ICE-HIP-UDP 864 mode. 866 In step 6, the Control Relay Server receives the I2 packet. The 867 Control Relay Server appends a RELAY_FROM and a RELAY_HMAC to the I2 868 packet similarly as explained in step 2, and forwards the packet to 869 the Responder. 871 In step 7, the Responder receives the I2 packet and processes it 872 according to [RFC7401]. It replies with an R2 packet and includes a 873 RELAY_TO parameter as explained in step 3. The R2 packet includes a 874 LOCATOR_SET parameter that lists all the HIP candidates (ICE answer) 875 of the Responder. The RELAY_TO parameter is protected by the HMAC. 877 In step 8, the Control Relay Server processes the R2 as described in 878 step 4. The Control Relay Server forwards the packet to the 879 Initiator. After the Initiator has received the R2 and processed it 880 successfully, the base exchange is completed. 882 Hosts MUST include the address of one or more Control Relay Servers 883 (including the one that is being used for the initial signaling) in 884 the LOCATOR_SET parameter in I2 and R2 if they intend to use such 885 servers for relaying HIP signaling immediately after the base 886 exchange completes. The traffic type of these addresses MUST be "HIP 887 signaling" and they MUST NOT be used as HIP candidates. If the 888 Control Relay Server locator used for relaying the base exchange is 889 not included in I2 or R2 LOCATOR_SET parameters, it SHOULD NOT be 890 used after the base exchange. Instead, further HIP signaling SHOULD 891 use the same path as the data traffic. It is RECOMMENDED to use the 892 same Control Relay Server throughout the lifetime of the host 893 association that was used for forwarding the base exchange if the 894 Responder includes it in the locator parameter of the R2 message. 896 4.6. Connectivity Checks 898 When the Initiator and Responder complete the base exchange through 899 the Control Relay Server, both of them employ the IP address of the 900 Control Relay Server as the destination address for the packets. 901 This address MUST NOT be used as a destination for ESP traffic (i.e., 902 the corresponding Control Relay Client cannot advertise it to its 903 peer) unless the server supports also Data Relay Server 904 functionality, for which the client has successfully registered to. 905 When NAT traversal mode with ICE-HIP-UDP was successfully negotiated 906 and selected, the Initiator and Responder MUST start the connectivity 907 checks in order to attempt to obtain direct end-to-end connectivity 908 through NAT devices. It is worth noting that the connectivity checks 909 MUST be completed even though no ESP_TRANSFORM would be negotiated 910 and selected. 912 The connectivity checks follow the ICE methodology [MMUSIC-ICE], but 913 UDP encapsulated HIP control messages are used instead of ICE 914 messages. Only normal nomination MUST be used for the connectivity 915 checks, i.e., aggressive nomination MUST NOT be employed. As stated 916 in the ICE specification, the basic procedure for connectivity checks 917 has three phases: sorting the candidate pairs according their 918 priority, sending checks in the prioritized order and acknowledging 919 the checks from the peer host. 921 The Initiator MUST take the role of controlling host and the 922 Responder acts as the controlled host. The roles MUST persist 923 throughout the HIP associate lifetime (to be reused in the possibly 924 mobility UPDATE procedures). In the case both communicating nodes 925 are initiating the communications to each other using an I1 packet, 926 the conflict is resolved as defined in section 6.7 in [RFC7401]: the 927 host with the "larger" HIT changes to its Role to Responder. In such 928 a case, the host changing its role to Responder MUST also switch to 929 controlling role. 931 The protocol follows standard HIP UPDATE sending and processing rules 932 as defined in section 6.11 and 6.12 in [RFC7401], but some new 933 parameters are introduced (CANDIDATE_PRIORITY, MAPPED_ADDRESS and 934 NOMINATE). 936 4.6.1. Connectivity Check Procedure 938 Figure 5 illustrates connectivity checks in a simplified scenario, 939 where the Initiator and Responder have only a single candidate pair 940 to check. Typically, NATs drop messages until both sides have sent 941 messages using the same port pair. In this scenario, the Responder 942 sends a connectivity check first but the NAT of the Initiator drops 943 it. However, the connectivity check from the Initiator reaches the 944 Responder because it uses the same port pair as the first message. 945 It is worth noting that the message flow in this section is 946 idealistic, and, in practice, more messages would be dropped, 947 especially in the beginning. For instance, connectivity tests always 948 start with the candidates with the highest priority, which would be 949 host candidates (which would not reach the recipient in this 950 scenario). 952 Initiator NAT1 NAT2 Responder 953 | | 1. UDP(UPDATE(SEQ, CAND_PRIO, | | 954 | | ECHO_REQ_SIGN)) | | 955 | X<-----------------------------------+----------------+ 956 | | | | 957 | 2. UDP(UPDATE(SEQ, ECHO_REQ_SIGN, CAND_PRIO)) | | 958 +-------------+------------------------------------+--------------->| 959 | | | | 960 | 3. UDP(UPDATE(ACK, ECHO_RESP_SIGN, MAPPED_ADDR)) | | 961 |<------------+------------------------------------+----------------+ 962 | | | | 963 | 4. UDP(UPDATE(SEQ, ECHO_REQ_SIGN, CAND_PRIO)) | | 964 |<------------+------------------------------------+----------------+ 965 | | | | 966 | 5. UDP(UPDATE(ACK, ECHO_RESP_SIGN, MAPPED_ADDR)) | | 967 +-------------+------------------------------------+--------------->| 968 | | | | 969 | 6. Other connectivity checks using UPDATE over UDP | 970 |<------------+------------------------------------+----------------> 971 | | | | 972 | 7. UDP(UPDATE(SEQ, ECHO_REQ_SIGN, CAND_PRIO, NOMINATE)) | 973 +-------------+------------------------------------+--------------->| 974 | | | | 975 | 8. UDP(UPDATE(SEQ, ACK, ECHO_REQ_SIGN, ECHO_RESP_SIGN, | 976 | NOMINATE)) | | 977 |<------------+------------------------------------+----------------+ 978 | | | | 979 | 9. UDP(UPDATE(ACK, ECHO_RESP_SIGN)) | | 980 +-------------+------------------------------------+--------------->+ 981 | | | | 982 | 10. ESP data traffic over UDP | | 983 +<------------+------------------------------------+--------------->+ 984 | | | | 986 Figure 5: Connectivity Checks 988 In step 1, the Responder sends a connectivity check to the Initiator 989 that the NAT of the Initiator drops. The message includes a number 990 of parameters. As specified in [RFC7401]), the SEQ parameter 991 includes a running sequence identifier for the connectivity check. 992 The candidate priority (denoted "CAND_PRIO" in the figure) describes 993 the priority of the address candidate being tested. The 994 ECHO_REQUEST_SIGNED (denoted ECHO_REQ_SIGN in the figure) includes a 995 nonce that the recipient must sign and echo back as it is. 997 In step 2, the Initiator sends a connectivity check, using the same 998 address pair candidate as in the previous step, and the message 999 traverses successfully the NAT boxes. The message includes the same 1000 parameters as in the previous step. It should be noted that the 1001 sequence identifier is locally assigned by the Responder, so it can 1002 be different than in the previous step. 1004 In step 3, the Responder has successfully received the previous 1005 connectivity check from the Initiator and starts to build a response 1006 message. Since the message from the Initiator included a SEQ, the 1007 Responder must acknowledge it using an ACK parameter. Also, the 1008 nonce contained in the echo request must be echoed back in an 1009 ECHO_RESPONSE_SIGNED (denoted ECHO_RESP_SIGN) parameter. The 1010 Responder includes also a MAPPED_ADDRESS parameter (denoted 1011 MAPPED_ADDR in the figure) that contains the transport address of the 1012 Initiator as observed by the Responder (i.e. peer reflexive 1013 candidate). This message is successfully delivered to the Initiator, 1014 and upon reception the Initiator marks the candidate pair as valid. 1016 In step 4, the Responder retransmits the connectivity check sent in 1017 the first step, since it was not acknowledged yet. 1019 In step 5, the Initiator responds to the previous connectivity check 1020 message from the Responder. The Initiator acknowledges the SEQ 1021 parameter from the previous message using ACK parameter and the 1022 ECHO_REQUEST_SIGNED parameter with ECHO_RESPONSE_SIGNED. In 1023 addition, it includes MAPPED_ADDR parameter that includes the peer 1024 reflexive candidate. This response message is successfully delivered 1025 to the Responder, and upon reception the Initiator marks the 1026 candidate pair as valid. 1028 In step 6, despite the two hosts now having valid address candidates, 1029 the hosts still test the remaining address candidates in a similar 1030 way as in the previous steps (due to the use of normal nomination). 1031 It should be noted that each connectivity check has a unique sequence 1032 number in the SEQ parameter. 1034 In step 7, the Initiator has completed testing all address candidates 1035 and nominates one address candidate to be used. It sends an UPDATE 1036 message using the selected address candidates that includes a number 1037 of parameters: SEQ, ECHO_REQUEST_SIGNED, CANDIDATE_PRIORITY and the 1038 NOMINATE parameter. 1040 In step 8, the Responder receives the message with NOMINATE parameter 1041 from the Initiator. It sends a response that includes the NOMINATE 1042 parameter in addition to a number of other parameters. The ACK and 1043 ECHO_RESPONSE_SIGNED parameters acknowledge the SEQ and 1044 ECHO_REQUEST_SIGNED parameters from previous message from the 1045 Initiator. The Responder includes SEQ and ECHO_REQUEST_SIGNED 1046 parameters in order to receive an acknowledgment from the Responder. 1048 In step 9, the Initiator completes the candidate nomination process 1049 by confirming the message reception to the Responder. In the 1050 confirmation message, the ACK and ECHO_RESPONSE_SIGNED parameters 1051 correspond to the SEQ and ECHO_REQUEST_SIGNED parameters in the 1052 message sent by the Responder in the previous step. 1054 In step 10, the Initiator and Responder can start sending application 1055 payload over the successfully nominated address candidates. 1057 It is worth noting that if either host has registered a relayed 1058 address candidate from a Data Relay Server, the host MUST activate 1059 the address before connectivity checks by sending an UPDATE message 1060 containing PEER_PERMISSION parameter as described in Section 4.12.1. 1061 Otherwise, the Data Relay Server drops ESP packets using the relayed 1062 address. 1064 It should be noted that in the case both Initiator and Responder both 1065 advertising their own relayed address candidates, it is possible that 1066 the two hosts choose the two relayed addresses as a result of the ICE 1067 nomination algorithm. While this is possible (and even could be 1068 desirable for privacy reasons), it can be unlikely due to low 1069 priority assigned for the relayed address candidates. In such a 1070 event, the nominated address pair is always symmetric; the nomination 1071 algorithm prevents asymmetric address pairs (i.e. each side choosing 1072 different pair), such as a Data Relay Client using its own Data Relay 1073 Server to send data directly to its peer while receiving data from 1074 the Data Relay Server of its peer. 1076 4.6.2. Rules for Connectivity Checks 1078 The HITs of the two communicating hosts MUST be used as credentials 1079 in this protocol (in contrast to ICE which employs username-password 1080 fragments). A HIT pair uniquely identifies the corresponding HIT 1081 association, and a SEQ number in an UPDATE message identifies a 1082 particular connectivity check. 1084 All of the connectivity check packets MUST be protected with HMACs 1085 and signatures (even though the illustrations in this specification 1086 omit them for simplicity). Each connectivity check sent by a host 1087 MUST include a SEQ parameter and ECHO_REQUEST_SIGNED parameter, and 1088 correspondingly the peer MUST respond to these using ACK and 1089 ECHO_RESPONSE_SIGNED according to the rules specified in [RFC7401]. 1091 The host sending a connectivity check MUST validate that the response 1092 uses the same pair of UDP ports, and drop the packet if this is not 1093 the case. 1095 A host may receive a connectivity check before it has received the 1096 candidates from its peer. In such a case, the host MUST immediately 1097 generate a response, and then continue waiting for the candidates. A 1098 host MUST NOT select a candidate pair until it has verified the pair 1099 using a connectivity check as defined in Section 4.6.1. 1101 [RFC7401] states that UPDATE packets have to include either a SEQ or 1102 ACK parameter (or both). According to the RFC, each SEQ parameter 1103 should be acknowledged separately. In the context of NATs, this 1104 means that some of the SEQ parameters sent in connectivity checks 1105 will be lost or arrive out of order. From the viewpoint of the 1106 recipient, this is not a problem since the recipient will just 1107 "blindly" acknowledge the SEQ. However, the sender needs to be 1108 prepared for lost sequence identifiers and ACKs parameters that 1109 arrive out of order. 1111 As specified in [RFC7401], an ACK parameter may acknowledge multiple 1112 sequence identifiers. While the examples in the previous sections do 1113 not illustrate such functionality, it is also permitted when 1114 employing ICE-HIP-UDP mode. 1116 In ICE-HIP-UDP mode, a retransmission of a connectivity check SHOULD 1117 be sent with the same sequence identifier in the SEQ parameter. Some 1118 tested address candidates will never produce a working address pair, 1119 and thus may cause retransmissions. Upon successful nomination an 1120 address pair, a host MAY immediately stop sending such 1121 retransmissions. 1123 ICE procedures for prioritizing candidates, eliminating redundant 1124 candidates and forming check lists (including pruning) must be 1125 followed (as specified in [I-D.ietf-ice-rfc5245bis]), with the 1126 exception that the foundation, frozen candidates and default 1127 candidates are not used. From viewpoint of the ICE specification 1128 [I-D.ietf-ice-rfc5245bis], the protocol specified in this document 1129 operates using Component ID of 1 on all candidates, and the 1130 foundation of all candidates is unique. This specification defines 1131 only "full ICE" mode, and the "lite ICE" is not supported. The 1132 reasoning behind the missing features is described in Appendix B. 1134 The connectivity check messages MUST be paced by the Ta value 1135 negotiated during the base exchange as described in Section 4.4. If 1136 neither one of the hosts announced a minimum pacing value, a value of 1137 50 ms SHOULD be used. 1139 Both hosts MUST form a priority ordered checklist and begin to check 1140 transactions every Ta milliseconds as long as the checks are running 1141 and there are candidate pairs whose tests have not started. The 1142 retransmission timeout (RTO) for the connectivity check UPDATE 1143 packets SHOULD be calculated as follows: 1145 RTO = MAX (500ms, Ta * (Num-Waiting + Num-In-Progress)) 1147 In the RTO formula, Ta is the value used for the connectivity check 1148 pacing, Num-Waiting is the number of pairs in the checklist in the 1149 "Waiting" state, and Num-In-Progress is the number of pairs in the 1150 "In-Progress" state. This is identical to the formula in 1151 [I-D.ietf-ice-rfc5245bis] when there is only one checklist. A 1152 smaller value than 500 ms for the RTO MUST NOT be used. 1154 Each connectivity check request packet MUST contain a 1155 CANDIDATE_PRIORITY parameter (see Section 5.14) with the priority 1156 value that would be assigned to a peer reflexive candidate if one was 1157 learned from the corresponding check. An UPDATE packet that 1158 acknowledges a connectivity check request MUST be sent from the same 1159 address that received the check and delivered to the same address 1160 where the check was received from. Each acknowledgment UPDATE packet 1161 MUST contain a MAPPED_ADDRESS parameter with the port, protocol, and 1162 IP address of the address where the connectivity check request was 1163 received from. 1165 Following the ICE guidelines [I-D.ietf-ice-rfc5245bis], it is 1166 RECOMMENDED to restrict the total number of connectivity checks to 1167 100 for each host association. This can be achieved by limiting the 1168 connectivity checks to the 100 candidate pairs with the highest 1169 priority. 1171 4.6.3. Rules for Concluding Connectivity Checks 1173 The controlling agent may find multiple working candidate pairs. To 1174 conclude the connectivity checks, it SHOULD nominate the pair with 1175 the highest priority. The controlling agent MUST nominate a 1176 candidate pair essentially by repeating a connectivity check using an 1177 UPDATE message that contains a SEQ parameter (with new sequence 1178 number), a ECHO_REQUEST_SIGNED parameter, the priority of the 1179 candidate in a CANDIDATE_PRIORITY parameter and NOMINATE parameter to 1180 signify conclusion of the connectivity checks. Since the nominated 1181 address pair has already been tested for reachability, the controlled 1182 host should be able to receive the message. Upon reception, the 1183 controlled host SHOULD select the nominated address pair. The 1184 response message MUST include a SEQ parameter with a new sequence id, 1185 acknowledgment of the sequence from the controlling host in an ACK 1186 parameter, a new ECHO_REQUEST_SIGNED parameter, ECHO_RESPONSE_SIGNED 1187 parameter corresponding to the ECHO_REQUEST_SIGNED parameter from the 1188 controlling host and the NOMINATE parameter. After sending this 1189 packet, the controlled host can create IPsec security associations 1190 using the nominated address candidate for delivering application 1191 payload to the controlling host. Since the message from the 1192 controlled host included a new sequence id and echo request for 1193 signature, the controlling host MUST acknowledge this with a new 1194 UPDATE message that includes an ACK and ECHO_RESPONSE_SIGNED 1195 parameters. After this final concluding message, the controlling 1196 host also can create IPsec security associations for delivering 1197 application payload to the controlled host. 1199 It is possible that packets are delayed by the network. Both hosts 1200 MUST continue to respond to any connectivity checks despite an 1201 address pair having been nominated. 1203 If all the connectivity checks have failed, the hosts MUST NOT send 1204 ESP traffic to each other but MAY continue communicating using HIP 1205 packets and the locators used for the base exchange. Also, the hosts 1206 SHOULD notify each other about the failure with a 1207 CONNECTIVITY_CHECKS_FAILED NOTIFY packet (see Section 5.10). 1209 4.7. NAT Traversal Optimizations 1211 4.7.1. Minimal NAT Traversal Support 1213 If the Responder has a fixed and publicly reachable IPv4 address and 1214 does not employ a Control Relay Server, the explicit NAT traversal 1215 mode negotiation MAY be omitted, and thus even the UDP-ENCAPSULATION 1216 mode does not have to be negotiated. In such a scenario, the 1217 Initiator sends an I1 message over UDP and the Responder responds 1218 with an R1 message over UDP without including any NAT traversal mode 1219 parameter. The rest of the base exchange follows the procedures 1220 defined in [RFC7401], except that the control and data plane use UDP 1221 encapsulation. Here, the use of UDP for NAT traversal is agreed 1222 implicitly. This way of operation is still subject to NAT timeouts, 1223 and the hosts MUST employ NAT keepalives as defined in Section 4.10. 1225 When UDP-ENCAPSULATION mode is chosen either explicitly or 1226 implicitly, the connectivity checks as defined in this document MUST 1227 NOT be used. When hosts lose connectivity, they MUST instead utilize 1228 [RFC8046] or [RFC8047] procedures, but with the difference being that 1229 UDP-based tunneling MUST be employed for the entire lifetime of the 1230 corresponding Host Association. 1232 4.7.2. Base Exchange without Connectivity Checks 1234 It is possible to run a base exchange without any connectivity checks 1235 as defined in Legacy ICE-HIP section 4.8 [RFC5770]. The procedure is 1236 applicable also in the context of this specification, so it is 1237 repeated here for completeness. 1239 In certain network environments, the connectivity checks can be 1240 omitted to reduce initial connection set-up latency because a base 1241 exchange acts as an implicit connectivity test itself. For this to 1242 work, the Initiator MUST be able to reach the Responder by simply UDP 1243 encapsulating HIP and ESP packets sent to the Responder's address. 1244 Detecting and configuring this particular scenario is prone to 1245 failure unless carefully planned. 1247 In such a scenario, the Responder MAY include UDP-ENCAPSULATION NAT 1248 traversal mode as one of the supported modes in the R1 packet. If 1249 the Responder has registered to a Control Relay Server, it MUST also 1250 include a LOCATOR_SET parameter in R1 that contains a preferred 1251 address where the Responder is able to receive UDP-encapsulated ESP 1252 and HIP packets. This locator MUST be of type "Transport address", 1253 its Traffic type MUST be "both", and it MUST have the "Preferred bit" 1254 set (see Table 1). If there is no such locator in R1, the source 1255 address of R1 is used as the Responder's preferred address. 1257 The Initiator MAY choose the UDP-ENCAPSULATION mode if the Responder 1258 listed it in the supported modes and the Initiator does not wish to 1259 use the connectivity checks defined in this document for searching 1260 for a more optimal path. In this case, the Initiator sends the I2 1261 with UDP-ENCAPSULATION mode in the NAT traversal mode parameter 1262 directly to the Responder's preferred address (i.e., to the preferred 1263 locator in R1 or to the address where R1 was received from if there 1264 was no preferred locator in R1). The Initiator MAY include locators 1265 in I2 but they MUST NOT be taken as address candidates, since 1266 connectivity checks defined in this document will not be used for 1267 connections with UDP-ENCAPSULATION NAT traversal mode. Instead, if 1268 R2 and I2 are received and processed successfully, a security 1269 association can be created and UDP-encapsulated ESP can be exchanged 1270 between the hosts after the base exchange completes. However, the 1271 Responder SHOULD NOT send any ESP to the Initiator's address before 1272 it has received data from the Initiator, as specified in Sections 1273 4.4.3. and 6.9 of [RFC7401] and in Sections 3.2.9 and 5.4 of 1274 [RFC8046]. 1276 Since an I2 packet with UDP-ENCAPSULATION NAT traversal mode selected 1277 MUST NOT be sent via a Control Relay Server, the Responder SHOULD 1278 reject such I2 packets and reply with a 1279 NO_VALID_NAT_TRAVERSAL_MODE_PARAMETER NOTIFY packet (see 1280 Section 5.10). 1282 If there is no answer for the I2 packet sent directly to the 1283 Responder's preferred address, the Initiator MAY send another I2 via 1284 the Control Relay Server, but it MUST NOT choose UDP-ENCAPSULATION 1285 NAT traversal mode for that I2. 1287 4.7.3. Initiating a Base Exchange both with and without UDP 1288 Encapsulation 1290 It is possible to run a base exchange in parallel both with and 1291 without UDP encapsulation as defined in Legacy ICE-HIP section 4.9 in 1292 [RFC5770]. The procedure is applicable also in the context of this 1293 specification, so it is repeated here for completeness. 1295 The Initiator MAY also try to simultaneously perform a base exchange 1296 with the Responder without UDP encapsulation. In such a case, the 1297 Initiator sends two I1 packets, one without and one with UDP 1298 encapsulation, to the Responder. The Initiator MAY wait for a while 1299 before sending the other I1. How long to wait and in which order to 1300 send the I1 packets can be decided based on local policy. For 1301 retransmissions, the procedure is repeated. 1303 The I1 packet without UDP encapsulation may arrive directly, without 1304 passing any Control Data Relays, at the Responder. When this 1305 happens, the procedures in [RFC7401] are followed for the rest of the 1306 base exchange. The Initiator may receive multiple R1 packets, with 1307 and without UDP encapsulation, from the Responder. However, after 1308 receiving a valid R1 and answering it with an I2, further R1 packets 1309 that are not retransmissions of the original R1 message MUST be 1310 ignored. 1312 The I1 packet without UDP encapsulation may also arrive at a HIP- 1313 capable middlebox. When the middlebox is a HIP rendezvous server and 1314 the Responder has successfully registered with the rendezvous 1315 service, the middlebox follows rendezvous procedures in [RFC8004]. 1317 If the Initiator receives a NAT traversal mode parameter in R1 1318 without UDP encapsulation, the Initiator MAY ignore this parameter 1319 and send an I2 without UDP encapsulation and without any selected NAT 1320 traversal mode. When the Responder receives the I2 without UDP 1321 encapsulation and without NAT traversal mode, it will assume that no 1322 NAT traversal mechanism is needed. The packet processing will be 1323 done as described in [RFC7401]. The Initiator MAY store the NAT 1324 traversal modes for future use, e.g., in case of a mobility or 1325 multihoming event that causes NAT traversal to be used during the 1326 lifetime of the HIP association. 1328 4.8. Sending Control Packets after the Base Exchange 1330 The same considerations of sending control packets after the base 1331 exchange described in legacy ICE-HIP section 5.10 in [RFC5770] apply 1332 also here, so they are repeated here for completeness. 1334 After the base exchange, the two end-hosts MAY send HIP control 1335 packets directly to each other using the transport address pair 1336 established for a data channel without sending the control packets 1337 through any Control Relay Servers . When a host does not receive 1338 acknowledgments, e.g., to an UPDATE or CLOSE packet after a timeout 1339 based on local policies, a host SHOULD resend the packet through the 1340 associated Data Relay Server of the peer (if the peer listed it in 1341 its LOCATOR_SET parameter in the base exchange. 1343 If Control Relay Client sends a packet through a Control Relay 1344 Server, the Control Relay Client MUST always utilize the RELAY_TO 1345 parameter. The Control Relay Server SHOULD forward HIP control 1346 packets originating from a Control Relay Client to the address 1347 denoted in the RELAY_TO parameter. In the other direction, the 1348 Control Relay Server SHOULD forward HIP control packets to the 1349 Control Relay Clients, and MUST add a RELAY_FROM parameter to the 1350 control packets it relays to the Control Relay Clients. 1352 If the Control Relay Server is not willing or able to relay a HIP 1353 packet, it MAY notify the sender of the packet with 1354 MESSAGE_NOT_RELAYED error notification (see Section 5.10). 1356 4.9. Mobility Handover Procedure 1358 A host may move after base exchange and connectivity checks. 1359 Mobility extensions for HIP [RFC8046] define handover procedures 1360 without NATs. In this section, we define how two hosts interact with 1361 handover procedures in scenarios involving NATs. The specified 1362 extensions define only simple mobility using a pair of security 1363 associations, and multihoming extensions are left to be defined in 1364 later specifications. The procedures in this section offer the same 1365 functionality as "ICE restart" specified in 1366 [I-D.ietf-ice-rfc5245bis]. The example described in this section 1367 shows only a Control Relay Server for the peer host for the sake of 1368 simplicity, but the mobile host may also have a Control Relay Server. 1370 The assumption here is that the two hosts have successfully 1371 negotiated and chosen the ICE-HIP-UDP mode during the base exchange 1372 as defined in Section 4.3. The Initiator of the base exchange MUST 1373 store information that it was the controlling host during the base 1374 exchange. Similarly, the Responder MUST store information that it 1375 was the controlled host during the base exchange. 1377 Prior to starting the handover procedures with all peer hosts, the 1378 mobile host SHOULD first send its locators in UPDATE messages to its 1379 Control and Data Relay Servers if it has registered to such. It 1380 SHOULD wait for all of them to respond for a configurable time, by 1381 default two minutes, and then continue with the handover procedure 1382 without information from the Relay Server that did not respond. As 1383 defined in Section 4.1, a response message from a Control Relay 1384 Server includes a REG_FROM parameter that describes the server 1385 reflexive candidate of the mobile host to be used in the candidate 1386 exchange during the handover. Similarly, an UPDATE to a Data Relay 1387 Server is necessary to make sure the Data Relay Server can forward 1388 data to the correct IP address after a handoff. 1390 The mobility extensions for NAT traversal are illustrated in 1391 Figure 6. The mobile host is the host that has changed its locators, 1392 and the peer host is the host it has a host association with. The 1393 mobile host may have multiple peers and it repeats the process with 1394 all of its peers. In the figure, the Control Relay Server belongs to 1395 the peer host, i.e., the peer host is a Control Relay Client for the 1396 Control Relay Server. Note that the figure corresponds to figure 3 1397 in [RFC8046], but the difference is that the main UPDATE procedure is 1398 carried over the relay and the connectivity is tested separately. 1399 Next, we describe the procedure in the figure in detail. 1401 Mobile Host Control Relay Server Peer Host 1402 | 1. UDP(UPDATE(ESP_INFO, | | 1403 | LOC_SET, SEQ)) | | 1404 +--------------------------------->| 2. UDP(UPDATE(ESP_INFO, | 1405 | | LOC_SET, SEQ, | 1406 | | RELAY_FROM)) | 1407 | +------------------------------->| 1408 | | | 1409 | | 3. UDP(UPDATE(ESP_INFO, SEQ, | 1410 | | ACK, ECHO_REQ_SIGN, | 1411 | | RELAY_TO)) | 1412 | 4. UDP(UPDATE(ESP_INFO, SEQ, |<-------------------------------+ 1413 | ACK, ECHO_REQ_SIGN, | | 1414 | RELAY_TO)) | | 1415 |<---------------------------------+ | 1416 | | | 1417 | 5. UDP(UPDATE(ACK, | | 1418 | ECHO_RESP_SIGNED)) | | 1419 +--------------------------------->| 6. UDP(UPDATE(ACK, | 1420 | | ECHO_RESP_SIGNED, | 1421 | | RELAY_FROM)) | 1422 | +------------------------------->| 1423 | | | 1424 | 7. connectivity checks over UDP | 1425 +<----------------------------------------------------------------->+ 1426 | | | 1427 | 8. ESP data over UDP | 1428 +<----------------------------------------------------------------->+ 1429 | | | 1431 Figure 6: HIP UPDATE procedure 1433 In step 1, the mobile host has changed location and sends a location 1434 update to its peer through the Control Relay Server of the peer. It 1435 sends an UPDATE packet with source HIT belonging to itself and 1436 destination HIT belonging to the peer host. In the packet, the 1437 source IP address belongs to the mobile host and the destination to 1438 the Control Relay Server. The packet contains an ESP_INFO parameter, 1439 where, in this case, the OLD SPI and NEW SPI parameters both contain 1440 the pre-existing incoming SPI. The packet also contains the locators 1441 of the mobile host in a LOCATOR_SET parameter. The packet contains 1442 also a SEQ number to be acknowledged by the peer. As specified in 1443 [RFC8046], the packet may also include a HOST_ID (for middlebox 1444 inspection) and DIFFIE_HELLMAN parameter for rekeying. 1446 In step 2, the Control Relay Server receives the UPDATE packet and 1447 forwards it to the peer host (i.e. Control Relay Client). The 1448 Control Relay Server rewrites the destination IP address and appends 1449 a RELAY_FROM parameter to the message. 1451 In step 3, the peer host receives the UPDATE packet, processes it and 1452 responds with another UPDATE message. The message is destined to the 1453 HIT of mobile host and to the IP address of the Control Relay Server. 1454 The message includes an ESP_INFO parameter where, in this case, the 1455 OLD SPI and NEW SPI parameters both contain the pre-existing incoming 1456 SPI. The peer includes a new SEQ and ECHO_REQUEST_SIGNED parameters 1457 to be acknowledged by the mobile host. The message acknowledges the 1458 SEQ parameter of the earlier message with an ACK parameter. The 1459 RELAY_TO parameter specifies the address of the mobile host where the 1460 Control Relay Server should forward the message. 1462 In step 4, the Control Relay Server receives the message, rewrites 1463 the destination IP address and UDP port according to the RELAY_TO 1464 parameter, and then forwards the modified message to the mobile host. 1466 In step 5, the mobile host receives the UPDATE packet and processes 1467 it. The mobile host concludes the handover procedure by 1468 acknowledging the received SEQ parameter with an ACK parameter and 1469 the ECHO_REQUEST_SIGNED parameter with ECHO_RESPONSE_SIGNED 1470 parameter. The mobile host delivers the packet to the HIT of the 1471 peer and to the address of the HIP relay. The mobile host can start 1472 connectivity checks after this packet. 1474 In step 6, HIP relay receives the UPDATE packet and forwards it to 1475 the peer host (i.e. Relay Client). The HIP relay rewrites the 1476 destination IP address and port, and then appends a RELAY_FROM 1477 parameter to the message. When the peer host receives this 1478 concluding UPDATE packet, it can initiate the connectivity checks. 1480 In step 7, the two hosts test for connectivity across NATs according 1481 to procedures described in Section 4.6. The original Initiator of 1482 the communications is the controlling and the original Responder is 1483 the controlled host. 1485 In step 8, the connectivity checks are successfully completed and the 1486 controlling host has nominated one address pair to be used. The 1487 hosts set up security associations to deliver the application 1488 payload. 1490 It is worth noting that the Control and Data Relay Client do not have 1491 to re-register for the related services after a handoff. However, if 1492 a Data Relay Client has registered a relayed address candidate from a 1493 Data Relay Server, the Data Relay Client MUST reactivate the address 1494 before the connectivity checks by sending an UPDATE message 1495 containing PEER_PERMISSION parameter as described in Section 4.12.1. 1497 Otherwise, the Data Relay Server drops ESP packets sent to the 1498 relayed address. 1500 In so called "double jump" or simultaneous mobility scenario both 1501 peers change their location simultaneously. In such a case, both 1502 peers trigger the procedure described earlier in this section at the 1503 same time. In other words, both of the communicating hosts send an 1504 UPDATE packet carrying locators at the same time or with some delay. 1505 When the locators are exchanged almost simultaneously (reliably via 1506 Control Relay Servers), the two hosts can continue with connectivity 1507 checks after both have completed separately the steps in Figure 6. 1508 The problematic case occurs when the one of the hosts (referred here 1509 as host "M") moves later during the connectivity checks. In such a 1510 case, host M sends a locator to the peer which is in the middle of 1511 connectivity checks. Upon receiving the UPDATE message, the peer 1512 responds with an UPDATE with ECHO_REQ_SIGN as described in step 3 in 1513 Figure 6. Upon receiving the valid response from host M as described 1514 in step 6, the peer host MUST restart the connectivity checks with 1515 host M. This way, both hosts start the connectivity checks roughly 1516 in a synchronized way. It is also important that peer host does not 1517 restart the connectivity checks until it has received a valid "fresh" 1518 confirmation from host M because the UPDATE message carrying locators 1519 could be replayed by an attacker. 1521 4.10. NAT Keepalives 1523 To prevent NAT states from expiring, communicating hosts MUST send 1524 periodic keepalives to other hosts with which they have established a 1525 Host Association every 15 seconds (the so called Tr value in ICE). 1526 Other values MAY be used, but a Tr value smaller than 15 seconds MUST 1527 NOT be used. Both a Control/Data Relay Client and Control/Data Relay 1528 Server, as well as two peers employing UDP-ENCAPSULATION or ICE-HIP- 1529 UDP mode, SHOULD send HIP NOTIFY packets unless they have exchanged 1530 some other traffic over the used UDP ports. However, the Data Relay 1531 Client and Data Relay Server MUST employ only HIP NOTIFY packets in 1532 order to keep the server reflexive candidates alive. The keepalive 1533 message encoding format is defined in Section 5.3. If the base 1534 exchange or mobility handover procedure occurs during an extremely 1535 slow path, a host (with a Host Association with the peer) MAY also 1536 send HIP NOTIFY packets every 15 seconds to keep the path active with 1537 the recipient. 1539 4.11. Closing Procedure 1541 The two-way procedure for closing a HIP association and the related 1542 security associations is defined in [RFC7401]. One host initiates 1543 the procedure by sending a CLOSE message and the recipient confirms 1544 it with CLOSE_ACK. All packets are protected using HMACs and 1545 signatures, and the CLOSE messages includes a ECHO_REQUEST_SIGNED 1546 parameter to protect against replay attacks. 1548 The same procedure for closing HIP associations applies also here, 1549 but the messaging occurs using the UDP encapsulated tunnel that the 1550 two hosts employ. A host sending the CLOSE message SHOULD first send 1551 the message over a direct link. After a number of retransmissions, 1552 it MUST send over a Control Relay Server of the recipient if one 1553 exists. The host receiving the CLOSE message directly without a 1554 Control Data Relay SHOULD respond directly. If CLOSE message came 1555 via a Control Data Relay, the host SHOULD respond using the same 1556 Control Data Relay. 1558 4.12. Relaying Considerations 1560 4.12.1. Forwarding Rules and Permissions 1562 The Data Relay Server uses a similar permission model as a TURN 1563 server: before the Data Relay Server forwards any ESP data packets 1564 from a peer to a Data Relay Client (or the other direction), the 1565 client MUST set a permission for the peer's address. The permissions 1566 also install a forwarding rule for each direction, similar to TURN's 1567 channels, based on the Security Parameter Index (SPI) values in the 1568 ESP packets. 1570 Permissions are not required for HIP control packets. However, if a 1571 relayed address (as conveyed in the RELAYED_ADDRESS parameter from 1572 the Data Relay Server) is selected to be used for data, the Control 1573 Relay Client MUST send an UPDATE message to the Data Relay Server 1574 containing a PEER_PERMISSION parameter (see Section 5.13) with the 1575 following information: the UDP port and address for the server 1576 reflexive address, the UDP port and address of the peer, and the 1577 inbound and outbound SPIs used for ESP. The packet MUST be sent to 1578 the same UDP tunnel the Client employed in the base exchange to 1579 contact the Server (i.e., not to the port occupied by the server 1580 reflexive candidate). To avoid packet dropping of ESP packets, the 1581 Control Relay Client SHOULD send the PEER_PERMISSION parameter before 1582 connectivity checks both in the case of base exchange and a mobility 1583 handover. It is worth noting that the UPDATE message includes a SEQ 1584 parameter (as specified in [RFC7401]) that the Data Relay Server must 1585 acknowledge, so that the Control Relay Client can resend the message 1586 with PEER_PERMISSION parameter if it gets lost. 1588 When a Data Relay Server receives an UPDATE with a PEER_PERMISSION 1589 parameter, it MUST check if the sender of the UPDATE is registered 1590 for data relaying service, and drop the UPDATE if the host was not 1591 registered. If the host was registered, the Data Relay Server checks 1592 if there is a permission with matching information (protocol, 1593 addresses, ports and SPI values). If there is no such permission, a 1594 new permission MUST be created and its lifetime MUST be set to 5 1595 minutes. If an identical permission already existed, it MUST be 1596 refreshed by setting the lifetime to 5 minutes. A Data Relay Client 1597 SHOULD refresh permissions 1 minute before the expiration when the 1598 permission is still needed. 1600 When a Data Relay Server receives an UPDATE from a registered client 1601 but without a PEER_PERMISSION parameter and with a new locator set, 1602 the Data Relay Server can assume that the mobile host has changed its 1603 location and, thus, is not reachable in its previous location. In 1604 such an event, the Data Relay Server SHOULD deactivate the permission 1605 and stop relaying data plane traffic to the client. 1607 The relayed address MUST be activated with the PEER_PERMISSION 1608 parameter both after a base exchange and after a handover procedure 1609 with another ICE-HIP-UDP capable host. Unless activated, the Data 1610 Relay Server MUST drop all ESP packets. It is worth noting that a 1611 Data Relay Client does not have to renew its registration upon a 1612 change of location UPDATE, but only when the lifetime of the 1613 registration is close to end. 1615 4.12.2. HIP Data Relay and Relaying of Control Packets 1617 When a Data Relay Server accepts to relay UDP encapsulated ESP 1618 between a Data Relay Client and its peer, the Data Relay Server opens 1619 a UDP port (relayed address) for this purpose as described in 1620 Section 4.1. This port can be used for delivering also control 1621 packets because connectivity checks also cover the path through the 1622 Data Relay Server. If the Data Relay Server receives a UDP 1623 encapsulated HIP control packet on that port, it MUST forward the 1624 packet to the Data Relay Client and add a RELAY_FROM parameter to the 1625 packet as if the Data Relay Server were acting as a Control Relay 1626 Server. When the Data Relay Client replies to a control packet with 1627 a RELAY_FROM parameter via its Data Relay Server, the Data Relay 1628 Client MUST add a RELAY_TO parameter containing the peer's address 1629 and use the address of its Data Relay Server as the destination 1630 address. Further, the Data Relay Server MUST send this packet to the 1631 peer's address from the relayed address. 1633 If the Data Relay Server receives a UDP packet that is not a HIP 1634 control packet to the relayed address, it MUST check if it has a 1635 permission set for the peer the packet is arriving from (i.e., the 1636 sender's address and SPI value matches to an installed permission). 1637 If permissions are set, the Data Relay Server MUST forward the packet 1638 to the Data Relay Client that created the permission. The Data Relay 1639 Server MUST also implement the similar checks for the reverse 1640 direction (i.e. ESP packets from the Data Relay Client to the peer). 1641 Packets without a permission MUST be dropped silently. 1643 4.12.3. Handling Conflicting SPI Values 1645 From the viewpoint of a host, its remote peers can have overlapping 1646 inbound SPI numbers because the IPsec uses also the destination IP 1647 address to index the remote peer host. However, a Data Relay Server 1648 can represent multiple remote peers, thus masquerading the actual 1649 destination. Since a Data Relay Server may have to deal with a 1650 multitude of Relay Clients and their peers, a Data Relay Server may 1651 experience collisions in the SPI namespace, thus being unable forward 1652 datagrams to the correct destination. Since the SPI space is 32 bits 1653 and the SPI values should be random, the probability for a 1654 conflicting SPI value is fairly small, but could occur on a busy Data 1655 Relay Server. The two problematic cases are described in this 1656 section. 1658 In the first scenario, the SPI collision problems occurs if two hosts 1659 have registered to the same Data Relay Server and a third host 1660 initiates base exchange with both of them. Here, the two Responders 1661 (i.e. Data Relay Clients) claim the same inbound SPI number with the 1662 same Initiator (peer). However, in this case, the Data Relay Server 1663 has allocated separate UDP ports for the two Data Relay Clients 1664 acting now as Responders (as recommended in Section 6.5). When the 1665 third host sends an ESP packet, the Data Relay Server is able to 1666 forward the packet to the correct Data Relay Client because the 1667 destination UDP port is different for each of the clients. 1669 In the second scenario, an SPI collision may occur when two 1670 Initiators run a base exchange to the same Responder (i.e. Data 1671 Relay Client), and both of the Initiators claim the same inbound SPI 1672 at the Data Relay Server using PEER_PERMISSION Parameter. In this 1673 case, the Data Relay Server cannot disambiguate the correct 1674 destination of an ESP packet originating from the Data Relay Client 1675 because the SPI could belong to either of the peers (and destination 1676 IP and UDP port belonging to the Data Relay Server are not unique 1677 either). The recommended way and a contingency plan to solve this 1678 issue are described below. 1680 The recommend way to mitigate the problem is as follows. For each 1681 new Host Association, A Data Relay Client acting as a Responder 1682 SHOULD register a new server reflexive candidate as described in 1683 Section 4.2. Similarly, the Data Relay Server SHOULD NOT re-use the 1684 port numbers as described in Section 6.5. This way, each server 1685 reflexive candidate for the Data Relay Client has a separate UDP port 1686 that the Data Relay Server can use to disambiguate packet 1687 destinations in case of SPI collisions. 1689 When the Data Relay Client is not registering or failed to register a 1690 new relay candidate for a new peer, the Data Relay Client MUST follow 1691 a contingency plan as follows. Upon receiving an I2 with a colliding 1692 SPI, the Data Relay client acting as the Responder MUST NOT include 1693 the relayed address candidate in the R2 message because the Data 1694 Relay Server would not be able demultiplex the related ESP packet to 1695 the correct Initiator. The same applies also the handover 1696 procedures; the Data Relay Client MUST NOT include the relayed 1697 address candidate when sending its new locator set in an UPDATE to 1698 its peer if it would cause a SPI conflict with another peer. 1700 5. Packet Formats 1702 The following subsections define the parameter and packet encodings 1703 for the HIP and ESP packets. All values MUST be in network byte 1704 order. 1706 It is worth noting that most of the parameters are shown for the sake 1707 of completeness even though they are specified already in Legacy ICE- 1708 HIP [RFC5770]. New parameters are explicitly described as new. 1710 5.1. HIP Control Packets 1712 Figure 7 illustrates the packet format for UDP-encapsulated HIP. The 1713 format is identical to Legacy ICE-HIP [RFC5770]. 1715 0 1 2 3 1716 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 1717 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1718 | Source Port | Destination Port | 1719 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1720 | Length | Checksum | 1721 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1722 | 32 bits of zeroes | 1723 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1724 | | 1725 ~ HIP Header and Parameters ~ 1726 | | 1727 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1729 Figure 7: Format of UDP-Encapsulated HIP Control Packets 1731 HIP control packets are encapsulated in UDP packets as defined in 1732 Section 2.2 of [RFC3948], "IKE Header Format for Port 4500", except 1733 that a different port number is used. Figure 7 illustrates the 1734 encapsulation. The UDP header is followed by 32 zero bits that can 1735 be used to differentiate HIP control packets from ESP packets. The 1736 HIP header and parameters follow the conventions of [RFC7401] with 1737 the exception that the HIP header checksum MUST be zero. The HIP 1738 header checksum is zero for two reasons. First, the UDP header 1739 already contains a checksum. Second, the checksum definition in 1740 [RFC7401] includes the IP addresses in the checksum calculation. The 1741 NATs that are unaware of HIP cannot recompute the HIP checksum after 1742 changing IP addresses. 1744 A Control/Data Relay Server or a non-relay Responder SHOULD listen at 1745 UDP port 10500 for incoming UDP-encapsulated HIP control packets. If 1746 some other port number is used, it needs to be known by potential 1747 Initiators. 1749 It is worth noting that UDP encapsulation of HIP packets reduces the 1750 Maximum Transfer Unit (MTU) size of the control plane by 12 bytes. 1752 5.2. Connectivity Checks 1754 HIP connectivity checks are HIP UPDATE packets. The format is 1755 specified in [RFC7401]. 1757 5.3. Keepalives 1759 The RECOMMENDED encoding format for keepalives is HIP NOTIFY packets 1760 as specified in [RFC7401] with Notify message type field set to 1761 NAT_KEEPALIVE [TBD by IANA: 16385] and with an empty Notification 1762 data field. It is worth noting that sending of such a HIP NOTIFY 1763 message MAY be omitted if the host is actively (or passively) sending 1764 some other traffic (HIP or ESP) to the peer host over the related UDP 1765 tunnel during the Tr period. For instance, the host MAY actively 1766 send ICMPv6 requests (or respond with an ICMPv6 response) inside the 1767 ESP tunnel to test the health of the associated IPsec security 1768 association. Alternatively, the host MAY use UPDATE packets as a 1769 substitute. A minimal UPDATE packet would consist of a SEQ and 1770 ECHO_REQ_SIGN parameters, and a more complex would involve rekeying 1771 procedures as specified in section 6.8 in [RFC7402]. It is worth 1772 noting that a host actively sending periodic UPDATE packets to a busy 1773 server may increase the computational load of the server since it has 1774 to verify HMACs and signatures in UPDATE messages. 1776 5.4. NAT Traversal Mode Parameter 1778 The format of NAT traversal mode parameter is borrowed from Legacy 1779 ICE-HIP [RFC5770]. The format of the NAT_TRAVERSAL_MODE parameter is 1780 similar to the format of the ESP_TRANSFORM parameter in [RFC7402] and 1781 is shown in Figure 8. The Native ICE-HIP extension specified in this 1782 document defines the new NAT traversal mode identifier for ICE-HIP- 1783 UDP and reuses the UDP-ENCAPSULATION mode from Legacy ICE-HIP 1785 [RFC5770]. The identifier named RESERVED is reserved for future use. 1786 Future specifications may define more traversal modes. 1788 0 1 2 3 1789 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 1790 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1791 | Type | Length | 1792 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1793 | Reserved | Mode ID #1 | 1794 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1795 | Mode ID #2 | Mode ID #3 | 1796 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1797 | Mode ID #n | Padding | 1798 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1800 Type 608 1801 Length length in octets, excluding Type, Length, and padding 1802 Reserved zero when sent, ignored when received 1803 Mode ID defines the proposed or selected NAT traversal mode(s) 1805 The following NAT traversal mode IDs are defined: 1807 ID name Value 1808 RESERVED 0 1809 UDP-ENCAPSULATION 1 1810 ICE-STUN-UDP 2 1811 ICE-HIP-UDP 3 1813 Figure 8: Format of the NAT_TRAVERSAL_MODE Parameter 1815 The sender of a NAT_TRAVERSAL_MODE parameter MUST make sure that 1816 there are no more than six (6) Mode IDs in one NAT_TRAVERSAL_MODE 1817 parameter. Conversely, a recipient MUST be prepared to handle 1818 received NAT traversal mode parameters that contain more than six 1819 Mode IDs by accepting the first six Mode IDs and dropping the rest. 1820 The limited number of Mode IDs sets the maximum size of the 1821 NAT_TRAVERSAL_MODE parameter. The modes MUST be in preference order, 1822 most preferred mode(s) first. 1824 Implementations conforming to this specification MUST implement UDP- 1825 ENCAPSULATION and SHOULD implement ICE-HIP-UDP modes. 1827 5.5. Connectivity Check Transaction Pacing Parameter 1829 The TRANSACTION_PACING is defined in [RFC5770], but repeated in 1830 Figure 9 for completeness. It contains only the connectivity check 1831 pacing value, expressed in milliseconds, as a 32-bit unsigned 1832 integer. 1834 0 1 2 3 1835 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 1836 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1837 | Type | Length | 1838 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1839 | Min Ta | 1840 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1842 Type 610 1843 Length 4 1844 Min Ta the minimum connectivity check transaction pacing 1845 value the host would use (in milliseconds) 1847 Figure 9: Format of the TRANSACTION_PACING Parameter 1849 5.6. Relay and Registration Parameters 1851 The format of the REG_FROM, RELAY_FROM, and RELAY_TO parameters is 1852 shown in Figure 10. All parameters are identical except for the 1853 type. REG_FROM is the only parameter covered with the signature. 1855 0 1 2 3 1856 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 1857 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1858 | Type | Length | 1859 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1860 | Port | Protocol | Reserved | 1861 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1862 | | 1863 | Address | 1864 | | 1865 | | 1866 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1868 Type REG_FROM: 950 1869 RELAY_FROM: 63998 1870 RELAY_TO: 64002 1871 Length 20 1872 Port transport port number; zero when plain IP is used 1873 Protocol IANA assigned, Internet Protocol number. 1874 17 for UDP, 0 for plain IP 1875 Reserved reserved for future use; zero when sent, ignored 1876 when received 1877 Address an IPv6 address or an IPv4 address in "IPv4-Mapped 1878 IPv6 address" format 1880 Figure 10: Format of the REG_FROM, RELAY_FROM, and RELAY_TO 1881 Parameters 1883 REG_FROM contains the transport address and protocol from which the 1884 Control Relay Server sees the registration coming. RELAY_FROM 1885 contains the address from which the relayed packet was received by 1886 the Control Relay Server and the protocol that was used. RELAY_TO 1887 contains the same information about the address to which a packet 1888 should be forwarded. 1890 5.7. LOCATOR_SET Parameter 1892 This specification reuses the format for UDP-based locators as 1893 specified in Legacy ICE-HIP [RFC5770] to be used for communicating 1894 the address candidates between two hosts. The generic and NAT- 1895 traversal-specific locator parameters are illustrated in Figure 11. 1897 0 1 2 3 1898 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 1899 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1900 | Type | Length | 1901 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1902 | Traffic Type | Locator Type | Locator Length| Reserved |P| 1903 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1904 | Locator Lifetime | 1905 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1906 | Locator | 1907 | | 1908 | | 1909 | | 1910 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1911 . . 1912 . . 1913 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1914 | Traffic Type | Loc Type = 2 | Locator Length| Reserved |P| 1915 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1916 | Locator Lifetime | 1917 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1918 | Transport Port | Transp. Proto| Kind | 1919 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1920 | Priority | 1921 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1922 | SPI | 1923 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1924 | Address | 1925 | | 1926 | | 1927 | | 1928 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1930 Figure 11: LOCATOR_SET Parameter 1932 The individual fields in the LOCATOR_SET parameter are described in 1933 Table 1. 1935 +-----------+----------+--------------------------------------------+ 1936 | Field | Value(s) | Purpose | 1937 +-----------+----------+--------------------------------------------+ 1938 | Type | 193 | Parameter type | 1939 | Length | Variable | Length in octets, excluding Type and | 1940 | | | Length fields and padding | 1941 | Traffic | 0-2 | Is the locator for HIP signaling (1), for | 1942 | Type | | ESP (2), or for both (0) | 1943 | Locator | 2 | "Transport address" locator type | 1944 | Type | | | 1945 | Locator | 7 | Length of the fields after Locator | 1946 | Length | | Lifetime in 4-octet units | 1947 | Reserved | 0 | Reserved for future extensions | 1948 | Preferred | 0 or 1 | Set to 1 for a Locator in R1 if the | 1949 | (P) bit | | Responder can use it for the rest of the | 1950 | | | base exchange, otherwise set to zero | 1951 | Locator | Variable | Locator lifetime in seconds | 1952 | Lifetime | | | 1953 | Transport | Variable | Transport layer port number | 1954 | Port | | | 1955 | Transport | Variable | IANA assigned, transport layer Internet | 1956 | Protocol | | Protocol number. Currently only UDP (17) | 1957 | | | is supported. | 1958 | Kind | Variable | 0 for host, 1 for server reflexive, 2 for | 1959 | | | peer reflexive or 3 for relayed address | 1960 | Priority | Variable | Locator's priority as described in | 1961 | | | [I-D.ietf-ice-rfc5245bis]. It is worth | 1962 | | | noting that while the priority of a single | 1963 | | | locator candidate is 32-bits, but an | 1964 | | | implementation should use a 64-bit integer | 1965 | | | to calculate the priority of a candidate | 1966 | | | pair for the ICE priority algorithm. | 1967 | SPI | Variable | Security Parameter Index (SPI) value that | 1968 | | | the host expects to see in incoming ESP | 1969 | | | packets that use this locator | 1970 | Address | Variable | IPv6 address or an "IPv4-Mapped IPv6 | 1971 | | | address" format IPv4 address [RFC4291] | 1972 +-----------+----------+--------------------------------------------+ 1974 Table 1: Fields of the LOCATOR_SET Parameter 1976 5.8. RELAY_HMAC Parameter 1978 As specified in Legacy ICE-HIP [RFC5770], the RELAY_HMAC parameter 1979 value has the TLV type 65520. It has the same semantics as RVS_HMAC 1980 [RFC8004]. 1982 5.9. Registration Types 1984 The REG_INFO, REG_REQ, REG_RESP, and REG_FAILED parameters contain 1985 Registration Type [RFC8003] values for Control Relay Server 1986 registration. The value for RELAY_UDP_HIP is 2 as specified in 1987 Legacy ICE-HIP [RFC5770]. The value for RELAY_UDP_ESP is (value [TBD 1988 by IANA: 3]). 1990 5.10. Notify Packet Types 1992 A Control/Data Relay Server and end-hosts can use NOTIFY packets to 1993 signal different error conditions. The NOTIFY packet types are the 1994 same as in Legacy ICE-HIP [RFC5770] except for last one, which is 1995 new. 1997 The Notify Packet Types [RFC7401] are shown below. The Notification 1998 Data field for the error notifications SHOULD contain the HIP header 1999 of the rejected packet and SHOULD be empty for the 2000 CONNECTIVITY_CHECKS_FAILED type. 2002 NOTIFICATION PARAMETER - ERROR TYPES Value 2003 ------------------------------------ ----- 2005 NO_VALID_NAT_TRAVERSAL_MODE_PARAMETER 60 2007 If a Control Relay Server does not forward a base exchange packet 2008 due to missing NAT traversal mode parameter, or the Initiator 2009 selects a NAT traversal mode that the (non-relay) Responder did 2010 not expect, the Control Relay Server or the Responder may send 2011 back a NOTIFY error packet with this type. 2013 CONNECTIVITY_CHECKS_FAILED 61 2015 Used by the end-hosts to signal that NAT traversal connectivity 2016 checks failed and did not produce a working path. 2018 MESSAGE_NOT_RELAYED 62 2020 Used by a Control Relay Server to signal that is was not able or 2021 willing to relay a HIP packet. 2023 SERVER_REFLEXIVE_CANDIDATE_ALLOCATION_FAILED 63 2025 Used by a Data Relay Server to signal that is was not able or 2026 willing to allocate a new server reflexive candidate for the Data 2027 Relay Client 2029 5.11. ESP Data Packets 2031 The format for ESP data packets is identical to Legacy ICE-HIP 2032 [RFC5770]. 2034 [RFC3948] describes the UDP encapsulation of the IPsec ESP transport 2035 and tunnel mode. On the wire, the HIP ESP packets do not differ from 2036 the transport mode ESP, and thus the encapsulation of the HIP ESP 2037 packets is same as the UDP encapsulation transport mode ESP. 2038 However, the (semantic) difference to Bound End-to-End Tunnel (BEET) 2039 mode ESP packets used by HIP is that IP header is not used in BEET 2040 integrity protection calculation. 2042 During the HIP base exchange, the two peers exchange parameters that 2043 enable them to define a pair of IPsec ESP security associations (SAs) 2044 as described in [RFC7402]. When two peers perform a UDP-encapsulated 2045 base exchange, they MUST define a pair of IPsec SAs that produces 2046 UDP-encapsulated ESP data traffic. 2048 The management of encryption/authentication protocols and SPIs is 2049 defined in [RFC7402]. The UDP encapsulation format and processing of 2050 HIP ESP traffic is described in Section 6.1 of [RFC7402]. 2052 It is worth noting that UDP encapsulation of ESP reduces the MTU size 2053 of data plane by 8 bytes. 2055 5.12. RELAYED_ADDRESS and MAPPED_ADDRESS Parameters 2057 While the type values are new, the format of the RELAYED_ADDRESS and 2058 MAPPED_ADDRESS parameters (Figure 12) is identical to REG_FROM, 2059 RELAY_FROM and RELAY_TO parameters. This document specifies only the 2060 use of UDP relaying, and, thus, only protocol 17 is allowed. 2061 However, future documents may specify support for other protocols. 2063 0 1 2 3 2064 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 2065 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2066 | Type | Length | 2067 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2068 | Port | Protocol | Reserved | 2069 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2070 | | 2071 | Address | 2072 | | 2073 | | 2074 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2076 Type [TBD by IANA; 2077 RELAYED_ADDRESS: 4650 2078 MAPPED_ADDRESS: 4660] 2079 Length 20 2080 Port the UDP port number 2081 Protocol IANA assigned, Internet Protocol number (17 for UDP) 2082 Reserved reserved for future use; zero when sent, ignored 2083 when received 2084 Address an IPv6 address or an IPv4 address in "IPv4-Mapped 2085 IPv6 address" format 2087 Figure 12: Format of the RELAYED_ADDRESS and MAPPED_ADDRESS 2088 Parameters 2090 5.13. PEER_PERMISSION Parameter 2092 The format of the new PEER_PERMISSION parameter is shown in 2093 Figure 13. The parameter is used for setting up and refreshing 2094 forwarding rules and the permissions for data packets at the Data 2095 Relay Server. The parameter contains one or more sets of Port, 2096 Protocol, Address, Outbound SPI (OSPI), and Inbound SPI (ISPI) 2097 values. One set defines a rule for one peer address. 2099 0 1 2 3 2100 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 2101 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2102 | Type | Length | 2103 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2104 | RPort | PPort | 2105 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2106 | Protocol | Reserved | 2107 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2108 | | 2109 | RAddress | 2110 | | 2111 | | 2112 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2113 | | 2114 | PAddress | 2115 | | 2116 | | 2117 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2118 | OSPI | 2119 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2120 | ISPI | 2121 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2123 Type [TBD by IANA; 4680] 2124 Length 48 2125 RPort the transport layer (UDP) port at the Data Relay Server 2126 (i.e. the port of the server reflexive candidate) 2127 PPort the transport layer (UDP) port number of the peer 2128 Protocol IANA assigned, Internet Protocol number (17 for UDP) 2129 Reserved reserved for future use; zero when sent, ignored 2130 when received 2131 RAddress an IPv6 address, or an IPv4 address in "IPv4-Mapped 2132 IPv6 address" format, of the server reflexive candidate 2133 PAddress an IPv6 address, or an IPv4 address in "IPv4-Mapped 2134 IPv6 address" format, of the peer 2135 OSPI the outbound SPI value the Data Relay Client is using for 2136 the peer 2137 ISPI the inbound SPI value the Data Relay Client is using for 2138 the peer 2140 Figure 13: Format of the PEER_PERMISSION Parameter 2142 5.14. HIP Connectivity Check Packets 2144 The connectivity request messages are HIP UPDATE packets containing a 2145 new CANDIDATE_PRIORITY parameter (Figure 14). Response UPDATE 2146 packets contain a MAPPED_ADDRESS parameter (Figure 12). 2148 0 1 2 3 2149 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 2150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2151 | Type | Length | 2152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2153 | Priority | 2154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2156 Type [TBD by IANA; 4700] 2157 Length 4 2158 Priority the priority of a (potential) peer reflexive candidate 2160 Figure 14: Format of the CANDIDATE_PRIORITY Parameter 2162 5.15. NOMINATE parameter 2164 Figure 15 shows the NOMINATE parameter that is used to conclude the 2165 candidate nomination process. 2167 0 1 2 3 2168 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 2169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2170 | Type | Length | 2171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2172 | Reserved | 2173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2175 Type [TBD by IANA; 4710] 2176 Length 4 2177 Reserved Reserved for future extension purposes 2179 Figure 15: Format of the NOMINATE Parameter 2181 6. Security Considerations 2183 The security considerations are the same as in Legacy ICE-HIP 2184 [RFC5770], but are repeated here for the sake of completeness. 2186 6.1. Privacy Considerations 2188 The locators are in plain text format in favor of inspection at HIP- 2189 aware middleboxes in the future. The current document does not 2190 specify encrypted versions of LOCATOR_SETs, even though it could be 2191 beneficial for privacy reasons to avoid disclosing them to 2192 middleboxes. 2194 It is also possible that end-users may not want to reveal all 2195 locators to each other. For example, tracking the physical location 2196 of a multihoming end-host may become easier if it reveals all 2197 locators to its peer during a base exchange. Also, revealing host 2198 addresses exposes information about the local topology that may not 2199 be allowed in all corporate environments. For these two reasons, an 2200 end-host may exclude certain host addresses from its LOCATOR_SET 2201 parameter. However, such behavior creates non-optimal paths when the 2202 hosts are located behind the same NAT. Especially, this could be 2203 problematic with a legacy NAT that does not support routing from the 2204 private address realm back to itself through the outer address of the 2205 NAT. This scenario is referred to as the hairpin problem [RFC5128]. 2206 With such a legacy NAT, the only option left would be to use a 2207 relayed transport address from a TURN server. 2209 The use of Control and Data Relay Servers can be also useful for 2210 privacy purposes. For example, a privacy concerned Responder may 2211 reveal only its Control Relay Server and Relayed candidates to 2212 Initiators. This same mechanism also protects the Responder against 2213 Denial-of-Service (DoS) attacks by allowing the Responder to initiate 2214 new connections even if its relays would be unavailable due to a DoS 2215 attack. 2217 6.2. Opportunistic Mode 2219 In opportunistic HIP mode, an Initiator sends an I1 with without 2220 setting the destination HIT of the Responder (i.e. the Control Relay 2221 Client). A Control Relay Server SHOULD have a unique IP address per 2222 Control Relay Client when the Control Relay Server is serving more 2223 than one Control Relay Client and supports opportunistic mode. 2224 Otherwise, the Control Relay Server cannot guarantee to deliver the 2225 I1 packet to the intended recipient. Future extensions of this 2226 document may allow opportunistic mode to be used with non-unique IP 2227 addresses to be utilized either as a HIP-level anycast or multicast 2228 mechanism. Both of the mentioned cases would require a separate 2229 registration parameters that the Control Relay Server proposes and 2230 the Control Client Server accepts during registration. 2232 6.3. Base Exchange Replay Protection for Control Relay Server 2234 In certain scenarios, it is possible that an attacker, or two 2235 attackers, can replay an earlier base exchange through a Control 2236 Relay Server by masquerading as the original Initiator and Responder. 2237 The attack does not require the attacker(s) to compromise the private 2238 key(s) of the attacked host(s). However, for this attack to succeed, 2239 the legitimate Responder has to be disconnected from the Control 2240 Relay Server. 2242 The Control Relay Server can protect itself against replay attacks by 2243 becoming involved in the base exchange by introducing nonces that the 2244 end-hosts (Initiator and Responder) are required to sign. One way to 2245 do this is to add ECHO_REQUEST_M parameters to the R1 and I2 packets 2246 as described in [HIP-MIDDLE] and drop the I2 or R2 packets if the 2247 corresponding ECHO_RESPONSE_M parameters are not present. 2249 6.4. Demultiplexing Different HIP Associations 2251 Section 5.1 of [RFC3948] describes a security issue for the UDP 2252 encapsulation in the standard IP tunnel mode when two hosts behind 2253 different NATs have the same private IP address and initiate 2254 communication to the same Responder in the public Internet. The 2255 Responder cannot distinguish between two hosts, because security 2256 associations are based on the same inner IP addresses. 2258 This issue does not exist with the UDP encapsulation of HIP ESP 2259 transport format because the Responder uses HITs to distinguish 2260 between different Initiators. 2262 6.5. Reuse of Ports at the Data Relay Server 2264 If the Data Relay Server uses the same relayed address and port (as 2265 conveyed in the RELAYED_ADDRESS parameter) for multiple Data Relay 2266 Clients, it appears to all the peers, and their firewalls, that all 2267 the Data Relay Clients are at the same address. Thus, a stateful 2268 firewall may allow packets pass from hosts that would not normally be 2269 able to send packets to a peer behind the firewall. Therefore, a 2270 Data Relay Server SHOULD NOT re-use the port numbers. If port 2271 numbers need to be re-used, the Data Relay Server SHOULD have a 2272 sufficiently large pool of port numbers and select ports from the 2273 pool randomly to decrease the chances of a Data Relay Client 2274 obtaining the same address that a another host behind the same 2275 firewall is using. 2277 6.6. Amplification attacks 2279 A malicious host may send an invalid list of candidates for its peer 2280 that are used for targeting a victim host by flooding it with 2281 connectivity checks. To mitigate the attack, this protocol adopts 2282 the ICE mechanism to cap the total amount of connectivity checks as 2283 defined in Section 4.7. 2285 6.7. Attacks against Connectivity Checks and Candidate Gathering 2287 [I-D.ietf-ice-rfc5245bis] describes attacks against ICE connectivity 2288 checks. HIP bases its control plane security on Diffie-Hellman key 2289 exchange, public keys and Hashed Message Authentication codes, 2290 meaning that the mentioned security concerns do not apply to HIP 2291 either. The mentioned section discusses also of man-in-the-middle 2292 replay attacks that are difficult to prevent. The connectivity 2293 checks in this protocol are immune against replay attacks because a 2294 connectivity request includes a random nonce that the recipient must 2295 sign and send back as a response. 2297 [I-D.ietf-ice-rfc5245bis] describes attacks on server reflexive 2298 address gathering. Similarly here, if the DNS, a Control Relay 2299 Server or a Data Relay Server has been compromised, not much can be 2300 done. However, the case where attacker can inject fake messages 2301 (located on a shared network segment like Wifi) does not apply here. 2302 HIP messages are integrity and replay protected, so it is not 2303 possible inject fake server reflexive address candidates. 2305 [I-D.ietf-ice-rfc5245bis] describes attacks on relayed candidate 2306 gathering. Similarly to ICE TURN servers, Data Relay Server require 2307 an authenticated base exchange that protects relayed address 2308 gathering against fake requests and responses. Further, replay 2309 attacks are not possible because the HIP base exchange (and also 2310 UPDATE procedure) is protected against replay attacks. 2312 7. IANA Considerations 2314 This section is to be interpreted according to [RFC8126]. 2316 This document reuses the same default UDP port number 10500 as 2317 specified by Legacy ICE-HIP [RFC5770] for tunneling both HIP control 2318 plane and data plane traffic. The selection between Legacy ICE-HIP 2319 and Native ICE-HIP mode is negotiated using NAT_TRAVERSAL_MODE 2320 parameter during the base exchange. By default, hosts listen this 2321 port for incoming UDP datagrams and can use it also for sending UDP 2322 datagrams. Other emphemeral port numbers are negotiated and utilized 2323 dynamically. 2325 This document updates the IANA Registry for HIP Parameter Types 2326 [RFC7401] by assigning new HIP Parameter Type values for the new HIP 2327 Parameters: RELAYED_ADDRESS (length 20), MAPPED_ADDRESS (length 20, 2328 defined in Section 5.12), PEER_PERMISSION (length 48, defined in 2329 Section 5.13), CANDIDATE_PRIORITY (length 4, defined in Section 5.14) 2330 and NOMINATE (length 4, defined in Section 5.15). 2332 This document updates the IANA Registry for HIP NAT traversal modes 2333 specified in Legacy ICE-HIP [RFC5770] by assigning value for the NAT 2334 traversal mode ICE-HIP-UDP (defined in Section 5.4). 2336 This document updates the IANA Registry for HIP Notify Message Types: 2337 type field NAT_KEEPALIVE in Section 5.3 and a new error type 2338 SERVER_REFLEXIVE_CANDIDATE_ALLOCATION_FAILED in Section 5.9. 2340 This document defines additional registration types for the HIP 2341 Registration Extension [RFC8003] that allow registering with a Data 2342 Relay Server for ESP relaying service: RELAY_UDP_ESP (defined in 2343 Section 5.9, and performing server reflexive candidate discovery: 2344 CANDIDATE_DISCOVERY (defined in Section 4.2). 2346 ICE specification [I-D.ietf-ice-rfc5245bis] discusses "Unilateral 2347 Self-Address Fixing" . This protocol is based on ICE, and thus the 2348 same considerations apply also here with one exception: this protocol 2349 does not hide binary IP addresses from application-level gateways. 2351 8. Contributors 2353 Marcelo Bagnulo, Philip Matthews and Hannes Tschofenig have 2354 contributed to [RFC5770]. This document leans heavily on the work in 2355 the RFC. 2357 9. Acknowledgments 2359 Thanks to Jonathan Rosenberg, Christer Holmberg and the rest of the 2360 MMUSIC WG folks for the excellent work on ICE. In addition, the 2361 authors would like to thank Andrei Gurtov, Simon Schuetz, Martin 2362 Stiemerling, Lars Eggert, Vivien Schmitt, and Abhinav Pathak for 2363 their contributions and Tobias Heer, Teemu Koponen, Juhana Mattila, 2364 Jeffrey M. Ahrenholz, Kristian Slavov, Janne Lindqvist, Pekka 2365 Nikander, Lauri Silvennoinen, Jukka Ylitalo, Juha Heinanen, Joakim 2366 Koskela, Samu Varjonen, Dan Wing, Tom Henderson, Alex Elsayed and 2367 Jani Hautakorpi for their comments to [RFC5770], which is the basis 2368 for this document. 2370 This work has been partially funded by CyberTrust programme by 2371 Digile/Tekes in Finland. 2373 10. References 2375 10.1. Normative References 2377 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2378 Requirement Levels", BCP 14, RFC 2119, 2379 DOI 10.17487/RFC2119, March 1997, . 2382 [RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T. 2383 Henderson, "Host Identity Protocol Version 2 (HIPv2)", 2384 RFC 7401, DOI 10.17487/RFC7401, April 2015, 2385 . 2387 [RFC8003] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) 2388 Registration Extension", RFC 8003, DOI 10.17487/RFC8003, 2389 October 2016, . 2391 [RFC8004] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) 2392 Rendezvous Extension", RFC 8004, DOI 10.17487/RFC8004, 2393 October 2016, . 2395 [RFC8046] Henderson, T., Ed., Vogt, C., and J. Arkko, "Host Mobility 2396 with the Host Identity Protocol", RFC 8046, 2397 DOI 10.17487/RFC8046, February 2017, . 2400 [RFC8047] Henderson, T., Ed., Vogt, C., and J. Arkko, "Host 2401 Multihoming with the Host Identity Protocol", RFC 8047, 2402 DOI 10.17487/RFC8047, February 2017, . 2405 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 2406 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 2407 DOI 10.17487/RFC5389, October 2008, . 2410 [RFC7402] Jokela, P., Moskowitz, R., and J. Melen, "Using the 2411 Encapsulating Security Payload (ESP) Transport Format with 2412 the Host Identity Protocol (HIP)", RFC 7402, 2413 DOI 10.17487/RFC7402, April 2015, . 2416 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 2417 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 2418 2006, . 2420 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 2421 Writing an IANA Considerations Section in RFCs", BCP 26, 2422 RFC 8126, DOI 10.17487/RFC8126, June 2017, 2423 . 2425 [I-D.ietf-ice-rfc5245bis] 2426 Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive 2427 Connectivity Establishment (ICE): A Protocol for Network 2428 Address Translator (NAT) Traversal", draft-ietf-ice- 2429 rfc5245bis-15 (work in progress), November 2017. 2431 10.2. Informative References 2433 [RFC5770] Komu, M., Henderson, T., Tschofenig, H., Melen, J., and A. 2434 Keranen, Ed., "Basic Host Identity Protocol (HIP) 2435 Extensions for Traversal of Network Address Translators", 2436 RFC 5770, DOI 10.17487/RFC5770, April 2010, 2437 . 2439 [RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol 2440 (HIP) Architecture", RFC 4423, DOI 10.17487/RFC4423, May 2441 2006, . 2443 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 2444 and W. Weiss, "An Architecture for Differentiated 2445 Services", RFC 2475, DOI 10.17487/RFC2475, December 1998, 2446 . 2448 [RFC5207] Stiemerling, M., Quittek, J., and L. Eggert, "NAT and 2449 Firewall Traversal Issues of Host Identity Protocol (HIP) 2450 Communication", RFC 5207, DOI 10.17487/RFC5207, April 2451 2008, . 2453 [RFC6538] Henderson, T. and A. Gurtov, "The Host Identity Protocol 2454 (HIP) Experiment Report", RFC 6538, DOI 10.17487/RFC6538, 2455 March 2012, . 2457 [MMUSIC-ICE] 2458 Rosenberg, J., "Guidelines for Usage of Interactive 2459 Connectivity Establishment (ICE) by non Session Initiation 2460 Protocol (SIP) Protocols", Work in Progress, July 2008. 2462 [RFC5128] Srisuresh, P., Ford, B., and D. Kegel, "State of Peer-to- 2463 Peer (P2P) Communication across Network Address 2464 Translators (NATs)", RFC 5128, DOI 10.17487/RFC5128, March 2465 2008, . 2467 [HIP-MIDDLE] 2468 Heer, T., Wehrle, K., and M. Komu, "End-Host 2469 Authentication for HIP Middleboxes", Work in Progress, 2470 February 2009. 2472 [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. 2473 Stenberg, "UDP Encapsulation of IPsec ESP Packets", 2474 RFC 3948, DOI 10.17487/RFC3948, January 2005, 2475 . 2477 Appendix A. Selecting a Value for Check Pacing 2479 Selecting a suitable value for the connectivity check transaction 2480 pacing is essential for the performance of connectivity check-based 2481 NAT traversal. The value should not be so small that the checks 2482 cause network congestion or overwhelm the NATs. On the other hand, a 2483 pacing value that is too high makes the checks last for a long time, 2484 thus increasing the connection setup delay. 2486 The Ta value may be configured by the user in environments where the 2487 network characteristics are known beforehand. However, if the 2488 characteristics are not known, it is recommended that the value is 2489 adjusted dynamically. In this case, it is recommended that the hosts 2490 estimate the round-trip time (RTT) between them and set the minimum 2491 Ta value so that only two connectivity check messages are sent on 2492 every RTT. 2494 One way to estimate the RTT is to use the time that it takes for the 2495 Control Relay Server registration exchange to complete; this would 2496 give an estimate on the registering host's access link's RTT. Also, 2497 the I1/R1 exchange could be used for estimating the RTT, but since 2498 the R1 can be cached in the network, or the relaying service can 2499 increase the delay notably, this is not recommended. 2501 Appendix B. Differences with respect to ICE 2503 Legacy ICE-HIP reuses ICE/STUN/TURN protocol stack as it is. The 2504 benefits of such as an approach include the reuse of STUN/TURN 2505 infrastructure and possibly the reuse of existing software libraries, 2506 but there are also drawbacks with the approach. For example, ICE is 2507 meant for application-layer protocols, whereas HIP operates at layer 2508 3.5 between transport and network layers. This is particularly 2509 problematic because the implementations employ IPsec ESP as their 2510 data plane: demultiplexing of incoming ESP, HIP and TURN messages 2511 required capturing of all UDP packets destined to port 10500 to the 2512 userspace, thus causing additional software complexity and an 2513 unnecessary latency/throughput bottleneck for the dataplane 2514 performance. Also, relaying of ESP packets via TURN relays was not 2515 considered that simple because TURN relays require adding and 2516 removing extra TURN framing for the relayed packets. Finally, the 2517 developers of the two Legacy ICE-HIP implementations concluded that 2518 "effort needed for integrating an ICE library into a HIP 2519 implementation turned out to be quite a bit higher that initially 2520 estimated. Also, the amount of extra code (some 10 kLoC) needed for 2521 all the new parsers, state machines, etc., is quite high and by re- 2522 using the HIP code one should be able to do with much less. This 2523 should result in smaller binary size, less bugs, and easier 2524 debugging.". Consequently, the HIP working group decided to follow 2525 ICE methodology but reuse HIP messaging format to achieve the same 2526 functionality as ICE, and consequently the result is this document 2527 that specifies the Native ICE-HIP protocol. 2529 The Native ICE-HIP protocol specified in this document follows the 2530 semantics of ICE as close as possible, and most of the differences 2531 are syntactical due to the use of a different protocol. In this 2532 section, we describe the differences to the ICE protocol. 2534 o ICE operates at the application layer, whereas this protocol 2535 operates between transport and network layers, thus hiding the 2536 protocol details from the application. 2538 o The STUN protocol is not employed. Instead, native ICE-HIP reuses 2539 the HIP control plane format in order simplify demultiplexing of 2540 different protocols. For example, the STUN binding response is 2541 replaced with a HIP UPDATE message containing an 2542 ECHO_REQUEST_SIGNED parameter and the STUN binding response with a 2543 HIP UPDATE message containing an ECHO_RESPONSE_SIGNED parameter as 2544 defined in Section 4.6. 2546 o The TURN protocol is not utilized. Instead, native ICE-HIP reuses 2547 Control Relay Servers for the same purpose. 2549 o ICMP errors may be used in ICE to signal failure. In Native ICE- 2550 HIP protocol, HIP NOTIFY messages are used instead. 2552 o Instead of the ICE username fragment and password mechanism for 2553 credentials, native ICE-HIP uses the HIT, derived from a public 2554 key, for the same purpose. The username fragments are "transient 2555 host identifiers, bound to a particular session established as 2556 part of the candidate exchange" [I-D.ietf-ice-rfc5245bis]. 2557 Generally in HIP, a local public key and the derived HIT are 2558 considered long-term identifiers, and invariant across different 2559 host associations and different transport-layer flows. 2561 o In ICE, the conflict when two communicating end-points take the 2562 same controlling role is solved using random values (so called 2563 tie-breaker value). In Native ICE-HIP protocol, the conflict is 2564 solved by the standard HIP base exchange procedure, where the host 2565 with the "larger" HIT switches to Responder role, thus changing 2566 also to controlled role. 2568 o The ICE-CONTROLLED and ICE-CONTROLLING attributes are not included 2569 in the connectivity checks. 2571 o The foundation concept is unnecessary in native ICE-HIP because 2572 only a single UDP flow for the IPsec tunnel will be negotiated. 2574 o Frozen candidates are omitted for the same reason as foundation 2575 concept is excluded. 2577 o Components are omitted for the same reason as foundation concept 2578 is excluded. 2580 o Native ICE-HIP supports only "full ICE" where the two 2581 communicating hosts participate actively to the connectivity 2582 checks, and the "lite" mode is not supported. This design 2583 decision follows the guidelines of ICE which recommends full ICE 2584 implementations. However, it should be noted that a publicly 2585 reachable Responder may refuse to negotiate the ICE mode as 2586 described in Section 4.7.2. This would result in a [RFC7401] 2587 based HIP base exchange tunneled over UDP followed ESP traffic 2588 over the same tunnel, without the connectivity check procedures 2589 defined in this document (in some sense, this mode corresponds to 2590 the case where two ICE lite implementations connect since no 2591 connectivity checks are sent). 2593 o As the "ICE lite" is not adopted here and both sides are capable 2594 of ICE-HIP-UDP mode (negotiated during the base exchange), default 2595 candidates are not employed in Native ICE-HIP. 2597 o If the agent is using Diffserv Codepoint markings [RFC2475] in its 2598 media packets, it SHOULD apply those same markings to its 2599 connectivity checks. 2601 o Unlike in ICE, the addresses are not XOR-ed in Native ICE-HIP 2602 protocol in order to avoid middlebox tampering. 2604 o Native ICE-HIP protocol does not employ the ICE related address 2605 and related port attributes (that are used for diagnostic or SIP 2606 purposes). 2608 Appendix C. Differences to Base Exchange and UPDATE procedures 2610 This section gives some design guidance for implementers how the 2611 extensions in this protocol extend and differ from [RFC7401] and 2612 [RFC8046]. 2614 o Both control and data plane are operated on top of UDP, not 2615 directly on IP. 2617 o A minimal implementation would conform only to Section 4.7.1 or 2618 Section 4.7.2, thus merely tunneling HIP control and data traffic 2619 over UDP. The drawback here is that it works only in the limited 2620 cases where the Responder has a public address. 2622 o It is worth noting that while a rendezvous server [RFC8004] has 2623 not been designed to be used in NATted scenarios because it just 2624 relays the first I1 packet and does not employ UDP encapsulation, 2625 the Control Relay Server forwards all control traffic and, hence, 2626 is more suitable in NATted environments. Further, the Data Relay 2627 Server guarantees forwarding of data plane traffic also in the 2628 cases when the NAT traversal procedures fail. 2630 o Registration procedures with a Control/Data Relay Server are 2631 similar as with rendezvous server. However, a Control/Data Relay 2632 Server has different registration parameters than rendezvous 2633 because it offers a different service. Also, the Control/Data 2634 Relay Server includes also a REG_FROM parameter that informs the 2635 Control/Data Relay Client about its server reflexive address. A 2636 Data Relay Server includes also a RELAYED_ADDRESS containing the 2637 relayed address for the Data Relay Client. 2639 o In [RFC7401], the Initiator and Responder can start to exchange 2640 application payload immediately after the base exchange. While 2641 exchanging data immediately after a base exchange via a Data 2642 Control Relay would be possible also here, we follow the ICE 2643 methodology to establish a direct path between two hosts using 2644 connectivity checks. This means that there will be some 2645 additional delay after the base exchange before application 2646 payload can be transmitted. The same applies for the UPDATE 2647 procedure as the connectivity checks introduce some additional 2648 delay. 2650 o In HIP without any NAT traversal support, the base exchange acts 2651 as an implicit connectivity check, and the mobility and 2652 multihoming extensions support explicit connectivity checks. 2653 After a base exchange or UPDATE based connectivity checks, a host 2654 can use the associated address pair for transmitting application 2655 payload. In this Native ICE-HIP extension, we follow the ICE 2656 methodology, where one end-point acting in the controlled role 2657 chooses the used address pair also on behalf of the other end- 2658 point acting in controlled role, which is different from HIP 2659 without NAT traversal support. Another difference is that the 2660 process of choosing an address pair is explicitly signaled using 2661 the nomination packets. The nomination process in this protocol 2662 supports only single address pair, and multihoming extensions are 2663 left for further study. 2665 o The UPDATE procedure resembles the mobility extensions defined in 2666 [RFC8046]. The first UPDATE message from the mobile host is 2667 exactly the same as in the mobility extensions. The second UPDATE 2668 message from the peer host and third from the mobile host are 2669 different in the sense that they merely acknowledge and conclude 2670 the reception of the candidates through the Control Relay Server. 2671 In other words, they do not yet test for connectivity (besides 2672 reachability through the Control Relay Server) unlike in the 2673 mobility extensions. The idea is that connectivity check 2674 procedure follows the ICE specification, which is somewhat 2675 different from the HIP mobility extensions. 2677 o The connectivity checks as defined in the mobility extensions 2678 [RFC8046] are triggered only by the peer of the mobile host. 2679 Since successful NAT traversal requires that both end-points test 2680 connectivity, both the mobile host and its peer host have to test 2681 for connectivity. In addition, this protocol validates also the 2682 UDP ports; the ports in the connectivity check must match with the 2683 response, as required by ICE. 2685 o In HIP mobility extensions [RFC8046], an outbound locator has some 2686 associated state: UNVERIFIED mean that the locator has not been 2687 tested for reachability, ACTIVE means that the address has been 2688 verified for reachability and is being used actively, and 2689 DEPRECATED means that the locator lifetime has expired. In the 2690 subset of ICE specifications used by this protocol, an individual 2691 address candidate has only two properties: type and priority. 2692 Instead, the actual state in ICE is associated with candidate 2693 pairs rather than individual addresses. The subset of ICE 2694 specifications utilized by this protocol require the following 2695 attributes for a candidate pair: valid bit, nominated bit, base 2696 and the state of connectivity check. The connectivity checks have 2697 the following states: Waiting, In-progress, Succeeded and Failed. 2698 Handling of this state attribute requires some additional logic 2699 when compared to the mobility extensions since the state is 2700 associated with a local-remote address pair rather just a remote 2701 address, and, thus, the mobility and ICE states do not have an 2702 unambiguous one-to-one mapping. 2704 o Credit-based authorization as defined in [RFC8046] could be used 2705 before candidate nomination has been concluded upon discovering 2706 working candidate pairs. However, this may result in the use of 2707 asymmetric paths for a short time period in the beginning of 2708 communications (similarly as in aggressive ICE nomination). Thus, 2709 support of credit-based authorization is left for further study. 2711 Appendix D. Multihoming Considerations 2713 This document allows a host to collect address candidates from 2714 multiple interfaces, but does not support activation and the 2715 simultaneous use of multiple address candidates. While multihoming 2716 extensions to support [RFC8047] like functionality are left for 2717 further study and experimentation, we envision here some potential 2718 compatibility improvements to support multihoming: 2720 o Data Relay Registration: a Data Relay Client acting as an 2721 Initiator with another peer host should register a new server 2722 reflexive candidate for each local transport address candidate. A 2723 Data Relay Client acting as an Responder should register a new 2724 server reflexive candidate for each { local transport address 2725 candidate, new peer host} pair for the reasons described in 2726 Section 4.12.3. In both cases, the Data Relay Client should 2727 request the additional server reflexive candidates by sending 2728 UPDATE messages originating from each of the local address 2729 candidates as described in Section 4.1. As the UPDATE messages 2730 are originating from an unknown location from the viewpoint of the 2731 Data Relay Server, it must include also a ECHO_REQUEST_SIGNED in 2732 the response in order to test for return routability. 2734 o Data Relay unregistration: this follows the procedure in Section 4 2735 but the Data Relay Client should unregister using the particular 2736 transport address to be unregistered. All transport address pair 2737 registrations can be unregistered when no RELAYED_ADDRESS 2738 parameter is included. 2740 o PEER_PERMISSION parameter: this needs to be extended or an 2741 additional parameter is needed to declare the specific local 2742 candidate of the Data Relay Client. Alternatively, the use of the 2743 PEER_PERMISSION could be used as a wild card to open permissions 2744 for a specific peer to all of the candidates of the Data Relay 2745 Client. 2747 o Connectivity checks: the controlling host should be able to 2748 nominate multiple candidates (by repeating step 7 in Figure 5 in 2749 Section 4.6 using the additional candidate pairs). 2751 o Keepalives should be sent for all the nominated candidate pairs. 2752 Similarly, the Control/Data Relay Client should send keepalives 2753 from its local candidates to its Control/Data Relay Server 2754 transport addresses. 2756 Authors' Addresses 2758 Ari Keranen 2759 Ericsson 2760 Hirsalantie 11 2761 02420 Jorvas 2762 Finland 2764 Email: ari.keranen@ericsson.com 2765 Jan Melen 2766 Ericsson 2767 Hirsalantie 11 2768 02420 Jorvas 2769 Finland 2771 Email: jan.melen@ericsson.com 2773 Miika Komu (editor) 2774 Ericsson 2775 Hirsalantie 11 2776 02420 Jorvas 2777 Finland 2779 Email: miika.komu@ericsson.com