Security Requirements of NVO3
Author(s): Margaret Wasserman, Dacheng Zhang, Sam Hartman
This draft discusses the security requirements and several issues which need to be considered in securing a virtualized data center network for multiple tenants. In addition, the draft also attempts to discuss how such issues could be addressed...
Network Working Group S. Hartman Internet-Draft Painless Security Intended status: Experimental D. Zhang Expires: August 22, 2013 Huawei M. Wasserman Painless Security February 18, 2013 Security Requirements of NVO3 draft-hartman-nvo3-security-requirements-00 Abstract This draft discusses the security requirements and several issues which need to be considered in securing a virtualized data center network for multiple tenants. In addition, the draft also attempts to discuss how such issues could be addressed or mitigated. Requirements Language 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]. 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 August 22, 2013. Copyright Notice Copyright (c) 2013 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 Hartman, et al. Expires August 22, 2013 [Page 1] Internet-Draft NVO3 security February 2013 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminologies . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Threat Model . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Basic Security Requirements . . . . . . . . . . . . . . . . . . 5 4.1. Security Requirements Between NVEs and TESes . . . . . . . 5 4.2. Security Requirements within Overlays . . . . . . . . . . . 6 4.2.1. Control Plan Security . . . . . . . . . . . . . . . . . 6 4.2.2. Data Plan Security . . . . . . . . . . . . . . . . . . 7 5. Security Issues Imposed by the New Overlay Design Characteristics . . . . . . . . . . . . . . . . . . . . . . . . 7 5.1. Scalability Issues . . . . . . . . . . . . . . . . . . . . 7 5.2. Influence on Security Devices . . . . . . . . . . . . . . . 8 5.3. Security Issues with VM Migration . . . . . . . . . . . . . 8 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 9 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 9.1. Normative References . . . . . . . . . . . . . . . . . . . 9 9.2. Informative References . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 Hartman, et al. Expires August 22, 2013 [Page 2] Internet-Draft NVO3 security February 2013 1. Introduction In [I-D.ietf-nvo3-overlay-problem-statement], it is indicated that there multiple properties that a virtualized data center network for multiple tenants may need to provide ( e.g., large amounts of tenant end devices (TESes), the support of TES (e.g., VM) migration, and dynamic network provisioning). This draft introduces the basic security requirements for such a data center network and introduce several security issues brought by the new features. The remainder of this document is organized as follows. (Section 3) introduces the the attack model of this work and the properties that a NOV3 security mechanism needs to enforce. Section 4 describes the essential security requirements which should be fulfilled in the generation of a virtual data center network supporting multiple tenants. Then, in Section 5, we analyze the challenges brought by the new features mentioned in[I-D.ietf-nvo3-overlay-problem-statement]. 2. Terminologies Tenant End System (TES): An end system of a tenant, which can be, e.g., a virtual machine(VM), a non-virtualized server, or a physical appliance. A TES is attached to a Network Virtualization Edge(NVE) node. Network Virtualization Edge(NVE): An NVE implements network virtualization functions that allow for L2/L3 tenant separation, tenant-related control plane activity. An NVE contains one or more tenant service instances whereby a TES interfaces with its associated instance. The NVE also provides tunneling overlay functions. Virtual Network Instance (VNI): This is one instance of a virtual overlay network. Two Virtual Networks are isolated from one another and may use overlapping addresses. 3. Threat Model In the analysis, it is assumed that an attacker has the capability of 1. intercepting the packets transported through a virtual data center network, 2. replaying the intercepted packets, and Hartman, et al. Expires August 22, 2013 [Page 3] Internet-Draft NVO3 security February 2013 3. generating fake packets and injecting them into the network. When using the above capability to perform a successful attack on a virtual data center network, an attacker may be able to 1. obtain the data which it is un-authorized to access, 2. analyze the traffic pattern of a tenant or a end device, or 3. disrupt and degrade the service quality of the network. Under the attacks performed by an attacker, a virtual data center network MUST guarantee the following security properties: 1. Isolation of the VNIs. Isolation benefits not only in simplifying managemt operations but also in confining the damages of attacks.In [I-D.ietf-nvo3-overlay-problem-statement], the data plane isolation amongst different VNIs has been discussed. The traffic within a virtual network can only be transited into another one in a controlled fashion (e.g., via a configured router and/or a security gateway). Apart from that, the control plane isolation in the overlay is also very important. That is, an entity cannot make use of its privilege obtained within a VNI to manipulate the overlay control plane to affect on the operations of other VNIs. 2. Integrity and origin authentication of the control plane: All the control panel implementations of the overlay MUST support the integrity protection on the signaling packets. No entity can modify a overlay signaling packet during its transportation without being detected. Also, an attacker cannot impersonate a legal victim (e.g., a NVE or another servers within the overlay) to send signaling packets without detection. 3. Availability of the control plane: The design of the control plan must consider the DDOS attacks. Especially, when there are centralized servers in the control plan of the overlay, the servers must be well protected and make sure that they will not become the bottle neck of the control plane especially under DDOS attacks. And the following properties SHOULD be optionally provided: 1. Confidentiality and integrity of the TES traffic. In some conditions, the cryptographic protection on the TES traffic is not necessary. For example, if most of the TES data is headed towards the Internet and nothing is confidential, encryption is redundant. In addition, in the cases where the underlay network Hartman, et al. Expires August 22, 2013 [Page 4] Internet-Draft NVO3 security February 2013 is secure enough, no additional cryptographic protection needs to be provided. 2. Confidentiality of the control plane. On many occasions, the the signaling messages can be transported in plaintext. However, when some information contained within the signaling messages are sensitive to a tenant (e.g., the location of a TES, when a TES migration happens), the signaling messages related with that tenant should be encrypted. Note that the following two types of attacks is out of the scope of this draft: the attacks taking advantage of social engineering, and the attacks taking advantage of the weak security algorithms, the drawbacks of security protocols, or the loopholes of security implementations. In addition, NOV3 assumes all the NVO3 overlay is within a administration domain, and so there is no issue with federated authentication and authorization. 4. Basic Security Requirements 4.1. Security Requirements Between NVEs and TESes A NVE and the TESes it supports can be deployed in a distributed way (e.g., a NVE is implemented in an individual device, and VMs are located on servers) or in a co-located way (e.g., a NVE and the VMs it serves are located on the same server). In the former case, the packets between the NVE and the TESes are exchanged over a network. If the network connecting the NVE and the TESes is potentially accessible to attackers, the protection on the the security properties including the integrity, the confidentiality, and the message origin authenticity of the data traffic of TESes SHOULD be provided, e.g., by IPsec, SSL, and etc., according to different security requirements. In addition, in the conditions where there are signaling messages exchanged between the NVE and the end devices (e.g., VMs or hypervisors) for the purposes of, e.g., VM online detection or VM migration detection, the integrity of the those packets MUST be ensured since such messages may be used to the state of the NVE and then be distributed across the overlay. The end devices sending the signaling messages SHOULD be authenticated, and only the signaling messages from the authorized TESes will be accepted. In addition, it is important to guarantee the isolation between different VNIs. If a NVE supports multiple NVIs concurrently, the traffic of the TESes in different VNIs must be separated physically or by e.g., VLAN. In addition, to confine the damage caused by a compromised TES, A TES in a VNI is not allowed to distribute the information about other VNIs. For instance, When a Hartman, et al. Expires August 22, 2013 [Page 5] Internet-Draft NVO3 security February 2013 NVE receives an address mapping information, the NVE must guarantee the information is from an authorized entity before updating its mapping table. In the latter case, all the communication between the NVE and the TESes are located within the same device. It is also important to keep the isolation of the TES traffic in different VNIs. In addition, in the co-location fashion, because the NVE, the hypervisor, and the VMs are deployed on the same device, the computing and memory resources of the NVE , the hypervisor, and the TESes need to be isolated to prevents a malicious or compromised TES from accessing the memory of the NVE or affecting the performance of the NVE by occupying large amounts of computing resources. 4.2. Security Requirements within Overlays This section discusses the security issues within a virtual data center overlay in the control plan and the data plan respectively. 4.2.1. Control Plan Security In an overlay, the signaling messages must be transported over the underlay network in a secure way, the integrity and origin authentication of the messages must be guaranteed. The signaling packets should also be encrypted if the signaling messages are confidential. The issues of DDOS attacks also need to be considered in designing the overlay control plane. For instance, in the VXLAN solution[I-D.mahalingam-dutt-dcops-vxlan], an attacker attached to a NVE can try to manipulate the NVE to keep multicasting messages by sending ARP packets to query the VMs which does not exist. In order to mitigate this type of attack, the NVEs SHOULD be only allowed to send signaling message in the overlay with a limited frequency. When there are centralized servers (e.g., the backend oracles providing mapping information for NVEs[I-D.ietf-nvo3-overlay-problem-statement], or the SDN controllers) are located within the overlay, the potential security risks caused by DDOS attack on such servers can be more serious. When considering inside attacks where one or more NVEes are compromised, authentication between the communicating entities within the overlay (NVEs, the centralized servers) is important. Only the control messages from the authenticated entity will be adopted. In addition, authorization MAY need to be performed. For instance, when a NVE receives a control message about the operations in a VNI, the NVE needs to verify whether the message comes from one which is authorized to work for that VNI. If the authentication or the Hartman, et al. Expires August 22, 2013 [Page 6] Internet-Draft NVO3 security February 2013 authorization fail, the control message will be discarded. In order enforce the security boundary of different VNIs, the signaling messages of different VNIs need be protected by different keys. Otherwise, a compromised NVE could use the key it got within a VNI to impersonate the NVEs in other VNIs which it is not involved within and generate fake signaling messages without being detected. If we expect to provide a better attack confinement capability and prevent a compromised NVE to impersonate other NVEs in the same VNI, different NVEs working inside a NVI need to secure their signaling messages with different keys. When there are centralized servers providing mapping information within the overlay, it will be important to prevent a compromised NVE from impersonating the centralized servers to communicate with other NVEs. A straightforward solution is to associate different NVEs with different keys when they exchange information with the centralized servers. Since the NVO3 overlay is expected to consist of a large amount of NVEs, manual key management could be infeasible. First, it becomes burdensome to deploy pre-shared keys for thousands of NVEs, not to mention that multiple keys may need to be deployed on a single device for different purposes. Key derivation can be used to mitigate this problem. That is, multiple keys are derived from a pre-shared master key for different usuages. However, key derivation cannot protect against the situation where a system was incorrectly trusted to have the key used to perform the derivation. If the master key were somehow compromised, all the resulting keys would need to be changed. In addition, TES migration will also introduce challenges to manual key management. The migration of a VM in a VNI may cause the change of the NVEs which are involved within the NVI. A NVE newly involved within a VNI needs to get the key to join the operations within the VNI. A NVE no longer supporting a VNI should not keep the key associated with that VNI. All those updates of the key are performed at run time and difficult to be performed by human beings. As a result, it is feasible to introduce an auto key management solution for NVO3 overlays. 4.2.2. Data Plan Security As illustrated in Section 3, the security of data plan is optionally provided. 5. Security Issues Imposed by the New Overlay Design Characteristics 5.1. Scalability Issues NOV3 WG requires an overlay be able to work in an environment where there are many thousands of NVEs (e.g. residing within the hypervisors) and large amounts of trust domains (VNIs). Therefore, Hartman, et al. Expires August 22, 2013 [Page 7] Internet-Draft NVO3 security February 2013 the scalability issues should be considered. In the cases where a NVE only has a limited number of NVEs to communicate with, the scalability problem brought by the overhead of generating and maintaining the security channels with the remote NVEs is not serious. However, if a NVE needs to communicate with a large number of peers, the scalability issue could be serious. For instance, in[I-D.ietf-ipsecme-ad-vpn-problem], it has been demonstrated it is not trivial to enabling a large number of systems to communicate directly using IPsec to protect the traffic between them. 5.2. Influence on Security Devices If the data packets transported through out an overlay are encrypted (e.g., by NVEs), it is difficult for a security device, e,g., a firewall deployed on the path to intercept the contents of the packets. The firewall can only know which VNI the packets belong to through the VNID transported in the outer header. If a firewall would like to identify which end device sends a packets or which end device a packet is sent to, the firewall can be deployed in some place where it can access the packet before it is encapsulated or un- encapsulated by NVEs. However, in this case, the firewall cannot get VN ID from the packet. If the firewall is used to process two VNIs concurrently and there are IP or MAC addresses of the end devices in the two VNIs overlapped, confusion will be caused. If a firewall can generate multiple firewalls instances for different tenants respectively, this issue can be largely addressed. 5.3. Security Issues with VM Migration The support of VM migration is an important issue considered in NVO3 WG. The migration may also cause security risks. Because the VMs within a VNI may move from one server to another which connects to a different NVE, the packets exchanging between two VMs may be transferred in a new path. If the security policies deployed on the firewalls of the two paths are conflict or the firewalls on the new path lack essential state to process the packets. The communication between the VMs may be broken. To address this problem, one option is to enable the state migration and policy confliction detection between firewalls. The other one is to force all the traffic within a VNI be processed by a single firewall. However this solution may cause traffic optimization issues. 6. IANA Considerations This document makes no request of IANA. Note to RFC Editor: this section may be removed on publication as an Hartman, et al. Expires August 22, 2013 [Page 8] Internet-Draft NVO3 security February 2013 RFC. 7. Security Considerations TBD 8. Acknowledgements 9. References 9.1. Normative References [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 9.2. Informative References [I-D.ietf-ipsecme-ad-vpn-problem] Hanna, S. and V. Manral, "Auto Discovery VPN Problem Statement and Requirements", draft-ietf-ipsecme-ad-vpn-problem-03 (work in progress), December 2012. [I-D.ietf-nvo3-overlay-problem-statement] Narten, T., Gray, E., Black, D., Dutt, D., Fang, L., Kreeger, L., Napierala, M., and M. Sridharan, "Problem Statement: Overlays for Network Virtualization", draft-ietf-nvo3-overlay-problem-statement-02 (work in progress), February 2013. [I-D.mahalingam-dutt-dcops-vxlan] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, L., Sridhar, T., Bursell, M., and C. Wright, "VXLAN: A Framework for Overlaying Virtualized Layer 2 Networks over Layer 3 Networks", draft-mahalingam-dutt-dcops-vxlan-02 (work in progress), August 2012. Hartman, et al. Expires August 22, 2013 [Page 9] Internet-Draft NVO3 security February 2013 Authors' Addresses Sam Hartman Painless Security 356 Abbott Street North Andover, MA 01845 USA Email: firstname.lastname@example.org URI: http://www.painless-security.com Dacheng Zhang Huawei Beijing, China Phone: Fax: Email: email@example.com URI: Margaret Wasserman Painless Security 356 Abbott Street North Andover, MA 01845 USA Phone: +1 781 405 7464 Email: firstname.lastname@example.org URI: http://www.painless-security.com Hartman, et al. Expires August 22, 2013 [Page 10]