BGP Flowspec Explained: Traffic Filters over BGP and How to Secure It

BGP Flow Specification (Flowspec) is a BGP extension that carries traffic filter rules instead of plain routes: each rule matches packets on fields such as destination and source prefix, protocol, ports, ICMP type, TCP flags, packet length, DSCP and fragment state, and attaches an action such as rate limit, discard, redirect to a VRF or DSCP remarking. It was first published as RFC 5575 in August 2009, replaced by RFC 8955 in December 2020, extended to IPv6 by RFC 8956 the same month, and its validation rules were revised by RFC 9117 in August 2021. Securing it means validating who may send a rule, capping how many rules you accept, restricting which actions outsiders may use, and treating the controller that originates rules as critical infrastructure.

This post goes one level below our BGP explainer and our DDoS explainer. Here we stay on Flowspec: how a rule is encoded byte by byte, which actions it can carry, how it compares with black hole routing, how validation works and why RFC 9117 changed it, how Flowspec can hurt the network it protects, and a lab where you announce, verify and withdraw a rate limit rule with open source BGP daemons.

Key takeaways

• Flowspec defines a new BGP address family. IPv4 Flowspec uses AFI 1 with SAFI 133, VPNv4 Flowspec uses AFI 1 with SAFI 134, and RFC 8956 adds IPv6 Flowspec on AFI 2 with the same SAFI values.
• A rule is an ordered list of up to 13 component types, from Type 1 (destination prefix) to Type 13 (IPv6 flow label). A packet matches only if it matches every component present (a logical AND).
• Actions travel as BGP extended communities: traffic-rate-bytes (0x8006), traffic-rate-packets (0x800c), traffic-action (0x8007), three rt-redirect formats (0x8008, 0x8108, 0x8208), rt-redirect-ipv6 (0x000d) and traffic-marking (0x8009). A rate of zero means discard. With no action, a matching packet is accepted.
• Rules are evaluated in a deterministic order defined by RFC 8955 Section 5.1, not the order they arrived. More specific destination prefixes win, and rules that contain a lower numbered component beat rules that lack it. This produces real surprises.
• By default, a Flowspec rule is only feasible if it contains a destination prefix and comes from the same originator as the best unicast route for that prefix. RFC 9117 relaxed this so a central controller inside your own AS can originate rules, and so rules can cross an Internet exchange route server.
• Remotely triggered black hole routing (RFC 5635) and the BLACKHOLE community 65535:666 (RFC 7999) drop everything to a destination. Flowspec can drop only the attack traffic, at the cost of more router hardware resources and more ways to get it wrong.
• The main operational risks are a rule that matches too much, hardware filter table (TCAM) exhaustion, ordering and action interference, and a compromised or buggy controller pushing filters to every edge router at once. RFC 8955 itself tells operators they may need to cap the number of rules they accept.
• NIST SP 800-189 (December 2019) recommends that edge routers support destination and source based RTBH (Security Recommendation 60) and Flowspec for coordinated DDoS mitigation (Security Recommendation 61).

What BGP Flow Specification is and when it was standardised

BGP was built to answer one question: to reach this prefix, which neighbor do I send packets to? Flowspec reuses the same machinery, sessions, update messages, path selection and policy, to answer a different question: for packets that look like this, what should the router do? RFC 8955 describes its purpose as letting "an upstream autonomous system to perform inbound filtering in their ingress routers of traffic that a given downstream AS wishes to drop." The document lists three applications it was designed for: preventing traffic based denial of service attacks, traffic filtering in BGP/MPLS VPN services, and centralized traffic control for SDN and NFV networks.

The key idea is that a filter becomes BGP routing information. Instead of an operator typing an access list into fifty edge routers, one BGP speaker announces a Flowspec route, and every router with the Flowspec address family enabled receives it, validates it and programs a matching filter into its forwarding hardware. Withdrawing the route removes the filter everywhere. Fast propagation, automatic withdrawal when a session drops, and policy at each hop now apply to filters too.

Flowspec is negotiated per session. RFC 8955 says implementations that want to exchange Flowspec "MUST use BGP's Capability Advertisement facility" to advertise the Multiprotocol Extensions capability (code 1, from RFC 4760) with the right AFI and SAFI pair. If the neighbor does not advertise the Flowspec family, no Flowspec routes cross that session. That is the first line of defence: a peer you never enabled Flowspec with cannot send you filters.

Timeline of Flowspec and related standards

The RFC 8955 change list is worth knowing if you run older equipment. Appendix B says RFC 5575 left the meaning of the numeric operator bit combinations "not explicitly defined and left open to the reader", defined the traffic-rate action as non transitive and did not say whether the other actions were transitive. RFC 8955 fixed all three and added a packet based rate action that did not exist before. Two routers that both claim Flowspec support may therefore behave differently on the same rule if one implements RFC 5575 and the other RFC 8955. The open source projects in our lab show this in their own documentation: GoBGP lists RFC 5575, RFC 7674 and the IPv6 draft that became RFC 8956 as its basis, and FRRouting lists RFC 5575 and two drafts.

How a Flowspec rule is encoded

