MIP4 Working Group                                       M. Sahasrabudhe
Internet-Draft                                                     Nokia
Expires: September 18, 2006                               V. Devarapalli
                                                         Azaire Networks
                                                          March 17, 2006


           Optimizations to Secure Connectivity and Mobility
               draft-meghana-mip4-mobike-optimizations-00

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   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.

   This Internet-Draft will expire on September 18, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   Users that need to connect to their enterprise network from an
   untrusted network require secure connectivity and mobility.
   Enterprise users are increasingly using mobile nodes.  A user may
   need to connect to the enterprise network from anywhere, and in a
   number of scenarios, from untrusted networks.  There are existing
   specifications developed by the Mobile IPv4 working group that
   describe solutions for enterprise secure connectivity and mobility.



Sahasrabudhe & Devarapalli  Expires September 18, 2006          [Page 1]


Internet-Draft      VPN Gateway and FA/HA co-location         March 2006


   This document proposes optimizations to those solutions to reduce the
   tunneling overhead and allow for a number of new access modes.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Solution Overview with FA on VPN Gateway . . . . . . . . . . .  4
     3.1.  Access modes . . . . . . . . . . . . . . . . . . . . . . .  6
     3.2.  Access mode: 'fvf' . . . . . . . . . . . . . . . . . . . .  6
     3.3.  Access mode: 'cvf' . . . . . . . . . . . . . . . . . . . .  7
     3.4.  Access mode: 'mf'  . . . . . . . . . . . . . . . . . . . .  7
   4.  Solution Overview with HA on VPN Gateway . . . . . . . . . . .  8
     4.1.  Access mode: 'fvh' . . . . . . . . . . . . . . . . . . . .  8
     4.2.  Access mode: 'cvh' . . . . . . . . . . . . . . . . . . . .  9
     4.3.  Access mode: 'mh'  . . . . . . . . . . . . . . . . . . . . 10
   5.  Home Address as IPsec TIA  . . . . . . . . . . . . . . . . . . 10
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 11
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 11
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 11
     8.2.  Informative References . . . . . . . . . . . . . . . . . . 12
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
   Intellectual Property and Copyright Statements . . . . . . . . . . 14


























Sahasrabudhe & Devarapalli  Expires September 18, 2006          [Page 2]


Internet-Draft      VPN Gateway and FA/HA co-location         March 2006


1.  Introduction

   It is assumed that the reader is familiar with
   draft-ietf-mip4-mobike-connectivity-00.txt [2].  This document talks
   about optimizations to the solution proposed in [2] and also to [6].
   An enterprise user authenticates to the VPN gateway from an untrusted
   network to gain access to the services on the enterprise network.
   While inside the network, a user doesn't need to use the VPN gateway.
   When a user roams in and out from a trusted to an untrusted network
   the sessions currently active should not drop and the change in
   connectivity should be seamless to the user.

   The solution in [2] elaborates that the user uses only Mobile IPv4
   [3] when inside the enterprise network and uses IPsec VPNs with
   MOBIKE extensions to IKEv2 when roaming outside the enterprise
   network to have access to the services provided by the enterprise.
   Point to note is that this solution does not support legacy IPsec
   VPNs.  The VPN gateways have to implement mobility extensions to
   IKEv2 [4].  The solution also does not require multiple Home Agents
   or a Home Agent in the DMZ.  The Home Agent is always located inside
   the enterprise network.  The tunnel inner address of the IPsec tunnel
   is used as the MIPv4 co-located care of address (CCoA).  As long as
   the mobile node is connected to the same VPN gateway and its TIA
   remains the same, there is no change in the CoA used by the mobile
   node.  When the mobile node moves to a new VPN gateway or gets a new
   TIA, it updates its home agent with its new CCoA.

   The packet format for packets sent from the mobile node to a
   correspondent node, when the mobile node is outside the enterprise,
   looks as follows

       IPv4 hdr (src=IPA, dst=VPN_GW)
       ESP Hdr
       IPv4 hdr (src=TIA, dst=HA)
       IPv4 hdr (src=HoA, dst=CN)
       Payload

   From the VPN gateway to the correspondent node the packet looks as
   follows

       IPv4 hdr (src=TIA, dst=HA)
       IPv4 hdr (src=HoA, dst=CN)
       Payload

   When the mobile node is inside the enterprise the packet format looks
   as follows





