How BGP FlowSpec Works: Distributed DDoS Mitigation via BGP

BGP FlowSpec (Flow Specification) is a BGP extension that allows network operators to distribute traffic filtering and rate-limiting rules across their network using the BGP routing protocol. Instead of manually configuring access control lists (ACLs) on every router during a DDoS attack, an operator can inject a single FlowSpec rule into BGP, and it propagates automatically to all BGP-speaking routers in the network. FlowSpec transforms BGP from a pure reachability protocol into a distributed firewall policy distribution system. Originally defined in RFC 5575 and updated by RFC 8955 (which obsoletes RFC 5575), FlowSpec is one of the most powerful tools available for real-time DDoS mitigation in ISP and enterprise networks.

FlowSpec is particularly valuable because it operates at the network layer, close to the attack source. Rather than absorbing attack traffic at a scrubbing center or at the target, FlowSpec rules can be pushed to upstream routers and even to peering partners, filtering malicious traffic before it consumes expensive transit capacity. When combined with BGP communities and automation, FlowSpec enables sub-minute DDoS response times without human intervention.

The Problem FlowSpec Solves

Consider a typical DDoS mitigation scenario without FlowSpec: a volumetric UDP flood targets a customer's IP address. The operator detects the attack (via NetFlow, sFlow, or inline monitoring), identifies the attack characteristics (source port 53, destination port random, protocol UDP), and then must:

1. Log into each border router individually
2. Write an ACL that matches the attack traffic
3. Apply the ACL to the appropriate interface
4. Repeat for every router that receives attack traffic
5. Reverse the process when the attack ends

In a network with 20 border routers across multiple PoPs, this manual process can take 30-60 minutes — during which the target is unreachable and collateral damage affects other customers sharing the same links. FlowSpec replaces this entire process with a single BGP announcement that propagates to all routers in seconds.

FlowSpec NLRI Encoding

FlowSpec uses a new BGP NLRI (Network Layer Reachability Information) encoding to describe traffic flows. Each FlowSpec rule is encoded as a sequence of match components in the NLRI, and actions encoded as extended communities attached to the BGP UPDATE. The NLRI is carried in the BGP Multiprotocol Extensions (RFC 4760) using AFI 1 (IPv4) or AFI 2 (IPv6) and SAFI 133 (FlowSpec) or SAFI 134 (FlowSpec VPN).

Match Components (NLRI)

Each match component specifies a condition that traffic must meet. Multiple components are combined with an implicit AND — all conditions must match for the rule to apply. The following component types are defined in RFC 8955:

