Internet DRAFT - draft-adrangi-mobileip-nat-vpn-problem-stat-req

draft-adrangi-mobileip-nat-vpn-problem-stat-req




   Internet Engineering Task Force                      Farid Adrangi 
   INTERNET DRAFT                                       Prakash Iyer 
   Category: Informational                              Intel Corp. 
    
   <draft-adrangi-mobileip-nat-vpn-problem-stat-req-00>          
   Date:    January 2002 
    
    
        Problem Statement and Requirements for Mobile IPv4 Traversal 
        Across VPN or 'NAT and VPN' Gateways 
    
    
   Status of this Memo 
    
        This document is an Internet-Draft and is in full conformance 
        with all provisions of Section 10 of RFC2026. 
         
        Internet-Drafts are working documents of the Internet 
        Engineering Task Force (IETF), its areas, and its working 
        groups. Note that other groups may also distribute working 
        documents as Internet-Drafts. 
         
        Internet-Drafts are draft documents valid for a maximum of six 
        months and may be updated, replaced, or obsoleted by other 
        documents at any time. It is inappropriate to use Internet-
        Drafts as reference material or to cite them other than as "work 
        in progress." 
         
        The list of current Internet-Drafts can be accessed at 
        http://www.ietf.org/ietf/1id-abstracts.txt  
         
        The list of Internet-Draft Shadow Directories can be accessed at 
        http://www.ietf.org/shadow.html. 
         
        To view the entire list of current Internet-Drafts, please 
        check the "1id-abstracts.txt" listing contained in the 
        Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), 
        ftp.nordu.net (Northern Europe), ftp.nis.garr.it (Southern 
        Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East 
        Coast), or ftp.isi.edu (US West Coast). 
         
   Abstract 
         
        This draft describes the problem statement and specifies the 
        solution requirements for MIPv4 traversal across VPN or 'NAT 
        and VPN' gateways.  The 'NAT and VPN' case refers to a network 
        topology in which the MIPv4 traffic has to traverse one or more 
        NAT gateway(s) followed by a VPN gateway in the path to its 
        final destination.  Requirements and problems associated with 
        MIPv4 traversal through NAT gateways NOT involving VPNs is 
        outside the scope of this draft.  
         
    
   Table of Contents 
  
Expires August 2002.                                          [Page 1] 

Internet Draft  draft-adrangi-mobileip-nat-vpn-problem-stat-req-00
                             January 2002 
 
 
    
   1. Introduction....................................................2 
   2. Terminology.....................................................3 
   3. Acronyms........................................................3 
   4.0. Roaming Scenarios.............................................4 
   4.1. Roaming Inside the Home Network...............................5 
   4.2. Roaming Outside the Home Network..............................5 
   4.2.1. Roaming Outside the Home Network in a Routable Address Space 
   (where, FA-assisted routing is not used)...........................6 
   4.2.2 Roaming Outside the Home Network in Routable Address Space 
   (where, FA-assisted routing is used)...............................6 
   4.2.3 Roaming Outside the Home Network in a non-Routable Address 
   Space..............................................................7 
   5. Problem Statement...............................................8 
   5.1. MIPv4 Incompatibilities with VPN Gateways.....................8 
   5.2. MIPv4 Incompatibilities with NAT Gateways.....................9 
   6. The Requirements................................................9 
   6.1. Implications of Intervening NAT Gateways......................9 
   6.2. Implications of Cascaded NAT.................................10 
   6.3. MIPv4 Protocol...............................................10 
   6.5. Functional Entities..........................................10 
   6.6. Multi-vendor Interoperability................................10 
   6.7. Fast MIPv4 Handoffs..........................................10 
   6.8. Preservation of Existing VPN Infrastructure..................11 
   6.9. Preserve Existing DMZ Traversal Policies.....................11 
   6.10 Support For Route Optimization...............................11 
   6.11 MIPv4 Registration SA Management.............................11 
   6.12 Security Implications........................................11 
   7. References.....................................................11 
 
    
   1. Introduction  
    
        Multi-subnetted IEEE 802.11 WLAN networks are being widely 
        deployed in Enterprise Intranets - in many cases requiring a 
        VPN tunnel to connect back and access Intranet resources, and 
        public areas such as airports, coffee shops, convention centers 
        and shopping malls. Many of these WLAN networks also employ NAT 
        to translate between non-routable and routable IPv4 care-of 
        (point of attachment) addresses. WWAN networks such as those 
        based on GPRS and eventually EDGE and UMTS are also starting to 
        see deployment. These deployments are paving the way for 
        applications and usage scenarios requiring TCP/IP session 
        persistence and constant reachability while connecting back to 
        a secured (VPN protected), target 'home' network. This in turn 
        drives the need for a mobile VPN solution that is multi-vendor 
        interoperable, providing seamless access with persistent VPN 
        sessions and through NAT gateways when needed. This draft 
        identifies example usage scenarios, defines a problem statement 
        based on the scenarios and specifies requirements that MUST be 
        met to ensure broad deployment of multi-vendor interoperable 
        solutions.   
  
