AutoNAT: how to handle non-global IP addresses?

[hamamo]

Currently, AutoNAT seems to consider private IP addresses as possible external addresses when two peers run in the same private network. In my case, this is one computer where I run multiple instances of my code, but it is conceivable that the same happens when separate machines run in the same private network (i.e. behind the same router or within some corporate network).

I don't really know which behavior would be most appropriate. My initial guess is that non-public IP-Adresses (i.e. those for which Ipv4Addr::is_global() or Ipv6Addr::is_global() returns false) should not be considered as candidates for probes, but I don't know yet whether there are use cases where private IP addresses are valid external addresses (is multi-layered NAT a thing?).

If people see this as a valid concern, it should probably be communicated to the libp2p AutoNAT spec team for inclusion in the spec.

[elenaf9]

On the initial PR for AutoNAT we had a discussion about whether to filter out non-global IP-Addresses or not (#2262 (comment)). Initially we had it as well, but the complexity of the filter logic triggered a discussion about whether it is necessary at all in the first place. I was in favor of also considering non-public IP-Addresses for probes, because of:

Maybe there are cases where the peers are all within a private network, but there are firewalls established and a peer would like to use autonat to figure out if it can be dialed by peers in the same private network?

Admittedly that's probably a very rare case, and your issue happens much more often.There was also the same discussion in go-autonat and they decided to filter out non-global IP-Addreses as well: libp2p/go-libp2p-autonat#60.
Therefore I am in favor of adding this to rust AutoNAT too. I would personally still favor to have it behind a config flag (and enabled per default), but I don't have a strong opinion on that.
@hamamo are you interested in doing a PR with the fix? It would require that:

• the client only uses peers as servers if their observed IP-address is global
• the server rejects dial request from a client if the observed IP-address is private

Otherwise I can create a PR for this, but not sure when that will be.

If people see this as a valid concern, it should probably be communicated to the libp2p AutoNAT spec team for inclusion in the spec.

👍 Good idea. What do you think @mxinden?

[rkuhn]

While I haven’t yet had the time to fully understand AutoNAT, I can add a data point: private networks with an “interesting” structure are quite common in the environments where we deploy libp2p-based applications (which is in factories, on the shop floor). We try to push people towards end-to-end connectivity at least within a factory site, but that’s not always successful.

[hamamo]

@hamamo are you interested in doing a PR with the fix?
I'll try but it will take me a bit of time, too, as I'm not too familiar with the codebase yet.

[mxinden]

I am in favor of adding this to rust AutoNAT too. I would personally still favor to have it behind a config flag (and enabled per default), but I don't have a strong opinion on that.

👍 for a config flag filtering out non-global IP addresses by default.

If people see this as a valid concern, it should probably be communicated to the libp2p AutoNAT spec team for inclusion in the spec.

+1 Good idea. What do you think @mxinden?

Agreed. Good call out. Contributions are most welcome. Also I am happy to do it as a follow-up to the rust-libp2p patch.

We try to push people towards end-to-end connectivity at least within a factory site, but that’s not always successful.

Just to confirm, with a config flag your use-case would be covered as well, right? @rkuhn?

@hamamo are you interested in doing a PR with the fix?

I'll try but it will take me a bit of time, too, as I'm not too familiar with the codebase yet.

Let us know if you need any help, e.g. via a draft pull request.

[rkuhn]

As I said, I was just providing a data point — I should probably add that IT security requirements tend to contain a growing portion of “security theatre” and cargo cult, which lead to NAT because people confuse “firewall” with “address translation”.

A config option would solve the libp2p part, but it adds the ongoing maintenance cost of more tests and PR discipline, to keep the less commonly used setting working. I can’t decide whether it’ll be an overall win in the grand scheme of things :-)