06 Aug The ASPA shift

Eng. Hisham, Chief Community Officer, RIPE NCC, explores the next layer of Internet routing security.

Routing security rarely makes headlines, but it quietly underpins almost everything we do online. Every time we open a website, send a message, join a video call, or stream a film, the Internet’s routing system is working behind the scenes to move data between networks across the world. When that system works properly, the Internet feels seamless. When it fails, even briefly, the effects can ripple globally.

Over the past decade, the Internet community has made major progress in securing this infrastructure through the deployment of the Resource Public Key Infrastructure (RPKI) and Route Origin Validation (ROV). These technologies help networks verify whether an Autonomous System (AS) is authorised to announce a particular IP address range. In simple terms, they reduce the chances of accidental or malicious route hijacks, where traffic is sent to the wrong place.

But while RPKI and ROV answer one important question – “Who is allowed to originate this route?” – they leave another unanswered: “Does the path this route has taken actually make sense?”

That’s where ASPA, or Autonomous System Provider Authorisation, comes in.

ASPA is an emerging Internet standard designed to improve routing security by checking declared customer-to-provider relationships between networks. It builds on the existing RPKI framework and adds a way for networks to declare which upstream providers they legitimately use. With ASPA, routers can begin to identify suspicious or implausible routing paths before they cause problems on the global Internet.

The technology is now beginning to appear in operational tools and software, including the RIPE NCC RPKI Dashboard. While ASPA is still in the early stages of deployment, many in the technical community see it as one of the most important next steps in securing interdomain routing.

Why routing security matters

The Internet is made up of thousands of independently operated networks, known as Autonomous Systems. These networks exchange routing information using the Border Gateway Protocol (BGP), which effectively tells routers where traffic should go.

BGP was designed back when we had a much smaller and more trusting Internet. Security was not a central design requirement. As a result, networks generally accept routing information from one another in good faith.

That trust model has created problems over the years. Misconfigurations and route leaks have repeatedly disrupted global connectivity. In some cases, traffic has accidentally been redirected through networks that were never meant to carry it. In others, malicious actors have deliberately hijacked routes to intercept or blackhole traffic.

These problems are difficult to solve because BGP does not inherently verify the information it receives. Routers can announce routes they should not be advertising, and other routers may believe them.

The role of RPKI and ROV

RPKI was developed to address part of this problem. Using cryptographic certificates tied to Internet number resources, RPKI allows the holder of an IP address range to create a Route Origin Authorisation (ROA). A ROA states which AS is allowed to originate routes for that address space.

Networks that perform Route Origin Validation can then compare incoming BGP announcements against these signed objects. If a route is announced by an AS that is not authorised in a ROA, the route can be marked invalid and rejected.

This has significantly improved routing hygiene across the Internet. Accidental origin hijacks have become easier to detect and filter, and many large networks now reject invalid routes by default.

However, RPKI and ROV only validate the origin AS at the end of the path. They do not validate the rest of the AS path itself. A route might originate from the correct AS and still travel through an unexpected or suspicious sequence of providers. This is where route leaks become a problem.

What ASPA adds

ASPA extends the RPKI system by allowing networks to publish information about their provider relationships.

An ASPA object is a signed statement created by the holder of an AS Number. Inside the object, the network lists the ASNs of its legitimate upstream providers. Routers and validators can then use this information to assess whether the AS paths seen in BGP are plausible.

For example, if AS65000 says that its authorised providers are AS64496 and AS64497, routers can verify whether routes involving AS65000 appear upstream through one of those providers. If traffic appears to flow through an AS that is not authorised as a provider, the path may indicate a route leak or fabricated routing information.

This extends routing security beyond origin validation toward AS-path plausibility checks. Importantly, ASPA does not attempt to map the entire Internet or define every relationship between networks. Instead, it focuses specifically on customer-to-provider relationships, which are generally more stable and easier to express operationally.

How ASPA verification works

ASPA works by allowing routers to compare parts of a BGP path against published customer-to-provider relationships. When a network publishes an ASPA object, it declares which upstream providers are authorised to appear above it in routing paths. Routers can then use this information to assess whether a path follows the kinds of customer-provider patterns normally seen on the Internet.

If the published ASPA information clearly contradicts part of a route’s path – for example, if an AS appears connected to a provider it has not authorised – the route may be treated as ASPA invalid. If there is not enough ASPA information available to make a determination, the route remains in an unknown state.

Operational guidance currently recommends rejecting clearly invalid customer paths while continuing to accept valid and unknown routes. This allows networks to improve routing security incrementally while ASPA deployment across the Internet is still growing.

Building on existing infrastructure

ASPA builds on infrastructure many networks already use. The same RPKI validators that process ROAs can also validate ASPA objects, while routers receive the validated information through the RPKI-to-router protocol and apply ASPA verification locally. The RIPE NCC’s inclusion of ASPA support in its RPKI Dashboard reflects this operational continuity.

Like any routing security mechanism, ASPA introduces operational responsibilities. Networks need accurate inventories of their upstream providers and must keep ASPA objects updated when relationships change. If a provider is omitted accidentally, legitimate routes could appear invalid to ASPA-aware networks. ASPA is therefore not a ‘set and forget’ technology.

A gradual but important step forward

ASPA is still evolving through the Internet Engineering Task Force (IETF) standardisation process, but the specifications are considered mature enough for operational experimentation and early deployment. Support is already available in BIRD and OpenBGPD, with testing under way in Cisco IOS-XR.

No single technology will completely secure Internet routing. The Internet’s decentralised structure and enormous scale make perfect validation unrealistic. But ASPA represents an important evolution in routing security thinking. RPKI and ROV helped answer the question of who is authorised to announce an IP prefix. ASPA begins addressing whether the path used to reach that prefix is believable.

As the Internet continues to support critical infrastructure, commerce, government services, and daily communication, improving trust in routing becomes increasingly important. Even incremental improvements can reduce outages, limit the impact of leaks, and make malicious attacks harder to execute.

For most Internet users, these systems remain invisible. But for the networks that keep the Internet functioning, technologies like ASPA are becoming part of a broader effort to make global routing more resilient, verifiable, and secure.