ASPA Check: How to Verify a Network's Authorized Providers
Last updated
An ASPA check tells you which upstream transit providers a network has cryptographically authorized in the RPKI. To run one, look up the customer ASN in an ASPA lookup: the result is either a list of provider ASNs, the special value AS0 for a transit-free network, or nothing if the network has not published an ASPA object yet. You can then compare that list with the upstreams actually seen in BGP, and use it to judge whether an AS-path is plausible or looks like a route leak.
What an ASPA check answers
An ASPA object is a signed list of the networks allowed to appear directly above a customer AS in a BGP path. Checking it answers three practical questions:
- Has this network published an ASPA at all? If not, routers that verify ASPA treat its hops as unknown.
- Is the provider list complete? A missing provider makes legitimate routes look invalid.
- Is a given AS-path consistent with the published relationships, or does it contain a hop that no ASPA allows - the signature of a route leak?
Step 1: Look up the ASN
Enter the ASN in the ASPA check tool, or open its ASPA page directly, for example /as/24940/aspa. From a terminal, the ASN summary includes an ASPA: line that reads published with the number of providers, or not published:
$ curl -s ipctl.io/as/24940 | grep ASPAThere are three possible outcomes:
| Result | Meaning | Effect on verification |
|---|---|---|
| Provider list | The network has published an ASPA naming the ASNs allowed directly above it. | Hops from this AS can be checked: listed providers pass, anything else fails. |
| AS0 only | The network declares itself transit-free. | Any AS appearing above it as a provider makes the path invalid. |
| No ASPA | Nothing published yet. | Hops from this AS are unknown - neither valid nor invalid. |
"No ASPA" is still the most common answer. It is not an error, only missing coverage. The ASPA page also shows the reverse direction: which other networks list this ASN as one of their providers.
Step 2: Compare the ASPA with real BGP upstreams
An ASPA is only useful if it matches reality. Compare the authorized providers with the upstreams the network is actually seen behind in the global routing table: the AS that appears directly before it in the AS-paths of its prefixes, as shown by your own routers, a public looking glass or a route collector.
| Situation | Risk | What to do |
|---|---|---|
| Seen upstream in BGP, missing from the ASPA | High: routes via this provider become invalid at verifying routers | Add the provider to the ASPA |
| Listed in the ASPA, never seen in BGP | None: backup or future transit | Keep it if the contract exists; remove it after the provider is gone |
| Seen upstream, but the link is actually peering | None: peers belong in neither list | Do not add peers as providers |
Upstreams observed this way depend on where you look: a link that carries only a few prefixes, or that is used only as backup, may not appear in the paths you see. Treat the BGP view as evidence, not as the authoritative list - only the network operator knows all its contracts.
Step 3: Validate an AS-path by hand
ASPA verification reads the path from the origin outward and checks each pair of neighbors: is the next AS in the current AS's provider set? A hop is Provider+ if yes, Not Provider+ if the current AS has an ASPA that does not list the next AS, and No Attestation if the current AS has no ASPA.
Example: a router learns the following path from one of its customers. AS64500 is the origin, AS64502 the neighbor that sent the route:
64502 64501 64500| Hop | Published ASPA | Result |
|---|---|---|
| AS64500 to AS64501 | AS64500 lists AS64501 | Provider+ |
| AS64501 to AS64502 | AS64501 has no ASPA | No Attestation |
No hop failed, but one is unknown, so the path is Unknown and accepted. Had AS64501 published an ASPA that did not include AS64502, the second hop would be Not Provider+ and the path - received from a customer, so it must only climb - would be Invalid: a route leak through AS64502.
For routes received from a provider, the path may go up, cross one peering link at the top and then come down, so a single Not Provider+ hop does not automatically make it invalid; the ASPA explained guide walks through both procedures.
Step 4: Publish or fix your own ASPA
To make your own routes verifiable, create an ASPA object listing every provider you buy transit from (plus any non-transparent IXP route server you are a client of), in your Regional Internet Registry's hosted RPKI where ASPA is supported, or in your own delegated RPKI setup. Then run the ASPA check on your own ASN to confirm the object is visible and the provider list is complete.
Common mistakes:
- Forgetting a backup or regional transit provider. Its routes look like leaks to verifying routers.
- Listing peers or customers as providers. It does not break your routes, but it allows those networks to carry your routes upward without being flagged, weakening leak protection.
- Combining AS0 with real providers. AS0 means "no providers" and the ASPA profile does not allow it alongside other entries; use either AS0 alone or a real list.
- Letting the object go stale. Update the ASPA before you add or drop a transit contract, not afterwards.
ASPA check vs ROA check
The two checks answer different questions and complement each other:
| ROA check | ASPA check | |
|---|---|---|
| Object | Route Origin Authorization | Autonomous System Provider Authorization |
| Published by | The holder of the IP prefix | The holder of the customer ASN |
| Question | May this AS originate this prefix? | May this AS carry that AS's routes upward? |
| Catches | Wrong origin, unauthorized more-specifics | Route leaks, many forged paths |
| Tool | RPKI & ROA lookup | ASPA check |
Frequently Asked Questions
How do I check if an ASN has ASPA?
Look the ASN up in the ASPA check. It shows the authorized provider ASNs, AS0 for a transit-free network, or that no ASPA object has been published.
What does AS0 mean in an ASPA check?
The network declares it has no transit providers. Any path in which some AS appears directly above it as a provider is therefore invalid.
Why does my ASPA check show a provider I don't use?
That is harmless - an ASPA may list more providers than are active, such as backup transit. The risk is the opposite: a provider you do use that is missing from the list.
What is the difference between an ASPA check and a ROA check?
A ROA check validates who may originate a prefix. An ASPA check validates the customer-to-provider relationships along the AS-path, which catches route leaks that keep the correct origin.
Is a path through networks without ASPA invalid?
No. Hops without ASPA data are unknown. A path only becomes invalid when an AS that has published an ASPA is followed, in a position that requires a provider, by an AS it did not authorize.
Do I need ASPA if I already have ROAs?
Yes, if you want leak protection. ROAs protect the origin of your prefixes; an ASPA lets other networks detect when your routes are leaked through a path you never authorized.