idnits 2.17.1 draft-ietf-sfc-problem-statement-13.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 date (February 19, 2015) is 3346 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Quinn, Ed. 3 Internet-Draft Cisco Systems, Inc. 4 Intended status: Informational T. Nadeau, Ed. 5 Expires: August 23, 2015 Brocade 6 February 19, 2015 8 Service Function Chaining Problem Statement 9 draft-ietf-sfc-problem-statement-13.txt 11 Abstract 13 This document provides an overview of the issues associated with the 14 deployment of service functions (such as firewalls, load balancers, 15 etc.) in large-scale environments. The term service function 16 chaining is used to describe the definition and instantiation of an 17 ordered list of instances of such service functions, and the 18 subsequent "steering" of traffic flows through those service 19 functions. 21 The set of enabled service function chains reflect operator service 22 offerings and is designed in conjunction with application delivery 23 and service and network policy. 25 This document also identifies several key areas that the SFC working 26 group will investigate to guide its architectural and protocol work 27 and associated drafts. 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 August 23, 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 1.1. Definition of Terms . . . . . . . . . . . . . . . . . . . 3 65 2. Problem Space . . . . . . . . . . . . . . . . . . . . . . . . 6 66 2.1. Topological Dependencies . . . . . . . . . . . . . . . . . 6 67 2.2. Configuration complexity . . . . . . . . . . . . . . . . . 7 68 2.3. Constrained High Availability . . . . . . . . . . . . . . 7 69 2.4. Consistent Ordering of Service Functions . . . . . . . . . 7 70 2.5. Application of Service Policy . . . . . . . . . . . . . . 7 71 2.6. Transport Dependence . . . . . . . . . . . . . . . . . . . 8 72 2.7. Elastic Service Delivery . . . . . . . . . . . . . . . . . 8 73 2.8. Traffic Selection Criteria . . . . . . . . . . . . . . . . 8 74 2.9. Limited End-to-End Service Visibility . . . . . . . . . . 8 75 2.10. Per-Service Function (re)Classification . . . . . . . . . 8 76 2.11. Symmetric Traffic Flows . . . . . . . . . . . . . . . . . 9 77 2.12. Multi-vendor Service Functions . . . . . . . . . . . . . . 9 78 3. Service Function Chaining . . . . . . . . . . . . . . . . . . 10 79 3.1. Service Overlay . . . . . . . . . . . . . . . . . . . . . 10 80 3.2. Service Classification . . . . . . . . . . . . . . . . . . 10 81 3.3. SFC Encapsulation . . . . . . . . . . . . . . . . . . . . 10 82 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 83 5. Security Considerations . . . . . . . . . . . . . . . . . . . 13 84 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 15 85 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 86 8. Informative References . . . . . . . . . . . . . . . . . . . . 18 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 89 1. Introduction 91 The delivery of end-to-end services often require various service 92 functions including traditional network service functions (for 93 example firewalls and server load balancers), as well as application- 94 specific features such as http header manipulation. Service 95 functions may be delivered within the context of an isolated user 96 (e.g. a tenant), or shared amongst many users/user groups. 98 Current service function deployment models are often tightly coupled 99 to network topology and physical resources resulting in relatively 100 rigid and static deployments. The static nature of such deployments 101 greatly reduces, and in many cases, limits the ability of an operator 102 to introduce new or modify existing services and/or service 103 functions. Furthermore there is a cascading effect: changing one (or 104 more) elements of a service function chain often affects other 105 elements in the chain and/or the network elements used to construct 106 the chain. 108 This issue is particular acute in elastic service environments that 109 require relatively rapid creation, destruction or movement of 110 physical or virtual service functions or network elements. 111 Additionally, the transition to virtual platforms requires an agile 112 service insertion model that supports elastic and very granular 113 service delivery, post-facto modification and the movement of service 114 functions and application workloads in the existing network. The 115 service insertion model must also retain the network and service 116 policies and the ability to easily bind service policy to granular 117 information such as per-subscriber state. 119 This document outlines the problems encountered with existing service 120 deployment models for Service Function Chaining (SFC) (often referred 121 to simply as service chaining (in this document the terms will be 122 used interchangeably), as well as the problems of service chain 123 creation, deletion, modification/update, policy integration with 124 service chains, and policy enforcement within the network 125 infrastructure. The document highlights three key areas of WG focus 126 for addressing the issues highlighted in this draft that will form 127 the basis for the possible WG solutions that address the current 128 problems. 130 1.1. Definition of Terms 132 Classification: Locally instantiated matching of traffic flows 133 against policy for subsequent application of the required set of 134 network service functions. The policy may be customer/network/ 135 service specific. 137 Network Overlay: A logical network built, via virtual links or 138 packet encapsulation, over an existing network (the underlay). 140 Network Service: An offering provided by an operator that is 141 delivered using one or more service functions. This may also be 142 referred to as a composite service. The term "service" is used to 143 denote a "network service" in the context of this document. 145 Note: Beyond this document, the term "service" is overloaded with 146 varying definitions. For example, to some a service is an 147 offering composed of several elements within the operator's 148 network, whereas for others a service, or more specifically a 149 network service, is a discrete element such as a "firewall". 150 Traditionally, such services (in the latter sense) host a set of 151 service functions and have a network locator where the service is 152 hosted. 154 Service Function: A function that is responsible for specific 155 treatment of received packets. A Service Function can act at 156 various layers of a protocol stack (e.g., at the network layer or 157 other OSI layers). As a logical component, a Service Function can 158 be realized as a virtual element or be embedded in a physical 159 network element. One or more Service Functions can be embedded in 160 the same network element. Multiple occurrences of the Service 161 Function can exist in the same administrative domain. 163 A non-exhaustive list of service functions includes: firewalls, 164 WAN and application acceleration, Deep Packet Inspection (DPI), 165 server load balancers, NAT44 [RFC3022], NAT64 [RFC6146], HTTP 166 Header Enrichment functions, TCP optimizer. 168 The generic term "L4-L7 services" is often used to describe many 169 service functions. 171 Service Function Chain (SFC): A service function chain defines an 172 ordered or partially ordered set of abstract service functions 173 (SFs) and ordering constraints that must be applied to packets 174 and/or frames and/or flows selected as a result of classification. 175 An example of an abstract service function is "a firewall". The 176 implied order may not be a linear progression as the architecture 177 allows for SFCs that copy to more than one branch, and also allows 178 for cases where there is flexibility in the order in which service 179 functions need to be applied. The term service chain is often 180 used as shorthand for service function chain. 182 Service Overlay: An overlay network created for the purpose of 183 forwarding data to required service functions. 185 Service Topology: The service overlay connectivity forms a service 186 topology. 188 2. Problem Space 190 The following points describe aspects of existing service deployments 191 that are problematic, and that the Service Function Chaining (SFC) 192 working group aims to address. 194 2.1. Topological Dependencies 196 Network service deployments are often coupled to network topology, 197 whether it be physical or virtualized, or a hybrid of the two. For 198 example, use of a firewall requires that traffic flow through the 199 firewall, which require means placing the firewall on the network 200 path (often via creation of VLANs), or architecting the network 201 topology to steer traffic through the firewall. Such dependency 202 imposes constraints on service delivery, potentially inhibiting the 203 network operator from optimally utilizing service resources, and 204 reduces flexibility. This limits scale, capacity, and redundancy 205 across network resources. 207 These topologies serve only to "insert" the service function (i.e., 208 ensure that traffic traverses a service function); they are not 209 required from a native packet delivery perspective. For example, 210 firewalls often require an "in" and "out" layer-2 segment and adding 211 a new firewall requires changing the topology (i.e., adding new 212 layer-2 segments and/or IP subnets). 214 As more service functions are required - often with strict ordering - 215 topology changes are needed in "front" and "behind" each service 216 function resulting in complex network changes and device 217 configuration. In such topologies, all traffic, whether a service 218 function needs to be applied or not, often passes through the same 219 strict order. 221 The topological coupling limits placement and selection of service 222 functions: service functions are "fixed" in place by topology and 223 therefore placement and service function selection taking into 224 account network topology information such as load, new links, or 225 traffic engineering is often not possible. 227 A common example is web servers using a server load balancer as the 228 default gateway. When the web service responds to non-load balanced 229 traffic (e.g., administrative or backup operations) all traffic from 230 the server must traverse the load balancer forcing network 231 administrators to create complex routing schemes or create additional 232 interfaces to provide an alternate topology. 234 2.2. Configuration complexity 236 A direct consequence of topological dependencies is the complexity of 237 the entire configuration, specifically in deploying service function 238 chains. Simple actions such as changing the order of the service 239 functions in a service function chain require changes to the logical 240 and/or physical topology. However, network operators are hesitant to 241 make changes to the network once services are installed, configured 242 and deployed in production environments for fear of misconfiguration 243 and consequent downtime. All of this leads to very static service 244 delivery deployments. Furthermore, the speed at which these 245 topological changes can be made is not rapid or dynamic enough as it 246 often requires manual intervention, or use of slow provisioning 247 systems. 249 2.3. Constrained High Availability 251 Since traffic reaches many service functions based on network 252 topology, alternate, or redundant service functions must be placed in 253 the same topology as the primary service. 255 An effect of topological dependency is constrained service function 256 high availability. Worse, when modified, inadvertent non-high 257 availability or downtime can result. 259 2.4. Consistent Ordering of Service Functions 261 Service functions are typically independent; service function_1 262 (SF1)...service function_n (SFn) are unrelated and there is no notion 263 at the service layer that SF1 occurs before SF2. However, to an 264 administrator many service functions have a strict ordering that must 265 be in place, yet the administrator has no consistent way to impose 266 and verify the ordering of the service functions that are used to 267 deliver a given service. Furthermore, altering the order of a 268 deployed chain is complex and cumbersome. 270 2.5. Application of Service Policy 272 Service functions rely on topology information such as VLANs or 273 packet (re)classification to determine service policy selection, 274 i.e., the service function specific action taken. Topology 275 information is increasingly less viable due to scaling, tenancy and 276 complexity reasons. Topology-centric information often does not 277 convey adequate information to the service functions, forcing 278 functions to individually perform more granular classification. In 279 other words, the topology information is not granular enough, and its 280 semantics often overloaded. 282 2.6. Transport Dependence 284 Service functions can and will be deployed in networks with a range 285 of network transports, including network under and overlays, such as 286 Ethernet, GRE, VXLAN, MPLS, etc. The coupling of service functions 287 to topology may require service functions to support many transport 288 encapsulations or for a transport gateway function to be present. 290 2.7. Elastic Service Delivery 292 Given that the current state of the art for adding/removing service 293 functions largely centers around VLANs and routing changes, rapid 294 changes to the deployed service capacity (increasing or decreasing) 295 can be hard to realize due to the risk and complexity of VLANs and/or 296 routing modifications. 298 2.8. Traffic Selection Criteria 300 Traffic selection is coarse, that is, all traffic on a particular 301 segment traverses all service functions whether the traffic requires 302 service enforcement or not. This lack of traffic selection is 303 largely due to the topological nature of service deployment since the 304 forwarding topology dictates how (and what) data traverses which 305 service function(s). In some deployments, more granular traffic 306 selection is achieved using policy routing or access control 307 filtering. This results in operationally complex configurations and 308 is still relatively coarse and inflexible. 310 2.9. Limited End-to-End Service Visibility 312 Troubleshooting service related issues is a complex process that 313 involve both network-specific and service-specific expertise. This 314 is especially the case when service function chains span multiple 315 DCs, or across administrative boundaries. Furthermore, the physical 316 and virtual environments (network and service), can be highly 317 divergent in terms of topology and that topological variance adds to 318 these challenges. 320 2.10. Per-Service Function (re)Classification 322 Classification occurs at each service function independent from 323 previously applied service functions since there are limited 324 mechanisms to share the detailed classification information between 325 services. The classification functionality often differs between 326 service functions, and service functions may not leverage the 327 classification results from other service functions. 329 2.11. Symmetric Traffic Flows 331 Service function chains may be unidirectional or bidirectional 332 depending on the state requirements of the service functions. In a 333 unidirectional chain traffic is passed through a set of service 334 functions in one forwarding direction only. Bidirectional chains 335 require traffic to be passed through a set of service functions in 336 both forwarding directions. Many common service functions such as 337 DPI and firewall often require bidirectional chaining in order to 338 ensure flow state is consistent. 340 Existing service deployment models provide a static approach to 341 realizing forward and reverse service function chain association most 342 often requiring complex configuration of each network device 343 throughout the SFC. In other words, the same complex network 344 configuration must be in place for both "directions" of the traffic, 345 effectively doubling the configuration and associated testing. 346 Further, if partial symmetry is required (i.e. only some of the 347 services in the chain required symmetry), the network configuration 348 complexity increases since the operator must ensure that the 349 exceptions -- the services that do not need the symmetry flow -- are 350 handled correctly via unique configuration to account for their 351 requirements. 353 2.12. Multi-vendor Service Functions 355 Deploying service functions from multiple vendors often require per- 356 vendor expertise: insertion models differ, there are limited common 357 attributes and inter-vendor service functions do not share 358 information, hence the need for standards to ensure interoperability. 360 3. Service Function Chaining 362 Service Function Chaining aims to address the aforementioned problems 363 associated with service deployment. Concretely, the SFC working 364 group will investigate solutions that address the following elements: 366 3.1. Service Overlay 368 Service function chaining utilizes a service specific overlay that 369 creates the service topology. The service overlay provides service 370 function connectivity, built "on top" of the existing network 371 topology and allows operators to use whatever overlay or underlay 372 they prefer to create a path between service functions, and to locate 373 service functions in the network as needed. 375 Within the service topology, service functions can be viewed as 376 resources for consumption and an arbitrary topology constructed to 377 connect those resources in a required order. Adding new service 378 functions to the topology is easily accomplished, and no underlying 379 network changes are required. 381 Lastly, the service overlay can provide service specific information 382 needed for troubleshooting service related issues. 384 3.2. Service Classification 386 Classification is used to select which traffic enters a service 387 overlay. The granularity of the classification varies based on 388 device capabilities, customer requirements, and services offered. 389 Initial classification determines the service function chain required 390 to process the traffic. Subsequent classification can be used within 391 a given service function chain to alter the sequence of service 392 functions applied. Symmetric classification ensures that forward and 393 reverse chains are in place. Similarly, asymmetric -- relative to 394 required service function -- chains can be achieved via service 395 classification. 397 3.3. SFC Encapsulation 399 The SFC encapsulation enables the creation of a service chain in the 400 data plane and can convey information about the chain such as chain 401 identification and OAM status. 403 The SFC encapsulation also carries data plane metadata which provides 404 the ability to exchange information between logical classification 405 points and service functions (and vice versa) and between service 406 functions. Metadata is not used as forwarding information to deliver 407 packets along the service overlay. 409 Metadata can include the result of antecedent classification and/or 410 information from external sources. Service functions utilize 411 metadata, as required, for localized policy decisions. 413 In addition to sharing of information, the use of metadata addresses 414 several of the issues raised in section 2, most notably by decoupling 415 policy from the network topology, and by removing the need for per- 416 service function classification (and re-classification) described in 417 section 2.10. 419 A common approach to service metadata creates a common foundation for 420 interoperability between service functions, regardless of vendor. 422 4. IANA Considerations 424 This document makes no request to IANA. 426 5. Security Considerations 428 Although this problem statement does not introduce any protocols, 429 when considering service function chaining, the three main areas 430 begin investigated (see section 3) by the WG have security aspects 431 that warrant consideration. 433 Service Overlay: The service overlay will be constructed using 434 existing transport protocols (e.g. MPLS, VXLAN) and as such is 435 subject to the security specifics of the transport selected. If 436 an operator requires authenticity and/or confidentiality in the 437 service overlay, a transport (e.g. IPSec) that provides such 438 functionally can be used. 440 Classification: Since classification is used to select the 441 appropriate service overlay, and required service encapsulation 442 details, classification policy must be both accurate and trusted. 443 Conveying the policy to a SFC-edge device node may be done via a 444 multitude of methods depending on an operator's existing 445 provisioning practices and security posture. 447 Additionally, traffic entering the SFC domain and being classified 448 may be encrypted thus limiting the granularity of classification. 449 The use of pervasive encryption varies based on type of traffic, 450 environment and level of operator control. For instance a large 451 enterprise can mandate how encryption is used by its users, 452 whereas a broadband provider likely does not have the ability to 453 do so. 455 The use of encrypted traffic however does not obviate the need for 456 SFC (nor the problems associated with current deployment models 457 described herein), rather when encrypted traffic must be 458 classified, the granularity of such classification must adapt. In 459 such cases, service overlay selection might occur, for example, 460 using outer (i.e. unencrypted) header information, on the presence 461 of encryption, or via external information about the packets. 463 SFC Encapsulation: As described in section 3, the SFC encapsulation 464 carries information about the SFC, and data plane metadata. 465 Depending on environment and security posture, the SFC 466 encapsulation might need to be authenticated and/or encrypted. 467 The use of an appropriate overlay transport as described above can 468 provide data plane confidentially and authenticity. 470 The exchange of SFC encapsulation data such as metadata must 471 originate from trusted source(s) and, if needed, be subject to 472 authenticity and confidentiality during the exchange to the 473 various SFC nodes. 475 SFC and Multi-tenancy: If tenant isolation is required in an SFC 476 deployment, an appropriate network transport overlay that provides 477 adequate isolation and identification can be used. Additionally, 478 tenancy might be used in the selection of the appropriate service 479 chain, however, as stated, the network overlay is still required 480 to provide transport isolation. SF deployment and how specific 481 SFs might or might not be allocated per tenant is outside the 482 scope of this document. 484 The SFC Architecture draft present a more complete review of the 485 security implications of a complete SFC architecture. 487 6. Contributors 489 The following people are active contributors to this document and 490 have provided review, content and concepts (listed alphabetically by 491 surname): 493 Puneet Agarwal 494 Broadcom 495 Email: pagarwal@broadcom.com 497 Mohamed Boucadair 498 France Telecom 499 Email: mohamed.boucadair@orange.com 501 Abhishek Chauhan 502 Citrix 503 Email: Abhishek.Chauhan@citrix.com 505 Uri Elzur 506 Intel 507 Email: uri.elzur@intel.com 509 Kevin Glavin 510 Riverbed 511 Email: Kevin.Glavin@riverbed.com 513 Ken Gray 514 Cisco Systems 515 Email: kegray@cisco.com 517 Jim Guichard 518 Cisco Systems 519 Email:jguichar@cisco.com 521 Christian Jacquenet 522 France Telecom 523 Email: christian.jacquenet@orange.com 525 Surendra Kumar 526 Cisco Systems 527 Email: smkumar@cisco.com 529 Nic Leymann 530 Deutsche Telekom 531 Email: n.leymann@telekom.de 533 Darrel Lewis 534 Cisco Systems 535 Email: darlewis@cisco.com 537 Rajeev Manur 538 Broadcom 539 Email:rmanur@broadcom.com 541 Brad McConnell 542 Rackspace 543 Email: bmcconne@rackspace.com 545 Carlos Pignataro 546 Cisco Systems 547 Email: cpignata@cisco.com 549 Michael Smith 550 Cisco Systems 551 Email: michsmit@cisco.com 553 Navindra Yadav 554 Cisco Systems 555 Email: nyadav@cisco.com 557 7. Acknowledgments 559 The authors would like to thank David Ward, Rex Fernando, David 560 McDysan, Jamal Hadi Salim, Charles Perkins, Andre Beliveau, Joel 561 Halpern and Jim French for their reviews and comments. 563 Additionally, the authors would like to thank the IESG and Benjamin 564 Kaduk for their detailed reviews and suggestions. 566 8. Informative References 568 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 569 Address Translator (Traditional NAT)", RFC 3022, 570 January 2001. 572 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 573 NAT64: Network Address and Protocol Translation from IPv6 574 Clients to IPv4 Servers", RFC 6146, April 2011. 576 Authors' Addresses 578 Paul Quinn (editor) 579 Cisco Systems, Inc. 581 Email: paulq@cisco.com 583 Thomas Nadeau (editor) 584 Brocade 586 Email: tnadeau@lucidvision.com