Adrangi, Iyer            Expires January 2002                 [Page 2] 

Internet Draft  draft-adrangi-mobileip-nat-vpn-problem-stat-req-00
                             January 2002 
 
 
  
        The important sections of this draft are organized as follows:  
             
            Section 4: Describe roaming scenarios to motivate the 
                       problem statement 
         
            Section 5: Describes a problem statement for MIPv4 
                       traversal across VPN and NAT gateways. 
         
           Section 6: Specifies the requirements for a solution to 
                       support multi-vendor seamless IPv4 mobility 
                       across VPN or the 'NAT VPN' gateways. 
    
   2. Terminology 
    
        Traditional NAT: 
        Network Address Translation.  "Traditional NAT would allow 
        hosts within a private network to transparently access hosts in 
        the external network, in most cases.  In a traditional NAT, 
        sessions are uni-directional, outbound from the private 
        network." ' [RFC2663]. Traditional NAT' are of two types: 
        Basic NAT and NAPT. 
         
        Basic NAT:  
        "With Basic NAT, a block of external addresses are set aside 
        for translating addresses of hosts in a private domain as they        
        originate sessions to the external domain.  For packets 
        outbound from the private network, the source IP address and 
        related fields such as IP, TCP, UDP and ICMP header checksums 
        are translated.  For inbound packets, the destination IP 
        address and the checksums as listed above are translated." Ż 
        [RFC2663] 
         
         
        NAPT: 
        Network Address Port Translation.  "NAPT extends the notion of   
        translation one step further by also translating transport 
        identifier (e.g., TCP and UDP port numbers, ICMP query 
        identifiers).  This allows the transport identifiers of a 
        number of private hosts to be multiplexed into the transport 
        identifiers of a single external address.  NAPT allows a set of 
        hosts to share a single external address.  Note that NAPT can 
        be combined with Basic NAT so that a pool of external addresses 
        are used in conjunction with port translation." Ż [RFC2663] 
         
   3. Acronyms 
        ACL: Access Control List 
        GRE: Generic Routing Encapsulation 
        MIPv4: Mobile IP for IPv4 
        MIPv6: Mobile IP for IPv6  
        VPN: Virtual Private Network 
         
  
Adrangi, Iyer            Expires January 2002                 [Page 3] 

