Beyond Origin Validation: Four Classes of Routing Attack Nobody Is Validating | RIPE Labs

Antonio Prado

Beyond Origin Validation: Four Classes of Routing Attack Nobody Is Validating

Antonio Prado(community contributor)

Antonio Prado

Based in ITALY

Antonio Prado holds a Ph.D. in Computer Science, with a research focus on Internet Routing Security. His doctoral work focused on tools and methodologies for the automated verification of BGP configurations. He is co-author of BGP from Theory to Practice, a book aimed at both technical and academic audiences, and … More

Contributors:

Flavio Luciani,

Stefano Servillo,

Pietro Spadaccino,

Marco Centenaro,

Massimiliano Rossi,

Monica Scannapieco,

Francesca Cuomo

8 min read — 21 Jul 2026

bgp

rpki

internet attacks

116

Click to like, and right click to unlike this article.

Share

Share

X/Twitter<br>LinkedIn<br>Facebook<br>Mastodon<br>Vkontacte<br>Telegram<br>Whatsapp<br>Email<br>Copy link

More

RPKI has made real progress against prefix hijacking. But when you map every known class of BGP attack against the defences that exist, four of them turn out to sit entirely outside cryptographic validation: handled with local filters, static thresholds and reactive response.

Ten seconds in May<br>On 20 May 2025, a BGP UPDATE carrying a corrupted Prefix-SID attribute, optional, transitive, attribute code 40, was originated by an AS in the Asia-Pacific region. What happened next was not a hijack and not a leak.<br>Cisco IOS-XR and Nokia SR-OS did what RFC 7606 says: they discarded the malformed attribute and moved on. Juniper's JunOS passed the message along intact. Arista routers that received it responded by resetting their BGP sessions. Route servers at several IXPs relayed the attribute onward without filtering it. Within ten seconds the global routing system saw more than 150,000 updates, and sessions flapped at Starlink, Disney, Zscaler and ByteDance among others. Arista changed the behaviour in EOS 4.28.11 and later releases.<br>Nothing that 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". That is a reasonable proxy for how much attention this class of problem has received.<br>That gap was one of the starting points for a survey we have just published in IEEE Communications Surveys & Tutorials, which revisits the open questions posed in Huston, Rossi and Armitage's 2011 routing security survey and asks what has actually changed in fifteen years. This article is about the part of the answer that surprised us.

Four macro-categories<br>We ended up with a taxonomy of four macro-categories and eight micro-categories. The contribution is not new attack notions - most of these distinctions already exist in RFCs and in operational practice - but a single structure with consistent naming, so that every class can be systematically mapped onto the defences that address it.

BGP Attack Categorisation

Route Manipulation : unauthorised modification of prefix or path information. Prefix hijack (PRH) in its complete, incomplete, interception and abusive variants; AS_PATH manipulation (ASM) covering poisoning, forged origin injection, path shortening and path extension.<br>Routing Consistency : attacks on the stability of the table rather than its contents. State volatility (VOL): disruptive flapping, flooding through oscillation, amplified churn injection, delayed convergence. Prefix deaggregation (DEG): malicious, careless, exploitative, and the fragmentation flood.<br>Policy Violation : routing leaks (RLK) in the four directions defined in RFC 7908, and policy manipulation (POL) via Local Preference, MED, AS_PATH length and selective propagation.<br>Session-based : attribute-based session reset (ATR): malformed optional transitive attribute injection, vendor-specific attribute exploitation, error-handling policy abuse. This is where the May 2025 event lives.

Where the coverage actually is<br>Laying the defences over that structure produces a lopsided picture that is easy to miss when you evaluate any single mechanism on its own.<br>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 that 36.2% do not implement ROV at all, and only 12.3% achieve full protection. Permissive maxLength widens the attack surface rather than narrowing it (hence RFC 9319). And abusive hijacking of unannounced space remains entirely feasible where objects aren't maintained.

Trend of unique IPv6 address prefix/origin AS pairs.

ASM is partially addressed in principle and barely at all in practice. BGPsec exists, is implemented, and is essentially undeployed: a single non-adopting AS in the path strips the security information, which makes partial deployment close to worthless.<br>RLK is where the most encouraging movement is. ASPA objects have been publishable in RIR...