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.

  • 3
    This sorta happens already in TCP, doesn't it? Commented Dec 7, 2016 at 20:17
  • DDoS scrubbers (CloudFlare, Prolexic, etc.) are a better solution as instead of bluntly saying "don't send me anything" they let you say "send me legitimate traffic only"
    – paj28
    Commented Dec 8, 2016 at 20:38
  • Is it so easy for upstream routers to recognize legitimate traffic?
    – vonlost
    Commented Dec 9, 2016 at 4:16
  • Routers usually just push packets in the right direction. Anti DDoS appliances filter traffic, and they can distinguish some common attack types (e.g. NTP floods) and traffic anomalies (more TCP SYNs) and filter based on reaching thresholds for those.
    – Teun Vink
    Commented Dec 9, 2016 at 5:05
  • 1
    There used to be a thing called ICMP Source Quench, check out why I said used.
    – JZeolla
    Commented Dec 12, 2016 at 2:16

4 Answers 4


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.

  • "this would result into a very large database" So are there many constant DDoS attacks we don't hear about? I thought they were rare, so no large database. "Solutions like you proposed are complex" but really? One message that goes out that expires in a few ms, requiring one test while active? I did say "non-spoofable" but if not possible and already solved, then okay.
    – vonlost
    Commented Dec 9, 2016 at 0:49
  • Yes, attacks happen all the time, in all different sizes and shapes. Not every DDoS reaches the mainstream news, because the impact isn't that obvious to the public. And the database is also large due to the large number of IPv4 and IPv6 addresses you would need to be able to store. Adjusting protocols is always complex, if you don't believe me, read up on some of the IETF mailinglist to see how much discussion and time implementation of changes on existing standards takes.
    – Teun Vink
    Commented Dec 9, 2016 at 5:03

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.

  • Cool, except for the automatic expiration after N ms. Is this routinely exploited during an attack?
    – vonlost
    Commented Dec 9, 2016 at 1:11

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.

  • "There are a number of reasons why this solution is not sufficient" but it's not intended to be sufficient (didn't I say that?), but rather only to lighten the local network load during attack. Yes, a separate thread is needed to send the message upstream (can't be done?). I wrote "non-spoofable" but if the experts find it impossible to construct a non-spoofable message, so be it (I thought things like PGP can do it).
    – vonlost
    Commented Dec 9, 2016 at 0:39
  • Just running a separate thread to send the message won't work because the network, not just the server, is choked with data. Using things like PGP/GPG at a network layer is not possible due to the latency it would create and the amount of overhead. Network equipment needs to be extremely lean to ensure it does not impact traffic throughput. This becomes even more critical in DoS situations where it is already dealing with large numbers of data packets. Critical point is you cannot do anything from your local network as it is already swamped - can't get data out.
    – Tim X
    Commented Dec 9, 2016 at 7:52
  • Long before the network is choked, the server senses it's under attack, sends the message. The network has zero burden until the message arrives, and the message prevents the network from becoming choked. If preventing spoofing is the overhead problem, so be it.
    – vonlost
    Commented Dec 9, 2016 at 21:31
  • 1
    The assumption there is zero burden on the network is false. DDoS is about flooding your ISP connection, then your router and then your local network. By the time your server is aware, it is too late. DDoS attacks often target other devices - laptops, IoT devices, desktops, not just servers. The target IP is incidental. This is why you cannot just stop a DDoS by turning the target off. Your proposal adds more processing to the key network components, potentially making the situation worse, making them easier to overload. Overhead is even higher if done securely due to extra checking needed.
    – Tim X
    Commented Dec 10, 2016 at 1:59
  • "The assumption there is zero burden on the network is false." I wasn't clear. The proposal adds zero burden to the network until the victim sends the first message to its router to stop sending traffic to the victim; the traffic burden on the network is immediately reduced, not increased. The goal is not to stop DDoS attackers, but rather to stop routers from forwarding their attacks. One simple lightweight message immediately prevents traffic from all attackers from being forwarded.
    – vonlost
    Commented Dec 10, 2016 at 7:43

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.

  • "because then nobody can access your service" but that's the goal (as I stated), for a few ms, until renewed if the server is still overwhelmed and can't do any valuable work anyway. As I said, this proposal has nothing to do with stopping a DDoS attack, but rather mitigating damage during an attack. E.g., when the victim has room for only one more request in its queue, it sends the message, requests stop arriving, the queue is emptied, time expires, requests start arriving again. Meanwhile the sending local network is not flooded, so neighbors can get work done.
    – vonlost
    Commented Dec 9, 2016 at 1:06
  • This does presume that experts know how to send a non-spoofable message, and that a large database of servers currently under attack is not needed (just limit the number of entries to keep track of to a small number, discarding additional requests).
    – vonlost
    Commented Dec 9, 2016 at 1:07
  • "but that's the goal" Interesting. Yes the idea you propose would allow "neighbors can get work done" and be easier to implement than upstream signals. However, your idea is only helpful then for Bandwidth Exhaustion attacks (since others can already be blocked by managed router) when there are other important services on the same network that are equally important. (not so for certain large-scale DDoS attacks we've seen. i.e. if Dyn's primary service is DNS, then there probably wouldn't be 'neighbors' you refer to) Commented Dec 13, 2016 at 14:43
  • "This does presume that experts know how to send a non-spoofable message, and that a large database of servers currently under attack is not needed" I agree, both your idea and my suggestion both require this. In my solution, the ability to DoS the enforcing routers upstream is greater (over-filling the databases, causing old entries to drop off), but then the datacenter operator should be able to just block the attack one step closer to home. (assuming that enforcing router has more free space in its list) Anyway, huge implementation hurdles in my solution. :-) Commented Dec 13, 2016 at 14:46

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .