1

Hybrid Conventional and Quantum Security forSoftware Defined and Virtualized Networks

Alejandro Aguado, Victor Lopez, Jesus Martinez-Mateo, Thomas Szyrkowiec, Achim Autenrieth, Momtchil Peev,Diego Lopez and Vicente Martin

Abstract—Today’s networks are quickly evolving towards moredynamic and flexible infrastructures and architectures. Thissoftware-based evolution has seen its peak with the developmentof software-defined networking (SDN) and network functionsvirtualization (NFV) paradigms. These new concepts allow op-erators to automate the setup of services, reducing costs indeploying and operating the required infrastructure. On theother hand, these novel paradigms expose new vulnerabilities,as critical information travels through the infrastructure fromcentral offices, down to remote data centers and network devices.Quantum key distribution (QKD) is a state of the art technologythat can be seen as a source of symmetric keys in two separateddomains. It is immune to any algorithmic cryptanalysis, thussuitable for long term security. This technology is based onthe laws of physics, that forbid to copy the quantum statesexchanged between two endpoints from which a secret key canbe extracted. Thus, even though it has some limitations, a correctimplementation can deliver keys of the highest security. In thispaper, we propose the integration of QKD systems with well-known protocols and methodologies to secure the network’scontrol plane in an SDN and NFV environment. Furthermore,we experimentally demonstrate a workflow where QKD keysare used together with classically generated keys to encryptcommunications between cloud and SDN platforms for settingup a service via secure shell (SSH), while showcasing theapplicability to other cryptographic protocols.

Index Terms—Quantum Key Distribution, Software DefinedNetworks, Network Functions Virtualization

I. INTRODUCTION

The nature of today’s network services has changed drasti-cally, moving from a monolithic vision, where services weremanually and statically configured across the infrastructure,towards a more flexible approach. Achieving such level offlexibility on traditional networks requires a software-basedevolution, where network devices are managed from remoteoffices, while some other devices are even physically replaced

This work has been partially supported by the Spanish Ministry of Economyand Competitiveness, MINECO under grant CVQuCo, TEC2015-70406-R,and by ACINO European H2020 project, http://www.acino.eu, grant number645127.

A. Aguado, J. Martinez-Mateo and V. Martin are with Center for Computa-tional Simulation, Universidad Politecnica de Madrid, Campus Montegancedo,28660 Boadilla del Monte, Madrid, Spain (e-mail: a.aguadom@fi.upm.es,jmartinez@fi.upm.es, vicente@fi.upm.es).

V. Lopez and D. Lopez are with Telefonica GCTO, Ronda de la Comuni-cacion s/n 28050 Madrid, Spain (e-mail: victor.lopezalvarez@telefonica.com,diego.r.lopez@telefonica.com).

T. Szyrkowiec and A. Autenrieth are with the ADVA Optical Networking,Munich 82152, Germany (e-mail: tszyrkowiec@advaoptical.com; aautenri-eth@advaoptical.com).

M. Peev is with Huawei Technologies Duesseldorf GmbH, Riesstrasse 25,80992 Munchen, Germany (e-mail: momtchil.peev@huawei.com).

by software running in a distributed computing infrastructure.These new network paradigms, so called software-definednetworking (SDN) [1] and network functions virtualization(NFV) [2], reduce substantially the costs and the deploymenttime for both, setting up and operating the infrastructure toprovide services to end users. However, these novel networkparadigms use processes that have to communicate remotelyand are implemented in commodity platforms. This makesthem more vulnerable to different types of attacks [3], [4].In particular, certain sensitive information (e.g., entire virtualnetwork functions, VNFs, configuration messages or files,etc.) must be securely transferred from central offices toremote data centers and network devices. Securing this type ofcritical infrastructures is extremely important, as the undesireddisclosure or modification of any control plane informationcan compromise the entire infrastructure, affecting in differentways important data traversing the network.

Quantum key distribution (QKD) is a suitable technologyfor securing network infrastructures [5]. It can be regarded astwo sources of synchronized random numbers that are sepa-rated in space, which communicate using qubit1 transmissions—usually embodied in single photons— over a physical chan-nel (fiber or free space). The security of the symmetric keysproduced by systems built around this technology is rootedin the physical layer, offering a distinct protection over themore traditional, algorithm based, security mechanisms. Theyare immune, by principle, to any algorithmic cryptanalysis.Having a QKD link is akin to extend the security perimeter ofthe installation to the optical fiber —the carrier of the quantumchannel— connecting the emitter and receiver.

