Onion Message Jamming in the Lightning Network

Protocol Design
21

Thanks @erickcestari. Let me take a step back to add some color.

Fundamentally, onions are designed to obscure the source. Without a source, direct attribution is impossible, and without direct attribution, an incremental cost must be inferred to hold peers accountable. So, the question becomes, what is that cost? Payment is ideal, but complex in practice. That’s not to say it shouldn’t be done, but I maintain reputation is an underutilized lever that can be deployed today without a protocol change.

By “reputation,” I’m referring to a long-term, holistic judgment about a peer. A rate limit, by comparison, is like a circuit-breaker: a short-term reflex to a burst of traffic. Rate limiting schemes alone, such as (4), leave routing nodes vulnerable to repeated attacks over time.

My argument is, if a circuit is broken, the offending node’s reputation should be charged. To protect its reputation, that node lowers its ingress limits. Lowering ingress limits reduces amplification and increases long-term reputation risk in the direction of the malicious source. Similar to (4), back-propagation limits the short-term damage. Unlike (4), reputation charges diminish the durability of an attack; an adversary can only attack the network as long as they have goodwill with their peers. The underlying assumption is that good actors will have a higher reputation than bad actors and can therefore resist attacks.

a node can build a high score by forwarding HTLCs correctly and then spend it on onion message spam without losing anything.

I contend this attack is not free. The adversary has to do useful work to earn a reputation that is subsequently spent. Also, note that these behaviors can be represented as a cost function that are weighted against each other (i.e “tuning” parameters). A node can charge a high price to relay OMs, but that makes them unreliable as an OM forwarder. If priced too cheaply, a routing node expends system resources as an OM relay without adequate compensation and risks reputation damage with its peers.

This reputation function can be defined by each node independently and can be incrementally improved over time. Individual weights are likely to be more dynamic and unique to a node, while the shape of the function is likely to be widespread. For example, repeatedly breaking a circuit should be charged more than an isolated instance.

With that said, I acknowledge that reputation alone does not fully resolve current attack vectors. Most notably, long-paths take a long time to back-propagate and loops can be used to easily trigger rate limits. The hop-limit described in (2) limits the reach of an adversary, but doesn’t fully resolve the amplification of a loop. A hypothetical onion_message_id could be used to detect loops, but comes at a small privacy cost.

1 Like
22

Thanks for explaining further. Two things I want to check before responding:

  • This implies forwarding OM only to peers you have a channel.
  • Is this reputation a separate metric from the channel-jamming one, or the same score?

And when does an OM cost reputation: only once the upstream peer trips a configured limit, or does every message debit something?

23

This implies forwarding OM only to peers you have a channel.

Out of self-interest, I would expect most OM relaying to occur over channels. But that’s not a necessary constraint here because nodes can evaluate the reputation of any other node on the network, including non-channel peers. For a given node, non-channel peers would presumably have a lower reputation than channel peers, which aligns with the example in (4) where channel peers are afforded 10/sec while non-channel peers only 1/sec.

Is this reputation a separate metric from the channel-jamming one, or the same score?

Independent metrics can be jointly assessed. For example, fee revenue may influence OM budget. But because OM can be misattributed, OM score probably should not influence payments much.

And when does an OM cost reputation: only once the upstream peer trips a configured limit, or does every message debit something?

For the implementations to decide. Generally speaking, coarser accounting (i.e charge on broken circuit) is easier to account for, but also easier for an adversary to game. A routing node that employs a coarser strategy is more likely to take reputational damage from an adversary that maximizes flow through them without tripping the circuit. Meanwhile, granular accounting is more work, but quicker to respond to the adversary. Calling a reputation function is light work with bounded state, so I’d speculate granular accounting is do-able. I suppose a node could even employ a hybrid. In good times, a node can keep a meter; in adversarial times, (after a circuit is broken) the node may switch to a more granular approach.

1 Like
24

I definitely agree that a dynamic reputation system is better than static rate-limiting. While it might not be an easy first step to implement practically (though still worth pursuing), my primary concern is how it affects honest nodes. Specifically, if the system is too restrictive or vulnerable to gaming, legitimate onion messages generated by normal usage could easily end up getting dropped by honest peers.

For a reputation system to actually work, reputation gains must be directly tied to economic incentives. Free or low-cost behaviors, like responding to pings on time or properly relaying gossip, should not grant reputation. Otherwise, an attacker can cheaply farm high reputation without taking on real economic risk.

If the system only penalizes nodes once a threshold or “circuit breaker” is tripped, an attacker simply needs to stay just below that limit. From there, they can continuously spam at a controlled rate without risking their reputation. Worse, by routing their spam through honest intermediate nodes, they can launch a Sybil attack that artificially degrades the reputation of those honest nodes instead.

As additional context: at the Vienna meeting, we agreed on separating the onion_message into distinct header and payload components (Onion V2). This limits the route length to ~6 hops. While this isn’t part of the formal spec yet, it should make spam mitigation models much simpler to reason about, while loops are still possible, their blast radius and amplification potential are significantly capped.

1 Like
25

Free or low-cost behaviors, like responding to pings on time or properly relaying gossip, should not grant reputation.

Agree, reputation is a function of cost

an attacker simply needs to stay just below that limit.

Only simple if the attacker knows that limit. Furthermore, a prudent routing node may apply thresholds at multiple time-intervals (e.g 10/sec, 300/min) to make a constant stream more difficult. At the limit, the most conservative strategy is debit each message.

by routing their spam through honest intermediate nodes, they can launch a Sybil attack that artificially degrades the reputation of those honest nodes instead.

Without source-attribution, this is always a possibility. The question becomes how to mitigate the durability of an attack. Payment is an incremental economic cost. I argue reputation is also an incremental, economic cost.

at the Vienna meeting, we agreed on separating the onion_message into distinct header and payload components (Onion V2)

Glad to hear.

Specifically, if the system is too restrictive or vulnerable to gaming, legitimate onion messages generated by normal usage could easily end up getting dropped by honest peers.

I see this as the loose formulation of an LP problem, where the primal is maximum OM flow and its dual is the minimum cut. Because OMs are cheap, my assumption is the difference between max flow and current demand is high, which means the actual constraints are flexible. Perhaps someone mathematically inclined would be interested in modeling this problem fully.

I’m aware reputation systems are notoriously difficult, but if there’s any setting I’d expect it to be possible, it would be one with well-defined relationships between persistent identities.

1 Like