Christian Decker [ARCHIVE] on Nostr: 📅 Original date posted:2022-06-30 📝 Original message: Thanks Bastien for ...
📅 Original date posted:2022-06-30
📝 Original message:
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
📝 Original message:
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