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

Versions: 02

   Internet Engineering Task Force                     Farid Adrangi
   INTERNET DRAFT                                      Prakash Iyer
   <draft-adrangi-mobileip-vpn-traversal-02>           Intel Corp.
   Date:    July 17 2002
   Expires: January 2003                               Kent Leung
                                                       Milind Kulkarni
                                                       Alpesh Patel
                                                       Cisco Systems

                                                       Qiang Zhang
                                                       Liqwid Networks

                                                       Joe Lau
                                                       Hewlett Packard
                                                       Corp.

              Mobile IPv4 Traversal Across IPsec-based VPN Gateways

   Status of this Memo

        This document is an Internet-Draft and is in full conformance
        with all provisions of Section 10 of RFC2026.

        Internet-Drafts are working documents of the Internet
        Engineering Task Force (IETF), its areas, and its working
        groups. Note that other groups may also distribute working
        documents as Internet-Drafts.

        Internet-Drafts are draft documents valid for a maximum of six
        months and may be updated, replaced, or obsoleted by other
        documents at any time. It is inappropriate to use Internet-
        Drafts as reference material or to cite them other than as "work
        in progress."

        The list of current Internet-Drafts can be accessed at
        http://www.ietf.org/ietf/1id-abstracts.txt

        The list of Internet-Draft Shadow Directories can be accessed at
        http://www.ietf.org/shadow.html.

        To view the entire list of current Internet-Drafts, please
        check the "1id-abstracts.txt" listing contained in the
        Internet-Drafts Shadow Directories on ftp.is.co.za (Africa),
        ftp.nordu.net (Northern Europe), ftp.nis.garr.it (Southern
        Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East
        Coast), or ftp.isi.edu (US West Coast).

   Abstract

        Multi-subnetted IEEE 802.11 WLAN networks are being widely
        deployed in Enterprise Intranets û(in many cases requiring a
        VPN tunnel to connect back and access Intranet resources), and
        public areas such as airports, coffee shops, convention centers
        and shopping malls. Many of these WLAN networks also employ NAT

Expires January 2003.                                         [Page 1]


Internet Draft  draft-adrangi-mobileip-vpn-traversal-02      July 2002


        to translate between non-routable and routable IPv4 care-of
        (point of attachment) addresses. WWAN networks such as those
        based on GPRS, 1xRTT and eventually EDGE, 1xEV, CDMA2000 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 - through NAT gateways when
        needed. This draft proposes a solution framework that enables
        efficient, seamless operation of Mobile IPv4 when combined with
        an IPsec-based VPN and supporting NAT traversal when needed.
        The solution has no link layer dependencies and can be applied
        to other 802.3-compatible wired and wireless physical media as
        well.


   Table Of Contents
   1. Introduction....................................................3
   1.2. Goals.........................................................3
   1.3. Problem Description...........................................4
   1.4. Solution Overview.............................................5
   1.4.1. Assumptions and Applicability...............................5
   1.5. Terminology...................................................6
   1.6. Acronyms......................................................6
   2. Registration....................................................6
   2.1. Authentication................................................7
   2.2. Registration Request Process..................................7
   2.2.1. Registration Request Bits...................................7
   2.2.2. Registration Request Fields.................................8
   2.2.3. Registration Request Extensions.............................8
   2.2.4. Registration Request Validity Check.........................8
   2.3. Registration Reply Process....................................9
   2.3.1. Registration Reply Fields...................................9
   2.4. Registration Reply Initiated by the MIP Proxy................10
   2.4.1. New Registration Reply Codes...............................10
   2.5. Mobile Node Considerations...................................10
   2.5.1. Location Detection.........................................10
   2.5.2. New Configuration Requirement..............................10
   2.5.3. HA Parameter Extension.....................................10
   2.6. MIP Proxy Considerations.....................................11
   2.6.1. Algorithm for location detection...........................11
   2.6.2. Simultaneous Mobility Binding..............................12
   2.6.3. Mobile IP NAI Extension....................................13
   2.6.4. Dynamic HA Assignment......................................13
   2.6.5. Pending Registration List..................................13
   2.6.6. Mobility Bindings..........................................14
   2.6.7. Handling ICMP Error Messages...............................14
   2.7. MIPv4 Registration Packet Flow...............................14
   2.7.1. MIPv4 Registration Request Packet Flow from MN to HA.......14
   2.7.2. MIPv4 Registration Reply Packet Flow from HA to MN.........15
   3. Functions Not Performed By The MIP Proxy.......................15

Adrangi, Iyer            Expires January 2003                 [Page 2]


Internet Draft  draft-adrangi-mobileip-vpn-traversal-02      July 2002


   4. MIP Proxy Integration with VPN.................................16
   4.1. One-Box Integration..........................................16
   4.1.1. Redundancy.................................................16
   4.2. Two-Box Integration..........................................17
   4.2.1. Two-Box Integration Requirements...........................17
   5. MIPv4 Data Traffic Routing Through VPN.........................17
   5.1. Establishment of Secured MIPv4 Traffic.......................17
   5.2. Association Between VPN Inner and MN Home IP Address.........17
   5.3. MIPv4 Data Traffic from MN on External Network to CN.........18
   5.4. MIPv4 Data Traffic from CN to MN on External Network.........20
   5.5. Key Management and SA Preservation...........................22
   5.6. Supporting Other IPsec-based VPN Configurations..............22
   5.7 Routing Considerations........................................22
   5.7.1. Broadcast / multicast Datagrams............................22
   5.7.2. MN Registration through a Trusted FA.......................23
   6. MIPv4 Traversal Through IPsec ôNAT and VPNö Gateways...........23
   6.1. MIPv4 Registration Message Flow..............................24
   6.1.1. MIPv4 Registration Requests................................24
   6.1.2. MIPv4 Registration Replies.................................24
   6.2. MIPv4 Data Flow..............................................25
   6.2.1. Data Flow from the MN to the CN............................25
   6.2.2. Data Flow from the CN to the MN............................25
   7. Security Implications..........................................26
   8. Acknowledgements...............................................26
   9. Intellectual Property Rights...................................27
   10. Revision History..............................................27
   11. References....................................................27


   1. Introduction

     The problem statement and solution requirements for MIPv4
     traversal across VPN gateways are articulated in [15].  To
     understand the motivation and rationale for the solution proposed
     in this draft, we strongly encourage the audience to read [15]
     first.

     This draft introduces a logical component called the Mobile IP
     Proxy (MIP Proxy) to enable seamless Mobile IPv4 functionality
     across VPN gateways, without requiring any IPsec VPN protocol
     changes to VPN gateways.  The solution aims specifically at
     extending the use of deployed IPsec-based VPN gateways, a feature
     that is much desired by corporate IT departments.  The solution
     also leverages [11] to support Mobile traversal across ôNAT and
     VPNö gateways.  The ôNAT and VPNö refers to a network topology
     where Mobile IP traffic has to traverse one or more NAT gateway(s)
     followed by a VPN gateway in the path to its final destination.
     While the discussion in this draft is limited to IPsec-based VPN
     gateways, it should be compatible with other IP-based VPN
     solutions as well.

   1.2. Goals


