Four classes of BGP attack still have no cryptographic defense, and the May 2025 Prefix-SID incident proved it

May 20, 2025. A BGP UPDATE carrying a corrupted Prefix-SID attribute — optional transitive, code 40 — is originated by an AS in the Asia-Pacific region. Ten seconds. How long the global routing system took to absorb more than 150,000 updates and watch sessions flap at Starlink, Disney, Zscaler, and ByteDance. July 2026. A survey published in IEEE Communications Surveys & Tutorials finally maps the problem in full. The verdict fits one sentence: RPKI and ASPA cover only two of the eight BGP attack subcategories on record.

For a network operator, that is the difference between a verifiable defense — “check the ROA and drop invalid” — and a local one — “I have a prefix limit and I hope.”

What the May 2025 incident was not

The May 20, 2025 event was neither a hijack nor a leak. Cisco IOS-XR and Nokia SR-OS did what RFC 7606 prescribes: they discarded the malformed attribute and moved on. Juniper JunOS passed it along intact. The Arista routers that received it answered by resetting their BGP sessions. Route servers at several IXPs relayed the attribute onward without filtering it.

Nothing RPKI validates was violated at any point in that chain. Ask an operator to classify the event and you get a shrug: “not a hijack, not a leak, something with an attribute.” Arista fixed the behavior in EOS 4.28.11 and later — but the blind spot stayed.

That is precisely the kind of incident a survey published this summer in IEEE Communications Surveys & Tutorials (DOI 10.1109/COMST.2026.3714569, a collaboration between Sapienza University of Rome, Namex, and the Italian National Cybersecurity Agency, ACN) set out to classify. It revisits the open questions posed in 2011 by Huston, Rossi, and Armitage and asks what has actually changed in fifteen years.

Four families, eight subcategories

The survey’s contribution is not new attacks — most of the distinctions already exist in RFCs and operational practice — but a single structure with consistent naming. Four macro-categories, eight micro-categories:

• Route manipulation: prefix hijacking (PRH) in its complete, incomplete, interception, and abusive variants, plus AS_PATH manipulation (ASM) — poisoning, forged-origin injection, path shortening, and path extension.
• Routing consistency: state volatility (VOL) — disruptive flapping, oscillation flooding, amplified churn injection, delayed convergence — and prefix deaggregation (DEG).
• Policy violation: route leaks (RLK) in the four directions defined by RFC 7908, and policy manipulation (POL) via Local Preference, MED, AS_PATH length, and selective propagation.
• Session-based: attribute-based session reset (ATR) — malformed optional-transitive-attribute injection, vendor-specific exploitation, and error-handling-policy abuse. This is where the May 2025 event lives.

The taxonomy’s value is that it makes every class mappable: you can now ask “which defense covers which class” and get a clean answer, instead of evaluating each mechanism in isolation.

Where coverage actually exists

Laying the defenses over that grid produces a lopsided picture, easy to miss when you judge each mechanism alone.

PRH is the success story, with caveats. IRR and RPKI provide origin validation, and ROA coverage keeps climbing. But coverage is not enforcement: a longitudinal study across more than 28,000 ASes found 36.2% do not implement ROV at all, and only 12.3% reach full protection. Permissive maxLength widens the attack surface instead of narrowing it — hence RFC 9319.

ASM is partially addressed in principle and barely at all in practice. BGPsec exists, is implemented, and remains essentially undeployed: a single non-adopting AS in the path strips the security information, which makes partial deployment close to worthless.

RLK is the most encouraging front. ASPA objects have been publishable in RIR repositories since December 2025 — 1,314 registered at the time of writing — and deployment by strategically placed ASes could cut the number of ASes affected by leaks by up to 96%. The OTC attribute and the Down Only community, both building on the roles in RFC 9234, could suppress over 98% of multi-hop leaks if adopted selectively across well-connected Tier-1 and Tier-2 networks.

The four classes with no cryptographic answer

VOL, DEG, POL, and ATR have no cryptographic answer. Not a partially deployed one: none. They are handled by operational hardening — control-plane policing, prefix limits, prefix-length filters, policy hygiene, robust error handling, and attribute filtering at route servers. All of it is local, reactive, and unverifiable by the party that suffers the consequences.

There is no equivalent of “check the ROA and drop invalid,” no global state anyone can query. When an operator asks whether they are protected against a deaggregation flood from a peer, the honest answer is: you have a prefix limit and a hope.

Two things have shifted the risk. The first is IPv6 arithmetic. Deaggregation abuse in IPv4 is bounded by what the attacker actually holds. In IPv6 it is not: within a single /29, up to 524,288 distinct /48s can be generated and announced, while the global IPv6 BGP table holds roughly 219,000 entries. One allocation, one router, and the table more than doubles — and the defense, a static prefix limit, also breaks legitimate growth if set too tight, which is exactly why operators set it loose.

The second is the economics of attacker attention. As ROV enforcement grows, the marginal return on prefix hijacking falls and the marginal return on the classes nobody validates rises. That is the ordinary effect of a control that covers one thing well: it redirects effort elsewhere.

What to do

The action splits along one line: whether or not you operate an AS.

If you operate an AS, start by measuring your real exposure. Your ROV coverage and any ASPA records protect only two subcategories out of eight. For the other four, protection is a list of local controls you must harden, not assume: a per-peer prefix limit with a threshold that does not throttle legitimate growth, prefix-length filters consistent with what you actually announce, control-plane policing on eBGP sessions, and RFC 7606-compliant error handling so a malformed attribute never becomes a session reset.

If you buy transit or cloud, the question for your provider is no longer “do you run RPKI” — nearly everyone says yes now — but “what happens when a peer sends you a malformed attribute or a deaggregation flood?” A provider that cannot answer precisely is only protecting you across half the spectrum of routing incidents.

Verdict

RPKI and ASPA have solved — partially — hijacking and leaking. The other four classes of BGP attack are still defended by local practices no one can verify remotely, and the May 20, 2025 Prefix-SID incident showed their cost is measured in ten seconds and 150,000 updates, not in days.

The survey’s underlying signal is blunt: in fifteen years, the “optimal” solutions (S-BGP, soBGP, psBGP) went nowhere, and “good enough and deployable” won every time. The next real improvement will not come from new cryptography but from systematic operational hardening on the classes cryptography will never touch — and from demanding transparency from your transit providers.

References

• RIPE Labs — Beyond Origin Validation: Four Classes of Routing Attack Nobody Is Validating, Antonio Prado, July 21, 2026
• IEEE Communications Surveys & Tutorials — Survey on Internet Routing Security, DOI 10.1109/COMST.2026.3714569, 2026
• RFC 7606 — Revised Error Handling for BGP UPDATE Messages, IETF
• RFC 9234 — Route Leak Prevention and Detection Using Roles, IETF, May 2022
• RFC 9319 — The Use of maxLength in the RPKI, IETF