In this work, we propose and demonstrate the integrationof QKD systems to secure novel network control plane tech-nologies and protocols. Originally, authors in [6] proposed theintegration of QKD systems to encrypt VNF images beforetransmission as a way to secure the provisioning of virtualizedservices. Our work goes beyond the demonstration in [6],proposing the integration of QKD keys2 into cryptographicprotocols that currently rely on public key encryption forkey exchange, and not just using QKD keys for offlineencryption of VNFs (via private key encryption). Furthermore,we include the coexistence of conventional and quantum-based mechanisms to secure the management communicationsin a realistic scenario, setting up a functional service in adistributed environment as a final result. This solution helps to

1Quantum bits.2Secret keys generated by a QKD system.

2

mitigate limitations of QKD technology and allows for a dou-ble security mechanism. Combining hybrid quantum (physicallayer security) and conventional (computationally difficult tosolve) methods to secure the control plane hardens the infras-tructure and makes extremely difficult the exploitation of sidechannels. Hybridization of conventional cryptosystems and itsbenefits have been well-studied [7], [8]. Since QKD primitiveshave been demonstrated to be composable [9] and are basedon fundamentally different assumptions than the conventionalalgorithms, they add a new security layer. Composability guar-antees that both cryptosystems must be broken to compromisethe key agreement. In particular, the proposed hybrid solutioninherits existing certifications from the conventional securityscheme [10], while increasing the security with the integrationof quantum-based cryptosystems. To showcase this integration,QKD-generated keys are combined with conventional keysusing Diffie-Hellman key exchange protocol within secureshell (SSH) sessions for setting up a virtual network serviceover a physical infrastructure. This physical infrastructureincludes an optical network, like the one demonstrated in [11].

It is important to note that, despite our solution has beenintegrated into SSH sessions for the service deployment, wehave also demonstrated it into the Secure Socket Layer (SSL)and Transport Layer Security (TLS) layer, used to secureother protocols and sessions, e.g. Hypertext Transfer ProtocolSecure (HTTPS), Secure Copy Protocol (SCP), OpenFlow,Network Configuration Protocol (NETCONF), GeneralizedMulti-Protocol Label Switching (GMPLS), etc. Once again,this layer can integrate the hybrid solution into the keyagreement (client/server), as long as QKD has been deployedin the corresponding links.

The paper is organized as follows. Section II elaborates onexisting QKD networks, exposing their limitations. Section IIIintroduces SDN and NFV, describing existing architecturesand vulnerabilities. Section IV proposes extensions in a Diffie-Hellman exchange for synchronizing the quantum keys withinan SSH session. Section V shows the setup and workflow usedfor this demonstration. Section V-C presents some results ofour test, while finally, Section VI concludes this paper.

II. QUANTUM KEY DISTRIBUTION NETWORKS

QKD can be regarded as an additional physical layer to anoptical network that allows the creation of keys between thepairs of its quantum connected QKD systems in a way that ismathematically proven to be secure —an information theoreticsecure (ITS) primitive—. A correct implementation of thistechnology can deliver keys of the highest security. However,the point-to-point nature of QKD brings limitations that do notaffect the conventional cryptosystems. In particular, the samephysical law that confers QKD its security also forbids theuse of any signal amplification or active components in thenetwork, as they might affect the transmitted quantum state.This restriction cause limits in terms of reachable distances(or maximum absorptions) that QKD can tolerate [5].

Current demonstrations in the literature show practical sys-tems tolerating absorptions of around 30 dB (i.e., approx.150 km) and still producing a usable key rate [12]. Demonstra-tions beyond these limits are laboratory experiments and not

Fig. 1. Optical network topology, composed by three ROADMs showing theconnection points of the different QKD systems.

very realistic in practice, either because of extremely low keyrates or requiring devices unsuitable as telecommunicationsequipment (e.g. cryogenic superconducting detectors). On theother hand, a trusted node approach [13], [14] could easilysolve distance issues, considering that any node is closeenough to others to interconnect the entire network. Similarly,quantum repeaters could tackle current distance issues inQKD, but it is a technology not yet available that will takemany years to mature. Nonetheless, when considering realnetworks, the distance limit has a relative importance as longas the different security perimeters are connected. Operatorsassume that inside a security perimeter their nodes are secured.Distances between secure nodes are typically well within theQKD distance limits [15]. Also, network coding techniquescan be used to increase the security and alleviate this problemwhen several paths are available [16].

