<?xml version="1.0" encoding="utf-8"?>
<!-- name="GENERATOR" content="github.com/mmarkdown/mmark Mmark Markdown Processor - mmark.miek.nl" -->
<rfc version="3" ipr="trust200902" docName="draft-danet-qkdn-considerations-00" submissionType="IETF" category="info" xml:lang="en" xmlns:xi="http://www.w3.org/2001/XInclude" indexInclude="true">

<front>
<title abbrev="InitConQKDNProto">Initial Considerations about QDKN Protocols</title><seriesInfo value="draft-danet-qkdn-considerations-00" stream="IETF" status="informational" name="I-D"></seriesInfo>
<author initials="M." surname="Stiemerling" fullname="Martin Stiemerling"><organization>Darmstadt University of Applied Sciences</organization><address><postal><street></street>
</postal><email>mls.ietf@gmail.com</email>
<uri>https://danet.h-da.io</uri>
</address></author><author initials="F." surname="Seidl" fullname="Fabian Seidl"><organization>Darmstadt University of Applied Sciences</organization><address><postal><street></street>
</postal><email>fabian.seidl@h-da.de</email>
<uri>https://danet.h-da.io</uri>
</address></author><author initials="M." surname="Bauch" fullname="Malte Bauch"><organization>Darmstadt University of Applied Sciences</organization><address><postal><street></street>
</postal><email>malte.bauch@h-da.de</email>
<uri>https://danet.h-da.io</uri>
</address></author><author initials="N." surname="Schark" fullname="Neil Schark"><organization>Darmstadt University of Applied Sciences</organization><address><postal><street></street>
</postal><email>neil.schark@h-da.de</email>
<uri>https://danet.h-da.io</uri>
</address></author><author initials="J." surname="Henrich" fullname="Johanna Henrich"><organization>Darmstadt University of Applied Sciences</organization><address><postal><street></street>
</postal><email>johanna.henrich@h-da.de</email>
<uri>https://ucs.h-da.io</uri>
</address></author><date/>
<area>Internet</area>
<workgroup>Network Working Group</workgroup>
<keyword>QKDN</keyword>

<abstract>
<t>Quantum communication modules connected via a link, either via fiber or free-space
communications, have been used since a while to distribute random
numbers as secure keys, but there are other use cases, such as time
synchronization.</t>
<t>By today, a number of research and industrial efforts are underway to built
complete networks, primary for secure key distribution, i.e., so-called Quantum
Key Distribution Networks (QKDN).</t>
<t>This memo briefly explores the space of QKDNs and identifies spots
of potentials interest to develop standardized protocols specific for such
networks.</t>
</abstract>

</front>

<middle>

<section anchor="introduction"><name>Introduction</name>
<t>Quantum communication modules connected via a link, either via fiber or free-space
communications, have been used since a while <xref target="darpa-qkd"></xref> to distribute random
numbers as secure keys, but there also other use cases, such as time
synchronization.</t>
<t>By today, a number of research and industrial efforts are underway to built
complete networks, primary for secure key distribution, i.e., so-called Quantum
Key Distribution Networks (QKDN) (see <xref target="qkd-overview"></xref> as one overview).</t>
<t>Quantum Links (QL) are quite limited in their distance between two adjacent
Quantum Communication Modules (QCM), e.g., around 100 km distance or even below. To overcome
this limitation, multiple segments of Quantum Links are concatenated. This
concatenation typically requires an extra level of functionality, i.e.,
the use of Key Management Systems (KMS).</t>
<t>This memo briefly explores the space of QKDNs and identifies spots
of potentials interest to develop standardized protocols specific for such
networks.</t>
</section>

