idnits 2.17.1 draft-mglt-nvo3-geneve-security-requirements-06.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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (February 28, 2019) is 1883 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) ** Obsolete normative reference: RFC 7525 (Obsoleted by RFC 9325) == Outdated reference: A later version (-16) exists of draft-ietf-nvo3-geneve-09 == Outdated reference: A later version (-43) exists of draft-ietf-tls-dtls13-30 Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NVO3 D. Migault 3 Internet-Draft Ericsson 4 Intended status: Informational S. Boutros 5 Expires: September 1, 2019 D. Wings 6 VMware, Inc. 7 S. Krishnan 8 Kaloom 9 February 28, 2019 11 Geneve Security Requirements 12 draft-mglt-nvo3-geneve-security-requirements-06 14 Abstract 16 The document defines the security requirements to protect tenants 17 overlay traffic against security threats from the NVO3 network 18 components that are interconnected with tunnels implemented using 19 Generic Network Virtualization Encapsulation (Geneve). 21 The document provides two sets of security requirements: 1. 22 requirements to evaluate the data plane security of a given 23 deployment of Geneve overlay. Such requirements are intended to 24 Geneve overlay provider to evaluate a given deployment. 25 2. requirement a security mechanism need to fulfill to secure any 26 deployment of Geneve overlay deployment 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on September 1, 2019. 45 Copyright Notice 47 Copyright (c) 2019 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (https://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3 63 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 64 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 65 4. Security Threats . . . . . . . . . . . . . . . . . . . . . . 6 66 4.1. Passive Attacks . . . . . . . . . . . . . . . . . . . . . 6 67 4.2. Active Attacks . . . . . . . . . . . . . . . . . . . . . 7 68 5. Requirements for Security Mitigations . . . . . . . . . . . . 8 69 5.1. Protection Against Traffic Sniffing . . . . . . . . . . . 8 70 5.1.1. Operational Security Requirements . . . . . . . . . . 9 71 5.1.2. Geneve Security Requirements . . . . . . . . . . . . 10 72 5.2. Protecting Against Traffic Injection . . . . . . . . . . 10 73 5.2.1. Operational Security Requirements . . . . . . . . . . 12 74 5.2.2. Geneve Security Requirements . . . . . . . . . . . . 13 75 5.3. Protecting Against Traffic Redirection . . . . . . . . . 13 76 5.4. Protecting Against Traffic Replay . . . . . . . . . . . . 14 77 5.4.1. Geneve Security Requirements . . . . . . . . . . . . 14 78 5.4.2. Geneve Security Requirements . . . . . . . . . . . . 15 79 5.5. Security Management . . . . . . . . . . . . . . . . . . . 15 80 5.5.1. Operational Security Requirements . . . . . . . . . . 15 81 5.5.2. Geneve Security Requirements . . . . . . . . . . . . 15 82 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 83 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 84 8. Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . 16 85 8.1. DTLS . . . . . . . . . . . . . . . . . . . . . . . . . . 16 86 8.1.1. Operational Security Requirements . . . . . . . . . . 16 87 8.1.2. Geneve Security Requirements . . . . . . . . . . . . 18 88 8.2. IPsec . . . . . . . . . . . . . . . . . . . . . . . . . . 20 89 8.2.1. Operational Security Requirements . . . . . . . . . . 20 90 8.2.2. Geneve Security Requirements . . . . . . . . . . . . 21 91 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 92 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 93 10.1. Normative References . . . . . . . . . . . . . . . . . . 23 94 10.2. Informative References . . . . . . . . . . . . . . . . . 25 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 97 1. Requirements Notation 99 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 100 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 101 "OPTIONAL" in this document are to be interpreted as described BCP 14 102 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, 103 as shown here. 105 2. Introduction 107 The network virtualization overlay over Layer 3 (NVO3) as depicted in 108 Figure 1, allows an overlay cloud provider to provide a logical L2/L3 109 interconnect for the Tenant Systems TSes that belong to a specific 110 tenant network. A packet received from a TS is encapsulated by the 111 ingress Network Virtualization Edge (NVE). The encapsulated packet 112 is then sent to the remote NVE through a tunnel. When reaching the 113 egress NVE of the tunnel, the packet is decapsulated and forwarded to 114 the target TS. The L2/L3 address mappings to the remote NVE(s) are 115 distributed to the NVEs by a logically centralized Network 116 Virtualization Authority (NVA) or using a distributed control plane 117 such as Ethernet-VPN. In a datacenter, the NVO3 tunnels can be 118 implemented using Generic Network Virtualization Encapsulation 119 (Geneve) [I-D.ietf-nvo3-geneve]. Such Geneve tunnels establish NVE- 120 to-NVE communications, may transit within the data center via Transit 121 device. The Geneve tunnels overlay network enable multiple Virtual 122 Networks to coexist over a shared underlay infrastructure, and a 123 Virtual Network may span a single data center or multiple data 124 centers. 126 The underlay infrastructure on which the multi-tenancy overlay 127 networks are hosted, can be owned and provided by an underlay 128 provider who may be different from the overlay cloud provider. 130 +--------+ +--------+ 131 | Tenant +--+ +----| Tenant | 132 | System | | (') | System | 133 +--------+ | ................. ( ) +--------+ 134 | +---+ +---+ (_) 135 +--|NVE|---+ +---|NVE|-----+ 136 +---+ | | +---+ 137 / . +-----+ . 138 / . +--| NVA | . 139 / . | +-----+ . 140 | . | . 141 | . | L3 Overlay +--+--++--------+ 142 +--------+ | . | Network | NVE || Tenant | 143 | Tenant +--+ . | | || System | 144 | System | . \ +---+ +--+--++--------+ 145 +--------+ .....|NVE|......... 146 +---+ 147 | 148 | 149 ===================== 150 | | 151 +--------+ +--------+ 152 | Tenant | | Tenant | 153 | System | | System | 154 +--------+ +--------+ 156 Figure 1: Generic Reference Model for Network Virtualization Overlays 157 [RFC7365] 159 This document discusses the security risks that a Geneve based NVO3 160 network may encounter. In addition, this document lists the 161 requirements to protect the Geneve packet components defined in 162 [I-D.ietf-nvo3-geneve] that include the Geneve tunnel IP and UDP 163 header, the Geneve Header, Geneve options, and inner payload. 165 The document provides two sets of security requirements: 167 1. SEC-OP: requirements to evaluate a given deployment of Geneve 168 overlay. Such requirements are intended to Geneve overlay 169 provider to evaluate a given deployment. Security of the Geneve 170 packet may be achieved using various mechanisms. Typically, some 171 deployments may use a limited subset of the capabilities provided 172 by Geneve and rely on specific assumptions. Given these 173 specificities, the secure deployment of a given Geneve deployment 174 may be achieved reusing specific mechanisms such as for example 175 DTLS [RFC6347] or IPsec [RFC4301]. On the other hand, the 176 definition of a security mechanisms that enables to secure any 177 Geneve deployment requires the design of a Geneve specific 178 mechanism. Note that the security s limited to the security of 179 the data plane only. Additional requirements for the control 180 plan MAY be considered in [I-D.ietf-nvo3-security-requirements]. 181 A given Geneve deployment will be considered secured when 182 matching with all SEC-OP requirements does not raises any 183 concern. As such the given deployment will be considered passing 184 SEC-OP requirements that are not applicable. 186 2. SEC-GEN: requirements a security mechanism need to fulfill to 187 secure any deployment of Geneve overlay deployment. Such 188 mechanism may require the design of a specific solution. In the 189 case new protocol needs to be design, the document strongly 190 recommend to re-use existing security protocols like IP Security 191 (IPsec) [RFC4301] and Datagram Transport Layer Security (DTLS) 192 [RFC6347], and existing encryption algorithms (such as 193 [RFC8221]), and authentication protocols. A given candidate for 194 a security mechanism will be considered as valid when matching 195 with all SEC-GEN requirements does not raise any concern. In 196 other words, at least all MUST status are met. 198 This document assumes the following roles are involved: - Tenant: 199 designates the entity that connects various systems within a single 200 virtualized network. The various system can typically be containers, 201 VMs implementing a single or various functions. 202 - Geneve Overlay Provider: provides the Geneve overlay that 203 seamlessly connect the various Tenant Systems over a given 204 virtualized network. 205 - Infrastructure Provider: provides the infrastructure that runs the 206 Geneve overlay network as well as the Tenant System. A given 207 deployment may consider different infrastructure provider with 208 different level of trust. Typically the Geneve overlay network may 209 use a public cloud to extend the resource of a private cloud. 210 Similarly, a edge computing may extend its resources using resource 211 of the core network. 213 Tenant, Geneve Overlay Provider and Infrastructure Provider can be 214 implemented by a single or various different entities with different 215 level of trust between each other. The simplest deployment may 216 consists in a single entity running its systems in its data center 217 and using Geneve in order to manage its internal resources. A more 218 complex use case may consider that a Tenant subscribe to the Geneve 219 Overlay Provider which manage the virtualized network over various 220 type of infrastructure. The trust between the Tenant, Geneve Overlay 221 Provider and Infrastructure Provider may be limited. 223 Given the different relations between Tenant, Geneve Overlay Provider 224 and Infrastructure Provider, this document aims providing 225 requirements to ensure: 1. The Geneve Overlay Provider delivers 226 tenant payload traffic (Geneve inner payload) and ensuring privacy 227 and integrity. 2. The Geneve Overlay Provider provides the 228 necessary means to prevent injection or redirection of the Tenant 229 traffic from a rogue node in the Geneve overlay network or a rogue 230 node from the infrastructure. 3. The Geneve Overlay Provider can 231 rely on the Geneve overlay in term of robustness and reliability of 232 the signaling associated to the Geneve packets (Geneve tunnel header, 233 Geneve header and Geneve options) in order to appropriately manage 234 its overlay. 236 3. Terminology 238 This document uses the terminology of [RFC8014], [RFC7365] and 239 [I-D.ietf-nvo3-geneve]. 241 4. Security Threats 243 This section considers attacks performed by NVE, network devices or 244 any other devices using Geneve, that is when the attackers knowing 245 the details of the Geneve packets can perform their attacks by 246 changing fields in the Geneve tunnel header, base header, Geneve 247 options and Geneve inner payload. Attacks related to the control 248 plane are outside the scope of this document. The reader is 249 encouraged to read [I-D.ietf-nvo3-security-requirements] for a 250 similar threat analysis of NVO3 overlay networks. 252 Threats include traffic analysis, sniffing, injection, redirection, 253 and replay. Based on these threats, this document enumerates the 254 security requirements. 256 Threats are divided into two categories: passive attack and active 257 attack. 259 Threats are always associated with risks and the evaluation of these 260 risks depend among other things on the environment. 262 4.1. Passive Attacks 264 Passive attacks include traffic analysis (noticing which workloads 265 are communicating with which other workloads, how much traffic, and 266 when those communications occur) and sniffing (examining traffic for 267 useful information such as personally-identifyable information or 268 protocol information (e.g., TLS certificate, overlay routing 269 protocols). 271 Passive attacks may also consist in inferring information about a 272 virtualized network or some Tenant System from observing the Geneve 273 traffic. This could also involve the correlation between observed 274 traffic and additional information. For example, a passive network 275 observer can determine two virtual machines are communicating by 276 manipulating activity or network activity of other virtual machines 277 on that same host. For example, the attacker could control (or be 278 otherwise aware of) network activity of the other VMs running on the 279 same host, and deduce other network activity is due to a victim VM. 281 A rogue element of the overlay Geneve network under the control of an 282 attacker may leak and redirect the traffic from a virtual network to 283 the attacker for passive monitoring [RFC7258]. 285 Avoiding leaking information is hard to enforced. The security 286 requirements provided in section {{sniffing} expect to mitigate such 287 attacks by lowering the consequences, typically making leaked data 288 unusable to an attacker. 290 4.2. Active Attacks 292 Active attacks involve modifying Geneve packets, injecting Geneve 293 packets, or interfering with Geneve packet delivery (such as by 294 corrupting packet checksum). Active attack may target the Tenant 295 System or the Geneve overlay. 297 There are multiple motivations to inject illegitimate traffic into a 298 tenants network. When the rogue element is on the path of the TS 299 traffic, it may be able to inject and receive the corresponding 300 messages back. On the other hand, if the attacker is not on the path 301 of the TS traffic it may be limited to only inject traffic to a TS 302 without receiving any response back. When rogue element have access 303 to the traffic in both directions, the possibilities are only limited 304 by the capabilities of the other on path elements - Transit device, 305 NVE or TS - to detect and protect against the illegitimate traffic. 306 On the other hand, when the rogue element is not on path, the surface 307 for such attacks remains still quite large. For example, an attacker 308 may target a specific TS or application by crafting a specific packet 309 that can either generate load on the system or crash the system or 310 application. TCP syn flood typically overload the TS while not 311 requiring the ability to receive responses. Note that udp 312 application are privileged target as they do not require the 313 establishment of a session and are expected to treat any incoming 314 packets. 316 Traffic injection may also be used to flood the virtual network to 317 disrupt the communications between the TS or to introduce additional 318 cost for the tenant, for example when pricing considers the traffic 319 inside the virtual network. The two latest attacks may also take 320 advantage of applications with a large factor of amplification for 321 their responses as well as applications that upon receiving a packet 322 interact with multiple TS. Similarly, applications running on top of 323 UDP are privileged targets. 325 Note also that an attacker that is not able to receive the response 326 traffic, may use other channels to evaluate or measure the impact of 327 the attack. Typically, in the case of a service, the attacker may 328 have access, for example, to a user interface that provides 329 indication on the level of disruption and the success of an attack, 330 Such feed backs may also be used by the attacker to discover or scan 331 the network. 333 Preventing traffic to cross virtual networks, reduce the surface of 334 attack, but rogue element main still perform attacks within a given 335 virtual network by replaying a legitimate packet. Some variant of 336 such attack also includes modification of unprotected parts when 337 available in order for example to increase the payload size. 339 5. Requirements for Security Mitigations 341 The document assumes that Security protocols, algorithms, and 342 implementations provide the security properties for which they are 343 designed, an attack caused by a weakness in a cryptographic algorithm 344 is out of scope. The algorithm used MUST follow the cryptographic 345 guidance such as [RFC8247], [RFC8221] or [RFC7525]. In this context, 346 when the document mentions encryption, it assumes authenticated 347 encryption. 349 Protecting network connecting TSes and NVEs which could be accessible 350 to outside attackers is out of scope. 352 An attacker controlling an underlying network device may break the 353 communication of the overlays by discarding or delaying the delivery 354 of the packets passing through it. The security consideration to 355 prevent this type of attack is out of scope of this document. 357 Securing communication between NVAs and NVEs is out of scope. 359 Selectively providing integrity / authentication, confidentiality / 360 encryption of only portions of the Geneve packet is in scope. This 361 will be the case if the Tenant Systems uses security protocol to 362 protect its communications. 364 5.1. Protection Against Traffic Sniffing 366 The inner payload, unless protection is provided by the Tenant System 367 reveals the content of the communication. This may be mitigate by 368 the Tenant using application level security such as, for example JSON 369 Web Encryption [RFC7516] or transport layer security such as DTLS 371 [RFC6347] or TLS [RFC8446] or IPsec/ESP [RFC4303]. However none of 372 these security protocols are sufficient to protect the entire inner 373 payload. IPsec/ESP still leave in clear the optional L2 layer 374 information as well as the IP addresses and some IP options. In 375 addition to these pieces of information, the use of TLS or DTLS 376 reveals the transport layer protocol as well as ports. As a result, 377 the confidentiality protection of the inner packet may be handled 378 either entirely by the Geneve Overlay Provider, or partially by the 379 Tenant or handled by both the Tenant and the Geneve Overlay Provider. 381 The Geneve Header contains information related to the Geneve 382 communications or metadata designated as Geneve Information. Geneve 383 Information is carried on the Geneve Outer Header, the Geneve Header 384 (excluding Geneve Options) as well as in the Geneve Options. Geneve 385 Information needs to be accessed solely by a NVE or transit device 386 while other Geneve Information may need to be accessed by other 387 transit devices. More specifically, a subset of the information 388 contained in the Geneve Header (excluding Geneve Options) as well as 389 a subset of (none, one or multiple Geneve Option) may be accessed by 390 a transit device or the NVE while the others needs to be accessed by 391 other transit devices. The confidentiality protection of the Geneve 392 Information is handled by the Geneve Overlay Provider. 394 In addition to Geneve Information, the traffic generated for the 395 Geneve overlay may be exposed to traffic volumetry and pattern 396 analysis within a virtualized network. Confidentiality protection 397 against traffic pattern recognition is handled by the Geneve Overlay 398 Provider. 400 5.1.1. Operational Security Requirements 402 A secure deployment of a Geneve overlay must fulfill the requirement 403 below: 405 o SEC-OP-1: A secure deployment of a Geneve overlay SHOULD by 406 default encrypt the inner payload. A Geneve overlay provider MAY 407 disable this capability for example when encryption is performed 408 by the Tenant System and that level of confidentiality is believed 409 to be sufficient. In order to provide additional protection to 410 traffic already encrypted by the Tenant the Geneve network 411 operator MAY partially encrypt the clear part of the inner 412 payload. 414 o SEC-OP-2: A secure deployment of a Geneve overlay MUST evaluate 415 the information associated to the leakage of Geneve Information 416 carried by the Geneve Packet. When a risk analysis concludes that 417 the risk of leaking sensitive information is too high, such Geneve 418 Information MUST NOT be transmit in clear text. 420 o SEC-OP-3: A secure deployment of a Geneve overlay MUST evaluate 421 the risk associated to traffic pattern recognition. When a risk 422 has been identified, traffic pattern recognition MUST be addressed 423 with padding policies as well as generation of dummy packets. 425 5.1.2. Geneve Security Requirements 427 A Geneve security mechanism must fulfill the requirements below: 429 o SEC-GEN-1: Geneve security mechanism MUST provide the capability 430 to encrypt the inner payload. 432 o SEC-GEN-2: Geneve security mechanism SHOULD provide the capability 433 to partially encrypt the inner payload header. 435 o SEC-GEN-3: Geneve security mechanism MUST provide means to encrypt 436 a single or a set of zero, one or multiple Geneve Options while 437 leave other Geneve Options in clear. Reversely, a Geneve security 438 mechanism MUST be able to leave a Geneve option in clear, while 439 encrypting the others. 441 o SEC-GEN-4: Geneve security mechanism MUST provide means to encrypt 442 the information of Geneve Header (excluding Geneve Options). 443 Reversely, a Geneve security mechanism MUST be able to leave in 444 clear Geneve Header information (Geneve Options excluded) while 445 encrypting the other. 447 o SEC-GEN-5: Geneve security mechanisms MUST provide the ability to 448 provide confidentiality protection between multiple nodes, i.e. 449 multiple transit devices and a NVE. 451 o SEC-GEN-6: Geneve security mechanism MUST provide the ability to 452 pad a Geneve packet. 454 o SEC-GEN-7: Geneve security mechanism MUST provide the ability to 455 send dummy packets. 457 5.2. Protecting Against Traffic Injection 459 Traffic injection from a rogue non legitimate NVO3 Geneve overlay 460 device or a rogue underlay transit device can target an NVE, a 461 transit underlay device or a Tenant System. Targeting a Tenant's 462 System requires a valid MAC and IP addresses of the Tenant's System. 464 When traffic between tenants is not protected, the rogue device may 465 forward the modified packet over a valid (authenticated) Geneve 466 Header. The crafted packet may for example, include a specifically 467 crafted application payload for a specific Tenant Systems 468 application, with the intention to load the tenant specific 469 application. Tenant's System may provide integrity protection of the 470 inner payload by protect their communications using for example 471 IPsec/ESP, IPsec/AH [RFC4302], TLS or DTLS. Such protection protects 472 at various layers the Tenants from receiving spoofed packets, as any 473 injected packet is expected to be discarded by the destination 474 Tenant's System. Note IPsec/ESP with NULL encryption may be used to 475 authenticate-only the layers above IP in which case the IP header 476 remains unprotected. However IPsec/AH enables the protection of the 477 entire IP packet, including the IP header. As a result, when Geneve 478 encapsulates IP packets the Tenant has the ability to integrity 479 protect the IP packet on its own, without relying on the Geneve 480 overlay network. On the other hand, L2 layers remains unprotected. 481 As encryption is using authenticated encryption, authentication may 482 also be provided via encryption. At the time of writing the document 483 DTLS 1.3 [I-D.ietf-tls-dtls13] is still a draft document and TLS 1.3 484 does not yet provide the ability for authenticate only the traffic. 485 As such it is likely that the use of DTLS1.3 may not involve 486 authentication-only cipher suites. Similarly to confidentiality 487 protection, integrity protection may be handled either entirely by 488 the Geneve Overlay Provider, or partially by the Tenant or handled by 489 both the Tenant and the Geneve Overlay Provider. 491 In addition to confidentiality protection of the inner payload, 492 integrity protection also prevents the Tenant System from receiving 493 illegitimate packets that may disrupt the Tenant's System 494 performance. The Geneve overlay network need to prevent the overlay 495 to be used as a vector to spoof packets being steered to the Tenant's 496 system. As a result, the Overlay Network Provider needs to ensure 497 that inner packets steered to the Tenant's network are only 498 originating from one Tenant System and not from an outsider using the 499 Geneve Overlay to inject packets to one virtual network. As such, 500 the destination NVE MUST be able to authenticate the incoming Geneve 501 packets from the source NVE. This may be performed by the NVE 502 authenticating the full Geneve Packet. When the Geneve Overlay wants 503 to take advantage of the authentication performed by the Tenant 504 System, the NVE shoudl be able to perform some checks between the 505 Geneve Header and the inner payload. Suppose two Geneve packets are 506 composed of a Geneve Header (H1, and H2) and a inner payload (P1 and 507 P2). Suppose H1, H2, P1 and P2 are authenticated. The replacement 508 of P2 by P1 by an attacker will be detected by the NVE only if there 509 is a binding between H2 and P2. Such integrity protection is handled 510 by the Geneve Overlay Provider. 512 While traffic injection may target the Tenant's virtual network or a 513 specific Tenant System, traffic injection may also target the Geneve 514 Overlay Network by injecting Geneve Options that will affect the 515 processing of the Geneve Packet. Updating the Geneve header and 516 option parameters such as setting an OAM bit, adding bogus option 517 TLVs, or setting a critical bit, may result in different processing 518 behavior, that could greatly impact performance of the overlay 519 network and the underlay infrastructure and thus affect the tenants 520 traffic delivery. As such, the Geneve Overlay should provide 521 integrity protection of the Geneve Information present in the Geneve 522 Header to guarantee Geneve processing is not altered. 524 The Geneve architecture considers transit devices that may process 525 some Geneve Options. More specifically, a Geneve packet may have A 526 subset of Geneve Information of the Geneve Header (excluding Geneve 527 Options) as well as a set of zero, one or multiple of Geneve Options 528 accessed by one or more transit devices. This information needs to 529 be authenticated by a transit device while other options may be 530 authenticated by other transit devices or the tunnel endpoint. The 531 integrity protection is handled by the Geneve Overlay Provider and 532 authentication MUST be performed prior any processing. 534 5.2.1. Operational Security Requirements 536 A secure deployment of a Geneve overlay must fulfill the requirement 537 below: 539 o SEC-OP-4: A secure deployment of a Geneve overlay MUST provide the 540 capability authenticate the inner payload when encryption is not 541 provided. A Geneve overlay provider MAY disable this capability 542 for example when this is performed by the Tenant System and that 543 level of integrity is believed to be sufficient. In order to 544 provide additional protection to traffic already protected by the 545 Tenant the Geneve network operator MAY partially protect the 546 unprotected part of the inner payload. 548 o SEC-OP-5: A secure deployment of a Geneve overlay MUST evaluate 549 the risk associated to a change of the Geneve Outer Header, Geneve 550 Header (excluding Geneve Options) and Geneve Option. When a risk 551 analysis concludes that the risk is too high, this piece of 552 information MUST be authenticated. 554 o SEC-OP-6: A secure deployment of a Geneve overlay SHOULD 555 authenticate communications between NVE to protect the Geneve 556 Overlay infrastructure as well as the Tenants System's 557 communications (Geneve Packet). A Geneve overlay provider MAY 558 disable authentication of the inner packet and delegates it to the 559 Tenant Systems when communications between Tenant's System is 560 secured. This is NOT RECOMMENDED. Instead, it is RECOMMENDED 561 that mechanisms binds the inner payload to the Geneve Header. To 562 prevent injection between virtualized network, it is strongly 563 RECOMMENDED that at least the Geneve Header without Geneve Options 564 is authenticated. 566 o SEC-OP-7: A secure deployment of a Geneve overlay SHOULD NOT 567 process data prior authentication. If that is not possible, the 568 Geneve overlay provider SHOULD evaluate its impact. 570 5.2.2. Geneve Security Requirements 572 A Geneve security mechanism must fulfill the requirements below: 574 o SEC-GEN-8: Geneve security mechanism MUST provide the capability 575 to authenticate the inner payload. 577 o SEC-GEN-9: Geneve security mechanism SHOULD provide the capability 578 to partially authenticate the inner payload header. 580 o SEC-GEN-10: Geneve security mechanism MUST provide the capability 581 to authenticate a single or a set of options while leave other 582 Geneve Option unauthenticated. Reversely, a Geneve security 583 mechanism MUST be able to leave a Geneve option unauthenticated, 584 while encrypting the others. 586 o SEC-GEN-11: Geneve security mechanism MUST provide means to 587 authenticate the information of Geneve Header (Geneve Option 588 excluded). Reversely, a Geneve security mechanism MUST be able to 589 leave unauthenticated Geneve header information (Geneve Options 590 excluded) while authenticating the other. 592 o SEC-GEN-12: Geneve Security mechanism MUST provide means for a 593 tunnel endpoint (NVE) to authenticate data prior it is being 594 processed. 596 o SEC-GEN-13: Geneve Security mechanism MUST provide means for a 597 transit device to authenticate data prior it is being processed. 599 5.3. Protecting Against Traffic Redirection 601 A rogue device of the NVO3 overlay Geneve network or the underlay 602 network may redirect the traffic from a virtual network to the 603 attacker for passive or active attacks. If the rogue device is in 604 charge of securing the Geneve packet, then Geneve security mechanisms 605 are not intended to address this threat. More specifically, a rogue 606 source NVE will still be able to redirect the traffic in clear text 607 before protecting ( and encrypting the packet). A rogue destination 608 NVE will still be able to redirect the traffic in clear text after 609 decrypting the Geneve packets. The same occurs with a rogue transit 610 that is in charge of encrypting and decrypting a Geneve Option, 611 Geneve Option or any information. The security mechanisms are 612 intended to protect a Geneve information from any on path node. Note 613 that modern cryptography recommend the use of authenticated 614 encryption. This section assumes such algorithms are used, and as 615 such encrypted packets are also authenticated. 617 To prevent an attacker located in the middle between the NVEs and 618 modifying the tunnel address information in the data packet header to 619 redirect the data traffic, the solution needs to provide 620 confidentiality protection for data traffic exchanged between NVEs. 622 Requirements are similar as those provided in section Section 5.1 to 623 mitigate sniffing attacks and those provided in section Section 5.2 624 to mitigate traffic injection attacks. 626 5.4. Protecting Against Traffic Replay 628 A rogue device of the NVO3 overlay Geneve network or the underlay 629 network may replay a Geneve packet, to load the network and/or a 630 specific Tenant System with a modified Geneve payload. In some 631 cases, such attacks may target an increase of the tenants costs. 633 When traffic between Tenant System is not protected against anti- 634 replay. A packet even authenticated can be replayed. DTLS and IPsec 635 provides anti replay mechanisms, so it is unlikely that authenticated 636 Tenant's traffic is subject to replay attacks. 638 Similarly to integrity protection, the Geneve Overlay Provider should 639 prevent the overlay to be used to replay packet to the Tenant's 640 System. In addition, similarly to integrity protection, the Geneve 641 Overlay network may also be a target of a replay attack, and NVE as 642 well as transit devices should benefit from the same protection. 644 Given the proximity between authentication and anti-replay mechanisms 645 and that most authentication mechanisms integrates anti-replay 646 attacks, we RECOMMEND that authentication contains an anti-replay 647 mechanisms. 649 5.4.1. Geneve Security Requirements 651 A secure deployment of a Geneve overlay must fulfill the requirement 652 below: 654 o SEC-OP-8: A secure deployment of a Geneve overlay MUST evaluate 655 the communications subject to replay attacks. Communications that 656 are subject to this attacks MUST be authenticated with an anti 657 replay mechanism. Note that when partial authentication is 658 provided, the part not covered by the authentication remains a 659 surface of attack. It is strongly RECOMMENDED that the Geneve 660 Header is authenticated with anti replay protection. 662 5.4.2. Geneve Security Requirements 664 A Geneve security mechanism must fulfill the requirements below: 666 o SEC-GEN-14: Geneve Security mechanism MUST provide authentication 667 with anti-replay protection. 669 5.5. Security Management 671 5.5.1. Operational Security Requirements 673 A secure deployment of a Geneve overlay must fulfill the requirement 674 below: 676 o SEC-OP-9: A secure deployment of a Geneve overlay MUST define the 677 security policies that associates the encryption, and 678 authentication associated to each flow between NVEs. 680 o SEC-OP-10: A secure deployment of a Geneve overlay SHOULD define 681 distinct material for each flow. The cryptographic depends on the 682 nature of the flow (multicast, unicast) as well as on the security 683 mechanism enabled to protect the flow. 685 5.5.2. Geneve Security Requirements 687 A Geneve security mechanism must fulfill the requirements below: 689 o SEC-GEN-15: A Geneve security mechanism MUST be managed via 690 security policies associated for each traffic flow to be 691 protected. Geneve overlay provider MUST be able to configure NVEs 692 with different security policies for different flows. A flow MUST 693 be identified at minimum by the Geneve virtual network identifier 694 and the inner IP and transport headers, and optionally additional 695 fields which define a flow (e.g., inner IP DSCP, IPv6 flow id, 696 Geneve options). 698 o SEC-GEN-16: A Geneve security mechanism MUST be able to assign 699 different cryptographic keys to protect the unicast tunnels 700 between NVEs respectively. 702 o SEC-GEN-17: A Geneve security mechanisms, when multicast is used, 703 packets,MUST be able to assign distinct cryptographic group keys 704 to protect the multicast packets exchanged among the NVEs within 705 different multicast groups. Upon receiving a data packet, an 706 egress Geneve NVE MUST be able to verify whether the packet is 707 sent from a proper ingress NVE which is authorized to forward that 708 packet. 710 6. IANA Considerations 712 There are no IANA consideration for this document. 714 7. Security Considerations 716 The whole document is about security. 718 Limiting the coverage of the authentication / encryption provides 719 some means for an attack to craft special packets. 721 The current document details security requirements that are related 722 to the Geneve protocol. Instead, 723 [I-D.ietf-nvo3-security-requirements] provides generic architecture 724 security requirement upon the deployment of an NVO3 overlay network. 725 It is strongly recommended to read that document as architecture 726 requirements also apply here. In addition, architecture security 727 requirements go beyond the scope of Geneve communications, and as 728 such are more likely to address the security needs upon deploying an 729 Geneve overlay network. 731 8. Appendix 733 8.1. DTLS 735 This section compares how NVE communications using DTLS meet the 736 security requirements for a secure Geneve overlay deployment. In 737 this example DTLS is used over the Geneve Outer Header and secures 738 the Geneve Header including the Geneve Options and the inner payload. 740 The use of DTLS MAY fill the security requirements for a secure 741 Geneve deployment. However DTLS cannot be considered as the Geneve 742 security mechanism enabling all Geneve deployments. To ease the 743 reading of the Requirements met by DTLS or IPsec, the requirements 744 list indicates with Y (Yes) when the requirement and N (No) when the 745 requirement is not met. In addition, an explanation is provided on 746 the reasoning. This section is not normative and its purpose is 747 limited to illustrative purpose. 749 8.1.1. Operational Security Requirements 751 This section shows how DTLS may secure some Geneve deployments. Some 752 Geneve deployments may not be secured by DTLS, but that does not 753 exclude DTLS from being used. 755 o SEC-OP-1 (Y): A deployment using DTLS between NVEs with an non 756 NULL encryption cipher suite will provide confidentiality to the 757 full Geneve Packet which contains the inner payload. As such the 758 use of DTLS meets SEC-OP-1. Note that DTLS does not provide 759 partial encryption and as such the Geneve Overlay Provider may not 760 benefit from the encryption performed by the Tenant if performed, 761 which may result in some portion of the payload being encrypted 762 twice. 764 o SEC-OP-2 (Y): A deployment using DTLS between NVEs with an non 765 NULL encryption cipher suite encrypt the Geneve Packet which 766 includes the Geneve Header and associated metadata. Only the UDP 767 port is leaked which could be acceptable. As such, the use of 768 DTLS meets SEC-OP-2. 770 o SEC-OP-3 (Y/N): A deployment using DTLS between NVEs will not be 771 able to send dummy packets or pad Geneve Packet unless this is 772 managed by the Geneve packet itself. DTLS does not provide the 773 ability to send dummy traffic, nor to pad. As a result DTLS 774 itself does not meet this requirement. This requirement may be 775 met if handled by the Geneve protocol. As such SEC-OP-3 may not 776 be met for some the deployment. However, it is not a mandatory 777 requirement and as such it is likely that the use of DTLS SEC-OP-3 778 is met. 780 o SEC-OP-4 (Y): Similarly to SEC-OP-1, A deployment using DTLS 781 between NVEs provides integrity protection to the full Geneve 782 Packet which includes the inner payload. As such the use of DTLS 783 meets SEC-OP-4. Note that DTLS 1.2 provides integrity-only cipher 784 suites while DTLS 1.3 does not yet. As a result, the use of DTLS 785 1.3 may provide integrity protection using authenticated 786 encryption. 788 o SEC-OP-5 (Y): Similarly to SEC-OP-2, A deployment using DTLS 789 between NVE authenticates the full Geneve Packet which includes 790 the Geneve Header. Only the UDP port is left unauthenticated. As 791 such, the use of DTLS meets SEC-OP-5. 793 o SEC-OP-6 (Y): A deployment using DTLS between NVE authenticates 794 NVE-to-NVE communications and the use of DTLS meets SEC-OP-6. 796 o SEC-OP-7 (Y/N): A deployment using DTLS between NVEs is not 797 compatible with a Geneve architecture that includes transit 798 devices. When the DTLS session uses a non NULL encryption cipher 799 suite, the transit device will not be able to access it. When the 800 NULL encryption cipher suite is used, the transit device may be 801 able to access the data, but will not be able to authenticate it 802 prior to processing the packet. As such the use of DTLS only 803 meets SEC-OP-7 for deployment that do not include any transit 804 devices. 806 o SEC-OP-8 (Y): A deployment using DTLS between NVEs provides anti- 807 replay protection and so, the use of DTLS meets SEC-OP-8. 809 o SEC-OP-9 (Y/N): DTLS does not define any policies. Instead DTLS 810 process is bound to an UDP socket. As such handling of flow 811 policies is handled outside the scope of DTLS. As such SEC-OP-9 812 is met outside the scope of DTLS. 814 o SEC-OP-10 (N): DTLS session may be established with specific 815 material, as such it is possible to assign different material for 816 each flow. However, the binding between flow and session is 817 performed outside the scope of DTLS. In addition, DTLS does not 818 support multicast. As such, the use of DTLS may only meets SEC- 819 OP-10 in the case of unicast communications. 821 8.1.2. Geneve Security Requirements 823 This section shows that DTLS cannot be used as a generic Geneve 824 security mechanism to secure Geneve deployments. A Geneve security 825 mechanism woudl need to meet all SEC-GEN requirements. 827 o SEC-GEN-1 (Y): A deployment using DTLS between NVEs with an non 828 NULL encryption cipher suite will provide confidentiality to the 829 full Geneve Packet which contains the inner payload. As such the 830 use of DTLS meets SEC-GEN-1. 832 o SEC-GEN-2 (Y): A deployment using DTLS between NVEs with an non 833 NULL encryption cipher suite will not be able to partially encrypt 834 the inner payload header. However such requirement is not set a 835 mandatory so the use of DTLS meets SEC-GEN-2 837 o SEC-GEN-3 (N): A deployment using DTLS between NVEs with an non 838 NULL encryption cipher suite encrypt the Geneve Packet which 839 includes the Geneve Header and all Geneve Options. However DTLS 840 does not provides any means to selectively encrypt or leave in 841 clear text a subset of Geneve Options. As a result the use of 842 DTLS does not meet SEC-GEN-3. 844 o SEC-GEN-4 (N): A deployment using DTLS between NVEs with an non 845 NULL encryption cipher suite encrypt the Geneve Packet which 846 includes the Geneve Header and all Geneve Options. However, DTLS 847 does not provides means to selectively encrypt some information of 848 the Geneve Header. As such the use of DTLS does not meet SEC-GEN- 849 5. 851 o SEC-GEN-5 (N): A deployment using DTLS between NVEs with an non 852 NULL encryption cipher suite provides end-to-end security between 853 the NVEs and as such does not permit the interaction of one or 854 multiple on-path transit devices. As such the use of DTLS does 855 not meet SEC-GEN-5. 857 o SEC-GEN-6 (N): A deployment using DTLS between NVEs with an non 858 NULL encryption cipher suite does not provide padding facilities. 859 This requirements is not met by DTLS itself and needs to be 860 handled by Geneve and specific options. As a result, the use of 861 DTLS does not meet SEC-GEN-6 863 o SEC-GEN-7 (N): A deployment using DTLS between NVEs with an non 864 NULL encryption cipher suite does not provide the ability to send 865 dummy packets. This requirements is not met by DTLS itself and 866 needs to be handled by Geneve and specific options. As a result, 867 the use of DTLS does not meet SEC-GEN-7. 869 o SEC-GEN-8 (Y): A deployment using DTLS between NVEs with an non 870 NULL encryption cipher suite or a NULL encryption cipher suite 871 provide authentication of the inner payload. As such the use of 872 DTLS meets SEC-GEN-8. 874 o SEC-GEN-9 (Y): A deployment using DTLS between NVEs does not 875 provide the ability to partially authenticate the inner payload 876 header. However such requirement is not set a mandatory so the 877 use of DTLS meets SEC-GEN-9 879 o SEC-GEN-10 (N): A deployment using DTLS between NVEs authenticates 880 the Geneve Packet which includes the Geneve Header and all Geneve 881 Options. However, DTLS does not provides means to selectively 882 encrypt some information of the Geneve Header. As such the use of 883 DTLS meets SEC-GEN-10. 885 o SEC-GEN-11 (N): A deployment using DTLS between NVEs authenticates 886 the Geneve Packet which includes the Geneve Header and all Geneve 887 Options. However, DTLS does not provides means to selectively 888 authenticate some information of the Geneve Header. As such the 889 use of DTLS does not meet SEC-GEN-11. 891 o SEC-GEN-12 (Y): A deployment using DTLS between NVEs authenticates 892 the data prior the data is processed by the NVE. As such, the use 893 of DTLS meets SEC-GEN-12. 895 o SEC-GEN-13 (N): A deployment using DTLS between NVEs authenticates 896 the data when the tunnel reaches the NVE. As a result the transit 897 device is not able to authenticate the data prior accessing it and 898 the use of DTLS does not meet SEC-GEN-13. 900 o SEC-GEN-14 (Y): DTLS provides anti-replay mechanism as such, the 901 use of DTLS meets SEC-GEN-14. 903 o SEC-GEN-15 (N): DTLS itself does not have a policy base mechanism. 904 As a result, the classification of the flows needs to be handled 905 by a module outside DTLS. In order to meet SEC-GEN-15 further 906 integration is needed and DTLS in itself cannot be considered as 907 meeting SEC-GEN-15. 909 o SEC-GEN-16 (Y): DTLS is able to assign various material to each 910 flows, as such the use of DTLS meets SEC-GEN-16. 912 o SEC-GEN-17 (N): DTLS does not handle mutlicast communications. As 913 such the use of DTLS does not meet SEC-GEN-17. 915 8.2. IPsec 917 This section compares how NVE communications using IPsec/ESP or 918 IPsec/AH meet the security requirements for a secure Geneve overlay 919 deployment. In this example secures the Geneve IP packet including 920 Outer IP header, the Geneve Outer Header, the Geneve Header including 921 Geneve Options and the inner payload. 923 The use of IPsec/ESP or IPsec/AH share most of the analysis performed 924 for DTLS. The main advantages of using IPsec would be that IPsec 925 supports multicast communications and natively supports flow based 926 security policies. However, the use of these security policies in a 927 context of Geneve is not natively supported. 929 As a result, the use of IPsec MAY fill the security requirements for 930 a secure Geneve deployment. However IPsec cannot be considered as 931 the Geneve security mechanism enabling all Geneve deployments. 933 8.2.1. Operational Security Requirements 935 This section shows how IPsec may secure some Geneve deployments. 936 Some Geneve deployments may not be secured by IPsec, but that does 937 not exclude IPsec from being used. 939 o SEC-OP-1 (Y): A deployment using IPsec/ESP between NVEs with an 940 non NULL encryption will provide confidentiality to the full Outer 941 IP payload of the Geneve Packet which contains the inner payload. 942 As a result, such deployments meet SEC-OP-1. Note that IPsec/ESP 943 does not provide partial encryption and as such the Geneve Overlay 944 Provider may not benefit from the encryption performed by the 945 Tenant if performed, which may result in some portion of the 946 payload being encrypted twice. 948 o SEC-OP-2 (Y): A deployment using IPsec/ESP between NVEs with an 949 non NULL encryption encrypts the Outer IP payload Geneve IP Packet 950 which includes the Geneve Header and associated information. As 951 such SEC-OP-2 is met. 953 o SEC-OP-3 (Y): A deployment using IPsec/ESP between NVEs will be 954 able to send dummy packets or pad Geneve Packet. As such OP-SEC-3 955 is met. 957 o SEC-OP-4 (Y): Similarly to SEC-OP-1, A deployment using IPsec/ESP 958 or IPsec/AH between NVEs provides integrity protection to the full 959 Geneve Packet which includes the inner payload. As such SEC-OP-4 960 is met. 962 o SEC-OP-5 (Y): Similarly to SEC-OP-2, A deployment using IPsec/ESP 963 or IPsec/AH between NVE authenticates the full Geneve Packet which 964 includes the Geneve Header. As such SEC-OP-5 is met as well. 966 o SEC-OP-6 (Y): A deployment using IPsec/ESP or IPsec/AH between NVE 967 authenticates NVE-to-NVE communications and SEC-OP-6 is met. 969 o SEC-OP-7 (Y/N): A deployment using IPsec between NVEs is not 970 compatible with a Geneve architecture that includes transit 971 devices. When IPsec/ESP with a non NULL encryption is used, the 972 transit device will not be able to access it. When IPsec/AH or 973 IPsec/ESP with the NULL encryption is used, the transit device may 974 be able to access the data, but will not be able to authenticate 975 it prior to processing the packet. As SEC-OP-7 is only met for 976 deployment that do not include any transit devices. 978 o SEC-OP-8 (Y): A deployment using IPsec between NVEs provides anti- 979 replay protection and so meets SEC-OP-8. 981 o SEC-OP-9 (Y/N): IPsec enables the definition of security policies. 982 As such IPsec is likely to handle a per flow security. However 983 the traffic selector required for Geneve flows may not be provided 984 natively by IPsec. As such Sec-OP-9 is only partialy met. 986 o SEC-OP-10 (Y): IPsec session may be established with specific 987 material, as such it is possible to assign different material for 988 each flow. In addition IPsec supports multicats communications. 989 As such SEC-OP-10 is met. 991 8.2.2. Geneve Security Requirements 993 This section shows that IPsec cannot be used as a generic Geneve 994 security mechanism to secure Geneve deployments. A Geneve security 995 mechanism would need to meet all SEC-GEN requirements. 997 o SEC-GEN-1 (Y): A deployment using IPsec/ESP between NVEs with an 998 non NULL encryption provide confidentiality to the full Geneve 999 Packet which contains the inner payload. As such IPsec/ESP meets 1000 SEC-GEN-1. 1002 o SEC-GEN-2 (Y): A deployment using IPsec/ESP between NVEs with an 1003 non NULL encryption will not be able to partially encrypt the 1004 inner payload header. However such requirement is not set a 1005 mandatory so IPsec/ESP meets SEC-GEN-2 1007 o SEC-GEN-3 (N): A deployment using IPsec between NVEs with an non 1008 NULL encryption encrypts the Outer IP payload of the Geneve Packet 1009 which includes the Geneve Header and all Geneve Options. However 1010 IPsec/ESP does not provides any means to selectively encrypt or 1011 leave in clear text a subset of Geneve Options. As a result SEC- 1012 GEN-3 is not met. 1014 o SEC-GEN-4 (N): A deployment using IPsec/ESP between NVEs with an 1015 non NULL encryption encrypts the Geneve Packet which includes the 1016 Geneve Header and all Geneve Options. However, IPsec/ESP does not 1017 provides means to selectively encrypt some information of the 1018 Geneve Header. As such SEC-GEN-5 is not met. 1020 o SEC-GEN-5 (N): A deployment using IPsec between NVEs with an non 1021 NULL encryption provides end-to-end security between the NVEs and 1022 as such does not permit the interaction of one or multiple on-path 1023 transit devices. As such IPsec/ESP does not meet SEC-GEN-5. 1025 o SEC-GEN-6 (Y): A deployment using IPsec/ESP between NVEs with an 1026 non NULL encryption provides padding facilities and as such IPsec/ 1027 ESP meets SEC-GEN-6. 1029 o SEC-GEN-7 (Y): A deployment using IPsec between NVEs with an non 1030 NULL encryption cipher provides the ability to send dummy packets. 1031 As such IPsec/ESP meets SEC-GEN-7. 1033 o SEC-GEN-8 (Y): A deployment using IPsec/ESP or IPsec/AH 1034 authenticates the inner payload. As such SEC-GEN-8 is met. 1036 o SEC-GEN-9 (Y): A deployment using IPsec/AH or IPsec/ESP between 1037 NVEs does not provide the ability to partially authenticate the 1038 inner payload header. However such requirement is not set a 1039 mandatory so IPsec meets SEC-GEN-9 1041 o SEC-GEN-10 (N): A deployment using IPsec/ESP or IPsec/AH between 1042 NVEs authenticates the Geneve Packet which includes the Geneve 1043 Header and all Geneve Options. However, IPsec does not provides 1044 means to selectively encrypt some information of the Geneve 1045 Header. As such SEC-GEN-10 is not met. 1047 o SEC-GEN-11 (N): A deployment using IPsec/ESP or IPsec/AH between 1048 NVEs authenticates the Geneve Packet which includes the Geneve 1049 Header and all Geneve Options. However, IPsec does not provides 1050 means to selectively authenticate some information of the Geneve 1051 Header. As such SEC-GEN-11 is not met. 1053 o SEC-GEN-12 (Y): A deployment using IPsec/ESP or IPsec/AH between 1054 NVEs authenticates the data prior the data is processed by the 1055 NVE. As such SEC-GEN-12 is met. 1057 o SEC-GEN-13 (N): A deployment using IPsec/ESP or IPsec/AH between 1058 NVEs authenticates the data when the tunnel reaches the NVE. As a 1059 result the transit device is not able to authenticate the data 1060 prior accessing it and SEC-GEN-13 is not met. 1062 o SEC-GEN-14 (Y): IPsec/ESP and IPsec/AH provides anti-replay 1063 mechanism as such SEC-GEN-14 is met. 1065 o SEC-GEN-15 (N): IPsec is a policy base architecture. As a result, 1066 the classification of the flows needs to be handled by IPsec. 1067 However, the traffic selector available are probably not those 1068 required by Geneve and further integration is needed. As such 1069 SEC-GEN-15 is not met. 1071 o SEC-GEN-16 (Y): IPsec is able to assign various material to each 1072 flows, as such SEC-GEN-16 is met. 1074 o SEC-GEN-17 (Y): IPsec handles mutlicast communications. As such 1075 SEC-GEN-17 is met. 1077 9. Acknowledgments 1079 We would like to thank Ilango S Ganaga, Magnus Nystroem for their 1080 useful reviews and clarifications as well as Matthew Bocci, Sam 1081 Aldrin and Ignas Bagdona for moving the work forward. 1083 10. References 1085 10.1. Normative References 1087 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1088 Requirement Levels", BCP 14, RFC 2119, 1089 DOI 10.17487/RFC2119, March 1997, 1090 . 1092 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1093 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 1094 December 2005, . 1096 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 1097 DOI 10.17487/RFC4302, December 2005, 1098 . 1100 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 1101 RFC 4303, DOI 10.17487/RFC4303, December 2005, 1102 . 1104 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1105 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 1106 January 2012, . 1108 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 1109 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 1110 2014, . 1112 [RFC7365] Lasserre, M., Balus, F., Morin, T., Bitar, N., and Y. 1113 Rekhter, "Framework for Data Center (DC) Network 1114 Virtualization", RFC 7365, DOI 10.17487/RFC7365, October 1115 2014, . 1117 [RFC7516] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)", 1118 RFC 7516, DOI 10.17487/RFC7516, May 2015, 1119 . 1121 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 1122 "Recommendations for Secure Use of Transport Layer 1123 Security (TLS) and Datagram Transport Layer Security 1124 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 1125 2015, . 1127 [RFC8014] Black, D., Hudson, J., Kreeger, L., Lasserre, M., and T. 1128 Narten, "An Architecture for Data-Center Network 1129 Virtualization over Layer 3 (NVO3)", RFC 8014, 1130 DOI 10.17487/RFC8014, December 2016, 1131 . 1133 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1134 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1135 May 2017, . 1137 [RFC8221] Wouters, P., Migault, D., Mattsson, J., Nir, Y., and T. 1138 Kivinen, "Cryptographic Algorithm Implementation 1139 Requirements and Usage Guidance for Encapsulating Security 1140 Payload (ESP) and Authentication Header (AH)", RFC 8221, 1141 DOI 10.17487/RFC8221, October 2017, 1142 . 1144 [RFC8247] Nir, Y., Kivinen, T., Wouters, P., and D. Migault, 1145 "Algorithm Implementation Requirements and Usage Guidance 1146 for the Internet Key Exchange Protocol Version 2 (IKEv2)", 1147 RFC 8247, DOI 10.17487/RFC8247, September 2017, 1148 . 1150 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1151 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1152 . 1154 10.2. Informative References 1156 [I-D.ietf-nvo3-geneve] 1157 Gross, J., Ganga, I., and T. Sridhar, "Geneve: Generic 1158 Network Virtualization Encapsulation", draft-ietf- 1159 nvo3-geneve-09 (work in progress), February 2019. 1161 [I-D.ietf-nvo3-security-requirements] 1162 Hartman, S., Zhang, D., Wasserman, M., Qiang, Z., and M. 1163 Zhang, "Security Requirements of NVO3", draft-ietf-nvo3- 1164 security-requirements-07 (work in progress), June 2016. 1166 [I-D.ietf-tls-dtls13] 1167 Rescorla, E., Tschofenig, H., and N. Modadugu, "The 1168 Datagram Transport Layer Security (DTLS) Protocol Version 1169 1.3", draft-ietf-tls-dtls13-30 (work in progress), 1170 November 2018. 1172 Authors' Addresses 1174 Daniel Migault 1175 Ericsson 1176 8275 Trans Canada Route 1177 Saint Laurent, QC 4S 0B6 1178 Canada 1180 EMail: daniel.migault@ericsson.com 1181 Sami Boutros 1182 VMware, Inc. 1184 EMail: boutros@vmware.com< 1186 Dan Wings 1187 VMware, Inc. 1189 EMail: dwing@vmware.com 1191 Suresh Krishnan 1192 Kaloom 1194 EMail: suresh@kaloom.com