Adrangi, Iyer            Expires January 2003                 [Page 3]


Internet Draft  draft-adrangi-mobileip-vpn-traversal-02      July 2002


      A MN whose home network is in a protected 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 (i.e, the HA is not directly
      reachable by the MN), as illustrated in Figure 1.2.

      It is desirable in this scenario to connect back to the Intranet
      via a VPN while maintaining the transport connections prior to
      the move, and stay connected as the user roams from one external
      IP subnet to another outside the DMZ, or the user decides to roam
      back inside the DMZ.

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

      Figure 1.2 û MN moves from its home network to a foreign network
      outside the DMZ

   1.3. Problem Description

      With respect to Figure 1.2 above, the problem can be summarized
      in the following 3 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 undesirable performance implications on
      real-time applications.

      Scenario 2: The MN could roam into a foreign subnet with a FA. If
      the MN were to associate a VPN tunnel with its COA, the FA (which
      is likely in a different administrative domain) cannot parse the
      IPsec and will not be able to setup SAs with the MNÆs VPN gateway
      and will consequently not be able to relay MIPv4 packets between
      the MN and the VPN gateway.

      Scenario 3: The MN could roam into a NATÆed network that may or
      may not employ a FA. In this scenario, the MIPv4 traffic has to
      traverse a NAT followed by a VPN gateway.  The problem statement


Adrangi, Iyer            Expires January 2003                 [Page 4]


Internet Draft  draft-adrangi-mobileip-vpn-traversal-02      July 2002


      and solution for MIPv4 traversal across NAT gateways is
      articulated in [11].

   1.4. Solution Overview

      The solution introduces a new Mobile IP logical entity, called
      Mobile IP Proxy (MIP Proxy).  With respect to Figure 1.2 above,
      the MIP Proxy is placed in the DMZ, co-located or running in
      parallel with the VPN. The MIP Proxy is in the path between a MN
      outside the DMZ and its corresponding actual HA.

      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 the MN and its actual 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 SHOULD belong to the same
      administrative domain as any of its associated home agents and
      their corresponding MNs. It MUST share SAs for various MIPv4
      registration extensions with its associated HA(s).

      The MIP Proxy will nominally run on a dual-homed host - one of
      its interfaces on the private (LAN) side, and the other on the
      public (WAN) side. The MIP Proxy can be instantiated on a singly
      homed host - however in this document we assume that the MIP
      Proxy is instantiated on a dual-homed host. The MIP Proxy MAY be
      implemented as a standalone device or combined with a VPN
      gateway.

   1.4.1. Assumptions and Applicability

        The solution is derived based on the following assumptions and
        applicability criteria:

        - An end-to-end IPsec tunnel mode MUST be applied to MIPv4 data
        flows; i.e. between the MN and the VPN gateway at the edge of
        its home network.

        - MIPv4 registration packets MAY NOT require an IPsec tunnel as
        they are authenticated and integrity protected. However, they
        MUST be terminated inside the DMZ to enable authenticated
        firewall traversal.

        - The DMZ outer firewall MUST allow inbound tunneled IP packets
        destined to the MIP Proxy.

        - The DMZ outer firewall MUST permit inbound UDP registration
        packets (destination port = 434 and destination address = MIP
        Proxy interface on the public (WAN) side).

        - The DMZ inner firewall MUST permit the forwarding of
        registration request and reply messages from the MIP Proxy to
        one or more HAs.

Adrangi, Iyer            Expires January 2003                 [Page 5]


Internet Draft  draft-adrangi-mobileip-vpn-traversal-02      July 2002



   1.5. Terminology

      Administrative Domain:
      In the context of this draft an administrative domain is the
      entity that specifies security parameters for Mobile IP
      registration extensions for one or more Home Agents and their
      corresponding mobile nodes. The administrative domain also
      manages policies that govern negotiation of security associations
      for VPN sessions that terminate or initiate at the edge of the
      network under its jurisdiction.

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

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

   1.6. Acronyms

      DMZ: De-Militarized Zone
      FA-COA: Foreign Agent care-of address
      FA-Routed: FAÆs interface address on the routed network
      FA-Visited: FAÆs interface address on the visited network
      GRE: Generic Routing Encapsulation
      IP-D: IP Destination Address
      IP-S: IP source Address
      ISP: Internet Service provider
      MIPv4: Mobile IP for IPv4
      MIPv6: Mobile IP for IPv6
      MN-COA: Co-located care-of address of the MN
      MN-Perm: Permanent home address of the MN
      MIPP-Priv: MIP Proxy interface address on the private (HA) side
      MIPP-Pub: MIP Proxy interface address on the public (Internet)
      side
      NAT: Network Address Translation
      NATGW-Priv: NAT gatewayÆs IP address on the private (LAN) side
      NATGW-Pub: NAT gatewayÆs IP address on the public (WAN) side
      VPNGW-Priv: VPN Gateway Private/Intranet IP Address
      VPNGW-Pub: VPN Gateway Public/External IP Address

   2. Registration

     The MN roaming outside the DMZ sends MIPv4 registration requests
     directly to the MIP Proxy. The registration messages are not
     protected by an IPsec tunnel, and MUST be excluded from the tunnel
     SA applied to flows between the MN and any correspondent hosts via
     the VPN gateway. The MIP Proxy terminates and authenticates the
     registration requests. It then generates a new registration
     request and forwards it to the corresponding actual HA.  The


Adrangi, Iyer            Expires January 2003                 [Page 6]


