Draft: draft-ietf-quic-version-negotiation

Commentary: confirmed offline that he can live with this PR as - is , so I 'm merging it 
 Currently at says future versions might allow the long header version to be different from the chosen version in the versioninfo transport parameter . But there 's nothing about what to do until such a version exists which changes the semantics of the chosenversion . This is in the initial packet , before incompatible version negotiation , and before compatible version negotiation , has happened . Which error should the handshake be closed with ? says that version info transport parameter parsing errors should use the transport parameter error . 
 Thinking about this some more , I think draft - ietf - quic - version - negotiation does n't need to say anything more , as those details are specific to the compatibility version document . So I opened to discuss this there . 
 I 'm a little confused because this document explains which errors should be used with QUIC v1 when closing the connection on failure to parse the transport parameter or invalid versions ( i.e. 0 ) . In the absence of another compatibility version document , should n't this document specify the error for QUIC v1 ? Or are you saying this is not an error in QUIC v1 , but could be an error in , e.g. , QUIC v2 ? 
 This only causes an error when there are two versions involved - and therefore that scenario should be covered by the document that defines compatibility between those two versions . Or do you have a scenario in mind where one version is QUICv1 and the other is unknown ? I 'm noticing that RFC 9000 does n't say what you 're supposed to do if you receive a packet from another version - I think the assumption is that you silently drop it because you do n't know how to parse it . 
 Agreed that I should specify the v1 / v2 case . But perhaps the VN draft should handle the behavior when the long header has a known version ( certainly v1 ) and the Chosen Version is unknown ? ( I imagine that allowing this allows us to have a backdoor for version upgrade if the version field ossifies ) 
 I would recommend that a server sends a VN packet in this case , and a client kills the connection -- there is no valid reason for the server to slip in a version the client did n't advertise . 
  what originally wrote along with comments , I think we can tighten up the validation requirements in this spec to prevent tampering . I 've written it up as , please take a look . I went with forcing a close instead of your suggestion , because this back door would weaken the protocol ( allows tampering ) without helping ( if the long header ossifies we can use compatible VN as our backdoor ) . 
 I 'm not sure compatible VN is sufficient . If someone writes a firewall that says " drop all Long Headers with version = = 4 " I do n't see that compatible negotiation solves the problem -- all the long headers have to say v1 and the actual negotiation happens using TPs . Though I have n't fully thought this through , and certainly not any backdoor implications . 
 Note that the requirement is only for the client 's first flight . So you work around that firewall by defining v1 - to - v4 compatibility as always setting Version=1 in long headers 
 Yeah , I think that works . 
 WFM .  pointed out that this already defines " in use " and the change to " processes " is good . LGTM
Both endpoints MUST parse their peer's Version Information during the
handshake.  If parsing the Version Information failed (for example,
if it is too short or if its length is not divisible by four), then
the endpoint MUST close the connection; if the connection was using
QUIC version 1, that connection closure MUST use a transport error of
type TRANSPORT_PARAMETER_ERROR.  If an endpoint receives a Chosen
Version equal to zero, or any Available Version equal to zero, it
MUST treat it as a parsing failure.
Both endpoints MUST parse their peer's Version Information during the
handshake.  If that leads to a parsing failure (for example, if it is
too short or if its length is not divisible by four), then the
endpoint MUST close the connection; if the connection was using QUIC
version 1, that connection closure MUST use a transport error of type
TRANSPORT_PARAMETER_ERROR.  If an endpoint receives a Chosen Version
equal to zero, or any Available Version equal to zero, it MUST treat
it as a parsing failure.  If a server receives a Version Information
where the Chosen Version is not included in Available Versions, it
MUST treat it as a parsing failure.
When a server receives a client's first flight, the server will first
establish which QUIC version is in use for this connection in order
to properly parse the first flight.  For example, the server
determines that QUIC version 1 is in use by observing that the
Version field of the first Long Header packet it receives is set to
0x00000001.  When the server then processes the client's Version
Information, the server MUST validate that the client's Chosen
Version matches the version in use for the connection.  If the two
differ, the server MUST close the connection with a version
negotiation error.  For example, if a server receives the client's
Version Information over QUIC version 1 (as indicated by the Version
field of the Long Header packets that carried the transport
parameters) and the client's Chosen Version is not set to 0x00000001,
the server will close the connection with a version negotiation
error.
If a client receives a Version Information where the server's Chosen
Version was not sent by the client as part of its Available Versions,
the client MUST close the connection with a version negotiation
error.