idnits 2.17.1 draft-wei-nvo3-security-framework-01.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. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (July 16, 2012) is 4300 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC 2119' is defined on line 403, but no explicit reference was found in the text == Unused Reference: 'RFC4111' is defined on line 406, but no explicit reference was found in the text == Unused Reference: 'RFC5920' is defined on line 410, but no explicit reference was found in the text == Unused Reference: 'VM-Migration' is defined on line 417, but no explicit reference was found in the text == Unused Reference: 'I-D.narten-nvo3-overlay-problem-statement' is defined on line 421, but no explicit reference was found in the text == Unused Reference: 'I-D.fang-vpn4dc-problem-statement' is defined on line 426, but no explicit reference was found in the text == Unused Reference: 'I-D.lasserre-nvo3-framework' is defined on line 433, but no explicit reference was found in the text == Unused Reference: 'I-D.kreeger-nvo3-overlay-cp' is defined on line 438, but no explicit reference was found in the text == Unused Reference: 'I-D.bitar-lasserre-nvo3-dp-reqs' is defined on line 443, but no explicit reference was found in the text == Outdated reference: A later version (-04) exists of draft-narten-nvo3-overlay-problem-statement-02 == Outdated reference: A later version (-04) exists of draft-kreeger-nvo3-overlay-cp-00 Summary: 0 errors (**), 0 flaws (~~), 13 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NV03 Working Group Y. Wei, Ed. 3 Internet Draft ZTE Corporation 4 Intended status: Informational L. Fang, Ed. 5 Expires: January 16, 2013 Cisco Systems 6 S. Zhang 7 ZTE Corporation 9 July 16, 2012 11 NVO3 Security Framework 12 draft-wei-nvo3-security-framework-01 14 Abstract 16 This document provides a security framework for overlay based 17 network virtualization. It describes the security reference model, 18 the security threats and security requirements. 20 Status of this Memo 22 This Internet-Draft is submitted to IETF in full conformance with 23 the provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six 31 months and may be updated, replaced, or obsoleted by other documents 32 at any time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress". 35 This Internet-Draft will expire on January 16, 2013. 37 Copyright Notice 39 Copyright (c) 2012 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 NVO3 Security Framework 43 Expires Jan. 2013 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with 50 respect to this document. Code Components extracted from this 51 document must include Simplified BSD License text as described in 52 Section 4.e of the Trust Legal Provisions and are provided without 53 warranty as described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction .................................................2 58 2 59 2. Terminologies ................................................3 60 3 61 3. Security Reference Models ....................................5 62 5 63 3.1. Scenario 1: Virtual Network and DC infrastructure belong to 64 the same DC operator ............................................5 65 5 66 4. Security Threats .............................................6 67 6 68 4.1. Attacks on Control Plane ..................................7 69 7 70 4.2. Attacks on the Data Plane .................................7 71 7 72 5. Security Requirements ........................................8 73 8 74 5.1. Control Plane Security Requirements .......................8 75 8 76 5.2. Data Plane Security Requirements ..........................8 77 8 78 6. Security Considerations ......................................8 79 8 80 7. IANA Considerations ..........................................9 81 9 82 8. Normative References .........................................9 83 9 84 9. Informative References .......................................9 85 9 86 10. Author's Addresses ........................................10 87 10 89 Requirements Language 91 Although this document is not a protocol specification, the key 92 words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 93 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 94 this document are to be interpreted as described in RFC 2119 [RFC 96 1. Introduction 97 NVO3 Security Framework 98 Expires Jan. 2013 100 Security is one of most important factors in the environment of 101 cloud computing and particularly to the Data Center Network 102 Virtualization where multi-tenancy support is one of the fundamental 103 requirements. 105 Though security considerations are provided in several individual 106 documents, a general description of security for NVO3 is needed, 107 especially there are areas not covered in the current documents. 108 The motivation of this document is to provide a general and 109 consistent security framework for NVO3, and to provide a guidance 110 for the design of related protocol. 112 This document is organized as follows. Section 3 describes the 113 security reference model in the context of NVO3, which defines which 114 component is trusted or not for a particular scenario. Section 4 115 describes the security threats under the security model. Section 5 116 addresses the security requirements in response to the security 117 threats. 119 2. Terminologies 121 This document uses NVO3 specific terminology defined in [I- 122 D.lasserre-nvo3-framework]. For reader's convenience, this 123 document repeats some of the definitions in addition to reference 124 it. 126 NVE: Network Virtualization Edge. It is a network entity that sits 127 on the edge of the NVO3 network. It implements network 128 virtualization functions that allow for L2 and/or L3 tenant 129 separation and for hiding tenant addressing information (MAC and IP 130 addresses). An NVE could be implemented as part of a virtual switch 131 within a hypervisor, a physical switch or router, a Network Service 132 Appliance or even be embedded within an End Station. 134 VN: Virtual Network. This is a virtual L2 or L3 domain that belongs 135 a tenant. 137 VNI: Virtual Network Instance. This is one instance of a virtual 138 overlay network. Two Virtual Networks are isolated from one another 139 and may use overlapping addresses. 141 Virtual Network Context or VN Context: Field that is part of the 142 overlay encapsulation header which allows the encapsulated frame to 143 be delivered to the appropriate virtual network endpoint by the 144 egress NVE. The egress NVE uses this field to determine the 145 appropriate virtual network context in which to process the packet. 146 This field MAY be an explicit, unique (to the administrative 147 domain) virtual network identifier (VNID) or MAY express the 148 NVO3 Security Framework 149 Expires Jan. 2013 151 necessary context information in other ways (e.g. a locally 152 significant identifier). 154 VNID: Virtual Network Identifier. In the case where the VN context 155 has global significance, this is the ID value that is carried in 156 each data packet in the overlay encapsulation that identifies the 157 Virtual Network the packet belongs to. 159 Underlay or Underlying Network: This is the network that provides 160 the connectivity between NVEs. The Underlying Network can be 161 completely unaware of the overlay packets. Addresses within the 162 Underlying Network are also referred to as "outer addresses" 163 because they exist in the outer encapsulation. The Underlying 164 Network can use a completely different protocol (and address 165 family) from that of the overlay. 167 Data Center (DC): A physical complex housing physical servers, 168 network switches and routers, Network Service Appliances and 169 networked storage. The purpose of a Data Center is to provide 170 application and/or compute and/or storage services. One such 171 service is virtualized data center services, also known as 172 Infrastructure as a Service. 174 Virtual Data Center or Virtual DC: A container for virtualized 175 compute, storage and network services. Managed by a single tenant, 176 a Virtual DC can contain multiple VNs and multiple Tenant End 177 Systems that are connected to one or more of these VNs. 179 VM: Virtual Machine. Several Virtual Machines can share the 180 resources of a single physical computer server using the services 181 of a Hypervisor (see below definition). 183 Hypervisor: Server virtualization software running on a physical 184 compute server that hosts Virtual Machines. The hypervisor provides 185 shared compute/memory/storage and network connectivity to the VMs 186 that it hosts. Hypervisors often embed a Virtual Switch (see 187 below). 189 Virtual Switch: A function within a Hypervisor (typically 190 implemented in software) that provides similar services to a 191 physical Ethernet switch. It switches Ethernet frames between VMs' 192 virtual NICs within the same physical server, or between a VM and a 193 physical NIC card connecting the server to a physical Ethernet 194 switch. It also enforces network isolation between VMs that should 195 not communicate with each other. 197 Tenant: A customer who consumes virtualized data center services 198 offered by a cloud service provider. A single tenant may consume 199 NVO3 Security Framework 200 Expires Jan. 2013 202 one or more Virtual Data Centers hosted by the same cloud service 203 provider. 205 Tenant End System: It defines an end system of a particular tenant, 206 which can be for instance a virtual machine (VM), a non-virtualized 207 server, or a physical appliance. 209 3. Security Reference Models 211 This section defines the security reference models for Overlay 212 based Network Virtualization. 214 The L3 overlay network provides virtual network to multi-tenants, 215 which is deployed on the underlying network. The tenant end system 216 attaches to the L3 overlay network. 218 L3 overlay network provides isolation to each tenant, which 219 provides a level of security to its tenant. L3 overlay network can 220 be regarded secure zone from the view of ONV3 operator. Other 221 components outside of the ONV3 are considered as untrusted, which 222 may impose security risk to the NVO3 networks. Each virtual 223 network should assume not trusting other virtual networks. This 224 model is the basis to analyze the security of ONV3. 226 3.1. Scenario 1: Virtual Network and DC infrastructure 227 belong to the same DC operator 229 |<-----------(Trusted)---------->| 230 | | 231 | /---------------------------\ | 232 ++ Virtual Network L3 Overlay ++ 233 | \---------------------------/ | 234 +----------+ +--+------+ +-----------+ +-------+-+ +----------+ 235 |Tenant End| | NV | | DC infra | | NV | |Tenant End| 236 | System +-+ Edge +--+ Underlay +--+ Edge +-+ System | 237 | (TES) | | (NVE) | | Network | | (NVE) | | (TES) | 238 +----------+ +---------+ +-----------+ +---------+ +----------+ 239 |<---------->|<-------->|<------------>|<--------->|<---------->| 240 |(Untrusted) | (Trusted)| (Trusted) | (Trusted) |(Untrusted) | 242 Figure 1. Trust Model for Scenario 1 244 NVO3 Security Framework 245 Expires Jan. 2013 247 Notes: 249 1) The diagram is a logical illustration. The TES and NVE may be 250 implemented in the same physical device, or separate devices. 251 2) The physical end system may in reality include virtual 252 switching/routing instances and multiple VMs (TESs) belong to 253 different tenants. 254 3) The trusted or untrusted notions in the diagram is from a Virtual 255 Overlay Network point of view, not the underlay network. 256 4) Each VN treats other VNs as untrusted. 258 Scenario 2: Virtual Network and DC infrastructure belong to 259 different DC operators 261 |<-----------(Trusted)---------->| 262 | | 263 | /---------------------------\ | 264 ++ Virtual Network L3 Overlay ++ 265 | \---------------------------/ | 266 +----------+ +--+------+ +-----------+ +-------+-+ +----------+ 267 |Tenant End| | NV | | DC infra | | NV | |Tenant End| 268 | System +-+ Edge +--+ Underlay +--+ Edge +-+ System | 269 | (TES) | | (NVE) | | Network | | (NVE) | | (TES) | 270 +----------+ +---------+ +-----------+ +---------+ +----------+ 271 |<---------->|<-------->|<------------>|<--------->|<---------->| 272 |(Untrusted) | (Trusted)| (Untrusted) | (Trusted) |(Untrusted) | 274 Figure 2. Trust Model for Scenario 2 276 The same notes listed under scenario 1 also apply here. 278 4. Security Threats 280 This section describes the various security threats that may 281 endanger overlay based network virtualization. For example, an 282 attack on ONV3 may result in some unexpected effects: 284 o Interrupt the connectivity of tenant's virtual network. 285 o Inject some unwanted traffic into virtual network. 286 o Eavesdrop sensitive information from tenant. 287 o Degrade provider's service level. 289 NVO3 Security Framework 290 Expires Jan. 2013 292 Security threats may be malicious or casual. For example, some of 293 them may come from the following sources: 295 o A tenant who rents one or more virtual networks may want to 296 acquire some information from other tenants co-existed in the same 297 data center. 298 o Some persons who manipulate the activation, migration or 299 deactivation of tenant's virtual machine. 300 o Some persons who physically access to underlying network. 302 4.1. Attacks on Control Plane 304 1. Attack association between VM and VN: one of the 305 functionalities of ONV3 is to provide virtual network to multi- 306 tenants. ONV3 associates a virtual machine's NIC with corresponding 307 virtual network, and maintain that association as the VM is 308 activated, migrated or deactivated. The signaling information 309 between endpoint and access switch may be spoofed or altered. Thus 310 the association between VM and VN may be invalid if the signaling 311 is not properly protected. 313 2. Attack the mapping of a virtual network: The mapping between 314 the inner and outer addresses may be affected through altering the 315 mapping table. 317 3. Inject traffic: The comprised underlying network may inject 318 traffic into virtual network. 320 4. Attack live migration: An attacker may cause guest VMs to be 321 live migrated to the attacker's machine and gain full control over 322 guest VMs. 324 5. Denial of Service attacks against endpoint by false resource 325 advertising: for live migration initiated automatically to 326 distribute load across a number of servers, an attacker may falsely 327 advertise available resources via the control plane. By pretending 328 to have a large number of spare CPU cycles, that attacker may be 329 able to influence the control plane to migrate a VM to a 330 compromised endpoint. 332 4.2. Attacks on the Data Plane 334 1. Unauthorized snooping of data traffic: This is attack 335 results in leakage of sensitive information, attacker can sniffer 336 information from the user packets and extract their content. 338 NVO3 Security Framework 339 Expires Jan. 2013 341 2. Modification of data traffic: An attacker may modify, insert 342 or delete data packets and impersonate them as legitimate ones. 344 3. Man-in-the-Middle attack on live migration of VM: When a 345 virtual machine is migrated from one endpoint to another, the VM 346 may be intercepted and modified in the middle of the migration. 348 5. Security Requirements 350 This section describes security requirements for control plane and 351 data plane of NVO3. 353 5.1. Control Plane Security Requirements 355 1. The network infrastructure shall support mechanisms for 356 authentication and integrity protection of the control 357 plane. (1)When a protocol is used for the service auto- 358 provisioning/discovery, the information from endpoint shall 359 not be spoofed or altered. (2)When a protocol is used to 360 distribute address advertisement and tunneling information, 361 the protocol shall provide integrity protection. (3)The 362 protocol for tunnel management shall provide integrity and 363 authentication protection. 364 2. NVEs shall assure the information in the mapping table is 365 coming from a trusted source. 366 3. The virtual network should prevent malformed traffic 367 injection from underlying network, other virtual network, or 368 endpoint. 370 5.2. Data Plane Security Requirements 372 1. The mapping function from the tenant to overlay shall be 373 protected. NVEs should verify VNID is not spoofed. 374 2. The data plane should protect VM's state against snooping 375 and tampering. 376 3. IPsec can be used to provide authentication, integrity and 377 confidentiality protection. IPsec can be used to protect 378 the data plane. 380 6. Security Considerations 381 NVO3 Security Framework 382 Expires Jan. 2013 384 This document discusses general security threats and requirements 385 for NVO3. Individual document may raise specific issues based on the 386 particular content and should address them in the individual 387 document. 389 7. IANA Considerations 391 This document contains no new IANA considerations. 393 8. Normative References 395 9. Informative References 397 [Editors' note: All Network Virtualization with Layer 3 (NVO3) 398 Internet drafts or related ID(s) referenced in the following list 399 are currently work in progress individual drafts in their early 400 development stage, status and text are subject to change, more 401 reference may be added along with the development of the NVO3 WG.] 403 [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate 404 Requirement Levels", BCP 14, RFC 2119, March 1997. 406 [RFC4111] Fang, L., Fang, L., Ed., "Security Framework for 407 Provider-Provisioned Virtual Private Networks (PPVPNs)", RFC 4111, 408 July 2005. 410 [RFC5920] Fang, L., "Security Framework for MPLS and GMPLS 411 Networks", RFC 5920, July 2010. 413 [opsec-efforts] Lonvick, C., and Spak, D., "Security Best Practices 414 Efforts and Documents", IETF draft-ietf-opsec-efforts-18.txt, April 415 2012. 417 [VM-Migration] Oberheide, Jon., Cooke, Evan., and Farnam. Jahanian, 418 "Empirical Exploitation of Live Virtual Machine Migration", Feb 419 2011. 421 [I-D.narten-nvo3-overlay-problem-statement] Narten, T., Sridhavan, 422 M., Dutt, D., Black, D., and L. Kreeger, "Problem Statement: 423 Overlays for Network Virtualization", draft-narten-nvo3-overlay- 424 problem-statement-02 (work in progress), June 2012. 426 [I-D.fang-vpn4dc-problem-statement] Napierala M., Fang L., Cai, 427 Dennis, "IP-VPN Data Center Problem Statement and Requirements", 428 draft-fang-vpn4dc-problem-statement-01.txt, June 2012. 430 NVO3 Security Framework 431 Expires Jan. 2013 433 [I-D.lasserre-nvo3-framework] Lasserre, M., Balus, F., Morin, T., 434 Bitar, N., and Y.Rekhter, "Framework for DC Network 435 Virtualization", draft-lasserre-nvo3-framework-03 (work in 436 progress), July 2012. 438 [I-D.kreeger-nvo3-overlay-cp] Black, D., Dutt, D., Kreeger, L., 439 Sridhavan, M., and T. Narten, "Network Virtualization Overlay 440 Control Protocol Requirements", draft-kreeger-nvo3-overlay-cp-00 441 (work in progress), January 2012. 443 [I-D.bitar-lasserre-nvo3-dp-reqs] Bitar, N., Lasserre, M., and F. 444 Balus, "NVO3 Data Plane Requirements", draft-bitar-lasserre-nvo3- 445 dp-reqs-00 (work in progress), May 2012. 447 10. Author's Addresses 449 Yinxing Wei (Editor) 450 ZTE Corporation 451 No 68, Zijinghua Road 452 Nanjing, Jiangsu 210012 453 China 455 Phone: +86 25 52872328 456 Email: wei.yinxing@zte.com.cn 458 Luyuan Fang (Editor) 459 Cisco Systems, Inc. 460 111 Wood Ave. South 461 Iselin, NJ 08830 462 USA 463 Email: lufang@cisco.com 465 Shiwei Zhang 466 ZTE Corporation 467 No 68, Zijinghua Road 468 Nanjing, Jiangsu 210012 469 China 471 Phone: +86 25 52870100 472 Email: zhang.shiwei@zte.com.cn