RPKI ASPA: using the AS-PATH to secure BGP inter-domain routing

Why does BGP remain vulnerable?

BGP was designed in an environment of mutual trust. Every router accepts announcements from its neighbours without verifying whether the advertised AS path is plausible or authorised. It is precisely this lack of path validation that enables attacks such as route leaks and BGP hijacks through AS_PATH manipulation.

RPKI with ROAs (Route Origin Authorizations) has partially solved the origin problem: it is now possible to verify that a prefix is being announced by the AS that legitimately holds it. However, RPKI says nothing about the validity of the path (AS-PATH) between the origin and the receiver. That is where ASPA comes in.

What is an ASPA?

An AS Provider Authorization (ASPA) is an RPKI-signed object through which a customer AS explicitly declares its list of transit providers. In other words: “these are the ASes through which I have transit, and to which I am authorised to propagate my routes upstream.”

Concretely, if AS64500 has an ASPA declaring AS1299 (Telia) and AS3356 (Lumen) as providers, any BGP path in which AS64500 is followed by an AS that is not one of those two providers constitutes an anomaly that receivers can detect.

ASProviderAuthorization {
  customer-asid:  64500
  provider-asid:  1299   (Telia)
  provider-asid:  3356   (Lumen)
  afi-limit:      IPv4 + IPv6
}

How does validation work?

Upon receiving a BGP route, a router validates ASPA by traversing the AS_PATH from right to left (from the nearest AS towards the origin). For each consecutive pair (ASi, ASi+1), it checks whether ASi+1 appears in the list of providers declared by ASi in its ASPA object. If a pair is missing or inconsistent, the path is marked Invalid.

The three possible states are identical to those of RPKI/ROA: Valid, Invalid, and Unknown (no ASPA object exists for that AS). Based on these states, operators can apply routing policies to accept, (de)prefer, or reject routes. Mirroring what is already done for ROA-based origin validation.

Route leak detection: the valley-free principle

To detect an illegitimate detour, ASPA relies on the natural hierarchy of the Internet. In healthy routing, traffic travels “up” through increasingly large providers, optionally crosses a single peering link at the top, then flows “down” to the destination. This is the so-called “mountain” or “valley-free” shape:

A route leak creates a “valley”: traffic descends to a customer AS and then unexpectedly travels back up to another provider. ASPA detects precisely this down-then-up movement by verifying that both ends of the path meet at the top:

What ASPA detects — and what it does not

ASPA is particularly effective against route leaks: a customer AS re-announcing to its providers prefixes learned from those same providers, in violation of valley-free relationships.

That said, ASPA does not replace ROAs for origin validation and does not protect against all forms of AS_PATH manipulation, such as the insertion of a fictitious AS. A robust BGP defence will combine ROA + ASPA + explicit filtering where needed.

Deployment status

ASPA is standardised in RFC 9582 (published in 2024), making it very recent. ASPA objects fit into the existing RPKI infrastructure: they are signed by the AS holder, either through a delegated CA or hosted directly at a RIR (RIPE NCC, ARIN, APNIC…). Most RIRs have recently added, or are in the process of adding, support for creating ASPA objects in their portals. RIPE NCC has notably integrated this into its RPKI dashboard [2].

Cisco is working on an IOS-XR version with ASPA support, currently in Early Field Trial (EFT). It is therefore possible to test this functionality in a lab environment. On the RTR (RPKI-to-Router) protocol side, Routinator and Fort already support the new version required to propagate ASPA objects to routers, while StayRTR still requires a specific patch [3].

The path to large-scale operational deployment will still be long, as it is still the case for RPKI/ROA. But the building blocks are falling into place, and early results are encouraging. Growing regulatory pressure, notably through ENISA and NIST recommendations, may accelerate the pace on the vendor and operator side.

References