draft-hartman-nvo3-security-requirements-00:
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: hartmans@painless-security.com
URI: http://www.painless-security.com
Dacheng Zhang
Huawei
Beijing,
China
Phone:
Fax:
Email: zhangdacheng@huawei.com
URI:
Margaret Wasserman
Painless Security
356 Abbott Street
North Andover, MA 01845
USA
Phone: +1 781 405 7464
Email: mrw@painless-security.com
URI: http://www.painless-security.com
Hartman, et al. Expires August 22, 2013 [Page 10]
