idnits 2.17.1 draft-nikander-hip-path-01.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 on line 1193. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1170. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1177. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1183. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 210: '...destination port MUST NOT be expected ...' RFC 2119 keyword, line 720: '...-routability test MUST be performed in...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year ** The document contains RFC2119-like boilerplate, but doesn't seem to mention RFC 2119. The boilerplate contains a reference [4], but that reference does not seem to mention RFC 2119 either. -- 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 (March 6, 2006) is 6624 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: '18' is mentioned on line 1000, but not defined == Outdated reference: A later version (-10) exists of draft-ietf-hip-base-05 ** Downref: Normative reference to an Experimental draft: draft-ietf-hip-base (ref. '1') == Outdated reference: A later version (-05) exists of draft-ietf-hip-mm-03 ** Downref: Normative reference to an Experimental draft: draft-ietf-hip-mm (ref. '2') == Outdated reference: A later version (-05) exists of draft-ietf-hip-rvs-04 ** Downref: Normative reference to an Experimental draft: draft-ietf-hip-rvs (ref. '3') -- Possible downref: Non-RFC (?) normative reference: ref. '4' == Outdated reference: A later version (-09) exists of draft-nikander-esp-beet-mode-05 -- Obsolete informational reference (is this intentional?): RFC 3489 (ref. '9') (Obsoleted by RFC 5389) == Outdated reference: A later version (-25) exists of draft-ietf-nsis-nslp-natfw-09 -- Obsolete informational reference (is this intentional?): RFC 4306 (ref. '12') (Obsoleted by RFC 5996) == Outdated reference: A later version (-06) exists of draft-tschofenig-hiprg-hip-natfw-traversal-03 == Outdated reference: A later version (-02) exists of draft-ietf-hip-registration-01 == Outdated reference: A later version (-05) exists of draft-dupont-mipv6-3bombing-03 Summary: 8 errors (**), 0 flaws (~~), 11 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 HIP P. Nikander 3 Internet-Draft Ericsson 4 Expires: September 7, 2006 H. Tschofenig 5 Siemens 6 X. Fu 7 Univ. Goettingen 8 T. Henderson 9 The Boeing Company 10 J. Laganier 11 DoCoMo Euro-Labs 12 March 6, 2006 14 Preferred Alternatives for Tunnelling HIP (PATH) 15 draft-nikander-hip-path-01.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 September 7, 2006. 42 Copyright Notice 44 Copyright (C) The Internet Society (2006). 46 Abstract 48 With the extensions defined in this document Host Identity Protocol 49 (HIP) can traverse legacy Network Address Translators (NATs) and 50 certain firewalls. The extension will be useful as part of the base 51 exchange and with the HIP Registration Extension. By using a 52 rendezvous server an additional entity inside the network is 53 utilized, which not only allows but also supports more restrictive 54 NATs to be traversed. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 3. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . 6 61 3.1. UDP Encapsulation of HIP . . . . . . . . . . . . . . . . . 6 62 3.2. UDP-REA parameter . . . . . . . . . . . . . . . . . . . . 6 63 3.3. S-UDP-REA parameter . . . . . . . . . . . . . . . . . . . 7 64 4. Message Handling Rules . . . . . . . . . . . . . . . . . . . . 10 65 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 66 5.1. HIP Initiator behind a NAT . . . . . . . . . . . . . . . . 11 67 5.2. PATH Server Registration and Keep Alive . . . . . . . . . 11 68 5.3. Message flow for data receiver behind a NAT . . . . . . . 12 69 5.4. Mobility and multihoming message flow . . . . . . . . . . 15 70 6. New Requirements for IPsec . . . . . . . . . . . . . . . . . . 17 71 6.1. Association with server inside/outside NAT . . . . . . . . 17 72 6.2. Mobility Scenarios . . . . . . . . . . . . . . . . . . . . 17 73 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18 74 7.1. Third Party Bombing . . . . . . . . . . . . . . . . . . . 18 75 7.2. Black hole . . . . . . . . . . . . . . . . . . . . . . . . 19 76 7.3. Man-in-the-middle attack . . . . . . . . . . . . . . . . . 19 77 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 78 9. IAB Considerations . . . . . . . . . . . . . . . . . . . . . . 22 79 9.1. Problem Definition . . . . . . . . . . . . . . 22 80 9.2. Exit Strategy . . . . . . . . . . . . . . . . . . . . . . 22 81 9.3. Brittleness Introduced by PATH . . . . . . . . . . . . . . 23 82 9.4. Requirements for a Long Term Solution . . . . . . . . . . 24 83 9.5. Issues with Existing NAPT Boxes . . . . . . . . . . . . . 25 84 9.6. In Closing . . . . . . . . . . . . . . . . . . . . . . . . 26 85 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27 86 11. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 28 87 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 88 12.1. Normative References . . . . . . . . . . . . . . . . . . . 29 89 12.2. Informative References . . . . . . . . . . . . . . . . . . 29 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31 91 Intellectual Property and Copyright Statements . . . . . . . . . . 33 93 1. Introduction 95 This document defines extensions and allows the Host Identity 96 Protocol (HIP) to be used in an environment where legacy NATs or 97 Firewalls are present. To support this functionality it is necessary 98 to provide 100 o UDP encapsulation for HIP signaling messages 102 o UDP encapsulation for IPsec traffic 104 The problems of allowing IPsec protected traffic and the 105 corresponding signaling protocol (IKEv1) to traverse a NA(P)T are 106 well described in [5]. A proposal for UDP encapsulation of IPsec 107 protected traffic is described in [6]. It is possible to design an 108 optimized version of it for usage with HIP. This aspect is, however, 109 outside the scope of this document. 111 This document tries to accomplish the following goals: 113 o Make HIP work through legacy NATs (and possibly through some 114 firewalls) 116 o Make HIP hosts reachable behind NATs 118 HIP signaling consists of (for static and bootstrapping) base 119 exchange [1], which establish a HIP association state, and (in 120 particullar for mobilility and multi-homing scenarios) an Update 121 packet containing a LOCATOR parameter [2] which allows a HIP host to 122 notify a peer about alternate locator(s) at which it is reachable. A 123 third party in the network infrastructure, the rendezvous server 124 (RVS) is typically used to allow a HIP initiator to learn a 125 responder's (present) locator before initializing HIP base exchange. 126 The interaction of HIP hosts with the rendezvous server is described 127 in [3]. Currently, two possible ESP transport formats are being 128 defined for carrying HIP user data, namely the standard ESP [7] and 129 the BEET mode [8]. 131 This document builds on the RVS concept to allow HIP signaling and 132 ESP-mode data traffic to successfully traverse legacy NA(P)Ts (and if 133 necessary, firewalls). There are two possible approaches to achieve 134 this: 136 o First, it is possible to combine a HIP rendezvous server and a 137 STUN server [9], TURN server [10] or NSIS NATFW [11] node. Here, 138 the STUN, TURN or NSIS NATFW protocol is used to allow the PATH 139 client to learn the public IP address (and port number) created at 140 the NAT. The client obviously needs to support the client part of 141 the protocol as well. 143 o Alternatively, the HIP registration protocol can be extended to 144 integrate a NAT detection check. This ensembles NAT traversal 145 support in IKEv2 [12] and corresponding extensions for IKEv1 (see 146 [5] and [13]). 148 This document employs the latter approach to avoid the complexity of 149 integrating another protocol and additional message exchanges, while 150 still taking some advantages of the former approach. In contrast, an 151 integration with STUN or TURN may not bring better security features 152 in the protocol exchange. 154 In the proposed approach, a new parameter UDP-REA (UDP encapsulated 155 REAddress packet) is introduced to support NAT detection. When a HIP 156 message needs to be sent from a host to RVS (for registration 157 messages) or another HIP (HIP signaling and data traffic), with a 158 UDP-REA it is now possible to detect the existence of NATs and thus 159 retrieve or create only the preferred IP address and port number, 160 instead of the private address and port number for the host. Thus, 161 this approach is called "Preferred Alternatives for Tunnelling HIP", 162 or PATH. 164 To allow the client to inform the PATH server about its public IP 165 address and port in a secure fashion (where this is possible and 166 appropriate), another parameter is also introduced: S-UDP-REA, a 167 secure version of the UDP-REA parameter. By using this parameter a 168 secure traversal of legacy NATs is supported. The S-UDP-REA 169 parameter information can be obtained for example by interacting with 170 NSIS or MIDCOM. This provides better security properties, however 171 the details of interaction with NSIS or MIDCOM are outside the scope 172 of this document. 174 Please note that the goal of this document is different from that of 175 [14], where middleboxes (such as NATs and firewalls) are assumed to 176 be HIP-aware and participate in the HIP message exchange. As a 177 result, the security properties of these protocols are different as 178 well. 180 2. Terminology 182 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 183 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 184 document are to be interpreted as described in [4]. 186 For an interaction between a HIP host with a rendezvous server, two 187 communicating entities are also denoted as PATH client and PATH 188 server in this document. The PATH server always resides on the same 189 entity as the rendezvous server. A PATH client is a HIP-aware device 190 which supports the extensions defined in this document in addition to 191 the HIP Registration Extension [15]. The PATH client might be 192 located behind a legacy NAT and initiates the protocol exchange with 193 the PATH server. The PATH server interacts with the client in the 194 way specified in this document. 196 Different types of NATs (e.g., full cone, restricted NAT) are being 197 deployed today. [9] assigns these NAT boxes to certain categories 198 based on their data traffic forwarding or blocking behaviors. The 199 existence of different NAT types has an impact on the protocol. 201 3. Protocol Extensions 203 This section explains the necessary protocol extensions to support 204 the above-mentioned functionality. 206 3.1. UDP Encapsulation of HIP 208 In order to deal with NA(P)Ts, it is necessary that the HIP signaling 209 messages are UDP encapsulated. Moreover, the source port and the 210 destination port MUST NOT be expected at a fixed port number. This 211 aspect of NAT traversal is known from IPsec/IKE and also reflected in 212 the design of IKEv2. 214 It is a policy issue whether to enable UDP encapsulation immediately 215 when the first HIP base message is sent (i.e., the I1 message). 217 For IPv4, the packet format is shown in Appendix E of [1]. The same 218 specification states that UDP encapsulation is forbidden for IPv6 but 219 might still be necessary, particularly for IPv4-IPv6 transition. 221 3.2. UDP-REA parameter 223 This section defines the UDP-REA parameter which will be used in the 224 traversal of legacy NATs. 226 0 1 2 3 227 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 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 229 | Type | Length | 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 | Address Lifetime | Reserved | 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 ~ HASH ~ 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 ~ Padding ~ 236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 238 Type (2 bytes): 239 This parameter has the value of TBD. 241 Length (2 bytes) 242 Represents the length in octets, 243 excluding Type, Length and Padding. 245 Address Lifetime (2 bytes): 246 This field represents the address lifetime, in seconds. 248 HASH (variable): 249 This field of variable length contains the hash of 250 IP address and port information. 252 Padding (variable): 253 Padding information following the HASH value 255 The HASH is calculated as follows: 257 HASH = PRF(RANDOM | Source IP | Destination IP | Source Port | 258 Destination Port) 260 Where, PRF is a hash algorithm negotiated through HIP_TRANSFORM (see 261 Section 5.2.7 of [1]); the IP address is 4 octets for an IPv4 address 262 and 16 octets for an IPv6 address; the port numbers are encoded in 263 network byte-order. A RANDOM value is included to prevent pre- 264 computation attacks. The puzzle mechanism could be used for this 265 purpose. 267 The UDP-REA parameter is zero-padded to 8 bytes. The length field 268 contains the length of the payload without padding. 270 3.3. S-UDP-REA parameter 272 This section defines the S-UDP-REA parameter, the secure version of 273 the UDP-REA parameter. An end host might be able to retrieve address 274 information securely using some protocols, such as MIDCOM or the NSIS 275 NATFW NSLP. These protocols enable the PATH client to create and 276 retrieve a NAT binding in a secure fashion. This information is then 277 communicated from the PATH client to the PATH server experiencing 278 integrity protection, thus it is called secured UDP-REA (S-UDP-REA). 279 Furthermore, when there is a stateful packet filter firewall along 280 the path, S-UDP-REA may be used to allow UDP encapsulation. UDP-REA 281 Section 3.2 would not be able to detect or act accordingly in such a 282 situation. 284 0 1 2 3 285 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 286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 287 | Type | Length | 288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 289 | Address Lifetime | Reserved |T| 290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 291 | Source Port | Destination Port | 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 ~ Source Address ~ 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 ~ Destination Address ~ 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 ~ Padding ~ 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 Type (2 bytes): 301 This parameter has the value of TBD. 303 Length (2 bytes) 304 Represents the length in octets, 305 excluding Type, Length and Padding. 307 Address Lifetime (2 bytes): 308 This field represents the address lifetime, in seconds. 310 Type (T) Flag (1 bit): 311 If this bit is set to 1 then the values in the Address 312 fields are IPv6 addresses otherwise a IPv4 addresses. 314 Source Port (2 bytes): 315 This field contains the source port. 317 Destination Port (2 bytes): 318 This field contains the destination port. 320 Source Address (4 or 16 bytes): 321 This field contains either an IPv4 or an IPv6 address. 323 Destination Address (4 or 16 bytes): 324 This field contains either an IPv4 or an IPv6 address. 326 Padding (variable): 327 Padding information following the HASH value. 329 4. Message Handling Rules 331 The PATH client attaches the UDP-REA payload to indicate support for 332 legacy NAT traversal. Thereby it generates a hash value over the 333 source IP address, source port, destination IP and destination port 334 from the IP header of the HIP message. When the HIP message 335 traverses a NAT along the path between the client and the server, its 336 IP header will be modified. When the server receives the HIP 337 message, it will compare the hash value carried in the HASH field of 338 the UDP-REA parameter and the value computed on the IP address header 339 information. If the two values do not match, then the server 340 determines that someone along the path modified the IP header (and 341 hopefully it is a NAT but not an adversary). The server will then 342 use the information in the IP header to return a response to the 343 client. If the two values are equal then it is assumed that no NAT 344 is located along the path and UDP encapsulation is not necessary. 346 If a PATH client is able to obtain S-UDP-REA related information, the 347 S-UDP-REA parameter in an integrity protected fashion instead of the 348 plain UDP-REA should be used. This offers better security and 349 additional capability of traversing firewalls. 351 This section provides further information on the message handling. 353 o Checksum and length field are provided in the UDP header and might 354 not need to be repeated in the HIP header. 356 o HIP version (either normal or secured) is determined by the used 357 destination port when sending the I1 packet. 359 o The digital signature and the keyed message digest is computed 360 over the original payload. First, a "normal" HIP packet is 361 constructed, then the HMAC and the digital signatures are 362 computed. Afterwards the HIP packet is encapsulated into the UDP 363 format. 365 o Short timeout (e.g., 200ms) after first packet and therefore 366 encourage NAT-less operation. 368 o If preferred source address is in RFC 1918 address space, then I1 369 is UDP encapsulated. 371 5. Examples 373 5.1. HIP Initiator behind a NAT 375 This figure shows the usage of the UDP-REA parameter by the Initiator 376 and the Responder to detect the presence of a NAT along the path. In 377 this example, we assume the HIP Initiator is behind a NAT and the HIP 378 Initiator initially starts with UDP encapsulation. 380 Private Public 381 Network Network 382 HIP Network Address HIP 383 Initiator Translator Responder 384 | | | 385 | I1: Trigger exchange | I1: Trigger exchange | 386 | over UDP | over UDP | 387 | --------------------------> | --------------------------> | 388 | | | 389 | R1: {Puzzle,DH(R),HI(R) | R1: {Puzzle,DH(R),HI(R) | 390 | HIP Transform}SIG | HIP Transform}SIG | 391 | UDP-REA(R) | UDP-REA(R) | 392 | <-------------------------- | <-------------------------- | 393 | | | 394 | I2: {Solution,DH(I), | I2: {Solution,DH(I), | 395 | HIP Transform | HIP Transform | 396 | {H(I)},CERT(I)}SIG | {H(I)},CERT(I)}SIG | 397 | UDP-REA(I) | UDP-REA(I) | 398 | --------------------------> | --------------------------> | 399 | | | 400 | R2: {HMAC}SIG | R2: {HMAC}SIG | 401 | <-------------------------- | <-------------------------- | 402 | | | 404 Figure 3: HIP Initiation behind a NAT: Message Flow 406 5.2. PATH Server Registration and Keep Alive 408 This section illustrates the message exchange for a PATH client 409 registering with a PATH server, as introduced with [15]. After the 410 protocol exchange is finalized, both peers are mutually authenticated 411 and authorized by each other and a security association for HIP has 412 been established. 414 When the PATH client starts to interact with the PATH server, the 415 client can detect the presence of the legacy NAT along the path, by 416 including UDP-REA parameter in the registration messages and making 417 the computation in the client and server. 419 Figure 4 shows such a message exchange. 421 Private Public 422 Network Network 423 PATH Network Address PATH 424 Client Translator Server 425 | | | 426 | | | 427 | I1: Trigger exchange | I1: Trigger exchange | 428 | over UDP | over UDP | 429 | --------------------------> | --------------------------> | 430 | | | 431 | R1: {Puzzle,DH(R),HI(R) | R1: {Puzzle,DH(R),HI(R) | 432 | HIP Transform}SIG | HIP Transform}SIG | 433 | UDP_REA(R), REG_INFO | UDP_REA(R), REG_INFO | 434 | <-------------------------- | <-------------------------- | 435 | | | 436 | I2: {Solution,DH(I), | I2: {Solution,DH(I), | 437 | HIP Transform | HIP Transform | 438 | {H(I)},CERT(I)}SIG | {H(I)},CERT(I)}SIG | 439 | UDP_REA(I), REG_REQ | UDP_REA(I), REG_REQ | 440 | --------------------------> | --------------------------> | 441 | | | 442 | R2: {HMAC}SIG, REG_RESP | R2: {HMAC}SIG, REG_RESP | 443 | <-------------------------- | <-------------------------- | 444 | | | 445 | | | 447 Figure 4: Registration Protocol Message Flow 449 Here, the HIP Registration messages are extended to not only carry 450 REG_INFO (in the R1 message), REG_REQ (in the I2 message), REG_RESP 451 (in the R2 message) and HIP_SIGNATURE, but also contain UDP_REQ for 452 the detection of NATs and behaving properly. 454 Note that this protocol exchange implicitly indicates that the PATH 455 client will use the source IP address of the I1 and I2 messages as 456 the preferred address when it needs to send out packets. The PATH 457 server will use the source IP address of the incoming packet as the 458 preferred address even though it was not authenticated (i.e., 459 integrity protected). This extended HIP registration protocol, which 460 comprises a 4-way message exchange including a return routability 461 test, ensures that the PATH server can reach the PATH client and that 462 the message has not been crafted by an off-path adversary. 464 5.3. Message flow for data receiver behind a NAT 466 This section shows two approaches for a message flow where one HIP 467 node acting as the data receiver is behind a NAT. The registration 468 with the PATH server is not shown in the figure. Figure 5 only shows 469 the HIP base exchange between the HIP Initiator and the HIP Responder 470 interacting with the PATH server. Figure 5 shows such a protocol 471 exchange taken from [2]. 473 Figure 5 shows that the HIP base exchange between the HIP Initiator 474 and the PATH server does not use UDP encapsulation. UDP 475 encapsulation for HIP signaling messages and for the IPsec data 476 traffic is only enabled between the PATH server and the HIP Responder 477 which is enabled with this extension to the HIP registration 478 protocol. Note that IPsec data traffic will traverse the PATH server 479 to experience UDP encapsulation. The main advantage of this approach 480 is two-fold: (1) the HIP Initiator does not need to support the 481 extension defined in this document and (2) traversal of more 482 restrictive NATs can be supported when the PATH server also changes 483 IP address information. 485 Public Private 486 Network Network 487 HIP PATH Network Address HIP 488 Initiator Server Translator Responder 489 | | | | 490 | I1 over IP | | | 491 | ----------------> | I1 over UDP | I1 over UDP | 492 | | ----------------> | ----------------> | 493 | | | | 494 | | R1 over UDP | R1 over UDP | 495 | R1 over IP | with UDP-REA | with UDP-REA | 496 | without UDP-REA | <---------------- | <---------------- | 497 | <---------------- | | | 498 | | | | 499 | I2 over IP | | | 500 | without UDP-REA | I2 over UDP | I2 over UDP | 501 | ----------------> | without UDP-REA | without UDP-REA | 502 | | ----------------> | ----------------> | 503 | | | | 504 | | R2 over UDP | R2 over UDP | 505 | R2 over IP | <---------------- | <---------------- | 506 | <---------------- | | | 507 | | | | 508 | IPsec ESP | IPsec ESP | IPsec ESP | 509 | <===============> | over UDP | over UDP | 510 | | <================ | ================> | 511 | | | | 512 | | | | 514 Legend: 515 -->: HIP signaling messages 516 ==>: Data traffic 518 Figure 5: Establishing contact (1/3) 520 Figure 6 modifies the message flow described in Figure 5 whereby R2 521 is already sent from the HIP Responder to the HIP Initiator directly. 522 The responder thereby creates the necessary NAT binding at the NAT to 523 potentially allow IPsec protected traffic from the initiator towards 524 the responder to traverse the NAT. IPsec protected data traffic is 525 sent only directly between the HIP Initiator and the HIP Responder. 527 Public Private 528 Network Network 529 HIP PATH Network Address HIP 530 Initiator Server Translator Responder 531 | | | | 532 | I1 over IP | | | 533 | ----------------> | I1 over UDP | I1 over UDP | 534 | | ----------------> | ----------------> | 535 | | | | 536 | | R1 over UDP | R1 over UDP | 537 | R1 over IP | with UDP-REA | with UDP-REA | 538 | with UDP-REA | <---------------- | <---------------- | 539 | <---------------- | | | 540 | | | | 541 | I2 over IP | | | 542 | without UDP-REA | I2 over UDP | I2 over UDP | 543 | ----------------> | without UDP-REA | without UDP-REA | 544 | | ----------------> | ----------------> | 545 | | | | 546 | R2 over UDP | R2 over UDP | R2 over UDP | 547 | <------------------------------------ | <---------------- | 548 | | | | 549 | IPsec ESP | IPsec ESP | IPsec ESP | 550 | over UDP | over UDP | over UDP | 551 | <==================================== | ================> | 552 | | | | 553 | | | | 555 Legend: 556 -->: HIP signaling messages 557 ==>: Data traffic 559 Figure 6: Establishing contact (2/3) 561 Sending the IPsec protected data traffic via the PATH server is 562 useful if a NAT is very restrictive. This method also addresses 563 privacy and denial of service issues as raised in the rendezvous 564 server discussion. As symmetrical NATs are rare and an additional 565 proxy host should be avoided, the second approach is recommended as 566 the default method. The selection of the approach is a policy 567 decision. 569 5.4. Mobility and multihoming message flow 571 After the PATH client has registered itself to the PATH server, as 572 described in Figure 4, the PATH client might roam within a network or 573 roam outside a network. Whenever the PATH client obtains a new IP 574 address (either due to mobility, IP address reconfiguration or 575 switching of interfaces), a UPDATE (containing UDP-REA) message will 576 be sent towards the PATH server to update the stored IP address 577 information. Note that the initial registration procedure might be 578 executed without a NAT along the path. Hence, the messages may be 579 carried over IP and do not require UDP encapsulation. When the PATH 580 client roams to a new network, UDP encapsulation should be used to 581 detect the presence of a NAT. Hence, it is required to have the 582 capability to enable UDP encapsulation for the HIP base exchange (and 583 for the IPsec protected data traffic) in addition to the registration 584 messages. 586 Figure 7 shows such a protocol exchange which ensembles the work in 587 [2] but applies it in the PATH/RVS registration. Note UPP_REA is 588 used for NAT traversal. 590 Private Public 591 Network Network 592 PATH Network Address PATH 593 Client Translator Server 594 | | | 595 | UPDATE(UDP_REA(S), SEQ) | UPDATE(UDP_REA(S), SEQ) | 596 | over UDP | over UDP | 597 | --------------------------> | --------------------------> | 598 | | | 599 | UPDATE(UDP_REA(C), SPI, SEQ,| UPDATE(UDP_REA(C), SPI, SEQ,| 600 | ACK, ECHO_REQUEST) | ACK, ECHO_REQUEST) | 601 | <-------------------------- | <-------------------------- | 602 | | | 603 | UPDATE(ACK, ECHO_RESPONSE) | UPDATE(ACK, ECHO_RESPONSE) | 604 | --------------------------> | --------------------------> | 605 | | | 606 | | | 608 Figure 7: Mobility Message Flow 610 Further issues with mobility and multihoming are being investigated 611 and will be detailed in next versions of the document. 613 6. New Requirements for IPsec 615 The text in this section focuses on Dynamic UDP Encapsulation for 616 IPsec. By dynamic UDP encapsulation we mean UDP encapsulation per 617 security association. Before describing the approach we describe 618 some of the scenarios where dynamic UDP encapsulation is needed. 620 6.1. Association with server inside/outside NAT 622 The association of a client with a server outside NAT should have UDP 623 encapsulation on while an association with a server within the same 624 NAT should normal HIP association without any UDP encapsulation. 625 This identification is done during base exchange. Dynamic UDP 626 encapsulation based on security association could achieve this. 628 Figure 8 shows difference in association between different servers. 630 Private Public 631 Network Network 632 PATH PATH Network Address PATH 633 Server Client Translator Server 634 | | | | 635 | HIP association | HIP association | | 636 | No UDP encapsulation | UDP encapsulated | | 637 |<-----------------------| ------------------------------------>| 638 | | | | 640 Figure 8: Dynamic NAT Associations 642 6.2. Mobility Scenarios 644 If a HIP client moves from behind the NAT to outside it then it would 645 not need any more UDP encapsulation as it can have an HIP association 646 without any UDP encapsulation. So when the client moves out of NAT 647 it should reset all the NAT variables that are in security 648 associations. 650 To achieve dynamic UDP encapsulation for Legacy NAT traversal we need 651 to define it per Security Association basis. The SA would contain an 652 indicator which would indicate whether or not the particular HIP 653 association needs UDP encapsulation or not. By default this 654 indicator would be off. During base exchange if NAT is detected on 655 the way then this indicator should be turned on. The UDP 656 encapsulation in the kernel should also be based on this variable. 658 7. Security Considerations 660 Currently this text in this section focuses on the attacks between 661 the PATH client and the PATH server since they differ from the 662 description of threats provided in the past about NAT traversal for 663 mobility protocols. The latter one have been investigated in context 664 of IKE, IKEv2 and various other protocols and will be summarized in a 665 future version of the document. 667 Attacks on the interaction between the PATH client and the PATH 668 server can be classified as denial of service and might be launched 669 against the PATH server itself, against third parties or against the 670 PATH client. 672 PATH servers create state through the HIP registration protocol. A 673 number of counter-measures are built-in into HIP registration 674 protocol. A PATH server might use the client-puzzle mechanism to 675 prevent a certain degree of DoS attacks. Additionally, it might be 676 reasonable to limit the number of registrations at a PATH server 677 itself. Since the PATH server needs to be discovered somehow it 678 needs to be ensured that some security mechanisms are provided for 679 this procedure. For example, if the PATH server is discovered using 680 DNS SRV records then an attacker can compromise the DNS, it can 681 inject fake records which map a domain name to the IP address of a 682 PATH server run by the attacker. This will allow it to inject fake 683 responses to launch a number of the attacks. This discovery 684 procedure might, however, be part of the HIP Registration protocol. 685 A detailed discussion about the security properties of the HIP 686 registration protocol is outside the scope of this document. Even 687 though the base HIP registration protocol is outside the scope of 688 this document some of its security properties are highly relevant and 689 applicable for this discussion. This document extends the 690 capabilities of the registration protocol that might raise security 691 concerns. This section mostly focuses on the security properties of 692 the UDP-REA parameter and it's semantic. 694 7.1. Third Party Bombing 696 Threat: 698 Third party bombing is also of concern when legacy NAT traversal 699 mechanisms are in place. These attacks have been discovered in 700 the context of Mobile IP and a threat description can be found in 701 [16]. The main problem described in [16] is caused by the missing 702 integrity protection of the IP address communicated from the PATH 703 client to the PATH server. The PATH client cannot protect the IP 704 address (without relying on additional protocol) since a NA(P)T is 705 supposed to change the header's IP address (source, possibly 706 destination IP address and transport protocol identifiers). 707 Instead of using the protected IP address inside the signaling 708 message the PATH server is supposed to use IP header information. 709 An adversary might provide change the IP header address to point 710 to the intended target. Data sent to the PATH server will be send 711 to the target rather than to the true IP address of the client. 713 Countermeasures: 715 To prevent third party bombing, the address provided by the PATH 716 client via the IP header needs to be verified using a return- 717 routability check. This check might either be provided as part of 718 the base exchange (which involves two roundtrips) or as part of 719 the REA message exchange which also provides mechanisms to execute 720 such a test. This return-routability test MUST be performed in 721 order to ensure that this and other attacks can be thwarted. A 722 third party entity cannot respond to any of these HIP messages due 723 to the cryptographic properties of the HIP base protocol and the 724 multi-homing and mobility extensions. 726 7.2. Black hole 728 Threat: 730 This attack again exploits the ability for an adversary to act as 731 a NAT and to modify the IP address information in the header. 732 This information will then be used by the PATH server to sent 733 traffic towards the indicated address. If this address is not 734 used by any entity (and particularly by the legitimate PATH 735 client) then the traffic will be dropped. This attack is a denial 736 of service attack. 738 Countermeasures: 740 This threat can be avoided using the same counter measures as 741 third party bombing. 743 7.3. Man-in-the-middle attack 745 Threat: 747 This attack again requires the adversary to modify the IP header 748 of the HIP registration protocol messages exchanged between the 749 PATH server and the PATH client. Instead of pointing to a black 750 hole or to a third party the adversary provides his address. This 751 allows the adversary to eavesdrop the data traffic. However, in 752 order to launch the attack, the adversary must have already been 753 able to observe packets from the PATH client to the PATH server. 755 In most cases (such as when the attack is launched from an access 756 network), this means that the attacker could already observe 757 packets sent to the client. 759 Countermeasures: 761 It is possible that an adversary modifies the IP address 762 information in such a way that it will receive the all traffic for 763 a particular PATH client. Therefore, it is necessary for the 764 adversary to be along the path to mount the initial attack. This 765 will allow the adversary to eavesdrop both the HIP message 766 exchange and the subsequent data traffic. However, the HIP 767 exchange is a cryptographic protocol which is resistant against 768 these types of attack. The data traffic is IPsec protected and 769 therefore the adversary will gain very little profit from this 770 attack. To make things worse for the adversary, if the PATH 771 client roams and uses the HIP registration protocol or the REA 772 message to update state at the PATH server the adversary needs to 773 be located somewhere along the path where it can observe this 774 exchange and to modify it. As a consequence, this attack is not 775 particular useful for the adversary. 777 The S-UDP-REA parameter does not suffer from the same threats as the 778 UDP-REA parameter since it aims to provide a secure mechanism for the 779 PATH server and the PATH client to communicate addressing 780 information. Still, the PATH server might want to authorize the 781 parameters provided by the PATH client by either executing a return- 782 routability check or by using other techniques (e.g., authorization 783 certificates) to ensure that the PATH client is indeed reachable at 784 the indicated addresses. A malicious PATH client might add wrong 785 addressing information to redirect traffic to a black hole or a third 786 party. This threat has a different degree than the previously 787 discussed threats in the sense that the PATH server will most likely 788 know the identity of the PATH client, if we assume that only 789 authenticated and authorized clients are allowed to use the PATH 790 server. If the PATH server is able to detect the malicious behavior 791 it can act accordingly. 793 Finally, it is necessary to add a remark on the usage of NAT/Firewall 794 signaling protocols in relationship with the S-UDP-REA parameter 795 usage. If the PATH client uses these protocols in an insecure or 796 inadequate way then the envisioned security of the S-UDP-REA 797 parameter is seriously affected. A discussion of the security 798 properties of various NAT/Firewall signaling protocols is outside the 799 scope of the document (in the same way as these protocols are outside 800 the scope of this document). 802 8. IANA Considerations 804 This document extends the HIP registration protocol by defining a new 805 parameter (the UDP-REA and the S-UDP-REA parameter). These 806 parameters need IANA registration: 808 TBD: 810 Changes to the PATH protocol are made through a standards track 811 revision of this specification. This document does not create new 812 IANA registries. 814 9. IAB Considerations 816 The IAB has studied the problem of "Unilateral Self Address Fixing 817 (UNSAF)", which is the general process by which a client attempts to 818 determine its address in another realm on the other side of a NAT 819 through a collaborative protocol reflection mechanism (RFC 3424 820 [17]). PATH is an example of a protocol that performs this type of 821 function. The IAB has mandated that any protocols developed for this 822 purpose document a specific set of considerations. This section 823 meets those requirements. 825 The text in this section heavily borrows from [9]. 827 9.1. Problem Definition 829 From RFC 3424 [17], any UNSAF proposal must provide: 831 Precise definition of a specific, limited-scope problem that is to 832 be solved with the UNSAF proposal. A short term fix should not be 833 generalized to solve other problems; this is why "short term fixes 834 usually aren't". 836 The specific problem being solved by PATH is to provide a means for a 837 PATH client to detect the presence of one or more NATs between it and 838 a PATH server. The purpose of such detection is to determine the 839 need for UDP encapsulation by the PATH server (i.e., rendezvous 840 server). 842 PATH affect both UDP encapsulation of data traffic (which is IPsec 843 protected) and HIP signaling messages. 845 9.2. Exit Strategy 847 From [17], any UNSAF proposal must provide: 849 Description of an exit strategy/transition plan. The better short 850 term fixes are the ones that will naturally see less and less use 851 as the appropriate technology is deployed. 853 PATH comes with its own built in exit strategy. This strategy is the 854 detection operation that is performed as a precursor to the actual 855 UNSAF address-fixing operation. The discovery operation, described 856 in Section 3.2, attempts to discover the existence of, and type of, 857 any NATS between the client and the PATH server. PATH does not aim 858 to detect the type of NAT (due to known deficiencies) and the 859 discovery of the existence of NAT is itself quite robust. As NATs 860 are phased out through the deployment of IPv6, the discovery 861 operation will return immediately with the result that there is no 862 NAT, and no further operations are required. Indeed, the discovery 863 operation itself can be used to help motivate deployment of IPv6; if 864 a user detects a NAT between themselves and the public Internet, they 865 can call up their access provider and complain about it. 867 PATH can also help to facilitate the introduction of MIDCOM or NSIS. 868 As MIDCOM or NSIS-capable NATs are deployed, HIP end hosts will, 869 instead of using UDP-REA, first allocate an address binding using 870 MIDCOM or NSIS and use S-UDP-REA. However, it is a well-known 871 limitation of MIDCOM that it only works when the agent knows the 872 middleboxes through which its traffic will flow. This issue is fixed 873 with the path-coupled approach followed in NSIS. Once bindings have 874 been allocated from those middleboxes, a PATH detection procedure can 875 validate that there are no additional middleboxes on the path from 876 the PATH server to the PATH client. If this is the case, the HIP end 877 host can continue operation using the address bindings allocated from 878 MIDCOM or NSIS. If it is not the case, PATH provides a mechanism for 879 self-address fixing through the remaining MIDCOM or NSIS-unaware 880 middleboxes. Thus, PATH provides a way to help transition to full 881 MIDCOM or NSIS-aware networks. 883 9.3. Brittleness Introduced by PATH 885 From [17], any UNSAF proposal must provide: 887 Discussion of specific issues that may render systems more 888 "brittle". For example, approaches that involve using data at 889 multiple network layers create more dependencies, increase 890 debugging challenges, and make it harder to transition. 892 PATH has its own limitations in several ways: 894 [EDITOR's NOTE: Depending on the signaling flow and the 895 involvement of the PATH server some behavior is assumed by NATs. 896 There could be other types of NATs that are deployed that would 897 not work well with some of the proposed signaling message flows. 898 For some of the message flows the binding acquisition usage of 899 PATH does not work for all NAT types. It will work for any 900 application running across full cone NATs only. For restricted 901 cone and port restricted cone NAT, it may work for some cases. 902 For symmetric NATs, the binding acquisition will not yield a 903 usable address (in case that not all the signaling messages and 904 the entire data traffic is routed through the PATH server). The 905 tight dependency on the specific type of NAT may limit the 906 protocol application scenarios.] 908 PATH assumes that the server exists on the public Internet. If 909 the server is located in another private address realm, the HIP 910 end host may or may not be able to use the established state at 911 the PATH server. This heavily depends on the protocol interaction 912 between the other HIP end host and possibly other PATH servers 913 than are cascaded. 915 The bindings allocated from the NAT need to be continuously 916 refreshed. Since the timeouts for these bindings is 917 implementation specific, the refresh interval cannot easily be 918 determined. When the binding is not being actively used to 919 receive traffic, but to wait for an incoming message, the binding 920 refresh will needlessly consume network bandwidth. 922 The use of the PATH server as an additional network element 923 introduces another point of potential security attack. These 924 attacks are largely prevented by the security measures provided 925 the HIP registration protocol, but not entirely. 927 The use of the PATH server as an additional network element 928 introduces another point of failure. If the client cannot locate 929 a PATH server, or if the server should be unavailable due to 930 failure, no interaction can be performed. 932 The use of PATH to enable UDP encapsulation for IPsec protected 933 data traffic and for HIP messages introduces an additional 934 bandwidth consumption which might be problematic in certain 935 wireless networks. The modified packet forwarding through the 936 PATH server, which might be necessary to ensure traversal of 937 certain NAT types, might represent a non-optimal route and may 938 increase latency for some applications (depending on the location 939 of the PATH server). 941 9.4. Requirements for a Long Term Solution 943 From [17], any UNSAF proposal must provide: 945 Identify requirements for longer term, sound technical solutions - 946 contribute to the process of finding the right longer term 947 solution. 949 Our experience with PATH has led to the following requirements for a 950 long term solution to the NAT problem: 952 Requests for bindings and control of other resources in a NAT need 953 to be explicit. Much of the brittleness in PATH derives from its 954 guessing at the parameters of the NAT, rather than telling the NAT 955 what parameters to use. 957 Control needs to be "in-band". There are far too many scenarios 958 in which the client will not know about the location of 959 middleboxes ahead of time. Instead, control of such boxes needs 960 to occur in-band, traveling along the same path as the data will 961 itself travel. This guarantees that the right set of middleboxes 962 are controlled. NSIS exactly provides a solution for this 963 purpose. Third-party controls are best handled using the MIDCOM 964 framework. 966 Control needs to be limited. Users will need to communicate 967 through NATs which are outside of their administrative control. 968 In order for providers to be willing to deploy NATs which can be 969 controlled by users in different domains, the scope of such 970 controls needs to be extremely limited - typically, allocating a 971 binding to reach the address where the control packets are coming 972 from. 974 Simplicity is paramount. The control protocol will need to be 975 implement in very simple clients. The servers will need to 976 support extremely high loads. The protocol will need to be 977 extremely robust, being the precursor to a host of application 978 protocols. As such, simplicity is key. 980 9.5. Issues with Existing NAPT Boxes 982 From [17], any UNSAF proposal must provide: 984 Discussion of the impact of the noted practical issues with 985 existing, deployed NA(P)Ts and experience reports. 987 Several of the practical issues with PATH involve future proofing - 988 breaking the protocol when new NAT types get deployed. Fortunately, 989 this is not an issue at the current time, since most of the deployed 990 NATs are of the types assumed by PATH. The primary usage PATH has 991 been found in the area of VoIP, to facilitate allocation of addresses 992 for receiving RTP [12] traffic. In that application, the periodic 993 keepalives are provided by the RTP traffic itself. However, several 994 practical problems arise for RTP. First, RTP assumes that RTCP 995 traffic is on a port one higher than the RTP traffic. This pairing 996 property cannot be guaranteed through NATs that are not directly 997 controllable. As a result, RTCP traffic may not be properly 998 received. Protocol extensions to SDP have been proposed which 999 mitigate this by allowing the client to signal a different port for 1000 RTCP [18]. However, there will be interoperability problems for some 1001 time. 1003 For VoIP, silence suppression can cause a gap in the transmission of 1004 RTP packets. This could result in the loss of a binding in the 1005 middle of a call, if that silence period exceeds the binding timeout. 1006 This can be mitigated by sending occasional silence packets to keep 1007 the binding alive. However, the result is additional brittleness; 1008 proper operation depends on the silence suppression algorithm in use, 1009 the usage of a comfort noise codec, the duration of the silence 1010 period, and the binding lifetime in the NAT. 1012 9.6. In Closing 1014 Some of the limitations of PATH are not design flaws. Due to the 1015 properties of HIP, PATH is fairly secure and robust form of legacy 1016 NAT traversal compared to other approach such as STUN. Some 1017 limitations are, however, related to the lack of standardized 1018 behaviors and controls in NATs. The result of this lack of 1019 standardization has been a proliferation of devices whose behavior is 1020 highly unpredictable, extremely variable, and uncontrollable. PATH 1021 does the best it can in such a hostile environment. Ultimately, the 1022 solution is to make the environment less hostile, and to introduce 1023 controls and standardized behaviors into NAT. However, until such 1024 time as that happens, PATH provides a good short term solution given 1025 the terrible conditions under which it is forced to operate. PATH 1026 also offers a long-term solution if NATs are NSIS or MIDCOM aware. 1027 The main benefit is increased secure and a less brittle protocol 1028 operation since the NAT (or even firewalls) can be controlled and 1029 should then behave according to respective middlebox signaling 1030 protocol. Ultimately, NAT boxes might be HIP aware. 1032 10. Acknowledgements 1034 The authors would like to thank Aarthi Nagarajan, Abhinav Pathak, and 1035 Murugaraj Shanmugam for their helpful feedbacks on this document. 1037 The authors would like to specially thank Lars Eggert for his 1038 contribution to previous versions of the draft. 1040 11. Open Issues 1042 Open issues can be found here: 1043 http://www.tschofenig.com:8080/hip-nat/ 1045 12. References 1047 12.1. Normative References 1049 [1] Moskowitz, R., "Host Identity Protocol", draft-ietf-hip-base-05 1050 (work in progress), March 2006. 1052 [2] Nikander, P., "End-Host Mobility and Multihoming with the Host 1053 Identity Protocol", draft-ietf-hip-mm-03 (work in progress), 1054 March 2006. 1056 [3] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) 1057 Rendezvous Extension", draft-ietf-hip-rvs-04 (work in progress), 1058 October 2005. 1060 [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1061 Levels", March 1997. 1063 12.2. Informative References 1065 [5] Aboba, B. and W. Dixon, "IPsec-Network Address Translation 1066 (NAT) Compatibility Requirements", RFC 3715, March 2004. 1068 [6] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. 1069 Stenberg, "UDP Encapsulation of IPsec ESP Packets", RFC 3948, 1070 January 2005. 1072 [7] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, 1073 December 2005. 1075 [8] Melen, J. and P. Nikander, "A Bound End-to-End Tunnel (BEET) 1076 mode for ESP", draft-nikander-esp-beet-mode-05 (work in 1077 progress), February 2006. 1079 [9] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, "STUN 1080 - Simple Traversal of User Datagram Protocol (UDP) Through 1081 Network Address Translators (NATs)", RFC 3489, March 2003. 1083 [10] Rosenberg, J., "Traversal Using Relay NAT (TURN)", 1084 draft-rosenberg-midcom-turn-08 (work in progress), 1085 September 2005. 1087 [11] Stiemerling, M., "NAT/Firewall NSIS Signaling Layer Protocol 1088 (NSLP)", draft-ietf-nsis-nslp-natfw-09 (work in progress), 1089 February 2006. 1091 [12] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 1092 RFC 4306, December 2005. 1094 [13] Kivinen, T., Swander, B., Huttunen, A., and V. Volpe, 1095 "Negotiation of NAT-Traversal in the IKE", RFC 3947, 1096 January 2005. 1098 [14] Tschofenig, H. and M. Shanmugam, "Traversing HIP-aware NATs and 1099 Firewalls: Problem Statement and Requirements", 1100 draft-tschofenig-hiprg-hip-natfw-traversal-03 (work in 1101 progress), October 2005. 1103 [15] Laganier, J., "Host Identity Protocol (HIP) Registration 1104 Extension", draft-ietf-hip-registration-01 (work in progress), 1105 December 2005. 1107 [16] Dupont, F., "A note about 3rd party bombing in Mobile IPv6", 1108 draft-dupont-mipv6-3bombing-03 (work in progress), 1109 December 2005. 1111 [17] Daigle, L. and IAB, "IAB Considerations for UNilateral Self- 1112 Address Fixing (UNSAF) Across Network Address Translation", 1113 RFC 3424, November 2002. 1115 Authors' Addresses 1117 Pekka Nikander 1118 Ericsson Research Nomadic Lab 1119 Hirsalantie 11 1120 Turku FIN FIN-02420 JORVAS 1121 Finland 1123 Phone: +358 9 299 1 1124 Email: pekka.nikander@nomadiclab.com 1126 Hannes Tschofenig 1127 Siemens 1128 Otto-Hahn-Ring 6 1129 Munich, Bavaria 81739 1130 Germany 1132 Email: Hannes.Tschofenig@siemens.com 1133 URI: http://www.tschofenig.com 1135 Xiaoming Fu 1136 University of Goettingen 1137 Institute for Informatics 1138 Lotzestr. 16-18 1139 Goettingen 37083 1140 Germany 1142 Email: fu@cs.uni-goettingen.de 1144 Thomas R. Henderson 1145 The Boeing Company 1146 P.O. Box 3707 1147 Seattle, WA 1148 USA 1150 Email: thomas.r.henderson@boeing.com 1151 Julien Laganier 1152 DoCoMo Communications Laboratories Europe GmbH 1153 DoCoMo Communications Laboratories Europe GmbH 1154 Munich 80687 1155 Germany 1157 Phone: +49 89 56824 231 1158 Email: julien.ietf@laposte.net 1159 URI: http://www.docomolab-euro.com/ 1161 Intellectual Property Statement 1163 The IETF takes no position regarding the validity or scope of any 1164 Intellectual Property Rights or other rights that might be claimed to 1165 pertain to the implementation or use of the technology described in 1166 this document or the extent to which any license under such rights 1167 might or might not be available; nor does it represent that it has 1168 made any independent effort to identify any such rights. Information 1169 on the procedures with respect to rights in RFC documents can be 1170 found in BCP 78 and BCP 79. 1172 Copies of IPR disclosures made to the IETF Secretariat and any 1173 assurances of licenses to be made available, or the result of an 1174 attempt made to obtain a general license or permission for the use of 1175 such proprietary rights by implementers or users of this 1176 specification can be obtained from the IETF on-line IPR repository at 1177 http://www.ietf.org/ipr. 1179 The IETF invites any interested party to bring to its attention any 1180 copyrights, patents or patent applications, or other proprietary 1181 rights that may cover technology that may be required to implement 1182 this standard. Please address the information to the IETF at 1183 ietf-ipr@ietf.org. 1185 Disclaimer of Validity 1187 This document and the information contained herein are provided on an 1188 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1189 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1190 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1191 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1192 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1193 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1195 Copyright Statement 1197 Copyright (C) The Internet Society (2006). This document is subject 1198 to the rights, licenses and restrictions contained in BCP 78, and 1199 except as set forth therein, the authors retain all their rights. 1201 Acknowledgment 1203 Funding for the RFC Editor function is currently provided by the 1204 Internet Society.