idnits 2.17.1 draft-ietf-hip-native-nat-traversal-11.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 1411 has weird spacing: '...eserved zero...' == Line 1447 has weird spacing: '... Min Ta the ...' == Line 1478 has weird spacing: '...eserved rese...' == Line 1480 has weird spacing: '...Address an ...' == Line 1667 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 (June 15, 2016) is 2871 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 341, but not defined ** Obsolete normative reference: RFC 4423 (Obsoleted by RFC 9063) == Outdated reference: A later version (-11) exists of draft-ietf-hip-rfc5203-bis-10 == Outdated reference: A later version (-08) exists of draft-ietf-hip-rfc5204-bis-07 == Outdated reference: A later version (-14) exists of draft-ietf-hip-rfc5206-bis-12 ** Obsolete normative reference: RFC 5245 (Obsoleted by RFC 8445, RFC 8839) ** Obsolete normative reference: RFC 5766 (Obsoleted by RFC 8656) ** 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) -- Obsolete informational reference (is this intentional?): RFC 5201 (Obsoleted by RFC 7401) Summary: 6 errors (**), 0 flaws (~~), 12 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 HIP Working Group A. Keranen 3 Internet-Draft J. Melen 4 Intended status: Standards Track M. Komu, Ed. 5 Expires: December 17, 2016 Ericsson 6 June 15, 2016 8 Native NAT Traversal Mode for the Host Identity Protocol 9 draft-ietf-hip-native-nat-traversal-11 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 December 17, 2016. 37 Copyright Notice 39 Copyright (c) 2016 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 . . . . . . . . . . . . . . . . . . . . 5 57 4. Protocol Description . . . . . . . . . . . . . . . . . . . . 7 58 4.1. Relay Registration . . . . . . . . . . . . . . . . . . . 7 59 4.2. Transport Address Candidate Gathering . . . . . . . . . . 9 60 4.3. NAT Traversal Mode Negotiation . . . . . . . . . . . . . 10 61 4.4. Connectivity Check Pacing Negotiation . . . . . . . . . . 11 62 4.5. Base Exchange via HIP Relay Server . . . . . . . . . . . 12 63 4.6. Connectivity Checks . . . . . . . . . . . . . . . . . . . 15 64 4.6.1. Aggressive Connectivity Checks . . . . . . . . . . . 15 65 4.6.2. Normal Connectivity Checks . . . . . . . . . . . . . 18 66 4.6.3. Rules for Connectivity Checks . . . . . . . . . . . . 20 67 4.7. NAT Traversal Alternatives . . . . . . . . . . . . . . . 22 68 4.7.1. Minimal NAT Traversal Support . . . . . . . . . . . . 22 69 4.7.2. Base Exchange without Connectivity Checks . . . . . . 22 70 4.7.3. Initiating a Base Exchange both with and without UDP 71 Encapsulation . . . . . . . . . . . . . . . . . . . . 23 72 4.8. Sending Control Packets after the Base Exchange . . . . . 24 73 4.9. Mobility Handover Procedure . . . . . . . . . . . . . . . 24 74 4.10. NAT Keepalives . . . . . . . . . . . . . . . . . . . . . 27 75 4.11. Close Procedure . . . . . . . . . . . . . . . . . . . . . 28 76 4.12. Relaying Considerations . . . . . . . . . . . . . . . . . 28 77 4.12.1. Forwarding Rules and Permissions . . . . . . . . . . 28 78 4.12.2. Relaying UDP Encapsulated Data and Control Packets . 29 79 4.12.3. Handling Conflicting SPI Values . . . . . . . . . . 29 80 5. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 30 81 5.1. HIP Control Packets . . . . . . . . . . . . . . . . . . . 30 82 5.2. Connectivity Checks . . . . . . . . . . . . . . . . . . . 31 83 5.3. Keepalives . . . . . . . . . . . . . . . . . . . . . . . 31 84 5.4. NAT Traversal Mode Parameter . . . . . . . . . . . . . . 31 85 5.5. Connectivity Check Transaction Pacing Parameter . . . . . 32 86 5.6. Relay and Registration Parameters . . . . . . . . . . . . 33 87 5.7. LOCATOR_SET Parameter . . . . . . . . . . . . . . . . . . 34 88 5.8. RELAY_HMAC Parameter . . . . . . . . . . . . . . . . . . 35 89 5.9. Registration Types . . . . . . . . . . . . . . . . . . . 36 90 5.10. Notify Packet Types . . . . . . . . . . . . . . . . . . . 36 91 5.11. ESP Data Packets . . . . . . . . . . . . . . . . . . . . 36 92 5.12. RELAYED_ADDRESS and MAPPED_ADDRESS Parameters . . . . . . 37 93 5.13. PEER_PERMISSION Parameter . . . . . . . . . . . . . . . . 38 94 5.14. HIP Connectivity Check Packets . . . . . . . . . . . . . 39 95 5.15. NOMINATE parameter . . . . . . . . . . . . . . . . . . . 39 96 6. Security Considerations . . . . . . . . . . . . . . . . . . . 39 97 6.1. Privacy Considerations . . . . . . . . . . . . . . . . . 40 98 6.2. Opportunistic Mode . . . . . . . . . . . . . . . . . . . 40 99 6.3. Base Exchange Replay Protection for HIP Relay Server . . 40 100 6.4. Demuxing Different HIP Associations . . . . . . . . . . . 41 101 6.5. Reuse of Ports at the Data Relay . . . . . . . . . . . . 41 102 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41 103 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 42 104 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 42 105 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 42 106 10.1. Normative References . . . . . . . . . . . . . . . . . . 42 107 10.2. Informative References . . . . . . . . . . . . . . . . . 44 108 Appendix A. Selecting a Value for Check Pacing . . . . . . . . . 44 109 Appendix B. Base Exchange through a Rendezvous Server . . . . . 45 110 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 45 112 1. Introduction 114 The Host Identity Protocol (HIP) [RFC7401] is specified to run 115 directly on top of IPv4 or IPv6. However, many middleboxes found in 116 the Internet, such as NATs and firewalls, often allow only UDP or TCP 117 traffic to pass [RFC5207]. Also, especially NATs usually require the 118 host behind a NAT to create a forwarding state in the NAT before 119 other hosts outside of the NAT can contact the host behind the NAT. 120 To overcome this problem, different methods, commonly referred to as 121 NAT traversal techniques, have been developed. 123 Two NAT traversal techniques for HIP are specified in [RFC5770]. One 124 of them uses only UDP encapsulation, while the other uses also the 125 Interactive Connectivity Establishment (ICE) [RFC5245] protocol, 126 which in turn uses Session Traversal Utilities for NAT (STUN) 127 [RFC5389] and Traversal Using Relays around NAT (TURN) [RFC5766] 128 protocols to achieve a reliable NAT traversal solution. 130 The benefit of using ICE and STUN/TURN is that one can re-use the NAT 131 traversal infrastructure already available in the Internet, such as 132 STUN and TURN servers. Also, some middleboxes may be STUN-aware and 133 could be able to do something "smart" when they see STUN being used 134 for NAT traversal. However, implementing a full ICE/STUN/TURN 135 protocol stack results in a considerable amount of effort and code 136 which could be avoided by re-using and extending HIP messages and 137 state machines for the same purpose. Thus, this document specifies 138 an alternative NAT traversal mode that uses HIP messages instead of 139 STUN for the connectivity checks, keepalives, and data relaying. 140 This document also specifies how mobility management works in the 141 context of NAT traversal, which was missing from [RFC5770]. 143 2. Terminology 145 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 146 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 147 document are to be interpreted as described in [RFC2119]. 149 This document borrows terminology from [RFC5770], [RFC7401], 150 [I-D.ietf-hip-rfc5206-bis], [RFC4423], [RFC5245], and [RFC5389]. The 151 following terms recur in the text: 153 HIP relay server: 154 A host that forwards any kind of HIP control packets between the 155 Initiator and the Responder. 157 HIP data relay: 158 A host that forwards HIP data packets, such as Encapsulating 159 Security Payload (ESP) [RFC7402], between two hosts. 161 Registered host: 162 A host that has registered for a relaying service with a HIP data 163 relay. 165 Locator: 166 As defined in [I-D.ietf-hip-rfc5206-bis]: "A name that controls 167 how the packet is routed through the network and demultiplexed by 168 the end-host. It may include a concatenation of traditional 169 network addresses such as an IPv6 address and end-to-end 170 identifiers such as an ESP SPI. It may also include transport 171 port numbers or IPv6 Flow Labels as demultiplexing context, or it 172 may simply be a network address." 174 LOCATOR_SET (written in capital letters): 175 Denotes a HIP control packet parameter that bundles multiple 176 locators together. 178 ICE offer: 179 The Initiator's LOCATOR_SET parameter in a HIP I2 control packet. 180 Corresponds to the ICE offer parameter, but is HIP specific. 182 ICE answer: 183 The Responder's LOCATOR_SET parameter in a HIP R2 control packet. 184 Corresponds to the ICE answer parameter, but is HIP specific. 186 HIP connectivity checks: 187 In order to obtain a non-relayed communication path, two 188 communicating HIP hosts try to "punch holes" through their NAT 189 boxes using this mechanism. Similar to the ICE connectivity 190 checks, but implemented using HIP return routability checks. 192 Controlling host : 193 The controlling host nominates the candidate pair to be used with 194 the controlled host. 196 Controlled host : 197 The controlled host waits for the controlling to nominate an 198 address candidate pair. 200 Checklist: 201 A list of address candidate pairs that need to be tested for 202 connectivity. 204 Transport address: 205 Transport layer port and the corresponding IPv4/v6 address. 207 Candidate: 208 A transport address that is a potential point of contact for 209 receiving data. 211 Host candidate: 212 A candidate obtained by binding to a specific port from an IP 213 address on the host. 215 Server reflexive candidate: 216 A translated transport address of a host as observed by a HIP 217 relay server or a STUN/TURN server. 219 Peer reflexive candidate: 220 A translated transport address of a host as observed by its peer. 222 Relayed candidate: 223 A transport address that exists on a HIP data relay. Packets that 224 arrive at this address are relayed towards the registered host. 226 3. Overview of Operation 227 +-------+ 228 | HIP | 229 +--------+ | Relay | +--------+ 230 | Data | +-------+ | Data | 231 | Relay | / \ | Relay | 232 +--------+ / \ +--------+ 233 / \ 234 / \ 235 / \ 236 / <- Signaling -> \ 237 / \ 238 +-------+ +-------+ 239 | NAT | | NAT | 240 +-------+ +-------+ 241 / \ 242 / \ 243 +-------+ +-------+ 244 | Init- | | Resp- | 245 | iator | | onder | 246 +-------+ +-------+ 248 Figure 1: Example Network Configuration 250 In the example configuration depicted in Figure 1, both Initiator and 251 Responder are behind one or more NATs, and both private networks are 252 connected to the public Internet. To be contacted from behind a NAT, 253 the Responder must be registered with a HIP relay server reachable on 254 the public Internet, and we assume, as a starting point, that the 255 Initiator knows both the Responder's Host Identity Tag (HIT) and the 256 address of one of its relay servers (how the Initiator learns of the 257 Responder's relay server is outside of the scope of this document, 258 but may be through DNS or another name service). 260 The first steps are for both the Initiator and Responder to register 261 with a relay server (need not be the same one) and gather a set of 262 address candidates. The hosts may use HIP relay servers (or even 263 STUN or TURN servers) for gathering the candidates. Next, the HIP 264 base exchange is carried out by encapsulating the HIP control packets 265 in UDP datagrams and sending them through the Responder's relay 266 server. As part of the base exchange, each HIP host learns of the 267 peer's candidate addresses through the HIP offer/answer procedure 268 embedded in the base exchange, which follows closely the ICE 269 [RFC5245] protocol. 271 Once the base exchange is completed, two HIP hosts have established a 272 working communication session (for signaling) via a HIP relay server, 273 but the hosts still have to find a better path, preferably without a 274 HIP data relay, for the ESP data flow. For this, connectivity checks 275 are carried out until a working pair of addresses is discovered. At 276 the end of the procedure, if successful, the hosts will have 277 established a UDP-based tunnel that traverses both NATs, with the 278 data flowing directly from NAT to NAT or via a HIP data relay server. 279 At this point, also the HIP signaling can be sent over the same 280 address/port pair, and is demultiplexed from IPsec as described in 281 the UDP encapsulation standard for IPsec [RFC3948] Finally, the two 282 hosts send NAT keepalives as needed in order keep their UDP-tunnel 283 state active in the associated NAT boxes. 285 If either one of the hosts knows that it is not behind a NAT, hosts 286 can negotiate during the base exchange a different mode of NAT 287 traversal that does not use HIP connectivity checks, but only UDP 288 encapsulation of HIP and ESP. Also, it is possible for the Initiator 289 to simultaneously try a base exchange with and without UDP 290 encapsulation. If a base exchange without UDP encapsulation 291 succeeds, no HIP connectivity checks or UDP encapsulation of ESP are 292 needed. 294 4. Protocol Description 296 This section describes the normative behavior of the protocol 297 extension. Most of the procedures are similar to what is defined in 298 [RFC5770] but with different, or additional, parameter types and 299 values. In addition, a new type of relaying server, HIP data relay, 300 is specified. Also, it should be noted that HIP version 2 [RFC7401] 301 (instead of [RFC5201] used in [RFC5770]) is expected to be used with 302 this NAT traversal mode. 304 4.1. Relay Registration 306 In order for two hosts to communicate over NATted environments, they 307 need a reliable way to exchange information. HIP relay servers as 308 defined in [RFC5770] support relaying of HIP control plane traffic 309 over UDP in NATted environments. A HIP relay server forwards HIP 310 control packets between the Initiator and the Responder. 312 To guarantee also data plane delivery over varying types of NAT 313 devices, a host MAY also register for UDP encapsulated ESP relaying 314 using Registration Type RELAY_UDP_ESP (value [TBD by IANA: 3]). This 315 service may be coupled with the HIP relay server or offered 316 separately on another server. If the server supports relaying of UDP 317 encapsulated ESP, the host is allowed to register for a data relaying 318 service using the registration extensions in Section 3.3 of 319 [I-D.ietf-hip-rfc5203-bis]). If the server has sufficient relaying 320 resources (free port numbers, bandwidth, etc.) available, it opens a 321 UDP port on one of its addresses and signals the address and port to 322 the registering host using the RELAYED_ADDRESS parameter (as defined 323 in section Section 5.12 in this document). If the relay would accept 324 the data relaying request but does not currently have enough 325 resources to provide data relaying service, it MUST reject the 326 request with Failure Type "Insufficient resources" 327 [I-D.ietf-hip-rfc5203-bis]. 329 A HIP relay server MUST silently drop packets to a HIP relay client 330 that has not previously registered with the HIP relay. The 331 registration process follows the generic registration extensions 332 defined in [I-D.ietf-hip-rfc5203-bis]. The HIP control plane 333 relaying registration follows [RFC5770], but the data plane 334 registration is different. It is worth noting that if the HIP 335 control and data plane relay services reside on different hosts, the 336 relay client has to register separately to each of them. In the 337 example shown in in Figure 2, the two services are coupled on a 338 single host. 340 HIP HIP 341 Relay [Data] Relay 342 Client Server 343 | 1. UDP(I1) | 344 +---------------------------------------------------------------->| 345 | | 346 | 2. UDP(R1(REG_INFO(RELAY_UDP_HIP,[RELAY_UDP_ESP]))) | 347 |<----------------------------------------------------------------+ 348 | | 349 | 3. UDP(I2(REG_REQ(RELAY_UDP_HIP),[RELAY_UDP_ESP]))) | 350 +---------------------------------------------------------------->| 351 | | 352 | 4. UDP(R2(REG_RES(RELAY_UDP_HIP,[RELAY_UDP_ESP]), REG_FROM, | 353 | [RELAYED_ADDRESS])) | 354 |<----------------------------------------------------------------+ 355 | | 357 Figure 2: Example Registration with a HIP Relay 359 In step 1, the relay client (Initiator) starts the registration 360 procedure by sending an I1 packet over UDP to the relay. It is 361 RECOMMENDED that the Initiator select a random port number from the 362 ephemeral port range 49152-65535 for initiating a base exchange. 363 Alternatively, a host MAY also use a single fixed port for initiating 364 all outgoing connections. However, the allocated port MUST be 365 maintained until all of the corresponding HIP Associations are 366 closed. It is RECOMMENDED that the HIP relay server listen to 367 incoming connections at UDP port 10500. If some other port number is 368 used, it needs to be known by potential Initiators. 370 In step 2, the HIP relay server (Responder) lists the services that 371 it supports in the R1 packet. The support for HIP control plane over 372 UDP relaying is denoted by the Registration Type value RELAY_UDP_HIP 373 (see Section 5.9). If the server supports also relaying of ESP 374 traffic over UDP, it includes also Registration type value 375 RELAY_UDP_ESP. 377 In step 3, the Initiator selects the services for which it registers 378 and lists them in the REG_REQ parameter. The Initiator registers for 379 HIP relay service by listing the RELAY_UDP_HIP value in the request 380 parameter. If the Initiator requires also ESP relaying over UDP, it 381 lists also RELAY_UDP_ESP. 383 In step 4, the Responder concludes the registration procedure with an 384 R2 packet and acknowledges the registered services in the REG_RES 385 parameter. The Responder denotes unsuccessful registrations (if any) 386 in the REG_FAILED parameter of R2. The Responder also includes a 387 REG_FROM parameter that contains the transport address of the client 388 as observed by the relay (Server Reflexive candidate). If the 389 Initiator registered to ESP relaying service, the Responder includes 390 RELAYED_ADDRESS paramater that describes the UDP port allocated to 391 the Initiator for ESP relaying. It is worth noting that this client 392 must first activate this UDP port by sending an UPDATE message to the 393 relay server that includes a PEER_PERMISSION parameter as described 394 in section Section 4.12.1. 396 After the registration, the relay client sends periodically NAT 397 keepalives to the relay server in order to keep the NAT bindings 398 between the initiator and the relay alive. The keepalive extensions 399 are described in Section 4.10. 401 The registered host MUST maintain an active HIP association with the 402 data relay as long as it requires the data relaying service. When 403 the HIP association is closed (or times out), or the registration 404 lifetime passes without the registered host refreshing the 405 registration, the data relay MUST stop relaying packets for that host 406 and close the corresponding UDP port (unless other registered hosts 407 are still using it). 409 The data relay MAY use the same relayed address and port for multiple 410 registered hosts, but since this can cause problems with stateful 411 firewalls (see Section 6.5) it is NOT RECOMMENDED. 413 4.2. Transport Address Candidate Gathering 415 A host needs to gather a set of address candidates before contacting 416 a non-relay host. The candidates are needed for connectivity checks 417 that allow two hosts to discover a direct, non-relayed path for 418 communicating with each other. One server reflexive candidate can be 419 discovered during the registration with the HIP relay server from the 420 REG_FROM parameter. 422 The candidate gathering can be done at any time, but it needs to be 423 done before sending an I2 or R2 in the base exchange if ICE is to be 424 used for the connectivity checks. It is RECOMMENDED that all three 425 types of candidates (host, server reflexive, and relayed) are 426 gathered to maximize the probability of successful NAT traversal. 427 However, if no data relay is used, and the host has only a single 428 local IP address to use, the host MAY use the local address as the 429 only host candidate and the address from the REG_FROM parameter 430 discovered during the relay registration as a server reflexive 431 candidate. In this case, no further candidate gathering is needed. 433 If a host has more than one network interface, additional server 434 reflexive candidates can be discovered by sending registration 435 requests with Registration Type CANDIDATE_DISCOVERY (value [TBD by 436 IANA: 4]) from each of the interfaces to a HIP relay server. When a 437 HIP relay server receives a registration request with 438 CANDIDATE_DISCOVERY type, it MUST add a REG_FROM parameter, 439 containing the same information as if this was a relay registration, 440 to the response. This request type SHOULD NOT create any state at 441 the HIP relay server. 443 Gathering of candidates MAY also be performed as specified in 444 Section 4.2 of [RFC5770] if STUN servers are available, or if the 445 host has just a single interface and no TURN or HIP data relay 446 servers are available. 448 4.3. NAT Traversal Mode Negotiation 450 This section describes the usage of a new non-critical parameter 451 type. The presence of the parameter in a HIP base exchange means 452 that the end-host supports NAT traversal extensions described in this 453 document. As the parameter is non-critical (as defined in 454 Section 5.2.1 of [RFC7401]), it can be ignored by an end-host, which 455 means that the host does not support or is not willing to use these 456 extensions. 458 With registration with a HIP relay, it is usually sufficient to use 459 the UDP-ENCAPSULATION mode of NAT traversal since the relay is 460 assumed to be in public address space. Thus, the relay SHOULD 461 propose the UDP-ENCAPSULATION mode as the preferred or only mode. 462 The NAT traversal mode negotiation in a HIP base exchange is 463 illustrated in Figure 3. It is worth noting that the HIP relay could 464 be located between the hosts, but omitted here for simplicity. 466 Initiator Responder 467 | 1. UDP(I1) | 468 +--------------------------------------------------------------->| 469 | | 470 | 2. UDP(R1(.., NAT_TRAVERSAL_MODE(ICE-HIP-UDP), ..)) | 471 |<---------------------------------------------------------------+ 472 | | 473 | 3. UDP(I2(.., NAT_TRAVERSAL_MODE(ICE-HIP-UDP), LOC_SET, ..)) | 474 +--------------------------------------------------------------->| 475 | | 476 | 4. UDP(R2(.., LOC_SET, ..)) | 477 |<---------------------------------------------------------------+ 478 | | 480 Figure 3: Negotiation of NAT Traversal Mode 482 In step 1, the Initiator sends an I1 to the Responder. In step 2, 483 the Responder responds with an R1. As specified in [RFC5770], the 484 NAT_TRAVERSAL_MODE parameter in R1 contains a list of NAT traversal 485 modes the Responder supports. The mode specified in this document is 486 ICE-HIP-UDP (value [TBD by IANA: 3]). 488 In step 3, the Initiator sends an I2 that includes a 489 NAT_TRAVERSAL_MODE parameter. It contains the mode selected by the 490 Initiator from the list of modes offered by the Responder. If ICE- 491 HIP-UDP mode was selected, the I2 also includes the "Transport 492 address" locators (as defined in Section 5.7) of the Initiator in a 493 LOCATOR_SET parameter (denoted here LOC_SET). The locators in I2 are 494 the "ICE offer". 496 In step 4, the Responder concludes the base exchange with an R2 497 packet. If the Initiator chose ICE NAT traversal mode, the Responder 498 includes a LOCATOR_SET parameter in the R2 packet. The locators in 499 R2, encoded like the locators in I2, are the "ICE answer". If the 500 NAT traversal mode selected by the Initiator is not supported by the 501 Responder, the Responder SHOULD reply with a NOTIFY packet with type 502 NO_VALID_NAT_TRAVERSAL_MODE_PARAMETER and abort the base exchange. 504 4.4. Connectivity Check Pacing Negotiation 506 As explained in [RFC5770], when a NAT traversal mode with 507 connectivity checks is used, new transactions should not be started 508 too fast to avoid congestion and overwhelming the NATs. For this 509 purpose, during the base exchange, hosts can negotiate a transaction 510 pacing value, Ta, using a TRANSACTION_PACING parameter in R1 and I2 511 packets. The parameter contains the minimum time (expressed in 512 milliseconds) the host would wait between two NAT traversal 513 transactions, such as starting a new connectivity check or retrying a 514 previous check. The value that is used by both of the hosts is the 515 higher out of the two offered values. 517 The minimum Ta value SHOULD be configurable, and if no value is 518 configured, a value of 500 ms MUST be used. Guidelines for selecting 519 a Ta value are given in Appendix A. Hosts SHOULD NOT use values 520 smaller than 20 ms for the minimum Ta, since such values may not work 521 well with some NATs, as explained in [RFC5245]. The Initiator MUST 522 NOT propose a smaller value than what the Responder offered. If a 523 host does not include the TRANSACTION_PACING parameter in the base 524 exchange, a Ta value of 500 ms MUST be used as that host's minimum 525 value. 527 4.5. Base Exchange via HIP Relay Server 529 This section describes how the Initiator and Responder perform a base 530 exchange through a HIP relay server. Connectivity pacing (denoted as 531 TA_P here) was described in Section 4.4 and is neither repeated here. 532 Similarly, the NAT traversal mode negotiation process (denoted as 533 NAT_TM in the example) was described in Section 4.3 and is neither 534 repeated here. If a relay receives an R1 or I2 packet without the 535 NAT traversal mode parameter, it MUST drop it and SHOULD send a 536 NOTIFY error packet with type NO_VALID_NAT_TRAVERSAL_MODE_PARAMETER 537 to the sender of the R1 or I2. 539 It is RECOMMENDED that the Initiator send an I1 packet encapsulated 540 in UDP when it is destined to an IPv4 address of the Responder. 541 Respectively, the Responder MUST respond to such an I1 packet with a 542 UDP-encapsulated R1 packet, and also the rest of the communication 543 related to the HIP association MUST also use UDP encapsulation. 545 Figure Figure 4 illustrates a base exchange via a HIP relay server. 546 We assume that the Responder (i.e. a HIP relay client) has already 547 registered to the HIP relay server. The Initiator may have also 548 registered to another (or the same relay server), but the base 549 exchange will traverse always through the relay of the Responder. 551 Initiator HIP relay Responder 552 | 1. UDP(I1) | | 553 +--------------------------------->| 2. UDP(I1(RELAY_FROM)) | 554 | +------------------------------->| 555 | | | 556 | | 3. UDP(R1(RELAY_TO, NAT_TM, | 557 | | TA_P)) | 558 | 4. UDP(R1(RELAY_TO, NAT_TM, |<-------------------------------+ 559 | TA_P)) | | 560 |<---------------------------------+ | 561 | | | 562 | 5. UDP(I2(LOC_SET, NAT_TM, | | 563 | TA_P)) | | 564 +--------------------------------->| 6. UDP(I2(LOC_SET, RELAY_FROM, | 565 | | NAT_TM, TA_P)) | 566 | +------------------------------->| 567 | | | 568 | | 7. UDP(R2(LOC_SET, RELAY_TO)) | 569 | 8. UDP(R2(LOC_SET, RELAY_TO)) |<-------------------------------+ 570 |<---------------------------------+ | 571 | | | 573 Figure 4: Base Exchange via a HIP Relay Server 575 In step 1 of Figure 4, the Initiator sends an I1 packet over UDP via 576 the relay server to the Responder. In the HIP header, the source HIT 577 belongs to the Initiator and the destination HIT to the Responder. 578 The initiator sends the I1 packet from its IP address to the IP 579 address of the HIP relay over UDP. 581 In step 2, the HIP relay server receives the I1 packet. If the 582 destination HIT belongs to a registered Responder, the relay 583 processes the packet. Otherwise, the relay MUST drop the packet 584 silently. The relay appends a RELAY_FROM parameter to the I1 packet, 585 which contains the transport source address and port of the I1 as 586 observed by the relay. The relay protects the I1 packet with 587 RELAY_HMAC as described in [I-D.ietf-hip-rfc5204-bis], except that 588 the parameter type is different (see Section 5.8). The relay changes 589 the source and destination ports and IP addresses of the packet to 590 match the values the Responder used when registering to the relay, 591 i.e., the reverse of the R2 used in the registration. The relay MUST 592 recalculate the transport checksum and forward the packet to the 593 Responder. 595 In step 3, the Responder receives the I1 packet. The Responder 596 processes it according to the rules in [RFC7401]. In addition, the 597 Responder validates the RELAY_HMAC according to 599 [I-D.ietf-hip-rfc5204-bis] and silently drops the packet if the 600 validation fails. The Responder replies with an R1 packet to which 601 it includes RELAY_TO and NAT traversal mode parameters. The 602 responder MUST include ICE-HIP-UDP in the NAT traversal modes. The 603 RELAY_TO parameter MUST contain the same information as the 604 RELAY_FROM parameter, i.e., the Initiator's transport address, but 605 the type of the parameter is different. The RELAY_TO parameter is 606 not integrity protected by the signature of the R1 to allow pre- 607 created R1 packets at the Responder. 609 In step 4, the relay receives the R1 packet. The relay drops the 610 packet silently if the source HIT belongs to an unregistered host. 611 The relay MAY verify the signature of the R1 packet and drop it if 612 the signature is invalid. Otherwise, the relay rewrites the source 613 address and port, and changes the destination address and port to 614 match RELAY_TO information. Finally, the relay recalculates 615 transport checksum and forwards the packet. 617 In step 5, the Initiator receives the R1 packet and processes it 618 according to [RFC7401]. The Initiator MAY use the address in the 619 RELAY_TO parameter as a local peer-reflexive candidate for this HIP 620 association if it is different from all known local candidates. The 621 Initiator replies with an I2 packet that uses the destination 622 transport address of R1 as the source address and port. The I2 623 packet contains a LOCATOR_SET parameter that lists all the HIP 624 candidates (ICE offer) of the Initiator. The candidates are encoded 625 using the format defined in Section 5.7. The I2 packet MUST also 626 contain a NAT traversal mode parameter that includes ICE-HIP-UDP 627 mode. 629 In step 6, the relay receives the I2 packet. The relay appends a 630 RELAY_FROM and a RELAY_HMAC to the I2 packet similarly as explained 631 in step 2, and forwards the packet to the Responder. 633 In step 7, the Responder receives the I2 packet and processes it 634 according to [RFC7401]. It replies with an R2 packet and includes a 635 RELAY_TO parameter as explained in step 3. The R2 packet includes a 636 LOCATOR_SET parameter that lists all the HIP candidates (ICE answer) 637 of the Responder. The RELAY_TO parameter is protected by the HMAC. 639 In step 8, the relay processes the R2 as described in step 4. The 640 relay forwards the packet to the Initiator. After the Initiator has 641 received the R2 and processed it successfully, the base exchange is 642 completed. 644 Hosts MUST include the address of one or more HIP relay servers 645 (including the one that is being used for the initial signaling) in 646 the LOCATOR_SET parameter in I2 and R2 if they intend to use such 647 servers for relaying HIP signaling immediately after the base 648 exchange completes. The traffic type of these addresses MUST be "HIP 649 signaling" and they MUST NOT be used as HIP candidates. If the HIP 650 relay server locator used for relaying the base exchange is not 651 included in I2 or R2 LOCATOR_SET parameters, it SHOULD NOT be used 652 after the base exchange. Instead, further HIP signaling SHOULD use 653 the same path as the data traffic. 655 4.6. Connectivity Checks 657 When the Initiator and Responder complete the base exchange through 658 the HIP relay, both of them employ the IP address of the relay as the 659 destination address for the packets. This address MUST NOT be used 660 as a destination for ESP traffic unless the HIP relay supports also 661 ESP data relaying. When NAT traversal mode with ICE-HIP-UDP was 662 successfully negotiated and selected, the Initiator and Responder 663 MUST start the connectivity checks in order to attempt to obtain 664 direct end-to-end connectivity through NAT devices. 666 The connectivity checks follow the ICE methodology [MMUSIC-ICE], but 667 UDP encapsulated HIP control messages are used instead of ICE 668 messages. Similarly as in ICE, both regular and aggressive mode for 669 nominating address candidates can be used. The Initiator MUST take 670 the role of controlling host and the Responder acts as the controlled 671 host. The protocol follows standard HIP UPDATE sending and 672 processing rules as defined in section 6.11 and 6.12 in [RFC7401], 673 but some new parameters are introduced: CANDIDATE_PRIORITY, 674 MAPPED_ADDR and NOMINATE. 676 4.6.1. Aggressive Connectivity Checks 678 Figure Figure 5 illustrates connectivity checks in a simplified 679 scenario, where the Initiator and Responder have only a single 680 candidate pair to check and they employ aggressive mode. Typically, 681 NATs drop messages messages until both sides have sent messages using 682 the same port pair. In this scenario, the Responder sends a 683 connectivity check first but the NAT of the Initiator drops it. 684 However, the connectivity check from the Initiator reaches the 685 Responder because it uses the same port pair as the first message. 687 Initiator NAT1 NAT2 Responder 688 | | 1. UDP(UPDATE(SEQ, CAND_PRIO, | | 689 | | ECHO_REQ_SIGN)) | | 690 | X<-+------------------------------------+----------------+ 691 | | | | 692 | 2. UDP(UPDATE(SEQ, ECHO_REQ_SIGN, CAND_PRIO, NOMINATE)) | 693 +-------------+------------------------------------+--------------->| 694 | | | | 695 | 3. UDP(UPDATE(SEQ, ACK, ECHO_REQ_SIGN, ECHO_RESP_SIGN, | 696 | MAPPED_ADDR, NOMINATE)) | | 697 |<------------+------------------------------------+----------------+ 698 | | | | 699 | 4. UDP(UPDATE(ACK, ECHO_RESP_SIGN, MAPPED_ADDR)) | | 700 +-------------+------------------------------------+--------------->+ 701 | | | | 702 | 5. ESP data traffic over UDP | | 703 +<------------+------------------------------------+--------------->+ 704 | | | | 706 Figure 5: Aggressive Connectivity Checks, Scenario A 708 In step 1, the Responder sends a connectivity check to the Initiator 709 that the NAT of the Initiator drops. The message includes a number 710 of parameters. As specified in [RFC7401]), the SEQ parameter 711 includes a running sequence identifier for the connectivity check. 712 The candidate priority (denoted "CAND_PRIO" in the figure) describes 713 the priority of the address candidate being tested. The 714 ECHO_REQUEST_SIGNED (denoted ECHO_REQ_SIGN in the figure) includes a 715 nonce that the recipient must sign and echo back as it is. 717 In step 2,the Responder sends a connectivity check using the same 718 address pair candidate as the Initiator did and the message traverses 719 successfully the NAT boxes. The message includes the same parameters 720 as in the previous step. However, since Initiator is employing 721 aggressive mode, it also includes NOMINATE parameter in the message. 722 This signals that the connectivity checks should be conclude upon 723 finding the first working address pair candidates. 725 In step 3, the Responder has successfully received the previous 726 connectivity check from the Initiator and starts to build a response 727 message. Since the message from the Initiator included a SEQ, the 728 Responder must acknowledge it using an ACK parameter. Also, the 729 nonce contained in the echo request must be echoed back in an 730 ECHO_REQUEST_SIGNED (denoted ECHO_REQUEST_SIGN) parameter. In 731 addition to these two parameters, the Responder includes an NOMINATE 732 parameter to confirm that the current address pair candidate is 733 selected for use. The Responder includes also a MAPPED_ADDRESS 734 parameter that contains the transport address of the Initiator as 735 observed by the Responder (i.e. peer reflexive candidate). The 736 Initiator should acknowledge the message from the Responder, so it 737 also includes its own SEQ in the message and its own echo request for 738 additional security. 740 In step 4, the Initiator receives the message from the Responder and 741 builds a corresponding response that concludes connectivity checks. 742 Since the previous message from the Responder included a new SEQ and 743 ECHO_REQUEST_SIGN parameters, the Initiator includes the 744 corresponding ACK and ECHO_RESPONSE_SIGN parameters. Before sending, 745 it also includes a MAPPED_ADDR parameter describing the peer 746 reflexive candidate. 748 In step 5, the Responder has received the message from the Initiator 749 and both end-points create the corresponding IPsec security 750 associations that can be used for delivering application payload. 752 Figure Figure 6 illustrates aggressive connectivity checks. For 753 simplicity, the hosts test here only a single address candidate. The 754 difference to the previous scenario is that Initiator sends the first 755 connectivity test that is then dropped by the NAT of the Responder. 757 Initiator NAT1 NAT2 Responder 758 | | | | 759 | 1. UDP(UPDATE(SEQ, ECHO_REQ_SIGN, CAND_PRIO, NOMINATE)) | 760 +------------>+----------------------------------->+->X | 761 | | | | 762 | 2. UDP(UPDATE(SEQ, ECHO_REQ_SIGN, CAND_PRIO)) | | 763 |<------------+------------------------------------+----------------+ 764 | | | | 765 | 3. UDP(UPDATE(SEQ, ACK, ECHO_REQ_SIGN, ECHO_RESP_SIGN | 766 | MAPPED_ADDR, NOMINATE)) | | 767 +-------------+------------------------------------+--------------->+ 768 | | | | 769 | 4. UDP(UPDATE(ACK, ECHO_RESP_SIGN, MAPPED_ADDR, NOMINATE)) | 770 +<------------+------------------------------------+----------------+ 771 | | | | 772 | 5. ESP data traffic over UDP | | 773 +<------------+------------------------------------+--------------->+ 774 | | | | 775 | | | | 777 Figure 6: Aggressive Connectivity Checks, Scenario B 779 In step 1, the Initiator sends the first connectivity check message 780 to the Responder, but the packet is dropped by the NAT of the 781 Responder. 783 In step 2, the Responder sends a connectivity check message to the 784 Initiator that passes both NATs. The message includes SEQ, 785 ECHO_REQUEST_SIGN and CANDIDATE_PRIORITY parameters. 787 In step 3, the Initiator receives the message from the Responder. It 788 constructs a response message that includes an ACK and 789 ECHO_RESPONSE_SIGN parameters that acknowledge the corresponding SEQ 790 and ECHO_REQUEST_SIGN parameters from the previous message from the 791 Responder. The response message also includes a new SEQ and 792 ECHO_REQUEST_SIGN parameters to be acknowledged by the Responder. 793 The responder also includes the peer reflexive candidate in 794 MAPPED_ADDR parameter and NOMINATE (since it employs aggressive 795 connectivity checks). 797 In step 4, the Responder receives the message from the Initiator and 798 builds a response message, where the ACK and ECHO_RESP_SIGN 799 parameters correspond to the SEQ and ECHO_REQUEST_SIGN parameters in 800 the previously received message. The Responder includes also the 801 peer reflexive candidate in MAPPED_ADDR parameter and confirms the 802 completion of the candidate nomination with the NOMINATE parameter. 804 In step 5, the candidate nomination is complete and the hosts can 805 start to exchange application payload. 807 4.6.2. Normal Connectivity Checks 809 Normal connectivity checks are similar as aggressive, but the 810 difference is that the controlling host (i.e. Initiator) does not 811 include the NOMINATE parameter until all candidates have been tested. 812 Figure Figure 6 illustrates normal connectivity checks (in the same 813 scenario as illustrated in figure Figure 5). 815 Initiator NAT1 NAT2 Responder 816 | | 1. UDP(UPDATE(SEQ, CAND_PRIO, | | 817 | | ECHO_REQ_SIGN)) | | 818 | X<-+------------------------------------+----------------+ 819 | | | | 820 | 2. UDP(UPDATE(SEQ, ECHO_REQ_SIGN, CAND_PRIO)) | | 821 +-------------+------------------------------------+--------------->| 822 | | | | 823 | 3. UDP(UPDATE(SEQ, ACK, ECHO_REQ_SIGN, ECHO_RESP_SIGN, | 824 | | MAPPED_ADDR)) | | 825 |<------------+------------------------------------+----------------+ 826 | | | | 827 | 4. UDP(UPDATE(ACK, ECHO_RESP_SIGN, MAPPED_ADDR)) | | 828 +-------------+------------------------------------+--------------->+ 829 | | | | 830 | 5. Other connectivity checks using UPDATE over UDP | 831 <-------------+------------------------------------+----------------> 832 | | | | 833 | 6. UDP(UPDATE(SEQ, ECHO_REQ_SIGN, CAND_PRIO, NOMINATE)) | 834 +-------------+------------------------------------+--------------->| 835 | | | | 836 | 7. UDP(UPDATE(SEQ, ACK, ECHO_REQ_SIGN, ECHO_RESP_SIGN, | 837 | NOMINATE)) | | 838 |<------------+------------------------------------+----------------+ 839 | | | | 840 | 8. UDP(UPDATE(ACK, ECHO_RESP_SIGN)) | | 841 +-------------+------------------------------------+--------------->+ 842 | | | | 843 | 9. ESP data traffic over UDP | | 844 +<------------+------------------------------------+--------------->+ 845 | | | | 847 Figure 7: Normal Connectivity Checks 849 Steps 1-4 are identical to the same steps in figure Figure 5. The 850 difference here is that the initiator does not include the NOMINATE 851 parameter. 853 In step 5, the Initiator and Responder test the remaining address 854 candidates (if any) because the Initiator did not elect an address 855 candidate with the NOMINATE parameter. 857 In step 6, the Initiator has completed testing all address candidates 858 and nominates one address candidate to be used. It sends an UPDATE 859 message using the selected address candidates that includes a number 860 of parameters: SEQ, ECHO_REQUEST_SIGN, CANDIDATE_PRIORITY and the 861 NOMINATE parameter. 863 In step 7, the Responder receives the message with NOMINATE parameter 864 from the Initiator. It sends a response that includes the NOMINATE 865 parameter in addition to a number of other parameters. The ACK and 866 ECHO_RESPONSE_SIGN parameters acknowledge the SEQ and 867 ECHO_REQUEST_SIGN parameters from previous message from the 868 Initiator. The Responder includes SEQ and ECHO_REQUEST_SIGN 869 parameters in order to receive an acknowledgment from the Responder. 871 In step 8, the Initiator completes the candidate nomination process 872 by confirming the message reception to the Responder. In the 873 confirmation message, the ACK and ECHO_RESPONSE_SIGN parameters 874 correspond to the SEQ and ECHO_REQUEST_SIGN parameters in the message 875 sent by the Responder in the previous step. 877 In step 9, the Initiator and Responder can start sending application 878 payload over the successfully nominated address candidates. 880 Compared to aggressive connectivity steps, it is worth noting that 881 the MAPPED_ADDRESS does not need to be included in normal 882 connectivity checks in the messages sent in steps 7 and 8. 884 4.6.3. Rules for Connectivity Checks 886 All of the connectivity check packets MUST be protected with HMACs 887 and signatures (even though the illustrations omitted them for 888 simplicity). To provide strong replay protection, for each pair of 889 address candidates, both the Initiator and Responder MUST send a send 890 a nonce to each other for signing using the ECHO_REQUEST_SIGNED 891 parameter (that then has to be echoed back by the recipient). 892 Similarly, the SEQ parameter enforces the the recipient to 893 acknowledge a received message. Effectively these two mechanisms 894 combined result in a secure three way packet exchange that tests both 895 sides for return routability. 897 [RFC7401] states that UPDATE packets have to include either a SEQ or 898 ACK parameter (or both). According to the RFC, each SEQ parameter 899 should be acknowledged separately. In the context of NATs, this 900 means that some of the SEQ parameters sent in connectivity checks 901 will lost or arrive out of order. From the viewpoint of the 902 recipient, this is not a problem since the the recipient will just 903 "blindly" acknowledge the SEQ. However, the sender needs to be 904 prepared for lost sequence identifiers and ACKs parameters that 905 arrive out of order. 907 As specified in [RFC7401], an ACK parameter may acknowledge multiple 908 sequence identifiers. While the examples in the previous sections do 909 not illustrate such functionality, it is also permitted when 910 employing ICE-HIP-UDP mode. 912 In ICE-HIP-UDP mode, a retransmission of a connectivity checks SHOULD 913 be sent with the same sequence identifier in the SEQ parameter. Some 914 of tested address candidates will never produce a working address 915 pair, and thus may cause retransmissions. Upon successful nomination 916 an address pair, a host MAY immediately stop sending such 917 retransmissions. 919 The packet flow illustrations are missing a scenario where both the 920 Initiator and Responder send simultaneously connectivity checks to 921 each other using the same address candidates, and the NATs at both 922 sides let the packets pass. From the viewpoint of NAT penetration, 923 this results in a bit more unnecessary packet exchanges, but both 924 ends SHOULD nevertheless complete the three way connectivity check 925 process they initiated. 927 The connectivity check messages MUST be paced by the value negotiated 928 during the base exchange as described in Section 4.4. If neither one 929 of the hosts announced a minimum pacing value, a value of 500 ms MUST 930 be used. 932 As defined in [RFC5770], both hosts MUST form a priority ordered 933 checklist and start check transactions every Ta milliseconds as long 934 as the checks are running and there are candidate pairs whose tests 935 have not started. The retransmission timeout (RTO) for the 936 connectivity check UPDATE packets MUST be calculated as follows: 938 RTO = MAX (500ms, Ta * (Num-Waiting + Num-In-Progress)) 940 In the RTO formula, Ta is the value used for the connectivity check 941 pacing, Num-Waiting is the number of pairs in the checklist in the 942 "Waiting" state, and Num-In-Progress is the number of pairs in the 943 "In-Progress" state. This is identical to the formula in [RFC5245] 944 if there is only one checklist. 946 Each connectivity check request packet MUST contain a 947 CANDIDATE_PRIORITY parameter (see Section 5.14) with the priority 948 value that would be assigned to a peer reflexive candidate if one was 949 learned from the corresponding check. An UPDATE packet that 950 acknowledges a connectivity check request MUST be sent from the same 951 address that received the check and delivered to the same address 952 where the check was received from. Each acknowledgment UPDATE packet 953 MUST contain a MAPPED_ADDRESS parameter with the port, protocol, and 954 IP address of the address where the connectivity check request was 955 received from. 957 If the connectivity checks failed, the hosts MUST NOT send ESP 958 traffic to each other but MAY continue communicating using HIP 959 packets and the locators used for the base exchange. Also, the hosts 960 SHOULD notify each other about the failure with a 961 CONNECTIVITY_CHECKS_FAILED NOTIFY packet (see Section 5.10). 963 4.7. NAT Traversal Alternatives 965 4.7.1. Minimal NAT Traversal Support 967 If the Responder has a fixed and publicly reachable IPv4 address and 968 does not employ a HIP relay, the explicit NAT traversal mode 969 negotiation MAY be omitted, and thus even the UDP-ENCAPSULATION mode 970 does not have to be negotiated. In such a scenario, the Initiator 971 sends an I1 message over UDP and the Responder responds with an R1 972 message without including any NAT traversal mode parameter. The rest 973 of the base exchange follows the procedures defined in [RFC7401], 974 except that the control and data plane use UDP encapsulation. Here, 975 the use of UDP for NAT traversal is agreed implicitly. This way of 976 operation is still subject to NAT timeouts, and the hosts MUST employ 977 NAT keepalives as defined in section Section 4.10. 979 4.7.2. Base Exchange without Connectivity Checks 981 It is possible to run a base exchange without any connectivity checks 982 as defined in section 4.8 in [RFC5770]. The procedure is applicable 983 also in the context of this specification, so it is repeated here for 984 completeness. 986 In certain network environments, the connectivity checks can be 987 omitted to reduce initial connection set-up latency because a base 988 exchange acts as an implicit connectivity test itself. For this to 989 work, the Initiator MUST be able to reach the Responder by simply UDP 990 encapsulating HIP and ESP packets sent to the Responder's address. 991 Detecting and configuring this particular scenario is prone to 992 failure unless carefully planned. 994 In such a scenario, the Responder MAY include UDP-ENCAPSULATION NAT 995 traversal mode as one of the supported modes in the R1 packet. If 996 the Responder has registered to a HIP relay server, it MUST also 997 include a LOCATOR_SET parameter in R1 that contains a preferred 998 address where the Responder is able to receive UDP-encapsulated ESP 999 and HIP packets. This locator MUST be of type "Transport address", 1000 its Traffic type MUST be "both", and it MUST have the "Preferred bit" 1001 set (see Table 1). If there is no such locator in R1, the source 1002 address of R1 is used as the Responder's preferred address. 1004 The Initiator MAY choose the UDP-ENCAPSULATION mode if the Responder 1005 listed it in the supported modes and the Initiator does not wish to 1006 use the connectivity checks defined in this document for searching 1007 for a more optimal path. In this case, the Initiator sends the I2 1008 with UDP-ENCAPSULATION mode in the NAT traversal mode parameter 1009 directly to the Responder's preferred address (i.e., to the preferred 1010 locator in R1 or to the address where R1 was received from if there 1011 was no preferred locator in R1). The Initiator MAY include locators 1012 in I2 but they MUST NOT be taken as address candidates, since 1013 connectivity checks defined in this document will not be used for 1014 connections with UDP-ENCAPSULATION NAT traversal mode. Instead, if 1015 R2 and I2 are received and processed successfully, a security 1016 association can be created and UDP-encapsulated ESP can be exchanged 1017 between the hosts after the base exchange completes. However, the 1018 Responder SHOULD NOT send any ESP to the Initiator's address before 1019 it has received data from the Initiator, as specified in Sections 1020 4.4.3. and 6.9 of [RFC7401] and in Sections 3.2.9 and 5.4 of 1021 [I-D.ietf-hip-rfc5206-bis]. 1023 Since an I2 packet with UDP-ENCAPSULATION NAT traversal mode selected 1024 MUST NOT be sent via a relay, the Responder SHOULD reject such I2 1025 packets and reply with a NO_VALID_NAT_TRAVERSAL_MODE_PARAMETER NOTIFY 1026 packet (see Section 5.10). 1028 If there is no answer for the I2 packet sent directly to the 1029 Responder's preferred address, the Initiator MAY send another I2 via 1030 the HIP relay server, but it MUST NOT choose UDP-ENCAPSULATION NAT 1031 traversal mode for that I2. 1033 4.7.3. Initiating a Base Exchange both with and without UDP 1034 Encapsulation 1036 It is possible to run a base exchange in parallel both with and 1037 without UDP encapsulation as defined in section 4.9 in [RFC5770]. 1038 The procedure is applicable also in the context of this 1039 specification, so it is repeated here for completeness. 1041 The Initiator MAY also try to simultaneously perform a base exchange 1042 with the Responder without UDP encapsulation. In such a case, the 1043 Initiator sends two I1 packets, one without and one with UDP 1044 encapsulation, to the Responder. The Initiator MAY wait for a while 1045 before sending the other I1. How long to wait and in which order to 1046 send the I1 packets can be decided based on local policy. For 1047 retransmissions, the procedure is repeated. 1049 The I1 packet without UDP encapsulation may arrive directly, without 1050 any relays, at the Responder. When this happens, the procedures in 1051 [RFC7401] are followed for the rest of the base exchange. The 1052 Initiator may receive multiple R1 packets, with and without UDP 1053 encapsulation, from the Responder. However, after receiving a valid 1054 R1 and answering it with an I2, further R1 packets that are not 1055 retransmits of the original R1 MUST be ignored. 1057 The I1 packet without UDP encapsulation may also arrive at a HIP- 1058 capable middlebox. When the middlebox is a HIP rendezvous server and 1059 the Responder has successfully registered with the rendezvous 1060 service, the middlebox follows rendezvous procedures in 1061 [I-D.ietf-hip-rfc5204-bis]. 1063 If the Initiator receives a NAT traversal mode parameter in R1 1064 without UDP encapsulation, the Initiator MAY ignore this parameter 1065 and send an I2 without UDP encapsulation and without any selected NAT 1066 traversal mode. When the Responder receives the I2 without UDP 1067 encapsulation and without NAT traversal mode, it will assume that no 1068 NAT traversal mechanism is needed. The packet processing will be 1069 done as described in [RFC7401]. The Initiator MAY store the NAT 1070 traversal modes for future use, e.g., in case of a mobility or 1071 multihoming event that causes NAT traversal to be used during the 1072 lifetime of the HIP association. 1074 4.8. Sending Control Packets after the Base Exchange 1076 The same considerations of sending control packets after the base 1077 exchange described in section 5.10 in [RFC5770] apply also here, so 1078 they are repeated here for completeness. 1080 After the base exchange, the end-hosts MAY send HIP control packets 1081 directly to each other using the transport address pair established 1082 for a data channel without sending the control packets through the 1083 HIP relay server. When a host does not get acknowledgments, e.g., to 1084 an UPDATE or CLOSE packet after a timeout based on local policies, 1085 the host SHOULD resend the packet through the relay, if it was listed 1086 in the LOCATOR_SET parameter in the base exchange. 1088 If control packets are sent through a HIP relay server, the host 1089 registered with the relay MUST utilize the RELAY_TO parameter as in 1090 the base exchange. The HIP relay server SHOULD forward HIP packets 1091 to the registered hosts and forward packets from a registered host to 1092 the address in the RELAY_TO parameter. The relay MUST add a 1093 RELAY_FROM parameter to the control packets it relays to the 1094 registered hosts. 1096 If the HIP relay server is not willing or able to relay a HIP packet, 1097 it MAY notify the sender of the packet with MESSAGE_NOT_RELAYED error 1098 notification (see Section 5.10). 1100 4.9. Mobility Handover Procedure 1102 A host may move after base exchange and connectivity checks. 1103 Mobility extensions for HIP [I-D.ietf-hip-rfc5206-bis] define 1104 handover procedures without NATs. In this section, we define how two 1105 hosts interact handover procedures in scenarios involving NATs. The 1106 specified extensions define only simple mobility using a pair of 1107 security associations, and multihoming extensions are left to be 1108 defined in later specifications. 1110 We assume that the two hosts have successfully negotiated and chosen 1111 the ICE-HIP-UDP mode during the base exchange as defined in section 1112 Section 4.3. The Initiator of the base exchange MUST store 1113 information that it was the controlling host during the base 1114 exchange. Similarly, the Responder MUST store information that it 1115 was the controlled host during the base exchange. 1117 The mobility extensions for NAT traversal are illustrated in figure 1118 Figure 8. The mobile host is the host that has changed its locators, 1119 and the peer host is the host it has a host association with. The 1120 mobile host may have multiple peers and it repeats the process with 1121 all of its peers. In the figure, the HIP relay belongs to the peer 1122 host, i.e., the peer host is a relay client for the HIP relay. It is 1123 worth noting that the figure corresponds to figure 3 in Figure 8, but 1124 the difference is that the main UPDATE procedure is carried over the 1125 relay and the connectivity is tested separately. Next, we describe 1126 the procedure in the figure in detail. 1128 Mobile Host HIP relay Peer Host 1129 | 1. UDP(UPDATE(ESP_INFO, | | 1130 | LOC_SET, SEQ)) | | 1131 +--------------------------------->| 2. UDP(UPDATE(ESP_INFO, | 1132 | | LOC_SET, SEQ, | 1133 | | RELAY_FROM)) | 1134 | +------------------------------->| 1135 | | | 1136 | | 3. UDP(UPDATE(ESP_INFO, SEQ, | 1137 | | ACK, ECHO_REQ_SIGN)) | 1138 | 4. UDP(UPDATE(ESP_INFO, SEQ, |<-------------------------------+ 1139 | ACK, ECHO_REQ_SIGN, | | 1140 | RELAY_TO)) | | 1141 |<---------------------------------+ | 1142 | | | 1143 | 5. UDP(UPDATE(ACK, | | 1144 | ECHO_RESP_SIGN)) | | 1145 +--------------------------------->| 6. UDP(UPDATE(ACK, | 1146 | | ECHO_RESP_SIGN, | 1147 | | RELAY_FROM)) | 1148 | +------------------------------->| 1149 | | | 1150 | 7. connectivity checks over UDP | 1151 +<----------------------------------------------------------------->+ 1152 | | | 1153 | 8. ESP data over UDP | 1154 +<----------------------------------------------------------------->+ 1155 | | | 1157 Figure 8: HIP UPDATE procedure 1159 In step 1, the mobile host has changed location and sends a location 1160 update to its peer through the HIP relay of the peer. It sends an 1161 UPDATE packet with source HIT belonging to itself and destination HIT 1162 belonging to the peer host. In the packet, the source IP address 1163 belongs to the mobile host and the destination to the HIP relay. The 1164 packet contains an ESP_INFO parameter, where, in this case, the OLD 1165 SPI and NEW SPI parameters both contain the pre-existing incoming 1166 SPI. The packet also contains the locators of the mobile host in a 1167 LOCATOR_SET parameter. The packet contains also a SEQ number to be 1168 acknowledged by the peer. As specified in 1169 [I-D.ietf-hip-rfc5206-bis], the packet may also include a HOST_ID 1170 (for middlebox inspection) and DIFFIE_HELLMAN parameter for rekeying. 1172 In step 2, HIP relay receives the UPDATE packet and forwards it to 1173 the peer host (i.e. relay client). The HIP relay rewrites the 1174 destination IP address and appends a RELAY_FROM parameter to the 1175 message. 1177 In step 3, the peer host receives the UPDATE packet, processes it and 1178 responds with another UPDATE message. The message is destined to the 1179 HIT of mobile host and to the IP address of the HIP relay. The 1180 message includes an ESP_INFO parameter where, in this case, the OLD 1181 SPI and NEW SPI parameters both contain the pre-existing incoming 1182 SPI. The peer includes a new SEQ and ECHO_REQUEST_SIGN parameters to 1183 be acknowledged by the mobile host. The message acknowledges the SEQ 1184 parameter of the earlier message with an ACK parameter. 1186 In step 4, the HIP relay receives the message, rewrites the 1187 destination IP address, appends an RELAY_TO parameter and forwards 1188 the modified message to the mobile host. 1190 In step 5, the mobile host receives the UPDATE packet from the peer 1191 and processes it. It concludes the information exchange by 1192 acknowledging the received SEQ parameter with an ACK parameter and 1193 the ECHO_REQUEST_SIGN parameter with ECHO_RESPONSE_SIGN parameter. 1194 The mobile host delivers the packet to the HIT of the peer and to the 1195 address of the HIP relay. The mobile host can start connectivity 1196 checks after this packet. 1198 In step 6, HIP relay receives the UPDATE packet and forwards it to 1199 the peer host (i.e. relay client). The HIP relay rewrites the 1200 destination IP address and appends a RELAY_FROM parameter to the 1201 message. When the peer host receives this concluding UPDATE packet, 1202 it can initiate the connectivity checks. 1204 In step 7, the two hosts test for connectivity across NATs according 1205 to procedures described in in section Section 4.6. The original 1206 Initiator of the communications is the controlling and the original 1207 Responder is the controlled host. The controlling host SHOULD employ 1208 the same mode as earlier for the base exchange (i.e. aggressive or 1209 normal mode). 1211 In step 8, the connectivity checks are successfully completed and the 1212 controlling host has nominated one address pair to be used. The 1213 hosts set up security associations to deliver the application 1214 payload. 1216 4.10. NAT Keepalives 1218 To prevent NAT states from expiring, communicating hosts send 1219 periodic keepalives to other hosts that they have established a host 1220 associating with. If a registered host has not sent any data or 1221 control messages to its HIP or data relay for 15 seconds, it MUST 1222 send a HIP NOTIFY packet to the relay. Likewise, if a host has not 1223 sent any data to another host it has established a host association 1224 in the ICE-HIP_UDP mode, it MUST send either a HIP NOTIFY packet or 1225 an ICMPv6 echo request inside the related ESP tunnel. HIP relay 1226 servers MAY refrain from sending keepalives if it's known that they 1227 are not behind a middlebox that requires keepalives. If the base 1228 exchange or mobility handover procedure occurs during an extremely 1229 slow path, a host MAY also send HIP notify packets every 15 seconds 1230 to keep to path active. 1232 4.11. Close Procedure 1234 The two-way procedure for closing a HIP and the related security 1235 associations is defined in [RFC7401]. One hosts initiates the 1236 procedure by sending a CLOSE party and the recipient confirms it with 1237 CLOSE_ACK. All packets are protected using HMACs and signatures, and 1238 the CLOSE messages includes a ECHO_REQUEST_SIGNED parameter to 1239 protect against replay attacks. 1241 The same procedure for closing HIP associations applies also here, 1242 but the messaging occurs using the UDP encapsulated tunnel that the 1243 two hosts employ. A host sending the CLOSE message SHOULD first send 1244 the message over a direct link. After a number of retransmissions, 1245 it MUST send over a HIP relay of the recipient if one exists. The 1246 host receiving the CLOSE message directly without a relay SHOULD 1247 respond directly. The the CLOSE message came via a relay, it SHOULD 1248 respond using the same relay. 1250 4.12. Relaying Considerations 1252 4.12.1. Forwarding Rules and Permissions 1254 The HIP data relay uses a similar permission model as a TURN server: 1255 before any ESP data packets sent by a peer are forwarded, a 1256 permission MUST be set for the peer's address. The permissions also 1257 install a forwarding rule, similar to TURN's channels, based on the 1258 Security Parameter Index (SPI) values in the ESP packets. 1260 Permissions are not required for the connectivity checks, but if a 1261 relayed address is selected to be used for data, the registered host 1262 MUST send an UPDATE message [RFC7401] with a PEER_PERMISSION 1263 parameter (see Section 5.13) with the address of the peer and the 1264 outbound and inbound SPI values the host is using with this peer. 1266 When a data relay receives an UPDATE with a PEER_PERMISSION 1267 parameter, it MUST check if the sender of the UPDATE is registered 1268 for data relaying service, and drop the UPDATE if the host was not 1269 registered. If the host was registered, the relay checks if there is 1270 a permission with matching information (address, protocol, port and 1271 SPI values). If there is no such permission, a new permission MUST 1272 be created and its lifetime MUST be set to 5 minutes. If an 1273 identical permission already existed, it MUST be refreshed by setting 1274 the lifetime to 5 minutes. A registered host SHOULD refresh 1275 permissions 1 minute before the expiration if the permission is still 1276 needed. 1278 4.12.2. Relaying UDP Encapsulated Data and Control Packets 1280 When a HIP data relay accepts to relay UDP encapsulated data, it 1281 opens a UDP port (relayed address) for this purpose as described in 1282 Section 4.1. If the data relay receives a UDP encapsulated HIP 1283 control packet on that port, it MUST forward the packet to the 1284 registered host and add a RELAY_FROM parameter to the packet as if 1285 the data relay was acting as a HIP relay server [RFC5770]. 1287 When a host wants to send a HIP control packet (such as a 1288 connectivity check packet) to a peer via the data relay, it MUST add 1289 a RELAY_TO parameter containing the peer's address to the packet and 1290 send it to the data relay's address. The data relay MUST send the 1291 packet to the peer's address from the relayed address. 1293 If the data relay receives a UDP packet that is not a HIP control 1294 packet to the relayed address, it MUST check whether there is a 1295 permission set for the peer the packet is coming from (i.e., the 1296 sender's address and SPI value matches to an installed permission), 1297 and if there is, it MUST forward the packet to the registered host 1298 that created the permission. Packets without a permission MUST be 1299 dropped silently. 1301 When a host wants to send a UDP encapsulated ESP packet to a peer via 1302 the data relay, it MUST have an active permission at the data relay 1303 for the peer with the outbound SPI value it is using. The host MUST 1304 send the UDP encapsulated ESP packet to the data relay's address. 1306 When the data relay receives a UDP encapsulated ESP packet from a 1307 registered host, it MUST check whether there exists a permission for 1308 that outbound SPI value. If such permission exists, the packet MUST 1309 be forwarded to the address that was registered for the SPI value. 1310 If no permission exists, the packet is dropped. 1312 4.12.3. Handling Conflicting SPI Values 1314 Since the HIP data relay determines from the SPI value to which peer 1315 an ESP packet should be forwarded, the outbound SPI values need to be 1316 unique for each relayed address registration. Thus, if a registered 1317 host detects that a peer would use an SPI value that is already used 1318 with another peer via the relay, it MUST NOT select the relayed 1319 address for use. The host MAY restart the base exchange to avoid a 1320 conflict or it MAY refrain from using the relayed candidate for the 1321 connectivity checks. 1323 Since the SPI space is 32 bits and the SPI values should be random, 1324 the probability for a conflicting SPI value is fairly small. 1325 However, a host with many peers MAY decrease the odds of a conflict 1326 by registering more than one relayed address using different local 1327 addresses. 1329 5. Packet Formats 1331 The following subsections define the parameter and packet encodings 1332 for the HIP and ESP packets. All values MUST be in network byte 1333 order. 1335 It is worth noting that most of the parameters are shown for 1336 completeness sake even though they are specified already in 1337 [RFC5770]. New parameters are explicitly described as new. 1339 5.1. HIP Control Packets 1341 Figure Figure 9 illustrates the packet format for UDP-encapsulated 1342 HIP. The format is identical to [RFC5770]. 1344 0 1 2 3 1345 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 1346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1347 | Source Port | Destination Port | 1348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1349 | Length | Checksum | 1350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1351 | 32 bits of zeroes | 1352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1353 | | 1354 ~ HIP Header and Parameters ~ 1355 | | 1356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1358 Figure 9: Format of UDP-Encapsulated HIP Control Packets 1360 HIP control packets are encapsulated in UDP packets as defined in 1361 Section 2.2 of [RFC3948], "IKE Header Format for Port 4500", except a 1362 different port number is used. Figure 9 illustrates the 1363 encapsulation. The UDP header is followed by 32 zero bits that can 1364 be used to differentiate HIP control packets from ESP packets. The 1365 HIP header and parameters follow the conventions of [RFC7401] with 1366 the exception that the HIP header checksum MUST be zero. The HIP 1367 header checksum is zero for two reasons. First, the UDP header 1368 already contains a checksum. Second, the checksum definition in 1369 [RFC7401] includes the IP addresses in the checksum calculation. The 1370 NATs unaware of HIP cannot recompute the HIP checksum after changing 1371 IP addresses. 1373 A HIP relay server or a Responder without a relay SHOULD listen at 1374 UDP port 10500 for incoming UDP-encapsulated HIP control packets. If 1375 some other port number is used, it needs to be known by potential 1376 Initiators. 1378 5.2. Connectivity Checks 1380 HIP connectivity checks are HIP UPDATE packets. The format is 1381 specified in [RFC7401]. 1383 5.3. Keepalives 1385 The keepalives are either HIP NOTIFY packets as specified in 1386 [RFC7401] or ICMPv6 packets inside the ESP tunnel. 1388 5.4. NAT Traversal Mode Parameter 1390 The format of NAT traversal mode parameter is borrowed from 1391 [RFC5770]. The format of the NAT_TRAVERSAL_MODE parameter is similar 1392 to the format of the ESP_TRANSFORM parameter in [RFC7402] and is 1393 shown in Figure 10. This specification defines traversal mode 1394 identifier for ICE-HIP-UDP. The identifier RESERVED is reserved for 1395 future use. Future specifications may define more traversal modes. 1397 0 1 2 3 1398 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 1399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1400 | Type | Length | 1401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1402 | Reserved | Mode ID #1 | 1403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1404 | Mode ID #2 | Mode ID #3 | 1405 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1406 | Mode ID #n | Padding | 1407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1409 Type 608 1410 Length length in octets, excluding Type, Length, and padding 1411 Reserved zero when sent, ignored when received 1412 Mode ID defines the proposed or selected NAT traversal mode(s) 1414 The following NAT traversal mode IDs are defined: 1416 ID name Value 1417 RESERVED 0 1418 ICE-HIP-UDP 3 1420 Figure 10: Format of the NAT_TRAVERSAL_MODE Parameter 1422 The sender of a NAT_TRAVERSAL_MODE parameter MUST make sure that 1423 there are no more than six (6) Mode IDs in one NAT_TRAVERSAL_MODE 1424 parameter. Conversely, a recipient MUST be prepared to handle 1425 received NAT traversal mode parameters that contain more than six 1426 Mode IDs by accepting the first six Mode IDs and dropping the rest. 1427 The limited number of Mode IDs sets the maximum size of the 1428 NAT_TRAVERSAL_MODE parameter. The modes MUST be in preference order, 1429 most preferred mode(s) first. 1431 5.5. Connectivity Check Transaction Pacing Parameter 1433 The TRANSACTION_PACING is a new parameter, and it shown in Figure 11 1434 contains only the connectivity check pacing value, expressed in 1435 milliseconds, as a 32-bit unsigned integer. 1437 0 1 2 3 1438 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 1439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1440 | Type | Length | 1441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1442 | Min Ta | 1443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1445 Type 610 1446 Length 4 1447 Min Ta the minimum connectivity check transaction pacing 1448 value the host would use 1450 Figure 11: Format of the TRANSACTION_PACING Parameter 1452 5.6. Relay and Registration Parameters 1454 The format of the REG_FROM, RELAY_FROM, and RELAY_TO parameters is 1455 shown in Figure 12. All parameters are identical except for the 1456 type. REG_FROM is the only parameter covered with the signature. 1458 0 1 2 3 1459 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 1460 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1461 | Type | Length | 1462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1463 | Port | Protocol | Reserved | 1464 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1465 | | 1466 | Address | 1467 | | 1468 | | 1469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1471 Type REG_FROM: 950 1472 RELAY_FROM: 63998 1473 RELAY_TO: 64002 1474 Length 20 1475 Port transport port number; zero when plain IP is used 1476 Protocol IANA assigned, Internet Protocol number. 1477 17 for UDP, 0 for plain IP 1478 Reserved reserved for future use; zero when sent, ignored 1479 when received 1480 Address an IPv6 address or an IPv4 address in "IPv4-Mapped 1481 IPv6 address" format 1483 Figure 12: Format of the REG_FROM, RELAY_FROM, and RELAY_TO 1484 Parameters 1486 REG_FROM contains the transport address and protocol from which the 1487 HIP relay server sees the registration coming. RELAY_FROM contains 1488 the address from which the relayed packet was received by the relay 1489 server and the protocol that was used. RELAY_TO contains the same 1490 information about the address to which a packet should be forwarded. 1492 5.7. LOCATOR_SET Parameter 1494 This specification reuses the format for UDP-based locators specified 1495 in [RFC5770] to be used for communicating the address candidates 1496 between two hosts. The generic and NAT-traversal-specific locator 1497 parameters are illustrated in Figure 13. 1499 0 1 2 3 1500 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 1501 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1502 | Type | Length | 1503 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1504 | Traffic Type | Locator Type | Locator Length| Reserved |P| 1505 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1506 | Locator Lifetime | 1507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1508 | Locator | 1509 | | 1510 | | 1511 | | 1512 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1513 . . 1514 . . 1515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1516 | Traffic Type | Loc Type = 2 | Locator Length| Reserved |P| 1517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1518 | Locator Lifetime | 1519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1520 | Transport Port | Transp. Proto| Kind | 1521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1522 | Priority | 1523 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1524 | SPI | 1525 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1526 | Address | 1527 | | 1528 | | 1529 | | 1530 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1532 Figure 13: LOC_SET Parameter 1534 The individual fields in the LOCATOR_SET parameter are described in 1535 Table 1. 1537 +-----------+----------+--------------------------------------------+ 1538 | Field | Value(s) | Purpose | 1539 +-----------+----------+--------------------------------------------+ 1540 | Type | 193 | Parameter type | 1541 | Length | Variable | Length in octets, excluding Type and | 1542 | | | Length fields and padding | 1543 | Traffic | 0-2 | Is the locator for HIP signaling (1), for | 1544 | Type | | ESP (2), or for both (0) | 1545 | Locator | 2 | "Transport address" locator type | 1546 | Type | | | 1547 | Locator | 7 | Length of the fields after Locator | 1548 | Length | | Lifetime in 4-octet units | 1549 | Reserved | 0 | Reserved for future extensions | 1550 | Preferred | 0 or 1 | Set to 1 for a Locator in R1 if the | 1551 | (P) bit | | Responder can use it for the rest of the | 1552 | | | base exchange, otherwise set to zero | 1553 | Locator | Variable | Locator lifetime in seconds | 1554 | Lifetime | | | 1555 | Transport | Variable | Transport layer port number | 1556 | Port | | | 1557 | Transport | Variable | IANA assigned, transport layer Internet | 1558 | Protocol | | Protocol number. Currently only UDP (17) | 1559 | | | is supported. | 1560 | Kind | Variable | 0 for host, 1 for server reflexive, 2 for | 1561 | | | peer reflexive or 3 for relayed address | 1562 | Priority | Variable | Locator's priority as described in | 1563 | | | [RFC5245] | 1564 | SPI | Variable | Security Parameter Index (SPI) value that | 1565 | | | the host expects to see in incoming ESP | 1566 | | | packets that use this locator | 1567 | Address | Variable | IPv6 address or an "IPv4-Mapped IPv6 | 1568 | | | address" format IPv4 address [RFC4291] | 1569 +-----------+----------+--------------------------------------------+ 1571 Table 1: Fields of the LOCATOR_SET Parameter 1573 5.8. RELAY_HMAC Parameter 1575 As specified in [RFC5770], the RELAY_HMAC parameter value has the TLV 1576 type 65520. It has the same semantics as RVS_HMAC 1577 [I-D.ietf-hip-rfc5204-bis]. 1579 5.9. Registration Types 1581 The REG_INFO, REG_REQ, REG_RESP, and REG_FAILED parameters contain 1582 Registration Type [I-D.ietf-hip-rfc5203-bis] values for HIP relay 1583 server registration. The value for RELAY_UDP_HIP is 2 as specified 1584 in [RFC5770]. 1586 5.10. Notify Packet Types 1588 A HIP relay server and end-hosts can use NOTIFY packets to signal 1589 different error conditions. The NOTIFY packet types are the same as 1590 in [RFC5770]. 1592 The Notify Packet Types [RFC7401] are shown below. The Notification 1593 Data field for the error notifications SHOULD contain the HIP header 1594 of the rejected packet and SHOULD be empty for the 1595 CONNECTIVITY_CHECKS_FAILED type. 1597 NOTIFICATION PARAMETER - ERROR TYPES Value 1598 ------------------------------------ ----- 1600 NO_VALID_NAT_TRAVERSAL_MODE_PARAMETER 60 1602 If a HIP relay server does not forward a base exchange packet due 1603 to missing NAT traversal mode parameter, or the Initiator selects 1604 a NAT traversal mode that the Responder did not expect, the relay 1605 or the Responder may send back a NOTIFY error packet with this 1606 type. 1608 CONNECTIVITY_CHECKS_FAILED 61 1610 Used by the end-hosts to signal that NAT traversal connectivity 1611 checks failed and did not produce a working path. 1613 MESSAGE_NOT_RELAYED 62 1615 Used by a HIP relay server to signal that is was not able or 1616 willing to relay a HIP packet. 1618 5.11. ESP Data Packets 1620 The format for ESP data packets is identical to [RFC5770]. 1622 [RFC3948] describes the UDP encapsulation of the IPsec ESP transport 1623 and tunnel mode. On the wire, the HIP ESP packets do not differ from 1624 the transport mode ESP, and thus the encapsulation of the HIP ESP 1625 packets is same as the UDP encapsulation transport mode ESP. 1626 However, the (semantic) difference to Bound End-to-End Tunnel (BEET) 1627 mode ESP packets used by HIP is that IP header is not used in BEET 1628 integrity protection calculation. 1630 During the HIP base exchange, the two peers exchange parameters that 1631 enable them to define a pair of IPsec ESP security associations (SAs) 1632 as described in [RFC7402]. When two peers perform a UDP-encapsulated 1633 base exchange, they MUST define a pair of IPsec SAs that produces 1634 UDP-encapsulated ESP data traffic. 1636 The management of encryption/authentication protocols and SPIs is 1637 defined in [RFC7402]. The UDP encapsulation format and processing of 1638 HIP ESP traffic is described in Section 6.1 of [RFC7402]. 1640 5.12. RELAYED_ADDRESS and MAPPED_ADDRESS Parameters 1642 While the type values are new, the format of the RELAYED_ADDRESS and 1643 MAPPED_ADDRESS parameters (Figure 14) is identical to REG_FROM, 1644 RELAY_FROM and RELAY_TO parameters. This document specifies only use 1645 of UDP relaying, and, thus, only protocol 17 is allowed. However, 1646 future documents may specify support for other protocols. 1648 0 1 2 3 1649 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 1650 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1651 | Type | Length | 1652 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1653 | Port | Protocol | Reserved | 1654 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1655 | | 1656 | Address | 1657 | | 1658 | | 1659 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1661 Type [TBD by IANA; 1662 RELAYED_ADDRESS: 4650 1663 MAPPED_ADDRESS: 4660] 1664 Length 20 1665 Port the UDP port number 1666 Protocol IANA assigned, Internet Protocol number (17 for UDP) 1667 Reserved reserved for future use; zero when sent, ignored 1668 when received 1669 Address an IPv6 address or an IPv4 address in "IPv4-Mapped 1670 IPv6 address" format 1672 Figure 14: Format of the RELAYED_ADDRESS and MAPPED_ADDRESS 1673 Parameters 1675 5.13. PEER_PERMISSION Parameter 1677 The format of the new PEER_PERMISSION parameter is shown in 1678 Figure 15. The parameter is used for setting up and refreshing 1679 forwarding rules and permissions at the data relay for data packets. 1680 The parameter contains one or more sets of Port, Protocol, Address, 1681 Outbound SPI (OSPI), and Inbound SPI (ISPI) values. One set defines 1682 a rule for one peer address. 1684 0 1 2 3 1685 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 1686 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1687 | Type | Length | 1688 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1689 | Port | Protocol | Reserved | 1690 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1691 | | 1692 | Address | 1693 | | 1694 | | 1695 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1696 | OSPI | 1697 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1698 | ISPI | 1699 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1700 | | 1701 | ... | 1702 | | 1703 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1705 Type [TBD by IANA; 4680] 1706 Length length in octets, excluding Type and Length 1707 Port the transport layer (UDP) port number of the peer 1708 Protocol IANA assigned, Internet Protocol number (17 for UDP) 1709 Reserved reserved for future use; zero when sent, ignored 1710 when received 1711 Address an IPv6 address, or an IPv4 address in "IPv4-Mapped 1712 IPv6 address" format, of the peer 1713 OSPI the outbound SPI value the registered host is using for 1714 the peer with the Address and Port 1715 ISPI the inbound SPI value the registered host is using for 1716 the peer with the Address and Port 1718 Figure 15: Format of the PEER_PERMISSION Parameter 1720 5.14. HIP Connectivity Check Packets 1722 The connectivity request messages are HIP UPDATE packets containing a 1723 new CANDIDATE_PRIORITY parameter (Figure 16). Response UPDATE 1724 packets contain a MAPPED_ADDRESS parameter (Figure 14). 1726 0 1 2 3 1727 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1728 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1729 | Type | Length | 1730 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1731 | Priority | 1732 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1734 Type [TBD by IANA; 4700] 1735 Length 4 1736 Priority the priority of a (potential) peer reflexive candidate 1738 Figure 16: Format of the CANDIDATE_PRIORITY Parameter 1740 5.15. NOMINATE parameter 1742 Figure Figure 17 shows the NOMINATE parameter that is used to 1743 conclude the candidate nomination process. 1745 0 1 2 3 1746 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 1747 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1748 | Type | Length | 1749 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1750 | Reserved | 1751 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1753 Type [TBD by IANA; 4710] 1754 Length 4 1755 Reserved Reserved for future extension purposes 1757 Figure 17: Format of the NOMINATE Parameter 1759 6. Security Considerations 1761 The security considerations are the same as in [RFC5770], but are 1762 repeated here for completeness sake. 1764 6.1. Privacy Considerations 1766 The locators are in plain text format in favor of inspection at HIP- 1767 aware middleboxes in the future. The current document does not 1768 specify encrypted versions of LOCATOR_SETs, even though it could be 1769 beneficial for privacy reasons to avoid disclosing them to 1770 middleboxes. 1772 It is also possible that end-users may not want to reveal all 1773 locators to each other. For example, tracking the physical location 1774 of a multihoming end-host may become easier if it reveals all 1775 locators to its peer during a base exchange. Also, revealing host 1776 addresses exposes information about the local topology that may not 1777 be allowed in all corporate environments. For these two reasons, an 1778 end-host may exclude certain host addresses from its LOCATOR_SET 1779 parameter. However, such behavior creates non-optimal paths when the 1780 hosts are located behind the same NAT. Especially, this could be 1781 problematic with a legacy NAT that does not support routing from the 1782 private address realm back to itself through the outer address of the 1783 NAT. This scenario is referred to as the hairpin problem [RFC5128]. 1784 With such a legacy NAT, the only option left would be to use a 1785 relayed transport address from a TURN server. 1787 The use of HIP and data relays can be also useful for privacy 1788 purposes. For example, a privacy concerned Responder may reveal only 1789 its HIP relay server and Relayed candidates to Initiators. This same 1790 mechanism also protects the Responder against Denial-of-Service (DoS) 1791 attacks by allowing the Responder to initiate new connections even if 1792 its relays would be unavailable due to a DoS attack. 1794 6.2. Opportunistic Mode 1796 A HIP relay server should have one address per relay client when a 1797 HIP relay is serving more than one relay client and supports 1798 opportunistic mode. Otherwise, it cannot be guaranteed that the HIP 1799 relay server can deliver the I1 packet to the intended recipient. 1801 6.3. Base Exchange Replay Protection for HIP Relay Server 1803 In certain scenarios, it is possible that an attacker, or two 1804 attackers, can replay an earlier base exchange through a HIP relay 1805 server by masquerading as the original Initiator and Responder. The 1806 attack does not require the attacker(s) to compromise the private 1807 key(s) of the attacked host(s). However, for this attack to succeed, 1808 the Responder has to be disconnected from the HIP relay server. 1810 The relay can protect itself against replay attacks by becoming 1811 involved in the base exchange by introducing nonces that the end- 1812 hosts (Initiator and Responder) are required to sign. One way to do 1813 this is to add ECHO_REQUEST_M parameters to the R1 and I2 packets as 1814 described in [HIP-MIDDLE] and drop the I2 or R2 packets if the 1815 corresponding ECHO_RESPONSE_M parameters are not present. 1817 6.4. Demuxing Different HIP Associations 1819 Section 5.1 of [RFC3948] describes a security issue for the UDP 1820 encapsulation in the standard IP tunnel mode when two hosts behind 1821 different NATs have the same private IP address and initiate 1822 communication to the same Responder in the public Internet. The 1823 Responder cannot distinguish between two hosts, because security 1824 associations are based on the same inner IP addresses. 1826 This issue does not exist with the UDP encapsulation of HIP ESP 1827 transport format because the Responder uses HITs to distinguish 1828 between different Initiators. 1830 6.5. Reuse of Ports at the Data Relay 1832 If the data relay uses the same relayed address and port for multiple 1833 registered hosts, it appears to all the peers, and their firewalls, 1834 that all the registered hosts using the relay are at the same 1835 address. Thus, a stateful firewall may allow packets pass from hosts 1836 that would not normally be able to send packets to a peer behind the 1837 firewall. Therefore, a HIP data relay SHOULD NOT re-use the port 1838 numbers. If port numbers need to be re-used, the relay SHOULD have a 1839 sufficiently large pool of port numbers and select ports from the 1840 pool randomly to decrease the chances of a registered host obtaining 1841 the same address that a another host behind the same firewall is 1842 using. 1844 7. IANA Considerations 1846 This section is to be interpreted according to [RFC5226]. 1848 This document updates the IANA Registry for HIP Parameter Types 1849 [RFC7401] by assigning new HIP Parameter Type values for the new HIP 1850 Parameters: RELAYED_ADDRESS, MAPPED_ADDRESS (defined in 1851 Section 5.12), and PEER_PERMISSION (defined in Section 5.13). 1853 This document also updates the IANA Registry for HIP NAT traversal 1854 modes [RFC5770] by assigning value for the NAT traversal mode ICE- 1855 HIP-UDP (defined in XX FIXME target="sec:hip-nat-traversal-mode". 1857 This document defines additional registration types for the HIP 1858 Registration Extension [I-D.ietf-hip-rfc5203-bis] that allow 1859 registering with a HIP relay server for ESP relaying service: 1861 RELAY_UDP_ESP (defined in Section 4.1; and performing server 1862 reflexive candidate discovery: CANDIDATE_DISCOVERY (defined in 1863 Section 4.2). 1865 8. Contributors 1867 Marcelo Bagnulo, Philip Matthews and Hannes Tschofenig have 1868 contributed to [RFC5770]. This document leans heavily on the work in 1869 the RFC. 1871 9. Acknowledgments 1873 Thanks to Jonathan Rosenberg and the rest of the MMUSIC WG folks for 1874 the excellent work on ICE. In addition, the authors would like to 1875 thank Andrei Gurtov, Simon Schuetz, Martin Stiemerling, Lars Eggert, 1876 Vivien Schmitt, and Abhinav Pathak for their contributions and Tobias 1877 Heer, Teemu Koponen, Juhana Mattila, Jeffrey M. Ahrenholz, Kristian 1878 Slavov, Janne Lindqvist, Pekka Nikander, Lauri Silvennoinen, Jukka 1879 Ylitalo, Juha Heinanen, Joakim Koskela, Samu Varjonen, Dan Wing, and 1880 Jani Hautakorpi for their comments to [RFC5770], which is the basis 1881 for this document. 1883 10. References 1885 10.1. Normative References 1887 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1888 Requirement Levels", BCP 14, RFC 2119, 1889 DOI 10.17487/RFC2119, March 1997, 1890 . 1892 [RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T. 1893 Henderson, "Host Identity Protocol Version 2 (HIPv2)", 1894 RFC 7401, DOI 10.17487/RFC7401, April 2015, 1895 . 1897 [RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol 1898 (HIP) Architecture", RFC 4423, DOI 10.17487/RFC4423, May 1899 2006, . 1901 [I-D.ietf-hip-rfc5203-bis] 1902 Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) 1903 Registration Extension", draft-ietf-hip-rfc5203-bis-10 1904 (work in progress), January 2016. 1906 [I-D.ietf-hip-rfc5204-bis] 1907 Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) 1908 Rendezvous Extension", draft-ietf-hip-rfc5204-bis-07 (work 1909 in progress), December 2015. 1911 [I-D.ietf-hip-rfc5206-bis] 1912 Henderson, T., Vogt, C., and J. Arkko, "Host Mobility with 1913 the Host Identity Protocol", draft-ietf-hip-rfc5206-bis-12 1914 (work in progress), May 2016. 1916 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 1917 (ICE): A Protocol for Network Address Translator (NAT) 1918 Traversal for Offer/Answer Protocols", RFC 5245, April 1919 2010. 1921 [RFC5766] Rosenberg, J., Mahy, R., and P. Matthews, "Traversal Using 1922 Relays around NAT (TURN): Relay Extensions to Session 1923 Traversal Utilities for NAT (STUN)", RFC 5766, April 2010. 1925 [RFC5770] Komu, M., Henderson, T., Tschofenig, H., Melen, J., and A. 1926 Keranen, Ed., "Basic Host Identity Protocol (HIP) 1927 Extensions for Traversal of Network Address Translators", 1928 RFC 5770, DOI 10.17487/RFC5770, April 2010, 1929 . 1931 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 1932 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 1933 DOI 10.17487/RFC5389, October 2008, 1934 . 1936 [RFC7402] Jokela, P., Moskowitz, R., and J. Melen, "Using the 1937 Encapsulating Security Payload (ESP) Transport Format with 1938 the Host Identity Protocol (HIP)", RFC 7402, 1939 DOI 10.17487/RFC7402, April 2015, 1940 . 1942 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 1943 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 1944 2006, . 1946 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1947 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1948 DOI 10.17487/RFC5226, May 2008, 1949 . 1951 10.2. Informative References 1953 [RFC5201] Moskowitz, R., Nikander, P., Jokela, P., Ed., and T. 1954 Henderson, "Host Identity Protocol", RFC 5201, 1955 DOI 10.17487/RFC5201, April 2008, 1956 . 1958 [RFC5207] Stiemerling, M., Quittek, J., and L. Eggert, "NAT and 1959 Firewall Traversal Issues of Host Identity Protocol (HIP) 1960 Communication", RFC 5207, DOI 10.17487/RFC5207, April 1961 2008, . 1963 [MMUSIC-ICE] 1964 Rosenberg, J., "Guidelines for Usage of Interactive 1965 Connectivity Establishment (ICE) by non Session Initiation 1966 Protocol (SIP) Protocols", Work in Progress, July 2008. 1968 [RFC5128] Srisuresh, P., Ford, B., and D. Kegel, "State of Peer-to- 1969 Peer (P2P) Communication across Network Address 1970 Translators (NATs)", RFC 5128, DOI 10.17487/RFC5128, March 1971 2008, . 1973 [HIP-MIDDLE] 1974 Heer, T., Wehrle, K., and M. Komu, "End-Host 1975 Authentication for HIP Middleboxes", Work in Progress, 1976 February 2009. 1978 [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. 1979 Stenberg, "UDP Encapsulation of IPsec ESP Packets", 1980 RFC 3948, DOI 10.17487/RFC3948, January 2005, 1981 . 1983 Appendix A. Selecting a Value for Check Pacing 1985 Selecting a suitable value for the connectivity check transaction 1986 pacing is essential for the performance of connectivity check-based 1987 NAT traversal. The value should not be so small that the checks 1988 cause network congestion or overwhelm the NATs. On the other hand, a 1989 pacing value that is too high makes the checks last for a long time, 1990 thus increasing the connection setup delay. 1992 The Ta value may be configured by the user in environments where the 1993 network characteristics are known beforehand. However, if the 1994 characteristics are not known, it is recommended that the value is 1995 adjusted dynamically. In this case, it's recommended that the hosts 1996 estimate the round-trip time (RTT) between them and set the minimum 1997 Ta value so that only two connectivity check messages are sent on 1998 every RTT. 2000 One way to estimate the RTT is to use the time it takes for the HIP 2001 relay server registration exchange to complete; this would give an 2002 estimate on the registering host's access link's RTT. Also, the I1/ 2003 R1 exchange could be used for estimating the RTT, but since the R1 2004 can be cached in the network, or the relaying service can increase 2005 the delay notably, it is not recommended. 2007 Appendix B. Base Exchange through a Rendezvous Server 2009 When the Initiator looks up the information of the Responder from 2010 DNS, it's possible that it discovers a rendezvous server (RVS) record 2011 [I-D.ietf-hip-rfc5204-bis]. In this case, if the Initiator uses NAT 2012 traversal methods described in this document, it MAY use its own HIP 2013 relay server to forward HIP traffic to the rendezvous server. The 2014 Initiator will send the I1 packet using its HIP relay server, which 2015 will then forward it to the RVS server of the Responder. In this 2016 case, the value of the protocol field in the RELAY_TO parameter MUST 2017 be IP since RVS does not support UDP-encapsulated base exchange 2018 packets. The Responder will send the R1 packet directly to the 2019 Initiator's HIP relay server and the following I2 and R2 packets are 2020 also sent directly using the relay. 2022 In case the Initiator is not able to distinguish which records are 2023 RVS address records and which are Responder's address records (e.g., 2024 if the DNS server did not support HIP extensions), the Initiator 2025 SHOULD first try to contact the Responder directly, without using a 2026 HIP relay server. If none of the addresses are reachable, it MAY try 2027 them out using its own HIP relay server as described above. 2029 Authors' Addresses 2031 Ari Keranen 2032 Ericsson 2033 Hirsalantie 11 2034 02420 Jorvas 2035 Finland 2037 Email: ari.keranen@ericsson.com 2039 Jan Melen 2040 Ericsson 2041 Hirsalantie 11 2042 02420 Jorvas 2043 Finland 2045 Email: jan.melen@ericsson.com 2046 Miika Komu (editor) 2047 Ericsson 2048 Hirsalantie 11 2049 02420 Jorvas 2050 Finland 2052 Email: miika.komu@ericsson.com