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