discv5: attacks mitigation proposal

[mkalinin]

cc @jrhea

This issue is a proposal of including the following counter-measures as recommendations into discv5 spec. Clients should make their own decision on whether to implement them or not.

Rate limit processing of unsolicited messages

• Only N unsolicited messages per unit of time should be processed. Once that limit is reached, implementations should drop requests.
• The other potential approach to rate limiting is to limit a number of threads that processes discovery requests to e.g. a single thread.

Rationale

In a permissionless discovery network rate limiting seems the only proven counter-measure against DoS attacks. It's been figured out by @jrhea with his attacks on Prysm, Teku and Lighthouse where Lighthouse was pretty successful in resisting those attacks because of implemented rate limiting mechanism.

New nodes should temporarily ignore unsolicited messages from unknown peers

For some period of time, depending on the implementation, new nodes should not respond to:

• unsolicited messages from unknown peers
• unsolicited messages from ANY peers

I.e. there is a trial period with only egress sessions allowed. The second option could lead to the liveness check failure in rare case, while the former requires to store any peer that the node had an egress session with.

Rationale

This should give the node a chance to explore the network before an attacker can actively attempt to eclipse it.

An example of this kind of eclipse attack goes beyond discovery and involves application layer. For instance, in Eth1 and Eth2 attacker may quickly find a young node and offer it malicious information about the state of the chain causing the node to make a wrong decision about the sync with any potential output.

This proposal is akin to a counter-measure implemented in go-ethereum where young nodes are started to get advertised after a short period of time.

[fjl]

I think it's not a good idea in general to process discovery traffic on more than one thread.

[fjl]

The Lighthouse implementation of discv5 has some kind of 'banning' logic that could be interesting to compare:

• Nodes become 'banned' for protocol violations, such as
  • sending invalid ENRs
  • sending multiple ENRs for distance 0
  • sending ENRs with unrequested distance
  • sending responses without a matching request
  • unsolicited packets
• The ban lasts for some amount of time, like 24h.