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