BGP ASPA: The Next Layer of RPKI-Based Routing Security

How ASPA helps detect route leaks and path spoofing without replacing BGP.

Internet routing still depends on BGP, a protocol that was built for connectivity first and security later. That design choice helped the Internet scale, but it also means that route leaks, path manipulation, and accidental misconfigurations can still affect production traffic in ways that are hard to detect before impact is felt.

RPKI and Route Origin Validation (ROV) improved the situation by letting operators verify whether an AS is authorized to originate a prefix. But origin validation does not validate the rest of the AS path. That is where ASPA comes in.

Autonomous System Provider Authorization (ASPA) is an RPKI object that lets a customer AS cryptographically declare which upstream providers are valid. With that information, routers and supporting validation systems can better identify implausible AS paths and route leaks.

In this post:

• What problem ASPA solves.
• How it relates to RPKI and ROAs.
• How ASPA-based path validation works.
• Why it matters now.
• How to start deploying it.

The Gap Left by ROA/ROV

ROAs answer a very specific question: is this AS allowed to originate this prefix? That is valuable, but it only checks the origin of the route, not the full path the route took to get to you.

That means a route can still look fine from an origin-validation perspective while being wrong from a path-validation perspective. A provider could accidentally leak customer routes to another provider, or an attacker could construct a path that appears legitimate enough to propagate even though the business relationships in the path make no sense.

A simplified example looks like this:

Expected valley-free flow:

Customer -> Provider -> Transit/Core -> Provider -> Customer

Problematic leaked flow:

Customer -> Provider -> Peer -> Provider

Figure 1: Valley-free routing. The path goes up, peaks at the core, and comes back down. A leak occurs when a customer or peer re-advertises a route in a direction it should not.

That second pattern can signal a route leak or another kind of implausible propagation path. ROA validation alone does not catch that. ASPA is meant to help.

ASPA in One Picture

At a high level, ASPA lets a customer AS publish a signed statement listing its authorized upstream providers.

AS 65010 publishes ASPA:

Customer AS: 65010
Providers:   64500, 64501

Meaning:
AS 65010 says that AS 64500 and AS 64501 are valid upstream providers.

Figure 2: ASPA object structure. A customer AS signs a statement listing its authorized providers, published in the RPKI.

If a router later sees an AS path where AS 65010 appears to be connected to a different upstream that is not listed, that path may be flagged as suspicious or invalid depending on validation state and policy.

Put simply:

• ROA tells you who may originate a prefix.
• ASPA tells you which upstream provider relationships are valid.
• Together they provide stronger routing assurance than either one alone.

Figure 3: ROA and ASPA answer different questions. Together they cover both the origin and the upstream relationships in the AS path.

How ASPA-Based Validation Works

The verification idea is straightforward even if the implementation details are more nuanced.

1. Receive a BGP route.
2. Read the AS_PATH.
3. Look up ASPA data for each customer AS in the path.
4. Check whether the next AS is an authorized provider.
5. Evaluate whether the full path remains valley-free.
6. Classify the route as valid, invalid, or unknown.

Figure 4: ASPA validation flow. Each customer AS in the path is checked against published provider authorizations, and the path is classified as valid, invalid, or unknown.

A common way to explain this is with the "valley-free" model. Internet routing normally moves up from a customer to a provider, may cross a peer or core segment, and then moves back down toward customers. If a path appears to go up, then down, and then up again, that often suggests a route leak or implausible transit relationship.

ASPA helps routers and validators distinguish those suspicious paths from plausible ones by consulting cryptographically signed provider authorization data published in RPKI.

Why ASPA Matters Now

This is not just an academic improvement.

For operators, ASPA improves the ability to detect route leaks that would otherwise pass ROA/ROV checks. That means better routing hygiene, better troubleshooting, and stronger protection for networks already investing in RPKI.

For businesses, the impact is broader. Internet routing problems can create outages, traffic detours, degraded application performance, or even exposure of sensitive traffic to untrusted intermediaries. As more critical services depend on cloud connectivity, CDN reachability, SaaS platforms, and remote work infrastructure, routing resilience becomes a business continuity issue.

