Hi all, One way to keep this future-work discussion concrete is to split the candidate use cases before comparing transports.
For IKEv2-over-QUIC, I would not start from general QUIC properties such as stream multiplexing or TCP head-of-line avoidance; those are not obviously the limiting factors for IKEv2 itself. The more relevant question seems to be whether there is a deployment class where UDP/500, UDP/4500, or TCP-based IKE is operationally hard, while UDP/443 QUIC is permitted and can provide a better control-plane path without changing ESP data-plane semantics. If so, the problem statement would need a fairly strict comparison matrix: - whether the problem is message size, path traversal, mobility/NAT rebinding, DoS/client puzzles, or middlebox policy; - why existing IKE fragmentation, MOBIKE, IKE over TCP, ESP-in-UDP, or MASQUE is insufficient for that case; - what new state, authentication binding, retry/anti-amplification, and fallback behavior QUIC introduces; - whether the result remains a control-plane transport only or implies ESP-in-QUIC or other data-plane work. Without that use-case separation, I agree it is hard to tell whether QUIC is solving an IKEv2 problem or just adding another transport option. Best, Songbo On Wed, 17 Jun 2026 14:56:27 -0400, Michael Richardson <[email protected]> wrote: > CJ Tjhai <[email protected]> wrote: > > Did you mean https://www.rfc-editor.org/rfc/rfc8019.html? > > Thank you (search engines suck now) > Apparently, not in my directory of IPsec RFCs (fixed), and the title in DT > list didn't shout puzzles at me :-) > > Anyway, it wasn't well deployed/loved. > I think that if anything, any key agreement protocol that QUIC does over UDP > would benefit from this work. > > -- > Michael Richardson <[email protected]>, Sandelman Software Works > -= IPv6 IoT consulting =- *I*LIKE*TRAINS* _______________________________________________ IPsec mailing list -- [email protected] To unsubscribe send an email to [email protected]
