Autonomous System Provider Authorization (ASPA)

Autonomous System Provider Authorization (ASPA) addresses a longstanding gap in Border Gateway Protocol (BGP) security. While origin validation was resolved through Resource Public Key Infrastructure (RPKI) and Route Origin Authorizations (ROAs), path validation remained unaddressed. This gap has enabled the persistence of route leaks.

BGP relies on mutual trust among network operators. This trust is compromised when an operator exports unauthorized routes. For example, a customer may inadvertently announce a full routing table to an upstream provider, or a small Internet Service Provider (ISP) may leak a partial table at an exchange. In both cases, the consequences are similar: traffic is rerouted, latency increases, and engineers must quickly diagnose the incident.

ROAs address a single question: whether a given Autonomous System (AS) is authorized to originate a specific prefix. They do not assess if the AS_PATH is valid. Consequently, a prefix may have a legitimate origin but traverse a path that contravenes fundamental provider-customer relationships. ASPA is designed to address this limitation.

ASPA allows a customer AS to cryptographically declare which upstream providers are authorized to carry its routes. The object is published in the RPKI system, just like a ROA. Instead of binding a prefix to an origin AS, ASPA binds a customer AS to its legitimate providers. That single shift changes how we can evaluate an AS path.

When a router performs ASPA validation, it evaluates the provider-customer sequence inside the AS_PATH. The goal is to detect “valley” violations. In normal routing economics, traffic flows up from customer to provider, possibly across peers, and back down to another customer. If the path shows a provider suddenly acting like a customer, that is a strong signal of a route leak.

Numerous high-profile route leaks in the past decade could have been prevented through ASPA validation. Type 1 leaks, in which a customer propagates routes from one provider to another, are specifically addressed. Accidental transit, frequently resulting from permissive export policies, becomes immediately detectable. Although the path may persist, it will fail validation.

ASPA does not replace ROAs. It complements them. ROAs protect prefix origin integrity. ASPA protects the integrity of the provider chain. Together, they form the beginning of actual BGP path validation rather than best-effort filtering.

For Internet exchanges and transit providers, this matters more than most realize. An exchange fabric can amplify a leak in seconds. A misconfigured member can propagate routes to dozens of networks before anyone notices. ASPA provides operators with a cryptographic signal that a relationship along the path does not match the network’s policy.

Deployment of ASPA is practical. Organizations already utilizing RPKI validation possess much of the necessary infrastructure. ASPA objects are published within the same system. Modern RPKI validators are incorporating support, and router vendors are implementing validation logic. Although widespread adoption will be gradual, incremental deployment offers immediate benefits.

Operational challenges are anticipated. For example, questions arise regarding the handling of invalid paths during maintenance windows and the appropriate policy response to invalid ASPA states. Most operators are expected to initially tag and monitor such events before enforcing traffic drops. This approach mirrors early RPKI deployment strategies and allows teams to build confidence prior to implementing stricter filters.

Some argue that IRR data and strict prefix filtering are enough. IRR is not cryptographically verified, and it does not encode provider relationships in a way routers can enforce. ASPA moves this information into a signed, machine-validated format that routers can actually use.

The broader shift here is important. We are moving from social contracts and mailing list threads to cryptographic assertions. BGP will never be perfect, but we can reduce the blast radius of human error. ASPA is a concrete step toward reducing error.

If you operate an AS, especially one with multiple upstreams, now is the time to prepare. Audit your provider relationships. Confirm your RPKI infrastructure can publish ASPA objects. Test validation behavior before turning it on in production.

Route leaks happen all the time. ASPA does not eliminate mistakes, but it gives us a way to detect and contain them with math instead of hope.

Some Resources for Further Reading

https://www.ripe.net/manage-ips-and-asns/resource-management/rpki/aspa

Creating an ASPA in ARIN
https://www.arin.net/resources/manage/rpki/aspa/

The post Autonomous System Provider Authorization (ASPA) appeared first on j2sw Blog.