QUIC permissiveness

Posted Nov 29, 2023 16:51 UTC (Wed) by wtarreau (subscriber, #51152)
In reply to: QUIC permissiveness by paulj
Parent article: OpenSSL 3.2.0 released

Here it allows the client to decide when to switch. A sliding window would not exactly, unless the client indicates which key number it's using. But that info would need to pass one way or another and be detectable, I suspect that's the reason why it was not adopted. With that said, the machinery is not *that* complex, the server produces N CIDs that it's willing to recognize, the client is free to drop them if it does not intend to use them. It's not exactly something terribly difficult.

QUIC permissiveness

Posted Nov 29, 2023 16:59 UTC (Wed) by paulj (subscriber, #341) [Link] (1 responses)

You just update the window when the other side uses a new CID. (Maintain 1 pool for each side, as is done now). Yeah, the explicit message based stuff is not terribly difficult. But it's a bunch of extra pointless code on top of that (and at least some implementations are already using a derivation function from the shared secret to generate their CIDs!). Anyway, just a nit.

My real gripe though is that QUIC /also/ requires to support no-CID, 4-tuple. So 2 distinct ways required to demux the incoming packet and match up to and validate to the connection state (and /both/ ways require 4-tuple lookup and validation, just differently). Just... annoying.

QUIC permissiveness

Posted Nov 29, 2023 17:06 UTC (Wed) by paulj (subscriber, #341) [Link]

Oh, one other annoyance in QUIC. A network protocol, created in the 21st C, and the framing does /not/ have a length field. (And QUIC has variable length encoding!). So if you add a frame type, any tooling like wireshark will fail to parse a packet once that new frame type is there. Any other frames past that that it could recognise - tough.

Really annoying.