Hi Paul, Thank you for sharing your thoughts
I agree that IKE-o-QUIC is not necessarily better than the current IKEv2 transport mechanisms. The intention is more to explore whether it may provide a different deployment option in some scenarios. For firewall traversal, UDP/443 is already widely permitted in many networks because of the growing deployment of QUIC. In some environments where UDP/500 and UDP/4500 are restricted, this may make deployment easier. I agree that IKE fragmentation already provides a mechanism to support large PQC and hybrid exchanges over UDP. It is not suggesting that PQC itself requires QUIC, nor that QUIC is necessary to address message size issues. My point is simply that QUIC has become widely deployed and is commonly allowed on UDP/443. This may make it an interesting transport candidate for environments where deployment of traditional IKE transports requires extra operation. For NAT handling, I agree that MOBIKE already addresses IP address and port changes effectively. My point was not that QUIC solves a problem that MOBIKE cannot solve, but rather that QUIC uses a different approach based on Connection IDs, which may simplify connection continuity across NAT rebinding and address changes. Whether that provides meaningful operational benefits compared to MOBIKE would certainly need further evaluation. Overall, the goal is not to claim that IKE-o-QUIC is superior to existing solutions. Rather, it is to investigate whether it could serve as an additional option that may be easier to deploy in certain environments, allowing operators and customers to choose the approach that best fits their needs. Best, Wang -----Original Message----- From: Paul Wouters <[email protected]> Sent: Tuesday, June 16, 2026 7:31 PM To: Wang Xi <[email protected]> Cc: Erik Kline <[email protected]>; [email protected] Subject: Re: [IPsec] Re: Possible future transport design space for QUIC ALERT : This message originated outside of the Fortinet network. BE CAUTIOUS before clicking any link or opening an attachment. On Tue, 16 Jun 2026, Wang Xi wrote: > In addition, IKE-o-QUIC is primarily concerned with the control plane, > after the key negotiation is completed, IPsec data traffic still can be > carried over another transport. If you are only using QUIC to run an IKEv2 variant, then: > Compared to TCP, QUIC provides: > - built-in stream multiplexing > - avoidance of TCP head-of-line blocking > - better behavior under NAT and loss-prone networks > - integrated congestion control over UDP Those items seem hardly relevant when comparing that to IKEv2 ? multiplexing == IKEv2 Window Scaling > 1 TCP head-of-line blocking would hardly matter because IKEv2 isn't a performance bottleneck per stream. And this assumes we would need TCP for IKEv2, but even for PQC hybrids we can use UDP with IKEv2 fragmentation support. While IKE over TCP is defined, it currently sees zero deployment (partially because only generic Linux supports it, and Apple and Android do not) Better behaviour under NAT? I am not sure because if you are behind NAT you are using ESPinUDP, which would now become some kind of ESPinQUIC, but I don't see how that would change behaviour under NAT or loss-prone networks? Congestion control over UDP wouldn't matter much as IPsec isn't an application. It is the applications using UDP (or TCP) that need to deal with proper congestion control. The IPsec VPN is just encrypting application traffic first come first serve. Can you give concrete examples of where you think QUIC would make a substantional improvement that would justify the effort? Paul *** Please note that this message and any attachments may contain confidential and proprietary material and information and are intended only for the use of the intended recipient(s). If you are not the intended recipient, you are hereby notified that any review, use, disclosure, dissemination, distribution or copying of this message and any attachments is strictly prohibited. If you have received this email in error, please immediately notify the sender and destroy this e-mail and any attachments and all copies, whether electronic or printed. Please also note that any views, opinions, conclusions or commitments expressed in this message are those of the individual sender and do not necessarily reflect the views of Fortinet, Inc., its affiliates, and emails are not binding on Fortinet and only a writing manually signed by Fortinet's General Counsel can be a binding commitment of Fortinet to Fortinet's customers or partners. Thank you. *** _______________________________________________ IPsec mailing list -- [email protected] To unsubscribe send an email to [email protected]
