Connection ID on a version negotiation packet

[martinthomson]

Given that we have opted to go with #119 universally, it might be reasonable to think that the server could make a proposal for the connection ID on a version negotiation packet. However, it probably isn't a good idea. Since version negotiation is stateless, there is less need to have stable routing for this packet. Echoing the connection ID gives the client better assurance that its initial packet was what generated the response.

[martinthomson]

Hmm, not sure if this is a duplicate of #244.

[igorlord]

The first part ("should a version negotiation packet from the server -- a proposal to the client to change its version -- contain a Server-generated Connection ID?") is a new issue. On one hand, I agree with you that this seems a bit like a kludge. On the other hand, stable routing may actually be required by some systems.

Imagine a pop with a load balancer and a number of backends behind it. One may want to roll out a new experimental version of QUIC on a subset of backends. To do that, the system should ensure that the same server that send a version negotiation packet proposing a new QUIC protocol version actually receives packets using the new version (if the client accepts that new version). Our mechanism to make sure this happens is to encode the backend ID in the Server-proposed Connection ID.

The second part (proving that the sender of the version negotiation packet is on-path) is a dup of #244.

[MikeBishop]

#361 purports to address this; please re-open or file a new issue if that's incorrect.