Internet Engineering Task Force Farid Adrangi INTERNET DRAFT Prakash Iyer Category: Informational Intel Corp. Kent Leung Milind Kulkarni Alpesh Patel Cisco Systems Qiang Zhang Liqwidnet Inc. Joe Lau Hewlett Packard Corp. Date: March 2002 Problem Statement for Mobile IPv4 Traversal Across VPN Gateways Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. To view the entire list of current Internet-Drafts, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). Abstract Expires September 2002. [Page 1] Internet Draft draft-ietf-mobileip-vpn-problem-statement-00 March 2002 Mobile IP [1] agents are being deployed in enterprise networks, to enable mobile users with network mobility across wired and wireless LANs while roaming inside the enterprise firewall. With the growing deployment of multi-subnetted IEEE 802.11 networks (referred as hot spots) in public places such as hotels, airports, and convention centers, and wireless WAN data networks such as GPRS, the need for enabling mobile users to maintain their transport connections and constant reachability while connecting back to their target ôhomeö networks protected by VPNs is increasing. This draft identifies example usage scenarios for enterprise users roaming outside the firewall, and defines a problem statement based on the scenarios. Table of Contents 1. Introduction....................................................2 2. Terminology.....................................................3 3. Acronyms........................................................3 4.0. Roaming Scenarios.............................................3 4.1. Accessing Services Inside the Home Network....................4 4.2. Accessing Services From Outside the Home Network..............4 5.1. MN registers with its HA using co-located mode................5 5.2. MN registers with its HA via a FA (non co-located mode).......5 6. Problem Statement...............................................6 6.1. MIPv4 Incompatibilities with VPN Gateways.....................7 7. MIPv6 Considerations............................................8 8. Revisions History...............................................8 9. References......................................................8 1. Introduction Multi-subnetted IEEE 802.11 WLAN networks are being widely deployed in Enterprise Intranets - in many cases requiring a VPN tunnel to connect back and access Intranet resources, and public areas such as airports, coffee shops, convention centers and shopping malls. Wireless WAN networks such as those based on GPRS and eventually EDGE and UMTS are also starting to see deployment. These deployments are paving the way for applications and usage scenarios requiring TCP/IP session persistence and constant reachability while connecting back to a secured (VPN protected), target ôhomeö network. This in turn drives the need for a mobile VPN solution that is multi-vendor interoperable, providing seamless access with persistent VPN sessions. This draft identifies example usage scenarios, and defines a problem statement based on the scenarios. The important sections of this draft are organized as follows: Section 4: Describe roaming scenarios to motivate the problem statement Adrangi, Iyer Expires September 2002 [Page 2] Internet Draft draft-ietf-mobileip-vpn-problem-statement-00 March 2002 Section 5: Describes a problem statement for MIPv4 traversal across VPN gateways. 2. Terminology 3. Acronyms ACL: Access Control List MIPv4: Mobile IP for IPv4 MIPv6: Mobile IP for IPv6 VPN: Virtual Private Network MN-HoA: Permanent home address of the MN MN-CoA: Co-located care-of address of the MN VPN_E_Addr: VPN Gateway External IP Address WLAN: IEEE 802.11 (a/b/g) Wireless Local Area Network 4.0. Roaming Scenarios This section describes roaming scenarios, wherein a mobile user roaming outside the firewall needs to connect to his/her ôtargetö home network protected by a VPN. The scenarios are constructed based on a multi-subnetted MIPv4 enabled Intranet (hereafter, referred by Home Network or VPN domain) protected by an IPsec-based VPN gateway as depicted in Figure 4.0a. +---------+ +------+ +---------------------------+ | | | | |Home network / VPN Domain | | | |IPsec-| | +----+ +-----+ +----+ | |Internet | |based |<->| |HA-1 | HA-2| |HA-n| | | | | | | +----+ +-----+ +----+ | | | | VPN | | | +---------+ +------+ | +----+ +-----+ +----+ | | |FA-1| | FA-2| |FA-n| | | +----+ +-----+ +----+ | | | | +----+ +-----+ +-----+ | | |MN-1| | MN-2| | MN-n| | | +----+ +-----+ +-----+ | +---------------------------+ Figure 4.0a û Home Network protected by a VPN Gateway The home network, depicted in Figure 4.0a, may include both wired (IEEE 802.3) and IEEE 802.11 wireless LAN deployments. However, it is also possible to see IEEE 802.11 deployments outside the home network due to the perceived lack of 802.1x security, as depicted in Figure 4.0b. Adrangi, Iyer Expires September 2002 [Page 3] Internet Draft draft-ietf-mobileip-vpn-problem-statement-00 March 2002 +---------+ +------+ +---------------------------+ | | | | |Home network / VPN Domain | | | |IPsec-| | +----+ +-----+ +----+ | |Internet | |-->|based |<->| |HA-1| | HA-2| |HA-n| | | | | | | | +----+ +-----+ +----+ | | | | | VPN | | | +---------+ | +------+ | +----+ +-----+ +----+ | | | |FA-1| | FA-2| |FA-n| | | | +----+ +-----+ +----+ | +-----------------+ | | | | | +----+ +-----+ +-----+ | | 802.11 Wireless | | |MN-1| | MN-2| | MN-n| | | Network | | +----+ +-----+ +-----+ | | | +---------------------------+ +-----------------+ Figure 4.0b û IEEE 802.11 Wireless deployment outside the home network It is important to note that MIPv4 mobility agents inside the home network are likely to be deployed in existing routers from vendor X while VPN client/server solutions may come from vendor Y and mobility clients (MN) may come from yet another vendor. This is very typical as medium and large Enterprises purchase and deploy best-of-breed multi-vendor solutions for IP routing, VPNs, firewalls etc. To help describe scenarios in the following sections, we have used the aid of an imaginary mobile user, called Dr. Joe. Dr. Joe is a chief surgeon in a hospital, and always on the move. He leverages his wireless MIPv4 enabled hand-held device to access his patientÆs records, communicate with his colleagues and staff, and stay reachable in case of any emergencies. For clarity, we assume that Dr. JoeÆs hospital employs a network similar to the one showed in Figure 4.0a (MIPv4 enabled network protected by a VPN, and includes both wired and IEEE 802.11 wireless deployments). 4.1. Accessing Services Inside the Home Network Dr. JoeÆs needs for constant reachablity and maintaining his current transport connections as he roams from one network link to another are met by standard MIPv4 [1] deployment inside the home network. 4.2. Accessing Services From Outside the Home Network Dr. Joe frequently visits other clinics and hospitals, in which a multi-subnetted IEEE 802.11 hot spot network is utilized to provide Internet access for visitors. Dr. Joe leverages the hot spot network to connect to his home network, and he would also like to maintain his transport connections to the home Adrangi, Iyer Expires September 2002 [Page 4] Internet Draft draft-ietf-mobileip-vpn-problem-statement-00 March 2002 network as he roams from one network link to another in the visited network. Dr. Joe needs to establish an IPsec tunnel to the VPN gateway first so that he can register with the home agent while roaming outside the home network. This implies that the MIPv4 traffic destined to the home network has to run inside an IPsec tunnel. The different registration modes of the MN are described in sections below. 5.0. Operational Configurations 5.1. MN registers with its HA using co-located mode +---------+ +------+ +---------------------------+ |Internet | | | |Home network /VPN Domain | | |--------------|IPsec-| | +----+ +-----+ +----+ | | | |-----------|based |<->| |HA-1 | HA-2| |HA-n| | +--|--|---+ |VPN | | +----+ +-----+ +----+ | | | +------+ | | | | | +----+ +-----+ +----+ | | |<-- IPsec Tunnel | |FA-1| | FA-2| |FA-n| | | | | +----+ +-----+ +----+ | | | | | +---|--|---+ | +----+ +-----+ +-----+ | | | | | | |MN-1| |MN-2 | |MN-n | | | +-|--|-+ | | +----+ +-----+ +-----+ | | | MN | | | | | +------+ | +---------------------------+ | Multi- | | Subnetted| | Hot Spot | | | +----------+ Figure 5.1. 5.2. MN registers with its HA via a FA (non co-located mode) There are 2 cases to consider. Case 1: The FA is trusted, i.e. an SA has been established a priori between the FA and the home VPN gateway. In this case, the IPsec tunnel end-points are the FA and home VPN gateway. Furthermore, it is also possible for the MN in a trusted FA region to have end-to-end security with its home VPN gateway. This implies that there will be two concurrent IPsec tunnels, one between the FA and home VPN gateway, and the other between the MN and its home VPN gateway. Figure 5.2a shows the MN in a trusted FA region, where there is only an IPsec tunnel between the FA and the home VPN gateway. Adrangi, Iyer Expires September 2002 [Page 5] Internet Draft draft-ietf-mobileip-vpn-problem-statement-00 March 2002 Case2: In a non-trusted FA region, i.e. where there is no SA between the FA and the home VPN gateway, there will always be a single IPsec tunnel established between the MN and its home VPN gateway, as depicted in Figure 5.2b. +---------+ +------+ +---------------------------+ |Internet | | | |Home network /VPN Domain | | |--------------|IPsec-| | +----+ +-----+ +----+ | | | ------------|based |<->| |HA-1 | HA-2| |HA-n| | +--|--|---+ |VPN | | +----+ +-----+ +----+ | | | +------+ | | +--|--|----+ | +----+ +-----+ +----+ | | +|--|+ | | |FA-1| | FA-2| |FA-n| | | | FA | | | +----+ +-----+ +----+ | | +----+ | | | | | | +----+ +-----+ +-----+ | | +----+ | | |MN-1| |MN-2 | |MN-n | | | |MN | | | +----+ +-----+ +-----+ | | +----+ | | | | Multi- | +---------------------------+ | Subnetted| | Hot Spot | +----------+ Figure 5.2a - the MN in trusted FA region +---------+ +------+ +---------------------------+ |Internet | | | |Home network /VPN Domain | | |--------------|IPsec-| | +----+ +-----+ +----+ | | | ------------|based |<->| |HA-1 | HA-2| |HA-n| | +--|--|---+ |VPN | | +----+ +-----+ +----+ | | | +------+ | | +--|--|----+ | +----+ +-----+ +----+ | | +|--|+ | | |FA-1| | FA-2| |FA-n| | | ||FA|| | | +----+ +-----+ +----+ | | +|--|+ | | | | | |<------- IPsec Tunnel | +----+ +-----+ +-----+ | | +|--|+ | | |MN-1| |MN-2 | |MN-n | | | |MN | | | +----+ +-----+ +-----+ | | +----+ | | | | Multi- | +---------------------------+ | Subnetted| | Hot Spot | +----------+ Figure 5.2b - the MN in non-trusted FA region 6. Problem Statement Adrangi, Iyer Expires September 2002 [Page 6] Internet Draft draft-ietf-mobileip-vpn-problem-statement-00 March 2002 This section describes MIPv4 incompatibilities with IPsec-based VPN gateways, in the context of the roaming scenarios outlined in section 4. 6.1. MIPv4 Incompatibilities with VPN Gateways The MN roaming outside the home network has to establish an IPsec tunnel to its home VPN gateway first, in order to be able to register with its home agent. Figure 6.1a and 6.1b show the tunnel end-points in non co-located and co-located modes respectively. MN (========= FA ===========) VPN ------------ HA MN-HoA VPN-E-Addr (==========================) IPsec ESP Tunnel Figure 6.1a û Shows IPsec Tunnel end-points, MN Home Address and VPN External IP Address, in non co-located mode MN (========================) VPN --------------- HA MN-CoA VPN-E-Addr (=========================) IPSec ESP Tunnel Figure 6.1b û Shows IPsec tunnel endpoints, MN-CoA and the VPN External IP address, in co-located mode This implies that the MIPv4 traffic has to run inside IPsec tunnel, and will not be in the clear. This leads to the following problems: Problem 1: In non co-located mode, this implies that the FA (which is likely in a different administrative domain) cannot decrypt MIPv4 packets between the MN and the VPN gateway, and will consequently be not able to relay the MIPv4 packets. For example, the following shows the MNÆs registration packet arrived at FA, which cannot be decrypted by the FA. Adrangi, Iyer Expires September 2002 [Page 7] Internet Draft draft-ietf-mobileip-vpn-problem-statement-00 March 2002 +------------------------------------------------------------+ |Src: MN HoA |ESP |Src: MN HoA|UDP |Reg. |ESP | |Dst: VPN_E_Addr|Header|Dst: HA |Port 434|Request|Trailer | +------------------------------------------------------------+ Problem 2: In co-located mode, the MN obtains a CoA at its point of attachment (via DHCP[7] or some other means). In an end-to-end security model, an IPsec tunnel that terminates at the VPN gateway MUST protect the IP traffic originating at the MN. If the IPsec tunnel is associated with the CoA, the tunnel SA MUST be refreshed after each IP subnet handoff which could have some performance implications on real-time applications. It is important to note that only IPsec tunnel mode is applicable here, as the mobile node connecting to the home network MUST establish an IPsec tunnel SA to the VPN gateway first. 7. MIPv6 Considerations MIPv6 does not have a FA component, hence the MN will always run in co-located mode. This implies that only problem #2 specified in the problem statement (section 6.1) is applicable to MIPv6. 8. Revisions History 1) Initial Version March 2002 2) Second Version April 2002 + Modified the draft based on Phil Roberts comments. 1. NAT section was removed 2. Solution requirements section was removed 3. Tunnel end-point are clearly identified + Made minor organizational changes as Phil Roberts requests 1. Make Dr. Joe section more generic 2. Split 4.0 section 9. References [1] RFC 3220 û IP mobility support for IPv4 [2] RFC 3024 û Reverse tunneling for mobile IP [3] RFC 2004 û Minimal encapsulation within IP [4] RFC 1701 û Generic Routing encapsulation [5] RFC 2119 - Key words for use in RFCs to Indicate Requirement Levels [6] RFC 1918 û Address Allocation for Private Internets [7] RFC 2663 - IP Network Address Translator (NAT) Terminology and Considerations [8] RFC 2131 û Dynamic Host Configuration Protocol Adrangi, Iyer Expires September 2002 [Page 8] Internet Draft draft-ietf-mobileip-vpn-problem-statement-00 March 2002 [9] draft-bpatil-mobileip-sec-guide-01.txt - Requirements / Implementation Guidelines for Mobile IP using IP Security [10] Dynamic Configuration of IPv4 Link-Local Addresses, Authors: Farid Adrangi Intel Corporation 2111 N.E. 25th Avenue Hillsboro, OR USA Phone: 503-712-1791 Email: farid.adrangi@intel.com Prakash Iyer Intel Corporation 2111 N.E. 25th Avenue Hillsboro, OR USA Phone: 503-264-1815 Email: prakash.iyer@intel.com Kent Leung Email: kleung@cisco.com Phone: 408-526-5030 Milind Kulkarni Email: mkulkarn@cisco.com Phone: 408-527-8382 Alpesh Patel Email: alpesh@cisco.com Phone: 408-853-9580 Cisco Systems 170 W. Tasman Drive, San Jose, CA 95134 Qiang Zhang Email: qzhang@liqwident.com Phone: 703 8641327 Liqwidnet Inc. Joe Lau Email: jlau@cup.hp.com Phone: 408 447-2159 Hewlett-Packard Company 19420 Homestead Road, MS 4301 Cupertino, CA 95014 Adrangi, Iyer Expires September 2002 [Page 9]