idnits 2.17.00 (12 Aug 2021) /tmp/idnits15065/draft-tschofenig-hiprg-hip-natfw-traversal-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 692. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 669. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 676. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 682. ** 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 an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 24, 2005) is 6053 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) == Outdated reference: draft-ietf-hip-esp has been published as RFC 5202 ** Downref: Normative reference to an Experimental draft: draft-ietf-hip-esp (ref. 'I-D.ietf-HIP-esp') == Outdated reference: draft-ietf-hip-base has been published as RFC 5201 ** Downref: Normative reference to an Experimental draft: draft-ietf-hip-base (ref. 'I-D.ietf-hip-base') == Outdated reference: draft-ietf-ipsec-ikev2 has been published as RFC 4306 == Outdated reference: draft-ietf-nsis-nslp-natfw has been published as RFC 5973 == Outdated reference: draft-irtf-hiprg-nat has been published as RFC 5207 -- Obsolete informational reference (is this intentional?): RFC 2401 (Obsoleted by RFC 4301) Summary: 6 errors (**), 0 flaws (~~), 7 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 HIPRG H. Tschofenig 3 Internet-Draft Siemens 4 Expires: April 27, 2006 M. Shanmugam 5 TUHH 6 October 24, 2005 8 Traversing HIP-aware NATs and Firewalls: Problem Statement and 9 Requirements 10 draft-tschofenig-hiprg-hip-natfw-traversal-03.txt 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on April 27, 2006. 37 Copyright Notice 39 Copyright (C) The Internet Society (2005). 41 Abstract 43 The Host Identity Protocol is a signaling protocol which adds another 44 layer to the Internet model and (optionally) establishes IPsec ESP 45 SAs to protect subsequent data traffic. HIP is designed to be a 46 middlebox friendly protocol, it allows the middleboxes (such as NATs 47 and Firewalls) to participate in the base exchange messages in order 48 to learn the flow identifier and thereby, relying the data traffic. 50 Adding authentication and authorization mechanisms can help the 51 middlebox decide which end hosts are allowed to traverse a firewall. 52 This can potentially prevent waste of network resources and limit 53 unwanted traffic. This document gives a problem statement and 54 requirements for HIP-aware middlebox traversal techniques. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5 61 4. Overview of HIP Base Exchange with Middleboxes . . . . . . . . 7 62 4.1. HIP Base Exchange with NAT . . . . . . . . . . . . . . . . 7 63 4.2. HIP Base Exchange with Firewall . . . . . . . . . . . . . 8 64 5. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 10 65 5.1. Same Firewall at Initiator for both outgoing and 66 incoming packets . . . . . . . . . . . . . . . . . . . . . 10 67 5.2. Different Firewalls at Initiator for outgoing and 68 incoming packets . . . . . . . . . . . . . . . . . . . . . 11 69 5.3. Different Firewalls at Initiator and Receiver . . . . . . 12 70 6. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 15 71 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 72 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 17 73 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 74 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 75 10.1. Normative References . . . . . . . . . . . . . . . . . . . 19 76 10.2. Informative References . . . . . . . . . . . . . . . . . . 19 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 78 Intellectual Property and Copyright Statements . . . . . . . . . . 22 80 1. Introduction 82 An IP address serves the dual role of a locator and an identifier for 83 every host on the Internet. Since, the transport layer connections 84 are bound to the IP address, end systems that use IP addresses as 85 identifiers cannot support dynamic changes in the mapping between the 86 identifier and the locator in case of multi-homing and mobility. 88 The Host Identity Protocol (HIP) [I-D.ietf-hip-base] proposes to 89 separate the identifier from the locator by adding an additional 90 layer between the transport layer and the network layer. The 91 transport layer uses a new, mobility-unrelated identifier called as 92 Host Identity Tags (HITs), in place of IP addresses, while the 93 network layer uses conventional IP addresses for routing. IPsec 94 security associations are bound to the HITs and are not modified with 95 IP address changes. In other words, a host despite being mobile or 96 multi-homed can use a single transport layer connection associated to 97 one HIT and multiple IP addresses. 99 The Host Identity Protocol offers also the functionality to establish 100 IPsec ESP SAs which are subsequently used to encrypt data traffic 101 between the two end hosts. HIP is liable to all known 102 incompatibilities of IPsec with middleboxes such as NATs [RFC3022] 103 and firewalls. The problem statement for dealing with legacy NATs is 104 described in [I-D.irtf-hiprg-nat]. The main goal of the draft is to 105 present a problem statement and requirements in order to aim for a 106 NAT/FW traversal solution using the Host Identity Protocol. 108 2. Terminology 110 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 111 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 112 document are to be interpreted as described in [RFC2119]. 114 This draft used the terminology defined in [NATTerminology], 115 [I-D.ietf-hip-base], [I-D.ietf-HIP-esp] and 116 [draft-moskowitz-hip-arch] and [RFC2401]. 118 The term SPI refers to the Security Parameter Index value used in 119 IPsec packets. The initiator selects one SPI(I) that can be found in 120 the ESP_info parameter, which is then used by the responder to create 121 an IPsec packet (ESP packet in this case) for traffic sent to the 122 initiator. The responder selects one SPI(R)(using ESP_info(R) 123 parameter) which is used by the initiator to encrypt all data sent to 124 the responder. 126 Other relevant abbreviations can be found in [I-D.ietf-hip-base] and 127 [I-D.ietf-HIP-esp]. 129 The concept of a flow identifier is described in [RFC4080]. 131 We use the following notation throughout this document: 133 o [x] indicates that x is optional. 135 o {x} indicates that x is encrypted. 137 o y indicates that "x" is encrypted with the key "y". 139 o --> signifies "Initiator to Responder" communication (requests). 141 o <-- signifies "Responder to Initiator" communication (replies). 143 3. Problem Statement 145 This document assumes that the data traffic following the HIP base 146 exchange is IPsec protected using the mechanism described in 147 [I-D.ietf-HIP-esp] for exchanging the IPsec parameters. A future 148 version of this draft might also be extended to support other 149 mechanisms for data traffic protection including no protection at 150 all. 152 Besides the communicating hosts in the Internet, the entities such as 153 NATs and Firewalls play a major role in the event of delivering 154 packets to an appropriate host, and each meant for specific 155 functionality. For instance, NATs are used to combat the IPv4 156 address depletion problem, and Firewalls are erected to protect 157 unsolicited information flowing in and out of a corporate network. 158 NATs use as an flow 159 identifier to identify a particular traffic or connection. Because 160 of this, protocols like IPsec suffers from well-known NAT related 161 problems. The NAT traversal approach described in [RFC3947] and 162 [I-D.ietf-ipsec-ikev2] allows the end hosts to detect one or more 163 NATs in between them and [RFC3948] proposes to use the UDP 164 encapsulation of IPsec ESP packets to traverse NATs. 166 Since HIP uses IPsec protection for the data traffic, the flow 167 identifier takes the shape of a 168 (in order to support smooth traversal of the middleboxes) and the 169 middleboxes should learn this flow id in order to relay the data 170 packets. To achieve this, HIP aims to interact with middleboxes 171 actively whereby these devices need to understand the HIP protocol 172 and they need to be involved in the protocol exchange. HIP also 173 provides a way to deal with legacy NATs, as described in 174 [draft-nikander-hip-path-00.txt]. To support this functionality, it 175 is necessary to provide UDP encapsulation for both HIP signaling and 176 IPsec packets. Legacy NAT traversal does not require NATs to be HIP 177 aware or to understand the HIP message exchange. 179 Even though HIP allows the middleboxes to participate in the base 180 exchange, but scenarios like routing asymmetry poses a serious 181 challenge for the HIP to traverse a middlebox. Section 5 explains 182 some possible scenarios which have routing asymmetry. The inability 183 of HIP to handle routing asymmetry motivates to use an explicit 184 signaling mechanism for the HIP hosts in order to support secure and 185 smooth traversal of the middleboxes. 187 Although HIP is described as a two-party protocol, middle boxes are 188 supposed to intercept these messages in order to learn the flow 189 identifier and to process them correctly. In other words, a multi 190 party protocol is created such that the flow identifier is available 191 to middle boxes between the HIP hosts. To provide proper security, 192 middleboxes should not be subject to denial of service attacks and 193 might want to authenticate or authorize entities which create state. 194 Note that the IPsec SA is unidirectional and therefore two IPsec SAs 195 (with two different SPIs, ESP_info contains the SPI value) have to be 196 established. 198 4. Overview of HIP Base Exchange with Middleboxes 200 This section explains the HIP base exchange together with the 201 middleboxes and describes how the middleboxes behave during the base 202 exchange. 204 4.1. HIP Base Exchange with NAT 206 Figure 1 shows the HIP base exchange traversing a NAT. 208 I1 +-----------+ I1 209 +-------------------->| |----------------------+ 210 | | | | 211 | | | | 212 R1 | Intercept | R1 v 213 +---------+ <-------------| the flow |<---------------- +---------+ 214 |Initiator| I2 | identifer | I2 |Responder| 215 +---------+ ------------->| +---------+ 216 ^ | SPI,ESP> | 217 | | | | 218 | R2 | | R2 | 219 +---------------------| |<----------------------+ 220 +-----------+ 221 NAT 223 Figure 1: NAT and HIP Base Exchange 225 Subsequently, the HIP base exchange is described in more detail. 227 I -> R: I1: Trigger exchange 229 I <- R: R1: {Puzzle, D-H(R), HI(R), ESP Transform, 230 HIP Transform }SIG 232 I -> R: I2: {Solution, LSI(I), ESP_info(I), D-H(I), 233 ESP_Transform, HIP Transform, {H(I)}SK }SIG 235 I <- R: R2: {LSI(R), ESP_info(R), HMAC}SIG 237 A potential responsibility of the NAT, as shown in Figure 1, can be 238 the following 240 o Intercept the signaling messages 242 o Authenticate and authorize the HIP nodes by verifying the 243 signatures. 245 o Process the flow identifier information 247 o Perform actions according to the state machine 249 o Create state based on the content of message I2 with ESP_info(I) 250 and R2 with ESP_info(R). Additionally, it might be necessary to 251 include support for storing the respective HITs and host 252 identities. 254 4.2. HIP Base Exchange with Firewall 256 In case of a firewall traversal, the routing asymmetry needs to be 257 considered i.e., the fact that the messages I1 and I2 do not 258 necessarily traverse the same devices as R1 and R2. The same is true 259 with more complex network topologies with a mixture of NATs and 260 Firewalls. This is an assumption made in the NSIS working group (and 261 therefore also with NAT/Firewall traversal). Pure NAT traversal is 262 therefore simpler to handle in comparison to middlebox traversal 263 which also includes devices such as Firewalls. Figure 3 shows this 264 circumstance graphically: 266 I1 +----------+ I1 267 +--------------------> | Firewall | -----------------------+ 268 | I2 | 1 | I2 | 269 | +-----------------> | | ------------------+ | 270 | | +----------+ v v 271 +---------+ +---------+ 272 |Initiator| |Responder| 273 +---------+ +---------+ 274 ^ ^ R1 +----------+ R1 | | 275 | +------------------ | Firewall | <-------------------+ | 276 | R2 | 2 | R2 | 277 +--------------------- | | <-----------------------+ 278 +----------+ 280 ............... IPsec ESP protected traffic (SPI(R)).........> 281 <.............. IPsec ESP protected traffic (SPI(I)).......... 283 Legend: 284 --- = HIP signaling 285 ... = IPsec protected data traffic 287 Figure 3: Firewall and HIP Base Exchange 289 With one single NAT between the HIP nodes, all messages of the base 290 exchange are forced through it. With firewalls, it becomes obvious 291 that the nice property of a NAT with respect to the symmetric 292 forwarding path is lost and the individual firewalls (Firewall 1 and 293 Firewall 2) are unable to create the necessary firewall pinholes. 294 SPI(I) is exchanged in I2 message (ESP_info(I)) through firewall 1, 295 however firewall 2 only needs it. Similarly firewall 2 needs SPI (R) 296 which is sent in message R2 (ESP_info(I)) through firewall 1. 298 5. Scenarios 300 The following section describes some sample scenarios, in the context 301 of involving middleboxes, to learn the flow identifier: 303 5.1. Same Firewall at Initiator for both outgoing and incoming packets 305 This scenario assumes that the initiator I alone is behind a firewall 306 named FW(I). This firewall is both for the outgoing and incoming 307 packets and hence can look into all the base exchange messages. This 308 scenario is also applicable for NATs as well. This is illustrated in 309 Figure 4 311 FW(I) 312 I1 +-----+ I1 313 +----------> | |--------------------------------------+ 314 | I2 | | I2 | 315 | +-----> | |---------------------------------+ | 316 | | | | | | 317 | | | | v v 318 ---------+ | | +--------+ 319 Initiator| | | |Receiver| 320 ---------+ | | +--------+ 321 ^ ^ | | 322 | | R2 | | R2 | | 323 | +------ | |< --------------------------------+ | 324 | R1 | | R1 | 325 +---------- | |< -------------------------------------+ 326 +-----+ 328 Figure 4: One FW only at initiator end 330 1. I1 packet is sent from the initiator I to receiver R. 332 2. FW(I) forward the packet to the Receiver. 334 3. R sends R1 message with puzzle,D-H key protected with the 335 signature of R. 337 4. FW(I) forward the packet to the Initiator. 339 5. On receiving I2, FW(I) verifies the signature of I and learns the 340 SPI value form the ESP_info parameter and forwards it to the 341 Receiver 343 6. R sends the message R2 to I. 345 7. On receiving R2, FW(I) verifies the signature of R. Accordingly, 346 it earns the SPI value form the ESP_info parameter and forwards 347 it to the Initiator. 349 8. The base exchange continues until complete. Since all messages 350 I1,R1,I2 and R2 traverse through FW(I), it can look into these 351 messages to learn the flow identifier information. 353 5.2. Different Firewalls at Initiator for outgoing and incoming packets 355 This scenario assumes that both the initiator I and the receiver R is 356 situated behind firewalls named FW(I) and FW(R) respectively. FW(I) 357 is for the incoming packets to I and FW(R) is for the incoming 358 packets to R. It is necessary that both the firewalls must learn the 359 flow identifier information and should store the state 360 to forward IPsec protected payload packets. This scenario is 361 illustrated in Figure 5 363 FW(R) 364 I1 +-----+ I1 365 +------------------------>| |--------+ 366 | I2 | | I2 | 367 | +------------------->| |---+ | 368 | | +-----+ | | 369 | | v v 370 +---------+ +--------+ 371 |Initiator| |Receiver| 372 +---------+ FW(I) +--------+ 373 ^ ^ +-----+ | | 374 | | R2 | | R2 | | 375 | +--------| |<--------------+ | 376 | R1 | | R1 | 377 +------------| |<-------------------+ 378 +-----+ 380 Figure 5: End hosts behind FWs 382 1. I1 packet is sent from the initiator I to receiver R. 384 2. FW(R) forwards the packet to the Receiver. 386 3. Then, R sends R1 message with puzzle,D-H key protected with the 387 signature of R. 389 4. FW(I) forward the packet to the Initiator. 391 5. Now, I sends the I2 packet, on receiving I2, FW(R) verifies the 392 signature of I and learns the SPI value form the ESP_info 393 parameter and forwards it to the Receiver 395 6. To complete the base exchange, R sends the message R2 to I. 397 7. On receiving R2, FW(I) verifies the signature of R. Accordingly, 398 it earns the SPI value from the ESP_info parameter and forwards 399 it to the Initiator. 401 Here, the problem with this asymmetric base exchange is that the SPI 402 needed for the FW(I) is sent through the I2 message, which flows 403 through the FW(R) and the SPI needed for for the FW(I) is sent to 404 FW(R). 406 5.3. Different Firewalls at Initiator and Receiver 408 This scenario looks into a more complicated situation. Initiator I 409 is behind multiple firewalls FW1(I) for outgoing packets and FW2(I) 410 and FW3(I) are for incoming packets. Similarly, receiver R is behind 411 FW1(R) and FW2(R) for incoming packets and FW3(R) for outgoing 412 packets. The incoming firewalls are chosen based on the type of the 413 application and the hosts are unaware from which firewall they 414 receive packets. Here, however for our scenario we assume that 415 FW2(R) and FW2(I) are chosen about which also the hosts are unaware 416 of. This scenario is illustrated in Figure 6 417 +-----+ 418 | | 419 |FW1-R| 420 | | 421 +-----+ +-----+ 422 I1 | | I1 +-----+ 423 +------------| | -------------------> | |---------+ 424 | I2 |FW1-I| I2 |FW2-R| | 425 | +-------| | -------------------> | |----+ | 426 | | | | +-----+ | | 427 | | +-----+ v v 428 +---------+ +--------+ 429 |Initiator| |Receiver| 430 +---------+ +--------+ 431 ^ ^ +-----+ 432 | | R2 | | R2 +-----+ | | 433 | +------ |FW2-I| <--------------------| |-----+ | 434 | R1 | | R1 |FW3-R| | 435 +---------- | | <--------------------| |----------+ 436 +-----+ | | 437 +-----+ | | 438 | | +-----+ 439 |FW3-I| 440 | | 441 +-----+ 443 Figure 6: Multiple FWs at initiator's and receiver's end 445 1. I1 packet is sent from the initiator I to receiver R. 447 2. FW1(I) and FW2(R) forwards the packet to the Receiver. 449 3. Then, R sends R1 message with puzzle,D-H key protected with the 450 signature of R. 452 4. Now, FW3(R) and FW2(I) forward the packet to the Initiator. 454 5. Now, the I sends the I2 packet, on receiving I2, FW1(I) and 455 FW2(R) can verify the signature of I and can learn the SPI value 456 from the ESP_info parameter and forward it to the Receiver. 458 6. To complete the base exchange, R sends the message R2 to I. 460 7. On receiving R2, FW3(R) and FW2(I) can verify the signature of R. 461 Accordingly, they learn the SPI value form the ESP_info parameter 462 and forwards it to the Initiator. 464 Here, the problems are : 466 1. With this asymmetric base exchange is that the SPI needed for the 467 Firewall(s) on the receiver side is sent through the I2 message, 468 Which is actually sent through FW1(I) and FW2(R) and the SPI 469 needed for for the Firewall(s) on the Initiator side is sent to 470 FW3(R) and FW2(I). 472 2. When hosts are behind multiple incoming firewalls, there are 473 unable to decide to which firewall they have to inform their SPI 474 values to. 476 3. The second problem is to secure the SPI signalling message from 477 the end host to the FW. Since the end hosts authenticate and 478 authorize to the FW that lets outgoing packets, they share keys 479 only with them. However, as mentioned earlier, they, somehow, 480 need to signal the SPI value to the FW on the other end which 481 forwards incoming packets. 483 6. Requirements 485 In the context of middlebox signaling, a few high-level requirements 486 have to be accomplished: 488 o Add some authentication and authorization capabilities to NAT 489 traversal. Many NAT/Firewall traversal solutions do not allow the 490 end host to interact with the middlebox. As a consequence, some 491 security vulnerabilities are introduced. 493 o Add secure firewall traversal functionality as another type of 494 middlebox signaling by using triplet. as a substitute for the typical < source IP, 496 destination IP, source port, destination port, transport protocol> 497 information. 499 Such a solution for HIP-based middlebox signaling needs to have the 500 following properties: 502 o A HIP-aware NAT/FW MUST be able to authenticate the entity 503 requesting a NAT binding or a firewall pinhole. 505 o A HIP-aware NAT/FW MUST authorize the entity requesting a NAT 506 binding or a firewall pinhole before storing state information. 507 This requirement might be accomplished by identity based 508 authorization or an identity independent authorization mechanism. 510 o A HIP-aware NAT/FW MUST be able to intercept HIP messages in order 511 to extract the flow identifier information and other related 512 information. HIP messages are base exchange messages during 513 context establishment and readdressing messages during IP address 514 changes. A NAT/FW MUST be able to distinguish these messages. 516 o A NAT/FW node MUST NOT introduce new denial of service attacks 517 based on authentication or key management mechanisms. 519 o A potential solution MUST respect the property of some middleboxes 520 which do not allow traffic (data and signaling traffic) to 521 traverse this middlebox without proper authorization. 523 Some requirements are taken from [I-D.ietf-nsis-nslp-natfw]. 525 7. Security Considerations 527 This document analyzes the traversal of HIP-aware middleboxes. A 528 problem statement is given and scenarios are described that lead to a 529 number of requirements. 531 This document therefore lists a number of security aspects throughout 532 the document. Care should be taken when solutions are developed and 533 the security solution must not introduce new vulnerabilities to the 534 middlebox. 536 8. Contributors 538 We would like to thank Aarthi Nagarajan, Vesa Torvinen, Jochen 539 Grimminger and Jukka Ylitalo for their help with initial versions of 540 this document. 542 9. Acknowledgements 544 The authors would like to thank Pekka Nikander, Dieter Gollmann and 545 Thomas Aura for their feedback to this document. 547 This document is a byproduct of the Ambient Networks Project, 548 partially funded by the European Commission under its Sixth Framework 549 Programme. It is provided "as is" and without any express or implied 550 warranties, including, without limitation, the implied warranties of 551 fitness for a particular purpose. The views and conclusions 552 contained herein are those of the authors and should not be 553 interpreted as necessarily representing the official policies or 554 endorsements, either expressed or implied, of the Ambient Networks 555 Project or the European Commission. 557 10. References 559 10.1. Normative References 561 [I-D.ietf-HIP-esp] 562 Moskowitz, R., Nikander, P., and P. Jokela, "Using ESP 563 transport format with HIP", draft-ietf-hip-esp-00 (work in 564 progress), June 2005. 566 [I-D.ietf-hip-base] 567 Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson, 568 "Host Identity Protocol", draft-ietf-hip-base-03 (work in 569 progress), June 2005. 571 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 572 Requirement Levels", March 1997. 574 10.2. Informative References 576 [I-D.ietf-ipsec-ikev2] 577 Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 578 draft-ietf-ipsec-ikev2-17 (work in progress), 579 September 2004. 581 [I-D.ietf-nsis-nslp-natfw] 582 Stiemerling, M., Tschofenig, H., and C. Aoun, "A NAT/ 583 Firewall NSIS Signaling Layer Protocol (NSLP)", 584 draft-ietf-nsis-nslp-natfw-07 (work in progress), 585 July 2005. 587 [I-D.irtf-hiprg-nat] 588 Stiemerling, M., Quittek, J., and L. Eggert, "Middlebox 589 Traversal Issues of Host Identity Protocol (HIP) 590 Communication", draft-irtf-hiprg-nat-00.txt (work in 591 progress) (work in progress), October 2005. 593 [NATTerminology] 594 Srisuresh, P. and M. Holdrege, "IP Network Address 595 Translator (NAT) Terminology and Considerations", Request 596 For Comments RFC 2663, August 1999. 598 [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the 599 Internet Protocol", RFC 2401, November 1998. 601 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 602 Address Translator (Traditional NAT)", RFC 3022, 603 January 2001. 605 [RFC3947] Kivinen, T., A. Huttunen, A., Swander, B., and V. Volpe, 606 "Negotiation of NAT-Traversal in the IKE", RFC 3947, 607 January 2005. 609 [RFC3948] A. Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and 610 M. Stenberg, "UDP Encapsulation of IPsec Packets", 611 RFC 3948, January 2005. 613 [RFC4080] Hancock, R., "Next Steps in Signaling: Framework", 614 RFC 4080, November 2004. 616 [draft-ietf-hip-mm] 617 Henderson (Editor), T., "End-Host Mobility and Multi- 618 Homing with Host Identity Protocol", 619 draft-nikander-hip-mm-02.txt (work in progress) (work in 620 progress), July 2005. 622 [draft-ietf-ipsec-esp-v3-08] 623 Kent, S., "IP Encapsulating Security Payload (ESP)", 624 draft-ietf-ipsec-esp-v3-10 (work in progress) (work in 625 progress), March 2005. 627 [draft-moskowitz-hip-arch] 628 Moskowitz, R. and P. Nikander, "Host Identity Protocol 629 Architecture", draft-ietf-hip-arch-03 (work in progress) 630 (work in progress), August 2005. 632 [draft-nikander-hip-path-00.txt] 633 Nikander, P., Tschofenig, H., Henderson, T., Eggert, L., 634 and J. Laganier, "Preferred Alternatives for Tunnelling 635 HIP (PATH)", draft-nikander-hip-path-00.txt (work in 636 progress) (work in progress), February 2005. 638 [rfc3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 639 Address Translator (Traditional NAT)", Request For 640 Comments RFC 3022, January 2001. 642 Authors' Addresses 644 Hannes Tschofenig 645 Siemens 646 Otto-Hahn-Ring 6 647 Munich, Bayern 81739 648 Germany 650 Email: Hannes.Tschofenig@siemens.com 652 Murugaraj Shanmugam 653 Technical Univeristy Hamburg-Harburg 654 Schwarzenbergstrasse 95 655 Harburg, Hamburg 21073 656 Germany 658 Email: murugaraj.shanmugam@tuhh.de 660 Intellectual Property Statement 662 The IETF takes no position regarding the validity or scope of any 663 Intellectual Property Rights or other rights that might be claimed to 664 pertain to the implementation or use of the technology described in 665 this document or the extent to which any license under such rights 666 might or might not be available; nor does it represent that it has 667 made any independent effort to identify any such rights. Information 668 on the procedures with respect to rights in RFC documents can be 669 found in BCP 78 and BCP 79. 671 Copies of IPR disclosures made to the IETF Secretariat and any 672 assurances of licenses to be made available, or the result of an 673 attempt made to obtain a general license or permission for the use of 674 such proprietary rights by implementers or users of this 675 specification can be obtained from the IETF on-line IPR repository at 676 http://www.ietf.org/ipr. 678 The IETF invites any interested party to bring to its attention any 679 copyrights, patents or patent applications, or other proprietary 680 rights that may cover technology that may be required to implement 681 this standard. Please address the information to the IETF at 682 ietf-ipr@ietf.org. 684 Disclaimer of Validity 686 This document and the information contained herein are provided on an 687 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 688 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 689 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 690 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 691 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 692 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 694 Copyright Statement 696 Copyright (C) The Internet Society (2005). This document is subject 697 to the rights, licenses and restrictions contained in BCP 78, and 698 except as set forth therein, the authors retain all their rights. 700 Acknowledgment 702 Funding for the RFC Editor function is currently provided by the 703 Internet Society.