Re: [quicwg/base-drafts] Handling of corrupt Retry packets (#3014)

[Martin Thomson <[e-mail]>]

Even if we do nothing here, we need to note that UDP checksums are a good idea (cite RFC 8085, Section 3.4).  And we need to point out that a bad Retry token will result in the server dropping the packet.  Also, corruption of Retry could make it hard to distinguish between Retry tokens and NEW_TOKEN tokens unless the discriminator the server uses is in the clear (in which case, the distinction is erased, but that seems unlikely, or maybe you can create markers with a Hamming distance >1 so that bit flips are less likely to erase that signal.

Advice for clients would be to make a new connection if an Initial with a token times out.  What is likely to happen for HTTP - at least in the near term - is that clients will fall back to TCP.

@ianswett suggests that we could allow a server to generate a CONNECTION_CLOSE in response to an Initial with a token that is probably an invalid Retry token.  This would allow the server to signal to the client that the connection is busted.  However, this won't work if we make the proposed change to retain the Initial keys after Retry (#2823), because the server won't be able to get the original keys.

-- 
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/3014#issuecomment-542388445