ethereum
discv5: collect more eclipse attack countermeasures
The eclipse attack texts deletes the previous information and references to the "Bound-LogIDforPhyIDSrc" in this paper https://engineering.purdue.edu/~isl/TR-EE-07-13.pdf
Instead, the text now makes a general suggestion to limit /24 subnet IPs by bucket and table.
Both approaches have their limitations. In the former case, it is difficult to establish what the correct weighting of per-learned-from-source should be, and with the latter I feel a determined attacker may still be able to take advantage of delays in the node verification schedule to propagate junk around a target and with self-propagation.
I would prefer if the implementation recommendation was more agnostic about how these attacks should be mitigated, while proposing multiple strategies and referring to the papers.
One countermeasure often recommended in literature is proof-of-work. We have a separate issue for that: #122.
Just found another very interesting approach, described in this paper (also see slides for an overview.
The idea is simple: during lookup activity, track node ID distribution. Since node IDs are uniformly distributed across the entire ID number space, any deviations from the regular distribution are malicious and those nodes should be ignored.
Found this while browsing gtk-gnutella source code.
I still want to add the above thing to the spec and try it out in implementation.
Just found another very interesting approach, described in this paper (also see slides for an overview.
The idea is simple: during lookup activity, track node ID distribution. Since node IDs are uniformly distributed across the entire ID number space, any deviations from the regular distribution are malicious and those nodes should be ignored.
Found this while browsing gtk-gnutella source code.
I don't think this countermeasure is effective in discv5. This countermeasure is needed because attackers can choose whatever node ID closer to the target in the DHT network like emule, while in discv5 the node ID is actually a hash digest. The attacker has no way to effectively choose node ID closer to the targets.
The attacker has no way to effectively choose node ID closer to the targets.
While more costly, the attacker can still "mine" for those node IDs.
The attacker has no way to effectively choose node ID closer to the targets.
While more costly, the attacker can still "mine" for those node IDs.
Fair point.