[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

   Internet Engineering Task Force                      Farid Adrangi
   INTERNET DRAFT                                       Prakash Iyer
   <draft-adrangi-mipv4-midbox-traversal-00>            Intel Corp.
   Date:    July 2001
   Expires: January 2002


                Mobile IPv4 Traversal Across 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

        Wireless LANs or hot spots are starting to be widely deployed
        in Enterprise Intranets and public areas such as airports,
        coffee shops, shopping malls etc. based on IPv4. This combined
        with the availability of multi-mode networked devices and
        applications that can take advantage of continuous mobility and
        constant reachability, is driving the need for Mobile IP in
        these networks. At the same time, middleboxes (NAT and VPN
        gateways for example) are also seeing widespread usage. Mobile
        IPv4 has known functional and performance limitations in the
        presence of these middleboxes. This draft proposes a solution
        framework that enables seamless operation of Mobile IPv4 across
        middleboxes without requiring any changes to the middleboxes
        themselves. Although the solution is generically extensible,


Expires January 2002

[Page 1]


Internet Draft draft-adrangi-mipv4-midbox-traversal-00      July 2001


        the draft specifically focuses on NAT and VPN traversal. The
        solution has no link layer dependencies and can be applied to
        other 802.3-compatible physical media as well.


   Table Of Contents

   1. Introduction....................................................3
   2. Terminology.....................................................4
   3. Acronyms........................................................4
   4. The MIP Proxy...................................................4
   4.1. Surrogate MN Functionality....................................5
   4.2. Surrogate HA Functionality....................................5
   4.3. Deploying a MIP Proxy.........................................6
   4.4. Discovering a MIP Proxy.......................................6
   4.5. MIP Proxy Redundancy..........................................6
   5. MIPv4 Traversal Through NAT Gateways............................6
   5.1.  NAT Traversal Problem Statement..............................6
   5.2. Assumptions and Applicability.................................7
   5.3.  Using the MIP Proxy for NAT Traversal.......................8
   5.3.1.  When does a MN register with the MIP Proxy?................8
   5.3.1.1. Selection of the COA Field in the Registration Request
   Payload............................................................9
   5.3.1.2. Discovery Registration Extension.........................10
   5.3.2. MIPv4 registration protocol between MN and HA..............10
   5.3.2.1. Establishing UDP Tunnel Parameters for MIPv4 Data Traffic11
   5.3.2.2. Discovering the MNÆs actual home agent by the MIP Proxy..11
   5.3.2.3. Parameter Registration Extension.........................12
   5.3.2.4. MIPv4 Registration Request Packet Flow From MN to HA.....12
   5.3.2.5. MIPv4 Registration Reply Packet Flow From HA to MN.......13
   5.3.3. MIPv4 data traffic from MN to CN...........................14
   5.3.4. MIPv4 data traffic from CN to MN...........................15
   5.4. Summary of changes on MIPv4 components required by this
   solution..........................................................16
   5.4.1. Required Changes to a MN...................................16
   5.4.2. Required Configuration for the MIP Proxy...................16
   5.5. Performance Implications of MIP Proxy assisted NAT Traversal.16
   5.6. Implications of Twice NAT between the MN and MIP Proxy.......16
   6. MIPv4 Traversal Through IPsec VPN Gateways.....................16
   6.1. IPsec VPN Traversal Problem Statement........................17
   6.2. Integration of MIPv4 and IPsec...............................17
   6.3. Assumptions and Applicability................................18
   6.4. Solution Considerations......................................18
   6.4.1. Fast Handoffs..............................................18
   6.4.2. Preserve Existing VPN Infrastructure.......................18
   6.4.3. Preserve Existing DMZ Traversal Policies...................19
   6.5. Deploying the MIP Proxy to support VPN Traversal.............19
   6.5.1. Mobile IPv4 Registration...................................19
   6.5.1.1. MIPv4 Registration Request Packet Flow from MN to HA.....19
   6.5.1.2. MIPv4 Registration Reply Packet Flow from HA to MN.......20
   6.5.1.3. DMZ Configuration Requirements for MIPv4 Registration
   Packets...........................................................20
   6.5.2. Mobile IPv4 Data Processing................................21

Adrangi, Iyer
Expires January 2002
[Page 2]


Internet Draft draft-adrangi-mipv4-midbox-traversal-00      July 2001


   6.5.2.1. MIPv4 Data Traffic from MN to CN.........................21
   6.5.2.2. MIPv4 Data Traffic from CN to MN.........................23
   6.5.3. Support For Route Optimization.............................24
   6.6. Key Management and SA Preservation...........................24
   6.7. DMZ and VPN Gateway Configuration Requirements...............25
   6.8. Supporting Other IPsec-based VPN Configurations..............25
   6.9. Considerations for Integrating the MIP Proxy and VPN Gateway.25
   7. Using the MIP Proxy for combined NAT and VPN Traversal.........25
   7.1. MIPv4 Registration Message Flow..............................26
   7.1.1. MIPv4 Registration Requests................................26
   7.1.2. MIPv4 Registration Replies.................................26
   7.2. MIPv4 Data Flow..............................................27
   7.2.1. Data Flow from the MN to the CN............................27
   7.2.2. Data Flow from the CN to the MN............................28
   8. Security Implications..........................................29
   9. Acknowledgements...............................................29
   10. Patents.......................................................29
   11. References....................................................29

1. Introduction

        The deployment of 802.3-based wired LANs and wireless LAN hot
        spots and WAN packet data networks based on 2.5G and 3G
        technologies and the availability of multi-mode networked
        devices is driving new application scenarios that require
        Mobile IPv4 support. These networks are also seeing widespread
        use of NAT and VPN gateways. For example, many Enterprises are
        deploying wireless LANs outside their corporate DeMilitarized
        Zone (DMZ), requiring mobile nodes to "VPN" back into the
        Intranet, from NATÆed subnets. Wireless WAN operators are
        setting up to offer routable IPv4 addresses to corporate
        clients for remote access back to their Enterprise networks,
        while offering NAT-based access to their core network and the
        Internet to consumers. NAT and firewall-enabled residential
        networks are another example where mobile nodes could encounter
        such middleboxes. Mobile IPv4 has known functional and
        performance limitations, traversing these middleboxes. It is
        often unacceptable to deploy workarounds that require any
        software or hardware changes to these middleboxes or compromise
        their functionality in any way.

        The solution proposed in this draft introduces a logical
        component called the MIP Proxy to enable seamless Mobile IPv4
        functionality across such middleboxes, without requiring any
        changes to these middleboxes.

        The important sections of this draft are organized as follows:
        Section 4 describes the MIP proxy.
        Section 5 discusses seamless traversal through NAT gateways.
        Section 6 discusses seamless traversal through VPN gateways.
        These two solutions can be deployed independently or in
        combination depending on specific network configurations, as
        discussed in section 7.

Adrangi, Iyer            Expires January 2002                 [Page 3]


Internet Draft draft-adrangi-mipv4-midbox-traversal-00      July 2001



2. Terminology

        Administrative Domain:
        A Mobile IP administrative domain specifies the Mobile IP
        security parameters for one or more home agents and their
        corresponding mobile nodes.  The security parameters are used
        for authentication or encryption to provide a secure channel
        for the Mobile IP control and data traffic between the home
        agent and mobile nodes.

        Actual Home Agent:
        It is the mobile nodeÆs real home agent, as defined by
        [RFC2002].

        NAT-Router:
        It is an IPv4 Router with NAT functionality.

        The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
        NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and
        "OPTIONAL" in this draft are to be interpreted as described in
        [RFC2119].

3. Acronyms

        GRE: Generic Routing Encapsulation
        ISP: Internet Service provider
        MIPv4: Mobile IP for IPv4
        MIPv6: Mobile IP for IPv6
        NAT: Network Address Translator

        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 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. The MIP Proxy

        The MIP Proxy is a functional entity that is introduced in the
        path between a MN and itÆs corresponding 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 itÆs 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. It

Adrangi, Iyer            Expires January 2002                 [Page 4]


Internet Draft draft-adrangi-mipv4-midbox-traversal-00      July 2001


        MUST share SAs for various MIPv4 registration extensions with
        its associated HA(s).

                   +----+
                   | MN |------                               +----+
                   +----+     |                            |--| HA |
                    . . .     |                            |  +----+
                   +----+     |      +----------+          |  +----+
                   | MN |------------| MIP Proxy|----------|--| HA |
                   +----+     |      +----------+          |  +----+
                    . . .     |                            |  +----+
                   +----+     |                            |--| HA |
                   | MN |-----                                +----+
                   +----+

                Figure 4.0 : MIP Proxy serving multiple MNs and HAs

        A MIP Proxy MAY support additional functionality in the context
        of support for a specific type of middlebox. For NAT and VPN
        gateways, additional functionality, if any, is described in
        relevant sections of this draft.

        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.

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.

        As a surrogate MN, the MIP Proxy MUST perform the following MN
        compliant functions:

        - It MUST perform registration request and reply protocol,
        specified by [RFC2002]
        - It MUST perform reverse tunneling, defined by [RFC3024]
        - It MUST perform authentication mechanism(s) for the MN and
        HA, required by [RFC2002]
        - It MUST perform replay protection for registration request,
        defined by [RFC2002]

        The MIP Proxy MUST NOT perform the following MN functions:

        - It MUST NOT perform agent solicitation, defined by [RFC2002]
        - It MUST NOT perform any functions related to agent discovery,
        defined by [RFC2002]
        - It MUST NOT perform registration retransmission, defined by
        [RFC2002]
        - It MUST NOT perform move detection mechanisms, defined by
        [RFC2002]

4.2. Surrogate HA Functionality

Adrangi, Iyer            Expires January 2002                 [Page 5]


Internet Draft draft-adrangi-mipv4-midbox-traversal-00      July 2001



        The other primary function of the MIP Proxy is to serve as a
        surrogate HA to a roaming MN that is outside its home network,
        and with an intervening middlebox such as a NAT or VPN gateway.

        As a surrogate HA, the MIP Proxy MUST perform the following MN
        compliant functions:

        - It MUST perform registration request and reply protocol,
        defined by [RFC2002]
        - It MUST perform authentication mechanism(s) for the (MN & HA
        and the HA & FA), required by [RFC2002]
        - It MUST maintain registration binding table, defined by
        [RFC2002]
        - It MUST perform replay protection for registration request,
        defined by [RFC2002]

        The MIP Proxy MUST NOT perform the following MN functions:

        - It MUST NOT perform agent advertisement, defined by [RFC2002]
        - It MUST NOT perform gratuitous ARP, defined by [RFC2002]
        - It MUST NOT perform Proxy ARP, defined by [RFC2002]
        - It MUST NOT perform Route Optimization [ROUTE-OPT]

4.3. Deploying a MIP Proxy

        A MIP Proxy MAY be deployed in a public network serving
        multiple HAs in that network as conceptually depicted in the
        figure above. It MUST be deployed in a DMZ to supported
        authenticated firewall traversal for MIPv4 packets traversing
        the DMZ from an MN with an intervening NAT gateway in itÆs
        foreign network. It MUST be deployed in parallel with an IPsec-
        compatible VPN gateway in a DMZ. Trivially, a subset of the MIP
        Proxy functionality MAY be co-located with a HA if appropriate.

        The MIP Proxy MAY be located in the same or a different subnet
        from any of its associated home agents.

4.4. 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.5. MIP Proxy Redundancy

        A MIP Proxy redundancy protocol is desirable to effect high
        availability in public and Enterprise deployment. Details of
        such a protocol are beyond the current scope of this draft.

5. MIPv4 Traversal Through NAT Gateways

5.1.  NAT Traversal Problem Statement

Adrangi, Iyer            Expires January 2002                 [Page 6]


Internet Draft draft-adrangi-mipv4-midbox-traversal-00      July 2001



        When an MN roams from its home network (which may or may not be
        in a routable IP address space) to a foreign network behind a
        NAT gateway, it acquires a non-routable care-of address (most
        likely through [DHCP]). The acquired non-routable care-of
        address is passed to the HA through a registration request.
        This causes the MN to lose its connectivity to its home
        network, since the HA will not be able to forward the MNÆs
        packets to the non-routable care-of address. The scenario is
        depicted in Figure 5.1 below.

         +-------------------+              +-------------------------+
         |  Foreign network  |              | Home Network            |
         |  +----+           |    +-----+   |                         |
         |  | MN |           |----| NAT |---|  +----+   +----+  +---+ |
         |  +----+           |    +-----+   |  | MN |   | HA |  |CN | |
         |                   |              |  +----+   +----+  +---+ |
         +-------------------+              |                         |
                                            |           +---+         |
                                            |           | FA|         |
                                            |           +---+         |
                                            +-------------------------+

                Figure 5.1 : MN has moved from its home network to a
                foreign network

        Even if we overcome this problem somehow by using the NAT
        gatewayÆs public routable address in the care-of address field
        of the registration request, the NAT gateway will not always be
        able to demultiplex inbound MIPv4 data traffic properly.
        Consider two MNs behind the NAT gateway registered with the
        same HA. The inbound IP-in-IP tunneled MIPv4 packets from the
        HA to the two MNs will have the source and destination IP
        address, making it difficult for the NAT gateway to route the
        packets to the appropriate MN.
        The implications on Minimal IP [RFC2004] and GRE encapsulation
        [RFC1701] modes of MIPv4 are similar to IP-in-IP tunneling.

5.2. Assumptions and Applicability

        The solution proposed in the draft is targeted toward network
        environments where the following are true.
        - The NATÆed foreign network SHOULD NOT be modified. This
        implies that no software or hardware changes to the NAT gateway
        are feasible and adding a new routing entity (dedicated to
        MIPv4 nodes) to such a network is unacceptable. Most
        residential and small business networks are typical examples of
        such NATÆed networks, wherein an embedded broadband router
        (supporting local DHCP and NAT) is employed and additional
        resources such as a routable IP address and/or a system are not
        obtainable.
        - The NAT gateway is capable of doing address and port mapping.


Adrangi, Iyer            Expires January 2002                 [Page 7]


Internet Draft draft-adrangi-mipv4-midbox-traversal-00      July 2001


        - The NATÆed network MUST provide DHCP service to the foreign
        subnet or a mobile node MUST be capable of self-assigning or
        acquiring by other means, a non-routable care-of address when
        it roams behind the NAT.
        - The NATÆed network MAY NOT include a foreign agent.
        - The NATÆed network MAY NOT be in the same administrative
        domain as the MN, MIP Proxy and HA.
        - The NATÆed network MUST be configured with the IP addresses
        reserved for private Internets by IANA ([RFC1918], [LOCAL-
        LINK]).
        - If the NATÆed network is multi-subnetted, the routers within
        that network cannot be compromised.
        - The HA SHOULD NOT be modified.
        - MNÆs home network MUST be in a routable IP address domain.
        This address domain MAY be behind a firewall/DMZ.
        - A FA MAY NOT be available in the ISP access or core network.
        - Security implications should not be worse than direct comm.
        With HA.

        Applicability in other network environments has not been
        verified; however it is not explicitly precluded. Furthermore,
        the proposed solution MAY be used in combination with other NAT
        traversal solutions as appropriate.

        If the MNÆs home network is in a non-routable IP address
        domain, an appropriate solution (outside the scope of this
        draft) MUST be deployed to make the home network accessible
        from an external public or private network.

5.3.    Using the MIP Proxy for NAT Traversal

        The MIP Proxy acts as an intermediate node between a MN in
        foreign network behind NAT and itÆs HA. MIPv4 registration
        requests from the MN are sent to the MIP Proxy, instead of the
        actual HA. The MIP Proxy terminates the registration request
        and validates the payload. If the registration request is
        acceptable, the MIP Proxy creates a new registration request
        and forwards it to the HA on behalf of the MN. The registration
        response from the HA is translated into a new response from the
        MIP Proxy back to the MN.

        All subsequent MIPv4 data traffic between the MN and the MIP
        Proxy SHOULD be encapsulated in a UDP tunnel, in order to help
        the NAT gateway demultiplex return inbound MIPv4 traffic
        NAT/NAPT mechanisms.

        The solution is detailed in the following sections.

5.3.1.  When does a MN register with the MIP Proxy?

        A mobile node MUST register with the MIP Proxy when it roams to
        a foreign network behind a NAT gateway. Mechanisms to detect


Adrangi, Iyer            Expires January 2002                 [Page 8]


Internet Draft draft-adrangi-mipv4-midbox-traversal-00      July 2001


        the presence of a NAT gateway are beyond the scope of this
        draft.

5.3.1.1. Selection of the COA Field in the Registration Request Payload

       As explained in the problem statement, the use of a non-routable
       address as the COA causes the MN to lose its connectivity to its
       home network.  Therefore, the MN MUST use the NAT gatewayÆs
       routable (WAN) as the COA in its registration payload.  The MN
       MAY be configured with the NAT gatewayÆs routable IP address a
       priori. However, if this is not feasible, it is imperative for
       the MN to use a secured discovery scheme to realize the NAT
       gatewayÆs routable address to avoid potential Denial-of-Service
       (DoS) attacks.  The following diagrams show one possible method
       for dynamically discovering and verifying the NAT gatewayÆs
       routable address.

           MN                  NAT             MIP Proxy
           |Registration       |               |
           |Request (COA=0)    |               |
           |-----------------> |Registration   |
           |                   |Request        |
           |                   |-------------->|
           |                   |               |
           |                   |Registration   |
           |                   | Reply With    |
           |                   | Reject        |
           | Registration      |<------------  |
           | Reply With Reject |               |
           | <---------------- |               |
           |                   |               |

           Figure 5.3a : Discovery of the NAT gatewayÆs routable
           address


           MN                         NAT
           |                           |
           |ICMP echo Message(s)       |
           |                           |
           | ---------------------->   |
           |ICMP Reply Message(s)      |
           |                           |
           | <-----------------------  |
           |                           |


          Figure 5.3b : Verification of the NAT gatewayÆs routable
          address

        The NAT gatewayÆs routable address discovery (as depicted in
        Figure 5.3a) is accomplished as a part of the registration
        request protocol initiated when the MN roams to a foreign

Adrangi, Iyer            Expires January 2002                 [Page 9]


Internet Draft draft-adrangi-mipv4-midbox-traversal-00      July 2001


        network behind a NAT gateway.  The MN MUST send a registration
        request to the MIP Proxy with the COA set to a zero.  As the
        registration payload contains an invalid COA, the MIP Proxy
        MUST send a registration reply with error code 134 (Poorly
        Formatted). The MIP Proxy MUST also include the NAT Discovery
        extension in its reply (see section 5.3.1.2).  The MIP Proxy
        employs this extension to notify the MN about the possible NAT
        gatewayÆs routable address, obtained from the source IP address
        of the registration request.

        The MN MAY verify this IP address, before it can use it as the
        COA in its registration payload.  With NAT-router gateways, The
        MN MAY achieve this by analyzing the trace-route log (i.e., a
        series of ICMP echo and reply messages) from the MN to the
        possible NAT gatewayÆs routable address obtained form the
        registration discovery extension.

5.3.1.2. Discovery Registration Extension

        The following shows the format of the NAT Discovery extension
        used in the registration reply from the MIP Proxy to the MN.

     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                       | Reserved       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |               Possible NAT GatewayÆs routable Address         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        Type: 180
        Length: Indicates (in bytes) of the data fields within the
        extension, excluding the Type and Length bytes.
        Reserved: For future user.
        Possible NAT GatewayÆs routable Address: An IP address

        Once the MN obtains and verifies the NAT gatewayÆs public
        address, it MUST send a registration request with the COA set
        to the NAT gatewayÆs routable address.

5.3.2. MIPv4 registration protocol between MN and HA

        Once the MN obtains and verifies the NAT gatewayÆs routable
        address, the MN MUST register with its actual home agent via
        the MIP Proxy.  Therefore,
        the normal flow of MIPv4 registration messages between a MN and
        a HA are altered as depicted in the figure below.



Adrangi, Iyer            Expires January 2002                [Page 10]


Internet Draft draft-adrangi-mipv4-midbox-traversal-00      July 2001




         MN              NAT Gateway     MIP Proxy                 HA
         |Reg.Request       |                   |                  |
         |----------------->|Reg. Request       |                  |
         |                  |-----------------> |Reg. Request      |
         |                  |                   |----------------->|
         |                  |                   |Reg. Reply        |
         |                  |Reg. Reply         |<-----------------|
         |Reg. Reply        |<----------------- |                  |
         |<-----------------|                   |                  |

           Figure 5.3.2 : Mobile IP registration protocol between
                          MN and HA

5.3.2.1. Establishing UDP Tunnel Parameters for MIPv4 Data Traffic

        To support multiple, simultaneous MIPv4 data sessions from MNs
        behind a NAT gateway to a home network via the same HA, a UDP
        tunnel MUST be established between the MN and MIP Proxy.  The
        MN MUST use the parameter registration extension (see section
        5.3.2.3) to notify the MIP Proxy about the UDP port number
        ought to be used to establish a UDP tunnel for the Mobile IP
        data traffic between the MN and MIP Proxy.

        The UDP port number 434 MAY be used to tunnel the data traffic
        between the MN and MIP Proxy.  However, this MAY have some
        performance implications.  If any UDP port numbers other than
        434 is used, a new entry in the NAT gatewayÆs address/port
        mapping MUST be created right after a successful registration.
        This can be done, by sending a NULL UDP packet (i.e, an empty
        payload) from the MN to the MIP proxy.

        The mobile node MUST maintain the selected UDP port number for
        the lifetime of the registration request. The MN SHOULD ensure
        that the NAT gatewayÆs lifetime for the UDP tunnel port mapping
        does not expire prior to the expiry of the Registration
        lifetime.  This MAY be done through some sort of periodic
        KeepAlive messages from the MN to MIP Proxy.

5.3.2.2. Discovering the MNÆs actual home agent by the MIP Proxy

        The MN MUST notify the MIP Proxy about its actual home agent
        address, via the parameter registration extension.  The
        following shows the parameter registration extension format.


Adrangi, Iyer            Expires January 2002                [Page 11]


Internet Draft draft-adrangi-mipv4-midbox-traversal-00      July 2001


5.3.2.3. Parameter Registration Extension

        The following shows the format of the parameter extension used
        in the registration request from MN 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                       | Reserved       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                    Home Agent Address                         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |        UDP Port Number        | Reserved                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------------------------+

                Type : 181
                Length :
                    Indicates (in bytes) of the data fields within the
                    extension, excluding the Type and Length bytes.
                Reserved: For future use.
                Home Agent Address: An IP address of the MNÆs actual
                home agent
                UDP Port Number: Used to establish UDP tunnel
                Reserved: For future use.

5.3.2.4. MIPv4 Registration Request Packet Flow From MN to HA

        The MN sends the Registration Request to the MIP Proxy. The
        intervening NAT gateway modifies the source IP address (and
        possibly the UDP source port).

        From MN to the MIP Proxy:

                +--------------------------------------------------+
                |IP-S = MN-COA    | Permanent Address = MN-Perm    |
                |IP-D = MIPP-Pub  | Home Agent = MIPP-Priv         |
                |                 | Care-of Address = NATGW-Pub    |
                |                 |     . . .                      |
                +--------------------------------------------------+

        The NAT gateway modifies the source IP address, and possibly
        UDP source port number.





Adrangi, Iyer            Expires January 2002                [Page 12]


Internet Draft draft-adrangi-mipv4-midbox-traversal-00      July 2001



                +--------------------------------------------------+
                |IP-S = NATGW-Pub | Permanent Address = MN-Perm    |
                |IP-D = MIPP-Pub  | Home Agent = MIPP-Priv         |
                |                 | Care-of Address = NATGW-Pub    |
                |                 |     . . .                      |
                +--------------------------------------------------+

        The MIP Proxy terminates and authenticates the Registration
        Request received from the MN. It then modifies the registration
        request payload and forwards a new registration request to the
        HA associated with the MN. The MIP Proxy MUST set the Home
        Agent and Care-of Address fields of the registration request to
        the MNÆs actual HA (learned from the parameter registration
        extension) and the MIP ProxyÆs private address respectively.
        The packet format is shown below.

                +--------------------------------------------------+
                |IP-S = MIPP-Priv    | Permanent Address = MN-Perm |
                |IP-D = HA           | Home Agent = HA             |
                |                    | Care-of Address = MIPP-Priv |
                |                    |     . . .                   |
                +--------------------------------------------------+

        The MIP Proxy maintains a registration binding cache similar to
        the one specified by [RFC2002] for a HA, in order to forward
        the registration replies and subsequent MIPv4 data traffic.  In
        addition, the MIP Proxy MUST also record the UDP port number
        (learned form the parameter registration extension) for the UDP
        tunnel between the MN and the MIP Proxy in the registration
        binding cache. The MIP Proxy MUST not manage registration
        lifetimes and MUST NOT reinitiate a registration request with a
        HA prior to its expiration. A MN MUST continue to manage
        Registration lifetimes as specified in [RFC2002].

5.3.2.5. MIPv4 Registration Reply Packet Flow From HA to MN

        If the actual HA were to accept the registration request, the
        reply flow sequence will be as follows:

        From the HA to the MIP Proxy:
                +--------------------------------------------------+
                |IP-S = HA                | Home Agent = HA        |
                |IP-D = MIPP-Pri          | . . .                  |
                +--------------------------------------------------+

        From the MIP Proxy to the NAT
                +-------------------------------------------------+
                |IP-S = MIPP-Pub          | Home Agent = MIPP-Pub |
                |IP-D = NAT-Pub           |  . . .                |
                +-------------------------------------------------+

        From the NAT to the MN:

Adrangi, Iyer            Expires January 2002                [Page 13]


Internet Draft draft-adrangi-mipv4-midbox-traversal-00      July 2001


                +--------------------------------------------------+
                |IP-S = NAT-Priv          | Home Agent = MIPP-Pub  |
                |IP-D = MN-Perm           | . . .                  |
                +--------------------------------------------------+

5.3.3. MIPv4 data traffic from MN to CN

        The normal flow of MIPv4 data flow between a MN and a HA are
        altered as depicted in the figures below.  Note that the data
        traffic form the MN to MIP Proxy is encapsulated in a UDP
        tunnel.


                MN      NAT        MIP       CN
                                   Proxy
                |         |         |       |
                |IP/UDP/IP|         |       |
                |-------> |         |       |
                |         |IP/UDP/IP|       |
                |         |-------> |       |
                |         |         | IP    |
                |         |         |------>|

                Figure 5.3.5 : MIP Proxy forwards data packet directly
           to CN

        All MIPv4 data traffic between the MN and MIP Proxy will be
        encapsulated in a UDP tunnel.  The MIP Proxy will strip off the
        outer IP and UDP headers, and re-encapsulate the detunneled
        packet in an IP header (from MIPP-Pub to MN or from MIPP-Priv
        to HA as the case may be) before forwarding it to the MN or HA
        respectively. The following figures illustrate the traffic flow
        from the MN to the MIP Proxy, and the MIP Proxy to the actual
        HA.

        MIPv4 data packet flow from the MN to the MIP Proxy:

        +-------------------------------------------------------+
        |IP-S=MN-COA   |UDP Src Port# |IP Src = MN-Perm | Data  |
        |IP-D=MIPP-Pub |UDP Dest Port#|IP Dest = CN     |       |
        +-------------------------------------------------------+

        The intermediate NAT gateway will apply address and port
        mapping on the packet, and forward the packet, as follows:

        +-------------------------------------------------------+
        |IP-S=NAT-Pub  |UDP Src Port# |IP Src = MN-Perm |Data   |
        |IP-D=MIPP-Pub |UDP Dest Port#|IP Dest = CN     |       |
        +-------------------------------------------------------+





Adrangi, Iyer            Expires January 2002                [Page 14]


Internet Draft draft-adrangi-mipv4-midbox-traversal-00      July 2001


        MIPv4 data packet flow from the MIP Proxy to CN is as follows:

        +------------------------------------------------+
        | IP-S = MIPP-Pri   |IP Src = MN-Perm |Data      |
        | IP-D = CN         |IP Dest = CN     |          |
        +------------------------------------------------+

5.3.4. MIPv4 data traffic from CN to MN

        MIPv4 data traffic will be tunneled from the actual HA to the
        MIP Proxy IP-in-IP tunnel is illustrated in the figure above,
        however the discussion applies to other MIPv4 encapsulation
        modes as well).  The MIP Proxy strips off the outer IP header,
        and forwards the inner IP packet to the MN in a UDP tunnel.

        The following figures illustrate the traffic flow from the CN
        to the MN (via the actual HA and the MIP Proxy).


        The data packets from the CN will be sent to the MNÆs permanent
        address, MN-Perm.

        +-----------------------------+
        | IP-S = CN          |Data    |
        | IP-D = MN-Perm     |        |
        +-----------------------------+

        The MNÆs home agent will intercept the data packet, and will
        forward it to its current care-of address (i.e., MIP Proxy) as
        follows:

        +----------------------------------------------+
        | IP-S = HA         |IP Src = MN-Perm |Data    |
        | IP-D = MIPP-Priv  |IP Dest = CN     |        |
        +----------------------------------------------+

        From the MIP Proxy to the NAT gateway:
        +---------------------------------------------------------+
        |IP-S = MIPP-Pub   |UDP Src Port# |IP Src = MN-Perm |Data |
        |IP-D = NAT-Pub    |UDP Dest Port#|IP Dest = CN     |     |
        +---------------------------------------------------------+

        The NAT gateway unapplies address and port mapping on the
        packet, and forwards the packet, as follows:




        From the NAT gateway to the MN:
        +----------------------------------------------------------+
        | IP-S = MIPP-Pub   |UDP Src Port# |IP Src = MN-Perm |Data |
        | IP-D = MN-COA     |UDP Dest Port#|IP Dest = CN     |     |
        +----------------------------------------------------------+