For its particular relevance to this work, we have consideredan optical network composed by three reconfigurable opticaladd-drop multiplexers (ROADM) interconnected in a triangletopology, as shown in Fig. 1. This particular topology wasused in [11], where results demonstrated a quantum channelworking in the core of a metropolitan area network, traversingthe three nodes and sharing the same fiber with classicalsignals. It demonstrated that the quantum channel can tolerateenough noise to work with standard equipment when careto insulate it is taken. In that demonstration, distances up to10 km were considered between nodes A and B. The distancebetween nodes B and C was not significant in that setup fromthe coexistence point of view, and can be extended up to themaximum distance dictated by the tolerable absorptions of theQKD systems.

III. SDN AND NFV SECURITY

As mentioned above, software defined and virtualized net-works are vulnerable to multiple security threats [3], [4].Current SDN and NFV architectures and existing solutionsavailable in the market are based on logically centralizedsystems that facilitate and optimize service management froma single point. This approach can happen even in severallayers, bringing in architectures for orchestrating physical[17] and virtualized [18] network resources in multi-domainscenarios. However, such centralization and remote controlmake these systems a single point of failure where attackers

3

Fig. 2. Abstract view of a control plane architecture including cloud/NFVand network orchestration and SDN control plane.

can focus their efforts. Denial-of-service attacks with farreaching consequences are easier in this structure. Other kindof attacks attempt to gather service and configuration confi-dential information and to modify it on-the-fly, thus affectingthe behaviour and performance of the network and openingsecurity holes (a modified firewall allowing undesired accessto a private network, a virtual router dropping a service, aswitch duplicating the traffic, etc.).

To avoid the second group of attacks, current networkingprotocols and architectures have been defined over securelayers (see Fig. 2): SDN controllers and NFV manage-ment and orchestration (MANO) solutions provide SSH andHTTPS interfaces, NETCONF RPC goes over SSH, REST-ful APIs, OpenFlow and potentially GMPLS protocols canuse SSL/TLS-based solutions, etc. All these cryptographicnetwork protocols, even though they use private (secret) keyencryption to secure their communication channels, ultimatelyrely on public key encryption schemes when exchanging keysfor the session. At the same time, public key encryption secu-rity depends on the complexity of solving certain mathematicalproblems (e.g., integer factorization, elliptic curve or discretelogarithms). These problems are exponentially difficult from aclassical computing perspective, whereas they are polynomialin quantum computing [19]. QKD, if properly integratedin current cryptographic network protocols, can drasticallyincrease the level of security in control plane communications.It also increases the long term security (LTS) of the network,since QKD is immune to quantum attackers [20].

IV. SECRET KEY AGREEMENT AND QKD INTEGRATION

Current network cryptographic protocols require severalhandshakes between server and client to establish certainparameters and policies for securing a session. This schemeallows client and server to choose and agree different method-ologies and techniques to exchange important informationprivately and safely. Among many others, one of these agree-ments includes transferring a set of preferred key exchangeprotocols. These key exchange protocols are used to providesecret keys to remote entities to encrypt their subsequentconnections via private key encryption algorithms. Upon trans-mission, it is agreed to use the first supported protocol by

Fig. 3. Diffie-Hellman and QKD key exchange protocol integration.

both ends, together with a hash function. One of the mostcommonly used protocols for key exchange is Diffie-Hellman.Although there are different versions of this protocol, any ofthem requires the exchange of multiple messages between bothendpoints. In this way, both ends share certain informationover a public channel to generate a secret (private key).

QKD key agreement3 works in a similar way. When com-municating two endpoints, one of them must extract a quantumkey and its corresponding keyID from the QKD systems.Then, it transmits that ID (and potentially other importantinformation) over an open and possibly non-secure channel(public information). This process, similarly to the Diffie-Hellman protocol, requires several messages to synchronizekeys on both ends for inbound and outbound (bidirectional)communications. Therefore, due to these similarities, the in-tegration of the QKD key agreement process together withthe Diffie-Hellman protocol could be directly mapped if theexchanged messages are properly combined for both pro-cesses. To combine both solutions, Diffie-Hellman messagesare extended including new parameters, such as quantumkeyIDs, to further secure the sessions.

Fig. 3 shows the Diffie-Hellman group1 (as an example)message exchange, integrating the keyIDs as a parameter inthe exchanged messages. The workflow is as follows:

• Firstly, the node on the client side extracts a key for itsoutbound communication from the QKD systems. It canuse a standard API or interface (e.g. [21]) or proprietaryones (as in [22]).

• Then, in this example, the client sends the keyID (andpotentially an initialization vector ID) to the server.

• The server extracts the IDs and uses them to obtain thekey for its inbound channel.

• Similarly, the server extracts a key for its outboundcommunication and sends the appropriate ID to the clientin a response message.

• When the client receives these messages, it uses the IDto extract the key for its inbound interface.

• Finally, after digesting the generated secret using theagreed hash function, a classical key is generated. Bothkeys are combined via XOR (addition module 2) to be

3Note that here we use the term agreement referring to the process ofidentifying two previously exchanged keys.

4

Fig. 4. Demonstration scenario composed by two DockerNet instances, anONOS controller, and an Orchestrator.

used together to secure the channel, providing hybridquantum-classical security.

Although the proposed solution has been designed forbeing integrated into the SSH cryptographic protocol, it canbe mapped to the SSL/TLS layer by inserting the QKDkey IDs into the client and server key exchange process.This allows to appropriately combine the keys at the end-points. Following Fig. 3, this mapping is done by replacingMSG KEXDH INIT by the server key exchange handshake

protocol and MSG KEXDH REPLY by the client key ex-change handshake protocol, both within a TLS record layerstructure. This kind of mechanisms can be also extended touse novel versions of key exchange protocols and algorithmsas they are developed. One of the most popular solutionsthat potentially could be combined in the hybrid scheme arepostquantum cryptographic algorithms. By postquantum wemean any cryptographic solution thought to be safe againstquantum computing as far as we know it today. Correctly used,the hybrid solution not only provides a higher level of securityby forcing an attacker to break two completely differentcryptosystems to access the key, but from an industrial pointof view, it also makes the adoption of QKD easier: If one ofthe two cryptosystems is certified, the XOR of both inheritsthe certification [10].

V. IMPLEMENTATION AND RESULTS

A. Testbed

To demonstrate the quantum-conventional integration inexisting protocols, we have built the setup shown in Fig. 4.On the top left, we have built a simple cloud and networkorchestrator. This element locally receives virtual topologyrequests, decomposes it into different smaller topologies to bedeployed in different servers/data centers, and sends connectiv-ity requests (intents) to the network controller. On each server,we have placed DockerNet [23] instances, creating container-based virtual networks. Using this platform, the user canautomate the creation of hosts or even VNFs providing variousservices. The network controller (ONOS), receives requestsfrom the orchestrator to connect the virtual nodes (within thedata center topology) in the shape of intents. Once the requestis deployed by the orchestrator, the user can access to its ownvirtual network, with node connectivity as initially requested.

Fig. 5. Distributed virtual infrastructure deployment and configuration work-flow.

Regarding the physical infrastructure, we use the same opticalequipment (Fig. 1) as part of our testbed to interconnect twoendpoints in the data plane. For the purpose of this test, weassume that a quantum channel is given (similar to the oneshown in [11]) and strictly separated from the data channel.Coexistence of quantum and classical signals in the same fiber,then, is not an issue, meaning that longer distances and largerrates than in [11] can be achieved. Attached to the opticalequipment, we have two Juniper MX-240 routers, providingthe connectivity between the two servers across the opticaldomain. This underlying physical infrastructure (comprisingcarrier grade devices from IP and optical layers) is assumedto be configured.

We have incorporated our proposed hybrid solution intoSSH sessions in order to secure the deployment of the vir-tual infrastructure in a distributed scenario. The hybrid SSHsessions have been implemented using a Python library calledparamiko, while the SSL/TLS layer was implemented usingtlslite-ng. Any required configuration has been implementedas commands that are executed via SSH, restricting the client’saccess to any other command out of the workflow. The QKDsystems have been emulated for this demonstration, deployinga software process that provides the same interface as ID3100Clavis2 (IDQ3P) [22] to share the key resources.

B. Workflow

