FreeTransit Learning Centre

Understand ASPA provider authorisations, BGP Roles, OTC and the operational risks of incomplete relationship data.

ASPA, BGP Roles and route-leak prevention

A ROA answers a route-origin question: May this ASN originate this prefix?

ASPA addresses a path question: Which provider ASNs is this customer ASN authorised to use?

This adds information that can help detect route leaks and implausible AS paths. ASPA complements ROAs, IRR data and ordinary BGP policy; it does not replace them.

Current status

As of 12 July 2026:

• the RIPE NCC RPKI Dashboard supports creating ASPA objects;
• the RIPE NCC describes ASPA as an emerging IETF standard suitable for signing with care;
• the ASPA object profile and AS-path verification procedures remain IETF Internet-Drafts rather than final RFCs;
• implementation and validation behaviour is still developing.

Because the standard and implementations are evolving, always read the current RIPE NCC documentation and current IETF drafts before changing production validation policy.

What an ASPA contains

An ASPA is signed by the holder of a customer ASN and lists the ASNs that are authorised to act as providers for that ASN in the BGP relationship sense.

For a simple single-homed network:

• customer ASN: AS64512;
• transit provider: AS64513;
• ASPA statement: AS64512 authorises AS64513 as a provider.

For a multihomed network, every legitimate provider relationship must be represented correctly. An incomplete provider set can cause legitimate paths to be classified as ASPA-invalid by validating networks.

What not to add automatically

Do not add an ASN merely because you have a BGP session with it. In particular, ordinary bilateral peers, customers and an IXP route-server ASN are not automatically your providers.

Complex relationships, sibling ASNs, partial transit and route-server behaviour require careful reading of the current specification and platform guidance.

Critical operational warning

The RIPE NCC dashboard does not infer the correct provider set from observed BGP for you. You are responsible for understanding and maintaining the list. Update ASPA in lockstep with provider changes.

Before publishing or changing ASPA:

1. Inventory every active IPv4 and IPv6 transit relationship.
2. Identify the provider ASN used on the wire, not only the supplier's brand name.
3. Check whether IPv4 and IPv6 use the same provider relationships.
4. Include backup providers that may legitimately propagate your routes.
5. Review complex or indirect relationships with the provider.
6. Compare your intended list with observed AS paths from several collectors.
7. Schedule ASPA updates together with BGP activation or removal.
8. Monitor for ASPA-invalid paths after the change.

Official ASPA resources

• RIPE NCC — Autonomous System Provider Authorization
• RIPE Labs — ASPA in the RPKI Dashboard
• RIPE 91 — ASPA in the RPKI Dashboard
• RIPE 92 — Why is ASPA still a draft?
• RIPE 92 — Six Months of ASPA
• RIPE 92 — Do not drop ASPA invalids of the last resort
• IETF Datatracker — ASPA object profile, current version
• IETF Datatracker — ASPA AS_PATH verification, current version
• Routinator ASPA documentation
• Krill ASPA management

BGP Roles and Only-To-Customer

ASPA is not the only route-leak defence. RFC 9234 defines BGP Roles and the Only-To-Customer, or OTC, attribute.

BGP Roles allow two neighbours to declare the relationship expected on a session, such as provider, customer or peer. OTC carries information that helps detect routes propagated in violation of expected valley-free policy.

Use current router documentation to determine support and interoperability. Do not enable strict role negotiation on an existing session without coordinating with the neighbour, because mismatched role configuration can prevent the session from establishing.

Relationship with other controls

A secure design uses several layers:

• exact import and export policy;
• customer prefix and AS-path filters;
• prefix limits;
• IRR route and AS-SET data;
• RPKI ROAs and origin validation;
• ASPA signing and path verification where supported;
• BGP Roles and OTC where supported;
• monitoring from independent route collectors.

No single control makes an unsafe export policy acceptable.