[Technical Errata Reported] RFC9000 (8875)

RFC Errata System <rfc-editor@rfc-editor.org> Fri, 10 April 2026 04:48 UTC

To: jri.ietf@gmail.com, mt@lowentropy.net, quic-ads@ietf.org, matt.joras@gmail.com, lucas@lucaspardue.com
Subject: [Technical Errata Reported] RFC9000 (8875)
From: RFC Errata System <rfc-editor@rfc-editor.org>
Content-Type: text/plain; charset="UTF-8"
Message-Id: <20260410044810.13CCE2B2DE9@rfcpa.rfc-editor.org>
Date: Thu, 09 Apr 2026 21:48:10 -0700
Message-ID-Hash: MRQBLRNVVSKONZPESB4HTJPQYGINSVPB
CC: abhinavagarwal1996@gmail.com, quic@ietf.org, rfc-editor@rfc-editor.org
Precedence: list
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/-bt89p0i1d8nNb98_KqxjYToFE0>

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 <abhinavagarwal1996@gmail.com>

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

[Technical Errata Reported] RFC9000 (8875) RFC Errata System
Re: [Technical Errata Reported] RFC9000 (8875) Martin Thomson