idnits 2.17.1 draft-ietf-mip4-vpn-problem-statement-02.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 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 88 has weird spacing: '...eed for enabl...' == Line 90 has weird spacing: '...o their targe...' == Line 110 has weird spacing: '... (also refer...' == Line 133 has weird spacing: '... From the ...' == Line 135 has weird spacing: '...erefore any...' == (9 more instances...) -- 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 (February 14, 2004) is 7377 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) ** Obsolete normative reference: RFC 3344 (Obsoleted by RFC 5944) == Outdated reference: A later version (-08) exists of draft-ietf-ipsec-nat-t-ike-07 Summary: 3 errors (**), 0 flaws (~~), 9 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: August 14, 2004 H. Levkowetz, Ed. 5 ipUnplugged 6 February 14, 2004 8 Problem Statement: Mobile IPv4 Traversal of VPN Gateways 9 11 Status of this Memo 13 This document is an Internet-Draft and is subject to all provisions 14 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 26 http://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 August 14, 2004. 33 Copyright Notice 35 Copyright (C) The Internet Society (2004). All Rights Reserved. 37 Abstract 38 Deploying Mobile-IP v4 in networks which are connected to the 39 Internet through a VPN (Virtual Private Network) gateway presents 40 some problems which do not currently have well-described solutions. 41 This document aims to describe and illustrate these problems, and 42 propose some guidelines for possible solutions. 44 Table of Contents 46 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 47 1.1 Overview of the Problem . . . . . . . . . . . . . . . 3 48 1.2 Specification of Requirements . . . . . . . . . . . . 4 49 1.3 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) on the VPN domain border . 7 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 9 56 3. Deployment Scenarios Selection . . . . . . . . . . . . . . . 10 57 4. Problem statement . . . . . . . . . . . . . . . . . . . . . 11 58 4.1 Registering in co-located mode . . . . . . . . . . . . 12 59 4.2 Registering via an FA . . . . . . . . . . . . . . . . 13 60 4.3 Summary: MIP Incompatibilities with IPsec-VPN 61 Gateways . . . . . . . . . . . . . . . . . . . . . . . . . . 14 62 5. Solution Guidelines . . . . . . . . . . . . . . . . . . . . 15 63 5.1 Preservation of Existing VPN Infrastructure . . . . . 15 64 5.2 Software Upgrades to Existing VPN Client and Gateways 15 65 5.3 IPsec Protocol . . . . . . . . . . . . . . . . . . . . 15 66 5.4 Multi-Vendor Interoperability . . . . . . . . . . . . 15 67 5.5 MIPv4 Protocol . . . . . . . . . . . . . . . . . . . . 15 68 5.6 Handoff Overhead . . . . . . . . . . . . . . . . . . . 16 69 5.7 Scalability, Availability, Reliability, and Performance 16 70 5.8 Functional Entities . . . . . . . . . . . . . . . . . 16 71 5.9 Implications of Intervening NAT Gateways . . . . . . . 16 72 5.10 Security Requirements . . . . . . . . . . . . . . . . 16 73 6. Security Considerations . . . . . . . . . . . . . . . . . . 16 74 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 75 Normative References . . . . . . . . . . . . . . . . . . . . 17 76 Informative References . . . . . . . . . . . . . . . . . . . 17 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 17 78 Intellectual Property and Copyright Statements . . . . . . . 20 80 Adrangi, Ed., et al. Expires August 14, 2004 2] 81 1. Introduction 83 Mobile IP [RFC3344] agents are being deployed in enterprise networks 84 to enable mobility across wired and wireless LANs while roaming 85 inside the enterprise Intranet. With the growing deployment of IEEE 86 802.11 access points ("hot spots") in public places such as hotels, 87 airports, and convention centers, and wireless WAN data networks such 88 as GPRS, the need for enabling mobile users to maintain their 89 transport connections and constant reachability while connecting back 90 to their target "home" networks protected by Virtual Private 91 Network (VPN) technology is increasing. This implies that Mobile IP 92 and VPN technologies have to coexist and function together in order 93 to provide mobility and security to the enterprise mobile users. 95 The goal of this draft is to: 96 o Identify and describe practical deployment scenarios for Mobile IP 97 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. 100 o Articulate the problems resulting from Mobile IP and VPN 101 coexistence. Specify a set of framework guidelines to evaluate 102 proposed solutions, supporting multi-vendor seamless IPv4 mobility 103 across IPsec-based VPN gateways. 105 1.1 Overview of the Problem 107 Real life networks typically consist of three different domains from 108 a corporate point of view. The first domain is the Internet (i.e., 109 the untrusted external network). The second domain is the trusted 110 Intranet (also referred to as VPN Domain in this document). 111 The third domain is the DMZ, which is between the Internet and the 112 Intranet. 114 Access to the Intranet is typically guarded by both a firewall and a 115 VPN device. The Intranet can only be accessed by respecting the 116 security policies in the firewall and the VPN device. 118 When MIP is deployed in a corporate network behind a VPN device, 119 roaming between these two different domains (i.e., the untrusted 120 Internet and the trusted Intranet) becomes problematic. It would be 121 desirable to have seamless session mobility between the two domains, 122 because MIP was designed for session mobility regardless of the 123 network point of attachment. Unfortunately, the current MIP 124 standards fall short of this promise for an important customer 125 segment, corporate users behind VPN gateways. 127 Because current standards do not provide for session mobility across 128 these two domains the possibility of finding a solution to this 129 problem has been investigated. The goal is to provide seamless 130 session mobility when the mobile node moves between these two domains 131 or between subnets in either domain. 133 From the beginning it was also assumed that VPNs and 134 firewalls were to be taken as more or less granted because they have 135 much wider deployments than MIP at the present. Therefore any 136 solutions would need to minimize impact on existing VPN and 137 firewall deployments, related standards and "de facto" standards. 139 1.2 Specification of Requirements 141 In this document, several words are used to signify the requirements 142 of the specification. These words are often capitalized. The key 143 words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", 144 "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document 145 are to be interpreted as described in [RFC2119]. 147 1.3 Terminology 149 MIPv4 Mobile IP for IPv4 [RFC3344] 150 MIPv6 Mobile IP for IPv6 151 VPN Virtual Private Network 152 GW Gateway 153 VPN Domain 154 An Intranet protected by a VPN gateway. 155 DMZ 156 (Demilitarized Zone) A small network inserted as a "neutral 157 zone" between a company's private network and the outside 158 public network to prevent outside users from getting direct 159 access to the company's private network 160 Home Network 161 A network, possibly virtual, having a network prefix matching 162 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. 168 MIPv4 inside IPsec-ESP tunnel 169 MIPv4 packet is encapsulated in an IPsec-ESP tunnel 170 established between the Mobile Node and the VPN gateway. 171 IPsec-ESP inside MIPv4 tunnel 172 IPsec-ESP packet is encapsulated in an MIPv4 tunnel 173 established between the Mobile Node and the home agent. 175 2. MIP and VPN Deployment Scenarios 177 This section describes a set of deployment scenarios where MIP agents 178 and VPN gateways have to coexist to provide mobility and security. 179 The intention is to identify practical deployment scenarios for MIP 180 and VPNs where MIP technology might be extended to solve problems 181 resulting from the desire for co-existence. 183 In all scenarios, "MN" refers to a mobile node that runs both MIP and 184 IPsec-based VPN client software. The foreign network might or 185 might not employ a foreign agent. And, the term "Intranet" 186 refers to a private network protected by a VPN gateway and perhaps a 187 layer-3 transparent or non-transparent firewall. Please note that 188 firewalls are purposely omitted from the following scenarios, 189 because they may be installed in a number of different ways, and the 190 fact that this draft's focus is the relationship between MIP and VPN. 192 Finally, the scenarios assume that encryption is not enforced inside 193 the VPN domain because 1) the VPN domain (Intranet) is viewed as a 194 trusted network, and users allowed inside the Intranet are also 195 trusted 2) it is a common VPN deployment practice where the VPN is 196 used to guard the Intranet resources from unauthorized users attached 197 to an untrusted network, and to provide a secure communication 198 channel for authorized users to access resources inside the Intranet 199 from outside. 201 The following sub-sections introduce five representative 202 combinations of MIPv4 HA and VPN gateway placement. 204 2.1 MIPv4 HA(s) Inside the Intranet behind a VPN Gateway 206 MIPv4 HAs are deployed inside the Intranet protected by a VPN 207 gateway, and are not directly reachable by the MNs outside the 208 Intranet. 210 ..Foreign Network.. .....VPN Domain..(Intranet)..... 211 . . . . 212 . +----+ +----+ . +----+ +-------+ +-------+ . 213 . |MNs | | FA | . | VPN| | Router| | HA | . 214 . |away| | | .<=========>| | | 1..n | | 1..n | . 215 . +----+ +----+ . | GW | +-------+ +-------+ . 216 . . +----+ . 217 ................... . +-------+ +-------+ . 218 . | CN | | MNs | . 219 . | 1..n | | home | . 220 . +-------+ +-------+ . 221 . . 222 ................................ 224 Figure 1 226 Direct application of MIPv4 standards [RFC3344] is successfully used 227 to provide mobility for users inside the Intranet. However, mobile 228 users outside the Intranet can only access the Intranet resources 229 (e.g., MIP agents) through the VPN gateway, which will allow only 230 authenticated IPsec traffic inside. This implies that the MIPv4 231 traffic has to run inside IPsec, which leads to two distinct 232 problems: 234 1. When the foreign network has an FA deployed (as in e.g. CDMA 235 2000), MIPv4 registration becomes impossible. This is because 236 the MIPv4 traffic between MN and VPN gateway is encrypted and the 237 FA (which is likely in a different administrative domain) cannot 238 inspect the MIPv4 headers needed for relaying the MIPv4 packets. 239 Please see Section 4.2 for more details. 241 2. In co-located mode, successful registration is possible but the 242 VPN tunnel has to be re-negotiated every time the MN changes its 243 point of network attachment. 245 Please note that the VPN tunnel re-negotiation problem can be 246 avoided by the work that the MOBIKE workgroup has been chartered 247 to accomplish. 249 These problems are articulated in Section 4. 251 This deployment scenario may not be common yet, but it is practical 252 and becoming important as there is an increasing need for providing 253 corporate remote users with continuous access to the Intranet 254 resources. 256 2.2 VPN Gateway and MIPv4 HA(s) on the VPN domain border 258 A MIPv4 HA is deployed on the VPN domain border (e.g., in the DMZ) 259 together with the VPN gateway, and it is directly reachable by MNs 260 inside or outside the Intranet. 262 ..Foreign Network.. .....VPN Domain..(Intranet)..... 263 . . . . 264 . +----+ +----+ . +----+ +-------+ . 265 . |MNs | | FA | . | VPN| | Router| . 266 . |away| | | .<=========>| | | 1..n | . 267 . +----+ +----+ . /\ | GW | +-------+ . 268 . . || +----+ . 269 . . || +----+ +-------+ +-------+ . 270 . . ++====>| HA | | CN | | MNs | . 271 ................... | | | 1..n | | home | . 272 +----+ +-------+ +-------+ . 273 . . 274 ................................ 276 Figure 2 278 The MIPv4 HA has a public interface connected to the Internet, and a 279 private interface attached to the Intranet. Mobile users will most 280 likely have a virtual home network associated with the MIPv4 HA's 281 private interface, so that the mobile users are always away from home 282 and hence registered with the MIPv4 HA. Furthermore, in deployments 283 where the VPN gateway and the HA are placed in a corporate DMZ, this 284 implies that MIPv4 traffic will always be routed through the 285 DMZ (regardless of whether MNs are located outside or inside the 286 Intranet), which may not be acceptable by IT departments in large 287 corporations. 289 This deployment can be used with two different configurations: "MIPv4 290 inside IPsec-ESP tunnel" and "IPsec-ESP inside MIPv4 tunnel". The 291 "MIPv4 inside IPsec-ESP tunnel" has the same problems as the scenario 292 of Section 2.1 (namely, MIPv4 registration becomes impossible when 293 the registration is to be done via an FA and furthermore in 294 co-located mode, the VPN tunnel has to be re-negotiated every time 295 the MN changes its point of attachment). The "IPsec-ESP inside MIPv4 296 tunnel" does not have problems described in Section 2.1, however it 297 will require some modifications to the routing logic of the MIPv4 HA 298 or the VPN gateway. 300 2.3 Combined VPN Gateway and MIPv4 HA 302 This is similar to deployment scenario described in Section 2.2, with 303 the exception that the VPN gateway and MIPv4 HA are running on the 304 same physical machine. 306 ..Foreign Network.. .....VPN Domain..(Intranet)..... 307 . . . . 308 . +----+ +----+ . +----+ +-------+ . 309 . |MNs | | FA | . | VPN| | Router| . 310 . |away| | | .<==========| GW | | 1..n | . 311 . +----+ +----+ . | + | +-------+ . 312 . . | HA | . 313 ................... +----+ +-------+ +-------+ . 314 . | CN | | MNs | . 315 . | 1..n | | home | . 316 . +-------+ +-------+ . 317 . . 318 ................................ 320 Figure 3 322 Running MIPv4 HA and VPN on the same machine resolves routing 323 related issues that exist in Section 2.2 when a "IPsec-ESP inside 324 MIPv4 tunnel" configuration is used. However, it does not promote 325 multi-vendor interoperability in environments where MIPv4 HA and VPN 326 technologies must be acquired from different vendors. 328 2.4 MIPv4 HA(s) Outside the VPN domain 330 In this scenario, MIPv4 HAs are deployed outside the Intranet (e.g., 331 in an operator network), as depicted in Figure 4 below. 333 ..Foreign Network.. .....VPN Domain..(Intranet)..... 334 . . . . 335 . +----+ +----+ . +----+ +-------+ . 336 . |MNs | | FA | . | VPN| | Router| . 337 . |away| | | .<==========| GW | | 1..n | . 338 . +----+ +----+ . /\ | | +-------+ . 339 . . || | | . 340 ................... || | | +-------+ +-------+ . 341 || | | | CN | | MNs | . 342 .....MIPv4 Home.... || | | | 1..n | | home | . 343 . .<===++ | | +-------+ +-------+ . 344 . +------+ . +----+ . 345 . | HAs | . . . 346 . | 1..n | . ................................ 347 . +------+ . 348 ................... 350 Figure 4 352 In this deployment scenario the goal is to provide remote users with 353 continuous access to the Intranet resources while they are roaming 354 outside the Intranet only (i.e., mobility is not supported inside the 355 Intranet). In this case it is most practical to run IPsec-ESP inside 356 a MIPv4 tunnel (i.e., MIPv4 tunnel end-points are the MN and the HA; 357 the IPsec-ESP packet from the MN and to the VPN gateway is 358 encapsulated in the MIPv4 tunnel) as the MNs can register with the HA 359 without establishing an IPsec tunnel to the VPN gateway. This should 360 work without any technical problems. The IPsec tunnel end-points 361 will be the MN and the VPN gateway. The 'home network' will be a 362 virtual home network, located at the HA, from which it is possible to 363 reach the Corporate Intranet through the VPN gateway. 365 2.5 Combined VPN Gateway and MIPv4 HA(s) on the Local Link 367 This is similar to the deployment scenario described in Section 2.3, 368 with the difference that the VPN gateway/HA is sitting on the local 369 link. In this the VPN gateway and HA would most naturally be 370 co-located in the same box, although this is in no way a requirement. 372 ..Foreign Network.. .....VPN Domain..(Intranet)..... 373 . . . . 374 . +----+ +----+ . +------+ +-------+ +-------+ . 375 . |MNs | | FA | . | Fire | | Router| | VPN/HA| . 376 . |away| | | .<=======>| wall | | 1..n | | 1..n | . 377 . +----+ +----+ . | | +-------+ +-------+ . 378 . . | NAT | . 379 ................... +------+ +-------+ +-------+ . 380 . | CN | | MNs | . 381 . | 1..n | | home | . 382 . +-------+ +-------+ . 383 . . 384 ................................ 386 Figure 5 388 This deployment works today without any technical problems with 389 IPsec-ESP running inside a MIPv4 tunnel. If however MIPv4 is run 390 inside the IPsec-ESP tunnel it has the same problems as in Section 391 2.1 (namely, MIPv4 registration becomes impossible when the 392 registration is to be done via an FA and furthermore in co-located 393 mode, the VPN tunnel has to be re-negotiated every time the MN 394 changes its point of attachment). This deployment is not common or 395 practical for large deployments (on the order of thousands of users) 396 because of the large and distributed security perimeter. 398 3. Deployment Scenarios Selection 400 The deployment scenarios described in Section 2 were evaluated to 401 identify the ones most in need of solving. The evaluation was done 402 based on two main criteria: 1) Is the deployment scenario common and 403 practical? and 2) Does the deployment scenario reveal any problems 404 resulting from MIPv4 and VPN coexistence? 406 There was a consensus about importance and practicality of the 407 scenario in Section 2.1 because of rising needs to provide corporate 408 remote users with continuous access to their Intranet resources. 409 After analyzing each scenario one realizes that problems occurring in 410 scenarios in Section 2.2 and Section 2.4 are either the same as or a 411 subset of those in the scenario in Section 2.1. Therefore, solving 412 the scenario in Section 2.1 will also solve the scenarios in Section 413 2.2 and Section 2.4. The scenarios in Section 2.3 and Section 2.5 do 414 not introduce functional problems resulting from MIPv4 and VPN 415 co-existence, hence there is no need to seek a solution. A solution 416 for the deployment scenario in Section 2.1 is therefore seen as 417 essential, and this in turn can also be applied to solve problems in 418 other scenarios. For the remainder of this draft, we will articulate 419 the roaming scenarios, the problems, and the solution guidelines 420 relevant to the scenario in Section 2.1. 422 4. Problem statement 424 This section describes roaming scenarios corresponding to the 425 deployment scenario in Section 2.1 where an MN needs to have 426 continuous access to the Intranet resources regardless of whether it 427 is roaming inside or outside the Intranet, and their associated 428 problems. The scenarios are constructed based on a multi-subnetted, 429 MIPv4-enabled Intranet (hereafter, referred to as Intranet or VPN 430 domain) protected by an IPsec-based VPN gateway as depicted in Figure 431 6. 433 ....Internet....... .....VPN Domain..(Intranet)..... 434 . . . . 435 . +----+ . +----+ +-------+ +-------+ . 436 . |MNs | . | VPN| | Router| | VPN/HA| . 437 . |away| .<=========>| | | 1..n | | 1..n | . 438 . +----+ . | GW | +-------+ +-------+ . 439 . . +----+ . 440 ................... . +-------+ +-------+ . 441 . | CN | | MNs | . 442 . | 1..n | | home | . 443 . +-------+ +-------+ . 444 . . 445 ................................ 447 Figure 6: Intranet protected by a VPN Gateway 449 The Intranet, depicted in Figure 6, may include both wired (IEEE 450 802.3) and IEEE 802.11 wireless LAN deployments. However, it is also 451 possible to see IEEE 802.11 deployments outside the Intranet due to 452 the perceived lack of current 802.11 security, as depicted in Figure 453 7. 455 ....Internet....... .....VPN Domain..(Intranet)..... 456 . . . . 457 . +----+ . +----+ +-------+ +-------+ . 458 . |MNs | . | VPN| | Router| | VPN/HA| . 459 . |away| .<=========>| | | 1..n | | 1..n | . 460 . +----+ . | GW | +-------+ +-------+ . 461 . . | | . 462 ................... | | +-------+ +-------+ . 463 | | | CN | | MNs | . 464 ..802.11 Wireless.. <====>| | | 1..n | | home | . 465 . Network . +----+ +-------+ +-------+ . 466 . . . . 467 ................... ................................ 469 Figure 7: IEEE 802.11 Wireless deployment outside the home network 471 4.1 Registering in co-located mode 473 In co-located mode, the IPsec tunnel endpoints would be at the MN and 474 the VPN gateway, which (supposing we have the scenario described in 475 Section 2.1) results in the mobile-ip tunnel from MN to HA being 476 encapsulated inside the IPsec tunnel. See Figure 8 below. This 477 scenario is still possible, but has some major drawbacks. 479 ....Internet....... .....VPN Domain..(Intranet)..... 480 . . . . 481 . +----+ . +----+ +-------+ +-------+ . 482 . |MNs | . | VPN| | Router| | VPN/HA| . 483 . |away|<###################>| |-----| 1..n |->| 1..n | . 484 . +----+ . \ | GW | +-------+ +-------+ . 485 . . \ +----+ . 486 ................... mip . +-------+ +-------+ . 487 inside . | CN | | MNs | . 488 IPsec . | 1..n | | home | . 489 . +-------+ +-------+ . 490 . . 491 ................................ 493 Figure 8 495 The MN obtains an address at its point of attachment (via DHCP 496 [RFC2131] or some other means), and then first sets up an IPsec 497 tunnel to the VPN gateway, after which it can successfully register 498 with its HA through the IPsec tunnel. The problem is that in an 499 end-to-end security model, an IPsec tunnel that terminates at the VPN 500 gateway must protect the IP traffic originating at the MN. As the 501 MN's IPsec tunnel address is the address obtained at the point of 502 attachment, it will change during movement, and the VPN tunnel 503 security association must be refreshed after each IP subnet handoff. 504 This could have noticeable performance implications on real-time 505 applications. In effect, we don't have mobility support for the 506 tunnel endpoint changes associated with MN movements. 508 4.2 Registering via an FA 510 In the case where a mobile node is in a network where mobility 511 support is provided through the use of an FA, and no DHCP allocated 512 address and co-located mode is possible, we run into severe trouble. 513 Figure 9 below illustrates this: 515 ..Foreign Network.. .....VPN Domain..(Intranet)..... 516 . . . . 517 . +----+ +----+ . +----+ +-------+ +-------+ . 518 . |MNs | | FA | . | VPN| | Router| | VPN/HA| . 519 . |away|| |-----| 1..n |->| 1..n | . 520 . +----+ \ +----+ . \ | GW | +-------+ +-------+ . 521 . \ . \ +----+ . 522 ...........\....... mip . +-------+ +-------+ . 523 \ inside . | CN | | MNs | . 524 MN expects IPsec . | 1..n | | home | . 525 IPsec traffic . +-------+ +-------+ . 526 . . 527 ................................ 529 Figure 9 531 The mobile node, when arriving at this network, may have a IPsec 532 session going with its VPN gateway. This session will not be passed 533 through the FA as long as the MN has not registered and a mip tunnel 534 has been set up. But the MN, which is secure inside the IPsec based 535 VPN, will not even hear the FA advertisements. And any IPsec traffic 536 from the Intranet (via the VPN gateway and IPsec tunnel) will not be 537 understood by the FA. Simply put, you could say that the FA needs to 538 see the mip tunnel outermost, while the VPN-GW needs to see the IPsec 539 tunnel outermost. Or in more details: 541 Firstly, the MN must have a IPsec tunnel established with the VPN-GW 542 in order to reach the HA, which places the IPsec tunnel outside the 543 mip traffic between MN and HA. The FA (which is likely in a 544 different administrative domain) cannot decrypt MIPv4 packets between 545 the MN and the VPN gateway, and will consequently be not able to 546 relay the MIPv4 packets. This is because the MIPv4 headers (which 547 the FA should be able to interpret) will be encrypted and protected 548 by IPsec. 550 Secondly, when the MN is communicating with the VPN-GW, an explicit 551 bypass policy for MIP packets is required, so that the MN can hear FA 552 advertisements and send and receive MIP registration packets. 553 Although not a problem in principle, there may be practical problems 554 when VPN and MIP clients from different vendors are used. 556 The use of a 'trusted FA' has been suggested in this scenario; 557 meaning an FA which is actually a combined VPN GW and FA. The 558 scenario will work fine in this case; effectively we are then 559 operating within the VPN established between the two VPN gateways, 560 and the case is analogous to deploying mobile-ip within a corporate 561 Intranet which is not physically disjoint. See Figure 10 below. 562 However, we cannot expect that e.g. wireless hot-spots or CDMA 2000 563 FAs will have VPN gateways with security associations with any given 564 corporate network, so this is not particularly realistic in the 565 general mobility case. 567 ..Foreign Network.. .....VPN Domain..(Intranet)..... 568 . . . . 569 . +----+ +----+ . +----+ +-------+ +-------+ . 570 . | FA | | VPN| . | VPN| | Router| | VPN/HA| . 571 . | |<--| GW |<###########>| |-----| 1..n |->| 1..n | . 572 . +----+ +----+ . \ | GW | +-------+ +-------+ . 573 . | . \ +----+ . 574 . +----+ . mip . +-------+ +-------+ . 575 . |MNs | . inside . | CN | | MNs | . 576 . |away| . IPsec . | 1..n | | home | . 577 . +----+ . . +-------+ +-------+ . 578 ................... . . 579 ................................ 581 Figure 10 583 Furthermore, this solution would leave the traffic between FA and MN 584 unprotected, and as this link in particular may be a wireless link, 585 this is clearly undesirable. 587 4.3 Summary: MIP Incompatibilities with IPsec-based VPN Gateways 589 An MN roaming outside the Intranet has to establish an IPsec tunnel 590 to its home VPN gateway first, in order to be able to register with 591 its home agent. This is because the MN cannot reach its HA (inside 592 the private protected network) directly from the outside. This 593 implies that the MIPv4 traffic from the MN to a node inside the 594 Intranet is forced to run inside an IPsec tunnel, and hence will not 595 be in the clear. This in turn leads to two distinct problems 596 depending on whether the MN uses co-located or non co-located modes 597 to register with its HA. 599 5. Solution Guidelines 601 This section describes guidelines for a solution to MIPv4 traversal 602 across VPN gateways. 604 5.1 Preservation of Existing VPN Infrastructure 606 o The solution MUST preserve the investment in existing VPN 607 gateways. 608 o The solution MUST provide security which is not inferior to what 609 is already provided to existing "nomadic computing" remote access 610 users, i.e. for confidentiality, authentication, message 611 integrity, protection against replay attacks and related security 612 services. 614 5.2 Software Upgrades to Existing VPN Client and Gateways 616 o The solution SHOULD minimize changes to existing VPN client/ 617 gateway software. 619 5.3 IPsec Protocol 621 o The solution SHOULD NOT require any changes to existing IPsec or 622 key exchange standard protocols implemented by VPN gateways. 623 o The solution SHOULD NOT require that the VPN gateway or the VPN 624 client implement any new protocols in addition to the existing 625 standard protocols. 627 5.4 Multi-Vendor Interoperability 629 o The solution MUST provide multi-vendor interoperability, where 630 MIPv4 mobility agents, mobility clients (MN), VPN server, and VPN 631 client solutions may come from four different vendors. This is 632 typical for medium and large enterprises which purchase and deploy 633 best-of-breed multi-vendor solutions for IP routing, VPNs, 634 firewalls etc. 636 5.5 MIPv4 Protocol 638 o The solution MUST adhere to MIPv4 protocol [RFC3344]. That is, 639 the solution MUST NOT impose any changes that violates MIPv4 640 protocol. 641 o The solution MAY introduce new extensions to MIPv4 nodes per 642 guidelines specified in the MIPv4 protocol [RFC3344]. However, it 643 is highly desirable to avoid any changes to MIPv4 mobility agents 644 such as the FA and HA in order to overcome barriers to 645 deployment. 647 o The solution MAY require more than one instance of MIPv4 running 648 in parallel (multiple encapsulation). 650 5.6 Handoff Overhead 652 o It is imperative to keep the key management overhead down to a 653 minimum, in order to support fast handoffs across IP subnets. 654 Hence, the solution MUST propose a mechanism to avoid or minimize 655 IPsec tunnel SA renegotiation and IKE renegotiation as the MN 656 changes its current point of network attachment. 658 5.7 Scalability, Availability, Reliability, and Performance 660 o The solution complexity MUST increase at most linearly with the 661 number of MNs registered and accessing resources inside the 662 Intranet. 663 o The solution MAY introduce additional header or tunnelling 664 overhead if needed. 666 5.8 Functional Entities 668 o The solution MAY introduce new MIPv4 compliant functional 669 entities. 671 5.9 Implications of Intervening NAT Gateways 673 o The solution MUST be able to leverage the existing MIPv4 and IPsec 674 NAT traversal solutions [RFC3519][IPSEC-NAT][IKE-NAT]. 676 5.10 Security Requirements 678 o The solution MUST NOT introduce any new vulnerabilities to the 679 MIPv4 or IPsec as specified in related RFCs. 681 6. Security Considerations 683 This document describes an existing problem and proposes guidelines 684 for possible solutions; as such its security implications are 685 indirect, through the guidelines it proposes for the solutions. 686 Section 5.10 gives the relevant security requirements. 688 7. Acknowledgements 690 The authors who contributed text to this document were in no 691 particular order: Farid Adrangi, Milind Kulkarni, Gopal Dommety, Eli 692 Gelasco, Qiang Zhang, Sami Vaarala, Dorothy Gellert, Nitsan Baider 693 and Henrik Levkowetz. 695 The authors would like to thank other contributors, especially 696 Prakash Iyer, Mike Andrews, Ranjit Narjala, Joe Lau, Kent Leung, 697 Alpesh Patel, Phil Roberts, Hans Sjostrand, Serge Tessier, Antti 698 Nuopponen, Alan O'neill, Gaetan Feige, Brijesh Kumar for their 699 continuous feedback and helping us improve this draft. 701 Normative References 703 [RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, 704 August 2002. 706 Informative References 708 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 709 Requirement Levels", BCP 14, RFC 2119, March 1997. 711 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 712 2131, March 1997. 714 [RFC3519] Levkowetz, H. and S. Vaarala, "Mobile IP Traversal of 715 Network Address Translation (NAT) Devices", RFC 3519, May 716 2003. 718 [IPSEC-NAT] 719 Aboba, B. and W. Dixon, "IPsec-NAT Compatibility 720 Requirements", draft-ietf-ipsec-nat-reqts-06 (work in 721 progress), October 2003. 723 [IKE-NAT] Kivinen, T., "Negotiation of NAT-Traversal in the IKE", 724 draft-ietf-ipsec-nat-t-ike-07 (work in progress), 725 September 2003. 727 Authors' Addresses 729 Farid Adrangi 730 Intel Corporation 731 2111 N.E. 25th Avenue 732 Hillsboro OR 733 USA 735 Phone: +1 503-712-1791 736 EMail: farid.adrangi@intel.com 737 Henrik Levkowetz 738 ipUnplugged AB 739 Arenavagen 33 740 Stockholm S-121 28 741 SWEDEN 743 Phone: +46 8 725 9513 744 EMail: henrik@levkowetz.com 746 Milind Kulkarni 747 Cisco Systems 748 170 W. Tasman Drive 749 San Jose CA 95134 750 USA 752 Phone: +1 408-527-8382 753 EMail: mkulkarn@cisco.com 755 Gopal Dommety 756 Cisco Systems 757 170 W. Tasman Drive 758 San Jose CA 95134 759 USA 761 EMail: gdommety@cisco.com 763 Eli Gelasco 764 Cisco Systems 765 170 W. Tasman Drive 766 San Jose CA 95134 767 USA 769 EMail: egelasco@cisco.com 771 Qiang Zhang 772 Liqwid Networks, Inc. 773 1000 Wilson Blvd, Suite 900 774 Arlington VA 22209 775 USA 777 Phone: +1 703-224-1120 -x 203 778 EMail: qzhang@liqwidnet.com 779 Sami Vaarala 780 Netseal 781 Niittykatu 6 782 Espoo 02201 783 FINLAND 785 Phone: +358 9 435 310 786 EMail: sami.vaarala@iki.fi 788 Dorothy Gellert 789 Nokia Corporation 791 EMail: dorothy.gellert@nokia.com 793 Nitsan Baider 794 Check Point Software Technologies, Inc. 796 EMail: nitsan@checkpoint.com 798 Intellectual Property Statement 800 The IETF takes no position regarding the validity or scope of any 801 intellectual property or other rights that might be claimed to 802 pertain to the implementation or use of the technology described in 803 this document or the extent to which any license under such rights 804 might or might not be available; neither does it represent that it 805 has made any effort to identify any such rights. Information on the 806 IETF's procedures with respect to rights in standards-track and 807 standards-related documentation can be found in BCP-11. Copies of 808 claims of rights made available for publication and any assurances of 809 licenses to be made available, or the result of an attempt made to 810 obtain a general license or permission for the use of such 811 proprietary rights by implementors or users of this specification can 812 be obtained from the IETF Secretariat. 814 The IETF invites any interested party to bring to its attention any 815 copyrights, patents or patent applications, or other proprietary 816 rights which may cover technology that may be required to practice 817 this standard. Please address the information to the IETF Executive 818 Director. 820 Full Copyright Statement 822 Copyright (C) The Internet Society (2004). All Rights Reserved. 824 This document and translations of it may be copied and furnished to 825 others, and derivative works that comment on or otherwise explain it 826 or assist in its implementation may be prepared, copied, published 827 and distributed, in whole or in part, without restriction of any 828 kind, provided that the above copyright notice and this paragraph are 829 included on all such copies and derivative works. However, this 830 document itself may not be modified in any way, such as by removing 831 the copyright notice or references to the Internet Society or other 832 Internet organizations, except as needed for the purpose of 833 developing Internet standards in which case the procedures for 834 copyrights defined in the Internet Standards process must be 835 followed, or as required to translate it into languages other than 836 English. 838 The limited permissions granted above are perpetual and will not be 839 revoked by the Internet Society or its successors or assignees. 841 This document and the information contained herein is provided on an 842 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 843 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 844 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 845 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 846 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 848 Acknowledgment 850 Funding for the RFC Editor function is currently provided by the 851 Internet Society.