Joost Jager [ARCHIVE] on Nostr: 📅 Original date posted:2022-07-10 📝 Original message: On Thu, Jun 30, 2022 at ...
📅 Original date posted:2022-07-10
📝 Original message:
On Thu, Jun 30, 2022 at 4:19 AM Matt Corallo <lf-lists at mattcorallo.com>
wrote:
> Better yet, as Val points out, requiring a channel to relay onion messages
> puts a very real,
> nontrivial (in a world of msats) cost to getting an onion messaging
> channel. Better yet, with
> backpressure ability to DoS onion message links isn't denominated in
> number of messages, but instead
> in number of channels you are able to create, making the backpressure
> system equivalent to today's
> HTLC DoS considerations, whereas explicit payment allows an attacker to
> pay much less to break the
> system.
>
It can also be considered a bad thing that DoS ability is not based on a
number of messages. It means that for the one time cost of channel
open/close, the attacker can generate spam forever if they stay right below
the rate limit.
> Ultimately, paying suffers from the standard PoW-for-spam issue - you
> cannot assign a reasonable
> cost that an attacker cares about without impacting the system's usability
> due to said cost. Indeed,
> making it expensive enough to mount a months-long DDoS without impacting
> legitimate users be pretty
> easy - at 1msat per relay of a 1366 byte onion message you can only
> saturate an average home users'
> 30Mbps connection for 30 minutes before you rack up a dollar in costs, but
> if your concern is
> whether someone can reasonably trivially take out the network for minutes
> at a time to make it have
> perceptibly high failure rates, no reasonable cost scheme will work. Quite
> the opposite - the only
> reasonable way to respond is to respond to a spike in traffic while
> maintaining QoS is to rate-limit
> by inbound edge!
>
Suppose the attacker has enough channels to hit the rate limit on an
important connection some hops away from themselves. They can then sustain
that attack indefinitely, assuming that they stay below the rate limit on
the routes towards the target connection. What will the response be in that
case? Will node operators work together to try to trace back to the source
and take down the attacker? That requires operators to know each other.
Maybe this is a difference between lightning network and the internet that
is relevant for this discussion. That routers on the internet know each
other and have physical links between them, where as in lightning ties can
be much looser.
Joost
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220710/d7fe084e/attachment.html>;
📝 Original message:
On Thu, Jun 30, 2022 at 4:19 AM Matt Corallo <lf-lists at mattcorallo.com>
wrote:
> Better yet, as Val points out, requiring a channel to relay onion messages
> puts a very real,
> nontrivial (in a world of msats) cost to getting an onion messaging
> channel. Better yet, with
> backpressure ability to DoS onion message links isn't denominated in
> number of messages, but instead
> in number of channels you are able to create, making the backpressure
> system equivalent to today's
> HTLC DoS considerations, whereas explicit payment allows an attacker to
> pay much less to break the
> system.
>
It can also be considered a bad thing that DoS ability is not based on a
number of messages. It means that for the one time cost of channel
open/close, the attacker can generate spam forever if they stay right below
the rate limit.
> Ultimately, paying suffers from the standard PoW-for-spam issue - you
> cannot assign a reasonable
> cost that an attacker cares about without impacting the system's usability
> due to said cost. Indeed,
> making it expensive enough to mount a months-long DDoS without impacting
> legitimate users be pretty
> easy - at 1msat per relay of a 1366 byte onion message you can only
> saturate an average home users'
> 30Mbps connection for 30 minutes before you rack up a dollar in costs, but
> if your concern is
> whether someone can reasonably trivially take out the network for minutes
> at a time to make it have
> perceptibly high failure rates, no reasonable cost scheme will work. Quite
> the opposite - the only
> reasonable way to respond is to respond to a spike in traffic while
> maintaining QoS is to rate-limit
> by inbound edge!
>
Suppose the attacker has enough channels to hit the rate limit on an
important connection some hops away from themselves. They can then sustain
that attack indefinitely, assuming that they stay below the rate limit on
the routes towards the target connection. What will the response be in that
case? Will node operators work together to try to trace back to the source
and take down the attacker? That requires operators to know each other.
Maybe this is a difference between lightning network and the internet that
is relevant for this discussion. That routers on the internet know each
other and have physical links between them, where as in lightning ties can
be much looser.
Joost
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220710/d7fe084e/attachment.html>;