Subscriber and Performance Policy Identifier Context Headers in the Network Service Header (NSH)
Extracted elements (27)
Identifiers in both Context Headers are treated as opaque values with no assumed internal structure; the semantics and validation are policies local to each SFC-enabled domain. This document focuses solely on the data plane behavior and leaves control plane considerations out of scope.
Subscriber and Performance Policy identifiers are carried in distinct Context Headers rather than multiplexed in one header because multiple policies may be associated with a single subscriber within a Service Function Chain, and multiplexing would require additional internal structure to distinguish identifier types.
The Performance Policy Identifier Context Header enables distributed enforcement of per-service QoS policies (e.g., ULL, UHR) by allowing SFFs and SFs to dynamically select SF instances and SFPs based on performance criteria, which is not possible when path computation is fully centralized with a strict SFP presented to SFFs.
The Subscriber Identifier Context Header was introduced to address the case where SFs located after a NAT function in mobile networks (e.g., past a 4G PGW or 5G UPF) cannot identify subscribers via internal IP addresses; passing an opaque subscriber ID in the NSH resolves this without requiring NAT traversal logic in SFs.
The default behavior of intermediary NSH-aware nodes is to preserve both Subscriber Identifier and Performance Policy Identifier Context Headers and pass them to next-hop NSH-aware nodes, but local policy may override this to strip a Context Header after processing.
The type and format of identifiers injected in a Subscriber Identifier Context Header must be consistently configured across all nodes authorized to inject and consume such headers within the SFC-enabled domain to prevent interoperability issues.
Events logged locally by NSH-aware nodes with notification alerts sent to a Control Element SHOULD be rate limited to prevent notification storms.
It is RECOMMENDED for network operators to increase the underlying MTU so that NSH traffic is forwarded within an SFC-enabled domain without fragmentation, per Section 5 of RFC 8300.
Multiple Performance Policy Identifier Context Headers MAY be present in the NSH, each carrying an opaque value for a distinct policy. When conflicting policies are detected, the default behavior is to discard the packet and send a notification alarm to a Control Element.
NSH-aware SFs MUST ignore Context Headers carrying unknown subscriber identifiers. If validation checks fail on a Subscriber Identifier Context Header, an NSH-aware SF MUST ignore that Context Header.
Subscriber identifier values SHOULD be obfuscated, in alignment with Section 8.2.2 of RFC 8300, because no cryptographic protection is provided for their internal structure and any structure will be visible on the wire if no secure transport encapsulation is used.
The classifier and NSH-aware SFs MAY inject a Subscriber Identifier Context Header as a function of local policy, which should indicate the SFP(s) for which the header will be added.
The Metadata Class field in both Context Headers MUST be set to 0x0, as defined in RFC 8300.
The use of indirect and non-persistent identification is RECOMMENDED because persistent identifiers facilitate tracking over time.
When multiple Subscriber Identifier Context Headers are present and an SF is instructed to strip them, that SF MUST remove all Subscriber Identifier Context Headers, not just one.
Subscriber identifiers may be generated from information already in original packets (e.g., internal IP addresses) or collected from other domain sources (e.g., line identifiers). Because persistent identifiers facilitate tracking, non-persistent and indirect identifiers are RECOMMENDED, and identifier rotation can improve unlinkability per RFC 6973.
The scope for privacy breaches and user tracking is by design limited to within the SFC-enabled domain where the NSH is used, as the NSH is stripped at egress SFC boundary nodes and subscriber-related information is not revealed to outside parties.
Multiple Subscriber Identifier Context Headers MAY be present in the NSH simultaneously, each carrying a distinct opaque value but all pointing to the same subscriber. This supports environments where different SFs use different identifier types (e.g., IP address vs. non-IP identifiers).
The Performance Policy Identifier Context Header conveys an opaque value pointing to a specific performance policy (e.g., ultra-low latency or ultra-high reliability) to be enforced, enabling downstream NSH-aware nodes to select suitable SFC paths and SF instances.
The Subscriber Identifier Context Header carries an opaque local identifier assigned to a subscriber by a network operator. It is used by SFs to enforce per-subscriber policies such as resource quota, customized filtering, and accounting.
IANA assigned two values in the 'NSH IETF-Assigned Optional Variable-Length Metadata Types' subregistry under the 0x0000 IETF Base NSH MD Class: 0x00 for Subscriber Identifier and 0x01 for Performance Policy Identifier, both referencing RFC 8979.
A misbehaving node within the SFC-enabled domain may alter the content of Subscriber Identifier and Performance Policy Identifier Context Headers, potentially causing service disruption. NSH integrity mechanisms (referenced as NSH-INTEGRITY draft) should be used when enhanced protection is required.
If no secure transport encapsulation is used, trivial subscriber identifier structures combined with specific SFs in a chain may reveal sensitive user information to every on-path device and operational staff. SFs SHOULD NOT log the content of these Context Headers unless they actually use that content for their operation.
The NSH natively prevents leaking subscriber-related information outside an SFC-enabled domain because the last SFF of an SFP systematically removes the NSH (including the Context Headers defined in this document) before forwarding a packet that exits the SFP.
The presence of multiple Subscriber Identifier Context Headers in the same NSH allows a misbehaving node to bind these identifiers to the same subscriber for tracking. Use of non-persistent randomized identifiers and removal of headers by the last SF that uses them mitigates this risk.
The Performance Policy Identifier Context Header shares the same 32-bit fixed header layout as the Subscriber Identifier header (Metadata Class: 16 bits, Type: 8 bits, U bit: 1 bit, Length: 7 bits) followed by a variable-length opaque Performance Policy Identifier field. Metadata Class MUST be 0x0, Type is 0x01.
The Subscriber Identifier Context Header is a variable-length NSH Context Header with a 32-bit fixed header (Metadata Class: 16 bits, Type: 8 bits, U bit: 1 bit, Length: 7 bits) followed by a variable-length opaque Subscriber Identifier field. Metadata Class MUST be 0x0, Type is 0x00.