Adrangi, Iyer            Expires January 2002                [Page 15]


Internet Draft draft-adrangi-mipv4-midbox-traversal-00      July 2001



5.4. Summary of changes on MIPv4 components required by this solution

        This solution requires changes on the mobile node, and of
        course an addition of a new component, the MIP Proxy.

5.4.1. Required Changes to a MN

        - The MN MUST be configured with the static IP address of the
        MIP Proxy. A mechanism for MIP Proxy discovery MAY be defined
        in future.
        - The MN MUST be able to determine if it has roamed to a
        private address space behind a NAT gateway.
        - The MN MUST implement the registration extension as specified
        in this draft.
        - The MN SHOULD be able to extend the lifetime of the NAT
        gatewayÆs address and port mapping entries for the UDP tunnel
        beyond the registration lifetime determined with itÆs HA.

5.4.2. Required Configuration for the MIP Proxy

        - The MIP Proxy MUST be configured with all of the SAs of an MN
        and a HA that it represents as a surrogate.
        - The MIP Proxy SHOULD be configured with static IP addresses
        to avoid periodic reconfiguration on MNs.

5.5. Performance Implications of MIP Proxy assisted NAT Traversal

        - The proposed method creates a layer of indirection (i.e., the
        MIP Proxy), which MAY have some performance implications.
        - An eight bytes UDP header is added to the Mobile IP data
        traffic from the MN to MIP Proxy.
        - Discovery and verification method of the NAT gatewayÆs public
        address will degrade the registration hand-off performance.