Sahasrabudhe & Devarapalli  Expires September 18, 2006          [Page 3]


Internet-Draft      VPN Gateway and FA/HA co-location         March 2006


       IPv4 hdr (src=IPA, dst=HA)
       IPv4 hdr (src=HoA, dst=CN)
       Payload

   There is additional tunneling overhead when the mobile node is
   roaming in an untrusted network.  This overhead can be avoided by
   having the Mobile IPv4 Foreign Agent functionality on the VPN
   gateway.  This would avoid having to encapsulate a Mobile IP tunnel
   inside an IPsec tunnel.  The following sections describe an optimized
   connectivity and roaming solution that reduces the packet overhead
   from the solution described in [2].


2.  Terminology

   i-MIP: Mobile IP layer used for internal enterprise mobility.  Home
      Agent is inside the enterprise network.

   x-MIP: Mobile IP layer used for access from outside the enterprise
      network.  Home Agent resides either in the Internet or in the DMZ
      before the VPN gateway looking from the Internet

   i-HA: Home Agent inside the enterprise network

   x-HA: Home Agent outside the enterprise network

   i-FA: Mobile IPv4 foreign agent residing in the trusted enterprise
      network

   FA CoA: Foreign Agent mode care of address

   cCoA: co-located care of address

   HoA: Home address

   TIA: Tunnel Inner Address, the address given out to the mobile node
      by the VPN gateway during IKE setup

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


3.  Solution Overview with FA on VPN Gateway

   The two optimizations proposed in this document place the Foreign
   Agent on the VPN gateway in one and the Home Agent on the VPN gateway
   in the other.  These reduces the tunnel overhead as the additional



Sahasrabudhe & Devarapalli  Expires September 18, 2006          [Page 4]


Internet-Draft      VPN Gateway and FA/HA co-location         March 2006


   tunneling from the TIA to the Home Agent is not required.  In the FA
   optimization, when the VPN gateway receives the packet from the
   mobile node, it removes the IPsec header and the FA functionality on
   the VPN GW encapsulates the original packet and sends it to the Home
   Agent inside the enterprise.  In the HA optimization, since the Home
   Agent functionality is on the VPN gateway itself, the Mobile Node is
   always on the Home Network even when roaming.

   In the FA optimization, the packet format from the mobile node to the
   VPN gateway now looks as follows

       IPv4 hdr (src=IPA, dst=VPN_GW/FA)
       ESP hdr
       IPv4 hdr (src=HoA, dst=CN)
       Payload

   From the VPN gateway to the correspondent node the packet looks as
   follows

       IPv4 hdr (src=VPN_GW/FA, dst=HA)
       IPv4 hdr (src=HoA, dst=CN)
       Payload

   The figure below depicts the network topology assumed for the
   solution.  It also shows the possible mobile node locations and
   access modes.

       (MN) {mf}                             {home} (MN)   [i-HA]
        !                                             \     /
     .--+---.                                        .-+---+-.
    (        )                                      (         )
     `--+---'                      [MVPN/FA]         `--+----'
         \                           !                  !
         [R/FA]                   .--+--.              [R]
            \                    (  DMZ  )              !
           .-+-------+--.         `--+--'         .-----+------.
          (              )           !           (              )
          ( external net +---[R]----[FW]----[R]--+ internal net )
          (              )                       (              )
           `--+---------'                         `---+---+----'
             /                                       /     \
   [DHCP]  [R]                              [DHCP] [R]     [R]    [i-FA]
      \    /                                   \   /         \    /
      .+--+---.                               .-+-+--.     .--+--+-.
     (         )                             (        )   (         )
      `---+---'                               `--+---'     `---+---'
          !                                      !             !
         (MN) {mf}                             (MN) {c}      (MN) {f}



Sahasrabudhe & Devarapalli  Expires September 18, 2006          [Page 5]


