[PATCH 3 of 5] HTTP/3: traffic-based flood detection

[Roman Arutyunyan]

On Wed, Oct 13, 2021 at 12:06:56PM +0300, Vladimir Homutov wrote:
> On Thu, Oct 07, 2021 at 02:36:16PM +0300, Roman Arutyunyan wrote:
> > # HG changeset patch
> > # User Roman Arutyunyan <arut at nginx.com>
> > # Date 1633602162 -10800
> > #      Thu Oct 07 13:22:42 2021 +0300
> > # Branch quic
> > # Node ID 31561ac584b74d29af9a442afca47821a98217b2
> > # Parent  1b87f4e196cce2b7aae33a63ca6dfc857b99f2b7
> > HTTP/3: traffic-based flood detection.
> >
> > With this patch, all traffic over HTTP/3 bidi and uni streams is counted in
> > the h3c->total_bytes field, and payload traffic is counted in the
> > h3c->payload_bytes field.  As long as total traffic is many times larger than
> > payload traffic, we consider this to be a flood.
> >
> > Request header traffic is counted as if all fields are literal.  Response
> > header traffic is counted as is.
> 
> [..]
> 
> this looks more complex than QUIC part, as we don't have clear
> understanding what 'payload' is.

Exactly.

> Attempt to count literal fields vs bytes leads to situations when
> payload is greater than total due to en/decoding. It looks like
> it doesn't harm though, as the difference is not that big and we
> should not have something like zip-bomb here
> (i.e. decoded payload increases greatly in length, while total is quite
> small)

Counting fields as literal:

1. simplifies code
2. takes into account bytes passed via the encoder stream otherwise counted
   as burden, which technically they aren't

Overall, I like the idea of comparing the traffic we received with the
size of the request, whatever method we use to calculate it.  Cherrypicking
payload from the traffic is tricky in HTTP/3 since what logically constitutes
the payload is spread over several streams.

> I'm not sure that assuming reserved frames is not a good payload
> is a good idea. While we don't know what is there, RFC tells us
> not assume anything about their meaning. On the other side,
> we can definitely consider huge number of reserved frames as a flood,
> as we don't make any progress with request as we receive them
> and waste resources.

I assume reserved streams are potentially the main source of flood.

> overal, it looks working, and I have no better ideas how we can improve
> it.
> _______________________________________________
> nginx-devel mailing list
> nginx-devel at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-devel

-- 
Roman Arutyunyan