A clarification about one point here - I had overlooked “close-by”, now I think I understand the attack: this is a host on the same WiFi network, spoofing packets, and sending NACKs (or DupACKs, for TCP, probably) - right?

See below:

Yet, the QUIC protocol makes ACKs part of the protected payload. Having the ACKs protected by the frame protection allows ensuring that nobody had meddled with the ACKs - and by this to avoid an entire class of attacks that put a close-by endpoint which NACKs segments.

Were such attacks a real problem before QUIC was designed? And besides, aren’t MASQUE proxies visible and authenticated?

So this seems not to be a matching answer for the attack that I now think you have in mind.

Here’s another answer: this is solved by encryption between the host and the MASQUE proxy. That’s okay, I’m not questioning this part of the design. What I say is: the MASQUE proxy itself shouldn’t have to relay e2e-encrypted transport headers (which I *believe* it does, but I really still have some catching-up to do). (and of course I also don’t speak against the e2e encryption of payload!)

Cheers,

Michael