Go-ipfs: significant amount of SYNs to private addresses triggers router reboot

[RubenKelevra]

Description:

The current default profile do not contain a swarm-filter, unlike the server profile.

This leads to a significant amount of connection probes towards private IPv4 ranges like 100.64.0.0/10, 10.0.0.0/8, 172.16.0.0/12 169.254.0.0/16 and 192.168.0.0/16.

I let IPFS run for 20 minutes and 27.5% of all SYN packages generated by it were directed in those IP-Ranges.

If the ISP runs either a DS-Lite or a CGN for its customers, the router has likely a route for one of those ranges, since they are used by the provider. In this circumstance, this behavior will create a lot of NAT-entries since the router cannot just discard those packages, because there's a route for them.

If the upstream router drops those packages, instead of responding, the local router will have to maintain a huge number of NAT-entries.

There was one report in the ipfs-chat complaining, that IPFS will result in a rebooting router after some minutes. I attribute this behavior IPFS-behavior to the reported issue.

Solution:

We could add the server-swarm filter to the default profile and avoid that mDNS-peers get filtered. This should cover more than 99.9% of use cases since most people don't use multiple IP-Networks while not creating a custom configuration by hand.

[Stebalien]

This is: https://github.com/ipfs/go-ipfs/issues/6932, https://github.com/libp2p/go-libp2p/issues/436.

Status:

1. We need to add scopes to signed peer records.
2. Filter public addresses in the private DHT.
3. Filter private addresses from the public DHT.

Unfortunately, this could still lead to some regressions in connectivity as not all LANs will end up forming local DHTs (MDNS may not work) so we need to be careful.

Unfortunately:

• We can't just apply the server profile as that would filter all LAN connections.
• We can't require MDNS because that doesn't always work (e.g., VPNs).
• We can't even look at our local interfaces/subnets because that would break VPNs and complex network structures.

[Stebalien]

Although you're right, this could very much be a large cause of the "killing routers" problem. I also think there may be a simple solution we can get into the next release (attempting now).