Internet DRAFT - draft-mglt-nvo3-geneve-authentication-option

draft-mglt-nvo3-geneve-authentication-option







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


               Geneve Header Authentication Option (GAO)
            draft-mglt-nvo3-geneve-authentication-option-00

Abstract

   This document describes the Geneve Header Authentication Option
   (GAO).  This option enables a Geneve element to authenticate the
   Geneve Header with selected associated Geneve Options as well as a
   portion of the Geneve Payload.

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 Header Authentication Option (GAO)      June 2017


Table of Contents

   1.  Requirements notation . . . . . . . . . . . . . . . . . . . .   2
   2.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   3.  Position versus DTLS/IPsec  . . . . . . . . . . . . . . . . .   3
   4.  Scope of the GAO  . . . . . . . . . . . . . . . . . . . . . .   5
   5.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   6
   6.  GAO Description . . . . . . . . . . . . . . . . . . . . . . .   6
   7.  GAO Processing  . . . . . . . . . . . . . . . . . . . . . . .   7
     7.1.  GAO Placement . . . . . . . . . . . . . . . . . . . . . .   7
     7.2.  GSA Parameters  . . . . . . . . . . . . . . . . . . . . .   8
     7.3.  GAO Outbound Processing . . . . . . . . . . . . . . . . .  10
       7.3.1.  Generating the Sequence Number  . . . . . . . . . . .  10
       7.3.2.  Generating a Covered Length . . . . . . . . . . . . .  11
       7.3.3.  GAO Inbound Processing  . . . . . . . . . . . . . . .  12
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  15
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .  15
   10. Acknowledgment  . . . . . . . . . . . . . . . . . . . . . . .  15
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  15
     11.1.  Normative References . . . . . . . . . . . . . . . . . .  15
     11.2.  Informative References . . . . . . . . . . . . . . . . .  16
   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

   Geneve [I-D.ietf-nvo3-geneve] defines an overlay network that enables
   communications between tenants within a given virtual network.  The
   Geneve overlay network enables these tenants to be distributed over a
   data center or multiple data centers.  As multiple virtual networks
   share a common infrastructure, Geneve needs to isolate both
   communications between virtual networks as well as each virtual
   network address space [RFC7364].

   The Geneve Header indicates the virtual network a communication
   belongs to with a Virtual Network Identifier (VNI).  Geneve packets
   may be steered to the appropriated destination tenant through the
   destination switch based on that NVI value.  In addition to the NVI,
   the Geneve Header may carry additional metadata that impacts how the
   traffic could be steered to the destination tenant.

   As stated by [I-D.ietf-nvo3-encap] and
   [I-D.mglt-nvo3-security-requirements], it is crucial that the



Migault                 Expires December 29, 2017               [Page 2]

Internet-Draft  Geneve Header Authentication Option (GAO)      June 2017


   information of the Geneve Header remains protected and authenticated
   in order to prevent that traffic be delivered to the wrong tenant.
   Typically, without integrity check mechanisms, a one bit switch in
   the NVI results in such a wrong delivery.  Such vulnerability is
   further increased by the use of UDP encapsulation that makes any
   application able to spoof packets.

   This document addresses these issues by proposing a GAO which enables
   to authenticate the Geneve Header with a set of selected Geneve
   Options as well as a portion of inner packet (Geneve Payload) carried
   by the Geneve overlay network (Geneve Payload).  In addition, GAO
   also prevent a Geneve Packet to be replayed by introducing an anti-
   replay mechanism.  GAO does not provides encryption which is instead
   provided by [I-D.mglt-nvo3-geneve-encryption-option].

