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
On 8/5/2025 10:40 PM, rs...@mails.tsinghua.edu.cn 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: rs...@mails.tsinghua.edu.cn
