Internet DRAFT - draft-antoine-mip4-proxymobike

draft-antoine-mip4-proxymobike





Network Working Group                                   Stephane Antoine
Internet-Draft                               France Telecom Research and
Intended status: Standards Track                             Development
Expires: August 17, 2008                               February 14, 2008


                  Mobility using Proxy MIP and Mobike
                 draft-antoine-mip4-proxymobike-01.txt

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.
   This document may not be modified, and derivative works of it may not
   be created.

   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 August 17, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2008).

Abstract

   The simultaneous use of Mobike and Mobile IPv4 has been proposed to
   provide secure connectivity and session continuity to roaming
   corporate users.  Optimization of this solution have eliminated the
   tunneling overhead of Mobile IPv4 in the vpn tunnel by having a
   Foreign Agent co-located to the mobile vpn gateway.  This document
   further proposes an interaction between Mobike and Proxy Mobile IP



Stephane Antoine         Expires August 17, 2008                [Page 1]

Internet-Draft     Mobility using Proxy MIP and Mobike     February 2008


   that simplifies implementation and deployment of the previous
   methods.  The mobile vpn gateway is co-located to the Mobility Proxy
   Agent and each Access Point in the corporate network is equipped with
   Proxy Mobile IP.  When moving outside the corporate network, the
   Mobile Node secure connectivity and session continuity is handled by
   Mobike.  Proxy Mobile IP alone is used to handle mobility when the
   Mobile Node moves within the corporate network.  This document
   introduces an interaction between Internet Key Exchange v2 and Proxy
   Mobile IP in which the Internet Key Exchange AUTH request triggers
   the Proxy Mobile IP registration request to the internal Home Agent.
   This interaction easily allows the Mobile Node's home address to be
   used as vpn Tunnel Inner Address.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Architecture and solution overview . . . . . . . . . . . . . .  3
   4.  Solution description . . . . . . . . . . . . . . . . . . . . .  5
     4.1.  VPN establishment and HoA address acquisition. . . . . . .  5
     4.2.  Detecting that MN has moved into the trusted network.  . .  6
     4.3.  Moving to the trusted network  . . . . . . . . . . . . . .  6
     4.4.  Moving outside the trusted network . . . . . . . . . . . .  6
     4.5.  Moving back to an un-trusted network . . . . . . . . . . .  7
     4.6.  Moving within the enterprise network . . . . . . . . . . .  7
   5.  Routing considerations . . . . . . . . . . . . . . . . . . . .  7
   6.  Packet formats . . . . . . . . . . . . . . . . . . . . . . . .  7
   7.  Solution Benefits  . . . . . . . . . . . . . . . . . . . . . .  8
     7.1.  Simplicity . . . . . . . . . . . . . . . . . . . . . . . .  8
     7.2.  Reduction of the overhead  . . . . . . . . . . . . . . . .  8
   8.  Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . .  8
   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  9
   10. Normative References . . . . . . . . . . . . . . . . . . . . .  9
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . .  9
   Intellectual Property and Copyright Statements . . . . . . . . . . 10















Stephane Antoine         Expires August 17, 2008                [Page 2]

Internet-Draft     Mobility using Proxy MIP and Mobike     February 2008


1.  Introduction

   To provide secure connectivity and session continuity to corporate
   users a combination of mobike and Mobile IPv4 (MIPv4) has been
   proposed [SECURE].  Mobike is used to achieve vpn session continuity
   as the Mobile Node (MN) is moving outside the corporate network
   premises.  The MIPv4 session alone which is anchored to an internal
   Home Agent (i-HA) is used to handle mobility as the MN is moving
   inside the corporate network.  To eliminate the overhead of MIPv4 in
   the vpn tunnel, an optimisation introduced a Foreign Agent (FA) co-
   located with the mobile VPN (mVPN) gateway.  However this
   optimisation introduced complexity in setting the MN's Home address
   as the vpn tunnel inner address.  In the present document, a
   combination of Mobike and Proxy MIP eliminates the previous problems.
   The Proxy Mobility Agent is co-located to the mVPN gateway.  Outside
   the corporate network, the MN uses Mobike for secure connectivity and
   session continuity.  When the MN moves within the corporate network,
   proxy MIP alone is used with the i-HA to maintain the MN's session
   continuity.  The Internet Key Exchange (IKEv2) AUTH request triggers
   the Proxy MIP (PMIP) registration hence making it easy for the Home
   Address to be assigned as the vpn Tunnel Inner Address (TIA).  It
   also removes some complexity as the MN only has an instance of Mobike
   on the MN and its mobility inside the corporate network is handled by
   the network through Proxy MIP.

   .


