idnits 2.17.1 draft-ietf-hip-nat-traversal-02.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 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1380. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1391. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1398. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1404. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The document 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 (July 6, 2007) is 6136 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-10) exists of draft-ietf-hip-base-08 == Outdated reference: A later version (-19) exists of draft-ietf-mmusic-ice-16 == Outdated reference: A later version (-09) exists of draft-nikander-esp-beet-mode-07 ** Obsolete normative reference: RFC 2373 (Obsoleted by RFC 3513) ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 4423 (Obsoleted by RFC 9063) == Outdated reference: A later version (-06) exists of draft-ietf-behave-p2p-state-03 Summary: 4 errors (**), 0 flaws (~~), 6 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 HIP Working Group M. Komu, Ed. 3 Internet-Draft HIIT 4 Intended status: Experimental S. Schuetz 5 Expires: January 7, 2008 M. Stiemerling 6 NEC 7 July 6, 2007 9 HIP Extensions for the Traversal of Network Address Translators 10 draft-ietf-hip-nat-traversal-02 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on January 7, 2008. 37 Copyright Notice 39 Copyright (C) The IETF Trust (2007). 41 Abstract 43 The Host Identity Protocol (HIP) provides a new namespace that can be 44 used for uniquely identifying hosts in public and also in private 45 address realms. Usually, HIP control and data traffic cannot 46 traverse Network Address Translators (NATs), that hinders general 47 deployment. This document specifies NAT traversal extensions for 48 HIP. As HIP is located between network and transport layer, the 49 extensions also provide general-purpose NAT traversal support for all 50 high-layer networking applications that run over HIP. The basic 51 design concepts for these extensions have been adopted from the 52 Interactive Connectivity Establishment (ICE) protocol to HIP. Using 53 the specified extensions, two HIP-capable hosts are able to 54 communicate with each other even when they are in different private 55 address realms. 57 Table of Contents 59 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 3. HIP Across NATs . . . . . . . . . . . . . . . . . . . . . . . 5 62 3.1. Port Number Selection . . . . . . . . . . . . . . . . . . 6 63 3.2. Relay Registration and NAT Detection . . . . . . . . . . . 6 64 3.3. Base Exchange via Relay . . . . . . . . . . . . . . . . . 8 65 3.4. Base Exchange without a Relay . . . . . . . . . . . . . . 10 66 3.5. Connectivity Tests . . . . . . . . . . . . . . . . . . . . 11 67 3.6. Selecting an Address Pair . . . . . . . . . . . . . . . . 13 68 3.7. Mobility . . . . . . . . . . . . . . . . . . . . . . . . . 14 69 3.8. NAT Keepalives . . . . . . . . . . . . . . . . . . . . . . 15 70 3.9. Closing of HIP Associations . . . . . . . . . . . . . . . 16 71 3.10. Communication with HIP Hosts without NAT Traversal 72 Support . . . . . . . . . . . . . . . . . . . . . . . . . 16 73 4. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . . 17 74 4.1. HIP Control Packets . . . . . . . . . . . . . . . . . . . 17 75 4.2. Control Channel Keep-Alives . . . . . . . . . . . . . . . 18 76 4.3. RELAY_FROM, RELAY_TO and RELAY_VIA Parameters . . . . . . 18 77 4.4. LOCATOR Parameter . . . . . . . . . . . . . . . . . . . . 19 78 4.5. RELAY_HMAC . . . . . . . . . . . . . . . . . . . . . . . . 20 79 4.6. Registration Types . . . . . . . . . . . . . . . . . . . . 20 80 4.7. ESP Data Packets . . . . . . . . . . . . . . . . . . . . . 21 81 4.8. UDP Encapsulation/Decapsulation of IPsec BEET-Mode ESP . . 21 82 5. Firewall Traversal . . . . . . . . . . . . . . . . . . . . . . 23 83 6. Security Considerations . . . . . . . . . . . . . . . . . . . 23 84 6.1. A Difference to RFC3948 . . . . . . . . . . . . . . . . . 23 85 6.2. Privacy Considerations . . . . . . . . . . . . . . . . . . 24 86 6.3. Opportunistic Mode . . . . . . . . . . . . . . . . . . . . 24 87 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 88 8. Acknowlegements . . . . . . . . . . . . . . . . . . . . . . . 25 89 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 90 9.1. Normative References . . . . . . . . . . . . . . . . . . . 26 91 9.2. Informative References . . . . . . . . . . . . . . . . . . 27 92 Appendix A. Differences to ICE . . . . . . . . . . . . . . . . . 28 93 Appendix B. Document Revision History . . . . . . . . . . . . . . 29 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 95 Intellectual Property and Copyright Statements . . . . . . . . . . 31 97 1. Terminology 99 In general, this document borrows the terminology from 100 [I-D.ietf-hip-base] and [RFC4423]. Additional terms are defined in 101 the table below." These draft e.g. define "Initiator" and 102 "Responder" 104 +---------------------+---------------------------------------------+ 105 | Term | Explanation | 106 +---------------------+---------------------------------------------+ 107 | Rendezvous server | A host that forwards I1 packets to the | 108 | | Responder | 109 | HIP Relay | A host that forwards all HIP control | 110 | | packets between an Initiator and Responder | 111 | ESP Relay | A host that forwards ESP traffic between | 112 | | two HIP-enabled hosts | 113 | Locator | A routable IPv4 or IPv6 address | 114 | Transport locator | Transport layer port and the corresponding | 115 | | IPv4/v6 address | 116 | Unreflexive locator | An IPv4 or IPv6 address of a network | 117 | | interface of a host | 118 | Relay reflexive | A translated transport locator of a host as | 119 | transport locator | observed by a relay | 120 | Peer reflexive | A translated transport locator of a host as | 121 | transport locator | observed by its peer | 122 | Leased transport | Transport locator of an ESP relay | 123 | locator | | 124 +---------------------+---------------------------------------------+ 126 Table 1: Terminology 128 2. Introduction 130 The Host Identity Protocol (HIP) describes a new communication 131 mechanism for Internet hosts [RFC4423]. It introduces a new 132 namespace and protocol layer between the network and transport layers 133 that decouples the identifier and locator roles to support mobility 134 and multihoming in the Internet architecture. HIP also secures 135 application layer communications using IPsec ESP [I-D.ietf-hip-esp]. 137 The HIP protocol [I-D.ietf-hip-base] cannot operate across legacy NAT 138 middleboxes as described in [I-D.irtf-hiprg-nat]. This document 139 specifies mechanisms that allow HIP to traverse through such NAT 140 middleboxes that are neither HIP-aware nor ESP-aware, without manual 141 configuration of the NAT middleboxes. 143 HIP introduces a new namespace for hosts that decouples the identity 144 of a host from its location [RFC4423]. The namespace consists of 145 Host Identifiers which are public keys. The hosts create the 146 corresponding private keys by themselves which makes identity theft 147 more difficult. 149 The new namespace of HIP has some additional benefits when the 150 extensions defined in this document are used. First, it is possible 151 to address hosts behind a single NAT middlebox in a relatively simple 152 way. The NAT middlebox translates the locators, but the Host 153 Identifiers remain the same and can be used for uniquely identifying 154 a host inside the private address realm. Second, multiple services 155 on different hosts can share the same transport layer port number 156 behind a single legacy NAT. There is no multiplexing issue as long 157 as these hosts have different Host Identifiers and UDP encapsulation 158 is used for traversing the legacy NAT. 160 Several different types of NATs exist [RFC2663]. This document 161 describes HIP extensions for the traversal of both Network Address 162 Translator (NAT) and Network Address and Port Translator (NAPT) 163 middleboxes. The document generally uses the term NAT to refer to 164 both types of middleboxes, unless it needs to distinguish between the 165 two types. 167 Three basic scenarios exist for NAT traversal. In the first case, 168 only the Initiator of a HIP base exchange is located behind a NAT. 169 In the second case, only the Responder of a HIP base exchange is 170 located behind a NAT. The respective peer is assumed to be located 171 at a publicly reachable address in both cases. In the third case, 172 both peers are located behind (possible different) NATs. All of the 173 use cases are addressed in the draft in a unified method that has 174 been adopted from Interactive Connectivity Establishment (ICE) 175 protocol [I-D.ietf-mmusic-ice] and adapted to HIP. 177 Legacy NAT devices do not operate consistently although the behavior 178 for new NAT devices has been unified in [RFC4787]. The HIP protocol 179 extensions in this document make as little assumptions as possible of 180 the behavior of the NAT devices so that NAT traversal will work even 181 with legacy NAT devices in the most general sense. The purpose of 182 the extensions is to allow two HIP-enabled hosts to communicate with 183 each other even if one or both communicating hosts are in private 184 address realms. With some legacy NAT devices, connecting two hosts 185 behind different address realms is impossible without relaying all 186 traffic through a third party host [I-D.ietf-behave-p2p-state]. As a 187 consequence, the relay host introduces additional hops between the 188 hosts and can become a point of network congestion. In the 189 extensions described in this document, the peers try to avoid the use 190 of a relay for data traffic and only make use of it when necessary. 192 Hosts that always get a public addresses can use the rendezvous 193 services as described in [I-D.ietf-hip-rvs]. Hosts that can be 194 located in private-address realms may use a transport-layer based 195 relay service as defined in this document. Both rendezvous and relay 196 services forward HIP control packets, but the main difference is that 197 the rendezvous service forwards only the initial I1 packet of the 198 base exchange while all other HIP control packets are sent directly 199 between the communicating hosts. In contrast, the relay service 200 relays all HIP control packets because p2p-unfriendly NAT devices 201 drop the packets otherwise [I-D.ietf-behave-p2p-state]. The peers 202 use the control channel to communicate their current locators to each 203 other to find a direct path for carrying ESP encapsulated data 204 traffic. A direct path between the hosts enables efficient delivery 205 of data traffic without relaying of ESP packets through an 206 intermediary ESP relay. The direct path is searched using 207 connectivity tests. 209 The basis for the connectivity tests is ICE [I-D.ietf-mmusic-ice]. 210 Two hosts communicate their transport locator (a port and an IP 211 address) to each other in a base exchange. The local locators are 212 paired with peer locators and the pairs are prioritized according to 213 their proximity. The locator pairs are tested sequentially in 214 priority order using return routability tests [I-D.ietf-hip-mm]. 215 Both sides participate in the connectivity tests. The tests also 216 determine whether transport layer encapsulation is required or not. 217 As a result, the hosts either detect that no transport locator pairs 218 are working, or establish a number of working locator pairs and 219 select a single pair to be used for communication. 221 The same connectivity tests are also used in situations when a mobile 222 host moves to a different network. The mobile host communicates its 223 new location to the corresponding node through the relay server of 224 its peer and starts the connectivity tests. 226 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 227 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 228 document are to be interpreted as described in [RFC2119]. 230 3. HIP Across NATs 232 This section describes NAT traversal between two HIP end-hosts. A 233 successful NAT traversal requires at least the Responder located in a 234 private address realm to register to a relay server. The use of the 235 relay is optional when the Responder is located in a public address 236 realm without rendezvous server. 238 The base exchange is relayed through the relay server. Next, the 239 hosts test the reachability between the different locators to 240 construct a direct route. When a direct route is not possible, the 241 hosts resort to ESP relays. When locators of a host change, the 242 hosts test reachability of locators again and select the "optimal" 243 locator. End-hosts can tear down HIP associations using the CLOSE 244 mechanism through the relay. 246 3.1. Port Number Selection 248 This document defines only UDP encapsulation for HIP and ESP packets. 249 Further extensions may define bindings for other transport protocols. 250 The RECOMMENDED transport protocol is UDP. 252 It is RECOMMENDED that an Initiator selects a random port number 253 between the ephemeral port ranged 49152-65535 for initiating a base 254 exchange even for registration. However, the allocated port MUST be 255 maintained until all of the corresponding Host Associations are 256 closed. Alternatively, a host MAY also use a single fixed port for 257 initiating all outgoing connections. 259 A relay or a Responder without a relay MUST listen at transport port 260 HIPPORT for incoming UDP-encapsulated HIP control packets. 262 3.2. Relay Registration and NAT Detection 264 HIP rendezvous servers are used in non-NATted environments and its 265 use is described in [I-D.ietf-hip-rvs]. This section defines the 266 another types middleboxes, called HIP and ESP Relays, which are used 267 in NATted environments. 269 A HIP relay forwards UDP-encapsulated traffic, and in future 270 extensions, a relay may also forward TCP-encapsulated traffic. A 271 single relay may forward only HIP control packets, ESP traffic or 272 both. A host acting as a Responder in a private address realm SHOULD 273 use a HIP relay for NAT traversal. It is RECOMMENDED that the 274 Responder uses also an ESP relay to guarantee successful NAT 275 traversal with p2p-unfriendly NAT devices. 277 A relay MUST NOT forward any packets to a host that has not 278 successfully registered to the relay. The registration process 279 follows the generic registration extensions defined in 280 [I-D.ietf-hip-registration]. The registration process is illustrated 281 in Figure 1. 283 Relay Relay 284 Client Server 285 | 1. I1 | 286 +------------------------------------------------------->| 287 | | 288 | 2. R1(LOCATOR,REG_INFO(RELAY_UDP_HIP,RELAY_UDP_ESP)) | 289 |<-------------------------------------------------------+ 290 | | 291 | 3. I2(LOCATOR,REG_REQ(RELAY_UDP_HIP,RELAY_UDP_ESP)) | 292 +------------------------------------------------------->| 293 | | 294 | 4. R2(REG_RES(RELAY_UDP_HIP,RELAY_UDP_ESP),REG_FROM) | 295 |<-------------------------------------------------------| 296 | | 297 | 5. Connectivity tests | 298 |<------------------------------------------------------>| 300 Figure 1: Example registration to a relay 302 In the above figure, the end-host is referred to as a relay client 303 and the relay middlebox as a relay server. The registration is 304 piggybacked to a base exchange, but it can be done also using HIP 305 UPDATE control packets as described in [I-D.ietf-hip-registration]. 307 In step 1, the relay client starts the registration procedure by 308 sending an I1 packet over the transport layer. The port selection 309 was explained in section Section 3.1. 311 In step 2, the Responder lists the services that it supports in the 312 R1 packet. The support for HIP-over-UDP relaying is denoted by 313 RELAY_UDP_HIP value and the support for ESP-over-UDP relaying is 314 denoted by a RELAY_UDP_ESP value in the REG_INFO parameter. 316 In step 3, the Initiator selects the services it registers to and 317 lists them in the REG_REQ parameter. In this example, the Initiator 318 registers both to HIP and ESP relay services. 320 In step 4, the relay server concludes the registration procedure with 321 an R2 packet and acknowledges the registered services in the REG_RES 322 parameter. The relay may also denote unsuccessful registrations in 323 the REG_FAILED parameter in R2. After the registration, the hosts 324 MUST send periodically NAT keepalive packets to each other as defined 325 later in this document. 327 In step 5, the client and server handle connectivity tests. The 328 procedure is described in a later section. 330 When the ESP relay registration was successful, the relay server uses 331 the source IP address and port of the R2 packet (HIPPORT) to relay 332 ESP traffic with the client. This address-port pair of the relay is 333 referred to as a "leased transport locator" in this document. As the 334 port number may be shared by multiple clients, the ESP relay MUST 335 multiplex the ESP traffic based on SPIs and not the just the port 336 number. 338 The R2 packet also includes an REG_FROM parameter that indicates the 339 transport locator of the client as observed by the server. The 340 transport locator may be translated by a number of NAT middleboxes 341 between the client and the server. This locator is referred to as 342 the "relay reflexive transport locator" later in this document. 344 A single server can provide multiple HIP middlebox services or the 345 services can be distributed among multiple servers. The difference 346 between a HIP rendezvous server [I-D.ietf-hip-rvs] and a HIP relay 347 server depends on the registration. The rendezvous server processing 348 rules apply when the Responder has registered to a middlebox with the 349 RVS registration type. Correspondingly, the middlebox applies the 350 relay extensions defined in this document when the Responder has 351 registered using the relay registration types. When a single server 352 provides both rendezvous and relay services, they are multiplexed 353 depending on the absence or presence of transport layer 354 encapsulation. 356 The Relay Client MUST include a LOCATOR parameter in I2 which lists 357 all of the locators of the Initiator. The Relay Server MUST include 358 a LOCATOR parameter in R1, but it is RECOMMENDED that the LOCATOR 359 parameter includes only the source transport LOCATOR of R1 as the 360 only locator. The case when the Relay Server includes more locators 361 may require IP header conversion between IPv4 and IPv6, insertion, or 362 removal of, UDP header and fragmentation handling. Multiple locators 363 in R1 is left for further experimentation. 365 3.3. Base Exchange via Relay 367 It is RECOMMENDED that the Initiator sends an I1 packet over the 368 transport layer when it is destined to an IPv4 address of the 369 Responder. Respectively, the Responder MUST respond to a such I1 370 packet with an R1 packet over the transport layer and using the same 371 transport protocol. The rest of the base exchange, I2 and R2, MUST 372 also be sent over the transport layer. However, the transport layer 373 encapsulation can be unnecessary when there are no NATs between the 374 Initiator and Responder. This will be detected in the connectivity 375 tests described in the next section. 377 When the Initiator has an IPv6 address and it has discovered only an 378 IPv6 address for the peer, it MUST send it directly over IP. In such 379 a case, the Initiator MUST follow the procedures described in 380 [I-D.ietf-hip-base]. Otherwise, it is RECOMMENDED that the Initiator 381 proceeds as shown in Figure 2. 383 I Relay R 384 | 1. I1 | | 385 +------------------------------->| 2. I1(RELAY_FROM) | 386 | +--------------------------->| 387 | | | 388 | | 3. R1(LOCATOR,RELAY_TO) | 389 | 4. R1(LOCATOR,RELAY_TO) |<---------------------------+ 390 |<-------------------------------+ | 391 | | | 392 | 5. I2(LOCATOR) | | 393 +------------------------------->| | 394 | | 6. I2(LOCATOR,RELAY_FROM) | 395 | +--------------------------->| 396 | | | 397 | | 7. R2(RELAY_TO) | 398 | 8. R2(RELAY_TO) |<---------------------------+ 399 |<-------------------------------+ | 400 | | | 402 Figure 2: Base Exchange via a relay 404 In step 1 of the figure, the Initiator discovers the HIT of the 405 Responder and the IPv4 address of the relay of the Responder. The 406 Initiator sends an I1 packet over the transport layer to the HIT of 407 the Responder. The port selection was explained in Section 3.1. The 408 source address is one of the routable addresses of the host is called 409 "unreflexive locators" in this document. 411 In step 2, the relay receives the I1 packet at port HIPPORT. If the 412 destination HIT belongs to a registered Responder, the relay 413 processes the packet. Otherwise, the relay MUST drop the packet. 414 The relay MUST append a RELAY_FROM parameter to the I1 packet which 415 preserves the transport source address and port of the Initiator. 416 The relay protects the I1 packet with RELAY_HMAC as described in 417 [I-D.ietf-hip-rvs], except that the parameter type is different. The 418 relay MUST change the transport source to and destination of the 419 packet to match the values the Responder used when registering to the 420 relay, i.e., the reverse of the R2 used in the registration. The 421 relay MUST recalculate the transport checksum and forwards the packet 422 to the Responder. 424 In step 3, the Responder receives the I1 packet at the transport 425 layer. The Responder MUST process it according to the rules in 426 [I-D.ietf-hip-base]. In addition, the Responder MUST validate the 427 RELAY_HMAC according to [I-D.ietf-hip-rvs] and drop the packet if the 428 validation fails. The Responder replies with an R1 packet that MUST 429 contain a LOCATOR parameter that lists the locators of the Responder. 430 The locator list consists of unreflexive, reflexive and leased 431 transport locators of the Responder. The R1 packet also contains a 432 RELAY_TO parameter. The RELAY_TO parameter contains same information 433 as the RELAY_FROM parameter, i.e., Initiator transport locator, but 434 the type of the parameter is different. The RELAY_TO parameter is 435 not integrity protected by the signature of the R1 to allow pre- 436 created R1 packets at the Responder. 438 In step 4, the relay receives the R1 packet. The relay MUST drop the 439 packet if the source HIT belongs to an unregistered host. The relay 440 MAY verify the signature of the R1 packet and drop it when the 441 signature is invalid. Otherwise, the relay changes the destination 442 transport header to match RELAY_TO information, recalculates 443 transport checksum and forwards the packet. 445 In step 5, the Initiator receives the R1 packet and processes it 446 accordingly to [I-D.ietf-hip-base]. It replies with an I2 packet 447 that has the same transport locator as R1, but the source and 448 destination ports are swapped. The I2 contains a LOCATOR parameter 449 containing the listing unreflexive, reflexive and leased transport 450 locators of the Initiator 452 In step 6, the relay receives the I2 packet. The relay appends a 453 RELAY_FROM and a RELAY_HMAC to the I2 packet as in the second step. 455 In step 7, the Responder receives the I2 packet and processes it 456 according to [I-D.ietf-hip-base]. It replies with an R2 packet and 457 includes a RELAY_TO parameter as in step three. The RELAY_TO 458 parameter is protected by the HMAC. 460 In step 8, the relay processes the R2 as described in step four. The 461 relay forwards the packet to the Responder. 463 3.4. Base Exchange without a Relay 465 A host that has a publicly addressable, fixed IP address MAY exclude 466 registration to a Relay. As the Relay is not present, the host MUST 467 listen at HIPPORT for transport-encapsulated HIP and ESP packets. An 468 UDP-encapsulated base exchange with such an host does not have the 469 RELAY_TO and RELAY_FROM parameters present. Connectivity tests MUST 470 be handled as defined in the following section before any ESP traffic 471 is allowed. 473 3.5. Connectivity Tests 475 The base exchange is completed with an R2 packet. Then, the state of 476 the HIP associations at both peers is ESTABLISHED, but the peers MUST 477 NOT allow any ESP traffic until the connectivity tests described in 478 the next section are performed successfully. All of the locators, 479 except the relay address, are in UNVERIFIED state. In the 480 connectivity tests, the hosts test connectivity between different 481 locator pairs in order to find a working one. The connectivity tests 482 are illustrated in Figure 3. In this example, both hosts are behind 483 NATs. 485 I Relay R 486 | 2. R2(RELAY_TO) | 1. R2(RELAY_TO) | 487 +<------------------------------+-------------------------------+ 488 | | 489 | 3. UPDATE(ECHO_REQUEST,FROM_PEER) NAT-R:DROP| 490 +------------------------------------------------------------->X| 491 | | 492 | 4. UPDATE(ECHO_REQUEST,FROM_PEER) | 493 |<--------------------------------------------------------------+ 494 | | 495 | 5. UPDATE(ECHO_RESP,TO_PEER) | 496 +-------------------------------------------------------------->+ 497 | | 498 | 6. UPDATE(ECHO_REQUEST,FROM_PEER) | 499 +-------------------------------------------------------------->| 500 | | 501 | 7. UPDATE(ECHO_RESP,TO_PEER) | 502 |<--------------------------------------------------------------+ 503 | | 505 Figure 3: Connectivity tests 507 The connectivity tests are handled as the mobility extensions defined 508 in [I-D.ietf-hip-mm] and are therefore subject to the same processing 509 rules. The packets include ESP_INFO, SEQ, ACK, HMAC, SIGNATURE 510 parameters that are omitted in this section for simplicity. The 511 differences to the mobility extensions are described in this section. 513 In steps 1 and 2, the R2 packet is relayed from the Responder through 514 the Relay to the Responder. After this, both hosts start 515 connectivity tests using the return routability tests defined in 516 [I-D.ietf-hip-mm]. The return routability tests are used to probe 517 for connectivity between each locator pair obtained from the local 518 and peer locators obtained during base exchange. The return 519 routability tests are also used as a UDP hole punching mechanism. 520 The tests are carried in certain order which determined by the 521 priorization algorithm defined in the next section. 523 As an example, let's consider the case where hosts are testing each 524 others outermost NAT addresses, i.e., relay reflexive transport 525 locators. In step 3, host I sends an UPDATE message containing an 526 ECHO_REQUEST to the R. This will punch a hole the NAT of I, but the 527 NAT of R drops the message because the NAT of R has no state with I. 529 In step 4, R starts also reachability detection by sending an UPDATE 530 with ECHO_REQUEST. This traverses the NAT of I successfully because 531 Initiator had already punched an hole into its NAT in step 3. The 532 Responder replies using ECHO_RESPONSE in step 5. Upon receiving the 533 ECHO_RESPONSE, the Responder transitions the address pair to VERIFIED 534 state. 536 In step 6, host I starts a new return routability test either due to 537 a retransmission timer or as a reaction to UPDATE with ECHO_REQUEST 538 received from R. In step 7, host R receives and sends a response to 539 I. Upon receiving the response, host R transitions the locator pair 540 being tested to VERIFIED state. 542 All locators in UNVERIFIED state MUST be retransmitted RTIME times. 543 The retransmission packets MUST be paced Ta ms apart as defined in 544 [I-D.ietf-mmusic-ice]. The retransmission are ordered in a sequence 545 determined by the priority of the transport locator pairs, as 546 described in the next section. 548 The source address of the UPDATE messages containing ECHO_REQUEST 549 parameter is always an unreflexive IPv4 locator of the host. The 550 destination locator is the peer's unreflexive, reflexive or leased 551 transport locator, depending on which address is being tested for 552 reachability. Implementations may add RTT measurement information to 553 the ECHO_REQUEST parameter in addition to a nonce. 555 The UPDATE messages carrying ECHO_REQUEST include a FROM_PEER 556 parameter. The sender of the UPDATE MUST copy the source address of 557 the UPDATE to the FROM_PEER parameter. When the peer receives the 558 UPDATE, it responds with an UPDATE containing and a ECHO_REQUEST and 559 TO_PEER parameters. The TO_PEER parameter MUST contain the source 560 address of the UPDATE redundantly. The reason from the FROM_PEER and 561 TO_PEER parameters is that it is possible to learn new addresses 562 using them. When there is p2p-unfriendly NAT between the peers, it 563 may cause translate port number of the UPDATE packets to something 564 that has not been communicated through the relay before. Such an 565 addresses are called "peer reflexive transport locators" in this 566 document. The FROM_PEER and TO_PEER parameters can be used for 567 detecting peer reflexive locators. The learned locators are added to 568 the connectivity tests. 570 UPDATE packets destined to the unreflexive locators are sent directly 571 over IP. UPDATE packets destined for reflexive peer, relay and 572 leased locators are sent transport layer encapsulated. 574 Hosts proceed sequentially through the locator pairs in the order 575 described in the next section. A host MUST transition the state of 576 transport locator pairs verified by the return routability tests to 577 the ACTIVE state. Keepalive mechanisms described in later sections 578 MUST be applied to refresh the port state in NAT devices for locators 579 in the ACTIVE state. A host MUST also set up the Security 580 Associations for the inbound ESP traffic for such locators. The 581 selection of a default outbound SA is defined in the next section. 583 3.6. Selecting an Address Pair 585 This section describes priority ordering of connectivity tests and 586 locators pair selection based on ICE [I-D.ietf-mmusic-ice]. As part 587 of the priority calculation, each locator has a preference based on 588 its type. The values for these preferences are shown in Table 2. 590 +-----------------------------------+------------+ 591 | Locator Type | Preference | 592 +-----------------------------------+------------+ 593 | The preferred locator | 127 | 594 | Unreflexive locator | 126 | 595 | Peer reflexive transport locator | 120 | 596 | Relay reflexive transport locator | 100 | 597 | Leased transport locator | 0 | 598 +-----------------------------------+------------+ 600 Table 2: Locator Type Preferences 602 In addition to the "type" priority, the priority of a locator is also 603 affected by the "local" priority. A (multihoming) host may have 604 multiple locators of same type and SHOULD assign a unique local 605 priority for each locator. Hosts preferring IPv6 communication can 606 assign higher local preferences for IPv6 locators than for 607 unreflexive IPv4 locators. ECHO_REQUEST parameters may include RTT 608 calculation information that an implementation may use to increase 609 the local priority. A host SHOULD calculate locator priority based 610 on the local and type priorities as shown in Figure 4. The locator 611 priority MUST always be included in the type 3 locator fields in 612 LOCATOR parameters as described in section Section 4.4. 614 Locator priority = (2^24) * (type preference) + 615 (2^8) * (local preference) 617 Figure 4: Locator priority 619 A host SHOULD calculate a priority for each locator pair as shown in 620 Figure 5. I and R denote the priorities of locators of Initiator and 621 Responder. The use of the same formula at both ends gives more 622 guarantees that the peers prefer shortest paths between them. It 623 also converges the selection of the locator pair towards a symmetric 624 pair instead of an asymmetric pair even though it is not completely 625 guaranteed. The reasoning for the formula is described in 626 [I-D.ietf-mmusic-ice]. 628 Pair priority = 2^32 * MIN(I,R) + 2 * MAX(I,R) + (I > R ? 1 : 0) 630 Figure 5: Pair priority 632 After reachability tests, both hosts SHOULD assign the transport 633 address pair with the highest pair priority as their default outgoing 634 SA for ESP. 636 3.7. Mobility 638 When one of the hosts changes its locators, it has to notify its 639 peers of the address change. This is handled as described in the 640 connectivity tests in Section 3.5 with the exception that the UPDATE 641 with parameter LOCATOR is used as the trigger to start connectivity 642 tests instead of the R2. The UPDATE packet contains a LOCATOR 643 parameter listing unreflexive, reflexive and leased transport 644 locators of the Initiator. This is illustrated in Figure 6. 646 Mobile Relay Corresponding 647 Node | Node 648 | | | 649 | 1. UPDATE(LOCATOR) | 2. UPDATE(LOCATOR,RELAY_TO) | 650 +-------------------------------+------------------------------>| 651 | | 652 | 3. UPDATE(ECHO_REQUEST,FROM_PEER) NAT: DROP| 653 +------------------------------------------------------------->X| 654 | | 655 | 4. UPDATE(ECHO_REQUEST,FROM_PEER) | 656 |<--------------------------------------------------------------+ 657 | | 658 | 5. UPDATE(ECHO_RESP,TO_PEER) | 659 |-------------------------------------------------------------->| 660 | | 661 | 6. UPDATE(ECHO_REQUEST,FROM_PEER) | 662 |<--------------------------------------------------------------| 663 | | 664 | 7. UPDATE(ECHO_RESP,TO_PEER) | 665 |-------------------------------------------------------------->| 666 | | 668 Figure 6: Handover 670 When a mobile host moves from a private address realm to another, it 671 can obtain the same locator on both networks. To denote that the new 672 locator requires reachability detection, the mobile host MUST use a 673 new SPI for the new locator. 675 A host can also use the UPDATE mechanism can also be used for 676 switching to a more optimal path after connectivity tests. In the 677 connectivity tests, the host may implement RTT measurements within 678 ECHO_REQUEST and ECHO_RESPONSE messages. In some cases the result of 679 the RTT measurements may indicate that another locator pair is more 680 optimal than the locator pair resulting from the connectivity and 681 priority tests. In such a case, the host MAY send UPDATE with 682 LOCATOR parameter with the optimal locator with the preferred bit on. 683 This gives the highest priority for the most optimal locator and will 684 be used if the connectivity tests succeed. 686 3.8. NAT Keepalives 688 A NAT can delete the mapping state after a timeout when there is no 689 traffic refreshing the state. For this reason, both hosts MUST send 690 keep-alives to each other for all locators pairs that are in the 691 ACTIVE state. Keepalives MUST be sent every 20 seconds for UDP. The 692 keepalive is a NOTIFY packet without parameters. 694 The keep-alives MAY also be used to implement failure detection 695 between end-hosts as in [I-D.oliva-hiprg-reap4hip] (XX FIXME: this 696 needs still more details). The basic idea is to keep track of HIP 697 control and ESP packets received over a transport port. When there 698 is no HIP or ESP traffic (not even keep-alives) arriving during a 699 certain time period, the host switches to an alternative locator 700 pair. The host transitions the default locator pair to the 701 UNVERIFIED state and replaces the currently default SA to correspond 702 to the ACTIVE locator pair with the highest priority. The host may 703 also try to send an UPDATE packet with the LOCATOR parameter after a 704 certain time period if connectivity is still broken. 706 End-host may also used the keep-alives to detect loss of connectivity 707 with relay server. When this occurs, the end-host can register to a 708 new relay and replace the IP address of the old relay server with a 709 new one in DNS or DHT. 711 3.9. Closing of HIP Associations 713 A host closes a HIP association as described in [I-D.ietf-hip-base] 714 except that the CLOSE and CLOSE_ACK packets are sent over transport 715 layer and through the relay as illustrated in Figure 7. Hosts MUST 716 transition the corresponding locator pairs to the DEPRECATED state 717 after a successful CLOSE-CLOSE_ACK exchange. The corresponding 718 inbound and outbound SAs must be deleted on such occasion. 720 I Relay R 721 | 1. CLOSE | | 722 +---------------------------->| 2. CLOSE | 723 | +-------------------------------->| 724 | | | 725 | | 3. CLOSE_ACK | 726 | 4. CLOSE_ACK |<--------------------------------+ 727 |<----------------------------+ | 728 | | | 730 Figure 7: Closing of a HIP association 732 The hosts may also use the CLOSE mechanism to remove redundant SAs 733 remaining from the connectivity tests. However, the removal can 734 prolong the recovery in the event of connectivity failures. 736 3.10. Communication with HIP Hosts without NAT Traversal Support 738 The UDP encapsulation of HIP and ESP control packets has not been 739 defined in any other IETF document and legacy hosts drop all UDP 740 encapsulated HIP and ESP traffic. Processing of unknown locator 741 types terminates the base exchange or UPDATE. As such, the 742 extensions defined in this document are not completely backwards 743 compatible and require a minimal support in implementations. 745 A minimal implementation MUST provide UDP encapsulation of HIP and 746 ESP packets. In such a case, the minimal NAT traversal 747 implementation MUST silently discard the processing of type 3 748 locators to allow communication with implementations supporting NAT 749 traversal defined in this document. The minimal implementation MUST 750 support UDP keepalives to refresh state of the NAT(s). 752 Hosts that conform to [I-D.ietf-hip-mm] respond to UPDATE messages 753 containing an ECHO_REQUEST with an UPDATE message containing an 754 ECHO_RESPONSE. This completes the connectivity tests for the host 755 supporting the extensions defined in this document. As long as the 756 implementation supports UDP encapsulation of HIP control packets, 757 this requires no changes. 759 The Relay extensions defined in this document do not work with 760 minimalistic implementations. When there is a Relay between the 761 hosts, both the Initiator and Responder MUST support the extensions 762 defined in this document. The presence of RELAY_TO and RELAY_FROM 763 parameters denotes the precence of a relay. 765 4. Packet Formats 767 This section defines an UDP-encapsulation packet format for HIP base 768 exchange and control traffic, IPsec ESP BEET-mode traffic and NAT 769 keep-alive packets. 771 4.1. HIP Control Packets 773 0 1 2 3 774 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 775 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 776 | Source Port | Destination Port | 777 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 778 | Length | Checksum | 779 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 780 | | 781 ~ HIP Header and Parameters ~ 782 | | 783 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 785 Figure 8: Format for UDP-encapsulated HIP control packets 787 Figure 8 shows how HIP control packets are encapsulated within UDP. 788 A minimal UDP packet carries a complete HIP packet in its payload. 790 Contents of the UDP source and destination ports are described below. 791 The UDP length and checksum field MUST be computed as described in 792 [RFC0768]. The HIP header and parameter follow the conventions 793 [I-D.ietf-hip-base] with the exception that the HIP header checksum 794 MUST be zero. The HIP header checksum is zero for two reasons. 795 First, the UDP header contains already a checksum. Second, the 796 checksum definition in [I-D.ietf-hip-base] includes the IP addresses 797 in the checksum calculation. The NATs unaware of HIP cannot 798 recompute the HIP checksum after changing IP addresses. 800 4.2. Control Channel Keep-Alives 802 The keep-alive for control channel are UDP encapsulated NOTIFY 803 packets [I-D.ietf-hip-base]. The NOTIFY packets MAY contain HIP 804 parameters. The NAT traversal mechanisms encapsulate these NOTIFY 805 packets within the payload of UDP packets. 807 4.3. RELAY_FROM, RELAY_TO and RELAY_VIA Parameters 809 0 1 2 3 810 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 811 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 812 | Type | Length | 813 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 814 | | 815 | Address | 816 | | 817 | | 818 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 819 | Port | Padding | 820 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 822 Type [ TBD by IANA: 823 RELAY_FROM: (63998 = 2^16 - 2^11 + 2^9 - 2) 824 RELAY_TO: (64002 = 2^16 - 2^11 + 2^9 + 2) 825 RELAY_VIA: (64006 = 2^16 - 2^11 + 2^9 + 6) ] 826 830 Length 18 831 Address An IPv6 address or an IPv4 address in IPv4-in-IPv6 832 format. 833 Port Transport port number 835 Figure 9: Format for the RELAY_FROM, RELAY_TO and RELAY_VIA 836 parameters 838 Figure 9 shows the format of RELAY_FROM, RELAY_TO and RELAY_VIA 839 parameters. 841 4.4. LOCATOR Parameter 843 The generic LOCATOR parameter format is the same as in 844 [I-D.ietf-hip-mm]. However, presenting transport locators requires a 845 new locator type. The generic and NAT specific locator parameters 846 are illustrated in Figure 10. 848 0 1 2 3 849 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 850 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 851 | Type | Length | 852 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 853 | Traffic Type | Locator Type | Locator Length | Reserved |P| 854 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 855 | Locator Lifetime | 856 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 857 | Locator | 858 | | 859 | | 860 | | 861 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 862 . . 863 . . 864 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 865 | Traffic Type | Loc Type = 2 | Locator Length | Reserved |P| 866 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 867 | Locator Lifetime | 868 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 869 | Transport Port | Transp. Proto | Kind | 870 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 871 | Priority | 872 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 873 | SPI | 874 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 875 | Locator | 876 | | 877 | | 878 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 880 Figure 10: Locator parameter 882 The individual fields in the LOCATOR parameter are described in 883 Table 3. 885 +------------+----------+-------------------------------------------+ 886 | Field | Value(s) | Purpose | 887 +------------+----------+-------------------------------------------+ 888 | Type | 193 | Parameter type | 889 | Length | Variable | Length in octets, excluding Type and | 890 | | | Length fields, and excluding padding. | 891 | Traffic | 0-2 | 2 for unreflexive and leased, 1 for relay | 892 | Type | | reflexive | 893 | Locator | 3 | Transport locator | 894 | Type | | | 895 | Locator | 19 | Length of the Locator field in 4-octet | 896 | Length | | units | 897 | Reserved | 0 | Reserved for future extensions | 898 | Preferred | 0 | Usually zero for type 3 locators | 899 | (P) bit | | | 900 | Locator | Variable | Locator lifetime in seconds | 901 | Lifetime | | | 902 | Transport | Variable | Zero for unreflexive and greater than | 903 | Port | | zero otherwise | 904 | Transport | 0 | Zero for UDP | 905 | Protocol | | | 906 | Kind | Variable | 0 for unreflexive, 1 for relay reflexive, | 907 | | | 2 for leased | 908 | Priority | Variable | Locator preference, see Section 3.6 | 909 | SPI | Variable | 0 for relay reflexive, otherwise greater | 910 | | | than zero | 911 | Locator | Variable | An IPv6 address or an IPv4-in-IPv6 format | 912 | | | IPv4 address[RFC2373] | 913 +------------+----------+-------------------------------------------+ 915 Table 3: Fields of the locator parameter 917 4.5. RELAY_HMAC 919 The RELAY_HMAC parameter value has the TLV type 65520 (2^16 - 2^5 + 920 2^4). It has the same semantics as RVS_HMAC [I-D.ietf-hip-rvs]. 922 4.6. Registration Types 924 The REG_INFO, REQ_REQ, REG_RESP and REG_FAILED parameters contains 925 values for relay registration. The value for RELAY_UDP_HIP is 2. 926 The value for RELAY_UDP_ESP is 3. 928 4.7. ESP Data Packets 930 0 1 2 3 931 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 932 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 933 | Source Port | Destination Port | 934 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 935 | Length | Checksum | 936 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 937 | | 938 ~ ESP Header ~ 939 | | 940 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 942 Figure 11: Format for UDP-encapsulated IPsec ESP BEET-mode traffic 944 Figure 11 shows how IPsec ESP BEET-mode packets are encapsulated 945 within UDP. Again, a minimal UDP packet carries the ESP packet in 946 its payload. The contents of the UDP source and destination ports 947 are described in later sections. The UDP length and checksum field 948 MUST be computed as described in [RFC0768]. 950 4.8. UDP Encapsulation/Decapsulation of IPsec BEET-Mode ESP 952 [RFC3948] describes UDP encapsulation of the IPsec ESP transport and 953 tunnel mode. This section describes the UDP encapsulation of the 954 BEET mode. 956 4.8.1. UDP Encapsulation of IPsec BEET-Mode ESP 958 During the HIP base exchange, the two peers exchange parameters that 959 enable them to define a pair of IPsec ESP security associations 960 (SAs), as described in [I-D.ietf-hip-esp]. When two peers perform a 961 UDP-encapsulated base exchange, they MUST define a pair of IPsec SAs 962 that produces UDP-encapsulated BEET-mode ESP data traffic. 964 The management of encryption/authentication protocols and security 965 parameter indices (SPIs) is defined in [I-D.ietf-hip-esp]. 966 Additional SA parameters, such as IP addresses and UDP ports, MUST be 967 defined according to this section. Two SAs MUST be defined on each 968 host for one HIP association; one for outgoing data and another one 969 for incoming data. 971 The BEET mode provides limited tunnel mode semantics without the 972 regular tunnel mode overhead [I-D.nikander-esp-beet-mode]. In the 973 BEET mode, transport-layer checksums in the payload data are based on 974 the HITs. The packet MUST then undergo BEET-mode ESP cryptographic 975 processing as defined in Section 5.3 of [I-D.nikander-esp-beet-mode]. 977 Next, the resulting BEET-mode packet is UDP encapsulated. For this 978 purpose, a UDP header MUST be inserted between the IP and ESP header. 979 The source and destination ports are filled in. The UDP checksum 980 MUST be calculated based on the outer addresses (locators) of the 981 IPsec security association. The other fields of the UDP header are 982 computed as described in [RFC0768]. 984 The resulting UDP packet MUST then undergo BEET IP header processing 985 as defined in Section 5.4 of [I-D.nikander-esp-beet-mode]. 987 Figure 12 illustrates the BEET-mode UDP encapsulation procedure for a 988 TCP packet. 990 ORIGINAL TCP PACKET: 991 +------------------------------------------+ 992 | inner IPv6 hdr | ext hdrs | | | 993 | with HITs | if present | TCP | Data | 994 +------------------------------------------+ 996 PACKET AFTER BEET-MODE ESP PROCESSING: 997 +----------------------------------------------------------+ 998 | inner IPv6 hdr | ESP | dest | | | ESP | ESP | 999 | with HITs | hdr | opts.| TCP | Data | Trailer | ICV | 1000 +----------------------------------------------------------+ 1001 |<------- encryption -------->| 1002 |<----------- integrity ----------->| 1004 FINAL PACKET AFTER BEET_MODE IP HEADER PROCESSING: 1005 +------------------------------------------------------------+ 1006 | outer IPv4 | UDP | ESP | dest | | | ESP | ESP | 1007 | hdr | hdr | hdr | opts.| TCP | Data | Trailer | ICV | 1008 +------------------------------------------------------------+ 1009 |<------- encryption -------->| 1010 |<----------- integrity ----------->| 1012 Figure 12: UDP encapsulation of an IPsec BEET-mode ESP packet 1013 containing a TCP segment 1015 4.8.2. UDP Decapsulation of IPsec BEET-Mode ESP 1017 An incoming UDP-encapsulated IPsec BEET-mode ESP packet is 1018 decapsulated as follows. First, if the UDP checksum is invalid, then 1019 the packet MUST be dropped. Then, the packet MUST be verified as 1020 defined in [I-D.nikander-esp-beet-mode]. If verified, the ESP data 1021 contained in the payload of the UDP packet MUST be decrypted as 1022 described in [I-D.nikander-esp-beet-mode]. 1024 5. Firewall Traversal 1026 This section describes firewall traversal issues separately from NAT 1027 issues. When the Initiator or the Responder of a HIP association is 1028 behind a firewall, additional issues arise. 1030 The NAT traversal mechanisms described in Section 3 require that the 1031 firewall - stateful or not - allows UDP traffic. At the minimum, 1032 successful firewall control packet traversal requires that the host 1033 behind the firewall is allowed to communicate packets with a HIP 1034 relay (or a Responder without Relay) that is listening on UDP port 1035 HIPPORT. Successful ESP data packet traversal requires the same for 1036 the ESP relay. For unrelayed traffic, the destination port HIPPORT 1037 should be open at the firewall to all hosts behind the firewall. 1039 Most firewall implementations support "UDP connection tracking", 1040 i.e., after a host behind a firewall has initiated UDP communication 1041 to the public Internet, the firewall relays UDP response traffic in 1042 the return direction. If no such return traffic arrives for a 1043 specific period of time, the firewall stops relaying the given IP 1044 address and port pair. The mechanisms described in Section 3 already 1045 enable traversal of such firewalls, if the keep-alive interval used 1046 is less than the refresh interval of the firewall. 1048 When the Initiator is behind a firewall, the NAT traversal mechanisms 1049 described in Section 3 depend on the ability to initiate 1050 communication via UDP to the destination port HIPPORT from arbitrary 1051 source ports and to receive UDP response traffic from that port to 1052 the chosen source port. If the Initiator is behind a firewall that 1053 does not support "UDP connection tracking", the NAT traversal 1054 mechanisms described in Section 3 can still be supported, if the 1055 firewall allows permanently inbound UDP traffic from the port HIPPORT 1056 and destined to arbitrary source IP addresses and UDP ports. 1058 When the Responder is behind a firewall, the NAT traversal mechanisms 1059 described in Section 3 depend on the ability to send and receive UDP 1060 traffic originating from HIPPORT of the HIP and ESP relays. When 1061 unrelayed traffic is preferred, arbitrary source IP addresses and 1062 ports are required. 1064 6. Security Considerations 1066 6.1. A Difference to RFC3948 1068 Section 5.1 of [RFC3948] describes a security issue for the UDP 1069 encapsulation in the standard IP tunnel mode when two hosts behind 1070 different NATs have the same private IP address and initiate 1071 communication to the same Responder in the public Internet. The 1072 Responder cannot distinguish between two hosts, because security 1073 associations are based on the same inner IP addresses. 1075 This issue does not exist with the UDP encapsulation of IPsec BEET 1076 mode as described in Section 3, because the Responder use HITs to 1077 distinguish between different communication instances. 1079 6.2. Privacy Considerations 1081 The LOCATORs are sent in plain text. Alternatively, they could be 1082 encrypted. This option was not chosen to allow packet inspection by 1083 middleboxes. Plain text locators may be useful for HIP-aware 1084 middleboxes in the future. 1086 It is possible that an Initiator or Responder may not want to reveal 1087 all of its locators to its peer. For example, a host may not want to 1088 reveal the internal topology of the private address realm and it 1089 discards unreflexive locators. Such behavior creates non-optimal 1090 paths when the hosts are located behind the same NAT. Especially, 1091 this could be a problem with a legacy NAT that does not support 1092 routing from the private address realm back to itself through the 1093 outer address of the NAT. This scenario is referred to as the 1094 hairpin problem [I-D.ietf-behave-p2p-state]. With such a legacy NAT, 1095 the only option left would be to use a leased transport locator from 1096 a relay. As a consequence, a host may support locator-based privacy 1097 by leaving out the reflexive locators. Using only unreflexive 1098 locators can produce suboptimal paths possibly causing congestion. 1100 The use of relays can be useful for protection against Denial-of- 1101 Service attacks. If a Responder reveals only its HIP and ESP relay 1102 addresses to malign Initiators, the Initiators can only attack the 1103 relays that does not prevent the Responder from initiating new 1104 outgoing connections if a path around the relay exists. 1106 6.3. Opportunistic Mode 1108 The use of opportunistic HIP is NOT RECOMMENDED and its use is not 1109 defined in this document. In opportunistic HIP, the Initiator sends 1110 the I1 message with null destination HIT. Private address realms do 1111 not have unique addresses by definition. Therefore, opportunistic 1112 mode is subject to failure even when there are no attackers present. 1113 In a normal HIP base exchange, a well-behaving Responder drops the I1 1114 packet when the destination HIT does not belong to it. An attacker 1115 could respond to the I1, but the base exchange would eventually fail 1116 as the attacker would fail to prove its ownership of the destination 1117 HIT of the I1. 1119 7. IANA Considerations 1121 This section is to be interpreted according to [RFC2434]. 1123 This draft currently uses a UDP port in the "Dynamic and/or Private 1124 Port" and HIPPORT. Upon publication of this document, IANA is 1125 requested to register a UDP port and the RFC editor is requested to 1126 change all occurrences of port HIPPORT to the port IANA has 1127 registered. The HIPPORT number 50500 should be used for initial 1128 experimentation. 1130 This document updates the IANA Registry for HIP Parameters Types by 1131 assigning new HIP Parameter Types values for the new HIP Parameters 1132 defined in Section 4: o RELAY_FROM (defined in Section 4.3) o 1133 RELAY_TO (defined in Section 4.3) o RELAY_VIA (defined in Section 1134 4.3) o RELAY_HMAC (defined in Section 4.5) 1136 8. Acknowlegements 1138 The authors would like to thank Lars Eggert, Vivien Schmitt, Abhinav 1139 Pathak and Andrei Gurtov for their contributions to previous versions 1140 of this draft. Thanks for Philip Matthews on introducing ICE 1141 concepts to the authors and for proposing the initial design. Thanks 1142 for Jonathan Rosenberg and the rest of the MMUSIC WG folks for the 1143 excellent work on ICE. In addition, the authors would like to thank 1144 Tobias Heer, Teemu Koponen, Juhana Mattila, Jeffrey M. Ahrenholz, 1145 Thomas Henderson, Kristian Slavov, Janne Lindqvist, Pekka Nikander, 1146 Lauri Silvennoinen, Jukka Ylitalo, Juha Heinanen, Joakim Koskela, 1147 Samu Varjonen, Dan Wing, Hannes Tschofenig and Jani Hautakorpi for 1148 their comments on this document. 1150 [I-D.nikander-hip-path] presented some initial ideas for NAT 1151 traversal of HIP communication. The idea was based on NAT detection 1152 using extra parameters in the base exchange. This document takes a 1153 different approach based on ICE. 1155 Simon Schuetz and Martin Stiemerling are partly funded by Ambient 1156 Networks, a research project supported by the European Commission 1157 under its Sixth Framework Program. The views and conclusions 1158 contained herein are those of the authors and should not be 1159 interpreted as necessarily representing the official policies or 1160 endorsements, either expressed or implied, of the Ambient Networks 1161 project or the European Commission. 1163 Miika Komu is working in the Networking Research group at Helsinki 1164 Institute for Information Technology (HIIT). The InfraHIP project 1165 was funded by Tekes, Telia-Sonera, Elisa, Nokia, the Finnish Defence 1166 Forces and Ericsson. Miika Komu wrote draft-ietf-hip-nat-02 version 1167 from scratch based on ICE-related comments from Philip Matthews. 1169 9. References 1171 9.1. Normative References 1173 [I-D.ietf-hip-base] 1174 Moskowitz, R., "Host Identity Protocol", 1175 draft-ietf-hip-base-08 (work in progress), June 2007. 1177 [I-D.ietf-hip-esp] 1178 Jokela, P., "Using ESP transport format with HIP", 1179 draft-ietf-hip-esp-06 (work in progress), June 2007. 1181 [I-D.ietf-hip-mm] 1182 Henderson, T., "End-Host Mobility and Multihoming with the 1183 Host Identity Protocol", draft-ietf-hip-mm-05 (work in 1184 progress), March 2007. 1186 [I-D.ietf-hip-registration] 1187 Laganier, J., "Host Identity Protocol (HIP) Registration 1188 Extension", draft-ietf-hip-registration-02 (work in 1189 progress), June 2006. 1191 [I-D.ietf-hip-rvs] 1192 Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) 1193 Rendezvous Extension", draft-ietf-hip-rvs-05 (work in 1194 progress), June 2006. 1196 [I-D.ietf-mmusic-ice] 1197 Rosenberg, J., "Interactive Connectivity Establishment 1198 (ICE): A Protocol for Network Address Translator (NAT) 1199 Traversal for Offer/Answer Protocols", 1200 draft-ietf-mmusic-ice-16 (work in progress), June 2007. 1202 [I-D.nikander-esp-beet-mode] 1203 Melen, J. and P. Nikander, "A Bound End-to-End Tunnel 1204 (BEET) mode for ESP", draft-nikander-esp-beet-mode-07 1205 (work in progress), February 2007. 1207 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 1208 August 1980. 1210 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1211 Requirement Levels", BCP 14, RFC 2119, March 1997. 1213 [RFC2373] Hinden, R. and S. Deering, "IP Version 6 Addressing 1214 Architecture", RFC 2373, July 1998. 1216 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1217 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 1218 October 1998. 1220 [RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol 1221 (HIP) Architecture", RFC 4423, May 2006. 1223 9.2. Informative References 1225 [I-D.ietf-behave-p2p-state] 1226 Srisuresh, P., "State of Peer-to-Peer(P2P) Communication 1227 Across Network Address Translators(NATs)", 1228 draft-ietf-behave-p2p-state-03 (work in progress), 1229 July 2007. 1231 [I-D.irtf-hiprg-nat] 1232 Stiemerling, M., "NAT and Firewall Traversal Issues of 1233 Host Identity Protocol (HIP) Communication", 1234 draft-irtf-hiprg-nat-04 (work in progress), March 2007. 1236 [I-D.nikander-hip-path] 1237 Nikander, P., "Preferred Alternatives for Tunnelling HIP 1238 (PATH)", draft-nikander-hip-path-01 (work in progress), 1239 March 2006. 1241 [I-D.oliva-hiprg-reap4hip] 1242 Oliva, A. and M. Bagnulo, "Fault tolerance configurations 1243 for HIP multihoming", draft-oliva-hiprg-reap4hip-00 (work 1244 in progress), July 2007. 1246 [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address 1247 Translator (NAT) Terminology and Considerations", 1248 RFC 2663, August 1999. 1250 [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. 1251 Stenberg, "UDP Encapsulation of IPsec ESP Packets", 1252 RFC 3948, January 2005. 1254 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 1255 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 1256 RFC 4787, January 2007. 1258 Appendix A. Differences to ICE 1260 The protocol extensions defined in this draft are based on ICE. The 1261 extensions are a rough translation of ICE concepts to HIP protocol. 1262 The translation preserved certain concepts as they are, but there are 1263 subtle differences. This section tries to explain how ICE concepts 1264 were mapped to HIP protocol and what are the differences. 1266 The terminology for this draft is a hybrid of ICE and HIP 1267 terminology. "Agent" was translated to "host" in favour of HIP 1268 terminology. Transport address was changed to transport locator. 1269 Similarly, address pair is denoted as locator pair. This document 1270 does not really talk about "candidate addresses", but just "locators" 1271 which may or may not be verified using the return routability tests, 1272 in favour of mobility terminology in [I-D.ietf-hip-mm]. Host 1273 candidate of ICE became unreflexive locator, server reflexive 1274 candidate was mapped to relay reflexive transport locator, peer 1275 reflexive candidate was mapped to peer reflexive locator and relayed 1276 candidate became leased transport locator. 1278 The component, base and foundation terms are not used in the document 1279 as there is only a single "media stream" for all (ESP) traffic 1280 between two hosts. 1282 There is no "lite" version ICE in this document, just full, as the 1283 full version is the preferred one also for ICE. One specific 1284 scenario defined in this document has some resemblance to the lite 1285 ICE. When a Responder is a publicly accessible server with fixed 1286 address, it may exclude the use of the relay. In that case, it does 1287 not have to handle the RELAY parameters but still has to respond to 1288 the connectivity checks. 1290 A connectivity check is not a STUN Binding Request. Instead, it is 1291 return routability check as defined in [I-D.ietf-hip-mm]. "Triggered 1292 check" occurs when a host receives a UPDATE with ECHO_REQUEST and it 1293 responds using a ECHO_RESPONSE and sends its own ECHO_REQUEST. A 1294 "check list" is effectively a LOCATOR parameter as defined in 1295 [I-D.ietf-hip-mm]. The term "ordinary check" is not really used in 1296 this document as it HIP packets are retransmitted periodically when 1297 the LOCATORs are in UNVERIFIED state. "Valid list" corresponds to 1298 locator pairs that have been verified successfully by the return 1299 routability tests. 1301 The peers trigger the connectivity checks after the base exchange or 1302 after a base exchange. The conclusion of the connectivity checks, 1303 i.e., selection of the final address pair, differs the most as a 1304 result of fitting the ICE nomination algorithm to HIP mobility 1305 mechanisms. There is no "controlling agent" and the end-hosts make a 1306 local decision on which locator pair to choose. This could lead to 1307 asymmetric address pairs, but the priority algorithm guarantees that 1308 the address pairs converge. Also, there is are no aggressive and 1309 regular nomination modes as a consequence of the lack of controlling 1310 agent. 1312 ICE uses TLS, usernames and passwords as security mechanisms. HIP 1313 has built-in security mechanisms that preferred over the ones that 1314 are used in ICE. 1316 Appendix B. Document Revision History 1318 To be removed upon publication 1320 +------------+------------------------------------------------------+ 1321 | Revision | Comments | 1322 +------------+------------------------------------------------------+ 1323 | schmitt-00 | Initial version. | 1324 | ietf-00 | Officially adopted as WG item. Solved issues | 1325 | | 1-9,11,12 | 1326 | ietf-01 | Solved remaining issues except that relaying ESP and | 1327 | | mobility were still incomplete. | 1328 | ietf-02 | Miika rewrote almost from scratch based on ICE. | 1329 | | Editorial corrections from Simon and Andrei. | 1330 +------------+------------------------------------------------------+ 1332 Authors' Addresses 1334 Miika Komu (editor) 1335 Helsinki Institute for Information Technology 1336 Metsanneidonkuja 4 1337 Espoo 1338 Finland 1340 Phone: +358503841531 1341 Fax: +35896949768 1342 Email: miika@iki.fi 1343 URI: http://www.hiit.fi/ 1344 Simon Schuetz 1345 NEC Network Laboratories 1346 Kurfuerstenanlage 36 1347 Heidelberg 69115 1348 Germany 1350 Phone: +49 6221 4342 165 1351 Fax: +49 6221 4342 155 1352 Email: simon.schuetz@netlab.nec.de 1353 URI: http://www.netlab.nec.de/ 1355 Martin Stiemerling 1356 NEC Network Laboratories 1357 Kurfuerstenanlage 36 1358 Heidelberg 69115 1359 Germany 1361 Phone: +49 6221 4342 113 1362 Fax: +49 6221 4342 155 1363 Email: stiemerling@netlab.nec.de 1364 URI: http://www.netlab.nec.de/ 1366 Full Copyright Statement 1368 Copyright (C) The IETF Trust (2007). 1370 This document is subject to the rights, licenses and restrictions 1371 contained in BCP 78, and except as set forth therein, the authors 1372 retain all their rights. 1374 This document and the information contained herein are provided on an 1375 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1376 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1377 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1378 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1379 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1380 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1382 Intellectual Property 1384 The IETF takes no position regarding the validity or scope of any 1385 Intellectual Property Rights or other rights that might be claimed to 1386 pertain to the implementation or use of the technology described in 1387 this document or the extent to which any license under such rights 1388 might or might not be available; nor does it represent that it has 1389 made any independent effort to identify any such rights. Information 1390 on the procedures with respect to rights in RFC documents can be 1391 found in BCP 78 and BCP 79. 1393 Copies of IPR disclosures made to the IETF Secretariat and any 1394 assurances of licenses to be made available, or the result of an 1395 attempt made to obtain a general license or permission for the use of 1396 such proprietary rights by implementers or users of this 1397 specification can be obtained from the IETF on-line IPR repository at 1398 http://www.ietf.org/ipr. 1400 The IETF invites any interested party to bring to its attention any 1401 copyrights, patents or patent applications, or other proprietary 1402 rights that may cover technology that may be required to implement 1403 this standard. Please address the information to the IETF at 1404 ietf-ipr@ietf.org. 1406 Acknowledgment 1408 Funding for the RFC Editor function is provided by the IETF 1409 Administrative Support Activity (IASA).