P2P Circuit Advertisements

[Stebalien]

The next step to getting relays working is to figure out how to advertise addresses proxied through a relay.

Random thoughts:

1. Ignore unspecific relay advertisements. That is, ignore all advertisements of the form /p2p-circuit/ipfs/QmId (no relay specified). These are pretty much useless and could be used to trick nodes into doing a lot of work.
2. Have relays publish p2p-circuit addresses for their relayed peers. This will get us one step closer to using circuits for privacy. The downside is that advertising these addresses could be a lot of work.

[Stebalien]

@vyzo

[dryajov]

@Stebalien can you clarify what you mean by

advertise addresses proxied through a relay.

Do you mean, the relay advertising which connections/peers/addrs it can relay or the peer itself advertising the desired relay it wants to be reached over? Both have been discussed during the circuit spec review rounds. Glad this issues is being brought back.

[Stebalien]

The former. Could you point me to that discussion? I couldn't find it.

[dryajov]

https://github.com/libp2p/specs/pull/22 and https://github.com/libp2p/specs/pull/18 capture most of the discussion around the circuit spec. There is also https://github.com/ipfs/notes/issues/237 that talks about connections that the relay knows about - which I think is what we need, rather than advertising addresses, because in passive mode the relay will only make the circuit to peers it has connections to.

I don't think that the later has been discussed outside a few IRC exchanges and would like to see it captured somewhere - should probably open an issue around it.

[dryajov]

Ah, forgot the main PR that had the most info captured - https://github.com/libp2p/specs/pull/15

[dryajov]

BTW - I'm not saying that ls is the right approach, but that it was born out of specifically this requirement, its a good thing that we're coming back to it.

I think a consistent way of announcing capabilities and other useful info is important for circuit and other parts of libp2p/IPFS.

[vyzo]

I think we also need to figure out the when -- when should we advertise a relay address?

For the case of NAT, I would like the node to automatically detect its behind an impenetrable NAT, and then proceed to advertise (specific) relay addresses.

Unfortunately this is not an easy determination to make without the help of other nodes. The presence of NAT can be detected by local-observed address mismatch, but determining whether it's penetrable would require another node to actively open a connection to the peer. Perhaps we could maintain a service to facilitate this.

[dryajov]

Just to clarify, from my perspective there are two distinct things that happen regarding relay addresses/connections.

1) From node perspective - the node should be able to say it is accessible over one or more relays

• no explicit relays in swarm config A peer doesn't care which relay it's accessed from, the closes/fastest the better.

  • In this case, there should be some mechanism to determine which relay is closer and faster - probably a simple ping over a set of relays should be enough to tell which ones are fast.
    • The peer should be able to announce which relay it is accessible over at any given (somewhat real) time and it happens when you're on the move and switching from network to network. It can be done by updating the DHT and broadcasting through pubsub.

• explicit relays in swarm config A peer only wants to be accessed over a particular set of relays

  • In this case, no automatic switching of relays happens and the peers is always accessible over the same set of relays. This is needed if you're in a private network and won't be moving around too much but still need that peer to be accessible from the outside (gateway relay?).

2) From a relay prospective - the relay should be able to announce which nodes it has connections to.

• This is needed for passive mode, since passive mode will reject relay request to nodes it doesn't have a connection to. The relay should be able to say which peers it's connected to and it's needed to prevent needlessly hitting relays that will reject you. I think there are two ways to provide such info:
  • passive/query: the relay will respond to queries (ls) which will return connected peers, possibly alongside other info
  • active/broadcast: the relay will periodically announce through the DHT, pubsub or other means which peers it has connections to.

@vyzo

For the case of NAT, I would like the node to automatically detect its behind an impenetrable NAT, and then proceed to advertise (specific) relay addresses.

Relay is a fallback mechanism in case all else failed and as long as there is a correctly configured relay around, NAT shouldn't be a problem? Thats why I like the idea of advertising relay addresses just as any other address and its also the reason I like the priorities mechanism you and I proposed at different times - because it allows us to treat circuit just a any other transport and reuse the same semantics both at the implementation and UX level.

One more thing that comes to mind - what if a relay is wrongly configured and its itself behind a NAT or worst it's malicious and it advertises as relay but doesn't actually relay anything? I think there should be a mechanism to black list malicious/misbehaving peers in general and relays in particular - is there something like that in libp2p/IPFS already?

[dryajov]

@vyzo

Perhaps we could maintain a service to facilitate this.

I think there should a mechanism to rate/blacklist peers/nodes and it should live on the DHT? This should be probably a built in mechanism that allows the network to self heal/manage. If a massive attack with hundreds or thousands/millions of malicious relays is deployed, it could be a pretty bad day if there is no clear way for the network to avoid those relays?

Just a few ideas on rating categories:

• This peer are fast and uptime is good - some measure of good here
• This peer is slow and uptime is bad - some measure of bad here
• This peers is outright malicious avoid at all costs - blacklist!!!