Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

discv5: transport pre-negotiation packet (LETSTALK) #83

Closed
FrankSzendzielarz opened this issue Apr 12, 2019 · 3 comments · Fixed by #157
Closed

discv5: transport pre-negotiation packet (LETSTALK) #83

FrankSzendzielarz opened this issue Apr 12, 2019 · 3 comments · Fixed by #157
Labels
proposal Ideas and proposals related to devp2p

Comments

@FrankSzendzielarz
Copy link
Member

FrankSzendzielarz commented Apr 12, 2019

This is more of a discussion starter / idea than a concrete proposal:

Although it's not yet documented, the discv5 spec seems to be evolving towards encrypted aes-gcm based communication, rather than obfuscation and recoverable signatures....

Assuming we get there, the following idea:

  1. The discv5 protocol now involves a quick handshake of secrets and keys from ENRs, before any kind of Kademlia communication can happen
  2. Aes-gcm allows parallel communication
  3. Can the same shared secrets and cypher ('channel') be re-used for TCP?
  4. Because it is aes-gcm, large messages can be streamed.
  5. This would allow ETH (etc) protocol to work without handshake.

Regarding libp2p - other implementations that want to use libp2p for flexibility and interoperability could do so (eg: polkadot) - and they could be able to communicate with nodes that use such a mechanism as proposed above (???). Eth 2.0 will use discovery v5 anyway in all likelihood.

However, for implementations that want to deliver a single performance optimized method of networking that employs a common udp+tcp handshake, the discovery 'channel' (pardon the pun) and this aes-gcm encrypted communication would be all that was needed, as long as the transport was reliable. Which particular transport outside of TCP could in future be determined by ENR (eg: ETH = tcp 30303, http 80 etc)

Thoughts?

@FrankSzendzielarz FrankSzendzielarz added the proposal Ideas and proposals related to devp2p label Apr 12, 2019
@fjl fjl changed the title discv5 channel re-use for tcp or other streamed transports discv5: channel re-use for tcp or other streamed transports Aug 15, 2019
@fjl
Copy link
Collaborator

fjl commented Aug 15, 2019

If needed, we can add a protocol message like LETSTALK to help with establishing communication through another transport protocol. This kind of message can relay key material or initialization data for a new connection.

Regarding the secrets, I think the outputs of the handshake should NOT be reused in any way. It's fragile enough as-is.

@fjl fjl changed the title discv5: channel re-use for tcp or other streamed transports discv5: transport pre-negotiation packet Nov 22, 2019
@fjl fjl added this to the Discovery v5 milestone Nov 22, 2019
@fjl
Copy link
Collaborator

fjl commented Nov 22, 2019

The need for this is now becoming more urgent since @zsfelfoldi wants to add pre-negotiation to les.

Here's the use case: when a client finds a server, it needs to establish a TCP connnection and run the handshake only to find out that the provided service is too expensive or not enough capacity is available. Discovery should be able help with this issue by providing enough information to make an informed connectivity decision.

With the LETSTALK packet from the previous comment, pre-negotiation would look as follows:

A -> B   LETSTALK [<req-id>, "les"]
A <- B   LETSTALKRESPONSE [<req-id>, <server-info>]

@fjl
Copy link
Collaborator

fjl commented Nov 22, 2019

We might need a better name for this new packet pair, and a clearer definition of its semantics.

@fjl fjl changed the title discv5: transport pre-negotiation packet discv5: transport pre-negotiation packet (LETSTALK) Jan 17, 2020
@fjl fjl mentioned this issue Jul 29, 2020
2 tasks
@fjl fjl closed this as completed in #157 Oct 7, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
proposal Ideas and proposals related to devp2p
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants
@fjl @FrankSzendzielarz and others