QUIC permissiveness

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

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.