I thought I'd share some random thoughts on this proposal:
* First of all, I do not believe that this is a good fit for the IPsecME working group - it doesn't really touch on IKE at all. On the other hand, I'm not sure where would be better. The only place where this might partially fit is QIRG (Quantum Internet Research Group), but I'm not sure they'd be interested. * I do not believe QKD networks internally run via IPv6, and so I'm not sure that the IPv6 extensions you suggest are appropriate. On the other hand, I'm not sure how QKD networks work internally, and that's not something the IETF gets into - maybe ETSI would be a better fit (as they really do have a QKD group)? * I believe that QKD systems don't natively generate a random value R and then transmit it to the other side; instead, the two sides work together to generate a random R that no one else knows. For the (n,n) scheme with the xor combining, that is quite sufficient; we'll generate n random values R_1, R_2, ..., R_n and xor them together. For a Shamir (or Blakley) scheme, it doesn't work with random shares. This could be worked around by having the two parties communicate some authenticated (but not necessarily private) auxiliary information; not that difficult but needs to be thought through. Your proposal tries to send that information through the QKD network - I'm not sure the provisions for that are there. * You want n distinct paths through the QKD network. Well, one necessary (but not sufficient) requirement is that both peers have n direct QKD connections to someone else; is this realistic? If either peer has only a single QKD link, there is little point to this. * Another thing to worry about with any sort of protocol like this is to make sure that it is stable even if the peers are doing other things at the same time, including other instances of this protocol. For example, if A tries to connect to B, B connects to C and C connects to A, we need to somehow make sure that each side associates the QKD shared secrets with the correct connection. Having two independent networks (the classical network and the QKD network) may make this challenging. You try to do some of it in your QKD-DOH, but at the very least you'd need some sort of session identifier (to handle the case where there are multiple connections going on at once). ________________________________ From: 李金铭 <[email protected]> Sent: Monday, March 16, 2026 4:13 AM To: Tero Kivinen <[email protected]> Cc: [email protected] <[email protected]> Subject: [IPsec] Re: Slides for the IETF 125 hi Tero I have uploaded the slides. I apologize for the delay. 发件人: Tero Kivinen <[email protected]> 日期: 星期一, 2026年3月16日 13:40 收件人: [email protected] <[email protected]> 抄送: Tiger Xu <[email protected]>, [email protected] <[email protected]> 主题: Slides for the IETF 125 I am still missing two slidesets for the agenda items, i.e., ESP in UDP for load balancing and Multi-Path Secret Sharing for QKD Key Relay. The agenda is already very full, and if I do not receive slides for those by the end of today, I will move them to the end of agenda with comment (if time permits). -- [email protected] [DELETED ATTACHMENT IETF125-draft-xu-ipsecme-esp-in-udp-lb-15.pdf, PDF] [DELETED ATTACHMENT IETF125-draft-xu-ipsecme-esp-in-udp-lb-15.pptx, Presentation]
_______________________________________________ IPsec mailing list -- [email protected] To unsubscribe send an email to [email protected]
