A New Way to Deal with DDoS
DDoS is a Threat to Large and Small Operators Alike
Most large scale providers manage Distributed Denial of Service (DDoS) attacks by spreading the attack over as many servers as possible, and simply “eating” the traffic. This traffic spreading routine is normally accomplished using Border Gateway Protocol (BGP) communities and selective advertisement of reachable destinations, combined with the use of anycast to regionalize and manage load sharing on inbound network paths. But what about the smaller operator, who may only have two or three entry points, and does not have a large number of servers, or a large aggregate edge bandwidth, to react to DDoS attacks?
One way of solving this problem is to contract with a provider, whether a transit provider (such as your upstream) or a specialized provider (a cloud based DDoS protection service) to handle the DDoS on their servers, which tend to be sized to handle even the largest DDoS attacks. The figure below illustrates one common way for this kind of cloud based DDoS protection service to operate.
In this illustration, AS65000 is the network under attack, and the attack is originating from AS65005. Normally the traffic flow follows the dot/dash red paths through the internetwork, from AS65005 to AS65004, then to AS65001 and AS65002, then finally to AS65000. With a DDoS mitigation service in place, however, the traffic will be redirected through AS65003 for scrubbing along the dashed blue path. AS65003, in this case, would advertise AS6500’s route, so every AS in the internetwork would believe the destination is actually in AS65003. This means the attack traffic, sourced from AS6505, would flow through AS65004 to AS65003.
Within the AS65003 network, which has enough bandwidth to support the entire flow (in theory!), the traffic will be scrubbed, and the “good” traffic will be tunneled across the internetwork to the actual destination in AS65000. This traffic flow is shown by the dashed lines in the diagram.
This method of DDoS mitigation is obviously quite complicated; AS65003 must either always advertise the destinations in AS65000, or it must advertise these destination dynamically. The DDoS cannot scale if it must always advertise every destination of every customer, but the time required for BGP to converge in the case of dynamic advertisement can leave a window open during which a lot of damage can be done by the DDoS attack. Further, each DDoS mitigation provider has developed a separate Application Programming Interface (API) to trigger the redirection process, and the redirection can only be done through changing the destination of the route in the routing system.
How could this system be improved? There are several obvious answers, but two stand out. Firsts, some form of common signaling mechanism could be designed and deployed so every provider—transit, edge, and security—could use the same signaling mechanism so a single operator who is under attack can more easily coordinate mitigation efforts among various providers. Second, some form of redirection could be provided further up the path, perhaps at AS65004, so modifying routes is either simpler or not needed at all.
The DDoS Open Threats Signaling (DOTS) working group in the Internet Engineering Task Force (IETF) is working on just such a system. The system is illustrated below.
This figure shows a very basic DOTS configuration. When the client detects a DDoS attack, it sends a request for mitigation to a server. This request is carried over the DOTS signal channel, and is a YANG formatted description of the kind of DDoS, and a request for action on the part of one or more mitigators. The server, in turn, sends a request for mitigation to one or more mitigators. The server would normally be run by a provider of some sort, either a transit or edge provider who has contracted with a mitigation service, or a mitigation service the end user has contracted with directly. The mitigators are either run by the DDoS protection service, or by transit or edge providers; again, there would be some contract in place to allow the server to connect to, and use the resources of, the mitigator. The illustration below shows a more complex configuration.
Here the user has contracted with an edge provider, who has, in turn, contracted with a DDoS protection service. The client sends a request for mitigation over the DOTS sign channel to a local server. The local server is actually a back-to-back server and client; it performs any necessary modifications on the request, and sends it to another agent, in this case just a server, which then request action by one or more mitigators.
The DOTS specifications actually contain two channels, a signal channel and a data channel, much like the File Transfer Protocol (FTP). The data channel is used to carry snippets of the attacking flow and more complex instruction sets. Each channel has its own set of requirements. Both channels are required to be carried over a secure transport, such as TLS, to prevent the use of the DOTS mechanisms as another form of attack, and to prevent any confidential information from being released into the public Internet.
To learn more about ECI's security solutions for service providers of all size, click here.
Topics: Cyber Security