How to check a host's DDoS protection claims

A plan page says "Tbps of DDoS protection, always-on, unlimited, built for game servers". Every word of it can be true, and a server on that plan can still go dark the first evening someone floods it. The terabits belong to a network that everyone on it shares. The server behind them has a port a thousand or more times smaller. And "unlimited" ends wherever the provider decides it has to protect its other customers.

None of that makes the claims lies. It makes them incomplete, and the missing parts are where outages come from. What follows takes the usual claims one at a time, says what each can and cannot mean, and then shows how to check the parts that are checkable from public routing data, without sending a single packet to anything you do not own.

Four claims, and the question each one leaves open

Most hosts describe their DDoS protection with some mix of four claims. Each is shorthand, and each shorthand drops a detail that decides whether your server stays up. The table is the short version; the sections after it explain each row.

The drawing at the top of this page puts each claim where it belongs on the path an attack takes. Capacity and always-on are about the upstream network. Unlimited is decided at the provider's edge. Game protection lives in the filter on the host. Your port sits in the middle, and no claim mentions it.

A capacity figure belongs to a network, not to your server

A figure in terabits per second measures how much traffic something can take in, and 1 Tbps is 1,000 Gbit/s. The useful questions are what that something is, and how much of it stands between an attacker and your server.

Whose network is it?

A host does not need a network of its own to sell servers. The internet's long-standing guidance on autonomous systems, RFC 1930, says a site connected to a single provider does not need an AS of its own: its addresses belong in the provider's AS.¹ Scrubbing, too, is something many internet providers offer either themselves or through a third party.² So the terabits on a host's page may be its provider's, or its provider's provider's. That is normal and not dishonest. Presenting someone else's network as your own, without saying whose it is, is a different matter, and routing data can often show which of the two you are looking at.

What is it summed over?

A network's capacity is the sum of its connections: every link to every upstream and peer, at every site. That total is the right number for the network and the wrong one for a single server. Three different numbers also wear the same unit: the capacity of the network's links, the capacity of its filtering equipment, and the largest attack it says it has handled. Ask which one you are reading, and whether it applies in the region where your server would be.

Who else shares it?

Capacity in front of a network is shared by every customer behind it. Nobody reserves terabits for one server, and that is fine. It does mean a big attack on another customer uses the same headroom as a small attack on you, and an attack on your provider reaches you even when you were not the target: CISA notes that a network loses service when its internet or cloud provider is attacked.³

What reaches your port

However large the figure, the last link to your server has a fixed speed, and that is the most it can receive. Take a round 1 Tbps and a 1 Gbit/s port: 1,000 Gbit/s ÷ 1 Gbit/s = 1,000, so the port is one thousandth of the headline. A 40 Gbit/s flood is 40 ÷ 1,000 = 4% of that headline, small enough for the network to shrug off, and 40 times what the port can carry. Unless something upstream removes it first, the attack fills the link to your server and starves out the legitimate traffic sharing it.⁴ A filter on the server itself cannot help with that, however good it is, because the loss happens in front of it; the guide to how DDoS protection works explains why.

Of 1 Gbit/s each, in 1 Tbps of capacity

1,000ports

Of a 1 Tbps figure taken up by a 40 Gbit/s flood

4%

What the same flood is to a single 1 Gbit/s port

40×

So the capacity figure answers one question, whether the network can absorb a big flood at all, and leaves the important one open: whether it removes a flood aimed at your address before it reaches your port. That depends on where filtering happens and when it starts.

Where the filtering happens decides what it can catch

A claim of protection is also a claim about place. Traffic for your server passes several points where it can be stopped, and each sees something different. All of them are covered in depth in how DDoS protection works; for a buyer, a sentence or two on each is enough to know what to ask.

