DDoS protection for an ISP
How an ISP protects subscribers from DDoS: why blackholing is a defeat, what CGNAT breaks and where the traffic filtering belongs.
Last updated:
For an ISP a DDoS attack looks different than it does for the owner of a single service. The target may be one subscriber, but the whole customer base feels the effect, because the attack traffic has to cross the shared uplink either way. Protection therefore comes down to one question: where in the network do you drop that traffic so it does no damage on the way.
Why a blackhole is a defeat rather than a defence
The simplest response is RTBH, asking your upstream to drop the attacked address into a blackhole. The traffic stops arriving and the link clears, but the attacked subscriber is offline, which is exactly what the attacker set out to achieve. From the customer's point of view there is no difference between a successful attack and a successful defence in this model. Blackholing makes sense as a last resort, when the alternative is losing the whole network, but not as a product sold as protection.
BGP FlowSpec gives more precision, since it distributes rules matched on address, port, protocol or packet length. It is still coarse and still requires somebody to write a rule for the specific vector. Against an attack that changes its characteristics mid-flight, writing rules is chasing the target.
What CGNAT breaks
If you run CGNAT, hundreds of subscribers sit behind one public address. An attack aimed at that address is an outage for all of them at once, and a blackhole on it produces the same result. On top of that come exhausted translation tables: a flood of new sessions eats entries and port pools, so the service degrades for subscribers whose traffic has nothing to do with the attack. With CGNAT the filtering has to happen in front of the NAT device, not behind it.
The layers an operator actually fights on
| Vector | What it loads | Where to drop it |
|---|---|---|
| UDP amplification and reflection | Uplink bandwidth | Provider network edge, above your port |
| SYN floods and pps floods | State tables, device CPU | Ahead of the firewall and NAT, with SYN proxy |
| Carpet bombing | The uplink, while per-IP alarms stay quiet | Prefix-wide filtering with no per-address thresholds |
| Application-layer attacks (L7) | The application and the database | L7 filtering, caching and limits at the service |
Where the filtering belongs
There is one rule: the filter has to sit above the bottleneck. A device in your own facility protects what is behind it only while its link has room. Once a flood fills the uplink, the equipment behind it has nothing left to defend, however good it is. That is why mitigation runs at the upstream provider's network edge, where there is still capacity to absorb the attack traffic.
In practice that means protected traffic runs through the protection provider's network. It is worth checking where exactly it takes it: whether filtering happens in-country and inside the same network that carries the traffic, or whether the traffic is handed to a third party and taken abroad. The difference shows in latency, in what troubleshooting looks like during an incident, and in who gets to look at your subscribers' data.
What to demand from a protection provider
- Stateful filtering rather than only rules matched to known vectors, because those are always missing for the newest attack.
- A response with no detection and diversion stage, or clear numbers on how long on-demand protection takes to engage.
- Policies set per prefix and per service, so DNS resolvers, game servers and VPNs do not fall victim to their own protection.
- Keeping the attacked address reachable instead of dropping it into a blackhole.
- Handling carpet bombing without thresholds counted per IP address.
- The option to connect where you already are: a cross-connect, a VLAN at an internet exchange or a GRE tunnel.
- NOC support available during the incident, not only in office hours.
Frequently asked questions
As a small operator, do I even need DDoS protection?
Network size does not protect you from an attack, and a smaller uplink fills up faster. For an operator with a few gigabits of capacity, an attack that a large player would barely notice means a congested link and a call from every subscriber. The practical question is not whether but in which model: permanent protection for the whole prefix, or protection engaged on demand for selected ranges.
Does DDoS protection require changing transit providers?
The simplest arrangement is protection together with transit, because then what is filtered is traffic that already runs through that provider. Mixed setups are possible too, where only part of the traffic or only selected prefixes run through the protection provider's network. In that scenario it is worth agreeing up front what the return path looks like and what happens if the tunnel fails.