Document the ping protocol

Protocol Design
1

From @adrianhopebailie on Fri May 18 2018 14:14:17 GMT+0000 (UTC)

Document the ping protocol as implemented in interledgerjs/ilp-connector

Copied from original issue: https://github.com/interledger/rfcs/issues/433

2

From @dora-gt on Mon Aug 27 2018 01:26:40 GMT+0000 (UTC)

I’ll do this next.

3

From @dora-gt on Mon Aug 27 2018 06:37:42 GMT+0000 (UTC)

I could almost understand by reading echo.ts, but I could not find the module that actually sends requests.
Is this used from somewhere?
Could you give me some references that send requests?

4

From @dora-gt on Mon Aug 27 2018 10:32:25 GMT+0000 (UTC)

I found that moneyd-gui used it. So I’ll look into it.

5

From @sappenin on Sat Oct 06 2018 20:09:29 GMT+0000 (UTC)

The ping protocol is in-use in the JS Connector - we should keep this issue open, or else overtly indicate that the ping protocol should not be spec’d.

7

From @adrianhopebailie on Fri Nov 16 2018 12:03:05 GMT+0000 (UTC)

As discussed on the community call on Wed 14 November there are some concerns about the protocol currently implemented in moneyd-gui and ilp-connector.

@emschwartz and @sappenin please feel free to expand on this.
@justmoon and @sharafian your input also welcome as the implementors of these two componenets.

The high level flow for that protocol is as follows:
Assuming Alice (ILP Address: g.alice) is sending a Ping to Bob (ILP Address: g.bob).

  1. Alice generates a new random 32 byte value to use as a fulfilment (F) and generates the corresponding condition (C).
  2. Alice constructs an ILP Prepare packet addressed to g.bob with:
    • a non-zero amount of her choice
    • an appropriate expiry (quite long as it must allow for two round trips along the route)
    • the condition C
    • a data payload consisting of
      • the ascii encoded text string “ECHOECHOECHOECHO”
      • the byte `0x00
      • A return address (g.alice) as an OER encoded, variable length IA5 string (same as encoding used in the packet header)
  3. Alice sends this packet out on the network
  4. On receiving this packet, Bob (a connector) identifies that it is a Ping by the fact that it is addressed directly to his connector address (i.e. it has no tx or child suffix) and by the fact that the byte following the “ECHOECHOECHOECHO” prefix in the payload is 0x00.
  5. Bob DOES NOT immediately send an ILP Fulfill. Instead Bob creates a new ILP Prepare addressed to the address parsed from the payload with:
    • an amount equal to the amount received in the ILP Prepare
    • an expiry that is marginally smaller than the expiry on the ILP Prepare
    • the same condition C
    • a data payload consisting of
      • the ascii encoded text string “ECHOECHOECHOECHO”
      • the byte `0x01
  6. Bob sends this packet out on the network.
  7. On receiving this packet, Alice identifies that it is a Pong by the fact that it is addressed to the address she used in the Ping.
  8. Alice fulfills the packet using the fulfilment she generated at the beginning: F
  9. On receiving the ILP Fulfill from Alice, Bob also fulfills the original Ping from Alice using the same fulfillment.

Observations:

  1. This protocol results in money being spent by both Alice and Bob.
  2. If Alice sends too much Bob can claim some by sending the Pong with less and hoping Alice will still fulfill the Pong.
  3. It’s not clear how Alice could differentiate a Pong from other packets right now as she uses her address with no additional suffix.

Other discussions on the call

  1. Do we need a simpler “heartbeat” protocol that is just between peers to allow the ILP module on each peer to ensure that packets are routable. I.e. Not only is there an available data transport but the connectors are in a state to be able to route packets.
  2. Would an authenticated ping protocol be a better way to go (at the transport layer). (Public middle-boxes like connectors can be contacted securely by sending the payload encrypted with their public key. i.e. You can still ping connectors directly)
8

From @justmoon on Fri Nov 16 2018 12:07:33 GMT+0000 (UTC)

Just going to leave this here: #232

