+1 to what Marten and Martin say. Separately, I would point out that even though the specification states that clients include a CRYPTO frame in the first Initial packet it sends, that packet may get dropped. Therefore, even if the client did, the first Initial packet that the server receives could be a packet that does not contain a CRYPTO frame.
Servers have to deal with that somehow. 2025年7月11日(金) 13:07 Martin Thomson <[email protected]>: > 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 > >> > >> > > -- Kazuho Oku
