Summary

  • An internal routing domain sent a large volume of prefixes into a data-centre backbone. The routes carried a legitimate BGP community, passed the ingress route-map and spread across the internal mesh; aggregation routers ran out of memory and their routing daemons restarted.
  • Daria Shantalova’s RIPE 93 proposal separates three checks: what a prefix is, where it may cross, and whether production routing state still matches the intended record.
  • The presentation says nearly all observed violations were removed within months, but publishes no starting count, residual count or dated series.

The tag checked out. The routes did not.

The awkward detail in Daria Shantalova’s RIPE 93 incident report is that the bad routes wore a valid badge. An adjacent internal routing domain sent a large number of prefixes toward the Express Backbone connecting data centres. Each prefix carried a BGP community assigned to that domain. The ingress route-map recognised the community and let the routes through.

They then travelled across the internal BGP mesh. Data-centre aggregation routers received the full set; their routing daemon exhausted memory and restarted. The public presentation gives no prefix total, router count or outage duration. It does give the more useful failure mechanism: the filter checked whether the community belonged to the sending domain, not whether each advertised prefix was authorised to cross from that domain into the backbone.

That is a permission gap disguised as a tagging success. A community can identify an origin domain or describe a route’s scope. It does not magically turn every prefix carrying that value into an approved route at every boundary.

Three controls, three different questions

Shantalova’s distinction matters because familiar safeguards are often asked to do jobs they were not built to do. A maximum-prefix limit asks how many routes arrived. A prefix permit list asks which routes may enter. A community filter asks whether a tag is recognised or should be retained. These checks can sit together, but they are not substitutes for one another. RFC 7454 discusses prefix filtering, maximum-prefix limits and community scrubbing as separate BGP operations controls; RFC 4271 defines how BGP exchanges reachability and makes routing decisions.

The proposed design starts with identity. Each prefix receives one BGP ID community describing its origin domain and allowed propagation scope. Missing, incorrect, multiple or conflicting IDs count as violations. Next comes authority: an internal Route Registry records the intended origin domain and ID for each prefix, then generates inbound filters for every domain boundary. Finally comes reality: production RIB data is collected continuously and checked against the registry for unregistered prefixes, bad or absent IDs and drift from the intended state. Deviations generate monitoring and alerts.

The sequence is plain: label the route, decide where that route is allowed, then check what the routers actually accepted. The registry holds intent; the RIB shows the live control plane. Neither a dashboard nor a one-time configuration export can stand in for that comparison.

“Nearly all” is a result with its denominator missing

The RIPE abstract reports that the team removed “nearly all” observed violations within months and says automated enforcement prevents recurrence. That is a concrete claim from the presentation, but the slides provide no initial count, exact remainder, dated violation series, enforcement coverage or incident duration. A published before-and-after series, including the number of protected boundaries, would show how much of the improvement came from cleanup and how much from automated enforcement.

For operators, the lesson is not “add another filter” and declare victory. It is to give each control one job and make the hand-off inspectable. The route must carry an interpretable identity; the boundary must compare the actual prefix with an authorised list; and monitoring must catch a mismatch after deployment. When a valid tag is mistaken for a complete permission, the routing system can be perfectly consistent about accepting the wrong thing.

Sources: RIPE 93 session and abstract; official text transcript; original presentation slides; RFC 4271; RFC 7454.