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