3.  Position versus DTLS/IPsec

   This section exposes the motivations for designing GAO rather than
   re-using existing security mechanisms such as DTLS or IPsec.

   GAO provides integrity protection of a Geneve Packet, i.e. the Geneve
   Header, including a set of Geneve Options as well as a portion of the
   Geneve Payload.

   As Geneve is encapsulated in UDP packet, DTLS is a natural candidate.
   Similarly IPsec/AH [RFC4302] defines an protocol to authenticate an
   IP packet.  However relying on DTLS (or IPsec)/AH instead of a
   specific extension designed for Geneve comes with the following
   drawbacks:

   o  Modern versions of DTLS [I-D.ietf-tls-dtls13] currently do not
      consider authentication-only.  Instead the traffic is always
      encrypted.  Encrypting the Geneve Header prevents on path Geneve
      elements to manage secured intra NVI communications.  Typically
      when multiple intra NVI communications are multiplexed into a DTLS
      tunnel, a Geneve on path element will not be able to re-route some
      traffic nor to appropriately prioritize flows or load balance them
      according to their NVI.  On the other hand, DTLS1.2 [RFC6347]
      enabled authentication-only protection, and further cipher suite
      could be defined for DTLS1.3 in case there were a significant
      advantage in using DTLS to secure the Geneve communications.  In
      case such cipher will not be available, currently defined end to
      end encryption would prevent providing information useful to
      manage the various intra-NVI communications.  This information
      might be carried by lower layer such as UDP using port number for
      example.  However, such alternatives clearly makes secure intra
      NVI communication unnecessarily too hard to manage, and so does




Migault                 Expires December 29, 2017               [Page 3]

Internet-Draft  Geneve Header Authentication Option (GAO)      June 2017


      not encourage a secure deployment of these communications.
      Typically:

      *  Management of secure Geneve communications are reduces to
         management of UDP tunnel which ignores all motivations for
         designing Geneve.  That is the ability to tag flows, as well as
         to carry states or metadata.

      *  Management complexity is increased with an additional binding
         between Geneve Header and port number for example.  Not only a
         new binding is introduced, but as Geneve Headers and UDP source
         ports / destination ports have different spaces ranges, this
         makes such correspondence not straight forward to manage.
         Typically NVI are 24 bit long while source port are 16 bit
         long, this means that additional destination port may be used
         in order to benefit from the full NVI space.

      *  Increases the number of tunnels and the number of keying
         material as different Geneve Header needs to be transported in
         different UDP tunnel.  The number of UDP tunnels may reach the
         number of different Geneve communications.

   o  DTLS comes with a key exchange agreement, included as part of the
      DTLS protocol.  In most cases, DTLS or TLS is used without any
      configurations by a (D)TLS client while the (D)TLS server has all
      the necessary authentication information, so the (D)TLS client can
      appropriately authenticate the (D)TLS server.  In this case, for
      end-to-end authentication, authentication is performed by both
      Geneve NVEs which requires all of them to be appropriately
      provisioned with the necessary authentication credentials.
      Management of these authentication credential is not trivial and
      is expected to handled in addition of the security policies.  In
      addition, the presence of such handshake protocol may introduce
      some latencies in a forwarding plan usually managed by a
      orchestrator.  As a result, if DTLS would be used, a variant of
      DTLS without key exchange may rather be considered.

   o  Geneve does not provide any standard way to inform whether a
      packet is authenticated or not.  The current assigned port number
      for Geneve is 6081.  In order to make possible for the receiving
      node to distinguish an unprotected Geneve Packet from a protected
      traffic, a new port should be defined.

   o  The current use of TLS is usually based on a TLS client wishing to
      access a resource using TLS.  In that case, the TLS client uses a
      specific port number.  A server may also redirect the requests
      from a client that is non protected to a specific port which
      defines the protected version of that service.  Such redirection



Migault                 Expires December 29, 2017               [Page 4]

