Distributed denial-of-service, or DDoS, attacks can be debilitating -- particularly for smaller organizations that...
lack the resources to manage them.
Yet, the scale and scope of DDoS attacks today have reached the level where someone can easily take your ability to connect to the internet offline for many hours. That means it's imperative to have some sort of DDos attack defense.
At the same time, the internet of things is set to make things worse. A hacker can now source an attack from thousands of devices that are spread throughout the world, each of which potentially connected to a different edge provider.
When the attack does come, what are your options?
The first is to try to mitigate the attack on your edge, perhaps by installing some sort of DDoS protection system on your links toward your providers -- AS65001 and 65002 in the illustration above. The problem with this approach is your bandwidth is still being eaten by the DDoS attack; therefore, this is far too late in the game to be useful in many situations.
Another option is to call your upstream providers -- again, AS65001 and 65002 in the illustration above -- and ask them to mitigate the attack. There are many providers that offer this kind of service, so this is a viable option, but they may not be able to handle the volume of the attack.
It may also be that you have enough edge connections, so asking for service from each of your providers is expensive; think of the situation where you have a large SD-WAN-based hub-and-spoke network, with several hundred remote offices and, therefore, potentially tens of upstream providers. Further, the provider is still taking in traffic along its edges that is ultimately dropped -- a waste of bandwidth and resources.
Looking at cloud, DOTS as DDoS attack defense
You can also work out a strategy with a cloud-based DDoS provider to advertise your routes, which draws the traffic into its cloud, scrubs out the DDoS and forwards it to you -- typically over a tunnel. The problem with these sorts of DDoS attack defense services is you either must have the redirection in place permanently, which reduces the performance of your internet-facing services all the time, or you must somehow contact the provider within moments after a DDoS attack begins in order to quell the intrusion.
The DDoS Open Threat Signaling (DOTS) working group in the Internet Engineering Task Force has been working on an alternative tact: the ability to signal any -- or all -- of the above responses automatically. The DOTS approach has several components, including a client, a server and a mitigatory. The client uses DOTS signaling to ask for mitigation from a server; the server asks mitigators to actually mitigate the attack.
A device can act as both a server and a client, so a request to a single server can then spread out throughout an entire overlay network of mitigation services to stop the attack as close to the sources as possible.
For instance, in the original example, perhaps DDoS mitigation is offered by your two upstream providers, 65001 and 65002. When the DDoS attack is detected, you can use DOTS signaling to request mitigation from your two upstreams. In turn, they can mitigate some part of the DDoS locally, or they may simply act as a client to a cloud-based DDoS mitigation service with which they have a contract. They can request service from these providers, which ultimately redirects traffic as needed to provide the DDoS mitigation. This could even be combined with the upstream provider requesting mitigation toward the originating autonomous systems, across the internet -- s1-s6 in the first illustration.
A future column will look at some of the technical details of how DOTS works and its role as a DDoS attack defense mechanism.