On 12/08/2025 21:20, Christian Huitema wrote:
Hello Ren,
Yes, the reporting of ACK delay depends entirely on the endpoint
generating the ACK packets. And yes, the endpoint can try to fake the
delay to somehow disturb the connection. A query on the GitHub depot
used during the development of the specifications will find a large
number of related issues, see for example:
https://github.com/quicwg/base-drafts/issues?q=is%3Aissue%20ack%20delay.
The specs do include some protections against excessive values of the
ACK DELAY:
- the Min RTT is always computed based on the actual measurement,
before compensating the ACK delay.
- if compensation for the ACK delay results in a value lower than Min
RTT, then the RTT sample is ignored.
- if the ACK delay is larger than the max ACK delay announced by the
peer, the extra value is used in the computation of the smoothed RTT.
You are correct that because the max ACK delay is announced by the
peer, the effectiveness of the last mitigation is limited. It might
make sense for implementations to limit the max ACK delay value that
they accept, not just rely on than the 16s maximum. The "max ack
delay" is further discussed in the ACK Frequency draft,
https://datatracker.ietf.org/doc/html/draft-ietf-quic-ack-frequency,
which allow endpoints to signal a "requested max ack delay". It would
be natural to add something about the issue in the security section of
that draft.
-- Christian Huitema
The quality of the implementation at the peer and design/configuration
does impact the sender's ability to respond to feedback provided by the
peer. In most transport protocols we need to trust the peer in some way.
It is true (as in this case) that a receiver could (for whatever reason)
send packets that disupt protocol operation at the sender. A sender can
only provide some sanity checks on what is acceptable
Whilst we do need to design for off-path attacks, which disrupt packets
in flight without knowlegde of their context, and sometimes for on-path
attacks that modify packets, I would not regard a broken/malicious
receiver as a part of the security model.
Gorry
On 8/5/2025 10:40 PM, [email protected] wrote:
Dear QUIC Working Group Members,
We have identified a potential vulnerability in QUIC's host delay
feedback mechanism (RFC 9000 and 9002), which impacts delay-based
Congestion Control Algorithms (CCAs).
1.Core Issue: Host Delay Manipulation Affecting CCAs
We have found that the current Host Delay field allows a malicious
receiver to distort the sender's RTT estimation by reporting
falsified host delays. This can directly impact delay-sensitive CCAs
(e.g., Copa, Vegas, PCC Vivace...) with false under-estimation of
network congestion and cause senders to over-issue packets.
Furthermore, co-existing flows sharing bottlenecks are forced to
experience throughput degradation.
Under controlled conditions (30Mbps bandwidth, 30ms RTT), our
experiments show that manipulating host delay can significantly
induce delay-based CCA overtransmission. This artificial
overtransmission congests the shared bottleneck, severely throttling
any competing victim flows. Compared to attack-free scenarios where
two flows using normal CCAs compete fairly over a shared bottleneck,
this manipulation causes throughput degradation up to 50% for
delay-based CCAs (Vegas, Copa), and exceeding 50% even for
non-delay-based CCAs (e.g., CUBIC) in the victim flow.
2.Impacts on RTT-Dependent Mechanisms
max_ack_delay is the maximum acknowledgment delay (up to 2^14 ms)
sent from a receiver to the sender, a constraint subject to
utilization in host delay, and also used for calculating PTO.
Malicious receiver can greatly increase the sender's PTO up to around
16s by simply setting a large max_ack_delay, leading to
miscalculation of the sender's PTO.
3.Proposed Mitigation Directions:
Replacing normative requirements for Host Delay usage with
demonstrative implementation examples might preserve CCA robustness
without QUIC architectural changes:
1. a)
Explicitly document Host Delay's potential vulnerability and
susceptibility to manipulation (e.g., noting that a malicious
receiver MAY artificially inflate delay values);
2. b)
Outline sender-side mitigation patterns, such as:
*
●disable Host Delay locally (despite potential RTT accuracy
loss);
*
●deploy validation mechanisms as measured alternatives (e.g.,
statistical anomaly detection for untrusted peers) to reject
outlier max_ack_delay and Host Delay values.
Sincerely,
Ren
Institute for Network Sciences and Cyberspace, Tsinghua University
Contact: [email protected]
