[quicwg/base-drafts] loss of only two packets can lead to an unrecoverable situation (#2267)

[Marten Seemann <[e-mail]>]

Assume that client and server handshake successfully, all packets containing handshake data are received, but the ACK for the CFIN message is lost. Furthermore, assume that the RTT is `x` and there is negligible RTT variance (just to simplify my example).
At this point, the server considers the handshake as completed, and starts its timer to drop the Handshake keys after 3 times the PTO timeout. 3 PTOs equals a duration of `3x`. The client doesn't consider the handshake as completed, since it didn't receive the ACK for the last Handshake packet it sent. On sending that packet, it already set a the crypto timeout timer to a duration of twice the RTT, i.e. `2x`.
When the crypto timer fires, the client retransmits the CFIN. Now assume that this packet is lost (or, leading to the same outcome, the packet is received, but the ACK for it is lost again). The client resets the timer (now with backoff) to `4x` after sending the retransmission. By the time this timer fires, the server will already have dropped the Handshake key. We're now in the situation where the client will never receive an acknowledgement for the CFIN.

Note that a similar situation (with the roles reversed) can occur when an ACK for the certificate sent by the server is lost.

This scenario gets interesting when the client begins sending 1-RTT data after sending the CFIN. The server will be able to read the 1-RTT data, and send acknowledgements for it. There's nothing stopping client and server from running the application protocol, as they normally would, with one interesting caveat: The client will continue to retransmit the CFIN indefinitely and always declare it lost (and decrease its congestion window). Furthermore, the client will only be able to use ACK-based loss recovery, since it is not allowed to use probe timeouts as long as crypto data is still outstanding.

-- 
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/2267