idnits 2.17.00 (12 Aug 2021) /tmp/idnits22952/draft-thiruvengadam-nsis-mip6-fw-08.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 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 804. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 815. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 822. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 828. 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 (November 16, 2007) is 5299 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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: '9' is defined on line 758, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 4487 (ref. '1') == Outdated reference: draft-ietf-nsis-nslp-natfw has been published as RFC 5973 ** Downref: Normative reference to an Experimental draft: draft-ietf-nsis-nslp-natfw (ref. '2') ** Obsolete normative reference: RFC 3775 (ref. '4') (Obsoleted by RFC 6275) == Outdated reference: draft-ietf-nsis-ntlp has been published as RFC 5971 == Outdated reference: draft-ietf-nsis-applicability-mobility-signaling has been published as RFC 5980 == Outdated reference: draft-ietf-mip6-auth-protocol has been published as RFC 4285 Summary: 5 errors (**), 0 flaws (~~), 7 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NSIS N. Steinleitner, Ed. 3 Internet-Draft X. Fu 4 Expires: May 19, 2008 Univ. Goettingen 5 F. Le 6 CMU 7 November 16, 2007 9 Mobile IPv6 - NSIS Interaction for Firewall traversal 10 draft-thiruvengadam-nsis-mip6-fw-08.txt 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on May 19, 2008. 37 Copyright Notice 39 Copyright (C) The IETF Trust (2007). 41 Abstract 43 Most of the firewalls deployed today are Mobile IPv6 unaware. 44 Widespread Mobile IPv6 deployment is not possible unless Mobile IPv6 45 messages can pass through these firewalls. One approach is to use a 46 signaling protocol to communicate with these firewalls and instruct 47 them to bypass these Mobile IPv6 messages. The goal of this document 48 is to describe the interaction between NSIS and Mobile IPv6 for 49 enabling Mobile IPv6 traversal. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 3. Mobile node behind a firewall . . . . . . . . . . . . . . . . 5 56 3.1. Binding updates . . . . . . . . . . . . . . . . . . . . . 5 57 3.2. Route optimization . . . . . . . . . . . . . . . . . . . . 5 58 3.3. Bi-directional tunneling . . . . . . . . . . . . . . . . . 7 59 3.4. Change of Firewalls . . . . . . . . . . . . . . . . . . . 8 60 3.5. Operations when MN is behind a firewall . . . . . . . . . 8 61 4. Correspondent Node behind a firewall . . . . . . . . . . . . . 10 62 4.1. Route Optimization . . . . . . . . . . . . . . . . . . . . 10 63 4.2. Bi-directional Tunneling . . . . . . . . . . . . . . . . . 12 64 4.3. Change of Firewalls . . . . . . . . . . . . . . . . . . . 13 65 4.4. Operations when CN is behind a firewall . . . . . . . . . 14 66 5. Home Agent behind a firewall . . . . . . . . . . . . . . . . . 15 67 5.1. Route Optimization . . . . . . . . . . . . . . . . . . . . 15 68 5.2. Bi-directional tunneling . . . . . . . . . . . . . . . . . 17 69 5.3. Operations when HA is behind a firewall . . . . . . . . . 17 70 6. Additional Discussions . . . . . . . . . . . . . . . . . . . . 19 71 7. Security Considerations . . . . . . . . . . . . . . . . . . . 20 72 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21 73 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 74 9.1. Normative References . . . . . . . . . . . . . . . . . . . 22 75 9.2. Informative References . . . . . . . . . . . . . . . . . . 22 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 77 Intellectual Property and Copyright Statements . . . . . . . . . . 24 79 1. Introduction 81 Route optimization, an integral part of Mobile IPv6 specification 82 does not work with state of the art firewalls that employ stateful 83 packet filtering (SPF). This problem is well described in [1]. The 84 other mode of communication in Mobile IPv6, namely bi-directional 85 tunneling, also do not work under some firewall placements. Apart 86 from this, the Mobile IPv6 binding updates (encapsulated using IPsec 87 ESP) packets also have problems with firewall traversal. To tackle 88 these issues, one approach is to utilize a signaling protocol to 89 install some firewall rules for allowing these Mobile IPv6 messages 90 to pass through. The NSIS NAT/FW NSLP, as described in [2], allows 91 to establish, maintain and delete middlebox state (i.e., NAT bindings 92 and Firewall rules), and allow packets to traverse these boxes. This 93 protocol thus provides a possible way to address the aforementioned 94 problem. This document describe the considerations of NSIS NAT/FW 95 NSLP, especially the involved messages and necessary firewall rules, 96 when firewalls are encountered in a Mobile IPv6 network. More 97 specifically, the following basic scenarios are studied individually. 99 o Mobile Node (MN) behind a firewall; 101 o Correspondent Node (CN) behind a firewall; 103 o Home Agent (HA) behind a firewall. 105 For every scenario, we will discuss how to apply NSIS signaling for 106 the routing modes. It has to be noted that a real scenario could 107 include a combination of some set of these cases. In any case, we 108 assume that the MN, the CN, the HA and the Firewalls (FWs) are NSIS 109 and NAT/FW NSLP aware. Also note that for every NSIS message, the 110 underlying GIST[5] level provides flow-id information which will be 111 used to install the firewall policies. 113 2. Terminology 115 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 116 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 117 document are to be interpreted as described in [3]. 119 Furthermore, we use the same terminology as in [4], [2], and [6]. 120 Apart from this, we use some abbreviations to describe the flow-id of 121 the NSIS messages: 123 o SA-Source Address, 125 o DA-Destination Address, 127 o SP-Source Port, 129 o DP-Destination Port, and 131 o an asterisk is used as wild-card. 133 The term 'DS' refers to data sender and the term 'DR' to data 134 receiver. 136 3. Mobile node behind a firewall 138 In Figure 1, the MN is protected by a firewall that employs stateful 139 packet filtering (SPF). The external CN and the HA are also shown in 140 the figure. The MN is located in a visited network and is expecting 141 to communicate with the CN. If the MN initiated normal data traffic 142 there is no problem with the SPF firewall, as the communication is 143 initiated from internal. 145 +----------------+ +----+ 146 | | | HA | 147 | | +----+ 148 | | Home Agent 149 | +----+ +----+ 150 | | MN | | FW | 151 | +----+ +----+ 152 | | +----+ 153 | | | CN | 154 | | +----+ 155 +----------------+ External CN 156 Network protected 157 by a firewall 159 Figure 1: MN behind the firewall 161 3.1. Binding updates 163 IPsec protected Binding Updates cause problems in some deployment 164 environments, as described in [1]. As a solution, NAT/FW NSLP can be 165 used to dynamically configure the firewall(s) to allow the IPsec 166 packets and associated traffic like IKE/IKEv2 packets to traverse, 167 before sending the binding updates. Therefore, IP Protocol ID 50 168 should be allowed in the filter policies in order to allow IPsec ESP 169 and IP Protocol ID 51 to allow IPsec AH. The firewall should also 170 allow IKE packets (to UDP port 500) to bypass. As the firewall is a 171 SPF, the subsequent Binding Acknowledgement from the HA to the CoA 172 can pass the firewall, as it matches an existing state inside the 173 firewall. 175 For the BU message (IPsec ESP in transport mode) from MN to HA, 176 the MN installs rules using CREATE for the flow-id: SA: CoA, DA: 177 HA, SPIx. 179 3.2. Route optimization 181 Immediately after moving into a new network, the MN acquires a new 182 CoA, performs the pinhole creation as described in section 183 Section 3.1 and runs the Binding Update to the HA. The HoTI message 184 from the MN is IPsec encapsulated in tunnel mode and as it does not 185 belong to the session initiated by the MN or match a previously 186 installed rule, it will be dropped by the firewall. Using CREATE, 187 the MN initiates NSIS signalling to the firewall and open pinholes 188 for the HoTI message. The message flow is shown in Figure 2. The 189 HoT message can re-use this pinhole and is able to reach the MN. 191 For the HoTI message (IPsec ESP in tunnel mode) from MN to HA, the 192 MN installs rules using the CREATE message for the flow-id: SA: 193 CoA, DA:HA, SPIx. 195 Network protected 196 +-------------------------+ 197 | | 198 | +-----+ +-----+ +----+ 199 | | |Binding Update| | | | 200 | | |-------->-----+ +--------->----------+ | 201 | | | | | Binding ACK | | 202 | | |--------<-----+ +---------<----------+ | 203 | | MN | CREATE | FW | | HA | 204 | | +-------->-----+ |--------->----------| | 205 | |(DS) | | | RESPONSE | | 206 | | +--------<-----+ |---------<----------| | 207 | | | HoTI | | | | 208 | | +-------->-----+ +--------->----------+ | 209 | | | | | HoT | | 210 | | +--------<-----+ +---------<----------+ | 211 | +-----+ +-----+ +----+ 212 | | ^ 213 +-------------------------+ | 214 v 215 +----+ 216 | CN | 217 |(DR)| 218 +----+ 219 ----- = signaling traffic Correspondent node 221 Figure 2: NSIS signaling for MN behind the firewall 223 The CoTI message and the CoT message can traverse the MN's ASP- 224 firewall, as the CoTI message is not IPsec encapsulated and the CoT 225 message correspond to the state previously installed by the CoTI 226 message. Once the RRT is successful, the binding update message is 227 sent to the CN. If the MN wants to continue sending data traffic, no 228 NSIS signaling is needed at all for this scenario. However, if the 229 CN wants to send data traffic and the rules installed before matching 230 again the addresses, the ports and the IPsec encapsulation, the 231 relevant packet filter rules have to be installed at the firewall. 232 If the rules installed before only matching again source and 233 destination address, the data traffic exchanged with the CN in RO- 234 case can also traverse the firewall with no need of installing 235 additional rules. However, that would allow all kind of traffic from 236 the CN and is rejected. Hence, the MN has to initiate sending data 237 traffic to the CN but this happens after the RRT. 239 For the data traffic from CN to MN the MN installs rules using EXT 240 for the flow-id: SA: CN, DA:CoA, SP: data application port, DP: 241 data application port. 243 3.3. Bi-directional tunneling 245 Consider the scenario where the MN is protected by a SPF. Even 246 though the MN had earlier initiated a connection for the purpose of 247 binding update, new filter rules have to be installed to allow the 248 tunnelled data traffic as the rules before installed rules match 249 again the addresses, the ports and the IPsec ESP encapsulation. The 250 message flow is shown in Figure 3. If the MN is the DS, no signaling 251 is needed at all. Otherwise, the MN open pinholes to let the data 252 messages traverse, with the help of EXT. 254 For the data traffic from HA to MN, the MN installs rules using 255 EXT for the flow-id: SA: HA, DA: CoA. Note these data messages 256 for which we do signaling, are IP- in-IP tunneled messages. 258 Protected network 259 +-------------------------+ 260 | | Home Agent 261 | +-----+ +-----+ +----+ 262 | | |Binding update| | | | 263 | | |------->------+ +--------->----------+ | 264 | | | | | Binding ACK | | 265 | | |-------<------+ +---------<----------+ | 266 | | MN | EXT | FW | | HA | 267 | |(DR) +------->------+ | | | 268 | | | RESPONSE | | | | 269 | | +-------<------+ | | | 270 | | | | | Data traffic | | 271 | | +*******<******+ +*********<**********+ | 272 | +-----+ +-----+ +----+ 273 | | * 274 +-------------------------+ ^ 275 * 276 +----+ 277 | CN | 278 |(DS)| 279 ***** = Data traffic +----+ 280 ----- = Signaling traffic Correspondent node 282 Figure 3: NSIS signaling for MN behind the firewall 284 3.4. Change of Firewalls 286 If the MN roams and attaches to a different firewall, the above- 287 mentioned routing methods will have problems in traversing the new 288 firewall. In this case the data sender (where it is MN or the CN or 289 the HA) should re-signaling to the firewall using NSIS and establish 290 the policies accordingly (mentioned above according to the routing 291 methods). 293 Since the NAT/FW NSLP rely on a soft-state approach, established 294 sessions will be automatically be teardown after a specified timeout 295 value. Thus it is not necessary to delete or teardown a session 296 after an MN roams to another network, as the protocol will do this by 297 it own. More discussions about a possible alternative way by tearing 298 down the established state are given in [7]. 300 3.5. Operations when MN is behind a firewall 302 In summary, when a firewall is located in MN's ASP, the MN configures 303 the firewall(s) using CREATE to let following messages traverse: 305 o Binding update messages (src: CoA, dst: HA, SPIx) (IPsec ESP in 306 transport mode) {for BU} 308 o HoTI message (src: CoA, dst: HA, SPIx) (IPsec ESP in tunnel mode) 309 {for RO} 311 MN configures the firewall(s) using EXT to let following traverse: 313 o for data traffic from HA to MN (src: HA, dst: CoA) {BT} 315 o for data traffic from CN to MN (src: CN, dst: CoA) {RO} 317 4. Correspondent Node behind a firewall 319 4.1. Route Optimization 321 In Figure 4, the CN is protected by a firewall that employs stateful 322 packet filtering. The external MN and its associated HA are also 323 shown in the figure. The MN communicates with the CN. If the CN 324 initiated normal data traffic there is no problem with the SPF, as 325 the communication is initiated from internal. 327 +----------------+ +----+ 328 | | | HA | 329 | | +----+ 330 | | Home Agent 331 | +----+ +----+ 332 | | CN | | FW | 333 | +----+ +----+ 334 | | +----+ 335 | | | MN | 336 | | +----+ 337 +----------------+ External Mobile 338 Network protected Node 339 by a firewall 341 Figure 4: CN behind the firewall 343 The MN moves out of its home network and has to perform the return 344 routability test before sending the binding update to the CN. It 345 sends a HoTI message through the HA to the CN and expects a HoT 346 message from the CN along the same path. It also sends a CoTI 347 message directly to the CN and expects CoT message in the same path 348 from the CN. The SPF will only allow packets that belong to an 349 existing session and hence both the packets (HoTI, CoTI) will be 350 dropped as these packets are Mobile IPv6 packets and these packets 351 have a different header structure. The existing rules at the 352 firewall might have been installed for some kind of data traffic. 354 +-----------------------+ Home Agent 355 | | +----+ 356 | +-----+ | HA | 357 | | | +----+ 358 |+----+ | | 359 || | | | CREATE +----+ 360 || +--------<-----+ +---------<----------+ | 361 || | RESPONSE | | | | 362 || +-------->-----+ FW +--------->----------+ | 363 || | | | CoTI | | 364 || CN +--------<-----+ +---------<----------+ MN | 365 || | CoT | | | | 366 ||(DR)+-------->-----+ +--------->----------+(DS)| 367 || | | | Binding update | | 368 || +--------<-----+ +---------<----------+ | 369 |+----+ +-----+ +----+ 370 | | Mobile 371 +-----------------------+ Node 372 Network protected 373 by a firewall 375 Figure 5: CN behind the firewall 377 As the RRT procedure cannot be executed, the firewall rules have to 378 be modified to allow these MIPv6 messages to go through. The MN 379 initiates the NSIS session by sending a CREATE message to the CN to 380 install rules for the CoTI message. The NSIS signaling to allow the 381 CoTI message is shown in Figure 5. 383 For the CoTI message from MN to CN, the MN installs rules using 384 CREATE for the flow-id: SA: CoA, DA: CN. 386 This allows the CoTI to reach the CN. If the MN signal as described 387 in section Section 3.2 the HoTI is able to reach the HA. 388 Nevertheless, the HoTI message from the HA to the CN is not able to 389 traverse, as it does not match any state at the CN's ASP-FW. 390 Therefore, either the HA or the CN has to signal install rules to let 391 the HoTI traverse. 393 If the HA initiates the pinhole creation, the CREATE message for 394 the HoTI message from HA to CN the flow-id will be: SA: HoA, DA: 395 CN. 397 If the CN initiates the pinhole creation, the EXT message for the 398 HoTI message from HA to CN the flow-id will be: SA: HoA, DA: CN. 400 When the MN receives both CoT and HoT messages, it performs binding 401 update to the CN which is possible, as the BU can re-uses the 402 previously installed rules. Note that the aforementioned signalling 403 was only to allow the Mobile IPv6 messages. 405 If the CN wants to continue sending data traffic (CN is the DS) to 406 the new CoA, it can do so without any additional signaling. This is 407 because the SPF will allow the traffic initiated by the nodes that it 408 protects. But if the MN wants to continue sending data traffic (MN 409 is the DS), it has to install filter rules for data traffic. The 410 prospect of combined signaling (for control and data traffic) could 411 be useful, but currently the NSIS NAT/FW protocol does not support 412 installing multiple rules at the same time. 414 For the data traffic from MN to CN, the MN installs rules using 415 CREATE for the flow-id: SA: CoA, DA:CN, SP: data application port, 416 DP: data application port. 418 This solution works with the assumption that the firewalls will allow 419 NSIS messages from external network to bypass with delayed packet 420 filter state establishment and authorization from the CN. However, 421 operators might be reluctant to allow NSIS message from external 422 network as this might lead to DoS attacks. The CN might therefore be 423 required to authorize the traversal of NSIS signaling message 424 implicitly to reduce unwanted traffic. 426 To avoid this, it is also possible to ask the CN to open pinholes in 427 the firewall on behalf of the MN. But this solution will not work in 428 some scenarios due to routing asymmetry as explained in [2]. 430 4.2. Bi-directional Tunneling 432 If the CN is protected by a SPF firewall, there is no need for any 433 signaling if the CN starts sending data traffic. The CN sends the 434 data traffic and hence the SPF will store relevant state information 435 and accepts packets from the reverse direction. 437 Protected network 438 +-------------------------+ 439 | | Home Agent 440 | +-----+ +-----+ +----+ 441 | | | | | | | 442 | | CN | EXT | FW | | HA | 443 | | +-------->-----+ | | | 444 | |(DR) | RESPONSE | | | | 445 | | +--------<-----+ | | | 446 | | | | | Data traffic | | 447 | | +**************+ +********************+ | 448 | +-----+ +-----+ +----+ 449 | | # 450 +-------------------------+ # 451 +----+ 452 | MN | 453 |(DS)| 454 ***** = Data traffic (both direction) +----+ 455 ----- = signaling traffic Correspondent node 456 ##### = tunneled traffic 458 Figure 6: NSIS signaling for CN behind the firewall 460 If the HA is the DS, then either the CN has to initiate the signaling 461 using EXT or the HA using CREATE, in order to configure the firewall 462 to allow the data traffic traverse from the HA to CN. The message 463 flow if the CN should signal for this pinhole is shown in Figure 6. 465 If the CN initiates the pinhole creation, the EXT message for the 466 data traffic from HA to CN the flow-id will be: SA: HA, DA: CN, 467 SP: data application port, DP: data application port. 469 If the HA initiates the pinhole creation, the CREATE message for 470 the data traffic from HA to CN the flow-id will be: SA: HA, DA: 471 CN, SP: data application port, DP: data application port. 473 4.3. Change of Firewalls 475 If the MN roams and attaches to a network with a different firewall, 476 the Mobile IPv6 protocol will be problematic again while traversing 477 the newly encountered firewall, as the firewall is not configured 478 appropriately. In this case the data sender (either the MN or the CN 479 for both Mobile IPv6 signalling and data traffic, or the HA in case 480 of Mobile IPv6 signaling traffic) should re-signal to the firewall 481 using NSIS and establish the policies accordingly (following the 482 similar procedures as described before). One possible enhancement 483 would be to use the context transfer protocol between the old and new 484 firewalls upon proper authorization of the operation; however this 485 approach will require further study. 487 4.4. Operations when CN is behind a firewall 489 In summary, when a firewall is located in the CN's ASP, MN configures 490 the firewall(s) using CREATE to let following messages traverse: 492 o CoTI messages (src: CoA, dst: CN) {RO} 494 o for data traffic from MN to CN and vice versa (src: CoA, dst: CN) 495 {for RO} 497 The HA configures the firewall(s) using CREATE to let following 498 messages traverse: 500 o HoTI messages (src: HoA, dst: CN) {for RO} 502 o for data traffic from HA to CN (src: HA, dst: CN) {for BT} 504 CN configure the firewall(s) using EXT to let following traverse: 506 o for data traffic from HA to CN (src: HA, dst: CN) {for BT} 508 o for data traffic from HA to CN (src: HA, dst: CN) {for BT} 510 5. Home Agent behind a firewall 512 5.1. Route Optimization 514 In Figure 7, the Mobile Node's MSP is protected by a firewall that 515 employs the stateful packet filtering. The MN and the CN are also 516 shown in the figure. The MN, after entering a new network, sends a 517 Binding Update to the HA. But as it is initiated by the MN, it first 518 has to install some filter rules in the firewall before sending the 519 Binding Update. 521 +----------------+ +----+ 522 | | | MN | 523 | | +----+ 524 | | Mobile Node 525 | +----+ +----+ 526 | | HA | | FW | 527 | +----+ +----+ 528 | | +----+ 529 | | | CN | 530 | | +----+ 531 +----------------+ External CN 532 Network protected 533 by a firewall 535 Figure 7: HA behind the firewall 537 The MN-HA Binding Update message is assumed to be IPsec encapsulated. 538 This might cause problems, as some primitive firewalls do not 539 recognize IPsec traffic and hence drop the packets because of the 540 absence of any transport header. One approach is to use UDP 541 encapsulation of IPsec traffic in order to overcome this problem. 542 Another is using NSIS NAT/FW NSLP to signal the firewall to allow 543 such traffic to traverse. 545 The MN initiates the NSIS signaling to create rules that will allow 546 the Binding Update messages to go through the firewall. The MN then 547 sends the Binding Update message to the HA. 549 For the BU (IPsec ESP in transport mode) traffic from MN to the 550 HA, the MN installs rules using CREATE for the flow-id will be: 551 SA: CoA, DA: HA, SPIx 553 By default, the rules previously installed in the firewall will not 554 allow the HoTI message to go through. Hence, the MN has to install a 555 different set of rules for these signaling messages by initiating 556 another NAT/FW NSLP signaling exchange. After that it sends the HoTI 557 message to the HA. The HA installs rules between the HA and the CN 558 and accordingly send the HoTI to the CN. The HoT message from the CN 559 to the HA is also allowed by the SPF as it belongs to the session 560 previously installed by the HA. The HoT message from the HA to the 561 MN is also allowed as it is initiated by the HA. The RRT completes 562 successfully. 564 For the HoTI message (IPsec ESP in tunnel mode) from MN to the HA, 565 the MN installs rules using CREATE the flow-id: SA: CoA, DA: HA, 566 SPIx. 568 For the HoTI message from HA to the CN, the HA installs rules 569 using CREATE for the flow-id: SA: HoA, DA: CN. 571 Detailed message flow between MN and HA is shown in Figure 8. 573 +------------------------+ 574 | | 575 | +----+ +-----+ +------------------+ 576 | | | | | CREATE | +----+ | 577 | | +--------<-----+ +---------<------|---<---+ | | 578 | | | RESPONSE | | | | | | 579 | | +-------->-----+ +--------->------|--->---+ | | 580 | | | | | Binding update | | | | 581 | | +--------<-----+ +---------<------|---<---+ | | 582 | | HA | | FW | Binding ACK | | MN | | 583 | | +-------->-----+ +--------->------|--->---+ | | 584 | | | | | | |(DS)| | 585 | | | | | CREATE | | | | 586 | | +--------<-----+ +---------<------|---<---+ | | 587 | | | RESPONSE | | | | | | 588 | | +-------->-----+ +--------->------|--->---+ | | 589 | | | | | HoTI | | | | 590 | | +--------<-----+ +---------<------|---<---+ | | 591 | | | | | HoT | | | | 592 | | +-------->-----+ +--------->------|--->---+ | | 593 | +----+ +-----+ | +----+ | 594 | | | | 595 +------------------------+ +------------------+ 596 HA protected by firewall Visited Network 597 (Home Network) 599 Figure 8: NSIS signaling for HA behind the firewall 601 For the data traffic, there is no additional signaling as the MN 602 sends data directly to CN and none of these networks (CN network and 603 MN network) are protected by firewalls. This is applicable for both 604 cases when either MN or CN is the data senders. 606 5.2. Bi-directional tunneling 608 Here, it is necessary that the HA open pinholes for the data traffic 609 from the CN using EXT. The CN is then allowed to send the data 610 traffic through the FW. After intercepting a packet, the HA tunnels 611 it to the MN. Figure 9 shows the message flow. 613 HA Network protected 614 +-------------------------+ 615 | | 616 | +-----+ +-----+ +----+ 617 | | | EXT | | | | 618 | | |-------->-----+ | | CN | 619 | | | RESPONSE | | |(DS)| 620 | | |--------<-----+ | | | 621 | | | | | | | 622 | | HA |********<*****+ FW +*********<**********+ | 623 | | | | | +----+ 624 | | | | | 625 | | | | | +----+ 626 | | +########>#####+ +#########>##########+ MN | 627 | | | | | |(DR)| 628 | +-----+ +-----+ +----+ 629 | | 630 +-------------------------+ 632 ----- = Signaling traffic 633 ***** = Data traffic 634 ##### = Tunneled data packet 636 Figure 9: NSIS signaling for HA behind the firewall 638 For the data traffic from CN to HA, the HA installs rules using 639 EXT for the flow-id: SA: CN, DA: HoA, SP: Data application port, 640 DP: Data application port. 642 5.3. Operations when HA is behind a firewall 644 In summary, if a firewall is located at the edge of the MN's MSP, the 645 MN configures the firewall(s) using CREATE to let following messages 646 traverse: 648 o BU messages (src: CoA, dst: HA, SPIx) (IPsec ESP in transport 649 mode) {for BU} 651 o HoTI messages (src: CoA, dst: HA, SPIx) (IPsec ESP in tunnel mode) 652 {for RO} 654 The HA configures the firewall(s) using CREATE to let following 655 messages traverse: 657 o HoTI messages (src: HoA, dst: CN) {for RO} 659 HA configure the firewall(s) using EXT to let following traverse: 661 o for data traffic from CN to HA (src: CN, dst: HA, SP: data 662 application port, DP: data application port) {BT} 664 6. Additional Discussions 666 To support the operations described in this draft, it would be 667 desirable if the NSIS NAT/FW NSLP has the ability to discover the 668 presence and the characteristics (e.g., uplink or downlink filter) of 669 firewalls. This will be useful in several cases. 671 For instance, it would be desirable if one could detect whether a 672 firewall exists, if no, then NAT/FW NSLP will be unnecessary. 673 Moreover, it is necessary to determine where (i.e., in which MIPv6 674 segment/scenario) is the firewall. This will be very useful to 675 provide multiple firewall rules within a single signaling message 676 exchange for multiple traffic modes (e.g., rules to allow BU and HoTI 677 traverse). Current NAT/FW NSLP [2] specification does not provide 678 this ability, however, we believe it would be useful to extend it to 679 be able to discover the presence and characteristics of firewalls. 680 This desired feature is already discussed in [8]: 682 "A client MUST be able to create pinholes and specify the 683 characteristics of the pinholes to be installed in the firewalls." 685 To enable the operations defined in this draft, some kind of 686 interface between Mobile IPv6 and the NAT/FW NSLP is required. This 687 interface notifies the NSLP about the MIP6 actions, for example the 688 roaming into a new network and provides the required information 689 (CoA, HoA, ...). This notification triggers the required operation. 690 The protocol uses a firewall detection approach to determine the 691 current scenario and performs the pinhole creation process necessary 692 for this case. After creation of the pinholes, MIP6 signaling is 693 enabled to traverse possible firewalls. 695 The operation overview will be explained in more detail in future 696 versions of this draft. 698 7. Security Considerations 700 The NAT/FW NSLP is in itself a very security sensitive service. A 701 detailed description of possible threats and countermeasures are 702 described in [2]. 704 More details to authorization and authentication will be provided in 705 the next version of this draft. 707 8. Acknowledgements 709 Parts of this document are a by-product of the ENABLE Project, 710 partially funded by the European Commission under its Sixth Framework 711 Programme. It is provided "as is" and without any express or implied 712 warranties, including, without limitation, the implied warranties of 713 fitness for a particular purpose. The views and conclusions 714 contained herein are those of the authors and should not be 715 interpreted as necessarily representing the official policies or 716 endorsements, either expressed or implied, of the ENABLE Project or 717 the European Commission. 719 The authors would like to thank Hannes Tschofenig, Srinath 720 Thiruvengadam, Martin Stiemerling, Cedric Aoun and Elwyn Davies for 721 the discussions about the NAT/Firewall NSLP. Additionally, we would 722 like to thank Marcus Brunner and Miquel Martin for their feedback. 724 9. References 726 9.1. Normative References 728 [1] Le, F., Faccin, S., Patil, B., and H. Tschofenig, "Mobile IPv6 729 and Firewalls: Problem Statement", RFC 4487, May 2006. 731 [2] Stiemerling, M., "NAT/Firewall NSIS Signaling Layer Protocol 732 (NSLP)", draft-ietf-nsis-nslp-natfw-15 (work in progress), 733 July 2007. 735 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 736 Levels", BCP 14, RFC 2119, March 1997. 738 [4] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in 739 IPv6", RFC 3775, June 2004. 741 9.2. Informative References 743 [5] Schulzrinne, H. and R. Hancock, "GIST: General Internet 744 Signalling Transport", draft-ietf-nsis-ntlp-14 (work in 745 progress), July 2007. 747 [6] Brunner, M., "Requirements for Signaling Protocols", RFC 3726, 748 April 2004. 750 [7] Lee, S., "Applicability Statement of NSIS Protocols in Mobile 751 Environments", 752 draft-ietf-nsis-applicability-mobility-signaling-07 (work in 753 progress), July 2007. 755 [8] Bajko, G., "Requirements for Firewall Configuration Protocol", 756 draft-bajko-nsis-fw-reqs-08 (work in progress), October 2007. 758 [9] Leung, K., "Authentication Protocol for Mobile IPv6", 759 draft-ietf-mip6-auth-protocol-07 (work in progress), 760 September 2005. 762 Authors' Addresses 764 Niklas Steinleitner (editor) 765 University of Goettingen 766 Institute for Informatics 767 Lotzestr. 16-18 768 Goettingen 37083 769 Germany 771 Email: steinleitner@cs.uni-goettingen.de 773 Xiaoming Fu 774 University of Goettingen 775 Institute for Informatics 776 Lotzestr. 16-18 777 Goettingen 37083 778 Germany 780 Email: fu@cs.uni-goettingen.de 782 Franck Le 783 Carnegie Mellon University 784 5000 Forbes Avenue 785 Pittsburgh, PA 15213 786 USA 788 Email: franckle@cmu.edu 790 Full Copyright Statement 792 Copyright (C) The IETF Trust (2007). 794 This document is subject to the rights, licenses and restrictions 795 contained in BCP 78, and except as set forth therein, the authors 796 retain all their rights. 798 This document and the information contained herein are provided on an 799 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 800 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 801 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 802 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 803 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 804 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 806 Intellectual Property 808 The IETF takes no position regarding the validity or scope of any 809 Intellectual Property Rights or other rights that might be claimed to 810 pertain to the implementation or use of the technology described in 811 this document or the extent to which any license under such rights 812 might or might not be available; nor does it represent that it has 813 made any independent effort to identify any such rights. Information 814 on the procedures with respect to rights in RFC documents can be 815 found in BCP 78 and BCP 79. 817 Copies of IPR disclosures made to the IETF Secretariat and any 818 assurances of licenses to be made available, or the result of an 819 attempt made to obtain a general license or permission for the use of 820 such proprietary rights by implementers or users of this 821 specification can be obtained from the IETF on-line IPR repository at 822 http://www.ietf.org/ipr. 824 The IETF invites any interested party to bring to its attention any 825 copyrights, patents or patent applications, or other proprietary 826 rights that may cover technology that may be required to implement 827 this standard. Please address the information to the IETF at 828 ietf-ipr@ietf.org. 830 Acknowledgment 832 Funding for the RFC Editor function is provided by the IETF 833 Administrative Support Activity (IASA).