Notes on Peer Sourcing

[mpguerra]

Motivation

We want to make Zebra's peers more robust and distributed:

• Zebra should store a persistent list of recent successful peers #1956
  • fixed in feat(net): Cache a list of useful peers on disk #6739
• Add a new default peers config, using the current config name for an "extra peers" config #6871
  • Add IP addresses to the default peers config

Auditor Comments

When a peer initially connects to the network, they start by sourcing peers from a list of known-good mainnet peers. The default list is specified in code in zebra/zebra-network/src/config.rs, although users can override it by generating and editing a zebrad.toml config file.

zebra/zebra-network/src/config.rs

Lines 277 to 282 in c76d1f5

	let mainnet_peers = [
	"dnsseed.z.cash:8233",
	"dnsseed.str4d.xyz:8233",
	"mainnet.seeder.zfnd.org:8233",
	"mainnet.is.yolo.money:8233",
	]

The use of a variety of trusted introduction points with distinctive, easily recognized names is considered a best practice. However, taken together, these endpoints do represent a degree of centralization in the network infrastructure. While users technically can change or extend this list, it is doubtful that many of them will.

Additionally, changes to the default list would not be propagated to any user who has made local modifications. One could imagine a case where one of the default mainnet peers is compromised, loses trust, and is removed from the list, but peers who edited their configuration to extend this list fail to receive this change and continue connecting to a malicious peer.

Scenarios such as this one could be mitigated by decomposing the default mainnet peer list into two lists: one, the “officially sanctioned” default list, which users technically could edit but are not expected to, and another, which may default to an empty list, which is intended to contain any additional peers a user may wish to use by default. This would simplify peer list maintenance, leading to better user experience and maintainability. It could also act as a subtle encouragement for peers to diversify their set of introduction points, which would be good for network health and resilience (as long as users vet any new introduction points to their satisfaction out-of-band).

As a further improvement, the degree of centralization could be reduced by following a practice commonly seen in other peer-to-peer systems, e.g., torrent clients, where the client will attempt, on startup, to reconnect to whoever it was connected to before it last exited the network. The initial mainnet peers can be used as well, and should probably be preferred*, but they are no longer treated as an exclusive source of truth± regarding the peer-to-peer network.

*When considering attacks at the level of the routing overlay, we can assume that malicious peers will only refer us to other malicious peers, whereas honest peers may refer us to either a malicious or an honest peer. Thus, even if we trust our introduction point, this trust is not fully transitive, and our trust in other peers should be inversely correlated to the number of routing hops required to reach them - although of course this level of trust cannot be precisely quantified in general. What we can say in general is that even if our introduction points are not exclusively trusted, they are likely the
most trusted peers we have.

±Slight caveat: the default peers likely - though not necessarily, if we’ve modified the peer list - gave us our original introduction to these cached peers (either directly or by introducing their introducers, etc). Therefore there is still a great deal of trust placed in these introduction points; the improvement here is that we have to extend this trust for a shorter time window.

[teor2345]

Here's a summary of the actions we could take to improve seed peers, these changes will help make Zebra more robust to DNS and network attacks:

• store some peer IP addresses on disk, to avoid DNS attacks for instances that have previously run
  • security note: the addresses should be sorted to destroy order, and we should avoid storing timestamps or other data for each peer, to avoid privacy leaks
• have a default and extra list of peers in the config, so users can replace or add to the standard list
  • implementation note: Zebra generates configs with the current default list, so that config field will need to become the new "extra" list. Otherwise, old configs will never get updates to the default peers. This is a breaking change for users who have replaced all their peers.
  • implementation note: we'll want to de-duplicate between the default and extra lists, to avoid querying the same DNS twice
• add some peer IP addresses to the default seed peer list in the config, to avoid DNS attacks for new instances

Which of these changes are the most important? Which should we do before the stable release?

[oxarbitrage]

Hey team! Please add your planning poker estimate with Zenhub @arya2 @conradoplg @upbqdn @teor2345 @dconnolly

[teor2345]

@mpguerra I can't estimate this PR until we decide which changes we're going to make.

Some of these changes should probably have their own tickets.

[teor2345]

We have a ticket for one of these changes already:

• Zebra should store a persistent list of recent successful peers #1956

And an older ticket with a bunch of similar suggestions:

• Zebra should try harder to discover and distribute good peer addresses #1892

[teor2345]

As a further improvement, the degree of centralization could be reduced by following a practice commonly seen in other peer-to-peer systems, e.g., torrent clients, where the client will attempt, on startup, to reconnect to whoever it was connected to before it last exited the network. The initial mainnet peers can be used as well, and should probably be preferred*, but they are no longer treated as an exclusive source of truth± regarding the peer-to-peer network.

This part was done in ticket #1956 and PR #6739.

[teor2345]

I think we've finished everything we're going to do here for now.

This audit item was partially fixed and partially accepted as a risk.