Skip to content

p2p blacklisting

qcdll edited this page Mar 24, 2019 · 4 revisions

In addition to implementation of devp2p in py-evm (now trinity), we constitute the following blacklisting rules:

All blacklisting info is local to the node possessing the information, and will not convey to other nodes in the network. However, blacklisting causes nodes to be removed from routing table, as a result it will be harder for other nodes to discover them.

Blacklisting is applied to IP addresses instead of node identity (IP+PORT+PUBKEY).

Dial-out Blacklist

Criteria

  1. when establishing secure connection with a remote node failed
  2. exemption: whitelisted node
  3. exemption: the case of secure connection failing with error message "too many peers", "blacklisted" (*)

Penalty

  1. the remote node will be removed from routing table; and will not be added back
  2. when dialing out, the node will not be picked (1 will also cause the node not being picked when dialing out)
  3. the blacklist period is 24 hours

Dial-in Blacklist

Criteria

  1. when a remote node dials in and failed to establish a secure connection
  2. p2p protocol determines the remote peer is misbehaving(**)
  3. exemption: whitelisted node
  4. exemption: the case of secure connection failing with error message "too many peers"

Penalty

  1. the remote node will be removed from routing table; and will not be added back
  2. when dialing out, the node will not be picked (1 will also cause the node not being picked when dialing out)
  3. when receiving dialins, reject the attempt with "blacklisted"
  4. the blacklist period is 16 hours

(*) an indication of the remote node has dialin-blacklisted us, should not retaliate by blacklisting (**) currently, close_with_error() is a good indication

The criteria for dialin blacklisting is more strict than that of dialout, and the penalty is more severe (for a shorter period of time).