A head of infrastructure signs a 1Gbps dedicated internet access (DIA) circuit for a distribution business in the Midlands, sees the line “DDoS protection included”in the order form, and files the question as answered. Nine months later the website goes dark for three hours during a promotion. The provider’s incident note says the attack was “mitigated at the network edge”. Both statements are true. The site was still offline the whole time.

ISP DDoS protection in the UK is genuinely useful, and for one specific failure mode it is the only thing that works. But what most UK connectivity contracts actually bundle is detection plus a null route, and the gap between that and what buyers assume they bought is where the outage lives. This piece decodes the language, names the three surfaces a circuit can never defend, and sets out the questions to ask before the contract is signed rather than during the incident.

What ISP DDoS protection in the UK actually includes

Strip away the datasheet and the standard anatomy is consistent across most UK providers: routers at the provider edge export sampled flow data (NetFlow, sFlow or IPFIX), a detection platform compares that against a baseline or a fixed threshold, an alert fires, and then something happens to your traffic. The first three steps are commodity engineering and broadly reliable. The fourth step is the whole product.

That fourth step is usually one of three things. Inline on-net scrubbing appliances sitting in the provider’s own network, filtering traffic and passing clean packets through. Diversion, where a BGP announcement pulls your traffic to a scrubbing centre (the provider’s or a partner’s) and returns the clean portion over a tunnel or direct connection. Or a null route.

Pricing follows the same split. The no-cost tier bundled with the circuit is nearly always detection plus blackhole, sometimes with a monthly allowance of mitigation events. Always-on scrubbing with clean-traffic return is a chargeable add-on, typically priced by protected bandwidth, number of protected IPs or prefixes, and whether mitigation is on-demand or permanent. The uplift usually triggers on one of those three variables, so ask which one before someone quotes you a figure.

None of that scepticism changes the one thing only a connectivity or transit provider can do. Take a 1Gbps DIA circuit hit by a 40Gbps reflection flood. The firewall, the load balancer, the application gateway: none of them matter, because the tail circuit is already saturated upstream of every box you own. Nothing on your premises can empty a full pipe. Mitigation has to happen at the ISP, at its transit provider, or at a cloud scrubbing centre further out. That is the real strength of circuit-level protection, and it is worth paying for.

Blackholing is not mitigation: the clause that decides your outage

Remote-triggered black hole (RTBH) filtering is a legitimate, well-documented operational technique. It is described in RFC 5635, and the well-known BGP community used to signal it is defined in RFC 7999 as 65535:666. The mechanism works by announcing the victim address with a community that tells upstream routers to discard all traffic for it, as close to the network edge as possible.

Read that again. All traffic. Not attack traffic.

RTBH protects the ISP’s core, its peering links and every other customer sharing that infrastructure. It is a good decision for the network operator and a terrible outcome for the single customer being attacked, who is now comprehensively offline until the hold-down timer expires. The attacker has achieved exactly their objective, faster and more completely than the flood alone would have managed.

Two questions decide how bad it gets. First, granularity: is the discard route applied to a single /32 (or /128), or to the whole prefix? If your ISP nulls a /24 that also carries your mail server, your VPN concentrator and the API your customers integrate against, one attack on a marketing page takes down services that were never targeted. Second, duration: is there a stated hold-down period, who can lift it, and does lifting it require a ticket during working hours?

Contract language rarely makes this obvious. “Mitigate”, “discard”, “filter”, “suppress”and “protect the network”can all describe the same null route. Get it defined in writing. The sentence you want somewhere in the service description reads roughly: attack traffic is filtered at a scrubbing platform and legitimate traffic is returned to the circuit, with a stated time-to-mitigate and blackholing used only as a last resort with notification. If the provider will not write that down, assume the default is a null route and price your risk accordingly.

Three surfaces your circuit cannot defend

Circuit-level detection is tuned for bits per second and packets per second, because those are the metrics that threaten the provider’s network. Attackers know this.

The application layer. A few hundred Mbps of valid-looking, TLS-terminated HTTPS requests on a 1Gbps circuit will exhaust connection pools, PHP workers and database sessions while sitting comfortably below every volumetric threshold. Sampled flow data sees normal-ish traffic volumes to port 443. The detector stays quiet. The application falls over. That is the argument for treating a proxy or app-layer service as a companion to ISP protection rather than a competitor to it, and the specific gaps are worth reading up on in more detail in our breakdown of where application layer DDoS protection falls short.

