Internet DRAFT - draft-wei-nvo3-security-framework
draft-wei-nvo3-security-framework
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]