Internet Draft  draft-adrangi-mobileip-vpn-traversal-02      July 2002


     registration replies from the actual HA will also go through the
     MIP Proxy bypassing the VPN gateway.

     A railroad diagram illustrating the MIPv4 registration process is
     shown below.


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

                Figure 2. û Mobile IP registration protocol between
                               MN and HA

   2.1. Authentication

      Each MN and the MIP proxy MUST share the SA for the MN-HA
      authentication extension.  The MIP Proxy MUST authenticate
      received Registration Requests or Replies before processing them.
      The mechanisms to share SAs are beyond the current scope of this
      draft.  2.2. Registration Request Process

      The MIP Proxy MUST relay all valid Registration Requests received
      from a MN to its actual HA, after updating its pending
      registration request list.  Here, relaying means that the MIP
      Proxy creates a new Registration Request on the behalf of the MN
      and sends it to the MNÆs actual HA. The MIP Proxy MUST be
      compliant with [1], and it MUST adhere to the rules specified in
      the following sub-sections in creating the new Registration
      Request.

   2.2.1. Registration Request Bits

        - The new Registration Request header MAY have the same æMÆ,
        æGÆ, rsv bit values included in the Registration Request
        received from the MN.

        - The æBÆ bit in new Registration Request header MUST be set
        ifthe æBÆ bit in the Registration Request received from the MN
        is set and the MIP Proxy supports broadcast.

        - The æDÆ bit in the new Registration Request MUST NOT be set,
        if the æBÆ bit is set.  Although the surrogate MN side of the
        MIP Proxy always uses a co-located care-of address (i.e, MIPP-
        Priv), this restriction is enforced to cause the actual HA to
        encapsulate a broadcast or a multicast IP datagram in a unicast
        datagram addressed to the MNÆs home address, and then tunnel

Adrangi, Iyer            Expires January 2003                 [Page 7]


Internet Draft  draft-adrangi-mobileip-vpn-traversal-02      July 2002


        this encapsulated datagram to the MIP Proxy (i.e, MIPP-Priv).
        Otherwise, the MIP Proxy will not be able to route the
        broadcast or multicast IP datagrams received from the HA(s), as
        it cannot determine to which MN the packet should be routed.

        - The æTÆ bit in the new Registration Request MUST be set, if
        the MIP Proxy may route the MIPv4 data traffic received from
        the MN to CN in reverse tunneling mode.

        - The new Registration Request MUST NOT set the æSÆ bit, as the
        actual HA will always have the same care-of address (MIPP-Priv)
        for all its MNs roaming outside the DMZ.  Please see section
        2.7.1. for more details.

   2.2.2. Registration Request Fields

        - The new Registration Request header MUST have equal or
        smaller lifetime value included in the registration request
        received from the MN.

        - The new Registration Request header MUST have the same
        identification value included in the Registration Request
        received from the MN.

        - The new Registration Request header MUST have the same Home
        Address value included in the Registration Request received
        from the MN.

        - The new Registration Request headerÆs HA address field MUST
        be set to the MNÆs actual HA address.

        - The new Registration Request headerÆs care-of address field
        MUST be set to MIPP-Priv.

   2.2.3. Registration Request Extensions

        - The new Registration Request MUST contain all Registration
        extensions included in the Registration Request received from
        the MN, with the exception of the ones specific to the MN and
        the MIP Proxy protocol negotiation and the authentication
        extension protecting the registration message between the MN
        and the MIP Proxy.

        - The new Registration Request MUST include the MN-HA
        authentication extension.

   2.2.4. Registration Request Validity Check

        When a Registration Request is received from a MN, the MIP
        proxy MUST validate the registration request and respond to a
        malformed registration request as a HA would, as specified in
        [1]. In addition, the MIP proxy MUST also check the
        Registration Request for the following:

Adrangi, Iyer            Expires January 2003                 [Page 8]


Internet Draft  draft-adrangi-mobileip-vpn-traversal-02      July 2002



        - The æTÆ bit MUST be set in the Registration Request. If not,
        the MIP Proxy MUST return a Registration Reply to the MN with
        an appropriate error code specified in[2].

        - The MIP proxy MUST check for the existence of the HA
        Parameter extension, specified in section 2.6.3. In the absence
        of a valid HA Parameter extension, the MIP proxy MUST return a
        Registration Reply to the MN with an appropriate error code
        specified in section 2.4.1 if MIP Proxy cannot determine an
        appropriate HA to service the MN.

   2.3. Registration Reply Process

      The MIP proxy MUST relay Registration Replies received from
      actual HAs to appropriate MNs.  Here, relaying means that the MIP
      Proxy creates a new Registration Reply on the behalf of the MNÆs
      actual HA and sends it to the MN. The MIP proxy MUST update its
      record of mobility bindings associated with a MN, before relaying
      the registration reply to the MN.

      In processing a registration reply, the MIP proxy MUST be
      compliant with [1]. And, it MUST adhere to the rules specified in
      the following sub-sections.

   2.3.1. Registration Reply Fields

        - The new Registration Reply header MUST have the same Code
        value as in the Registration Reply received from the MNÆs
        actual HA, except when MIP Proxy received accepted Registration
        Reply from the actual HA but cannot service the MN (eg. create
        mobility binding, route, tunnel). In this case, insufficient
        resource (133) error code should be set in the Registration
        Reply to the MN.

        - The new Registration Reply header MUST have the same lifetime
        value as in the Registration Reply received from the MNÆs
        actual HA.  If the lifetime value is zero, the MIP Proxy should
        also retire the entry/entries in its mobility-binding list for
        the MN, as specified in [1].

        - The new Registration Reply header MUST have the same Home
        Address value as in the Registration Reply received from the
        MNÆs actual HA.

        - The new Registration Reply headerÆs Home Agent address field
        MUST be set to MIPP-Pub.

        - The new Registration Reply header MUST have the same
        identification value as the Registration Reply received from
        the MNÆs actual HA.



Adrangi, Iyer            Expires January 2003                 [Page 9]


