FreeTransit Learning Centre

What ASPA is, why FreeTransit asks you to list AS41051 as a provider, and how BGP Roles and OTC help against route leaks.

ASPA, BGP Roles and route-leak prevention

A ROA answers one question: may this ASN originate this prefix?

ASPA (Autonomous System Provider Authorisation) answers another: which ASNs are this ASN's providers?

With that information, a validating network can spot AS paths that can't be right, such as a route that went up to a provider, across to a peer and back up again. That is the typical shape of a route leak. ASPA adds to ROAs, IRR data and your own filters; it doesn't replace any of them.

Current status

When we last checked, in October 2026:

• The two IETF documents behind ASPA, the object profile and the path verification procedure, were still Internet-Drafts (revision 29 of each), waiting for their working-group write-up. Neither is an RFC yet.
• The RIPE NCC, ARIN, APNIC and LACNIC let you create ASPAs in their hosted RPKI services. We haven't seen an announcement from AFRINIC.
• Routinator, rpki-client, FORT and BIRD can already process ASPA.
• Few networks publish an ASPA so far, and fewer validate or drop ASPA-invalid paths.

The details can still change. Read your registry's current documentation before you change anything in production.

What an ASPA contains

The holder of an ASN signs an ASPA listing every ASN that acts as a provider (upstream) for it.

A single-homed example:

• your ASN: AS64512
• your transit provider: AS64513
• ASPA: AS64512 lists AS64513 as its provider

If you are multihomed, list every provider. A validating network that sees your route arrive through a provider you didn't list will classify the path as ASPA-invalid and may drop it.

One ASPA covers IPv4 and IPv6 together. Earlier drafts allowed a separate list per address family; the current one doesn't. If a provider gives you transit on only one family, it still goes on the list.

Who belongs on the list

Include:

• every transit provider, including backup links that are normally idle
• FreeTransit, AS41051, once you use our service
• an IXP route server only if it adds its own ASN to the path. Most route servers are transparent and don't, so they don't belong on the list.

Don't include:

• ordinary bilateral peers
• your own customers
• ASNs you only reach through a route server

Siblings, partial transit and other unusual relationships need a careful read of the current documentation and a conversation with the other network.

ASPA and FreeTransit

FreeTransit is a provider for your ASN, so your ASPA must list AS41051 next to your other upstreams.

If your ASN is registered with the RIPE NCC or ARIN, we provision the session only after a published, validated ASPA lists AS41051. For ASNs from other registries the request page shows whether this step applies. Even where it's optional, publish one if your registry supports it.

To set it up:

1. Open your registry's RPKI dashboard and create or edit the ASPA for your ASN.
2. Add AS41051 as a provider and keep all your other legitimate providers.
3. Publish. It can take several hours before validators everywhere see the change; the request page updates on its own.

An ASPA is not a ROA, a PeeringDB entry, an AS-SET entry or an aut-num policy line. Do not change the origin of your ROAs to AS41051. Your prefixes stay originated by your own ASN.

On our side, we check ASPA on every route we receive and record the result in a large community. We don't reject ASPA-invalid routes yet.

Before you publish or change an ASPA

Your RIR's dashboard doesn't work out your providers from BGP for you. You maintain the list yourself, and you have to change it whenever a provider comes or goes.

1. List every active transit relationship on IPv4 and IPv6.
2. Write down the ASN each provider uses on the session, which is not always the ASN of the company you pay.
3. Include backup providers that may carry your routes.
4. Ask providers with unusual setups how they appear in the path.
5. Compare your list with the AS paths public route collectors see for your prefixes.
6. Add a new provider to the ASPA before its session goes live, and remove an old one only after the session is gone.
7. Watch for ASPA-invalid paths after the change.

Resources

• RIPE NCC: Autonomous System Provider Authorisation
• ARIN: ASPA instructions
• APNIC Blog: ASPA at APNIC (July 2026)
• LACNIC Blog: RPKI ASPA (September 2026)
• RIPE Labs: ASPA in the RPKI Dashboard
• Hurricane Electric RPKI and ASPA adoption report
• Routinator ASPA documentation
• Krill ASPA management
• Talks: ASPA in the RPKI Dashboard (RIPE 91), Why is ASPA still a draft? (RIPE 92), Six Months of ASPA (RIPE 92), Do not drop ASPA invalids of the last resort (RIPE 92)

BGP Roles and Only-To-Customer

RFC 9234 defines a second defence against leaks that doesn't depend on RPKI at all. Both sides of a session declare its role, such as provider, customer or peer. Routers then add an Only-To-Customer (OTC) attribute to routes that must only go down to customers, and refuse to send OTC-marked routes back up or sideways.

BIRD, FRRouting and several commercial platforms support it. In strict mode a role mismatch stops the session from coming up, so agree the roles with your neighbour before you turn it on. FreeTransit sessions don't negotiate BGP Roles yet; leave the role unset, or at least not strict, on the session with us.

Layers that work together

• exact import and export policy
• prefix and AS-path filters for each neighbour
• prefix limits
• IRR route objects and AS-SETs
• ROAs and origin validation
• ASPA, published and, where supported, validated
• BGP Roles and OTC where both sides support them
• monitoring from public route collectors

Each of these catches mistakes the others miss. A bad export policy is still a bad export policy, whatever else is in place.