A monitoring graph that never crosses its trigger line is the most common evidence of ISP DDoS protection limits at work. The circuit is saturated, the service desk queue is filling, and the carrier portal still shows green, because the flood arrived at around 1.4 Gbps against a 1 Gbps tail and never breached a detection profile written for attacks an order of magnitude larger. Nothing failed. The protection simply did what it was configured to do.
If your connectivity contract includes a line reading “DDoS protection”, the useful question is not whether you have it. It is what numbers sit underneath it. Detection thresholds, allocated clean bandwidth, protected prefix counts, mitigation event allowances and the carrier’s right to null route your address are all contractual, and they decide whether carrier mitigation rescues your service or sidelines it. This piece reads those limits the way you would read a contract, then maps each one to the three surfaces worth assessing separately: network and transport, the application layer, and authoritative DNS.
What Carrier DDoS Protection Is Actually Built To Do
Most carrier mitigation rests on flow-based detection. Edge routers export NetFlow or sFlow records, sampled at roughly one packet in a few thousand, into a detection platform that compares current traffic against a learned baseline for your circuit. Cross the threshold and the platform raises an alert; depending on the service tier, traffic is then diverted to an upstream scrubbing centre and clean traffic handed back over a GRE tunnel, a cross-connect or a re-advertised route.
That design is genuinely good at one thing: volumetric floods aimed at your circuit. Reflection and amplification attacks are precisely why carrier-level cover exists. The March 2013 attack on Spamhaus, reported by CloudFlare at the time at around 300 Gbps of DNS reflection, and the February 2018 memcached reflection attack on GitHub, which GitHub put at 1.35 Tbps in its own incident write-up, are the shape of traffic no customer-premises appliance will absorb. Upstream is the only sensible place to deal with it.
What that design is not built to do is protect your service. An ISP’s mitigation platform exists first to keep the backbone healthy and to stop one customer’s attack degrading the others sharing that edge router. Thresholds, automation and escalation paths are tuned to that goal. The practical consequence is worth stating plainly: carrier cover is circuit insurance, not service insurance. Your pipe stays usable. Whether your application stays usable is a separate question, and it is answered at layer 7 and at DNS.
The Caps Buried in the Contract
Detection thresholds in Mbps, Gbps and packets per second
Template detection profiles are convenient for the carrier and dangerous for the customer with a small tail. An attack has to be large enough to trip the trigger before anything happens, and a default profile set in gigabits per second will happily ignore an attack that has already filled a 1 Gbps or 10 Gbps access circuit. Packet-rate thresholds matter just as much as bandwidth ones, because a high packets-per-second flood of small packets can exhaust router or firewall forwarding capacity long before the bit rate looks remarkable. Ask what your thresholds are in both units, ask whether they are per-circuit or per-prefix, and ask who can tune them down.
Allocated clean-pipe capacity versus the headline figure
Carriers advertise aggregate scrubbing capacity in terabits per second. Treat that claim the way you would treat any scrubbing vendor’s Tbps number: it describes the backbone during a quiet hour, not your handback. The figures that bind you are the clean bandwidth allocated to your service, the capacity of the scrubbing centre serving your region, and the size of the return path. A 10 Gbps handback is a 10 Gbps ceiling no matter what the network total says, and if the nearest scrubbing centre to your overseas office is three countries away, the latency penalty during diversion is yours too.
Protected prefixes and the /24 problem
BGP-based diversion works at prefix granularity, and the global routing table’s practical floor for an advertised prefix is a /24. If you hold your own address space and announce a /24 or larger, diversion is straightforward. If your public-facing service lives on one or two IP addresses inside the provider’s own range, the carrier cannot divert your addresses without diverting its other customers in that block, so the realistic options narrow to on-net scrubbing (if offered) or a null route. Contracts often cap the number of protected prefixes or protected IPs included in the base fee, with additional assets priced per unit. Count your public-facing addresses before signing, not after.
Mitigation event allowances and per-incident charges
“Included”rarely means unlimited. Common structures cap the number of mitigation events per month or per year, cap mitigation hours, or charge per incident beyond an allowance. Two details decide whether an allowance is generous: how an “event”is defined, and whether repeated attacks within a window count once or many times. Attackers who probe in short bursts across a weekend can burn an annual allowance in one sitting, which is exactly when you least want a commercial conversation about overage.
Where ISP DDoS Protection Limits Bite: Layer 7 And Authoritative DNS
Flow-based detection sees addresses, ports, protocols and volumes. An encrypted HTTPS request flood is none of those things in any suspicious combination. Twenty thousand requests per second against a search endpoint or a login page can sit comfortably inside a normal-looking bandwidth profile while the application tier collapses behind it, because each request is cheap to send and expensive to serve: a database query, a session lookup, a password hash. The carrier graph stays flat. The service is down. Application-layer defence needs request-level inspection, rate controls and bot management, which is a different product from clean pipes, and in most carrier contracts it is out of scope.
Authoritative DNS is the layer most often left unmanaged, usually because both parties assume the other owns it. If your zones are served by a registrar’s free name servers or by a single pair of self-hosted resolvers outside the carrier’s protected prefixes, carrier mitigation does nothing for them. Take the name resolution away and every other layer of protection is decorative. DNS providers have been targeted directly for years; the attacks on EveryDNS during the 2010 WikiLeaks episode, covered in our earlier report on that incident, are a reminder that your zone’s availability depends on someone else’s capacity.
Three questions will tell you which of the three surfaces your contract actually touches. Does mitigation apply to all public-facing addresses or only to those on this carrier’s circuits? Does the service inspect application-layer requests, or only traffic volumes and protocol anomalies? And who serves your authoritative DNS, on what infrastructure, with what protection of its own? If the honest answer to the second and third is “nobody here”, you have found your gap.
When The ISP’s Fix Is Your Outage: Blackholing Explained
Remotely triggered black hole filtering is the oldest and cheapest tool in the carrier kit. The mechanism is documented in RFC 5635, building on the approach set out in RFC 3882: the targeted address is tagged with a community that causes upstream routers to discard everything addressed to it. Attack traffic stops at the network edge, well before it reaches your circuit. So does your customers’ traffic, your API calls and your monitoring.
That is why the escalation clause matters more than the headline capacity number. A null route can be recorded, accurately, as a successful mitigation. The backbone was protected, the neighbouring customers were unaffected, and the incident report will say so, while your service was unreachable for the entire window. Where blackholing is the standard first action rather than the last resort, your cover is a clean way to lose.
BGP Flowspec, originally specified in RFC 5575 and since updated by RFC 8955, is the more surgical alternative: filters matched on source, destination, port and protocol rather than a blanket drop of a destination address. Support varies by carrier and by peering relationship, and many providers will accept Flowspec rules only from a limited set of customers. Ask whether it is available on your service, and if not, what sits between “monitor”and “null route”.
Then read the clause itself. When may the carrier blackhole unilaterally? For how long, and on what review cycle? Who inside your organisation is notified, through which channel, at what hour? And who authorises withdrawal of the null route once the attack subsides, because a route left in place overnight is a self-inflicted outage.
Time To Mitigate, Diversion And The On-Demand Penalty
The SLA number is rarely the real clock. Flow sampling intervals add time before the attack is even visible; detection logic waits for confirmation to avoid false positives; on-demand services then need authorisation, whether automated or from a human in a network operations centre; and BGP convergence takes its own minutes once diversion is announced. Add those together and a short, sharp attack can begin and end before clean traffic ever arrives.
Always-on and on-demand are not simply price tiers. Diversion changes your routing, and changed routing breaks things that assumed symmetry: GRE or cross-connect return paths need to exist and be tested, asymmetric paths can confuse stateful firewalls and load balancers, and long-lived sessions can drop at the moment of diversion. Stateful kit loses state. That is a design decision to make in advance, not during an incident.
How much those minutes cost depends entirely on what the service does. A brochure site absorbs fifteen minutes of unavailability with a shrug. A ticketing on-sale, a payment API or a betting platform during a live event fails commercially in the first ninety seconds. Verify rather than accept: ask for mitigation time measured from first packet to clean handback rather than from alert acknowledgement, ask for anonymised timings from recent incidents on the same platform and region, and schedule a diversion test with the carrier so the return path is proven while nobody is attacking you.
The Single-Path Trap For Multi-Site And Multi-Country Estates
Carrier protection follows that carrier’s circuits. Everything else is someone else’s problem, and most estates now have a lot of “everything else”.
A worked example that fits a surprising number of mid-sized organisations: production servers in colocation behind one transit provider, who offers mitigation on that circuit; a public cloud front end whose provider offers its own network-layer protection, usually at an extra tier for anything application-aware; a customer portal delivered as SaaS, where the vendor’s contract governs availability; and authoritative DNS at the domain registrar, chosen years ago by someone who has since left. Four different parties, four different definitions of mitigation, and one surface with nobody named against it.
Shared hosting and colocation tenants have a further wrinkle: the upstream decision maker is the provider, not you. If a neighbouring tenant is attacked and the provider null routes a shared range, you are in the crossfire with no vote. Our colocation DDoS protection checklist covers the questions worth asking a data centre operator about exactly that.
The mapping exercise is dull and takes an afternoon. List every public-facing IP address, hostname and DNS zone. Against each, name the party who mitigates an attack on it, the mechanism they use, and the contractual trigger. Mark the blanks. The blanks are your buying list.
Topping Up Without Paying Twice
The expensive procurement mistake is buying a second full mitigation stack when the real gap is one surface. If the carrier handles volumetric floods competently on your main circuits, you do not need another clean-pipe provider; you need the piece that is missing. That is usually one of four things: a cloud scrubbing layer for assets the carrier cannot divert, a WAF or bot-management layer for application and API paths, anycast authoritative DNS with its own capacity, or simply a better-specified tier from the carrier you already pay. Our explainer on how cloud scrubbing services actually work is a reasonable starting point for the first of those, and the overview of what UK ISP protection covers and does not sets the wider context for this one.
UK managed DDoS pricing is typically built from the same components, which makes honest comparison possible once you insist on seeing them separately: contract commitment and term; number of protected assets, prefixes or hostnames; allocated clean bandwidth; mitigation event or hour allowances with the overage rate; onboarding and professional services; and the cost of testing and of emergency onboarding mid-attack. Two quotes that look wildly different often differ on only two of those lines.
Build the case from downtime cost per hour, not from attack headlines. Revenue per trading hour, staff hours lost, contractual service credits owed to your own customers and the regulatory reporting burden give you a defensible number; a terabit figure from someone else’s incident does not. Our board-ready DDoS protection business case model works through that calculation, and the UK National Cyber Security Centre’s denial of service guidance collection is a sensible reference to cite alongside it when finance asks who says so.
Before signature, put five questions to the carrier and to any additional provider: what are my detection thresholds in Mbps and packets per second; what clean bandwidth and which scrubbing location are allocated to me; under what circumstances will you blackhole my address, for how long, and who withdraws it; what is the measured time from first packet to clean handback on this platform; and which of network, application and DNS does this contract cover. Get the answers in writing. The ISP DDoS protection limits that catch organisations out are almost never secret; they are simply never read until the graph stays flat and the service does not.
Frequently Asked Questions
What are the usual ISP DDoS protection limits on attack size?
Two numbers matter and they are different: the detection threshold that must be crossed before anything happens, and the clean bandwidth allocated to your handback. Advertised network-wide scrubbing capacity in terabits per second describes the carrier’s backbone, not your circuit. Ask for your per-service allocation, the scrubbing location serving your region, and the thresholds in both bandwidth and packets per second.
Will my ISP blackhole my IP address during a DDoS attack?
Many carriers reserve the right to, and some use remotely triggered black hole filtering as a standard action rather than a last resort. The mechanism, described in RFC 5635, discards all traffic to the targeted address, so the attack stops and so does legitimate access. Check the contract for when the carrier may null route unilaterally, for how long, who is notified and who authorises withdrawal.
Does carrier DDoS protection stop application layer attacks?
Usually not. Flow-based detection reads volumes and protocol patterns, and an encrypted HTTPS request flood against a login, search or API endpoint can stay well inside a normal bandwidth profile while exhausting the application tier. Stopping that needs request-level inspection, rate limiting and bot management, which is a separate product from clean pipes.
Who protects my authoritative DNS if my ISP does not?
Whoever serves your zones, which is often a registrar whose free name servers were never chosen for resilience. Options are an anycast managed DNS provider with published capacity, a secondary provider for diversity, or hosting your own authoritative servers inside protected prefixes. Confirm in writing which party mitigates attacks on your name servers, because this is the surface both sides most often assume the other owns.
Do I still need managed DDoS protection if my ISP includes it?
It depends on which gaps the mapping exercise reveals. If carrier cover handles volumetric attacks on your main circuits and your exposure is application endpoints or DNS, buy that layer rather than a second full stack. Price the addition against downtime cost per hour and the surfaces genuinely left uncovered, not against the largest attack in the news.