3 ms·

This is terrible news in the chilling effects department. The mere fact that CloudFlare and similar services are a "requirement" for not being beaten in to sub

This is terrible news in the chilling effects department. The mere fact that CloudFlare and similar services are a "requirement" for not being beaten in to submission for pennies of traffic flooding in to a website is a clear design flaw of the global communications system. No site or service should be forced to receive //every// bit of information sent at it. Nor should they be forced to blackhole (route) /themselves/ (giving in to the terrorists) out of existence. 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.

devit 9y ago
Yeah, it seems like it should be possible to send a packet using a "firewall rule protocol" to the DoSing IP address, and have any non-malicious routers in between enact a rule that blocks traffic in the opposite direction (obviously there needs to be either spoofing prevention, or the packet must be signed with a certificate provided by the RIR to prove ownership of the source IP address). Why not do this? Is it impossible to design it in a non-abusable way, or is there too much overhead to store and apply a possibly long list of arbitrary blocking rules?
- mjevans 9y ago
  Well, there would be the overhead, so more ideally you'd be submitting such requests to an out of band network (possibly forward to such a CnC network /by/ the routers along the way). The command and control network would authenticate the source request via some means and if it's authentic act accordingly. The benefit of this is that it also allows for identifying infected or otherwise abusive customers and actually being proactive about getting them cleaned up. Of course all of that degrades the 'customer' experience, and costs money. Both of which are probably why no one does this right now.
- zzzcpan 9y ago
  ISPs do this and have such capabilities. They don't necessarily use the same protocol, like BGP Flow Specification (RFC 5575), but they often do provide a way to push filtering rules if you need it and you are an ISP yourself.
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.)
jjrh 9y ago
Based on the article it sounds like they were mostly using the CDN part of Cloudflare's offering. > No site or service should be forced to receive //every// bit of information sent at it. They aren't, but usually public websites/services want to receive everything. Determining what's legitimate or not isn't easy because of the distributed part of DDoS.
totalZero 9y ago
It would be better to use a separate term from "chilling effect" for this. That term has a specific legal connotation and generally indicates a fear of unfavorable treatment by the government for doing/saying something otherwise totally permissible. This situation involves a private company that is no longer serving data from a domain found to be in violation of the law. It does not meet the same definition.
gsich 9y ago
The main problem why DDoS work is because ISPs are routing traffic that can't be originating from them. If ISPs would stop this, any IP that is trying to DoS you, is really that IP, not some spoofed source address.
the8472 9y ago
The scaling problems between small senders and a potentially huge crowd of receivers can be solved with immutable, hash-addressed resources + proxies/caches and best effort multicast. The former would at least require changes at several levels in the protocol stack, which is difficult when most changes happen incrementally one level at a time. The latter I believe faces real hardware design problems in network equipment AND incentive problems on the ISP sides. So large collective action is required. Or we continue to pay cloudflare.

devit 9y ago

Yeah, it seems like it should be possible to send a packet using a "firewall rule protocol" to the DoSing IP address, and have any non-malicious routers in between enact a rule that blocks traffic in the opposite direction (obviously there needs to be either spoofing prevention, or the packet must be signed with a certificate provided by the RIR to prove ownership of the source IP address). Why not do this? Is it impossible to design it in a non-abusable way, or is there too much overhead to store and apply a possibly long list of arbitrary blocking rules?

mjevans 9y ago
Well, there would be the overhead, so more ideally you'd be submitting such requests to an out of band network (possibly forward to such a CnC network /by/ the routers along the way). The command and control network would authenticate the source request via some means and if it's authentic act accordingly. The benefit of this is that it also allows for identifying infected or otherwise abusive customers and actually being proactive about getting them cleaned up. Of course all of that degrades the 'customer' experience, and costs money. Both of which are probably why no one does this right now.
zzzcpan 9y ago
ISPs do this and have such capabilities. They don't necessarily use the same protocol, like BGP Flow Specification (RFC 5575), but they often do provide a way to push filtering rules if you need it and you are an ISP yourself.

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.)

jjrh 9y ago

Based on the article it sounds like they were mostly using the CDN part of Cloudflare's offering. > No site or service should be forced to receive //every// bit of information sent at it. They aren't, but usually public websites/services want to receive everything. Determining what's legitimate or not isn't easy because of the distributed part of DDoS.

totalZero 9y ago

It would be better to use a separate term from "chilling effect" for this. That term has a specific legal connotation and generally indicates a fear of unfavorable treatment by the government for doing/saying something otherwise totally permissible. This situation involves a private company that is no longer serving data from a domain found to be in violation of the law. It does not meet the same definition.

gsich 9y ago

The main problem why DDoS work is because ISPs are routing traffic that can't be originating from them. If ISPs would stop this, any IP that is trying to DoS you, is really that IP, not some spoofed source address.

the8472 9y ago

The scaling problems between small senders and a potentially huge crowd of receivers can be solved with immutable, hash-addressed resources + proxies/caches and best effort multicast. The former would at least require changes at several levels in the protocol stack, which is difficult when most changes happen incrementally one level at a time. The latter I believe faces real hardware design problems in network equipment AND incentive problems on the ISP sides. So large collective action is required. Or we continue to pay cloudflare.