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(Segment Routing Header) 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 specificed 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, which 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 specificed 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. And this approach also significantly reduces the processing overhead associated with hop-by-hop path verification.

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.

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 IPv6/SRv6 packet. It encrypts the destination segment identifier (i.e., the SID of the first intermediate node) using a predefined encryption algorithm (e.g., HMAC, CRC, or other generic algorithms) and a pre-shared key, generating verification information 1. This verification information 1 is then inserted into a specified field of the packet (e.g., the Segment Routing Header (SRH) label field, SRH TLV field, path segment field, or IPv6 extension header), In this document, it is assumed that the mechanism is implemented by extending the "SRv6 SID Verify TLV" and incorporating it into the SRH (Segment Routing Header). The packet, now containing verification information 1, is forwarded to the first intermediate node. Intermediate Nodes: The first intermediate node receives the IPv6/SRv6 packet from the head node, which includes verification information 1 and the destination segment identifier of the next hop (i.e., the SID of the second intermediate node). The intermediate node reads verification information 1 and the segment identifier of the next hop from the packet, and then encrypts the verification information 1 and the segment identifier of the next hop using the same predefined encryption algorithm and pre-shared key, respectively. It then sums up verification information 2 through a predefined operation (e.g., weighted summation), generating verification information 2, which will be inserted into the same specified field of the packet, which is then forwarded to the second intermediate node. Subsequent intermediate nodes repeat this process, sequentially propagating the combined results of their own and all preceding nodes' calculations. Tail Node: The tail node receives the packet from the last intermediate node, which carries the combined verification information. It will compare the combined verification information with pre-calculated path verification value. If they do not match, the packet is considered routed by unexpected path and can be discarded. If they match, the packet strictly follows the SID List carried in the packet. In case of a mismatch, tail node can compare these results with its own calculations to identify the specific node where the verification failed, enabling traceability of the verification anomaly. In summary, the algorithm works in the following way. Define ALG_n(x) = ALG(kn, x), kn is the key for node n, and x is the SID in the destination address, and Yn is the path verification information carried by the packet and updated on each hop. Suppose the SRv6 path starts from Node1 and ends on Node4, the path verification information would be computed as below on each node. Node1: Y1 = ALG_1(SID_2); Node2: Y2 = ALG_2(SID_3) + ALG_2(Y1); Node3: Y3 = ALG_3(SID_4) + ALG_3(Y2); Node4: Y4 = ALG_3(SID_4) + ALG_4(y3). Optionally, on last hop node, if the verication failed it can send the packet to the SDN controller. Because Yn and ALG_n(x) is known to SDN controller, it can identify which nodes has been bypassed. In this way, the intermediate nodes specified by in the SID list will not be allowed to be bypassed since every hop will have fingerpint in the Yn.

Extensions

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

IANA Considerations

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

Security Considerations This document should not affect the security of the Internet.