I suggest we hold this for document update. Though I'm almost inclined to reject it, there is always room for improvement as we learn more about how to manage this sort of attack.
However, at its root, this is an editorial matter, not a flaw in the specification. (The flaw is in implementations.) As with many parts of the protocol, useful features can be abused by the malicious to attack the incautious. If we had to forward reference the warnings in every place that these traps existed, we'd have a lot of redundant text. Some implementations got hit, but that doesn't justify an erratum. We've discussed the different methods that implementations might use to deal with this class of attack numerous times and I don't think that we've ever concluded that any particular approach is worth codifying in an RFC. What strategy works best appears to depend on architectural decisions made well beyond the scope of the QUIC layer. On Fri, Apr 10, 2026, at 14:48, RFC Errata System wrote: > The following errata report has been submitted for RFC9000, > "QUIC: A UDP-Based Multiplexed and Secure Transport". > > -------------------------------------- > You may review the report below and at: > https://www.rfc-editor.org/errata/eid8875 > > -------------------------------------- > Type: Technical > Reported by: Abhinav Agarwal <[email protected]> > > Section: 8.2.2 > > Original Text > ------------- > On receiving a PATH_CHALLENGE frame, an endpoint MUST respond by > echoing the data contained in the PATH_CHALLENGE frame in a > PATH_RESPONSE frame. An endpoint MUST NOT delay transmission of a > packet containing a PATH_RESPONSE frame unless constrained by > congestion control. > > Corrected Text > -------------- > On receiving a PATH_CHALLENGE frame, an endpoint MUST respond by > echoing the data contained in the PATH_CHALLENGE frame in a > PATH_RESPONSE frame. An endpoint MUST NOT delay transmission of a > packet containing a PATH_RESPONSE frame unless constrained by > congestion control. > > As with any frame type, the general guidance in Section 21.9 > applies when excessive quantities of PATH_CHALLENGE frames are > indicative of an attack. > > Notes > ----- > Section 8.2.2 does not cross-reference the general peer DoS > guidance in Section 21.9 or make explicit that that guidance > also applies to excessive PATH_CHALLENGE traffic. As a result, > implementers reading Section 8.2.2 in isolation can reasonably > conclude that a PATH_RESPONSE must be generated for every > PATH_CHALLENGE, even under resource pressure. Because > PATH_CHALLENGE is only 9 bytes on the wire (Section 19.17), a > single minimal 1200-byte datagram can carry over 100 > PATH_CHALLENGE frames. Combined with ACK withholding to prevent > freeing of queued state, this creates a practical memory > exhaustion vector. > > In December 2023, three implementations were found vulnerable to > this pattern and issued coordinated fixes: > - quic-go: CVE-2023-49295 > - quiche: CVE-2023-6193 > - quicly: CVE-2023-50247 > (See https://seemann.io/posts/2023-12-18---exploiting-quics-path-validation/) > > Post-fix implementations have adopted incompatible defensive > strategies (bounded queuing, single-slot overwrite). Those > defenses can appear inconsistent with a literal reading of > Section 8.2.2 even though Section 21.9 already provides general > latitude to drop packets or close the connection under attack. > An explicit cross-reference would clarify this relationship. > > Instructions: > ------------- > This erratum is currently posted as "Reported". (If it is spam, it > will be removed shortly by the RFC Production Center.) Please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party > will log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC9000 (draft-ietf-quic-transport-34) > -------------------------------------- > Title : QUIC: A UDP-Based Multiplexed and Secure Transport > Publication Date : May 2021 > Author(s) : J. Iyengar, Ed., M. Thomson, Ed. > Category : PROPOSED STANDARD > Source : QUIC > Stream : IETF > Verifying Party : IESG
