idnits 2.17.00 (12 Aug 2021) /tmp/idnits16228/draft-tschofenig-hiprg-hip-natfw-traversal-05.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 16. -- Found old boilerplate from RFC 3978, Section 5.5 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. ** 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 issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 23, 2006) is 5689 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC3022' is defined on line 729, but no explicit reference was found in the text == Unused Reference: 'RFC4303' is defined on line 747, but no explicit reference was found in the text == Outdated reference: draft-ietf-hip-base has been published as RFC 5201 == Outdated reference: draft-ietf-hip-esp has been published as RFC 5202 == Outdated reference: draft-ietf-hip-mm has been published as RFC 5206 == Outdated reference: draft-ietf-nsis-nslp-natfw has been published as RFC 5973 == Outdated reference: draft-irtf-hiprg-nat has been published as RFC 5207 -- Obsolete informational reference (is this intentional?): RFC 2401 (Obsoleted by RFC 4301) -- 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 (~~), 8 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 HIPRG H. Tschofenig 3 Internet-Draft M. Shanmugam 4 Intended status: Informational Siemens Networks GmbH & Co KG 5 Expires: April 26, 2007 October 23, 2006 7 Traversing HIP-aware NATs and Firewalls: Problem Statement and 8 Requirements 9 draft-tschofenig-hiprg-hip-natfw-traversal-05.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on April 26, 2007. 36 Copyright Notice 38 Copyright (C) The Internet Society (2006). 40 Abstract 42 The Host Identity Protocol (HIP) is a signaling protocol, which 43 supports mobility and multihoming by adding a new layer in the TCP/IP 44 stack. By carring relevant parameters in the signaling messages, HIP 45 can be used to establish IPsec encapsulating security payload (ESP) 46 security associations between two hosts. Middleboxes (e.g. firewalls 47 and network address translators) cannot inspect transport layer 48 headers of data traffic if that traffic is sent over an IPsec ESP 49 tunnel. However, HIP is designed to be middlebox friendly; it 50 enables the middleboxes to inspect the signaling messages. The 51 information that they can derive from that messages enables the 52 middleboxes to uniquely identify the subsequent data flows, e.g. for 53 the purposes of multiplexing and demultiplexing . A middlebox that 54 implements the relevant mechanisms is called "HIP-aware". This 55 document presents a problem statement and lists some requirements 56 that are necessary for a HIP-aware middlebox traversal technique. 57 These include authentication and authorization of signaling end-hosts 58 by the middleboxes. Such authorization will help the middleboxes to 59 decide whether or not an end host is allowed to traverse, and can 60 potentially limit unwanted traffic. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 66 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 7 67 4. HIP with Middleboxes . . . . . . . . . . . . . . . . . . . . . 9 68 4.1. HIP Base Exchange with middleboxes . . . . . . . . . . . . 9 69 4.2. HIP Base Exchange with ESP Parameters and Middleboxes . . 10 70 4.3. HIP Mobility/Multihoming Exchange with Middleboxes . . . . 11 71 5. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 14 72 5.1. Different Firewalls at Initiator for outgoing and 73 incoming packets . . . . . . . . . . . . . . . . . . . . . 14 74 5.2. Data Receiver behind a NAT . . . . . . . . . . . . . . . . 16 75 6. Requirements for HIP Middlebox Solution . . . . . . . . . . . 18 76 7. Security Considerations . . . . . . . . . . . . . . . . . . . 19 77 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 20 78 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21 79 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 80 10.1. Normative References . . . . . . . . . . . . . . . . . . . 22 81 10.2. Informative References . . . . . . . . . . . . . . . . . . 22 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 83 Intellectual Property and Copyright Statements . . . . . . . . . . 25 85 1. Introduction 87 In the current Internet architecture, an IP address is used to locate 88 and to identify a host, termed as "locator" and "identifier" 89 respectively. Hosts that move and change their IP addresses are said 90 to be mobile and those that prefer to be addressed with multiple IPs 91 at a given time are said to be multihomed. Mobility and Multihoming 92 are together expressed as Multiaddressing. When hosts use IP 93 addresses for communication, all transport connections are bound to 94 it. Changes to IP addresses mean breaking the existing transport 95 bindings and establishing a new transport connection. Hence, the 96 existing dual role of IP addresses are not able to cope with the 97 requirements for multiaddressing. 99 The Host Identity Protocol (HIP) [I-D.ietf-hip-base], a 100 multiaddressing proposal, presents a novel approach to separate the 101 "identifier" role from the "locator" role by adding an additional 102 layer between the traditional transport layer and the network layer. 103 The transport layer uses a new, mobility-unrelated identifier called 104 as Host Identity Tags (HITs), in place of IP addresses, while the 105 network layer uses conventional IP addresses for routing. As the 106 transport connections are bound to the HITs, they are not disturbed 107 with the change in IP address. In other words, a host despite being 108 mobile can use a single transport layer connection associated to one 109 HIT and multiple IP addresses. 111 HIP uses a two-way handshake mechanism, termed as base exchange 112 messages, to authenticate and to establish a connection with an end 113 host. HIP also offers the functionality to carry IPsec ESP relevant 114 payloads together with the base exchange messages in order to 115 establish IPsec ESP security associations, which are subsequently 116 used to encrypt the data traffic between the two end hosts. 117 Consequently, if HIP is used to establish IPsec ESP SAs then it will 118 also inherit some of the well-known incompatibilities similar to 119 IPsec ESP-NAT problems, as described in [RFC3715]. To overcome that, 120 HIP allows the middleboxes to participate in the base exchange, 121 inspect the relevant traffic identifiers and later the middleboxes 122 will use those identifiers to distinguish and to allow a particular 123 data traffic. 125 This document presents a problem statement in the context of HIP and 126 middlebox traversal, and discusses the requirements that has to be 127 addressed by a HIP-aware NAT/FW traversal technique. 129 [Editor's Note: The problem statement for the HIP dealing with legacy 130 NATs is described in [I-D.irtf-hiprg-nat].] 132 The document is organized as follows: Section 3 presents the problem 133 statement, Section 4 sketches the overview of the HIP base exchange 134 together with the middleboxes, Section 5 discusses possible scenarios 135 and Section 6 discusses the requirements and properties for a HIP- 136 aware middlebox solution. 138 2. Terminology 140 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 141 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 142 document are to be interpreted as described in [RFC2119]. 144 This draft used the terminology defined in [RFC2663], 145 [I-D.ietf-hip-base], [I-D.ietf-hip-esp] and [RFC4423] and [RFC2401]. 147 The term SPI refers to the Security Parameter Index value used in 148 IPsec packets. The initiator selects one SPI(I) that can be found in 149 the ESP_info parameter, which is then used by the responder to create 150 an IPsec packet (ESP packet in this case) for traffic sent to the 151 initiator. The responder selects one SPI(R)(using ESP_info(R) 152 parameter) which is used by the initiator to encrypt all data sent to 153 the responder. 155 Other relevant abbreviations can be found in [I-D.ietf-hip-base] and 156 [I-D.ietf-hip-esp]. 158 The concept of a flow identifier is described in [RFC4080]. 160 We use the following notation throughout this document: 162 [x] indicates that x is optional. 164 {x} indicates that x is encrypted. 166 y indicates that "x" is encrypted with the key "y". 168 --> signifies "Initiator to Responder" communication (requests). 170 <-- signifies "Responder to Initiator" communication (replies). 172 3. Problem Statement 174 Besides the communicating hosts in the Internet, the entities such as 175 NATs and Firewalls play a major role in the event of delivering 176 packets to an appropriate host, and each meant for specific 177 functionality. For instance, NATs are used to combat the IPv4 178 address depletion problem, and Firewalls are erected to protect 179 unsolicited information flowing in and out of a corporate network. 181 Typically, NATs use as 182 a flow identifier to identify a particular traffic or connection. 183 Because of this, protocols like IPsec suffers from well-known NAT 184 related problems [RFC3715] (middleboxes cannot inspect the port 185 numbers, when the packets are IPsec-ESP protected). To work around 186 IPsec-NAT problems several approaches have been discussed, e.g., the 187 NAT traversal approaches described in [RFC3947] and [RFC4306] allows 188 the end hosts to detect one or more NATs in between them and 189 [RFC3948] proposes to use the UDP encapsulation of IPsec ESP packets 190 to traverse NATs. 192 If HIP uses IPsec protection for the data traffic then the flow 193 identifier will take the shape of in order to facilitate the middlebox traversal. Note that the 195 flow identifier used here is one possible example and used throughout 196 the document, however it could be possible to have other variants of 197 flow identitier as well. Although HIP is described as a two-party 198 protocol, middle boxes are supposed to intercept the base exchange 199 messages to learn the flow identifier and to process them correctly. 200 In other words, a multi party protocol is created such that the flow 201 identifier is available to middle boxes between the HIP hosts. To 202 achieve this, HIP aims to interact with middleboxes actively whereby 203 these devices need to understand the HIP protocol and they need to be 204 involved in the protocol exchange. 206 This interaction, obviously, requires the middleboxes to verify the 207 authenticity of the base exchange messages in order to learn the flow 208 identifier and to create a state i.e., NAT binding or a pinhole. In 209 this context, to provide proper security, middleboxes should not be 210 vulnerable to denial of service attacks and might want to 211 authenticate or authorize entities before creating state information. 212 Note that the IPsec SA is unidirectional and therefore two IPsec SAs 213 (with two different SPIs, ESP_info contains the SPI value) have to be 214 established. 216 Additionally, End hosts behind middleboxes, especially NATs, require 217 the following steps to facilitate its reachability. 219 1. Connection, end host connects to the server, while doing that it 220 may also identify the middleboxes. 222 2. Registration, end host registers with the middlebox in order to 223 inform the middlebox to relay its traffic. 225 3. Keep-alive, end host maintains the NAT registration by sending 226 heart-beat messages. 228 4. Messaging, end host receives the solicited traffic. 230 HIP hosts can also make use of such procedures by binding their HITs 231 (static identifier) with the middlebox to be connected, anywhere. 232 Evidently, this requires the HIP hosts to perform a explicit 233 registration mechanism with the middleboxes. 235 HIP also provides a way to deal with legacy NATs, as described in 236 [I-D.nikander-hip-path]. To support this functionality, it is 237 necessary to provide UDP encapsulation for both HIP signaling and 238 IPsec packets. Legacy NAT traversal does not require NATs to be HIP 239 aware or to understand the HIP message exchange. 241 4. HIP with Middleboxes 243 This section describes some sample message exchanges between the 244 Initiator and the Responder, in which some of them situated behind a 245 middlebox. Curently, this document explains the interaction of 246 middlebox with plain HIP base exchange and the HIP base exchange 247 carrying ESP payloads. However, this draft can also be extended to 248 support other mechanisms. 250 4.1. HIP Base Exchange with middleboxes 252 Assume that the initiator starts the HIP base exchange, Figure 1 253 shows the HIP base exchange traversing a middlebox. Note that if a 254 host wants to be contacted by the other peers, it needs some other 255 mechanisms to signal its public address to the peers and, if 256 necessary, should also inform the middlebox to allow the peers. 258 I1 +-----+ I1 259 +-------------------->| |----------------------+ 260 | | | | 261 | | | | 262 R1 | | R1 v 263 +---------+ <-------------| |<---------------- +---------+ 264 |Initiator| I2 | | I2 |Responder| 265 +---------+ ------------->| |----------------> +---------+ 266 ^ | | | 267 | | | | 268 | R2 | | R2 | 269 +---------------------| |<----------------------+ 270 +-----+ 271 Middlebox 273 Figure 1: HIP Base Exchange and middleboxes 275 Subsequently, the HIP base exchange is depicted in more detail. 277 I -> R: I1: Trigger exchange 279 I <- R: R1: (Puzzle, {D-H(R), HI(R), HIP Transform})SIG 281 I -> R: I2: {Solution, LSI(I),D-H(I), 282 HIP Transform, {H(I)}SK }SIG 284 I <- R: R2: {LSI(R), HMAC}SIG 286 Here, the base exchange becomes vulnerable to a DoS attack (for the 287 middleboxes) because the initiator's HI is encrypted in the I2 packet 288 and the middleboxes are unable to verify the I2 message. As a 289 consequence, an attacker may send spoofed I2 messages before the 290 authentic initiator does that. 292 When HIP is used with HIP-aware NAT devices, the checksum, computed 293 over the source and destination address, in the IP header must be 294 recomputed. Additionally, it might be necessary to include support 295 for storing the respective HITs and host identities. 297 4.2. HIP Base Exchange with ESP Parameters and Middleboxes 299 This section explains the HIP base exchange, carrying ESP parameters, 300 together with the middleboxes and describes how the middleboxes may 301 behave during the base exchange. Figure 3 shows the corresponding 302 message exchange traversing a middlebox. 304 I1 +-----------+ I1 305 +-------------------->| |----------------------+ 306 | | | | 307 | | | | 308 R1 | Intercept | R1 v 309 +---------+ <-------------| the flow |<---------------- +---------+ 310 |Initiator| I2 | identifer | I2 |Responder| 311 +---------+ ------------->| +---------+ 312 ^ | SPI,ESP> | 313 | | | | 314 | R2 | | R2 | 315 +---------------------| |<----------------------+ 316 +-----------+ 317 middlebox 319 Figure 3: ESP Transport Format with HIP Base Exchange and Middleboxes 321 Subsequently, the HIP with ESP exchange is described in more detail. 323 I -> R: I1: Trigger exchange 325 I <- R: R1: {Puzzle, D-H(R), HI(R), ESP Transform, 326 HIP Transform }SIG 328 I -> R: I2: {Solution, LSI(I), ESP_info(I), D-H(I), 329 ESP_Transform, HIP Transform, {H(I)}SK }SIG 331 I <- R: R2: {LSI(R), ESP_info(R), HMAC}SIG 333 A potential responsibility of the middlebox, as shown in Figure 3, 334 can be the following 336 o Intercept the signaling messages 338 o Authenticate and authorize the HIP nodes by verifying the 339 signatures. 341 o Process the flow identifier information 343 o Perform actions according to the state machine 345 o Create state based on the content of message I2 with ESP_info(I) 346 and R2 with ESP_info(R). Additionally, it might be necessary to 347 include support for storing the respective HITs and host 348 identities. 350 The middleboxes should participate in the signaling messages and has 351 to learn the flow identifier to pass the subsequent data traffic. 353 Here, together with the spoofed I2 message, an attacker may send a 354 bogus SPI value, which will result in an inconsistent state at 355 NAT/FW. 357 4.3. HIP Mobility/Multihoming Exchange with Middleboxes 359 This section explains the HIP mobility and multihoming extensions for 360 the HIP hosts [I-D.ietf-hip-mm] together with the middleboxes. 361 Assume that the initiator moves after the base exchange and wants to 362 inform the responder. During this procedure, the Initiator wants to 363 start the rekeying procedure in order to establish new keys. 364 Figure 5 shows the mobility message exchange, traversing a middlebox. 365 Note that this draft explains only one possible exchange for 366 mobility, [I-D.ietf-hip-mm] provides a detailed message exchange for 367 other variants such as rekeying initiated by responder. 369 +-----+ UPDATE SEQ 370 +----------> | |--------------------------------------+ 371 | | | UPDATE ACK | 372 | +------ | |---------------------------------+ | 373 | | | | | | 374 | v | | | v 375 +---------+ | | +---------+ 376 |Initiator| | | |Responder| 377 +---------+ | | +---------+ 378 | | | ^ 379 | | | ACK | 380 +------ | |----------------------------------+ 381 | | 382 +-----+ 383 middlebox 385 Figure 5: HIP Mobility Exchange with Middleboxee 387 Subsequently, the HIP mobility exchange is depicted below. 389 I -> R:UPDATE SEQ (ESP_INFO(I), LOCATOR, [DIFFIE_HELLMAN], SEQ) 391 I <- R:UPDATE ACK (ESP_INFO(R), SEQ, ACK, 392 [DIFFIE_HELLMAN], ECHO_REQUEST) 394 I -> R:ACK (ACK, ECHO_RESPONSE) 396 In such cases, a middlebox should, 398 o Intercept the HIP mobility messages 400 o Authenticate and authorize the HIP nodes by verifying the 401 signatures 403 o Process the flow identifier information and perform actions 404 according to the state machine 406 o Update the location of the initiator based on the "LOCATOR 407 parameter" in the UPDATE messages, also in case of rekeying, the 408 middlebox should update the state based on the information in the 409 ESP_info parameter, together with the respective HITs and host 410 identities 412 The problem with the mobilty exchange, when the host is behind a NAT, 413 is that the address in the LOCATOR parameter is a private address and 414 not globally routable. 416 [Editor's Note: Some possible solutions, to overcome this problem, 417 are to use RVS server as a contact point, initiator should find the 418 public address and somehow has to inform it to the responder and the 419 NAT has to bind the new private address and the public address.] 421 In case of multihoming scenario, in which the hosts can be reached by 422 several addresses, the NAT handling becomes complicated. For 423 example, if a host is multihomed, assume that the initial HIP and 424 security associations are established with a public IP address of the 425 host. Later, if it decides to use the address which is behind a NAT, 426 then the "new" NAT has to create a binding between the hosts. 428 +---------+ 1. Base Exchange +---------+ 429 |Initiator|<------------------------------------->|Responder| 430 +---------+ +---------+ 431 ^ ^ 432 | +------+ | 433 | 2. Update | NAT | 2. Update | 434 +-------------------->| |----------------------+ 435 +------+ 436 Intercept the flow id 438 Figure 7: Multihoming and Middleboxes 440 Figure 7 depicts the one possible scenario in which the initiator is 441 multihomed. 443 1. If the Initiator notices the change, it can update the new 444 address by using "Locator" parameter in the UPDATE messages (or 445 can inform the NAT). By this way, a NAT can create a new binding 446 by intercepting the UPDATE messages. 448 2. If the Responder itself decides to send the traffic to the 449 previously exchanged address (informed as alternative address), 450 then the NAT will disrupt the connection, since it does not have 451 necessary state information to handle the traffic. A more 452 detailed analysis, about multihoming, will be done in the future 453 version of this draft. 455 5. Scenarios 457 The following section describes some example scenarios, in the 458 context of involving middleboxes, to learn the flow identifier: 460 5.1. Different Firewalls at Initiator for outgoing and incoming packets 462 This scenario assumes that both the initiator I and the responderR is 463 situated behind firewalls named FW(I) and FW(R) respectively. FW(I) 464 is for the incoming packets to I and FW(R) is for the incoming 465 packets to R. It is necessary that both the firewalls must learn the 466 flow identifier information and should store the state 467 to forward IPsec protected payload packets. This scenario is 468 illustrated in Figure 8 470 I1 +----------+ I1 471 +--------------------> | Firewall | -----------------------+ 472 | I2 | FW(R) | I2 | 473 | +-----------------> | | ------------------+ | 474 | | +----------+ v v 475 +---------+ +---------+ 476 |Initiator| |Responder| 477 +---------+ +---------+ 478 ^ ^ R1 +----------+ R1 | | 479 | +------------------ | Firewall | <-------------------+ | 480 | R2 | FW(I) | R2 | 481 +--------------------- | | <-----------------------+ 482 +----------+ 484 ............... IPsec ESP protected traffic (SPI(R)).........> 485 <.............. IPsec ESP protected traffic (SPI(I)).......... 487 Legend: 488 --- = HIP signaling 489 ... = IPsec protected data traffic 491 Figure 8: End hosts behind FWs 493 1. I1 packet is sent from the initiator I to responder R. 495 2. FW(R) forwards the packet to the Responder. 497 3. Then, R sends R1 message with puzzle,D-H key protected with the 498 signature of R. 500 4. FW(I) forward the packet to the Initiator. 502 5. Now, I sends the I2 packet, on receiving I2, FW(R) verifies the 503 signature of I and learns the SPI value form the ESP_info 504 parameter and forwards it to the Responder 506 6. To complete the base exchange, R sends the message R2 to I. 508 7. On receiving R2, FW(I) verifies the signature of R. Accordingly, 509 it earns the SPI value from the ESP_info parameter and forwards 510 it to the Initiator. 512 Here, the problem with this asymmetric base exchange is that the SPI 513 needed for the FW(I) is sent through the I2 message, which flows 514 through the FW(R) and the SPI needed for for the FW(I) is sent to 515 FW(R). 517 The topology shown in Figure 8 shows a scenario where messages R1/R2 518 are traversed by middlebox FW(I) and messages I1/I2 traverse 519 middlebox FW(R). These scenarios might be found in larger networks 520 with routing asymmetry and multi-homed networks. Today, in many 521 cases a state synchronization protocol is used between these two 522 middleboxes to make them apear as a single device and therefore 523 avoiding problems. 525 A solution for dealing with NAT traversal is simpler compared to 526 firewall traversal. With one single NAT between the HIP nodes, all 527 messages of the base exchange are forced to pass through it. With 528 firewalls, it becomes obvious that the nice property of a NAT with 529 respect to the symmetric forwarding path is lost and here the 530 individual firewalls are unable to create the necessary firewall 531 pinholes. SPI(I) is exchanged in I2 message (ESP_info(I)) through 532 firewall 1, however firewall 2 only needs it. Similarly firewall 2 533 needs SPI (R) which is sent in message R2 (ESP_info(I)) through 534 firewall 1. 536 Hence, problems related with routing asymmetry and firewall traversal 537 are : 539 1. When hosts are behind multiple incoming firewalls, they are 540 unable to decide to which firewall they have to signal the 541 appropriate SPI values. 543 2. The second problem is to secure the SPI signalling message from 544 the end host to the FW. Since the end hosts authenticate and 545 authorize to the FW that lets outgoing packets, they share keys 546 only with them. However, as mentioned earlier, they, somehow, 547 need to signal the SPI value to the FW on the other end which 548 forwards incoming packets. 550 5.2. Data Receiver behind a NAT 552 This scenario explains the full operation during the HIP base 553 exchange between the Initiator and the Responder, where the Responder 554 is assumed to be situated behind a NAT and registered with the 555 rendevous server (RVS) to facilitate its reachability. 557 ------- 558 /// \\\ 559 1. DNS Look Up | | 560 +--------------> DNS 561 | | | 562 | +-----------\\\ /// 563 | | ------- 1'. Registration 564 | | +------------------------+ 565 | | | | 566 | | | | 567 | |2. IP_RVS,HIT_R | | 568 | | v | 569 | | +-----+ +-----+ | 570 | | |RVS | | | | 571 | v +----->| +->| | | 572 ++--------+ 3. I1 | +-----+ | | 3.'I1 +---------+ 573 | +-----------+ | +---------->| | 574 |Initiator| | | |Responder| 575 | | 4. Base Exchg | NAT | | | 576 +---------+ <-------------------------+-----+---------> +--+------+ 577 | | | 578 | |1''.Registration | 579 | |<----------------+ 580 +-----+ 582 Figure 9: HIP Responder with RVS and NAT 584 Figure 9 shows the pictorial representaton of the operation. 586 o Initiator looks up the DNS in order to find the connection 587 parameters for the responder, This is typically done by querying 588 the DNS with the corresponding FQDN. 590 o Since the responder is registerd with the RVS, the DNS record will 591 contain the IP of the RVS and the HIT of the responder. 593 o The Initiator, now, contacts the RVS by sending I1 message, the 594 RVS relays the message to the responder. If the responder is 595 situated behind a NAT, it must inform the NAT, beforehand, to 596 allow the HIP base exchange packets to be traversed via the NAT. 598 This typically requires a registration mechanism to siganl the 599 NAT. 601 o The NAT forwards the HIP packets and actively participates in the 602 base exchange. If ESP traffic information is exchanged, the 603 middlebox will also learn the flow identifier. 605 Here, the NAT might require authentication and authorization from the 606 endhosts in order to enable a NAT binding for the requesting hosts. 607 This can be done achieved by performing middlebox signaling, the 608 requirements for such solution is explained in Section 6. 610 6. Requirements for HIP Middlebox Solution 612 This section presents a few high-level requirements that are derived 613 from the given problem statement. A novel middlebox signaling 614 approach has to accomplish the following goals: 616 o Add some authentication and authorization capabilities to the NAT/ 617 Firewall traversal. Many NAT/Firewall traversal solutions do not 618 allow the end host to interact with the middlebox. As a 619 consequence, some security vulnerabilities are introduced 620 e.g.,denial of service. 622 o Add secure firewall traversal functionality as another type of 623 middlebox signaling by using triplet. as a substitute for the traditional < source 625 IP, destination IP, source port, destination port, transport 626 protocol> information. 628 It is recommended that a solution for HIP-aware middlebox signaling 629 needs to have the following properties: 631 o A HIP-aware NAT/FW MUST be able to authenticate the entity 632 requesting a NAT binding or a firewall pinhole. 634 o A HIP-aware NAT/FW MUST be able to intercept HIP messages in order 635 to extract the flow identifier information and other related 636 information. A HIP-aware NAT/FW MUST be able to distinguish these 637 messages. 639 o A HIP-aware NAT/FW MUST authorize the entity requesting a NAT 640 binding or a firewall pinhole before storing state information. 641 This requirement might be accomplished by identity based 642 authorization or an identity independent authorization mechanism. 644 o A NAT/FW node MUST NOT introduce denial of service attacks. 646 o A potential solution MUST respect the property of some middleboxes 647 which do not allow traffic (data and signaling traffic) to 648 traverse the middlebox without proper authorization. 650 Some requirements are taken from [I-D.ietf-nsis-nslp-natfw]. 652 7. Security Considerations 654 In this document, a problem statement is given and scenarios are 655 described that lead to a number of requirements, which focusses on 656 security at a higher level of abstraction. However, this document 657 does not perform a detailed security analysis for a HIP-aware 658 middlebox solution. 660 The authors recommend that, atmost care should be taken when 661 solutions are developed and the solution must not introduce new 662 security vulnerabilities to the middlebox. 664 8. Contributors 666 We would like to thank Aarthi Nagarajan, Vesa Torvinen, Jochen 667 Grimminger and Jukka Ylitalo for their help with initial versions of 668 this document. 670 9. Acknowledgements 672 The authors would like to thank Pekka Nikander, Dieter Gollmann and 673 Tuomas Aura for their feedback to this document. 675 This document is a byproduct of the Ambient Networks Project, 676 partially funded by the European Commission under its Sixth Framework 677 Programme. It is provided "as is" and without any express or implied 678 warranties, including, without limitation, the implied warranties of 679 fitness for a particular purpose. The views and conclusions 680 contained herein are those of the authors and should not be 681 interpreted as necessarily representing the official policies or 682 endorsements, either expressed or implied, of the Ambient Networks 683 Project or the European Commission. 685 10. References 687 10.1. Normative References 689 [I-D.ietf-hip-base] 690 Moskowitz, R., "Host Identity Protocol", 691 draft-ietf-hip-base-06 (work in progress), June 2006. 693 [I-D.ietf-hip-esp] 694 Jokela, P., "Using ESP transport format with HIP", 695 draft-ietf-hip-esp-04 (work in progress), October 2006. 697 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 698 Requirement Levels", March 1997. 700 10.2. Informative References 702 [I-D.ietf-hip-mm] 703 Nikander, P., "End-Host Mobility and Multihoming with the 704 Host Identity Protocol", draft-ietf-hip-mm-04 (work in 705 progress), June 2006. 707 [I-D.ietf-nsis-nslp-natfw] 708 Stiemerling, M., "NAT/Firewall NSIS Signaling Layer 709 Protocol (NSLP)", draft-ietf-nsis-nslp-natfw-12 (work in 710 progress), June 2006. 712 [I-D.irtf-hiprg-nat] 713 Stiemerling, M., "NAT and Firewall Traversal Issues of 714 Host Identity Protocol (HIP) Communication", 715 draft-irtf-hiprg-nat-03 (work in progress), June 2006. 717 [I-D.nikander-hip-path] 718 Nikander, P., "Preferred Alternatives for Tunnelling HIP 719 (PATH)", draft-nikander-hip-path-01 (work in progress), 720 March 2006. 722 [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the 723 Internet Protocol", RFC 2401, November 1998. 725 [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address 726 Translator (NAT) Terminology and Considerations", 727 RFC 2663, August 1999. 729 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 730 Address Translator (Traditional NAT)", RFC 3022, 731 January 2001. 733 [RFC3715] Aboba, B. and W. Dixon, "IPsec-Network Address Translation 734 (NAT) Compatibility Requirements", RFC 3715, March 2004. 736 [RFC3947] Kivinen, T., A. Huttunen, A., Swander, B., and V. Volpe, 737 "Negotiation of NAT-Traversal in the IKE", RFC 3947, 738 January 2005. 740 [RFC3948] A. Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and 741 M. Stenberg, "UDP Encapsulation of IPsec Packets", 742 RFC 3948, January 2005. 744 [RFC4080] Hancock, R., "Next Steps in Signaling: Framework", 745 RFC 4080, November 2004. 747 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 748 RFC RFC4303, December 2005. 750 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 751 RFC 3948, September 2004. 753 [RFC4423] Moskowitz, R. and P. Nikandar, "Host Identity Protocol 754 (HIP) Architecture", RFC RFC4423, May 2006. 756 Authors' Addresses 758 Hannes Tschofenig 759 Siemens Networks GmbH & Co KG 760 Otto-Hahn-Ring 6 761 Munich, Bavaria 81739 762 Germany 764 Phone: +49 89 636 40390 765 Email: Hannes.Tschofenig@siemens.com 766 URI: http://www.tschofenig.com 768 Murugaraj Shanmugam 769 Siemens Networks GmbH & Co KG 770 Otto-Hahn-Ring 6 771 Munich, Bayern 81739 772 Germany 774 Email: murugaraj.shanmugam@siemens.com 776 Full Copyright Statement 778 Copyright (C) The Internet Society (2006). 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 AND THE INTERNET 787 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 788 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 789 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).