Internet DRAFT - draft-mglt-nvo3-geneve-security-requirements
draft-mglt-nvo3-geneve-security-requirements
NVO3 D. Migault
Internet-Draft Ericsson
Intended status: Informational S. Boutros
Expires: September 1, 2019 D. Wings
VMware, Inc.
S. Krishnan
Kaloom
February 28, 2019
Geneve Security Requirements
draft-mglt-nvo3-geneve-security-requirements-06
Abstract
The document defines the security requirements to protect tenants
overlay traffic against security threats from the NVO3 network
components that are interconnected with tunnels implemented using
Generic Network Virtualization Encapsulation (Geneve).
The document provides two sets of security requirements: 1.
requirements to evaluate the data plane security of a given
deployment of Geneve overlay. Such requirements are intended to
Geneve overlay provider to evaluate a given deployment.
2. requirement a security mechanism need to fulfill to secure any
deployment of Geneve overlay deployment
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 https://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 September 1, 2019.
Migault, et al. Expires September 1, 2019 [Page 1]
Internet-Draft Geneve Security Requirements February 2019
Copyright Notice
Copyright (c) 2019 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
(https://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. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Security Threats . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Passive Attacks . . . . . . . . . . . . . . . . . . . . . 6
4.2. Active Attacks . . . . . . . . . . . . . . . . . . . . . 7
5. Requirements for Security Mitigations . . . . . . . . . . . . 8
5.1. Protection Against Traffic Sniffing . . . . . . . . . . . 8
5.1.1. Operational Security Requirements . . . . . . . . . . 9
5.1.2. Geneve Security Requirements . . . . . . . . . . . . 10
5.2. Protecting Against Traffic Injection . . . . . . . . . . 10
5.2.1. Operational Security Requirements . . . . . . . . . . 12
5.2.2. Geneve Security Requirements . . . . . . . . . . . . 13
5.3. Protecting Against Traffic Redirection . . . . . . . . . 13
5.4. Protecting Against Traffic Replay . . . . . . . . . . . . 14
5.4.1. Geneve Security Requirements . . . . . . . . . . . . 14
5.4.2. Geneve Security Requirements . . . . . . . . . . . . 15
5.5. Security Management . . . . . . . . . . . . . . . . . . . 15
5.5.1. Operational Security Requirements . . . . . . . . . . 15
5.5.2. Geneve Security Requirements . . . . . . . . . . . . 15
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
7. Security Considerations . . . . . . . . . . . . . . . . . . . 16
8. Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . 16
8.1. DTLS . . . . . . . . . . . . . . . . . . . . . . . . . . 16
8.1.1. Operational Security Requirements . . . . . . . . . . 16
8.1.2. Geneve Security Requirements . . . . . . . . . . . . 18
8.2. IPsec . . . . . . . . . . . . . . . . . . . . . . . . . . 20
8.2.1. Operational Security Requirements . . . . . . . . . . 20
8.2.2. Geneve Security Requirements . . . . . . . . . . . . 21
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 23
Migault, et al. Expires September 1, 2019 [Page 2]
Internet-Draft Geneve Security Requirements February 2019
10.1. Normative References . . . . . . . . . . . . . . . . . . 23
10.2. Informative References . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25
1. Requirements Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described BCP 14
[RFC2119] [RFC8174] when, and only when, they appear in all capitals,
as shown here.
2. Introduction
The network virtualization overlay over Layer 3 (NVO3) as depicted in
Figure 1, allows an overlay cloud provider to provide a logical L2/L3
interconnect for the Tenant Systems TSes that belong to a specific
tenant network. A packet received from a TS is encapsulated by the
ingress Network Virtualization Edge (NVE). The encapsulated packet
is then sent to the remote NVE through a tunnel. When reaching the
egress NVE of the tunnel, the packet is decapsulated and forwarded to
the target TS. The L2/L3 address mappings to the remote NVE(s) are
distributed to the NVEs by a logically centralized Network
Virtualization Authority (NVA) or using a distributed control plane
such as Ethernet-VPN. In a datacenter, the NVO3 tunnels can be
implemented using Generic Network Virtualization Encapsulation
(Geneve) [I-D.ietf-nvo3-geneve]. Such Geneve tunnels establish NVE-
to-NVE communications, may transit within the data center via Transit
device. The Geneve tunnels overlay network enable multiple Virtual
Networks to coexist over a shared underlay infrastructure, and a
Virtual Network may span a single data center or multiple data
centers.
The underlay infrastructure on which the multi-tenancy overlay
networks are hosted, can be owned and provided by an underlay
provider who may be different from the overlay cloud provider.
Migault, et al. Expires September 1, 2019 [Page 3]
Internet-Draft Geneve Security Requirements February 2019
+--------+ +--------+
| 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 Network Virtualization Overlays
[RFC7365]
This document discusses the security risks that a Geneve based NVO3
network may encounter. In addition, this document lists the
requirements to protect the Geneve packet components defined in
[I-D.ietf-nvo3-geneve] that include the Geneve tunnel IP and UDP
header, the Geneve Header, Geneve options, and inner payload.
The document provides two sets of security requirements:
1. SEC-OP: requirements to evaluate a given deployment of Geneve
overlay. Such requirements are intended to Geneve overlay
provider to evaluate a given deployment. Security of the Geneve
packet may be achieved using various mechanisms. Typically, some
deployments may use a limited subset of the capabilities provided
by Geneve and rely on specific assumptions. Given these
specificities, the secure deployment of a given Geneve deployment
may be achieved reusing specific mechanisms such as for example
DTLS [RFC6347] or IPsec [RFC4301]. On the other hand, the
definition of a security mechanisms that enables to secure any
Geneve deployment requires the design of a Geneve specific
Migault, et al. Expires September 1, 2019 [Page 4]
Internet-Draft Geneve Security Requirements February 2019
mechanism. Note that the security s limited to the security of
the data plane only. Additional requirements for the control
plan MAY be considered in [I-D.ietf-nvo3-security-requirements].
A given Geneve deployment will be considered secured when
matching with all SEC-OP requirements does not raises any
concern. As such the given deployment will be considered passing
SEC-OP requirements that are not applicable.
2. SEC-GEN: requirements a security mechanism need to fulfill to
secure any deployment of Geneve overlay deployment. Such
mechanism may require the design of a specific solution. In the
case new protocol needs to be design, the document strongly
recommend to re-use existing security protocols like IP Security
(IPsec) [RFC4301] and Datagram Transport Layer Security (DTLS)
[RFC6347], and existing encryption algorithms (such as
[RFC8221]), and authentication protocols. A given candidate for
a security mechanism will be considered as valid when matching
with all SEC-GEN requirements does not raise any concern. In
other words, at least all MUST status are met.
This document assumes the following roles are involved: - Tenant:
designates the entity that connects various systems within a single
virtualized network. The various system can typically be containers,
VMs implementing a single or various functions.
- Geneve Overlay Provider: provides the Geneve overlay that
seamlessly connect the various Tenant Systems over a given
virtualized network.
- Infrastructure Provider: provides the infrastructure that runs the
Geneve overlay network as well as the Tenant System. A given
deployment may consider different infrastructure provider with
different level of trust. Typically the Geneve overlay network may
use a public cloud to extend the resource of a private cloud.
Similarly, a edge computing may extend its resources using resource
of the core network.
Tenant, Geneve Overlay Provider and Infrastructure Provider can be
implemented by a single or various different entities with different
level of trust between each other. The simplest deployment may
consists in a single entity running its systems in its data center
and using Geneve in order to manage its internal resources. A more
complex use case may consider that a Tenant subscribe to the Geneve
Overlay Provider which manage the virtualized network over various
type of infrastructure. The trust between the Tenant, Geneve Overlay
Provider and Infrastructure Provider may be limited.
Given the different relations between Tenant, Geneve Overlay Provider
and Infrastructure Provider, this document aims providing
requirements to ensure: 1. The Geneve Overlay Provider delivers
Migault, et al. Expires September 1, 2019 [Page 5]
Internet-Draft Geneve Security Requirements February 2019
tenant payload traffic (Geneve inner payload) and ensuring privacy
and integrity. 2. The Geneve Overlay Provider provides the
necessary means to prevent injection or redirection of the Tenant
traffic from a rogue node in the Geneve overlay network or a rogue
node from the infrastructure. 3. The Geneve Overlay Provider can
rely on the Geneve overlay in term of robustness and reliability of
the signaling associated to the Geneve packets (Geneve tunnel header,
Geneve header and Geneve options) in order to appropriately manage
its overlay.
3. Terminology
This document uses the terminology of [RFC8014], [RFC7365] and
[I-D.ietf-nvo3-geneve].
4. Security Threats
This section considers attacks performed by NVE, network devices or
any other devices using Geneve, that is when the attackers knowing
the details of the Geneve packets can perform their attacks by
changing fields in the Geneve tunnel header, base header, Geneve
options and Geneve inner payload. Attacks related to the control
plane are outside the scope of this document. The reader is
encouraged to read [I-D.ietf-nvo3-security-requirements] for a
similar threat analysis of NVO3 overlay networks.
Threats include traffic analysis, sniffing, injection, redirection,
and replay. Based on these threats, this document enumerates the
security requirements.
Threats are divided into two categories: passive attack and active
attack.
Threats are always associated with risks and the evaluation of these
risks depend among other things on the environment.
4.1. Passive Attacks
Passive attacks include traffic analysis (noticing which workloads
are communicating with which other workloads, how much traffic, and
when those communications occur) and sniffing (examining traffic for
useful information such as personally-identifyable information or
protocol information (e.g., TLS certificate, overlay routing
protocols).
Passive attacks may also consist in inferring information about a
virtualized network or some Tenant System from observing the Geneve
traffic. This could also involve the correlation between observed
Migault, et al. Expires September 1, 2019 [Page 6]
Internet-Draft Geneve Security Requirements February 2019
traffic and additional information. For example, a passive network
observer can determine two virtual machines are communicating by
manipulating activity or network activity of other virtual machines
on that same host. For example, the attacker could control (or be
otherwise aware of) network activity of the other VMs running on the
same host, and deduce other network activity is due to a victim VM.
A rogue element of the overlay Geneve network under the control of an
attacker may leak and redirect the traffic from a virtual network to
the attacker for passive monitoring [RFC7258].
Avoiding leaking information is hard to enforced. The security
requirements provided in section {{sniffing} expect to mitigate such
attacks by lowering the consequences, typically making leaked data
unusable to an attacker.
4.2. Active Attacks
Active attacks involve modifying Geneve packets, injecting Geneve
packets, or interfering with Geneve packet delivery (such as by
corrupting packet checksum). Active attack may target the Tenant
System or the Geneve overlay.
There are multiple motivations to inject illegitimate traffic into a
tenants network. When the rogue element is on the path of the TS
traffic, it may be able to inject and receive the corresponding
messages back. On the other hand, if the attacker is not on the path
of the TS traffic it may be limited to only inject traffic to a TS
without receiving any response back. When rogue element have access
to the traffic in both directions, the possibilities are only limited
by the capabilities of the other on path elements - Transit device,
NVE or TS - to detect and protect against the illegitimate traffic.
On the other hand, when the rogue element is not on path, the surface
for such attacks remains still quite large. For example, an attacker
may target a specific TS or application by crafting a specific packet
that can either generate load on the system or crash the system or
application. TCP syn flood typically overload the TS while not
requiring the ability to receive responses. Note that udp
application are privileged target as they do not require the
establishment of a session and are expected to treat any incoming
packets.
Traffic injection may also be used to flood the virtual network to
disrupt the communications between the TS or to introduce additional
cost for the tenant, for example when pricing considers the traffic
inside the virtual network. The two latest attacks may also take
advantage of applications with a large factor of amplification for
their responses as well as applications that upon receiving a packet
Migault, et al. Expires September 1, 2019 [Page 7]
Internet-Draft Geneve Security Requirements February 2019
interact with multiple TS. Similarly, applications running on top of
UDP are privileged targets.
Note also that an attacker that is not able to receive the response
traffic, may use other channels to evaluate or measure the impact of
the attack. Typically, in the case of a service, the attacker may
have access, for example, to a user interface that provides
indication on the level of disruption and the success of an attack,
Such feed backs may also be used by the attacker to discover or scan
the network.
Preventing traffic to cross virtual networks, reduce the surface of
attack, but rogue element main still perform attacks within a given
virtual network by replaying a legitimate packet. Some variant of
such attack also includes modification of unprotected parts when
available in order for example to increase the payload size.
5. Requirements for Security Mitigations
The document assumes that Security protocols, algorithms, and
implementations provide the security properties for which they are
designed, an attack caused by a weakness in a cryptographic algorithm
is out of scope. The algorithm used MUST follow the cryptographic
guidance such as [RFC8247], [RFC8221] or [RFC7525]. In this context,
when the document mentions encryption, it assumes authenticated
encryption.
Protecting network connecting TSes and NVEs which could be accessible
to outside attackers is out of scope.
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.
Securing communication between NVAs and NVEs is out of scope.
Selectively providing integrity / authentication, confidentiality /
encryption of only portions of the Geneve packet is in scope. This
will be the case if the Tenant Systems uses security protocol to
protect its communications.
5.1. Protection Against Traffic Sniffing
The inner payload, unless protection is provided by the Tenant System
reveals the content of the communication. This may be mitigate by
the Tenant using application level security such as, for example JSON
Web Encryption [RFC7516] or transport layer security such as DTLS
Migault, et al. Expires September 1, 2019 [Page 8]
Internet-Draft Geneve Security Requirements February 2019
[RFC6347] or TLS [RFC8446] or IPsec/ESP [RFC4303]. However none of
these security protocols are sufficient to protect the entire inner
payload. IPsec/ESP still leave in clear the optional L2 layer
information as well as the IP addresses and some IP options. In
addition to these pieces of information, the use of TLS or DTLS
reveals the transport layer protocol as well as ports. As a result,
the confidentiality protection of the inner packet may be handled
either entirely by the Geneve Overlay Provider, or partially by the
Tenant or handled by both the Tenant and the Geneve Overlay Provider.
The Geneve Header contains information related to the Geneve
communications or metadata designated as Geneve Information. Geneve
Information is carried on the Geneve Outer Header, the Geneve Header
(excluding Geneve Options) as well as in the Geneve Options. Geneve
Information needs to be accessed solely by a NVE or transit device
while other Geneve Information may need to be accessed by other
transit devices. More specifically, a subset of the information
contained in the Geneve Header (excluding Geneve Options) as well as
a subset of (none, one or multiple Geneve Option) may be accessed by
a transit device or the NVE while the others needs to be accessed by
other transit devices. The confidentiality protection of the Geneve
Information is handled by the Geneve Overlay Provider.
In addition to Geneve Information, the traffic generated for the
Geneve overlay may be exposed to traffic volumetry and pattern
analysis within a virtualized network. Confidentiality protection
against traffic pattern recognition is handled by the Geneve Overlay
Provider.
5.1.1. Operational Security Requirements
A secure deployment of a Geneve overlay must fulfill the requirement
below:
o SEC-OP-1: A secure deployment of a Geneve overlay SHOULD by
default encrypt the inner payload. A Geneve overlay provider MAY
disable this capability for example when encryption is performed
by the Tenant System and that level of confidentiality is believed
to be sufficient. In order to provide additional protection to
traffic already encrypted by the Tenant the Geneve network
operator MAY partially encrypt the clear part of the inner
payload.
o SEC-OP-2: A secure deployment of a Geneve overlay MUST evaluate
the information associated to the leakage of Geneve Information
carried by the Geneve Packet. When a risk analysis concludes that
the risk of leaking sensitive information is too high, such Geneve
Information MUST NOT be transmit in clear text.
Migault, et al. Expires September 1, 2019 [Page 9]
Internet-Draft Geneve Security Requirements February 2019
o SEC-OP-3: A secure deployment of a Geneve overlay MUST evaluate
the risk associated to traffic pattern recognition. When a risk
has been identified, traffic pattern recognition MUST be addressed
with padding policies as well as generation of dummy packets.
5.1.2. Geneve Security Requirements
A Geneve security mechanism must fulfill the requirements below:
o SEC-GEN-1: Geneve security mechanism MUST provide the capability
to encrypt the inner payload.
o SEC-GEN-2: Geneve security mechanism SHOULD provide the capability
to partially encrypt the inner payload header.
o SEC-GEN-3: Geneve security mechanism MUST provide means to encrypt
a single or a set of zero, one or multiple Geneve Options while
leave other Geneve Options in clear. Reversely, a Geneve security
mechanism MUST be able to leave a Geneve option in clear, while
encrypting the others.
o SEC-GEN-4: Geneve security mechanism MUST provide means to encrypt
the information of Geneve Header (excluding Geneve Options).
Reversely, a Geneve security mechanism MUST be able to leave in
clear Geneve Header information (Geneve Options excluded) while
encrypting the other.
o SEC-GEN-5: Geneve security mechanisms MUST provide the ability to
provide confidentiality protection between multiple nodes, i.e.
multiple transit devices and a NVE.
o SEC-GEN-6: Geneve security mechanism MUST provide the ability to
pad a Geneve packet.
o SEC-GEN-7: Geneve security mechanism MUST provide the ability to
send dummy packets.
5.2. Protecting Against Traffic Injection
Traffic injection from a rogue non legitimate NVO3 Geneve overlay
device or a rogue underlay transit device can target an NVE, a
transit underlay device or a Tenant System. Targeting a Tenant's
System requires a valid MAC and IP addresses of the Tenant's System.
When traffic between tenants is not protected, the rogue device may
forward the modified packet over a valid (authenticated) Geneve
Header. The crafted packet may for example, include a specifically
crafted application payload for a specific Tenant Systems
Migault, et al. Expires September 1, 2019 [Page 10]
Internet-Draft Geneve Security Requirements February 2019
application, with the intention to load the tenant specific
application. Tenant's System may provide integrity protection of the
inner payload by protect their communications using for example
IPsec/ESP, IPsec/AH [RFC4302], TLS or DTLS. Such protection protects
at various layers the Tenants from receiving spoofed packets, as any
injected packet is expected to be discarded by the destination
Tenant's System. Note IPsec/ESP with NULL encryption may be used to
authenticate-only the layers above IP in which case the IP header
remains unprotected. However IPsec/AH enables the protection of the
entire IP packet, including the IP header. As a result, when Geneve
encapsulates IP packets the Tenant has the ability to integrity
protect the IP packet on its own, without relying on the Geneve
overlay network. On the other hand, L2 layers remains unprotected.
As encryption is using authenticated encryption, authentication may
also be provided via encryption. At the time of writing the document
DTLS 1.3 [I-D.ietf-tls-dtls13] is still a draft document and TLS 1.3
does not yet provide the ability for authenticate only the traffic.
As such it is likely that the use of DTLS1.3 may not involve
authentication-only cipher suites. Similarly to confidentiality
protection, integrity protection may be handled either entirely by
the Geneve Overlay Provider, or partially by the Tenant or handled by
both the Tenant and the Geneve Overlay Provider.
In addition to confidentiality protection of the inner payload,
integrity protection also prevents the Tenant System from receiving
illegitimate packets that may disrupt the Tenant's System
performance. The Geneve overlay network need to prevent the overlay
to be used as a vector to spoof packets being steered to the Tenant's
system. As a result, the Overlay Network Provider needs to ensure
that inner packets steered to the Tenant's network are only
originating from one Tenant System and not from an outsider using the
Geneve Overlay to inject packets to one virtual network. As such,
the destination NVE MUST be able to authenticate the incoming Geneve
packets from the source NVE. This may be performed by the NVE
authenticating the full Geneve Packet. When the Geneve Overlay wants
to take advantage of the authentication performed by the Tenant
System, the NVE shoudl be able to perform some checks between the
Geneve Header and the inner payload. Suppose two Geneve packets are
composed of a Geneve Header (H1, and H2) and a inner payload (P1 and
P2). Suppose H1, H2, P1 and P2 are authenticated. The replacement
of P2 by P1 by an attacker will be detected by the NVE only if there
is a binding between H2 and P2. Such integrity protection is handled
by the Geneve Overlay Provider.
While traffic injection may target the Tenant's virtual network or a
specific Tenant System, traffic injection may also target the Geneve
Overlay Network by injecting Geneve Options that will affect the
processing of the Geneve Packet. Updating the Geneve header and
Migault, et al. Expires September 1, 2019 [Page 11]
Internet-Draft Geneve Security Requirements February 2019
option parameters such as setting an OAM bit, adding bogus option
TLVs, or setting a critical bit, may result in different processing
behavior, that could greatly impact performance of the overlay
network and the underlay infrastructure and thus affect the tenants
traffic delivery. As such, the Geneve Overlay should provide
integrity protection of the Geneve Information present in the Geneve
Header to guarantee Geneve processing is not altered.
The Geneve architecture considers transit devices that may process
some Geneve Options. More specifically, a Geneve packet may have A
subset of Geneve Information of the Geneve Header (excluding Geneve
Options) as well as a set of zero, one or multiple of Geneve Options
accessed by one or more transit devices. This information needs to
be authenticated by a transit device while other options may be
authenticated by other transit devices or the tunnel endpoint. The
integrity protection is handled by the Geneve Overlay Provider and
authentication MUST be performed prior any processing.
5.2.1. Operational Security Requirements
A secure deployment of a Geneve overlay must fulfill the requirement
below:
o SEC-OP-4: A secure deployment of a Geneve overlay MUST provide the
capability authenticate the inner payload when encryption is not
provided. A Geneve overlay provider MAY disable this capability
for example when this is performed by the Tenant System and that
level of integrity is believed to be sufficient. In order to
provide additional protection to traffic already protected by the
Tenant the Geneve network operator MAY partially protect the
unprotected part of the inner payload.
o SEC-OP-5: A secure deployment of a Geneve overlay MUST evaluate
the risk associated to a change of the Geneve Outer Header, Geneve
Header (excluding Geneve Options) and Geneve Option. When a risk
analysis concludes that the risk is too high, this piece of
information MUST be authenticated.
o SEC-OP-6: A secure deployment of a Geneve overlay SHOULD
authenticate communications between NVE to protect the Geneve
Overlay infrastructure as well as the Tenants System's
communications (Geneve Packet). A Geneve overlay provider MAY
disable authentication of the inner packet and delegates it to the
Tenant Systems when communications between Tenant's System is
secured. This is NOT RECOMMENDED. Instead, it is RECOMMENDED
that mechanisms binds the inner payload to the Geneve Header. To
prevent injection between virtualized network, it is strongly
Migault, et al. Expires September 1, 2019 [Page 12]
Internet-Draft Geneve Security Requirements February 2019
RECOMMENDED that at least the Geneve Header without Geneve Options
is authenticated.
o SEC-OP-7: A secure deployment of a Geneve overlay SHOULD NOT
process data prior authentication. If that is not possible, the
Geneve overlay provider SHOULD evaluate its impact.
5.2.2. Geneve Security Requirements
A Geneve security mechanism must fulfill the requirements below:
o SEC-GEN-8: Geneve security mechanism MUST provide the capability
to authenticate the inner payload.
o SEC-GEN-9: Geneve security mechanism SHOULD provide the capability
to partially authenticate the inner payload header.
o SEC-GEN-10: Geneve security mechanism MUST provide the capability
to authenticate a single or a set of options while leave other
Geneve Option unauthenticated. Reversely, a Geneve security
mechanism MUST be able to leave a Geneve option unauthenticated,
while encrypting the others.
o SEC-GEN-11: Geneve security mechanism MUST provide means to
authenticate the information of Geneve Header (Geneve Option
excluded). Reversely, a Geneve security mechanism MUST be able to
leave unauthenticated Geneve header information (Geneve Options
excluded) while authenticating the other.
o SEC-GEN-12: Geneve Security mechanism MUST provide means for a
tunnel endpoint (NVE) to authenticate data prior it is being
processed.
o SEC-GEN-13: Geneve Security mechanism MUST provide means for a
transit device to authenticate data prior it is being processed.
5.3. Protecting Against Traffic Redirection
A rogue device of the NVO3 overlay Geneve network or the underlay
network may redirect the traffic from a virtual network to the
attacker for passive or active attacks. If the rogue device is in
charge of securing the Geneve packet, then Geneve security mechanisms
are not intended to address this threat. More specifically, a rogue
source NVE will still be able to redirect the traffic in clear text
before protecting ( and encrypting the packet). A rogue destination
NVE will still be able to redirect the traffic in clear text after
decrypting the Geneve packets. The same occurs with a rogue transit
that is in charge of encrypting and decrypting a Geneve Option,
Migault, et al. Expires September 1, 2019 [Page 13]
Internet-Draft Geneve Security Requirements February 2019
Geneve Option or any information. The security mechanisms are
intended to protect a Geneve information from any on path node. Note
that modern cryptography recommend the use of authenticated
encryption. This section assumes such algorithms are used, and as
such encrypted packets are also authenticated.
To prevent an attacker located in the middle between the NVEs and
modifying the tunnel address information in the data packet header to
redirect the data traffic, the solution needs to provide
confidentiality protection for data traffic exchanged between NVEs.
Requirements are similar as those provided in section Section 5.1 to
mitigate sniffing attacks and those provided in section Section 5.2
to mitigate traffic injection attacks.
5.4. Protecting Against Traffic Replay
A rogue device of the NVO3 overlay Geneve network or the underlay
network may replay a Geneve packet, to load the network and/or a
specific Tenant System with a modified Geneve payload. In some
cases, such attacks may target an increase of the tenants costs.
When traffic between Tenant System is not protected against anti-
replay. A packet even authenticated can be replayed. DTLS and IPsec
provides anti replay mechanisms, so it is unlikely that authenticated
Tenant's traffic is subject to replay attacks.
Similarly to integrity protection, the Geneve Overlay Provider should
prevent the overlay to be used to replay packet to the Tenant's
System. In addition, similarly to integrity protection, the Geneve
Overlay network may also be a target of a replay attack, and NVE as
well as transit devices should benefit from the same protection.
Given the proximity between authentication and anti-replay mechanisms
and that most authentication mechanisms integrates anti-replay
attacks, we RECOMMEND that authentication contains an anti-replay
mechanisms.
5.4.1. Geneve Security Requirements
A secure deployment of a Geneve overlay must fulfill the requirement
below:
o SEC-OP-8: A secure deployment of a Geneve overlay MUST evaluate
the communications subject to replay attacks. Communications that
are subject to this attacks MUST be authenticated with an anti
replay mechanism. Note that when partial authentication is
provided, the part not covered by the authentication remains a
Migault, et al. Expires September 1, 2019 [Page 14]
Internet-Draft Geneve Security Requirements February 2019
surface of attack. It is strongly RECOMMENDED that the Geneve
Header is authenticated with anti replay protection.
5.4.2. Geneve Security Requirements
A Geneve security mechanism must fulfill the requirements below:
o SEC-GEN-14: Geneve Security mechanism MUST provide authentication
with anti-replay protection.
5.5. Security Management
5.5.1. Operational Security Requirements
A secure deployment of a Geneve overlay must fulfill the requirement
below:
o SEC-OP-9: A secure deployment of a Geneve overlay MUST define the
security policies that associates the encryption, and
authentication associated to each flow between NVEs.
o SEC-OP-10: A secure deployment of a Geneve overlay SHOULD define
distinct material for each flow. The cryptographic depends on the
nature of the flow (multicast, unicast) as well as on the security
mechanism enabled to protect the flow.
5.5.2. Geneve Security Requirements
A Geneve security mechanism must fulfill the requirements below:
o SEC-GEN-15: A Geneve security mechanism MUST be managed via
security policies associated for each traffic flow to be
protected. Geneve overlay provider MUST be able to configure NVEs
with different security policies for different flows. A flow MUST
be identified at minimum by the Geneve virtual network identifier
and the inner IP and transport headers, and optionally additional
fields which define a flow (e.g., inner IP DSCP, IPv6 flow id,
Geneve options).
o SEC-GEN-16: A Geneve security mechanism MUST be able to assign
different cryptographic keys to protect the unicast tunnels
between NVEs respectively.
o SEC-GEN-17: A Geneve security mechanisms, when multicast is used,
packets,MUST be able to assign distinct cryptographic group keys
to protect the multicast packets exchanged among the NVEs within
different multicast groups. Upon receiving a data packet, an
egress Geneve NVE MUST be able to verify whether the packet is
Migault, et al. Expires September 1, 2019 [Page 15]
Internet-Draft Geneve Security Requirements February 2019
sent from a proper ingress NVE which is authorized to forward that
packet.
6. IANA Considerations
There are no IANA consideration for this document.
7. Security Considerations
The whole document is about security.
Limiting the coverage of the authentication / encryption provides
some means for an attack to craft special packets.
The current document details security requirements that are related
to the Geneve protocol. Instead,
[I-D.ietf-nvo3-security-requirements] provides generic architecture
security requirement upon the deployment of an NVO3 overlay network.
It is strongly recommended to read that document as architecture
requirements also apply here. In addition, architecture security
requirements go beyond the scope of Geneve communications, and as
such are more likely to address the security needs upon deploying an
Geneve overlay network.
8. Appendix
8.1. DTLS
This section compares how NVE communications using DTLS meet the
security requirements for a secure Geneve overlay deployment. In
this example DTLS is used over the Geneve Outer Header and secures
the Geneve Header including the Geneve Options and the inner payload.
The use of DTLS MAY fill the security requirements for a secure
Geneve deployment. However DTLS cannot be considered as the Geneve
security mechanism enabling all Geneve deployments. To ease the
reading of the Requirements met by DTLS or IPsec, the requirements
list indicates with Y (Yes) when the requirement and N (No) when the
requirement is not met. In addition, an explanation is provided on
the reasoning. This section is not normative and its purpose is
limited to illustrative purpose.
8.1.1. Operational Security Requirements
This section shows how DTLS may secure some Geneve deployments. Some
Geneve deployments may not be secured by DTLS, but that does not
exclude DTLS from being used.
Migault, et al. Expires September 1, 2019 [Page 16]
Internet-Draft Geneve Security Requirements February 2019
o SEC-OP-1 (Y): A deployment using DTLS between NVEs with an non
NULL encryption cipher suite will provide confidentiality to the
full Geneve Packet which contains the inner payload. As such the
use of DTLS meets SEC-OP-1. Note that DTLS does not provide
partial encryption and as such the Geneve Overlay Provider may not
benefit from the encryption performed by the Tenant if performed,
which may result in some portion of the payload being encrypted
twice.
o SEC-OP-2 (Y): A deployment using DTLS between NVEs with an non
NULL encryption cipher suite encrypt the Geneve Packet which
includes the Geneve Header and associated metadata. Only the UDP
port is leaked which could be acceptable. As such, the use of
DTLS meets SEC-OP-2.
o SEC-OP-3 (Y/N): A deployment using DTLS between NVEs will not be
able to send dummy packets or pad Geneve Packet unless this is
managed by the Geneve packet itself. DTLS does not provide the
ability to send dummy traffic, nor to pad. As a result DTLS
itself does not meet this requirement. This requirement may be
met if handled by the Geneve protocol. As such SEC-OP-3 may not
be met for some the deployment. However, it is not a mandatory
requirement and as such it is likely that the use of DTLS SEC-OP-3
is met.
o SEC-OP-4 (Y): Similarly to SEC-OP-1, A deployment using DTLS
between NVEs provides integrity protection to the full Geneve
Packet which includes the inner payload. As such the use of DTLS
meets SEC-OP-4. Note that DTLS 1.2 provides integrity-only cipher
suites while DTLS 1.3 does not yet. As a result, the use of DTLS
1.3 may provide integrity protection using authenticated
encryption.
o SEC-OP-5 (Y): Similarly to SEC-OP-2, A deployment using DTLS
between NVE authenticates the full Geneve Packet which includes
the Geneve Header. Only the UDP port is left unauthenticated. As
such, the use of DTLS meets SEC-OP-5.
o SEC-OP-6 (Y): A deployment using DTLS between NVE authenticates
NVE-to-NVE communications and the use of DTLS meets SEC-OP-6.
o SEC-OP-7 (Y/N): A deployment using DTLS between NVEs is not
compatible with a Geneve architecture that includes transit
devices. When the DTLS session uses a non NULL encryption cipher
suite, the transit device will not be able to access it. When the
NULL encryption cipher suite is used, the transit device may be
able to access the data, but will not be able to authenticate it
prior to processing the packet. As such the use of DTLS only
Migault, et al. Expires September 1, 2019 [Page 17]
Internet-Draft Geneve Security Requirements February 2019
meets SEC-OP-7 for deployment that do not include any transit
devices.
o SEC-OP-8 (Y): A deployment using DTLS between NVEs provides anti-
replay protection and so, the use of DTLS meets SEC-OP-8.
o SEC-OP-9 (Y/N): DTLS does not define any policies. Instead DTLS
process is bound to an UDP socket. As such handling of flow
policies is handled outside the scope of DTLS. As such SEC-OP-9
is met outside the scope of DTLS.
o SEC-OP-10 (N): DTLS session may be established with specific
material, as such it is possible to assign different material for
each flow. However, the binding between flow and session is
performed outside the scope of DTLS. In addition, DTLS does not
support multicast. As such, the use of DTLS may only meets SEC-
OP-10 in the case of unicast communications.
8.1.2. Geneve Security Requirements
This section shows that DTLS cannot be used as a generic Geneve
security mechanism to secure Geneve deployments. A Geneve security
mechanism woudl need to meet all SEC-GEN requirements.
o SEC-GEN-1 (Y): A deployment using DTLS between NVEs with an non
NULL encryption cipher suite will provide confidentiality to the
full Geneve Packet which contains the inner payload. As such the
use of DTLS meets SEC-GEN-1.
o SEC-GEN-2 (Y): A deployment using DTLS between NVEs with an non
NULL encryption cipher suite will not be able to partially encrypt
the inner payload header. However such requirement is not set a
mandatory so the use of DTLS meets SEC-GEN-2
o SEC-GEN-3 (N): A deployment using DTLS between NVEs with an non
NULL encryption cipher suite encrypt the Geneve Packet which
includes the Geneve Header and all Geneve Options. However DTLS
does not provides any means to selectively encrypt or leave in
clear text a subset of Geneve Options. As a result the use of
DTLS does not meet SEC-GEN-3.
o SEC-GEN-4 (N): A deployment using DTLS between NVEs with an non
NULL encryption cipher suite encrypt the Geneve Packet which
includes the Geneve Header and all Geneve Options. However, DTLS
does not provides means to selectively encrypt some information of
the Geneve Header. As such the use of DTLS does not meet SEC-GEN-
5.
Migault, et al. Expires September 1, 2019 [Page 18]
Internet-Draft Geneve Security Requirements February 2019
o SEC-GEN-5 (N): A deployment using DTLS between NVEs with an non
NULL encryption cipher suite provides end-to-end security between
the NVEs and as such does not permit the interaction of one or
multiple on-path transit devices. As such the use of DTLS does
not meet SEC-GEN-5.
o SEC-GEN-6 (N): A deployment using DTLS between NVEs with an non
NULL encryption cipher suite does not provide padding facilities.
This requirements is not met by DTLS itself and needs to be
handled by Geneve and specific options. As a result, the use of
DTLS does not meet SEC-GEN-6
o SEC-GEN-7 (N): A deployment using DTLS between NVEs with an non
NULL encryption cipher suite does not provide the ability to send
dummy packets. This requirements is not met by DTLS itself and
needs to be handled by Geneve and specific options. As a result,
the use of DTLS does not meet SEC-GEN-7.
o SEC-GEN-8 (Y): A deployment using DTLS between NVEs with an non
NULL encryption cipher suite or a NULL encryption cipher suite
provide authentication of the inner payload. As such the use of
DTLS meets SEC-GEN-8.
o SEC-GEN-9 (Y): A deployment using DTLS between NVEs does not
provide the ability to partially authenticate the inner payload
header. However such requirement is not set a mandatory so the
use of DTLS meets SEC-GEN-9
o SEC-GEN-10 (N): A deployment using DTLS between NVEs authenticates
the Geneve Packet which includes the Geneve Header and all Geneve
Options. However, DTLS does not provides means to selectively
encrypt some information of the Geneve Header. As such the use of
DTLS meets SEC-GEN-10.
o SEC-GEN-11 (N): A deployment using DTLS between NVEs authenticates
the Geneve Packet which includes the Geneve Header and all Geneve
Options. However, DTLS does not provides means to selectively
authenticate some information of the Geneve Header. As such the
use of DTLS does not meet SEC-GEN-11.
o SEC-GEN-12 (Y): A deployment using DTLS between NVEs authenticates
the data prior the data is processed by the NVE. As such, the use
of DTLS meets SEC-GEN-12.
o SEC-GEN-13 (N): A deployment using DTLS between NVEs authenticates
the data when the tunnel reaches the NVE. As a result the transit
device is not able to authenticate the data prior accessing it and
the use of DTLS does not meet SEC-GEN-13.
Migault, et al. Expires September 1, 2019 [Page 19]
Internet-Draft Geneve Security Requirements February 2019
o SEC-GEN-14 (Y): DTLS provides anti-replay mechanism as such, the
use of DTLS meets SEC-GEN-14.
o SEC-GEN-15 (N): DTLS itself does not have a policy base mechanism.
As a result, the classification of the flows needs to be handled
by a module outside DTLS. In order to meet SEC-GEN-15 further
integration is needed and DTLS in itself cannot be considered as
meeting SEC-GEN-15.
o SEC-GEN-16 (Y): DTLS is able to assign various material to each
flows, as such the use of DTLS meets SEC-GEN-16.
o SEC-GEN-17 (N): DTLS does not handle mutlicast communications. As
such the use of DTLS does not meet SEC-GEN-17.
8.2. IPsec
This section compares how NVE communications using IPsec/ESP or
IPsec/AH meet the security requirements for a secure Geneve overlay
deployment. In this example secures the Geneve IP packet including
Outer IP header, the Geneve Outer Header, the Geneve Header including
Geneve Options and the inner payload.
The use of IPsec/ESP or IPsec/AH share most of the analysis performed
for DTLS. The main advantages of using IPsec would be that IPsec
supports multicast communications and natively supports flow based
security policies. However, the use of these security policies in a
context of Geneve is not natively supported.
As a result, the use of IPsec MAY fill the security requirements for
a secure Geneve deployment. However IPsec cannot be considered as
the Geneve security mechanism enabling all Geneve deployments.
8.2.1. Operational Security Requirements
This section shows how IPsec may secure some Geneve deployments.
Some Geneve deployments may not be secured by IPsec, but that does
not exclude IPsec from being used.
o SEC-OP-1 (Y): A deployment using IPsec/ESP between NVEs with an
non NULL encryption will provide confidentiality to the full Outer
IP payload of the Geneve Packet which contains the inner payload.
As a result, such deployments meet SEC-OP-1. Note that IPsec/ESP
does not provide partial encryption and as such the Geneve Overlay
Provider may not benefit from the encryption performed by the
Tenant if performed, which may result in some portion of the
payload being encrypted twice.
Migault, et al. Expires September 1, 2019 [Page 20]
Internet-Draft Geneve Security Requirements February 2019
o SEC-OP-2 (Y): A deployment using IPsec/ESP between NVEs with an
non NULL encryption encrypts the Outer IP payload Geneve IP Packet
which includes the Geneve Header and associated information. As
such SEC-OP-2 is met.
o SEC-OP-3 (Y): A deployment using IPsec/ESP between NVEs will be
able to send dummy packets or pad Geneve Packet. As such OP-SEC-3
is met.
o SEC-OP-4 (Y): Similarly to SEC-OP-1, A deployment using IPsec/ESP
or IPsec/AH between NVEs provides integrity protection to the full
Geneve Packet which includes the inner payload. As such SEC-OP-4
is met.
o SEC-OP-5 (Y): Similarly to SEC-OP-2, A deployment using IPsec/ESP
or IPsec/AH between NVE authenticates the full Geneve Packet which
includes the Geneve Header. As such SEC-OP-5 is met as well.
o SEC-OP-6 (Y): A deployment using IPsec/ESP or IPsec/AH between NVE
authenticates NVE-to-NVE communications and SEC-OP-6 is met.
o SEC-OP-7 (Y/N): A deployment using IPsec between NVEs is not
compatible with a Geneve architecture that includes transit
devices. When IPsec/ESP with a non NULL encryption is used, the
transit device will not be able to access it. When IPsec/AH or
IPsec/ESP with the NULL encryption is used, the transit device may
be able to access the data, but will not be able to authenticate
it prior to processing the packet. As SEC-OP-7 is only met for
deployment that do not include any transit devices.
o SEC-OP-8 (Y): A deployment using IPsec between NVEs provides anti-
replay protection and so meets SEC-OP-8.
o SEC-OP-9 (Y/N): IPsec enables the definition of security policies.
As such IPsec is likely to handle a per flow security. However
the traffic selector required for Geneve flows may not be provided
natively by IPsec. As such Sec-OP-9 is only partialy met.
o SEC-OP-10 (Y): IPsec session may be established with specific
material, as such it is possible to assign different material for
each flow. In addition IPsec supports multicats communications.
As such SEC-OP-10 is met.
8.2.2. Geneve Security Requirements
This section shows that IPsec cannot be used as a generic Geneve
security mechanism to secure Geneve deployments. A Geneve security
mechanism would need to meet all SEC-GEN requirements.
Migault, et al. Expires September 1, 2019 [Page 21]
Internet-Draft Geneve Security Requirements February 2019
o SEC-GEN-1 (Y): A deployment using IPsec/ESP between NVEs with an
non NULL encryption provide confidentiality to the full Geneve
Packet which contains the inner payload. As such IPsec/ESP meets
SEC-GEN-1.
o SEC-GEN-2 (Y): A deployment using IPsec/ESP between NVEs with an
non NULL encryption will not be able to partially encrypt the
inner payload header. However such requirement is not set a
mandatory so IPsec/ESP meets SEC-GEN-2
o SEC-GEN-3 (N): A deployment using IPsec between NVEs with an non
NULL encryption encrypts the Outer IP payload of the Geneve Packet
which includes the Geneve Header and all Geneve Options. However
IPsec/ESP does not provides any means to selectively encrypt or
leave in clear text a subset of Geneve Options. As a result SEC-
GEN-3 is not met.
o SEC-GEN-4 (N): A deployment using IPsec/ESP between NVEs with an
non NULL encryption encrypts the Geneve Packet which includes the
Geneve Header and all Geneve Options. However, IPsec/ESP does not
provides means to selectively encrypt some information of the
Geneve Header. As such SEC-GEN-5 is not met.
o SEC-GEN-5 (N): A deployment using IPsec between NVEs with an non
NULL encryption provides end-to-end security between the NVEs and
as such does not permit the interaction of one or multiple on-path
transit devices. As such IPsec/ESP does not meet SEC-GEN-5.
o SEC-GEN-6 (Y): A deployment using IPsec/ESP between NVEs with an
non NULL encryption provides padding facilities and as such IPsec/
ESP meets SEC-GEN-6.
o SEC-GEN-7 (Y): A deployment using IPsec between NVEs with an non
NULL encryption cipher provides the ability to send dummy packets.
As such IPsec/ESP meets SEC-GEN-7.
o SEC-GEN-8 (Y): A deployment using IPsec/ESP or IPsec/AH
authenticates the inner payload. As such SEC-GEN-8 is met.
o SEC-GEN-9 (Y): A deployment using IPsec/AH or IPsec/ESP between
NVEs does not provide the ability to partially authenticate the
inner payload header. However such requirement is not set a
mandatory so IPsec meets SEC-GEN-9
o SEC-GEN-10 (N): A deployment using IPsec/ESP or IPsec/AH between
NVEs authenticates the Geneve Packet which includes the Geneve
Header and all Geneve Options. However, IPsec does not provides
Migault, et al. Expires September 1, 2019 [Page 22]
Internet-Draft Geneve Security Requirements February 2019
means to selectively encrypt some information of the Geneve
Header. As such SEC-GEN-10 is not met.
o SEC-GEN-11 (N): A deployment using IPsec/ESP or IPsec/AH between
NVEs authenticates the Geneve Packet which includes the Geneve
Header and all Geneve Options. However, IPsec does not provides
means to selectively authenticate some information of the Geneve
Header. As such SEC-GEN-11 is not met.
o SEC-GEN-12 (Y): A deployment using IPsec/ESP or IPsec/AH between
NVEs authenticates the data prior the data is processed by the
NVE. As such SEC-GEN-12 is met.
o SEC-GEN-13 (N): A deployment using IPsec/ESP or IPsec/AH between
NVEs authenticates the data when the tunnel reaches the NVE. As a
result the transit device is not able to authenticate the data
prior accessing it and SEC-GEN-13 is not met.
o SEC-GEN-14 (Y): IPsec/ESP and IPsec/AH provides anti-replay
mechanism as such SEC-GEN-14 is met.
o SEC-GEN-15 (N): IPsec is a policy base architecture. As a result,
the classification of the flows needs to be handled by IPsec.
However, the traffic selector available are probably not those
required by Geneve and further integration is needed. As such
SEC-GEN-15 is not met.
o SEC-GEN-16 (Y): IPsec is able to assign various material to each
flows, as such SEC-GEN-16 is met.
o SEC-GEN-17 (Y): IPsec handles mutlicast communications. As such
SEC-GEN-17 is met.
9. Acknowledgments
We would like to thank Ilango S Ganaga, Magnus Nystroem for their
useful reviews and clarifications as well as Matthew Bocci, Sam
Aldrin and Ignas Bagdona for moving the work forward.
10. References
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
Migault, et al. Expires September 1, 2019 [Page 23]
Internet-Draft Geneve Security Requirements February 2019
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, DOI 10.17487/RFC4301,
December 2005, <https://www.rfc-editor.org/info/rfc4301>.
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302,
DOI 10.17487/RFC4302, December 2005,
<https://www.rfc-editor.org/info/rfc4302>.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, DOI 10.17487/RFC4303, December 2005,
<https://www.rfc-editor.org/info/rfc4303>.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
January 2012, <https://www.rfc-editor.org/info/rfc6347>.
[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an
Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May
2014, <https://www.rfc-editor.org/info/rfc7258>.
[RFC7365] Lasserre, M., Balus, F., Morin, T., Bitar, N., and Y.
Rekhter, "Framework for Data Center (DC) Network
Virtualization", RFC 7365, DOI 10.17487/RFC7365, October
2014, <https://www.rfc-editor.org/info/rfc7365>.
[RFC7516] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)",
RFC 7516, DOI 10.17487/RFC7516, May 2015,
<https://www.rfc-editor.org/info/rfc7516>.
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre,
"Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
2015, <https://www.rfc-editor.org/info/rfc7525>.
[RFC8014] Black, D., Hudson, J., Kreeger, L., Lasserre, M., and T.
Narten, "An Architecture for Data-Center Network
Virtualization over Layer 3 (NVO3)", RFC 8014,
DOI 10.17487/RFC8014, December 2016,
<https://www.rfc-editor.org/info/rfc8014>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
Migault, et al. Expires September 1, 2019 [Page 24]
Internet-Draft Geneve Security Requirements February 2019
[RFC8221] Wouters, P., Migault, D., Mattsson, J., Nir, Y., and T.
Kivinen, "Cryptographic Algorithm Implementation
Requirements and Usage Guidance for Encapsulating Security
Payload (ESP) and Authentication Header (AH)", RFC 8221,
DOI 10.17487/RFC8221, October 2017,
<https://www.rfc-editor.org/info/rfc8221>.
[RFC8247] Nir, Y., Kivinen, T., Wouters, P., and D. Migault,
"Algorithm Implementation Requirements and Usage Guidance
for the Internet Key Exchange Protocol Version 2 (IKEv2)",
RFC 8247, DOI 10.17487/RFC8247, September 2017,
<https://www.rfc-editor.org/info/rfc8247>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.
10.2. Informative References
[I-D.ietf-nvo3-geneve]
Gross, J., Ganga, I., and T. Sridhar, "Geneve: Generic
Network Virtualization Encapsulation", draft-ietf-
nvo3-geneve-09 (work in progress), February 2019.
[I-D.ietf-nvo3-security-requirements]
Hartman, S., Zhang, D., Wasserman, M., Qiang, Z., and M.
Zhang, "Security Requirements of NVO3", draft-ietf-nvo3-
security-requirements-07 (work in progress), June 2016.
[I-D.ietf-tls-dtls13]
Rescorla, E., Tschofenig, H., and N. Modadugu, "The
Datagram Transport Layer Security (DTLS) Protocol Version
1.3", draft-ietf-tls-dtls13-30 (work in progress),
November 2018.
Authors' Addresses
Daniel Migault
Ericsson
8275 Trans Canada Route
Saint Laurent, QC 4S 0B6
Canada
EMail: daniel.migault@ericsson.com
Migault, et al. Expires September 1, 2019 [Page 25]
Internet-Draft Geneve Security Requirements February 2019
Sami Boutros
VMware, Inc.
EMail: boutros@vmware.com<
Dan Wings
VMware, Inc.
EMail: dwing@vmware.com
Suresh Krishnan
Kaloom
EMail: suresh@kaloom.com
Migault, et al. Expires September 1, 2019 [Page 26]