5.6. Implications of Twice NAT between the MN and MIP Proxy
        The proposed solution MAY not work if Twice NAT is encountered
        in the path between the MN and the MIP proxy.

6. 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

Adrangi, Iyer            Expires January 2002                [Page 16]


Internet Draft draft-adrangi-mipv4-midbox-traversal-00      July 2001


        have to overcome to support seamless end-to-end IPsec. This
        draft describes a solution based on the use of the MIP Proxy to
        enable seamless traversal across IPsec-based VPNs.

+----------------+  +-----+    +------+       +-----+ +---------------+
|Foreign network |  |     |  ->|VPN-GW|<----  |     | |Home network   |
|+----+   +----+ |  |Outer|  | +------+    |  |Inner| | +----+ +----+ |
|| MN |   | FA | |  |FW   |  |             |  |FW   | | |HA  | | CN | |
|+----+   +----+ |  |     |  | +---------+ |  |     | | +----+ +----+ |
|                |  |     |  ->|MIP Proxy|<-  |     | |               |
+----------------+  +-----+    +---------+    +-----+ | +----+        |
                       ^                         ^    | | MN |        |
                       |----- Firewall/DMZ ----- |    | +----+        |
                                                      +---------------+

        Figure 6.0 : MN has moved from its home network to a foreign
        network outside the DMZ

