Add peer ban list to Fluffy

status-im / nimbus-eth1

Nimbus: an Ethereum Execution Client for Resource-Restricted Devices

https://status-im.github.io/nimbus-eth1/

Apache License 2.0

590 stars 120 forks source link

Add peer ban list to Fluffy #2809

Open kdeme opened 3 weeks ago

kdeme commented 3 weeks ago

Nodes that offer invalid data will currently be allowed to keep doing so wasting bandwidth and cpu of the receiving node.

Any offer that has a properly encoded content key and that falls in the data radius of the receiving node will be accepted. Data will be send and once received it will be validated. If the data fails validation, the peer currently is not punished and thus allowed to keep offering this or other invalid data.

Similary a node can provide invalid data on a FindContent. Or send no data at all or very slow until uTP transfers time out.

We should add a temporary ban list for nodes that do this.

There might also be nodes that end up in the DHT of a specific subnetwork for some reason, but don't actually support the subnetwork. Might require a temporary (per network) ban list for these to avoid trying to ping over and over a node that is not supported.

kdeme commented 2 weeks ago

We currently see a lot of following errors:

WRN 2024-11-06 11:11:29.853+01:00 Offer failed due to accept request failure  topics="portal_wire" error="No message data, peer might not support this talk protocol" contentKeys=@[0x00458ff92094a00fac6e393a435d58242c4971e9711adf1cd16215fc97856e4a1e] node=b7*406c26:164.92.247.243:5008

This is definitely a good candidate as reason for subnetwork specific temporary bans. As it really indicate a node that does not support a subnetwork. In theory these should get filtered out of the subnetwork DHT, but if other clients don't do that properly or if the node does reply to ping/pongs on that subnetwork, this will not occur.

bhartnett commented 2 hours ago

@kdeme I remember you mentioned that there is an existing ban list implementation in nimbus-eth2 somewhere but I can't seem to find the link (if you shared it previously). Can you share it here when you get a chance?

bhartnett commented 2 hours ago

How long should we ban nodes that are misbehaving?

So we should ban nodes for a period of time when they:

Send offers that fail to validate (conteny key or value)
Return responses to findContent that fails to validate
Fails to respond or sends data too slow and hits timeout in response to pings, lookups and offers.
Responds with empty or bad data to pings, lookups and offers.

Does this cover it or are there other scenarios that need to be covered?