| Network Working Group | A. Name |
| Internet-Draft | April 11, 2013 |
| Intended status: Experimental | |
| Expires: October 13, 2013 |
Security Requirement of NVO3
draft-nvo3-security-document-00
This draft discusses the security issues which need to be considered in achieving Data Center Network Virtualization over L3 tunnels and how such issues could be addressed or mitigated.
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 [RFC2119].
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 October 13, 2013.
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 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.
[I-D.ietf-nvo3-overlay-problem-statement] has indicated that there multiple properties that a virtualized data center networks for multiple tenants may need to provide ( e.g., large amounts of tenant end devices (e.g., VM), the support of VM migration, and dynamic network provisioning). This drafts introdcue the basic security requirement for such a data center network and analyzes the security issues brought by the new features.
Section 2 describes the essential security requirements which should be fulfilled in the generation large scale virtual data center networks supporting multiple tenants. Then, in section 3 we analyze the challenges brought by the new features mentioned in [I-D.ietf-nvo3-overlay-problem-statement].
end system: An end system of a tenant, which can be for instance a virtual machine(VM), a non-virtualized server, or a physical appliance. A TES attaches to 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.
Top of Rack (TOR):
Tentant End System (TES):
In the analysis, it is assumed that an attacker has the capability of
When using the above capability to perform a successful attack on a virtual data center network, an attacker may be able to
Under the attacks mentioned above, a virtual data center network should guarantee the following security properties:
And the following properties are optionally provided:
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.
A NVE and the TESes it supports can be deployed in a distributed way (e.g., a NVE is implemented in a TOR switch, and VMs are located on servers) or on the same device (e.g., a NVE and the VMs it serves are located on the same server).
In the former case, the information exchanged between the NVE and the end devices (e.g., the VMs ) MUST not be accessed by any unauthorized principal. If the network connecting the NVE and the end devices is assumed to be accessible to attackers and the data transported in the network is confidential, the security properties including the integrity, the confidentiality, and the message origin authenticity of the TES traffic need be protected, e.g., by IPsec, SSL, and etc. In addition, it is important to guarantee the isolation of different VNIs. If a NVE supports multiple NVIs concurrently, the traffic of different VNIs must be physically seperated or seperated by e.g., VLAN. A compromised TES MUSt not be able to affect the integrity, availability or isolation of the network.
In the latter case, it is also important for the hypervisor and the NVE component to keep the isolation of the TESes in different VNIs. Although there is no traffic between the TESes and the NVE are transported over the network, it is also important for a VM of tenant to reach the traffic in the VNI of other tenants.
There are could be signaling messages exchanged between the NVE and the end devices (e.g., VMs or hypervisors) for TES management purposes (e.g, VM online detection or VM migration detection). The end devices SHOULD be autenticated, only the signalling messages from the authorized end device will be accepted. This is also very important in keeping the isolation of different VNIs. For instance, if a hypervisor reports the migration of a VM not in the VNIs that the hypervisor supports, the information cannot be used to update the mapping table on the NVE. In addition,
The authenticaiton on end devices could be very important. For instance, in the VXLAN solution [I-D.mahalingam-dutt-dcops-vxlan], an attacker attached to a NVE can force the NVE to keep multicast messages by sending ARP packets to query the VMs existing or not.
This section discusses the security issues within a virtual data center overlay in the control plan and the data plan respectively.
Authentication between NVEs are required. Before, two NVEs exchange any information, mutual authentication must be performed.
The signaling messages must be transported over the underlay network in a secure way, the integrity and original authentication of the messages must be guaranteed. The signaling packets should also be encrypted if the signaling messages are confidential.
When a NVE receives an address mapping information, the NVE must guarantee the information is from an authorized entity before updating its mapping table. For instance, when if a message is about the address mapping of a VM inside a VNI but from a NVE which is not authorized to serve the VNI, the information must not be input into the mapping table.
A data of a tenant transported between two NVEs should not be accessed by any un-authorized principal. If the underlay network can potentially be accessed by attackers, the overlay Must be able to provide the protection on the integrity, confidentiality, and original authentication of the data.
Comments about Control Plane Overlays: First, sreplace plan with plane. Why is authentication important? One answer is that you make some authorization requirements. Is mapping update the only thing that requires authorization? What's the insider attack model? Are there central controllers? Or do NVEs get to generate mapping updates as well as receive them? If there are controllers, is it important to prevent an NVE from impersonating a controller? Are all NVEs equal? Is it important to prevent one NVE from impersonating another? Note that the answer can be "sometimes". For example in KARP, we've said that you want to be able to isolate trusted zones from each other even though inside attacks are not in scope. See the top few paragraphs on page 10 of draft-ietf-karp-ops-model. Your discussion in the authorization section where you point out that an NVE not authorized to hold a given TES should not be able to update the mapping for that TES. That's an example of the sort of trusted zone thing we are talking about. If you have a lot of that going on, you do tend to need to require no impersonation. That tends to require strong key management rather than preshared keys.
NOV3 assumes all the NVO3 overlay is within a administration domain, and so the issues with federated authentication and authorization need not to be considered. However, the overlay should work in an environment where there could be many thousands of NVEs (e.g. residing within the hypervisors), and the scalability issues should be considered. In the cases where a NVE only have a limited number of NVEs to communicate with, the scalability issue imposed by the overhead of generating maintaining the security channels with the peers 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.
In addition, if the packets transported through out overlay are encrypted, 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.
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 are process by a single firewall. However this solution may cause traffic optimization issues.
T
This document makes no request of IANA.
Note to RFC Editor: this section may be removed on publication as an RFC.
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. |