BGP FlowSpec and RTBH in an Operator's Practice
BGP FlowSpec and RTBH in an Operator's Practice
What your router must support, and what the upstream does not need to support at all
In conversations with ISPs about anti-DDoS protection, one question comes up more often than any other: "does my upstream have to support FlowSpec for this to work?" The answer is: no. And this misunderstanding is worth clearing up once and for all, because it makes some operators give up on considering automatic DDoS mitigation before they have even checked that their current infrastructure is entirely sufficient.
Two mechanisms, two different places in the network
BGP FlowSpec and RTBH (Remotely Triggered Blackholing) are the two basic mechanisms for mitigating DDoS attacks in operator networks. They are often thrown into one bag called "BGP for DDoS protection", but they work in different places and solve different problems.
FlowSpec is precise filtering. A FlowSpec rule describes specific traffic (protocol, port, packet length, fragmentation) and instructs the router what to do with it: drop, rate-limit, redirect. The attacked address remains reachable; only traffic matching the attack pattern is cut out.
RTBH is cutting off. A route for the attacked address is announced with a special community, and routers (your own or the upstream's) send all traffic to that address into null. Effective, but blunt: the attacked address stops being reachable at all. RTBH makes sense when the attack volume threatens to saturate transit links and the rest of the network has to be saved.
The key point: FlowSpec works locally, at your edge
A system such as LiveShield announces FlowSpec rules over a BGP session to your own edge routers. They program filtering in the data plane and cut out attack traffic at the entrance to the network. The upstream takes no part in this and does not have to support or agree to anything.
On the upstream's side, only one, widely available thing is needed: blackholing support via community (RTBH). This is standard at practically every transit provider and at internet exchange points. Blackhole routes are announced over an ordinary BGP unicast session and redistributed upward with the appropriate community, with no additional technical arrangements.
If the upstream additionally accepts FlowSpec rules from customers, great: filtering can then be moved even higher, and the attack is cut out before it touches your links. In practice, operators whose upstreams offer FlowSpec can give up RTBH entirely. But that is an option, not a condition.
What it looks like during a real attack: the hybrid scenario
In practice the most effective approach is a combination of both mechanisms, working automatically depending on the scale of the incident:
- The attack is detected, and the first FlowSpec rules reach the edge routers within single seconds. Attack traffic is cut out locally, the remaining traffic to the attacked address passes normally, and the customer does not feel the incident.
- The system refines filtering based on analysis of sampled packets, generating the narrowest possible rules instead of blocking all traffic of a given protocol.
- If the attack volume grows to a level threatening to saturate the transit links, RTBH is triggered for the attacked address: local filtering is no longer enough, so the blackhole route is redistributed to the upstreams and the traffic dies outside your network.
LiveShield carries out this scenario automatically. Thresholds and the sequence of reactions can be configured per prefix or customer group: different actions for a small attack, different ones for a large one, with notifications and triggering of your own scripts along the way.
BGP FlowSpec in LiveShield
"Will my router handle it?" Practical hardware realities
This is the second most common question, and it is worth being honest here: not every piece of hardware that declares FlowSpec support can actually program rules in the data plane. Some platforms accept FlowSpec routes and can redistribute them, but do not apply filtering.
A few practical tips from deployments:
- Proven platforms include Juniper MX/PTX, Cisco ASR 9000/9900, ASR 1000 and Cisco 8000.
- On the Cisco NCS 5500 series, FlowSpec requires models with an external eTCAM (marked -SE), and not all of them. FlowSpec rules take up a lot of TCAM space, so it is worth verifying the specific model before purchase.
- Software routers (BIRD, CHR and similar) are a separate story: BIRD will accept FlowSpec rules, but does nothing with them itself beyond passing them on. For such environments, RTBH or redistributing rules to an upstream with FlowSpec support remains a realistic option.
If you are unsure about your model, ask the manufacturer or write to us. Given the number of deployments we have carried out, there is a good chance we already know your hardware.
Good configuration practice: apply FlowSpec rules only on upstream interfaces, disabling them on customer and internal interfaces. Ready-made configuration examples for individual platforms can be found in our documentation: docs.liveshield.net/bgpconfiguration.html.
What follows for the operator
Automatic DDoS mitigation based on BGP FlowSpec and RTBH requires neither replacing infrastructure nor negotiating with the transit provider. It requires an edge router with real FlowSpec support, which a large share of operators already have, and standard blackholing support at the upstream, which is the norm today.
LiveShield ties this into one automatic mechanism: per-IP and per-subnet detection, FlowSpec rules at your edge within seconds of detecting the attack, RTBH as protection against link saturation. All on-premise, without redirecting traffic outside your network and within a single license.
Unsure whether your routers will cope with FlowSpec? Write to us: office@liveshield.net. We will advise based on our experience with specific platforms. You can see the system in action at demo.liveshield.net.
