idnits 2.17.00 (12 Aug 2021) /tmp/idnits19695/draft-tschofenig-hiprg-hip-natfw-traversal-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.a on line 22. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1206. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1183. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1190. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1196. ** 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 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.) ** 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 476: '...HIP-aware NAT/FW MUST be able to authe...' RFC 2119 keyword, line 478: '...HIP-aware NAT/FW MUST authorize the en...' RFC 2119 keyword, line 482: '...HIP-aware NAT/FW MUST be able to inter...' RFC 2119 keyword, line 486: '...anges. A NAT/FW MUST be able to disti...' RFC 2119 keyword, line 487: '...o A NAT/FW node MUST NOT introduce ne...' (1 more instance...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 584 has weird spacing: '...rovided innov...' ** 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 21, 2005) is 6298 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) == Unused Reference: '18' is defined on line 1116, but no explicit reference was found in the text == Unused Reference: '19' is defined on line 1120, but no explicit reference was found in the text == Unused Reference: '20' is defined on line 1124, but no explicit reference was found in the text == Unused Reference: '21' is defined on line 1129, but no explicit reference was found in the text == Outdated reference: draft-ietf-hip-base has been published as RFC 5201 ** Downref: Normative reference to an Experimental draft: draft-ietf-hip-base (ref. '1') -- Possible downref: Non-RFC (?) normative reference: ref. '2' == Outdated reference: A later version (-06) exists of draft-moskowitz-hip-arch-05 -- Obsolete informational reference (is this intentional?): RFC 2401 (ref. '6') (Obsoleted by RFC 4301) == Outdated reference: draft-ietf-nsis-fw has been published as RFC 4080 == Outdated reference: draft-ietf-ipsec-ikev2 has been published as RFC 4306 == Outdated reference: A later version (-01) exists of draft-nikander-hip-path-00 == Outdated reference: draft-ietf-nsis-nslp-natfw has been published as RFC 5973 == Outdated reference: A later version (-01) exists of draft-koponen-hip-registration-00 == Outdated reference: draft-ietf-ipsec-esp-v3 has been published as RFC 4303 -- Duplicate reference: RFC3022, mentioned in '19', was also mentioned in '3'. == Outdated reference: A later version (-02) exists of draft-nikander-hip-mm-01 -- No information found for draft-crocker-multiaddr-analysis - is the name correct? Summary: 9 errors (**), 0 flaws (~~), 16 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 HIPRG H. Tschofenig 3 Internet-Draft A. Nagarajan 4 Expires: August 25, 2005 Siemens 5 V. Torvinen 6 J. Ylitalo 7 Ericsson 8 M. Shanmugam 9 Siemens 10 February 21, 2005 12 NAT and Firewall Traversal for HIP 13 draft-tschofenig-hiprg-hip-natfw-traversal-01.txt 15 Status of this Memo 17 This document is an Internet-Draft and is subject to all provisions 18 of Section 3 of RFC 3667. By submitting this Internet-Draft, each 19 author represents that any applicable patent or other IPR claims of 20 which he or she is aware have been or will be disclosed, and any of 21 which he or she become aware will be disclosed, in accordance with 22 RFC 3668. 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 27 Internet-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 August 25, 2005. 42 Copyright Notice 44 Copyright (C) The Internet Society (2005). 46 Abstract 48 The Host Identity Protocol is a signaling protocol which adds another 49 layer to the Internet model and establishes IPsec ESP SAs to protect 50 subsequent data traffic. HIP also aims to interwork with middleboxes 51 (such as NATs and Firewalls). This document investigates this aspect 52 in more detail. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5 59 4. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 8 60 4.1 Same Firewall at Initiator for both outgoing and 61 incoming packets . . . . . . . . . . . . . . . . . . . . . 8 62 4.2 Different Firewalls at Initiator for outgoing and 63 incoming packets . . . . . . . . . . . . . . . . . . . . . 9 64 4.3 Different Firewalls at Initiator and Receiver . . . . . . 11 65 5. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 66 6. Solution Approach . . . . . . . . . . . . . . . . . . . . . . 15 67 6.1 Flow identifier interception . . . . . . . . . . . . . . . 15 68 6.2 Sender Invariance . . . . . . . . . . . . . . . . . . . . 16 69 6.3 Authentication and Authorization . . . . . . . . . . . . . 17 70 6.3.1 What is SPKI? . . . . . . . . . . . . . . . . . . . . 17 71 6.3.2 SAML Usage in HIP . . . . . . . . . . . . . . . . . . 18 72 6.3.3 SPKI usage for HIP . . . . . . . . . . . . . . . . . . 20 73 6.3.4 Authentication and authorization for Base Exchange . . 20 74 6.3.5 Authentication and authorization for Readdressing . . 24 75 7. Security Considerations . . . . . . . . . . . . . . . . . . . 27 76 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28 77 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 78 9.1 Normative References . . . . . . . . . . . . . . . . . . . 29 79 9.2 Informative References . . . . . . . . . . . . . . . . . . 29 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 30 81 Intellectual Property and Copyright Statements . . . . . . . . 32 83 1. Introduction 85 An IP address serves the dual role of a locator and an identifier for 86 every host on the Internet. End systems that use IP addresses as 87 identifiers cannot support dynamic changes in the mapping between the 88 identifier and the locator in case of multi-homing and mobility. 90 The Host Identity Protocol (HIP) [1] proposes to separate the 91 identifier from the locator by adding an additional layer between the 92 transport layer and the network layer. The transport layer uses a 93 new, mobility-unrelated identifier, Host Identity Tags (HITs), in 94 place of IP addresses, while the network layer uses conventional IP 95 addresses. IPsec security associations are bound to the HITs and are 96 not modified with IP address changes. In other words, a host despite 97 being mobile or multi-homed can use a single transport layer 98 connection associated to one HIT and multiple IP addresses. 100 One of the integral features of HIP protocol is, it establishes IPsec 101 ESP which are subsequently used to encrypt data traffic between the 102 two end hosts. HIP being a mobility protocol also supports changes 103 in IP addresses. Because of this, HIP is liable to all known 104 incompatibilities of IPsec with middleboxes as NATs [3] and 105 firewalls. This draft investigates problems with the HIP protocol 106 when supporting the secure traversal of NATs and Firewalls. 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 [2]. 114 This draft used the terminology defined in [4], [1] and [5] and [6]. 116 The term SPI refers to the Security Parameter Index value used in 117 IPsec packets. The initiator selects one SPI(I) which is then used 118 by the responder to create an IPsec packet (ESP packet in this case) 119 for traffic sent to the initiator. The responder selects one SPI(R) 120 which is used by the initiator to encrypt all data sent to the 121 responder. 123 Other relevant abbreviations can be found in [1]. 125 The concept of a flow identifier is described in [7]. 127 3. Problem Statement 129 This version of the document assumes that the data traffic following 130 the HIP base exchange is IPsec protected. Besides the communicating 131 hosts, the entities such as NATs and Firewalls play a major role to 132 allow the packets to traverse through them. The NAT traversal 133 approach described in [8] and [9] allows the NAT to be detected and 134 IPsec protected packets to experience UDP encapsulation (see also 135 [10] with regard to UDP encapsulation). HIP also provides a way to 136 deal with legacy NATs, as described in [11]. To support this 137 functionality, it is necessary to provide UDP encapsulation for both 138 HIP signaling and IPsec packets. Legacy NAT traversal does not 139 require NATs to be HIP aware or to understand the HIP message 140 exchange. HIP, however, aims to interact with middleboxes actively 141 whereby these devices need to understand the HIP protocol and they 142 need to be involved in the protocol exchange. 144 In the context of middlebox signaling a few goals can be 145 accomplished: 146 o Add some authentication and authorization capabilities to NAT 147 traversal. Many NAT/Firewall traversal solutions do not allow the 148 end host to interact with the middlebox. As a consequence, some 149 security vulnerabilities are introduced. 150 o Add secure firewall traversal functionality as another type of 151 middlebox signaling by using triplet. as a substitute for the typical < source IP, 153 destination IP, source port, destination port, transport protocol> 154 information. 156 The HIP protocol is a signaling protocol that carries (what NSIS 157 calls a flow identifier) inside the signaling protocol payloads. 158 Since HIP uses IPsec ESP to encrypt all its payload messages, the 159 flow identifier takes the shape of a . Although HIP is described as a two-party protocol, middle 161 boxes are supposed to intercept these messages in order to learn the 162 flow identifier and to process them correctly. In other words, a 163 multi party protocol is created such that the flow identifier is 164 available to middle boxes between the HIP hosts. To provide proper 165 security, middleboxes should not be subject to denial of service 166 attacks and might want to authenticate or authorize entities which 167 create state. Note that the IPsec SA is unidirectional and therefore 168 two IPsec SAs (with two different SPIs) have to be established. 170 Figure 1 shows the HIP base exchange traversing a NAT. 172 I1 +-----------+ I1 173 +-------------------->| |----------------------+ 174 | | | | 175 | | | | 176 R1 | Intercept | R1 v 177 +---------+ <-------------| the flow |<---------------- +---------+ 178 |Initiator| I2 | identifer | I2 |Responder| 179 +---------+ ------------->| +---------+ 180 ^ | SPI,ESP> | 181 | | | | 182 | R2 | | R2 | 183 +---------------------| |<----------------------+ 184 +-----------+ 185 NAT 187 Figure 1: NAT and HIP Base Exchange 189 Subsequently, the HIP base exchange is described in more detail. 191 I -> R: I1: Trigger exchange 193 I <- R: R1: {Puzzle, D-H(R), HI(R), ESP Transform, 194 HIP Transform }SIG 196 I -> R: I2: {Solution, LSI(I), SPI(I), D-H(I), 197 ESP Transform, HIP Transform, {H(I)}SK }SIG 199 I <- R: R2: {LSI(R), SPI(R), HMAC}SIG 201 A potential responsibility of the NAT, as shown in Figure 1, can be 202 the following 203 o Intercept the signaling messages 204 o Authenticate and authorize the HIP nodes by verifying the 205 signatures. 206 o Process the flow identifier information 207 o Perform actions according to the state machine 208 o Create state based on the content of message I2 (SPI(I)) and R2 209 (SPI(R)). Additionally, it might be necessary to include support 210 for storing the respective HITs and host identities. 212 If HIP should also consider firewall traversal then the routing 213 asymmetry needs to be looked into and the fact that the messages I1 214 and I2 do not necessarily traverse the same devices as R1 and R2. 215 The same is true with more complex network topologies with a mixture 216 of NATs and Firewalls. This is an assumption made in the NSIS 217 working group (and therefore also with NAT/Firewall traversal). Pure 218 NAT traversal is therefore simpler to handle in comparison to 219 middlebox traversal which also includes devices such as Firewalls. 220 Figure 3 shows this circumstance graphically: 222 I1 +----------+ I1 223 +--------------------> | Firewall | -----------------------+ 224 | I2 | 1 | I2 | 225 | +-----------------> | | ------------------+ | 226 | | +----------+ v v 227 +---------+ +---------+ 228 |Initiator| |Responder| 229 +---------+ +---------+ 230 ^ ^ R1 +----------+ R1 | | 231 | +------------------ | Firewall | <-------------------+ | 232 | R2 | 2 | R2 | 233 +--------------------- | | <-----------------------+ 234 +----------+ 236 ............... IPsec ESP protected traffic (SPI(R)).........> 237 <.............. IPsec ESP protected traffic (SPI(I)).......... 239 Legend: 240 --- = HIP signaling 241 ... = IPsec protected data traffic 243 Figure 3: NAT and HIP Base Exchange 245 With one single NAT between the HIP nodes, all messages of the base 246 exchange are forced through it. With firewalls, it becomes obvious 247 that the nice property of a NAT with respect to the symmetric 248 forwarding path is lost and the individual firewalls (Firewall 1 and 249 Firewall 2) are unable to create the necessary firewall pinholes. 250 SPI(I) is exchanged in I2 message through firewall 1, however 251 firewall 2 only needs it. Similarly firewall 2 needs SPI (R) which 252 is sent in message R2 through firewall 1. 254 4. Scenarios 256 The following section describes some sample scenarios and the 257 possible solutions to learn the flow identifier: 259 4.1 Same Firewall at Initiator for both outgoing and incoming packets 261 This scenario assumes that the initiator I alone is behind a firewall 262 named FW(I). This firewall is both for the outgoing and incoming 263 packets and hence can look into all the base exchange messages. The 264 FW(I) is expected to authenticate and authorize the initiator to send 265 out going packets, receiver if necessary to let incoming packets and 266 intercept the flow identifier from the base exchange. With the E2M 267 messages, it can be achieved as follows. This is illustrated in 268 Figure 4 270 FW(I) 271 I1 +-----+ I1 272 +----------> | |--------------------------------------+ 273 | I2 | | I2 | 274 | +-----> | |---------------------------------+ | 275 | | | | | | 276 | | | | v v 277 ---------+ | | +--------+ 278 Initiator| | | |Receiver| 279 ---------+ | | +--------+ 280 ^ ^ | | 281 | | R2 | | R2 | | 282 | +------ | |< --------------------------------+ | 283 | R1 | | R1 | 284 +---------- | |< -------------------------------------+ 285 +-----+ 287 Figure 4: One FW only at initiator end 289 1. I1 packet is sent from the initiator I to receiver R. 290 2. FW(I) drops the packet and sends a R1' message back to I. This 291 is the End host-to-Middlebox or E2M message exchange initiation. 292 3. I sends I2' message with CERT(I) parameters to FW(I). It 293 requests the FW(I) to open up a pinhole. 294 4. FW verifies SPKI certificate and the signature of I. 295 Accordingly, it either sends a R2' to acknowledge I that it can 296 continue with the base exchange with message I1 or drops packet 297 if verification fails. 298 5. On receiving R2',I sends message I1 to R again. Now the FW(I) 299 will let the packet through. 301 6. R sends the message R1 to I. 302 7. On receiving R1, if FW(I) wishes to authenticate/authorize the 303 receiver R, it should initiate E2M exchange here. It sends 304 message R1'to R forcing R to send an I2' in exchange. 305 8. R sends the CERT(R) parameter in I2'. 306 9. FW verifies SPKI certificate and the signature of R. 307 Accordingly, it either sends a R2' to acknowledge R that it can 308 continue with the base exchange with message R1 or drops packet 309 if verification fails. 310 10. On receiving R2', R sends message R1 to I again. Now the FW(I) 311 will let it through. 312 11. The base exchange continues until complete. Since all messages 313 I1,R1,I2 and R2 traverse through FW(I), it can look into these 314 messages to learn the flow identifier information. 316 4.2 Different Firewalls at Initiator for outgoing and incoming packets 318 This scenario assumes that the initiator I alone is behind firewalls 319 named FW1(I) and FW2(I).FW1(I) is for the incoming packets to I and 320 FW2(I) is for the outgoing packets to R. The FW(I) is expected to 321 authenticate and authorize the initiator to send out going packets, 322 while FW2(I) would authenticate and authorize the receiver, if 323 necessary to let incoming packets. It is sufficient that FW2(I) 324 alone learns the flow identifier information of I. It should store 325 the state to forward IPsec protected payload 326 packets. This scenario is illustrated in Figure 5 327 FW1(I) 328 I1 +-----+ I1 329 +----------> | |--------------------------------------+ 330 | I2 | | I2 | 331 | +-----> | |---------------------------------+ | 332 | | +-----+ | | 333 | | v v 334 +---------+ +--------+ 335 |Initiator| |Receiver| 336 +---------+ FW2(I) +--------+ 337 ^ ^ +-----+ 338 | | R2 | | R2 | | 339 | +------ | |< --------------------------------+ | 340 | R1 | | R1 | 341 +---------- | |< -------------------------------------+ 342 +-----+ 344 Figure 5: Two FWs at initiator's end 346 1. I1 packet is sent from the initiator I to receiver R. 347 2. FW1(I) drops the packet and sends a R1' message back to I. This 348 is the E2M message exchange initiation. 349 3. I sends I2' message with CERT(I) parameters to FW1(I). It 350 requests the FW1(I) to open up a pinhole. 351 4. FW1(I) verifies SPKI certificate and the signature of I. 352 Accordingly, it either sends a R2' to acknowledge I that it can 353 continue with the base exchange with message I1 or drops packet 354 if verification fails. 355 5. On receiving R2',I sends message I1 to R again. Now the FW1(I) 356 will let the packet through. 357 6. R sends the message R1 to I. 358 7. On receiving R1, if FW2(I) wishes to authenticate/authorize the 359 receiver R, it should initiate E2M exchange here. It sends 360 message R1'to R forcing R to send an I2' in exchange. 361 8. R sends the CERT(R) parameter in I2'. 362 9. FW2(I) verifies SPKI certificate and the signature of R. 363 Accordingly, it either sends a R2' to acknowledge R that it can 364 continue with the base exchange with message R1 or drops packet 365 if verification fails. 366 10. On receiving R2', R sends message R1 to I again. Now the FW2(I) 367 will let it through. 368 11. Since FW2(I) needs the store the state, once the base exchange 369 is complete, the initiator should inform the FW2(I) about the 370 SPI it has chosen for the exchange. This way, FW2(I) can 371 forward further IPsec payload packets from R to I 373 4.3 Different Firewalls at Initiator and Receiver 375 This scenario looks into a more complicated situation. Initiator I 376 is behind multiple firewalls FW1(I) for outgoing packets and FW2(I) 377 and FW3(I) are for incoming packets. Similarly, receiver R is behind 378 FW1(R) and FW2(R) for incoming packets and FW3(R) for outgoing 379 packets. The incoming firewalls are chosen based on the type of the 380 application and the hosts are unaware from which firewall they 381 receive packets. Here, however for our scenario we assume that 382 FW2(R) and FW2(I) are chosen about which also the hosts are unaware 383 of. The FW1(I) is expected to authenticate and authorize the 384 initiator to send outgoing packets to R, while FW2(R) would 385 authenticate and authorize the receiver to let outgoing packets to I. 386 FW2(R) should store the state for the receiver 387 while FW2(I) should store the state for the 388 initiator. This scenario is illustrated in Figure 6 389 +-----+ 390 | | 391 |FW1-R| 392 | | 393 +-----+ +-----+ 394 I1 | | I1 +-----+ 395 +------------| | -------------------> | |---------+ 396 | I2 |FW1-I| I2 |FW2-R| | 397 | +-------| | -------------------> | |----+ | 398 | | | | +-----+ | | 399 | | +-----+ v v 400 +---------+ +--------+ 401 |Initiator| |Receiver| 402 +---------+ +--------+ 403 ^ ^ +-----+ 404 | | R2 | | R2 +-----+ | | 405 | +------ |FW2-I| <--------------------| |-----+ | 406 | R1 | | R1 |FW3-R| | 407 +---------- | | <--------------------| |----------+ 408 +-----+ | | 409 +-----+ | | 410 | | +-----+ 411 |FW3-I| 412 | | 413 +-----+ 415 Figure 6: Multiple FWs at initiator's and receiver's end 417 1. I1 packet is sent from the initiator I to receiver R. 418 2. FW1(I) drops the packet and sends a R1' message back to I. This 419 is the E2M message exchange initiation. 420 3. I sends I2' message with CERT(I) parameters to FW1(I). It 421 requests the FW1(I) to open up a pinhole. 422 4. FW1(I) verifies SPKI certificate and the signature of I. 423 Accordingly, it either sends a R2' to acknowledge I that it can 424 continue with the base exchange with message I1 or drops packet 425 if verification fails. 426 5. On receiving R2',I sends message I1 to R again. Now the FW1(I) 427 will let the packet through. 428 6. This packet would reach FW2(R). If this firewall wishes to 429 authenticate and authorize the initiator I, then it can start a 430 E2M exchange with I. After this is successfully completed, 431 FW2(R) would open up a pinhole to send packets to R. 432 7. R sends the message R1 to I. 433 8. When R sends R1 to I, FW3(R) would initiate a E2M message to 434 authenticate and authorize the receiver R. After this is 435 complete, it will forward the packet to the initiator. On 436 receiving R1, if FW2(I) wishes to authenticate/authorize the 437 receiver R, it should initiate E2M exchange here. 438 9. FW2(I) verifies SPKI certificate and the signature of R. 439 Accordingly, it either sends a R2' to acknowledge R that it can 440 continue with the base exchange with message R1 or drops packet 441 if verification fails. 442 10. On receiving R2', R sends message R1 to I again. Now the FW2(I) 443 will let it through. 444 11. This has completed only one round of authentication and 445 authorization. However, the states are still not established at 446 the firewalls. For this, the hosts have to signal their 447 incoming firewalls about the SPI that they have chosen for IPsec 448 ESP packets to follow. 450 When hosts are behind multiple incoming firewalls, there are uble to 451 decide to which firewall they have to inform their SPI values to. 452 The first option would be to somehow make the chosen FW to signal the 453 host about its requirement for a state to forward IPsec protected 454 packets (similar to a pull model). This could be possibly done along 455 with the first incoming packet which is R1. R1 packet could include 456 extra signaling as record route to the initiator. The second option 457 would be to inform firewall about the SPI values (like the push 458 model). Here, however it would be necessary to send an extra message 459 I3 from the initiator to the receiver which would include the SPI(I) 460 for FW(I) and to resend the SPI(R) in I2 message for FW(R). 462 The second problem is to secure the SPI signalling message from the 463 end host to the FW. Since the endhosts authenticate and authorize to 464 the FW that lets outgoing packets, they share keys only with them. 465 However, they need to signal the SPI value to the FW on the other end 466 which forwards incoming packets . For the sake of securing the SPI 467 value, it might be necessary that the end hosts have to run a E2M 468 exchange with the firewalls on the receiving end also. 470 5. Goals 472 The main goal of the draft is to find a suitable NAT/FW traversal 473 solution for the Host Identity Protocol. Such a solution for 474 HIP-based middlebox signaling has to provide the following 475 properties: 476 o A HIP-aware NAT/FW MUST be able to authenticate the entity 477 requesting a NAT binding or a firewall pinhole. 478 o A HIP-aware NAT/FW MUST authorize the entity requesting a NAT 479 binding or a firewall pinhole before storing state information. 480 This requirement might be accomplished by identity based 481 authorization or an identity independent authorization mechanism. 482 o A HIP-aware NAT/FW MUST be able to intercept HIP messages in order 483 to extract the flow identifier information and other related 484 information. HIP messages are base exchange messages during 485 context establishment and readdressing messages during IP address 486 changes. A NAT/FW MUST be able to distinguish these messages. 487 o A NAT/FW node MUST NOT introduce new denial of service attacks 488 based on authentication or key management mechanisms. 489 o A potential solution MUST respect the property of some middleboxes 490 which do not allow traffic (data and signaling traffic) to 491 traverse this middlebox without proper authorization. 493 Some requirements are taken from [12]. 495 6. Solution Approach 497 6.1 Flow identifier interception 499 The most important issue with the HIP NAT/FW traversal is to make the 500 flow identifier available to 501 the middleboxes. In the presence of NATs, we are always sure that 502 the forward path and the backward path are same, since the NAT forces 503 the IP packets to flow through these devices. Hence all the 4 504 messages I1, R1, I2 and R2 traverse through a single NAT. This makes 505 it possible for the NATs to intercept the messages for the relevant 506 flow identifier information. But, in the presence of firewalls, 507 routing asymmetry has to be taken into consideration. 509 To enable the firewalls intercept the correct mapping triplet < dest 510 IP, SPI, ESP > certain values have to be resent with the base 511 exchange messages. This is illustrated in the Figure 7. While the 512 IP value of the flow identifier can be intercepted from the IP header 513 of any base exchange message, the SPI value can be intercepted only 514 in messages I2 and R2. I generates its SPI(I) and sends it to R 515 through FW-R. However, FW-I needs this information to forward all 516 packets from R to I. Therefore there has to be someway FW-I can 517 learn this information. One possible method would be that message R2 518 could include the SPI(I) value. However, changes to the base 519 exchange are not desired and we try to keep the base exchange 520 unaffected. The only other possibility would be that once the base 521 exchange is complete, the HIP host I could inform the FW-I in its 522 domain about its SPI(I) value. Similarly, the receiver R could 523 inform the FW-R local to it about its SPI(R).This way, the firewalls 524 will be able to learn the SPI values needed to create the state. 526 FW-R 527 +-+ 528 1.I1 | | I1 529 -------------------------------------> | |---------> 530 | | 531 FW-I +-+ 532 +-+ 533 2.R1 | | R1 534 <---------| | <------------------------------------ 535 | | 536 +-+ FW-R 537 +-+ 538 3.I2 | | I2 539 -------------------------------------->| |---------> 540 | | 541 FW-I +-+ 542 +-+ 543 4.R2 | | R2 544 <---------| | <------------------------------------ 545 | | 546 +-+ 548 FW-I FW-R 549 +-+ +-+ 550 5.SPI(I) | | | | 5.SPI(R) 551 -------->| | | |<-------- 552 | | | | 553 +-+ +-+ 555 Figure 7: Firewalls and mapping information during Base exchange 557 6.2 Sender Invariance 559 The NAT/Firewall HIP node establishes state at possibly several 560 entities between the HIP Initiator and the HIP Responder. Providing 561 authentication of the signaling initiator to each individual HIP node 562 along the path might be possible but not particularly useful, since 563 the initiator is most likely unknown to some middlebox along the 564 path. Hence, authentication per se does not solve the security 565 problem. 567 With mobility, it might be possible that the intermediate HIP-aware 568 middlebox need some assurance that a particular node is the allowed 569 to modify existing state. No other entity should be allowed to 570 modify state since this would allow certain attacks (such as denial 571 of service or third party flooding). In some respect this issue is 572 similar to the authorization property in Mobile IP where the mobility 573 binding state established at the CN needs to be protected against 574 unauthorized modifications. 576 It seems that the property of "sender Invariance" is required in this 577 case: "A party is assured that the source of the communication has 578 remained the same as the one that started the communication, although 579 the actual identity of the source is not important to the recipient." 581 This property is particularly important in the context of mobility 582 which requires a change in the NAT binding or the packet filter. An 583 outline for solutions have been presented in [13]. SPINAT (see [14] 584 and [15]) provided innovative aspects by using a hash chain approach 585 in combination with delayed authorization to secure state 586 modifications at NAT devices. 588 A future version of this document will address the aspect of sender 589 invariance in more details. 591 6.3 Authentication and Authorization 593 Before a middlebox can allocate a NAT binding or a pin hole, the HIP 594 nodes requesting them may need to be authenticated. Middleboxes 595 could potentially use information stored in the DNS to authenticate 596 the HIP end points. Since Host Identities are used to identify HIP 597 nodes, middleboxes can also use signature verification at relevant 598 HIP messages for authentication. This might raise some issues on 599 denial of service attacks at the middleboxes and these need to be 600 determined. Authorization is certainly more important than 601 authentication particularly since HIP supports ephemeral host 602 identities as a mechanism to preserve privacy. As such it would be 603 useful to use identity independent authorization assertions. SPKI 604 certificates, attribute certificates or similar mechanisms could be 605 of particular use, especially in cases where the HIP nodes prefer to 606 remain anonymous. 608 6.3.1 What is SPKI? 610 SPKI authorization certificates are used in access control and are 611 identity independent. Issuing and receiving an SPKI certificate is 612 completely local to the network domain and there is no need for a 613 higher certification authority to issue them. For a HIP protocol 614 this would mean whenever a HIP host wishes to create a NAT binding or 615 a FW pinhole, it can locally obtain the SPKI certificate for 616 authorization at middleboxes. The structure of the SPKI certificate 617 is shown in Figure 8. 619 +--------+---------+-----------------+ 620 | Key 1 | Key 2 | | 621 | Issuer | Receiver| Can delegate ? | 622 | | | | 623 +--------+---------+-----------------+ 624 | | 625 | Rights | 626 | | 627 +------------------------------------+ 628 | | 629 | Dates |Certificate signed 630 | |by issuer 631 +------------------------------------+ 633 Figure 8: SPKI certificate structure 635 o Key 1 is the public key of the certificate issuer. 636 o Key 2 is the public key of the certificate receiver. 637 o If a subject gets the right to re-delegate its rights, it can 638 re-delegate its certificates to other subjects. In addition, he 639 can freely sign new certificates to other subjects. 640 o Rights define access control of the receiver. 641 o Dates define the validity period of the certificate. 642 o The complete certificate is signed by the private key of the 643 issuer. 645 When a subject wishes to use his certificates, it sends a request 646 that is signed by the subject's private key. Attached are a chain of 647 certificates that belong not only to it but also to those of its 648 delegates. When a verifier receives requests along with a chain of 649 certificates from a subject, the verifier verifies the requests and 650 the certificates. If the verifier is satisfied with the 651 certificates, then the requested operation is allowed. Otherwise, 652 the requests will be refused. 654 6.3.2 SAML Usage in HIP 656 Security Assertion Markup Language (SAML) [16] is an XML extension 657 for security information exchange. It is being developed by OASIS. 658 SAML enables entities to access resources by providing assertions 659 which allow authorization. 661 6.3.2.1 Assertions 663 An Assertion is a package of information including authentication 664 statements, attribute statements and authorization decision 665 statements. All kinds of statements do not have to be present, but 666 at least one. An Assertion contains several elements: 668 Issuing information: 670 Who issued the assertion, when was it issued and the assertion 671 identifier. 673 Subject information: 675 The name of the subject, the security domain and optional subject 676 information, like public key. 678 Conditions under which the assertion is valid: 680 special kind of conditions like assertion validity period, 681 audience restriction and target restriction. 683 Additional advice: 685 explaining how the assertion was made, for example. 687 In an authentication statement, an issuing authority asserts that a 688 certain subject was authenticated by certain means at a certain time. 690 In an attribute statement, an issuing authority asserts that a 691 certain subject is associated with certain attributes which has 692 certain values. For example, user jon@cs.example.com is associated 693 with the attribute 'Department', which has the value 'Computer 694 Science'. 696 In an authorization decision statement, a certain subject with a 697 certain access type to a certain resource has given certain evidence 698 that the identity is correct. Based on this, the relying party then 699 makes the decision on giving access or not. The subject could be a 700 human or a program, the resource could be a webpage or a web service, 701 for example. 703 6.3.2.2 Artifact 705 The Artifact is a base-64 encoded string which is 40 bytes long. 20 706 bytes consists of the typecode, which is the source id. The 707 remaining 20 bytes consists of a 20-byte random number that servers 708 use to look up an assertion. The entity creating an Assertion stores 709 it temporarily. The entity performing the authorization decision 710 uses the received Artifact to retrieve the assertion. The purpose of 711 the Artifact is to act as a token which references an Assertion. 713 SAML also defines a request/response protocol for obtaining 714 Assertions. The request asks for an Assertion or makes queries for 715 authentication, attribute and authorization decisions. The response 716 is carrying back the requested Assertion. The XML format for 717 protocol messages are defined within an XML schema. 719 A HIP-aware NAT/Firewall can use this request/response protocol to 720 fetch assertions from the indicated place. 722 HIP can use SAML Assertions in CER payloads to provide a mechanism 723 for HIP end points to authorize them towards middlebox using an 724 emerging technology. Furthermore, SAML Assertions can be used to 725 bind the authorization decision of different protocols sessions from 726 different layers in the ISO-OSI model together. As an example, the 727 authorization decision by an application layer entity can be used to 728 bind it to a subsequent HIP exchange. SAML provides a complete 729 solution for authorization using Artifacts and Assertions and the 730 corresponding protocols to obtain them. The assertions are based on 731 XML which allows extensibility beyond the initially envisioned 732 deployment area. 734 6.3.3 SPKI usage for HIP 736 HIP has already defined the CERT parameter that can carry 737 certificates. The HIP nodes requesting a NAT/FW traversal can send 738 their base exchange message with the CERT parameter. The CERT will 739 carry the SPKI certificate and the packet will be signed by the 740 requesting HIP node. This would mean, messages I2 and R2 should 741 include the CERT parameter to get them authorized at the middleboxes. 742 The structure of the SPKI certificate for HIP is shown in Figure 9. 744 +------+-------+---------------+ 745 | Key1 |HI(I/R)|Can Delegate? | 746 +------+-------+---------------+ 747 | | 748 | Rights for NAT/FW traversal | 749 +------------------------------+ 750 | | 751 | Date and further info | 752 +------------------------------+ 753 | | 754 | Digital Signature | 755 +------------------------------+ 757 Figure 9: SPKI certificate structure for HIP 759 6.3.4 Authentication and authorization for Base Exchange 761 When a HIP host requests a NAT binding or a FW pinhole, it has to be 762 first authenticated and authorized by the middleboxes. 763 Authentication is necessary in many cases,because, in case of 764 mobility, the middlebox should be authorized to change the flow id 765 and no other party forge the middlebox to change. Since all HIP 766 packets are signed using the private keys of the HIP hosts, 767 middleboxes can verify these packets using the signature 768 verifications. This, of course, will introduce certain kinds of 769 denial of service attacks. Denial of service attacks for signature 770 verification at middleboxes can be prevented by using the client 771 puzzle concept used by the HIP protocol. For more details the HIP 772 protocol [1] can be consulted. This will force the middleboxes to 773 delay state creation and to also delay expensive computational 774 operations. As explained in the previous sections, we seek to use 775 non-identity based authorization mechanisms that can be verified by 776 the middleboxes before creating a NAT binding or FW pinhole. Since 777 NATs force the outbound and inbound packets to flow through them, 778 they are much easier to handle. For instance, the mechanism used by 779 SPINAT [14] can be used for authorization of state modifications by 780 utilizing hash chains and delayed authentication with NATS. However, 781 this is not presently suitable for firewalls with asymmetric paths. 782 More work needs to be done towards extending this idea for a 783 combination of NATs and firewalls with routing asymmetry. 785 A HIP host behind a firewall might need to register itself with local 786 middleboxes before the base exchange can be initiated or completed. 787 Firewalls might not allow the traffic to bypass the firewall. For 788 this, we consider using messages I1',R1',I2' and R2' which are an 789 extended version of the normal base exchange messages used in HIP. 790 However, these messages are exclusively used only for configuring the 791 HIP host with the firewalls such that authentication and 792 authorization is complete before the firewall opens up a pinhole. 793 With this approach, we make fewer changes to the base exchange by 794 avoiding the inclusion of certain authorization parameters into them. 795 We refer to this exchange as 'Registration Procedure', defined in 796 [17], as shown in Figure 10 which provides more details of this 797 lightweight protocol exchange. 799 End host-to-Middlebox or E2M messages 801 I -> R: I1: Trigger exchange 802 OR 803 I -> FW1: I1': Trigger exchange 805 I <- FW1: R1': {Puzzle, D-H(R), HI(R),HIP Transform}SIG 807 I -> FW1: I2': {Solution,D-H(I),HIP Transform,{H(I)},CERT(I)}SIG 809 I <- FW1: R2': {HMAC}SIG 811 Figure 10: HIP NAT/Firewall Registration Procedure 813 As an overview, we modify the HIP exchange protocol to authenticate 814 the middlebox towards the initiator, to authorize (and possibly 815 authenticate) the initiator towards the firewall and to establish a 816 security association between the initiator and the responder. We 817 reuse the HIP protocol for this purpose to use the same 818 infrastructure and to benefit from a lightweight protocol. Note that 819 the message flow in Figure 10 does not establish IPsec security 820 associations. These security associations are not necessary in most 821 scenarios. 823 When a host I wishes to create a pinhole with a FW on its side (named 824 as FW-I), it has two choices: 825 o It sends a regular I1 message to the firewall. This assumes that 826 the end host knows that a firewall is located in the network and 827 additionally the address of this firewall is also known to the end 828 host. This might be the case in a corporate network environment. 829 This is shown as the I1' message. 830 o The initiator I can also send a regular HIP I1 message towards a 831 destination host (denoted as R). This message will then be 832 intercepted by the firewall and a R1' is returned. 834 With R1' the firewall sends a puzzle to the initiator similar to the 835 one sent from a HIP receiver to a HIP initiator. The initiator 836 solves the puzzle and sends the solution back to the FW along with 837 its SPKI certificate using the I2' message. Note that the Initiator 838 can send its certificate in the I1/I1' message. This will, however, 839 create a state even before the client puzzle solution is obtained 840 from the initiator. This raises some denial of service concerns. 841 The FW can validate this SPKI certificate and authorize the HIP host 842 I1. This packet is not liable to any denial of service or replay 843 attacks as the solution is dependent on the cookie that R1' included. 844 Hence, the FW can look into the cookie index to avoid unwanted 845 signature verifications. The ESP transforms are also dropped here as 846 the there will be no IPsec ESP packets exchanged between the HIP host 847 and the FW. There is also no need for the SPI(I) values in I2' and 848 R2' messages. 850 Once the FW receives the I2' packet, it verifies the solution to make 851 sure that it is the entity to which it sent the R1' packet. It sends 852 a R2' packet back to the initiator as an acknowledgement for 853 authorization. The R2' packet however should include a HMAC to 854 prevent denial of service attacks on I. 856 After I receives the R2' packet, it can now initiate the normal base 857 exchange that the FW will forward to R. 859 On receiving I1, receiver R will send a R1 message back to the 860 initiator. However, since the FW-R at the receiver end also needs to 861 authenticate and authorize the receiver, we run the registration 862 procedure with the E2M messages similar to the previous step between 863 FW-R and receiver R. Once receiver R receives the acknowledgement 864 R2', it now sends packet R1 to the initiator that the FW-R will 865 forward. The rest of the base exchange continues as usual. However 866 for the sake of the SPI interception at the firewalls, as mentioned 867 before signaling messages have to be sent from the HIP hosts to their 868 local middleboxes about the SPI values they have agreed on. 870 I1' FW-I 871 ----------------> +-+ 872 R1' | | 873 <---------------- | | 874 I2' | | 875 ----------------> | | 876 R2' | | 877 <---------------- | | 878 I1 | | 1.I1 879 ---------------> | | -----------------------------------> 880 +-+ 882 FW-R R1 883 +-+<--------------- 884 | | R1' 885 | |----------------> 886 | | I2' 887 | |<---------------- 888 | | R2' 889 | |----------------> 890 2.R1 | | R1 891 <--------------------------------------| |<--------------- 892 +-+ 894 FW-I 895 +-+ 896 3.I2 | | I2 897 ---------------> | | ------------------------------------> 898 | | 899 +-+ 901 FW-R 902 +-+ 903 4.R2 | | R2 904 <-------------------------------------| |<------------------ 905 | | 906 +-+ 908 FW-I FW-R 909 +-+ +-+ 910 5.SPI(I) | | | | 5.SPI(R) 911 --------------->| | | |<------------------ 912 | | | | 913 +-+ +-+ 915 Figure 11: Authentication and authorization for base exchange 916 messages 918 6.3.5 Authentication and authorization for Readdressing 920 After the base exchange is complete, IPsec payload packets are 921 exchanged among the HIP hosts. The middleboxes use the state that is 922 established with them to forward such packets to the HIP hosts. The 923 state at FW-R is < SPI(R), IP(R), HIT(R) > and state at FW-I will be 924 < SPI(I), IP(I), HIT(I) >.When one of the HIP hosts moves, it sends 925 an UPDATE message to its peer informing about the new IP addresses. 926 The peer will send a new SPI value back to the initiator to make a 927 return routability check. If the peer receives data from the 928 initiator on the new security association with this new SPI, it 929 confirms the mobile node has moved and is indeed reachable at the new 930 IP address. For middleboxes that use as the flow identifier to forward HIP packets, this 932 information needs to be updated with every UPDATE message. FW-I 933 (assuming that I is mobile) has to intercept the new IP address of I 934 while FW-R (behind which is the peer R) has to update the new SPI(R) 935 to forward packets correctly. This is illustrated in Figure 12. 937 FW-R 938 +-+ 939 1.UPDATE with REA[new IP(I)] | | 940 ---------------------------------+ |----------------> 941 | | 942 FW-I +-+ 943 +-+ 944 | | 2.UPDATE[new SPI(R)] to IP(I) 945 <---------| |---------------------------------------- 946 | | 947 | | 948 +-+ 950 FW-R 951 +-+ 952 | | 3.new SPI(R) 953 | |<------------------ 954 | | 955 +-+ 956 FW-I 957 +-+ 958 | | 4.Data on the new SA 959 ---------| |----------------------------------------> 960 | | 961 | | 962 +-+ 964 Figure 12: Authentication and authorization for UPDATE messages 966 As seen, FW-R has the flow identifier information for receiver R and 967 FW-I has the flow identifier information for initiator I. When I 968 sends a UPDATE message with a REA parameter, R sends a new SPI(R) to 969 check the reachability of the new IP address. FW-I can intercept the 970 destination IP address from this message and can update its 971 information. After both the UPDATE and UPDATE reply messages have 972 been sent out, the receiver needs to signal the FW-R about it new 973 SPI(R). Denial of service attacks and replay attacks are 974 considerably reduced at firewalls if the firewalls keep track of the 975 UPDATE ID that is sent in the UPDATE messages. Every UPDATE REPLY 976 message carries the same number as the UPDATE message and hence the 977 middleboxes are able to keep up the sequence. Issues as to how the 978 receiver can inform the FW-R about its new SPI(R) even before it has 979 received a confirmation on the return routability test have to be 980 considered. 982 However, even this is true only if the new access point has the same 983 set of middleboxes. If the mobile node is behind a new firewall 984 while sending an UPDATE message, the firewall does not have any state 985 information to create a pin hole. Hence, it should send a trigger 986 message that will reinitiate the extended E2M messages between the 987 mobile node and the firewall as in Figure 11. 989 7. Security Considerations 991 In this approach, we have tried to extend the HIP base exchange to 992 create a state at the NAT/FW securely. Though it is possible to make 993 this configuration along with the base exchange messages itself, the 994 middlebox traversal will significantly alter the original base 995 exchange messages as including the sequence numbers and SPI values 996 for the middleboxes. By extending the base exchange messages as 997 I1',R1',I2' and R2', we also effectively make use of the security 998 features that comes with the HIP protocol to protect the 999 configuration information between the HIP hosts and the middleboxes. 1000 We will now quickly look into some possible security threats at the 1001 middleboxes and how extended HIP base exchange mechanism can protect 1002 the configuration information. 1004 Extended Base Exchange messages for configuration 1005 o Message I1' is only a trigger message sent from the initiator to 1006 the FW. FW has support to precompute many R1' messages and to 1007 send them in response to the I1' messages. Since the FW does not 1008 create any state at this point in time, it is quite difficult to 1009 launch a DoS attack here. 1010 o Message R1' can be spoofed by a MITM and can tie up an initiator 1011 with solving puzzles for a long time. However, this is avoided by 1012 solving puzzles in R1' messages that correspond to a previously 1013 sent I1' message only. 1014 o On receiving an I2' message, a FW is expected to verify the 1015 signature and validate the certificates. There can be possible 1016 DoS and replay attacks here either to create multiple false states 1017 at the firewall or to reuse the certificates. However, the FW 1018 maintains a cookie index and the corresponding cookie that was 1019 sent in the R1' packet. The firewall can choose to validate the 1020 certificate only if the cookie index and the cookie value both 1021 match the expected values. These verifications can considerably 1022 prevent such attacks. 1023 o Hosts are protected against replays to R2' by use of a less 1024 expensive HMAC verification preceding HIP signature verification. 1025 o Hosts can prevent denial of service attacks and replay attacks 1026 with the UPDATE message with the use of the UPDATE ID in the 1027 UPDATE packets. These UPDATE messages are sequence numbers which 1028 the middleboxes can keep a track of. They can simply precede any 1029 signature verification by checking the UPDATE ID first. 1031 8. Acknowledgements 1033 The authors would like to thank Pekka Nikander, Dieter Gollmann and 1034 Thomas Aura for their feedback to this document. 1036 This document is a byproduct of the Ambient Networks Project, 1037 partially funded by the European Commission under its Sixth Framework 1038 Programme. It is provided "as is" and without any express or implied 1039 warranties, including, without limitation, the implied warranties of 1040 fitness for a particular purpose. The views and conclusions 1041 contained herein are those of the authors and should not be 1042 interpreted as necessarily representing the official policies or 1043 endorsements, either expressed or implied, of the Ambient Networks 1044 Project or the European Commission. 1046 9. References 1048 9.1 Normative References 1050 [1] Moskowitz, R., "Host Identity Protocol", 1051 Internet-Draft draft-ietf-hip-base-00, June 2004. 1053 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1054 Levels", March 1997. 1056 9.2 Informative References 1058 [3] Srisuresh, P. and K. Egevang, "Traditional IP Network Address 1059 Translator (Traditional NAT)", RFC 3022, January 2001. 1061 [4] Srisuresh, P. and M. Holdrege, "IP Network Address Translator 1062 (NAT) Terminology and Considerations", Request For Comments RFC 1063 2663, August 1999. 1065 [5] Moskowitz, R. and P. Nikander, "Host Identity Protocol 1066 Architecture", Internet-Draft draft-moskowitz-hip-arch-05 (work 1067 in progress), September 2003. 1069 [6] Kent, S. and R. Atkinson, "Security Architecture for the 1070 Internet Protocol", RFC 2401, November 1998. 1072 [7] Hancock, R., "Next Steps in Signaling: Framework", 1073 Internet-Draft draft-ietf-nsis-fw-07, November 2004. 1075 [8] Kivinen, T., A. Huttunen, A., Swander, B. and V. Volpe, 1076 "Negotiation of NAT-Traversal in the IKE", RFC 3947, January 1077 2005. 1079 [9] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 1080 Internet-Draft draft-ietf-ipsec-ikev2-17, September 2004. 1082 [10] A. Huttunen, A., Swander, B., Volpe, V., DiBurro, L. and M. 1083 Stenberg, "UDP Encapsulation of IPsec Packets", RFC 3948, 1084 January 2005. 1086 [11] Nikander, P., Tschofenig, H., Henderson, T., Eggert, L. and J. 1087 Laganier, "Preferred Alternatives for Tunnelling HIP (PATH)", 1088 Internet-Draft draft-nikander-hip-path-00.txt (work in 1089 progress), February 2005. 1091 [12] Stiemerling, M., "A NAT/Firewall NSIS Signaling Layer Protocol 1092 (NSLP)", Internet-Draft draft-ietf-nsis-nslp-natfw-04, October 1093 2004. 1095 [13] Tschofenig, H., "Security Implications of the Session 1096 Identifier", Internet-Draft draft-tschofenig-nsis-sid-00, June 1097 2003. 1099 [14] Ylitalo, J., Melen, J., Nikander, P. and V. Torvinen, 1100 "Re-thinking Security in IP based Micro-Mobility", 7th 1101 Information Security Conference (ISC-04), Palo Alto,", 1102 September 2004. 1104 [15] Ylitalo, J., Melen, J. and P. Nikander, "SPINAT: A Security 1105 Framework for Local IP Mobility Management, unpublished 1106 manuscript", November 2003. 1108 [16] Maler, E. and J. Hughes, "Technical Overview of the OASIS 1109 Security Assertion Markup Language (SAML) V1.1", March 2004. 1111 [17] Laganier, J., Koponen, T. and L. Eggert, "Host Identity 1112 Protocol (HIP) Registration Extension", 1113 Internet-Draft draft-koponen-hip-registration-00.txt, February 1114 2005. 1116 [18] Kent, S., "IP Encapsulating Security Payload (ESP)", 1117 Internet-Draft draft-ietf-ipsec-esp-v3-08 (work in progress), 1118 March 2004. 1120 [19] Srisuresh, P. and K. Egevang, "Traditional IP Network Address 1121 Translator (Traditional NAT)", Request For Comments RFC 3022, 1122 January 2001. 1124 [20] Nikander, P. and J. Arkko, "End-Host Mobility and Multi-Homing 1125 with Host Identity Protocol", 1126 Internet-Draft draft-nikander-hip-mm-01.txt (work in progress), 1127 October 2004. 1129 [21] Crocker, D., "Choices for Multiaddressing", 1130 Internet-Draft draft-crocker-multiaddr-analysis-01.txt, October 1131 2003. 1133 Authors' Addresses 1135 Hannes Tschofenig 1136 Siemens 1137 Otto-Hahn-Ring 6 1138 Munich, Bayern 81739 1139 Germany 1141 Email: Hannes.Tschofenig@siemens.com 1142 Aarthi Nagarajan 1143 Siemens 1144 Otto-Hahn-Ring 6 1145 Munich, Bayern 81739 1146 Germany 1148 Email: aarthi.nagarajan@tuhh.de 1150 Vesa Torvinen 1151 Ericsson 1152 Joukahaisenkatu 1 1153 Turku FIN 20520 1154 Finland 1156 Email: vesa.torvinen@ericsson.com 1158 Jukka Ylitalo 1159 Ericsson Research Nomadiclab 1160 Jorvas FIN 02420 1161 Finland 1163 Phone: +358 9 299 1 1164 Email: jukka.ylitalo@ericsson.com 1166 Murugaraj Shanmugam 1167 Siemens 1168 Otto-Hahn-Ring 6 1169 Munich, Bayern 81739 1170 Germany 1172 Email: murugaraj.shanmugam@tuhh.de 1174 Intellectual Property Statement 1176 The IETF takes no position regarding the validity or scope of any 1177 Intellectual Property Rights or other rights that might be claimed to 1178 pertain to the implementation or use of the technology described in 1179 this document or the extent to which any license under such rights 1180 might or might not be available; nor does it represent that it has 1181 made any independent effort to identify any such rights. Information 1182 on the procedures with respect to rights in RFC documents can be 1183 found in BCP 78 and BCP 79. 1185 Copies of IPR disclosures made to the IETF Secretariat and any 1186 assurances of licenses to be made available, or the result of an 1187 attempt made to obtain a general license or permission for the use of 1188 such proprietary rights by implementers or users of this 1189 specification can be obtained from the IETF on-line IPR repository at 1190 http://www.ietf.org/ipr. 1192 The IETF invites any interested party to bring to its attention any 1193 copyrights, patents or patent applications, or other proprietary 1194 rights that may cover technology that may be required to implement 1195 this standard. Please address the information to the IETF at 1196 ietf-ipr@ietf.org. 1198 Disclaimer of Validity 1200 This document and the information contained herein are provided on an 1201 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1202 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1203 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1204 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1205 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1206 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1208 Copyright Statement 1210 Copyright (C) The Internet Society (2005). This document is subject 1211 to the rights, licenses and restrictions contained in BCP 78, and 1212 except as set forth therein, the authors retain all their rights. 1214 Acknowledgment 1216 Funding for the RFC Editor function is currently provided by the 1217 Internet Society.