Project Updates: Hybrid Channel Jamming Mitigation

[carlaKC]

This issue will be regularly updated to provide meta updates the ongoing work to mitigate channel jamming attacks in lightning.
It will only be used for meta updates on the project, we'll still use delving / spec calls for discussions.

⚠️ You only need to read this paragraph ⚠️

Currently Investigating: ✨ Does outgoing reputation protect against a sink attack? ✨

TLDR:

• The originally proposed reputation algorithm looked at incoming reputation - see terminology overview here.
• There was no revenue loss under attack for "typical" slow/fast jamming attacks that aim to fill up slots/liquidity.
• This algorithm did not protect against a "sink" attack, where a downstream node passively holds HTLCs to ruin reputation, because it assumes that the malicious party is upstream.

Last update: 21 Jan - simulator with accelerated times for long simulations complete, busy with testing + analytics
Estimated Results™️: Early Feb

Update Log

* 10 Jan - working on speeding up simulations to run long-term sink attacks

---

High Level Tracker:

(1) Is there revenue loss when a node is targeted by a channel jamming attack?

If the price to obtain good reputation is comparable to the cost suffered when it is abused, nodes that are targeted by a jamming attack do not suffer economic loss.

• Incoming reputation attackathon
  • No revenue loss for [slow/fast] [liquidity/reputation] attacks
  • Revenue loss under a "sink" attack
  • Reputation laddering attack is inefficient
  • Surge attack has a pathological edge case
    • How common / severe is this edge case?
• Outgoing reputation investigation
  • Is there revenue loss under a "sink" attack?
  • Is there revenue loss for [slow/fast] [liquidity/reputation] attacks?
  • Do we need bidirectional reputation?
  • Is there a "see-saw" reliability issue (drop if endorsed / drop if not endorsed)?
• Attackathon - try to break it again

(2) Are honest nodes able to obtain reputation?

Honest traffic is protected from jamming attacks in this mitigation if nodes are able to obtain good reputation. We should confirm this with real world data!

• SimLN sanity check: 60-70% of nodes in mainnet sample of 100 nodes can build good reputation*
• Experimental endorsement signaling
• Implementation support:
  • LND
  • Eclair
• BLOCKED: Senders set endorsement signal (waiting on deployment of feature bit in network)
• BLOCKED: Threshold to forward as endorsed for non-binary algorithm
• Data collection

(3) Does resource bucketing have no impact on the steady state?

Under regular operation, the introduction of reputation and resource bucketing should not be a barrier to entry for new/infrequently active nodes because channels are only saturated under attack. We should confirm this with real-world data!

• SimLN sanity check: mainnet sample of 100 nodes processing 2x its capacity per month does not saturate channels*
• Early sanity check with ~10 large nodes in the network: nobody sees > 10 htlcs in flight at once
• BLOCKED: Data collection measuring liquidity/slot usage (will do this alongside (2) )

* Of course, all simulations are highly dependent on assumptions made about traffic patterns. They merely act as a sanity check - if it breaks there, it probably breaks IRL too.

---

Tooling

We've built out a lot of tooling in our research, listed below. This will be useful if you're interested in running simulations yourself, or testing out some of our results.

• Attackathon branch: this repo allows you to spin up a test network in warnet and run attacks against a network fully implementing outgoing reputation mitigation
• LND branch: runs LND with endorsement signals propagated (NOTE: not using the TLV number set in BLIP-004 ⚠️ )
• Circuitbreaker branch: imports golang outgoing reputation library to implement outgoing reputation for LND
• SimLN branch: runs a fully simulated lightning network and records each node's forwards, useful for generating long-term forwarding projects for a topology (supports time speedup)

If you'd like to experiment with any of these HMU! It's a bit of a tangle of branches and dependencies, so can be a bit difficult to navigate.

Background Resources

If you're looking to get up to date with the context of this work, this is a good place to start.

• High level write up: overview of solution
• Original Proposal: this is out of date while we iterate on the proposal!

---

h/t: Package relay tracking issue in core for the idea for this issue.

[t-bast]

@thomash-acinq making sure you're following this thread, we can use this issue to post results and ideas.

[PurpleTimez]

Browsed the "Hybrid Jamming Mitigation: Results and Updates", with some interrogations, which are echoing the open questions in this issue.

The "Resource Jamming" / "Reputation Jamming" Distinction

I got the distinction between ressource jamming, which is the classic loop attack / channel jamming attack characterization where in a simple topology (A <-> B <-> C <-> D and E <-> B), a HTLC sender (e.g E) and receiver (e.g D) are holding the resolution to jam an intermediate link (e.g B <-> C) to provoke a blocking or stealing of routing fees. And on the other hand, reputation jamming, where the protected resources are rendered unusable by downgrading all the peers's reputation with the target node.

I think there can be attacks which are blurring the frontier between "resource jamming" and "reputation jamming". E.g, let's say you have the topology Alice <-> Bob <-> Caroll <-> Dave, with the additional topology segments { Alice <-> Eve <-> Caroll ; Fanny <-> Alice }.

Here, the jamming attackers are Dave, Eve and Fanny and they do a slow jamming on the Alice <-> Bob link to occupy all the protected_slot_count of this channel link with cheap htlc_minimum_msat HTLCs. Indeed, they will burn all the built reputation for the link, however if Alice is a low reputation peer and she receives a consequential influx of inbound HTLC traffic from honest links to send to Caroll, this traffic will be "hijacked" to Eve.

In the described experiment on slow slot jamming, the attack has paid 1,370,485 msat in off-chain fees and the target has earned 1,875,080 msat in off-chain fees. As far as I can tell, there is no indication if hijacked traffic is included in the slow jamming experiment evaluation.

Especially, as in lightning off-chain fees are paid proportionally to the routed amount (bolt7 fee_proportional_millionths) so the occupying traffic for the protected_slot_count might be very cheap while the hijacked traffic to the attacker (here Eve) can be very high, more near htlc_maximum_msat. As fact as I can tell, there is no decaying penalty to occupy high-value slots encumbered by at max low return off-chain fees HTLC.

This would deserve more experiments of course, but I believe a reputation jamming can be leveraged to get a "classic" jamming attack, so I think the two different approach to jamming attacks should be thought in a composable fashion, rather than dissociatively.

The Laddering Attack

If I'm understanding correctly, the idea with the laddering attack is to pipeline routing nodes to acquire reputation on the targeted link to gain the endorsed flag at a lower cost than direct neighboring with the targeted link.

This is interesting that the fuzzing experiment didn't yield a positive attacking result, which is a hint there might some link transitivity already assured by the local resource conservation algorithms.

From browsing the spreadsheet, if I'm understanding correctly the ladder is only built-in on ascending inter-peer traffic denominated in absolute satoshi denominated revenue (10,000 ; 100,000 ; 400,000 ; 800,000). I think an obvious variation could be to layout channels of varying capacity along the ladder, with some asymmetry e.g A <-> B: 0.5 BTC, B <-> C: 0.2 BTC
C -> D: 0.7 BTC and C <-> D 0.6 BTC, contrary to the assumption that size is a proxy for activity.

A well-placed routing node in the lightning topology could get highest absolute routing fee revenue for the same period with smaller capacity due to the topological location.

So let's assume the same scenario than in the paragraph above, where the attack goal is to hijack honest traffic from the target link to a substitution link owned by the attacker. If you have Fanny <-> Alice <-> Bob the correct question to ask about laddering is if Fanny <-> Alice is 0.2 BTC and Alice <-> Bob is 0.5 BTC and Bob <-> Caroll is 0.5 BTC the reputation building cost to acquire a 1 sat of protected_slot_liquidity on the Bob <-> Caroll link proportional to the channel capacity ?

Otherwise, I think any differential in the reputation building cost gives an advantage to the attacker in deploying a substitution link on the Alice <-> Bob <-> Caroll link. I.e now, Eve can put 0.3 BTC to capture slow jammed traffic on the ABC links, stealing routing fees income from Bob.

Sink Attack and Footnote 5

There is no walkthrough available for the Sink Attack, so it's hard to get the topology, though if I'm understanding correctly you have a circular topology where Alice <-> Bob * 10 <-> Caroll <-> Alice.

Alice is the attacker and self-forward HTLC to itself, while holding the resolution to downgrade the reputation on the Bob * 10 <-> Caroll links, until Bob * 10 do not send any honest traffic on their links with Caroll. Yes, I think this attack holds, and in fact it's similar to what is described on the local resource conservation 1071 pull request as a resolution_period drift attack (with more details and explanation on how to make the attack stealth).

I think too it can be tempting to think again about monetary solutions here, where the fees is scaled on the max hold time (i.e the HTLC-timeout's nLocktime). Honest peers could get a discount for the fees based on their reputation building cost, after they have proven they're really honest.

[carlaKC]

Browsed the "Hybrid Jamming Mitigation: Results and Updates", with some interrogations, which are echoing the open questions in this issue.

Happy to answer questions on the original delving thread, but I'd really like to keep this issue meta so that discussion isn't scattered across platforms. Feel free to re-post there.