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

Versions: 00

   Internet Engineering Task Force                      Farid Adrangi
   INTERNET DRAFT                                       Prakash Iyer
   Category: Informational                              Intel Corp.

                                                        Kent Leung
                                                        Milind  Kulkarni
                                                        Alpesh Patel
                                                        Cisco Systems

                                                        Qiang Zhang
                                                        Liqwidnet Inc.

                                                        Joe Lau
                                                        Hewlett Packard
                                                        Corp.


   <draft-ietf-mobileip-vpn-problem-statement-00>
   Date:    March 2002


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

Expires September 2002.                                       [Page 1]


Internet Draft  draft-ietf-mobileip-vpn-problem-statement-00 March 2002


        Mobile IP [1] agents are being deployed in enterprise networks,
        to enable mobile users with network mobility across wired and
        wireless LANs while roaming inside the enterprise firewall.
        With the growing deployment of multi-subnetted IEEE 802.11
        networks (referred as hot spots) in public places such as
        hotels, airports, and convention centers, and wireless WAN data
        networks such as GPRS, the need for enabling mobile users to
        maintain their transport connections and constant reachability
        while connecting back to their target ôhomeö networks protected
        by VPNs is increasing.  This draft identifies example usage
        scenarios for enterprise users roaming outside the firewall,
        and defines a problem statement based on the scenarios.


   Table of Contents

   1. Introduction....................................................2
   2. Terminology.....................................................3
   3. Acronyms........................................................3
   4.0. Roaming Scenarios.............................................3
   4.1. Accessing Services Inside the Home Network....................4
   4.2. Accessing Services From Outside the Home Network..............4
   5.1. MN registers with its HA using co-located mode................5
   5.2. MN registers with its HA via a FA (non co-located mode).......5
   6. Problem Statement...............................................6
   6.1. MIPv4 Incompatibilities with VPN Gateways.....................7
   7. MIPv6 Considerations............................................8
   8. Revisions History...............................................8
   9. References......................................................8


   1. Introduction

        Multi-subnetted IEEE 802.11 WLAN networks are being widely
        deployed in Enterprise Intranets - in many cases requiring a
        VPN tunnel to connect back and access Intranet resources, and
        public areas such as airports, coffee shops, convention centers
        and shopping malls. Wireless WAN networks such as those based
        on GPRS and eventually EDGE and UMTS are also starting to see
        deployment.  These  deployments  are  paving  the  way  for
        applications  and  usage  scenarios  requiring  TCP/IP  session
        persistence and constant reachability while connecting back to
        a secured (VPN protected), target ôhomeö network. This in turn
        drives the need for a mobile VPN solution that is multi-vendor
        interoperable, providing seamless access with persistent VPN
        sessions. This draft identifies example usage scenarios, and
        defines a problem statement based on the scenarios.

        The important sections of this draft are organized as follows:

            Section  4:  Describe  roaming  scenarios  to  motivate  the
                       problem statement


Adrangi, Iyer           Expires September 2002                [Page 2]


Internet Draft  draft-ietf-mobileip-vpn-problem-statement-00 March 2002


            Section  5:  Describes  a  problem  statement  for  MIPv4
                       traversal across VPN gateways.

   2. Terminology

   3. Acronyms
        ACL: Access Control List
        MIPv4: Mobile IP for IPv4
        MIPv6: Mobile IP for IPv6
        VPN: Virtual Private Network

        MN-HoA: Permanent home address of the MN
        MN-CoA: Co-located care-of address of the MN
        VPN_E_Addr: VPN Gateway External IP Address
        WLAN: IEEE 802.11 (a/b/g) Wireless Local Area Network

   4.0. Roaming Scenarios

        This section describes roaming scenarios, wherein a mobile user
        roaming  outside  the  firewall  needs  to  connect  to  his/her
        ôtargetö home network protected by a VPN.  The scenarios are
        constructed based on a multi-subnetted MIPv4 enabled Intranet
        (hereafter, referred by Home Network or VPN domain) protected
        by an IPsec-based VPN gateway as depicted in Figure 4.0a.

        +---------+       +------+   +---------------------------+
        |         |       |      |   |Home network / VPN Domain  |
        |         |       |IPsec-|   | +----+ +-----+ +----+     |
        |Internet |       |based |<->| |HA-1  | HA-2| |HA-n|     |
        |         |       |      |   | +----+ +-----+ +----+     |
        |         |       | VPN  |   |                           |
        +---------+       +------+   | +----+ +-----+ +----+     |
                                     | |FA-1| | FA-2| |FA-n|     |
                                     | +----+ +-----+ +----+     |
                                     |                           |
                                     | +----+ +-----+ +-----+    |
                                     | |MN-1| | MN-2| | MN-n|    |
                                     | +----+ +-----+ +-----+    |
                                     +---------------------------+

           Figure 4.0a û Home Network protected by a VPN Gateway

        The home network, depicted in Figure 4.0a, may include both
        wired (IEEE 802.3) and IEEE 802.11 wireless LAN deployments.
        However, it is also possible to see IEEE 802.11 deployments
        outside the home network due to the perceived lack of 802.1x
        security, as depicted in Figure 4.0b.







