Track active (downtream) tls handshakes

[lambdai]

TLS handshake nowadays are still cpu insenstive.

Even In the service mesh env where no intended attacker or few compromised workload,
a TLS client can easily create DOS attack to a TLS server with unbounded TLS retry.

In this situation, the server side envoy with limited CPU resources should leave decent
cycles to serve the established connections.

It's generally available if we can maintain a queue of active TLS shake, and avoid enqueue
too many tls handshake tasks.

I am proposing usig a L4 filter to track the active handshakes.
The L4 filter can treat connections that have not received ConnectionEvent::Connected as
"active handshaking" connections.

Once we have this metric, either listener or l4 filter can early shutdown the connection.
Or overload manager can be plumbed to stop enqueue.

Alternatively the queuing can be achieved by handshake agent, but there is no timeline yet.

Does anyone have similar requirement? This could be treated as extended "connection limit filter"

[adisuissa]

cc @kyessenov @yanavlasov

[kyessenov]

I like the overload manager integration. I think we can make it a generic gauge that tracks the number of pre-connected transport sockets. Similar issue can happen with other transport sockets that can be computationally heavy (e.g. incomplete PROXY, etc).

[github-actions]

This issue has been automatically marked as stale because it has not had activity in the last 30 days. It will be closed in the next 7 days unless it is tagged "help wanted" or "no stalebot" or other activity occurs. Thank you for your contributions.

[github-actions]

This issue has been automatically closed because it has not had activity in the last 37 days. If this issue is still valid, please ping a maintainer and ask them to label it as "help wanted" or "no stalebot". Thank you for your contributions.