6.1. IPsec VPN Traversal Problem Statement

        With respect to Figure 6.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, will not be able to setup SAs with the MNÆs
        VPN gateway and will consequently be not able to relay MIPv4
        packets between the MN and the VPN gateway.

6.2. Integration of MIPv4 and IPsec

        Clearly there are several schemes to apply IPsec to MIPv4
        packets. [MIPv4-SEC-GUIDE] describes different segments where

Adrangi, Iyer            Expires January 2002                [Page 17]


Internet Draft draft-adrangi-mipv4-midbox-traversal-00      July 2001


        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 IPsec is applied end-to-end.

6.3. Assumptions and Applicability

        The solution is derived based on the following assumptions and
        applicability criteria:
        - 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 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.

6.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 can
        meet the following criteria:

6.4.1. Fast Handoffs

        To support fast handoffs across IP subnets, it is imperative to
        keep the key management overhead down to a minimum. In this
        draft, we propose a mechanism whereby the IPsec tunnel SA can
        be bound to the invariant permanent IP address of the MN. Doing
        so, enables the reuse of the SA across IP subnet handoffs and
        also minimizes the protocol handshake between the VPN gateway,
        actual HA and the MIP Proxy.

6.4.2. Preserve Existing VPN Infrastructure

        This implies the following:
        - Preserves the investment in existing VPN gateways
        - Requires no software upgrades to VPN gateways to explicitly
        support MIPv4 users
        - Preserves IPsec VPN security requirements that are not
        inferior to what is already provided to existing "nomadic

