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,
<https://www.rfc-editor.org/info/rfc8754>.
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]