SRv6 Path Verification

Introduction SRv6 is being rapidly deployed and is currently primarily used in trusted-domain backbone networks. However, we have also observed that SRv6 is beginning to extend toward end-user devices, e.g., in SD-WAN deployments. SD-WAN can be deployed in third-party clouds or at customer sites, causing the physical boundary of SRv6 to become blurred. This introduces certain security risks, such as packet injection and path manipulation attacks. Section 6 of identifies these risks as well, including Section 6.2.1 on Modification Attacks and Section 6.2.3 on Packet Insertion. This proposal mitigates these risks by enhancing the HMAC mechanism defined in . describes how to use the HMAC TLV to verify the integrity and authenticity of the SRH during the transmission process, and to prevent the SRH from being maliciously tampered with or forged. Although the HMAC mechanism specified in RFC 8754 can verify the integrity of the entire SID List, if we want to force the SRv6 endpoints the packet must pass through during forwarding, it is necessary to retain some information each time the packet passes through an SRv6 endpoint. This draft proposes an enhancement to HMAC specified by RFC 8754 that provides the capability to enforce the packet's forwarding path to go through all or certain SRv6 endpoints in the SID List. Meanwhile, the SRv6 HMAC mechanism performs end-to-end cryptographic verification of the entire IPv6 header and SRH header. This significantly increases the processing performance and storage overhead of forwarding chips, making it challenging to implement in practical commercial deployments. This document proposes a path verification mechanism for SRv6, which adopts a hop-by-hop cryptographic computation on the destination segment identifier at each node, combined with an end-to-end verification at the last hop. Although the HMAC mechanism specified in RFC 8754 can verify the integrity of the entire SID List, if we want to force the SRv6 endpoints the packet must pass through during forwarding, it is necessary to retain some information each time the packet passes through an SRv6 endpoint. This draft proposes an enhancement to HMAC specified by RFC 8754 that provides the capability to enforce the packet's forwarding path to go through all or certain SRv6 endpoints in the SID List. This approach also significantly reduces the processing overhead associated with hop-by-hop path verification. Three authentication algorithms are defined for the SRv6 path verification: HMAC-SHA256 and AES-CMAC-128. These algorithms provide operators with flexibility to choose the most appropriate mechanism based on their hardware capabilities and security requirements. HMAC-SHA256 and AES-CMAC-128 incorporate a sequence number to prevent replay attacks.

Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Terminology ALG: Authentication algorithm DA: Destination address in IPv6 header CMAC: Cipher-based Message Authentication Code, defined in HMAC: Hash-based Message Authentication Code, defined in MAC: Message Authentication Code SID: Segment Identifier, defined in SRH: Segment Routing Header, defined in SRv6: SR over IPv6, defined in

Process The improved SRv6 path verification mechanism proposed in this document follows the processing flow at the head node, intermediate nodes, and tail nodes as described below:

| P2 | /+----+\ / \ +------+ +-+--+ +-+--+ +------+ | Head |------| P1 |-----| P3 |------| Tail | +---+--+ +----+ +----+ +------+ | +<---- User traffic: SRH (P1, P3, PE2) w/ correct HMAC ]]> Head Node: The head node sends an SRv6 packet. It MUST perform the selected an authentication algorithm and produce an authentication tag. This authentication tag MUST be placed into SRv6 SID Verify TLV within the SRH. The packet, now containing authentication tag, is forwarded to the next SRv6 node. Intermediate Nodes: After an node receives the SRv6 packet and replaces the DA with the next SID, it MUST perform the selected authentication algorithm again with authentication tag and DA from the packet as inputs, and produce a new authentication tag. The packet MUST be updated with the newly generated authentication tag, then forwarded to next SRv6 node. Subsequent intermediate nodes repeat this process. Tail Node: An SDN controller MAY pre-compute the expected authentication tag for each SRv6 tunnel and programme it to tail node. Once the tail node receives the packet carrying the authentication tag, it MUST compare the authentication tag with the expected value. If they do not match, the packet is considered to have violated path verification and MUST be discarded. If they match, it means the packet strictly follows the SID List carried in the packet. In summary, the algorithm works in the following way. Define auth(n) as the path authentication function, which produces a tag on node n and sends it to the next SRv6 endpoint with the packet. The auth(n) SHOULD be calculated in the following manner:

= 1: auth(n) = ALG(k(n), auth(n-1), x) ]]> Suppose the SRv6 path starts from head to tail, the path verification information would be computed incrementally on each node. In this way, the intermediate nodes specified in the SID list will not be allowed to be skipped since every hop will have a fingerprint in the auth(n).

