Internet DRAFT - draft-ietf-nvo3-security-requirements
draft-ietf-nvo3-security-requirements
Network Working Group S. Hartman
Internet Draft Painless Security
Intended status: Informational D. Zhang
Expires: June 15, 2016
M. Wasserman
Painless Security
Z. Qiang
Ericsson
M. Zhang
Huawei
December 15, 2015
Security Requirements of NVO3
draft-ietf-nvo3-security-requirements-06
Abstract
The draft describes a list of essential requirements in order to
benefit the design of NVO3 security solutions. In addition, this
draft introduces the candidate techniques which could be used to
construct a security solution fulfilling these security requirements.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute working
documents as Internet-Drafts. The list of current Internet-Drafts is
at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on June 15, 2016.
Hartman, et al. Expires June 15, 2016 [Page 1]
Internet-Draft NVO3 security December 2015
Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction...................................................3
2. Terminology....................................................3
3. NVO3 Overlay Architecture......................................4
4. Threat Model...................................................5
4.1. Capabilities of Outsiders.................................5
4.2. Capabilities of Insiders..................................5
4.3. Capabilities of Malicious TSes............................6
5. Scope..........................................................6
6. Security Requirements..........................................7
6.1. Control Plane of NVO3 Overlay.............................7
6.2. NVE-NVE Data Plane.......................................11
6.3. NVE-Hypervisor Data Plane................................13
7. Candidate Techniques..........................................14
7.1. Entity Authentication....................................15
7.2. Packet Level Security....................................15
7.3. Authorization............................................15
7.4. Automated Key Management.................................16
8. IANA Considerations...........................................16
9. Security Considerations.......................................16
10. Acknowledgements.............................................17
11. References...................................................17
11.1. Normative References....................................17
11.2. Informative References..................................17
Authors' Addresses...............................................19
Hartman, et al. Expires June 15, 2016 [Page 2]
Internet-Draft NVO3 security December 2015
1. Introduction
As described in [RFC7365], the NVO3 framework is intended to aid in
standardizing protocols and mechanisms to support large-scale multi-
tenancy data centers. In such kind data center, security is a key
issue which needs to be considered during the network design. This
document discusses the security risks that a NVO3 network may
encounter and tries to provide a list of essential security
requirements that needs to be fulfilled. In addition, this document
introduces the candidate techniques which could be potentially used
to construct a security solution fulfilling the NVO3 security
requirements.
The remainder of this document is organized as follows. Section 2
introduces several key terms used in this memo. Section 3 gives a
brief introduction of the NVO3 network architecture. Section 4
discusses the attack model of this document. Section 5 lists the
scope of the security considerations of this document. Section 6
provides a list of security requirements as well as the associated
justifications. In Section 7, the candidate techniques are
introduced.
2. Terminology
This document uses the same terminology as defined in the NVO3
Framework document [RFC7365] and the Hypervisor to NVE Control Plane
Requirements document [I-D.ietf-nvo3-hpvr2nve-cp-req]. The Followings
are the additional terminologies that are used by this document.
Hypervisor: This memo uses the term "hypervisor" throughout when
describing requirements at the Split-NVE scenario where part of the
NVE functionality is off-loaded to a separate device from the
"hypervisor" that contains a VM connected to a VN. In this context,
the term "hypervisor" is meant to cover any device type where part of
the NVE functionality is off-loaded in this fashion, e.g. a Network
Service Appliance, Linux Container.
NVO3 device: In this memo, the devices (e.g., NVE and NVA) work
cooperatively to provide NVO3 overlay functionalities are referred as
NVO3 devices.
Hartman, et al. Expires June 15, 2016 [Page 3]
Internet-Draft NVO3 security December 2015
3. NVO3 Overlay Architecture
+--------+ +--------+
| Tenant +--+ +----| Tenant |
| System | | (') | System |
+--------+ | ................. ( ) +--------+
| +---+ +---+ (_)
+--|NVE|---+ +---|NVE|-----+
+---+ | | +---+
/ . +-----+ .
/ . +--| NVA | .
/ . | +-----+ .
| . | .
| . | L3 Overlay +--+--++--------+
+--------+ | . | Network | NVE || Tenant |
| Tenant +--+ . | | || System |
| System | . \ +---+ +--+--++--------+
+--------+ .....|NVE|.........
+---+
|
|
=====================
| |
+--------+ +--------+
| Tenant | | Tenant |
| System | | System |
+--------+ +--------+
Figure 1 : Generic Reference Model for DC Network Virtualization
Overlays [RFC7365]
This figure illustrates a generic reference model for NVO3 overlay
where NVEs provide a logical L2/L3 interconnect for the TSes that
belong to a specific tenant network over a L3 networks. A packet
received from a tenant system is encapsulated by the ingress NVE.
Then encapsulated packet is then sent to the remote NVE through a
proper tunnel. When reaching the egress NVE of the tunnel, the packet
is decapsulated and forwarded to the target tenant system. The
address mappings and other related information are distributed to the
NVEs by a logically centralized Network Virtualization Authority
(NVA).
Hartman, et al. Expires June 15, 2016 [Page 4]
Internet-Draft NVO3 security December 2015
4. Threat Model
To benefit describing the threats a NVO3 network may have to face,
the attacks considered in this document are classified into three
categories: the attacks from compromised NVO3 devices (inside
attacks), the attacks from compromised tenant systems, and the
attacks from underlying networks (outside attacks).
The adversaries performing the first type of attack are called as
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 (e.g., a
malicious tenant, or an attacker who has compromised a virtual
machine of an innocent tenant) has got certain privileges in changing
the configuration or software of tenant systems and attempts to
manipulate the controlled tenant systems to interfere with the normal
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.
4.1. Capabilities of Outsiders
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:
A) Analyze the traffic pattern within the network by performing
passive attacks;
B) Disrupt the network connectivity or degrade the network service
quality (e.g., by performing DoS attacks); or
C) Access the contents of the data/control packets which are not
properly encrypted.
4.2. Capabilities of Insiders
Besides intercepting packets, deleting packets, and/or inserting
bogus packets, an inside attacker may use already obtained privilege
to,
A) Interfere with the normal operations of the overlay as a legal NVO3
device, by sending packets containing invalid information or with
improper frequencies;
Hartman, et al. Expires June 15, 2016 [Page 5]
Internet-Draft NVO3 security December 2015
B) Perform spoofing attacks and impersonate another legal NVO3 device
to communicate with victims using the cryptographic information it
obtained; and
C) Access the contents of the data/control packets if they are
encrypted with the keys held by the attacker.
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:
A) Interfere with the normal operations of the overlay as a legal TS,
by sending packets containing invalid information or with improper
frequencies to NVEs;
B) 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
C) Access the contents of the data/control packets if they are
encrypted with the keys held by the attacker.
5. Scope
The following security issues are in the scope of the NVO3 security
requirement consideration of this document:
A) The NVO3 connections may be considered as secured if there is a
security solution supported by the underlying network. However such
kind security solution normally only can protect the NVO3 network
from outsider attacker.
B) During the design of a security solution for a NVO3 network, the
attacks raised from compromised NVEs and hypervisors needs to be
considered.
C) It is reasonable to consider the conditions where the network
connecting TSes and NVEs is accessible to outside attackers.
The following security issues are out of scope of the NVO3 security
requirement consideration of this document:
A) In this document, it is assumed that security protocols,
algorithms, and implementations provide the security properties for
Hartman, et al. Expires June 15, 2016 [Page 6]
Internet-Draft NVO3 security December 2015
which they are designed; attacks depending on a failure of this
assumption are out of scope. For instance, an attack caused by a
weakness in a cryptographic algorithm is out of scope, while an
attack caused by failure to use confidentiality when
confidentiality is a security requirement is in scope.
B) An attacker controlling an underlying network device may break the
communication of the overlays by discarding or delaying the
delivery of the packets passing through it. The security
consideration to prevent this type of attack is out of scope of
this document.
C) NVAs are centralized servers and play a critical role in NVO3
overlay network. 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. The security requirements discussed in this document is to
protect a NVA from any security risk. And if a NVA is attacked, it
should be detected. However, this document does not consider how to
deal with the problem after a NVA is compromised.
D) Because this document only tries to provide the most essential high
level requirements, some important issues in designing concept
security mechanisms are not covered in the requirements. Such
issues include:
- How to manage keys/credentials during their life periods
- How to support algorithm agility
- How to provide accountability
- How to secure the management interfaces
- Use underlying security protocols versus design integrated
security extensions
6. Security Requirements
6.1. Control Plane of NVO3 Overlay
In this section, the security requirements associated with following
control plane are described:
- The NVE-NVA control plane: allows a NVE to obtain information
about the location and status of other TSs with which it needs to
communicate; to provide updates to the NVA about the attached TSs;
Hartman, et al. Expires June 15, 2016 [Page 7]
Internet-Draft NVO3 security December 2015
and to report any communication errors. In this case, the term
"NVO3 device" is referring to a NVA or a NVE.
- The NVA-NVA control plane: 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. In this case, the term "NVO3
device" is referring to a NVA.
- The NVE-NVE control plane: As specified in [RFC7365], in order to
obtain reachability information, NVEs may exchange information
directly between themselves via a control-plane protocol. In this
case, the term "NVO3 device" is referring to a NVE.
- The NVE-Hypervisor control plane: In the Split-NVE scenario, the
NVE and hypervisors may also need to exchange signaling packets
over network in order to facilitate, e.g., VM online detection, VM
migration detection, or auto-provisioning/service discovery as
described in [RFC7365]. In this case, the term "NVO3 device" is
referring to a Hypervisor or a NVE.
REQ 1. The security solution for NVO3 MUST enable the two NVO3
devices to mutually authenticate each other before exchanging
any control packets.
Entity authentication can protect a NVO3 device against imposter
attacks and then reduce the risk of DoS / DDoS 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. More detailed discussions are provided
in Section 6.1.
REQ 2. The security solution of NVO3 MUST be able to provide
integrity protection, replay protection, and packet origin
authentication for the control packets exchanged between two
NVO3 devices.
Message authentication is performed on each incoming packet. Packet
level security protection can prevent an attacker from illegally
interfere with the normal operations of NVO3 device by injecting
bogus control packets into the network. Through message
authentication, the NVO3 device receiving a control packet can verify
whether the packet is generated by a legitimate NVO3 device, is not
antique, and is not tampered during transportation.
Such protection must be deployed if there is any possibility that the
control packets could be accessed by outside attackers. This
Hartman, et al. Expires June 15, 2016 [Page 8]
Internet-Draft NVO3 security December 2015
protection can prevent an attacker locating in the middle between the
NVO3 devices and modifying the information in the control packet so
as to redirect the traffic as wished. In addition, with the support
of properly distributed keys, these level protections can also
benefit the detection of spoofing attacks raised from insiders.
REQ 3. The security solution of a NVO3 network SHOULD provide
confidentiality protection for the control packets exchanged
between two NVO3 devices.
On many occasions, the control packets can be transported in
plaintext. However, if the information contained within the control
packets is considered to be sensitive or valuable, it is recommended
to encrypt the packets in order to prevent outsiders from accessing
the sensitive data, especially when the underlying network is not
secured enough. Note that encryption will impose additional overhead
in processing control packets and make NVO3 devices more vulnerable
to DoS / DDoS attacks.
REQ 4. Node authorization procedure MUST be supported before
processing any received control packets in the NVO3 device
When receiving a control packet, besides authentication,
authorization needs to be carried out by the receiver to identify the
role that the packet sender acts as in the overlay and then assess
the sender's privileges. If a compromised NVO3 device tries to
illegally elevate its privilege, it will be detected and rejected.
For instance, a compromised NVO3 device may use its credentials to
communicate with other NVEs as a NVA, or attempting to access or
update the mapping information of the VNs which it is not authorized
to serve.
REQ 5. The security solution of NVO3 SHOULD be able to provide
distinct cryptographic keys for each NVO3 device to protect the
unicast control traffics exchanged between different NVO3
devices respectively.
During the exchange of control packets, keys are critical in
authenticating the packet senders. The purpose of this requirement is
to provide a basic capability to confine the damage caused by inside
attacks. After compromising a NVO3 device, an attacker may be able
to use the keys it obtained to exchange control traffics with other
NVO3 devices. But it will not be able to use the keys it obtained to
breach the security of the control traffics exchanged between other
NVO3 devices.
Hartman, et al. Expires June 15, 2016 [Page 9]
Internet-Draft NVO3 security December 2015
REQ 6. The security solution of NVO3 SHOULD be able to assign
distinct cryptographic group keys for each multicast group to
protect the multicast packets exchanged among the NVO3 devices
within the group.
In order to provide an essential packet level security protection
specified for integrity and confidentiality, at least one group key
may need to be shared among the NVO3 devices in a same multicast
group. It is recommended to use different keys for different
multicast groups.
REQ 7. The resistance at DOS/DDOS attack MUST be considered in the
design of NVO3 control plane
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
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 NVO3. The following requirements, but not limited to this
listed, are used to benefit the migration of DoS/DDoS issue.
REQ 7.a. A NVO3 device MUST have a frequency limitation at
sending its control packets and processing any received
control packets.
Without this limitation, an attacker can attempt to perform DoS /
DDoS attacks to exhaust the limited computing and memory resources of
a target NVO3 device by manipulating a compromised NVO3 device to
generate a significant amount of control plane packets in a short
period.
REQ 7.b. The amplification effect MUST be avoided
A distributed denial-of-service attack may involve sending forged
requests of some type to a very large number of NVO3 devices that
will reply to the requests. If in certain conditions, the responses
generated by a NVO3 device are a much longer process than the
received requests. An attacker may take advantage of this
amplification effect procedure, which the NVO3 device is used as a
reflector to carry out DoS / DDoS attacks towards a victim NVO3
device.
For instance, the attacker may send request messages to a NVO3 device
with a spoofed source address set to the targeted victim. In that
case, all the replies generated by the NVO3 device will be sent (and
flooded) to the target. Another example is that as discussed in [I-
Hartman, et al. Expires June 15, 2016 [Page 10]
Internet-Draft NVO3 security December 2015
D.ietf-nvo3-arch], a NVE may wish to query the NVA about individual
mapping when receiving a packet with unknown destination address.
This query procedure may also be triggered at ARP / ND message
handling or when NVE-NVE interaction message is received. An attacker
may take advantage of this query procedure which the NVE is used as a
reflector to carry out DoS / DDoS attacks towards the NVA.
Specifically, the attacker can concurrently send out a large amount
of spoofed short request messages to multiple NVO3 devices which the
amplification effect can be enlarged which may overwhelm the victim's
processing capability quickly.
REQ 8. The security solution of a NVO3 SHOULD be able to provide
different security levels of protections for the control
traffics and data traffics exchanged between NVO3 devices.
In NVE-NVE interface and NVE-Hypervisor interface, the same security
solution may be used to protect both the control plane and data plane
traffic. In many cases, the control and data traffics between NVO3
devices may be transported over the same path or even within the same
security channel. However, the control traffics and data traffics may
have different levels of security sensitivity. Therefore, the
protection on the traffic needs be distinguished. In this case, the
security solution may need to provide different security channels for
control traffics and data traffics respectively and protect the data
traffics and control traffics exchanged between NVO3 devices with
different keys and ciphers.
6.2. NVE-NVE Data Plane
As specified in [RFC7365], a NVO3 overlay needs to generate tunnels
between NVEs for data packet transportation. When a data packet
reaches the boundary of an overlay, the ingress NVE will encapsulate
the packet and forward it to the destination egress NVE through a
proper tunnel.
REQ 9. The security solution for NVO3 MAY enable two NVEs to
mutually authenticate each other before establishing a tunnel
for data transportation.
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.
In order to protect the data packets transported over the overlay
against the attacks raised from the underlying network, the NVO3
Hartman, et al. Expires June 15, 2016 [Page 11]
Internet-Draft NVO3 security December 2015
overlay needs to provide essential security protection for data
packets.
REQ 10. The security solution of NVO3 SHOULD be able to provide
integrity protection, replay protection, and packet origin
authentication for data traffics exchanged between NVEs.
This requirement is used to prevent an attacker who has compromised
underlying network devices on the path from replaying antique packets
or injecting bogus data packets without being detected.
Such protection must be deployed if there is any possibility that the
data packets could be accessed by outside attackers. This protection
can prevent an attacker locating in the middle between the NVEs and
modifying the tunnel address information in the data packet header so
as to redirect the data traffic as wished.
REQ 11. The security solution of NVO3 MAY be able to provide
confidentiality protection for data traffics exchanged between
NVEs, if information leaking is a concern.
If TS data traffic privacy is required, the TS data traffic needs to
be encrypted when being transported within the overlay. In practice,
tenants may select end-to-end security solutions to encrypt their
sensitive data during transportation. Therefore this confidentiality
requirement for data plane is an optional requirement.
REQ 12. The security solution of NVO3 SHOULD be able to assign
different cryptographic keys to protect the unicast tunnels
between NVEs respectively.
This requirement is used to confine the damage caused by inside
attacks. When different tunnels secured with different keys, the
compromise of a key in a tunnel will not affect the security of other
tunnels. In addition, if the key used to protect a tunnel is only
shared by the NVEs on the both sides, the egress NVE receiving a data
packet is able to distinctively prove the identity of the ingress NVE
encapsulating the data packet during the message authentication.
REQ 13. If there are multicast packets, the security solution of
NVO3 SHOULD be able to assign distinct cryptographic group keys
to protect the multicast packets exchanged among the NVEs within
different multicast groups.
In NVO3, a NVE may need to support data plane multicast capability.
In order to provide an essential packet level security protection
(including authentication, integrity, confidentiality) for the
Hartman, et al. Expires June 15, 2016 [Page 12]
Internet-Draft NVO3 security December 2015
multicast packets transferred within the group, at least one group
key may need to be shared among the NVEs of the same multicast group.
It is recommended to deploy different keys for different multicast
groups, in order to confine the insider attacks on NVEs.
REQ 14. Upon receiving a data packet, an egress NVE MUST be able
to verify whether the packet is sent from a proper ingress NVE
which is authorized to forward that packet.
In cooperation with authentication, authorization enables an egress
NVE to detect the data packets which violate certain security
policies, even when they are forwarded from a legal NVE. For
instance, if the remote NVE is not authorized to forward data packet
of a given VN, the packet needs to be detected and discarded without
processing. Note that the detection of an invalid packet may not
indicate that the system is under a malicious attack. Mis-
configuration or byzantine failure of a NVE may also result in such
invalid packets.
6.3. NVE-Hypervisor Data Plane
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
and hypervisor. One simple deployment scenario may have a simple L2
Ethernet link. A more complicated scenario may have the server and
NVE separated by a bridged access network, such as when the NVE
resides on a ToR, with an embedded switch residing between servers
and the ToR.
In any of above deployment scenarios, the data link between NVE and
hypervisor may be potentially accessible to attackers, e.g. with a
shared link. In that case, security solutions, including integrity
protection and confidentiality protection, may be needed to secure
the data link.
REQ 15. The security solution of NVO3 SHOULD be able to provide
integrity protection, replay protection and origin
authentication for the data packets exchanged between a NVE and
a hypervisor.
Packet level security protection can prevent an attacker from
illegally interfere with the normal operations of NVEs and
hypervisors by injecting bogus packets into the network. Because it
is assumed that the network connecting the NVE and the hypervisor is
potentially accessible to attackers, security solutions need to
prevent an attacker locating in the middle between the NVE and the
Hartman, et al. Expires June 15, 2016 [Page 13]
Internet-Draft NVO3 security December 2015
hypervisor from modifying the information in the data packet headers
so as to redirect the traffic as wished.
REQ 16. The security solution of a NVO3 network MAY provide
confidentiality protection for the data traffics exchanged
between a NVE and a hypervisor.
If TS data packet privacy is required, the data packet needs to be
encrypted. The security solution of a NVE network may need to provide
confidentiality for the data packets exchanged between a NVE and a
hypervisor if they have to use an insecure network to transport their
data packet.
REQ 17. The security solution of a NVO3 network MAY be able to
provide different cryptographic keys to secure the unicast data
traffic exchanged between different hypervisors and their NVEs
respectively.
This requirement is used to benefit the damage confinement of inside
attacks. For instance, data traffic may be forwarded over a shared
link between a NVE and a hypervisor. In that case, the compromise of
a hypervisor or a NVE will not be able to affect the security of data
traffics exchanged between different hypervisors and their NVEs.
REQ 18. The security solution of NVO3 MAY be able to assign
distinct cryptographic group keys to protect the multicast
traffic exchanged between different hypervisors and their NVEs
respectively within different multicast groups.
If there are multicast data traffic between hypervisors and their
NVE, in order to provide an essential packet level security
protection (including authentication, integrity, confidentiality) for
the multicast packets transferred within the multicast group, at
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
different keys for different multicast groups, in order to confine
the insider attacks on the hypervisors and their NVE.
7. Candidate Techniques
This section introduces the techniques which can potentially be used
to fulfill the security requirements introduced in Section 6.
Hartman, et al. Expires June 15, 2016 [Page 14]
Internet-Draft NVO3 security December 2015
7.1. Entity Authentication
Entity authentication is normally performed as a part of automated
key management, and a successful authentication may result in the key
materials used in subsequent communications.
In the circumstance where no authentication protocols are applied,
the communicating entities could use message authentication
mechanisms to verify each other's identity.
The widely adopted protocols supporting entity authentication
include: IKE [RFC2409], IKEv2 [RFC5996], 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.
7.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], or MACsec [802.1AE]. 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.
7.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 NVO3
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
Hartman, et al. Expires June 15, 2016 [Page 15]
Internet-Draft NVO3 security December 2015
attacks and increasing the difficulties of DoS / DDoS attacks
targeting at the security protocol implementations.
For instance, a NVE may maintain an authorization NVE table. This
table may be distributed by a trusted entity, e.g. NVA, in
combination with the inner-outer address mapping table. And NVE may
use this table to filter the received control / data packets over
NVE-NVE interface. The NVE may effectively drop any packets received
from an unauthorized NVE before processing it, e.g.
cryptographically verification procedure.
7.4. Automated Key Management
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.
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.
Hartman, et al. Expires June 15, 2016 [Page 16]
Internet-Draft NVO3 security December 2015
10. Acknowledgements
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
cannot thank all contributors, some have played an especially
prominent role. The followings have provided essential input:
Melinda Shore and Makan Pourzandi.
11. References
11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
11.2. Informative References
[I-D.ietf-nvo3-arch] Black, D., Narten, T., et al, "An Architecture
for Overlay Networks (NVO3)", draft-narten-nvo3-arch, work
in progress.
[I-D.ietf-ipsecme-ad-vpn-problem] Manral, V. and S. Hanna, "Auto
Discovery VPN Problem Statement and Requirements", draft-
ietf-ipsecme-ad-vpn-problem-09 (work in progress), July
2013.
[I-D.ietf-nvo3-hpvr2nve-cp-req] Yizhou, L., Yong, L., Kreeger, L.,
Narten, T., and D. Black, "Hypervisor to NVE Control Plane
Requirements", draft-ietf-nvo3-hpvr2nve-cp-req-01 (work in
progress), November 2014.
[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,
"Multicast Security (MSEC) Group Key Management
Architecture", RFC 4046, April 2005.
[RFC4137] Vollbrecht, J., Eronen, P., Petroni, N., and Y. Ohba,
"State Machines for Extensible Authentication Protocol
(EAP) Peer and Authenticator", RFC 4137, August 2005.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December
2005.
Hartman, et al. Expires June 15, 2016 [Page 17]
Internet-Draft NVO3 security December 2015
[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
(TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, "Internet
Key Exchange Protocol Version 2 (IKEv2)", RFC 5996,
September 2010.
[RFC7364] Narten, T., Gray, E., Black, D., Fang, L., Kreeger, L., and
M. Napierala, "Problem Statement: Overlays for Network
Virtualization", RFC 7364, October 2014.
[RFC7365] Lasserre, M., Balus, F., Morin, T., Bitar, N., and Y.
Rekhter, "Framework for Data Center (DC) Network
Virtualization", RFC 7365, October 2014.
[802.1AE] 802.1AE - Media Access Control (MAC) Security
Hartman, et al. Expires June 15, 2016 [Page 18]
Internet-Draft NVO3 security December 2015
Authors' Addresses
Sam Hartman
Painless Security
356 Abbott Street
North Andover, MA 01845
USA
Email: hartmans@painless-security.com
URI: http://www.painless-security.com
Dacheng Zhang
Chaoyang Dist. Beijing
P.R. China
Email: dacheng.zhang@gmail
Margaret Wasserman
Painless Security
356 Abbott Street
North Andover, MA 01845
USA
Phone: +1 781 405 7464
Email: mrw@painless-security.com
URI: http://www.painless-security.com
Zu Qiang
Ericsson
8400 Decarie Blvd.
Town of Mount Royal, QC, H4P 2N2
Canada
Phone: +1 514 345 7900 x47370
Email: Zu.Qiang@ericsson.com
Mingui Zhang
Huawei Technologies
No. 156 Beiqing Rd. Haidian District,
Beijing 100095
P.R. China
Email: zhangmingui@huawei.com
Hartman, et al. Expires June 15, 2016 [Page 19]