Authoritative DNS. This is the surface most often left entirely unmanaged, and it almost never sits behind the circuit being protected. Delegation usually lives with a registrar, a hosting control panel or an inherited nameserver pair from a previous web agency. A random-subdomain (water torture) or NXDOMAIN flood against those nameservers is somebody else’s problem, and your ISP’s scrubbing platform never sees a single query. DNS providers do get attacked, as the flooding of Point DNS demonstrated, and when the nameservers go the whole estate goes with them regardless of how healthy the circuit is. The fix is splitting delegation across two independent anycast operators, and it has to be proved with a real delegation change and a tested failover, not assumed from a feature list.

Anything not behind that circuit. Cloud workloads, SaaS integrations, branch VPN concentrators on different lines, third-party payment and booking layers, the customer portal someone put on a separate hosting account. ISP protection is scoped to traffic crossing that connection. Draw the estate on a whiteboard and mark what actually transits the protected circuit. The map is usually smaller than expected.

Then there is origin IP leakage, which breaks more proxy deployments than raw attack volume does. Mail servers in the same range, stale A records for old. and dev. subdomains, staging hosts, certificate transparency logs and outbound connections from the origin all republish the circuit IP to anyone who looks. Once an attacker has it, they bypass the proxy entirely and hit the line. At that moment the ISP layer is your real perimeter, which is precisely when a blackhole-only contract turns into a multi-hour outage.

Whose network and whose scrubbing capacity are you buying?

Ask the resale question early and plainly: whose appliances, whose transit, whose scrubbing centres? There are three honest answers and they lead to different numbers.

Where the ISP runs its own on-net mitigation, capacity is bounded by that ISP’s transit and peering, not by any global figure in a brochure. A provider with 200Gbps of aggregate upstream cannot absorb a 300Gbps flood, whatever the appliance vendor’s specification sheet claims. Where mitigation is white-labelled from a cloud platform, you get far larger headline capacity, a diversion step, a GRE or direct-connect return path and added latency, plus a support chain where your incident ticket passes through two companies. Where the ISP relies on its upstream transit provider’s platform, mitigation policy is being set by an organisation you have no contract with.

Useful follow-ups: which scrubbing centre locations serve UK traffic, whether they peer at LINX or LONAP, how clean traffic returns and what that adds to round-trip time, and what happens when the attack exceeds the local centre’s capacity. Capacity claims deserve the same scepticism as any vendor number, and the approach to testing them is set out in our guide to judging Tbps scrubbing claims.

What “managed”has to mean before you sign

“Managed”is the most elastic word in the sector. Pressure-test it with operational questions rather than features.

• Who detects, who decides and who acts at 02:00 on a Sunday? Name the team and the escalation matrix, not a portal login. If nobody on the provider side can change policy without your written sign-off, you have bought monitoring, not management.
• Does time-to-mitigate start at detection or when you telephone the NOC? The difference is routinely the difference between four minutes and forty.
• Who tunes thresholds before a product launch, a ticket release or results day at a college? False positives during planned traffic spikes do more commercial damage at some organisations than small attacks do.
• What is the remedy when the SLA is missed, and is it a service credit against the mitigation line item or against the whole circuit?
• Can they supply a redacted post-attack report showing vectors, packet rates and mitigation timeline? You will want that document for your insurer, and for Action Fraud if you report the incident.

Request a tested change window too. Rolling a mitigation policy change for the first time during a live attack is not a plan.

ISP protection, reverse proxy or BGP scrubbing: which combination fits

These are not three competing purchases. They defend different things.

Circuit-level ISP protection handles volumetric saturation of the tail, the one problem you cannot solve yourself. A reverse proxy or CDN handles HTTP(S) floods, bot filtering, caching and TLS termination, and hides the origin if (and only if) the origin stays hidden. BGP diversion to a scrubbing provider protects whole prefixes and non-web services: game servers, SIP trunks, mail, VPN, anything a web proxy cannot front. Hosting and SaaS businesses shopping for a DDoS protected hosting provider should check which of these three the provider actually operates, because “DDoS protected”on a hosting page frequently means its upstream will blackhole the IP.

