I wanted to synthesize some of the interesting events that took place on the public network and in the Interledger gitter last week. Over the past while, several users have been reporting errors connecting to the network. Some of this was due to individual nodes being out of date - in fact, nearly every public XRP-enabled connector was not functional (public defined by inclusion in connector_list.json).
Strata’s connector was working however, but after some debugging I discovered that the their XRP wallet had very little unlocked liquidity - which had interesting consequences for the network. As the only functional connector, the fact that no new channels could be opened meant that the Interledger was effectively “down.”
Modern problems require modern solutions, however. This being 2019 and blockchains being public, I realized that there was a way to prove liquidity was the issue and bring the network back online - I simply located and (lightly) funded Strata’s XRP liquidity pool myself. Immediately, basic network functionality resumed.
This is not a permanent solution however, and I believe the underlying problem presents an attack vector on the network. If I were a bad actor, I could run a zero-cost (but not zero capital) “DDoS” by eating up every connector’s liquidity. This weekend, I could’ve taken down the Interledger (for new connections) with ~$50 and a shell script. And even if the price was much higher, the fact that I can recover almost 100% of funds dedicated to such an attack by closing channels after the desired damage is done dramatically increases the set of actors with such capabilities in practice.
Arriving at the point - while IP does not attempt to prevent DDoS and my intuition is that ILP wont/shouldn’t either, I think last week’s learning shows that there is definitely room for discussion as to how such attacks can be prevented in practice. Currently, ILP documentation (RFC 0018) suggests the below:
Connectors should monitor the percentage of their total liquidity that is on hold at any given time for a given peer, customer, or destination prefix and may reject incoming payment requests if that party exceeds their allocated “payment bandwidth”. Connectors may allocate less bandwidth to unknown or untrustworthy senders or receivers.
However, because the underlying ledgers are unprivileged there is no easy way to distinguish attacker channel creation requests from honest ones. The basic solution is to restrict new connections, but that effectively brings us back to the original problem - new users can’t connect to the Interledger.
Would love to continue the discussion.