Authentication Algorithms This section defines three authentication algorithms for SRv6 path verification. The AlgoID field in the SRv6 SID Verify TLV identifies which algorithm is used. Several MAC algorithms are selected, including HMAC and CMAC. HMAC-SHA256 provides strong cryptographic integrity protection using the SHA-256 hash function. It is RECOMMENDED for deployments where hardware-accelerated SHA-256 is available. Note, it requires two 64-bytes blocks of HMAC processing. AES-CMAC-128 provides efficient message authentication using the AES block cipher. It is RECOMMENDED for deployments with AES-NI hardware acceleration or dedicated crypto engines. Note, AES-CMAC requires four AES encryptions on the 16-bytes key, authentication tag, DA and SN. Computation on node n:

Where x includes: - ALG is the MAC algorithm, CMAC or HMAC - key(n) is the pre-shared key for node n - DA is the 16-byte IPv6 Destination Address on node n - SN is the sequence number in the packet - "||" denotes concatenation Algorithm Name Auth Tag Len Key Len SN Len HMAC-SHA-256 16/32 bytes 32 bytes 0 ~ 128 bits AES-CMAC-128 16 bytes 16 bytes 0 ~ 128 bits

Sequence Number Handling: The sequence number SHOULD be present to prevent replay attacks. The head node generates a unique sequence number for each packet flow. The tail node maintains a sliding window of recently seen sequence numbers and rejects packets with duplicate or out-of-window sequence numbers.

Algorithm Selection Guidelines Implementations SHOULD select algorithms based on the following deployment characteristics: Deployment Scenario Recommended Algorithm Rationale Hardware with SHA-256 acceleration HMAC-SHA256 Strong security, widely supported in hardware Hardware with AES-NI or dedicated AES crypto engines AES-CMAC-128 Efficient in hardware, low power consumption

Extensions

SRv6 SID Verify TLV A new SRv6 SID Verify TLV is requested from "Segment Routing Header TLVs" in this document.

Operational Consideration Operators SHOULD configure a single algorithm for an SRv6 domain to ensure interoperability. Mixed-algorithm paths are NOT RECOMMENDED and may lead to verification failures. All nodes along the SRv6 path MUST support the path verification. The algorithm selection SHOULD be consistent with the hardware capabilities of all nodes along the path. Sequence number is RECOMMENDED as the default if it is available for the implementation. Deployments requiring strict path verification SHOULD configure nodes to drop packets with missing or invalid SRv6 SID Verify TLVs.

Backward Compatibility If a path contains any node that does not support the TLV, path verification MUST NOT be enabled for that path. Nodes that do not support the SRv6 SID Verify TLV MUST ignore it and process the packet normally, as per Section 2.1. This preserves backward compatibility but provides no path verification. Nodes that support the SRv6 SID Verify TLV but do not recognize a specific AlgoID value MUST treat the packet as having failed verification and SHOULD discard it.

Security Considerations The security strength of the path verification mechanism depends on the selected algorithm and key management practices. HMAC-SHA256 provides 256-bit security against forgery. AES-CMAC-128 provides 128-bit security. Replay attack prevention relies on proper sequence number management. Implementations MUST ensure sequence number uniqueness and detect replayed packets. Key compromise at any intermediate node allows that node to forge valid authentication tags for paths passing through it. This is an inherent limitation of symmetric-key designs. For high-security deployments, keys SHOULD be rotated frequently and distributed via secure channels.

Key Management Considerations Keys SHOULD be rotated periodically. The key lifetime is a local policy decision. Key distribution is outside the scope of this document and MAY use mechanisms such as NETCONF/YANG, BGP-SR Policy. All nodes on a given SRv6 path MUST be configured with the same algorithm (AlgoID) to ensure interoperability.

Replay Attack Prevention The head node generates a monotonically increasing sequence number for each packet within a flow. The sequence number space MUST be large enough to prevent wraparound during the key lifetime. The tail node maintains a replay window and rejects packets with duplicate sequence numbers within the window. The sequence number verification failures SHOULD trigger logging and MAY trigger rate-limited alerts to the management plane.

IANA Considerations

SRv6 SID Verify TLV A new SRv6 SID Verify TLV is requested from "Segment Routing Header TLVs". Value Description Reference TBD SRv6 SID Verify TLV This document

SRv6 SID Verify Algorithm Registry IANA is requested to create a new registry "SRv6 SID Verify Algorithms" under the "Segment Routing" registry group. Initial allocations: Value Algorithm Name Reference TBD HMAC-SHA256 This document TBD AES-CMAC-128 This document TBD Unassigned