Adrangi, Iyer            Expires January 2002                [Page 18]


Internet Draft draft-adrangi-mipv4-midbox-traversal-00      July 2001


        computing" remote access users, i.e. for confidentiality,
        primary and secondary authentication, message integrity,
        protection against replay attacks and related security services

6.4.3. Preserve Existing DMZ Traversal Policies

        Most Corporate DMZ policies recommend authenticated firewall
        traversal for protocols that traverse the DMZ. Placing devices
        outside the outer DMZ firewall to assist with DMZ traversal
        exposes the device to hackers and is generally not an
        acceptable solution. IT departments prefer that solutions
        adhere to and can be accommodated with existing or compliant
        DMZ ACLs.

6.5. Deploying the MIP Proxy to support VPN Traversal

        As shown in Figure 6.0, the MIP Proxy is deployed in parallel
        to an existing VPN gateway in the DMZ to support MIPv4.

6.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 MUST include the discovery registration
        extension (see section 5.3.1.2.) to notify the MIP Proxy about
        the MNÆs actual home agent.  The registration replies from the
        HA will also go through the MIP Proxy bypassing the VPN
        gateway. Note that 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 rail-road diagram illustrating the MIPv4 registration process
        is shown below.

                MN              MIP Proxy               HA
                |Reg. Request           |                  |
                |----------------->     |                  |
                |                       |Reg. Request      |
                |                       |----------------->|
                |                       |Reg. Reply        |
                |                       |<-----------------|
                |Reg. Reply             |                  |
                |<-----------------     |                  |

                Figure 6.5.1 : Mobile IP registration protocol between
   MN and HA

