diff options
Diffstat (limited to 'doc/rfc/rfc8300.txt')
| -rw-r--r-- | doc/rfc/rfc8300.txt | 2243 |
1 files changed, 2243 insertions, 0 deletions
diff --git a/doc/rfc/rfc8300.txt b/doc/rfc/rfc8300.txt new file mode 100644 index 0000000..481b72b --- /dev/null +++ b/doc/rfc/rfc8300.txt @@ -0,0 +1,2243 @@ + + + + + + +Internet Engineering Task Force (IETF) P. Quinn, Ed. +Request for Comments: 8300 Cisco +Category: Standards Track U. Elzur, Ed. +ISSN: 2070-1721 Intel + C. Pignataro, Ed. + Cisco + January 2018 + + + Network Service Header (NSH) + +Abstract + + This document describes a Network Service Header (NSH) imposed on + packets or frames to realize Service Function Paths (SFPs). The NSH + also provides a mechanism for metadata exchange along the + instantiated service paths. The NSH is the Service Function Chaining + (SFC) encapsulation required to support the SFC architecture (defined + in RFC 7665). + +Status of This Memo + + This is an Internet Standards Track document. + + 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). Further information on + Internet Standards is available in Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + https://www.rfc-editor.org/info/rfc8300. + +Copyright Notice + + Copyright (c) 2018 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 + (https://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. + + + +Quinn, et al. Standards Track [Page 1] + +RFC 8300 Network Service Header (NSH) January 2018 + + +Table of Contents + + 1. Introduction ....................................................3 + 1.1. Applicability ..............................................4 + 1.2. Requirements Language ......................................4 + 1.3. Definition of Terms ........................................4 + 1.4. Problem Space ..............................................6 + 1.5. NSH-Based Service Chaining .................................6 + 2. Network Service Header ..........................................7 + 2.1. Network Service Header Format ..............................7 + 2.2. NSH Base Header ............................................8 + 2.3. Service Path Header .......................................11 + 2.4. NSH MD Type 1 .............................................12 + 2.5. NSH MD Type 2 .............................................13 + 2.5.1. Optional Variable-Length Metadata ..................13 + 3. NSH Actions ....................................................15 + 4. NSH Transport Encapsulation ....................................16 + 5. Fragmentation Considerations ...................................17 + 6. Service Path Forwarding with NSH ...............................18 + 6.1. SFFs and Overlay Selection ................................18 + 6.2. Mapping the NSH to Network Topology .......................21 + 6.3. Service Plane Visibility ..................................21 + 6.4. Service Graphs ............................................22 + 7. Policy Enforcement with NSH ....................................22 + 7.1. NSH Metadata and Policy Enforcement .......................22 + 7.2. Updating/Augmenting Metadata ..............................24 + 7.3. Service Path Identifier and Metadata ......................25 + 8. Security Considerations ........................................26 + 8.1. NSH Security Considerations from Operators' Environments ..27 + 8.2. NSH Security Considerations from the SFC Architecture .....28 + 8.2.1. Integrity ..........................................29 + 8.2.2. Confidentiality ....................................31 + 9. IANA Considerations ............................................32 + 9.1. NSH Parameters ............................................32 + 9.1.1. NSH Base Header Bits ...............................32 + 9.1.2. NSH Version ........................................32 + 9.1.3. NSH MD Types .......................................33 + 9.1.4. NSH MD Class .......................................33 + 9.1.5. NSH IETF-Assigned Optional Variable-Length + Metadata Types .....................................34 + 9.1.6. NSH Next Protocol ..................................35 + 10. NSH-Related Codepoints ........................................35 + 10.1. NSH Ethertype ............................................35 + 11. References ....................................................36 + Acknowledgments ...................................................38 + Contributors ......................................................39 + Authors' Addresses ................................................40 + + + + +Quinn, et al. Standards Track [Page 2] + +RFC 8300 Network Service Header (NSH) January 2018 + + +1. Introduction + + Service Functions are widely deployed and essential in many networks. + These Service Functions provide a range of features such as security, + WAN acceleration, and server load balancing. Service Functions may + be instantiated at different points in the network infrastructure + such as the WAN, data center, and so forth. + + Prior to development of the SFC architecture [RFC7665] and the + protocol specified in this document, current Service Function + deployment models have been relatively static and bound to topology + for insertion and policy selection. Furthermore, they do not adapt + well to elastic service environments enabled by virtualization. + + New data-center network and cloud architectures require more flexible + Service Function deployment models. Additionally, the transition to + virtual platforms demands an agile service insertion model that + supports dynamic and elastic service delivery. Specifically, the + following functions are necessary: + + 1. The movement of Service Functions and application workloads in + the network. + + 2. The ability to easily bind service policy to granular + information, such as per-subscriber state. + + 3. The capability to steer traffic to the requisite Service + Function(s). + + This document, the Network Service Header (NSH) specification, + defines a new data-plane protocol, which is an encapsulation for + SFCs. The NSH is designed to encapsulate an original packet or frame + and, in turn, be encapsulated by an outer transport encapsulation + (which is used to deliver the NSH to NSH-aware network elements), as + shown in Figure 1: + + +------------------------------+ + | Transport Encapsulation | + +------------------------------+ + | Network Service Header (NSH) | + +------------------------------+ + | Original Packet / Frame | + +------------------------------+ + + Figure 1: Network Service Header Encapsulation + + + + + + +Quinn, et al. Standards Track [Page 3] + +RFC 8300 Network Service Header (NSH) January 2018 + + + The NSH is composed of the following elements: + + 1. Service Function Path identification. + + 2. Indication of location within a Service Function Path. + + 3. Optional, per-packet metadata (fixed-length or variable). + + [RFC7665] provides an overview of a service chaining architecture + that clearly defines the roles of the various elements and the scope + of a SFC encapsulation. Figure 3 of [RFC7665] depicts the SFC + architectural components after classification. The NSH is the SFC + encapsulation referenced in [RFC7665]. + +1.1. Applicability + + The NSH is designed to be easy to implement across a range of + devices, both physical and virtual, including hardware platforms. + + The intended scope of the NSH is for use within a single provider's + operational domain. This deployment scope is deliberately + constrained, as explained also in [RFC7665], and limited to a single + network administrative domain. In this context, a "domain" is a set + of network entities within a single administration. For example, a + network administrative domain can include a single data center, or an + overlay domain using virtual connections and tunnels. A corollary is + that a network administrative domain has a well-defined perimeter. + + An NSH-aware control plane is outside the scope of this document. + +1.2. Requirements Language + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in + BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all + capitals, as shown here. + +1.3. Definition of Terms + + Byte: All references to "bytes" in this document refer to 8-bit + bytes, or octets. + + Classification: Defined in [RFC7665]. + + Classifier: Defined in [RFC7665]. + + + + + +Quinn, et al. Standards Track [Page 4] + +RFC 8300 Network Service Header (NSH) January 2018 + + + Metadata (MD): Defined in [RFC7665]. The metadata, or context + information shared between Classifiers and SFs, and among SFs, is + carried on the NSH's Context Headers. It allows summarizing a + classification result in the packet itself, avoiding subsequent + re-classifications. Examples of metadata include classification + information used for policy enforcement and network context for + forwarding after service delivery. + + Network Locator: Data-plane address, typically IPv4 or IPv6, used to + send and receive network traffic. + + Network Node/Element: Device that forwards packets or frames based + on an outer header (i.e., transport encapsulation) information. + + Network Overlay: Logical network built on top of an existing network + (the underlay). Packets are encapsulated or tunneled to create + the overlay network topology. + + NSH-aware: NSH-aware means SFC-encapsulation-aware, where the NSH + provides the SFC encapsulation. This specification uses NSH-aware + as a more specific term from the more generic term "SFC-aware" + [RFC7665]. + + Service Classifier: Logical entity providing classification + function. Since they are logical, Classifiers may be co-resident + with SFC elements such as SFs or SFFs. Service Classifiers + perform classification and impose the NSH. The initial Classifier + imposes the initial NSH and sends the NSH packet to the first SFF + in the path. Non-initial (i.e., subsequent) classification can + occur as needed and can alter, or create a new service path. + + Service Function (SF): Defined in [RFC7665]. + + Service Function Chain (SFC): Defined in [RFC7665]. + + Service Function Forwarder (SFF): Defined in [RFC7665]. + + Service Function Path (SFP): Defined in [RFC7665]. + + Service Plane: The collection of SFFs and associated SFs creates a + service-plane overlay in which all SFs and SFC Proxies reside + [RFC7665]. + + SFC Proxy: Defined in [RFC7665]. + + + + + + + +Quinn, et al. Standards Track [Page 5] + +RFC 8300 Network Service Header (NSH) January 2018 + + +1.4. Problem Space + + The NSH addresses several limitations associated with Service + Function deployments. [RFC7498] provides a comprehensive review of + those issues. + +1.5. NSH-Based Service Chaining + + The NSH creates a dedicated service plane; more specifically, the NSH + enables: + + 1. Topological Independence: Service forwarding occurs within the + service plane, so the underlying network topology does not + require modification. The NSH provides an identifier used to + select the network overlay for network forwarding. + + 2. Service Chaining: The NSH enables service chaining per [RFC7665]. + The NSH contains path identification information needed to + realize a service path. Furthermore, the NSH provides the + ability to monitor and troubleshoot a service chain, end-to-end + via service-specific Operations, Administration, and Maintenance + (OAM) messages. The NSH fields can be used by administrators + (for example, via a traffic analyzer) to verify the path + specifics (e.g., accounting, ensuring correct chaining, providing + reports, etc.) of packets being forwarded along a service path. + + 3. The NSH provides a mechanism to carry shared metadata between + participating entities and Service Functions. The semantics of + the shared metadata are communicated via a control plane (which + is outside the scope of this document) to participating nodes. + Section 3.3 of [SFC-CONTROL-PLANE] provides an example of this. + Examples of metadata include classification information used for + policy enforcement and network context for forwarding post + service delivery. Sharing the metadata allows Service Functions + to share initial and intermediate classification results with + downstream Service Functions saving re-classification, where + enough information was enclosed. + + 4. The NSH offers a common and standards-based header for service + chaining to all network and service nodes. + + 5. Transport Encapsulation Agnostic: The NSH is transport + encapsulation independent: meaning it can be transported by a + variety of encapsulation protocols. An appropriate (for a given + deployment) encapsulation protocol can be used to carry NSH- + encapsulated traffic. This transport encapsulation may form an + + + + + +Quinn, et al. Standards Track [Page 6] + +RFC 8300 Network Service Header (NSH) January 2018 + + + overlay network; and if an existing overlay topology provides the + required service path connectivity, that existing overlay may be + used. + +2. Network Service Header + + An NSH is imposed on the original packet/frame. This NSH contains + service path information and, optionally, metadata that are added to + a packet or frame and used to create a service plane. Subsequently, + an outer transport encapsulation is imposed on the NSH, which is used + for network forwarding. + + A Service Classifier adds the NSH. The NSH is removed by the last + SFF in the service chain or by an SF that consumes the packet. + +2.1. Network Service Header Format + + The NSH is composed of a 4-byte Base Header, a 4-byte Service Path + Header, and optional Context Headers, as shown in Figure 2. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Base Header | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Service Path Header | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + ~ Context Header(s) ~ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 2: Network Service Header + + Base Header: Provides information about the service header and the + payload protocol. + + Service Path Header: Provides path identification and location + within a service path. + + Context Header: Carries metadata (i.e., context data) along a + service path. + + + + + + + + + +Quinn, et al. Standards Track [Page 7] + +RFC 8300 Network Service Header (NSH) January 2018 + + +2.2. NSH Base Header + + Figure 3 depicts the NSH Base Header: + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |Ver|O|U| TTL | Length |U|U|U|U|MD Type| Next Protocol | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 3: NSH Base Header + + The field descriptions are as follows: + + Version: The Version field is used to ensure backward compatibility + going forward with future NSH specification updates. It MUST be + set to 0x0 by the sender, in this first revision of the NSH. If a + packet presumed to carry an NSH header is received at an SFF, and + the SFF does not understand the version of the protocol as + indicated in the base header, the packet MUST be discarded, and + the event SHOULD be logged. Given the widespread implementation + of existing hardware that uses the first nibble after an MPLS + label stack for Equal-Cost Multipath (ECMP) decision processing, + this document reserves version 01b. This value MUST NOT be used + in future versions of the protocol. Please see [RFC7325] for + further discussion of MPLS-related forwarding requirements. + + O bit: Setting this bit indicates an OAM packet (see [RFC6291]). + The actual format and processing of SFC OAM packets is outside the + scope of this specification (for example, see [SFC-OAM-FRAMEWORK] + for one approach). + + The O bit MUST be set for OAM packets and MUST NOT be set for + non-OAM packets. The O bit MUST NOT be modified along the SFP. + + SF/SFF/SFC Proxy/Classifier implementations that do not support + SFC OAM procedures SHOULD discard packets with O bit set, but MAY + support a configurable parameter to enable forwarding received SFC + OAM packets unmodified to the next element in the chain. + Forwarding OAM packets unmodified by SFC elements that do not + support SFC OAM procedures may be acceptable for a subset of OAM + functions, but it can result in unexpected outcomes for others; + thus, it is recommended to analyze the impact of forwarding an OAM + packet for all OAM functions prior to enabling this behavior. The + configurable parameter MUST be disabled by default. + + + + + + +Quinn, et al. Standards Track [Page 8] + +RFC 8300 Network Service Header (NSH) January 2018 + + + TTL: Indicates the maximum SFF hops for an SFP. This field is used + for service-plane loop detection. The initial TTL value SHOULD be + configurable via the control plane; the configured initial value + can be specific to one or more SFPs. If no initial value is + explicitly provided, the default initial TTL value of 63 MUST be + used. Each SFF involved in forwarding an NSH packet MUST + decrement the TTL value by 1 prior to NSH forwarding lookup. + Decrementing by 1 from an incoming value of 0 shall result in a + TTL value of 63. The packet MUST NOT be forwarded if TTL is, + after decrement, 0. + + This TTL field is the primary loop-prevention mechanism. This TTL + mechanism represents a robust complement to the Service Index (see + Section 2.3), as the TTL is decremented by each SFF. The handling + of an incoming 0 TTL allows for better, although not perfect, + interoperation with pre-standard implementations that do not + support this TTL field. + + Length: The total length, in 4-byte words, of the NSH including the + Base Header, the Service Path Header, the Fixed-Length Context + Header, or Variable-Length Context Header(s). The length MUST be + 0x6 for MD Type 0x1, and it MUST be 0x2 or greater for MD Type + 0x2. The length of the Network Service Header MUST be an integer + multiple of 4 bytes; thus, variable-length metadata is always + padded out to a multiple of 4 bytes. + + Unassigned bits: All other flag fields, marked U, are unassigned and + available for future use; see Section 9.1.1. Unassigned bits MUST + be set to zero upon origination, and they MUST be ignored and + preserved unmodified by other NSH supporting elements. At + reception, all elements MUST NOT modify their actions based on + these unknown bits. + + Metadata (MD) Type: Indicates the format of the NSH beyond the + mandatory NSH Base Header and the Service Path Header. MD Type + defines the format of the metadata being carried. Please see the + IANA Considerations in Section 9.1.3. + + This document specifies the following four MD Type values: + + 0x0: This is a reserved value. Implementations SHOULD silently + discard packets with MD Type 0x0. + + 0x1: This indicates that the format of the header includes a + Fixed-Length Context Header (see Figure 5 below). + + + + + + +Quinn, et al. Standards Track [Page 9] + +RFC 8300 Network Service Header (NSH) January 2018 + + + 0x2: This does not mandate any headers beyond the Base Header and + Service Path Header, but may contain optional Variable- + Length Context Header(s). With MD Type 0x2, a length of 0x2 + implies there are no Context Headers. The semantics of the + Variable-Length Context Header(s) are not defined in this + document. The format of the optional Variable-Length + Context Headers is provided in Section 2.5.1. + + 0xF: This value is reserved for experimentation and testing, as + per [RFC3692]. Implementations not explicitly configured to + be part of an experiment SHOULD silently discard packets + with MD Type 0xF. + + The format of the Base Header and the Service Path Header is + invariant and not affected by MD Type. + + The NSH MD Type 1 and MD Type 2 are described in detail in + Sections 2.4 and 2.5, respectively. NSH implementations MUST + support MD Types 0x1 and 0x2 (where the length is 0x2). NSH + implementations SHOULD support MD Type 0x2 with length greater + than 0x2. Devices that do not support MD Type 0x2 with a length + greater than 0x2 MUST ignore any optional Context Headers and + process the packet without them; the Base Header Length field can + be used to determine the original payload offset if access to the + original packet/frame is required. This specification does not + disallow the MD Type value from changing along an SFP; however, + the specification of the necessary mechanism to allow the MD Type + to change along an SFP are outside the scope of this document and + would need to be defined for that functionality to be available. + Packets with MD Type values not supported by an implementation + MUST be silently dropped. + + Next Protocol: Indicates the protocol type of the encapsulated data. + The NSH does not alter the inner payload, and the semantics on the + inner protocol remain unchanged due to NSH SFC. Please see the + IANA Considerations in Section 9.1.6. + + This document defines the following Next Protocol values: + + 0x1: IPv4 + 0x2: IPv6 + 0x3: Ethernet + 0x4: NSH + 0x5: MPLS + 0xFE: Experiment 1 + 0xFF: Experiment 2 + + + + + +Quinn, et al. Standards Track [Page 10] + +RFC 8300 Network Service Header (NSH) January 2018 + + + The functionality of hierarchical NSH using a Next Protocol value + of 0x4 (NSH) is outside the scope of this specification. Packets + with Next Protocol values not supported SHOULD be silently dropped + by default, although an implementation MAY provide a configuration + parameter to forward them. Additionally, an implementation not + explicitly configured for a specific experiment [RFC3692] SHOULD + silently drop packets with Next Protocol values 0xFE and 0xFF. + +2.3. Service Path Header + + Figure 4 shows the format of the Service Path Header: + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Service Path Identifier (SPI) | Service Index | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Service Path Identifier (SPI): 24 bits + Service Index (SI): 8 bits + + Figure 4: NSH Service Path Header + + The meaning of these fields is as follows: + + Service Path Identifier (SPI): Uniquely identifies a Service Function + Path (SFP). Participating nodes MUST use this identifier for SFP + selection. The initial Classifier MUST set the appropriate SPI for a + given classification result. + + Service Index (SI): Provides location within the SFP. The initial + Classifier for a given SFP SHOULD set the SI to 255; however, the + control plane MAY configure the initial value of the SI as + appropriate (i.e., taking into account the length of the SFP). The + Service Index MUST be decremented by a value of 1 by Service + Functions or by SFC Proxy nodes after performing required services; + the new decremented SI value MUST be used in the egress packet's NSH. + The initial Classifier MUST send the packet to the first SFF in the + identified SFP for forwarding along an SFP. If re-classification + occurs, and that re-classification results in a new SPI, the + (re-)Classifier is, in effect, the initial Classifier for the + resultant SPI. + + The SI is used in conjunction with the Service Path Identifier for + SFP selection and for determining the next SFF/SF in the path. The + SI is also valuable when troubleshooting or reporting service paths. + While the TTL provides the primary SFF-based loop prevention for this + mechanism, SI decrement by SF serves as a limited loop-prevention + + + +Quinn, et al. Standards Track [Page 11] + +RFC 8300 Network Service Header (NSH) January 2018 + + + mechanism. NSH packets, as described above, are discarded when an + SFF decrements the TTL to 0. In addition, an SFF that is not the + terminal SFF for an SFP will discard any NSH packet with an SI of 0, + as there will be no valid next SF information. + +2.4. NSH MD Type 1 + + When the Base Header specifies MD Type 0x1, a Fixed-Length Context + Header (16-bytes) MUST be present immediately following the Service + Path Header, as per Figure 5. The value of a Fixed-Length Context + Header that carries no metadata MUST be set to zero. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |Ver|O|U| TTL | Length |U|U|U|U|MD Type| Next Protocol | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Service Path Identifier | Service Index | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + | Fixed-Length Context Header | + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 5: NSH MD Type 0x1 + + This specification does not make any assumptions about the content of + the 16-byte Context Header that must be present when the MD Type + field is set to 1, and it does not describe the structure or meaning + of the included metadata. + + An SFC-aware SF or SFC Proxy needs to receive the data structure and + semantics first in order to process the data placed in the mandatory + context field. The data structure and semantics include both the + allocation schema and order as well as the meaning of the included + data. How an SFC-aware SF or SFC Proxy gets the data structure and + semantics is outside the scope of this specification. + + An SF or SFC Proxy that does not know the format or semantics of the + Context Header for an NSH with MD Type 1 MUST discard any packet with + such an NSH (i.e., MUST NOT ignore the metadata that it cannot + process), and MUST log the event at least once per the SPI for which + the event occurs (subject to thresholding). + + [NSH-DC-ALLOCATION] and [NSH-BROADBAND-ALLOCATION] provide specific + examples of how metadata can be allocated. + + + + + +Quinn, et al. Standards Track [Page 12] + +RFC 8300 Network Service Header (NSH) January 2018 + + +2.5. NSH MD Type 2 + + When the Base Header specifies MD Type 0x2, zero or more Variable- + Length Context Headers MAY be added, immediately following the + Service Path Header (see Figure 6). Therefore, Length = 0x2, + indicates that only the Base Header and Service Path Header are + present (and in that order). The optional Variable-Length Context + Headers MUST be of an integer number of 4-bytes. The Base Header + Length field MUST be used to determine the offset to locate the + original packet or frame for SFC nodes that require access to that + information. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |Ver|O|U| TTL | Length |U|U|U|U|MD Type| Next Protocol | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Service Path Identifier | Service Index | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + ~ Variable-Length Context Headers (opt.) ~ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 6: NSH MD Type 0x2 + +2.5.1. Optional Variable-Length Metadata + + The format of the optional Variable-Length Context Headers, is as + depicted in Figure 7. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Metadata Class | Type |U| Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Variable-Length Metadata | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 7: Variable-Length Context Headers + + Metadata Class (MD Class): Defines the scope of the Type field to + provide a hierarchical namespace. Section 9.1.4 defines how the + MD Class values can be allocated to standards bodies, vendors, and + others. + + + + + + +Quinn, et al. Standards Track [Page 13] + +RFC 8300 Network Service Header (NSH) January 2018 + + + Type: Indicates the explicit type of metadata being carried. The + definition of the Type is the responsibility of the MD Class + owner. + + Unassigned bit: One unassigned bit is available for future use. + This bit MUST NOT be set, and it MUST be ignored on receipt. + + Length: Indicates the length of the variable-length metadata, in + bytes. In case the metadata length is not an integer number of + 4-byte words, the sender MUST add pad bytes immediately following + the last metadata byte to extend the metadata to an integer number + of 4-byte words. The receiver MUST round the Length field up to + the nearest 4-byte-word boundary, to locate and process the next + field in the packet. The receiver MUST access only those bytes in + the metadata indicated by the Length field (i.e., actual number of + bytes) and MUST ignore the remaining bytes up to the nearest + 4-byte-word boundary. The length may be 0 or greater. + + A value of 0 denotes a Context Header without a Variable-Length + Metadata field. + + This specification does not make any assumption about Context Headers + that are mandatory to implement or those that are mandatory to + process. These considerations are deployment specific. However, the + control plane is entitled to instruct SFC-aware SFs with the data + structure of the Context Header together with its scoping (see e.g., + Section 3.3.3 of [SFC-CONTROL-PLANE]). + + Upon receipt of a packet that belongs to a given SFP, if a mandatory- + to-process Context Header is missing in that packet, the SFC-aware SF + MUST NOT process the packet and MUST log an error at least once per + the SPI for which the mandatory metadata is missing. + + If multiple mandatory-to-process Context Headers are required for a + given SFP, the control plane MAY instruct the SFC-aware SF with the + order to consume these Context Headers. If no instructions are + provided and the SFC-aware SF will make use of or modify the specific + Context Header, then the SFC-aware SF MUST process these Context + Headers in the order they appear in an NSH packet. + + If multiple instances of the same metadata are included in an NSH + packet, but the definition of that Context Header does not allow for + it, the SFC-aware SF MUST process the first instance and ignore + subsequent instances. The SFC-aware SF MAY log or increase a counter + for this event. + + + + + + +Quinn, et al. Standards Track [Page 14] + +RFC 8300 Network Service Header (NSH) January 2018 + + +3. NSH Actions + + NSH-aware nodes (which include Service Classifiers, SFFs, SFs, and + SFC Proxies) may alter the contents of the NSH headers. These nodes + have several possible NSH-related actions: + + 1. Insert or remove the NSH: These actions can occur respectively at + the start and end of a service path. Packets are classified, and + if determined to require servicing, an NSH will be imposed. A + + Service Classifier MUST insert an NSH at the start of an SFP. An + imposed NSH MUST contain both a valid Base Header and Service + Path Header. At the end of an SFP, an SFF MUST remove the NSH + before forwarding or delivering the un-encapsulated packet. + Therefore, it is the last node operating on the service header. + + Multiple logical Classifiers may exist within a given service + path. Non-initial Classifiers may re-classify data, and that + re-classification MAY result in the selection of a different SFP. + When the logical Classifier performs re-classification that + results in a change of service path, it MUST replace the existing + NSH with a new NSH with the Base Header and Service Path Header + reflecting the new service path information and MUST set the + initial SI. The O bit, the TTL field, and unassigned flags MUST + be copied transparently from the old NSH to a new NSH. Metadata + MAY be preserved in the new NSH. + + 2. Select service path: The Service Path Header provides service + path information and is used by SFFs to determine correct service + path selection. SFFs MUST use the Service Path Header for + selecting the next SF or SFF in the service path. + + 3. Update the NSH: SFs MUST decrement the service index by one. If + an SFF receives a packet with an SPI and SI that do not + correspond to a valid next hop in a valid SFP, that packet MUST + be dropped by the SFF. + + Classifiers MAY update Context Headers if new/updated context is + available. + + If an SFC proxy is in use (acting on behalf of an NSH-unaware + Service Function for NSH actions), then the proxy MUST update the + Service Index and MAY update contexts. When an SFC Proxy + receives an NSH-encapsulated packet, it MUST remove the NSH + before forwarding it to an NSH-unaware SF. When the SFC Proxy + receives a packet back from an NSH-unaware SF, it MUST + re-encapsulate it with the correct NSH, and it MUST decrement the + Service Index by one. + + + +Quinn, et al. Standards Track [Page 15] + +RFC 8300 Network Service Header (NSH) January 2018 + + + 4. Service policy selection: Service Functions derive policy (i.e., + service actions such as permit or deny) selection and enforcement + from the NSH. Metadata shared in the NSH can provide a range of + service-relevant information such as traffic classification. + + Figure 8 maps each of the four actions above to the components in the + SFC architecture that can perform it. + + +-----------+-----------------------+-------+---------------+-------+ + | | Insert, remove, or |Forward| Update |Service| + | | replace the NSH |the NSH| the NSH |policy | + | | |packets| |sel. | + |Component +-------+-------+-------+ +-------+-------+ | + | | | | | |Dec. |Update | | + | |Insert |Remove |Replace| |Service|Context| | + | | | | | |Index |Header | | + +-----------+-------+-------+-------+-------+-------+-------+-------+ + | | + | | + | | | + | | + |Classifier | | | | | | | | + +-----------+-------+-------+-------+-------+-------+-------+-------+ + |Service | | + | | + | | | | + |Function | | | | | | | | + |Forwarder | | | | | | | | + |(SFF) | | | | | | | | + +-----------+-------+-------+-------+-------+-------+-------+-------+ + |Service | | | | | + | + | + | + |Function | | | | | | | | + |(SF) | | | | | | | | + +-----------+-------+-------+-------+-------+-------+-------+-------+ + | | + | + | | | + | + | | + |SFC Proxy | | | | | | | | + +-----------+-------+-------+-------+-------+-------+-------+-------+ + + Figure 8: NSH Action and Role Mapping + +4. NSH Transport Encapsulation + + Once the NSH is added to a packet, an outer transport encapsulation + is used to forward the original packet and the associated metadata to + the start of a service chain. The encapsulation serves two purposes: + + 1. Creates a topologically independent services plane. Packets are + forwarded to the required services without changing the + underlying network topology. + + + + + + + +Quinn, et al. Standards Track [Page 16] + +RFC 8300 Network Service Header (NSH) January 2018 + + + 2. Transit network nodes simply forward the encapsulated packets + without modification. + + The service header is independent of the transport encapsulation + used. Existing transport encapsulations can be used. The presence + of an NSH is indicated via a protocol type or another indicator in + the outer transport encapsulation. + +5. Fragmentation Considerations + + The NSH and the associated transport encapsulation header are "added" + to the encapsulated packet/frame. This additional information + increases the size of the packet. + + Within a managed administrative domain, an operator can ensure that + the underlay MTU is sufficient to carry SFC traffic without requiring + fragmentation. Given that the intended scope of the NSH is within a + single provider's operational domain, that approach is sufficient. + + However, although explicitly outside the scope of this specification, + there might be cases where the underlay MTU is not large enough to + carry the NSH traffic. Since the NSH does not provide fragmentation + support at the service plane, the transport encapsulation protocol + ought to provide the requisite fragmentation handling. For instance, + Section 9 of [RTG-ENCAP] provides exemplary approaches and guidance + for those scenarios. + + When the transport encapsulation protocol supports fragmentation, and + fragmentation procedures needs to be used, such fragmentation is part + of the transport encapsulation logic. If, as it is common, + fragmentation is performed by the endpoints of the transport + encapsulation, then fragmentation procedures are performed at the + sending NSH entity as part of the transport encapsulation, and + reassembly procedures are performed at the receiving NSH entity + during transport de-encapsulation handling logic. In no case would + such fragmentation result in duplication of the NSH header. + + For example, when the NSH is encapsulated in IP, IP-level + fragmentation coupled with Path MTU Discovery (PMTUD) (e.g., + [RFC8201]) is used. Since PMTUD relies on ICMP messages, an operator + should ensure ICMP packets are not blocked. When, on the other hand, + the underlay does not support fragmentation procedures, an error + message SHOULD be logged when dropping a packet too big. Lastly, + NSH-specific fragmentation and reassembly methods may be defined as + well, but these methods are outside the scope of this document and + subject for future work. + + + + + +Quinn, et al. Standards Track [Page 17] + +RFC 8300 Network Service Header (NSH) January 2018 + + +6. Service Path Forwarding with NSH + +6.1. SFFs and Overlay Selection + + As described above, the NSH contains a Service Path Identifier (SPI) + and a Service Index (SI). The SPI is, as per its name, an + identifier. The SPI alone cannot be used to forward packets along a + service path. Rather, the SPI provides a level of indirection + between the service path / topology and the network transport + encapsulation. Furthermore, there is no requirement for, or + expectation of, an SPI being bound to a predetermined or static + network path. + + The Service Index provides an indication of location within a service + path. The combination of SPI and SI provides the identification of a + logical SF and its order within the service plane. This combination + is used to select the appropriate network locator(s) for overlay + forwarding. The logical SF may be a single SF or a set of eligible + SFs that are equivalent. In the latter case, the SFF provides load + distribution amongst the collection of SFs as needed. + + SI serves as a mechanism for detecting invalid SFPs. In particular, + an SI value of zero indicates that forwarding is incorrect and the + packet must be discarded. + + This indirection -- SPI to overlay -- creates a true service plane. + That is, the SFF/SF topology is constructed without impacting the + network topology, but, more importantly, service-plane-only + participants (i.e., most SFs) need not be part of the network overlay + topology and its associated infrastructure (e.g., control plane, + routing tables, etc.). SFs need to be able to return a packet to an + appropriate SFF (i.e., has the requisite NSH information) when + service processing is complete. This can be via the overlay or + underlay and, in some cases, can require additional configuration on + the SF. As mentioned above, an existing overlay topology may be + used, provided it offers the requisite connectivity. + + The mapping of SPI to transport encapsulation occurs on an SFF (as + discussed above, the first SFF in the path gets an NSH encapsulated + packet from the Classifier). The SFF consults the SPI/ID values to + determine the appropriate overlay transport encapsulation protocol + (several may be used within a given network) and next hop for the + requisite SF. Table 1 depicts an example of a single next-hop SPI/ + SI-to-network overlay network locator mapping. + + + + + + + +Quinn, et al. Standards Track [Page 18] + +RFC 8300 Network Service Header (NSH) January 2018 + + + +------+------+---------------------+-------------------------+ + | SPI | SI | Next Hop(s) | Transport Encapsulation | + +------+------+---------------------+-------------------------+ + | 10 | 255 | 192.0.2.1 | VXLAN-gpe | + | | | | | + | 10 | 254 | 198.51.100.10 | GRE | + | | | | | + | 10 | 251 | 198.51.100.15 | GRE | + | | | | | + | 40 | 251 | 198.51.100.15 | GRE | + | | | | | + | 50 | 200 | 01:23:45:67:89:ab | Ethernet | + | | | | | + | 15 | 212 | Null (end of path) | None | + +------+------+---------------------+-------------------------+ + + Table 1: SFF NSH Mapping Example + + Additionally, further indirection is possible: the resolution of the + required SF network locator may be a localized resolution on an SFF, + rather than an SFC control plane responsibility, as per Tables 2 and + 3. + + Please note: VXLAN-gpe and GRE in the above table refer to + [VXLAN-GPE] and [RFC2784] [RFC7676], respectively. + + +------+-----+----------------+ + | SPI | SI | Next Hop(s) | + +------+-----+----------------+ + | 10 | 3 | SF2 | + | | | | + | 245 | 12 | SF34 | + | | | | + | 40 | 9 | SF9 | + +------+-----+----------------+ + + Table 2: NSH-to-SF Mapping Example + + + + + + + + + + + + + + +Quinn, et al. Standards Track [Page 19] + +RFC 8300 Network Service Header (NSH) January 2018 + + + +------+-------------------+-------------------------+ + | SF | Next Hop(s) | Transport Encapsulation | + +------+-------------------+-------------------------+ + | SF2 | 192.0.2.2 | VXLAN-gpe | + | | | | + | SF34 | 198.51.100.34 | UDP | + | | | | + | SF9 | 2001:db8::1 | GRE | + +------+-------------------+-------------------------+ + + Table 3: SF Locator Mapping Example + + Since the SPI is a representation of the service path, the lookup may + return more than one possible next hop within a service path for a + given SF, essentially a series of weighted (equally or otherwise) + paths to be used (for load distribution, redundancy, or policy); see + Table 4. The metric depicted in Table 4 is an example to help + illustrate weighing SFs. In a real network, the metric will range + from a simple preference (similar to routing next-hop) to a true + dynamic composite metric based on the state of a Service Function + (including load, session state, capacity, etc.). + + +------+-----+--------------+---------+ + | SPI | SI | NH | Metric | + +------+-----+--------------+---------+ + | 10 | 3 | 203.0.113.1 | 1 | + | | | | | + | | | 203.0.113.2 | 1 | + | | | | | + | 20 | 12 | 192.0.2.1 | 1 | + | | | | | + | | | 203.0.113.4 | 1 | + | | | | | + | 30 | 7 | 192.0.2.10 | 10 | + | | | | | + | | | 198.51.100.1 | 5 | + +------+-----+--------------+---------+ + + (encapsulation type omitted for formatting) + + Table 4: NSH Weighted Service Path + + The information contained in Tables 1-4 may be received from the + control plane, but the exact mechanism is outside the scope of this + document. + + + + + + +Quinn, et al. Standards Track [Page 20] + +RFC 8300 Network Service Header (NSH) January 2018 + + +6.2. Mapping the NSH to Network Topology + + As described above, the mapping of the SPI to network topology may + result in a single path, or it might result in a more complex + topology. Furthermore, the SPI-to-overlay mapping occurs at each SFF + independently. Any combination of topology selection is possible. + Please note, there is no requirement to create a new overlay topology + if a suitable one already exists. NSH packets can use any (new or + existing) overlay, provided the requisite connectivity requirements + are satisfied. + + Examples of mapping for a topology: + + 1. Next SF is located at SFFb with locator 2001:db8::1 + SFFa mapping: SPI=10 --> VXLAN-gpe, dst-ip: 2001:db8::1 + + 2. Next SF is located at SFFc with multiple network locators for + load-distribution purposes: + SFFb mapping: SPI=10 --> VXLAN-gpe, dst_ip:203.0.113.1, + 203.0.113.2, 203.0.113.3, equal cost + + 3. Next SF is located at SFFd with two paths from SFFc, one for + redundancy: + SFFc mapping: SPI=10 --> VXLAN-gpe, dst_ip:192.0.2.10 cost=10, + 203.0.113.10, cost=20 + + In the above example, each SFF makes an independent decision about + the network overlay path and policy for that path. In other words, + there is no a priori mandate about how to forward packets in the + network (only the order of services that must be traversed). + + The network operator retains the ability to engineer the network + paths as required. For example, the overlay path between SFFs may + utilize traffic engineering, QoS marking, or ECMP, without requiring + complex configuration and network protocol support to be extended to + the service path explicitly. In other words, the network operates as + expected, and evolves as required, as does the service plane. + +6.3. Service Plane Visibility + + The SPI and SI serve an important function for visibility into the + service topology. An operator can determine what service path a + packet is "on" and its location within that path simply by viewing + NSH information (packet capture, IP Flow Information Export (IPFIX), + etc.). The information can be used for service scheduling and + placement decisions, troubleshooting, and compliance verification. + + + + + +Quinn, et al. Standards Track [Page 21] + +RFC 8300 Network Service Header (NSH) January 2018 + + +6.4. Service Graphs + + While a given realized SFP is a specific sequence of Service + Functions, the service, as seen by a user, can actually be a + collection of SFPs, with the interconnection provided by Classifiers + (in-service path, non-initial re-classification). These internal re- + Classifiers examine the packet at relevant points in the network, + and, if needed, SPI and SI are updated (whether this update is a re- + write, or the imposition of a new NSH with new values is + implementation specific) to reflect the "result" of the + classification. These Classifiers may, of course, also modify the + metadata associated with the packet. + Section 2.1 of [RFC7665] describes Service Graphs in detail. + +7. Policy Enforcement with NSH + +7.1. NSH Metadata and Policy Enforcement + + As described in Section 2, NSH provides the ability to carry metadata + along a service path. This metadata may be derived from several + sources. Common examples include: + + Network nodes/devices: Information provided by network nodes can + indicate network-centric information (such as VPN Routing and + Forwarding (VRF) or tenant) that may be used by Service Functions + or conveyed to another network node post service path egress. + + External (to the network) systems: External systems, such as + orchestration systems, often contain information that is valuable + for Service Function policy decisions. In most cases, this + information cannot be deduced by network nodes. For example, a + cloud orchestration platform placing workloads "knows" what + application is being instantiated and can communicate this + information to all NSH nodes via metadata carried in the Context + Header(s). + + Service Functions: A Classifier co-resident with Service Functions + often performs very detailed and valuable classification. + + Regardless of the source, metadata reflects the "result" of + classification. The granularity of classification may vary. For + example, a network switch, acting as a Classifier, might only be able + to classify based on a 2-tuple, or based on a 5-tuple, while a + Service Function may be able to inspect application information. + Regardless of granularity, the classification information can be + represented in the NSH. + + + + + +Quinn, et al. Standards Track [Page 22] + +RFC 8300 Network Service Header (NSH) January 2018 + + + Once the data is added to the NSH, it is carried along the service + path. NSH-aware SFs receive the metadata, and can use that metadata + for local decisions and policy enforcement. Figures 9 and 10 + highlight the relationship between metadata and policy. + + +-------+ +-------+ +-------+ + | SFF )------->( SFF |------->| SFF | + +---+---+ +---+---+ +---+---+ + ^ | | + ,-|-. ,-|-. ,-|-. + / \ / \ / \ + ( Class ) ( SF1 ) ( SF2 ) + \ ify / \ / \ / + `---' `---' `---' + 5-tuple: Permit Inspect + Tenant A Tenant A AppY + AppY + + Figure 9: Metadata and Policy + + +-----+ +-----+ +-----+ + | SFF |---------> | SFF |----------> | SFF | + +--+--+ +--+--+ +--+--+ + ^ | | + ,-+-. ,-+-. ,-+-. + / \ / \ / \ + ( Class ) ( SF1 ) ( SF2 ) + \ ify / \ / \ / + `-+-' `---' `---' + | Permit Deny AppZ + +---+---+ employees + | | + +-------+ + External + system: + Employee + AppZ + + Figure 10: External Metadata and Policy + + In both of the examples above, the Service Functions perform policy + decisions based on the result of the initial classification: the SFs + did not need to perform re-classification; instead, they rely on an + antecedent classification for local policy enforcement. + + Depending on the information carried in the metadata, data privacy + impact needs to be considered. For example, if the metadata conveys + tenant information, that information may need to be authenticated + + + +Quinn, et al. Standards Track [Page 23] + +RFC 8300 Network Service Header (NSH) January 2018 + + + and/or encrypted between the originator and the intended recipients + (which may include intended SFs only); one approach to an optional + capability to do this is explored in [NSH-ENCRYPT]. The NSH itself + does not provide privacy functions, rather it relies on the transport + encapsulation/overlay. An operator can select the appropriate set of + transport encapsulation protocols to ensure confidentiality (and + other security) considerations are met. Metadata privacy and + security considerations are a matter for the documents that define + metadata format. + +7.2. Updating/Augmenting Metadata + + Post-initial metadata imposition (typically, performed during initial + service path determination), the metadata may be augmented or + updated: + + 1. Metadata Augmentation: Information may be added to the NSH's + existing metadata, as depicted in Figure 11. For example, if the + initial classification returns the tenant information, a + secondary classification (perhaps co-resident with deep packet + inspection (DPI) or server load balancing (SLB)) may augment the + tenant classification with application information, and impose + that new information in NSH metadata. The tenant classification + is still valid and present, but additional information has been + added to it. + + 2. Metadata Update: Subsequent Classifiers may update the initial + classification if it is determined to be incorrect or not + descriptive enough. For example, the initial Classifier adds + metadata that describes the traffic as "Internet", but a security + Service Function determines that the traffic is really "attack". + Figure 12 illustrates an example of updating metadata. + + + + + + + + + + + + + + + + + + + +Quinn, et al. Standards Track [Page 24] + +RFC 8300 Network Service Header (NSH) January 2018 + + + +-----+ +-----+ +-----+ + | SFF |---------> | SFF |----------> | SFF | + +--+--+ +--+--+ +--+--+ + ^ | | + ,---. ,---. ,---. + / \ / \ / \ + ( Class ) ( SF1 ) ( SF2 ) + \ / \ / \ / + `-+-' `---' `---' + | Inspect Deny + +---+---+ employees employee+ + | | Class=AppZ appZ + +-------+ + External + system: + Employee + + Figure 11: Metadata Augmentation + + +-----+ +-----+ +-----+ + | SFF |---------> | SFF |----------> | SFF | + +--+--+ +--+--+ +--+--+ + ^ | | + ,---. ,---. ,---. + / \ / \ / \ + ( Class ) ( SF1 ) ( SF2 ) + \ / \ / \ / + `---' `---' `---' + 5-tuple: Inspect Deny + Tenant A Tenant A attack + --> attack + + Figure 12: Metadata Update + +7.3. Service Path Identifier and Metadata + + Metadata information may influence the service path selection since + the Service Path Identifier values can represent the result of + classification. A given SPI can be defined based on classification + results (including metadata classification). The imposition of the + SPI and SI results in the packet being placed on the newly specified + SFP at the position indicated by the imposed SPI and SI. + + This relationship provides the ability to create a dynamic service + plane based on complex classification, without requiring each node to + be capable of such classification or requiring a coupling to the + network topology. This yields Service Graph functionality as + + + + +Quinn, et al. Standards Track [Page 25] + +RFC 8300 Network Service Header (NSH) January 2018 + + + described in Section 6.4. Figure 13 illustrates an example of this + behavior. + + +-----+ +-----+ +-----+ + | SFF |---------> | SFF |------+---> | SFF | + +--+--+ +--+--+ | +--+--+ + | | | | + ,---. ,---. | ,---. + / \ / SF1 \ | / \ + ( SCL ) ( + ) | ( SF2 ) + \ / \SCL2 / | \ / + `---' `---' +-----+ `---' + 5-tuple: Inspect | SFF | Original + Tenant A Tenant A +--+--+ next SF + --> DoS | + V + ,-+-. + / \ + ( SF10 ) + \ / + `---' + DoS + "Scrubber" + + Legend: + SCL = Service Classifier + + Figure 13: Path ID and Metadata + + Specific algorithms for mapping metadata to an SPI are outside the + scope of this document. + +8. Security Considerations + + NSH security must be considered in the contexts of the SFC + architecture and operators' environments. One important + characteristic of NSH is that it is not an end-to-end protocol. As + opposed to a protocol that "starts" on a host and "ends" on a server + or another host, NSH is typically imposed by a network device on + ingress to the SFC domain and removed at the egress of the SFC + domain. As such, and as with any other network-centric protocols + (e.g., IP Tunneling, Traffic Engineering, MPLS, or Provider- + Provisioned Virtual Private Networks), there is an underlying trust + in the network devices responsible for imposing, removing, and acting + on NSH information. + + The following sections detail an analysis and present a set of + requirements and recommendations in those two areas. + + + +Quinn, et al. Standards Track [Page 26] + +RFC 8300 Network Service Header (NSH) January 2018 + + +8.1. NSH Security Considerations from Operators' Environments + + Trusted Devices + + All Classifiers, SFFs and SFs (hereinafter referred to as "SFC + devices") within an operator's environment are assumed to have + been selected, vetted, and actively maintained; therefore, they + are trusted by that operator. This assumption differs from the + oft held view that devices are untrusted, often referred to as the + "zero-trust model". Operators SHOULD regularly monitor (i.e., + continuously audit) these devices to help ensure compliant + behavior. This trust, therefore, extends into NSH operations: SFC + devices are not, themselves, considered to be attack vectors. + This assumption, and the resultant conclusion is reasonable since + this is the very basis of an operator posture; the operator + depends on this reality to function. If these devices are not + trusted, and indeed are compromised, almost the entirety of the + operator's standard-based IP and MPLS protocol suites are + vulnerable; therefore, the operation of the entire network is + compromised. Although there are well-documented monitoring-based + methods for detecting compromise (such as included continuous + monitoring and audit and log review), these may not be sufficient + to contain damage by a completely compromised element. + + Methods and best practices to secure devices are also widely + documented and outside the scope of this document. + + Single Domain Boundary + + As per [RFC7665], NSH is designed for use within a single + administrative domain. This scoping provides two important + characteristics: + + i) Clear NSH boundaries + + NSH egress devices MUST strip the NSH headers before they send the + users' packets or frames out of the NSH domain. + + Means to prevent leaking privacy-related information outside an + administrative domain are natively supported by the NSH given that + the last SFF of a service path will systematically remove the NSH + encapsulation before forwarding a packet exiting the service path. + + The second step in such prevention is to filter the transport + encapsulation protocol used by NSH at the domain edge. The + transport encapsulation protocol MUST be filtered and MUST NOT + leave the domain edge. + + + + +Quinn, et al. Standards Track [Page 27] + +RFC 8300 Network Service Header (NSH) January 2018 + + + Depending upon the transport encapsulation protocol used for NSH, + this can be done either by completely blocking the transport + encapsulation (e.g., if MPLS is the chosen NSH transport + encapsulation protocol, it is therefore never allowed to leave the + domain) or by examining the carried protocol with the transport + encapsulation (e.g., if VXLAN-gpe is used as the NSH transport + encapsulation protocol, all domain edges need to filter based on + the carried protocol in the VXLAN-gpe.) + + The other consequence of this bounding is that ingress packets + MUST also be filtered to prevent attackers from sending in NSH + packets with service path identification and metadata of their own + selection. The same filters as described above for both the NSH + at SFC devices and for the transport encapsulation protocol as + general edge protections MUST be applied on ingress. + + In summary, packets originating outside the SFC-enabled domain + MUST be dropped if they contain an NSH. Similarly, packets + exiting the SFC-enabled domain MUST be dropped if they contain an + NSH. + + ii) Mitigation of external threats + + As per the trusted SFC device points raised above, given that NSH + is scoped within an operator's domain, that operator can ensure + that the environment and its transitive properties comply with + that operator's required security posture. Continuous audits for + assurance are recommended with this reliance on a fully trusted + environment. The term "continuous audits" describes a method + (automated or manual) of checking security-control compliance on a + regular basis, at some set period of time. + +8.2. NSH Security Considerations from the SFC Architecture + + The SFC architecture defines functional roles (e.g., SFF), as well as + protocol elements (e.g., Metadata). This section considers each role + and element in the context of threats posed in the areas of integrity + and confidentiality. As with routing, the distributed computation + model assumes a distributed trust model. + + An important consideration is that NSH contains mandatory-to-mute + fields, and further, the SFC architecture describes cases where other + fields in NSH change, all on a possible SFP hop-by-hop basis. This + means that any cryptographic solution requires complex key + distribution and life-cycle operations. + + + + + + +Quinn, et al. Standards Track [Page 28] + +RFC 8300 Network Service Header (NSH) January 2018 + + +8.2.1. Integrity + + SFC devices + + SFC devices MAY perform various forms of verification on received + NSH packets such as only accepting NSH packets from expected + devices, checking that NSH SPI and SI values received from + expected devices conform to expected values and so on. + Implementation of these additional checks are a local matter and, + thus, out of scope of this document. + + NSH Base and Service Path Headers + + Attackers who can modify packets within the operator's network may + be able to modify the SFP, path position, and/or the metadata + associated with a packet. + + One specific concern is an attack in which a malicious + modification of the SPI/SI results in an alteration of the path to + avoid security devices. The options discussed in this section + help thwart that attack, and so does the use of the optional + "Proof of Transit" method [PROOF-OF-TRANSIT]. + + As stated above, SFC devices are trusted; in the case where an SFC + device is compromised, NSH integrity protection would be subject + to forging (in many cases) as well. + + NSH itself does not mandate protocol-specific integrity + protection. However, if an operator deems protection is required, + several options are viable: + + 1. SFF/SF NSH verification + + Although, strictly speaking, not integrity protection, some of + the techniques mentioned above, such as checking expected NSH + values are received from expected SFC device(s), can provide a + form of verification without incurring the burden of a full- + fledged integrity-protection deployment. + + 2. Transport Security + + NSH is always encapsulated by an outer transport encapsulation + as detailed in Section 4 of this specification, and as + depicted in Figure 1. If an operator deems cryptographic + integrity protection necessary due to their risk analysis, + then an outer transport encapsulation that provides such + protection [RFC6071], such as IPsec, MUST be used. + + + + +Quinn, et al. Standards Track [Page 29] + +RFC 8300 Network Service Header (NSH) January 2018 + + + Although the threat model and recommendations of Section 5 of + BCP 72 [RFC3552] would normally require cryptographic data + origin authentication for the header, this document does not + mandate such mechanisms in order to reflect the operational + and technical realities of deployment. + + Given that NSH is transport independent, as mentioned above, a + secure transport, such as IPsec can be used for carry NSH. + IPsec can be used either alone or in conjunction with other + transport encapsulation protocols, in turn, encapsulating NSH. + + Operators MUST ensure the selected transport encapsulation + protocol can be supported by the transport encapsulation/ + underlay of all relevant network segments as well as SFFs, + SFs, and SFC Proxies in the service path. + + If connectivity between SFC-enabled devices traverses the + public Internet, then such connectivity MUST be secured at the + transport encapsulation layer. IPsec is an example of such a + transport. + + 3. NSH Variable Header-Based Integrity + + Lastly, NSH MD Type 2 provides, via variable-length headers, + the ability to append cryptographic integrity protection to + the NSH packet. The implementation of such a scheme is + outside the scope of this document. + + NSH metadata + + As with the Base and Service Path Headers, if an operator deems + cryptographic integrity protection needed, then an existing, + standard transport protocol MUST be used since the integrity + protection applies to entire encapsulated NSH packets. As + mentioned above, a risk assessment that deems data-plane traffic + subject to tampering will apply not only to NSH but to the + transport information; therefore, the use of a secure transport is + likely needed already to protect the entire stack. + + If an MD Type 2 variable header integrity scheme is in place, then + the integrity of the metadata can be ensured via that mechanism as + well. + + + + + + + + + +Quinn, et al. Standards Track [Page 30] + +RFC 8300 Network Service Header (NSH) January 2018 + + +8.2.2. Confidentiality + + SFC devices + + SFC devices can "see" (and need to use) NSH information. + + NSH Base and Service Path Headers + + SPI and other base / service path information does not typically + require confidentiality; however, if an operator does deem + confidentiality to be required, then, as with integrity, an + existing transport encapsulation that provides encryption MUST be + utilized. + + NSH metadata + + An attacker with access to the traffic in an operator's network + can potentially observe the metadata NSH carries with packets, + potentially discovering privacy-sensitive information. + + Much of the metadata carried by NSH is not sensitive. It often + reflects information that can be derived from the underlying + packet or frame. Direct protection of such information is not + necessary, as the risks are simply those of carrying the + underlying packet or frame. + + Implementers and operators MUST be aware that metadata can have + privacy implications, and those implications are sometimes hard to + predict. Therefore, attached metadata should be limited to that + necessary for correct operation of the SFP. Further, [RFC8165] + defines metadata considerations that operators can take into + account when using NSH. + + Protecting NSH metadata information between SFC components can be + done using transport encapsulation protocols with suitable + security capabilities, along the lines discussed above. If a + security analysis deems these protections necessary, then security + features in the transport encapsulation protocol (such as IPsec) + MUST be used. + + One useful element of providing privacy protection for sensitive + metadata is described under the "SFC Encapsulation" area of the + Security Considerations of [RFC7665]. Operators can and should + use indirect identification for metadata deemed to be sensitive + (such as personally identifying information), significantly + mitigating the risk of a privacy violation. In particular, + subscriber-identifying information should be handled carefully, + and, in general, SHOULD be obfuscated. + + + +Quinn, et al. Standards Track [Page 31] + +RFC 8300 Network Service Header (NSH) January 2018 + + + For those situations where obfuscation is either inapplicable or + judged to be insufficient, an operator can also encrypt the + metadata. An approach to an optional capability to do this was + explored in [NSH-ENCRYPT]. For other situations where greater + assurance is desired, optional mechanisms such as + [PROOF-OF-TRANSIT] can be used. + +9. IANA Considerations + +9.1. NSH Parameters + + IANA has created a new "Network Service Header (NSH) Parameters" + registry. The following subsections detail new registries within the + "Network Service Header (NSH) Parameters" registry. + +9.1.1. NSH Base Header Bits + + There are five unassigned bits (U bits) in the NSH Base Header, and + one assigned bit (O bit). New bits are assigned via Standards Action + [RFC8126]. + + Bit 2 - O (OAM) bit + Bit 3 - Unassigned + Bits 16-19 - Unassigned + +9.1.2. NSH Version + + IANA has set up the "NSH Version" registry. New values are assigned + via Standards Action [RFC8126]. + + +-------------+---------------------------------+-----------+ + | Version | Description | Reference | + +-------------+---------------------------------+-----------+ + | Version 00b | Protocol as defined by RFC 8300 | RFC 8300 | + | Version 01b | Reserved | RFC 8300 | + | Version 10b | Unassigned | | + | Version 11b | Unassigned | | + +-------------+---------------------------------+-----------+ + + Table 5: NSH Version + + + + + + + + + + + +Quinn, et al. Standards Track [Page 32] + +RFC 8300 Network Service Header (NSH) January 2018 + + +9.1.3. NSH MD Types + + IANA has set up the "NSH MD Types" registry, which contains 4-bit + values. MD Type values 0x0, 0x1, 0x2, and 0xF are specified in this + document; see Table 6. Registry entries are assigned via the "IETF + Review" policy defined in RFC 8126 [RFC8126]. + + +-----------+-----------------+-----------+ + | MD Type | Description | Reference | + +-----------+-----------------+-----------+ + | 0x0 | Reserved | RFC 8300 | + | | | | + | 0x1 | NSH MD Type 1 | RFC 8300 | + | | | | + | 0x2 | NSH MD Type 2 | RFC 8300 | + | | | | + | 0x3 - 0xE | Unassigned | | + | | | | + | 0xF | Experimentation | RFC 8300 | + +-----------+-----------------+-----------+ + + Table 6: MD Type Values + +9.1.4. NSH MD Class + + IANA has set up the "NSH MD Class" registry, which contains 16-bit + values. New allocations are to be made according to the following + policies: + + 0x0000 to 0x01ff: IETF Review + 0x0200 to 0xfff5: Expert Review + + IANA has assigned the values as follows: + + +------------------+------------------------+------------+ + | Value | Meaning | Reference | + +------------------+------------------------+------------+ + | 0x0000 | IETF Base NSH MD Class | RFC 8300 | + | | | | + | 0xfff6 to 0xfffe | Experimental | RFC 8300 | + | | | | + | 0xffff | Reserved | RFC 8300 | + +------------------+------------------------+------------+ + + Table 7: NSH MD Class + + A registry for Types for the MD Class of 0x0000 is defined in + Section 9.1.5. + + + +Quinn, et al. Standards Track [Page 33] + +RFC 8300 Network Service Header (NSH) January 2018 + + + Designated Experts evaluating new allocation requests from the + "Expert Review" range should principally consider whether a new MD + class is needed compared to adding MD Types to an existing class. + The Designated Experts should also encourage the existence of an + associated and publicly visible registry of MD Types although this + registry need not be maintained by IANA. + + When evaluating a request for an allocation, the Expert should verify + that the allocation plan includes considerations to handle privacy + and security issues associated with the anticipated individual MD + Types allocated within this class. These plans should consider, when + appropriate, alternatives such as indirection, encryption, and + limited-deployment scenarios. Information that can't be directly + derived from viewing the packet contents should be examined for + privacy and security implications. + +9.1.5. NSH IETF-Assigned Optional Variable-Length Metadata Types + + The Type values within the IETF Base NSH MD Class, i.e., when the MD + Class is set to 0x0000 (see Section 9.1.4), are the Types owned by + the IETF. Per this document, IANA has created a registry for the + Type values for the IETF Base NSH MD Class called the "NSH IETF- + Assigned Optional Variable-Length Metadata Types" registry, as + specified in Section 2.5.1. + + The type values are assigned via Standards Action [RFC8126]. + + No initial values are assigned at the creation of the registry. + + + + + + + + + + + + + + + + + + + + + + + +Quinn, et al. Standards Track [Page 34] + +RFC 8300 Network Service Header (NSH) January 2018 + + +9.1.6. NSH Next Protocol + + IANA has set up the "NSH Next Protocol" registry, which contains + 8-bit values. Next Protocol values 0, 1, 2, 3, 4, and 5 are defined + in this document (see Table 8). New values are assigned via "Expert + Review" as per [RFC8126]. + + +---------------+--------------+-----------+ + | Next Protocol | Description | Reference | + +---------------+--------------+-----------+ + | 0x00 | Unassigned | | + | | | | + | 0x01 | IPv4 | RFC 8300 | + | | | | + | 0x02 | IPv6 | RFC 8300 | + | | | | + | 0x03 | Ethernet | RFC 8300 | + | | | | + | 0x04 | NSH | RFC 8300 | + | | | | + | 0x05 | MPLS | RFC 8300 | + | | | | + | 0x06 - 0xFD | Unassigned | | + | | | | + | 0xFE | Experiment 1 | RFC 8300 | + | | | | + | 0xFF | Experiment 2 | RFC 8300 | + +---------------+--------------+-----------+ + + Table 8: NSH Base Header Next Protocol Values + + Expert Review requests MUST include a single codepoint per request. + Designated Experts evaluating new allocation requests from this + registry should consider the potential scarcity of codepoints for an + 8-bit value, and check both for duplications and availability of + documentation. If the actual assignment of the Next Protocol field + allocation reaches half of the range (that is, when there are 128 + unassigned values), IANA needs to alert the IESG. At that point, a + new more strict allocation policy SHOULD be considered. + +10. NSH-Related Codepoints + +10.1. NSH Ethertype + + An IEEE Ethertype, 0x894F, has been allocated for NSH. + + + + + + +Quinn, et al. Standards Track [Page 35] + +RFC 8300 Network Service Header (NSH) January 2018 + + +11. References + +11.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, + <https://www.rfc-editor.org/info/rfc2119>. + + [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function + Chaining (SFC) Architecture", RFC 7665, + DOI 10.17487/RFC7665, October 2015, + <https://www.rfc-editor.org/info/rfc7665>. + + [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for + Writing an IANA Considerations Section in RFCs", BCP 26, + RFC 8126, DOI 10.17487/RFC8126, June 2017, + <https://www.rfc-editor.org/info/rfc8126>. + + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC + 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, + May 2017, <https://www.rfc-editor.org/info/rfc8174>. + +11.2. Informative References + + [NSH-BROADBAND-ALLOCATION] + Napper, J., Kumar, S., Muley, P., Henderickx, W., and M. + Boucadair, "NSH Context Header Allocation -- Broadband", + Work in Progress, draft-napper-sfc-nsh-broadband- + allocation-04, November 2017. + + [NSH-DC-ALLOCATION] + Guichard, J., Smith, M., Kumar, S., Majee, S., Agarwal, + P., Glavin, K., Laribi, Y., and T. Mizrahi, "Network + Service Header (NSH) MD Type 1: Context Header Allocation + (Data Center)", Work in Progress, + draft-guichard-sfc-nsh-dc-allocation-07, August 2017. + + [NSH-ENCRYPT] + Reddy, T., Patil, P., Fluhrer, S., and P. Quinn, + "Authenticated and encrypted NSH service chains", Work in + Progress, draft-reddy-sfc-nsh-encrypt-00, April 2015. + + + + + + + + + +Quinn, et al. Standards Track [Page 36] + +RFC 8300 Network Service Header (NSH) January 2018 + + + [PROOF-OF-TRANSIT] + Brockners, F., Bhandari, S., Dara, S., Pignataro, C., + Leddy, J., Youell, S., Mozes, D., and T. Mizrahi, "Proof + of Transit", Work in Progress, draft-brockners-proof- + of-transit-04, October 2017. + + [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. + Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, + DOI 10.17487/RFC2784, March 2000, + <https://www.rfc-editor.org/info/rfc2784>. + + [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC + Text on Security Considerations", BCP 72, RFC 3552, + DOI 10.17487/RFC3552, July 2003, + <https://www.rfc-editor.org/info/rfc3552>. + + [RFC3692] Narten, T., "Assigning Experimental and Testing Numbers + Considered Useful", BCP 82, RFC 3692, + DOI 10.17487/RFC3692, January 2004, + <https://www.rfc-editor.org/info/rfc3692>. + + [RFC6071] Frankel, S. and S. Krishnan, "IP Security (IPsec) and + Internet Key Exchange (IKE) Document Roadmap", RFC 6071, + DOI 10.17487/RFC6071, February 2011, + <https://www.rfc-editor.org/info/rfc6071>. + + [RFC6291] Andersson, L., van Helvoort, H., Bonica, R., Romascanu, + D., and S. Mansfield, "Guidelines for the Use of the "OAM" + Acronym in the IETF", BCP 161, RFC 6291, + DOI 10.17487/RFC6291, June 2011, + <https://www.rfc-editor.org/info/rfc6291>. + + [RFC7325] Villamizar, C., Ed., Kompella, K., Amante, S., Malis, A., + and C. Pignataro, "MPLS Forwarding Compliance and + Performance Requirements", RFC 7325, DOI 10.17487/RFC7325, + August 2014, <https://www.rfc-editor.org/info/rfc7325>. + + [RFC7498] Quinn, P., Ed. and T. Nadeau, Ed., "Problem Statement for + Service Function Chaining", RFC 7498, + DOI 10.17487/RFC7498, April 2015, + <https://www.rfc-editor.org/info/rfc7498>. + + [RFC7676] Pignataro, C., Bonica, R., and S. Krishnan, "IPv6 Support + for Generic Routing Encapsulation (GRE)", RFC 7676, + DOI 10.17487/RFC7676, October 2015, + <https://www.rfc-editor.org/info/rfc7676>. + + + + + +Quinn, et al. Standards Track [Page 37] + +RFC 8300 Network Service Header (NSH) January 2018 + + + [RFC8165] Hardie, T., "Design Considerations for Metadata + Insertion", RFC 8165, DOI 10.17487/RFC8165, May 2017, + <https://www.rfc-editor.org/info/rfc8165>. + + [RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed., + "Path MTU Discovery for IP version 6", STD 87, RFC 8201, + DOI 10.17487/RFC8201, July 2017, + <https://www.rfc-editor.org/info/rfc8201>. + + [RTG-ENCAP] + Nordmark, E., Tian, A., Gross, J., Hudson, J., Kreeger, + L., Garg, P., Thaler, P., and T. Herbert, "Encapsulation + Considerations", Work in Progress, + draft-ietf-rtgwg-dt-encap-02, October 2016. + + [SFC-CONTROL-PLANE] + Boucadair, M., "Service Function Chaining (SFC) Control + Plane Components & Requirements", Work in Progress, + draft-ietf-sfc-control-plane-08, October 2016. + + [SFC-OAM-FRAMEWORK] + Aldrin, S., Pignataro, C., Kumar, N., Akiya, N., Krishnan, + R., and A. Ghanwani, "Service Function Chaining (SFC) + Operation, Administration and Maintenance (OAM) + Framework", Work in Progress, + draft-ietf-sfc-oam-framework-03, September 2017. + + [VXLAN-GPE] + Maino, F., Kreeger, L., and U. Elzur, "Generic Protocol + Extension for VXLAN", Work in Progress, + draft-ietf-nvo3-vxlan-gpe-05, October 2017. + +Acknowledgments + + The authors would like to thank Sunil Vallamkonda, Nagaraj Bagepalli, + Abhijit Patra, Peter Bosch, Darrel Lewis, Pritesh Kothari, Tal + Mizrahi, and Ken Gray for their detailed reviews, comments, and + contributions. + + A special thank you goes to David Ward and Tom Edsall for their + guidance and feedback. + + Additionally, the authors would like to thank Larry Kreeger for his + invaluable ideas and contributions, which are reflected throughout + this document. + + Loa Andersson provided a thorough review and valuable comments; we + thank him for that. + + + +Quinn, et al. Standards Track [Page 38] + +RFC 8300 Network Service Header (NSH) January 2018 + + + Reinaldo Penno deserves a particular thank you for his architecture + and implementation work that helped guide the protocol concepts and + design. + + The editors also acknowledge comprehensive reviews and respective + useful suggestions by Med Boucadair, Adrian Farrel, Juergen + Schoenwaelder, Acee Lindem, and Kathleen Moriarty. + + Lastly, David Dolson has provided significant review, feedback, and + suggestions throughout the evolution of this document. His + contributions are very much appreciated. + +Contributors + + This WG document originated as draft-quinn-sfc-nsh; the following are + its coauthors and contributors along with their respective + affiliations at the time of WG adoption. The editors of this + document would like to thank and recognize them and their + contributions. These coauthors and contributors provided invaluable + concepts and content for this document's creation. + + o Jim Guichard, Cisco Systems, Inc. + o Surendra Kumar, Cisco Systems, Inc. + o Michael Smith, Cisco Systems, Inc. + o Wim Henderickx, Alcatel-Lucent + o Tom Nadeau, Brocade + o Puneet Agarwal + o Rajeev Manur, Broadcom + o Abhishek Chauhan, Citrix + o Joel Halpern, Ericsson + o Sumandra Majee, F5 + o David Melman, Marvell + o Pankaj Garg, Microsoft + o Brad McConnell, Rackspace + o Chris Wright, Red Hat, Inc. + o Kevin Glavin, Riverbed + o Hong (Cathy) Zhang, Huawei US R&D + o Louis Fourie, Huawei US R&D + o Ron Parker, Affirmed Networks + o Myo Zarny, Goldman Sachs + o Andrew Dolganow, Alcatel-Lucent + o Rex Fernando, Cisco Systems, Inc. + o Praveen Muley, Alcatel-Lucent + o Navindra Yadav, Cisco Systems, Inc. + + + + + + + +Quinn, et al. Standards Track [Page 39] + +RFC 8300 Network Service Header (NSH) January 2018 + + +Authors' Addresses + + Paul Quinn (editor) + Cisco Systems, Inc. + + Email: paulq@cisco.com + + + Uri Elzur (editor) + Intel + + Email: uri.elzur@intel.com + + + Carlos Pignataro (editor) + Cisco Systems, Inc. + + Email: cpignata@cisco.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Quinn, et al. Standards Track [Page 40] + |