idnits 2.17.1 draft-ietf-mobileip-vpn-problem-statement-req-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by 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 a Security Considerations section. ** 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 == Line 86 has weird spacing: '...eed for enabl...' == Line 88 has weird spacing: '...o their targe...' == Line 111 has weird spacing: '... (also refer...' == Line 134 has weird spacing: '... From the ...' == Line 136 has weird spacing: '...erefore any...' == (9 more instances...) == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (June 23, 2003) is 7612 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: '2' is defined on line 704, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 707, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 711, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 714, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 717, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 723, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3344 (ref. '1') (Obsoleted by RFC 5944) == Outdated reference: A later version (-06) exists of draft-ietf-ipsec-nat-reqts-04 == Outdated reference: A later version (-08) exists of draft-ietf-ipsec-nat-t-ike-06 Summary: 4 errors (**), 0 flaws (~~), 17 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Mobile IP Working Group F. Adrangi, Ed. 3 Internet-Draft intel 4 Expires: December 22, 2003 H. Levkowetz, Ed. 5 ipUnplugged 6 June 23, 2003 8 Problem Statement: Mobile IPv4 Traversal of VPN Gateways 9 draft-ietf-mobileip-vpn-problem-statement-req-03 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that other 18 groups may also distribute working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at http:// 26 www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on December 22, 2003. 33 Copyright Notice 35 Copyright (C) The Internet Society (2003). All Rights Reserved. 37 Abstract 39 Deploying Mobile-IP v4 in networks which are connected to the 40 internet through a VPN (Virtual Private Network) gateway presents 41 some problems which do not currently have well-described solutions. 42 This document aims to describe and illustrate these problems, and 43 propose some guidelines for possible solutions. 45 Table of Contents 47 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 48 1.1 Overview of the Problem . . . . . . . . . . . . . . . . . . 3 49 1.2 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 50 2. MIP and VPN Deployment Scenarios . . . . . . . . . . . . . . 5 51 2.1 MIPv4 HA(s) Inside the Intranet behind a VPN Gateway . . . . 5 52 2.2 VPN Gateway and MIPv4 HA(s) in parallel . . . . . . . . . . 6 53 2.3 Combined VPN Gateway and MIPv4 HA . . . . . . . . . . . . . 7 54 2.4 MIPv4 HA(s) Outside the VPN domain . . . . . . . . . . . . . 8 55 2.5 Combined VPN Gateway and MIPv4 HA(s) on the Local Link . . . 8 56 3. Deployment Scenarios Selection . . . . . . . . . . . . . . . 9 57 4. Problem statement . . . . . . . . . . . . . . . . . . . . . 10 58 4.1 Registering in co-located mode . . . . . . . . . . . . . . . 11 59 4.2 Registering via an FA . . . . . . . . . . . . . . . . . . . 11 60 4.3 Summary: MIP Incompatibilities with IPsec-based VPN 61 Gateways . . . . . . . . . . . . . . . . . . . . . . . . . . 13 62 5. Solution Guidelines . . . . . . . . . . . . . . . . . . . . 13 63 5.1 Preservation of Existing VPN Infrastructure . . . . . . . . 13 64 5.2 Software Upgrades to Existing VPN Client and Gateways . . . 14 65 5.3 IPsec Protocol . . . . . . . . . . . . . . . . . . . . . . . 14 66 5.4 Multi-Vendor Interoperability . . . . . . . . . . . . . . . 14 67 5.5 MIPv4 Protocol . . . . . . . . . . . . . . . . . . . . . . . 14 68 5.6 Handoff Overhead . . . . . . . . . . . . . . . . . . . . . . 15 69 5.7 Scalability, Availability, Reliability, and Performance . . 15 70 5.8 Functional Entities . . . . . . . . . . . . . . . . . . . . 15 71 5.9 Implications of Intervening NAT Gateways . . . . . . . . . . 15 72 5.10 Security Implications . . . . . . . . . . . . . . . . . . . 15 73 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 74 Normative References . . . . . . . . . . . . . . . . . . . . 16 75 Informative References . . . . . . . . . . . . . . . . . . . 16 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 17 77 Intellectual Property and Copyright Statements . . . . . . . 19 79 1. Introduction 81 Mobile IP [1] agents are being deployed in enterprise networks to 82 enable mobility across wired and wireless LANs while roaming inside 83 the enterprise intranet. With the growing deployment of IEEE 802.11 84 access points ("hot spots") in public places such as hotels, 85 airports, and convention centers, and wireless WAN data networks such 86 as GPRS, the need for enabling mobile users to maintain their 87 transport connections and constant reachability while connecting back 88 to their target "home" networks protected by Virtual Private 89 Network (VPN) technology is increasing. This implies that Mobile IP 90 and VPN technologies have to coexist and function together in order 91 to provide mobility and security to the enterprise mobile users. 93 The goal of this draft is to: 95 o Identify and describe practical deployment scenarios for Mobile IP 96 and VPN in enterprise and operator environments. 98 o Identify example usage scenarios for remote users roaming outside 99 the "home" network protected by a VPN gateway. 101 o Articulate the problems resulting from Mobile IP and VPN 102 coexistence. Specify a set of framework guidelines to evaluate 103 proposed solutions, supporting multi-vendor seamless IPv4 mobility 104 across IPsec-based VPN gateways. 106 1.1 Overview of the Problem 108 Real life networks typically consist of three different domains from 109 a corporate point of view. The first domain is the Internet (i.e., 110 the untrusted external network). The second domain is the trusted 111 intranet (also referred to as VPN Domain in this document). 112 The third domain is the DMZ, which is between the Internet and the 113 intranet. 115 Access to the intranet is typically guarded by both a firewall and a 116 VPN device. The intranet can only be accessed by respecting the 117 security policies in the firewall and the VPN device. 119 When MIP is deployed in a corporate network behind a VPN device, 120 roaming between these two different domains (i.e., the untrusted 121 Internet and the trusted intranet) becomes problematic. It would be 122 desirable to have seamless session mobility between the two domains, 123 because MIP was designed for session mobility regardless of the 124 network point of attachment. Unfortunately, the current MIP 125 standards fall short of this promise for an important customer 126 segment, corporate users behind VPN gateways. 128 Because current standards do not provide for session mobility across 129 these two domains the possibility of finding a solution to this 130 problem has been investigated. The goal is to provide seamless 131 session mobility when the mobile node moves between these two domains 132 or between subnets in either domain. 134 From the beginning it was also assumed that VPNs and 135 firewalls were to be taken as more or less granted because they have 136 much wider deployments than MIP at the present. Therefore any 137 solutions would need to minimize impact on existing VPN and 138 firewall deployments, related standards and "de facto" standards. 140 1.2 Terminology 142 MIPv4 Mobile IP for IPv4 [1] 144 MIPv6 Mobile IP for IPv6 146 VPN Virtual Private Network 148 GW Gateway 150 VPN Domain 151 An intranet protected by a VPN gateway. 153 DMZ 154 (DeMilitarized Zone) A small network inserted as a "neutral 155 zone" between a company's private network and the outside 156 public network to prevent outside users from getting direct 157 access to the company's private network 159 Home Network 160 A network, possibly virtual, having a network prefix matching 161 that of a mobile node's home address. 163 Home Agent 164 A router on a mobile node's home network which tunnels 165 datagrams for delivery to the mobile node when it is away 166 from home, and maintains current location information for the 167 mobile node. 169 MIPv4 inside IPsec-ESP tunnel 170 MIPv4 packet is encapsulated in an IPsec-ESP tunnel 171 established between the Mobile Node and the VPN gateway. 173 IPsec-ESP inside MIPv4 tunnel 174 IPsec-ESP packet is encapsulated in an MIPv4 tunnel 175 established between the Mobile Node and the home agent. 177 2. MIP and VPN Deployment Scenarios 179 This section describes a set of deployment scenarios where MIP agents 180 and VPN gateways have to coexist to provide mobility and security. 181 The intention is to identify practical deployment scenarios for MIP 182 and VPNs where MIP technology might be extended to solve problems 183 resulting from the desire for co-existence. 185 In all scenarios, "MN" refers to a mobile node that runs both MIP and 186 IPsec-based VPN client software. The foreign network might or 187 might not employ a foreign agent. And, the term "Intranet" 188 refers to a private network protected by a VPN gateway and perhaps a 189 layer-3 transparent or non-transparent firewall. Please note that 190 firewalls are purposely omitted from the following scenarios, 191 because they may be installed in a number of different ways, and the 192 fact that this draft's focus is the relationship between MIP and VPN. 194 Finally, the scenarios assume that encryption is not enforced inside 195 the VPN domain because 1) the VPN domain (Intranet) is viewed as a 196 trusted network, and users allowed inside the Intranet are also 197 trusted 2) it is a common VPN deployment practice where the VPN is 198 used to guard the Intranet resources from unauthorized users attached 199 to an untrusted network, and to provide a secure communication 200 channel for authorized users to access resources inside the Intranet 201 from outside. 203 The following sub-sections introduce five representative 204 combinations of MIPv4 HA and VPN gateway placement. 206 2.1 MIPv4 HA(s) Inside the Intranet behind a VPN Gateway 208 MIPv4 HAs are deployed inside the Intranet protected by a VPN 209 gateway, and are not directly reachable by the MNs outside the 210 Intranet. 212 ..Foreign Network.. .....VPN Domain..(Intranet)..... 213 . . . . 214 . +----+ +----+ . +----+ +-------+ +-------+ . 215 . |MNs | | FA | . | VPN| | Router| | HA | . 216 . |away| | | .<=========>| | | 1..n | | 1..n | . 217 . +----+ +----+ . | GW | +-------+ +-------+ . 218 . . +----+ . 219 ................... . +-------+ +-------+ . 221 . | CN | | MNs | . 222 . | 1..n | | home | . 223 . +-------+ +-------+ . 224 . . 225 ................................ 227 Figure 1 229 Direct application of MIPv4 standards [1] is successfully used to 230 provide mobility for users inside the Intranet. However, mobile 231 users outside the Intranet can only access the intranet resources 232 (e.g., MIP agents) through the VPN gateway, which will allow only 233 authenticated IPsec traffic inside. This implies that the MIPv4 234 traffic has to run inside IPsec, which leads to two distinct 235 problems: 237 1. When the foreign network has an FA deployed (as in e.g. CDMA 238 2000), MIPv4 registration becomes impossible because the traffic 239 between MN and VPN gateway, which is what the FA sees, is 240 encrypted and the FA is not set up to decrypt it. 242 2. In co-located mode, successful registration is possible but the 243 VPN tunnel has to be re-negotiated every time the MN changes its 244 point of network attachment. 246 These problems are articulated in Section 4. 248 This deployment scenario may not be common yet, but it is practical 249 and becoming important as there is an increasing need for providing 250 corporate remote users with continuous access to the Intranet 251 resources. 253 2.2 VPN Gateway and MIPv4 HA(s) in parallel 255 A MIPv4 HA is deployed in parallel with the VPN gateway, and it is 256 directly reachable by MNs inside or outside the Intranet. 258 ..Foreign Network.. .....VPN Domain..(Intranet)..... 259 . . . . 260 . +----+ +----+ . +----+ +-------+ . 261 . |MNs | | FA | . | VPN| | Router| . 262 . |away| | | .<=========>| | | 1..n | . 263 . +----+ +----+ . | GW | +-------+ . 264 . . +----+ . 265 . . +----+ +-------+ +-------+ . 266 . .<=========>| HA | | CN | | MNs | . 267 ................... | | | 1..n | | home | . 268 +----+ +-------+ +-------+ . 270 . . 271 ................................ 273 Figure 2 275 The MIPv4 HA has a public interface connected to the Internet, and a 276 private interface attached to the Intranet. Mobile users will most 277 likely have a virtual home network associated with the MIPv4 HA's 278 private interface, so that the mobile users are always away from home 279 and hence registered with the MIPv4 HA. Furthermore, in deployments 280 where the VPN gateway and the HA are placed in a corporate DMZ, this 281 implies that MIPv4 traffic will always be routed through the 282 DMZ (regardless of whether MNs are located outside or inside the 283 Intranet), which may not be acceptable by IT departments in large 284 corporations. 286 This deployment can be used with two different configurations: "MIPv4 287 inside IPsec-ESP tunnel" and "IPsec-ESP inside MIPv4 tunnel". The 288 "MIPv4 inside IPsec-ESP tunnel" has the same problems as the scenario 289 of Section 2.1 (namely, MIPv4 registration becomes impossible when 290 the registration is to be done via an FA and furthermore in 291 co-located mode, the VPN tunnel has to be re-negotiated every time 292 the MN changes its point of attachement). The "IPsec-ESP inside 293 MIPv4 tunnel" does not have problems described in Section 2.1, 294 however it will require some modifications to the routing logic of 295 the MIPv4 HA or the VPN gateway. 297 2.3 Combined VPN Gateway and MIPv4 HA 299 This is similar to deployment scenario described in Section 2.2, with 300 the exception that the VPN gateway and MIPv4 HA are running on the 301 same physical machine. 303 ..Foreign Network.. .....VPN Domain..(Intranet)..... 304 . . . . 305 . +----+ +----+ . +----+ +-------+ . 306 . |MNs | | FA | . | VPN| | Router| . 307 . |away| | | .<==========| GW | | 1..n | . 308 . +----+ +----+ . | + | +-------+ . 309 . . | HA | . 310 ................... +----+ +-------+ +-------+ . 311 . | CN | | MNs | . 312 . | 1..n | | home | . 313 . +-------+ +-------+ . 314 . . 315 ................................ 317 Figure 3 319 Running MIPv4 HA and VPN on the same machine resolves routing 320 related issues that exist in Section 2.2 when a "IPsec-ESP inside 321 MIPv4 tunnel" configuration is used. However, it does not promote 322 multi-vendor interoperability in environments where MIPv4 HA and VPN 323 technologies must be acquired from different vendors. 325 2.4 MIPv4 HA(s) Outside the VPN domain 327 In this scenario, MIPv4 HAs are deployed outside the Intranet (e.g., 328 in an operator network), as depicted in Figure 4 below. 330 ..Foreign Network.. .....VPN Domain..(Intranet)..... 331 . . . . 332 . +----+ +----+ . +----+ +-------+ . 333 . |MNs | | FA | . | VPN| | Router| . 334 . |away| | | .<==========| GW | | 1..n | . 335 . +----+ +----+ . | | +-------+ . 336 . . | | . 337 ................... | | +-------+ +-------+ . 338 | | | CN | | MNs | . 339 .....MIPv4 Home.... | | | 1..n | | home | . 340 . .<=========>| | +-------+ +-------+ . 341 . +------+ . +----+ . 342 . | HAs | . . . 343 . | 1..n | . ................................ 344 . +------+ . 345 ................... 347 Figure 4 349 In this deployment scenario the goal is to provide remote users with 350 continuous access to the Intranet resources while they are roaming 351 outside the Intranet only (i.e., mobility is not supported inside the 352 Intranet). In this case it is most practical to run IPsec-ESP inside 353 a MIPv4 tunnel (i.e., MIPv4 tunnel end-points are the MN and the HA; 354 the IPsec-ESP packet from the MN and to the VPN gateway is 355 encapsulated in the MIPv4 tunnel) as the MNs can register with the HA 356 without establishing an IPsec tunnel to the VPN gateway. This should 357 work without any technical problems. The IPsec tunnel end-points 358 will be the MN and the VPN gateway. The 'home network' will be a 359 virtual home network, located at the HA, from which it is possible to 360 reach the Corporate intranet through the VPN gateway. 362 2.5 Combined VPN Gateway and MIPv4 HA(s) on the Local Link 364 This is similar to the deployment scenario described in Section 2.3, 365 with the difference that the VPN gateway/HA is sitting on the local 366 link. In this the VPN gateway and HA would most naturaly be 367 co-located in the same box, although this is in no way a requirement. 369 ..Foreign Network.. .....VPN Domain..(Intranet)..... 370 . . . . 371 . +----+ +----+ . +------+ +-------+ +-------+ . 372 . |MNs | | FA | . | Fire | | Router| | VPN/HA| . 373 . |away| | | .<=======>| wall | | 1..n | | 1..n | . 374 . +----+ +----+ . | | +-------+ +-------+ . 375 . . | NAT | . 376 ................... +------+ +-------+ +-------+ . 377 . | CN | | MNs | . 378 . | 1..n | | home | . 379 . +-------+ +-------+ . 380 . . 381 ................................ 383 Figure 5 385 This deployment works today without any technical problems with 386 IPsec-ESP running inside a MIPv4 tunnel. If however MIPv4 is run 387 inside the IPsec-ESP tunnel it has the same problems as in Section 388 2.1 (namely, MIPv4 registration becomes impossible when the 389 registration is to be done via an FA and furthermore in co-located 390 mode, the VPN tunnel has to be re-negotiated every time the MN 391 changes its point of attachement). This deployment is not common or 392 practical for large deployments (on the order of thousands of users) 393 because of the large and distributed security perimeter. 395 3. Deployment Scenarios Selection 397 The deployment scenarios described in Section 2 were evaluated to 398 identify the ones most in need of solving. The evaluation was done 399 based on two main criteria: 1) Is the deployment scenario common and 400 practical? and 2) Does the deployment scenario reveal any problems 401 resulting from MIPv4 and VPN coexistence? 403 There was a consensus about importance and practicality of the 404 scenario in Section 2.1 because of rising needs to provide corporate 405 remote users with continuous access to their Intranet resources. 406 After analyzing each scenario one realizes that problems occurring in 407 scenarios in Section 2.2 and Section 2.4 are either the same as or a 408 subset of those in the scenario in Section 2.1. Therefore, solving 409 the scenario in Section 2.1 will also solve the scenarios in Section 410 2.2 and Section 2.4. The scenarios in Section 2.3 and Section 2.5 do 411 not introduce functional problems resulting from MIPv4 and VPN 412 co-existence, hence there is no need to seek a solution. A solution 413 for the deployment scenario in Section 2.1 is therefore seen as 414 essential, and this in turn can also be applied to solve problems in 415 other scenarios. For the remainder of this draft, we will articulate 416 the roaming scenarios, the problems, and the solution guidelines 417 relevant to the scenario in Section 2.1. 419 4. Problem statement 421 This section describes roaming scenarios corresponding to the 422 deployment scenario in Section 2.1 where an MN needs to have 423 continuous access to the Intranet resources regardless of whether it 424 is roaming inside or outside the Intranet, and their associated 425 problems. The scenarios are constructed based on a multi-subnetted, 426 MIPv4-enabled Intranet (hereafter, referred to as Intranet or VPN 427 domain) protected by an IPsec-based VPN gateway as depicted in Figure 428 6. 430 ....Internet....... .....VPN Domain..(Intranet)..... 431 . . . . 432 . +----+ . +----+ +-------+ +-------+ . 433 . |MNs | . | VPN| | Router| | VPN/HA| . 434 . |away| .<=========>| | | 1..n | | 1..n | . 435 . +----+ . | GW | +-------+ +-------+ . 436 . . +----+ . 437 ................... . +-------+ +-------+ . 438 . | CN | | MNs | . 439 . | 1..n | | home | . 440 . +-------+ +-------+ . 441 . . 442 ................................ 444 Figure 6: Intranet protected by a VPN Gateway 446 The Intranet, depicted in Figure 6, may include both wired (IEEE 447 802.3) and IEEE 802.11 wireless LAN deployments. However, it is also 448 possible to see IEEE 802.11 deployments outside the Intranet due to 449 the perceived lack of current 802.11 security, as depicted in Figure 450 7. 452 ....Internet....... .....VPN Domain..(Intranet)..... 453 . . . . 454 . +----+ . +----+ +-------+ +-------+ . 455 . |MNs | . | VPN| | Router| | VPN/HA| . 456 . |away| .<=========>| | | 1..n | | 1..n | . 457 . +----+ . | GW | +-------+ +-------+ . 458 . . | | . 459 ................... | | +-------+ +-------+ . 460 | | | CN | | MNs | . 461 ..802.11 Wireless.. <====>| | | 1..n | | home | . 462 . Network . +----+ +-------+ +-------+ . 464 . . . . 465 ................... ................................ 467 Figure 7: IEEE 802.11 Wireless deployment outside the home network 469 4.1 Registering in co-located mode 471 In co-located mode, the IPsec tunnel endpoints would be at the MN and 472 the VPN gateway, which (supposing we have the scenario described in 473 Section 2.1) results in the mobile-ip tunnel from MN to HA being 474 encapsulated inside the IPsec tunnel. See Figure 8 below. This 475 scenario is still possible, but has some major drawbacks. 477 ....Internet....... .....VPN Domain..(Intranet)..... 478 . . . . 479 . +----+ . +----+ +-------+ +-------+ . 480 . |MNs | . | VPN| | Router| | VPN/HA| . 481 . |away|<###################>| |-----| 1..n |->| 1..n | . 482 . +----+ . \ | GW | +-------+ +-------+ . 483 . . \ +----+ . 484 ................... mip . +-------+ +-------+ . 485 inside . | CN | | MNs | . 486 IPsec . | 1..n | | home | . 487 . +-------+ +-------+ . 488 . . 489 ................................ 491 Figure 8 493 The MN obtains an address at its point of attachment (via DHCP[7] or 494 some other means), and then first sets up an IPsec tunnel to the VPN 495 gateway, after which it can successfully register with its HA through 496 the IPsec tunnel. The problem is that in an end-to-end security 497 model, an IPsec tunnel that terminates at the VPN gateway must 498 protect the IP traffic originating at the MN. As the MN's IPsec 499 tunnel address is the address obtained at the point of attachment, it 500 will change during movement, and the VPN tunnel security association 501 must be refreshed after each IP subnet handoff. This could have 502 noticeable performance implications on real-time applications. In 503 effect, we don't have mobility support for the tunnel endpoint 504 changes associated with MN movements. 506 4.2 Registering via an FA 508 In the case where a mobile node is in a network where mobility 509 support is provided through the use of an FA, and no dhcpd allocated 510 address and co-located mode is possible, we run into severe trouble. 512 Figure 9 below illustrates this: 514 ..Foreign Network.. .....VPN Domain..(Intranet)..... 515 . . . . 516 . +----+ +----+ . +----+ +-------+ +-------+ . 517 . |MNs | | FA | . | VPN| | Router| | VPN/HA| . 518 . |away|| |-----| 1..n |->| 1..n | . 519 . +----+ \ +----+ . \ | GW | +-------+ +-------+ . 520 . \ . \ +----+ . 521 ...........\....... mip . +-------+ +-------+ . 522 \ inside . | CN | | MNs | . 523 MN expects IPsec . | 1..n | | home | . 524 IPsec traffic . +-------+ +-------+ . 525 . . 526 ................................ 528 Figure 9 530 The mobile node, when arriving at this network, may have a IPsec 531 session going with its VPN gateway. This session will not be passed 532 through the FA as long as the MN has not registered and a mip tunnel 533 has been set up. But the MN, which is secure inside the IPsec based 534 VPN, will not even hear the FA advertisements. And any IPsec traffic 535 from the intranet (via the VPN gateway and IPsec tunnel) will not be 536 understood by the FA. Simply put, you could say that the FA needs to 537 see the mip tunnel outermost, while the VPN-GW needs to see the IPsec 538 tunnel outermost. Or in more details: 540 Firstly, the MN must have a IPsec tunnel established with the VPN-GW 541 in order to reach the HA, which places the IPsec tunnel outside the 542 mip traffic between MN and HA. The FA (which is likely in a 543 different administrative domain) cannot decrypt MIPv4 packets between 544 the MN and the VPN gateway, and will consequently be not able to 545 relay the MIPv4 packets. This is because the MIPv4 headers (which 546 the FA should be able to interpret) will be encrypted and protected 547 by IPSec. 549 Secondly, when the MN is communicating with the VPN-GW, an explicit 550 bypass policy for MIP packets is required, so that the MN can hear FA 551 advertisments and send and receive MIP registration packets. 552 Although not a problem in principle, there may be practical problems 553 when VPN and MIP clients from different vendors are used. 555 The use of a 'trusted FA' has been suggested in this scenario; 556 meaning an FA which is actually a combined VPN GW and FA. The 557 scenario will work fine in this case; effectively we are then 558 operating within the VPN established between the two VPN gateways, 559 and the case is analogous to deploying mobile-ip within a corporate 560 intranet which is not physically disjoint. See Figure 10 below. 561 However, we cannot expect that e.g. wireless hot-spots or CDMA 2000 562 FAs will have VPN gateways with security associations with any given 563 corporate network, so this is not particularly realistic in the 564 general mobility case. 566 ..Foreign Network.. .....VPN Domain..(Intranet)..... 567 . . . . 568 . +----+ +----+ . +----+ +-------+ +-------+ . 569 . | FA | | VPN| . | VPN| | Router| | VPN/HA| . 570 . | |<--| GW |<###########>| |-----| 1..n |->| 1..n | . 571 . +----+ +----+ . \ | GW | +-------+ +-------+ . 572 . | . \ +----+ . 573 . +----+ . mip . +-------+ +-------+ . 574 . |MNs | . inside . | CN | | MNs | . 575 . |away| . IPsec . | 1..n | | home | . 576 . +----+ . . +-------+ +-------+ . 577 ................... . . 578 ................................ 580 Figure 10 582 Furthermore, this solution would leave the traffic between FA and MN 583 unprotected, and as this link in particular may be a wireless link, 584 this is clearly undesireable. 586 4.3 Summary: MIP Incompatibilities with IPsec-based VPN Gateways 588 An MN roaming outside the Intranet has to establish an IPsec tunnel 589 to its home VPN gateway first, in order to be able to register with 590 its home agent. This is because the MN cannot reach its HA (inside 591 the private protected network) directly from the outside. This 592 implies that the MIPv4 traffic from the MN to a node inside the 593 Intranet is forced to run inside an IPsec tunnel, and hence will not 594 be in the clear. This in turn leads to two distinct problems 595 depending on whether the MN uses co-located or non co-located modes 596 to register with its HA. 598 5. Solution Guidelines 600 This section describes guidelines for a solution to MIPv4 traversal 601 across VPN gateways. The subsections discuss the guidelines in a 602 decreasing order of importance. 604 5.1 Preservation of Existing VPN Infrastructure 606 o The solution MUST preserve the investment in existing VPN 607 gateways. 609 o The solution MUST provide security which is not inferior to what 610 is already provided to existing "nomadic computing" remote access 611 users, i.e. for confidentiality, authentication, message 612 integrity, protection against replay attacks and related security 613 services. 615 5.2 Software Upgrades to Existing VPN Client and Gateways 617 o The solution SHOULD minimize changes to existing VPN client/ 618 gateway software. 620 5.3 IPsec Protocol 622 o The solution SHOULD NOT require any changes to existing IPsec or 623 key exchange standard protocols implemented by VPN gateways. 625 o The solution SHOULD NOT require that the VPN gateway or the VPN 626 client implement any new protocols in addition to the existing 627 standard protocols. 629 5.4 Multi-Vendor Interoperability 631 o The solution MUST provide multi-vendor interoperability, where 632 MIPv4 mobility agents, mobility clients (MN), VPN server, and VPN 633 client solutions may come from four different vendors. This is 634 typical for medium and large enterprises which purchase and deploy 635 best-of-breed multi-vendor solutions for IP routing, VPNs, 636 firewalls etc. 638 5.5 MIPv4 Protocol 640 o The solution MUST adhere to MIPv4 protocol [1]. That is, the 641 solution MUST NOT impose any changes that violates MIPv4 protocol. 643 o The solution MAY introduce new extensions to MIPv4 nodes per 644 guidelines specified in the MIPv4 protocol [1]. However, it is 645 highly desirable to avoid any changes to MIPv4 mobility agents 646 such as the FA and HA in order to overcome barriers to 647 deployment. 649 o The solution MAY require more than one instance of MIPv4 running 650 in parallel (multiple encapsulation). 652 5.6 Handoff Overhead 654 o It is imperative to keep the key management overhead down to a 655 minimum, in order to support fast handoffs across IP subnets. 656 Hence, the solution MUST propose a mechanism to avoid or minimize 657 IPsec tunnel SA renegotiation and IKE renegotiation as the MN 658 changes its current point of network attachment. 660 5.7 Scalability, Availability, Reliability, and Performance 662 o The solution complexity MUST increase at most linearly with the 663 number of MNs registered and accessing resources inside the 664 Intranet. 666 o The solution MAY introduce additional header or tunnelling 667 overhead if needed. 669 5.8 Functional Entities 671 o The solution MAY introduce new MIPv4 compliant functional 672 entities. 674 5.9 Implications of Intervening NAT Gateways 676 o The solution MUST be able to leverage the existing MIPv4 and IPsec 677 NAT traversal solutions [9][10][11]. 679 5.10 Security Implications 681 o The solution MUST NOT introduce any new vulnerabilities to the 682 MIPv4 or IPsec as specified in related RFCs. 684 6. Acknowledgements 686 The authors who contributed text to this document were in no 687 particular order: Farid Adrangi, Milind Kulkarni, Gopal Dommety, Eli 688 Gelasco, Qiang Zhang, Sami Vaarala, Dorothy Gellert, Nitsan Baider 689 and Henrik Levkowetz. 691 The authors would like to thank other contributors, especially 692 Prakash Iyer, Mike Andrews, Ranjit Narjala, Joe Lau, Kent Leung, 693 Alpesh Patel, Phil Roberts, Hans Sjostrand, Serge Tessier, Antti 694 Nuopponen, Alan O'neill, Gaetan Feige, Brijesh Kumar for their 695 continuous feedback and helping us improve this draft. 697 Normative References 699 [1] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August 700 2002. 702 Informative References 704 [2] Hanks, S., Li, T., Farinacci, D. and P. Traina, "Generic 705 Routing Encapsulation (GRE)", RFC 1701, October 1994. 707 [3] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G. and E. 708 Lear, "Address Allocation for Private Internets", BCP 5, RFC 709 1918, February 1996. 711 [4] Perkins, C., "Minimal Encapsulation within IP", RFC 2004, 712 October 1996. 714 [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement 715 Levels", BCP 14, RFC 2119, March 1997. 717 [6] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, 718 March 1997. 720 [7] Srisuresh, P. and M. Holdrege, "IP Network Address Translator 721 (NAT) Terminology and Considerations", RFC 2663, August 1999. 723 [8] Montenegro, G., "Reverse Tunneling for Mobile IP, revised", RFC 724 3024, January 2001. 726 [9] Vaarala, S. and O. Levkowetz, "Mobile IP NAT/NAPT Traversal 727 using UDP Tunnelling", draft-ietf-mobileip-nat-traversal-07 728 (work in progress), November 2002. 730 [10] Aboba, B. and W. Dixon, "IPsec-NAT Compatibility Requirements", 731 draft-ietf-ipsec-nat-reqts-04 (work in progress), March 2003. 733 [11] Kivinen, T., "Negotiation of NAT-Traversal in the IKE", 734 draft-ietf-ipsec-nat-t-ike-06 (work in progress), May 2003. 736 Authors' Addresses 738 Farid Adrangi 739 Intel Corporation 740 2111 N.E. 25th Avenue 741 Hillsboro OR 742 USA 744 Phone: +1 503-712-1791 745 EMail: farid.adrangi@intel.com 747 Henrik Levkowetz 748 ipUnplugged AB 749 Arenavagen 33 750 Stockholm S-121 28 751 SWEDEN 753 Phone: +46 8 725 9513 754 EMail: henrik@levkowetz.com 756 Milind Kulkarni 757 Cisco Systems 758 170 W. Tasman Drive 759 San Jose CA 95134 760 USA 762 Phone: +1 408-527-8382 763 EMail: mkulkarn@cisco.com 765 Gopal Dommety 766 Cisco Systems 767 170 W. Tasman Drive 768 San Jose CA 95134 769 USA 771 EMail: gdommety@cisco.com 773 Eli Gelasco 774 Cisco Systems 775 170 W. Tasman Drive 776 San Jose CA 95134 777 USA 779 EMail: egelasco@cisco.com 780 Qiang Zhang 781 Liqwid Networks, Inc. 782 1000 Wilson Blvd, Suite 900 783 Arlington VA 22209 784 USA 786 Phone: +1 703-224-1120 -x 203 787 EMail: qzhang@liqwidnet.com 789 Sami Vaarala 790 Netseal 791 Niittykatu 6 792 Espoo 02201 793 FINLAND 795 Phone: +358 9 435 310 796 EMail: sami.vaarala@iki.fi 798 Dorothy Gellert 799 Nokia Corporation 801 EMail: dorothy.gellert@nokia.com 803 Nitsan Baider 804 Check Point Software Technologies, Inc. 806 EMail: nitsan@checkpoint.com 808 Intellectual Property Statement 810 The IETF takes no position regarding the validity or scope of any 811 intellectual property or other rights that might be claimed to 812 pertain to the implementation or use of the technology described in 813 this document or the extent to which any license under such rights 814 might or might not be available; neither does it represent that it 815 has made any effort to identify any such rights. Information on the 816 IETF's procedures with respect to rights in standards-track and 817 standards-related documentation can be found in BCP-11. Copies of 818 claims of rights made available for publication and any assurances of 819 licenses to be made available, or the result of an attempt made to 820 obtain a general license or permission for the use of such 821 proprietary rights by implementors or users of this specification can 822 be obtained from the IETF Secretariat. 824 The IETF invites any interested party to bring to its attention any 825 copyrights, patents or patent applications, or other proprietary 826 rights which may cover technology that may be required to practice 827 this standard. Please address the information to the IETF Executive 828 Director. 830 Full Copyright Statement 832 Copyright (C) The Internet Society (2003). All Rights Reserved. 834 This document and translations of it may be copied and furnished to 835 others, and derivative works that comment on or otherwise explain it 836 or assist in its implementation may be prepared, copied, published 837 and distributed, in whole or in part, without restriction of any 838 kind, provided that the above copyright notice and this paragraph are 839 included on all such copies and derivative works. However, this 840 document itself may not be modified in any way, such as by removing 841 the copyright notice or references to the Internet Society or other 842 Internet organizations, except as needed for the purpose of 843 developing Internet standards in which case the procedures for 844 copyrights defined in the Internet Standards process must be 845 followed, or as required to translate it into languages other than 846 English. 848 The limited permissions granted above are perpetual and will not be 849 revoked by the Internet Society or its successors or assignees. 851 This document and the information contained herein is provided on an 852 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 853 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 854 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 855 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 856 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 858 Acknowledgment 860 Funding for the RFC Editor function is currently provided by the 861 Internet Society.