Published on: 2022-07-26T08:16:24+00:00
In a recent email thread, members of the Lightning Network community discussed proposals for rate-limiting onion messages to mitigate denial-of-service (DoS) attacks. One proposal suggested applying backpressure to limit the rate of incoming onion messages. However, concerns were raised about its reliability for tasks like fetching invoices. It was also mentioned that lessons could be learned from Tor, although the two systems are not identical.Another proposal involved introducing pre-payments for Hash Time-Locked Contracts (HTLCs) to mitigate jamming attacks. However, determining a reasonable cost for these pre-payments without impacting system usability was acknowledged as a challenge. Alternative solutions, such as the forwarding pass approach, were also discussed.During the discussion, Rusty proposed a scheme for DoS protection for onion messages. This scheme involved rate-limiting per-peer incoming onion messages and using the node_id of the peer who sent the messages to track their origin. When an incoming onion message reached the rate limit, the receiver would send an `onion_message_drop` message to the sender, indicating congestion and allowing the sender to retry through a different path. However, concerns were expressed about accurately attributing `onion_message_drop` when there is latency between nodes and many onion messages.The conversation also highlighted the differences between the Lightning Network and the internet in terms of tracing sources of DoS attacks. While routers on the internet have physical links and know each other, ties between Lightning Network nodes can be looser. The possibility of extending backpressure to HTLC forwarding rate limiters to combat short-lived spam was mentioned as well.Overall, the discussion emphasized the challenges of designing secure and usable systems for the Lightning Network, particularly in mitigating DoS attacks. Different approaches were considered, including backpressure rate limiting, pre-payments for HTLCs, and the forwarding pass approach. The effectiveness and reliability of these approaches were debated, and further research was encouraged to evaluate their efficiency against various types of spam.During the Oakland Dev Summit, lightning engineers discussed a rate-limiting scheme for onion messaging. The scheme involves applying per-peer rate limits on incoming onion messages that should be relayed, with higher limits for peers with whom the node has channels. Nodes keep track of the origin of onion messages by using the `node_id` of the sending peer. A new message called `onion_message_drop` is introduced and sent when an incoming onion message reaches the rate limit. The receiver sends `onion_message_drop` to the sender, who then relays it to the last sender, halving their rate limits with that peer. If the sender does not exceed the rate limit again, the receiver should double the rate limit after 30 seconds until it reaches the default rate limit.The `shared_secret_hash` field contains a BIP 340 tagged hash of the Sphinx shared secret of the rate limiting peer, allowing the creator of the onion message to determine which part of the route is congested and retry through a different path. However, latency between nodes and multiple onion messages can cause `onion_message_drop` to be relayed to the incorrect incoming peer, resulting in a statistical penalty for the correct incoming peer.There are two classes of proposals for rate limiting onion messaging: back propagation based rate limiting and allowing nodes to express a per-message cost for their forwarding services. The issue with the first category is that a single party can flood the network and trigger rate limits, affecting the usability of onion messages for other well-behaving parties. With the second approach, if an attacker floods the network, they need to directly pay for the forwarding usage themselves. In this case, the attacker incurs a concrete cost, and even if the rates rise, those who truly need the service can continue to pay the new rate.The email thread also mentions the ongoing distributed denial-of-service (DDoS) attack on Tor, which has started to affect the Lightning Network and other related systems. Tor developers have suggested adding proof-of-work (PoW) to mitigate DDoS attacks. They have also discussed using anonymous tokens to allow nodes to give them to "good" clients, similar to the Forwarding Pass idea for onion messaging and HTLC jamming mitigation. The question of whether the same network can be both a reliable micro-payment system and a reliable arbitrary message transport layer remains open.
Updated on: 2023-08-01T00:36:04.436488+00:00