-
Notifications
You must be signed in to change notification settings - Fork 203
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Retry packet and Server-Chosen Connection ID #713
Comments
From editors' discussion on this: Our joint recollection is that a new Connection ID can be sent along with the HRR, potentially in a TLS extension. The client uses it in the subsequent Client Initial. The server-side load balancer treating it as a client-chosen connection ID, which means that the server that sent the HRR should, if it wants redirection, generate this Connection ID accordingly. For verification, the server can send a cookie along with HRR that contains the proposed connection ID, which the client echoes in new Client Initial. |
Based on re-reading the draft, I don't believe this was ever written up. Also, if we do this in an extension, which I like, can we stop having the server unilaterally change the connection ID and instead have the server inform the client to change the connection ID with the TLS extension? That would solve #714 cleanly I believe. |
Part of why we were echoing the connection ID in Retry is now no longer relevant. We now have encryption providing the primary proof of receipt for the Initial packet. Allowing the server to pick a new connection ID and include that in the Retry packet header allows servers to steer clients. Closes #713.
Part of why we were echoing the connection ID in Retry is now no longer relevant. We now have encryption providing the primary proof of receipt for the Initial packet. Allowing the server to pick a new connection ID and include that in the Retry packet header allows servers to steer clients. Closes #713, #1041.
In Paris, there was discussion about allowing the server to change the Connection ID on a Server Stateless Retry. However, the spec doesn't actually define how to do this. Currently, it says to start a new connection, which could be read to imply a newly-random Connection ID.
For load-shedding, it would be nice to enable the server to point the client to a new server, which likely implies carrying it in the HelloRetryRequest.
The text was updated successfully, but these errors were encountered: