SRv6 Path Verification

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 29 December 2026.¶

Copyright Notice

Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. 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 [I-D.draft-ietf-spring-srv6-security] 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 [RFC8754].¶

[RFC8754] 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.¶

2. 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:¶

Attack traffic: SRH (P1, P3, PE2) w/ HMAC captured from user traffic
                  |
                  |     +----+
                  +---->| 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:¶

if n == 0: auth(0) = 0
if n >= 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).¶

auth(n) = ALG(k(n), auth(n-1) || DA || SN)

3. Extensions

0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Type(TBD)   |    Length     |AlgoID |S|     Reserved        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
//                     Sequence Number (128 bits)              //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
//                      Auth Tag (variable)                    //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

- Type (1 octet): TBD, SRv6 SID Verify TLV
- Length (1 octet): The length of data in bytes.
- AlgoID(4 bits): The authentication algorithm ID.
- S(1 bit): 0/1 indicates presentation of sequence number.
- Sequence Number(0 or 128bits): SN is for replay attack
  prevention.
- Auth Tag:  Value produced by authentication algorithm, in
  multiples of 8 octets.
- Reserved (1 octet): MUST be set to zero on transmission,
  ignored on receipt.

4. 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.¶

5. 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 [RFC8754] 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.¶

6. 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.¶

7. IANA Considerations

8. References

Authors' Addresses