Remote Blackholing and FlowSpec Distribution

A victim of a volumetric attack has a problem that no local filter solves: the traffic is arriving on links sized for normal demand, and the filtering device sits after the point where the link is already saturated. The only place the traffic can be dropped cheaply is upstream, at a router with more capacity than the attack. Getting a rule to that router is the hard part, because the upstream is a different administrative domain, often a different company. The mechanism that solved it reuses the one protocol that already carries instructions between autonomous systems: BGP.

The discard route

The original technique is a route announcement. The victim announces a more specific prefix with a special next-hop value that means “discard” rather than “forward to this address”. A router receiving such a route installs it with that next-hop, and packets forwarded to it are dropped at the router that made the decision: one lookup, no queueing, no per-flow state.

Two details make it work. The announcement must be more specific than the prefix actually in use, so that longest-prefix match selects it over the real route; a /32 for a single host, or a shorter prefix covering the attacked range. And the next-hop must be an address the receiving router will not try to resolve to a real neighbour. RFC 3882 describes the arrangement, including the recommendation to use an address from a reserved block as the discard next-hop so that the value is recognisable and does not collide with a real peer.

Because the route is more specific, it wins the lookup for every packet addressed into it. That is the point, and it is also the cost: all traffic to that prefix is dropped, not just the attack. The mechanism is therefore a blunt instrument that trades availability of the target for protection of the network around it. It is used when the target is already effectively down, or when the attack is so large that the collateral is cheaper than the congestion.

The variant that avoids announcing a route is to attach a well-known community to an existing announcement. RFC 7999 defines the BLACKHOLE community, with the value 65535:666, meaning “drop traffic for this prefix”. A customer announces its own prefix with that community, and a provider configured to honour it installs the discard behaviour without the customer needing to control a more specific route. The advantage is that the trigger stays inside the customer’s existing announcement, so the origin is unambiguous and no additional prefix appears in the global table.

Why the trigger has to be authenticated

A mechanism that lets one party cause traffic to another party to be dropped is a denial-of-service primitive. Everything about the operational design is about constraining who can pull that trigger.

The first constraint is authorisation by prefix. A network should only honour a discard trigger for prefixes its customer is entitled to announce. Without that check, a customer can blackhole a competitor’s address space. Providers enforce it by filtering on the origin autonomous system and on a prefix list, and by accepting triggers only from the customer’s own sessions.

The second constraint is scale. If every customer could blackhole arbitrary flow specifications, the provider’s routers would carry an unbounded rule set built from untrusted input. Rate limits on triggered announcements and a cap on the number of installed filters per peer are the usual controls, and both are necessary: the filters are evaluated in the forwarding path, and their number is a direct cost on every packet.

The third is that the trigger must not leak. A discard route announced to one upstream but propagated to others, or a FlowSpec rule accepted from a peer and re-announced, turns a local mitigation into a network-wide outage. Route policy has to treat these announcements as strictly scoped, and the same origin authorisation that RFC 6811 defines for ordinary announcements applies to discard routes: the origin autonomous system must be the one entitled to the prefix, or the route is not installed.

FlowSpec: matching instead of all traffic

The bluntness of the discard route is what FlowSpec fixes. RFC 8955 defines an address family whose NLRI encodes a match on packet header fields together with an action, distributed by BGP. A router that receives a FlowSpec rule compiles it into its filter path, so a provider can drop, rate-limit, or redirect a specific class of traffic without affecting the rest.

The match is expressed as a list of components, each identified by a type code:

Type	Component	Example use
1	Destination prefix	the attacked service
2	Source prefix	a specific attack source range
3	IP protocol	UDP only
4	Port	either port
5	Destination port	the service port
6	Source port	a spoofed source port range
9	TCP flags	SYN-only floods
12	Fragment	drop non-initial fragments

