Deprecate the Echo Protocol and Replace with One-way Ping?

#1

A discussion point for the community (plz read the Documenting the Ping Protocol thread for context):

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
Document the ping protocol
#2

we use this to debug right now and it’s extremely useful. It’s very common that only one direction of communication works, which wouldn’t be caught by a unidirectional ping.

as for the security concerns, ilp connectors already forward packets, so I’m not really sure how this could be an attack vector.

1 Like
#3

For a cross-currency connector, the echo protocol might be very dangerous.

Suppose an attacker has two accounts on a connector, on assets A and B. The attacker sends a PREPARE conforming to the echo protocol using asset A. Since there’s no verification of the source address, the attacker can include the address for their own account on asset B. Then, the connector constructs an outgoing PREPARE to the attacker on asset B. The key vulnerability is the connector uses the same amount for the outgoing PREPARE as the attacker defined on the incoming PREPARE. So, if 1 unit of asset B is worth a lot more than 1 unit of asset A, the attacker can make a nice profit.

I haven’t tested this, but that’s my hypothesis after looking over the code in ilp-connector.

1 Like
#4

Oof. It does appear that that’s the case with ilp-connector.

That said, that’s a problem with the implementation, not the protocol itself. As long as the packet is put into the normal flow with other packets going through the router and the exchange rate applier this wouldn’t be a problem. (This issue describes how it should be implemented for interledger.rs)

3 Likes
#5

Sounds like a better approach!

Seems like one of the primary goals of the echo protocol is to evaluate the connectivity of a given path (if it takes a long time or costs a lot, that looks bad for an ILSP). With respect to that, one question I have is, wouldn’t any connector that receives an echo packet be incentivized to just intercept and ‘short circuit’ the path, act as if they’re the destination, and directly echo back to the sender? It’d be faster and cheaper, which makes it look as if they’re closer/more connected to the destination connector than they really are.

(i.e., there’s no way for the sender to know if the destination of the packet was the one that actually responded to it)

2 Likes
#6

it’s still useful internal to a cluster or when you trust that nobody along the path is intentionally misbehaving (i.e. when coil and strata debug our connectivity we’re not worried one of us is lying)

that said I could see an upgrade to this once we switch to secure routing, in which the destination signs the packet with their routing key

1 Like