Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
GMPLSNetworkControlPlane Enabling QuantumEncryption inEnd-to-End Services AlejandroAguado,VíctorLópez,Jesús Martínez-Mateo, Momtchil Peev,DiegoLópez andVicenteMartin Outline • Introduction • SecureChannelCreation • QKDnodearchitecture • PCE/GMPLSextensionstoenableautomaticprovisioning • Experimentalvalidation • Conclusions Introduction • Quantumkeydistribution (QKD)isanoveltechnologythatcanbe seenasasynchronizedsourceofsymmetrickeys intwoseparated domainsthatisimmunetoanyalgorithmiccryptanalysis. • Ontheotherhand,networkservicesareincreasinglyrequesting moreflexibilityandnetworkresources. • Oneofthebiggestdemandsistoincreasethelevelofsecurity forthe transmissionbetweenremotepremises. • Inthiswork,weproposeanodearchitecture anddefineprotocol requirementsinaGMPLSenvironmenttoprovideQKD-enhanced securityinend-to-endservices. Introduction Key exchange Channel Creation Eve Alice Encrypt Bob Encrypt Message encryption Message Exchange Introduction:QuantumKeyDistribution Bob Alice Encrypt QKD System Message encryption Eve Message Exchange DataChannel PublicAuthenticatedChannel QuantumChannel Key exchange Decrypt QKD System Ingredients: • Qubittransmitter(typically photons),Alice. • Singlequbitreceivers,Bob. • Quantumchannel(capableof transmittingqubitsfromAliceto Bob,inourcasefibre). • Classicalchannel(public,but authenticated). Mainsteps: • Rawkeyexchange: • Qubittransmission • Sifting(basisreconciliation) • Keypost-processing: • Informationreconciliation • Errorverification • Privacyamplification Introduction:QuantumKeyDistribution • QKD technologycanberegardedastwo sourcesofsynchronizedrandom numbers thatareseparatedphysically. • Acorrectimplementationwilldeliver keysofthehighestsecurity • Itcanbemathematicallyproventobe secure(inprinciple,aninformation theoreticsecure(ITS)primitive) Classicalchannel Alice Eve Quantumchannel Bob LIMITATIONS • QKDhassomelimitationsthatdonotaffect theconventionalcryptosystems,usually basedoncomputationalcomplexity. • Anykindofamplifiersoractivecomponents thatcanmodifythestateofthesesignalsmust bebypassed. • Thissetsalimittothemaximumdistance(or absorptions)thataQKDprotocolcantolerate, wellsuitedtobeusedwithinametropolitan areaorwithlinksofupto150km Securechannelcreation Key exchange Alice QKDBox ETSIProxy ExchangeSecureKeys/QuantumChannel Channel Creation Eve QKDBox ETSIProxy PCE Lightpath creation/ControlPlane GMPLS Agent … GMPLS Agent Message encryption Encryptor IncludeKeysintheencryptioncard GMPLS Agent GMPLS Agent Encryptor Exchangeinformation/DataPlane OXC Message Exchange OXC Bob ExampleofQKD-enablednetworknode architecture PCE Extended PCEP GMPLS Agent KeyReq/Resp QKDBox Proprietary protocols Classical channels ETSI Proxy Flowcontrol Keyinjection QuantumLink Encryptor OXC Desiredcapabilities: • AccesstoQKD-generatedkeys. • Encryptioninupstreamservices(Data encryptor,securitymodule,etc.). • Switching/Routing. • Controlplaneinterfaceenablingautomation Definitionofrequirementsintermsof parameters • Parametersrequiredtobeexchanged(point-to-pointencryption): • SessionID(key_handle):Initiallysetas0,sessionIDgetsthevalueofthefirstKey handleextractedbythesourceagentintheinitialsetup.Thesourceagentwillbein chargeofupdates(futurework). • Keylength:Lengthofthekeytobeusedfortheencryption. • Destination:Itdefinestheotherpeer(encryptor/decryptor)tosynchronisewith. CurrentlydefinedbyanIPaddress. • EncryptionLayer:Layerwhereencryptionisperformed. • Refreshtypeandvalue:Typeofrefreshtobedoneforakey(time/traffic/etc)and thevaluetobeconsideredasathreshold. • Algorithm:Encryptionalgorithmtobeused. DistributedGMPLSControl • Majorityofthecommercialdeploymentsofopticalcoreandtransport networksarebasedonGMPLS. • GMPLSwasstandardizedbyIETFinCCAMP WG • Fundamentalprotocols: • RSVP-TE:responsibleofsettingupend-to-endquality-enabledconnections • OSPF-TE:disseminationofthetopologyandtrafficengineering(TE) information,enablingrouting • LMP(LinkManagementProtocol):isresponsibleoflinksmanagement PathComputationElement • GMPLSiscomplementedwithalogicallycentralized element,thePCE • PCElearnstheTEDBlistening PCE PCEP(PCReq,PRep) IGP RSVP theIGP. • ActiveStatefulPCEcanrequest tocreateapathusingPCInitiate. • Thenodeset-uptheconnection usingRSVPPath,Resv. • TelefonicaNetphony releaseopensourcePCE implementationand GMPLScontrolplane. GMPLS+PCEArchitecture Proposedworkflow:Case“Nodestarts” PCE 4 metrics: - Keylength - Layerofencryption - Refreshtype/value - Enc_Alg Node1 QKD NoSessionID(=0) InjectSessionID inERO Node5 QKD Node3 Node2 GMPLScase: - PCRequest includingmetricforinline encryption. - PCReply includingnewEROsubobjects for keymanagement - RSVPincludingthesameERO - RSVPQEEROsubobject detectedbynode1. Key_handle unset(=0),itgetsanewkeyand key_handle,andaddsthekey_handle as sessionIDtobeusedbynode5 - Node5getsthesessionID andextractsthe requiredkey. - TherestisstandardRSVP Node4 sessionID found getsessionID Experimentalvalidation ETSItoIDQ Proxies Emulated Quantum Link GMPLS Control Plane https://github.com/alexaguado/DockerNet Experimentalvalidation OSPFforQuantumencryptioncapabilities InformationalCapabilitiesTLV QuantumEncryptionsupport(bit7):capable ExperimentalvalidationPCEP NewQE ERO subobject ExperimentalvalidationRSVP(signalling) Node4QE EROsubobject. (beforenode2) Type:0x67 Value:”00..00”(64bytes) KeyLenght:32 Enc_layer:2 RefType:0xfd RefValue:60 Alg:10(TBD) Node4QE EROsubobject. (beforenode2) Type:0x67 Value:“4a0e…052f”(64bytes) KeyLenght:32 Enc_layer:2 RefType:0xfd RefValue:60 Alg:10(TBD) Conclusions • Weproposeanodearchitectureanddefineprotocolrequirementsin aGMPLSenvironmenttoprovideQKD-enhancedsecurityinend-toendservices. • Thisisthefirstworktopropose,implementandvalidateextensionsin aPCE/GMPLSarchitecturetousethistechnology. • TheworkisdonewithOpenSourcetoolsusingNetphony and DockerNet. • Asfuturework,theauthorswillexplorethisapproachinOpenFlow or Netconf. THANKYOU!!! AlejandroAguado,VíctorLópez,Jesús Martínez-Mateo, Momtchil Peev,DiegoLópez andVicenteMartin AppendixA ETSIGSQKD004V1.1.1 forremoteappsandIDQ3P ETSIIDQProxy • ETSIGSQKD004V1.1.1definesanAPItobeusedbyapplications whicharerunningwithinthesameserverastheKeyManager. • Inordertojustifytheuseofthisstandard,wehavedevelopedaproxy thatimplementsETSIGSQKD004V1.1.1-basedmessagesto communicatewithexternalapplications • ThesemessagesaremappedtoIDQ3Prequests. • AdditionalSyncmessageshavebeenimplementes aswell. • Thisinterfaceallowstouseasingleidentifier(key_handle)thatcan beusedtoextractmultiplekeys. Modules/Messages ALICE APP ETSIGSQKD004V1.1.1msgs QKD_{OPEN,CLOSE,GET_KEY, CONNECT_NONBLOCK, CONNECT_BLOCKING} ETSI/IDQ Proxy IDQ3P IDQSystem BOB Appmessages Send_key_handle() Sync messages: Session Opened/closed BlockSession,Update Key Quantumchannel Errorcorrection Distillation… APP ETSIGSQKD004V1.1.1msgs QKD_{OPEN,CLOSE,GET_KEY, CONNECT_NONBLOCK, CONNECT_BLOCKING} ETSI/IDQ Proxy IDQ3P IDQSystem ExampleOPEN&CONNECT BOB ALICE IDQSystem ETSI/IDQ Proxy APP QKD_OPEN() ETSI/IDQ Proxy APP SYNC_OPEN(key_handle) Key_handle Send_key_handle() ACK QKD_CONNECT_ NONBLOCK() ACK QKD_OPEN(Key_handle) ACK QKD_CONNECT_ NONBLOCK() ACK IDQSystem ExampleGET_KEY BOB ALICE IDQSystem ETSI/IDQ Proxy APP ETSI/IDQ Proxy APP IDQSystem QKD_GET_KEY(Key_handle) SYNC_BLOCK(key_handle) GET_KEY() KeyID,Key SYNC_KEY(key_ids) GET_KEY() KeyID,Key ACK Update_Key() ACK QKD_GET_KEY(key_handle) KEY ExampleCLOSE BOB ALICE IDQSystem ETSI/IDQ Proxy APP QKD_CLOSE() ETSI/IDQ Proxy APP SYNC_CLOSE(key_handle) ACK Send_close()????? ACK QKD_CLOSE(Key_handle) ACK IDQSystem