The set of operations for the virtual infrastructure deploy-ment are shown in Fig. 5. Initially, the orchestrator receivesthe instruction of deploying a new virtual infrastructure. Thisrequest is locally executed (e.g., by a system administrator)and clearly divided into two separated private networks: a localnetwork, where users can access Ubuntu 14.04 containers, anda remote private network placed in a data center offeringweb services. Both networks require virtual routers to bedeployed on each side to provide the connectivity to thepublic network with external public IPs. Therefore, duringthe deployment process, both, topological information andconfiguration commands are transmitted. After this initialdeployment, the orchestrator gathers hosts information (macaddresses, attachment points, etc.) from both systems tocreate the necessary connectivity requests for the controller.

5

Fig. 6. SSH message exchange and IDQ3P key extraction messages for settingup the virtual infrastructure.

(a)

(b)

Fig. 7. (a) Key exchange init message with the QKD-DH method, and (b)Payload in the Diffie-Hellman exchange including Key ID and initializationvector ID.

When this information has been obtained, the connectivity isestablished via the network controller. In our scenario, wehave an ONOS controller for the remote packet network. Ifnecessary, the orchestrator could also provision a multi-layerpath as demonstrated in [17], but in our demonstration itis assumed to be preconfigured. After that, the orchestratorenables connectivity among hosts via host-to-host intents (macaddress-based). Every message between management elementsin this workflow is encrypted via SSH sessions with hybridquantum and conventional keys to secure the channel.

C. Experimental Results

To keep the parallelism with the infrastructure shown inFig. 1, we have created our distributed scenario using two sep-arate domains. One server emulates the local private network,with different client hosts, a virtual router and the orchestratorinstance. Another server emulates a remote data center, withanother virtual router (could be multiple), multiple Nginx hostsproviding web services and a local SDN controller managingthe connectivity within the data center.

Fig. 6 shows, as an example, a set of messages exchangedfor each required SSH session. These messages include first,a key exchange init sequence to agree on the key exchangeprotocol to be used and, secondly, Diffie-Hellman exchangeinit and reply messages. It also includes encrypted packets

Fig. 8. Capture of the SSL/TLS messages, showing the exchange of QKDkey IDs for obtaining hybrid keys for combined security.

Fig. 9. Three captures showing the OpenFlow domain working: OpenFlowlocal messages, the installed intents via SSH and ONOS GUI with the intentsdrawn on top.

and UDP messages containing the keys extracted from theemulated QKD systems. Fig. 7a shows the proposed QKDDiffie-Hellman (QKD-DH) group1 as a first choice in thekey agreement process, while Fig. 7b shows the keyID andinitialization vector ID for encrypting the outbound commu-nication of the client within the Diffie-Hellman key exchangeinit message.

To further demonstrate the proposed hybrid solution, wehave implemented the integration of QKD keys into theSSL/TLS layer, incorporating the hybrid security into a differ-ent cryptographic protocol. Fig. 8 shows the initial exchange ofmessages between the client and the server for the subsequentsecure communication of different applications (in our case,HTTPS). The capture shows the key exchanges between serverand client, where we have included the QKD key IDs (byextending the messages). More specifically, we have extendedthe key exchange (client/server) handshake protocol withinthe TLSv1.2 record layer. Both messages contain byte arraysthat can be extended to include more information. Using thisflexibility, we have concatenated the QKD key IDs at the endof this structure to be included in the key exchange process(QKD key IDs highlighted in red). The UDP messages, inthe Diffie-Hellman exchange, correspond to the key extractionprocess from the emulated QKD systems.

6

Fig. 10. Traffic capture of the web service inside the local virtual router.

Additionally, to illustrate how the service has been suc-cessfully deployed, Fig. 9 shows some OpenFlow messagesbetween the virtual switches and the data center controller(ONOS), the three intents pushed in the controller via SSHinterface from the orchestrator and the topology discoveredby the network controller, with the intents highlighted. Acapture taken inside the private domain to display the httptraffic between a client and the data center is also shown inFig. 10. Note that, even though the OpenFlow messages are notencrypted, the same hybrid method used to encrypt the SSHchannel, could be used to encrypt OpenFlow messages overSSL (if QKD systems are available within the secure perimeterof the switches). The time required to deploy the distributedcontainer-based topology was around 11 seconds, consideringthat the management network has a latency average of 200msbetween servers. Obtaining a key from a QKD layer has nodelay penalties unless the key store is empty. In this case, it isup to the quality of service defined to either drop the sessionand wait until there are available keys or keep the sessionusing conventional security alone. For this demonstration wehave selected the second option, showing a log message to theorchestrator in case the SSH session does not use QKD keys.

VI. CONCLUSION

