[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06

NVO3                                                          D. Migault
Internet-Draft                                                  Ericsson
Intended status: Informational                                S. Boutros
Expires: September 1, 2019                                      D. Wings
                                                            VMware, Inc.
                                                             S. Krishnan
                                                                  Kaloom
                                                       February 28, 2019


                      Geneve Security Requirements
            draft-mglt-nvo3-geneve-security-requirements-06

Abstract

   The document defines the security requirements to protect tenants
   overlay traffic against security threats from the NVO3 network
   components that are interconnected with tunnels implemented using
   Generic Network Virtualization Encapsulation (Geneve).

   The document provides two sets of security requirements: 1.
   requirements to evaluate the data plane security of a given
   deployment of Geneve overlay.  Such requirements are intended to
   Geneve overlay provider to evaluate a given deployment.
   2. requirement a security mechanism need to fulfill to secure any
   deployment of Geneve overlay deployment

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on September 1, 2019.








Migault, et al.         Expires September 1, 2019               [Page 1]


Internet-Draft        Geneve Security Requirements         February 2019


Copyright Notice

   Copyright (c) 2019 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Requirements Notation . . . . . . . . . . . . . . . . . . . .   3
   2.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   6
   4.  Security Threats  . . . . . . . . . . . . . . . . . . . . . .   6
     4.1.  Passive Attacks . . . . . . . . . . . . . . . . . . . . .   6
     4.2.  Active Attacks  . . . . . . . . . . . . . . . . . . . . .   7
   5.  Requirements for Security Mitigations . . . . . . . . . . . .   8
     5.1.  Protection Against Traffic Sniffing . . . . . . . . . . .   8
       5.1.1.  Operational Security Requirements . . . . . . . . . .   9
       5.1.2.  Geneve Security Requirements  . . . . . . . . . . . .  10
     5.2.  Protecting Against Traffic Injection  . . . . . . . . . .  10
       5.2.1.  Operational Security Requirements . . . . . . . . . .  12
       5.2.2.  Geneve Security Requirements  . . . . . . . . . . . .  13
     5.3.  Protecting Against Traffic Redirection  . . . . . . . . .  13
     5.4.  Protecting Against Traffic Replay . . . . . . . . . . . .  14
       5.4.1.  Geneve Security Requirements  . . . . . . . . . . . .  14
       5.4.2.  Geneve Security Requirements  . . . . . . . . . . . .  15
     5.5.  Security Management . . . . . . . . . . . . . . . . . . .  15
       5.5.1.  Operational Security Requirements . . . . . . . . . .  15
       5.5.2.  Geneve Security Requirements  . . . . . . . . . . . .  15
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  16
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  16
   8.  Appendix  . . . . . . . . . . . . . . . . . . . . . . . . . .  16
     8.1.  DTLS  . . . . . . . . . . . . . . . . . . . . . . . . . .  16
       8.1.1.  Operational Security Requirements . . . . . . . . . .  16
       8.1.2.  Geneve Security Requirements  . . . . . . . . . . . .  18
     8.2.  IPsec . . . . . . . . . . . . . . . . . . . . . . . . . .  20
       8.2.1.  Operational Security Requirements . . . . . . . . . .  20
       8.2.2.  Geneve Security Requirements  . . . . . . . . . . . .  21
   9.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  23
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  23



Migault, et al.         Expires September 1, 2019               [Page 2]


Internet-Draft        Geneve Security Requirements         February 2019


     10.1.  Normative References . . . . . . . . . . . . . . . . . .  23
     10.2.  Informative References . . . . . . . . . . . . . . . . .  25
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  25

1.  Requirements Notation

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described BCP 14
   [RFC2119] [RFC8174] when, and only when, they appear in all capitals,
   as shown here.

2.  Introduction

   The network virtualization overlay over Layer 3 (NVO3) as depicted in
   Figure 1, allows an overlay cloud provider to provide a logical L2/L3
   interconnect for the Tenant Systems TSes that belong to a specific
   tenant network.  A packet received from a TS is encapsulated by the
   ingress Network Virtualization Edge (NVE).  The encapsulated packet
   is then sent to the remote NVE through a tunnel.  When reaching the
   egress NVE of the tunnel, the packet is decapsulated and forwarded to
   the target TS.  The L2/L3 address mappings to the remote NVE(s) are
   distributed to the NVEs by a logically centralized Network
   Virtualization Authority (NVA) or using a distributed control plane
   such as Ethernet-VPN.  In a datacenter, the NVO3 tunnels can be
   implemented using Generic Network Virtualization Encapsulation
   (Geneve) [I-D.ietf-nvo3-geneve].  Such Geneve tunnels establish NVE-
   to-NVE communications, may transit within the data center via Transit
   device.  The Geneve tunnels overlay network enable multiple Virtual
   Networks to coexist over a shared underlay infrastructure, and a
   Virtual Network may span a single data center or multiple data
   centers.

   The underlay infrastructure on which the multi-tenancy overlay
   networks are hosted, can be owned and provided by an underlay
   provider who may be different from the overlay cloud provider.















Migault, et al.         Expires September 1, 2019               [Page 3]


Internet-Draft        Geneve Security Requirements         February 2019


   +--------+                                    +--------+
   | Tenant +--+                            +----| Tenant |
   | System |  |                           (')   | System |
   +--------+  |    .................     (   )  +--------+
               |  +---+           +---+    (_)
               +--|NVE|---+   +---|NVE|-----+
                  +---+   |   |   +---+
                  / .    +-----+      .
                 /  . +--| NVA |      .
                /   . |  +-----+      .
               |    . |               .
               |    . |  L3 Overlay +--+--++--------+
   +--------+  |    . |   Network   | NVE || Tenant |
   | Tenant +--+    . |             |     || System |
   | System |       .  \ +---+      +--+--++--------+
   +--------+       .....|NVE|.........
                         +---+
                           |
                           |
                 =====================
                   |               |
               +--------+      +--------+
               | Tenant |      | Tenant |
               | System |      | System |
               +--------+      +--------+

   Figure 1: Generic Reference Model for Network Virtualization Overlays
   [RFC7365]

   This document discusses the security risks that a Geneve based NVO3
   network may encounter.  In addition, this document lists the
   requirements to protect the Geneve packet components defined in
   [I-D.ietf-nvo3-geneve] that include the Geneve tunnel IP and UDP
   header, the Geneve Header, Geneve options, and inner payload.

   The document provides two sets of security requirements:

   1.  SEC-OP: requirements to evaluate a given deployment of Geneve
       overlay.  Such requirements are intended to Geneve overlay
       provider to evaluate a given deployment.  Security of the Geneve
       packet may be achieved using various mechanisms.  Typically, some
       deployments may use a limited subset of the capabilities provided
       by Geneve and rely on specific assumptions.  Given these
       specificities, the secure deployment of a given Geneve deployment
       may be achieved reusing specific mechanisms such as for example
       DTLS [RFC6347] or IPsec [RFC4301].  On the other hand, the
       definition of a security mechanisms that enables to secure any
       Geneve deployment requires the design of a Geneve specific



Migault, et al.         Expires September 1, 2019               [Page 4]


Internet-Draft        Geneve Security Requirements         February 2019


       mechanism.  Note that the security s limited to the security of
       the data plane only.  Additional requirements for the control
       plan MAY be considered in [I-D.ietf-nvo3-security-requirements].
       A given Geneve deployment will be considered secured when
       matching with all SEC-OP requirements does not raises any
       concern.  As such the given deployment will be considered passing
       SEC-OP requirements that are not applicable.

   2.  SEC-GEN: requirements a security mechanism need to fulfill to
       secure any deployment of Geneve overlay deployment.  Such
       mechanism may require the design of a specific solution.  In the
       case new protocol needs to be design, the document strongly
       recommend to re-use existing security protocols like IP Security
       (IPsec) [RFC4301] and Datagram Transport Layer Security (DTLS)
       [RFC6347], and existing encryption algorithms (such as
       [RFC8221]), and authentication protocols.  A given candidate for
       a security mechanism will be considered as valid when matching
       with all SEC-GEN requirements does not raise any concern.  In
       other words, at least all MUST status are met.

   This document assumes the following roles are involved: - Tenant:
   designates the entity that connects various systems within a single
   virtualized network.  The various system can typically be containers,
   VMs implementing a single or various functions.
   - Geneve Overlay Provider: provides the Geneve overlay that
   seamlessly connect the various Tenant Systems over a given
   virtualized network.
   - Infrastructure Provider: provides the infrastructure that runs the
   Geneve overlay network as well as the Tenant System.  A given
   deployment may consider different infrastructure provider with
   different level of trust.  Typically the Geneve overlay network may
   use a public cloud to extend the resource of a private cloud.
   Similarly, a edge computing may extend its resources using resource
   of the core network.

   Tenant, Geneve Overlay Provider and Infrastructure Provider can be
   implemented by a single or various different entities with different
   level of trust between each other.  The simplest deployment may
   consists in a single entity running its systems in its data center
   and using Geneve in order to manage its internal resources.  A more
   complex use case may consider that a Tenant subscribe to the Geneve
   Overlay Provider which manage the virtualized network over various
   type of infrastructure.  The trust between the Tenant, Geneve Overlay
   Provider and Infrastructure Provider may be limited.

   Given the different relations between Tenant, Geneve Overlay Provider
   and Infrastructure Provider, this document aims providing
   requirements to ensure: 1.  The Geneve Overlay Provider delivers



Migault, et al.         Expires September 1, 2019               [Page 5]


Internet-Draft        Geneve Security Requirements         February 2019


   tenant payload traffic (Geneve inner payload) and ensuring privacy
   and integrity.  2.  The Geneve Overlay Provider provides the
   necessary means to prevent injection or redirection of the Tenant
   traffic from a rogue node in the Geneve overlay network or a rogue
   node from the infrastructure.  3.  The Geneve Overlay Provider can
   rely on the Geneve overlay in term of robustness and reliability of
   the signaling associated to the Geneve packets (Geneve tunnel header,
   Geneve header and Geneve options) in order to appropriately manage
   its overlay.

3.  Terminology

   This document uses the terminology of [RFC8014], [RFC7365] and
   [I-D.ietf-nvo3-geneve].

4.  Security Threats

   This section considers attacks performed by NVE, network devices or
   any other devices using Geneve, that is when the attackers knowing
   the details of the Geneve packets can perform their attacks by
   changing fields in the Geneve tunnel header, base header, Geneve
   options and Geneve inner payload.  Attacks related to the control
   plane are outside the scope of this document.  The reader is
   encouraged to read [I-D.ietf-nvo3-security-requirements] for a
   similar threat analysis of NVO3 overlay networks.

   Threats include traffic analysis, sniffing, injection, redirection,
   and replay.  Based on these threats, this document enumerates the
   security requirements.

   Threats are divided into two categories: passive attack and active
   attack.

   Threats are always associated with risks and the evaluation of these
   risks depend among other things on the environment.

4.1.  Passive Attacks

   Passive attacks include traffic analysis (noticing which workloads
   are communicating with which other workloads, how much traffic, and
   when those communications occur) and sniffing (examining traffic for
   useful information such as personally-identifyable information or
   protocol information (e.g., TLS certificate, overlay routing
   protocols).

   Passive attacks may also consist in inferring information about a
   virtualized network or some Tenant System from observing the Geneve
   traffic.  This could also involve the correlation between observed



Migault, et al.         Expires September 1, 2019               [Page 6]


Internet-Draft        Geneve Security Requirements         February 2019


   traffic and additional information.  For example, a passive network
   observer can determine two virtual machines are communicating by
   manipulating activity or network activity of other virtual machines
   on that same host.  For example, the attacker could control (or be
   otherwise aware of) network activity of the other VMs running on the
   same host, and deduce other network activity is due to a victim VM.

   A rogue element of the overlay Geneve network under the control of an
   attacker may leak and redirect the traffic from a virtual network to
   the attacker for passive monitoring [RFC7258].

   Avoiding leaking information is hard to enforced.  The security
   requirements provided in section {{sniffing} expect to mitigate such
   attacks by lowering the consequences, typically making leaked data
   unusable to an attacker.

4.2.  Active Attacks

   Active attacks involve modifying Geneve packets, injecting Geneve
   packets, or interfering with Geneve packet delivery (such as by
   corrupting packet checksum).  Active attack may target the Tenant
   System or the Geneve overlay.

   There are multiple motivations to inject illegitimate traffic into a
   tenants network.  When the rogue element is on the path of the TS
   traffic, it may be able to inject and receive the corresponding
   messages back.  On the other hand, if the attacker is not on the path
   of the TS traffic it may be limited to only inject traffic to a TS
   without receiving any response back.  When rogue element have access
   to the traffic in both directions, the possibilities are only limited
   by the capabilities of the other on path elements - Transit device,
   NVE or TS - to detect and protect against the illegitimate traffic.
   On the other hand, when the rogue element is not on path, the surface
   for such attacks remains still quite large.  For example, an attacker
   may target a specific TS or application by crafting a specific packet
   that can either generate load on the system or crash the system or
   application.  TCP syn flood typically overload the TS while not
   requiring the ability to receive responses.  Note that udp
   application are privileged target as they do not require the
   establishment of a session and are expected to treat any incoming
   packets.

   Traffic injection may also be used to flood the virtual network to
   disrupt the communications between the TS or to introduce additional
   cost for the tenant, for example when pricing considers the traffic
   inside the virtual network.  The two latest attacks may also take
   advantage of applications with a large factor of amplification for
   their responses as well as applications that upon receiving a packet



Migault, et al.         Expires September 1, 2019               [Page 7]


Internet-Draft        Geneve Security Requirements         February 2019


   interact with multiple TS.  Similarly, applications running on top of
   UDP are privileged targets.

   Note also that an attacker that is not able to receive the response
   traffic, may use other channels to evaluate or measure the impact of
   the attack.  Typically, in the case of a service, the attacker may
   have access, for example, to a user interface that provides
   indication on the level of disruption and the success of an attack,
   Such feed backs may also be used by the attacker to discover or scan
   the network.

   Preventing traffic to cross virtual networks, reduce the surface of
   attack, but rogue element main still perform attacks within a given
   virtual network by replaying a legitimate packet.  Some variant of
   such attack also includes modification of unprotected parts when
   available in order for example to increase the payload size.

5.  Requirements for Security Mitigations

   The document assumes that Security protocols, algorithms, and
   implementations provide the security properties for which they are
   designed, an attack caused by a weakness in a cryptographic algorithm
   is out of scope.  The algorithm used MUST follow the cryptographic
   guidance such as [RFC8247], [RFC8221] or [RFC7525].  In this context,
   when the document mentions encryption, it assumes authenticated
   encryption.

   Protecting network connecting TSes and NVEs which could be accessible
   to outside attackers is out of scope.

   An attacker controlling an underlying network device may break the
   communication of the overlays by discarding or delaying the delivery
   of the packets passing through it.  The security consideration to
   prevent this type of attack is out of scope of this document.

   Securing communication between NVAs and NVEs is out of scope.

   Selectively providing integrity / authentication, confidentiality /
   encryption of only portions of the Geneve packet is in scope.  This
   will be the case if the Tenant Systems uses security protocol to
   protect its communications.

5.1.  Protection Against Traffic Sniffing

   The inner payload, unless protection is provided by the Tenant System
   reveals the content of the communication.  This may be mitigate by
   the Tenant using application level security such as, for example JSON
   Web Encryption [RFC7516] or transport layer security such as DTLS



Migault, et al.         Expires September 1, 2019               [Page 8]


Internet-Draft        Geneve Security Requirements         February 2019


   [RFC6347] or TLS [RFC8446] or IPsec/ESP [RFC4303].  However none of
   these security protocols are sufficient to protect the entire inner
   payload.  IPsec/ESP still leave in clear the optional L2 layer
   information as well as the IP addresses and some IP options.  In
   addition to these pieces of information, the use of TLS or DTLS
   reveals the transport layer protocol as well as ports.  As a result,
   the confidentiality protection of the inner packet may be handled
   either entirely by the Geneve Overlay Provider, or partially by the
   Tenant or handled by both the Tenant and the Geneve Overlay Provider.

   The Geneve Header contains information related to the Geneve
   communications or metadata designated as Geneve Information.  Geneve
   Information is carried on the Geneve Outer Header, the Geneve Header
   (excluding Geneve Options) as well as in the Geneve Options.  Geneve
   Information needs to be accessed solely by a NVE or transit device
   while other Geneve Information may need to be accessed by other
   transit devices.  More specifically, a subset of the information
   contained in the Geneve Header (excluding Geneve Options) as well as
   a subset of (none, one or multiple Geneve Option) may be accessed by
   a transit device or the NVE while the others needs to be accessed by
   other transit devices.  The confidentiality protection of the Geneve
   Information is handled by the Geneve Overlay Provider.

   In addition to Geneve Information, the traffic generated for the
   Geneve overlay may be exposed to traffic volumetry and pattern
   analysis within a virtualized network.  Confidentiality protection
   against traffic pattern recognition is handled by the Geneve Overlay
   Provider.

5.1.1.  Operational Security Requirements

   A secure deployment of a Geneve overlay must fulfill the requirement
   below:

   o  SEC-OP-1: A secure deployment of a Geneve overlay SHOULD by
      default encrypt the inner payload.  A Geneve overlay provider MAY
      disable this capability for example when encryption is performed
      by the Tenant System and that level of confidentiality is believed
      to be sufficient.  In order to provide additional protection to
      traffic already encrypted by the Tenant the Geneve network
      operator MAY partially encrypt the clear part of the inner
      payload.

   o  SEC-OP-2: A secure deployment of a Geneve overlay MUST evaluate
      the information associated to the leakage of Geneve Information
      carried by the Geneve Packet.  When a risk analysis concludes that
      the risk of leaking sensitive information is too high, such Geneve
      Information MUST NOT be transmit in clear text.



Migault, et al.         Expires September 1, 2019               [Page 9]


Internet-Draft        Geneve Security Requirements         February 2019


   o  SEC-OP-3: A secure deployment of a Geneve overlay MUST evaluate
      the risk associated to traffic pattern recognition.  When a risk
      has been identified, traffic pattern recognition MUST be addressed
      with padding policies as well as generation of dummy packets.

5.1.2.  Geneve Security Requirements

   A Geneve security mechanism must fulfill the requirements below:

   o  SEC-GEN-1: Geneve security mechanism MUST provide the capability
      to encrypt the inner payload.

   o  SEC-GEN-2: Geneve security mechanism SHOULD provide the capability
      to partially encrypt the inner payload header.

   o  SEC-GEN-3: Geneve security mechanism MUST provide means to encrypt
      a single or a set of zero, one or multiple Geneve Options while
      leave other Geneve Options in clear.  Reversely, a Geneve security
      mechanism MUST be able to leave a Geneve option in clear, while
      encrypting the others.

   o  SEC-GEN-4: Geneve security mechanism MUST provide means to encrypt
      the information of Geneve Header (excluding Geneve Options).
      Reversely, a Geneve security mechanism MUST be able to leave in
      clear Geneve Header information (Geneve Options excluded) while
      encrypting the other.

   o  SEC-GEN-5: Geneve security mechanisms MUST provide the ability to
      provide confidentiality protection between multiple nodes, i.e.
      multiple transit devices and a NVE.

   o  SEC-GEN-6: Geneve security mechanism MUST provide the ability to
      pad a Geneve packet.

   o  SEC-GEN-7: Geneve security mechanism MUST provide the ability to
      send dummy packets.

5.2.  Protecting Against Traffic Injection

   Traffic injection from a rogue non legitimate NVO3 Geneve overlay
   device or a rogue underlay transit device can target an NVE, a
   transit underlay device or a Tenant System.  Targeting a Tenant's
   System requires a valid MAC and IP addresses of the Tenant's System.

   When traffic between tenants is not protected, the rogue device may
   forward the modified packet over a valid (authenticated) Geneve
   Header.  The crafted packet may for example, include a specifically
   crafted application payload for a specific Tenant Systems



Migault, et al.         Expires September 1, 2019              [Page 10]


Internet-Draft        Geneve Security Requirements         February 2019


   application, with the intention to load the tenant specific
   application.  Tenant's System may provide integrity protection of the
   inner payload by protect their communications using for example
   IPsec/ESP, IPsec/AH [RFC4302], TLS or DTLS.  Such protection protects
   at various layers the Tenants from receiving spoofed packets, as any
   injected packet is expected to be discarded by the destination
   Tenant's System.  Note IPsec/ESP with NULL encryption may be used to
   authenticate-only the layers above IP in which case the IP header
   remains unprotected.  However IPsec/AH enables the protection of the
   entire IP packet, including the IP header.  As a result, when Geneve
   encapsulates IP packets the Tenant has the ability to integrity
   protect the IP packet on its own, without relying on the Geneve
   overlay network.  On the other hand, L2 layers remains unprotected.
   As encryption is using authenticated encryption, authentication may
   also be provided via encryption.  At the time of writing the document
   DTLS 1.3 [I-D.ietf-tls-dtls13] is still a draft document and TLS 1.3
   does not yet provide the ability for authenticate only the traffic.
   As such it is likely that the use of DTLS1.3 may not involve
   authentication-only cipher suites.  Similarly to confidentiality
   protection, integrity protection may be handled either entirely by
   the Geneve Overlay Provider, or partially by the Tenant or handled by
   both the Tenant and the Geneve Overlay Provider.

   In addition to confidentiality protection of the inner payload,
   integrity protection also prevents the Tenant System from receiving
   illegitimate packets that may disrupt the Tenant's System
   performance.  The Geneve overlay network need to prevent the overlay
   to be used as a vector to spoof packets being steered to the Tenant's
   system.  As a result, the Overlay Network Provider needs to ensure
   that inner packets steered to the Tenant's network are only
   originating from one Tenant System and not from an outsider using the
   Geneve Overlay to inject packets to one virtual network.  As such,
   the destination NVE MUST be able to authenticate the incoming Geneve
   packets from the source NVE.  This may be performed by the NVE
   authenticating the full Geneve Packet.  When the Geneve Overlay wants
   to take advantage of the authentication performed by the Tenant
   System, the NVE shoudl be able to perform some checks between the
   Geneve Header and the inner payload.  Suppose two Geneve packets are
   composed of a Geneve Header (H1, and H2) and a inner payload (P1 and
   P2).  Suppose H1, H2, P1 and P2 are authenticated.  The replacement
   of P2 by P1 by an attacker will be detected by the NVE only if there
   is a binding between H2 and P2.  Such integrity protection is handled
   by the Geneve Overlay Provider.

   While traffic injection may target the Tenant's virtual network or a
   specific Tenant System, traffic injection may also target the Geneve
   Overlay Network by injecting Geneve Options that will affect the
   processing of the Geneve Packet.  Updating the Geneve header and



Migault, et al.         Expires September 1, 2019              [Page 11]


Internet-Draft        Geneve Security Requirements         February 2019


   option parameters such as setting an OAM bit, adding bogus option
   TLVs, or setting a critical bit, may result in different processing
   behavior, that could greatly impact performance of the overlay
   network and the underlay infrastructure and thus affect the tenants
   traffic delivery.  As such, the Geneve Overlay should provide
   integrity protection of the Geneve Information present in the Geneve
   Header to guarantee Geneve processing is not altered.

   The Geneve architecture considers transit devices that may process
   some Geneve Options.  More specifically, a Geneve packet may have A
   subset of Geneve Information of the Geneve Header (excluding Geneve
   Options) as well as a set of zero, one or multiple of Geneve Options
   accessed by one or more transit devices.  This information needs to
   be authenticated by a transit device while other options may be
   authenticated by other transit devices or the tunnel endpoint.  The
   integrity protection is handled by the Geneve Overlay Provider and
   authentication MUST be performed prior any processing.

5.2.1.  Operational Security Requirements

   A secure deployment of a Geneve overlay must fulfill the requirement
   below:

   o  SEC-OP-4: A secure deployment of a Geneve overlay MUST provide the
      capability authenticate the inner payload when encryption is not
      provided.  A Geneve overlay provider MAY disable this capability
      for example when this is performed by the Tenant System and that
      level of integrity is believed to be sufficient.  In order to
      provide additional protection to traffic already protected by the
      Tenant the Geneve network operator MAY partially protect the
      unprotected part of the inner payload.

   o  SEC-OP-5: A secure deployment of a Geneve overlay MUST evaluate
      the risk associated to a change of the Geneve Outer Header, Geneve
      Header (excluding Geneve Options) and Geneve Option.  When a risk
      analysis concludes that the risk is too high, this piece of
      information MUST be authenticated.

   o  SEC-OP-6: A secure deployment of a Geneve overlay SHOULD
      authenticate communications between NVE to protect the Geneve
      Overlay infrastructure as well as the Tenants System's
      communications (Geneve Packet).  A Geneve overlay provider MAY
      disable authentication of the inner packet and delegates it to the
      Tenant Systems when communications between Tenant's System is
      secured.  This is NOT RECOMMENDED.  Instead, it is RECOMMENDED
      that mechanisms binds the inner payload to the Geneve Header.  To
      prevent injection between virtualized network, it is strongly




Migault, et al.         Expires September 1, 2019              [Page 12]


Internet-Draft        Geneve Security Requirements         February 2019


      RECOMMENDED that at least the Geneve Header without Geneve Options
      is authenticated.

   o  SEC-OP-7: A secure deployment of a Geneve overlay SHOULD NOT
      process data prior authentication.  If that is not possible, the
      Geneve overlay provider SHOULD evaluate its impact.

5.2.2.  Geneve Security Requirements

   A Geneve security mechanism must fulfill the requirements below:

   o  SEC-GEN-8: Geneve security mechanism MUST provide the capability
      to authenticate the inner payload.

   o  SEC-GEN-9: Geneve security mechanism SHOULD provide the capability
      to partially authenticate the inner payload header.

   o  SEC-GEN-10: Geneve security mechanism MUST provide the capability
      to authenticate a single or a set of options while leave other
      Geneve Option unauthenticated.  Reversely, a Geneve security
      mechanism MUST be able to leave a Geneve option unauthenticated,
      while encrypting the others.

   o  SEC-GEN-11: Geneve security mechanism MUST provide means to
      authenticate the information of Geneve Header (Geneve Option
      excluded).  Reversely, a Geneve security mechanism MUST be able to
      leave unauthenticated Geneve header information (Geneve Options
      excluded) while authenticating the other.

   o  SEC-GEN-12: Geneve Security mechanism MUST provide means for a
      tunnel endpoint (NVE) to authenticate data prior it is being
      processed.

   o  SEC-GEN-13: Geneve Security mechanism MUST provide means for a
      transit device to authenticate data prior it is being processed.

5.3.  Protecting Against Traffic Redirection

   A rogue device of the NVO3 overlay Geneve network or the underlay
   network may redirect the traffic from a virtual network to the
   attacker for passive or active attacks.  If the rogue device is in
   charge of securing the Geneve packet, then Geneve security mechanisms
   are not intended to address this threat.  More specifically, a rogue
   source NVE will still be able to redirect the traffic in clear text
   before protecting ( and encrypting the packet).  A rogue destination
   NVE will still be able to redirect the traffic in clear text after
   decrypting the Geneve packets.  The same occurs with a rogue transit
   that is in charge of encrypting and decrypting a Geneve Option,



Migault, et al.         Expires September 1, 2019              [Page 13]


Internet-Draft        Geneve Security Requirements         February 2019


   Geneve Option or any information.  The security mechanisms are
   intended to protect a Geneve information from any on path node.  Note
   that modern cryptography recommend the use of authenticated
   encryption.  This section assumes such algorithms are used, and as
   such encrypted packets are also authenticated.

   To prevent an attacker located in the middle between the NVEs and
   modifying the tunnel address information in the data packet header to
   redirect the data traffic, the solution needs to provide
   confidentiality protection for data traffic exchanged between NVEs.

   Requirements are similar as those provided in section Section 5.1 to
   mitigate sniffing attacks and those provided in section Section 5.2
   to mitigate traffic injection attacks.

5.4.  Protecting Against Traffic Replay

   A rogue device of the NVO3 overlay Geneve network or the underlay
   network may replay a Geneve packet, to load the network and/or a
   specific Tenant System with a modified Geneve payload.  In some
   cases, such attacks may target an increase of the tenants costs.

   When traffic between Tenant System is not protected against anti-
   replay.  A packet even authenticated can be replayed.  DTLS and IPsec
   provides anti replay mechanisms, so it is unlikely that authenticated
   Tenant's traffic is subject to replay attacks.

   Similarly to integrity protection, the Geneve Overlay Provider should
   prevent the overlay to be used to replay packet to the Tenant's
   System.  In addition, similarly to integrity protection, the Geneve
   Overlay network may also be a target of a replay attack, and NVE as
   well as transit devices should benefit from the same protection.

   Given the proximity between authentication and anti-replay mechanisms
   and that most authentication mechanisms integrates anti-replay
   attacks, we RECOMMEND that authentication contains an anti-replay
   mechanisms.

5.4.1.  Geneve Security Requirements

   A secure deployment of a Geneve overlay must fulfill the requirement
   below:

   o  SEC-OP-8: A secure deployment of a Geneve overlay MUST evaluate
      the communications subject to replay attacks.  Communications that
      are subject to this attacks MUST be authenticated with an anti
      replay mechanism.  Note that when partial authentication is
      provided, the part not covered by the authentication remains a



Migault, et al.         Expires September 1, 2019              [Page 14]


Internet-Draft        Geneve Security Requirements         February 2019


      surface of attack.  It is strongly RECOMMENDED that the Geneve
      Header is authenticated with anti replay protection.

5.4.2.  Geneve Security Requirements

   A Geneve security mechanism must fulfill the requirements below:

   o  SEC-GEN-14: Geneve Security mechanism MUST provide authentication
      with anti-replay protection.

5.5.  Security Management

5.5.1.  Operational Security Requirements

   A secure deployment of a Geneve overlay must fulfill the requirement
   below:

   o  SEC-OP-9: A secure deployment of a Geneve overlay MUST define the
      security policies that associates the encryption, and
      authentication associated to each flow between NVEs.

   o  SEC-OP-10: A secure deployment of a Geneve overlay SHOULD define
      distinct material for each flow.  The cryptographic depends on the
      nature of the flow (multicast, unicast) as well as on the security
      mechanism enabled to protect the flow.

5.5.2.  Geneve Security Requirements

   A Geneve security mechanism must fulfill the requirements below:

   o  SEC-GEN-15: A Geneve security mechanism MUST be managed via
      security policies associated for each traffic flow to be
      protected.  Geneve overlay provider MUST be able to configure NVEs
      with different security policies for different flows.  A flow MUST
      be identified at minimum by the Geneve virtual network identifier
      and the inner IP and transport headers, and optionally additional
      fields which define a flow (e.g., inner IP DSCP, IPv6 flow id,
      Geneve options).

   o  SEC-GEN-16: A Geneve security mechanism MUST be able to assign
      different cryptographic keys to protect the unicast tunnels
      between NVEs respectively.

   o  SEC-GEN-17: A Geneve security mechanisms, when multicast is used,
      packets,MUST be able to assign distinct cryptographic group keys
      to protect the multicast packets exchanged among the NVEs within
      different multicast groups.  Upon receiving a data packet, an
      egress Geneve NVE MUST be able to verify whether the packet is



Migault, et al.         Expires September 1, 2019              [Page 15]


Internet-Draft        Geneve Security Requirements         February 2019


      sent from a proper ingress NVE which is authorized to forward that
      packet.

6.  IANA Considerations

   There are no IANA consideration for this document.

7.  Security Considerations

   The whole document is about security.

   Limiting the coverage of the authentication / encryption provides
   some means for an attack to craft special packets.

   The current document details security requirements that are related
   to the Geneve protocol.  Instead,
   [I-D.ietf-nvo3-security-requirements] provides generic architecture
   security requirement upon the deployment of an NVO3 overlay network.
   It is strongly recommended to read that document as architecture
   requirements also apply here.  In addition, architecture security
   requirements go beyond the scope of Geneve communications, and as
   such are more likely to address the security needs upon deploying an
   Geneve overlay network.

8.  Appendix

8.1.  DTLS

   This section compares how NVE communications using DTLS meet the
   security requirements for a secure Geneve overlay deployment.  In
   this example DTLS is used over the Geneve Outer Header and secures
   the Geneve Header including the Geneve Options and the inner payload.

   The use of DTLS MAY fill the security requirements for a secure
   Geneve deployment.  However DTLS cannot be considered as the Geneve
   security mechanism enabling all Geneve deployments.  To ease the
   reading of the Requirements met by DTLS or IPsec, the requirements
   list indicates with Y (Yes) when the requirement and N (No) when the
   requirement is not met.  In addition, an explanation is provided on
   the reasoning.  This section is not normative and its purpose is
   limited to illustrative purpose.

8.1.1.  Operational Security Requirements

   This section shows how DTLS may secure some Geneve deployments.  Some
   Geneve deployments may not be secured by DTLS, but that does not
   exclude DTLS from being used.




Migault, et al.         Expires September 1, 2019              [Page 16]


Internet-Draft        Geneve Security Requirements         February 2019


   o  SEC-OP-1 (Y): A deployment using DTLS between NVEs with an non
      NULL encryption cipher suite will provide confidentiality to the
      full Geneve Packet which contains the inner payload.  As such the
      use of DTLS meets SEC-OP-1.  Note that DTLS does not provide
      partial encryption and as such the Geneve Overlay Provider may not
      benefit from the encryption performed by the Tenant if performed,
      which may result in some portion of the payload being encrypted
      twice.

   o  SEC-OP-2 (Y): A deployment using DTLS between NVEs with an non
      NULL encryption cipher suite encrypt the Geneve Packet which
      includes the Geneve Header and associated metadata.  Only the UDP
      port is leaked which could be acceptable.  As such, the use of
      DTLS meets SEC-OP-2.

   o  SEC-OP-3 (Y/N): A deployment using DTLS between NVEs will not be
      able to send dummy packets or pad Geneve Packet unless this is
      managed by the Geneve packet itself.  DTLS does not provide the
      ability to send dummy traffic, nor to pad.  As a result DTLS
      itself does not meet this requirement.  This requirement may be
      met if handled by the Geneve protocol.  As such SEC-OP-3 may not
      be met for some the deployment.  However, it is not a mandatory
      requirement and as such it is likely that the use of DTLS SEC-OP-3
      is met.

   o  SEC-OP-4 (Y): Similarly to SEC-OP-1, A deployment using DTLS
      between NVEs provides integrity protection to the full Geneve
      Packet which includes the inner payload.  As such the use of DTLS
      meets SEC-OP-4.  Note that DTLS 1.2 provides integrity-only cipher
      suites while DTLS 1.3 does not yet.  As a result, the use of DTLS
      1.3 may provide integrity protection using authenticated
      encryption.

   o  SEC-OP-5 (Y): Similarly to SEC-OP-2, A deployment using DTLS
      between NVE authenticates the full Geneve Packet which includes
      the Geneve Header.  Only the UDP port is left unauthenticated.  As
      such, the use of DTLS meets SEC-OP-5.

   o  SEC-OP-6 (Y): A deployment using DTLS between NVE authenticates
      NVE-to-NVE communications and the use of DTLS meets SEC-OP-6.

   o  SEC-OP-7 (Y/N): A deployment using DTLS between NVEs is not
      compatible with a Geneve architecture that includes transit
      devices.  When the DTLS session uses a non NULL encryption cipher
      suite, the transit device will not be able to access it.  When the
      NULL encryption cipher suite is used, the transit device may be
      able to access the data, but will not be able to authenticate it
      prior to processing the packet.  As such the use of DTLS only



Migault, et al.         Expires September 1, 2019              [Page 17]


Internet-Draft        Geneve Security Requirements         February 2019


      meets SEC-OP-7 for deployment that do not include any transit
      devices.

   o  SEC-OP-8 (Y): A deployment using DTLS between NVEs provides anti-
      replay protection and so, the use of DTLS meets SEC-OP-8.

   o  SEC-OP-9 (Y/N): DTLS does not define any policies.  Instead DTLS
      process is bound to an UDP socket.  As such handling of flow
      policies is handled outside the scope of DTLS.  As such SEC-OP-9
      is met outside the scope of DTLS.

   o  SEC-OP-10 (N): DTLS session may be established with specific
      material, as such it is possible to assign different material for
      each flow.  However, the binding between flow and session is
      performed outside the scope of DTLS.  In addition, DTLS does not
      support multicast.  As such, the use of DTLS may only meets SEC-
      OP-10 in the case of unicast communications.

8.1.2.  Geneve Security Requirements

   This section shows that DTLS cannot be used as a generic Geneve
   security mechanism to secure Geneve deployments.  A Geneve security
   mechanism woudl need to meet all SEC-GEN requirements.

   o  SEC-GEN-1 (Y): A deployment using DTLS between NVEs with an non
      NULL encryption cipher suite will provide confidentiality to the
      full Geneve Packet which contains the inner payload.  As such the
      use of DTLS meets SEC-GEN-1.

   o  SEC-GEN-2 (Y): A deployment using DTLS between NVEs with an non
      NULL encryption cipher suite will not be able to partially encrypt
      the inner payload header.  However such requirement is not set a
      mandatory so the use of DTLS meets SEC-GEN-2

   o  SEC-GEN-3 (N): A deployment using DTLS between NVEs with an non
      NULL encryption cipher suite encrypt the Geneve Packet which
      includes the Geneve Header and all Geneve Options.  However DTLS
      does not provides any means to selectively encrypt or leave in
      clear text a subset of Geneve Options.  As a result the use of
      DTLS does not meet SEC-GEN-3.

   o  SEC-GEN-4 (N): A deployment using DTLS between NVEs with an non
      NULL encryption cipher suite encrypt the Geneve Packet which
      includes the Geneve Header and all Geneve Options.  However, DTLS
      does not provides means to selectively encrypt some information of
      the Geneve Header.  As such the use of DTLS does not meet SEC-GEN-
      5.




Migault, et al.         Expires September 1, 2019              [Page 18]


Internet-Draft        Geneve Security Requirements         February 2019


   o  SEC-GEN-5 (N): A deployment using DTLS between NVEs with an non
      NULL encryption cipher suite provides end-to-end security between
      the NVEs and as such does not permit the interaction of one or
      multiple on-path transit devices.  As such the use of DTLS does
      not meet SEC-GEN-5.

   o  SEC-GEN-6 (N): A deployment using DTLS between NVEs with an non
      NULL encryption cipher suite does not provide padding facilities.
      This requirements is not met by DTLS itself and needs to be
      handled by Geneve and specific options.  As a result, the use of
      DTLS does not meet SEC-GEN-6

   o  SEC-GEN-7 (N): A deployment using DTLS between NVEs with an non
      NULL encryption cipher suite does not provide the ability to send
      dummy packets.  This requirements is not met by DTLS itself and
      needs to be handled by Geneve and specific options.  As a result,
      the use of DTLS does not meet SEC-GEN-7.

   o  SEC-GEN-8 (Y): A deployment using DTLS between NVEs with an non
      NULL encryption cipher suite or a NULL encryption cipher suite
      provide authentication of the inner payload.  As such the use of
      DTLS meets SEC-GEN-8.

   o  SEC-GEN-9 (Y): A deployment using DTLS between NVEs does not
      provide the ability to partially authenticate the inner payload
      header.  However such requirement is not set a mandatory so the
      use of DTLS meets SEC-GEN-9

   o  SEC-GEN-10 (N): A deployment using DTLS between NVEs authenticates
      the Geneve Packet which includes the Geneve Header and all Geneve
      Options.  However, DTLS does not provides means to selectively
      encrypt some information of the Geneve Header.  As such the use of
      DTLS meets SEC-GEN-10.

   o  SEC-GEN-11 (N): A deployment using DTLS between NVEs authenticates
      the Geneve Packet which includes the Geneve Header and all Geneve
      Options.  However, DTLS does not provides means to selectively
      authenticate some information of the Geneve Header.  As such the
      use of DTLS does not meet SEC-GEN-11.

   o  SEC-GEN-12 (Y): A deployment using DTLS between NVEs authenticates
      the data prior the data is processed by the NVE.  As such, the use
      of DTLS meets SEC-GEN-12.

   o  SEC-GEN-13 (N): A deployment using DTLS between NVEs authenticates
      the data when the tunnel reaches the NVE.  As a result the transit
      device is not able to authenticate the data prior accessing it and
      the use of DTLS does not meet SEC-GEN-13.



Migault, et al.         Expires September 1, 2019              [Page 19]


Internet-Draft        Geneve Security Requirements         February 2019


   o  SEC-GEN-14 (Y): DTLS provides anti-replay mechanism as such, the
      use of DTLS meets SEC-GEN-14.

   o  SEC-GEN-15 (N): DTLS itself does not have a policy base mechanism.
      As a result, the classification of the flows needs to be handled
      by a module outside DTLS.  In order to meet SEC-GEN-15 further
      integration is needed and DTLS in itself cannot be considered as
      meeting SEC-GEN-15.

   o  SEC-GEN-16 (Y): DTLS is able to assign various material to each
      flows, as such the use of DTLS meets SEC-GEN-16.

   o  SEC-GEN-17 (N): DTLS does not handle mutlicast communications.  As
      such the use of DTLS does not meet SEC-GEN-17.

8.2.  IPsec

   This section compares how NVE communications using IPsec/ESP or
   IPsec/AH meet the security requirements for a secure Geneve overlay
   deployment.  In this example secures the Geneve IP packet including
   Outer IP header, the Geneve Outer Header, the Geneve Header including
   Geneve Options and the inner payload.

   The use of IPsec/ESP or IPsec/AH share most of the analysis performed
   for DTLS.  The main advantages of using IPsec would be that IPsec
   supports multicast communications and natively supports flow based
   security policies.  However, the use of these security policies in a
   context of Geneve is not natively supported.

   As a result, the use of IPsec MAY fill the security requirements for
   a secure Geneve deployment.  However IPsec cannot be considered as
   the Geneve security mechanism enabling all Geneve deployments.

8.2.1.  Operational Security Requirements

   This section shows how IPsec may secure some Geneve deployments.
   Some Geneve deployments may not be secured by IPsec, but that does
   not exclude IPsec from being used.

   o  SEC-OP-1 (Y): A deployment using IPsec/ESP between NVEs with an
      non NULL encryption will provide confidentiality to the full Outer
      IP payload of the Geneve Packet which contains the inner payload.
      As a result, such deployments meet SEC-OP-1.  Note that IPsec/ESP
      does not provide partial encryption and as such the Geneve Overlay
      Provider may not benefit from the encryption performed by the
      Tenant if performed, which may result in some portion of the
      payload being encrypted twice.




Migault, et al.         Expires September 1, 2019              [Page 20]


Internet-Draft        Geneve Security Requirements         February 2019


   o  SEC-OP-2 (Y): A deployment using IPsec/ESP between NVEs with an
      non NULL encryption encrypts the Outer IP payload Geneve IP Packet
      which includes the Geneve Header and associated information.  As
      such SEC-OP-2 is met.

   o  SEC-OP-3 (Y): A deployment using IPsec/ESP between NVEs will be
      able to send dummy packets or pad Geneve Packet.  As such OP-SEC-3
      is met.

   o  SEC-OP-4 (Y): Similarly to SEC-OP-1, A deployment using IPsec/ESP
      or IPsec/AH between NVEs provides integrity protection to the full
      Geneve Packet which includes the inner payload.  As such SEC-OP-4
      is met.

   o  SEC-OP-5 (Y): Similarly to SEC-OP-2, A deployment using IPsec/ESP
      or IPsec/AH between NVE authenticates the full Geneve Packet which
      includes the Geneve Header.  As such SEC-OP-5 is met as well.

   o  SEC-OP-6 (Y): A deployment using IPsec/ESP or IPsec/AH between NVE
      authenticates NVE-to-NVE communications and SEC-OP-6 is met.

   o  SEC-OP-7 (Y/N): A deployment using IPsec between NVEs is not
      compatible with a Geneve architecture that includes transit
      devices.  When IPsec/ESP with a non NULL encryption is used, the
      transit device will not be able to access it.  When IPsec/AH or
      IPsec/ESP with the NULL encryption is used, the transit device may
      be able to access the data, but will not be able to authenticate
      it prior to processing the packet.  As SEC-OP-7 is only met for
      deployment that do not include any transit devices.

   o  SEC-OP-8 (Y): A deployment using IPsec between NVEs provides anti-
      replay protection and so meets SEC-OP-8.

   o  SEC-OP-9 (Y/N): IPsec enables the definition of security policies.
      As such IPsec is likely to handle a per flow security.  However
      the traffic selector required for Geneve flows may not be provided
      natively by IPsec.  As such Sec-OP-9 is only partialy met.

   o  SEC-OP-10 (Y): IPsec session may be established with specific
      material, as such it is possible to assign different material for
      each flow.  In addition IPsec supports multicats communications.
      As such SEC-OP-10 is met.

8.2.2.  Geneve Security Requirements

   This section shows that IPsec cannot be used as a generic Geneve
   security mechanism to secure Geneve deployments.  A Geneve security
   mechanism would need to meet all SEC-GEN requirements.



Migault, et al.         Expires September 1, 2019              [Page 21]


Internet-Draft        Geneve Security Requirements         February 2019


   o  SEC-GEN-1 (Y): A deployment using IPsec/ESP between NVEs with an
      non NULL encryption provide confidentiality to the full Geneve
      Packet which contains the inner payload.  As such IPsec/ESP meets
      SEC-GEN-1.

   o  SEC-GEN-2 (Y): A deployment using IPsec/ESP between NVEs with an
      non NULL encryption will not be able to partially encrypt the
      inner payload header.  However such requirement is not set a
      mandatory so IPsec/ESP meets SEC-GEN-2

   o  SEC-GEN-3 (N): A deployment using IPsec between NVEs with an non
      NULL encryption encrypts the Outer IP payload of the Geneve Packet
      which includes the Geneve Header and all Geneve Options.  However
      IPsec/ESP does not provides any means to selectively encrypt or
      leave in clear text a subset of Geneve Options.  As a result SEC-
      GEN-3 is not met.

   o  SEC-GEN-4 (N): A deployment using IPsec/ESP between NVEs with an
      non NULL encryption encrypts the Geneve Packet which includes the
      Geneve Header and all Geneve Options.  However, IPsec/ESP does not
      provides means to selectively encrypt some information of the
      Geneve Header.  As such SEC-GEN-5 is not met.

   o  SEC-GEN-5 (N): A deployment using IPsec between NVEs with an non
      NULL encryption provides end-to-end security between the NVEs and
      as such does not permit the interaction of one or multiple on-path
      transit devices.  As such IPsec/ESP does not meet SEC-GEN-5.

   o  SEC-GEN-6 (Y): A deployment using IPsec/ESP between NVEs with an
      non NULL encryption provides padding facilities and as such IPsec/
      ESP meets SEC-GEN-6.

   o  SEC-GEN-7 (Y): A deployment using IPsec between NVEs with an non
      NULL encryption cipher provides the ability to send dummy packets.
      As such IPsec/ESP meets SEC-GEN-7.

   o  SEC-GEN-8 (Y): A deployment using IPsec/ESP or IPsec/AH
      authenticates the inner payload.  As such SEC-GEN-8 is met.

   o  SEC-GEN-9 (Y): A deployment using IPsec/AH or IPsec/ESP between
      NVEs does not provide the ability to partially authenticate the
      inner payload header.  However such requirement is not set a
      mandatory so IPsec meets SEC-GEN-9

   o  SEC-GEN-10 (N): A deployment using IPsec/ESP or IPsec/AH between
      NVEs authenticates the Geneve Packet which includes the Geneve
      Header and all Geneve Options.  However, IPsec does not provides




Migault, et al.         Expires September 1, 2019              [Page 22]


Internet-Draft        Geneve Security Requirements         February 2019


      means to selectively encrypt some information of the Geneve
      Header.  As such SEC-GEN-10 is not met.

   o  SEC-GEN-11 (N): A deployment using IPsec/ESP or IPsec/AH between
      NVEs authenticates the Geneve Packet which includes the Geneve
      Header and all Geneve Options.  However, IPsec does not provides
      means to selectively authenticate some information of the Geneve
      Header.  As such SEC-GEN-11 is not met.

   o  SEC-GEN-12 (Y): A deployment using IPsec/ESP or IPsec/AH between
      NVEs authenticates the data prior the data is processed by the
      NVE.  As such SEC-GEN-12 is met.

   o  SEC-GEN-13 (N): A deployment using IPsec/ESP or IPsec/AH between
      NVEs authenticates the data when the tunnel reaches the NVE.  As a
      result the transit device is not able to authenticate the data
      prior accessing it and SEC-GEN-13 is not met.

   o  SEC-GEN-14 (Y): IPsec/ESP and IPsec/AH provides anti-replay
      mechanism as such SEC-GEN-14 is met.

   o  SEC-GEN-15 (N): IPsec is a policy base architecture.  As a result,
      the classification of the flows needs to be handled by IPsec.
      However, the traffic selector available are probably not those
      required by Geneve and further integration is needed.  As such
      SEC-GEN-15 is not met.

   o  SEC-GEN-16 (Y): IPsec is able to assign various material to each
      flows, as such SEC-GEN-16 is met.

   o  SEC-GEN-17 (Y): IPsec handles mutlicast communications.  As such
      SEC-GEN-17 is met.

9.  Acknowledgments

   We would like to thank Ilango S Ganaga, Magnus Nystroem for their
   useful reviews and clarifications as well as Matthew Bocci, Sam
   Aldrin and Ignas Bagdona for moving the work forward.

10.  References

10.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.




Migault, et al.         Expires September 1, 2019              [Page 23]


Internet-Draft        Geneve Security Requirements         February 2019


   [RFC4301]  Kent, S. and K. Seo, "Security Architecture for the
              Internet Protocol", RFC 4301, DOI 10.17487/RFC4301,
              December 2005, <https://www.rfc-editor.org/info/rfc4301>.

   [RFC4302]  Kent, S., "IP Authentication Header", RFC 4302,
              DOI 10.17487/RFC4302, December 2005,
              <https://www.rfc-editor.org/info/rfc4302>.

   [RFC4303]  Kent, S., "IP Encapsulating Security Payload (ESP)",
              RFC 4303, DOI 10.17487/RFC4303, December 2005,
              <https://www.rfc-editor.org/info/rfc4303>.

   [RFC6347]  Rescorla, E. and N. Modadugu, "Datagram Transport Layer
              Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
              January 2012, <https://www.rfc-editor.org/info/rfc6347>.

   [RFC7258]  Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an
              Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May
              2014, <https://www.rfc-editor.org/info/rfc7258>.

   [RFC7365]  Lasserre, M., Balus, F., Morin, T., Bitar, N., and Y.
              Rekhter, "Framework for Data Center (DC) Network
              Virtualization", RFC 7365, DOI 10.17487/RFC7365, October
              2014, <https://www.rfc-editor.org/info/rfc7365>.

   [RFC7516]  Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)",
              RFC 7516, DOI 10.17487/RFC7516, May 2015,
              <https://www.rfc-editor.org/info/rfc7516>.

   [RFC7525]  Sheffer, Y., Holz, R., and P. Saint-Andre,
              "Recommendations for Secure Use of Transport Layer
              Security (TLS) and Datagram Transport Layer Security
              (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
              2015, <https://www.rfc-editor.org/info/rfc7525>.

   [RFC8014]  Black, D., Hudson, J., Kreeger, L., Lasserre, M., and T.
              Narten, "An Architecture for Data-Center Network
              Virtualization over Layer 3 (NVO3)", RFC 8014,
              DOI 10.17487/RFC8014, December 2016,
              <https://www.rfc-editor.org/info/rfc8014>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.







Migault, et al.         Expires September 1, 2019              [Page 24]


Internet-Draft        Geneve Security Requirements         February 2019


   [RFC8221]  Wouters, P., Migault, D., Mattsson, J., Nir, Y., and T.
              Kivinen, "Cryptographic Algorithm Implementation
              Requirements and Usage Guidance for Encapsulating Security
              Payload (ESP) and Authentication Header (AH)", RFC 8221,
              DOI 10.17487/RFC8221, October 2017,
              <https://www.rfc-editor.org/info/rfc8221>.

   [RFC8247]  Nir, Y., Kivinen, T., Wouters, P., and D. Migault,
              "Algorithm Implementation Requirements and Usage Guidance
              for the Internet Key Exchange Protocol Version 2 (IKEv2)",
              RFC 8247, DOI 10.17487/RFC8247, September 2017,
              <https://www.rfc-editor.org/info/rfc8247>.

   [RFC8446]  Rescorla, E., "The Transport Layer Security (TLS) Protocol
              Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
              <https://www.rfc-editor.org/info/rfc8446>.

10.2.  Informative References

   [I-D.ietf-nvo3-geneve]
              Gross, J., Ganga, I., and T. Sridhar, "Geneve: Generic
              Network Virtualization Encapsulation", draft-ietf-
              nvo3-geneve-09 (work in progress), February 2019.

   [I-D.ietf-nvo3-security-requirements]
              Hartman, S., Zhang, D., Wasserman, M., Qiang, Z., and M.
              Zhang, "Security Requirements of NVO3", draft-ietf-nvo3-
              security-requirements-07 (work in progress), June 2016.

   [I-D.ietf-tls-dtls13]
              Rescorla, E., Tschofenig, H., and N. Modadugu, "The
              Datagram Transport Layer Security (DTLS) Protocol Version
              1.3", draft-ietf-tls-dtls13-30 (work in progress),
              November 2018.

Authors' Addresses

   Daniel Migault
   Ericsson
   8275 Trans Canada Route
   Saint Laurent, QC  4S 0B6
   Canada

   EMail: daniel.migault@ericsson.com







Migault, et al.         Expires September 1, 2019              [Page 25]


Internet-Draft        Geneve Security Requirements         February 2019


   Sami Boutros
   VMware, Inc.

   EMail: boutros@vmware.com<


   Dan Wings
   VMware, Inc.

   EMail: dwing@vmware.com


   Suresh Krishnan
   Kaloom

   EMail: suresh@kaloom.com



































Migault, et al.         Expires September 1, 2019              [Page 26]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/