FlowSpec mitigation
RTBH blackholing takes the whole victim offline — it trades the attack for an outage. BGP FlowSpec (RFC 8955 for IPv4, RFC 8956 for IPv6) instead distributes a rule that drops only the matching attack traffic, so the victim keeps serving everything else.
iDry-run first
The generated rules appear in /api/v1/attacks (method, flowspec), in /api/v1/bans,
and in notifications before you ever set dry_run: false — so you can confirm them
against your upstream's FlowSpec support first. See Going live.
Enabling FlowSpec
Set the mitigation method to flowspec. The default method is blackhole (RTBH).
mitigation: flowspec # default method for all groups (default: blackhole)
flowspec:
action: discard # or rate_limit
rate_mbps: 100 # required for rate_limit
hostgroups:
- name: web
networks: ["203.0.113.0/26"]
mitigation: blackhole # per-group override
mitigation is overridable per hostgroup, so you can run FlowSpec
globally and fall back to blackhole for a specific prefix set (or vice versa).
Generated rules
On an attack, Kapkan derives a minimal rule set (at most 8) from the attack's classification and flow sample, matching the victim as destination plus the vector:
| Attack | Generated FlowSpec match |
|---|---|
| NTP / DNS / CLDAP / memcached / SSDP / chargen amplification | dst=victim, proto=udp, src-port=<reflected port> |
| SYN flood | dst=victim, proto=tcp, tcp-flags=SYN |
| Fragment flood | dst=victim, fragment |
| ICMP / UDP / TCP flood | dst=victim, proto=<icmp/udp/tcp> |
| mixed / unknown | dst=victim (plus a rule per dominant reflector port in the sample) |
The victim is always matched as a /32 (IPv4) or /128 (IPv6). IPv6 FlowSpec is at full
parity with IPv4 — where FastNetMon's own roadmap still lists IPv6 FlowSpec as unsupported.
Outgoing attacks
For an outgoing attack — a compromised host flooding outward — the rule matches the host as source (the RFC 8955/8956 source-prefix), so it actually drops the outbound flood. This is unlike a destination-based RTBH blackhole, which only kills traffic to the host.
Caveats
- The
tcp-flagsmatch for SYN floods is a bitmask that also matches SYN-ACK, so adiscardaction drops the victim's outbound-initiated connections too — preferrate_limitfor TCP vectors. max_active_banscaps bans, not rules: a FlowSpec ban can carry up to 8 rules, so N bans can mean up to 8N rules in your upstream's RIB. Watch themitigate_flowspec_rulesmetric against your routers' FlowSpec route limit.
Rule action and lifecycle
Each rule carries a traffic-rate extended community: discard (rate 0) or a rate_limit
ceiling. FlowSpec bans share the same TTL, unban hysteresis, and max_active_bans lifecycle
as blackhole bans — see RTBH mitigation.
FlowSpec rides the same BGP neighbors as RTBH: the FlowSpec AFI/SAFI is advertised
additively, and a peer that does not support it simply will not negotiate it. FlowSpec is
not valid for calculation: total hostgroups — there is no single victim prefix to
match.
Related
- RTBH mitigation — the blackhole method and shared ban lifecycle.
- Escalation ladders — step up from alert to FlowSpec to blackhole over time.
- Configuration reference · Metrics · REST API