Zebra attempts new peer connections in a fixed, predictable order

[teor2345]

Motivation

Zebra attempts new peer connections in a fixed, predictable order, based on the untrusted_last_seen_time gossiped by other peers, and the local last_success_time and last_failure_time.

This design is vulnerable to attacks that take advantage of this specific retry order to starve the local node, replace all the peers of the local node, or target remote nodes.

This design is also vulnerable to issues after a network connection failure, where every peer is in a failed state. It can also get into a failure mode where it cycles through disconnected successful peers, but never tries failed previously successful peers.

This issue is mitigated by:

• the existing Zebra implementation, which ignores gossiped peers unless it specifically requested them
• Zebra should limit the number of addresses it uses from a single Addrs response, to avoid address book takeover #1869 Zebra should limit the number of addresses it uses from a single node
• Security: Zebra should stop believing far-future last_seen times from peers #1871 Zebra should stop believing far-future last_seen times from peers
• Security: Zebra's address book can use all available memory #1873 Zebra's address book can use all available memory
• Limit new peer connection rate #1847 Limit new peer connection rate
• Security: Limit reconnection rate to each individual peer address #1848 Limit reconnection rate to each individual peer address
• Security: Limit the number of outbound peer connections when dialing new peers #1850 Limit the number of active peers in zebra-network
• Security: Limit the number of inbound peer connections in the listener task #1851 Limit the number of connected peers in the PeerSet
• Security: Retry previously successful peers before peers that have always failed #1876 Retry previously successful peers before peers that have always failed
• randomising the order of initial seed peer connections

Due to the large number of mitigations, this is a low-priority issue.

Solution

This fix depends on #1848, #1849 and #1871.

Zebra should choose the next peer to connect to using the "power of two choices" algorithm.

In the following functions:

• CandidateSet::next()

Use the "power of two choices" algorithm:

• choose two random addresses that are eligible for connection
  • filter the addresses for eligibility before randomly selecting two of them
• select the best address from the chosen addresses (the best address has the lower index in the address book)
• attempt to connect to that address
• if there is only one eligible address, attempt to connect to that address
• if there are no eligible addresses, return None

This change risks connecting to slightly worse peers, or skipping some peers that would otherwise have been chosen for reconnection.

Ideally, the algorithm should be implemented by the address book. This improves modularity and performance.

Alternatives

We could do nothing, and trust the other fixes to mitigate the worst impacts of this issue.

Context

zcashd does not have this issue.

[teor2345]

We did this for the initial peers, so the rest of the task is a low priority.

[teor2345]

This is covered by other tickets.

[teor2345]

This could be relevant to some of our current network security bugs.