Adrangi, Iyer           Expires September 2002                [Page 3]


Internet Draft  draft-ietf-mobileip-vpn-problem-statement-00 March 2002


        +---------+       +------+   +---------------------------+
        |         |       |      |   |Home network / VPN Domain  |
        |         |       |IPsec-|   | +----+ +-----+ +----+     |
        |Internet |   |-->|based |<->| |HA-1| | HA-2| |HA-n|     |
        |         |   |   |      |   | +----+ +-----+ +----+     |
        |         |   |   | VPN  |   |                           |
        +---------+   |   +------+   | +----+ +-----+ +----+     |
                      |              | |FA-1| | FA-2| |FA-n|     |
                      |              | +----+ +-----+ +----+     |
           +-----------------+       |                           |
           |                 |       | +----+ +-----+ +-----+    |
           | 802.11 Wireless |       | |MN-1| | MN-2| | MN-n|    |
           |  Network        |       | +----+ +-----+ +-----+    |
           |                 |       +---------------------------+
           +-----------------+

        Figure 4.0b û IEEE 802.11 Wireless deployment outside the home
                      network

        It is important to note that MIPv4 mobility agents inside the
        home network are likely to be deployed in existing routers from
        vendor X while VPN client/server solutions may come from vendor
        Y and mobility clients (MN) may come from yet another vendor.
        This is very typical as medium and large Enterprises purchase
        and deploy best-of-breed multi-vendor solutions for IP routing,
        VPNs, firewalls etc.

        To help describe scenarios in the following sections, we have
        used the aid of an imaginary mobile user, called Dr. Joe.

        Dr. Joe is a chief surgeon in a hospital, and always on the
        move. He leverages his wireless MIPv4 enabled hand-held device
        to  access  his  patientÆs  records,  communicate  with  his
        colleagues  and  staff,  and  stay  reachable  in  case  of  any
        emergencies.  For clarity, we assume that Dr. JoeÆs hospital
        employs a network similar to the one showed in Figure 4.0a
        (MIPv4 enabled network protected by a VPN, and includes both
        wired and IEEE 802.11 wireless deployments).

   4.1. Accessing Services Inside the Home Network

        Dr. JoeÆs needs for constant reachablity and maintaining his
        current transport connections as he roams from one network link
        to another are met by standard MIPv4 [1] deployment inside the
        home network.

   4.2. Accessing Services From Outside the Home Network

        Dr. Joe frequently visits other clinics and hospitals, in which
        a multi-subnetted IEEE 802.11 hot spot network is utilized to
        provide Internet access for visitors.  Dr. Joe leverages the
        hot spot network to connect to his home network, and he would
        also like to maintain his transport connections to the home

Adrangi, Iyer           Expires September 2002                [Page 4]


