idnits 2.17.1 draft-mglt-nvo3-geneve-security-architecture-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 : ---------------------------------------------------------------------------- No issues found here. 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 2492 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) -- Looks like a reference, but probably isn't: '0' on line 443 -- Looks like a reference, but probably isn't: '1' on line 443 == Missing Reference: 'GSA1' is mentioned on line 445, but not defined == Missing Reference: 'GSA2' is mentioned on line 445, but not defined -- Looks like a reference, but probably isn't: '50' on line 449 == Outdated reference: A later version (-12) exists of draft-ietf-nvo3-encap-00 == Outdated reference: A later version (-16) exists of draft-ietf-nvo3-geneve-04 -- No information found for draft-mglt-nvo3-geneve-authentication-option - is the name correct? -- No information found for draft-mglt-nvo3-geneve-encryption-option - is the name correct? -- No information found for draft-mglt-nvo3-security-requirements - is the name correct? Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 7 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 Security Architecture 8 draft-mglt-nvo3-geneve-security-architecture-00 10 Abstract 12 This document describes the Geneve Security Architecture. 14 Status of This Memo 16 This Internet-Draft is submitted in full conformance with the 17 provisions of BCP 78 and BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF). Note that other groups may also distribute 21 working documents as Internet-Drafts. The list of current Internet- 22 Drafts is at http://datatracker.ietf.org/drafts/current/. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 This Internet-Draft will expire on December 29, 2017. 31 Copyright Notice 33 Copyright (c) 2017 IETF Trust and the persons identified as the 34 document authors. All rights reserved. 36 This document is subject to BCP 78 and the IETF Trust's Legal 37 Provisions Relating to IETF Documents 38 (http://trustee.ietf.org/license-info) in effect on the date of 39 publication of this document. Please review these documents 40 carefully, as they describe your rights and restrictions with respect 41 to this document. Code Components extracted from this document must 42 include Simplified BSD License text as described in Section 4.e of 43 the Trust Legal Provisions and are provided without warranty as 44 described in the Simplified BSD License. 46 Table of Contents 48 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 2 49 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 50 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 4. Architecture Overview . . . . . . . . . . . . . . . . . . . . 4 52 5. Geneve Security Policies Database . . . . . . . . . . . . . . 5 53 5.1. Selectors . . . . . . . . . . . . . . . . . . . . . . . . 6 54 5.2. Geneve Security Policies . . . . . . . . . . . . . . . . 8 55 5.3. Geneve Security Policies Example . . . . . . . . . . . . 8 56 6. Geneve Security Association Database . . . . . . . . . . . . 11 57 6.1. Geneve Security Associations . . . . . . . . . . . . . . 11 58 7. Geneve Security Module Packet Processing . . . . . . . . . . 13 59 7.1. Outbound Geneve Processing . . . . . . . . . . . . . . . 13 60 7.2. Inbound Geneve Packet Processing . . . . . . . . . . . . 13 61 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 62 9. Security Considerations . . . . . . . . . . . . . . . . . . . 14 63 10. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . 14 64 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 65 11.1. Normative References . . . . . . . . . . . . . . . . . . 15 66 11.2. Informational References . . . . . . . . . . . . . . . . 15 67 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16 69 1. Requirements notation 71 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 72 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 73 document are to be interpreted as described in [RFC2119]. 75 2. Introduction 77 [I-D.ietf-nvo3-encap] and [I-D.mglt-nvo3-security-requirements] 78 clearly state the need to secure the Geneve overlay network and 79 provide means to authenticate the Geneve Header as well as being able 80 to encrypt the Geneve Payload. 82 Both of these requirements are fulfilled with specific Geneve 83 Security Options. More explicitly, 84 [I-D.mglt-nvo3-geneve-authentication-option] defines an option that 85 authenticate the Geneve fixed Header and optionally a set of Geneve 86 Option as well as a portion of the Geneve Payload. 87 [I-D.mglt-nvo3-geneve-encryption-option] defines a Geneve Option that 88 enables to encrypt a subset of Geneve Options as well as a portion of 89 the Geneve Payload. Further descriptions on how an Geneve Security 90 Option is treated is out of the scope of this document. 92 This document defines how the Geneve overlay can be secured properly. 93 A Geneve Element may handle different Geneve overlay networks 94 associated with different level of security. This document defines 95 how to associate a level of security to an Geneve overlay network. 96 In addition, a security level for a given overlay network may result 97 in a combination of multiple Geneve Security Options. As the order 98 these Geneve Security Options are processed matters, it is necessary 99 the sending and receiving Geneve Element have similar behaviours in 100 order to guarantee interoperability while securing a Geneve overlay 101 Network. 103 This document explains how Geneve Security Policies and Geneve 104 Security Associations are organized to associate a given level of 105 security to an Geneve overlay network. In addition, this document 106 also exposes how the Geneve Security Module implementing the security 107 interacts with the Geneve architecture. 109 3. Terminology 111 o Geneve Elements: designates all elements that handled Geneve 112 Packets. These elements may be terminal elements such as NVEs for 113 example, but can also be on path elements that are expected to 114 manage the flow inside the Geneve overlay network. 116 o Geneve Packet: designates the packet that Geneve Elements are 117 expected to handled. It is composed of a Geneve Header and a 118 Geneve Payload. In this document the Outer Ethernet Header and 119 Outer IPv4 Header as well as the Outer UDP Header defined in 120 [I-D.ietf-nvo3-geneve] section 3.1 are not part of the Geneve 121 Packet. Similarly, the Outer Ethernet Header, the Outer IPv6 122 Header as well as the Outer UDP Header defined in 123 [I-D.ietf-nvo3-geneve] section 3.2 are not part of the Geneve 124 Packet. 126 o Geneve Header: is described in [I-D.ietf-nvo3-geneve] section 3.4. 127 The Geneve Header may contain zero or more Geneve options. 129 o Geneve Payload: designates the data carried by a Geneve Packet. 130 [I-D.ietf-nvo3-geneve]. In [I-D.ietf-nvo3-geneve] section 3.1 and 131 section 3.2, the Geneve Payload would be the Inner Ethernet 132 Header, the Payload and the Frame Check Sequence. 134 o Geneve Fix Header: The Geneve Header without any Geneve Options. 136 o Geneve Security Policies (GSP): 138 o Geneve Security Policies Data Base (GSP DB): 140 o Geneve Security Association (GSA): 142 o Geneve Security Association Data Base (GSA DB): 144 o Geneve Security Options (GSO): A security option defined for 145 Geneve. Currently the security options that have been defined are 146 GAO or GEO. 148 o Geneve Authentication Option (GAO): Geneve Option that describes 149 how to authenticate the Geneve Header as well as part of the 150 Geneve Payload. This option is described in 151 [I-D.mglt-nvo3-geneve-authentication-option]. 153 o Geneve Encryption Option (GEO): Geneve Option that describe how to 154 encrypt Geneve Options as well as a part of the Geneve Payload. 155 GEO is defined in [I-D.mglt-nvo3-geneve-encryption-option]. 157 o Geneve Security Module: an implementation responsible to enforce 158 the security of Geneve Packets. 160 4. Architecture Overview 162 The Geneve Security Architecture is represented in figure Figure 1. 163 Geneve security is enforced by the Geneve Security Module. The 164 Geneve Security Policies (GSP) define which which flows inside a 165 virtuial network needs to be secured by associating a action SECURE, 166 BYPASS or DISCARD to each Geneve Packet. When a Geneve Packet is 167 tagged as SECURE, the GSP provides specific structures known as 168 Geneve Security Associations (GSA) that describe how the Geneve 169 Packet MUST be secured. Typically, the GSA defines the type of 170 option (Geneve Authentication Option (GAO) or the Geneve Encryption 171 Option (GEO) to be computed or validated, as well as the necessary 172 material such as the appropriated counters, the necessary keys to 173 compute and validate the GSO. GSP and GSA are respectively stored in 174 GSP Database (GSP DB) and GSA Database (GSA DB). 176 For outbound traffic, the Geneve Security Module receives a non 177 secured Geneve Packet and is responsible to secure that Geneve Packet 178 with the appropriated GSOs - as defined by the GSP/GSAs. Once the 179 GSO have been added, Outer Encapsulation is performed as described in 180 [I-D.ietf-nvo3-geneve] i.e. the Geneve Packet is being encapsulated 181 with Outer Ethernet / Outer IPv4 or IPv6 / and Outer UDP. 183 For inbound traffic, the Geneve Security Module defines whether a 184 incoming Geneve Packet must be secured or not as defined by the GSP. 185 If a Geneve Packet does not have to be secured, any GSO found is 186 ignored. Otherwise, the Geneve Security Module validates each GSO, 187 and check the validated GSOs are conformed to the defined GSP. The 188 last step is necessary to make sure that in addition to valid 189 security options, the expected GSO were encountered. 191 This document assumes that all nodes GSP DB and GSA DB are 192 appropriately provisioned by the control plane. 194 outbound packets inbound packets 195 | ^ 196 v | 197 +-----------------------------+ +-------------------------------+ 198 | Geneve | | Geneve | 199 +-----------------------------+ +-------------------------------+ 200 | Geneve Security Module | | Geneve Security Module | 201 | +---------+| | +-----------+| 202 | Computation | GSA DB || | Check | GSA DB || 203 | |... || | ^ BYPASS |... || 204 |+--------+ SECURE |+-------+|| |+--------+ SECURE |+---------+|| 205 || GSP DB |------->|| GSA ||| || GSP DB |------->|| GSA ||| 206 |+--------+ |+-------+|| |+--------+ |+---------+|| 207 | v (DISCARD) +---------+| | ^ (DISCARD) +-----------+| 208 | BYPASS | | | 209 +-----------------------------+ +-------------------------------+ 210 | Outer Encapsulation | | Outer Decapsulation | 211 +-----------------------------+ +-------------------------------+ 212 | ^ 213 v | 214 ----------------------------------------------------------------- 215 Network 217 Figure 1: Geneve Security Architecture 219 5. Geneve Security Policies Database 221 The GSP DB contains a list of GSP that associates a Geneve Packet 222 with a specific action BYPASS, DISCARD, SECURE. 224 The matching between a Geneve Packet and an action is performed 225 through Selectors. These Selectors associated to specific values 226 defined whether a Geneve Packet match a given GSP. As GSO may result 227 in encrypting a Selector, a GSP lookup is always performed with a 228 "clear text" Geneve Packet. More specifically, the GSP lookup for a 229 Geneve Packet associated with the SECURE action is performed before 230 the GSO is being added or after the GSO has been validated. For 231 outbound Geneve Packet, a GSP DB look up is performed using the 232 Selectors' value before the GSO is computed. In that case, the GSP 233 will even provide the required structure to generate the GSO. On the 234 other hand, for incoming traffic, the GSO is identified by an 235 identifier carried by the Geneve Packet, a GSP look up is performed 236 once the GSO has been valiated / decryped. As a consequence, the 237 same GSP DB is shared by the sending and the receiving Geneve 238 Element. 240 When BYPASS is selected, then the Geneve Security Module forwards the 241 matching Geneve to the next layer. As represented in Figure 1, the 242 next layer of an outbound Geneve Packet is the Outer Encapsulation 243 while the next layer of an incoming Geneve Packet is the Geneve layer 244 . When DISCARD is selected, the Geneve Security Module is expected to 245 drop the matching Geneve Packet. When a SECURE action is selected 246 the associated GSAs MUST be provided. For outbound Geneve Packet, 247 the GSAs provided will be used in order to appropriately generate the 248 GSO. On the other hand, for incoming Geneve Packet, the GSAs are 249 returned so the Geneve Security Module can validate the GSO present 250 in the Geneve Packet are conform to the GSP. 252 It is worth noting that for incoming Geneve Packet, those not tagged 253 as BYPASS or DISCARD are by default considered as tagged as SECURE. 254 This means that the GSP DB may be split into sub databases that 255 contains GSP associated to a specific action. GSP DB (DISCARD/ 256 BYPASS) may contain all GSP associated to the DISCARD and BYPASS 257 rules while GSP DB (SECURE) contains all GSP associated to the action 258 SECURE. By doing so, a incoming Geneve Packet may be associated to 259 the SECURE action without performing a lookup on GSP DB (SECURE). 260 This does not prevents the Geneve Security Module from validating the 261 GSO found in the incoming Geneve Packet, as these GSO are carrying a 262 specific Identifier. On the other hand, the GSP DB (SECURE) MUST be 263 lookup in order to validate that all GSO defined by the security 264 policies have been appropriately validated. 266 5.1. Selectors 268 The Selectors are the elements read from the packet in order to match 269 a GSP. When a Selector is expected to be found in the Geneve Packet, 270 the Selectors values that match the condition are indicated with a 271 range or a list of matching values. For clarity, this document uses 272 ANY to indicate the full range. When the Selector may not exist or 273 may not be accessible and must be ignored to evaluate the matching 274 condition, it is qualified of being OPAQUE. 276 Geneve Header Selectors: 278 o Geneve Version (2 bits): The version of the Geneve Version. This 279 field is always present and MUST be specified. When all Geneve 280 Version are associated to the same GSP, then all values must be 281 specified with ANY = [0, ..., 4]. 283 o OAM bit (1 bit): The indication of an OAM indication. When OAM 284 and non OAM traffic is associated to the same GPS, then all values 285 must be indicated with ANY = [0, 1]. 287 o Critical bit ( 1 bit): indicates the presence of a critical 288 option. When the presence of a critical option or its absence are 289 associated to the same GSP, then all values must be indicated with 290 ANY = [0, 1] 292 o Rsv (6 bits): Currently [I-D.ietf-nvo3-geneve] specifies the field 293 is set to zero by the sender and ignored by the receiver. 294 According to these rules, the sender is expected to DISCARD any 295 non zero values and the receiver is expect to indicate all these 296 values in its GSP. 298 o Protocol Type (16 bits): indicates the type of the Geneve Payload. 299 It is likely that only a few types will be specified for matching. 301 o VNI: indicates the virtual network identifier. It is also likely 302 that only a small set of VNI values will be provisioned per 303 switches. 305 o Reserved (8 bits): (see Rsv) 307 o Geneve Options Class - Type List: This fields specifies the Geneve 308 Options that MUST be present. The absence of one of these option 309 result in discarding the Geneve Header. When the presence or 310 absence of a specific Geneve Option has no impact for the GSP 311 selection, the value is set to OPAQUE as they may not be any 312 options. 314 Additional Selectors are considered within the Geneve Payload. The 315 Selectors provided below are expected to enable different GSP 316 according to the protection of the traffic. Typically, the Geneve 317 overlay network may protect differently traffic that is already 318 protected by the tenants with IPsec, DTLS/TLS, or SSH. 320 o Next Header (IPv6) / Protocol (IPv4) (8 bits): For IPv6 this field 321 indicates the presence of an IPv6 Option or the transport layer 322 used after the IPv6 Header. For IPv4 packets, the protocol 323 indicates the layer after the IPv4 Header. This field is 324 typically used to indicate whether IPsec/AH (51), IPsec/ESP (50), 325 TCP (6) or UDP (17) is used. Next Header is a mandatory field and 326 is expected in any IP header. When the matching condition does 327 not consider the Next Header or Protocol number than ANY = [0, 328 ..., 65535] is expected. When non IP packet are expected, OPAQUE 329 is expected. 331 o Port Source is typically used to determine how the tenants traffic 332 is being protected by TLS or DTLS. Ports associated to TLS are 333 expected to be 443 https, 636 ldaps, 989 ftps-data, 990 ftps, 992 334 telnets, 993 imaps, 994 ircs, 995 pop3s, 5061 sips, 22 ssh/scp. 336 Note that not all transport are associated with a port number. 337 When only transport layers with port numbers are expected to be 338 used (such as TCP or UDP) and the matching condition does not 339 consider the port numbers, ANY = [0, ..., 65535] is expected. 340 When traffic may not have port numbers - such as ICMP traffic, 341 OPAQUE is expected. 343 o Port Destination: (see Port Source) 345 5.2. Geneve Security Policies 347 Geneve Security Policies are unidirectional. A GSP is composed of: 349 o Selectors that express a matching condition 351 o Action that defines if the Geneve Packet MUST be DISCARDed, 352 BYPASSed or SECUREd. When the associated action is SECURE, then 353 the GSP associates an ordered list of GSA. The GSA contains the 354 description and the necessary material to perform the SECURE 355 action. 357 The GSP DB is an ordered list of GSP. 359 5.3. Geneve Security Policies Example 361 According to [I-D.ietf-nvo3-geneve], the associated Geneve Version is 362 0, a sender MUST set Rsv and Reserved to zero. When the sender only 363 supports [I-D.ietf-nvo3-geneve], it may performed a sanity check for 364 its outbound packets. The rules can be places at the beginning of 365 the GSP DB. 367 Selector | Value | Action 368 ------------------------------------------------------- 369 Geneve Version | [1 ... 4] (non-zero) | 370 OAM | [0,1] (ANY) | 371 Critical | [0,1] (ANY) | 372 Rsv | [0, ... ,63] (ANY) | DISCARD 373 Protocol | [0, ..., 65535] (ANY) | 374 VNI | [0, ..., 16777215] (ANY) | 375 Reserved | [0, ..., 255] (ANY) | 376 Geneve Options | OPAQUE | 377 Next Header | [0, ..., 255] (ANY) | 378 Port Source | OPAQUE | 379 Port Destination | OPAQUE | 380 ------------------------------------------------------- 381 Geneve Version | [0 ... 4] (ANY) | 382 OAM | [0,1] (ANY) | 383 Critical | [0,1] (ANY) | 384 Rsv | [1, ... ,63] (non-zero) | DISCARD 385 VNI | [0, ..., 65535] (ANY) | 386 Reserved | [0, ..., 15] (ANY) | 387 Geneve Options | OPAQUE | 388 Next Header | [0, ..., 255] (ANY) | 389 Port Source | OPAQUE | 390 Port Destination | OPAQUE | 391 ------------------------------------------------------- 392 Geneve Version | [0 ... 4] (ANY) | 393 OAM | [0,1] (ANY) | 394 Critical | [0,1] (ANY) | 395 Rsv | [1, ... ,63] (ANY) | DISCARD 396 VNI | [0, ..., 65535] (ANY) | 397 Reserved | [1, ..., 15] (non-zero) | 398 Geneve Options | OPAQUE | 399 Next Header | [0, ..., 255] (ANY) | 400 Port Source | OPAQUE | 401 Port Destination | OPAQUE | 402 ------------------------------------------------------- 404 Figure 2: Example 1: Geneve Security Policy for [I-D.ietf- 405 nvo3-geneve] compliance (sender) 407 By default a Geneve Security Madule may DISCARD any Geneve packet 408 that have no matching This is indicated by the following GSP at the 409 end of the GSP DB. 411 Selector | Value | Action 412 ------------------------------------------------------- 413 Geneve Version | [0 ... 4] (ANY) | 414 OAM | [0,1] (ANY) | 415 Critical | [0,1] (ANY) | 416 Rsv | [0, ... ,63] (ANY) | DISCARD 417 Protocol | [0, ..., 65535] (ANY) | 418 VNI | [0, ..., 16777215] (ANY) | 419 Reserved | [0, ..., 255] (ANY) | 420 Geneve Options | OPAQUE | 421 Next Header | [0, ..., 255] (ANY) | 422 Port Source | OPAQUE | 423 Port Destination | OPAQUE | 424 ------------------------------------------------------- 426 Figure 3: Example 2: Geneve Security Policy for [I-D.ietf- 427 nvo3-geneve] compliance (sender) 429 The example below details a GSP that proceeds to a specific treatment 430 to the traffic between tenant using ESP. The specific treatment 431 could typically only authenticate the Geneve Packet or partially 432 encrypt the Geneve Payload, in order to only hide the Inner headers - 433 including the ESP header - up to the ESP payload. 435 In the example, the GSP apply the same GSAs whatever the Geneve 436 Header informations are. More specifically, all virtualized network 437 share the same GSAs. 439 Selector | Value | Action 440 ------------------------------------------------------- 441 Geneve Version | [0 ... 4] (ANY) | 442 OAM | [0,1] (ANY) | 443 Critical | [0,1] (ANY) | 444 Rsv | [0, ... ,63] (ANY) | SECURE 445 Protocol | [0, ..., 65535] (ANY) | [GSA1, GSA2] 446 VNI | [0, ..., 16777215] (ANY) | 447 Reserved | [0, ..., 255] (ANY) | 448 Geneve Options | OPAQUE | 449 Next Header | [50] (ESP) | 450 Port Source | OPAQUE | 451 Port Destination | OPAQUE | 452 ------------------------------------------------------- 454 Figure 4: Example 3: Geneve Security Policy for ESP protect traffic 456 6. Geneve Security Association Database 458 GSA DB contains all GSAs. GSA are expected to contain all the 459 necessary information for the Geneve Security Module to compute the 460 GSO by both the sender and teh receiver. This includes for example 461 the cryptographic keys to encrypt ( resp. authenticate) as well as to 462 decrypt (resp. validate) the Geneve Packet. In addition, the GSA 463 also contains parameters associated to the protection of the security 464 option such as the anti-replay mechanisms as well as the management 465 of that options such as its lifetime. 467 For outbound traffic, the concerned GSA are provided by the GSP. In 468 this case, it is the purpose of the implementation of Geneve Security 469 Module to provide that appropriated reference. Most likely, the 470 appropriated GSAs will be designated using a memory address. 472 For inbound traffic, the concerned GSA is designated by the 473 associated GSO with a GSO-ID. In that case the appropriated GSA is 474 retrieved using this index. 476 6.1. Geneve Security Associations 478 A GSA contains the following information: 480 o GSO ID: The identifier of that GSA. This identifier is used by 481 receiver to bind the appropriated GSO to the appropriated GSA. 482 Note that when the packet is encrypted by the GSO, it may not be 483 possible to associate the GSA using GSP. 485 o GSO Protocol: The security protocol associated with the Geneve 486 Security Option. Currently the two GSO are GAO and GEO. 488 When the security option includes some encryption operation, the 489 following parameters are provided. Note that as recommended by 490 [I-D.ietf-ipsecme-rfc7321bis], encryption is authenticated 491 encryption. 493 o GSO Encryption Algorithm: In most cases, the encryption is 494 combined with an authentication performed with the same key. 496 o GSO Encryption Key: 498 When the security option includes a dedicated authentication 499 operation ( that is not part of the encryption), the following 500 parameters are provided: 502 o GSO Authentication Algorithm: 504 o GSO Authentication Key: 506 The following parameters indicate the coverage of the security 508 o GSO Payload Covered Length: the length of the Geneve Payload 509 covered by the GSO. The expression of the length can be a number 510 of bytes, but it may also be defined with an abstract designation. 511 For example, a sending node may be willing to authenticate the 512 Geneve Payload up to the ESP layer. In that case, the sending 513 node will have to compute the corresponding Payload Covered 514 Length. This value is only used by the sending node. The 515 receiving node read that value from the GAO. 517 o GSO Covered Geneve Options: Indicates the Geneve Options covered 518 by the GSO. This indication is primarily necessary for the 519 sending node and is derived from the Geneve Packet by the 520 receiving node. It might be checked by the receiving node to 521 validate the GSA. It might typically be expressed as a list of 522 Geneve Options that needs to be covered by the authentication. 524 In order to implement the anti replay mechanisms the following 525 parameters are provided: 527 o GSO Sequence Number Size: indicates the size of the SN. This 528 document considers a 32 bit or a 64 bit length. 530 o GSO Last Received Packet: that designates the Sequence Number last 531 sent or received packet. 533 o GSO Anti Replay Window: that indicates the minimum acceptable 534 value of the Sequence Number. Any Geneve Packet with a lower SN 535 MUST be rejected. Such SN value is usually derived from the Last 536 Received Packet - Anti Replay Windows. 538 In order to check the conformity with the GSP: 540 o GSO Selectors: The selectors are provided so the receiver can 541 check the Geneve Packet protected by the GSO is conform to the 542 GSP. In other words a valid GSO is not sufficient for the Geneve 543 Packet to be forwarded to the upper layers. Note that the 544 Selectors MUST match the Geneve Packet associated to the GSA 545 before the GSO is built for outbound Packets. For inbound Geneve 546 Packet the Selectors are those that corresponds to the Geneve 547 Packet after the GSO has been validated/decrytped. Selectors are 548 mostly expected to be used by the GSA for incoming Geneve Packet, 549 in order to check the GSA is conform with its GSP. 551 o GSA Life time: 553 7. Geneve Security Module Packet Processing 555 This section assumes that the GSA is valid. Unvalid GSA MUST be 556 deleted or considered as non existing by either the sender or the 557 receiver. 559 7.1. Outbound Geneve Processing 561 o The Geneve Security Module consults the GSP DB to determine the 562 GSP associated to the Geneve Packet. 564 * When a Geneve Packet is DISCARD, the Geneve Packet is dropped. 566 * When a Geneve Packet is BYPASS, the Geneve Packet is directly 567 forwarded to the lower layers for the outer encapsulation. 569 * When a Geneve Packet is SECURE, the GSP returns one or multiple 570 Geneve Security Association (GAS) of the Geneve Security 571 Association Database (GSA DB). GAS contains the necessary 572 material to compute the GSO for outbound Geneve Packet. When 573 multiple GAS are returned, GAS are applied in the order they 574 are provided. Each computed GSO carries a unique GSA-ID, so 575 the receiver can check the corresponding GSO without performing 576 a GSP DB lookup. 578 * When no matching is found, the Geneve Packet is DISCARDed 580 o Geneve Packet is forwarded to the lower layers for the Outer 581 Encapsulation. 583 7.2. Inbound Geneve Packet Processing 585 For inbound Geneve Packets: 587 o The Geneve Security Module checks the Geneve Packet is associated 588 to a DISCARD or a BYPASS GSP. 590 * If a match occurs the Geneve Packet is either DISCARDed or 591 BYPASSed to the Geneve layer. 593 * Otherwise the Geneve Packet is expected to be SECURED and 594 processed as such by the Geneve Security Module. 596 When the Geneve Packet is believed to be SECURed. 598 o The Geneve Security Module opens a security context which lists 599 the encountered and validated GSO as well as their respective 600 order. 602 o The Geneve Security Module inspects the Geneve Header for GSO in a 603 network order and proceeds as follows: 605 * The Geneve Security Module extracts the GSA-ID of the GSO. 607 * The Geneve Security Module performs a GSA DB lookup based on 608 the GSA-ID to retrieve the GSA associated to the Geneve Packet. 610 + If the GSA DB the GSO, the SO is skipped and the Geneve 611 Security Module continue wity the next GSO. In this case, 612 the GSO is treated as a unexpected geneve option. 614 * The Geneve Security Module validates the Geneve Security Option 615 against the GSA. If the validation does not succeeds, the 616 Geneve Packet is discarded. 618 * The Geneve security Module validates the Geneve Packet - once 619 the GSO process has been performed - is conformed with the GSP 620 by checking the resulting Geneve Packet matches the Selectors 621 provided in the GSA. 623 + If the validation is successful, the Geneve Security Module 624 associates the GSA-ID with a validated status in the 625 security context. For this reason it is important to match 626 the GSA Selector with the appropriated Selectors value. In 627 case multiple GSO are combined, the Selectors of the GSA MAY 628 differ from those used for the GSP DB matching. 630 + If a mismatch occurs the Geneve Packet is dropped. 632 When all Geneve Security Options have been validated, the Geneve 633 Packet is matched against the GSP DB to validate the GSA-ID listed in 634 the security context match those returned by the GSP DB. Note that 635 the receiver and the sender MUST have the same GSA-IDs, however, 636 computation and validation are processed in a different order. 638 8. IANA Considerations 640 There are no IANA consideration for this document. 642 9. Security Considerations 644 10. Acknowledgment 645 11. References 647 11.1. Normative References 649 [I-D.ietf-ipsecme-rfc7321bis] 650 Wouters, P., Migault, D., Mattsson, J., Nir, Y., and T. 651 Kivinen, "Cryptographic Algorithm Implementation 652 Requirements and Usage Guidance for Encapsulating Security 653 Payload (ESP) and Authentication Header (AH)", draft-ietf- 654 ipsecme-rfc7321bis-06 (work in progress), June 2017. 656 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 657 Requirement Levels", BCP 14, RFC 2119, 658 DOI 10.17487/RFC2119, March 1997, 659 . 661 11.2. Informational References 663 [I-D.ietf-nvo3-encap] 664 Boutros, S., Ganga, I., Garg, P., Manur, R., Mizrahi, T., 665 Mozes, D., and E. Nordmark, "NVO3 Encapsulation 666 Considerations", draft-ietf-nvo3-encap-00 (work in 667 progress), June 2017. 669 [I-D.ietf-nvo3-geneve] 670 Gross, J., Ganga, I., and T. Sridhar, "Geneve: Generic 671 Network Virtualization Encapsulation", draft-ietf- 672 nvo3-geneve-04 (work in progress), March 2017. 674 [I-D.mglt-nvo3-geneve-authentication-option] 675 Migault, D., "Geneve Authentication Option", July 2017, 676 . 679 [I-D.mglt-nvo3-geneve-encryption-option] 680 Migault, D., "Geneve Encryption Option", July 2017, 681 . 684 [I-D.mglt-nvo3-security-requirements] 685 Migault, D., "Geneve Security Requirements", July 2017, 686 . 689 Author's Address 691 Daniel Migault 693 Email: daniel.migault@ericsson.com