Re: [quicwg/base-drafts] Stateless Reset packet sizes should not depend on the maximum connection ID length (#2869)

[David Schinazi <[e-mail]>]

I agree with this threat model. We really want to avoid NATs reacting to stateless resets the way they react to TCP RSTs today.

However, we've heard from implementors that the majority of QUIC traffic will not use client connection IDs. But there will be an implementation that uses them (either all the time, or at least some of the time, to apply grease to servers to make sure they support them). Let's assume there is a client implementation called CLIENT_18 that always uses 18-byte client CIDs. Do you think someone will go out of their way to implement code that detects CLIENT_18 traffic, and then installs a rule for those connections only where the detection of a server-to-client packet shorter than 39 bytes will drop the NAT mapping? This sounds about as likely as a NAT implementation that drops packets whose connection IDs are prime numbers...

To answer your question on reliability: I think it will be common to have a client establish a connection, send some requests, get the responses, then idle for a few minutes, then after user action, sends another request. Assuming the server uses 8-byte CIDs, this will cause the client to send a packet than can easily be under 39 bytes (assuming a short request). Let's assume the server has restarted during the idle period. It won't recognize the connection ID. If the server decides that this packet is too short to trigger a stateless reset, then the client will timeout causing user-visible delays. For a protocol with such a goal of improving latency, a timeout is a critical failure.

The issue here is that the spec doesn't mandate the client to pad its packets, and allows servers to not respond to short packets. Giving both implementations too much leeway is dangerous here.

It would be in the spirit of the spec to be more prescriptive. We remove the 39-byte requirement, and tell servers that their stateless resets should be of length in the range `[min(39, client_packet_size - 1), max(39, client_packet_size - 1)]`. We then tell clients to pad their packets such that `packet_number_length + payload_length >= 4 + max(0, max_used_client_cid_length - server_cid_length)`.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2869#issuecomment-508884624