Floodfill router DoS Mitigation

[TheRook]

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:

1. Each node should have a hard-coded ceiling IP address limit - seeing a floodfill advertisement or a direct connection will count against the IP limit. In practice I think a limit of ~10 would be unlikely to filter legitimate traffic, once the cap is hit - ignore future advertisements for that "unique" floodfill.
2. Require that floodfill routers generate a unique, timestamped zoro-prefix'ed signature as a proof-of-work that is used for their first advertisement. A CPU bound process local process of a PoW will limit a floodfill router's ability eating community DHT resources. Even generating just one PoW would make floodfilll DoS more difficult to carry out.

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.

1. Use a libp2p-style pub/sub establish a CRDT communal counter (OrbitDB has one of these data types). Each counter is a k/v pair of the hash of the public key of a node on the network so that anyone can lookup a reputation score of a public key using the DHT.
2. Votes which have been cast by nodes with higher reputation should be seen as more valuable, where as votes cast by nodes without reputation should be seen as less so.
3. On a regular interval a high-reputation node to establish connections with nodes, and subtract reputation if a message wasn't routed. (not all that unlike PoS elections)

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.

[zzzi2p]

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.

[TheRook]

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.

freenet/freenet-core#458
freenet/freenet-core#244

No one has a distributed reputation solution yet, but together we have the best chance.

[bonedaddy]

@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

[s-b-repo]

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