draft-ietf-nvo3-security-requirements-03.txt   draft-ietf-nvo3-security-requirements-04.txt 
Network Working Group S. Hartman
Internet Draft Painless Security
Intended status: Informational D. Zhang
Expires: July 28,, 2015 Alibaba
M. Wasserman
Painless Security
Z. Qiang
Ericsson
Mingui Zhang
Huawei
January 28, 2015
Network Working Group S. Hartman Security Requirements of NVO3
Internet-Draft Painless Security draft-ietf-nvo3-security-requirements-04
Intended status: Experimental D. Zhang
Expires: April 30, 2015 Huawei
M. Wasserman
Painless Security
October 27, 2014
Security Requirements of NVO3
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 NVO3 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
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
Status of This Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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
working documents as Internet-Drafts. The list of current Internet- documents as Internet-Drafts. The list of current Internet-Drafts is
Drafts is at http://datatracker.ietf.org/drafts/current/. 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 April 30, 2015. This Internet-Draft will expire on July 28, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2015 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction...................................................3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology....................................................3
3. NVO3 Overlay Architecture . . . . . . . . . . . . . . . . . . 4 3. NVO3 Overlay Architecture......................................4
4. Threat Model . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Threat Model...................................................5
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 . . . . . . . . . . . . . 6 4.3. Capabilities of Malicious TSes............................6
4.4. Security Issues In Scope and Out of Scope . . . . . . . . 6 5. Scope..........................................................6
5. Security Requirements . . . . . . . . . . . . . . . . . . . . 7 6. Security Requirements..........................................8
5.1. Control/Data Plane of NVO3 Overlay . . . . . . . . . . . 7 6.1. Control Plane of NVO3 Overlay.............................8
5.1.1. NVE-NVA Control Plane . . . . . . . . . . . . . . . . 7 6.2. NVE-NVE Data Plane.......................................11
5.1.2. NVA-NVA Control Plane . . . . . . . . . . . . . . . . 9 6.3. NVE-Hypervisor Data Plane................................13
5.1.3. NVE-NVE Control Plane . . . . . . . . . . . . . . . . 10 7. Candidate Techniques..........................................15
5.1.4. NVE-NVE Data Plane . . . . . . . . . . . . . . . . . 10 7.1. Entity Authentication....................................15
5.2. Control/Data Plane between NVEs and Hypervisors . . . . . 12 7.2. Packet Level Security....................................15
5.2.1. Distributed Deployment of NVE and Hypervisor . . . . 12 7.3. Authorization............................................15
6. Candidate Techniques . . . . . . . . . . . . . . . . . . . . 15 8. IANA Considerations...........................................16
6.1. Entity Authentication . . . . . . . . . . . . . . . . . . 15 9. Security Considerations.......................................16
6.2. Packet Level Security . . . . . . . . . . . . . . . . . . 15 9.1. Automated Key Management in NVO3.........................16
6.3. Authorization . . . . . . . . . . . . . . . . . . . . . . 15 10. Acknowledgements.............................................17
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 11. References...................................................17
8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 11.1. Normative References....................................17
8.1. Automated Key Management in NVO3 . . . . . . . . . . . . 16 11.2. Informative References..................................17
8.2. Issues not Discussed . . . . . . . . . . . . . . . . . . 16
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
10.1. Normative References . . . . . . . . . . . . . . . . . . 17
10.2. Informative References . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction
Security is a key issue which needs to be considered during the
design of a data center network. This document discusses the
security risks that a NVO3 network may encounter and tries to provide
a list of essential security requirements that a NVO3 network needs
to fulfill. In addition, this draft introduces the candidate
techniques which could be potentially used to construct a security
solution fulfilling the security requirements.
The remainder of this document is organized as follows. Section 2
introduces several key terms used in this memo. Section 3 gives a
brief introduction of the NVO3 network architecture. Section 4
discusses the attack model of this work. Section 5 provides a list
of security requirements as well as the associated justifications.
In Section 6, the candidate techniques are introduced.
2. Terminology
This document uses the same terminology as found in the NVO3 1. Introduction
Framework document [RFC7365] and [I-D.ietf-nvo3-hpvr2nve-cp-req].
Some of the terms defined in the framework document have been
repeated in this section for the convenience of the reader, along
with additional terminology that is used by this document.
Tenant System (TS): A physical or virtual system that can play the As described in [RFC7365], the NVO3 framework is intended to aid in
role of a host, or a forwarding element such as a router, switch, standardizing protocols and mechanisms to support large-scale multi-
firewall, etc. It belongs to a single tenant and connects to one or tenancy data centers. In such kind data center, security is a key
more VNs of that tenant. issue which needs to be considered during the network design. This
document discusses the security risks that a NVO3 network may
encounter and tries to provide a list of essential security
requirements that needs to be fulfilled. In addition, this document
introduces the candidate techniques which could be potentially used
to construct a security solution fulfilling the security
requirements.
End System (ES): An end system of a tenant, which can be, e.g., a The remainder of this document is organized as follows. Section 2
virtual machine(VM), a non-virtualized server, or a physical introduces several key terms used in this memo. Section 3 gives a
appliance. A TS is attached to a Network Virtualization Edge(NVE) brief introduction of the NVO3 network architecture. Section 4
node. discusses the attack model of this work. Section 5 lists the scope of
the security considerations of this memo. Section 6 provides a list
of security requirements as well as the associated justifications. In
Section 7, the candidate techniques are introduced. Section 9
discusses additional security considerations.
Network Virtualization Edge (NVE): An NVE implements network 2. Terminology
virtualization functions that allow for L2/L3 tenant separation and
tenant-related control plane activity. An NVE contains one or more
tenant service instances whereby a TS interfaces with its associated
instance. The NVE also provides tunneling overlay functions.
Virtual Network (VN): This is a virtual L2 or L3 domain that belongs This document uses the same terminology as defined in the NVO3
to a tenant. Framework document [RFC7365] and the Hypervisor to NVE Control Plane
Requirements document [I-D.ietf-nvo3-hpvr2nve-cp-req]. The Followings
are the additional terminologies that are used by this document.
Network Virtualization Authority (NVA). A back-end system that is Hypervisor: This memo uses the term "hypervisor" throughout when
responsible for distributing and maintaining the mapping information describing requirements at the Split-NVE scenario where part of the
for the entire overlay system. NVE functionality is off-loaded to a separate device from the
"hypervisor" that contains a VM connected to a VN. In this context,
the term "hypervisor" is meant to cover any device type where part of
the NVE functionality is off-loaded in this fashion, e.g. a Network
Service Appliance, Linux Container.
NVO3 device: In this memo, the devices (e.g., NVE and NVA) work NVO3 device: In this memo, the devices (e.g., NVE and NVA) work
cooperatively to provide NVO3 overlay functionalities are called as cooperatively to provide NVO3 overlay functionalities are referred as
NOV3 devices. NVO3 devices.
3. NVO3 Overlay Architecture 3. NVO3 Overlay Architecture
+--------+ +--------+ +--------+ +--------+
| Tenant +--+ +----| Tenant | | Tenant +--+ +----| Tenant |
| System | | (') | System | | System | | (') | System |
+--------+ | ................. ( ) +--------+ +--------+ | ................. ( ) +--------+
| +---+ +---+ (_) | +---+ +---+ (_)
+--|NVE|---+ +---|NVE|-----+ +--|NVE|---+ +---|NVE|-----+
+---+ | | +---+ +---+ | | +---+
/ . +-----+ . / . +-----+ .
/ . +--| NVA | . / . +--| NVA | .
skipping to change at page 4, line 32 skipping to change at page 4, line 32
+--------+ .....|NVE|......... +--------+ .....|NVE|.........
+---+ +---+
| |
| |
===================== =====================
| | | |
+--------+ +--------+ +--------+ +--------+
| Tenant | | Tenant | | Tenant | | Tenant |
| System | | System | | System | | System |
+--------+ +--------+ +--------+ +--------+
Figure 1 : Generic Reference Model for DC Network Virtualization
Overlays [RFC7365]
Figure 1: Generic Reference Model for DC Network Virtualization This figure illustrates a generic reference model for NVO3 overlay
Overlays [RFC7365] where NVEs provide a logical L2/L3 interconnect for the TSes that
belong to a specific tenant network over a L3 networks. A packet
This figure illustrates a simple nov3 overlay example where NVEs received from a tenant system is encapsulated by the ingress NVE.
provide a logical L2/L3 interconnect for the TSes that belong to a Then encapsulated packet is then sent to the remote NVE through a
specific tenant network over L3 networks. A packet from a tenant proper tunnel. When reaching the egress NVE of the tunnel, the packet
system is encapsulated when they reach the ingress NVE. Then is decapsulated and forwarded to the target tenant system. The
encapsulated packet is then sent to the remote NVE through a proper address mappings and other related information are distributed to the
tunnel. When reaching the egress NVE of the tunnel, the packet is NVEs by a logically centralized Network Virtualization Authority
decapsulated and forwarded to the target tenant system. The address (NVA).
advertisements and tunnel mappings are distributed to the NVEs by a
logically centralized server (i.e., NVA).
4. Threat Model 4. Threat Model
To benefit describing the threats a NVO3 network may have to face, To benefit describing the threats a NVO3 network may have to face,
the attacks considered in this document are classified into three the attacks considered in this document are classified into three
categories: the attacks from compromised NVO3 devices (inside categories: the attacks from compromised NVO3 devices (inside
attacks), the attacks from compromised tenant systems, and the attacks), the attacks from compromised tenant systems, and the
attacks from underlying networks (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 (e.g., a perimeter. In the second type of attack, an attacker (e.g., a
malicious tenant, or an attacker who has compromised a virtual malicious tenant, or an attacker who has compromised a virtual
machine of an innocent tenant) has got certain privileges in changing machine of an innocent tenant) has got certain privileges in changing
the configuration or software of tenant systems and attempts to 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 by performing 1. Analyze the traffic pattern within the network by performing
passive attacks, passive attacks;
2. Disrupt the network connectivity or degrade the network service 2. Disrupt the network connectivity or degrade the network service
quality (e.g., by performing DoS attacks), 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,
1. Interfere with the normal operations of the overlay as a legal 1. Interfere with the normal operations of the overlay as a legal
NVO3 device, by sending packets containing invalid information or NVO3 device, by sending packets containing invalid information or
with improper frequencies, with improper frequencies;
2. Perform spoofing attacks and impersonate another legal NVO3 2. Perform spoofing attacks and impersonate another legal NVO3 device
device to communicate with victims using the cryptographic to communicate with victims using the cryptographic information it
information it obtained, and obtained; and
3. Access the contents of the data/control packets if they are 3. Access the contents of the data/control packets if they are
encrypted with the keys held by the attacker. encrypted with the keys held by the attacker.
4.3. Capabilities of Malicious TSes 4.3. Capabilities of Malicious TSes
It is assumed that the attacker performing attacks from compromised It is assumed that the attacker performing attacks from compromised
TSes is able to intercept packets, delete packets, and/or insert TSes is able to intercept packets, delete packets, and/or insert
bogus packets. In addition, after compromising a TS, an attacker may bogus packets. In addition, after compromising a TS, an attacker may
be able to: be able to:
1. Interfere with the normal operations of the overlay as a legal 1. Interfere with the normal operations of the overlay as a legal
TS, by sending packets containing invalid information or with TS, by sending packets containing invalid information or with
improper frequencies to NVEs, improper frequencies to NVEs;
2. Perform spoofing attacks and impersonate another legal TS or NVE 2. Perform spoofing attacks and impersonate another legal TS or NVE
to communicate with victims (other legal NVEs or TSes) using the to communicate with victims (other legal NVEs or TSes) using the
cryptographic information it obtained, and cryptographic information it obtained; and
3. Access the contents of the data/control packets if they are 3. Access the contents of the data/control packets if they are
encrypted with the keys held by the attacker. encrypted with the keys held by the attacker.
4.4. Security Issues In Scope and Out of Scope 5. Scope
During the specification of security requirements, the following During the specification of security requirements, the following
security issues needs to be considered: security issues needs to be considered:
1. A underlying network connecting NOV3 devices (NVEs and NVAs) is 1. The NVO3 connections may be considered as secured if there is a
relatively secure if it is located within a data center and security solution supported by the underlying network. However
cannot be directly accessed by any tenants or outsiders. such kind security solution normally only can protect the NVO3
However, a NVO3 overlay for virtual data center may scatter network from outsider attacker.
across different geographically distributed sites which are
connected through the public Internet. In this case, outside
attacks may be raised from the underlying network connecting NVO3
devices.
2. During the design of a security solution for a NVO3 network, the 2. During the design of a security solution for a NVO3 network, the
attacks raised from compromised NVEs and hypervisors needs to be attacks raised from compromised NVEs and hypervisors needs to be
considered. considered.
3. It is reasonable to consider the conditions where the network 3. It is reasonable to consider the conditions where the network
connecting TSes and NVEs is accessible to outside attackers. connecting TSes and NVEs is accessible to outside attackers.
The following issues are out of scope of consideration in this The following issues are out of scope of consideration in this
document: document:
1. In this memo it is assumed that security protocols, algorithms, 1. In this memo it is assumed that security protocols, algorithms,
and implementations provide the security properties for which and implementations provide the security properties for which they
they are designed; attacks depending on a failure of this are designed; attacks depending on a failure of this assumption
assumption are out of scope. For instance, an attack caused by a are out of scope. For instance, an attack caused by a weakness in
weakness in a cryptographic algorithm is out of scope, while an a cryptographic algorithm is out of scope, while an attack caused
attack caused by failure to use confidentiality when by failure to use confidentiality when confidentiality is a
confidentiality is a security requirement is in scope. security requirement is in scope.
2. An attacker controlling an underlying network device may break 2. An attacker controlling an underlying network device may break the
the communication of the overlays by discarding or delaying the communication of the overlays by discarding or delaying the
delivery of the packets passing through it. This type of attack delivery of the packets passing through it. The security
is out of scope of this memo. consideration to prevent this type of attack is out of scope of
this memo.
3. NVAs are centralized servers and play a critical role in NVO3 3. NVAs are centralized servers and play a critical role in NVO3
overlays. A NVE will believe in the mapping information obtained overlay network. A NVE will believe in the mapping information
from its NVA. After compromising a NVA, the attacker can obtained from its NVA. After compromising a NVA, the attacker can
distribute bogus mapping information to NVEs under the management distribute bogus mapping information to NVEs under the management
of NVA. This work does not consider how to deal with this of NVA. The security requirements discussed in this document is to
problem. protect a NVA from any security risk. And if a NVA is attacked, it
should be detected. However, this work does not consider how to
deal with the problem after a NVA is compromised.
5. Security Requirements 4. Because this memo only tries to provide the most essential high
level requirements, some important issues in designing concept
security mechanisms are not covered in the requirements. Such
issues include:
5.1. Control/Data Plane of NVO3 Overlay - How to manage keys/credentials during their life periods
In this section, the security requirements associated with the NVE- - How to support algorithm agility
NVA control plane, the NVA-NVA control plane, and the NVE-NVE data
plane are proposed.
5.1.1. NVE-NVA Control Plane - How to provide accountability
In a NVE-NVA control plane, it is assumed that a NVE only exchanges - How to secure the management interfaces
control traffics with its NVA using unicast.
REQ 1: The security solution for NVO3 SHOULD enable two NVO3 devices - Use underlying security protocols versus design integrated
to mutually authenticate each other. security extensions
Entity authentication can protect a network device against 6. Security Requirements
imposter attacks and then reduce the risk of DoS attacks and man-
in-the-middle attacks. In addition, a successful authentication
normally results in the distribution key materials for the
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 6.1. Control Plane of NVO3 Overlay
integrity protection, replay protection, and packet origin
authentication for the control packets.
Unlike entity authentication mentioned in REQ 1, message In this section, the security requirements associated with following
authentication is performed on each incoming packet. Through control plane are described:
message authentication, the NOV3 device receiving a control packet
can verify whether the packet is generated by a legitimate NVO3
device, is not antique, and is not tampered during transportation.
Such protection be deployed when the control packets could be
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 - The NVE-NVA control plane: allows a NVE to obtain information
confidentiality protection for the control packets. about the location and status of other TSs with which it needs to
communicate; to provide updates to the NVA about the attached TSs;
and to report any communication errors. In this case, the term
"NVO3 device" is referring to a NVA or a NVE.
On many occasions, the control packets can be transported in - The NVA-NVA control plane: Multiple NVAs may be deployed in a NVO3
plaintext. However, under the circumstances where some overlay for better scalability and fault tolerance capability. The
information contained within the control packets is considered to NVAs may use unicast and/or multicast to exchange signaling
be sensitive or valuable, the information needs to be encrypted in packets within the control plane. In this case, the term "NVO3
order to prevent outsiders from accessing the sensitive data. when device" is referring to a NVA.
the underlying network is not secure. Note that encryption will
impose additional overhead in processing control packets and make
NVAs more vulnerable to DoS/DDoS attacks.
REQ 4: Before adopting the information within a control packet, a - The NVE-NVE control plane: As specified in [RFC7365], in order to
NOV3 device receiving the packet MUST be able to verify whether obtain reachability information, NVEs may exchange information
the packet comes from one who has the privilege to send that directly between themselves via a control-plane protocol. In this
packet. case, the term "NVO3 device" is referring to a NVE.
When receiving a control packet, besides authentication, - The NVE-Hypervisor control plane: In the Split-NVE scenario, the
authorization needs to be carried out by the receiver to identify NVE and hypervisors may also need to exchange signaling packets
the role that the packet sender acts as in the overlay and then over network in order to facilitate, e.g., VM online detection, VM
assess the sender's privileges. If a compromised NVE tries to migration detection, or auto-provisioning/service discovery as
illegally elevate its privilege (e.g., using its credentials to described in [RFC7365]. In this case, the term "NVO3 device" is
communicate with other NVEs as a NVA, or attempting to access the referring to a Hypervisor or a NVE.
mapping information of the VNs which it is not authorized to
serve), it will be detected and rejected.
REQ 5: The security solution of NVO3 SHOULD be able to provide REQ 1. The security solution for NVO3 MUST enable the two NVO3
distinct keys to protect the unicast control traffics exchanged devices to mutually authenticate each other before exchanging
between a NVA and different NVEs respectively. any control packets.
During the exchange of control packets, keys are critical in Entity authentication can protect a NVO3 device against imposter
authenticating the packet senders. The purpose of this attacks and then reduce the risk of DoS/DDoS attacks and man-in-the-
requirement is to provide a basic capability to confine the damage middle attacks. In addition, a successful authentication normally
caused by inside attacks. After compromising a NVE, an attacker results in the distribution key materials for the security protection
will not be able to use the keys it obtained to breach the for subsequent communications. More detailed discussions are provided
security of the control traffics exchanged between the NVA and in Section 6.1.
other NVEs.
In a NVO3 overlay, NVAs can be the valuable targets of DoS/DDoS REQ 2. The security solution of NVO3 MUST be able to provide
attacks, and large amount of NVEs can be potentially used as integrity protection, replay protection, and packet origin
reflectors in reflection attacks. Therefore, the DoS/DDoS risks authentication for the control packets exchanged between two
needs be considered during designing the control planes for NOV3. NVO3 devices.
The following two requirements are used to benefit the migration of
DoS/DDoS issue.
REQ 6: A NVO3 device MUST send its control packets with limited Message authentication is performed on each incoming packet. Packet
frequencies. level security protection can prevent an attacker from illegally
interfere with the normal operations of NVO3 device by injecting
bogus control packets into the network. Through message
authentication, the NVO3 device receiving a control packet can verify
whether the packet is generated by a legitimate NVO3 device, is not
antique, and is not tampered during transportation.
Without this limitation, an attacker can attempt to perform DDoS Such protection must be deployed if there is any possibility that the
attacks to exhaust the limited computing and memory resources of a control packets could be accessed by outside attackers. This
NVA by manipulating the NVEs attached to the NVA to generate a protection can prevent an attacker locating in the middle between the
significant member of mapping queries in a short period. NVO3 devices and modifying the information in the control packet so
as to redirect the traffic as wished. In addition, with the support
of properly distributed keys, these level protections can also
benefit the detection of spoofing attacks raised from insiders.
REQ 7: The amplification effect SHOULD be avoided REQ 3. The security solution of a NVO3 network SHOULD provide
confidentiality protection for the control packets exchanged
between two NVO3 devices.
If in certain conditions the responses generated by a NVE are much On many occasions, the control packets can be transported in
longer than the received requests, the NVE may be taken advantage plaintext. However, if the information contained within the control
of by an attacker as a reflector to carry out DDoS attacks. packets is considered to be sensitive or valuable, it is recommended
Specifically, the attacker can concurrently send out a large to encrypt the packets in order to prevent outsiders from accessing
amount of spoofed short requests to multiple NVEs with the source the sensitive data, especially when the underlying network is not
address of a victim (e.g., a NVA). The responses generated by the secured enough. Note that encryption will impose additional overhead
NVEs will be forwarded to the victim and overwhelm the victim's in processing control packets and make NVO3 devices more vulnerable
processing capability. to DoS / DDoS attacks.
5.1.2. NVA-NVA Control Plane REQ 4. Node authorization procedure MUST be supported before
processing any received control packets in the NVO3 device
Multiple NVAs may be deployed in a NVO3 overlay for better When receiving a control packet, besides authentication,
scalability and fault tolerance capability. The NVAs may use unicast authorization needs to be carried out by the receiver to identify the
and/or multicast to exchange signaling packets within the control role that the packet sender acts as in the overlay and then assess
plane. the sender's privileges. If a compromised NVO3 device tries to
illegally elevate its privilege, it will be detected and rejected.
For instance, a compromised NVO3 device may use its credentials to
communicate with other NVEs as a NVA, or attempting to access or
update the mapping information of the VNs which it is not authorized
to serve.
Except the key deployment requirement (REQ 5), all the other REQ 5. The security solution of NVO3 SHOULD be able to provide
requirements in the NVE-NVA control plane (REQs 1,2,3,4, 6, and 7) distinct cryptographic keys for each NVO3 device to protect the
are applicable in the NVA-NVA control plane as well. Before two NVA unicast control traffics exchanged between different NVO3
communicate with each other, they should be able to mutually devices respectively.
authenticated. In addition, message authentication can help a NVO3
device to verify the authenticity of the received packets, and the
sensitive information in the control packets need to be encrypted.
Authorization is important to filter the invalid control packets and
any un-privileged requests. Moreover, the approach to mitigating
DoS/DDoS attacks needs to be considered in the control plane
protocols.
The key deployment requirements for the NVA-NVA control plane are During the exchange of control packets, keys are critical in
described as follows: authenticating the packet senders. The purpose of this requirement is
to provide a basic capability to confine the damage caused by inside
attacks. After compromising a NVO3 device, an attacker may be able
to use the keys it obtained to exchange control traffics with other
NVO3 devices. But it will not be able to use the keys it obtained to
breach the security of the control traffics exchanged between other
NVO3 devices.
REQ 8: The security solution of NVO3 SHOULD be able to provide REQ 6. The security solution of NVO3 SHOULD be able to assign
different keys to protect the unicast control traffics exchanged distinct cryptographic group keys for each multicast group to
between different NVO3 devices respectively. protect the multicast packets exchanged among the NVO3 devices
within the group.
The purpose of this requirement is to provide a basic capability In order to provide an essential packet level security protection
to confine the damage caused by compromised key. The compromise specified for integrity and confidentiality, at least one group key
of a key will not affect the traffics protected by other keys. may need to be shared among the NVO3 devices in a same multicast
group. It is recommended to use different keys for different
multicast groups.
REQ 9: If there are multicast packets, the security solution of NVO3 REQ 7. The resistance at DOS/DDOS attack MUST be considered in the
SHOULD be able to assign distinct cryptographic group keys to design of NVO3 control plane
protect the multicast packets exchanged among the NVO3 devices
within different multicast groups.
In order to provide an essential packet level security protection Any NVO3 devices may be used by an attacker to initiate a DOS/DDOS.
specified in REQs 2 and 3, at least a group key may need to be One example is that in a NVO3 overlay, NVAs can be the valuable
shared among the NVEs in a same mutlicast group. It is targets of DoS/DDoS attacks, and large amount of NVEs can be
recommended to use different keys for different mutlicast groups. potentially used as reflectors in reflection attacks. Therefore, the
DoS/DDoS risks needs be considered during designing the control
planes for NVO3. The following requirements, but not limited to this
listed, are used to benefit the migration of DoS/DDoS issue.
5.1.3. NVE-NVE Control Plane REQ 7.a. A NVO3 device MUST have a frequency limitation at
sending its control packets and processing any received
control packets.
As specified in [RFC7365], in order to obtain reachability Without this limitation, an attacker can attempt to perform DoS/DDoS
information, NVEs may exchange information directly between attacks to exhaust the limited computing and memory resources of a
themselves via a control-plane protocol. target NVO3 device by manipulating a compromised NVO3 device to
generate a significant amount of control plane packets in a short
period.
The requirements in the NVA-NVA control plane (REQs 1,2,3,4, 6, 7,8, REQ 7.b. The amplification effect MUST be avoided
and 9) are applicable in the NVE-NVE control plane as well.
5.1.4. NVE-NVE Data Plane A distributed denial-of-service attack may involve sending forged
requests of some type to a very large number of NVO3 devices that
will reply to the requests. If in certain conditions, the responses
generated by a NVO3 device are a much longer process than the
received requests. An attacker may take advantage of this
amplification effect procedure, which the NVO3 device is used as a
reflector to carry out DoS / DDoS attacks towards a victim NVO3
device.
For instance, the attacker may send request messages to a NVO3 device
with a spoofed source address set to the targeted victim. In that
case, all the replies generated by the NVO3 device will be sent (and
flooded) to the target. Another example is that as discussed in [I-
D.ietf-nvo3-arch], a NVE may wish to query the NVA about individual
mapping when receiving a packet with unknown destination address.
This query procedure may also be triggered at ARP / ND message
handling or when NVE-NVE interaction message is received. An attacker
may take advantage of this query procedure which the NVE is used as a
reflector to carry out DoS / DDoS attacks towards the NVA.
Specifically, the attacker can concurrently send out a large amount
of spoofed short request messages to multiple NVO3 devices which the
amplification effect can be enlarged which may overwhelm the victim's
processing capability quickly.
REQ 8. The security solution of a NVO3 SHOULD be able to provide
different security levels of protections for the control
traffics and data traffics exchanged between NVO3 devices.
In NVE-NVE interface and NVE-Hypervisor interface, the same security
solution may be used to protect both the control plane and data plane
traffic. In many cases, the control and data traffics between NVO3
devices may be transported over the same path or even within the same
security channel. However, the control traffics and data traffics may
have different levels of security sensitivity. Therefore, the
protection on the traffic needs be distinguished. In this case, the
security solution may need to provide different security channels for
control traffics and data traffics respectively and protect the data
traffics and control traffics exchanged between NVO3 devices with
different keys and ciphers.
6.2. NVE-NVE Data Plane
As specified in [RFC7365], a NVO3 overlay needs to generate tunnels As specified in [RFC7365], a NVO3 overlay needs to generate tunnels
between NVEs for data packet transportation. When a data packet between NVEs for data packet transportation. When a data packet
reaches the boundary of a overlay, the ingress NVE will encapsulate reaches the boundary of an overlay, the ingress NVE will encapsulate
the packet and forward it to the destination egress NVE through a the packet and forward it to the destination egress NVE through a
proper tunnel. proper tunnel.
REQ 10: The security solution for NVO3 SHOULD enable two NVEs to REQ 9. The security solution for NVO3 MAY 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. 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
guarantee a data tunnel is generated between two proper NVEs and data tunnel is generated between two proper NVEs and reduce the risk
reduce the risk of man-in-the-middle attacks. of man-in-the-middle attacks.
In order to protect the data packets transported over the overlay In order to protect the data packets transported over the overlay
against the attacks raised from the underlying network, the NVO3 against the attacks raised from the underlying network, the NVO3
overlay needs to provide essential security protection for data overlay needs to provide essential security protection for data
packets. packets.
REQ 11: The security solution of NVO3 MUST be able to provide REQ 10. The security solution of NVO3 SHOULD be able to provide
integrity protection, replay protection, and packet origin integrity protection, replay protection, and packet origin
authentication for data traffics exchanged between NVEs. authentication for data traffics exchanged between NVEs.
This requirement is used to prevent an attacker who has
compromised a underlying network devices on the path from
replaying antique packets or injecting bogus data packets without
being detected.
REQ 12: The security solution of NVO3 MAY provide confidentiality
protection for data traffics exchanged between NVEs.
If the data traffics from the TSes are sensitive, they needs to be
encrypted when being transported within the overlay. Otherwise,
encryption will be unnecessary. In addition, in practice, tenants
may also select to encrypt their sensitive data during
transportation. Therefore this confidentiality requirement for
data plane is then not as crucial as the integrity requirement.
REQ 13: The security solution of NVO3 SHOULD be able to assign
different cryptographic keys to protect the unicast tunnels
between NVEs respectively.
This requirement is used to confine the damage caused by inside
attacks. When different tunnels secured with different keys, the
compromise of a key in a tunnel will not affect the security of
others. In addition, if the key used to protect a tunnel is only
shared by the NVEs on the both sides, the egress NVE receiving a
data packet is able to distinctively prove the identity of the
ingress NVE encapsulating the data packet during the message
authentication.
REQ 14: If there are multicast packets, the security solution of
NVO3 SHOULD be able to assign distinct cryptographic group keys to
protect the multicast packets exchanged among the NVEs within
different multicast groups.
In practice, a NVE may need to use the multicast capability
provided by the underlying network to transfer multicast packets
to other NVEs. In this case, in order to provide an essential
packet level security protection specified in requirements 11 and
12, at least a group key may need to be shared among the NVEs in a
same mutlicast group, in order to provide packet level
authentication or optionally confidentiality protection for the
multicast packets transferred within the group. It is recommended
to deploy different keys for different mutlicast groups, in order
to confine the insider attacks on NVEs.
REQ 15: Upon receiving a data packet, an egress NVE must be able to
verify whether the packet is from a proper ingress NVE which is
authorized to forward that packet.
In cooperation with authentication, authorization enables a egress
NVE to detect the data packets which violate certain security
policies, even when they are forwarded from a legal NVE. For
instance, if a data packet belonging to a VN is forwarded from an
ingress NVE which is not supposed to support that VN, the packet
needs to be detected and discarded. Note that the detection of a
invalid packet may not indicate that the system is under a
malicious attack. Mis-configuration or byzantine failure of a NVE
may also result in such invalid packets.
5.2. Control/Data Plane between NVEs and Hypervisors
Apart from data traffics, the NVE and hypervisors may also need to
exchange signaling packets in order to facilitate, e.g., VM online
detection, VM migration detection, or auto-provisioning/service
discovery [RFC7365].
A NVE and the hypervisors working with it can be deployed in a
distributed way (e.g., the NVE is implemented in an individual
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
same server). In the former case, the data and control traffic
between the NVE and the hypervisors are exchanged over network.
5.2.1. Distributed Deployment of NVE and Hypervisor
Five security requirements appliabled for both control and data
packets exchanged between NVEs and hypervisors are listed as follows:
REQ 16: The security solution for NVO3 SHOULD enable the
communicating NVE and hypervisor to mutually authenticate each
other before exchanging any control/ data packets.
Mutual authentication is used to prevent an attacker from
impersonating a legal NVE or a hypervisor without being detected
and then reduce the risks of man-in-the-middle attacks. A
successful authentication normally results in the distribution key
materials to protect the security of subsequent communications.
REQ 17: The security solution of NVO3 MUST be able to provide This requirement is used to prevent an attacker who has compromised
integrity protection, replay protection and origin authentication underlying network devices on the path from replaying antique packets
for the control/ data packets exchanged between a NVE and a or injecting bogus data packets without being detected.
hypervisor.
Packet level security protection can prevent an attacker from Such protection must be deployed if there is any possibility that the
illegally interfere with the normal operations of NVEs and data packets could be accessed by outside attackers. This protection
hypervisors by injecting bogus control packets into the network. can prevent an attacker locating in the middle between the NVEs and
In addition, because it is assumed the network connecting the NVE modifying the tunnel address information in the data packet header so
and the hypervisor is potentially accessible to attackers, as to redirect the data traffic as wished.
security solutions need to prevent an attacker locating in the
middle between the NVE and the hypervisor from modifying the VN
identification information in the packet headers so as to
manipulate the NVE to transport the data packets within a VN to
another.
REQ 18: If a NVE needs to communicate with multiple hypervisors, the REQ 11. The security solution of NVO3 MAY be able to provide
security solution of a NVO3 network SHOULD be able to provide confidentiality protection for data traffics exchanged between
different keys and ciphers to secure the control /data packets NVEs, if information leaking is a concern.
exchanged between different hypervisors and their NVEs
respectively.
This requirement is used to benefit the damage confinement of If TS data traffic privacy is required, the TS data traffic needs to
inside attacks. For instance, the compromise of a hypervisor will be encrypted when being transported within the overlay. In practice,
not affect the security of control/data traffics exchanged between tenants may select end-to-end security solutions to encrypt their
the NVE and other hypervisors. sensitive data during transportation. Therefore this confidentiality
requirement for data plane is an optional requirement.
REQ 19: Before accepting a control/data packet, a NVE or a REQ 12. The security solution of NVO3 SHOULD be able to assign
hypervisor receiving the packet MUST verify that the device different cryptographic keys to protect the unicast tunnels
sending the packet is authorized to do so. between NVEs respectively.
This is an authorization requirement. When receiving a control/ This requirement is used to confine the damage caused by inside
data packet, besides authentication, authorization needs to be attacks. When different tunnels secured with different keys, the
carried out by a NVE or a hypervisor to identify the role that the compromise of a key in a tunnel will not affect the security of other
packet sender acts as and then assess the sender's privileges. tunnels. In addition, if the key used to protect a tunnel is only
Therefore, if a compromised hypervisor attempts to use it shared by the NVEs on the both sides, the egress NVE receiving a data
credentials to impersonate a NVE to communicate with other packet is able to distinctively prove the identity of the ingress NVE
hypervisors, it will be detected. encapsulating the data packet during the message authentication.
REQ 20: The security solution of a NVO3 SHOULD be able to provide REQ 13. If there are multicast packets, the security solution of
different security levels of protections for the control/data NVO3 SHOULD be able to assign distinct cryptographic group keys
traffics exchanged between a NVE or a hypervisor. to protect the multicast packets exchanged among the NVEs within
different multicast groups.
The control and data traffics between a NVE and a hypervisor may In NVO3, a NVE may need to support data plane multicast capability.
be transported over the same path or even within the same security In order to provide an essential packet level security protection
channel. However, when the control traffics and data traffics (including authentication, integrity, confidentiality) for the
have different levels of sensitivity, the protection on them needs multicast packets transferred within the group, at least one group
be different. In this case, the security solution may need to key may need to be shared among the NVEs of the same multicast group.
different security channels for control and data traffics It is recommended to deploy different keys for different multicast
respectively and so protect the data and control traffics groups, in order to confine the insider attacks on NVEs.
exchanged between a hypervisor and a NVE with different keys and
ciphers.
5.2.1.1. Control Plane REQ 14. Upon receiving a data packet, an egress NVE MUST be able
to verify whether the packet is sent from a proper ingress NVE
which is authorized to forward that packet.
REQ 21: The security solution of a NVO3 network MAY provide In cooperation with authentication, authorization enables an egress
confidentiality protection for the control traffics exchanged NVE to detect the data packets which violate certain security
between a NVE and a hypervisor. policies, even when they are forwarded from a legal NVE. For
instance, if the remote NVE is not authorized to forward data packet
of a given VN, the packet needs to be detected and discarded without
processing. Note that the detection of an invalid packet may not
indicate that the system is under a malicious attack. Mis-
configuration or byzantine failure of a NVE may also result in such
invalid packets.
The contents of the control/data packets need to be encrypted when 6.3. NVE-Hypervisor Data Plane
they are considered to be sensitive.
Similar to REQs 6 and 7, the following two requirements are used to As described in the NVO3 architecture draft [I-D.ietf-nvo3-arch], in
mitigate potential DDoS risks. split-NVE scenario, a number of link types are possible between NVE
and hypervisor. One simple deployment scenario may have a simple L2
Ethernet link. A more complicated scenario may have the server and
NVE separated by a bridged access network, such as when the NVE
resides on a ToR, with an embedded switch residing between servers
and the ToR.
REQ 22: The frequency in forwarding control packets from a NVE or a In any of above deployment scenarios, the data link between NVE and
hypervisors MUST be limited. hypervisor may be potentially accessible to attackers, e.g. with a
shared link. In that case, security solutions, including integrity
protection and confidentiality protection, may be needed to secure
the data link.
This is a common security requirement that can effectively avoid REQ 15. The security solution of NVO3 SHOULD be able to provide
the capability of a device in processing control packets to be integrity protection, replay protection and origin
overwhelmed by the high frequent control packets generated by the authentication for the data packets exchanged between a NVE and
devices attached to it. a hypervisor.
REQ 23: Amplification effect SHOULD be Addressed. Packet level security protection can prevent an attacker from
illegally interfere with the normal operations of NVEs and
hypervisors by injecting bogus packets into the network. Because it
is assumed that the network connecting the NVE and the hypervisor is
potentially accessible to attackers, security solutions need to
prevent an attacker locating in the middle between the NVE and the
hypervisor from modifying the information in the data packet headers
so as to redirect the traffic as wished.
If the responses generated by a NVE or a hypervisor are much REQ 16. The security solution of a NVO3 network MAY provide
longer than the received requests, an attacker may take advantage confidentiality protection for the data traffics exchanged
of the device as a reflector to perform DDoS attacks. between a NVE and a hypervisor.
Specifically, the attacker sends a large amount of spoofed short
requests to NVEs or hypervisors with the source address of a
victim. The responses will then be generated by the NVEs and
forwarded to the victim and overwhelm its process capability.
This issues should be considered in the design of the control
protocols.
5.2.1.2. Data Plane If TS data packet privacy is required, the data packet needs to be
encrypted. The security solution of a NVE network may need to provide
confidentiality for the data packets exchanged between a NVE and a
hypervisor if they have to use an insecure network to transport their
data packet.
REQ 24: The security solution of a NVO3 network MUST provide REQ 17. The security solution of a NVO3 network MAY be able to
security gateways to control the data traffics across the provide different cryptographic keys to secure the unicast data
boundaries of different VNs according to specified security traffic exchanged between different hypervisors and their NVEs
policies. respectively.
In [RFC7364], the data plane isolation requirement amongst This requirement is used to benefit the damage confinement of inside
different VNs has been discussed. The traffic within a virtual attacks. For instance, data traffic may be forwarded over a shared
network can only be transited into another one in a controlled link between a NVE and a hypervisor. In that case, the compromise of
fashion (e.g., via a configured router and/or a security gateway). a hypervisor or a NVE will not be able to affect the security of data
traffics exchanged between different hypervisors and their NVEs.
REQ 25: The security solution of a NVO3 network MAY provide REQ 18. The security solution of NVO3 MAY be able to assign
confidentiality protection for the data traffics exchanged between distinct cryptographic group keys to protect the multicast
a NVE and a hypervisor. traffic exchanged between different hypervisors and their NVEs
respectively within different multicast groups.
When the contents of the data packets are sensitive to a tenant, If there are multicast data traffic between hypervisors and their
the data packet needs to be encrypted. The security solution of a NVE, in order to provide an essential packet level security
NVE network may need to provide confidentiality for the data protection (including authentication, integrity, confidentiality) for
packets exchanged between a NVE and a hypervisor if they have to the multicast packets transferred within the multicast group, at
use an insecure network to transport their data packet and the least one group key may need to be shared among the hypervisors and
tenants cannot encrypt their sensitive data themselves. their NVE of the same multicast group. It is recommended to deploy
different keys for different multicast groups, in order to confine
the insider attacks on the hypervisors and their NVE.
6. Candidate Techniques 7. Candidate Techniques
This section introduces the techniques which can potentially be used This section introduces the techniques which can potentially be used
to fulfill the security requirements introduced in Section 5. to fulfill the security requirements introduced in Section 5.
6.1. Entity Authentication 7.1. Entity Authentication
Entity authentication is normally performed as a part of automated Entity authentication is normally performed as a part of automated
key management, and a successful authentication may result in the key key management, and a successful authentication may result in the key
materials used in subsequent communications. materials used in subsequent communications.
In the circumstance where no authentication protocols are applied,
the communicating entities could use message authentication
mechanisms to verify each other's identity.
The widely adopted protocols supporting entity authentication The widely adopted protocols supporting entity authentication
include: IKE[RFC2409], IKEv2[RFC4306], EAP[RFC4137], TLS [RFC5246] include: IKE [RFC2409], IKEv2 [RFC4306], EAP [RFC4137], TLS [RFC5246]
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 7.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 confidentiality, and provide packet origin authentication for
control/ data packets. Such functions can be provided through using control/ data packets. Such functions can be provided through using
the 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], or MACsec [802.1AE]. Also, when
protocols people can select to provide embedded security approaches designing the control protocols people can select to provide embedded
(just like the packet level security mechanism provided in security approaches (just like the packet level security mechanism
OSPFv2[RFC2328]). The cryptographic keys can be manually deployed or provided in OSPFv2 [RFC2328]). The cryptographic keys can be manually
dynamically generated by using certain automatic key management deployed or dynamically generated by using certain automatic key
protocols. Note that when using manual key management, the replay management protocols. Note that when using manual key management, the
protection mechanism of IPsec will be switched off. replay protection mechanism of IPsec will be switched off.
6.3. Authorization 7.3. Authorization
Without any cryptographic supports, the authorization mechanisms Without any cryptographic supports, the authorization mechanisms
(e.g., packet filters) could be much easier to be bypassed by (e.g., packet filters) could be much easier to be bypassed by
attackers, and thus the authorization mechanisms deployed on NOV3 attackers, and thus the authorization mechanisms deployed on NVO3
devices should interoperate with entity authentication and other devices should interoperate with entity authentication and other
packet level security mechanisms, and be able to make the access packet level security mechanisms, and be able to make the access
control decisions based on the cryptographically proved results. An control decisions based on the cryptographically proved results.
exception is packet filtering. Because packet filters are efficient
and can effectively drop some un-authorized packets before they have
to be cryptographically verified, it is worthwhile to use packet
filters as an auxiliary approach to dealing with some simple attacks
and increasing the difficulties of DoS/DDoS attacks targeting at the
security protocol implementations.
7. IANA Considerations An exception is packet filtering. Because packet filters are
efficient and can effectively drop some un-authorized packets before
they have to be cryptographically verified, it is worthwhile to use
packet filters as an auxiliary approach to dealing with some simple
attacks and increasing the difficulties of DoS/DDoS attacks
targeting at the security protocol implementations.
For instance, a NVE may maintain an authorization NVE table. This
table may be distributed by a trusted entity, e.g. NVA, in
combination with the inner-outer address mapping table. And NVE may
use this table to filter the received control / data packets over
NVE-NVE interface. The NVE may effectively drop any packets received
from an unauthorized NVE before processing it, e.g.
cryptographically verification procedure.
8. IANA Considerations
This document makes no request of IANA. This document makes no request of IANA.
Note to RFC Editor: this section may be removed on publication as an Note to RFC Editor: this section may be removed on publication as an
RFC. RFC.
8. Security Considerations 9. Security Considerations
8.1. Automated Key Management in NVO3 9.1. Automated Key Management in NVO3
Because entity authentication and automated key distribution are Because entity authentication and automated key distribution are
normally performed in the same process, the requirements of entity normally performed in the same process, the requirements of entity
authentication have already implied that it is recommended to use authentication have already implied that it is recommended to use
automated key management in the security solutions for NVO3 networks. automated key management in the security solutions for NVO3 networks.
In the cases where there are a large amount of NVEs working within a In the cases where there are a large amount of NVEs working within a
NVO3 overlay, manual key management becomes infeasible. First, it NVO3 overlay, manual key management becomes infeasible. First, it
could be tedious to deploy pre-shared keys for thousands of NVEs, not could be tedious to deploy pre-shared keys for thousands of NVEs, not
to mention that multiple keys may need to be deployed on a single to mention that multiple keys may need to be deployed on a single
device for different purposes. Key derivation can be used to device for different purposes. Key derivation can be used to mitigate
mitigate this problem. Using key derivation functions, multiple keys this problem. Using key derivation functions, multiple keys for
for different usages can be derived from a pre-shared master key. different usages can be derived from a pre-shared master key.
However, key derivation cannot protect against the situation where a However, key derivation cannot protect against the situation where a
system was incorrectly trusted to have the key used to perform the system was incorrectly trusted to have the key used to perform the
derivation. If the master key were somehow compromised, all the derivation. If the master key were somehow compromised, all the
resulting keys would need to be changed [RFC4301]. Moreover, some resulting keys would need to be changed [RFC4301]. Moreover, some
security protocols need the support of automated key management in security protocols need the support of automated key management in
order to perform certain security functions properly. As mentioned order to perform certain security functions properly. As mentioned
above, the replay protecting mechanism of IPsec will be turned off above, the replay protecting mechanism of IPsec will be turned off
without the support of automated key management mechanisms. without the support of automated key management mechanisms.
8.2. Issues not Discussed 10. Acknowledgements
Because this memo only tries to provide the most essential high level
requirements, some important issues in designing concret security
mechanisms are not covered in the requirements. Such issues include:
o How to manage keys/credentials during their life periods
o How to support algorithm agility
o How to provide accountability
o How to secure the management interfaces
o Use underlying security protocols versus design integrated Many people have contributed to the development of this document and
security extensions many more will probably do so before we are done with it. While we
cannot thank all contributors, some have played an especially
prominent role. The followings have provided essential input:
Melinda Shore and Makan Pourzandi.
9. Acknowledgements 11. References
Thanks a lot for the comments from Melinda Shore and Zu Qiang. 11.1. Normative References
10. References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
10.1. Normative References 11.2. Informative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [I-D.ietf-nvo3-arch] Black, D., Narten, T., et al, "An Architecture
Requirement Levels", BCP 14, RFC 2119, March 1997. for Overlay Networks (NVO3)", draft-narten-nvo3-arch, work
in progress.
10.2. Informative References [I-D.ietf-ipsecme-ad-vpn-problem] Manral, V. and S. Hanna, "Auto
Discovery VPN Problem Statement and Requirements", draft-
ietf-ipsecme-ad-vpn-problem-09 (work in progress), July
2013.
[I-D.ietf-ipsecme-ad-vpn-problem] [I-D.ietf-nvo3-hpvr2nve-cp-req] Yizhou, L., Yong, L., Kreeger, L.,
Manral, V. and S. Hanna, "Auto Discovery VPN Problem Narten, T., and D. Black, "Hypervisor to NVE Control Plane
Statement and Requirements", draft-ietf-ipsecme-ad-vpn- Requirements", draft-ietf-nvo3-hpvr2nve-cp-req-01 (work in
problem-09 (work in progress), July 2013. progress), November 2014.
[I-D.ietf-nvo3-hpvr2nve-cp-req] [I-D.mahalingam-dutt-dcops-vxlan] Mahalingam, M., Dutt, D., Duda, K.,
Yizhou, L., Yong, L., Kreeger, L., Narten, T., and D. Agarwal, P., Kreeger, L., Sridhar, T., Bursell, M., and C.
Black, "Hypervisor to NVE Control Plane Requirements", Wright, "VXLAN: A Framework for Overlaying Virtualized
draft-ietf-nvo3-hpvr2nve-cp-req-00 (work in progress), Layer 2 Networks over Layer 3 Networks", draft-mahalingam-
July 2014. dutt-dcops-vxlan-09, (work in progress), April 2014.
[I-D.mahalingam-dutt-dcops-vxlan] [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
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-09
(work in progress), April 2014.
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange
(IKE)", RFC 2409, November 1998.
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange [RFC4046] Baugher, M., Canetti, R., Dondeti, L., and F. Lindholm,
(IKE)", RFC 2409, November 1998. "Multicast Security (MSEC) Group Key Management
Architecture", RFC 4046, April 2005.
[RFC4046] Baugher, M., Canetti, R., Dondeti, L., and F. Lindholm, [RFC4137] Vollbrecht, J., Eronen, P., Petroni, N., and Y. Ohba,
"Multicast Security (MSEC) Group Key Management "State Machines for Extensible Authentication Protocol
Architecture", RFC 4046, April 2005. (EAP) Peer and Authenticator", RFC 4137, August 2005.
[RFC4137] Vollbrecht, J., Eronen, P., Petroni, N., and Y. Ohba, [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
"State Machines for Extensible Authentication Protocol Internet Protocol", RFC 4301, December 2005.
(EAP) Peer and Authenticator", RFC 4137, August 2005.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December
Internet Protocol", RFC 4301, December 2005. 2005.
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC
2005. 4303, December 2005.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC
4303, December 2005. 4306, December 2005.
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
4306, December 2005. (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, "Internet
(TLS) Protocol Version 1.2", RFC 5246, August 2008. Key Exchange Protocol Version 2 (IKEv2)", RFC 5996,
September 2010.
[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, [RFC7364] Narten, T., Gray, E., Black, D., Fang, L., Kreeger, L., and
"Internet Key Exchange Protocol Version 2 (IKEv2)", RFC M. Napierala, "Problem Statement: Overlays for Network
5996, September 2010. Virtualization", RFC 7364, October 2014.
[RFC7364] Narten, T., Gray, E., Black, D., Fang, L., Kreeger, L., [RFC7365] Lasserre, M., Balus, F., Morin, T., Bitar, N., and Y.
and M. Napierala, "Problem Statement: Overlays for Network Rekhter, "Framework for Data Center (DC) Network
Virtualization", RFC 7364, October 2014. Virtualization", RFC 7365, October 2014.
[RFC7365] Lasserre, M., Balus, F., Morin, T., Bitar, N., and Y. [802.1AE] 802.1AE - Media Access Control (MAC) Security
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
Dacheng Zhang Dacheng Zhang
Huawei Alibaba
Beijing Chaoyang Dist. Beijing
China
Email: zhangdacheng@huawei.com P.R. China
Email: Dacheng.zdc@alibaba-inc.com
Margaret Wasserman Margaret Wasserman
Painless Security Painless Security
356 Abbott Street 356 Abbott Street
North Andover, MA 01845 North Andover, MA 01845
USA USA
Phone: +1 781 405 7464 Phone: +1 781 405 7464
Email: mrw@painless-security.com Email: mrw@painless-security.com
URI: http://www.painless-security.com URI: http://www.painless-security.com
Zu Qiang
Ericsson
8400 Decarie Blvd.
Town of Mount Royal, QC, H4P 2N2
Canada
Phone: +1 514 345 7900 x47370
Email: Zu.Qiang@ericsson.com
Mingui Zhang
Huawei Technologies
No. 156 Beiqing Rd. Haidian District,
Beijing 100095
P.R. China
Email: zhangmingui@huawei.com
 End of changes. 148 change blocks. 
581 lines changed or deleted 540 lines changed or added

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