Internet-Draft  Geneve Header Authentication Option (GAO)      June 2017


      is usually performed when the service defines that resource has to
      be accessed using a secure channel.  In addition, the redirection
      is performed by the application protocol.  As a result, the
      security policies as usually quite simple that is, 1) security
      initiated by the client or 2) server enforces that all requested
      are secured.  The case of Geneve overlay network considers instead
      the coexistence of protected and non protected traffic which would
      require some mechanisms to define and enforce security policies
      not yet part of DTLS.

   o  DTLS usually protects the whole UDP payload.  In our case, the
      protection of the Geneve Header only, for example, would require
      some further developments to the existing DTLS.

   o  IPsec/AH prevents the creation of the Geneve overlay network.
      IPsec/AH has been defined for end-to-end IP communications.  In
      the case of a Geneve Packet, the two ends are defined by the IP
      addresses of the Geneve Packet Outer IP Headers.  These IP
      addresses are not necessarily the Geneve NVE, and could instead be
      those of an Geneve element that belong to the Geneve overlay
      network and in charge of steering the traffic to another Geneve
      overlay element.  With IPsec/AH, the IP addresses could not be
      modified, and the Geneve Packet will not be able to be steered
      across the Geneve overlay network.  In this case IPsec/AH could be
      used for a hop-by-hop security.  This would require each node of
      the Geneve Overlay network to be provisioned appropriately with
      the IPsec material which would come with significant management
      issues.  In addition, this would not achieve a end-to-end security
      between the two ends of the Geneve tunnel.

   o  IPsec/ESP may also be used without encryption.  However, in this
      case, the port number would be protected, which would prevent
      Geneve element to redirect the traffic to a different Geneve
      element using a different port.  Such constraint may prevent the
      overlay network to be operated as an overlay network, that is any
      on path Geneve element is able to redirect the traffic to another
      Geneve element that belongs to the overlay network.

4.  Scope of the GAO

   The Geneve Header Authentication Option (GAO) expects to have the
   following properties:

   o  Provides means to authenticate the Geneve Header, a selected
      associated set of options as well as part of the Geneve Payload.

   o  Provides an anti-replay mechanism.  This option does not encrypt
      any data and as such does not provide any privacy.  When privacy



Migault                 Expires December 29, 2017               [Page 5]

Internet-Draft  Geneve Header Authentication Option (GAO)      June 2017


      is expected, it can be enforced by the Geneve overlay network
      using GEO ([I-D.mglt-nvo3-geneve-encryption-option]) as well as by
      the Tenant's System which may encrypt their communications using
      IPsec/ESP or TLS.  The main purpose of the GAO is to provide means
      for the infrastructure to ensure that Geneve communications cannot
      be injected for example by modifying the NVI.

   o  Provides authentication - at least in an orchestrated environment
      - to the two NVEs, but also to any appropriately configured on-
      path Geneve forwarding element.

   o  Provides read access to the Geneve Header for any Geneve on path
      elements.  This option is expected to enable Geneve communications
      to be secured, while benefiting from all the facilities provided
      by Geneve.

   o  Provide the ability for on path Geneve forwarding elements to add
      Geneve Options on Geneve authenticated Packets without
      invalidating the GAO.

   o  Provides means with some restrictions for an on-path element to
      add Geneve Option and authenticate that Geneve Option using a GAO.

5.  Terminology

   The terminology used in this document has been introduced in
   [I-D.mglt-nvo3-geneve-security-architecture].

6.  GAO Description

   For generic format of the Geneve Options is defined in Figure 1.  The
   following values are expected:

   o  Option Class: 0x0000

   o  Type: C is unset as the GAO can simply be ignored by a NVE or a
      transit node.  The GSP will prevent to accept a GOA that is
      mandated by the GSP and that has not been validated.

   o  R is set to 0.

   o  Length: This document only considers the algorithms recommended by
      [I-D.ietf-ipsecme-rfc7321bis] AUTH_HMAC_SHA2_256_128 and
      AUTH_HMAC_SHA2_512_256.  These algorithms are defined in [RFC4868]
      with a respective 16 and 32 byte ICV.  As a result, the option
      length is expected to 4 + 28 = 32 bytes (resp. 4 + 44 = 48 bytes)
      which leads to 8 or 12 as the possible values for Length.




Migault                 Expires December 29, 2017               [Page 6]

