ASPA in the RPKI Dashboard: A New Layer of Routing Security

Over the past decade, RPKI and Route Origin Validation (ROV) have made it much harder to accidentally hijack prefixes, but they don’t say anything about who's allowed to sit upstream of whom on a BGP path. Autonomous System Provider Authorisation (ASPA) is an emerging IETF standard that fills exactly that gap, using RPKI objects to describe customer-to-provider AS relationships and to detect route leaks and implausible paths before they cause trouble on the global Internet.

With ASPA support now appearing in the RIPE NCC RPKI Dashboard, many operators in our service region will first encounter the mechanism there. This article is meant to give you enough background to understand what ASPA is doing, why we’re exposing it in the Dashboard, and how to think about adopting it.

A lot of the information laid out in this article can be found over on our ASPA documentation page, but read on for more about the what and why behind ASPA.

What is ASPA?

ASPA is a new kind of signed RPKI object being standardised in the IETF SIDROPS working group. It lets the holder of an AS number explicitly list one or more other ASNs as its legitimate upstream providers in BGP.

In practical terms, you issue an ASPA for your AS, and inside that object you list the set of provider ASes that are allowed to appear upstream of you in AS paths. RPKI validators fetch and validate these objects, and routers use the resulting data to check whether a given AS path lines up with the customer-provider relationships you’ve declared.

ASPA is considered mature enough that operators can start signing, but - as with ROAs - it comes with responsibilities. Before you start using it, we strongly recommend reading the current documentation and watching this recent RIPE Meeting presentation on ASPA, both of which go into more operational detail.

Why we’re surfacing ASPA in the RPKI Dashboard

From an operator’s point of view, ASPA is easiest to approach as "the next layer on top of what I already do with RPKI". The same infrastructure that currently lets you create and manage ROAs can be used to publish ASPAs.

By adding ASPA support to the RPKI Dashboard, we make this new building block visible and available alongside the tools you already use. The dashboard gives you a familiar place to create and manage ASPA objects next to your ROAs.

What the dashboard does not do is guess or infer your provider set for you. In particular, it does not currently tell you which providers we see for your AS in BGP; that remains something you need to understand from your own routing and measurement systems. That separation is deliberate: ASPA is ultimately about you making explicit, policy-relevant statements about your own relationships.

ASPA objects in the RPKI can already be validated by recent versions of the most widely used validators, and support is on the roadmap for others. The validated ASPA payloads are picked up by routers using an updated version of the RPKI to router protocol. ASPA path verification is done in routers. ASPA support is currently available in Bird and OpenBGPD, and is being tested in Cisco IOS-XR. It is expected that other router vendors will implement support based on both customer demand, and the availability of ASPA objects in the RPKI.

Signing ASPAs - what you commit to

When you create an ASPA for your AS, you are putting your view of your upstreams into the RPKI. You authorise all of the ASes you list there to appear as providers in BGP paths that include your AS. The verification logic only cares about provider relationships, so you do not list lateral peers or customers. If you have a neighbour with a "complex relationship" - for example they act as both a peer and a provider in different contexts - they still need to be listed as a provider. Non-transparent route servers at IXPs also appear in the BGP path in a provider-like role and should be included as well.

Just as with ROAs, keeping ASPAs correct involves ongoing operational work. You need to include all of your upstreams, because if you omit one, ASPA-aware networks may treat your paths via that provider as ASPA invalid and drop them. ASPAs also have to be kept in sync with changes to your upstreams, and because the RIPE NCC RPKI Dashboard doesn’t currently show which providers we see for your AS in BGP, you’ll need your own tooling and processes to track that. As with ROAs, ASPA is not "set and forget", so if you're not prepared to maintain these objects as part of day-to-day operations, you should be cautious about enabling them.

Why sign?

Despite that extra operational overhead, there are good reasons to sign ASPAs. If you invest in maintaining them, you gain protection against many kinds of route leaks, especially classic "valley" leaks where a route is propagated through an unexpected chain of providers. You also make path spoofing harder, because attackers find it more difficult to fabricate plausible-looking AS paths that include your AS - and the more networks that publish ASPAs, the harder that becomes.

Verifying paths from customers

The first place ASPA helps is in validating paths you receive from customers. Conceptually, the idea is simple: every AS-to-AS hop along the path should reflect a plausible customer-to-provider relationship.

