idnits 2.17.00 (12 Aug 2021) /tmp/idnits18282/draft-tschofenig-hiprg-hip-natfw-traversal-02.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 19. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1295. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1272. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1279. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1285. ** 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 == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: o MUST not be vulnerable to Man-in-the-Middle attacks. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 18, 2005) is 6151 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: 'RFC2663' is defined on line 676, 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. 'I-D.ietf-hip-base') == Outdated reference: draft-ietf-hip-arch has been published as RFC 4423 == Outdated reference: draft-ietf-hip-esp has been published as RFC 5202 == 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 -- Obsolete informational reference (is this intentional?): RFC 2401 (Obsoleted by RFC 4301) Summary: 5 errors (**), 0 flaws (~~), 9 warnings (==), 8 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: January 19, 2006 Siemens 5 J. Ylitalo 6 Ericsson 7 M. Shanmugam 8 TUHH 9 July 18, 2005 11 Traversal of HIP aware NATs and Firewalls 12 draft-tschofenig-hiprg-hip-natfw-traversal-02.txt 14 Status of this Memo 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on January 19, 2006. 39 Copyright Notice 41 Copyright (C) The Internet Society (2005). 43 Abstract 45 The Host Identity Protocol is a signaling protocol which adds another 46 layer to the Internet model and (optionally) establishes IPsec ESP 47 SAs to protect subsequent data traffic. HIP is designed to be a 48 middlebox friendly protocol; it allows middleboxes (such as NATs and 49 Firewalls) to participate in the protocol exchange in order to learn 50 the flow identifier. Additionally, adding authentication and 51 authorization mechanisms can help the middlebox to prevent 52 unauthorized end hosts to gain access to the network. This document 53 provides a problem description, goals and lists a few scenarios. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 2.1 Notation . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5 61 4. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 62 5. Overview of HIP Base Exchange with Middleboxes . . . . . . . . 8 63 5.1 HIP Base Exchange with NAT . . . . . . . . . . . . . . . . 8 64 5.2 HIP Base Exchange with Firewall . . . . . . . . . . . . . 9 65 6. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 11 66 6.1 Same Firewall at Initiator for both outgoing and 67 incoming packets . . . . . . . . . . . . . . . . . . . . . 11 68 6.2 Different Firewalls at Initiator for outgoing and 69 incoming packets . . . . . . . . . . . . . . . . . . . . . 12 70 6.3 Different Firewalls at Initiator and Receiver . . . . . . 14 71 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 72 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 73 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 74 9.1 Normative References . . . . . . . . . . . . . . . . . . . 19 75 9.2 Informative References . . . . . . . . . . . . . . . . . . 19 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 20 77 A. Solution Approach . . . . . . . . . . . . . . . . . . . . . . 22 78 A.1 Flow identifier interception . . . . . . . . . . . . . . . 22 79 A.2 Sender Invariance . . . . . . . . . . . . . . . . . . . . 23 80 A.3 Authentication and Authorization . . . . . . . . . . . . . 24 81 A.3.1 What is SPKI? . . . . . . . . . . . . . . . . . . . . 24 82 A.3.2 SAML Usage in HIP . . . . . . . . . . . . . . . . . . 25 83 A.3.3 SPKI usage for HIP . . . . . . . . . . . . . . . . . . 27 84 A.3.4 Authentication and authorization for Base Exchange . . 28 85 A.3.5 Authentication and authorization for Readdressing . . 32 86 Intellectual Property and Copyright Statements . . . . . . . . 34 88 1. Introduction 90 An IP address serves the dual role of a locator and an identifier for 91 every host on the Internet. Since, the transport layer connections 92 are bound to the IP address, end systems that use IP addresses as 93 identifiers cannot support dynamic changes in the mapping between the 94 identifier and the locator in case of multi-homing and mobility. 96 The Host Identity Protocol (HIP) [I-D.ietf-hip-base] proposes to 97 separate the identifier from the locator by adding an additional 98 layer between the transport layer and the network layer. The 99 transport layer uses a new, mobility-unrelated identifier called as 100 Host Identity Tags (HITs), in place of IP addresses, while the 101 network layer uses conventional IP addresses for routing. IPsec 102 security associations are bound to the HITs and are not modified with 103 IP address changes. In other words, a host despite being mobile or 104 multi-homed can use a single transport layer connection associated to 105 one HIT and multiple IP addresses. 107 One of the integral features of HIP protocol is, it provides a way to 108 establish IPsec ESP which are subsequently used to encrypt data 109 traffic between the two end hosts. HIP, being a mobility protocol, 110 supports dynamic changes in IP addresses. Because of this, HIP is 111 liable to all known incompatibilities of IPsec with middleboxes such 112 as NATs [RFC3022] and firewalls. This draft investigates some of 113 these problems and proposes a registration mechanism in order to 114 support the secure traversal of NATs and Firewalls. 116 This document is organized as follows: Section 2 introduces some 117 terms, Section 3 provides the problem statement, the goals are listed 118 in Section 4, Section 5 explains the HIP base exchange, Section 6 and 119 in Section 7 we provide some security considerations. 121 Appendix A illustrates a possible solution. This section will be 122 moved into a separate document with a future draft version. 124 2. Terminology 126 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 127 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 128 document are to be interpreted as described in [RFC2119]. 130 This draft used the terminology defined in [RFC3022], [I-D.ietf-hip- 131 base], [I-D.ietf-hip-esp] and [I-D.ietf-hip-arch] and [RFC2401]. 133 The term SPI refers to the Security Parameter Index value used in 134 IPsec packets. The initiator selects one SPI(I) that can be found in 135 the ESP_info parameter, which is then used by the responder to create 136 an IPsec packet (ESP packet in this case) for traffic sent to the 137 initiator. The responder selects one SPI(R)(using ESP_info(R) 138 parameter) which is used by the initiator to encrypt all data sent to 139 the responder. 141 Other relevant abbreviations can be found in [I-D.ietf-hip-base] and 142 [I-D.ietf-hip-esp]. 144 The concept of a flow identifier is described in [RFC4080]. 146 2.1 Notation 148 [x] indicates that x is optional. 150 {x} indicates that x is encrypted. 152 y indicates that "x" is encrypted with the key "y". 154 --> signifies "Initiator to Responder" communication (requests). 156 <-- signifies "Responder to Initiator" communication (replies). 158 3. Problem Statement 160 This version of the document assumes that the data traffic following 161 the HIP base exchange is IPsec protected and uses the mechanism 162 described in [I-D.ietf-hip-esp] for exchanging the IPsec parameters. 163 However, this draft can also be extended to support other HIP based 164 key exchange mechanisms. 166 Besides the communicating hosts in the Internet, the entities such as 167 NATs and Firewalls play a major role in the event of delivering 168 packets to an appropriate host, and each meant for specific 169 functionality. For instance, NATs are used to combat the IPv4 170 address depletion problem, and Firewalls are erected to protect 171 unsolicited information flowing in and out of a corporate network. 172 NATs use as an flow 173 identifier to identify a particular traffic or connection. Because 174 of this, protocols like IPsec suffers from well-known NAT related 175 problems. The NAT traversal approach described in [RFC3947] and 176 [I-D.ietf-ipsec-ikev2] allows the end hosts to detect one or more 177 NATs in between them and [RFC3948] proposes to use the UDP 178 encapsulation of IPsec ESP packets to traverse NATs. 180 Since HIP uses IPsec protection for the data traffic, the flow 181 identifier takes the shape of a 182 (in order to support smooth traversal of the middleboxes) and the 183 middleboxes should learn this flow id in order to relay the data 184 packets. To achieve this, HIP aims to interact with middleboxes 185 actively whereby these devices need to understand the HIP protocol 186 and they need to be involved in the protocol exchange. HIP also 187 provides a way to deal with legacy NATs, as described in 188 [draft-nikander-hip-path-00.txt]. To support this functionality, it 189 is necessary to provide UDP encapsulation for both HIP signaling and 190 IPsec packets. Legacy NAT traversal does not require NATs to be HIP 191 aware or to understand the HIP message exchange. 193 Even though HIP allows the middleboxes to participate in the base 194 exchange, but scenarios like routing asymmetry poses a serious 195 challenge for the HIP to traverse a middlebox. Section 6 explains 196 some possible scenarios which have routing asymmetry. The inability 197 of HIP to handle routing asymmetry motivates to use an explicit 198 signaling mechanism for the HIP hosts in order to support secure and 199 smooth traversal of the middleboxes. 201 Although HIP is described as a two-party protocol, middleboxes are 202 supposed to intercept these messages in order to learn the flow 203 identifier and to process them correctly. In other words, a multi 204 party protocol is created such that the flow identifier is available 205 to middleboxes between the HIP hosts. To provide proper security, 206 middleboxes should not be subject to denial of service attacks and 207 might want to authenticate or authorize entities which create state. 208 Note that the IPsec SA is unidirectional and therefore two IPsec SAs 209 (with two different SPIs, ESP_info contains the SPI value) have to be 210 established. 212 4. Goals 214 The main goal of the draft is to find a suitable NAT/FW traversal 215 solution for the Host Identity Protocol. In the context of middlebox 216 signaling a few goals can be accomplished: 218 o Add some authentication and authorization capabilities to NAT 219 traversal. Many NAT/Firewall traversal solutions do not allow the 220 end host to interact with the middlebox. As a consequence, some 221 security vulnerabilities are introduced. 223 o Add secure firewall traversal functionality as another type of 224 middlebox signaling by using triplet. as a substitute for the typical < source IP, 226 destination IP, source port, destination port, transport protocol> 227 information. 229 Such a solution for HIP-based middlebox signaling has to provide the 230 following properties: 232 o A HIP-aware NAT/FW MUST be able to authenticate the entity 233 requesting a NAT binding or a firewall pinhole. 235 o A HIP-aware NAT/FW MUST authorize the entity requesting a NAT 236 binding or a firewall pinhole before storing state information. 237 This requirement might be accomplished by identity based 238 authorization or an identity independent authorization mechanism. 240 o A HIP-aware NAT/FW MUST be able to intercept HIP messages in order 241 to extract the flow identifier information and other related 242 information. HIP messages are base exchange messages during 243 context establishment and readdressing messages during IP address 244 changes. A NAT/FW MUST be able to distinguish these messages. 246 o A NAT/FW node MUST NOT introduce new denial of service attacks 247 based on authentication or key management mechanisms. 249 o A potential solution MUST respect the property of some middleboxes 250 which do not allow traffic (data and signaling traffic) to 251 traverse this middlebox without proper authorization. 253 Some requirements are taken from [I-D.ietf-nsis-nslp-natfw]. 255 5. Overview of HIP Base Exchange with Middleboxes 257 This section explains the HIP base exchange together with the 258 middleboxes and describes how the middleboxes behave during the base 259 exchange. 261 5.1 HIP Base Exchange with NAT 263 Figure 1 shows the HIP base exchange traversing a NAT. 265 I1 +-----------+ I1 266 +-------------------->| |----------------------+ 267 | | | | 268 | | | | 269 R1 | Intercept | R1 v 270 +---------+ <-------------| the flow |<---------------- +---------+ 271 |Initiator| I2 | identfier | I2 |Responder| 272 +---------+ ------------->| +---------+ 273 ^ | SPI,ESP> | 274 | | | | 275 | R2 | | R2 | 276 +---------------------| |<----------------------+ 277 +-----------+ 278 NAT 280 Figure 1: NAT and HIP Base Exchange 282 Subsequently, the HIP base exchange is described in more detail. 284 I -> R: I1: Trigger exchange 286 I <- R: R1: {Puzzle, D-H(R), HI(R), ESP Transform, 287 HIP Transform }SIG 289 I -> R: I2: {Solution, LSI(I), ESP_info(I), D-H(I), 290 ESP_Transform, HIP Transform, {H(I)}SK }SIG 292 I <- R: R2: {LSI(R), ESP_info(R), HMAC}SIG 294 A potential responsibility of the NAT, as shown in Figure 1, can be 295 the following 297 o Intercept the signaling messages 299 o Authenticate and authorize the HIP nodes by verifying the 300 signatures. 302 o Process the flow identifier information 304 o Perform actions according to the state machine 306 o Create state based on the content of message I2 with ESP_info(I) 307 and R2 with ESP_info(R). Additionally, it might be necessary to 308 include support for storing the respective HITs and host 309 identities. 311 5.2 HIP Base Exchange with Firewall 313 In case of a firewall traversal, the routing asymmetry needs to be 314 considered i.e., the fact that the messages I1 and I2 do not 315 necessarily traverse the same devices as R1 and R2. The same is true 316 with more complex network topologies with a mixture of NATs and 317 Firewalls. This is an assumption made in the NSIS working group (and 318 therefore also with NAT/Firewall traversal). Pure NAT traversal is 319 therefore simpler to handle in comparison to middlebox traversal 320 which also includes devices such as Firewalls. Figure 3 shows this 321 circumstance graphically: 323 I1 +----------+ I1 324 +--------------------> | Firewall | -----------------------+ 325 | I2 | 1 | I2 | 326 | +-----------------> | | ------------------+ | 327 | | +----------+ v v 328 +---------+ +---------+ 329 |Initiator| |Responder| 330 +---------+ +---------+ 331 ^ ^ R1 +----------+ R1 | | 332 | +------------------ | Firewall | <-------------------+ | 333 | R2 | 2 | R2 | 334 +--------------------- | | <-----------------------+ 335 +----------+ 337 ............... IPsec ESP protected traffic (SPI(R)).........> 338 <.............. IPsec ESP protected traffic (SPI(I)).......... 340 Legend: 341 --- = HIP signaling 342 ... = IPsec protected data traffic 344 Figure 3: Firewall and HIP Base Exchange 346 With one single NAT between the HIP nodes, all messages of the base 347 exchange are forced through it. With firewalls, it becomes obvious 348 that the nice property of a NAT with respect to the symmetric 349 forwarding path is lost and the individual firewalls (Firewall 1 and 350 Firewall 2) are unable to create the necessary firewall pinholes. 351 SPI(I) is exchanged in I2 message (ESP_info(I)) through firewall 1, 352 however firewall 2 only needs it. Similarly firewall 2 needs SPI (R) 353 which is sent in message R2 (ESP_info(I)) through firewall 1. 355 6. Scenarios 357 The following section describes some sample scenarios and the 358 possible solutions to learn the flow identifier: 360 6.1 Same Firewall at Initiator for both outgoing and incoming packets 362 This scenario assumes that the initiator I alone is behind a firewall 363 named FW(I). This firewall is both for the outgoing and incoming 364 packets and hence can look into all the base exchange messages. The 365 FW(I) is expected to authenticate and authorize the initiator to send 366 out going packets, receiver if necessary to let incoming packets and 367 intercept the flow identifier from the base exchange. With the E2M 368 messages, it can be achieved as follows. This is illustrated in 369 Figure 4 371 FW(I) 372 I1 +-----+ I1 373 +----------> | |--------------------------------------+ 374 | I2 | | I2 | 375 | +-----> | |---------------------------------+ | 376 | | | | | | 377 | | | | v v 378 ---------+ | | +--------+ 379 Initiator| | | |Receiver| 380 ---------+ | | +--------+ 381 ^ ^ | | 382 | | R2 | | R2 | | 383 | +------ | |< --------------------------------+ | 384 | R1 | | R1 | 385 +---------- | |< -------------------------------------+ 386 +-----+ 388 Figure 4: One FW only at initiator end 390 1. I1 packet is sent from the initiator I to receiver R. 392 2. FW(I) drops the packet and sends a R1' message back to I. This 393 is the End host-to-Middlebox or E2M message exchange initiation. 395 3. I sends I2' message with CERT(I) parameters to FW(I). It 396 requests the FW(I) to open up a pinhole. 398 4. FW verifies SPKI certificate and the signature of I. 399 Accordingly, it either sends a R2' to acknowledge I that it can 400 continue with the base exchange with message I1 or drops packet 401 if verification fails. 403 5. On receiving R2',I sends message I1 to R again. Now the FW(I) 404 will let the packet through. 406 6. R sends the message R1 to I. 408 7. On receiving R1, if FW(I) wishes to authenticate/authorize the 409 receiver R, it should initiate E2M exchange here. It sends 410 message R1' to R forcing R to send an I2' in exchange. 412 8. R sends the CERT(R) parameter in I2'. 414 9. FW verifies SPKI certificate and the signature of R. 415 Accordingly, it either sends a R2' to acknowledge R that it can 416 continue with the base exchange with message R1 or drops packet 417 if verification fails. 419 10. On receiving R2', R sends message R1 to I again. Now the FW(I) 420 will let it through. 422 11. The base exchange continues until complete. Since all messages 423 I1,R1,I2 and R2 traverse through FW(I), it can look into these 424 messages to learn the flow identifier information. 426 6.2 Different Firewalls at Initiator for outgoing and incoming packets 428 This scenario assumes that the initiator I alone is behind firewalls 429 named FW1(I) and FW2(I).FW1(I) is for the incoming packets to I and 430 FW2(I) is for the outgoing packets to R. The FW(I) is expected to 431 authenticate and authorize the initiator to send out going packets, 432 while FW2(I) would authenticate and authorize the receiver, if 433 necessary to let incoming packets. It is sufficient that FW2(I) 434 alone learns the flow identifier information of I. It should store 435 the state to forward IPsec protected payload 436 packets. This scenario is illustrated in Figure 5 437 FW1(I) 438 I1 +-----+ I1 439 +----------> | |--------------------------------------+ 440 | I2 | | I2 | 441 | +-----> | |---------------------------------+ | 442 | | +-----+ | | 443 | | v v 444 +---------+ +--------+ 445 |Initiator| |Receiver| 446 +---------+ FW2(I) +--------+ 447 ^ ^ +-----+ 448 | | R2 | | R2 | | 449 | +------ | |< --------------------------------+ | 450 | R1 | | R1 | 451 +---------- | |< -------------------------------------+ 452 +-----+ 454 Figure 5: Two FWs at initiator's end 456 1. I1 packet is sent from the initiator I to receiver R. 458 2. FW1(I) drops the packet and sends a R1' message back to I. This 459 is the E2M message exchange initiation. 461 3. I sends I2' message with CERT(I) parameters to FW1(I). It 462 requests the FW1(I) to open up a pinhole. 464 4. FW1(I) verifies SPKI certificate and the signature of I. 465 Accordingly, it either sends a R2' to acknowledge I that it can 466 continue with the base exchange with message I1 or drops packet 467 if verification fails. 469 5. On receiving R2',I sends message I1 to R again. Now the FW1(I) 470 will let the packet through. 472 6. R sends the message R1 to I. 474 7. On receiving R1, if FW2(I) wishes to authenticate/authorize the 475 receiver R, it should initiate E2M exchange here. It sends 476 message R1' to R forcing R to send an I2' in exchange. 478 8. R sends the CERT(R) parameter in I2'. 480 9. FW2(I) verifies SPKI certificate and the signature of R. 481 Accordingly, it either sends a R2' to acknowledge R that it can 482 continue with the base exchange with message R1 or drops packet 483 if verification fails. 485 10. On receiving R2', R sends message R1 to I again. Now the FW2(I) 486 will let it through. 488 11. Since FW2(I) needs the store the state, once the base exchange 489 is complete, the initiator should inform the FW2(I) about the 490 SPI it has chosen for the exchange. This way, FW2(I) can 491 forward further IPsec payload packets from R to I 493 6.3 Different Firewalls at Initiator and Receiver 495 This scenario looks into a more complicated situation. Initiator I 496 is behind multiple firewalls FW1(I) for outgoing packets and FW2(I) 497 and FW3(I) are for incoming packets. Similarly, receiver R is behind 498 FW1(R) and FW2(R) for incoming packets and FW3(R) for outgoing 499 packets. The incoming firewalls are chosen based on the type of the 500 application and the hosts are unaware from which firewall they 501 receive packets. Here, however for our scenario we assume that 502 FW2(R) and FW2(I) are chosen about which also the hosts are unaware 503 of. The FW1(I) is expected to authenticate and authorize the 504 initiator to send outgoing packets to R, while FW2(R) would 505 authenticate and authorize the receiver to let outgoing packets to I. 506 FW2(R) should store the state for the receiver 507 while FW2(I) should store the state for the 508 initiator. This scenario is illustrated in Figure 6 509 +-----+ 510 | | 511 |FW1-R| 512 | | 513 +-----+ +-----+ 514 I1 | | I1 +-----+ 515 +------------| | -------------------> | |---------+ 516 | I2 |FW1-I| I2 |FW2-R| | 517 | +-------| | -------------------> | |----+ | 518 | | | | +-----+ | | 519 | | +-----+ v v 520 +---------+ +--------+ 521 |Initiator| |Receiver| 522 +---------+ +--------+ 523 ^ ^ +-----+ 524 | | R2 | | R2 +-----+ | | 525 | +------ |FW2-I| <--------------------| |-----+ | 526 | R1 | | R1 |FW3-R| | 527 +---------- | | <--------------------| |----------+ 528 +-----+ | | 529 +-----+ | | 530 | | +-----+ 531 |FW3-I| 532 | | 533 +-----+ 535 Figure 6: Multiple FWs at initiator's and receiver's end 537 1. I1 packet is sent from the initiator I to receiver R. 539 2. FW1(I) drops the packet and sends a R1' message back to I. This 540 is the E2M message exchange initiation. 542 3. I sends I2' message with CERT(I) parameters to FW1(I). It 543 requests the FW1(I) to open up a pinhole. 545 4. FW1(I) verifies SPKI certificate and the signature of I. 546 Accordingly, it either sends a R2' to acknowledge I that it can 547 continue with the base exchange with message I1 or drops packet 548 if verification fails. 550 5. On receiving R2',I sends message I1 to R again. Now the FW1(I) 551 will let the packet through. 553 6. This packet would reach FW2(R). If this firewall wishes to 554 authenticate and authorize the initiator I, then it can start a 555 E2M exchange with I. After this is successfully completed, 556 FW2(R) would open up a pinhole to send packets to R. 558 7. R sends the message R1 to I. 560 8. When R sends R1 to I, FW3(R) would initiate a E2M message to 561 authenticate and authorize the receiver R. After this is 562 complete, it will forward the packet to the initiator. On 563 receiving R1, if FW2(I) wishes to authenticate/authorize the 564 receiver R, it should initiate E2M exchange here. 566 9. FW2(I) verifies SPKI certificate and the signature of R. 567 Accordingly, it either sends a R2' to acknowledge R that it can 568 continue with the base exchange with message R1 or drops packet 569 if verification fails. 571 10. On receiving R2', R sends message R1 to I again. Now the FW2(I) 572 will let it through. 574 11. This has completed only one round of authentication and 575 authorization. However, the states are still not established at 576 the firewalls. For this, the hosts have to signal their 577 incoming firewalls about the SPI that they have chosen for IPsec 578 ESP packets to follow. 580 When hosts are behind multiple incoming firewalls, there are unable 581 to decide to which firewall they have to inform their SPI values to. 582 The first option would be to somehow make the chosen FW to signal the 583 host about its requirement for a state to forward IPsec protected 584 packets (similar to a pull model). This could be possibly done along 585 with the first incoming packet which is R1. R1 packet could include 586 extra signaling as record route to the initiator. The second option 587 would be to inform firewall about the SPI values (like the push 588 model). Here, however it would be necessary to send an extra message 589 I3 from the initiator to the receiver which would include the 590 ESP_info(I) for FW(I) and to resend the ESP_info(R) in I2 message for 591 FW(R). 593 The second problem is to secure the SPI signaling message from the 594 end host to the FW. Since the end hosts authenticate and authorize 595 to the FW that lets outgoing packets, they share keys only with them. 596 However, they need to signal the SPI value to the FW on the other end 597 which forwards incoming packets . For the sake of securing the SPI 598 value, it might be necessary that the end hosts have to run a E2M 599 exchange with the firewalls on the receiving end also. 601 7. Security Considerations 603 This document provides problem description and overview of the 604 scenarios for the Host identity protocol, when deployed with the 605 middleboxes. As motivated in the previous sections, in order to 606 provide a smooth traversal of middleboxes, an explicit signaling 607 mechanism is necessary. The solution approach should satisfy the 608 following properties: 610 o SHOULD be resistant to denial of service attacks. 612 o MUST authenticate and authorize the end hosts. 614 o A potential solution MUST respect the property of some middleboxes 615 which do not allow traffic (data and signaling traffic) to 616 traverse this middlebox without proper authorization. 618 o MUST not be vulnerable to Man-in-the-Middle attacks. 620 o MUST protect the end hosts against replay attacks. 622 8. Acknowledgements 624 The authors would like to thank Pekka Nikander, Dieter Gollmann and 625 Thomas Aura for their feedback to this document. 627 This document is a byproduct of the Ambient Networks Project, 628 partially funded by the European Commission under its Sixth Framework 629 Programme. It is provided "as is" and without any express or implied 630 warranties, including, without limitation, the implied warranties of 631 fitness for a particular purpose. The views and conclusions 632 contained herein are those of the authors and should not be 633 interpreted as necessarily representing the official policies or 634 endorsements, either expressed or implied, of the Ambient Networks 635 Project or the European Commission. 637 9. References 639 9.1 Normative References 641 [I-D.ietf-hip-base] 642 Moskowitz, R., "Host Identity Protocol", 643 draft-ietf-hip-base-03 (work in progress), June 2005. 645 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 646 Requirement Levels", March 1997. 648 9.2 Informative References 650 [I-D.ietf-hip-arch] 651 Moskowitz, R., "Host Identity Protocol Architecture", 652 draft-ietf-hip-arch-02 (work in progress), January 2005. 654 [I-D.ietf-hip-esp] 655 Jokela, P., "Using ESP transport format with HIP", 656 draft-ietf-hip-esp-00 (work in progress), July 2005. 658 [I-D.ietf-ipsec-ikev2] 659 Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 660 draft-ietf-ipsec-ikev2-17 (work in progress), 661 October 2004. 663 [I-D.ietf-nsis-nslp-natfw] 664 Stiemerling, M., "NAT/Firewall NSIS Signaling Layer 665 Protocol (NSLP)", draft-ietf-nsis-nslp-natfw-06 (work in 666 progress), May 2005. 668 [I-D.saml-tech-overview-1.1-03] 669 Maler, E. and J. Hughes, "Technical Overview of the OASIS 670 Security Assertion Markup Language (SAML) V1.1", 671 March 2004. 673 [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the 674 Internet Protocol", RFC 2401, November 1998. 676 [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address 677 Translator (NAT) Terminology and Considerations", 678 RFC 2663, August 1999. 680 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 681 Address Translator (Traditional NAT)", RFC 3022, 682 January 2001. 684 [RFC3947] Kivinen, T., Swander, B., Huttunen, A., and V. Volpe, 685 "Negotiation of NAT-Traversal in the IKE", RFC 3947, 686 January 2005. 688 [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. 689 Stenberg, "UDP Encapsulation of IPsec ESP Packets", 690 RFC 3948, January 2005. 692 [RFC4080] Hancock, R., Karagiannis, G., Loughney, J., and S. Van den 693 Bosch, "Next Steps in Signaling (NSIS): Framework", 694 RFC 4080, June 2005. 696 [SPINAT] Ylitalo, J., Melen, J., Nikander, P., and V. Torvinen, 697 "Re-thinking Security in IP based Micro-Mobility", 7th 698 Information Security Conference (ISC-04), Palo Alto,", 699 September 2004. 701 [SPINAT1] Ylitalo, J., Melen, J., and P. Nikander, "SPINAT: A 702 Security Framework for Local IP Mobility Management, 703 unpublished manuscript", November 2003. 705 [draft-ietf-ipsec-esp-v3-08] 706 Kent, S., "IP Encapsulating Security Payload (ESP)", 707 draft-ietf-ipsec-esp-v3-10 (work in progress) (work in 708 progress), March 2005. 710 [draft-koponen-hip-registration-00.txt] 711 Laganier, J., Koponen, T., and L. Eggert, "Host Identity 712 Protocol (HIP) Registration Extension", 713 draft-koponen-hip-registration-00.txt (work in progress), 714 February 2005. 716 [draft-nikander-hip-path-00.txt] 717 Nikander, P., Tschofenig, H., Henderson, T., Eggert, L., 718 and J. Laganier, "Preferred Alternatives for Tunnelling 719 HIP (PATH)", draft-nikander-hip-path-00.txt (work in 720 progress) (work in progress), February 2005. 722 Authors' Addresses 724 Hannes Tschofenig 725 Siemens 726 Otto-Hahn-Ring 6 727 Munich, Bavaria 81739 728 Germany 730 Email: Hannes.Tschofenig@siemens.com 731 URI: http://www.tschofenig.com 733 Aarthi Nagarajan 734 Siemens 735 Otto-Hahn-Ring 6 736 Munich, Bayern 81739 737 Germany 739 Email: aarthi.nagarajan@tuhh.de 741 Jukka Ylitalo 742 Ericsson Research Nomadiclab 743 Jorvas FIN 02420 744 Finland 746 Phone: +358 9 299 1 747 Email: jukka.ylitalo@ericsson.com 749 Murugaraj Shanmugam 750 Technical Univeristy Hamburg-Harburg 751 Schwarzenbergstrasse 95 752 Harburg, Hamburg 21073 753 Germany 755 Email: murugaraj.shanmugam@tuhh.de 757 Appendix A. Solution Approach 759 A.1 Flow identifier interception 761 The most important issue with the HIP NAT/FW traversal is to make the 762 flow identifier available to 763 the middleboxes. In the presence of NATs, we are always sure that 764 the forward path and the backward path are same, since the NAT forces 765 the IP packets to flow through these devices. Hence all the 4 766 messages I1, R1, I2 and R2 traverse through a single NAT. This makes 767 it possible for the NATs to intercept the messages for the relevant 768 flow identifier information. But, in the presence of firewalls, 769 routing asymmetry has to be taken into consideration. 771 To enable the firewalls intercept the correct mapping triplet < dest 772 IP, SPI, ESP > certain values have to be resent with the base 773 exchange messages. This is illustrated in the Figure 7. While the 774 IP value of the flow identifier can be intercepted from the IP header 775 of any base exchange message, the SPI value can be intercepted only 776 in messages I2 (using ESP_info(I)) and R2 (using ESP_info(R)). I 777 generates its SPI(I) and sends it to R through FW-R. However, FW-I 778 needs this information to forward all packets from R to I. Therefore 779 there has to be someway FW-I can learn this information. One 780 possible method would be that message R2 could include the 781 ESP_info(I) value. However, changes to the base exchange are not 782 desired and we try to keep the base exchange unaffected. The only 783 other possibility would be that once the base exchange is complete, 784 the HIP host I could inform the FW-I in its domain about its SPI(I) 785 value. Similarly, the receiver R could inform the FW-R local to it 786 about its SPI(R).This way, the firewalls will be able to learn the 787 SPI values needed to create the state. 789 FW-R 790 +-+ 791 1.I1 | | I1 792 -------------------------------------> | |---------> 793 | | 794 FW-I +-+ 795 +-+ 796 2.R1 | | R1 797 <---------| | <------------------------------------ 798 | | 799 +-+ FW-R 800 +-+ 801 3.I2 | | I2 802 -------------------------------------->| |---------> 803 | | 804 FW-I +-+ 805 +-+ 806 4.R2 | | R2 807 <---------| | <------------------------------------ 808 | | 809 +-+ 811 FW-I FW-R 812 +-+ +-+ 813 5.(ESP_info(I))| | | | 5.(ESP_info(R)) 814 --------> | | | |<-------- 815 | | | | 816 +-+ +-+ 818 Figure 7: Firewalls and mapping information during Base exchange 820 A.2 Sender Invariance 822 The NAT/Firewall HIP node establishes state at possibly several 823 entities between the HIP Initiator and the HIP Responder. Providing 824 authentication of the signaling initiator to each individual HIP node 825 along the path might be possible but not particularly useful, since 826 the initiator is most likely unknown to some middlebox along the 827 path. Hence, authentication per se does not solve the security 828 problem. 830 With mobility, it might be possible that the intermediate HIP-aware 831 middlebox need some assurance that a particular node is the allowed 832 to modify existing state. No other entity should be allowed to 833 modify state since this would allow certain attacks (such as denial 834 of service or third party flooding). In some respect this issue is 835 similar to the authorization property in Mobile IP where the mobility 836 binding state established at the CN needs to be protected against 837 unauthorized modifications. 839 It seems that the property of "sender Invariance" is required in this 840 case: "A party is assured that the source of the communication has 841 remained the same as the one that started the communication, although 842 the actual identity of the source is not important to the recipient." 844 This property is particularly important in the context of mobility 845 which requires a change in the NAT binding or the packet filter. 846 SPINAT (see [SPINAT] and [SPINAT1]) provided innovative aspects by 847 using a hash chain approach in combination with delayed authorization 848 to secure state modifications at NAT devices. 850 A future version of this document will address the aspect of sender 851 invariance in more details. 853 A.3 Authentication and Authorization 855 Before a middlebox can allocate a NAT binding or a pin hole, the HIP 856 nodes requesting them may need to be authenticated. Middleboxes 857 could potentially use information stored in the DNS to authenticate 858 the HIP end points. Since Host Identities are used to identify HIP 859 nodes, middleboxes can also use signature verification at relevant 860 HIP messages for authentication. This might raise some issues on 861 denial of service attacks at the middleboxes and these need to be 862 determined. Authorization is certainly more important than 863 authentication particularly since HIP supports ephemeral host 864 identities as a mechanism to preserve privacy. As such it would be 865 useful to use identity independent authorization assertions. SPKI 866 certificates, attribute certificates or similar mechanisms could be 867 of particular use, especially in cases where the HIP nodes prefer to 868 remain anonymous. 870 A.3.1 What is SPKI? 872 SPKI authorization certificates are used in access control and are 873 identity independent. Issuing and receiving an SPKI certificate is 874 completely local to the network domain and there is no need for a 875 higher certification authority to issue them. For a HIP protocol 876 this would mean whenever a HIP host wishes to create a NAT binding or 877 a FW pinhole, it can locally obtain the SPKI certificate for 878 authorization at middleboxes. The structure of the SPKI certificate 879 is shown in Figure 8. 881 +--------+---------+-----------------+ 882 | Key 1 | Key 2 | | 883 | Issuer | Receiver| Can delegate ? | 884 | | | | 885 +--------+---------+-----------------+ 886 | | 887 | Rights | 888 | | 889 +------------------------------------+ 890 | | 891 | Dates |Certificate signed 892 | |by issuer 893 +------------------------------------+ 895 Figure 8: SPKI certificate structure 897 o Key 1 is the public key of the certificate issuer. 899 o Key 2 is the public key of the certificate receiver. 901 o If a subject gets the right to re-delegate its rights, it can re- 902 delegate its certificates to other subjects. In addition, he can 903 freely sign new certificates to other subjects. 905 o Rights define access control of the receiver. 907 o Dates define the validity period of the certificate. 909 o The complete certificate is signed by the private key of the 910 issuer. 912 When a subject wishes to use his certificates, it sends a request 913 that is signed by the subject's private key. Attached are a chain of 914 certificates that belong not only to it but also to those of its 915 delegates. When a verifier receives requests along with a chain of 916 certificates from a subject, the verifier verifies the requests and 917 the certificates. If the verifier is satisfied with the 918 certificates, then the requested operation is allowed. Otherwise, 919 the requests will be refused. 921 A.3.2 SAML Usage in HIP 923 Security Assertion Markup Language (SAML) [I-D.saml-tech-overview- 924 1.1-03] is an XML extension for security information exchange. It is 925 being developed by OASIS. SAML enables entities to access resources 926 by providing assertions which allow authorization. 928 A.3.2.1 Assertions 930 An Assertion is a package of information including authentication 931 statements, attribute statements and authorization decision 932 statements. All kinds of statements do not have to be present, but 933 at least one. An Assertion contains several elements: 935 Issuing information: 937 Who issued the assertion, when was it issued and the assertion 938 identifier. 940 Subject information: 942 The name of the subject, the security domain and optional subject 943 information, like public key. 945 Conditions under which the assertion is valid: 947 special kind of conditions like assertion validity period, 948 audience restriction and target restriction. 950 Additional advice: 952 explaining how the assertion was made, for example. 954 In an authentication statement, an issuing authority asserts that a 955 certain subject was authenticated by certain means at a certain time. 957 In an attribute statement, an issuing authority asserts that a 958 certain subject is associated with certain attributes which has 959 certain values. For example, user jon@cs.example.com is associated 960 with the attribute 'Department', which has the value 'Computer 961 Science'. 963 In an authorization decision statement, a certain subject with a 964 certain access type to a certain resource has given certain evidence 965 that the identity is correct. Based on this, the relying party then 966 makes the decision on giving access or not. The subject could be a 967 human or a program, the resource could be a webpage or a web service, 968 for example. 970 A.3.2.2 Artifact 972 The Artifact is a base-64 encoded string which is 40 bytes long. 20 973 bytes consists of the typecode, which is the source id. The 974 remaining 20 bytes consists of a 20-byte random number that servers 975 use to look up an assertion. The entity creating an Assertion stores 976 it temporarily. The entity performing the authorization decision 977 uses the received Artifact to retrieve the assertion. The purpose of 978 the Artifact is to act as a token which references an Assertion. 980 SAML also defines a request/response protocol for obtaining 981 Assertions. The request asks for an Assertion or makes queries for 982 authentication, attribute and authorization decisions. The response 983 is carrying back the requested Assertion. The XML format for 984 protocol messages are defined within an XML schema. 986 A HIP-aware NAT/Firewall can use this request/response protocol to 987 fetch assertions from the indicated place. 989 HIP can use SAML Assertions in CER payloads to provide a mechanism 990 for HIP end points to authorize them towards middlebox using an 991 emerging technology. Furthermore, SAML Assertions can be used to 992 bind the authorization decision of different protocols sessions from 993 different layers in the ISO-OSI model together. As an example, the 994 authorization decision by an application layer entity can be used to 995 bind it to a subsequent HIP exchange. SAML provides a complete 996 solution for authorization using Artifacts and Assertions and the 997 corresponding protocols to obtain them. The assertions are based on 998 XML which allows extensibility beyond the initially envisioned 999 deployment area. 1001 A.3.3 SPKI usage for HIP 1003 HIP has already defined the CERT parameter that can carry 1004 certificates. The HIP nodes requesting a NAT/FW traversal can send 1005 their base exchange message with the CERT parameter. The CERT will 1006 carry the SPKI certificate and the packet will be signed by the 1007 requesting HIP node. This would mean, messages I2 and R2 should 1008 include the CERT parameter to get them authorized at the middleboxes. 1009 The structure of the SPKI certificate for HIP is shown in Figure 9. 1011 +------+-------+---------------+ 1012 | Key1 |HI(I/R)|Can Delegate? | 1013 +------+-------+---------------+ 1014 | | 1015 | Rights for NAT/FW traversal | 1016 +------------------------------+ 1017 | | 1018 | Date and further info | 1019 +------------------------------+ 1020 | | 1021 | Digital Signature | 1022 +------------------------------+ 1024 Figure 9: SPKI certificate structure for HIP 1026 A.3.4 Authentication and authorization for Base Exchange 1028 When a HIP host requests a NAT binding or a FW pinhole, it has to be 1029 first authenticated and authorized by the middleboxes. 1030 Authentication is necessary in many cases,because, in case of 1031 mobility, the middlebox should be authorized to change the flow id 1032 and no other party forge the middlebox to change. Since all HIP 1033 packets are signed using the private keys of the HIP hosts, 1034 middleboxes can verify these packets using the signature 1035 verifications. This, of course, will introduce certain kinds of 1036 denial of service attacks. Denial of service attacks for signature 1037 verification at middleboxes can be prevented by using the client 1038 puzzle concept used by the HIP protocol. For more details the HIP 1039 protocol [I-D.ietf-hip-base] can be consulted. This will force the 1040 middleboxes to delay state creation and to also delay expensive 1041 computational operations. As explained in the previous sections, we 1042 seek to use non-identity based authorization mechanisms that can be 1043 verified by the middleboxes before creating a NAT binding or FW 1044 pinhole. Since NATs force the outbound and inbound packets to flow 1045 through them, they are much easier to handle. For instance, the 1046 mechanism used by SPINAT [SPINAT] can be used for authorization of 1047 state modifications by utilizing hash chains and delayed 1048 authentication with NATS. However, this is not presently suitable 1049 for firewalls with asymmetric paths. More work needs to be done 1050 towards extending this idea for a combination of NATs and firewalls 1051 with routing asymmetry. 1053 A HIP host behind a firewall might need to register itself with local 1054 middleboxes before the base exchange can be initiated or completed. 1055 Firewalls might not allow the traffic to bypass the firewall. For 1056 this, we consider using messages I1',R1',I2' and R2' which are an 1057 extended version of the normal base exchange messages used in HIP. 1059 However, these messages are exclusively used only for configuring the 1060 HIP host with the firewalls such that authentication and 1061 authorization is complete before the firewall opens up a pinhole. 1062 With this approach, we make fewer changes to the base exchange by 1063 avoiding the inclusion of certain authorization parameters into them. 1064 We refer to this exchange as 'Registration Procedure', defined in 1065 [draft-koponen-hip-registration-00.txt], as shown in Figure 10 which 1066 provides more details of this lightweight protocol exchange. 1068 End host-to-Middlebox or E2M messages 1070 I -> R: I1: Trigger exchange 1071 OR 1072 I -> FW1: I1': Trigger exchange 1074 I <- FW1: R1': {Puzzle, D-H(R), HI(R),HIP Transform}SIG 1076 I -> FW1: I2': {Solution,D-H(I),HIP Transform,{H(I)},CERT(I)}SIG 1078 I <- FW1: R2': {HMAC}SIG 1080 Figure 10: HIP NAT/Firewall Registration Procedure 1082 As an overview, we modify the HIP exchange protocol to authenticate 1083 the middlebox towards the initiator, to authorize (and possibly 1084 authenticate) the initiator towards the firewall and to establish a 1085 security association between the initiator and the responder. We 1086 reuse the HIP protocol for this purpose to use the same 1087 infrastructure and to benefit from a lightweight protocol. Note that 1088 the message flow in Figure 10 does not establish IPsec security 1089 associations. These security associations are not necessary in most 1090 scenarios. 1092 When a host I wishes to create a pinhole with a FW on its side (named 1093 as FW-I), it has two choices: 1095 o It sends a regular I1 message to the firewall. This assumes that 1096 the end host knows that a firewall is located in the network and 1097 additionally the address of this firewall is also known to the end 1098 host. This might be the case in a corporate network environment. 1099 This is shown as the I1' message. 1101 o The initiator I can also send a regular HIP I1 message towards a 1102 destination host (denoted as R). This message will then be 1103 intercepted by the firewall and a R1' is returned. 1105 With R1' the firewall sends a puzzle to the initiator similar to the 1106 one sent from a HIP receiver to a HIP initiator. The initiator 1107 solves the puzzle and sends the solution back to the FW along with 1108 its SPKI certificate using the I2' message. Note that the Initiator 1109 can send its certificate in the I1/I1' message. This will, however, 1110 create a state even before the client puzzle solution is obtained 1111 from the initiator. This raises some denial of service concerns. 1112 The FW can validate this SPKI certificate and authorize the HIP host 1113 I1. This packet is not liable to any denial of service or replay 1114 attacks as the solution is dependent on the cookie that R1' included. 1115 Hence, the FW can look into the cookie index to avoid unwanted 1116 signature verifications. The ESP transforms are also dropped here as 1117 the there will be no IPsec ESP packets exchanged between the HIP host 1118 and the FW. There is also no need for the ESP_info values in I2' and 1119 R2' messages. 1121 Once the FW receives the I2' packet, it verifies the solution to make 1122 sure that it is the entity to which it sent the R1' packet. It sends 1123 a R2' packet back to the initiator as an acknowledgement for 1124 authorization. The R2' packet however should include a HMAC to 1125 prevent denial of service attacks on I. 1127 After I receives the R2' packet, it can now initiate the normal base 1128 exchange that the FW will forward to R. 1130 On receiving I1, receiver R will send a R1 message back to the 1131 initiator. However, since the FW-R at the receiver end also needs to 1132 authenticate and authorize the receiver, we run the registration 1133 procedure with the E2M messages similar to the previous step between 1134 FW-R and receiver R. Once receiver R receives the acknowledgement 1135 R2', it now sends packet R1 to the initiator that the FW-R will 1136 forward. The rest of the base exchange continues as usual. However 1137 for the sake of the ESP_info interception at the firewalls, as 1138 mentioned before signaling messages have to be sent from the HIP 1139 hosts to their local middleboxes about the SPI values (using ESP_info 1140 parameter)they have agreed on. 1142 I1' FW-I 1143 ----------------> +-+ 1144 R1' | | 1145 <---------------- | | 1146 I2' | | 1147 ----------------> | | 1148 R2' | | 1149 <---------------- | | 1150 I1 | | 1.I1 1151 ---------------> | | -----------------------------------> 1152 +-+ 1154 FW-R R1 1155 +-+<--------------- 1156 | | R1' 1157 | |----------------> 1158 | | I2' 1159 | |<---------------- 1160 | | R2' 1161 | |----------------> 1162 2.R1 | | R1 1163 <--------------------------------------| |<--------------- 1164 +-+ 1166 FW-I 1167 +-+ 1168 3.I2 | | I2 1169 ---------------> | | ------------------------------------> 1170 | | 1171 +-+ 1173 FW-R 1174 +-+ 1175 4.R2 | | R2 1176 <-------------------------------------| |<------------------ 1177 | | 1178 +-+ 1180 FW-I FW-R 1181 +-+ +-+ 1182 5.(ESP_info(I)) | | | | 5.(ESP_info(R)) 1183 --------------->| | | |<------------------ 1184 | | | | 1185 +-+ +-+ 1187 Figure 11: Authentication and authorization for base exchange 1188 messages 1190 A.3.5 Authentication and authorization for Readdressing 1192 After the base exchange is complete, IPsec payload packets are 1193 exchanged among the HIP hosts. The middleboxes use the state that is 1194 established with them to forward such packets to the HIP hosts. The 1195 state at FW-R is < SPI(R), IP(R), HIT(R) > and state at FW-I will be 1196 < SPI(I), IP(I), HIT(I) >.When one of the HIP hosts moves, it sends 1197 an UPDATE message to its peer informing about the new IP addresses. 1198 The peer will send a new SPI value back to the initiator to make a 1199 return routability check. If the peer receives data from the 1200 initiator on the new security association with this new SPI, it 1201 confirms the mobile node has moved and is indeed reachable at the new 1202 IP address. For middleboxes that use as the flow identifier to forward HIP packets, this 1204 information needs to be updated with every UPDATE message. FW-I 1205 (assuming that I is mobile) has to intercept the new IP address of I 1206 while FW-R (behind which is the peer R) has to update the new SPI(R) 1207 (using ESP_info(R) parameter( to forward packets correctly. This is 1208 illustrated in Figure 12. 1210 FW-R 1211 +-+ 1212 1.UPDATE with REA[new IP(I)] | | 1213 ---------------------------------+ |----------------> 1214 | | 1215 FW-I +-+ 1216 +-+ 1217 | | 2.UPDATE[new (ESP_info(R))] to IP(I) 1218 <---------| |---------------------------------------- 1219 | | 1220 | | 1221 +-+ 1223 FW-R 1224 +-+ 1225 | | 3.new (ESP_info(R)) 1226 | |<------------------ 1227 | | 1228 +-+ 1229 FW-I 1230 +-+ 1231 | | 4.Data on the new SA 1232 ---------| |----------------------------------------> 1233 | | 1234 | | 1235 +-+ 1237 Figure 12: Authentication and authorization for UPDATE messages 1239 As seen, FW-R has the flow identifier information for receiver R and 1240 FW-I has the flow identifier information for initiator I. When I 1241 sends a UPDATE message with a REA parameter, R sends a new 1242 ESP_info(R) parameter, which contains SPI(R), to check the 1243 reachability of the new IP address. FW-I can intercept the 1244 destination IP address from this message and can update its 1245 information. After both the UPDATE and UPDATE reply messages have 1246 been sent out, the receiver needs to signal the FW-R about it new 1247 SPI(R). Denial of service attacks and replay attacks are 1248 considerably reduced at firewalls if the firewalls keep track of the 1249 UPDATE ID that is sent in the UPDATE messages. Every UPDATE REPLY 1250 message carries the same number as the UPDATE message and hence the 1251 middleboxes are able to keep up the sequence. Issues as to how the 1252 receiver can inform the FW-R about its new SPI(R) even before it has 1253 received a confirmation on the return routability test have to be 1254 considered. 1256 However, even this is true only if the new access point has the same 1257 set of middleboxes. If the mobile node is behind a new firewall 1258 while sending an UPDATE message, the firewall does not have any state 1259 information to create a pin hole. Hence, it should send a trigger 1260 message that will reinitiate the extended E2M messages between the 1261 mobile node and the firewall as in Figure 11. 1263 Intellectual Property Statement 1265 The IETF takes no position regarding the validity or scope of any 1266 Intellectual Property Rights or other rights that might be claimed to 1267 pertain to the implementation or use of the technology described in 1268 this document or the extent to which any license under such rights 1269 might or might not be available; nor does it represent that it has 1270 made any independent effort to identify any such rights. Information 1271 on the procedures with respect to rights in RFC documents can be 1272 found in BCP 78 and BCP 79. 1274 Copies of IPR disclosures made to the IETF Secretariat and any 1275 assurances of licenses to be made available, or the result of an 1276 attempt made to obtain a general license or permission for the use of 1277 such proprietary rights by implementers or users of this 1278 specification can be obtained from the IETF on-line IPR repository at 1279 http://www.ietf.org/ipr. 1281 The IETF invites any interested party to bring to its attention any 1282 copyrights, patents or patent applications, or other proprietary 1283 rights that may cover technology that may be required to implement 1284 this standard. Please address the information to the IETF at 1285 ietf-ipr@ietf.org. 1287 Disclaimer of Validity 1289 This document and the information contained herein are provided on an 1290 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1291 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1292 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1293 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1294 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1295 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1297 Copyright Statement 1299 Copyright (C) The Internet Society (2005). This document is subject 1300 to the rights, licenses and restrictions contained in BCP 78, and 1301 except as set forth therein, the authors retain all their rights. 1303 Acknowledgment 1305 Funding for the RFC Editor function is currently provided by the 1306 Internet Society.