idnits 2.17.1 draft-ietf-hip-native-nat-traversal-33.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 1882 has weird spacing: '...eserved zero...' == Line 1924 has weird spacing: '... Min Ta the ...' == Line 1955 has weird spacing: '...eserved rese...' == Line 1957 has weird spacing: '...Address an ...' == Line 2172 has weird spacing: '...eserved reser...' == (5 more instances...) -- The document date (August 3, 2020) is 1361 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 5389 (Obsoleted by RFC 8489) ** Obsolete normative reference: RFC 1063 (Obsoleted by RFC 1191) == Outdated reference: A later version (-17) exists of draft-ietf-tcpm-rto-consider-16 -- Obsolete informational reference (is this intentional?): RFC 5245 (Obsoleted by RFC 8445, RFC 8839) -- Obsolete informational reference (is this intentional?): RFC 5766 (Obsoleted by RFC 8656) Summary: 2 errors (**), 0 flaws (~~), 8 warnings (==), 3 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: Experimental M. Komu, Ed. 5 Expires: February 4, 2021 Ericsson 6 August 3, 2020 8 Native NAT Traversal Mode for the Host Identity Protocol 9 draft-ietf-hip-native-nat-traversal-33 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 instead of ICE for all NAT traversal procedures due to the 19 kernel-space dependencies of HIP. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on February 4, 2021. 38 Copyright Notice 40 Copyright (c) 2020 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (https://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 57 3. Overview of Operation . . . . . . . . . . . . . . . . . . . . 8 58 4. Protocol Description . . . . . . . . . . . . . . . . . . . . 10 59 4.1. Relay Registration . . . . . . . . . . . . . . . . . . . 10 60 4.2. Transport Address Candidate Gathering at the Relay Client 13 61 4.3. NAT Traversal Mode Negotiation . . . . . . . . . . . . . 16 62 4.4. Connectivity Check Pacing Negotiation . . . . . . . . . . 17 63 4.5. Base Exchange via Control Relay Server . . . . . . . . . 17 64 4.6. Connectivity Checks . . . . . . . . . . . . . . . . . . . 20 65 4.6.1. Connectivity Check Procedure . . . . . . . . . . . . 21 66 4.6.2. Rules for Connectivity Checks . . . . . . . . . . . . 24 67 4.6.3. Rules for Concluding Connectivity Checks . . . . . . 26 68 4.7. NAT Traversal Optimizations . . . . . . . . . . . . . . . 27 69 4.7.1. Minimal NAT Traversal Support . . . . . . . . . . . . 27 70 4.7.2. Base Exchange without Connectivity Checks . . . . . . 27 71 4.7.3. Initiating a Base Exchange both with and without UDP 72 Encapsulation . . . . . . . . . . . . . . . . . . . . 29 73 4.8. Sending Control Packets after the Base Exchange . . . . . 29 74 4.9. Mobility Handover Procedure . . . . . . . . . . . . . . . 30 75 4.10. NAT Keepalives . . . . . . . . . . . . . . . . . . . . . 34 76 4.11. Closing Procedure . . . . . . . . . . . . . . . . . . . . 35 77 4.12. Relaying Considerations . . . . . . . . . . . . . . . . . 35 78 4.12.1. Forwarding Rules and Permissions . . . . . . . . . . 35 79 4.12.2. HIP Data Relay and Relaying of Control Packets . . . 36 80 4.12.3. Handling Conflicting SPI Values . . . . . . . . . . 37 81 5. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 38 82 5.1. HIP Control Packets . . . . . . . . . . . . . . . . . . . 38 83 5.2. Connectivity Checks . . . . . . . . . . . . . . . . . . . 40 84 5.3. Keepalives . . . . . . . . . . . . . . . . . . . . . . . 40 85 5.4. NAT Traversal Mode Parameter . . . . . . . . . . . . . . 40 86 5.5. Connectivity Check Transaction Pacing Parameter . . . . . 41 87 5.6. Relay and Registration Parameters . . . . . . . . . . . . 42 88 5.7. LOCATOR_SET Parameter . . . . . . . . . . . . . . . . . . 43 89 5.8. RELAY_HMAC Parameter . . . . . . . . . . . . . . . . . . 45 90 5.9. Registration Types . . . . . . . . . . . . . . . . . . . 45 91 5.10. Notify Packet Types . . . . . . . . . . . . . . . . . . . 45 92 5.11. ESP Data Packets . . . . . . . . . . . . . . . . . . . . 46 93 5.12. RELAYED_ADDRESS and MAPPED_ADDRESS Parameters . . . . . . 46 94 5.13. PEER_PERMISSION Parameter . . . . . . . . . . . . . . . . 47 95 5.14. HIP Connectivity Check Packets . . . . . . . . . . . . . 48 96 5.15. NOMINATE parameter . . . . . . . . . . . . . . . . . . . 49 98 6. Security Considerations . . . . . . . . . . . . . . . . . . . 49 99 6.1. Privacy Considerations . . . . . . . . . . . . . . . . . 50 100 6.2. Opportunistic Mode . . . . . . . . . . . . . . . . . . . 50 101 6.3. Base Exchange Replay Protection for Control Relay Server 50 102 6.4. Demultiplexing Different HIP Associations . . . . . . . . 51 103 6.5. Reuse of Ports at the Data Relay Server . . . . . . . . . 51 104 6.6. Amplification attacks . . . . . . . . . . . . . . . . . . 51 105 6.7. Attacks against Connectivity Checks and Candidate 106 Gathering . . . . . . . . . . . . . . . . . . . . . . . . 52 107 6.8. Cross-Protocol Attacks . . . . . . . . . . . . . . . . . 52 108 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 53 109 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 54 110 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 54 111 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 55 112 10.1. Normative References . . . . . . . . . . . . . . . . . . 55 113 10.2. Informative References . . . . . . . . . . . . . . . . . 57 114 Appendix A. Selecting a Value for Check Pacing . . . . . . . . . 59 115 Appendix B. Differences with respect to ICE . . . . . . . . . . 59 116 Appendix C. Differences to Base Exchange and UPDATE procedures . 62 117 Appendix D. Multihoming Considerations . . . . . . . . . . . . . 64 118 Appendix E. DNS Considerations . . . . . . . . . . . . . . . . . 65 119 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 66 121 1. Introduction 123 The Host Identity Protocol (HIP) [RFC7401] is specified to run 124 directly on top of IPv4 or IPv6. However, many middleboxes found in 125 the Internet, such as NATs and firewalls, often allow only UDP or TCP 126 traffic to pass [RFC5207]. Also, NATs usually require the host 127 behind a NAT to create a forwarding state in the NAT before other 128 hosts outside of the NAT can contact the host behind the NAT. To 129 overcome this problem, different methods, commonly referred to as NAT 130 traversal techniques, have been developed. 132 As one solution, the HIP experiment report [RFC6538] mentions Teredo- 133 based NAT traversal for HIP and related ESP traffic (with double 134 tunneling overhead). Another solution is specified in [RFC5770], 135 which will be referred to as "Legacy ICE-HIP" in this document. The 136 experimental Legacy ICE-HIP specification combines Interactive 137 Connectivity Establishment (ICE) protocol [RFC5245] with HIP, so that 138 basically ICE is responsible for NAT traversal and connectivity 139 testing, while HIP is responsible for end-host authentication and 140 IPsec key management. The resulting protocol uses HIP, STUN and ESP 141 messages tunneled over a single UDP flow. The benefit of using ICE 142 and its STUN/TURN messaging formats is that one can re-use the NAT 143 traversal infrastructure already available in the Internet, such as 144 STUN and TURN servers. Also, some middleboxes may be STUN-aware and 145 may be able to do something "smart" when they see STUN being used for 146 NAT traversal. 148 HIP poses a unique challenge to using standard ICE, due not only to 149 kernel-space dependencies of HIP, but also due to its close 150 integration with kernel-space IPSec; and, that while [RFC5770] 151 provides a technically workable path, it incurs unacceptable 152 performance drawbacks for kernel-space implementations. Also, 153 implementing and integrating a full ICE/STUN/TURN protocol stack as 154 specified in Legacy ICE-HIP results in a considerable amount of 155 effort and code which could be avoided by re-using and extending HIP 156 messages and state machines for the same purpose. Thus, this 157 document specifies an alternative NAT traversal mode referred as 158 "Native ICE-HIP" that employs HIP messaging format instead of STUN or 159 TURN for the connectivity checks, keepalives and data relaying. 160 Native ICE-HIP also specifies how mobility management works in the 161 context of NAT traversal, which is missing from the Legacy ICE-HIP 162 specification. The native specification is also based on HIPv2, 163 whereas legacy specification is based on HIPv1. The differences to 164 the Legacy ICE-HIP are further elaborated in Appendix B. 166 Similarly as Legacy ICE-HIP, also this specification builds on the 167 HIP registration extensions [RFC8003] and the base exchange procedure 168 [RFC7401] and its closing procedures, so the reader is recommended to 169 get familiar with the relevant specifications. In a nutshell, the 170 registration extensions allow a HIP Initiator (usually a "client" 171 host) to ask for specific services from a HIP Responder (usually a 172 "server" host). The registration parameters are included in a base 173 exchange, which is essentially a four-way Diffie-Hellman key exchange 174 authenticated using the public keys of the end-hosts. When the hosts 175 negotiate support for ESP [RFC7402] during the base exchange, they 176 can deliver ESP protected application payload to each other. When 177 either of the hosts moves and changes its IP address, the two hosts 178 re-establish connectivity using the mobility extensions [RFC8046]. 179 The reader is also recommended to get familiar with the mobility 180 extensions, but basically it is a three-way procedure, where the 181 mobile host first announces its new location to the peer, and then 182 the peer tests for connectivity (so called return routability check), 183 for which the mobile hosts must respond in order to activate its new 184 location. This specification builds on the mobility procedures, but 185 modifies it to be compatible with ICE. The differences to the 186 mobility extensions specified in Appendix C. It is worth noting that 187 multihoming support as specified in [RFC8047] is left for further 188 study. 190 This specification builds heavily on the ICE methodology, so it is 191 recommended that the reader is familiar with the ICE specification 192 [RFC8445] (especially the overview). However, native ICE-HIP does 193 not implement all the features in ICE, and, hence, the different 194 features of ICE are cross referenced using [RFC2119] terminology for 195 clarity. Appendix B explains the differences to ICE, and it is 196 recommended that the reader would read also this section in addition 197 to the ICE specification. 199 2. Terminology 201 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 202 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 203 "OPTIONAL" in this document are to be interpreted as described in BCP 204 14 [RFC2119] [RFC8174] when, and only when, they appear in all 205 capitals, as shown here. 207 This document borrows terminology from [RFC5770], [RFC7401], 208 [RFC8046], [I-D.ietf-hip-rfc4423-bis], [RFC8445], and [RFC5389]. The 209 following terms recur in the text: 211 ICE: 212 Interactive Connectivity Establishment (ICE) protocol as specified 213 in [RFC8445] 215 Legacy ICE-HIP: 216 Refers to the "Basic Host Identity Protocol (HIP) Extensions for 217 Traversal of Network Address Translators" as specified in 218 [RFC5770]. The protocol specified in this document offers an 219 alternative to Legacy ICE-HIP. 221 Native ICE-HIP: 222 The protocol specified in this document (Native NAT Traversal Mode 223 for HIP). 225 Initiator: 226 The Initiator is the host that initiates the base exchange using 227 I1 message [RFC7401]. 229 Responder: 230 The Responder is the host that receives the I1 packet from the 231 Initiator [RFC7401]. 233 Control Relay Server 234 A registrar host that forwards any kind of HIP control plane 235 packets between the Initiator and the Responder. This host is 236 critical because it relays the locators between the Initiator and 237 the Responder, so that they can try to establish a direct 238 communication path with each other. This host is used to replace 239 HIP rendezvous servers [RFC8004] for hosts operating in private 240 address realms. In the Legacy ICE-HIP specification [RFC5770], 241 this host is denoted as "HIP Relay Server". 243 Control Relay Client: 244 A requester host that registers to a Control Relay Server 245 requesting it to forward control-plane traffic (i.e. HIP control 246 messages). In the Legacy ICE-HIP specification [RFC5770], this is 247 denoted as "HIP Relay Client". 249 Data Relay Server: 250 A new entity introduced in this document; a registrar host that 251 forwards HIP related data plane packets, such as Encapsulating 252 Security Payload (ESP) [RFC7402], between two hosts. This host 253 implements similar functionality as TURN servers. 255 Data Relay Client: 256 A requester host that registers to a Data Relay Server requesting 257 it to forward data-plane traffic (e.g. ESP traffic). This 258 functionality is a new and introduced in this document. 260 Locator: 261 As defined in [RFC8046]: "A name that controls how the packet is 262 routed through the network and demultiplexed by the end-host. It 263 may include a concatenation of traditional network addresses such 264 as an IPv6 address and end-to-end identifiers such as an ESP 265 Security Parameter Index (SPI). It may also include transport 266 port numbers or IPv6 Flow Labels as demultiplexing context, or it 267 may simply be a network address." 269 LOCATOR_SET (written in capital letters): 270 Denotes a HIP control packet parameter that bundles multiple 271 locators together [RFC8046]. 273 HIP offer: 274 Before two end-hosts can establish a communication channel using 275 the NAT traversal procedures defined in this document, they need 276 exchange their locators (i.e. candidates) with each other. In 277 ICE, this procedure is called Candidate Exchange and it does not 278 specify how the candidates are exchanged but Session Description 279 Protocol (SDP) "offer/answer" is mentioned as an example. In 280 contrast, the Candidate Exchange in HIP is the base exchange 281 itself or a subsequent UPDATE prodecure occurring after a 282 handover. Following [RFC5770] and SDP related naming conventions 283 [RFC3264], "HIP offer" is the the Initiator's LOCATOR_SET 284 parameter in a HIP I2 or in an UPDATE control packet. 286 HIP answer: 287 The Responder's LOCATOR_SET parameter in a HIP R2 or UPDATE 288 control packet. Corresponds to the SDP answer parameter 289 [RFC3264], but is HIP specific. Please refer also to the longer 290 description of the "HIP offer" term above. 292 HIP connectivity checks: 293 In order to obtain a direct end-to-end communication path (without 294 employing a Data Relay Server), two communicating HIP hosts try to 295 "punch holes" through their NAT boxes using this mechanism. It is 296 similar to the ICE connectivity checks, but implemented using HIP 297 return routability checks. 299 Controlling host: 300 The controlling host [RFC8445] is always the Initiator in the 301 context of this specification. It nominates the candidate pair to 302 be used with the controlled host. 304 Controlled host: 305 The controlled host [RFC8445] is always the Responder in the 306 context of this specification. It waits for the controlling to 307 nominate an address candidate pair. 309 Checklist: 310 A list of address candidate pairs that need to be tested for 311 connectivity (same as in [RFC8445]). 313 Transport address: 314 Transport layer port and the corresponding IPv4/v6 address (same 315 as in [RFC8445]). 317 Candidate: 318 A transport address that is a potential point of contact for 319 receiving data (same as in [RFC8445]). 321 Host candidate: 322 A candidate obtained by binding to a specific port from an IP 323 address on the host (same as in [RFC8445]). 325 Server reflexive candidate: 326 A translated transport address of a host as observed by a Control 327 or Data Relay Server (same as in [RFC8445]). 329 Peer reflexive candidate: 330 A translated transport address of a host as observed by its peer 331 (same as in [RFC8445]). 333 Relayed candidate: 335 A transport address that exists on a Data Relay Server. Packets 336 that arrive at this address are relayed towards the Data Relay 337 Client. The concept is the same as in [RFC8445], but a Data Relay 338 Server is used instead of a TURN server. 340 Permission: 341 In the context of Data Relay Server, permission refers to a 342 concept similar to TURN's ([RFC5766]) channels. Before a host can 343 use a relayed candidate to forward traffic through a Data Relay 344 Server, the host must activate the relayed candidate with a 345 specific peer host. 347 Base: 348 Similarly as in [RFC8445], the base of a candidate is the local 349 source address a host uses to send packets for the associated 350 candidate. For example, the base of a server reflexive address is 351 the local address the host used for registering itself to the 352 associated Control or Data Relay Server. The base of a host 353 candidate is equal to the host candidate itself. 355 3. Overview of Operation 357 +--------------+ 358 | Control | 359 +--------+ | Relay Server | +--------+ 360 | Data | +----+-----+---+ | Data | 361 | Relay | / \ | Relay | 362 | Server | / \ | Server | 363 +--------+ / \ +--------+ 364 / \ 365 / \ 366 / \ 367 / <- Signaling -> \ 368 / \ 369 +-------+ +-------+ 370 | NAT | | NAT | 371 +-------+ +-------+ 372 / \ 373 / \ 374 +-------+ +-------+ 375 | Init- | | Resp- | 376 | iator | | onder | 377 +-------+ +-------+ 379 Figure 1: Example Network Configuration 381 In the example configuration depicted in Figure 1, both Initiator and 382 Responder are behind one or more NATs, and both private networks are 383 connected to the public Internet. To be contacted from behind a NAT, 384 at least the Responder must be registered with a Control Relay Server 385 reachable on the public Internet. The Responder may have also 386 registered to a Data Relay Server that can forward the data plane in 387 case NAT traversal fails. While, strictly speaking, the Initiator 388 does not need a Data Relay Server, it may act in the other role with 389 other hosts, and connectivity with the Data Relay Server of the 390 Responder may fail, so the Initiator may also need to register to a 391 Cotrol and/or Data Relay Server. It is worth noting that a Control 392 and Data Relay does not forge the source address of a passing packet, 393 but always translates the source address and source port of a packet 394 to be forwarded (to its own). 396 We assume, as a starting point, that the Initiator knows both the 397 Responder's Host Identity Tag (HIT) and the address(es) of the 398 Responder's Control Relay Server(s) (how the Initiator learns of the 399 Responder's Control Relay Server is outside of the scope of this 400 document, but may be through DNS or another name service). The first 401 steps are for both the Initiator and Responder to register with a 402 Control Relay Server (need not be the same one) and gather a set of 403 address candidates. The hosts use either Control Relay Servers or 404 Data Relay Servers for gathering the candidates. Next, the HIP base 405 exchange is carried out by encapsulating the HIP control packets in 406 UDP datagrams and sending them through the Responder's Control Relay 407 Server. As part of the base exchange, each HIP host learns of the 408 peer's candidate addresses through the HIP offer/answer procedure 409 embedded in the base exchange. 411 Once the base exchange is completed, two HIP hosts have established a 412 working communication session (for signaling) via a Control Relay 413 Server, but the hosts still have to find a better path, preferably 414 without a Data Relay Server, for the ESP data flow. For this, 415 connectivity checks are carried out until a working pair of addresses 416 is discovered. At the end of the procedure, if successful, the hosts 417 will have established a UDP-based tunnel that traverses both NATs, 418 with the data flowing directly from NAT to NAT or via a Data Relay 419 Server. At this point, also the HIP signaling can be sent over the 420 same address/port pair, and is demultiplexed (or, in other words, 421 separated) from IPsec as described in the UDP encapsulation standard 422 for IPsec [RFC3948]. Finally, the two hosts send NAT keepalives as 423 needed in order keep their UDP-tunnel state active in the associated 424 NAT boxes. 426 If either one of the hosts knows that it is not behind a NAT, hosts 427 can negotiate during the base exchange a different mode of NAT 428 traversal that does not use HIP connectivity checks, but only UDP 429 encapsulation of HIP and ESP. Also, it is possible for the Initiator 430 to simultaneously try a base exchange with and without UDP 431 encapsulation. If a base exchange without UDP encapsulation 432 succeeds, no HIP connectivity checks or UDP encapsulation of ESP are 433 needed. 435 4. Protocol Description 437 This section describes the normative behavior of the "Native ICE-HIP" 438 protocol extension. Most of the procedures are similar to what is 439 defined in [RFC5770] but with different, or additional, parameter 440 types and values. In addition, a new type of relaying server, Data 441 Relay Server, is specified. Also, it should be noted that HIP 442 version 2 [RFC7401] MUST be used instead of HIPv1 with this NAT 443 traversal mode. 445 4.1. Relay Registration 447 In order for two hosts to communicate over NATted environments, they 448 need a reliable way to exchange information. To achieve this, "HIP 449 Relay Server" is defined in [RFC5770]. It supports relaying of HIP 450 control plane traffic over UDP in NATted environments, and forwards 451 HIP control packets between the Initiator and the Responder. In this 452 document, the HIP Relay Server is denoted as "Control Relay Server" 453 for better alignment with the rest of the terminology. The 454 registration to the Control Relay Server can be achieved using 455 RELAY_UDP_HIP parameter as explained later in this section. 457 To guarantee also data plane delivery over varying types of NAT 458 devices, a host MAY also register for UDP encapsulated ESP relaying 459 using Registration Type RELAY_UDP_ESP (value [TBD by IANA: 3]). This 460 service may be coupled with the Control Relay Server or offered 461 separately on another server. If the server supports relaying of UDP 462 encapsulated ESP, the host is allowed to register for a data relaying 463 service using the registration extensions in Section 3.3 of 464 [RFC8003]). If the server has sufficient relaying resources (free 465 port numbers, bandwidth, etc.) available, it opens a UDP port on one 466 of its addresses and signals the address and port to the registering 467 host using the RELAYED_ADDRESS parameter (as defined in Section 5.12 468 in this document). If the Data Relay Server would accept the data 469 relaying request but does not currently have enough resources to 470 provide data relaying service, it MUST reject the request with 471 Failure Type "Insufficient resources" [RFC8003]. 473 The registration process follows the generic registration extensions 474 defined in [RFC8003]. The HIP control plane relaying registration 475 follows [RFC5770], but the data plane registration is different. It 476 is worth noting that if the HIP control and data plane relay services 477 reside on different hosts, the client has to register separately to 478 each of them. In the example shown in Figure 2, the two services are 479 coupled on a single host. The text uses "Relay Client" and "Relay 480 Server" as a shorthand when the procedures apply both to control and 481 data cases. 483 Control/Data Control/Data 484 Relay Client (Initiator) Relay Server (Responder) 485 | 1. UDP(I1) | 486 +---------------------------------------------------------------->| 487 | | 488 | 2. UDP(R1(REG_INFO(RELAY_UDP_HIP,[RELAY_UDP_ESP]))) | 489 |<----------------------------------------------------------------+ 490 | | 491 | 3. UDP(I2(REG_REQ(RELAY_UDP_HIP),[RELAY_UDP_ESP])) | 492 +---------------------------------------------------------------->| 493 | | 494 | 4. UDP(R2(REG_RES(RELAY_UDP_HIP,[RELAY_UDP_ESP]), REG_FROM, | 495 | [RELAYED_ADDRESS])) | 496 |<----------------------------------------------------------------+ 497 | | 499 Figure 2: Example Registration with a HIP Relay 501 In step 1, the Relay Client (Initiator) starts the registration 502 procedure by sending an I1 packet over UDP to the Relay Server. It 503 is RECOMMENDED that the Relay Client select a random source port 504 number from the ephemeral port range 49152-65535 for initiating a 505 base exchange. Alternatively, a host MAY also use a single fixed 506 port for initiating all outgoing connections. However, the allocated 507 port MUST be maintained until all of the corresponding HIP 508 Associations are closed. It is RECOMMENDED that the Relay Server 509 listen to incoming connections at UDP port 10500. If some other port 510 number is used, it needs to be known by potential Relay Clients. 512 In step 2, the Relay Server (Responder) lists the services that it 513 supports in the R1 packet. The support for HIP control plane over 514 UDP relaying is denoted by the Registration Type value RELAY_UDP_HIP 515 (see Section 5.9). If the server supports also relaying of ESP 516 traffic over UDP, it includes also Registration type value 517 RELAY_UDP_ESP. 519 In step 3, the Relay Client selects the services for which it 520 registers and lists them in the REG_REQ parameter. The Relay Client 521 registers for the Control Relay service by listing the RELAY_UDP_HIP 522 value in the request parameter. If the Relay Client requires also 523 ESP relaying over UDP, it lists also RELAY_UDP_ESP. 525 In step 4, the Relay Server concludes the registration procedure with 526 an R2 packet and acknowledges the registered services in the REG_RES 527 parameter. The Relay Server denotes unsuccessful registrations (if 528 any) in the REG_FAILED parameter of R2. The Relay Server also 529 includes a REG_FROM parameter that contains the transport address of 530 the Relay Client as observed by the Relay Server (Server Reflexive 531 candidate). If the Relay Client registered to ESP relaying service, 532 the Relay Server includes RELAYED_ADDRESS parameter that describes 533 the UDP port allocated to the Relay Client for ESP relaying. It is 534 worth noting that the Data Relay Client must first activate this UDP 535 port by sending an UPDATE message to the Data Relay Server that 536 includes a PEER_PERMISSION parameter as described in Section 4.12.1 537 both after base exchange and handover procedures. Also, the Data 538 Relay Server should follow the port allocation recommendations in 539 Section 6.5. 541 After the registration, the Relay Client sends periodically NAT 542 keepalives to the Relay Server in order to keep the NAT bindings 543 between the Relay Client and the relay alive. The keepalive 544 extensions are described in Section 4.10. 546 The Data Relay Client MUST maintain an active HIP association with 547 the Data Relay Server as long as it requires the data relaying 548 service. When the HIP association is closed (or times out), or the 549 registration lifetime passes without the Data Relay Client refreshing 550 the registration, the Data Relay Server MUST stop relaying packets 551 for that host and close the corresponding UDP port (unless other Data 552 Relay Clients are still using it). 554 The Data Relay Server SHOULD offer a different relayed address and 555 port for each Data Relay Client because not doing so can cause 556 problems with stateful firewalls (see Section 6.5). 558 When a Control Relay Client sends an UPDATE (e.g., due to host 559 movement or to renew service registration), the Control Relay Server 560 MUST follow the general guidelines defined in [RFC8003], with the 561 difference that all UPDATE messages are delivered on top of UDP. In 562 addition to this, the Control Relay Server MUST include the REG_FROM 563 parameter in all UPDATE responses sent to the Control Relay Client. 564 This applies to both renewals of service registration and to host 565 movement. It is especially important for the case of host movement, 566 as this is the mechanism that allows the Control Relay Client to 567 learn its new server reflexive address candidate. 569 A Data Relay Client can request multiple relayed candidates from the 570 Data Relay Server (e.g., for the reasons described in 571 Section 4.12.3). After the base exchange with registration, the Data 572 Relay Client can request additional relayed candidates similarly as 573 during the base exchange. The Data Relay Client sends an UPDATE 574 message REG_REQ parameter requesting for the RELAY_UDP_ESP service. 575 The UPDATE message MUST also include a SEQ and a ECHO_REQUEST_SIGNED 576 parameter. The Data Relay Server MUST respond with an UPDATE message 577 that includes the corresponding response parameters: REG_RES, ACK and 578 ECHO_REQUEST_SIGNED . In case the Data Relay Server allocated a new 579 relayed UDP port for the Data Relay Client, the REG_RES parameter 580 MUST list RELAY_UDP_ESP as a service and the UPDATE message MUST also 581 include a RELAYED_ADDRESS parameter describing the relayed UDP port. 582 The Data Relay Server MUST also include the Server Reflexive 583 candidate in a REG_FROM parameter. It is worth mentioning that Data 584 Relay Client MUST activate the UDP port as described in 585 Section 4.12.1 before it can be used for any ESP relaying. 587 A Data Relay Client may unregister a relayed candidate in two ways. 588 It can wait for its lifetime to expire or it can explicitly request 589 it with zero lifetime using the UPDATE mechanism. The Data Relay 590 Client can send an REG_REQ parameter with zero lifetime to the Data 591 Relay Server in order to expire all relayed candidates. To expire a 592 specific relayed candidate, the Data Relay Client MUST also include 593 RELAYED_ADDRESS parameter as sent by the server in the UPDATE 594 message. Upon closing the HIP association (CLOSE-CLOSE-ACK procedure 595 initiated by either party), the Data Relay Server MUST also expire 596 all relayed candidates. 598 Please also refer to Section 6.8 for protection against cross- 599 protocol attacks for both Control Relay Client and Server. 601 4.2. Transport Address Candidate Gathering at the Relay Client 603 An Initiator needs to gather a set of address candidates before 604 contacting a (non-relay) Responder. The candidates are needed for 605 connectivity checks that allow two hosts to discover a direct, non- 606 relayed path for communicating with each other. One server reflexive 607 candidate can be discovered during the registration with the Control 608 Relay Server from the REG_FROM parameter (and another from Data Relay 609 Server if one is employed). 611 The candidate gathering can be done at any time, but it needs to be 612 done before sending an I2 or R2 in the base exchange if ICE-HIP-UDP 613 mode is to be used for the connectivity checks. It is RECOMMENDED 614 that all three types of candidates (host, server reflexive, and 615 relayed) are gathered to maximize the probability of successful NAT 616 traversal. However, if no Data Relay Server is used, and the host 617 has only a single local IP address to use, the host MAY use the local 618 address as the only host candidate and the address from the REG_FROM 619 parameter discovered during the Control Relay Server registration as 620 a server reflexive candidate. In this case, no further candidate 621 gathering is needed. 623 A Data Relay Client MAY register only a single relayed candidate that 624 it uses with multiple other peers. However, it is RECOMMENDED that a 625 Data Relay Client registers a new server relayed candidate for each 626 of its peer for the reasons described in Section 4.12.3. The 627 procedures for registering multiple relayed candidates are described 628 in Section 4.1. 630 If a Relay Client has more than one network interface, it can 631 discover additional server reflexive candidates by sending UPDATE 632 messages from each of its interfaces to the Relay Server. Each such 633 UPDATE message MUST include the following parameters: registration 634 request (REG_REQ) parameter with Registration Type 635 CANDIDATE_DISCOVERY (value [TBD by IANA: 4]) and ECHO_REQUEST_SIGNED 636 parameter. When a Control Relay Server receives an UPDATE message 637 with registration request containing a CANDIDATE_DISCOVERY type, it 638 MUST include a REG_FROM parameter, containing the same information as 639 if this were a Control Relay Server registration, to the response (in 640 addition to the mandatory ECHO_RESPONSE_SIGNED parameter). This 641 request type SHOULD NOT create any state at the Control Relay Server. 643 The rules in section 5.1.1 in [RFC8445] for candidate gathering are 644 followed here. A number of host candidates (loopback, anycast and 645 others) should be excluded as described in section 5.1.1.1 of the ICE 646 specification [RFC8445]. Relayed candidates SHOULD be gathered in 647 order to guarantee successful NAT traversal, and implementations 648 SHOULD support this functionality even if it will not be used in 649 deployments in order to enable it by software configuration update if 650 needed at some point. Similarly as explained in section 5.1.1.2 of 651 the ICE specification [RFC8445], if an IPv6-only host is in a network 652 that utilizes NAT64 [RFC6146] and DNS64 [RFC6147] technologies, it 653 may also gather IPv4 server- reflexive and/or relayed candidates from 654 IPv4-only Control or Data Relay Servers. IPv6-only hosts SHOULD also 655 utilize IPv6 prefix discovery [RFC7050] to discover the IPv6 prefix 656 used by NAT64 (if any) and generate server-reflexive candidates for 657 each IPv6-only interface, accordingly. The NAT64 server-reflexive 658 candidates are prioritized like IPv4 server-reflexive candidates. 660 HIP based connectivity can be utilized by IPv4 applications using 661 Local Scope Identifiers (LSIs) and by IPv6 based applications using 662 HITs. The LSIs and HITs of the local virtual interfaces MUST be 663 excluded in the candidate gathering phase as well to avoid creating 664 unnecessary loopback connectivity tests. 666 Gathering of candidates MAY also be performed by other means than 667 described in this section. For example, the candidates could be 668 gathered as specified in Section 4.2 of [RFC5770] if STUN servers are 669 available, or if the host has just a single interface and no STUN or 670 Data Relay Server are available. 672 Each local address candidate MUST be assigned a priority. The 673 following recommended formula (as described in [RFC8445]) SHOULD be 674 used: 676 priority = (2^24)*(type preference) + (2^8)*(local preference) + 677 (2^0)*(256 - component ID) 679 In the formula, the type preference follows the ICE specification (as 680 defined in section 5.1.2.1 in [RFC8445]): the RECOMMENDED values are 681 126 for host candidates, 100 for server reflexive candidates, 110 for 682 peer reflexive candidates, and 0 for relayed candidates. The highest 683 value is 126 (the most preferred) and lowest is 0 (last resort). For 684 all candidates of the same type, the preference type value MUST be 685 identical, and, correspondingly, the value MUST be different for 686 different types. For peer reflexive values, the type preference 687 value MUST be higher than for server reflexive types. It should be 688 noted that peer reflexive values are learned later during 689 connectivity checks, so a host cannot employ it during candidate 690 gathering stage yet. 692 Following the ICE specification, the local preference MUST be an 693 integer from 0 (lowest preference) to 65535 (highest preference) 694 inclusive. In the case the host has only a single address candidate, 695 the value SHOULD be 65535. In the case of multiple candidates, each 696 local preference value MUST be unique. Dual-stack considerations for 697 IPv6 apply also here as defined in [RFC8445] in section 5.1.2.2. 699 Unlike with SDP used in conjunction with ICE, this protocol only 700 creates a single UDP flow between the two communicating hosts, so 701 only a single component exists. Hence, the component ID value MUST 702 always be set to 1. 704 As defined in section 14.3 in [RFC8445], the retransmission timeout 705 (RTO) for address gathering from a Control/Data Relay Server SHOULD 706 be calculated as follows: 708 RTO = MAX (1000ms, Ta * (Num-Of-Cands)) 710 where Ta is the value used for the connectivity check pacing and Num- 711 Of-Cands is the number of server-reflexive and relay candidates. A 712 smaller value than 1000 ms for the RTO MUST NOT be used. 714 4.3. NAT Traversal Mode Negotiation 716 This section describes the usage of a non-critical parameter type 717 called NAT_TRAVERSAL_MODE with a new mode called ICE-HIP-UDP. The 718 presence of the new mode in the NAT_TRAVERSAL_MODE parameter in a HIP 719 base exchange means that the end-host supports NAT traversal 720 extensions described in this document. As the parameter is non- 721 critical (as defined in Section 5.2.1 of [RFC7401]), it can be 722 ignored by a end-host, which means that the host is not required to 723 support it or may decline to use it. 725 With registration with a Control/Data Relay Server, it is usually 726 sufficient to use the UDP-ENCAPSULATION mode of NAT traversal since 727 the Relay Server is assumed to be in public address space. Thus, the 728 Relay Server SHOULD propose the UDP-ENCAPSULATION mode as the 729 preferred or only mode. The NAT traversal mode negotiation in a HIP 730 base exchange is illustrated in Figure 3. It is worth noting that 731 the Relay Server could be located between the hosts, but is omitted 732 here for simplicity. 734 Initiator Responder 735 | 1. UDP(I1) | 736 +----------------------------------------------------------------->| 737 | | 738 | 2. UDP(R1(.., NAT_TRAVERSAL_MODE(ICE-HIP-UDP), ..)) | 739 |<-----------------------------------------------------------------+ 740 | | 741 | 3. UDP(I2(.., NAT_TRAVERSAL_MODE(ICE-HIP-UDP), ENC(LOC_SET), ..))| 742 +----------------------------------------------------------------->| 743 | | 744 | 4. UDP(R2(.., ENC(LOC_SET), ..)) | 745 |<-----------------------------------------------------------------+ 746 | | 748 Figure 3: Negotiation of NAT Traversal Mode 750 In step 1, the Initiator sends an I1 to the Responder. In step 2, 751 the Responder responds with an R1. As specified in [RFC5770], the 752 NAT_TRAVERSAL_MODE parameter in R1 contains a list of NAT traversal 753 modes the Responder supports. The mode specified in this document is 754 ICE-HIP-UDP (value [TBD by IANA: 3]). 756 In step 3, the Initiator sends an I2 that includes a 757 NAT_TRAVERSAL_MODE parameter. It contains the mode selected by the 758 Initiator from the list of modes offered by the Responder. If ICE- 759 HIP-UDP mode was selected, the I2 also includes the "Transport 760 address" locators (as defined in Section 5.7) of the Initiator in a 761 LOCATOR_SET parameter (denoted here with LOC_SET). With ICE-HIP-UDP 762 mode, the LOCATOR_SET parameter MUST be encapsulated within an 763 ENCRYPTED parameter (denoted here with ENC) according to the 764 procedures in sections 5.2.18 and 6.5 in [RFC7401]. The locators in 765 I2 are the "HIP offer". 767 In step 4, the Responder concludes the base exchange with an R2 768 packet. If the Initiator chose ICE-HIP-UDP traversal mode, the 769 Responder includes a LOCATOR_SET parameter in the R2 packet. With 770 ICE-HIP-UDP mode, the LOCATOR_SET parameter MUST be encapsulated 771 within an ENCRYPTED parameter according to the procedures in sections 772 5.2.18 and 6.5 in [RFC7401]. The locators in R2, encoded like the 773 locators in I2, are the "ICE answer". If the NAT traversal mode 774 selected by the Initiator is not supported by the Responder, the 775 Responder SHOULD reply with a NOTIFY packet with type 776 NO_VALID_NAT_TRAVERSAL_MODE_PARAMETER and abort the base exchange. 778 4.4. Connectivity Check Pacing Negotiation 780 As explained in Legacy ICE-HIP [RFC5770], when a NAT traversal mode 781 with connectivity checks is used, new transactions should not be 782 started too fast to avoid congestion and overwhelming the NATs. For 783 this purpose, during the base exchange, hosts can negotiate a 784 transaction pacing value, Ta, using a TRANSACTION_PACING parameter in 785 R1 and I2 packets. The parameter contains the minimum time 786 (expressed in milliseconds) the host would wait between two NAT 787 traversal transactions, such as starting a new connectivity check or 788 retrying a previous check. The value that is used by both of the 789 hosts is the higher of the two offered values. 791 The minimum Ta value SHOULD be configurable, and if no value is 792 configured, a value of 50 ms MUST be used. Guidelines for selecting 793 a Ta value are given in Appendix A. Hosts MUST NOT use values 794 smaller than 5 ms for the minimum Ta, since such values may not work 795 well with some NATs (as explained in [RFC8445]). The Initiator MUST 796 NOT propose a smaller value than what the Responder offered. If a 797 host does not include the TRANSACTION_PACING parameter in the base 798 exchange, a Ta value of 50 ms MUST be used as that host's minimum 799 value. 801 4.5. Base Exchange via Control Relay Server 803 This section describes how the Initiator and Responder perform a base 804 exchange through a Control Relay Server. Connectivity pacing 805 (denoted as TA_P here) was described in Section 4.4 and is not 806 repeated here. Similarly, the NAT traversal mode negotiation process 807 (denoted as NAT_TM in the example) was described in Section 4.3 and 808 is also not repeated here. If a Control Relay Server receives an R1 809 or I2 packet without the NAT traversal mode parameter, it MUST drop 810 it and SHOULD send a NOTIFY error packet with type 811 NO_VALID_NAT_TRAVERSAL_MODE_PARAMETER to the sender of the R1 or I2. 813 It is RECOMMENDED that the Initiator send an I1 packet encapsulated 814 in UDP when it is destined to an IP address of the Responder. 815 Respectively, the Responder MUST respond to such an I1 packet with a 816 UDP-encapsulated R1 packet, and also the rest of the communication 817 related to the HIP association MUST also use UDP encapsulation. 819 Figure 4 illustrates a base exchange via a Control Relay Server. We 820 assume that the Responder (i.e. a Control Relay Client) has already 821 registered to the Control Relay Server. The Initiator may have also 822 registered to another (or the same Control Relay Server), but the 823 base exchange will traverse always through the Control Relay Server 824 of the Responder. 826 Initiator Control Relay Server Responder 827 | 1. UDP(I1) | | 828 +--------------------------------->| 2. UDP(I1(RELAY_FROM)) | 829 | +------------------------------->| 830 | | | 831 | | 3. UDP(R1(RELAY_TO, NAT_TM, | 832 | | TA_P)) | 833 | 4. UDP(R1(RELAY_TO, NAT_TM, |<-------------------------------+ 834 | TA_P)) | | 835 |<---------------------------------+ | 836 | | | 837 | 5. UDP(I2(ENC(LOC_SET)), | | 838 | NAT_TM, TA_P)) | | 839 +--------------------------------->| 6. UDP(I2(ENC(LOC_SET), | 840 | | RELAY_FROM, NAT_TM, TA_P))| 841 | +------------------------------->| 842 | | | 843 | | 7. UDP(R2(ENC(LOC_SET), | 844 | 8. UDP(R2(ENC(LOC_SET), | RELAY_TO)) | 845 | RELAY_TO)) |<-------------------------------+ 846 |<---------------------------------+ | 847 | | | 849 Figure 4: Base Exchange via a HIP Relay Server 851 In step 1 of Figure 4, the Initiator sends an I1 packet over UDP via 852 the Control Relay Server to the Responder. In the HIP header, the 853 source HIT belongs to the Initiator and the destination HIT to the 854 Responder. The initiator sends the I1 packet from its IP address to 855 the IP address of the Control Relay Server over UDP. 857 In step 2, the Control Relay Server receives the I1 packet. If the 858 destination HIT belongs to a successfully registered Control Relay 859 Client (i.e., the host marked "Responder" in Figure 4), the Control 860 Relay Server processes the packet. Otherwise, the Control Relay 861 Server MUST drop the packet silently. The Control Relay Server 862 appends a RELAY_FROM parameter to the I1 packet, which contains the 863 transport source address and port of the I1 as observed by the 864 Control Relay Server. The Control Relay Server protects the I1 865 packet with RELAY_HMAC, except that the parameter type is different 866 as described in Section 5.8. The Control Relay Server changes the 867 source and destination ports and IP addresses of the packet to match 868 the values the Responder used when registering to the Control Relay 869 Server, i.e., the reverse of the R2 used in the registration. The 870 Control Relay Server MUST recalculate the transport checksum and 871 forward the packet to the Responder. 873 In step 3, the Responder receives the I1 packet. The Responder 874 processes it according to the rules in [RFC7401]. In addition, the 875 Responder validates the RELAY_HMAC according to Section 5.8 and 876 silently drops the packet if the validation fails. The Responder 877 replies with an R1 packet to which it includes RELAY_TO and NAT 878 traversal mode parameters. The responder MUST include ICE-HIP-UDP in 879 the NAT traversal modes. The RELAY_TO parameter MUST contain the 880 same information as the RELAY_FROM parameter, i.e., the Initiator's 881 transport address, but the type of the parameter is different. The 882 RELAY_TO parameter is not integrity protected by the signature of the 883 R1 to allow pre-created R1 packets at the Responder. 885 In step 4, the Control Relay Server receives the R1 packet. The 886 Control Relay Server drops the packet silently if the source HIT 887 belongs to a Control Relay Client that has not successfully 888 registered. The Control Relay Server MAY verify the signature of the 889 R1 packet and drop it if the signature is invalid. Otherwise, the 890 Control Relay Server rewrites the source address and port, and 891 changes the destination address and port to match RELAY_TO 892 information. Finally, the Control Relay Server recalculates the 893 transport checksum and forwards the packet. 895 In step 5, the Initiator receives the R1 packet and processes it 896 according to [RFC7401]. The Initiator MAY use the address in the 897 RELAY_TO parameter as a local peer-reflexive candidate for this HIP 898 association if it is different from all known local candidates. The 899 Initiator replies with an I2 packet that uses the destination 900 transport address of R1 as the source address and port. The I2 901 packet contains a LOCATOR_SET parameter inside an ENCRYPTED parameter 902 that lists all the HIP candidates (HIP offer) of the Initiator. The 903 candidates are encoded using the format defined in Section 5.7. The 904 I2 packet MUST also contain a NAT traversal mode parameter that 905 includes ICE-HIP-UDP mode. The ENCRYPTED parameter along with its 906 key material generation are described in detail in sections 5.2.18 907 and 6.5 in [RFC7401]. 909 In step 6, the Control Relay Server receives the I2 packet. The 910 Control Relay Server appends a RELAY_FROM and a RELAY_HMAC to the I2 911 packet similarly as explained in step 2, and forwards the packet to 912 the Responder. 914 In step 7, the Responder receives the I2 packet and processes it 915 according to [RFC7401]. The Responder validates the RELAY_HMAC 916 according to Section 5.8 and silently drops the packet if the 917 validation fails. It replies with an R2 packet and includes a 918 RELAY_TO parameter as explained in step 3. The R2 packet includes a 919 LOCATOR_SET parameter inside an ENCRYPTED parameter that lists all 920 the HIP candidates (ICE answer) of the Responder. The RELAY_TO 921 parameter is protected by the HMAC. The ENCRYPTED parameter along 922 with its key material generation are described in detail in sections 923 5.2.18 and 6.5 in [RFC7401]. 925 In step 8, the Control Relay Server processes the R2 as described in 926 step 4. The Control Relay Server forwards the packet to the 927 Initiator. After the Initiator has received the R2 and processed it 928 successfully, the base exchange is completed. 930 Hosts MUST include the address of one or more Control Relay Servers 931 (including the one that is being used for the initial signaling) in 932 the LOCATOR_SET parameter in I2 and R2 messages if they intend to use 933 such servers for relaying HIP signaling immediately after the base 934 exchange completes. The traffic type of these addresses MUST be "HIP 935 signaling" (see Section 5.7) and they MUST NOT be used for the 936 connectivity tests described in Section 4.6. If the Control Relay 937 Server locator used for relaying the base exchange is not included in 938 I2 or R2 LOCATOR_SET parameters, it SHOULD NOT be used after the base 939 exchange. Instead, further HIP signaling SHOULD use the same path as 940 the data traffic. It is RECOMMENDED to use the same Control Relay 941 Server throughout the lifetime of the host association that was used 942 for forwarding the base exchange if the Responder includes it in the 943 locator parameter of the R2 message. 945 4.6. Connectivity Checks 947 When the Initiator and Responder complete the base exchange through 948 the Control Relay Server, both of them employ the IP address of the 949 Control Relay Server as the destination address for the packets. The 950 address of the Control Relay Server MUST NOT be used as a destination 951 for data plane traffic unless the server supports also Data Relay 952 Server functionality, and the Client has successfully registered to 953 use it. When NAT traversal mode with ICE-HIP-UDP was successfully 954 negotiated and selected, the Initiator and Responder MUST start the 955 connectivity checks in order to attempt to obtain direct end-to-end 956 connectivity through NAT devices. It is worth noting that the 957 connectivity checks MUST be completed even though no ESP_TRANSFORM 958 would be negotiated and selected. 960 The connectivity checks follow the ICE methodology 961 [I-D.rosenberg-mmusic-ice-nonsip], but UDP encapsulated HIP control 962 messages are used instead of ICE messages. As stated in the ICE 963 specification, the basic procedure for connectivity checks has three 964 phases: sorting the candidate pairs according their priority, sending 965 checks in the prioritized order and acknowledging the checks from the 966 peer host. 968 The Initiator MUST take the role of controlling host and the 969 Responder acts as the controlled host. The roles MUST persist 970 throughout the HIP associate lifetime (to be reused in the possibly 971 mobility UPDATE procedures). In the case both communicating nodes 972 are initiating the communications to each other using an I1 packet, 973 the conflict is resolved as defined in section 6.7 in [RFC7401]: the 974 host with the "larger" HIT changes to its Role to Responder. In such 975 a case, the host changing its role to Responder MUST also switch to 976 controlled role. 978 The protocol follows standard HIP UPDATE sending and processing rules 979 as defined in section 6.11 and 6.12 in [RFC7401], but some new 980 parameters are introduced (CANDIDATE_PRIORITY, MAPPED_ADDRESS and 981 NOMINATE). 983 4.6.1. Connectivity Check Procedure 985 Figure 5 illustrates connectivity checks in a simplified scenario, 986 where the Initiator and Responder have only a single candidate pair 987 to check. Typically, NATs drop messages until both sides have sent 988 messages using the same port pair. In this scenario, the Responder 989 sends a connectivity check first but the NAT of the Initiator drops 990 it. However, the connectivity check from the Initiator reaches the 991 Responder because it uses the same port pair as the first message. 992 It is worth noting that the message flow in this section is 993 idealistic, and, in practice, more messages would be dropped, 994 especially in the beginning. For instance, connectivity tests always 995 start with the candidates with the highest priority, which would be 996 host candidates (which would not reach the recipient in this 997 scenario). 999 Initiator NAT1 NAT2 Responder 1000 | | 1. UDP(UPDATE(SEQ, CAND_PRIO, | | 1001 | | ECHO_REQ_SIGN)) | | 1002 | X<-----------------------------------+----------------+ 1003 | | | | 1004 | 2. UDP(UPDATE(SEQ, ECHO_REQ_SIGN, CAND_PRIO)) | | 1005 +-------------+------------------------------------+--------------->| 1006 | | | | 1007 | 3. UDP(UPDATE(ACK, ECHO_RESP_SIGN, MAPPED_ADDR)) | | 1008 |<------------+------------------------------------+----------------+ 1009 | | | | 1010 | 4. UDP(UPDATE(SEQ, ECHO_REQ_SIGN, CAND_PRIO)) | | 1011 |<------------+------------------------------------+----------------+ 1012 | | | | 1013 | 5. UDP(UPDATE(ACK, ECHO_RESP_SIGN, MAPPED_ADDR)) | | 1014 +-------------+------------------------------------+--------------->| 1015 | | | | 1016 | 6. Other connectivity checks using UPDATE over UDP | 1017 |<------------+------------------------------------+----------------> 1018 | | | | 1019 | 7. UDP(UPDATE(SEQ, ECHO_REQ_SIGN, CAND_PRIO, NOMINATE)) | 1020 +-------------+------------------------------------+--------------->| 1021 | | | | 1022 | 8. UDP(UPDATE(SEQ, ACK, ECHO_REQ_SIGN, ECHO_RESP_SIGN, | 1023 | NOMINATE)) | | 1024 |<------------+------------------------------------+----------------+ 1025 | | | | 1026 | 9. UDP(UPDATE(ACK, ECHO_RESP_SIGN)) | | 1027 +-------------+------------------------------------+--------------->+ 1028 | | | | 1029 | 10. ESP data traffic over UDP | | 1030 +<------------+------------------------------------+--------------->+ 1031 | | | | 1033 Figure 5: Connectivity Checks 1035 In step 1, the Responder sends a connectivity check to the Initiator 1036 that the NAT of the Initiator drops. The message includes a number 1037 of parameters. As specified in [RFC7401]), the SEQ parameter 1038 includes a running sequence identifier for the connectivity check. 1039 The candidate priority (denoted "CAND_PRIO" in the figure) describes 1040 the priority of the address candidate being tested. The 1041 ECHO_REQUEST_SIGNED (denoted ECHO_REQ_SIGN in the figure) includes a 1042 nonce that the recipient must sign and echo back as it is. 1044 In step 2, the Initiator sends a connectivity check, using the same 1045 address pair candidate as in the previous step, and the message 1046 traverses successfully the NAT boxes. The message includes the same 1047 parameters as in the previous step. It should be noted that the 1048 sequence identifier is locally assigned by the Initiator, so it can 1049 be different than in the previous step. 1051 In step 3, the Responder has successfully received the previous 1052 connectivity check from the Initiator and starts to build a response 1053 message. Since the message from the Initiator included a SEQ, the 1054 Responder must acknowledge it using an ACK parameter. Also, the 1055 nonce contained in the echo request must be echoed back in an 1056 ECHO_RESPONSE_SIGNED (denoted ECHO_RESP_SIGN) parameter. The 1057 Responder includes also a MAPPED_ADDRESS parameter (denoted 1058 MAPPED_ADDR in the figure) that contains the transport address of the 1059 Initiator as observed by the Responder (i.e. peer reflexive 1060 candidate). This message is successfully delivered to the Initiator, 1061 and upon reception the Initiator marks the candidate pair as valid. 1063 In step 4, the Responder retransmits the connectivity check sent in 1064 the first step, since it was not acknowledged yet. 1066 In step 5, the Initiator responds to the previous connectivity check 1067 message from the Responder. The Initiator acknowledges the SEQ 1068 parameter from the previous message using ACK parameter and the 1069 ECHO_REQUEST_SIGNED parameter with ECHO_RESPONSE_SIGNED. In 1070 addition, it includes MAPPED_ADDR parameter that includes the peer 1071 reflexive candidate. This response message is successfully delivered 1072 to the Responder, and upon reception the Initiator marks the 1073 candidate pair as valid. 1075 In step 6, despite the two hosts now having valid address candidates, 1076 the hosts still test the remaining address candidates in a similar 1077 way as in the previous steps. It should be noted that each 1078 connectivity check has a unique sequence number in the SEQ parameter. 1080 In step 7, the Initiator has completed testing all address candidates 1081 and nominates one address candidate to be used. It sends an UPDATE 1082 message using the selected address candidates that includes a number 1083 of parameters: SEQ, ECHO_REQUEST_SIGNED, CANDIDATE_PRIORITY and the 1084 NOMINATE parameter. 1086 In step 8, the Responder receives the message with NOMINATE parameter 1087 from the Initiator. It sends a response that includes the NOMINATE 1088 parameter in addition to a number of other parameters. The ACK and 1089 ECHO_RESPONSE_SIGNED parameters acknowledge the SEQ and 1090 ECHO_REQUEST_SIGNED parameters from previous message from the 1091 Initiator. The Responder includes SEQ and ECHO_REQUEST_SIGNED 1092 parameters in order to receive an acknowledgment from the Responder. 1094 In step 9, the Initiator completes the candidate nomination process 1095 by confirming the message reception to the Responder. In the 1096 confirmation message, the ACK and ECHO_RESPONSE_SIGNED parameters 1097 correspond to the SEQ and ECHO_REQUEST_SIGNED parameters in the 1098 message sent by the Responder in the previous step. 1100 In step 10, the Initiator and Responder can start sending application 1101 payload over the successfully nominated address candidates. 1103 It is worth noting that if either host has registered a relayed 1104 address candidate from a Data Relay Server, the host MUST activate 1105 the address before connectivity checks by sending an UPDATE message 1106 containing PEER_PERMISSION parameter as described in Section 4.12.1. 1107 Otherwise, the Data Relay Server drops ESP packets using the relayed 1108 address. 1110 It should be noted that in the case both Initiator and Responder both 1111 advertising their own relayed address candidates, it is possible that 1112 the two hosts choose the two relayed addresses as a result of the ICE 1113 nomination algorithm. While this is possible (and even could be 1114 desirable for privacy reasons), it can be unlikely due to low 1115 priority assigned for the relayed address candidates. In such a 1116 event, the nominated address pair is always symmetric; the nomination 1117 algorithm prevents asymmetric address pairs (i.e. each side choosing 1118 different pair), such as a Data Relay Client using its own Data Relay 1119 Server to send data directly to its peer while receiving data from 1120 the Data Relay Server of its peer. 1122 4.6.2. Rules for Connectivity Checks 1124 The HITs of the two communicating hosts MUST be used as credentials 1125 in this protocol (in contrast to ICE which employs username-password 1126 fragments). A HIT pair uniquely identifies the corresponding HIT 1127 association, and a SEQ number in an UPDATE message identifies a 1128 particular connectivity check. 1130 All of the connectivity check messages MUST be protected with 1131 HIP_HMAC and signatures (even though the illustrations in this 1132 specification omit them for simplicity) according to [RFC7401]. Each 1133 connectivity check sent by a host MUST include a SEQ parameter and 1134 ECHO_REQUEST_SIGNED parameter, and correspondingly the peer MUST 1135 respond to these using ACK and ECHO_RESPONSE_SIGNED according to the 1136 rules specified in [RFC7401]. 1138 The host sending a connectivity check MUST validate that the response 1139 uses the same pair of UDP ports, and drop the packet if this is not 1140 the case. 1142 A host may receive a connectivity check before it has received the 1143 candidates from its peer. In such a case, the host MUST immediately 1144 queue a response by placing it in the triggered-check queue, and then 1145 continue waiting for the candidates. A host MUST NOT select a 1146 candidate pair until it has verified the pair using a connectivity 1147 check as defined in Section 4.6.1. 1149 [RFC7401] section 5.3.5 states that UPDATE packets have to include 1150 either a SEQ or ACK parameter (but can include both). In the 1151 connectivity check procedure specified in Section 4.6.1, each SEQ 1152 parameter should be acknowledged separately. In the context of NATs, 1153 this means that some of the SEQ parameters sent in connectivity 1154 checks will be lost or arrive out of order. From the viewpoint of 1155 the recipient, this is not a problem since the recipient will just 1156 "blindly" acknowledge the SEQ. However, the sender needs to be 1157 prepared for lost sequence identifiers and ACKs parameters that 1158 arrive out of order. 1160 As specified in [RFC7401], an ACK parameter may acknowledge multiple 1161 sequence identifiers. While the examples in the previous sections do 1162 not illustrate such functionality, it is also permitted when 1163 employing ICE-HIP-UDP mode. 1165 In ICE-HIP-UDP mode, a retransmission of a connectivity check SHOULD 1166 be sent with the same sequence identifier in the SEQ parameter. Some 1167 tested address candidates will never produce a working address pair, 1168 and thus may cause retransmissions. Upon successful nomination of an 1169 address pair, a host SHOULD immediately stop sending such 1170 retransmissions. 1172 Full ICE procedures for prioritizing candidates, eliminating 1173 redundant candidates, forming check lists (including pruning) and 1174 triggered check-queues MUST be followed as specified in section 6.1 1175 [RFC8445], with the exception of that the foundation, frozen 1176 candidates and default candidates are not used. From viewpoint of 1177 the ICE specification [RFC8445], the protocol specified in this 1178 document operates using Component ID of 1 on all candidates, and the 1179 foundation of all candidates is unique. This specification defines 1180 only "full ICE" mode, and the "lite ICE" is not supported. The 1181 reasoning behind the missing features is described in Appendix B. 1183 The connectivity check messages MUST be paced by the Ta value 1184 negotiated during the base exchange as described in Section 4.4. If 1185 neither one of the hosts announced a minimum pacing value, a value of 1186 50 ms MUST be used. 1188 Both hosts MUST form a priority ordered checklist and begin to check 1189 transactions every Ta milliseconds as long as the checks are running 1190 and there are candidate pairs whose tests have not started. The 1191 retransmission timeout (RTO) for the connectivity check UPDATE 1192 packets SHOULD be calculated as follows: 1194 RTO = MAX (1000ms, Ta * (Num-Waiting + Num-In-Progress)) 1196 In the RTO formula, Ta is the value used for the connectivity check 1197 pacing, Num-Waiting is the number of pairs in the checklist in the 1198 "Waiting" state, and Num-In-Progress is the number of pairs in the 1199 "In-Progress" state. This is identical to the formula in [RFC8445] 1200 when there is only one checklist. A smaller value than 1000 ms for 1201 the RTO MUST NOT be used. 1203 Each connectivity check request packet MUST contain a 1204 CANDIDATE_PRIORITY parameter (see Section 5.14) with the priority 1205 value that would be assigned to a peer reflexive candidate if one was 1206 learned from the corresponding check. An UPDATE packet that 1207 acknowledges a connectivity check request MUST be sent from the same 1208 address that received the check and delivered to the same address 1209 where the check was received from. Each acknowledgment UPDATE packet 1210 MUST contain a MAPPED_ADDRESS parameter with the port, protocol, and 1211 IP address of the address where the connectivity check request was 1212 received from. 1214 Following the ICE guidelines [RFC8445], it is RECOMMENDED to restrict 1215 the total number of connectivity checks to 100 for each host 1216 association. This can be achieved by limiting the connectivity 1217 checks to the 100 candidate pairs with the highest priority. 1219 4.6.3. Rules for Concluding Connectivity Checks 1221 The controlling agent may find multiple working candidate pairs. To 1222 conclude the connectivity checks, it SHOULD nominate the pair with 1223 the highest priority. The controlling agent MUST nominate a 1224 candidate pair essentially by repeating a connectivity check using an 1225 UPDATE message that contains a SEQ parameter (with new sequence 1226 number), a ECHO_REQUEST_SIGNED parameter, the priority of the 1227 candidate in a CANDIDATE_PRIORITY parameter and NOMINATE parameter to 1228 signify conclusion of the connectivity checks. Since the nominated 1229 address pair has already been tested for reachability, the controlled 1230 host should be able to receive the message. Upon reception, the 1231 controlled host SHOULD select the nominated address pair. The 1232 response message MUST include a SEQ parameter with a new sequence id, 1233 acknowledgment of the sequence from the controlling host in an ACK 1234 parameter, a new ECHO_REQUEST_SIGNED parameter, ECHO_RESPONSE_SIGNED 1235 parameter corresponding to the ECHO_REQUEST_SIGNED parameter from the 1236 controlling host and the NOMINATE parameter. After sending this 1237 packet, the controlled host can create IPsec security associations 1238 using the nominated address candidate for delivering application 1239 payload to the controlling host. Since the message from the 1240 controlled host included a new sequence id and echo request for 1241 signature, the controlling host MUST acknowledge this with a new 1242 UPDATE message that includes an ACK and ECHO_RESPONSE_SIGNED 1243 parameters. After this final concluding message, the controlling 1244 host also can create IPsec security associations for delivering 1245 application payload to the controlled host. 1247 It is possible that packets are delayed by the network. Both hosts 1248 MUST continue to respond to any connectivity checks despite an 1249 address pair having been nominated. 1251 If all the connectivity checks have failed, the hosts MUST NOT send 1252 ESP traffic to each other but MAY continue communicating using HIP 1253 packets and the locators used for the base exchange. Also, the hosts 1254 SHOULD notify each other about the failure with a 1255 CONNECTIVITY_CHECKS_FAILED NOTIFY packet (see Section 5.10). 1257 4.7. NAT Traversal Optimizations 1259 4.7.1. Minimal NAT Traversal Support 1261 If the Responder has a fixed and publicly reachable IPv4 address and 1262 does not employ a Control Relay Server, the explicit NAT traversal 1263 mode negotiation MAY be omitted, and thus even the UDP-ENCAPSULATION 1264 mode does not have to be negotiated. In such a scenario, the 1265 Initiator sends an I1 message over UDP and the Responder responds 1266 with an R1 message over UDP without including any NAT traversal mode 1267 parameter. The rest of the base exchange follows the procedures 1268 defined in [RFC7401], except that the control and data plane use UDP 1269 encapsulation. Here, the use of UDP for NAT traversal is agreed 1270 implicitly. This way of operation is still subject to NAT timeouts, 1271 and the hosts MUST employ NAT keepalives as defined in Section 4.10. 1273 When UDP-ENCAPSULATION mode is chosen either explicitly or 1274 implicitly, the connectivity checks as defined in this document MUST 1275 NOT be used. When hosts lose connectivity, they MUST instead utilize 1276 [RFC8046] or [RFC8047] procedures, but with the difference being that 1277 UDP-based tunneling MUST be employed for the entire lifetime of the 1278 corresponding Host Association. 1280 4.7.2. Base Exchange without Connectivity Checks 1282 It is possible to run a base exchange without any connectivity checks 1283 as defined in Legacy ICE-HIP section 4.8 [RFC5770]. The procedure is 1284 applicable also in the context of this specification, so it is 1285 repeated here for completeness. 1287 In certain network environments, the connectivity checks can be 1288 omitted to reduce initial connection set-up latency because a base 1289 exchange acts as an implicit connectivity test itself. For this to 1290 work, the Initiator MUST be able to reach the Responder by simply UDP 1291 encapsulating HIP and ESP packets sent to the Responder's address. 1292 Detecting and configuring this particular scenario is prone to 1293 failure unless carefully planned. 1295 In such a scenario, the Responder MAY include UDP-ENCAPSULATION NAT 1296 traversal mode as one of the supported modes in the R1 packet. If 1297 the Responder has registered to a Control Relay Server in order to 1298 discover its address candidates, it MUST also include a LOCATOR_SET 1299 parameter encapsulated inside an ENCRYPTED parameter in R1 message 1300 that contains a preferred address where the Responder is able to 1301 receive UDP-encapsulated ESP and HIP packets. This locator MUST be 1302 of type "Transport address", its Traffic type MUST be "both", and it 1303 MUST have the "Preferred bit" set (see Table 1). If there is no such 1304 locator in R1, the Initiator MUST use the source address of the R1 as 1305 the Responder's preferred address. 1307 The Initiator MAY choose the UDP-ENCAPSULATION mode if the Responder 1308 listed it in the supported modes and the Initiator does not wish to 1309 use the connectivity checks defined in this document for searching 1310 for a more optimal path. In this case, the Initiator sends the I2 1311 with UDP-ENCAPSULATION mode in the NAT traversal mode parameter 1312 directly to the Responder's preferred address (i.e., to the preferred 1313 locator in R1 or to the address where R1 was received from if there 1314 was no preferred locator in R1). The Initiator MAY include locators 1315 in I2 but they MUST NOT be taken as address candidates, since 1316 connectivity checks defined in this document will not be used for 1317 connections with UDP-ENCAPSULATION NAT traversal mode. Instead, if 1318 R2 and I2 are received and processed successfully, a security 1319 association can be created and UDP-encapsulated ESP can be exchanged 1320 between the hosts after the base exchange completes according to the 1321 rules in Section 4.4 in [RFC7401]. 1323 The Control Relay Server can be used for discovering address 1324 candidates but it is not intended to be used for relaying end-host 1325 packets using the UDP-ENCAPSULATION NAT mode. Since an I2 packet 1326 with UDP-ENCAPSULATION NAT traversal mode selected MUST NOT be sent 1327 via a Control Relay Server, the Responder SHOULD reject such I2 1328 packets and reply with a NO_VALID_NAT_TRAVERSAL_MODE_PARAMETER NOTIFY 1329 packet (see Section 5.10). 1331 If there is no answer for the I2 packet sent directly to the 1332 Responder's preferred address, the Initiator MAY send another I2 via 1333 the Control Relay Server, but it MUST NOT choose UDP-ENCAPSULATION 1334 NAT traversal mode for that I2. 1336 4.7.3. Initiating a Base Exchange both with and without UDP 1337 Encapsulation 1339 It is possible to run a base exchange in parallel both with and 1340 without UDP encapsulation as defined in Legacy ICE-HIP section 4.9 in 1341 [RFC5770]. The procedure is applicable also in the context of this 1342 specification, so it is repeated here for completeness. 1344 The Initiator MAY also try to simultaneously perform a base exchange 1345 with the Responder without UDP encapsulation. In such a case, the 1346 Initiator sends two I1 packets, one without and one with UDP 1347 encapsulation, to the Responder. The Initiator MAY wait for a while 1348 before sending the other I1. How long to wait and in which order to 1349 send the I1 packets can be decided based on local policy. For 1350 retransmissions, the procedure is repeated. 1352 The I1 packet without UDP encapsulation may arrive directly, without 1353 passing any a Control Relay Server, at the Responder. When this 1354 happens, the procedures in [RFC7401] are followed for the rest of the 1355 base exchange. The Initiator may receive multiple R1 packets, with 1356 and without UDP encapsulation, from the Responder. However, after 1357 receiving a valid R1 and answering it with an I2, further R1 packets 1358 that are not retransmissions of the R1 message received first MUST be 1359 ignored. 1361 The I1 packet without UDP encapsulation may also arrive at a HIP- 1362 capable middlebox. When the middlebox is a HIP rendezvous server and 1363 the Responder has successfully registered with the rendezvous 1364 service, the middlebox follows rendezvous procedures in [RFC8004]. 1366 If the Initiator receives a NAT traversal mode parameter in R1 1367 without UDP encapsulation, the Initiator MAY ignore this parameter 1368 and send an I2 without UDP encapsulation and without any selected NAT 1369 traversal mode. When the Responder receives the I2 without UDP 1370 encapsulation and without NAT traversal mode, it will assume that no 1371 NAT traversal mechanism is needed. The packet processing will be 1372 done as described in [RFC7401]. The Initiator MAY store the NAT 1373 traversal modes for future use, e.g., in case of a mobility or 1374 multihoming event that causes NAT traversal to be used during the 1375 lifetime of the HIP association. 1377 4.8. Sending Control Packets after the Base Exchange 1379 The same considerations of sending control packets after the base 1380 exchange described in legacy ICE-HIP section 5.10 in [RFC5770] apply 1381 also here, so they are repeated here for completeness. 1383 After the base exchange, the two end-hosts MAY send HIP control 1384 packets directly to each other using the transport address pair 1385 established for a data channel without sending the control packets 1386 through any Control Relay Servers . When a host does not receive 1387 acknowledgments, e.g., to an UPDATE or CLOSE packet after a timeout 1388 based on local policies, a host SHOULD resend the packet through the 1389 associated Data Relay Server of the peer (if the peer listed it in 1390 its LOCATOR_SET parameter in the base exchange according the rules 1391 specified in section 4.4.2 in [RFC7401]. 1393 If Control Relay Client sends a packet through a Control Relay 1394 Server, the Control Relay Client MUST always utilize the RELAY_TO 1395 parameter. The Control Relay Server SHOULD forward HIP control 1396 packets originating from a Control Relay Client to the address 1397 denoted in the RELAY_TO parameter. In the other direction, the 1398 Control Relay Server SHOULD forward HIP control packets to the 1399 Control Relay Clients, and MUST add a RELAY_FROM parameter to the 1400 control packets it relays to the Control Relay Clients. 1402 If the Control Relay Server is not willing or able to relay a HIP 1403 packet, it MAY notify the sender of the packet with 1404 MESSAGE_NOT_RELAYED error notification (see Section 5.10). 1406 4.9. Mobility Handover Procedure 1408 A host may move after base exchange and connectivity checks. 1409 Mobility extensions for HIP [RFC8046] define handover procedures 1410 without NATs. In this section, we define how two hosts interact with 1411 handover procedures in scenarios involving NATs. The specified 1412 extensions define only simple mobility using a pair of security 1413 associations, and multihoming extensions are left to be defined in 1414 later specifications. The procedures in this section offer the same 1415 functionality as "ICE restart" specified in [RFC8445]. The example 1416 described in this section shows only a Control Relay Server for the 1417 peer host for the sake of simplicity, but the mobile host may also 1418 have a Control Relay Server. 1420 The assumption here is that the two hosts have successfully 1421 negotiated and chosen the ICE-HIP-UDP mode during the base exchange 1422 as defined in Section 4.3. The Initiator of the base exchange MUST 1423 store information that it was the controlling host during the base 1424 exchange. Similarly, the Responder MUST store information that it 1425 was the controlled host during the base exchange. 1427 Prior to starting the handover procedures with all peer hosts, the 1428 mobile host SHOULD first send its locators in UPDATE messages to its 1429 Control and Data Relay Servers if it has registered to such. It 1430 SHOULD wait for all of them to respond for a configurable time, by 1431 default two minutes, and then continue with the handover procedure 1432 without information from the Relay Server that did not respond. As 1433 defined in Section 4.1, a response message from a Control Relay 1434 Server includes a REG_FROM parameter that describes the server 1435 reflexive candidate of the mobile host to be used in the candidate 1436 exchange during the handover. Similarly, an UPDATE to a Data Relay 1437 Server is necessary to make sure the Data Relay Server can forward 1438 data to the correct IP address after a handoff. 1440 The mobility extensions for NAT traversal are illustrated in 1441 Figure 6. The mobile host is the host that has changed its locators, 1442 and the peer host is the host it has a host association with. The 1443 mobile host may have multiple peers and it repeats the process with 1444 all of its peers. In the figure, the Control Relay Server belongs to 1445 the peer host, i.e., the peer host is a Control Relay Client for the 1446 Control Relay Server. Note that the figure corresponds to figure 3 1447 in [RFC8046], but the difference is that the main UPDATE procedure is 1448 carried over the relay and the connectivity is tested separately. 1449 Next, we describe the procedure in the figure in detail. 1451 Mobile Host Control Relay Server Peer Host 1452 | 1. UDP(UPDATE(ESP_INFO, | | 1453 | ENC(LOC_SET), SEQ)) | | 1454 +--------------------------------->| 2. UDP(UPDATE(ESP_INFO, | 1455 | | ENC(LOC_SET), SEQ, | 1456 | | RELAY_FROM)) | 1457 | +------------------------------->| 1458 | | | 1459 | | 3. UDP(UPDATE(ESP_INFO, SEQ, | 1460 | | ACK, ECHO_REQ_SIGN, | 1461 | | RELAY_TO)) | 1462 | 4. UDP(UPDATE(ESP_INFO, SEQ, |<-------------------------------+ 1463 | ACK, ECHO_REQ_SIGN, | | 1464 | RELAY_TO)) | | 1465 |<---------------------------------+ | 1466 | | | 1467 | 5. UDP(UPDATE(ACK, | | 1468 | ECHO_RESP_SIGNED)) | | 1469 +--------------------------------->| 6. UDP(UPDATE(ACK, | 1470 | | ECHO_RESP_SIGNED, | 1471 | | RELAY_FROM)) | 1472 | +------------------------------->| 1473 | | | 1474 | 7. connectivity checks over UDP | 1475 +<----------------------------------------------------------------->+ 1476 | | | 1477 | 8. ESP data over UDP | 1478 +<----------------------------------------------------------------->+ 1479 | | | 1481 Figure 6: HIP UPDATE procedure 1483 In step 1, the mobile host has changed location and sends a location 1484 update to its peer through the Control Relay Server of the peer. It 1485 sends an UPDATE packet with source HIT belonging to itself and 1486 destination HIT belonging to the peer host. In the packet, the 1487 source IP address belongs to the mobile host and the destination to 1488 the Control Relay Server. The packet contains an ESP_INFO parameter, 1489 where, in this case, the OLD SPI and NEW SPI parameters both contain 1490 the pre-existing incoming SPI. The packet also contains the locators 1491 of the mobile host in a LOCATOR_SET parameter, encapsulated inside an 1492 ENCRYPTED parameter (see sections 5.2.18 and 6.5 in [RFC7401] for 1493 details on the ENCRYPTED parameter). The packet contains also a SEQ 1494 number to be acknowledged by the peer. As specified in [RFC8046], 1495 the packet may also include a HOST_ID (for middlebox inspection) and 1496 DIFFIE_HELLMAN parameter for rekeying. 1498 In step 2, the Control Relay Server receives the UPDATE packet and 1499 forwards it to the peer host (i.e. Control Relay Client). The 1500 Control Relay Server rewrites the destination IP address and appends 1501 a RELAY_FROM parameter to the message. 1503 In step 3, the peer host receives the UPDATE packet, processes it and 1504 responds with another UPDATE message. The message is destined to the 1505 HIT of mobile host and to the IP address of the Control Relay Server. 1506 The message includes an ESP_INFO parameter where, in this case, the 1507 OLD SPI and NEW SPI parameters both contain the pre-existing incoming 1508 SPI. The peer includes a new SEQ and ECHO_REQUEST_SIGNED parameters 1509 to be acknowledged by the mobile host. The message acknowledges the 1510 SEQ parameter of the earlier message with an ACK parameter. The 1511 RELAY_TO parameter specifies the address of the mobile host where the 1512 Control Relay Server should forward the message. 1514 In step 4, the Control Relay Server receives the message, rewrites 1515 the destination IP address and UDP port according to the RELAY_TO 1516 parameter, and then forwards the modified message to the mobile host. 1518 In step 5, the mobile host receives the UPDATE packet and processes 1519 it. The mobile host concludes the handover procedure by 1520 acknowledging the received SEQ parameter with an ACK parameter and 1521 the ECHO_REQUEST_SIGNED parameter with ECHO_RESPONSE_SIGNED 1522 parameter. The mobile host delivers the packet to the HIT of the 1523 peer and to the address of the HIP relay. The mobile host can start 1524 connectivity checks after this packet. 1526 In step 6, HIP relay receives the UPDATE packet and forwards it to 1527 the peer host (i.e. Relay Client). The HIP relay rewrites the 1528 destination IP address and port, and then appends a RELAY_FROM 1529 parameter to the message. When the peer host receives this 1530 concluding UPDATE packet, it can initiate the connectivity checks. 1532 In step 7, the two hosts test for connectivity across NATs according 1533 to procedures described in Section 4.6. The original Initiator of 1534 the communications is the controlling and the original Responder is 1535 the controlled host. 1537 In step 8, the connectivity checks are successfully completed and the 1538 controlling host has nominated one address pair to be used. The 1539 hosts set up security associations to deliver the application 1540 payload. 1542 It is worth noting that the Control and Data Relay Client do not have 1543 to re-register for the related services after a handoff. However, if 1544 a Data Relay Client has registered a relayed address candidate from a 1545 Data Relay Server, the Data Relay Client MUST reactivate the address 1546 before the connectivity checks by sending an UPDATE message 1547 containing PEER_PERMISSION parameter as described in Section 4.12.1. 1548 Otherwise, the Data Relay Server drops ESP packets sent to the 1549 relayed address. 1551 In so called "double jump" or simultaneous mobility scenario both 1552 peers change their location simultaneously. In such a case, both 1553 peers trigger the procedure described earlier in this section at the 1554 same time. In other words, both of the communicating hosts send an 1555 UPDATE packet carrying locators at the same time or with some delay. 1556 When the locators are exchanged almost simultaneously (reliably via 1557 Control Relay Servers), the two hosts can continue with connectivity 1558 checks after both have completed separately the steps in Figure 6. 1559 The problematic case occurs when one of the hosts (referred here as 1560 host "M") moves later during the connectivity checks. In such a 1561 case, host M sends a locator to the peer which is in the middle of 1562 connectivity checks. Upon receiving the UPDATE message, the peer 1563 responds with an UPDATE with ECHO_REQ_SIGN as described in step 3 in 1564 Figure 6. Upon receiving the valid response from host M as described 1565 in step 6, the peer host MUST restart the connectivity checks with 1566 host M. This way, both hosts start the connectivity checks roughly 1567 in a synchronized way. It is also important that peer host does not 1568 restart the connectivity checks until the step 6 is successfully 1569 completed because the UPDATE message carrying locators in step 1 1570 could be replayed by an attacker. 1572 4.10. NAT Keepalives 1574 To prevent NAT states from expiring, communicating hosts MUST send 1575 periodic keepalives to other hosts with which they have established a 1576 Host Association every 15 seconds (the so called Tr value in ICE). 1577 Other values MAY be used, but a Tr value smaller than 15 seconds MUST 1578 NOT be used. Both a Control/Data Relay Client and Control/Data Relay 1579 Server, as well as two peers employing UDP-ENCAPSULATION or ICE-HIP- 1580 UDP mode, SHOULD send HIP NOTIFY packets unless they have exchanged 1581 some other traffic over the used UDP ports. However, the Data Relay 1582 Client and Data Relay Server MUST employ only HIP NOTIFY packets in 1583 order to keep the server reflexive candidates alive. The keepalive 1584 message encoding format is defined in Section 5.3. If the base 1585 exchange or mobility handover procedure occurs during an extremely 1586 slow path, a host (with a Host Association with the peer) MAY also 1587 send HIP NOTIFY packets every 15 seconds to keep the path active with 1588 the recipient. 1590 4.11. Closing Procedure 1592 The two-way procedure for closing a HIP association and the related 1593 security associations is defined in [RFC7401]. One host initiates 1594 the procedure by sending a CLOSE message and the recipient confirms 1595 it with CLOSE_ACK. All packets are protected using HMACs and 1596 signatures, and the CLOSE messages includes a ECHO_REQUEST_SIGNED 1597 parameter to protect against replay attacks. 1599 The same procedure for closing HIP associations applies also here, 1600 but the messaging occurs using the UDP encapsulated tunnel that the 1601 two hosts employ. A host sending the CLOSE message SHOULD first send 1602 the message over a direct link. After a number of retransmissions, 1603 it MUST send over a Control Relay Server of the recipient if one 1604 exists. The host receiving the CLOSE message directly without a 1605 Control Relay Server SHOULD respond directly. If CLOSE message came 1606 via a Control Relay Server, the host SHOULD respond using the same 1607 Control Relay Server. 1609 4.12. Relaying Considerations 1611 4.12.1. Forwarding Rules and Permissions 1613 The Data Relay Server uses a similar permission model as a TURN 1614 server: before the Data Relay Server forwards any ESP data packets 1615 from a peer to a Data Relay Client (or the other direction), the 1616 client MUST set a permission for the peer's address. The permissions 1617 also install a forwarding rule for each direction, similar to TURN's 1618 channels, based on the Security Parameter Index (SPI) values in the 1619 ESP packets. 1621 Permissions are not required for HIP control packets. However, if a 1622 relayed address (as conveyed in the RELAYED_ADDRESS parameter from 1623 the Data Relay Server) is selected to be used for data, the Control 1624 Relay Client MUST send an UPDATE message to the Data Relay Server 1625 containing a PEER_PERMISSION parameter (see Section 5.13) with the 1626 following information: the UDP port and address for the server 1627 reflexive address, the UDP port and address of the peer, and the 1628 inbound and outbound SPIs used for ESP. The packet MUST be sent to 1629 the same UDP tunnel the Client employed in the base exchange to 1630 contact the Server (i.e., not to the port occupied by the server 1631 reflexive candidate). To avoid packet dropping of ESP packets, the 1632 Control Relay Client SHOULD send the PEER_PERMISSION parameter before 1633 connectivity checks both in the case of base exchange and a mobility 1634 handover. It is worth noting that the UPDATE message includes a SEQ 1635 parameter (as specified in [RFC7401]) that the Data Relay Server must 1636 acknowledge, so that the Control Relay Client can resend the message 1637 with PEER_PERMISSION parameter if it gets lost. 1639 When a Data Relay Server receives an UPDATE with a PEER_PERMISSION 1640 parameter, it MUST check if the sender of the UPDATE is registered 1641 for data relaying service, and drop the UPDATE if the host was not 1642 registered. If the host was registered, the Data Relay Server checks 1643 if there is a permission with matching information (protocol, 1644 addresses, ports and SPI values). If there is no such permission, a 1645 new permission MUST be created and its lifetime MUST be set to 5 1646 minutes. If an identical permission already existed, it MUST be 1647 refreshed by setting the lifetime to 5 minutes. A Data Relay Client 1648 SHOULD refresh permissions 1 minute before the expiration when the 1649 permission is still needed. 1651 When a Data Relay Server receives an UPDATE from a registered client 1652 but without a PEER_PERMISSION parameter and with a new locator set, 1653 the Data Relay Server can assume that the mobile host has changed its 1654 location and, thus, is not reachable in its previous location. In 1655 such an event, the Data Relay Server SHOULD deactivate the permission 1656 and stop relaying data plane traffic to the client. 1658 The relayed address MUST be activated with the PEER_PERMISSION 1659 parameter both after a base exchange and after a handover procedure 1660 with another ICE-HIP-UDP capable host. Unless activated, the Data 1661 Relay Server MUST drop all ESP packets. It is worth noting that a 1662 Data Relay Client does not have to renew its registration upon a 1663 change of location UPDATE, but only when the lifetime of the 1664 registration is close to end. 1666 4.12.2. HIP Data Relay and Relaying of Control Packets 1668 When a Data Relay Server accepts to relay UDP encapsulated ESP 1669 between a Data Relay Client and its peer, the Data Relay Server opens 1670 a UDP port (relayed address) for this purpose as described in 1671 Section 4.1. This port can be used for delivering also control 1672 packets because connectivity checks also cover the path through the 1673 Data Relay Server. If the Data Relay Server receives a UDP 1674 encapsulated HIP control packet on that port, it MUST forward the 1675 packet to the Data Relay Client and add a RELAY_FROM parameter to the 1676 packet as if the Data Relay Server were acting as a Control Relay 1677 Server. When the Data Relay Client replies to a control packet with 1678 a RELAY_FROM parameter via its Data Relay Server, the Data Relay 1679 Client MUST add a RELAY_TO parameter containing the peer's address 1680 and use the address of its Data Relay Server as the destination 1681 address. Further, the Data Relay Server MUST send this packet to the 1682 peer's address from the relayed address. 1684 If the Data Relay Server receives a UDP packet that is not a HIP 1685 control packet to the relayed address, it MUST check if it has a 1686 permission set for the peer the packet is arriving from (i.e., the 1687 sender's address and SPI value matches to an installed permission). 1688 If permissions are set, the Data Relay Server MUST forward the packet 1689 to the Data Relay Client that created the permission. The Data Relay 1690 Server MUST also implement the similar checks for the reverse 1691 direction (i.e. ESP packets from the Data Relay Client to the peer). 1692 Packets without a permission MUST be dropped silently. 1694 4.12.3. Handling Conflicting SPI Values 1696 From the viewpoint of a host, its remote peers can have overlapping 1697 inbound SPI numbers because the IPsec uses also the destination IP 1698 address to index the remote peer host. However, a Data Relay Server 1699 can represent multiple remote peers, thus masquerading the actual 1700 destination. Since a Data Relay Server may have to deal with a 1701 multitude of Relay Clients and their peers, a Data Relay Server may 1702 experience collisions in the SPI namespace, thus being unable forward 1703 datagrams to the correct destination. Since the SPI space is 32 bits 1704 and the SPI values should be random, the probability for a 1705 conflicting SPI value is fairly small, but could occur on a busy Data 1706 Relay Server. The two problematic cases are described in this 1707 section. 1709 In the first scenario, the SPI collision problems occurs if two hosts 1710 have registered to the same Data Relay Server and a third host 1711 initiates base exchange with both of them. Here, the two Responders 1712 (i.e. Data Relay Clients) claim the same inbound SPI number with the 1713 same Initiator (peer). However, in this case, the Data Relay Server 1714 has allocated separate UDP ports for the two Data Relay Clients 1715 acting now as Responders (as recommended in Section 6.5). When the 1716 third host sends an ESP packet, the Data Relay Server is able to 1717 forward the packet to the correct Data Relay Client because the 1718 destination UDP port is different for each of the clients. 1720 In the second scenario, an SPI collision may occur when two 1721 Initiators run a base exchange to the same Responder (i.e. Data 1722 Relay Client), and both of the Initiators claim the same inbound SPI 1723 at the Data Relay Server using PEER_PERMISSION Parameter. In this 1724 case, the Data Relay Server cannot disambiguate the correct 1725 destination of an ESP packet originating from the Data Relay Client 1726 because the SPI could belong to either of the peers (and destination 1727 IP and UDP port belonging to the Data Relay Server are not unique 1728 either). The recommended way and a contingency plan to solve this 1729 issue are described below. 1731 The recommend way to mitigate the problem is as follows. For each 1732 new Host Association, A Data Relay Client acting as a Responder 1733 SHOULD register a new server reflexive candidate as described in 1734 Section 4.2. Similarly, the Data Relay Server SHOULD NOT re-use the 1735 port numbers as described in Section 6.5. This way, each server 1736 reflexive candidate for the Data Relay Client has a separate UDP port 1737 that the Data Relay Server can use to disambiguate packet 1738 destinations in case of SPI collisions. 1740 When the Data Relay Client is not registering or failed to register a 1741 new relay candidate for a new peer, the Data Relay Client MUST follow 1742 a contingency plan as follows. Upon receiving an I2 with a colliding 1743 SPI, the Data Relay client acting as the Responder MUST NOT include 1744 the relayed address candidate in the R2 message because the Data 1745 Relay Server would not be able demultiplex the related ESP packet to 1746 the correct Initiator. The same applies also the handover 1747 procedures; the Data Relay Client MUST NOT include the relayed 1748 address candidate when sending its new locator set in an UPDATE to 1749 its peer if it would cause a SPI conflict with another peer. 1751 5. Packet Formats 1753 The following subsections define the parameter and packet encodings 1754 for the HIP and ESP packets. All values MUST be in network byte 1755 order. 1757 It is worth noting that all of the parameters are shown for the sake 1758 of completeness even though they are specified already in Legacy ICE- 1759 HIP [RFC5770]. New parameters are explicitly described as new. 1761 5.1. HIP Control Packets 1763 Figure 7 illustrates the packet format for UDP-encapsulated HIP. The 1764 format is identical to Legacy ICE-HIP [RFC5770]. 1766 0 1 2 3 1767 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 1768 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1769 | Source Port | Destination Port | 1770 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1771 | Length | Checksum | 1772 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1773 | 32 bits of zeroes | 1774 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1775 | | 1776 ~ HIP Header and Parameters ~ 1777 | | 1778 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1780 Figure 7: Format of UDP-Encapsulated HIP Control Packets 1782 HIP control packets are encapsulated in UDP packets as defined in 1783 Section 2.2 of [RFC3948], "IKE Header Format for Port 4500", except 1784 that a different port number is used. Figure 7 illustrates the 1785 encapsulation. The UDP header is followed by 32 zero bits that can 1786 be used to differentiate HIP control packets from ESP packets. The 1787 HIP header and parameters follow the conventions of [RFC7401] with 1788 the exception that the HIP header checksum MUST be zero. The HIP 1789 header checksum is zero for two reasons. First, the UDP header 1790 already contains a checksum. Second, the checksum definition in 1791 [RFC7401] includes the IP addresses in the checksum calculation. The 1792 NATs that are unaware of HIP cannot recompute the HIP checksum after 1793 changing IP addresses. 1795 A Control/Data Relay Server or a non-relay Responder SHOULD listen at 1796 UDP port 10500 for incoming UDP-encapsulated HIP control packets. If 1797 some other port number is used, it needs to be known by potential 1798 Initiators. 1800 UDP encapsulation of HIP packets reduces the Maximum Transfer Unit 1801 (MTU) size of the control plane by 12 bytes (8-byte UDP header plus 1802 4-byte zero SPI marker), and the data plane by 8 bytes. Additional 1803 HIP relay parameters, such as RELAY_HMAC, RELAY_UDP_HIP, 1804 RELAY_UDP_ESP, etc., further increase the size of certain HIP 1805 packets. In regard to MTU, the following aspects need to be 1806 considered in an implementation: 1808 o A HIP host SHOULD implement ICMP message handling to support path 1809 MTU discovery (PMTUD) discovery as described in [RFC1063] 1810 [RFC8201] 1812 o Reliance on IP fragmentation is unlikely to be a viable strategy 1813 through NATs. If ICMP MTU discovery is not working, MTU related 1814 path black holes may occur. 1816 o A mitigation strategy is to constrain the MTU, especially for 1817 virtual interfaces, to expected safe MTU values, e.g., 1400 bytes 1818 for the underlying interfaces that support 1500 bytes MTU. 1820 o Further extensions to this specification may define a HIP-based 1821 mechanism to find a working path MTU without unnecessary 1822 constraining that size using Packetization Layer Path MTU 1823 Discovery for Datagram Transports 1824 [I-D.ietf-tsvwg-datagram-plpmtud]. For instance, such mechanism 1825 could be implemented between a HIP Relay Client and HIP Relay 1826 Server. 1828 o It is worth noting that further HIP extensions can trim off 8 1829 bytes in the ESP header by negotiating implicit IV support in the 1830 ESP_TRANSFORM parameter as described in [RFC8750]. 1832 5.2. Connectivity Checks 1834 HIP connectivity checks are HIP UPDATE packets. The format is 1835 specified in [RFC7401]. 1837 5.3. Keepalives 1839 The RECOMMENDED encoding format for keepalives is HIP NOTIFY packets 1840 as specified in [RFC7401] with Notify message type field set to 1841 NAT_KEEPALIVE [TBD by IANA: 16385] and with an empty Notification 1842 data field. It is worth noting that sending of such a HIP NOTIFY 1843 message SHOULD be omitted if the host is actively (or passively) 1844 sending some other traffic (HIP or ESP) to the peer host over the 1845 related UDP tunnel during the Tr period. For instance, the host MAY 1846 actively send ICMPv6 requests (or respond with an ICMPv6 response) 1847 inside the ESP tunnel to test the health of the associated IPsec 1848 security association. Alternatively, the host MAY use UPDATE packets 1849 as a substitute. A minimal UPDATE packet would consist of a SEQ and 1850 ECHO_REQ_SIGN parameters, and a more complex would involve rekeying 1851 procedures as specified in section 6.8 in [RFC7402]. It is worth 1852 noting that a host actively sending periodic UPDATE packets to a busy 1853 server may increase the computational load of the server since it has 1854 to verify HMACs and signatures in UPDATE messages. 1856 5.4. NAT Traversal Mode Parameter 1858 The format of NAT traversal mode parameter is defined in Legacy ICE- 1859 HIP [RFC5770] but repeated here for completeness. The format of the 1860 NAT_TRAVERSAL_MODE parameter is similar to the format of the 1861 ESP_TRANSFORM parameter in [RFC7402] and is shown in Figure 8. The 1862 Native ICE-HIP extension specified in this document defines the new 1863 NAT traversal mode identifier for ICE-HIP-UDP and reuses the UDP- 1864 ENCAPSULATION mode from Legacy ICE-HIP [RFC5770]. The identifier 1865 named RESERVED is reserved for future use. Future specifications may 1866 define more traversal modes. 1868 0 1 2 3 1869 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 1870 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1871 | Type | Length | 1872 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1873 | Reserved | Mode ID #1 | 1874 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1875 | Mode ID #2 | Mode ID #3 | 1876 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1877 | Mode ID #n | Padding | 1878 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1880 Type 608 1881 Length length in octets, excluding Type, Length, and padding 1882 Reserved zero when sent, ignored when received 1883 Mode ID defines the proposed or selected NAT traversal mode(s) 1885 The following NAT traversal mode IDs are defined: 1887 ID name Value 1888 RESERVED 0 1889 UDP-ENCAPSULATION 1 1890 ICE-STUN-UDP 2 1891 ICE-HIP-UDP 3 1893 Figure 8: Format of the NAT_TRAVERSAL_MODE Parameter 1895 The sender of a NAT_TRAVERSAL_MODE parameter MUST make sure that 1896 there are no more than six (6) Mode IDs in one NAT_TRAVERSAL_MODE 1897 parameter. Conversely, a recipient MUST be prepared to handle 1898 received NAT traversal mode parameters that contain more than six 1899 Mode IDs by accepting the first six Mode IDs and dropping the rest. 1900 The limited number of Mode IDs sets the maximum size of the 1901 NAT_TRAVERSAL_MODE parameter. The modes MUST be in preference order, 1902 most preferred mode(s) first. 1904 Implementations conforming to this specification MUST implement UDP- 1905 ENCAPSULATION and SHOULD implement ICE-HIP-UDP modes. 1907 5.5. Connectivity Check Transaction Pacing Parameter 1909 The TRANSACTION_PACING is defined in [RFC5770], but repeated in 1910 Figure 9 for completeness. It contains only the connectivity check 1911 pacing value, expressed in milliseconds, as a 32-bit unsigned 1912 integer. 1914 0 1 2 3 1915 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 1916 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1917 | Type | Length | 1918 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1919 | Min Ta | 1920 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1922 Type 610 1923 Length 4 1924 Min Ta the minimum connectivity check transaction pacing 1925 value the host would use (in milliseconds) 1927 Figure 9: Format of the TRANSACTION_PACING Parameter 1929 5.6. Relay and Registration Parameters 1931 The format of the REG_FROM, RELAY_FROM, and RELAY_TO parameters is 1932 shown in Figure 10. All parameters are identical except for the 1933 type. Of the three, only REG_FROM is covered by the signature. 1935 0 1 2 3 1936 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 1937 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1938 | Type | Length | 1939 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1940 | Port | Protocol | Reserved | 1941 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1942 | | 1943 | Address | 1944 | | 1945 | | 1946 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1948 Type REG_FROM: 950 1949 RELAY_FROM: 63998 1950 RELAY_TO: 64002 1951 Length 20 1952 Port transport port number; zero when plain IP is used 1953 Protocol IANA assigned, Internet Protocol number. 1954 17 for UDP, 0 for plain IP 1955 Reserved reserved for future use; zero when sent, ignored 1956 when received 1957 Address an IPv6 address or an IPv4 address in "IPv4-Mapped 1958 IPv6 address" format 1960 Figure 10: Format of the REG_FROM, RELAY_FROM, and RELAY_TO 1961 Parameters 1963 REG_FROM contains the transport address and protocol from which the 1964 Control Relay Server sees the registration coming. RELAY_FROM 1965 contains the address from which the relayed packet was received by 1966 the Control Relay Server and the protocol that was used. RELAY_TO 1967 contains the same information about the address to which a packet 1968 should be forwarded. 1970 5.7. LOCATOR_SET Parameter 1972 This specification reuses the format for UDP-based locators as 1973 specified in Legacy ICE-HIP [RFC5770] to be used for communicating 1974 the address candidates between two hosts. The generic and NAT- 1975 traversal-specific locator parameters are illustrated in Figure 11. 1977 0 1 2 3 1978 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 1979 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1980 | Type | Length | 1981 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1982 | Traffic Type | Locator Type | Locator Length| Reserved |P| 1983 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1984 | Locator Lifetime | 1985 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1986 | Locator | 1987 | | 1988 | | 1989 | | 1990 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1991 . . 1992 . . 1993 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1994 | Traffic Type | Loc Type = 2 | Locator Length| Reserved |P| 1995 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1996 | Locator Lifetime | 1997 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1998 | Transport Port | Transp. Proto| Kind | 1999 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2000 | Priority | 2001 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2002 | SPI | 2003 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2004 | Address | 2005 | | 2006 | | 2007 | | 2008 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2010 Figure 11: LOCATOR_SET Parameter 2012 The individual fields in the LOCATOR_SET parameter are described in 2013 Table 1. 2015 +-----------+----------+--------------------------------------------+ 2016 | Field | Value(s) | Purpose | 2017 +-----------+----------+--------------------------------------------+ 2018 | Type | 193 | Parameter type | 2019 | Length | Variable | Length in octets, excluding Type and | 2020 | | | Length fields and padding | 2021 | Traffic | 0-2 | Is the locator for HIP signaling (1), for | 2022 | Type | | ESP (2), or for both (0) | 2023 | Locator | 2 | "Transport address" locator type | 2024 | Type | | | 2025 | Locator | 7 | Length of the fields after Locator | 2026 | Length | | Lifetime in 4-octet units | 2027 | Reserved | 0 | Reserved for future extensions | 2028 | Preferred | 0 or 1 | Set to 1 for a Locator in R1 if the | 2029 | (P) bit | | Responder can use it for the rest of the | 2030 | | | base exchange, otherwise set to zero | 2031 | Locator | Variable | Locator lifetime in seconds, see Section 4 | 2032 | Lifetime | | in [RFC8046] | 2033 | Transport | Variable | Transport layer port number | 2034 | Port | | | 2035 | Transport | Variable | IANA assigned, transport layer Internet | 2036 | Protocol | | Protocol number. Currently only UDP (17) | 2037 | | | is supported. | 2038 | Kind | Variable | 0 for host, 1 for server reflexive, 2 for | 2039 | | | peer reflexive (currently unused) or 3 for | 2040 | | | relayed address | 2041 | Priority | Variable | Locator's priority as described in | 2042 | | | [RFC8445]. It is worth noting that while | 2043 | | | the priority of a single locator candidate | 2044 | | | is 32-bits, but an implementation should | 2045 | | | use a 64-bit integer to calculate the | 2046 | | | priority of a candidate pair for the ICE | 2047 | | | priority algorithm. | 2048 | SPI | Variable | Security Parameter Index (SPI) value that | 2049 | | | the host expects to see in incoming ESP | 2050 | | | packets that use this locator | 2051 | Address | Variable | IPv6 address or an "IPv4-Mapped IPv6 | 2052 | | | address" format IPv4 address [RFC4291] | 2053 +-----------+----------+--------------------------------------------+ 2055 Table 1: Fields of the LOCATOR_SET Parameter 2057 The LOCATOR parameter MUST be encapsulated inside an ENCRYPTED 2058 parameter. 2060 5.8. RELAY_HMAC Parameter 2062 As specified in Legacy ICE-HIP [RFC5770], the RELAY_HMAC parameter 2063 value has the TLV type 65520. It has the same semantics as RVS_HMAC 2064 as specified in section 4.2.1 in [RFC8004]. Similarly as with 2065 RVS_HMAC, also RELAY_HMAC is keyed with the HIP integrity key (HIP-lg 2066 or HIP-gl as specified in section 6.5 in [RFC7401]), established 2067 during the relay registration procedure as described in Section 4.1. 2069 5.9. Registration Types 2071 The REG_INFO, REG_REQ, REG_RESP, and REG_FAILED parameters contain 2072 Registration Type [RFC8003] values for Control Relay Server 2073 registration. The value for RELAY_UDP_HIP is 2 as specified in 2074 Legacy ICE-HIP [RFC5770]. The value for RELAY_UDP_ESP is (value [TBD 2075 by IANA: 3]). 2077 5.10. Notify Packet Types 2079 A Control/Data Relay Server and end-hosts can use NOTIFY packets to 2080 signal different error conditions. The NOTIFY packet types are the 2081 same as in Legacy ICE-HIP [RFC5770] except for the two last ones, 2082 which are new. 2084 The Notify Packet Types [RFC7401] are shown below. The Notification 2085 Data field for the error notifications SHOULD contain the HIP header 2086 of the rejected packet and SHOULD be empty for the 2087 CONNECTIVITY_CHECKS_FAILED type. 2089 NOTIFICATION PARAMETER - ERROR TYPES Value 2090 ------------------------------------ ----- 2092 NO_VALID_NAT_TRAVERSAL_MODE_PARAMETER 60 2094 If a Control Relay Server does not forward a base exchange packet 2095 due to missing NAT traversal mode parameter, or the Initiator 2096 selects a NAT traversal mode that the (non-relay) Responder did 2097 not expect, the Control Relay Server or the Responder may send 2098 back a NOTIFY error packet with this type. 2100 CONNECTIVITY_CHECKS_FAILED 61 2102 Used by the end-hosts to signal that NAT traversal connectivity 2103 checks failed and did not produce a working path. 2105 MESSAGE_NOT_RELAYED 62 2106 Used by a Control Relay Server to signal that is was not able or 2107 willing to relay a HIP packet. 2109 SERVER_REFLEXIVE_CANDIDATE_ALLOCATION_FAILED 63 2111 Used by a Data Relay Server to signal that is was not able or 2112 willing to allocate a new server reflexive candidate for the Data 2113 Relay Client 2115 RVS_HMAC_PROHIBITED_WITH_RELAY 64 2117 In the unintended event that a Control Relay Server sends any HIP 2118 message with a RVS_HMAC parameter, the Control Relay Client drops 2119 the received HIP message and sends a notify message back to the 2120 Control Relay Server using this notify type 2122 5.11. ESP Data Packets 2124 The format for ESP data packets is identical to Legacy ICE-HIP 2125 [RFC5770]. 2127 [RFC3948] describes the UDP encapsulation of the IPsec ESP transport 2128 and tunnel mode. On the wire, the HIP ESP packets do not differ from 2129 the transport mode ESP, and thus the encapsulation of the HIP ESP 2130 packets is same as the UDP encapsulation transport mode ESP. 2131 However, the (semantic) difference to Bound End-to-End Tunnel (BEET) 2132 mode ESP packets used by HIP is that IP header is not used in BEET 2133 integrity protection calculation. 2135 During the HIP base exchange, the two peers exchange parameters that 2136 enable them to define a pair of IPsec ESP security associations (SAs) 2137 as described in [RFC7402]. When two peers perform a UDP-encapsulated 2138 base exchange, they MUST define a pair of IPsec SAs that produces 2139 UDP-encapsulated ESP data traffic. 2141 The management of encryption/authentication protocols and SPIs is 2142 defined in [RFC7402]. The UDP encapsulation format and processing of 2143 HIP ESP traffic is described in Section 6.1 of [RFC7402]. 2145 5.12. RELAYED_ADDRESS and MAPPED_ADDRESS Parameters 2147 While the type values are new, the format of the RELAYED_ADDRESS and 2148 MAPPED_ADDRESS parameters (Figure 12) is identical to REG_FROM, 2149 RELAY_FROM and RELAY_TO parameters. This document specifies only the 2150 use of UDP relaying, and, thus, only protocol 17 is allowed. 2151 However, future documents may specify support for other protocols. 2153 0 1 2 3 2154 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 2155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2156 | Type | Length | 2157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2158 | Port | Protocol | Reserved | 2159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2160 | | 2161 | Address | 2162 | | 2163 | | 2164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2166 Type [TBD by IANA; 2167 RELAYED_ADDRESS: 4650 2168 MAPPED_ADDRESS: 4660] 2169 Length 20 2170 Port the UDP port number 2171 Protocol IANA assigned, Internet Protocol number (17 for UDP) 2172 Reserved reserved for future use; zero when sent, ignored 2173 when received 2174 Address an IPv6 address or an IPv4 address in "IPv4-Mapped 2175 IPv6 address" format 2177 Figure 12: Format of the RELAYED_ADDRESS and MAPPED_ADDRESS 2178 Parameters 2180 5.13. PEER_PERMISSION Parameter 2182 The format of the new PEER_PERMISSION parameter is shown in 2183 Figure 13. The parameter is used for setting up and refreshing 2184 forwarding rules and the permissions for data packets at the Data 2185 Relay Server. The parameter contains one or more sets of Port, 2186 Protocol, Address, Outbound SPI (OSPI), and Inbound SPI (ISPI) 2187 values. One set defines a rule for one peer address. 2189 0 1 2 3 2190 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 2191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2192 | Type | Length | 2193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2194 | RPort | PPort | 2195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2196 | Protocol | Reserved | 2197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2198 | | 2199 | RAddress | 2200 | | 2201 | | 2202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2203 | | 2204 | PAddress | 2205 | | 2206 | | 2207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2208 | OSPI | 2209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2210 | ISPI | 2211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2213 Type [TBD by IANA; 4680] 2214 Length 48 2215 RPort the transport layer (UDP) port at the Data Relay Server 2216 (i.e. the port of the server reflexive candidate) 2217 PPort the transport layer (UDP) port number of the peer 2218 Protocol IANA assigned, Internet Protocol number (17 for UDP) 2219 Reserved reserved for future use; zero when sent, ignored 2220 when received 2221 RAddress an IPv6 address, or an IPv4 address in "IPv4-Mapped 2222 IPv6 address" format, of the server reflexive candidate 2223 PAddress an IPv6 address, or an IPv4 address in "IPv4-Mapped 2224 IPv6 address" format, of the peer 2225 OSPI the outbound SPI value the Data Relay Client is using for 2226 the peer 2227 ISPI the inbound SPI value the Data Relay Client is using for 2228 the peer 2230 Figure 13: Format of the PEER_PERMISSION Parameter 2232 5.14. HIP Connectivity Check Packets 2234 The connectivity request messages are HIP UPDATE packets containing a 2235 new CANDIDATE_PRIORITY parameter (Figure 14). Response UPDATE 2236 packets contain a MAPPED_ADDRESS parameter (Figure 12). 2238 0 1 2 3 2239 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 2240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2241 | Type | Length | 2242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2243 | Priority | 2244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2246 Type [TBD by IANA; 4700] 2247 Length 4 2248 Priority the priority of a (potential) peer reflexive candidate 2250 Figure 14: Format of the CANDIDATE_PRIORITY Parameter 2252 5.15. NOMINATE parameter 2254 Figure 15 shows the NOMINATE parameter that is used to conclude the 2255 candidate nomination process. 2257 0 1 2 3 2258 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 2259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2260 | Type | Length | 2261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2262 | Reserved | 2263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2265 Type [TBD by IANA; 4710] 2266 Length 4 2267 Reserved Reserved for future extension purposes 2269 Figure 15: Format of the NOMINATE Parameter 2271 6. Security Considerations 2273 Since the control plane protocol and Control Relay Server are 2274 essentially the same (with some minor differences) in this document 2275 as in Legacy ICE-HIP [RFC5770], the same security considerations (in 2276 Section 6.1, Section 6.2, Section 6.3 and Section 6.4,) are still 2277 valid, but are repeated here for the sake of completeness. New 2278 security considerations related to the new Data Relay Server are 2279 discussed in Section 6.5, and considerations related to the new 2280 connectivity check protocol are discussed in Section 6.6 and 2281 Section 6.7. 2283 6.1. Privacy Considerations 2285 It is also possible that end-users may not want to reveal all 2286 locators to each other. For example, tracking the physical location 2287 of a multihoming end-host may become easier if it reveals all 2288 locators to its peer during a base exchange. Also, revealing host 2289 addresses exposes information about the local topology that may not 2290 be allowed in all corporate environments. For these two local policy 2291 reasons, it might be tempting exclude certain host addresses from the 2292 LOCATOR_SET parameter of an end-host but this is NOT RECOMMENDED. 2293 For instance, such behavior creates non-optimal paths when the hosts 2294 are located behind the same NAT. Especially, this could be 2295 problematic with a legacy NAT that does not support routing from the 2296 private address realm back to itself through the outer address of the 2297 NAT. This scenario is referred to as the hairpin problem [RFC5128]. 2298 With such a legacy NAT, the only option left would be to use a 2299 relayed transport address from an Data Relay Server. 2301 The use of Control and Data Relay Servers can be also useful for 2302 privacy purposes. For example, a privacy concerned Responder may 2303 reveal only its Control Relay Server and Relayed candidates to 2304 Initiators. This partially protects the Responder against Denial-of- 2305 Service (DoS) attacks by allowing the Responder to initiate new 2306 connections even if its relays would be unavailable due to a DoS 2307 attack. 2309 6.2. Opportunistic Mode 2311 In opportunistic HIP mode (cf. Section 4.1.8 in [RFC7401]), an 2312 Initiator sends an I1 with without setting the destination HIT of the 2313 Responder (i.e. the Control Relay Client). A Control Relay Server 2314 SHOULD have a unique IP address per Control Relay Client when the 2315 Control Relay Server is serving more than one Control Relay Client 2316 and supports opportunistic mode. Otherwise, the Control Relay Server 2317 cannot guarantee to deliver the I1 packet to the intended recipient. 2318 Future extensions of this document may allow opportunistic mode to be 2319 used with non-unique IP addresses to be utilized either as a HIP- 2320 level anycast or multicast mechanism. Both of the mentioned cases 2321 would require a separate registration parameters that the Control 2322 Relay Server proposes and the Control Client Server accepts during 2323 registration. 2325 6.3. Base Exchange Replay Protection for Control Relay Server 2327 In certain scenarios, it is possible that an attacker, or two 2328 attackers, can replay an earlier base exchange through a Control 2329 Relay Server by masquerading as the original Initiator and Responder. 2330 The attack does not require the attacker(s) to compromise the private 2331 key(s) of the attacked host(s). However, for this attack to succeed, 2332 the legitimate Responder has to be disconnected from the Control 2333 Relay Server. 2335 The Control Relay Server can protect itself against replay attacks by 2336 becoming involved in the base exchange by introducing nonces that the 2337 end-hosts (Initiator and Responder) are required to sign. One way to 2338 do this is to add ECHO_REQUEST_M parameters to the R1 and I2 packets 2339 as described in [I-D.heer-hip-middle-auth] and drop the I2 or R2 2340 packets if the corresponding ECHO_RESPONSE_M parameters are not 2341 present. 2343 6.4. Demultiplexing Different HIP Associations 2345 Section 5.1 of [RFC3948] describes a security issue for the UDP 2346 encapsulation in the standard IP tunnel mode when two hosts behind 2347 different NATs have the same private IP address and initiate 2348 communication to the same Responder in the public Internet. The 2349 Responder cannot distinguish between two hosts, because security 2350 associations are based on the same inner IP addresses. 2352 This issue does not exist with the UDP encapsulation of HIP ESP 2353 transport format because the Responder uses HITs to distinguish 2354 between different Initiators. 2356 6.5. Reuse of Ports at the Data Relay Server 2358 If the Data Relay Server uses the same relayed address and port (as 2359 conveyed in the RELAYED_ADDRESS parameter) for multiple Data Relay 2360 Clients, it appears to all the peers, and their firewalls, that all 2361 the Data Relay Clients are at the same address. Thus, a stateful 2362 firewall may allow packets pass from hosts that would not normally be 2363 able to send packets to a peer behind the firewall. Therefore, a 2364 Data Relay Server SHOULD NOT re-use the port numbers. If port 2365 numbers need to be re-used, the Data Relay Server SHOULD have a 2366 sufficiently large pool of port numbers and select ports from the 2367 pool randomly to decrease the chances of a Data Relay Client 2368 obtaining the same address that a another host behind the same 2369 firewall is using. 2371 6.6. Amplification attacks 2373 A malicious host may send an invalid list of candidates to its peer 2374 that are used for targeting a victim host by flooding it with 2375 connectivity checks. To mitigate the attack, this protocol adopts 2376 the ICE mechanism to cap the total amount of connectivity checks as 2377 defined in Section 4.7. 2379 6.7. Attacks against Connectivity Checks and Candidate Gathering 2381 Section 19.2 in [RFC8445] describes attacks against ICE connectivity 2382 checks. HIP bases its control plane security on Diffie-Hellman key 2383 exchange, public keys and Hashed Message Authentication codes, 2384 meaning that the mentioned security concerns do not apply to HIP 2385 either. The mentioned section discusses also of man-in-the-middle 2386 replay attacks that are difficult to prevent. The connectivity 2387 checks in this protocol are effectively immune against replay attacks 2388 because a connectivity request includes a random nonce that the 2389 recipient must sign and send back as a response. 2391 Section 19.3 in [RFC8445] describes attacks on server reflexive 2392 address gathering. Similarly here, if the DNS, a Control Relay 2393 Server or a Data Relay Server has been compromised, not much can be 2394 done. However, the case where attacker can inject fake messages 2395 (located on a shared network segment like Wifi) does not apply here. 2396 HIP messages are integrity and replay protected, so it is not 2397 possible inject fake server reflexive address candidates. 2399 Section 19.4 in [RFC8445] describes attacks on relayed candidate 2400 gathering. Similarly to ICE TURN servers, Data Relay Server require 2401 an authenticated base exchange that protects relayed address 2402 gathering against fake requests and responses. Further, replay 2403 attacks are not possible because the HIP base exchange (and also 2404 UPDATE procedure) is protected against replay attacks. 2406 6.8. Cross-Protocol Attacks 2408 Section 4.1 explains how a Control Relay Client registers for the 2409 RELAY_UDP_HIP service from a Control Relay Server. However, the same 2410 server may offer also Rendezvous functionality, and, thus, a client 2411 can register both to a RELAY_UDP_HIP and a RENDEZVOUS (see [RFC8004]) 2412 service from the same server. Potentially, this introduces a cross- 2413 protocol attack (or actually a "cross-message" attack) because the 2414 key material is the same for the Control Relay Service and Rendezvous 2415 HMACs. While the problem could be avoided by deriving different keys 2416 for the Control Relay Service, a more simple measure was chosen 2417 because the exact attack scenario was unclear. Consequently, this 2418 section defines a mandatory mitigation mechanism against the cross- 2419 protocol attack that works by preventing the simultanous use of 2420 Rendezvous and Control Relay Service in the context of a single HIP 2421 Association. 2423 The registration involves three parameters typically delivered 2424 sequentally in R1 (REG_INFO parameter), I2 (REG_REQUEST) and R2 2425 (REG_RESPONSE) messages but can also be delivered in UPDATE messages 2426 as described in [RFC8003]. The parameters and the modifications to 2427 their processing are described below: 2429 1. REG_INFO: the Control Relay Server advertizes its available 2430 services using this parameter. RELAY_UDP_HIP and RENDEZVOUS 2431 services MAY be included in the first advertizement for the HIP 2432 association but subsequent ones MUST include only one of them as 2433 agreed in earlier registrations (see steps 2 and 3). 2435 2. REG_REQUEST: the Control Relay Client chooses the services it 2436 requires using this parameter. If the Control Relay Server 2437 offered both RENDEZVOUS or RELAY_UDP_HIP, the Control Relay 2438 Client MUST choose only one of them in the REG_REQUEST parameter. 2439 Upon choosing one of of the two, it persists throughout the 2440 lifetime of the HIP association, and the Control Relay Client 2441 MUST NOT register the other remaining one in a subsequent UPDATE 2442 message. 2444 3. REG_RESPONSE: the Control Relay Server verifies the services 2445 requested by the Control Relay Client using this parameter. If 2446 the Control Relay Server offered both RENDEZVOUS and 2447 RELAY_UDP_HIP service, and the Control Relay Client requested for 2448 both of them, the Control Relay Client MUST offer only 2449 RELAY_UDP_HIP service in the REG_RESPONSE parameter and include a 2450 REG_FAILED parameter in the same message, with RENDEZVOUS as the 2451 Registration Type and [TBD by IANA: 9] as the Failure Type. 2453 As a further measure against cross-protocol attacks, Control Relay 2454 Client MUST drop any HIP message that includes an RVS_HMAC parameter 2455 when it originates from successfully registered Control Relay Server. 2456 Upon such an (unintended) event, the Control Relay Client MUST send a 2457 NOTIFY message with RVS_HMAC_PROHIBITED_WITH_RELAY as the Notify 2458 Message Type to the Control Relay Server. 2460 7. IANA Considerations 2462 This section is to be interpreted according to [RFC8126]. 2464 This document reuses the same default UDP port number 10500 as 2465 specified by Legacy ICE-HIP [RFC5770] for tunneling both HIP control 2466 plane and data plane traffic. The port was was registered separately 2467 for RFC5770 to co-author Ari Keranen but should now be re-assigned 2468 for IESG control. With the permission of Ari Keranen, the new 2469 assignee is IESG and contact "chair@ietf.org". In addition, IANA is 2470 requested to add a reference to this document in the entry for UDP 2471 port 10500 in the Transport Protocol Port Number Registry. The 2472 selection between Legacy ICE-HIP and Native ICE-HIP mode is 2473 negotiated using NAT_TRAVERSAL_MODE parameter during the base 2474 exchange. By default, hosts listen this port for incoming UDP 2475 datagrams and can use it also for sending UDP datagrams. Other 2476 emphemeral port numbers are negotiated and utilized dynamically. 2478 This document updates the IANA Registry for HIP Parameter Types 2479 [RFC7401] by assigning new HIP Parameter Type values for the new HIP 2480 Parameters: RELAYED_ADDRESS (length 20), MAPPED_ADDRESS (length 20, 2481 defined in Section 5.12), PEER_PERMISSION (length 48, defined in 2482 Section 5.13), CANDIDATE_PRIORITY (length 4, defined in Section 5.14) 2483 and NOMINATE (length 4, defined in Section 5.15). 2485 This document updates the IANA Registry for HIP NAT traversal modes 2486 specified in Legacy ICE-HIP [RFC5770] by assigning value for the NAT 2487 traversal mode ICE-HIP-UDP (defined in Section 5.4). 2489 This document updates the IANA Registry for HIP Notify Message Types: 2490 type field NAT_KEEPALIVE in Section 5.3, a new error type 2491 SERVER_REFLEXIVE_CANDIDATE_ALLOCATION_FAILED and 2492 RVS_HMAC_PROHIBITED_WITH_RELAY in Section 5.10. . 2494 This document defines additional registration types for the HIP 2495 Registration Extension [RFC8003] that allow registering with a Data 2496 Relay Server for ESP relaying service: RELAY_UDP_ESP (defined in 2497 Section 5.9, and performing server reflexive candidate discovery: 2498 CANDIDATE_DISCOVERY (defined in Section 4.2). 2500 This document defines an additional Registration Failure Type as 2501 defined in Section 6.8. The value is [TBD by IANA: 9] and the 2502 Registration Failure Type is "Simultaneous Rendezvous and Control 2503 Relay Service usage prohibited". 2505 ICE specification [RFC8445] discusses "Unilateral Self-Address 2506 Fixing" in section 18. This protocol is based on ICE, and thus the 2507 same considerations apply also here. 2509 8. Contributors 2511 Marcelo Bagnulo, Philip Matthews and Hannes Tschofenig have 2512 contributed to [RFC5770]. This document leans heavily on the work in 2513 the RFC. 2515 9. Acknowledgments 2517 Thanks to Jonathan Rosenberg, Christer Holmberg and the rest of the 2518 MMUSIC WG folks for the excellent work on ICE. The authors would 2519 like to thank also Andrei Gurtov, Simon Schuetz, Martin Stiemerling, 2520 Lars Eggert, Vivien Schmitt, and Abhinav Pathak for their 2521 contributions and Tobias Heer, Teemu Koponen, Juhana Mattila, Jeffrey 2522 M. Ahrenholz, Kristian Slavov, Janne Lindqvist, Pekka Nikander, 2523 Lauri Silvennoinen, Jukka Ylitalo, Juha Heinanen, Joakim Koskela, 2524 Samu Varjonen, Dan Wing, Tom Henderson, Alex Elsayed, Jani 2525 Hautakorpi, Tero Kauppinen and Timo Simanainen for their comments to 2526 [RFC5770] and this document. Thanks for Eric Vyncke, Alvaro Retana, 2527 Adam Roach, Ben Campbell, Eric Rescorla, Mirja Kuhlewind, Spencer 2528 Dawkins, Derek Fawcus, Tianran Zhou, Amanda Barber, Colin Perkins, 2529 Roni Even, Alissa Cooper, Carl Wallace, Martin Duke and Benjamin 2530 Kaduk for reviewing this document. 2532 This work has been partially funded by CyberTrust programme by 2533 Digile/Tekes in Finland. 2535 10. References 2537 10.1. Normative References 2539 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2540 Requirement Levels", BCP 14, RFC 2119, 2541 DOI 10.17487/RFC2119, March 1997, 2542 . 2544 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2545 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2546 May 2017, . 2548 [RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T. 2549 Henderson, "Host Identity Protocol Version 2 (HIPv2)", 2550 RFC 7401, DOI 10.17487/RFC7401, April 2015, 2551 . 2553 [RFC8003] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) 2554 Registration Extension", RFC 8003, DOI 10.17487/RFC8003, 2555 October 2016, . 2557 [RFC8004] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) 2558 Rendezvous Extension", RFC 8004, DOI 10.17487/RFC8004, 2559 October 2016, . 2561 [RFC8046] Henderson, T., Ed., Vogt, C., and J. Arkko, "Host Mobility 2562 with the Host Identity Protocol", RFC 8046, 2563 DOI 10.17487/RFC8046, February 2017, 2564 . 2566 [RFC8047] Henderson, T., Ed., Vogt, C., and J. Arkko, "Host 2567 Multihoming with the Host Identity Protocol", RFC 8047, 2568 DOI 10.17487/RFC8047, February 2017, 2569 . 2571 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 2572 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 2573 DOI 10.17487/RFC5389, October 2008, 2574 . 2576 [RFC7402] Jokela, P., Moskowitz, R., and J. Melen, "Using the 2577 Encapsulating Security Payload (ESP) Transport Format with 2578 the Host Identity Protocol (HIP)", RFC 7402, 2579 DOI 10.17487/RFC7402, April 2015, 2580 . 2582 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 2583 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 2584 2006, . 2586 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 2587 Writing an IANA Considerations Section in RFCs", BCP 26, 2588 RFC 8126, DOI 10.17487/RFC8126, June 2017, 2589 . 2591 [RFC8445] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive 2592 Connectivity Establishment (ICE): A Protocol for Network 2593 Address Translator (NAT) Traversal", RFC 8445, 2594 DOI 10.17487/RFC8445, July 2018, 2595 . 2597 [RFC7050] Savolainen, T., Korhonen, J., and D. Wing, "Discovery of 2598 the IPv6 Prefix Used for IPv6 Address Synthesis", 2599 RFC 7050, DOI 10.17487/RFC7050, November 2013, 2600 . 2602 [RFC8005] Laganier, J., "Host Identity Protocol (HIP) Domain Name 2603 System (DNS) Extension", RFC 8005, DOI 10.17487/RFC8005, 2604 October 2016, . 2606 [RFC1063] Mogul, J., Kent, C., Partridge, C., and K. McCloghrie, "IP 2607 MTU discovery options", RFC 1063, DOI 10.17487/RFC1063, 2608 July 1988, . 2610 [RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed., 2611 "Path MTU Discovery for IP version 6", STD 87, RFC 8201, 2612 DOI 10.17487/RFC8201, July 2017, 2613 . 2615 [RFC5770] Komu, M., Henderson, T., Tschofenig, H., Melen, J., and A. 2616 Keranen, Ed., "Basic Host Identity Protocol (HIP) 2617 Extensions for Traversal of Network Address Translators", 2618 RFC 5770, DOI 10.17487/RFC5770, April 2010, 2619 . 2621 [I-D.ietf-tcpm-rto-consider] 2622 Allman, M., "Requirements for Time-Based Loss Detection", 2623 draft-ietf-tcpm-rto-consider-16 (work in progress), June 2624 2020. 2626 10.2. Informative References 2628 [I-D.ietf-hip-rfc4423-bis] 2629 Moskowitz, R. and M. Komu, "Host Identity Protocol 2630 Architecture", draft-ietf-hip-rfc4423-bis-20 (work in 2631 progress), February 2019. 2633 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 2634 and W. Weiss, "An Architecture for Differentiated 2635 Services", RFC 2475, DOI 10.17487/RFC2475, December 1998, 2636 . 2638 [RFC5207] Stiemerling, M., Quittek, J., and L. Eggert, "NAT and 2639 Firewall Traversal Issues of Host Identity Protocol (HIP) 2640 Communication", RFC 5207, DOI 10.17487/RFC5207, April 2641 2008, . 2643 [I-D.rosenberg-mmusic-ice-nonsip] 2644 Rosenberg, J., "Guidelines for Usage of Interactive 2645 Connectivity Establishment (ICE) by non Session Initiation 2646 Protocol (SIP) Protocols", draft-rosenberg-mmusic-ice- 2647 nonsip-01 (work in progress), July 2008. 2649 [RFC6538] Henderson, T. and A. Gurtov, "The Host Identity Protocol 2650 (HIP) Experiment Report", RFC 6538, DOI 10.17487/RFC6538, 2651 March 2012, . 2653 [RFC5128] Srisuresh, P., Ford, B., and D. Kegel, "State of Peer-to- 2654 Peer (P2P) Communication across Network Address 2655 Translators (NATs)", RFC 5128, DOI 10.17487/RFC5128, March 2656 2008, . 2658 [I-D.heer-hip-middle-auth] 2659 Heer, T., Hummen, R., and M. Komu, "End-Host 2660 Authentication for HIP Middleboxes", draft-heer-hip- 2661 middle-auth-04 (work in progress), October 2011. 2663 [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. 2664 Stenberg, "UDP Encapsulation of IPsec ESP Packets", 2665 RFC 3948, DOI 10.17487/RFC3948, January 2005, 2666 . 2668 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 2669 with Session Description Protocol (SDP)", RFC 3264, 2670 DOI 10.17487/RFC3264, June 2002, 2671 . 2673 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 2674 (ICE): A Protocol for Network Address Translator (NAT) 2675 Traversal for Offer/Answer Protocols", RFC 5245, 2676 DOI 10.17487/RFC5245, April 2010, 2677 . 2679 [RFC8750] Migault, D., Guggemos, T., and Y. Nir, "Implicit 2680 Initialization Vector (IV) for Counter-Based Ciphers in 2681 Encapsulating Security Payload (ESP)", RFC 8750, 2682 DOI 10.17487/RFC8750, March 2020, 2683 . 2685 [I-D.ietf-tsvwg-datagram-plpmtud] 2686 Fairhurst, G., Jones, T., Tuexen, M., Ruengeler, I., and 2687 T. Voelker, "Packetization Layer Path MTU Discovery for 2688 Datagram Transports", draft-ietf-tsvwg-datagram-plpmtud-22 2689 (work in progress), June 2020. 2691 [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using 2692 Relays around NAT (TURN): Relay Extensions to Session 2693 Traversal Utilities for NAT (STUN)", RFC 5766, 2694 DOI 10.17487/RFC5766, April 2010, 2695 . 2697 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 2698 NAT64: Network Address and Protocol Translation from IPv6 2699 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, 2700 April 2011, . 2702 [RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van 2703 Beijnum, "DNS64: DNS Extensions for Network Address 2704 Translation from IPv6 Clients to IPv4 Servers", RFC 6147, 2705 DOI 10.17487/RFC6147, April 2011, 2706 . 2708 Appendix A. Selecting a Value for Check Pacing 2710 Selecting a suitable value for the connectivity check transaction 2711 pacing is essential for the performance of connectivity check-based 2712 NAT traversal. The value should not be so small that the checks 2713 cause network congestion or overwhelm the NATs. On the other hand, a 2714 pacing value that is too high makes the checks last for a long time, 2715 thus increasing the connection setup delay. 2717 The Ta value may be configured by the user in environments where the 2718 network characteristics are known beforehand. However, if the 2719 characteristics are not known, it is recommended that the value is 2720 adjusted dynamically. In this case, it is recommended that the hosts 2721 estimate the round-trip time (RTT) between them and SHOULD set the 2722 minimum Ta value so that at most a single connectivity check message 2723 is sent on every RTT. 2725 One way to estimate the RTT is to use the time that it takes for the 2726 Control Relay Server registration exchange to complete; this would 2727 give an estimate on the registering host's access link's RTT. Also, 2728 the I1/R1 exchange could be used for estimating the RTT, but since 2729 the R1 can be cached in the network, or the relaying service can 2730 increase the delay notably, this is not recommended. In general, 2731 estimating RTT can be difficult and error prone, thus the guidelines 2732 for choosing a Ta value in Section 4.4 MUST be followed. 2734 Appendix B. Differences with respect to ICE 2736 Legacy ICE-HIP reuses ICE/STUN/TURN protocol stack as it is. The 2737 benefits of such as an approach include the reuse of STUN/TURN 2738 infrastructure and possibly the reuse of existing software libraries, 2739 but there are also drawbacks with the approach. For example, ICE is 2740 meant for application-layer protocols, whereas HIP operates at layer 2741 3.5 between transport and network layers. This is particularly 2742 problematic because the implementations employ kernelspace IPsec ESP 2743 as their data plane: demultiplexing of incoming ESP, HIP and TURN 2744 messages required capturing of all UDP packets destined to port 10500 2745 to the userspace (due to different, incompatible markers in ESP and 2746 STUN), thus causing additional software complexity and an unnecessary 2747 latency/throughput bottleneck for the dataplane performance. It is 2748 also worth noting that demultiplexing of STUN packets in the kernel 2749 would incur an also a performance impact (albeit smaller than with 2750 userspace demultiplexing), and secure verification of STUN messages 2751 would require communication between the kernelspace STUN detector and 2752 HIP daemon typically residing in the userspace (thus, again 2753 increasing the performance overhead). 2755 Legacy ICE-HIP involves also some other complexities when compared to 2756 the approach taken in this document. Relaying of ESP packets via 2757 TURN relays was not considered that simple because TURN relays 2758 require adding and removing extra TURN framing for the relayed 2759 packets. Finally, the developers of the two Legacy ICE-HIP 2760 implementations concluded that "effort needed for integrating an ICE 2761 library into a HIP implementation turned out to be quite a bit higher 2762 that initially estimated. Also, the amount of extra code (some 10 2763 kLoC) needed for all the new parsers, state machines, etc., is quite 2764 high and by re-using the HIP code one should be able to do with much 2765 less. This should result in smaller binary size, less bugs, and 2766 easier debugging.". Consequently, the HIP working group decided to 2767 follow ICE methodology but reuse HIP messaging format to achieve the 2768 same functionality as ICE, and consequently the result is this 2769 document that specifies the Native ICE-HIP protocol. 2771 The Native ICE-HIP protocol specified in this document follows the 2772 semantics of ICE as close as possible, and most of the differences 2773 are syntactical due to the use of a different protocol. In this 2774 section, we describe the differences to the ICE protocol. 2776 o ICE operates at the application layer, whereas this protocol 2777 operates between transport and network layers, thus hiding the 2778 protocol details from the application. 2780 o The STUN protocol is not employed. Instead, native ICE-HIP reuses 2781 the HIP control plane format in order simplify demultiplexing of 2782 different protocols. For example, the STUN binding response is 2783 replaced with a HIP UPDATE message containing an 2784 ECHO_REQUEST_SIGNED parameter and the STUN binding response with a 2785 HIP UPDATE message containing an ECHO_RESPONSE_SIGNED parameter as 2786 defined in Section 4.6. It is worth noting that a drawback of not 2787 employing STUN is that discovery of the address candidates 2788 requires creating (using HIP base exchange) and maintaining (using 2789 HIP UPDATE procedures) state at the Control Relay Client and 2790 Control Relay Server. Future extensions to this document may 2791 define a stateless, HIP-specific mechanism for an end-host to 2792 discover its address candidates. 2794 o The TURN protocol is not utilized. Instead, native ICE-HIP reuses 2795 Control Relay Servers for the same purpose. 2797 o ICMP errors may be used in ICE to signal failure. In Native ICE- 2798 HIP protocol, HIP NOTIFY messages are used instead. 2800 o Instead of the ICE username fragment and password mechanism for 2801 credentials, native ICE-HIP uses the HIT, derived from a public 2802 key, for the same purpose. The username fragments are "transient 2803 host identifiers, bound to a particular session established as 2804 part of the candidate exchange" [RFC8445]. Generally in HIP, a 2805 local public key and the derived HIT are considered long-term 2806 identifiers, and invariant across different host associations and 2807 different transport-layer flows. 2809 o In ICE, the conflict when two communicating end-points take the 2810 same controlling role is solved using random values (so called 2811 tie-breaker value). In Native ICE-HIP protocol, the conflict is 2812 solved by the standard HIP base exchange procedure, where the host 2813 with the "larger" HIT switches to Responder role, thus changing 2814 also to controlled role. 2816 o The ICE-CONTROLLED and ICE-CONTROLLING attributes are not included 2817 in the connectivity checks. 2819 o The foundation concept is unnecessary in native ICE-HIP because 2820 only a single UDP flow for the IPsec tunnel will be negotiated. 2822 o Frozen candidates are omitted for the same reason as foundation 2823 concept is excluded. 2825 o Components are omitted for the same reason as foundation concept 2826 is excluded. 2828 o Native ICE-HIP supports only "full ICE" where the two 2829 communicating hosts participate actively to the connectivity 2830 checks, and the "lite" mode is not supported. This design 2831 decision follows the guidelines of ICE which recommends full ICE 2832 implementations. However, it should be noted that a publicly 2833 reachable Responder may refuse to negotiate the ICE mode as 2834 described in Section 4.7.2. This would result in a [RFC7401] 2835 based HIP base exchange tunneled over UDP followed ESP traffic 2836 over the same tunnel, without the connectivity check procedures 2837 defined in this document (in some sense, this mode corresponds to 2838 the case where two ICE lite implementations connect since no 2839 connectivity checks are sent). 2841 o As the "ICE lite" is not adopted here and both sides are capable 2842 of ICE-HIP-UDP mode (negotiated during the base exchange), default 2843 candidates are not employed in Native ICE-HIP. 2845 o If the agent is using Diffserv Codepoint markings [RFC2475] in its 2846 media packets, it SHOULD apply those same markings to its 2847 connectivity checks. 2849 o Unlike in ICE, the addresses are not XOR-ed in Native ICE-HIP 2850 protocol but rather encrypted to avoid middlebox tampering. 2852 o Native ICE-HIP protocol does not employ the ICE related address 2853 and related port attributes (that are used for diagnostic or SIP 2854 purposes). 2856 o Minimum RTO is 500 ms in ICE but 1000 ms in Native ICE-HIP 2857 protocol in favor of [I-D.ietf-tcpm-rto-consider] 2859 Appendix C. Differences to Base Exchange and UPDATE procedures 2861 This section gives some design guidance for implementers how the 2862 extensions in this protocol extend and differ from [RFC7401] and 2863 [RFC8046]. 2865 o Both control and data plane are operated on top of UDP, not 2866 directly on IP. 2868 o A minimal implementation would conform only to Section 4.7.1 or 2869 Section 4.7.2, thus merely tunneling HIP control and data traffic 2870 over UDP. The drawback here is that it works only in the limited 2871 cases where the Responder has a public address. 2873 o It is worth noting that while a rendezvous server [RFC8004] has 2874 not been designed to be used in NATted scenarios because it just 2875 relays the first I1 packet and does not employ UDP encapsulation, 2876 the Control Relay Server forwards all control traffic and, hence, 2877 is more suitable in NATted environments. Further, the Data Relay 2878 Server guarantees forwarding of data plane traffic also in the 2879 cases when the NAT traversal procedures fail. 2881 o Registration procedures with a Control/Data Relay Server are 2882 similar as with rendezvous server. However, a Control/Data Relay 2883 Server has different registration parameters than rendezvous 2884 because it offers a different service. Also, the Control/Data 2885 Relay Server includes also a REG_FROM parameter that informs the 2886 Control/Data Relay Client about its server reflexive address. A 2887 Data Relay Server includes also a RELAYED_ADDRESS containing the 2888 relayed address for the Data Relay Client. 2890 o In [RFC7401], the Initiator and Responder can start to exchange 2891 application payload immediately after the base exchange. While 2892 exchanging data immediately after a base exchange via a Data 2893 Control Relay would be possible also here, we follow the ICE 2894 methodology to establish a direct path between two hosts using 2895 connectivity checks. This means that there will be some 2896 additional delay after the base exchange before application 2897 payload can be transmitted. The same applies for the UPDATE 2898 procedure as the connectivity checks introduce some additional 2899 delay. 2901 o In HIP without any NAT traversal support, the base exchange acts 2902 as an implicit connectivity check, and the mobility and 2903 multihoming extensions support explicit connectivity checks. 2904 After a base exchange or UPDATE based connectivity checks, a host 2905 can use the associated address pair for transmitting application 2906 payload. In this Native ICE-HIP extension, we follow the ICE 2907 methodology, where one end-point acting in the controlled role 2908 chooses the used address pair also on behalf of the other end- 2909 point acting in controlled role, which is different from HIP 2910 without NAT traversal support. Another difference is that the 2911 process of choosing an address pair is explicitly signaled using 2912 the nomination packets. The nomination process in this protocol 2913 supports only single address pair, and multihoming extensions are 2914 left for further study. 2916 o The UPDATE procedure resembles the mobility extensions defined in 2917 [RFC8046]. The first UPDATE message from the mobile host is 2918 exactly the same as in the mobility extensions. The second UPDATE 2919 message from the peer host and third from the mobile host are 2920 different in the sense that they merely acknowledge and conclude 2921 the reception of the candidates through the Control Relay Server. 2922 In other words, they do not yet test for connectivity (besides 2923 reachability through the Control Relay Server) unlike in the 2924 mobility extensions. The idea is that connectivity check 2925 procedure follows the ICE specification, which is somewhat 2926 different from the HIP mobility extensions. 2928 o The connectivity checks as defined in the mobility extensions 2929 [RFC8046] are triggered only by the peer of the mobile host. 2930 Since successful NAT traversal requires that both end-points test 2931 connectivity, both the mobile host and its peer host have to test 2932 for connectivity. In addition, this protocol validates also the 2933 UDP ports; the ports in the connectivity check must match with the 2934 response, as required by ICE. 2936 o In HIP mobility extensions [RFC8046], an outbound locator has some 2937 associated state: UNVERIFIED mean that the locator has not been 2938 tested for reachability, ACTIVE means that the address has been 2939 verified for reachability and is being used actively, and 2940 DEPRECATED means that the locator lifetime has expired. In the 2941 subset of ICE specifications used by this protocol, an individual 2942 address candidate has only two properties: type and priority. 2943 Instead, the actual state in ICE is associated with candidate 2944 pairs rather than individual addresses. The subset of ICE 2945 specifications utilized by this protocol require the following 2946 attributes for a candidate pair: valid bit, nominated bit, base 2947 and the state of connectivity check. The connectivity checks have 2948 the following states: Waiting, In-progress, Succeeded and Failed. 2950 Handling of this state attribute requires some additional logic 2951 when compared to the mobility extensions since the state is 2952 associated with a local-remote address pair rather just a remote 2953 address, and, thus, the mobility and ICE states do not have an 2954 unambiguous one-to-one mapping. 2956 o Credit-based authorization as defined in [RFC8046] could be used 2957 before candidate nomination has been concluded upon discovering 2958 working candidate pairs. However, this may result in the use of 2959 asymmetric paths for a short time period in the beginning of 2960 communications. Thus, support of credit-based authorization is 2961 left for further study. 2963 Appendix D. Multihoming Considerations 2965 This document allows a host to collect address candidates from 2966 multiple interfaces, but does not support activation and the 2967 simultaneous use of multiple address candidates. While multihoming 2968 extensions to support [RFC8047] like functionality are left for 2969 further study and experimentation, we envision here some potential 2970 compatibility improvements to support multihoming: 2972 o Data Relay Registration: a Data Relay Client acting as an 2973 Initiator with another peer host should register a new server 2974 reflexive candidate for each local transport address candidate. A 2975 Data Relay Client acting as an Responder should register a new 2976 server reflexive candidate for each { local transport address 2977 candidate, new peer host} pair for the reasons described in 2978 Section 4.12.3. In both cases, the Data Relay Client should 2979 request the additional server reflexive candidates by sending 2980 UPDATE messages originating from each of the local address 2981 candidates as described in Section 4.1. As the UPDATE messages 2982 are originating from an unknown location from the viewpoint of the 2983 Data Relay Server, it must include also a ECHO_REQUEST_SIGNED in 2984 the response in order to test for return routability. 2986 o Data Relay unregistration: this follows the procedure in Section 4 2987 but the Data Relay Client should unregister using the particular 2988 transport address to be unregistered. All transport address pair 2989 registrations can be unregistered when no RELAYED_ADDRESS 2990 parameter is included. 2992 o PEER_PERMISSION parameter: this needs to be extended or an 2993 additional parameter is needed to declare the specific local 2994 candidate of the Data Relay Client. Alternatively, the use of the 2995 PEER_PERMISSION could be used as a wild card to open permissions 2996 for a specific peer to all of the candidates of the Data Relay 2997 Client. 2999 o Connectivity checks: the controlling host should be able to 3000 nominate multiple candidates (by repeating step 7 in Figure 5 in 3001 Section 4.6 using the additional candidate pairs). 3003 o Keepalives should be sent for all the nominated candidate pairs. 3004 Similarly, the Control/Data Relay Client should send keepalives 3005 from its local candidates to its Control/Data Relay Server 3006 transport addresses. 3008 Appendix E. DNS Considerations 3010 This section updates [RFC5770] Appendix B which will be replaced with 3011 the mechanism described in this section. 3013 [RFC5770] did not specify how an end-host can look up another end- 3014 host via DNS and initiate an UDP-based HIP base exchange with it, so 3015 this section makes an attempt to fill this gap. 3017 [RFC8005] specifies how a HIP end-host and its Rendezvous server is 3018 registered to DNS. Essentially, the public key of the end-host is 3019 stored as HI record and its Rendezvous Server as A or AAAA record. 3020 This way, the Rendezvous Server can act as an intermediary for the 3021 end-host and forward packets to it based on the DNS configuration. 3022 Control Relay Server offers similar functionality as Rendezvous 3023 Server, with the difference that the Control Relay Server forwards 3024 all control messages, not just the first I1 message. 3026 Prior to this document, the A and AAAA records in the DNS refer 3027 either to the HIP end-host itself or a Rendezvous Server [RFC8005], 3028 and control and data plane communication with the associated host has 3029 been assumed to occur directly over IPv4 or IPv6. However, this 3030 specification extends the records to be used for UDP-based 3031 communications. 3033 Let us consider the case of a HIP Initiator with the default policy 3034 to employ UDP encapsulation and the extensions defined in this 3035 document. The Initiator looks up the FQDN of a Responder, and 3036 retrieves its HI, A and AAAA records. Since the default policy is to 3037 use UDP encapsulation, the Initiator MUST send the I1 message over 3038 UDP to destination port 10500 (either over IPv4 in the case of a A 3039 record or over IPv6 in the case of a AAAA record). It MAY send an I1 3040 message both with and without UDP encapsulation in parallel. In the 3041 case the Initiator receives R1 messages both with and without UDP 3042 encapsulation from the Responder, the Initiator SHOULD ignore the R1 3043 messages without UDP encapsulation. 3045 The UDP encapsulated I1 packet could be received by three different 3046 types of hosts: 3048 1. HIP Control Relay Server: in this case the A/AAAA records refers 3049 to a Control Relay Server, and it will forward the packet to the 3050 corresponding Control Relay Client based on the destination HIT 3051 in the I1 packet. 3053 2. HIP Responder supporting UDP encapsulation: in this case, the A/ 3054 AAAA records refers to the end-host. Assuming the destination 3055 HIT belongs to the Responder, it receives and processes it 3056 according to the negotiated NAT traversal mechanism. The support 3057 for the protocol defined in this document vs [RFC5770] is 3058 dynamically negotiated during the base exchange. The details are 3059 specified in Section 4.3. 3061 3. HIP Rendezvous Server: this entity is not listening to UDP port 3062 10500, so it will drop the I1 message. 3064 4. HIP Responder not supporting UDP encapsulation: the targeted end- 3065 host is not listening to UDP port 10500, so it will drop the I1 3066 message. 3068 The A/AAAA-record MUST NOT be configured to refer to a Data Relay 3069 Server unless the host in question supports also Control Relay Server 3070 functionality. 3072 It also worth noting that SRV records are not employed in this 3073 specification. While they could be used for more flexible UDP port 3074 selection, they are not suitable for end-host discovery but rather 3075 would be more suitable for the discovery of HIP-specific 3076 infrastructure. Further extensions to this document may define SRV 3077 records for Control and Data Relay Server discovery within a DNS 3078 domain. 3080 Authors' Addresses 3082 Ari Keranen 3083 Ericsson 3084 Hirsalantie 11 3085 02420 Jorvas 3086 Finland 3088 Email: ari.keranen@ericsson.com 3089 Jan Melen 3090 Ericsson 3091 Hirsalantie 11 3092 02420 Jorvas 3093 Finland 3095 Email: jan.melen@ericsson.com 3097 Miika Komu (editor) 3098 Ericsson 3099 Hirsalantie 11 3100 02420 Jorvas 3101 Finland 3103 Email: miika.komu@ericsson.com