Rate limiting for rust libp2p GossipSub

[jakerumbles]

I want to add some rate limiting capabilities to nodes in our network. We are using a rendevouz client/server model and gossipsub for message organization and propagation. I see that this crate used to exist (https://crates.io/crates/libp2p-ratelimit), but for some reason it was removed from libp2p

Does anyone know if there is in fact still any existing rate limiting crate to plug into our swarm, or do I need to start thinking about building something custom?

[jxs]

Hi! There's connection-limits

[jakerumbles]

Appreciate the response @jxs. I was looking more for gossipsub message rate limiting. I don't think there is a behaviour for that. I think I will utilize governor (https://docs.rs/governor/latest/governor/) for rate limiting and tie it into the code when the swarm receives a new gossipsub message.

Good to know about connection-limits though. Something else I can add on top probably. Cheers

[jxs]

you can limit the number of messages per rpc with max_messages_per_rpc.
Can you elaborate on your usecase, i.e. why do you want to limit gossipsub messages? If using governor how would you plug it into gossipsub?
I am asking cause beware that if you are in a gossipsub overlay and don't cooperate you may be downscored, see #5595 where we dowscore based on slow peers for example

[jakerumbles]

Our node will be open source in the future so we are imagining if someone modified it, and as a member of a rendevouz namespace and a gossipsub topic started flooding tons of messages in a sort of DoS fashion. Nodes are expecting to receive messages on a regular basis, but beyond some reasonable limit it would be great to identify that and start dropping messages or block them entirely.

I'm not really clear how the max_messages_per_rpc works from the docs. Is the context of the count the lifetime of the connection or the count resets per heartbeat? I'm really looking for something that allows say no more than 5 messages per 10 seconds for example, and after it starts dropping the messages. Because no honest node will be sending messages over this set rate limit.

As far as governor, it wouldn't be plugged directly into gossipsub, but after we receive the message I will handle it there and if the rate limit gets hit then I won't send the message deeper into our systems and I could potentially add the peer to a block list, at least for some period of time.

So you are saying that dropping messages or blocking a peer could yield negative consequences for the node that limits/blocks?

[jxs]

I'm really looking for something that allows say no more than 5 messages per 10 seconds for example, and after it starts dropping the messages. Because no honest node will be sending messages over this set rate limit.

is that an attack vector by itself? Gossipsub offers multiple ways to both downscore bad/malicious peers, and discard messages therefore reducing the DoS attack vector possibilities.
I.e, Are the gossipsub messages valid? what is going to be your max message size? Are those messages unique?

you can validate the messages via data transform and invalid messages will penalize the peers who sent them.

If the messages are valid you can discard rpc's bigger than a defined size and as I referred above you can set the max number of messages an rpc can contain with max_messages_per_rpc.

You can also define the duplicate cache duration time, duplicate messages are ignored and not forwarded.

If can even blacklist a peer that you may deem malicious via other protocol.

This should cover most of the cases, but if it doesn't yours you an always submit an issue and we'll see from there :)