Internet-Draft  Geneve Header Authentication Option (GAO)      June 2017


   0                   1                   2
   3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Option Class         |      Type     |R|R|R| Length  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Variable Option Data                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                      Figure 1: Geneve Option Format

    0                   1                   2
   3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Sequence Number                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           GAO-ID            |        Covered Length           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                 ICV  128/256 bits 16 / 32 octets              |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                   Figure 2: Geneve Authentication Data

   o  Sequence Number (32 bits): indicates the Sequence number of the
      Geneve Header.  When the SN is 32 bit long, the whole SN is
      indicated.  When the SN is 64 bit long, only the 32 least
      significant bits are indicated.

   o  GAO-ID (16 bits): indicates the identifier of the GAO.  This
      identifier is useful to retrieve the GSA, with the necessary
      information to compute the GAO or to validate it.

   o  Covered Length (16 bits): indicates in number of bytes following
      the GAO that are covered by the authentication.

   o  ICV contains the HMAC value.

7.  GAO Processing

7.1.  GAO Placement

   A GAO option covers the Geneve Header, the Geneve Options following
   the GAO as well as the Covered Length appended to the GAO.  As a
   result, any on path (Geneve) element MUST leave the Geneve Fixed
   Header and the first Covered Length bytes after GAO unchanged.





Migault                 Expires December 29, 2017               [Page 7]

Internet-Draft  Geneve Header Authentication Option (GAO)      June 2017


   GAO does not covers the Geneve Options placed between the Geneve
   Fixed Header and the GAO.  In addition, GAO does not cover the bytes
   located after the Covered Length.

   Geneve Options that are expected to be updated by any Geneve
   forwarding elements MUST be located between the Geneve Fixed Header
   and the existing GAO.

   When a Geneve Packet is received by a Geneve forwarding elements and
   that element is expected to insert an additional Geneve Option, the
   Geneve forwarding element MUST NOT insert the Geneve Option in a area
   covered by a GAO.  A safe way to proceed is that Geneve forwarding
   element that do not understand GAO MUST insert new Geneve Option
   right after the Geneve Fixed Header.  This will result in having the
   Gneve Option before the existing GAO.  When the Geneve forwarding
   element understadn GAO it can consider the covered area by each GAO
   and place its new option in a non covered area.


Geneve Authentication Option  -----+
                                   |
                                   |           Covered Length
 <------------------->             v       <-------------------->
+---------------------+-------------+-----+------------+----------------+
| Geneve Fixed Header | Geneve Opt. | GAO | Geneve Opt.| Geneve Payload |
+---------------------+-------------+-----+------------+----------------+
 <--------+----------> <---------+-------> <----------+---------> <-+-->
          |                      |                    |             |
          +-------------------------------------------+             |
       Fields covered            |                                  |
       by the authentication     +----------------------------------+
                                    Fields not covered
                                    by the authentication

             Figure 3: Geneve Authentication Options Placement

7.2.  GSA Parameters

   This section describes the parameters of the GAS necessary to compute
   or validate the GAO.  These parameters are then latter used to
   described the processing.

   o  GSO ID: The identifier of that GAO.  This identifier is used to
      bind the GAO with the appropriated GSA.  It is expected that GSA
      are uniquely identified on the receiver side.  In case collision
      are supported, the implementation MUST be able to
      deterministically associate the GAO to the appropriated GSA for
      example by using IP addresses and UDP ports.



Migault                 Expires December 29, 2017               [Page 8]

Internet-Draft  Geneve Header Authentication Option (GAO)      June 2017


   o  GSO Protocol: The security protocol associated with the Geneve
      Security Option.  In our case the protocol is GAO.

   o  GSO Authentication Algorithm: This document follows
      recommendations provided by [I-D.ietf-ipsecme-rfc7321bis] which
      recommends AUTH_HMAC_SHA2_256_128 and AUTH_HMAC_SHA2_512_256
      defined in [RFC4868].

   o  GSO Payload Covered Length: the length of the Geneve Payload
      covered by GAO.  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 GAO.  This indication is primarily necessary for the
      sending node and is derived from the Geneve Packet by the
      receiving node.  It MUST 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.

   o  GSO Authentication Key: the shared secret necessary compute and
      validate the HMAC value generated by the Authentication Algorithm
      specified above.

   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 Sequence Number: that designates the Sequence Number last sent
      or received packet.

   o  GSO Anti Replay Window: that indicates the windows that defines
      out-of order packet or late packets versus a replayed Geneve
      Packet.  Any Geneve Packet with a lower SN than GSO Sequence
      Number - Anti Replay Windows MUST be rejected.

   In order to check the conformity with the GSP:

   o  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



