Closing the gap: how ASPA validates the path traffic takes

BGP route leaks have long been a known weakness in Internet routing. When traffic is diverted through networks it was never meant to cross — whether by misconfiguration or malice — the impact can range from degraded performance to full-blown outages. Existing security measures like Resource Public Key Infrastructure (RPKI) and Route Origin Authorizations (ROAs) confirm that an Autonomous System (AS) is allowed to announce a given prefix, but they say nothing about the route that announcement takes to reach peers.

Autonomous System Provider Authorization (ASPA) is a newer cryptographic standard, built on top of RPKI, that addresses that blind spot. An ASPA record lets a network publish a signed list of its authorized upstream providers. Receiving networks can then check the BGP AS_PATH against those records to verify that traffic only transited an approved chain of networks. In short: ROAs verify the destination, ASPA verifies the journey.

How path validation detects leaks

ASPA validation rests on the assumption that healthy Internet routing follows a “valley-free” structure. Traffic should flow up from a customer to its provider (or providers), possibly across a single peering link between large networks at the top, and then down to the destination. A route leak, by contrast, creates a “valley”: traffic goes down to a customer, then unexpectedly back up to another provider — a role customers are neither intended nor equipped to perform.

To evaluate a path, ASPA works from both ends of the AS_PATH:

  • Up-ramp check: Starting at the origin AS, each hop is examined to confirm it authorized the next network as a provider.
  • Down-ramp check: Starting at the destination, the path is traced backward with the same provider-authorization checks.

A path is considered Valid when the up-ramp and down-ramp meet at the top — the mountain shape holds. When they fail to connect, there is a gap in the middle, and that gap marks the unauthorized transition: the leak. Such a path is flagged as ASPA Invalid.

Consider a case where AS65539 receives a route from customer AS65538. AS65538 is trying to transit traffic from provider AS65537 up to another provider — a classic route leak. Validating the path:

  1. The origin AS65536 authorizes its provider; the up-ramp check passes.
  2. From the destination, the down-ramp check reaches AS65538.
  3. The up-ramp ends at AS65537 while the down-ramp ends at AS65538 — the two do not connect, so the route is reported as invalid.

Without signed ASPA objects, there is no way to perform this kind of check — the relationship between which networks may advertise prefixes to whom simply is not published. ASPA makes that relationship explicit.

Limits against forged-origin hijacks

ASPA can also help stop forged-origin hijacks, where an attacker advertises a path to a real origin prefix but fabricates the relationship with the origin AS. Even when Route Origin Validation (ROV) passes because the origin is correct, ASPA steps in: since the attacker is not on the victim’s list of authorized providers, the path is rejected.

There is, however, one notable gap. If a provider forges a path advertisement to its own customer, ASPA does not catch it. A provider can invent a peering link with another AS to attract customer traffic on a shorter AS_PATH, even though no such link exists. ASPA knows nothing about peering relationships — only provider authorizations — so it cannot block this form of path forgery.

Creating ASPA objects in practice

For network operators, publishing an ASPA record is now a simple task in the RIR dashboards that support it — currently RIPE and ARIN. The required inputs are the AS number and the AS numbers of the providers from which transit is purchased. These providers are the upstream networks authorized to announce the customer’s prefixes and to send a full routing table.

As an example, consider AS203898, used for Cloudflare’s London office Internet. It has three providers at the time of writing: AS8220, AS2860, and AS1273. In the RIPE RPKI dashboard, navigating to the ASPA section and clicking “Create ASPA” lets you enter those three ASNs as the provider list. After a short propagation period, the signed object is visible in the global RPKI system.

ARIN’s process is nearly identical. Under Routing Security → “Manage RPKI,” the option to “Create ASPA” is available. The one special value worth noting in both interfaces is provider AS0. Signing an ASPA object with AS0 as the only entry attests that the AS has no valid upstream providers — which is exactly what transit-free Tier-1 networks with only peer and customer relationships should eventually do.

ASPA tracking in Cloudflare Radar

To help the community observe this rollout, Cloudflare Radar now includes a dedicated ASPA deployment monitoring view. The new view charts adoption over time and can break down trends by each of the five Regional Internet Registries (RIRs), based on where the customer ASNs are registered.

ASPA data has also been integrated into the country/region and ASN routing pages, making it possible to compare how different locations are progressing in signing their infrastructure. Drilling down into a specific AS — for example, AS203898 — shows whether its observed BGP upstreams are ASPA authorized, the complete provider list from its ASPA object, and a timeline of any ASPA changes involving that AS.

Deployment is only the beginning

ASPA’s publication as an RFC is a milestone, but the hard part starts now. Turning ASPA objects into measurable routing-security value requires coordinated updates across the entire RPKI toolchain: Relaying Party (RP) packages, signer implementations, RTR (RPKI-to-Router protocol) software, and the BGP implementations that will actually consume and validate ASPA data. History with RPKI’s Route Origin Validation rollout suggests this transition will take years, not months.

Pair ASPA with BGP roles

Operators should also configure BGP roles per RFC9234 alongside ASPA adoption. The roles assigned to a BGP session give routers the context they need to choose between the upstream and downstream ASPA validation algorithms. This is a direct way to encode your intended business relationship with a neighboring AS onto the session itself. Verify with your routing vendor that they support both RFC9234 BGP roles and the Only-to-Customer (OTC) attribute.

Handle ASPA objects with care

Creating ASPA objects for your own AS is encouraged, but maintenance requires precision. As networks begin actively blocking invalid paths based on these records, a missing legitimate provider entry could cause your traffic to be dropped. That risk is familiar — it is the same operational discipline networks already apply to Route Origin Authorizations (ROAs). ASPA is the necessary cryptographic upgrade for Internet path validation, and its arrival is welcome news.