Kai and I did discuss this (I think that I was probably the Martin he mentioned). I gave a similar response to Marten. neqo is not a general purpose server; it exists only to support protocol testing, but the rest generally applies.
One thing that I think this highlights is that the response from the "category 1" servers is compliant with the spec. The others are arguably non-compliant on a strict reading. That said, a server can exercise discretion in terms of who it accepts connections from, so the other implementations aren't completely wrong (modulo msquic). Quant sending CONNECTION_CLOSE is entirely within its rights; and pretending to be hard of hearing isn't exactly the worst response to what is clearly not a useful packet. It does beg the question: should we modify the spec to say that Initial packets MUST include CRYPTO frames? Not that it helps against the attack, as Marten point out, but just to reset the baseline to allow this class of rejection. I'm particularly interested in msquic, which sends an acknowledgment without saving anything. What would happen if it were under stress and a subsequent incoming packet needed a Retry? I can't imagine how that strategy is going to lead to a good outcome. On Fri, Jul 11, 2025, at 13:43, Marten Seemann wrote: > 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 >> >>
