Active Operations, Administration, and Maintenance (OAM) for Service Function Chaining (SFC)
Extracted elements (29)
The MAC#1 Context Header (RFC 9145) is preferred over MAC#2 for SFC active OAM integrity protection because MAC#1 does not require recalculation of the MAC when the NSH Base Header TTL field changes, which happens at every hop during forwarding.
The SFC Active OAM Header was introduced to demultiplex active OAM protocols on SFC without requiring IP/UDP encapsulation. Adding an extra IP/UDP header, especially in IPv6 networks, adds significant overhead compared to the length of typical Active OAM Control Packets such as BFD Control packets.
Fate sharing between active OAM packets and monitored SFC data traffic cannot be guaranteed when reclassification occurs along the SFP or when the load balancing principle is unknown. In such cases, OAM results may only reflect the state of an SFC segment rather than the entire SFC. Operators must consider this limitation.
SFC elements (Classifiers or SFFs) that do not support SFC active OAM will discard the protocol's packets during incremental deployment. The SFC Echo Request/Reply mechanism is defined for NSH encapsulation; applicability to other SFC encapsulations such as MPLS (RFC 8595) is outside scope.
An SFF receiving an SFC Echo Request MUST validate in order: verify authentication if integrity-protected (failing auth triggers Echo Reply with Return Code 3), validate Source ID TLV (malformed TLV causes silent drop with optional logging), check overall packet well-formedness (malformed triggers Return Code 1), report unknown TLVs with Return Code 2, and at the end of the SFP reply with Return Code 5.
An SFF SHOULD NOT accept an SFC Echo Reply unless the message is well-formed, a matching Echo Request is found with equal Sender's Handle values, and the Sequence Number matches an outstanding transmitted Echo Request's Sequence Number.
Each SFF in the SFP MUST send exactly one CVRep per CVReq. For multiple SFs attached to the same SFF as different SFP hops, information about each SF MUST be listed as separate SF Information Sub-TLVs. For load-balanced SFs sharing the same Service Index, all SF Identifiers MUST be listed sequentially within a single sub-TLV.
The Sender's Handle field MUST be filled in by the sender of the Echo Request and returned unchanged by the Echo Reply sender. The sender SHOULD use a pseudorandom number generator to set the Sender's Handle value.
The Sequence Number in an SFC Echo Request MUST be pseudorandomly generated and SHOULD be monotonically increasing during the test session. If a reply is sent, the Echo Reply sender MUST copy the Sequence Number from the received Echo Request.
To identify an SFC active OAM message, the NSH Next Protocol field MUST be set to SFC Active OAM (0x07) and the O bit in the NSH MUST be set per RFC 9451. An erroneous combination where the O bit is clear but Next Protocol is 0x07 MUST be reported with rate-limiting control, and the packet SHOULD be dropped.
When Reply Mode is 'Reply via Specified Path' (4) but no Reply Service Function Path TLV is present, the responding SFF MUST send an Echo Reply with Return Code 6. If the requested SFP cannot be found, it MUST send Return Code 7 and include the original Reply Service Function Path TLV.
When the Reply Mode is set to 'Reply via an IPv4/IPv6 UDP Packet' (2) or its integrity-protected variant (5), and the SFC Echo Request is not encapsulated in IP/UDP, the sender MUST include the Source ID TLV so the responder can determine the destination IP address and UDP port for the Echo Reply.
Return Code values defined: 0=No Error, 1=Malformed Echo Request received, 2=One or more TLVs not understood, 3=Authentication failed, 4=SFC TTL Exceeded, 5=End of the SFP, 6=Reply Service Function Path TLV is missing, 7=Reply SFP was not found, 8=Unverifiable Reply Service Function Path. For all defined return codes the Return Subcode MUST be set to zero.
The Reply Mode field specifies how the Echo Reply should be returned: 1=Do Not Reply, 2=Reply via IPv4/IPv6 UDP Packet, 4=Reply via Specified Path, 5=Reply via IPv4/IPv6 UDP Packet with data integrity protection (using MAC Context Header per RFC 9145), 7=Reply via Specified Path with data integrity protection.
The SFC Consistency Verification Request (CVReq, Echo Type=3) and Consistency Verification Reply (CVRep, Echo Type=4) enable SFP path consistency verification. Every SFF receiving a CVReq MUST collect information about traversed SFs and send a CVRep to the ingress SFF over IP, and MUST forward the CVReq to the next downstream SFF.
IANA assigned Next Protocol value 0x07 ('SFC Active OAM') in the 'NSH Next Protocol' registry within the 'Network Service Header (NSH) Parameters' group.
IANA created the 'Service Function Chaining (SFC) Active OAM' group of registries containing: SFC Active OAM Message Types (0-31 IETF Review, 32-62 FCFS); SFC Echo Request Flags (0-15 Standards Action); SFC Echo Types (0-175 IETF Review, 176-239 FCFS, 240-251 Experimental, 252-254 Private); SFC Echo Reply Modes (same policy as Echo Types); SFC Echo Return Codes (0-191 IETF Review, 192-251 FCFS); SFC Active OAM TLV Types (same as Echo Types); and SF Identifier Types (0-191 IETF Review, 192-251 FCFS).
Implementations MUST provide means to check the source addresses of CVReq messages against an access list before accepting, because the SF Information Sub-TLV discloses SFP topology information and a spoofed CVReq could be used to gather network intelligence.
Integrity protection for SFC active OAM is RECOMMENDED using the MAC#1 Context Header from RFC 9145. Confidentiality can be achieved using IP ESP (RFC 4303). For IPv6 underlay networks, IP AH (RFC 4302) or ESP can also provide integrity protection.
Three attack vectors are identified: (1) DoS via flooding SFC Echo Requests to overload SFC elements—mitigated by RECOMMENDED throttling of messages to the control plane; (2) spoofing/replay of Echo Replies—mitigated by requiring matching Sender's Handle and Sequence Number; (3) unauthorized information gathering via Echo Request/Reply—implementations MUST verify the source of Echo Requests is part of the SFP.
In SFP traceroute mode, the sender begins with NSH TTL=1 and increments by 1 for each subsequent Echo Request. The sender stops transmitting when the received Echo Reply contains Return Code 5 ('End of the SFP'). This discovers the RSP hop-by-hop and localizes defects.
Each SFC Echo Request/Reply TLV uses a 1-octet Type field, 1-octet Reserved field (MUST be zeroed on transmission), 2-octet Length field (length of Value in octets), and a variable-length Value field. Sub-TLVs may be nested within the Value field of an outer TLV.
The Errored TLVs TLV (Type=2) encapsulates unrecognized or malformed TLVs as sub-TLVs. Each sub-TLV contains: Sub-TLV Type (copy of the errored TLV's first octet), Reserved (1-octet, MUST be zeroed), Sub-TLV Length (copy of the errored TLV's Length field), and Sub-TLV Value (data following the Length field in the errored TLV).
The Reply Service Function Path TLV (Type=3) carries: Reply SFP (1-octet, value 3), Reserved (1-octet), Length (2-octet, MUST equal 4), Reply Service Function Path Identifier (3-octet SFP identifier), and Service Index (1-octet). The TLV specifies the return SFP over which the Echo Reply should be transmitted.
The SF Information Sub-TLV (Type=5) contains: SF Sub-TLV (1-octet, value 5), Reserved (1-octet), Length (2-octet), Service Index (1-octet indicating SF position), SF Type (2-octet per RFC 9015), SF ID Type (1-octet per IANA registry), and variable-length SF Identifier (e.g., 32 bits for IPv4).
The SFC Active OAM Header consists of a 4-bit version field (V, currently 0), a 6-bit Msg Type field identifying the OAM protocol, a 6-bit Reserved field (MUST be zeroed on transmission), and a 2-octet Length field indicating the length of the SFC Active OAM Control Packet in octets.
The SFC Echo Request/Reply message contains: Echo Request Flags (2-octet bit vector, MUST be zeroed), Reserved (2-octet, MUST be zeroed), Echo Type (1-octet), Reply Mode (1-octet), Return Code (1-octet), Return Subcode (1-octet), Sender's Handle (4-octet), Sequence Number (4-octet), followed by variable-length TLVs. If no TLVs are included, the Length in the SFC Active OAM Header MUST be 16 octets.
The SFF Information Record TLV (Type=4) contains: SFF Record TLV (1-octet, value 4), Reserved (1-octet), Length (2-octet), Service Path Identifier (3-octet SPI), Reserved (1-octet), and one or more SF Information Sub-TLVs. It reports all SFs available from an SFF instance for the specified SFP.
The Source ID TLV (Type=1) carries: Source ID (1-octet, value 1), Reserved1 (1-octet), Length (2-octet, value must be 8 for IPv4 or 20 for IPv6; any other value renders it malformed), Port Number (2-octet UDP port), Reserved2 (2-octet), and IP Address (4 or 16 octets). The Port Number and IP Address MUST be used as the destination UDP port and IP address for the Echo Reply.