Internet-Draft SRv6 QKD Relay Framework July 2026
Chen, et al. Expires 7 January 2027 [Page]
Workgroup:
QIRG
Internet-Draft:
draft-chen-qirg-srv6-qkd-relay-framework-00
Published:
Intended Status:
Informational
Expires:
Authors:
X. Chen
China Mobile
L. Han
China Mobile
L. Dai
Huawei Technologies

A Framework for SRv6-Based Trusted Key Relay in Quantum Key Distribution Networks

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 capacity and node trust information, compute a relay path according to service requirements, translate the result into an SRv6 path, and carry the relayed key information in an IPv6/UDP packet steered by that SRv6 path.

This document describes an architectural framework for such a service. Each QKD link provides its available quantum key rate capacity, and each relay node provides a trust level. 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, SRv6 behaviors, 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/.

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 7 January 2027.

▲

Table of Contents

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:

After the path is calculated, the network must enforce the selected relay sequence and carry the key-relay information between the nodes. 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:

This document focuses on the architecture and protocol requirements. It does not define detailed wire formats or a mandatory path-computation algorithm.

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.

1.2. Scope

This document specifies an architectural framework in which:

  • each QKD link provides quantum key rate capacity information;
  • each QKD node provides node trust information;
  • a controller computes a relay path according to service requirements;
  • the path-computation algorithm may be defined by the operator, user, or implementation;
  • the controller translates the selected relay sequence into an SRv6 path;
  • SRv6 steers UDP packets through the selected trusted relay nodes; and
  • the UDP payload carries the key-relay information required by the trusted relay process.

The following items are outside the scope of this document:

  • the detailed algorithm used for path computation;
  • the detailed protocol encoding used to advertise QKD link capacity;
  • the detailed protocol encoding used to advertise node trust levels;
  • the detailed SRv6 endpoint behavior or SRH extension;
  • the detailed UDP message format;
  • the cryptographic protection format for the UDP payload;
  • the local interface between the relay function and the QKD key management system; and
  • multi-path key splitting and reconstruction.

All such protocol details are left as TBD.

2. Terminology

QKD Link
A communication relationship between two directly connected QKD nodes that can generate shared key material.
QKD Node
A network node containing, or connected to, QKD key-generation and key-management functions.
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.
Node Trust Level
A metric describing the trustworthiness of a QKD node according to the operator's security policy.
Service Requirement
A set of constraints associated with a key-relay request, such as requested key rate, minimum node trust level, 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

A conventional IP path is selected mainly according to reachability and network metrics. Such a path may not be suitable for QKD key relay because it does not necessarily consider QKD key availability or node trustworthiness.

For example, the shortest IP path may traverse:

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 key-relay information is carried in the UDP payload. Each trusted relay node processes the received information and forwards a new or updated UDP packet toward the next relay according to the SRv6 path.

4. Framework Overview

4.1. Functional Components

The framework contains the following logical components:

+--------------------+       resource and trust       +-------------+
| QKD Links and      | ---------------------------->  |             |
| QKD Relay Nodes    |                                |             |
+--------------------+                                |             |
                                                      |    QKD      |
+--------------------+       service request          | Controller  |
| Application or KME | ---------------------------->  |             |
+--------------------+                                |             |
                                                      +------+------+
                     path install                            |
        +----------------------------------------------------+
        |
        v
   +---------+      +-----------+      +-----------+      +---------+
   | Source  |----->| Relay R1  |----->| Relay R2  |----->| Dest.   |
   | QKD/KME |      | SRv6/QKD  |      | SRv6/QKD  |      | QKD/KME |
   +---------+      +-----------+      +-----------+      +---------+
          SRv6-steered IPv6/UDP key-relay packets
Figure 1: SRv6-Based QKD Trusted Relay Framework

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.

4.2. Information Flow

The general information flow is:

  1. QKD links provide their quantum key rate capacity to the control system.
  2. QKD relay nodes provide their node trust levels and relay capabilities to the control system.
  3. An application or key-management entity sends a key-relay service request to the QKD controller.
  4. The controller combines the QKD topology information with the service requirements.
  5. The controller runs a path-computation algorithm selected by the user, operator, or implementation.
  6. The controller generates an ordered relay-node sequence.
  7. The controller translates the relay-node sequence into an SRv6 path.
  8. The controller installs the SRv6 path and any required relay state.
  9. The source sends a UDP key-relay packet along the SRv6 path.
  10. Each trusted relay node processes the key-relay information and forwards the packet toward the next relay.
  11. The destination accepts the delivered key information and may return an acknowledgment.

5. Path-Computation Inputs

5.1. Quantum Key Rate Capacity

Quantum Key Rate Capacity, referred to as QKRC 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. Depending on the implementation, it may represent:

  • a nominal key-generation rate;
  • a currently available key-generation rate;
  • an available amount of key material in a key pool;
  • a combination of current rate and stored key amount; or
  • another operator-defined capacity metric.

