Kapkandocs
GitHub

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:

AttackGenerated FlowSpec match
NTP / DNS / CLDAP / memcached / SSDP / chargen amplificationdst=victim, proto=udp, src-port=<reflected port>
SYN flooddst=victim, proto=tcp, tcp-flags=SYN
Fragment flooddst=victim, fragment
ICMP / UDP / TCP flooddst=victim, proto=<icmp/udp/tcp>
mixed / unknowndst=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-flags match for SYN floods is a bitmask that also matches SYN-ACK, so a discard action drops the victim's outbound-initiated connections too — prefer rate_limit for TCP vectors.
  • max_active_bans caps 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 the mitigate_flowspec_rules metric 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.