New test: stateless reset

[ghedo]

The idea would be to create a connection to the server, close it, wait a bit, then send a Short header packet using the encryption keys and connection IDs from the closed connection. If the server sends something back in response, check that is matches the stateless reset token from the previous connection.

Not sure how feasible this is though...

[mpiraux]

I was always wondering how to test Stateless Reset. Is there more text now that impose the server to send a SS in such cases ? It could also send back the packet with the Connection Close instead of an SS, right ?

[ghedo]

The server doesn't need to do anything, but when receiving a packet that it can't associate with a connection it MAY send stateless reset https://quicwg.org/base-drafts/draft-ietf-quic-transport.html#rfc.section.10.4

Sending connection close is not really an option, because the server wouldn't have the required encryption keys (as there is no connection state), but it could do nothing (i.e. stateless reset is not mandatory).

Though I think it would still be useful for quic-tracker to have a test for this, for the servers that do implement SS.

[mpiraux]

Sending connection close is not really an option, because the server wouldn't have the required encryption keys (as there is no connection state), but it could do nothing (i.e. stateless reset is not mandatory).

The spec allows you to buffer and retransmit the last packet containing a CC frame as is. But doing nothing is also valid indeed. I have a test on the way that should be part of tonight's run!

[mpiraux]

It turned out to be very easy to implement. It goes:

• Handshake
• Waits 2 sRTT
• Closes the connection
• Waits 8 sRTT
• Sends 3 pings, spaced by 3 sRTT each