2.  Terminology

   The terminology in [SECURE] applies for this document and we further
   introduce the following terms: GMPA: Gateway Mobility Proxy Agent.
   MPA collocated to the mVPN gateway. i-MPA: Internal Mobility Proxy
   Agent residing in the trusted enterprise network.


3.  Architecture and solution overview

   The architecture considered involved a mVPN Gateway, the
   demilitarized zone and the internal network which is the trusted
   network










Stephane Antoine         Expires August 17, 2008                [Page 3]

Internet-Draft     Mobility using Proxy MIP and Mobike     February 2008


     (MN)                                        (MN)     [i-HA]
      !                                            \     /
    .------.                                      .-+---+-.
   (        )                                    (         )
    -------                      [mVPN/GMPA]       --+----
      \                             !                 !
       [R/(MPA)]                 .--+--.             [AR/MPA]
        \                       ( DMZ   )             !
        .+------------.          --+----        .-----+------.
       (               )            !          (              )
       ( external net  +---[R]----[FW]----[R]--+ internal net )
       (               )                       (              )
        -----+---------                         ---+---+------
            /                                     /     \
   [DHCP] [R]                          [DHCP]   [AR/MPA] [AR/MPA][i-MPA]
      \   /                               \     /          \    /
      .+-+---.                            .-+-+--.       .--+--+-.
     (        )                          (        )     (         )
       --+---                             --+----        ---+-----
         !                                  !               !
        (MN)                               (MN)            (MN)


   Figure 1: Network topology with GMPA colocated with VPN Gateway

   The architecture described supports PMIP in the corporate network.
   In this architecture, it is assumed that every Access Point or Access
   Router (AR) in the corporate network is a MPA implementing the
   functionalities of PMIP.  In this architecture, the MPAs and the i-HA
   are not directly accessible from the external network.  The mobility
   service provided by the i-HA is not available to un-trusted users.
   When a trusted MN moves within the corporate network, PMIP is used to
   maintain the MN session continuity.  The MPA maintains a valid
   Binding cache entry at all times at the Home Agent mapping the Home
   address to the current CoA (Address of the MPA or of the FA).
   Whenever, the MN attaches a new MPA, the MPA sends a registration
   request to update the binding cache entry for that MN.  If the mobile
   node moves while outside the enterprise and its access network
   changes, it uses the MOBIKE protocol [MOB] to update the VPN gateway
   of its current address.  When the MN is connected to the same VPN
   Gateway, the GMPA still maintains a valid binding cache entry at the
   i-HA.  The i-HA is not aware of the mobile node's movement as long as
   the MN is attached to the same VPN gateway and the GMPA address
   remains the same.  In order to maintain session continuity of the MN
   as it moves between networks, the Home Address (HoA) stays unchanged.
   If the MN had to change VPN gateway, the new GMPA would update the
   i-HA with the new Care of Address.




Stephane Antoine         Expires August 17, 2008                [Page 4]

Internet-Draft     Mobility using Proxy MIP and Mobike     February 2008


4.   Solution description

   The few set of functionality introduced in the document are depicted
   in this section.

4.1.  VPN establishment and HoA address acquisition.

   To use the MN's HoA as the vpn TIA, the current solution proposes
   that the IKE AUTH request of the vpn session establishment triggers
   the Proxy MIP registration.  Figure 2 illustrates the interaction
   between the IKEv2 signalling exchange and the first proxy MIP
   registration.



    MN                   mVPN/GMPA                      i-HA
    |                         |                          |
    |------------------------>|                          |
   1| IKE_SA_INIT             |                          |
    |<------------------------|                          |
    |                         |                          |
    |IKE_AUTH request         |                          |
   2|------------------------>|                          |
    |IDi=NAI                  |                          |
    |CP_CFG_REQUEST           |                          |
    |initial address= 0.0.0.0 |                          |
    |                         |                          |
    |                         |   Reg_Req: (HoA=0.0.0.0) |
    |                         |3------------------------>|
    |                         |<------------------------4|
    |                         |       Reg_Repl (HoA)     |
    | IKE_AUTH response       |                          |
   5| <-----------------------|                          |
    |CP(CFG_REPLY)= Internal_address (HoA)               |
    |                         |                          |

   Figure 2: Initial registration and HoA acquisition

   1.  The first message exchange is the IKE_SA_INIT.

   2.  The MN presents its NAI in the IDi (Identification of initiator)
       payload of the IKE_AUTH request.  The GMPA will use the NAI to
       send the Registration request for the MN.  IKE_AUTH request will
       also contain a CP_CFG_REQUEST payload containing the internal
       address 0.0.0.0 indicating that the MN is requesting an IP
       address from the internal network.