Internet Draft  draft-adrangi-mobileip-nat-vpn-problem-stat-req-00
                             January 2002 
 
 
        MN-Perm: Permanent home address of the MN 
        MN-COA: Co-located care-of address of the MN 
        WLAN: IEEE 802.11 Wireless Local Area Network 
    
   4.0. Roaming Scenarios 
         
        This section describes roaming scenarios, wherein MIPv4 traffic 
        has to traverse VPN or the 'NAT and VPN' gateways.  The 
        scenarios are constructed based on a multi-subnetted MIPv4 
        enabled Intranet (hereafter, referred by Home Network or VPN 
        domain) protected by an IPsec-based VPN gateway as depicted in 
        Figure 4.0a.   
            
        +---------+       +------+   +---------------------------+ 
        |         |       |      |   |Home network / VPN Domain  | 
        |         |       |IPsec-|   | +----+ +-----+ +----+     | 
        |Internet |       |based |<->| |HA-1  | HA-2| |HA-n|     | 
        |         |       |      |   | +----+ +-----+ +----+     |  
        |         |       | VPN  |   |                           | 
        +---------+       +------+   | +----+ +-----+ +----+     |  
                                     | |FA-1| | FA-2| |FA-n|     | 
                                     | +----+ +-----+ +----+     |    
                                     |                           | 
                                     | +----+ +-----+ +-----+    | 
                                     | |MN-1| | MN-2| | MN-n|    | 
                                     | +----+ +-----+ +-----+    |  
                                     +---------------------------+ 
 
           Figure 4.0a Home Network protected by a VPN Gateway 
         
        The home network, depicted in Figure 4.0a, may include both 
        wired (IEEE 802.3) and IEEE 802.11 wireless LAN deployments.  
        However, it is also possible to see IEEE 802.11 deployments 
        outside the home network due to perceived lack of 802.1x 
        security, as depicted in Figure 4.0b.  
            
            
        +---------+       +------+   +---------------------------+ 
        |         |       |      |   |Home network / VPN Domain  | 
        |         |       |IPsec-|   | +----+ +-----+ +----+     | 
        |Internet |   |-->|based |<->| |HA-1| | HA-2| |HA-n|     | 
        |         |   |   |      |   | +----+ +-----+ +----+     |  
        |         |   |   | VPN  |   |                           | 
        +---------+   |   +------+   | +----+ +-----+ +----+     |  
                      |              | |FA-1| | FA-2| |FA-n|     | 
                      |              | +----+ +-----+ +----+     |    
           +-----------------+       |                           | 
           |                 |       | +----+ +-----+ +-----+    | 
           | 802.11 Wireless |       | |MN-1| | MN-2| | MN-n|    | 
           |  Network        |       | +----+ +-----+ +-----+    |  
           |                 |       +---------------------------+ 
           +-----------------+ 
  
Adrangi, Iyer            Expires January 2002                 [Page 4] 

Internet Draft  draft-adrangi-mobileip-nat-vpn-problem-stat-req-00
                             January 2002 
 
 
         
        Figure 4.0b' IEEE 802.11 Wireless deployment outside the home  
                     network 
         
        To help describe scenarios in the following sections, we have 
        used the aid of an imaginary nomadic user, called Dr. Joe. 
        Dr. Joe is a chief surgeon in a hospital, and always on the 
        move. He leverages his wireless MIPv4 enabled hand-held device 
        to access his patient' records, communicate with his 
        colleagues and staff, and stay reachable in case of any 
        emergencies.  For clarity, we assume that Dr. Joe' hospital 
        employs a network similar to the one showed in Figure 4.0a 
        (MIPv4 enabled network protected by a VPN, and includes both 
        wired and IEEE 802.11 wireless deployments). 
         
   4.1. Roaming Inside the Home Network  
    
        Dr. Joe' needs for constant reachablity and maintaining his 
        current transport connections as he roams from one network link 
        to another are met by standard MIPv4 deployment inside the home 
        network. Please note that NAT∆ed networks might be seen inside 
        the home network, however, draft-mobileip-nat-traversal-00.txt 
        solves the problem, as the mobile node's home agent will most 
        likely be directly reachable by the mobile node.  
 
   4.2. Roaming Outside the Home Network  
 
        Dr. Joe frequently visits other clinics and hospitals, in which 
        a multi-subnetted IEEE 802.11 hot spot network is utilized to 
        provide Internet access for visitors.  Dr. Joe leverages the 
        hot spot network to connect to his home network, and he would 
        also like to maintain his transport connections to the home 
        network as he roams from one network link to another in the hot 
        spot network.   
 
        This implies that the MIPv4 traffic destined to the home 
        network MUST run inside an IPsec tunnel (i.e, MIP/IP/ESP/IP) 
        established between the mobile node and the home network∆s VPN 
        gateway.  Moreover, the IPsec∆ed MIPv4 traffic may also have to 
        traverse a NAT gateway or a foreign agent in the path to the 
        VPN gateway.  The following sub-sections illustrate these 
        possibilities. 
 
 
 
 
 
 
 
 
 
 
  
