6 ms·

> Clearly, we are lacking a means for pushing 'cancer' filtering over to the source side of data transit. To the point where it becomes the problem of the sourc

by zrm 9y ago

> Clearly, we are lacking a means for pushing 'cancer' filtering over to the source side of data transit. To the point where it becomes the problem of the source ISP. "Block this customer" (for a while) and "don't send us any traffic at all" (for a while; in response to /far too many/ abusive customers) are the necessary solutions. That problem is hard. It's not just that we need a way to tell the source ISP to drop the traffic on their end, it's that we need a way for them to trust that you are the actual destination and not someone trying to cause a denial of service by having them drop legitimate traffic. Which is basically the key distribution problem, i.e. one of the hardest problems in security. And it's not clear it would even fix it because of the way DDoS works. The attacker has some huge botnet with hosts all over the place. Each of the hosts don't have to send an unusually large amount of traffic, there are just many more of them than there are normal users, which is enough to overload the servers. But unless you have a way to distinguish the attackers from the normal users -- and it has to be something they can't compensate for once you start doing it -- you don't know who to block. What Cloudflare does is to just absorb the traffic by brute force, and then the problem is that they themselves become a centralized target for imposing censorship. So it feels like the solution is some kind of decentralized Cloudflare, in the nature of IPFS or BitTorrent, which causes content to be hosted on more sources the more popular it is. So that if you get a huge traffic surge targeting some specific data, every node hosting it sends it to another node which doubles the number of hosts, and then doubles it again until there are enough sources to handle the traffic.

nokcha 9y ago
>That problem is hard. It's not just that we need a way to tell the source ISP to drop the traffic on their end, it's that we need a way for them to trust that you are the actual destination and not someone trying to cause a denial of service by having them drop legitimate traffic. I think a large part of it could be solved by a combination of (1) egress filtering and (2) the ISP enforcing TCP congestion control -- so that if a DDoS'd server stops sending an ACKs to an attacker, the attacker get limited (at its own ISP) to 1 packet every few seconds. For UDP, something similar could probably be done -- e.g., if no packets are received from the other host, then drastically rate-limit the bandwidth to that host. (I'm not sure if this would break any widely used UDP protocols, though.)
- jsjohnst 9y ago
  Hell, I’d be happy if ISPs blocked outbound traffic with source IPs outside their blocks. That alone seems to be asking to much sadly.
- zrm 9y ago
  "Have middleboxes do something" as a method of solving problems has historically created more problems than it solved. The current dark age where nearly everything uses TLS/443 has been the net result, because for a significant minority of networks nothing else can get through. People are now even running DNS over TLS, even though DNS itself is allowed and DNS over TLS is complicated and inefficient, because the middleboxes prevent the DNS protocol from evolving to have better security. Inviting more interference would only create more problems. For example, suppose I want to create a multipath UDP-based protocol where the acknowledgments can be consolidated (and so only sent along one path). That proposal would break it and force me to use something less efficient. In general it creates asymmetric routing problems at the ISP level. Middlebox "solutions" cause problems that are hard to predict and even harder to fix after the fact, because once 20% of networks are doing something it's hard to get half of them to stop even after the problems are discovered. And it may not even solve the original problem. What happens when the DDoS is just a botnet acting like a huge number of normal users?
  - reificator 9y ago
    > What happens when the DDoS is just a botnet acting like a huge number of normal users? I thought that's exactly what the first `D` stood for...
    - zrm 9y ago
      They can do things like spoof DNS requests from the victim which are known to have large responses. The attacker causes ~4000 bytes of traffic to be sent to the victim from the DNS server by sending a ~40 byte DNS request. That amplifies the attacker's bandwidth but is a lot easier to distinguish from normal traffic, and would be prevented if everyone did egress filtering because then the attacker couldn't spoof the requests. But that only prevents the amplification, not the general problem. A botnet with millions of computers in it has enough bandwidth even without amplification to cause plenty of trouble.

by zrm 9y ago

nokcha 9y ago

>That problem is hard. It's not just that we need a way to tell the source ISP to drop the traffic on their end, it's that we need a way for them to trust that you are the actual destination and not someone trying to cause a denial of service by having them drop legitimate traffic. I think a large part of it could be solved by a combination of (1) egress filtering and (2) the ISP enforcing TCP congestion control -- so that if a DDoS'd server stops sending an ACKs to an attacker, the attacker get limited (at its own ISP) to 1 packet every few seconds. For UDP, something similar could probably be done -- e.g., if no packets are received from the other host, then drastically rate-limit the bandwidth to that host. (I'm not sure if this would break any widely used UDP protocols, though.)

jsjohnst 9y ago
Hell, I’d be happy if ISPs blocked outbound traffic with source IPs outside their blocks. That alone seems to be asking to much sadly.
zrm 9y ago
"Have middleboxes do something" as a method of solving problems has historically created more problems than it solved. The current dark age where nearly everything uses TLS/443 has been the net result, because for a significant minority of networks nothing else can get through. People are now even running DNS over TLS, even though DNS itself is allowed and DNS over TLS is complicated and inefficient, because the middleboxes prevent the DNS protocol from evolving to have better security. Inviting more interference would only create more problems. For example, suppose I want to create a multipath UDP-based protocol where the acknowledgments can be consolidated (and so only sent along one path). That proposal would break it and force me to use something less efficient. In general it creates asymmetric routing problems at the ISP level. Middlebox "solutions" cause problems that are hard to predict and even harder to fix after the fact, because once 20% of networks are doing something it's hard to get half of them to stop even after the problems are discovered. And it may not even solve the original problem. What happens when the DDoS is just a botnet acting like a huge number of normal users?
- reificator 9y ago
  > What happens when the DDoS is just a botnet acting like a huge number of normal users? I thought that's exactly what the first `D` stood for...
  - zrm 9y ago
    They can do things like spoof DNS requests from the victim which are known to have large responses. The attacker causes ~4000 bytes of traffic to be sent to the victim from the DNS server by sending a ~40 byte DNS request. That amplifies the attacker's bandwidth but is a lot easier to distinguish from normal traffic, and would be prevented if everyone did egress filtering because then the attacker couldn't spoof the requests. But that only prevents the amplification, not the general problem. A botnet with millions of computers in it has enough bandwidth even without amplification to cause plenty of trouble.