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, . [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, DOI 10.17487/RFC4302, December 2005, . [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, . [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, January 2012, . 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, . [I-D.mglt-nvo3-geneve-security-architecture] Migault, D., "Geneve Security Architecture", July 2017, . [I-D.mglt-nvo3-security-requirements] Migault, D., "Geneve Security Requirements", July 2017, . [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, . Author's Address Daniel Migault Email: daniel.migault@ericsson.com Migault Expires December 29, 2017 [Page 16]