From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc7665.txt | 1795 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1795 insertions(+) create mode 100644 doc/rfc/rfc7665.txt (limited to 'doc/rfc/rfc7665.txt') diff --git a/doc/rfc/rfc7665.txt b/doc/rfc/rfc7665.txt new file mode 100644 index 0000000..4b5e889 --- /dev/null +++ b/doc/rfc/rfc7665.txt @@ -0,0 +1,1795 @@ + + + + + + +Internet Engineering Task Force (IETF) J. Halpern, Ed. +Request for Comments: 7665 Ericsson +Category: Informational C. Pignataro, Ed. +ISSN: 2070-1721 Cisco + October 2015 + + + Service Function Chaining (SFC) Architecture + +Abstract + + This document describes an architecture for the specification, + creation, and ongoing maintenance of Service Function Chains (SFCs) + in a network. It includes architectural concepts, principles, and + components used in the construction of composite services through + deployment of SFCs, with a focus on those to be standardized in the + IETF. This document does not propose solutions, protocols, or + extensions to existing protocols. + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for informational purposes. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Not all documents + approved by the IESG are a candidate for any level of Internet + Standard; see Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc7665. + + + + + + + + + + + + + + + + + +Halpern & Pignataro Informational [Page 1] + +RFC 7665 SFC Architecture October 2015 + + +Copyright Notice + + Copyright (c) 2015 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Halpern & Pignataro Informational [Page 2] + +RFC 7665 SFC Architecture October 2015 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 + 1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 1.2. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 5 + 1.3. Specification of Requirements . . . . . . . . . . . . . . 5 + 1.4. Definition of Terms . . . . . . . . . . . . . . . . . . . 6 + 2. Architectural Concepts . . . . . . . . . . . . . . . . . . . 8 + 2.1. Service Function Chains . . . . . . . . . . . . . . . . . 8 + 2.2. Service Function Chain Symmetry . . . . . . . . . . . . . 9 + 2.3. Service Function Paths . . . . . . . . . . . . . . . . . 10 + 2.3.1. Service Function Chains, Service Function Paths, and + Rendered Service Path . . . . . . . . . . . . . . . . 11 + 3. Architecture Principles . . . . . . . . . . . . . . . . . . . 12 + 4. Core SFC Architecture Components . . . . . . . . . . . . . . 13 + 4.1. SFC Encapsulation . . . . . . . . . . . . . . . . . . . . 14 + 4.2. Service Function (SF) . . . . . . . . . . . . . . . . . . 15 + 4.3. Service Function Forwarder (SFF) . . . . . . . . . . . . 15 + 4.3.1. Transport-Derived SFF . . . . . . . . . . . . . . . . 17 + 4.4. SFC-Enabled Domain . . . . . . . . . . . . . . . . . . . 17 + 4.5. Network Overlay and Network Components . . . . . . . . . 18 + 4.6. SFC Proxy . . . . . . . . . . . . . . . . . . . . . . . . 18 + 4.7. Classification . . . . . . . . . . . . . . . . . . . . . 19 + 4.8. Reclassification and Branching . . . . . . . . . . . . . 19 + 4.9. Shared Metadata . . . . . . . . . . . . . . . . . . . . . 20 + 5. Additional Architectural Concepts . . . . . . . . . . . . . . 21 + 5.1. The Role of Policy . . . . . . . . . . . . . . . . . . . 21 + 5.2. SFC Control Plane . . . . . . . . . . . . . . . . . . . . 21 + 5.3. Resource Control . . . . . . . . . . . . . . . . . . . . 22 + 5.4. Infinite Loop Detection and Avoidance . . . . . . . . . . 23 + 5.5. Load-Balancing Considerations . . . . . . . . . . . . . . 23 + 5.6. MTU and Fragmentation Considerations . . . . . . . . . . 24 + 5.7. SFC OAM . . . . . . . . . . . . . . . . . . . . . . . . . 25 + 5.8. Resilience and Redundancy . . . . . . . . . . . . . . . . 26 + 6. Security Considerations . . . . . . . . . . . . . . . . . . . 27 + 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 + 7.1. Normative References . . . . . . . . . . . . . . . . . . 29 + 7.2. Informative References . . . . . . . . . . . . . . . . . 29 + Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 30 + Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 31 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 + + + + + + + + + + +Halpern & Pignataro Informational [Page 3] + +RFC 7665 SFC Architecture October 2015 + + +1. Introduction + + The delivery of end-to-end services often requires various service + functions. These include traditional network service functions such + as firewalls and traditional IP Network Address Translators (NATs), + as well as application-specific functions. The definition and + instantiation of an ordered set of service functions and subsequent + "steering" of traffic through them is termed Service Function + Chaining (SFC). + + This document describes an architecture used for the creation and + ongoing maintenance of Service Function Chains (SFCs) in a network. + It includes architectural concepts, principles, and components, with + a focus on those to be standardized in the IETF. SFCs enable + composite services that are constructed from one or more service + functions. + + An overview of the issues associated with the deployment of end-to- + end service function chains, abstract sets of service functions and + their ordering constraints that create a composite service, and the + subsequent "steering" of traffic flows through said service + functions, is described in [RFC7498]. + + The current service function deployment models are relatively static, + coupled to network topology and physical resources, greatly reducing + or eliminating the ability of an operator to introduce new services + or dynamically create service function chains. This architecture + presents a model addressing the problematic aspects of existing + service deployments, including topological independence and + configuration complexity. + +1.1. Scope + + This document defines the architecture for Service Function Chaining + (SFC) as standardized in the IETF. The SFC architecture is + predicated on topological independence from the underlying forwarding + topology. + + In this architecture, packets are classified on ingress for handling + by the required set of Service Functions (SFs) in the SFC-enabled + domain and are then forwarded through that set of functions for + processing by each function in turn. Packets may be reclassified as + a result of this processing. + + The architecture described in this document is independent of the + planned usage of the network and deployment context and thus, for + example, is applicable to both fixed and mobile networks as well as + being useful in many data center applications. + + + +Halpern & Pignataro Informational [Page 4] + +RFC 7665 SFC Architecture October 2015 + + + The architecture described herein is assumed to be applicable to a + single network administrative domain. While it is possible for the + architectural principles and components to be applied to inter-domain + SFCs, these are left for future study. + +1.2. Assumptions + + The following assumptions are made: + + o There is no standard definition or characterization applicable to + all SFs, and thus the architecture considers each SF as an opaque + processing element. + + o There is no global or standard list of SFs enabled in a given + administrative domain. The set of SFs enabled in a given domain + is a function of the currently active services that may vary with + time and according to the networking environment. + + o There is no global or standard SF chaining logic. The ordered set + of SFs that needs to be applied to deliver a given service is + specific to each administrative entity. + + o The chaining of SFs and the criteria to invoke them are specific + to each administrative entity that operates an SF-enabled domain. + + o Several SF chaining policies can be simultaneously applied within + an administrative domain to meet various business requirements. + + o The underlay is assumed to provide the necessary connectivity to + interconnect the Service Function Forwarders (SFFs; see + Section 1.4), but the architecture places no constraints on how + that connectivity is realized other than it have the required + bandwidth, latency, and jitter to support the SFC. + + o No assumption is made on how Forwarding Information Bases (FIBs) + and Routing Information Bases (RIBs) of involved nodes are + populated. + + o How to bind traffic to a given SF chain is policy-based. + +1.3. Specification of Requirements + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in [RFC2119]. + + + + + + +Halpern & Pignataro Informational [Page 5] + +RFC 7665 SFC Architecture October 2015 + + +1.4. Definition of Terms + + Network Service: An offering provided by an operator that is + delivered using one or more service functions. This may also be + referred to as a "composite service". The term "service" is + used to denote a "network service" in the context of this + document. + + Note: Beyond this document, the term "service" is overloaded + with varying definitions. For example, to some a service is an + offering composed of several elements within the operator's + network, whereas for others a service, or more specifically a + network service, is a discrete element such as a "firewall". + Traditionally, such services (in the latter sense) host a set of + service functions and have a network locator where the service + is hosted. + + Classification: Locally instantiated matching of traffic flows + against policy for subsequent application of the required set of + network service functions. The policy may be customer/network/ + service specific. + + Classifier: An element that performs Classification. + + Service Function Chain (SFC): A service function chain defines an + ordered set of abstract service functions and ordering + constraints that must be applied to packets and/or frames and/or + flows selected as a result of classification. An example of an + abstract service function is "a firewall". The implied order + may not be a linear progression as the architecture allows for + SFCs that copy to more than one branch, and also allows for + cases where there is flexibility in the order in which service + functions need to be applied. The term "service chain" is often + used as shorthand for service function chain. + + Service Function (SF): A function that is responsible for specific + treatment of received packets. A Service Function can act at + various layers of a protocol stack (e.g., at the network layer + or other OSI layers). As a logical component, a service + function can be realized as a virtual element or be embedded in + a physical network element. One or more Service Functions can + be embedded in the same network element. Multiple occurrences + of the service function can exist in the same administrative + domain. + + One or more service functions can be involved in the delivery of + added-value services. A non-exhaustive list of abstract service + functions includes: firewalls, WAN and application acceleration, + + + +Halpern & Pignataro Informational [Page 6] + +RFC 7665 SFC Architecture October 2015 + + + Deep Packet Inspection (DPI), Lawful Intercept (LI), server load + balancing, NAT44 [RFC3022], NAT64 [RFC6146], NPTv6 [RFC6296], + HOST_ID injection, HTTP Header Enrichment functions, and TCP + optimizer. + + An SF may be SFC encapsulation aware (that is, it receives and + acts on information in the SFC encapsulation) or unaware (in + which case, data forwarded to the SF does not contain the SFC + encapsulation). This is often referred to as "SFC aware" and + "SFC unaware", respectively. + + Service Function Forwarder (SFF): A service function forwarder is + responsible for forwarding traffic to one or more connected + service functions according to information carried in the SFC + encapsulation, as well as handling traffic coming back from the + SF. Additionally, an SFF is responsible for delivering traffic + to a classifier when needed and supported, transporting traffic + to another SFF (in the same or different type of overlay), and + terminating the Service Function Path (SFP). + + Metadata: Provides the ability to exchange context information + between classifiers and SFs, and among SFs. + + Service Function Path (SFP): The service function path is a + constrained specification of where packets assigned to a certain + service function path must go. While it may be so constrained + as to identify the exact locations, it can also be less + specific. The SFP provides a level of indirection between the + fully abstract notion of service chain as a sequence of abstract + service functions to be delivered, and the fully specified + notion of exactly which SFF/SFs the packet will visit when it + actually traverses the network. By allowing the control + components to specify this level of indirection, the operator + may control the degree of SFF/SF selection authority that is + delegated to the network. + + SFC Encapsulation: The SFC encapsulation provides, at a minimum, SFP + identification, and is used by the SFC-aware functions, such as + the SFF and SFC-aware SFs. The SFC encapsulation is not used + for network packet forwarding. In addition to SFP + identification, the SFC encapsulation carries metadata including + data-plane context information. + + + + + + + + + +Halpern & Pignataro Informational [Page 7] + +RFC 7665 SFC Architecture October 2015 + + + Rendered Service Path (RSP): Within an SFP, packets themselves are + of course transmitted from and to specific places in the + network, visiting a specific sequence of SFFs and SFs. This + sequence of actual visits by a packet to specific SFFs and SFs + in the network is known as the Rendered Service Path (RSP). + This definition is included here for use by later documents, + such as when solutions may need to discuss the actual sequence + of locations the packets visit. + + SFC-Enabled Domain: A network or region of a network that implements + SFC. An SFC-enabled domain is limited to a single network + administrative domain. + + SFC Proxy: Removes and inserts SFC encapsulation on behalf of an + SFC-unaware service function. SFC proxies are logical elements. + +2. Architectural Concepts + + The following sections describe the foundational concepts of service + function chaining and the SFC architecture. + + Service function chaining enables the creation of composite (network) + services that consist of an ordered set of SFs that must be applied + to packets and/or frames and/or flows selected as a result of + classification. Each SF is referenced using an identifier that is + unique within an SF-enabled domain. + + Service function chaining is a concept that provides for more than + just the application of an ordered set of SFs to selected traffic; + rather, it describes a method for deploying SFs in a way that enables + dynamic ordering and topological independence of those SFs as well as + the exchange of metadata between participating entities. + +2.1. Service Function Chains + + In most networks, services are constructed as abstract sequences of + SFs that represent SFCs. At a high level, an SFC is an abstracted + view of a service that specifies the set of required SFs as well as + the order in which they must be executed. Graphs, as illustrated in + Figure 1, define an SFC, where each graph node represents the + required existence of at least one abstract SF. Such graph nodes + (SFs) can be part of zero, one, or many SFCs. A given graph node + (SF) can appear one time or multiple times in a given SFC. + + SFCs can start from the origination point of the service function + graph (i.e., node 1 in Figure 1), or from any subsequent node in the + graph. As shown, SFs may therefore become branching nodes in the + graph, with those SFs selecting edges that move traffic to one or + + + +Halpern & Pignataro Informational [Page 8] + +RFC 7665 SFC Architecture October 2015 + + + more branches. The top and middle graphs depict such a case, where a + second classification event occurs after node 2, and a new graph is + selected (i.e., node 3 instead of node 6). The bottom graph + highlights the concept of a cycle, in which a given SF (e.g., node 7 + in the depiction) can be visited more than once within a given + service chain. An SFC can have more than one terminus. + + ,-+-. ,---. ,---. ,---. + / \ / \ / \ / \ + ( 1 )+--->( 2 )+---->( 6 )+---->( 8 ) + \ / \ / \ / \ / + `---' `---' `---' `---' + + ,-+-. ,---. ,---. ,---. ,---. + / \ / \ / \ / \ / \ + ( 1 )+--->( 2 )+---->( 3 )+---->( 7 )+---->( 9 ) + \ / \ / \ / \ / \ / + `---' `---' `---' `---' `---' + + ,-+-. ,---. ,---. ,---. ,---. + / \ / \ / \ / \ / \ + ( 1 )+--->( 7 )+---->( 8 )+---->( 4 )+---->( 7 ) + \ / \ / \ / \ / \ / + `---' `---' `---' `---' `---' + + Figure 1: Service Function Chain Graphs + + The concepts of classification, reclassification, and branching are + covered in subsequent sections of this architecture (see Sections 4.7 + and 4.8). + +2.2. Service Function Chain Symmetry + + SFCs may be unidirectional or bidirectional. A unidirectional SFC + requires that traffic be forwarded through the ordered SFs in one + direction (sf1 -> sf2 -> sf3), whereas a bidirectional SFC requires a + symmetric path (sf1 -> sf2 -> sf3 and sf3 -> sf2 -> sf1), and in + which the SF instances are the same in opposite directions. A hybrid + SFC has attributes of both unidirectional and bidirectional SFCs; + that is to say some SFs require symmetric traffic, whereas other SFs + do not process reverse traffic or are independent of the + corresponding forward traffic. + + SFCs may contain cycles; that is traffic may need to traverse one or + more SFs within an SFC more than once. Solutions will need to ensure + suitable disambiguation for such situations. + + + + + +Halpern & Pignataro Informational [Page 9] + +RFC 7665 SFC Architecture October 2015 + + + The architectural allowance that is made for SFPs that delegate + choice to the network for which SFs and/or SFFs a packet will visit + creates potential issues here. A solution that allows such + delegation needs to also describe how the solution ensures that those + service chains requiring service function chain symmetry can achieve + that. + + Further, there are state trade-offs in symmetry. Symmetry may be + realized in several ways depending on the SFF and classifier + functionality. In some cases, "mirrored" classification (i.e., from + Source to Destination and from Destination to Source) policy may be + deployed, whereas in others shared state between classifiers may be + used to ensure that symmetric flows are correctly identified, then + steered along the required SFP. At a high level, there are various + common cases. In a non-exhaustive way, there can be for example: + + o A single classifier (or a small number of classifiers), in which + case both incoming and outgoing flows could be recognized at the + same classifier, so the synchronization would be feasible by + internal mechanisms internal to the classifier. + + o Stateful classifiers where several classifiers may be clustered + and share state. + + o Fully distributed classifiers, where synchronization needs to be + provided through unspecified means. + + o A classifier that learns state from the egress packets/flows that + is then used to provide state for the return packets/flow. + + o Symmetry may also be provided by stateful forwarding logic in the + SFF in some implementations. + + This is a non-comprehensive list of common cases. + +2.3. Service Function Paths + + A Service Function Path (SFP) is a mechanism used by service chaining + to express the result of applying more granular policy and + operational constraints to the abstract requirements of a service + chain (SFC). This architecture does not mandate the degree of + specificity of the SFP. Architecturally, within the same SFC-enabled + domain, some SFPs may be fully specified, selecting exactly which SFF + and which SF are to be visited by packets using that SFP, while other + SFPs may be quite vague, deferring to the SFF the decisions about the + exact sequence of steps to be used to realize the SFC. The + specificity may be anywhere in between these extremes. + + + + +Halpern & Pignataro Informational [Page 10] + +RFC 7665 SFC Architecture October 2015 + + + As an example of such an intermediate specificity, there may be two + SFPs associated with a given SFC, where one SFP specifies that any + order of SFF and SF may be used as long as it is within Data Center + 1, and where the second SFP allows the same latitude, but only within + Data Center 2. + + Thus, the policies and logic of SFP selection or creation (depending + upon the solution) produce what may be thought of as a constrained + version of the original SFC. Since multiple policies may apply to + different traffic that uses the same SFC, it also follows that there + may be multiple SFPs associated with a single SFC. + + The architecture allows for the same SF to be reachable through + multiple SFFs. In these cases, some SFPs may constrain which SFF is + used to reach which SF, while some SFPs may leave that decision to + the SFF itself. + + Further, the architecture allows for two or more SFs to be attached + to the same SFF, and possibly connected via internal means allowing + more effective communication. In these cases, some solutions or + deployments may choose to use some form of internal inter-process or + inter-VM messaging (communication behind the virtual switching + element) that is optimized for such an environment. This must be + coordinated with the SFF so that it can properly perform its job. + Implementation details of such mechanisms are considered out of scope + for this document, and can include a spectrum of methods: for + example, situations including all next-hops explicitly, others where + a list of possible next-hops is provided and the selection is local, + or cases with just an identifier, where all resolution is local. + + This architecture also allows the same SF to be part of multiple + SFPs. + +2.3.1. Service Function Chains, Service Function Paths, and Rendered + Service Path + + As an example of this progressive refinement, consider a Service + Function Chain (SFC) that states that packets using this chain should + be delivered to a firewall and a caching engine. + + A Service Function Path (SFP) could refine this, considering that + this architecture does not mandate the degree of specificity an SFP + has to have. It might specify that the firewall and caching engine + are both to be in a specific data center (e.g., in DC1), or it might + specify exactly which instance of each firewall and caching engine is + to be used. + + + + + +Halpern & Pignataro Informational [Page 11] + +RFC 7665 SFC Architecture October 2015 + + + The Rendered Service Path (RSP) is the actual sequence of SFFs and + SFs that the packets will actually visit. So if the SFP picked the + DC, the RSP would be more specific. + +3. Architecture Principles + + Service function chaining is predicated on several key architectural + principles: + + 1. Topological independence: No changes to the underlay network + forwarding topology -- implicit, or explicit -- are needed to + deploy and invoke SFs or SFCs. + + 2. Plane separation: Dynamic realization of SFPs is separated from + packet handling operations (e.g., packet forwarding). + + 3. Classification: Traffic that satisfies classification rules is + forwarded according to a specific SFP. For example, + classification can be as simple as an explicit forwarding entry + that forwards all traffic from one address into the SFP. + Multiple classification points are possible within an SFC (i.e., + forming a service graph), thus enabling changes/updates to the + SFC by SFs. + + Classification can occur at varying degrees of granularity; for + example, classification can use a 5-tuple, a transport port or + set of ports, part of the packet payload, it can be the result of + high-level inspections, or it can come from external systems. + + 4. Shared Metadata: Metadata/context data can be shared amongst SFs + and classifiers, between SFs, and between external systems and + SFs (e.g., orchestration). + + One use of metadata is to provide and share the result of + classification (that occurs within the SFC-enabled domain, or + external to it) along an SFP. For example, an external + repository might provide user/subscriber information to a service + chain classifier. This classifier could in turn impose that + information in the SFC encapsulation for delivery to the + requisite SFs. The SFs could in turn utilize the user/subscriber + information for local policy decisions. Metadata can also share + SF output along the SFP. + + 5. Service definition independence: The SFC architecture does not + depend on the details of SFs themselves. + + + + + + +Halpern & Pignataro Informational [Page 12] + +RFC 7665 SFC Architecture October 2015 + + + 6. Service function chain independence: The creation, modification, + or deletion of an SFC has no impact on other SFCs. The same is + true for SFPs. + + 7. Heterogeneous control/policy points: The architecture allows SFs + to use independent mechanisms (out of scope for this document) to + populate and resolve local policy and (if needed) local + classification criteria. + +4. Core SFC Architecture Components + + The SFC Architecture is built out of architectural building blocks + that are logical components; these logical components are + classifiers, Service Function Forwarders (SFFs), the Service + Functions (SFs) themselves, and SFC proxies. While this architecture + describes functionally distinct logical components and promotes + transport independence, they could be realized and combined in + various ways in deployed products, and could be combined with an + overlay. + + They are interconnected using the SFC encapsulation. This results in + a high-level logical architecture of an SFC-enabled domain that + comprises: + + o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . + . +--------------+ +------------------~~~ + . | Service | SFC | Service +---+ +---+ + . |Classification| Encapsulation | Function |sf1|...|sfn| + +---->| Function |+---------------->| Path +---+ +---+ + . +--------------+ +------------------~~~ + . SFC-enabled Domain + o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . + + Figure 2: Service Function Chain Architecture + + The following subsections provide details on each logical component + that form the basis of the SFC architecture. A detailed overview of + how some of these architectural components interact is provided in + Figure 3: + + + + + + + + + + + + +Halpern & Pignataro Informational [Page 13] + +RFC 7665 SFC Architecture October 2015 + + + +----------------+ +----------------+ + | SFC-aware | | SFC-unaware | + |Service Function| |Service Function| + +-------+--------+ +-------+--------+ + | | + SFC Encapsulation No SFC Encapsulation + | SFC | + +---------+ +----------------+ Encapsulation +---------+ + |SFC-Aware|-----------------+ \ +------------|SFC Proxy| + | SF | ... ----------+ \ \ / +---------+ + +---------+ \ \ \ / + +-------+--------+ + | SF Forwarder | + | (SFF) | + +-------+--------+ + | + SFC Encapsulation + | + ... SFC-enabled Domain ... + | + Network Overlay Transport + | + _,....._ + ,-' `-. + / `. + | Network | + `. / + `.__ __,-' + `'''' + + Figure 3: SFC Architecture Components After Initial Classification + + Please note that the depiction in Figure 3 shows packets after + initial classification, and therefore includes the SFC encapsulation. + Although not included in Figure 3, the classifier is an SFC + architectural component. + +4.1. SFC Encapsulation + + The SFC encapsulation enables service function path selection. It + also enables the sharing of metadata/context information when such + metadata exchange is required. + + The SFC encapsulation carries explicit information used to identify + the SFP. However, the SFC encapsulation is not a transport + encapsulation itself: it is not used to forward packets within the + network fabric. If packets need to flow between separate physical + platforms, the SFC encapsulation relies on an outer network + + + +Halpern & Pignataro Informational [Page 14] + +RFC 7665 SFC Architecture October 2015 + + + transport. Transit forwarders -- such as router and switches -- + forward SFC encapsulated packets based on the outer (non-SFC) + encapsulation. + + One of the key architecture principles of SFC is that the SFC + encapsulation remain transport independent. As such, any network + transport protocol may be used to carry the SFC encapsulated traffic. + +4.2. Service Function (SF) + + The concept of an SF evolves; rather than being viewed as a bump in + the wire, an SF becomes a resource within a specified administrative + domain that is available for consumption as part of a composite + service. SFs send/receive data to/from one or more SFFs. SFC-aware + SFs receive this traffic with the SFC encapsulation. + + While the SFC architecture defines the concept and specifies some + characteristics of a new encapsulation -- the SFC encapsulation -- + and several logical components for the construction of SFCs, existing + SF implementations may not have the capabilities to act upon or fully + integrate with the new SFC encapsulation. In order to provide a + mechanism for such SFs to participate in the architecture, an SFC + proxy function is defined (see Section 4.6). The SFC proxy acts as a + gateway between the SFC encapsulation and SFC-unaware SFs. The + integration of SFC-unaware service functions is discussed in more + detail in the SFC proxy section. + + This architecture allows an SF to be part of multiple SFPs and SFCs. + +4.3. Service Function Forwarder (SFF) + + The SFF is responsible for forwarding packets and/or frames received + from the network to one or more SFs associated with a given SFF using + information conveyed in the SFC encapsulation. Traffic from SFs + eventually returns to the same SFF, which is responsible for + injecting traffic back onto the network. Some SFs, such as + firewalls, could also consume a packet. + + The collection of SFFs and associated SFs creates a service-plane + overlay in which SFC-aware SFs, as well as SFC-unaware SFs reside. + Within this service plane, the SFF component connects different SFs + that form a service function path. + + SFFs maintain the requisite SFP forwarding information. SFP + forwarding information is associated with a service path identifier + that is used to uniquely identify an SFP. The service forwarding + state enables an SFF to identify which SFs of a given SFP should be + applied, and in what order, as traffic flows through the associated + + + +Halpern & Pignataro Informational [Page 15] + +RFC 7665 SFC Architecture October 2015 + + + SFP. While there may appear to the SFF to be only one available way + to deliver the given SF, there may also be multiple choices allowed + by the constraints of the SFP. + + If there are multiple choices, the SFF needs to preserve the property + that all packets of a given flow are handled the same way, since the + SF may well be stateful. Additionally, the SFF may preserve the + handling of packets based on other properties on top of a flow, such + as a subscriber, session, or application instance identification. + + The SFF also has the information that allows it to forward packets to + the next SFF after applying local service functions. Again, while + there may be only a single choice available, the architecture allows + for multiple choices for the next SFF. As with SFs, the solution + needs to operate such that the behavior with regard to specific flows + (see the Rendered Service Path) is stable. The selection of + available SFs and next SFFs may be interwoven when an SFF supports + multiple distinct service functions and the same service function is + available at multiple SFFs. Solutions need to be clear about what is + allowed in these cases. + + Even when the SFF supports and utilizes multiple choices, the + decision as to whether to use flow-specific mechanisms or coarser- + grained means to ensure that the behavior of specific flows is stable + is a matter for specific solutions and specific implementations. + + The SFF component has the following primary responsibilities: + + 1. SFP forwarding: Traffic arrives at an SFF from the network. The + SFF determines the appropriate SF the traffic should be forwarded + to via information contained in the SFC encapsulation. After SF + processing, the traffic is returned to the SFF, and, if needed, + is forwarded to another SF associated with that SFF. If there is + another non-local (i.e., different SFF) hop in the SFP, the SFF + further encapsulates the traffic in the appropriate network + transport protocol and delivers it to the network for delivery to + the next SFF along the path. Related to this forwarding + responsibility, an SFF should be able to interact with metadata. + + 2. Terminating SFPs: An SFC is completely executed when traffic has + traversed all required SFs in a chain. When traffic arrives at + the SFF after the last SF has finished processing it, the final + SFF knows from the service forwarding state that the SFC is + complete. The SFF removes the SFC encapsulation and delivers the + packet back to the network for forwarding. + + + + + + +Halpern & Pignataro Informational [Page 16] + +RFC 7665 SFC Architecture October 2015 + + + 3. Maintaining flow state: In some cases, the SFF may be stateful. + It creates flows and stores flow-centric information. This state + information may be used for a range of SFP-related tasks such as + ensuring consistent treatment of all packets in a given flow, + ensuring symmetry, or for state-aware SFC Proxy functionality + (see Section 4.8). + +4.3.1. Transport-Derived SFF + + SFP forwarding, as described above, directly depends upon the use of + the service path information contained in the SFC encapsulation. + However, existing implementations may not be able to act on the SFC + encapsulation. These platforms may opt to use existing transport + information, if it can be arranged, to provide explicit service path + information. + + This results in the same architectural behavior and meaning for SFP + forwarding and service function paths. It is the responsibility of + the control components to ensure that the transport path executed in + such a case is fully aligned with the path identified by the + information in the service chaining encapsulation. + +4.4. SFC-Enabled Domain + + Specific features may need to be enforced at the boundaries of an + SFC-enabled domain, for example to avoid leaking SFC information. + Using the term "node" to refer generically to an entity that is + performing a set of functions, in this context, an SFC boundary node + denotes a node that connects one SFC-enabled domain to a node either + located in another SFC-enabled domain or in a domain that is SFC- + unaware. + + An SFC boundary node can act as egress or ingress. An SFC Egress + Node denotes an SFC boundary node that handles traffic leaving the + SFC-enabled domain the Egress Node belongs to. Such a node is + required to remove any information specific to the SFC Domain, + typically the SFC encapsulation. Further, from a privacy + perspective, an SFC Egress Node is required to ensure that any + sensitive information added as part of SFC gets removed. In this + context, information may be sensitive due to network concerns or end- + customer concerns. An SFC Ingress Node denotes an SFC boundary node + that handles traffic entering the SFC-enabled domain. In most + solutions and deployments this will need to include a classifier, and + will be responsible for adding the SFC encapsulation to the packet. + + An SFC Proxy and corresponding SFC-unaware service function (see + Figure 3) are inside the SFC-enabled domain. + + + + +Halpern & Pignataro Informational [Page 17] + +RFC 7665 SFC Architecture October 2015 + + +4.5. Network Overlay and Network Components + + Underneath the SFF there are components responsible for performing + the transport (overlay) forwarding. They do not consult the SFC + encapsulation or inner payload for performing this forwarding. They + only consult the outer-transport encapsulation for the transport + (overlay) forwarding. + +4.6. SFC Proxy + + In order for the SFC architecture to support SFC-unaware SFs (e.g., + legacy service functions) a logical SFC proxy function may be used. + This function sits between an SFF and one or more SFs to which the + SFF is directing traffic (see Figure 3). + + The proxy accepts packets from the SFF on behalf of the SF. It + removes the SFC encapsulation, and then uses a local attachment + circuit to deliver packets to SFC-unaware SFs. It also receives + packets back from the SF, reapplies the SFC encapsulation, and + returns them to the SFF for processing along the service function + path. + + Thus, from the point of view of the SFF, the SFC proxy appears to be + part of an SFC-aware SF. + + Communication details between the SFF and the SFC Proxy are the same + as those between the SFF and an SFC-aware SF. The details of that + are not part of this architecture. The details of the communication + methods over the local attachment circuit between the SFC proxy and + the SFC-unaware SF are dependent upon the specific behaviors and + capabilities of that SFC-unaware SF, and thus are also out of scope + for this architecture. + + Specifically, for traffic received from the SFF intended for the SF + the proxy is representing, the SFC proxy: + + o Removes the SFC encapsulation from SFC encapsulated packets. + + o Identifies the required SF to be applied based on available + information including that carried in the SFC encapsulation. + + o Selects the appropriate outbound local attachment circuit through + which the next SF for this SFP is reachable. This is derived from + the identification of the SF carried in the SFC encapsulation, and + may include local techniques. Examples of a local attachment + circuit include, but are not limited to, VLAN, IP-in-IP, Layer 2 + + + + + +Halpern & Pignataro Informational [Page 18] + +RFC 7665 SFC Architecture October 2015 + + + Tunneling Protocol version 3 (L2TPv3), Generic Routing + Encapsulation (GRE), and Virtual eXtensible Local Area Network + (VXLAN). + + o Forwards the original payload via the selected local attachment + circuit to the appropriate SF. + + When traffic is returned from the SF: + + o Applies the required SFC encapsulation. The determination of the + encapsulation details may be inferred by the local attachment + circuit through which the packet and/or frame was received, or via + packet classification, or other local policy. In some cases, + packet ordering or modification by the SF may necessitate + additional classification in order to reapply the correct SFC + encapsulation. + + o Delivers the packet with the SFC encapsulation to the SFF, as + would happen with packets returned from an SFC-aware SF. + +4.7. Classification + + Traffic from the network that satisfies classification criteria is + directed into an SFP and forwarded to the requisite service + function(s). Classification is handled by a service classification + function; initial classification occurs at the ingress to the SFC + domain. The granularity of the initial classification is determined + by the capabilities of the classifier and the requirements of the SFC + policy. For instance, classification might be relatively coarse: all + packets from this port are subject to SFC policy X and directed into + SFP A, or quite granular: all packets matching this 5-tuple are + subject to SFC policy Y and directed into SFP B. + + As a consequence of the classification decision, the appropriate SFC + encapsulation is imposed on the data, and a suitable SFP is selected + or created. Classification results in attaching the traffic to a + specific SFP. + +4.8. Reclassification and Branching + + The SFC architecture supports reclassification (or non-initial + classification) as well. As packets traverse an SFP, + reclassification may occur -- typically performed by a classification + function co-resident with a service function. Reclassification may + result in the selection of a new SFP, an update of the associated + metadata, or both. This is referred to as "branching". + + + + + +Halpern & Pignataro Informational [Page 19] + +RFC 7665 SFC Architecture October 2015 + + + For example, an initial classification results in the selection of + SFP A: DPI_1 --> SLB_8. However, when the DPI service function is + executed, attack traffic is detected at the application layer. DPI_1 + reclassifies the traffic as attack and alters the service path to SFP + B, to include a firewall for policy enforcement: dropping the + traffic: DPI_1 --> FW_4. Subsequent to FW_4, surviving traffic would + be returned to the original SFF. In this simple example, the DPI + service function reclassifies the traffic based on local application + layer classification capabilities (that were not available during the + initial classification step). + + When traffic arrives after being steered through an SFC-unaware SF, + the SFC Proxy must perform reclassification of traffic to determine + the SFP. The SFC Proxy is concerned with re-attaching information + for SFC-unaware SFs, and a stateful SFC Proxy simplifies such + classification to a flow lookup. + +4.9. Shared Metadata + + Sharing metadata allows the network to provide network-derived + information to the SFs, SF-to-SF information exchange, and the + sharing of service-derived information to the network. Some SFCs may + not require metadata exchange. SFC infrastructure enables the + exchange of this shared data along the SFP. The shared metadata + serves several possible roles within the SFC architecture: + + o Allows elements that typically operate independently (e.g., as + "ships in the night") to exchange information. + + o Encodes information about the network and/or data for subsequent + use within the SFP. + + o Creates an identifier used for policy binding by SFs. + + Context information can be derived in several ways: + + o External sources + + o Network node classification + + o Service function classification + + + + + + + + + + +Halpern & Pignataro Informational [Page 20] + +RFC 7665 SFC Architecture October 2015 + + +5. Additional Architectural Concepts + + There are a number of issues that solutions need to address, and that + the architecture informs but does not determine. This section lays + out some of those concepts. + +5.1. The Role of Policy + + Much of the behavior of service chains is driven by operator and per- + customer policy. This architecture is structured to isolate the + policy interactions from the data plane and control logic. + + Specifically, it is assumed that the service chaining control plane + creates the service paths. The service chaining data plane is used + to deliver the classified packets along the service chains to the + intended service functions. + + Policy, in contrast, interacts with the system in other places. + Policies and policy engines may monitor service functions to decide + if additional (or fewer) instances of services are needed. When + applicable, those decisions may in turn result in interactions that + direct the control logic to change the SFP placement or packet + classification rules. + + Similarly, operator service policy, often managed by Operations or + Business Support Systems (OSS or BSS), will frequently determine what + service functions are available. Operator service policies also + determine which sequences of functions are valid and are to be used + or made available. + + The offering of service chains to customers, and the selection of + which service chain a customer wishes to use, are driven by a + combination of operator and customer policies using appropriate + portals in conjunction with the OSS and BSS tools. These selections + then drive the service chaining control logic, which in turn + establishes the appropriate packet classification rules. + +5.2. SFC Control Plane + + The SFC control plane is part of the overall SFC architecture, and + this section describes its high-level functions. However, the + detailed definition of the SFC control plane is outside the scope of + this document. + + The SFC control plane is responsible for constructing SFPs, + translating SFCs to forwarding paths, and propagating path + information to participating nodes to achieve requisite forwarding + behavior to construct the service overlay. For instance, an SFC + + + +Halpern & Pignataro Informational [Page 21] + +RFC 7665 SFC Architecture October 2015 + + + construction may be static; selecting exactly which SFFs and which + SFs from those SFFs are to be used, or it may be dynamic, allowing + the network to perform some or all of the choices of SFF or SF to use + to deliver the selected service chain within the constraints + represented by the service path. + + In the SFC architecture, SFs are resources; the control plane manages + and communicates their capabilities, availability, and location in + fashions suitable for the transport and SFC operations in use. The + control plane is also responsible for the creation of the context + (see below). The control plane may be distributed (using new or + existing control-plane protocols), or be centralized, or a + combination of the two. + + The SFC control plane provides the following functionality: + + 1. An SFC-enabled domain wide view of all available service function + resources as well as the network locators through which they are + reachable. + + 2. Uses SFC policy to construct service function chains, and + associated SFPs. + + 3. Selection of specific SFs for a requested SFC, either statically + (using specific SFs) or dynamically (using service explicit SFs + at the time of delivering traffic to them). + + 4. Provides requisite SFC data-plane information to the SFC + architecture components, most notably the SFF. + + 5. Provides the metadata and usage information classifiers need so + that they in turn can provide this metadata for appropriate + packets in the data plane. + + 6. When needed, provide information including policy information to + other SFC elements to be able to properly interpret metadata. + +5.3. Resource Control + + The SFC system may be responsible for managing all resources + necessary for the SFC components to function. This includes network + constraints used to plan and choose network path(s) between service + function forwarders, network communication paths between service + function forwarders and their attached service functions, + characteristics of the nodes themselves such as memory, number of + virtual interfaces, routes, and instantiation, configuration, and + deletion of SFs. + + + + +Halpern & Pignataro Informational [Page 22] + +RFC 7665 SFC Architecture October 2015 + + + The SFC system will also be required to reflect policy decisions + about resource control, as expressed by other components in the + system. + + While all of these aspects are part of the overall system, they are + beyond the scope of this architecture. + +5.4. Infinite Loop Detection and Avoidance + + This SFC architecture is predicated on topological independence from + the underlying forwarding topology. Consequently, a service topology + is created by service function paths or by the local decisions of the + service function forwarders based on the constraints expressed in the + SFP. Due to the overlay constraints, the packet-forwarding path may + need to visit the same SFF multiple times, and in some less common + cases may even need to visit the same SF more than once. The Service + Chaining solution needs to permit these limited and policy-compliant + loops. At the same time, the solutions must ensure that indefinite + and unbounded loops cannot be formed, as such would consume unbounded + resources without delivering any value. + + In other words, this architecture requires the solution to prevent + infinite service function loops, even when service functions may be + invoked multiple times in the same SFP. + +5.5. Load-Balancing Considerations + + Supporting function elasticity and high-availability should not + overly complicate SFC or lead to unnecessary scalability problems. + + In the simplest case, where there is only a single function in the + SFP (the next hop is either the destination address of the flow or + the appropriate next hop to that destination), one could argue that + there may be no need for SFC. + + In the cases where the classifier is separate from the single + function or a function at the terminal address may need a sub-prefix + (e.g., finer-grained address information) or per-subscriber metadata, + a single SFP exists (i.e., the metadata changes but the SFP does + not), regardless of the number of potential terminal addresses for + the flow. This is the case of the simple load balancer. See + Figure 4. + + +---+ +---++--->web server + source+-->|sff|+-->|sf1|+--->web server + +---+ +---++--->web server + + Figure 4: Simple Load Balancing + + + +Halpern & Pignataro Informational [Page 23] + +RFC 7665 SFC Architecture October 2015 + + + By extrapolation, in the case where intermediary functions within a + chain had similar "elastic" behaviors, we do not need separate chains + to account for this behavior -- as long as the traffic coalesces to a + common next-hop after the point of elasticity. + + In Figure 5, we have a chain of five service functions between the + traffic source and its destination. + + +---+ +---+ +---+ +---+ +---+ +---+ + |sf2| |sf2| |sf3| |sf3| |sf4| |sf4| + +---+ +---+ +---+ +---+ +---+ +---+ + | | | | | | + +-----+-----+ +-----+-----+ + | | + + + + +---+ +---+ +---+ +---+ +---+ + source+-->|sff|+-->|sff|+--->|sff|+--->|sff|+-->|sff|+-->destination + +---+ +---+ +---+ +---+ +---+ + + + + + | | | + +---+ +---+ +---+ + |sf1| |sf3| |sf5| + +---+ +---+ +---+ + + Figure 5: Load Balancing + + This would be represented as one service function path: + sf1 -> sf2 -> sf3 -> sf4 -> sf5. The SFF is a logical element, which + may be made up of one or multiple components. In this architecture, + the SFF may handle load distribution based on policy. + + It can also be seen in the above that the same service function may + be reachable through multiple SFFs, as discussed earlier. The + selection of which SFF to use to reach sf3 may be made by the control + logic in defining the SFP, or may be left to the SFFs themselves, + depending upon policy, solution, and deployment constraints. In the + latter case, it needs to be assured that exactly one SFF takes + responsibility to steer traffic through sf3. + +5.6. MTU and Fragmentation Considerations + + This architecture prescribes that additional information be added to + packets to identify service function paths and often to represent + metadata. It also envisions adding transport information to carry + packets along service function paths, at least between service + function forwarders. This added information increases the size of + the packet to be carried by service chaining. Such additions could + + + + +Halpern & Pignataro Informational [Page 24] + +RFC 7665 SFC Architecture October 2015 + + + potentially increase the packet size beyond the MTU supported on some + or all of the media used in the service chaining domain. + + Such packet size increases can thus cause operational MTU problems. + Requiring fragmentation and reassembly in an SFF would be a major + processing increase and might be impossible with some transports. + Expecting service functions to deal with packets fragmented by the + SFC function might be onerous even when such fragmentation was + possible. Thus, at the very least, solutions need to pay attention + to the size cost of their approach. There may be alternative or + additional means available, although any solution needs to consider + the trade-offs. + + These considerations apply to any generic architecture that increases + the header size. There are also more specific MTU considerations: + Effects on Path MTU Discovery (PMTUD) as well as deployment + considerations. Deployments within a single administrative control + or even a single data center complex can afford more flexibility in + dealing with larger packets, and deploying existing mitigations that + decrease the likelihood of fragmentation or discard. + +5.7. SFC OAM + + Operations, Administration, and Maintenance (OAM) tools are an + integral part of the architecture. These serve various purposes, + including fault detection and isolation, and performance management. + For example, there are many advantages of SFP liveness detection, + including status reporting, support for resiliency operations and + policies, and an enhanced ability to balance load. + + Service function paths create a services topology, and OAM performs + various functions within this service layer. Furthermore, SFC OAM + follows the same architectural principles of SFC in general. For + example, topological independence (including the ability to run OAM + over various overlay technologies) and classification-based policy. + + We can subdivide the SFC OAM architecture in two parts: + + o In-band: OAM packets follow the same path and share fate with user + packets, within the service topology. For this, they also follow + the architectural principle of consistent policy identifiers, and + use the same path IDs as the service chain data packets. Load + balancing and SFC encapsulation with packet forwarding are + particularly important here. + + o Out-of-band: Reporting beyond the actual data plane. An + additional layer beyond the data-plane OAM allows for additional + alerting and measurements. + + + +Halpern & Pignataro Informational [Page 25] + +RFC 7665 SFC Architecture October 2015 + + + This architecture prescribes end-to-end SFP OAM functions, which + implies SFF understanding of whether an in-band packet is an OAM or + user packet. However, service function validation is outside of the + scope of this architecture, and application-level OAM is not what + this architecture prescribes. + + Some of the detailed functions performed by SFC OAM include fault + detection and isolation in a service function path or a service + function, verification that connectivity using SFPs is both effective + and directing packets to the intended service functions, service path + tracing, diagnostic and fault isolation, alarm reporting, performance + measurement, locking and testing of service functions, validation + with the control plane (see Section 5.2), and also allow for vendor- + specific as well as experimental functions. SFC should leverage and, + if needed, extend relevant existing OAM mechanisms. + +5.8. Resilience and Redundancy + + As a practical operational requirement, any service chaining solution + needs to be able to respond effectively, and usually very quickly, to + failure conditions. These may be failures of connectivity in the + network between SFFs, failures of SFFs, or failures of SFs. Per-SF + state (as, for example, stateful-firewall state) is the + responsibility of the SF, and not addressed by this architecture. + + Multiple techniques are available to address this issue. Solutions + can describe both what they require and what they allow to address + failure. Solutions can make use of flexible specificity of service + function paths, if the SFF can be given enough information in a + timely fashion to do this. Solutions can also make use of MAC- or + IP-level redundancy mechanisms such as Virtual Router Redundancy + Protocol (VRRP). Also, particularly for SF failures, load balancers + co-located with the SFF or as part of the service function delivery + mechanism can provide such robustness. + + Similarly, operational requirements imply resilience in the face of + load changes. While mechanisms for managing (e.g., monitoring, + instantiating, loading images, providing configuration to SFC + control, deleting, etc.) virtual machines are out of scope for this + architecture, solutions can and are aided by describing how they can + make use of scaling mechanisms. + + + + + + + + + + +Halpern & Pignataro Informational [Page 26] + +RFC 7665 SFC Architecture October 2015 + + +6. Security Considerations + + The architecture described here is different from the current model, + and moving to the new model could lead to different security + arrangements and modeling. In the SFC architecture, a relatively + static topologically-dependent deployment model is replaced with the + chaining of sets of service functions. This can change the flow of + data through the network, and the security and privacy considerations + of the protocol and deployment will need to be reevaluated in light + of the new model. + + Security considerations apply to the realization of this + architecture, in particular to the documents that will define + protocols. Such realization ought to provide means to protect + against security and privacy attacks in the areas hereby described. + + Building from the categorization of [RFC7498], we can largely divide + the security considerations into four areas: + + Service Overlay: Underneath the service function forwarders, the + components that are responsible for performing the transport + forwarding consult the outer-transport encapsulation for + underlay forwarding. Used transport mechanisms should satisfy + the security requirements of the specific SFC deployment. These + requirements typically include varying degrees of traffic + separation, protection against different attacks (e.g., + spoofing, man-in-the-middle, brute-force, or insertion attacks), + and can also include authenticity and integrity checking, and/or + confidentiality provisions, for both the network overlay + transport and traffic it encapsulates. + + Boundaries: Specific requirements may need to be enforced at the + boundaries of an SFC-enabled domain. These include, for + example, to avoid leaking SFC information, and to protect its + borders against various forms of attacks. If untrusted parties + can inject packets that will be treated as being properly + classified for service chaining, there are a large range of + attacks that can be mounted against the resulting system. + Depending upon deployment details, these likely include spoofing + packets from users and creating DDoS and reflection attacks of + various kinds. Thus, when transport mechanisms are selected for + use with SFC, they MUST ensure that outside parties cannot + inject SFC packets that will be accepted for processing into the + domain. This border security MUST include any tunnels to other + domains. If those tunnels are to be used for SFC without + reclassification, then the tunnel MUST include additional + techniques to ensure the integrity and validity of such packets. + + + + +Halpern & Pignataro Informational [Page 27] + +RFC 7665 SFC Architecture October 2015 + + + Classification: Classification is used at the ingress edge of an + SFC-enabled domain. Policy for this classification is done + using a plurality of methods. Whatever method is used needs to + consider a range of security issues. These include appropriate + authentication and authorization of classification policy, + potential confidentiality issues of that policy, protection + against corruption, and proper application of policy with needed + segregation of application. This includes proper controls on + the policies that drive the application of the SFC encapsulation + and associated metadata to packets. Similar issues need to be + addressed if classification is performed within a service + chaining domain, i.e., reclassification. + + SFC Encapsulation: The SFC encapsulation provides at a minimum SFP + identification, and carries metadata. An operator may consider + the SFC Metadata as sensitive. From a privacy perspective, a + user may be concerned about the operator revealing data about + (and not belonging to) the customer. Therefore, solutions + should consider whether there is a risk of sensitive information + slipping out of the operator's control. Issues of information + exposure should also consider flow analysis. Further, when a + specific metadata element is defined, it should be carefully + considered whether origin authentication is needed for it. + + A classifier may have privileged access to information about a + packet or inside a packet (see Section 3, item 4, and + Section 4.9) that is then communicated in the metadata. The + threat of leaking this private data needs to be mitigated + [RFC6973]. As one example, if private data is represented by an + identifier, then a new identifier can be allocated, such that + the mapping from the private data to the new identifier is not + broadly shared. + + Some metadata added to and carried in SFC packets is sensitive + for various reasons, including potentially revealing personally + identifying information. Realizations of the architecture MUST + protect such information to ensure that it is handled with + suitable care and precautions against inappropriate + dissemination. This can have implications to the data plane, + the control plane, or both. Data-plane protocol definitions for + SFC can include suitable provisions to protect such information + for use when handling sensitive information, with packet or SFP + granularity. Equally, the control mechanisms used with SFC can + have provisions to determine that such mechanisms are available, + and to ensure that they are used when needed. Inability to do + so needs to result in error indications to appropriate + management systems. In particular, when the control systems + know that sensitive information may potentially be added to + + + +Halpern & Pignataro Informational [Page 28] + +RFC 7665 SFC Architecture October 2015 + + + packets at certain points on certain service chains, the control + mechanism MUST verify that appropriate protective treatment of + NSH information is available from the point where the + information is added to the point where it will be removed. If + such mechanisms are unavailable, error notifications SHOULD be + generated. + + Additionally, SFC OAM functions need to not negatively affect the + security considerations of an SFC-enabled domain. + + Finally, all entities (software or hardware) interacting with the + service chaining mechanisms need to provide means of security against + malformed, poorly configured (deliberate or not) protocol constructs + and loops. These considerations are largely the same as those in any + network, particularly an overlay network. + +7. References + +7.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + . + +7.2. Informative References + + [Boucadair2014] + Boucadair, M., Jacquenet, C., Parker, R., Lopez, D., + Guichard, J., and C. Pignataro, "Service Function + Chaining: Framework & Architecture", Work in Progress, + draft-boucadair-sfc-framework-02, February 2014. + + [Quinn2014] + Quinn, P. and J. Halpern, "Service Function Chaining (SFC) + Architecture", Work in Progress, draft-quinn-sfc-arch-05, + May 2014. + + [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network + Address Translator (Traditional NAT)", RFC 3022, + DOI 10.17487/RFC3022, January 2001, + . + + [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful + NAT64: Network Address and Protocol Translation from IPv6 + Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, + April 2011, . + + + + +Halpern & Pignataro Informational [Page 29] + +RFC 7665 SFC Architecture October 2015 + + + [RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix + Translation", RFC 6296, DOI 10.17487/RFC6296, June 2011, + . + + [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., + Morris, J., Hansen, M., and R. Smith, "Privacy + Considerations for Internet Protocols", RFC 6973, + DOI 10.17487/RFC6973, July 2013, + . + + [RFC7498] Quinn, P., Ed. and T. Nadeau, Ed., "Problem Statement for + Service Function Chaining", RFC 7498, + DOI 10.17487/RFC7498, April 2015, + . + +Acknowledgments + + The editors would like to thank Sam Aldrin, Alia Atlas, Nicolas + Bouthors, Stewart Bryant, Linda Dunbar, Alla Goldner, Ken Gray, Barry + Greene, Anil Gunturu, David Harrington, Shunsuke Homma, Dave Hood, + Chris Inacio, Nagendra Kumar, Hongyu Li, Andrew Malis, Guy + Meador III, Kengo Naito, Thomas Narten, Ron Parker, Reinaldo Penno, + Naiming Shen, Xiaohu Xu, and Lucy Yong for a thorough review and + useful comments. + + The initial draft of this document was the result of merging two + previous documents, and this section lists the acknowledgments from + those documents. + + From "Service Function Chaining (SFC) Architecture" [Quinn2014] + + The authors would like to thank David Ward, Abhijit Patra, Nagaraj + Bagepalli, Darrel Lewis, Ron Parker, Lucy Yong, and Christian + Jacquenet for their review and comments. + + From "Service Function Chaining (SF) - Framework and Architecture" + [Boucadair2014]: + + Many thanks to D. Abgrall, D. Minodier, Y. Le Goff, D. Cheng, + R. White, and B. Chatras for their review and comments. + + + + + + + + + + + +Halpern & Pignataro Informational [Page 30] + +RFC 7665 SFC Architecture October 2015 + + +Contributors + + As noted above, this document is the result of merging two previous + documents. This section lists those who provided important ideas and + text that fed into this architecture. + + The authors of "Service Function Chaining (SFC) - Framework and + Architecture" [Boucadair2014] were: + + Mohamed Boucadair + Christian Jacquenet + Ron Parker + Diego R. Lopez + Jim Guichard + Carlos Pignataro + + The contributors were: + + Parviz Yegani + Paul Quinn + Linda Dunbar + + The authors of "Service Function Chaining (SFC) Architecture" + [Quinn2014] were: + + Paul Quinn (editor) + Joel Halpern (editor) + + The contributors were: + + Puneet Agarwal + Andre Beliveau + Kevin Glavin + Ken Gray + Jim Guichard + Surendra Kumar + Darrel Lewis + Nic Leymann + Rajeev Manur + Thomas Nadeau + Carlos Pignataro + Michael Smith + Navindra Yadav + + + + + + + + +Halpern & Pignataro Informational [Page 31] + +RFC 7665 SFC Architecture October 2015 + + +Authors' Addresses + + Joel Halpern (editor) + Ericsson + + Email: jmh@joelhalpern.com + + + Carlos Pignataro (editor) + Cisco Systems, Inc. + + Email: cpignata@cisco.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Halpern & Pignataro Informational [Page 32] + -- cgit v1.2.3