Venus: DHTs may be able to merge between networks

[jhiesey]

Description

As far as I (@jhiesey) am aware, there is nothing preventing filecoin network DHTs from merging with each other or the global IPFS DHT. For this to happen, one node would have to communicate with two networks.

Assuming no bugs or malicious nodes this shouldn't happen, but it's still a risk, especially after launch when people could run modified clients or misconfigure bootstrap nodes. This already happened when the test network for the rust implementation of libp2p-kad-dht accidentally merged with the live IPFS network.

This could have a few different consequences:

• The test networks may not be as isolated as we want. Nodes on a test network could end up visible to public IPFS nodes, and vice versa. This would make debugging much more confusing and open test networks up to potential attack.
• The test and nightly networks may merge. This could be a particular problem given that the same deterministic node IDs are used for bootstrap nodes across both networks. Having multiple nodes with the same ID would likely cause network collapse. One partial solution to this would be to use different bootstrap node IDs on the test vs. nightly networks.

This came out of a discussion with @phritz @anacrolix @mgoelzer over this issue: https://github.com/filecoin-project/pm/issues/105

Acceptance criteria

Accidental DHT network merges either aren't possible or don't matter.

Risks + pitfalls

Even experimenting with this could result in networks unexpectedly merging, which might be very difficult to fix.

Where to begin

We need to discuss whether this is an issue, and if so where in the stack to fix it.

[mishmosh]

thanks for this writeup. would be really helpful to have libp2p friends pick this up, make a recommendation, and carry it through to implementation. does that sound right to you @jhiesey @mgoelzer?

[mgoelzer]

Yes, I think it's fine to assign this to @jhiesey and/or @anacrolix. It started as a sincere question -- there are some legitimate reasons why FC might want them to merge. Since then we have discussed with @whyrusleeping, and he said no, don't let them merge. We can prevent that by adding a DHT ID field somewhere.

[anacrolix]

Yes, please assign this me. I'll do some checks to determine what is required in libp2p and lodge specific issues there.

[phritz]

see also https://github.com/filecoin-project/go-filecoin/pull/2042#discussion_r258935218

[raulk]

A simple and immediately applicable method to solve this is to pass in an option to override the default DHT protocol ID with a custom string: https://github.com/libp2p/go-libp2p-kad-dht/blob/master/opts/options.go#L99.

This is what OpenBazaar does to segregate their DHT network and safeguard against accidental merges.

[anacrolix]

Yes that sounds like the ideal solution. It is also the most appropriate way to handle it throughout the codebase with regard to interacting with other libp2p components.

[anacrolix]

Some useful pointers to the API: DefaultProtocols and Protocols, and any of the IpfsDHT constructors. I'll try to post a PR in the next day or two.

[anacrolix]

It looks like this is already done here. It also looks like there's already a test in go-libp2p-kad-dht too. The only other case is the merging of test and production networks for Filecoin. It could be desirable to have these networks use the same protocol to test other sanity checking measures, and the resilience of the network to having bad nodes. If not we could allow specifying a custom protocol in the Filecoin code. @anorth

[anorth]

Thanks for investigating for us! So if we want to prevent the networks merging at that level, it's just a matter of runtime configuration now? Great, I think we should do it, but it's not urgent.

[anacrolix]

We should close this, referring back to it if we have an issue in the future. I think exposing a runtime option is a separate issue, and should be opened when the need arises.