Draft: draft-ietf-quic-transport

Commentary: The text was a little too broad . This breaks up the text and adds two caveats to handling rules : you have handled another packet , then assume that everything is good . you the VN includes QUIC v1 , then assume that something got corrupted . The issue addresses the second , but I think we were implying the first for some time . 
 The " packet corruption " test that 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 do n't know how frequent packet corruption is today . The 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 do n't know whether the 1997 measurements are still valid . They could be higher . I also do n'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 ? 
 We used to require that a client ignore Version Negotiation packets that include the version the client attempted . edited that out . Maybe we should restore it . That pushes the odds of failure to 1 in 90 quadrillion . Would that help ? I want to say that this is a design issue . 
 The problem with the " one in 300 million " figure is that it relies on the UDP checksum . If you can not trust the UDP checksum , the figure is " 1 in 5000 " , which is more concerning . And there are scenarios in which uncontrolled middle - boxes do rewrite that checksum . 
 I 'd support restoring that check that edited out . Anecdotally , we 've found packet corruption to be very rare and basically a non - issue . Or maybe something in the network or the host is just dropping them , but we do n't receive them in userspace . 
 I 'm fine with adding this check back in . It 's not onerous to implementers . This is a design issue . 
 Now if we were really paranoid , we would consider the possibility that the VN packet itself is corrupted . 
 I did . If we do n't trust the UDP checksum on either , the error rates are still pretty high , but either checksum bumps it up to 1.5 trillion and both is 90 quadrillion . 
 I was thinking about that -- it does n't need paranoia , it 's just a question of how often -- and in this case the chances are vanishingly small . 
 To clarify the statement , that happened when we decided to move version negotiation to an extension . The states that - I 'd be supportive of adding a sentence such as 
 I support the change . Does the general concern about security proofs that is driving us to authenticate the CIDs also apply to the version field ? 
 The security concerns do apply to the version field , our current plan to address that is . 
 Thanks , but is it sufficient for this to be an extension ? What if the base spec is n't provably secure ? 
 there 's still time for us to make the use of that extension mandatory before we ship , but I 'd suggest having that discussion on a separate issue . 
 Works for me .
Paragraph (version A):
When a client receives a Version Negotiation packet, it MUST abandon
the current connection attempt.  Version Negotiation packets are
designed to allow future versions of QUIC to negotiate the version in
use between endpoints.  Future versions of QUIC might change how
implementations that support multiple versions of QUIC react to
Version Negotiation packets when attempting to establish a connection
using this version.  How to perform version negotiation is left as
future work defined by future versions of QUIC.  In particular, that
future work will need to ensure robustness against version downgrade
attacks; see version-downgrade.
Paragraph (version B):
Version Negotiation packets are designed to allow future versions of
QUIC to negotiate the version in use between endpoints.  Future
versions of QUIC might change how implementations that support
multiple versions of QUIC react to Version Negotiation packets when
attempting to establish a connection using this version.
Paragraph (version B):
A client that supports only this version of QUIC MUST abandon the
current connection attempt if it receives a Version Negotiation
packet, with the following two exceptions.  A client MUST discard any
Version Negotiation packet if it has received and successfully
processed any other packet, including an earlier Version Negotiation
packet.  A client MUST discard a Version Negotiation packet that
lists the QUIC version selected by the client.
Paragraph (version B):
How to perform version negotiation is left as future work defined by
future versions of QUIC.  In particular, that future work will ensure
robustness against version downgrade attacks; see version-downgrade.