Chair's update: - Virtual IAB review held in May 2020 - Couple of challenges: - group would ideally contain a better blend of quantum network experts by helping current members, network engineers and physicists, become these experts - lack of hands-on examples - not many participants have access to hardware
1: - Attacking the Quantum Internet - Takahiko Satoh, Shigeya Suzuki - Two main topics - How can elements of a QI be attacked? - What can attackers achieve if they successfully gain control of a quantum node?
Node types: MNode: Classical computer with measurement device ENode: Quantum end node INode: Intermediate node (e.g for creating/linking Bell pairs) RNode: Repeater node (for improving network performance) XNode: Can branch quantum routing
Current focus: tomography and presence of malicious actors. Quantum state tomography is useful for (a) estimating quantum states and (b) identifying possible malicious action on a quantum link. [By implication, quantum tomography infers quantum states from multiple samples, and does not inspect the actual state of - and therefore collapse - qubits]
Potential attacks using a hijacked node: - "framing" other repeaters/routers by subverting tomography [? i.e. simulating malicious activity on a target node]
Speakers' paper summarizes safety aspects of quantum repeater architecture Quantum tomography is a key tool for detecting malicious activity.
Scott Fluhrer: "Isn't the problem "how to prevent eavesdropping on classical channels?" a solved problem?" Satoh: Eavesdropping on classical channels was out of scope for this paper.Isn't the problem "how to prevent eavesdropping on classical channels?" a solved problem?
佐々木寿彦: How to identify hijacked node? It seems that attack strategy heavily depends on that. Satoh: We increase the detection rate by randomizing the timing of the tomography. We have briefly discussed the resources needed in previous papers.(https://arxiv.org/abs/1701.04587)
2: - Chonggang Wang: Applications and Use Cases for Quantum Internet https://datatracker.ietf.org/doc/draft-irtf-qirg-quantum-internet-use-cases/
v01 use-case document ( draft-irtf-qirg-quantum-internet-use-cases-01 ) - Clarifications on Control plane vs data plane (Sect. 4.3) - Mapping use cases to Wehner's QI roadmap (Sect. 6) - Requirements section updates and includes reference to roadmap (Section 6 )
Clarifications distinguish between, e.g., quantum network functionality vs Quantum Internet functionality. e.g. quantum network: signalling to control entanglement distribution, quantum Internet: QKD, quantum PING
Mapping takes the 6 QI stages set out by Wehner, and relates these to the use cases envisaged in the draft: - Secure comms setup with trusted nodes - Secure comms setup with E2E qubit transmission (i.e. no requirement for trusted intermediary nodes) - Secure long-distance qubit transmission by entanglement - Secure/Blind quantum computing - Improved fault tolerance, e.g.higher-accuracy time synchronization (current draft is not detailed on this topic) - Secure distributed QC
Feedback sought from QIRG Should this draft be synchronized with draft-irtf-qirg-principles for RGLC?
Rod van Meter (from floor): would be useful to try and estimate what the performance requirements would be for the various applications, not just list the applications. Chonggang: has been looking for reference papers, but little success to date.
Joey: what other functions are being considered, aside from performance? (e.g. user privacy/data anonymization) Chonggang: will look at data privacy aspects. Trying to define functionality and architecture for each use case as the starting point.
Diego Lopez: Manageability and operationalization are also important functional areas to consider. Current approach seems to be mostly about classical applications that can benefit from quantum; what about "pure quantum" applications? Chonggang: agree on management/operations; we think both the quantum computing use-cases described in the document are novel. Scott Fluhrer: QKD isn't needed for everything... quantum-safe classical key distribution mechanisms also exist.
3 - Wojciech Kozlowski - update on https://datatracker.ietf.org/doc/draft-irtf-qirg-principles/
Recap: March 2019 goal; set out network node roles and definitions, common vocabulary, and starting point for non-quantum specialists. Updates presented at IETF 106, 107, reflecting extensive rework. Most recent version is likely to be on Github (Wojciech stages it from there to Datatracker once stable).
Discussion point relating to current draft: How to encode qubits (discrete vs continuous variable encodings) Next steps: - add references for completeness; - conclude mailing list discussions - shortest-path definition - control plane definition - time-skewed entangled pairs - is "all-optical" excluded by the language
Rod van Meter: As long as the doc contains references/pointers to further information, it probably need not go into detail itself, on encoding.
Jerry: current draft doesn't do much to address broader networking issues e.g. inter-domain routing Wojciech: good point, and will need to be addressed. Rod van Meter: has given some thought to recursive quantum network architecture (i.e. multi-layer, not just 2-layer). See here: https://arxiv.org/abs/1105.1238
Distillation and purification are mentioned but should be more explicitly linked to the error connection section in the draft. Diego Lopez: error connection seems to imply a parallel classical network. If there's a collaborative dependency there, this should be explicit in the architecture document/use cases. Wojciech: current draft mentions the dependency (Sect 5.2), both for communications payload and control data. Rod: a distinction here is between e.g. "hard" traffic such as photon timing, and "soft" traffic such as acknowledgement messages... but this risks getting into too much detail and definition.
Open Floor Discussion
Jonathan Hammill: does this group have any liaison with e.g. ESTI, ISO? Rod VM: thinks those groups are lookg at subsets (e.g. hardware, single-photon QKD); no recent contact with ETSI. Believes ITU is also looking at this, but no liaison in place. Jonathan: ISO SC27 and corresponding ITU Focus Group held a joint session on this topics. Rod VM: welcomes suggestions about liaison with ITU SIM Dong-hi regarding ITU-T works, there are two study groups (SG) in ITU-T working on QKD. In SG13, there are standardizing the network aspects of QKD which means how to incorporate QKD into telecom networks. In SG17, the security aspects of QKD in the telecom networks are considered. Jim Reid: ITU SG-13 is meeting this week to agree its 4-year work plan for submission early next year. Colin Perkins, Rod Van M: that would have to be via the designated liaisons, but should happen.
Robin Wilton: is this group looking at quantum cryptanalysis, or is that out of scope? Rod VM: was considered pre-Charter, but thought out of scope, in favour of a focus on networking issues and quantum repeaters etc. Colin Perkins: It's being discussed in CFRG and there's a paper: https://datatracker.ietf.org/doc/draft-hoffman-c2pq/ Ira McDonald: FTI, NIST announced the Round Three candidates for quantum-safe encryption aglrothms last week Jonathan H.: - https://www.itu.int/en/ITU-T/focusgroups/qit4n/Pages/default.aspx - https://www.etsi.org/committee/qkd
Shota Nagayama About the use case document. I think quantum internet algorithms found so far are only a few portion of the all quantum internet algorithms and more and more algorithm will be discovered. I would think that adding more abstracted pattern of use cases would make this document valuable long, like, prepare Bell pair and measurement. Table 1 on https://arxiv.org/pdf/1701.04586.pdf and Dahlberg’s Link Layer protocol paper has similar summary.
Chonggang: paper does mention potential QKD algorithms and how they would fit into a secure quantum communcations setup process, as a step towards secure distributed quantum computing.
Wojciech: - any new topics people would like to see covered? - how can we improve access to the physicists' work and hardware?
Wojciech is always happy to try and connect people with the right experts in other domains.
Principles plus use cases, once documented, will form most of the basis for the group's work going forward, so do suggest new themes/areas.
Chonggang: Prague IETF included a good tutorial - would be helpful to repeat Rod VM: That session's recording is available on the IETF's Youtube channel... but it would make sense to repeat it every year or two, to cater for new participants and new material.
Meeting closed at 15:49UTC