DOTS: DDoS Open Threat Signaling

DDoS is a problem for more than the target. The attack traffic is carried by many AS along the way and nobody is interesting in assisting illegitimate traffic. Frequently the target at the final destination has a circuit overwhelmed by the volume so the mitigation must occur upstream of the target device.

As a result the detection of the DDoS attack can occur at a different point in the traffic path than where mitigation efforts need to happen to be effective. Communications between two companies and network domains need to occur to effectively both detect and mitigate an attack.

Today most of this communications occurs manually offline unless the target and scrubbing center deploy equipment from the same vendor that has developed a proprietary method to pass the detection information to the upstream scrubbing center. The market for DDoS scrubbing centers is now diverse and mature enough that standards are appropriate for this type of signaling.

Enter the IETF standards working group DOTS – DDoS Open Threat Signaling. As with other network communications standards representatives from the DDoS space both as operators and manufacturers come together to define a framework for the necessary communications. The working group home page and current draft documents are linked below.

Architecture

DOTS is a communications standard. The entities performing the communications are:

DOTS clients – that are reporting the detected DDoS issue
DOTS Servers – that receive the reports on behalf of entities that can potentially act on these reports
DOTS gateway – optional entity that can translate internal DOTS clients that only understand RFC1918 addressing into requests that communicate the appropriate public ip addresses involved as the DDoS target.

The simplest basic DOTS architecture

When the DOTS client is some server running in RFC1918 space and scope the gateway architecture looks like this.

The protocol also allows for multiple clients signaling a single upstream or a single client signaling multiple multiple servers for assistance. Or the DOTS gateway can be used to consolidate multiple clients for the upstream signaling requests to either single or multiple servers. In short the communication combinations and permutations are well covered.

The idea is that detector clients can be deployed by any vendor and at any point that makes sense to detect the malicious DDoS attack. The vendor need not have any mitigation ability at all to be a detector. They can even be completely out of the traffic path itself and operating on data streams of any sort at all.

Likewise the DOTS server can be communicating to mitigation tools that have no detection ability at all. There is no need for the mitigator to detect the DDoS attack as the signal is requesting the mitigation.

Naturally there is a significant value in having both detection and mitigation working hand in hand but the standard allows for vendors to specialize in one or the other more easily.

Use Cases

There are two primary use cases for DOTS, communications between the target and the immediate upstream provider and from the target to 3rd party mitigation services outside the initial connection to the target.

When signaling the immediate transit provider the nature of the traffic path means they will already have the malicious packets on their network. So no route diversions are needed in the overall internet table for the transit provider to mitigate the issue. The DOTS server mitigation can use /32 addressing and the built in infrastructure of the transit provider to provide mitigation service with no need for any other internet routing changes to occur.

With 3rd party DDoS Mitigation service they need to first divert the global internet table to receive the traffic before they can provide mitigation. So part of the process is to identify the /24 route that will need to be inserted into the global internet routing table for this to occur. The other major difference is that the good traffic that is then sent to the target needs a delivery path. This is typically a tunnel of some sort created between the enterprise and the DDoS service.

Signaling Standards

Communications between DOTS nodes is separated into a signal channel and data channel. This allows the clean separation of data from communications infrastructure and more ability to simply ignore messages not understood and extend messages in the future. Security of communications is paramount as well. We don’t want this channel of communications becoming a new method of DDoS attack.

Further the existing communications protocol coap is used as the foundation for the channel. This takes advantage of an existing mature communications standard that is also resilient by nature. The working group understands that when the DOTS client is under attack the channel of communications may also be impacted.

The standard also makes use of the existing standard of YANG to describe the data structure of messages passed in the system. By using a small set of required data elements and an extended set of optional ones that can be safely ignored by any DOTS element, the system becomes easily extendable and resilient for backwards compatibility.

Conclusion

The current drafts are now in the final stages of review and comment and should start to be implemented by vendors this year or early next year. I am encouraged that the framework seems to be a robust standard. It uses existing signaling mechanism where practical. It separates a basic message from detailed data that makes it easy for vendors to extend without breaking cross vendor signaling. And the structure allows for future feature extensions in a fully backward compatible way that won’t break older nodes when new features are added.

I look forward to seeing the implementation details as they emerge from the major vendors in the space.