The following subsections describe the processing rules for integrity-protected NSH and, optionally, encrypted Context Headers.
This document adheres to the recommendations in Section 8.1
of RFC 8300
for handling the Context Headers at both ingress and egress SFC boundary nodes (i.e., to strip the entire NSH, including Context Headers).
Failures of a Classifier to inject the Context Headers defined in this document SHOULD
be logged locally while a notification alarm MAY
be sent to an SFC control element. Failures of an NSH-aware node to validate the integrity of the NSH data MUST
cause that packet to be discarded while a notification alarm MAY
be sent to an SFC control element. The details of sending notification alarms (i.e., the parameters that affect the transmission of the notification alarms depending on the information in the Context Header such as frequency, thresholds, and content in the alarm) SHOULD
NSH-aware SFs and SFC proxies MAY
be instructed to strip some encrypted Context Headers from the packet or to pass the data to the next SF in the service function chain after processing the content of the Context Headers. If no instruction is provided, the default behavior for intermediary NSH-aware nodes is to maintain such Context Headers so that the information can be passed to the next NSH-aware hops. NSH-aware SFs and SFC proxies MUST
reapply the integrity protection if any modification is made to the Context Headers (e.g., strip a Context Header, update the content of an existing Context Header, insert a new Context Header).
An NSH-aware SF or SFC Proxy that is not allowed to decrypt any Context Headers MUST NOT
be given access to the ENC_KEY.
Otherwise, an NSH-aware SF or SFC Proxy that receives encrypted Context Headers, for which it is not allowed to consume a specific Context Header it decrypts (but consumes others), MUST
keep that Context Header unaltered when forwarding the packet upstream.
Only one instance of a "MAC and Encrypted Metadata" Context Header (Section 5
) is allowed in an NSH level. If multiple instances of a "MAC and Encrypted Metadata" Context Header are included in an NSH level, the SFC data plane element MUST
process the first instance and ignore subsequent instances and MAY
log or increase a counter for this event as per Section 2.5.1
of RFC 8300
. If NSH within NSH is used (Section 4.6
), distinct LoAs may be used for each NSH level.
MTU and fragmentation considerations are discussed in Section 8
After performing any Context Header encryption, the HMAC algorithm discussed in [RFC 4868
] is used to integrity protect the target NSH data. An NSH imposer inserts a "MAC and Encrypted Metadata" Context Header for integrity protection (Section 5
The NSH imposer sets the MAC field to zero and then computes the message integrity for the target NSH data (depending on the integrity-protection scope discussed in Section 5
) using the MAC_KEY and HMAC algorithm. It inserts the computed digest in the MAC field of the "MAC and Encrypted Metadata" Context Header. The length of the MAC is decided by the HMAC algorithm adopted for the particular key identifier.
The Message Authentication Code (T) computation process for the target NSH data with HMAC-SHA-256-128() can be illustrated as follows:
T = HMAC-SHA-256-128(MAC_KEY, target NSH data)
An entity in the SFP that updates the NSH MUST
follow the above behavior to maintain message integrity of the NSH for subsequent validations.
An NSH imposer can encrypt Context Headers carrying sensitive metadata, i.e., encrypted and unencrypted metadata may be carried simultaneously in the same NSH packet (Sections [5
] and [6
In order to prevent pervasive monitoring [RFC 7258
], it is RECOMMENDED
to encrypt all Context Headers. All Context Headers carrying privacy-sensitive metadata MUST
be encrypted; by doing so, privacy-sensitive metadata is not revealed to attackers. Privacy-specific threats are discussed in Section 5.2
of RFC 6973
Using the secret key (ENC_KEY) and authenticated encryption algorithm, the NSH imposer encrypts the Context Headers (as set, for example, in Section 3
) and inserts the resulting payload in the "MAC and Encrypted Metadata" Context Header (Section 5
). The additional authenticated data input to the AEAD function is a zero-length byte string. The entire Context Header carrying sensitive metadata is encrypted (that is, including the MD Class, Type, Length, and associated metadata of each Context Header).
More details about the exact encryption procedure are provided in Section 2.1
of RFC 5116
. In this case, the associated data (A) input is zero length for AES Galois/Counter Mode (AES-GCM).
An authorized entity in the SFP that updates the content of an encrypted Context Header or needs to add a new encrypted Context Header MUST
also follow the aforementioned behavior.
The Timestamp imposed by an initial Classifier is left untouched along an SFP. However, it can be updated when reclassification occurs (Section 4.8
of RFC 7665
). The same considerations for setting the Timestamp are followed in both initial classification and reclassification (Section 6
The received NSH is accepted by an NSH-aware node if the Timestamp (TS) in the NSH is recent enough to the reception time of the NSH (TSrt). The following formula is used for this check:
-Delta < (TSrt - TS) < +Delta
The Delta interval is a configurable parameter. The default value for the allowed Delta is 2 seconds. Special care should be taken when setting very low Delta values as this may lead to dropping legitimate traffic. If the timestamp is not within the boundaries, then the SFC data plane element receiving such packets MUST
discard the NSH message.
Replay attacks within the Delta window may be detected by an NSH-aware node by recording a unique value derived from the packet, such as a unique value from the MAC field value. Such an NSH-aware node will detect and reject duplicates. If for legitimate service reasons some flows have to be duplicated but still share a portion of an SFP with the original flow, legitimate duplicate packets will be tagged by NSH-aware nodes involved in that segment as replay packets unless sufficient entropy is added to the duplicate packet. How such an entropy is added is implementation specific.
Note: Within the timestamp Delta window, defining a sequence number to protect against replay attacks may be considered. In such a mode, NSH-aware nodes must discard packets with duplicate sequence numbers within the timestamp Delta window. However, in deployments with several instances of the same SF (e.g., cluster or load-balanced SFs), a mechanism to coordinate among those instances to discard duplicate sequence numbers is required. Because the coordination mechanism to comply with this requirement is service specific, this document does not include this protection.
All SFC data plane elements must be synchronized among themselves. These elements may be synchronized to a global reference time.
When an SFC data plane element that conforms to this specification needs to check the validity of the NSH data, it MUST
ensure that a "MAC and Encrypted Metadata" Context Header is included in a received NSH packet. The imposer MUST
silently discard the packet and MUST
log an error at least once per the SPI if at least one of the following is observed:
the "MAC and Encrypted Metadata" Context Header is missing,
the enclosed key identifier is unknown or invalid (e.g., the corresponding key expired), or
the timestamp is invalid (Section 7.4).
If the timestamp check is successfully passed, the SFC data plane element proceeds with NSH data integrity validation. After storing the value of the MAC field in the "MAC and Encrypted Metadata" Context Header, the SFC data plane element fills the MAC field with zeros. Then, the SFC data plane element generates the message integrity for the target NSH data (depending on the integrity-protection scope discussed in Section 5
) using the MAC_KEY and HMAC algorithm. If the value of the newly generated digest is identical to the stored one, the SFC data plane element is certain that the NSH data has not been tampered with and validation is therefore successful. Otherwise, the NSH packet MUST
be discarded. The comparison of the computed HMAC value to the stored value MUST
be done in a constant-time manner to thwart timing attacks.
If entitled to consume a supplied encrypted Context Header, an NSH-aware SF or SFC Proxy decrypts metadata using (K) and a decryption algorithm for the key identifier in the NSH.
The authenticated encryption algorithm has only a single output, either a plaintext or a special symbol (FAIL) that indicates that the inputs are not authentic (Section 2.2
of RFC 5116