Onion messages rate-limiting

Summary:

During the Oakland Dev Summit, engineers discussed DoS protection for onion messages. Rusty proposed a rate-limiting scheme that propagates back to the correct sender. Nodes apply per-peer rate limits on incoming onion messages they should relay. When relaying an onion message, nodes keep track of where it came from using the node_id of the peer who sent it. A new message is introduced that will be sent when dropping an incoming onion message because it reached rate limits. The shared_secret_hash field contains a BIP 340 tagged hash of the Sphinx shared secret of the rate limiting peer.There are two cases to address here. Firstly, people trying to stream GoT over lightning. In this case, just rate limiting should disrupt their viewing experience such that it becomes unusable. Secondly, an attacker trying to flood the network with OMs. In this case, LN also can’t be compared to Tor because you can limit your OMs to channel partners only, and this in itself provides a proof of work that an attacker can't surmount without actually opening channels. Another huge win of backpressure is that it only needs to happen in DoS situations, meaning it doesn’t have to impact users in the normal case.The email is discussing a potential solution to spamming in the context of onion messaging. The proposed solution is to drop the onion message if it is suspected to be spam and propagate it back to the sender instead. However, this approach would statistically penalize the right incoming peer based on the volume of legitimate onion messages compared to the volume of spam generated by the spamming peer. The email encourages researchers to develop formulas to evaluate the efficiency of this scheme against different types of spam.To increase the accuracy of attributing onion_message_drop, more data could be stored in the future if necessary. The protocol may become more complex as a result, so further research is needed to determine how much accuracy would be gained by storing more data. A link to a GitHub gist containing more information was also provided.Tor has been facing a severe DDoS attack that has lasted weeks, which has started to affect LN and other related systems like Umbrel that rely on tor for networking traversal. Tor developers have suggested adding some PoW to attempt to mitigate DDoS attacks. In summary, we're not the first to attempt to tackle the problem of rate-limiting relayed message spam in an anonymous/pseudonymous network, and we can probably learn a lot from what is and isn't working with how Tor handles things.While the proposal presents one avenue in a long line of research to best figure out how to handle the spam concerns introduced by onion messaging, it still seems to be an open question if the same network can be both a reliable micro-payment system and also a reliable arbitrary message transport layer.

Updated on: 2023-06-03T09:23:43.175105+00:00