| Internet-Draft | A Framework for SRv6-Based Trusted Key R | November 2026 |
| Chen, et al. | Expires 6 May 2027 | [Page] |
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.¶
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 6 May 2027.¶
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.¶
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.¶
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.¶
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.¶
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 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.¶
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.¶
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.¶
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
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.¶
The general information flow is:¶
QKD links provide their quantum key rate capacity to the control system.¶
QKD relay nodes provide their node quantum capabilities and relay capabilities to the control system.¶
An application or key-management entity sends a key-relay service request to the QKD controller.¶
The controller combines the QKD topology information with the service requirements.¶
The controller runs a path-computation algorithm selected by the user, operator, or implementation.¶
The controller generates an ordered relay-node sequence.¶
The controller translates the relay-node sequence into an SRv6 path.¶
The controller installs the SRv6 path and any required relay state.¶
The source sends a UDP key-relay packet along the SRv6 path.¶
Each trusted relay node processes the key-relay information and forwards the packet toward the next relay.¶
The destination accepts the delivered key information and may return an acknowledgment.¶
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.¶
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.¶
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.¶
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;¶
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.¶
The specific path-computation algorithm is out of scope and may be freely defined by the operator or implementation.¶
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.¶
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.¶
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.¶
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.¶
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:¶
Extract the key-relay information from the transport layer payload.¶
Deliver the key-relay information to the local QKD relay or KME function.¶
Process the received key information according to the trusted relay policy.¶
Generate or update the key-relay information for the next node.¶
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.¶
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.¶
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.¶
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.¶
A protocol extension or new protocol is required to carry the key- relay information.¶
The protocol SHOULD support:¶
service identifier;¶
Intermediate encrypted key;¶
key identifier;¶
The transport protocol, payload encoding, key- protection method, and algorithm negotiation are TBD.¶
TBD¶
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.¶
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.¶
This document makes no IANA requests.¶