Set stream limits for HTTP2 protocol - CVE CVE-2023-44487

[akshaysngupta]

envoyproxy/envoy#30055

1. Set max_concurrent_stream=100 to limit streams per connection. Helps limit memory usage.
2. Set http.max_requests_per_io_cycle=1 to limit requests processed in one IO cycle.
3. Set overload.premature_reset_total_stream_count=50. This kept low enough to reduce impact.
4. Set overload.premature_reset_min_stream_lifetime_seconds=1.

[github-actions]

Hi @akshaysngupta! Welcome to our community and thank you for opening your first Pull Request. Someone will review it soon. Thank you for committing to making Contour better. You can also join us on our mailing list and in our channel in the Kubernetes Slack Workspace

[sunjayBhatia]

I was working on #5827 while this was submitted and looks like there is some overlap

It seems pretty much all of these are set via Envoy defaults already

[sunjayBhatia]

Hey @akshaysngupta I don't think we will merge this PR as structured, but would rather prefer PRs that solve the targeted issues I just created and linked. I personally would not consider those blockers for a release since there are other mitigations for CVE-2023-44487 in place with defaults and other Contour changes. IMO they are a nice to have that we would appreciate community contributions for.

[akshaysngupta]

@sunjayBhatia those other defaults are not enough. Contour-managed Envoy are getting OOM killed within the first 5 seconds (depends on memory allocated) of the attack without a limit on the max streams. But it also makes sense to keep this configurable. Sadly, I don't have the bandwidth right now to make the contribution.

What are the options that users have until this setting is exposed to mitigate the attack?
Should users build their own custom Contour images to have some sort of mitigation?
How will the users discover the settings that will help mitigate ?

[sunjayBhatia]

see #5850

[egerkke]

Hi @akshaysngupta ,

We are also investigating how new Contour parameters shall be introduced due to the rapid reset attack. And you mentioned:

Contour-managed Envoy are getting OOM killed within the first 5 seconds (depends on memory allocated) of the attack without a limit on the max streams.

Did you refer to max-concurrent-streams of Envoy? If yes then can you please explain a little bit how it is related to the rapid reset attack? My understanding is that this is actually one of the main points of the attack that prematurely closed streams by RSTs are not counted in the max-concurrent-streams.

Or exposing this parameter in general is useful since its high default value can be exploited easily even without the rapid reset attack?

[akshaysngupta]

That's right. Rapid resets don't increase the stream count. This helps with later where attacker creates too many streams.