idnits 2.17.1 draft-ietf-hip-nat-traversal-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 927 has weird spacing: '...eserved zero...' == Line 964 has weird spacing: '... Min Ta the ...' == Line 996 has weird spacing: '...eserved rese...' == Line 998 has weird spacing: '...Address an ...' -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 23, 2009) is 5297 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 4423 (Obsoleted by RFC 9063) ** Obsolete normative reference: RFC 5201 (Obsoleted by RFC 7401) ** Obsolete normative reference: RFC 5202 (Obsoleted by RFC 7402) ** Obsolete normative reference: RFC 5203 (Obsoleted by RFC 8003) ** Obsolete normative reference: RFC 5204 (Obsoleted by RFC 8004) ** Obsolete normative reference: RFC 5206 (Obsoleted by RFC 8046) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** Obsolete normative reference: RFC 5389 (Obsoleted by RFC 8489) == Outdated reference: A later version (-04) exists of draft-heer-hip-middle-auth-02 Summary: 9 errors (**), 0 flaws (~~), 7 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 HIP Working Group M. Komu 3 Internet-Draft HIIT 4 Intended status: Experimental T. Henderson 5 Expires: April 26, 2010 The Boeing Company 6 H. Tschofenig 7 Nokia Siemens Networks 8 J. Melen 9 A. Keranen, Ed. 10 Ericsson Research Nomadiclab 11 October 23, 2009 13 Basic HIP Extensions for Traversal of Network Address Translators 14 draft-ietf-hip-nat-traversal-09.txt 16 Status of this Memo 18 This Internet-Draft is submitted to IETF in full conformance with the 19 provisions of BCP 78 and BCP 79. This document may contain material 20 from IETF Documents or IETF Contributions published or made publicly 21 available before November 10, 2008. The person(s) controlling the 22 copyright in some of this material may not have granted the IETF 23 Trust the right to allow modifications of such material outside the 24 IETF Standards Process. Without obtaining an adequate license from 25 the person(s) controlling the copyright in such materials, this 26 document may not be modified outside the IETF Standards Process, and 27 derivative works of it may not be created outside the IETF Standards 28 Process, except to format it for publication as an RFC or to 29 translate it into languages other than English. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF), its areas, and its working groups. Note that 33 other groups may also distribute working documents as Internet- 34 Drafts. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 The list of current Internet-Drafts can be accessed at 42 http://www.ietf.org/ietf/1id-abstracts.txt. 44 The list of Internet-Draft Shadow Directories can be accessed at 45 http://www.ietf.org/shadow.html. 47 This Internet-Draft will expire on April 26, 2010. 49 Copyright Notice 51 Copyright (c) 2009 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents in effect on the date of 56 publication of this document (http://trustee.ietf.org/license-info). 57 Please review these documents carefully, as they describe your rights 58 and restrictions with respect to this document. 60 Abstract 62 This document specifies extensions to the Host Identity Protocol 63 (HIP) to facilitate Network Address Translator (NAT) traversal. The 64 extensions are based on the use of the Interactive Connectivity 65 Establishment (ICE) methodology to discover a working path between 66 two end-hosts, and on standard techniques for encapsulating 67 Encapsulating Security Payload (ESP) packets within the User Datagram 68 Protocol (UDP). This document also defines elements of a procedure 69 for NAT traversal, including the optional use of a HIP relay server. 70 With these extensions HIP is able to work in environments that have 71 NATs and provides a generic NAT traversal solution to higher-layer 72 networking applications. 74 Table of Contents 76 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 77 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 78 3. Overview of Operation . . . . . . . . . . . . . . . . . . . . 7 79 4. Protocol Description . . . . . . . . . . . . . . . . . . . . . 8 80 4.1. Relay Registration . . . . . . . . . . . . . . . . . . . . 8 81 4.2. ICE Candidate Gathering . . . . . . . . . . . . . . . . . 10 82 4.3. NAT Traversal Mode Negotiation . . . . . . . . . . . . . . 10 83 4.4. Connectivity Check Pacing Negotiation . . . . . . . . . . 12 84 4.5. Base Exchange via HIP Relay Server . . . . . . . . . . . . 12 85 4.6. ICE Connectivity Checks . . . . . . . . . . . . . . . . . 15 86 4.7. NAT Keepalives . . . . . . . . . . . . . . . . . . . . . . 15 87 4.8. Base Exchange without ICE Connectivity Checks . . . . . . 16 88 4.9. Initiating a Base Exchange both with and without UDP 89 Encapsulation . . . . . . . . . . . . . . . . . . . . . . 17 90 4.10. Sending Control Packets after the Base Exchange . . . . . 18 91 5. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . . 18 92 5.1. HIP Control Packets . . . . . . . . . . . . . . . . . . . 18 93 5.2. Connectivity Checks . . . . . . . . . . . . . . . . . . . 19 94 5.3. Keepalives . . . . . . . . . . . . . . . . . . . . . . . . 20 95 5.4. NAT Traversal Mode Parameter . . . . . . . . . . . . . . . 20 96 5.5. Connectivity Check Transaction Pacing Parameter . . . . . 21 97 5.6. Relay and Registration Parameters . . . . . . . . . . . . 22 98 5.7. LOCATOR Parameter . . . . . . . . . . . . . . . . . . . . 23 99 5.8. RELAY_HMAC Parameter . . . . . . . . . . . . . . . . . . . 24 100 5.9. Registration Types . . . . . . . . . . . . . . . . . . . . 24 101 5.10. Notify Packet Types . . . . . . . . . . . . . . . . . . . 25 102 5.11. ESP Data Packets . . . . . . . . . . . . . . . . . . . . . 25 103 6. Security Considerations . . . . . . . . . . . . . . . . . . . 26 104 6.1. Privacy Considerations . . . . . . . . . . . . . . . . . . 26 105 6.2. Opportunistic Mode . . . . . . . . . . . . . . . . . . . . 26 106 6.3. Base Exchange Replay Protection for HIP Relay Server . . . 26 107 6.4. Demuxing Different HIP Associations . . . . . . . . . . . 27 108 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 109 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 28 110 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28 111 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 112 10.1. Normative References . . . . . . . . . . . . . . . . . . . 28 113 10.2. Informative References . . . . . . . . . . . . . . . . . . 29 114 Appendix A. Selecting a Value for Check Pacing . . . . . . . . . 30 115 Appendix B. Base Exchange through a Rendezvous Server . . . . . . 31 116 Appendix C. Document Revision History . . . . . . . . . . . . . . 31 117 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31 119 1. Introduction 121 HIP [RFC5201] is defined as a protocol that runs directly over IPv4 122 or IPv6, and HIP coordinates the setup of ESP security associations 123 [RFC5202] that are also specified to run over IPv4 or IPv6. This 124 approach is known to have problems traversing NATs and other 125 middleboxes [RFC5207]. This document defines HIP extensions for the 126 traversal of both Network Address Translator (NAT) and Network 127 Address and Port Translator (NAPT) middleboxes. The document 128 generally uses the term NAT to refer to these types of middleboxes. 130 Currently deployed NAT devices do not operate consistently even 131 though a recommended behavior is described in [RFC4787]. The HIP 132 protocol extensions in this document make as few assumptions as 133 possible about the behavior of the NAT devices so that NAT traversal 134 will work even with legacy NAT devices. The purpose of these 135 extensions is to allow two HIP-enabled hosts to communicate with each 136 other even if one or both of the communicating hosts are in a network 137 that is behind one or more NATs. 139 Using the extensions defined in this document, HIP end-hosts use 140 techniques drawn from the Interactive Connectivity Establishment 141 (ICE) methodology [I-D.ietf-mmusic-ice] to find operational paths for 142 the HIP control protocol and for ESP encapsulated data traffic. The 143 hosts test connectivity between different locators and try to 144 discover a direct end-to-end path between them. However, with some 145 legacy NATs, utilizing the shortest path between two end-hosts 146 located behind NATs is not possible without relaying the traffic 147 through a relay, such as a TURN server [RFC5128]. Because relaying 148 traffic increases the roundtrip delay and consumes resources from the 149 relay, with the extensions described in this document, hosts try to 150 avoid using the TURN server whenever possible. 152 HIP has defined a Rendezvous Server [RFC5204] to allow for mobile HIP 153 hosts to establish a stable point-of-contact in the Internet. This 154 document defines extensions to the Rendezvous Server that solve the 155 same problems but for both NATed and non-NATed networks. The 156 extended Rendezvous Server, called a "HIP relay server", forwards HIP 157 control packets between an Initiator and a Responder, allowing hosts 158 to be located behind NATs. This behavior is in contrast to the HIP 159 rendezvous service that forwards only the initial I1 packet of the 160 base exchange; an approach which is less likely to work in a NATed 161 environment [RFC5128]. Therefore, when using relays to traverse 162 NATs, HIP uses a HIP relay server for the control traffic and a TURN 163 server for the data traffic. 165 The basis for the connectivity checks is ICE [I-D.ietf-mmusic-ice]. 166 [I-D.ietf-mmusic-ice] describes ICE as follows: 168 "The Interactive Connectivity Establishment (ICE) methodology is a 169 technique for NAT traversal for UDP-based media streams (though 170 ICE can be extended to handle other transport protocols, such as 171 TCP) established by the offer/answer model. ICE is an extension 172 to the offer/answer model, and works by including a multiplicity 173 of IP addresses and ports in SDP offers and answers, which are 174 then tested for connectivity by peer-to-peer connectivity checks. 175 The IP addresses and ports included in the SDP and the 176 connectivity checks are performed using the revised STUN 177 specification [RFC5389], now renamed to Session Traversal 178 Utilities for NAT." 180 The standard ICE [I-D.ietf-mmusic-ice] is specified with SIP in mind 181 and it has some features that are not necessary or suitable as such 182 for other protocols. [I-D.rosenberg-mmusic-ice-nonsip] gives 183 instructions and recommendations on how ICE can be used for other 184 protocols and this document follows those guidelines. 186 Two HIP hosts that implement this specification communicate their 187 locators to each other in the HIP base exchange. The locators are 188 then paired with the locators of the other endpoint and prioritized 189 according to recommended and local policies. These locator pairs are 190 then tested sequentially by both of the end hosts. The tests may 191 result in multiple operational pairs but ICE procedures determine a 192 single preferred address pair to be used for subsequent 193 communication. 195 In summary, the extensions in this document define: 197 o UDP encapsulation of HIP packets 199 o UDP encapsulation of IPsec ESP packets 201 o registration extensions for HIP relay services 203 o how the ICE "offer" and "answer" are carried in the base exchange 205 o interaction with ICE connectivity check messages 207 o backwards compatibility issues with rendezvous servers 209 o a number of optimizations (such as when the ICE connectivity tests 210 can be omitted) 212 2. Terminology 214 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 215 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 216 document are to be interpreted as described in [RFC2119]. 218 This document borrows terminology from [RFC5201], [RFC5206], 219 [RFC4423], [I-D.ietf-mmusic-ice], and [RFC5389]. Additionally, the 220 following terms are used: 222 Rendezvous server: 223 A host that forwards I1 packets to the Responder. 225 HIP relay server: 226 A host that forwards any kind of HIP control packets between the 227 Initiator and the Responder. 229 TURN server: 230 A server that forwards data traffic between two end-hosts as 231 defined in [I-D.ietf-behave-turn]. 233 Locator: 234 As defined in [RFC5206]: "A name that controls how the packet is 235 routed through the network and demultiplexed by the end-host. It 236 may include a concatenation of traditional network addresses such 237 as an IPv6 address and end-to-end identifiers such as an ESP SPI. 238 It may also include transport port numbers or IPv6 Flow Labels as 239 demultiplexing context, or it may simply be a network address." 241 LOCATOR (written in capital letters): 242 Denotes a HIP control packet parameter that bundles multiple 243 locators together. 245 ICE offer: 246 The Initiator's LOCATOR parameter in a HIP I2 control packet. 248 ICE answer: 249 The Responder's LOCATOR parameter in a HIP R2 control packet. 251 Transport address: 252 Transport layer port and the corresponding IPv4/v6 address. 254 Candidate: 255 A transport address that is a potential point of contact for 256 receiving data. 258 Host candidate: 259 A candidate obtained by binding to a specific port from an IP 260 address on the host. 262 Server reflexive candidate: 263 A translated transport address of a host as observed by a HIP 264 relay server or a STUN/TURN server. 266 Peer reflexive candidate: 267 A translated transport address of a host as observed by its peer. 269 Relayed candidate: 270 A transport address that exists on a TURN server. Packets that 271 arrive at this address are relayed towards the TURN client. 273 3. Overview of Operation 275 +-------+ 276 | HIP | 277 +--------+ | Relay | +--------+ 278 | TURN | +-------+ | STUN | 279 | Server | / \ | Server | 280 +--------+ / \ +--------+ 281 / \ 282 / \ 283 / \ 284 / <- Signaling -> \ 285 / \ 286 +-------+ +-------+ 287 | NAT | | NAT | 288 +-------+ +-------+ 289 / \ 290 / \ 291 +-------+ +-------+ 292 | Init- | | Resp- | 293 | iator | | onder | 294 +-------+ +-------+ 296 Figure 1: Example network configuration 298 In an example configuration depicted in Figure 1, both Initiator and 299 Responder are behind one or more NATs, and both private networks are 300 connected to the public Internet. To be contacted from behind a NAT, 301 the Responder must be registered with a HIP relay server reachable on 302 the public Internet, and we assume as a starting point that the 303 Initiator knows both the Responder's HIT and the address of one of 304 its relay servers (how the Initiator learns of the Responder's relay 305 server is outside of the scope of this document, but may be through 306 DNS or another name service). 308 The first steps are for both the Initiator and Responder to register 309 with a relay server (need not be the same one) and gather a set of 310 address candidates. The hosts may use TURN and STUN servers for 311 gathering the candidates. Next, the HIP base exchange is carried out 312 by encapsulating the HIP control packets in UDP datagrams and sending 313 them through the Responder's relay server. As part of the base 314 exchange, each HIP host learns of the peer's candidate addresses 315 through the ICE offer/answer procedure embedded in the base exchange. 317 Once the base exchange is completed, HIP has established a working 318 communication session (for signaling) via a relay server, but the 319 hosts still work to find a better path, preferably without a relay, 320 for the ESP data flow. For this, ICE connectivity checks are carried 321 out until a working pair of addresses is discovered. At the end of 322 the procedure, if successful, the hosts will have enabled a UDP-based 323 flow that traverses both NATs, with the data flowing directly from 324 NAT to NAT or via a TURN server. Further HIP signaling can be sent 325 over the same address/port pair and is demultiplexed from data 326 traffic via a marker in the payload. Finally, NAT keepalives will be 327 sent as needed. 329 If either one of the hosts knows that it is not behind a NAT, hosts 330 can negotiate during the base exchange a different mode of NAT 331 traversal that does not use ICE connectivity checks, but only UDP 332 encapsulation of HIP and ESP. Also, it is possible for the Initiator 333 to simultaneously try a base exchange with and without UDP 334 encapsulation. If a base exchange without UDP encapsulation 335 succeeds, no ICE connectivity checks or UDP encapsulation of ESP are 336 needed. 338 4. Protocol Description 340 This section describes the normative behavior of the protocol 341 extension. Examples of packet exchanges are provided for 342 illustration purposes. 344 4.1. Relay Registration 346 HIP rendezvous servers operate in non-NATed environments and their 347 use is described in [RFC5204]. This section specifies a new 348 middlebox extension, called the HIP relay server, for operating in 349 NATed environments. A HIP relay server forwards HIP control packets 350 between the Initiator and the Responder. 352 End-hosts cannot use the HIP relay service for forwarding the ESP 353 data plane. Instead, they use TURN servers [I-D.ietf-behave-turn] 354 for that. 356 A HIP relay server MUST silently drop packets to a HIP relay client 357 that has not previously registered with the HIP relay. The 358 registration process follows the generic registration extensions 359 defined in [RFC5203] and is illustrated in Figure 2. 361 HIP HIP 362 Relay Relay 363 Client Server 364 | 1. UDP(I1) | 365 +------------------------------------------------------->| 366 | | 367 | 2. UDP(R1(REG_INFO(RELAY_UDP_HIP))) | 368 |<-------------------------------------------------------+ 369 | | 370 | 3. UDP(I2(REG_REQ(RELAY_UDP_HIP))) | 371 +------------------------------------------------------->| 372 | | 373 | 4. UDP(R2(REG_RES(RELAY_UDP_HIP), REG_FROM)) | 374 |<-------------------------------------------------------+ 376 Figure 2: Example Registration with a HIP Relay 378 In step 1, the relay client (Initiator) starts the registration 379 procedure by sending an I1 packet over UDP. It is RECOMMENDED that 380 the Initiator selects a random port number from the ephemeral port 381 range 49152-65535 for initiating a base exchange. Alternatively, a 382 host MAY also use a single fixed port for initiating all outgoing 383 connections. However, the allocated port MUST be maintained until 384 all of the corresponding HIP Associations are closed. It is 385 RECOMMENDED that the HIP relay server listens to incoming connections 386 at UDP port HIPPORT. If some other port number is used, it needs to 387 be communicated to possible Initiators. 389 In step 2, the HIP relay server (Responder) lists the services that 390 it supports in the R1 packet. The support for HIP-over-UDP relaying 391 is denoted by the Registration Type value RELAY_UDP_HIP (see 392 Section 5.9). 394 In step 3, the Initiator selects the services it registers for and 395 lists them in the REG_REQ parameter. The Initiator registers for HIP 396 relay service by listing the RELAY_UDP_HIP value in the request 397 parameter. 399 In step 4, the Responder concludes the registration procedure with an 400 R2 packet and acknowledges the registered services in the REG_RES 401 parameter. The Responder denotes unsuccessful registrations (if any) 402 in the REG_FAILED parameter of R2. The Responder also includes a 403 REG_FROM parameter that contains the transport address of the client 404 as observed by the relay (Server Reflexive candidate). After the 405 registration, the client sends NAT keepalives periodically to the 406 relay to keep possible NAT bindings between the client and the relay 407 alive. The relay client maintains the HIP association with the relay 408 server as long as it requires relaying service from it. 410 4.2. ICE Candidate Gathering 412 If a host is going to use ICE, it needs to gather a set of address 413 candidates. The candidate gathering SHOULD be done as defined in 414 Section 4.1 of [I-D.ietf-mmusic-ice]. Candidates need to be gathered 415 for the UDP encapsulated flow of HIP and ESP traffic. This flow 416 corresponds to one ICE media stream and component. Since ICE 417 component IDs are not needed, they are not explicitly signaled and ID 418 value of 1 SHOULD be used for ICE processing, where needed. The 419 Initiator takes the role of the ICE controlling agent. 421 The candidate gathering can be done at any time, but it needs to be 422 done before sending an I2 or R2 in the base exchange if ICE is to be 423 used for the connectivity checks. It is RECOMMENDED that all three 424 types of candidates (host, server reflexive and relayed) are gathered 425 to maximize the probability of successful NAT traversal. However, if 426 no TURN server is used, and the host has only a single local IP 427 address to use, the host MAY use the local address as the only host 428 candidate and the address from the REG_FROM parameter discovered 429 during the relay registration as a server reflexive candidate. In 430 this case, no further candidate gathering is needed. 432 4.3. NAT Traversal Mode Negotiation 434 This section describes the usage of a new non-critical parameter 435 type. The presence of the parameter in a HIP base exchange means 436 that the end-host supports NAT traversal extensions described in this 437 document. As the parameter is non-critical (as defined in Section 438 5.2.1 of [RFC5201]), it can be ignored by an end-host which means 439 that the host does not support or is not willing to use these 440 extensions. 442 With registration with a HIP relay it is usually sufficient to use 443 UDP-ENCAPSULATION mode of NAT traversal since the relay should not be 444 behind a NAT. Thus, the relay SHOULD propose the UDP-ENCAPSULATION 445 mode as the preferred or only mode. The NAT traversal mode 446 negotiation in a HIP base exchange is illustrated in Figure 3. 448 Initiator Responder 449 | 1. UDP(I1) | 450 +--------------------------------------------------------------->| 451 | | 452 | 2. UDP(R1(.., NAT_TRAVERSAL_MODE(list of modes), ..)) | 453 |<---------------------------------------------------------------+ 454 | | 455 | 3. UDP(I2(.., NAT_TRAVERSAL_MODE(selected mode), LOCATOR, ..)) | 456 +--------------------------------------------------------------->| 457 | | 458 | 4. UDP(R2(.., LOCATOR, ..)) | 459 |<---------------------------------------------------------------+ 460 | | 462 Figure 3: Negotiation of NAT Traversal Mode 464 In step 1, the Initiator sends an I1 to the Responder. In step 2, 465 the Responder responds with an R1. The NAT_TRAVERSAL_MODE parameter 466 in R1 contains a list of NAT traversal modes the Responder supports. 467 The modes specified in this document are shown in Table 1 and their 468 values in Section 5.4. 470 +-------------------+-----------------------------------------------+ 471 | Type | Purpose | 472 +-------------------+-----------------------------------------------+ 473 | RESERVED | Reserved for future use | 474 | UDP-ENCAPSULATION | Use only UDP encapsulation of the HIP | 475 | | signaling traffic and ESP (no ICE | 476 | | connectivity checks) | 477 | ICE-STUN-UDP | UDP-encapsulated control and data traffic | 478 | | with ICE-based connectivity checks using STUN | 479 | | messages | 480 +-------------------+-----------------------------------------------+ 482 Table 1: NAT Traversal Modes 484 In step 3, the Initiator sends an I2 that includes a 485 NAT_TRAVERSAL_MODE parameter. It contains the mode selected by the 486 Initiator from the list of modes offered by the Responder. If ICE 487 mode was selected, the I2 also includes the "Transport address" 488 locators (as defined in Section 5.7) of the Initiator in a LOCATOR 489 parameter. The locators in I2 are the "ICE offer". 491 In step 4, the Responder concludes the base exchange with an R2 492 packet. If the Initiator chose ICE NAT traversal mode, the Responder 493 includes a LOCATOR parameter in the R2 packet. The locators in R2, 494 encoded like the locators in I2, are the "ICE answer". If the NAT 495 traversal mode selected by the Initiator is not supported by the 496 Responder, the Responder SHOULD reply with NOTIFY packet with type 497 NO_VALID_NAT_TRAVERSAL_MODE_PARAMETER and abort the base exchange. 499 4.4. Connectivity Check Pacing Negotiation 501 As explained in [I-D.ietf-mmusic-ice], when a NAT traversal mode with 502 connectivity checks is used, new transactions should not be started 503 too fast to avoid congestion and overwhelming the NATs. 505 For this purpose, during the base exchange, hosts can negotiate a 506 transaction pacing value, Ta, using a TRANSACTION_PACING parameter in 507 R1 and I2 packets. The parameter contains the minimum time 508 (expressed in milliseconds) the host would wait between two NAT 509 traversal transactions, such as starting a new connectivity check or 510 retrying a previous check. If a host does not include this parameter 511 in the base exchange, a Ta value of 500ms MUST be used as that host's 512 minimum value. The value that is used by both of the hosts is the 513 higher out of the two offered values. 515 Hosts SHOULD NOT use values smaller than 20ms for the minimum Ta, 516 since such values may not work well with some NATs, as explained in 517 [I-D.ietf-mmusic-ice]. The Initiator MUST NOT propose a smaller 518 value than what the Responder offered. 520 The minimum Ta value SHOULD be configurable, and if no value is 521 configured, value of 500ms MUST be used. Guidelines for selecting a 522 Ta value are given in Appendix A. Currently this feature applies 523 only to the ICE-STUN-UDP NAT traversal mode, but any other mode using 524 connectivity checks SHOULD utilize this feature. 526 4.5. Base Exchange via HIP Relay Server 528 This section describes how Initiator and Responder perform a base 529 exchange through a HIP relay server. The NAT traversal mode 530 negotiation (denoted as NAT_TM in the example) was described in 531 Section 4.3 and is not repeated here. If a relay receives an R1 or 532 I2 packet without the NAT traversal mode parameter, it MUST drop it 533 and SHOULD send a NOTIFY error packet with type 534 NO_VALID_NAT_TRAVERSAL_MODE_PARAMETER to the sender of the R1/I2. 536 It is RECOMMENDED that the Initiator sends an I1 packet encapsulated 537 in UDP when it is destined to an IPv4 address of the Responder. 538 Respectively, the Responder MUST respond to such an I1 packet with a 539 UDP-encapsulated R1 packet and the rest of the base exchange, I2 and 540 R2, MUST also use UDP encapsulation. 542 I HIP relay R 543 | 1. UDP(I1) | | 544 +----------------------------->| 2. UDP(I1(RELAY_FROM)) | 545 | +------------------------------->| 546 | | | 547 | | 3. UDP(R1(RELAY_TO, NAT_TM)) | 548 | 4. UDP(R1(RELAY_TO, NAT_TM)) |<-------------------------------+ 549 |<-----------------------------+ | 550 | | | 551 | 5. UDP(I2(LOCATOR, NAT_TM)) | | 552 +----------------------------->| 6. UDP(I2(LOCATOR, RELAY_FROM, | 553 | | NAT_TM)) | 554 | +------------------------------->| 555 | | | 556 | | 7. UDP(R2(LOCATOR, RELAY_TO)) | 557 | 8. UDP(R2(LOCATOR, RELAY_TO))|<-------------------------------+ 558 |<-----------------------------+ | 559 | | | 561 Figure 4: Base Exchange via a HIP Relay Server 563 In step 1 of Figure 4, the Initiator sends an I1 packet over the 564 transport layer to the HIT of the Responder and IP address and port 565 of the HIP relay server. The source address is one of the locators 566 of the Initiator. 568 In step 2, the HIP relay server receives the I1 packet. If the 569 destination HIT belongs to a registered Responder, the relay 570 processes the packet. Otherwise, the relay MUST drop the packet 571 silently. The relay appends a RELAY_FROM parameter to the I1 packet 572 which contains the transport source address and port of the I1 as 573 observed by the relay. The relay protects the I1 packet with 574 RELAY_HMAC as described in [RFC5204], except that the parameter type 575 is different (see Section 5.8). The relay changes the source and 576 destination ports and IP addresses of the packet to match the values 577 the Responder used when registering to the relay, i.e., the reverse 578 of the R2 used in the registration. The relay MUST recalculate the 579 transport checksum and forward the packet to the Responder. 581 In step 3, the Responder receives the I1 packet. The Responder 582 processes it according to the rules in [RFC5201]. In addition, the 583 Responder validates the RELAY_HMAC according to [RFC5204] and 584 silently drops the packet if the validation fails. The Responder 585 replies with an R1 packet to which it includes RELAY_TO and NAT 586 traversal mode parameters. The RELAY_TO parameter MUST contain the 587 same information as the RELAY_FROM parameter, i.e., the Initiator's 588 transport address, but the type of the parameter is different. The 589 RELAY_TO parameter is not integrity protected by the signature of the 590 R1 to allow pre-created R1 packets at the Responder. 592 In step 4, the relay receives the R1 packet. The relay drops the 593 packet silently if the source HIT belongs to an unregistered host. 594 The relay MAY verify the signature of the R1 packet and drop it if 595 the signature is invalid. Otherwise, the relay rewrites the source 596 address and port, and changes the destination address and port to 597 match RELAY_TO information. Finally, the relay recalculates 598 transport checksum and forwards the packet. 600 In step 5, the Initiator receives the R1 packet and processes it 601 according to [RFC5201]. The Initiator MAY use the address in the 602 RELAY_TO parameter as a local peer-reflexive candidate for this HIP 603 association if it is different from all known local candidates. The 604 Initiator replies with an I2 packet that uses the destination 605 transport address of R1 as the source address and port. The I2 606 packet contains a LOCATOR parameter that lists all the ICE candidates 607 (ICE offer) of the Initiator. The candidates are encoded using the 608 format defined in Section 5.7. The I2 packet MUST also contain a NAT 609 traversal mode parameter with the mode the Initiator selected. 611 In step 6, the relay receives the I2 packet. The relay appends a 612 RELAY_FROM and a RELAY_HMAC to the I2 packet as explained in step 2. 614 In step 7, the Responder receives the I2 packet and processes it 615 according to [RFC5201]. It replies with an R2 packet and includes a 616 RELAY_TO parameter as explained in step 3. The R2 packet includes a 617 LOCATOR parameter that lists all the ICE candidates (ICE answer) of 618 the Responder. The RELAY_TO parameter is protected by the HMAC. 620 In step 8, the relay processes the R2 as described in step 4. The 621 relay forwards the packet to the Initiator. After the Initiator has 622 received the R2 and processed it successfully, the base exchange is 623 completed. 625 Hosts MUST include the address of one or more HIP relay servers 626 (including the one that is being used for the initial signaling) in 627 the LOCATOR parameter in I2/R2 if they intend to use such servers for 628 relaying HIP signaling immediately after the base exchange completes. 629 The traffic type of these addresses MUST be "HIP signaling" and they 630 MUST NOT be used as ICE candidates. If the HIP relay server locator 631 used for the base exchange is not included in I2/R2 LOCATOR 632 parameters, it SHOULD NOT be used after the base exchange, but 633 further HIP signaling SHOULD use the same path as the data traffic. 635 4.6. ICE Connectivity Checks 637 If a HIP relay server was used, the Responder completes the base 638 exchange with the R2 packet through the relay. However, the 639 destination address the Initiator and Responder used for the base 640 exchange packets belongs to the HIP relay server. Therefore, that 641 address MUST NOT be used as a destination for ESP traffic. Instead, 642 if a NAT traversal mode with ICE connectivity checks was selected, 643 the Initiator and Responder MUST start the connectivity checks. 645 Creating the check list for the ICE connectivity checks should be 646 performed as described in Section 5.7 of [I-D.ietf-mmusic-ice] 647 bearing in mind that only one media stream and component is needed 648 (so there will be only a single checklist and all candidates should 649 have the same component ID value). The actual connectivity checks 650 MUST be performed as described in Section 7 of [I-D.ietf-mmusic-ice]. 651 Regular mode SHOULD be used for the candidate nomination. 652 Section 5.2 defines the details of the STUN control packets. As a 653 result of the ICE connectivity checks, ICE nominates a single 654 transport address pair to be used if an operational address pair was 655 found. The end-hosts MUST use this address pair for the ESP traffic. 657 The connectivity check messages MUST be paced by the value negotiated 658 during the base exchange as described in Section 4.4. If neither one 659 of the hosts announced a minimum pacing value, value of 500ms MUST be 660 used. 662 For retransmissions, the RTO value should be calculated as follows: 664 RTO = MAX (500ms, Ta * P) 666 In the RTO formula, Ta is the value used for the connectivity check 667 pacing and P is the number of pairs in the checklist when the 668 connectivity checks begin. This is identical to the formula in 669 [I-D.ietf-mmusic-ice] if there is only one checklist. 671 If the ICE connectivity checks failed, the hosts MUST NOT send ESP 672 traffic to each other but MAY continue communicating using HIP 673 packets and the locators used for the base exchange. Also, the hosts 674 SHOULD notify each other about the failure with a 675 CONNECTIVITY_CHECKS_FAILED NOTIFY packet (see Section 5.10). 677 4.7. NAT Keepalives 679 To prevent NAT states from expiring, communicating hosts send 680 periodic keepalives to each other. HIP relay servers MAY refrain 681 from sending keepalives if it's known that they are not behind a 682 middlebox that requires keepalives. An end-host MUST send keepalives 683 every 15 seconds to refresh the UDP port mapping at the NAT(s) when 684 the control or data channel is idle. To implement failure tolerance, 685 an end-host SHOULD have shorter keepalive period. 687 The keepalives are STUN Binding Indications if the hosts have agreed 688 on ICE-STUN-UDP NAT traversal mode during the base exchange. 689 Otherwise, HIP NOTIFY packets MAY be used as keepalives. 691 The communicating hosts MUST send keepalives to each other using the 692 transport locators they agreed to use for data and signaling when 693 they are in ESTABLISHED state. Also, the Initiator MUST send a 694 NOTIFY packet to the relay to keep the NAT states alive on the path 695 between the Initiator and relay when the Initiator has not received 696 any response to its I1 or I2 from the Responder in 15 seconds. 698 4.8. Base Exchange without ICE Connectivity Checks 700 In certain network environments the ICE connectivity checks can be 701 omitted to reduce initial connection set up latency because a base 702 exchange acts as an implicit connectivity test itself. For this to 703 work, the Initiator MUST be able to reach the Responder by simply UDP 704 encapsulating HIP and ESP packets sent to the Responder's address. 705 Detecting and configuring this particular scenario is prone to 706 failure unless carefully planned. 708 In such a scenario, the Responder MAY include UDP-ENCAPSULATION NAT 709 traversal mode as one of the supported modes in the R1 packet. If 710 the Responder has registered to a HIP relay server, it MUST also 711 include a LOCATOR parameter in R1 that contains a preferred address 712 where the Responder is able to receive UDP-encapsulated ESP and HIP 713 packets. This locator MUST be of type "Transport address", its 714 Traffic type MUST be "both" and it MUST have the "Preferred bit" set 715 (see Table 2). If there is no such locator in R1, the source address 716 of R1 is used as the Responder's preferred address. 718 The Initiator MAY choose the UDP-ENCAPSULATION mode if the Responder 719 listed it in the supported modes and the Initiator does not wish to 720 use ICE for searching for a more optimal path. In this case, the 721 Initiator sends the I2 with UDP-ENCAPSULATION mode in the NAT 722 traversal mode parameter directly to the Responder's preferred 723 address (i.e., to the preferred locator in R1 or to the address where 724 R1 was received from if there was no preferred locator in R1). The 725 Initiator MAY include locators in I2 but they MUST NOT be taken as 726 ICE candidates, since ICE will not be used for connections with UDP- 727 ENCAPSULATION NAT traversal mode. Instead, if R2 and I2 are received 728 and processed successfully, a security association can be created and 729 UDP-encapsulated ESP can be exchanged between the hosts after the 730 base exchange completes. However, the Responder SHOULD NOT send any 731 ESP to the Initiator's address before it has received data from the 732 Initiator, as specified in Sections 4.4.2. and 6.9 of [RFC5201] and 733 in Sections 3.2.9 and 5.4 of [RFC5206]. 735 Since an I2 packet with UDP-ENCAPSULATION NAT traversal mode selected 736 MUST NOT be sent via a relay, the Responder SHOULD reject such I2 737 packets and reply with NO_VALID_NAT_TRAVERSAL_MODE_PARAMETER NOTIFY 738 packet (see Section 5.10). 740 If there is no answer for the I2 packet sent directly to the 741 Responder's preferred address, the Initiator MAY send another I2 via 742 the HIP relay server, but it MUST NOT choose UDP-ENCAPSULATION NAT 743 traversal mode for that I2. 745 4.9. Initiating a Base Exchange both with and without UDP Encapsulation 747 The Initiator MAY also try to simultaneously perform a base exchange 748 with the Responder without UDP encapsulation. In such a case, the 749 Initiator sends two I1 packets, one without and one with UDP 750 encapsulation, to the Responder. The Initiator MAY wait for a while 751 before sending the other I1. How long to wait and in which order to 752 send the I1 packets can be decided based on local policy. For 753 retransmissions, the procedure is repeated. 755 The I1 packet without UDP encapsulation may arrive directly, without 756 any relays, at the Responder. When this happens, the procedures in 757 [RFC5201] are followed for the rest of the base exchange. The 758 Initiator may receive multiple R1 packets, with and without UDP 759 encapsulation, from the Responder. However, after receiving a valid 760 R1 and answering it with an I2, further R1 packets that are not 761 retransmits of the original R1 MUST be ignored. 763 The I1 packet without UDP encapsulation may also arrive at a HIP- 764 capable middlebox. When the middlebox is a HIP rendezvous server and 765 the Responder has successfully registered with the rendezvous 766 service, the middlebox follows rendezvous procedures in [RFC5204]. 768 If the Initiator receives a NAT traversal mode parameter in R1 769 without UDP encapsulation, the Initiator MAY ignore this parameter 770 and send an I2 without UDP encapsulation and without any selected NAT 771 traversal mode. When the Responder receives the I2 without UDP 772 encapsulation and without NAT traversal mode, it will assume that no 773 NAT traversal mechanism is needed. The packet processing will be 774 done as described in [RFC5201]. The Initiator MAY store the NAT 775 traversal modes for future use e.g., in case of a mobility or 776 multihoming event which causes NAT traversal to be used during the 777 lifetime of the HIP association. 779 4.10. Sending Control Packets after the Base Exchange 781 After the base exchange, the end-hosts MAY send HIP control packets 782 directly to each other using the transport address pair established 783 for a data channel without sending the control packets through the 784 HIP relay server. When a host does not get acknowledgments, e.g., to 785 an UPDATE or CLOSE packet after a timeout based on local policies, 786 the host SHOULD resend the packet through the relay, if it was listed 787 in the LOCATOR parameter in the base exchange. 789 If control packets are sent through a HIP relay server, the host 790 registered with the relay MUST utilize the RELAY_TO parameter as in 791 the base exchange. The HIP relay server SHOULD forward HIP packets 792 to the registered hosts and forward packets from a registered host to 793 the address in the RELAY_TO parameter. The relay MUST add a 794 RELAY_FROM parameter to the control packets it relays to the 795 registered hosts. 797 If the HIP relay server is not willing or able to relay a HIP packet, 798 it MAY notify the sender of the packet with MESSAGE_NOT_RELAYED error 799 notification (see Section 5.10). 801 5. Packet Formats 803 The following subsections define the parameter and packet encodings 804 for the HIP, ESP and ICE connectivity check packets. All values MUST 805 be in network byte order. 807 5.1. HIP Control Packets 809 0 1 2 3 810 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 811 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 812 | Source Port | Destination Port | 813 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 814 | Length | Checksum | 815 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 816 | 32 bits of zeroes | 817 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 818 | | 819 ~ HIP Header and Parameters ~ 820 | | 821 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 823 Figure 5: Format of UDP-encapsulated HIP Control Packets 825 HIP control packets are encapsulated in UDP packets as defined in 826 Section 2.2 of [RFC3948], "rules for encapsulating IKE messages", 827 except a different port number is used. Figure 5 illustrates the 828 encapsulation. The UDP header is followed by 32 zero bits that can 829 be used to differentiate HIP control packets from ESP packets. The 830 HIP header and parameters follow the conventions of [RFC5201] with 831 the exception that the HIP header checksum MUST be zero. The HIP 832 header checksum is zero for two reasons. First, the UDP header 833 already contains a checksum. Second, the checksum definition in 834 [RFC5201] includes the IP addresses in the checksum calculation. The 835 NATs unaware of HIP cannot recompute the HIP checksum after changing 836 IP addresses. 838 A HIP relay server or a Responder without a relay SHOULD listen at 839 UDP port HIPPORT for incoming UDP-encapsulated HIP control packets. 841 5.2. Connectivity Checks 843 The connectivity checks are performed using STUN Binding Requests as 844 defined in [I-D.ietf-mmusic-ice]. This section describes the details 845 of the parameters in the STUN messages. 847 The Binding Requests MUST use STUN short term credentials with last 848 32 bits of the HITs of the Initiator and Responder as the username 849 fragments. The username is formed from the username fragments as 850 defined in Section 7.1.1.3 of [I-D.ietf-mmusic-ice]. The 32 bit 851 username fragments are expressed using lowercase hexadecimal ASCII 852 characters. The leading zeroes MUST NOT be omitted so that the 853 username's size is fixed (8 characters): for example, if the local 854 HIT is 2001:15:8ebe:1aa7:42f5:b413:7237:6c0a and the remote HIT is 855 2001:18:46fa:97c0:ba5:cd77:51:47b, the local username would be 856 72376c0a and the remote username 0051047b. 858 The STUN password is drawn from the DH keying material. Drawing of 859 HIP keys is defined in [RFC5201] Section 6.5 and drawing of ESP keys 860 in [RFC5202] Section 7. Correspondingly, the hosts MUST draw 861 symmetric keys for STUN according to [RFC5201] Section 6.5. The 862 hosts draw the STUN key after HIP keys, or after ESP keys if ESP 863 transform was successfully negotiated in the base exchange. Both 864 hosts draw a 128 bit key from the DH keying material, express that in 865 hexadecimal ASCII format using only lowercase letters (resulting in 866 32 numbers or lowercase letters), and use that as both the local and 867 peer password. [RFC5389] describes how hosts use the password for 868 message integrity of STUN messages. 870 Both the username and password are expressed in ASCII hexadecimal 871 format to prevent the need to run them through SASLPrep as defined in 872 [RFC5389]. 874 The connectivity checks MUST contain PRIORITY attribute. They MAY 875 contain USE-CANDIDATE attribute as defined in Section 7.1.1.1 of 876 [I-D.ietf-mmusic-ice]. 878 The Initiator is always in the controlling role during a base 879 exchange. When two hosts are initiating a connection to each other 880 simultaneously, HIP state machine detects it and assigns the host 881 with the larger HIT as the Responder as explained in Sections 4.4.2 882 and 6.7 in [RFC5201]. Hence, the ICE-CONTROLLED and ICE-CONTROLLING 883 attributes are not needed to resolve role conflicts. However, the 884 attributes SHOULD be added to the connectivity check messages to 885 ensure interoperability with different ICE stacks and they can be 886 safely ignored on received connectivity checks. 888 5.3. Keepalives 890 The keepalives for HIP associations that are created with ICE are 891 STUN Binding Indications, as defined in [RFC5389]. In contrast to 892 the UDP-encapsulated HIP header, the non-ESP-marker between the UDP 893 header and the STUN header is excluded. Keepalives MUST contain the 894 FINGERPRINT STUN attribute but SHOULD NOT contain any other STUN 895 attributes and SHOULD NOT utilize any authentication mechanism. STUN 896 messages are demultiplexed from ESP and HIP control packets using the 897 STUN markers, such as the magic cookie value and the FINGERPRINT 898 attribute. 900 Keepalives for HIP associations created without ICE are HIP control 901 packets that have NOTIFY as the packet type. The keepalive NOTIFY 902 packets do not contain any parameters. 904 5.4. NAT Traversal Mode Parameter 906 Format of the NAT_TRAVERSAL_MODE parameter is similar to the format 907 of the ESP_TRANSFORM parameter in [RFC5202] and is shown in Figure 6. 908 This specification defines traversal mode identifiers UDP- 909 ENCAPSULATION and ICE-STUN-UDP. The identifier RESERVED is reserved 910 for future use. Future specifications may define more traversal 911 modes. 913 0 1 2 3 914 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 915 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 916 | Type | Length | 917 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 918 | Reserved | Mode ID #1 | 919 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 920 | Mode ID #2 | Mode ID #3 | 921 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 922 | Mode ID #n | Padding | 923 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 925 Type [ TBD by IANA: 608 ] 926 Length length in octets, excluding Type, Length, and padding 927 Reserved zero when sent, ignored when received 928 Mode ID defines the proposed or selected NAT traversal mode(s) 930 The following NAT traversal mode IDs are defined: 932 ID name Value 933 RESERVED 0 934 UDP-ENCAPSULATION 1 935 ICE-STUN-UDP 2 937 Figure 6: Format of the NAT_TRAVERSAL_MODE parameter 939 The sender of a NAT_TRAVERSAL_MODE parameter MUST make sure that 940 there are no more than six (6) Mode IDs in one NAT_TRAVERSAL_MODE 941 parameter. Conversely, a recipient MUST be prepared to handle 942 received NAT traversal mode parameters that contain more than six 943 Mode IDs by accepting the first six Mode IDs and dropping the rest. 944 The limited number of Mode IDs sets the maximum size of the 945 NAT_TRAVERSAL_MODE parameter. The modes MUST be in preference order, 946 most preferred mode(s) first. 948 5.5. Connectivity Check Transaction Pacing Parameter 950 The TRANSACTION_PACING parameter shown in Figure 7 contains only the 951 connectivity check pacing value, expressed in milliseconds, as 32 bit 952 unsigned integer. 954 0 1 2 3 955 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 956 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 957 | Type | Length | 958 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 959 | Min Ta | 960 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 962 Type [ TBD by IANA: 610 ] 963 Length 4 964 Min Ta the minimum connectivity check transaction pacing 965 value the host would use 967 Figure 7: Format of the TRANSACTION_PACING parameter 969 5.6. Relay and Registration Parameters 971 Format of the REG_FROM, RELAY_FROM and RELAY_TO parameters is shown 972 in Figure 8. All parameters are identical except for the type. 973 REG_FROM is the only parameter covered with the signature. 975 0 1 2 3 976 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 977 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 978 | Type | Length | 979 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 980 | Port | Protocol | Reserved | 981 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 982 | | 983 | Address | 984 | | 985 | | 986 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 988 Type [ TBD by IANA: 989 REG_FROM: 950 990 RELAY_FROM: 63998 (2^16 - 2^11 + 2^9 - 2) 991 RELAY_TO: 64002 (2^16 - 2^11 + 2^9 + 2) ] 992 Length 20 993 Port transport port number; zero when plain IP is used 994 Protocol IANA assigned, Internet Protocol number. 995 17 for UDP, 0 for plain IP. 996 Reserved reserved for future use; zero when sent, ignored 997 when received 998 Address an IPv6 address or an IPv4 address in "IPv4-Mapped 999 IPv6 address" format 1001 Figure 8: Format of the REG_FROM, RELAY_FROM and RELAY_TO parameters 1002 REG_FROM contains the transport address and protocol where the HIP 1003 relay server sees the registration coming from. RELAY_FROM contains 1004 the address where the relayed packet was received from by the relay 1005 server and the protocol that was used. RELAY_TO contains same 1006 information about the address where a packet should be forwarded to. 1008 5.7. LOCATOR Parameter 1010 The generic LOCATOR parameter format is the same as in [RFC5206]. 1011 However, presenting ICE candidates requires a new locator type. The 1012 generic and NAT traversal specific locator parameters are illustrated 1013 in Figure 9. 1015 0 1 2 3 1016 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 1017 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1018 | Type | Length | 1019 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1020 | Traffic Type | Locator Type | Locator Length| Reserved |P| 1021 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1022 | Locator Lifetime | 1023 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1024 | Locator | 1025 | | 1026 | | 1027 | | 1028 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1029 . . 1030 . . 1031 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1032 | Traffic Type | Loc Type = 2 | Locator Length| Reserved |P| 1033 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1034 | Locator Lifetime | 1035 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1036 | Transport Port | Transp. Proto| Kind | 1037 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1038 | Priority | 1039 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1040 | SPI | 1041 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1042 | Address | 1043 | | 1044 | | 1045 | | 1046 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1048 Figure 9: LOCATOR parameter 1050 The individual fields in the LOCATOR parameter are described in 1051 Table 2. 1053 +-----------+----------+--------------------------------------------+ 1054 | Field | Value(s) | Purpose | 1055 +-----------+----------+--------------------------------------------+ 1056 | Type | 193 | Parameter type | 1057 | Length | Variable | Length in octets, excluding Type and | 1058 | | | Length fields and padding | 1059 | Traffic | 0-2 | Is the locator for HIP signaling (1), for | 1060 | Type | | ESP (2), or for both (0) | 1061 | Locator | 2 | "Transport address" locator type | 1062 | Type | | | 1063 | Locator | 7 | Length of the fields after Locator | 1064 | Length | | Lifetime in 4-octet units | 1065 | Reserved | 0 | Reserved for future extensions | 1066 | Preferred | 0 or 1 | Set to 1 for a Locator in R1 if the | 1067 | (P) bit | | Responder can use it for the rest of the | 1068 | | | base exchange, otherwise set to zero | 1069 | Locator | Variable | Locator lifetime in seconds | 1070 | Lifetime | | | 1071 | Transport | Variable | Transport layer port number | 1072 | Port | | | 1073 | Transport | Variable | IANA Assigned, transport layer Internet | 1074 | Protocol | | Protocol number. Currently only UDP (17) | 1075 | | | is supported. | 1076 | Kind | Variable | 0 for host, 1 for server reflexive, 2 for | 1077 | | | peer reflexive or 3 for relayed address | 1078 | Priority | Variable | Locator's priority as described in | 1079 | | | [I-D.ietf-mmusic-ice] | 1080 | SPI | Variable | SPI value which the host expects to see in | 1081 | | | incoming ESP packets that use this locator | 1082 | Address | Variable | IPv6 address or an "IPv4-Mapped IPv6 | 1083 | | | address" format IPv4 address [RFC4291] | 1084 +-----------+----------+--------------------------------------------+ 1086 Table 2: Fields of the LOCATOR parameter 1088 5.8. RELAY_HMAC Parameter 1090 The RELAY_HMAC parameter value has the TLV type 65520 (2^16 - 2^5 + 1091 2^4). It has the same semantics as RVS_HMAC [RFC5204]. 1093 5.9. Registration Types 1095 The REG_INFO, REG_REQ, REG_RESP and REG_FAILED parameters contain 1096 Registration Type [RFC5203] values for HIP relay server registration. 1097 The value for RELAY_UDP_HIP is 2. 1099 5.10. Notify Packet Types 1101 A HIP relay server and end hosts can use NOTIFY packets to signal 1102 different error conditions. The new Notify Packet Types [RFC5201] 1103 defined in this document are shown below [values TBD by IANA]. The 1104 Notification Data field for the error notifications SHOULD contain 1105 the HIP header of the rejected packet and SHOULD be empty for the 1106 CONNECTIVITY_CHECKS_FAILED type. 1108 NOTIFICATION PARAMETER - ERROR TYPES Value 1109 ------------------------------------ ----- 1111 NO_VALID_NAT_TRAVERSAL_MODE_PARAMETER 60 1113 If a HIP relay server does not forward a base exchange packet due 1114 to missing NAT traversal mode parameter, or the Initiator selects 1115 a NAT traversal mode that the Responder did not expect, the relay 1116 or the Responder may send back a NOTIFY error packet with this 1117 type. 1119 CONNECTIVITY_CHECKS_FAILED 61 1121 Used by the end hosts to signal that NAT traversal connectivity 1122 checks failed and did not produce a working path. 1124 MESSAGE_NOT_RELAYED 62 1126 Used by a HIP relay server to signal that is was not able or 1127 willing to relay a HIP packet. 1129 5.11. ESP Data Packets 1131 [RFC3948] describes UDP encapsulation of the IPsec ESP transport and 1132 tunnel mode. On the wire, the HIP ESP packets do not differ from the 1133 transport mode ESP and thus the encapsulation of the HIP ESP packets 1134 is same as the UDP encapsulation transport mode ESP. However, the 1135 (semantic) difference to BEET mode ESP packets used by HIP is that IP 1136 header is not used in BEET integrity protection calculation. 1138 During the HIP base exchange, the two peers exchange parameters that 1139 enable them to define a pair of IPsec ESP security associations (SAs) 1140 as described in [RFC5202]. When two peers perform a UDP-encapsulated 1141 base exchange, they MUST define a pair of IPsec SAs that produces 1142 UDP-encapsulated ESP data traffic. 1144 The management of encryption/authentication protocols and SPIs is 1145 defined in [RFC5202]. The UDP encapsulation format and processing of 1146 HIP ESP traffic is described in Section 6.1 of [RFC5202]. 1148 6. Security Considerations 1150 6.1. Privacy Considerations 1152 The locators are in plain text format in favor of inspection at HIP- 1153 aware middleboxes in the future. The current draft does not specify 1154 encrypted versions of LOCATORs even though it could be beneficial for 1155 privacy reasons to avoid disclosing them to middleboxes. 1157 It is also possible that end-users may not want to reveal all 1158 locators to each other. For example, tracking the physical location 1159 of a multihoming end-host may become easier if it reveals all 1160 locators to its peer during a base exchange. Also, revealing host 1161 addresses exposes information about the local topology which may not 1162 be allowed in all corporate environments. For these two reasons, an 1163 end-host may exclude certain host addresses from its LOCATOR 1164 parameter. However, such behavior creates non-optimal paths when the 1165 hosts are located behind the same NAT. Especially, this could be 1166 problematic with a legacy NAT that does not support routing from the 1167 private address realm back to itself through the outer address of the 1168 NAT. This scenario is referred to as the hairpin problem [RFC5128]. 1169 With such a legacy NAT, the only option left would be to use a 1170 relayed transport address from a TURN server. 1172 The use of HIP relay servers and TURN relays can be also useful for 1173 privacy purposes. For example, a privacy concerned Responder may 1174 reveal only its HIP relay server and Relayed candidates to 1175 Initiators. This same mechanism also protects the Responder against 1176 Denial-of-Service attacks by allowing the Responder to initiate new 1177 connections even if its relays would be unavailable due to a DoS 1178 attack. 1180 6.2. Opportunistic Mode 1182 A HIP relay server should have one address per relay client when a 1183 HIP relay is serving more than one relay clients and supports 1184 opportunistic mode. Otherwise, it cannot be guaranteed that the HIP 1185 relay server can deliver the I1 packet to the intended recipient. 1187 6.3. Base Exchange Replay Protection for HIP Relay Server 1189 In certain scenarios, it is possible that an attacker, or two 1190 attackers, can replay an earlier base exchange through a HIP relay 1191 server by masquerading as the original Initiator and Responder. The 1192 attack does not require the attacker(s) to compromise the private 1193 key(s) of the attacked host(s). However, for this attack to succeed, 1194 the Responder has to be disconnected from the HIP relay server. 1196 The relay can protect itself against replay attacks by becoming 1197 involved in the base exchange by introducing nonces that the end- 1198 hosts (Initiator and Responder) are required to sign. One way to do 1199 this is to add ECHO_REQUEST_M parameters to the R1 and I2 packets as 1200 described in [I-D.heer-hip-middle-auth] and drop the I2 or R2 packets 1201 if the corresponding ECHO_RESPONSE_M parameters are not present. 1203 6.4. Demuxing Different HIP Associations 1205 Section 5.1 of [RFC3948] describes a security issue for the UDP 1206 encapsulation in the standard IP tunnel mode when two hosts behind 1207 different NATs have the same private IP address and initiate 1208 communication to the same Responder in the public Internet. The 1209 Responder cannot distinguish between two hosts, because security 1210 associations are based on the same inner IP addresses. 1212 This issue does not exist with the UDP encapsulation of HIP ESP 1213 transport format because the Responder uses HITs to distinguish 1214 between different Initiators. 1216 7. IANA Considerations 1218 This section is to be interpreted according to [RFC5226]. 1220 [TO BE REMOVED: Upon publication of this document, IANA is requested 1221 to register a UDP port from the Registered Ports range and the RFC 1222 editor is requested to change all occurrences of port HIPPORT to the 1223 port IANA has registered. The HIPPORT number 50500 should be used 1224 for initial experimentation. ] 1226 This document updates the IANA Registry for HIP Parameter Types 1227 [RFC5201] by assigning new HIP Parameter Type values for the new HIP 1228 Parameters: RELAY_FROM, RELAY_TO and REG_FROM (defined in 1229 Section 5.6), RELAY_HMAC (defined in Section 5.8), TRANSACTION_PACING 1230 (defined in Section 5.5), and NAT_TRAVERSAL_MODE (defined in 1231 Section 5.4). 1233 This document defines an additional registration type for the HIP 1234 Registration Extension [RFC5203] that allows registering with a HIP 1235 relay server for relaying service: RELAY_UDP_HIP (defined in 1236 Section 5.9). 1238 This document also defines NO_VALID_NAT_TRAVERSAL_MODE_PARAMETER, 1239 CONNECTIVITY_CHECKS_FAILED and MESSAGE_NOT_RELAYED Notify Packet 1240 Types [RFC5201] in Section 5.10. 1242 The NAT_TRAVERSAL_MODE parameter has 16-bit unsigned integer fields 1243 for different modes, for which IANA is to create and maintain a new 1244 sub-registry entitled "HIP NAT traversal modes" under the "Host 1245 Identity Protocol (HIP) Parameters". Initial values for the NAT 1246 traversal mode registry are given in Section 5.4; future assignments 1247 are to be made through IETF Review [RFC5226]. Assignments consist of 1248 a NAT traversal mode identifier name and its associated value. [TO 1249 BE REMOVED: This registration should take place at the following 1250 location: http://www.iana.org/assignments/hip-parameters/] 1252 8. Contributors 1254 This draft is a product of a design team which also included Marcelo 1255 Bagnulo and Philip Matthews who both have made major contributions to 1256 this document. 1258 9. Acknowledgments 1260 Thanks for Jonathan Rosenberg and the rest of the MMUSIC WG folks for 1261 the excellent work on ICE. In addition, the authors would like to 1262 thank Andrei Gurtov, Simon Schuetz, Martin Stiemerling, Lars Eggert, 1263 Vivien Schmitt, Abhinav Pathak for their contributions and Tobias 1264 Heer, Teemu Koponen, Juhana Mattila, Jeffrey M. Ahrenholz, Kristian 1265 Slavov, Janne Lindqvist, Pekka Nikander, Lauri Silvennoinen, Jukka 1266 Ylitalo, Juha Heinanen, Joakim Koskela, Samu Varjonen, Dan Wing and 1267 Jani Hautakorpi for their comments on this document. 1269 Miika Komu is working in the Networking Research group at Helsinki 1270 Institute for Information Technology (HIIT). The InfraHIP project 1271 was funded by Tekes, Telia-Sonera, Elisa, Nokia, the Finnish Defence 1272 Forces, Ericsson, and Birdstep. 1274 10. References 1276 10.1. Normative References 1278 [I-D.ietf-behave-turn] 1279 Rosenberg, J., Mahy, R., and P. Matthews, "Traversal Using 1280 Relays around NAT (TURN): Relay Extensions to Session 1281 Traversal Utilities for NAT (STUN)", 1282 draft-ietf-behave-turn-16 (work in progress), July 2009. 1284 [I-D.ietf-mmusic-ice] 1285 Rosenberg, J., "Interactive Connectivity Establishment 1286 (ICE): A Protocol for Network Address Translator (NAT) 1287 Traversal for Offer/Answer Protocols", 1288 draft-ietf-mmusic-ice-19 (work in progress), October 2007. 1290 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1291 Requirement Levels", BCP 14, RFC 2119, March 1997. 1293 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 1294 Architecture", RFC 4291, February 2006. 1296 [RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol 1297 (HIP) Architecture", RFC 4423, May 2006. 1299 [RFC5201] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson, 1300 "Host Identity Protocol", RFC 5201, April 2008. 1302 [RFC5202] Jokela, P., Moskowitz, R., and P. Nikander, "Using the 1303 Encapsulating Security Payload (ESP) Transport Format with 1304 the Host Identity Protocol (HIP)", RFC 5202, April 2008. 1306 [RFC5203] Laganier, J., Koponen, T., and L. Eggert, "Host Identity 1307 Protocol (HIP) Registration Extension", RFC 5203, 1308 April 2008. 1310 [RFC5204] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) 1311 Rendezvous Extension", RFC 5204, April 2008. 1313 [RFC5206] Nikander, P., Henderson, T., Vogt, C., and J. Arkko, "End- 1314 Host Mobility and Multihoming with the Host Identity 1315 Protocol", RFC 5206, April 2008. 1317 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1318 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1319 May 2008. 1321 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 1322 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 1323 October 2008. 1325 10.2. Informative References 1327 [I-D.heer-hip-middle-auth] 1328 Heer, T., Wehrle, K., and M. Komu, "End-Host 1329 Authentication for HIP Middleboxes", 1330 draft-heer-hip-middle-auth-02 (work in progress), 1331 February 2009. 1333 [I-D.rosenberg-mmusic-ice-nonsip] 1334 Rosenberg, J., "Guidelines for Usage of Interactive 1335 Connectivity Establishment (ICE) by non Session 1336 Initiation Protocol (SIP) Protocols", 1337 draft-rosenberg-mmusic-ice-nonsip-01 (work in progress), 1338 July 2008. 1340 [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. 1341 Stenberg, "UDP Encapsulation of IPsec ESP Packets", 1342 RFC 3948, January 2005. 1344 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 1345 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 1346 RFC 4787, January 2007. 1348 [RFC5128] Srisuresh, P., Ford, B., and D. Kegel, "State of Peer-to- 1349 Peer (P2P) Communication across Network Address 1350 Translators (NATs)", RFC 5128, March 2008. 1352 [RFC5207] Stiemerling, M., Quittek, J., and L. Eggert, "NAT and 1353 Firewall Traversal Issues of Host Identity Protocol (HIP) 1354 Communication", RFC 5207, April 2008. 1356 Appendix A. Selecting a Value for Check Pacing 1358 Selecting a suitable value for the connectivity check transaction 1359 pacing is essential for the performance of connectivity check-based 1360 NAT traversal. The value should not be so small that the checks 1361 cause network congestion or overwhelm the NATs. On the other hand, a 1362 pacing value that is too high makes the checks last for a long time, 1363 thus increasing the connection setup delay. 1365 The Ta value may be configured by the user in environments where the 1366 network characteristics are known beforehand. However, if the 1367 characteristics are not known, it is recommended that the value is 1368 adjusted dynamically. In this case it's recommended that the hosts 1369 estimate the RTT between them and set the minimum Ta value so that 1370 only two connectivity check messages are sent on every RTT. 1372 One way to estimate the RTT is to use the time it takes for the HIP 1373 relay server registration exchange to complete; this would give an 1374 estimate on the registering host's access link's RTT. Also the I1/R1 1375 exchange could be used for estimating the RTT, but since the R1 can 1376 be cached in the network, or the relaying service can increase the 1377 delay notably, it is not recommended. 1379 Appendix B. Base Exchange through a Rendezvous Server 1381 When the Initiator looks up the information of the Responder from 1382 DNS, it's possible that it discovers an RVS record [RFC5204]. In 1383 this case, if the Initiator uses NAT traversal methods described in 1384 this document, it MAY use its own HIP relay server to forward HIP 1385 traffic to the Rendezvous server. The Initiator will send the I1 1386 packet using its HIP relay server which will then forward it to the 1387 RVS server of the Responder. In this case, the value of the protocol 1388 field in the RELAY_TO parameter MUST be IP since RVS does not support 1389 UDP-encapsulated base exchange packets. The Responder will send the 1390 R1 packet directly to the Initiator's HIP relay server and the 1391 following I2 and R2 packets are also sent directly using the relay. 1393 In case the Initiator is not able to distinguish which records are 1394 RVS address records and which are Responder's address records (e.g., 1395 if the DNS server did not support HIP extensions), the Initiator 1396 SHOULD first try to contact the Responder directly, without using a 1397 HIP relay server. If none of the addresses is reachable, it MAY try 1398 out them using its own HIP relay server as described above. 1400 Appendix C. Document Revision History 1402 To be removed upon publication 1404 +----------+--------------------------------------------------------+ 1405 | Revision | Comments | 1406 +----------+--------------------------------------------------------+ 1407 | -00 | Initial version. | 1408 | -01 | Draft based on RVS. | 1409 | -02 | Draft based on Relay proxies and ICE concepts. | 1410 | -03 | Draft based on STUN/ICE formats. | 1411 | -04 | Issues 25-27,29-36 | 1412 | -05 | Issues 28,40-43,47,49,51 | 1413 | -06 | New copyright boilerplate and STUN username encoding | 1414 | -07 | New NOTIFY error packet parameters, changed handling | 1415 | | of I2/R2 via relay with UDP-ENCAPSULATION mode | 1416 | -08 | Small editorial fixes regarding WGLC comments | 1417 | -09 | Small fixes regarding IESG and Gen-ART review comments | 1418 +----------+--------------------------------------------------------+ 1420 Authors' Addresses 1422 Miika Komu 1423 Helsinki Institute for Information Technology 1424 Metsanneidonkuja 4 1425 Espoo 1426 Finland 1428 Phone: +358503841531 1429 Fax: +35896949768 1430 Email: miika@iki.fi 1431 URI: http://www.hiit.fi/ 1433 Thomas Henderson 1434 The Boeing Company 1435 P.O. Box 3707 1436 Seattle, WA 1437 USA 1439 Email: thomas.r.henderson@boeing.com 1441 Hannes Tschofenig 1442 Nokia Siemens Networks 1443 Linnoitustie 6 1444 Espoo 02600 1445 Finland 1447 Phone: +358 (50) 4871445 1448 Email: Hannes.Tschofenig@gmx.net 1449 URI: http://www.tschofenig.com 1451 Jan Melen 1452 Ericsson Research Nomadiclab 1453 Hirsalantie 11 1454 02420 Jorvas 1455 Finland 1457 Phone: +358 9 2991 1458 Email: jan.melen@ericsson.com 1459 Ari Keranen (editor) 1460 Ericsson Research Nomadiclab 1461 Hirsalantie 11 1462 02420 Jorvas 1463 Finland 1465 Phone: +358 9 2991 1466 Email: ari.keranen@ericsson.com