Re: Proposal: Increase QUIC Amplification Limit to 5x

[Ian Swett <[e-mail]>]

We found that once we deployed certificate compression, we could typically
keep the cert under 3 packets, but without it, we typically went over.  I
believe one reason the QUIC WG chose 3 is because we had data to show that
most certificates were small enough once compressed to enable a 1 RTT
handshake.

I'd be curious what your results are with and without certificate
compression in your client?

On Wed, Jul 31, 2024 at 11:15 AM Christian Huitema <[e-mail]>
wrote:

>
>
> On 7/30/2024 5:52 PM, Paul Vixie wrote:
> > Do we know a reason why the system's behavior won't move beyond the new
> > limit the same way it moved beyond the old one? If it's some bizarre
> > kind of leaky bucket let's have the showdown now rather than later when
> > everything is larger and ossification has begun.
>
> The concern is that the wily hackers will send a single UDP "initial"
> packet to a server, and the the server will reply with a complete flight
> of packets including key exchanges, parameters and certificates. Send
> 1.2KB to the server, see the server send back 5, 6 or maybe 10 packets
> to the source IP of the UDP packet. With that the DDOS attack has been
> "amplified" 5, 6 or maybe 10 times.
>
> The amplification limit is there to limit the usefulness of QUIC servers
> for these DDOS attackers. The value 3 was chosen because with
> "reasonable" configurations the server's first flight fits in 2 or 3
> packets, and that there are many UDP services that provide more than 3x
> amplification (see
>
> https://www.cisa.gov/news-events/alerts/2014/01/17/udp-based-amplification-attacks
> ).
>
> But if we loosen the QUIC amplification limit while other services are
> tightening, that situation will change.
>
> -- Christian Huitema
>
>