<section anchor="simplified-architecture"><name>Simplified Architecture</name>
<t>The ITU defines an extensive QKDN architecture in Y.3802 <xref target="itu-y-3802"></xref>.
However, for our discussion we use a simplified architecture here.</t>
<t>The Figure below shows a simplified architecture for a single QKDN
domain.</t>
<t>The Quantum Communication Modules (QCM) are in charge of exchanging random
numbers between 2 QCM, or n modules for single-source entangled based
systems.</t>
<t>The Key Management Systems (KMS) are in charge of allowing a secure end-to-end
relay of a secret across the whole domain. They obtain the encryption keys, or
some initial input to the encryption key, from their local KMS.</t>
<t>The Network Controller (NW cntrl) can be used to control and managed the
operations of the KMS and also the QCM.</t>
<figure><name>A simplified single Domain QKDN Architecture
</name>
<sourcecode type="ascii-art"><![CDATA[
          (d)    +-------------+    (d)
      +----------|  NW cntrl   |----------+
      |          +-------------+          |
      |                 | (d)             |
      v                 v                 v
   +-----+  (a)  +-------------+  (a)  +-----+
   | KMS |<----->|     KMS     |<----->| KMS |
   +-----+       +-------------+       +-----+
      ^             ^       ^             ^
      | (b)         |  (b)  |             | (b)
      v             v       v             v
   +-----+  (c)  +-----+ +-----+  (c)  +-----+
   | QCM |<----->| QCM | | QCM |<----->| QCM |
   +-----+       +-----+ +-----+       +-----+
]]></sourcecode>
</figure>
<t>The interfaces between the components are:</t>

<ul>
<li><t>(a) KMS-to-KMS interface: this interface is used to facilitate the secure key forwarding between the KMS</t>
</li>
<li><t>(b) KMS-to-QCM interface: this interface is used by the KMS to obtain the generated random numbers from the QCM</t>
</li>
<li><t>(c) QCM-to-QCM interface: this interface is used between adjacent Quantum Communication Modules and consists actually out of two interfaces, i.e., the quantum link and the classical channel.</t>
</li>
<li><t>(d) Network Controller to KMS interface: This interface, if a controller-based approach is used, controls the operation of the KMS.</t>
</li>
</ul>
</section>

<section anchor="conclusion"><name>Conclusion</name>
<t>This document does not yet have a conclusion, at it is a first attempt to
gather information about protocols for QDKNS.</t>
</section>

<section anchor="iana-considerations"><name>IANA Considerations</name>
<t>This document has no IANA actions.</t>
</section>

<section anchor="security-considerations"><name>Security Considerations</name>
<t>This document has no security considerations yet, but since the whole sense of a QDKN is to securely, i.e., secured against eavesdropping, tampering, and replay attacks, forward a key from end-to-end, security is a matter per se. Future revisions of this memo will discuss the security considerations.</t>
</section>

</middle>

<back>
<references><name>Informative References</name>
<reference anchor="darpa-qkd" target="https://apps.dtic.mil/sti/pdfs/ADA471450.pdf">
  <front>
    <title>DARPA Quantum Network Testbed</title>
    <author fullname="Chip Elliott" initials="C." surname="Elliott"></author>
    <author fullname="Henry Yeh" initials="H." surname="Yeh"></author>
    <date year="2007" month="July"></date>
  </front>
</reference>
<reference anchor="itu-y-3802" target="https://www.itu.int/rec/T-REC-Y.3802-202012-I/en">
  <front>
    <title>Quantum key distribution networks – Functional&#xA;architecture</title>
    <author fullname="ITU-T" surname="ITU-T"></author>
    <date year="2020" month="December"></date>
  </front>
</reference>
<reference anchor="qkd-overview" target="https://doi.org/10.1049/qtc2.12044">
  <front>
    <title>Towards the industrialisation of quantum key distribution in communication networks: A short survey</title>
    <author fullname="Ruiqi Lui et al" initials="R." surname="Liu"></author>
    <date year="2022" month="September"></date>
  </front>
</reference>
</references>

<section anchor="acknowledgements" numbered="false"><name>Acknowledgements</name>
<t>Malte Bauch, Neil Schark and Fabian Seidl are funded by the German BMBF DemoQuanDT project. Martin Stiemerling is partially funded by the German BMBF DemoQuanDT project.</t>
</section>

</back>

</rfc>
