ASPA at APNIC: Strengthening BGP path validation

The Resource Public Key Infrastructure (RPKI) has helped operators improve the integrity of Internet routing through Route Origin Authorizations (ROAs). These allow networks to verify whether an Autonomous System (AS) is authorized to originate a prefix. This has reduced many accidental routing errors and some forms of hijacking. However, it does not protect against problems related to a route's AS path.

APNIC has now deployed support for Autonomous System Provider Authorization (ASPA) objects in MyAPNIC and the APNIC Registry API. This gives APNIC Members a new way to publish upstream provider relationships and enables operators to verify BGP AS paths.

What is ASPA?

ASPA is a new RPKI object that allows an AS Number (ASN) holder to publish a signed list of its authorized upstream providers. Operators can download ASPA objects alongside other RPKI data and use them to check whether AS paths in BGP announcements match published provider - customer relationships. This helps detect route leaks and makes it harder for attackers to manipulate routing information.

How does ASPA prevent route leaks?

In Figure 1, AS2 is a customer of both AS1 and AS3. AS1 has published an ASPA listing AS5 as its only provider. After learning a route to from AS1, AS2 mistakenly propagates it to AS3. When AS3 performs ASPA validation, it checks AS1's ASPA and finds that AS2 is not an authorized provider of AS1. The route is therefore ASPA-invalid and can be rejected.

ASPA validation is also valuable for downstream recipients, particularly when other ASes along the path are not performing validation themselves.

Figure 2 extends the previous example by adding AS4 as a customer of AS3. AS3 has also now published an ASPA listing AS6 as its only provider. Since AS3 is not performing ASPA validation here, it accepts the route leak from AS2 and attempts to pass it on to AS4. However, AS4 itself can still perform ASPA validation on the route when it receives it.

When AS4 checks the ASPAs associated with the route, it observes that the route has moved from a provider, to a customer, to another provider. The route is therefore ASPA-invalid and can be rejected. This demonstrates that ASPA validation can be effective even when validation is not performed by every AS along the path.

How does ASPA reduce the risk of BGP hijacks?

In Figure 3, the networks rely solely on ROAs for route validation. AS1 legitimately originates in accordance with its ROA, and the route propagates through the network towards AS4. However, AS5, a customer of AS4, creates a forged route for and announces it to AS4. Although the route is false, it still appears to originate from AS1. As a result, ROA validation alone does not identify the route as suspicious, and AS4 accepts it.

Because the forged route also has a shorter AS path, AS4 may prefer it over the legitimate route.

In Figure 4, AS1 has published an ASPA and AS4 performs ASPA validation. When AS4 validates the forged route, it finds that the route depends on AS5 being a valid provider of AS1. However, AS1's ASPA does not list AS5 as a provider. The route is therefore ASPA-invalid and can be rejected.

An attacker could attempt to bypass this check by inserting AS2 after AS1 in the forged AS path, making the path appear consistent with ASPA validation. However, this increases the length of the AS path, making the attack less attractive from a routing perspective. The attack would also depend on the next AS in the path not having published an ASPA, reducing the attacker's options and increasing the difficulty of carrying out a successful hijack.

A coordinated effort

APNIC's deployment is part of a broader effort across the five Regional Internet Registries (RIRs). Since November 2025, the RIPE NCC, ARIN, and APNIC have deployed support for ASPAs, and all RIRs are expected to support ASPA by the end of 2026. This alignment is important for a technology in which the full realization of its benefits depends on global adoption.

Looking ahead

While three RIRs now support the creation of ASPA objects, actually using ASPAs for validation is more of a work in progress. There is good support in open source software routers, such as BIRD and OpenBGPD, and several commercial vendors have either released support or are in the process of developing it, but so far the level of validation observed in the public internet is low. That should increase over time, though, as the number of ASPAs increases and the number of implementations grows.

With support now available in MyAPNIC and the APNIC Registry API, APNIC Members can begin publishing ASPAs and contribute to a more secure inter-domain routing system.

The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.