Summary

  • RFC 8955 lets BGP carry traffic-matching rules and actions, but its default validation ties permission to the originator of the best matching unicast route and requires the rule to be reconsidered when that route changes.
  • Susan Hares co-authored RFC 8955 and edited its IPv6 companion, RFC 8956. RFC 9117, written by a different author group, later relaxed validation inside one local domain for central-controller and route-server designs; it did not create a general right to filter across domains.

A route that can change the treatment of packets

BGP is normally described as a system for exchanging reachability. FlowSpec adds a more operationally forceful vocabulary. Its Network Layer Reachability Information can match a destination or source prefix, protocol, port, ICMP fields, TCP flags, packet length, DSCP or fragment properties. Extended communities can then attach actions: impose a byte or packet rate, set a terminal or sampling behaviour, redirect traffic using a route target, or mark packets. A rate of zero means discard.

The legitimate use is immediate. During a denial-of-service attack, an operator may need to distribute one precise rule across many routers faster than technicians can configure every box. VPN filtering and centrally managed network functions create similar demand. The same capability, however, is not simply another route. A mistaken or unauthorised reachability announcement can misdirect traffic; a mistaken FlowSpec announcement can directly change how matching traffic is treated.

The official IETF Datatracker profile for Susan Hares records her long standards participation. For this narrower story, the relevant documentary chain is exact. RFC 8955, published on the Standards Track in December 2020, credits Christoph Loibl, Susan Hares, Robert Raszuk, Danny McPherson and Martin Bacher. It revises the original IPv4 FlowSpec specification and obsoletes RFC 5575 and RFC 7674. RFC 8956, the IPv6 extension, names Loibl, Raszuk and Hares as editors.

That is a contribution within a collective IETF result, not a claim that Hares singly invented FlowSpec or controls its deployment. The distinction matters because the standards themselves distribute authority: one speaker originates a rule, another network validates it, and local policy decides whether and how it reaches forwarding hardware.

Deterministic order is not sufficient authority

RFC 8955 defines how overlapping FlowSpec rules are ordered so implementations can reach a consistent result. It also says that a match without an attached action is accepted by default. Those details make the rule language predictable. They do not answer the more consequential question: why should this particular BGP neighbour be allowed to make this particular treatment request?

The default validation procedure answers by borrowing authority from ordinary unicast routing. A FlowSpec rule containing a destination prefix is checked against the best matching unicast route. The rule's originator must match that route's originator, and a more-specific route from another neighbouring autonomous system can invalidate the request. For an external BGP speaker, the left-most autonomous system in the FlowSpec path is also checked against the left-most AS in the unicast path.

This is not cryptographic proof of benign intent. It is a scope test. A neighbouring AS already sits on the immediate path toward the relevant destination and could discard traffic after receiving it. Allowing it to ask its upstream to discard or rate-limit the same traffic earlier can spare capacity, but the request derives its legitimacy from that destination path. The rule is not accepted merely because it has valid BGP encoding.

The dependency is dynamic. RFC 8955 requires FlowSpec validation to be repeated whenever the corresponding unicast route changes. If a destination moves to a different origin or a more-specific route appears through another neighbour, the earlier basis for action may disappear. Permission therefore follows current topology rather than becoming a permanent property of the rule.

The local controller problem

Centralised control exposes a limitation. A controller inside an operator's own domain may legitimately distribute mitigation rules without appearing on the best forwarding path to every affected prefix. Under the strict default test, useful rules from that controller can fail precisely because it is a controller rather than a transit hop.

RFC 9117, published in August 2021, updates RFC 8955 for that case. Its authors are Jeffrey Uttaro, Jorge Alcaide, Clarence Filsfils, David Smith and Pradosh Mohapatra—not Susan Hares. The later document belongs in this story because it reveals how the authority boundary evolved after the standard Hares co-authored.

The relaxation is bounded. Within the same local administrative domain, an operator may explicitly trust a central route controller and skip the origin validation that assumes the originator lies on the forwarding path. RFC 9117 also clarifies AS-path handling where a route server distributes FlowSpec routes without behaving like a conventional transit router. It does not turn any remote controller into a universal filtering authority. Inter-domain propagation remains subject to the stronger validation model unless the receiving operator deliberately adopts a different policy and accepts the risk.

That boundary separates two statements that are often blurred. “This device is authorised by my organisation to program my network” is a local governance decision. “This neighbouring network may ask mine to affect traffic for a destination” is an inter-domain coordination claim. The first can be configured by one operator. The second needs a defensible relationship to routing state and an explicit receiver policy.

Actions magnify both utility and error

RFC 8955's security discussion is unusually practical. Relaxed validation may permit unwanted filtering, remarking or redirection. Non-rate actions can alter forwarding, place traffic into another VPN context or change queue treatment. A broken or compromised controller can emit high update rates, exceed platform capacity or install a syntactically correct rule with a disastrous match.

The receiver therefore needs more than a pass/fail parser. Border policy may allow only a subset of actions. Prefix and port ranges can be constrained. Rate limits, redirect targets and rule counts need bounds. Route-server deployments require particular care because the path attributes may not express authority in the same way as direct bilateral EBGP. Hardware capacity also matters: a router that accepts the route into BGP may still fail to install it in the forwarding table.

Publication of an RFC proves none of these operational facts. It does not show that a vendor supports every component, that an operator enabled the feature, that policy is equivalent across routers, or that a mitigation succeeded. The standards define interoperable meaning and default safety logic. Running networks still have to demonstrate the result.

A small syntax with a local decision surface

Lu Heng's essay on Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption offers a useful analytical frame. FlowSpec's shared layer can remain narrow: common match components, common action encodings, deterministic ordering and a default validation relationship to unicast routing. The receiving network retains the future decision surface—accepted peers, allowed actions, controller trust, capacity limits, logging and withdrawal policy.

The mechanism becomes dangerous when a shared syntax is mistaken for central permission. It becomes ineffective when every implementation gives the syntax a different meaning. The workable middle is a small interoperable grammar whose consequences are authorised and observed locally.

Running-Code Primacy sharpens the test. The decisive evidence is not that a rule appears in a control-plane table. Operators must verify validation state, selected rule order, forwarding installation, counters for matched packets, the actual action, the affected services, withdrawal and recovery. They should test what happens when the unicast route changes, because that is when authority must be recalculated. These later essays are Sofia Ren's interpretive lens; they are not positions attributed to Hares or to the RFC authors.

FlowSpec is most trustworthy when the network can answer three questions for every consequential rule: who originated it, what current routing fact gives that originator standing, and which local policy allowed the requested action. Hares's place in the documentary chain helps illuminate that discipline. The filter earns the right to act not by being powerful, but by remaining bounded, revocable and accountable to current state.

Sources