Internet Draft  draft-ietf-mobileip-vpn-problem-statement-00 March 2002


        network as he roams from one network link to another in the
        visited network.

        Dr. Joe needs to establish an IPsec tunnel to the VPN gateway
        first so that he can register with the home agent while roaming
        outside the home network.  This implies that the MIPv4 traffic
        destined to the home network has to run inside an IPsec tunnel.

        The different registration modes of the MN are described in
        sections below.

   5.0. Operational Configurations

   5.1. MN registers with its HA using co-located mode

        +---------+       +------+   +---------------------------+
        |Internet |       |      |   |Home network /VPN Domain   |
        |  |--------------|IPsec-|   | +----+ +-----+ +----+     |
        |  |  |-----------|based |<->| |HA-1  | HA-2| |HA-n|     |
        +--|--|---+       |VPN   |   | +----+ +-----+ +----+     |
           |  |           +------+   |                           |
           |  |                      | +----+ +-----+ +----+     |
           |  |<-- IPsec Tunnel      | |FA-1| | FA-2| |FA-n|     |
           |  |                      | +----+ +-----+ +----+     |
           |  |                      |                           |
       +---|--|---+                  | +----+ +-----+ +-----+    |
       |   |  |   |                  | |MN-1| |MN-2 | |MN-n |    |
       | +-|--|-+ |                  | +----+ +-----+ +-----+    |
       | | MN   | |                  |                           |
       | +------+ |                  +---------------------------+
       | Multi-   |
       | Subnetted|
       | Hot Spot |
       |          |
       +----------+
        Figure 5.1.

   5.2. MN registers with its HA via a FA (non co-located mode)

         There are 2 cases to consider.
         Case 1:
         The FA is trusted, i.e. an SA has been established a priori
         between the FA and the home VPN gateway.  In this case, the
         IPsec tunnel end-points are the FA and home VPN gateway.
         Furthermore, it is also possible for the MN in a trusted FA
         region to have end-to-end security with its home VPN gateway.
         This implies that there will be two concurrent IPsec tunnels,
         one between the FA and home VPN gateway, and the other between
         the MN and its home VPN gateway. Figure 5.2a shows the MN in a
         trusted FA region, where there is only an IPsec tunnel between
         the FA and the home VPN gateway.



Adrangi, Iyer           Expires September 2002                [Page 5]


Internet Draft  draft-ietf-mobileip-vpn-problem-statement-00 March 2002


         Case2:
         In a non-trusted FA region, i.e. where there is no SA between
         the FA and the home VPN gateway, there will always be a single
         IPsec tunnel established between the MN and its home VPN
         gateway, as depicted in Figure 5.2b.


        +---------+       +------+   +---------------------------+
        |Internet |       |      |   |Home network /VPN Domain   |
        |  |--------------|IPsec-|   | +----+ +-----+ +----+     |
        |  |  ------------|based |<->| |HA-1  | HA-2| |HA-n|     |
        +--|--|---+       |VPN   |   | +----+ +-----+ +----+     |
           |  |           +------+   |                           |
        +--|--|----+                 | +----+ +-----+ +----+     |
        | +|--|+   |                 | |FA-1| | FA-2| |FA-n|     |
        | | FA |   |                 | +----+ +-----+ +----+     |
        | +----+   |                 |                           |
        |          |                 | +----+ +-----+ +-----+    |
        | +----+   |                 | |MN-1| |MN-2 | |MN-n |    |
        | |MN  |   |                 | +----+ +-----+ +-----+    |
        | +----+   |                 |                           |
        | Multi-   |                 +---------------------------+
        | Subnetted|
        | Hot Spot |
        +----------+

        Figure 5.2a - the MN in trusted FA region

        +---------+       +------+   +---------------------------+
        |Internet |       |      |   |Home network /VPN Domain   |
        |  |--------------|IPsec-|   | +----+ +-----+ +----+     |
        |  |  ------------|based |<->| |HA-1  | HA-2| |HA-n|     |
        +--|--|---+       |VPN   |   | +----+ +-----+ +----+     |
           |  |           +------+   |                           |
        +--|--|----+                 | +----+ +-----+ +----+     |
        | +|--|+   |                 | |FA-1| | FA-2| |FA-n|     |
        | ||FA||   |                 | +----+ +-----+ +----+     |
        | +|--|+   |                 |                           |
        |  |  |<------- IPsec Tunnel | +----+ +-----+ +-----+    |
        | +|--|+   |                 | |MN-1| |MN-2 | |MN-n |    |
        | |MN  |   |                 | +----+ +-----+ +-----+    |
        | +----+   |                 |                           |
        | Multi-   |                 +---------------------------+
        | Subnetted|
        | Hot Spot |
        +----------+

        Figure 5.2b - the MN in non-trusted FA region

   6. Problem Statement




Adrangi, Iyer           Expires September 2002                [Page 6]


