Network Working Group X. Chen Internet-Draft L. Han Intended status: Informational China Mobile Expires: 6 May 2027 L. Zhang L. Dai Huawei 2 November 2026 A Framework for SRv6-Based Trusted Key Relay in Quantum Key Distribution Networks draft-chen-rtg-framework-srv6-trusted-relay-qkd-00 Abstract Quantum Key Distribution (QKD) links generate symmetric key material between directly connected QKD nodes. Trusted relay is commonly used to extend key delivery beyond the reach of a single QKD link. A complete trusted-relay service requires the network to collect QKD link and node quantum capability information, compute a relay path according to service requirements, translate the result into a network forwarding path, and carry the relayed key information in an IPv6/UDP packet steered by that path. This document describes an architectural framework for such a service. Each QKD link provides its link quantum capability such as available quantum key rate capacity, and each relay node provides its node quantum capability . A controller uses these inputs together with application requirements to calculate a relay path. The path- computation algorithm is not standardized and may be selected or defined by the user, operator, or implementation. The calculated relay sequence is represented as an SRv6 path, and UDP packets following that path carry the key-relay information. This document identifies the protocol extension points needed to support the framework. The detailed encodings, message formats, TLVs, and signaling procedures are left for future work and are marked as TBD. 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/. Chen, et al. Expires 6 May 2027 [Page 1] Internet-Draft A Framework for SRv6-Based Trusted Key R November 2026 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 6 May 2027. 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4 4. Framework Overview . . . . . . . . . . . . . . . . . . . . . 6 4.1. Functional Components . . . . . . . . . . . . . . . . . . 6 4.2. Information Flow . . . . . . . . . . . . . . . . . . . . 7 5. Path-Computation Inputs . . . . . . . . . . . . . . . . . . . 7 5.1. Quantum Key Generation Rate (QKGR) . . . . . . . . . . . 8 5.2. Node QKD Capability . . . . . . . . . . . . . . . . . . . 8 5.3. Service Requirements . . . . . . . . . . . . . . . . . . 8 6. Path Computation . . . . . . . . . . . . . . . . . . . . . . 8 6.1. General Requirements . . . . . . . . . . . . . . . . . . 8 6.2. Path Computation Algorithms . . . . . . . . . . . . . . . 9 6.3. Path Output . . . . . . . . . . . . . . . . . . . . . . . 9 7. SRv6-Based Key Relay . . . . . . . . . . . . . . . . . . . . 9 7.1. SRv6 Path Representation . . . . . . . . . . . . . . . . 9 7.2. Key Relay Payload Transport . . . . . . . . . . . . . . . 9 7.3. Processing at Trusted Relay Nodes . . . . . . . . . . . . 10 8. Protocol Extension Requirements . . . . . . . . . . . . . . . 11 8.1. QKD Link Capacity Advertisement . . . . . . . . . . . . . 11 8.2. Node Capability Advertisement . . . . . . . . . . . . . . 11 8.3. Key-Relay Message . . . . . . . . . . . . . . . . . . . . 11 9. Operational Considerations . . . . . . . . . . . . . . . . . 12 10. Security Considerations . . . . . . . . . . . . . . . . . . . 12 Chen, et al. Expires 6 May 2027 [Page 2] Internet-Draft A Framework for SRv6-Based Trusted Key R November 2026 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 12. Normative References . . . . . . . . . . . . . . . . . . . . 13 13. Informative References . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 1. Introduction Quantum Key Distribution provides a method for generating shared symmetric keys between two QKD systems. The physical distance of a single QKD link is limited by optical attenuation, noise, equipment capability, and deployment conditions. Large-scale QKD networks therefore commonly use trusted relay nodes to deliver key material across multiple QKD links. Trusted relay is not only a key-management function. It also requires a network path that selects the correct relay nodes in the correct order. The path should take into account at least two QKD- specific properties: * the link quantum capability ( e.g., the quantum key rate capacity available on each QKD link); and * the node quantum capability ( e.g., key relay processing capability of each node). After the path is calculated, the network must enforce the selected relay sequence and carry the key-relay information between the nodes. Segment Routing over IPv6 (SRv6) [RFC8986] enables a network operator or an application to specify a packet processing program by encoding a sequence of instructions in the IPv6 packet header. This document uses SRv6 as the path-steering mechanism and UDP as the transport for the key-relay information. The framework is intended to connect four previously separated functions: * QKD resource and quantum capability collection; * service-driven path computation; * SRv6 path generation and installation; and * hop-by-hop trusted key relay using SRv6-steered UDP packets. This document focuses on the architecture and protocol requirements. It does not define detailed wire formats or a mandatory path- computation algorithm. Chen, et al. Expires 6 May 2027 [Page 3] Internet-Draft A Framework for SRv6-Based Trusted Key R November 2026 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. Terminology QKD Node: A network node containing, or connected to, QKD key- generation and key-management functions. QKD Link: A communication relationship between two directly connected QKD nodes that can generate shared key material. Trusted Relay Node: A QKD node authorized to receive, process, and forward relayed key information. Quantum Key Rate Capacity: A metric describing the amount or rate of QKD-generated key material that a QKD link can provide for a key- relay service. Service Requirement: A set of constraints associated with a key-relay request, such as requested key rate, maximum number of relays, latency, administrative policy, and protection requirements. QKD Controller: A control function that collects QKD topology information, receives service requirements, computes a trusted relay path, and installs the corresponding SRv6 path. SRv6 Path: An ordered SRv6 segment list used to steer a key-relay packet through the selected trusted relay nodes. Key-Relay Packet: An IPv6 packet containing an SRv6 path and a UDP payload carrying key-relay information. 3. Problem Statement QKD provides information-theoretic security, but the physical distance of a single QKD link is strictly bounded by optical attenuation, environmental noise, and hardware limitations. Typically, a quantum metropolitan network covers a transmission range of tens to over a hundred kilometers. While current standards define specific key generation rate requirements under certain distances (e.g., 20 kbps at 40 km and 2 kbps at 80 km), the actual end-to-end service delivery distance in operational networks often far exceeds the direct reach of a single QKD link. To provide end-to-end secure Chen, et al. Expires 6 May 2027 [Page 4] Internet-Draft A Framework for SRv6-Based Trusted Key R November 2026 services across a wide area, QKD key material must be relayed. However, once intermediate relay nodes are introduced, the key material is exposed to the risk of eavesdropping or theft at these nodes. Therefore, a trusted relay mechanism is mandatory, especially across the following deployment scenarios: * Integrated transport networks: In operational networks, QKD equipment can be co-deployed with classical transport equipment. Operators leverage existing telecom nodes as trusted relays to extend key delivery, ensuring smooth integration with current network infrastructures. * High-Security Isolation Domains: For sensitive applications (e.g., financial transactions), keys must not be exposed in plaintext at arbitrary intermediate nodes. The relay path must be strictly constrained to traverse only nodes that meet specific security isolation capabilities. A trusted relay relies on Relay Mechanism: The key relay process itself must be secured. For instance, current standard relay methods use chained relay, transmitting only the XOR value of the keys rather than the plaintext keys, ensuring that key material does not "land" at any single intermediate node. Key relay in QKD networks imposes strict security requirements, specifically ensuring that key material is not exposed in plaintext at intermediate nodes. To minimize the risk of key interception, it is essential to achieve global, dynamic path orchestration that distributes keys across multiple disjoint paths, avoiding reliance on any single fixed route. Currently, key relay paths in QKD networks are typically established via static or manual configurations managed by a centralized Key Management System (KMS). However, this approach suffers from significant limitations when applied to dynamic operational networks: * Lack of Dynamics: Static paths cannot adapt to real-time changes in link key generation rates, key pool depletion, or network failures, leading to potential service interruptions. * Scalability and Interoperability: Manual configuration is labor- intensive and does not scale for multi-point mesh networks. It also faces severe challenges in cross-domain deployment and interoperability across multi-vendor equipment. Chen, et al. Expires 6 May 2027 [Page 5] Internet-Draft A Framework for SRv6-Based Trusted Key R November 2026 To overcome these limitations, a dynamic, QKD-aware, and standardized path-steering mechanism is required. Segment Routing over IPv6 (SRv6) provides an ideal foundation: it uses source routing to encode the explicit relay sequence in the packet header, eliminating the need for per-flow state at intermediate nodes, while its programmable architecture ensures seamless cross-domain interoperability. 4. Framework Overview A QKD relay service therefore needs a mechanism that connects path computation with packet forwarding. The controller first selects a relay path based on QKD-specific inputs and service requirements. It then expresses that path as an SRv6 segment list so that key-relay packets visit the selected relay nodes in the selected order. 4.1. Functional Components The framework contains the following logical components: +--------------------+ | Application or KME | +--------------------+ | service request | | v +--------------------------------------------------------------+ | QKD Controller | +--------------------------------------------------------------+ ^ ^ ^ ^ | | | | | | | | QKD | SRv6-based | | | | Capability | QKD relay | | | | Collection | path | | | | | installation | | | | | | v +------+ +-------+ +-------+ +-------+ | QKD |<-------->| QKD |<-------->| QKD |<-------->| QKD | | Node | QKD Link | Node | QKD Link | Node | QKD Link | Node | |(Dst) | | | | | |(Src) | +------+ +-------+ +-------+ +-------+ <------------SRv6 Based Key Relay --------------------- SRv6-steered IPv6/UDP key-relay packets Figure 1: Functional Components Chen, et al. Expires 6 May 2027 [Page 6] Internet-Draft A Framework for SRv6-Based Trusted Key R November 2026 The components may be implemented in separate physical devices or combined in one device. For example, an SRv6 router and a QKD key management entity may be integrated or connected through a protected local interface. The Application or KME serves as the source of the key service request, while the QKD Controller collects QKD capability information to compute and install an SRv6-based relay path, which is then used to steer the key relay across the QKD Links between the Source and Destination QKD nodes. 4.2. Information Flow The general information flow is: 1. QKD links provide their quantum key rate capacity to the control system. 1. QKD relay nodes provide their node quantum capabilities and relay capabilities to the control system. 1. An application or key-management entity sends a key-relay service request to the QKD controller. 1. The controller combines the QKD topology information with the service requirements. 1. The controller runs a path-computation algorithm selected by the user, operator, or implementation. 1. The controller generates an ordered relay-node sequence. 1. The controller translates the relay-node sequence into an SRv6 path. 1. The controller installs the SRv6 path and any required relay state. 1. The source sends a UDP key-relay packet along the SRv6 path. 1. Each trusted relay node processes the key-relay information and forwards the packet toward the next relay. 1. The destination accepts the delivered key information and may return an acknowledgment. 5. Path-Computation Inputs Chen, et al. Expires 6 May 2027 [Page 7] Internet-Draft A Framework for SRv6-Based Trusted Key R November 2026 5.1. Quantum Key Generation Rate (QKGR) Quantum Key Generation Rate, referred to as QKGR in this document, is a metric describing the QKD key-generation resource associated with a QKD link. The value SHOULD represent the amount of key material that can be made available to new key-relay services. A QKD link without QKGR MUST NOT be selected for a new key-relay path. The protocol used to advertise QKGR and its detailed encoding are TBD. 5.2. Node QKD Capability Attributes associated with a QKD node that are required for path computation and forwarding. This contains a unique Key Manager Identifier (KM-ID) and a routable Key Manager IP Address (KM-IP), which are necessary for the controller to interact with the node's KME and for mapping the SRv6 segment to the local key relay function. 5.3. Service Requirements A key-relay request may contain one or more of the following requirements based on the basic path computation requirements (e.g., bandwidth, latency): * source QKD node or source KME; * destination QKD node or destination KME; * requested QKGR; The exact service-request interface and message format are TBD. 6. Path Computation 6.1. General Requirements The controller uses the QKD topology information and service requirements to select a trusted relay path. A valid path SHOULD satisfy all mandatory service constraints. At a minimum, the controller SHOULD verify that: * consecutive relay nodes are connected by usable QKD links; Chen, et al. Expires 6 May 2027 [Page 8] Internet-Draft A Framework for SRv6-Based Trusted Key R November 2026 * selected QKD links provide sufficient QKGR; * the selected relay sequence can be represented and installed as an SRv6 path. The controller MAY consider additional information, including IP transport cost, link latency, key-pool status, network congestion, failure risk, administrative boundaries, or protection policy. 6.2. Path Computation Algorithms The specific path-computation algorithm is out of scope and may be freely defined by the operator or implementation. 6.3. Path Output The output of path computation is an ordered sequence of trusted relay nodes from the source to the destination. The controller maps each relay node to an SRv6 segment or SRv6 service instruction. The resulting SRv6 path MUST preserve the relay order selected by the path-computation function. The detailed mapping between a trusted relay node and an SRv6 SID is TBD. The controller MAY also insert transport-related segments when needed to constrain the classical IP path between two trusted relay nodes. The detailed rules are TBD. 7. SRv6-Based Key Relay 7.1. SRv6 Path Representation SRv6 provides an ordered list of network instructions that can be carried in an IPv6 packet. In this framework, the SRv6 path represents the ordered trusted relay sequence selected by the controller. Each trusted relay node SHOULD be explicitly represented in the SRv6 path. This ensures that the key-relay packet is processed by all selected relay nodes in the required order. 7.2. Key Relay Payload Transport The SRv6 packet carries a transport layer datagram to deliver the key-relay information. The transport layer payload carries the information required by the trusted key-relay process. Chen, et al. Expires 6 May 2027 [Page 9] Internet-Draft A Framework for SRv6-Based Trusted Key R November 2026 The transport layer payload should contain the following information: * Intermediate encrypted key: the key material processed for the next hop. * key identifier: to uniquely identify the key session. * service identifier: to map the packet to the specific key-relay service; The port, message types, field encoding, cryptographic container, and message-protection mechanism are TBD. Existing generic transport protocols lack standardized fields to carry essential key-relay contexts. Furthermore, there is no standardized message format to acknowledge successful key delivery or to report relay processing errors. A dedicated payload format or protocol extension is required. 7.3. Processing at Trusted Relay Nodes When a key-relay packet reaches a trusted relay node, the node performs the trusted relay function associated with that SRv6 processing point. The logical processing includes: 1. Extract the key-relay information from the transport layer payload. 1. Deliver the key-relay information to the local QKD relay or KME function. 1. Process the received key information according to the trusted relay policy. 1. Generate or update the key-relay information for the next node. 1. Continue forwarding according to the SRv6 path. At the destination, the key information is delivered to the destination KME or application. The exact packet-processing behavior and the division of functions between the SRv6 node and the KME are TBD. Chen, et al. Expires 6 May 2027 [Page 10] Internet-Draft A Framework for SRv6-Based Trusted Key R November 2026 8. Protocol Extension Requirements As identified in Section 7, standard forwarding, routing, and transport protocols lack the specific mechanisms required to enforce a trusted QKD relay. This section identifies the protocol areas that require extension. Only the extension objectives are defined. All detailed formats and procedures are TBD. 8.1. QKD Link Capacity Advertisement A protocol extension is required to advertise the quantum key rate capacity of each QKD link to the controller. The extension is to provide the controller with real-time visibility into the network's key generation resources, enabling QKD-aware path computation to avoid links with insufficient key rates or depleted key pools. The extension SHOULD support: * identification of the associated QKD link; * representation of QKGR (e.g., key generation rate and available key storage).; The protocol selected for carrying this information and the detailed extension format are TBD. 8.2. Node Capability Advertisement A protocol extension is required to advertise the QKD relay capability of each node. This extension is designed to expose the node's internal key management endpoint to the control plane. The extension SHOULD support: * identification of the associated Key Manager in the Node. * IP Address of the associated Key Manager in the Node. The protocol selected for carrying this information and the detailed extension format are TBD. 8.3. Key-Relay Message A protocol extension or new protocol is required to carry the key- relay information. The protocol SHOULD support: Chen, et al. Expires 6 May 2027 [Page 11] Internet-Draft A Framework for SRv6-Based Trusted Key R November 2026 * service identifier; * Intermediate encrypted key; * key identifier; The transport protocol, payload encoding, key- protection method, and algorithm negotiation are TBD. 9. Operational Considerations TBD 10. Security Considerations Trusted Relay Model: Every trusted relay node may obtain access to the relayed key information. The security of the end-to-end service therefore depends on every selected relay node. Integrity of Path-Computation Inputs: An attacker that changes QKGR or NTL information may cause the controller to select an exhausted, unavailable, or insufficiently trusted path. The mechanisms used to distribute these values MUST provide authentication and integrity protection. The detailed mechanism is TBD. Authorization of SRv6 Paths: An attacker MUST NOT be able to create an unauthorized SRv6 path that invokes the trusted relay function. SRv6 ingress filtering, policy authorization, and path validation SHOULD be used. Any additional mechanism is TBD. Protection of Key Material: Key material carried in the UDP payload MUST be protected against disclosure and modification. The detailed encryption, authentication, key-identification, and nonce-handling mechanisms are TBD. Binding to the Selected Path: A key-relay message SHOULD be bound to the intended service, session, and relay path so that it cannot be moved to a different path or replayed in a different context. The detailed binding mechanism is TBD. Replay and Duplicate Delivery: The key-relay protocol MUST provide replay protection and duplicate-safe processing. The detailed sequence-number and state-management procedures are TBD. Relay Node Protection: A relay node SHOULD process plaintext key information only inside a protected execution and storage environment. The implementation SHOULD minimize the lifetime of plaintext key material. Chen, et al. Expires 6 May 2027 [Page 12] Internet-Draft A Framework for SRv6-Based Trusted Key R November 2026 Denial of Service: SRv6 and UDP processing may expose relay nodes and KMEs to resource-exhaustion attacks. Implementations SHOULD use filtering, rate limiting, bounded state, and authorization checks. Metadata Exposure: An SRv6 path may reveal the trusted relay sequence, and visible context may reveal that a QKD key-relay service is active. Operators SHOULD evaluate whether additional tunnel or metadata- protection mechanisms are required. 11. IANA Considerations This document makes no IANA requests. 12. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", RFC 8174, May 2017, . [RFC8200] Deering, S., "Internet Protocol, Version 6 (IPv6) Specification", RFC 8200, July 2017, . [RFC8754] Filsfils, C., "IPv6 Segment Routing Header (SRH)", RFC 8754, March 2020, . [RFC8986] Filsfils, C., "Segment Routing over IPv6 (SRv6) Network Programming", RFC 8986, February 2021, . 13. Informative References [RFC8402] Filsfils, C., "Segment Routing Architecture", RFC 8402, July 2018, . [RFC9256] Filsfils, C., "Segment Routing Policy Architecture", RFC 9256, July 2022, . [ITU-Y3800] ITU-T, "Overview on networks supporting quantum key distribution", ITU-T Recommendation Y.3800, October 2019. Chen, et al. Expires 6 May 2027 [Page 13] Internet-Draft A Framework for SRv6-Based Trusted Key R November 2026 [ETSI-QKD014] ETSI, "Quantum Key Distribution (QKD); Protocol and data format of REST-based key delivery API", ETSI GS QKD 014 V1.1.1, February 2019, . Authors' Addresses Xinyu Chen China Mobile Email: chenxinyuyjy@chinamobile.com Liuyan Han China Mobile Email: hanliuyan@chinamobile.com Li Zhang Huawei Email: zhangli344@huawei.com Longfei Dai Huawei Email: larry.dai@huawei.com Chen, et al. Expires 6 May 2027 [Page 14]