Internet Draft  draft-adrangi-mobileip-vpn-traversal-02      July 2002


        - The new Registration Reply MUST contain all non-
        authentication extensions included in the Registration Reply
        received from the MNÆs actual HA.

        - The new Registration Reply MUST include the ôMN-HAö
        authentication extension.

        - The new Registration Reply MAY include the ôFA-HAö
        authentication extension, as needed.

   2.4. Registration Reply Initiated by the MIP Proxy

      The MIP proxy MAY deny a Registration Request for various
      reasons. If so, the MIP Proxy MUST use an appropriate
      registration denied code, specified in the following section.

   2.4.1. New Registration Reply Codes

        The following values are defined for use within the Code field.

        Registration denied by the MIP Proxy:

        200    missing HA Parameter extension
        201    non zero HA address Required in HA Parameter extension
        202    home agent unreachable (when ICMP unreachable received)
        203    MISSING-NAI
        204    MISSING-HOMEADDR
        205    MISSING-HOME-AGENT
        206    ASSIGNED-HOME-AGENT

   2.5. Mobile Node Considerations

   2.5.1. Location Detection

        Location detection is done by MIP Proxy and MN is aware of its
        location as per the response from MIP Proxy.  Please see
        section 2.6.1 for more details.

   2.5.2. New Configuration Requirement

        A mobile node MUST be configured with the MIPP-Pub, unless
        dynamic MIPP-Pub discovery is used, which is outside the scope
        of this draft.

   2.5.3. HA Parameter Extension

        When a MN registers with the MIP Proxy, it MUST include the
        non-skippable HA Parameter extension.  This extension is used
        to indicate the IP address of the actual HA to the MIP Proxy.
        HA address in the extension MAY be set to zero, to request
        dynamic HA assignment û please see section 2.7.3. for more
        details.


Adrangi, Iyer            Expires January 2003                [Page 10]


Internet Draft  draft-adrangi-mobileip-vpn-traversal-02      July 2002



    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Type          | Length        |  Sub-Type     |Reserved       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                    Home Agent Address                         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                Type : To be assigned by IANA (non-skippable)
               Length :
                    Indicates the length (in bytes) of the data fields
                    within the extension, excluding the Type and Length
                    bytes.
                Sub-Type: To be assigned by IANA
                Reserved: For future use.
                Home Agent Address: IP address of the MNÆs actual HA

   2.6. MIP Proxy Considerations

   2.6.1. Algorithm for location detection

          MN always communicates to the MIP Proxy (public address),
          whether on internal or external network. MIP Proxy detects
          location of MN either by 1) care-of address in the
          Registration Request or source address if MN registers using
          NAT traversal or 2) inside or outside interface receiving the
          Registration Request.

          As per #1 above, MIP Proxy does location detection based on
          care-of-address in Registration Request. Internal addresses
          (enterprise private and public addresses) are known at the
          MIP Proxy and so MIP Proxy can determine if the care-of-
          address is internal. If the Registration Request from MN
          indicates NAT traversal (mismatch of source and care-of-
          address), MIP Proxy uses the source address to determine the
          location of MN.

          If the network design can guarantee that internal traffic
          reaches the MIP Proxy on internal interface and external
          traffic reaches the MIP Proxy on external interface, then the
          MIP Proxy can interpret the MNÆs location based on the
          interface on which it receives Registration Request, as
          mentioned in #2 above.

          Regardless of location detection algorithm, if the
          Registration Request originates from external network, MIP
          Proxy forwards the Registration Request to the appropriate
          HA. If the Registration Request originates from internal
          network, MIP Proxy rejects the Registration Request with
          error code 206. This informs MN to use the HA address
          specified in HA Parameter Extension.


Adrangi, Iyer            Expires January 2003                [Page 11]


Internet Draft  draft-adrangi-mobileip-vpn-traversal-02      July 2002


          If MN is registering using dynamic HA assignment (HA address
          in HA Parameter Extension set to zero) and if MN is
          registering from internal network, MIP Proxy selects the home
          agent and puts that address in home agent field in HA
          Parameter Extension in Registration Reply with error code
          206. If MN is registering using dynamic HA assignment from
          external network, HA includes the home agent address in HA
          Parameter Extension in Registration Reply (if successful).

          If MN receives a Registration Reply with code set to 206, MN
          interprets as being in internal network and registers
          directly with the home agent. If MN is behind NAT in internal
          network, it will register with the specified home agent using
          UDP tunnel extension. The home agent in this case SHOULD
          support NAT traversal.

          When MN re-registers due to a change in care-of-address, MN
          always registers with the MIP Proxy and includes the HA
          Parameter extension. If MN is just renewing its registration,
          MN registers with HA or MIP Proxy, the entity with which it
          last registered.

          HA Parameter Extension is always present in both Registration
          Request and Registration Reply.

   2.6.2. Simultaneous Mobility Binding

        The MIP proxy MAY support simultaneous mobility bindings,
        regardless of if a MNÆs actual HA supports this feature or not.

        When a Registration Request with an æSÆ bit set (i.e.
        simultaneous binding requested by a MN) is received, the MIP
        proxy MUST NOT set the æSÆ bit in the new Registration Request,
        whether or not it support simultaneous mobility bindings.

        If the MIP Proxy supports simultaneous bindings and it receives
        a Registration Request with an æSÆ set, it MUST set the
        lifetime value in the relayed Registration Request to the
        maximum of the remaining lifetime values of all existing
        mobility bindings for this MN and the lifetime value of the new
        Registration Request received from the MN.  Any subsequent
        Registration Request refreshes received for any of the existing
        simultaneous mobility bindings MUST follow the same rule with
        respect to setting the lifetime value in the Registration
        Request to be relayed to the MNÆs actual home agent.

        When the Registration Reply is received from the MNÆs actual
        HA, the lifetime value in the mobility bindings list for this
        MN MUST be set to the lesser value of the accepted lifetime
        (reflected in the Registration Reply) and the existing lifetime
        (the request lifetime through the Registration Request) in the
        mobility bindings list of the MIP proxy.


Adrangi, Iyer            Expires January 2003                [Page 12]


