Internet Engineering Task Force Farid Adrangi INTERNET DRAFT Prakash Iyer Category: Informational Intel Corp. Kent Leung Milind Kulkarni Alpesh Patel Cisco Systems Qiang Zhang Liqwid Networks Joe Lau Hewlett Packard Corp. Date: July 29, 2002 Problem Statement and Requirements for Mobile IPv4 Traversal Across IPsec-based 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). Expires January 2003 [Page 1] Internet Draft draft-ietf-mobileip-vpn-problem-statement-Req-00 July 2002 Abstract 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 Virtual Private Network (VPN) technology is increasing. This implies that Mobile IP and VPN technologies have to coexist and co-function in order to provide mobility and security to the enterprise mobile users. The goal of this draft is threefold. The first is to describe possible deployment scenarios for Mobile IP and VPN in enterprise and operator environments. The second is to identify example usage scenarios for enterprise users roaming outside the ôhomeö network (e.g., corporate Intranet), and articulate the problems resulting from Mobile IP and VPN coexistence. The third is to specify a set of framework requirements to evaluate proposed solutions, supporting multi- vendor seamless IPv4 mobility across IPsec-based VPN Gateways. Hereafter, a ôVPNö term in this draft refers to an IPsec-based VPN Gateway. Table of Contents 1. Introduction....................................................3 1.2. Acronyms......................................................3 1.3. Terminology...................................................3 2. Mobile IP and VPN Deployment Scenarios..........................3 2.1. VPN Gateway in DMZ and MIP HA(s) Inside the Intranet..........4 2.2. VPN Gateway and MIP HA(s) in DMZ..............................4 2.3. Combined VPN Gateway and MIP HA in DMZ........................4 2.4. VPN Gateway in DMZ And MIP HA(s) Outside the Intranet.........4 3. Roaming Scenarios...............................................4 3.1. Accessing Services Inside the Home Network....................6 3.2. Accessing Services From Outside the Home Network..............6 3.2.1. Operational Configurations................................6 3.2.1.1. MN registers with its HA using co-located mode............6 3.2.1.2. MN registers with its HA via a FA (non co-located mode)...7 4. Problem Statement...............................................8 4.1. MIPv4 Incompatibilities with IPsec-based VPN Gateways.........8 5. The Solution Requirements.......................................9 5.1. Implications of Intervening NAT Gateways.....................10 5.2. MIPv4 Protocol...............................................10 5.3. Scalability, Availability, Reliability, and Performance......10 5.4. Functional Entities..........................................10 5.5. Fast MIPv4 Handoffs..........................................10 Adrangi, Iyer Expires January 2003 [Page 2] Internet Draft draft-ietf-mobileip-vpn-problem-statement-Req-00 July 2002 5.6. Preservation of Existing VPN Infrastructure..................10 5.7. Preserve Existing DMZ Traversal Policies.....................11 5.8. MIPv4 Registration SA Management.............................11 5.9. Security Implications........................................11 6. MIPv6 Considerations...........................................11 7. Acknowledgements...............................................11 8. Revisions History..............................................11 9. References.....................................................12 1. Introduction The important sections of this draft are organized as follows: Section 2: Describes Mobile IP and VPN deployment scenarios in enterprise and operator environments Section 3: Describes roaming scenarios to motivate the problem statement Section 4: Describes a problem statement for MIPv4 traversal across VPN gateways Section 5: Describes the solution requirements for MIPv4 traversal across VPN gateways 1.2. Acronyms ACL: Access Control List DMZ: DeMilitarized Zone MIPv4: Mobile IP and IPsec client for IPv4 MIPv6: Mobile IP and IPsec client for IPv6 VPN: Virtual Private Network SA: Security Association GW: Gateway 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 1.3. Terminology Home Network/VPN Domain: An intranet protected by a VPN gateway. DMZ: A small network inserted as a "neutral zone" between a company's private network and the outside public network to prevent outside users from getting direct access to the companyÆs private network 2. Mobile IP and VPN Deployment Scenarios Adrangi, Iyer Expires January 2003 [Page 3] Internet Draft draft-ietf-mobileip-vpn-problem-statement-Req-00 July 2002 This section describes possible deployment scenarios for Mobile IP and VPN in enterprise and operator environments. In all scenarios, Mobile IP and VPN have to coexist in order to provide mobility and security to the mobile users roaming outside the Intranet. Here, the term ôIntranetö refers to a private network protected by a VPN gateway. The following sub-sections introduce four representative combinations of MIP HA and VPN placement. 2.1. VPN Gateway in DMZ and MIP HA(s) Inside the Intranet This can be considered a typical deployment scenario in enterprise environments with a large and growing number of mobile users. MN ---Foreign Network---Internet--FWùVPN--FWù-Intranet--- HA 2.2. VPN Gateway and MIP HA(s) in DMZ The MIP HA runs in parallel with the VPN Gateway, and it serves mobile users roaming both inside and outside the Intranet. This type of deployment is more suitable for small or medium size Intranets with a limited number of mobile users. MN ---Foreign Network---InternetùFW----VPN---FW---Intranet | | |--HA--| 2.3. Combined VPN Gateway and MIP HA in DMZ This is similar to the deployment scenario described in section 2.2, with the exception that the VPN gateway and HA are running on the same physical machine. MN ---Foreign Network---InternetùFW----VPN/HA---FW---Intranet 2.4. VPN Gateway in DMZ And MIP HA(s) Outside the Intranet This deployment scenario differs from ones previously mentioned as the MIP HA(s) are deployed outside the Intranet (e.g., in an operator environment). MN ---Foreign Network--HA---Internetù-FW--VPNGW---FW---Intranet For the remainder of this draft, we will only consider section 2.1 deployment scenario. This is because, section 2.2, 2.3, and 2.4 deployment scenarios do not introduce any problems resulting from MIP and VPN coexistence. 3. Roaming Scenarios Adrangi, Iyer Expires January 2003 [Page 4] Internet Draft draft-ietf-mobileip-vpn-problem-statement-Req-00 July 2002 This section describes roaming scenarios corresponding to section 2.1 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 3.0a. +---------+ +------+ +---------------------------+ | | | | |Home network / VPN Domain | | | |IPsec-| | +------+ +------+ +------+| |Internet |<----->|based |<->| | HAs | | FAs | | MNs || | | | VPN | | |(1..n)| |(1..n)| |(1..n)|| | | | GW | | +------+ +------+ +------+| | | +------| | | +---------+ +---------------------------+ Figure 3.0a û Home Network protected by a VPN Gateway The home network, depicted in Figure 3.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 3.0b. +---------+ +------+ +---------------------------+ | | | | |Home network / VPN Domain | | | |IPsec-| | +------+ +------+ +------+| |Internet |<----->|based |<->| | HAs | | FAs | | MNs || | | | VPN | | |(1..n)| |(1..n)| |(1..n)|| | | |-->| GW | | +------+ +------+ +------+| | | | +------| | | +---------+ | +---------------------------+ | +-----------------+ | 802.11 Wireless | | Network | +-----------------+ Figure 3.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. Adrangi, Iyer Expires January 2003 [Page 5] Internet Draft draft-ietf-mobileip-vpn-problem-statement-Req-00 July 2002 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 (MN) 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). 3.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. 3.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 network as he roams from one network link to another in the visited network. Dr. Joe has to perform both Mobile IP and IPsec functions in order to establish a secure connection to his home network while maintaining his existing transport connections and constant reachability. This means that an IPsec tunnel MUST be established between the MN and the VPN gateway, to allow secure access to the home network. And, a MIP tunnel MUST be established between the MN and its HA through a successful MIP registration. The different MIP registration modes of the MN are described in sections below. 3.2.1. Operational Configurations 3.2.1.1. MN registers with its HA using co-located mode This section illustrates a scenario where Dr. Joe registers with its HA using co-located mode. The IPsec tunnel end-points are MN and the VPN gateway as depicted in the figure below. Adrangi, Iyer Expires January 2003 [Page 6] Internet Draft draft-ietf-mobileip-vpn-problem-statement-Req-00 July 2002 +---------+ +------+ +---------------------------+ | +-----+ | | | |Home network / VPN Domain | | | |-----------|IPsec-| | +------+ +------+ +------+| | | MN | | |based |<->| | HAs | | FAs | | MNs || | | |-----------| VPN | | |(1..n)| |(1..n)| |(1..n)|| | +-----+ | ^ | GW | | +------+ +------+ +------+| | Multi- | | +------+ | | |Subnetted| | +---------------------------+ | Hot Spot| IPsec Tunnel +---------+ Figure 3.2a. 3.2.1.2. MN registers with its HA via a FA (non co-located mode) This section describes a scenario where Dr. Joe registers with its HA using a FA care-of address. And, 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, or a VPN-to-VPN security scheme exists between a VPN GW located at the edge of the foreign network and the IPSec-based VPN at the edge of the home network. 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 3.2b shows the MN in a trusted FA region, where there is only an IPsec tunnel between the FA and the home VPN gateway. +---------+ +------+ +---------------------------+ | +-----+ | | | |Home network / VPN Domain | | | |-----------|IPsec-| | +------+ +------+ +------+| | | FA | | |based |<->| | HAs | | FAs | | MNs || | | |-----------| VPN | | |(1..n)| |(1..n)| |(1..n)|| | +-----+ | ^ | GW | | +------+ +------+ +------+| | | | +------+ | | | +-----+ | | +---------------------------+ | | MN | | IPsec Tunnel | +-----+ | | Multi- | |Subnetted| | Hot Spot| +---------+ Figure 3.2b - the MN in trusted FA region Adrangi, Iyer Expires January 2003 [Page 7] Internet Draft draft-ietf-mobileip-vpn-problem-statement-Req-00 July 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 3.2c. +---------+ | +-----+ | +------+ +---------------------------+ | | FA | | | | |Home network / VPN Domain | | | ----------------|IPsec-| | +------+ +------+ +------+| | | | --------------|based |<->| | HAs | | FAs | | MNs || | | | | | | | VPN | | |(1..n)| |(1..n)| |(1..n)|| | +-|-|-+ | ^ | GW | | +------+ +------+ +------+| | | | | | +------+ | | | +-|-|-+ | | +---------------------------+ | | MN | | IPsec Tunnel | +-----+ | | Multi- | |Subnetted| | Hot Spot| +---------+ Figure 3.2c - the MN in non-trusted FA region 4. Problem Statement This section describes MIPv4 incompatibilities with IPsec-based VPN gateways, in the context of the roaming scenarios outlined in section 3. 4.1. MIPv4 Incompatibilities with IPsec-based 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. This is because the MN cannot reach its HA (inside the private protected network) directly from outside. Figure 4.1a and 4.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 MN-CoA HA [=========] MIP tunnel Figure 4.1a û Shows IPsec and MIP Tunnel end-points in non co-located mode Adrangi, Iyer Expires January 2003 [Page 8] Internet Draft draft-ietf-mobileip-vpn-problem-statement-Req-00 July 2002 MN [(========================) VPN ===========] HA MN-CoA VPN-E-Addr (=============) IPsec ESP Tunnel MN-CoA HA [=============] MIP Tunnel Figure 4.1a û Shows IPsec and MIP Tunnel end-points in co-located mode This implies that the MIPv4 traffic from the MN to a node inside the home network is forced to run inside an IPsec tunnel, and hence 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. This is because the MIPv4 headers (that the FA can interpret) will be encrypted and protected by IPSec. For example, the following shows the MNÆs registration packet arrived at FA, which cannot be decrypted by the FA. +------------------------------------------------------------+ |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 the mobile node connecting to the home network is forced to establish an IPsec tunnel SA to the VPN gateway first. And, this does NOT mean that this draft is suggesting an ôIPsec over MIPö solution. 5. The Solution Requirements Adrangi, Iyer Expires January 2003 [Page 9] Internet Draft draft-ietf-mobileip-vpn-problem-statement-Req-00 July 2002 This section describes the requirements that are intended to establish a framework where in a solution can be developed to support MIPv4 traversal across VPN gateways. 5.1. Implications of Intervening NAT Gateways The solution MUST be able to leverage the resolution for MIPv4 traversal across NAT gateways provided in [11] to support MIPv4 traversal across ôNAT and VPNö scenario, in which MN has to traverse one or more NAT gateway(s) followed by a VPN gateway in the path to its final destination. 5.2. MIPv4 Protocol - The solution MUST adhere to MIPv4 protocol [1]. That is, the solution MUST NOT impose any changes that violates MIPv4 protocol [1]. - The solution MAY introduce new extensions to MIPv4 nodes per guidelines specified in the MIPv4 protocol [1]. - The solution MAY introduce new extensions to MIPv4 nodes per guidelines specified in the MIPv4 protocol [1]. However, it is highly desirable to avoid any changes to MIPv4 mobility agents such as the FA and HA in order to overcome barriers to deployment. 5.3. Scalability, Availability, Reliability, and Performance 5.3.1. The solution complexity MUST increase at most linearly with the number of MNs registered, and need to communicate with their home network protected behind a VPN gateway. 5.3.2. The solution MAY introduce additional header or tunneling overhead if needed. However, the additional headers MUST be reviewed by the design team. 5.4. Functional Entities The solution MAY introduce a MIPv4 compliant functional entity that helps MIPv4 traversal across VPN or the ôNAT and VPNö gateways. 5.5. Fast MIPv4 Handoffs It is imperative to keep the key management overhead down to a minimum, in order to support fast handoffs across IP subnets. Hence, the solution MUST propose a mechanism whereby the IPsec tunnel SA need not to be renegotiated as the MN changes its current point of network attachment. 5.6. Preservation of Existing VPN Infrastructure Adrangi, Iyer Expires January 2003 [Page 10] Internet Draft draft-ietf-mobileip-vpn-problem-statement-Req-00 July 2002 This implies the following: - The solution MUST preserve the investment in existing VPN gateways - The solution MAY require software upgrades to VPN gateways to explicitly support MIPv4 users - The solution MUST preserves VPN security requirements that are not inferior to what is already provided to existing "nomadic computing" remote access users, i.e. for confidentiality, primary and secondary authentication, message integrity, protection against replay attacks and related security services. 5.7. Preserve Existing DMZ Traversal Policies The solution MUST be compatible with existing DMZ policies with respect to ACLs. 5.8. MIPv4 Registration SA Management The solution MUST provide a mechanism for MIPv4 registration SA management if needed. 5.9. Security Implications The solution MUST NOT introduce any new vulnerabilities to the MIPv4 protocol as specified in related RFCs. 6. 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) may beapplicable to MIPv6. 7. Acknowledgements The authors would like to thank MIP/VPN design team, especially Phil Roberts, Hans Sjostrand, Henrik Levkowetz, Sami Serge Tessier, Gopal Dommety, Sami Varaala, Antti Nueppoen, Alan O'neill, Gaetan Feige for their feedback and helping us improve this draft. 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 Adrangi, Iyer Expires January 2003 [Page 11] Internet Draft draft-ietf-mobileip-vpn-problem-statement-Req-00 July 2002 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 3) Thrid version August 2002 th + Make changes as per our Bar BoF at 54 IETF + Added solution requirements 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 [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, [11] Mobile IP NAT/NAPT Traversal using UDP Tunneling, 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 Adrangi, Iyer Expires January 2003 [Page 12] Internet Draft draft-ietf-mobileip-vpn-problem-statement-Req-00 July 2002 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@liqwidnet.com Phone: 703 8641327 Liqwid networks, 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 January 2003 [Page 13]