Network Working Group F. Yang Internet Draft X. Zhang Intended status: Standards Track China Mobile Expires: September 03, 2025 C. Lin New H3C Technologies March 3, 2025 SRv6 Path Verification draft-yang-spring-srv6-verification-00 Abstract 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. 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), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Yang, et al. Expire September, 2025 [Page 1] Internet-Draft SRv6 Path Verification March 2025 This Internet-Draft will expire on September 03, 2025. Copyright Notice Copyright (c) 2025 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 (http://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 Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction...................................................2 1.1. Requirements Language.....................................3 2. Process........................................................3 3. Extensions.....................................................5 3.1. SRv6 SID Verify TLV.......................................5 4. IANA Considerations............................................5 4.1. SRv6 SID Verify TLV.......................................5 5. References.....................................................6 5.1. Normative References......................................6 5.2. Informational References..................................6 Authors' Addresses................................................6 1. Introduction [RFC8754] 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, Yang, et al. Expires September, 2025 [Page 2] Internet-Draft SRv6 Path Verification March 2025 making it challenging to implement in practical commercial deployments. This document proposes a mechanism that adopts a hop-by-hop cryptographic computation of the destination segment identifier at each node, combined with an end-to-end verification at the last hop. This approach significantly reduces the processing overhead associated with hop-by-hop HMAC path verification. Furthermore, the document replaces the HMAC algorithm with a more versatile signature algorithm, thereby extending its applicability beyond the confines of HMAC. 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. 2. Process +------+ +-------+ +------+ +-----+ |Head +-----+Inter +----+Inter + --+Tail | |Node | |Nodes 1| |Node 2| |Node | +------+ +-------+ +------+ +-----+ 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: 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 Result 1. This result 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 Result 1, is forwarded to the first intermediate node. Yang, et al. Expires September, 2025 [Page 3] Internet-Draft SRv6 Path Verification March 2025 Intermediate Nodes: The first intermediate node receives the IPv6/SRv6 packet from the head node, which includes Result 1 and the destination segment identifier of the next hop (i.e., the SID of the second intermediate node). The intermediate node encrypts the destination segment identifier of the next hop using the same predefined encryption algorithm and pre-shared key, generating Result 2. It then reads Result 1 from the packet and combines it with Result 2 through a predefined operation (e.g., weighted summation), generating Combined Result 1. This combined result is 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 result (Combined Result 1). It decrypts the path verification information (i.e., Combined Result 1) using the same pre-shared key and encryption algorithm, based on the destination segment identifiers (SIDs) of all preceding nodes, generating Result N. It then performs the same combination operation to generate Combined Result 2. The tail node compares Combined Result 1 and Combined Result 2. If they do not match, the packet is considered untrusted and discarded. If they match, the packet is forwarded normally based on the last hop SID. In case of a mismatch, the tail node triggers the head node and all intermediate nodes to resend their individual calculation results in the specified field. The tail node then compares these results with its own calculations to identify the specific node where the verification failed, enabling traceability of the verification anomaly. Head Node: [SID1] -> encryption -> Result 1 -> Insert into Packet -> Forward to Intermediate Node 1 Intermediate Node 1: [SID2] -> encryption -> Result 2 -> Combine with Result 1 -> Combined Result 1 -> Insert into Packet -> Forward to Intermediate Node 2 Intermediate Node 2: Yang, et al. Expires September, 2025 [Page 4] Internet-Draft SRv6 Path Verification March 2025 [SID3] -> encryption -> Result 3 -> Combine with Combined Result 1 -> Combined Result 2 -> Insert into Packet -> Forward to Tail Node Tail Node: [SID1, SID2, SID3] -> encryption -> Result N -> Combine -> Combined Result -> Compare with Combined Result 1 -> Forward/Discard 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 | 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 1: 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". Yang, et al. Expires September, 2025 [Page 5] Internet-Draft SRv6 Path Verification March 2025 +---------+--------------------------+---------------+ | Value | Description | Reference | +=========+==========================+===============+ | 0 | SRv6 SID Verify TLV | This document | +---------+--------------------------+---------------+ 5. References 5.1. Normative References [RFC8754] C. Filsfils, Ed., D. Dukes, Ed., Cisco Systems, Inc., S. Previdi, Huawei, J. Leddy, Individual, S. Matsushima, SoftBank, D. Voyer, Bell Canada, "IPv6 Segment Routing Header (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, . 5.2. Informational References TBD Authors' Addresses Feng Yang China Mobile Beijing China Email: yangfeng@chinamobile.com Changwang Lin New H3C Technologies Beijing China Email: linchangwang.04414@h3c.com Xiaoqiu Zhang China Mobile Beijing China Email: zhangxiaoqiu@chinamobile.com Yang, et al. Expires September, 2025 [Page 6]