Internet DRAFT - draft-adrangi-mobileip-natvpn-traversal

draft-adrangi-mobileip-natvpn-traversal




   Internet Engineering Task Force                      Farid Adrangi 
   INTERNET DRAFT                                       Prakash Iyer 
   <draft-adrangi-mobileip-natvpn-traversal-01>         Intel Corp. 
   Date:    February 23 2002 
   Expires: August 2002 
    
    
          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 
         
        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 
  
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 traversal when needed. The solution has no 
        link layer dependencies and can be applied to other 802.3-
        compatible wired and wireless physical media as well.   
    
    
   Table Of Contents 
   1. Introduction....................................................3 
   2. Terminology.....................................................3 
   3. Acronyms........................................................4 
   4. An Overview of the MIP Proxy....................................4 
   4.1. Surrogate MN Functionality....................................5 
   4.1.1. Registration Request Process................................5 
   4.1.2. MN Functions Not Performed By The MIP Proxy.................6 
   4.2. Surrogate HA Functionality....................................6 
   4.2.1. Registration Request Process................................7 
   4.2.2. Registration Reply Process..................................7 
   4.2.3. HA Functions Not Performed By The MIP Proxy.................7 
   4.4. Discovering the MNÆs actual HA by the MIP Proxy...............8 
   4.5.  Parameter Registration Request Extension....................8 
   4.6. Deploying a MIP Proxy.........................................9 
   4.7. Discovering a MIP Proxy.......................................9 
   4.8. MIP Proxy Redundancy..........................................9 
   5. MIPv4 Traversal Through IPsec VPN Gateways......................9 
   5.1. IPsec VPN Traversal Problem Statement........................10 
   5.2. Integration of MIPv4 and IPsec...............................10 
   5.3. Assumptions and Applicability................................11 
   5.4. Solution Considerations......................................11 
   5.5. Deploying the MIP Proxy to support VPN Traversal.............11 
   5.5.1. Mobile IPv4 Registration...................................11 
   5.5.1.1. MIPv4 Registration Request Packet Flow from MN to HA.....12 
   5.5.1.2. MIPv4 Registration Reply Packet Flow from HA to MN.......12 
   5.5.1.3. DMZ Configuration Requirements for MIPv4 Registration 
   Packets...........................................................13 
   5.5.2. Mobile IPv4 Data Processing................................13 
   5.5.2.1. MIPv4 Data Traffic from MN to CN.........................14 
   5.5.2.2. MIPv4 Data Traffic from CN to MN.........................15 
   5.5.3. Support For Route Optimization.............................17 
   5.6. Key Management and SA Preservation...........................17 
   5.7. DMZ and VPN Gateway Configuration Requirements...............17 
   5.8. Supporting Other IPsec-based VPN Configurations..............18 
   5.9. Considerations for Integrating the MIP Proxy and VPN Gateway.18 
   5.10. Association Between VPN Inner and MN Home IP Address........18 
   6. MIPv4 Traversal Through IPsec ôNAT and VPNö Gateways...........18 
   6.1. MIPv4 Registration Message Flow..............................19 
   6.1.1. MIPv4 Registration Requests................................19 
   6.1.2. MIPv4 Registration Replies.................................19 
   6.2. MIPv4 Data Flow..............................................20 
   6.2.1. Data Flow from the MN to the CN............................20 
   6.2.2. Data Flow from the CN to the MN............................20 
   7. MIP Proxy Considerations.......................................21 
  
Adrangi, Iyer            Expires August 2002                 [Page 2] 