Migault                 Expires December 29, 2017               [Page 9]

Internet-Draft  Geneve Header Authentication Option (GAO)      June 2017


      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 correspond 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:

7.3.  GAO Outbound Processing

   Upon receiving a Geneve Packet, the Geneve Security Module performs a
   GSP DB look up to determine if any security action is required.  If
   the security action is DISCARD, the Geneve Packet is discarded.  If
   the security action is BYPASS, the Geneve Packet is sent to the lower
   layers for the outer encapsulation without any additional security
   consideration.  If the action is SECURE, the GSP returns the list of
   GSAs that need to be applied.  The list is an ordered list, and the
   Geneve Security Module performs these GSAs in the received order.
   (See [I-D.mglt-nvo3-geneve-security-architecture] for more
   information.)

   When a list of GSAs is provided, it is crucial that the
   implementation updates the Selectors of the further GSAs according to
   the actions undertaken by the previous GSAs.  In most cases, a GSA
   results in the addition of GSO.  The Selectors of the next GSA MUST
   consider this new GSO, in the Selectors.

   The outbound processing consists in the following actions:

   1.  Generating the Sequence Number

   2.  Generating a Covered Length

   3.  Generating the ICV

   4.  Building the GAO

   5.  Building the output Geneve Packet

7.3.1.  Generating the Sequence Number

   The Sequence Number is used to prevent anti replay.  The Sequence
   Number is any number strictly greater than the current value of the
   GSO Sequence Number mentioned in the GSA.

   The size of the GSO Sequence Number is designated by the GSO Sequence
   Number Size.  The GSO Sequence Number can be a 32 bit or 64 bit



Migault                 Expires December 29, 2017              [Page 10]

Internet-Draft  Geneve Header Authentication Option (GAO)      June 2017


   number.  When the limit or the GSO Sequence number has been reached,
   the GSA MUST be renewed.  In other words, no re-initialization nor
   rolling mechanisms are expected for the GSO Sequence Number.  The
   Geneve Elements need to take the necessary actions in order to
   generate GSAs before the limit of the GSO Sequence Number is reached.

   The new value of the GSO Sequence Number replaces the former GSO
   Sequence Number in the GSA.

7.3.2.  Generating a Covered Length

   The Covered Length describes the number of bytes of the Geneve Packet
   that are located after the GAO and authenticated by GAO.

   The Covered Length includes Geneve Options that are covered by the
   authentication designated by the GSO Covered Geneve Options as well
   as a portion of the Geneve Payload designated by the GSO Payload
   Covered Length.

   The covered Geneve Options MUST be immutable, and any on-path Geneve
   element MUST NOT change any of the Geneve Options covered by GAO.
   The covered Options MAY be agreed between the two Geneve element,
   however, by default, it is expected that the sending node will
   include any immutable Geneve Option.  The agreement of the covered
   Geneve Options is not necessary to validate the GAO.  In fact the
   position of the GAO in the Geneve Packet indicates deterministically
   the covered Geneve Options.  However, Geneve Options that are
   immutable while not being covered by the GAO will be considered
   suspicious and as such SHOULD be rejected by the Geneve Security
   Module of the receiving node.  This Geneve Option could have been
   inserted as well as modified.  Of course some Geneve Security Module
   MAY also specify a list of immutable Geneve Option that are not
   expected to be covered.  In that case such options MUST NOT be
   removed by the Geneve Security Module.

   Overall, the covered Geneve Options is determined by the sending
   node.  In addition that Geneve Options may have varying size, the
   contribution of the Covered Length is likely to vary for each Geneve
   Packet.

   Similarly, the contribution of the Covered Length by the Geneve
   Payload is also likely to vary for each Geneve Packet.  More
   specifically, it is more likely that a GSA defines the layers of the
   Geneve Payload that needs to be authenticated instead of a number of
   bytes.  For example, a GSA may indicate that the Geneve Payload may
   be covered up to the ESP or (D)TLS layer.  In addition, the GSA may
   also indicate an upper bound value for the Covered Length which could
   be imposed by hardware or computing restrictions.  As a result, the



