Route Hijacking and DoS in Off-Chain Networks

By: Saar Tochner    Posted previously at Medium

In our new paper, we uncovered a new denial-of-service (DoS) attack that could sabotage payments on the Lightning Network. This method exploits the routing mechanism to attract and hijack transactions using a small number of channels owned by the attacker.
Through our experiments, just five new channels (costing less than 1$) are enough to draw the majority (55% — 75%) of the traffic between nodes. With 30 channels the attacker will hijack more than 80% of all transfers.

Off-chain peer-to-peer networks (a.k.a. payment channel networks)
are a promising approach to mitigate Bitcoin’s scalability problem, which currently supports only dozens of transactions per second.

What is the Lightning Network?

The nodes in the lightning network avoid the overhead of a global consensus for each transaction. Every pair of nodes locks money on the blockchain, which creates a logical “channel” for payments. A payment through this channel is simply an agreement on a new division of the locked funds. Blockchain transactions are only used when opening and when closing the channel.

 

Things get a bit more complex when some sender wants to send money to a node he is not directly connected to. In this mechanism, the source node finds a path in the network’s graph and performs an atomic transfer of money on all channels in the path. To incentivize nodes to participate, the source node pays a fee for using each channel. Nodes publish this fee for all to see, and senders can choose which route they prefer. This is done using a routing algorithm, which prefers routes with lower fees (other parameters are also considered).

Route Hijacking

The attack we present is to strategically create channels with low fees, which attract many nodes to route through them. The attacker then deliberately fails to execute transfers, thereby executing a wide DoS attack.

We studied the three major implementations of the Lightning Network (LND, Eclair, C-Lightning) and simulated each nodes’ decisions for routes. In general we find that all three implementations are similarly susceptible, in spite of their slightly different routing mechanisms.

We base our experiments on the topology of the actual network (which is publicly shared in order to allow nodes to route). Since we do not know the real pattern of transfers, we assume that every pair of nodes in the network tries to execute a single transaction between them.

The following figure shows what percentage of the paths we are able to hijack as a function of the number of channels the attacker added to the network.

 

The liquidity that the attacker needed to place in each channel, is just the maximum over the size transactions he wishes to block.

We can additionally evaluate how many nodes in the current graph can collude to perform a hijack (e.g., if the attacker is already embedded in the network graph). The figure below shows the number of transactions that are currently routed through the most influential nodes.

 

All three implementations randomize over routes to some extent (thus they won’t always use the lowest fee route). C-lightning’s approach was to add “fuzz”, which is random noise to the “weight” function of channels. Fuzz was added as a multiplier to the fee. We notice that this form of noise does little to stop the attack since we use much lower fees than others in the network.

 

A second approach, taken by Eclair, was to uniformly select one of the top three routes. This too fails badly as a defensive strategy against our attack, and in some cases makes things worse.

The example below explains why: if a source is trying to route to the target, then he will be hijacked with probability 0.5. But, with Eclaire’s “top 3” approach, he will be hijacked with probability 0.66.

 

Lastly, LND’s approach punishes nodes along a route that recently failed to forward a transaction. Weight is added to every channel in this route (the specific failing channel is unknown due to onion routing). This method should make the node more resilient to hijacking and denial of service over time.

 

In order to avoid blocking failed routes for prolonged periods of time, LND’s penalty decreases over time. The exact formula for the decay depends on two parameters: n (which is hardcoded to be 100), and h that denotes the number of hours from the last failure to route. The figure to the left shows the impact of the attack for various values of these parameters.

Note that during the attack, the attacker can increase the time that passes between transaction failures (timeouts in lightning can even be several days!) and can thus decrease the penalty for past failing routes.

Conclusions

We consider routing hijacks an important threat to the network. If relaying nodes are to gain from participating, they will try to extract fees, and attackers that are willing to forgo these fees will be able to attract traffic. On the other hand, if senders randomize on routes with no regard to fees, intermediaries will raise transfer fees and use of the network will be prohibitively expensive. Attackers may be difficult to identify, since they can use more than a single nodes (a Sybil attack).

Currently implemented methods for routing do not adequately protect the network, however we are hopeful! Since we first published our paper (6 months ago), routing mechanisms were significantly improved. Specifically, LND has implemented the above method during that period. Unfortunately, as described broadly in the paper, the network is still vulnerable, and further work on routing is needed.

We encourage you to look at more details in our full version of the paper, we welcome any question, constructive feedback, and future cooperation.