• Upstream scrubbing takes in volume no single server could, and judges packets by their addresses, ports, sizes and rates. Filtering for many customers at once, it has little feel for the detail of any one application, and with encrypted traffic such as HTTPS it has even less to go on.² Always-on means your traffic passes through it all the time. On-demand means traffic is diverted there only after an attack is detected, so every flood reaches you unfiltered until it has been noticed and rerouted.
• The provider's edge routers are where an address can be dropped entirely with a null route, the subject of the next section, and where some networks apply simple header rules to drop one kind of traffic.
• A filter on the host sees every packet that fits through the port, in full, and can check whether it really speaks the protocol of the service it is aimed at. The guide to XDP and eBPF explains how a filter at the network driver does that cheaply.
• The game server or application sees players and requests, but by then each packet has already cost the link, the kernel and the program something.

This is where "game protection" gets its meaning. A filter that checks a game's protocol drops packets that do not behave like the game: the wrong first message, the wrong structure, a handshake that never completes. A preset that opens the right ports and sets a rate limit is useful, but it is a firewall rule, and it cannot tell a player from a flood built to look like one. Why game servers get DDoS attacks explains why that difference matters so much for UDP games. Ask which games are actually validated, whether validation is on by default, and what happens if your server listens on a port the host's presets do not know about.

When the attack is bigger than the protection

Every network has a size of attack it cannot absorb, or will not absorb for one customer. When a flood aimed at one customer is bigger than the links to that customer can carry, it starves out legitimate traffic and often damages other customers and the provider's own network too.⁴ The standard response is the null route, or blackhole: the provider points the attacked address at a discard route, and the routers drop every packet sent to it. RFC 5635 is plain about the result. Attack traffic and legitimate traffic are both dropped, and the target is taken completely offline.⁴ The customer can ask for it, or the provider can decide it is necessary on its own, to keep the rest of the network available.⁴

A network can also ask its neighbours to do the dropping. RFC 7999 defines a well-known BGP community, BLACKHOLE, which asks a neighbouring network to discard all traffic for the tagged prefix,⁵ typically a single address: a /32 in IPv4.⁵ That moves the drop further away, onto networks with more room, and the result for your address is the same. Nothing reaches it, and an attacker who wanted your server offline has got exactly that. The protection guide walks through how blackholing works router by router.

Why "never null-routed" deserves a question

A host that says it never null-routes is saying that, for any attack it may face, it will either filter all of it or accept the damage to its other customers. That may be true for the attacks it expects. Ask what it does with the one that is bigger. Does it drop your address, throttle it, suspend the server, or move you to a new address? RFC 5635 mentions moving the service to another address as one way to keep it up.⁴ And for how long, and will you be told?

The UK National Cyber Security Centre suggests asking a provider exactly this kind of thing before you need it: whether it applies mitigation automatically and tells you when it does, whether it will throttle your bandwidth beyond a limit, whether it reserves the right to cut off or sink-hole your traffic to protect its other customers, and how quickly service can be restored.² "Unlimited" deserves the same questions. Nothing physical is unlimited: links have speeds and filters have capacity. Read it as "no extra charge", and find out what happens at the point where the provider stops absorbing.

Checking it yourself from public routing data

You cannot measure a host's filtering from outside, and you should not try: sending traffic at a network you do not own to see what it does is an attack, whatever the intent. What you can do is read what the host's network tells the rest of the internet about itself. That information is public by design, because the internet's routing depends on it.

How the internet knows where an address lives

The networks that route traffic on the internet are autonomous systems, or ASes. The classic definition is a set of routers under a single technical administration,⁶ and RFC 1930 adds that an AS has a single, clearly defined routing policy.¹ Each has a number, its ASN, and announces the blocks of addresses it can deliver to, called prefixes, to its neighbours over BGP. Every announcement carries an AS_PATH, the list of autonomous systems the route has passed through,⁶ and each network that passes the route on to another AS prepends its own number.⁶ The origin, the network that first announced the prefix, is the rightmost number in the path.⁷