Internet-Draft      VPN Gateway and FA/HA co-location         March 2006


   The tunnel overhead reduction is significant especially if the mobile
   node is connected over a wireless network.  The optimization
   requirement of co-locating the Foreign Agent with the VPN gateway can
   place the FA multiple hops away from the mobile node.  FA
   availability is hence an issue here.  The FA still has to be on link
   for the mobile node to receive Agent Advertisement messages.  There
   already exists a tunnel interface between the mobile node and the VPN
   gateway.  This tunnel interface can be used so the FA can appear just
   one hope away and on link to the mobile node.  The FA sends out Agent
   Advertisement messages on the tunnel interface.  The mobile node too
   can send out MIP control messages to the FA on the tunnel interface.

3.1.  Access modes

   The access modes possible in [1] are

   f: i-MIP with FA-CoA
   c: i-MIP with CCoA
   mc: mobile enhanced VPN, i-MIP with VPN TIA as CCoA

   The additional access modes possible with this optimization are

   fvf: x-MIP with FA CoA/ VPN/ i-MIP with FA CoA
   cvf: x-MIP with CCoA/VPN/ i-MIP with FA CoA
   mf: mobile enhanced VPN, i-MIP with FA CoA

3.2.  Access mode: 'fvf'

   In this access mode there are two home agents.  One Home Agent is
   located inside the enterprise and one outside the enterprise in the
   internet or the DMZ before the VPN gateway looking from the internet.
   In this mode the mobile node uses the external care-of address
   (x-FACoA) and an external home address (x-HoA).  Packets are first
   tunneled to the external home Agent, then to the VPN gateway and
   eventually to the internal home Agent.

   Packet format from the mobile node to the VPN gateway looks as
   follows:

       IPv4 hdr (src=x-FA-CoA, dst=x-HA)
       IPv4 hdr (src=i-HoA, dst=VPN_GW/FA)
       ESP hdr
       IPv4 hdr (src=i-HoA, dst=CN)
       Payload

   Packet format from the VPN gateway to the correspondent node looks as
   follows:




Sahasrabudhe & Devarapalli  Expires September 18, 2006          [Page 6]


Internet-Draft      VPN Gateway and FA/HA co-location         March 2006


       IPv4 hdr (src=VPN_GW/FA, dst=i-HA)
       IPv4 hdr (src=i-HoA, dst=CN)
       Payload

3.3.  Access mode: 'cvf'

   There are two home agents here also.  One Home Agent is located
   inside the enterprise and one outside the enterprise in the internet
   or the DMZ before the VPN gateway looking from the internet.  In this
   mode tme mobile node uses the external co-located care-of address
   (x-cCoA) and an external home address ( x-HoA).Packets are first
   tunneled to the external home Agent, then to the VPN gateway and
   eventually to the internal home Agent.

   Packet format from the mobile node to the VPN gateway looks as
   follows:

       IPv4 hdr (src=x-cCoA, dst=x-HA)
       IPv4 hdr (src=i-HoA, dst=VPN_GW/FA)
       ESP hdr
       IPv4 hdr (src=i-HoA, dst=CN)
       Payload

   Packet format from the VPN gateway to the CN looks as follows:

       IPv4 hdr (src=VPN_GW/FA, dst=i-HA)
       IPv4 hdr (src=i-HoA, dst=CN)
       Payload

3.4.  Access mode: 'mf'

   In this mode the VPN gateway is mobility aware in the sense that it
   also implements MOBIKE extensions in addition to being a Foreign
   Agent.  The mobile node uses the home address as TIA.

   Packet format from mobile node to the VPN GW/FA looks as follows:

       IPv4 hdr (src=IPA, dst=VPN_GW/FA)
       ESP hdr
       IPv4 hdr (src=i-HoA, dst=CN)
       Payload

   Packet format from the VPN gateway to the correspondent node looks as
   follows:

       IPv4 hdr (src=FA, dst=i-HA)
       IPv4 hdr (src=i-HoA, dst=CN)
       Payload



Sahasrabudhe & Devarapalli  Expires September 18, 2006          [Page 7]


Internet-Draft      VPN Gateway and FA/HA co-location         March 2006


   The advantage in using access modes "fvf" and "cvf" is that these can
   still be used with legacy IPsec VPNs.  Hence these can be deployed in
   existing enterprise networks that may have already invested heavily
   in legacy VPNs and would be reluctant to upgrade the VPN gateways in
   the enterprise network.


