Hi, Performing some test using h2load+h3 I noticed this behavior
Client ---- INIT no token SCID = a , DCID = A ---> Server (1) Client <--- RETRY+TOKEN DCID = a, SCID = B ---- Server (2) Client ---- INIT+TOKEN SCID = a , DCID = B ---> Server (3) Client <--- INIT DCID = a, SCID = C ---- Server (4) Client ---- INIT+TOKEN SCID = a, DCID = C ---> Server (5) But I notice an issue here on packet (5), it is related to the way the token is generated: Indeed, for packet (2) the SCID value "B" is randomly chosen and to defer the state processing costs of connection establishment, it generates a token supposed stateless. This token includes a ciphered version of the ODCID+a timestamp, but it also uses AHEAD. In AHEAD sig are included the client information, to validate the source is still the same but also includes the SCID of the generated retry packet (2) to validate that subsequent init packet including the token is re-using the CID computed by the server to generate the retry packet. Doing this validation of the token receiving (3) is ok, and the server allocate a session and respond an INIT (4) showing an new SCID "C" and this one allow to statefuly identify the connection on further packets. Packet (5) shows that the Client consider the new CID "C" provided by the server witch now identifies a statfully connection on server side. The issue appear at this packet (5), here the client re-use the new CID "C" and continue to post the token. But the server is unable to process a stateless validation of this token since the value "B" is no more present in the incoming packet. However, this session now exist on the Server side. I read multiple time the RFC but it remains unclear what the server is supposed to do about token validation, especially for received init packets from the client "after" session establishment (client's INIT using DCID offered by an SCID INIT packet from the server). 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. Perhaps the right thing to do is to store the "B" value into the session on server side for further INIT+token validation for packet matching an exisitng session instead of DCID present in the packet. Or store it into the token itself instead of aad and compare, but it will grow the token. Regards, Emeric
