SRv6 Path Verification
draft-yang-spring-srv6-verification-04

SPRING                                                           F. Yang
Internet-Draft                                                  X. Zhang
Intended status: Standards Track                            China Mobile
Expires: 14 August 2026                                           C. Lin
                                                    New H3C Technologies
                                                                H. Zhang
                                                     Tsinghua University
                                                        10 February 2026

                         SRv6 Path Verification
                 draft-yang-spring-srv6-verification-04

Abstract

   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 customer site devices, e.g.,
   SD-WAN and enterprise network deployments.  Both of the scenarios can
   be deployed in third-party clouds or at customer sites.  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].

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 14 August 2026.

Copyright Notice

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

Yang, et al.             Expires 14 August 2026                 [Page 1]
Internet-Draft           SRv6 Path Verification            February 2026

   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  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3
     1.2.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Process . . . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Extensions  . . . . . . . . . . . . . . . . . . . . . . . . .   5
     3.1.  SRv6 SID Verify TLV . . . . . . . . . . . . . . . . . . .   5
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
     4.1.  SRv6 SID Verify TLV . . . . . . . . . . . . . . . . . . .   6
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   6
     6.1.  Normative References  . . . . . . . . . . . . . . . . . .   7
     6.2.  Informative References  . . . . . . . . . . . . . . . . .   7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   7

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

Yang, et al.             Expires 14 August 2026                 [Page 2]
Internet-Draft           SRv6 Path Verification            February 2026

   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 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.  And this approach also
   significantly reduces the processing overhead associated with hop-by-
   hop path verification.

1.1.  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 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

1.2.  Terminology

   ALG: authentication algorithm

   DA: destination address in IPv6 header

   HMAC: Hashed Message Authentication Code

   SID: Segment Identifier, defined in [RFC8402]

   SRH: Segment Routing Header, defined in [RFC8402]

   SRv6: SR over IPv6, defined in [RFC8402]

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:

Yang, et al.             Expires 14 August 2026                 [Page 3]
Internet-Draft           SRv6 Path Verification            February 2026

   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

                         Figure 1: Example topology

   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:

Yang, et al.             Expires 14 August 2026                 [Page 4]
Internet-Draft           SRv6 Path Verification            February 2026

   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) as the authentication algorithm, in which n is the node
   index along the path, with the head being the 0th node.

        ALG_n(x) = ALG(k(n), x), k(n) is the key for node n, n >= 0

   Define auth(n) as the path verification information, HMAC
   authentication code, which is calculated by node n and sent out in
   packet towards next SRv6 end point. the auth(n) SHOULD be calculated
   in the following manner.

                if n == 0: auth(0) = 0
                if n >= 1: auth(n) = ALG_n(auth(n-1) + DA)

   Suppose the SRv6 path starts from Node1 and ends on Node4, the path
   verification information would be computed as below on each node.
   Node1: auth(1) = ALG_1(auth(0) + DA) = ALG_1(DA); Node2: auth(2) =
   ALG_2(auth(1) + DA); Node3: auth(3) = ALG_3(auth(2) + DA); Node4:
   auth(4) = ALG_4(auth(3) + DA).  Operator can enable either hop by hop
   verification or tail node verification, because auth(n) can be pre-
   computed by SDN controller and updated to each node.

   In this way, the intermediate nodes specified by in the SID list will
   not be allowed to be bypassed since every hop will have fingerprint
   in the auth(n).

3.  Extensions

3.1.  SRv6 SID Verify TLV

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

Yang, et al.             Expires 14 August 2026                 [Page 5]
Internet-Draft           SRv6 Path Verification            February 2026

    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     | Algorithm ID  |    Key Len    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                        Auth Key ID (variable)                 |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                              //
    |                      Signature (variable)
    //
    |                                                              //
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Type (1 octets): TBD, SRv6 SID Verify TLV

    Length (1 octets): The length of the variable-length data in bytes.

    Algorithm ID(1 octets): The ID of encryption Algorithm.

    Key Len(1 octet): Length of pre-shared

    Auth Key ID:  pre-shared key to encrypt the SID.

    Signature:  encrypted SID data, variable, in multiples of 8 octets.

                       Figure 2: SRv6 SID Verify TLV

4.  IANA Considerations

4.1.  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 |
              +-------+---------------------+---------------+

                            Table 1: Code Point

5.  Security Considerations

   This document should not affect the security of the Internet.

6.  References

Yang, et al.             Expires 14 August 2026                 [Page 6]
Internet-Draft           SRv6 Path Verification            February 2026

6.1.  Normative References

   [RFC8402]  Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
              Decraene, B., Litkowski, S., and R. Shakir, "Segment
              Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
              July 2018, <https://www.rfc-editor.org/rfc/rfc8402>.

   [RFC8754]  Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J.,
              Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header
              (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020,
              <https://www.rfc-editor.org/rfc/rfc8754>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/rfc/rfc2119>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

6.2.  Informative References

   [I-D.draft-ietf-spring-srv6-security]
              Buraglio, N., Mizrahi, T., tongtian124, Contreras, L. M.,
              and F. Gont, "Segment Routing IPv6 Security
              Considerations", Work in Progress, Internet-Draft, draft-
              ietf-spring-srv6-security-11, 2 February 2026,
              <https://datatracker.ietf.org/doc/html/draft-ietf-spring-
              srv6-security-11>.

Authors' Addresses

   Feng Yang
   China Mobile
   China
   Email: yangfeng@chinamobile.com

   Xiaoqiu Zhang
   China Mobile
   China
   Email: zhangxiaoqiu@chinamobile.com

   Changwang Lin
   New H3C Technologies
   China

Yang, et al.             Expires 14 August 2026                 [Page 7]
Internet-Draft           SRv6 Path Verification            February 2026

   Email: linchangwang.04414@h3c.com

   Han Zhang
   Tsinghua University
   China
   Email: zhhan@tsinghua.edu.cn

Yang, et al.             Expires 14 August 2026                 [Page 8]