Geneve Protocol Security Requirements
Ericsson
8400 boulevard Decarie
Montreal, QC
H4P 2N2
Canada
daniel.migault@ericsson.com
Routing
NVO3
This draft lists the security requirements associated to the Generic
Network Virtualization Encapsulation (Geneve) .
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in .
A cloud provider may administrate Tenant Systems belonging to one or
multiple tenants using an Geneve overlay network. The Geneve overlay enables
multiple Virtual Networks to coexist over a shared infrastructure, and a
Virtual Network may be distributed within a single data center or
between different data centers. The Geneve overlay network is constituted
by Geneve forwarding elements as well as Network Virtualization Edges
(NVE) . Traffic with a Virtual Network is thus
steered between NVEs using Generic Network Virtualization Encapsulation
(Geneve) .
This document analyses and lists the security requirements to
securely deploy Geneve overlay networks. It is expected that these
requirements will help design the appropriated security mechanisms for
Geneve as well as provides some basis security notion for further Geneve
deployments.
In addition, when a tenant subscribes to a cloud provider for hosting
its Tenant Systems, the cloud provider manages the Geneve overlay network
on behalf of the tenant . It may also, but not
necessarily manage the infrastructure supporting the overlay network.
The Geneve security requirements listed in this document aims at
providing the cloud provider the necessary options to ensure the
tenant:
Tenants Isolation, that is Tenant System inside a Virtual Network are
isolated from other Tenants Virtual Networks. This Tenants isolation
mostly prevents traffic from one tenant to be redirected to another
tenant as well as traffic from one tenant being injected into another
tenant.
Geneve robustness, that is a rogue elements of the Geneve overlay network
will have limited impacts over the Geneve overlay network itself as
well as over Tenants Systems.
Geneve isolation of the infrastructure, that is information in transit
is not subject to passive monitoring. Information in transit concerns
both information associated to the Geneve overlay network as well as
information exchanged by the Tenant' Systems. Hiding information of the
overlay network to the infrastructure is typically required when the
overlay network provider and the infrastructure provider are different
entities.
Tenant Systems isolation prevents communications from one tenant to leak
into another Tenant Systems' virtual network. This section is focused on an
Geneve overlay network perspective which means:
Only communications between NVEs are considered. In other words, the
transmission from the NVE to the Tenant System itself is out of the
scope of this section. Similarly the security used by the infrastructure
to steer Geneve Packets from a NVE to Geneve forwarding element is out
of scope either.
Isolation is only broken by rogue NVE or rogue Geneve forwarding
elements. In other words, breaking isolation using other elements or
other protocol layers are out of scope of this section
A Geneve NVE SHOULD be able to set different security policies
to different flows. These flows MUST be characterized from the Geneve
Header and Geneve Options as well as some inner traffic selectors.
Typically an NVE SHOULD be able to selectively authenticate only the
sections that are not authenticate by the Tenant System. If the Tenant
Systems authenticates its communications with TLS, only the IP, transport
(TCP / UDP) and TLS/DTLS section should be encrypted while only the IP
header and ESP header is expected to be encrypted when tenants'
communications are encrypted with ESP.
Suppose Tenant A and Tenant B are two distinct tenants and are
expected to remain isolated by the Geneve overlay network. The attacks
breaking the isolation considered in this section are the injection of
traffic into one virtual network as well as the redirection of one
tenant's traffic to a third party.
Traffic injection can target a specific element on the overlay
network such as, for example, an NVE, a Geneve forwarding element or
eventually specific Tenant System. On a overlay network perspective, the
difference of targeting a Tenant's System requires valid MAC and IP
addresses of the Tenant's System.
In order to provide integrity protection, 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 is independent from the Geneve overlay network and as such
provides protection against any node outside the virtual network
including the nodes of the Geneve overlay network to inject packets to a
Tenant System. On the other such protection does not protect the virtual
network from receiving illegitimate packets that may disrupt the
Tenant's System performances.
When Tenant Systems are protected against spoofed packets, the Geneve
overlay network may still prevent such spoofed Geneve Packet to be
steered into the virtual network. In addition, when the Tenant's System
have not enabled such protections, the overlay network should be able to
provide a secure infrastructure for hosting these virtual networks and
prevent a third party to inject traffic into the overlay. In this
section the third party is a node on the infrastructure hosting the
Geneve overlay network. In addition, this node could be any Geneve
element except the legitimate NVEs (source or destination).
A Geneve overlay network is composed of multiple Geneve forwarding
elements steering a Geneve Packet between the two NVEs. The Geneve
Packet is forwarded according to the information carried in the Geneve
Packet as well as routing tables associated to this information. For
that reason, the information carried in the Geneve Header, including
Geneve Option MUST be accessible by the intermediary nodes.
In order to prevent traffic injection in one virtual network, the
destination Geneve NVE MUST be able to authenticate the incoming traffic
sent by the source NVE. Note that this threat model assumes that the
third party injecting traffic does not inject traffic through the
NVEs.
Authentication of the whole Geneve Packet may raise the cost of
security unnecessarily. In fact it is expected that the Tenant Systems
will also protect their end-to-end traffic, as a result, corruption of
the Geneve Payload can be detected by the System Tenant. In addition,
for the ease of processing, an authenticated Geneve Packet should not
impact the processing of the intermediary nodes, unless they are able to
check the authentication themselves. A key advantage of validating the
authentication by intermediary nodes is that detection can occur
earlier, however such requirement may require the use of asymmetric
cryptography, which may be balanced by its low performance over
symmetric cryptography. As a result the following requirements are
associated with the authentication:
A Geneve NVE MUST be able to authenticate the Geneve Header including
the immutable Geneve Options.
A Geneve NVE MUST be able to agreement that authentication includes
or not the Geneve Payload, and if so it SHOULD also be able to indicate
that only a portion of it is authenticated.
A Geneve intermediary forwarding element MAY be able to validate the
authentication before the packet reaches the Geneve destination tunnel
end point.
A Geneve intermediary forwarding element MUST be able to insert an
authenticated Geneve Option into a authenticated Geneve Packet -
protected by the source Geneve tunnel termination point.
A Geneve intermediary forwarding element not supporting
authentication MUST NOT be impacted by the authentication of the Geneve
Packet and should be able to handle the Geneve Packet as an
non-authenticated Geneve Packet.
A Geneve NVE SHOULD be able to set different security policies
to different flows. These flows MUST be characterized from the Geneve
Header and Geneve Options as well as some inner traffic selectors.
Typically an NVE SHOULD be able to selectively encrypt only the
sections that are not encrypted by the Tenant System. If the Tenant
Systems encrypts its communications with TLS, only the IP, transport
(TCP / UDP) and TLS/DTLS section should be encrypted while only the IP
header and ESP header is expected to be encrypted when tenants'
communications are encrypted with ESP.
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, or for actively re-injecting a modified
Geneve Packet into the overlay.
Avoiding leaking information is hard to enforced at a Geneve level.
However, the Geneve overlay network and the Tenants Systems can lower
the consequences of such leakage in case these occurs. The Tenant System
may protect partly the data carries over the overlay network using
end-to-end encryption such as IPsec/TLS. Doing so provides integrity
protection as well as confidentiality for the Tenant's information. Such
protection applies even if the source or destination NVE are corrupted.
The purpose of the Geneve overlay network is to limit the information
it is aware of to leak. When Tenant Systems are enforcing
confidentiality of the information in transit with IPsec or TLS for
example, they are still some information revealed the MAC and IP headers
of the inner packet may remain unprotected. IN this case, the Geneve
overlay network should be able to maintain this information
confidential. When Tenant's have not enforced such security the Geneve
overlay network should be able to provide a secure infrastructure and
prevent leakage of information outside the virtual network. In
addition, the information carried by the Geneve Header may also reveal
some information on the overlay network itself, its deployment as well
as states from the Tenant System. In this the Geneve overlay network
should also be able to protect such Geneve Options.
Note that when the overlay network is hosted on an architecture that
belongs to another administrative domain, the administrator of the
infrastructure is typically able to perform passive monitoring
attacks.
In order to protect the Geneve communications between the Geneve
tunnel terminating points here are the following requirements:
A Geneve NVE MUST be able to agree that the Geneve Payload or portion
of it is encrypted as well as as immutable Geneve Options not intended
for the intermediary Geneve nodes.
A Geneve intermediary forwarding element MUST be able to insert an
encrypted Geneve Option into a authenticated Geneve Packet - protected
by the source Geneve tunnel termination point.
A Geneve intermediary forwarding element MUST be able to insert an
encrypted Geneve Option into an encrypted Geneve Packet - protected by
the source Geneve NVE.
A Geneve intermediary forwarding element not supporting encryption
MUST NOT be impacted by the authentication of the Geneve Packet and
should be able to handle the Geneve Packet as an non-protected Geneve
Packet.
Re-injection through a Geneve intermediary node is prevented by the
authentication. On the other hand, if the re-injection is performed
through one of the Geneve NVE, the protection provided by encryption as
well as authentication does not apply. The authentication is intended to
check integrity toward the data provided by the source Geneve NVE. If
that point is corrupted, it is likely to inject corrupted traffic with
integrity protection. On the other hand, if the destination Geneve NVE
is expected to validate the data, as a result if traffic is injected
through that node it is likely to bypass the integrity validation.
While Tenant isolation prevents one Tenant to inject packets into
another Tenants, it does not prevent a rogue or misconfigured node to
replay a packet, to load a specific Tenant System with a modified Geneve
payload or to abuse the Geneve overlay network.
A rogue Geneve overlay forwarding element on path of one Tenants
traffic may replay a valid packet to load the network. This can
typically be seen as a volumetric attack in order to disrupt the tenants
domain, a specific Tenant System or the multi Tenant infrastructure
itself. In some cases, especially when the tenants costs are evaluate on
the necessary computing resources, such attacks may target an increase
of the tenants costs.
When traffic between tenants is not protected, a rogue Geneve overlay
element may forward a modified packet over a valid Geneve Header. The
crafted packet may for example, include a specifically crafted
application payload intended for a specific Tenant Systems application.
Other examples includes a larger randomly craft payload intended to load
one specific application.
The Geneve forwarding policies are engineered according to the various
types of flows with their associated volumetry and requirements. For
example, some OAM flows are expected to be associated with a higher
priority then standard data plane flows. Similarly, the use of various
Geneve Header parameters or options may introduce different treatments.
Updating the Geneve header may result in counter all optimizations used
to setup a performant infrastructure and thus affect the tenants.
Note nodes that may address such attacks MUST be provided means to authenticate the Geneve Packet. More specifically,
In order to avoid the above mentioned attacks, the following
requirements should be considered:
Geneve Header SHOULD be bound to the forwarded
payload. By reading the Geneve Header and the Payload, the Geneve
forwarding element SHOULD be able to validate the Geneve Header
corresponds to the Geneve payload. In case of mismatch the Geneve
forwarding element is expected to discard the packet.
Geneve forwarding element SHOULD be provided anti
replay mechanisms. By reading the Geneve Header, the Geneve forwarding
element is expected to detect a packet has been replayed or at least
limit the replay windows. When a packet is detected as being replayed,
the Geneve forwarding element is expected to discard this packet.
The cloud provider managing the Geneve overlay network may be willing
to isolate the communications between Tenant Systems as well as the
organization of the Geneve overlay from the infrastructure. Such isolation
may be performed by encrypting the data in transit within the Geneve
overly network.
The main purpose for encrypting tenants communication inside the Geneve
overlay network is to prevent that external parties such a
infrastructure providers may access to the information exchanged between
Tenant System exchanged via the Geneve overlay network. A typical example
comes would be the infrastructure provider used by the Geneve overlay
network.
In addition, encryption of the data in transit in the Geneve overlay
network may also be one way to prevent the leakage of information when
tenant isolation is broken. Encryption is not expected to enforce tenant
isolation, but if information can hardly be used by another tenant it
may limit the interest in breaking such isolation to still information
as well as it might reduce the risks of leaking some confidential
information.
The requirements correspond to the those protecting against the
redirection or passive monitoring attacks in .
IPsec or TLS provides end-to-end encryption for NVE communications.
However, as the Geneve Header would be encrypted, these mechanisms
cannot be used are general mechanisms for the overlay network.
Encrypting Geneve payload by the NVE prevents disclosing the Geneve
payload to third party in case of leakage. However, such service is
provided by the cloud provider and the tenant has little control over
it. In most cases, if the tenant is willing to enforce data
confidentiality, it is recommended that it encrypts communications
between Tenants systems using IPsec or TLS. By doing so, the cloud
provider would not even have access to such information. While
encryption is being performed by the tenant, a cloud provider may be
willing to avoid re-encrypting that same content. Instead, the cloud
provider may prefer to only encrypt the tenants informations that have
not been encrypted by TLS or IPsec. Doing so is expected to reduce the
necessary resource for encrypting.
The requirements correspond to the those protecting against the
redirection or passive monitoring attacks in .
In addition, to the information exchanged between Tenant Systems, the
cloud provider may also avoid revealing the distribution of the Tenant
Systems through the data center. In fact a passive attacker may observe
the NVI in the Geneve header in order to derive the communication
pattern between the Tenant Systems. Other parameters or options may
reveal other kind of informations. One possibility is to encrypt the
information, but other transformations may also apply.
The requirements correspond to the those protecting against the
redirection or passive monitoring attacks in .
There are no IANA consideration for this document.
The whole document is about security.
Limiting the coverage of the authentication / encryption provides
some means for an attack to craft special packets.