search

vacp2p / rfc

Modular p2p messaging stack, with a focus on secure messaging.
https://rfc.vac.dev/
115 stars 14 forks source link

25/LIBP2P-DNS-DISCOVERY: Leaf entry format to allow for multiple mutliaddrs and self signature #462

Closed D4nte closed 3 years ago

D4nte commented 3 years ago

Problem

During the implementation of EIP-1459 in nim-waku, the ENR encoding format was preferred over encoding a multiaddr due to the fact that multiaddr format cannot include a self signed signature and that multiaddresses bring little benefits over ENR.

During the implementation of EIP-1459 in js-waku it was discovered that the following information MUST be present in the ENR tree for EIP-1459 to be useful for Waku nodes in the browser:

EIP-778 ENR currently does not pre-define keys to store such values. However, it is possible to extend the ENR format with arbitrary keys.

Considered solutions

Several solutions were proposed for the extension of the ENR format. For example, new fields fqdn and wss to respectively encode the peer domain name and websocket port. It was concluded that the most future proof solution would be to introduce a new key value multiaddr that could contain one (or several) multiaddresse(s).

This would not only allow wss and fqdn information to be encoded in the ENR (thanks to the dns4, dns6, and wss keys of the multiaddr format) but it would also future proof the format (e.g. support of quic protocol) thanks to the self-describing characteristics of multiaddr.

However, adding a multiaddr key to ENR lead to handling 2 layers of encoding (ENR and then multiaddr) for no to little benefits. This could be justifiable for backward compatibility reasons (e.g. we had several implementation of Waku v2 in the wild using ENR format) but DNS discovery in Waku v2 is brand new and not yet deployed in the prod fleet.

Also, it is not certain how multiple multiaddr would be encoded. Indeed, EIP-788 states that a key can only be present once. Meaning that within the multiaddr value, additional information such as number of multiaddresses encoded would need to be catered for, adding another layer of codec logic.

Proposed solution

Libp2p's RFC 0003 - Peer Routing Records defines a format that satisfy all sought characteristics:

Size consideration

One question remains unanswered: Can RFC 003/RFC 002 records fit in TXT DNS records?

Let's review EIP-778 space usage.

EIP-778 uses URL-safe base64 alphabet omitting padding characters for text encoding. Using a similar text encoding seems appropriate.

Maximum size

DNS TXT records MUST have a maximum length of 255 bytes (rfc6763).

However, it is possible to register several TXT entrioes against the same fqdn and concatenate the entries to extract a string longer than 255 characters.

EIP-778 defines a maximum encoded size of 300 bytes.

Base 64 Encoding enables [..] 6 bits to be represented per printable character.

300 bytes = 300 octet = 2400 bits = 400 characters.

Which means that, at most, ENR records may take 2 TXT DNS entry (255 * 2 = 510) to be stored.

Typical size

EIP-778 states:

A record containing a IPv4 address, when signed using the “v4” scheme occupies roughly 120 bytes, leaving plenty of room for additional metadata.

Definition of done

Size consideration

Calculation of the typical size of RFC-003 data (wrapped in an RFC 002 signed envelope) should be done to know whether it would fit in a single TXT DNS entry when encoded in base 64.

Currently, a typical RFC 003 record would contain:

Also, review of a practical maximum size for the record should be done to ensure that there is enough space to add further multi addr entries within a reasonable byte space (EIP-778 usage of 2 DNS TXT record could be used as reference).

Spec update

If appropriate (see size consideration), propose a spec change to replace multiaddr entries with RFC 002/RFC 003 entry.

D4nte commented 3 years ago

Cc: @richard-ramos @jm-clius

jm-clius commented 3 years ago

Thanks, @D4nte.

Roughly I think this is a sane approach and agree with the proposed changes to RFC 25. Size consideration is important, but so is it for EIP-778. As far as I can see, this should be relatively simple to implement using the existing EIP-1459 code as baseline.

In fact, the idea was always that after a standard EIP-1459 implementation we could implement our own deviated standard if it provides enough benefit. 👍

arnetheduck commented 3 years ago

The main difference between multiaddr and enr is that enr are signed - ie they offer a higher degree of securiy - they're also containers for multiple formats, one of which could be multiaddr.

The discovery mechanism in ethereum is based on ENR - this means there's a large deployed fleet of nodes that provide lookup capabilities - these and other reasons have been enough to tilt our preference towards enr in general.

When lookup is made too specific, it also becomes easier to spoof and block - there is strength in following the herd because it makes it more difficult to pick out waku among other users, making it more expensive and difficult to block.

D4nte commented 3 years ago

The main difference between multiaddr and enr is that enr are signed - ie they offer a higher degree of securiy

This is why we propose the use of RFC 002 Signed Enveloppes.

The discovery mechanism in ethereum is based on ENR - this means there's a large deployed fleet of nodes that provide lookup capabilities - these and other reasons have been enough to tilt our preference towards enr in general.

Are you saying we could use the Ethereum discovery fleet of nodes to lookup Waku v2 nodes?

Would it actually be practical? The Ethereum fleet only support UDP, which creates challenges for browser nodes to do any lookup. Proxy services are being built to allow a bridge from websocket to UDP. But then, it means that the large fleet of nodes is not really usable for browser client and they would have to relay on these bridges which could become the target.

D4nte commented 3 years ago

Also note that RFC 002/003 are on the libp2p roadmap [1] [2].

Meaning it's not "abandoned" but in the works. The "too specific lookup" issue should be attenuate/moot if all libp2p traffic uses these format.

D4nte commented 3 years ago

Are we not supporting UDP in nim-waku? https://github.com/status-im/nim-waku/pull/728

Which means that using ENR would be of no help if the only point is to generate traffic similar to eth2 (UDP only).

arnetheduck commented 3 years ago

Well, ENR records are independent of how you obtain them - ENR is used in discv5 which indeed is an UDP-based discovery protocol, but they're also used in DNS-based trees, and could reasonably be used elsewhere - they're just a key-value store with some useful properties - for web client use, a web socket bridge for discoveryv5 is being built, which will also be used by the portal client we're building (fluffy).

arnetheduck commented 3 years ago

the libp2p roadmap may or may not get implemented - it usually requires an interested party with a concrete use case to drive it - ENR is there, it's been audited and released and is in use today.

arnetheduck commented 3 years ago

also, it seems easier to extend ENR with a new key for multiaddrs or indeed websockets (the latter is likely generally interesting) than to build another dns-based discovery mechanism with a different format.

0x-r4bbit commented 3 years ago

Are we not supporting UDP in nim-waku? status-im/nim-waku#728

@D4nte No UDP support, which is why the UDP config options is being removed from the CLI in status-im/nim-waku#728. However, there's underlying libp2p APIs nim-waku depends on and those require UDP ports.

Getting rid off those seems to be a big refactor, probably also requires changes in libp2p, so the PR only removes the CLI option and sets a dummy UDP port (that isn't actually used for anything meaningful).

D4nte commented 3 years ago

After further discussion with @oskarth, we decided to proceed with EIP-1459/ENR implementation for now.

IMHO, the main reasons are:

While the ENR solution is not as elegant, it can suffice and we can revisit this decision at a later stage (e.g when introducing a new transport protocol such as quic).

I'll write an RFC for ENR usage.

D4nte commented 3 years ago

ENR usage RFC: https://github.com/vacp2p/rfc/pull/465

jm-clius commented 3 years ago

Can be closed once https://github.com/vacp2p/rfc/pull/465 is merged