Thanks Bastien for writing up the proposal, it is simple but effective I think.
>> One issue I see w/ the first category is that a single party can flood the >> network and cause nodes to trigger their rate limits, which then affects >> the >> usability of the onion messages for all other well-behaving parties. >> > > But that's exactly what this proposal addresses? That single party can > only flood for a very small amount of time before being rate-limited for > a while, so it cannot disrupt other parties that much (to be properly > quantified by research, but it seems quite intuitive). Indeed, it creates a tiny bubble (1-2 hops) in which an attacker can indeed trigger the rate-limiter, but beyond which its messages simply get dropped. In this respect it is very similar to the staggered gossip, in which a node may send updates at an arbitrary rate, but since each node will locally buffer these changes and aggregate them, the effective rate that is forwarded/broadcast is such that it doesn't overwhelm the network (parametrization and network size apart ^^). This is also an argument for not allowing onion messages over non-channel connections, since otherwise an attacker could arbitrarily extend their bubble to encompass every channel in the network, and can sybil its way to covering the entire network (depending on rate limiter, and their parameters and timing the attacker bubble may extend to more than a single hop). Going back a step it is also questionable whether non-channel OM forwarding is usable at all, since nodes usually do not know about the existence of these connections at all (not gossiped). I'd therefore not allow non-channel forwarding at all, with the small exception of some local applications, where local knowledge is required, but in that case the OM should signal this clearly to the forwarding node as well or rely on direct messaging with the peer (pre-channel negotiation, etc). >> W.r.t this topic, one event that imo is worth pointing out is that a very >> popular onion routing system, Tor, has been facing a severe DDoS attack >> that >> has lasted weeks, and isn't yet fully resolved [2]. >> > > I don't think we can compare lightning to Tor, the only common design > is that there is onion encryption, but the networking parts are very > different (and the attack vectors on Tor are mostly on components that > don't exist in lightning). Indeed, a major difference if we insist on there being a channel is that it is no longer easy to sybil the network, and there are no ways to just connect to a node and send it data (which is pretty much the Tor circuit construction). So we can rely on the topology of the network to keep an attacker constrained in its local region of the network, and extending the attacker's reach would require opening channel, i.e., wouldn't be free. Cheers, Christian _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
