draft-ietf-nvo3-security-requirements-02.txt   draft-ietf-nvo3-security-requirements-03.txt 
Network Working Group S. Hartman Network Working Group S. Hartman
Internet-Draft Painless Security Internet-Draft Painless Security
Intended status: Experimental D. Zhang Intended status: Experimental D. Zhang
Expires: July 28, 2014 Huawei Expires: April 30, 2015 Huawei
M. Wasserman M. Wasserman
Painless Security Painless Security
January 24, 2014 October 27, 2014
Security Requirements of NVO3 Security Requirements of NVO3
draft-ietf-nvo3-security-requirements-02 draft-ietf-nvo3-security-requirements-03
Abstract Abstract
The draft describes a list of essential requirements in order to The draft describes a list of essential requirements in order to
benefit the design of NOV3 security solutions. In addition, this benefit the design of NOV3 security solutions. In addition, this
draft introduces the candidate techniques which could be used to draft introduces the candidate techniques which could be used to
construct a security solution fulfilling these security requirements. construct a security solution fulfilling these security requirements.
Requirements Language Requirements Language
skipping to change at page 1, line 42 skipping to change at page 1, line 42
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 28, 2014. This Internet-Draft will expire on April 30, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 23 skipping to change at page 2, line 23
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. NVO3 Overlay Architecture . . . . . . . . . . . . . . . . . . 4 3. NVO3 Overlay Architecture . . . . . . . . . . . . . . . . . . 4
4. Threat Model . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Threat Model . . . . . . . . . . . . . . . . . . . . . . . . 4
4.1. Capabilities of Outsiders . . . . . . . . . . . . . . . . 5 4.1. Capabilities of Outsiders . . . . . . . . . . . . . . . . 5
4.2. Capabilities of Insiders . . . . . . . . . . . . . . . . 5 4.2. Capabilities of Insiders . . . . . . . . . . . . . . . . 5
4.3. Capabilities of Malicious TSes . . . . . . . . . . . . . 5 4.3. Capabilities of Malicious TSes . . . . . . . . . . . . . 6
4.4. Security Issues In Scope and Out of Scope . . . . . . . . 6 4.4. Security Issues In Scope and Out of Scope . . . . . . . . 6
5. Security Requirements . . . . . . . . . . . . . . . . . . . . 7 5. Security Requirements . . . . . . . . . . . . . . . . . . . . 7
5.1. Control/Data Plane of NVO3 Overlay . . . . . . . . . . . 7 5.1. Control/Data Plane of NVO3 Overlay . . . . . . . . . . . 7
5.1.1. NVE-NVA Control Plane . . . . . . . . . . . . . . . . 7 5.1.1. NVE-NVA Control Plane . . . . . . . . . . . . . . . . 7
5.1.2. NVA-NVA Control Plane . . . . . . . . . . . . . . . . 9 5.1.2. NVA-NVA Control Plane . . . . . . . . . . . . . . . . 9
5.1.3. NVE-NVE Data Plane . . . . . . . . . . . . . . . . . 10 5.1.3. NVE-NVE Control Plane . . . . . . . . . . . . . . . . 10
5.2. Control/Data Plane between NVEs and Hypervisors . . . . . 11 5.1.4. NVE-NVE Data Plane . . . . . . . . . . . . . . . . . 10
5.2. Control/Data Plane between NVEs and Hypervisors . . . . . 12
5.2.1. Distributed Deployment of NVE and Hypervisor . . . . 12 5.2.1. Distributed Deployment of NVE and Hypervisor . . . . 12
6. Candidate Techniques . . . . . . . . . . . . . . . . . . . . 14 6. Candidate Techniques . . . . . . . . . . . . . . . . . . . . 15
6.1. Entity Authentication . . . . . . . . . . . . . . . . . . 14 6.1. Entity Authentication . . . . . . . . . . . . . . . . . . 15
6.2. Packet Level Security . . . . . . . . . . . . . . . . . . 15 6.2. Packet Level Security . . . . . . . . . . . . . . . . . . 15
6.3. Authorization . . . . . . . . . . . . . . . . . . . . . . 15 6.3. Authorization . . . . . . . . . . . . . . . . . . . . . . 15
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
8. Security Considerations . . . . . . . . . . . . . . . . . . . 15 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16
8.1. Automated Key Management in NVO3 . . . . . . . . . . . . 15 8.1. Automated Key Management in NVO3 . . . . . . . . . . . . 16
8.2. Issues not Discussed . . . . . . . . . . . . . . . . . . 16 8.2. Issues not Discussed . . . . . . . . . . . . . . . . . . 16
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
10.1. Normative References . . . . . . . . . . . . . . . . . . 16 10.1. Normative References . . . . . . . . . . . . . . . . . . 17
10.2. Informative References . . . . . . . . . . . . . . . . . 17 10.2. Informative References . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction 1. Introduction
Security is a key issue which needs to be considered during the Security is a key issue which needs to be considered during the
design of a data center network. This document discusses the design of a data center network. This document discusses the
security risks that a NVO3 network may encounter and tries to provide security risks that a NVO3 network may encounter and tries to provide
a list of essential security requirements that a NVO3 network needs a list of essential security requirements that a NVO3 network needs
to fulfill. In addition, this draft introduces the candidate to fulfill. In addition, this draft introduces the candidate
skipping to change at page 3, line 17 skipping to change at page 3, line 18
The remainder of this document is organized as follows. Section 2 The remainder of this document is organized as follows. Section 2
introduces several key terms used in this memo. Section 3 gives a introduces several key terms used in this memo. Section 3 gives a
brief introduction of the NVO3 network architecture. Section 4 brief introduction of the NVO3 network architecture. Section 4
discusses the attack model of this work. Section 5 provides a list discusses the attack model of this work. Section 5 provides a list
of security requirements as well as the associated justifications. of security requirements as well as the associated justifications.
In Section 6, the candidate techniques are introduced. In Section 6, the candidate techniques are introduced.
2. Terminology 2. Terminology
This document uses the same terminology as found in the NVO3 This document uses the same terminology as found in the NVO3
Framework document [I-D.ietf-nvo3-framework] and Framework document [RFC7365] and [I-D.ietf-nvo3-hpvr2nve-cp-req].
[I-D.kreeger-nvo3-hypervisor-nve-cp]. Some of the terms defined in Some of the terms defined in the framework document have been
the framework document have been repeated in this section for the repeated in this section for the convenience of the reader, along
convenience of the reader, along with additional terminology that is with additional terminology that is used by this document.
used by this document.
Tenant System (TS): A physical or virtual system that can play the Tenant System (TS): A physical or virtual system that can play the
role of a host, or a forwarding element such as a router, switch, role of a host, or a forwarding element such as a router, switch,
firewall, etc. It belongs to a single tenant and connects to one or firewall, etc. It belongs to a single tenant and connects to one or
more VNs of that tenant. more VNs of that tenant.
End System (ES): An end system of a tenant, which can be, e.g., a End System (ES): An end system of a tenant, which can be, e.g., a
virtual machine(VM), a non-virtualized server, or a physical virtual machine(VM), a non-virtualized server, or a physical
appliance. A TS is attached to a Network Virtualization Edge(NVE) appliance. A TS is attached to a Network Virtualization Edge(NVE)
node. node.
skipping to change at page 4, line 33 skipping to change at page 4, line 33
+---+ +---+
| |
| |
===================== =====================
| | | |
+--------+ +--------+ +--------+ +--------+
| Tenant | | Tenant | | Tenant | | Tenant |
| System | | System | | System | | System |
+--------+ +--------+ +--------+ +--------+
Figure 1: Generic Reference Model for DC Network Virtualization
Overlays [RFC7365]
This figure illustrates a simple nov3 overlay example where NVEs This figure illustrates a simple nov3 overlay example where NVEs
provide a logical L2/L3 interconnect for the TSes that belong to a provide a logical L2/L3 interconnect for the TSes that belong to a
specific tenant network over L3 networks. A packet from a tenant specific tenant network over L3 networks. A packet from a tenant
system is encapsulated when they reach the ingress NVE. Then system is encapsulated when they reach the ingress NVE. Then
encapsulated packet is then sent to the remote NVE through a proper encapsulated packet is then sent to the remote NVE through a proper
tunnel. When reaching the egress NVE of the tunnel, the packet is tunnel. When reaching the egress NVE of the tunnel, the packet is
decapsulated and forwarded to the target tenant system. The address decapsulated and forwarded to the target tenant system. The address
advertisements and tunnel mappings are distributed to the NVEs by a advertisements and tunnel mappings are distributed to the NVEs by a
logically centralized server (i.e., NVA). logically centralized server (i.e., NVA).
4. Threat Model 4. Threat Model
To benefit describing the threats a NVO3 network may have to face, in To benefit describing the threats a NVO3 network may have to face,
this work, attacks are classified into three categories: the attacks the attacks considered in this document are classified into three
from compromised NVO3 devices (inside attacks), the attacks from categories: the attacks from compromised NVO3 devices (inside
compromised tenant systems, and the attacks from underlying networks attacks), the attacks from compromised tenant systems, and the
(outside attacks). attacks from underlying networks (outside attacks).
The adversaries performing the first type of attack are called as The adversaries performing the first type of attack are called as
insiders or inside attackers because they need to get certain insiders or inside attackers because they need to get certain
privileges in changing the configuration or software of NVO3 devices privileges in changing the configuration or software of NVO3 devices
beforehand and initiate the attacks within the overlay security beforehand and initiate the attacks within the overlay security
perimeter. In the second type of attack, an attacker has got certain perimeter. In the second type of attack, an attacker (e.g., a
privileges in changing the configuration or software of tenant malicious tenant, or an attacker who has compromised a virtual
systems (e.g., hypervisors or virtual machines) and attempts to machine of an innocent tenant) has got certain privileges in changing
the configuration or software of tenant systems and attempts to
manipulate the controlled tenant systems to interfere with the normal manipulate the controlled tenant systems to interfere with the normal
operations of the NVO3 overlay. The third type of attack is referred operations of the NVO3 overlay. The third type of attack is referred
to as the outside attack since adversaries do not have to obtain any to as the outside attack since adversaries do not have to obtain any
privilege on the NVO3 devices or tenant systems in advance in order privilege on the NVO3 devices or tenant systems in advance in order
to perform this type attack, and thus the adversaries performing to perform this type attack, and thus the adversaries performing
outside attacks are called as outside attackers or outsiders. outside attacks are called as outside attackers or outsiders.
4.1. Capabilities of Outsiders 4.1. Capabilities of Outsiders
In practice, an outside attacker may perform attacks by intercepting In practice, an outside attacker may perform attacks by intercepting
packets, deleting packets, and/or inserting bogus packets. With a packets, deleting packets, and/or inserting bogus packets. With a
successful outside attack, an attacker may be able to: successful outside attack, an attacker may be able to:
1. Analyze the traffic pattern within the network, 1. Analyze the traffic pattern within the network by performing
passive attacks,
2. Disrupt the network connectivity or degrade the network service 2. Disrupt the network connectivity or degrade the network service
quality, or quality (e.g., by performing DoS attacks), or
3. Access the contents of the data/control packets which are not 3. Access the contents of the data/control packets which are not
properly encrypted. properly encrypted.
4.2. Capabilities of Insiders 4.2. Capabilities of Insiders
Besides intercepting packets, deleting packets, and/or inserting Besides intercepting packets, deleting packets, and/or inserting
bogus packets, an inside attacker may use already obtained privilege bogus packets, an inside attacker may use already obtained privilege
to, to,
skipping to change at page 7, line 28 skipping to change at page 7, line 33
In this section, the security requirements associated with the NVE- In this section, the security requirements associated with the NVE-
NVA control plane, the NVA-NVA control plane, and the NVE-NVE data NVA control plane, the NVA-NVA control plane, and the NVE-NVE data
plane are proposed. plane are proposed.
5.1.1. NVE-NVA Control Plane 5.1.1. NVE-NVA Control Plane
In a NVE-NVA control plane, it is assumed that a NVE only exchanges In a NVE-NVA control plane, it is assumed that a NVE only exchanges
control traffics with its NVA using unicast. control traffics with its NVA using unicast.
REQ 1: The security solution for NVO3 SHOULD enable two NVO3 devices REQ 1: The security solution for NVO3 SHOULD enable two NVO3 devices
to mutually authenticate each other before they exchange any to mutually authenticate each other.
control packets.
Entity authentication can protect a network device against Entity authentication can protect a network device against
imposter attacks and then reduce the risk of DoS attacks and man- imposter attacks and then reduce the risk of DoS attacks and man-
in-the-middle attacks. In addition, a successful authentication in-the-middle attacks. In addition, a successful authentication
normally results in the distribution key materials for the normally results in the distribution key materials for the
security protection for subsequent communications. security protection for subsequent communications. Note that in
the circumstance where no authentication protocols are applied
there could be no entity authentication and communicating NOV3
devices use message authentication mechanisms to verify each
other's identity. More detailed discussions are provided in
Section 8.1.
REQ 2: The security solution of NVO3 MUST be able to provide REQ 2: The security solution of NVO3 MUST be able to provide
integrity protection, replay protection, and packet origin integrity protection, replay protection, and packet origin
authentication for the control packets. authentication for the control packets.
Unlike entity authentication, message authentication is performed Unlike entity authentication mentioned in REQ 1, message
on each incoming packet. Through message authentication, the NOV3 authentication is performed on each incoming packet. Through
device receiving a control packet can verify whether the packet is message authentication, the NOV3 device receiving a control packet
generated by a legitimate NVO3 device, is not antique, and is not can verify whether the packet is generated by a legitimate NVO3
tampered during transportation. In addition, with the support of device, is not antique, and is not tampered during transportation.
properly distributed keys, the packet level protection can also Such protection be deployed when the control packets could be
benefit the detection of spoofing attacks raised from insiders. accessed by outside attackers. In addition, with the support of
properly distributed keys, these level protection can also benefit
the detection of spoofing attacks raised from insiders.
REQ 3: The security solution of a NVO3 network MAY provide REQ 3: The security solution of a NVO3 network MAY provide
confidentiality protection for the control packets. confidentiality protection for the control packets.
On many occasions, the control packets can be transported in On many occasions, the control packets can be transported in
plaintext. However, under the circumstances where some plaintext. However, under the circumstances where some
information contained within the control packets is considered to information contained within the control packets is considered to
be sensitive or valuable, the information needs to be encrypted be sensitive or valuable, the information needs to be encrypted in
especially when the underlying network is not secure. Note that order to prevent outsiders from accessing the sensitive data. when
encryption will impose additional overhead in processing control the underlying network is not secure. Note that encryption will
packets and make NVAs more vulnerable to DoS/DDoS attacks. impose additional overhead in processing control packets and make
NVAs more vulnerable to DoS/DDoS attacks.
REQ 4: Before accepting a control packet, a NOV3 device receiving REQ 4: Before adopting the information within a control packet, a
the packet MUST be able to verify whether the packet comes from NOV3 device receiving the packet MUST be able to verify whether
one who has the privilege to send that packet. the packet comes from one who has the privilege to send that
packet.
When receiving a control packet, besides authentication, When receiving a control packet, besides authentication,
authorization needs to be carried out by the receiver to identify authorization needs to be carried out by the receiver to identify
the role that the packet sender acts as in the overlay and then the role that the packet sender acts as in the overlay and then
assess the sender's privileges. If a compromised NVE tries to assess the sender's privileges. If a compromised NVE tries to
illegally elevate its privilege (e.g., using its credentials to illegally elevate its privilege (e.g., using its credentials to
communicate with other NVEs as a NVA, or attempting to access the communicate with other NVEs as a NVA, or attempting to access the
mapping information of the VNs which it is not authorized to mapping information of the VNs which it is not authorized to
serve), it will be detected and rejected. serve), it will be detected and rejected.
REQ 5: The security solution of NVO3 SHOULD be able to provide REQ 5: The security solution of NVO3 SHOULD be able to provide
distinct keys to protect the control traffics exchanged between a distinct keys to protect the unicast control traffics exchanged
NVA and different NVEs respectively. between a NVA and different NVEs respectively.
During the exchange of control packets, keys are critical in During the exchange of control packets, keys are critical in
authenticating the packet senders. The purpose of this authenticating the packet senders. The purpose of this
requirement is to provide a basic capability to confine the damage requirement is to provide a basic capability to confine the damage
caused by inside attacks. After compromising a NVE, an attacker caused by inside attacks. After compromising a NVE, an attacker
will not be able to use the keys it obtained to breach the will not be able to use the keys it obtained to breach the
security of the control traffics exchanged between the NVA and security of the control traffics exchanged between the NVA and
other NVEs. other NVEs.
In a NVO3 overlay, NVAs can be the valuable targets of DoS/DDoS In a NVO3 overlay, NVAs can be the valuable targets of DoS/DDoS
skipping to change at page 9, line 31 skipping to change at page 9, line 43
plane. plane.
Except the key deployment requirement (REQ 5), all the other Except the key deployment requirement (REQ 5), all the other
requirements in the NVE-NVA control plane (REQs 1,2,3,4, 6, and 7) requirements in the NVE-NVA control plane (REQs 1,2,3,4, 6, and 7)
are applicable in the NVA-NVA control plane as well. Before two NVA are applicable in the NVA-NVA control plane as well. Before two NVA
communicate with each other, they should be able to mutually communicate with each other, they should be able to mutually
authenticated. In addition, message authentication can help a NVO3 authenticated. In addition, message authentication can help a NVO3
device to verify the authenticity of the received packets, and the device to verify the authenticity of the received packets, and the
sensitive information in the control packets need to be encrypted. sensitive information in the control packets need to be encrypted.
Authorization is important to filter the invalid control packets and Authorization is important to filter the invalid control packets and
any un-priviledged requests. Moreover, the approach to mitigating any un-privileged requests. Moreover, the approach to mitigating
DoS/DDoS attacks needs to be considered in the control plane DoS/DDoS attacks needs to be considered in the control plane
protocols. protocols.
The key deployment requirements for the NVA-NVA control plane are The key deployment requirements for the NVA-NVA control plane are
described as follows: described as follows:
REQ 8: The security solution of NVO3 SHOULD be able to provide REQ 8: The security solution of NVO3 SHOULD be able to provide
different keys to protect the unicast control traffics exchanged different keys to protect the unicast control traffics exchanged
between different NVAs respectively. between different NVO3 devices respectively.
The purpose of this requirement is to provide a basic capability The purpose of this requirement is to provide a basic capability
to confine the damage caused by compromised key. The compromise to confine the damage caused by compromised key. The compromise
of a key will not affect the traffics protected by other keys. of a key will not affect the traffics protected by other keys.
REQ 9: If there are multicast packets, the security solution of NVO3 REQ 9: If there are multicast packets, the security solution of NVO3
SHOULD be able to assign distinct cryptographic group keys to SHOULD be able to assign distinct cryptographic group keys to
protect the multicast packets exchanged among the NVAs within protect the multicast packets exchanged among the NVO3 devices
different multicast groups. within different multicast groups.
In order to provide an essential packet level security protection In order to provide an essential packet level security protection
specified in REQs 2 and 3, at least a group key may need to be specified in REQs 2 and 3, at least a group key may need to be
shared among the NVEs in a same mutlicast group. It is shared among the NVEs in a same mutlicast group. It is
recommended to user different keys for different mutlicast groups. recommended to use different keys for different mutlicast groups.
5.1.3. NVE-NVE Data Plane 5.1.3. NVE-NVE Control Plane
As specified in [I-D.ietf-nvo3-framework], a NVO3 overlay needs to As specified in [RFC7365], in order to obtain reachability
generate tunnels between NVEs for data packet transportation. When a information, NVEs may exchange information directly between
data packet reaches the boundary of a overlay, the ingress NVE will themselves via a control-plane protocol.
encapsulate the packet and forward it to the destination egress NVE
through a proper tunnel. The requirements in the NVA-NVA control plane (REQs 1,2,3,4, 6, 7,8,
and 9) are applicable in the NVE-NVE control plane as well.
5.1.4. NVE-NVE Data Plane
As specified in [RFC7365], a NVO3 overlay needs to generate tunnels
between NVEs for data packet transportation. When a data packet
reaches the boundary of a overlay, the ingress NVE will encapsulate
the packet and forward it to the destination egress NVE through a
proper tunnel.
REQ 10: The security solution for NVO3 SHOULD enable two NVEs to REQ 10: The security solution for NVO3 SHOULD enable two NVEs to
mutually authenticate each other before establishing a tunnel mutually authenticate each other before establishing a tunnel
connecting them for data transportation. connecting them for data transportation.
This entity authentication requirement is used to protect a NVE This entity authentication requirement is used to protect a NVE
against imposter attacks. Also, this requirement can help against imposter attacks. Also, this requirement can help
guarantee a data tunnel is generated between two proper NVEs and guarantee a data tunnel is generated between two proper NVEs and
reduce the risk of man-in-the-middle attacks. reduce the risk of man-in-the-middle attacks.
skipping to change at page 11, line 49 skipping to change at page 12, line 24
needs to be detected and discarded. Note that the detection of a needs to be detected and discarded. Note that the detection of a
invalid packet may not indicate that the system is under a invalid packet may not indicate that the system is under a
malicious attack. Mis-configuration or byzantine failure of a NVE malicious attack. Mis-configuration or byzantine failure of a NVE
may also result in such invalid packets. may also result in such invalid packets.
5.2. Control/Data Plane between NVEs and Hypervisors 5.2. Control/Data Plane between NVEs and Hypervisors
Apart from data traffics, the NVE and hypervisors may also need to Apart from data traffics, the NVE and hypervisors may also need to
exchange signaling packets in order to facilitate, e.g., VM online exchange signaling packets in order to facilitate, e.g., VM online
detection, VM migration detection, or auto-provisioning/service detection, VM migration detection, or auto-provisioning/service
discovery [I-D.ietf-nvo3-framework]. discovery [RFC7365].
A NVE and the hypervisors working with it can be deployed in a A NVE and the hypervisors working with it can be deployed in a
distributed way (e.g., the NVE is implemented in an individual distributed way (e.g., the NVE is implemented in an individual
device, and the hypervisors are located on servers) or in a co- device, and the hypervisors are located on servers) or in a co-
located way (e.g., the NVE and the hypervisors are located on the located way (e.g., the NVE and the hypervisors are located on the
same server). In the former case, the data and control traffic same server). In the former case, the data and control traffic
between the NVE and the hypervisors are exchanged over network. between the NVE and the hypervisors are exchanged over network.
5.2.1. Distributed Deployment of NVE and Hypervisor 5.2.1. Distributed Deployment of NVE and Hypervisor
skipping to change at page 13, line 17 skipping to change at page 13, line 39
sending the packet is authorized to do so. sending the packet is authorized to do so.
This is an authorization requirement. When receiving a control/ This is an authorization requirement. When receiving a control/
data packet, besides authentication, authorization needs to be data packet, besides authentication, authorization needs to be
carried out by a NVE or a hypervisor to identify the role that the carried out by a NVE or a hypervisor to identify the role that the
packet sender acts as and then assess the sender's privileges. packet sender acts as and then assess the sender's privileges.
Therefore, if a compromised hypervisor attempts to use it Therefore, if a compromised hypervisor attempts to use it
credentials to impersonate a NVE to communicate with other credentials to impersonate a NVE to communicate with other
hypervisors, it will be detected. hypervisors, it will be detected.
REQ 20: The security solution of a NVO3 network SHOULD be able to REQ 20: The security solution of a NVO3 SHOULD be able to provide
provide different security levels of protections for the control/ different security levels of protections for the control/data
data traffics exchanged between a NVE or a hypervisor. traffics exchanged between a NVE or a hypervisor.
The control and data traffics between a NVE and a hypervisor may The control and data traffics between a NVE and a hypervisor may
be transported over the same path or even within the same security be transported over the same path or even within the same security
channel. However, when the control traffics and data traffics channel. However, when the control traffics and data traffics
have different levels of sensitivity, the protection on them needs have different levels of sensitivity, the protection on them needs
be different. In this case, the security solution may need to be different. In this case, the security solution may need to
different security channels for control and data traffics different security channels for control and data traffics
respectively and so protect the data and control traffics respectively and so protect the data and control traffics
exchanged between a hypervisor and a NVE with different keys and exchanged between a hypervisor and a NVE with different keys and
ciphers. ciphers.
skipping to change at page 14, line 22 skipping to change at page 14, line 44
This issues should be considered in the design of the control This issues should be considered in the design of the control
protocols. protocols.
5.2.1.2. Data Plane 5.2.1.2. Data Plane
REQ 24: The security solution of a NVO3 network MUST provide REQ 24: The security solution of a NVO3 network MUST provide
security gateways to control the data traffics across the security gateways to control the data traffics across the
boundaries of different VNs according to specified security boundaries of different VNs according to specified security
policies. policies.
In [I-D.ietf-nvo3-overlay-problem-statement], the data plane In [RFC7364], the data plane isolation requirement amongst
isolation requirement amongst different VNs has been discussed. different VNs has been discussed. The traffic within a virtual
The traffic within a virtual network can only be transited into network can only be transited into another one in a controlled
another one in a controlled fashion (e.g., via a configured router fashion (e.g., via a configured router and/or a security gateway).
and/or a security gateway).
REQ 25: The security solution of a NVO3 network MAY provide REQ 25: The security solution of a NVO3 network MAY provide
confidentiality protection for the data traffics exchanged between confidentiality protection for the data traffics exchanged between
a NVE and a hypervisor. a NVE and a hypervisor.
When the contents of the data packets are sensitive to a tenant, When the contents of the data packets are sensitive to a tenant,
the data packet needs to be encrypted. The security solution of a the data packet needs to be encrypted. The security solution of a
NVE network may need to provide confidentiality for the data NVE network may need to provide confidentiality for the data
packets exchanged between a NVE and a hypervisor if they have to packets exchanged between a NVE and a hypervisor if they have to
use an insecure network to transport their data packet and the use an insecure network to transport their data packet and the
skipping to change at page 15, line 13 skipping to change at page 15, line 35
and etc. and etc.
It is recommended to cryptographically verify the devices' identities It is recommended to cryptographically verify the devices' identities
during authentication. Therefore, an inside attacker cannot use the during authentication. Therefore, an inside attacker cannot use the
keys or credentials got from the compromised device to impersonate keys or credentials got from the compromised device to impersonate
other victims. other victims.
6.2. Packet Level Security 6.2. Packet Level Security
There are requirements about protecting the integrity, There are requirements about protecting the integrity,
confidentiality, and provide packet origin authentication for control confidentiality, and provide packet origin authentication for
/ data packets. Such functions can be provided through using the control/ data packets. Such functions can be provided through using
underlying security protocols (e.g., IPsec AH[RFC4302], IPsec the underlying security protocols (e.g., IPsec AH[RFC4302], IPsec
ESP[RFC4303], TLS[RFC5246]). Also, when designing the control ESP[RFC4303], TLS[RFC5246]). Also, when designing the control
protocols people can select to provide embedded security approaches protocols people can select to provide embedded security approaches
(just like the packet level security mechanism provided in (just like the packet level security mechanism provided in
OSPFv2[RFC2328]). The cryptographic keys can be manually deployed or OSPFv2[RFC2328]). The cryptographic keys can be manually deployed or
dynamically generated by using certain automatic key management dynamically generated by using certain automatic key management
protocols. Note that when using manual key management, the replay protocols. Note that when using manual key management, the replay
protection mechanism of IPsec will be switched off. protection mechanism of IPsec will be switched off.
6.3. Authorization 6.3. Authorization
skipping to change at page 17, line 12 skipping to change at page 17, line 29
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
10.2. Informative References 10.2. Informative References
[I-D.ietf-ipsecme-ad-vpn-problem] [I-D.ietf-ipsecme-ad-vpn-problem]
Manral, V. and S. Hanna, "Auto Discovery VPN Problem Manral, V. and S. Hanna, "Auto Discovery VPN Problem
Statement and Requirements", draft-ietf-ipsecme-ad-vpn- Statement and Requirements", draft-ietf-ipsecme-ad-vpn-
problem-09 (work in progress), July 2013. problem-09 (work in progress), July 2013.
[I-D.ietf-nvo3-framework] [I-D.ietf-nvo3-hpvr2nve-cp-req]
Lasserre, M., Balus, F., Morin, T., Bitar, N., and Y. Yizhou, L., Yong, L., Kreeger, L., Narten, T., and D.
Rekhter, "Framework for DC Network Virtualization", draft- Black, "Hypervisor to NVE Control Plane Requirements",
ietf-nvo3-framework-04 (work in progress), November 2013. draft-ietf-nvo3-hpvr2nve-cp-req-00 (work in progress),
July 2014.
[I-D.ietf-nvo3-overlay-problem-statement]
Narten, T., Gray, E., Black, D., Fang, L., Kreeger, L.,
and M. Napierala, "Problem Statement: Overlays for Network
Virtualization", draft-ietf-nvo3-overlay-problem-
statement-04 (work in progress), July 2013.
[I-D.kreeger-nvo3-hypervisor-nve-cp]
Kreeger, L., Narten, T., and D. Black, "Network
Virtualization Hypervisor-to-NVE Overlay Control Protocol
Requirements", draft-kreeger-nvo3-hypervisor-nve-cp-01
(work in progress), February 2013.
[I-D.mahalingam-dutt-dcops-vxlan] [I-D.mahalingam-dutt-dcops-vxlan]
Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger,
L., Sridhar, T., Bursell, M., and C. Wright, "VXLAN: A L., Sridhar, T., Bursell, M., and C. Wright, "VXLAN: A
Framework for Overlaying Virtualized Layer 2 Networks over Framework for Overlaying Virtualized Layer 2 Networks over
Layer 3 Networks", draft-mahalingam-dutt-dcops-vxlan-06 Layer 3 Networks", draft-mahalingam-dutt-dcops-vxlan-09
(work in progress), November 2013. (work in progress), April 2014.
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange
(IKE)", RFC 2409, November 1998. (IKE)", RFC 2409, November 1998.
[RFC4046] Baugher, M., Canetti, R., Dondeti, L., and F. Lindholm, [RFC4046] Baugher, M., Canetti, R., Dondeti, L., and F. Lindholm,
"Multicast Security (MSEC) Group Key Management "Multicast Security (MSEC) Group Key Management
Architecture", RFC 4046, April 2005. Architecture", RFC 4046, April 2005.
skipping to change at page 18, line 21 skipping to change at page 18, line 28
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC
4306, December 2005. 4306, December 2005.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008. (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen,
"Internet Key Exchange Protocol Version 2 (IKEv2)", RFC "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC
5996, September 2010. 5996, September 2010.
[RFC7364] Narten, T., Gray, E., Black, D., Fang, L., Kreeger, L.,
and M. Napierala, "Problem Statement: Overlays for Network
Virtualization", RFC 7364, October 2014.
[RFC7365] Lasserre, M., Balus, F., Morin, T., Bitar, N., and Y.
Rekhter, "Framework for Data Center (DC) Network
Virtualization", RFC 7365, October 2014.
Authors' Addresses Authors' Addresses
Sam Hartman Sam Hartman
Painless Security Painless Security
356 Abbott Street 356 Abbott Street
North Andover, MA 01845 North Andover, MA 01845
USA USA
Email: hartmans@painless-security.com Email: hartmans@painless-security.com
URI: http://www.painless-security.com URI: http://www.painless-security.com
 End of changes. 34 change blocks. 
90 lines changed or deleted 108 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/