Download GMPLS Network Control Plane Enabling Quantum

Survey
yes no Was this document useful for you?
   Thank you for your participation!

* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project

Document related concepts

CAN bus wikipedia , lookup

Recursive InterNetwork Architecture (RINA) wikipedia , lookup

Cracking of wireless networks wikipedia , lookup

Transcript
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