RPKI, route origin validation and ASPA: securing BGP routing

What the problem is

The Border Gateway Protocol (BGP) connects the tens of thousands of autonomous systems (ASes) that make up the internet. When a network announces "I can reach 203.0.113.0/24", its neighbours generally believe it. Mistakes and attacks exploit this trust:

• Prefix hijacks, where an AS announces address space it does not hold, drawing traffic towards itself.
• Route leaks, where an AS passes routes learned from one provider to another provider or peer, against normal policy, so traffic takes an unintended path.

Well-known incidents, such as a 2008 event in which a national filtering attempt made a major video site unreachable worldwide, show how one bad announcement can spread globally within minutes. For a refresher on routing protocols, see routing protocols.

Key ideas

The Resource Public Key Infrastructure (RPKI), described in RFC 6480, is a certificate hierarchy that follows how address space is actually allocated: from the five Regional Internet Registries (RIRs) down to the organisations that hold addresses. Holders use it to sign statements about their resources.

• Route Origin Authorisation (ROA). A signed object saying "AS 64500 may originate 203.0.113.0/24, up to a maximum length of /24".
• Relying party software (validators) download and verify all RPKI objects and produce a list of validated ROA payloads (VRPs).
• RPKI-to-Router protocol (RTR) sends VRPs to routers, which do not need to perform cryptography themselves.
• Route Origin Validation (ROV), defined in RFC 6811, gives each route one of three states: Valid (a matching ROA exists), Invalid (a ROA covers the prefix but the origin AS or length does not match) or NotFound (no ROA covers it). Operators typically drop Invalid routes.

Tip: Set the ROA maximum length to exactly what you announce. A loose max-length lets an attacker announce a more specific prefix with your AS as the forged origin, and it would still appear Valid.

Why it matters and what changed recently

ROV only checks the origin AS. An attacker can forge a path that ends in the legitimate origin, and route leaks usually keep the correct origin. Two further mechanisms address the path:

• BGPsec (RFC 8205) signs each hop of the path but requires router changes and has seen very little deployment.
• ASPA (Autonomous System Provider Authorisation) lets an AS publish a signed list of its upstream providers. Validators can then check whether a received AS path is consistent with real customer-provider relationships, which catches many leaks and some forged paths. ASPA is still progressing through the IETF, but since November 2025 RIPE NCC, ARIN and APNIC have all deployed support for creating ASPA objects, and router and validator support is growing.

Policy pressure has also grown. In September 2024 the US White House published a roadmap for enhancing internet routing security, urging networks, and especially federal agencies and their providers, to publish ROAs and deploy ROV. Industry programmes such as MANRS promote the same baseline. ROA coverage and ROV deployment have increased substantially over the last few years, so dropping Invalid routes now gives real protection for a large share of address space.

How practitioners apply it

1. Publish ROAs for every prefix you announce, through your RIR’s hosted RPKI service, with tight max-length values. Include ROAs for prefixes announced by your DDoS mitigation provider if they originate them.
2. Run two or more validators from different software projects, for resilience.
3. Enable ROV on edge routers, first in monitoring mode to see what would be dropped, then reject Invalid routes.
4. Create ASPA objects if your RIR supports them, listing all your upstream providers.
5. Keep classic hygiene: prefix filters on customer sessions, maximum-prefix limits and monitoring of your own announcements.

An enterprise that does not run BGP itself still benefits by asking its transit providers whether they perform ROV and by making sure ROAs exist for any address space it holds.

Limitations and open questions

• Origin is not path. ROV alone does not stop forged-origin hijacks or most leaks; ASPA adoption is still early.
• Operational risk. A wrong or expired ROA can make your own routes Invalid and cut you off. Monitor your RPKI objects like certificates.
• Dependency on RIRs. The RPKI trust anchors are the five RIRs, which raises governance questions and creates single points of failure if repositories are unavailable.
• Partial deployment. Protection depends on many other networks validating; one validating network cannot protect the whole internet.