draft-ietf-nvo3-geneve-07.txt   draft-ietf-nvo3-geneve-08.txt 
Network Working Group J. Gross, Ed. Network Working Group J. Gross, Ed.
Internet-Draft Internet-Draft
Intended status: Standards Track I. Ganga, Ed. Intended status: Standards Track I. Ganga, Ed.
Expires: January 3, 2019 Intel Expires: April 10, 2019 Intel
T. Sridhar, Ed. T. Sridhar, Ed.
VMware VMware
July 02, 2018 October 07, 2018
Geneve: Generic Network Virtualization Encapsulation Geneve: Generic Network Virtualization Encapsulation
draft-ietf-nvo3-geneve-07 draft-ietf-nvo3-geneve-08
Abstract Abstract
Network virtualization involves the cooperation of devices with a Network virtualization involves the cooperation of devices with a
wide variety of capabilities such as software and hardware tunnel wide variety of capabilities such as software and hardware tunnel
endpoints, transit fabrics, and centralized control clusters. As a endpoints, transit fabrics, and centralized control clusters. As a
result of their role in tying together different elements in the result of their role in tying together different elements in the
system, the requirements on tunnels are influenced by all of these system, the requirements on tunnels are influenced by all of these
components. Flexibility is therefore the most important aspect of a components. Flexibility is therefore the most important aspect of a
tunnel protocol if it is to keep pace with the evolution of the tunnel protocol if it is to keep pace with the evolution of the
skipping to change at page 1, line 41 skipping to change at page 1, line 41
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 3, 2019. This Internet-Draft will expire on April 10, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 41 skipping to change at page 2, line 41
4.1.1. IP Fragmentation . . . . . . . . . . . . . . . . . . 17 4.1.1. IP Fragmentation . . . . . . . . . . . . . . . . . . 17
4.1.2. DSCP and ECN . . . . . . . . . . . . . . . . . . . . 17 4.1.2. DSCP and ECN . . . . . . . . . . . . . . . . . . . . 17
4.1.3. Broadcast and Multicast . . . . . . . . . . . . . . . 18 4.1.3. Broadcast and Multicast . . . . . . . . . . . . . . . 18
4.1.4. Unidirectional Tunnels . . . . . . . . . . . . . . . 18 4.1.4. Unidirectional Tunnels . . . . . . . . . . . . . . . 18
4.2. Constraints on Protocol Features . . . . . . . . . . . . 19 4.2. Constraints on Protocol Features . . . . . . . . . . . . 19
4.2.1. Constraints on Options . . . . . . . . . . . . . . . 19 4.2.1. Constraints on Options . . . . . . . . . . . . . . . 19
4.3. NIC Offloads . . . . . . . . . . . . . . . . . . . . . . 19 4.3. NIC Offloads . . . . . . . . . . . . . . . . . . . . . . 19
4.4. Inner VLAN Handling . . . . . . . . . . . . . . . . . . . 20 4.4. Inner VLAN Handling . . . . . . . . . . . . . . . . . . . 20
5. Interoperability Issues . . . . . . . . . . . . . . . . . . . 20 5. Interoperability Issues . . . . . . . . . . . . . . . . . . . 20
6. Security Considerations . . . . . . . . . . . . . . . . . . . 21 6. Security Considerations . . . . . . . . . . . . . . . . . . . 21
6.1. Data Confidentiality . . . . . . . . . . . . . . . . . . 21 6.1. Data Confidentiality . . . . . . . . . . . . . . . . . . 22
6.1.1. Inter-data center traffic . . . . . . . . . . . . . . 22 6.1.1. Inter-data center traffic . . . . . . . . . . . . . . 22
6.2. Data Integrity . . . . . . . . . . . . . . . . . . . . . 22 6.2. Data Integrity . . . . . . . . . . . . . . . . . . . . . 22
6.3. Authentication of NVE peers . . . . . . . . . . . . . . . 23 6.3. Authentication of NVE peers . . . . . . . . . . . . . . . 23
6.4. Multicast/Broadcast . . . . . . . . . . . . . . . . . . . 23 6.4. Multicast/Broadcast . . . . . . . . . . . . . . . . . . . 23
6.5. Control plane communications . . . . . . . . . . . . . . 24 6.5. Control plane communications . . . . . . . . . . . . . . 24
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 25 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 25
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 26
10.1. Normative References . . . . . . . . . . . . . . . . . . 26 10.1. Normative References . . . . . . . . . . . . . . . . . . 26
skipping to change at page 21, line 46 skipping to change at page 21, line 46
operated in environments controlled by the service provider, such as operated in environments controlled by the service provider, such as
the hypervisor itself rather than within a customer VM. the hypervisor itself rather than within a customer VM.
When crossing an untrusted link, such as the public Internet, IPsec When crossing an untrusted link, such as the public Internet, IPsec
[RFC4301] may be used to provide authentication and/or encryption of [RFC4301] may be used to provide authentication and/or encryption of
the IP packets formed as part of Geneve encapsulation. the IP packets formed as part of Geneve encapsulation.
Geneve does not otherwise affect the security of the encapsulated Geneve does not otherwise affect the security of the encapsulated
packets. As per the guidelines of BCP72 [RFC3552], the following packets. As per the guidelines of BCP72 [RFC3552], the following
sections describe potential security risks that may be applicable to sections describe potential security risks that may be applicable to
Geneve deployments and approaches to mitigate such risks. Geneve deployments and approaches to mitigate such risks. It is also
noted that not all such risks are applicable to all Geneve deployment
scenarios, i.e., only a subset may be applicable to certain
deployments. So an operator has to make an assessment based on their
network environment and determine the risks that are applicable to
their specific environment and use appropriate mitigation approaches
as applicable.
6.1. Data Confidentiality 6.1. Data Confidentiality
Geneve is a network virtualization overlay encapsulation protocol Geneve is a network virtualization overlay encapsulation protocol
designed to establish tunnels between network virtualization end designed to establish tunnels between network virtualization end
points (NVE) over an existing IP network. It can be used to deploy points (NVE) over an existing IP network. It can be used to deploy
multi-tenant overlay networks over an existing IP underlay network in multi-tenant overlay networks over an existing IP underlay network in
a public or private data center. The overlay service is typically a public or private data center. The overlay service is typically
provided by a service provider, for example a cloud services provider provided by a service provider, for example a cloud services provider
or a private data center operator. Due to the nature of multi- or a private data center operator. Due to the nature of multi-
tenancy in such environments, a tenant system may expect data tenancy in such environments, a tenant system may expect data
confidentiality to ensure its packet data is not tampered with confidentiality to ensure its packet data is not tampered with
(active attack) in transit or a target of unauthorized monitoring (active attack) in transit or a target of unauthorized monitoring
(passive attack). A tenant may expect the overlay service provider (passive attack). A tenant may expect the overlay service provider
to provide data confidentiality as part of the service or a tenant to provide data confidentiality as part of the service or a tenant
may bring its own data confidentiality mechanisms like IPsec or TLS may bring its own data confidentiality mechanisms like IPsec or TLS
to protect the data end to end between its tenant systems. to protect the data end to end between its tenant systems.
An NVE, used in multi-tenant environments, MUST have the capability If an operator determines data confidentiality is necessary in their
to encrypt the tenant data end to end between the NVEs. The NVEs may environment based on their risk analysis, for example as in multi-
tenant environments, then an encryption mechanism SHOULD be used to
encrypt the tenant data end to end between the NVEs. The NVEs may
use existing well established encryption mechanisms such as IPsec, use existing well established encryption mechanisms such as IPsec,
DTLs, etc., The NVEs SHOULD have a configurable option to disable the DTLs, etc., The operator may choose not to enable the encryption if,
encryption if, for example, the packet data is already encrypted by for example, the packet data is already encrypted by the tenant
the tenant system. system.
6.1.1. Inter-data center traffic 6.1.1. Inter-data center traffic
A tenant system in a customer premises (private data center) may want A tenant system in a customer premises (private data center) may want
to connect to tenant systems on their tenant overlay network in a to connect to tenant systems on their tenant overlay network in a
public cloud data center or a tenant may want to have its tenant public cloud data center or a tenant may want to have its tenant
systems located in multiple geographically separated data centers for systems located in multiple geographically separated data centers for
high availability. Geneve data traffic between tenant systems across high availability. Geneve data traffic between tenant systems across
such separated networks should be protected from threats when such separated networks should be protected from threats when
traversing public networks. Any Geneve overlay data leaving the data traversing public networks. Any Geneve overlay data leaving the data
center network, beyond the operators security domain, for example center network beyond the operator's security domain, for example
over a public Internet SHOULD be secured by encryption mechanisms over the public Internet, SHOULD be secured by encryption mechanisms
such as IPsec or other VPN mechanisms to protect the communications such as IPsec or other VPN mechanisms to protect the communications
between the NVEs when they are geographically separated over between the NVEs when they are geographically separated over
untrusted network links. Implementation of specific data protection untrusted network links. Implementation of specific data protection
mechanisms employed between data centers is beyond the scope of this mechanisms employed between data centers is beyond the scope of this
document. document.
6.2. Data Integrity 6.2. Data Integrity
Geneve encapsulation is used between NVEs to establish overlay Geneve encapsulation is used between NVEs to establish overlay
tunnels over an existing IP underlay network. In a multi-tenant data tunnels over an existing IP underlay network. In a multi-tenant data
skipping to change at page 23, line 12 skipping to change at page 23, line 19
not to forward unauthorized traffic between TSs in different tenant not to forward unauthorized traffic between TSs in different tenant
networks. networks.
A compromised network node or a transit device within a data center A compromised network node or a transit device within a data center
may launch an active attack trying to tamper with the Geneve packet may launch an active attack trying to tamper with the Geneve packet
data between NVEs. Malicious tampering of Geneve header fields may data between NVEs. Malicious tampering of Geneve header fields may
cause the packet from one tenant to be forwarded to a different cause the packet from one tenant to be forwarded to a different
tenant network. If an operator determines the possibility of such tenant network. If an operator determines the possibility of such
threat in their environment, the operator may choose to employ data threat in their environment, the operator may choose to employ data
integrity mechanisms between NVEs. In order to prevent such risks, a integrity mechanisms between NVEs. In order to prevent such risks, a
Geneve NVE MUST have the capability to protect the integrity of data integrity mechanism SHOULD be used in such environments to
Geneve packets including packet headers, options and payload on protect the integrity of Geneve packets including packet headers,
communications between NVE pairs. A cryptographic data protection options and payload on communications between NVE pairs. A
mechanism such as IPsec may be used to provide data integrity cryptographic data protection mechanism such as IPsec may be used to
protection. The NVE SHOULD have a configuration option to enable or provide data integrity protection. A data center operator may choose
disable the data integrity protection, based on the presence of to deploy any other data integrity mechanisms as applicable and
threats in their environment. A data center operator may choose to
deploy any other data integrity mechanisms as applicable and
supported in their underlay networks. supported in their underlay networks.
Geneve supports Geneve Options, so an operator may choose to use a Geneve supports Geneve Options, so an operator may choose to use a
Geneve option TLV to provide a cryptographic data protection Geneve option TLV to provide a cryptographic data protection
mechanism, to verify the data integrity of the Geneve header, Geneve mechanism, to verify the data integrity of the Geneve header, Geneve
options or the entire Geneve packet including the payload. options or the entire Geneve packet including the payload.
Implementation of such a mechanism is beyond the scope of this Implementation of such a mechanism is beyond the scope of this
document. document.
6.3. Authentication of NVE peers 6.3. Authentication of NVE peers
A rogue network device or a compromised NVE in a data center A rogue network device or a compromised NVE in a data center
environment might be able to spoof Geneve packets as if it came from environment might be able to spoof Geneve packets as if it came from
a legitimate NVE. In order to mitigate such a risk, a Geneve NVE a legitimate NVE. In order to mitigate such a risk, an operator
MUST support an Authentication mechanism, such as IPsec AH, to ensure SHOULD use an Authentication mechanism, such as IPsec to ensure that
that the Geneve packet originated from the intended NVE peer, in the Geneve packet originated from the intended NVE peer, in
environments where spoofing or rogue devices is a potential threat. environments where the operator determines spoofing or rogue devices
Other simpler source checks such as ingress filtering for VLAN/MAC/IP is a potential threat. Other simpler source checks such as ingress
address, reverse path forwarding checks, etc., may be used in certain filtering for VLAN/MAC/IP address, reverse path forwarding checks,
trusted environments to ensure Geneve packets originated from the etc., may be used in certain trusted environments to ensure Geneve
intended NVE peer. packets originated from the intended NVE peer.
6.4. Multicast/Broadcast 6.4. Multicast/Broadcast
In typical data center networks where IP multicasting is not In typical data center networks where IP multicasting is not
supported in the underlay network, multicasting can be supported supported in the underlay network, multicasting may be supported
using multiple unicast tunnels. The same security requirements as using multiple unicast tunnels. The same security requirements as
described in the above sections can be used to protect Geneve described in the above sections can be used to protect Geneve
communications between NVE peers. If IP multicasting is supported in communications between NVE peers. If IP multicasting is supported in
the underlay network and the operator chooses to use it for multicast the underlay network and the operator chooses to use it for multicast
traffic among Geneve endpoints, then Geneve NVEs used in such traffic among Geneve endpoints, then the operator in such
environments SHOULD support data protection mechanisms such as IPsec environments may use data protection mechanisms such as IPsec with
with Multicast extensions [RFC5374] to protect multicast traffic Multicast extensions [RFC5374] to protect multicast traffic among
among Geneve NVE groups. Geneve NVE groups.
6.5. Control plane communications 6.5. Control plane communications
A Network Virtualization Authority (NVA) as outlined in [RFC8014] may A Network Virtualization Authority (NVA) as outlined in [RFC8014] may
be used as a control plane for configuring and managing the Geneve be used as a control plane for configuring and managing the Geneve
NVEs. The data center operator is expected to use security NVEs. The data center operator is expected to use security
mechanisms to protect the communications between the NVA to NVEs and mechanisms to protect the communications between the NVA to NVEs and
use authentication mechanisms to detect any rogue or compromised NVEs use authentication mechanisms to detect any rogue or compromised NVEs
within their administrative domain. Data protection mechanisms for within their administrative domain. Data protection mechanisms for
control plane communication or authentication mechanisms between the control plane communication or authentication mechanisms between the
 End of changes. 13 change blocks. 
34 lines changed or deleted 40 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/