4.  Solution Overview with HA on VPN Gateway

   The figure below depicts the network topology assumed for the
   solution when the HA is co-located with the VPN gateway.  It also
   shows the possible mobile node locations and access modes.



       (MN) {mh}
        !
     .--+---.
    (        )
     `--+---'                      [MVPN/i-HA]
         \                           !
         [R/FA]                   .--+--.
            \                    (  DMZ  )
           .-+-------+--.         `--+--'         .-----+------.
          (              )           !           (              )
          ( external net +---[R]----[FW]----[R]--+ internal net )
          (              )                       (              )
           `--+---------'                         `---+---+----'
             /                                       /     \
   [DHCP]  [R]                              [DHCP] [R]     [R]    [i-FA]
      \    /                                   \   /         \    /
      .+--+---.                               .-+-+--.     .--+--+-.
     (         )                             (        )   (         )
      `---+---'                               `--+---'     `---+---'
          !                                      !             !
         (MN) {mh}                             (MN) {c}      (MN) {f}



   The additional access modes possible with this optimization are

   fvh: x-MIP with FA CoA/ VPN/ i-MIP with MN at home
   cvh: x-MIP with CCoA/VPN/ i-MIP with MN at home
   mh: mobile enhanced VPN, i-MIP with MN at home

4.1.  Access mode: 'fvh'

   In this access mode there are two home agents.  One Home Agent is



Sahasrabudhe & Devarapalli  Expires September 18, 2006          [Page 8]


Internet-Draft      VPN Gateway and FA/HA co-location         March 2006


   located inside the enterprise and one outside the enterprise in the
   internet or the DMZ before the VPN gateway looking from the internet.
   In this mode the mobile node uses the external care-of address
   (x-FACoA) and an external home address (x-HoA).  Packets are first
   tunneled to the external home Agent, then to the VPN gateway/Home
   Agent.

   Packet format from the mobile node to the VPN gateway looks as
   follows:

       IPv4 hdr (src=x-FA-CoA, dst=x-HA)
       IPv4 hdr (src=i-HoA, dst=VPN_GW/HA)
       ESP hdr
       IPv4 hdr (src=i-HoA, dst=CN)
       Payload

   Packet format from the VPN gateway to the correspondent node looks as
   follows:

       IPv4 hdr (src=i-HoA, dst=CN)
       Payload

4.2.  Access mode: 'cvh'

   There are two home agents here also.  One Home Agent is located
   inside the enterprise and one outside the enterprise in the internet
   or the DMZ before the VPN gateway looking from the internet.  In this
   mode the mobile node uses the external co-located care-of address
   (x-cCoA) and an external home address ( x-HoA).Packets are first
   tunneled to the external home Agent, then to the VPN gateway/Home
   Agent.

   Packet format from the mobile node to the VPN gateway looks as
   follows:

       IPv4 hdr (src=x-cCoA, dst=x-HA)
       IPv4 hdr (src=i-HoA, dst=VPN_GW/HA)
       ESP hdr
       IPv4 hdr (src=i-HoA, dst=CN)
       Payload

   Packet format from the VPN gateway to the CN looks as follows:

       IPv4 hdr (src=i-HoA, dst=CN)
       Payload






Sahasrabudhe & Devarapalli  Expires September 18, 2006          [Page 9]


Internet-Draft      VPN Gateway and FA/HA co-location         March 2006


4.3.  Access mode: 'mh'

   In this mode the VPN gateway is mobility aware in the sense that it
   also implements MOBIKE extensions in addition to being a Home Agent.
   The mobile node uses the home address as TIA.

   Packet format from mobile node to the VPN GW/HA looks as follows:

       IPv4 hdr (src=IPA, dst=VPN_GW/HA)
       ESP hdr
       IPv4 hdr (src=i-HoA, dst=CN)
       Payload

   Packet format from the VPN gateway to the correspondent node looks as
   follows:

       IPv4 hdr (src=i-HoA, dst=CN)
       Payload

   The advantage in using access modes "fvh" and "cvh" is that these can
   still be used with legacy IPsec VPNs.  Hence these can be deployed in
   existing enterprise networks that may have already invested heavily
   in legacy VPNs and would be reluctant to upgrade the VPN gateways in
   the enterprise network.