Software defined networking and network virtualizationtechniques are rapidly evolving and being integrated into realnetworks. This situation, although promising in terms of costreduction in network deployment and operations, comes alongwith certain security vulnerabilities that need to be tackled. Inthis work, we propose a method to integrate QKD systems inmodern network infrastructures and cryptographic protocols tosecure network’s control plane operations. This can be donewhile keeping the old protocols or adding new, postquantum,ones, providing hybrid solutions. This also allows to leverageexisting certifications: the augmented system is never worsethan the certified one. The net result is an increased securitylevel and a network much more resilient to side channelattacks. Furthermore, we demonstrate our QKD-DH proposedsolution by incorporating it into SSH sessions used for set-ting up a network and infrastructure service in a distributedscenario.

REFERENCES

[1] N. McKeown, T. Anderson, H. Balakrishnan, G. Parulkar, L. Peterson,J. Rexford, S. Shenker, and J. Turner, “OpenFlow: Enablinginnovation in campus networks,” SIGCOMM Comput. Commun.Rev., vol. 38, no. 2, pp. 69–74, March 2008. [Online]. Available:http://doi.acm.org/10.1145/1355734.1355746

[2] B. Han, V. Gopalakrishnan, L. Ji, and S. Lee, “Network functionvirtualization: Challenges and opportunities for innovations,” IEEECommunications Magazine, vol. 53, no. 2, pp. 90–97, Feb 2015.

[3] S. Scott-Hayward, G. O’Callaghan, and S. Sezer, “SDN security: Asurvey,” in IEEE SDN for Future Networks and Services (SDN4FNS),2013.

[4] W. Yang and C. Fung, “A survey on security in network functionsvirtualization,” in IEEE NetSoft Conference and Workshops (NetSoft),2016.

[5] N. Gisin, G. Ribordy, W. Tittel, and H. Zbinden, “Quantum cryptogra-phy,” Rev. Mod. Phys., vol. 74, no. 1, pp. 145–195, Mar. 2002.

[6] A. Aguado, E. Hugues-Salas, P. A. Haigh, J. Marhuenda, A. B. Price,P. Sibson, J. E. Kennard, C. Erven, J. G. Rarity, M. G. Thompson,A. Lord, R. Nejabati, and D. Simeonidou, “Secure nfv orchestrationover an sdn-controlled optical network with time-shared quantum keydistribution resources,” Journal of Lightwave Technology, vol. PP, no. 99,2017.

[7] R. Cramer and V. Shoup, “A practical public key cryptosystem provablysecure against adaptive chosen ciphertext attack,” in CRYPTO 1998, vol.1462 of LNCS, pages 1325. Springer-Verlag., 1998.

[8] K. Kurosawa and Y. Desmedt, “A new paradigm of hybrid encryptionscheme,” in CRYPTOCRYPTO 2004, vol. 3152 of LNCS, p. 426442.Springer-Verlag., 2004.

[9] M. Ben-Or, M. Horodecki, D. W. Leung, D. Mayers, and J. Oppenheim,“The universal composable security of quantum key distribution,” inTheory of Cryptography: Second Theory of Cryptography Conference,TCC 2005, vol. 3378 of LNCS, pp. 386-406. J.Kilian (ed.) Springer-Verlag., 2005.

[10] N. Walenta, M. Soucarros, D. Stucki, D. Caselunghe, M. Domer-gue, M. Hagerman, R. Hart, D. Hayford, R. Houlmann, M. Legre,T. McCandlish, J.-B. Page, M. Tourville, and R. Wolterman, “Practicalaspects of security certification for commercial quantum technologies,”in Proceedings of SPIE, 2015.

[11] D. Lancho, J. Martinez, D. Elkouss, M. Soto, and V. Martin, “QKD instandard optical telecommunications networks,” in Quantum Communi-cation and Quantum Networking, ser. Lecture Notes of the Institutefor Computer Sciences, Social Informatics and TelecommunicationsEngineering. Springer Berlin Heidelberg, 2010, vol. 36, pp. 142–149.

[12] N. Walenta, A. Burg, D. Caselunghe, J. Constantin, N. Gisin,O. Guinnard, R. Houlmann, P. Junod, B. Korzh, N. Kulesza, M. Legre,C. W. Lim, T. Lunghi, L. Monat, C. Portmann, M. Soucarros, R. T.Thew, P. Trinkler, G. Trolliet, F. Vannel, and H. Zbinden, “A fastand versatile quantum key distribution system with hardware keydistillation and wavelength multiplexing,” New J. Phys., vol. 16,no. 1, p. 013047, 2014. [Online]. Available: http://stacks.iop.org/1367-2630/16/i=1/a=013047

