Security: Zebra's address book can use all available memory

[teor2345]

Motivation

Zebra does not limit the size of its address book. Since it accepts up to 1000 addresses from each peer address request, other nodes can fill up Zebra's memory with junk addresses.

Goals

1. Zebra should limit the address book size.
2. Zebra should delete peers based on how recently they were successful.
3. Zebra should replace peers that have never been successful with new gossiped peers.
4. Zebra should replace old peers that have never been attempted with new gossiped peers.

Edge Cases

1. In PR Security: Avoid reconnecting to peers that are likely unreachable #3030, we made Zebra try outdated peers once, and if they fail, ignore them forever. When should we delete these peers?

If we delete them immediately, we could get gossiped another copy of their address, and then retry them

2. We closed ticket Zebra should limit the number of addresses it uses from a single Addrs response, to avoid address book takeover #1869 because it wouldn't work with zcashd. Does deleting peers make address book takeover more likely? How can we prevent that?

3. What happens if our local clock is a long way ahead, so all gossiped peers seem outdated to us?

4. Do we need to warn the user when all their peers get deleted? What if all their peers fail the is_probably_reachable check from Security: Avoid reconnecting to peers that are likely unreachable #3030?

Suggestions

Choosing Peers

Zebra could retain peers in the following order, choosing the newest timestamps first within each category:

• recently successful peers: they will be re-added to the peer set as long as they stay connected
• request pending peers: they will be re-added to the peer set if they are successful
• never attempted peers: they have just been gossiped by other peers, so they are untrusted
• peers that have never been successful

To implement this choice, Zebra could sort peers in recently live order, then reconnection (Ord trait) order, then delete the last peers in the list. AddressBook::update is the only method that increases the address book size, so it is a good place to delete excess peers.

Edge Cases

• We should not spawn an extra task to make these changes, because that increases the risk of threaded mutex deadlocks
• We should ignore last_failed_time, so that we don't risk losing all our peers after a network interruption
• Zebra should minimise the performance impact of this new code:
  • keep peers sorted in this order: https://docs.rs/ordered-map/0.4.2/ordered_map/struct.OrderedMap.html , or
  • delete peers in batches or on a timer

Choosing the Limit

• large enough to contain most active peer addresses, even if we're not connected to them (approx 250, required by Justify our alternative to "evicting pre-upgrade peers from the peer set across a network upgrade" #706)
• large enough to send a full Addrs response (3000 peers * 1/3 peer response = 1000 limit)
• small enough to avoid using too much memory
• small enough to trigger peer deletion reasonably often, so we actually run this code (less than the 5000 addresses currently gossiped on mainnet and testnet)
• small enough to cycle through all peers at the new peer reconnection rate (10 per second - Limit new peer connection rate #1847), within a reasonable amount of time (a few minutes)

Alternatives

We could choose a random selection of untrusted_last_seen peers instead, but choosing the newest peers retains peers that are more likely to be available.

Mitigations

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

[teor2345]

This ticket is not Critical, because #1889 resists this attack. (And zcashd should resist these kinds of attacks anyway.)