core/network-libp2p: possible spoofing of NAT traversed addresses

[Eenae]

When processing Identified event from a peer here observed address of the current node is added to a list as reported by the peer. During the addition only basic checks are performed on the libp2p level.

Malicious node can spoof other nodes observed addresses which as a result will be added to listening_addrs and announced further by the node itself, potentially hindering node connectivity.

I suggest to introduce some form of quorum checking on observed addresses as a simplest solution.

[tomaka]

This is far from being a trivial problem.

To give an illustration, at the moment I can't see any way of differentiating between a maliciously-reported IP address and a legitimate address in the local 192.168.x.x range.
Both can be visible only to a part of the network, and therefore any measure against malicious IP addresses will also apply to the 192.168.x.x address.

I'm not an expert on that topic, but as far as I know some NATs will sometimes happily rewrite IP addresses that belong to the outside of the network as well. A "bad" IP can therefore come from a legitimate implementation that is behind one of these NATs.

[Eenae]

Agree.

Looks like local subnets need special treatment and separate consensus on address validity per subnet (hopefully a host can reliably determine in which subnets it participates). By the way, announcing local ip reported by subnet fellow to external world is a bad idea anyway, so there should be some handling.

I'm not an expert on that topic, but as far as I know some NATs will sometimes happily rewrite IP addresses that belong to the outside of the network as well.

I think rewrite of src address of incoming packet won't cause problems, and I doubt any software will deep-inspect and rewrite addresses in L7 payload. Or am I missing something in this case?

[tomaka]

I think rewrite of src address of incoming packet won't cause problems, and I doubt any software will deep-inspect and rewrite addresses in L7 payload. Or am I missing something in this case?

The problem is that these nodes would report back bad external IPs, and I don't know how we would filter that.

One possible quick fix for now is to sort addresses by the number of times they have been reported. Addresses are attempted in the order in which they are announced, and so nodes would first try the addresses which the majority agrees on.

[Demi-Marie]

@tomaka could we just declare that nodes in such networks are not allowed to participate in the public blockchain, or can only participate in a read-only mode?

[Demi-Marie]

I have a friend who is a professional network administrator. I will ask him about this question.

[tomaka]

I'm going to close this issue as duplicate of paritytech/polkadot-sdk#564 which is more recent and contains more details.