Re: Comments and Suggestions to Address an Ambiguity Related to Connection Management in QUIC RFC 9000 Based on an Investigation of 19 Servers

[Christian Huitema]

+1 to what Marten said. A ping only attack will at worst create a "half 
context" per packet, that is the minima; context required to decrypt the 
initial. A CHello flood will do all of that, plus force the server to 
perform expensive asymmetric key computations and send a server first 
flight that typically spans several packets.

-- Christian Huitema
On 7/11/2025 9:46 AM, Marten Seemann wrote:
You’re absolutely right. I did receive your email back in December 2023. I
didn’t expect it to be that long ago and completely forgot about it.

That said, I’m somewhat reassured to see that my response back then was
essentially identical to what I wrote earlier today:
[image: image.png]

What’s disappointing, however, is that the feedback I provided at the time
doesn’t appear to have been acknowledged or reflected in the final version
of your paper. The issues I raised weren’t minor, they directly challenge
the premise that a PING-only Initial packet constitutes a meaningful or
distinct attack.

On Fri, 11 Jul 2025 at 08:42, Kian Kai Ang <kiankai....@adelaide.edu.au>
wrote:

Dear Marten,

Thank you for your reply and sharing your thoughts. We shared our
observations and an opinion. Happy to see it being discussed.

We do wanted to clarify again that we have sent disclosures to all the
vendors in 2023 before we submitted the report to IETF QUIC-WG this year.

For quic-go, we sent one on 7 December 2023 (from quictester2...@gmail.com)
and I think we had a discussion similar to what you include in your email
(please see the screenshot below).

As background, the observation we shared emerged during our compliance
testing of QUIC servers. We observed that different implementations handle
Initial PING frames differently. This led us to investigate the
consequences of implementing choices.

As a side note, one of the reasons for the delay in sending the report is
because we had a lot of disclosures (not just this but others in the paper)
to do and wanted to give everyone to address them.
Best regards,
Kai

[image: PastedGraphic-1.png]



On 11 Jul 2025, at 1:13 pm, Marten Seemann <martenseem...@gmail.com>
wrote:

* CAUTION: External email. Only click on links or open attachments from
trusted senders. *
------------------------------
Thanks for sharing. For the record, I have not received any responsible
disclosure related to quic-go.

While one might argue that a packet containing only a PING frame and no
CRYPTO is “simpler” than one with a CRYPTO frame, this distinction is
largely irrelevant from an attacker’s perspective. An Initial packet must
be at least 1200 bytes, so the attacker has to send some kind of payload
regardless, be it PING, PADDING, or anything else. Given that, why would an
attacker restrict itself to sending just a PING frame to create QUIC state,
when it can just as easily also include a ClientHello and force the server
to allocate TLS state and burn CPU cycles processing it?

Including a ClientHello doesn’t increase resource consumption on the
attacker’s side: these can be precomputed or even reused across multiple
connection attempts. This suggested PING-only attack is simply a less
effective version of a general connection flooding attack. It’s not
particularly interesting or novel, and I don’t think it warrants any
special consideration, which is why quic-go doesn’t implement defenses
specifically targeting it.

I’d also note that, at least for quic-go, behavior under such an attack is
governed by configuration, for example when Retry packets are sent and how
many concurrent handshakes are allowed. What you’re measuring is therefore
not "the behavior of quic-go", but the behavior of one specific server
configuration you happened to test.

Focusing on the default values of these config flags is of limited value.
quic-go is a general-purpose QUIC stack used in a wide variety of use cases
(HTTP/3, MASQUE-style proxying, p2p, just to name a few), and it's simply
not possible to provide a one-size-fits-all configuration. Real-world
deployments tune configuration parameters based on application-specific
requirements and the environment they run in. I assume the same is true for
other QUIC implementations, which makes it hard to see the value in
comparing memory usage across stacks in the way you do in Figure 1.

For these reasons, I see no need to modify the QUIC specification. Despite
the claims in the paper, there is no ambiguity: a valid Initial packet is a
valid Initial packet, regardless of its frame contents. In fact, the
proposed change (ignoring packets that lack CRYPTO frames) would, in my
view, be potentially harmful. It is entirely valid for clients to send
PING-only packets as tail loss probes, and failing to acknowledge these
would interfere with effective loss recovery. I also don’t consider the
proposed use case of liveness testing to be valid, as this can be achieved
more efficiently by sending a packet with a GREASE version number to elicit
a Version Negotiation packet.

On Fri, 11 Jul 2025 at 10:52, Kian Kai Ang <kiankai....@adelaide.edu.au>
wrote:

Hi QUIC-IETF-Group,

We investigated automated testing methods for QUIC protocol
implementations. During our testing (open source tool and findings are here
https://github.com/QUICTester/QUICTester and
https://github.com/QUICTester/QUIC-Fuzz), we found an issue with
implementations that can be traced back to the current specification’s
description on connection management. We base this finding on testing 19
implementations. We responsibly disclosed our findings to all affected
developers over 90 days ago and privately to Martin. As Martin suggested,
we have attached the report outlining our findings to the QUIC mailing list
in this email.

We feel more clarity would lead to better implementation of the protocol.

Please let us know if you would like any more information.

Thank you.

Best regards,
Kai and Damith