Adrangi, Iyer            Expires January 2002                 [Page 5] 

Internet Draft  draft-adrangi-mobileip-nat-vpn-problem-stat-req-00
                             January 2002 
 
 
   4.2.1. Roaming Outside the Home Network in a Routable Address Space 
   (where, FA-assisted routing is not used) 
  
        +---------+       +------+   +---------------------------+ 
        |Internet |       |      |   |Home network /VPN Domain   | 
        |  |--------------|IPsec-|   | +----+ +-----+ +----+     | 
        |  |  |-----------|based |<->| |HA-1  | HA-2| |HA-n|     | 
        +--|--|---+       |VPN   |   | +----+ +-----+ +----+     |  
           |  |           +------+   |                           | 
           |  |                      | +----+ +-----+ +----+     |  
           |  |<-- IPsec Tunnel      | |FA-1| | FA-2| |FA-n|     | 
           |  |                      | +----+ +-----+ +----+     |    
           |  |                      |                           | 
       +---|--|---+                  | +----+ +-----+ +-----+    | 
       |   |  |   |                  | |MN-1| |MN-2 | |MN-n |    | 
       | +-|--|-+ |                  | +----+ +-----+ +-----+    | 
       | | MN   | |                  |                           |  
       | +------+ |                  +---------------------------+ 
       | Multi-   |   
       | Subnetted|                           
       | Hot Spot | 
       |          | 
       +----------+            
 
   4.2.2 Roaming Outside the Home Network in Routable Address Space 
   (where, FA-assisted routing is used) 
          
         There is a notion of trusted FA, where there is a SA 
         established between the FA and home VPN gateway.  In this 
         case, IPsec tunnel end-points are the FA and home VPN gateway.  
         Furthermore, It is also possible for the MN in a trusted FA 
         region to have end-to-end security with its home VPN gateway.  
         This implies that there will be two pairs of IPsec tunnels, 
         one between the FA and home VPN gateway, and the other between 
         the MN and its home VPN gateway. Figure 4.3.2a shows the MN in 
         a trusted FA region, where there is only an IPsec tunnel 
         between the FA and home VPN gateway. 
 
         In a non-trusted FA region, where there is no SA established 
         between the FA and home gateway, there will always be a single 
         IPsec tunnel established between the MN and its home VPN 
         gateway, as depicted in Figure 4.3.2b. 
 
 
 
 
 
 
 
 
 
 
  
Adrangi, Iyer            Expires January 2002                 [Page 6] 

Internet Draft  draft-adrangi-mobileip-nat-vpn-problem-stat-req-00
                             January 2002 
 
 
        +---------+       +------+   +---------------------------+ 
        |Internet |       |      |   |Home network /VPN Domain   | 
        |  |--------------|IPsec-|   | +----+ +-----+ +----+     | 
        |  |  ------------|based |<->| |HA-1  | HA-2| |HA-n|     | 
        +--|--|---+       |VPN   |   | +----+ +-----+ +----+     |  
           |  |           +------+   |                           | 
        +--|--|----+                 | +----+ +-----+ +----+     |  
        | +|--|+   |                 | |FA-1| | FA-2| |FA-n|     | 
        | | FA |   |                 | +----+ +-----+ +----+     |    
        | +----+   |                 |                           | 
        |          |                 | +----+ +-----+ +-----+    | 
        | +----+   |                 | |MN-1| |MN-2 | |MN-n |    | 
        | |MN  |   |                 | +----+ +-----+ +-----+    | 
        | +----+   |                 |                           |  
        | Multi-   |                 +---------------------------+ 
        | Subnetted|          
        | Hot Spot | 
        +----------+ 
 
        Figure 4.3.2a - the MN in trusted FA region 
 
 
 
        +---------+       +------+   +---------------------------+ 
        |Internet |       |      |   |Home network /VPN Domain   | 
        |  |--------------|IPsec-|   | +----+ +-----+ +----+     | 
        |  |  ------------|based |<->| |HA-1  | HA-2| |HA-n|     | 
        +--|--|---+       |VPN   |   | +----+ +-----+ +----+     |  
           |  |           +------+   |                           | 
        +--|--|----+                 | +----+ +-----+ +----+     |  
        | +|--|+   |                 | |FA-1| | FA-2| |FA-n|     | 
        | ||FA||   |                 | +----+ +-----+ +----+     |    
        | +|--|+   |                 |                           | 
        |  |  |<------- IPsec Tunnel | +----+ +-----+ +-----+    | 
        | +|--|+   |                 | |MN-1| |MN-2 | |MN-n |    | 
        | |MN  |   |                 | +----+ +-----+ +-----+    | 
        | +----+   |                 |                           |  
        | Multi-   |                 +---------------------------+ 
        | Subnetted|          
        | Hot Spot | 
        +----------+ 
 
        Figure 4.3.2b - the MN in non-trusted FA region 
 
 
   4.2.3 Roaming Outside the Home Network in a non-Routable Address 
   Space  
    
         Note that the MN's home agent is not directly reachable in 
         this case.  Therefore, draft-mobileip-nat-traversal-00.txt 
         cannot be directly applied.  Furthermore, cascaded NAT gateway 

  
