idnits 2.17.1 draft-ietf-hip-nat-traversal-04.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 1166. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1177. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1184. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1190. 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 == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: In step 2, the Relay Server (Responder) lists the services that it supports in the R1 packet. The support for HIP-over-UDP relaying is denoted by the RELAY_UDP_HIP value. The R1 SHOULD not contain any NAT transform parameter. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: The NAT transform parameter applies to a base exchange between end-hosts, but currently does not apply to with a registration with a HIP Relay server. The NAT transform applies only to a base exchange with transport layer encapsulation and MUST not be included without transport layer encapsulation. The NAT transform negotiation in base exchange is illustrated in Figure 2. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: The Responder completes the base exchange with the R2 packet through the Relay. When Initiator successfully receives and processes the R2, both hosts have transitioned to ESTABLISHED state. However, the destination address the Initiator and Responder used for delivering base exchange packets belonged to the Relay as indicated by the RELAY_FROM and RELAY_TO parameters. Therefore, the address of the Relay MUST not be used for sending ESP traffic unless it was listed as a TURN server in the offer/answer. Instead, the Initiator and Responder MUST start ICE connectivity tests after they have transitioned to ESTABLISHED state after the base exchange when they do not have valid locator pair for ESP traffic and the NAT transform parameter was negotiated successfully. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: To prevent NAT state from expiring, communicating end-hosts hosts send periodically keepalives to each other. NAT Relays MUST not send any keepalives. An end-host MUST send keepalives every 15 seconds to refresh the UDP port mapping at the NAT(s) when the control or data channel is idle. To implement failure tolerance, an end-host SHOULD have shorter keepalive period. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: The keepalives are STUN Binding Indications if the hosts have agreed on NAT_TRANSFORM during the base exchange, or HIP NOTIFY messages otherwise. A HIP Relay MUST not forward NOTIFY messages. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: The communicating hosts MUST send keepalives to each other using the transport locators exchanged in the base exchange when they are in ESTABLISHED state. Also, the Initiator MUST send a NOTIFY message to the Relay to refresh the NAT state alive on the path between the Initiator and Relay when the Initiator has not received any response to its I1 or I2 from the Responder in 15 seconds. The Relay MUST not forward the NOTIFY messages. -- 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 15, 2008) is 5761 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-18) exists of draft-ietf-behave-rfc3489bis-16 == Outdated reference: A later version (-16) exists of draft-ietf-behave-turn-08 == Outdated reference: A later version (-01) exists of draft-rosenberg-mmusic-ice-nonsip-00 ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 3513 (Obsoleted by RFC 4291) ** Obsolete normative reference: RFC 4013 (Obsoleted by RFC 7613) ** 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) == Outdated reference: A later version (-04) exists of draft-heer-hip-middle-auth-01 Summary: 10 errors (**), 0 flaws (~~), 11 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: January 16, 2009 The Boeing Company 6 P. Matthews 7 (Unaffiliated) 8 H. Tschofenig 9 Nokia Siemens Networks 10 A. Keraenen, Ed. 11 Ericsson Research Nomadiclab 12 July 15, 2008 14 Basic HIP Extensions for Traversal of Network Address Translators 15 draft-ietf-hip-nat-traversal-04.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 January 16, 2009. 42 Abstract 44 The Host Identity Protocol (HIP) provides a new namespace that can be 45 used for uniquely identifying hosts. Existing HIP experimental 46 specifications do not specify protocol operations across Network 47 Address Translators (NATs). 49 This document specifies basic NAT traversal extensions for HIP. The 50 HIP shim layer is located between the network and transport layer, 51 the extensions can also provide a more general-purpose NAT traversal 52 support for higher-layer networking applications. The extensions are 53 based on the use of the The Interactive Connectivity Establishment 54 (ICE) methodology to discover a working path between two end-hosts. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 3. Protocol Description . . . . . . . . . . . . . . . . . . . . . 6 61 3.1. Relay Registration . . . . . . . . . . . . . . . . . . . . 6 62 3.2. NAT Transformation Negotiation . . . . . . . . . . . . . . 8 63 3.3. Base Exchange via HIP Relay . . . . . . . . . . . . . . . 9 64 3.4. ICE Connectivity Checks . . . . . . . . . . . . . . . . . 11 65 3.5. NAT Keepalives . . . . . . . . . . . . . . . . . . . . . . 12 66 3.6. Base Exchange without ICE Connectivity Checks . . . . . . 12 67 3.7. Base Exchange without UDP Encapsulation . . . . . . . . . 13 68 3.8. Sending Control Messages using the Data Plane . . . . . . 13 69 4. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . . 13 70 4.1. HIP Control Packets . . . . . . . . . . . . . . . . . . . 14 71 4.2. Connectivity Checks . . . . . . . . . . . . . . . . . . . 14 72 4.3. Keepalives . . . . . . . . . . . . . . . . . . . . . . . . 15 73 4.4. Relay and Registration Parameters . . . . . . . . . . . . 16 74 4.5. LOCATOR Parameter . . . . . . . . . . . . . . . . . . . . 17 75 4.6. RELAY_HMAC . . . . . . . . . . . . . . . . . . . . . . . . 19 76 4.7. Registration Types . . . . . . . . . . . . . . . . . . . . 19 77 4.8. ESP Data Packets . . . . . . . . . . . . . . . . . . . . . 20 78 5. Security Considerations . . . . . . . . . . . . . . . . . . . 20 79 5.1. Privacy Considerations . . . . . . . . . . . . . . . . . . 20 80 5.2. Opportunistic Mode . . . . . . . . . . . . . . . . . . . . 21 81 5.3. Base Exchange Replay Protection for HIP Relay Server . . . 21 82 5.4. Demuxing Different HIP Associations . . . . . . . . . . . 21 83 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 84 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 22 85 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22 86 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 87 9.1. Normative References . . . . . . . . . . . . . . . . . . . 22 88 9.2. Informative References . . . . . . . . . . . . . . . . . . 24 89 Appendix A. IPv4-IPv6 Interoperability . . . . . . . . . . . . . 24 90 Appendix B. Base Exchange through a Rendezvous Server . . . . . . 24 91 Appendix C. Document Revision History . . . . . . . . . . . . . . 25 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 93 Intellectual Property and Copyright Statements . . . . . . . . . . 27 95 1. Introduction 97 HIP [RFC5201] is defined as a protocol that runs directly over IPv4 98 or IPv6. This approach is known to have problems traversing NATs. A 99 detailed description of HIP problems with traversing legacy 100 middleboxes is documented in [I-D.irtf-hiprg-nat]. This document 101 describes HIP extensions for the traversal of both Network Address 102 Translator (NAT) and Network Address and Port Translator (NAPT) 103 middleboxes. The document generally uses the term NAT to refer to 104 these types of middleboxes. 106 Currently deployed NAT devices do not operate consistently even 107 though a recommended behavior is described in [RFC4787]. The HIP 108 protocol extensions in this document make as few assumptions as 109 possible about the behavior of the NAT devices so that NAT traversal 110 will work even with legacy NAT devices. The purpose of these 111 extensions is to allow two HIP-enabled hosts to communicate with each 112 other even if one or both communicating hosts are in private address 113 realms. 115 Using the extensions defined in this draft, HIP end-hosts use the HIP 116 control channel to communicate their current locators to each other 117 to find a operational path for the ESP encapsulated data traffic. 118 The hosts test connectivity between different locators and try to 119 discover direct end-to-end path between the end-hosts. However, With 120 some legacy NATs, utilizing the shortest path between two end hosts 121 located behind NATs is not possible without relaying the traffic 122 through a relay, such as a TURN server [RFC5128]. As a consequence, 123 the TURN server increases the roundtrip delay and may become a point 124 of network congestion. With the extensions described in this 125 document, hosts try to avoid the use the TURN server when possible. 127 This document defines new middlebox extensions to allow NAT traversal 128 for HIP control plane. The HIP Relay extensions define mechanisms to 129 forward HIP control plane. A distinction must be made here between a 130 HIP rendezvous services [RFC5204]) and HIP Relay services. HIP 131 rendezvous servers solve initial contact and mobility related 132 problems in networks without NATs. HIP Relay servers solve the same 133 problems, in addition to NAT traversal problems. HIP Relay servers 134 can be used both in NATed and non-NATed networks. 136 Both rendezvous and relay services forward HIP control packets, but 137 the main difference is that the rendezvous service forwards only the 138 initial I1 packet of the base exchange while all other HIP control 139 packets are sent directly between the communicating hosts. In 140 contrast, the relay service relays all HIP control packets because 141 NATs can drop the packets otherwise [RFC5128]. 143 The basis for the connectivity checks is ICE [I-D.ietf-mmusic-ice]. 145 [I-D.ietf-mmusic-ice] describes ICE as follows: 147 "The Interactive Connectivity Establishment (ICE) methodology is a 148 technique for NAT traversal for UDP-based media streams (though 149 ICE can be extended to handle other transport protocols, such as 150 TCP) established by the offer/answer model. ICE is an extension 151 to the offer/answer model, and works by including a multiplicity 152 of IP addresses and ports in SDP offers and answers, which are 153 then tested for connectivity by peer-to-peer connectivity checks. 154 The IP addresses and ports included in the SDP and the 155 connectivity checks are performed using the revised STUN 156 specification [I-D.ietf-behave-rfc3489bis], now renamed to Session 157 Traversal Utilities for NAT." 159 ICE for SIP is specified in [I-D.ietf-mmusic-ice] and ICE for non-SIP 160 protocols is specified in [I-D.rosenberg-mmusic-ice-nonsip]. 162 Two hosts communicate their locators to each other in the HIP base 163 exchange. They are then paired with the locally operational address 164 of the other endpoint and prioritized according local and recommended 165 policies. These address sets are then tested sequentially based on 166 the procedures specified in ICE. Both sides participate in the 167 connectivity checks. The tests may also discover multiple 168 operational address pairs but determine a single preferred address 169 pair to be used for subsequent communication. 171 In a nutshell, the extensions in this document defines: 173 o encapsulatation of HIP packets in UDP 175 o UDP encapsulation of IPsec ESP packets 177 o registration extensions for HIP Relay services 179 o how the "offer" and "answer" are carried in the base exchange 181 o interaction with ICE connectivity messages 183 o backwards compatibility issues with rendezvous servers 185 o a number of optimizations (such when the ICE connectivity tests 186 can be excluded) 188 2. Terminology 190 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 191 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 192 document are to be interpreted as described in [RFC2119]. 194 This document borrows terminology from [RFC5201], [RFC5206], 195 [RFC4423], [I-D.ietf-mmusic-ice], and [I-D.ietf-behave-rfc3489bis]. 196 Additionally, the following terms are used: 198 Rendezvous server: 200 A host that forwards I1 packets to the Responder 202 HIP Relay: 204 A host that forwards all HIP control packets between an Initiator 205 and Responder 207 TURN server: 209 A server that forwards data traffic between two end-hosts 211 Locator: 213 As defined in [RFC5206]: "A name that controls how the packet is 214 routed through the network and demultiplexed by the end host. It 215 may include a concatenation of traditional network addresses such 216 as an IPv6 address and end-to-end identifiers such as an ESP SPI. 217 It may also include transport port numbers or IPv6 Flow Labels as 218 demultiplexing context, or it may simply be a network address." 219 It should noticed that "address" is used in this document as a 220 synonym for locator. 222 HIP Relay: 224 LOCATOR (written in capital letters) denotes a HIP control message 225 parameter that bundles multiple locators together 227 ICE Offer: 229 The Initiator's LOCATOR parameter in HIP I2 control message. 231 ICE Answer: 233 The Responder's LOCATOR parameter in HIP R2 control message 235 Transport address: 237 Transport layer port and the corresponding IPv4/v6 address 239 Candidate: 241 A transport address that has not been verified yet for 242 reachability using ICE 244 Host candidate: 246 An IPv4 or IPv6 address of a network interface of a host 248 Server reflexive transport candidate: 250 A translated transport address of a host as observed by a HIP 251 Relay or a STUN server 253 Peer reflexive transport candidate: 255 A translated transport address of a host as observed by its peer 257 Relayed transport candidate: 259 A transport address that exists on a TURN server. Packets that 260 arrive at this address are relayed towards the TURN client. 262 3. Protocol Description 264 This section describes the normative behavior of the protocol 265 extension. Examples of packet exchanges are provided for 266 illustration purposes. 268 3.1. Relay Registration 270 HIP rendezvous servers operate in non-NATed environments and their 271 use is described in [RFC5204]. This section specifies a new 272 middlebox extension, called the HIP Relay, to perate in NATted 273 environments. HIP Relay servers forward all HIP control packets 274 between the Initiator and the Responder over UDP. 276 End-hosts cannot use the HIP Relay service for forward ESP data 277 plane. Instead, they use TURN servers [I-D.ietf-behave-turn] for 278 relaying the ESP traffic. A HIP end-host SHOULD register to a TURN 279 server before registering to a HIP Relay to guarantee that the host 280 can accept ESP traffic immediately after HIP Relay registration. 282 A HIP Relay MUST silently drop packets to a HIP Relay Client that has 283 not previously registered with the HIP Relay. The registration 284 process follows the generic registration extensions defined in 285 [RFC5203] and is illustrated in Figure 1. 287 HIP HIP 288 Relay Relay 289 Client Server 290 | 1. UDP(I1) | 291 +------------------------------------------------------->| 292 | | 293 | 2. UDP(R1(REG_INFO(RELAY_UDP_HIP))) | 294 |<-------------------------------------------------------+ 295 | | 296 | 3. UDP(I2(REG_REQ(RELAY_UDP_HIP))) | 297 +------------------------------------------------------->| 298 | | 299 | 4. UDP(R2(REG_RES(RELAY_UDP_HIP), REG_FROM)) | 300 |<-------------------------------------------------------+ 302 Figure 1: Example Registration to a HIP Relay 304 In step 1, the Relay Client (Initiator) starts the registration 305 procedure by sending an I1 packet over UDP. It is RECOMMENDED that 306 the Initiator selects a random port number from the ephemeral port 307 range 49152-65535 for initiating a base exchange. However, the 308 allocated port MUST be maintained until all of the corresponding HIP 309 Associations are closed. Alternatively, a host MAY also use a single 310 fixed port for initiating all outgoing connections. 312 In step 2, the Relay Server (Responder) lists the services that it 313 supports in the R1 packet. The support for HIP-over-UDP relaying is 314 denoted by the RELAY_UDP_HIP value. The R1 SHOULD not contain any 315 NAT transform parameter. 317 In step 3, the Initiator selects the services it registers for and 318 lists them in the REG_REQ parameter. In this example, the Initiator 319 registers for HIP Relay service. 321 In step 4, the Responder concludes the registration procedure with an 322 R2 packet and acknowledges the registered services in the REG_RES 323 parameter. The Responder denotes unsuccessful registrations in the 324 REG_FAILED parameter in R2. The Responder also includes a REG_FROM 325 parameter that contains the transport address of the client as 326 observed by the Relay (Server Reflexive candidate). After the 327 registration, the Initiator sends periodically NAT keepalives. 329 There are different ways for an Initiator to learn it's publicly 330 visible IP address and port that are referred to as the "server 331 reflexive transport candidate" in this document. It is a local 332 decision on how the end-host learnds the candidate, but either of the 333 following methods is RECOMMENDED: 335 o The Relay client may use STUN servers to detect the server 336 reflexive locator, as described in [RFC5128]. 338 o Alternatively, the Relay Client can learn it from the REG_FROM 339 parameter when registering to a Relay. 341 3.2. NAT Transformation Negotiation 343 This section describes the usage of a new non-critical transform 344 parameter type. The presence of the parameter in HIP base exchange 345 means that the end-host supports ICE connectivity checks. As the 346 parameter is non-critical, it can be ignored by an end-host which 347 means that the host does not support or is not willing to use ICE 348 connectivity checks. 350 The NAT transform parameter applies to a base exchange between end- 351 hosts, but currently does not apply to with a registration with a HIP 352 Relay server. The NAT transform applies only to a base exchange with 353 transport layer encapsulation and MUST not be included without 354 transport layer encapsulation. The NAT transform negotiation in base 355 exchange is illustrated in Figure 2. 357 Initiator Responder 358 | 1. UDP(I1) | 359 +------------------------------------------------------------->| 360 | | 361 | 2. UDP(R1(.., NAT_TRANSFORM(list of transforms), ..)) | 362 |<-------------------------------------------------------------+ 363 | | 364 | 3. UDP(I2(.., NAT_TRANSFORM(selected transform), LOCATOR..)) | 365 +------------------------------------------------------------->| 366 | | 367 | 4. UDP(R2(.., LOCATOR, ..)) | 368 |<-------------------------------------------------------------+ 369 | .... | 371 Figure 2: Negotiation of NAT Transforms 373 In step 1, the Initiator sends an I1 to the Responder. In step 2, 374 the Responder responds with an R1. The R1 contains a list of 375 transforms the Responder supports in NAT_TRANSFORM parameter as shown 376 in Table 1. 378 +--------------+----------------------------------------------------+ 379 | Transform | Purpose | 380 | Type | | 381 +--------------+----------------------------------------------------+ 382 | RESERVED | Reserved for future use | 383 | ICE-STUN-UDP | UDP encapsulated control and data traffic with | 384 | | ICE-based connectivity checks using STUN messages | 385 +--------------+----------------------------------------------------+ 387 Table 1: Locator Transformations 389 In step 3, the Initiator sends an I2 that includes a NAT_TRANSFORM 390 parameter. It contains the transform type selected by the Initiator 391 from the list of transforms offered by the Responder. The I2 also 392 includes the locators of the Initiator in a LOCATOR parameter. The 393 locator parameter in I2 is the "ICE offer". 395 In step 4, the Responder concludes the base exchange with an R2 396 packet. The Responder includes a LOCATOR parameter in the R2 packet. 397 The locators parameter in R2 is the "ICE answer". 399 3.3. Base Exchange via HIP Relay 401 This section describes how Initiator and Responder establish a base 402 exchange through a HIP Relay. The NAT transform negotiation (denoted 403 as NAT_TFM in the example) was described in previous section and 404 shall not be repeated here. When a Relay receives an R1 or I2 packet 405 without the NAT transform packet, it drops it and sends a NOTIFY 406 error message to the originator. 408 It is RECOMMENDED that the Initiator sends an I1 packet encapsulated 409 in UDP when it is destined to an IPv4 address of the Responder. 410 Respectively, the Responder MUST respond to such an I1 packet with an 411 R1 packet over the transport layer and using the same transport 412 protocol. The rest of the base exchange, I2 and R2, MUST also use 413 the same transport layer. 415 I HIP Relay R 416 | 1. UDP(I1) | | 417 +----------------------------->| 2. UDP(I1(RELAY_FROM)) | 418 | +------------------------------->| 419 | | | 420 | | 3. UDP(R1(RELAY_TO, NAT_TFM)) | 421 | 4. UDP(R1(RELAY_TO),NAT_TFM) |<-------------------------------+ 422 |<-----------------------------+ | 423 | | | 424 | 5. UDP(I2(LOCATOR),NAT_TFM) | | 425 +----------------------------->| 6. UDP(I2(LOCATOR,RELAY_FROM),| 426 | | NAT_TFM) | 427 | +------------------------------->| 428 | | | 429 | | 7. UDP(R2(LOCATOR,RELAY_TO)) | 430 | 8. UDP(R2(LOCATOR,RELAY_TO)) |<-------------------------------+ 431 |<-----------------------------+ | 432 | | | 434 Figure 3: Base Exchange via a HIP Relay 436 In step 1 of Figure 3, the Initiator sends an I1 packet over the 437 transport layer to the HIT of the Responder. The source address is 438 one of the locators of the host. The locators belonging to the end- 439 hosts are referred as "host candidates" in this document. 441 In step 2, the HIP Relay receives the I1 packet at port HIPPORT. If 442 the destination HIT belongs to a registered Responder, the Relay 443 processes the packet. Otherwise, the Relay MUST drop the packet 444 silently. The Relay appends a RELAY_FROM parameter to the I1 packet 445 which contains the transport source address and port of the I1 as 446 observed by the Relay. The Relay protects the I1 packet with 447 RELAY_HMAC as described in [RFC5204], except that the parameter type 448 is different. The Relay changes the source and destination ports and 449 IP addresses of the packet to match the values the Responder used 450 when registering to the Relay, i.e., the reverse of the R2 used in 451 the registration. The Relay MUST recalculate the transport checksum 452 and forward the packet to the Responder. 454 In step 3, the Responder receives the I1 packet. The Responder 455 processes it according to the rules in [RFC5201]. In addition, the 456 Responder validates the RELAY_HMAC according to [RFC5204] and 457 silently drops the packet if the validation fails. The Responder 458 replies with an R1 packet to which it includes a RELAY_TO parameter. 459 The RELAY_TO parameter MUST contain same information as the 460 RELAY_FROM parameter, i.e., the Initiator's transport address and the 461 nonce, but the type of the parameter is different. The RELAY_TO 462 parameter is not integrity protected by the signature of the R1 to 463 allow pre-created R1 packets at the Responder. 465 In step 4, the Relay receives the R1 packet. The Relay drops the 466 packet silently if the source HIT belongs to an unregistered host. 467 The Relay MAY verify the signature of the R1 packet and drop it if 468 the signature is invalid. Otherwise, the Relay rewrites the source 469 address and port, and changes the destination address and port to 470 match RELAY_TO information. Finally, the Relay recalculates 471 transport checksum and forwards the packet. 473 In step 5, the Initiator receives the R1 packet and processes it 474 according to [RFC5201]. It replies with an I2 packet that uses the 475 destination transport address of R1 as the source address and port. 476 The I2 contains a LOCATOR parameter that lists all the ICE candidates 477 (ICE offer) of the Initiator. The candidates are encoded using the 478 format defined in Section 4.5. The I2 packet MUST also contain the 479 NAT transform parameter with ICE-STUN-UDP or some other transform 480 selected because otherwise the Relay may drop the I2 packet. 482 In step 6, the Relay receives the I2 packet. The relay appends a 483 RELAY_FROM and a RELAY_HMAC to the I2 packet as explained in the 484 second step. 486 In step 7, the Responder receives the I2 packet and processes it 487 according to [RFC5201]. It replies with a R2 packet and includes a 488 RELAY_TO parameter as explained in step three. The R2 packet 489 includes a LOCATOR parameter that lists all the ICE candidates (ICE 490 answer) of the Responder. The RELAY_TO parameter is protected by the 491 HMAC. 493 In step 8, the Relay processes the R2 as described in step four. The 494 Relay forwards the packet to the Responder. 496 3.4. ICE Connectivity Checks 498 The Responder completes the base exchange with the R2 packet through 499 the Relay. When Initiator successfully receives and processes the 500 R2, both hosts have transitioned to ESTABLISHED state. However, the 501 destination address the Initiator and Responder used for delivering 502 base exchange packets belonged to the Relay as indicated by the 503 RELAY_FROM and RELAY_TO parameters. Therefore, the address of the 504 Relay MUST not be used for sending ESP traffic unless it was listed 505 as a TURN server in the offer/answer. Instead, the Initiator and 506 Responder MUST start ICE connectivity tests after they have 507 transitioned to ESTABLISHED state after the base exchange when they 508 do not have valid locator pair for ESP traffic and the NAT transform 509 parameter was negotiated successfully. 511 The ICE connectivity checks are defined in [I-D.ietf-mmusic-ice]. 512 Section Section 4.2 defines the details of the STUN control packets. 513 As a result of the ICE connectivity checks, ICE nominates a single 514 transport address pair to be used if an operational address could be 515 found. The end-hosts MUST use this address pair for the ESP traffic. 517 3.5. NAT Keepalives 519 To prevent NAT state from expiring, communicating end-hosts hosts 520 send periodically keepalives to each other. NAT Relays MUST not send 521 any keepalives. An end-host MUST send keepalives every 15 seconds to 522 refresh the UDP port mapping at the NAT(s) when the control or data 523 channel is idle. To implement failure tolerance, an end-host SHOULD 524 have shorter keepalive period. 526 The keepalives are STUN Binding Indications if the hosts have agreed 527 on NAT_TRANSFORM during the base exchange, or HIP NOTIFY messages 528 otherwise. A HIP Relay MUST not forward NOTIFY messages. 530 The communicating hosts MUST send keepalives to each other using the 531 transport locators exchanged in the base exchange when they are in 532 ESTABLISHED state. Also, the Initiator MUST send a NOTIFY message to 533 the Relay to refresh the NAT state alive on the path between the 534 Initiator and Relay when the Initiator has not received any response 535 to its I1 or I2 from the Responder in 15 seconds. The Relay MUST not 536 forward the NOTIFY messages. 538 3.6. Base Exchange without ICE Connectivity Checks 540 In certain network environments, the ICE connectivity checks can be 541 omitted to reduce initial connection set up latency because base 542 exchange acts an implicit connectivity test itself. There are three 543 assumptions about such as environments. First, the Responder should 544 have a long-term, fixed locator in the network. Second, the 545 Responder should not have a HIP Relay configured for itself. Third, 546 the Initiator can reach the Responder by simply UDP encapsulating HIP 547 and ESP packets to the host. Detecting and configuring this 548 particular scenario is prone to administrative failure unless 549 carefully planned. 551 In such a scenario, the Initiator sends an I1 packet over UDP to the 552 Responder. The Responder replies with a R1 packet that does not 553 contain the NAT transform parameter. The Initiator receives the R1 554 packet and determines from the absence of the NAT transform and 555 RELAY_TO parameters that ICE connectivity checks can be omitted. 556 Finally, the hosts can start to use the locators from the concluding 557 I2 and R2 packets of the base exchange for ESP without ICE 558 connectivity checks. 560 3.7. Base Exchange without UDP Encapsulation 562 The Initiator MAY also try to establish a base exchange with the 563 Responder without UDP encapsulation. In such a case, the Initiator 564 sends first an I1 packet without UDP encapsulation to the Responder. 565 After 100 ms, the Initiator MUST then send an UDP-encapsulated I1 566 packet. For retransmissions, the procedure is repeated. 568 The I1 packet may arrive directly at the Responder. When the 569 recipient is the Responder, the proceduces in [RFC5201] are followed 570 for the rest of the base exchange. The Initiator may receive 571 multiple R1 messages from the Responder, but upon receiving a valid 572 R1 without UDP encapsulation, the Initiator MUST ignore further R1 573 messages with UDP encapsulation encapsulation. The end-hosts do not 574 trigger ICE connectivity checks after the base exchange since the UDP 575 encapsulation was excluded. 577 The packet may also arrive at a HIP-capable middlebox. When the 578 middlebox is a HIP rendezvous server and the Responder has 579 successfully registered to the rendezvous service, the middlebox 580 follows rendezvous procedures in [RFC5204]. If the middlebox is a 581 HIP Relay server, it drops the I1 packet silently. 583 3.8. Sending Control Messages using the Data Plane 585 The end-hosts MAY send control messages directly to each other using 586 the transport address pair established for data channel without 587 sending the control packets through the Relay. When a host does not 588 get acknowledgements e.g. to an UPDATE or CLOSE message after a 589 timeout based on local policies, the host SHOULD resend the packet 590 through the Relay. This optimization requires further 591 experimentation. 593 4. Packet Formats 595 The following subsections define the parameter and packet encodings. 596 All values MUST be in network byte order. 598 4.1. HIP Control Packets 600 0 1 2 3 601 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 602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 603 | Source Port | Destination Port | 604 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 605 | Length | Checksum | 606 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 607 | 32 bits of zeroes | 608 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 609 | | 610 ~ HIP Header and Parameters ~ 611 | | 612 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 614 Figure 4: Format for UDP-encapsulated HIP Control Packets 616 HIP control packets are encapsulated in UDP packets as defined in 617 Section 2.2 of [RFC3948], "rules for encapsulating IKE messages" 618 except for a different port number. Figure 4 illustrates the 619 encapsulation. The UDP header is followed by 32 zero bits that can 620 be used to differentiate HIP control packets from ESP packets. The 621 HIP header and parameters follow the conventions of [RFC5201] with 622 the exception that the HIP header checksum MUST be zero. The HIP 623 header checksum is zero for two reasons. First, the UDP header 624 contains already a checksum. Second, the checksum definition in 625 [RFC5201] includes the IP addresses in the checksum calculation. The 626 NATs unaware of HIP cannot recompute the HIP checksum after changing 627 IP addresses. 629 A HIP Relay or a Responder without a relay MUST listen at transport 630 port HIPPORT for incoming UDP-encapsulated HIP control packets. 632 4.2. Connectivity Checks 634 The connectivity checks are performed using STUN Binding Requests. 635 This section describes the details of the parameters in the STUN 636 messages. 638 The username is formed from the username fragments as defined in 639 section 7.1.1.3 of [I-D.ietf-mmusic-ice]. The requests MUST use STUN 640 short term credentials with HITs of the Initiator and Responder 641 concatenated as a username fragment. The HITs are concatenated 642 according to the Sort(HIT-I, HIT-R) algorithm defined in [RFC5201] 643 section 6.5. The HIT username fragment MUST contain a UTF-8 644 [RFC3629] encoded sequence and MUST have been processed using 645 SASLPrep [RFC4013] as defined section 15.3 of 647 [I-D.ietf-behave-rfc3489bis]. The concatenated HIT pair MUST have a 648 fixed size that is accomplished by including the leading zeroes for 649 the HITs. 651 Drawing of HIP keys is defined in [RFC5201] section 6.5 and drawing 652 of ESP keys in [RFC5202] section 7. Correspondingly, the hosts MUST 653 draw symmetric keys for STUN according to [RFC5201] section 6.5. The 654 hosts draw the STUN keys after HIP keys, or after ESP keys if ESP 655 transform was successfully negotiated in the base exchange. The 656 hosts draw two keys which they MUST use to generate the STUN 657 password. As the STUN password is the same at both ends, the two 658 drawn keys MUST be concatenated with the key for the greater HIT 659 first. Section 15.4 of [I-D.ietf-behave-rfc3489bis] describes how 660 hosts use the password for message integrity of STUN messages. 662 The connectivity checks MUST contain PRIORITY attribute. They MAY 663 contain USE-CANDIDATE attributes as defined in section 7.1.1.1 of 664 [I-D.ietf-mmusic-ice]. 666 The Initiator is always in the controller role during a base 667 exchange. Hence, the ICE-CONTROLLED and ICE-CONTROLLING attributes 668 are not needed and SHOULD NOT be used. When two hosts are initiating 669 to each other simultaneously, HIP state machine detects it and 670 assigns the host with the larger HIT as the Responder as explained in 671 sections 4.4.2 and and 6.7 in [RFC5201]. 673 4.3. Keepalives 675 The keepalives for HIP associations agreed that are NAT_TRANSFORM 676 capable are STUN Binding Indications, as defined in 677 [I-D.ietf-behave-rfc3489bis]. The source and destination ports are 678 in the UDP header are the same as used for HIP (50500). However, in 679 contrast to the UDP encapsulated HIP header, there non-ESP-marker 680 between the UDP header and the STUN header is excluded. Keepalives 681 MUST contain the FINGERPRINT STUN attribute but SHOULD NOT contain 682 any other STUN attributes and SHOULD NOT utilize any authentication 683 mechanism. STUN messages are demultiplexed from ESP and HIP control 684 messages using the STUN markers, such as the magic cookie value and 685 the FINGERPRINT attribute. 687 Keepalives for aHIP associations that are not NAT_TRANSFORM capable 688 are HIP control messages that have NOTIFY as the packet type. The 689 NOTIFY messages do not contain any parameters. 691 4.4. Relay and Registration Parameters 693 0 1 2 3 694 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 695 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 696 | Type | Length | 697 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 698 | | 699 | Address | 700 | | 701 | | 702 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 703 | Port | Transport | 704 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 706 Type [ TBD by IANA: 707 REG_FROM: (64010 = 2^16 - 2^11 + 2^9 + 10) ] 709 Length 20 710 Address An IPv6 address or an IPv4 address in "IPv4-compatible 711 IPv6 address" format 712 Port Transport port number; zero when plain IP is used 713 Transport Transport protocol type; zero for UDP 715 Figure 5: Format for REG_FROM parameter 717 0 1 2 3 718 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 719 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 720 | Type | Length | 721 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 722 | | 723 | Address | 724 | | 725 | | 726 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 727 | Port | Transport | 728 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 729 | Nonce | 730 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 732 Type [ TBD by IANA: 733 Critical parameters: 734 RELAY_FROM: (63998 = 2^16 - 2^11 + 2^9 - 2) 735 RELAY_TO: (64002 = 2^16 - 2^11 + 2^9 + 2) 737 Length 24 738 Address An IPv6 address or an IPv4 address in "IPv4-compatible 739 IPv6 address" format 740 Port Transport port number; zero when plain IP is used 741 Transport Transport protocol type; zero for UDP 742 Nonce A nonce assigned by the Relay server. 744 Figure 6: Format for the RELAY_FROM and RELAY_TO parameters 746 Format for the REG_FROM parameter is shown in Figure 5, and 747 RELAY_FROM and RELAY_TO in Figure 6. Parameters are identical except 748 for the type and nonce fields. 750 The nonce field is an experimental field for the RELAY_FROM and 751 RELAY_TO parameters. It allows the Relay to have constant state 752 towards the Initiators without allowing the Responder to send R1 or 753 R2 packets to arbitrary hosts through the Relay. 755 4.5. LOCATOR Parameter 757 The generic LOCATOR parameter format is the same as in [RFC5206]. 758 However, presenting ICE candidates requires a new locator type. The 759 generic and NAT traversal specific locator parameters are illustrated 760 in Figure 7. 762 0 1 2 3 763 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 764 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 765 | Type | Length | 766 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 767 | Traffic Type | Locator Type | Locator Length| Reserved |P| 768 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 769 | Locator Lifetime | 770 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 771 | Locator | 772 | | 773 | | 774 | | 775 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 776 . . 777 . . 778 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 779 | Traffic Type | Loc Type = 2 | Locator Length| Reserved |P| 780 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 781 | Locator Lifetime | 782 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 783 | Transport Port | Transp. Proto| Kind | 784 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 785 | Priority | 786 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 787 | SPI | 788 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 789 | Locator | 790 | | 791 | | 792 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 794 Figure 7: LOCATOR parameter 796 The individual fields in the LOCATOR parameter are described in 797 Table 2. 799 +-----------+----------+--------------------------------------------+ 800 | Field | Value(s) | Purpose | 801 +-----------+----------+--------------------------------------------+ 802 | Type | 193 | Parameter type | 803 | Length | Variable | Length in octets, excluding Type and | 804 | | | Length fields and padding | 805 | Traffic | 0-2 | Is the locator for HIP signaling (1), for | 806 | Type | | ESP (2), or for both (0) | 807 | Locator | 2 | "Transport address" locator type | 808 | Type | | | 809 | Locator | 7 | Length of the Locator field in 4-octet | 810 | Length | | units | 811 | Reserved | 0 | Reserved for future extensions | 812 | Preferred | 0 | Not used for transport address locators; | 813 | (P) bit | | MUST be ignored by the receiver. | 814 | Locator | Variable | Locator lifetime in seconds | 815 | Lifetime | | | 816 | Transport | Variable | Transport layer port number | 817 | Port | | | 818 | Transport | 0 | 0 for UDP | 819 | Protocol | | | 820 | Kind | Variable | 0 for host, 1 for server reflexive, 2 for | 821 | | | peer reflexive or 3 for relayed address | 822 | Priority | Variable | Locator's priority as described in | 823 | | | [I-D.ietf-mmusic-ice] | 824 | SPI | Variable | SPI value which the host expects to see in | 825 | | | incoming ESP packets that use this locator | 826 | Locator | Variable | IPv6 address or an "IPv4-compatible IPv6 | 827 | | | address" format IPv4 address [RFC3513], | 828 | | | obfuscated by XORing it with the owner's | 829 | | | HIT | 830 +-----------+----------+--------------------------------------------+ 832 Table 2: Fields of the LOCATOR parameter 834 4.6. RELAY_HMAC 836 The RELAY_HMAC parameter value has the TLV type 65520 (2^16 - 2^5 + 837 2^4). It has the same semantics as RVS_HMAC [RFC5204]. 839 4.7. Registration Types 841 The REG_INFO, REQ_REQ, REG_RESP and REG_FAILED parameters contain 842 values for HIP Relay registration. The value for RELAY_UDP_HIP is 2. 843 The value for RELAY_UDP_ESP is 3. 845 4.8. ESP Data Packets 847 [RFC3948] describes UDP encapsulation of the IPsec ESP transport and 848 tunnel mode. On the wire, the HIP ESP packets do not differ from the 849 transport mode ESP and thus the encapsulation of the HIP ESP packets 850 is same as the UDP encapsulation transport mode ESP. However, the 851 (semantic) difference to BEET mode ESP packets used by HIP is that IP 852 header is not used in BEET integrity protection calculation. 854 During the HIP base exchange, the two peers exchange parameters that 855 enable them to define a pair of IPsec ESP security associations (SAs) 856 as described in [RFC5202]. When two peers perform a UDP-encapsulated 857 base exchange, they MUST define a pair of IPsec SAs that produces 858 UDP-encapsulated ESP data traffic. 860 The management of encryption/authentication protocols and SPIs is 861 defined in [RFC5202]. The UDP encapsulation format and processing of 862 HIP ESP traffic is described in Section 6.1 of [RFC5202]. 864 5. Security Considerations 866 5.1. Privacy Considerations 868 The locators are in XORed format in plain text in favor of inspection 869 at HIP-aware middleboxes in the future. The current draft does not 870 specify encrypted versions of LOCATORs even though it could be 871 beneficial for privacy reasons. 873 It is possible that an Initiator or Responder may not want to reveal 874 all of its locators to its peer. For example, a host may not want to 875 reveal the internal topology of the private address realm and it 876 discards host addresses. Such behavior creates non-optimal paths 877 when the hosts are located behind the same NAT. Especially, this 878 could be a problem with a legacy NAT that does not support routing 879 from the private address realm back to itself through the outer 880 address of the NAT. This scenario is referred to as the hairpin 881 problem [RFC5128]. With such a legacy NAT, the only option left 882 would be to use a relayed transport address from a TURN server. 884 As a consequence, a host may support locator-based privacy by leaving 885 out the reflexive candidates. However, the trade-off in using only 886 host candidates can produce suboptimal paths that can congest the 887 TURN server. The use of HIP Relays or TURN Relays can be useful for 888 protection against Denial-of-Service attacks. If a Responder reveals 889 only its HIP Relay addresses and Relayed transport candidates to 890 Initiators, the Initiators can only attack the relays that does not 891 prevent the Responder from initiating new outgoing connections if a 892 path around the relay exists. 894 5.2. Opportunistic Mode 896 A HIP Relay server should have one address per Relay Client when a 897 HIP Relay is serving more than one Relay Clients and supports 898 opportunistic mode. Otherwise, it cannot be guaranteed that the 899 Relay can deliver the I1 packet to the intended recipient. 901 5.3. Base Exchange Replay Protection for HIP Relay Server 903 On certain scenarios, it is possible that an attacker, or two 904 attackers, can replay an earlier base exchange through a Relay server 905 by masquerading as the original Initiator and Responder. The attack 906 does not require the attacker(s) to compromise the private key(s) of 907 the attacked host(s). However, Responder has to be disconnected from 908 the Relay in order to masquarade successfully as the Responder. 910 The Relay can protect itself against Replay attacks by involving in 911 the base exchange by introducing nonces that the end-hosts (Initiator 912 and Responder) have to sign. The Relay MAY add ECHO_REQUEST_M 913 parameters to the R1 and I2 messages as described in 914 [I-D.heer-hip-middle-auth] and drops the I2 or R2 messages if the 915 corresponding ECHO_RESPONSE_M parameters are not present. 917 5.4. Demuxing Different HIP Associations 919 Section 5.1 of [RFC3948] describes a security issue for the UDP 920 encapsulation in the standard IP tunnel mode when two hosts behind 921 different NATs have the same private IP address and initiate 922 communication to the same Responder in the public Internet. The 923 Responder cannot distinguish between two hosts, because security 924 associations are based on the same inner IP addresses. 926 This issue does not exist with the UDP encapsulation of HIP ESP 927 transport format because the Responder use HITs to distinguish 928 between different Initiators. 930 6. IANA Considerations 932 This section is to be interpreted according to [RFC2434]. 934 This draft currently uses a UDP port in the "Dynamic and/or Private 935 Port" and HIPPORT. Upon publication of this document, IANA is 936 requested to register a UDP port and the RFC editor is requested to 937 change all occurrences of port HIPPORT to the port IANA has 938 registered. The HIPPORT number 50500 should be used for initial 939 experimentation. 941 This document updates the IANA Registry for HIP Parameter Types by 942 assigning new HIP Parameter Type values for the new HIP Parameters: 943 RELAY_FROM, RELAY_TO and REG_FROM (defined in Section 4.4) and 944 RELAY_HMAC (defined in Section 4.6). NAT_TRANSFORM is also a new 945 parameter. 947 7. Contributors 949 This draft is a product of a design team which also included Marcelo 950 Bagnulo and Jan Melen who both have made major contributions to this 951 document. 953 8. Acknowledgments 955 Thanks for Jonathan Rosenberg and the rest of the MMUSIC WG folks for 956 the excellent work on ICE. In addition, the authors would like to 957 thank Andrei Gurtov, Simon Schuetz, Martin Stiemerling, Lars Eggert, 958 Vivien Schmitt, Abhinav Pathak for their contributions and Tobias 959 Heer, Teemu Koponen, Juhana Mattila, Jeffrey M. Ahrenholz, Thomas 960 Henderson, Kristian Slavov, Janne Lindqvist, Pekka Nikander, Lauri 961 Silvennoinen, Jukka Ylitalo, Juha Heinanen, Joakim Koskela, Samu 962 Varjonen, Dan Wing and Jani Hautakorpi for their comments on this 963 document. 965 Miika Komu is working in the Networking Research group at Helsinki 966 Institute for Information Technology (HIIT). The InfraHIP project 967 was funded by Tekes, Telia-Sonera, Elisa, Nokia, the Finnish Defence 968 Forces, and Ericsson and Birdstep. 970 9. References 972 9.1. Normative References 974 [I-D.ietf-behave-rfc3489bis] 975 Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 976 "Session Traversal Utilities for (NAT) (STUN)", 977 draft-ietf-behave-rfc3489bis-16 (work in progress), 978 July 2008. 980 [I-D.ietf-behave-turn] 981 Rosenberg, J., Mahy, R., and P. Matthews, "Traversal Using 982 Relays around NAT (TURN): Relay Extensions to Session 983 Traversal Utilities for NAT (STUN)", 984 draft-ietf-behave-turn-08 (work in progress), June 2008. 986 [I-D.ietf-mmusic-ice] 987 Rosenberg, J., "Interactive Connectivity Establishment 988 (ICE): A Protocol for Network Address Translator (NAT) 989 Traversal for Offer/Answer Protocols", 990 draft-ietf-mmusic-ice-19 (work in progress), October 2007. 992 [I-D.rosenberg-mmusic-ice-nonsip] 993 Rosenberg, J., "NICE: Non Session Initiation Protocol 994 (SIP) usage of Interactive Connectivity Establishment 995 (ICE)", draft-rosenberg-mmusic-ice-nonsip-00 (work in 996 progress), February 2008. 998 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 999 Requirement Levels", BCP 14, RFC 2119, March 1997. 1001 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1002 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 1003 October 1998. 1005 [RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6 1006 (IPv6) Addressing Architecture", RFC 3513, April 2003. 1008 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 1009 10646", STD 63, RFC 3629, November 2003. 1011 [RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User Names 1012 and Passwords", RFC 4013, February 2005. 1014 [RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol 1015 (HIP) Architecture", RFC 4423, May 2006. 1017 [RFC5201] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson, 1018 "Host Identity Protocol", RFC 5201, April 2008. 1020 [RFC5202] Jokela, P., Moskowitz, R., and P. Nikander, "Using the 1021 Encapsulating Security Payload (ESP) Transport Format with 1022 the Host Identity Protocol (HIP)", RFC 5202, April 2008. 1024 [RFC5203] Laganier, J., Koponen, T., and L. Eggert, "Host Identity 1025 Protocol (HIP) Registration Extension", RFC 5203, 1026 April 2008. 1028 [RFC5204] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) 1029 Rendezvous Extension", RFC 5204, April 2008. 1031 [RFC5206] Nikander, P., Henderson, T., Vogt, C., and J. Arkko, "End- 1032 Host Mobility and Multihoming with the Host Identity 1033 Protocol", RFC 5206, April 2008. 1035 9.2. Informative References 1037 [I-D.heer-hip-middle-auth] 1038 Heer, T., Wehrle, K., and M. Komu, "End-Host 1039 Authentication for HIP Middleboxes", 1040 draft-heer-hip-middle-auth-01 (work in progress), 1041 July 2008. 1043 [I-D.irtf-hiprg-nat] 1044 Stiemerling, M., "NAT and Firewall Traversal Issues of 1045 Host Identity Protocol (HIP) Communication", 1046 draft-irtf-hiprg-nat-04 (work in progress), March 2007. 1048 [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. 1049 Stenberg, "UDP Encapsulation of IPsec ESP Packets", 1050 RFC 3948, January 2005. 1052 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 1053 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 1054 RFC 4787, January 2007. 1056 [RFC5128] Srisuresh, P., Ford, B., and D. Kegel, "State of Peer-to- 1057 Peer (P2P) Communication across Network Address 1058 Translators (NATs)", RFC 5128, March 2008. 1060 Appendix A. IPv4-IPv6 Interoperability 1062 Currently Relay Client and Server do not have to run any ICE 1063 connectivity tests as described in Section 3.6. However, it could be 1064 useful for IPv4-IPv6 interoperability when the Relay Server actually 1065 includes both the NAT transform parameter and multiple locators in 1066 R2. The interoperability benefit is that the Relay could support 1067 IPv4-based Initiators and IPv6-based Responders by converting the 1068 network headers and recalculating UDP checksums. 1070 Such an approach is underspecified in this document currently. It is 1071 not yet recommended because it may consume resources at the Relay and 1072 requires also similar conversion support at the TURN relay for data 1073 packets. 1075 Appendix B. Base Exchange through a Rendezvous Server 1077 This section describes handling for a scenario where Initiator looks 1078 up the information of the Responder from DNS and discovers a RVS 1079 record [RFC5204]. In such a case, the Initiator uses its own HIP 1080 Relay to forward HIP traffic to the Rendezvous server. The Initiator 1081 will send the I1 message using the its HIP Relay server which will 1082 then forward it to the RVS server of the responder. The responder 1083 will send the R1 packet directly to the Initiator's HIP Relay server 1084 and the following I2 and R2 packets are also sent directly using the 1085 Relay. 1087 In case the Initiator is not able to distinguish which records are 1088 RVS address records and which are Responders address records, then 1089 the Initiator SHOULD first try to contact the Responder directly and 1090 if none of the addresses is reachable it MAY try out them using its 1091 own HIP Relay as described in the above. 1093 Appendix C. Document Revision History 1095 To be removed upon publication 1097 +-----------------------------+-------------------------------------+ 1098 | Revision | Comments | 1099 +-----------------------------+-------------------------------------+ 1100 | draft-ietf-nat-traversal-00 | Initial version. | 1101 | draft-ietf-nat-traversal-01 | Draft based on RVS. | 1102 | draft-ietf-nat-traversal-02 | Draft based on Relay proxies and | 1103 | | ICE concepts. | 1104 | draft-ietf-nat-traversal-03 | Draft based on STUN/ICE formats. | 1105 | draft-ietf-nat-traversal-04 | Issues 25-27,29-36 | 1106 +-----------------------------+-------------------------------------+ 1108 Authors' Addresses 1110 Miika Komu 1111 Helsinki Institute for Information Technology 1112 Metsanneidonkuja 4 1113 Espoo 1114 Finland 1116 Phone: +358503841531 1117 Fax: +35896949768 1118 Email: miika@iki.fi 1119 URI: http://www.hiit.fi/ 1120 Thomas Henderson 1121 The Boeing Company 1122 P.O. Box 3707 1123 Seattle, WA 1124 USA 1126 Email: thomas.r.henderson@boeing.com 1128 Philip Matthews 1129 (Unaffiliated) 1131 Email: philip_matthews@magma.ca 1133 Hannes Tschofenig 1134 Nokia Siemens Networks 1135 Linnoitustie 6 1136 Espoo 02600 1137 Finland 1139 Phone: +358 (50) 4871445 1140 Email: Hannes.Tschofenig@gmx.net 1141 URI: http://www.tschofenig.com 1143 Ari Keraenen (editor) 1144 Ericsson Research Nomadiclab 1145 Hirsalantie 11 1146 02420 Jorvas 1147 Finland 1149 Phone: +358 9 2991 1150 Email: ari.keranen@ericsson.com 1152 Full Copyright Statement 1154 Copyright (C) The IETF Trust (2008). 1156 This document is subject to the rights, licenses and restrictions 1157 contained in BCP 78, and except as set forth therein, the authors 1158 retain all their rights. 1160 This document and the information contained herein are provided on an 1161 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1162 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1163 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1164 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1165 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1166 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1168 Intellectual Property 1170 The IETF takes no position regarding the validity or scope of any 1171 Intellectual Property Rights or other rights that might be claimed to 1172 pertain to the implementation or use of the technology described in 1173 this document or the extent to which any license under such rights 1174 might or might not be available; nor does it represent that it has 1175 made any independent effort to identify any such rights. Information 1176 on the procedures with respect to rights in RFC documents can be 1177 found in BCP 78 and BCP 79. 1179 Copies of IPR disclosures made to the IETF Secretariat and any 1180 assurances of licenses to be made available, or the result of an 1181 attempt made to obtain a general license or permission for the use of 1182 such proprietary rights by implementers or users of this 1183 specification can be obtained from the IETF on-line IPR repository at 1184 http://www.ietf.org/ipr. 1186 The IETF invites any interested party to bring to its attention any 1187 copyrights, patents or patent applications, or other proprietary 1188 rights that may cover technology that may be required to implement 1189 this standard. Please address the information to the IETF at 1190 ietf-ipr@ietf.org.