idnits 2.17.1 draft-tschofenig-hiprg-hip-natfw-traversal-06.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, updated by RFC 4748 on line 790. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 801. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 808. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 814. 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 IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 9, 2007) is 6108 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: 'RFC3022' is defined on line 722, but no explicit reference was found in the text == Unused Reference: 'RFC4303' is defined on line 740, but no explicit reference was found in the text == Outdated reference: A later version (-10) exists of draft-ietf-hip-base-08 ** Downref: Normative reference to an Experimental draft: draft-ietf-hip-base (ref. 'I-D.ietf-hip-base') ** Downref: Normative reference to an Experimental draft: draft-ietf-hip-esp (ref. 'I-D.ietf-hip-esp') == Outdated reference: A later version (-25) exists of draft-ietf-nsis-nslp-natfw-14 -- Obsolete informational reference (is this intentional?): RFC 2401 (Obsoleted by RFC 4301) -- Duplicate reference: RFC3948, mentioned in 'RFC4306', was also mentioned in 'RFC3948'. -- Obsolete informational reference (is this intentional?): RFC 4423 (Obsoleted by RFC 9063) Summary: 4 errors (**), 0 flaws (~~), 6 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 HIPRG H. Tschofenig 3 Internet-Draft Nokia Siemens Networks 4 Expires: January 10, 2008 M. Shanmugam 5 Individual 6 M. Stiemerling 7 NEC 8 July 9, 2007 10 Traversing HIP-aware NATs and Firewalls: Problem Statement and 11 Requirements 12 draft-tschofenig-hiprg-hip-natfw-traversal-06.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 10, 2008. 39 Copyright Notice 41 Copyright (C) The IETF Trust (2007). 43 Abstract 45 The Host Identity Protocol (HIP) is a signaling protocol, which 46 supports mobility and multihoming by adding a new layer in the TCP/IP 47 stack. By carring relevant parameters in the signaling messages, HIP 48 can be used to establish IPsec encapsulating security payload (ESP) 49 security associations between two hosts. Middleboxes (e.g. firewalls 50 and network address translators) cannot inspect transport layer 51 headers of data traffic if that traffic is sent over an IPsec ESP 52 tunnel. However, HIP is designed to be middlebox friendly; it 53 enables the middleboxes to inspect the signaling messages. The 54 information that they can derive from that messages enables the 55 middleboxes to uniquely identify the subsequent data flows, e.g. for 56 the purposes of multiplexing and demultiplexing . A middlebox that 57 implements the relevant mechanisms is called "HIP-aware". This 58 document presents a problem statement and lists some requirements 59 that are necessary for a HIP-aware middlebox traversal technique. 60 These include authentication and authorization of signaling end-hosts 61 by the middleboxes. Such authorization will help the middleboxes to 62 decide whether or not an end host is allowed to traverse, and can 63 potentially limit unwanted traffic. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 69 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 7 70 4. HIP with Middleboxes . . . . . . . . . . . . . . . . . . . . . 9 71 4.1. HIP Base Exchange with middleboxes . . . . . . . . . . . . 9 72 4.2. HIP Base Exchange with ESP Parameters and Middleboxes . . 10 73 4.3. HIP Mobility/Multihoming Exchange with Middleboxes . . . . 11 74 5. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 14 75 5.1. Different Firewalls at Initiator for outgoing and 76 incoming packets . . . . . . . . . . . . . . . . . . . . . 14 77 5.2. Data Receiver behind a NAT . . . . . . . . . . . . . . . . 16 78 6. Requirements for HIP Middlebox Solution . . . . . . . . . . . 18 79 7. Security Considerations . . . . . . . . . . . . . . . . . . . 19 80 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 20 81 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21 82 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 83 10.1. Normative References . . . . . . . . . . . . . . . . . . . 22 84 10.2. Informative References . . . . . . . . . . . . . . . . . . 22 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 86 Intellectual Property and Copyright Statements . . . . . . . . . . 25 88 1. Introduction 90 In the current Internet architecture, an IP address is used to locate 91 and to identify a host, termed as "locator" and "identifier" 92 respectively. Hosts that move and change their IP addresses are said 93 to be mobile and those that prefer to be addressed with multiple IPs 94 at a given time are said to be multihomed. Mobility and Multihoming 95 are together expressed as Multiaddressing. When hosts use IP 96 addresses for communication, all transport connections are bound to 97 it. Changes to IP addresses mean breaking the existing transport 98 bindings and establishing a new transport connection. Hence, the 99 existing dual role of IP addresses are not able to cope with the 100 requirements for multiaddressing. 102 The Host Identity Protocol (HIP) [I-D.ietf-hip-base], a 103 multiaddressing proposal, presents a novel approach to separate the 104 "identifier" role from the "locator" role by adding an additional 105 layer between the traditional transport layer and the network layer. 106 The transport layer uses a new, mobility-unrelated identifier called 107 as Host Identity Tags (HITs), in place of IP addresses, while the 108 network layer uses conventional IP addresses for routing. As the 109 transport connections are bound to the HITs, they are not disturbed 110 with the change in IP address. In other words, a host despite being 111 mobile can use a single transport layer connection associated to one 112 HIT and multiple IP addresses. 114 HIP uses a two-way handshake mechanism, termed as base exchange 115 messages, to authenticate and to establish a connection with an end 116 host. HIP also offers the functionality to carry IPsec ESP relevant 117 payloads together with the base exchange messages in order to 118 establish IPsec ESP security associations, which are subsequently 119 used to encrypt the data traffic between the two end hosts. 120 Consequently, if HIP is used to establish IPsec ESP SAs then it will 121 also inherit some of the well-known incompatibilities similar to 122 IPsec ESP-NAT problems, as described in [RFC3715]. To overcome that, 123 HIP allows the middleboxes to participate in the base exchange, 124 inspect the relevant traffic identifiers and later the middleboxes 125 will use those identifiers to distinguish and to allow a particular 126 data traffic. 128 This document presents a problem statement in the context of HIP and 129 middlebox traversal, and discusses the requirements that has to be 130 addressed by a HIP-aware NAT/FW traversal technique. 132 The problem statement for the HIP dealing with legacy NATs is 133 described in [I-D.irtf-hiprg-nat]. 135 The document is organized as follows: Section 3 presents the problem 136 statement, Section 4 sketches the overview of the HIP base exchange 137 together with the middleboxes, Section 5 discusses possible scenarios 138 and Section 6 discusses the requirements and properties for a HIP- 139 aware middlebox solution. 141 2. Terminology 143 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 144 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 145 document are to be interpreted as described in [RFC2119]. 147 This draft used the terminology defined in [RFC2663], 148 [I-D.ietf-hip-base], [I-D.ietf-hip-esp] and [RFC4423] and [RFC2401]. 150 The term SPI refers to the Security Parameter Index value used in 151 IPsec packets. The initiator selects one SPI(I) that can be found in 152 the ESP_info parameter, which is then used by the responder to create 153 an IPsec packet (ESP packet in this case) for traffic sent to the 154 initiator. The responder selects one SPI(R)(using ESP_info(R) 155 parameter) which is used by the initiator to encrypt all data sent to 156 the responder. 158 Other relevant abbreviations can be found in [I-D.ietf-hip-base] and 159 [I-D.ietf-hip-esp]. 161 The concept of a flow identifier is described in [RFC4080]. 163 We use the following notation throughout this document: 165 [x] indicates that x is optional. 167 {x} indicates that x is encrypted. 169 y indicates that "x" is encrypted with the key "y". 171 --> signifies "Initiator to Responder" communication (requests). 173 <-- signifies "Responder to Initiator" communication (replies). 175 3. Problem Statement 177 Besides the communicating hosts in the Internet, the entities such as 178 NATs and Firewalls play a major role in the event of delivering 179 packets to an appropriate host, and each meant for specific 180 functionality. For instance, NATs are used to combat the IPv4 181 address depletion problem, and Firewalls are erected to protect 182 unsolicited information flowing in and out of a corporate network. 184 Typically, NATs use as 185 a flow identifier to identify a particular traffic or connection. 186 Because of this, protocols like IPsec suffers from well-known NAT 187 related problems [RFC3715] (middleboxes cannot inspect the port 188 numbers, when the packets are IPsec-ESP protected). To work around 189 IPsec-NAT problems several approaches have been discussed, e.g., the 190 NAT traversal approaches described in [RFC3947] and [RFC4306] allows 191 the end hosts to detect one or more NATs in between them and 192 [RFC3948] proposes to use the UDP encapsulation of IPsec ESP packets 193 to traverse NATs. 195 If HIP uses IPsec protection for the data traffic then the flow 196 identifier will take the shape of in order to facilitate the middlebox traversal. Note that the 198 flow identifier used here is one possible example and used throughout 199 the document, however it could be possible to have other variants of 200 flow identitier as well. Although HIP is described as a two-party 201 protocol, middle boxes are supposed to intercept the base exchange 202 messages to learn the flow identifier and to process them correctly. 203 In other words, a multi party protocol is created such that the flow 204 identifier is available to middle boxes between the HIP hosts. To 205 achieve this, HIP aims to interact with middleboxes actively whereby 206 these devices need to understand the HIP protocol and they need to be 207 involved in the protocol exchange. 209 This interaction, obviously, requires the middleboxes to verify the 210 authenticity of the base exchange messages in order to learn the flow 211 identifier and to create a state i.e., NAT binding or a pinhole. In 212 this context, to provide proper security, middleboxes should not be 213 vulnerable to denial of service attacks and might want to 214 authenticate or authorize entities before creating state information. 215 Note that the IPsec SA is unidirectional and therefore two IPsec SAs 216 (with two different SPIs, ESP_info contains the SPI value) have to be 217 established. 219 Additionally, End hosts behind middleboxes, especially NATs, require 220 the following steps to facilitate its reachability. 222 1. Connection, end host connects to the server, while doing that it 223 may also identify the middleboxes. 225 2. Registration, end host registers with the middlebox in order to 226 inform the middlebox to relay its traffic. 228 3. Keep-alive, end host maintains the NAT registration by sending 229 heart-beat messages. 231 4. Messaging, end host receives the solicited traffic. 233 HIP hosts can also make use of such procedures by binding their HITs 234 (static identifier) with the middlebox to be connected, anywhere. 235 Evidently, this requires the HIP hosts to perform a explicit 236 registration mechanism with the middleboxes. 238 HIP also provides a way to deal with legacy NATs, as described in 239 [I-D.nikander-hip-path]. To support this functionality, it is 240 necessary to provide UDP encapsulation for both HIP signaling and 241 IPsec packets. Legacy NAT traversal does not require NATs to be HIP 242 aware or to understand the HIP message exchange. 244 4. HIP with Middleboxes 246 This section describes some sample message exchanges between the 247 Initiator and the Responder, in which some of them situated behind a 248 middlebox. Curently, this document explains the interaction of 249 middlebox with plain HIP base exchange and the HIP base exchange 250 carrying ESP payloads. However, this draft can also be extended to 251 support other mechanisms. 253 4.1. HIP Base Exchange with middleboxes 255 Assume that the initiator starts the HIP base exchange, Figure 1 256 shows the HIP base exchange traversing a middlebox. Note that if a 257 host wants to be contacted by the other peers, it needs some other 258 mechanisms to signal its public address to the peers and, if 259 necessary, should also inform the middlebox to allow the peers. 261 I1 +-----+ I1 262 +-------------------->| |----------------------+ 263 | | | | 264 | | | | 265 R1 | | R1 v 266 +---------+ <-------------| |<---------------- +---------+ 267 |Initiator| I2 | | I2 |Responder| 268 +---------+ ------------->| |----------------> +---------+ 269 ^ | | | 270 | | | | 271 | R2 | | R2 | 272 +---------------------| |<----------------------+ 273 +-----+ 274 Middlebox 276 Figure 1: HIP Base Exchange and middleboxes 278 Subsequently, the HIP base exchange is depicted in more detail. 280 I -> R: I1: Trigger exchange 282 I <- R: R1: (Puzzle, {D-H(R), HI(R), HIP Transform})SIG 284 I -> R: I2: {Solution, LSI(I),D-H(I), 285 HIP Transform, {H(I)}SK }SIG 287 I <- R: R2: {LSI(R), HMAC}SIG 289 Here, the base exchange becomes vulnerable to a DoS attack (for the 290 middleboxes) because the initiator's HI is encrypted in the I2 packet 291 and the middleboxes are unable to verify the I2 message. As a 292 consequence, an attacker may send spoofed I2 messages before the 293 authentic initiator does that. 295 When HIP is used with HIP-aware NAT devices, the checksum, computed 296 over the source and destination address, in the IP header must be 297 recomputed. Additionally, it might be necessary to include support 298 for storing the respective HITs and host identities. 300 4.2. HIP Base Exchange with ESP Parameters and Middleboxes 302 This section explains the HIP base exchange, carrying ESP parameters, 303 together with the middleboxes and describes how the middleboxes may 304 behave during the base exchange. Figure 3 shows the corresponding 305 message exchange traversing a middlebox. 307 I1 +-----------+ I1 308 +-------------------->| |----------------------+ 309 | | | | 310 | | | | 311 R1 | Intercept | R1 v 312 +---------+ <-------------| the flow |<---------------- +---------+ 313 |Initiator| I2 | identifer | I2 |Responder| 314 +---------+ ------------->| +---------+ 315 ^ | SPI,ESP> | 316 | | | | 317 | R2 | | R2 | 318 +---------------------| |<----------------------+ 319 +-----------+ 320 middlebox 322 Figure 3: ESP Transport Format with HIP Base Exchange and Middleboxes 324 Subsequently, the HIP with ESP exchange is described in more detail. 326 I -> R: I1: Trigger exchange 328 I <- R: R1: {Puzzle, D-H(R), HI(R), ESP Transform, 329 HIP Transform }SIG 331 I -> R: I2: {Solution, LSI(I), ESP_info(I), D-H(I), 332 ESP_Transform, HIP Transform, {H(I)}SK }SIG 334 I <- R: R2: {LSI(R), ESP_info(R), HMAC}SIG 336 A potential responsibility of the middlebox, as shown in Figure 3, 337 can be the following 339 o Intercept the signaling messages 341 o Authenticate and authorize the HIP nodes by verifying the 342 signatures. 344 o Process the flow identifier information 346 o Perform actions according to the state machine 348 o Create state based on the content of message I2 with ESP_info(I) 349 and R2 with ESP_info(R). Additionally, it might be necessary to 350 include support for storing the respective HITs and host 351 identities. 353 The middleboxes should participate in the signaling messages and has 354 to learn the flow identifier to pass the subsequent data traffic. 356 Here, together with the spoofed I2 message, an attacker may send a 357 bogus SPI value, which will result in an inconsistent state at 358 NAT/FW. 360 4.3. HIP Mobility/Multihoming Exchange with Middleboxes 362 This section explains the HIP mobility and multihoming extensions for 363 the HIP hosts [I-D.ietf-hip-mm] together with the middleboxes. 364 Assume that the initiator moves after the base exchange and wants to 365 inform the responder. During this procedure, the Initiator wants to 366 start the rekeying procedure in order to establish new keys. 367 Figure 5 shows the mobility message exchange, traversing a middlebox. 368 Note that this draft explains only one possible exchange for 369 mobility, [I-D.ietf-hip-mm] provides a detailed message exchange for 370 other variants such as rekeying initiated by responder. 372 +-----+ UPDATE SEQ 373 +----------> | |--------------------------------------+ 374 | | | UPDATE ACK | 375 | +------ | |---------------------------------+ | 376 | | | | | | 377 | v | | | v 378 +---------+ | | +---------+ 379 |Initiator| | | |Responder| 380 +---------+ | | +---------+ 381 | | | ^ 382 | | | ACK | 383 +------ | |----------------------------------+ 384 | | 385 +-----+ 386 middlebox 388 Figure 5: HIP Mobility Exchange with Middleboxee 390 Subsequently, the HIP mobility exchange is depicted below. 392 I -> R:UPDATE SEQ (ESP_INFO(I), LOCATOR, [DIFFIE_HELLMAN], SEQ) 394 I <- R:UPDATE ACK (ESP_INFO(R), SEQ, ACK, 395 [DIFFIE_HELLMAN], ECHO_REQUEST) 397 I -> R:ACK (ACK, ECHO_RESPONSE) 399 In such cases, a middlebox should, 401 o Intercept the HIP mobility messages 403 o Authenticate and authorize the HIP nodes by verifying the 404 signatures 406 o Process the flow identifier information and perform actions 407 according to the state machine 409 o Update the location of the initiator based on the "LOCATOR 410 parameter" in the UPDATE messages, also in case of rekeying, the 411 middlebox should update the state based on the information in the 412 ESP_info parameter, together with the respective HITs and host 413 identities 415 The problem with the mobilty exchange, when the host is behind a NAT, 416 is that the address in the LOCATOR parameter is a private address and 417 not globally routable. 419 [Editor's Note: Some possible solutions, to overcome this problem, 420 are to use RVS server as a contact point, initiator should find the 421 public address and somehow has to inform it to the responder and the 422 NAT has to bind the new private address and the public address.] 424 In case of multihoming scenario, in which the hosts can be reached by 425 several addresses, the NAT handling becomes complicated. For 426 example, if a host is multihomed, assume that the initial HIP and 427 security associations are established with a public IP address of the 428 host. Later, if it decides to use the address which is behind a NAT, 429 then the "new" NAT has to create a binding between the hosts. 431 +---------+ 1. Base Exchange +---------+ 432 |Initiator|<------------------------------------->|Responder| 433 +---------+ +---------+ 434 ^ ^ 435 | +------+ | 436 | 2. Update | NAT | 2. Update | 437 +-------------------->| |----------------------+ 438 +------+ 439 Intercept the flow id 441 Figure 7: Multihoming and Middleboxes 443 Figure 7 depicts the one possible scenario in which the initiator is 444 multihomed. 446 1. If the Initiator notices the change, it can update the new 447 address by using "Locator" parameter in the UPDATE messages (or 448 can inform the NAT). By this way, a NAT can create a new binding 449 by intercepting the UPDATE messages. 451 2. If the Responder itself decides to send the traffic to the 452 previously exchanged address (informed as alternative address), 453 then the NAT will disrupt the connection, since it does not have 454 necessary state information to handle the traffic. A more 455 detailed analysis, about multihoming, will be done in the future 456 version of this draft. 458 5. Scenarios 460 The following section describes some example scenarios, in the 461 context of involving middleboxes, to learn the flow identifier: 463 5.1. Different Firewalls at Initiator for outgoing and incoming packets 465 This scenario assumes that both the initiator I and the responderR is 466 situated behind firewalls named FW(I) and FW(R) respectively. FW(I) 467 is for the incoming packets to I and FW(R) is for the incoming 468 packets to R. It is necessary that both the firewalls must learn the 469 flow identifier information and should store the state 470 to forward IPsec protected payload packets. This scenario is 471 illustrated in Figure 8 473 I1 +----------+ I1 474 +--------------------> | Firewall | -----------------------+ 475 | I2 | FW(R) | I2 | 476 | +-----------------> | | ------------------+ | 477 | | +----------+ v v 478 +---------+ +---------+ 479 |Initiator| |Responder| 480 +---------+ +---------+ 481 ^ ^ R1 +----------+ R1 | | 482 | +------------------ | Firewall | <-------------------+ | 483 | R2 | FW(I) | R2 | 484 +--------------------- | | <-----------------------+ 485 +----------+ 487 ............... IPsec ESP protected traffic (SPI(R)).........> 488 <.............. IPsec ESP protected traffic (SPI(I)).......... 490 Legend: 491 --- = HIP signaling 492 ... = IPsec protected data traffic 494 Figure 8: End hosts behind FWs 496 1. I1 packet is sent from the initiator I to responder R. 498 2. FW(R) forwards the packet to the Responder. 500 3. Then, R sends R1 message with puzzle,D-H key protected with the 501 signature of R. 503 4. FW(I) forward the packet to the Initiator. 505 5. Now, I sends the I2 packet, on receiving I2, FW(R) verifies the 506 signature of I and learns the SPI value form the ESP_info 507 parameter and forwards it to the Responder 509 6. To complete the base exchange, R sends the message R2 to I. 511 7. On receiving R2, FW(I) verifies the signature of R. Accordingly, 512 it earns the SPI value from the ESP_info parameter and forwards 513 it to the Initiator. 515 Here, the problem with this asymmetric base exchange is that the SPI 516 needed for the FW(I) is sent through the I2 message, which flows 517 through the FW(R) and the SPI needed for for the FW(I) is sent to 518 FW(R). 520 The topology shown in Figure 8 shows a scenario where messages R1/R2 521 are traversed by middlebox FW(I) and messages I1/I2 traverse 522 middlebox FW(R). These scenarios might be found in larger networks 523 with routing asymmetry and multi-homed networks. Today, in many 524 cases a state synchronization protocol is used between these two 525 middleboxes to make them apear as a single device and therefore 526 avoiding problems. 528 A solution for dealing with NAT traversal is simpler compared to 529 firewall traversal. With one single NAT between the HIP nodes, all 530 messages of the base exchange are forced to pass through it. With 531 firewalls, it becomes obvious that the nice property of a NAT with 532 respect to the symmetric forwarding path is lost and here the 533 individual firewalls are unable to create the necessary firewall 534 pinholes. SPI(I) is exchanged in I2 message (ESP_info(I)) through 535 firewall 1, however firewall 2 only needs it. Similarly firewall 2 536 needs SPI (R) which is sent in message R2 (ESP_info(I)) through 537 firewall 1. 539 Hence, problems related with routing asymmetry and firewall traversal 540 are : 542 1. When hosts are behind multiple incoming firewalls, they are 543 unable to decide to which firewall they have to signal the 544 appropriate SPI values. 546 2. The second problem is to secure the SPI signalling message from 547 the end host to the FW. Since the end hosts authenticate and 548 authorize to the FW that lets outgoing packets, they share keys 549 only with them. However, as mentioned earlier, they, somehow, 550 need to signal the SPI value to the FW on the other end which 551 forwards incoming packets. 553 5.2. Data Receiver behind a NAT 555 This scenario explains the full operation during the HIP base 556 exchange between the Initiator and the Responder, where the Responder 557 is assumed to be situated behind a NAT and registered with the 558 rendevous server (RVS) to facilitate its reachability. 560 ------- 561 /// \\\ 562 1. DNS Look Up | | 563 +--------------> DNS 564 | | | 565 | +-----------\\\ /// 566 | | ------- 1'. Registration 567 | | +------------------------+ 568 | | | | 569 | | | | 570 | |2. IP_RVS,HIT_R | | 571 | | v | 572 | | +-----+ +-----+ | 573 | | |RVS | | | | 574 | v +----->| +->| | | 575 ++--------+ 3. I1 | +-----+ | | 3.'I1 +---------+ 576 | +-----------+ | +---------->| | 577 |Initiator| | | |Responder| 578 | | 4. Base Exchg | NAT | | | 579 +---------+ <-------------------------+-----+---------> +--+------+ 580 | | | 581 | |1''.Registration | 582 | |<----------------+ 583 +-----+ 585 Figure 9: HIP Responder with RVS and NAT 587 Figure 9 shows the pictorial representaton of the operation. 589 o Initiator looks up the DNS in order to find the connection 590 parameters for the responder, This is typically done by querying 591 the DNS with the corresponding FQDN. 593 o Since the responder is registerd with the RVS, the DNS record will 594 contain the IP of the RVS and the HIT of the responder. 596 o The Initiator, now, contacts the RVS by sending I1 message, the 597 RVS relays the message to the responder. If the responder is 598 situated behind a NAT, it must inform the NAT, beforehand, to 599 allow the HIP base exchange packets to be traversed via the NAT. 601 This typically requires a registration mechanism to siganl the 602 NAT. 604 o The NAT forwards the HIP packets and actively participates in the 605 base exchange. If ESP traffic information is exchanged, the 606 middlebox will also learn the flow identifier. 608 Here, the NAT might require authentication and authorization from the 609 endhosts in order to enable a NAT binding for the requesting hosts. 610 This can be done achieved by performing middlebox signaling, the 611 requirements for such solution is explained in Section 6. 613 6. Requirements for HIP Middlebox Solution 615 This section presents a few high-level requirements that are derived 616 from the given problem statement. A novel middlebox signaling 617 approach has to accomplish the following goals: 619 o Add some authentication and authorization capabilities to the NAT/ 620 Firewall traversal. Many NAT/Firewall traversal solutions do not 621 allow the end host to interact with the middlebox. As a 622 consequence, some security vulnerabilities are introduced 623 e.g.,denial of service. 625 o Add secure firewall traversal functionality as another type of 626 middlebox signaling by using triplet. as a substitute for the traditional < source 628 IP, destination IP, source port, destination port, transport 629 protocol> information. 631 It is recommended that a solution for HIP-aware middlebox signaling 632 needs to have the following properties: 634 o A HIP-aware NAT/FW MUST be able to authenticate the entity 635 requesting a NAT binding or a firewall pinhole. 637 o A HIP-aware NAT/FW MUST be able to intercept HIP messages in order 638 to extract the flow identifier information and other related 639 information. A HIP-aware NAT/FW MUST be able to distinguish these 640 messages. 642 o A HIP-aware NAT/FW MUST authorize the entity requesting a NAT 643 binding or a firewall pinhole before storing state information. 644 This requirement might be accomplished by identity based 645 authorization or an identity independent authorization mechanism. 647 o A NAT/FW node MUST NOT introduce denial of service attacks. 649 o A potential solution MUST respect the property of some middleboxes 650 which do not allow traffic (data and signaling traffic) to 651 traverse the middlebox without proper authorization. 653 Some requirements are taken from [I-D.ietf-nsis-nslp-natfw]. 655 7. Security Considerations 657 In this document, a problem statement is given and scenarios are 658 described that lead to a number of requirements, which focusses on 659 security at a higher level of abstraction. However, this document 660 does not perform a detailed security analysis for a HIP-aware 661 middlebox solution. 663 The authors recommend that, atmost care should be taken when 664 solutions are developed and the solution must not introduce new 665 security vulnerabilities to the middlebox. 667 8. Contributors 669 We would like to thank Aarthi Nagarajan, Vesa Torvinen, Jochen 670 Grimminger, Jukka Ylitalo, and Murugaraj Shanmugam for their help 671 with earlier versions of this document. 673 9. Acknowledgements 675 The authors would like to thank Pekka Nikander, Dieter Gollmann and 676 Tuomas Aura for their feedback to this document. 678 10. References 680 10.1. Normative References 682 [I-D.ietf-hip-base] 683 Moskowitz, R., "Host Identity Protocol", 684 draft-ietf-hip-base-08 (work in progress), June 2007. 686 [I-D.ietf-hip-esp] 687 Jokela, P., "Using ESP transport format with HIP", 688 draft-ietf-hip-esp-06 (work in progress), June 2007. 690 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 691 Requirement Levels", March 1997. 693 10.2. Informative References 695 [I-D.ietf-hip-mm] 696 Henderson, T., "End-Host Mobility and Multihoming with the 697 Host Identity Protocol", draft-ietf-hip-mm-05 (work in 698 progress), March 2007. 700 [I-D.ietf-nsis-nslp-natfw] 701 Stiemerling, M., "NAT/Firewall NSIS Signaling Layer 702 Protocol (NSLP)", draft-ietf-nsis-nslp-natfw-14 (work in 703 progress), March 2007. 705 [I-D.irtf-hiprg-nat] 706 Stiemerling, M., "NAT and Firewall Traversal Issues of 707 Host Identity Protocol (HIP) Communication", 708 draft-irtf-hiprg-nat-04 (work in progress), March 2007. 710 [I-D.nikander-hip-path] 711 Nikander, P., "Preferred Alternatives for Tunnelling HIP 712 (PATH)", draft-nikander-hip-path-01 (work in progress), 713 March 2006. 715 [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the 716 Internet Protocol", RFC 2401, November 1998. 718 [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address 719 Translator (NAT) Terminology and Considerations", 720 RFC 2663, August 1999. 722 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 723 Address Translator (Traditional NAT)", RFC 3022, 724 January 2001. 726 [RFC3715] Aboba, B. and W. Dixon, "IPsec-Network Address Translation 727 (NAT) Compatibility Requirements", RFC 3715, March 2004. 729 [RFC3947] Kivinen, T., A. Huttunen, A., Swander, B., and V. Volpe, 730 "Negotiation of NAT-Traversal in the IKE", RFC 3947, 731 January 2005. 733 [RFC3948] A. Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and 734 M. Stenberg, "UDP Encapsulation of IPsec Packets", 735 RFC 3948, January 2005. 737 [RFC4080] Hancock, R., "Next Steps in Signaling: Framework", 738 RFC 4080, November 2004. 740 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 741 RFC RFC4303, December 2005. 743 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 744 RFC 3948, September 2004. 746 [RFC4423] Moskowitz, R. and P. Nikandar, "Host Identity Protocol 747 (HIP) Architecture", RFC RFC4423, May 2006. 749 Authors' Addresses 751 Hannes Tschofenig 752 Nokia Siemens Networks 753 Otto-Hahn-Ring 6 754 Munich, Bavaria 81739 755 Germany 757 Phone: +49 89 636 40390 758 Email: Hannes.Tschofenig@siemens.com 759 URI: http://www.tschofenig.com 761 Murugaraj Shanmugam 762 Individual 764 Email: murugaraj@gmail.com 766 Martin Stiemerling 767 NEC Europe Ltd. and University of Goettingen 768 Kurfuersten-Anlage 36 769 Heidelberg 69115 770 Germany 772 Phone: +49 (0) 6221 4342 113 773 Email: stiemerling@netlab.nec.de 774 URI: http://www.stiemerling.org 776 Full Copyright Statement 778 Copyright (C) The IETF Trust (2007). 780 This document is subject to the rights, licenses and restrictions 781 contained in BCP 78, and except as set forth therein, the authors 782 retain all their rights. 784 This document and the information contained herein are provided on an 785 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 786 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 787 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 788 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 789 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 790 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 792 Intellectual Property 794 The IETF takes no position regarding the validity or scope of any 795 Intellectual Property Rights or other rights that might be claimed to 796 pertain to the implementation or use of the technology described in 797 this document or the extent to which any license under such rights 798 might or might not be available; nor does it represent that it has 799 made any independent effort to identify any such rights. Information 800 on the procedures with respect to rights in RFC documents can be 801 found in BCP 78 and BCP 79. 803 Copies of IPR disclosures made to the IETF Secretariat and any 804 assurances of licenses to be made available, or the result of an 805 attempt made to obtain a general license or permission for the use of 806 such proprietary rights by implementers or users of this 807 specification can be obtained from the IETF on-line IPR repository at 808 http://www.ietf.org/ipr. 810 The IETF invites any interested party to bring to its attention any 811 copyrights, patents or patent applications, or other proprietary 812 rights that may cover technology that may be required to implement 813 this standard. Please address the information to the IETF at 814 ietf-ipr@ietf.org. 816 Acknowledgment 818 Funding for the RFC Editor function is provided by the IETF 819 Administrative Support Activity (IASA).