Migault                 Expires December 29, 2017              [Page 11]

Internet-Draft  Geneve Header Authentication Option (GAO)      June 2017


   contribution of the Geneve Payload is determined by the sending node
   and evaluated for each Geneve Packet.

7.3.2.1.  Generating the ICV

   The ICV results from applying the GSO Authentication Algorithm with
   the GSO Authentication Key to the appropriated data.

   The appropriated data is build by concatenating the initial string
   "geneve authentication option" with the Geneve Fixed Header, the GSO
   Sequence Number, the GSO-ID, the GSO Covered Length, the covered
   Geneve options as well as the covered part of the Geneve Payload.

   All fields of the Geneve Fixed Header are considered, including the
   Rsv and Reserved fields.  It is important to understand that these
   fields are expected to remain immutable fields.

7.3.2.2.  Building the GAO

   The GAO is built by concatenating the 32 least significant bits of
   the GSO Sequence Number, the GAO-ID, the Covered Length and the
   generated ICV.

7.3.2.3.  Building the output Geneve Packet

   The GAO is placed before all covered Geneve Options, followed by the
   Geneve Payload.  A Geneve Option that is not covered by the GAO MUST
   NOT be placed after the GAO.  The Geneve Options covered by the GAO
   MUST remain in the same order as the order considered for generating
   the ICV.  A Geneve Option covered by the GAO MUST NOT be located
   before the GAO.  In addition, a Geneve Element MUST NOT change any
   bit located after the GAO that is covered by the GAO.

   The generated Geneve Packet is then forwarded to the Outer Tunnel
   encapsulation.

7.3.3.  GAO Inbound Processing

   Upon receiving a Geneve Packet, the receiving Geneve element
   determines the Geneve Packet is neither associated with a DISCARD nor
   with a BYPASS policy, and as such is expected to be SECURED - see
   [I-D.mglt-nvo3-geneve-security-architecture].

   When the Geneve Security Module finds a GAO, the inbound processing
   consists in the following actions:

   1.  Computing the Sequence Number




Migault                 Expires December 29, 2017              [Page 12]

Internet-Draft  Geneve Header Authentication Option (GAO)      June 2017


   2.  Validate the ICV

   3.  Apply the anti-replay protection

   4.  Remove the GAO from the Geneve Packet

   5.  GSP Validation

7.3.3.1.  Computing the Sequence Number

   When the GSO Sequence Number Size indicates the GSO Sequence Number
   is coded over 32 bits, the Sequence Number is as indicated in the
   GAO.

   When the GSO Sequence Number Size indicates the GSO Sequence Number
   is coded over 64 bits, the receiving node needs to evaluate the value
   of the 32 most significant bits.  If the Sequence Number is lower
   than the 32 least significant bits of the GSO Sequence Number, the
   receiving node will assume the 32 most significant bits of the
   Sequence Number are the most significant bits of the GSO Sequence
   incremented by one.  The Sequence Number is evaluated as the
   combination of its 32 most significant bits and the 32 least
   significant bits indicated in the GAO.

   In case it is not possible to increment these 32 most significant
   bits, the Sequence Number is considered out of the limit and the
   Geneve Packet is rejected.

   It is worth noting that if the Sequence number MUST NOT be
   incremented by several order of the most significant bits.

