rfc-9263

Network Service Header (NSH) Metadata Type 2 Variable-Length Context Headers

Y. Wei (Editor), U. Elzur, S. Majee, C. Pignataro, D. Eastlake 3rd
date2022-08 streamIETF areartg wgsfc statusPROPOSED STANDARD pages15 canonicalhttps://www.rfc-editor.org/rfc/rfc9263 doi10.17487/RFC9263
Service Function Chaining (SFC) uses the Network Service Header (NSH) (RFC 8300) to steer and provide context metadata (MD) with each packet. Such metadata can be of various types, including MD Type 2, consisting of Variable-Length Context Headers. This document specifies several such Context Headers that can be used within a Service Function Path (SFP).

Extracted elements (29)

design-rationale §5.1

Forwarding Context and Flow ID headers repeat fields already present in the encapsulated packet for convenience; because they duplicate existing data, they introduce no additional security or privacy considerations beyond what the original packet fields already expose.

design-rationale §4.7

The Policy ID defined here is intentionally distinct from the Performance Policy ID in RFC 8979, which has narrowly scoped use; this general Policy ID covers cases like URL filtering and transcoding that are not addressed by RFC 8979.

interoperability-note §4.3

The Ingress Network Node Information Context Header is superfluous when the Service Path Identifier (SPI) in the NSH already identifies or closely constrains the ingress node.

interoperability-note §1

These Context Headers supplement (not replace) the Subscriber Identifier and Performance Policy MD Type 2 Context Headers specified in RFC 8979; implementors should consult both documents for the full set of IETF-defined MD Type 2 headers.

normative-requirement §4.6 MUST

If a Source Group or Destination Group field has no group information specified, it MUST be sent as zero and ignored on receipt.

normative-requirement §5 MUST

If MAC verification of NSH metadata fails (per RFC 9145), the receiver MUST stop processing the Variable-Length Context Headers and notify an operator.

security

normative-requirement §5 MUST

If the NSH includes a MAC and Encrypted Metadata Context Header per RFC 9145, the authentication of the packet MUST be verified before using any data from Variable-Length Context Headers.

security

normative-requirement §4.5 MUST

Reserved bits in Flow ID context fields MUST be sent as zero and ignored on receipt.

normative-requirement §4.1 MUST

Reserved bits in Forwarding Context fields MUST be sent as zero and ignored on receipt.

protocol-element §4

Seven MD Type 2 Context Header types are defined under Metadata Class 0x0000 (IETF Base NSH MD Class): Forwarding Context (0x04), Tenant ID (0x05), Ingress Network Node ID (0x06), Ingress Network Interface (0x07), Flow ID (0x08), Source and/or Destination Groups (0x09), and Policy ID (0x0A).

registry

protocol-element §4.5

The Flow ID Context Type (CT) is a 4-bit field distinguishing IPv6 Flow Label (0x0) from MPLS entropy label (0x1); values 0x2-0xE are unassigned and 0xF is reserved.

mpls, ip

protocol-element §4.1

The Forwarding Context (CT) field is a 4-bit subtype discriminator that determines the encoding of the forwarding context value, with values 0x0-0x4 defined and 0x5-0xE unassigned; 0xF is reserved.

protocol-element §4.7

The Policy ID Context Header is a general-purpose policy reference distinct from the Performance Policy ID in RFC 8979; it allows SFs to identify what treatment policies (URL filtering, transcoding, etc.) to apply to packets.

registry §6.1

IANA assigned seven type values (0x04-0x0A) in the 'NSH IETF-Assigned Optional Variable-Length Metadata Types' registry for the Context Headers defined in this document.

registry

registry §6.3

IANA created a new 'Flow ID Context Types' subregistry under NSH Parameters with 0x0 (IPv6 Flow Label) and 0x1 (MPLS entropy label) assigned, 0x2-0xE unassigned, and 0xF reserved. Registration policy is IETF Review.

registry, mpls, ip

registry §6.2

IANA created a new 'Forwarding Context Types' subregistry under NSH Parameters with values 0x0-0x4 assigned, 0x5-0xE unassigned, and 0xF reserved. Registration policy is IETF Review.

registry

security-consideration §5

A misbehaving node within the SFC-enabled domain may alter Context Header content, leading to service disruption. RFC 9145 specifies integrity protection and encryption for NSH metadata; MAC verification must precede any use of Context Header data.

security

security-consideration §5

Context Headers that are unnecessary or have no effect provide a covert channel for the entity adding them to communicate limited arbitrary information to downstream entities within the SFC domain.

security

security-consideration §5.4

Including both Ingress Network Node Information and Ingress Node Source Interface headers together provides more fine-grained source identification and is a greater threat to privacy than the node information header alone, though the threat is confined to the SFC domain.

security, privacy

security-consideration §5.6

Source and/or Destination Groups header with non-zero values can erode security and privacy within the SFC domain by either distinguishing otherwise indistinguishable flows or grouping flows that could not otherwise be correlated for analysis.

security, privacy

security-consideration §5.2

Tenant ID may reduce security by facilitating traffic analysis and correlation of packets within the SFC-enabled domain, particularly when other identifiers are being randomized.

security, privacy

wire-format §4.5

Flow ID header (Type=0x08, Metadata Class=0x0000, Length=4) uses a 4-bit CT to encode either a 20-bit IPv6 Flow Label (CT=0x0) or a 20-bit MPLS entropy label (CT=0x1). Absence or zero value denotes unlabeled packets.

mpls, ip

wire-format §4.1

Forwarding Context header (Type=0x04, Metadata Class=0x0000) uses a 4-bit Context Type (CT) field to encode VLAN (CT=0x0, 12-bit), QinQ (CT=0x1, 24-bit), MPLS VPN label (CT=0x2, 20-bit), VNI (CT=0x3, 24-bit), or Session ID (CT=0x4, 32-bit). Length is 4 octets for CT 0x0-0x3 and 8 octets for CT=0x4.

mpls

wire-format §4.3

Ingress Network Node ID header (Type=0x06, Metadata Class=0x0000) carries a variable-length opaque Node ID of the classifier node where a packet entered the SFC domain. Node ID may be IPv4 (4 octets), IPv6 (16 octets), MAC (6 octets), or EUI-64 (8 octets).

wire-format §4.4

Ingress Network Source Interface header (Type=0x07, Metadata Class=0x0000) carries a variable-length opaque identifier for the ingress interface of the ingress network node.

wire-format §3

NSH MD Type 2 Variable-Length Context Header format consists of a 2-octet Metadata Class, 1-octet Type, 1 U-bit, 7-bit Length field, followed by variable-length metadata. Defined in RFC 8300 Section 2.5.1 and reused here.

registry

wire-format §4.7

Policy ID header (Type=0x0A, Metadata Class=0x0000) carries a variable-length opaque Policy ID that Service Functions use to look up applicable policies (e.g., URL filter data sets, transcoding policies).

wire-format §4.6

Source and/or Destination Groups header (Type=0x09, Metadata Class=0x0000, Length=8) carries two 32-bit opaque fields: Source Group and Destination Group, used for intent-based logical grouping.

wire-format §4.2

Tenant ID header (Type=0x05, Metadata Class=0x0000) carries a variable-length opaque value representing an orchestration system-generated Tenant ID. Length field indicates the number of octets.