ETSI GS QKD 015 V2.1.1 (2022-04)

Quantum Key Distribution (QKD); Control Interface for Software Defined Networks

RGS/QKD-015ed2_ContIntSDN

General Information

• Status: Not Published
• Technical Committee: QKD - Quantum Key Distribution
• Current Stage: 12 - Completion
• Due Date: 01-Apr-2022
• Completion Date: 07-Apr-2022

Standards Content (Sample)

ETSI GS QKD 015 V2.1.1 (2022-04)






GROUP SPECIFICATION
Quantum Key Distribution (QKD);
Control Interface for
Software Defined Networks
Disclaimer
The present document has been produced and approved by the Quantum Key Distribution (QKD) ETSI Industry Specification
Group (ISG) and represents the views of those members who participated in this ISG.
It does not necessarily represent the views of the entire ETSI membership.

---------------------- Page: 1 ----------------------
2 ETSI GS QKD 015 V2.1.1 (2022-04)

Reference
RGS/QKD-015ed2_ContIntSDN
Keywords
control interface, quantum cryptography, Quantum
Key Distribution, Software-Defined Networking

ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE

Tel.: [phone]  Fax: [phone]

Siret N° 348 623 562 00017 - APE 7112B
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° w061004871

Important notice
The present document can be downloaded from:
http://www.etsi.org/standards-search
The present document may be made available in electronic versions and/or in print. The content of any electronic and/or
print versions of the present document shall not be modified without the prior written authorization of ETSI. In case of any
existing or perceived difference in contents between such versions and/or in print, the prevailing version of an ETSI
deliverable is the one made publicly available in PDF format at www.etsi.org/deliver.
Users of the present document should be aware that the document may be subject to revision or change of status.
Information on the current status of this and other ETSI documents is available at
https://portal.etsi.org/TB/ETSIDeliverableStatus.aspx
If you find errors in the present document, please send your comment to one of the following services:
https://portal.etsi.org/People/CommiteeSupportStaff.aspx
If you find a security vulnerability in the present document, please report it through our
Coordinated Vulnerability Disclosure Program:
https://www.etsi.org/standards/coordinated-vulnerability-disclosure
Notice of disclaimer & limitation of liability
The information provided in the present deliverable is directed solely to professionals who have the appropriate degree of
experience to understand and interpret its content in accordance with generally accepted engineering or
other professional standard and applicable regulations.
No recommendation as to products and services or vendors is made or should be implied.
No representation or warranty is made that this deliverable is technically accurate or sufficient or conforms to any law
rule and/or regulation and further, no representation or warranty is made of merchantability or fitness
and/or governmental
for any particular purpose or against infringement of intellectual property rights.
In no event shall ETSI be held liable for loss of profits or any other incidental or consequential damages.

Any software contained in this deliverable is provided "AS IS" with no warranties, express or implied, including but not
limited to, the warranties of merchantability, fitness for a particular purpose and non-infringement of intellectual property
rights and ETSI shall not be held liable in any event for any damages whatsoever (including, without limitation, damages
for loss of profits, business interruption, loss of information, or any other pecuniary loss) arising out of or related to the use
of or inability to use the software.
Copyright Notification
No part may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying and
microfilm except as authorized by written permission of ETSI.
The content of the PDF version shall not be modified without the written authorization of ETSI.
The copyright and the foregoing restriction extend to reproduction in all media.

© ETSI 2022.
All rights reserved.

ETSI

---------------------- Page: 2 ----------------------
3 ETSI GS QKD 015 V2.1.1 (2022-04)
Contents
Intellectual Property Rights . 4
Foreword . 4
Modal verbs terminology . 4
Executive summary . 4
Introduction . 5
1 Scope . 6
2 References . 6
2.1 Normative references . 6
2.2 Informative references . 6
3 Definition of terms, symbols and abbreviations . 6
3.1 Terms . 6
3.2 Symbols . 7
3.3 Abbreviations . 7
4 Software-Defined Quantum Key Distribution. . 8
4.1 Introduction . 8
4.2 SD-QKD node . 8
4.3 SD-QKD node capabilities . 11
4.4 QKD Interfaces . 11
4.5 QKD Key Association Links . 12
4.6 QKD Applications . 13
4.7 Notifications . 15
5 Sequence Diagrams and Workflows . 15
5.1 Introduction . 15
5.2 QKD Application Registration . 16
5.3 QKD Physical (Direct) Link creation . 17
5.4 QKD Virtual Link creation . 18
6 Security considerations. 19
7 Protocol Considerations . 19
Annex A (normative): SD-QKD node YANG Model . 20
Annex B (informative): Bibliography . 21
Annex C (informative): Change History . 22
History . 23