At the ISP layer, decide between always-on and on-demand. On-demand costs less and adds no steady-state latency, but diversion takes time to converge and asymmetric routing during the switch causes its own problems. Always-on removes the convergence delay and makes every packet pay the detour.

Address space is the quiet decider. A /24 allocated or transferred to you by the RIPE NCC plus your own autonomous system number means you can re-announce to a scrubbing provider in minutes and walk at renewal. Provider-assigned space ties you to whatever your current ISP is willing to do, and migration becomes a renumbering project touching firewall rules, allowlists and third-party integrations.

Build the spend case from downtime, not from the monthly line. Work out your own hourly revenue from your own figures, and do it twice: once averaged across the week, and once for a peak trading evening, which will be several times higher. On that arithmetic a four-hour null route during a promotion can cost more than a year of always-on scrubbing, before SLA credits owed to your own customers and staff time. Our breakdown of what DDoS protection actually costs in the UK covers how those quotes are structured. Procurement patterns reinforce the point: UK public bodies commonly buy mitigation as a separate service through the Digital Marketplace, and education and research sites receive it in tiers attached to Janet connectivity via Jisc. In both cases protection is attached to a connection, priced in tiers, and scoped to traffic crossing it.

If you are the ISP or hosting provider

Smaller UK ISPs, WISPs and hosts face the same questions from the other side. Protect shared infrastructure first: core and edge routers, recursive resolvers, RADIUS, mail relays and the customer-facing portal. An attack on one customer that takes out your resolvers affects everyone, and that is the outage your subscribers will remember.

Then make the customer-impacting choices deliberately. Per-customer detection thresholds rather than one network-wide number. Opt-in scrubbing as a priced tier, with blackholing reserved for traffic that exceeds what you can filter. And communicate a null route honestly: a status update saying “we have discarded traffic to this address to protect other customers, estimated hold-down 60 minutes”earns more trust than “attack mitigated”. Resellers should document whose capacity sits behind the service, the return-path design and the escalation chain, because the buyers reading this article will ask.

Frequently Asked Questions

Does ISP DDoS protection cover attacks on my website?

Partly. It covers volumetric floods that would saturate the circuit your web server sits behind, which is real and valuable protection. It will not normally stop an application-layer HTTPS request flood, because that traffic looks legitimate and stays below bits-per-second thresholds, and it does not cover attacks on your authoritative DNS or on anything hosted elsewhere.

Is DDoS protection included with UK business internet, or charged extra?

Both, depending on tier. Many UK providers include basic detection and blackhole response at no extra cost on DIA and transit services, then charge for scrubbing with clean-traffic return, usually priced on protected bandwidth, protected IP count or always-on versus on-demand. Ask which of those variables drives the quote, and confirm in writing what the free tier does when an attack starts.

What is blackholing, and why does it leave my site offline?

Blackholing, or remote-triggered black hole filtering (RFC 5635), announces your address upstream with a BGP community that tells routers to discard every packet destined for it. All traffic is dropped, legitimate requests included, so the attack stops reaching the provider’s core while your service stays unreachable. Check whether the discard applies to a single /32 or to the whole prefix, and what the hold-down period is.

Can I use my ISP’s protection alongside a CDN or reverse proxy?

Yes, and that combination is usually the right one. The proxy absorbs HTTP(S) floods and hides the origin; the ISP layer catches volumetric traffic aimed directly at the circuit when the origin IP leaks through mail records, old subdomains or certificate transparency logs. The two defend different layers, so treat them as complementary rather than choosing one.

How fast should an ISP mitigate a DDoS attack?

Providers commonly quote detection within a minute or two of flow sampling and mitigation inside a small number of minutes for automated responses, but the contractual wording matters more than the headline figure. Establish whether the clock starts at automated detection or at your phone call, what the figure is for on-demand diversion versus always-on, and what remedy applies if it is missed. The NCSC’s denial of service guidance collection is a sensible reference when drafting those requirements.

Buying ISP DDoS protection in the UK is not a mistake. Buying it believing it is a complete answer is. Find out whether you have scrubbing or a null route, whether the null route is per address or per prefix, whose capacity sits behind the promise and who is authorised to act at three in the morning. The answers are easy to get before you sign, and expensive to discover afterwards. Many UK firms still have not asked, which is one reason preparedness research keeps finding the same gaps.