Filter Idea: Rate limiting

[markmandel]

Since a game server / client usually has a known frequency for sending packets, having a rate limiting filter seems like an easy win for protecting game servers.

This would likely be more relevant on the receiver (game server) side, but may have applications on the client (sender) side.

[iffyio]

Todo

• Add proper configuration from yaml
• Add integration test
• Add metrics
• Add option to configure traffic direction to rate limit
• Add ability to configure which endpoints will be rate limited

[iffyio]

Add ability to configure which endpoints will be rate limited

@markmandel Is the idea to turn off rate limiting for some endpoints and/or set different limits depending on the endpoints? I imagine this would require specifying each endpoint in the rate limiter's config? e.g

  filters:
    - name: quilkin.rate_limiter
      config:
        - endpoint: gs1
          max_packets: 10
          period: 1
        - endpoint: gs2
          max_packets: 20
          period: 1

vs

  filters:
    - name: quilkin.rate_limiter
      config:
        max_packets: 10
        period: 1

we could instead have the rate limiter config not concerned with endpoints and instead make it possible to configure multiple filter chains depending on endpoints.

[markmandel]

Add ability to configure which endpoints will be rate limited

Apologies, I totally used the wrong words. What I meant to say, is that there could be an option to determine which Filter function the rate limiting is applied to, with a default.

So a Rate Limiter could be applied to local_receive_filter, local_send_filter, endpoint_receive_filter or endpoint_send_filter - as needed.

So something like:

  filters:
    - name: quilkin.rate_limiter
      config:
        max_packets: 10
        period: 1
        direction: local_receive

(I actually see more reason to have a rate limit on receiving than sending, personally)

I think this rate limiter only needs one "direction" (couldn't come up with a better name), as you can always add more rate limiting filters into the FilterChain.

I don't think we need to have filter config per endpoint - endpoint data is too mutable, and I don't think it's necessary, at least at this point.

[iffyio]

I'm not entirely sure of adding this option because it's dependent on how the filter trait is defined. Ideally, the rate limiter config would only deal with rate limiting functionality while e.g direction is handled by the filter chain mechanism. Though I'm not sure what that would look like config wise or if we need to allow rate limiting in the opposite direction

Also I'm wondering whether having 2 send and 2 receive callbacks on the Filter trait complicates things a bit.
From what I can tell, an endpoint_send_filter callback will always be at the tail end of the local_receive_filter chain while a local_send_filter callback is at the end of the endpoint_receive_filter chain.
So that for example a chain
local_receive_filter => A -> B
endpoint_send_filter => C -> D
is the same as local_receive_filter => A -> B -> C -> D

If this is the case we could consider using 1 callback each for send and receive on the filter trait since that would be simpler and make the api harder to misuse like I initially did with rate limiting on send instead of receive. WDYT?

[markmandel]

So I think there are 2 things here:

1. Should have rate limiting available on local_receive_filter and endpoint_receive_filter?

So let me give two scenarios. To stop excess or malicious data coming from a client to a game server, rate limiting on local_receive makes perfect sense.

But what I want to protect from a game server going rogue (or being hacked), and suddenly sending way more data than it should from game server to client - how do I rate limit what data is going from game server back to the client? Right now, I don't think we can with the current filter implementation.

I think this could be handled by a direction of either local or endpoint - since it's only ever going to be receive.

2. Should we consolidate filters? This is an interesting question, but should probably be a separate ticket, to not intermingle conversations.

Thoughts?

[iffyio]

Makes sense, we can use the direction option to configure the rate limiter then

[XAMPPRocky]

It seems like this was implemented, should we close?

[markmandel]

We are still missing the "Add option to configure traffic direction to rate limit" - The LocalRateLimit only does rate limiting on local ➡️ endpoint, but not endpoint ➡️ local.

We should probably discuss if this should be a seperate filter, or if it should be a config option on an RateLimit Filter. 🤔

[iffyio]

Ooh also it currently rate limits on the entire proxy level but likely what makes more sense is to ratelimit on the session level instead so e.g 60pps doesn't mean the proxy can only allow that muc

[XAMPPRocky]

We can close this now with #406 right?