[Search] [pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
NVO3                                                          D. Migault
Internet-Draft                                             June 27, 2017
Intended status: Standards Track
Expires: December 29, 2017


                      Geneve Security Architecture
            draft-mglt-nvo3-geneve-security-architecture-00

Abstract

   This document describes the Geneve Security Architecture.

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 http://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 December 29, 2017.

Copyright Notice

   Copyright (c) 2017 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
   (http://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.







Migault                 Expires December 29, 2017               [Page 1]


Internet-Draft        Geneve Security Architecture             June 2017


Table of Contents

   1.  Requirements notation . . . . . . . . . . . . . . . . . . . .   2
   2.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   3.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   4.  Architecture Overview . . . . . . . . . . . . . . . . . . . .   4
   5.  Geneve Security Policies Database . . . . . . . . . . . . . .   5
     5.1.  Selectors . . . . . . . . . . . . . . . . . . . . . . . .   6
     5.2.  Geneve Security Policies  . . . . . . . . . . . . . . . .   8
     5.3.  Geneve Security Policies Example  . . . . . . . . . . . .   8
   6.  Geneve Security Association Database  . . . . . . . . . . . .  11
     6.1.  Geneve Security Associations  . . . . . . . . . . . . . .  11
   7.  Geneve Security Module Packet Processing  . . . . . . . . . .  13
     7.1.  Outbound Geneve Processing  . . . . . . . . . . . . . . .  13
     7.2.  Inbound Geneve Packet Processing  . . . . . . . . . . . .  13
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  14
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .  14
   10. Acknowledgment  . . . . . . . . . . . . . . . . . . . . . . .  14
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  15
     11.1.  Normative References . . . . . . . . . . . . . . . . . .  15
     11.2.  Informational References . . . . . . . . . . . . . . . .  15
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  16

1.  Requirements notation

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

2.  Introduction

   [I-D.ietf-nvo3-encap] and [I-D.mglt-nvo3-security-requirements]
   clearly state the need to secure the Geneve overlay network and
   provide means to authenticate the Geneve Header as well as being able
   to encrypt the Geneve Payload.

   Both of these requirements are fulfilled with specific Geneve
   Security Options.  More explicitly,
   [I-D.mglt-nvo3-geneve-authentication-option] defines an option that
   authenticate the Geneve fixed Header and optionally a set of Geneve
   Option as well as a portion of the Geneve Payload.
   [I-D.mglt-nvo3-geneve-encryption-option] defines a Geneve Option that
   enables to encrypt a subset of Geneve Options as well as a portion of
   the Geneve Payload.  Further descriptions on how an Geneve Security
   Option is treated is out of the scope of this document.

   This document defines how the Geneve overlay can be secured properly.
   A Geneve Element may handle different Geneve overlay networks



Migault                 Expires December 29, 2017               [Page 2]


Internet-Draft        Geneve Security Architecture             June 2017


   associated with different level of security.  This document defines
   how to associate a level of security to an Geneve overlay network.
   In addition, a security level for a given overlay network may result
   in a combination of multiple Geneve Security Options.  As the order
   these Geneve Security Options are processed matters, it is necessary
   the sending and receiving Geneve Element have similar behaviours in
   order to guarantee interoperability while securing a Geneve overlay
   Network.

   This document explains how Geneve Security Policies and Geneve
   Security Associations are organized to associate a given level of
   security to an Geneve overlay network.  In addition, this document
   also exposes how the Geneve Security Module implementing the security
   interacts with the Geneve architecture.

3.  Terminology

   o  Geneve Elements: designates all elements that handled Geneve
      Packets.  These elements may be terminal elements such as NVEs for
      example, but can also be on path elements that are expected to
      manage the flow inside the Geneve overlay network.

   o  Geneve Packet: designates the packet that Geneve Elements are
      expected to handled.  It is composed of a Geneve Header and a
      Geneve Payload.  In this document the Outer Ethernet Header and
      Outer IPv4 Header as well as the Outer UDP Header defined in
      [I-D.ietf-nvo3-geneve] section 3.1 are not part of the Geneve
      Packet.  Similarly, the Outer Ethernet Header, the Outer IPv6
      Header as well as the Outer UDP Header defined in
      [I-D.ietf-nvo3-geneve] section 3.2 are not part of the Geneve
      Packet.

   o  Geneve Header: is described in [I-D.ietf-nvo3-geneve] section 3.4.
      The Geneve Header may contain zero or more Geneve options.

   o  Geneve Payload: designates the data carried by a Geneve Packet.
      [I-D.ietf-nvo3-geneve].  In [I-D.ietf-nvo3-geneve] section 3.1 and
      section 3.2, the Geneve Payload would be the Inner Ethernet
      Header, the Payload and the Frame Check Sequence.

   o  Geneve Fix Header: The Geneve Header without any Geneve Options.

   o  Geneve Security Policies (GSP):

   o  Geneve Security Policies Data Base (GSP DB):

   o  Geneve Security Association (GSA):




Migault                 Expires December 29, 2017               [Page 3]


Internet-Draft        Geneve Security Architecture             June 2017


   o  Geneve Security Association Data Base (GSA DB):

   o  Geneve Security Options (GSO): A security option defined for
      Geneve.  Currently the security options that have been defined are
      GAO or GEO.

   o  Geneve Authentication Option (GAO): Geneve Option that describes
      how to authenticate the Geneve Header as well as part of the
      Geneve Payload.  This option is described in
      [I-D.mglt-nvo3-geneve-authentication-option].

   o  Geneve Encryption Option (GEO): Geneve Option that describe how to
      encrypt Geneve Options as well as a part of the Geneve Payload.
      GEO is defined in [I-D.mglt-nvo3-geneve-encryption-option].

   o  Geneve Security Module: an implementation responsible to enforce
      the security of Geneve Packets.

4.  Architecture Overview

   The Geneve Security Architecture is represented in figure Figure 1.
   Geneve security is enforced by the Geneve Security Module.  The
   Geneve Security Policies (GSP) define which which flows inside a
   virtuial network needs to be secured by associating a action SECURE,
   BYPASS or DISCARD to each Geneve Packet.  When a Geneve Packet is
   tagged as SECURE, the GSP provides specific structures known as
   Geneve Security Associations (GSA) that describe how the Geneve
   Packet MUST be secured.  Typically, the GSA defines the type of
   option (Geneve Authentication Option (GAO) or the Geneve Encryption
   Option (GEO) to be computed or validated, as well as the necessary
   material such as the appropriated counters, the necessary keys to
   compute and validate the GSO.  GSP and GSA are respectively stored in
   GSP Database (GSP DB) and GSA Database (GSA DB).

   For outbound traffic, the Geneve Security Module receives a non
   secured Geneve Packet and is responsible to secure that Geneve Packet
   with the appropriated GSOs - as defined by the GSP/GSAs.  Once the
   GSO have been added, Outer Encapsulation is performed as described in
   [I-D.ietf-nvo3-geneve] i.e. the Geneve Packet is being encapsulated
   with Outer Ethernet / Outer IPv4 or IPv6 / and Outer UDP.

   For inbound traffic, the Geneve Security Module defines whether a
   incoming Geneve Packet must be secured or not as defined by the GSP.
   If a Geneve Packet does not have to be secured, any GSO found is
   ignored.  Otherwise, the Geneve Security Module validates each GSO,
   and check the validated GSOs are conformed to the defined GSP.  The
   last step is necessary to make sure that in addition to valid
   security options, the expected GSO were encountered.



Migault                 Expires December 29, 2017               [Page 4]


Internet-Draft        Geneve Security Architecture             June 2017


   This document assumes that all nodes GSP DB and GSA DB are
   appropriately provisioned by the control plane.

         outbound packets                 inbound packets
               |                                ^
               v                                |
   +-----------------------------+ +-------------------------------+
   | Geneve                      | | Geneve                        |
   +-----------------------------+ +-------------------------------+
   | Geneve Security Module      | | Geneve Security Module        |
   |                  +---------+| |                  +-----------+|
   | Computation      |  GSA DB || | Check            |  GSA DB   ||
   |                  |...      || |   ^ BYPASS       |...        ||
   |+--------+ SECURE |+-------+|| |+--------+ SECURE |+---------+||
   || GSP DB |------->|| GSA   ||| || GSP DB |------->|| GSA     |||
   |+--------+        |+-------+|| |+--------+        |+---------+||
   |   v  (DISCARD)   +---------+| |   ^  (DISCARD)   +-----------+|
   | BYPASS                      | |                               |
   +-----------------------------+ +-------------------------------+
   | Outer Encapsulation         | | Outer Decapsulation           |
   +-----------------------------+ +-------------------------------+
               |                               ^
               v                               |
   -----------------------------------------------------------------
                             Network

                  Figure 1: Geneve Security Architecture

5.  Geneve Security Policies Database

   The GSP DB contains a list of GSP that associates a Geneve Packet
   with a specific action BYPASS, DISCARD, SECURE.

   The matching between a Geneve Packet and an action is performed
   through Selectors.  These Selectors associated to specific values
   defined whether a Geneve Packet match a given GSP.  As GSO may result
   in encrypting a Selector, a GSP lookup is always performed with a
   "clear text" Geneve Packet.  More specifically, the GSP lookup for a
   Geneve Packet associated with the SECURE action is performed before
   the GSO is being added or after the GSO has been validated.  For
   outbound Geneve Packet, a GSP DB look up is performed using the
   Selectors' value before the GSO is computed.  In that case, the GSP
   will even provide the required structure to generate the GSO.  On the
   other hand, for incoming traffic, the GSO is identified by an
   identifier carried by the Geneve Packet, a GSP look up is performed
   once the GSO has been valiated / decryped.  As a consequence, the
   same GSP DB is shared by the sending and the receiving Geneve
   Element.



Migault                 Expires December 29, 2017               [Page 5]


Internet-Draft        Geneve Security Architecture             June 2017


   When BYPASS is selected, then the Geneve Security Module forwards the
   matching Geneve to the next layer.  As represented in Figure 1, the
   next layer of an outbound Geneve Packet is the Outer Encapsulation
   while the next layer of an incoming Geneve Packet is the Geneve layer
   . When DISCARD is selected, the Geneve Security Module is expected to
   drop the matching Geneve Packet.  When a SECURE action is selected
   the associated GSAs MUST be provided.  For outbound Geneve Packet,
   the GSAs provided will be used in order to appropriately generate the
   GSO.  On the other hand, for incoming Geneve Packet, the GSAs are
   returned so the Geneve Security Module can validate the GSO present
   in the Geneve Packet are conform to the GSP.

   It is worth noting that for incoming Geneve Packet, those not tagged
   as BYPASS or DISCARD are by default considered as tagged as SECURE.
   This means that the GSP DB may be split into sub databases that
   contains GSP associated to a specific action.  GSP DB (DISCARD/
   BYPASS) may contain all GSP associated to the DISCARD and BYPASS
   rules while GSP DB (SECURE) contains all GSP associated to the action
   SECURE.  By doing so, a incoming Geneve Packet may be associated to
   the SECURE action without performing a lookup on GSP DB (SECURE).
   This does not prevents the Geneve Security Module from validating the
   GSO found in the incoming Geneve Packet, as these GSO are carrying a
   specific Identifier.  On the other hand, the GSP DB (SECURE) MUST be
   lookup in order to validate that all GSO defined by the security
   policies have been appropriately validated.

5.1.  Selectors

   The Selectors are the elements read from the packet in order to match
   a GSP.  When a Selector is expected to be found in the Geneve Packet,
   the Selectors values that match the condition are indicated with a
   range or a list of matching values.  For clarity, this document uses
   ANY to indicate the full range.  When the Selector may not exist or
   may not be accessible and must be ignored to evaluate the matching
   condition, it is qualified of being OPAQUE.

   Geneve Header Selectors:

   o  Geneve Version (2 bits): The version of the Geneve Version.  This
      field is always present and MUST be specified.  When all Geneve
      Version are associated to the same GSP, then all values must be
      specified with ANY = [0, ..., 4].

   o  OAM bit (1 bit): The indication of an OAM indication.  When OAM
      and non OAM traffic is associated to the same GPS, then all values
      must be indicated with ANY = [0, 1].





Migault                 Expires December 29, 2017               [Page 6]


Internet-Draft        Geneve Security Architecture             June 2017


   o  Critical bit ( 1 bit): indicates the presence of a critical
      option.  When the presence of a critical option or its absence are
      associated to the same GSP, then all values must be indicated with
      ANY = [0, 1]

   o  Rsv (6 bits): Currently [I-D.ietf-nvo3-geneve] specifies the field
      is set to zero by the sender and ignored by the receiver.
      According to these rules, the sender is expected to DISCARD any
      non zero values and the receiver is expect to indicate all these
      values in its GSP.

   o  Protocol Type (16 bits): indicates the type of the Geneve Payload.
      It is likely that only a few types will be specified for matching.

   o  VNI: indicates the virtual network identifier.  It is also likely
      that only a small set of VNI values will be provisioned per
      switches.

   o  Reserved (8 bits): (see Rsv)

   o  Geneve Options Class - Type List: This fields specifies the Geneve
      Options that MUST be present.  The absence of one of these option
      result in discarding the Geneve Header.  When the presence or
      absence of a specific Geneve Option has no impact for the GSP
      selection, the value is set to OPAQUE as they may not be any
      options.

   Additional Selectors are considered within the Geneve Payload.  The
   Selectors provided below are expected to enable different GSP
   according to the protection of the traffic.  Typically, the Geneve
   overlay network may protect differently traffic that is already
   protected by the tenants with IPsec, DTLS/TLS, or SSH.

   o  Next Header (IPv6) / Protocol (IPv4) (8 bits): For IPv6 this field
      indicates the presence of an IPv6 Option or the transport layer
      used after the IPv6 Header.  For IPv4 packets, the protocol
      indicates the layer after the IPv4 Header.  This field is
      typically used to indicate whether IPsec/AH (51), IPsec/ESP (50),
      TCP (6) or UDP (17) is used.  Next Header is a mandatory field and
      is expected in any IP header.  When the matching condition does
      not consider the Next Header or Protocol number than ANY = [0,
      ..., 65535] is expected.  When non IP packet are expected, OPAQUE
      is expected.

   o  Port Source is typically used to determine how the tenants traffic
      is being protected by TLS or DTLS.  Ports associated to TLS are
      expected to be 443 https, 636 ldaps, 989 ftps-data, 990 ftps, 992
      telnets, 993 imaps, 994 ircs, 995 pop3s, 5061 sips, 22 ssh/scp.



Migault                 Expires December 29, 2017               [Page 7]


Internet-Draft        Geneve Security Architecture             June 2017


      Note that not all transport are associated with a port number.
      When only transport layers with port numbers are expected to be
      used (such as TCP or UDP) and the matching condition does not
      consider the port numbers, ANY = [0, ..., 65535] is expected.
      When traffic may not have port numbers - such as ICMP traffic,
      OPAQUE is expected.

   o  Port Destination: (see Port Source)

5.2.  Geneve Security Policies

   Geneve Security Policies are unidirectional.  A GSP is composed of:

   o  Selectors that express a matching condition

   o  Action that defines if the Geneve Packet MUST be DISCARDed,
      BYPASSed or SECUREd.  When the associated action is SECURE, then
      the GSP associates an ordered list of GSA.  The GSA contains the
      description and the necessary material to perform the SECURE
      action.

   The GSP DB is an ordered list of GSP.

5.3.  Geneve Security Policies Example

   According to [I-D.ietf-nvo3-geneve], the associated Geneve Version is
   0, a sender MUST set Rsv and Reserved to zero.  When the sender only
   supports [I-D.ietf-nvo3-geneve], it may performed a sanity check for
   its outbound packets.  The rules can be places at the beginning of
   the GSP DB.





















Migault                 Expires December 29, 2017               [Page 8]


Internet-Draft        Geneve Security Architecture             June 2017


   Selector         |   Value                  | Action
   -------------------------------------------------------
   Geneve Version   | [1 ... 4] (non-zero)     |
   OAM              | [0,1] (ANY)              |
   Critical         | [0,1] (ANY)              |
   Rsv              | [0, ... ,63] (ANY)       | DISCARD
   Protocol         | [0, ..., 65535] (ANY)    |
   VNI              | [0, ..., 16777215] (ANY) |
   Reserved         | [0, ..., 255] (ANY)      |
   Geneve Options   | OPAQUE                   |
   Next Header      | [0, ..., 255] (ANY)      |
   Port Source      | OPAQUE                   |
   Port Destination | OPAQUE                   |
   -------------------------------------------------------
   Geneve Version   | [0 ... 4] (ANY)          |
   OAM              | [0,1] (ANY)              |
   Critical         | [0,1] (ANY)              |
   Rsv              | [1, ... ,63] (non-zero)  | DISCARD
   VNI              | [0, ..., 65535] (ANY)    |
   Reserved         | [0, ..., 15] (ANY)       |
   Geneve Options   | OPAQUE                   |
   Next Header      | [0, ..., 255] (ANY)      |
   Port Source      | OPAQUE                   |
   Port Destination | OPAQUE                   |
   -------------------------------------------------------
   Geneve Version   | [0 ... 4] (ANY)          |
   OAM              | [0,1] (ANY)              |
   Critical         | [0,1] (ANY)              |
   Rsv              | [1, ... ,63] (ANY)       | DISCARD
   VNI              | [0, ..., 65535] (ANY)    |
   Reserved         | [1, ..., 15] (non-zero)  |
   Geneve Options   | OPAQUE                   |
   Next Header      | [0, ..., 255] (ANY)      |
   Port Source      | OPAQUE                   |
   Port Destination | OPAQUE                   |
   -------------------------------------------------------

        Figure 2: Example 1: Geneve Security Policy for [I-D.ietf-
                     nvo3-geneve] compliance (sender)

   By default a Geneve Security Madule may DISCARD any Geneve packet
   that have no matching This is indicated by the following GSP at the
   end of the GSP DB.








Migault                 Expires December 29, 2017               [Page 9]


Internet-Draft        Geneve Security Architecture             June 2017


   Selector         |   Value                  | Action
   -------------------------------------------------------
   Geneve Version   | [0 ... 4] (ANY)          |
   OAM              | [0,1] (ANY)              |
   Critical         | [0,1] (ANY)              |
   Rsv              | [0, ... ,63] (ANY)       | DISCARD
   Protocol         | [0, ..., 65535] (ANY)    |
   VNI              | [0, ..., 16777215] (ANY) |
   Reserved         | [0, ..., 255] (ANY)      |
   Geneve Options   | OPAQUE                   |
   Next Header      | [0, ..., 255] (ANY)      |
   Port Source      | OPAQUE                   |
   Port Destination | OPAQUE                   |
   -------------------------------------------------------

        Figure 3: Example 2: Geneve Security Policy for [I-D.ietf-
                     nvo3-geneve] compliance (sender)

   The example below details a GSP that proceeds to a specific treatment
   to the traffic between tenant using ESP.  The specific treatment
   could typically only authenticate the Geneve Packet or partially
   encrypt the Geneve Payload, in order to only hide the Inner headers -
   including the ESP header - up to the ESP payload.

   In the example, the GSP apply the same GSAs whatever the Geneve
   Header informations are.  More specifically, all virtualized network
   share the same GSAs.

   Selector         |   Value                  | Action
   -------------------------------------------------------
   Geneve Version   | [0 ... 4] (ANY)          |
   OAM              | [0,1] (ANY)              |
   Critical         | [0,1] (ANY)              |
   Rsv              | [0, ... ,63] (ANY)       | SECURE
   Protocol         | [0, ..., 65535] (ANY)    | [GSA1, GSA2]
   VNI              | [0, ..., 16777215] (ANY) |
   Reserved         | [0, ..., 255] (ANY)      |
   Geneve Options   | OPAQUE                   |
   Next Header      | [50] (ESP)               |
   Port Source      | OPAQUE                   |
   Port Destination | OPAQUE                   |
   -------------------------------------------------------

    Figure 4: Example 3: Geneve Security Policy for ESP protect traffic







Migault                 Expires December 29, 2017              [Page 10]


Internet-Draft        Geneve Security Architecture             June 2017


6.  Geneve Security Association Database

   GSA DB contains all GSAs.  GSA are expected to contain all the
   necessary information for the Geneve Security Module to compute the
   GSO by both the sender and teh receiver.  This includes for example
   the cryptographic keys to encrypt ( resp. authenticate) as well as to
   decrypt (resp. validate) the Geneve Packet.  In addition, the GSA
   also contains parameters associated to the protection of the security
   option such as the anti-replay mechanisms as well as the management
   of that options such as its lifetime.

   For outbound traffic, the concerned GSA are provided by the GSP.  In
   this case, it is the purpose of the implementation of Geneve Security
   Module to provide that appropriated reference.  Most likely, the
   appropriated GSAs will be designated using a memory address.

   For inbound traffic, the concerned GSA is designated by the
   associated GSO with a GSO-ID.  In that case the appropriated GSA is
   retrieved using this index.

6.1.  Geneve Security Associations

   A GSA contains the following information:

   o  GSO ID: The identifier of that GSA.  This identifier is used by
      receiver to bind the appropriated GSO to the appropriated GSA.
      Note that when the packet is encrypted by the GSO, it may not be
      possible to associate the GSA using GSP.

   o  GSO Protocol: The security protocol associated with the Geneve
      Security Option.  Currently the two GSO are GAO and GEO.

   When the security option includes some encryption operation, the
   following parameters are provided.  Note that as recommended by
   [I-D.ietf-ipsecme-rfc7321bis], encryption is authenticated
   encryption.

   o  GSO Encryption Algorithm: In most cases, the encryption is
      combined with an authentication performed with the same key.

   o  GSO Encryption Key:

   When the security option includes a dedicated authentication
   operation ( that is not part of the encryption), the following
   parameters are provided:

   o  GSO Authentication Algorithm:




Migault                 Expires December 29, 2017              [Page 11]


Internet-Draft        Geneve Security Architecture             June 2017


   o  GSO Authentication Key:

   The following parameters indicate the coverage of the security

   o  GSO Payload Covered Length: the length of the Geneve Payload
      covered by the GSO.  The expression of the length can be a number
      of bytes, but it may also be defined with an abstract designation.
      For example, a sending node may be willing to authenticate the
      Geneve Payload up to the ESP layer.  In that case, the sending
      node will have to compute the corresponding Payload Covered
      Length.  This value is only used by the sending node.  The
      receiving node read that value from the GAO.

   o  GSO Covered Geneve Options: Indicates the Geneve Options covered
      by the GSO.  This indication is primarily necessary for the
      sending node and is derived from the Geneve Packet by the
      receiving node.  It might be checked by the receiving node to
      validate the GSA.  It might typically be expressed as a list of
      Geneve Options that needs to be covered by the authentication.

   In order to implement the anti replay mechanisms the following
   parameters are provided:

   o  GSO Sequence Number Size: indicates the size of the SN.  This
      document considers a 32 bit or a 64 bit length.

   o  GSO Last Received Packet: that designates the Sequence Number last
      sent or received packet.

   o  GSO Anti Replay Window: that indicates the minimum acceptable
      value of the Sequence Number.  Any Geneve Packet with a lower SN
      MUST be rejected.  Such SN value is usually derived from the Last
      Received Packet - Anti Replay Windows.

   In order to check the conformity with the GSP:

   o  GSO Selectors: The selectors are provided so the receiver can
      check the Geneve Packet protected by the GSO is conform to the
      GSP.  In other words a valid GSO is not sufficient for the Geneve
      Packet to be forwarded to the upper layers.  Note that the
      Selectors MUST match the Geneve Packet associated to the GSA
      before the GSO is built for outbound Packets.  For inbound Geneve
      Packet the Selectors are those that corresponds to the Geneve
      Packet after the GSO has been validated/decrytped.  Selectors are
      mostly expected to be used by the GSA for incoming Geneve Packet,
      in order to check the GSA is conform with its GSP.

   o  GSA Life time:



Migault                 Expires December 29, 2017              [Page 12]


Internet-Draft        Geneve Security Architecture             June 2017


7.  Geneve Security Module Packet Processing

   This section assumes that the GSA is valid.  Unvalid GSA MUST be
   deleted or considered as non existing by either the sender or the
   receiver.

7.1.  Outbound Geneve Processing

   o  The Geneve Security Module consults the GSP DB to determine the
      GSP associated to the Geneve Packet.

      *  When a Geneve Packet is DISCARD, the Geneve Packet is dropped.

      *  When a Geneve Packet is BYPASS, the Geneve Packet is directly
         forwarded to the lower layers for the outer encapsulation.

      *  When a Geneve Packet is SECURE, the GSP returns one or multiple
         Geneve Security Association (GAS) of the Geneve Security
         Association Database (GSA DB).  GAS contains the necessary
         material to compute the GSO for outbound Geneve Packet.  When
         multiple GAS are returned, GAS are applied in the order they
         are provided.  Each computed GSO carries a unique GSA-ID, so
         the receiver can check the corresponding GSO without performing
         a GSP DB lookup.

      *  When no matching is found, the Geneve Packet is DISCARDed

   o  Geneve Packet is forwarded to the lower layers for the Outer
      Encapsulation.

7.2.  Inbound Geneve Packet Processing

   For inbound Geneve Packets:

   o  The Geneve Security Module checks the Geneve Packet is associated
      to a DISCARD or a BYPASS GSP.

      *  If a match occurs the Geneve Packet is either DISCARDed or
         BYPASSed to the Geneve layer.

      *  Otherwise the Geneve Packet is expected to be SECURED and
         processed as such by the Geneve Security Module.

   When the Geneve Packet is believed to be SECURed.

   o  The Geneve Security Module opens a security context which lists
      the encountered and validated GSO as well as their respective
      order.



Migault                 Expires December 29, 2017              [Page 13]


Internet-Draft        Geneve Security Architecture             June 2017


   o  The Geneve Security Module inspects the Geneve Header for GSO in a
      network order and proceeds as follows:

      *  The Geneve Security Module extracts the GSA-ID of the GSO.

      *  The Geneve Security Module performs a GSA DB lookup based on
         the GSA-ID to retrieve the GSA associated to the Geneve Packet.

         +  If the GSA DB the GSO, the SO is skipped and the Geneve
            Security Module continue wity the next GSO.  In this case,
            the GSO is treated as a unexpected geneve option.

      *  The Geneve Security Module validates the Geneve Security Option
         against the GSA.  If the validation does not succeeds, the
         Geneve Packet is discarded.

      *  The Geneve security Module validates the Geneve Packet - once
         the GSO process has been performed - is conformed with the GSP
         by checking the resulting Geneve Packet matches the Selectors
         provided in the GSA.

         +  If the validation is successful, the Geneve Security Module
            associates the GSA-ID with a validated status in the
            security context.  For this reason it is important to match
            the GSA Selector with the appropriated Selectors value.  In
            case multiple GSO are combined, the Selectors of the GSA MAY
            differ from those used for the GSP DB matching.

         +  If a mismatch occurs the Geneve Packet is dropped.

   When all Geneve Security Options have been validated, the Geneve
   Packet is matched against the GSP DB to validate the GSA-ID listed in
   the security context match those returned by the GSP DB.  Note that
   the receiver and the sender MUST have the same GSA-IDs, however,
   computation and validation are processed in a different order.

8.  IANA Considerations

   There are no IANA consideration for this document.

9.  Security Considerations

10.  Acknowledgment








Migault                 Expires December 29, 2017              [Page 14]


Internet-Draft        Geneve Security Architecture             June 2017


11.  References

11.1.  Normative References

   [I-D.ietf-ipsecme-rfc7321bis]
              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)", draft-ietf-
              ipsecme-rfc7321bis-06 (work in progress), June 2017.

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

11.2.  Informational References

   [I-D.ietf-nvo3-encap]
              Boutros, S., Ganga, I., Garg, P., Manur, R., Mizrahi, T.,
              Mozes, D., and E. Nordmark, "NVO3 Encapsulation
              Considerations", draft-ietf-nvo3-encap-00 (work in
              progress), June 2017.

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

   [I-D.mglt-nvo3-geneve-authentication-option]
              Migault, D., "Geneve Authentication Option", July 2017,
              <https://tools.ietf.org/html/I-D.ietf-nvo3-geneve-
              authentication-option-00>.

   [I-D.mglt-nvo3-geneve-encryption-option]
              Migault, D., "Geneve Encryption Option", July 2017,
              <https://tools.ietf.org/html/I-D.ietf-nvo3-geneve-
              encryption-option-00>.

   [I-D.mglt-nvo3-security-requirements]
              Migault, D., "Geneve Security Requirements", July 2017,
              <https://tools.ietf.org/html/I-D.mglt-nvo3-security-
              requirements-00>.








Migault                 Expires December 29, 2017              [Page 15]


Internet-Draft        Geneve Security Architecture             June 2017


Author's Address

   Daniel Migault

   Email: daniel.migault@ericsson.com














































Migault                 Expires December 29, 2017              [Page 16]