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
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
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
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
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)
3 Likes
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
2 Likes
Closing the loop on this thread, but it seems like the community has interest in maintaining both protocols. I think the question now is does it makes sense to have separate RFCs for both ping and echo, or a single RFC that contains both?
I’m leaning towards updating https://github.com/interledger/rfcs/pull/516 to contain both protocols.
I’ve just pushed a new variant of the Echo RFC which contains both modes (unidirectional and bidirectional). Feedback welcome!
1 Like
If they are two separate and unrelated protocols, I would lean towards having them in separate RFCs
If they are two separate and unrelated protocols, I would lean towards having them in separate RFCs
I agree, but they don’t seem very separate/unrelated after putting them together into a single RFC. For example, much of the document is the same for both protocol modes (e.g., Intro, Scope, Overview, Terminology). The actual protocol flows are pretty small (~8 lines for unidirectional and ~23 lines for bidirectional).
That said, the actual two flows are quite different. After reading the new RFC commit, do you still think two RFCs are better than one? If you do, that’s enough to sway me to separate them.