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