IPFS should not default to doing port scanning

[alexanderkjeldaas]

Regarding issue #1226, #1173, #1433, #4343, #5418, #5473, and also helm/charts#7746 is relevant.

These issues relate to the port scanning / default profile used by ipfs.

This issue is about the current default when running:

ipfs init

issues port scanning traffic. This means that it's highly dangerous for any business to use ipfs. It can cost thousands of dollars in lost revenue to have access revoked by an ISP that reacts to this traffic and misinterprets it as abuse.

The default for ipfs must be one of:

1. Ask the user interactively for a profile to use
2. Ask the user interactively to approve scanning.
3. Default to a safe mode.
4. Print a HUGE warning that the user might hear from the abuse department at the ISP.

The last option is not really a viable alternative as damage mitigation might happen automatically from the ISPs point of view.

issues port scanning traffic

It's legitimate attempts to connect to IPFS nodes, using addresses it has learned from the DHT. It's not port scanning, not by any definition. We have argued this with many hosters, some have fixed their monitoring, others are stubborn. A few even told us we're not smart enough to grasp their sophisticated "intrusion detection" systems.

Whether these local-network addresses should be published to the DHT is something we should seriously reconsider though. My own two cents are that it's rather pointless to publish them there -- a global DHT isn't a good tool for facilitating local connectivity, not when we have mDNS, link-local multicast, etc.

The default for ipfs must be one of:

Your four UX suggestions are also worth considering 👍

[alexanderkjeldaas]

It's legitimate attempts to connect to IPFS nodes, using addresses it has learned from the DHT. It's not port scanning, not by any definition. We have argued this with many hosters, some have fixed their monitoring, others are stubborn. A few even told us we're not smart enough to grasp their sophisticated "intrusion detection" systems.

Private addresses should only be published together with at least one corresponding STUN response IP. If your own STUN address is "close", then at least there's a chance in h*** that the private address is reachable. Without this extra information, the probability is x⁻¹, x → ∞.

Google runs public STUN servers for ICE.

[alexanderkjeldaas]

Maybe you can use something like https://github.com/ccding/go-stun ?

[rob-deutsch]

Whether these local-network addresses should be published to the DHT is something we should seriously reconsider though. My own two cents are that it's rather pointless to publish them there -- a global DHT isn't a good tool for facilitating local connectivity, not when we have mDNS, link-local multicast, etc.

I totally concur. Publishing local-network addresses to the global DHT doesn't make sense for the vast majority of go-ipfs users.

If there is a strong desire to have seperate IPFS swarms within private networks, then there might be a desire to publish local-network addresses to the DHT but maybe this is better handled with a specific configuration operations?

[Stebalien]

1. We could, and probably should, create one DHT per distinct private IP network. However, this will require some improvements to our DHT protocol.
2. For each peer, we should filter the addresses we advertise to them based on their IP address and the IP/netmask of the interface we're listening on. This is something we can do right now and it should solve the private network use-case. This one should actually be pretty easy. This won't work. The gateway is still allowed to route non-routable IPs as long as they don't end up on the public internet. Multiple distinct subnets can be joined.

Together, these two options should just "do the right thing", no configuration necessary.

[Stebalien]

Proposed solution: libp2p/go-libp2p#436

[Stebalien]

Closing in favor of #6932 as it has more (and more accurate) information.