Internet Draft  draft-adrangi-mobileip-vpn-traversal-02      July 2002


        If the MIP Proxy does not support simultaneous bindings and it
        receives a Registration with an æSÆ bit set, it MUST send a
        Registration Reply to the MN as specified in[1].

   2.6.3. Mobile IP NAI Extension

        The MIP proxy MAY support the Mobile IP NAI extension,
        specified in [14].

        If the MIP Proxy receives a Registration Request whose Home
        Address is zero and includes the Mobile IP NAI extension, it
        MUST use NAI instead in its pending registration request list.
        If the Registration Reply has a non-zero Home Address and
        includes the Mobile IP NAI extension, the MIP Proxy MUST update
        its mobility bindings list for this MN, and relay the
        Registration Reply to the MN.

        The MIP Proxy MUST do the following validity checks, if it
        supports the Mobile IP NAI extension.

        - If Home Address is zero in the Registration Request and the
        MIP Proxy does not support the Mobile IP NAI extension, the MIP
        Proxy MUST silently discard the Request since there is no SA.

        - If the MIP Proxy receives a Registration Request with a value
        of zero in the Home Address field and no NAI extension, it MUST
        silently discard the Request since there is no SA.

        - If the Registration Reply from the MNÆs actual HA does not
        include the Mobile Node NAI extension, the MIP proxy SHOULD
        send the Registration Reply to the mobile node with an error
        code indicating MISSING-NAI, as defined in section 2.4.1.

        - If the Registration Reply from the MNÆs actual HA includes a
        zero Home Address or zero Home Agent address, the MIP proxy
        SHOULD send the Registration Reply to the mobile node with an
        error code indicating MISSING-HOMEADDR or MISSING-HOME-AGENT,
        as defined in section 2.4.1.

   2.6.4. Dynamic HA Assignment

        The MIP proxy MAY support dynamic HA assignment in conjunction
        with dynamic home address assignment for a MN. If the MN sends
        a Registration Request with the Home Agent field set to zero in
        the HA Parameter extension and includes a valid NAI extension,
        the MIP Proxy can dynamically assign a HA from a pool of HA IP
        addresses. The selection of a HA is beyond the scope of this
        draft. The selected HA MUST support the NAI extension in the
        Registration Request. However, this scheme is NOT intended to
        support dynamic HA handovers.

   2.6.5. Pending Registration List


Adrangi, Iyer            Expires January 2003                [Page 13]


Internet Draft  draft-adrangi-mobileip-vpn-traversal-02      July 2002


        For each pending registration, the MIP Proxy maintains the
        following information:

        - The IP destination address of the actual HA
        - The care-of address in the received Registration Request
        - The identification in the received Registration Request
        - The lifetime in the received Registration Request, and
        - The remaining Lifetime of the pending registration

   2.6.6. Mobility Bindings

        The MIP Proxy MUST maintain a mobility binding list similar to
        the one specified in [1] for a HA, in order to forward the
        registration replies and subsequent MIPv4 data traffic. The MIP
        Proxy updates its binding table, when a successful Registration
        Reply is received from an actual HA.

        For each mobility binding entry, the MIP Proxy maintains the
        following information:

        - The IP destination address of the actual HA
        - The home address of the MN
        - NAI if in the received Registration Request
        - The care-of address in the received Registration Request
        - The identification in the received Registration Request
        - The lifetime in the received Registration Request, and

        The MIP Proxy MUST also use the same methods defined in [1] for
        deleting or retiring the entries in its mobility-binding
        list(s).

   2.6.7. Handling ICMP Error Messages

        When the MIP Proxy sends a Registration Request to an actual HA
        on the behalf of a MN, it may receive an ICMP error message
        indicating that the actual HA is not reachable for a specific
        reason (i.e., network unreachable, host unreachable, port
        unreachable, protocol unreachable).  If so, the MIP Proxy MUST
        send a Registration Reply to the MN with Code indicating why
        the actual HA was not reachable.

   2.7. MIPv4 Registration Packet Flow

   2.7.1. MIPv4 Registration Request Packet Flow from MN to HA

        This draft illustrates the sequence from MN to HA via a FA û it
        can be easily extended to describe the flow for a co-located
        COA mode MN.






Adrangi, Iyer            Expires January 2003                [Page 14]


Internet Draft  draft-adrangi-mobileip-vpn-traversal-02      July 2002


        From the MN to a FA:
                +--------------------------------------------------+
                |IP-S = MN-Perm   | Permanent Address = MN-Perm    |
                |IP-D = FA-Visited| Home Agent = MIPP-Pub          |
                |                 | Care-of Address = FA-COA       |
                |                 |     . . .                      |
                +--------------------------------------------------+

        From the FA to the MIP Proxy:
                +--------------------------------------------------+
                |IP-S = FA-Routed | 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    |
                |                 |                                |
                +--------------------------------------------------+

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

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

   3. Functions Not Performed By The MIP Proxy

     The MIP Proxy MUST NOT perform the following HA functions, as
     defined in [1]:

     - It MUST NOT generate agent advertisements
     - It MUST NOT send gratuitous ARPs

Adrangi, Iyer            Expires January 2003                [Page 15]


Internet Draft  draft-adrangi-mobileip-vpn-traversal-02      July 2002


     - It MUST NOT perform Proxy ARP
     - It MUST NOT support Route Optimization [10]

     The MIP proxy MUST NOT perform the following MN functions, as
     specified by [1]:

     - It MUST NOT generate agent solicitations or functions pertaining
     to agent discovery
     - It MUST NOT implement any move detection mechanisms
     - The MIP Proxy MUST NOT manage registration lifetimes and MUST
     NOT reinitiate a registration request with the actual HA prior to
     its expiration.

   4. MIP Proxy Integration with VPN

     The MIP Proxy as described in this draft is a logical functional
     entity and as such can be integrated with VPN in 2 possible ways,
     which are one-box and two-box solutions.

   4.1. One-Box Integration

      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.  Figure 4.1. depicts a network stack resulted
      from the one-box integration of the MIP proxy with the VPN
      gateway.  Please note that IPsec and the MIP Proxy layers can be
      combined into one layer (tightly coupled integration), or they
      can be layered as shown in figure 4.1. (loosely coupled
      integration).

                             +------------+
                             |   TCP/IP   |
                             +------------+
                             |   IPsec    |
                             +------------+
                             |  MIP Proxy |
                             +------------+
                             | Link Layer |
                             +------------+
                             | Physical   |
                             |  Layer     |
                             +------------+

               Figure 4.1. û One-Box Integration of MIP Proxy with VPN

   4.1.1. Redundancy

        A MIP Proxy redundancy protocol is desirable to effect high
        availability in public and Enterprise deployments, when two box
        solution approach is used. Details of such a protocol are
        beyond the current scope of this draft.


Adrangi, Iyer            Expires January 2003                [Page 16]


Internet Draft  draft-adrangi-mobileip-vpn-traversal-02      July 2002


   4.2. Two-Box Integration

      Implemented as a standalone device deployed in parallel with the
      VPN gateway as depicted in Figure 1.2. This decouples support for
      MIPv4 users from any software or hardware upgrades to the VPN
      gateway itself and also enables multi-vendor interoperability.
      The scheme however adds some overhead to the end-to-end
      communication path between a MN and a CN.

   4.2.1. Two-Box Integration Requirements

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

        - The MIP Proxy MUST be able to forward packets (destined to
        MN) to VPN gateway via layer 2 mechanism.  This implies that
        the MIP Proxy and VPN Gateway MUST be on the same subnet.

   5. MIPv4 Data Traffic Routing Through VPN

     This section describes MIPv4 data traffic flow through VPN with
     the aid of the MIP Proxy.  For clarity, this section assumes a
     two-box solution approach.

   5.1. Establishment of Secured MIPv4 Traffic

      There are two steps that MUST be successfully completed in order
      to establish secured MIPv4 traffic between a MN and a CN.

      The first step is that the MN MUST complete MIPv4 registration
      with its actual home agent through the MIP Proxy, as discussed in
      section 2.  The second step is that the MN MUST establish IPsec
      tunnel SA to the VPN gateway through the MIP Proxy, as shown in
      Figure 3.a.  Any subsequent registration and SA refreshes may
      occur independent of each other.


                MN              MIP Proxy       VPN Gateway
                |  IKE-Phase 1/MIPv4                     |
                | -------------->   | IKE-phase 1        |
                |                   |----------------->  |
                |                   | IKE-phase 2        |
                |  IKE-Phase 2/MIPv4|<-------------------|
                | <---------------- |                    |

                Figure 3.a û IPsec Tunnel SA Establishment
                             (Two Box Solution)


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

   5.2. Association Between VPN Inner and MN Home IP Address

Adrangi, Iyer            Expires January 2003                [Page 17]


Internet Draft  draft-adrangi-mobileip-vpn-traversal-02      July 2002



      To support continuous mobility and constant reachability, the
      tunnel inner IP address assigned to a MN MUST be the same as the
      home IP address.

   5.3. MIPv4 Data Traffic from MN on External Network 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 or FA-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 MIP Proxy MUST perform the following validity checks on
      received MIP data packets whose destination IP address is set to
      MIPP-Pub (i.e., packets received from outside the DMZ).

          - The received packet MUST be encapsulated by an appropriate
          method (e.g., IP-in-IP, Minimal Encapsulation, GRE) that the
          MIP Proxy supports
          - The inner IP packetÆs destination IP address MUST be set to
          a VPN gateway IP address that the MIP Proxy supports
          - An ESP header MUST follow the inner IP header

      If any of above validity checks fail, then the MIP Proxy MUST
      silently drop the packet.

      The packet routing from the MIP Proxy to the CN may differ
      depending on whether the CN belongs to any of ômobility subnetsö
      that the MIP Proxy supports.  The following railroad diagrams
      depict the packet flow sequence for both cases, followed by a
      description of packets as they traverse the network.


        MN      FA      MIP Proxy       VPN Gateway     HA       CN
        |       |          |                |           |         |
        | ----> |          |                |           |         |
        |       | ----->   |                |           |         |
        |       |          | ------------>  |           |         |
        |       |          |                | ----------------->  |

      Figure 5.2a û Packet flow from MN to CN, where the CN does not
      belong to any of ôMobility subnetsö that the MIP Proxy supports

      From the MN to FA:        IP-ESP-IP-Data
      From the FA to MIP Proxy: IP-IP-ESP-IP-Data
      From MIP Proxy to VPN:    IP-ESP-IP-Data
      From VPN Gateway to CN:   IP-Data



Adrangi, Iyer            Expires January 2003                [Page 18]


Internet Draft  draft-adrangi-mobileip-vpn-traversal-02      July 2002


        MN      FA      MIP Proxy       VPN Gateway     HA       CN
        |       |          |                |           |         |
        | ----> |          |                |           |         |
        |       | ----->   |                |           |         |
        |       |          | ------------>  |           |         |
        |       |          | <-----------   |           |         |
        |       |          | -------------------------->|         |
        |       |          |                |           |-------->|
        |       |          |                OR                    |
        |       |          |----------------------------------->  |

      Figure 5.2b û Packet flow from MN to CN, where the CN belongs to
      a ôMobility subnetö that the MIP Proxy supports

      From the MN to FA:        IP-ESP-IP-Data
      From the FA to MIP Proxy: IP-IP-ESP-IP-Data
      From MIP Proxy to VPN:    IP-ESP-IP-Data
      From VPN Gateway to MIP Proxy:   IP-Data
      (forwarded back to the MIP Proxy using via Network route
      installed on the VPN gateway)

      Reverse tunneling delivery method is used:
      ------------------------------------------
      From MIP Proxy to HA:     IP-IP-Data
      From HA to CN:            IP-Data

      Non-Reverse Tunneling delivery method is used:
      ----------------------------------------------
      From MIP Proxy to CN:     IP-Data


      The packet flow analysis from the MN to the CN is described
      below. The analysis assumes that the CN does not belong to any
      ômobility subnetsö that the MIP Proxy supports.

      From the MN to the FA:
      +------------------------------------------------+
      | IP-S=MN-Perm  |IPsec-ESP |IP-S=MN-Perm| Data   |
      | 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-Routed|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. FA only reverse tunnel traffic to the MIP
      Proxy.

Adrangi, Iyer            Expires January 2003                [Page 19]


Internet Draft  draft-adrangi-mobileip-vpn-traversal-02      July 2002



      From the MIP Proxy to the VPN gateway:
      The MIP Proxy strips off the outermost IP header and forwards the
      packet (whose destination address is set to VPNGW-Pub) 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:
      The VPN gateway completes IPsec tunnel processing on the packet,
      strips off the outermost IP and ESP headers and forwards the
      original IP datagram to the CN.

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

   5.4. MIPv4 Data Traffic from CN to MN on External Network

      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 CN to the HA:                     IP-Data
      From the HA to the MIP Proxy:          IP-IP-Data
      From the MIP Proxy to the VPN gateway: IP-Data
      From the VPN gateway to the MIP Proxy: IP-ESP-IP-Data
      From the MIP Proxy to the FA:          IP-IP-ESP-IP-Data
      From the FA to the MN:                 IP-ESP-IP-Data


Adrangi, Iyer            Expires January 2003                [Page 20]


