It might or might not be safe to use the ACK Delay in an Initial packet, but I don't think you can even consistently know what the delay is until the transport parameters have been received.
I believe a server always knows its peer's max_ack_delay by the time it has Handshake keys, but a client could receive Handshake ACKs before receiving transport parameters. On Tue, Jun 13, 2023 at 3:21 PM Marten Seemann <martenseem...@gmail.com> wrote: > 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 <dneil= > 40google....@dmarc.ietf.org> 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? >> >
