Problem Statement and Operational Considerations for QKD-Assisted SRv6 Private Line Services

Introduction Segment Routing over IPv6 (SRv6) enables operators to steer traffic through explicit paths and to support service-aware forwarding. SRv6-based IP private line services are used in scenarios such as enterprise connectivity, government networks, financial services, industrial networks, and cloud interconnection. In these scenarios, encryption or authentication may be applied at customer edge devices, provider edge devices, gateways, or other service endpoints. These security functions require key material and key lifecycle management. QKD networks can provide symmetric keys to authorized key-consuming entities. However, QKD key availability is not independent from network operation. It may be affected by QKD link status, key generation rate, key pool level, trusted relay availability, key consumption rate, and security policy. When SRv6 private line services consume QKD-generated keys, the SRv6 service domain and the QKD key service domain need to be coordinated. A service may have a valid SRv6 path but insufficient QKD key resources. Conversely, QKD keys may be available, but not usable by the endpoints or service instance selected by the SRv6 service controller. This document identifies the main operational problems that need to be understood before detailed solution work is considered.

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 .[FC8174] when, and only when, they appear in all capitals, as shown here.

Problem Statement

Service-to-Key Association An SRv6 private line service is typically described by service endpoints, bandwidth, latency, availability, path constraints, and isolation requirements. A QKD key service is typically described by key availability, key identifiers, key pool status, key lifetime, and endpoint authorization. There is currently no common operational model that describes how an SRv6 private line service should be associated with QKD-provided key material. The main issue is not only how a key is delivered. Operators also need to know which service instance, endpoint pair, security function, and key resource belong together.

Coordination of SRv6 Path State and QKD Key State SRv6 path state and QKD key state may change independently. For example, an SRv6 policy may change because of traffic engineering, failure recovery, or maintenance. A QKD key service may change because of key expiration, key pool depletion, QKD link degradation, or policy changes. If these changes are not coordinated, a service may remain reachable from a forwarding perspective but may no longer have the expected key resources. Alternatively, a service may have available keys but may not be using the intended path, endpoint, or security policy. Operators need a way to correlate SRv6 service state and QKD key state for provisioning, monitoring, and troubleshooting.

Key Availability and Service Assurance QKD-generated keys are a resource with capacity and lifecycle constraints. For SRv6 private line services, operators need to understand whether sufficient key resources are available for a requested service. The following core questions must be addressed:

Whether QKD key resources are available before service activation;
Whether key resources remain sufficient during service operation;
How key exhaustion or QKD degradation affects the service;
How rekeying events are coordinated with service continuity;
How service status is reported when forwarding is normal but key resources are degraded.

Without such coordination, the service assurance system may report incomplete or misleading information.

Failure and Degradation Handling SRv6 networks and QKD networks have different failure modes. SRv6 failures may include link failure, node failure, or policy invalidation. QKD-related failures may include QKD link degradation, key generation rate reduction, key pool exhaustion, or key synchronization failure. Operators need clear policies for how a QKD-assisted SRv6 private line service behaves under such conditions. Possible policies may include alarm-only operation, service degradation, rerouting, fallback to other keying mechanisms, or service blocking. This document does not recommend one policy for all deployments. The appropriate behavior depends on operator policy, customer requirement, and regulatory environment.

Telemetry and Troubleshooting Existing SRv6 OAM and telemetry can provide information about forwarding paths and service performance. QKD management systems can provide information about QKD links, key generation, key pool status, and alarms. For QKD-assisted SRv6 private line services, operators need a correlated view. It should be possible to determine whether a specific private line service is both reachable and operating with the expected security resources. At a high level, the following information may need to be integrated:

Service identifier and Endpoint pair;
SRv6 policy or path information;
Security function status;
Key availability or key service status;
Rekeying state with associated alarms and degradation events.

The problem is not the absence of telemetry in each individual domain, but the lack of an integrated operational view across the SRv6 service domain and the QKD key service domain.

Operational Considerations

Avoiding SRv6 Data-Plane Dependency A QKD-assisted SRv6 private line service should not assume that QKD-specific information has to be carried in SRv6 packets. In particular, key material must not be carried in SRv6 packets. Key identifiers, security association identifiers, or other security metadata may also be sensitive and should not be exposed unless there is a clear requirement and adequate protection. A conservative deployment model is to keep QKD-related state in the management plane, control plane, or endpoint security functions, while SRv6 continues to provide packet forwarding and path steering.

Endpoint-Based Security Functions In many deployments, encryption and authentication are applied at service endpoints, such as customer edge devices, provider edge devices, or security gateways. Intermediate SRv6 routers should not be required to understand QKD key state. This reduces deployment complexity and avoids unnecessary changes to the SRv6 forwarding plane.

Service Provisioning When a QKD-assisted SRv6 private line service is provisioned, operators must strictly verify both forwarding resources and key resources in a coordinated sequence.

whether the SRv6 path or policy can be established;
whether the service endpoints are authorized to consume QKD keys;
whether sufficient key resources are available;
whether endpoint security functions are ready;
whether service assurance systems can monitor both forwarding and key status.

The service should not be considered fully operational until both the SRv6 service state and the required security state are completely available.

Rekeying QKD-generated keys may be refreshed based on time, consumption, policy, or security events. Rekeying should be coordinated with endpoint security functions so that service disruption is avoided. The SRv6 forwarding path does not necessarily need to change when a key is refreshed. A stable service association is therefore useful, so that the service can continue while underlying key material changes according to policy.

Degradation and Fallback Policy Fallback behavior is deployment-specific and security-sensitive. For some services, fallback to non-QKD keying mechanisms may be acceptable. For other services, fallback may violate the customer’s security policy. In some cases, the correct behavior may be to raise an alarm or block service activation. Operators should define the fallback policy clearly and expose the resulting service status to service management systems and, where appropriate, to customers.

Multi-Domain Deployment SRv6 private line services and QKD networks may span multiple administrative domains. In such cases, operators need to consider:

how endpoint authorization is performed;
which domain provides the QKD key service;
how QKD coverage is represented when only part of the service path is supported;
how alarms and audit information are exchanged;
how customer-facing service status is reported.

This document does not define inter-domain procedures, but identifies multi-domain coordination as an important operational issue.

Security Considerations This document does not define a protocol. However, security considerations are central to the problem space. QKD-generated keys do not by themselves secure an SRv6 private line service. Overall service security also depends on endpoint authentication, authorization, key delivery protection, cryptographic protocol design, implementation security, and operational policy. Key material must not be exposed in SRv6 packets. Sensitive key metadata should also be protected from unnecessary disclosure. Fallback behavior needs careful treatment. If a service falls back from QKD-assisted keying to another keying mechanism, the resulting security level should be clear to the operator and, where applicable, to the customer. Telemetry and audit data may reveal customer endpoints, service relationships, security status, and failure events. Access to such information should be controlled.

IANA Considerations This document makes no request of IANA.