[Lightning-dev] [1.1] Proposed `funding_cancelled` message

[ZmnSCPxj]

I do not see the relevance of the example.  The limit I propose that nodes will impose is a limit imposed on *each* *peer*, not a limit imposed on all peers in total.  Indeed, imposing the limit on each peer reduces the actual CPU, bandwidth, and storage resources that each peer can consume on the attacked node.  If it did not limit each peer, then each attacking peer can consume significantly more resources (CPU, bandwidth, storage) that other, legitimate peers would want to use.  By limiting each peer to some maximum number of channel open attempts, it allows the server to serve more peers, and possibly shrug off a 10k or 100k attack (depending on the actual CPU/bandwidth/storage resources it has) that it otherwise would be unable to service if each peer could consume an arbitrary amount of resources on the server.

In any case this has diverged from "propose `funding_cancelled` message".  Obviously only cooperative, non-attacking peers will use `funding_canclled`, but only cooperative non-attacking peers will start an `open_channel` sequence and broadcast a valid funding tx to the blockchain network anyway.

Regards,
ZmnSCPxj

Sent with [ProtonMail](https://protonmail.com) Secure Email.

-------- Original Message --------
On January 21, 2018 8:57 PM, <7riw77 at gmail.com> wrote:

>
>
>> Yes, but it still limits how much damage each peer can do to the node.
>> And I think you overstate the ease of distributed denial of service attacks,
>> and the relative resource consumption differences on an attacker simulating
>> multiple nodes versus one simulating a single node.
>
> So assume the following situation: Someone has gotten a "bum deal" on their pizza (or thinks they have), and they want to take down their pizza provider. They note the lightning node the pizza provider uses happens to be some particular address, so they hire out a 10k node botnet (rather small in the real world), and ask each bot to open as many transactions as possible, as fast as possible, without completing any of them, with the ip address of the node in question. The server eventually says "I'm not accepting any more connections, because I have too many outstanding connections right now," which effectively takes it off line for new transactions, blocking anyone who uses that node from any sort of transaction. How long can this last? So long as the botnet continues asking for new connections.
>
> There are ways around this on the network side -- specifically using anycast, like DNS does, to spread the attack around -- but I'm not certain anycast would work in this case because of the state issues involved in lightning.
>
> When I was at Verisign, we figured a 100g link was enough to block any sort of DDoS against the DNS root servers. The attack against Krebs shows just how silly this line of thinking is today.
>
> There is no perfect defense, but it might be useful to think about these things, and how to solve them, now, rather than once they happen, particularly when the trust of the overall network is in play. This might mean several things, such as --
>
> - The closer you can come to stateless on the server side during session setup, before you know the request is going to be followed through/is legitimate, the less chance this sort of thing will happen
> - The more you have the ability to shift a transaction from one server to another without losing some essential state, the more a network of devices can be designed to handle such problems
>
> There may be other solutions, as well; just throwing some ideas out there.
>
> 😊 /r
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180122/66216327/attachment.html>