Internet Draft  draft-adrangi-mobileip-vpn-traversal-02      July 2002


      The packet flow from the CN to the MN is described below.
      From the CN to the actual HA:
      +---------------------+
      |IP-S=CN     | Data   |
      |IP-D=MN-Perm|        |
      +---------------------+

      The packet is intercepted by the actual HA, as the MN has moved
      outside its home subnet.

      From the actual HA to the MIP Proxy:


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

      From the MIP Proxy to the VPN gateway:
      The MIP Proxy strips off the outermost IP header and forwards the
      packet to the VPNGW-Priv interface using the corresponding layer-
      2 address.

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

      From the VPN gateway to the MIP Proxy:
      The VPN gateway applies an IPsec ESP tunnel SA to the IP packet
      and forwards it back to the MIP Proxy on the MIPP-Pub interface
      based on its routing table.

      +-------------------------------------------------+
      |IP-S=VPNGW-Pub|IPsec-ESP   |IP-S=CN     | Data   |
      |IP-D=MN-Perm  |VPNGW-Pub to|IP-D=MN-Perm|        |
      |              |MN-Perm     |            |        |
      +-------------------------------------------------+

      From the MIP Proxy to the FA:
      The MIP Proxy adds an outer encapsulating IP header to the FA
      COA.
      +--------------------------------------------------------+
      |IP-S=MIPP-Pub|IP-S=VPNGW-Pub|IPsec-ESP   |IP-S=CN | Data|
      |IP-D=FA-COA  |IP-D=MN-Perm  |VPNGW-Pub to|IP-D=   |     |
      |             |              |MN-Perm     | MN-Perm|     |
      +--------------------------------------------------------+







Adrangi, Iyer            Expires January 2003                [Page 21]


Internet Draft  draft-adrangi-mobileip-vpn-traversal-02      July 2002


      From the FA to the MN:
      The FA strips off the outermost IP header and forwards the packet
      to the MN.
      +-------------------------------------------------+
      |IP-S=VPNGW-Pub|IPsec-ESP   |IP-S=CN     | Data   |
      |IP-D=MN-Perm  |VPNGW-Pub to|IP-D=MN-Perm|        |
      |              |MN-Perm     |            |        |
      +-------------------------------------------------+

       The MN terminates the IPsec tunnel and processes the MIPv4 data
      as always.

   5.5. Key Management and SA Preservation

      The MIPv4 data traffic routing described in the previous section
      binds the IPsec tunnel SA to the normally invariant permanent
      (home) IP address of the MN. This implies that the tunnel SA can
      be preserved even when the MN changes its co-located COA or
      connects via a FA in a different IP subnet. The SA however must
      be refreshed prior to its lifetime expiration. Also, many VPN
      gateway implementations support some keep-alive mechanism to
      detect the presence of a VPN client and ôretireö the SA if the
      VPN client is not detected for a period of time. If a MN loses
      link connectivity for a period extending the keep-alive timeout
      interval, it MUST reestablish the tunnel SA, regardless of
      whether it reconnects to the same IP subnet or not.

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

   5.6. Supporting Other IPsec-based VPN Configurations

      The scheme currently described in this draft assumes a native
      IPsec VPN scheme extended to support secondary authentication
      schemes. However the solution should apply to L2TP over IPsec
      transport [12] and ESP-in-UDP VPN [13] configurations as well.

      Note that ESP-in-UDP VPN is not necessary when Mobile IP UDP
      tunnels [11] are in use.

   5.7 Routing Considerations

      VPN gateway must insert a route for the home network(s) to point
      to the MIP Proxy. This route MUST not be redistributed via an
      IGP.

      On the MIP Proxy, packets that come from a MIP tunnel (on either
      the Public or Private interface) must be forwarded (via layer-two
      mechanism) to the VPN Gateway for IPSec tunnel
      encapsulation/decapsulation.

   5.7.1. Broadcast / multicast Datagrams


Adrangi, Iyer            Expires January 2003                [Page 22]


Internet Draft  draft-adrangi-mobileip-vpn-traversal-02      July 2002


        When an actual HA receives a broadcast or a multicast datagram,
        it forwards the datagram to the MIP proxy for any qualified MNs
        outside the DMZ.

        Since the MIP proxy always unsets the æDÆ bit in a Registration
        Request that it sends to the actual HA on the behalf of the MN
        (see section 2.2.1), the actual home agent applies double
        encapsulation on broadcast or multicast packets that need to be
        forwarded to the MN, as specified in [1].  When the MIP Proxy
        receives the double encapsulated packets from an actual HA, it
        decapsulates the outer IP header, and then forwards the packet
        to the VPN as shown below.


        From Actual HA to the MIP Proxy:
        +--------------------------------------------------+
        |IP-S=HA       |IP-S=HA  | IP-S=CN        | Data   |
        |IP-D=MIPP-Priv|IP-D=MN  | IP-D=Bcast or  |        |
        |              |         | IP-D=Mcast     |        |
        +--------------------------------------------------+

        From the MIP Proxy to VPN:
        +-----------------------------------+
        |IP-S=HA  | IP-S=CN        | Data   |
        |IP-D=MN  | IP-D=Bcast or  |        |
        |         | IP-D=Mcast     |        |
        +-----------------------------------+

   5.7.2. MN Registration through a Trusted FA

        A MN may roam into a network served by a trusted FA. The
        trusted FA refers to a FA that has SA with the VPN-GW or a FA
        whose hosting network has SA with VPN-GW and an IPsec tunnel
        will be established between the FA or its hosting network and
        the VPN-GW while necessary to protect any traffic between.  In
        this case, the MN MUST use the NAI extension in the FA route
        advertisement or other mechanisms which are out of the scope of
        this draft to determine that the FA is a trusted FA. The MN
        MUST not use the MIP Proxy in this scenario, the FA is
        responsible for properly tunneling the traffic including the
        MIP signaling and data through the VPN-GW.

   6. MIPv4 Traversal Through IPsec ôNAT and VPNö Gateways

     This section extends MIPv4 VPN traversal solution described in
     section 5 to support MIPv4 traversal across ôNAT and VPNö
     scenario, in which MN has to traverse one or more NAT gateway(s)
     followed by a VPN gateway in the path to its final destination.

     A solution for MIPv4 traversal across intervening NAT gateways is
     provided in [11] through a MN/HA protocol extension. The solution
     cannot be directly applied here, since the MNÆs home agent is not


