[quicwg/base-drafts] Defense against version number corruption (#3532)

[Christian Huitema <[e-mail]>]

The "packet corruption" test that @marten-seemann added to the interop-runner has surfaced an issue about version number corruption. Suppose that a long header packet is corrupted in transit, and that the corruption changes the value of the version number. Per spec, the server will respond with a version number negotiation packet. In the test, we observe that when clients receive such packets, they abandon the connection attempt.

Obviously, this is a rare event. We don't know how frequent packet corruption is today. The [1997 paper by Vern Paxson ](https://cseweb.ucsd.edu/classes/wi01/cse222/papers/paxson-e2e-packets-sigcomm97.pdf) measured "1 packet in 5000". In theory, only one in 2^16 of these corruptions would not be detected by the UDP checksum, leading to undetected corruption in 1 in 300 million packets.

That's a very small number, but I don't know whether the 1997 measurements are still valid. They could be higher. I also don't know whether the loss patterns would be detected by the UDP checksum, since some middleboxes appear to rewrite these checksums. Faced with exactly the same issue, we decided recently to add a checksum to the Retry packets.

Clients can protect against such corruptions by checking the incoming VN packets for sanity. If the server issues a VN in response to a corrupted packet, the list of supported versions will include the version proposed by the client. That should normally never happen. Ignoring such bogus VN does protect against most version number correction issues. Should we point that out in the spec?

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