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 <[email protected]> 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 > > >
