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
AbstractThis 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.
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.
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
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.
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. 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. RFC2119].
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.
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. 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
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).
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.
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.
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.
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. 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:
+----------------+ +----------------+ | 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.
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. 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.
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.
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). Figure 3) are inside the SFC-enabled domain.
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
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.
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.
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.
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. Figure 4. +---+ +---++--->web server source+-->|sff|+-->|sf1|+--->web server +---+ +---++--->web server Figure 4: Simple Load Balancing
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.
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.
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.
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.
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
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. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>. [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, <http://www.rfc-editor.org/info/rfc3022>. [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, <http://www.rfc-editor.org/info/rfc6146>.
[RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix Translation", RFC 6296, DOI 10.17487/RFC6296, June 2011, <http://www.rfc-editor.org/info/rfc6296>. [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, <http://www.rfc-editor.org/info/rfc6973>. [RFC7498] Quinn, P., Ed. and T. Nadeau, Ed., "Problem Statement for Service Function Chaining", RFC 7498, DOI 10.17487/RFC7498, April 2015, <http://www.rfc-editor.org/info/rfc7498>. 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.
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