idnits 2.17.1 draft-ietf-mobileip-vpn-problem-statement-00.txt: -(60): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(92): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(344): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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: ---------------------------------------------------------------------------- == There are 17 instances of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 38 has weird spacing: '... The list ...' == Line 45 has weird spacing: '... check the ...' == Line 89 has weird spacing: '... These deplo...' == Line 90 has weird spacing: '...cations and ...' == Line 100 has weird spacing: '...escribe roami...' == (7 more instances...) == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 2002) is 8068 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: '2' is defined on line 389, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 390, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 391, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 392, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 394, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 397, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 399, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 401, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3220 (ref. '1') (Obsoleted by RFC 3344) Summary: 6 errors (**), 0 flaws (~~), 16 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Farid Adrangi 2 INTERNET DRAFT Prakash Iyer 3 Category: Informational Intel Corp. 5 Kent Leung 6 Milind Kulkarni 7 Alpesh Patel 8 Cisco Systems 10 Qiang Zhang 11 Liqwidnet Inc. 13 Joe Lau 14 Hewlett Packard 15 Corp. 17 18 Date: March 2002 20 Problem Statement for Mobile IPv4 Traversal Across VPN Gateways 22 Status of this Memo 24 This document is an Internet-Draft and is in full conformance 25 with all provisions of Section 10 of RFC2026. 27 Internet-Drafts are working documents of the Internet 28 Engineering Task Force (IETF), its areas, and its working 29 groups. Note that other groups may also distribute working 30 documents as Internet-Drafts. 32 Internet-Drafts are draft documents valid for a maximum of six 33 months and may be updated, replaced, or obsoleted by other 34 documents at any time. It is inappropriate to use Internet- 35 Drafts as reference material or to cite them other than as "work 36 in progress." 38 The list of current Internet-Drafts can be accessed at 39 http://www.ietf.org/ietf/1id-abstracts.txt 41 The list of Internet-Draft Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html. 44 To view the entire list of current Internet-Drafts, please 45 check the "1id-abstracts.txt" listing contained in the 46 Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), 47 ftp.nordu.net (Northern Europe), ftp.nis.garr.it (Southern 48 Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East 49 Coast), or ftp.isi.edu (US West Coast). 51 Abstract 52 Mobile IP [1] agents are being deployed in enterprise networks, 53 to enable mobile users with network mobility across wired and 54 wireless LANs while roaming inside the enterprise firewall. 55 With the growing deployment of multi-subnetted IEEE 802.11 56 networks (referred as hot spots) in public places such as 57 hotels, airports, and convention centers, and wireless WAN data 58 networks such as GPRS, the need for enabling mobile users to 59 maintain their transport connections and constant reachability 60 while connecting back to their target �home� networks protected 61 by VPNs is increasing. This draft identifies example usage 62 scenarios for enterprise users roaming outside the firewall, 63 and defines a problem statement based on the scenarios. 65 Table of Contents 67 1. Introduction....................................................2 68 2. Terminology.....................................................3 69 3. Acronyms........................................................3 70 4.0. Roaming Scenarios.............................................3 71 4.1. Accessing Services Inside the Home Network....................4 72 4.2. Accessing Services From Outside the Home Network..............4 73 5.1. MN registers with its HA using co-located mode................5 74 5.2. MN registers with its HA via a FA (non co-located mode).......5 75 6. Problem Statement...............................................6 76 6.1. MIPv4 Incompatibilities with VPN Gateways.....................7 77 7. MIPv6 Considerations............................................8 78 8. Revisions History...............................................8 79 9. References......................................................8 81 1. Introduction 83 Multi-subnetted IEEE 802.11 WLAN networks are being widely 84 deployed in Enterprise Intranets - in many cases requiring a 85 VPN tunnel to connect back and access Intranet resources, and 86 public areas such as airports, coffee shops, convention centers 87 and shopping malls. Wireless WAN networks such as those based 88 on GPRS and eventually EDGE and UMTS are also starting to see 89 deployment. These deployments are paving the way for 90 applications and usage scenarios requiring TCP/IP session 91 persistence and constant reachability while connecting back to 92 a secured (VPN protected), target �home� network. This in turn 93 drives the need for a mobile VPN solution that is multi-vendor 94 interoperable, providing seamless access with persistent VPN 95 sessions. This draft identifies example usage scenarios, and 96 defines a problem statement based on the scenarios. 98 The important sections of this draft are organized as follows: 100 Section 4: Describe roaming scenarios to motivate the 101 problem statement 103 Section 5: Describes a problem statement for MIPv4 104 traversal across VPN gateways. 106 2. Terminology 108 3. Acronyms 109 ACL: Access Control List 110 MIPv4: Mobile IP for IPv4 111 MIPv6: Mobile IP for IPv6 112 VPN: Virtual Private Network 114 MN-HoA: Permanent home address of the MN 115 MN-CoA: Co-located care-of address of the MN 116 VPN_E_Addr: VPN Gateway External IP Address 117 WLAN: IEEE 802.11 (a/b/g) Wireless Local Area Network 119 4.0. Roaming Scenarios 121 This section describes roaming scenarios, wherein a mobile user 122 roaming outside the firewall needs to connect to his/her 123 �target� home network protected by a VPN. The scenarios are 124 constructed based on a multi-subnetted MIPv4 enabled Intranet 125 (hereafter, referred by Home Network or VPN domain) protected 126 by an IPsec-based VPN gateway as depicted in Figure 4.0a. 128 +---------+ +------+ +---------------------------+ 129 | | | | |Home network / VPN Domain | 130 | | |IPsec-| | +----+ +-----+ +----+ | 131 |Internet | |based |<->| |HA-1 | HA-2| |HA-n| | 132 | | | | | +----+ +-----+ +----+ | 133 | | | VPN | | | 134 +---------+ +------+ | +----+ +-----+ +----+ | 135 | |FA-1| | FA-2| |FA-n| | 136 | +----+ +-----+ +----+ | 137 | | 138 | +----+ +-----+ +-----+ | 139 | |MN-1| | MN-2| | MN-n| | 140 | +----+ +-----+ +-----+ | 141 +---------------------------+ 143 Figure 4.0a � Home Network protected by a VPN Gateway 145 The home network, depicted in Figure 4.0a, may include both 146 wired (IEEE 802.3) and IEEE 802.11 wireless LAN deployments. 147 However, it is also possible to see IEEE 802.11 deployments 148 outside the home network due to the perceived lack of 802.1x 149 security, as depicted in Figure 4.0b. 151 +---------+ +------+ +---------------------------+ 152 | | | | |Home network / VPN Domain | 153 | | |IPsec-| | +----+ +-----+ +----+ | 154 |Internet | |-->|based |<->| |HA-1| | HA-2| |HA-n| | 155 | | | | | | +----+ +-----+ +----+ | 156 | | | | VPN | | | 157 +---------+ | +------+ | +----+ +-----+ +----+ | 158 | | |FA-1| | FA-2| |FA-n| | 159 | | +----+ +-----+ +----+ | 160 +-----------------+ | | 161 | | | +----+ +-----+ +-----+ | 162 | 802.11 Wireless | | |MN-1| | MN-2| | MN-n| | 163 | Network | | +----+ +-----+ +-----+ | 164 | | +---------------------------+ 165 +-----------------+ 167 Figure 4.0b � IEEE 802.11 Wireless deployment outside the home 168 network 170 It is important to note that MIPv4 mobility agents inside the 171 home network are likely to be deployed in existing routers from 172 vendor X while VPN client/server solutions may come from vendor 173 Y and mobility clients (MN) may come from yet another vendor. 174 This is very typical as medium and large Enterprises purchase 175 and deploy best-of-breed multi-vendor solutions for IP routing, 176 VPNs, firewalls etc. 178 To help describe scenarios in the following sections, we have 179 used the aid of an imaginary mobile user, called Dr. Joe. 181 Dr. Joe is a chief surgeon in a hospital, and always on the 182 move. He leverages his wireless MIPv4 enabled hand-held device 183 to access his patient�s records, communicate with his 184 colleagues and staff, and stay reachable in case of any 185 emergencies. For clarity, we assume that Dr. Joe�s hospital 186 employs a network similar to the one showed in Figure 4.0a 187 (MIPv4 enabled network protected by a VPN, and includes both 188 wired and IEEE 802.11 wireless deployments). 190 4.1. Accessing Services Inside the Home Network 192 Dr. Joe�s needs for constant reachablity and maintaining his 193 current transport connections as he roams from one network link 194 to another are met by standard MIPv4 [1] deployment inside the 195 home network. 197 4.2. Accessing Services From Outside the Home Network 199 Dr. Joe frequently visits other clinics and hospitals, in which 200 a multi-subnetted IEEE 802.11 hot spot network is utilized to 201 provide Internet access for visitors. Dr. Joe leverages the 202 hot spot network to connect to his home network, and he would 203 also like to maintain his transport connections to the home 204 network as he roams from one network link to another in the 205 visited network. 207 Dr. Joe needs to establish an IPsec tunnel to the VPN gateway 208 first so that he can register with the home agent while roaming 209 outside the home network. This implies that the MIPv4 traffic 210 destined to the home network has to run inside an IPsec tunnel. 212 The different registration modes of the MN are described in 213 sections below. 215 5.0. Operational Configurations 217 5.1. MN registers with its HA using co-located mode 219 +---------+ +------+ +---------------------------+ 220 |Internet | | | |Home network /VPN Domain | 221 | |--------------|IPsec-| | +----+ +-----+ +----+ | 222 | | |-----------|based |<->| |HA-1 | HA-2| |HA-n| | 223 +--|--|---+ |VPN | | +----+ +-----+ +----+ | 224 | | +------+ | | 225 | | | +----+ +-----+ +----+ | 226 | |<-- IPsec Tunnel | |FA-1| | FA-2| |FA-n| | 227 | | | +----+ +-----+ +----+ | 228 | | | | 229 +---|--|---+ | +----+ +-----+ +-----+ | 230 | | | | | |MN-1| |MN-2 | |MN-n | | 231 | +-|--|-+ | | +----+ +-----+ +-----+ | 232 | | MN | | | | 233 | +------+ | +---------------------------+ 234 | Multi- | 235 | Subnetted| 236 | Hot Spot | 237 | | 238 +----------+ 239 Figure 5.1. 241 5.2. MN registers with its HA via a FA (non co-located mode) 243 There are 2 cases to consider. 244 Case 1: 245 The FA is trusted, i.e. an SA has been established a priori 246 between the FA and the home VPN gateway. In this case, the 247 IPsec tunnel end-points are the FA and home VPN gateway. 248 Furthermore, it is also possible for the MN in a trusted FA 249 region to have end-to-end security with its home VPN gateway. 250 This implies that there will be two concurrent IPsec tunnels, 251 one between the FA and home VPN gateway, and the other between 252 the MN and its home VPN gateway. Figure 5.2a shows the MN in a 253 trusted FA region, where there is only an IPsec tunnel between 254 the FA and the home VPN gateway. 256 Case2: 257 In a non-trusted FA region, i.e. where there is no SA between 258 the FA and the home VPN gateway, there will always be a single 259 IPsec tunnel established between the MN and its home VPN 260 gateway, as depicted in Figure 5.2b. 262 +---------+ +------+ +---------------------------+ 263 |Internet | | | |Home network /VPN Domain | 264 | |--------------|IPsec-| | +----+ +-----+ +----+ | 265 | | ------------|based |<->| |HA-1 | HA-2| |HA-n| | 266 +--|--|---+ |VPN | | +----+ +-----+ +----+ | 267 | | +------+ | | 268 +--|--|----+ | +----+ +-----+ +----+ | 269 | +|--|+ | | |FA-1| | FA-2| |FA-n| | 270 | | FA | | | +----+ +-----+ +----+ | 271 | +----+ | | | 272 | | | +----+ +-----+ +-----+ | 273 | +----+ | | |MN-1| |MN-2 | |MN-n | | 274 | |MN | | | +----+ +-----+ +-----+ | 275 | +----+ | | | 276 | Multi- | +---------------------------+ 277 | Subnetted| 278 | Hot Spot | 279 +----------+ 281 Figure 5.2a - the MN in trusted FA region 283 +---------+ +------+ +---------------------------+ 284 |Internet | | | |Home network /VPN Domain | 285 | |--------------|IPsec-| | +----+ +-----+ +----+ | 286 | | ------------|based |<->| |HA-1 | HA-2| |HA-n| | 287 +--|--|---+ |VPN | | +----+ +-----+ +----+ | 288 | | +------+ | | 289 +--|--|----+ | +----+ +-----+ +----+ | 290 | +|--|+ | | |FA-1| | FA-2| |FA-n| | 291 | ||FA|| | | +----+ +-----+ +----+ | 292 | +|--|+ | | | 293 | | |<------- IPsec Tunnel | +----+ +-----+ +-----+ | 294 | +|--|+ | | |MN-1| |MN-2 | |MN-n | | 295 | |MN | | | +----+ +-----+ +-----+ | 296 | +----+ | | | 297 | Multi- | +---------------------------+ 298 | Subnetted| 299 | Hot Spot | 300 +----------+ 302 Figure 5.2b - the MN in non-trusted FA region 304 6. Problem Statement 305 This section describes MIPv4 incompatibilities with IPsec-based 306 VPN gateways, in the context of the roaming scenarios outlined 307 in section 4. 309 6.1. MIPv4 Incompatibilities with VPN Gateways 311 The MN roaming outside the home network has to establish an 312 IPsec tunnel to its home VPN gateway first, in order to be able 313 to register with its home agent. Figure 6.1a and 6.1b show the 314 tunnel end-points in non co-located and co-located modes 315 respectively. 317 MN (========= FA ===========) VPN ------------ HA 319 MN-HoA VPN-E-Addr 320 (==========================) 321 IPsec ESP Tunnel 323 Figure 6.1a � Shows IPsec Tunnel end-points, MN Home Address 324 and VPN External IP Address, in non co-located 325 mode 327 MN (========================) VPN --------------- HA 329 MN-CoA VPN-E-Addr 330 (=========================) 331 IPSec ESP Tunnel 333 Figure 6.1b � Shows IPsec tunnel endpoints, MN-CoA and the VPN 334 External IP address, in co-located mode 336 This implies that the MIPv4 traffic has to run inside IPsec 337 tunnel, and will not be in the clear. This leads to the 338 following problems: 340 Problem 1: In non co-located mode, this implies that the FA 341 (which is likely in a different administrative domain) cannot 342 decrypt MIPv4 packets between the MN and the VPN gateway, and 343 will consequently be not able to relay the MIPv4 packets. For 344 example, the following shows the MN�s registration packet 345 arrived at FA, which cannot be decrypted by the FA. 347 +------------------------------------------------------------+ 348 |Src: MN HoA |ESP |Src: MN HoA|UDP |Reg. |ESP | 349 |Dst: VPN_E_Addr|Header|Dst: HA |Port 434|Request|Trailer | 350 +------------------------------------------------------------+ 352 Problem 2: In co-located mode, the MN obtains a CoA at its 353 point of attachment (via DHCP[7] or some other means). In an 354 end-to-end security model, an IPsec tunnel that terminates at 355 the VPN gateway MUST protect the IP traffic originating at the 356 MN. If the IPsec tunnel is associated with the CoA, the tunnel 357 SA MUST be refreshed after each IP subnet handoff which could 358 have some performance implications on real-time applications. 360 It is important to note that only IPsec tunnel mode is 361 applicable here, as the mobile node connecting to the home 362 network MUST establish an IPsec tunnel SA to the VPN gateway 363 first. 365 7. MIPv6 Considerations 367 MIPv6 does not have a FA component, hence the MN will always 368 run in co-located mode. This implies that only problem #2 369 specified in the problem statement (section 6.1) is applicable 370 to MIPv6. 372 8. Revisions History 374 1) Initial Version March 2002 376 2) Second Version April 2002 377 + Modified the draft based on Phil Roberts comments. 378 1. NAT section was removed 379 2. Solution requirements section was removed 380 3. Tunnel end-point are clearly identified 382 + Made minor organizational changes as Phil Roberts requests 383 1. Make Dr. Joe section more generic 384 2. Split 4.0 section 386 9. References 388 [1] RFC 3220 � IP mobility support for IPv4 389 [2] RFC 3024 � Reverse tunneling for mobile IP 390 [3] RFC 2004 � Minimal encapsulation within IP 391 [4] RFC 1701 � Generic Routing encapsulation 392 [5] RFC 2119 - Key words for use in RFCs to Indicate Requirement 393 Levels 394 [6] RFC 1918 � Address Allocation for Private Internets 395 [7] RFC 2663 - IP Network Address Translator (NAT) Terminology and 396 Considerations 397 [8] RFC 2131 � Dynamic Host Configuration Protocol 399 [9] draft-bpatil-mobileip-sec-guide-01.txt - Requirements / 400 Implementation Guidelines for Mobile IP using IP Security 401 [10] Dynamic Configuration of IPv4 Link-Local Addresses, 402 404 Authors: 406 Farid Adrangi 407 Intel Corporation 408 2111 N.E. 25th Avenue 409 Hillsboro, OR 410 USA 412 Phone: 503-712-1791 413 Email: farid.adrangi@intel.com 415 Prakash Iyer 416 Intel Corporation 417 2111 N.E. 25th Avenue 418 Hillsboro, OR 419 USA 421 Phone: 503-264-1815 422 Email: prakash.iyer@intel.com 424 Kent Leung Email: kleung@cisco.com Phone: 408-526-5030 425 Milind Kulkarni Email: mkulkarn@cisco.com Phone: 408-527-8382 426 Alpesh Patel Email: alpesh@cisco.com Phone: 408-853-9580 428 Cisco Systems 429 170 W. Tasman Drive, 430 San Jose, CA 95134 432 Qiang Zhang Email: qzhang@liqwident.com 433 Phone: 703 8641327 434 Liqwidnet Inc. 436 Joe Lau Email: jlau@cup.hp.com Phone: 408 447-2159 437 Hewlett-Packard Company 438 19420 Homestead Road, MS 4301 439 Cupertino, CA 95014