draft-ietf-nvo3-security-requirements-01.txt   draft-ietf-nvo3-security-requirements-02.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: April 25, 2014 Huawei Expires: July 28, 2014 Huawei
M. Wasserman M. Wasserman
Painless Security Painless Security
October 22, 2013 January 24, 2014
Security Requirements of NVO3 Security Requirements of NVO3
draft-ietf-nvo3-security-requirements-01 draft-ietf-nvo3-security-requirements-02
Abstract Abstract
The draft provides a list of security requirements to benefit the The draft describes a list of essential requirements in order to
design of NOV3 security mechanisms. In addition, this draft benefit the design of NOV3 security solutions. In addition, this
introduces the candidate techniques which could be used to fulfill draft introduces the candidate techniques which could be used to
such 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
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 April 25, 2014. This Internet-Draft will expire on July 28, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 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
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 . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. NVO3 Overlay Architecture . . . . . . . . . . . . . . . . . . 3 3. NVO3 Overlay Architecture . . . . . . . . . . . . . . . . . . 4
4. Threat Model . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Threat Model . . . . . . . . . . . . . . . . . . . . . . . . 4
4.1. Outsider Capabilities . . . . . . . . . . . . . . . . . . 4 4.1. Capabilities of Outsiders . . . . . . . . . . . . . . . . 5
4.2. Insider Capabilities . . . . . . . . . . . . . . . . . . 5 4.2. Capabilities of Insiders . . . . . . . . . . . . . . . . 5
4.3. Security Issues In Scope and Out of Scope . . . . . . . . 5 4.3. Capabilities of Malicious TSes . . . . . . . . . . . . . 5
5. Security Requirements and Candidate Approaches . . . . . . . 6 4.4. Security Issues In Scope and Out of Scope . . . . . . . . 6
5.1. Control/Data Traffic within Overlay . . . . . . . . . . . 6 5. Security Requirements . . . . . . . . . . . . . . . . . . . . 7
5.1.1. Control Plane Security . . . . . . . . . . . . . . . 6 5.1. Control/Data Plane of NVO3 Overlay . . . . . . . . . . . 7
5.1.2. Data Plane . . . . . . . . . . . . . . . . . . . . . 9 5.1.1. NVE-NVA Control Plane . . . . . . . . . . . . . . . . 7
5.2. Control/Data Traffic between NVEs and Hypervisors . . . . 10 5.1.2. NVA-NVA Control Plane . . . . . . . . . . . . . . . . 9
5.2.1. Distributed Deployment of NVE and Hypervisor . . . . 11 5.1.3. NVE-NVE Data Plane . . . . . . . . . . . . . . . . . 10
5.3. Key Management . . . . . . . . . . . . . . . . . . . . . 13 5.2. Control/Data Plane between NVEs and Hypervisors . . . . . 11
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 5.2.1. Distributed Deployment of NVE and Hypervisor . . . . 12
7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 6. Candidate Techniques . . . . . . . . . . . . . . . . . . . . 14
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 6.1. Entity Authentication . . . . . . . . . . . . . . . . . . 14
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 6.2. Packet Level Security . . . . . . . . . . . . . . . . . . 15
9.1. Normative References . . . . . . . . . . . . . . . . . . 15 6.3. Authorization . . . . . . . . . . . . . . . . . . . . . . 15
9.2. Informative References . . . . . . . . . . . . . . . . . 15 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15
8.1. Automated Key Management in NVO3 . . . . . . . . . . . . 15
8.2. Issues not Discussed . . . . . . . . . . . . . . . . . . 16
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
10.1. Normative References . . . . . . . . . . . . . . . . . . 16
10.2. Informative References . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction 1. Introduction
Security is a key issue which needs to be considered in the design of Security is a key issue which needs to be considered during the
a data center network. This document discusses the security risks design of a data center network. This document discusses the
that a NVO3 network may encounter and the security requirements that security risks that a NVO3 network may encounter and tries to provide
a NVO3 network needs to fulfill. In addition, this draft attempts to a list of essential security requirements that a NVO3 network needs
discuss the security techniques which could be applied to fulfill to fulfill. In addition, this draft introduces the candidate
such requirements. 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 The remainder of this document is organized as follows. Section 2
introduces the terms used in this memo. Section 3 gives a briefly introduces several key terms used in this memo. Section 3 gives a
introduction of the NVO3 network architecture. Section 4 discusses brief introduction of the NVO3 network architecture. Section 4
the attack model of this work. Section 5 describes the essential discusses the attack model of this work. Section 5 provides a list
security requirements which should be fulfilled in the generation of of security requirements as well as the associated justifications.
a NVO3 network. 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 [I-D.ietf-nvo3-framework] and
[I-D.kreeger-nvo3-hypervisor-nve-cp]. Some of the terms defined in [I-D.kreeger-nvo3-hypervisor-nve-cp]. Some of the terms defined in
the framework document have been repeated in this section for the the framework document have been repeated in this section for the
convenience of the reader, along with additional terminology that is convenience of the reader, along with additional terminology that is
used by this document. used by this document.
skipping to change at page 3, line 42 skipping to change at page 3, line 44
virtualization functions that allow for L2/L3 tenant separation and virtualization functions that allow for L2/L3 tenant separation and
tenant-related control plane activity. An NVE contains one or more tenant-related control plane activity. An NVE contains one or more
tenant service instances whereby a TS interfaces with its associated tenant service instances whereby a TS interfaces with its associated
instance. The NVE also provides tunneling overlay functions. instance. The NVE also provides tunneling overlay functions.
Virtual Network (VN): This is a virtual L2 or L3 domain that belongs Virtual Network (VN): This is a virtual L2 or L3 domain that belongs
to a tenant. to a tenant.
Network Virtualization Authority (NVA). A back-end system that is Network Virtualization Authority (NVA). A back-end system that is
responsible for distributing and maintaining the mapping information responsible for distributing and maintaining the mapping information
for the entire overlay system. Note that the WG never reached for the entire overlay system.
consensus on what to call this architectural entity within the
overlay system, so this term is subject to change.
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 called as
NOV3 devices. NOV3 devices.
3. NVO3 Overlay Architecture 3. NVO3 Overlay Architecture
..................................
. . +--------+ +--------+
. . | Tenant +--+ +----| Tenant |
. . | System | | (') | System |
+-+--+ +--+-++--------+ +--------+ | ................. ( ) +--------+
+--------+ | NV | | NV || Tenant | | +---+ +---+ (_)
| Tenant +------+Edge| L3 Overlay |Edge|| System | +--|NVE|---+ +---|NVE|-----+
| System | +-+--+ Network +--+-++--------+ +---+ | | +---+
+--------+ . . / . +-----+ .
. . / . +--| NVA | .
. . / . | +-----+ .
.................................. | . | .
| . | L3 Overlay +--+--++--------+
+--------+ | . | Network | NVE || Tenant |
| Tenant +--+ . | | || System |
| System | . \ +---+ +--+--++--------+
+--------+ .....|NVE|.........
+---+
|
|
=====================
| |
+--------+ +--------+
| Tenant | | Tenant |
| System | | System |
+--------+ +--------+
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 egress 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 ingress NVE, the packet is decapsulated tunnel. When reaching the egress NVE of the tunnel, the packet is
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 among the NVEs advertisements and tunnel mappings are distributed to the NVEs by a
through either distributed control protocols or by certain logically centralized server (i.e., NVA).
centralized servers (called NVAs).
4. Threat Model 4. Threat Model
To benefit the discussion, in this analysis work, attacks are To benefit describing the threats a NVO3 network may have to face, in
classified into two categories: inside attacks and outside attacks. this work, attacks are classified into three categories: the attacks
An attack is considered as an inside attack if the adversary from compromised NVO3 devices (inside attacks), the attacks from
performing the attack (inside attacker or insider) has got certain compromised tenant systems, and the attacks from underlying networks
privileges in changing the configuration or software of a NVO3 device (outside attacks).
and initiates the attack within the overlay security perimeter. In
contrast, an attack is referred to as an outside attack if the
adversary performing the attack (outside attacker or outsider) has no
such privilege and can only initiate the attacks from compromised
TSes (or the network devices of the underlying network which the
overlay is located upon). Note that in a complex attack inside and
outside attacking operations may be performed in a well organized way
to expand the damages caused by the attack.
4.1. Outsider Capabilities
The following capabilities of outside attackers MUST be considered in
the design of a NOV3 security mechanism:
1. Eavesdropping on the packets, The adversaries performing the first type of attack are called as
2. Replaying the intercepted packets, and insiders or inside attackers because they need to get certain
privileges in changing the configuration or software of NVO3 devices
beforehand and initiate the attacks within the overlay security
perimeter. In the second type of attack, an attacker has got certain
privileges in changing the configuration or software of tenant
systems (e.g., hypervisors or virtual machines) and attempts to
manipulate the controlled tenant systems to interfere with the normal
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
privilege on the NVO3 devices or tenant systems in advance in order
to perform this type attack, and thus the adversaries performing
outside attacks are called as outside attackers or outsiders.
3. Generating illegal packets and injecting them into the network. 4.1. Capabilities of Outsiders
With a successful outside attack, an attacker may be able to: In practice, an outside attacker may perform attacks by intercepting
packets, deleting packets, and/or inserting bogus packets. With a
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,
2. Disrupt the network connectivity or degrade the network service 2. Disrupt the network connectivity or degrade the network service
quality, or quality, or
3. Access the contents of the data/control packets if they are not 3. Access the contents of the data/control packets which are not
properly encrypted. properly encrypted.
4.2. Insider Capabilities 4.2. Capabilities of Insiders
It is assumed that an inside attacker can perform any types of Besides intercepting packets, deleting packets, and/or inserting
outside attacks from the inside or outside of the overlay perimeter. bogus packets, an inside attacker may use already obtained privilege
In addition, in an inside attack, an attacker may use already to,
obtained privilege to, for instance,
1. Interfere with the normal operations of the overlay as a legal 1. Interfere with the normal operations of the overlay as a legal
entity, by sending packets containing invalid information or with NVO3 device, by sending packets containing invalid information or
improper frequencies, with improper frequencies,
2. Perform spoofing attacks and impersonate another legal device to 2. Perform spoofing attacks and impersonate another legal NVO3
communicate with victims using the cryptographic information it device to communicate with victims using the cryptographic
obtained, and 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.3. Security Issues In Scope and Out of Scope 4.3. Capabilities of Malicious TSes
It is assumed that the attacker performing attacks from compromised
TSes is able to intercept packets, delete packets, and/or insert
bogus packets. In addition, after compromising a TS, an attacker may
be able to:
1. Interfere with the normal operations of the overlay as a legal
TS, by sending packets containing invalid information or with
improper frequencies to NVEs,
2. Perform spoofing attacks and impersonate another legal TS or NVE
to communicate with victims (other legal NVEs or TSes) using the
cryptographic information it obtained, and
3. Access the contents of the data/control packets if they are
encrypted with the keys held by the attacker.
4.4. Security Issues In Scope and Out of 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. Insecure underlying network. It is normally assumed that a 1. A underlying network connecting NOV3 devices (NVEs and NVAs) is
underlying network connecting NOV3 devices (NVEs and NVAs) is relatively secure if it is located within a data center and
secure if it is located within a data center and cannot be cannot be directly accessed by any tenants or outsiders.
directly accessed by tenants. However, in a virtual data center However, a NVO3 overlay for virtual data center may scatter
scenario, a NVO3 overlay scatters across different sites which across different geographically distributed sites which are
are connected through the public network. Outside attacks may be connected through the public Internet. In this case, outside
raised from the underlying network. attacks may be raised from the underlying network connecting NVO3
devices.
2. Insider attacker. During the design of a security solution for a 2. During the design of a security solution for a NVO3 network, the
NVO3 network, the inside attacks raised from compromised NVO3 attacks raised from compromised NVEs and hypervisors needs to be
devices (NVEs and NVAs) needs to be considered. considered.
3. Insecure tenant network. It is reasonable to consider the 3. It is reasonable to consider the conditions where the network
conditions where the network connecting TSes and NVEs is connecting TSes and NVEs is accessible to outside attackers.
accessible to outside attackers.
The following issues are out of scope of cosideration 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 are designed; attacks depending on a failure of this they are designed; attacks depending on a failure of this
assumption are out of scope. As an example, an attack caused by assumption are out of scope. For instance, an attack caused by a
a weakness in a cryptographic algorithm is out of scope, while an weakness in a cryptographic algorithm is out of scope, while an
attack caused by failure to use confidentiality when attack caused by failure to use confidentiality when
confidentiality is a security requirement is in scope. confidentiality is a security requirement is in scope.
2. In practice an attacker controlling an underlying network device 2. An attacker controlling an underlying network device may break
may break the communication of the overlays by discarding or the communication of the overlays by discarding or delaying the
delaying the delivery of the packets passing through it. delivery of the packets passing through it. This type of attack
However, this type of attack is out of scope. is out of scope of this memo.
5. Security Requirements and Candidate Approaches
This section introduces the security requirements and candidate
solutions.
5.1. Control/Data Traffic within Overlay 3. NVAs are centralized servers and play a critical role in NVO3
overlays. A NVE will believe in the mapping information obtained
from its NVA. After compromising a NVA, the attacker can
distribute bogus mapping information to NVEs under the management
of NVA. This work does not consider how to deal with this
problem.
This section analyzes the security issues in the control and data 5. Security Requirements
plans of a NVO3 overlay.
5.1.1. Control Plane Security 5.1. Control/Data Plane of NVO3 Overlay
REQ1: A NVO3 security solution MUST enable two NOV3 devices (NVE or In this section, the security requirements associated with the NVE-
NVA) to perform mutual authentication before exchanging control NVA control plane, the NVA-NVA control plane, and the NVE-NVE data
packets. plane are proposed.
This requirement is used to prevent an attacker from impersonating 5.1.1. NVE-NVA Control Plane
a legal NVO3 device and sending out bogus control packets without
being detected.
The authentication between devices can be performed as a part of In a NVE-NVA control plane, it is assumed that a NVE only exchanges
automated key management protocols (e.g., IKEv2[RFC5996], control traffics with its NVA using unicast.
EAP[RFC4137], etc.). After such an authentication procedure, an
device can find out whether its peer holds valid security
credentials and is the one who it has claimed. Additionally, the
keys shared between the devices can be also used for the
authentication purpose. For instance, assumed a NVE and a NVA
have shared a secret key without known by any other third parties.
The NVE can ensure that a device that it is communicating with is REQ 1: The security solution for NVO3 SHOULD enable two NVO3 devices
the NVA if the device can prove that it possesses the shared key. to mutually authenticate each other before they exchange any
control packets.
a: The identity of the network devices SHOULD be verified during Entity authentication can protect a network device against
authentication. 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.
In some authentication mechanisms, instead of verifying the peers' REQ 2: The security solution of NVO3 MUST be able to provide
identities, the authentication result can only prove that a device integrity protection, replay protection, and packet origin
joining the authentication is a legal member of a group. However, authentication for the control packets.
for a better damage confining capability to insider attacker, it
is recommended to verify the devices' identities during
authentication. Therefore, an insider attacker cannot impersonate
others, even when it holds legal credentials or keys.
REQ2: Before accepting a control packet, the device receiving the Unlike entity authentication, message authentication is performed
packet MUST verify whether the packet comes from one which has the on each incoming packet. Through message authentication, the NOV3
privilege to send that packet. 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. In addition, with the support of
properly distributed keys, the packet level protection can also
benefit the detection of spoofing attacks raised from insiders.
This is an authorization requirement. A device needs to clarify REQ 3: The security solution of a NVO3 network MAY provide
the roles (e.g., a NVE or a NVA) that its authentication peer acts confidentiality protection for the control packets.
as in the overlay. Therefore, if a compromised NVE uses it
credentials to impersonate a NVA to communicate with other NVEs,
it will be detected. In addition, authorization is important for
enforcing the VN isolation, a device only can distribute control
packets within the VNs it is involved within. If a control packet
about a VN is sent from a NVE which is not authorized to support
the VN, the packet will not be accepted
Normally, it is assumed that the access control operations are On many occasions, the control packets can be transported in
based on the authentication results. The simple authorization plaintext. However, under the circumstances where some
mechanisms (such as ACLs which filters packets based on the packet information contained within the control packets is considered to
addresses) can be used as auxiliary approaches since they are be sensitive or valuable, the information needs to be encrypted
relatively easy to bypass if attackers can access to the network especially when the underlying network is not secure. Note that
and modify packets. encryption will impose additional overhead in processing control
packets and make NVAs more vulnerable to DoS/DDoS attacks.
REQ3: Integrity, confidentiality, and origin Authentication REQ 4: Before accepting a control packet, a NOV3 device receiving
protection for Control traffics the packet MUST be able to verify whether the packet comes from
one who has the privilege to send that packet.
It is the responsibility of a NVO3 overlay to protect the control When receiving a control packet, besides authentication,
packets transported over the overlay against the attacks raised authorization needs to be carried out by the receiver to identify
from the underlying network. the role that the packet sender acts as in the overlay and then
assess the sender's privileges. If a compromised NVE tries to
illegally elevate its privilege (e.g., using its credentials to
communicate with other NVEs as a NVA, or attempting to access the
mapping information of the VNs which it is not authorized to
serve), it will be detected and rejected.
a: The integrity and origin authentication of the packets MUST be REQ 5: The security solution of NVO3 SHOULD be able to provide
guaranteed. distinct keys to protect the control traffics exchanged between a
NVA and different NVEs respectively.
With this requirement, the receiver can ensure that the packets During the exchange of control packets, keys are critical in
are from the legitimate sender, not replayed, and not modified authenticating the packet senders. The purpose of this
during the transportation. requirement is to provide a basic capability to confine the damage
caused by inside attacks. After compromising a NVE, an attacker
will not be able to use the keys it obtained to breach the
security of the control traffics exchanged between the NVA and
other NVEs.
b: The signaling packets SHOULD be encrypted. In a NVO3 overlay, NVAs can be the valuable targets of DoS/DDoS
attacks, and large amount of NVEs can be potentially used as
reflectors in reflection attacks. Therefore, the DoS/DDoS risks
needs be considered during designing the control planes for NOV3.
The following two requirements are used to benefit the migration of
DoS/DDoS issue.
On many occasions, the signaling packets can be transported in REQ 6: A NVO3 device MUST send its control packets with limited
plaintext. However, In the cases where the information contained frequencies.
within the signaling packets are sensitive or valuable to
attackers , the signaling packets related with that tenant need be
encrypted.
To achieve such objectives, when the network devices exchange Without this limitation, an attacker can attempt to perform DDoS
control plane packets, integrated security mechanisms or attacks to exhaust the limited computing and memory resources of a
underlying security protocols need to provided. In addition, NVA by manipulating the NVEs attached to the NVA to generate a
cryptographic keys need to be deployed manually in advance or significant member of mapping queries in a short period.
dynamically generated by using certain automatic key management
protocols (e.g., TLS [RFC5246]). The keys are used to generate
digests for or encrypt control packets.
REQ4: The toleration of DOS attacks REQ 7: The amplification effect SHOULD be avoided
a: Frequency in distributing control packets within in the overlay If in certain conditions the responses generated by a NVE are much
MUST be limited. longer than the received requests, the NVE may be taken advantage
of by an attacker as a reflector to carry out DDoS attacks.
Specifically, the attacker can concurrently send out a large
amount of spoofed short requests to multiple NVEs with the source
address of a victim (e.g., a NVA). The responses generated by the
NVEs will be forwarded to the victim and overwhelm the victim's
processing capability.
The issues within DOS attacks also need to be considered in 5.1.2. NVA-NVA Control Plane
designing the overlay control plane. For instance, in the VXLAN
solution[I-D.mahalingam-dutt-dcops-vxlan], an attacker attached to
a NVE can try to manipulate the NVE to keep multicasting control
packets by sending a large amount of ARP packets to query the
inexistent VMs. In order to mitigate this type of attack, the
NVEs SHOULD be only allowed to send signaling packet in the
overlay with a limited frequency. When there are centralized
servers (e.g., the backend oracles providing mapping information
for NVEs[I-D.ietf-nvo3-overlay-problem-statement], or the SDN
controllers) are located within the overlay, the potential
security risks caused by DDOS attack on such servers can be more
serious.
b: Mitigation of amplification attacks SHOULD be provided. Multiple NVAs may be deployed in a NVO3 overlay for better
scalability and fault tolerance capability. The NVAs may use unicast
and/or multicast to exchange signaling packets within the control
plane.
During the design of the control plane, it is important to Except the key deployment requirement (REQ 5), all the other
consider the amplification effects. For instance, if NVEs may requirements in the NVE-NVA control plane (REQs 1,2,3,4, 6, and 7)
generate a large response to a short request, an attacker may send are applicable in the NVA-NVA control plane as well. Before two NVA
spoofed requests to the NVEs with the source address of a victim. communicate with each other, they should be able to mutually
Then the NVEs will send the response to the victim and result in authenticated. In addition, message authentication can help a NVO3
DDOS attacks. 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-priviledged requests. Moreover, the approach to mitigating
DoS/DDoS attacks needs to be considered in the control plane
protocols.
If the amplification effect cannot be avoided in the control The key deployment requirements for the NVA-NVA control plane are
protocol, the requirements 1,2,3, and 4a can all be used to described as follows:
benefit the mitigation of this type of attacks.
REQ5: The key management solution MUST be able to confine the scope REQ 8: The security solution of NVO3 SHOULD be able to provide
of key distribution and provide different keys to isolate the different keys to protect the unicast control traffics exchanged
control traffic according to different security requirements. between different NVAs respectively.
a: It SHOULD be guaranteed that different keys are used to secure The purpose of this requirement is to provide a basic capability
the control packets exchanged within different tenant networks. to confine the damage caused by compromised key. The compromise
of a key will not affect the traffics protected by other keys.
This requirement can be used to provide a basic attack confinement REQ 9: If there are multicast packets, the security solution of NVO3
capability. The compromise of a NVE working within a tenant will SHOULD be able to assign distinct cryptographic group keys to
not result in the key leakage of other tenant networks. protect the multicast packets exchanged among the NVAs within
different multicast groups.
b: It SHOULD be guaranteed that different keys are used to secure In order to provide an essential packet level security protection
the control packets exchanges with different VNs. 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
recommended to user different keys for different mutlicast groups.
This requirement can be used to provide a better attack 5.1.3. NVE-NVE Data Plane
confinement capability for the control plane. The compromise of a
NVE working within a VN will not result in the key leakage of
other VNs. However, since there is only a single key used for
securing the data traffic within a VN, an attacker which has
compromised a NVE within the VN may be able to impersonate any
other NVEs within the VN to send out bogus control packets. In
addition, the key management overheads introduced by key
revocation also need to be considered[RFC4046]. When a NVE stops
severing a VN, the key used for the VN needs to be revoked, and a
new key needs to be distributed for the NVO3 devices still within
the VN.
If we expect to provide a even stronger confinement capability and As specified in [I-D.ietf-nvo3-framework], a NVO3 overlay needs to
prevent a compromised NVE from impersonating other NVEs even when generate tunnels between NVEs for data packet transportation. When a
they are in the same VN, different NVEs working inside a VN need data packet reaches the boundary of a overlay, the ingress NVE will
to secure their signaling packets with different keys. encapsulate the packet and forward it to the destination egress NVE
through a proper tunnel.
If there is automated key management deployed, the authentication REQ 10: The security solution for NVO3 SHOULD enable two NVEs to
and authorization can be used to largely mitigate the isolation mutually authenticate each other before establishing a tunnel
issues. When a NVE attempts to join a VN, the NVE needs to be connecting them for data transportation.
authenticated and prove that it have sufficient privileges. Then,
a new key (or a set of keys) will be generated to secure its
control packet exchanged with this VN.
5.1.2. Data Plane This entity authentication requirement is used to protect a NVE
against imposter attacks. Also, this requirement can help
guarantee a data tunnel is generated between two proper NVEs and
reduce the risk of man-in-the-middle attacks.
[I-D.ietf-nvo3-framework] specifies a NVO3 overlay needs to generate In order to protect the data packets transported over the overlay
tunnels between NVEs for data transportation. When a data packet against the attacks raised from the underlying network, the NVO3
reaches the boundary of a overlay, it will be encapsulated and overlay needs to provide essential security protection for data
forwarded to the destination NVE through a proper tunnel. packets.
REQ6: Integrity, confidentiality, and origin authentication REQ 11: The security solution of NVO3 MUST be able to provide
protection for data traffics integrity protection, replay protection, and packet origin
a: The integrity and origin authentication of data traffics MUST authentication for data traffics exchanged between NVEs.
be guaranteed when the underlying network is not secure.
During the transportation of data packets, it is the This requirement is used to prevent an attacker who has
responsibility of the NVO3 overlay to deal with the attacks from compromised a underlying network devices on the path from
the underlying network. For instance, an inside attacker replaying antique packets or injecting bogus data packets without
compromising a underlying network device may intercept an being detected.
encapsulated data packet transported within a tunnel, modify the
contents in the encapsulating tunnel packet and, transfer it into
another tunnel without being detected. When the modified packet
reaches a NVE, the NVE may decapsulated the data packet and
forward it into a VN according to the information within the
encapsulating header generated by the attacker. Similarly, a
compromised NVE may try to redirect the data packets within a VN
into another VN by adding improper encapsulating tunnel headers to
the data packets.
Under such circumstances, in order to enforce the VN isolation REQ 12: The security solution of NVO3 MAY provide confidentiality
property, underlying security protocols need to provided. protection for data traffics exchanged between NVEs.
Signatures or digests need to be generated for both data packets
and the encapsulating tunnel headers in order to provide data
origin authentication and integrity protection.
b: The confidentiality protection of data traffics SHOULD be If the data traffics from the TSes are sensitive, they needs to be
provided, when the underlying network is not secure. 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.
If the data traffics from the TSes is sensitive, they needs to be REQ 13: The security solution of NVO3 SHOULD be able to assign
encrypted during the tunnels. However, if the data traffics is different cryptographic keys to protect the unicast tunnels
not valuable and sensitive, the encryption is not necessary. between NVEs respectively.
REQ7: Different tunnels SHOULD be secured with different keys 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.
This requirement can be used to provide a basic attack confinement REQ 14: If there are multicast packets, the security solution of
capability. When different tunnels secured with different keys, NVO3 SHOULD be able to assign distinct cryptographic group keys to
the compromise of a key in a tunnel will not affect the security protect the multicast packets exchanged among the NVEs within
of others. different multicast groups.
5.2. Control/Data Traffic between NVEs and Hypervisors 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.
Assume there is a VNE providing a logical L2/L3 interconnect for a REQ 15: Upon receiving a data packet, an egress NVE must be able to
set of TSes. Apart from data traffics, the NVE and certain TSes verify whether the packet is from a proper ingress NVE which is
(i.e., Hypervisors) also need to exchange signaling packets in order authorized to forward that packet.
to facilitate, e.g., VM online detection, VM migration detection, or
auto-provisioning/service discovery [I-D.ietf-nvo3-framework].
The NVE and its associated TSes can be deployed in a distributed way In cooperation with authentication, authorization enables a egress
(e.g., a NVE is implemented in an individual device, and VMs are NVE to detect the data packets which violate certain security
located on servers) or in a co-located way (e.g., a NVE and the TSes policies, even when they are forwarded from a legal NVE. For
it serves are located on the same server). 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.1. Distributed Deployment of NVE and Hypervisor 5.2. Control/Data Plane between NVEs and Hypervisors
In this case, the data and control traffic between the NVE and the Apart from data traffics, the NVE and hypervisors may also need to
TSes are exchanged over network. exchange signaling packets in order to facilitate, e.g., VM online
detection, VM migration detection, or auto-provisioning/service
discovery [I-D.ietf-nvo3-framework].
5.2.1.1. Control Plane 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.
REQ8: Mutual authentication MUST be performed between a NVE and a TS 5.2.1. Distributed Deployment of NVE and Hypervisor
at the beginning of their communication, if the network connecting
them is not secure.
Mutual authentication is used to guarantee that an attacker cannot Five security requirements appliabled for both control and data
impersonate a legal NVE or a hypervisor without being detected. packets exchanged between NVEs and hypervisors are listed as follows:
There are various ways to perform mutual authentication. If there REQ 16: The security solution for NVO3 SHOULD enable the
are auto key management mechanism (e.g., IKEv2, EAP), the NVE and communicating NVE and hypervisor to mutually authenticate each
the TS can use their credential to perform authentication. If other before exchanging any control/ data packets.
there a key pre-distributed between a NVE and a TS, an entity can
also use the key verify the identity of is remote peer.
If practice, a NVE and a TS may simply use IP or MAC addresses to Mutual authentication is used to prevent an attacker from
identify each other. This type of technique can be used as a impersonating a legal NVE or a hypervisor without being detected
complementary approach although it may becomes vulnerable if and then reduce the risks of man-in-the-middle attacks. A
attackers can inject bogus control packets the network and modify successful authentication normally results in the distribution key
the packets transported between the NVE and TS. materials to protect the security of subsequent communications.
REQ9: Before accepting a control packet, the receiver device MUST REQ 17: The security solution of NVO3 MUST be able to provide
verify whether the packet comes from one which has the privilege integrity protection, replay protection and origin authentication
to send that packet. for the control/ data packets exchanged between a NVE and a
hypervisor.
This is an authorization requirement. A device needs to clarify Packet level security protection can prevent an attacker from
the roles (e.g., a TS or a NVE) of the device that it is illegally interfere with the normal operations of NVEs and
communicating with. Therefore, if a compromised TS attempts to hypervisors by injecting bogus control packets into the network.
use it credentials to impersonate a NVE to communicate with other In addition, because it is assumed the network connecting the NVE
TSes, it will be detected. 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 VN
identification information in the packet headers so as to
manipulate the NVE to transport the data packets within a VN to
another.
Authorization is very important to guarantee the isolation REQ 18: If a NVE needs to communicate with multiple hypervisors, the
property. For instance, if a compromised hypervisor tries to security solution of a NVO3 network SHOULD be able to provide
elevate its privilege and interfere the VNs that it is not different keys and ciphers to secure the control /data packets
supposed to be involved within, its attempt will be detected and exchanged between different hypervisors and their NVEs
rejected. respectively.
Normally, it is assumed that the access control operations are This requirement is used to benefit the damage confinement of
based on the authentication results. The simple authorization inside attacks. For instance, the compromise of a hypervisor will
mechanisms (such as ACLs which filters packets based on the packet not affect the security of control/data traffics exchanged between
addresses) can be used as complementary solutions. the NVE and other hypervisors.
REQ10: Integrity, Confidentiality, and Origin Authentication for REQ 19: Before accepting a control/data packet, a NVE or a
Control Packets hypervisor receiving the packet MUST verify that the device
sending the packet is authorized to do so.
a:The security solution of a NVE network MUST be able to provide This is an authorization requirement. When receiving a control/
integrity protection and origin authentication for the control data packet, besides authentication, authorization needs to be
packets exchanged between a NVE and a TS if they have to use an carried out by a NVE or a hypervisor to identify the role that the
insecure network to transport their packet. packet sender acts as and then assess the sender's privileges.
Therefore, if a compromised hypervisor attempts to use it
credentials to impersonate a NVE to communicate with other
hypervisors, it will be detected.
This requirement can prevent an attacker from illegally interfere REQ 20: The security solution of a NVO3 network SHOULD be able to
with the normal operations of NVEs and TSes by injecting bogus provide different security levels of protections for the control/
control packets into the network. data traffics exchanged between a NVE or a hypervisor.
b:The confidentiality protection for the control packet exchange The control and data traffics between a NVE and a hypervisor may
SHOULD be provided. be transported over the same path or even within the same security
channel. However, when the control traffics and data traffics
have different levels of sensitivity, the protection on them needs
be different. In this case, the security solution may need to
different security channels for control and data traffics
respectively and so protect the data and control traffics
exchanged between a hypervisor and a NVE with different keys and
ciphers.
When the contents of the control packets (e.g., the location of a 5.2.1.1. Control Plane
ES, when a VM migration happens) are sensitive to a tenant, the
control packet needs to be encrypted.
There are various security protocols (such as IPsec, SSL, and TCP- REQ 21: The security solution of a NVO3 network MAY provide
AO) can be used for transport control packets. In addition, it is confidentiality protection for the control traffics exchanged
possible to define integrated security solutions for the control between a NVE and a hypervisor.
packets.
In order to secure the control traffic, cryptographic keys need to The contents of the control/data packets need to be encrypted when
be distributed to generate digests or signatures for the control they are considered to be sensitive.
packets. Such cryptographic keys can be manually deployed in
advance or dynamically generated with certain automatic key
management protocols (e.g., TLS [RFC5246]).
REQ11: The key management solution MUST be able to confine the scope Similar to REQs 6 and 7, the following two requirements are used to
of key distribution and provide different keys to isolate the mitigate potential DDoS risks.
control traffic according to different security requirements.
a: If assuming TSes (hypervisors) will not be compromised, the REQ 22: The frequency in forwarding control packets from a NVE or a
TSes belonging to different Tenants MUST use different keys to hypervisors MUST be limited.
secure the control packet exchanges with their NVE.
This requirement is used to enforce the security boundaries of This is a common security requirement that can effectively avoid
different tenant networks. Since different tenants belong to the capability of a device in processing control packets to be
different security domains and may be competitive to each other, overwhelmed by the high frequent control packets generated by the
the control plane traffics need to be carefully isolated so that devices attached to it.
an attacker from a tenant cannot affect the operations of another
tenant network.
b: If assuming the hypervisors can be compromised, the TSes REQ 23: Amplification effect SHOULD be Addressed.
belonging to different VNs MUST use different keys to secure the
control packets exchanges with their NVE.
Therefore, if a key used for a VN is compromised, other VNs will If the responses generated by a NVE or a hypervisor are much
not be affected. This requirement is used to ensure the VN longer than the received requests, an attacker may take advantage
isolation property. of the device as a reflector to perform DDoS attacks.
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 5.2.1.2. Data Plane
REQ12: The data traffic isolation of different VNs MUST be REQ 24: The security solution of a NVO3 network MUST provide
guaranteed. security gateways to control the data traffics across the
boundaries of different VNs according to specified security
policies.
In [I-D.ietf-nvo3-overlay-problem-statement], the data plane In [I-D.ietf-nvo3-overlay-problem-statement], the data plane
isolation requirement amongst different VNs has been discussed. isolation requirement amongst different VNs has been discussed.
The traffic within a virtual network can only be transited into The traffic within a virtual network can only be transited into
another one in a controlled fashion (e.g., via a configured router another one in a controlled fashion (e.g., via a configured router
and/or a security gateway). Therefore, if the NVE supports and/or a security gateway).
multiple VNs concurrently, the data traffic in different VNs MUST
be isolated.
a:The security solution of a NVE network MUST be able to provide REQ 25: The security solution of a NVO3 network MAY provide
integrity protection and origin authentication for the data confidentiality protection for the data traffics exchanged between
packets exchanged between a NVE and a TS if they have to use an a NVE and a hypervisor.
insecure network to transport their data packet.
In practice, the data traffics in different VNs can be isolated When the contents of the data packets are sensitive to a tenant,
physically or by using VPN technologies. If the network the data packet needs to be encrypted. The security solution of a
connecting the NVE and the TSes is potentially accessible to NVE network may need to provide confidentiality for the data
attackers, security solutions need to be considered to prevent an packets exchanged between a NVE and a hypervisor if they have to
attacker locating in the middle between the NVE and TS from use an insecure network to transport their data packet and the
modifying the VN identification information in the packet headers tenants cannot encrypt their sensitive data themselves.
so as to manipulate the NVE to transport the data packets within a
VN to another. The security protocols such as IPsec and TCP-AO,
can be used to enforce the isolation property if necessary.
The key management requirement R11 can be applied here for data 6. Candidate Techniques
traffic
5.3. Key Management This section introduces the techniques which can potentially be used
REQ13: A security solution for NVO3 SHOULD provide automated key to fulfill the security requirements introduced in Section 5.
management mechanisms.
In the cases where there are a large amount of NVEs working within 6.1. Entity Authentication
a NVO3 overlay, manual key management may become infeasible.
First, it could be burdensome to deploy pre-shared keys for
thousands of NVEs, not to mention that multiple keys may need to
be deployed on a single device for different purposes. Key
derivation can be used to mitigate this problem. Using key
derivation functions, multiple keys for different usages can be
derived from a pre-shared master key. However, key derivation
cannot protect against the situation where a system was
incorrectly trusted to have the key used to perform the
derivation. If the master key were somehow compromised, all the
resulting keys would need to be changed [RFC4301]. In addition,
VM migration will introduce challenges to manual key management.
The migration of a VM in a VN may cause the change of the NVEs
which are involved within the NV. When a NVE is newly involved
within a VN, it needs to get the key to join the operations within
the VN. If a NVE stops supporting a VN, it should not keep the
keys associated with that VN. All those key updates need to be
performed at run time, and difficult to be handled by human
beings. As a result, it is reasonable to introduce automated key
management solutions such as EAP [RFC4137] for NVO3 overlays.
Without the support automated key management mechanisms, some Entity authentication is normally performed as a part of automated
security functions of certain security protocols cannot work key management, and a successful authentication may result in the key
properly. For instance, the anti-replay mechanism of IPsec is materials used in subsequent communications.
turned off without the support of automated key management
mechanisms. Therefore, if IPsec is selected to protect the
control packets. In this case, the system may suffer from the
replay attacks.
6. IANA Considerations The widely adopted protocols supporting entity authentication
include: IKE[RFC2409], IKEv2[RFC4306], EAP[RFC4137], TLS [RFC5246]
and etc.
It is recommended to cryptographically verify the devices' identities
during authentication. Therefore, an inside attacker cannot use the
keys or credentials got from the compromised device to impersonate
other victims.
6.2. Packet Level Security
There are requirements about protecting the integrity,
confidentiality, and provide packet origin authentication for control
/ data packets. Such functions can be provided through using the
underlying security protocols (e.g., IPsec AH[RFC4302], IPsec
ESP[RFC4303], TLS[RFC5246]). Also, when designing the control
protocols people can select to provide embedded security approaches
(just like the packet level security mechanism provided in
OSPFv2[RFC2328]). The cryptographic keys can be manually deployed or
dynamically generated by using certain automatic key management
protocols. Note that when using manual key management, the replay
protection mechanism of IPsec will be switched off.
6.3. Authorization
Without any cryptographic supports, the authorization mechanisms
(e.g., packet filters) could be much easier to be bypassed by
attackers, and thus the authorization mechanisms deployed on NOV3
devices should interoperate with entity authentication and other
packet level security mechanisms, and be able to make the access
control decisions based on the cryptographically proved results. 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.
7. 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.
7. Security Considerations 8. Security Considerations
TBD 8.1. Automated Key Management in NVO3
8. Acknowledgements Because entity authentication and automated key distribution are
normally performed in the same process, the requirements of entity
authentication have already implied that it is recommended to use
automated key management in the security solutions for NVO3 networks.
In the cases where there are a large amount of NVEs working within a
NVO3 overlay, manual key management becomes infeasible. First, it
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
device for different purposes. Key derivation can be used to
mitigate this problem. Using key derivation functions, multiple keys
for different usages can be derived from a pre-shared master key.
However, key derivation cannot protect against the situation where a
system was incorrectly trusted to have the key used to perform the
derivation. If the master key were somehow compromised, all the
resulting keys would need to be changed [RFC4301]. Moreover, some
security protocols need the support of automated key management in
order to perform certain security functions properly. As mentioned
above, the replay protecting mechanism of IPsec will be turned off
without the support of automated key management mechanisms.
Thanks a lot for the comments from Melinda Shore, and Zu Qiang. 8.2. Issues not Discussed
9. References 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:
9.1. Normative References 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
security extensions
9. Acknowledgements
Thanks a lot for the comments from Melinda Shore and Zu Qiang.
10. References
10.1. Normative References
[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.
9.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-framework]
Lasserre, M., Balus, F., Morin, T., Bitar, N., and Y. Lasserre, M., Balus, F., Morin, T., Bitar, N., and Y.
Rekhter, "Framework for DC Network Virtualization", draft- Rekhter, "Framework for DC Network Virtualization", draft-
ietf-nvo3-framework-03 (work in progress), July 2013. ietf-nvo3-framework-04 (work in progress), November 2013.
[I-D.ietf-nvo3-overlay-problem-statement] [I-D.ietf-nvo3-overlay-problem-statement]
Narten, T., Gray, E., Black, D., Fang, L., Kreeger, L., Narten, T., Gray, E., Black, D., Fang, L., Kreeger, L.,
and M. Napierala, "Problem Statement: Overlays for Network and M. Napierala, "Problem Statement: Overlays for Network
Virtualization", draft-ietf-nvo3-overlay-problem- Virtualization", draft-ietf-nvo3-overlay-problem-
statement-04 (work in progress), July 2013. statement-04 (work in progress), July 2013.
[I-D.kreeger-nvo3-hypervisor-nve-cp] [I-D.kreeger-nvo3-hypervisor-nve-cp]
Kreeger, L., Narten, T., and D. Black, "Network Kreeger, L., Narten, T., and D. Black, "Network
Virtualization Hypervisor-to-NVE Overlay Control Protocol Virtualization Hypervisor-to-NVE Overlay Control Protocol
Requirements", draft-kreeger-nvo3-hypervisor-nve-cp-01 Requirements", draft-kreeger-nvo3-hypervisor-nve-cp-01
(work in progress), February 2013. (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-05 Layer 3 Networks", draft-mahalingam-dutt-dcops-vxlan-06
(work in progress), October 2013. (work in progress), November 2013.
[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.
[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.
[RFC4137] Vollbrecht, J., Eronen, P., Petroni, N., and Y. Ohba, [RFC4137] Vollbrecht, J., Eronen, P., Petroni, N., and Y. Ohba,
"State Machines for Extensible Authentication Protocol "State Machines for Extensible Authentication Protocol
(EAP) Peer and Authenticator", RFC 4137, August 2005. (EAP) Peer and Authenticator", RFC 4137, August 2005.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005. Internet Protocol", RFC 4301, December 2005.
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December
2005.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC
4303, December 2005.
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC
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.
Authors' Addresses Authors' Addresses
Sam Hartman Sam Hartman
 End of changes. 116 change blocks. 
432 lines changed or deleted 545 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/