DDoS: A protocol where the victim says "Don't send me traffic for N ms"?

Question

When a server senses (whether or not true) it is under DDoS attack, how about a protocol where it sends a non-spoofable message upstream to routers saying "Don't send traffic to my IP address for N ms" to cut down net clogging (the server can't handle the requests anyway). Each router passes the message upstream until time expires. The process repeats as long as the "attack" continues, N optimally adjusted each time, until the attack subsides (it always does, for some reason).

This would not save the target, since it would be deliberately taken offline. But perhaps it could be used to protect other machines on the same network from being affected by the attack.

Ok, this is an obvious idea; is it used, or why doesn't it work? Don't ask me questions; I won't know the answer.

Answer 1

Although this sounds like a nice idea in theory, I think there are a few reasons why this hasn't been implemented yet and won't be implemented. They mostly have to do with complexity and scalability:

If every router on the internet needs to keep track of requests from every host to throttle traffic, this would result into a very large database every router needs to update and check for every packet being routed. This has a huge impact on the router's performance.

A second thing to consider is that things like this only work if it's widely supported. Solutions like you proposed are complex, and before consensus can be found in the IETF to define standards on how to implement this (if it is found at all) a lot of time will have passed. After that, even more time passes before a large amount of routers on the internet have upgraded to software which has implemented such a feature. All in all, it can easily take a number of years before such an idea is converted into an implemented standard.

Another problem is trust. You'll need to provide some mechanism to make sure that the host or router claiming to request throttling is actually responsible for hosting that IP. Without this, the mechanism could actually be used as a tool for doing a DDoS attack, by spoofing requests for throttling for the target, thus stopping all traffic towards the host. Routing and trust is still a very complex combination. BGP, the dynamic routing protocol on which the internet is built, is still mostly based on trust, and more and more it's clear that there are a lot of people operating networks on the internet you simply cannot trust. Solutions like RPKI and BGPsec are still not widely deployed. Adding yet trust based another mechanism will make things only more complicated.

And last but not least: not everyone benefits from not sending packets. If packets are queued, this may be a burden on networks along the path. But even if that's not the case: many networks make money by transporting packets, and transporting less packets means earning less money. If a network has a direct relationship with the network under attack the may consider it a (possibly paid) service, if not, they might be reducing their income by throttling. Of course, plenty of networks also focus the good of the internet, but may won't, and that would mean that the idea won't work that well.

Answer 2

ICMP already has a Code for "Communication with Destination Host is Administratively Prohibited" see this document for reference the upstream router will have to accept this and your requirements are (mostly) fulfilled.

Answer 3

There are a number of reasons why this solution is not sufficient, some already covered in replies. However, the main problem, especially with modern DoS attacks is bandwidth.

Originally, DoS attacks were primarily about sending a sufficient number of requests to a server to swamp the servers ability to process the requests. Often it was a resource issue on the server i.e. not enough CPU or memory resources. In many cases, only a single service would be impacted. For example, the web server might appear to be unresponsive because of too many requests, but other service might still work.

Modern Dos, especially DDoS type attacks are now more about flooding the network. You have so much data coming in, your firewall, router and internal network becomes flooded. Part of the reason it is so devastating is that you cannot communicate effectively with anything else. You can't send a message to an upstream router because the connection is flooded - switches, firewalls and routers have become unresponsive. Even if you know what you want to tell the upstream device/router to do, you can't get the message through.

This is why the solution often involves your upstream service provider. Either you need a separate communication channel, which could even be a telephone call, to get your provider to take some action, such as creating a BGP 'black hole' for the ip address in your network which is being targeted. This 'black hole' will send all data addressed to your internal IP address to a black hole so that the amount of traffic coming down the pipe to your network drops off and you can now send/receive other data. The problem is, if you use NAT or similar, so that you really only have 1 public address, then the black hole means your effectively off the network and the DoS has succeeded. On the other hand, if you have multiple public IP addresses, then you may be lucky and only suffer a partial loss of service.

The other problem with your suggestion is that to work, it needs to be fast and light-weight. However, it also needs to be secure otherwise you would run the risk of creating a new DoS vector. for example, if you used a fast light-weight connecitonless protocol, it might be too easy to spoof the IP address. This would allow me to send requests to your upstream router pretending to be you asking that no data be sent. So, any commands which would affect what data is sent need to be secure and verifiable - you now have a command which requires more processing power to process - multiply that by the number of machines and now you have to have more powerful routers - faster with more memory and this multiplies as you move up from your local router, to your ISP router to the segment router etc.

Answer 4

A signal you propose would have to reach an upstream router.

Your server cannot just signal the ISP "don't send me packets", because then nobody can access your service. (DoS successful)

You need to cut off the attack as close to the source as possible in order to limit the number of legitimate users blocked along with the attacker.

I can imagine a scenario where the datacenter operator uses human intervention or scripts to determine which routers to signal.

I'm going to focus on Bandwidth Exhaustion DDoS attacks for a moment. These can probably only be solved by blocking the attack upstream.

Unfortunately it is common for the source address to be Spoofed. So you cannot use traceroute ...

For this to work, every packet would have to have a traceroute of its own. This is quite an overhead and would have implementation barriers.

_{I might edit this later when I get more time.}