5.  Home Address as IPsec TIA

   When the mobile node sets up an IPsec tunnel with the VPN gateway it
   is allocated a tunnel inner address (TIA).  The TIA is used as the
   source address for all traffic sent through the IPsec tunnel.  In
   tunnel mode IPsec security associations are created based on TIA.
   But when a foreign agent functionality exists on the VPN gateway, the
   mobile node MUST use the home address as the source address on the
   data traffic.  Moreover, the optimization described in Section 3.4 is
   possible only if the home address is equal to the TIA.

   In order for the home address to be equal to the TIA, there is a need
   for close interaction between the IKEv2 implementation and Foreign
   agent implementation on the VPN gateway.  This may not be possible
   with all implementations, since the IPsec tunnel setup happens before
   an Foreign Agent Advertisement can be sent over the IPsec tunnel to
   the mobile node.  One possible solution would be to allocate a TIA
   when the IPsec tunnel is setup and later replace the TIA with the
   home address.  This would require updating the IPsec SAs with the new
   home address.  But this would violate RFC 4301 [8] which says the TIA
   cannot be changed without rendering the tunnel mode IPsec SAs
   invalid.



Sahasrabudhe & Devarapalli  Expires September 18, 2006         [Page 10]


Internet-Draft      VPN Gateway and FA/HA co-location         March 2006


   A simple solution would be for the mobile node to setup an IPsec
   tunnel with the TIA allocated by the VPN gateway, and then run a
   separate CREATE_CHILD_SA exchange [5] to setup new tunnel mode IPsec
   security associations for the home address.  This would however
   introduce additional delay in the form of an additional
   CREATE_CHILD_SA exchange when the mobile node connects to the
   enterprise network from outside.  The security associations created
   earlier for the TIA can be either torn down or allowed to expire
   based on the configuration on the mobile node.

   When the Home Agent is co-located with the VPN gateway the allocated
   TIA can be the Home Address at the initial IPsec tunnel establishment
   itself.


6.  Security Considerations

   The solution described in this document does not introduce any new
   security vulnerabilities on top of what is described in the security
   considerations sections of [2], [6] and [7].


7.  IANA Considerations

   This document requires no action from IANA.


8.  References

8.1.  Normative References

   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.

   [2]  Devarapalli, V. and P. Eronen, "Secure Connectivity and Mobility
        using Mobile IPv4 and MOBIKE",
        draft-ietf-mip4-mobike-connectivity-00 (work in progress),
        January 2006.

   [3]  Perkins, C., "IP Mobility Support for IPv4", RFC 3344,
        August 2002.

   [4]  Eronen, P., "IKEv2 Mobility and Multihoming Protocol (MOBIKE)",
        draft-ietf-mobike-protocol-08 (work in progress), February 2006.

   [5]  Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306,
        December 2005.




Sahasrabudhe & Devarapalli  Expires September 18, 2006         [Page 11]


Internet-Draft      VPN Gateway and FA/HA co-location         March 2006


8.2.  Informative References

   [6]  Vaarala, S. and E. Klovning, "Mobile IPv4 Traversal Across
        IPsec-based VPN Gateways",
        draft-ietf-mip4-vpn-problem-solution-02 (work in progress),
        November 2005.

   [7]  Adrangi, F. and H. Levkowetz, "Problem Statement: Mobile IPv4
        Traversal of Virtual Private Network (VPN) Gateways", RFC 4093,
        August 2005.

   [8]  Kent, S. and K. Seo, "Security Architecture for the Internet
        Protocol", RFC 4301, December 2005.






































Sahasrabudhe & Devarapalli  Expires September 18, 2006         [Page 12]


Internet-Draft      VPN Gateway and FA/HA co-location         March 2006


Authors' Addresses

   Meghana Sahasrabudhe
   Nokia Research Center
   313 Fairchild Drive
   Mountain View, CA  94043
   USA

   Email: meghana.saha@nokia.com


   Vijay Devarapalli
   Azaire Networks
   4800 Great America Parkway
   Santa Clara, CA  95054
   USA

   Email: vijay.devarapalli@azairenet.com

































Sahasrabudhe & Devarapalli  Expires September 18, 2006         [Page 13]


Internet-Draft      VPN Gateway and FA/HA co-location         March 2006


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Copyright Statement

   Copyright (C) The Internet Society (2006).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.




Sahasrabudhe & Devarapalli  Expires September 18, 2006         [Page 14]