idnits 2.17.1 draft-ietf-mip4-vpn-problem-statement-03.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.a on line 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 817. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 794. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 801. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 807. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 4, 2004) is 7144 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) -- Obsolete informational reference (is this intentional?): RFC 2401 (Obsoleted by RFC 4301) Summary: 7 errors (**), 0 flaws (~~), 2 warnings (==), 8 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: April 4, 2005 H. Levkowetz, Ed. 5 October 4, 2004 7 Problem Statement: Mobile IPv4 Traversal of VPN Gateways 8 draft-ietf-mip4-vpn-problem-statement-03 10 Status of this Memo 12 This document is an Internet-Draft and is subject to all provisions 13 of section 3 of RFC 3667. By submitting this Internet-Draft, each 14 author represents that any applicable patent or other IPR claims of 15 which he or she is aware have been or will be disclosed, and any of 16 which he or she become aware will be disclosed, in accordance with 17 RFC 3668. 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 22 Internet-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 April 4, 2005. 37 Copyright Notice 39 Copyright (C) The Internet Society (2004). 41 Abstract 43 Deploying Mobile-IP v4 in networks which are connected to the 44 Internet through a VPN (Virtual Private Network) gateway presents 45 some problems which do not currently have well-described solutions. 46 This document aims to describe and illustrate these problems, and 47 propose some guidelines for possible solutions. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 52 1.1 Overview of the Problem . . . . . . . . . . . . . . . . . 3 53 1.2 Specification of Requirements . . . . . . . . . . . . . . 4 54 1.3 Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 55 2. MIP and VPN Deployment Scenarios . . . . . . . . . . . . . . 4 56 2.1 MIPv4 HA(s) Inside the Intranet behind a VPN Gateway . . . 5 57 2.2 VPN Gateway and MIPv4 HA(s) on the VPN domain border . . . 6 58 2.3 Combined VPN Gateway and MIPv4 HA . . . . . . . . . . . . 7 59 2.4 MIPv4 HA(s) Outside the VPN domain . . . . . . . . . . . . 8 60 2.5 Combined VPN Gateway and MIPv4 HA(s) on the Local Link . . 9 61 3. Deployment Scenarios Selection . . . . . . . . . . . . . . . 10 62 4. Problem statement . . . . . . . . . . . . . . . . . . . . . 10 63 4.1 Registering in co-located mode . . . . . . . . . . . . . . 11 64 4.2 Registering via an FA . . . . . . . . . . . . . . . . . . 12 65 4.3 Summary: MIP Incompatibilities with IPsec-based VPN 66 Gateways . . . . . . . . . . . . . . . . . . . . . . . . . 14 67 5. Solution Guidelines . . . . . . . . . . . . . . . . . . . . 15 68 5.1 Preservation of Existing VPN Infrastructure . . . . . . . 15 69 5.2 Software Upgrades to Existing VPN Client and Gateways . . 15 70 5.3 IPsec Protocol . . . . . . . . . . . . . . . . . . . . . . 15 71 5.4 Multi-Vendor Interoperability . . . . . . . . . . . . . . 15 72 5.5 MIPv4 Protocol . . . . . . . . . . . . . . . . . . . . . . 15 73 5.6 Handoff Overhead . . . . . . . . . . . . . . . . . . . . . 16 74 5.7 Scalability, Availability, Reliability, and Performance . 16 75 5.8 Functional Entities . . . . . . . . . . . . . . . . . . . 16 76 5.9 Implications of Intervening NAT Gateways . . . . . . . . . 16 77 5.10 Security Requirements . . . . . . . . . . . . . . . . . 16 78 6. Security Considerations . . . . . . . . . . . . . . . . . . 16 79 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 80 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 81 8.1 Normative References . . . . . . . . . . . . . . . . . . . . 17 82 8.2 Informative References . . . . . . . . . . . . . . . . . . . 17 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 18 84 Intellectual Property and Copyright Statements . . . . . . . 19 86 1. Introduction 88 Mobile IP [RFC3344] agents are being deployed in enterprise networks 89 to enable mobility across wired and wireless LANs while roaming 90 inside the enterprise Intranet. With the growing deployment of IEEE 91 802.11 access points ("hot spots") in public places such as hotels, 92 airports, and convention centers, and wireless WAN data networks such 93 as General Packet Radio Service (GPRS), the need for enabling mobile 94 users to maintain their transport connections and constant 95 reachability while connecting back to their target "home" networks 96 protected by Virtual Private Network (VPN) technology is increasing. 97 This implies that Mobile IP and VPN technologies have to coexist and 98 function together in order to provide mobility and security to the 99 enterprise mobile users. 101 The goal of this document is to: 102 o Identify and describe practical deployment scenarios for Mobile IP 103 and VPN in enterprise and operator environments. 104 o Identify example usage scenarios for remote users roaming outside 105 the "home" network protected by a VPN gateway. 106 o Articulate the problems resulting from Mobile IP and VPN 107 coexistence. 108 o Specify a set of framework guidelines to evaluate proposed 109 solutions to supporting multi-vendor seamless IPv4 mobility across 110 IPsec-based VPN gateways. 112 1.1 Overview of the Problem 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 Intranet (also referred to as VPN 119 domain), roaming between the Intranet (i.e., trusted domain) and the 120 internet (i.e., untrusted domain) 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 (using VPN for remote access) who desire to 126 add mobility support because of a need to have continuous access to 127 Intranet resources while roaming outside the Intranet from one subnet 128 to another, or between the VPN domain and the Internet. 130 From the beginning it was also assumed that VPNs and firewalls were 131 to be taken as more or less granted because they have much wider 132 deployments than MIP at the present. Therefore any solutions would 133 need to minimize impact on existing VPN and firewall deployments, 134 related standards and "de facto" standards. 136 1.2 Specification of Requirements 138 In this document, several words are used to signify the requirements 139 of the specification. These words are often capitalized. The key 140 words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", 141 "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document 142 are to be interpreted as described in [RFC2119]. 144 1.3 Terminology 146 MIPv4 Mobile IP for IPv4 [RFC3344] 147 MIPv6 Mobile IP for IPv6 148 VPN Virtual Private Network 149 GW Gateway 150 VPN Domain 151 An Intranet protected by a VPN gateway. 152 DMZ 153 (Demilitarized Zone) A small network inserted as a "neutral 154 zone" between a company's private network and the outside 155 public network to prevent outside users from getting direct 156 access to the company's private network 157 Home Network 158 A network, possibly virtual, having a network prefix matching 159 that of a mobile node's home address. 160 Home Agent 161 A router on a mobile node's home network which tunnels 162 datagrams for delivery to the mobile node when it is away 163 from home, and maintains current location information for the 164 mobile node. 165 MN 166 Refers to a mobile node that runs both MIP and IPsec-based 167 VPN client software. 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 The network topology in the following diagrams consists of an 184 Intranet connected to the public network (i.e., Internet). Here, the 185 word "Intranet" refers to a private network (where private addresses 186 [RFC1918] are typically used) protected by a VPN gateway and perhaps 187 a layer-3 transparent or non-transparent firewall. When private 188 addresses are used, the non-transparent firewall also functions as a 189 Network Address Translator (NAT) or Network Address Port Translator 190 (NAPT) bridging between the two address realms (i.e., the Intranet 191 and the internet). 193 Firewalls may be placed on either side of the VPN gateway - referred 194 to as inner and outer firewalls. The inner and outer firewalls 195 typically inspect outbound traffic (i.e., from the Intranet to the 196 Internet) and inbound traffic (i.e., from the Internet to the 197 Intranet) respectively. When a firewall is present, it MUST be 198 configured to allow Mobile IP traffic (both control and tunneled data 199 packets) go through. As our focus here is the relationship between 200 MIP and VPN, we have purposely omitted firewall from the following 201 scenarios in order to keep things simple. 203 It is assumed that encryption is not enforced inside the VPN domain 204 because: 1) the VPN domain (Intranet) is viewed as a trusted network, 205 and users allowed inside the Intranet are also trusted 2) it is a 206 common VPN deployment practice where the VPN is used to guard the 207 Intranet resources from unauthorized users attached to an untrusted 208 network, and to provide a secure communication channel for authorized 209 users to access resources inside the Intranet from outside. 211 The following sub-sections introduce five representative combinations 212 of MIPv4 HA and VPN gateway placement. 214 In order to give a reasonably complete survey of MIPv4 and VPN 215 co-existence scenarios, the ones in Section 2.3 and Section 2.5 are 216 included even though, as covered in more detail below, there are no 217 co-existence problems to be solved in these two cases. 219 2.1 MIPv4 HA(s) Inside the Intranet behind a VPN Gateway 221 MIPv4 HAs are deployed inside the Intranet protected by a VPN 222 gateway, and are not directly reachable by the MNs outside the 223 Intranet. 225 ..Foreign Network.. .....VPN Domain..(Intranet)..... 226 . . . . 227 . +----+ +----+ . +----+ +-------+ +-------+ . 228 . |MNs | | FA | . | VPN| | Router| | HA | . 229 . |away| | | .<=========>| | | 1..n | | 1..n | . 230 . +----+ +----+ . | GW | +-------+ +-------+ . 231 . . +----+ . 232 ................... . +-------+ +-------+ . 233 . | CN | | MNs | . 234 . | 1..n | | home | . 235 . +-------+ +-------+ . 236 . . 237 ................................ 239 Figure 1 241 Direct application of MIPv4 standards [RFC3344] is successfully used 242 to provide mobility for users inside the Intranet. However, mobile 243 users outside the Intranet can only access the Intranet resources 244 (e.g., MIP agents) through the VPN gateway, which will allow only 245 authenticated IPsec traffic inside. This implies that the MIPv4 246 traffic has to run inside IPsec, which leads to two distinct 247 problems: 249 1. When the foreign network has an FA deployed (as in e.g. CDMA 250 2000), MIPv4 registration becomes impossible. This is because 251 the MIPv4 traffic between MN and VPN gateway is encrypted and the 252 FA (which is likely in a different administrative domain) cannot 253 inspect the MIPv4 headers needed for relaying the MIPv4 packets. 254 Please see Section 4.2 for more details. 256 2. In co-located mode, successful registration is possible but the 257 VPN tunnel has to be re-negotiated every time the MN changes its 258 point of network attachment. 260 These problems are articulated in Section 4. 262 This deployment scenario may not be common yet, but it is practical 263 and becoming important as there is an increasing need for providing 264 corporate remote users with continuous access to the Intranet 265 resources. 267 2.2 VPN Gateway and MIPv4 HA(s) on the VPN domain border 269 A MIPv4 HA is deployed on the VPN domain border (e.g., in the DMZ) 270 together with the VPN gateway, and it is directly reachable by MNs 271 inside or outside the Intranet. 273 ..Foreign Network.. .....VPN Domain..(Intranet)..... 274 . . . . 275 . +----+ +----+ . +----+ +-------+ . 276 . |MNs | | FA | . | VPN| | Router| . 277 . |away| | | .<=========>| | | 1..n | . 278 . +----+ +----+ . /\ | GW | +-------+ . 279 . . || +----+ . 280 . . || +----+ +-------+ +-------+ . 281 . . ++====>| HA | | CN | | MNs | . 282 ................... | | | 1..n | | home | . 283 +----+ +-------+ +-------+ . 284 . . 285 ................................ 287 Figure 2 289 Please note that in deployments where the security policy prohibits 290 direct communication between the MN (roaming outside the Intranet) 291 and outside machines, the HA can be configured to forward only 292 encrypted traffic from/to the MN. 294 The MIPv4 HA has a public interface connected to the Internet, and a 295 private interface attached to the Intranet. Mobile users will most 296 likely have a virtual home network associated with the MIPv4 HA's 297 private interface, so that the mobile users are always away from home 298 and hence registered with the MIPv4 HA. Furthermore, in deployments 299 where the VPN gateway and the HA are placed in a corporate DMZ, this 300 implies that MIPv4 traffic will always be routed through the DMZ 301 (regardless of whether MNs are located outside or inside the 302 Intranet), which may not be acceptable by IT departments in large 303 corporations. 305 This deployment can be used with two different configurations: "MIPv4 306 inside IPsec-ESP tunnel" and "IPsec-ESP inside MIPv4 tunnel". The 307 "MIPv4 inside IPsec-ESP tunnel" has the same problems as the scenario 308 of Section 2.1 (namely, MIPv4 registration becomes impossible when 309 the registration is to be done via an FA and furthermore in 310 co-located mode, the VPN tunnel has to be re-negotiated every time 311 the MN changes its point of attachment). The "IPsec-ESP inside MIPv4 312 tunnel" does not have problems described in Section 2.1, however it 313 will require some modifications to the routing logic of the MIPv4 HA 314 or the VPN gateway. 316 2.3 Combined VPN Gateway and MIPv4 HA 318 This is similar to deployment scenario described in Section 2.2, with 319 the exception that the VPN gateway and MIPv4 HA are running on the 320 same physical machine. 322 ..Foreign Network.. .....VPN Domain..(Intranet)..... 323 . . . . 324 . +----+ +----+ . +----+ +-------+ . 325 . |MNs | | FA | . | VPN| | Router| . 326 . |away| | | .<==========| GW | | 1..n | . 327 . +----+ +----+ . | + | +-------+ . 328 . . | HA | . 329 ................... +----+ +-------+ +-------+ . 330 . | CN | | MNs | . 331 . | 1..n | | home | . 332 . +-------+ +-------+ . 333 . . 334 ................................ 336 Figure 3 338 Running MIPv4 HA and VPN on the same machine resolves routing 339 related issues that exist in Section 2.2 when a "IPsec-ESP inside 340 MIPv4 tunnel" configuration is used. However, it does not promote 341 multi-vendor interoperability in environments where MIPv4 HA and VPN 342 technologies must be acquired from different vendors. 344 2.4 MIPv4 HA(s) Outside the VPN domain 346 In this scenario, MIPv4 HAs are deployed outside the Intranet (e.g., 347 in an operator network), as depicted in Figure 4 below. 349 ..Foreign Network.. .....VPN Domain..(Intranet)..... 350 . . . . 351 . +----+ +----+ . +----+ +-------+ . 352 . |MNs | | FA | . | VPN| | Router| . 353 . |away| | | .<==========| GW | | 1..n | . 354 . +----+ +----+ . /\ | | +-------+ . 355 . . || | | . 356 ................... || | | +-------+ +-------+ . 357 || | | | CN | | MNs | . 358 .....MIPv4 Home.... || | | | 1..n | | home | . 359 . .<===++ | | +-------+ +-------+ . 360 . +------+ . +----+ . 361 . | HAs | . . . 362 . | 1..n | . ................................ 363 . +------+ . 364 ................... 366 Figure 4 368 The IPsec tunnel end-points will be the MN and the VPN gateway. The 369 'home network' will most likely be a virtual home network, located at 370 the HA, through which authorized remote users (i.e., the users have 371 successfully established a connection to the corporate VPN) can reach 372 the Corporate Intranet and maintain their transport session 373 connectivity while roaming outside the Intranet from one subnet to 374 another. Please note that this deployment scenario does not support 375 mobility inside the Intranet. 377 In this case it is most practical to run IPsec-ESP inside a MIPv4 378 tunnel (i.e., MIPv4 tunnel end-points are the MN and the HA; the 379 IPsec-ESP packet from the MN and to the VPN gateway is encapsulated 380 in the MIPv4 tunnel) as the MNs can register with the HA without 381 establishing an IPsec tunnel to the VPN gateway. This should work 382 without any technical problems. 384 2.5 Combined VPN Gateway and MIPv4 HA(s) on the Local Link 386 This is similar to the deployment scenario described in Section 2.3, 387 with the difference that the VPN gateway/HA is sitting on the local 388 link. In this case the VPN gateway and HA would most naturally be 389 co-located in the same box, although this is in no way a requirement. 391 The VPN/HA is assumed to be reachable from the external network, i.e. 392 it is assumed to have a public IP address, and the firewall is 393 assumed to be configured to allow direct access to the VPN/HA from 394 the external network. 396 ..Foreign Network.. .....VPN Domain..(Intranet)..... 397 . . . . 398 . +----+ +----+ . +------+ +-------+ +-------+ . 399 . |MNs | | FA | . | Fire | | Router| | VPN/HA| . 400 . |away| | | .<=======>| wall | | 1..n | | 1..n | . 401 . +----+ +----+ . | | +-------+ +-------+ . 402 . . | NAT | . 403 ................... +------+ +-------+ +-------+ . 404 . | CN | | MNs | . 405 . | 1..n | | home | . 406 . +-------+ +-------+ . 407 . . 408 ................................ 410 Figure 5 412 This deployment works today without any technical problems with 413 IPsec-ESP running inside a MIPv4 tunnel. If you were to run MIPv 414 inside the IPsec-ESP tunnel it would have the same problems as in 415 Section 2.1, so it is deployed with the IPsec-ESP running inside the 416 MIPv4 tunnel. This deployment is not practical for large deployments 417 (on the order of thousands of users) because of the large and 418 distributed security perimeter. 420 3. Deployment Scenarios Selection 422 The deployment scenarios described in Section 2 were evaluated to 423 identify the ones most in need of solving. The evaluation was done 424 based on two main criteria: 1) Is the deployment scenario common and 425 practical? and 2) Does the deployment scenario reveal any problems 426 resulting from MIPv4 and VPN coexistence? 428 The authors believe that the scenario in Section 2.1 is the most 429 important and practical one because of rising needs to provide 430 corporate remote users with continuous access to their Intranet 431 resources. After analyzing each scenario one realizes that problems 432 occurring in scenarios in Section 2.2 and Section 2.4 are either the 433 same as or a subset of those in the scenario in Section 2.1. 434 Therefore, solving the scenario in Section 2.1 will also solve the 435 scenarios in Section 2.2 and Section 2.4. The scenarios in Section 436 2.3 and Section 2.5 do not introduce functional problems resulting 437 from MIPv4 and VPN co-existence, hence there is no need to seek a 438 solution. A solution for the deployment scenario in Section 2.1 is 439 therefore seen as essential, and this in turn can also be applied to 440 solve problems in other scenarios. In subsequent sections, we will 441 articulate the roaming scenarios, the problems, and the solution 442 guidelines relevant to the scenario in Section 2.1. 444 4. Problem statement 446 This section describes roaming scenarios corresponding to the 447 deployment scenario in Section 2.1 where an MN needs to have 448 continuous access to the Intranet resources regardless of whether it 449 is roaming inside or outside the Intranet, and their associated 450 problems. The scenarios are constructed based on a multi-subnetted, 451 MIPv4-enabled Intranet (hereafter, referred to as Intranet or VPN 452 domain) protected by an IPsec-based VPN gateway as depicted in Figure 453 6. 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 . | 1..n | | home | . 465 . +-------+ +-------+ . 466 . . 467 ................................ 469 Figure 6: Intranet protected by a VPN Gateway 471 The Intranet, depicted in Figure 6, may include both wired (IEEE 472 802.3) and IEEE 802.11 wireless LAN deployments. However, it is also 473 possible to see IEEE 802.11 deployments outside the Intranet due to 474 the perceived lack of current 802.11 security, as depicted in Figure 475 7. 477 ....Internet....... .....VPN Domain..(Intranet)..... 478 . . . . 479 . +----+ . +----+ +-------+ +-------+ . 480 . |MNs | . | VPN| | Router| | VPN/HA| . 481 . |away| .<=========>| | | 1..n | | 1..n | . 482 . +----+ . | GW | +-------+ +-------+ . 483 . . | | . 484 ................... | | +-------+ +-------+ . 485 | | | CN | | MNs | . 486 ..802.11 Wireless.. <====>| | | 1..n | | home | . 487 . Network . +----+ +-------+ +-------+ . 488 . . . . 489 ................... ................................ 491 Figure 7: IEEE 802.11 Wireless deployment outside the home network 493 4.1 Registering in co-located mode 495 In co-located mode, the IPsec tunnel endpoints would be at the MN and 496 the VPN gateway, which (supposing we have the scenario described in 497 Section 2.1) results in the mobile-ip tunnel from MN to HA being 498 encapsulated inside the IPsec tunnel. See Figure 8 below. This 499 scenario is still possible, but has some major drawbacks. 501 ....Internet....... .....VPN Domain..(Intranet)..... 502 . . . . 503 . +----+ . +----+ +-------+ +-------+ . 504 . |MNs | . | VPN| | Router| | VPN/HA| . 505 . |away|<###################>| |-----| 1..n |->| 1..n | . 506 . +----+ . \ | GW | +-------+ +-------+ . 507 . . \ +----+ . 508 ................... mip . +-------+ +-------+ . 509 inside . | CN | | MNs | . 510 IPsec . | 1..n | | home | . 511 . +-------+ +-------+ . 512 . . 513 ................................ 515 Figure 8 517 The MN obtains an address at its point of attachment (via DHCP 518 [RFC2131] or some other means), and then first sets up an IPsec 519 tunnel to the VPN gateway, after which it can successfully register 520 with its HA through the IPsec tunnel. The IPsec tunnel SA (Security 521 Association) is identified by a triplet consisting of SPI (Security 522 Parameter Index), MN's IP destination address (i.e., the address 523 obtained at the point of attachment), and Security Protocol (AH or 524 ESP) Identifier as described in [RFC2401]. This means that as the 525 MN's IP destination address changes on each IP subnet handoff, the 526 IPsec tunnel needs to be re-established. This could have noticeable 527 performance implications on real-time applications and in 528 resource-constrained wireless networks. In effect, we don't have 529 mobility support for the tunnel endpoint changes associated with MN 530 movements. 532 4.2 Registering via an FA 534 In the case where a mobile node is in a network where mobility 535 support is provided through the use of an FA, and no DHCP allocated 536 address and co-located mode is possible, we run into severe trouble. 537 This is illustrated in Figure 9 and explained below: 539 ..Foreign Network.. .....VPN Domain..(Intranet)..... 540 . . . . 541 . +----+ +----+ . +----+ +-------+ +-------+ . 542 . |MNs | | FA | . | VPN| | Router| | VPN/HA| . 543 . |away|| |-----| 1..n |->| 1..n | . 544 . +----+ \ +----+ . \ | GW | +-------+ +-------+ . 545 . \ . \ +----+ . 546 ...........\....... mip . +-------+ +-------+ . 547 \ inside . | CN | | MNs | . 548 MN expects IPsec . | 1..n | | home | . 549 IPsec traffic . +-------+ +-------+ . 550 . . 551 ................................ 553 Figure 9 555 The MN, when arriving at the visited network on the left in this 556 figure, has to reach the FA with registration requests in order to 557 have the FA send them on to the HA. However, the MN in all 558 likelihood cannot register with the FA because the registration 559 requests will be sent encrypted, and the FA will not be able to 560 decrypt them. Now, if the MN would have a policy which allowed split 561 tunneling, so that it could reach the FA with clear text messages, 562 the FA would still not be able to get through the VPN gateway unless 563 the HA is reachable from outside and the Intranet security policy 564 allows MIP registration packets bypass the VPN gateway. 566 Even if the HA is reachable and the MIP registration succeeds, the FA 567 (which is likely in a different administrative domain) will not be 568 able to relay packets between the MN and the VPN gateway. Packets 569 from the MN will be encapsulated by the FA with IP-in-IP (RFC 2003) 570 which the VPN gateway will drop, and packets from the VPN gateway 571 will have ESP payloads (with IP-in-IP inside) which the FA will drop 572 (as it expects IP-in-IP encapsulated traffic to the MN). 574 The use of a 'trusted FA' has also been suggested in this scenario; 575 meaning an FA which is actually a combined VPN GW and FA. The 576 scenario will work fine in this case as the tunnel end-points are at 577 the FA and the VPN gateway as shown in Figure 10 below. However, we 578 cannot expect the FA in access networks (e.g., wireless hot-spots or 579 CDMA 2000 networks) will have security associations with any given 580 corporate network, so this is not particularly realistic in the 581 general mobility case. 583 ..Foreign Network.. .....VPN Domain..(Intranet)..... 584 . . . . 585 . +----+ +----+ . +----+ +-------+ +-------+ . 586 . | FA | | VPN| . | VPN| | Router| | VPN/HA| . 587 . | |<--| GW |<###########>| |-----| 1..n |->| 1..n | . 588 . +----+ +----+ . \ | GW | +-------+ +-------+ . 589 . | . \ +----+ . 590 . +----+ . mip . +-------+ +-------+ . 591 . |MNs | . inside . | CN | | MNs | . 592 . |away| . IPsec . | 1..n | | home | . 593 . +----+ . . +-------+ +-------+ . 594 ................... . . 595 ................................ 597 Figure 10 599 Furthermore, this solution would leave the traffic between FA and MN 600 unprotected, and as this link in particular may be a wireless link, 601 this is clearly undesirable. 603 4.3 Summary: MIP Incompatibilities with IPsec-based VPN Gateways 605 An MN roaming outside the Intranet has to establish an IPsec tunnel 606 to its home VPN gateway first, in order to be able to register with 607 its home agent. This is because the MN cannot reach its HA (inside 608 the private protected network) directly from the outside. This 609 implies that the MIPv4 traffic from the MN to a node inside the 610 Intranet is forced to run inside an IPsec tunnel, and hence will not 611 be in the clear. This in turn leads to two distinct problems 612 depending on whether the MN uses co-located or non co-located modes 613 to register with its HA. 615 In co-located mode, the IPsec tunnel needs to be re-established on 616 each IP subnet handoff which will have performance implications on 617 real-time applications and resource-constrained wireless networks. 619 In non co-located mode (i.e., using an FA care-of address), the 620 problem becomes severe as the MN may be unable to register with its 621 HA through the FA, because the FA cannot understand MIPv4 622 registration requests if they are encrypted in the IPsec tunnel 623 (i.e., split tunneling is not supported). Even if the MN could reach 624 the FA with non-encrypted registration requests (i.e., split 625 tunneling is supported), and the requests going from the FA to the HA 626 can pass through the VPN gateway, there will still be a problem with 627 routing of data packets between the Intranet and the internet. This 628 is because the VPN will not allow IP-in-IP encapsulated packets from 629 the FA go through. And furthermore, ESP encapsulated packets from 630 the VPN gateway to the MN will be dropped by the FA as it expects 631 IP-in-IP encapsulated traffic to the MN. 633 5. Solution Guidelines 635 This section describes guidelines for a solution to MIPv4 traversal 636 across VPN gateways. 638 5.1 Preservation of Existing VPN Infrastructure 640 o The solution MUST work with currently deployed VPN gateways. This 641 is the whole raison d'etre of this investigation: Finding a way 642 to deploy Mobile-IP in cases where a VPN solution is already in 643 place. 645 5.2 Software Upgrades to Existing VPN Client and Gateways 647 o The solution SHOULD minimize changes to existing VPN client/ 648 gateway software. 650 5.3 IPsec Protocol 652 o The solution SHOULD NOT require any changes to existing IPsec or 653 key exchange standard protocols implemented by VPN gateways. 654 o The solution SHOULD NOT require that the VPN gateway or the VPN 655 client implement any new protocols in addition to the existing 656 standard protocols. 658 5.4 Multi-Vendor Interoperability 660 o The solution MUST provide multi-vendor interoperability, where 661 MIPv4 mobility agents, mobility clients (MN), VPN server, and VPN 662 client solutions may come from four different vendors. This is 663 typical for medium and large enterprises which purchase and deploy 664 best-of-breed multi-vendor solutions for IP routing, VPNs, 665 firewalls etc. 667 5.5 MIPv4 Protocol 669 o The solution MUST adhere to MIPv4 protocol [RFC3344]. That is, 670 the solution MUST NOT impose any changes that violates MIPv4 671 protocol. 672 o The solution MAY introduce new extensions to MIPv4 nodes per 673 guidelines specified in the MIPv4 protocol [RFC3344]. However, it 674 is highly desirable to avoid any changes to MIPv4 mobility agents 675 such as the FA and HA in order to overcome barriers to deployment. 676 o The solution MAY require more than one instance of MIPv4 running 677 in parallel (multiple encapsulation). 679 5.6 Handoff Overhead 681 o It is imperative to keep the key management overhead down to a 682 minimum, in order to support fast handoffs across IP subnets. 683 Hence, the solution MUST propose a mechanism to avoid or minimize 684 IPsec tunnel SA renegotiation and IKE renegotiation as the MN 685 changes its current point of network attachment. 687 5.7 Scalability, Availability, Reliability, and Performance 689 o The solution complexity MUST increase at most linearly with the 690 number of MNs registered and accessing resources inside the 691 Intranet. 692 o The solution MAY introduce additional header or tunnelling 693 overhead if needed. 695 5.8 Functional Entities 697 o The solution MAY introduce new MIPv4 compliant functional 698 entities. 700 5.9 Implications of Intervening NAT Gateways 702 o The solution MUST be able to work with the existing MIPv4 and 703 IPsec NAT traversal solutions [RFC3519][RFC3715][IKE-NAT]. 705 5.10 Security Requirements 707 o The solution MUST provide security which is not inferior to what 708 is already provided to existing "nomadic computing" remote access 709 users, i.e. for confidentiality, authentication, message 710 integrity, protection against replay attacks and related security 711 services. 713 6. Security Considerations 715 This document describes an existing problem and proposes guidelines 716 for possible solutions; as such its security implications are 717 indirect, through the guidelines it proposes for the solutions. 718 Section 5.10 gives the relevant security requirements. 720 7. Acknowledgements 722 The authors who contributed text to this document were in no 723 particular order: Farid Adrangi, Milind Kulkarni, Gopal Dommety, Eli 724 Gelasco, Qiang Zhang, Sami Vaarala, Dorothy Gellert, Nitsan Baider 725 and Henrik Levkowetz. 727 The authors would like to thank other contributors, especially 728 Prakash Iyer, Mike Andrews, Ranjit Narjala, Joe Lau, Kent Leung, 729 Alpesh Patel, Phil Roberts, Hans Sjostrand, Serge Tessier, Antti 730 Nuopponen, Alan O'neill, Gaetan Feige, Brijesh Kumar for their 731 continuous feedback and helping us improve this draft. 733 8. References 735 8.1 Normative References 737 [RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, 738 August 2002. 740 8.2 Informative References 742 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G. and 743 E. Lear, "Address Allocation for Private Internets", BCP 744 5, RFC 1918, February 1996. 746 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 747 Requirement Levels", BCP 14, RFC 2119, March 1997. 749 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 750 2131, March 1997. 752 [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the 753 Internet Protocol", RFC 2401, November 1998. 755 [RFC3519] Levkowetz, H. and S. Vaarala, "Mobile IP Traversal of 756 Network Address Translation (NAT) Devices", RFC 3519, May 757 2003. 759 [RFC3715] Aboba, B. and W. Dixon, "IPsec-Network Address Translation 760 (NAT) Compatibility Requirements", RFC 3715, March 2004. 762 [IKE-NAT] Kivinen, T., "Negotiation of NAT-Traversal in the IKE", 763 draft-ietf-ipsec-nat-t-ike-08 (work in progress), February 764 2004. 766 Authors' Addresses 768 Farid Adrangi 769 Intel Corporation 770 2111 N.E. 25th Avenue 771 Hillsboro OR 772 USA 774 Phone: +1 503-712-1791 775 EMail: farid.adrangi@intel.com 777 Henrik Levkowetz 778 Torsgatan 71 779 Stockholm S-113 37 780 SWEDEN 782 Phone: +46 7 08 32 16 08 783 EMail: henrik@levkowetz.com 785 Intellectual Property Statement 787 The IETF takes no position regarding the validity or scope of any 788 Intellectual Property Rights or other rights that might be claimed to 789 pertain to the implementation or use of the technology described in 790 this document or the extent to which any license under such rights 791 might or might not be available; nor does it represent that it has 792 made any independent effort to identify any such rights. Information 793 on the procedures with respect to rights in RFC documents can be 794 found in BCP 78 and BCP 79. 796 Copies of IPR disclosures made to the IETF Secretariat and any 797 assurances of licenses to be made available, or the result of an 798 attempt made to obtain a general license or permission for the use of 799 such proprietary rights by implementers or users of this 800 specification can be obtained from the IETF on-line IPR repository at 801 http://www.ietf.org/ipr. 803 The IETF invites any interested party to bring to its attention any 804 copyrights, patents or patent applications, or other proprietary 805 rights that may cover technology that may be required to implement 806 this standard. Please address the information to the IETF at 807 ietf-ipr@ietf.org. 809 Disclaimer of Validity 811 This document and the information contained herein are provided on an 812 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 813 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 814 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 815 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 816 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 817 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 819 Copyright Statement 821 Copyright (C) The Internet Society (2004). This document is subject 822 to the rights, licenses and restrictions contained in BCP 78, and 823 except as set forth therein, the authors retain all their rights. 825 Acknowledgment 827 Funding for the RFC Editor function is currently provided by the 828 Internet Society.