idnits 2.17.1 draft-ietf-nvo3-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 == Line 557 has weird spacing: '...nce, if the r...' -- The document date (January 28, 2015) is 3376 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.ietf-ipsecme-ad-vpn-problem' is defined on line 743, but no explicit reference was found in the text == Unused Reference: 'I-D.mahalingam-dutt-dcops-vxlan' is defined on line 753, but no explicit reference was found in the text == Unused Reference: 'RFC4046' is defined on line 764, but no explicit reference was found in the text == Unused Reference: 'RFC5996' is defined on line 787, but no explicit reference was found in the text == Unused Reference: 'RFC7364' is defined on line 791, but no explicit reference was found in the text == Outdated reference: A later version (-17) exists of draft-ietf-nvo3-hpvr2nve-cp-req-01 -- Obsolete informational reference (is this intentional?): RFC 2409 (Obsoleted by RFC 4306) -- Obsolete informational reference (is this intentional?): RFC 4306 (Obsoleted by RFC 5996) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 5996 (Obsoleted by RFC 7296) Summary: 0 errors (**), 0 flaws (~~), 8 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group S. Hartman 2 Internet Draft Painless Security 3 Intended status: Informational D. Zhang 4 Expires: July 28,, 2015 Alibaba 5 M. Wasserman 6 Painless Security 7 Z. Qiang 8 Ericsson 9 Mingui Zhang 10 Huawei 11 January 28, 2015 13 Security Requirements of NVO3 14 draft-ietf-nvo3-security-requirements-04 16 Abstract 18 The draft describes a list of essential requirements in order to 19 benefit the design of NVO3 security solutions. In addition, this 20 draft introduces the candidate techniques which could be used to 21 construct a security solution fulfilling these security requirements. 23 Requirements Language 25 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 26 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 27 document are to be interpreted as described in RFC 2119 [RFC2119]. 29 Status of this Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute working 36 documents as Internet-Drafts. The list of current Internet-Drafts is 37 at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on July 28, 2015. 46 Copyright Notice 48 Copyright (c) 2015 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction...................................................3 64 2. Terminology....................................................3 65 3. NVO3 Overlay Architecture......................................4 66 4. Threat Model...................................................5 67 4.1. Capabilities of Outsiders.................................5 68 4.2. Capabilities of Insiders..................................5 69 4.3. Capabilities of Malicious TSes............................6 70 5. Scope..........................................................6 71 6. Security Requirements..........................................8 72 6.1. Control Plane of NVO3 Overlay.............................8 73 6.2. NVE-NVE Data Plane.......................................11 74 6.3. NVE-Hypervisor Data Plane................................13 75 7. Candidate Techniques..........................................15 76 7.1. Entity Authentication....................................15 77 7.2. Packet Level Security....................................15 78 7.3. Authorization............................................15 79 8. IANA Considerations...........................................16 80 9. Security Considerations.......................................16 81 9.1. Automated Key Management in NVO3.........................16 82 10. Acknowledgements.............................................17 83 11. References...................................................17 84 11.1. Normative References....................................17 85 11.2. Informative References..................................17 87 1. Introduction 89 As described in [RFC7365], the NVO3 framework is intended to aid in 90 standardizing protocols and mechanisms to support large-scale multi- 91 tenancy data centers. In such kind data center, security is a key 92 issue which needs to be considered during the network design. This 93 document discusses the security risks that a NVO3 network may 94 encounter and tries to provide a list of essential security 95 requirements that needs to be fulfilled. In addition, this document 96 introduces the candidate techniques which could be potentially used 97 to construct a security solution fulfilling the security 98 requirements. 100 The remainder of this document is organized as follows. Section 2 101 introduces several key terms used in this memo. Section 3 gives a 102 brief introduction of the NVO3 network architecture. Section 4 103 discusses the attack model of this work. Section 5 lists the scope of 104 the security considerations of this memo. Section 6 provides a list 105 of security requirements as well as the associated justifications. In 106 Section 7, the candidate techniques are introduced. Section 9 107 discusses additional security considerations. 109 2. Terminology 111 This document uses the same terminology as defined in the NVO3 112 Framework document [RFC7365] and the Hypervisor to NVE Control Plane 113 Requirements document [I-D.ietf-nvo3-hpvr2nve-cp-req]. The Followings 114 are the additional terminologies that are used by this document. 116 Hypervisor: This memo uses the term "hypervisor" throughout when 117 describing requirements at the Split-NVE scenario where part of the 118 NVE functionality is off-loaded to a separate device from the 119 "hypervisor" that contains a VM connected to a VN. In this context, 120 the term "hypervisor" is meant to cover any device type where part of 121 the NVE functionality is off-loaded in this fashion, e.g. a Network 122 Service Appliance, Linux Container. 124 NVO3 device: In this memo, the devices (e.g., NVE and NVA) work 125 cooperatively to provide NVO3 overlay functionalities are referred as 126 NVO3 devices. 128 3. NVO3 Overlay Architecture 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 +--------+ +--------+ 155 Figure 1 : Generic Reference Model for DC Network Virtualization 156 Overlays [RFC7365] 158 This figure illustrates a generic reference model for NVO3 overlay 159 where NVEs provide a logical L2/L3 interconnect for the TSes that 160 belong to a specific tenant network over a L3 networks. A packet 161 received from a tenant system is encapsulated by the ingress NVE. 162 Then encapsulated packet is then sent to the remote NVE through a 163 proper tunnel. When reaching the egress NVE of the tunnel, the packet 164 is decapsulated and forwarded to the target tenant system. The 165 address mappings and other related information are distributed to the 166 NVEs by a logically centralized Network Virtualization Authority 167 (NVA). 169 4. Threat Model 171 To benefit describing the threats a NVO3 network may have to face, 172 the attacks considered in this document are classified into three 173 categories: the attacks from compromised NVO3 devices (inside 174 attacks), the attacks from compromised tenant systems, and the 175 attacks from underlying networks (outside attacks). 177 The adversaries performing the first type of attack are called as 178 insiders or inside attackers because they need to get certain 179 privileges in changing the configuration or software of NVO3 devices 180 beforehand and initiate the attacks within the overlay security 181 perimeter. In the second type of attack, an attacker (e.g., a 182 malicious tenant, or an attacker who has compromised a virtual 183 machine of an innocent tenant) has got certain privileges in changing 184 the configuration or software of tenant systems and attempts to 185 manipulate the controlled tenant systems to interfere with the normal 186 operations of the NVO3 overlay. The third type of attack is referred 187 to as the outside attack since adversaries do not have to obtain any 188 privilege on the NVO3 devices or tenant systems in advance in order 189 to perform this type attack, and thus the adversaries performing 190 outside attacks are called as outside attackers or outsiders. 192 4.1. Capabilities of Outsiders 194 In practice, an outside attacker may perform attacks by intercepting 195 packets, deleting packets, and/or inserting bogus packets. With a 196 successful outside attack, an attacker may be able to: 198 1. Analyze the traffic pattern within the network by performing 199 passive attacks; 201 2. Disrupt the network connectivity or degrade the network service 202 quality (e.g., by performing DoS attacks); or 204 3. Access the contents of the data/control packets which are not 205 properly encrypted. 207 4.2. Capabilities of Insiders 209 Besides intercepting packets, deleting packets, and/or inserting 210 bogus packets, an inside attacker may use already obtained privilege 211 to, 213 1. Interfere with the normal operations of the overlay as a legal 214 NVO3 device, by sending packets containing invalid information or 215 with improper frequencies; 217 2. Perform spoofing attacks and impersonate another legal NVO3 device 218 to communicate with victims using the cryptographic information it 219 obtained; and 221 3. Access the contents of the data/control packets if they are 222 encrypted with the keys held by the attacker. 224 4.3. Capabilities of Malicious TSes 226 It is assumed that the attacker performing attacks from compromised 227 TSes is able to intercept packets, delete packets, and/or insert 228 bogus packets. In addition, after compromising a TS, an attacker may 229 be able to: 231 1. Interfere with the normal operations of the overlay as a legal 232 TS, by sending packets containing invalid information or with 233 improper frequencies to NVEs; 235 2. Perform spoofing attacks and impersonate another legal TS or NVE 236 to communicate with victims (other legal NVEs or TSes) using the 237 cryptographic information it obtained; and 239 3. Access the contents of the data/control packets if they are 240 encrypted with the keys held by the attacker. 242 5. Scope 244 During the specification of security requirements, the following 245 security issues needs to be considered: 247 1. The NVO3 connections may be considered as secured if there is a 248 security solution supported by the underlying network. However 249 such kind security solution normally only can protect the NVO3 250 network from outsider attacker. 252 2. During the design of a security solution for a NVO3 network, the 253 attacks raised from compromised NVEs and hypervisors needs to be 254 considered. 256 3. It is reasonable to consider the conditions where the network 257 connecting TSes and NVEs is accessible to outside attackers. 259 The following issues are out of scope of consideration in this 260 document: 262 1. In this memo it is assumed that security protocols, algorithms, 263 and implementations provide the security properties for which they 264 are designed; attacks depending on a failure of this assumption 265 are out of scope. For instance, an attack caused by a weakness in 266 a cryptographic algorithm is out of scope, while an attack caused 267 by failure to use confidentiality when confidentiality is a 268 security requirement is in scope. 270 2. An attacker controlling an underlying network device may break the 271 communication of the overlays by discarding or delaying the 272 delivery of the packets passing through it. The security 273 consideration to prevent this type of attack is out of scope of 274 this memo. 276 3. NVAs are centralized servers and play a critical role in NVO3 277 overlay network. A NVE will believe in the mapping information 278 obtained from its NVA. After compromising a NVA, the attacker can 279 distribute bogus mapping information to NVEs under the management 280 of NVA. The security requirements discussed in this document is to 281 protect a NVA from any security risk. And if a NVA is attacked, it 282 should be detected. However, this work does not consider how to 283 deal with the problem after a NVA is compromised. 285 4. Because this memo only tries to provide the most essential high 286 level requirements, some important issues in designing concept 287 security mechanisms are not covered in the requirements. Such 288 issues include: 290 - How to manage keys/credentials during their life periods 292 - How to support algorithm agility 294 - How to provide accountability 296 - How to secure the management interfaces 298 - Use underlying security protocols versus design integrated 299 security extensions 301 6. Security Requirements 303 6.1. Control Plane of NVO3 Overlay 305 In this section, the security requirements associated with following 306 control plane are described: 308 - The NVE-NVA control plane: allows a NVE to obtain information 309 about the location and status of other TSs with which it needs to 310 communicate; to provide updates to the NVA about the attached TSs; 311 and to report any communication errors. In this case, the term 312 "NVO3 device" is referring to a NVA or a NVE. 314 - The NVA-NVA control plane: Multiple NVAs may be deployed in a NVO3 315 overlay for better scalability and fault tolerance capability. The 316 NVAs may use unicast and/or multicast to exchange signaling 317 packets within the control plane. In this case, the term "NVO3 318 device" is referring to a NVA. 320 - The NVE-NVE control plane: As specified in [RFC7365], in order to 321 obtain reachability information, NVEs may exchange information 322 directly between themselves via a control-plane protocol. In this 323 case, the term "NVO3 device" is referring to a NVE. 325 - The NVE-Hypervisor control plane: In the Split-NVE scenario, the 326 NVE and hypervisors may also need to exchange signaling packets 327 over network in order to facilitate, e.g., VM online detection, VM 328 migration detection, or auto-provisioning/service discovery as 329 described in [RFC7365]. In this case, the term "NVO3 device" is 330 referring to a Hypervisor or a NVE. 332 REQ 1. The security solution for NVO3 MUST enable the two NVO3 333 devices to mutually authenticate each other before exchanging 334 any control packets. 336 Entity authentication can protect a NVO3 device against imposter 337 attacks and then reduce the risk of DoS/DDoS attacks and man-in-the- 338 middle attacks. In addition, a successful authentication normally 339 results in the distribution key materials for the security protection 340 for subsequent communications. More detailed discussions are provided 341 in Section 6.1. 343 REQ 2. The security solution of NVO3 MUST be able to provide 344 integrity protection, replay protection, and packet origin 345 authentication for the control packets exchanged between two 346 NVO3 devices. 348 Message authentication is performed on each incoming packet. Packet 349 level security protection can prevent an attacker from illegally 350 interfere with the normal operations of NVO3 device by injecting 351 bogus control packets into the network. Through message 352 authentication, the NVO3 device receiving a control packet can verify 353 whether the packet is generated by a legitimate NVO3 device, is not 354 antique, and is not tampered during transportation. 356 Such protection must be deployed if there is any possibility that the 357 control packets could be accessed by outside attackers. This 358 protection can prevent an attacker locating in the middle between the 359 NVO3 devices and modifying the information in the control packet so 360 as to redirect the traffic as wished. In addition, with the support 361 of properly distributed keys, these level protections can also 362 benefit the detection of spoofing attacks raised from insiders. 364 REQ 3. The security solution of a NVO3 network SHOULD provide 365 confidentiality protection for the control packets exchanged 366 between two NVO3 devices. 368 On many occasions, the control packets can be transported in 369 plaintext. However, if the information contained within the control 370 packets is considered to be sensitive or valuable, it is recommended 371 to encrypt the packets in order to prevent outsiders from accessing 372 the sensitive data, especially when the underlying network is not 373 secured enough. Note that encryption will impose additional overhead 374 in processing control packets and make NVO3 devices more vulnerable 375 to DoS / DDoS attacks. 377 REQ 4. Node authorization procedure MUST be supported before 378 processing any received control packets in the NVO3 device 380 When receiving a control packet, besides authentication, 381 authorization needs to be carried out by the receiver to identify the 382 role that the packet sender acts as in the overlay and then assess 383 the sender's privileges. If a compromised NVO3 device tries to 384 illegally elevate its privilege, it will be detected and rejected. 385 For instance, a compromised NVO3 device may use its credentials to 386 communicate with other NVEs as a NVA, or attempting to access or 387 update the mapping information of the VNs which it is not authorized 388 to serve. 390 REQ 5. The security solution of NVO3 SHOULD be able to provide 391 distinct cryptographic keys for each NVO3 device to protect the 392 unicast control traffics exchanged between different NVO3 393 devices respectively. 395 During the exchange of control packets, keys are critical in 396 authenticating the packet senders. The purpose of this requirement is 397 to provide a basic capability to confine the damage caused by inside 398 attacks. After compromising a NVO3 device, an attacker may be able 399 to use the keys it obtained to exchange control traffics with other 400 NVO3 devices. But it will not be able to use the keys it obtained to 401 breach the security of the control traffics exchanged between other 402 NVO3 devices. 404 REQ 6. The security solution of NVO3 SHOULD be able to assign 405 distinct cryptographic group keys for each multicast group to 406 protect the multicast packets exchanged among the NVO3 devices 407 within the group. 409 In order to provide an essential packet level security protection 410 specified for integrity and confidentiality, at least one group key 411 may need to be shared among the NVO3 devices in a same multicast 412 group. It is recommended to use different keys for different 413 multicast groups. 415 REQ 7. The resistance at DOS/DDOS attack MUST be considered in the 416 design of NVO3 control plane 418 Any NVO3 devices may be used by an attacker to initiate a DOS/DDOS. 419 One example is that in a NVO3 overlay, NVAs can be the valuable 420 targets of DoS/DDoS attacks, and large amount of NVEs can be 421 potentially used as reflectors in reflection attacks. Therefore, the 422 DoS/DDoS risks needs be considered during designing the control 423 planes for NVO3. The following requirements, but not limited to this 424 listed, are used to benefit the migration of DoS/DDoS issue. 426 REQ 7.a. A NVO3 device MUST have a frequency limitation at 427 sending its control packets and processing any received 428 control packets. 430 Without this limitation, an attacker can attempt to perform DoS/DDoS 431 attacks to exhaust the limited computing and memory resources of a 432 target NVO3 device by manipulating a compromised NVO3 device to 433 generate a significant amount of control plane packets in a short 434 period. 436 REQ 7.b. The amplification effect MUST be avoided 438 A distributed denial-of-service attack may involve sending forged 439 requests of some type to a very large number of NVO3 devices that 440 will reply to the requests. If in certain conditions, the responses 441 generated by a NVO3 device are a much longer process than the 442 received requests. An attacker may take advantage of this 443 amplification effect procedure, which the NVO3 device is used as a 444 reflector to carry out DoS / DDoS attacks towards a victim NVO3 445 device. 447 For instance, the attacker may send request messages to a NVO3 device 448 with a spoofed source address set to the targeted victim. In that 449 case, all the replies generated by the NVO3 device will be sent (and 450 flooded) to the target. Another example is that as discussed in [I- 451 D.ietf-nvo3-arch], a NVE may wish to query the NVA about individual 452 mapping when receiving a packet with unknown destination address. 453 This query procedure may also be triggered at ARP / ND message 454 handling or when NVE-NVE interaction message is received. An attacker 455 may take advantage of this query procedure which the NVE is used as a 456 reflector to carry out DoS / DDoS attacks towards the NVA. 458 Specifically, the attacker can concurrently send out a large amount 459 of spoofed short request messages to multiple NVO3 devices which the 460 amplification effect can be enlarged which may overwhelm the victim's 461 processing capability quickly. 463 REQ 8. The security solution of a NVO3 SHOULD be able to provide 464 different security levels of protections for the control 465 traffics and data traffics exchanged between NVO3 devices. 467 In NVE-NVE interface and NVE-Hypervisor interface, the same security 468 solution may be used to protect both the control plane and data plane 469 traffic. In many cases, the control and data traffics between NVO3 470 devices may be transported over the same path or even within the same 471 security channel. However, the control traffics and data traffics may 472 have different levels of security sensitivity. Therefore, the 473 protection on the traffic needs be distinguished. In this case, the 474 security solution may need to provide different security channels for 475 control traffics and data traffics respectively and protect the data 476 traffics and control traffics exchanged between NVO3 devices with 477 different keys and ciphers. 479 6.2. NVE-NVE Data Plane 481 As specified in [RFC7365], a NVO3 overlay needs to generate tunnels 482 between NVEs for data packet transportation. When a data packet 483 reaches the boundary of an overlay, the ingress NVE will encapsulate 484 the packet and forward it to the destination egress NVE through a 485 proper tunnel. 487 REQ 9. The security solution for NVO3 MAY enable two NVEs to 488 mutually authenticate each other before establishing a tunnel 489 for data transportation. 491 This entity authentication requirement is used to protect a NVE 492 against imposter attacks. Also, this requirement can help guarantee a 493 data tunnel is generated between two proper NVEs and reduce the risk 494 of man-in-the-middle attacks. 496 In order to protect the data packets transported over the overlay 497 against the attacks raised from the underlying network, the NVO3 498 overlay needs to provide essential security protection for data 499 packets. 501 REQ 10. The security solution of NVO3 SHOULD be able to provide 502 integrity protection, replay protection, and packet origin 503 authentication for data traffics exchanged between NVEs. 505 This requirement is used to prevent an attacker who has compromised 506 underlying network devices on the path from replaying antique packets 507 or injecting bogus data packets without being detected. 509 Such protection must be deployed if there is any possibility that the 510 data packets could be accessed by outside attackers. This protection 511 can prevent an attacker locating in the middle between the NVEs and 512 modifying the tunnel address information in the data packet header so 513 as to redirect the data traffic as wished. 515 REQ 11. The security solution of NVO3 MAY be able to provide 516 confidentiality protection for data traffics exchanged between 517 NVEs, if information leaking is a concern. 519 If TS data traffic privacy is required, the TS data traffic needs to 520 be encrypted when being transported within the overlay. In practice, 521 tenants may select end-to-end security solutions to encrypt their 522 sensitive data during transportation. Therefore this confidentiality 523 requirement for data plane is an optional requirement. 525 REQ 12. The security solution of NVO3 SHOULD be able to assign 526 different cryptographic keys to protect the unicast tunnels 527 between NVEs respectively. 529 This requirement is used to confine the damage caused by inside 530 attacks. When different tunnels secured with different keys, the 531 compromise of a key in a tunnel will not affect the security of other 532 tunnels. In addition, if the key used to protect a tunnel is only 533 shared by the NVEs on the both sides, the egress NVE receiving a data 534 packet is able to distinctively prove the identity of the ingress NVE 535 encapsulating the data packet during the message authentication. 537 REQ 13. If there are multicast packets, the security solution of 538 NVO3 SHOULD be able to assign distinct cryptographic group keys 539 to protect the multicast packets exchanged among the NVEs within 540 different multicast groups. 542 In NVO3, a NVE may need to support data plane multicast capability. 543 In order to provide an essential packet level security protection 544 (including authentication, integrity, confidentiality) for the 545 multicast packets transferred within the group, at least one group 546 key may need to be shared among the NVEs of the same multicast group. 547 It is recommended to deploy different keys for different multicast 548 groups, in order to confine the insider attacks on NVEs. 550 REQ 14. Upon receiving a data packet, an egress NVE MUST be able 551 to verify whether the packet is sent from a proper ingress NVE 552 which is authorized to forward that packet. 554 In cooperation with authentication, authorization enables an egress 555 NVE to detect the data packets which violate certain security 556 policies, even when they are forwarded from a legal NVE. For 557 instance, if the remote NVE is not authorized to forward data packet 558 of a given VN, the packet needs to be detected and discarded without 559 processing. Note that the detection of an invalid packet may not 560 indicate that the system is under a malicious attack. Mis- 561 configuration or byzantine failure of a NVE may also result in such 562 invalid packets. 564 6.3. NVE-Hypervisor Data Plane 566 As described in the NVO3 architecture draft [I-D.ietf-nvo3-arch], in 567 split-NVE scenario, a number of link types are possible between NVE 568 and hypervisor. One simple deployment scenario may have a simple L2 569 Ethernet link. A more complicated scenario may have the server and 570 NVE separated by a bridged access network, such as when the NVE 571 resides on a ToR, with an embedded switch residing between servers 572 and the ToR. 574 In any of above deployment scenarios, the data link between NVE and 575 hypervisor may be potentially accessible to attackers, e.g. with a 576 shared link. In that case, security solutions, including integrity 577 protection and confidentiality protection, may be needed to secure 578 the data link. 580 REQ 15. The security solution of NVO3 SHOULD be able to provide 581 integrity protection, replay protection and origin 582 authentication for the data packets exchanged between a NVE and 583 a hypervisor. 585 Packet level security protection can prevent an attacker from 586 illegally interfere with the normal operations of NVEs and 587 hypervisors by injecting bogus packets into the network. Because it 588 is assumed that the network connecting the NVE and the hypervisor is 589 potentially accessible to attackers, security solutions need to 590 prevent an attacker locating in the middle between the NVE and the 591 hypervisor from modifying the information in the data packet headers 592 so as to redirect the traffic as wished. 594 REQ 16. The security solution of a NVO3 network MAY provide 595 confidentiality protection for the data traffics exchanged 596 between a NVE and a hypervisor. 598 If TS data packet privacy is required, the data packet needs to be 599 encrypted. The security solution of a NVE network may need to provide 600 confidentiality for the data packets exchanged between a NVE and a 601 hypervisor if they have to use an insecure network to transport their 602 data packet. 604 REQ 17. The security solution of a NVO3 network MAY be able to 605 provide different cryptographic keys to secure the unicast data 606 traffic exchanged between different hypervisors and their NVEs 607 respectively. 609 This requirement is used to benefit the damage confinement of inside 610 attacks. For instance, data traffic may be forwarded over a shared 611 link between a NVE and a hypervisor. In that case, the compromise of 612 a hypervisor or a NVE will not be able to affect the security of data 613 traffics exchanged between different hypervisors and their NVEs. 615 REQ 18. The security solution of NVO3 MAY be able to assign 616 distinct cryptographic group keys to protect the multicast 617 traffic exchanged between different hypervisors and their NVEs 618 respectively within different multicast groups. 620 If there are multicast data traffic between hypervisors and their 621 NVE, in order to provide an essential packet level security 622 protection (including authentication, integrity, confidentiality) for 623 the multicast packets transferred within the multicast group, at 624 least one group key may need to be shared among the hypervisors and 625 their NVE of the same multicast group. It is recommended to deploy 626 different keys for different multicast groups, in order to confine 627 the insider attacks on the hypervisors and their NVE. 629 7. Candidate Techniques 631 This section introduces the techniques which can potentially be used 632 to fulfill the security requirements introduced in Section 5. 634 7.1. Entity Authentication 636 Entity authentication is normally performed as a part of automated 637 key management, and a successful authentication may result in the key 638 materials used in subsequent communications. 640 In the circumstance where no authentication protocols are applied, 641 the communicating entities could use message authentication 642 mechanisms to verify each other's identity. 644 The widely adopted protocols supporting entity authentication 645 include: IKE [RFC2409], IKEv2 [RFC4306], EAP [RFC4137], TLS [RFC5246] 646 and etc. 648 It is recommended to cryptographically verify the devices' identities 649 during authentication. Therefore, an inside attacker cannot use the 650 keys or credentials got from the compromised device to impersonate 651 other victims. 653 7.2. Packet Level Security 655 There are requirements about protecting the integrity, 656 confidentiality, and provide packet origin authentication for 657 control/ data packets. Such functions can be provided through using 658 the underlying security protocols, e.g., IPsec AH [RFC4302], IPsec 659 ESP [RFC4303], TLS [RFC5246], or MACsec [802.1AE]. Also, when 660 designing the control protocols people can select to provide embedded 661 security approaches (just like the packet level security mechanism 662 provided in OSPFv2 [RFC2328]). The cryptographic keys can be manually 663 deployed or dynamically generated by using certain automatic key 664 management protocols. Note that when using manual key management, the 665 replay protection mechanism of IPsec will be switched off. 667 7.3. Authorization 669 Without any cryptographic supports, the authorization mechanisms 670 (e.g., packet filters) could be much easier to be bypassed by 671 attackers, and thus the authorization mechanisms deployed on NVO3 672 devices should interoperate with entity authentication and other 673 packet level security mechanisms, and be able to make the access 674 control decisions based on the cryptographically proved results. 676 An exception is packet filtering. Because packet filters are 677 efficient and can effectively drop some un-authorized packets before 678 they have to be cryptographically verified, it is worthwhile to use 679 packet filters as an auxiliary approach to dealing with some simple 680 attacks and increasing the difficulties of DoS/DDoS attacks 681 targeting at the security protocol implementations. 683 For instance, a NVE may maintain an authorization NVE table. This 684 table may be distributed by a trusted entity, e.g. NVA, in 685 combination with the inner-outer address mapping table. And NVE may 686 use this table to filter the received control / data packets over 687 NVE-NVE interface. The NVE may effectively drop any packets received 688 from an unauthorized NVE before processing it, e.g. 689 cryptographically verification procedure. 691 8. IANA Considerations 693 This document makes no request of IANA. 695 Note to RFC Editor: this section may be removed on publication as an 696 RFC. 698 9. Security Considerations 700 9.1. Automated Key Management in NVO3 702 Because entity authentication and automated key distribution are 703 normally performed in the same process, the requirements of entity 704 authentication have already implied that it is recommended to use 705 automated key management in the security solutions for NVO3 networks. 706 In the cases where there are a large amount of NVEs working within a 707 NVO3 overlay, manual key management becomes infeasible. First, it 708 could be tedious to deploy pre-shared keys for thousands of NVEs, not 709 to mention that multiple keys may need to be deployed on a single 710 device for different purposes. Key derivation can be used to mitigate 711 this problem. Using key derivation functions, multiple keys for 712 different usages can be derived from a pre-shared master key. 713 However, key derivation cannot protect against the situation where a 714 system was incorrectly trusted to have the key used to perform the 715 derivation. If the master key were somehow compromised, all the 716 resulting keys would need to be changed [RFC4301]. Moreover, some 717 security protocols need the support of automated key management in 718 order to perform certain security functions properly. As mentioned 719 above, the replay protecting mechanism of IPsec will be turned off 720 without the support of automated key management mechanisms. 722 10. Acknowledgements 724 Many people have contributed to the development of this document and 725 many more will probably do so before we are done with it. While we 726 cannot thank all contributors, some have played an especially 727 prominent role. The followings have provided essential input: 728 Melinda Shore and Makan Pourzandi. 730 11. References 732 11.1. Normative References 734 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 735 Requirement Levels", BCP 14, RFC 2119, March 1997. 737 11.2. Informative References 739 [I-D.ietf-nvo3-arch] Black, D., Narten, T., et al, "An Architecture 740 for Overlay Networks (NVO3)", draft-narten-nvo3-arch, work 741 in progress. 743 [I-D.ietf-ipsecme-ad-vpn-problem] Manral, V. and S. Hanna, "Auto 744 Discovery VPN Problem Statement and Requirements", draft- 745 ietf-ipsecme-ad-vpn-problem-09 (work in progress), July 746 2013. 748 [I-D.ietf-nvo3-hpvr2nve-cp-req] Yizhou, L., Yong, L., Kreeger, L., 749 Narten, T., and D. Black, "Hypervisor to NVE Control Plane 750 Requirements", draft-ietf-nvo3-hpvr2nve-cp-req-01 (work in 751 progress), November 2014. 753 [I-D.mahalingam-dutt-dcops-vxlan] Mahalingam, M., Dutt, D., Duda, K., 754 Agarwal, P., Kreeger, L., Sridhar, T., Bursell, M., and C. 755 Wright, "VXLAN: A Framework for Overlaying Virtualized 756 Layer 2 Networks over Layer 3 Networks", draft-mahalingam- 757 dutt-dcops-vxlan-09, (work in progress), April 2014. 759 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 761 [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange 762 (IKE)", RFC 2409, November 1998. 764 [RFC4046] Baugher, M., Canetti, R., Dondeti, L., and F. Lindholm, 765 "Multicast Security (MSEC) Group Key Management 766 Architecture", RFC 4046, April 2005. 768 [RFC4137] Vollbrecht, J., Eronen, P., Petroni, N., and Y. Ohba, 769 "State Machines for Extensible Authentication Protocol 770 (EAP) Peer and Authenticator", RFC 4137, August 2005. 772 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 773 Internet Protocol", RFC 4301, December 2005. 775 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 776 2005. 778 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 779 4303, December 2005. 781 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 782 4306, December 2005. 784 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 785 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 787 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, "Internet 788 Key Exchange Protocol Version 2 (IKEv2)", RFC 5996, 789 September 2010. 791 [RFC7364] Narten, T., Gray, E., Black, D., Fang, L., Kreeger, L., and 792 M. Napierala, "Problem Statement: Overlays for Network 793 Virtualization", RFC 7364, October 2014. 795 [RFC7365] Lasserre, M., Balus, F., Morin, T., Bitar, N., and Y. 796 Rekhter, "Framework for Data Center (DC) Network 797 Virtualization", RFC 7365, October 2014. 799 [802.1AE] 802.1AE - Media Access Control (MAC) Security 801 Authors' Addresses 802 Sam Hartman 803 Painless Security 804 356 Abbott Street 805 North Andover, MA 01845 806 USA 808 Email: hartmans@painless-security.com 809 URI: http://www.painless-security.com 811 Dacheng Zhang 812 Alibaba 813 Chaoyang Dist. Beijing 815 P.R. China 816 Email: Dacheng.zdc@alibaba-inc.com 818 Margaret Wasserman 819 Painless Security 820 356 Abbott Street 821 North Andover, MA 01845 822 USA 824 Phone: +1 781 405 7464 825 Email: mrw@painless-security.com 826 URI: http://www.painless-security.com 828 Zu Qiang 829 Ericsson 830 8400 Decarie Blvd. 831 Town of Mount Royal, QC, H4P 2N2 832 Canada 834 Phone: +1 514 345 7900 x47370 835 Email: Zu.Qiang@ericsson.com 837 Mingui Zhang 838 Huawei Technologies 839 No. 156 Beiqing Rd. Haidian District, 840 Beijing 100095 842 P.R. China 843 Email: zhangmingui@huawei.com