ETSI

---------------------- Page: 3 ----------------------
4 ETSI GS QKD 015 V2.1.1 (2022-04)
Intellectual Property Rights
Essential patents
IPRs essential or potentially essential to normative deliverables may have been declared to ETSI. The declarations
pertaining to these essential IPRs, if any, are publicly available for ETSI members and non-members, and can be
found in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to
ETSI in respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the
ETSI Web server (https://ipr.etsi.org/).
Pursuant to the ETSI Directives including the ETSI IPR Policy, no investigation regarding the essentiality of IPRs,
including IPR searches, has been carried out by ETSI. No guarantee can be given as to the existence of other IPRs not
referenced in ETSI SR 000 314 (or the updates on the ETSI Web server) which are, or may be, or may become,
essential to the present document.
Trademarks
The present document may include trademarks and/or tradenames which are asserted and/or registered by their owners.
ETSI claims no ownership of these except for any which are indicated as being the property of ETSI, and conveys no
right to use or reproduce any trademark and/or tradename. Mention of those trademarks in the present document does
not constitute an endorsement by ETSI of products, services or organizations associated with those trademarks.
DECT™, PLUGTESTS™, UMTS™ and the ETSI logo are trademarks of ETSI registered for the benefit of its

Members. 3GPP™ and LTE™ are trademarks of ETSI registered for the benefit of its Members and of the 3GPP
Organizational Partners. oneM2M™ logo is a trademark of ETSI registered for the benefit of its Members and of the
®
oneM2M Partners. GSM and the GSM logo are trademarks registered and owned by the GSM Association.
Foreword
This Group Specification (GS) has been produced by ETSI Industry Specification Group (ISG) Quantum Key
Distribution (QKD).
Modal verbs terminology
In the present document "shall", "shall not", "should", "should not", "may", "need not", "will", "will not", "can" and
"cannot" are to be interpreted as described in clause 3.2 of the ETSI Drafting Rules (Verbal forms for the expression of
provisions).
"must" and "must not" are NOT allowed in ETSI deliverables except when used in direct citation.
Executive summary
The present document deals with the interface between an SDN-QKD node and an SDN controller. It describes the flow
of information between both entities. The SDN-QKD node part being embodied by an SDN-Agent that collects the
local node information. The information model is given in YANG [1] and [2], a language well suited and widely used
for these purposes. The information model is agnostic from the vendor and the implementation, permitting to control
any type of QKD systems whilst also enabling the centralized SDN controller to build an end-to-end view of the
network for managing and optimizing the transmission of quantum signals and also to deliver the QKD-derived keys.
ETSI

---------------------- Page: 4 ----------------------
5 ETSI GS QKD 015 V2.1.1 (2022-04)
Introduction
Quantum Key Distribution relies on the creation, transmission and detection of signals at the quantum level. This is
difficult to achieve if the network used for the transmission is also in use with classical signals, which are much more
powerful. On the other hand, the quantum transmission can be neither amplified nor regenerated - at least without
quantum repeaters, which are not feasible with current technology - implying a limited reach for quantum
communications and the need to resort to trusted repeaters to increase the distance. To optimize the transmission of
quantum signals together with classical communications - whether they share the same physical media or not - over a
network and manage the key relay required for longer distances, it is necessary to integrate the QKD systems such that
they can communicate with the network control and also receive commands from it. These network-aware QKD
systems have to be integrated at the physical level (e.g. to allocate spectrum for the quantum channel, dynamically
change the peer, or use a new optical path, etc.), but also logically connected to management architectures. To achieve
this integration, the required capabilities of the QKD devices have to be described to the network controller. YANG [1]
and [2] is the major modelling language used to describe network elements. Any new elements, services or capabilities
being defined usually come together with a YANG model for enabling a faster integration into management systems.
The purpose of the information model presented in the present document, regardless of the protocol chosen to
implement the control channel, is to simplify the management of the QKD resources by implementing an abstraction
layer described in YANG. This will allow to optimize the creation and usage of the QKD-derived keys by introducing a
central element through the SDN controller. This is a standard component of SDN networks that has a global view of
the whole network. This abstraction layer will enable the SDN controller to simultaneously manage both the classical
and quantum parts of the network. The integration has the added benefit of using well-known mechanisms and tools in
the classical community, which will facilitate its adoption and deployment by the telecommunications world.

ETSI

---------------------- Page: 5 ----------------------
6 ETSI GS QKD 015 V2.1.1 (2022-04)
1 Scope
The present document provides a definition of management interfaces for the integration of QKD in disaggregated
network control plane architectures, in particular with Software-Defined Networking (SDN). It defines abstraction
models and workflows between an SDN-enabled QKD node and the SDN controller, including resource discovery,
capabilities dissemination and system configuration operations. Application layer interfaces and quantum-channel
interfaces are out of scope.
2 References
2.1 Normative references
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the
referenced document (including any amendments) applies.
Referenced documents which are not found to be publicly available in the expected location might be found at
https://docbox.etsi.org/Reference.
NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee
their long term validity.
The following referenced documents are necessary for the application of the present document.
[1] IETF RFC 6020 (October 2010): "YANG - A Data Modeling Language for the Network
Configuration Protocol (NETCONF)".
[2] IETF RFC 7950 (August 2016): "The YANG 1.1 Data Modeling Language".
[3] IETF RFC 6241 (June 2011): "Network Configuration Protocol (NETCONF)".
[4] IETF RFC 8040 (January 2017): "RESTCONF Protocol".
2.2 Informative references
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the
referenced document (including any amendments) applies.
NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee
their long term validity.
The following referenced documents are not necessary for the application of the present document but they assist the
user with regard to a particular subject area.
[i.1] ETSI GR QKD 007: "Quantum Key Distribution (QKD); Vocabulary".
3 Definition of terms, symbols and abbreviations
3.1 Terms
For the purposes of the present document, the following terms apply:
NOTE: Where possible, the definitions from ETSI GR QKD 007 [i.1] are used.
entity: set of hardware, software or firmware components providing specific functionalities
ETSI

---------------------- Page: 6 ----------------------
7 ETSI GS QKD 015 V2.1.1 (2022-04)
QKD application: entity consuming QKD-derived keys from the key management system
NOTE: They can be either external applications (similar to SAE, see below) or internal applications running in
the QKD system.
QKD-derived key: secret key derived from QKD system(s) operating QKD protocol(s) over a QKD link
QKD interface: interface that is a high-level abstraction of a QKD system
NOTE: A QKD interface defines only attributes that are relevant from the point of view of the network. These
attributes are revealed to an SDN controller to establish and manage QKD.
QKD link: set of active and/or passive components that connect a pair of QKD modules to enable them to perform
QKD and where the security of symmetric keys established does not depend on the link components under any of the
one or more QKD protocols executed
QKD module: set of hardware, software or firmware components that implements part of one or more QKD protocol(s)
to be capable of securely agreeing symmetric keys with at least one other QKD module
QKD network: network comprised of two or more QKD nodes
QKD node: set of QKD modules installed in the same location within the same security perimeter
QKD protocol: operations on quantum and classical signals that allow two parties to agree on commonly shared bit
strings between two ends of a QKD link that remain secret
QKD system: pair of QKD modules connected by a QKD link designed to provide Quantum Key Distribution
functionality using QKD protocols
quantum channel: communication channel for transmitting quantum signals
Quantum Key Distribution (QKD): procedure involving the transport of quantum states to establish symmetric keys
between remote parties using a protocol with security based on quantum entanglement or the impossibility of perfectly
cloning the transported quantum states
SDN agent: entity that is responsible for managing one or more QKD Systems (through their respective QKD
interfaces) within a secure location, abstracting the information of QKD resources under its control and communicating
with an SDN controller for the QKD network
SD-QKD node: logical and abstracted representation of the QKD resources under the responsibility of a single SDN
Agent
Secure Application Entity (SAE): entity that requests one or more keys from a Key Management System for one or
more applications running in cooperation with one or more other Secure Application Entities
secure location: location assumed to be secured against access by adversaries
3.2 Symbols
Void.
3.3 Abbreviations
For the purposes of the present document, the following abbreviations apply:
ACK Acknowledgement
API Application Programming Interface
CRUD Create, Read, Update and Delete
DoS Denial of Service
HSM Hardware Security Module
HTTP HyperText Transfer Protocol
ID IDentifier
IETF International Engineering Task Force
ETSI

---------------------- Page: 7 ----------------------
8 ETSI GS QKD 015 V2.1.1 (2022-04)
IP Internet Protocol
JSON JavaScript Object Notation
NBI North Bound Interface
NMS Network Management System
PHYS Physical link
QBER Quantum Bit Error Rate
QKD Quantum Key Distribution
QoS Quality of Service
REST REpresentational State Transfer
RFC Request For Comments
SAE Secure Application Entity
SDN Software-Defined Networking
SD-ONC Software-Defined Optical Network Controller
SD-QKD Software-Defined Quantum Key Distribution
SD-QNC Software-Defined Quantum Network Controller
SKR Secure Key generation Rate
SSH Secure Shell
TLS Transport Layer Security
URI Uniform Resource Identifier
URL Uniform Resource Locator
UUID Universally Unique Identifier
XML Extensible Markup Language
YANG Yet Another Next Generation
4 Software-Defined Quantum Key Distribution
4.1 Introduction
The parametrization and modelling defined in the present document relate to the management interface of QKD
modules (one or multiple) that connects them to an SDN controller. The requirements for such an interface and the
further integration is described as a YANG model and as associated workflows for the main functional use cases (see
Annex A). This architectural design permits a controller to centrally orchestrate the QKD resources to optimize the key
allocation per link based on demands and automate the creation of either direct (physically connected through an
uninterrupted quantum channel) or virtual (multi-hop-based) QKD links, where the keys are relayed from one hop
(direct QKD link) to the next in the chain connecting the initial with the final points. The workflows described in
Annex A are thought to be implemented by using any of the well-accepted network management protocols used in SDN
architectures, which are based on YANG information models for their internal data structures. However, it is out of the
scope of the present document to define which specific protocol, data structures or specific implementation is chosen to
carry the YANG-structured information defined in the present document. These specifics are left aside to permit some
flexibility during the system design and implementation phases.
In addition, this YANG model is designed to be a base or core model for the integration of QKD technologies in
operator's management architectures. However, it is not closed for experimentation and further extensions, as YANG
provides such flexibility to easily integrate new capabilities inside a given model. Future revisions of the present
document may include additional parameters.
4.2 SD-QKD node
A Software-Defined Quantum Key Distribution (SD-QKD) node is an aggregation of one or multiple QKD modules
that interface with an SDN controller using standard protocols (i.e. it is SDN-enabled). The connection between node
and controller allows information to be retrieved from the QKD domain and dynamically and remotely configure the
behaviour of the QKD systems to create, remove or update key associations (either through a quantum channel or via
multi-hop) between remote secure locations. An SD-QKD node shall be compliant with some specific requirements:
• An SD-QKD node shall comprise at least one QKD module, exposed to the controller as a QKD interface.
• It may comprise multiple QKD modules, creating an abstraction of a single node with multiple interfaces.
ETSI

---------------------- Page: 8 ----------------------
9 ETSI GS QKD 015 V2.1.1 (2022-04)
• It shall be located within a secure location.
• A single location may comprise one or multiple SD-QKD nodes.
• An SD-QKD node shall contain a key management system aggregating the key material from the different key
associations. The key management system may be implemented using multiple logical key stores to
distinguish groups of applications.
• It shall provide a single access for applications to retrieve keys from the key store via an API.
• It shall connect to (at least) one SDN controller via standard protocols and mechanisms to enable discovery,
control and telemetry and statistics streaming.
• It should expose applications information to the controller for discovery purposes and to better optimize the
utilization of QKD keys.
• It should expose QKD interfaces with QKD system information to the SDN controller and allow to configure
some parameters of the systems to create the quantum channel.
• It should expose information of the key associations (links) with other SD-QKD systems.
• It should expose the classical channel requirements for each of the systems within the node (e.g. attenuation
and supported wavelengths).
The modelling defined in the following clauses provides an abstracted view of the QKD domain. It can abstract the
QKD systems within a secure location as interfaces of a network element. This network element, the SD-QKD node, is
able to communicate with its neighbours and with the central controller to create end-to-end services or key
associations. When possible (enough QKD systems, reachability over the physical media), these associations are created
over a direct quantum channel. In other cases, a multi-hop link or key association is created, granting a fully connected
QKD network. Also, the information exchanged across the control plane is not critical (e.g. keys are not forwarded to
the controller). Therefore, introducing the SDN paradigm for QKD networks should not imply any further security risks
from the already known in trusted node QKD networks (e.g. DoS attacks). In particular, this abstraction model aims to:
• Enable centralized management of the QKD resources based on demands, capabilities and network (quantum
and classical) status.
• Aggregate different QKD systems within a secure perimeter under a single key management to better detect
demands and provision the necessary links or key associations.
• Reduce the complexity of operating all the QKD modules separately within a secure location and handling
statistics from the QKD systems.
• Abstract the complexity of managing low-level parameters and behaviour of each QKD system and
technology, as each node can take the responsibility of low-level configurations.
• Optimize the configuration and the distribution of QKD links in the QKD network to cope with all demands,
based on the application's QoS information and generation rate statistics of each link.
• Coordinate quantum and classical channels (the configuration of the optical network), whether they share the
same physical media or not, to enhance the performance of the QKD systems.
ETSI

---------------------- Page: 9 ----------------------
10 ETSI GS QKD 015 V2.1.1 (2022-04)

NOTE: The SD-QKD Nodes are connected among them (solid lines) and with the SDN controller (dashed lines).
One of the nodes is detailed to show a typical set of components and the type of information that flows
among them. In particular, the SDN Agent that connects the node with the SDN controller is shown. The
present document deals with this connection. See the text for additional information.

Figure 1: Depiction of an SD-QKD network showing a set of SD-QKD nodes
Figure 1 shows, in a high-level design, an SD-QKD network as a set of connected nodes under the control of the SDN
controller. One of the nodes is shown in more detail with the fundamental components which are required to build an
SD-QKD node in order to illustrate the typical flow of information between components. Note that the figure is for
illustrative purposes and does not imply a mandatory node structure. The Applications are included as part of the node
to illustrate that they are contained in the same security perimeter. At the hardware level, the SD-QKD system shall
comprise at least one QKD module (in the example figure, there are three modules). These modules are used to
physically connect the SD-QKD node to other remote peers through a quantum link, composing a QKD system for key
generation purposes (note that the scheme can be easily extended to include other services allowed by the quantum
device, like entanglement distribution). The generated keys are pushed (or extracted) to a key management system,
which is responsible for maintaining and distributing them. The key management system registers incoming
applications and their QoS and monitors the real demands of each of them. It also exposes the parameters needed to
monitor the utilization of the QKD-derived keys for each link. This information allows optimizing the planning of the
QKD network.
The following clauses describe the different data structures (YANG grouping) to be handled by the SD-QKD node and
the SDN controller. The YANG data model for the SD-QKD node is divided into four main structures (groupings):
SD-QKD node capabilities, QKD applications, QKD links (or key associations) and QKD interfaces (or systems). In
addition, YANG notifications are also included for a server (node) to client (controller) communications.
Table 1: Parameters of SD-QKD node
Name Type Details Description
qkdn_id ietf_yang_types:uuid None This value reflects the unique ID of the SD-QKD
node.
qkdn_status etsi-qkdn-types: Config false Status of the SD-QKD node.
qkdn-status-types
qkdn_version string None Hardware or software version of the SD-QKD
node.
qkdn_location_id string Default: "" This value enables the location of the secure
area that contains the SD-QKD node to be
specified.

ETSI

---------------------- Page: 10 ----------------------
11 ETSI GS QKD 015 V2.1.1 (202
...