The exact capacity model is deployment specific. A controller MUST understand the semantics of the value before using it for path computation.

A QKD link with no usable key-generation capability MUST NOT be selected for a new key-relay path.

The protocol used to advertise QKRC and its detailed encoding are TBD.

5.2. Node Trust Level

Node Trust Level, referred to as NTL in this document, is a policy-defined metric representing the degree of trust assigned to a QKD relay node.

An implementation may use a five-level model such as:

Level 1
Minimal trust.
Level 2
Basic operational trust.
Level 3
Moderate trust with controlled physical and management access.
Level 4
High trust with enhanced hardware and operational protection.
Level 5
Maximum trust under the operator's assurance policy.

The specific criteria associated with each level are defined by the operator, user, or applicable assurance framework. Trust levels from different administrative or assurance domains may not be directly comparable.

A service may require that every selected trusted relay node meet a minimum NTL.

The protocol used to advertise NTL and its detailed encoding are TBD.

5.3. Service Requirements

A key-relay request may contain one or more of the following requirements:

  • source QKD node or source KME;
  • destination QKD node or destination KME;
  • requested key rate;
  • requested key amount;
  • minimum node trust level;
  • maximum number of trusted relay nodes;
  • maximum latency;
  • administrative inclusion or exclusion policy;
  • path diversity or protection requirement;
  • service priority; and
  • service lifetime.

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;
  • selected QKD links provide sufficient quantum key rate capacity;
  • selected relay nodes satisfy the required node trust level;
  • selected relay nodes support the required trusted relay function; and
  • 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. User-Defined Algorithms

This document does not define or require a specific path-computation algorithm.

The algorithm MAY be:

  • selected by the operator;
  • configured by the user;
  • implemented as a shortest-path or constrained shortest-path algorithm;
  • implemented as a multi-objective optimization algorithm;
  • based on policy rules;
  • based on real-time measurements; or
  • implemented using another vendor-specific or application-specific method.

Different algorithms may produce different valid paths for the same input. Such differences do not affect protocol interoperability, provided that the resulting relay path can be represented as an SRv6 path and installed consistently at the participating nodes.

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.

The framework may require one or more SRv6 extensions to identify a QKD trusted relay function or to associate an SRv6 SID with a local key-relay service.

The specific SRv6 endpoint behavior, SID format, signaling method, and processing rules are TBD.

7.2. UDP-Based Key Relay

The SRv6 packet carries a UDP datagram. The UDP payload carries the information required by the trusted key-relay process.

The UDP payload may need to contain information such as:

  • key-relay service identifier;
  • relay session identifier;
  • source and destination KME identifiers;
  • key identifier;
  • protected key material;
  • sequence information;
  • relay-hop information;
  • lifetime information;
  • acknowledgment indication; and
  • error information.

This list identifies functional requirements only. It does not define a wire format.

The UDP port, message types, field encoding, cryptographic container, and message-protection mechanism are TBD.

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. Verify that the packet belongs to an authorized key-relay service.
  2. Verify that the packet follows an installed and valid relay path.
  3. Deliver the UDP key-relay information to the local QKD relay or KME function.
  4. Process the received key information according to the trusted relay policy.
  5. Obtain any key material required to protect the next relay hop.
  6. Generate or update the UDP key-relay information for the next node.
  7. 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.

8. Protocol Extension Requirements

This section identifies the protocol areas that require extension. Only the extension objectives are defined. All detailed formats and procedures are TBD.

8.2. Node Trust Advertisement

A protocol extension is required to advertise the trust level and QKD relay capability of each node.

The extension SHOULD support:

  • node identification;
  • node trust level;
  • trust or assurance domain;
  • indication of trusted relay capability;
  • validity or freshness information; and
  • withdrawal or downgrade after a security event.

The protocol selected for carrying this information and the detailed extension format are TBD.

8.3. SRv6 Path Installation

A mechanism is required for the controller to install the calculated SRv6 path at the source and, when necessary, at the trusted relay nodes.

The mechanism SHOULD support:

  • installation of an ordered segment list;
  • association of the segment list with a QKD relay service;
  • activation and deactivation of a path;
  • replacement of an old path by a new path;
  • installation of a reverse or protection path when required; and
  • consistent lifecycle management of path and relay state.

The use of an existing SR Policy mechanism or another controller-to-device protocol is possible. The selected mechanism and any required extension are TBD.

8.4. SRv6 Service Identification

An SRv6 extension may be required to identify that a segment invokes a QKD trusted relay function.

The extension may be realized by a dedicated SRv6 endpoint behavior, a service SID, an argument carried in a SID, a policy association, or another SRv6 mechanism.

The selected mechanism, code point, SID structure, and processing behavior are TBD.

