Re: [quicwg/base-drafts] Invert the connection ID logic during the handshake (#442)

[janaiyengar <[e-mail]>]

Correction: the current scheme *does* allow a load balancer to distinguish between client and server-chosen connection IDs (see Section 5.7), but it does not allow a client to start with a server-chosen connection ID. Thinking about this issue some more, there's a tradeoff here.

The current scheme has the client sending a random ID on first packet and eventually the final ID on a successful handshake. This means that the client cannot use a server chosen connection ID on a re-connection attempt (after a version negotiation, or after a stateless reject, for instance), but part of the point of using server-chosen connection IDs is to limit DoS-ability. This design makes it so that any initial client packets are load-balanced among all available servers, and only packets sent after successful handshake are directed to a single server.

This proposed scheme doesn't spell it out yet, but is useful when the client sends a random ID or a previously-server-chosen ID on the first packet and then a server-chosen final ID (the same or a new one) on successful handshake. This allows for the server to specify a connection ID for the client to reconnect with on a Version Negotiation or a stateless reject. However, allowing a client to say that the connection ID is server-chosen has DoS-ability similar to the previous client-chosen connection ID scheme (in draft version -01).

-- 
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/442#issuecomment-297146659