Problem Statement and Operational Considerations for QKD-Assisted SRv6 Private Line Services
draft-pang-srv6ops-qkd-srv6-private-line-00

srv6ops                                                          R. Pang
Internet-Draft                                                     J. Li
Intended status: Informational                                   J. Zhao
Expires: 6 January 2027                                     China Unicom
                                                             5 July 2026

 Problem Statement and Operational Considerations for QKD-Assisted SRv6
                         Private Line Services
              draft-pang-srv6ops-qkd-srv6-private-line-00

Abstract

   SRv6 is used by operators to provide programmable and traffic-
   engineered IP private line services.  Such services are often
   deployed for customers with strict requirements on service isolation,
   predictable forwarding, and communication security.

   Quantum Key Distribution (QKD) networks can provide symmetric key
   material to authorized applications or security functions.  When QKD-
   generated keys are used together with SRv6-based private line
   services, operators need to coordinate service provisioning, SRv6
   policy state, endpoint security functions, and QKD key availability.

   This document describes the problem space and operational
   considerations for QKD-assisted SRv6 private line services.  It does
   not define new SRv6 data-plane behavior, new SRv6 Segment Identifier
   semantics, a new QKD protocol, or a new cryptographic algorithm.

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

Pang, et al.             Expires 6 January 2027                 [Page 1]
Internet-Draft       QKD-Assisted SRv6 Private Line            July 2026

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  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Requirements Language . . . . . . . . . . . . . . . . . . . .   3
   3.  Problem Statement . . . . . . . . . . . . . . . . . . . . . .   3
     3.1.  Service-to-Key Association  . . . . . . . . . . . . . . .   3
     3.2.  Coordination of SRv6 Path State and QKD Key State . . . .   4
     3.3.  Key Availability and Service Assurance  . . . . . . . . .   4
     3.4.  Failure and Degradation Handling  . . . . . . . . . . . .   4
     3.5.  Telemetry and Troubleshooting . . . . . . . . . . . . . .   5
   4.  Operational Considerations  . . . . . . . . . . . . . . . . .   5
     4.1.  Avoiding SRv6 Data-Plane Dependency . . . . . . . . . . .   5
     4.2.  Endpoint-Based Security Functions . . . . . . . . . . . .   6
     4.3.  Service Provisioning  . . . . . . . . . . . . . . . . . .   6
     4.4.  Rekeying  . . . . . . . . . . . . . . . . . . . . . . . .   6
     4.5.  Degradation and Fallback Policy . . . . . . . . . . . . .   7
     4.6.  Multi-Domain Deployment . . . . . . . . . . . . . . . . .   7
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .   8
     7.2.  Informative References  . . . . . . . . . . . . . . . . .   8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   9

1.  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.

Pang, et al.             Expires 6 January 2027                 [Page 2]
Internet-Draft       QKD-Assisted SRv6 Private Line            July 2026

   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.

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

3.  Problem Statement

3.1.  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.

Pang, et al.             Expires 6 January 2027                 [Page 3]
Internet-Draft       QKD-Assisted SRv6 Private Line            July 2026

3.2.  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.

3.3.  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.

3.4.  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.

Pang, et al.             Expires 6 January 2027                 [Page 4]
Internet-Draft       QKD-Assisted SRv6 Private Line            July 2026

   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.

3.5.  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.

4.  Operational Considerations

4.1.  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.

Pang, et al.             Expires 6 January 2027                 [Page 5]
Internet-Draft       QKD-Assisted SRv6 Private Line            July 2026

   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.

4.2.  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.

4.3.  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.

4.4.  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.

Pang, et al.             Expires 6 January 2027                 [Page 6]
Internet-Draft       QKD-Assisted SRv6 Private Line            July 2026

4.5.  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.

4.6.  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.

5.  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.

Pang, et al.             Expires 6 January 2027                 [Page 7]
Internet-Draft       QKD-Assisted SRv6 Private Line            July 2026

   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.

6.  IANA Considerations

   This document makes no request of IANA.

7.  References

7.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <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,
              May 2017, <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, July 2017,
              <https://www.rfc-editor.org/info/rfc8200>.

   [RFC8305]  Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2:
              Better Connectivity Using Concurrency", RFC 8305,
              DOI 10.17487/RFC8305, December 2017,
              <https://www.rfc-editor.org/info/rfc8305>.

7.2.  Informative References

   [RFC9386]  Fioccola, G., Volpato, P., Palet Martinez, J., Mishra, G.,
              and C. Xie, "IPv6 Deployment Status", RFC 9386,
              DOI 10.17487/RFC9386, April 2023,
              <https://www.rfc-editor.org/info/rfc9386>.

   [RFC9099]  Vyncke, É., Chittimaneni, K., Kaeo, M., and E. Rey,
              "Operational Security Considerations for IPv6 Networks",
              RFC 9099, DOI 10.17487/RFC9099, August 2021,
              <https://www.rfc-editor.org/info/rfc9099>.

Pang, et al.             Expires 6 January 2027                 [Page 8]
Internet-Draft       QKD-Assisted SRv6 Private Line            July 2026

Authors' Addresses

   Ran Pang
   China Unicom
   Beijing
   China
   Email: pangran@chinaunicom.cn

   Jianfei Li
   China Unicom
   Beijing
   China
   Email: lijf299@chinaunicom.cn

   Jing Zhao
   China Unicom
   Beijing
   China
   Email: zhaoj501@chinaunicom.cn

Pang, et al.             Expires 6 January 2027                 [Page 9]