[13] M. Peev, C. Pacher, R. Alleaume, C. Barreiro, J. Bouda, W. Boxleitner,T. Debuisschert, E. Diamanti, M. Dianati, J. F. Dynes, S. Fasel,S. Fossier, M. Furst, J.-D. Gautier, O. Gay, N. Gisin, P. Grangier,A. Happe, Y. Hasani, M. Hentschel, H. Hubel, G. Humer, T. Langer,M. Legre, R. Lieger, J. Lodewyck, T. Lorunser, N. Lutkenhaus,A. Marhold, T. Matyus, O. Maurhart, L. Monat, S. Nauerth, J.-B.Page, A. Poppe, E. Querasser, G. Ribordy, S. Robyr, L. Salvail, A. W.Sharpe, A. J. Shields, D. Stucki, M. Suda, C. Tamas, T. Themel, R. T.Thew, Y. Thoma, A. Treiber, P. Trinkler, R. Tualle-Brouri, F. Vannel,N. Walenta, H. Weier, H. Weinfurter, I. Wimberger, Z. L. Yuan,H. Zbinden, and A. Zeilinger, “The SECOQC quantum key distributionnetwork in Vienna,” New J. Phys., vol. 11, no. 7, p. 075001, 2009.[Online]. Available: http://stacks.iop.org/1367-2630/11/i=7/a=075001

[14] M. Sasaki, M. Fujiwara, H. Ishizuka, W. Klaus, K. Wakui, M. Takeoka,S. Miki, T. Yamashita, Z. Wang, A. Tanaka, K. Yoshino, Y. Nambu,S. Takahashi, A. Tajima, A. Tomita, T. Domeki, T. Hasegawa, Y. Sakai,H. Kobayashi, T. Asai, K. Shimizu, T. Tokura, T. Tsurumaru, M. Matsui,T. Honjo, K. Tamaki, H. Takesue, Y. Tokura, J. F. Dynes, A. R. Dixon,A. W. Sharpe, Z. L. Yuan, A. J. Shields, S. Uchikoga, M. Legre,S. Robyr, P. Trinkler, L. Monat, J. Page, G. Ribordy, A. Poppe,A. Allacher, O. Maurhart, T. Langer, M. Peev, and A. Zeilinger, “Fieldtest of quantum key distribution in the Tokyo QKD Network,” Opt.Express, vol. 19, no. 11, pp. 10 387–10 409, 2011.

[15] T. Jimenez, V. Lopez, F. Jimenez, O. Gonzalez, and J. P. Fernandez,“Techno-economic analysis of transmission technologies in low aggrega-tion rings of metropolitan networks,” in Proc. Optical Fiber Conference(OFC), 2017.

[16] D. Elkouss, J. Martinez-Mateo, A. Ciurana, and V. Martin, “Secureoptical networks based on quantum key distribution and weakly trustedrepeaters,” Journal of Optical Communications and Networking, vol. 5,no. 4, pp. 316–328, April 2013.

[17] A. Aguado, V. Lopez, J. Marhuenda, O. G. de Dios, and J. P. Fernandez-palacios, “ABNO: a feasible SDN approach for multivendor IP andoptical networks,” J. Opt. Commun. Netw., vol. 7, no. 2, pp. A356–A362, Feb. 2015.

[18] “Network functions virtualisation (nfv); architectural framework,” inETSI GS NFV 002 V1.2.1, 2014-12.

7

[19] P. W. Shor, “Polynomial-time algorithms for prime factorization and dis-crete logarithms on a quantum computer,” SIAM Journal on Computing,vol. 26, no. 5, pp. 1484–1509, 1997.

[20] D. Mayers, “Unconditional security in quantum cryptography,” J. ACM,vol. 48, no. 3, pp. 351–406, May 2001.

[21] “Quantum key distribution (qkd); application interface,” in ETSI GSQKD 004 V1.1.1, 2010-12.

[22] [Online], “Idquantique clavis2 qkd platform,” Available:http://www.idquantique.com/photon-counting/clavis2-qkd-platform/(Accessed March 14, 2017).

[23] ——, “Github dockernet-tool,” Available:https://github.com/alexaguado/DockerNet (Accessed March 14, 2017).