Separate the connector from the ILP kit API

[dappelt]

Currently, the ILP connector runs in the same process as the ILP kit API, which substantially increases the attack surface on the connector.

For example, a malicious sender could get a connector to put money on hold for a payment to a destination account he controls. Before the sender would fulfill the payment, he would provoke the ILP kit's API to crash (e.g. with an uncaught exception, like this or this). Since the connector runs in the same process as the API, the connector also becomes unavailable. Then, the receiver fulfills the payment, the connector cannot forward the fulfillment and, hence, loses his money.

To mitigate this problem we could run the connector in a separate process like we do it with the ledger.

[vhpoet]

@sharafian how would we add plugins to the connector if we run the connector as a separate process?

[justmoon]

Not sure we should do this at all. Let's discuss when we can.

[dappelt]

Can you elaborate why you do not want to separate them? In summary, my arguments for separating them are:

• Contradicting Design Goals: The ILP kit API has to be a public endpoint. On the other hand, it was a conscious design choice for the connector not to have a public endpoint. A public endpoint makes an easy target for Denial-of-Service attacks. The incentive for an attacker to perform a DOS attack on a connector is high since he can steal money, while the incentive to DOS the ILP kit API is "only" to make it unavailable (Users can't login, send payments, etc. but no money is lost).

• Increased Attack Surface: As outlined in my first post, bugs in the ILP kit API will affect the connector. Such bugs do not have to be necessarily uncaught exceptions that crash the ILP kit. They could be more subtle. For example, a synchronous function call that blocks node's event loop a little too long for the connector to fulfill payments in time. In the context of the ILP kit, such a synchronous function would only be a minor annoyance. However, in the context of the connector, it might be sufficient to steal funds.

[emschwartz]

I would agree with @dappelt. I think the safest option would be for the connectors to use something like WebRTC to communicate with one another. The ilp-kit could be used to broker an initial connection, but then all messaging would be done directly. That way, if the ilp-kit goes down or is unresponsive the connectors can still talk to one another.

[michielbdejong]

I would like to approach @dappelt's proposal from a product perspective as well. ilp-kit combines a lot of our reusable components, thereby testing all of them, and that is useful: as a code example, as an integration test, as an experimentation platform, and to demonstrate that we have working code for the RFCs we publish.

However, maybe we should stop viewing ilp-kit as something you want to run as your node on the public Interledger? For that, it could also make sense to run just a connector on your server, and run ilp-kit on localhost?

[michielbdejong]

The connector in the middle is running on a secret IPv4 address, only known to its administrator and its two peers. It is firewalled off so it only allows traffic from its peers and its administrator's office location. If you're really professional about it, use 3 secret IPv4 addresses, one for each connecting party.

If you DoS the sending connector, the ledger inside the sending ilp-kit forgives it for fulfilling late. If you DoS the receiving connector, there are two cases:

• receiver process inside ilp-kit -> it will seem like the fulfilling never happened
• receiver in ledger user's client-side client -> the ilp-kit should wait with saying it accepted the fulfillment until its connector has successfully forwarded it.

[michielbdejong]

In order to support ilp-kits running on secret IP addresses, I'll change connectorland so that it can display a public URL with information about a connector, but not publish the actual URL or IP address of the rpc endpoint used for the peering.