NV03 Working Group Y. Wei, Ed. Internet Draft ZTE Corporation Intended status: Informational L. Fang, Ed. Expires: January 16, 2013 Cisco Systems S. Zhang ZTE Corporation July 16, 2012 NVO3 Security Framework draft-wei-nvo3-security-framework-01 Abstract This document provides a security framework for overlay based network virtualization. It describes the security reference model, the security threats and security requirements. Status of this Memo This Internet-Draft is submitted to IETF 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 January 16, 2013. Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. [Page 1] NVO3 Security Framework Expires Jan. 2013 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 described in the Simplified BSD License. Table of Contents 1. Introduction .................................................2 2 2. Terminologies ................................................3 3 3. Security Reference Models ....................................5 5 3.1. Scenario 1: Virtual Network and DC infrastructure belong to the same DC operator ............................................5 5 4. Security Threats .............................................6 6 4.1. Attacks on Control Plane ..................................7 7 4.2. Attacks on the Data Plane .................................7 7 5. Security Requirements ........................................8 8 5.1. Control Plane Security Requirements .......................8 8 5.2. Data Plane Security Requirements ..........................8 8 6. Security Considerations ......................................8 8 7. IANA Considerations ..........................................9 9 8. Normative References .........................................9 9 9. Informative References .......................................9 9 10. Author's Addresses ........................................10 10 Requirements Language Although this document is not a protocol specification, 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 RFC 2119 [RFC 2119]. 1. Introduction [Page 2] NVO3 Security Framework Expires Jan. 2013 Security is one of most important factors in the environment of cloud computing and particularly to the Data Center Network Virtualization where multi-tenancy support is one of the fundamental requirements. Though security considerations are provided in several individual documents, a general description of security for NVO3 is needed, especially there are areas not covered in the current documents. The motivation of this document is to provide a general and consistent security framework for NVO3, and to provide a guidance for the design of related protocol. This document is organized as follows. Section 3 describes the security reference model in the context of NVO3, which defines which component is trusted or not for a particular scenario. Section 4 describes the security threats under the security model. Section 5 addresses the security requirements in response to the security threats. 2. Terminologies This document uses NVO3 specific terminology defined in [I- D.lasserre-nvo3-framework]. For reader's convenience, this document repeats some of the definitions in addition to reference it. NVE: Network Virtualization Edge. It is a network entity that sits on the edge of the NVO3 network. It implements network virtualization functions that allow for L2 and/or L3 tenant separation and for hiding tenant addressing information (MAC and IP addresses). An NVE could be implemented as part of a virtual switch within a hypervisor, a physical switch or router, a Network Service Appliance or even be embedded within an End Station. VN: Virtual Network. This is a virtual L2 or L3 domain that belongs a tenant. VNI: Virtual Network Instance. This is one instance of a virtual overlay network. Two Virtual Networks are isolated from one another and may use overlapping addresses. Virtual Network Context or VN Context: Field that is part of the overlay encapsulation header which allows the encapsulated frame to be delivered to the appropriate virtual network endpoint by the egress NVE. The egress NVE uses this field to determine the appropriate virtual network context in which to process the packet. This field MAY be an explicit, unique (to the administrative domain) virtual network identifier (VNID) or MAY express the [Page 3] NVO3 Security Framework Expires Jan. 2013 necessary context information in other ways (e.g. a locally significant identifier). VNID: Virtual Network Identifier. In the case where the VN context has global significance, this is the ID value that is carried in each data packet in the overlay encapsulation that identifies the Virtual Network the packet belongs to. Underlay or Underlying Network: This is the network that provides the connectivity between NVEs. The Underlying Network can be completely unaware of the overlay packets. Addresses within the Underlying Network are also referred to as "outer addresses" because they exist in the outer encapsulation. The Underlying Network can use a completely different protocol (and address family) from that of the overlay. Data Center (DC): A physical complex housing physical servers, network switches and routers, Network Service Appliances and networked storage. The purpose of a Data Center is to provide application and/or compute and/or storage services. One such service is virtualized data center services, also known as Infrastructure as a Service. Virtual Data Center or Virtual DC: A container for virtualized compute, storage and network services. Managed by a single tenant, a Virtual DC can contain multiple VNs and multiple Tenant End Systems that are connected to one or more of these VNs. VM: Virtual Machine. Several Virtual Machines can share the resources of a single physical computer server using the services of a Hypervisor (see below definition). Hypervisor: Server virtualization software running on a physical compute server that hosts Virtual Machines. The hypervisor provides shared compute/memory/storage and network connectivity to the VMs that it hosts. Hypervisors often embed a Virtual Switch (see below). Virtual Switch: A function within a Hypervisor (typically implemented in software) that provides similar services to a physical Ethernet switch. It switches Ethernet frames between VMs' virtual NICs within the same physical server, or between a VM and a physical NIC card connecting the server to a physical Ethernet switch. It also enforces network isolation between VMs that should not communicate with each other. Tenant: A customer who consumes virtualized data center services offered by a cloud service provider. A single tenant may consume [Page 4] NVO3 Security Framework Expires Jan. 2013 one or more Virtual Data Centers hosted by the same cloud service provider. Tenant End System: It defines an end system of a particular tenant, which can be for instance a virtual machine (VM), a non-virtualized server, or a physical appliance. 3. Security Reference Models This section defines the security reference models for Overlay based Network Virtualization. The L3 overlay network provides virtual network to multi-tenants, which is deployed on the underlying network. The tenant end system attaches to the L3 overlay network. L3 overlay network provides isolation to each tenant, which provides a level of security to its tenant. L3 overlay network can be regarded secure zone from the view of ONV3 operator. Other components outside of the ONV3 are considered as untrusted, which may impose security risk to the NVO3 networks. Each virtual network should assume not trusting other virtual networks. This model is the basis to analyze the security of ONV3. 3.1. Scenario 1: Virtual Network and DC infrastructure belong to the same DC operator |<-----------(Trusted)---------->| | | | /---------------------------\ | ++ Virtual Network L3 Overlay ++ | \---------------------------/ | +----------+ +--+------+ +-----------+ +-------+-+ +----------+ |Tenant End| | NV | | DC infra | | NV | |Tenant End| | System +-+ Edge +--+ Underlay +--+ Edge +-+ System | | (TES) | | (NVE) | | Network | | (NVE) | | (TES) | +----------+ +---------+ +-----------+ +---------+ +----------+ |<---------->|<-------->|<------------>|<--------->|<---------->| |(Untrusted) | (Trusted)| (Trusted) | (Trusted) |(Untrusted) | Figure 1. Trust Model for Scenario 1 [Page 5] NVO3 Security Framework Expires Jan. 2013 Notes: 1) The diagram is a logical illustration. The TES and NVE may be implemented in the same physical device, or separate devices. 2) The physical end system may in reality include virtual switching/routing instances and multiple VMs (TESs) belong to different tenants. 3) The trusted or untrusted notions in the diagram is from a Virtual Overlay Network point of view, not the underlay network. 4) Each VN treats other VNs as untrusted. Scenario 2: Virtual Network and DC infrastructure belong to different DC operators |<-----------(Trusted)---------->| | | | /---------------------------\ | ++ Virtual Network L3 Overlay ++ | \---------------------------/ | +----------+ +--+------+ +-----------+ +-------+-+ +----------+ |Tenant End| | NV | | DC infra | | NV | |Tenant End| | System +-+ Edge +--+ Underlay +--+ Edge +-+ System | | (TES) | | (NVE) | | Network | | (NVE) | | (TES) | +----------+ +---------+ +-----------+ +---------+ +----------+ |<---------->|<-------->|<------------>|<--------->|<---------->| |(Untrusted) | (Trusted)| (Untrusted) | (Trusted) |(Untrusted) | Figure 2. Trust Model for Scenario 2 The same notes listed under scenario 1 also apply here. 4. Security Threats This section describes the various security threats that may endanger overlay based network virtualization. For example, an attack on ONV3 may result in some unexpected effects: o Interrupt the connectivity of tenant's virtual network. o Inject some unwanted traffic into virtual network. o Eavesdrop sensitive information from tenant. o Degrade provider's service level. [Page 6] NVO3 Security Framework Expires Jan. 2013 Security threats may be malicious or casual. For example, some of them may come from the following sources: o A tenant who rents one or more virtual networks may want to acquire some information from other tenants co-existed in the same data center. o Some persons who manipulate the activation, migration or deactivation of tenant's virtual machine. o Some persons who physically access to underlying network. 4.1. Attacks on Control Plane 1. Attack association between VM and VN: one of the functionalities of ONV3 is to provide virtual network to multi- tenants. ONV3 associates a virtual machine's NIC with corresponding virtual network, and maintain that association as the VM is activated, migrated or deactivated. The signaling information between endpoint and access switch may be spoofed or altered. Thus the association between VM and VN may be invalid if the signaling is not properly protected. 2. Attack the mapping of a virtual network: The mapping between the inner and outer addresses may be affected through altering the mapping table. 3. Inject traffic: The comprised underlying network may inject traffic into virtual network. 4. Attack live migration: An attacker may cause guest VMs to be live migrated to the attacker's machine and gain full control over guest VMs. 5. Denial of Service attacks against endpoint by false resource advertising: for live migration initiated automatically to distribute load across a number of servers, an attacker may falsely advertise available resources via the control plane. By pretending to have a large number of spare CPU cycles, that attacker may be able to influence the control plane to migrate a VM to a compromised endpoint. 4.2. Attacks on the Data Plane 1. Unauthorized snooping of data traffic: This is attack results in leakage of sensitive information, attacker can sniffer information from the user packets and extract their content. [Page 7] NVO3 Security Framework Expires Jan. 2013 2. Modification of data traffic: An attacker may modify, insert or delete data packets and impersonate them as legitimate ones. 3. Man-in-the-Middle attack on live migration of VM: When a virtual machine is migrated from one endpoint to another, the VM may be intercepted and modified in the middle of the migration. 5. Security Requirements This section describes security requirements for control plane and data plane of NVO3. 5.1. Control Plane Security Requirements 1. The network infrastructure shall support mechanisms for authentication and integrity protection of the control plane. (1)When a protocol is used for the service auto- provisioning/discovery, the information from endpoint shall not be spoofed or altered. (2)When a protocol is used to distribute address advertisement and tunneling information, the protocol shall provide integrity protection. (3)The protocol for tunnel management shall provide integrity and authentication protection. 2. NVEs shall assure the information in the mapping table is coming from a trusted source. 3. The virtual network should prevent malformed traffic injection from underlying network, other virtual network, or endpoint. 5.2. Data Plane Security Requirements 1. The mapping function from the tenant to overlay shall be protected. NVEs should verify VNID is not spoofed. 2. The data plane should protect VM's state against snooping and tampering. 3. IPsec can be used to provide authentication, integrity and confidentiality protection. IPsec can be used to protect the data plane. 6. Security Considerations [Page 8] NVO3 Security Framework Expires Jan. 2013 This document discusses general security threats and requirements for NVO3. Individual document may raise specific issues based on the particular content and should address them in the individual document. 7. IANA Considerations This document contains no new IANA considerations. 8. Normative References 9. Informative References [Editors' note: All Network Virtualization with Layer 3 (NVO3) Internet drafts or related ID(s) referenced in the following list are currently work in progress individual drafts in their early development stage, status and text are subject to change, more reference may be added along with the development of the NVO3 WG.] [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4111] Fang, L., Fang, L., Ed., "Security Framework for Provider-Provisioned Virtual Private Networks (PPVPNs)", RFC 4111, July 2005. [RFC5920] Fang, L., "Security Framework for MPLS and GMPLS Networks", RFC 5920, July 2010. [opsec-efforts] Lonvick, C., and Spak, D., "Security Best Practices Efforts and Documents", IETF draft-ietf-opsec-efforts-18.txt, April 2012. [VM-Migration] Oberheide, Jon., Cooke, Evan., and Farnam. Jahanian, "Empirical Exploitation of Live Virtual Machine Migration", Feb 2011. [I-D.narten-nvo3-overlay-problem-statement] Narten, T., Sridhavan, M., Dutt, D., Black, D., and L. Kreeger, "Problem Statement: Overlays for Network Virtualization", draft-narten-nvo3-overlay- problem-statement-02 (work in progress), June 2012. [I-D.fang-vpn4dc-problem-statement] Napierala M., Fang L., Cai, Dennis, "IP-VPN Data Center Problem Statement and Requirements", draft-fang-vpn4dc-problem-statement-01.txt, June 2012. [Page 9] NVO3 Security Framework Expires Jan. 2013 [I-D.lasserre-nvo3-framework] Lasserre, M., Balus, F., Morin, T., Bitar, N., and Y.Rekhter, "Framework for DC Network Virtualization", draft-lasserre-nvo3-framework-03 (work in progress), July 2012. [I-D.kreeger-nvo3-overlay-cp] Black, D., Dutt, D., Kreeger, L., Sridhavan, M., and T. Narten, "Network Virtualization Overlay Control Protocol Requirements", draft-kreeger-nvo3-overlay-cp-00 (work in progress), January 2012. [I-D.bitar-lasserre-nvo3-dp-reqs] Bitar, N., Lasserre, M., and F. Balus, "NVO3 Data Plane Requirements", draft-bitar-lasserre-nvo3- dp-reqs-00 (work in progress), May 2012. 10. Author's Addresses Yinxing Wei (Editor) ZTE Corporation No 68, Zijinghua Road Nanjing, Jiangsu 210012 China Phone: +86 25 52872328 Email: wei.yinxing@zte.com.cn Luyuan Fang (Editor) Cisco Systems, Inc. 111 Wood Ave. South Iselin, NJ 08830 USA Email: lufang@cisco.com Shiwei Zhang ZTE Corporation No 68, Zijinghua Road Nanjing, Jiangsu 210012 China Phone: +86 25 52870100 Email: zhang.shiwei@zte.com.cn [Page 10]