NVO3 D. Migault
Internet-Draft Ericsson
Intended status: Informational S. Boutros
Expires: April 15, 2019 D. Wings
VMware, Inc.
S. Krishnan
Kaloom
October 12, 2018
Geneve Security Requirements
draft-mglt-nvo3-geneve-security-requirements-04
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 April 15, 2019.
Migault, et al. Expires April 15, 2019 [Page 1]
Internet-Draft Geneve Security Requirements October 2018
Copyright Notice
Copyright (c) 2018 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 . . . . . . . . . . . . . . . . . . . . 2
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.2. Protecting Against Traffic Injection . . . . . . . . . . 10
5.3. Protecting Against Traffic Redirection . . . . . . . . . 11
5.4. Protecting Against Traffic Replay . . . . . . . . . . . . 12
5.5. Security Management . . . . . . . . . . . . . . . . . . . 13
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
7. Security Considerations . . . . . . . . . . . . . . . . . . . 14
7.1. TLS . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
7.2. IPsec . . . . . . . . . . . . . . . . . . . . . . . . . . 15
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
9.1. Normative References . . . . . . . . . . . . . . . . . . 15
9.2. Informative References . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
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.
Migault, et al. Expires April 15, 2019 [Page 2]
Internet-Draft Geneve Security Requirements October 2018
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 April 15, 2019 [Page 3]
Internet-Draft Geneve Security Requirements October 2018
+--------+ +--------+
| 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 April 15, 2019 [Page 4]
Internet-Draft Geneve Security Requirements October 2018
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].
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.
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
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,
Migault, et al. Expires April 15, 2019 [Page 5]
Internet-Draft Geneve Security Requirements October 2018
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
Attacks from compromised NVO3 and underlay network devices, and
attacks from compromised tenant systems defined in
[I-D.ietf-nvo3-security-requirements]. This document considers these
attacks in the scope of 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. The scope of Geneve excludes
security requirements related to the control plane.
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).
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 and the security
requirements expect to mitigate such attacks by lowering the
consequences, typically making leaked data unusable to an attacker..
Migault, et al. Expires April 15, 2019 [Page 6]
Internet-Draft Geneve Security Requirements October 2018
4.2. Active Attacks
Active attacks involve modifying packets, injecting packets, or
interfering with 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
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.
Migault, et al. Expires April 15, 2019 [Page 7]
Internet-Draft Geneve Security Requirements October 2018
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.
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
Passive attacks consists in inferring information about a virtualized
network or some Tenant System from observing the traffic. This could
also involve the correlation between observed 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.
The inner payload, unless protection is provided by the Tenant System
reveals the content of the communication. This may mitigate by the
Tenant using application level security such as, for example JSON Web
Encryption [RFC7516] or transport layer security such as DTLS
[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.
A secure deployment of a Geneve overlay must fulfill the requirement
below:
Migault, et al. Expires April 15, 2019 [Page 8]
Internet-Draft Geneve Security Requirements October 2018
1. 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.
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.
The Geneve Header and Geneve Options contains metadata information
related to the communications. Note that a Geneve packet may have a
combination of Geneve options that needs to be read by transit
device, in which case this option needs to be read by the transit
device while other options MAY only be accessed by the tunnel
endpoint. Information revealed as well as correlation with traffic
volumetry may reveal pattern traffic within a given virtualized
network as well as any information revealed by the current and future
Geneve Option.
A secure deployment of a Geneve overlay must fulfill the requirement
below:
o SEC-OP-2: A secure deployment of a Geneve overlay MUST evaluate
the information associated to the leakage of the Geneve Outer
Header, Geneve Header and Geneve Option. When those information
are likely to carry sensitive information. they MUST NOT be
transmit in clear text.
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.
A Geneve security mechanism must fulfill the requirements below:
o SEC-GEN-3: Geneve security mechanism MUST provide the capability
to encrypt a single or a set of options while leave other Geneve
Option in clear. Reversely, a Geneve security mechanism MUST be
able to leave a Geneve option in clear, while encrypting the
others.
Migault, et al. Expires April 15, 2019 [Page 9]
Internet-Draft Geneve Security Requirements October 2018
o SEC-GEN-4: Geneve security mechanism MUST provide means to encrypt
the information of Geneve Header. Reversely, a Geneve security
mechanism MUST be able to leave in clear header information while
encrypting the other.
o SEC-GEN-5: Geneve security mechanism MUST provide the ability to
pad a Geneve packet.
o SEC-GEN-6: 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.
Tenant's System may protect their communications using IPsec or TLS.
Such protection protects the Tenants from receiving spoofed packets,
as any injected packet is expected to be discarded by the destination
Tenant's System. Such protection does not protect the tenant system
from receiving illegitimate packets that may disrupt the Tenant's
System performance. The Geneve overlay network MAY still need to
prevent such spoofed Tenant's system packets from being steered to
the Tenant's system. When the Tenant's Systems are not protecting
their communications, the Geneve overlay network SHOULD be able to to
prevent a rogue device from injecting traffic into the overlay
network.
In order to prevent traffic injection to one virtual network, the
destination legitimate Geneve NVE MUST be able to authenticate the
incoming Geneve packets from the source NVE. The Geneve architecture
considers transit devices that MAY process some Geneve Option without
affecting the Geneve packet. These transit device MAY Authenticate
the Geneve packet as part of the Geneve packet processing but MAY
also process other Geneve options. As a result, integrity protection
and authentication SHOULD be performed by transit device, prior to
any processing.
A secure deployment of a Geneve overlay must fulfill the requirement
below:
o SEC-OP-4: 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
Migault, et al. Expires April 15, 2019 [Page 10]
Internet-Draft Geneve Security Requirements October 2018
Tenant Systems when communications between Tenant's System is
secured. This is NOT RECOMMENDED. To prevent injection between
virtualized network, it is strongly RECOMMENDED that at least the
Geneve Header is authenticated.
o SEC-OP-5: 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.
A Geneve security mechanism must fulfill the requirements below:
o SEC-GEN-8: Geneve Security mechanism MUST provide means for a
tunnel endpoint (NVE) to authenticate data prior it is being
processed. A tunnel endpoint (NVE) MUST be able to authenticate
at least:
* the Geneve Header and a subset of Geneve Options
* the Geneve Header, a subset of Geneve options and the Geneve
inner payload
* the Geneve Header, a subset of Geneve options and the Geneve
inner payload or the portion of the inner payload in case the
Tenant's System provides some authentication mechanism.
o SEC-GEN-9: Geneve Security mechanism SHOULD provide means for a
transit device to authenticate the Geneve Option prior processing
it. Authentication MAY concern the whole Geneve packet, but MAY
be limited to the Geneve Option.
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 the 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, 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.
Migault, et al. Expires April 15, 2019 [Page 11]
Internet-Draft Geneve Security Requirements October 2018
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 need to provide
confidentiality protection for data traffics 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 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
application, with the intention to load the tenant specific
application.
Updating the Geneve header and 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.
The NVO3 overlay network and underlay network nodes that may address
such attacks MUST provide means to authenticate the Geneve packet
components.
A secure deployment of a Geneve overlay must fulfill the requirement
below:
o SEC-OP-6: A secure deployment of a Geneve overlay MUST evaluate
the flows subject to replay attacks. Flows 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 surface of attack. It is
strongly RECOMMENDED that the Geneve Header is both authenticated
with anti replay protection.
A Geneve security mechanism must fulfill the requirements below:
Migault, et al. Expires April 15, 2019 [Page 12]
Internet-Draft Geneve Security Requirements October 2018
o SEC-GEN-10: Geneve Security mechanism MUST provide means for a
tunnel endpoint (NVE) to validate the Geneve Header corresponds to
the Geneve payload, and discard such packets.
5.5. Security Management
A secure deployment of a Geneve overlay must fulfill the requirement
below:
o SEC-OP-7: 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-8: 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.
A Geneve security mechanism must fulfill the requirements below:
o SEC-GEN-11: 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-12: A Geneve security mechanism MUST be able to assign
different cryptographic keys to protect the unicast tunnels
between NVEs respectively.
o SEC-GEN-13: 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
sent from a proper ingress NVE which is authorized to forward that
packet.
6. IANA Considerations
There are no IANA consideration for this document.
Migault, et al. Expires April 15, 2019 [Page 13]
Internet-Draft Geneve Security Requirements October 2018
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.
7.1. TLS
This section compares how NVE communications using TLS meet the
security requirements for a secure Geneve overlay deployment. In
this example TLS is used over the Geneve Outer Header and secured the
Geneve Header, Geneve Options and the inner payload.
The use of TLS MAY fill the security requirements for a secure Geneve
deployment. However TLS cannot be considered as the Geneve security
mechanism enabling all Geneve deployments.
The use of to secure a Geneve overlay deployment TLS meets SEC-OP-1
as it protects the inner payload of the tenant. It meets SEC-OP-2 as
except from the UDP port, no information concerning Geneve is leaked.
SEC-OP-3 is not met as TLS does not provide the ability to send dummy
traffic, nor to pad. SEC-OP-4 is met as the communication is
authenticated, including the Geneve Header. SEC-OP-5 is met as the
Geneve Packet is processed once it has been authenticated. SEC-OP-6
is met as TLS comes with anti replay protection. SEC-OP-7 and SEC-
OP-8 may also be met with security policies established per UDP
destination port where only unicast is considered.
The use of TLS as a generic Geneve Security mechanism meets SEC-GEN-1
as it encrypts the inner payload. However, TLS, but does not enable
partial encryption of the inner payload. TLS does not meet SEC-GEN3
or SEC-GEN-4 that requires the ability to encrypt of a subset of the
Geneve Options or the Geneve Header information. In addition, TLS
does not enable that some Geneve option of Header information remain
in clear text while other are encrypted. Typically TLS would not be
compatible with transit device. In addition is make the Geneve
option visible to the transit device, TLS does not provide the
Migault, et al. Expires April 15, 2019 [Page 14]
Internet-Draft Geneve Security Requirements October 2018
ability for a transit device to authenticate the option before
processing it. SEC-GEN-5 and SEC-GEN-6 are not met as TLS does not
provide padding nor the ability to generate dummy packets. TLS does
not meet SEC-GEN-8 that requires the ability to authenticate some
combination of Geneve Header, Geneve Options, (partial) inner
payload. TLS does not meet SEC-GEN-9 that requires the ability to
authenticate a single Geneve Option. TLS meets SEC-GEN-10 as it
provides anti replay mechanism to the authentication. SEC-GEN-11 is
not natively supported as TLS security is established by UDP
destination ports, rather than by flow. If more than one security
policy or flow needs to be considered a binding between flow and
ports needs to be established. SEC-GEN-13 is not met for mutlicast
traffic.
7.2. IPsec
The use of IPsec/ESP or IPsec/AH share most of the analysis performed
for TLS. 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.
8. Acknowledgments
We would like to thank Ilango S Ganaga for its useful reviews and
clarifications as well as Matthew Bocci, Sam Aldrin and Ignas Bagdona
for moving the work forward.
9. References
9.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>.
[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>.
[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>.
Migault, et al. Expires April 15, 2019 [Page 15]
Internet-Draft Geneve Security Requirements October 2018
[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>.
[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>.
[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>.
[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>.
9.2. Informative References
[I-D.ietf-nvo3-geneve]
Gross, J., Ganga, I., and T. Sridhar, "Geneve: Generic
Network Virtualization Encapsulation", draft-ietf-
nvo3-geneve-08 (work in progress), October 2018.
[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.
Migault, et al. Expires April 15, 2019 [Page 16]
Internet-Draft Geneve Security Requirements October 2018
Authors' Addresses
Daniel Migault
Ericsson
8275 Trans Canada Route
Saint Laurent, QC 4S 0B6
Canada
EMail: daniel.migault@ericsson.com
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 April 15, 2019 [Page 17]