idnits 2.17.1 draft-nikander-hip-path-00.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.a on line 24. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1119. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1096. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1103. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1109. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** 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. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 179: '...destination port MUST NOT be expected ...' RFC 2119 keyword, line 237: '... It MUST be ensured that the total l...' RFC 2119 keyword, line 662: '... This return-routability test MUST be...' 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 [2], 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 (February 14, 2005) is 7010 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 931, but not defined == Unused Reference: '16' is defined on line 1037, but no explicit reference was found in the text == Outdated reference: A later version (-05) exists of draft-ietf-hip-rvs-00 ** Downref: Normative reference to an Experimental draft: draft-ietf-hip-rvs (ref. '1') -- Possible downref: Non-RFC (?) normative reference: ref. '2' == Outdated reference: A later version (-10) exists of draft-ietf-hip-base-01 ** Downref: Normative reference to an Experimental draft: draft-ietf-hip-base (ref. '3') == Outdated reference: A later version (-05) exists of draft-ietf-hip-mm-00 ** Downref: Normative reference to an Experimental draft: draft-ietf-hip-mm (ref. '4') -- Obsolete informational reference (is this intentional?): RFC 3489 (ref. '7') (Obsoleted by RFC 5389) == Outdated reference: A later version (-08) exists of draft-rosenberg-midcom-turn-06 == Outdated reference: A later version (-25) exists of draft-ietf-nsis-nslp-natfw-04 -- No information found for draft-tschofenig-hiprg-natfw-traversal - is the name correct? == Outdated reference: A later version (-01) exists of draft-koponen-hip-registration-00 == Outdated reference: A later version (-05) exists of draft-dupont-mipv6-3bombing-01 Summary: 10 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: August 18, 2005 H. Tschofenig 5 Siemens 6 T. Henderson 7 The Boeing Company 8 L. Eggert 9 NEC 10 J. Laganier 11 SUN 12 February 14, 2005 14 Preferred Alternatives for Tunnelling HIP (PATH) 15 draft-nikander-hip-path-00.txt 17 Status of this Memo 19 This document is an Internet-Draft and is subject to all provisions 20 of Section 3 of RFC 3667. By submitting this Internet-Draft, each 21 author represents that any applicable patent or other IPR claims of 22 which he or she is aware have been or will be disclosed, and any of 23 which he or she become aware will be disclosed, in accordance with 24 RFC 3668. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that 28 other groups may also distribute working documents as 29 Internet-Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/ietf/1id-abstracts.txt. 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html. 42 This Internet-Draft will expire on August 18, 2005. 44 Copyright Notice 46 Copyright (C) The Internet Society (2005). 48 Abstract 49 With the extensions defined in this document Host Identity Protocol 50 (HIP) can traverse legacy Network Address Translators (NATs) and 51 certain Firewalls. The extension will be useful as part of the base 52 exchange and with the HIP Registration Extension. By using a 53 rendezvous server an additional entity inside the network is 54 utilized, which not only allows but also supports more restrictive 55 NATs to be traversed. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 5 61 3. Protocol Extensions . . . . . . . . . . . . . . . . . . . . 6 62 3.1 UDP Encapsulation of HIP . . . . . . . . . . . . . . . . . 6 63 3.2 UDP-REA parameter . . . . . . . . . . . . . . . . . . . . 6 64 3.3 S-UDP-REA parameter . . . . . . . . . . . . . . . . . . . 8 65 4. Message Handling Rules . . . . . . . . . . . . . . . . . . . 10 66 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 11 67 5.1 HIP Initiator behind a NAT . . . . . . . . . . . . . . . . 11 68 5.2 PATH Server Registration and Keep Alive . . . . . . . . . 11 69 5.3 Message flow for data receiver behind a NAT . . . . . . . 13 70 5.4 Mobility and multihoming message flow . . . . . . . . . . 16 71 6. Security Considerations . . . . . . . . . . . . . . . . . . 18 72 6.1 Third Party Bombing . . . . . . . . . . . . . . . . . . . 18 73 6.2 Black hole . . . . . . . . . . . . . . . . . . . . . . . . 19 74 6.3 Man-in-the-middle attack . . . . . . . . . . . . . . . . . 19 75 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 21 76 8. IAB Considerations . . . . . . . . . . . . . . . . . . . . . 22 77 8.1 Problem Definition . . . . . . . . . . . . . . . . . . . . 22 78 8.2 Exit Strategy . . . . . . . . . . . . . . . . . . . . . . 22 79 8.3 Brittleness Introduced by PATH . . . . . . . . . . . . . . 23 80 8.4 Requirements for a Long Term Solution . . . . . . . . . . 24 81 8.5 Issues with Existing NAPT Boxes . . . . . . . . . . . . . 25 82 8.6 In Closing . . . . . . . . . . . . . . . . . . . . . . . . 25 83 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27 84 10. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . 28 85 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 86 11.1 Normative References . . . . . . . . . . . . . . . . . . 29 87 11.2 Informative References . . . . . . . . . . . . . . . . . 29 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 30 89 Intellectual Property and Copyright Statements . . . . . . . 32 91 1. Introduction 93 This document defines extensions and allows the Host Identity 94 Protocol (HIP) to be used in an environment where legacy NATs or 95 Firewalls are presents. To support this functionality it is 96 necessary to provide 97 o UDP encapsulation for HIP signaling messages 98 o UDP encapsulation for IPsec traffic 99 The problems of IPsec protected traffic and also the problems for a 100 signaling protocol (namely IKEv1) traversing a NA[P]T are well 101 described in [5]. A proposal for UDP encapsulation of IPsec 102 protected traffic is described in [6]. It is possible to design an 103 optimized version of it for usage with HIP. This aspect is, however, 104 outside the scope of this document. 106 This document tries to accomplish the following goals: 107 o Make HIP work through legacy NATs (and possibly through some 108 firewalls) 109 o Make HIP hosts reachable behind NATs 111 By using a rendezvous server an additional entity inside the network 112 is introduced which interacts with the HIP message exchange. The 113 interaction of HIP with the rendezvous server is described in [1]. 114 This allows a complete NAT/Firewall traversal to be accomplished. 115 Two approaches are possible with respect to this rendezvous server 116 concept. 118 o First, it is possible to combine a HIP rendezvous server (i.e., 119 PATH server) and a STUN server [7], TURN server [8] or NSIS NATFW 120 [9] node. The client obviously needs to support the clide part of 121 the protocol as well. The STUN, TURN or NSIS NATFW protocol is 122 used to allow the PATH client to learn the public IP address (and 123 port number) created at the NAT. 124 o Second, the HIP registration protocol can integrate a NAT 125 detection check. NAT-T support is provided by IKEv2 [10] and the 126 corresponding extensions have been designed for IKEv1 (see [5] and 127 [11]). 129 This document uses the later approach to avoid the integration of 130 another protocol and additional message exchanges but does not 131 rule-out the former approach. An integration with STUN and TURN 132 would not add more security to the protocol exchange. To support NAT 133 detection a new parameter UDP-REA is introduced. 135 To also allow the client to inform the server about its public IP 136 address and port in a secure fashion (where this is possible and 137 appropriate) another parameter has been defined S-UDP-REA, a secure 138 version of the UDP-REA parameter. Using this parameter a secure 139 traversal of legacy NATs is supported, for example by interworking 140 with NSIS or MIDCOM. Both, MIDCOM and the NSIS NATFW NSLP provide 141 better security properties. The interaction with these protocols is 142 outside the scope of this document. 144 Please note that this document tries to accomplish a different goal 145 than [12] where middleboxes (such as NATs and firewalls) are assumed 146 to be HIP-aware and participate in the HIP message exchange. As a 147 consequence, the security properties of these protocols are different 148 as well. 150 2. Terminology 152 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 153 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 154 document are to be interpreted as described in [2]. 156 When interaction with a rendezvous server might be possible then we 157 denote these entities as the PATH client and the PATH server 158 traversing some type of legacy NAT. A PATH client is a HIP-aware 159 device which supports the extensions defined in this document in 160 addition to the HIP Registration Extension [13]. The PATH client 161 might be located behind a legacy NAT and initiates the protocol 162 exchange with the PATH server. The PATH server interacts with the 163 client in the way specified in this document. 165 Different types of NATs (e.g., full cone, restricted NAT) are 166 deployed today and [7] assigns these NAT boxes to certain categories 167 based on their data traffic forwarding or blocking behavior. The 168 existence of different NAT types has an impact on the protocol. 170 3. Protocol Extensions 172 This section explains the necessary protocol extensions to support 173 the above-mentioned functionality. 175 3.1 UDP Encapsulation of HIP 177 In order to deal with NA[P]Ts, it is necessary that the HIP signaling 178 messages are UDP encapsulated and moreover the source port and the 179 destination port MUST NOT be expected at a fixed port number. This 180 aspect of NAT traversal is known from IPsec/IKE and also reflected in 181 the design of IKEv2. 183 It is a policy issue whether to enable UDP encapsulation immediately 184 when the first HIP base message is sent (i.e., the I1 message). 186 For IPv4, the packet format is shown in Appendix E of [3]. The same 187 specification states that UDP encapsulation is forbidden for IPv6 but 188 might still be necessary particuarly particularly for IPv4-IPv6 189 transition. 191 3.2 UDP-REA parameter 193 This section defines the UDP-REA parameter which will be used in the 194 traversal of legacy NATs. 196 0 1 2 3 197 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 198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 199 | Type | Length | 200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 201 | Address Lifetime | 202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 203 ~ HASH ~ 204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 ~ Padding ~ 206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 208 Type (2 bytes): 209 This parameter has the value of TBD. 211 Length (2 bytes) 212 Represents the length in octets, 213 excluding Type and Length fields. 215 Address Lifetime (4 bytes): 216 This field represents the address lifetime, in seconds. 218 HASH (variable): 219 This field of variable length contains the hash of 220 IP address and port information. 222 Padding (variable): 223 Padding information following the HASH value 225 The HASH is calculated as follows: 227 HASH = PRF(RANDOM | Source IP | Destination IP | Source Port | 228 Destination Port) 230 using the negotiated hash algorithm (denoted as PRF) as part of the 231 HIP_TRANSFORM payload (see Section 6.2.8 of [3]). The hashed data is 232 in the network byte-order. The IP address is 4 octets for an IPv4 233 address and 16 octets for an IPv6 address. The port number is 234 encoded as a 2 octet number in network byte-order. 236 The necessary padding length depends on the selected hash algorithm. 237 It MUST be ensured that the total length (including padding) of the 238 UDP-REA parameter is 11 + Length - (Length + 3) % 8. 240 The RANDOM value is used to prevent precomputation attacks. The 241 puzzle mechanism could be used for this purpose. 243 3.3 S-UDP-REA parameter 245 This section defines the S-UDP-REA parameter, a secure UDP-REA 246 parameter version. An end host might be able to retrieve address 247 information securely using some protocols, such as MIDCOM or the NSIS 248 NATFW NSLP. These protocols enable the PATH client to create and 249 retrieve a NAT binding in a secure fashion. This information is then 250 communicated from the PATH client to the PATH server experiencing 251 integrity protection. Furthermore, this extension might also be used 252 when a stateful packet filtering firewall is known to be along the 253 path which requires UDP encapsulation in order to perform properly. 254 UDP-REA Section 3.2 would not be able to detect or act accordingly in 255 such a situation. 257 0 1 2 3 258 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 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 260 | Type | Length | 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 262 | Address Lifetime |T| 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 | Source Port | Destination Port | 265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 266 ~ Source Address ~ 267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 268 ~ Destination Address ~ 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 271 Type (2 bytes): 272 This parameter has the value of TBD. 274 Length (2 bytes) 275 Represents the length in octets, 276 excluding Type and Length fields. 278 Address Lifetime (4 bytes): 279 This field represents the address lifetime, in seconds. 281 Type (T) Flag (1 bit): 282 If this bit is set to 1 then the value in the Address 283 field is an IPv6 address otherwise an IPv4 address. 285 Source Port (2 bytes): 286 This field contains the source port. 288 Destination Port (2 bytes): 289 This field contains the destination port. 291 Source Address (4 or 16 bytes): 292 This field contains either an IPv4 or an IPv6 address. 294 Destination Address (4 or 16 bytes): 295 This field contains either an IPv4 or an IPv6 address. 297 4. Message Handling Rules 299 The PATH client attaches the UDP-REA payload to indicate support for 300 legacy NAT traversal. Thereby it creates a hash value over the 301 source IP address, source port, destination IP and destination port 302 from the IP header of the HIP packet. When the HIP message traverse 303 a NAT along the path between the client and the server, the IP header 304 will be modified. When the server receives the HIP message, it will 305 compare the hash value carried in the HASH field of the UDP-REA 306 parameter and the value computed on the IP address header 307 information. If the two values do not match then the server is 308 assured that someone along the path modified the IP header (and 309 hopefully a NAT and not an adversary). The server will then use the 310 information in the IP header to return a response to the client. If 311 the two values are equal then it is assumed that no NAT is located 312 along the path and UDP encapsulation might not be necessary. 314 This section provides further information on the message handling. 315 o Checksum and length field are provided in the UDP header and might 316 not need to be repeated in the HIP header. 317 o HIP version determined by the destination port used when sending 318 the I1 packet 319 o The digital signature and the keyed message digest is computed 320 over the original payload. First, a "normal" HIP packet is 321 constructed, then the the HMAC and the digital signatures are 322 computed. Afterwards the the HIP packet is encapsulated into the 323 UDP format. 324 o Short timeout (e.g., 200ms) after first packet and therefore 325 encourage NAT-less operation. 326 o If preferred source address is in RFC 1918 address space then send 327 I1 over IP and I1 over UDP a few milliseconds apart. 329 5. Examples 331 5.1 HIP Initiator behind a NAT 333 This figure shows the usage of the UDP-REA parameter by the Initiator 334 and the Responder to detect the presence of a NAT along the path. In 335 this case the HIP Initiator is behind a NAT. In this example, the 336 HIP Initiator is behind a NAT and we assume the HIP Initiator 337 immediately starts with UDP encapsulation. 339 Private Public 340 Addressing Addressing 341 HIP Realm Network Address Realm HIP 342 Initiator Translator Responder 343 | | | 344 | I1: Trigger exchange | I1: Trigger exchange | 345 | over UDP | over UDP | 346 | --------------------------> | --------------------------> | 347 | | | 348 | R1: {Puzzle,DH(R),HI(R) | R1: {Puzzle,DH(R),HI(R) | 349 | HIP Transform}SIG | HIP Transform}SIG | 350 | UDP-REA(R) | UDP-REA(R) | 351 | <-------------------------- | <-------------------------- | 352 | | | 353 | I2: {Solution,DH(I), | I2: {Solution,DH(I), | 354 | HIP Transform | HIP Transform | 355 | {H(I)},CERT(I)}SIG | {H(I)},CERT(I)}SIG | 356 | UDP-REA(I) | UDP-REA(I) | 357 | --------------------------> | --------------------------> | 358 | | | 359 | R2: {HMAC}SIG | R2: {HMAC}SIG | 360 | <-------------------------- | <-------------------------- | 361 | | | 363 Figure 3: HIP Initiation behind a NAT Message Flow 365 5.2 PATH Server Registration and Keep Alive 367 This section illustrates the message exchange for a PATH client 368 registering with a PATH server, as introduced with [13]. After the 369 protocol exchange is finalized both peers will be mutually 370 authenticated and authorized each other and a security association 371 for HIP has been established. 373 When the PATH client starts to interact with the PATH server the 374 client might not be aware of the presence of the legacy NAT along the 375 path. The I1 registration messages will most likely be dropped by 376 the NA[P]T. After some retransmissions the PATH client will switch 377 to an UDP encapsulated registration protocol exchange. 379 Figure 4 shows such a message exchange. 381 PATH Network Address PATH 382 Client Translator Server 383 | | | 384 | I1: Trigger exchange | | 385 | over IP | | 386 | --------------------------> | ...I1 dropped | 387 | | | 388 | ..retransmissions.. | | 389 | --------------------------> | ...I1 dropped | 390 | | | 391 | I1: Trigger exchange | I1: Trigger exchange | 392 | over UDP | over UDP | 393 | --------------------------> | --------------------------> | 394 | | | 395 | R1: {Puzzle,DH(R),HI(R) | R1: {Puzzle,DH(R),HI(R) | 396 | HIP Transform}SIG | HIP Transform}SIG | 397 | <-------------------------- | <-------------------------- | 398 | | | 399 | I2: {Solution,DH(I), | I2: {Solution,DH(I), | 400 | HIP Transform | HIP Transform | 401 | {H(I)},CERT(I)}SIG | {H(I)},CERT(I)}SIG | 402 | --------------------------> | --------------------------> | 403 | | | 404 | R2: {HMAC}SIG | R2: {HMAC}SIG | 405 | <-------------------------- | <-------------------------- | 406 | | | 407 | | | 409 Figure 4: Registration Protocol Message Flow 411 Additional payloads defined with the HIP Registration Extension are: 412 REG_INFO (carried in the R1 message), REQ_REQ (carried in the I2 413 message) and REQ_RESP (carried in the R2 message). These payloads 414 are not shown in the above message exchange. 416 Note that this protocol exchange implicitly indicates that the PATH 417 client will use the source IP address of the I1 and I2 messages as 418 the preferred address. The PATH server will use the source IP 419 address of the incoming packet as the preferred address even though 420 it was not authenticated (i.e., integrity protected). The HIP 421 middlebox registration protocol exchange already ensures that this 422 address is authorized via a return routability test. 424 5.3 Message flow for data receiver behind a NAT 426 This section shows a message flow where one HIP node acting as the 427 data receiver is behind a NAT. The registration with the PATH server 428 is not shown in the figure. Figure 5 only shows the HIP base 429 exchange between the HIP Initiator and the HIP Responder interacting 430 with the PATH server. Figure 5 shows such a protocol exchange taken 431 from [4]. 433 Figure 5 shows that the HIP base exchange between the HIP Initiator 434 and the PATH server does not use UDP encapsulation. UDP 435 encapsulation for HIP signaling messages and for the IPsec data 436 traffic is only enabled between the PATH server and the HIP Responder 437 which is enabled with this extension to the HIP registration 438 protocol. Note that IPsec data traffic will traverse the PATH server 439 to experience UDP encapsulation. The main advantage of this approach 440 is two-fold: (1) the HIP Initiator does not need to support the 441 extension defined in this document and (2) traversal of more 442 restrictive NATs can be supported when the PATH server also changes 443 IP address information 444 HIP PATH Network Address HIP 445 Initiator Server Translator Responder 446 | | | | 447 | I1 over IP | | | 448 | ----------------> | I1 over UDP | I1 over UDP | 449 | | ----------------> | ----------------> | 450 | | | | 451 | | R1 over UDP | R1 over UDP | 452 | R1 over IP | with UDP-REA | with UDP-REA | 453 | without UDP-REA | <---------------- | <---------------- | 454 | <---------------- | | | 455 | | | | 456 | I2 over IP | | | 457 | without UDP-REA | I2 over UDP | I2 over UDP | 458 | ----------------> | without UDP-REA | without UDP-REA | 459 | | ----------------> | ----------------> | 460 | | | | 461 | | R2 over UDP | R2 over UDP | 462 | R2 over IP | <---------------- | <---------------- | 463 | <---------------- | | | 464 | | | | 465 | IPsec ESP | IPsec ESP | IPsec ESP | 466 | <===============> | over UDP | over UDP | 467 | | <================ | ================> | 468 | | | | 469 | | | | 471 Legend: 472 -->: HIP signaling messages 473 ==>: Data traffic 475 Figure 5: Establishing contact (1/3) 477 Figure 6 modifies the message flow described in Figure 5 whereby R2 478 is already sent from the HIP Responder to the HIP Initiator directly. 479 The responder thereby creates the necessary NAT binding at the NAT to 480 potentially allow IPsec protected traffic from the initiator towards 481 the responder to traverse the NAT. IPsec protected data traffic is 482 sent only directly between the HIP Initiator and the HIP Responder. 484 HIP PATH Network Address HIP 485 Initiator Server Translator Responder 486 | | | | 487 | I1 over IP | | | 488 | ----------------> | I1 over UDP | I1 over UDP | 489 | | ----------------> | ----------------> | 490 | | | | 491 | | R1 over UDP | R1 over UDP | 492 | R1 over IP | with UDP-REA | with UDP-REA | 493 | with UDP-REA | <---------------- | <---------------- | 494 | <---------------- | | | 495 | | | | 496 | I2 over IP | | | 497 | without UDP-REA | I2 over UDP | I2 over UDP | 498 | ----------------> | without UDP-REA | without UDP-REA | 499 | | ----------------> | ----------------> | 500 | | | | 501 | R2 over UDP | R2 over UDP | R2 over UDP | 502 | <------------------------------------ | <---------------- | 503 | | | | 504 | IPsec ESP | IPsec ESP | IPsec ESP | 505 | over UDP | over UDP | over UDP | 506 | <==================================== | ================> | 507 | | | | 508 | | | | 510 Figure 6: Establishing contact (2/3) 512 Figure 7 extends Figure 6 further by allowing I2 to be sent directly 513 to the HIP Responder. This is only possible if the NAT forwards 514 packets with a different source IP address and source port than the 515 packets seen from the PATH server towards the HIP Responder. 517 HIP PATH Network Address HIP 518 Initiator Server Translator Responder 519 | | | | 520 | I1 over IP | | | 521 | ----------------> | I1 over UDP | I1 over UDP | 522 | | ----------------> | ----------------> | 523 | | | | 524 | | R1 over UDP | R1 over UDP | 525 | R1 over IP | with UDP-REA | with UDP-REA | 526 | with UDP-REA | <---------------- | <---------------- | 527 | <---------------- | | | 528 | | | | 529 | I2 over UDP | I2 over UDP | I2 over UDP | 530 | with UDP-REA | with UDP-REA | with UDP-REA | 531 | ------------------------------------> | ----------------> | 532 | | | | 533 | R2 over UDP | R2 over UDP | R2 over UDP | 534 | with UDP-REA | with UDP-REA | with UDP-REA | 535 | <------------------------------------ | <---------------- | 536 | | | | 537 | IPsec ESP | IPsec ESP | IPsec ESP | 538 | over UDP | over UDP | over UDP | 539 | <==================================== | ================> | 540 | | | | 541 | | | | 543 Figure 7: Establishing contact (3/3) 545 FOR DISCUSSION: It needs to be decided which approach is the best one 546 and if there are multiple preferred ways how we 547 (a) can detect which approach is applicable and 548 (b) what protocol extensions are required. 549 The answer most likely depends on the types of NATs we are willing to 550 support. For example, sending the IPsec protected data traffic via 551 the PATH server is useful if a NAT is very restrictive but, as a 552 default approach, probably not the best choice -- except if the PATH 553 server is along the path anyway (see discussion about discovery 554 exchange in the HIP registration protocol). Finally, the message 555 flows need to add info about the information conveyed to the end 556 hosts about the public IP address and port of it respective peer. 558 5.4 Mobility and multihoming message flow 560 After the PATH client has registered itself to the PATH server, as 561 described in Figure 4, the PATH client might roam within a network or 562 roam outside a network. Whenever the PATH client obtains a new IP 563 address (either due to mobility, IP address reconfiguration or 564 switching of interfaces) a REA message will be sent towards the PATH 565 server to update the stored IP address information. Note that the 566 initial registration procedure might be executed without a NAT along 567 the path. Hence, the messages are carried over IP and do not require 568 UDP encapsulation. When the PATH client roams to a new network UDP 569 encapsulation might be required due to the presence of a NAT. Hence, 570 it is required to have the capability to enable UDP encapsulation for 571 the HIP exchange (and for the IPsec protected data traffic) not only 572 during the initial protocol exchange. 574 Figure 8 shows such a protocol exchange which is taken from [4]. 576 PATH Network Address PATH 577 Client Translator Server 578 | | | 579 | UPDATE(REA, SEQ) | | 580 | over IP | | 581 | --------------------------> | ...UPDATE/REA dropped | 582 | | | 583 | ..retransmissions.. | | 584 | --------------------------> | ...UPDATE/REA dropped | 585 | | | 586 | UPDATE(REA, SEQ) | UPDATE(REA, SEQ) | 587 | over UDP | over UDP | 588 | --------------------------> | --------------------------> | 589 | | | 590 | UPDATE(SPI, SEQ, | UPDATE(SPI, SEQ, | 591 | ACK, ECHO_REQUEST) | ACK, ECHO_REQUEST) | 592 | <-------------------------- | <-------------------------- | 593 | | | 594 | UPDATE(ACK, ECHO_RESPONSE) | UPDATE(ACK, ECHO_RESPONSE) | 595 | --------------------------> | --------------------------> | 596 | | | 597 | | | 599 Figure 8: Mobility Message Flow 601 6. Security Considerations 603 Currently this text in this section focuses on the attacks between 604 the PATH client and the PATH server since they differ from the 605 description of threats provided in the past about NAT traversal for 606 mobility protocols. The latter one have been investigated in context 607 of IKE, IKEv2 and various other protocols and will be summarized in a 608 future version of the document. 610 Attacks on the interaction between the PATH client and the PATH 611 server can be classified as denial of service and might be launched 612 against the PATH server itself, against third parties or against the 613 PATH client. 615 PATH servers create state through the HIP registration protocol. A 616 number of counter-measures are built-in into HIP registration 617 protocol. A PATH server might use the client-puzzle mechanism to 618 prevent a certain degree of DoS attacks. Additionally, it might be 619 reasonable to limit the number of registrations at a PATH server 620 itself. Since the PATH server needs to be discovered somehow it 621 needs to be ensured that some security mechanisms are provided for 622 this procedure. For example, if the PATH server is discovered using 623 DNS SRV records then an attacker can compromise the DNS, it can 624 inject fake records which map a domain name to the IP address of a 625 PATH server run by the attacker. This will allow it to inject fake 626 responses to launch a number of the attacks. This discovery 627 procedure might, however, be part of the HIP Registration protocol. 628 A detailed discussion about the security properties of the HIP 629 registration protocol is outside the scope of this document. Even 630 though the base HIP registration protocol is outside the scope of 631 this document some of its security properties are highly relevant and 632 applicable for this discussion. This document extends the 633 capabilities of the registration protocol that might raise security 634 concerns. This section mostly focuses on the security properties of 635 the UDP-REA parameter and it's semantic. 637 6.1 Third Party Bombing 639 Threat: 641 Third party bombing is also of concern when legacy NAT traversal 642 mechanisms are in place. These attacks have been discovered in 643 the context of Mobile IP and a threat description can be found in 644 [14]. The main problem described in [14] is caused by the missing 645 integrity protection of the IP address communicated from the PATH 646 client to the PATH server. The PATH client cannot protect the IP 647 address (without relying on additional protocol) since a NA[P]T is 648 supposed to change the header's IP address (source, possibly 649 destination IP address and transport protocol identifiers). 650 Instead of using the protected IP address inside the signaling 651 message the PATH server is supposed to use IP header information. 652 An adversary might provide change the IP header address to point 653 to the intended target. Data sent to the PATH server will be send 654 to the target rather than to the true IP address of the client. 655 Countermeasures: 657 To prevent third party bombing, the address provided by the PATH 658 client via the IP header needs to be verified using a 659 return-routability check. This check might either be provided as 660 part of the base exchange (which involves two roundtrips) or as 661 part of the REA message exchange which also provides mechanisms to 662 execute such a test. This return-routability test MUST be 663 performed in order to ensure that this and other attacks can be 664 thwarted. A third party entity cannot respond to any of these HIP 665 messages due to the cryptographic properties of the HIP base 666 protocol and the multi-homing and mobility extensions. 668 6.2 Black hole 670 Threat: 672 This attack again exploits the ability for an adversary to act as 673 a NAT and to modify the IP address information in the header. 674 This information will then be used by the PATH server to sent 675 traffic towards the indicated address. If this address is not 676 used by any entity (and particularly by the legitimate PATH 677 client) then the traffic will be dropped. This attack is a denial 678 of service attack. 679 Countermeasures: 681 This threat can be avoided using the same counter measures as 682 third party bombing. 684 6.3 Man-in-the-middle attack 686 Threat: 688 This attack again requires the adversary to modify the IP header 689 of the HIP registration protocol messages exchanged between the 690 PATH server and the PATH client. Instead of pointing to a black 691 hole or to a third party the adversary provides his address. This 692 allows the adversary to eavesdrop the data traffic. However, in 693 order to launch the attack, the adversary must have already been 694 able to observe packets from the PATH client to the PATH server. 695 In most cases (such as when the attack is launched from an access 696 network), this means that the attacker could already observe 697 packets sent to the client. 698 Countermeasures: 700 It is possible that an adversary modifies the IP address 701 information in such a way that it will receive the all traffic for 702 a particular PATH client. Therefore, it is necessary for the 703 adversary to be along the path to mount the initial attack. This 704 will allow the adversary to eavesdrop both the HIP message 705 exchange and the subsequent data traffic. However, the HIP 706 exchange is a cryptographic protocol which is resistant against 707 these types of attack. The data traffic is IPsec protected and 708 therefore the adversary will gain very little profit from this 709 attack. To make things worse for the adversary, if the PATH 710 client roams and uses the HIP registration protocol or the REA 711 message to update state at the PATH server the adversary needs to 712 be located somewhere along the path where it can observe this 713 exchange and to modify it. As a consequence, this attack is not 714 particular useful for the adversary. 716 The S-UDP-REA parameter does not suffer from the same threats as the 717 UDP-REA parameter since it aims to provide a secure mechanism for the 718 PATH server and the PATH client to communicate addressing 719 information. Still, the PATH server might want to authorize the 720 parameters provided by the PATH client by either executing a 721 return-routability check or by using other techniques (e.g., 722 authorization certificates) to ensure that the PATH client is indeed 723 reachable at the indicated addresses. A malicious PATH client might 724 add wrong addressing information to redirect traffic to a black hole 725 or a third party. This threat has a different degree than the 726 previously discussed threats in the sense that the PATH server will 727 most likely know the identity of the PATH client, if we assume that 728 only authenticated and authorized clients are allowed to use the PATH 729 server. If the PATH server is able to detect the malicious behavior 730 it can act accordingly. 732 Finally, it is necessary to add a remark on the usage of NAT/Firewall 733 signaling protocols in relationship with the S-UDP-REA parameter 734 usage. If the PATH client uses these protocols in an insecure or 735 inadequate way then the envisioned security of the S-UDP-REA 736 parameter is seriously affected. A discussion of the security 737 properties of various NAT/Firewall signaling protocols is outside the 738 scope of the document (in the same way as these protocols are outside 739 the scope of this document). 741 7. IANA Considerations 743 This document extends the HIP registration protocol by defining a new 744 parameter (the UDP-REA and the S-UDP-REA parameter). These 745 parameters need IANA registration: 747 TBD: 749 Changes to the PATH protocol are made through a standards track 750 revision of this specification. This document does not create new 751 IANA registries. 753 8. IAB Considerations 755 The IAB has studied the problem of "Unilateral Self Address Fixing", 756 which is the general process by which a client attempts to determine 757 its address in another realm on the other side of a NAT through a 758 collaborative protocol reflection mechanism (RFC 3424 [15]). PATH is 759 an example of a protocol that performs this type of function. The 760 IAB has mandated that any protocols developed for this purpose 761 document a specific set of considerations. This section meets those 762 requirements. 764 The text in this section heavily borrows from [7]. 766 8.1 Problem Definition 768 From RFC 3424 [15], any UNSAF proposal must provide: 770 Precise definition of a specific, limited-scope problem that is to 771 be solved with the UNSAF proposal. A short term fix should not be 772 generalized to solve other problems; this is why "short term fixes 773 usually aren't". 775 The specific problem being solved by PATH is to provide a means for a 776 PATH client to detect the presence of one or more NATs between it and 777 a PATH server. The purpose of such detection is to determine the 778 need for UDP encapsulation by the PATH server (i.e., rendezvous 779 server). 781 PATH affect both UDP encapsulation of data traffic (which is IPsec 782 protected) and HIP signaling messages. 784 8.2 Exit Strategy 786 From [15], any UNSAF proposal must provide: 788 Description of an exit strategy/transition plan. The better short 789 term fixes are the ones that will naturally see less and less use 790 as the appropriate technology is deployed. 792 PATH comes with its own built in exit strategy. This strategy is the 793 detection operation that is performed as a precursor to the actual 794 UNSAF address-fixing operation. The discovery operation, described 795 in Section 3.2, attempts to discover the existence of, and type of, 796 any NATS between the client and the PATH server. PATH does not aim 797 to detect the type of NAT (due to known deficiencies) and the 798 discovery of the existence of NAT is itself quite robust. As NATs 799 are phased out through the deployment of IPv6, the discovery 800 operation will return immediately with the result that there is no 801 NAT, and no further operations are required. Indeed, the discovery 802 operation itself can be used to help motivate deployment of IPv6; if 803 a user detects a NAT between themselves and the public Internet, they 804 can call up their access provider and complain about it. 806 PATH can also help to facilitate the introduction of MICOM or NSIS. 807 As MIDCOM or NSIS-capable NATs are deployed, HIP end hosts will, 808 instead of using UDP-REA, first allocate an address binding using 809 MIDCOM or NSIS and use S-UDP-REA. However, it is a well-known 810 limitation of MIDCOM that it only works when the agent knows the 811 middleboxes through which its traffic will flow. This issue is fixed 812 with the path-coupled approach followed in NSIS. Once bindings have 813 been allocated from those middleboxes, a PATH detection procedure can 814 validate that there are no additional middleboxes on the path from 815 the PATH server to the PATH client. If this is the case, the HIP end 816 host can continue operation using the address bindings allocated from 817 MIDCOM or NSIS. If it is not the case, PATH provides a mechanism for 818 self-address fixing through the remaining MIDCOM or NSIS-unaware 819 middleboxes. Thus, PATH provides a way to help transition to full 820 MIDCOM or NSIS-aware networks. 822 8.3 Brittleness Introduced by PATH 824 From [15], any UNSAF proposal must provide: 826 Discussion of specific issues that may render systems more 827 "brittle". For example, approaches that involve using data at 828 multiple network layers create more dependencies, increase 829 debugging challenges, and make it harder to transition. 831 PATH introduces brittleness into the system in several ways: 833 [EDITOR's NOTE: Depending on the signaling flow and the 834 involvement of the PATH server some behavior is assumed by NATs. 835 There could be other types of NATs that are deployed that would 836 not work well with some of the proposed signaling message flows. 837 For some of the message flows the binding acquisition usage of 838 PATH does not work for all NAT types. It will work for any 839 application for full cone NATs only. For restricted cone and port 840 restricted cone NAT, it may work for some cases. For symmetric 841 NATs, the binding acquisition will not yield a usable address (in 842 case that not all the signaling messages and the entire data 843 traffic is routed through the PATH server). The tight dependency 844 on the specific type of NAT makes the protocol brittle.] 845 PATH assumes that the server exists on the public Internet. If 846 the server is located in another private address realm, the HIP 847 end host may or may not be able to use the established state at 848 the PATH server. This heavily depends on the protocol interaction 849 between the other HIP end host and possibly other PATH servers 850 than are cascaded. 851 The bindings allocated from the NAT need to be continuously 852 refreshed. Since the timeouts for these bindings is 853 implementation specific, the refresh interval cannot easily be 854 determined. When the binding is not being actively used to 855 receive traffic, but to wait for an incoming message, the binding 856 refresh will needlessly consume network bandwidth. 857 The use of the PATH server as an additional network element 858 introduces another point of potential security attack. These 859 attacks are largely prevented by the security measures provided 860 the HIP registration protocol, but not entirely. 861 The use of the PATH server as an additional network element 862 introduces another point of failure. If the client cannot locate 863 a PATH server, or if the server should be unavailable due to 864 failure, no interaction can be performed. 865 The use of PATH to enable UDP encapsulation for IPsec protected 866 data traffic and for HIP messages introduces an additional 867 bandwidth consumption which might be problematic in certain 868 wireless networks. The modified packet forwarding through the 869 PATH server, which might be necessary to ensure traversal of 870 certain NAT types, might represent a non-optimal route and may 871 increase latency for some applications (depending on the location 872 of the PATH server). 874 8.4 Requirements for a Long Term Solution 876 From [15], any UNSAF proposal must provide: 878 Identify requirements for longer term, sound technical solutions - 879 contribute to the process of finding the right longer term 880 solution. 882 Our experience with PATH has led to the following requirements for a 883 long term solution to the NAT problem: 885 Requests for bindings and control of other resources in a NAT need 886 to be explicit. Much of the brittleness in PATH derives from its 887 guessing at the parameters of the NAT, rather than telling the NAT 888 what parameters to use. 889 Control needs to be "in-band". There are far too many scenarios 890 in which the client will not know about the location of 891 middleboxes ahead of time. Instead, control of such boxes needs 892 to occur in-band, traveling along the same path as the data will 893 itself travel. This guarantees that the right set of middleboxes 894 are controlled. NSIS exactly provides a solution for this 895 purpose. Third-party controls are best handled using the MIDCOM 896 framework. 898 Control needs to be limited. Users will need to communicate 899 through NATs which are outside of their administrative control. 900 In order for providers to be willing to deploy NATs which can be 901 controlled by users in different domains, the scope of such 902 controls needs to be extremely limited - typically, allocating a 903 binding to reach the address where the control packets are coming 904 from. 905 Simplicity is paramount. The control protocol will need to be 906 implement in very simple clients. The servers will need to 907 support extremely high loads. The protocol will need to be 908 extremely robust, being the precursor to a host of application 909 protocols. As such, simplicity is key. 911 8.5 Issues with Existing NAPT Boxes 913 From [15], any UNSAF proposal must provide: 915 Discussion of the impact of the noted practical issues with 916 existing, deployed NA[P]Ts and experience reports. 918 Several of the practical issues with PATH involve future proofing - 919 breaking the protocol when new NAT types get deployed. Fortunately, 920 this is not an issue at the current time, since most of the deployed 921 NATs are of the types assumed by PATH. The primary usage PATH has 922 been found in the area of VoIP, to facilitate allocation of addresses 923 for receiving RTP [12] traffic. In that application, the periodic 924 keepalives are provided by the RTP traffic itself. However, several 925 practical problems arise for RTP. First, RTP assumes that RTCP 926 traffic is on a port one higher than the RTP traffic. This pairing 927 property cannot be guaranteed through NATs that are not directly 928 controllable. As a result, RTCP traffic may not be properly 929 received. Protocol extensions to SDP have been proposed which 930 mitigate this by allowing the client to signal a different port for 931 RTCP [18]. However, there will be interoperability problems for some 932 time. 934 For VoIP, silence suppression can cause a gap in the transmission of 935 RTP packets. This could result in the loss of a binding in the 936 middle of a call, if that silence period exceeds the binding timeout. 937 This can be mitigated by sending occasional silence packets to keep 938 the binding alive. However, the result is additional brittleness; 939 proper operation depends on the silence suppression algorithm in use, 940 the usage of a comfort noise codec, the duration of the silence 941 period, and the binding lifetime in the NAT. 943 8.6 In Closing 945 Some of the limitations of PATH are not design flaws. Due to the 946 properties of HIP, PATH is fairly secure and robust form of legacy 947 NAT traversal compared to other approach such as STUN. Some 948 limitations are, however, related to the lack of standardized 949 behaviors and controls in NATs. The result of this lack of 950 standardization has been a proliferation of devices whose behavior is 951 highly unpredictable, extremely variable, and uncontrollable. PATH 952 does the best it can in such a hostile environment. Ultimately, the 953 solution is to make the environment less hostile, and to introduce 954 controls and standardized behaviors into NAT. However, until such 955 time as that happens, PATH provides a good short term solution given 956 the terrible conditions under which it is forced to operate. PATH 957 also offers a long-term solution if NATs are NSIS or MIDCOM aware. 958 The main benefit is increased secure and a less brittle protocol 959 operation since the NAT (or even firewalls) can be controlled and 960 should then behave according to respective middlebox signaling 961 protocol. Ultimately, NAT boxes might be HIP aware. 963 9. Acknowledgements 965 The authors would like to thank Julien Laganier, Aarthi Nagarajan and 966 Murugaraj Shanmugam for their feedback on this document. 968 10. Open Issues 970 This document is a first attempt in defining HIP NAT/Firewall 971 traversal extensions. The document raises some questions with regard 972 to the usage of the PATH server and the later flow of data packets. 973 The document still lacks a number of details which would benefit from 974 hands-on experience. 976 11. References 978 11.1 Normative References 980 [1] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) 981 Rendezvous Extensions", Internet-Draft draft-ietf-hip-rvs-00, 982 October 2004. 984 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 985 Levels", March 1997. 987 [3] Moskowitz, R., "Host Identity Protocol", 988 Internet-Draft draft-ietf-hip-base-01, October 2004. 990 [4] Nikander, P., "End-Host Mobility and Multi-Homing with Host 991 Identity Protocol", Internet-Draft draft-ietf-hip-mm-00, October 992 2004. 994 11.2 Informative References 996 [5] Aboba, B. and W. Dixon, "IPsec-Network Address Translation 997 (NAT) Compatibility Requirements", RFC 3715, March 2004. 999 [6] Huttunen, A., Swander, B., Volpe, V., DiBurro, L. and M. 1000 Stenberg, "UDP Encapsulation of IPsec ESP Packets", RFC 3948, 1001 January 2005. 1003 [7] Rosenberg, J., Weinberger, J., Huitema, C. and R. Mahy, "STUN - 1004 Simple Traversal of User Datagram Protocol (UDP) Through 1005 Network Address Translators (NATs)", RFC 3489, March 2003. 1007 [8] Rosenberg, J., "Traversal Using Relay NAT (TURN)", 1008 Internet-Draft draft-rosenberg-midcom-turn-06, October 2004. 1010 [9] Stiemerling, M., "A NAT/Firewall NSIS Signaling Layer Protocol 1011 (NSLP)", Internet-Draft draft-ietf-nsis-nslp-natfw-04, October 1012 2004. 1014 [10] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 1015 Internet-Draft draft-ietf-ipsec-ikev2-17, October 2004. 1017 [11] Kivinen, T., "Negotiation of NAT-Traversal in the IKE", 1018 Internet-Draft draft-ietf-ipsec-nat-t-ike-08, February 2004. 1020 [12] Tschofenig, H., Nagarajan, A., Torvinen, V. and J. Ylitalo, 1021 "NAT and Firewall Traversal for HIP", 1022 Internet-Draft draft-tschofenig-hiprg-natfw-traversal-01.txt, 1023 February 2005. 1025 [13] Laganier, J., Koponen, T. and L. Eggert, "A Middlebox 1026 Registration Protocol for HIP", 1027 Internet-Draft draft-koponen-hip-registration-00.txt, February 1028 2005. 1030 [14] Dupont, F., "A note about 3rd party bombing in Mobile IPv6", 1031 Internet-Draft draft-dupont-mipv6-3bombing-01, January 2005. 1033 [15] Daigle, L. and IAB, "IAB Considerations for UNilateral 1034 Self-Address Fixing (UNSAF) Across Network Address 1035 Translation", RFC 3424, November 2002. 1037 [16] Kivinen, T., Swander, B., Huttunen, A. and V. Volpe, 1038 "Negotiation of NAT-Traversal in the IKE", RFC 3947, January 1039 2005. 1041 Authors' Addresses 1043 Pekka Nikander 1044 Ericsson Research Nomadic Lab 1045 Hirsalantie 11 1046 Turku FIN FIN-02420 JORVAS 1047 Finland 1049 Phone: +358 9 299 1 1050 Email: pekka.nikander@nomadiclab.com 1052 Hannes Tschofenig 1053 Siemens 1054 Otto-Hahn-Ring 6 1055 Munich, Bavaria 81739 1056 Germany 1058 Email: Hannes.Tschofenig@siemens.com 1059 URI: http://www.tschofenig.com 1061 Thomas R. Henderson 1062 The Boeing Company 1063 P.O. Box 3707 1064 Seattle, WA 1065 USA 1067 Email: thomas.r.henderson@boeing.com 1068 Lars Eggert 1069 NEC Network Laboratories 1070 Kurfuersten-Anlage 36 1071 Heidelberg 69115 1072 Germany 1074 Phone: +49 6221 90511 43 1075 Email: lars.eggert@netlab.nec.de 1077 Julien Laganier 1078 Sun Labs (Sun Microsystems) and LIP (CNRS/INRIA/ENSL/UCBL) 1079 180, Avenue de l'Europe 1080 Saint Ismier CEDEX 38334 1081 France 1083 Phone: +33 476 188 815 1084 Email: ju@sun.com 1085 URI: http://research.sun.com 1087 Intellectual Property Statement 1089 The IETF takes no position regarding the validity or scope of any 1090 Intellectual Property Rights or other rights that might be claimed to 1091 pertain to the implementation or use of the technology described in 1092 this document or the extent to which any license under such rights 1093 might or might not be available; nor does it represent that it has 1094 made any independent effort to identify any such rights. Information 1095 on the procedures with respect to rights in RFC documents can be 1096 found in BCP 78 and BCP 79. 1098 Copies of IPR disclosures made to the IETF Secretariat and any 1099 assurances of licenses to be made available, or the result of an 1100 attempt made to obtain a general license or permission for the use of 1101 such proprietary rights by implementers or users of this 1102 specification can be obtained from the IETF on-line IPR repository at 1103 http://www.ietf.org/ipr. 1105 The IETF invites any interested party to bring to its attention any 1106 copyrights, patents or patent applications, or other proprietary 1107 rights that may cover technology that may be required to implement 1108 this standard. Please address the information to the IETF at 1109 ietf-ipr@ietf.org. 1111 Disclaimer of Validity 1113 This document and the information contained herein are provided on an 1114 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1115 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1116 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1117 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1118 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1119 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1121 Copyright Statement 1123 Copyright (C) The Internet Society (2005). This document is subject 1124 to the rights, licenses and restrictions contained in BCP 78, and 1125 except as set forth therein, the authors retain all their rights. 1127 Acknowledgment 1129 Funding for the RFC Editor function is currently provided by the 1130 Internet Society.