Since launching support for Autonomous System Provider Authorization (ASPA) objects in June, APNIC has seen steady growth in adoption, with 538 ASPA objects now published under its RPKI trust anchor. A webinar held on 30 September 2026 titled 'Understanding ASPA: The next step in routing security' drew Members and Internet community participants to discuss emerging implementation questions, particularly regarding provider definitions, Internet Exchange Point (IXP) environments, and the operational risks of signing and relying on ASPA records for Border Gateway Protocol (BGP) path validation.

Defining 'provider' in ASPA contexts

An ASPA is a cryptographically signed RPKI object that permits an Autonomous System Number (ASN) holder to specify which upstream or transit ASNs are authorized providers. Network operators leverage this information to validate BGP paths, enabling detection and prevention of route leaks while reducing exposure to forged routes.

The ASPA profile draft establishes this definition:

A Provider AS (PAS) is a network providing connectivity between networks – it provides transit services to the customer. That is: The provider may propagate Border Gateway Protocol (BGP) routes received from any direction to their customers. For example, routes the provider learned from its own providers, lateral peers, and other customers. The provider may also announce a default route to their customers. The provider may propagate BGP routes received from the customer in any direction. For example, to the provider's providers, lateral peers, and other customers.

A Profile for Autonomous System Provider Authorization

A critical distinction: an AS qualifies as a provider even when transit occurs only intermittently, in specific geographic locations, or for particular route subsets. Partial-transit and backup-transit scenarios exemplify situations where the AS should appear in the relevant ASPA provider list.

Provider relationships need not be unidirectional. An AS may function as a customer to one AS for certain prefixes while serving as a provider for different prefixes—a configuration termed 'complex' peering in RFC 9234. For ASPA purposes, each AS in such an arrangement must list the other AS as a provider.

ASPA configuration at Internet Exchange Points

IXP route server architectures fall into two categories, each demanding distinct ASPA configuration approaches from participating networks.

Transparent (Layer 2)

The transparent configuration represents the predominant IXP route server design. Since the IXP does not insert its own ASN into the AS path of forwarded BGP announcements, IXP participants should not list the IXP's ASN as a provider in their ASPAs.

Because the route server operates transparently, the routing relationships between IXP participants retain significance for ASPA validation. Where one participant acts as a customer of another, the customer must include the provider participant's ASN in its ASPA provider list.

Non-transparent (Layer 3)

Layer 3 route servers enable connectivity across geographically distributed networks beyond a single switch fabric, typically employing IP or Multiprotocol Label Switching (MPLS). Pure Layer 2 designs attempting the same scope risk broadcast storms, Spanning Tree Protocol (STP) loops, and MAC table scaling problems.

In non-transparent mode, the IXP appends its ASN to the BGP message path. The IXP functions as a provider to each participant, and participants must include the IXP's ASN in their ASPA provider lists.

A non-transparent IXP maintains no ASPA providers itself. Its ASPA contains a provider list with a single AS0 entry, mirroring the Route Origin Authorization (ROA) convention where AS0 signifies no valid origin ASNs for a given prefix.

Managing risks in ASPA deployment

Risk: Misconfigured ASPAs

Like ROAs, an incorrectly configured ASPA can inflict significant damage on the issuer, potentially invalidating all routes involving their customer ASN.

Mitigation: Suggestions and BGP validation

The MyAPNIC ASPA interface reduces misconfiguration risk by offering recommendations grounded in BGP observations. ASPA modifications undergo validation before submission to prevent invalidation of active BGP routes.

Risk: Delayed validation deployment increases workload

Operators must verify that misconfigured ASPAs will not disrupt connectivity before enabling validation. As ASPA numbers climb, ASN holders face mounting effort to identify and remediate misconfigurations prior to validation activation.

Mitigation: Deploy ASPA validation early

Early validation deployment can ease operational burden on network operators. With relatively few ASPAs in circulation, misconfigurations become simpler to spot and fix. Once validation is active, subsequent issues from ASPA issuance typically fall to the responsible ASN holders to resolve.

Creating an ASPA in MyAPNIC

To establish an ASPA, sign into MyAPNIC and proceed to Route Management > Autonomous System Provider Authorization (ASPA). Select Create ASPA, input the ASPA details, and submit. The request enters the Pending queue. After reviewing pending changes and confirming accuracy, click Commit to publish the ASPA.

Ongoing support and resources

ASPA remains a nascent routing security technology, and additional questions will likely surface as adoption expands and operators activate validation. APNIC remains committed to supporting the community through simplified ASPA deployment guidance, validation assistance, and a maintained central FAQ. For ASPA inquiries, contact helpdesk@apnic.net.