Is it possible to add a shared peer reputation layer across the protocol stack?

[shamil-gadelshin]

Is it possible to add shared peer-reputation layer across the protocol stack?

@mxinden commented on the community call that such spam protection approaches are application specific which makes sense. However, Parity Substrate framework uses a concept of the PeerSet that accumulates peer reputation across different protocols and uses it for a ...strategy for choosing which nodes the network should be connected to.

Currently, it seems that all protocols will reinvent the same concepts on adding spam protection: #2735

[thomaseizinger]

I think in principle it makes sense to add a few data types and perhaps a NetworkBehaviour that allows users to manually track the reputation of peers.

Such a behaviour would have to be used from within an event loop that polls the Swarm.

On the other hand, such a NetworkBehaviour is quite basic and can easily be written manually which allows users to directly encode their scoring logic without an additional layer of indirection.

The problem is similar to NetworkBehaviours like AddressBook. Useful in principle but in practise, it is hard to provide something generic that has significant value without being in the way of what the users want to achieve.

I'd love for rust-libp2p to be more "batteries included". For the time being, however, the (unwritten) policy is that everything in here needs to have a spec.

[MarcoPolo]

This is pretty similar to a discussion @mxinden and I had around supporting protocols that could share some metadata about themselves and remote nodes they interact with. And I bet we can combine the two into a general solution. Here's the full context: #2680.

[shamil-gadelshin]

Thank you for your responses. I take it that it doesn't make much sense to implement such a layer (or NetworkBehaviour) however, it's possible to add some basic common types and/or provide additional metadata fields related to the peer reputation.

[mxinden]

To make this discussion more concrete, can you add sample scenarios where a shared peer reputation system would be useful?

[shamil-gadelshin]

Here is the existing example from the Parity Substrate codebase: the guys introduced several concepts for peer set management (reputation is one of the features). They use it in the request-response protocols family: block-request protocol, state-request protocol, warp-request protocol, light-client protocol.

All these protocols share reputation data for peers. Probably, these reputation management concepts are 1) application specific and 2) limited to similar request-response protocols. And they differ significantly from, for example, gossipsub v1.1 up to to the point that common layer would be meaninglessly thin.

The initial question came from the necessity of spam-protection for my request-response protocol. This would be great if there was a basic spam-protection strategy until I implement more complex and polished solution. It seems that new protocols initially don't have spam protection - gossipsub 1.0, episub, request-response, and probably some general basic mechanism (low hanging fruits) would be beneficial until more complex application specific approached developed. It could also be shared across protocols.

I'm not experienced enough in libp2p protocols architecture yet, so, I'm asking for your much more informed opinion, whether it feels like a good idea in principle.

By the way, another rookie question - but what prevents me to spam nodes using ping or identify protocols?

[mxinden]

I'm not experienced enough in libp2p protocols architecture yet, so, I'm asking for your much more informed opinion, whether it feels like a good idea in principle.

I would guess that @AgeManning sharing experience on building lighthouse's rate limiting would be useful for you.

https://github.com/divagant-martian/lighthouse/blob/master/beacon_node/lighthouse_network/src/rpc/rate_limiter.rs

By the way, another rookie question - but what prevents me to spam nodes using ping or identify protocols?

Can you expand on the specifics? Both protocols are ~cheap on the receiver side, thus spamming would be expensive for the spammer.

[shamil-gadelshin]

Can you expand on the specifics? Both protocols are ~cheap on the receiver side, thus spamming would be expensive for the spammer.

Yes, "too expensive to be effective" crossed my mind, but I had doubts. Thanks for the confirmation.

[AgeManning]

In Lighthouse we have built a whole peer reputation system which manages peers across all our protocols. I think something of that magnitude is very application specific and agree with the others that building it into libp2p probably isn't a great idea.

However, I think building in basic security mechanisms into the protocol is probably worth while. Gossipsub attempts this with v1.1. In discovery v5, i've added rate limiting for the messages (which is off by default, but users can configure it): See:

• https://github.com/sigp/discv5/blob/master/src/config.rs#L78
• https://github.com/sigp/discv5/blob/master/src/socket/filter/rate_limiter.rs#L58
• https://github.com/sigp/discv5/blob/master/src/config.rs#L83

We used the same rate limiting method (leaky-bucket) for rate limiting in discv5 and in our custom libp2p RPC implementation. See here: https://github.com/sigp/lighthouse/blob/stable/beacon_node/lighthouse_network/src/rpc/rate_limiter.rs

I haven't looked closely at the generic RPC protocol in libp2p but it could be worth while to implement this generic RPC rate limiting as a feature that users can enable (and configure) if they want.

[shamil-gadelshin]

discv5 implementation could be a great starting point. Thank you!

[shamil-gadelshin]

I think I'm able to derive a conclusion now: no shared layer between protocols, but possibly, a basic pluggable feature for request-response protocols.

There is a peer reputation subsystem and, probably, rate limiters in the roadmap of my project. If the result will be abstract enough to include in the libp2p request-response protocol as a feature - I'll contact Max again.

It's great to have several live examples for rate limiters. Here is another one from libp2p (if you googled this answer): https://github.com/libp2p/rust-libp2p/blob/v0.46.1/protocols/relay/src/v2/relay/rate_limiter.rs

Thank you for your time and answers, Guys!