Patch against eclipse attack

[zilm13]

Check whether EthereumJ is affected and in what aspects: https://bitcoinmagazine.com/articles/researchers-explore-eclipse-attacks-ethereum-blockchain/
Geth patch: https://github.com/ethereum/go-ethereum/milestone/62?closed=1

[adonley]

Which of the counter measures listed in part V of the white paper do you propose implementing?

[tenghuanhe]

@zilm13 @adonley
According to attack listed in part III of the paper:

Our first attack is simple. The client can be eclipsed if the attacker establishes maxpeers incoming TCP connections (to its own adversarial nodes) before the client has a chance to establish any outgoing TCP connections.

It seems that there is no such maxpeers limitation in EthereumJ.

[adonley]

Take a look at ethereumj.conf : maxActivePeers = 30

It might be worth it to do what geth did, associate and limit the number of peers from the same IP.

[tenghuanhe]

@adonley
Sorry for my missing mistake, thank you :)
I agree to avoid too many peers from the same IP and identifying peers just by their nodeIds.

BTW, after checking I found the maxActivePeers here is used to limit incoming connections, it should be different from maxpeers in geth I think, sorry if I misunderstood.

[adonley]

If you take a look at ChannelManager.java and SyncPool.java, the maxActivePeers system property limits the amount of active peers that the node can have (unless it's a trusted peer). I believe this to be the TCP portion of the block communication.

Let's check to see if the "packet-of-death", the open window for incoming connections upon boot or the ability to predict the Kademlia like buckets works on ethereumj. Also we could check to see if seeding from the DB happens even if the table is not empty.

Ethereumj does not implement any IP restrictions on peers at the moment.

[goldbe]

Hi guys, I'm one of the ETH and BTC eclipse paper authors. I think the most important countermeasure from the ETH paper is limiting the number of node IDs that have the same IP address that are stored in the peer tables. This is countermeasure 2 in our paper. The other ones are relevant as well, but if you don't have countermeasure 2 I would be very worried, since this opens the door to low resource (e.g. 1 or 2 attack machine) eclipse attacks of some sort. Even if they attack is not identical to the one in our paper, I am pretty sure a low-resource attack could be found somehow.

[RichardH92]

So the check for this would go in P2pHandler#setHandshake? Before calling channel.getNodeStatistics().setClientId(msg.getClientId()) we should check if that node ID / IP pair already exists?

[mkalinin]

@RichardH92 Basically, we already have a protection against a spam from same IP address. To continue work on this you better start from learning the paper.