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

SPRING                                                           F. Yang
Internet-Draft                                                  X. Zhang
Intended status: Standards Track                            China Mobile
Expires: 29 December 2026                                         C. Lin
                                                    New H3C Technologies
                                                                H. Zhang
                                                     Tsinghua University
                                                            27 June 2026

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

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 29 December 2026.

Copyright Notice

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

Yang, et al.            Expires 29 December 2026                [Page 1]
Internet-Draft           SRv6 Path Verification                June 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 . . . . . . . . . . . . . . . . . . . . . . .   4
   2.  Process . . . . . . . . . . . . . . . . . . . . . . . . . . .   4
     2.1.  Authentication Algorithms . . . . . . . . . . . . . . . .   5
       2.1.1.  Sequence Number Handling: . . . . . . . . . . . . . .   6
       2.1.2.  Algorithm Selection Guidelines  . . . . . . . . . . .   6
   3.  Extensions  . . . . . . . . . . . . . . . . . . . . . . . . .   7
     3.1.  SRv6 SID Verify TLV . . . . . . . . . . . . . . . . . . .   7
   4.  Operational Consideration . . . . . . . . . . . . . . . . . .   8
   5.  Backward Compatibility  . . . . . . . . . . . . . . . . . . .   8
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
     6.1.  Key Management Considerations . . . . . . . . . . . . . .   8
     6.2.  Replay Attack Prevention  . . . . . . . . . . . . . . . .   9
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
     7.1.  SRv6 SID Verify TLV . . . . . . . . . . . . . . . . . . .   9
     7.2.  SRv6 SID Verify Algorithm Registry  . . . . . . . . . . .   9
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   9
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .   9
     8.2.  Informative References  . . . . . . . . . . . . . . . . .  10
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  10

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].

Yang, et al.            Expires 29 December 2026                [Page 2]
Internet-Draft           SRv6 Path Verification                June 2026

   [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.

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.

Yang, et al.            Expires 29 December 2026                [Page 3]
Internet-Draft           SRv6 Path Verification                June 2026

1.2.  Terminology

   ALG: Authentication algorithm

   DA: Destination address in IPv6 header

   CMAC: Cipher-based Message Authentication Code, defined in [RFC4493]

   HMAC: Hash-based Message Authentication Code, defined in [RFC6234]

   MAC: 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:

   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 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:

Yang, et al.            Expires 29 December 2026                [Page 4]
Internet-Draft           SRv6 Path Verification                June 2026

   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).

2.1.  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 [RFC6234] 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.

Yang, et al.            Expires 29 December 2026                [Page 5]
Internet-Draft           SRv6 Path Verification                June 2026

   AES-CMAC-128 [RFC4493] 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:

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

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

                    Table 1: SRv6 SID Verify Algorithms

2.1.1.  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.

2.1.2.  Algorithm Selection Guidelines

   Implementations SHOULD select algorithms based on the following
   deployment characteristics:

Yang, et al.            Expires 29 December 2026                [Page 6]
Internet-Draft           SRv6 Path Verification                June 2026

     +======================+==============+=========================+
     | Deployment Scenario  | Recommended  | Rationale               |
     |                      | Algorithm    |                         |
     +======================+==============+=========================+
     | Hardware with        | HMAC-SHA256  | Strong security, widely |
     | SHA-256 acceleration |              | supported in hardware   |
     +----------------------+--------------+-------------------------+
     | Hardware with AES-NI | AES-CMAC-128 | Efficient in hardware,  |
     | or dedicated AES     |              | low power consumption   |
     | crypto engines       |              |                         |
     +----------------------+--------------+-------------------------+

                  Table 2: Algorithm Selection Guidelines

3.  Extensions

3.1.  SRv6 SID Verify TLV

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

     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.

                       Figure 2: SRv6 SID Verify TLV

Yang, et al.            Expires 29 December 2026                [Page 7]
Internet-Draft           SRv6 Path Verification                June 2026

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.

6.1.  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.

Yang, et al.            Expires 29 December 2026                [Page 8]
Internet-Draft           SRv6 Path Verification                June 2026

6.2.  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.

7.  IANA Considerations

7.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 3: Code Point

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

                       Table 4: Algorithm Registry

8.  References

8.1.  Normative References

Yang, et al.            Expires 29 December 2026                [Page 9]
Internet-Draft           SRv6 Path Verification                June 2026

   [RFC4493]  Song, JH., Poovendran, R., Lee, J., and T. Iwata, "The
              AES-CMAC Algorithm", RFC 4493, DOI 10.17487/RFC4493, June
              2006, <https://www.rfc-editor.org/rfc/rfc4493>.

   [RFC6234]  Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms
              (SHA and SHA-based HMAC and HKDF)", RFC 6234,
              DOI 10.17487/RFC6234, May 2011,
              <https://www.rfc-editor.org/rfc/rfc6234>.

   [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>.

8.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-15, 24 June 2026,
              <https://datatracker.ietf.org/doc/html/draft-ietf-spring-
              srv6-security-15>.

Authors' Addresses

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

Yang, et al.            Expires 29 December 2026               [Page 10]
Internet-Draft           SRv6 Path Verification                June 2026

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

   Changwang Lin
   New H3C Technologies
   China
   Email: linchangwang.04414@h3c.com

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

Yang, et al.            Expires 29 December 2026               [Page 11]