view Side-By-Side changes
Internet Engineering Task Force Farid Adrangi INTERNET DRAFT Prakash Iyer<draft-adrangi-mobileip-natvpn-traversal-00><draft-adrangi-mobileip-natvpn-traversal-01> Intel Corp. Date:November 13 2001February 23 2002 Expires:MayAugust 2002 Mobile IPv4 Traversal AcrossFirewallsVPN 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 Multi-subnetted IEEE 802.11a/bWLAN networks are being widely deployed in Enterprise Intranets(in most- in many casesoutside the DMZ)requiring a VPN tunnel to connect back and access Intranet resources, and public areas such as airports, coffee shops, convention centers and shopping malls.This combined with the availability of multi- mode networked devices and applications that can take advantage of continuous mobility and constant reachability, is driving the need for Mobile IPv4 across these networks.Many of these WLAN networks also employ NAT to translate between non-routable and routableIPIPv4 care-of (point of attachment) addresses.To access protected Enterprise networks, an IPsec-basedWWAN 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 ispreferred in conjunctionmulti-vendor interoperable, providing seamless access withMobile IP.persistent VPN Expires May 2002. [Page 1] Internet Draft draft-adrangi-mobileip-natvpn-traversal-01 Feb 2002 sessions and through NAT gateways when needed. This draft proposes a solution framework that enables efficient, seamless operation of Mobile IPv4 when combined with an IPsec-based VPN and supporting NAT traversalExpires May 2002@ [Page 1] Internet Draft draft-adrangi-mobileip-natvpn-traversal-00 Nov 2001when needed. The solution has no link layer dependencies and can be applied to other802.3-compatible802.3- compatible wired and wireless physical media as well. Table Of Contents 1. Introduction....................................................3 2.Terminology.....................................................4Terminology.....................................................3 3. Acronyms........................................................4 4. An Overview of the MIPProxy....................................5Proxy....................................4 4.1. Surrogate MN Functionality....................................5 4.1.1. Registration RequestProcess................................6Process................................5 4.1.2. MN Functions Not Performed By The MIP Proxy.................6 4.2. Surrogate HAFunctionality....................................7Functionality....................................6 4.2.1. Registration Request Process................................7 4.2.2. Registration Reply Process..................................7 4.2.3. HA Functions Not Performed By The MIPProxy.................8Proxy.................7 4.4. Discovering the MNÆs actual HA by the MIP Proxy...............8 4.5. Parameter Registration RequestExtension....................9Extension....................8 4.6. Deploying a MIP Proxy.........................................9 4.7. Discovering a MIP Proxy.......................................9 4.8. MIP Proxy Redundancy..........................................9 5. MIPv4 Traversal ThroughNAT Gateways...........................10 5.1. NAT Traversal Problem Statement.............................10 5.2. Assumptions and Applicability................................10 5.3. Using the MIP Proxy for NAT Traversal......................11 5.3.1. When does a MN register with the MIP Proxy................11 5.3.2. MIPv4 registration protocol between MN and its actual HA...12 5.3.2.1. MIPv4 Data Traffic between MN and a correspondent host...12 5.3.2.3. MIPv4 Registration Request Packet Flow From MN to HA.....13 5.3.2.4. MIPv4 Registration Reply Packet Flow From HA to MN.......13 5.3.3. MIPv4 data traffic from MN to CN...........................14 5.3.4. MIPv4 data traffic from CN to MN...........................14 5.4. Summary of changes on MIPv4 components required by this solution..........................................................15 5.4.1. Required Changes to a MN...................................15 5.4.2. Required Configuration for the MIP Proxy...................16 5.5. Performance Implications of MIP Proxy assisted NAT Traversal.16 5.6. Implications of Twice NAT between the MN and MIP Proxy.......16 6. MIPv4 Traversal ThroughIPsec VPNGateways.....................16 6.1.Gateways......................9 5.1. IPsec VPN Traversal ProblemStatement........................17 6.2.Statement........................10 5.2. Integration of MIPv4 andIPsec...............................17 6.3.IPsec...............................10 5.3. Assumptions andApplicability................................17 6.4.Applicability................................11 5.4. SolutionConsiderations......................................18 6.4.1. Fast Handoffs..............................................18 6.4.2. Preserve Existing VPN Infrastructure.......................18 6.4.3. Preserve Existing DMZ Traversal Policies...................18 6.5.Considerations......................................11 5.5. Deploying the MIP Proxy to support VPNTraversal.............18 6.5.1.Traversal.............11 5.5.1. Mobile IPv4Registration...................................19 6.5.1.1.Registration...................................11 5.5.1.1. MIPv4 Registration Request Packet Flow from MN toHA.....19 6.5.1.2.HA.....12 5.5.1.2. MIPv4 Registration Reply Packet Flow from HA toMN.......20 6.5.1.3.MN.......12 5.5.1.3. DMZ Configuration Requirements for MIPv4 RegistrationPackets...........................................................20 Adrangi, Iyer Expires Nov 2002 [Page 2] Internet Draft draft-adrangi-mobileip-natvpn-traversal-00 Nov 2001 6.5.2.Packets...........................................................13 5.5.2. Mobile IPv4 DataProcessing................................20 6.5.2.1.Processing................................13 5.5.2.1. MIPv4 Data Traffic from MN toCN.........................21 6.5.2.2.CN.........................14 5.5.2.2. MIPv4 Data Traffic from CN toMN.........................22 6.5.3.MN.........................15 5.5.3. Support For RouteOptimization.............................24 6.6.Optimization.............................17 5.6. Key Management and SAPreservation...........................24 6.7.Preservation...........................17 5.7. DMZ and VPN Gateway ConfigurationRequirements...............24 6.8.Requirements...............17 5.8. Supporting Other IPsec-based VPNConfigurations..............25 6.9.Configurations..............18 5.9. Considerations for Integrating the MIP Proxy and VPNGateway.25 6.10.Gateway.18 5.10. Association Between VPN Inner and MN Home IPAddress........25 7. Using the MIP Proxy for combined NATAddress........18 6. MIPv4 Traversal Through IPsec ôNAT andVPN Traversal.........25 7.1.VPNö Gateways...........18 6.1. MIPv4 Registration MessageFlow..............................25 7.1.1.Flow..............................19 6.1.1. MIPv4 RegistrationRequests................................25 7.1.2.Requests................................19 6.1.2. MIPv4 RegistrationReplies.................................26 7.2.Replies.................................19 6.2. MIPv4 DataFlow..............................................27 7.2.1.Flow..............................................20 6.2.1. Data Flow from the MN to theCN............................27 7.2.2.CN............................20 6.2.2. Data Flow from the CN to theMN............................27 8.MN............................20 7. MIP ProxyConsiderations.......................................28 8.1.Considerations.......................................21 Adrangi, Iyer Expires August 2002 [Page 2] Internet Draft draft-adrangi-mobileip-natvpn-traversal-01 Feb 2002 7.1. Handling Simultaneous MobilityBindings......................28 8.2.Bindings......................21 7.2. Handling Mobile IP NAIExtension.............................29 8.3.Extension.............................22 7.3. Dynamic HAAssignment........................................29 9.Assignment........................................22 8. SecurityImplications..........................................29Implications..........................................22 9. Acknowledgements...............................................23 10.Acknowledgements..............................................29Patents.......................................................23 11.Patents.......................................................30Revision History..............................................23 12.References....................................................30References....................................................23 1. IntroductionIEEE 802.11 a/b WLAN networks are being widely deployed in Enterprise Intranets (in most cases outside the corporate DeMilitarized Zone - DMZ) and public areas such as airports, coffee shops, convention centers and shopping malls. This combined with the availability of multi-mode networked devices (supporting radio interfaces such as GPRS, 802.11 and 802.3) and applications that can take advantage of continuous mobilityThe problem statement andconstant reachability, is driving the needsolution requirements forMobile IPv4MIPv4 traversal acrossthese networks. Many of the wireless networks employ NAT to translate between non-routableVPN or ôNAT androutable IP addresses. Also, as many of these mobile usersVPNö gateways arelikely to require continuous and secure connectivity to their ôhomeö Enterprise networks, integrating Mobile IP with an IPsec-based VPN is critical. The solution must be clearly efficient, enabling fast handovers across IP subnets to support real-time applicationsarticulated in [15]. To help understand the motivation andmust support NAT traversal when needed. Therational for the solution proposed in this draft, we strongly encourage the audience to read [15] first. This draft introduces a logical component called the MIP Proxy to enable seamless Mobile IPv4 functionality acrossNAT andVPNgateways / routers,or ôNAT and VPNö gateways, without requiring any IPsec VPN protocol changes tothese middle boxes.VPN gateways and completely transparent to intervening NAT gateways. In the context of VPNs, the solution aims specifically at extending the use of deployed IPsec-based VPN gateways, a feature that is much desired by corporate IT departments.Adrangi, Iyer Expires Nov 2002 [Page 3] Internet Draft draft-adrangi-mobileip-natvpn-traversal-00 Nov 2001 While much of the discussion in this draft is focused on deploying the MIP Proxy in conjunction with an IPsec-based VPN gateway in a DMZ, the MIP Proxy can also be deployed in the public Internet or in a service provider network to support NAT traversal without requiring any changes to deployed Home Agents (HA) or to enable load balancing across multiple HAs with dynamic home address assignment support.The important sections of this draft are organized as follows: Section 4 describes the MIPproxy.proxy component. Section 5 discusses theuse ofMIP Proxy forseamlessMIPv4 traversal throughNAT gateways.IPsec VPN Gateways Section 6 discusses theintegration ofMIP Proxywith VPN gatewaysforIPsec support with Mobile IPv4. Note that support for NAT and VPNMIPv4 traversalcan be deployed independently or in combination depending on specific network configurations, as discussed in section 7. Finally, section 8through ôNAT and VPNö Gateways Section 7 discusses miscellaneous topics related to the MIP Proxy. 2. Terminology Administrative Domain: In the context of this draft an administrative domain is the entity that specifies security parameters for Mobile IP registration extensions for one or more Home Agents and their corresponding mobile nodes. The administrative domain also manages policies that govern negotiation of security associations for VPN sessions that terminate or initiate at the edge of the network under its jurisdiction. Actual Home Agent: It is the mobile nodeÆs real home agent, as defined by[RFC2002].[RFC3220]. NAT-Router: It is an IPv4 Router with NAT functionality. Adrangi, Iyer Expires August 2002 [Page 3] Internet Draft draft-adrangi-mobileip-natvpn-traversal-01 Feb 2002 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this draft are to be interpreted as described in[RFC2119].[5]. 3. Acronyms GRE: Generic Routing Encapsulation ISP: Internet Service provider MIPv4: Mobile IP for IPv4 MIPv6: Mobile IP for IPv6 NAT: Network Address Translation MN-Perm: Permanent home address of the MN MN-COA: Co-located care-of address of the MNAdrangi, Iyer Expires Nov 2002 [Page 4] Internet Draft draft-adrangi-mobileip-natvpn-traversal-00 Nov 2001MIPP-Priv: MIP Proxy interface address on the private (HA) side MIPP-Pub: MIP Proxy interface address on the public (Internet) side NATGW-Priv: NAT gatewayÆs IP address on the private (LAN) side NATGW-Pub: NAT gatewayÆs IP address on the public (WAN) side IP-D: IP Destination Address IP-S: IP source Address VPNGW-Pub: VPN Gateway Public/External IP Address VPNGW-Priv: VPN Gateway Private/Intranet IP Address 4. An Overview of the MIP Proxy The MIP Proxy is a functional entity that is introduced in the path between a MN and itÆs corresponding actual HA as depicted in the figure below. The MIP Proxy serves two primary functions: that of a surrogate MN and a surrogate HA to essentially ôstitchö an end-to-end connection between a MN anditÆsits HA. A single MIP Proxy can serve multiple MNs and HAs and can consequently be associated with multiple home subnets. The MIP Proxy does not replace any existing HAs. The MIP Proxy MUST belong to the same administrative domain as any of its associated home agents and their corresponding mobile nodes. It MUST share SAs for various MIPv4 registration extensions with its associated HA(s).+----+The mechanisms to share SAs is beyond the current scope of this draft. Adrangi, Iyer Expires August 2002 [Page 4] Internet Draft draft-adrangi-mobileip-natvpn-traversal-01 Feb 2002 +---+ +------+ +---------------------------+ |MN | | | |Home network / VPN Domain | +---+ | MIP | |MN |------+----+ +-----+ +----+ ||--| HA. . . |Proxy |<->| |HA-1| | HA-2| |HA-n| | +---+ |à| | +----+ +-----+ +----+ |+----------+|MN | |+----+|MN |------------| MIP Proxy|----------|--| HA|+----+|+----------++---+ +------+ | +----+à+-----+ +----+ | +---+ | |FA-1| | FA-2| |FA-n| | |MN | | +----+ +-----+ +----+ ||--| HA+---+ | | |MN |-----+----+ +-----+ +-----+ | | |MN-1| | MN-2| | MN-n| | | +----+ +-----+ +-----+ | +---------------------------+ Figure 4.0 û MIP Proxy serving multiple MNs and HAs A MIP Proxy MAY be extended to support traversal through middle boxes other than NAT and VPN gateways. However, this draft only focuses on requirements forNAT andVPN or ôNAT and VPNö gateways. The MIP Proxy will nominally run on a dual-homed host.However, itIt MAY be possible to instantiate the MIP Proxy on a singly homedhost,host - however in this document we assume that the MIP Proxy is instantiated on a dual-homed host. The MIP ProxyMAYmay be implemented as a standalone device or combined with other functional entities such as a VPN gateway. 4.1. Surrogate MN Functionality One of the primary functions of the MIP Proxy is to serve as a MNÆs surrogate when it roams into a foreign network outside theAdrangi, Iyer Expires Nov 2002 [Page 5] Internet Draft draft-adrangi-mobileip-natvpn-traversal-00 Nov 2001intranet protected by the DMZ. The following sections describe the MIP ProxyÆs feature requirements as a MNÆs surrogate. 4.1.1. Registration Request Process The MIP Proxy MUST relay all Registration Requests received from a MN to its actual HA, with theexceptionexceptions specified in section 4.2.1. Here, relaying means that the MIP Proxy creates a new Registration Request on the behalf of the MN and sends it to the MNÆs actual HA. In doing so, the MIP proxy MUST be compliant with[RFC2002],[1], and it MUST adhere to the following rules in creating the new Registration Request: - The new Registration Request header MUST have the same æBÆ, æMÆ, æGÆ, rsv bit values included in the Registration Request received from the MN. - The æDÆand æTÆ bitsbit in the new Registration Request MUST be set. Adrangi, Iyer Expires August 2002 [Page 5] Internet Draft draft-adrangi-mobileip-natvpn-traversal-01 Feb 2002 - The æTÆ bit in the new Registration Request MUST NOT be set, as the MIPv4 data traffic will always be delivered in non- reverse tunnel mode from MIP Proxy surrogate MN to CN. - The new Registration Request MUST NOT set the æSÆbit.bit, please see section 7.1 for more details. - The new Registration Request header MUST have the same lifetime value included in the registration request received from the MN. - The new Registration Request header MUST have the same identification value included in the Registration Request received from the MN. - The new Registration Request header MUST have the same Home Address value included in the Registration Request received from the MN. - The new Registration Request headerÆs home agent address field MUST be set to the MNÆs actual home agent address. - The new Registration Request headerÆs care-of address field MUST be set to MIPP-Priv. - The new Registration Request MUST contain all Registration extensions included in the Registration Request received from the MN, with the exception of the ones specific to the MN and the MIP Proxy protocol negotiation and the authentication extension protecting the registration message between the MN and the MIP Proxy. - The new Registration Request MUST include the MN-HA authentication extension. 4.1.2. MN Functions Not Performed By The MIP ProxyAdrangi, Iyer Expires Nov 2002 [Page 6] Internet Draft draft-adrangi-mobileip-natvpn-traversal-00 Nov 2001The MIP proxy MUST NOT perform the following functions, as specified by[RFC2002]:[1]: - It MUST NOT respond to agent solicitations or functions pertaining to agent discovery - It MUST NOT implement any move detection mechanisms - The MIP Proxy MUST not manage registration lifetimes and MUST NOT reinitiate a registration request with the actual HA prior to its expiration. 4.2. Surrogate HA Functionality The other primary function of the MIP Proxy is to serve as a surrogate HA to a MN when it roams into a foreign network outside the intranet protected by a DMZ. The following sections describe the MIP proxyÆs features as a surrogate HA. Adrangi, Iyer Expires August 2002 [Page 6] Internet Draft draft-adrangi-mobileip-natvpn-traversal-01 Feb 2002 4.2.1. Registration Request Process Upon receipt of a Registration Request from a MN, the MIP proxy MUST apply the same validity checks as a HA would, as specified by[RFC2002].[1]. In addition, the MIP proxy MUST check for the following: - The æTÆ bit MUST be set in the Registration Request received from a MN. - The MIP proxy MUST check for the existence and validity of the Registration Request extension(s) required by the MIP proxy from a MN. If malformed Registration Requests are detected, the MIP proxy MUST return a Registration Reply to the MN with an appropriate error code, one from the list specified in[RFC2002][1] to be used by HAs. 4.2.2. Registration Reply Process The MIP proxy MUST relay received Registration Replies to appropriate MNs. The MIP proxy MUST update its record of mobility bindings associated with a MN, before relaying the registration reply to the MN. In processing a registration reply, the MIP proxy MUST be compliant with[RFC2002].[1]. And, it MUST adhere to the following rules in creating the new Registration Reply: - The new Registration Reply header MUST have the same Home Address value as in the Registration Reply received from the MNÆs actual HA. - The new Registration Reply headerÆs Home Agent Address field MUST be set to MIPP-Pub.Adrangi, Iyer Expires Nov 2002 [Page 7] Internet Draft draft-adrangi-mobileip-natvpn-traversal-00 Nov 2001- The new Registration Reply header MUST have the same identification value as the Registration Reply received from the MNÆs actual HA. - The new Registration Reply MUST contain all non- authentication extensions included in the Registration Reply received from the MNÆs actual HA. - The new Registration Reply MUST include the ôMN-HAö authentication extension or the ôMN-FAö authentication extension as appropriate. 4.2.3. HA Functions Not Performed By The MIP Proxy Adrangi, Iyer Expires August 2002 [Page 7] Internet Draft draft-adrangi-mobileip-natvpn-traversal-01 Feb 2002 The MIP Proxy MUST NOT perform the following HA functions, as defined in[RFC2002]:[1]: - It MUST NOT generate agent advertisements - It MUST NOT send gratuitous ARPs - It MUST NOT perform Proxy ARP - It MUST NOT support Route Optimization[ROUTE-OPT][10] 4.3. Registration Binding Table The MIP Proxy MUST maintain a mobility binding list similar to the one specified in[RFC2002][1] for a HA, in order to forward the registration replies and subsequent MIPv4 data traffic. The MIP Proxy MUST also use the same methods defined in[RFC2002][1] for deleting or retiring the entries in itsmobility- bindingmobility-binding list(s). 4.4. Discovering the MNÆs actual HA by the MIP Proxy As the MN registers with the actual HA via the MIP Proxy, the MIP Proxy needs a mechanism to determine the IP address of the actual HA. Some possible mechanisms include: - The MN MAY indicate the IP address of the actual HA via the Parameter Registration Extension, which is described in section 4.5. - The MIP Proxy MAY be statically configured with all HA addresses that it supports. - The MIP proxy MAY implement a dynamic method to discover the MNÆs actual HA address. In the absence of the Parameter Registration Extension and not being able to discover the HA by using any of the methods listed above or methods not described in this draft, the MIPAdrangi, Iyer Expires Nov 2002 [Page 8] Internet Draft draft-adrangi-mobileip-natvpn-traversal-00 Nov 2001Proxy MUST reject the Registration Request with an error code of 136, ôunknown home agent addressö. 4.5. Parameter Registration Request Extension The figure below shows the format of the Parameter Registration Extension that MAY be used in the registration request by a MN to specify the MNÆs actual HA IP address to the MIP Proxy. 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Sub-Type |Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Home Agent Address | +-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Adrangi, Iyer Expires August 2002 [Page 8] Internet Draft draft-adrangi-mobileip-natvpn-traversal-01 Feb 2002 Type : To be assigned by IANA (skippable) Length : Indicates the length (in bytes) of the data fields within theextension, excluding the Type and Length bytes. Sub-Type: To be assigned by IANA Reserved: For future use. Home Agent Address: IP address of the MNÆs actual HA 4.6. Deploying a MIP Proxy A MIP Proxy MAY be deployed in a public network serving multiple HAs in that network as conceptually depicted in Figure 4 above. It MUST be deployed in a DMZ to support authenticated firewall traversal for MIPv4 packets traversing the DMZ from a MN with an intervening NAT gateway in its foreign network. It MUST be deployed in parallel with an IPsec-compatible VPN gateway or functionally integrated with a VPN gateway in a DMZ. Trivially, a subset of the MIP Proxy functionality MAY be co- located with a HA if appropriate. The MIP Proxy MAY be located in the same or a different subnet from any of its associated HAs. 4.7. Discovering a MIP Proxy A MN MUST be statically configured with the MIPP-Pub address of the MIP Proxy. Dynamic discovery of the MIP ProxyÆs public IP address is outside the scope of this draft. 4.8. MIP Proxy Redundancy A MIP Proxy redundancy protocol is desirable to effect high availability in public and Enterprise deployments. Details of such a protocol are beyond the current scope of this draft. Adrangi, Iyer Expires Nov 2002 [Page 9] Internet Draft draft-adrangi-mobileip-natvpn-traversal-00 Nov 2001 5. MIPv4 Traversal Through NAT Gateways 5.1. NAT Traversal Problem Statement When a MN roams from its home network (which may or may not be in a routable IP address space) 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. The scenario is depicted in Figure 5.1 below. +-------------------+ +-------------------------+ | Foreign network | | Home Network | | +----+ | +-----+ | | | | MN | |----| NAT |---| +----+ +----+ +---+ | | +----+ | +-----+ | | MN | | HA | |CN | | | | | +----+ +----+ +---+ | +-------------------+ | | | +---+ | | | FA| | | +---+ | +-------------------------+ Figure 5.1 û MN has moved from its home network to a foreign network Even if we overcome this problem somehow by using the NAT gatewayÆs public routable address in the care-of address field of the registration request, the NAT gateway will not always be able to demultiplex inbound MIPv4 data traffic properly. Consider two MNs behind the NAT gateway registered with the same HA. The inbound IP-in-IP tunneled MIPv4 packets from the HA to the two MNs will have the source and destination IP address û making it difficult for the NAT gateway to route the packets to the appropriate MN. The implications on Minimal IP [RFC2004] and GRE encapsulation [RFC1701] modes of MIPv4 are similar to IP-in-IP tunneling. 5.2. Assumptions and Applicability The solution proposed in the draft is targeted toward network environments where the following considerations are valid. - The NAT gateway MUST support NAPT. - The NATÆed network MUST provide DHCP services to the foreign subnet or a mobile node MUST be capable of self-assigning or acquiring by other means, a non-routable care-of address and related information (such as the Default Gateway and Subnet Mask) when it roams behind the NAT gateway. Adrangi, Iyer Expires Nov 2002 [Page 10] Internet Draft draft-adrangi-mobileip-natvpn-traversal-00 Nov 2001 - The NATÆed network MAY NOT include a FA. - The NATÆed network MAY NOT be in the same administrative domain as the MN, MIP Proxy and actual HA. - The NATÆed network MUST be configured with the IP addresses reserved for private Internets by IANA ([RFC1918], [LOCAL- LINK]). - The actual HA is not directly reachable and as such SHOULD NOT be modified. - MNÆs home network MUST be in a routable IP address domain. This address domain MAY be behind a firewall/DMZ. - A FA MAY NOT be available in the ISP access or core network. - The security implications of the solution SHOULD NOT be worse than direct communication with the actual HA. Applicability in other network environments has not been verified; however it is not explicitly precluded. Furthermore, the proposed solution MAY be used in combination with other NAT traversal solutions as appropriate. If the MNÆs home network is in a non-routable IP address domain, an appropriate solution (outside the scope of this draft) MUST be deployed to make the home network accessible from an external public or private network. 5.3. Using the MIP Proxy for NAT Traversal The MIP Proxy relays registration request and reply messages as described in earlier sections. Registration messages are carried over UDP port 434 and as such as friendly to NAT. However, all subsequent MIPv4 data traffic between the MN and the MIP Proxy SHOULD be encapsulated in a UDP tunnel, in order to assist the NAT gateway in demultiplexing return inbound MIPv4 traffic using traditional NAT/NAPT mechanisms. The protocol details for Mobile IP NAT traversal are described in an IETF draft [MIP-NAT]. This draft specifies a protocol between the MN and its HA in order to enable and maintain the MN connectivity while visiting in a private network behind a NAT. When this protocol is used between a MN and the MIP Proxy, the MN SHOULD relay its actual HA address to the MIP proxy via the Parameter Registration Extension defined in section 4.5. However, if in this deployment scenario none of the HA changes specified in [MIP-NAT] are required. The following sections describe the adaptation of [MIP-NAT] to scenarios where the actual HA is behind a DMZ. 5.3.1. When does a MN register with the MIP Proxy A mobile node MUST register with the MIP Proxy when it roams to a foreign network behind a NAT gateway and needs to register with its HA behind a DMZ. Mechanisms to detect the presence of a NAT gateway are beyond the scope of this draft. Adrangi, Iyer Expires Nov 2002 [Page 11] Internet Draft draft-adrangi-mobileip-natvpn-traversal-00 Nov 2001 5.3.2. MIPv4 registration protocol between MN and its actual HA Once the MN obtains a co-located address and realizes that it is connected behind a NAT gateway, it generates a Registration Request for the MIP Proxy. The normal flow of MIPv4 registration messages between a MN and its HA are altered as depicted in the figure below. MN NAT Gateway MIP Proxy HA |Reg.Request | | | |-------------->|Reg. Request | | | |-------------> |New Reg. Request | | | |-------------> | | | |Reg. Reply | | |New Reg. Reply |<------------- | |New Reg. Reply |<------------- | | |<------------- | | | Figure 5.3.2 û Mobile IP registration between MN and HA 5.3.2.1. MIPv4 Data Traffic between MN and a correspondent host To support multiple, simultaneous MIPv4 data sessions from MNs behind a NAT gateway to a home network via the same HA behind a DMZ, a UDP tunnel MUST be established between the MN and MIP Proxy. The UDP establishment method and protocol are as described in the [MIP-NAT] draft. However, the UDP tunnel is terminated at the MIP Proxy instead of the MNÆs actual HA. In the reverse direction, the data traffic MUST be tunneled from the MIP Proxy to the MN. The MIP Proxy MAY forward MIPv4 data packets with or without reverse tunneling. MN NAT Gateway MIP Proxy HA CH |IP/UDP/IP | | | | |-------------->|IP/UDP/IP | | | |Traffic |-------------> |IP/IP | | |Traffic |-------------> | IP | | | | |------>| | | | |Traffic| | | | IP | | | | |---------------------->| | | | | IP | | | | IP/IP Traffic |< ---- | | | IP/UDP/IP |< ----------- |Traffic| | |< ------------ | | | IP/UDP/IP | Traffic | | | |< ------------ | | | | | Traffic | | | | Figure 5.3.2 û Mobile IP Data Traffic between MN and CH Adrangi, Iyer Expires Nov 2002 [Page 12] Internet Draft draft-adrangi-mobileip-natvpn-traversal-00 Nov 2001 5.3.2.3. MIPv4 Registration Request Packet Flow From MN to HA The MN sends the Registration Request to the MIP Proxy. The intervening NAT gateway modifies the source IP address (and possibly the UDP source port). From MN to the MIP Proxy: +--------------------------------------------------+ |IP-S = MN-COA | Permanent Address = MN-Perm | |IP-D = MIPP-Pub | Home Agent = MIPP-Pub | | | Care-of Address = MN-COA | | | . . . | +--------------------------------------------------+ The NAT gateway modifies the source IP address, and possibly UDP source port number. +--------------------------------------------------+ |IP-S = NATGW-Pub | Permanent Address = MN-Perm | |IP-D = MIPP-Pub | Home Agent = MIPP-Pub | | | Care-of Address = MN-COA | | | . . . | +--------------------------------------------------+ The MIP Proxy terminates and authenticates the Registration Request received from the MN. It then modifies the registration request payload and forwards a new registration request to the HA associated with the MN. The MIP Proxy MUST set the Home Agent and Care-of Address fields of the registration request to the MNÆs actual HA (learned from the Parameter Registration Extension) and the MIP ProxyÆs private address respectively. The packet format is shown below. +--------------------------------------------------+ |IP-S = MIPP-Priv | Permanent Address = MN-Perm | |IP-D = HA | Home Agent = HA | | | Care-of Address = MIPP-Priv | | | . . . | +--------------------------------------------------+ 5.3.2.4. MIPv4 Registration Reply Packet Flow From HA to MN If the actual HA were to accept the registration request, the reply flow sequence will be as follows: From the HA to the MIP Proxy: +------------------------------------------+ |IP-S = HA | Home Agent = HA | |IP-D = MIPP-Priv | . . . | +------------------------------------------+ Adrangi, Iyer Expires Nov 2002 [Page 13] Internet Draft draft-adrangi-mobileip-natvpn-traversal-00 Nov 2001 From the MIP Proxy to the NAT +------------------------------------------+ |IP-S = MIPP-Pub | Home Agent = MIPP-Pub | |IP-D = NAT-Pub | . . . | +------------------------------------------+ From the NAT to the MN: +------------------------------------------+ |IP-S = MIPP-Pub | Home Agent = MIPP-Pub | |IP-D = MN-COA | . . . | +------------------------------------------+ 5.3.3. MIPv4 data traffic from MN to CN The normal flow of MIPv4 data flow between a MN and a HA are altered as depicted in figure 5.3.2. All MIPv4 data traffic between the MN and MIP Proxy will be encapsulated in a UDP tunnel. The MIP Proxy will strip off the outer IP and UDP headers, and re-encapsulate the detunneled packet in an IP header (from MIPP-Pub to MN or from MIPP-Priv to HA as the case may be) before forwarding it to the MN or HA respectively. The following figures illustrate the traffic flow from the MN to the MIP Proxy, and the MIP Proxy to the actual HA. MIPv4 data packet flow from the MN to the MIP Proxy: +-------------------------------------------------------+ |IP-S=MN-COA |UDP Src Port# |IP Src = MN-Perm | Data | |IP-D=MIPP-Pub |UDP Dest Port#|IP Dest = CN | | +-------------------------------------------------------+ The intermediate NAT gateway will apply address and port mapping on the packet, and forward the packet, as follows: +-------------------------------------------------------+ |IP-S=NAT-Pub |UDP Src Port# |IP Src = MN-Perm |Data | |IP-D=MIPP-Pub |UDP Dest Port#|IP Dest = CN | | +-------------------------------------------------------+ MIPv4 data packet flow from the MIP Proxy to CN is as follows: +------------------------------------------------+ | IP-S = MIPP-Pri |IP Src = MN-Perm |Data | | IP-D = HA |IP Dest = CN | | +------------------------------------------------+ 5.3.4. MIPv4 data traffic from CN to MN MIPv4 data traffic will be tunneled from the actual HA to the MIP Proxy in an IP-in-IP tunnel is illustrated in the figure above. The solution MAY be extended to apply to other MIPv4 Adrangi, Iyer Expires Nov 2002 [Page 14] Internet Draft draft-adrangi-mobileip-natvpn-traversal-00 Nov 2001 encapsulation modes as well. The MIP Proxy strips off the outer IP header, and forwards the inner IP packet to the MN in a UDP tunnel. The following figures illustrate the traffic flow from the CN to the MN (via the actual HA and the MIP Proxy). The data packets from the CN will be sent to the MNÆs permanent address, MN-Perm. +-----------------------------+ | IP-S = CN |Data | | IP-D = MN-Perm | | +-----------------------------+ The MNÆs actual HA will intercept the data packet, and forward it to its current care-of address (i.e., MIP Proxy) as follows: +----------------------------------------------+ | IP-S = HA |IP Src = MN-Perm |Data | | IP-D = MIPP-Priv |IP Dest = CN | | +----------------------------------------------+ From the MIP Proxy to the NAT gateway: +---------------------------------------------------------+ |IP-S = MIPP-Pub |UDP Src Port# |IP Src = MN-Perm |Data | |IP-D = NAT-Pub |UDP Dest Port#|IP Dest = CN | | +---------------------------------------------------------+ The NAT gateway unapplies the address and port mapping on the packet, and forwards the packet, as follows: From the NAT gateway to the MN: +----------------------------------------------------------+ | IP-S = MIPP-Pub |UDP Src Port# |IP Src = MN-Perm |Data | | IP-D = MN-COA |UDP Dest Port#|IP Dest = CN | | +----------------------------------------------------------+ 5.4. Summary of changes on MIPv4 components required by this solution This solution requires changes on the mobile node, and of course an addition of a new component, the MIP Proxy. 5.4.1. Required Changes to a MN - The MN MUST be statically configured with MIPP-Pub. A mechanism for MIP Proxy discovery MAY be defined in future. - The MN MUST be able to determine if it has roamed to a private address space behind a NAT gateway. - The MN SHOULD implement the Parameter Registration Extension as specified in this draft. Adrangi, Iyer Expires Nov 2002 [Page 15] Internet Draft draft-adrangi-mobileip-natvpn-traversal-00 Nov 2001 - The MN MUST implement the protocol specified inextension, excluding the[MIP-NAT] draft. 5.4.2. Required Configuration forType and Length bytes. Sub-Type: To be assigned by IANA Reserved: For future use. Home Agent Address: IP address of the MNÆs actual HA 4.6. Deploying a MIP Proxy- TheA MIP Proxy MUST beconfigured with all ofdeployed in a DMZ to support authenticated firewall traversal for MIPv4 packets traversing theSAs ofDMZ from a MNandwith an intervening NAT gateway in its foreign network. It MUST be deployed in parallel with an IPsec-compatible VPN gateway or functionally integrated with aHA that it represents asVPN gateway in a DMZ. 4.7. Discovering asurrogate. - TheMIP ProxySHOULDA MN MUST be statically configured withstatic IP addresses to avoid periodic reconfiguration on MNs. 5.5. Performance Implicationsthe MIPP-Pub address of the MIPProxy assisted NAT Traversal TheProxy. Dynamic discovery of the MIPProxy introduces very minimal overhead to support NAT traversal. Specifically, an 8-byte UDP headerProxyÆs public IP address isadded to the MIPv4 data traffic from the MN tooutside the scope of this draft. 4.8. MIP Proxyand vice versa. 5.6. Implications of Twice NAT between the MN andRedundancy A MIP ProxyThe proposed solution WILL work even if Twice NATredundancy protocol isencountereddesirable to effect high availability inthe path between the MNpublic and Enterprise deployments. Details of such a protocol are beyond theMIP proxy. 6.current scope of this draft. 5. MIPv4 Traversal Through IPsec VPN Gateways A MN whose home network is in a routable IP address space behind a VPN gateway could roam to an external public or private address space. An example would be a user who roams from within a Corporate Intranet to an external wired or wireless hot spot. In this case, the MNÆs HA is located in the Corporate Intranet behind the firewall/DMZ complex, as illustrated in the figure below. It is desirable in this scenario to connect back to the Intranet via a VPN and stay connected even as the user roams from one external IP subnet to another. The integration of MIPv4 and IPsec has not been standardized and several issues have to be overcome to support seamless end-to-end IPsec with MIPv4. This draft describes a solution based on the use of the MIP Proxy to enable seamless traversal across IPsec-based VPNs. Adrangi, Iyer Expires August 2002 [Page 9] Internet Draft draft-adrangi-mobileip-natvpn-traversal-01 Feb 2002 +----------------+ +-----+ +------+ +-----+ +---------------+ |Foreign network | | | ->|VPN-GW|<---- | | |Home network | |+----+ +----+ | |Outer| | +------+ | |Inner| | +----+ +----+ | || MN | | FA | | |FW | | | |FW | | |HA | | CN | | |+----+ +----+ | | | | +---------+ | | | | +----+ +----+ | | | | | ->|MIP Proxy|<- | | | | +----------------+ +-----+ +---------+ +-----+ | +----+ | ^ ^ | | MN | | |----- Firewall/DMZ ----- | | +----+ | +---------------+ Figure6.05.0 û MN moves from its home network to a foreign network outside the DMZAdrangi, Iyer Expires Nov 2002 [Page 16] Internet Draft draft-adrangi-mobileip-natvpn-traversal-00 Nov 2001 6.1.5.1. IPsec VPN Traversal Problem Statement With respect to Figure6.05.0 above, the problem can be summarized in the following 2 scenarios: Scenario 1: The MN could roam into a foreign subnet without a FA and obtain a COA at its point of attachment (via DHCP or other means). In an end-to-end security model, an IPsec tunnel that terminates at the VPN gateway in the DMZ 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 subnet handoff which could have some performance implications on real-time applications. Scenario 2: 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 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.6.2.5.2. Integration of MIPv4 and IPsec Clearly there are several schemes to apply IPsec to MIPv4 packets.[MIPv4-SEC-GUIDE][8] describes different segments where IPsec could be applied to MIPv4 packets. This draft is based on the premise that the most likely acceptable scenario is the one in which Adrangi, Iyer Expires August 2002 [Page 10] Internet Draft draft-adrangi-mobileip-natvpn-traversal-01 Feb 2002 IPsec is appliedend-to-end. 6.3.ôend-to-endö (i.e. from the MN to a VPN gateway at the edge of the target network). 5.3. Assumptions and Applicability The solution is derived based on the following assumptions and applicability criteria: - An end-to-end IPsec tunnel mode MUST be applied to MIPv4 data flows; i.e. between the MN and the VPN gateway at the edge of its home network. - MIPv4 registration packets MAY NOT require an IPsec tunnel as they are authenticated and integrity protected. However, they MUST be terminated inside the DMZ to enable authenticated firewall traversal. - FA-assisted routing and MN co-located modes of operationMUST be supported. Adrangi, Iyer Expires Nov 2002 [Page 17] Internet Draft draft-adrangi-mobileip-natvpn-traversal-00 Nov 2001MUST be supported. - The MN MUST be configured with the MIP Proxy and the VPN gatewayÆs external IP addresses, and route the MIPv4 traffic through the MIP Proxy when it is outside the corporate intranet. - The MN SHOULD be able to determine if it has roamed outside the corporate network by some method (e.g., by comparing its current COA against address blocks used by the corporate intranet). - The MN MUST be able to determine when it should exercise its key exchange protocol to establish the IPsec tunnel SA to the VPN gateway.6.4.5.4. Solution Considerations In addition to enabling the use of end-to-end IPsec with MIPv4, the use of the MIP Proxy in the DMZ enables a solution thatcan meet the following criteria: 6.4.1. Fast Handoffs To support fast handoffs across IP subnets, it is imperative to keep the key management overhead down to a minimum. In this draft, we propose a mechanism whereby the IPsec tunnel SA can be bound to the invariant permanent IP address of the MN. Doing so, enables the reuse of the SA across IP subnet handoffs and also minimizes the protocol handshake between the VPN gateway, actual HA and the MIP Proxy. 6.4.2. Preserve Existing VPN Infrastructure This implies the following: - Preservesmeets theinvestment in existing VPN gateways - Requires no software upgrades to VPN gateways to explicitly support MIPv4 users - Preserves IPsec VPN securityrequirementsthat 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.4.3. Preserve Existing DMZ Traversal Policies Most Corporate DMZ policies recommend authenticated firewall traversal for protocols that traverse the DMZ. Placing devices outside the outer DMZ firewall to assist with DMZ traversal exposes the device to hackers and is generally not an acceptable solution. IT departments prefer that solutions adhere to and can be accommodated with existing or compliant DMZ ACLs. 6.5.specified in [15]. 5.5. Deploying the MIP Proxy to support VPN TraversalAdrangi, Iyer Expires Nov 2002 [Page 18] Internet Draft draft-adrangi-mobileip-natvpn-traversal-00 Nov 2001As shown in Figure6.0,5.0, the MIP Proxy is deployed in parallel to an existing VPN gateway in the DMZ to support MIPv4.6.5.1.The MIP Proxy can also be integrated with VPN to provide one box solution. 5.5.1. Mobile IPv4 Registration The MN sends MIPv4 registration requests directly to the MIP Proxy. The MIP Proxy terminates and authenticates the registration requests. It then generates a new registration request and forwards it to the corresponding HA. The registration request SHOULD include the Parameter Registration Extension (see section 4.5) to notify the MIP Proxy about the MNÆs actual HA. The registration replies from the HA will also go through the MIP Proxy bypassing the VPN gateway. Note that Adrangi, Iyer Expires August 2002 [Page 11] Internet Draft draft-adrangi-mobileip-natvpn-traversal-01 Feb 2002 the MN and the MIP Proxy MUST share the SA for the MN-HA authentication extension. This solution also works if the MN were to use a FA in the foreign network. Arail-roadrailroad diagram illustrating the MIPv4 registration process is shown below. MN MIP Proxy HA |Reg. Request | | |-------------> | | | |Reg. Request | | |-------------> | | |Reg. Reply | | |<------------- | |Reg. Reply | | |<--------------| | Figure6.5.15.5.1 û Mobile IP registration protocol between MN and HA6.5.1.1.5.5.1.1. MIPv4 Registration Request Packet Flow from MN to HA This draft illustrates the sequence from MN to HA via a FA û it can be easily extended to describe the flow for a co-located COA mode MN. From the MN to a FA: +--------------------------------------------------+ |IP-S = MN-Perm | Permanent Address = MN-Perm | |IP-D = FA_COA | Home Agent = MIPP-Pub | | | Care-of Address = FA COA | | | . . . | +--------------------------------------------------+ From the FA to the MIP Proxy: +--------------------------------------------------+ |IP-S = FA COA | Permanent Address = MN-Perm | |IP-D = MIPP-Pub | Home Agent = MIPP-Pub | | | Care-of Address = FA COA |Adrangi, Iyer Expires Nov 2002 [Page 19] Internet Draft draft-adrangi-mobileip-natvpn-traversal-00 Nov 2001| | . . . | +--------------------------------------------------+ From the MIP Proxy to the actual HA: +--------------------------------------------------+ |IP-S = MIPP-Priv | Permanent Address = MN-Perm | |IP-D = HA | Home Agent = HA | | | Care-of Address = MIPP-Priv | | | | +--------------------------------------------------+6.5.1.2.5.5.1.2. MIPv4 Registration Reply Packet Flow from HA to MN Adrangi, Iyer Expires August 2002 [Page 12] Internet Draft draft-adrangi-mobileip-natvpn-traversal-01 Feb 2002 If the actual HA were to accept the registration request, the reply flow sequence will be as follows: From the HA to the MIP Proxy: +--------------------------------------+ |IP-S = HA | Home Agent = HA | |IP-D = MIPP-Priv | | +--------------------------------------+ From the MIP Proxy to the FA: +-----------------------------------------------+ |IP-S = MIPP-Pub | Home Agent = MIPP-Pub | |IP-D = FA | . . . | +-----------------------------------------------+ From the FA to the MN: +-----------------------------------------------+ |IP-S = FA | Home Agent = MIPP-Pub | |IP-D = MN-Perm | . . . | +-----------------------------------------------+6.5.1.3.5.5.1.3. DMZ Configuration Requirements for MIPv4 Registration Packets The DMZ Access Control Lists (ACL) MUST be setup for the following: - Inbound UDP registration packets (destination port = 434 and destination address = MIPP-Pub) MUST be permitted. - The DMZ inner firewall MUST permit the forwarding of registration request and reply packets from the MIP Proxy to one or more HAs.6.5.2.5.5.2. Mobile IPv4 Data ProcessingThe following railroad diagram illustrates the sequence ofThere are two steps that MUST be successfully completed in order to establish secured MIPv4 traffic between a MN and a CN. Theprocess initially occursfirst step is that the MN MUST complete MIPv4 registration with its actual home agent through the MIP Proxy, as discussed in 5.5.1 section. The second step is that the MN MUST establish IPsec tunnel SA to the VPN gateway through the MIP Proxy, as shown in3 sequential steps: MIPv4 registration, IPsec tunnel SA establishment and MIPv4 data forwarding. RegistrationFigure 5.5.2b. Any subsequent registration and SA refreshes maysubsequentlyoccur independent of each other. Adrangi, Iyer ExpiresNovAugust 2002 [Page20]13] Internet Draftdraft-adrangi-mobileip-natvpn-traversal-00 Nov 2001 MIPv4 Registration û see Figure 6.5.1 Note that the VPN gateway is not involved in the MIPv4 Registration process. IPsec Tunnel SA Establishment:draft-adrangi-mobileip-natvpn-traversal-01 Feb 2002 MN MIP Proxy VPN Gateway | IKE-Phase 1/MIPv4 | | --------------> | IKE-phase 2 ||IKE Phase 1 (ISAKMP SA) <---------->| |-----------------> | ||IKE Phase| IKE-phase 2(Tunnel SA) <---------->| | IKE-Phase 2/MIPv4|<-------------------| |Note that the MIP proxy is not involved in the<---------------- | | Figure 5.5.2b û IPsec Tunnel SAestablishment and will not be involved in SA refreshes.Establishment The data forwarding is described in the following 2 sub- sections.6.5.2.1.5.5.2.1. MIPv4 Data Traffic from MN to CN The MN generates an IP packet from the MN-Perm interface and destined to the CN. This packet is encapsulated in an IPsec-ESP tunnel from MN-Perm to VPNGW-Pub. The packet in turn is encapsulated in an IP header from MN COA to the MIP Proxy. The MIP Proxy strips off the outermost IP header and forwards the inner IP packet (which is from the MNÆs permanent address to the VPN gateway) to the VPN gateway. The VPN gateway in turn processes the IPsec VPN tunnel, strips off the IP and ESP headers and forwards the inner most IP packet to the destination CN. The railroad diagram depicts the packet flow sequence, followed by a description of packets as they traverse the network. MN FA MIP Proxy VPN Gateway HA CN | | | | | | | ----> | | | | | | | -----> | | | | | | | ------------> | | | | | | | -----------------> | From the MN to MIP Proxy: IP-IP-ESP-IP-TCP/UDP-Data From MIP Proxy to VPN: IP-ESP-IP From VPN Gateway to CN: IP The packet flow from the MN to the CN is described below. The analysis assumes than the MN employs reverse tunneling to the HA (which is the MIP Proxy in this case) and that packets are routed via a FA. From the MN to the FA: +-------------------------------------------------------------+ |IP-S=MN-Perm |IP-S=MN-Perm |IPsec-ESP |IP-S=MN-Perm| Data |Adrangi, Iyer Expires Nov 2002 [Page 21] Internet Draft draft-adrangi-mobileip-natvpn-traversal-00 Nov 2001|IP-D=MIPP-Pub|IP-D=VPNGW-Pub|MN-Perm to|IP-D=CN | | | | |VPNGW-Pub | | | +-------------------------------------------------------------+ Adrangi, Iyer Expires August 2002 [Page 14] Internet Draft draft-adrangi-mobileip-natvpn-traversal-01 Feb 2002 In this case, the layer-2 destination address is set to the MAC address of the FA. From the FA to the MIP Proxy: +-------------------------------------------------------------+ |IP-S=FA COA |IP-S=MN-Perm |IPsec-ESP |IP-S=MN-Perm| Data | |IP-D=MIPP-Pub|IP-D=VPNGW-Pub|MN-Perm to|IP-D=CN | | | | |VPNGW-Pub | | | +-------------------------------------------------------------+ Clearly, the FA does not need to know the IPsec tunnel SA to process the packet. From the MIP Proxy to the VPN gateway: The MIP Proxy strips off the outermost IP header and forwards the packet to the VPN gatewayÆs outer interface using the layer-2 address corresponding to VPNGW-Pub. +-----------------------------------------------+ |IP-S=MN-Perm |IPsec-ESP |IP-S=MN-Perm| Data | |IP-D=VPNGW-Pub|MN-Perm to|IP-D=CN | | | |VPNGW-Pub | | | +-----------------------------------------------+ From the VPN gateway to the CN: The VPN gateway completes IPsec tunnel processing on the packet, strips off the outermost IP and ESP headers and forwards the encapsulated IP datagram to the CN. +---------------------+ |IP-S=MN-Perm| Data | |IP-D=CN | | +---------------------+6.5.2.2.5.5.2.2. MIPv4 Data Traffic from CN to MN The outbound MIPv4 data traffic destined to the MNÆs co-located address is always tunneled to the MIP Proxy (which appears as a surrogate MN to the actual HA). The MIP Proxy forwards the inner IP packet (with MN-Perm as the destination address) to the VPN gateway. The VPN gateway applies the IPsec ESP tunnel SA on the packet. The VPN gateway forwards the packet back to the MIP Proxy on its MIPP-Pub interface û this is accomplished by a routing table update on the VPN gateway. The MIP Proxy in turn tunnels the IPsecÆed packet to the MNÆs COA. The railroad diagram depicts the packet flow sequence, followed by a description of packets as they traverse the network. Adrangi, Iyer Expires August 2002 [Page 15] Internet Draft draft-adrangi-mobileip-natvpn-traversal-01 Feb 2002 MN FA MIP Proxy VPN Gateway HA CN | | | | | | | | | | | <------ | | | | <------------------------- | | | | | -----------> | | |Adrangi, Iyer Expires Nov 2002 [Page 22] Internet Draft draft-adrangi-mobileip-natvpn-traversal-00 Nov 2001| | | <----------- | | | | | <------ | | | | | <--- | | | | | From the HA to the MIP Proxy: IP-IP From the MIP Proxy to the VPN gateway: IP From the VPN gateway to the MIP Proxy: IP-ESP-IP From the MIP Proxy to the MN: IP-IP-ESP-IP The packet flow from the CN to the MN is described below. From the CN to the actual HA: +---------------------+ |IP-S=CN | Data | |IP-D=MN-Perm| | +---------------------+ TheCN sets the layer-2 destination address to that ofpacket is intercepted by the actualHA.HA, as the MN has moved outside its home subnet. From the actual HA to the MIP Proxy: +------------------------------------+ |IP-S=HA |IP-S=CN | Data | |IP-D=MIPP-Priv|IP-D=MN-Perm| | +------------------------------------+ From the MIP Proxy to the VPN gateway: The MIP Proxy strips off the outermost IP header and forwards the packet to the VPNGW-Priv interface using the corresponding layer-2 address. +---------------------+ |IP-S=CN | Data | |IP-D=MN-Perm| | +---------------------+ From the VPN gateway to the MIP Proxy: The VPN gateway applies an IPsec ESP tunnel SA to the IP packet and forwards it back to the MIP Proxy on the MIPP-Pub interface based on its routing table. +-------------------------------------------------+ |IP-S=VPNGW-Pub|IPsec-ESP |IP-S=CN | Data | |IP-D=MN-Perm |VPNGW-Pub to|IP-D=MN-Perm| | | |MN-Perm | | | +-------------------------------------------------+ From the MIP Proxy to the FA: The MIP Proxy adds an outer encapsulating IP header to the FA COA. Adrangi, Iyer Expires August 2002 [Page 16] Internet Draft draft-adrangi-mobileip-natvpn-traversal-01 Feb 2002 +--------------------------------------------------------+ |IP-S=MIPP-Pub|IP-S=VPNGW-Pub|IPsec-ESP |IP-S=CN | Data| |IP-D=FA COA |IP-D=MN-Perm |VPNGW-Pub to|IP-D= | | | | |MN-Perm | MN-Perm| | +--------------------------------------------------------+Adrangi, Iyer Expires Nov 2002 [Page 23] Internet Draft draft-adrangi-mobileip-natvpn-traversal-00 Nov 2001From the FA to the MN: The FA strips off the outermost IP header and forwards the packet to the MN. +-------------------------------------------------+ |IP-S=VPNGW-Pub|IPsec-ESP |IP-S=CN | Data | |IP-D=MN-Perm |VPNGW-Pub to|IP-D=MN-Perm| | | |MN-Perm | | | +-------------------------------------------------+ The MN terminates the IPsec tunnel and processes the MIPv4 data as always.6.5.3.5.5.3. Support For Route Optimization The MIP Proxy MUST NOT support Route Optimization[ROUTE-OPT].[10]. However, Route Optimization between the correspondent node and the mobile nodeÆs actual HA MAY be implemented.6.6.5.6. Key Management and SA Preservation The scheme described in the previous section binds the IPsec tunnel SA to the normally invariant permanent (home) IP address of the MN. This implies that the tunnel SA can be preserved even when the MN changes its co-located COA or connects via a FA in a different IP subnet. The SA however must be refreshed prior to its lifetime expiration. Also, many VPN gateway implementations support some keep-alive mechanism to detect the presence of a VPN client and ôretireö the SA if the VPN client is not detected for a period of time. If a MN loses link connectivity for a period extending the keep-alive timeout interval, it MUST reestablish the tunnel SA, regardless of whether it reconnects to the same IP subnet or not. The scheme also preserves any secondary authentication mechanisms that may be in the place to authenticate a remote access user.6.7.5.7. DMZ and VPN Gateway Configuration Requirements The solution described in this section makes the following assumptions on the configurability of the VPN gateway and the DMZ ACLs: - It MUST be possible to configure the VPN gatewayÆs routing table to deliver the outbound IPsecÆed MIPv4 packets destined to MN-Perm to the MIP ProxyÆs MIP-Pub interface, if MIP Proxy is not co-located with the VPN gateway. Adrangi, Iyer ExpiresNovAugust 2002 [Page24]17] Internet Draftdraft-adrangi-mobileip-natvpn-traversal-00 Nov 2001draft-adrangi-mobileip-natvpn-traversal-01 Feb 2002 - The outer firewall MUST allow inbound tunneled IP packets destined to the MIP Proxy - The MIP Proxy MUST be able to forward packets (destined to MN) to VPN gateway via layer 2 mechanism. This implies that the MIP Proxy and VPN Gateway MUST be on the same subnet.6.8.5.8. Supporting Other IPsec-based VPN Configurations The scheme currently described in this draft assumes a native IPsec VPN scheme extended to support secondary authentication schemes. However the solution should apply to L2TP over IPsec transport[RFC3193][12] and ESP-in-UDP VPN[ESPInUDP][13] configurations as well.6.9.5.9. Considerations for Integrating the MIP Proxy and VPN Gateway The MIP Proxy as described in this draft is a logical functional component and as such can be deployed in the DMZ in one of 2 possible ways: - As a standalone device in parallel with the VPN gateway as depicted in Figure 6.0. This decouples support for MIPv4 users from any software or hardware upgrades to the VPN gateway itself and also enables multi-vendor interoperability. The scheme however adds some overhead to the end-to-end communication path between a MN and a CN and requires minimal support from the VPN gateway software (i.e. a mechanism to make routing table updates). - Integrated as a software component with the VPN gateway. This clearly reduces the communication overhead but tightly couples support for MIPv4 users with any software upgrades to the VPN gateway itself.6.10.5.10. Association Between VPN Inner and MN Home IP Address TO support continuous mobility and constant reachability, the tunnel inner IP address assigned to a MN MUST be the same as the home IP address.7. Using the MIP Proxy for combined NAT6. MIPv4 Traversal Through IPsec ôNAT and VPNö Gateways This section extends MIPv4 VPNTraversal The discussiontraversal solution described inthe draft would be incomplete without describing a scenariosection 5 to support MIPv4 traversal across ôNAT and VPNö scenario, in whichaMNroams into a foreign NATÆed network andhas toconnect backtraverse one or more NAT gateway(s) followed by a VPN gateway in the path toitÆs home network whichits final destination. A solution for MIPv4 traversal across intervening NAT gateways isbehind a DMZ. Many Enterprises are deploying wireless LANs as a private NATÆed network outside their DMZ û users that roam into suchprovided in [11] through anetwork willMN/HA protocol extension. The solution cannot beforced to VPN back into their Intranet. Such a scenariodirectly applied here, since the MNÆs home agent is not directly reachable. However, the solution can besupported withleveraged by simply corresponding the MIP Proxyenabling simultaneous NAT and VPN traversal.surrogate HA to the HA in [11]. Adrangi, Iyer Expires August 2002 [Page 18] Internet Draft draft-adrangi-mobileip-natvpn-traversal-01 Feb 2002 Thenetwork configuration would befollowing sub-sections show MIPv4 control and data packets flow between acombination of Figures XMN andY. The analysis assumes that there is no FA in the NATÆed network. 7.1.a CN. 6.1. MIPv4 Registration Message Flow7.1.1.6.1.1. MIPv4 Registration RequestsAdrangi, Iyer Expires Nov 2002 [Page 25] Internet Draft draft-adrangi-mobileip-natvpn-traversal-00 Nov 2001From the MN to the NAT gateway: +-----------------------------------------------+ |IP-S=MN-Perm | Permanent Address = MN-Perm | |IP-D=MIPP-Pub | Home Agent = MIPP-Pub | | | Care-of Address =NATGW-PubMN-COA | | | . . . | +-----------------------------------------------+ Pleasesee the discussion in section 5 for possible mechanisms for a MNrefer todeterminesection 4.5 and theNAT gatewayÆs external (public) routable IP address.[11] draft for detailed discussion of required registration extensions. From the NAT gateway to the MIP Proxy: The NAT gateway performs source address and source UDP port translation before forwarding the packet to the MIP Proxy. +-----------------------------------------------+ |IP-S=NATGW-Pub | Permanent Address = MN-Perm | |IP-D=MIPP-Pub | Home Agent = MIPP-Pub | | | Care-of Address =NATGW-PubMN-COA | | | . . . | +-----------------------------------------------+ From the MIP Proxy to the actual HA: The MIP Proxy terminates and authenticates the registration request (as described in previous sections). It then creates a new registration request and forwards it to the actual HA. +-----------------------------------------------+ |IP-S=MIPP_Priv | Permanent Address = MN-Perm | |IP-D=HA | Home Agent = HA | | | Care-of Address = MIPP-Priv | | | . . . | +-----------------------------------------------+7.1.2.6.1.2. MIPv4 Registration Replies From the actual HA to the MIP Proxy: +-------------------------------------+ |IP-S=HA | Home Agent = HA | |IP-D=MIPP-Priv | . . . | +-------------------------------------+ From the MIP Proxy to the NAT gateway: +--------------------------------------+ |IP-S=MIPP-Pub | Home Agent = MIPP-Pub| |IP-D=NATGW-Pub | . . . | +--------------------------------------+ Adrangi, Iyer Expires August 2002 [Page 19] Internet Draft draft-adrangi-mobileip-natvpn-traversal-01 Feb 2002 From the NAT gateway to the MN: +----------------------------------------+ |IP-S=NATGW-Priv | Home Agent = MIPP-Pub | |IP-D=MN COA | . . . |Adrangi, Iyer Expires Nov 2002 [Page 26] Internet Draft draft-adrangi-mobileip-natvpn-traversal-00 Nov 2001+----------------------------------------+7.2.6.2. MIPv4 Data Flow Reverse tunneling is assumed in the packet flow descriptions that follow.7.2.1.6.2.1. Data Flow from the MN to the CN From MN to the NAT gateway: +--------------------------------------------------------+ |IP-S= | UDP|IP-S= |IPsec-ESP |IP-S=MN-Perm| Data | | MN-Priv | |MN-Perm | | | | |IP-D= | |IP-D= |MN-Perm to|IP-D=CN | | |MIPP-Pub | |VPNGW-Pub | VPNGW-Pub| | | +--------------------------------------------------------+ From the NAT gateway to the MIP Proxy: +----------------------------------------------------------+ |IP-S= | UDP |IP-S= |IPsec-ESP |IP-S=MN-Perm| Data | |NATGW-Pub | | MN-Perm | | | | |IP-D= | |IP-D= |MN-Perm to|IP-D=CN | | |MIPP-Pub | |VPNGW-Pub |VPNGW-Pub | | | +----------------------------------------------------------+ From the MIP Proxy to the VPN gateway: +-----------------------------------------------+ |IP-S=MN-Perm |IPsec-ESP |IP-S=MN-Perm| Data | |IP-D=VPNGW-Pub|MN-Perm to|IP-D=CN | | | |VPNGW-Pub | | | +-----------------------------------------------+ From the VPN gateway to the CN: +---------------------+ |IP-S=MN-Perm| Data | |IP-D=CN | | +---------------------+7.2.2.6.2.2. Data Flow from the CN to the MN From the CN to the actual HA: +---------------------+ |IP-S=CN | Data | |IP-D=MN-Perm| | +---------------------+ Adrangi, Iyer Expires August 2002 [Page 20] Internet Draft draft-adrangi-mobileip-natvpn-traversal-01 Feb 2002 From the actual HA to the MIP Proxy: +------------------------------------+ |IP-S=HA |IP-S=CN | Data | |IP-D=MIPP-Priv|IP-D=MN-Perm| | +------------------------------------+ From the MIP proxy to the VPN gateway:Adrangi, Iyer Expires Nov 2002 [Page 27] Internet Draft draft-adrangi-mobileip-natvpn-traversal-00 Nov 2001The MIP proxy strips off the outer IP header and forwards the packet on the layer-2 address for VPNGW-Priv. +---------------------+ |IP-S=CN | Data | |IP-D=MN-Perm| | +---------------------+ From the VPN gateway to the MIP Proxy: +-------------------------------------------------+ |IP-S=VPNGW-Pub|IPsec-ESP |IP-S=CN | Data | |IP-D=MN-Perm |VPNGW-Pub to|IP-D=MN-Perm| | | |MN-Perm | | | +-------------------------------------------------+ From the MIP Proxy to the NAT gateway: +----------------------------------------------------------+ |IP-S= | UDP |IP-S=VPNGW-Pub|IPsec-ESP |IP-S=CN| Data | |MIPP-Pub | | | | | | |IP-D= | |IP-D=NM-Perm |VPNGW-Pub to|IP-D= | | |NATGW-Pub| | | |MN-Perm| | | | | |MN-Perm | | | +----------------------------------------------------------+ From the NAT gateway to MN: +------------------------------------------------------------+ |IP-S= | UDP |IP-S= |IPsec-ESP |IP-S=CN |Data | |NATGW-Priv| |VPNGW-Pub | | | | |IP-D= | |IP-D= |VPNGW-Pub to|IP-D=MN-Perm| | |MN-Priv | |NM-Perm | MN-Perm | | | | | | | | | | +------------------------------------------------------------+8.7. MIP Proxy Considerations8.1.7.1. Handling Simultaneous Mobility Bindings The MIP proxy MUST support simultaneous mobility bindings, regardless of if a MNÆs actual HA supports this feature or not. When a Registration Request with an æSÆ bit set (i.e. simultaneous binding requested by a MN) is received, the MIP proxy MUST relay the Registration Request as described in section 4.0, but it MUST set the lifetime value in the relayed Registration Request to the maximum of the remaining lifetime Adrangi, Iyer Expires August 2002 [Page 21] Internet Draft draft-adrangi-mobileip-natvpn-traversal-01 Feb 2002 values of all existing mobility bindings for this MN and the lifetime value of the new Registration Request received from the MN. Any subsequent Registration Request refreshes received for any of the existing simultaneous mobility bindings MUST follow the same rule with respect to setting the lifetime value in the Registration Request to be relayed to the MNÆs actual home agent.Adrangi, Iyer Expires Nov 2002 [Page 28] Internet Draft draft-adrangi-mobileip-natvpn-traversal-00 Nov 2001When the Registration Reply is received from the MNÆs actual HA, the lifetime value in the mobility bindings list for this MN MUST be set to the lesser value of the accepted lifetime (reflected in the Registration Reply) and the existing lifetime (the request lifetime through the Registration Request) in the mobility bindings list of the MIP proxy.8.2.7.2. Handling Mobile IP NAI Extension The MIP proxy MUST support the Mobile IP NAI extension,defined by [RFC2290]. If the Home Address field is zerospecified in [14]. Upon detection of a NAI extension in the Registration Request received from a MN, the MIP proxy MUST record the NAI in its mobility bindings list for this MN. - If the MIP Proxy receives a Registration Request with a value of zero in the Home Address field and no NAI extension, it MUST return a Registration Reply with an error code indicatingMISSING_NAI,ôMISSING_NAIö, as defined in[RFC2290].[14]. - If the Registration Reply from the MNÆs actual HA does not include the Mobile Node NAI extension, the MIP proxyMUST relaySHOULD send the Registration Reply to the mobile node with an error code indicatingMISSING_NAI,ôMISSING_NAIö, as defined in[RFC2290].[14]. - If the Registration Reply from the MNÆs actual HA includes a zero Home Address, the MIP proxyMUST relaySHOULD send the Registration Reply to the mobile node with an error code indicatingMISSING_HOME_AGENT,ôMISSING_HOMEADDRö, as defined in[RFC2290]. 8.3.[14]. 7.3. Dynamic HA Assignment The MIP proxy can support dynamic HA assignment in conjunction with dynamic home address assignment for a MN. If the MN sends a Registration Request with the Home Agent field set to zero in the Parameter Registration Request Extension and includes a valid NAI extension, the MIP Proxy can dynamically assign a HA from a pool of HA IP addresses. The selection of a HA is beyond the scope of this draft. The selected HA MUST support the NAI extension in the Registration Request. However, this scheme is NOT intended to support dynamic HA handovers.9.8. Security Implications The MIP Proxy is a functional entity that MUST be implemented on a secure device especially if it is deployed in the DMZ. The Adrangi, Iyer Expires August 2002 [Page 22] Internet Draft draft-adrangi-mobileip-natvpn-traversal-01 Feb 2002 MIP Proxy is assumed to belong to the same (security) administrative domain as the MN and the actual HA. The protocol extensions specified in the draft do not introduce any new vulnerabilities to the mobile IP protocol.10.9. Acknowledgements The authors would like to thank Mike Andrews, Changwen Liu and Ranjit Narjala of IntelCorporationCorporation, Sami Vaarala of Netseal, Qiang Zhang of Ecutel, Alexis Oliverean of Motorola for their review and feedback on this draft.Adrangi, Iyer Expires Nov 2002 [Page 29] Internet Draft draft-adrangi-mobileip-natvpn-traversal-00 Nov 2001 11.10. Patents Intel Corporation is in the process of filing one or more patent applications that may be relevant to this IETF draft. 11. Revision History 1) Initial Version 9/2001 2) Second Version 3/2002 + Modified the draft to meet requirements defined in [15] + General Clean up + Made changes to reflect comments/feedbacks from Sami Vaarala of Netseal, Qiang Zhang of Ecutel, Alexis Oliverean of Motorola 12. References[RFC2002][1] RFC20023220 û IP mobility support[RFC3024]for IPv4 [2] RFC 3024 û Reverse tunneling for mobile IP[RFC2004][3] RFC 2004 û Minimal encapsulation within IP[RFC1701][4] RFC 1701 û Generic Routing encapsulation[RFC2119][5] RFC 2119 - Key words for use in RFCs to Indicate Requirement Levels[RFC1918][6] RFC 1918 û Address Allocation for Private Internets[DHCP][7] RFC 2131 û Dynamic Host Configuration Protocol[MIPv4-SEC-GUIDE][8] <draft-bpatil-mobileip-sec-guide-01.txt> - Requirements / Implementation Guidelines for Mobile IP using IP Security[LOCAL-LINK] û[9] <draft-ietf-zeroconf-ipv4-linklocal-03> - Dynamic Configuration of Iv4 Link-Local Addresses[ROUTE-OPT] û[10] <draft-ietf-mobileip-optim-10.txt> - Route Optimization in Mobile IP[MIP-NAT] û <draft-levkowetz-vaarala-mobileip-nat-traversal- 00.txt>[11] <draft-ietf-mobileip-nat-traversal-00.txt> - Mobile IP NAT/NAPT Traversal using UDP Tunneling[RFC3193][12] RFC 3193 û Securing L2TP with IPsec[ESPInUDP] -[13] <draft-ietf-ipsec-udp-encaps-00> - UDP Encapsulation of IPsec Packets[RFC 2290] -[14] Mobile-IPv4 Configuration Option for PPP IPCP [15] <draft-adrangi-mobileip-nat-vpn-problem-stat-req-00.txt> Problem Statement and Requirements for Mobile IPv4 Traversal Across VPN or ôNAT and VPNö Gateways Adrangi, Iyer Expires August 2002 [Page 23] Internet Draft draft-adrangi-mobileip-natvpn-traversal-01 Feb 2002 Authors: Farid Adrangi Intel Corporation 2111 N.E. 25th Avenue Hillsboro, OR 97124 USA Phone: 503-712-1791 Email: farid.adrangi@intel.com Prakash Iyer Intel Corporation 2111 N.E. 25th Avenue Hillsboro, OR 97124 USA Phone: 503-264-1815 Email: prakash.iyer@intel.com Adrangi, Iyer ExpiresNovAugust 2002 [Page30]24] ----