idnits 2.17.1 draft-mglt-nvo3-geneve-security-requirements-05.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 (November 04, 2018) is 1999 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) == Outdated reference: A later version (-16) exists of draft-ietf-nvo3-geneve-08 Summary: 1 error (**), 0 flaws (~~), 3 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: May 8, 2019 D. Wings 6 VMware, Inc. 7 S. Krishnan 8 Kaloom 9 November 04, 2018 11 Geneve Security Requirements 12 draft-mglt-nvo3-geneve-security-requirements-05 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 May 8, 2019. 45 Copyright Notice 47 Copyright (c) 2018 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 . . . . . . . . . . . . . . . . . . . . 2 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.2. Protecting Against Traffic Injection . . . . . . . . . . 10 71 5.3. Protecting Against Traffic Redirection . . . . . . . . . 11 72 5.4. Protecting Against Traffic Replay . . . . . . . . . . . . 12 73 5.5. Security Management . . . . . . . . . . . . . . . . . . . 13 74 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 75 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 76 8. Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . 14 77 8.1. TLS . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 78 8.2. IPsec . . . . . . . . . . . . . . . . . . . . . . . . . . 15 79 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 80 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 81 10.1. Normative References . . . . . . . . . . . . . . . . . . 15 82 10.2. Informative References . . . . . . . . . . . . . . . . . 16 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 85 1. Requirements Notation 87 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 88 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 89 "OPTIONAL" in this document are to be interpreted as described BCP 14 90 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, 91 as shown here. 93 2. Introduction 95 The network virtualization overlay over Layer 3 (NVO3) as depicted in 96 Figure 1, allows an overlay cloud provider to provide a logical L2/L3 97 interconnect for the Tenant Systems TSes that belong to a specific 98 tenant network. A packet received from a TS is encapsulated by the 99 ingress Network Virtualization Edge (NVE). The encapsulated packet 100 is then sent to the remote NVE through a tunnel. When reaching the 101 egress NVE of the tunnel, the packet is decapsulated and forwarded to 102 the target TS. The L2/L3 address mappings to the remote NVE(s) are 103 distributed to the NVEs by a logically centralized Network 104 Virtualization Authority (NVA) or using a distributed control plane 105 such as Ethernet-VPN. In a datacenter, the NVO3 tunnels can be 106 implemented using Generic Network Virtualization Encapsulation 107 (Geneve) [I-D.ietf-nvo3-geneve]. Such Geneve tunnels establish NVE- 108 to-NVE communications, may transit within the data center via Transit 109 device. The Geneve tunnels overlay network enable multiple Virtual 110 Networks to coexist over a shared underlay infrastructure, and a 111 Virtual Network may span a single data center or multiple data 112 centers. 114 The underlay infrastructure on which the multi-tenancy overlay 115 networks are hosted, can be owned and provided by an underlay 116 provider who may be different from the overlay cloud provider. 118 +--------+ +--------+ 119 | Tenant +--+ +----| Tenant | 120 | System | | (') | System | 121 +--------+ | ................. ( ) +--------+ 122 | +---+ +---+ (_) 123 +--|NVE|---+ +---|NVE|-----+ 124 +---+ | | +---+ 125 / . +-----+ . 126 / . +--| NVA | . 127 / . | +-----+ . 128 | . | . 129 | . | L3 Overlay +--+--++--------+ 130 +--------+ | . | Network | NVE || Tenant | 131 | Tenant +--+ . | | || System | 132 | System | . \ +---+ +--+--++--------+ 133 +--------+ .....|NVE|......... 134 +---+ 135 | 136 | 137 ===================== 138 | | 139 +--------+ +--------+ 140 | Tenant | | Tenant | 141 | System | | System | 142 +--------+ +--------+ 144 Figure 1: Generic Reference Model for Network Virtualization Overlays 145 [RFC7365] 147 This document discusses the security risks that a Geneve based NVO3 148 network may encounter. In addition, this document lists the 149 requirements to protect the Geneve packet components defined in 150 [I-D.ietf-nvo3-geneve] that include the Geneve tunnel IP and UDP 151 header, the Geneve Header, Geneve options, and inner payload. 153 The document provides two sets of security requirements: 155 1. SEC-OP: requirements to evaluate a given deployment of Geneve 156 overlay. Such requirements are intended to Geneve overlay 157 provider to evaluate a given deployment. Security of the Geneve 158 packet may be achieved using various mechanisms. Typically, some 159 deployments may use a limited subset of the capabilities provided 160 by Geneve and rely on specific assumptions. Given these 161 specificities, the secure deployment of a given Geneve deployment 162 may be achieved reusing specific mechanisms such as for example 163 DTLS [RFC6347] or IPsec [RFC4301]. On the other hand, the 164 definition of a security mechanisms that enables to secure any 165 Geneve deployment requires the design of a Geneve specific 166 mechanism. Note that the security s limited to the security of 167 the data plane only. Additional requirements for the control 168 plan MAY be considered in [I-D.ietf-nvo3-security-requirements]. 169 A given Geneve deployment will be considered secured when 170 matching with all SEC-OP requirements does not raises any 171 concern. As such the given deployment will be considered passing 172 SEC-OP requirements that are not applicable. 174 2. SEC-GEN: requirements a security mechanism need to fulfill to 175 secure any deployment of Geneve overlay deployment. Such 176 mechanism may require the design of a specific solution. In the 177 case new protocol needs to be design, the document strongly 178 recommend to re-use existing security protocols like IP Security 179 (IPsec) [RFC4301] and Datagram Transport Layer Security (DTLS) 180 [RFC6347], and existing encryption algorithms (such as 181 [RFC8221]), and authentication protocols. A given candidate for 182 a security mechanism will be considered as valid when matching 183 with all SEC-GEN requirements does not raise any concern. In 184 other words, at least all MUST status are met. 186 This document assumes the following roles are involved: - Tenant: 187 designates the entity that connects various systems within a single 188 virtualized network. The various system can typically be containers, 189 VMs implementing a single or various functions. 190 - Geneve Overlay Provider: provides the Geneve overlay that 191 seamlessly connect the various Tenant Systems over a given 192 virtualized network. 193 - Infrastructure Provider: provides the infrastructure that runs the 194 Geneve overlay network as well as the Tenant System. A given 195 deployment may consider different infrastructure provider with 196 different level of trust. Typically the Geneve overlay network may 197 use a public cloud to extend the resource of a private cloud. 198 Similarly, a edge computing may extend its resources using resource 199 of the core network. 201 Tenant, Geneve Overlay Provider and Infrastructure Provider can be 202 implemented by a single or various different entities with different 203 level of trust between each other. The simplest deployment may 204 consists in a single entity running its systems in its data center 205 and using Geneve in order to manage its internal resources. A more 206 complex use case may consider that a Tenant subscribe to the Geneve 207 Overlay Provider which manage the virtualized network over various 208 type of infrastructure. The trust between the Tenant, Geneve Overlay 209 Provider and Infrastructure Provider may be limited. 211 Given the different relations between Tenant, Geneve Overlay Provider 212 and Infrastructure Provider, this document aims providing 213 requirements to ensure: 1. The Geneve Overlay Provider delivers 214 tenant payload traffic (Geneve inner payload) and ensuring privacy 215 and integrity. 2. The Geneve Overlay Provider provides the 216 necessary means to prevent injection or redirection of the Tenant 217 traffic from a rogue node in the Geneve overlay network or a rogue 218 node from the infrastructure. 3. The Geneve Overlay Provider can 219 rely on the Geneve overlay in term of robustness and reliability of 220 the signaling associated to the Geneve packets (Geneve tunnel header, 221 Geneve header and Geneve options) in order to appropriately manage 222 its overlay. 224 3. Terminology 226 This document uses the terminology of [RFC8014], [RFC7365] and 227 [I-D.ietf-nvo3-geneve]. 229 4. Security Threats 231 This section considers attacks performed by NVE, network devices or 232 any other devices using Geneve, that is when the attackers knowing 233 the details of the Geneve packets can perform their attacks by 234 changing fields in the Geneve tunnel header, base header, Geneve 235 options and Geneve inner payload. Attacks related to the control 236 plane are outside the scope of this document. The reader is 237 encouraged to read [I-D.ietf-nvo3-security-requirements] for a 238 similar threat analysis of NVO3 overlay networks. 240 Threats include traffic analysis, sniffing, injection, redirection, 241 and replay. Based on these threats, this document enumerates the 242 security requirements. 244 Threats are divided into two categories: passive attack and active 245 attack. 247 Threats are always associated with risks and the evaluation of these 248 risks depend among other things on the environment. 250 4.1. Passive Attacks 252 Passive attacks include traffic analysis (noticing which workloads 253 are communicating with which other workloads, how much traffic, and 254 when those communications occur) and sniffing (examining traffic for 255 useful information such as personally-identifyable information or 256 protocol information (e.g., TLS certificate, overlay routing 257 protocols). 259 Passive attacks may also consist in inferring information about a 260 virtualized network or some Tenant System from observing the Geneve 261 traffic. This could also involve the correlation between observed 262 traffic and additional information. For example, a passive network 263 observer can determine two virtual machines are communicating by 264 manipulating activity or network activity of other virtual machines 265 on that same host. For example, the attacker could control (or be 266 otherwise aware of) network activity of the other VMs running on the 267 same host, and deduce other network activity is due to a victim VM. 269 A rogue element of the overlay Geneve network under the control of an 270 attacker may leak and redirect the traffic from a virtual network to 271 the attacker for passive monitoring [RFC7258]. 273 Avoiding leaking information is hard to enforced. The security 274 requirements provided in section {{sniffing} expect to mitigate such 275 attacks by lowering the consequences, typically making leaked data 276 unusable to an attacker. 278 4.2. Active Attacks 280 Active attacks involve modifying Geneve packets, injecting Geneve 281 packets, or interfering with Geneve packet delivery (such as by 282 corrupting packet checksum). Active attack may target the Tenant 283 System or the Geneve overlay. 285 There are multiple motivations to inject illegitimate traffic into a 286 tenants network. When the rogue element is on the path of the TS 287 traffic, it may be able to inject and receive the corresponding 288 messages back. On the other hand, if the attacker is not on the path 289 of the TS traffic it may be limited to only inject traffic to a TS 290 without receiving any response back. When rogue element have access 291 to the traffic in both directions, the possibilities are only limited 292 by the capabilities of the other on path elements - Transit device, 293 NVE or TS - to detect and protect against the illegitimate traffic. 294 On the other hand, when the rogue element is not on path, the surface 295 for such attacks remains still quite large. For example, an attacker 296 may target a specific TS or application by crafting a specific packet 297 that can either generate load on the system or crash the system or 298 application. TCP syn flood typically overload the TS while not 299 requiring the ability to receive responses. Note that udp 300 application are privileged target as they do not require the 301 establishment of a session and are expected to treat any incoming 302 packets. 304 Traffic injection may also be used to flood the virtual network to 305 disrupt the communications between the TS or to introduce additional 306 cost for the tenant, for example when pricing considers the traffic 307 inside the virtual network. The two latest attacks may also take 308 advantage of applications with a large factor of amplification for 309 their responses as well as applications that upon receiving a packet 310 interact with multiple TS. Similarly, applications running on top of 311 UDP are privileged targets. 313 Note also that an attacker that is not able to receive the response 314 traffic, may use other channels to evaluate or measure the impact of 315 the attack. Typically, in the case of a service, the attacker may 316 have access, for example, to a user interface that provides 317 indication on the level of disruption and the success of an attack, 318 Such feed backs may also be used by the attacker to discover or scan 319 the network. 321 Preventing traffic to cross virtual networks, reduce the surface of 322 attack, but rogue element main still perform attacks within a given 323 virtual network by replaying a legitimate packet. Some variant of 324 such attack also includes modification of unprotected parts when 325 available in order for example to increase the payload size. 327 5. Requirements for Security Mitigations 329 The document assumes that Security protocols, algorithms, and 330 implementations provide the security properties for which they are 331 designed, an attack caused by a weakness in a cryptographic algorithm 332 is out of scope. 334 Protecting network connecting TSes and NVEs which could be accessible 335 to outside attackers is out of scope. 337 An attacker controlling an underlying network device may break the 338 communication of the overlays by discarding or delaying the delivery 339 of the packets passing through it. The security consideration to 340 prevent this type of attack is out of scope of this document. 342 Securing communication between NVAs and NVEs is out of scope. 344 Selectively providing integrity / authentication, confidentiality / 345 encryption of only portions of the Geneve packet is in scope. This 346 will be the case if the Tenant Systems uses security protocol to 347 protect its communications. 349 5.1. Protection Against Traffic Sniffing 351 The inner payload, unless protection is provided by the Tenant System 352 reveals the content of the communication. This may mitigate by the 353 Tenant using application level security such as, for example JSON Web 354 Encryption [RFC7516] or transport layer security such as DTLS 355 [RFC6347] or TLS [RFC8446] or IPsec/ESP [RFC4303]. However none of 356 these security protocols are sufficient to protect the entire inner 357 payload. IPsec/ESP still leave in clear the optional L2 layer 358 information as well as the IP addresses and some IP options. In 359 addition to these pieces of information, the use of TLS or DTLS 360 reveals the transport layer protocol as well as ports. 362 A secure deployment of a Geneve overlay must fulfill the requirement 363 below: 365 1. SEC-OP-1: A secure deployment of a Geneve overlay SHOULD by 366 default encrypt the inner payload. A Geneve overlay provider MAY 367 disable this capability for example when encryption is performed 368 by the Tenant System and that level of confidentiality is 369 believed to be sufficient. In order to provide additional 370 protection to traffic already encrypted by the Tenant the Geneve 371 network operator MAY partially encrypt the clear part of the 372 inner payload. 374 A Geneve security mechanism must fulfill the requirements below: 376 o SEC-GEN-1: Geneve security mechanism MUST provide the capability 377 to encrypt the inner payload. 379 o SEC-GEN-2: Geneve security mechanism SHOULD provide the capability 380 to partially encrypt the inner payload header. 382 The Geneve Header and Geneve Options contains metadata information 383 related to the communications. Note that a Geneve packet may have a 384 combination of Geneve options that needs to be read by transit 385 device, in which case this option needs to be read by the transit 386 device while other options MAY only be accessed by the tunnel 387 endpoint. Information revealed as well as correlation with traffic 388 volumetry may reveal pattern traffic within a given virtualized 389 network as well as any information revealed by the current and future 390 Geneve Option. 392 A secure deployment of a Geneve overlay must fulfill the requirement 393 below: 395 o SEC-OP-2: A secure deployment of a Geneve overlay MUST evaluate 396 the information associated to the leakage of the Geneve Outer 397 Header, Geneve Header and Geneve Option. When a risk analysis 398 concludes that the risk of leaking sensitive information is too 399 high, such MUST NOT be transmit in clear text. 401 o SEC-OP-3: A secure deployment of a Geneve overlay MUST evaluate 402 the risk associated to traffic pattern recognition. When a risk 403 has been identified, traffic pattern recognition MUST be addressed 404 with padding policies as well as generation of dummy packets. 406 A Geneve security mechanism must fulfill the requirements below: 408 o SEC-GEN-3: Geneve security mechanism MUST provide the capability 409 to encrypt a single or a set of options while leave other Geneve 410 Option in clear. Reversely, a Geneve security mechanism MUST be 411 able to leave a Geneve option in clear, while encrypting the 412 others. 414 o SEC-GEN-4: Geneve security mechanism MUST provide means to encrypt 415 the information of Geneve Header. Reversely, a Geneve security 416 mechanism MUST be able to leave in clear header information while 417 encrypting the other. 419 o SEC-GEN-5: Geneve security mechanism MUST provide the ability to 420 pad a Geneve packet. 422 o SEC-GEN-6: Geneve security mechanism MUST provide the ability to 423 send dummy packets. 425 5.2. Protecting Against Traffic Injection 427 Traffic injection from a rogue non legitimate NVO3 Geneve overlay 428 device or a rogue underlay transit device can target an NVE, a 429 transit underlay device or a Tenant System. Targeting a Tenant's 430 System requires a valid MAC and IP addresses of the Tenant's System. 432 Tenant's System may protect their communications using IPsec or TLS. 433 Such protection protects the Tenants from receiving spoofed packets, 434 as any injected packet is expected to be discarded by the destination 435 Tenant's System. Such protection does not protect the tenant system 436 from receiving illegitimate packets that may disrupt the Tenant's 437 System performance. The Geneve overlay network MAY still need to 438 prevent such spoofed Tenant's system packets from being steered to 439 the Tenant's system. When the Tenant's Systems are not protecting 440 their communications, the Geneve overlay network SHOULD be able to to 441 prevent a rogue device from injecting traffic into the overlay 442 network. 444 In order to prevent traffic injection to one virtual network, the 445 destination legitimate Geneve NVE MUST be able to authenticate the 446 incoming Geneve packets from the source NVE. The Geneve architecture 447 considers transit devices that MAY process some Geneve Option without 448 affecting the Geneve packet. These transit device MAY Authenticate 449 the Geneve packet as part of the Geneve packet processing but MAY 450 also process other Geneve options. As a result, integrity protection 451 and authentication SHOULD be performed by transit device, prior to 452 any processing. 454 A secure deployment of a Geneve overlay must fulfill the requirement 455 below: 457 o SEC-OP-4: A secure deployment of a Geneve overlay SHOULD 458 authenticate communications between NVE to protect the Geneve 459 Overlay infrastructure as well as the Tenants System's 460 communications (Geneve Packet). A Geneve overlay provider MAY 461 disable authentication of the inner packet and delegates it to the 462 Tenant Systems when communications between Tenant's System is 463 secured. This is NOT RECOMMENDED. To prevent injection between 464 virtualized network, it is strongly RECOMMENDED that at least the 465 Geneve Header is authenticated. 467 o SEC-OP-5: A secure deployment of a Geneve overlay SHOULD NOT 468 process data prior authentication. If that is not possible, the 469 Geneve overlay provider SHOULD evaluate its impact. 471 A Geneve security mechanism must fulfill the requirements below: 473 o SEC-GEN-8: Geneve Security mechanism MUST provide means for a 474 tunnel endpoint (NVE) to authenticate data prior it is being 475 processed. A tunnel endpoint (NVE) MUST be able to authenticate 476 at least: 478 * the Geneve Header and a subset of Geneve Options 480 * the Geneve Header, a subset of Geneve options and the Geneve 481 inner payload 483 * the Geneve Header, a subset of Geneve options and the Geneve 484 inner payload or the portion of the inner payload in case the 485 Tenant's System provides some authentication mechanism. 487 o SEC-GEN-9: Geneve Security mechanism SHOULD provide means for a 488 transit device to authenticate the Geneve Option prior processing 489 it. Authentication MAY concern the whole Geneve packet, but MAY 490 be limited to the Geneve Option. 492 5.3. Protecting Against Traffic Redirection 494 A rogue device of the NVO3 overlay Geneve network or the underlay 495 network may redirect the traffic from a virtual network to the 496 attacker for passive or active attacks. If the rogue device is in 497 charge of the securing the Geneve packet, then Geneve security 498 mechanisms are not intended to address this threat. More 499 specifically, a rogue source NVE will still be able to redirect the 500 traffic in clear text before protecting ( and encrypting the packet). 501 A rogue destination NVE will still be able to redirect the traffic in 502 clear text after decrypting the Geneve packets. The same occurs with 503 a rogue transit that is in charge of encrypting and decrypting a 504 Geneve Option, Geneve Option or any information. The security 505 mechanisms are intended to protect a Geneve information from any on 506 path node. Note that modern cryptography recommend the use of 507 authenticated encryption. This section assumes such algorithms are 508 used, and as such encrypted packets are also authenticated. 510 To prevent an attacker located in the middle between the NVEs and 511 modifying the tunnel address information in the data packet header to 512 redirect the data traffic, the solution need to provide 513 confidentiality protection for data traffics exchanged between NVEs. 515 Requirements are similar as those provided in section Section 5.1 to 516 mitigate sniffing attacks and those provided in section Section 5.2 517 to mitigate traffic injection attacks. 519 5.4. Protecting Against Traffic Replay 521 A rogue device of the NVO3 overlay Geneve network or the underlay 522 network may replay a Geneve packet, to load the network and/or a 523 specific Tenant System with a modified Geneve payload. In some 524 cases, such attacks may target an increase of the tenants costs. 526 When traffic between tenants is not protected, the rogue device may 527 forward the modified packet over a valid (authenticated) Geneve 528 Header. The crafted packet may for example, include a specifically 529 crafted application payload for a specific Tenant Systems 530 application, with the intention to load the tenant specific 531 application. 533 Updating the Geneve header and option parameters such as setting an 534 OAM bit, adding bogus option TLVs, or setting a critical bit, may 535 result in different processing behavior, that could greatly impact 536 performance of the overlay network and the underlay infrastructure 537 and thus affect the tenants traffic delivery. 539 The NVO3 overlay network and underlay network nodes that may address 540 such attacks MUST provide means to authenticate the Geneve packet 541 components. 543 A secure deployment of a Geneve overlay must fulfill the requirement 544 below: 546 o SEC-OP-6: A secure deployment of a Geneve overlay MUST evaluate 547 the communications subject to replay attacks. Communications that 548 are subject to this attacks MUST be authenticated with an anti 549 replay mechanism. Note that when partial authentication is 550 provided, the part not covered by the authentication remains a 551 surface of attack. It is strongly RECOMMENDED that the Geneve 552 Header is both authenticated with anti replay protection. 554 A Geneve security mechanism must fulfill the requirements below: 556 o SEC-GEN-10: Geneve Security mechanism MUST provide means for a 557 tunnel endpoint (NVE) to validate the Geneve Header corresponds to 558 the Geneve payload, and discard such packets. 560 5.5. Security Management 562 A secure deployment of a Geneve overlay must fulfill the requirement 563 below: 565 o SEC-OP-7: A secure deployment of a Geneve overlay MUST define the 566 security policies that associates the encryption, and 567 authentication associated to each flow between NVEs. 569 o SEC-OP-8: A secure deployment of a Geneve overlay SHOULD define 570 distinct material for each flow. The cryptographic depends on the 571 nature of the flow (multicast, unicast) as well as on the security 572 mechanism enabled to protect the flow. 574 A Geneve security mechanism must fulfill the requirements below: 576 o SEC-GEN-11: A Geneve security mechanism MUST be managed via 577 security policies associated for each traffic flow to be 578 protected. Geneve overlay provider MUST be able to configure NVEs 579 with different security policies for different flows. A flow MUST 580 be identified at minimum by the Geneve virtual network identifier 581 and the inner IP and transport headers, and optionally additional 582 fields which define a flow (e.g., inner IP DSCP, IPv6 flow id, 583 Geneve options). 585 o SEC-GEN-12: A Geneve security mechanism MUST be able to assign 586 different cryptographic keys to protect the unicast tunnels 587 between NVEs respectively. 589 o SEC-GEN-13: A Geneve security mechanisms, when multicast is used, 590 packets,MUST be able to assign distinct cryptographic group keys 591 to protect the multicast packets exchanged among the NVEs within 592 different multicast groups. Upon receiving a data packet, an 593 egress Geneve NVE MUST be able to verify whether the packet is 594 sent from a proper ingress NVE which is authorized to forward that 595 packet. 597 6. IANA Considerations 599 There are no IANA consideration for this document. 601 7. Security Considerations 603 The whole document is about security. 605 Limiting the coverage of the authentication / encryption provides 606 some means for an attack to craft special packets. 608 The current document details security requirements that are related 609 to the Geneve protocol. Instead, 610 [I-D.ietf-nvo3-security-requirements] provides generic architecture 611 security requirement upon the deployment of an NVO3 overlay network. 612 It is strongly recommended to read that document as architecture 613 requirements also apply here. In addition, architecture security 614 requirements go beyond the scope of Geneve communications, and as 615 such are more likely to address the security needs upon deploying an 616 Geneve overlay network. 618 8. Appendix 620 8.1. TLS 622 This section compares how NVE communications using TLS meet the 623 security requirements for a secure Geneve overlay deployment. In 624 this example TLS is used over the Geneve Outer Header and secured the 625 Geneve Header, Geneve Options and the inner payload. 627 The use of TLS MAY fill the security requirements for a secure Geneve 628 deployment. However TLS cannot be considered as the Geneve security 629 mechanism enabling all Geneve deployments. 631 The use of to secure a Geneve overlay deployment TLS meets SEC-OP-1 632 as it protects the inner payload of the tenant. It meets SEC-OP-2 as 633 except from the UDP port, no information concerning Geneve is leaked. 634 SEC-OP-3 is not met as TLS does not provide the ability to send dummy 635 traffic, nor to pad. SEC-OP-4 is met as the communication is 636 authenticated, including the Geneve Header. SEC-OP-5 is met as the 637 Geneve Packet is processed once it has been authenticated. SEC-OP-6 638 is met as TLS comes with anti replay protection. SEC-OP-7 and SEC- 639 OP-8 may also be met with security policies established per UDP 640 destination port where only unicast is considered. 642 The use of TLS as a generic Geneve Security mechanism meets SEC-GEN-1 643 as it encrypts the inner payload. However, TLS, but does not enable 644 partial encryption of the inner payload. TLS does not meet SEC-GEN3 645 or SEC-GEN-4 that requires the ability to encrypt of a subset of the 646 Geneve Options or the Geneve Header information. In addition, TLS 647 does not enable that some Geneve option of Header information remain 648 in clear text while other are encrypted. Typically TLS would not be 649 compatible with transit device. In addition is make the Geneve 650 option visible to the transit device, TLS does not provide the 651 ability for a transit device to authenticate the option before 652 processing it. SEC-GEN-5 and SEC-GEN-6 are not met as TLS does not 653 provide padding nor the ability to generate dummy packets. TLS does 654 not meet SEC-GEN-8 that requires the ability to authenticate some 655 combination of Geneve Header, Geneve Options, (partial) inner 656 payload. TLS does not meet SEC-GEN-9 that requires the ability to 657 authenticate a single Geneve Option. TLS meets SEC-GEN-10 as it 658 provides anti replay mechanism to the authentication. SEC-GEN-11 is 659 not natively supported as TLS security is established by UDP 660 destination ports, rather than by flow. If more than one security 661 policy or flow needs to be considered a binding between flow and 662 ports needs to be established. SEC-GEN-13 is not met for mutlicast 663 traffic. 665 8.2. IPsec 667 The use of IPsec/ESP or IPsec/AH share most of the analysis performed 668 for TLS. The main advantages of using IPsec would be that IPsec 669 supports multicast communications and natively supports flow based 670 security policies. However, the use of these security policies in a 671 context of Geneve is not natively supported. 673 9. Acknowledgments 675 We would like to thank Ilango S Ganaga for its useful reviews and 676 clarifications as well as Matthew Bocci, Sam Aldrin and Ignas Bagdona 677 for moving the work forward. 679 10. References 681 10.1. Normative References 683 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 684 Requirement Levels", BCP 14, RFC 2119, 685 DOI 10.17487/RFC2119, March 1997, 686 . 688 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 689 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 690 December 2005, . 692 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 693 RFC 4303, DOI 10.17487/RFC4303, December 2005, 694 . 696 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 697 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 698 January 2012, . 700 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 701 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 702 2014, . 704 [RFC7365] Lasserre, M., Balus, F., Morin, T., Bitar, N., and Y. 705 Rekhter, "Framework for Data Center (DC) Network 706 Virtualization", RFC 7365, DOI 10.17487/RFC7365, October 707 2014, . 709 [RFC7516] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)", 710 RFC 7516, DOI 10.17487/RFC7516, May 2015, 711 . 713 [RFC8014] Black, D., Hudson, J., Kreeger, L., Lasserre, M., and T. 714 Narten, "An Architecture for Data-Center Network 715 Virtualization over Layer 3 (NVO3)", RFC 8014, 716 DOI 10.17487/RFC8014, December 2016, 717 . 719 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 720 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 721 May 2017, . 723 [RFC8221] Wouters, P., Migault, D., Mattsson, J., Nir, Y., and T. 724 Kivinen, "Cryptographic Algorithm Implementation 725 Requirements and Usage Guidance for Encapsulating Security 726 Payload (ESP) and Authentication Header (AH)", RFC 8221, 727 DOI 10.17487/RFC8221, October 2017, 728 . 730 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 731 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 732 . 734 10.2. Informative References 736 [I-D.ietf-nvo3-geneve] 737 Gross, J., Ganga, I., and T. Sridhar, "Geneve: Generic 738 Network Virtualization Encapsulation", draft-ietf- 739 nvo3-geneve-08 (work in progress), October 2018. 741 [I-D.ietf-nvo3-security-requirements] 742 Hartman, S., Zhang, D., Wasserman, M., Qiang, Z., and M. 743 Zhang, "Security Requirements of NVO3", draft-ietf-nvo3- 744 security-requirements-07 (work in progress), June 2016. 746 Authors' Addresses 748 Daniel Migault 749 Ericsson 750 8275 Trans Canada Route 751 Saint Laurent, QC 4S 0B6 752 Canada 754 EMail: daniel.migault@ericsson.com 756 Sami Boutros 757 VMware, Inc. 759 EMail: boutros@vmware.com< 761 Dan Wings 762 VMware, Inc. 764 EMail: dwing@vmware.com 766 Suresh Krishnan 767 Kaloom 769 EMail: suresh@kaloom.com