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