Route collectors record these announcements. The RIPE NCC's Routing Information Service runs collectors around the world, mostly at internet exchange points; volunteer networks peer with them over BGP, and every update and withdrawal they send is stored.⁸ RIPEstat, the RIPE NCC's open data platform, presents that routing data next to registration data, drawing on other regional registries and IANA as well as the RIPE NCC's own,⁹ so it works for addresses in Asia as well as in Europe. Sites such as bgp.tools and bgp.he.net show similar data in different layouts.

The examples on this page use addresses and AS numbers reserved for documentation: 203.0.113.0/24 is one of the blocks set aside for examples,¹⁵ and AS numbers 64496 to 64511 are reserved for the same purpose.¹⁴ A real lookup shows real networks.

Five checks, in order

1. 1

   Get an address that is really the host's

   A host's website is often behind a CDN, so its address tells you about the CDN, not the servers. Use the address of a server you already rent there, or a test address the host publishes for checking routes and speed. If neither exists, ask for one in the region you would buy in.

2. 2

   Find who announces it

   Look the address up. RIPEstat's prefix overview shows the prefix that covers it, whether it is announced, and the originating AS with its holder's name. Is that holder the host, or another company?

3. 3

   See who sits next to the origin

   The ASes seen just to the left of the origin in collected paths are the networks it hands its routes to: its upstream providers and its peers. One neighbour means one network carries everything in; several mean the host chooses between them.

4. 4

   Check RPKI

   Look up whether the route is covered by a signed Route Origin Authorisation and matches it. Valid is the result to hope for.

5. 5

   Compare the story over time

   Read the host's protection page, plan pages and terms side by side, then look at older copies of the same pages. A figure that changes without explanation, or a different number on each page, tells you how much weight to give it.

Steps two to four are three calls to the RIPEstat Data API, which answers in JSON; jq picks out the fields that matter. RIPEstat's prefix overview returns the covering prefix and a list of originating ASes with their holders' names.¹⁰ Its neighbours call labels each neighbour "left" or "right" by its position in the AS path relative to the AS you asked about,¹¹ and the left ones are those it hands its routes to. Its RPKI call returns one status.¹²

$ curl -s "https://stat.ripe.net/data/prefix-overview/data.json?resource=203.0.113.10" | jq '.data | {resource, announced, asns}'{  "resource": "203.0.113.0/24",  "announced": true,  "asns": [    {      "asn": 64500,      "holder": "EXAMPLE-AS Example Hosting Network"    }  ]}$ curl -s "https://stat.ripe.net/data/asn-neighbours/data.json?resource=AS64500" | jq -c '.data.neighbours[] | select(.type == "left") | {asn, power}'{"asn":64496,"power":812}{"asn":64497,"power":455}$ curl -s "https://stat.ripe.net/data/rpki-validation/data.json?resource=AS64500&prefix=203.0.113.0/24" | jq -r '.data.status'valid

Read it the way the drawing reads. AS64500 announces the prefix, and its holder's name is the first thing to compare with the host's own name. AS64496 and AS64497 sit to its left; power counts the collected paths in which each appeared. Be careful with the word "upstream". BGP has no field that says how two networks are related, so any site that labels a neighbour an upstream is making an educated guess from the paths it sees.¹³ Treat the labels as strong hints, not contracts.

What the RPKI status means

RPKI lets the holder of an address block publish a signed object, a Route Origin Authorisation (ROA), linking its addresses to the AS allowed to originate them.⁷ A route is Valid when a ROA matches it, Invalid when a ROA covers the prefix but none matches, and NotFound when no ROA covers it at all.⁷ RIPEstat reports these as valid, invalid_asn or invalid_length, and unknown.¹² Networks can act on the result, for example by rejecting all Invalid routes,⁷ so an Invalid route can leave the addresses unreachable from part of the internet. RPKI says nothing about DDoS capacity. It does tell you whether the people running the network look after its routing.

