idnits 2.17.1 draft-ietf-hip-nat-traversal-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 22. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1362. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1373. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1380. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1386. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Line 851 has weird spacing: '...eserved zero...' == Line 883 has weird spacing: '... Length leng...' == Line 884 has weird spacing: '... Min Ta the ...' == Line 916 has weird spacing: '...eserved rese...' == Line 918 has weird spacing: '...Address an ...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 31, 2008) is 5656 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-11 ** Obsolete normative reference: RFC 1884 (Obsoleted by RFC 2373) ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 3513 (Obsoleted by RFC 4291) ** 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 5389 (Obsoleted by RFC 8489) == Outdated reference: A later version (-04) exists of draft-heer-hip-middle-auth-01 Summary: 11 errors (**), 0 flaws (~~), 9 warnings (==), 7 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: May 4, 2009 The Boeing Company 6 P. Matthews 7 (Unaffiliated) 8 H. Tschofenig 9 Nokia Siemens Networks 10 A. Keranen, Ed. 11 Ericsson Research Nomadiclab 12 October 31, 2008 14 Basic HIP Extensions for Traversal of Network Address Translators 15 draft-ietf-hip-nat-traversal-05.txt 17 Status of this Memo 19 By submitting this Internet-Draft, each author represents that any 20 applicable patent or other IPR claims of which he or she is aware 21 have been or will be disclosed, and any of which he or she becomes 22 aware will be disclosed, in accordance with Section 6 of BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt. 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 This Internet-Draft will expire on May 4, 2009. 42 Abstract 44 This document specifies extensions to the Host Identity Protocol 45 (HIP) to facilitate Network Address Translator (NAT) traversal. The 46 extensions are based on the use of the Interactive Connectivity 47 Establishment (ICE) methodology to discover a working path between 48 two end-hosts, and on standard techniques for encapsulating 49 Encapsulating Security Payload (ESP) packets within the User Datagram 50 Protocol (UDP). This document also defines elements of procedure for 51 NAT traversal, including the optional use of a HIP relay server. 52 With these extensions HIP is able to work in environments that have 53 NATs and provides a generic NAT traversal solution to higher-layer 54 networking applications. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 60 3. Overview of Operation . . . . . . . . . . . . . . . . . . . . 7 61 4. Protocol Description . . . . . . . . . . . . . . . . . . . . . 8 62 4.1. Relay Registration . . . . . . . . . . . . . . . . . . . . 8 63 4.2. ICE Candidate Gathering . . . . . . . . . . . . . . . . . 10 64 4.3. NAT Traversal Mode Negotiation . . . . . . . . . . . . . . 10 65 4.4. Connectivity Check Pacing Negotiation . . . . . . . . . . 12 66 4.5. Base Exchange via HIP Relay Server . . . . . . . . . . . . 12 67 4.6. ICE Connectivity Checks . . . . . . . . . . . . . . . . . 14 68 4.7. NAT Keepalives . . . . . . . . . . . . . . . . . . . . . . 15 69 4.8. Base Exchange without ICE Connectivity Checks . . . . . . 16 70 4.9. Simultaneous Base Exchange with and without UDP 71 Encapsulation . . . . . . . . . . . . . . . . . . . . . . 16 72 4.10. Sending Control Messages after the Base Exchange . . . . . 17 73 5. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . . 17 74 5.1. HIP Control Packets . . . . . . . . . . . . . . . . . . . 18 75 5.2. Connectivity Checks . . . . . . . . . . . . . . . . . . . 18 76 5.3. Keepalives . . . . . . . . . . . . . . . . . . . . . . . . 19 77 5.4. NAT Traversal Mode Parameter . . . . . . . . . . . . . . . 20 78 5.5. Connectivity Check Transaction Pacing Parameter . . . . . 20 79 5.6. Relay and Registration Parameters . . . . . . . . . . . . 21 80 5.7. LOCATOR Parameter . . . . . . . . . . . . . . . . . . . . 22 81 5.8. RELAY_HMAC Parameter . . . . . . . . . . . . . . . . . . . 23 82 5.9. Registration Types . . . . . . . . . . . . . . . . . . . . 23 83 5.10. ESP Data Packets . . . . . . . . . . . . . . . . . . . . . 24 84 6. Security Considerations . . . . . . . . . . . . . . . . . . . 24 85 6.1. Privacy Considerations . . . . . . . . . . . . . . . . . . 24 86 6.2. Opportunistic Mode . . . . . . . . . . . . . . . . . . . . 25 87 6.3. Base Exchange Replay Protection for HIP Relay Server . . . 25 88 6.4. Demuxing Different HIP Associations . . . . . . . . . . . 25 89 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 90 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 26 91 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 26 92 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 93 10.1. Normative References . . . . . . . . . . . . . . . . . . . 26 94 10.2. Informative References . . . . . . . . . . . . . . . . . . 27 95 Appendix A. Selecting a Value for Check Pacing . . . . . . . . . 28 96 Appendix B. IPv4-IPv6 Interoperability . . . . . . . . . . . . . 29 97 Appendix C. Base Exchange through a Rendezvous Server . . . . . . 29 98 Appendix D. Document Revision History . . . . . . . . . . . . . . 29 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30 100 Intellectual Property and Copyright Statements . . . . . . . . . . 32 102 1. Introduction 104 HIP [RFC5201] is defined as a protocol that runs directly over IPv4 105 or IPv6, and HIP coordinates the setup of ESP security associations 106 [RFC5202] that are also specified to run over IPv4 or IPv6. This 107 approach is known to have problems traversing NATs and other 108 middleboxes [RFC5207]. This document defines HIP extensions for the 109 traversal of both Network Address Translator (NAT) and Network 110 Address and Port Translator (NAPT) middleboxes. The document 111 generally uses the term NAT to refer to these types of middleboxes. 113 Currently deployed NAT devices do not operate consistently even 114 though a recommended behavior is described in [RFC4787]. The HIP 115 protocol extensions in this document make as few assumptions as 116 possible about the behavior of the NAT devices so that NAT traversal 117 will work even with legacy NAT devices. The purpose of these 118 extensions is to allow two HIP-enabled hosts to communicate with each 119 other even if one or both of the communicating hosts are in a network 120 that is behind one or more NATs. 122 Using the extensions defined in this document, HIP end-hosts use 123 techniques drawn from the Interactive Connectivity Establishment 124 (ICE) methodology [I-D.ietf-mmusic-ice] to find operational paths for 125 the HIP control protocol and for ESP encapsulated data traffic. The 126 hosts test connectivity between different locators and try to 127 discover a direct end-to-end path between them. However, with some 128 legacy NATs, utilizing the shortest path between two end-hosts 129 located behind NATs is not possible without relaying the traffic 130 through a relay, such as a TURN server [RFC5128]. Because relaying 131 traffic increases the roundtrip delay and consumes resources from the 132 relay, with the extensions described in this document, hosts try to 133 avoid using the TURN server whenever possible. 135 HIP has defined a Rendezvous Server [RFC5204] to allow for mobile HIP 136 hosts to establish a stable point-of-contact in the Internet. This 137 document defines extensions to the Rendezvous Server that solve the 138 same problems but for both NATed and non-NATed networks. The 139 extended Rendezvous Server, called a "HIP relay server," forwards all 140 HIP control packets between an Initiator and Responder, allowing 141 Responders to be located behind NATs. This behavior is in contrast 142 to the HIP rendezvous service that forwards only the initial I1 143 packet of the base exchange, which is less likely to work in a NATed 144 environment [RFC5128]. Therefore, when using relays to traverse 145 NATs, HIP uses a HIP relay server for the control traffic and a TURN 146 server for the data traffic. 148 The basis for the connectivity checks is ICE [I-D.ietf-mmusic-ice]. 149 [I-D.ietf-mmusic-ice] describes ICE as follows: 151 "The Interactive Connectivity Establishment (ICE) methodology is a 152 technique for NAT traversal for UDP-based media streams (though 153 ICE can be extended to handle other transport protocols, such as 154 TCP) established by the offer/answer model. ICE is an extension 155 to the offer/answer model, and works by including a multiplicity 156 of IP addresses and ports in SDP offers and answers, which are 157 then tested for connectivity by peer-to-peer connectivity checks. 158 The IP addresses and ports included in the SDP and the 159 connectivity checks are performed using the revised STUN 160 specification [RFC5389], now renamed to Session Traversal 161 Utilities for NAT." 163 The standard ICE [I-D.ietf-mmusic-ice] is specified with SIP in mind 164 and it has some features that are not necessary or suitable as such 165 for other protocols. [I-D.rosenberg-mmusic-ice-nonsip] gives 166 instructions and recommendations on how ICE can be used for other 167 protocols and this document follows those guidelines. 169 Two HIP hosts that implement this specification communicate their 170 locators to each other in the HIP base exchange. The locators are 171 then paired with the locators of the other endpoint and prioritized 172 according to recommended and local policies. These locator pairs are 173 then tested sequentially by both of the end hosts. The tests may 174 result in multiple operational pairs but ICE procedures determine a 175 single preferred address pair to be used for subsequent 176 communication. 178 In summary, the extensions in this document define: 180 o UDP encapsulation of HIP packets 182 o UDP encapsulation of IPsec ESP packets 184 o registration extensions for HIP relay services 186 o how the ICE "offer" and "answer" are carried in the base exchange 188 o interaction with ICE connectivity check messages 190 o backwards compatibility issues with rendezvous servers 192 o a number of optimizations (such as when the ICE connectivity tests 193 can be omitted) 195 2. Terminology 197 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 198 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 199 document are to be interpreted as described in [RFC2119]. 201 This document borrows terminology from [RFC5201], [RFC5206], 202 [RFC4423], [I-D.ietf-mmusic-ice], and [RFC5389]. Additionally, the 203 following terms are used: 205 Rendezvous server: 206 A host that forwards I1 packets to the Responder. 208 HIP relay server: 209 A host that forwards all HIP control packets between the Initiator 210 and the Responder. 212 TURN server: 213 A server that forwards data traffic between two end-hosts as 214 defined in [I-D.ietf-behave-turn]. 216 Locator: 217 As defined in [RFC5206]: "A name that controls how the packet is 218 routed through the network and demultiplexed by the end-host. It 219 may include a concatenation of traditional network addresses such 220 as an IPv6 address and end-to-end identifiers such as an ESP SPI. 221 It may also include transport port numbers or IPv6 Flow Labels as 222 demultiplexing context, or it may simply be a network address." 223 It should noted that "address" is used in this document as a 224 synonym for locator. 226 LOCATOR (written in capital letters): 227 Denotes a HIP control message parameter that bundles multiple 228 locators together. 230 ICE offer: 231 The Initiator's LOCATOR parameter in a HIP I2 control message. 233 ICE answer: 234 The Responder's LOCATOR parameter in a HIP R2 control message. 236 Transport address: 237 Transport layer port and the corresponding IPv4/v6 address. 239 Candidate: 240 A transport address that is a potential point of contact for 241 receiving data. 243 Host candidate: 244 A candidate obtained by binding to a specific port from an IP 245 address on the host. 247 Server reflexive candidate: 248 A translated transport address of a host as observed by a HIP 249 relay server or a STUN/TURN server. 251 Peer reflexive candidate: 252 A translated transport address of a host as observed by its peer. 254 Relayed candidate: 255 A transport address that exists on a TURN server. Packets that 256 arrive at this address are relayed towards the TURN client. 258 3. Overview of Operation 260 +-------+ 261 | HIP | 262 +--------+ | Relay | +--------+ 263 | TURN | +-------+ | STUN | 264 | Server | / \ | Server | 265 +--------+ / \ +--------+ 266 / \ 267 / \ 268 / \ 269 / <- Signaling -> \ 270 / \ 271 +-------+ +-------+ 272 | NAT | | NAT | 273 +-------+ +-------+ 274 / \ 275 / \ 276 +-------+ +-------+ 277 | Init- | | Resp- | 278 | iator | | onder | 279 +-------+ +-------+ 281 Figure 1: Example network configuration 283 In an example configuration depicted in Figure 1, both Initiator and 284 Responder are behind one or more NATs, and both private networks are 285 connected to the public Internet. To be contacted from behind a NAT, 286 the Responder must be registered with a HIP relay server reachable on 287 the public Internet, and we assume as a starting point that the 288 Initiator knows both the Responder's HIT and the address of one of 289 its relay servers (how the Initiator learns of the Responder's relay 290 server is outside of the scope of this document, but may be through 291 DNS or another name service). 293 The first steps are for both the Initiator and Responder to register 294 with a relay server (need not be the same one) and gather a set of 295 address candidates. Next, the HIP base exchange is carried out by 296 encapsulating the HIP control packets in UDP datagrams and sending 297 them through the Responder's relay server. As part of the base 298 exchange, each HIP host learns of the peer's candidate addresses 299 through the ICE offer/answer procedure embedded in the base exchange. 301 Once the base exchange is completed, HIP has established a working 302 communication session (for signaling) via a relay server, but the 303 hosts still work to find a better path, preferably without a relay, 304 for the ESP data flow. For this, ICE connectivity checks are carried 305 out until a working pair of addresses is discovered. At the end of 306 the procedure, if successful, the hosts will have enabled a UDP-based 307 flow that traverses both NATs, with the data flowing directly from 308 NAT to NAT or via a TURN server. Further HIP signaling can be sent 309 over the same address/port pair and is demultiplexed from data 310 traffic via a marker in the payload. Finally, NAT keepalives will be 311 sent as needed. 313 If either one of the hosts knows that it is not behind a NAT, hosts 314 can negotiate during the base exchange a different mode of NAT 315 traversal that does not use ICE connectivity checks, but only UDP 316 encapsulation of HIP and ESP. Also, it is possible for the Initiator 317 to simultaneously try a base exchange with and without UDP 318 encapsulation. If a base exchange without UDP encapsulation 319 succeeds, no ICE connectivity checks or UDP encapsulation of ESP are 320 needed. 322 4. Protocol Description 324 This section describes the normative behavior of the protocol 325 extension. Examples of packet exchanges are provided for 326 illustration purposes. 328 4.1. Relay Registration 330 HIP rendezvous servers operate in non-NATed environments and their 331 use is described in [RFC5204]. This section specifies a new 332 middlebox extension, called the HIP relay server, for operating in 333 NATed environments. A HIP relay server forwards all HIP control 334 packets between the Initiator and the Responder. 336 End-hosts cannot use the HIP relay service for forwarding the ESP 337 data plane. Instead, they use TURN servers [I-D.ietf-behave-turn] 338 for that. 340 A HIP relay server MUST silently drop packets to a HIP relay client 341 that has not previously registered with the HIP relay. The 342 registration process follows the generic registration extensions 343 defined in [RFC5203] and is illustrated in Figure 2. 345 HIP HIP 346 Relay Relay 347 Client Server 348 | 1. UDP(I1) | 349 +------------------------------------------------------->| 350 | | 351 | 2. UDP(R1(REG_INFO(RELAY_UDP_HIP))) | 352 |<-------------------------------------------------------+ 353 | | 354 | 3. UDP(I2(REG_REQ(RELAY_UDP_HIP))) | 355 +------------------------------------------------------->| 356 | | 357 | 4. UDP(R2(REG_RES(RELAY_UDP_HIP), REG_FROM)) | 358 |<-------------------------------------------------------+ 360 Figure 2: Example Registration to a HIP Relay 362 In step 1, the relay client (Initiator) starts the registration 363 procedure by sending an I1 packet over UDP. It is RECOMMENDED that 364 the Initiator selects a random port number from the ephemeral port 365 range 49152-65535 for initiating a base exchange. However, the 366 allocated port MUST be maintained until all of the corresponding HIP 367 Associations are closed. Alternatively, a host MAY also use a single 368 fixed port for initiating all outgoing connections. The HIP relay 369 server MUST listen to incoming connections at UDP port HIPPORT. 371 In step 2, the HIP relay server (Responder) lists the services that 372 it supports in the R1 packet. The support for HIP-over-UDP relaying 373 is denoted by the RELAY_UDP_HIP value. 375 In step 3, the Initiator selects the services it registers for and 376 lists them in the REG_REQ parameter. The Initiator registers for HIP 377 relay service by listing the RELAY_UDP_HIP value in the request 378 parameter. 380 In step 4, the Responder concludes the registration procedure with an 381 R2 packet and acknowledges the registered services in the REG_RES 382 parameter. The Responder denotes unsuccessful registrations (if any) 383 in the REG_FAILED parameter of R2. The Responder also includes a 384 REG_FROM parameter that contains the transport address of the client 385 as observed by the relay (Server Reflexive candidate). After the 386 registration, the client sends NAT keepalives periodically to the 387 relay to keep possible NAT bindings between the client and the relay 388 alive. 390 4.2. ICE Candidate Gathering 392 If a host is going to use ICE, it needs to gather a set of address 393 candidates. The candidate gathering SHOULD be done as defined in 394 Section 4.1 of [I-D.ietf-mmusic-ice]. Candidates need to be gathered 395 for only one media stream and component. Component ID 1 should be 396 used for ICE processing, where needed. Initiator takes the role of 397 the ICE controlling agent. 399 The candidate gathering can be done at any time, but it needs to be 400 done before sending an I2 or R2 if ICE is used for the connectivity 401 checks. It is RECOMMENDED that all three types of candidates (host, 402 server reflexive and relayed) are gathered to maximize probability of 403 successful NAT traversal. However, if no TURN server is used, and 404 the host has only a single local IP address to use, the host MAY use 405 the local address as the only host candidate and the address from the 406 REG_FROM parameter discovered during the relay registration as a 407 server reflexive candidate. In this case, no further candidate 408 gathering is needed. 410 4.3. NAT Traversal Mode Negotiation 412 This section describes the usage of a new non-critical parameter 413 type. The presence of the parameter in a HIP base exchange means 414 that the end-host supports NAT traversal extensions described in this 415 document. As the parameter is non-critical, it can be ignored by an 416 end-host which means that the host does not support or is not willing 417 to use these extensions. 419 The NAT traversal mode parameter applies to a base exchange between 420 end-hosts, but currently does not apply to a registration with a HIP 421 relay server. The NAT traversal mode negotiation in base exchange is 422 illustrated in Figure 3. 424 Initiator Responder 425 | 1. UDP(I1) | 426 +------------------------------------------------------------->| 427 | | 428 | 2. UDP(R1(.., NAT_TRAVERSAL_MODE(list of modes), ..)) | 429 |<-------------------------------------------------------------+ 430 | | 431 | 3. UDP(I2(.., NAT_TRAVERSAL_MODE(selected mode), LOCATOR..)) | 432 +------------------------------------------------------------->| 433 | | 434 | 4. UDP(R2(.., LOCATOR, ..)) | 435 |<-------------------------------------------------------------+ 436 | .... | 438 Figure 3: Negotiation of NAT Traversal Mode 440 In step 1, the Initiator sends an I1 to the Responder. In step 2, 441 the Responder responds with an R1. The R1 contains a list of NAT 442 traversal modes the Responder supports in the NAT_TRAVERSAL_MODE 443 parameter as shown in Table 1. 445 +-------------------+-----------------------------------------------+ 446 | Type | Purpose | 447 +-------------------+-----------------------------------------------+ 448 | RESERVED | Reserved for future use | 449 | UDP-ENCAPSULATION | Use only UDP encapsulation of the HIP | 450 | | signaling traffic and ESP (no ICE | 451 | | connectivity checks) | 452 | ICE-STUN-UDP | UDP encapsulated control and data traffic | 453 | | with ICE-based connectivity checks using STUN | 454 | | messages | 455 +-------------------+-----------------------------------------------+ 457 Table 1: NAT Traversal Modes 459 In step 3, the Initiator sends an I2 that includes a 460 NAT_TRAVERSAL_MODE parameter. It contains the mode selected by the 461 Initiator from the list of modes offered by the Responder. The I2 462 also includes the locators of the Initiator in a LOCATOR parameter. 463 The locator parameter in I2 is the "ICE offer". 465 In step 4, the Responder concludes the base exchange with an R2 466 packet. The Responder includes a LOCATOR parameter in the R2 packet. 467 The locator parameter in R2 is the "ICE answer". 469 4.4. Connectivity Check Pacing Negotiation 471 As explained in [I-D.ietf-mmusic-ice], when a NAT traversal mode with 472 connectivity checks is used, new transactions should not be started 473 too fast to avoid congestion and overwhelming the NATs. 475 For this purpose, during the base exchange, hosts can negotiate a 476 transaction pacing value, Ta, using a TRANSACTION_PACING parameter in 477 I2 and R2 messages. The parameter contains the minimum time 478 (expressed in milliseconds) the host would wait between two NAT 479 traversal transactions, such as starting a new connectivity check or 480 retrying a previous check. If a host does not include this parameter 481 in the base exchange, a Ta value of 500ms MUST be used as that host's 482 minimum value. The value that is used by both of the hosts is the 483 higher out of the two offered values. 485 Hosts SHOULD NOT use values smaller than 20ms for the minimum Ta, 486 since such values may not work well with some NATs, as explained in 487 [I-D.ietf-mmusic-ice]. 489 The minimum Ta value SHOULD be configurable. Guidelines for 490 selecting a Ta value are given in Appendix A. Currently this feature 491 applies only to the ICE-STUN-UDP NAT traversal mode. 493 4.5. Base Exchange via HIP Relay Server 495 This section describes how Initiator and Responder perform a base 496 exchange through a HIP relay server. The NAT traversal mode 497 negotiation (denoted as NAT_TM in the example) was described in the 498 previous section and shall not be repeated here. If a relay receives 499 an R1 or I2 packet without the NAT traversal mode parameter, it drops 500 it and sends a NOTIFY error message to the sender of the R1/I2. 502 It is RECOMMENDED that the Initiator sends an I1 packet encapsulated 503 in UDP when it is destined to an IPv4 address of the Responder. 504 Respectively, the Responder MUST respond to such an I1 packet with an 505 R1 packet over the transport layer and using the same transport 506 protocol. The rest of the base exchange, I2 and R2, MUST also use 507 the same transport protocol. 509 I HIP relay R 510 | 1. UDP(I1) | | 511 +----------------------------->| 2. UDP(I1(RELAY_FROM)) | 512 | +------------------------------->| 513 | | | 514 | | 3. UDP(R1(RELAY_TO, NAT_TM)) | 515 | 4. UDP(R1(RELAY_TO),NAT_TM ) |<-------------------------------+ 516 |<-----------------------------+ | 517 | | | 518 | 5. UDP(I2(LOCATOR),NAT_TM) | | 519 +----------------------------->| 6. UDP(I2(LOCATOR,RELAY_FROM),| 520 | | NAT_TM) | 521 | +------------------------------->| 522 | | | 523 | | 7. UDP(R2(LOCATOR,RELAY_TO)) | 524 | 8. UDP(R2(LOCATOR,RELAY_TO)) |<-------------------------------+ 525 |<-----------------------------+ | 526 | | | 528 Figure 4: Base Exchange via a HIP Relay Server 530 In step 1 of Figure 4, the Initiator sends an I1 packet over the 531 transport layer to the HIT of the Responder (and IP address of the 532 relay). The source address is one of the locators of the Initiator. 534 In step 2, the HIP relay server receives the I1 packet at port 535 HIPPORT. If the destination HIT belongs to a registered Responder, 536 the relay processes the packet. Otherwise, the relay MUST drop the 537 packet silently. The relay appends a RELAY_FROM parameter to the I1 538 packet which contains the transport source address and port of the I1 539 as observed by the relay. The relay protects the I1 packet with 540 RELAY_HMAC as described in [RFC5204], except that the parameter type 541 is different (see Section 5.8). The relay changes the source and 542 destination ports and IP addresses of the packet to match the values 543 the Responder used when registering to the relay, i.e., the reverse 544 of the R2 used in the registration. The relay MUST recalculate the 545 transport checksum and forward the packet to the Responder. 547 In step 3, the Responder receives the I1 packet. The Responder 548 processes it according to the rules in [RFC5201]. In addition, the 549 Responder validates the RELAY_HMAC according to [RFC5204] and 550 silently drops the packet if the validation fails. The Responder 551 replies with an R1 packet to which it includes a RELAY_TO parameter. 552 The RELAY_TO parameter MUST contain same information as the 553 RELAY_FROM parameter, i.e., the Initiator's transport address, but 554 the type of the parameter is different. The RELAY_TO parameter is 555 not integrity protected by the signature of the R1 to allow pre- 556 created R1 packets at the Responder. 558 In step 4, the relay receives the R1 packet. The relay drops the 559 packet silently if the source HIT belongs to an unregistered host. 560 The relay MAY verify the signature of the R1 packet and drop it if 561 the signature is invalid. Otherwise, the relay rewrites the source 562 address and port, and changes the destination address and port to 563 match RELAY_TO information. Finally, the relay recalculates 564 transport checksum and forwards the packet. 566 In step 5, the Initiator receives the R1 packet and processes it 567 according to [RFC5201]. It replies with an I2 packet that uses the 568 destination transport address of R1 as the source address and port. 569 The I2 contains a LOCATOR parameter that lists all the ICE candidates 570 (ICE offer) of the Initiator. The candidates are encoded using the 571 format defined in Section 5.7. The I2 packet MUST also contain the 572 NAT traversal mode parameter with ICE-STUN-UDP or some other selected 573 mode. 575 In step 6, the relay receives the I2 packet. The relay appends a 576 RELAY_FROM and a RELAY_HMAC to the I2 packet as explained in step 2. 578 In step 7, the Responder receives the I2 packet and processes it 579 according to [RFC5201]. It replies with an R2 packet and includes a 580 RELAY_TO parameter as explained in step 3. The R2 packet includes a 581 LOCATOR parameter that lists all the ICE candidates (ICE answer) of 582 the Responder. The RELAY_TO parameter is protected by the HMAC. 584 In step 8, the relay processes the R2 as described in step 4. The 585 relay forwards the packet to the Initiator. 587 Hosts MAY include the address of their HIP relay server in the 588 LOCATOR parameter in I2/R2. The traffic type of this address MUST be 589 "HIP signaling" and it MUST NOT be used as an ICE candidate. This 590 address MAY be used for HIP signaling also after the base exchange. 591 If the HIP relay server locator is not included in I2/R2 LOCATOR 592 parameters, it SHOULD NOT be used after the base exchange, but the 593 HIP signaling SHOULD use the same path as the data traffic. 595 4.6. ICE Connectivity Checks 597 If a HIP relay server was used, the Responder completes the base 598 exchange with the R2 packet through the relay. When the Initiator 599 successfully receives and processes the R2, both hosts have 600 transitioned to ESTABLISHED state. However, the destination address 601 the Initiator and Responder used for delivering base exchange packets 602 belonged to the HIP relay server. Therefore, the address of the 603 relay MUST NOT be used for sending ESP traffic. Instead, if a NAT 604 traversal mode with ICE connectivity checks was selected, the 605 Initiator and Responder MUST start the connectivity checks. 607 Creating the check list for the ICE connectivity checks should be 608 performed as described in Section 5.7 of [I-D.ietf-mmusic-ice] 609 bearing in mind that only one media stream and component is needed 610 (so there will be only a single checklist and all candidates should 611 have the same component ID value). The actual connectivity checks 612 MUST be performed as described in Section 7 of [I-D.ietf-mmusic-ice]. 613 Regular mode SHOULD be used for the candidate nomination. 614 Section 5.2 defines the details of the STUN control packets. As a 615 result of the ICE connectivity checks, ICE nominates a single 616 transport address pair to be used if an operational address pair was 617 found. The end-hosts MUST use this address pair for the ESP traffic. 619 The connectivity check messages MUST be paced by the value negotiated 620 during the base exchange as described in Section 4.4. If neither one 621 of the hosts announced a minimum pacing value, value of 500ms MUST be 622 used. 624 For retransmissions, the RTO value should be calculated as follows: 626 RTO = MAX (500ms, Ta * P) 628 In the RTO formula, Ta is the value used for the connectivity check 629 pacing and P is the number of pairs in the checklist when the 630 connectivity checks begin. This is identical to the formula in 631 [I-D.ietf-mmusic-ice] if there is only one checklist. 633 4.7. NAT Keepalives 635 To prevent NAT states from expiring, communicating hosts send 636 periodically keepalives to each other. HIP relay servers MAY refrain 637 from sending keepalives if it's known that they are not behind a 638 middlebox that requires keepalives. An end-host MUST send keepalives 639 every 15 seconds to refresh the UDP port mapping at the NAT(s) when 640 the control or data channel is idle. To implement failure tolerance, 641 an end-host SHOULD have shorter keepalive period. 643 The keepalives are STUN Binding Indications if the hosts have agreed 644 on ICE-STUN-UDP NAT traversal mode during the base exchange. 645 Otherwise, HIP NOTIFY messages MAY be used. A HIP relay server MUST 646 NOT forward the NOTIFY messages. 648 The communicating hosts MUST send keepalives to each other using the 649 transport locators they agreed to use for data and signaling when 650 they are in ESTABLISHED state. Also, the Initiator MUST send a 651 NOTIFY message to the relay to keep the NAT states alive on the path 652 between the Initiator and relay when the Initiator has not received 653 any response to its I1 or I2 from the Responder in 15 seconds. The 654 relay MUST NOT forward the NOTIFY messages. 656 4.8. Base Exchange without ICE Connectivity Checks 658 In certain network environments, the ICE connectivity checks can be 659 omitted to reduce initial connection set up latency because base 660 exchange acts as an implicit connectivity test itself. There are 661 three assumptions about such as environments. First, the Responder 662 should have a long-term, fixed locator in the network. Second, the 663 Responder should not have a HIP relay server configured for itself. 664 Third, the Initiator can reach the Responder by simply UDP 665 encapsulating HIP and ESP packets to the host. Detecting and 666 configuring this particular scenario is prone to administrative 667 failure unless carefully planned. 669 In such a scenario, the Responder MAY include only the UDP- 670 ENCAPSULATION NAT traversal mode in the R1 message. Likewise, if the 671 Initiator knows that it can receive ESP and HIP signaling traffic by 672 using simply UDP encapsulation, it can choose the UDP-ENCAPSULATION 673 mode in the I2 message, if the Responder listed it in the supported 674 modes. In both of these cases the locators from I2 and R2 packets 675 will be used also for the UDP encapsulated ESP. 677 When no ICE connectivity checks are used, locator exchange and return 678 routability tests for mobility and multihoming are done as specified 679 in [RFC5206] with the exception that UDP encapsulation is used. 681 4.9. Simultaneous Base Exchange with and without UDP Encapsulation 683 The Initiator MAY also try to simultaneously perform a base exchange 684 with the Responder without UDP encapsulation. In such a case, the 685 Initiator sends two I1 packets, one without and one with UDP 686 encapsulation, to the Responder. The Initiator MAY wait for a while 687 before sending the other I1. How long to wait and in which order to 688 send the I1 packets can be decided based on local policy. For 689 retransmissions, the procedure is repeated. 691 The I1 packet without UDP encapsulation may arrive directly at the 692 Responder. When the recipient is the Responder, the procedures in 693 [RFC5201] are followed for the rest of the base exchange. The 694 Initiator may receive multiple R1 messages, with and without UDP 695 encapsulation, from the Responder. However, after receiving a valid 696 R1 and answering to it with an I2, further R1 messages that are not 697 retransmits of the original R1 MUST be ignored. 699 The I1 packet without UDP encapsulation may also arrive at a HIP- 700 capable middlebox. When the middlebox is a HIP rendezvous server and 701 the Responder has successfully registered to the rendezvous service, 702 the middlebox follows rendezvous procedures in [RFC5204]. 704 If the Initiator receives a NAT traversal mode parameter in R1 705 without UDP encapsulation, the Initiator MAY ignore this parameter 706 and send an I2 without UDP encapsulation and without any selected NAT 707 traversal mode. When the Responder receives the I2 without UDP 708 encapsulation and without NAT traversal mode, it will assume that no 709 NAT traversal mechanism is needed. The packet processing will be 710 done as described in [RFC5201]. The Initiator MAY store the NAT 711 traversal modes for future use e.g., to be used in case of mobility 712 or multihoming event which causes NAT traversal to be taken in to use 713 during the lifetime of the HIP association. 715 4.10. Sending Control Messages after the Base Exchange 717 After the base exchange, the end-hosts MAY send HIP control messages 718 directly to each other using the transport address pair established 719 for data channel without sending the control packets through the HIP 720 relay server. When a host does not get acknowledgments, e.g., to an 721 UPDATE or CLOSE message after a timeout based on local policies, the 722 host SHOULD resend the packet through the relay, if it was listed in 723 the LOCATOR parameter in the base exchange. 725 If control messages are sent through a HIP relay server, the sender 726 MUST include a RELAY_TO parameter to them. Also the HIP relay server 727 MUST add a RELAY_FROM parameter to the control messages it relays. 729 5. Packet Formats 731 The following subsections define the parameter and packet encodings 732 for the HIP, ESP and ICE connectivity check packets. All values MUST 733 be in network byte order. 735 5.1. HIP Control Packets 737 0 1 2 3 738 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 739 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 740 | Source Port | Destination Port | 741 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 742 | Length | Checksum | 743 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 744 | 32 bits of zeroes | 745 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 746 | | 747 ~ HIP Header and Parameters ~ 748 | | 749 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 751 Figure 5: Format of UDP-encapsulated HIP Control Packets 753 HIP control packets are encapsulated in UDP packets as defined in 754 Section 2.2 of [RFC3948], "rules for encapsulating IKE messages", 755 except a different port number is used. Figure 5 illustrates the 756 encapsulation. The UDP header is followed by 32 zero bits that can 757 be used to differentiate HIP control packets from ESP packets. The 758 HIP header and parameters follow the conventions of [RFC5201] with 759 the exception that the HIP header checksum MUST be zero. The HIP 760 header checksum is zero for two reasons. First, the UDP header 761 contains already a checksum. Second, the checksum definition in 762 [RFC5201] includes the IP addresses in the checksum calculation. The 763 NATs unaware of HIP cannot recompute the HIP checksum after changing 764 IP addresses. 766 A HIP relay server or a Responder without a relay MUST listen at UDP 767 port HIPPORT for incoming UDP encapsulated HIP control packets. 769 5.2. Connectivity Checks 771 The connectivity checks are performed using STUN Binding Requests as 772 defined in [I-D.ietf-mmusic-ice]. This section describes the details 773 of the parameters in the STUN messages. 775 The Binding Requests MUST use STUN short term credentials with HITs 776 of the Initiator and Responder as the username fragments. The 777 username is formed from the username fragments as defined in Section 778 7.1.1.3 of [I-D.ietf-mmusic-ice] with the Initiator being the 779 "offerer" and the Responder being the "answerer". The HITs are used 780 as usernames by expressing them in IPv6 hexadecimal ASCII format 781 [RFC1884], using lowercase letters, each 16 bit HIT fragment 782 separated by a one byte colon (hex 0x3a). The leading zeroes MUST 783 NOT be omitted so that the username's size is fixed. 785 The STUN password is drawn from the DH keying material. Drawing of 786 HIP keys is defined in [RFC5201] Section 6.5 and drawing of ESP keys 787 in [RFC5202] Section 7. Correspondingly, the hosts MUST draw 788 symmetric keys for STUN according to [RFC5201] Section 6.5. The 789 hosts draw the STUN key after HIP keys, or after ESP keys if ESP 790 transform was successfully negotiated in the base exchange. Both 791 hosts draw a 128 bit key from the DH keying material, express that in 792 hexadecimal ASCII format using only lowercase letters (resulting in 793 32 numbers or lowercase letters), and use that as both the local and 794 peer password. [RFC5389] describes how hosts use the password for 795 message integrity of STUN messages. 797 Both the username and password are expressed in ASCII hexadecimal 798 format to prevent the need to run them through SASLPrep as defined in 799 [RFC5389]. 801 The connectivity checks MUST contain PRIORITY attribute. They MAY 802 contain USE-CANDIDATE attribute as defined in Section 7.1.1.1 of 803 [I-D.ietf-mmusic-ice]. 805 The Initiator is always in the controller role during a base 806 exchange. Hence, the ICE-CONTROLLED and ICE-CONTROLLING attributes 807 are not needed and SHOULD NOT be used. When two hosts are initiating 808 a connection to each other simultaneously, HIP state machine detects 809 it and assigns the host with the larger HIT as the Responder as 810 explained in Sections 4.4.2 and 6.7 in [RFC5201]. 812 5.3. Keepalives 814 The keepalives for HIP associations that are created with ICE are 815 STUN Binding Indications, as defined in [RFC5389]. In contrast to 816 the UDP encapsulated HIP header, the non-ESP-marker between the UDP 817 header and the STUN header is excluded. Keepalives MUST contain the 818 FINGERPRINT STUN attribute but SHOULD NOT contain any other STUN 819 attributes and SHOULD NOT utilize any authentication mechanism. STUN 820 messages are demultiplexed from ESP and HIP control messages using 821 the STUN markers, such as the magic cookie value and the FINGERPRINT 822 attribute. 824 Keepalives for HIP associations created without ICE are HIP control 825 messages that have NOTIFY as the packet type. The NOTIFY messages do 826 not contain any parameters. 828 5.4. NAT Traversal Mode Parameter 830 Format of the NAT_TRAVERSAL_MODE parameter is similar to the format 831 of the ESP_TRANSFORM parameter in [RFC5202] and is shown in the 832 Figure 6. This specification defines traversal mode identifiers UDP- 833 ENCAPSULATION and ICE-STUN-UDP. The identifier RESERVED is reserved 834 for future use. Future specifications may define more traversal 835 modes. 837 0 1 2 3 838 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 839 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 840 | Type | Length | 841 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 842 | Reserved | Mode ID #1 | 843 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 844 | Mode ID #2 | Mode ID #3 | 845 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 846 | Mode ID #n | Padding | 847 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 849 Type [ TBD by IANA: 608 ] 850 Length length in octets, excluding Type, Length, and padding 851 Reserved zero when sent, ignored when received 852 Mode ID defines the NAT traversal mode to be used 854 The following NAT traversal mode IDs are defined: 856 ID Value 857 RESERVED 0 858 UDP-ENCAPSULATION 1 859 ICE-STUN-UDP 2 861 Figure 6: Format of the NAT_TRAVERSAL_MODE parameter 863 The sender of a NAT_TRAVERSAL_MODE parameter MUST make sure that 864 there are no more than six (6) Mode IDs in one NAT_TRAVERSAL_MODE 865 parameter. The limited number of Mode IDs sets the maximum size of 866 the NAT_TRAVERSAL_MODE parameter. 868 5.5. Connectivity Check Transaction Pacing Parameter 870 The TRANSACTION_PACING parameter shown in Figure 7 contains only the 871 connectivity check pacing value, expressed in milliseconds, as 32 bit 872 unsigned integer. 874 0 1 2 3 875 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 876 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 877 | Type | Length | 878 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 879 | Min Ta | 880 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 882 Type [ TBD by IANA: 610 ] 883 Length length in octets, excluding Type and Length 884 Min Ta the minimum connectivity check transaction pacing 885 value the host would use 887 Figure 7: Format of the TRANSACTION_PACING parameter 889 5.6. Relay and Registration Parameters 891 Format of the REG_FROM, RELAY_FROM and RELAY_TO parameters is shown 892 in Figure 8. All parameters are identical except for the type. 893 REG_FROM is the only parameter covered with the signature. 895 0 1 2 3 896 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 897 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 898 | Type | Length | 899 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 900 | Port | Protocol | Reserved | 901 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 902 | | 903 | Address | 904 | | 905 | | 906 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 908 Type [ TBD by IANA: 909 REG_FROM: 950 910 RELAY_FROM: 63998 (2^16 - 2^11 + 2^9 - 2) 911 RELAY_TO: 64002 (2^16 - 2^11 + 2^9 + 2) ] 912 Length 20 913 Port transport port number; zero when plain IP is used 914 Protocol IANA assigned, Internet Protocol number. 915 17 for UDP, 0 for plain IP. 916 Reserved reserved for future use; zero when sent, ignored 917 when received 918 Address an IPv6 address or an IPv4 address in "IPv4-Mapped 919 IPv6 address" format 921 Figure 8: Format of the REG_FROM, RELAY_FROM and RELAY_TO parameters 922 REG_FROM contains the transport address and protocol where the HIP 923 relay server sees the registration coming from. RELAY_FROM contains 924 the address where the relayed packet was received from by the relay 925 server and the protocol that was used. The RELAY_TO contains same 926 information about the address where a packet should be forwarded to. 928 5.7. LOCATOR Parameter 930 The generic LOCATOR parameter format is the same as in [RFC5206]. 931 However, presenting ICE candidates requires a new locator type. The 932 generic and NAT traversal specific locator parameters are illustrated 933 in Figure 9. 935 0 1 2 3 936 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 937 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 938 | Type | Length | 939 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 940 | Traffic Type | Locator Type | Locator Length| Reserved |P| 941 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 942 | Locator Lifetime | 943 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 944 | Locator | 945 | | 946 | | 947 | | 948 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 949 . . 950 . . 951 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 952 | Traffic Type | Loc Type = 2 | Locator Length| Reserved |P| 953 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 954 | Locator Lifetime | 955 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 956 | Transport Port | Transp. Proto| Kind | 957 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 958 | Priority | 959 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 960 | SPI | 961 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 962 | Locator | 963 | | 964 | | 965 | | 966 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 968 Figure 9: LOCATOR parameter 970 The individual fields in the LOCATOR parameter are described in 971 Table 2. 973 +-----------+----------+--------------------------------------------+ 974 | Field | Value(s) | Purpose | 975 +-----------+----------+--------------------------------------------+ 976 | Type | 193 | Parameter type | 977 | Length | Variable | Length in octets, excluding Type and | 978 | | | Length fields and padding | 979 | Traffic | 0-2 | Is the locator for HIP signaling (1), for | 980 | Type | | ESP (2), or for both (0) | 981 | Locator | 2 | "Transport address" locator type | 982 | Type | | | 983 | Locator | 7 | Length of the fields after Locator | 984 | Length | | Lifetime in 4-octet units | 985 | Reserved | 0 | Reserved for future extensions | 986 | Preferred | 0 | Not used for transport address locators; | 987 | (P) bit | | MUST be ignored by the receiver. | 988 | Locator | Variable | Locator lifetime in seconds | 989 | Lifetime | | | 990 | Transport | Variable | Transport layer port number | 991 | Port | | | 992 | Transport | Variable | IANA Assigned, transport layer Internet | 993 | Protocol | | Protocol number. Currently only UDP (17) | 994 | | | is supported. | 995 | Kind | Variable | 0 for host, 1 for server reflexive, 2 for | 996 | | | peer reflexive or 3 for relayed address | 997 | Priority | Variable | Locator's priority as described in | 998 | | | [I-D.ietf-mmusic-ice] | 999 | SPI | Variable | SPI value which the host expects to see in | 1000 | | | incoming ESP packets that use this locator | 1001 | Locator | Variable | IPv6 address or an "IPv4-Mapped IPv6 | 1002 | | | address" format IPv4 address [RFC3513] | 1003 +-----------+----------+--------------------------------------------+ 1005 Table 2: Fields of the LOCATOR parameter 1007 5.8. RELAY_HMAC Parameter 1009 The RELAY_HMAC parameter value has the TLV type 65520 (2^16 - 2^5 + 1010 2^4). It has the same semantics as RVS_HMAC [RFC5204]. 1012 5.9. Registration Types 1014 The REG_INFO, REG_REQ, REG_RESP and REG_FAILED parameters contain 1015 values for HIP relay server registration. The value for 1016 RELAY_UDP_HIP is 2. 1018 5.10. ESP Data Packets 1020 [RFC3948] describes UDP encapsulation of the IPsec ESP transport and 1021 tunnel mode. On the wire, the HIP ESP packets do not differ from the 1022 transport mode ESP and thus the encapsulation of the HIP ESP packets 1023 is same as the UDP encapsulation transport mode ESP. However, the 1024 (semantic) difference to BEET mode ESP packets used by HIP is that IP 1025 header is not used in BEET integrity protection calculation. 1027 During the HIP base exchange, the two peers exchange parameters that 1028 enable them to define a pair of IPsec ESP security associations (SAs) 1029 as described in [RFC5202]. When two peers perform a UDP-encapsulated 1030 base exchange, they MUST define a pair of IPsec SAs that produces 1031 UDP-encapsulated ESP data traffic. 1033 The management of encryption/authentication protocols and SPIs is 1034 defined in [RFC5202]. The UDP encapsulation format and processing of 1035 HIP ESP traffic is described in Section 6.1 of [RFC5202]. 1037 6. Security Considerations 1039 6.1. Privacy Considerations 1041 The locators are in plain text format in favor of inspection at HIP- 1042 aware middleboxes in the future. The current draft does not specify 1043 encrypted versions of LOCATORs even though it could be beneficial for 1044 privacy reasons. 1046 It is possible that an Initiator or Responder may not want to reveal 1047 all of its locators to its peer. For example, a host may not want to 1048 reveal the internal topology of the private address realm and it 1049 discards host addresses. Such behavior creates non-optimal paths 1050 when the hosts are located behind the same NAT. Especially, this 1051 could be a problem with a legacy NAT that does not support routing 1052 from the private address realm back to itself through the outer 1053 address of the NAT. This scenario is referred to as the hairpin 1054 problem [RFC5128]. With such a legacy NAT, the only option left 1055 would be to use a relayed transport address from a TURN server. 1057 As a consequence, a host may support locator-based privacy by leaving 1058 out the reflexive candidates. However, the trade-off in using only 1059 host candidates can produce suboptimal paths that can congest the 1060 TURN server. 1062 The use of HIP relay servers or TURN relays can be also useful for 1063 protection against Denial-of-Service attacks. If a Responder reveals 1064 only its HIP relay server addresses and Relayed candidates to 1065 Initiators, the Initiators can only attack the relays. That does not 1066 prevent the Responder from initiating new outgoing connections if a 1067 path around the relay exists. 1069 6.2. Opportunistic Mode 1071 A HIP relay server should have one address per relay client when a 1072 HIP relay is serving more than one relay clients and supports 1073 opportunistic mode. Otherwise, it cannot be guaranteed that the HIP 1074 relay server can deliver the I1 packet to the intended recipient. 1076 6.3. Base Exchange Replay Protection for HIP Relay Server 1078 In certain scenarios, it is possible that an attacker, or two 1079 attackers, can replay an earlier base exchange through a HIP relay 1080 server by masquerading as the original Initiator and Responder. The 1081 attack does not require the attacker(s) to compromise the private 1082 key(s) of the attacked host(s). However, for this attack to succeed, 1083 the Responder has to be disconnected from the HIP relay server. 1085 The relay can protect itself against replay attacks by involving in 1086 the base exchange by introducing nonces that the end-hosts (Initiator 1087 and Responder) have to sign. One way to do this is to add 1088 ECHO_REQUEST_M parameters to the R1 and I2 messages as described in 1089 [I-D.heer-hip-middle-auth] and drop the I2 or R2 messages if the 1090 corresponding ECHO_RESPONSE_M parameters are not present. 1092 6.4. Demuxing Different HIP Associations 1094 Section 5.1 of [RFC3948] describes a security issue for the UDP 1095 encapsulation in the standard IP tunnel mode when two hosts behind 1096 different NATs have the same private IP address and initiate 1097 communication to the same Responder in the public Internet. The 1098 Responder cannot distinguish between two hosts, because security 1099 associations are based on the same inner IP addresses. 1101 This issue does not exist with the UDP encapsulation of HIP ESP 1102 transport format because the Responder uses HITs to distinguish 1103 between different Initiators. 1105 7. IANA Considerations 1107 This section is to be interpreted according to [RFC2434]. 1109 This draft currently uses a UDP port in the "Dynamic and/or Private 1110 Port" and HIPPORT. Upon publication of this document, IANA is 1111 requested to register a UDP port and the RFC editor is requested to 1112 change all occurrences of port HIPPORT to the port IANA has 1113 registered. The HIPPORT number 50500 should be used for initial 1114 experimentation. 1116 This document updates the IANA Registry for HIP Parameter Types by 1117 assigning new HIP Parameter Type values for the new HIP Parameters: 1118 RELAY_FROM, RELAY_TO and REG_FROM (defined in Section 5.6), 1119 RELAY_HMAC (defined in Section 5.8), TRANSACTION_PACING (defined in 1120 Section 5.5), and NAT_TRAVERSAL_MODE (defined in Section 5.4). 1122 8. Contributors 1124 This draft is a product of a design team which also included Marcelo 1125 Bagnulo and Jan Melen who both have made major contributions to this 1126 document. 1128 9. Acknowledgments 1130 Thanks for Jonathan Rosenberg and the rest of the MMUSIC WG folks for 1131 the excellent work on ICE. In addition, the authors would like to 1132 thank Andrei Gurtov, Simon Schuetz, Martin Stiemerling, Lars Eggert, 1133 Vivien Schmitt, Abhinav Pathak for their contributions and Tobias 1134 Heer, Teemu Koponen, Juhana Mattila, Jeffrey M. Ahrenholz, Kristian 1135 Slavov, Janne Lindqvist, Pekka Nikander, Lauri Silvennoinen, Jukka 1136 Ylitalo, Juha Heinanen, Joakim Koskela, Samu Varjonen, Dan Wing and 1137 Jani Hautakorpi for their comments on this document. 1139 Miika Komu is working in the Networking Research group at Helsinki 1140 Institute for Information Technology (HIIT). The InfraHIP project 1141 was funded by Tekes, Telia-Sonera, Elisa, Nokia, the Finnish Defence 1142 Forces, and Ericsson and Birdstep. 1144 10. References 1146 10.1. Normative References 1148 [I-D.ietf-behave-turn] 1149 Rosenberg, J., Mahy, R., and P. Matthews, "Traversal Using 1150 Relays around NAT (TURN): Relay Extensions to Session 1151 Traversal Utilities for NAT (STUN)", 1152 draft-ietf-behave-turn-11 (work in progress), 1153 October 2008. 1155 [I-D.ietf-mmusic-ice] 1156 Rosenberg, J., "Interactive Connectivity Establishment 1157 (ICE): A Protocol for Network Address Translator (NAT) 1158 Traversal for Offer/Answer Protocols", 1159 draft-ietf-mmusic-ice-19 (work in progress), October 2007. 1161 [RFC1884] Hinden, R. and S. Deering, "IP Version 6 Addressing 1162 Architecture", RFC 1884, December 1995. 1164 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1165 Requirement Levels", BCP 14, RFC 2119, March 1997. 1167 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1168 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 1169 October 1998. 1171 [RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6 1172 (IPv6) Addressing Architecture", RFC 3513, April 2003. 1174 [RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol 1175 (HIP) Architecture", RFC 4423, May 2006. 1177 [RFC5201] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson, 1178 "Host Identity Protocol", RFC 5201, April 2008. 1180 [RFC5202] Jokela, P., Moskowitz, R., and P. Nikander, "Using the 1181 Encapsulating Security Payload (ESP) Transport Format with 1182 the Host Identity Protocol (HIP)", RFC 5202, April 2008. 1184 [RFC5203] Laganier, J., Koponen, T., and L. Eggert, "Host Identity 1185 Protocol (HIP) Registration Extension", RFC 5203, 1186 April 2008. 1188 [RFC5204] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) 1189 Rendezvous Extension", RFC 5204, April 2008. 1191 [RFC5206] Nikander, P., Henderson, T., Vogt, C., and J. Arkko, "End- 1192 Host Mobility and Multihoming with the Host Identity 1193 Protocol", RFC 5206, April 2008. 1195 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 1196 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 1197 October 2008. 1199 10.2. Informative References 1201 [I-D.heer-hip-middle-auth] 1202 Heer, T., Wehrle, K., and M. Komu, "End-Host 1203 Authentication for HIP Middleboxes", 1204 draft-heer-hip-middle-auth-01 (work in progress), 1205 July 2008. 1207 [I-D.rosenberg-mmusic-ice-nonsip] 1208 Rosenberg, J., "Guidelines for Usage of Interactive 1209 Connectivity Establishment (ICE) by non Session 1210 Initiation Protocol (SIP) Protocols", 1211 draft-rosenberg-mmusic-ice-nonsip-01 (work in progress), 1212 July 2008. 1214 [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. 1215 Stenberg, "UDP Encapsulation of IPsec ESP Packets", 1216 RFC 3948, January 2005. 1218 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 1219 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 1220 RFC 4787, January 2007. 1222 [RFC5128] Srisuresh, P., Ford, B., and D. Kegel, "State of Peer-to- 1223 Peer (P2P) Communication across Network Address 1224 Translators (NATs)", RFC 5128, March 2008. 1226 [RFC5207] Stiemerling, M., Quittek, J., and L. Eggert, "NAT and 1227 Firewall Traversal Issues of Host Identity Protocol (HIP) 1228 Communication", RFC 5207, April 2008. 1230 Appendix A. Selecting a Value for Check Pacing 1232 Selecting a suitable value for the connectivity check transaction 1233 pacing is essential for the performance of connectivity check-based 1234 NAT traversal. The value should not be too small so that the checks 1235 do not cause congestion in the network or overwhelm the NATs. On the 1236 other hand, too high pacing value makes the checks last for a long 1237 time and thus increase the connection setup delay. 1239 The Ta value may be configured by the user in environments where the 1240 network characteristics are known beforehand. However, if the 1241 characteristics are not know, it is recommended that the value is 1242 adjusted dynamically. In this case it's recommended that the hosts 1243 estimate the RTT between them and set the minimum Ta value so that 1244 only two connectivity check messages are sent on every RTT. 1246 One way to estimate the RTT is to use the time it takes for the HIP 1247 relay server registration exchange to complete; this would give an 1248 estimate on the registering host's access link's RTT. Also the I1/R1 1249 exchange could be used for estimating the RTT, but since the R1 can 1250 be cached in the network, or the relaying service can increase the 1251 delay notably, it is not recommended. 1253 Appendix B. IPv4-IPv6 Interoperability 1255 Currently relay client and server do not have to run any ICE 1256 connectivity tests as described in Section 4.8. However, it could be 1257 useful for IPv4-IPv6 interoperability when the HIP relay server 1258 actually includes both the NAT traversal mode parameter and multiple 1259 locators in R2. The interoperability benefit is that the relay could 1260 support IPv4-based Initiators and IPv6-based Responders by converting 1261 the network headers and recalculating UDP checksums. 1263 Such an approach is underspecified in this document currently. It is 1264 not yet recommended because it may consume resources at the relay and 1265 requires also similar conversion support at the TURN relay for data 1266 packets. 1268 Appendix C. Base Exchange through a Rendezvous Server 1270 When the Initiator looks up the information of the Responder from 1271 DNS, it's possible that it discovers an RVS record [RFC5204]. In 1272 this case, if the Initiator uses NAT traversal methods described in 1273 this document, it uses its own HIP relay server to forward HIP 1274 traffic to the Rendezvous server. The Initiator will send the I1 1275 message using its HIP relay server which will then forward it to the 1276 RVS server of the Responder. In this case, the value of the protocol 1277 field in the RELAY_TO parameter MUST be IP since RVS does not support 1278 UDP encapsulated base exchange packets. The Responder will send the 1279 R1 packet directly to the Initiator's HIP relay server and the 1280 following I2 and R2 packets are also sent directly using the relay. 1282 In case the Initiator is not able to distinguish which records are 1283 RVS address records and which are Responder's address records (e.g., 1284 if the DNS server did not support HIP extensions), the Initiator 1285 SHOULD first try to contact the Responder directly, without using a 1286 HIP relay server. If none of the addresses is reachable, it MAY try 1287 out them using its own HIP relay server as described above. 1289 Appendix D. Document Revision History 1291 To be removed upon publication 1292 +-----------------------------+-------------------------------------+ 1293 | Revision | Comments | 1294 +-----------------------------+-------------------------------------+ 1295 | draft-ietf-nat-traversal-00 | Initial version. | 1296 | draft-ietf-nat-traversal-01 | Draft based on RVS. | 1297 | draft-ietf-nat-traversal-02 | Draft based on Relay proxies and | 1298 | | ICE concepts. | 1299 | draft-ietf-nat-traversal-03 | Draft based on STUN/ICE formats. | 1300 | draft-ietf-nat-traversal-04 | Issues 25-27,29-36 | 1301 | draft-ietf-nat-traversal-05 | Issues 28,40-43,47,49,51 | 1302 +-----------------------------+-------------------------------------+ 1304 Authors' Addresses 1306 Miika Komu 1307 Helsinki Institute for Information Technology 1308 Metsanneidonkuja 4 1309 Espoo 1310 Finland 1312 Phone: +358503841531 1313 Fax: +35896949768 1314 Email: miika@iki.fi 1315 URI: http://www.hiit.fi/ 1317 Thomas Henderson 1318 The Boeing Company 1319 P.O. Box 3707 1320 Seattle, WA 1321 USA 1323 Email: thomas.r.henderson@boeing.com 1325 Philip Matthews 1326 (Unaffiliated) 1328 Email: philip_matthews@magma.ca 1329 Hannes Tschofenig 1330 Nokia Siemens Networks 1331 Linnoitustie 6 1332 Espoo 02600 1333 Finland 1335 Phone: +358 (50) 4871445 1336 Email: Hannes.Tschofenig@gmx.net 1337 URI: http://www.tschofenig.com 1339 Ari Keranen (editor) 1340 Ericsson Research Nomadiclab 1341 Hirsalantie 11 1342 02420 Jorvas 1343 Finland 1345 Phone: +358 9 2991 1346 Email: ari.keranen@ericsson.com 1348 Full Copyright Statement 1350 Copyright (C) The IETF Trust (2008). 1352 This document is subject to the rights, licenses and restrictions 1353 contained in BCP 78, and except as set forth therein, the authors 1354 retain all their rights. 1356 This document and the information contained herein are provided on an 1357 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1358 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1359 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1360 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1361 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1362 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1364 Intellectual Property 1366 The IETF takes no position regarding the validity or scope of any 1367 Intellectual Property Rights or other rights that might be claimed to 1368 pertain to the implementation or use of the technology described in 1369 this document or the extent to which any license under such rights 1370 might or might not be available; nor does it represent that it has 1371 made any independent effort to identify any such rights. Information 1372 on the procedures with respect to rights in RFC documents can be 1373 found in BCP 78 and BCP 79. 1375 Copies of IPR disclosures made to the IETF Secretariat and any 1376 assurances of licenses to be made available, or the result of an 1377 attempt made to obtain a general license or permission for the use of 1378 such proprietary rights by implementers or users of this 1379 specification can be obtained from the IETF on-line IPR repository at 1380 http://www.ietf.org/ipr. 1382 The IETF invites any interested party to bring to its attention any 1383 copyrights, patents or patent applications, or other proprietary 1384 rights that may cover technology that may be required to implement 1385 this standard. Please address the information to the IETF at 1386 ietf-ipr@ietf.org.