idnits 2.17.1 draft-ietf-hip-nat-traversal-08.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 924 has weird spacing: '...eserved zero...' == Line 961 has weird spacing: '... Min Ta the ...' == Line 993 has weird spacing: '...eserved rese...' == Line 995 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 (June 29, 2009) is 5415 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-16) exists of draft-ietf-behave-turn-15 ** 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 (~~), 8 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: December 31, 2009 The Boeing Company 6 H. Tschofenig 7 Nokia Siemens Networks 8 J. Melen 9 A. Keranen, Ed. 10 Ericsson Research Nomadiclab 11 June 29, 2009 13 Basic HIP Extensions for Traversal of Network Address Translators 14 draft-ietf-hip-nat-traversal-08.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 December 31, 2009. 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 procedure for 69 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 only one media stream and component. Component ID 1 should be 416 used for ICE processing, where needed. The Initiator takes the role 417 of the ICE controlling agent. 419 The candidate gathering can be done at any time, but it needs to be 420 done before sending an I2 or R2 in the base exchange if ICE is to be 421 used for the connectivity checks. It is RECOMMENDED that all three 422 types of candidates (host, server reflexive and relayed) are gathered 423 to maximize the probability of successful NAT traversal. However, if 424 no TURN server is used, and the host has only a single local IP 425 address to use, the host MAY use the local address as the only host 426 candidate and the address from the REG_FROM parameter discovered 427 during the relay registration as a server reflexive candidate. In 428 this case, no further candidate gathering is needed. 430 4.3. NAT Traversal Mode Negotiation 432 This section describes the usage of a new non-critical parameter 433 type. The presence of the parameter in a HIP base exchange means 434 that the end-host supports NAT traversal extensions described in this 435 document. As the parameter is non-critical (as defined in Section 436 5.2.1 of [RFC5201]), it can be ignored by an end-host which means 437 that the host does not support or is not willing to use these 438 extensions. 440 With registration with a HIP relay it is usually sufficient to use 441 UDP-ENCAPSULATION mode of NAT traversal since the relay should not be 442 behind a NAT. Thus, the relay SHOULD propose the UDP-ENCAPSULATION 443 mode as the preferred or only mode. The NAT traversal mode 444 negotiation in a HIP base exchange is illustrated in Figure 3. 446 Initiator Responder 447 | 1. UDP(I1) | 448 +--------------------------------------------------------------->| 449 | | 450 | 2. UDP(R1(.., NAT_TRAVERSAL_MODE(list of modes), ..)) | 451 |<---------------------------------------------------------------+ 452 | | 453 | 3. UDP(I2(.., NAT_TRAVERSAL_MODE(selected mode), LOCATOR, ..)) | 454 +--------------------------------------------------------------->| 455 | | 456 | 4. UDP(R2(.., LOCATOR, ..)) | 457 |<---------------------------------------------------------------+ 458 | | 460 Figure 3: Negotiation of NAT Traversal Mode 462 In step 1, the Initiator sends an I1 to the Responder. In step 2, 463 the Responder responds with an R1. The NAT_TRAVERSAL_MODE parameter 464 in R1 contains a list of NAT traversal modes the Responder supports. 465 The modes specified in this document are shown in Table 1 and their 466 values in Section 5.4. 468 +-------------------+-----------------------------------------------+ 469 | Type | Purpose | 470 +-------------------+-----------------------------------------------+ 471 | RESERVED | Reserved for future use | 472 | UDP-ENCAPSULATION | Use only UDP encapsulation of the HIP | 473 | | signaling traffic and ESP (no ICE | 474 | | connectivity checks) | 475 | ICE-STUN-UDP | UDP-encapsulated control and data traffic | 476 | | with ICE-based connectivity checks using STUN | 477 | | messages | 478 +-------------------+-----------------------------------------------+ 480 Table 1: NAT Traversal Modes 482 In step 3, the Initiator sends an I2 that includes a 483 NAT_TRAVERSAL_MODE parameter. It contains the mode selected by the 484 Initiator from the list of modes offered by the Responder. If ICE 485 mode was selected, the I2 also includes the "Transport address" 486 locators (as defined in Section 5.7) of the Initiator in a LOCATOR 487 parameter. The locators in I2 are the "ICE offer". 489 In step 4, the Responder concludes the base exchange with an R2 490 packet. If the Initiator chose ICE NAT traversal mode, the Responder 491 includes a LOCATOR parameter in the R2 packet. The locators in R2, 492 encoded like the locators in I2, are the "ICE answer". If the NAT 493 traversal mode selected by the Initiator is not supported by the 494 Responder, the Responder SHOULD reply with NOTIFY packet with type 495 NO_VALID_NAT_TRAVERSAL_MODE_PARAMETER and abort the base exchange. 497 4.4. Connectivity Check Pacing Negotiation 499 As explained in [I-D.ietf-mmusic-ice], when a NAT traversal mode with 500 connectivity checks is used, new transactions should not be started 501 too fast to avoid congestion and overwhelming the NATs. 503 For this purpose, during the base exchange, hosts can negotiate a 504 transaction pacing value, Ta, using a TRANSACTION_PACING parameter in 505 R1 and I2 packets. The parameter contains the minimum time 506 (expressed in milliseconds) the host would wait between two NAT 507 traversal transactions, such as starting a new connectivity check or 508 retrying a previous check. If a host does not include this parameter 509 in the base exchange, a Ta value of 500ms MUST be used as that host's 510 minimum value. The value that is used by both of the hosts is the 511 higher out of the two offered values. 513 Hosts SHOULD NOT use values smaller than 20ms for the minimum Ta, 514 since such values may not work well with some NATs, as explained in 515 [I-D.ietf-mmusic-ice]. The Initiator MUST NOT propose a smaller 516 value than what the Responder offered. 518 The minimum Ta value SHOULD be configurable. Guidelines for 519 selecting a Ta value are given in Appendix A. Currently this feature 520 applies only to the ICE-STUN-UDP NAT traversal mode, but any other 521 mode using connectivity checks SHOULD utilize this feature. 523 4.5. Base Exchange via HIP Relay Server 525 This section describes how Initiator and Responder perform a base 526 exchange through a HIP relay server. The NAT traversal mode 527 negotiation (denoted as NAT_TM in the example) was described in 528 Section 4.3 and is not repeated here. If a relay receives an R1 or 529 I2 packet without the NAT traversal mode parameter, it MUST drop it 530 and SHOULD send a NOTIFY error packet with type 531 NO_VALID_NAT_TRAVERSAL_MODE_PARAMETER to the sender of the R1/I2. 533 It is RECOMMENDED that the Initiator sends an I1 packet encapsulated 534 in UDP when it is destined to an IPv4 address of the Responder. 535 Respectively, the Responder MUST respond to such an I1 packet with a 536 UDP-encapsulated R1 packet and the rest of the base exchange, I2 and 537 R2, MUST also use UDP encapsulation. 539 I HIP relay R 540 | 1. UDP(I1) | | 541 +----------------------------->| 2. UDP(I1(RELAY_FROM)) | 542 | +------------------------------->| 543 | | | 544 | | 3. UDP(R1(RELAY_TO, NAT_TM)) | 545 | 4. UDP(R1(RELAY_TO, NAT_TM)) |<-------------------------------+ 546 |<-----------------------------+ | 547 | | | 548 | 5. UDP(I2(LOCATOR, NAT_TM)) | | 549 +----------------------------->| 6. UDP(I2(LOCATOR, RELAY_FROM, | 550 | | NAT_TM)) | 551 | +------------------------------->| 552 | | | 553 | | 7. UDP(R2(LOCATOR, RELAY_TO)) | 554 | 8. UDP(R2(LOCATOR, RELAY_TO))|<-------------------------------+ 555 |<-----------------------------+ | 556 | | | 558 Figure 4: Base Exchange via a HIP Relay Server 560 In step 1 of Figure 4, the Initiator sends an I1 packet over the 561 transport layer to the HIT of the Responder and IP address and port 562 of the HIP relay server. The source address is one of the locators 563 of the Initiator. 565 In step 2, the HIP relay server receives the I1 packet. If the 566 destination HIT belongs to a registered Responder, the relay 567 processes the packet. Otherwise, the relay MUST drop the packet 568 silently. The relay appends a RELAY_FROM parameter to the I1 packet 569 which contains the transport source address and port of the I1 as 570 observed by the relay. The relay protects the I1 packet with 571 RELAY_HMAC as described in [RFC5204], except that the parameter type 572 is different (see Section 5.8). The relay changes the source and 573 destination ports and IP addresses of the packet to match the values 574 the Responder used when registering to the relay, i.e., the reverse 575 of the R2 used in the registration. The relay MUST recalculate the 576 transport checksum and forward the packet to the Responder. 578 In step 3, the Responder receives the I1 packet. The Responder 579 processes it according to the rules in [RFC5201]. In addition, the 580 Responder validates the RELAY_HMAC according to [RFC5204] and 581 silently drops the packet if the validation fails. The Responder 582 replies with an R1 packet to which it includes RELAY_TO and NAT 583 traversal mode parameters. The RELAY_TO parameter MUST contain the 584 same information as the RELAY_FROM parameter, i.e., the Initiator's 585 transport address, but the type of the parameter is different. The 586 RELAY_TO parameter is not integrity protected by the signature of the 587 R1 to allow pre-created R1 packets at the Responder. 589 In step 4, the relay receives the R1 packet. The relay drops the 590 packet silently if the source HIT belongs to an unregistered host. 591 The relay MAY verify the signature of the R1 packet and drop it if 592 the signature is invalid. Otherwise, the relay rewrites the source 593 address and port, and changes the destination address and port to 594 match RELAY_TO information. Finally, the relay recalculates 595 transport checksum and forwards the packet. 597 In step 5, the Initiator receives the R1 packet and processes it 598 according to [RFC5201]. The Initiator MAY use the address in the 599 RELAY_TO parameter as a local peer-reflexive candidate for this HIP 600 association if it is different from all known local candidates. The 601 Initiator replies with an I2 packet that uses the destination 602 transport address of R1 as the source address and port. The I2 603 packet contains a LOCATOR parameter that lists all the ICE candidates 604 (ICE offer) of the Initiator. The candidates are encoded using the 605 format defined in Section 5.7. The I2 packet MUST also contain a NAT 606 traversal mode parameter with the mode the Initiator selected. 608 In step 6, the relay receives the I2 packet. The relay appends a 609 RELAY_FROM and a RELAY_HMAC to the I2 packet as explained in step 2. 611 In step 7, the Responder receives the I2 packet and processes it 612 according to [RFC5201]. It replies with an R2 packet and includes a 613 RELAY_TO parameter as explained in step 3. The R2 packet includes a 614 LOCATOR parameter that lists all the ICE candidates (ICE answer) of 615 the Responder. The RELAY_TO parameter is protected by the HMAC. 617 In step 8, the relay processes the R2 as described in step 4. The 618 relay forwards the packet to the Initiator. After the Initiator has 619 received the R2 and processed it successfully, the base exchange is 620 completed. 622 Hosts MUST include the address of one or more HIP relay servers 623 (including the one that is being used for the initial signaling) in 624 the LOCATOR parameter in I2/R2 if they intend to use such servers for 625 relaying HIP signaling immediately after the base exchange completes. 626 The traffic type of these addresses MUST be "HIP signaling" and they 627 MUST NOT be used as ICE candidates. If the HIP relay server locator 628 used for the base exchange is not included in I2/R2 LOCATOR 629 parameters, it SHOULD NOT be used after the base exchange, but 630 further HIP signaling SHOULD use the same path as the data traffic. 632 4.6. ICE Connectivity Checks 634 If a HIP relay server was used, the Responder completes the base 635 exchange with the R2 packet through the relay. However, the 636 destination address the Initiator and Responder used for the base 637 exchange packets belongs to the HIP relay server. Therefore, that 638 address MUST NOT be used as a destination for ESP traffic. Instead, 639 if a NAT traversal mode with ICE connectivity checks was selected, 640 the Initiator and Responder MUST start the connectivity checks. 642 Creating the check list for the ICE connectivity checks should be 643 performed as described in Section 5.7 of [I-D.ietf-mmusic-ice] 644 bearing in mind that only one media stream and component is needed 645 (so there will be only a single checklist and all candidates should 646 have the same component ID value). The actual connectivity checks 647 MUST be performed as described in Section 7 of [I-D.ietf-mmusic-ice]. 648 Regular mode SHOULD be used for the candidate nomination. 649 Section 5.2 defines the details of the STUN control packets. As a 650 result of the ICE connectivity checks, ICE nominates a single 651 transport address pair to be used if an operational address pair was 652 found. The end-hosts MUST use this address pair for the ESP traffic. 654 The connectivity check messages MUST be paced by the value negotiated 655 during the base exchange as described in Section 4.4. If neither one 656 of the hosts announced a minimum pacing value, value of 500ms MUST be 657 used. 659 For retransmissions, the RTO value should be calculated as follows: 661 RTO = MAX (500ms, Ta * P) 663 In the RTO formula, Ta is the value used for the connectivity check 664 pacing and P is the number of pairs in the checklist when the 665 connectivity checks begin. This is identical to the formula in 666 [I-D.ietf-mmusic-ice] if there is only one checklist. 668 If the ICE connectivity checks failed, the hosts MUST NOT send ESP 669 traffic to each other but MAY continue communicating using HIP 670 packets and the locators used for the base exchange. Also, the hosts 671 SHOULD notify each other about the failure with a 672 CONNECTIVITY_CHECKS_FAILED NOTIFY packet (see Section 5.10). 674 4.7. NAT Keepalives 676 To prevent NAT states from expiring, communicating hosts send 677 periodically keepalives to each other. HIP relay servers MAY refrain 678 from sending keepalives if it's known that they are not behind a 679 middlebox that requires keepalives. An end-host MUST send keepalives 680 every 15 seconds to refresh the UDP port mapping at the NAT(s) when 681 the control or data channel is idle. To implement failure tolerance, 682 an end-host SHOULD have shorter keepalive period. 684 The keepalives are STUN Binding Indications if the hosts have agreed 685 on ICE-STUN-UDP NAT traversal mode during the base exchange. 686 Otherwise, HIP NOTIFY packets MAY be used as keepalives. 688 The communicating hosts MUST send keepalives to each other using the 689 transport locators they agreed to use for data and signaling when 690 they are in ESTABLISHED state. Also, the Initiator MUST send a 691 NOTIFY packet to the relay to keep the NAT states alive on the path 692 between the Initiator and relay when the Initiator has not received 693 any response to its I1 or I2 from the Responder in 15 seconds. 695 4.8. Base Exchange without ICE Connectivity Checks 697 In certain network environments the ICE connectivity checks can be 698 omitted to reduce initial connection set up latency because a base 699 exchange acts as an implicit connectivity test itself. For this to 700 work, the Initiator MUST be able to reach the Responder by simply UDP 701 encapsulating HIP and ESP packets sent to the Responder's address. 702 Detecting and configuring this particular scenario is prone to 703 failure unless carefully planned. 705 In such a scenario, the Responder MAY include UDP-ENCAPSULATION NAT 706 traversal mode as one of the supported modes in the R1 packet. If 707 the Responder has registered to a HIP relay server, it MUST also 708 include a LOCATOR parameter in R1 that contains a preferred address 709 where the Responder is able to receive UDP-encapsulated ESP and HIP 710 packets. This locator MUST be of type "Transport address", its 711 Traffic type MUST be "both" and it MUST have the "Preferred bit" set 712 (see Table 2). If there is no such locator in R1, the source address 713 of R1 is used as the Responder's preferred address. 715 The Initiator MAY choose the UDP-ENCAPSULATION mode if the Responder 716 listed it in the supported modes and the Initiator does not wish to 717 use ICE for searching for a more optimal path. In this case, the 718 Initiator sends the I2 with UDP-ENCAPSULATION mode in the NAT 719 traversal mode parameter directly to the Responder's preferred 720 address (i.e., to the preferred locator in R1 or to the address where 721 R1 was received from if there was no preferred locator in R1). The 722 Initiator MAY include locators in I2 but they MUST NOT be taken as 723 ICE candidates, since ICE will not be used for connections with UDP- 724 ENCAPSULATION NAT traversal mode. Instead, if R2 and I2 are received 725 and processed successfully, a security association can be created and 726 UDP-encapsulated ESP can be exchanged between the hosts after the 727 base exchange completes. However, the Responder SHOULD NOT send any 728 ESP to the Initiator's address before it has received data from the 729 Initiator, as specified in Sections 4.4.2. and 6.9 of [RFC5201] and 730 in Sections 3.2.9 and 5.4 of [RFC5206]. 732 Since an I2 packet with UDP-ENCAPSULATION NAT traversal mode selected 733 MUST NOT be sent via a relay, the Responder SHOULD reject such I2 734 packets and reply with NO_VALID_NAT_TRAVERSAL_MODE_PARAMETER NOTIFY 735 packet (see Section 5.10). 737 If there is no answer for the I2 packet sent directly to the 738 Responder's preferred address, the Initiator MAY send another I2 via 739 the HIP relay server, but it MUST NOT choose UDP-ENCAPSULATION NAT 740 traversal mode for that I2. 742 4.9. Initiating a Base Exchange both with and without UDP Encapsulation 744 The Initiator MAY also try to simultaneously perform a base exchange 745 with the Responder without UDP encapsulation. In such a case, the 746 Initiator sends two I1 packets, one without and one with UDP 747 encapsulation, to the Responder. The Initiator MAY wait for a while 748 before sending the other I1. How long to wait and in which order to 749 send the I1 packets can be decided based on local policy. For 750 retransmissions, the procedure is repeated. 752 The I1 packet without UDP encapsulation may arrive directly, without 753 any relays, at the Responder. When this happens, the procedures in 754 [RFC5201] are followed for the rest of the base exchange. The 755 Initiator may receive multiple R1 packets, with and without UDP 756 encapsulation, from the Responder. However, after receiving a valid 757 R1 and answering it with an I2, further R1 packets that are not 758 retransmits of the original R1 MUST be ignored. 760 The I1 packet without UDP encapsulation may also arrive at a HIP- 761 capable middlebox. When the middlebox is a HIP rendezvous server and 762 the Responder has successfully registered with the rendezvous 763 service, the middlebox follows rendezvous procedures in [RFC5204]. 765 If the Initiator receives a NAT traversal mode parameter in R1 766 without UDP encapsulation, the Initiator MAY ignore this parameter 767 and send an I2 without UDP encapsulation and without any selected NAT 768 traversal mode. When the Responder receives the I2 without UDP 769 encapsulation and without NAT traversal mode, it will assume that no 770 NAT traversal mechanism is needed. The packet processing will be 771 done as described in [RFC5201]. The Initiator MAY store the NAT 772 traversal modes for future use e.g., in case of a mobility or 773 multihoming event which causes NAT traversal to be used during the 774 lifetime of the HIP association. 776 4.10. Sending Control Packets after the Base Exchange 778 After the base exchange, the end-hosts MAY send HIP control packets 779 directly to each other using the transport address pair established 780 for a data channel without sending the control packets through the 781 HIP relay server. When a host does not get acknowledgments, e.g., to 782 an UPDATE or CLOSE packet after a timeout based on local policies, 783 the host SHOULD resend the packet through the relay, if it was listed 784 in the LOCATOR parameter in the base exchange. 786 If control packets are sent through a HIP relay server, the host 787 registered with the relay MUST utilize the RELAY_TO parameter as in 788 the base exchange. The HIP relay server SHOULD forward HIP packets 789 to the registered hosts and forward packets from a registered host to 790 the address in the RELAY_TO parameter. The relay MUST add a 791 RELAY_FROM parameter to the control packets it relays to the 792 registered hosts. 794 If the HIP relay server is not willing or able to relay a HIP packet, 795 it MAY notify the sender of the packet with MESSAGE_NOT_RELAYED error 796 notification (see Section 5.10). 798 5. Packet Formats 800 The following subsections define the parameter and packet encodings 801 for the HIP, ESP and ICE connectivity check packets. All values MUST 802 be in network byte order. 804 5.1. HIP Control Packets 806 0 1 2 3 807 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 808 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 809 | Source Port | Destination Port | 810 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 811 | Length | Checksum | 812 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 813 | 32 bits of zeroes | 814 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 815 | | 816 ~ HIP Header and Parameters ~ 817 | | 818 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 820 Figure 5: Format of UDP-encapsulated HIP Control Packets 822 HIP control packets are encapsulated in UDP packets as defined in 823 Section 2.2 of [RFC3948], "rules for encapsulating IKE messages", 824 except a different port number is used. Figure 5 illustrates the 825 encapsulation. The UDP header is followed by 32 zero bits that can 826 be used to differentiate HIP control packets from ESP packets. The 827 HIP header and parameters follow the conventions of [RFC5201] with 828 the exception that the HIP header checksum MUST be zero. The HIP 829 header checksum is zero for two reasons. First, the UDP header 830 already contains a checksum. Second, the checksum definition in 831 [RFC5201] includes the IP addresses in the checksum calculation. The 832 NATs unaware of HIP cannot recompute the HIP checksum after changing 833 IP addresses. 835 A HIP relay server or a Responder without a relay SHOULD listen at 836 UDP port HIPPORT for incoming UDP-encapsulated HIP control packets. 838 5.2. Connectivity Checks 840 The connectivity checks are performed using STUN Binding Requests as 841 defined in [I-D.ietf-mmusic-ice]. This section describes the details 842 of the parameters in the STUN messages. 844 The Binding Requests MUST use STUN short term credentials with last 845 32 bits of the HITs of the Initiator and Responder as the username 846 fragments. The username is formed from the username fragments as 847 defined in Section 7.1.1.3 of [I-D.ietf-mmusic-ice]. The 32 bit 848 username fragments are expressed using lowercase hexadecimal ASCII 849 characters. The leading zeroes MUST NOT be omitted so that the 850 username's size is fixed (8 characters): for example, if the local 851 HIT is 2001:15:8ebe:1aa7:42f5:b413:7237:6c0a and the remote HIT is 852 2001:18:46fa:97c0:ba5:cd77:51:47b, the local username would be 853 72376c0a and the remote username 0051047b. 855 The STUN password is drawn from the DH keying material. Drawing of 856 HIP keys is defined in [RFC5201] Section 6.5 and drawing of ESP keys 857 in [RFC5202] Section 7. Correspondingly, the hosts MUST draw 858 symmetric keys for STUN according to [RFC5201] Section 6.5. The 859 hosts draw the STUN key after HIP keys, or after ESP keys if ESP 860 transform was successfully negotiated in the base exchange. Both 861 hosts draw a 128 bit key from the DH keying material, express that in 862 hexadecimal ASCII format using only lowercase letters (resulting in 863 32 numbers or lowercase letters), and use that as both the local and 864 peer password. [RFC5389] describes how hosts use the password for 865 message integrity of STUN messages. 867 Both the username and password are expressed in ASCII hexadecimal 868 format to prevent the need to run them through SASLPrep as defined in 869 [RFC5389]. 871 The connectivity checks MUST contain PRIORITY attribute. They MAY 872 contain USE-CANDIDATE attribute as defined in Section 7.1.1.1 of 873 [I-D.ietf-mmusic-ice]. 875 The Initiator is always in the controlling role during a base 876 exchange. When two hosts are initiating a connection to each other 877 simultaneously, HIP state machine detects it and assigns the host 878 with the larger HIT as the Responder as explained in Sections 4.4.2 879 and 6.7 in [RFC5201]. Hence, the ICE-CONTROLLED and ICE-CONTROLLING 880 attributes are not needed to resolve role conflicts. However, the 881 attributes SHOULD be added to the connectivity check messages to 882 ensure interoperability with different ICE stacks and they can be 883 safely ignored on received connectivity checks. 885 5.3. Keepalives 887 The keepalives for HIP associations that are created with ICE are 888 STUN Binding Indications, as defined in [RFC5389]. In contrast to 889 the UDP-encapsulated HIP header, the non-ESP-marker between the UDP 890 header and the STUN header is excluded. Keepalives MUST contain the 891 FINGERPRINT STUN attribute but SHOULD NOT contain any other STUN 892 attributes and SHOULD NOT utilize any authentication mechanism. STUN 893 messages are demultiplexed from ESP and HIP control packets using the 894 STUN markers, such as the magic cookie value and the FINGERPRINT 895 attribute. 897 Keepalives for HIP associations created without ICE are HIP control 898 packets that have NOTIFY as the packet type. The keepalive NOTIFY 899 packets do not contain any parameters. 901 5.4. NAT Traversal Mode Parameter 903 Format of the NAT_TRAVERSAL_MODE parameter is similar to the format 904 of the ESP_TRANSFORM parameter in [RFC5202] and is shown in Figure 6. 905 This specification defines traversal mode identifiers UDP- 906 ENCAPSULATION and ICE-STUN-UDP. The identifier RESERVED is reserved 907 for future use. Future specifications may define more traversal 908 modes. 910 0 1 2 3 911 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 912 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 913 | Type | Length | 914 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 915 | Reserved | Mode ID #1 | 916 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 917 | Mode ID #2 | Mode ID #3 | 918 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 919 | Mode ID #n | Padding | 920 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 922 Type [ TBD by IANA: 608 ] 923 Length length in octets, excluding Type, Length, and padding 924 Reserved zero when sent, ignored when received 925 Mode ID defines the proposed or selected NAT traversal mode(s) 927 The following NAT traversal mode IDs are defined: 929 ID name Value 930 RESERVED 0 931 UDP-ENCAPSULATION 1 932 ICE-STUN-UDP 2 934 Figure 6: Format of the NAT_TRAVERSAL_MODE parameter 936 The sender of a NAT_TRAVERSAL_MODE parameter MUST make sure that 937 there are no more than six (6) Mode IDs in one NAT_TRAVERSAL_MODE 938 parameter. Conversely, a recipient MUST be prepared to handle 939 received NAT traversal mode parameters that contain more than six 940 Mode IDs by accepting the first six Mode IDs and dropping the rest. 941 The limited number of Mode IDs sets the maximum size of the 942 NAT_TRAVERSAL_MODE parameter. The modes MUST be in preference order, 943 most preferred mode(s) first. 945 5.5. Connectivity Check Transaction Pacing Parameter 947 The TRANSACTION_PACING parameter shown in Figure 7 contains only the 948 connectivity check pacing value, expressed in milliseconds, as 32 bit 949 unsigned integer. 951 0 1 2 3 952 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 953 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 954 | Type | Length | 955 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 956 | Min Ta | 957 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 959 Type [ TBD by IANA: 610 ] 960 Length 4 961 Min Ta the minimum connectivity check transaction pacing 962 value the host would use 964 Figure 7: Format of the TRANSACTION_PACING parameter 966 5.6. Relay and Registration Parameters 968 Format of the REG_FROM, RELAY_FROM and RELAY_TO parameters is shown 969 in Figure 8. All parameters are identical except for the type. 970 REG_FROM is the only parameter covered with the signature. 972 0 1 2 3 973 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 974 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 975 | Type | Length | 976 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 977 | Port | Protocol | Reserved | 978 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 979 | | 980 | Address | 981 | | 982 | | 983 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 985 Type [ TBD by IANA: 986 REG_FROM: 950 987 RELAY_FROM: 63998 (2^16 - 2^11 + 2^9 - 2) 988 RELAY_TO: 64002 (2^16 - 2^11 + 2^9 + 2) ] 989 Length 20 990 Port transport port number; zero when plain IP is used 991 Protocol IANA assigned, Internet Protocol number. 992 17 for UDP, 0 for plain IP. 993 Reserved reserved for future use; zero when sent, ignored 994 when received 995 Address an IPv6 address or an IPv4 address in "IPv4-Mapped 996 IPv6 address" format 998 Figure 8: Format of the REG_FROM, RELAY_FROM and RELAY_TO parameters 999 REG_FROM contains the transport address and protocol where the HIP 1000 relay server sees the registration coming from. RELAY_FROM contains 1001 the address where the relayed packet was received from by the relay 1002 server and the protocol that was used. RELAY_TO contains same 1003 information about the address where a packet should be forwarded to. 1005 5.7. LOCATOR Parameter 1007 The generic LOCATOR parameter format is the same as in [RFC5206]. 1008 However, presenting ICE candidates requires a new locator type. The 1009 generic and NAT traversal specific locator parameters are illustrated 1010 in Figure 9. 1012 0 1 2 3 1013 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 1014 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1015 | Type | Length | 1016 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1017 | Traffic Type | Locator Type | Locator Length| Reserved |P| 1018 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1019 | Locator Lifetime | 1020 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1021 | Locator | 1022 | | 1023 | | 1024 | | 1025 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1026 . . 1027 . . 1028 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1029 | Traffic Type | Loc Type = 2 | Locator Length| Reserved |P| 1030 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1031 | Locator Lifetime | 1032 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1033 | Transport Port | Transp. Proto| Kind | 1034 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1035 | Priority | 1036 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1037 | SPI | 1038 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1039 | Address | 1040 | | 1041 | | 1042 | | 1043 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1045 Figure 9: LOCATOR parameter 1047 The individual fields in the LOCATOR parameter are described in 1048 Table 2. 1050 +-----------+----------+--------------------------------------------+ 1051 | Field | Value(s) | Purpose | 1052 +-----------+----------+--------------------------------------------+ 1053 | Type | 193 | Parameter type | 1054 | Length | Variable | Length in octets, excluding Type and | 1055 | | | Length fields and padding | 1056 | Traffic | 0-2 | Is the locator for HIP signaling (1), for | 1057 | Type | | ESP (2), or for both (0) | 1058 | Locator | 2 | "Transport address" locator type | 1059 | Type | | | 1060 | Locator | 7 | Length of the fields after Locator | 1061 | Length | | Lifetime in 4-octet units | 1062 | Reserved | 0 | Reserved for future extensions | 1063 | Preferred | 0 or 1 | Set to 1 for a Locator in R1 if the | 1064 | (P) bit | | Responder can use it for the rest of the | 1065 | | | base exchange, otherwise set to zero | 1066 | Locator | Variable | Locator lifetime in seconds | 1067 | Lifetime | | | 1068 | Transport | Variable | Transport layer port number | 1069 | Port | | | 1070 | Transport | Variable | IANA Assigned, transport layer Internet | 1071 | Protocol | | Protocol number. Currently only UDP (17) | 1072 | | | is supported. | 1073 | Kind | Variable | 0 for host, 1 for server reflexive, 2 for | 1074 | | | peer reflexive or 3 for relayed address | 1075 | Priority | Variable | Locator's priority as described in | 1076 | | | [I-D.ietf-mmusic-ice] | 1077 | SPI | Variable | SPI value which the host expects to see in | 1078 | | | incoming ESP packets that use this locator | 1079 | Address | Variable | IPv6 address or an "IPv4-Mapped IPv6 | 1080 | | | address" format IPv4 address [RFC4291] | 1081 +-----------+----------+--------------------------------------------+ 1083 Table 2: Fields of the LOCATOR parameter 1085 5.8. RELAY_HMAC Parameter 1087 The RELAY_HMAC parameter value has the TLV type 65520 (2^16 - 2^5 + 1088 2^4). It has the same semantics as RVS_HMAC [RFC5204]. 1090 5.9. Registration Types 1092 The REG_INFO, REG_REQ, REG_RESP and REG_FAILED parameters contain 1093 Registration Type [RFC5203] values for HIP relay server registration. 1094 The value for RELAY_UDP_HIP is 2. 1096 5.10. Notify Packet Types 1098 A HIP relay server and end hosts can use NOTIFY packets to signal 1099 different error conditions. The new Notify Packet Types [RFC5201] 1100 defined in this document are shown below [values TBD by IANA]. The 1101 Notification Data field for the error notifications SHOULD contain 1102 the HIP header of the rejected packet and SHOULD be empty for the 1103 CONNECTIVITY_CHECKS_FAILED type. 1105 NOTIFICATION PARAMETER - ERROR TYPES Value 1106 ------------------------------------ ----- 1108 NO_VALID_NAT_TRAVERSAL_MODE_PARAMETER 60 1110 If a HIP relay server does not forward a base exchange packet due 1111 to missing NAT traversal mode parameter, or the Initiator selects 1112 a NAT traversal mode that the Responder did not expect, the relay 1113 or the Responder may send back a NOTIFY error packet with this 1114 type. 1116 CONNECTIVITY_CHECKS_FAILED 61 1118 Used by the end hosts to signal that NAT traversal connectivity 1119 checks failed and did not produce a working path. 1121 MESSAGE_NOT_RELAYED 62 1123 Used by a HIP relay server to signal that is was not able or 1124 willing to relay a HIP packet. 1126 5.11. ESP Data Packets 1128 [RFC3948] describes UDP encapsulation of the IPsec ESP transport and 1129 tunnel mode. On the wire, the HIP ESP packets do not differ from the 1130 transport mode ESP and thus the encapsulation of the HIP ESP packets 1131 is same as the UDP encapsulation transport mode ESP. However, the 1132 (semantic) difference to BEET mode ESP packets used by HIP is that IP 1133 header is not used in BEET integrity protection calculation. 1135 During the HIP base exchange, the two peers exchange parameters that 1136 enable them to define a pair of IPsec ESP security associations (SAs) 1137 as described in [RFC5202]. When two peers perform a UDP-encapsulated 1138 base exchange, they MUST define a pair of IPsec SAs that produces 1139 UDP-encapsulated ESP data traffic. 1141 The management of encryption/authentication protocols and SPIs is 1142 defined in [RFC5202]. The UDP encapsulation format and processing of 1143 HIP ESP traffic is described in Section 6.1 of [RFC5202]. 1145 6. Security Considerations 1147 6.1. Privacy Considerations 1149 The locators are in plain text format in favor of inspection at HIP- 1150 aware middleboxes in the future. The current draft does not specify 1151 encrypted versions of LOCATORs even though it could be beneficial for 1152 privacy reasons to avoid disclosing them to middleboxes. 1154 It is also possible that end-users may not want to reveal all 1155 locators to each other. For example, tracking the physical location 1156 of a multihoming end-host may become easier if it reveals all 1157 locators to its peer during a base exchange. Also, revealing host 1158 addresses exposes information about the local topology which may not 1159 be allowed in all corporate environments. For these two reasons, an 1160 end-host may exclude certain host addresses from its LOCATOR 1161 parameter. However, such behavior creates non-optimal paths when the 1162 hosts are located behind the same NAT. Especially, this could be 1163 problematic with a legacy NAT that does not support routing from the 1164 private address realm back to itself through the outer address of the 1165 NAT. This scenario is referred to as the hairpin problem [RFC5128]. 1166 With such a legacy NAT, the only option left would be to use a 1167 relayed transport address from a TURN server. 1169 The use of HIP relay servers and TURN relays can be also useful for 1170 privacy purposes. For example, a privacy concerned Responder may 1171 reveal only its HIP relay server and Relayed candidates to 1172 Initiators. This same mechanism also protects the Responder against 1173 Denial-of-Service attacks by allowing the Responder to initiate new 1174 connections even if its relays would be unavailable due to a DoS 1175 attack. 1177 6.2. Opportunistic Mode 1179 A HIP relay server should have one address per relay client when a 1180 HIP relay is serving more than one relay clients and supports 1181 opportunistic mode. Otherwise, it cannot be guaranteed that the HIP 1182 relay server can deliver the I1 packet to the intended recipient. 1184 6.3. Base Exchange Replay Protection for HIP Relay Server 1186 In certain scenarios, it is possible that an attacker, or two 1187 attackers, can replay an earlier base exchange through a HIP relay 1188 server by masquerading as the original Initiator and Responder. The 1189 attack does not require the attacker(s) to compromise the private 1190 key(s) of the attacked host(s). However, for this attack to succeed, 1191 the Responder has to be disconnected from the HIP relay server. 1193 The relay can protect itself against replay attacks by becoming 1194 involved in the base exchange by introducing nonces that the end- 1195 hosts (Initiator and Responder) are required to sign. One way to do 1196 this is to add ECHO_REQUEST_M parameters to the R1 and I2 packets as 1197 described in [I-D.heer-hip-middle-auth] and drop the I2 or R2 packets 1198 if the corresponding ECHO_RESPONSE_M parameters are not present. 1200 6.4. Demuxing Different HIP Associations 1202 Section 5.1 of [RFC3948] describes a security issue for the UDP 1203 encapsulation in the standard IP tunnel mode when two hosts behind 1204 different NATs have the same private IP address and initiate 1205 communication to the same Responder in the public Internet. The 1206 Responder cannot distinguish between two hosts, because security 1207 associations are based on the same inner IP addresses. 1209 This issue does not exist with the UDP encapsulation of HIP ESP 1210 transport format because the Responder uses HITs to distinguish 1211 between different Initiators. 1213 7. IANA Considerations 1215 This section is to be interpreted according to [RFC5226]. 1217 Upon publication of this document, IANA is requested to register a 1218 UDP port and the RFC editor is requested to change all occurrences of 1219 port HIPPORT to the port IANA has registered. The HIPPORT number 1220 50500 should be used for initial experimentation. 1222 This document updates the IANA Registry for HIP Parameter Types 1223 [RFC5201] by assigning new HIP Parameter Type values for the new HIP 1224 Parameters: RELAY_FROM, RELAY_TO and REG_FROM (defined in 1225 Section 5.6), RELAY_HMAC (defined in Section 5.8), TRANSACTION_PACING 1226 (defined in Section 5.5), and NAT_TRAVERSAL_MODE (defined in 1227 Section 5.4). 1229 This document defines an additional registration type for the HIP 1230 Registration Extension [RFC5203] that allows registering with a HIP 1231 relay server for relaying service: RELAY_UDP_HIP (defined in 1232 Section 5.9). 1234 This document also defines NO_VALID_NAT_TRAVERSAL_MODE_PARAMETER, 1235 CONNECTIVITY_CHECKS_FAILED and MESSAGE_NOT_RELAYED Notify Packet 1236 Types [RFC5201] in Section 5.10. 1238 The NAT_TRAVERSAL_MODE parameter has 8-bit unsigned integer fields 1239 for different modes, for which IANA is to create and maintain a new 1240 sub-registry entitled "HIP NAT traversal modes" under the "Host 1241 Identity Protocol (HIP) Parameters". Initial values for the NAT 1242 traversal mode registry are given in Section 5.4; future assignments 1243 are to be made through IETF Review [RFC5226]. Assignments consist of 1244 a NAT traversal mode identifier name and its associated value. [TO 1245 BE REMOVED: This registration should take place at the following 1246 location: http://www.iana.org/assignments/hip-parameters/] 1248 8. Contributors 1250 This draft is a product of a design team which also included Marcelo 1251 Bagnulo and Philip Matthews who both have made major contributions to 1252 this document. 1254 9. Acknowledgments 1256 Thanks for Jonathan Rosenberg and the rest of the MMUSIC WG folks for 1257 the excellent work on ICE. In addition, the authors would like to 1258 thank Andrei Gurtov, Simon Schuetz, Martin Stiemerling, Lars Eggert, 1259 Vivien Schmitt, Abhinav Pathak for their contributions and Tobias 1260 Heer, Teemu Koponen, Juhana Mattila, Jeffrey M. Ahrenholz, Kristian 1261 Slavov, Janne Lindqvist, Pekka Nikander, Lauri Silvennoinen, Jukka 1262 Ylitalo, Juha Heinanen, Joakim Koskela, Samu Varjonen, Dan Wing and 1263 Jani Hautakorpi for their comments on this document. 1265 Miika Komu is working in the Networking Research group at Helsinki 1266 Institute for Information Technology (HIIT). The InfraHIP project 1267 was funded by Tekes, Telia-Sonera, Elisa, Nokia, the Finnish Defence 1268 Forces, Ericsson, and Birdstep. 1270 10. References 1272 10.1. Normative References 1274 [I-D.ietf-behave-turn] 1275 Rosenberg, J., Mahy, R., and P. Matthews, "Traversal Using 1276 Relays around NAT (TURN): Relay Extensions to Session 1277 Traversal Utilities for NAT (STUN)", 1278 draft-ietf-behave-turn-15 (work in progress), June 2009. 1280 [I-D.ietf-mmusic-ice] 1281 Rosenberg, J., "Interactive Connectivity Establishment 1282 (ICE): A Protocol for Network Address Translator (NAT) 1283 Traversal for Offer/Answer Protocols", 1284 draft-ietf-mmusic-ice-19 (work in progress), October 2007. 1286 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1287 Requirement Levels", BCP 14, RFC 2119, March 1997. 1289 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 1290 Architecture", RFC 4291, February 2006. 1292 [RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol 1293 (HIP) Architecture", RFC 4423, May 2006. 1295 [RFC5201] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson, 1296 "Host Identity Protocol", RFC 5201, April 2008. 1298 [RFC5202] Jokela, P., Moskowitz, R., and P. Nikander, "Using the 1299 Encapsulating Security Payload (ESP) Transport Format with 1300 the Host Identity Protocol (HIP)", RFC 5202, April 2008. 1302 [RFC5203] Laganier, J., Koponen, T., and L. Eggert, "Host Identity 1303 Protocol (HIP) Registration Extension", RFC 5203, 1304 April 2008. 1306 [RFC5204] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) 1307 Rendezvous Extension", RFC 5204, April 2008. 1309 [RFC5206] Nikander, P., Henderson, T., Vogt, C., and J. Arkko, "End- 1310 Host Mobility and Multihoming with the Host Identity 1311 Protocol", RFC 5206, April 2008. 1313 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1314 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1315 May 2008. 1317 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 1318 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 1319 October 2008. 1321 10.2. Informative References 1323 [I-D.heer-hip-middle-auth] 1324 Heer, T., Wehrle, K., and M. Komu, "End-Host 1325 Authentication for HIP Middleboxes", 1326 draft-heer-hip-middle-auth-02 (work in progress), 1327 February 2009. 1329 [I-D.rosenberg-mmusic-ice-nonsip] 1330 Rosenberg, J., "Guidelines for Usage of Interactive 1331 Connectivity Establishment (ICE) by non Session 1332 Initiation Protocol (SIP) Protocols", 1333 draft-rosenberg-mmusic-ice-nonsip-01 (work in progress), 1334 July 2008. 1336 [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. 1337 Stenberg, "UDP Encapsulation of IPsec ESP Packets", 1338 RFC 3948, January 2005. 1340 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 1341 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 1342 RFC 4787, January 2007. 1344 [RFC5128] Srisuresh, P., Ford, B., and D. Kegel, "State of Peer-to- 1345 Peer (P2P) Communication across Network Address 1346 Translators (NATs)", RFC 5128, March 2008. 1348 [RFC5207] Stiemerling, M., Quittek, J., and L. Eggert, "NAT and 1349 Firewall Traversal Issues of Host Identity Protocol (HIP) 1350 Communication", RFC 5207, April 2008. 1352 Appendix A. Selecting a Value for Check Pacing 1354 Selecting a suitable value for the connectivity check transaction 1355 pacing is essential for the performance of connectivity check-based 1356 NAT traversal. The value should not be so small that the checks 1357 cause network congestion or overwhelm the NATs. On the other hand, a 1358 pacing value that is too high makes the checks last for a long time, 1359 thus increasing the connection setup delay. 1361 The Ta value may be configured by the user in environments where the 1362 network characteristics are known beforehand. However, if the 1363 characteristics are not known, it is recommended that the value is 1364 adjusted dynamically. In this case it's recommended that the hosts 1365 estimate the RTT between them and set the minimum Ta value so that 1366 only two connectivity check messages are sent on every RTT. 1368 One way to estimate the RTT is to use the time it takes for the HIP 1369 relay server registration exchange to complete; this would give an 1370 estimate on the registering host's access link's RTT. Also the I1/R1 1371 exchange could be used for estimating the RTT, but since the R1 can 1372 be cached in the network, or the relaying service can increase the 1373 delay notably, it is not recommended. 1375 Appendix B. Base Exchange through a Rendezvous Server 1377 When the Initiator looks up the information of the Responder from 1378 DNS, it's possible that it discovers an RVS record [RFC5204]. In 1379 this case, if the Initiator uses NAT traversal methods described in 1380 this document, it MAY use its own HIP relay server to forward HIP 1381 traffic to the Rendezvous server. The Initiator will send the I1 1382 packet using its HIP relay server which will then forward it to the 1383 RVS server of the Responder. In this case, the value of the protocol 1384 field in the RELAY_TO parameter MUST be IP since RVS does not support 1385 UDP-encapsulated base exchange packets. The Responder will send the 1386 R1 packet directly to the Initiator's HIP relay server and the 1387 following I2 and R2 packets are also sent directly using the relay. 1389 In case the Initiator is not able to distinguish which records are 1390 RVS address records and which are Responder's address records (e.g., 1391 if the DNS server did not support HIP extensions), the Initiator 1392 SHOULD first try to contact the Responder directly, without using a 1393 HIP relay server. If none of the addresses is reachable, it MAY try 1394 out them using its own HIP relay server as described above. 1396 Appendix C. Document Revision History 1398 To be removed upon publication 1400 +----------+--------------------------------------------------------+ 1401 | Revision | Comments | 1402 +----------+--------------------------------------------------------+ 1403 | -00 | Initial version. | 1404 | -01 | Draft based on RVS. | 1405 | -02 | Draft based on Relay proxies and ICE concepts. | 1406 | -03 | Draft based on STUN/ICE formats. | 1407 | -04 | Issues 25-27,29-36 | 1408 | -05 | Issues 28,40-43,47,49,51 | 1409 | -06 | New copyright boilerplate and STUN username encoding | 1410 | -07 | New NOTIFY error packet parameters, changed handling | 1411 | | of I2/R2 via relay with UDP-ENCAPSULATION mode | 1412 | -08 | Small editorial fixes regarding WGLC comments | 1413 +----------+--------------------------------------------------------+ 1415 Authors' Addresses 1417 Miika Komu 1418 Helsinki Institute for Information Technology 1419 Metsanneidonkuja 4 1420 Espoo 1421 Finland 1423 Phone: +358503841531 1424 Fax: +35896949768 1425 Email: miika@iki.fi 1426 URI: http://www.hiit.fi/ 1428 Thomas Henderson 1429 The Boeing Company 1430 P.O. Box 3707 1431 Seattle, WA 1432 USA 1434 Email: thomas.r.henderson@boeing.com 1436 Hannes Tschofenig 1437 Nokia Siemens Networks 1438 Linnoitustie 6 1439 Espoo 02600 1440 Finland 1442 Phone: +358 (50) 4871445 1443 Email: Hannes.Tschofenig@gmx.net 1444 URI: http://www.tschofenig.com 1446 Jan Melen 1447 Ericsson Research Nomadiclab 1448 Hirsalantie 11 1449 02420 Jorvas 1450 Finland 1452 Phone: +358 9 2991 1453 Email: jan.melen@ericsson.com 1454 Ari Keranen (editor) 1455 Ericsson Research Nomadiclab 1456 Hirsalantie 11 1457 02420 Jorvas 1458 Finland 1460 Phone: +358 9 2991 1461 Email: ari.keranen@ericsson.com