6.5.1.1. MIPv4 Registration Request Packet Flow from MN to HA



Adrangi, Iyer            Expires January 2002                [Page 19]


Internet Draft draft-adrangi-mipv4-midbox-traversal-00      July 2001


        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    |
                |                 |     . . .                      |
                +--------------------------------------------------+

6.5.1.2. MIPv4 Registration Reply Packet Flow from HA to MN

        If the actual HA were to accept the registration request, the
        reply flow sequence will be as follows:

        From the HA to the MIP Proxy:
                +--------------------------------------------------+
                |IP-S = HA         | Home Agent = HA               |
                |IP-D = MIPP-Priv  | . . .                         |
                +--------------------------------------------------+

        From the MIP Proxy to the FA:
                +--------------------------------------------------+
                |IP-S = MIPP-Pub  | Home Agent = MIPP-Pub          |
                |IP-D = FA        | . . .                          |
                +--------------------------------------------------+

        From the FA to the MN:
                +--------------------------------------------------+
                |IP-S =  FA       | Home Agent = MIPP-Pub          |
                |IP-D = MN-Perm   | . . .                          |
                +--------------------------------------------------+

6.5.1.3. DMZ Configuration Requirements for MIPv4 Registration Packets


Adrangi, Iyer            Expires January 2002                [Page 20]


