Hi Emeric, On Tue, Sep 26, 2023, at 00:03, Emeric Brun wrote:
> 17.2.5.2: " A client sets the Destination Connection ID field of this > Initial packet to the value from the Source Connection ID field in the > Retry packet. > > Server must check this? This is what my Server current implementation > tries to do this but doing that it is unable to validate the token at > step (5) and drops some INIT packets from the client. The server does not need to check this part. The client is expected to set the DCID on subsequent Initial packets because this is what will ensure that the packet is routed correctly. Anything else and it is possible that the Initial and token will not reach a server that are able to understand the pair of messages. Consider the case where you have different token keys on different server instances. That is possible under the QUIC design, because the server instance can choose a connection ID that will route to a specific instance. If the client does not follow the rules and copy the SCID from the Retry into the DCID of the subsequent Initial packets, then maybe it will work (because the server doesn't check) or maybe it will. It can fail either because the server does or because the packet gets routed to an instance that rejects the attempt to make a connection. If you want to statically enforce this behaviour at a server, then you will need extra state (either at the server or in the token, as you say), but I don't think you absolutely need to do this enforcement. Perhaps we should have said something about what a server can do here -- maybe with a "MAY" -- though I don't think this is a huge problem. My own implementation of this logic only stores a timestamp and the DCID from the very first client Initial in the retry token plaintext. The source address is added to the AAD to save space. Of course, that is a toy implementation, so don't pay too much attention. You might have good cause to track other state. Cheers, Martin
