Connection closed after a 404 + NR

[wbpcode]

When I send a POST request to Envoy, if no suitable route is found, Envoy will send a local response directly (404 + NR). In response, Envoy will send 'connection: close' to close the connection, since the body of the POST request has not been processed.

However, in a real production environment, Envoy, as an API gateway, is often not the entrypoint to the cluster. There is also a L4 proxy between the client and the Envoy.
If an attacker uses a large number of nonsensical POST requests to attack, this can lead to frequent establishment and disconnection between the ingress L4 proxy and the Envoy, resulting in degraded performance and unnecessary overhead.

Is that going to be a problem? I think this can be circumvented by sending a local response in the decodeData phase or decodeTrailers phase when no route can be found. Or what other options are available?

[alyssawilk]

I think the NR is orthogonal - one could send non-HTTP junk over L4 to establish a new connection, and the L7 Envoy would then close the connection because it was parsing junk. Trying to drain connections rather than close wouldn't help in that case. Fundamentally I think if your fleet doesn't scale to L4 connection establishment you have to be able to DoS block at L4 to blackhole junk traffic early.

There is some discussion of beefing up Enovy WAF support over here that you might find interesting regardless: #7918

[wbpcode]

I agree with you.