BGP FlowSpec for DDoS Mitigation

Blackholing works and takes the destination down with it. For most of the history of inter-provider DDoS response that was the whole toolkit: you could ask an upstream to discard everything to an address, and nothing finer.

FlowSpec exists to make the finer request possible. It reuses BGP as a distribution mechanism but carries filtering rules rather than reachability information RFC 8955, so an upstream can drop one vector and keep delivering the rest.

What a rule is made of

A flow specification has two halves: what to match, and what to do.

The match side is a set of components — destination prefix, source prefix, IP protocol, port, source and destination port, ICMP type and code, TCP flags, packet length, DSCP, fragment flags. Combining them describes a class of traffic with far more precision than a destination address alone.

The action side is carried in BGP extended communities: discard the traffic, rate-limit it to a stated bandwidth, redirect it into a VRF or to another next hop, or mark it with a different DSCP.

The IPv6 equivalent is defined separately RFC 8956, which matters when a dual-stack design assumes both work identically.

Where it fits between the alternatives

Appliance	Precision	Destination stays up	Depends on
Destination RTBH	None — everything to the address	No	A community your upstream honours
FlowSpec drop	One matched flow specification	Yes	Upstream accepting the rule at all
FlowSpec rate-limit	One matched flow, bounded rather than removed	Yes	Upstream accepting rate-limit actions
FlowSpec redirect	One matched flow, sent elsewhere	Yes	Upstream supporting redirect, and somewhere to send it

The third column is the whole story. FlowSpec's capability is defined by the standard; what you can actually use is defined by your contract and your provider's policy.

What it works against

Anything with a describable signature that saturates upstream of you. Reflection attacks are the clearest case: UDP from source port 123, or 11211, or 1900, against your prefix, with a packet length in a characteristic band. That rule discards the reflection and leaves ordinary traffic to the same destination untouched.

Crafted floods with distinctive packet lengths, fragment patterns or TCP flag combinations are similarly tractable. So are attacks against a service you do not run at all — dropping UDP to a port nothing listens on costs you nothing and can remove a large volume.

What it does not work against

Traffic that looks like your traffic. An application-layer flood over HTTPS to your web service matches the same specification your customers match. There is no flow component for “this request is abusive”.

Attacks whose signature changes faster than you can install rules. Rule installation and propagation take time, and an attacker who rotates source ports every few minutes turns rule writing into a losing race.

Anything your upstream will not accept. This is the operational constraint that decides whether FlowSpec is part of your design or a paragraph in it.

Operational risk

Rule scope is the dangerous part. A specification that omits the destination prefix filters traffic to everyone, and providers reject such rules precisely because a customer under pressure will eventually write one. Always scope to your own prefixes.

Rule count limits are real. Providers cap how many rules a customer may install. A design that assumes you can describe every vector individually will hit the cap during exactly the multi-vector campaign it was meant to handle.

Redirect actions are frequently unavailable. Redirecting into a scrubbing VRF is the most architecturally interesting action and the least commonly offered to customers.

Validation rules can drop your own announcement. The specification includes a validation procedure tying a flow specification to the best-match unicast route for its destination. Where your announcement does not satisfy it, the rule is discarded silently from your point of view.

Withdrawal. As with blackholing, a rule left installed after the attack is an outage nobody is looking for.

False-positive risk

Precisely as high as the rule is broad, and entirely under your control — which is a different kind of risk from an automated classifier. A rule that discards all UDP to your prefix stops the reflection attack and also stops your DNS, your VPN and your video. The discipline is to write the narrowest rule that removes the volume, verify what else matches it, and set a review point rather than leaving it indefinitely.

Relationship to the other upstream instruments

FlowSpec sits between RTBH and doing nothing: more precise than the blackhole, less certain to be available. NIST’s treatment places both alongside source-address validation as parts of one interdomain picture rather than as alternatives NIST SP 800 189, which is the right way to hold them.

Where a formal request channel to an upstream mitigator exists, DOTS is the standards-based way to ask for help rather than to install filtering yourself.

Questions to settle with your upstream

1. Do you accept customer-originated FlowSpec, and under what contract?
2. Which match components do you honour, and which do you ignore?
3. Which actions — discard, rate-limit, redirect, DSCP marking?
4. How many concurrent rules may we install?
5. How long does a rule take to take effect, and to withdraw?
6. Does the rule propagate beyond your own network?
7. What happens to our rule if it fails your validation procedure — are we told?

Write the answers down with the date. All seven change, and the one that changed is never the one you remembered to re-check.

Sources