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]