Rate-limit for publishing messages

[AbstractiveNord]

Proposed change

Option per publisher, which can block or even cause a disconnection for user, spamming into NATS network.

Use case

Every time when NATS publisher is not 100% trusted entity.

Contribution

Yes.

[derekcollison]

So this is not about sending to other subjects, which we can lock down, but for valid subjects just to rate limit yes?

[AbstractiveNord]

So this is not about sending to other subjects, which we can lock down, but for valid subjects just to rate limit yes?

Yes. Even for allowed subjects, if we have NATS connection on client side, for example, in JS code on web page, we cannot protect the NATS network by blocking spam. This is the problem, which causes irrelevant backend, doing nothing more than just rate-limiting and proxy client HTTP requests into NATS requests.

[AbstractiveNord]

It's probably good idea to have a bunch of distributed clustered NATS Jetstream KV buckets with TTL configured, used by Core NATS for rate-limit users. Core NATS acts like sticky proxy, so by implementing this approach, it's possible to have sync hot cache on Core NATS proxies, updates through NATS KV watch subscription. Welcome to discuss, just first idea.

[derekcollison]

Not following that last comment.

The server code base does have a rate limiter, currently only in use as an opt-in for JetStream consumers.

That could be utilized possibly.

[tjad]

I think 1 consideration for this topic is about whether or not a managed cluster of NATS is in use.

I have seen in another thread the consideration using TC #346 (comment) . This does sound plausible if the solution is self-managed, then using the TC sounds like a viable option at a more ideal level. My concern comes in for managed clusters. It should probably be the onus of the cluster provider to allow such functionality/feature, however this can't be guaranteed as a feature between providers.

Also, TC is rate limiting at the bandwidth level, it may be more convenient to rate limit at a per message level - this would alleviate requirement to understand and do calculations around the message size.

Just food for thought.

[dragonballa]

Not following that last comment.

The server code base does have a rate limiter, currently only in use as an opt-in for JetStream consumers.

That could be utilized possibly.

I'm facing this exact situation where we don't know if the publisher is trustable or not. Can easily spam/DDOS

I'm looking for a solution I can use NOW

Is KV the way to go? Not sure what that rate limiter code you speak of looks like (or know where it is).

[derekcollison]

Nothing to limit the inbound rate outside of network throughput and max payload size at the moment.