Stephane Antoine         Expires August 17, 2008                [Page 5]

Internet-Draft     Mobility using Proxy MIP and Mobike     February 2008


   3.  Following the Reception of the IKE_AUTH request and correct
       processing, the GMPA sends a Registration Request to the i-HA.

   4.  The i-HA will return the HoA to be allocated to the MN in the
       Registration reply.

   5.  When the GMPA receives the Reg_Reply with the HoA, the mVPN sends
       that HoA in the CP(CFG_REPLY) payload of the IKE_AUTH response.

4.2.  Detecting that MN has moved into the trusted network.

   When a new network becomes available, the MN performs network access
   authentication on that network.  During this authentication, the MN
   presents its NAI to the Access Router.  Alternatively, if network
   access authentication is not required, the client Fully Qualified
   Domain Name (FQDN) sub-option [DHCP] will present the MN's FQDN to
   the AR.  Assuming that in each MPA of the trusted network, it exists
   a mapping between the FQDN and the NAI; the MN will be identified by
   that mapping.  The AR/MPA then sends a Proxy Registration Request for
   the MN's NAI to the i-HA address.  The MN uses reception of native
   unprotected data to its HoA as an indication that it is in the
   trusted network.

4.3.  Moving to the trusted network

   In the trusted network, the MN does not use the vpn tunnel to send
   and receive traffic.  So the vpn tunnel may be torn down when the MN
   detects that it has moved in the trusted network.  The SAs that used
   to protect the traffic between the MN and the mVPN gateway can be
   deleted.  To that end the MN can send a Mobike DELETE message (with
   address 0.0.0.0) to the mVPN gateway.  The IPsec SA can be created
   when required.  The MN may have to re-negotiate IKEv2 SA to prevent
   the IKE SA from expiring.  This negotiation can be done through the
   old network if it is still available or through the internal network
   if the vpn gateway is reachable from the internal network.

4.4.  Moving outside the trusted network

   Mobike is used to handle mobility of the MN when it is roaming
   outside the trusted network.  The HoA which is the VPN TIA stays
   unchanged to maintain session continuity.  When the MN disconnects
   from the VPN gateway or attaches a different VPN gateway, it should
   re-connect and obtain the same VPN TIA as the previous one.  This
   will allow sessions to survive VPN disconnection as the Mobility
   Bindings for the MN's HoA at the i-HA have remained in spite of the
   VPN disconnection.





Stephane Antoine         Expires August 17, 2008                [Page 6]

Internet-Draft     Mobility using Proxy MIP and Mobike     February 2008


4.5.  Moving back to an un-trusted network

   After detecting that it has moved outside the trusted network, the MN
   will re-establish the VPN connection with possibly the old IKE SA it
   had before tearing the VPN tunnel down.  The mobile node may not have
   to re-negotiate the IKEv2 SA if it has maintained the VPN states
   alive in the VPN gateway while it was receiving traffic directly from
   the trusted network [SECURE].

4.6.  Moving within the enterprise network

   Within the corporate network, PMIP as described in [PMIP4] is
   handling mobility of MN with the i-HA serving as the mobility anchor.


5.   Routing considerations

   The GMPA is configured with the i-HA as its default router.  Packets
   from the MN are de-capsulated by the m-VPN gateway which, pass the
   inner packets to the GMPA.  The GMPA reverse tunnel them in IP to the
   i-HA.  Packets from the i-HA are de-capsulated by the GMPA and then
   re-encapsulated in the IPsec tunnel to the MN.  The GMPA might use a
   private address as source address of the Registration Request sent to
   the i-HA.  For routing simplifications, most corporate networks would
   not have any NAT between the MPA and the i-HA.  Encapsulation would
   then be of the type IP in IP for both forward and reverse tunnels.


6.  Packet formats

   Packet format from MN to the mVPN gateway:
   Outer IPv4 header: (Src: local IPA, Dst: mVPN Gtwy)
   ESP header
   Inner IPv4 header: (Src: HoA=TIA, Dst: CN )
   Payload

   Packet from the MPA to the i-HA:
   Outer IPv4 header: (Src: MPA, Dst: i-HA)
   Inner IPv4 header: ( Src: HoA, Dst: CN)
   Payload

   Packet from the i-HA to the CN:
   IPv4 header: (Src: HoA, Dst: CN)
   Payload

   For the forward path, the source and destination addresses are
   reversed.




Stephane Antoine         Expires August 17, 2008                [Page 7]

Internet-Draft     Mobility using Proxy MIP and Mobike     February 2008


7.   Solution Benefits

