Automated BGP mitigation, and the risk that comes with it
When an attack grows past what host-level firewalls can absorb, the answer is to push mitigation up into the routing layer. Flowtriq's BGP mitigation engine does this automatically: as an attack escalates, it announces FlowSpec rules to rate limit or drop the offending traffic, and at the top of the ladder it can announce a remotely triggered blackhole, an RTBH route, so the attacked address is dropped across the network before the flood ever reaches you.
That automation is exactly what you want at 3 a.m. during a multi-gigabit flood. But BGP is a protocol built on trust, and an automated system that announces routes has to be careful about what it announces. An incorrect or unexpected announcement does not just fail quietly. It can leak a prefix you do not own, draw an upstream rejection, or get your BGP session shut down for sending something the peer did not expect. Today we are announcing two features that make the BGP engine both safer about what it announces and more precise about how.
RPKI: validating a prefix before announcing it
RPKI, the Resource Public Key Infrastructure, is the system that cryptographically links an IP prefix to the autonomous system allowed to originate it. A resource holder publishes a Route Origin Authorization, a ROA, that says in effect: prefix 203.0.113.0/24 may be originated by AS64500, and nobody else. A router or validator can then check any route announcement against the ROAs and label it valid, invalid, or notfound.
An invalid result is a serious signal. It means a route is being announced for a prefix in a way the legitimate holder never authorized. That is the fingerprint of a route leak or a hijack, and it is also something an automated mitigation system should never do by accident.
Flowtriq now performs an RPKI check before any prefix announcement. When the engine is about to announce a unicast route, a blackhole or a scrubbing diversion, it first validates the target prefix against RPKI by querying a public RPKI validator. The outcome decides what happens next:
- Invalid: the announcement is blocked. The rule is marked failed, the event is logged, and a notification is dispatched. A leaked or hijacked prefix is never announced into BGP.
- Valid, notfound, or unknown: the announcement proceeds normally.
There is one design choice in here worth calling out, because it is deliberate. The check is fail-open. If the RPKI validator itself cannot be reached, the announcement still proceeds. This matters because the RPKI check runs at the worst possible moment, in the middle of an active attack. A validator outage must never become the reason your mitigation does not fire. RPKI here is a guard against announcing something demonstrably wrong, not a gate that can lock you out of defending yourself.
Only an explicit RPKI-invalid result blocks an announcement. Silence from the validator does not. The engine refuses to announce a prefix it knows is bad, and never refuses to act simply because it could not get an answer in time.
RPKI validation is controlled by a per-adapter toggle, and it is on by default. FlowSpec rules are exempt from the check, because a FlowSpec rule filters traffic rather than announcing a prefix, so prefix origin validation does not apply to it.
BGP Large Communities: precise signaling to upstreams
The second feature is about precision. BGP communities are tags attached to a route that tell other networks how to treat it. They are the standard mechanism behind operator services like "tag a route with this community and we will blackhole it for you" or "tag a route this way and we will steer it through scrubbing."
The classic BGP community, however, is two 16-bit numbers. That format predates 32-bit autonomous system numbers, and a 16-bit field simply cannot hold a modern 32-bit ASN. Operators with 32-bit AS numbers could not be cleanly represented. RFC 8092 fixed this by defining the BGP Large Community: three 32-bit fields, written as asn:value1:value2. The first field comfortably holds any ASN, and the remaining two carry the function and parameter the operator defines.
Flowtriq can now attach BGP Large Communities to its announcements. That means when the engine announces an RTBH route or a FlowSpec rule, it can carry exactly the community tags your upstreams expect, so the announcement does not just reach them, it instructs them. A blackhole announcement can be tagged for a transit provider to drop nationwide. A FlowSpec rule can be scoped with a community that selects which routers act on it.
A large community is validated and stored as a comma-separated list. Each entry is three unsigned 32-bit integers:
# A transit provider's RTBH trigger community 65000:666:0 # Several large communities on one announcement 64500:100:1, 65000:666:0, 64500:200:443
Communities can be configured at two levels. An adapter can carry a default set of large communities applied to everything it announces, and an individual rule can carry its own set, which overrides the adapter default when present. The values flow into announcements for the adapters that support communities: ExaBGP, GoBGP, BIRD 2, and FRRouting.
Why the two features belong together
RPKI validation and Large Communities solve different halves of the same problem. RPKI is about safety: never announce a prefix that is demonstrably not yours to announce. Large Communities are about precision: when you do announce, say exactly what you mean to every network downstream of you.
Together they make automated BGP mitigation something you can leave running without nervously watching it. The engine will not announce a hijacked or leaked prefix, and the announcements it does make are tagged so your upstreams act on them correctly and immediately. That is the combination that lets a small team trust a system to handle a multi-gigabit attack at 3 a.m. without a human in the loop.
Turning it on
Both features live in the mitigation adapter configuration. When you set up or edit a BGP adapter, you will find the RPKI validation toggle, already enabled, and a field for the default large communities that adapter should attach. Per-rule communities are available when you create a manual mitigation rule. Existing adapters keep working unchanged: RPKI validation simply begins guarding their announcements, and communities stay empty until you choose to set them.
Automated BGP mitigation you can trust to run unattended. Flowtriq's mitigation engine validates prefixes with RPKI before announcing and tags announcements with BGP Large Communities for precise upstream signaling. Start a free 7-day trial at flowtriq.com/signup.