idnits 2.17.1 draft-ietf-sfc-architecture-11.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 (July 24, 2015) is 3171 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 J. Halpern, Ed. 3 Internet-Draft Ericsson 4 Intended status: Informational C. Pignataro, Ed. 5 Expires: January 25, 2016 Cisco 6 July 24, 2015 8 Service Function Chaining (SFC) Architecture 9 draft-ietf-sfc-architecture-11 11 Abstract 13 This document describes an architecture for the specification, 14 creation, and ongoing maintenance of Service Function Chains (SFC) in 15 a network. It includes architectural concepts, principles, and 16 components used in the construction of composite services through 17 deployment of SFCs, with a focus on those to be standardized in the 18 IETF. This document does not propose solutions, protocols, or 19 extensions to existing protocols. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on January 25, 2016. 38 Copyright Notice 40 Copyright (c) 2015 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 56 1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 1.2. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 4 58 1.3. Specification of Requirements . . . . . . . . . . . . . . 4 59 1.4. Definition of Terms . . . . . . . . . . . . . . . . . . . 5 60 2. Architectural Concepts . . . . . . . . . . . . . . . . . . . 7 61 2.1. Service Function Chains . . . . . . . . . . . . . . . . . 7 62 2.2. Service Function Chain Symmetry . . . . . . . . . . . . . 8 63 2.3. Service Function Paths . . . . . . . . . . . . . . . . . 9 64 2.3.1. Service Function Chains, Service Function Paths, and 65 Rendered Service Path . . . . . . . . . . . . . . . . 10 66 3. Architecture Principles . . . . . . . . . . . . . . . . . . . 11 67 4. Core SFC Architecture Components . . . . . . . . . . . . . . 12 68 4.1. SFC Encapsulation . . . . . . . . . . . . . . . . . . . . 13 69 4.2. Service Function (SF) . . . . . . . . . . . . . . . . . . 14 70 4.3. Service Function Forwarder (SFF) . . . . . . . . . . . . 14 71 4.3.1. Transport Derived SFF . . . . . . . . . . . . . . . . 16 72 4.4. SFC-Enabled Domain . . . . . . . . . . . . . . . . . . . 16 73 4.5. Network Overlay and Network Components . . . . . . . . . 17 74 4.6. SFC Proxy . . . . . . . . . . . . . . . . . . . . . . . . 17 75 4.7. Classification . . . . . . . . . . . . . . . . . . . . . 18 76 4.8. Re-Classification and Branching . . . . . . . . . . . . . 18 77 4.9. Shared Metadata . . . . . . . . . . . . . . . . . . . . . 19 78 5. Additional Architectural Concepts . . . . . . . . . . . . . . 19 79 5.1. The Role of Policy . . . . . . . . . . . . . . . . . . . 19 80 5.2. SFC Control Plane . . . . . . . . . . . . . . . . . . . . 20 81 5.3. Resource Control . . . . . . . . . . . . . . . . . . . . 21 82 5.4. Infinite Loop Detection and Avoidance . . . . . . . . . . 22 83 5.5. Load Balancing Considerations . . . . . . . . . . . . . . 22 84 5.6. MTU and Fragmentation Considerations . . . . . . . . . . 23 85 5.7. SFC OAM . . . . . . . . . . . . . . . . . . . . . . . . . 24 86 5.8. Resilience and Redundancy . . . . . . . . . . . . . . . . 25 87 6. Security Considerations . . . . . . . . . . . . . . . . . . . 25 88 7. Contributors and Acknowledgments . . . . . . . . . . . . . . 28 89 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 90 9. Informative References . . . . . . . . . . . . . . . . . . . 29 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30 93 1. Introduction 95 The delivery of end-to-end services often requires various service 96 functions. These include traditional network service functions such 97 as firewalls and traditional IP Network Address Translators (NATs), 98 as well as application-specific functions. The definition and 99 instantiation of an ordered set of service functions and subsequent 100 'steering' of traffic through them is termed Service Function 101 Chaining (SFC). 103 This document describes an architecture used for the creation and 104 ongoing maintenance of Service Function Chains (SFC) in a network. 105 It includes architectural concepts, principles, and components, with 106 a focus on those to be standardized in the IETF. Service function 107 chains enable composite services that are constructed from one or 108 more service functions. 110 An overview of the issues associated with the deployment of end-to- 111 end service function chains, abstract sets of service functions and 112 their ordering constraints that create a composite service and the 113 subsequent "steering" of traffic flows through said service 114 functions, is described in [RFC7498]. 116 The current service function deployment models are relatively static, 117 coupled to network topology and physical resources, greatly reducing 118 or eliminating the ability of an operator to introduce new services 119 or dynamically create service function chains. This architecture 120 presents a model addressing the problematic aspects of existing 121 service deployments, including topological independence and 122 configuration complexity. 124 1.1. Scope 126 This document defines the architecture for Service Function Chaining 127 (SFC) as standardized in the IETF. The SFC architecture is 128 predicated on topological independence from the underlying forwarding 129 topology. 131 In this architecture packets are classified on ingress for handling 132 by the required set of Service Functions (SFs) in the SFC-enabled 133 domain and are then forwarded through that set of functions for 134 processing by each function in turn. Packets may be re-classified as 135 a result of this processing. 137 The architecture described in this document is independent of the 138 planned usage of the network and deployment context and thus, for 139 example, is applicable to both fixed and mobile networks as well as 140 being useful in many Data Center applications. 142 The architecture described herein is assumed to be applicable to a 143 single network administrative domain. While it is possible for the 144 architectural principles and components to be applied to inter-domain 145 SFCs, these are left for future study. 147 1.2. Assumptions 149 The following assumptions are made: 151 o There is no standard definition or characterization applicable to 152 all SFs, and thus the architecture considers each SF as an opaque 153 processing element. 155 o There is no global or standard list of SFs enabled in a given 156 administrative domain. The set of SFs enabled in a given domain 157 is a function of the currently active services which may vary with 158 time and according to the networking environment. 160 o There is no global or standard SF chaining logic. The ordered set 161 of SFs that needs to be applied to deliver a given service is 162 specific to each administrative entity. 164 o The chaining of SFs and the criteria to invoke them are specific 165 to each administrative entity that operates an SF-enabled domain. 167 o Several SF chaining policies can be simultaneously applied within 168 an administrative domain to meet various business requirements. 170 o The underlay is assumed to provide the necessary connectivity to 171 interconnect the Service Function Forwarders (SFFs, see 172 Section 1.4), but the architecture places no constraints on how 173 that connectivity is realized other than it have the required 174 bandwidth, latency, and jitter to support the SFC. 176 o No assumption is made on how Forwarding Information Bases (FIBs) 177 and Routing Information Bases (RIBs) of involved nodes are 178 populated. 180 o How to bind traffic to a given SF chain is policy-based. 182 1.3. Specification of Requirements 184 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 185 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 186 document are to be interpreted as described in [RFC2119]. 188 1.4. Definition of Terms 190 Network Service: An offering provided by an operator that is 191 delivered using one or more service functions. This may also be 192 referred to as a composite service. The term "service" is used 193 to denote a "network service" in the context of this document. 195 Note: Beyond this document, the term "service" is overloaded 196 with varying definitions. For example, to some a service is an 197 offering composed of several elements within the operator's 198 network, whereas for others a service, or more specifically a 199 network service, is a discrete element such as a "firewall". 200 Traditionally, such services (in the latter sense) host a set of 201 service functions and have a network locator where the service 202 is hosted. 204 Classification: Locally instantiated matching of traffic flows 205 against policy for subsequent application of the required set of 206 network service functions. The policy may be customer/network/ 207 service specific. 209 Classifier: An element that performs Classification. 211 Service Function Chain (SFC): A service function chain defines an 212 ordered set of abstract service functions (SFs) and ordering 213 constraints that must be applied to packets and/or frames and/or 214 flows selected as a result of classification. An example of an 215 abstract service function is "a firewall". The implied order 216 may not be a linear progression as the architecture allows for 217 SFCs that copy to more than one branch, and also allows for 218 cases where there is flexibility in the order in which service 219 functions need to be applied. The term service chain is often 220 used as shorthand for service function chain. 222 Service Function (SF): A function that is responsible for specific 223 treatment of received packets. A Service Function can act at 224 various layers of a protocol stack (e.g., at the network layer 225 or other OSI layers). As a logical component, a Service 226 Function can be realized as a virtual element or be embedded in 227 a physical network element. One or more Service Functions can 228 be embedded in the same network element. Multiple occurrences 229 of the Service Function can exist in the same administrative 230 domain. 232 One or more Service Functions can be involved in the delivery of 233 added-value services. A non-exhaustive list of abstract Service 234 Functions includes: firewalls, WAN and application acceleration, 235 Deep Packet Inspection (DPI), LI (Lawful Intercept), server load 236 balancing, NAT44 [RFC3022], NAT64 [RFC6146], NPTv6 [RFC6296], 237 HOST_ID injection, HTTP Header Enrichment functions, TCP 238 optimizer. 240 An SF may be SFC encapsulation aware, that is it receives and 241 acts on information in the SFC encapsulation, or unaware, in 242 which case data forwarded to the SF does not contain the SFC 243 encapsulation. 245 Service Function Forwarder (SFF): A service function forwarder is 246 responsible for forwarding traffic to one or more connected 247 service functions according to information carried in the SFC 248 encapsulation, as well as handling traffic coming back from the 249 SF. Additionally, a service function forwarder is responsible 250 for delivering traffic to a classifier when needed and 251 supported, transporting traffic to another SFF (in the same or 252 different type of overlay), and terminating the SFP. 254 Metadata: provides the ability to exchange context information 255 between classifiers and SFs and among SFs. 257 Service Function Path (SFP): The Service Function Path is a 258 constrained specification of where packets assigned to a certain 259 service function path must go. While it may be so constrained 260 as to identify the exact locations, it can also be less 261 specific. The SFP provides a level of indirection between the 262 fully abstract notion of service chain as a sequence of abstract 263 service functions to be delivered, and the fully specified 264 notion of exactly which SFF/SFs the packet will visit when it 265 actually traverses the network. By allowing the control 266 components to specify this level of indirection, the operator 267 may control the degree of SFF/SF selection authority that is 268 delegated to the network. 270 SFC Encapsulation: The SFC Encapsulation provides at a minimum SFP 271 identification, and is used by the SFC-aware functions, such as 272 the SFF and SFC-aware SFs. The SFC Encapsulation is not used 273 for network packet forwarding. In addition to SFP 274 identification, the SFC encapsulation carries metadata including 275 data plane context information. 277 Rendered Service Path (RSP): Within an SFP, packets themselves are 278 of course transmitted from and to specific places in the 279 network, visiting a specific sequence of SFFs and SFs. This 280 sequence of actual visits by a packet to specific SFFs and SFs 281 in the network is known as the Rendered Service Path (RSP). 282 This definition is included here for use by later documents, 283 such as when solutions may need to discuss the actual sequence 284 of locations the packets visit. 286 SFC-enabled Domain: A network or region of a network that implements 287 SFC. An SFC-enabled Domain is limited to a single network 288 administrative domain. 290 SFC Proxy: Removes and inserts SFC Encapsulation on behalf of an 291 SFC-unaware service function. SFC proxies are logical elements. 293 2. Architectural Concepts 295 The following sections describe the foundational concepts of service 296 function chaining and the SFC architecture. 298 Service Function Chaining enables the creation of composite (network) 299 services that consist of an ordered set of Service Functions (SF) 300 that must be applied to packets and/or frames and/or flows selected 301 as a result of classification. Each SF is referenced using an 302 identifier that is unique within an SF-enabled domain. 304 Service Function Chaining is a concept that provides for more than 305 just the application of an ordered set of SFs to selected traffic; 306 rather, it describes a method for deploying SFs in a way that enables 307 dynamic ordering and topological independence of those SFs as well as 308 the exchange of metadata between participating entities. 310 2.1. Service Function Chains 312 In most networks, services are constructed as abstract sequences of 313 SFs that represent SFCs. At a high level, an SFC is an abstracted 314 view of a service that specifies the set of required SFs as well as 315 the order in which they must be executed. Graphs, as illustrated in 316 Figure 1, define an SFC, where each graph node represents the 317 required existence of at least one abstract SF. Such graph nodes 318 (SFs) can be part of zero, one, or many SFCs. A given graph node 319 (SF) can appear one time or multiple times in a given SFC. 321 SFCs can start from the origination point of the service function 322 graph (i.e., node 1 in Figure 1), or from any subsequent node in the 323 graph. As shown, SFs may therefore become branching nodes in the 324 graph, with those SFs selecting edges that move traffic to one or 325 more branches. The top and middle graphs depict such a case, where a 326 second classification event occurs after node 2, and a new graph is 327 selected (i.e., node 3 instead of node 6). The bottom graph 328 highlights the concept of a cycle, in which a given SF (e.g., node 7 329 in the depiction) can be visited more than once within a given 330 service chain. An SFC can have more than one terminus. 332 ,-+-. ,---. ,---. ,---. 333 / \ / \ / \ / \ 334 ( 1 )+--->( 2 )+---->( 6 )+---->( 8 ) 335 \ / \ / \ / \ / 336 `---' `---' `---' `---' 338 ,-+-. ,---. ,---. ,---. ,---. 339 / \ / \ / \ / \ / \ 340 ( 1 )+--->( 2 )+---->( 3 )+---->( 7 )+---->( 9 ) 341 \ / \ / \ / \ / \ / 342 `---' `---' `---' `---' `---' 344 ,-+-. ,---. ,---. ,---. ,---. 345 / \ / \ / \ / \ / \ 346 ( 1 )+--->( 7 )+---->( 8 )+---->( 4 )+---->( 7 ) 347 \ / \ / \ / \ / \ / 348 `---' `---' `---' `---' `---' 350 Figure 1: Service Function Chain Graphs 352 The concepts of classification, re-classification, and branching are 353 covered in subsequent sections of this architecture (see Section 4.7 354 and Section 4.8). 356 2.2. Service Function Chain Symmetry 358 SFCs may be unidirectional or bidirectional. A unidirectional SFC 359 requires that traffic be forwarded through the ordered SFs in one 360 direction (SF1 -> SF2 -> SF3), whereas a bidirectional SFC requires a 361 symmetric path (SF1 -> SF2 -> SF3 and SF3 -> SF2 -> SF1), and in 362 which the SF instances are the same in opposite directions. A hybrid 363 SFC has attributes of both unidirectional and bidirectional SFCs; 364 that is to say some SFs require symmetric traffic, whereas other SFs 365 do not process reverse traffic or are independent of the 366 corresponding forward traffic. 368 SFCs may contain cycles; that is traffic may need to traverse one or 369 more SFs within an SFC more than once. Solutions will need to ensure 370 suitable disambiguation for such situations. 372 The architectural allowance that is made for SFPs that delegate 373 choice to the network for which SFs and/or SFFs a packet will visit 374 creates potential issues here. A solution that allows such 375 delegation needs to also describe how the solution ensures that those 376 service chains that require service function chain symmetry can 377 achieve that. 379 Further, there are state tradeoffs in symmetry. Symmetry may be 380 realized in several ways depending on the SFF and classifier 381 functionality. In some cases, "mirrored" classification (i.e., from 382 Source to Destination and from Destination to Source) policy may be 383 deployed, whereas in others shared state between classifiers may be 384 used to ensure that symmetric flows are correctly identified, then 385 steered along the required SFP. At a high level, there are various 386 common cases. In a non-exhaustive way, there can be for example: 388 o A single classifier (or a small number of classifiers), in which 389 case both incoming and outgoing flows could be recognized at the 390 same classifier, so the synchronization would be feasible by 391 internal mechanisms internal to the classifier. 393 o Stateful classifiers where several classifiers may be clustered 394 and share state. 396 o Fully distributed classifiers, where synchronization needs to be 397 provided through unspecified means. 399 o A classifier that learns state from the egress packets/flows that 400 is then used to provide state for the return packets/flow. 402 o Symmetry may also be provided by stateful forwarding logic in the 403 SFF in some implementations. 405 This is a non-comprehensive list of common cases. 407 2.3. Service Function Paths 409 A service function path (SFP) is a mechanism used by service chaining 410 to express the result of applying more granular policy and 411 operational constraints to the abstract requirements of a service 412 chain (SFC). This architecture does not mandate the degree of 413 specificity of the SFP. Architecturally, within the same SFC-enabled 414 domain, some SFPs may be fully specified, selecting exactly which SFF 415 and which SF are to be visited by packets using that SFP, while other 416 SFPs may be quite vague, deferring to the SFF the decisions about the 417 exact sequence of steps to be used to realize the SFC. The 418 specificity may be anywhere in between these extremes. 420 As an example of such an intermediate specificity, there may be two 421 SFPs associated with a given SFC, where one SFP specifies that any 422 order of SFF and SF may be used as long as it is within data center 423 1, and where the second SFP allows the same latitude, but only within 424 data center 2. 426 Thus, the policies and logic of SFP selection or creation (depending 427 upon the solution) produce what may be thought of as a constrained 428 version of the original SFC. Since multiple policies may apply to 429 different traffic that uses the same SFC, it also follows that there 430 may be multiple SFPs may be associated with a single SFC. 432 The architecture allows for the same SF to be reachable through 433 multiple SFFs. In these cases, some SFPs may constrain which SFF is 434 used to reach which SF, while some SFPs may leave that decision to 435 the SFF itself. 437 Further, the architecture allows for two or more SFs to be attached 438 to the same SFF, and possibly connected via internal means allowing 439 more effective communication. In these cases, some solutions or 440 deployments may choose to use some form of internal inter-process or 441 inter-VM messaging (communication behind the virtual switching 442 element) that is optimized for such an environment. This must be 443 coordinated with the SFF so that the service function forwarding can 444 properly perform its job. Implementation details of such mechanisms 445 are considered out of scope for this document, and can include a 446 spectrum of methods: for example situations including all next-hops 447 explicitly, others where a list of possible next-hops is provided and 448 the selection is local, or cases with just an identifier, where all 449 resolution is local. 451 This architecture also allows the same SF to be part of multiple 452 SFPs. 454 2.3.1. Service Function Chains, Service Function Paths, and Rendered 455 Service Path 457 As an example of this progressive refinement, consider a service 458 function chain (SFC) which states that packets using this chain 459 should be delivered to a firewall and a caching engine. 461 A Service Function Path (SFP) could refine this, considering that 462 this architecture does not mandate the degree of specificity an SFP 463 has to have. It might specify that the firewall and caching engine 464 are both to be in a specific Data Center (e.g., in DC1), or it might 465 specify exactly which instance of each firewall and chaching engine 466 is to be used. 468 The Rendered Service Path (RSP) is the actual sequence of SFFs and 469 SFs that the packets will actually visit. So if the SFP picked the 470 DC, the RSP would be more specific. 472 3. Architecture Principles 474 Service function chaining is predicated on several key architectural 475 principles: 477 1. Topological independence: no changes to the underlay network 478 forwarding topology - implicit, or explicit - are needed to 479 deploy and invoke SFs or SFCs. 481 2. Plane separation: dynamic realization of SFPs is separated from 482 packet handling operations (e.g., packet forwarding). 484 3. Classification: traffic that satisfies classification rules is 485 forwarded according to a specific SFP. For example, 486 classification can be as simple as an explicit forwarding entry 487 that forwards all traffic from one address into the SFP. 488 Multiple classification points are possible within an SFC (i.e., 489 forming a service graph) thus enabling changes/updates to the SFC 490 by SFs. 492 Classification can occur at varying degrees of granularity; for 493 example, classification can use a 5-tuple, a transport port or 494 set of ports, part of the packet payload, it can be the result of 495 high-level inspections, or it can come from external systems. 497 4. Shared Metadata: Metadata/context data can be shared amongst SFs 498 and classifiers, between SFs, and between external systems and 499 SFs (e.g., orchestration). 501 One use of metadata is to provide and share the result of 502 classification (that occurs within the SFC-enabled domain, or 503 external to it) along an SFP. For example, an external 504 repository might provide user/subscriber information to a service 505 chain classifier. This classifier could in turn impose that 506 information in the SFC encapsulation for delivery to the 507 requisite SFs. The SFs could in turn utilize the user/subscriber 508 information for local policy decisions. Metadata can also share 509 SF output along the SFP. 511 5. Service definition independence: The SFC architecture does not 512 depend on the details of SFs themselves. 514 6. Service function chain independence: The creation, modification, 515 or deletion of an SFC has no impact on other SFCs. The same is 516 true for SFPs. 518 7. Heterogeneous control/policy points: The architecture allows SFs 519 to use independent mechanisms (out of scope for this document) to 520 populate and resolve local policy and (if needed) local 521 classification criteria. 523 4. Core SFC Architecture Components 525 The SFC Architecture is built out of architectural building blocks 526 which are logical components; these logical components are 527 classifiers, service function forwarders (SFF), the service functions 528 themselves (SF), and SFC-proxies. While this architecture describes 529 functionally distinct logical components and promotes transport 530 indepencence, they could be realized and combined in various ways in 531 deployed products, and could be combined with an overlay. 533 They are interconnected using the SFC Encapsulation. This results in 534 a high level logical architecture of an SFC-enabled Domain which 535 comprises: 537 o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 538 . +--------------+ +------------------~~~ 539 . | Service | SFC | Service +---+ +---+ 540 . |Classification| Encapsulation | Function |sf1|...|sfn| 541 +---->| Function |+---------------->| Path +---+ +---+ 542 . +--------------+ +------------------~~~ 543 . SFC-enabled Domain 544 o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 546 Figure 2: Service Function Chain Architecture 548 The following sub-sections provide details on each logical component 549 that form the basis of the SFC architecture. A detailed overview of 550 how some of these architectural components interact is provided in 551 Figure 3: 553 +----------------+ +----------------+ 554 | SFC-aware | | SFC-unaware | 555 |Service Function| |Service Function| 556 +-------+--------+ +-------+--------+ 557 | | 558 SFC Encapsulation No SFC Encapsulation 559 | SFC | 560 +---------+ +----------------+ Encapsulation +---------+ 561 |SFC-Aware|-----------------+ \ +------------|SFC Proxy| 562 | SF | ... ----------+ \ \ / +---------+ 563 +---------+ \ \ \ / 564 +-------+--------+ 565 | SF Forwarder | 566 | (SFF) | 567 +-------+--------+ 568 | 569 SFC Encapsulation 570 | 571 ... SFC-enabled Domain ... 572 | 573 Network Overlay Transport 574 | 575 _,....._ 576 ,-' `-. 577 / `. 578 | Network | 579 `. / 580 `.__ __,-' 581 `'''' 583 Figure 3: SFC Architecture Components Post Initial Classification 585 Please note that the depiction in Figure 3 shows packets post initial 586 classification, and therefore including the SFC encapsulation. 587 Although not included in Figure 3, the classifier is an SFC 588 architectural component. 590 4.1. SFC Encapsulation 592 The SFC encapsulation enables service function path selection. It 593 also enables the sharing of metadata/context information when such 594 metadata exchange is required. 596 The SFC encapsulation carries explicit information used to identify 597 the SFP. However, the SFC encapsulation is not a transport 598 encapsulation itself: it is not used to forward packets within the 599 network fabric. If packets need to flow between separate physical 600 platforms, the SFC encapsulation therefore relies on an outer network 601 transport. Transit forwarders -- such as router and switches -- 602 forward SFC encapsulated packets based on the outer (non-SFC) 603 encapsulation. 605 One of the key architecture principles of SFC is that the SFC 606 encapsulation remain transport independent. As such any network 607 transport protocol may be used to carry the SFC encapsulated traffic. 609 4.2. Service Function (SF) 611 The concept of an SF evolves; rather than being viewed as a bump in 612 the wire, an SF becomes a resource within a specified administrative 613 domain that is available for consumption as part of a composite 614 service. SFs send/receive data to/from one or more SFFs. SFC-aware 615 SFs receive this traffic with the SFC encapsulation. 617 While the SFC architecture defines the concept and specifies some 618 characteristics of a new encapsulation - the SFC encapsulation - and 619 several logical components for the construction of SFCs, existing SF 620 implementations may not have the capabilities to act upon or fully 621 integrate with the new SFC encapsulation. In order to provide a 622 mechanism for such SFs to participate in the architecture, an SFC 623 proxy function is defined (see Section 4.6). The SFC proxy acts as a 624 gateway between the SFC encapsulation and SFC-unaware SFs. The 625 integration of SFC-unaware service functions is discussed in more 626 detail in the SFC proxy section. 628 This architecture allows an SF to be part of multiple SFPs and SFCs. 630 4.3. Service Function Forwarder (SFF) 632 The SFF is responsible for forwarding packets and/or frames received 633 from the network to one or more SFs associated with a given SFF using 634 information conveyed in the SFC encapsulation. Traffic from SFs 635 eventually returns to the same SFF, which is responsible for 636 injecting traffic back onto the network. Some SFs, such as 637 firewalls, could also consume a packet. 639 The collection of SFFs and associated SFs creates a service plane 640 overlay in which SFC-aware SFs, as well as SFC-unaware SFs reside. 641 Within this service plane, the SFF component connects different SFs 642 that form a service function path. 644 SFFs maintain the requisite SFP forwarding information. SFP 645 forwarding information is associated with a service path identifier 646 that is used to uniquely identify an SFP. The service forwarding 647 state enables an SFF to identify which SFs of a given SFP should be 648 applied, and in what order, as traffic flows through the associated 649 SFP. While there may appear to the SFF to be only one available way 650 to deliver the given SF, there may also be multiple choices allowed 651 by the constraints of the SFP. 653 If there are multiple choices, the SFF needs to preserve the property 654 that all packets of a given flow are handled the same way, since the 655 SF may well be stateful. Additionally, the SFF may preserve the 656 handling of packets based on other properties on top of a flow, such 657 as a subscriber, session, or application instance identification. 659 The SFF also has the information to allow it to forward packets to 660 the next SFF after applying local service functions. Again, while 661 there may be only a single choice available, the architecture allows 662 for multiple choices for the next SFF. As with SFs, the solution 663 needs to operate such that the behavior with regard to specific flows 664 (see the Rendered Service Path) is stable. The selection of 665 available SFs and next SFFs may be interwoven when an SFF supports 666 multiple distinct service functions and the same service function is 667 available at multiple SFFs. Solutions need to be clear about what is 668 allowed in these cases. 670 Even when the SFF supports and utilizes multiple choices, the 671 decision as to whether to use flow-specific mechanisms or coarser 672 grained means to ensure that the behavior of specific flows is stable 673 is a matter for specific solutions and specific implementations. 675 The SFF component has the following primary responsibilities: 677 1. SFP forwarding : Traffic arrives at an SFF from the network. The 678 SFF determines the appropriate SF the traffic should be forwarded 679 to via information contained in the SFC encapsulation. Post-SF, 680 the traffic is returned to the SFF, and, if needed, is forwarded 681 to another SF associated with that SFF. If there is another non- 682 local (i.e., different SFF) hop in the SFP, the SFF further 683 encapsulates the traffic in the appropriate network transport 684 protocol and delivers it to the network for delivery to the next 685 SFF along the path. Related to this forwarding responsibility, 686 an SFF should be able to interact with metadata. 688 2. Terminating SFPs : An SFC is completely executed when traffic has 689 traversed all required SFs in a chain. When traffic arrives at 690 the SFF after the last SF has finished processing it, the final 691 SFF knows from the service forwarding state that the SFC is 692 complete. The SFF removes the SFC encapsulation and delivers the 693 packet back to the network for forwarding. 695 3. Maintaining flow state: In some cases, the SFF may be stateful. 696 It creates flows and stores flow-centric information. This state 697 information may be used for a range of SFP-related tasks such as 698 ensuring consistent treatment of all packets in a given flow, 699 ensuring symmetry or for state-aware SFC Proxy functionality (see 700 Section 4.8). 702 4.3.1. Transport Derived SFF 704 Service function forwarding, as described above, directly depends 705 upon the use of the service path information contained in the SFC 706 encapsulation. However, existing implementations may not be able to 707 act on the SFC encapsulation. These platforms may opt to use 708 existing transport information if it can be arranged to provide 709 explicit service path information. 711 This results in the same architectural behavior and meaning for 712 service function forwarding and service function paths. It is the 713 responsibility of the control components to ensure that the transport 714 path executed in such a case is fully aligned with the path 715 identified by the information in the service chaining encapsulation. 717 4.4. SFC-Enabled Domain 719 Specific features may need to be enforced at the boundaries of an 720 SFC-enabled domain, for example to avoid leaking SFC information. 721 Using the term node to refer generically to an entity that is 722 performing a set of functions, in this context, an SFC Boundary Node 723 denotes a node that connects one SFC-enabled domain to a node either 724 located in another SFC-enabled domain or in a domain that is SFC- 725 unaware. 727 An SFC Boundary node can act as egress or ingress. An SFC Egress 728 Node denotes a SFC Boundary Node that handles traffic leaving the 729 SFC-enabled domain the Egress Node belongs to. Such a node is 730 required to remove any information specific to the SFC Domain, 731 typically the SFC Encapsulation. Further, from a privacy 732 perspective, an SFC Egress Node is required to ensure that any 733 sensitive information added as part of SFC gets removed. In this 734 context, information may be sensitive due to network concerns or end- 735 customer concerns. An SFC Ingress Node denotes an SFC Boundary Node 736 that handles traffic entering the SFC-enabled domain. In most 737 solutions and deployments this will need to include a classifier, and 738 will be responsible for adding the SFC encapsulation to the packet. 740 An SFC Proxy and corresponding SFC-unaware Service Function (see 741 Figure 3) are inside the SFC-enabled domain. 743 4.5. Network Overlay and Network Components 745 Underneath the SFF there are components responsible for performing 746 the transport (overlay) forwarding. They do not consult the SFC 747 encapsulation or inner payload for performing this forwarding. They 748 only consult the outer-transport encapsulation for the transport 749 (overlay) forwarding. 751 4.6. SFC Proxy 753 In order for the SFC architecture to support SFC-unaware SFs (e.g., 754 legacy service functions) a logical SFC proxy function may be used. 755 This function sits between an SFF and one or more SFs to which the 756 SFF is directing traffic (see Figure 3). 758 The proxy accepts packets from the SFF on behalf of the SF. It 759 removes the SFC encapsulation, and then uses a local attachment 760 circuit to deliver packets to SFC unaware SFs. It also receives 761 packets back from the SF, reapplies the SFC encapsulation, and 762 returns them to the SFF for processing along the service function 763 path. 765 Thus, from the point of view of the SFF, the SFC proxy appears to be 766 part of an SFC aware SF. 768 Communication details between the SFF and the SFC Proxy are the same 769 as those between the SFF and an SFC aware SF. The details of that 770 are not part of this architecture. The details of the communication 771 methods over the local attachment circuit between the SFC proxy and 772 the SFC-unaware SF are dependent upon the specific behaviors and 773 capabilities of that SFC-unaware SF, and thus are also out of scope 774 for this architecture. 776 Specifically, for traffic received from the SFF intended for the SF 777 the proxy is representing, the SFC proxy: 779 o Removes the SFC encapsulation from SFC encapsulated packets. 781 o Identifies the required SF to be applied based on available 782 information including that carried in the SFC encapsulation. 784 o Selects the appropriate outbound local attachment circuit through 785 which the next SF for this SFP is reachable. This is derived from 786 the identification of the SF carried in the SFC encapsulation, and 787 may include local techniques. Examples of a local attachment 788 circuit include, but are not limited to, VLAN, IP-in-IP, L2TPv3, 789 GRE, VXLAN. 791 o Forwards the original payload via the selected local attachment 792 circuit to the appropriate SF. 794 When traffic is returned from the SF: 796 o Applies the required SFC encapsulation. The determination of the 797 encapsulation details may be inferred by the local attachment 798 circuit through which the packet and/or frame was received, or via 799 packet classification, or other local policy. In some cases, 800 packet ordering or modification by the SF may necessitate 801 additional classification in order to re-apply the correct SFC 802 encapsulation. 804 o Delivers the packet with the SFC Encapsulation to the SFF, as 805 would happen with packets returned from an SFC-aware SF. 807 4.7. Classification 809 Traffic from the network that satisfies classification criteria is 810 directed into an SFP and forwarded to the requisite service 811 function(s). Classification is handled by a service classification 812 function; initial classification occurs at the ingress to the SFC 813 domain. The granularity of the initial classification is determined 814 by the capabilities of the classifier and the requirements of the SFC 815 policy. For instance, classification might be relatively coarse: all 816 packets from this port are subject to SFC policy X and directed into 817 SFP A, or quite granular: all packets matching this 5-tuple are 818 subject to SFC policy Y and directed into SFP B. 820 As a consequence of the classification decision, the appropriate SFC 821 encapsulation is imposed on the data, and a suitable SFP is selected 822 or created. Classification results in attaching the traffic to a 823 specific SFP. 825 4.8. Re-Classification and Branching 827 The SFC architecture supports re-classification (or non-initial 828 classification) as well. As packets traverse an SFP, re- 829 classification may occur - typically performed by a classification 830 function co-resident with a service function. Reclassification may 831 result in the selection of a new SFP, an update of the associated 832 metadata, or both. This is referred to as "branching". 834 For example, an initial classification results in the selection of 835 SFP A: DPI_1 --> SLB_8. However, when the DPI service function is 836 executed, attack traffic is detected at the application layer. DPI_1 837 re-classifies the traffic as attack and alters the service path to 838 SFP B, to include a firewall for policy enforcement: dropping the 839 traffic: DPI_1 --> FW_4. Subsequent to FW_4, surviving traffic would 840 be returned to the original SFF. In this simple example, the DPI 841 service function re-classifies the traffic based on local application 842 layer classification capabilities (that were not available during the 843 initial classification step). 845 When traffic arrives after being steered through an SFC-unaware SF, 846 the SFC Proxy must perform re-classification of traffic to determine 847 the SFP. The SFC Proxy is concerned with re-attaching information 848 for SFC-unaware SFs, and a stateful SFC Proxy simplifies such 849 classification to a flow lookup. 851 4.9. Shared Metadata 853 Sharing metadata allows the network to provide network-derived 854 information to the SFs, SF-to-SF information exchange and the sharing 855 of service-derived information to the network. Some SFCs may not 856 require metadata exchange. SFC infrastructure enables the exchange 857 of this shared data along the SFP. The shared metadata serves 858 several possible roles within the SFC architecture: 860 o Allows elements that typically operate as ships in the night to 861 exchange information. 863 o Encodes information about the network and/or data for post- 864 service forwarding. 866 o Creates an identifier used for policy binding by SFs. 868 Context information can be derived in several ways: 870 o External sources 872 o Network node classification 874 o Service function classification 876 5. Additional Architectural Concepts 878 There are a number of issues which solutions need to address, and 879 which the architecture informs but does not determine. This section 880 lays out some of those concepts. 882 5.1. The Role of Policy 884 Much of the behavior of service chains is driven by operator and per- 885 customer policy. This architecture is structured to isolate the 886 policy interactions from the data plane and control logic. 888 Specifically, it is assumed that the service chaining control plane 889 creates the service paths. The service chaining data plane is used 890 to deliver the classified packets along the service chains to the 891 intended service functions. 893 Policy, in contrast, interacts with the system in other places. 894 Policies and policy engines may monitor service functions to decide 895 if additional (or fewer) instances of services are needed. When 896 applicable, those decisions may in turn result in interactions that 897 direct the control logic to change the SFP placement or packet 898 classification rules. 900 Similarly, operator service policy, often managed by operational or 901 business support systems (OSS or BSS), will frequently determine what 902 service functions are available. Operator service policies also 903 determine which sequences of functions are valid and are to be used 904 or made available. 906 The offering of service chains to customers, and the selection of 907 which service chain a customer wishes to use, are driven by a 908 combination of operator and customer policies using appropriate 909 portals in conjunction with the OSS and BSS tools. These selections 910 then drive the service chaining control logic, which in turn 911 establishes the appropriate packet classification rules. 913 5.2. SFC Control Plane 915 The SFC Control Plane is part of the overall SFC architecture, and 916 this section describes its high-level functions. However, the 917 detailed definition of the SFC Control Plane is outside the scope of 918 this document. 920 The SFC control plane is responsible for constructing SFPs, 921 translating SFCs to forwarding paths and propagating path information 922 to participating nodes to achieve requisite forwarding behavior to 923 construct the service overlay. For instance, an SFC construction may 924 be static; selecting exactly which SFFs and which SFs from those SFFs 925 are to be used, or it may be dynamic, allowing the network to perform 926 some or all of the choices of SFF or SF to use to deliver the 927 selected service chain within the constraints represented by the 928 service path. 930 In the SFC architecture, SFs are resources; the control plane manages 931 and communicates their capabilities, availability and location in 932 fashions suitable for the transport and SFC operations in use. The 933 control plane is also responsible for the creation of the context 934 (see below). The control plane may be distributed (using new or 935 existing control plane protocols), or be centralized, or a 936 combination of the two. 938 The SFC control plane provides the following functionality: 940 1. An SFC-enabled domain wide view of all available service function 941 resources as well as the network locators through which they are 942 reachable. 944 2. Uses SFC policy to construct service function chains, and 945 associated service function paths. 947 3. Selection of specific SFs for a requested SFC, either statically 948 (using specific SFs) or dynamically (using service explicit SFs 949 at the time of delivering traffic to them). 951 4. Provides requisite SFC data plane information to the SFC 952 architecture components, most notably the SFF. 954 5. Provide the metadata and usage information classifiers need so 955 that they in turn can provide this metadata for appropriate 956 packets in the data plane. 958 6. When needed, provide information including policy information to 959 other SFC elements to be able to properly interpret metadata. 961 5.3. Resource Control 963 The SFC system may be responsible for managing all resources 964 necessary for the SFC components to function. This includes network 965 constraints used to plan and choose network path(s) between service 966 function forwarders, network communication paths between service 967 function forwarders and their attached service functions, 968 characteristics of the nodes themselves such as memory, number of 969 virtual interfaces, routes, and instantiation, configuration, and 970 deletion of SFs. 972 The SFC system will also be required to reflect policy decisions 973 about resource control, as expressed by other components in the 974 system. 976 While all of these aspects are part of the overall system, they are 977 beyond the scope of this architecture. 979 5.4. Infinite Loop Detection and Avoidance 981 This SFC architecture is predicated on topological independence from 982 the underlying forwarding topology. Consequently, a service topology 983 is created by Service Function Paths or by the local decisions of the 984 Service Function Forwarders based on the constraints expressed in the 985 SFP. Due to the overlay constraints, the packet-forwarding path may 986 need to visit the same SFF multiple times, and in some less common 987 cases may even need to visit the same SF more than once. The Service 988 Chaining solution needs to permit these limited and policy-compliant 989 loops. At the same time, the solutions must ensure that indefinite 990 and unbounded loops cannot be formed, as such would consume unbounded 991 resources without delivering any value. 993 In other words, this architecture requires the solution to prevent 994 infinite Service Function Loops, even when Service Functions may be 995 invoked multiple times in the same SFP. 997 5.5. Load Balancing Considerations 999 Supporting function elasticity and high-availability should not 1000 overly complicate SFC or lead to unnecessary scalability problems. 1002 In the simplest case, where there is only a single function in the 1003 SFP (the next hop is either the destination address of the flow or 1004 the appropriate next hop to that destination), one could argue that 1005 there may be no need for SFC. 1007 In the cases where the classifier is separate from the single 1008 function or a function at the terminal address may need sub-prefix 1009 (e.g., finer grained address information) or per-subscriber metadata, 1010 a single SFP exists (i.e., the metadata changes but the SFP does 1011 not), regardless of the number of potential terminal addresses for 1012 the flow. This is the case of the simple load balancer. See 1013 Figure 4. 1015 +---+ +---++--->web server 1016 source+-->|sff|+-->|sf1|+--->web server 1017 +---+ +---++--->web server 1019 Figure 4: Simple Load Balancing 1021 By extrapolation, in the case where intermediary functions within a 1022 chain had similar "elastic" behaviors, we do not need separate chains 1023 to account for this behavior - as long as the traffic coalesces to a 1024 common next-hop after the point of elasticity. 1026 In Figure 5, we have a chain of five service functions between the 1027 traffic source and its destination. 1029 +---+ +---+ +---+ +---+ +---+ +---+ 1030 |sf2| |sf2| |sf3| |sf3| |sf4| |sf4| 1031 +---+ +---+ +---+ +---+ +---+ +---+ 1032 | | | | | | 1033 +-----+-----+ +-----+-----+ 1034 | | 1035 + + 1036 +---+ +---+ +---+ +---+ +---+ 1037 source+-->|sff|+-->|sff|+--->|sff|+--->|sff|+-->|sff|+-->destination 1038 +---+ +---+ +---+ +---+ +---+ 1039 + + + 1040 | | | 1041 +---+ +---+ +---+ 1042 |sf1| |sf3| |sf5| 1043 +---+ +---+ +---+ 1045 Figure 5: Load Balancing 1047 This would be represented as one service function path: 1048 sf1->sf2->sf3->sf4->sf5. The SFF is a logical element, which may be 1049 made up of one or multiple components. In this architecture, the SFF 1050 may handle load distribution based on policy. 1052 It can also be seen in the above that the same service function may 1053 be reachable through multiple SFFs, as discussed earlier. The 1054 selection of which SFF to use to reach SF3 may be made by the control 1055 logic in defining the SFP, or may be left to the SFFs themselves, 1056 depending upon policy, solution, and deployment constraints. In the 1057 latter case, it needs to be assured that exactly one SFF takes 1058 responsibility to steer traffic through SF3. 1060 5.6. MTU and Fragmentation Considerations 1062 This architecture prescribes additional information being added to 1063 packets to identify service function paths and often to represent 1064 metadata. It also envisions adding transport information to carry 1065 packets along service function paths, at least between service 1066 function forwarders. This added information increases the size of 1067 the packet to be carried by service chaining. Such additions could 1068 potentially increase the packet size beyond the MTU supported on some 1069 or all of the media used in the service chaining domain. 1071 Such packet size increases can thus cause operational MTU problems. 1072 Requiring fragmentation and reassembly in an SFF would be a major 1073 processing increase, and might be impossible with some transports. 1075 Expecting service functions to deal with packets fragmented by the 1076 SFC function might be onerous even when such fragmentation was 1077 possible. Thus, at the very least, solutions need to pay attention 1078 to the size cost of their approach. There may be alternative or 1079 additional means available, although any solution needs to consider 1080 the tradeoffs. 1082 These considerations apply to any generic architecture that increases 1083 the header size. There are also more specific MTU considerations: 1084 Effects on Path MTU Discovery (PMTUD) as well as deployment 1085 considerations. Deployments within a single administrative control 1086 or even a single Data Center complex can afford more flexibility in 1087 dealing with larger packets, and deploying existing mitigations that 1088 decrease the likelihood of fragmentation or discard. 1090 5.7. SFC OAM 1092 Operations, Administration, and Maintenance (OAM) tools are an 1093 integral part of the architecture. These serve various purposes, 1094 including fault detection and isolation, and performance management. 1095 For example, there are many advantages of SFP liveness detection, 1096 including status reporting, support for resiliency operations and 1097 policies, and an enhanced ability to balance load. 1099 Service Function Paths create a services topology, and OAM performs 1100 various functions within this service layer. Furthermore, SFC OAM 1101 follows the same architectural principles of SFC in general. For 1102 example, topological independence (including the ability to run OAM 1103 over various overlay technologies) and classification-based policy. 1105 We can subdivide the SFC OAM architecture in two parts: 1107 o In-band: OAM packets follow the same path and share fate with user 1108 packets, within the service topology. For this, they also follow 1109 the architectural principle of consistent policy identifiers, and 1110 use the same path IDs as the service chain data packets. Load 1111 balancing and SFC encapsulation with packet forwarding are 1112 particularly important here. 1114 o Out-of-band: reporting beyond the actual data plane. An 1115 additional layer beyond the data-plane OAM allows for additional 1116 alerting and measurements. 1118 This architecture prescribes end-to-end SFP OAM functions, which 1119 implies SFF understanding of whether an in-band packet is an OAM or 1120 user packet. However, service function validation is outside of the 1121 scope of this architecture, and application-level OAM is not what 1122 this architecture prescribes. 1124 Some of the detailed functions performed by SFC OAM include fault 1125 detection and isolation in a Service Function Path or a Service 1126 Function, verification that connectivity using SFPs is both effective 1127 and directing packets to the intended service functions, service path 1128 tracing, diagnostic and fault isolation, alarm reporting, performance 1129 measurement, locking and testing of service functions, validation 1130 with the control plane (see Section 5.2), and also allow for vendor- 1131 specific as well as experimental functions. SFC should leverage, and 1132 if needed extend relevant existing OAM mechanisms. 1134 5.8. Resilience and Redundancy 1136 As a practical operational requirement, any service chaining solution 1137 needs to be able to respond effectively, and usually very quickly, to 1138 failure conditions. These may be failures of connectivity in the 1139 network between SFFs, failures of SFFs, or failures of SFs. Per-SF 1140 state, as for example stateful-firewall state, is the responsibility 1141 of the SF, and not addressed by this architecture. 1143 Multiple techniques are available to address this issue. Solutions 1144 can describe both what they require and what they allow to address 1145 failure. Solutions can make use of flexible specificity of service 1146 function paths, if the SFF can be given enough information in a 1147 timely fashion to do this. Solutions can also make use of MAC or IP 1148 level redundancy mechanisms such as VRRP. Also, particularly for SF 1149 failures, load balancers co-located with the SFF or as part of the 1150 service function delivery mechanism can provide such robustness. 1152 Similarly, operational requirements imply resilience in the face of 1153 load changes. While mechanisms for managing (e.g., monitoring, 1154 instantiating, loading images, providing configuration to service 1155 function chaining control, deleting, etc.) virtual machines are out 1156 of scope for this architecture, solutions can and are aided by 1157 describing how they can make use of scaling mechanisms. 1159 6. Security Considerations 1161 The architecture described here is different from the current model, 1162 and moving to the new model could lead to different security 1163 arrangements and modeling. In the SFC architecture, a relatively 1164 static topologically-dependent deployment model is replaced with the 1165 chaining of sets of service functions. This can change the flow of 1166 data through the network, and the security and privacy considerations 1167 of the protocol and deployment will need to be reevaluated in light 1168 of the new model. 1170 Security considerations apply to the realization of this 1171 architecture, in particular to the documents that will define 1172 protocols. Such realization ought to provide means to protect 1173 against security and privacy attacks in the areas hereby described. 1175 Building from the categorization of [RFC7498], we can largely divide 1176 the security considerations in four areas: 1178 Service Overlay: Underneath the Service Function Forwarders, the 1179 components that are responsible for performing the transport 1180 forwarding consult the outer-transport encapsulation for 1181 underlay forwarding. Used transport mechanisms should satisfy 1182 the security requirements of the specific SFC deployment. These 1183 requirements typically include varying degrees of traffic 1184 separation, protection against different attacks (e.g., 1185 spoofing, man-in-the-middle, brute-force, or insertion attacks), 1186 and can also include authenticity and integrity checking, and/or 1187 confidentiality provisions, for both the network overlay 1188 transport and traffic it encapsulates. 1190 Boundaries: Specific requirements may need to be enforced at the 1191 boundaries of an SFC-enabled domain. These include, for 1192 example, to avoid leaking SFC information, and to protect its 1193 borders against various forms of attacks. If untrusted parties 1194 can inject packets which will be treated as being properly 1195 classified for service chaining, there are a large range of 1196 attacks which can be mounted against the resulting system. 1197 Depending upon deployment details, these likely include spoofing 1198 packets from users and creating DDoS and reflection attacks of 1199 various kinds. Thus, when a transport mechanisms are selected 1200 for use with SFC, they MUST ensure that outside parties can not 1201 inject SFC packets which will be accepted for processing into 1202 the domain. This border security MUST include any tunnels to 1203 other domains. If those tunnels are to be used for SFC without 1204 reclassification, then the tunnel MUST include additional 1205 techniques to ensure the integrity and validity of such packets. 1207 Classification: Classification is used at the ingress edge of an 1208 SFC-enabled domain. Policy for this classification is done 1209 using a plurality of methods. Whatever method is used needs to 1210 consider a range of security issues. These include appropriate 1211 authentication and authorization of classification policy, 1212 potential confidentiality issues of that policy, protection 1213 against corruption, and proper application of policy with needed 1214 segregation of application. This includes proper controls on 1215 the policies which drive the application of the SFC 1216 Encapsulation and associated metadata to packets. Similar 1217 issues need to be addressed if classification is performed 1218 within a service chaining domain, i.e., re-classification. 1220 SFC Encapsulation: The SFC Encapsulation provides at a minimum SFP 1221 identification, and carries metadata. An operator may consider 1222 the SFC Metadata as sensitive. From a privacy perspective, a 1223 user may be concerned about the operator revealing data about 1224 (and not belonging to) the customer. Therefore, solutions 1225 should consider whether there is a risk of sensitive information 1226 slipping out of the operators control. Issues of information 1227 exposure should also consider flow analysis. Further, when a 1228 specific metadata element is defined, it should be carefully 1229 considered whether origin authentication is needed for it. 1231 A classifier may have privileged access to information about a 1232 packet or inside a packet (see Section 3, bullet 4, and 1233 Section 4.9) that is then communicated in the metadata. The 1234 threat of leaking this private data needs to be mitigated 1235 [RFC6973]. As one example, if private data is represented by an 1236 identifier, then a new identifier can be allocated, such that 1237 the mapping from the private data to the new identifier is not 1238 broadly shared. 1240 Some metadata added to and carried in SFC packets is sensitive 1241 for various reasons, including potentially revealing personally 1242 identifying information. Realizations of the architecture MUST 1243 protect to ensure that such information is handled with suitable 1244 care and precautions against inappropriate dissemination of the 1245 information. This can have implications to the data plane, the 1246 control plane, or both. Data plane protocol definitions for SFC 1247 can include suitable provision for protect such information for 1248 use when handling sensitive information, with packet or SFP 1249 granularity. Equally, the control mechanisms use with SFC can 1250 have provisions to determine that such mechanisms are available, 1251 and to ensure that they are used when needed. Inability to do 1252 so needs to result in error indications to appropriate 1253 management systems. In particular, when the control systems 1254 know that sensitive information may potentially be added to 1255 packets at certain points on certain service chains, the control 1256 mechanism MUST verify that appropriate protective treatment of 1257 NSH information is available from the point where the 1258 information is added to the point where it will be removed. If 1259 such mechanisms are unavailable, error notifications SHOULD be 1260 generated. 1262 Additionally, SFC OAM Functions need to not negatively affect the 1263 security considerations of an SFC-enabled domain. 1265 Finally, all entities (software or hardware) interacting with the 1266 service chaining mechanisms need to provide means of security against 1267 malformed, poorly configured (deliberate or not) protocol constructs 1268 and loops. These considerations are largely the same as those in any 1269 network, particularly an overlay network. 1271 7. Contributors and Acknowledgments 1273 The editors would like to thank Sam Aldrin, Alia Atlas, Nicolas 1274 Bouthors, Stewart Bryant, Linda Dunbar, Alla Goldner, Ken Gray, Barry 1275 Greene, Anil Gunturu, David Harrington, Shunsuke Homma, Dave Hood, 1276 Chris Inacio, Nagendra Kumar, Hongyu Li, Andrew Malis, Guy Meador 1277 III, Kengo Naito, Thomas Narten, Ron Parker, Reinaldo Penno, Naiming 1278 Shen, Xiaohu Xu, and Lucy Yong for a thorough review and useful 1279 comments. 1281 The initial version of this "Service Function Chaining (SFC) 1282 Architecture" document is the result of merging two previous 1283 documents, and this section lists the aggregate of authors, editors, 1284 contributors and acknowledged participants, all who provided 1285 important ideas and text that fed into this architecture. 1287 [I-D.boucadair-sfc-framework]: 1289 Authors: 1291 Mohamed Boucadair 1292 Christian Jacquenet 1293 Ron Parker 1294 Diego R. Lopez 1295 Jim Guichard 1296 Carlos Pignataro 1298 Contributors: 1300 Parviz Yegani 1301 Paul Quinn 1302 Linda Dunbar 1304 Acknowledgements: 1306 Many thanks to D. Abgrall, D. Minodier, Y. Le Goff, D. 1307 Cheng, R. White, and B. Chatras for their review and 1308 comments. 1310 [I-D.quinn-sfc-arch]: 1312 Authors: 1314 Paul Quinn (editor) 1315 Joel Halpern (editor) 1317 Contributors: 1319 Puneet Agarwal 1320 Andre Beliveau 1321 Kevin Glavin 1322 Ken Gray 1323 Jim Guichard 1324 Surendra Kumar 1325 Darrel Lewis 1326 Nic Leymann 1327 Rajeev Manur 1328 Thomas Nadeau 1329 Carlos Pignataro 1330 Michael Smith 1331 Navindra Yadav 1333 Acknowledgements: 1335 The authors would like to thank David Ward, Abhijit Patra, 1336 Nagaraj Bagepalli, Darrel Lewis, Ron Parker, Lucy Yong and 1337 Christian Jacquenet for their review and comments. 1339 8. IANA Considerations 1341 [RFC Editor: please remove this section prior to publication.] 1343 This document has no IANA actions. 1345 9. Informative References 1347 [I-D.boucadair-sfc-framework] 1348 Boucadair, M., Jacquenet, C., Parker, R., Lopez, D., 1349 Guichard, J., and C. Pignataro, "Service Function 1350 Chaining: Framework & Architecture", draft-boucadair-sfc- 1351 framework-02 (work in progress), February 2014. 1353 [I-D.quinn-sfc-arch] 1354 Quinn, P. and J. Halpern, "Service Function Chaining (SFC) 1355 Architecture", draft-quinn-sfc-arch-05 (work in progress), 1356 May 2014. 1358 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1359 Requirement Levels", BCP 14, RFC 2119, March 1997. 1361 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 1362 Address Translator (Traditional NAT)", RFC 3022, January 1363 2001. 1365 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 1366 NAT64: Network Address and Protocol Translation from IPv6 1367 Clients to IPv4 Servers", RFC 6146, April 2011. 1369 [RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix 1370 Translation", RFC 6296, June 2011. 1372 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 1373 Morris, J., Hansen, M., and R. Smith, "Privacy 1374 Considerations for Internet Protocols", RFC 6973, July 1375 2013. 1377 [RFC7498] Quinn, P. and T. Nadeau, "Problem Statement for Service 1378 Function Chaining", RFC 7498, April 2015. 1380 Authors' Addresses 1382 Joel Halpern (editor) 1383 Ericsson 1385 Email: jmh@joelhalpern.com 1387 Carlos Pignataro (editor) 1388 Cisco Systems, Inc. 1390 Email: cpignata@cisco.com