A traceroute, to the right address only

traceroute shows the routers on the path from you to an address. It sends probes with a rising time-to-live and listens for the ICMP time exceeded reply from each router along the way, and with -A it looks up each hop's AS in routing registries and prints it next to the address.¹⁷ That shows which networks carry your traffic towards the host. Run it only to your own server, or to a test address the host publishes for exactly this.

$ traceroute -n -A 203.0.113.10traceroute to 203.0.113.10 (203.0.113.10), 30 hops max, 60 byte packets 1  192.168.1.1 [*]  1.204 ms  1.188 ms  1.301 ms 2  10.24.0.1 [*]  6.912 ms  7.020 ms  6.877 ms 3  198.51.100.9 [AS64511]  9.410 ms  9.385 ms  9.502 ms 4  198.51.100.77 [AS64496]  31.207 ms  31.118 ms  31.344 ms 5  192.0.2.30 [AS64500]  32.016 ms  31.990 ms  * 6  203.0.113.10 [AS64500]  32.408 ms  32.377 ms  32.455 ms

Here traffic leaves your own network, crosses AS64511 and enters the host's network, AS64500, through AS64496, one of the neighbours the routing data listed. Two cautions. A traceroute maps the path out from you, not the path back. And some routers rate-limit the replies traceroute relies on,¹⁷ so a missing reply, like the star on hop 5, is not a fault on its own. The Clouduxe docs explain how to read a traceroute without drawing the wrong conclusion.

Old copies of the same claims

The fifth check needs no command. The Internet Archive's Wayback Machine lets you enter a URL and browse its captures by date,¹⁶ so you can see whether a host's capacity figure, its list of protected games or its wording about null routes has changed, and whether anything in the routing picture changed with it.

What the results tell you, and what they cannot

None of these findings is good or bad on its own. What matters is whether it fits what the host says.

Public data cannot show how much capacity really exists, where the filters sit, whether they are on for your address, how they treat your game's traffic, or what the host does under attack. Those remain questions. What public data can do is catch answers that do not fit the facts you can see. A host that describes its own large network while its addresses are announced from another company's AS with a single neighbour owes you an explanation. A host that names its upstream, and whose routing shows that upstream next to its AS, has told you something you could verify.

Questions to ask before you buy

Ask these in writing, before you pay, and keep the answers. A host that runs real protection can answer most of them in a sentence.

• Whose network is your capacity figure for, what is it summed over, and does it apply in the region I would buy in?
• Is filtering always on for my address, or switched on after an attack is detected? If the latter, how long does that take?
• What is my server's port speed, and what happens to traffic above it?
• What does your filtering check: addresses and rates only, or the protocol of my service? Which games and services have a protocol validator?
• Does game protection work on a port I choose, or only on your presets?
• What happens when an attack is bigger than you can filter? Null route, throttling, a new address or suspension; for how long; and will you tell me?²
• Is any part of the protection an add-on, a higher tier, or billed when I am attacked?²
• Will I see what was dropped, and when?
• Which network announces your addresses, and who are your upstreams? Then check the answer yourself.

Red flags

A number with no owner. A capacity figure that does not say whether it is the host's own or its upstream's, or what it is summed over.

A story that changes. A different figure on the home page, the plan page and the terms, or a number that grows between archived copies while nothing in the routing picture changes.

Claims nobody can check. "The only", "the first", "never null-routed", "unlimited". Each is a statement about every attack or every other host, and none comes with a way to verify it.

Protection in the small print. A plan sold as protected, where the protection that matters turns out to be an add-on or a higher tier. Some mitigations really do cost extra,² which is fine when the plan page says so.

A routing picture that contradicts the page. A host that describes its own network while its addresses are announced from someone else's AS, or an RPKI Invalid route that nobody can explain.

Game protection with no protocol named. If a host cannot say which games it validates and what the check looks at, assume it opens ports and sets rate limits, and price it accordingly.