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

[Nick Banks <[e-mail]>]

I discussed this on Slack and opened a related issue on the [QUIC-LB doc](https://github.com/martinduke/draft-duke-quic-load-balancers/issues/43), but I think the real issue needs to be discussed here. The issue here is how a server (it's LB specifically) is supposed to statelessly route Long Header packets. Right now, the client immediately changes the destination CID it puts in its packets to the server chosen CID. This results in all Initial and Handshake packets it sends after the first (successful) flight of packets are received and acknowleded/responded to by the server.

So, practically, that means Long Header packets could have one of two types of CIDs: client chosen or server chosen. To prevent attack vectors from being exposed, the LB practically needs to use different routing logic for each type of CID. We don't want an attacker to explicitly control which backend server it creates a new connection to. The problem arrises because we have no way to differentiate which type of CID is included in the Long Header packets processed by the LB.

**Proposal**: All Long Header packets use the client chosen CID, to allow for consistent routing of these packets.

Now, if we agree that the CID doesn't change until Short Header packets are used, then that means we don't have to use the current implicit mechanism for changing the CID in response to the first server packet received. We can instead exchange it, encrypted with the Handshake keys; possibly a new transport parameter; or just the first NEW_CONNECTION_ID.

-- 
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