to investigate: discv5 and private IPs

[richard-ramos]

Currently both nwaku and go-waku will dial to a peer using the IP information received from ENR. Although in go-waku I try to avoid this by selecting the most external address for the ENR record, it still could happen that some of these records might contain unreachable local network IPs. Should we filter the discovered records so only those that contain at least one external addresses are allowed? for local network discovery we could use instead mDNS discovery

(I'm not sure if this issue should have been opened here or in vacp2p/rfc)

[jm-clius]

Could be a way to keep the routing tables cleaner (wdyt @kaiserd?), but wouldn't the current behaviour be that these gets removed from the routing table in any case if not pingable?

I guess that nodes within that local network would continue keeping these unreachable addresses in their routing table, though...

[alrevuelta]

Although in go-waku I try to avoid this by selecting the most external address for the ENR record

Correct me if I'm wrong but afaik an ENR can only have one IP field or? So not sure what you mean by selecting the most external, if the record just has one.

An option could be to not even try to dial a peer containing a private ip in its multiaddress.

[richard-ramos]

By selecting the most external IP i mean to choose the which IP will go into the ENR to be advertised in discv5. This is probably a go-waku specific behavior: nodes can have multiple addresses. For example right now my desktop client has the following multiaddreses since i have UPnP enabled:

"/ip4/127.0.0.1/tcp/60000/p2p/16Uiu2HAmUVVrJo1KMw4QwUANYF7Ws4mfcRqf9xHaaGP87GbMuY2f",
"/ip4/192.168.0.106/tcp/60000/p2p/16Uiu2HAmUVVrJo1KMw4QwUANYF7Ws4mfcRqf9xHaaGP87GbMuY2f",
"/ip4/MY_EXTERNAL_IP/tcp/34552/p2p/16Uiu2HAmUVVrJo1KMw4QwUANYF7Ws4mfcRqf9xHaaGP87GbMuY2f

So to build the ENR from these multiaddresses i chose the most external one, which is the one represented by the last multiaddress.

If i'm behind a firewall I have even more multiaddresses due to Circuit Relay:

"/ip4/192.168.0.106/tcp/60000/p2p/16Uiu2HAmUVVrJo1KMw4QwUANYF7Ws4mfcRqf9xHaaGP87GbMuY2f",
"/ip4/127.0.0.1/tcp/60000/p2p/16Uiu2HAmUVVrJo1KMw4QwUANYF7Ws4mfcRqf9xHaaGP87GbMuY2f",
"/dns4/node-02.gc-us-central1-a.status.prod.statusim.net/tcp/30303/p2p/16Uiu2HAmDQugwDHM3YeUp86iGjrUvbdw3JPRgikC7YoGBsT2ymMg/p2p-circuit/p2p/16Uiu2HAmUVVrJo1KMw4QwUANYF7Ws4mfcRqf9xHaaGP87GbMuY2f",
"/dns4/node-02.gc-us-central1-a.status.prod.statusim.net/tcp/443/wss/p2p/16Uiu2HAmDQugwDHM3YeUp86iGjrUvbdw3JPRgikC7YoGBsT2ymMg/p2p-circuit/p2p/16Uiu2HAmUVVrJo1KMw4QwUANYF7Ws4mfcRqf9xHaaGP87GbMuY2f"
"/dns4/node-01.gc-us-central1-a.wakuv2.test.statusim.net/tcp/8000/wss/p2p/16Uiu2HAmJb2e28qLXxT5kZxVUUoJt72EMzNGXB47Rxx5hw3q4YjS/p2p-circuit/p2p/16Uiu2HAmUVVrJo1KMw4QwUANYF7Ws4mfcRqf9xHaaGP87GbMuY2f"
"/dns4/node-01.gc-us-central1-a.wakuv2.test.statusim.net/tcp/30303/p2p/16Uiu2HAmJb2e28qLXxT5kZxVUUoJt72EMzNGXB47Rxx5hw3q4YjS/p2p-circuit/p2p/16Uiu2HAmUVVrJo1KMw4QwUANYF7Ws4mfcRqf9xHaaGP87GbMuY2f"

Handling these circuit relay addresses is being discussed in #1491

[chair28980]

@jm-clius is this issue still relevant to pick up for nwaku?

[jm-clius]

Based on the work done here:

nwaku/apps/wakunode2/internal_config.nim

Line 87 in 3bbe234

proc networkConfiguration*(conf: WakuNodeConf,

I think we can close this issue. Although we still don't filter out non-public IPs, we do select the most external IP for the ENR.