It might not be safe to use the ACK Delay received in an Initial packet. An attacker could rewrite the value such that the client's RTT estimate becomes very close to zero, which would lead to very short retransmission timers.
quic-go therefore neither sends nor acts upon ACK delays reported in Initial packets. I thought we had text about that in the RFC, but I can't find it. The closest I can find is RFC 9002 Section 5.3, which states that Initial ACK Delays MAY be ignored, because Initial packets are supposed to be acknowledged immediately. On Wed, 14 Jun 2023 at 00:40, Damien Neil <[email protected]> wrote: > An endpoint's ack_delay_exponent is conveyed in its transport parameters. > > An endpoint can receive an ACK before it receives transport parameters > from the peer. For example, a client may read an ACK in an Initial packet > before it receives transport parameters in a Handshake packet. > > RFC 9000 isn't clear (IMO) on how to interpret an ACK Delay fields prior > to receiving transport parameters. Valid options might be to treat all ACK > Delay fields as 0 until an ack_delay_exponent is known, or to use the > default value of 3 for Initial and Handshake packets and only apply the > transport parameter for 1-RTT packets. Am I missing text somewhere which > explains the expected behavior? >
