]> git.ipfire.org Git - thirdparty/haproxy.git/commit
Revert "BUG/MEDIUM: quic: missing check of dcid for init pkt including a token"
authorEmeric Brun <ebrun@haproxy.com>
Thu, 28 Sep 2023 13:29:53 +0000 (15:29 +0200)
committerWilly Tarreau <w@1wt.eu>
Fri, 29 Sep 2023 07:27:22 +0000 (09:27 +0200)
commit3c250cb84767e709d53ca985930cd0fc51605044
treeaccbc5a68f755a31db11659914a6897972c7c3a9
parentd956db663878346c8e787e566ede2ac885ed38c8
Revert "BUG/MEDIUM: quic: missing check of dcid for init pkt including a token"

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)
include/haproxy/quic_tx.h
src/quic_rx.c
src/quic_tx.c