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
_______________________________________________
IPsec mailing list -- [email protected]
To unsubscribe send an email to [email protected]
