APNIC deployed support for managing Resource Public Key Infrastructure (RPKI) Autonomous System Provider Authorization (ASPA) objects in June this year. Since then, ASPA adoption has grown steadily, with 538 ASPA objects currently published under APNIC’s RPKI trust anchor.
On 30 September 2026, APNIC hosted a webinar for Members and the Internet community, ‘Understanding ASPA: The next step in routing security’ (recording available). As ASPA adoption grows, several common questions have emerged, particularly around the definition of a provider, the use of ASPA in Internet Exchange Point (IXP) environments, and the risks of signing and relying on ASPA records for Border Gateway Protocol (BGP) path validation.
What does ‘provider’ mean in ASPA?
An ASPA is a signed RPKI object that allows an Autonomous System Number (ASN) holder to declare its authorized provider (upstream or transit) ASNs. Network operators can use this information to validate BGP paths, helping to detect and prevent route leaks and reducing the risk of forged routes being accepted.
The ASPA profile draft has the following definition:
A Provider AS (PAS) is a network providing connectivity between networks – it provides transit services to the customer. That is:
A Profile for Autonomous System Provider Authorization
- 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.
The key point is that an AS is considered a provider even if it provides transit only some of the time, only at certain locations, or only for a subset of routes. Partial-transit and backup-transit arrangements are common examples where the AS should be included as a provider in the relevant ASPA.
Also, the provider relationship is not necessarily one-way. For example, it’s possible for an AS to act as a customer of another AS for certain prefixes, while acting as a provider for other prefixes. This is described as a ‘complex’ peering relationship in RFC 9234. Importantly for ASPAs, each AS in such a relationship lists the other AS as a provider.
How should ASPAs be configured for IXPs and their participants?
There are two types of IXP route server configuration, each requiring a different approach from IXP participants when creating ASPAs.
Transparent (Layer 2)
This is the most common IXP route server configuration. Because the IXP does not add its ASN to the AS path of the BGP announcements it forwards, participants do not list the IXP’s ASN as a provider in their ASPAs.
Because the route server is transparent, the routing relationship between IXP participants remains relevant for ASPA validation. For example, where one participant is a customer of another participant, the customer must include the provider’s ASN in its ASPA provider list.
Non-transparent (Layer 3)
Layer 3 route servers are commonly used to provide connectivity across wide-area networks beyond a single switch fabric, typically using IP or Multiprotocol Label Switching (MPLS). Attempting to achieve the same outcome with a purely Layer 2 design can result in broadcast storms, Spanning Tree Protocol (STP) loops, and MAC table scaling challenges.
In this non-transparent configuration, the IXP adds its own ASN to the path of the BGP messages. The IXP effectively acts as a provider for each participant, and participants should include the IXP’s ASN in their ASPA provider lists.
A non-transparent IXP does not itself have any ASPA providers. Its ASPA contains a provider list with a single AS0 entry. This mirrors the approach used in Route Origin Authorizations (ROAs), where AS0 indicates that there are no valid origin ASNs for a given prefix.
Are there any risks to creating ASPAs? How can those risks be mitigated?
Risk: Misconfigured ASPAs
As with ROAs, a misconfigured ASPA can have serious consequences for the issuer, including the potential invalidation of all routes that involve their customer ASN.
Mitigation: Suggestions and BGP validation
The MyAPNIC ASPA interface helps mitigate the risk of misconfiguration by providing recommendations based on BGP observations. ASPA changes are also validated before submission to ensure they do not invalidate any existing BGP routes.
Risk: Delayed validation deployment increases workload
Before ASPA validation can be deployed, operators must ensure that misconfigured ASPAs will not adversely affect connectivity. As the number of ASPAs grows, so too does the effort required for ASN holders to verify and correct any misconfigurations before validation can be enabled.
Mitigation: Deploy ASPA validation early
Deploying validation early can help reduce the operational burden on network operators. With relatively few ASPAs in existence, misconfigurations are easier to identify and correct. After validation has been enabled, any future issues resulting from ASPA issuance can generally be addressed directly by the ASN holders responsible for those ASPAs.
What is the most direct way to create an ASPA today?
To create an ASPA, log in to MyAPNIC and navigate to Route Management > Autonomous System Provider Authorization (ASPA). Select Create ASPA, enter the ASPA details, and submit the changes. The request will be placed in the Pending queue. Review the pending changes and, when satisfied, click Commit to publish the ASPA.
More questions?
ASPAs are still a relatively new routing security technology, and new questions are likely to emerge as adoption grows and more operators enable validation in their networks. APNIC will continue to support the community by helping to simplify ASPA deployment and validation, and by maintaining a central FAQ. If you have any questions about ASPAs, please contact helpdesk@apnic.net.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.