Signed peer records update

[AgeManning]

Signed peer records (https://github.com/libp2p/specs/blob/rfc/address-records/RFC/0003-routing-records.md#exchanging-records) (libp2p/specs#217) are being introduced into the libp2p specs.

They are an optional feature in gossipsub 1.1 also (as there are bootstrap nodes which can communicate peer records). I imagine signed records will be primarily suited to discovery-like protocols (kad, mdns, identify).

As I understand, in go there is a global peer store which these discovery mechanisms can update to include signed peer records. Gossipsub (which I'm most familiar with) can then access these signed records obtained from discovery mechanisms and can send them to peers on request.

Firstly, I'm curious if Signed Peer Records are on the radar for implementation? If so, I imagine some core changes to the API for NetworkBehaviour such that protocols can have access to a somewhat global peer store that can be updated by other protocols. Perhaps there's better ways of handling this. I'm curious about everyone's thoughts on how this would be implemented in the rust-libp2p context or if there is interest in having it implemented at all.

[mxinden]

Firstly, I'm curious if Signed Peer Records are on the radar for implementation?

They have not been on my radar thus far. Thanks for the pointers. After having read through the specification I am not sure I fully understand the motivation behind signed peer records. What is the benefit of signed peer records over the existing security provided via peer ids? Could you help me out @AgeManning?

Say there are 3 nodes A, B and C. A and C know the address of B. B knows the address of A and C. But A and C don't know the addresses of each other.

A asks malicious node B for the multiaddress of C. B replies with a wrong multiaddress routing A to malicious node B* instead. Given that B* can not authenticate itself with the peer id of C, A would disconnect from B*, maybe flagging B as malicious. B can not trick A into thinking B* is C. With signed peer records A would not have to make a connection to B* given that the signature of the peer record returned by B is invalid. Is not having to do a connection to B* the motivation behind signed peer records?

I see that signed peer records also offer the notion of sequence numbers. In which scenarios would a peer change their address so often that signed peer records are worth the additional complexity? Does this target environments where nodes are operated behind home routers being assigned a new public IP every 24h?

[AgeManning]

Good question! To be honest, I hadn't entirely thought through the motivation of these in the libp2p context.

We are using a separate discovery mechanism (discv5) which we use to discover peers on our network. There is a very similar object there, an Ethereum Node Record (ENR). All our peers thus are associated with a signed record (ENR). They are useful for us, because in addition to SocketAddrs, they contain various extra application specific information which is quite useful to have signed (we can discover peers which specific properties values without having to dial and find out later).

In the peer routing spec, it seems people are concerned with having a dialing strategy, which only dials verified addresses. This is something that signed records allows. I guess the attack vector here is a malicious node getting other nodes to attempt connections to arbitrary addresses (maybe for DoSing a particular IP).

Another point, would be to allow discovery protocols to collect, store and propagate records without having to dial each one to check validity against the id. 🤷

The go implementation has a version of these, so our main motivation was interoperability here.

I see that signed peer records also offer the notion of sequence numbers. In which scenarios would a peer change their address so often that signed peer records are worth the additional complexity? Does this target environments where nodes are operated behind home routers being assigned a new public IP every 24h?

The discovery that I'm most familiar with is discv5 + enr's. It's UDP based so doesn't have static connections. It has a ping RPC built in which allows for identifying out of date sequence numbers and updating the records. It can handle IP switching etc behind home routers etc.

I imagine for kad, a similar thing could happen mixed with the ping and/or identify protocols.

I've not been following this update in libp2p so I probably can't give you a more satisfactory answer, and it might be worth asking the question directly on the spec issues/PRs.

[thomaseizinger]

Closing this as completed, we have them in libp2p-core now.