idnits 2.17.1 draft-kreeger-nvo3-overlay-cp-02.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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 22, 2012) is 4197 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'I-D.kreeger-nvo3-hypervisor-nve-cp-req' is mentioned on line 101, but not defined == Outdated reference: A later version (-09) exists of draft-ietf-nvo3-framework-01 == Outdated reference: A later version (-04) exists of draft-ietf-nvo3-overlay-problem-statement-00 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force L. Kreeger 3 Internet-Draft Cisco 4 Intended status: Informational D. Dutt 5 Expires: April 25, 2013 Cumulus Networks 6 T. Narten 7 IBM 8 D. Black 9 EMC 10 M. Sridharan 11 Microsoft 12 October 22, 2012 14 Network Virtualization Overlay Control Protocol Requirements 15 draft-kreeger-nvo3-overlay-cp-02 17 Abstract 19 The document "Problem Statement: Overlays for Network Virtualization" 20 discusses the needs for network virtualization using overlay networks 21 in highly virtualized data centers. The problem statement outlines a 22 need for control protocols to facilitate running these overlay 23 networks. This document outlines the high level requirements to be 24 fulfilled by the control protocols related to building and managing 25 the mapping tables and other state information used by the Network 26 Virtualization Edge to transmit encapsulated packets across the 27 underlying network. 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 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is 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 April 25, 2013. 46 Copyright Notice 48 Copyright (c) 2012 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. Control Plane Protocol Functionality . . . . . . . . . . . . . 4 66 3.1. Inner to Outer Address Mapping . . . . . . . . . . . . . . 6 67 3.2. Underlying Network Multi-Destination Delivery 68 Address(es) . . . . . . . . . . . . . . . . . . . . . . . 6 69 3.3. VN Connect/Disconnect Notification . . . . . . . . . . . . 7 70 3.4. VN Name to VN ID Mapping . . . . . . . . . . . . . . . . . 7 71 4. Control Plane Characteristics . . . . . . . . . . . . . . . . 7 72 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 73 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 74 7. Informative References . . . . . . . . . . . . . . . . . . . . 10 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 77 1. Introduction 79 "Problem Statement: Overlays for Network Virtualization" 80 [I-D.ietf-nvo3-overlay-problem-statement] discusses the needs for 81 network virtualization using overlay networks in highly virtualized 82 data centers and provides a general motivation for building such 83 networks. "Framework for DC Network Virtualization" 84 [I-D.ietf-nvo3-framework] provides a framework for discussing overlay 85 networks generally and the various components that must work together 86 in building such systems. The reader is assumed to be familiar with 87 both documents. 89 Section 4.5 of [I-D.ietf-nvo3-overlay-problem-statement] describes 90 three separate work areas that fall under the general category of a 91 control protocol for NVO3. This document focuses entirely on those 92 aspects of the control protocol related to the building and 93 distributing the mapping tables an NVE uses to tunnel traffic from 94 one VM to another. Specifically, this document focuses on work areas 95 1 and 2 given in Section 3.5 of 96 [I-D.ietf-nvo3-overlay-problem-statement]. Work areas 1 and 2 cover 97 the interaction between an NVE and the "oracle" (work area 1) or 98 operation of the oracle itself (work area 2). Requirements related 99 to interaction between a hypervisor and NVE when the two entities 100 reside on separate physical devices (work area 3) are covered in 101 [I-D.kreeger-nvo3-hypervisor-nve-cp-req]. 103 2. Terminology 105 This document uses the same terminology as found in 106 [I-D.ietf-nvo3-framework]. This section defines additional 107 terminology used by this document. 109 Network Service Appliance: A stand-alone physical device or a 110 virtual device that provides a network service, such as a 111 firewall, load balancer, etc. Such appliances may embed Network 112 Virtualization Edge (NVE) functionality within them in order to 113 more efficiently operate as part of a virtualized network. 115 VN Alias: A string name for a VN as used by administrators and 116 customers to name a specific VN. A VN Alias is a human-usable 117 string that can be listed in contracts, customer forms, email, 118 configuration files, etc. and that can be communicated easily 119 vocally (e.g., over the phone). A VN Name is independent of the 120 underlying technology used to implement a VN and will generally 121 not be carried in protocol fields of control protocols used in 122 virtual networks. Rather, a VN Alias will be mapped into a VN 123 Name where precision is required. 125 VN Name: A globally unique identifier for a VN suitable for use 126 within network protocols. A VN Name will usually be paired with a 127 VN Alias, with the VN Alias used by humans as a shorthand way to 128 name and identify a specific VN. A VN Name should have a compact 129 representation to minimize protocol overhead where a VN Name is 130 carried in a protocol field. Using a Universally Unique 131 Identifier (UUID) as discussed in RFC 4122, may work well because 132 it is both compact and a fixed size and can be generated locally 133 with a very high likelihood of global uniqueness. 135 VN ID: A unique and compact identifier for a VN within the scope of 136 a specific NVO3 administrative domain. It will generally be more 137 efficient to carry VN IDs as fields in control protocols than VN 138 Aliases. There is a one-to-one mapping between a VN Name and a VN 139 ID within an NVO3 Administrative Domain. Depending on the 140 technology used to implement an overlay network, the VN ID could 141 be used as the VN Context in the data plane, or would need to be 142 mapped to a locally-significant context ID. 144 3. Control Plane Protocol Functionality 146 The NVO3 problem statement [I-D.ietf-nvo3-overlay-problem-statement], 147 discusses the needs for a control plane protocol (or protocols) to 148 populate each NVE with the state needed to perform its functions. 150 In one common scenario, an NVE provides overlay encapsulation/ 151 decapsulation packet forwarding services to Tenant Systems that are 152 co-resident with the NVE on the same End Device (e.g. when the NVE is 153 embedded within a hypervisor or a Network Service Appliance). 154 Alternatively, a Tenant System may use an externally connected NVE 155 (e.g. an NVE residing on a physical Network Switch connected to the 156 hypervisor via an access network). The latter scenario is not 157 discussed in this document, but is covered in [I-D.kreeger-nvo3- 158 hypervisor-nve-cp-req]. 160 The following figures show examples of scenarios in which the NVE is 161 co-resident within the same End Device as the Tenant System connected 162 to a given VN. 164 Hypervisor 165 +-----------------------+ 166 | +--+ +-------+---+ | 167 | |VM|---| | | | 168 | +--+ |Virtual|NVE|----- Underlying 169 | +--+ |Switch | | | Network 170 | |VM|---| | | | 171 | +--+ +-------+---+ | 172 +-----------------------+ 174 Hypervisor with an Embedded NVE. 176 Figure 1 178 Network Service Appliance 179 +---------------------------+ 180 | +------------+ +-----+ | 181 | |Net Service |---| | | 182 | |Instance | | | | 183 | +------------+ | NVE |------ Underlying 184 | +------------+ | | | Network 185 | |Net Service |---| | | 186 | |Instance | | | | 187 | +------------+ +-----+ | 188 +---------------------------+ 190 Network Service Appliance (physical or virtual) with an Embedded NVE. 192 Figure 2 194 To support an NVE, a control plane protocol is necessary to provide 195 an NVE with the information it needs to maintain its own internal 196 state necessary to carry out its forwarding functions as explained in 197 detail below. 199 1. An NVE maintains a per-VN table of mappings from Tenant System 200 (inner) addresses to Underlying Network (outer) addresses of 201 remote NVEs. 203 2. An NVE maintains per-VN state for delivering tenant multicast and 204 broadcast packets to other Tenant Systems. Such state could 205 include a list of multicast addresses and/or unicast addresses on 206 the Underlying Network for the NVEs associated with a particular 207 VN. 209 3. End Devices (such as a Hypervisor or Network Service Appliance) 210 utilizing an external NVE need to "attach to" and "detach from" 211 an NVE. Specifically, a mechanism is needed to notify an NVE 212 when a Tenant System attaches to or detaches from a specific VN. 213 Such a mechanism would provide the necessary information to the 214 NVE that it needs to provide service to a particular Tenant 215 System. The details of such a mechanism are out-of-scope for 216 this document and are covered in [I-D.kreeger-nvo3-hypervisor- 217 nve-cp-req]. 219 4. An NVE needs a mapping from each unique VN name to the VN Context 220 value used within encapsulated data packets within the 221 administrative domain that the VN is instantiated. 223 3.1. Inner to Outer Address Mapping 225 When presented with a data packet to forward to a Tenant System 226 within a VN, the NVE needs to know the mapping of the Tenant System 227 destination (inner) address to the (outer) address on the Underlying 228 Network of the remote NVE which can deliver the packet to the 229 destination Tenant System. In addition, the NVE needs to know what 230 VN Context to use when sending to a destination Tenant System. 232 A protocol is needed to provide this inner to outer mapping and VN 233 Context to each NVE that requires it and keep the mapping updated in 234 a timely manner. Timely updates are important for maintaining 235 connectivity between Tenant Systems when one Tenant System is a VM. 237 Note that one technique that could be used to create this mapping 238 without the need for a control protocol is via data plane learning; 239 However, the learning approach requires packets to be flooded to all 240 NVEs participating in the VN when no mapping exists. One goal of 241 using a control protocol is to eliminate this flooding. 243 3.2. Underlying Network Multi-Destination Delivery Address(es) 245 Each NVE needs a way to deliver multi-destination packets (i.e. 246 tenant broadcast/multicast) within a given VN to each remote NVE 247 which has a destination Tenant System for these packets. Three 248 possible ways of accomplishing this are: 250 o Use the multicast capabilities of the Underlying Network. 252 o Have each NVE replicate the packets and send a copy across the 253 Underlying Network to each remote NVE currently participating in 254 the VN. 256 o Use one or more distribution servers that replicate the packets on 257 the behalf of the NVEs. 259 Whichever method is used, a protocol is needed to provide on a per VN 260 basis, one or more multicast addresses (assuming the Underlying 261 Network supports multicast), and/or one or more unicast addresses of 262 either the remote NVEs which are not multicast reachable, or of one 263 or more distribution servers for the VN. 265 The protocol must also keep the list of addresses up to date in a 266 timely manner as the set of NVEs for a given VN changes over time. 267 For example, the set of NVEs for a VN could change as VMs power on/ 268 off or migrate to different hypervisors. 270 3.3. VN Connect/Disconnect Notification 272 For the purposes of this document, it is assumed that an NVE receives 273 appropriate notifications when a Tenant System attaches to or 274 detaches from a specific VN. The details of how that is done are 275 orthogonal to the NVE-to-oracle control plane, so long as such 276 notification provides the necessary information needed by the control 277 plane. As one example, the attach/detach notification would 278 presumably include a VN Name that identifies the specific VN to which 279 the attach/detach operation applies to. 281 3.4. VN Name to VN ID Mapping 283 Once an NVE (embedded or external) receives a VN connect indication 284 with a specified VN Name, the NVE must determine what VN Context 285 value and other necessary information to use to forward Tenant System 286 traffic to remote NVEs. In one approach, the NVE-to-oracle protocol 287 uses VN Names directly when interacting, with the oracle providing 288 such information as the VN Context (or VN ID) along with egress NVE's 289 address. Alternatively, it may be desirable for the NVE-to-oracle 290 protocol to use a more compact representation of the VN name, that 291 is, a VN ID. In such a case, a specific NVE-to-oracle operation 292 might be needed to first map the VN Name into a VN ID, with 293 subsequent NVE-to-oracle operations utilizing the VN ID directly. 294 Thus, it may be useful for the NVE-to-oracle protocol to support an 295 operation that maps VN Names into VN IDs. 297 4. Control Plane Characteristics 299 NVEs are expected to be implemented within both hypervisors (or 300 Network Service Appliances) and within access switches. Any 301 resources used by these protocols (e.g. processing or memory) takes 302 away resources that could be better used by these devices to perform 303 their intended functions (e.g. providing resources for hosted VMs). 305 A large scale data center may contain hundreds of thousands of these 306 NVEs (which may be several independent implementations); Therefore, 307 any savings in per-NVE resources can be multiplied hundreds of 308 thousands of times. 310 Given this, the control plane protocol(s) implemented by NVEs to 311 provide the functionality discussed above should have the below 312 characteristics. 314 1. Minimize the amount of state needed to be stored on each NVE. 315 The NVE should only be required to cache state that it is 316 actively using, and be able to discard any cached state when it 317 is no longer required. For example, an NVE should only need to 318 maintain an inner-to-outer address mapping for destinations to 319 which it is actively sending traffic as opposed to maintaining 320 mappings for all possible destinations. 322 2. Fast acquisition of needed state. For example, when a Tenant 323 System emits a packet destined to an inner address that the NVE 324 does not have a mapping for, the NVE should be able to acquire 325 the needed mapping quickly. 327 3. Fast detection/update of stale cached state information. This 328 only applies if the cached state is actually being used. For 329 example, when a VM moves such that it is connected to a 330 different NVE, the inner to outer mapping for this VM's address 331 that is cached on other NVEs must be updated in a timely manner 332 (if they are actively in use). If the update is not timely, the 333 NVEs will forward data to the wrong NVE until it is updated. 335 4. Minimize processing overhead. This means that an NVE should 336 only be required to perform protocol processing directly related 337 to maintaining state for the Tenant Systems it is actively 338 communicating with. This requirement is for the NVE 339 functionality only. The network node that contains the NVE may 340 be involved in other functionality for the underlying network 341 that maintains connectivity that the NVE is not actively using 342 (e.g., routing and multicast distribution protocols for the 343 underlying network). 345 5. Highly scalable. This means scaling to hundreds of thousands of 346 NVEs and several million VNs within a single administrative 347 domain. As the number of NVEs and/or VNs within a data center 348 grows, the protocol overhead at any one NVE should not increase 349 significantly. 351 6. Minimize the complexity of the implementation. This argues for 352 using the least number of protocols to achieve all the 353 functionality listed above. Ideally a single protocol should be 354 able to be used. The less complex the protocol is on the NVE, 355 the more likely interoperable implementations will be created in 356 a timely manner. 358 7. Extensible. The protocol should easily accommodate extension to 359 meet related future requirements. For example, access control 360 or QoS policies, or new address families for either inner or 361 outer addresses should be easy to add while maintaining 362 interoperability with NVEs running older versions. 364 8. Simple protocol configuration. A minimal amount of 365 configuration should be required for a new NVE to be 366 provisioned. Existing NVEs should not require any configuration 367 changes when a new NVE is provisioned. Ideally NVEs should be 368 able to auto configure themselves. 370 9. Do not rely on IP Multicast in the Underlying Network. Many 371 data centers do not have IP multicast routing enabled. If the 372 Underlying Network is an IP network, the protocol should allow 373 for, but not require the presence of IP multicast services 374 within the data center. 376 10. Flexible mapping sources. It should be possible for either NVEs 377 themselves, or other third party entities (e.g. data center 378 management or orchestration systems) to create inner to outer 379 address mappings in the oracle. The protocol should allow for 380 mappings created by an NVE to be automatically removed from all 381 other NVEs if it fails or is brought down unexpectedly. 383 11. Secure. See the Security Considerations section below. 385 5. Security Considerations 387 Editor's Note: This is an initial start on the security 388 considerations section; it will need to be expanded, and suggestions 389 for material to add are welcome. 391 The protocol(s) should protect the integrity of the mapping against 392 both off-path and on-path attacks. It should authenticate the 393 systems that are creating mappings, and rely on light weight security 394 mechanisms to minimize the impact on scalability and allow for simple 395 configuration. 397 Use of an overlay exposes virtual networks to attacks on the 398 underlying network beyond attacks on the control protocol that is the 399 subject of this draft. In addition to the directly applicable 400 security considerations for the networks involved, the use of an 401 overlay enables attacks on encapsulated virtual networks via the 402 underlying network. Examples of such attacks include traffic 403 injection into a virtual network via injection of encapsulated 404 traffic into the underlying network and modifying underlying network 405 traffic to forward traffic among virtual networks that should have no 406 connectivity. The control protocol should provide functionality to 407 help counter some of these attacks, e.g., distribution of NVE access 408 control lists for each virtual network to enable packets from non- 409 participating NVEs to be discarded, but the primary security measures 410 for the underlying network need to be applied to the underlying 411 network. For example, if the underlying network includes 412 connectivity across the public Internet, use of secure gateways 413 (e.g., based on IPsec [RFC4301]) may be appropriate. 415 The inner to outer address mappings used for forwarding data towards 416 a remote NVE could also be used to filter incoming traffic to ensure 417 the inner address sourced packet came from the correct NVE source 418 address, allowing access control to discard traffic that does not 419 originate from the correct NVE. This destination filtering 420 functionality should be optional to use. 422 6. Acknowledgements 424 Thanks to the following people for reviewing and providing feedback: 425 Fabio Maino, Victor Moreno, Ajit Sanzgiri, Chris Wright. 427 7. Informative References 429 [I-D.ietf-nvo3-framework] 430 Lasserre, M., Balus, F., Morin, T., Bitar, N., and Y. 431 Rekhter, "Framework for DC Network Virtualization", 432 draft-ietf-nvo3-framework-01 (work in progress), 433 October 2012. 435 [I-D.ietf-nvo3-overlay-problem-statement] 436 Narten, T., Black, D., Dutt, D., Fang, L., Gray, E., 437 Kreeger, L., Napierala, M., and M. Sridhavan, "Problem 438 Statement: Overlays for Network Virtualization", 439 draft-ietf-nvo3-overlay-problem-statement-00 (work in 440 progress), September 2012. 442 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 443 Internet Protocol", RFC 4301, December 2005. 445 Authors' Addresses 447 Lawrence Kreeger 448 Cisco 450 Email: kreeger@cisco.com 452 Dinesh Dutt 453 Cumulus Networks 455 Email: ddutt@cumulusnetworks.com 457 Thomas Narten 458 IBM 460 Email: narten@us.ibm.com 462 David Black 463 EMC 465 Email: david.black@emc.com 467 Murari Sridharan 468 Microsoft 470 Email: muraris@microsoft.com