Network Working Group B. Sarikaya Internet-Draft Huawei USA Intended status: Standards Track October 15, 2012 Expires: April 18, 2013 Mobility Management Protocols for Cloud-Like Architectures draft-sarikaya-dmm-cloud-mm-00.txt Abstract Telecommunication networks are being virtualized and are moving into the cloud networks. This brings the need to redesign the mobility protocols of Mobile and Proxy Mobile IPv6. This document defines mobility management protocols for virtualized networks. Control and data plane separation is achieved by separating Home Agent and Mobile Access Gateway functionalities into the control and data planes. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on April 18, 2013. Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as Sarikaya Expires April 18, 2013 [Page 1] Internet-Draft VMs for Mobility Management October 2012 described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Control and Data Plane Separation for MIPv6 . . . . . . . . . 5 4. Authentication in Control and Data Plane Separation . . . . . 6 5. Control and Data Plane Separation for PMIPv6 . . . . . . . . . 7 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 9.1. Normative References . . . . . . . . . . . . . . . . . . . 9 9.2. Informative references . . . . . . . . . . . . . . . . . . 10 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11 Sarikaya Expires April 18, 2013 [Page 2] Internet-Draft VMs for Mobility Management October 2012 1. Introduction Mobile IPv6 defines client based mobility support to the mobile nodes and is defined in [RFC6275]. There are several extensions to Mobile IPv6 such as multiple Care-of Address registration for multi-homed mobile nodes [RFC5648], flow mobility [RFC6089] and Dual Stack Mobile IPv6 [RFC5555]. Mobile IPv6 is based on a centralized mobility anchoring architecture at the home agent (HA). Proxy Mobile IPv6 defines network based mobility support to the mobile nodes and is defined in [RFC5213]. PMIPv6 operation involves a a Mobile Access Gateway handling mobility of the mobile node and registering the mobile node with the Local Mobility Anchor (LMA) which receives and sends MN traffic into the Internet. LMA operation is compatible with the home agent of MIPv6. IPv4 support for PMIPv6 is defined in [RFC5844] and flow mobility extensions in [I-D.ietf-netext-pmipv6-flowmob]. Centralized mobility anchoring has several drawbacks such as single point of failure, routing in a non optimal route, overloading of the centralized data anchor point due to the data traffic increase, low scalability of the centralized route and context management [I-D.ietf-dmm-requirements]. Architecture of a cloud network is shown in Figure 1, see also [I-D.rekhter-nvo3-vm-mobility-issues]. Top of Rack Switch (ToR) is a switch in a cloud network that is connected to the servers. The servers host virtual machines. A cloud network has one or more Data Center Border Routers (BR) or edge routers that connects the cloud network to the Internet including other cloud network or storage networks. Storage network is usually part of the same cloud network and it is connected to the BR using Fiber Channel (fc) links. Control and data plane separation is stated as a requirement for the distributed mobility management. Mobile IPv6 control plane is used for registration and handover signaling and for establishing security association, e.g. IPSec SAs. Data plane is used for data transfer from the corresponding nodes (CN) to MN and from MN to CNs. Typically control plane traffic is much ligther than the data plane traffic and control plane traffic has stronger latency requirements. Control plane data plane separation requires signaling between the control and data plane functional entities. Sarikaya Expires April 18, 2013 [Page 3] Internet-Draft VMs for Mobility Management October 2012 I N T E R N E T | | _____________________________________________________________ | | | Data | | ------ ------ fc Center | | | BR | | BR |-----------------| | | ------ ------ | | | |_____________| _____|________ | | ( Data Center ) | | | | ( Network ) |Storage Center| | | (___________) |_____________ | | | | | | ---- ---- | | | | | | ------------ ----- | | | ToR Switch | | ToR | | | ------------ ----- | | | | | | ---------- | ---------- | | |--| Server | |--| Server | | | | | | | ---------- | | | | ---- | | | | | | | VM | | | ---------- | | | | ----- | --| Server | | | | | | VM | | ---------- | | | | ----- | | | | | | VM | | | | | | ---- | | | | ---------- | | |-- Other servers | ------------------------------------------------------------- Figure 1: Architecture of Cloud 2. Terminology This document uses the terminology defined in [RFC6275] and [RFC5213]. Sarikaya Expires April 18, 2013 [Page 4] Internet-Draft VMs for Mobility Management October 2012 3. Control and Data Plane Separation for MIPv6 | ------------+----------. | | / Binding Cache and \ | | | Security Associations | | | \ / | | ------------------------- | | / \ | / +--------------+ / `-. \ | VM | / +--------------+ | HA Data | / | HA Control | \ |Plane Function| / |Plane Function| +--------------+ / +--------------+ \ \\ \ ----------------- \\ ' +-----+ +--\--+ | MN |---move----> | MN | +-----+ +-----+ Figure 2: Architecture of MIPv6 Control and Data Planes Control and data plane separation can be achieved by dividing HA into two functional entities: control plane functional entity and data plane functional entity as shown in Figure 2. These functional entities can be hosted on different physical entities. These two entities must share a common database. The database contains the binding cache and the security association information such as IPSec keys. HA Data Plane function can be implemented as virtual machine (VM) in a cloud network. Binding cache and security associations will be stored in the storage center of the cloud entwork that VMs can easily access. HA Control Plane function is geographically more distributed than HA data Plane function and is placed closer to the mobile nodes in order to meet the latency requirements. MN first communicates with the control plane function to establish security association. Address configuration and binding registration follows. Next MN receives/sends data packets using the data plane function closest to the link MN is attached. When MN moves MN does handover signaling with the control plane function which updates the binding cache based on this move. Control plane function informs the new data plane function of this binding cache update and then MN starts to receive and send data to the new data plane function. MN MUST keep HA control plane function address in cache so that it can conduct handover signaling with it. Sarikaya Expires April 18, 2013 [Page 5] Internet-Draft VMs for Mobility Management October 2012 When MN boots, it goes through authentication and security association establishment. Next MN sends a binding update. MN does these steps with HA control plane function. MN sends Binding Update message to HA control plane function and receives a Binding Acknowledgement message and in this message MN MUST receive HA data plane function address. HA data plane function address can be provided by HA control plane function to MN in Alternate Home Agent Tunnel Address option defined in [I-D.perkins-netext-hatunaddr] of BA message [RFC6275]. MN starts tunneling data packets and sends them to Alternate Home Agent Tunnel Address. Also MN receives data packets tunneled from Alternate Home Agent Tunnel Address. Control and data plane separation does not require protocol extensions except the sharing of binding cache and security associations database. How this sharing can be accomplished is left out of scope with this specification. 4. Authentication in Control and Data Plane Separation Currently, MN and HA create security associations (SA) based on the home address using IKEv2 as the key exchange protocol. When MN moves SAs are reestablished when MN gets a new care-of address. After SA is established, MN and HA use Encapsulating Security Payload (ESP) encapsulation for Binding Updates and Binding Acknowledgements [RFC4877]. IKEv2 enables the use of EAP authentication and provides EAP transport between MN as the peer and HA as the authenticator. EAP authentication is done using one of the EAP methods such as EAP-AKA [RFC4187]. MN is authorized as a valid user using EAP authentication. IKEv2 public key signature authentication with certificates is used to authenticate the home agent and derive keys to be used in exchanging BU/BA securely. MN can use the same identity, e.g. MN-NAI during both EAP and IKEv2 authentication. On the other hand MN goes through the access authentication when it first connects to the network. A typical access authentication protocol is AKA. MSK derived from this authentication serves as the session key in accessing the air interface. There is an overlap between the access and user authentications sometimes done using the same protocol, e.g. AKA. Full EAP method execution may take several round trips, some times five or more round Sarikaya Expires April 18, 2013 [Page 6] Internet-Draft VMs for Mobility Management October 2012 trips and slow down the user access to the Internet. This is especially an important consideration in Distributed Mobility Management since MN may connect to several home agents instead of staying anchored at one home agent. In order to reduce the number of round trips EAP authenticaton can be combined with reauthentication. Reauthentication is EAP method dependent. EAP-AKA reauthentication takes only one round trip [RFC4187]. MN must go through an EAP-AKA reauthentication before when MN was connected to the previous HA. During reauthentication reauthentication ID is generated. MN MUST use its reauthentication ID during IKEv2 EAP authentication with the new home agent. This ensures that EAP-AKA authentication takes only one round trip. MN continues to use its reauthentication ID in subsequent reauthentication runs with the same HA. 5. Control and Data Plane Separation for PMIPv6 | ------------+----------. | | / Binding Cache and \ | | | Security Associations | | | \ / | | ------------------------- | | / \ | / +--------------+ / `-. \ | VM | / +--------------+ +--------------+ | LMA | / | MAG Control | | MAG Data | \ | | / |Plane Function| |Plane Function| +--------------+ / +--------------+ +--------------+ \ \\ \ ----------------- \\ ' +-----+ +--\--+ | MN |---move----> | MN | +-----+ +-----+ Figure 3: Architecture of PMIPv6 Control and Data Planes Control and data plane separation can be achieved by dividing MAG into two functional entities: MAG control plane functional entity and MAG data plane functional entity as shown in Figure 3. LMA stays the same. LMA can be implemented as virtual machine (VM) in a cloud network. Binding cache and security associations will be stored in the storage center of the cloud entwork that VMs can easily access. MAG Control Plane function together with MAG Data Plane function is geographically distributed and is placed closer to the mobile nodes Sarikaya Expires April 18, 2013 [Page 7] Internet-Draft VMs for Mobility Management October 2012 in order to meet the latency requirements. MN first communicates with the MAG control plane function to establish security association. Address configuration follows. Next MN receives/sends data packets using the LMA closest to the link MN is attached from MAG Data Plane function. When MN moves MN does handover signaling with the control plane function which MAG control plane function updates the binding cache based on this move. MAG control plane function informs the MAG data plane function of this binding cache update and then MN starts to receive and send data to the new data plane function. MN MUST keep MAG control plane function address which is the same in the domain for all MNs in its cache. When MN boots, it goes through authentication and security association establishment. Next MAG control plane function sends a proxy binding update to the LMA. MAG control plane function sends Proxy Binding Update message to the LMA and receives a Proxy Binding Acknowledgement message and in this message MAG control plane function MUST receive (possibly new) LMA address. LMA address can be provided to MAG control plane function in Alternate Home Agent Tunnel Address option defined in [I-D.perkins-netext-hatunaddr] of PBA message [RFC5213]. MAG control plane function passes the LMA address to MAG data plane function. When MAG data plane function receives data packets from MN, it encapsulates the packets and sends them to Alternate Home Agent Tunnel Address. Also when packets are received from Alternate Home Agent Tunnel Address MAG data plane function decapsulates the packet and then send it to the MN. Alternate Home Agent Tunnel Address option in Proxy Mobile IPv6 is much less useful because MAG data plane function could be preconfigured with the LMA address value that happens to be topologically closest LMA. 6. Security Considerations TBD. 7. IANA Considerations TBD. Sarikaya Expires April 18, 2013 [Page 8] Internet-Draft VMs for Mobility Management October 2012 8. Acknowledgements TBD. 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, April 1997. [RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support in IPv6", RFC 6275, July 2011. [RFC5026] Giaretta, G., Kempf, J., and V. Devarapalli, "Mobile IPv6 Bootstrapping in Split Scenario", RFC 5026, October 2007. [RFC5555] Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and Routers", RFC 5555, June 2009. [RFC5648] Wakikawa, R., Devarapalli, V., Tsirtsis, G., Ernst, T., and K. Nagami, "Multiple Care-of Addresses Registration", RFC 5648, October 2009. [RFC5844] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy Mobile IPv6", RFC 5844, May 2010. [I-D.ietf-netext-pmipv6-flowmob] Bernardos, C., "Proxy Mobile IPv6 Extensions to Support Flow Mobility", draft-ietf-netext-pmipv6-flowmob-04 (work in progress), July 2012. [RFC6089] Tsirtsis, G., Soliman, H., Montavont, N., Giaretta, G., and K. Kuladinithi, "Flow Bindings in Mobile IPv6 and Network Mobility (NEMO) Basic Support", RFC 6089, January 2011. [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. [RFC4877] Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with IKEv2 and the Revised IPsec Architecture", RFC 4877, April 2007. Sarikaya Expires April 18, 2013 [Page 9] Internet-Draft VMs for Mobility Management October 2012 [RFC4187] Arkko, J. and H. Haverinen, "Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement (EAP-AKA)", RFC 4187, January 2006. 9.2. Informative references [I-D.ietf-dmm-requirements] Chan, A., "Requirements for Distributed Mobility Management", draft-ietf-dmm-requirements-02 (work in progress), September 2012. [I-D.rekhter-nvo3-vm-mobility-issues] Rekhter, Y., Henderickx, W., Shekhar, R., Fang, L., Dunbar, L., and A. Sajassi, "Network-related VM Mobility Issues", draft-rekhter-nvo3-vm-mobility-issues-03 (work in progress), October 2012. [I-D.perkins-netext-hatunaddr] Perkins, C., "Alternate Tunnel Source Address for LMA and Home Agent", draft-perkins-netext-hatunaddr-00 (work in progress), May 2012. Sarikaya Expires April 18, 2013 [Page 10] Internet-Draft VMs for Mobility Management October 2012 Author's Address Behcet Sarikaya Huawei USA 5340 Legacy Dr. Building 175 Plano, TX 75074 Phone: +1 469 277 5839 Email: sarikaya@ieee.org Sarikaya Expires April 18, 2013 [Page 11]