Adrangi, Iyer            Expires January 2002                 [Page 7] 

Internet Draft  draft-adrangi-mobileip-nat-vpn-problem-stat-req-00
                             January 2002 
 
 
         deployment is also a possibility, but not shown in the 
         diagram. 
    
        +---------+       +------+   +---------------------------+ 
        | Internet|       |      |   |Home network /VPN Domain   | 
        |  ---------------|IPsec-|   | +----+ +-----+ +----+     | 
        |  |  ------------|based |<->| |HA-1  | HA-2| |HA-n|     | 
        +--|--|---+       |VPN   |   | +----+ +-----+ +----+     |  
           |  |           +------+   |                           | 
        +--|--|+                     | +----+ +-----+ +----+     |  
        | NAT ||                     | |FA-1| | FA-2| |FA-n|     | 
        +--|--|+                     | +----+ +-----+ +----+     |    
           |  |<------ IPsec Tunnel  |                           | 
        +--|--|----+                 | +----+ +-----+ +-----+    | 
        | +----+   |                 | |MN-1| |MN-2 | |MN-n |    | 
        | | MN |   |                 | +----+ +-----+ +-----+    | 
        | +----+   |                 |                           |  
        | Multi-   |                 +---------------------------+ 
        | Subnetted|              
        | Hot Spot | 
        +----------+ 
 
 
   5. Problem Statement 
         
        This section describes MIPv4 incompatibilities with IPsec-based 
        VPN and NAT gateways, in the context of the roaming scenarios 
        outlined in section 4. 
    
   5.1. MIPv4 Incompatibilities with VPN Gateways 
 
        There are two problems associated with MIPv4 and VPN 
        incompatibilities.  
         
        Problem 1: The MN could roam into a foreign subnet with a FA. 
        If the MN were to associate a VPN tunnel with its CoA, the FA 
        (which is likely in a different administrative domain) cannot 
        parse the IPsec tunnel SA and will not be able to setup SAs 
        with the MN's VPN gateway and will consequently be not able to 
        relay MIPv4 packets between the MN and the VPN gateway.   
        ` 
        Problem 2: The MN could roam into a foreign subnet without a FA 
        and obtain a CoA at its point of attachment (via [DHCP] or some 
        other means). In an end-to-end security model, an IPsec tunnel 
        that terminates at the VPN gateway MUST protect the IP traffic 
        originating at the MN. If the IPsec tunnel is associated with 
        the CoA, the tunnel SA MUST be refreshed after each IP subnet 
        handoff which could have some performance implications on real-
        time applications. 
 


  
Adrangi, Iyer            Expires January 2002                 [Page 8] 

Internet Draft  draft-adrangi-mobileip-nat-vpn-problem-stat-req-00
                             January 2002 
 
 
        It is important to note that only IPsec tunnel mode is 
        applicable here, as the mobile node connecting to the home 
        network MUST establish an IPsec tunnel SA to the VPN gateway. 
    
   5.2. MIPv4 Incompatibilities with NAT Gateways 
 
        There are also two problems associated with MIPv4 and NAT 
        incompatibilities: 
         
        Problem 1: When an MN roams from its 'home' network (which may 
        or may not be in a routable IP address space) protected by a 
        VPN to a foreign network behind a NAT gateway, it acquires a 
        non-routable care-of address (most likely through [DHCP]). The 
        acquired non-routable care-of address is passed to the HA 
        through a registration request.  This causes the MN to lose its 
        connectivity to its home network, since the HA will not be able 
        to forward the MN's packets to the non-routable care-of 
        address.  
 
        Problem 2: Even if we solve the first problem, an intervening 
        NAT gateway in a foreign network will not always be able to 
        demultiplex inbound IP-in-IP reverse tunneled MIPv4 data 
        packets.  Because, NAPT gateways will simply not be able to 
        route the inbound IP-in-IP packets, as they rely on IP address 
        and transport identifier to route the packets from routable to 
        non-routable address space or vice a versa. And, in the case of 
        Basic NAT, consider two MNs that are registered with the same 
        Home Agent (HA).  The inbound packets destined to the two MNs 
        from the HA will have the same source and destination IP 
        addresses ' making it difficult for the NAT to route the 
        packets inside. 
         
        The implications on Minimal IP [RFC2004] and GRE encapsulation 
        [RFC1701] modes of MIPv4 are similar to IP-in-IP tunneling. 
         
        Draft [MIP-NAT] describes a solution to the NAT traversal 
        problem when VPNs are not involved. In this draft, we only 
        discuss NAT traversal requirements where the HA is behind a VPN 
        gateway and hence not directly reachable by the MN. 
 
   6. The Requirements 
    
   This section describes the requirements that are intended to 
   establish a framework where in a solution can be developed to 
   support MIPv4 traversal across VPN or 'NAT and VPN' gateways. 
    
    
   6.1. Implications of Intervening NAT Gateways 
         
        - The solution MUST work with both Basic NAT and NAPT.  
         

  
Adrangi, Iyer            Expires January 2002                 [Page 9] 

Internet Draft  draft-adrangi-mobileip-nat-vpn-problem-stat-req-00
                             January 2002 
 
 
        - The solution MUST not require any configuration or software 
        changes to exiting NAT gateways.   
         
        The reason for the above constraints is to not limit the 
        solution to network topologies that employ certain types of NAT 
        gateways and to enable deployment of MIPv4 in networks that 
        have currently deployed non-modifiable NAT gateways. 
         
   6.2. Implications of Cascaded NAT  
         
        Cascaded NAT deployment is seen in some network topologies 
        (case in point, a residential NAT gateway connected to a NAT∆ed 
        ISP network). Therefore, the solution MUST support cascaded 
        NAT. 
    
   6.3. MIPv4 Protocol 
         
        - The solution MUST be compliant with MIPv4 protocol [RFC 
        3220]. 
        - The solution MAY introduce new extensions to MIPv4 protocol 
        per guidelines specified in the MIPv4 RFCs. However, it is 
        highly desirable to avoid any changes to MIPv4 mobility agents 
        such as the FA and HA in order to overcome barriers to 
        deployment. 
  
   6.5. Functional Entities 
         
        The solution MAY introduce a MIPv4 compliant functional entity 
        that helps MIPv4 traversal across VPN or the ŰNAT and VPNŲ 
        gateways. However, scalability, manageability and availability 
        implications introduced by that functional entity MUST be well 
        understood. The functional entity MAY be implemented as a 
        standalone entity or combined with another device such as a VPN 
        gateway. 
    
   6.6. Multi-vendor Interoperability 
    
        Multi-vendor interoperability is a key requirement. In most 
        Enterprises, MIPv4 mobility agents are likely to be deployed in 
        existing routers from vendor X while VPN client/server 
        solutions may come from vendor Y and mobility clients (MN) may 
        come from yet another vendor. Medium and large Enterprises that 
        typically purchase and deploy best-of-breed multi-vendor 
        solutions for IP routing, VPNs, firewalls etc. are unlikely to 
        revamp their infrastructure in favor of single-vendor end-to-
        end integrated solutions, preferring instead to reuse as much 
        of their deployed infrastructure as possible. The solution 
        proposed MUST enable such scenarios to be easily accommodated.  
 
   6.7. Fast MIPv4 Handoffs 
         

  
Adrangi, Iyer            Expires January 2002                [Page 10] 

Internet Draft  draft-adrangi-mobileip-nat-vpn-problem-stat-req-00
                             January 2002 
 
 
        It is imperative to keep the key management overhead down to a 
        minimum, in order to support fast handoffs across IP subnets. 
        Hence, the solution MUST propose a mechanism whereby the IPsec 
        tunnel SA can be bound to the invariant home IP address of the 
        MN and applicable to static and dynamic home address 
        assignment.  
         
   6.8. Preservation of Existing VPN Infrastructure 
         
        This implies the following: 
         
        - The solution MUST preserve the investment in existing VPN 
        gateways 
        - The solution MAY require software upgrades to VPN gateways to 
        explicitly support MIPv4 users 
  
        - The solution MUST preserves VPN security requirements that 
        are not inferior to what is already provided to existing 
        "nomadic computing" remote access users, i.e. for 
        confidentiality, primary and secondary authentication, message 
        integrity, protection against replay attacks and related 
        security services. 
   
   6.9. Preserve Existing DMZ Traversal Policies 
         
        The solution MUST be compatible with existing DMZ policies with 
        respect to ACLs.  
         
   6.10 Support For Route Optimization 
         
        MIPv4 route optimization is not widely supported, as it 
        requires changes to both MN's home agent and the correspondent 
        node.  Hence, The solution MAY or MAY NOT support MIPv4 Route 
        Optimization [ROUTE-OPT]. 
    
   6.11 MIPv4 Registration SA Management 
         
        Mechanisms to manage MIPv4 Registration SAs are outside the 
        scope of this draft. 
 
   6.12 Security Implications 
         
        The solution MUST NOT introduce any new vulnerabilities to the 
        MIPv4 protocol as specified in related RFCs.    
 
   7. References 
    
   [RFC3220] RFC 3220 ' IP mobility support for IPv4 
   [RFC3024] RFC 3024 ' Reverse tunneling for mobile IP 
   [RFC2004] RFC 2004 ' Minimal encapsulation within IP  
   [RFC1701] RFC 1701 ' Generic Routing encapsulation 

  
Adrangi, Iyer            Expires January 2002                [Page 11] 

Internet Draft  draft-adrangi-mobileip-nat-vpn-problem-stat-req-00
                             January 2002 
 
 
   [RFC2119] RFC 2119 - Key words for use in RFCs to Indicate 
   Requirement Levels 
   [RFC1918] RFC 1918 ' Address Allocation for Private Internets 
   [RFC2663] RFC 2663 - IP Network Address Translator (NAT) Terminology 
   and Considerations 
   [DHCP] RFC 2131 ' Dynamic Host Configuration Protocol 
   [MIPv4-SEC-GUIDE] draft-bpatil-mobileip-sec-guide-01.txt - 
   Requirements / Implementation Guidelines for Mobile IP using IP 
   Security 
   [[LOCAL-LINK] ' Dynamic Configuration of Iv4 Link-Local Addresses,  
                   <draft-ietf-zeroconf-ipv4-linklocal-03> 
   [ROUTE-OPT] ' Route Optimization in Mobile IP, <draft-ietf-mobileip- 
   optim-10.txt> 
   [MIP-NAT]' Mobile IP NAT/NAPT Traversal using UDP Tunneling, 
   <draft-mobileip-nat-traversal.00.txt> 
    
    
    
   Authors: 
    
   Farid Adrangi 
   Intel Corporation 
   2111 N.E. 25th Avenue 
   Hillsboro, OR  
   USA 
    
   Phone: 503-712-1791  
   Email: farid.adrangi@intel.com 
    
    
   Prakash Iyer     
   Intel Corporation 
   2111 N.E. 25th Avenue 
   Hillsboro, OR 
   USA 
    
   Phone: 503-264-1815 
   Email: prakash.iyer@intel.com 
    
 












  
Adrangi, Iyer            Expires January 2002                [Page 12]