Rate-limit joining the P2P network

[kim]

With better understanding of the HyParView protocol, there seems to be a relatively easy way to impede eclipse attacks: rate-limiting how many connections (resp. Joins) are accepted per time unit. To see why, we need to consider two operations of the protocol:

1. Join
   A node wishing to join the network establishes a connection to one or more nodes already part of the network, and sends them a Join request. Crucially, if the connection was accepted in the first place, this request always succeeds, even if another node has to be ejected in favour of the new one.
2. Shuffle
   In order to learn about new peers in the network, nodes propagate (a subset of) their own peer information in the network using a random walk. In exchange, they receive a new set of peers, some of which they may not currently have in their partial views. This operation is triggered periodically at a fixed interval on every node.

It is easy to see that a node can easily be eclipsed by Joining it faster than it Shuffles, where the number of required distinct node-ids/network addresses is a relatively small number corresponding to the size of the partial view of the victim node. However, the inverse also holds: if a fully-connected node accepts new connections at a rate strictly smaller than shuffle interval / size of active view, it is guaranteed that a Shuffle occurs before older nodes get ejected.

The question is whether this should be baked into the protocol (allowing faster joins when the node is not fully connected, and slowing down once it is), or handled at the IO layer (with a fixed rate limit).

[tsenart]

@kim: How do you intend to use the token bucket rate limiter across the network? Are we going to Gossip bucket state across nodes, or will token bucket state be per-node?

[kim]

@tsenart per-node. As I tried to convey above, it is only necessary that a node Shuffles more frequently than it accepts new connections (resp. Joins).