QUIC permissiveness

Posted Nov 28, 2023 19:40 UTC (Tue) by riking (guest, #95706)
In reply to: QUIC permissiveness by paulj
Parent article: OpenSSL 3.2.0 released

And don't forget that they added the spin bit back in, which explicitly allows middleboxes to measure E2E latency. More complexity!

QUIC permissiveness

Posted Nov 29, 2023 13:58 UTC (Wed) by paulj (subscriber, #341) [Link] (2 responses)

Spin bit is kind of neat. Not too complicated to support. Though, not entirely accurate either.

I'm in 2 minds about the loss of insight into performance of transport flows with QUIC. With TCP you can capture and make nice sequence graphs showing exactly what's going on from a network POV. With QUIC, that is lost - unless you have the private key. Which a network operator will not have, and which even the application owner generally will not retrospectively have. It's a real shame to lose that insight. On the other hand, it's nice to make the transport opaque.

Does QUIC have the balance right? I don't know.

QUIC permissiveness

Posted Nov 29, 2023 14:32 UTC (Wed) by farnz (subscriber, #17727) [Link] (1 responses)

The network operators have demonstrated that if they have the private key, they will misuse it (as they have misused the ability to tamper with TCP traffic beyond port numbers changing in a NAPT). It's just a shame that applications don't make it easy to record the private keys for retrospective analysis by the owner of an endpoint.

QUIC permissiveness

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

You don't need to give operators the private key to let them see information. E.g. the QUIC header is not encrypted (but is part of the MAC, so can not be tampered with) - that's why they can see the spin bit.

Might it be better to give the network a bit more and higher-quality information about the congestion-related state of the flow, so network operators could debug problems?... maybe.