From 536ae936326f1af074f748f68d90a8f9fa78ea39 Mon Sep 17 00:00:00 2001 From: Yusef Napora Date: Thu, 14 Nov 2019 11:28:01 -0500 Subject: [PATCH] add "exchanging records" section with use cases --- RFC/0003-routing-records.md | 42 ++++++++++++++++++++++++++++++------- 1 file changed, 34 insertions(+), 8 deletions(-) diff --git a/RFC/0003-routing-records.md b/RFC/0003-routing-records.md index bf24426..23ed5a8 100644 --- a/RFC/0003-routing-records.md +++ b/RFC/0003-routing-records.md @@ -193,7 +193,7 @@ We will need to add a few methods to the peer store: - return the set of self-certified addresses for the given peer id - `SignedRoutingState(peer_id) -> Maybe` - - retrive the signed envelope that was most recently added to the peerstore + - retrieve the signed envelope that was most recently added to the peerstore for the given peer, if any exists. And possibly: @@ -206,6 +206,17 @@ We'll also need a method that constructs a new `RoutingState` containing our listen addresses and wraps it in a signed envelope. This may belong on the Host instead of the peer store, since it needs access to the private signing key. +When adding records to the peerstore, a receiving peer MUST keep track of the +latest `seq` value received for each peer and reject incoming `RoutingState` +messages unless they contain a greater `seq` value than the last received. + +After integrating the information from the `RoutingState` into the peerstore, +implementations SHOULD retain the original signed envelope. This will allow +other libp2p systems to share signed `RoutingState` records with other peers in +the network, preserving the signature of the issuing peer. The [Exchanging +Records section](#exchanging-records) section lists some systems that would need +to retrieve the original signed record from the peerstore. + ## Dialing Strategies Once self-certified addresses are available via the peer store, we can update @@ -213,13 +224,27 @@ the dialer to prefer using them when possible. Some systems may want to _only_ dial self-certified addresses, so we should include some configuration options to control whether non-certified addresses are acceptable. -## Changes to core libp2p protocols +## Exchanging Records -How to publish these to the DHT? Are there backward compatibility issues with -older unsigned address records? Maybe we just publish these to a different key -prefix... +We currently have several systems in libp2p that deal with peer addressing and +which could be updated to use signed routing records: -Should we update identify and mDNS discovery to use signed records? +- Public peer discovery using [libp2p's DHT][dht-spec] +- Local peer discovery with [mDNS][mdns-spec] +- Direct exchange using the [identify protocol][identify-spec] +- Service discovery via the [rendezvous protocol][rendezvous-spec] +- A proposal for [a public peer exchange protocol][pex-proposal] + +Of these, the highest priority for updating seems to be the DHT, since it's +actively used by several deployed systems and is vulnerable to routing attacks +by malicious peers. We should work on extending the `FIND_NODE`, `ADD_PROVIDER`, +and `GET_PROVIDERS` RPC messages to support returning signed records in addition +to the current unsigned address information they currently support. + +We should also either define a new "secure peer routing" interface or extend the +existing peer routing interfaces to support signed records, so that we don't end +up with a bunch of similar but incompatible APIs for exchanging signed address +records. ## Future Work @@ -245,8 +270,9 @@ before interacting with them directly. This could be added as a new field in the [identify-spec]: ../identify/README.md [peer-id-spec]: ../peer-ids/peer-ids.md +[mdns-spec]: ../discovery/mdns.md +[rendezvous-spec]: ../rendezvous/README.md +[pex-proposal]: https://github.com/libp2p/notes/issues/7 [autonat]: https://github.com/libp2p/specs/issues/180 -[ipld]: https://ipld.io/ -[ipld-schema-schema]: https://github.com/ipld/specs/blob/master/schemas/schema-schema.ipldsch [envelope-rfc]: ./0002-signed-envelopes.md [eip-778]: https://eips.ethereum.org/EIPS/eip-778