mirror of
https://git.haproxy.org/git/haproxy.git/
synced 2025-12-27 04:21:00 +01:00
3c250cb847
This reverts commit 072e77493961a06b89f853f4ab2bbf0e9cf3eff7. Doing h2load with h3 tests we notice 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) With (5) dropped by haproxy due to token validation. Indeed the previous patch adds SCID of retry packet sent to the aad of the token ciphering aad. It was useful to validate the next INIT packets including the token are sent by the client using the new provided SCID for DCID as mantionned into the RFC 9000. But this stateless information is lost on received INIT packets following the first outgoing INIT packet from the server because the client is also supposed to re-use a second time the lastest received SCID for its new DCID. This will break the token validation on those last packets and they will be dropped by haproxy. It was discussed there: https://mailarchive.ietf.org/arch/msg/quic/7kXVvzhNCpgPk6FwtyPuIC6tRk0/ To resume: this is not the role of the server to verify the re-use of retry's SCID for DCID in further client's INIT packets. The previous patch must be reverted in all versions where it was backported (supposed until 2.6)