The action is carried in extended communities: discard, rate-limit to a specified bandwidth, mark a DSCP, or redirect into a routing instance. Redirection is what makes scrubbing practical, because the provider steers the matched traffic into a cleaning environment and returns the cleaned flow, without changing the customer’s announcement.

Components combine conjunctively, so a rule with destination prefix, protocol, and destination port matches the intersection. That is expressive enough to describe most attacks and small enough that the compiled filter stays cheap. A rule that matches on source prefix is the most dangerous kind, because the source is attacker-controlled and often spoofed; a rule keyed on a spoofable field is an invitation to have legitimate traffic dropped by a forged header.

Validating a rule before installing it

FlowSpec’s failure mode is a rule that drops traffic it was not meant to. The specification addresses this with a validation requirement: a rule’s destination prefix must be covered by a route the announcing party originates. The check is a subset test between the rule’s prefix and the set of prefixes the peer is authorised to announce.

import ipaddress

def rule_is_valid(rule_prefix, authorised_prefixes):
    r = ipaddress.ip_network(rule_prefix)
    for p in authorised_prefixes:
        p = ipaddress.ip_network(p)
        if r.version != p.version:
            continue
        if r.subnet_of(p):
            return True
    return False

The check is one line of reasoning and it is where implementations diverge. A rule for 192.0.2.0/25 under an authorised 192.0.2.0/24 is valid; a rule for 192.0.2.0/23 is not, because it covers address space outside the authorisation even though it overlaps it. Rules that specify no destination prefix at all, matching only on protocol and port across the whole table, cannot be validated this way, which is why the specification restricts them.

The same logic applies to the redirect action. A redirect target is a route target community naming a VRF; accepting an arbitrary target from a peer would let the peer inject traffic into any instance on the router. The target must be checked against what the peer is allowed to use, and it must be checked before the rule is compiled, not after.

What the mechanism accepts

Four costs are inherent rather than fixable.

Propagation delay. A BGP update takes time to reach every router in the provider’s network, and the path from the trigger to the edge is not instantaneous. For a fast attack the mitigation arrives after the peak, which is why the trigger is usually automated from a monitoring signal rather than issued by a human. The monitoring signal is the part that fails under novel attacks: a threshold tuned to volume misses a low-volume attack that is nonetheless service-affecting.

Filter capacity. Every installed rule occupies space in a forwarding structure that is sized for a small number of entries. FlowSpec deployments limit the count per peer and per address family, and a rule that cannot be installed is silently not enforced unless the router reports it. The reporting is the operational lifeline here; without it a mitigation appears to be in place and is not.

Loss of observability. Traffic dropped upstream never reaches the customer’s sensor. During a mitigation the flow records and alerts from the affected prefix go quiet, which reads identically to the attack having stopped. The provider’s own counters are the only evidence available, and they are not usually exported to the customer.

Collateral. A discard rule removes legitimate traffic along with the attack. Rate-limiting instead of discarding is the softer option and produces a different failure: under a large attack the legitimate traffic is squeezed to the configured rate, so the service degrades rather than disappears. Which of the two is preferable depends on whether the service has any value while saturated, and that is a business decision expressed as a rule.

Where it sits in the defence

Remote blackholing is the outermost layer, and it exists because the alternative, absorbing the traffic locally, requires capacity proportional to the largest attack, which is not a stable target. Inside the network, the same traffic is subject to the ordinary filtering described in How a Stateful Firewall Matches a Packet, and the evidence that an attack is happening comes from the telemetry in Flow Records and Traffic Baselining. The three are not alternatives; the flow data detects, the local filter handles what fits through the link, and the upstream rule handles what does not.

The residual risk is that the trigger becomes a target. An attacker who can cause a victim’s monitoring to cross a threshold, or who can forge the announcement that carries the trigger, can use the victim’s own mitigation against it. That is why the trigger path is authenticated, rate-limited, scoped by prefix authorisation, and logged. These are the same controls that any remote administration channel needs, applied to a channel whose failure mode is a network outage.