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