A Flowspec route is carried in the MP_REACH_NLRI attribute to announce it and MP_UNREACH_NLRI to withdraw it, the same attributes multiprotocol BGP uses for IPv6 or VPN routes. RFC 8955 says the next hop length "MUST be set to 0" when advertising Flowspec, because a filter has no next hop. The NLRI itself is a length followed by a value.

The length is one octet if the value is shorter than 240 octets. From 240 up to the maximum of 4095 octets, it becomes two octets with the top nibble set to 0xf. RFC 8955 gives the example that 239 encodes as 0xef while 240 encodes as 0xf0f0.

The value is a sequence of components. Each starts with a one octet type. RFC 8955 has three rules about them that matter in practice:

1. Components "MUST follow strict type ordering by increasing numerical order." A destination prefix (Type 1) always comes before a protocol (Type 3), which always comes before a destination port (Type 5).
2. Each component type may appear at most once in a rule.
3. A packet matches the rule only if it matches "the intersection (AND) of all the components present."

An NLRI with an unknown component type, or one not encoded as specified, is malformed and handled under the BGP error handling rules of RFC 7606. RFC 8955 also notes that some combinations can never match anything, giving "ICMP Type AND Port" as the example, and says such rules "SHOULD NOT be propagated."

The twelve IPv4 components and the IPv6 thirteenth

Three details trip people up.

Port components and fragments. RFC 8955 says the port components never match "if the packet is fragmented and this is not the first fragment, or if the system is unable to locate the transport header." A rule that drops UDP source port 123 will not drop the second and later fragments of a large NTP response, because those fragments carry no UDP header at all. If the attack is heavily fragmented you need a separate rule on the Fragment component. NIST SP 800-189 Security Recommendation 59 separately recommends that providers rate limit non initial UDP fragments at edge routers facing customers and lateral peers.

Type 4 matches either port. The Port component matches a packet if the source port or the destination port matches. A rule written with Type 4 equal to 53 to catch DNS reflection replies (source port 53) will also hit your own resolvers' outbound queries to port 53 on the same destination prefix. Use Type 6 (source port) when you mean the source.

IPv6 needs extra care. RFC 8956 changes Type 1 and Type 2 to carry an offset, so a rule can skip the first N bits of an address and match a pattern in the middle, which is useful for addresses that embed an IPv4 address. Type 3 matches only the first Next Header that is not an extension header. RFC 8956 also warns that hardware limitations in several routers "may make it impossible to enforce a policy" that matches on upper layer fields when long IPv6 extension header chains are present.

Numeric and bitmask operators

Components from Type 3 onward carry a list of operator and value pairs. Each operator is one octet.

The numeric operator has, from the most significant bit: an end of list bit (e), an AND bit (a), a two bit length field (len) giving value sizes of 1, 2, 4 or 8 octets, a reserved zero bit, then three comparison bits lt, gt and eq. Combining the comparison bits gives equal (eq), greater than (gt), greater or equal (gt and eq), less than (lt), less or equal (lt and eq), not equal (lt and gt), and the two edge cases: none set means always false, all set means always true. Consecutive pairs are ORed unless the AND bit is set, and RFC 8955 says AND binds tighter than OR. The AND bit must be clear on the first pair.

The bitmask operator, used for TCP flags and fragments, replaces lt, gt and eq with a NOT bit and a Match bit. With Match set, the test is that all the bits in the value are set in the packet. With Match clear, the test is that any of them are set. The NOT bit negates the result.

Worked example 1: the RFC's own rule, decoded byte by byte

RFC 8955 Section 4.3.1 encodes the rule "all packets to 192.0.2.0/24 and TCP port 25" as:

0b  01 18 c0 00 02  03 81 06  04 81 19

Reading it left to right:

Count the bytes after the length: 5 for the prefix component, 3 for protocol, 3 for port, total 11, which is 0x0b.

Worked example 2: a rule against NTP reflection, with a range

Suppose an attack sends NTP responses (UDP, source port 123) to 198.51.100.10, and you also want a second rule for a web service on that host that accepts ports 8080 to 8088 only from a partner range. Here is the first rule, built the same way:

0c  01 20 c6 33 64 0a  03 81 11  06 81 7b

The components appear in type order 1, 3, 6, as required. For a destination port range of 8080 to 8088 you need two pairs joined by AND, each with a 2 octet value (len equal to 01):

05  13 1f 90  d5 1f 98

The first operator 0x13 is len 01 (0x10) plus gt and eq (0x03), with value 0x1f90 (8080). The second operator 0xd5 is end of list (0x80) plus AND (0x40) plus len 01 (0x10) plus lt and eq (0x05), with value 0x1f98 (8088). In words: port greater than or equal to 8080 AND port less than or equal to 8088. Leaving the AND bit clear would turn it into an OR and match every port, which is exactly the kind of one bit mistake that turns a narrow allow rule into a wide one.

You will rarely write these bytes by hand, but when a router shows a decoded rule that differs from what you meant to announce, reading the raw update in a packet capture tells you which side is wrong.

What actions a Flowspec rule can carry

The match half of a rule lives in the NLRI. The action half lives in BGP extended communities attached to the same update. RFC 8955 defines a minimum set and says "the default action for a matching Flow Specification is to accept the packet." An announced rule with no action community is a match that does nothing, apart from making that rule the first match for those packets.

RFC 8955 made all of these transitive, so they pass across AS boundaries unless policy strips them. Its security section explains why that matters: "all non-traffic-rate actions may allow a third party to modify packet forwarding properties and potentially gain access to other routing-tables/VPNs or undesired queues." A redirect rule from a customer could steer traffic into a VRF you never meant them to reach. The recommended defence is to accept only a predefined subset of actions from third parties, ideally by mapping communities the customer is allowed to set onto actions inside your network, and refusing raw action communities from outside.

Worked example 3: how rates are encoded, and the bits versus bytes trap

The rate is an IEEE 754 single precision float in bytes per second. Two numbers show why units matter:

• To police a flow to 1 Mbit per second, divide by 8: 1,000,000 bits per second is 125,000 bytes per second. As a float, 125000.0 is 0x47f42400, so the full community is 80 06, two ID octets, then 47 f4 24 00.
• The FRRouting documentation shows a SYN flood rule received with "FS:rate 1000000.000000". That is 1,000,000 bytes per second, or 8 Mbit per second, not 1 Mbit per second. An operator who typed one million thinking in bits has allowed eight times the traffic they intended.
• A rate of zero (0x00000000) discards everything. RFC 8955 says negative values "MUST be treated as zero", so a sign bit error also discards.

The two octet field before the float is informational. RFC 8955 says it "SHOULD NOT be interpreted by the implementation", although many operators put their AS number there so a rule is traceable.

The terminal bit and multiple matches

The traffic-action community defines two bits. The S (sample) bit turns on sampling and logging for the rule. The T (terminal) bit, despite its name, works the other way from what most people expect. RFC 8955 says that when the bit is set, "the traffic filtering engine will evaluate any subsequent Flow Specifications", and if it is not set, "the evaluation of the traffic filters stops when this Flow Specification is evaluated." So by default the first matching rule wins and nothing else runs. Set T when you want a rule's action applied and later rules checked too.

When several matching rules apply because of the T bit, RFC 8955 says all their actions are collected and applied, and when actions conflict, for example two different rate limits, "it is an implementation decision which Traffic Filtering Actions are selected." It asks implementers to document what they do and operators to use policy "to achieve a predictable behavior." In a mixed vendor network, assume two routers will resolve the same conflict differently.

Redirect and marking in practice

Redirect sends matching traffic into another routing instance. The classic use is diversion: traffic toward an attacked prefix is pushed into a VRF whose default route points at a cleaning or scrubbing system, while everything else follows the normal table. Traffic marking rewrites DSCP so that suspect traffic lands in a low priority queue rather than being dropped. RFC 8955 notes that "worse-than-best-effort" treatment is implemented differently on different systems and suggests mapping user defined communities to local behavior instead of standardizing it.

Redirect to an IP next hop, rather than to a VRF, comes from a separate IETF draft that FRRouting lists among the documents it implemented. It is not part of RFC 8955, so confirm both ends implement the same revision before relying on it.

How Flowspec compares with RTBH and the BLACKHOLE community

Before Flowspec, operators already used BGP to distribute filters, just much blunter ones.

Destination based remotely triggered black hole (D/RTBH). A trigger router announces the victim's address (often a /32) with an agreed community. Edge routers have a static discard route for a reserved address, and their policy rewrites the next hop of any route with that community to the discard address. RFC 5635 describes the result plainly: all packets to the destination, "attack traffic AND legitimate traffic", are dropped, "thereby taking the target completely offline." The benefit is that the rest of the network survives. The cost is that the attack succeeds against the one target.

Source based RTBH (S/RTBH). RFC 5635 adds a second mode: announce the attacker's source address toward the discard route and enable unicast reverse path forwarding (uRPF) on the edge. Packets whose source address resolves to the discard route fail the uRPF check and are dropped. RFC 5635 warns that this "will drop all traffic to/from the address, and not just the traffic to the victim," and it only helps when sources are few and not spoofed. NIST SP 800-189 describes S/RTBH as using loose uRPF for this purpose.

The BLACKHOLE community. RFC 7999 reserved 65535:666 (0xFFFF029A) as a well known community that asks a neighboring network to discard traffic to the tagged prefix. It is advisory and transitive. In a bilateral relationship, use "MUST be agreed upon by the two networks before advertising it." The receiver should add NO_EXPORT or NO_ADVERTISE so the blackhole does not leak further, and must only honor it when the announced prefix is covered by a prefix the neighbor is authorized to announce. Blackhole announcements are typically /32 or /128, far longer than the /24 and /48 limits most networks enforce, so RFC 7999 and NIST SP 800-189 Security Recommendation 62 both describe accepting longer prefixes only from customers and only when covered by an authorized shorter prefix. RFC 7999 also says operators must make sure route origin validation does not "inadvertently block legitimate announcements carrying the BLACKHOLE community."

Flowspec. NIST SP 800-189 Section 5.5 puts it this way: with Flowspec, "the basic principles of D/RTBH and S/RTBH are significantly enhanced and can be operationally deployed in a fine-grained, dynamic, and efficient way." Instead of dropping everything to 198.51.100.10, you drop UDP from source port 123 to 198.51.100.10, and the web site on port 443 keeps serving customers.

Comparison: ACLs, RTBH, Flowspec and scrubbing

Many networks combine them: Flowspec against well understood reflection floods, diversion to scrubbing when payload inspection is needed, and RTBH as the last resort when an attack is bigger than the upstream links and one target has to be sacrificed to protect its neighbors. Our NetFlow and IPFIX explainer covers the flow telemetry that usually triggers all three.

How Flowspec routes are validated

Any mechanism that lets a remote party install a filter in your forwarding plane needs an answer to the question "is this party allowed to filter that traffic?" RFC 8955 answers it by tying a Flowspec rule to the unicast route for the same destination.

The RFC 8955 rules

RFC 8955 Section 6 validates Flowspec received on SAFI 133 against unicast routes on SAFI 1, and SAFI 134 against VPN routes on SAFI 128. Without explicit configuration, a rule is feasible only if all three conditions hold:

• (a) The rule contains a destination prefix component.
• (b) The originator of the rule matches the originator of the best match unicast route for that destination prefix. Originator means the ORIGINATOR_ID attribute if present, otherwise the peer's address.
• (c) There are no more specific unicast routes, compared with the rule's destination prefix, received from a different neighboring AS than the best match route.

RFC 8955 also requires that for routes learned over eBGP, the AS_PATH contains the neighboring AS in the left most position. That check is optional for ordinary BGP, but RFC 8955 says "it becomes necessary to enforce it here for security reasons." Whenever the unicast table changes, every Flowspec rule has to be revalidated.

The reasoning is in the RFC's own explanation. The neighbor that announces the best route for a destination is the next hop for that traffic. If it asks you to drop the traffic, "that request can be honored without concern that it represents a denial of service in itself", because the traffic is effectively being dropped by the network it was going to anyway. Rule (c) closes a gap: if part of that destination range is reachable through a different neighbor, the first neighbor should not be able to filter traffic headed to the second.

Rule (a) may be relaxed by configuration to accept rules without a destination prefix. RFC 8955 says rules (b) and (c) are then "moot and MUST be disregarded." In other words, a rule with no destination matches traffic to anywhere and cannot be validated against anything. Only accept those from systems you fully control.

Why RFC 9117 revised validation

The RFC 8955 rules assume the router that sends a rule is the same router that announces the best unicast route. That fits the inter-domain case, where a customer's border router announces both. It does not fit the most common deployment inside a provider: a central DDoS controller or route reflector that is not in the forwarding path at all. RFC 9117 says that in this scenario "the validation procedure described in RFC 8955 will fail."

RFC 9117 (August 2021) makes two changes:

1. Rule (b) gets a second way to pass. A rule is also feasible if its AS_PATH is empty or contains only an AS_CONFED_SEQUENCE, which indicates it was originated inside the local domain. RFC 9117 says this condition "SHOULD be enabled by default" and may be disabled by configuration. It also allows policy to permit specific non empty AS paths, for example a set of ASes known to belong to the same organisation.
2. The AS_PATH check is redefined for route servers. Internet exchange route servers do not add their own AS to the path, so the RFC 8955 check that the neighbor AS is left most would always fail across a route server. RFC 9117 instead requires that the left most AS of the Flowspec route match the left most AS of the best match unicast route. It acknowledges that when the peer is a route server, "security is necessarily weakened for the Flow Specification NLRI, as it is for any unicast route advertised from a route server."

The practical consequence of change 1 is significant. Since RFC 9117, a correctly behaving router will by default accept a Flowspec rule from any iBGP speaker inside your AS, because empty AS_PATH means local. The protection that validation gave you against a misbehaving internal speaker is gone unless you disable the new condition or restrict which iBGP sessions carry the Flowspec family. RFC 9117 itself suggests disabling it if you know rules will never originate inside the local domain.

Why validation matters for inter-domain use

Between networks, Flowspec lets a customer or peer install filters in your routers, and validation is what limits them to their own traffic. RFC 8955's security section is direct: as long as rules are restricted to match the unicast paths for the relevant prefixes, Flowspec's security is "equivalent to the existing security properties of BGP unicast routing." Any relaxation "may allow unwanted Flow Specifications to be propagated" and "could open the door to further denial-of-service attacks, such as unwanted traffic filtering, remarking, or redirection."

Validation also inherits the weaknesses of unicast routing. If a neighbor can hijack a prefix, announcing reachability for address space it does not serve, it can then also pass Flowspec validation for that prefix. RFC 8955 names two mitigations: route origin validation with RPKI (RFC 6811) and BGPsec (RFC 8205). Our guide to getting an ASN and announcing your own prefix with RPKI walks through creating route origin authorizations, which is the foundation that makes Flowspec validation trustworthy for your own address space.

Finally, check whether your implementation validates at all. The FRRouting documentation states that "the validation procedure depicted in RFC 5575 is not available" in its implementation. Other daemons and router operating systems differ. If your receiver does not validate, your import policy is the only control, so write it as if validation does not exist.

What can go wrong: the operational risks of Flowspec

Flowspec moves firewall rules into the routing control plane. That is its strength and its main risk. RFC 8955's security section lists most of the failure modes itself.

A bad rule that drops everything

A Flowspec rule is applied at line rate on every router that accepts it, usually within seconds. A rule that is wider than intended has the same reach. Common ways it happens:

• A missing or wrong destination prefix, for example 0.0.0.0/0 instead of a /32, or a rule with no destination component at all on a network that accepts those.
• A rate of zero where a rate limit was intended, or a rate typed in bits that the platform reads as bytes, or a negative rate that the receiver must treat as zero.
• An OR where an AND was intended in a port range, as in worked example 2.
• A rule on Type 4 (any port) that catches legitimate traffic in the other direction.
• A packet length rule with no protocol component, which matches every protocol.

RFC 8955 also notes the debugging problem: "it is possible to allow TCP packets to pass between a pair of addresses but not ICMP packets," or to pass packets smaller than 900 octets and larger than 1000 but not those in between. When filters arrive dynamically and disappear on withdrawal, the operator debugging a strange outage at 3 a.m. may not know a Flowspec rule was ever involved. Log every rule with a timestamp and a ticket reference at the controller, and make the receiving routers' active Flowspec table part of your standard troubleshooting checklist.

Hardware filter table (TCAM) exhaustion

Routers implement Flowspec filters in the same hardware lookup resources they use for access lists and policers, usually ternary content addressable memory (TCAM) or an equivalent. Those resources are finite and shared. A complex rule with port ranges may expand into many hardware entries, because range matching is often implemented as several prefix style entries. RFC 8955 states that routers "are limited in terms of the maximum number of data elements they can hold as well as the number of events they are able to process in a given unit of time," and that providers "may need to limit the number of Flow Specifications accepted and processed."

Running out of filter space fails in implementation specific ways. Some platforms reject new rules, some program part of a rule, and some affect unrelated features that share the same table. Find out what yours does in a lab before an attack forces the question. Then set limits below the hardware ceiling: a maximum number of Flowspec routes per session, and a maximum rate of updates.

Rule ordering surprises

Because order is defined by RFC 8955 Section 5.1 and not by arrival time, the rule that wins is not always the one the operator most recently added. The algorithm compares components from the lowest type upward:

• If one rule has a component type the other lacks at that position, the one with the lower numbered type wins.
• For prefixes, the more specific prefix wins; if neither contains the other, the numerically lower prefix wins.
• For other components, the raw bytes are compared like memcmp: lower bytes win, and when one string is a prefix of the other, the longer string wins.

Worked example 4: an ordering surprise

Two rules are active:

• Rule A: destination 198.51.100.0/24, protocol UDP, rate 0 (discard UDP to the whole /24).
• Rule B: destination 198.51.100.10/32, rate 125,000 bytes per second (police one host to 1 Mbit per second), added later to protect a single server.

Both start with Type 1. Rule B's /32 is more specific than Rule A's /24, so Rule B has higher precedence for any packet to 198.51.100.10. Neither rule sets the T bit, so evaluation stops at the first match. Result: UDP flood traffic to 198.51.100.10 is no longer discarded by Rule A. It is policed to 1 Mbit per second by Rule B. The operator who added Rule B to be more careful has weakened the protection for that host. Fixing it means either adding protocol UDP with rate 0 to a /32 rule for that host, or setting the T bit on Rule B and confirming how your platform resolves the two rate actions when both apply.

Action interference

RFC 8955 Section 7.7 says conflicting actions on one rule, such as two traffic-rate-bytes communities, have no effect on BGP propagation, but when the rule is installed, "it is an implementation decision which of the interfering Traffic Filtering Actions are selected." A rule with both traffic-rate-bytes and traffic-rate-packets is legal, and RFC 8955 says a policy may allow both, but if it does not, they conflict. Keep one rate action per rule unless you have tested the combination on every platform in the path.

A compromised or buggy controller pushing filters network wide

The highest impact risk is the system that originates rules. Most networks run a controller: a detection system reads flow telemetry, decides an attack is under way, and tells a BGP speaker to announce a rule. RFC 8955 warns that "Flow Specification BGP speakers (e.g., automated DDoS controllers) not properly programmed, algorithms that are not performing as expected, or simply rogue systems may announce unintended Flow Specifications, send updates at a high rate, or generate a high number of Flow Specifications."

Since RFC 9117 makes rules with an empty AS path valid by default, an attacker who controls the controller, or any iBGP speaker with the Flowspec family enabled, can install filters on every edge router you have. They do not need to touch the routers themselves. That makes the controller host, its BGP speaker software, its API, and the software supply chain of both part of your network's control plane. Treat them with the same care as a route reflector:

• Run the controller on hardened, dedicated hosts, with management access restricted and logged.
• Authenticate BGP sessions to it (TCP Authentication Option or MD5, depending on what your platforms support) and restrict which routers accept the Flowspec family from which peers.
• Put a policy layer between detection and announcement: maximum prefix length checks (only /32 and /128 or only customer space), a deny list for your own infrastructure prefixes, a cap on concurrent rules, a default expiry, and human approval for anything wider than a single host.
• Keep the BGP speaker and controller packages patched and inventoried. They are ordinary open source software running on ordinary hosts.

Inter-domain specific risks

When you accept Flowspec from customers or peers, every risk above applies with someone else writing the rules. RFC 8955 recommends "only exposing a predefined subset" of actions to third parties, and for Internet exchange route servers it advises "a strict inbound route policy in such scenarios."

How to secure a Flowspec deployment

Bringing the pieces together, here is a control list you can map to your own network.

NIST SP 800-189 Recommendation 62 says to accept longer RTBH prefixes only from customers and only when covered by a route the customer is authorized to announce, with an IRR entry or a ROA. Apply the same test to Flowspec destination prefixes.

Step by step: announce, verify and withdraw a rate limit rule in a lab

This walkthrough uses two open source BGP daemons in an isolated lab: GoBGP as the rule originator (the controller side) and a second GoBGP instance as the receiver, so you can see the rule arrive, read its action, and apply a route limit. An optional step uses FRRouting as a receiver that installs rules into Linux Netfilter. All addresses are from the documentation ranges in RFC 5737 and the AS numbers are from the private range.

Lab only. Run this on two virtual machines or containers on a private network with no connection to production routers. Never enable the Flowspec family toward a production peer to experiment. A Flowspec discard rule that reaches a real edge router will drop real traffic.

Step 1: plan the lab

Install GoBGP from its release archives or your distribution's package on both hosts, and confirm the two hosts can reach each other on TCP port 179.

Step 2: configure the controller

On fs-ctl, create controller.toml. The neighbor block enables only the IPv4 Flowspec family, which is the address family name GoBGP's Flowspec documentation uses.

[global.config]
  as = 64512
  router-id = "192.0.2.1"

[[neighbors]]
  [neighbors.config]
    neighbor-address = "192.0.2.2"
    peer-as = 64513
  [[neighbors.afi-safis]]
    [neighbors.afi-safis.config]
      afi-safi-name = "ipv4-flowspec"

Start it and leave it running in its own terminal:

sudo gobgpd -f controller.toml

Step 3: configure the receiver with a route limit

On fs-rx, create receiver.toml. The prefix-limit block comes from GoBGP's configuration reference, where it sits under an address family. Here it caps the number of Flowspec routes this session will accept at 50, with a warning at 80 percent. In a real network you would choose the number from your hardware's filter capacity, leaving room for your own static filters.

[global.config]
  as = 64513
  router-id = "192.0.2.2"

[[neighbors]]
  [neighbors.config]
    neighbor-address = "192.0.2.1"
    peer-as = 64512
  [[neighbors.afi-safis]]
    [neighbors.afi-safis.config]
      afi-safi-name = "ipv4-flowspec"
    [neighbors.afi-safis.prefix-limit.config]
      max-prefixes = 50
      shutdown-threshold-pct = 80

sudo gobgpd -f receiver.toml

Check the session from either side. It should reach the Established state:

gobgp neighbor

If it does not, check that both sides list the same family. A Flowspec session where one side has only ipv4-unicast will come up for unicast and silently carry no rules.

Step 4: announce a rate limit rule

On fs-ctl, announce a rule that matches NTP responses (UDP source port 123) toward one lab host and polices them to 125,000 bytes per second, which is 1 Mbit per second. The syntax is from GoBGP's Flowspec CLI reference.

gobgp global rib -a ipv4-flowspec add match destination 198.51.100.10/32 protocol udp source-port '==123' then rate-limit 125000

Check it locally:

gobgp global rib -a ipv4-flowspec

You should see one entry with the destination, protocol and source port match and a rate action. GoBGP's syntax help lists rate-limit RATE [as AS], where the optional AS fills the informational ID field described earlier.

Step 5: verify it on the receiver

On fs-rx, list the Flowspec routes it has learned:

gobgp global rib -a ipv4-flowspec

The entry should show the same match fields and an extended community for the rate. Compare the rate shown on the receiver with what you typed. RFC 8955 defines this field in bytes per second, so 125000 here should mean 1 Mbit per second. If the number on the receiver is different, or your platform's documentation describes the unit differently, you have found a units mismatch in the lab instead of during an attack.

For a byte level check, capture the BGP session while you repeat step 4 and look at the UPDATE message:

sudo tcpdump -i any -nn -s 0 -w flowspec.pcap 'tcp port 179'

Open the capture in a protocol analyzer that decodes BGP. The MP_REACH_NLRI attribute should show AFI 1, SAFI 133, a next hop length of 0, and an NLRI starting 0c 01 20 c6 33 64 0a, the encoding from worked example 2. The extended communities attribute should contain 80 06 followed by two ID octets and 47 f4 24 00, the float for 125000.0 from worked example 3.

Step 6: test the limit

On fs-ctl, add rules in a loop, each for a different /32 inside the lab prefix:

for i in $(seq 11 70); do
  gobgp global rib -a ipv4-flowspec add match destination 198.51.100.$i/32 protocol udp source-port '==123' then rate-limit 125000
done

On fs-rx, watch the session and the count of received routes:

gobgp neighbor 192.0.2.1

As the count passes the warning threshold and then the maximum, the receiver should log a warning and then enforce the limit. Many BGP implementations tear the session down when a prefix limit is exceeded, which withdraws every rule learned on it. For Flowspec that is usually the safer failure, since a flood of rules is more likely a controller bug than a real need, but read your daemon's logs to see exactly what it did and decide what your production routers should do.

Clean up the extra rules:

for i in $(seq 11 70); do
  gobgp global rib -a ipv4-flowspec del match destination 198.51.100.$i/32 protocol udp source-port '==123'
done

Step 7: withdraw the rule

Withdraw the original rule using the same match, without the action:

gobgp global rib -a ipv4-flowspec del match destination 198.51.100.10/32 protocol udp source-port '==123'

On fs-rx, run gobgp global rib -a ipv4-flowspec again. The entry should be gone. In your packet capture, this appears as an MP_UNREACH_NLRI attribute carrying the same NLRI bytes. Time it: the gap between the command on the controller and the disappearance on the receiver is your best case withdraw time, and it is the number to put in your emergency runbook.

Step 8 (optional): install rules into Linux with FRRouting

FRRouting's documentation describes it as a Flowspec "client only": it receives rules and translates them into ipset, iptables mangle table entries and ip rule policy routes through its zebra daemon. It cannot originate rules. Replace the receiver with FRRouting and use the configuration from its documentation:

router bgp 64513
 neighbor 192.0.2.1 remote-as 64512
 address-family ipv4 flowspec
  neighbor 192.0.2.1 activate
  local-install eth1
 exit-address-family

The local-install line restricts installation to one interface. FRRouting's documentation says rules apply on all interfaces by default and that this can cause traffic to be filtered or "accounted for twice on multi-interface routers." Check what was received and installed:

show bgp ipv4 flowspec detail
show pbr ipset
show pbr iptable

Two limits from FRRouting's own known issues list are important here. First, a positive rate "is not used to apply shaping": the traffic is passed without any rate limit. Only a rate of zero (discard) and redirects are acted on, so to see an installed filter in this step, announce a rule with then discard instead of a rate limit. Second, if FRRouting crashes, stale ipset, iptables and ip rule entries may remain and must be cleaned up by hand. Add that cleanup to any runbook that uses it.

ExaBGP equivalent

ExaBGP is another open source BGP speaker used as a controller in many DDoS pipelines; its README lists centrally deploying blackhole and Flowspec filters as a use case and says the 5.0 branch is the stable release. Its example configuration expresses the same kind of rule in a block syntax:

flow {
  route ntp-police {
    match {
      destination 198.51.100.10/32;
      protocol udp;
      source-port =123;
    }
    then {
      rate-limit 125000;
    }
  }
}

The same lab checks apply: verify on the receiver, capture the update, and test withdraw times.

Common mistakes

• Thinking in bits when the field is bytes. RFC 8955 rates are bytes per second (or packets per second for the newer action). A rate of 1,000,000 is 8 Mbit per second.
• Assuming the terminal bit stops evaluation. In RFC 8955, setting the T bit makes the engine continue to later rules. Leaving it clear stops at the first match.
• Forgetting about fragments. Port, ICMP and TCP flag components never match non initial fragments. A port based rule leaves fragment floods untouched.
• Using Type 4 when you meant source or destination port. Type 4 matches either, which can catch your own outbound traffic.
• Adding a narrower rule that shadows a stronger one. As in worked example 4, a /32 rate limit can override a /24 discard for that host.
• Accepting Flowspec on every iBGP session. After RFC 9117, rules with an empty AS path validate by default. Enable the family only toward the speakers that should send rules.
• Trusting a receiver to validate without checking. At least one widely used open source implementation documents that it does not implement the validation procedure.
• No route limit on Flowspec sessions. RFC 8955 tells providers they may need to cap accepted rules; without a cap, a controller bug can fill filter tables.
• Accepting redirect and marking actions from customers. Non rate actions can steer traffic into other VRFs or queues. Remap or strip them at the border.
• No expiry. A rule added during an attack and never withdrawn becomes a mystery filter months later.
• Mixed implementations without testing. RFC 5575 era code may treat traffic-rate as non transitive, may not support packet rates, and may read ambiguous operator bits differently from RFC 8955 code.
• Treating the controller as a monitoring box. It is part of your control plane. Patch, harden and inventory it like one.

FAQ

What is BGP Flowspec used for?

Mostly DDoS mitigation: rules that drop, rate limit, redirect or remark specific attack traffic at every edge router within seconds. RFC 8955 also lists VPN traffic filtering and centralized SDN and NFV traffic control.

What is the difference between Flowspec and RTBH?

RTBH drops all traffic to (or, with uRPF, from) an address. Flowspec matches up to 13 header fields and can drop or police only the attack traffic, at the cost of hardware filter space for each rule.

What RFC defines BGP Flowspec?

RFC 8955 (December 2020) is the current IPv4 and VPNv4 specification. It obsoleted RFC 5575 (August 2009) and RFC 7674 (October 2015). RFC 8956 (December 2020) adds IPv6, and RFC 9117 (August 2021) revises the validation procedure.

What AFI and SAFI does Flowspec use?

IPv4 Flowspec is AFI 1, SAFI 133. VPNv4 Flowspec is AFI 1, SAFI 134. IPv6 Flowspec is AFI 2, SAFI 133, and VPNv6 is AFI 2, SAFI 134.

What does traffic-rate 0 mean in Flowspec?

Discard. RFC 8955 says a rate of zero should result in all matching traffic being discarded, and negative values must be treated as zero.

What is the BLACKHOLE community 65535:666?

A well known community reserved by RFC 7999 (October 2016) asking a neighbor to discard traffic to the tagged prefix. Bilateral use must be agreed in advance, and the receiver should add NO_EXPORT or NO_ADVERTISE.

Can Flowspec be used between different networks?

Yes, that was the original goal. The upstream validates that the rule's destination is covered by routes the downstream announces, restricts accepted actions and caps the number of rules.

Does Flowspec work with IPv6?

Yes, since RFC 8956, which adds prefix offsets, ICMPv6 matching, the Flow Label component and an IPv6 redirect community. Upper layer matching may fail behind long extension header chains.

What happens when a router runs out of Flowspec filter space?

It depends on the platform, so test it in a lab and set per session route limits below the hardware ceiling.

Is BGP Flowspec secure?

It is as secure as the validation, policy and controller around it. RFC 8955 says that with its validation in place, Flowspec has the same security properties as BGP unicast routing. Relaxing validation, accepting all actions from third parties, or running an unprotected controller opens the door to filters that deny service rather than prevent it.

Where Safeguard fits

Safeguard does not run on routers, does not originate or validate Flowspec rules, does not detect DDoS attacks, and does not analyze router firmware or network operating systems. The fit is with the software around Flowspec that your team builds and runs. The controller is usually a set of services: a flow collector, a detection engine, an API, and a BGP speaker such as ExaBGP (a Python package) or GoBGP (a Go module), packaged into container images. Safeguard scans those repositories, container images and SBOMs, lists the open source components and versions inside them, matches them against vulnerability databases, ranks findings by reachability, and can open fix pull requests (autonomous remediation ships switched off). When an advisory lands for a BGP library or a package your controller depends on, the platform shows which of your projects contain that component and version, so you know which controller images to rebuild.

Software supply chain hygiene still matters here because a Flowspec controller is ordinary software with dependencies, and a vulnerable package in the service that decides which filters to push sits one step away from every edge router you run. The fix paths below apply to those open source dependencies and container images, not to the routers' own operating systems, which still have to be patched through their vendors.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

This demo sets up the Safeguard runner on your own machine, approves it with its device code and scans from the terminal. Pointed at the container image of a Flowspec controller or detection service your team builds, the same scan lists the packages and versions inside it and their known vulnerabilities, so you know which images to rebuild after an advisory for a BGP library or one of its dependencies.

Click through it at your own pace, or open it full screen.

This demo is a real CLI session: ask it to fix the lodash CVE in a repository and watch it read the finding and the advisory, ask before each command, move lodash to 4.17.21, run npm install and npm test with your approval, and push nothing. The same approve each step flow applies when you bump a pinned dependency in the Python or Go service that feeds rules to your BGP speaker, where you want a human to see every change before it ships.

Click through it at your own pace, or open it full screen.

This demo connects Claude to the Safeguard MCP server with OAuth and lets you choose which tools Claude can use. You can then ask which of your projects ship a given package version, such as a specific ExaBGP release in your controller images, and get the answer from your own scan data rather than from memory.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• RFC 8955: Dissemination of Flow Specification Rules (December 2020)
• RFC 8956: Dissemination of Flow Specification Rules for IPv6 (December 2020)
• RFC 5575: Dissemination of Flow Specification Rules (August 2009, obsoleted)
• RFC 7674: Clarification of the Flowspec Redirect Extended Community (October 2015, obsoleted)
• RFC 9117: Revised Validation Procedure for BGP Flow Specifications (August 2021)
• RFC 7999: BLACKHOLE Community (October 2016)
• RFC 5635: Remote Triggered Black Hole Filtering with Unicast Reverse Path Forwarding (August 2009)
• RFC 6811: BGP Prefix Origin Validation (January 2013)
• IANA: Flow Spec Component Types registry
• NIST SP 800-189: Resilient Interdomain Traffic Exchange, BGP Security and DDoS Mitigation (publication page)
• NIST SP 800-189 full text (PDF)
• FRRouting documentation: Flowspec
• GoBGP documentation: Flow Specification
• GoBGP documentation: Getting Started
• GoBGP documentation: Configuration reference
• ExaBGP README
• ExaBGP example Flowspec configuration

Last reviewed: 24 October 2026. Flowspec implementations differ in which RFC revision they follow, whether they validate rules and how they handle conflicting actions; check your own platform's documentation before relying on any behavior described here.