• Type 1 — Destination Prefix: Matches the destination IP address. Encoded as a prefix length and prefix value. Example: 203.0.113.0/24
• Type 2 — Source Prefix: Matches the source IP address. Example: 198.51.100.0/24
• Type 3 — IP Protocol: Matches the IP protocol number. Example: 17 (UDP), 6 (TCP), 1 (ICMP)
• Type 4 — Port: Matches either source or destination port. Uses numeric operators (equals, greater-than, less-than, range).
• Type 5 — Destination Port: Matches the destination transport port. Example: =80 or >=1024 && <=65535
• Type 6 — Source Port: Matches the source transport port. Example: =53 (DNS responses, common in amplification attacks)
• Type 7 — ICMP Type: Matches the ICMP type field.
• Type 8 — ICMP Code: Matches the ICMP code field.
• Type 9 — TCP Flags: Matches specific TCP flags. Useful for filtering SYN floods (SYN && !ACK) or other flag-based attacks.
• Type 10 — Packet Length: Matches the total IP packet length. Useful for filtering unusually small or large packets characteristic of certain attacks.
• Type 11 — DSCP: Matches the DiffServ Code Point field.
• Type 12 — Fragment: Matches fragmentation flags (Don't Fragment, Is Fragment, First Fragment, Last Fragment). Useful for filtering fragmentation-based attacks.

RFC 8956 extends FlowSpec to IPv6, adding match components for IPv6 flow labels and using the IPv6 next-header field instead of IP protocol.

Numeric Operators

For numeric match components (port, packet length, protocol, etc.), FlowSpec uses a compact operator encoding. Each value is preceded by an operator byte that specifies the comparison:

• Bit 0-1: Length of the value (1, 2, 4, or 8 bytes)
• Bit 5: Less-than
• Bit 6: Greater-than
• Bit 7: Equal
• Bit 4: AND (combine with next value using AND; default is OR)
• Bit 3: End-of-list marker

Multiple values can be chained together with OR or AND logic. For example, to match "destination port 80 OR 443": =80 | =443. To match "port >= 1024 AND <= 65535": >=1024 & <=65535.

FlowSpec Actions

Actions are encoded as BGP extended communities attached to the FlowSpec NLRI. When a packet matches the flow specification, one or more actions are applied:

• Traffic Rate (type 0x8006): Rate-limits matching traffic to a specified bits-per-second value. A rate of 0 effectively drops all matching traffic (this is the most common DDoS mitigation action). Non-zero values enable proportional rate limiting, allowing some legitimate traffic through during an attack.
• Traffic Action (type 0x8007): Two bits control behavior:
  • Terminal action (T bit): If set, evaluation stops at this rule and no further FlowSpec rules are checked. If unset, the router continues evaluating additional rules.
  • Sample (S bit): If set, the router should log/sample matching traffic (e.g., via NetFlow/sFlow) for monitoring purposes.
• Redirect to VRF (type 0x8008): Redirects matching traffic into a specific VRF (Virtual Routing and Forwarding) instance. This enables traffic diversion to a scrubbing center or sinkhole without dropping it. The VRF can route the traffic through an inspection pipeline and re-inject clean traffic.
• Traffic Marking (type 0x8009): Rewrites the DSCP value in the IP header of matching traffic. Used to re-mark attack traffic to a lower priority class so it is dropped first during congestion, rather than dropping it outright.
• Redirect to IP (type 0x0800/0x0008): Defined in RFC 7674. Redirects matching traffic to a specific IPv4 or IPv6 next-hop address. This is more flexible than VRF redirect because it does not require pre-configured VRF infrastructure — traffic is simply forwarded to a different destination (e.g., a scrubbing appliance).

FlowSpec Validation

To prevent a rogue BGP speaker from injecting FlowSpec rules that disrupt legitimate traffic, RFC 8955 defines strict validation rules that a receiving router must apply before installing a FlowSpec rule:

1. Origin AS validation: The originator of the FlowSpec NLRI must be the same AS that originates the best-match unicast route for the destination prefix in the FlowSpec rule. If the FlowSpec rule specifies destination 203.0.113.0/24, and the best unicast route for 203.0.113.0/24 is originated by AS64500, then the FlowSpec rule must also originate from AS64500. This prevents arbitrary ASes from injecting filters for prefixes they do not own.
2. Neighbor AS validation: For eBGP-learned FlowSpec, the FlowSpec NLRI must be received from the same neighbor that advertised the best-match unicast route. This ensures FlowSpec rules propagate along the same paths as the unicast routes they protect.
3. Feasibility check: The destination prefix in the FlowSpec rule must have a matching entry in the unicast routing table. A FlowSpec rule for a prefix with no unicast route is rejected.

These validation rules are critical for security but can also be operationally inconvenient. For internal iBGP FlowSpec (where the FlowSpec controller is within the same AS), validation can be relaxed because the iBGP session is trusted. Many operators disable origin AS validation for iBGP-learned FlowSpec rules while keeping it strict for eBGP-learned rules.

FlowSpec Rule Examples

Here are practical FlowSpec rules expressed in a common CLI-like notation (actual syntax varies by vendor):

Drop all UDP traffic to a target

flow {
  match destination 203.0.113.50/32;
  match protocol udp;
  then discard;
}

This drops all UDP traffic destined for 203.0.113.50. Simple and effective for a UDP-only flood, but also drops legitimate UDP traffic (DNS, QUIC) to the target.

Drop DNS amplification attack

flow {
  match destination 203.0.113.50/32;
  match protocol udp;
  match source-port 53;
  match packet-length >= 512;
  then discard;
}

Targets DNS amplification specifically: large UDP packets from source port 53. Legitimate DNS responses to the target are typically small; amplified responses are artificially large. The packet-length filter reduces collateral damage to legitimate DNS traffic.

Rate-limit NTP amplification

flow {
  match destination 203.0.113.0/24;
  match protocol udp;
  match source-port 123;
  then rate-limit 1000000;
}

Instead of dropping all NTP traffic, this rate-limits it to 1 Mbps. Some NTP traffic may be legitimate; rate limiting allows a small amount through while preventing the volumetric attack from consuming all bandwidth.

Redirect SYN flood to scrubbing VRF

flow {
  match destination 203.0.113.50/32;
  match protocol tcp;
  match tcp-flags syn !ack;
  then redirect vrf SCRUBBER;
}

Redirects TCP SYN packets (without ACK, indicating connection initiation) to a scrubbing VRF where a mitigation appliance performs SYN validation (SYN cookies or SYN proxy) and forwards legitimate connections back.

FlowSpec at Internet Exchange Points

Some Internet Exchange Points (IXPs) and transit providers support FlowSpec from their customers via eBGP. This allows a customer under attack to inject FlowSpec rules that the upstream provider applies on its border routers, filtering attack traffic before it enters the customer's last-mile link. This is sometimes called upstream FlowSpec or remote triggered FlowSpec.

Upstream FlowSpec requires trust between the customer and the provider. Providers typically apply strict validation rules and limit the scope of FlowSpec rules a customer can inject:

• Customers can only create rules matching their own destination prefixes (enforced by validation against the unicast routing table).
• Maximum number of FlowSpec rules per customer is limited (e.g., 50 or 100) to prevent resource exhaustion.
• Only certain actions are permitted (typically rate-limit and discard, not redirect).
• Provider may require that FlowSpec rules include a destination prefix (no wildcard source-only rules).

FlowSpec vs. RTBH (Remotely Triggered Black Hole)

Before FlowSpec, the primary BGP-based DDoS mitigation technique was RTBH (Remotely Triggered Black Hole), also known as blackhole routing. RTBH works by advertising a /32 host route for the target IP with a specific BGP community (often the well-known blackhole community 65535:666, defined in RFC 7999). Upstream routers receiving this announcement set the next-hop to a null interface, dropping all traffic to that IP.

RTBH is simpler than FlowSpec but far cruder:

• RTBH drops ALL traffic to the target IP, including legitimate traffic. The DDoS attack succeeds in its goal of making the target unreachable — you are just moving the discard point upstream.
• FlowSpec can be selective: Drop only UDP, only traffic from specific source ports, only packets of certain sizes, etc. Legitimate traffic can continue to flow.
• RTBH is universally supported: Almost every BGP router supports blackhole routing. FlowSpec support, while widespread, is not universal, especially on older hardware.
• RTBH is a last resort: When an attack is so volumetric that selective filtering cannot help (e.g., the attack saturates the inbound links regardless of filtering), RTBH at the upstream provider is the only option. FlowSpec is most useful when the attack has identifiable characteristics that allow surgical filtering.

Many operators use both: FlowSpec for targeted, selective mitigation of attacks with identifiable signatures, and RTBH as a fallback when FlowSpec is insufficient or the attack volume exceeds the network's capacity to filter.

FlowSpec and BGP Hijack Mitigation

While FlowSpec is primarily used for DDoS mitigation, it can also play a role in responding to BGP hijacks. If an operator detects that their prefix is being hijacked (traffic is being misdirected to an unauthorized AS), they can use FlowSpec to filter spoofed traffic or redirect traffic matching specific patterns while the hijack is being resolved through RPKI-based route origin validation or manual coordination.

FlowSpec Implementation Considerations

Deploying FlowSpec in production requires careful attention to several operational details:

• Hardware support: FlowSpec rules are typically implemented as ACL entries in the router's TCAM (Ternary Content-Addressable Memory). TCAM space is finite and shared with other ACL functions (interface ACLs, QoS policies, etc.). A large number of FlowSpec rules can exhaust TCAM space, causing rules to be silently ignored. Operators must monitor TCAM utilization.
• Rule ordering: When multiple FlowSpec rules match the same traffic, RFC 8955 defines a strict ordering based on the NLRI encoding. More specific rules (with more match components) take precedence over less specific rules. Understanding the ordering algorithm is essential for predictable behavior.
• Convergence time: FlowSpec rules propagate via BGP, which means they are subject to BGP convergence delays (scan timer, MRAI timer, etc.). On a well-tuned iBGP network, FlowSpec rules propagate in seconds. On eBGP, MRAI and route processing delays can add 10-30 seconds.
• Rule limits: Most router implementations have a maximum number of FlowSpec rules they can install (often in the thousands to tens of thousands range). Operators should set per-peer limits and global limits to prevent resource exhaustion.
• Logging and monitoring: Every FlowSpec rule installation and removal should be logged. Match counters (packets and bytes matched per rule) should be monitored to verify that rules are effective and to detect when rules are no longer needed.

FlowSpec Automation

The full power of FlowSpec is realized when it is integrated with automated DDoS detection systems. The typical architecture uses:

1. Flow telemetry collection: NetFlow v9/IPFIX or sFlow data is collected from all border and core routers and sent to a central collector.
2. DDoS detection engine: Software that analyzes flow data in real time, detecting traffic anomalies that match known DDoS attack patterns (volumetric floods, protocol attacks, application-layer attacks).
3. FlowSpec controller: When an attack is detected, the controller automatically generates the appropriate FlowSpec rule based on the attack characteristics and injects it into BGP. The controller maintains a BGP session with a route reflector or directly with border routers.
4. Automatic withdrawal: The controller monitors ongoing traffic to determine when the attack has subsided and automatically withdraws the FlowSpec rule. Rules may also have a configurable timeout (not part of the BGP protocol but implemented in the controller logic).

Open-source tools like ExaBGP and GoBGP can act as FlowSpec controllers, injecting rules programmatically via BGP. Commercial platforms from vendors like Arbor/NETSCOUT, Flowmon, and A10 provide integrated detection-and-mitigation workflows with FlowSpec as the distribution mechanism.

Limitations of FlowSpec

FlowSpec is powerful but not a complete DDoS solution:

• Volumetric attacks that saturate upstream links: If the attack volume exceeds the capacity of the links connecting to upstream providers, filtering at the border routers is too late — the links are already congested. FlowSpec at the upstream provider (if supported) or RTBH is needed.
• Encrypted traffic: FlowSpec operates on IP/TCP/UDP header fields. It cannot inspect TLS-encrypted payloads or distinguish between legitimate and malicious HTTPS traffic. Application-layer DDoS attacks require L7 mitigation (WAFs, reverse proxies).
• Spoofed source addresses: Source prefix matching in FlowSpec is of limited use against attacks with spoofed source IPs (which are randomized). Destination-based rules and protocol/port-based rules are more effective.
• IPv6 FlowSpec maturity: While RFC 8956 defines IPv6 FlowSpec, vendor support and deployment are less mature than IPv4 FlowSpec. Operators should verify their equipment supports IPv6 FlowSpec before relying on it.
• Interoperability: FlowSpec rule encoding and action interpretation can vary between vendors. Testing FlowSpec interoperability between different router platforms (Cisco, Juniper, Nokia, Arista) before production deployment is essential.

RFCs and Standards

The FlowSpec standard has evolved over time:

• RFC 5575 (2009): The original FlowSpec specification for IPv4. Defined the NLRI encoding, match components, and action extended communities.
• RFC 7674 (2015): Added the "redirect to IP" action, enabling redirection to a specific next-hop address.
• RFC 8955 (2020): Obsoletes RFC 5575. Clarified validation rules, fixed ambiguities in the NLRI encoding, and tightened the specification based on operational experience.
• RFC 8956 (2020): Extends FlowSpec to IPv6, defining IPv6-specific match components (flow label, next-header).

Monitor BGP Routes and DDoS Indicators

FlowSpec is one layer of the DDoS defense stack built on top of BGP. Understanding how traffic flows between networks — the AS paths, upstream providers, and peering relationships — is essential context for designing effective FlowSpec rules. Use the god.ad BGP Looking Glass to explore live BGP routing data, trace AS paths to potential attack sources, and understand the routing topology that FlowSpec protects.