Internet Draft draft-adrangi-mipv4-midbox-traversal-00      July 2001


        The DMZ ACLs MUST be setup for the following:
        - Inbound UDP registration packets (destination port = 434 and
        destination address = MIPP-Pub) MUST be permitted.
        - The DMZ inner firewall MUST permit the forwarding of
        registration request and reply packets from the MIP Proxy to
        one or more HAs.

6.5.2. Mobile IPv4 Data Processing

        The following railroad diagram illustrates the sequence of
        steps to establish secured MIPv4 traffic between a MN and a CN.
        The process initially occurs in 3 sequential steps: MIPv4
        registration, IPsec tunnel SA establishment and MIPv4 data
        forwarding. Registration and SA refreshes may subsequently
        occur independent of each other.

        MIPv4 Registration- see Figure 6.5.1
        Note that the VPN gateway is not involved in the MIPv4
        Registration process.

        IPsec Tunnel SA Establishment:
                MN                      VPN Gateway
                |                                       |
                |IKE Phase 1 (ISAKMP SA) <---------->   |
                |                                       |
                |IKE Phase 2 (Tunnel SA) <---------->   |
                |                                       |

        Note that the MIP proxy is not involved in the Tunnel SA
        establishment and will not be involved in SA refreshes.

        The data forwarding is described in the following 2 sub-
        sections.

6.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
        |       |          |                |           |         |
        |------>|          |                |           |         |

Adrangi, Iyer            Expires January 2002                [Page 21]


Internet Draft draft-adrangi-mipv4-midbox-traversal-00      July 2001


        |       | -------> |                |           |         |
        |       |          | ------------>  |           |         |
        |       |          |                | ------------------> |


        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 |            |        |
        +-------------------------------------------------------------+
        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     |        |
        +---------------------+


Adrangi, Iyer            Expires January 2002                [Page 22]


Internet Draft draft-adrangi-mipv4-midbox-traversal-00      July 2001


6.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.

        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 CN sets the layer-2 destination address to that of the
        actual HA.

        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.
        +---------------------+

Adrangi, Iyer            Expires January 2002                [Page 23]


Internet Draft draft-adrangi-mipv4-midbox-traversal-00      July 2001


        |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.
        +-----------------------------------------------------------+
        |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.

6.5.3. Support For Route Optimization

        The MIP Proxy MUST NOT support Route Optimization [ROUTE-OPT].
        However, the Route Optimization between the correspondent node
        and the mobile nodeÆs actual home agent MAY be performed.

6.6. Key Management and SA Preservation

        The scheme described in the previous section binds the IPsec
        tunnel SA to the normally invariant permanent 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

Adrangi, Iyer            Expires January 2002                [Page 24]


Internet Draft draft-adrangi-mipv4-midbox-traversal-00      July 2001


        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 an MN loses link connectivity
        for a period extending the keep-alive timeout interval, it MUST
        reestablish the tunnel SA, regardless of whether it reconnects
        to the same IP subnet or not.

        The scheme also preserves any secondary authentication
        mechanisms that may be in the place to authenticate a remote
        access user.

6.7. 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.
        - The outer firewall MUST allow inbound tunneled IP packets
        destined to the MIP Proxy
        - The MIP Proxy MUST be able to forward packets (destined to
        MN) to VPN gateway via layer 2 mechanism.  This implies that
        the MIP Proxy and VPN Gateway MUST be on the same subnet.

