DDoS Scrubbing: Diversion, Cleaning and Return

There is exactly one thing you cannot fix inside your own building: more traffic arriving than your circuit can carry. Scrubbing is the standard answer, and it works by moving the problem to somewhere with more room.

Traffic is pulled away from its normal path into a facility sized far beyond any single customer, the attack component is removed there, and what remains is delivered to the origin.

The three timings

Appliance	Time to mitigating	Steady-state risk	Suits
On-demand diversion	Minutes — detection, decision, routing convergence	None; nothing in the path until needed	Long attacks, cost-sensitive designs
Always-on scrubbing	Seconds — traffic is already there	The provider is permanently in the path	Short bursts, services that cannot absorb a delay
On-premises inline	Immediate, up to the circuit ceiling	The device is permanently in the path	Protocol and application-layer attacks

Compare the first column against how long your attacks actually last. If diversion takes four minutes and your attacks last three, on-demand is a decision to arrive afterwards.

The first column is the one that decides most designs and the one most often taken from a brochure rather than measured. Diversion by routing is not an instruction that takes effect; it is a routing change that converges on the network’s own schedule. Against a campaign of short bursts, an on-demand design can consistently arrive after each burst has finished.

How diversion happens

By routing. The provider announces your prefix, so traffic destined for it reaches their network instead of yours. This covers everything addressed to the prefix, which is comprehensive and coarse — you cannot divert one service and not another within the same prefix.

By DNS. You point a hostname at the provider, so only that service is diverted. Quicker to arrange, finer-grained, and bounded by cache lifetimes, which means it takes effect gradually and cannot be relied on to complete quickly.

By signal. Where both parties implement it, DOTS makes the request itself standard rather than provider-specific RFC 8811.

Most large scrubbing networks are anycast underneath RFC 4786, which is what lets them absorb volumes no single facility could — the dispersal happens before the filtering does.

The return path is the part that surprises people

Cleaned traffic has to reach your origin, and the mechanism is normally a tunnel. Three consequences follow and all three have caused outages that were blamed on the scrubbing rather than the plumbing.

MTU. A tunnel reduces the usable maximum transmission unit. Path MTU discovery and TCP MSS clamping become part of your availability design rather than a networking detail, and the symptom of getting it wrong is large transfers hanging while small ones work.

Asymmetric routing. Traffic arrives through the provider and leaves directly. Anything in the path that expects to see both directions of a session — a stateful firewall, an IPS — starts dropping legitimate traffic. This is the single most common hybrid failure.

Origin exposure. If your origin addresses are reachable directly, an attacker who learns them bypasses the scrubbing entirely. Concealing the origin is part of the design, not an optional hardening step.

What it works against

Volume, at a scale that would be absurd to build yourself. Reflection and amplification floods, large protocol floods, and multi-vector campaigns whose volumetric component would otherwise saturate your transit.

It also works as an insurance layer for attacks larger than anything you have seen, which is the honest reason most organisations buy it.

What it does not work against

Short bursts, on-demand. Covered above, and worth restating because it is the mismatch that disappoints most often.

Application-layer attacks that need your context. A scrubbing tier judges traffic with what it can see. Deciding whether a request is abusive frequently requires knowing what this service normally receives, which is history the provider does not hold unless you have arranged for them to.

Anything after the tunnel. Traffic returned to your origin is clean by the provider’s judgement. Whatever they did not classify arrives at your edge, which is why a scrubbing subscription and an on-premises tier are complements rather than alternatives.

Operational risk

Telemetry arrives on their schedule. Flow-based detection is sampled by construction RFC 7011, and what you receive back about actions taken on your behalf varies enormously between providers. A mitigation you cannot describe is a mitigation you cannot report to a regulator.

Where TLS terminates. If application-layer inspection is part of the service, the session is terminated somewhere, and that somewhere holds your keys and sees your plaintext. It is a jurisdictional question dressed as a technical one.

Diversion is not free of side effects. Latency changes, geolocation changes, and anything in your stack that assumed a stable path may behave differently while mitigation is active.

Failback. Returning to the normal path is a second routing change with its own convergence and its own opportunity to break something.

False-positive risk

Real and largely invisible to you. The provider decides what to drop, using their classification against their view of your traffic, and you learn about mistakes from customer complaints rather than from a counter. The mitigation is contractual as much as technical: agree what goodput measurement you receive, and test it during an acceptance window rather than during an incident.

How to verify

1. Measure end-to-end time to mitigating on your own routing, not a stated figure.
2. Run an attack shorter than that measured time and record what reached the origin.
3. Test the return path under load, including large transfers, and confirm MTU handling.
4. Confirm whether any stateful device sits between the tunnel endpoint and your servers.
5. Establish what telemetry you receive, in what format, and how quickly.
6. Confirm your origin addresses are not directly reachable.

Sources