DOTS: DDoS Open Threat Signaling

Every hybrid DDoS design contains a moment where one party has to tell another that an attack is happening and ask for something to be done about it. For most of the history of the field that moment was a phone call, a support ticket or a proprietary API, and changing provider meant rebuilding it.

DOTS is the standards-based answer to that moment. The architecture document sets out the roles — a client under attack, a server able to mitigate, and optionally a gateway between them RFC 8811 — and two channels carry the work.

The two channels

Appliance	When it is used	What it carries	Design constraint
Signal channel	During an attack	Mitigation requests, status, and lifetime	Must work when the network is congested
Data channel	In peacetime	Aliases and filtering rules, set up in advance	Reliable transport; not usable mid-attack
Call Home	During an attack, reversed direction	The mitigator reaching a client it could not otherwise reach	Needed where the client is behind NAT

The split between the two channels is the design insight: configuration that can wait is kept off the path that has to work under fire.

The signal channel RFC 9132 is the part that matters during an incident. A client asks for mitigation for a set of prefixes, receives status back, and the request carries a lifetime so that it expires rather than persisting silently. Its design constraint is unusual and worth appreciating: it has to work over a path that is, by definition, congested — so it is deliberately compact and tolerant of loss rather than optimised for richness.

The data channel RFC 8783 does the work that can be done in advance: defining aliases for groups of resources, and installing filtering rules that the mitigator can apply. Doing this in peacetime means the mid-attack request can be short.

Call Home RFC 9066 reverses the initiation direction so a mitigator can reach a client that sits behind NAT — a case the base model does not cover and that is common in practice.

What it works for

Making the mitigation request itself portable. If both ends implement DOTS, an operator can change upstream mitigator without rewriting their side of the integration, and can plausibly signal to more than one.

It is also a good fit for automation, because a signalled request is machine-issued in a way a support ticket is not. A detection system that can raise a mitigation request without a human in the loop turns time-to-mitigate from a staffing question into a systems question.

What it does not settle

Whether anyone you buy from implements it. This is the honest caveat and it belongs at the front rather than in a footnote. The specifications are complete; adoption across commercial providers and equipment is uneven. Verify with your provider before a design depends on it.

What the mitigator actually does. DOTS carries the request, not the mitigation. Two providers honouring the same signal can respond with entirely different capability, latency and side effects.

Whether the request is trusted. Mutual authentication between client and server is part of the model, and the operational question — who at your organisation may issue a request, and under what authorisation — is yours to answer regardless of the protocol.

Operational risk

Silence is the failure mode to plan for. A signalled request that is never answered is harder to notice than a phone call that goes unanswered, precisely because it is automated. The runbook needs a timeout and a fallback, and the fallback is usually RTBH.

Lifetime handling. Requests expire by design. A mitigation that quietly lapses mid-incident because nobody refreshed it looks exactly like a second attack wave.

The channel shares the fate of the network. It is built for congested conditions, not for a severed path. If the circuit is entirely saturated, out-of-band access matters more than protocol design.

False-positive risk

Not a property of the protocol itself — DOTS carries whatever your detection decided. The risk it introduces is that automation makes a wrong decision faster and more often than a human would have. A detection threshold that produces one unnecessary phone call per quarter can produce one unnecessary diversion per day once it is wired to a signalling client.

Which is an argument for automating the request and keeping a human in the loop on the threshold, rather than the other way round.

How to evaluate provider support

1. Do you implement DOTS, and which RFCs — signal channel, data channel, Call Home?
2. Which clients or equipment have you interoperated with?
3. What authentication do you require, and how are credentials rotated?
4. What is the measured time from signal to mitigation active?
5. What status do we receive back, and can we retrieve it after the fact for reporting?
6. What happens if we signal and you decline?

The last question is the one most worth asking, because the answer tells you what your fallback has to cover.

Sources