7.3.3.2.  ICV Validation

   To validate the ICV, the receiving node computes the ICV and compares
   the computed value with the value carried by the GAO.  If the two
   values match the ICV is validated.  In case of mismatch, the Geneve
   Packet is rejected.

   The ICV results from applying the GSO Authentication Algorithm with
   the GSO Authentication Key to the appropriated data.

   The appropriated data is build by concatenating the initial string
   "geneve authentication option" with the Geneve Fixed Header, the GSO
   Sequence Number, the GSO-ID, the Covered Length, the covered Geneve
   data.






Migault                 Expires December 29, 2017              [Page 13]

Internet-Draft  Geneve Header Authentication Option (GAO)      June 2017


   All elements are read from the Geneve Fixed Header or the GAO and the
   covered data is read as the number of bytes indicated by the Covered
   Length value of the GAO that follow the GAO.

7.3.3.3.  Anti Replay Protection

   The receiving node reads the Sequence Number and Compare it with the
   GSO Sequence Number stored in the GSA.  The difference Delta is
   evaluated by computing GSO Sequence Number - Sequence Number.

   If Delta is greater than GSO Anti Replay Window, the Geneve Packet is
   rejected.

   If Delta is strictly negative, the GSO Sequence Number is updated
   with the value of the Sequence Number.

7.3.3.4.  GAO Removal

   Once the ICV protection has been verified as well as the anti replay
   protection, the GAO is removed from the Geneve Packet.  The removal
   of the Option occurs after the UDP decapsulation, thus there is no
   impact on the Geneve Packet, and, for example, no length needs to be
   adjusted.

7.3.3.5.  GSP Validation

   GSP Validation validates a given GAO is conform to the expected GSP.
   This means that when the GAO has been removed, the resulting Geneve
   Packet is matched against the GSP DB in order to validate the
   resulting Geneve Packet is associated to the GSA.  Such verification
   is performed by checking the GSO Selectors.

   The Geneve Security Module also cheks that the expected part of the
   Geneve Packet have been covered as expected.  This includes the
   Geneve Options as well as the Geneve Payload Length.  In case a
   mismatch is dedected the Geneve Packet MUST be rejected.

   Some implementations MAY perform additional checks or
   transformations.  For example, some implementation, unless specified
   or agreed otherwise, SHOULD remove the immutable Geneve Options that
   are not covered by the validation.

   Once validation is completed, the Geneve Packet is forwarded to the
   Geneve Layer.







Migault                 Expires December 29, 2017              [Page 14]

Internet-Draft  Geneve Header Authentication Option (GAO)      June 2017


8.  IANA Considerations

   There are no IANA consideration for this document.

9.  Security Considerations

10.  Acknowledgment

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.

   [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.ietf-tls-dtls13]
              Rescorla, E., Tschofenig, H., and N. Modadugu, "The
              Datagram Transport Layer Security (DTLS) Protocol Version
              1.3", draft-ietf-tls-dtls13-00 (work in progress), April
              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>.

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

   [RFC4868]  Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA-
              384, and HMAC-SHA-512 with IPsec", RFC 4868,
              DOI 10.17487/RFC4868, May 2007,
              <http://www.rfc-editor.org/info/rfc4868>.

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




Migault                 Expires December 29, 2017              [Page 15]

Internet-Draft  Geneve Header Authentication Option (GAO)      June 2017


11.2.  Informative 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.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-geneve-security-architecture]
              Migault, D., "Geneve Security Architecture", July 2017,
              <https://tools.ietf.org/html/I-D.ietf-nvo3-geneve-
              security-architecture-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>.

   [RFC7364]  Narten, T., Ed., Gray, E., Ed., Black, D., Fang, L.,
              Kreeger, L., and M. Napierala, "Problem Statement:
              Overlays for Network Virtualization", RFC 7364,
              DOI 10.17487/RFC7364, October 2014,
              <http://www.rfc-editor.org/info/rfc7364>.

Author's Address

   Daniel Migault

   Email: daniel.migault@ericsson.com

















Migault                 Expires December 29, 2017              [Page 16]