ASPA matters now because it is also practical. It builds on the RPKI ecosystem operators already use rather than requiring a complete redesign of BGP.

Figure 5: ASPA adoption trend. Growth tracks RIR support, validator readiness, and operator confidence. For live counts and per-RIR breakdowns, see the dashboard at bgprpki.com.

Getting Started with ASPA

A good ASPA rollout starts with inventory, not configuration.

1. Map your upstream relationships

For each ASN you operate, identify:

• Your transit providers.
• Any upstream route servers that appear in AS paths.
• Which ASN should publish the ASPA.

2. Confirm your RPKI foundation

Before worrying about ASPA, make sure:

• Your ROAs are already in good shape.
• Your resource certificates are current.
• Your validator and routing stack support newer RPKI object types.

3. Publish ASPAs where supported

Support varies by RIR and tooling, but the general workflow is similar:

• Log in to your RIR portal or delegated CA platform.
• Select the customer ASN.
• Enter the list of authorized provider ASNs.
• Publish the ASPA object.
• Validate that it appears correctly in your RPKI toolchain.

4. Start in monitoring mode

Do not jump straight to aggressive filtering. First:

• Log ASPA-invalid paths.
• Compare them with expected routing behavior.
• Fix missing provider entries.
• Only then move toward stronger policy enforcement.

Figure 6: ASPA rollout phases. Inventory and validator readiness come before publishing; enforcement only follows a monitoring period.

Regional Configuration Notes

ARIN

ARIN provides ASPA management in ARIN Online through the Routing Security and Manage RPKI workflow. Operators can open the ASPAs section, create a new ASPA, assign the customer ASN, list provider ASNs, review the object, and submit it for publication.

RIPE NCC

RIPE NCC supports ASPA through its RPKI Dashboard. The typical flow is to open the dashboard, select the ASN, create an ASPA object, enter the list of upstream providers, and publish it through the hosted CA workflow.

APNIC

APNIC has contributed significantly to ASPA research, demonstrations, and training. Depending on the timing of deployment in the member portal, operators may use hosted workflows as they become available or delegated RPKI toolchains for earlier experimentation.

LACNIC and AFRINIC

For LACNIC and AFRINIC, it is important to confirm the current state of hosted ASPA support before planning production rollout. Where delegated RPKI is available and ASPA-capable tooling is in place, that path may be the most practical starting point.

Table 1: ASPA workflow availability by RIR. Confirm current status in your regional portal before planning a rollout.

Tooling and Visibility

Publishing an ASPA is only part of the story. You also need to confirm that the object is visible and that your validation pipeline is using it correctly.

Useful places to check include:

• Your RPKI validator.
• Your router policy and logs.
• External visibility tools and reference material at bgprpki.com.

As tooling matures, operators should expect better dashboards, clearer invalid-path reporting, and stronger vendor support for ASPA-aware routing policy.

Best Practices and Gotchas

A few practical guidelines go a long way:

• Keep your provider list accurate and current.
• Treat ASPA updates as part of provider onboarding and offboarding.
• Prefer clean operational ownership for who maintains ASPAs.
• Validate changes before enforcing them.
• Expect partial deployment and plan for "unknown" states during rollout.

Closing Thoughts

ASPA is a meaningful next step for operators that have already adopted RPKI and want stronger protection against route leaks and implausible AS paths. It does not replace BGP, and it does not solve every routing-security problem, but it closes an important gap left by origin-only validation.

If your network already uses ROAs and validators, the logical next move is to evaluate ASPA support in your RIR portal, CA tooling, and routing stack, then begin with a monitored rollout.

Further Reading

• bgprpki.com
• RIPE NCC: ASPA
• ARIN: ASPAs
• Cloudflare: ASPA, making Internet routing more secure
• Krill documentation: Manage ASPA Objects
• IETF ASPA verification draft