On 10/16/26 13:13, Yeonggi Kim wrote:
> Hi Amaury, Frederic,
>
> While looking at our Retry statistics, I noticed a difference between
> 3.2 and 3.3+ in qc_new_conn(), and I would like to know whether it is
> intended.
>
> In 3.2, a listener connection created from an Initial packet with an
> already checked token is considered as having a validated peer address,
> whatever the token format. The condition is "token", which is set from
> pkt->token_len. Since 29fb1aee5 ("MINOR: quic-be: QUIC connection
> allocation adaptation (qc_new_conn())", 3.3-dev2), the condition is
> token_odcid->len, which is only set for a Retry token. So a connection
> created with a valid NEW_TOKEN token is now counted in half_open_conn,
> and it is subject to the anti-amplification limit until a Handshake
> packet is received. The commit message only mentions the QUIC backend
> side, so I wonder if this part was intended.
>
> I checked it with an aioquic client. A first connection gets a
> NEW_TOKEN token, then a second one uses this token while the server
> replies are dropped, so that the handshake does not complete. No Retry
> is emitted, so the token is accepted. While the second connection is
> pending, quic_half_open_conn is 0 on 3.2.23, and 1 on 3.4.7 and on
> current master.
>
> Regards,
> Yeonggi Kim
>
>
>
I have just pushed a fix for this bug here:
https://github.com/haproxy/haproxy/commit/7b37fe84dc95d793ca40c5a5104e9fc1d045f1ca
Thank you!
Fred.
