Re: [quicwg/base-drafts] Add sequence number to NCID frame (#1821)

[Mike Bishop <[e-mail]>]

MikeBishop requested changes on this pull request.

We either need a requirement that each CID be unique for the lifetime of a connection (potentially difficult to guarantee unless you're encrypting a payload with a counter inside), or we need sequence numbers in RETIRE as well.  Otherwise, it's possible for a delayed RETIRE to retire the wrong instance of a duplicate.  (My inclination is actually "both," but at a minimum we need one or the other.)

I recognize the problem of missing sequence numbers, but it's easy enough to say that the CID from the handshake is CID 0 and the sequence number from the SPA is CID 1 if present.  At that point, everything has a sequence number and we could save some bytes on RETIRE.

> @@ -3285,8 +3292,10 @@ zero-length Destination Connection ID MUST treat receipt of a NEW_CONNECTION_ID
 frame as a connection error of type PROTOCOL_VIOLATION.
 
 Transmission errors, timeouts and retransmissions might cause the same
-NEW_CONNECTION_ID frame to be received multiple times. Receipt of the same
-frame multiple times MUST NOT be treated as a connection error.
+NEW_CONNECTION_ID frame to be received multiple times.  Receipt of the same
+frame multiple times MUST NOT be treated as a connection error.  A receiver can
+use the sequence number supplied in the NEW_CONNECTION_ID frame to identify new
+connection IDs from old ones.

For the first, I think we need to require the sender to always increase by one.  That way, the receiver could assume they're in flight.  That's one argument for putting the sequence number on RETIRE, since you could preemptively retire CIDs that are in-flight but not yet received.  Otherwise, you wind up with gaps which the issuer could choose to fill at any time, and the recipient has to keep track of the sparse set of retired/available IDs.

For the second, I don't think it would be unreasonable to abort the connection if it still remembers what CID was with that sequence number, but we shouldn't require that behavior because it might have been forgotten.  Just drop based on the sequence number if it's a repeat.

-- 
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/pull/1821#pullrequestreview-160848192