Dear Christian, Gorry, and all, Thank you for the insightful comments and discussion on this issue! Yes, malicious receiver behavior may not appear as a typical off-path or on-path attack. However, we believe it is still worth paying attention to receiver-side malicious behavior for two reasons:
First, we would like to clarify that receiver behavior can indeed influence sender behavior, particularly when such actions negatively affect other users on the Internet. The risks we identified in the design of Host Delay could be exploited by an attacker to cause the sender’s CCA to malfunction and over-transmit data. This may further lead to reduced throughput for background traffic, congestion on critical links, and degraded service quality. Second, regarding the question of whether such an actor should be considered an "attacker", while it is different from traditional on-path or off-path categories, there has been prior work examining malicious receiver behavior. For instance, RFC 9000 (§21.4) specifically discusses Optimistic ACK Attack (a receiver-based attack) and corresponding defenses (https://www.rfc-editor.org/rfc/rfc9000.html#name-optimistic-ack-attack). Therefore, we think that interference with sender operation— even when originating from the receiver side— merits consideration in our threat discussions. Thank you again for your valuable insights. Our preliminary idea, as Christian suggested, is to consider documenting potential malicious receiver behaviors in a future QUIC draft. Best regards, Ren Institute for Network Sciences and Cyberspace, Tsinghua University Contact: rs...@mails.tsinghua.edu.cn > > 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, 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 >
