| NVO3 | D. Migault |
| Internet-Draft | June 28, 2017 |
| Intended status: Standards Track | |
| Expires: December 30, 2017 |
Geneve Header Authentication Option (GAO)
draft-mglt-nvo3-geneve-authentication-option-00
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.
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 30, 2017.
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.
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].
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 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].
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:
The Geneve Header Authentication Option (GAO) expects to have the following properties:
The terminology used in this document has been introduced in [I-D.mglt-nvo3-geneve-security-architecture].
For generic format of the Geneve Options is defined in Figure 1. The following values are expected:
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
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.
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
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.
In order to implement the anti replay mechanisms the following parameters are provided:
In order to check the conformity with the GSP:
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:
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 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.
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 contribution of the Geneve Payload is determined by the sending node and evaluated for each Geneve Packet.
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.
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.
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.
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:
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.
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.
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.
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.
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.
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.
There are no IANA consideration for this document.
| [I-D.ietf-nvo3-encap] | Boutros, S., Ganga, I., Garg, P., Manur, R., Mizrahi, T., Mozes, D. and E. Nordmark, "NVO3 Encapsulation Considerations", Internet-Draft draft-ietf-nvo3-encap-00, 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., Gray, E., Black, D., Fang, L., Kreeger, L. and M. Napierala, "Problem Statement: Overlays for Network Virtualization", RFC 7364, DOI 10.17487/RFC7364, October 2014. |