The ASPA specification defines a function that, for each hop, looks at the customer AS and asks whether the next AS in the path is listed as one of its providers. If every hop that can be checked this way lines up with what the ASPAs say, the path is treated as valid. If any hop contradicts the ASPA data - a customer says "this AS is not my provider", yet it appears that way in the path - the result is invalid. Paths where there is no ASPA data at all for one or more hops fall into an "unknown" bucket.

Operationally, the recommendation is straightforward: reject invalid customer paths and accept both valid and unknown ones. If providers and transit networks reject ASPA invalid paths then this will help to filter out many obviously broken or spoofed paths. Note that accepting unknown is important both during partial deployment (not everyone will sign ASPAs at the same time) and as a safety valve in case of RPKI validation problems, because aggressively dropping unknowns could cause outages if your validator has an issue.

Verifying other paths - valley-free routing

Customer paths are only half the story. You also receive routes from peers and providers, where you cannot assume the whole path is a simple chain of customer-to-provider hops leading to you.

Here ASPA leans on the long-standing notion of valley-free routing: routes go "uphill" from customers to providers, then cross at a "peak" (either a transit-free provider or a pair of lateral peers), and then go “downhill” from providers back to customers. A path that goes up-down-up (and so on) contains a valley, which is usually a route leak and can lead to sub-optimal routes and unexpected cost or latency.

ASPA’s valley-free verification essentially asks whether the "uphill" parts of the path, as seen from each end and according to the published ASPAs, fit together in a way that makes sense. If the customer-to-provider segments you can infer from each side are separated by more than a single hop in the middle, that gap is treated as a valley and the path is considered invalid. If those uphill segments meet at a single adjacency, that looks like a lateral peering; if they meet in a single AS, that looks like a shared provider or a complex peer-plus-provider relationship. In those non-valley cases, the result is valid or unknown, and the route should be accepted.

Again, ASPA doesn’t need to know every relationship on the Internet to be useful: even with partial deployment, it lets you reject a significant class of provably bad paths.

Validation and verification toolchain

The good news for operators is that ASPA reuses the same toolchain you already need for Route Origin Validation. RPKI validators (relying party software) fetch and validate the RPKI tree and all signed objects - now including ASPAs - while an updated version of SLURM (Simplified Local Internet Number Resource Management with RPKI) can also be used to apply local exceptions to ASPA data. Routers consume the validated data via the RPKI-to-router (rpki-rtr) protocol and then perform ASPA-based AS_PATH verification themselves, with no need for on-box cryptography.

In other words, employing ASPA is not a separate RPKI project; it’s an extension of what you already run for ROA/ROV. You will need updated versions of your validators and router software that understand ASPA objects and verification logic, but the basic architecture remains the same.

Where we are now, and what you can do

ASPA is still discussed in various Internet-Drafts, but both the profile (the binary layout of an ASPA object) and the BGP verification procedures are quite mature, with multiple iterations in the IETF and ongoing analysis of their impact on route leaks and path security.

If you operate in the RIPE NCC service region and already run RPKI, some practical next steps might be:

• Watch recent talks on ASPA from RIPE and IETF meetings to get a feel for operational experience as it develops.
• Make an inventory of your upstream providers per ASN, including complex relationships and route-server dependencies.
• Create ASPA objects for your ASN(s) in the RPKI Dashboard. If you want to get a feeling for this before you start, you may want to try the public RPKI Test Environment first as this uses a separate Trust Anchor and any mistakes made here will not affect your production network.
• If you create any ASPA objects then make sure that you keep them in sync with any changes in providers for your ASN(s).
• Consider validating routes received from your customers. Warn your customers about invalid ASPA paths, before you start dropping them.
• If your router vendor does not yet support ASPA then consider asking them about their ASPA roadmap. You may still want to use validated output of ASPA objects from your RPKI validator in order to monitor paths received from customers.
• Consider validating routes received from peers and providers as well. Again, it may be prudent to warn about ASPA invalid paths first before moving on to rejecting those paths.

ASPA won’t solve every routing security problem on its own, but it enables operators to encode and verify AS-to-AS provider relationships using RPKI - and that’s a significant step forward. Starting by signing ASPA objects helps because the more objects exist, the better ASPA path verification coverage becomes. This in turn makes a stronger case for getting router vendors to add ASPA support to their roadmap.