Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add peer ban list to fluffy #2809

Open
kdeme opened this issue Oct 31, 2024 · 1 comment
Open

Add peer ban list to fluffy #2809

kdeme opened this issue Oct 31, 2024 · 1 comment
Labels
Fluffy optimization Security Security vulnerability or security related

Comments

@kdeme
Copy link
Contributor

kdeme commented Oct 31, 2024

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
Copy link
Contributor Author

kdeme commented Nov 6, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Fluffy optimization Security Security vulnerability or security related
Projects
None yet
Development

No branches or pull requests

1 participant