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

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

"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?

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

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.

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.

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?

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.

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.

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.

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.

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.

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.