RFC 8300
Network Service Header (NSH)
Network Service Header (NSH) 🎀 (Part 1 of 9)
okay bestie, this is RFC 8300 🦋 It's a Standards Track document from January 2018, with ISSN 2070-1721. Three editors wrote it: P. Quinn (Cisco), U. Elzur (Intel), and C. Pignataro (Cisco). Its header doesn't list any Obsoletes or Updates lines, so it isn't replacing or patching another RFC. It is 2018 energy and it's literally iconic 💅
Abstract
okay so the NSH is a header that gets slapped onto packets or frames 💖 Its whole job is to make Service Function Paths (SFPs) happen. It also gives you a way to swap metadata along the service paths once they're up and running ✨ The NSH is the Service Function Chaining (SFC) encapsulation you need to make the SFC architecture work, and that architecture is defined in RFC 7665 🧚
Status of This Memo
this one is a Internet Standards Track document 🌈 Wait, correction: it says "an Internet Standards Track document" 💜
It came out of the IETF, the Internet Engineering Task Force, and it reflects what the IETF community agreed on. It went through public review and got the green light from the Internet Engineering Steering Group (IESG) 🫶 If you want more on Internet Standards, check Section 2 of RFC 7841.
Errata, the current status, and feedback are all found at https://www.rfc-editor.org/info/rfc8300 🍓
Copyright Notice
the IETF Trust and the document authors own the copyright, and it's dated 2018 🔒 All rights reserved, obviously.
This doc is covered by BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents, which you can read at https://trustee.ietf.org/license-info. Those rules are the ones in force on the day it was published, so please actually read them. They explain what you're allowed to do with the document 🙈 If you pull Code Components out of this document, they have to include the Simplified BSD License text described in Section 4.e of the Trust Legal Provisions. They also come with no warranty, just like the Simplified BSD License says.
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 ................................................401. Introduction ✨
Service Functions are everywhere and they're honestly essential 💅 They do stuff like security, WAN acceleration, and server load balancing. A Service Function can show up at different spots in the network infrastructure, like the WAN, a data center, and so on.
Before the SFC architecture [RFC7665] and this protocol existed, Service Function deployments were pretty static and tied to topology for insertion and policy selection 🙈 They also didn't play well with the elastic, virtualized environments we're living in now.
New data-center and cloud architectures need way more flexible deployment models ☁️ The move to virtual platforms also calls for an agile service insertion model that can deliver dynamic, elastic services. Specifically, these three things are necessary:
- The movement of Service Functions and application workloads in the network.
- The ability to easily bind service policy to granular information, such as per-subscriber state.
- The capability to steer traffic to the requisite Service Function(s).
So this document is the Network Service Header (NSH) spec 🦋 It defines a new data-plane protocol, and it's an encapsulation for SFCs. The NSH wraps an original packet or frame, and then an outer transport encapsulation wraps the NSH. That outer layer is what delivers the NSH to NSH-aware network elements. Here's the vibe, per Figure 1:
+------------------------------+
| Transport Encapsulation |
+------------------------------+
| Network Service Header (NSH) |
+------------------------------+
| Original Packet / Frame |
+------------------------------+Figure 1: Network Service Header Encapsulation
The NSH is made up of these elements:
- Service Function Path identification.
- Indication of location within a Service Function Path.
- Optional, per-packet metadata (fixed-length or variable).
[RFC7665] gives you an overview of a service chaining architecture that clearly spells out the roles of each element and the scope of an SFC encapsulation 👑 Figure 3 of [RFC7665] shows the SFC architectural components after classification. The NSH is the SFC encapsulation that [RFC7665] is talking about.
1.1. Applicability
The NSH is built to be easy to implement across a range of devices, both physical and virtual, including hardware platforms. Main character energy 💖
It's meant for use within a single provider's operational domain. That scope is intentionally tight, which [RFC7665] also explains, and it's limited to a single network administrative domain. Here, a "domain" is a set of network entities under one administration. A network administrative domain can be a single data center, or an overlay domain that uses 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
okay this part is the key-word lore 📜 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. Lowercase versions don't count 🫶
1.3. Definition of Terms
Here's the glossary, so everyone's on the same page 📖
- Byte: All references to "bytes" in this document refer to 8-bit bytes, or octets.
- Classification: Defined in [RFC7665].
- Classifier: Defined in [RFC7665].
- 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 lets you summarize a classification result in the packet itself, so you don't have to reclassify later 🧠 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 outer header (i.e., transport encapsulation) information.
- Network Overlay: Logical network built on top of an existing network (the underlay). Packets get 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 than the generic "SFC-aware" [RFC7665].
- Service Classifier: Logical entity providing classification function. Since they're logical, Classifiers may be co-resident with SFC elements like 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 happen as needed, and it can alter a service path or create a new one 💅
- 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 where all SFs and SFC Proxies live [RFC7665] ✨
- SFC Proxy: Defined in [RFC7665].
1.4. Problem Space
The NSH fixes several limitations that come with Service Function deployments 🌈 [RFC7498] gives a full breakdown of those issues, so go check it out if you want the deep dive 🍓
Okay bestie, let's get into it 🦋
1.5. NSH-Based Service Chaining 💅
okay so the NSH creates its own dedicated service plane 🧚 and the big wins are:
- Topological Independence 🌸: forwarding of services happens inside the service plane, so the underlying network topology does not need to be modified. ✨ The NSH gives you an identifier that picks which network overlay to use for the actual forwarding. it's giving clean separation, no cap.
- Service Chaining 🔗: the NSH does service chaining per [RFC7665]. It carries the path identification info needed to actually realize a service path 🛣️. It also lets you monitor and troubleshoot a whole service chain end-to-end using service-specific Operations, Administration, and Maintenance (OAM) messages 🔍. Admins can use the NSH fields (like with a traffic analyzer 📊) to verify the path details of packets moving along a service path, like accounting, making sure chaining is correct, making reports, and more. literally so useful 😭
- The NSH has a way to carry shared metadata between participating entities and Service Functions 🎀. The meaning of that shared metadata is communicated over a control plane, which is outside the scope of this document (not my problem here, bestie 🙈). [SFC-CONTROL-PLANE] has an example in Section 3.3 if you're curious. Metadata can be stuff like classification info for policy enforcement, or network context for forwarding after service delivery 💜. Sharing it means Service Functions can pass their initial and intermediate classification results down to later Service Functions, so nobody has to re-classify the packet, as long as there's enough info enclosed ✨ iconic efficiency.
- The NSH gives all network and service nodes one common, standards-based header for service chaining 👑. Everyone speaks the same language, periodt.
- Transport Encapsulation Agnostic 🦋: the NSH doesn't care how it's transported. It's transport-encapsulation independent, which means it can ride inside a bunch of different encapsulation protocols 🌈. You pick whichever encapsulation fits your deployment, and that encapsulation can form an overlay network. And if an overlay you already have gives you the service path connectivity you need, you're allowed to just use that existing overlay 🫶.
2. Network Service Header 🎀
okay so an NSH gets imposed on the original packet/frame 📦. It holds service path information and, optionally, metadata, and it's added to the packet or frame to build the service plane 🧚. After that, an outer transport encapsulation is imposed on top of the NSH, and that's the part used for network forwarding 🚀.
A Service Classifier adds the NSH 🏷️. The NSH gets 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 made of a 4-byte Base Header, a 4-byte Service Path Header, and optional Context Headers, as you can see 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 🧾: info about the service header and the payload protocol.
- Service Path Header 🛤️: path identification and location within a service path.
- Context Header 🎁: carries metadata (aka context data) along a service path.
2.2. NSH Base Header 💖
here's Figure 3, 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 Headerthe field descriptions, bestie, go like this 📝:
- Version 🔢: this makes sure things stay backward compatible with future NSH spec updates. It MUST be set to 0x0 by the sender in this first revision of the NSH. If a packet that's presumed to carry an NSH header hits an SFF, and the SFF doesn't understand the version in the base header, the packet MUST be discarded and the event SHOULD be logged 🙅♀️. Because lots of existing hardware uses the first nibble after an MPLS label stack for Equal-Cost Multipath (ECMP) decisions, this document reserves version 01b 🚫. This value MUST NOT be used in future versions of the protocol. For more on MPLS forwarding requirements, see [RFC7325] 📚.
- O bit 🛠️: setting this bit means it's an OAM packet (see [RFC6291]). The actual format and processing of SFC OAM packets is outside the scope of this spec (for example, [SFC-OAM-FRAMEWORK] is 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 don't support SFC OAM procedures SHOULD discard packets with the O bit set, but they 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 don't support SFC OAM procedures may be acceptable for a subset of OAM functions, but it can cause unexpected outcomes for others. So it is RECOMMENDED to analyze the impact of forwarding an OAM packet for all OAM functions before enabling this behavior 🧐. The configurable parameter MUST be disabled by default 🔒.
- 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, and 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 the TTL is, after decrement, 0 🛑.
This TTL field is the primary loop-prevention mechanism 👑. It's a robust complement to the Service Index (see Section 2.3), since the TTL gets decremented by each SFF. Handling an incoming 0 TTL allows for better, although not perfect, interoperation with pre-standard implementations that don't support this TTL field 🤝.
- Length 📏: the total length, in 4-byte words, of the NSH including the Base Header, the Service Path Header, and either the Fixed-Length Context Header or the 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, so variable-length metadata is always padded out to a multiple of 4 bytes 📐.
- Unassigned bits 🫧: all the 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. On 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 Base Header and Service Path Header. The MD Type defines the format of the metadata being carried. For IANA stuff, check Section 9.1.3 🏛️.
This document specifies the following four MD Type values:
0x0: reserved. Implementations SHOULD silently discard packets with MD Type 0x0 🗑️.0x1: the header format includes a Fixed-Length Context Header (see Figure 5 below) 📦.0x2: doesn't 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 means there are no Context Headers. The semantics of the Variable-Length Context Header(s) aren't defined in this document. The format of the optional Variable-Length Context Headers is in Section 2.5.1 🧩.0xF: reserved for experimentation and testing, 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 💎.
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 a length greater than 0x2. Devices that don't 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 figure out the original payload offset if you need access to the original packet/frame 🎯. This spec doesn't disallow the MD Type value from changing along an SFP. However, the mechanism needed to allow the MD Type to change along an SFP is outside the scope of this document and would need to be defined for that 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 doesn't alter the inner payload, and the semantics of the inner protocol stay unchanged because of NSH SFC 🫶. Please see the IANA Considerations in Section 9.1.6.
This document defines the following Next Protocol values:
0x1: IPv40x2: IPv60x3: Ethernet0x4: NSH0x5: MPLS0xFE: Experiment 10xFF: Experiment 2
Functionality of hierarchical NSH using a Next Protocol value of 0x4 (NSH) is outside the scope of this specification. Packets with Next Protocol values that aren't supported SHOULD be silently dropped by default, although an implementation MAY provide a configuration parameter to forward them. Also, 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 ✨
Okay so bestie, here's the Service Path Header 💅 It's the part of the NSH that tells the packet where it's going and how far along it is 🦋
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 HeaderSo here's the vibe for each field 🌸
Service Path Identifier (SPI): This one is literally the ID that uniquely identifies a Service Function Path (SFP) 🧚 Participating nodes MUST use it for SFP selection, no exceptions bestie 💖 And the initial Classifier MUST set the right SPI for whatever the classification result is ✨
Service Index (SI): This tells you where you are inside the SFP 📍 The initial Classifier for an SFP SHOULD set the SI to 255, but the control plane MAY configure the starting value instead, like taking the length of the SFP into account 🎀 Service Functions or SFC Proxy nodes MUST decrement the SI by 1 after they do their services, and the new decremented 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 so it can forward along the SFP 🦋 If re-classification happens and it results in a new SPI, the (re-)Classifier is, in effect, the initial Classifier for that resultant SPI 🫶
The SI is used together with the SPI for SFP selection, and for figuring out who the next SFF or SF is in the path 🌈 It's also super valuable for troubleshooting or reporting service paths 🔍 The TTL is the main SFF-based loop prevention thing, but the SI decrement by SF is a limited loop-prevention mechanism too 🔁 NSH packets, as described above, get discarded when an SFF decrements the TTL to 0 💀 Also, an SFF that is not the terminal SFF for an SFP will discard any NSH packet with an SI of 0, because there's no valid next SF info 😭
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 after the Service Path Header, as shown in Figure 5 🎀 If the Fixed-Length Context Header carries no metadata, its value 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 0x1This spec makes zero assumptions about what's inside that 16-byte Context Header when MD Type is 1 🙈 It doesn't describe the structure or meaning of the metadata either, so no spoilers here 🤐
An SFC-aware SF or SFC Proxy needs to get the data structure and semantics FIRST before it can process the data in the mandatory context field 📚 That includes the allocation schema and order, plus what the included data actually means 💜 How an SFC-aware SF or SFC Proxy gets that info is outside the scope of this spec, so that's a different story 🧚
An SF or SFC Proxy that doesn't 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 it cannot process) 🚫 It also 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] give specific examples of how metadata can be allocated 🍓
2.5. NSH MD Type 2 🦋
When the Base Header specifies MD Type 0x2, zero or more Variable-Length Context Headers MAY be added, right after the Service Path Header (see Figure 6) 🌈 So Length = 0x2 means only the Base Header and Service Path Header are present, in that order 💅 The optional Variable-Length Context Headers MUST be an integer number of 4-bytes 🎀 The Base Header Length field MUST be used to find the offset to the original packet or frame, for SFC nodes that need access to that info 🔍
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 0x22.5.1. Optional Variable-Length Metadata ✨
The optional Variable-Length Context Headers look like 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 HeadersMetadata Class (MD Class): This defines the scope of the Type field, giving you a hierarchical namespace 🌳 Section 9.1.4 explains how MD Class values can be allocated to standards bodies, vendors, and others 🏢
Type: This says what kind of metadata is being carried 🎁 The definition of the Type belongs to the MD Class owner 👩💻
Unassigned bit: There's one unassigned bit reserved for future use 🔒 This bit MUST NOT be set, and it MUST be ignored on receipt 🙅♀️
Length: This is the length of the variable-length metadata, in bytes 📏 If the metadata length isn't an integer number of 4-byte words, the sender MUST add pad bytes right after the last metadata byte to round it up to a whole number of 4-byte words 🧸 The receiver MUST round the Length field up to the nearest 4-byte-word boundary so it can locate and process the next field in the packet 🎯 The receiver MUST access only the bytes indicated by the Length field (the 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 means a Context Header without a Variable-Length Metadata field 🫧
This spec doesn't make any assumptions about which Context Headers are mandatory to implement or mandatory to process 🤷♀️ That's deployment specific 🏗️ However, the control plane is allowed to tell SFC-aware SFs about the data structure of the Context Header along with its scoping (see e.g., Section 3.3.3 of [SFC-CONTROL-PLANE]) 📣
If an SFC-aware SF gets a packet that belongs to a given SFP and a mandatory-to-process Context Header is missing, it MUST NOT process the packet, and it 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 tell the SFC-aware SF what order to consume them in 🔢 If no instructions are given and the SFC-aware SF is going to use or modify that specific Context Header, then the SFC-aware SF MUST process these Context Headers in the order they appear in the NSH packet 📦
If multiple instances of the same metadata show up in an NSH packet, but that Context Header's definition doesn't allow for it, the SFC-aware SF MUST process the first instance and ignore the subsequent ones 🙃 The SFC-aware SF MAY log or increase a counter for this event 📊
3. NSH Actions ✨
okay so NSH-aware nodes (that's Service Classifiers, SFFs, SFs, and SFC Proxies) are allowed to tweak the contents of the NSH headers 💅. They have a few NSH-related actions they can take:
- Insert or remove the NSH: 🎀 These happen at the very start and very end of a service path. Packets get classified, and if they need servicing, an NSH gets slapped on. 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. So it's literally the last node touching 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 does a re-classification that changes the service path, it MUST replace the existing NSH with a new NSH. The new one has the Base Header and Service Path Header reflecting the new service path information, and it MUST set the initial SI. The O bit, the TTL field, and unassigned flags MUST be copied transparently from the old NSH to the new NSH. Metadata MAY be preserved in the new NSH 🌸
- Select service path: 🦋 The Service Path Header holds the service path information, and SFFs use it to figure out the correct service path. SFFs MUST use the Service Path Header for selecting the next SF or SFF in the service path. Main character energy for that header, honestly 👑
- Update the NSH: 💖 SFs MUST decrement the service index by one. If an SFF gets a packet with an SPI and SI that don't correspond to a valid next hop in a valid SFP, that packet MUST be dropped by the SFF. No vibes allowed for invalid packets 💀
Classifiers MAY update Context Headers if new or 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 gets 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. The proxy is doing the most for that SF, ngl 🫶
- 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. Iconic chart, let's look 👀
+-----------+-----------------------+-------+---------------+-------+
| | 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 Mapping4. NSH Transport Encapsulation 🧚
Once the NSH is added to a packet, an outer transport encapsulation is used to forward the original packet and its metadata to the start of a service chain. The encapsulation has two jobs:
- Creates a topologically independent services plane. Packets get forwarded to the required services without changing the underlying network topology 🌈
- Transit network nodes simply forward the encapsulated packets without modification. Chill nodes, no touching 🫶
The service header doesn't depend on the transport encapsulation being 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 get "added" to the encapsulated packet or frame. This extra info makes the packet bigger 📦
Within a managed administrative domain, an operator can make sure the underlay MTU is big enough to carry SFC traffic without needing fragmentation. Since the intended scope of the NSH is inside a single provider's operational domain, that approach is enough 💅
However, although it's explicitly outside the scope of this specification, there might be cases where the underlay MTU isn't large enough to carry the NSH traffic. Since the NSH doesn't provide fragmentation support at the service plane, the transport encapsulation protocol ought to provide the required fragmentation handling. For instance, Section 9 of [RTG-ENCAP] gives example approaches and guidance for those scenarios 🎀
When the transport encapsulation protocol supports fragmentation, and fragmentation procedures need to be used, that fragmentation is part of the transport encapsulation logic. If, as 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. 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 doesn't support fragmentation procedures, an error message SHOULD be logged when dropping a packet that's too big. Lastly, NSH-specific fragmentation and reassembly methods may be defined as well, but those are outside the scope of this document and are subject for future work ✨
6. Service Path Forwarding with NSH 🦋
6.1. SFFs and Overlay Selection ✨
okay so, the NSH carries two things: a Service Path Identifier (SPI) and a Service Index (SI). the SPI is, as the name says, just an identifier 🆔. you can't forward packets with the SPI alone. it sits between the service path/topology and the network transport encapsulation as a layer of indirection, and there's no requirement or expectation that an SPI is tied to a fixed network path. it's giving flexibility 💅
the SI tells you where you are inside a service path 📍. the SPI and SI together identify a logical SF and its place in the service plane, and that pair is what gets used to pick the right network locator(s) for overlay forwarding. the logical SF can be one SF or a set of SFs that are equivalent to each other. in that second case, the SFF handles load distribution across the group whenever it's needed 🔄
SI also helps catch broken service paths 🚨. an SI value of zero means forwarding is incorrect, and the packet must be discarded.
this SPI-to-overlay indirection is what makes a true service plane 🦋. the SFF/SF topology gets built without touching the network topology. even better, service-plane-only participants (most SFs, basically) don't have to be part of the network overlay topology or its infrastructure, like the control plane, routing tables, and so on. SFs need to be able to send a packet back to an appropriate SFF (one that has the needed NSH information) once service processing is done 🔙. that return can go over the overlay or the underlay, and in some cases the SF needs some extra configuration for it. like we said before, an existing overlay topology can be reused as long as it gives the connectivity that's needed 🫶
the SPI-to-transport-encapsulation mapping happens on an SFF. as mentioned above, the first SFF in the path gets an NSH-encapsulated packet from the Classifier 🎀. the SFF checks the SPI/SI values to work out which overlay transport encapsulation protocol to use (several can be used in the same network) and the next hop for the required SF. Table 1 shows an example of a single next-hop SPI/SI-to-network overlay locator mapping 🌸
+------+------+---------------------+-------------------------+
| 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 Examplethere's even more indirection possible 🌀. resolving the network locator for the required SF can happen locally on an SFF, instead of being the job of the SFC control plane. see Tables 2 and 3 for that 👀
please note: VXLAN-gpe and GRE in the table above 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 +------+-------------------+-------------------------+
| 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 Examplesince the SPI represents the service path, a lookup can return more than one possible next hop for a given SF within that path. basically you get a set of weighted paths (equally weighted or not) to choose from, for load distribution, redundancy, or policy 🎯. Table 4 shows that. the metric in Table 4 is just an example to help illustrate weighting SFs. in a real network, the metric can go from a simple preference (kinda like a routing next hop) all the way to a real dynamic composite metric based on the state of a Service Function, like load, session state, capacity, and more 📊
+------+-----+--------------+---------+
| 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 Paththe info in Tables 1-4 can come from the control plane, but the exact mechanism is outside the scope of this document 🧚
6.2. Mapping the NSH to Network Topology 🗺️
as described above, mapping the SPI to network topology can give a single path, or something more complicated 🌈. also, the SPI-to-overlay mapping happens independently at each SFF, so any combination of topology selection is possible. there is no requirement to create a new overlay topology if a suitable one already exists. NSH packets can use any overlay, new or existing, as long as the required connectivity is satisfied ✨
here are some mapping examples for a topology:
- Next SF is located at SFFb with locator
2001:db8::1 - Next SF is located at SFFc with multiple network locators for load-distribution purposes
- Next SF is located at SFFd with two paths from SFFc, one for redundancy
SFFa mapping: SPI=10 --> VXLAN-gpe, dst-ip: 2001:db8::1
SFFb mapping: SPI=10 --> VXLAN-gpe, dst_ip:203.0.113.1,
203.0.113.2, 203.0.113.3, equal cost
SFFc mapping: SPI=10 --> VXLAN-gpe, dst_ip:192.0.2.10 cost=10,
203.0.113.10, cost=20in the examples above, each SFF makes its own independent decision about the network overlay path and the policy for that path 🧠. put another way, there's no a priori mandate about how packets get forwarded through the network. only the order of services that must be traversed is defined 🛣️
the network operator still gets to engineer the network paths however they need. for example, the overlay path between SFFs can use traffic engineering, QoS marking, or ECMP, without needing complex configuration or network protocol support extended to the service path explicitly 🔧. so the network keeps working as expected and evolves as needed, and so does the service plane 💖
6.3. Service Plane Visibility 👀
the SPI and SI are super important for seeing the service topology 🔍. an operator can tell what service path a packet is "on," and where it is on that path, just by looking at the NSH info (packet capture, IP Flow Information Export (IPFIX), and so on). that info can be used for service scheduling and placement decisions, troubleshooting, and compliance verification 📋
6.4. Service Graphs 🕸️
a single realized SFP is one specific sequence of Service Functions, but the service a user sees can actually be a collection of SFPs, connected by Classifiers (in-service path, non-initial re-classification) 🧩. these internal re-Classifiers look at the packet at relevant points in the network. if needed, the SPI and SI get updated to reflect the "result" of the classification. whether that update is a rewrite or the imposition of a new NSH with new values is implementation specific 🤷♀️. these Classifiers can also modify the metadata associated with the packet, of course 💜
Section 2.1 of [RFC7665] describes Service Graphs in detail 📚
7. Policy Enforcement with NSH 🛡️
7.1. NSH Metadata and Policy Enforcement ✨
okay so, like we talked about in Section 2, NSH lets you carry metadata along a service path 🧚 and this metadata can come from a few different places. The common ones are:
- Network nodes/devices: Network nodes can hand over network-centric info, like the VPN Routing and Forwarding (VRF) or tenant. Service Functions can use it, or it can be passed back to another network node after the service path egress 🌸
- External (to the network) systems: Things like orchestration systems usually know stuff that's super useful for Service Function policy decisions, and honestly the network nodes usually can't figure it out on their own 💅 For example, a cloud orchestration platform placing workloads "knows" what application is being instantiated and can tell every NSH node about it through metadata in the Context Header(s). iykyk 🫶
- Service Functions: A Classifier that lives right next to Service Functions often does really detailed and valuable classification 🔥
Regardless of where it comes from, the metadata is basically the "result" of classification 💜 The granularity can vary though. Like, a network switch acting as a Classifier might only be able to classify based on a 2-tuple, or a 5-tuple, while a Service Function might be able to look at application info 👀 No matter how granular it gets, the classification info can still be represented in the NSH ✨
Once the data is added to the NSH, it rides along the service path 🦋 NSH-aware SFs get the metadata and can use it for local decisions and policy enforcement. Figures 9 and 10 show the relationship between metadata and policy, and it's giving clear vibes 💖
+-------+ +-------+ +-------+
| 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 PolicyIn both of these examples, the Service Functions make their policy calls based on the result of the initial classification 🎀 The SFs didn't have to reclassify anything. They just relied on the antecedent classification for local policy enforcement. Efficient and iconic 👑
Now, depending on what's in the metadata, data privacy impact needs to be considered 🙈 For example, if the metadata carries tenant information, that info may need to be authenticated and/or encrypted between the originator and the intended recipients (which may include only the intended SFs). One approach to an optional capability for this is explored in [NSH-ENCRYPT]. The NSH itself does not provide privacy functions. It leans on the transport encapsulation/overlay instead 🧚 An operator can pick the right set of transport encapsulation protocols so that confidentiality (and other security) considerations are met. Metadata privacy and security considerations are handled by the documents that define the metadata format, so that's where to look 📚
7.2. Updating/Augmenting Metadata ✨
Post-initial metadata imposition (usually done during the initial service path determination), the metadata can be augmented or updated 🌈
- Metadata Augmentation: Information can be added to the NSH's existing metadata, as shown in Figure 11 💖 For example, if the initial classification returns tenant info, a secondary classification (maybe running alongside deep packet inspection (DPI) or server load balancing (SLB)) can augment the tenant classification with application info and impose that new info in the NSH metadata. The tenant classification is still valid and present. It just got some extra details added on top 🍓
- Metadata Update: Subsequent Classifiers can update the initial classification if it turns out to be incorrect or not descriptive enough 😭 For example, the initial Classifier adds metadata that labels the traffic as "Internet", but a security Service Function figures out the traffic is actually "attack" 💀 Figure 12 shows an example of updating metadata.
+-----+ +-----+ +-----+
| 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 Update7.3. Service Path Identifier and Metadata ✨
Metadata can influence service path selection, because the Service Path Identifier values can represent the result of classification 🦋 A given SPI can be defined based on classification results (including metadata classification). Imposing the SPI and SI puts the packet on the newly specified SFP, at the position indicated by the imposed SPI and SI. Cute and clean 🎀
This relationship lets you build a dynamic service plane based on complex classification, without needing every node to be capable of that classification or tying it to the network topology 💅 This gives you Service Graph functionality, as described in Section 6.4. Figure 13 shows what this looks like in action 👑
+-----+ +-----+ +-----+
| 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 MetadataSpecific 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 thing to know is that NSH is not an end-to-end protocol. Unlike 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 egress from the SFC domain. So, just like any other network-centric protocols (e.g., IP Tunneling, Traffic Engineering, MPLS, or Provider-Provisioned Virtual Private Networks), there's an underlying trust in the network devices responsible for imposing, removing, and acting on NSH information. Trust is the whole vibe here 🫶
⚠️ Heads up, bestie: NSH isn't end-to-end, so the whole thing runs on trusting the network devices that touch it. Treat that trust seriously. 💀
The following sections dig into an analysis and lay out a set of requirements and recommendations in those two areas 💜
8.1. NSH Security Considerations from Operators' Environments 🔐
Trusted Devices
okay bestie, so first things first: every Classifier, SFF, and SF (we're calling them "SFC devices" from here on 💅) inside an operator's environment is assumed to have been selected, vetted, and actively maintained. That means the operator trusts them! This is totally different from the "zero-trust model" people love to talk about, where devices are treated as untrusted by default 🙈. Operators SHOULD regularly monitor (i.e., continuously audit) these devices to help ensure compliant behavior ✨. Because of that trust, NSH operations inherit it too: SFC devices are not, themselves, considered to be attack vectors. ngl this makes total sense, since trusting your own gear is literally the foundation of an operator's whole posture. The network only works if they're trustworthy 🫶.
If these devices are not trusted and are actually compromised, almost the entire standards-based IP and MPLS protocol suite becomes vulnerable, so the operation of the entire network is compromised 😭. Monitoring-based ways to catch a compromise do exist (continuous monitoring, audit, and log review), but they may not be enough to contain the damage from 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
Per [RFC7665], NSH is designed for use within a single administrative domain 🏰. This scoping gives us 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 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 that 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 🛑.
Depending on 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 never allowed to leave the domain), or by examining the carried protocol within 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, so attackers can't send in NSH packets with service path identification and metadata of their own choosing 🕵️♀️. The same filters described above, both for 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. Bye bye, uninvited NSH 👋💀.
ii) Mitigation of external threats
As per the trusted SFC device points raised above, since NSH is scoped within an operator's domain, that operator can ensure the environment, and its transitive properties, comply with the 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 looks at each role and element through the lens of threats in the areas of integrity and confidentiality. Just like with routing, the distributed computation model assumes a distributed trust model 🌐.
An important consideration is that NSH contains mandatory-to-mute fields, and the SFC architecture also 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 🔑😵💫.
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 is 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 🎀:
- SFF/SF NSH verification
Although, strictly speaking, not integrity protection, some of the techniques mentioned above, such as checking that 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 🙌.
- 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 🔐.
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 to carry NSH. IPsec can be used either alone or in conjunction with other transport encapsulation protocols, which in turn encapsulate 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 🌍🔒.
- 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 also 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 ✅.
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), which significantly mitigates the risk of a privacy violation. In particular, subscriber-identifying information should be handled carefully and, in general, SHOULD be obfuscated 🫣.
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 ✨
okay so the NSH Base Header has five unassigned bits (U bits) and one assigned bit (O bit) 🎀 new bits get handed out through a Standards Action [RFC8126], so no free-for-all, bestie 💅
Bit 2 - O (OAM) bit Bit 3 - Unassigned Bits 16-19 - Unassigned
Bit 2 is the O (OAM) bit 🦋 and bit 3 plus bits 16-19 are still unassigned 🌸
9.1.2. NSH Version 🌈
IANA set up the "NSH Version" registry for us 💖 new values get 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 Versionso Version 00b is the protocol as defined by RFC 8300 👑 Version 01b is reserved 🧚 and the last two are still up for grabs 💀
9.1.3. NSH MD Types 💜
IANA set up the "NSH MD Types" registry, and it holds 4-bit values 🍓 the MD Type values 0x0, 0x1, 0x2, and 0xF are specified in this document (see Table 6) ✨ new entries are assigned through 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 Values9.1.4. NSH MD Class 🎀
IANA set up the "NSH MD Class" registry, which holds 16-bit values 🦋 new allocations follow these policies:
0x0000 to 0x01ff: IETF Review0x0200 to 0xfff5: Expert Review
IANA assigned the values like this 👑
+------------------+------------------------+------------+
| 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 Classa registry for Types of the MD Class 0x0000 is defined in Section 9.1.5 🌸
Designated Experts reviewing new requests from the "Expert Review" range should mainly think about whether a brand-new MD class is needed, versus just adding MD Types to an existing class 🧚 they should also encourage an associated, publicly visible registry of MD Types, though IANA doesn't have to maintain that one 💅
When the Expert checks an allocation request, they should verify that the plan covers privacy and security issues for the MD Types being allocated in this class 🔥 those plans should consider, when appropriate, alternatives like indirection, encryption, and limited-deployment scenarios 💖 anything you can't directly derive from looking at 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 inside the IETF Base NSH MD Class (MD Class set to 0x0000, see Section 9.1.4) are owned by the IETF ✨ this document has IANA create a registry for them 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 when the registry gets created 🍓
9.1.6. NSH Next Protocol 💜
IANA set up the "NSH Next Protocol" registry, which holds 8-bit values 🦋 Next Protocol values 0, 1, 2, 3, 4, and 5 are defined in this document (see Table 8) ✨ new values get 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 ValuesExpert Review requests MUST include a single codepoint per request 🔥 Designated Experts evaluating new requests from this registry should think about how scarce codepoints are in an 8-bit value, and check both for duplicates and whether documentation is available 🧚 if the actual assignment of the Next Protocol field reaches half the range (so 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 💖
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 📚
Okay, bestie, this is the "further reading" pile, the stuff that gives the protocol its backstory. 🧚
[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. 🔐
[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>.
[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. 💅
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. 🦋
- Jim Guichard, Cisco Systems, Inc.
- Surendra Kumar, Cisco Systems, Inc.
- Michael Smith, Cisco Systems, Inc.
- Wim Henderickx, Alcatel-Lucent
- Tom Nadeau, Brocade
- Puneet Agarwal
- Rajeev Manur, Broadcom
- Abhishek Chauhan, Citrix
- Joel Halpern, Ericsson
- Sumandra Majee, F5
- David Melman, Marvell
- Pankaj Garg, Microsoft
- Brad McConnell, Rackspace
- Chris Wright, Red Hat, Inc.
- Kevin Glavin, Riverbed
- Hong (Cathy) Zhang, Huawei US R&D
- Louis Fourie, Huawei US R&D
- Ron Parker, Affirmed Networks
- Myo Zarny, Goldman Sachs
- Andrew Dolganow, Alcatel-Lucent
- Rex Fernando, Cisco Systems, Inc.
- Praveen Muley, Alcatel-Lucent
- Navindra Yadav, Cisco Systems, Inc.
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
📦 where this page comes from
- ietf: rfc8300 2018-01
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms