Internet Engineering Task Force Farid Adrangi INTERNET DRAFT Prakash Iyer Category: Informational Intel Corp. <draft-adrangi-mobileip-nat-vpn-problem-stat-req-00> Date: January 2002 Problem Statement and Requirements for Mobile IPv4 Traversal Across VPN or 'NAT and 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 This draft describes the problem statement and specifies the solution requirements for MIPv4 traversal across VPN or 'NAT and VPN' gateways. The 'NAT and VPN' case refers to a network topology in which the MIPv4 traffic has to traverse one or more NAT gateway(s) followed by a VPN gateway in the path to its final destination. Requirements and problems associated with MIPv4 traversal through NAT gateways NOT involving VPNs is outside the scope of this draft. Table of Contents Expires August 2002. [Page 1]
Internet Draft draft-adrangi-mobileip-nat-vpn-problem-stat-req-00 January 2002 1. Introduction....................................................2 2. Terminology.....................................................3 3. Acronyms........................................................3 4.0. Roaming Scenarios.............................................4 4.1. Roaming Inside the Home Network...............................5 4.2. Roaming Outside the Home Network..............................5 4.2.1. Roaming Outside the Home Network in a Routable Address Space (where, FA-assisted routing is not used)...........................6 4.2.2 Roaming Outside the Home Network in Routable Address Space (where, FA-assisted routing is used)...............................6 4.2.3 Roaming Outside the Home Network in a non-Routable Address Space..............................................................7 5. Problem Statement...............................................8 5.1. MIPv4 Incompatibilities with VPN Gateways.....................8 5.2. MIPv4 Incompatibilities with NAT Gateways.....................9 6. The Requirements................................................9 6.1. Implications of Intervening NAT Gateways......................9 6.2. Implications of Cascaded NAT.................................10 6.3. MIPv4 Protocol...............................................10 6.5. Functional Entities..........................................10 6.6. Multi-vendor Interoperability................................10 6.7. Fast MIPv4 Handoffs..........................................10 6.8. Preservation of Existing VPN Infrastructure..................11 6.9. Preserve Existing DMZ Traversal Policies.....................11 6.10 Support For Route Optimization...............................11 6.11 MIPv4 Registration SA Management.............................11 6.12 Security Implications........................................11 7. References.....................................................11 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. Many of these WLAN networks also employ NAT to translate between non-routable and routable IPv4 care-of (point of attachment) addresses. WWAN 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 and through NAT gateways when needed. This draft identifies example usage scenarios, defines a problem statement based on the scenarios and specifies requirements that MUST be met to ensure broad deployment of multi-vendor interoperable solutions. Adrangi, Iyer Expires January 2002 [Page 2]
Internet Draft draft-adrangi-mobileip-nat-vpn-problem-stat-req-00 January 2002 The important sections of this draft are organized as follows: Section 4: Describe roaming scenarios to motivate the problem statement Section 5: Describes a problem statement for MIPv4 traversal across VPN and NAT gateways. Section 6: Specifies the requirements for a solution to support multi-vendor seamless IPv4 mobility across VPN or the 'NAT VPN' gateways. 2. Terminology Traditional NAT: Network Address Translation. "Traditional NAT would allow hosts within a private network to transparently access hosts in the external network, in most cases. In a traditional NAT, sessions are uni-directional, outbound from the private network." ' [RFC2663]. Traditional NAT' are of two types: Basic NAT and NAPT. Basic NAT: "With Basic NAT, a block of external addresses are set aside for translating addresses of hosts in a private domain as they originate sessions to the external domain. For packets outbound from the private network, the source IP address and related fields such as IP, TCP, UDP and ICMP header checksums are translated. For inbound packets, the destination IP address and the checksums as listed above are translated." û [RFC2663] NAPT: Network Address Port Translation. "NAPT extends the notion of translation one step further by also translating transport identifier (e.g., TCP and UDP port numbers, ICMP query identifiers). This allows the transport identifiers of a number of private hosts to be multiplexed into the transport identifiers of a single external address. NAPT allows a set of hosts to share a single external address. Note that NAPT can be combined with Basic NAT so that a pool of external addresses are used in conjunction with port translation." û [RFC2663] 3. Acronyms ACL: Access Control List GRE: Generic Routing Encapsulation MIPv4: Mobile IP for IPv4 MIPv6: Mobile IP for IPv6 VPN: Virtual Private Network Adrangi, Iyer Expires January 2002 [Page 3]
Internet Draft draft-adrangi-mobileip-nat-vpn-problem-stat-req-00 January 2002 MN-Perm: Permanent home address of the MN MN-COA: Co-located care-of address of the MN WLAN: IEEE 802.11 Wireless Local Area Network 4.0. Roaming Scenarios This section describes roaming scenarios, wherein MIPv4 traffic has to traverse VPN or the 'NAT and VPN' gateways. 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 perceived lack of 802.1x security, as depicted in Figure 4.0b. +---------+ +------+ +---------------------------+ | | | | |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 | | +----+ +-----+ +-----+ | | | +---------------------------+ +-----------------+ Adrangi, Iyer Expires January 2002 [Page 4]
Internet Draft draft-adrangi-mobileip-nat-vpn-problem-stat-req-00 January 2002 Figure 4.0b' IEEE 802.11 Wireless deployment outside the home network To help describe scenarios in the following sections, we have used the aid of an imaginary nomadic 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' records, communicate with his colleagues and staff, and stay reachable in case of any emergencies. For clarity, we assume that Dr. Joe' 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. Roaming Inside the Home Network Dr. Joe' needs for constant reachablity and maintaining his current transport connections as he roams from one network link to another are met by standard MIPv4 deployment inside the home network. Please note that NATÆed networks might be seen inside the home network, however, draft-mobileip-nat-traversal-00.txt solves the problem, as the mobile node's home agent will most likely be directly reachable by the mobile node. 4.2. Roaming 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 hot spot network. This implies that the MIPv4 traffic destined to the home network MUST run inside an IPsec tunnel (i.e, MIP/IP/ESP/IP) established between the mobile node and the home networkÆs VPN gateway. Moreover, the IPsecÆed MIPv4 traffic may also have to traverse a NAT gateway or a foreign agent in the path to the VPN gateway. The following sub-sections illustrate these possibilities. Adrangi, Iyer Expires January 2002 [Page 5]
Internet Draft draft-adrangi-mobileip-nat-vpn-problem-stat-req-00 January 2002 4.2.1. Roaming Outside the Home Network in a Routable Address Space (where, FA-assisted routing is not used) +---------+ +------+ +---------------------------+ |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 | | | +----------+ 4.2.2 Roaming Outside the Home Network in Routable Address Space (where, FA-assisted routing is used) There is a notion of trusted FA, where there is a SA established between the FA and home VPN gateway. In this case, 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 pairs of IPsec tunnels, one between the FA and home VPN gateway, and the other between the MN and its home VPN gateway. Figure 4.3.2a shows the MN in a trusted FA region, where there is only an IPsec tunnel between the FA and home VPN gateway. In a non-trusted FA region, where there is no SA established between the FA and home gateway, there will always be a single IPsec tunnel established between the MN and its home VPN gateway, as depicted in Figure 4.3.2b. Adrangi, Iyer Expires January 2002 [Page 6]
Internet Draft draft-adrangi-mobileip-nat-vpn-problem-stat-req-00 January 2002 +---------+ +------+ +---------------------------+ |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 4.3.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 4.3.2b - the MN in non-trusted FA region 4.2.3 Roaming Outside the Home Network in a non-Routable Address Space Note that the MN's home agent is not directly reachable in this case. Therefore, draft-mobileip-nat-traversal-00.txt cannot be directly applied. Furthermore, cascaded NAT gateway Adrangi, Iyer Expires January 2002 [Page 7]
Internet Draft draft-adrangi-mobileip-nat-vpn-problem-stat-req-00 January 2002 deployment is also a possibility, but not shown in the diagram. +---------+ +------+ +---------------------------+ | Internet| | | |Home network /VPN Domain | | ---------------|IPsec-| | +----+ +-----+ +----+ | | | ------------|based |<->| |HA-1 | HA-2| |HA-n| | +--|--|---+ |VPN | | +----+ +-----+ +----+ | | | +------+ | | +--|--|+ | +----+ +-----+ +----+ | | NAT || | |FA-1| | FA-2| |FA-n| | +--|--|+ | +----+ +-----+ +----+ | | |<------ IPsec Tunnel | | +--|--|----+ | +----+ +-----+ +-----+ | | +----+ | | |MN-1| |MN-2 | |MN-n | | | | MN | | | +----+ +-----+ +-----+ | | +----+ | | | | Multi- | +---------------------------+ | Subnetted| | Hot Spot | +----------+ 5. Problem Statement This section describes MIPv4 incompatibilities with IPsec-based VPN and NAT gateways, in the context of the roaming scenarios outlined in section 4. 5.1. MIPv4 Incompatibilities with VPN Gateways There are two problems associated with MIPv4 and VPN incompatibilities. Problem 1: The MN could roam into a foreign subnet with a FA. If the MN were to associate a VPN tunnel with its CoA, the FA (which is likely in a different administrative domain) cannot parse the IPsec tunnel SA and will not be able to setup SAs with the MN's VPN gateway and will consequently be not able to relay MIPv4 packets between the MN and the VPN gateway. ` Problem 2: The MN could roam into a foreign subnet without a FA and obtain a CoA at its point of attachment (via [DHCP] 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. Adrangi, Iyer Expires January 2002 [Page 8]
Internet Draft draft-adrangi-mobileip-nat-vpn-problem-stat-req-00 January 2002 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. 5.2. MIPv4 Incompatibilities with NAT Gateways There are also two problems associated with MIPv4 and NAT incompatibilities: Problem 1: When an MN roams from its 'home' network (which may or may not be in a routable IP address space) protected by a VPN to a foreign network behind a NAT gateway, it acquires a non-routable care-of address (most likely through [DHCP]). The acquired non-routable care-of address is passed to the HA through a registration request. This causes the MN to lose its connectivity to its home network, since the HA will not be able to forward the MN's packets to the non-routable care-of address. Problem 2: Even if we solve the first problem, an intervening NAT gateway in a foreign network will not always be able to demultiplex inbound IP-in-IP reverse tunneled MIPv4 data packets. Because, NAPT gateways will simply not be able to route the inbound IP-in-IP packets, as they rely on IP address and transport identifier to route the packets from routable to non-routable address space or vice a versa. And, in the case of Basic NAT, consider two MNs that are registered with the same Home Agent (HA). The inbound packets destined to the two MNs from the HA will have the same source and destination IP addresses ' making it difficult for the NAT to route the packets inside. The implications on Minimal IP [RFC2004] and GRE encapsulation [RFC1701] modes of MIPv4 are similar to IP-in-IP tunneling. Draft [MIP-NAT] describes a solution to the NAT traversal problem when VPNs are not involved. In this draft, we only discuss NAT traversal requirements where the HA is behind a VPN gateway and hence not directly reachable by the MN. 6. The Requirements 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 or 'NAT and VPN' gateways. 6.1. Implications of Intervening NAT Gateways - The solution MUST work with both Basic NAT and NAPT. Adrangi, Iyer Expires January 2002 [Page 9]
Internet Draft draft-adrangi-mobileip-nat-vpn-problem-stat-req-00 January 2002 - The solution MUST not require any configuration or software changes to exiting NAT gateways. The reason for the above constraints is to not limit the solution to network topologies that employ certain types of NAT gateways and to enable deployment of MIPv4 in networks that have currently deployed non-modifiable NAT gateways. 6.2. Implications of Cascaded NAT Cascaded NAT deployment is seen in some network topologies (case in point, a residential NAT gateway connected to a NATÆed ISP network). Therefore, the solution MUST support cascaded NAT. 6.3. MIPv4 Protocol - The solution MUST be compliant with MIPv4 protocol [RFC 3220]. - The solution MAY introduce new extensions to MIPv4 protocol per guidelines specified in the MIPv4 RFCs. 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. 6.5. Functional Entities The solution MAY introduce a MIPv4 compliant functional entity that helps MIPv4 traversal across VPN or the ôNAT and VPNö gateways. However, scalability, manageability and availability implications introduced by that functional entity MUST be well understood. The functional entity MAY be implemented as a standalone entity or combined with another device such as a VPN gateway. 6.6. Multi-vendor Interoperability Multi-vendor interoperability is a key requirement. In most Enterprises, MIPv4 mobility agents 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. Medium and large Enterprises that typically purchase and deploy best-of-breed multi-vendor solutions for IP routing, VPNs, firewalls etc. are unlikely to revamp their infrastructure in favor of single-vendor end-to- end integrated solutions, preferring instead to reuse as much of their deployed infrastructure as possible. The solution proposed MUST enable such scenarios to be easily accommodated. 6.7. Fast MIPv4 Handoffs Adrangi, Iyer Expires January 2002 [Page 10]
Internet Draft draft-adrangi-mobileip-nat-vpn-problem-stat-req-00 January 2002 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 can be bound to the invariant home IP address of the MN and applicable to static and dynamic home address assignment. 6.8. Preservation of Existing VPN Infrastructure 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. 6.9. Preserve Existing DMZ Traversal Policies The solution MUST be compatible with existing DMZ policies with respect to ACLs. 6.10 Support For Route Optimization MIPv4 route optimization is not widely supported, as it requires changes to both MN's home agent and the correspondent node. Hence, The solution MAY or MAY NOT support MIPv4 Route Optimization [ROUTE-OPT]. 6.11 MIPv4 Registration SA Management Mechanisms to manage MIPv4 Registration SAs are outside the scope of this draft. 6.12 Security Implications The solution MUST NOT introduce any new vulnerabilities to the MIPv4 protocol as specified in related RFCs. 7. References [RFC3220] RFC 3220 ' IP mobility support for IPv4 [RFC3024] RFC 3024 ' Reverse tunneling for mobile IP [RFC2004] RFC 2004 ' Minimal encapsulation within IP [RFC1701] RFC 1701 ' Generic Routing encapsulation Adrangi, Iyer Expires January 2002 [Page 11]
Internet Draft draft-adrangi-mobileip-nat-vpn-problem-stat-req-00 January 2002 [RFC2119] RFC 2119 - Key words for use in RFCs to Indicate Requirement Levels [RFC1918] RFC 1918 ' Address Allocation for Private Internets [RFC2663] RFC 2663 - IP Network Address Translator (NAT) Terminology and Considerations [DHCP] RFC 2131 ' Dynamic Host Configuration Protocol [MIPv4-SEC-GUIDE] draft-bpatil-mobileip-sec-guide-01.txt - Requirements / Implementation Guidelines for Mobile IP using IP Security [[LOCAL-LINK] ' Dynamic Configuration of Iv4 Link-Local Addresses, <draft-ietf-zeroconf-ipv4-linklocal-03> [ROUTE-OPT] ' Route Optimization in Mobile IP, <draft-ietf-mobileip- optim-10.txt> [MIP-NAT]' Mobile IP NAT/NAPT Traversal using UDP Tunneling, <draft-mobileip-nat-traversal.00.txt> 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 2002 [Page 12]