6.8. 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. Its applicability to other IPsec VPN configurations
        such as L2TP over IPsec transport and ESP-in-UDP tunneling is
        yet to be determined.

6.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 an 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.

7. Using the MIP Proxy for combined NAT and VPN Traversal

Adrangi, Iyer            Expires January 2002                [Page 25]


Internet Draft draft-adrangi-mipv4-midbox-traversal-00      July 2001



        The discussion in the draft would be incomplete without
        describing a scenario in which a MN roams into a foreign NATÆed
        network and has to connect back to itÆs home network which is
        behind a DMZ. Many Enterprises are deploying wireless LANs as a
        private NATÆed network outside their DMZ-users that roam into
        such a network will be forced to VPN back into their Intranet.
        Such a scenario can be supported with the MIP Proxy enabling
        simultaneous NAT and VPN traversal. The network configuration
        would be a combination of Figures X and Y. The analysis assumes
        that there is no FA in the NATÆed network.

7.1. MIPv4 Registration Message Flow
7.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 = NATGW-Pub   |
                |               |     . . .                     |
                +-----------------------------------------------+

        Please see the discussion in section 5 for possible mechanisms
        for an MN to determine the NAT gatewayÆs external (public)
        routable IP address.

        From the NAT gateway to the MIP Proxy:
        The NAT gateway performs source address and source UDP port
        translation before forwarding the packet to the MIP Proxy.


                +-----------------------------------------------+
                |IP-S=NATGW-Pub | Permanent Address = MN-Perm   |
                |IP-D=MIPP-Pub  | Home Agent = MIPP-Pub         |
                |               | Care-of Address = NATGW-Pub   |
                |               |     . . .                     |
                +-----------------------------------------------+

         From the MIP Proxy to the actual HA:
        The MIP Proxy terminates and authenticates the registration
        request (as described in previous sections). It then creates a
        new registration request and forwards it to the actual HA.


                +-----------------------------------------------+
                |IP-S=MIPP_Priv | Permanent Address = MN-Perm   |
                |IP-D=HA        | Home Agent = HA               |
                |               | Care-of Address = MIPP-Priv   |
                |               |     . . .                     |
                +-----------------------------------------------+

7.1.2. MIPv4 Registration Replies
        From the actual HA to the MIP Proxy:

Adrangi, Iyer            Expires January 2002                [Page 26]


Internet Draft draft-adrangi-mipv4-midbox-traversal-00      July 2001



                +--------------------------------------+
                |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 | . . .                |
                +------------------------------- ------+

        From the NAT gateway to the MN:
                +----------------------------------------+
                |IP-S=NATGW-Priv | Home Agent = MIPP-Pub |
                |IP-D=MN COA     | . . .                 |
                +----------------------------------------+

7.2. MIPv4 Data Flow

        Reverse tunneling is assumed in the packet flow descriptions
        that follow.

7.2.1. Data Flow from the MN to the CN

   From MN to the NAT gateway:
  +----------------------------------------------------------------+
  |IP-S=MN-Priv | UDP |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 |            |     |
  +----------------------------------------------------------------+



  From the NAT gateway to the MIP Proxy:
  +----------------------------------------------------------------+
  |IP-S=NATGW-Pub| UDP |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 January 2002                [Page 27]


Internet Draft draft-adrangi-mipv4-midbox-traversal-00      July 2001


        From the MIP Proxy to the VPN gateway:
        +-----------------------------------------------+
        |IP-S=MN-Perm  |IPsec-ESP |IP-S=MN-Perm| Data   |
        |IP-D=VPNGW-Pub|MN-Perm to|IP-D=CN     |        |
        |              |VPNGW-Pub |            |        |
        +-----------------------------------------------+

        From the VPN gateway to the CN:
        +---------------------+
        |IP-S=MN-Perm| Data   |
        |IP-D=CN     |        |
        +---------------------+

7.2.2. Data Flow from the CN to the MN

        From the CN to the actual HA:
        +---------------------+
        |IP-S=CN     | Data   |
        |IP-D=MN-Perm|        |
        +---------------------+

        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=MIPP-Pub | UDP |IP-S=VPNGW-Pub|IPsec-ESP   |IP-S=CN     |Data|
 |IP-D=NATGW-Pub|     |IP-D=NM-Perm  |VPNGW-Pub to|IP-D=MN-Perm|    |
 |              |     |              |MN-Perm     |            |    |
 +------------------------------------------------------------------+

Adrangi, Iyer            Expires January 2002                [Page 28]


Internet Draft draft-adrangi-mipv4-midbox-traversal-00      July 2001



 From the NAT gateway to MN:
 +-------------------------------------------------------------------+
 |IP-S=NATGW-Priv| UDP |IP-S=VPNGW-Pub|IPsec-ESP   |IP-S=CN     |Data|
 |IP-D=MN-Priv   |     |IP-D=NM-Perm  |VPNGW-Pub to|IP-D=MN-Perm|    |
 |               |     |              |MN-Perm     |            |    |
 +-------------------------------------------------------------------+

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 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 and Changwen Liu of
   Intel Corporation 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. References
   [RFC2002] RFC 2002 : IP mobility support
   [RFC3024] RFC 3024 : Reverse tunneling for mobile IP
   [RFC2004] RFC 2004 : Minimal encapsulation within IP
   [RFC1701] RFC 1701 : Generic Routing encapsulation
   [RFC2119] RFC 2119 : Key words for use in RFCs to Indicate
   Requirement Levels
   [RFC1918] RFC 1918 : Address Allocation for Private Internets
   [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>


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 29]


Internet Draft draft-adrangi-mipv4-midbox-traversal-00      July 2001

























































Adrangi, Iyer            Expires January 2002                [Page 30]


Html markup produced by rfcmarkup 1.123, available from https://tools.ietf.org/tools/rfcmarkup/