Open TheRook opened 1 year ago
Thanks for the ideas. Right now we're working on short-term mitigations while we continue investigating.
Almost everything above is a protocol change that would need to be proposed, documented, reviewed with i2pd, and implemented, following our proposal process. That of course takes a while. The best place to workshop ideas where people will see them is on our development forum zzz.i2p.
I tried to access zzz.i2p and it is down... maybe DDoS?
Almost everything above is a protocol change that would need to be proposed, documented, reviewed with i2pd, and implemented, following our proposal process. That of course takes a while. The best place to workshop ideas where people will see them is on our development forum zzz.i2p.
I did my best to provide a short term fix and a longer term fix. Honestly adding a small fixed zero prefix, even two or three zeros will be the least complex method with the greatest impact, and it is a solution we have seen work in production. I understand resources are limited, but you aren't the only network with this problem. Adding a small hashcash-like PoW is a lot easier than a distributed trust store using something like Freenet's Loctus or OrbitDB.
https://github.com/freenet/locutus/issues/458 https://github.com/freenet/locutus/issues/244
No one has a distributed reputation solution yet, but together we have the best chance.
@zzzi2p for short term fixes, aggressive sybil analysis settings will work. I configured my router to run sybil analysis every 60 minutes, with a min blocking score of 20, and to only analyze floodfill routers.
This seems to have worked fairly well so far
Thanks for the ideas. Right now we're working on short-term mitigations while we continue investigating.
Almost everything above is a protocol change that would need to be proposed, documented, reviewed with i2pd, and implemented, following our proposal process. That of course takes a while. The best place to workshop ideas where people will see them is on our development forum zzz.i2p.
why not limit the amount of flood fill routers the user can change it the amount from 1 - 20 flood fill and ignore the rest
In light of the recent Floodfill router DDoS. Denial-of-service is an effective means of censorship and I can see attacks like this becoming a bigger concern on the network. Seeing as the basis of this attack is that there simply are too many of floodfill routers, the first step is making it more difficult to create new floodfill routers and have them join:
Another approach is a reputation system, and being able to report on reputation solves the problem of a large number of floodfill routers working together and refusing to forwarding traffic.
Nodes gain reputation through good actions - and can quickly loose it for misbehaving, which is why judgement needs to be carried out by another trusted node on the network, but not the same node - a randomly elected node, which is similar to Ethereum's Proof of Stake election system.
If i am not mistaken the attacker wants to find as many legitimate floodfill routers out there to flood them with new requests which are then re-transmitted. I don't know how difficult it is to enumerate all floodfill routers. I suspect this is already happening, where a passive observer can collect them all. I'm not sure what we would gain by hiding them, or if hiding the list of routers is even possible.