Integrity Protection for the Network Service Header (NSH) and Encryption of Sensitive Context Headers
Extracted elements (28)
AES_128_CBC_HMAC_SHA_256 was rejected because CBC mode allows plaintext malleability: an attacker who knows the MAC key but not the encryption key can alter ciphertext to produce known arbitrary plaintext blocks. Separate AEAD and MAC protections prevent this attack class.
Both AEAD (for encryption) and HMAC (for integrity) are used rather than AEAD alone, so that NSH-aware SFs can recompute only the MAC (not the ciphertext) after decrementing the Service Index, and so that SFFs can be given MAC_KEY for integrity verification without receiving ENC_KEY.
This specification is not applicable to NSH MD Type 0x01 (fixed-length context header) because its fixed 16-byte size is insufficient to accommodate both the metadata and the message integrity data required by this mechanism. Only MD Type 0x02 (variable-length) is supported.
This specification applies only to NSH MD Type 0x02 (variable-length context headers as defined in Section 2.5 of RFC 8300). It is explicitly not applicable to NSH MD Type 0x01.
All Context Headers carrying privacy-sensitive metadata MUST be encrypted. To prevent pervasive monitoring (RFC 7258), it is RECOMMENDED to encrypt all Context Headers.
An NSH-aware SF or SFC Proxy not authorized to decrypt any Context Headers MUST NOT be given access to the ENC_KEY. If it decrypts Context Headers it is not authorized to consume, it MUST keep those headers unaltered when forwarding.
Classifiers, NSH-aware SFs, and SFC proxies MUST implement the AES_128_GCM authenticated encryption algorithm and SHOULD implement AES_192_GCM and AES_256_GCM. They MUST implement HMAC-SHA-256-128 and SHOULD implement HMAC-SHA-384-192 and HMAC-SHA-512-256. SFFs MAY implement these algorithms.
Failures of an NSH-aware node to validate the integrity of the NSH data MUST cause that packet to be discarded; a notification alarm MAY be sent to an SFC control element. Notification alarm details SHOULD be configurable.
Keying material used at an upper-level SFC domain SHOULD NOT be the same as the keying material used by a lower-level domain when NSH-within-NSH encapsulation is employed.
NSH-aware SFs and SFC proxies MUST reapply integrity protection if any modification is made to the Context Headers (e.g., stripping, updating, or inserting a Context Header).
Only one instance of a 'MAC and Encrypted Metadata' Context Header is allowed per NSH level. If multiple instances are present, the SFC data plane element MUST process the first instance and ignore subsequent instances.
Prior to expiration of the secret key K, all participating NSH-aware nodes SHOULD have the control plane distribute a new key identifier and associated keying material. It is RECOMMENDED that the next key identifier be distributed well prior to the secret key expiration time.
The interaction between SFC data plane elements and a key management system MUST NOT be transmitted unencrypted, as doing so would completely destroy the security benefits of the integrity-protection solution.
The 'MAC and Encrypted Metadata' Context Header, if included, MUST always be the last Context Header in the NSH.
The received NSH is accepted only if the Timestamp (TS) satisfies: -Delta < (TSrt - TS) < +Delta, where the default Delta is 2 seconds. If the timestamp is outside this window, the SFC data plane element MUST discard the NSH message.
When validating NSH data integrity, the comparison of the computed HMAC value to the stored value MUST be done in a constant-time manner to thwart timing attacks.
Context Headers may carry privacy-sensitive information inserted by Classifiers or intermediate SFs that is not visible to communication endpoints. Without encryption, SFFs or unauthorized SFs along the SFP would have access to this sensitive metadata even when hop-by-hop transport security (e.g., IPsec) is in use.
A single secret key K is split into two secondary keys: MAC_KEY (the initial MAC_KEY_LEN octets of K), used with HMAC for integrity protection of NSH data including unencrypted context headers and the inner packet; and ENC_KEY (the final ENC_KEY_LEN octets of K), used as the symmetric AEAD encryption key for Context Headers.
In hierarchical SFC (NSH-within-NSH per RFC 8459), a Lower-NSH is pushed in front of the Upper-NSH by the lower-level domain Classifier. SFC data plane elements of the lower-level domain include the Upper-NSH in the MAC computation, providing integrity protection over the entire nested structure.
MAC#1 Context Header (Type 0x02) provides integrity protection covering the Service Path Header, Context Headers, and the inner packet, but excludes the Base Header (first level of assurance). It does not require sharing MAC_KEY with SFFs and does not require SFFs to recompute the MAC during TTL processing.
MAC#2 Context Header (Type 0x03) provides integrity protection over the entire NSH data including the Base Header (second level of assurance). This requires sharing MAC_KEY with SFFs so they can verify and recompute the MAC when modifying the Base Header (e.g., TTL decrement).
Only Classifiers, NSH-aware SFs, and SFC proxies may encrypt or decrypt Context Headers; SFFs never participate in encryption. Both encrypted and unencrypted Context Headers may coexist in the same NSH packet. The Service Path Header is never encrypted because SFFs require SPI and SI for forwarding decisions.
IANA added two new types to the 'NSH IETF-Assigned Optional Variable-Length Metadata Types' registry (0x0000 IETF Base NSH MD Class): 0x02 ('MAC and Encrypted Metadata #1') and 0x03 ('MAC and Encrypted Metadata #2'), both referencing RFC 9145.
In SFC-enabled domains where on-path attacks, spoofing, replay, and packet replacement are possible: NSH data MUST be integrity protected and replay protected, and privacy-sensitive NSH metadata MUST be encrypted. The solution does not provide data origin authentication.
NTP time synchronization is required for replay attack prevention via timestamps. RFC 8633 describes NTP best current practices and RFC 8915 specifies cryptographic NTP security; both should be considered for SFC deployments.
Under MAC#1 (first level of assurance), an active attacker can modify the Base Header (e.g., decrement TTL to cause the next SFF to discard the packet) since the Base Header is outside the integrity-protection scope. Under MAC#2, SFFs can detect illegitimate modification of the Base Header.
The 'MAC and Encrypted Metadata' Context Header contains: Metadata Class (16 bits), Type (8 bits), U bit, Length (7 bits), Key Id Len (8 bits), Key Identifier (variable), Timestamp (8 bytes), Nonce Length (8 bits), Nonce (variable), and Message Authentication Code with optional Encrypted Context Headers (variable). Padded to a multiple of 4 bytes.
The Timestamp field is 64 bits: a 32-bit Seconds field (integer seconds since Unix epoch 1970-01-01T00:00 UTC) and a 32-bit Fraction field (units of 2^(-32) seconds ≈ 233 picoseconds). The format wraps around every 2^32 seconds (~136 years); the next wraparound occurs in 2106.