7riw77 at gmail.com [ARCHIVE] on Nostr: 📅 Original date posted:2018-01-21 📝 Original message: > Yes, but it still ...
📅 Original date posted:2018-01-21
📝 Original message:
> 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 --
1. 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
2. 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
Published at
2023-06-09 12:48:29Event JSON
{
"id": "c0f367816261712516eaa89036c1e42233f814d717419767b26e4edbe728cd46",
"pubkey": "71ee7d50cfca84b0c16b6892ca51fcfcf7556b903ca505a902e8a434c67533fa",
"created_at": 1686314909,
"kind": 1,
"tags": [
[
"e",
"2a4926c7999f60c613526723369cef244df2cc105602a16cdb8a4a5833ba7a81",
"",
"root"
],
[
"e",
"516643b29998e80df778e30a73b7ee81b0129aaf40df546205c5955af75fd470",
"",
"reply"
],
[
"p",
"4505072744a9d3e490af9262bfe38e6ee5338a77177b565b6b37730b63a7b861"
]
],
"content": "📅 Original date posted:2018-01-21\n📝 Original message:\n\u003e Yes, but it still limits how much damage each peer can do to the node.\n\u003e And I think you overstate the ease of distributed denial of service attacks,\n\u003e and the relative resource consumption differences on an attacker simulating\n\u003e multiple nodes versus one simulating a single node.\n\nSo 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. \n\nThere 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. \n\nWhen 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. \n\nThere 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 --\n\n1. 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\n2. 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\n\nThere may be other solutions, as well; just throwing some ideas out there.\n\n😊 /r",
"sig": "140b194ba8977bcb44bfad3a7ea1600976d273b848322b356ce0b7a456e02f483f3a13e3b2968b2620bf6597928fe8902792047f1c5bb6c79a2b2bb071c4233b"
}