draft-ietf-nvo3-security-requirements-04.txt   draft-ietf-nvo3-security-requirements-05.txt 
Network Working Group S. Hartman Network Working Group S. Hartman
Internet Draft Painless Security Internet Draft Painless Security
Intended status: Informational D. Zhang Intended status: Informational D. Zhang
Expires: July 28,, 2015 Alibaba Expires: December 18, 2015
M. Wasserman M. Wasserman
Painless Security Painless Security
Z. Qiang Z. Qiang
Ericsson Ericsson
Mingui Zhang M. Zhang
Huawei Huawei
January 28, 2015 June 18, 2015
Security Requirements of NVO3 Security Requirements of NVO3
draft-ietf-nvo3-security-requirements-04 draft-ietf-nvo3-security-requirements-05
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 NVO3 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
skipping to change at page 1, line 45 skipping to change at page 1, line 45
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 working Task Force (IETF). Note that other groups may also distribute working
documents as Internet-Drafts. The list of current Internet-Drafts is documents as Internet-Drafts. The list of current Internet-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 July 28, 2015. This Internet-Draft will expire on December 18, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2015 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
skipping to change at page 2, line 30 skipping to change at page 2, line 30
Table of Contents Table of Contents
1. Introduction...................................................3 1. Introduction...................................................3
2. Terminology....................................................3 2. Terminology....................................................3
3. NVO3 Overlay Architecture......................................4 3. NVO3 Overlay Architecture......................................4
4. Threat Model...................................................5 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
5. Scope..........................................................6 5. Scope..........................................................6
6. Security Requirements..........................................8 6. Security Requirements..........................................7
6.1. Control Plane of NVO3 Overlay.............................8 6.1. Control Plane of NVO3 Overlay.............................7
6.2. NVE-NVE Data Plane.......................................11 6.2. NVE-NVE Data Plane.......................................11
6.3. NVE-Hypervisor Data Plane................................13 6.3. NVE-Hypervisor Data Plane................................13
7. Candidate Techniques..........................................15 7. Candidate Techniques..........................................14
7.1. Entity Authentication....................................15 7.1. Entity Authentication....................................15
7.2. Packet Level Security....................................15 7.2. Packet Level Security....................................15
7.3. Authorization............................................15 7.3. Authorization............................................15
7.4. Automated Key Management.................................16
8. IANA Considerations...........................................16 8. IANA Considerations...........................................16
9. Security Considerations.......................................16 9. Security Considerations.......................................16
9.1. Automated Key Management in NVO3.........................16
10. Acknowledgements.............................................17 10. Acknowledgements.............................................17
11. References...................................................17 11. References...................................................17
11.1. Normative References....................................17 11.1. Normative References....................................17
11.2. Informative References..................................17 11.2. Informative References..................................17
Authors' Addresses...............................................19
1. Introduction 1. Introduction
As described in [RFC7365], the NVO3 framework is intended to aid in As described in [RFC7365], the NVO3 framework is intended to aid in
standardizing protocols and mechanisms to support large-scale multi- standardizing protocols and mechanisms to support large-scale multi-
tenancy data centers. In such kind data center, security is a key tenancy data centers. In such kind data center, security is a key
issue which needs to be considered during the network design. This issue which needs to be considered during the network design. This
document discusses the security risks that a NVO3 network may document discusses the security risks that a NVO3 network may
encounter and tries to provide a list of essential security encounter and tries to provide a list of essential security
requirements that needs to be fulfilled. In addition, this document requirements that needs to be fulfilled. In addition, this document
introduces the candidate techniques which could be potentially used introduces the candidate techniques which could be potentially used
to construct a security solution fulfilling the security to construct a security solution fulfilling the NVO3 security
requirements. requirements.
The remainder of this document is organized as follows. Section 2 The remainder of this document is organized as follows. Section 2
introduces several key terms used in this memo. Section 3 gives a introduces several key terms used in this memo. Section 3 gives a
brief introduction of the NVO3 network architecture. Section 4 brief introduction of the NVO3 network architecture. Section 4
discusses the attack model of this work. Section 5 lists the scope of discusses the attack model of this document. Section 5 lists the
the security considerations of this memo. Section 6 provides a list scope of the security considerations of this document. Section 6
of security requirements as well as the associated justifications. In provides a list of security requirements as well as the associated
Section 7, the candidate techniques are introduced. Section 9 justifications. In Section 7, the candidate techniques are
discusses additional security considerations. introduced.
2. Terminology 2. Terminology
This document uses the same terminology as defined in the NVO3 This document uses the same terminology as defined in the NVO3
Framework document [RFC7365] and the Hypervisor to NVE Control Plane Framework document [RFC7365] and the Hypervisor to NVE Control Plane
Requirements document [I-D.ietf-nvo3-hpvr2nve-cp-req]. The Followings Requirements document [I-D.ietf-nvo3-hpvr2nve-cp-req]. The Followings
are the additional terminologies that are used by this document. are the additional terminologies that are used by this document.
Hypervisor: This memo uses the term "hypervisor" throughout when Hypervisor: This memo uses the term "hypervisor" throughout when
describing requirements at the Split-NVE scenario where part of the describing requirements at the Split-NVE scenario where part of the
skipping to change at page 5, line 34 skipping to change at page 5, line 34
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 A) Analyze the traffic pattern within the network by performing
passive attacks; passive attacks;
2. Disrupt the network connectivity or degrade the network service B) 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 C) 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 A) Interfere with the normal operations of the overlay as a legal NVO3
NVO3 device, by sending packets containing invalid information or device, by sending packets containing invalid information or with
with improper frequencies; improper frequencies;
2. Perform spoofing attacks and impersonate another legal NVO3 device B) Perform spoofing attacks and impersonate another legal NVO3 device
to communicate with victims using the cryptographic information it to communicate with victims using the cryptographic information it
obtained; and obtained; and
3. Access the contents of the data/control packets if they are C) 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 A) Interfere with the normal operations of the overlay as a legal TS,
TS, by sending packets containing invalid information or with by sending packets containing invalid information or with improper
improper frequencies to NVEs; frequencies to NVEs;
2. Perform spoofing attacks and impersonate another legal TS or NVE B) Perform spoofing attacks and impersonate another legal TS or NVE to
to communicate with victims (other legal NVEs or TSes) using the 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 C) 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.
5. Scope 5. Scope
During the specification of security requirements, the following The following security issues are in the scope of the NVO3 security
security issues needs to be considered: requirement consideration of this document:
1. The NVO3 connections may be considered as secured if there is a A) The NVO3 connections may be considered as secured if there is a
security solution supported by the underlying network. However security solution supported by the underlying network. However such
such kind security solution normally only can protect the NVO3 kind security solution normally only can protect the NVO3 network
network from outsider attacker. from outsider attacker.
2. During the design of a security solution for a NVO3 network, the B) 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 C) 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 security issues are out of scope of the NVO3 security
document: requirement consideration of this document:
1. In this memo it is assumed that security protocols, algorithms, A) In this document, it is assumed that security protocols,
and implementations provide the security properties for which they algorithms, and implementations provide the security properties for
are designed; attacks depending on a failure of this assumption which they are designed; attacks depending on a failure of this
are out of scope. For instance, an attack caused by a weakness in assumption are out of scope. For instance, an attack caused by a
a cryptographic algorithm is out of scope, while an attack caused weakness in a cryptographic algorithm is out of scope, while an
by failure to use confidentiality when confidentiality is a attack caused by failure to use confidentiality when
security requirement is in scope. confidentiality is a security requirement is in scope.
2. An attacker controlling an underlying network device may break the B) An attacker controlling an underlying network device may break 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. The security delivery of the packets passing through it. The security
consideration to prevent this type of attack is out of scope of consideration to prevent this type of attack is out of scope of
this memo. this document.
3. NVAs are centralized servers and play a critical role in NVO3 C) NVAs are centralized servers and play a critical role in NVO3
overlay network. A NVE will believe in the mapping information overlay network. A NVE will believe in the mapping information
obtained 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. The security requirements discussed in this document is to of NVA. The security requirements discussed in this document is to
protect a NVA from any security risk. And if a NVA is attacked, it 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 should be detected. However, this document does not consider how to
deal with the problem after a NVA is compromised. deal with the problem after a NVA is compromised.
4. Because this memo only tries to provide the most essential high D) Because this document only tries to provide the most essential high
level requirements, some important issues in designing concept level requirements, some important issues in designing concept
security mechanisms are not covered in the requirements. Such security mechanisms are not covered in the requirements. Such
issues include: issues include:
- How to manage keys/credentials during their life periods - How to manage keys/credentials during their life periods
- How to support algorithm agility - How to support algorithm agility
- How to provide accountability - How to provide accountability
- How to secure the management interfaces - How to secure the management interfaces
- Use underlying security protocols versus design integrated - Use underlying security protocols versus design integrated
security extensions security extensions
6. Security Requirements 6. Security Requirements
6.1. Control Plane of NVO3 Overlay 6.1. Control Plane of NVO3 Overlay
In this section, the security requirements associated with following In this section, the security requirements associated with following
control plane are described: control plane are described:
- The NVE-NVA control plane: allows a NVE to obtain information - The NVE-NVA control plane: allows a NVE to obtain information
about the location and status of other TSs with which it needs to about the location and status of other TSs with which it needs to
skipping to change at page 8, line 41 skipping to change at page 8, line 30
over network in order to facilitate, e.g., VM online detection, VM over network in order to facilitate, e.g., VM online detection, VM
migration detection, or auto-provisioning/service discovery as migration detection, or auto-provisioning/service discovery as
described in [RFC7365]. In this case, the term "NVO3 device" is described in [RFC7365]. In this case, the term "NVO3 device" is
referring to a Hypervisor or a NVE. referring to a Hypervisor or a NVE.
REQ 1. The security solution for NVO3 MUST enable the two NVO3 REQ 1. The security solution for NVO3 MUST enable the two NVO3
devices to mutually authenticate each other before exchanging devices to mutually authenticate each other before exchanging
any control packets. any control packets.
Entity authentication can protect a NVO3 device against imposter Entity authentication can protect a NVO3 device against imposter
attacks and then reduce the risk of DoS/DDoS attacks and man-in-the- attacks and then reduce the risk of DoS / DDoS attacks and man-in-
middle attacks. In addition, a successful authentication normally the-middle attacks. In addition, a successful authentication normally
results in the distribution key materials for the security protection results in the distribution key materials for the security protection
for subsequent communications. More detailed discussions are provided for subsequent communications. More detailed discussions are provided
in Section 6.1. in Section 6.1.
REQ 2. The security solution of NVO3 MUST be able to provide REQ 2. The security solution of NVO3 MUST be able to provide
integrity protection, replay protection, and packet origin integrity protection, replay protection, and packet origin
authentication for the control packets exchanged between two authentication for the control packets exchanged between two
NVO3 devices. NVO3 devices.
Message authentication is performed on each incoming packet. Packet Message authentication is performed on each incoming packet. Packet
skipping to change at page 10, line 30 skipping to change at page 10, line 21
specified for integrity and confidentiality, at least one group key specified for integrity and confidentiality, at least one group key
may need to be shared among the NVO3 devices in a same multicast may need to be shared among the NVO3 devices in a same multicast
group. It is recommended to use different keys for different group. It is recommended to use different keys for different
multicast groups. multicast groups.
REQ 7. The resistance at DOS/DDOS attack MUST be considered in the REQ 7. The resistance at DOS/DDOS attack MUST be considered in the
design of NVO3 control plane design of NVO3 control plane
Any NVO3 devices may be used by an attacker to initiate a DOS/DDOS. Any NVO3 devices may be used by an attacker to initiate a DOS/DDOS.
One example is that in a NVO3 overlay, NVAs can be the valuable One example is that in a NVO3 overlay, NVAs can be the valuable
targets of DoS/DDoS attacks, and large amount of NVEs can be targets of DoS / DDoS attacks, and large amount of NVEs can be
potentially used as reflectors in reflection attacks. Therefore, the potentially used as reflectors in reflection attacks. Therefore, the
DoS/DDoS risks needs be considered during designing the control DoS / DDoS risks needs be considered during designing the control
planes for NVO3. The following requirements, but not limited to this planes for NVO3. The following requirements, but not limited to this
listed, are used to benefit the migration of DoS/DDoS issue. listed, are used to benefit the migration of DoS/DDoS issue.
REQ 7.a. A NVO3 device MUST have a frequency limitation at REQ 7.a. A NVO3 device MUST have a frequency limitation at
sending its control packets and processing any received sending its control packets and processing any received
control packets. control packets.
Without this limitation, an attacker can attempt to perform DoS/DDoS Without this limitation, an attacker can attempt to perform DoS /
attacks to exhaust the limited computing and memory resources of a DDoS attacks to exhaust the limited computing and memory resources of
target NVO3 device by manipulating a compromised NVO3 device to a target NVO3 device by manipulating a compromised NVO3 device to
generate a significant amount of control plane packets in a short generate a significant amount of control plane packets in a short
period. period.
REQ 7.b. The amplification effect MUST be avoided REQ 7.b. The amplification effect MUST be avoided
A distributed denial-of-service attack may involve sending forged A distributed denial-of-service attack may involve sending forged
requests of some type to a very large number of NVO3 devices that requests of some type to a very large number of NVO3 devices that
will reply to the requests. If in certain conditions, the responses will reply to the requests. If in certain conditions, the responses
generated by a NVO3 device are a much longer process than the generated by a NVO3 device are a much longer process than the
received requests. An attacker may take advantage of this received requests. An attacker may take advantage of this
skipping to change at page 13, line 27 skipping to change at page 13, line 16
It is recommended to deploy different keys for different multicast It is recommended to deploy different keys for different multicast
groups, in order to confine the insider attacks on NVEs. groups, in order to confine the insider attacks on NVEs.
REQ 14. Upon receiving a data packet, an egress NVE MUST be able 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 to verify whether the packet is sent from a proper ingress NVE
which is authorized to forward that packet. which is authorized to forward that packet.
In cooperation with authentication, authorization enables an egress In cooperation with authentication, authorization enables an egress
NVE to detect the data packets which violate certain security NVE to detect the data packets which violate certain security
policies, even when they are forwarded from a legal NVE. For policies, even when they are forwarded from a legal NVE. For
instance, if the remote NVE is not authorized to forward data packet 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 of a given VN, the packet needs to be detected and discarded without
processing. Note that the detection of an invalid packet may not processing. Note that the detection of an invalid packet may not
indicate that the system is under a malicious attack. Mis- indicate that the system is under a malicious attack. Mis-
configuration or byzantine failure of a NVE may also result in such configuration or byzantine failure of a NVE may also result in such
invalid packets. invalid packets.
6.3. NVE-Hypervisor Data Plane 6.3. NVE-Hypervisor Data Plane
As described in the NVO3 architecture draft [I-D.ietf-nvo3-arch], in As described in the NVO3 architecture draft [I-D.ietf-nvo3-arch], in
split-NVE scenario, a number of link types are possible between NVE split-NVE scenario, a number of link types are possible between NVE
skipping to change at page 15, line 10 skipping to change at page 14, line 45
protection (including authentication, integrity, confidentiality) for protection (including authentication, integrity, confidentiality) for
the multicast packets transferred within the multicast group, at the multicast packets transferred within the multicast group, at
least one group key may need to be shared among the hypervisors and least one group key may need to be shared among the hypervisors and
their NVE of the same multicast group. It is recommended to deploy their NVE of the same multicast group. It is recommended to deploy
different keys for different multicast groups, in order to confine different keys for different multicast groups, in order to confine
the insider attacks on the hypervisors and their NVE. the insider attacks on the hypervisors and their NVE.
7. 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 6.
7.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, In the circumstance where no authentication protocols are applied,
the communicating entities could use message authentication the communicating entities could use message authentication
mechanisms to verify each other's identity. 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 [RFC5996], 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.
7.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], or MACsec [802.1AE]. Also, when ESP [RFC4303], TLS [RFC5246], or MACsec [802.1AE]. Also, when
designing the control protocols people can select to provide embedded designing the control protocols, people can select to provide
security approaches (just like the packet level security mechanism embedded security approaches (just like the packet level security
provided in OSPFv2 [RFC2328]). The cryptographic keys can be manually mechanism provided in OSPFv2 [RFC2328]). The cryptographic keys can
deployed or dynamically generated by using certain automatic key be manually deployed or dynamically generated by using certain
management protocols. Note that when using manual key management, the automatic key management protocols. Note that when using manual key
replay protection mechanism of IPsec will be switched off. management, the replay protection mechanism of IPsec will be switched
off.
7.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 NVO3 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. control decisions based on the cryptographically proved results.
An exception is packet filtering. Because packet filters are An exception is packet filtering. Because packet filters are
efficient and can effectively drop some un-authorized packets before efficient and can effectively drop some un-authorized packets before
they have to be cryptographically verified, it is worthwhile to use they have to be cryptographically verified, it is worthwhile to use
packet filters as an auxiliary approach to dealing with some simple packet filters as an auxiliary approach to dealing with some simple
attacks and increasing the difficulties of DoS/DDoS attacks attacks and increasing the difficulties of DoS / DDoS attacks
targeting at the security protocol implementations. targeting at the security protocol implementations.
For instance, a NVE may maintain an authorization NVE table. This For instance, a NVE may maintain an authorization NVE table. This
table may be distributed by a trusted entity, e.g. NVA, in table may be distributed by a trusted entity, e.g. NVA, in
combination with the inner-outer address mapping table. And NVE may combination with the inner-outer address mapping table. And NVE may
use this table to filter the received control / data packets over use this table to filter the received control / data packets over
NVE-NVE interface. The NVE may effectively drop any packets received NVE-NVE interface. The NVE may effectively drop any packets received
from an unauthorized NVE before processing it, e.g. from an unauthorized NVE before processing it, e.g.
cryptographically verification procedure. cryptographically verification procedure.
8. IANA Considerations 7.4. Automated Key Management
This document makes no request of IANA.
Note to RFC Editor: this section may be removed on publication as an
RFC.
9. Security Considerations
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 mitigate device for different purposes. Key derivation can be used to mitigate
skipping to change at page 17, line 7 skipping to change at page 16, line 37
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. IANA Considerations
This document makes no request of IANA.
Note to RFC Editor: this section may be removed on publication as an
RFC.
9. Security Considerations
This is a requirement document which provides security requirements
for the NVO3 network and in itself does not introduce any new
security concerns.
10. Acknowledgements 10. Acknowledgements
Many people have contributed to the development of this document and Many people have contributed to the development of this document and
many more will probably do so before we are done with it. While we many more will probably do so before we are done with it. While we
cannot thank all contributors, some have played an especially cannot thank all contributors, some have played an especially
prominent role. The followings have provided essential input: prominent role. The followings have provided essential input:
Melinda Shore and Makan Pourzandi. Melinda Shore and Makan Pourzandi.
11. References 11. References
skipping to change at page 17, line 38 skipping to change at page 17, line 36
[I-D.ietf-ipsecme-ad-vpn-problem] Manral, V. and S. Hanna, "Auto [I-D.ietf-ipsecme-ad-vpn-problem] Manral, V. and S. Hanna, "Auto
Discovery VPN Problem Statement and Requirements", draft- Discovery VPN Problem Statement and Requirements", draft-
ietf-ipsecme-ad-vpn-problem-09 (work in progress), July ietf-ipsecme-ad-vpn-problem-09 (work in progress), July
2013. 2013.
[I-D.ietf-nvo3-hpvr2nve-cp-req] Yizhou, L., Yong, L., Kreeger, L., [I-D.ietf-nvo3-hpvr2nve-cp-req] Yizhou, L., Yong, L., Kreeger, L.,
Narten, T., and D. Black, "Hypervisor to NVE Control Plane Narten, T., and D. Black, "Hypervisor to NVE Control Plane
Requirements", draft-ietf-nvo3-hpvr2nve-cp-req-01 (work in Requirements", draft-ietf-nvo3-hpvr2nve-cp-req-01 (work in
progress), November 2014. progress), November 2014.
[I-D.mahalingam-dutt-dcops-vxlan] Mahalingam, M., Dutt, D., Duda, K.,
Agarwal, P., Kreeger, L., Sridhar, T., Bursell, M., and C.
Wright, "VXLAN: A Framework for Overlaying Virtualized
Layer 2 Networks over Layer 3 Networks", draft-mahalingam-
dutt-dcops-vxlan-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 [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange
(IKE)", RFC 2409, November 1998. (IKE)", RFC 2409, November 1998.
[RFC4046] Baugher, M., Canetti, R., Dondeti, L., and F. Lindholm, [RFC4046] Baugher, M., Canetti, R., Dondeti, L., and F. Lindholm,
"Multicast Security (MSEC) Group Key Management "Multicast Security (MSEC) Group Key Management
Architecture", RFC 4046, April 2005. Architecture", RFC 4046, April 2005.
[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.
skipping to change at page 19, line 16 skipping to change at page 19, line 17
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
Alibaba
Chaoyang Dist. Beijing Chaoyang Dist. Beijing
P.R. China P.R. China
Email: Dacheng.zdc@alibaba-inc.com
Email: dacheng.zhang@gmail
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
 End of changes. 52 change blocks. 
95 lines changed or deleted 92 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/