Re: [quicwg/base-drafts] Long Header Packets and Routing Connection IDs (#2834)

[Mike Bishop <[e-mail]>]

I think the different viewpoints here implicitly assume different properties of the CID.

- If server-generated CIDs are easy for the server to recognize, but hard for an attacker to duplicate, then @kazuho's design makes perfect sense -- check whether the CID in an Initial is yours, and route based on it if so.
- If they're either difficult to verify or easy to forge, then you should only route based on CID if you retain enough state / embed enough state in the token to recognize when the client has switched to your CID and assume anything else is client-generated and untrustworthy.

Handshake packets can't be sent until you've seen the server's Initial, which means that Handshake *can* always carry the server's selected CID, but we could decide otherwise without breakage.  0-RTT packets have to start with the ODCID, and they could change or not.  Initial packets after the first round trip could change or not.

My inclination is that server infrastructure SHOULD NOT route based on the CID in an Initial or 0-RTT packet, even if the client has switched to the one you gave it; you also SHOULD NOT route based on CID for a version you don't understand.  In that case, it really doesn't matter whether the client switches upon receipt of your Initial.  They can start using the server's CID in Handshake and short-header packets.

-- 
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/2834#issuecomment-505209548