Minutes IETF108: qirg
Quantum Internet Research Group
||Minutes IETF108: qirg
# Quantum Internet Research Group
## IETF-108 Virtual Meeting
- 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
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
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
2: - Chonggang Wang: Applications and Use Cases for Quantum Internet
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
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
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
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
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
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.: -
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.
- 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
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