Skip to content

RFC: dialMe protocol #64

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.

Sign up for GitHub

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

Open
dryajov wants to merge 3 commits into
base: master
Choose a base branch
from
Open

RFC: dialMe protocol #64

Changes from 1 commit
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
7d1c23c
feat: adding dialme protocol
dryajov May 29, 2018
b826284
fix: reword requirements
dryajov May 30, 2018
89075f0
feat: change addrs field to string, to prevent sending multiple multi…
dryajov May 30, 2018
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
40 changes: 40 additions & 0 deletions dialme/README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,40 @@
# Simple protocol to request dial backs

> Allow a peer in a network to be dialed back after an initial connection has been negotiated
In certain scenarios, it might be desirable for a peer to ask another peer to dial it back after an initial connection has been established. This might be useful in scenarios where the dialing peer has learned enough about the network topology and it knows of a better route to be reached over (NATed peers vs non NATed peers). This protocol will allow it to ask its counterpart to dial it back on a hopefully better route.

#### Requirements

- Should be transports agnostic
- Should be connection agnostic
- Can work with or without connection upgrades
Copy link
Contributor

@whyrusleeping whyrusleeping May 30, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

couldnt this all be simplified by saying that the dialme protocol is a standard libp2p protocol? all libp2p protocols are transport and connection agnostic and assume nothing about the network stack implementation

- this implies that the `dialme` protocol assumes nothing about the network stack implementation and is only concerned with requesting dial backs.

In order for dial back to happen a prior connection is required. This prior connection could be established over a circuit (the most likely scenario) or any other preexisting connection. The prior connection is only required to request the dial back, and the `dialme` protocol assumes nothing about it at all.

## Typical `dialme` (back) flow

A `dialme` flow might look similar to the one described below:

- Lets assume that `Peer A` wants to dial `Peer B`
- `Peer A` is publicly reachable on the wider internet
- `Peer B` is behind an impenetrable NAT
- `Peer A` dials `Peer B` using some relay(s)
- Once a connection has been established over the relay(s), `Peer A` asks `Peer B` to dial it back over the provided address using the `dialme` protocol
- `Peer B` proceeds to dial `Peer A` over the provided addresses, dropping the circuited connection once the new connection succeeds
- `Peer A` accepts the dial back and proceeds to use the new connection dropping the relayed one

### The protocol

This is a rather simple protocol that communicates a multiaddress to perform the dial back:

```protobuf
message DialMe {
message Peer {
required bytes id = 1; // peer id
Copy link
Member

@Stebalien Stebalien May 31, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wouldn't include this, the remote side should already know our peer ID and we definitely don't want to end up dialing a different peer.

Copy link
Member Author

@dryajov dryajov May 31, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm... I agree with you, I can't think of a use for this honestly. Unless anyone objects I'll remove it.

repeated bytes addrs = 2; // array of multiadrs
Copy link
Contributor

@whyrusleeping whyrusleeping May 30, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

my main concern with this protocol (and probably the reason it hasnt moved forward until now) is figuring out how to deal with spam and fake dials. If i can tell any peer to try dialing some random set of addresses, i could hypothetically use this to DoS a given ip address. Just connecting to a bunch of libp2p peers and saying "dialme at [all these addresses that are really the sameish]"

Copy link
Member Author

@dryajov dryajov May 30, 2018 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good point. I think in this case, having an array of addresses is a huge attack vector, we can limit that to only one address per request, as well as throttle dial back requests coming from the same peer. I though about nonces and challenge response schemes, but they don't seem to work in this case.

}
optional Peer peer = 1;
```