Re: [quicwg/base-drafts] Handling of connection ID in handshake creates corner cases (#843)

[Christian Huitema <[e-mail]>]

What might work is, look for an ACK Frame in the incoming Server Clear Text, and check that the "largest acknowledged" sequence number matches the sequence number of the client initial packet. Ignore the Server Clear text (and do not update the connection ID) if it does not carry an acknowledgement, or if the acknowledged number does not match the client initial sequence number. But this is not what the spec currently says:
>  5.4.3. Server Cleartext Packet
>
> A Server Cleartext packet uses long headers with a type value of 0x04. It is used to carry acknowledgments and cryptographic handshake messages from the server.
>
> The connection ID field in a Server Cleartext packet contains a connection ID that is chosen by the server (see Section 5.6).
>
> The first Server Cleartext packet contains a randomized packet number. This value is increased for each subsequent packet sent by the server as described in Section 5.7.
>
> The payload of this packet contains STREAM frames and could contain PADDING and ACK frames.

So, if we want to be robust, we may need to update that text: mandate that servers insert an ACK frame in the Server Clear Text, and allow clients to check for presence and value of the ACK frame.

-- 
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/843#issuecomment-335242018