Adrangi, Iyer            Expires January 2003                [Page 23]


Internet Draft  draft-adrangi-mobileip-vpn-traversal-02      July 2002


     directly reachable. However, the solution can be leveraged by
     simply corresponding the MIP Proxy surrogate HA to the HA in [11].

     The following sub-sections show MIPv4 control and data packets
     flow between a MN and a CN.

   6.1. MIPv4 Registration Message Flow
   6.1.1. MIPv4 Registration Requests

        From the MN to the NAT gateway:
                +-----------------------------------------------+
                |IP-S=MN-Perm   | Permanent Address = MN-Perm   |
                |IP-D=MIPP-Pub  | Home Agent = MIPP-Pub         |
                |               | Care-of Address = MN-COA      |
                |               |   . . .                       |
                +-----------------------------------------------+
        Please refer to section 4.5 and the [11] draft for detailed
        discussion of required registration extensions.

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

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

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

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

   6.1.2. MIPv4 Registration Replies

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





Adrangi, Iyer            Expires January 2003                [Page 24]


Internet Draft  draft-adrangi-mobileip-vpn-traversal-02      July 2002


        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=MIPP-Pub   | Home Agent = MIPP-Pub |
                |IP-D=MN COA     |      . . .            |
                +----------------------------------------+

   6.2. MIPv4 Data Flow

   6.2.1. Data Flow from the MN to the CN

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

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

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


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

   6.2.2. Data Flow from the CN to the MN

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

Adrangi, Iyer            Expires January 2003                [Page 25]


Internet Draft  draft-adrangi-mobileip-vpn-traversal-02      July 2002



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

        From the MIP proxy to the VPN gateway:
        The MIP proxy strips off the outer IP header and forwards the
        packet on the layer-2 address for VPNGW-Priv.
        +---------------------+
        |IP-S=CN     | Data   |
        |IP-D=MN-Perm|        |
        +---------------------+

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

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

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

   7. 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 vulnerability to
     the mobile IP protocol.


   8. Acknowledgements



Adrangi, Iyer            Expires January 2003                [Page 26]


Internet Draft  draft-adrangi-mobileip-vpn-traversal-02      July 2002


     The authors would like to thank Mike Andrews, Changwen Liu and
     Ranjit Narjala of Intel Corporation, Sami Vaarala of Netseal,
     Alexis Oliverean of Motorola for their review and feedback on this
     draft.

   9. Intellectual Property Rights

     Intel Corporation is in the process of filing one or more patent
     applications that may be relevant to this IETF draft.

     Cisco Systems is in the process of filing one or more patent
     applications that may be relevant to this IETF draft.

   10. Revision History

     1) Initial Version
                        9/2001

     2) Second Version 3/2002
       + Modified the draft to meet requirements defined in
              [15]
       + General Clean up
       + Made changes to reflect comments/feedbacks from
              Sami Vaarala of Netseal, Qiang Zhang of
              Ecutel, Alexis Oliverean of Motorola

   11. References

     [1] Perkins. IP mobility support for IPv4. RFC 3220, January 2002
     [2] Montenegro.  Reverse tunneling for mobile IP. RFC 3024,
     January 2001
     [3] Perkins. Minimal encapsulation within IP. RFC 2004, October
     1996
     [4] Hanks, Farinacci, Traina. Generic Routing encapsulation. RFC
     1701, October 1994
     [5] Bradner.  Key words for use in RFCs to Indicate Requirement
     Levels. RFC 2119, March 1997
     [6] Rekhter, Moskowitz, Karrenberg. Address Allocation for Private
     Internets. RFC 1918, Feburary 1996
     [7] Droms.  Dynamic Host Configuration Protocol. RFC 2131, March
     1997
     [8] <draft-bpatil-mobileip-sec-guide-01.txt> - Requirements /
     Implementation Guidelines for Mobile IP using IP Security
     [9] Cheshire, Aboba. Dynamic Configuration of IPv4 Link-Local
     Addresses. <draft-ietf-zeroconf-ipv4-linklocal-03>, April 2002
     [10] Perkins, Johnson. Route Optimization in Mobile IP. <draft-
     ietf-mobileip-optim-11.txt>, September 2001
     [11] Levkowetz, Vaarala. Mobile IP NAT/NAPT Traversal using UDP
     Tunneling. <draft-ietf-mobileip-nat-traversal-01.txt>, March 2002
     [12] Patel, Aboba, Zorn, Booth, RFC 3193 û Securing L2TP with
     IPsec
     [13] Huttunen , Dixon, Swander. UDP Encapsulation of IPsec Packets
     <draft-ietf-ipsec-udp-encaps-02>, April 2002


Adrangi, Iyer            Expires January 2003                [Page 27]


Internet Draft  draft-adrangi-mobileip-vpn-traversal-02      July 2002


     [14] Calhoun, Perkins. Mobile IP Network Access Identifier
     Extension for IPv4. RFC 2794, March 2000
     [15] Adrangi, Leung, Kulkarni, Patel, Zhang, Lau. Problem
     Statement and Requirements for Mobile IPv4 Traversal Across VPN
     Gateways. <draft-ietf-mobileip-vpn-problem-statement-00.txt>,
     March 2002

   Authors:

   Farid Adrangi        Email: farid.adrangi@intel.com
                        Phone: 503-712-1791
   Prakash Iyer         Email: prakash.iyer@intel.com
                        Phone: 503-264-1815

   Intel Corporation
   2111 N.E. 25th Avenue
   Hillsboro, OR 97124
   USA

   Kent Leung         Email: kleung@cisco.com     Phone: 408-526-5030
   Milind Kulkarni    Email: mkulkarn@cisco.com   Phone: 408-527-8382
   Alpesh Patel       Email: alpesh@cisco.com     Phone: 408-853-9580

   Cisco Systems
   170 W. Tasman Drive,
   San Jose, CA 95134

   Qiang Zhang          Email: qzhang@liqwidnet.com
                               Phone:703 8641327
   Liqwid Networks Inc.

   Joe Lau              Email: jlau@cup.hp.com  Phone: 408 447-2159
   Hewlett-Packard Company
   19420 Homestead Road, MS 4301
   Cupertino, CA 95014


















Adrangi, Iyer            Expires January 2003                [Page 28]


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