Internet Draft  draft-adrangi-mobileip-natvpn-traversal-01    Feb 2002 
 
 
   7.1. Handling Simultaneous Mobility Bindings......................21 
   7.2. Handling Mobile IP NAI Extension.............................22 
   7.3. Dynamic HA Assignment........................................22 
   8. Security Implications..........................................22 
   9. Acknowledgements...............................................23 
   10. Patents.......................................................23 
   11. Revision History..............................................23 
   12. References....................................................23 
    
    
   1. Introduction  
         
        The problem statement and solution requirements for MIPv4 
        traversal across VPN or ôNAT and VPNö gateways are articulated 
        in [15].  To help understand the motivation and rational 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 across VPN or ôNAT 
        and VPNö gateways, without requiring any IPsec VPN protocol 
        changes to 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. 
         
        The important sections of this draft are organized as follows: 
        Section 4 describes the MIP proxy component. 
        Section 5 discusses the MIP Proxy for MIPv4 traversal through 
        IPsec VPN Gateways  
        Section 6 discusses the MIP Proxy for MIPv4 traversal through 
        ô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 
        [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 
        [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 MN 
        MIPP-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 and 
        its 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  |   | +----+ +-----+ +----+     | 
         . . .            |Proxy |<->| |HA-1| | HA-2| |HA-n|     | 
        +---+             |      |   | +----+ +-----+ +----+     |  
        |MN |             |      |   |                           | 
        +---+             +------+   | +----+ +-----+ +----+     |  
        +---+                        | |FA-1| | FA-2| |FA-n|     | 
        |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 for VPN or ôNAT and VPNö gateways.  
         
        The MIP Proxy will nominally run on a dual-homed host. It MAY 
        be possible to instantiate the MIP Proxy on a singly homed host 
        - however in this document we assume that the MIP Proxy is 
        instantiated on a dual-homed host. The MIP Proxy may 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 the 
        intranet 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 the exceptions 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 [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Æ bit 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, 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 Proxy 
 
       The MIP proxy MUST NOT perform the following functions, as 
       specified by [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 [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 [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 [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.  
         
        - 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 [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 [10] 
         
   4.3. Registration Binding Table 
         
        The MIP Proxy MUST maintain a mobility binding list similar to 
        the one specified in [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 [1] for 
        deleting or retiring the entries in its mobility-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 MIP 
        Proxy 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 the extension, 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 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.  
 
   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. 
         
   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 ----- |    | +----+        | 
                                                      +---------------+ 
         
        Figure 5.0 û MN moves from its home network to a foreign 
        network outside the DMZ 
    
   5.1. IPsec VPN Traversal Problem Statement  
         
        With respect to Figure 5.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.   
          
   5.2. Integration of MIPv4 and IPsec 
         
        Clearly there are several schemes to apply IPsec to MIPv4 
        packets. [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 applied ô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 operation MUST 
        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. 
    
   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 that 
        meets the requirements specified in [15]. 
         
   5.5. Deploying the MIP Proxy to support VPN Traversal 
         
        As shown in Figure 5.0, the MIP Proxy is deployed in parallel 
        to an existing VPN gateway in the DMZ to support MIPv4.  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.  
         
        A railroad diagram illustrating the MIPv4 registration process 
        is shown below.  
    
                MN              MIP Proxy       HA 
                |Reg. Request   |               | 
                |-------------> |               | 
                |               |Reg. Request   | 
                |               |-------------> | 
                |               |Reg. Reply     | 
                |               |<------------- | 
                |Reg. Reply     |               | 
                |<--------------|               | 
    
                Figure 5.5.1 û Mobile IP registration protocol between  
                               MN and HA 
     
   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       | 
                |                 |     . . .                      | 
                +--------------------------------------------------+ 
        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    | 
                |                 |                                | 
                +--------------------------------------------------+ 
    
   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   |  . . .                      | 
                +-----------------------------------------------+ 
    
   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. 
 
   5.5.2. Mobile IPv4 Data Processing 
         
        There are two steps that MUST be successfully completed in 
        order to establish secured MIPv4 traffic between a MN and a CN.  
         
        The first 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 in Figure 5.5.2b. Any subsequent registration 
        and SA refreshes may occur independent of each other. 
 
 
 
 
 
 
 
 
 
 
  
Adrangi, Iyer            Expires August 2002                [Page 13] 

Internet Draft  draft-adrangi-mobileip-natvpn-traversal-01    Feb 2002 
 
 
                MN              MIP Proxy       VPN Gateway 
                |  IKE-Phase 1/MIPv4                     | 
                | -------------->   | IKE-phase 2        | 
                |                   |----------------->  | 
                |                   | IKE-phase 2        |          
                |  IKE-Phase 2/MIPv4|<-------------------| 
                | <---------------- |                    | 
         
                Figure 5.5.2b û IPsec Tunnel SA Establishment 
 
         
        The data forwarding is described in the following 2 sub-
        sections. 
                 
   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   | 
        |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     |        | 
        +---------------------+ 
    
   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 
        |       |          |                |           |         | 
        |       |          |                |           | <------ | 
        |       |          | <------------------------- |         | 
        |       |          | ----------->   |           |         | 
        |       |          | <-----------   |           |         | 
        |       | <------  |                |           |         | 
        | <---  |          |                |           |         | 
         
         
        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|        | 
        +---------------------+ 
         
        The packet is intercepted by the actual 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|     |     
        +--------------------------------------------------------+ 
         
        From 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. 
    
   5.5.3. Support For Route Optimization 
         
        The MIP Proxy MUST NOT support Route Optimization [10].  
        However, Route Optimization between the correspondent node and 
        the mobile nodeÆs actual HA MAY be implemented. 
    
   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. 
    
   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            Expires August 2002                [Page 17] 

Internet Draft  draft-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. 
    
   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 [12] and ESP-in-UDP VPN [13] configurations as well.  
    
   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. 
         
   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.  
    
   6. MIPv4 Traversal Through IPsec ôNAT and VPNö Gateways 
         
        This section extends MIPv4 VPN traversal solution described in 
        section 5 to support MIPv4 traversal across ôNAT and VPNö 
        scenario, in which MN has to traverse one or more NAT 
        gateway(s) followed by a VPN gateway in the path to its final 
        destination. 
         
        A solution for MIPv4 traversal across intervening NAT gateways 
        is provided in [11] through a MN/HA protocol extension. The 
        solution cannot be directly applied here, since the MNÆs home 
        agent is not directly reachable. However, the solution can be 
        leveraged by simply corresponding the MIP Proxy surrogate HA to 
        the HA in [11].   
         

  
Adrangi, Iyer            Expires August 2002                [Page 18] 

Internet Draft  draft-adrangi-mobileip-natvpn-traversal-01    Feb 2002 
 
 
        The following sub-sections show MIPv4 control and data packets 
        flow between a MN and a CN. 
         
   6.1. MIPv4 Registration Message Flow 
   6.1.1. MIPv4 Registration Requests    
        From 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 = MN-COA      | 
                |               |   . . .                       | 
                +-----------------------------------------------+ 
        Please refer to section 4.5 and the [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 = MN-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   | 
                |               |     . . .                     | 
                +-----------------------------------------------+ 
    
   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     |      . . .            | 
                +----------------------------------------+ 
    
   6.2. MIPv4 Data Flow 
         
        Reverse tunneling is assumed in the packet flow descriptions 
        that follow. 
 
    
   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     |        | 
        +---------------------+ 
     
   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: 
        The 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    |            |     |    
        |          |     |           |            |            |     | 
        +------------------------------------------------------------+ 
    
   7. MIP Proxy Considerations 
    
   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.  
         
        When 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.   
    
   7.2. Handling Mobile IP NAI Extension 
    
        The MIP proxy MUST support the Mobile IP NAI extension, 
        specified 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 indicating 
        ôMISSING_NAIö, as defined in [14].  
         
        - If the Registration Reply from the MNÆs actual HA does not 
        include the Mobile Node NAI extension, the MIP proxy SHOULD 
        send the Registration Reply to the mobile node with an error 
        code indicating ôMISSING_NAIö, as defined in [14]. 
           
        - If the Registration Reply from the MNÆs actual HA includes a 
        zero Home Address, the MIP proxy SHOULD send the Registration 
        Reply to the mobile node with an error code indicating 
        ôMISSING_HOMEADDRö, as defined in [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. 
    
   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.   
    
   9. Acknowledgements 
    
        The authors would like to thank Mike Andrews, Changwen Liu and 
        Ranjit Narjala of Intel Corporation, Sami Vaarala of Netseal, 
        Qiang Zhang of Ecutel, Alexis Oliverean of Motorola for their 
        review and feedback on this draft. 
    
   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 
        [1] RFC 3220 û IP mobility support for IPv4 
        [2] RFC 3024 û Reverse tunneling for mobile IP 
        [3] RFC 2004 û Minimal encapsulation within IP  
        [4] RFC 1701 û Generic Routing encapsulation 
        [5] RFC 2119 - Key words for use in RFCs to Indicate 
        Requirement Levels 
        [6] RFC 1918 û Address Allocation for Private Internets 
        [7] RFC 2131 û Dynamic Host Configuration Protocol 
        [8] <draft-bpatil-mobileip-sec-guide-01.txt> - Requirements / 
        Implementation Guidelines for Mobile IP using IP Security 
        [9] <draft-ietf-zeroconf-ipv4-linklocal-03> - Dynamic 
        Configuration of Iv4 Link-Local Addresses  
        [10] <draft-ietf-mobileip-optim-10.txt> - Route Optimization in 
        Mobile IP 
        [11] <draft-ietf-mobileip-nat-traversal-00.txt> - Mobile IP 
        NAT/NAPT Traversal using UDP Tunneling  
        [12] RFC 3193 û Securing L2TP with IPsec 
        [13] <draft-ietf-ipsec-udp-encaps-00> - UDP Encapsulation of 
        IPsec Packets  
        [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            Expires August 2002                [Page 24]