That was a PR to add an RFC for the ping protocol, although that PR describes an earlier version of the protocol, so @adrianhopebailie’s description is more accurate/up-to-date. Still, anyone working on docs for the ping protocol may find it useful to read this for context.

9

From @justmoon on Fri Nov 16 2018 12:27:48 GMT+0000 (UTC)

> It’s not clear how Alice could differentiate a Pong from other packets right now as she uses her address with no additional suffix.

That’s just an implementation detail/bug. The intent is that Alice would choose a unique address that is only used for a particular pinging session.

Remember the model is IP, so we think of moneyd as the stuff that would be built into OSes some day. When a piece of software like a ping tool spins up, moneyd will assign a unique address to it. In the case of a ping tool it will then use that unique address as its return address.

If Alice sends too much Bob can claim some by sending the Pong with less and hoping Alice will still fulfill the Pong.

I don’t see that as an issue. If Bob sends back a lesser amount, that’s no different than if there was simply high friction/fees between Alice and Bob. In many real-world scenarios, the cost of looking like your ILP connectivity is poor is going to vastly outweigh any money you might make from pings. Imagine if a popular connector started doing this: They might make $0.0001 from pings but nobody would want to peer with them because it looks like their connectivity is trash, so they’d quickly go out of business.

In our experience, pings have been used in production mostly to test/debug the routing protocol and to monitor uptime of ILP connectors. You can and should use amounts that are miniscule.

10

From @emschwartz on Fri Nov 16 2018 16:12:23 GMT+0000 (UTC)

@justmoon Are you worried about this being used in DDoS attacks at all? Because the source address isn’t authenticated or checked at all, an attacker could get a lot of other nodes on the network to simultaneously send packets to a single target. The amount of data they’d be sending isn’t that big so there wouldn’t be the amplification problem, but it still seems potentially problematic.

One argument against this being a problem is that it would be easy to filter out and drop these packets if you’re getting too many of them at once (but you need good infrastructure that’s capable of doing that quickly for a ton of packets received in quick succession).

11

From @sappenin on Thu Dec 13 2018 14:57:51 GMT+0000 (UTC)

One observation I’ve had about what we call “ILP Ping” is that it seems to be designed to be analagous to the Ping we all know and love.

What’s interesting here is it that while that protocol (ICMP Ping) employs a “ping” and a “pong” packet, this seems to be more of a result of using ICMP more than anything else (in other words, the ICMP Echo Reply packet feels more like a “response” as opposed to a new request, despite what’s actually going on in ICMP).

The reason I bring that up is that I think it would be useful for us to distinguish between an ILP Ping protocol and an ILP Echo protocol.

Here’s how I see the distinction:

Ping Protocol

  • Option1: Sender sends a Prepare packet with a tiny amount of value, and measures the time it takes to receive a Fulfillment.
  • Option2: Sender sends an unfulfillable Prepare packet, and measures the time it takes to receive a rejection.
  • Rationale: Measure the time it takes to send value in one direction via ILP; Determine if a sending node has payment connectivity to a given destination.

Echo Protocol

  • Functionality: See description above by @adrianhopebailie.
  • Rationale: Measure the time it takes to send value in both directions via ILP; Determine if a sending node has bidirectional (send+receive) connectivity to a given destination.

Any objections to formally defining both protocols as orthogonal things?

14

I introduced a PR for the first part of this feature (i.e, the Ping Protocol). See here: https://github.com/interledger/rfcs/pull/516

2 Likes
15

A discussion point for the community:

The echo protocol feels problematic to me because it constructs a non-normal ILP request/response flow for an atypical use-case; and it forces any implementing connector to make mirror payments in response to an incoming prepare packet (while I can’t think of any overt attack vectors here, it intuitively feels like something I don’t want my Connector to be doing - see one concern above raised by @emschwartz).

So, what if we deprecate the “echo” protocol and rely upon unidirectional ping packets (see my Ping PR) for measuring connectivity and response times, and we use higher layer protocols (like SPSP or STREAM or some others probing payment protocol) to measure things like FX and bandwidth, and possibly even route data?

2 Likes
16

I have decided to move my last comment to a new thread, since it’s a slightly different topic. Please read more here: Deprecate the Echo Protocol and Replace with One-way Ping?