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]