Internet Draft  draft-ietf-mobileip-vpn-problem-statement-00 March 2002


        This section describes MIPv4 incompatibilities with IPsec-based
        VPN gateways, in the context of the roaming scenarios outlined
        in section 4.

   6.1. MIPv4 Incompatibilities with VPN Gateways

        The MN roaming outside the home network has to establish an
        IPsec tunnel to its home VPN gateway first, in order to be able
        to register with its home agent. Figure 6.1a and 6.1b show the
        tunnel  end-points  in  non  co-located  and  co-located  modes
        respectively.



            MN (========= FA ===========) VPN ------------ HA

            MN-HoA                     VPN-E-Addr
             (==========================)
                    IPsec ESP Tunnel


        Figure 6.1a û Shows IPsec Tunnel end-points, MN Home Address
                      and VPN External IP Address, in non co-located
                      mode



            MN (========================) VPN --------------- HA

            MN-CoA                    VPN-E-Addr
             (=========================)
                   IPSec ESP Tunnel

        Figure 6.1b û Shows IPsec tunnel endpoints, MN-CoA and the VPN
                      External IP address, in co-located mode


        This implies that the MIPv4 traffic has to run inside IPsec
        tunnel, and will not be in the clear. This leads to the
        following problems:

        Problem 1: In non co-located mode, this implies that the FA
        (which is likely in a different administrative domain) cannot
        decrypt MIPv4 packets between the MN and the VPN gateway, and
        will consequently be not able to relay the MIPv4 packets. For
        example,  the  following  shows  the  MNÆs  registration  packet
        arrived at FA, which cannot be decrypted by the FA.






Adrangi, Iyer           Expires September 2002                [Page 7]


Internet Draft  draft-ietf-mobileip-vpn-problem-statement-00 March 2002


        +------------------------------------------------------------+
        |Src: MN HoA    |ESP   |Src: MN HoA|UDP     |Reg.   |ESP     |
        |Dst: VPN_E_Addr|Header|Dst: HA    |Port 434|Request|Trailer |
        +------------------------------------------------------------+

        Problem 2: In co-located mode, the MN obtains a CoA at its
        point of attachment (via DHCP[7] or some other means). In an
        end-to-end security model, an IPsec tunnel that terminates at
        the VPN gateway MUST protect the IP traffic originating at the
        MN. If the IPsec tunnel is associated with the CoA, the tunnel
        SA MUST be refreshed after each IP subnet handoff which could
        have some performance implications on real-time applications.

        It  is  important to note that only IPsec tunnel mode is
        applicable here, as the mobile node connecting to the home
        network MUST establish an IPsec tunnel SA to the VPN gateway
        first.

   7. MIPv6 Considerations

        MIPv6 does not have a FA component, hence the MN will always
        run in co-located mode.  This implies that only problem #2
        specified in the problem statement (section 6.1) is applicable
        to MIPv6.

   8. Revisions History

     1) Initial Version                          March 2002

     2) Second Version April 2002
       + Modified the draft based on Phil Roberts comments.
                1. NAT section was removed
                2. Solution requirements section was removed
                3. Tunnel end-point are clearly identified

       + Made minor organizational changes as Phil Roberts requests
                1. Make Dr. Joe section more generic
                2. Split 4.0 section

   9. References

   [1] RFC 3220 û IP mobility support for IPv4
   [2] RFC 3024 û Reverse tunneling for mobile IP
   [3] RFC 2004 û Minimal encapsulation within IP
   [4] RFC 1701 û Generic Routing encapsulation
   [5] RFC 2119 - Key words for use in RFCs to Indicate Requirement
   Levels
   [6] RFC 1918 û Address Allocation for Private Internets
   [7] RFC 2663 - IP Network Address Translator (NAT) Terminology and
   Considerations
   [8] RFC 2131 û Dynamic Host Configuration Protocol


Adrangi, Iyer           Expires September 2002                [Page 8]


Internet Draft  draft-ietf-mobileip-vpn-problem-statement-00 March 2002


   [9]   draft-bpatil-mobileip-sec-guide-01.txt   -   Requirements   /
   Implementation Guidelines for Mobile IP using IP Security
   [10] Dynamic Configuration of IPv4 Link-Local Addresses,
                   <draft-ietf-zeroconf-ipv4-linklocal-03>


   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


   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@liqwident.com
                               Phone: 703 8641327
   Liqwidnet 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 September 2002                [Page 9]


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