idnits 2.17.00 (12 Aug 2021) /tmp/idnits16990/draft-tschofenig-hiprg-hip-natfw-traversal-04.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 802. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 779. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 786. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 792. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 6, 2006) is 5920 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 728, but no explicit reference was found in the text == Unused Reference: 'RFC4303' is defined on line 746, 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-esp has been published as RFC 5202 ** Downref: Normative reference to an Experimental draft: draft-ietf-hip-esp (ref. 'I-D.ietf-hip-esp') == Outdated reference: draft-ietf-hip-arch has been published as RFC 4423 == 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 == Outdated reference: A later version (-01) exists of draft-nikander-hip-path-00 -- Obsolete informational reference (is this intentional?): RFC 2401 (Obsoleted by RFC 4301) -- Duplicate reference: RFC3948, mentioned in 'RFC4306', was also mentioned in 'RFC3948'. Summary: 6 errors (**), 0 flaws (~~), 11 warnings (==), 9 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 Expires: September 7, 2006 Siemens AG 5 March 6, 2006 7 Traversing HIP-aware NATs and Firewalls: Problem Statement and 8 Requirements 9 draft-tschofenig-hiprg-hip-natfw-traversal-04.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 September 7, 2006. 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 to 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 66 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 6 67 4. HIP with Middleboxes . . . . . . . . . . . . . . . . . . . . . 8 68 4.1. HIP Base Exchange with middleboxes . . . . . . . . . . . . 8 69 4.2. HIP Base Exchange with ESP Parameters and Middleboxes . . 9 70 4.3. HIP Mobility/Multihoming Exchange with Middleboxes . . . . 10 71 5. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 13 72 5.1. Different Firewalls at Initiator for outgoing and 73 incoming packets . . . . . . . . . . . . . . . . . . . . . 13 74 5.2. Data Receiver behind a NAT . . . . . . . . . . . . . . . . 15 75 6. Requirements for HIP Middlebox Solution . . . . . . . . . . . 17 76 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18 77 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 19 78 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20 79 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 80 10.1. Normative References . . . . . . . . . . . . . . . . . . . 21 81 10.2. Informative References . . . . . . . . . . . . . . . . . . 21 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 83 Intellectual Property and Copyright Statements . . . . . . . . . . 24 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], [I-D.ietf-hip- 145 base], [I-D.ietf-hip-esp] and [I-D.ietf-hip-arch] 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 an 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]. The NAT traversal approaches described in 185 [RFC3947] and [RFC4306] allows the end hosts to detect one or more 186 NATs in between them and [RFC3948] proposes to use the UDP 187 encapsulation of IPsec ESP packets to traverse NATs. 189 If HIP uses IPsec protection for the data traffic then the flow 190 identifier will take the shape of . Although HIP is described as a two-party protocol, middle 192 boxes are supposed to intercept the base exchange messages to learn 193 the flow identifier and to process them correctly. In other words, a 194 multi party protocol is created such that the flow identifier is 195 available to middle boxes between the HIP hosts. To achieve this, 196 HIP aims to interact with middleboxes actively whereby these devices 197 need to understand the HIP protocol and they need to be involved in 198 the protocol exchange. 200 This interaction, obviously, requires the middleboxes to verify the 201 authenticity of the base exchange messages in order to learn the flow 202 identifier and to create a state i.e., NAT binding or a pinhole. In 203 this context, to provide proper security, middleboxes should not be 204 vulnerable to denial of service attacks and might want to 205 authenticate or authorize entities before creating state information. 206 Note that the IPsec SA is unidirectional and therefore two IPsec SAs 207 (with two different SPIs, ESP_info contains the SPI value) have to be 208 established. 210 Finally, End hosts, behind middleboxes especially NATs, require the 211 following steps to facilitate its reachability. 213 1. Connection, end host connects to the server, while doing that it 214 may also identify the middleboxes. 216 2. Registration, end host registers with the middlebox in order to 217 inform the middlebox to relay its traffic. 219 3. Keep-alive, end host maintains the NAT registration by sending 220 heart-beat messages. 222 4. Messaging, end host receives the solicited traffic. 224 HIP hosts can also make use of such procedures by binding their HITs 225 (static identifier) with the middlebox to be connected, anywhere. 226 Evidently, this requires the HIP hosts to perform a explicit 227 registration mechanism with the middleboxes. 229 HIP also provides a way to deal with legacy NATs, as described in 230 [I-D.nikander-hip-path]. To support this functionality, it is 231 necessary to provide UDP encapsulation for both HIP signaling and 232 IPsec packets. Legacy NAT traversal does not require NATs to be HIP 233 aware or to understand the HIP message exchange. 235 4. HIP with Middleboxes 237 This section describes the message exchange between the Initiator and 238 the Responder, in which some of them situated behind a middlebox. 239 Curently, this document explains the interaction of middlebox with 240 plain HIP base exchange and the HIP base exchange carrying ESP 241 payloads. However, this draft can also be extended to support other 242 mechanisms for data traffic protection. 244 4.1. HIP Base Exchange with middleboxes 246 Assume that the initiator starts the HIP base exchange, Figure 1 247 shows the HIP base exchange traversing a middlebox. Note that if a 248 host wants to be contacted by the other peers, it needs some other 249 mechanisms to signal its public address to the peers and, if 250 necessary, should also inform the middlebox to allow the peers. 252 I1 +-----+ I1 253 +-------------------->| |----------------------+ 254 | | | | 255 | | | | 256 R1 | | R1 v 257 +---------+ <-------------| |<---------------- +---------+ 258 |Initiator| I2 | | I2 |Responder| 259 +---------+ ------------->| |----------------> +---------+ 260 ^ | | | 261 | | | | 262 | R2 | | R2 | 263 +---------------------| |<----------------------+ 264 +-----+ 265 Middlebox 267 Figure 1: HIP Base Exchange and middleboxes 269 Subsequently, the HIP base exchange is depicted in more detail. 271 I -> R: I1: Trigger exchange 273 I <- R: R1: (Puzzle, {D-H(R), HI(R), HIP Transform})SIG 275 I -> R: I2: {Solution, LSI(I),D-H(I), 276 HIP Transform, {H(I)}SK }SIG 278 I <- R: R2: {LSI(R), HMAC}SIG 280 Here, the base exchange becomes vulnerable to a DoS attack (for the 281 middleboxes) because the initiator's HI is encrypted in the I2 packet 282 and the middleboxes are unable to verify the I2 message. As a 283 consequence, an attacker may send spoofed I2 messages before the 284 authentic initiator does that. 286 When HIP is used with HIP-aware NAT devices, the checksum, computed 287 over the source and destination address, in the IP header must be 288 recomputed. Additionally, it might be necessary to include support 289 for storing the respective HITs and host identities. 291 4.2. HIP Base Exchange with ESP Parameters and Middleboxes 293 This section explains the HIP base exchange, carrying ESP parameters, 294 together with the middleboxes and describes how the middleboxes 295 behave during the base exchange. Figure 3 shows the corresponding 296 message exchange traversing a middlebox. 298 I1 +-----------+ I1 299 +-------------------->| |----------------------+ 300 | | | | 301 | | | | 302 R1 | Intercept | R1 v 303 +---------+ <-------------| the flow |<---------------- +---------+ 304 |Initiator| I2 | identifer | I2 |Responder| 305 +---------+ ------------->| +---------+ 306 ^ | SPI,ESP> | 307 | | | | 308 | R2 | | R2 | 309 +---------------------| |<----------------------+ 310 +-----------+ 311 middlebox 313 Figure 3: ESP Transport Format with HIP Base Exchange and Middleboxes 315 Subsequently, the HIP with ESP exchange is described in more detail. 317 I -> R: I1: Trigger exchange 319 I <- R: R1: {Puzzle, D-H(R), HI(R), ESP Transform, 320 HIP Transform }SIG 322 I -> R: I2: {Solution, LSI(I), ESP_info(I), D-H(I), 323 ESP_Transform, HIP Transform, {H(I)}SK }SIG 325 I <- R: R2: {LSI(R), ESP_info(R), HMAC}SIG 327 A potential responsibility of the middlebox, as shown in Figure 3, 328 can be the following 330 o Intercept the signaling messages 332 o Authenticate and authorize the HIP nodes by verifying the 333 signatures. 335 o Process the flow identifier information 337 o Perform actions according to the state machine 339 o Create state based on the content of message I2 with ESP_info(I) 340 and R2 with ESP_info(R). Additionally, it might be necessary to 341 include support for storing the respective HITs and host 342 identities. 344 The middleboxes should participate in the signaling messages and has 345 to learn the flow identifier to pass the subsequent data traffic. 347 Here, together with the spoofed I2 message, an attacker may send a 348 bogus SPI value, which will result in an inconsistent state at 349 NAT/FW. 351 4.3. HIP Mobility/Multihoming Exchange with Middleboxes 353 This section explains the HIP mobility and multihoming extensions for 354 the HIP hosts [I-D.ietf-hip-mm] together with the middleboxes. 355 Assume that the initiator moves after the base exchange and wants to 356 inform the responder. During this procedure, the Initiator wants to 357 start the rekeying proceudre in order to establish new keys. 358 Figure 5 shows the mobility message exchange, traversing a middlebox. 359 Note that this draft explains only one possible exchange for 360 mobility, [I-D.ietf-hip-mm] provides a detailed message exchange for 361 other variants such as rekeying initiated by responder. 363 +-----+ UPDATE SEQ 364 +----------> | |--------------------------------------+ 365 | | | UPDATE ACK | 366 | +------ | |---------------------------------+ | 367 | | | | | | 368 | v | | | v 369 +---------+ | | +---------+ 370 |Initiator| | | |Responder| 371 +---------+ | | +---------+ 372 | | | ^ 373 | | | ACK | 374 +------ | |----------------------------------+ 375 | | 376 +-----+ 377 middlebox 379 Figure 5: HIP Mobility Exchange with Middleboxee 381 Subsequently, the HIP mobility exchange is depicted below. 383 I -> R:UPDATE SEQ (ESP_INFO(I), LOCATOR, [DIFFIE_HELLMAN], SEQ) 385 I <- R:UPDATE ACK (ESP_INFO(R), SEQ, ACK, 386 [DIFFIE_HELLMAN], ECHO_REQUEST) 388 I -> R:ACK (ACK, ECHO_RESPONSE) 390 In such cases, a middlebox should, 392 o Intercept the HIP mobility messages 394 o Authenticate and authorize the HIP nodes by verifying the 395 signatures 397 o Process the flow identifier information and perform actions 398 according to the state machine 400 o Update the location of the initiator based on the "LOCATOR 401 parameter" in the UPDATE messages, also in case of rekeying, the 402 middlebox should update the state based on the information in the 403 ESP_info parameter, together with the respective HITs and host 404 identities 406 The problem with the mobilty exchange, when the host is behind a NAT, 407 is that the address in the LOCATOR parameter is a private address and 408 not globally routable. 410 [Editor's Note: Some possible solutions, to overcome this problem, 411 are to use RVS server as a contact point, initiator should find the 412 public address and somehow has to inform it to the responder and the 413 NAT has to bind the new private address and the public address.] 415 In case of multihoming scenario, in which the hosts can be reached by 416 several addresses, the NAT handling becomes complicated. For 417 example, if a host is multihomed, assume that the initial HIP and 418 security associations are established with a public IP address of the 419 host. Later, if it decides to use the address which is behind a NAT, 420 then the "new" NAT has to create a binding between the hosts. 422 +---------+ 1. Base Exchange +---------+ 423 |Initiator|<------------------------------------->|Responder| 424 +---------+ +---------+ 425 ^ ^ 426 | +------+ | 427 | 2. Update | NAT | 2. Update | 428 +-------------------->| |----------------------+ 429 +------+ 430 Intercept the flow id 432 Figure 7: Multihoming and Middleboxes 434 Figure 7 depicts the one possible scenario in which the initiator is 435 multihomed. 437 1. If the Initiator notices the change, it can update the new 438 address by using "Locator" parameter in the UPDATE messages (or 439 can inform the NAT). By this way, a NAT can create a new binding 440 by intercepting the UPDATE messages. 442 2. If the Responder itself decides to send the traffic to the 443 previously exchanged address (informed as alternative address), 444 then the NAT will disrupt the connection, since it does not have 445 necessary state information to handle the traffic. A more 446 detailed analysis, about multihoming, will be done in the future 447 version of this draft. 449 5. Scenarios 451 The following section describes some sample scenarios, in the context 452 of involving middleboxes, to learn the flow identifier: 454 5.1. Different Firewalls at Initiator for outgoing and incoming packets 456 This scenario assumes that both the initiator I and the responderR is 457 situated behind firewalls named FW(I) and FW(R) respectively. FW(I) 458 is for the incoming packets to I and FW(R) is for the incoming 459 packets to R. It is necessary that both the firewalls must learn the 460 flow identifier information and should store the state 461 to forward IPsec protected payload packets. This scenario is 462 illustrated in Figure 8 464 I1 +----------+ I1 465 +--------------------> | Firewall | -----------------------+ 466 | I2 | FW(R) | I2 | 467 | +-----------------> | | ------------------+ | 468 | | +----------+ v v 469 +---------+ +---------+ 470 |Initiator| |Responder| 471 +---------+ +---------+ 472 ^ ^ R1 +----------+ R1 | | 473 | +------------------ | Firewall | <-------------------+ | 474 | R2 | FW(I) | R2 | 475 +--------------------- | | <-----------------------+ 476 +----------+ 478 ............... IPsec ESP protected traffic (SPI(R)).........> 479 <.............. IPsec ESP protected traffic (SPI(I)).......... 481 Legend: 482 --- = HIP signaling 483 ... = IPsec protected data traffic 485 Figure 8: End hosts behind FWs 487 1. I1 packet is sent from the initiator I to responder R. 489 2. FW(R) forwards the packet to the Responder. 491 3. Then, R sends R1 message with puzzle,D-H key protected with the 492 signature of R. 494 4. FW(I) forward the packet to the Initiator. 496 5. Now, I sends the I2 packet, on receiving I2, FW(R) verifies the 497 signature of I and learns the SPI value form the ESP_info 498 parameter and forwards it to the Responder 500 6. To complete the base exchange, R sends the message R2 to I. 502 7. On receiving R2, FW(I) verifies the signature of R. Accordingly, 503 it earns the SPI value from the ESP_info parameter and forwards 504 it to the Initiator. 506 Here, the problem with this asymmetric base exchange is that the SPI 507 needed for the FW(I) is sent through the I2 message, which flows 508 through the FW(R) and the SPI needed for for the FW(I) is sent to 509 FW(R). 511 The topology shown in Figure 8 shows a scenario where messages R1/R2 512 are traversed by middlebox FW(I) and messages I1/I2 traverse 513 middlebox FW(R). These scenarios might be found in larger networks 514 with routing asymmetry and multi-homed networks. Today, in many 515 cases a state synchronization protocol is used between these two 516 middleboxes to make them apear as a single device and therefore 517 avoiding problems. 519 A solution for dealing with NAT traversal is simpler compared to 520 firewall traversal. With one single NAT between the HIP nodes, all 521 messages of the base exchange are forced to pass through it. With 522 firewalls, it becomes obvious that the nice property of a NAT with 523 respect to the symmetric forwarding path is lost and here the 524 individual firewalls are unable to create the necessary firewall 525 pinholes. SPI(I) is exchanged in I2 message (ESP_info(I)) through 526 firewall 1, however firewall 2 only needs it. Similarly firewall 2 527 needs SPI (R) which is sent in message R2 (ESP_info(I)) through 528 firewall 1. 530 Hence, problems related with routing asymmetry and firewall traversal 531 are : 533 1. When hosts are behind multiple incoming firewalls, they are 534 unable to decide to which firewall they have to signal the 535 appropriate SPI values. 537 2. The second problem is to secure the SPI signalling message from 538 the end host to the FW. Since the end hosts authenticate and 539 authorize to the FW that lets outgoing packets, they share keys 540 only with them. However, as mentioned earlier, they, somehow, 541 need to signal the SPI value to the FW on the other end which 542 forwards incoming packets. 544 5.2. Data Receiver behind a NAT 546 This scenario explains the full operation during the HIP base 547 exchange between the Initiator and the Responder, where the Responder 548 is assumed to be situated behind a NAT and registered with the 549 rendevous server (RVS) to facilitate its reachability. 551 ------- 552 /// \\\ 553 1. DNS Look Up | | 554 +--------------> DNS 555 | | | 556 | +-----------\\\ /// 557 | | ------- 1'. Registration 558 | | +------------------------+ 559 | | | | 560 | | | | 561 | |2. IP_RVS,HIT_R | | 562 | | v | 563 | | +-----+ +-----+ | 564 | | |RVS | | | | 565 | v +----->| +->| | | 566 ++--------+ 3. I1 | +-----+ | | 3.'I1 +---------+ 567 | +-----------+ | +---------->| | 568 |Initiator| | | |Responder| 569 | | 4. Base Exchg | NAT | | | 570 +---------+ <-------------------------+-----+---------> +--+------+ 571 | | | 572 | |1''.Registration | 573 | |<----------------+ 574 +-----+ 576 Figure 9: HIP Responder with RVS and NAT 578 Figure 9 shows the pictorial representaton of the operation. 580 o Initiator looks up the DNS in order to find the connection 581 parameters for the responder, This is typically done by querying 582 the DNS with the corresponding FQDN. 584 o Since the responder is registerd with the RVS, the DNS record will 585 contain the IP of the RVS and the HIT of the responder. 587 o The Initiator, now, contacts the RVS by sending I1 message, the 588 RVS relays the message to the responder. If the responder is 589 situated behind a NAT, it must inform the NAT, beforehand, to 590 allow the HIP base exchange packets to be traversed via the NAT. 592 This typically requires a registration mechanism to siganl the 593 NAT. 595 o The NAT forwards the HIP packets and actively participates in the 596 base exchange. If ESP traffic information is exchanged, the 597 middlebox will also learn the flow identifier. 599 Here, the NAT might require authentication and authorization from the 600 endhosts in order to enable a NAT binding for the requesting hosts. 601 This can be done achieved by performing middlebox signaling, the 602 requirements for such solution is explained in Section 6. 604 6. Requirements for HIP Middlebox Solution 606 This section presents a few high-level requirements that are derived 607 from the given problem statement. A novel middlebox signaling 608 approach has to accomplish the following goals: 610 o Add some authentication and authorization capabilities to the NAT/ 611 Firewall traversal. Many NAT/Firewall traversal solutions do not 612 allow the end host to interact with the middlebox. As a 613 consequence, some security vulnerabilities are introduced 614 e.g.,denial of service. 616 o Add secure firewall traversal functionality as another type of 617 middlebox signaling by using triplet. as a substitute for the traditional < source 619 IP, destination IP, source port, destination port, transport 620 protocol> information. 622 It is recommended that a solution for HIP-aware middlebox signaling 623 needs to have the following properties: 625 o A HIP-aware NAT/FW MUST be able to authenticate the entity 626 requesting a NAT binding or a firewall pinhole. 628 o A HIP-aware NAT/FW MUST be able to intercept HIP messages in order 629 to extract the flow identifier information and other related 630 information. A HIP-aware NAT/FW MUST be able to distinguish these 631 messages. 633 o A HIP-aware NAT/FW MUST authorize the entity requesting a NAT 634 binding or a firewall pinhole before storing state information. 635 This requirement might be accomplished by identity based 636 authorization or an identity independent authorization mechanism. 638 o A NAT/FW node MUST NOT introduce denial of service attacks. 640 o A potential solution MUST respect the property of some middleboxes 641 which do not allow traffic (data and signaling traffic) to 642 traverse the middlebox without proper authorization. 644 Some requirements are taken from [I-D.ietf-nsis-nslp-natfw]. 646 7. Security Considerations 648 In this document, a problem statement is given and scenarios are 649 described that lead to a number of requirements, which focusses on 650 security at a higher level of abstraction. However, this document 651 does not perform a detailed security analysis for a HIP-aware 652 middlebox solution. 654 The authors recommend that, atmost care should be taken when 655 solutions are developed and the solution must not introduce new 656 security vulnerabilities to the middlebox. 658 8. Contributors 660 We would like to thank Aarthi Nagarajan, Vesa Torvinen, Jochen 661 Grimminger and Jukka Ylitalo for their help with initial versions of 662 this document. 664 9. Acknowledgements 666 The authors would like to thank Pekka Nikander, Dieter Gollmann and 667 Tuomas Aura for their feedback to this document. 669 This document is a byproduct of the Ambient Networks Project, 670 partially funded by the European Commission under its Sixth Framework 671 Programme. It is provided "as is" and without any express or implied 672 warranties, including, without limitation, the implied warranties of 673 fitness for a particular purpose. The views and conclusions 674 contained herein are those of the authors and should not be 675 interpreted as necessarily representing the official policies or 676 endorsements, either expressed or implied, of the Ambient Networks 677 Project or the European Commission. 679 10. References 681 10.1. Normative References 683 [I-D.ietf-hip-base] 684 Moskowitz, R., "Host Identity Protocol", 685 draft-ietf-hip-base-05 (work in progress), March 2006. 687 [I-D.ietf-hip-esp] 688 Jokela, P., "Using ESP transport format with HIP", 689 draft-ietf-hip-esp-02 (work in progress), March 2006. 691 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 692 Requirement Levels", March 1997. 694 10.2. Informative References 696 [I-D.ietf-hip-arch] 697 Moskowitz, R. and P. Nikander, "Host Identity Protocol 698 Architecture", draft-ietf-hip-arch-03 (work in progress), 699 August 2005. 701 [I-D.ietf-hip-mm] 702 Nikander, P., "End-Host Mobility and Multihoming with the 703 Host Identity Protocol", draft-ietf-hip-mm-03 (work in 704 progress), March 2006. 706 [I-D.ietf-nsis-nslp-natfw] 707 Stiemerling, M., "NAT/Firewall NSIS Signaling Layer 708 Protocol (NSLP)", draft-ietf-nsis-nslp-natfw-09 (work in 709 progress), February 2006. 711 [I-D.irtf-hiprg-nat] 712 Stiemerling, M., "Middlebox Traversal Issues of Host 713 Identity Protocol (HIP) Communication", 714 draft-irtf-hiprg-nat-01 (work in progress), January 2006. 716 [I-D.nikander-hip-path] 717 Nikander, P., "Preferred Alternatives for Tunnelling HIP 718 (PATH)", draft-nikander-hip-path-00 (work in progress), 719 February 2005. 721 [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the 722 Internet Protocol", RFC 2401, November 1998. 724 [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address 725 Translator (NAT) Terminology and Considerations", 726 RFC 2663, August 1999. 728 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 729 Address Translator (Traditional NAT)", RFC 3022, 730 January 2001. 732 [RFC3715] Aboba, B. and W. Dixon, "IPsec-Network Address Translation 733 (NAT) Compatibility Requirements", RFC 3715, March 2004. 735 [RFC3947] Kivinen, T., A. Huttunen, A., Swander, B., and V. Volpe, 736 "Negotiation of NAT-Traversal in the IKE", RFC 3947, 737 January 2005. 739 [RFC3948] A. Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and 740 M. Stenberg, "UDP Encapsulation of IPsec Packets", 741 RFC 3948, January 2005. 743 [RFC4080] Hancock, R., "Next Steps in Signaling: Framework", 744 RFC 4080, November 2004. 746 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 747 RFC RFC4303, December 2005. 749 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 750 RFC 3948, September 2004. 752 Authors' Addresses 754 Hannes Tschofenig 755 Siemens AG 756 Otto-Hahn-Ring 6 757 Munich, Bayern 81739 758 Germany 760 Email: Hannes.Tschofenig@siemens.com 762 Murugaraj Shanmugam 763 Siemens AG 764 Otto-Hahn-Ring 6 765 Munich, Bayern 81739 766 Germany 768 Email: murugaraj.shanmugam@siemens.com 770 Intellectual Property Statement 772 The IETF takes no position regarding the validity or scope of any 773 Intellectual Property Rights or other rights that might be claimed to 774 pertain to the implementation or use of the technology described in 775 this document or the extent to which any license under such rights 776 might or might not be available; nor does it represent that it has 777 made any independent effort to identify any such rights. Information 778 on the procedures with respect to rights in RFC documents can be 779 found in BCP 78 and BCP 79. 781 Copies of IPR disclosures made to the IETF Secretariat and any 782 assurances of licenses to be made available, or the result of an 783 attempt made to obtain a general license or permission for the use of 784 such proprietary rights by implementers or users of this 785 specification can be obtained from the IETF on-line IPR repository at 786 http://www.ietf.org/ipr. 788 The IETF invites any interested party to bring to its attention any 789 copyrights, patents or patent applications, or other proprietary 790 rights that may cover technology that may be required to implement 791 this standard. Please address the information to the IETF at 792 ietf-ipr@ietf.org. 794 Disclaimer of Validity 796 This document and the information contained herein are provided on an 797 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 798 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 799 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 800 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 801 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 802 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 804 Copyright Statement 806 Copyright (C) The Internet Society (2006). This document is subject 807 to the rights, licenses and restrictions contained in BCP 78, and 808 except as set forth therein, the authors retain all their rights. 810 Acknowledgment 812 Funding for the RFC Editor function is currently provided by the 813 Internet Society.