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
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.
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.
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.
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
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.
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.
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.
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.
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
Laying the defences over that structure produces a lopsided picture that is easy to miss when you evaluate any single mechanism on its own.
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.
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.
RLK is where the most encouraging movement is. ASPA objects have been publishable in RIR repositories since December 2025 (1,314 of them registered at the time of writing) and analysis suggests that deployment by strategically positioned 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 defined in RFC 9234, could suppress over 98% of multi-hop leaks if adopted selectively across well-connected Tier-1 and Tier-2 networks.
VOL, DEG, POL and ATR have no cryptographic answer at all. Not a partially deployed one: none. They are addressed with operational hardening, control-plane policing, max-prefix limits, prefix-length filters, policy hygiene, robust error handling, and attribute filtering at route servers. All of these are 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 fragmentation flood from a peer, the candid answer is: you have a max-prefix limit and a hope.
Why the uncovered classes matter more than they used to
Two things have shifted the risk profile.
The first is IPv6 arithmetic. Deaggregation abuse in IPv4 is bounded by what the attacker actually holds. In IPv6 it isn't: within a single /29, up to 524,288 distinct /48s can be generated and announced. The global IPv6 BGP table currently holds around 219,000 entries. One allocation, one router, and the table more than doubles. The defence (a static max-prefix threshold) also breaks legitimate growth if set too tight, which is precisely why operators set it loosely.
The second is that the partial success of origin validation redistributes attacker attention. As ROV enforcement grows, the marginal return on hijacking a prefix falls and the marginal return on the classes nobody validates rises. That is the ordinary economics of a control that covers one thing well.
The four questions still open after fifteen years
Revisiting the 2011 open questions in light of the above, four remain live:
- Routing information versus forwarding state. Can a relying party validate not only that the AS_PATH in an UPDATE matches the path the advertisement travelled, but that the network's actual forwarding state is aligned with it? Every path-validation mechanism, ASPA and BGPsec included, secures the control plane and says nothing about where packets actually go. Proposals like FC-BGP and SBAS attempt to bridge this, and both remain experimental. This is the most technically difficult open problem in the field.
- The partial deployment problem. If a comprehensive framework is proving undeployable, can a less comprehensive one deliver acceptable outcomes? The evidence says yes, and it also says that effectiveness depends on operator policy: work surveying 100 operators found that partial path validation protects well when policies prefer secure routes, and much less well when they prefer short ones. Partial deployment should be the baseline design assumption for new proposals, not the degraded case.
- Improving what already exists. Computational cost is no longer the main obstacle it was in 2011: modern routers can carry the crypto. Operational complexity is. Managing ROAs, IRR records, ASPA relationships and certificates is a real burden, disproportionately so for smaller networks with limited staff. Proposals like Signed Prefix Lists, which replace permissive maxLength with explicit enumeration of intended announcements, are interesting precisely because they trade a little more maintenance for a lot less ambiguity.
- Auxiliary tools. Given that protocol-level security is incomplete and will stay incomplete, monitoring and risk assessment carry more weight than their status as "complementary" suggests. ARTEMIS, ROSE-T, origin-change detection systems, and risk scoring derived from IXP route server RIBs all provide value without requiring changes to BGP or coordination across ASes. Their effectiveness, though, depends entirely on the quality of IRR records, RPKI repositories and AS relationship data (which are inconsistently maintained). Improving those datasets is a prerequisite for everything else.
What the last fifteen years taught us
Three observations that cut across all of this, and that we think are worth arguing about:
Deployable beats optimal, consistently. S-BGP, soBGP and psBGP offered stronger guarantees than anything deployed today and went nowhere. RPKI, IRR and now ASPA gained traction because they can be adopted incrementally. In inter-domain routing, "good enough and deployable" wins every time.
Universal adoption is not a realistic assumption, and designs that require it have a poor track record.
The costs are individual and the benefits are collective, which is the classic collective action problem and the reason well-designed mechanisms stall. This is where institutional levers matter (NIS2, the Digital Networks Act proposal, national strategies) though their effectiveness depends on enforcement and compliance monitoring that remains uneven across jurisdictions.
An invitation to disagree
The part we are least confident about is the boundary between attack and accident. Almost every incident in the four uncovered classes has an innocent explanation available: a misconfigured redistribution, a script that ran twice, a vendor bug. That ambiguity is exactly why these classes are under-studied: it is hard to build a threat model around events you cannot attribute. It may also mean we are overstating the risk.
We would rather be corrected on that by people who run networks than be right about it in a journal. If your operational experience says the max-prefix limit is fine, or that RFC 7606 compliance is now good enough, that is the conversation we are hoping to start.
"Survey on Internet Routing Security: Stakeholder Interests, Current and Future Research Directions" is open access under CC BY 4.0 in IEEE Communications Surveys & Tutorials; DOI: 10.1109/COMST.2026.3714569. The work is a collaboration between Sapienza University of Rome, Namex, and the Italian National Cybersecurity Agency (ACN).
Comments 0