Network Working Group M. Hasan Internet-Draft Cisco Systems, Inc. Intended status: Informational A. Chari Expires: September 2, 2012 D. Fahed France Telecom - Orange Labs L. Tucker M. Morrow M. Malyon Cisco Systems, Inc. March 2012 A framework for controlling Multitenant Isolation, Connectivity and Reachability in a Hybrid Cloud Environment draft-masum-chari-shc-00 Abstract Multiple enterprises (tenants) consuming resources in a public Cloud shares the physical infrastructure of one or more DCs out of which the Cloud resources are serviced. Hence one of the major features that has to be supported in public Cloud DCs is multitenant isolation, which is realized via various DC isolation technologies, such as VLAN or VxLAN. In a hybrid Cloud environment where a public Cloud (more specifically off-premises public Cloud resources acquired by a tenant ) becomes an _extension_ of a tenant intranet or private Cloud, the multitenant isolation capability has to be extended beyond the public Cloud DCs. The multitenant isolation _domain_ has to span end-to-end from the tenant network or on-premises resources via the MAN/WAN and the public Cloud DC networks to tenant off-premises resources. While multitenant isolationI isolates one tenant from another (inter-hybrid Cloud isolation), an enterprise may desire controlled connectivity to a hybrid Cloud from another Cloud or network or tenant or select resources. In addition, there may be need for controlling direct reachability of resources within a hybrid Cloud itself (intra-hybrid Cloud). The tenant network may be connected to the public Cloud (DCs) over the Internet or a private IP/MPLS MAN/WAN owned or operated by a service provider, which also may support PPVPN (Provider Provided VPN) service, such as the L3 MPLS VPN. In this work we consider the latter type of network and describe a framework for supporting inter-hybrid Cloud multitenant isolation, inter-hybrid Cloud connectivity and intra-hybrid Cloud reachability. Status of this Memo This Internet-Draft is submitted in full conformance with the Hasan, et al. Expires September 2, 2012 [Page 1] Internet-Draft Multitenant Isolation in Hybrid Cloud March 2012 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 September 2, 2012. 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. Hasan, et al. Expires September 2, 2012 [Page 2] Internet-Draft Multitenant Isolation in Hybrid Cloud March 2012 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Acronyms and Definitions . . . . . . . . . . . . . . . . . 5 2. Logical Hybrid Cloud . . . . . . . . . . . . . . . . . . . . . 7 3. Realization Framework . . . . . . . . . . . . . . . . . . . . 11 4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 13 4.1. Use Case 1 - One SHC . . . . . . . . . . . . . . . . . . . 13 4.2. Use Case 2 - Multiple SHC . . . . . . . . . . . . . . . . 15 5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 18 5.1. Network Management . . . . . . . . . . . . . . . . . . . . 18 5.2. Protocol, Control Plane Features . . . . . . . . . . . . . 18 6. Security Considerations . . . . . . . . . . . . . . . . . . . 19 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 8. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 21 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 9.1. References . . . . . . . . . . . . . . . . . . . . . . . . 22 9.2. Normative References . . . . . . . . . . . . . . . . . . . 22 9.3. Informative References . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 Hasan, et al. Expires September 2, 2012 [Page 3] Internet-Draft Multitenant Isolation in Hybrid Cloud March 2012 1. Introduction A Cloud service provider (CSP) offers services to tenants (enterprises, enterprise departments, employees, end consumers) out of one or more Cloud DCs, where a tenant can acquire or release (CRUD: Create, Read, Update, Delete) compute, storage or network resources on-demand and anytime. The CSP exposes Cloud service interfaces to tenants which are used by tenants to CRUD resources. The NIST definition of Cloud computing [NIST] has defined following Cloud deployment models: o Private Cloud: A Cloud for use by an enterprise only, where the Cloud infrastructure and services are owned and/or operated by the enterprise IT or a 3rd party. o Public Cloud: A Cloud that can be used by anyone and owned/ operated/offered by a Cloud Service Provider. o Hybrid Cloud: A Cloud consisting of multiple interoperable Clouds that enables data and application portability. o Community Cloud: The Cloud infrastructure is shared by several organizations and supports a specific community that has shared concerns. The NIST definition of the hybrid Cloud refers to multiple interoperable Clouds to which we include a case where an enterprise may not have a private Cloud. Following are the options in which a hybrid Cloud can be architected or deployed: 1. A1: A tenant intranet and a single public Cloud. 2. A2: A tenant Private Cloud and a single public Cloud. 3. A3: A tenant intranet or private Cloud and multiple public Clouds. 4. A4: A Public Cloud and one or more other public Clouds. In this case the source public Cloud may acquire resources from another public Cloud on behalf of its tenant. 5. A5: A3 + A4. In this document we focus on A1 and A2 (the other options require further considerations and will be addressed in future work). We assume that the same SP owns or operates both the public Cloud (DCs) and the private MAN/WAN. Employing PPVPN (Provider Provided VPN, Hasan, et al. Expires September 2, 2012 [Page 4] Internet-Draft Multitenant Isolation in Hybrid Cloud March 2012 such as L3 MPLS VPN) features we describe a framework that facilitates inter-hybrid Cloud multitenant isolation and connectivity and intra-hybrid Cloud direct reachability between resources in the same hybrid Cloud. Note that the realization framework discussed in this document covers only the MAN/WAN segment of the end-to-end network of a hybrid Cloud. 1.1. Acronyms and Definitions Tenant: An enterprise, enterprise department, enterprise user or end consumer. CRUD: Create, Read, Update, Delete (of resources, entities). ONPR: On-premises resources - Tenant intranet or private Cloud resident resources. OFPR: Off-premises resources - Resources acquired by a tenant in a public Cloud on-demand. MTI: Multitenant Isolation - Isolate traffic and routing/ forwarding/switching instances from one tenant or hybrid Cloud from another. E2E: End-to-end - From ONPR via private MAN/WAN and public Cloud DC networks to OFPR. PPVPN: Provider Provided VPN - VPN that is configured and managed by a service provider on behalf of a tenant. L3MV: L3 MPLS VPN. PE: Provider Edge router. CE: Customer Edge router. VRF: Virtual Routing and Forwarding instance. VRF-Lite: VRF without need for various MPLS and L3MV features typically supported on CE or other DC routers. CSP: Cloud Service Provider - Owns or operates a public and hybrid Cloud. SHC: Seamless Hybrid Cloud - An instance of a logical hybrid Cloud. Hasan, et al. Expires September 2, 2012 [Page 5] Internet-Draft Multitenant Isolation in Hybrid Cloud March 2012 ECRT: BGP Extended Community Route Target. SRTR: Source MPLS PE router that originates or exports vpnv4 routes. DRTR: Destination MPLS PE router that imports vpnv4 routes. Hasan, et al. Expires September 2, 2012 [Page 6] Internet-Draft Multitenant Isolation in Hybrid Cloud March 2012 2. Logical Hybrid Cloud The simplest case of a hybrid Cloud environment is where an enterprise connects to a public Cloud and consumes resources and all- to-all communication, connectivity, reachability and route advertisements are allowed (between the whole enterprise intranet or private Cloud and all the acquired off-premises resources). But enterprises should have the flexibility in defining what constitutes a hybrid Cloud and control communication, connectivity and reachability in and across a hybrid Cloud (for enhanced security, flexibility and enterprise specific needs). While deploying a hybrid Cloud an enterprise (IaaS admin) should be able to specify following (it is expected that a CSP will support these requirements as part of its hybrid Cloud service and expose relevant tenant facing service interfaces so that an enterprise can choose these features; the full definition of services and tenant facing interfaces is beyond the scope of this document; Readers may check seamless Cloud abstraction, model and interfaces [SHCA] ): 1. Logical hybrid Cloud: Creation of instances of hybrid Clouds, for example, each belonging to an organization within the enterprise or for a particular use case or application. We call an instance of a logical hybrid Cloud a _seamless hybrid Cloud (SHC)_. The concept of a tenant is accordingly generalized where each SHC has an associated tenant. Following are the components of an SHC that can be associated to or disassociated from an SHC on-demand (by a tenant IaaS admin) thus allowing flexible hybrid Cloud deployment: 1. Sites: A set of tenant selected sites (DC, remote/branch). Sites not associated with an SHC will not be able to communicate with the SHC or resources in it. When a whole site is selected all the resources in it become accessible from within the SHC. 2. ONPR: A set of on-premises (intranet or private Cloud) resources of a particular site. In this case the whole site is not accessible from within the SHC, only the selected ONPR. 3. OFPR: A set of off-premises resources that are acquired in a public Cloud DC location. 2. Intra-SHC Direct Reachability: ONPR or OFPR that is _directly_ reachable within an SHC. For example, an ONPR or OFPR (such as a web tier) may be directly reachable from within an SHC, but an app tier is reachable indirectly via the web tier. Hasan, et al. Expires September 2, 2012 [Page 7] Internet-Draft Multitenant Isolation in Hybrid Cloud March 2012 3. Inter-SHC connectivity/reachability: Which SHC can connect to or reach directly which other SHC. The multitenant isolation will isolate both the data plane traffic and control plane elements, such as routing/forwarding/switching table instances. Figure 1 shows an example of full view of a network and Cloud. An example of an SHC (as viewed by a tenant) is shown in Figure 2. Hasan, et al. Expires September 2, 2012 [Page 8] Internet-Draft Multitenant Isolation in Hybrid Cloud March 2012 ------------------------- | O ONPR-DB O Other | T1 Site 1 FIGURE 1 | | | Resources| | O FW ------- | | | | HSW: Hypervisor Switch | O ONPR-App1-0 | VLB/FW: Virtual Load-balancer/Firewall | | | ER: Edge Router, CE: Customer Edge | O FW O ONPR- | VM: Virtual Machine, PE: Provider Edge | | | App-D-0 | | O ONPR-DMZ | | | | | | T2 Site 1 T1 Site 5 T1 Site 7 |---------------------- | ------------- ------------- ------------ | Tenant DC Network | | | | | | | | | | | |---------------------- | | | | | | | | | | | | | | | | | | | | | | |----O CE11-------------| |--O CE21---| |--O CE15---| |--O CE17--| | | | | ------------------------- ----------------- | | O PE-TS1------------------------------O PE-TS2 | SP Private (IP/MPLS) MAN/WAN | CSP O PE-CL1------------------------------O PE-CL2 CSP DC-Loc1 | | DC-Loc2 |-------------O ER-CL1-------------------| |--------O ER-CL2--------| | | | | | | | ------------------------- | | ---------------------- | | | CSP DC 1 Core/Aggr | | | |CSP DC 2 Core/Aggr | | | ---------O Access SW1---- | | ------O Access SW2---| | | | | | | \ | | ------------|----------- | | | \ | | | | | | | \ | | ---O HSW 1 ---------- O HSW 2 | | HSW 3 O O HSW 4 | | | | | | | | | | | | | | | | | | | | | | | O VFW | | | | O VFW | | | | | T11 | | | | | T12 | | | --------- ---------- ---- ------ | | ----------- --------- | | | | | | | | | | | | | | | O ... O O ... O O ... O ... | | O ... O O ... | | T1 T1 T1 T1 T2 T1 | | T1 T1 T1 | | VM11 VM12 VM13 VM14 VM21 VM15 | | VM16 VM17 VM18 | | OFPR- OFPR- OFPR- | | OFPR- OFPR- | | DMZ1 App1-1 App-D-1| | App1-2 App-D-2| ------------------------------------------ -------------------------- Hasan, et al. Expires September 2, 2012 [Page 9] Internet-Draft Multitenant Isolation in Hybrid Cloud March 2012 ------------------------- | O ONPR-DB | T1 Site 1 FIGURE 2 | | | | O FW | | | | HSW: Hypervisor Switch | O ONPR-App1-0 | VLB/FW: Virtual Load-balancer/Firewall | | | SHC Cloud Abstractions: | O FW O ONPR- | ST: Site VST: Virtual Site | | | App-D-0 | CDCL: Cloud DC Location | O ONPR-DMZ | | | | | | T1 Site 7 |---------------------- | ------------ | | | | | | |---------------------- | | | | | | | | | | |----O ST11-------------| |--O ST17--| | | |--------- --------- | | O-------------------------------------O | T1-SHC-1 | CSP O-------------------------------------O CSP DC-Loc1 | | DC-Loc2 |-------------O CDCL1---------------------| |--------O CDCL2--------| | / | | | | | / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | VST- O ------------ | | VST- O -------- | | T11 / | | | | T12 | | | | / | | | | | | | | | O VFW | | | O VFW | | | | | T11 | | | | T12 | | | ------ -------- ---- | | ----------- ---------| | | | | | | | | | | | O ... O ... O ... | | O ... O O ... | | T1 T1 T1 | | T1 T1 T1 | | VM11 VM13 VM15 | | VM16 VM17 VM18 | | OFPR- OFPR- OFPR- | | OFPR- OFPR- | | DMZ1 App1-1 App-D-1 | | App1-2 App-D-2| ------------------------------------------ -------------------------- Hasan, et al. Expires September 2, 2012 [Page 10] Internet-Draft Multitenant Isolation in Hybrid Cloud March 2012 3. Realization Framework The realization mechanism described in this document is based on the assumption that the CSP not only owns or operates the public Cloud DCs, but also owns or operates the private IP/MPLS MAN/WAN connecting tenant sites and the CSP DCs (note that with proper framework or interfaces in place this restriction can be lifted). We outline a framework for supporting inter-SHC isolation (multitenant isolation), intra SHC isolation ( reachability rules between SHC components) and inter-SHC connectivity (akin to extranet), which is as follows (note that the realization framework covers only the MAN/WAN segment of the E2E network of an SHC): o The inter-SHC isolation is realized by mapping an SHC to an instance of an L3 MPLS VPN [RFC4364] (L3MV) identified with a VPN ID [RFC2685] to uniquely identify the SHC (SHC-L3MV). The L3MV technology provides a framework for multitenant isolation (of traffic and routes) in the IP/MPLS MAN/WAN. For SHC, the multitenant isolation has to be extended into the public Cloud DCs to incorporate the OFPR in the SHC-L3MV. As shown in Figure 2, the set of OFPR can be considered as virtual L3MV sites, which in the CSP DC network spans from the DC edge (router) to the OFPR resources. On the DC edge the MTI can be realized via the L3MV multitenat feature on customer edge (CE) router, where multiple customers of an SP (such as in a multitenant building) are supported (via VRF-lite together with subinterface or other mechanism to separate traffic and routes of each tenant in the multitenant CE). Following are various options of mapping an SHC to L3MV: * Assuming that the tenant is already on an L3MV with a SP (where all the tenant sites are connected via the private IP/MPLS MAN/ WAN), which is also a CSP: 1. V1: Extend the existing L3MV (L3MV-Original) to include OFPR DC locations (to include OFPR resources) as _extended multitenant L3MV sites_ (set of OFPR of the SHC in a CSP DC becomes virtual L3MV site) of the L3MV-Original. No new L3MV created (see below). This option requires updates of existing configurations every time SHC or its elements (described above) are CRUD on-demand. 2. V2: Create a separate L3MV for an SHC (L3MV-SHC-Extr) identified by its unique VPN ID (different from L3MV- Original). The L3MV-SHC-Extr is then _connected_ as an _extranet_ to the L3MV-Original. Hasan, et al. Expires September 2, 2012 [Page 11] Internet-Draft Multitenant Isolation in Hybrid Cloud March 2012 3. V3: Create a separate L3MV for an SHC (L3MV-SHC) identified by its unique VPN ID, but L3MV-SHC stands on its own without being connected to the L3MV-Original. * In the case where a tenant is not already on an L3MV with a CSP, the V3 option above will cover it. o Map SHC components (Site, ONPR and OFPR) that are specified as directly reachable to BGP Extended Community Route Targets [RFC4360] (ECRT) in L3 MPLS VPN [RFC4364]. While a single resource can be mapped to an ECRT, typically an ONPR or OFPR will be an IP address prefix, subnet or DC tier (such as web, app and DB tiers). With this mapping only routes for selected SHC components will be exchanged between _relevant_ MPLS PEs. o Export the ECRTs from the _source MPLS PE router_ (export of ECRT results in MP-BGP update message to relevant PEs with MP_REACH_NLRI attribute containing VPNv4 address, ECRT and other parameters). Referring to Figure 1, examples of source MPLS PEs are PE-TS1, which is the source for ONPR-DMZ and PE-CL1 for OFPR- App-D2 . o Import the ECRTs in all _relevant_ _destination MPLS PE routers_ of the SHC. Referring to Figure 1, examples of _relevant_ destination PEs are PE-TS1, PE-TS2 and PE-CL1 for OFPR-App-D2. o On public Cloud DC networks the L3MV corresponding an SHC can be mapped to any of existing (such as VRF-lite, VLAN) or new generation DC isolation technologies, such as VxLAN [VXLN]. o When a component is detached from an SHC, withdraw the ECRT (resulting in MP-BGP update message with MP_UNREACH_NLRI). Hasan, et al. Expires September 2, 2012 [Page 12] Internet-Draft Multitenant Isolation in Hybrid Cloud March 2012 4. Use Cases We provide two use cases to explain the framework. 4.1. Use Case 1 - One SHC This use case shows creation of a flexible logical hybrid Cloud or SHC by selectively associating ONPR, OFPR and enterprise sites with the SHC. It also shows intra-SHC direct reachability. Referring to Figure 1, a tenant T1 creates an SHC T1-SHC-1 and associates following components to the SHC: 1. ONPR-DB, which is not directly reachable from within T1-SHC-1 (only via ONPR-App1-0), but accessible in the SHC. 2. ONPR-App1-0, which is not directly reachable (only via ONPR- DMZ), but accessible in the SHC. 3. ONPR-App-D-0, which is directly reachable. 4. ONPR-DMZ, which is directly reachable. 5. T1 Site 1 as a whole is not associated with the SHC. Hence other resources of Site 1 will not be accessible from within T1- SHC-1. 6. T1 Site 5 is not associated with T1-SHC-1. 7. T1 Site 7 is associated with T1-SHC-1. Hence all the resources in it will be accessible from within T1-SHC-1. 8. T1 acquires OFPR-DMZ1 resources in public Cloud DC location DC- Loc1. These resources are directly reachable. 9. T1 acquires OFPR-App1 resources (OFPR-App1-1) in public Cloud DC location DC-Loc1. These resources are not directly reachable, rather via ONPR-DMZ or OFPR-DMZ1. It is assumed that the DMZ web-servers are globally load-balanced to serve requests to instances of App1. 10. T1 acquires OFPR-App-D resources (OFPR-App-D-1) in public Cloud DC location DC-Loc1. These resources are directly reachable. 11. T1 acquires OFPR-App1 resources (OFPR-App1-2) in public Cloud DC location DC-Loc2. These resources are not directly reachable. Hasan, et al. Expires September 2, 2012 [Page 13] Internet-Draft Multitenant Isolation in Hybrid Cloud March 2012 12. T1 acquires OFPR-App-D resources (OFPR-App-D-2) in public Cloud DC location DC-Loc2. These resources are directly reachable. The realization of T1-SHC-1 is as follows: o The T1-SHC-1 is mapped to an L3MV with a unique VPN ID (L3MV-1) that facilitates inter-SHC MTI. Each SHC component described above is mapped as follows: o 1. ONPR-DB is not mapped to an ECRT, that is, its routes will not be advertised in the L3MV-1. 2. ONPR-App1-0 is not mapped to an ECRT, that is, its routes will not be advertised in the L3MV-1. 3. ONPR-App-D-0 is mapped to an ECRT, that is, its routes will be advertised in the L3MV-1. The ECRT is exported by the PE- TS1 and imported by PE-TS2 (to be directly reachable from the Site 7), PE-CL1 (to be directly reachable from the OFPR resources in DC-Loc1) and PE-CL2 (to be directly reachable from the OFPR resources in DC-Loc2). 4. ONPR-DMZ is mapped to an ECRT and exported by PE-TS1 and imported by PE-TS2, PE-CL1 and PE-CL2. 5. T1 Site 1 is not mapped to an ECRT. 6. T1 Site 5 is not mapped to an ECRT. 7. T1 Site 7 is mapped to an ECRT, exported by PE-TS2 and imported by PE-TS1, PE-CL1 and PE-CL2. 8. OFPR-DMZ1 is mapped to an ECRT, exported by PE-CL1 and imported by PE-TS1, PE-TS2 and PE-CL2. 9. OFPR-App1-1 is not mapped to an ECRT. 10. OFPR-App-D-1 is mapped to an ECRT, exported by PE-CL1 and imported by PE-TS1, PE-TS2 and PE-CL2. 11. OFPR-App1-2 is not mapped to an ECRT. 12. OFPR-App-D-2 is mapped to an ECRT, exported by PE-CL2 and imported by PE-TS1, PE-TS2 and PE-CL1. Hasan, et al. Expires September 2, 2012 [Page 14] Internet-Draft Multitenant Isolation in Hybrid Cloud March 2012 4.2. Use Case 2 - Multiple SHC This use case shows the case of inter-SHC connectivity, where two SHCs are connected in a controlled way. In this use case tenant at the Site 7 accesses App1 instances located on-premises in T1 Site 1 via load balancing through ONPR-DMZ or OFPR-DMZ1. Site 7 is associated with a (dedicated) SHC T1-SHC-7 and App1, DB and DMZ resources are grouped into a second SHC T1-SHC-2. Referring to Figure 3, a tenant T1 creates an SHC T1-SHC-7 and associates following components to the SHC: 1. T1 Site 7. The realization of T1-SHC-7 is as follows: o The T1-SHC-7 is mapped to an L3MV with a unique VPN ID (L3MV-7) that facilitates inter-SHC MTI. Each SHC component described above is mapped as follows: o 1. T1 Site 7 is mapped to an ECRT ECRT7, that is, its routes will be advertised into the L3MV-7. The ECRT7 is exported by PE- TS2 (L3MV-7 VRF) and imported into L3MV-2 at PE-TS1 and PE-CL1 (since connectivity to T1-SHC-2 is allowed; see below). Referring to Figure 3, a tenant T1 creates an SHC T1-SHC-2, allows connectivity to T1-SHC-7, and associates following components to the SHC: 1. ONPR-DB, which is not directly reachable (only via ONPR-App1). 2. ONPR-App1, which is not directly reachable (only via ONPR-DMZ). 3. ONPR-DMZ, which is directly reachable from within T1-SHC-2 and T1-SHC-7. 4. T1 acquires OFPR-DMZ1 resources in public Cloud DC location DC- Loc1. These resources are directly reachable from within T1-SHC-2 and T1-SHC-7. The realization of T1-SHC-2 is as follows: o The T1-SHC-2 is mapped to an L3MV with a unique VPN ID (L3MV-2) that facilitates inter-SHC MTI. Each SHC component described above is mapped as follows: Hasan, et al. Expires September 2, 2012 [Page 15] Internet-Draft Multitenant Isolation in Hybrid Cloud March 2012 o 1. ONPR-DB is not mapped to an ECRT. 2. ONPR-App1 is not mapped to an ECRT. 3. ONPR-DMZ is mapped to an ECRT, exported by PE-TS1 and imported into L3MV-2 at PE-CL1 and into L3MV-7 at PE-TS2. 4. OFPR-DMZ1 is mapped to an ECRT, exported by PE-CL1 and imported into L3MV-2 at PE-TS1 and L3MV-7 at PE-TS2. Hasan, et al. Expires September 2, 2012 [Page 16] Internet-Draft Multitenant Isolation in Hybrid Cloud March 2012 ------------------------- | O ONPR-DB | T1 Site 1 FIGURE 3 | | | | O FW | | | | HSW: Hypervisor Switch | O ONPR-App1-0 | VLB/FW: Virtual Load-balancer/Firewall | | | | O FW | | | | | O ONPR-DMZ | | | | T1 Site 7 |---------------------- | ------------ || | | | | | |---------------------- | | | | | | | | | | |----O CE11-------------| |--O CE17--| | | ------------------------- ----------------- | | O PE-TS1------------------------------O PE-TS2 | SP Private (IP/MPLS) MAN/WAN | CSP O PE-CL1------------------------------O PE-CL2 DC-Loc1 | |-------------O ER-CL1-------------------| | | | | ------------------------- | | | CSP DC 1 Core/Aggr | | | ---------O Access SW1---- | | | | | ------------| | | | | | ---O HSW 1 | | | | | | | | | | | | | | --------- | | | | | O | | T1 | | VM11 | | OFPR- | | DMZ1 | ------------------------------------------ Hasan, et al. Expires September 2, 2012 [Page 17] Internet-Draft Multitenant Isolation in Hybrid Cloud March 2012 5. Discussion In this section we discuss various issues that needs future considerations. 5.1. Network Management The framework described in this document is a network management (NM) framework. Hence the framework can be used on any _existing network without any changes_. But NM frameworks typically are not built for on-demand operations, as required in a Cloud environment. As described above, creation or deletion of an SHC should result in creation or deletion of L3MV on-demand so that pay-per-use accounting are turned on or off on-demand. Similarly, association or disassociation of SHC components should result in creation or deletion and export or withdrawal of ECRT on-demand. Currently, these actions can be performed via on-demand application of configuration. But current network (CLI or even NetConf based) configuration/provisioning frameworks are cumbersome to use in an on- demand environment. Hence proper Cloud-ready NM framework and interfaces are needed. 5.2. Protocol, Control Plane Features In current L3MV the import of ECRT in respective L3MV VRF can only be done via (static) pre-configuration, which is not suitable in an on- demand Cloud environment. This process can be automated, if an L3MV is identified by a unique VPN ID and the information is carried in MP-BGP ECRT update messages. As described above, the multitenant isolation (MTI) has to reach all the way to the OFPR. But currently E2E MTI (as required in a hybrid Cloud environment) can only be achieved by stitching together multiple isolation technologies (such as L3MV + VRF-Lite + VLAN or L3MV + VxLAN) with their own limitations. Homogenous E2E MTI technology is desirable. For example, L3MV all the way to a TOR switch (TS), where the TS can functions as a PE and the virtual access switches on hypervisors as L3MV multitenant CE. The L3MV technology handles the case of overlapping private IP addresses of multiple tenants. Hence bringing the technology all the way to the hypervisor will be useful. Hasan, et al. Expires September 2, 2012 [Page 18] Internet-Draft Multitenant Isolation in Hybrid Cloud March 2012 6. Security Considerations Typical security considerations of L3MV configuration will apply. In an on-demand dynamic Cloud environment certain security issues may be amplified. For example, uncontrolled BGP updates as resources are CRUD very dynamically (by a rogue entity). The dynamic application of configuration may amplify the situation of mistaken route leaking from one SHC to another. Hence proper steps should be taken. Hasan, et al. Expires September 2, 2012 [Page 19] Internet-Draft Multitenant Isolation in Hybrid Cloud March 2012 7. IANA Considerations There is no IANA consideration. Hasan, et al. Expires September 2, 2012 [Page 20] Internet-Draft Multitenant Isolation in Hybrid Cloud March 2012 8. Conclusion We have discussed a framework for realizing inter-hybrid Cloud end- to-end multitenant isolation, intra-hybrid Cloud reachability and inter-Hybrid Cloud controlled connectivity. The framework allows creation of a logical hybrid Cloud, we call a seamless hybrid Cloud (SHC), consisting of tenant selected subset of enterprise sites, on- premises resources (resident in tenant network) and off-premises resources (acquired by the tenant on-demand in public Cloud DCs). An SHC is mapped to an L3 MPLS VPN (L3MV) to support inter-SHC multitenant isolation and SHC components are mapped to BGP extended community route targets (ECRT) so that route advertisements of SHC associated components can be controlled and isolated from any other Cloud or non-Cloud L3MV. The intra-SHC reachability and inter-SHC connectivity are also controlled via SHC-component to ECRT mapping and via proper import/export policies involving ECRTs. The framework is network management based allowing support of it on existing infrastructure. We have discussed few issues above (in the Discussion section), which should be addressed. We have not covered the cases A3-A5 discussed in the Introduction section, which also should be addressed. Hasan, et al. Expires September 2, 2012 [Page 21] Internet-Draft Multitenant Isolation in Hybrid Cloud March 2012 9. References 9.1. References 9.2. Normative References [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006. [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended Communities Attribute", RFC 4360, February 2006. 9.3. Informative References [NIST] Mell, P. and T. Grance, "The NIST Definition of Cloud Computing", 800-145 NIST, September 2011, . [SHCA] Hasan, M., Morrow, M., Tucker, L., Gudreddi, S., and S. Figueira, "SEAMLESS CLOUD ABSTRACTION, MODEL AND INTERFACES", In Proc. ITU/IEEE Kaleidoscope Conference, December 2011, Cape Town, South Africa, December 2011, . [VXLN] M.Mahalingam, M. and et.al, "VXLAN: A Framework for Overlaying Virtualized Layer 2 Networks over Layer 3 Networks", draft-mahalingam-dutt-dcops-vxlan-00.txt, August 2011, . [RFC2685] Fox, B. and B. Gleeson, "Virtual Private Networks Identifier", RFC 2685, September 1999, . Hasan, et al. Expires September 2, 2012 [Page 22] Internet-Draft Multitenant Isolation in Hybrid Cloud March 2012 Authors' Addresses Masum Z. Hasan Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 USA Email: masum@cisco.com Abdelhadi Chari France Telecom - Orange Labs 2, avenue Pierre Marzin Lannion , 22307 France Email: abdelhadi.chari@orange.com David Fahed France Telecom - Orange Labs 2, avenue Pierre Marzin Lannion, 22307 France Email: david.fahed@orange.com Lew Tucker Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 USA Email: letucker@cisco.com Monique Morrow Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 USA Email: mmorrow@cisco.com Hasan, et al. Expires September 2, 2012 [Page 23] Internet-Draft Multitenant Isolation in Hybrid Cloud March 2012 Mark Malyon Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 USA Email: mmalyon@cisco.com Hasan, et al. Expires September 2, 2012 [Page 24]