8.5. Key-Relay Context in SRv6 Packets

The key-relay packet may require non-secret context that is visible to the SRv6 and relay-processing functions.

Such context may include:

  • service identifier;
  • session identifier;
  • path identifier;
  • relay count;
  • minimum required trust level; and
  • processing flags.

The context may be carried in an SRH TLV, another IPv6 extension, the UDP payload, or local policy state.

The selected location, encoding, mutability rules, and protection method are TBD.

Key material itself SHOULD NOT be carried in an unprotected SRv6 or IPv6 header field.

8.6. UDP Key-Relay Message

A UDP-based protocol extension or new protocol is required to carry the key-relay information.

The protocol SHOULD support:

  • transfer of protected key material;
  • service and session identification;
  • source and destination identification;
  • sequencing and duplicate detection;
  • relay-hop processing;
  • lifetime control;
  • acknowledgment;
  • error reporting; and
  • cryptographic protection.

The UDP port, versioning model, common header, payload encoding, key-protection method, and algorithm negotiation are TBD.

8.7. Acknowledgment and Error Handling

A key-relay service may require confirmation that the destination has accepted the relayed key.

The framework therefore requires a mechanism for:

  • successful delivery acknowledgment;
  • relay-processing failure notification;
  • path or session mismatch notification;
  • insufficient QKD resource notification;
  • retransmission or status query; and
  • duplicate-safe delivery.

The message types, timers, retry rules, state machine, and error codes are TBD.

9. Operational Considerations

QKD link capacity and node trust information may change over time. A controller SHOULD use sufficiently fresh information when admitting a new key-relay service.

A controller SHOULD coordinate the following operations:

When the relay path changes, the controller SHOULD ensure that packets associated with the old path are not incorrectly processed on the new path.

The specific reservation, transaction, and make-before-break procedures are 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. A node trust level is a policy input and does not eliminate the inherent trusted-relay risk.
Integrity of Path-Computation Inputs
An attacker that changes QKRC 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.

11. Manageability Considerations

An implementation SHOULD provide management and telemetry for:

Management systems MUST NOT expose plaintext key material or QKD link keys in logs, telemetry, alarms, or diagnostic output.

The detailed YANG models, telemetry models, and management interfaces are TBD.

12. IANA Considerations

This document makes no IANA requests.

Future documents that define the protocol extensions identified in Section 8 may request allocations for SRv6 endpoint behaviors, SRH TLVs, routing-protocol TLVs, UDP service names or port numbers, message types, error codes, or other protocol parameters.

13. Normative References

[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/info/rfc2119>.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/info/rfc8174>.
[RFC8200]
Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, , <https://www.rfc-editor.org/info/rfc8200>.
[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, , <https://www.rfc-editor.org/info/rfc8754>.
[RFC8986]
Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer, D., Matsushima, S., and Z. Li, "Segment Routing over IPv6 (SRv6) Network Programming", RFC 8986, DOI 10.17487/RFC8986, , <https://www.rfc-editor.org/info/rfc8986>.

14. Informative References

[ETSI-QKD014]
ETSI, "Quantum Key Distribution (QKD); Protocol and data format of REST-based key delivery API", ETSI GS QKD 014.
[ITU-Y3800]
ITU-T, "Overview on networks supporting quantum key distribution", Recommendation Y.3800, .
[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, , <https://www.rfc-editor.org/info/rfc8402>.
[RFC9256]
Filsfils, C., Talaulikar, K., Ed., Voyer, D., Bogdanov, A., and P. Mattes, "Segment Routing Policy Architecture", RFC 9256, DOI 10.17487/RFC9256, , <https://www.rfc-editor.org/info/rfc9256>.

Appendix A. Example Service Procedure

This appendix provides a non-normative example.

Assume the following relay topology:

   Source S ---- Relay R1 ---- Relay R2 ---- Destination D
Figure 2: Example Relay Topology

Each QKD link reports its available quantum key rate capacity. R1 and R2 report their node trust levels.

An application requests a key-relay service from S to D with:

The controller performs the following actions:

  1. Collect the current QKD link capacity and node trust information.
  2. Invoke a path-computation algorithm selected by the user or operator.
  3. Select the ordered relay sequence S-R1-R2-D.
  4. Translate R1, R2, and D into an SRv6 segment list.
  5. Install the SRv6 path and any required relay state.
  6. Instruct S to send a UDP key-relay packet.
  7. R1 processes the key-relay information and forwards it toward R2.
  8. R2 processes the key-relay information and forwards it toward D.
  9. D accepts the delivered key information.
  10. D may send an acknowledgment to S.

The detailed routing-protocol extensions, SRv6 behavior, packet formats, state machine, and cryptographic processing are all TBD.

Authors' Addresses

Xinyu Chen
China Mobile
Liuyan Han
China Mobile
Longfei Dai
Huawei Technologies