7.1.  Simplicity

   This method makes it easy to assign the MN's HoA as the VPN TIA.  It
   thus removes the complexity associated with the method proposed in
   [OPT] where the MN runs an instance of MIP and where the FA is co-
   located to the mVPN gateway.  This method suggested to; first
   allocate a TIA to the MN during vpn (IPsec tunnel mode) setup and
   then replace the TIA with the home address.  This would violate RFC
   4301 [SEC] which; states that the TIA cannot be changed without
   rendering the tunnel mode IPsec SAs invalid.  An alternative method
   was suggested to perform an additional CREATE_CHILD_SA exchange after
   the initial exchange to create an IPsec SA for the Home Address and
   let the first CHILD SA with the TIA expires.  This method introduced
   significant complexity.  Instead; the interaction between PMIP and
   Mobike works simply to allocate the HoA as the VPN TIA without any
   additional mechanism.  The method presented in this document also
   reduces the amount of signalling that would be necessary if Dynamic
   Host Configuration Protocol (DHCP) was used to obtain the HoA after
   the establishment of the VPN connection.

7.2.  Reduction of the overhead

   With this method, the MIPv4 overhead in [SECURE] is removed between
   the MN and the mVPN gateway.  Moreover, the present method eliminates
   the MIPv4 Registration overhead that still occurs between the MN and
   the FA in the method described in [OPT].  The great benefit of PMIP
   lies in the elimination of the MIP signalling between the MN and the
   MPA.


8.  Conclusion

   This document introduces the interaction between Mobike and Proxy MIP
   to provide secure connectivity and mobility to the corporate users.
   The proposed architecture involves a Gateway Proxy Mobility Agent co-
   located with the mVPN gateway and a MPA on each AP within the
   enterprise network.  When moving outside the corporate network,
   Mobike is used to maintain the user secure connectivity with the
   intranet.  Proxy MIP is used to maintain session continuity within
   the corporate network.  During the initial IKEv2 negotiation, the
   IKEv2 IKE_AUTH Request message triggers the Proxy Registration
   Request for the MN.  The Home Address allocated for the MN in the
   Registration Reply is passed to the MN in the IKE_AUTH Reply.  The
   MN's Home Address henceforth coincides with the MN's VPN Tunnel Inner
   Address.  Combining Proxy MIP and Mobike simplifies the deployment of
   a seamless mobility solution for corporate users while removing the



Stephane Antoine         Expires August 17, 2008                [Page 8]

Internet-Draft     Mobility using Proxy MIP and Mobike     February 2008


   overhead of MIPv4 in the vpn tunnel.  Using PMIP, guarantees mobility
   in the intranet without requiring the Mobile Node to run any mobility
   management protocol such as MIPv4.


9.  Acknowledgements


10.  Normative References

   [DHCP]    M. Stapp, B. Volz, Y. Rekhter, "The Dynamic Host
             Configuration Protocol (DHCP) Client, Fully Qualified
             Domain Name (FQDN) Option, Request for Comments: 4702",
             October 2006.

   [MOB]     P. Eronen, "Mobike, Internet draft; IKEv2 Mobility and
             Multihoming Protocol (MOBIKE)", February 2006.

   [OPT]     Sahasrabudhe, M. and V. Devarapalli, "Optimizations to
             Secure Connectivity and Mobility,
             draft-meghana-mip4-mobike-optimizations-01 (work in
             progress)", October  2006.

   [PMIP4]   K. Leung, G. Dommety, P. Yegani, K. Chowdhury, "Mobility
             Management using Proxy Mobile IPv4", January  2007.

   [SEC]     S. Kent, K. Seo, "Security Architecture for the Internet
             protocol, rfc 4301", December 2005.

   [SECURE]  V. Devarapalli, P. Eronen, Editor., "Secure Connectivity
             and Mobility using Mobile IPv4 and Mobike, MIPv4-Mobike: ht
             tp://www.ietf.org/internet-drafts/
             draft-ietf-mip4-mobike-connectivity-02.txt", January
              2007.


Author's Address

   Stephane Antoine
   France Telecom Research and Development
   Chiswick Park
   London, Chiswick  W4 5XS
   United Kingdom

   Phone: + 44 (0)208 849 5821
   Fax:   +44 (0)208 849 0991
   Email: stephane.antoine@orange-ftgroup.com




Stephane Antoine         Expires August 17, 2008                [Page 9]

Internet-Draft     Mobility using Proxy MIP and Mobike     February 2008


Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   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.

   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, THE IETF TRUST 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.


Intellectual Property

   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.


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).





Stephane Antoine         Expires August 17, 2008               [Page 10]