idnits 2.17.1 draft-mglt-nvo3-geneve-authentication-option-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 3 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 27, 2017) is 2495 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-16) exists of draft-ietf-nvo3-geneve-04 == Outdated reference: A later version (-43) exists of draft-ietf-tls-dtls13-00 ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) == Outdated reference: A later version (-12) exists of draft-ietf-nvo3-encap-00 -- No information found for draft-mglt-nvo3-geneve-encryption-option - is the name correct? -- No information found for draft-mglt-nvo3-geneve-security-architecture - is the name correct? -- No information found for draft-mglt-nvo3-security-requirements - is the name correct? Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NVO3 D. Migault 3 Internet-Draft June 27, 2017 4 Intended status: Standards Track 5 Expires: December 29, 2017 7 Geneve Header Authentication Option (GAO) 8 draft-mglt-nvo3-geneve-authentication-option-00 10 Abstract 12 This document describes the Geneve Header Authentication Option 13 (GAO). This option enables a Geneve element to authenticate the 14 Geneve Header with selected associated Geneve Options as well as a 15 portion of the Geneve Payload. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on December 29, 2017. 34 Copyright Notice 36 Copyright (c) 2017 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 2 52 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 3. Position versus DTLS/IPsec . . . . . . . . . . . . . . . . . 3 54 4. Scope of the GAO . . . . . . . . . . . . . . . . . . . . . . 5 55 5. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 56 6. GAO Description . . . . . . . . . . . . . . . . . . . . . . . 6 57 7. GAO Processing . . . . . . . . . . . . . . . . . . . . . . . 7 58 7.1. GAO Placement . . . . . . . . . . . . . . . . . . . . . . 7 59 7.2. GSA Parameters . . . . . . . . . . . . . . . . . . . . . 8 60 7.3. GAO Outbound Processing . . . . . . . . . . . . . . . . . 10 61 7.3.1. Generating the Sequence Number . . . . . . . . . . . 10 62 7.3.2. Generating a Covered Length . . . . . . . . . . . . . 11 63 7.3.3. GAO Inbound Processing . . . . . . . . . . . . . . . 12 64 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 65 9. Security Considerations . . . . . . . . . . . . . . . . . . . 15 66 10. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . 15 67 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 68 11.1. Normative References . . . . . . . . . . . . . . . . . . 15 69 11.2. Informative References . . . . . . . . . . . . . . . . . 16 70 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16 72 1. Requirements notation 74 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 75 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 76 document are to be interpreted as described in [RFC2119]. 78 2. Introduction 80 Geneve [I-D.ietf-nvo3-geneve] defines an overlay network that enables 81 communications between tenants within a given virtual network. The 82 Geneve overlay network enables these tenants to be distributed over a 83 data center or multiple data centers. As multiple virtual networks 84 share a common infrastructure, Geneve needs to isolate both 85 communications between virtual networks as well as each virtual 86 network address space [RFC7364]. 88 The Geneve Header indicates the virtual network a communication 89 belongs to with a Virtual Network Identifier (VNI). Geneve packets 90 may be steered to the appropriated destination tenant through the 91 destination switch based on that NVI value. In addition to the NVI, 92 the Geneve Header may carry additional metadata that impacts how the 93 traffic could be steered to the destination tenant. 95 As stated by [I-D.ietf-nvo3-encap] and 96 [I-D.mglt-nvo3-security-requirements], it is crucial that the 97 information of the Geneve Header remains protected and authenticated 98 in order to prevent that traffic be delivered to the wrong tenant. 99 Typically, without integrity check mechanisms, a one bit switch in 100 the NVI results in such a wrong delivery. Such vulnerability is 101 further increased by the use of UDP encapsulation that makes any 102 application able to spoof packets. 104 This document addresses these issues by proposing a GAO which enables 105 to authenticate the Geneve Header with a set of selected Geneve 106 Options as well as a portion of inner packet (Geneve Payload) carried 107 by the Geneve overlay network (Geneve Payload). In addition, GAO 108 also prevent a Geneve Packet to be replayed by introducing an anti- 109 replay mechanism. GAO does not provides encryption which is instead 110 provided by [I-D.mglt-nvo3-geneve-encryption-option]. 112 3. Position versus DTLS/IPsec 114 This section exposes the motivations for designing GAO rather than 115 re-using existing security mechanisms such as DTLS or IPsec. 117 GAO provides integrity protection of a Geneve Packet, i.e. the Geneve 118 Header, including a set of Geneve Options as well as a portion of the 119 Geneve Payload. 121 As Geneve is encapsulated in UDP packet, DTLS is a natural candidate. 122 Similarly IPsec/AH [RFC4302] defines an protocol to authenticate an 123 IP packet. However relying on DTLS (or IPsec)/AH instead of a 124 specific extension designed for Geneve comes with the following 125 drawbacks: 127 o Modern versions of DTLS [I-D.ietf-tls-dtls13] currently do not 128 consider authentication-only. Instead the traffic is always 129 encrypted. Encrypting the Geneve Header prevents on path Geneve 130 elements to manage secured intra NVI communications. Typically 131 when multiple intra NVI communications are multiplexed into a DTLS 132 tunnel, a Geneve on path element will not be able to re-route some 133 traffic nor to appropriately prioritize flows or load balance them 134 according to their NVI. On the other hand, DTLS1.2 [RFC6347] 135 enabled authentication-only protection, and further cipher suite 136 could be defined for DTLS1.3 in case there were a significant 137 advantage in using DTLS to secure the Geneve communications. In 138 case such cipher will not be available, currently defined end to 139 end encryption would prevent providing information useful to 140 manage the various intra-NVI communications. This information 141 might be carried by lower layer such as UDP using port number for 142 example. However, such alternatives clearly makes secure intra 143 NVI communication unnecessarily too hard to manage, and so does 144 not encourage a secure deployment of these communications. 145 Typically: 147 * Management of secure Geneve communications are reduces to 148 management of UDP tunnel which ignores all motivations for 149 designing Geneve. That is the ability to tag flows, as well as 150 to carry states or metadata. 152 * Management complexity is increased with an additional binding 153 between Geneve Header and port number for example. Not only a 154 new binding is introduced, but as Geneve Headers and UDP source 155 ports / destination ports have different spaces ranges, this 156 makes such correspondence not straight forward to manage. 157 Typically NVI are 24 bit long while source port are 16 bit 158 long, this means that additional destination port may be used 159 in order to benefit from the full NVI space. 161 * Increases the number of tunnels and the number of keying 162 material as different Geneve Header needs to be transported in 163 different UDP tunnel. The number of UDP tunnels may reach the 164 number of different Geneve communications. 166 o DTLS comes with a key exchange agreement, included as part of the 167 DTLS protocol. In most cases, DTLS or TLS is used without any 168 configurations by a (D)TLS client while the (D)TLS server has all 169 the necessary authentication information, so the (D)TLS client can 170 appropriately authenticate the (D)TLS server. In this case, for 171 end-to-end authentication, authentication is performed by both 172 Geneve NVEs which requires all of them to be appropriately 173 provisioned with the necessary authentication credentials. 174 Management of these authentication credential is not trivial and 175 is expected to handled in addition of the security policies. In 176 addition, the presence of such handshake protocol may introduce 177 some latencies in a forwarding plan usually managed by a 178 orchestrator. As a result, if DTLS would be used, a variant of 179 DTLS without key exchange may rather be considered. 181 o Geneve does not provide any standard way to inform whether a 182 packet is authenticated or not. The current assigned port number 183 for Geneve is 6081. In order to make possible for the receiving 184 node to distinguish an unprotected Geneve Packet from a protected 185 traffic, a new port should be defined. 187 o The current use of TLS is usually based on a TLS client wishing to 188 access a resource using TLS. In that case, the TLS client uses a 189 specific port number. A server may also redirect the requests 190 from a client that is non protected to a specific port which 191 defines the protected version of that service. Such redirection 192 is usually performed when the service defines that resource has to 193 be accessed using a secure channel. In addition, the redirection 194 is performed by the application protocol. As a result, the 195 security policies as usually quite simple that is, 1) security 196 initiated by the client or 2) server enforces that all requested 197 are secured. The case of Geneve overlay network considers instead 198 the coexistence of protected and non protected traffic which would 199 require some mechanisms to define and enforce security policies 200 not yet part of DTLS. 202 o DTLS usually protects the whole UDP payload. In our case, the 203 protection of the Geneve Header only, for example, would require 204 some further developments to the existing DTLS. 206 o IPsec/AH prevents the creation of the Geneve overlay network. 207 IPsec/AH has been defined for end-to-end IP communications. In 208 the case of a Geneve Packet, the two ends are defined by the IP 209 addresses of the Geneve Packet Outer IP Headers. These IP 210 addresses are not necessarily the Geneve NVE, and could instead be 211 those of an Geneve element that belong to the Geneve overlay 212 network and in charge of steering the traffic to another Geneve 213 overlay element. With IPsec/AH, the IP addresses could not be 214 modified, and the Geneve Packet will not be able to be steered 215 across the Geneve overlay network. In this case IPsec/AH could be 216 used for a hop-by-hop security. This would require each node of 217 the Geneve Overlay network to be provisioned appropriately with 218 the IPsec material which would come with significant management 219 issues. In addition, this would not achieve a end-to-end security 220 between the two ends of the Geneve tunnel. 222 o IPsec/ESP may also be used without encryption. However, in this 223 case, the port number would be protected, which would prevent 224 Geneve element to redirect the traffic to a different Geneve 225 element using a different port. Such constraint may prevent the 226 overlay network to be operated as an overlay network, that is any 227 on path Geneve element is able to redirect the traffic to another 228 Geneve element that belongs to the overlay network. 230 4. Scope of the GAO 232 The Geneve Header Authentication Option (GAO) expects to have the 233 following properties: 235 o Provides means to authenticate the Geneve Header, a selected 236 associated set of options as well as part of the Geneve Payload. 238 o Provides an anti-replay mechanism. This option does not encrypt 239 any data and as such does not provide any privacy. When privacy 240 is expected, it can be enforced by the Geneve overlay network 241 using GEO ([I-D.mglt-nvo3-geneve-encryption-option]) as well as by 242 the Tenant's System which may encrypt their communications using 243 IPsec/ESP or TLS. The main purpose of the GAO is to provide means 244 for the infrastructure to ensure that Geneve communications cannot 245 be injected for example by modifying the NVI. 247 o Provides authentication - at least in an orchestrated environment 248 - to the two NVEs, but also to any appropriately configured on- 249 path Geneve forwarding element. 251 o Provides read access to the Geneve Header for any Geneve on path 252 elements. This option is expected to enable Geneve communications 253 to be secured, while benefiting from all the facilities provided 254 by Geneve. 256 o Provide the ability for on path Geneve forwarding elements to add 257 Geneve Options on Geneve authenticated Packets without 258 invalidating the GAO. 260 o Provides means with some restrictions for an on-path element to 261 add Geneve Option and authenticate that Geneve Option using a GAO. 263 5. Terminology 265 The terminology used in this document has been introduced in 266 [I-D.mglt-nvo3-geneve-security-architecture]. 268 6. GAO Description 270 For generic format of the Geneve Options is defined in Figure 1. The 271 following values are expected: 273 o Option Class: 0x0000 275 o Type: C is unset as the GAO can simply be ignored by a NVE or a 276 transit node. The GSP will prevent to accept a GOA that is 277 mandated by the GSP and that has not been validated. 279 o R is set to 0. 281 o Length: This document only considers the algorithms recommended by 282 [I-D.ietf-ipsecme-rfc7321bis] AUTH_HMAC_SHA2_256_128 and 283 AUTH_HMAC_SHA2_512_256. These algorithms are defined in [RFC4868] 284 with a respective 16 and 32 byte ICV. As a result, the option 285 length is expected to 4 + 28 = 32 bytes (resp. 4 + 44 = 48 bytes) 286 which leads to 8 or 12 as the possible values for Length. 288 0 1 2 289 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 290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 291 | Option Class | Type |R|R|R| Length | 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 | Variable Option Data | 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 296 Figure 1: Geneve Option Format 298 0 1 2 299 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 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 | Sequence Number | 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 | GAO-ID | Covered Length | 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 | | 306 | ICV 128/256 bits 16 / 32 octets | 307 | | 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 310 Figure 2: Geneve Authentication Data 312 o Sequence Number (32 bits): indicates the Sequence number of the 313 Geneve Header. When the SN is 32 bit long, the whole SN is 314 indicated. When the SN is 64 bit long, only the 32 least 315 significant bits are indicated. 317 o GAO-ID (16 bits): indicates the identifier of the GAO. This 318 identifier is useful to retrieve the GSA, with the necessary 319 information to compute the GAO or to validate it. 321 o Covered Length (16 bits): indicates in number of bytes following 322 the GAO that are covered by the authentication. 324 o ICV contains the HMAC value. 326 7. GAO Processing 328 7.1. GAO Placement 330 A GAO option covers the Geneve Header, the Geneve Options following 331 the GAO as well as the Covered Length appended to the GAO. As a 332 result, any on path (Geneve) element MUST leave the Geneve Fixed 333 Header and the first Covered Length bytes after GAO unchanged. 335 GAO does not covers the Geneve Options placed between the Geneve 336 Fixed Header and the GAO. In addition, GAO does not cover the bytes 337 located after the Covered Length. 339 Geneve Options that are expected to be updated by any Geneve 340 forwarding elements MUST be located between the Geneve Fixed Header 341 and the existing GAO. 343 When a Geneve Packet is received by a Geneve forwarding elements and 344 that element is expected to insert an additional Geneve Option, the 345 Geneve forwarding element MUST NOT insert the Geneve Option in a area 346 covered by a GAO. A safe way to proceed is that Geneve forwarding 347 element that do not understand GAO MUST insert new Geneve Option 348 right after the Geneve Fixed Header. This will result in having the 349 Gneve Option before the existing GAO. When the Geneve forwarding 350 element understadn GAO it can consider the covered area by each GAO 351 and place its new option in a non covered area. 353 Geneve Authentication Option -----+ 354 | 355 | Covered Length 356 <-------------------> v <--------------------> 357 +---------------------+-------------+-----+------------+----------------+ 358 | Geneve Fixed Header | Geneve Opt. | GAO | Geneve Opt.| Geneve Payload | 359 +---------------------+-------------+-----+------------+----------------+ 360 <--------+----------> <---------+-------> <----------+---------> <-+--> 361 | | | | 362 +-------------------------------------------+ | 363 Fields covered | | 364 by the authentication +----------------------------------+ 365 Fields not covered 366 by the authentication 368 Figure 3: Geneve Authentication Options Placement 370 7.2. GSA Parameters 372 This section describes the parameters of the GAS necessary to compute 373 or validate the GAO. These parameters are then latter used to 374 described the processing. 376 o GSO ID: The identifier of that GAO. This identifier is used to 377 bind the GAO with the appropriated GSA. It is expected that GSA 378 are uniquely identified on the receiver side. In case collision 379 are supported, the implementation MUST be able to 380 deterministically associate the GAO to the appropriated GSA for 381 example by using IP addresses and UDP ports. 383 o GSO Protocol: The security protocol associated with the Geneve 384 Security Option. In our case the protocol is GAO. 386 o GSO Authentication Algorithm: This document follows 387 recommendations provided by [I-D.ietf-ipsecme-rfc7321bis] which 388 recommends AUTH_HMAC_SHA2_256_128 and AUTH_HMAC_SHA2_512_256 389 defined in [RFC4868]. 391 o GSO Payload Covered Length: the length of the Geneve Payload 392 covered by GAO. The expression of the length can be a number of 393 bytes, but it may also be defined with an abstract designation. 394 For example, a sending node may be willing to authenticate the 395 Geneve Payload up to the ESP layer. In that case, the sending 396 node will have to compute the corresponding Payload Covered 397 Length. This value is only used by the sending node. The 398 receiving node read that value from the GAO. 400 o GSO Covered Geneve Options: Indicates the Geneve Options covered 401 by the GAO. This indication is primarily necessary for the 402 sending node and is derived from the Geneve Packet by the 403 receiving node. It MUST be checked by the receiving node to 404 validate the GSA. It might typically be expressed as a list of 405 Geneve Options that needs to be covered by the authentication. 407 o GSO Authentication Key: the shared secret necessary compute and 408 validate the HMAC value generated by the Authentication Algorithm 409 specified above. 411 In order to implement the anti replay mechanisms the following 412 parameters are provided: 414 o GSO Sequence Number Size: indicates the size of the SN. This 415 document considers a 32 bit or a 64 bit length. 417 o GSO Sequence Number: that designates the Sequence Number last sent 418 or received packet. 420 o GSO Anti Replay Window: that indicates the windows that defines 421 out-of order packet or late packets versus a replayed Geneve 422 Packet. Any Geneve Packet with a lower SN than GSO Sequence 423 Number - Anti Replay Windows MUST be rejected. 425 In order to check the conformity with the GSP: 427 o Selectors: The selectors are provided so the receiver can check 428 the Geneve Packet protected by the GSO is conform to the GSP. In 429 other words a valid GSO is not sufficient for the Geneve Packet to 430 be forwarded to the upper layers. Note that the Selectors MUST 431 match the Geneve Packet associated to the GSA before the GSO is 432 built for outbound Packets. For inbound Geneve Packet the 433 Selectors are those that correspond to the Geneve Packet after the 434 GSO has been validated/decrytped. Selectors are mostly expected 435 to be used by the GSA for incoming Geneve Packet, in order to 436 check the GSA is conform with its GSP. 438 o GSA Life time: 440 7.3. GAO Outbound Processing 442 Upon receiving a Geneve Packet, the Geneve Security Module performs a 443 GSP DB look up to determine if any security action is required. If 444 the security action is DISCARD, the Geneve Packet is discarded. If 445 the security action is BYPASS, the Geneve Packet is sent to the lower 446 layers for the outer encapsulation without any additional security 447 consideration. If the action is SECURE, the GSP returns the list of 448 GSAs that need to be applied. The list is an ordered list, and the 449 Geneve Security Module performs these GSAs in the received order. 450 (See [I-D.mglt-nvo3-geneve-security-architecture] for more 451 information.) 453 When a list of GSAs is provided, it is crucial that the 454 implementation updates the Selectors of the further GSAs according to 455 the actions undertaken by the previous GSAs. In most cases, a GSA 456 results in the addition of GSO. The Selectors of the next GSA MUST 457 consider this new GSO, in the Selectors. 459 The outbound processing consists in the following actions: 461 1. Generating the Sequence Number 463 2. Generating a Covered Length 465 3. Generating the ICV 467 4. Building the GAO 469 5. Building the output Geneve Packet 471 7.3.1. Generating the Sequence Number 473 The Sequence Number is used to prevent anti replay. The Sequence 474 Number is any number strictly greater than the current value of the 475 GSO Sequence Number mentioned in the GSA. 477 The size of the GSO Sequence Number is designated by the GSO Sequence 478 Number Size. The GSO Sequence Number can be a 32 bit or 64 bit 479 number. When the limit or the GSO Sequence number has been reached, 480 the GSA MUST be renewed. In other words, no re-initialization nor 481 rolling mechanisms are expected for the GSO Sequence Number. The 482 Geneve Elements need to take the necessary actions in order to 483 generate GSAs before the limit of the GSO Sequence Number is reached. 485 The new value of the GSO Sequence Number replaces the former GSO 486 Sequence Number in the GSA. 488 7.3.2. Generating a Covered Length 490 The Covered Length describes the number of bytes of the Geneve Packet 491 that are located after the GAO and authenticated by GAO. 493 The Covered Length includes Geneve Options that are covered by the 494 authentication designated by the GSO Covered Geneve Options as well 495 as a portion of the Geneve Payload designated by the GSO Payload 496 Covered Length. 498 The covered Geneve Options MUST be immutable, and any on-path Geneve 499 element MUST NOT change any of the Geneve Options covered by GAO. 500 The covered Options MAY be agreed between the two Geneve element, 501 however, by default, it is expected that the sending node will 502 include any immutable Geneve Option. The agreement of the covered 503 Geneve Options is not necessary to validate the GAO. In fact the 504 position of the GAO in the Geneve Packet indicates deterministically 505 the covered Geneve Options. However, Geneve Options that are 506 immutable while not being covered by the GAO will be considered 507 suspicious and as such SHOULD be rejected by the Geneve Security 508 Module of the receiving node. This Geneve Option could have been 509 inserted as well as modified. Of course some Geneve Security Module 510 MAY also specify a list of immutable Geneve Option that are not 511 expected to be covered. In that case such options MUST NOT be 512 removed by the Geneve Security Module. 514 Overall, the covered Geneve Options is determined by the sending 515 node. In addition that Geneve Options may have varying size, the 516 contribution of the Covered Length is likely to vary for each Geneve 517 Packet. 519 Similarly, the contribution of the Covered Length by the Geneve 520 Payload is also likely to vary for each Geneve Packet. More 521 specifically, it is more likely that a GSA defines the layers of the 522 Geneve Payload that needs to be authenticated instead of a number of 523 bytes. For example, a GSA may indicate that the Geneve Payload may 524 be covered up to the ESP or (D)TLS layer. In addition, the GSA may 525 also indicate an upper bound value for the Covered Length which could 526 be imposed by hardware or computing restrictions. As a result, the 527 contribution of the Geneve Payload is determined by the sending node 528 and evaluated for each Geneve Packet. 530 7.3.2.1. Generating the ICV 532 The ICV results from applying the GSO Authentication Algorithm with 533 the GSO Authentication Key to the appropriated data. 535 The appropriated data is build by concatenating the initial string 536 "geneve authentication option" with the Geneve Fixed Header, the GSO 537 Sequence Number, the GSO-ID, the GSO Covered Length, the covered 538 Geneve options as well as the covered part of the Geneve Payload. 540 All fields of the Geneve Fixed Header are considered, including the 541 Rsv and Reserved fields. It is important to understand that these 542 fields are expected to remain immutable fields. 544 7.3.2.2. Building the GAO 546 The GAO is built by concatenating the 32 least significant bits of 547 the GSO Sequence Number, the GAO-ID, the Covered Length and the 548 generated ICV. 550 7.3.2.3. Building the output Geneve Packet 552 The GAO is placed before all covered Geneve Options, followed by the 553 Geneve Payload. A Geneve Option that is not covered by the GAO MUST 554 NOT be placed after the GAO. The Geneve Options covered by the GAO 555 MUST remain in the same order as the order considered for generating 556 the ICV. A Geneve Option covered by the GAO MUST NOT be located 557 before the GAO. In addition, a Geneve Element MUST NOT change any 558 bit located after the GAO that is covered by the GAO. 560 The generated Geneve Packet is then forwarded to the Outer Tunnel 561 encapsulation. 563 7.3.3. GAO Inbound Processing 565 Upon receiving a Geneve Packet, the receiving Geneve element 566 determines the Geneve Packet is neither associated with a DISCARD nor 567 with a BYPASS policy, and as such is expected to be SECURED - see 568 [I-D.mglt-nvo3-geneve-security-architecture]. 570 When the Geneve Security Module finds a GAO, the inbound processing 571 consists in the following actions: 573 1. Computing the Sequence Number 574 2. Validate the ICV 576 3. Apply the anti-replay protection 578 4. Remove the GAO from the Geneve Packet 580 5. GSP Validation 582 7.3.3.1. Computing the Sequence Number 584 When the GSO Sequence Number Size indicates the GSO Sequence Number 585 is coded over 32 bits, the Sequence Number is as indicated in the 586 GAO. 588 When the GSO Sequence Number Size indicates the GSO Sequence Number 589 is coded over 64 bits, the receiving node needs to evaluate the value 590 of the 32 most significant bits. If the Sequence Number is lower 591 than the 32 least significant bits of the GSO Sequence Number, the 592 receiving node will assume the 32 most significant bits of the 593 Sequence Number are the most significant bits of the GSO Sequence 594 incremented by one. The Sequence Number is evaluated as the 595 combination of its 32 most significant bits and the 32 least 596 significant bits indicated in the GAO. 598 In case it is not possible to increment these 32 most significant 599 bits, the Sequence Number is considered out of the limit and the 600 Geneve Packet is rejected. 602 It is worth noting that if the Sequence number MUST NOT be 603 incremented by several order of the most significant bits. 605 7.3.3.2. ICV Validation 607 To validate the ICV, the receiving node computes the ICV and compares 608 the computed value with the value carried by the GAO. If the two 609 values match the ICV is validated. In case of mismatch, the Geneve 610 Packet is rejected. 612 The ICV results from applying the GSO Authentication Algorithm with 613 the GSO Authentication Key to the appropriated data. 615 The appropriated data is build by concatenating the initial string 616 "geneve authentication option" with the Geneve Fixed Header, the GSO 617 Sequence Number, the GSO-ID, the Covered Length, the covered Geneve 618 data. 620 All elements are read from the Geneve Fixed Header or the GAO and the 621 covered data is read as the number of bytes indicated by the Covered 622 Length value of the GAO that follow the GAO. 624 7.3.3.3. Anti Replay Protection 626 The receiving node reads the Sequence Number and Compare it with the 627 GSO Sequence Number stored in the GSA. The difference Delta is 628 evaluated by computing GSO Sequence Number - Sequence Number. 630 If Delta is greater than GSO Anti Replay Window, the Geneve Packet is 631 rejected. 633 If Delta is strictly negative, the GSO Sequence Number is updated 634 with the value of the Sequence Number. 636 7.3.3.4. GAO Removal 638 Once the ICV protection has been verified as well as the anti replay 639 protection, the GAO is removed from the Geneve Packet. The removal 640 of the Option occurs after the UDP decapsulation, thus there is no 641 impact on the Geneve Packet, and, for example, no length needs to be 642 adjusted. 644 7.3.3.5. GSP Validation 646 GSP Validation validates a given GAO is conform to the expected GSP. 647 This means that when the GAO has been removed, the resulting Geneve 648 Packet is matched against the GSP DB in order to validate the 649 resulting Geneve Packet is associated to the GSA. Such verification 650 is performed by checking the GSO Selectors. 652 The Geneve Security Module also cheks that the expected part of the 653 Geneve Packet have been covered as expected. This includes the 654 Geneve Options as well as the Geneve Payload Length. In case a 655 mismatch is dedected the Geneve Packet MUST be rejected. 657 Some implementations MAY perform additional checks or 658 transformations. For example, some implementation, unless specified 659 or agreed otherwise, SHOULD remove the immutable Geneve Options that 660 are not covered by the validation. 662 Once validation is completed, the Geneve Packet is forwarded to the 663 Geneve Layer. 665 8. IANA Considerations 667 There are no IANA consideration for this document. 669 9. Security Considerations 671 10. Acknowledgment 673 11. References 675 11.1. Normative References 677 [I-D.ietf-ipsecme-rfc7321bis] 678 Wouters, P., Migault, D., Mattsson, J., Nir, Y., and T. 679 Kivinen, "Cryptographic Algorithm Implementation 680 Requirements and Usage Guidance for Encapsulating Security 681 Payload (ESP) and Authentication Header (AH)", draft-ietf- 682 ipsecme-rfc7321bis-06 (work in progress), June 2017. 684 [I-D.ietf-nvo3-geneve] 685 Gross, J., Ganga, I., and T. Sridhar, "Geneve: Generic 686 Network Virtualization Encapsulation", draft-ietf- 687 nvo3-geneve-04 (work in progress), March 2017. 689 [I-D.ietf-tls-dtls13] 690 Rescorla, E., Tschofenig, H., and N. Modadugu, "The 691 Datagram Transport Layer Security (DTLS) Protocol Version 692 1.3", draft-ietf-tls-dtls13-00 (work in progress), April 693 2017. 695 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 696 Requirement Levels", BCP 14, RFC 2119, 697 DOI 10.17487/RFC2119, March 1997, 698 . 700 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 701 DOI 10.17487/RFC4302, December 2005, 702 . 704 [RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA- 705 384, and HMAC-SHA-512 with IPsec", RFC 4868, 706 DOI 10.17487/RFC4868, May 2007, 707 . 709 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 710 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 711 January 2012, . 713 11.2. Informative References 715 [I-D.ietf-nvo3-encap] 716 Boutros, S., Ganga, I., Garg, P., Manur, R., Mizrahi, T., 717 Mozes, D., and E. Nordmark, "NVO3 Encapsulation 718 Considerations", draft-ietf-nvo3-encap-00 (work in 719 progress), June 2017. 721 [I-D.mglt-nvo3-geneve-encryption-option] 722 Migault, D., "Geneve Encryption Option", July 2017, 723 . 726 [I-D.mglt-nvo3-geneve-security-architecture] 727 Migault, D., "Geneve Security Architecture", July 2017, 728 . 731 [I-D.mglt-nvo3-security-requirements] 732 Migault, D., "Geneve Security Requirements", July 2017, 733 . 736 [RFC7364] Narten, T., Ed., Gray, E., Ed., Black, D., Fang, L., 737 Kreeger, L., and M. Napierala, "Problem Statement: 738 Overlays for Network Virtualization", RFC 7364, 739 DOI 10.17487/RFC7364, October 2014, 740 . 742 Author's Address 744 Daniel Migault 746 Email: daniel.migault@ericsson.com