ASPA, or Autonomous System Provider Authorization, is an RPKI-based mechanism being developed to let an AS publish which other ASes are authorised as its providers. The goal is to validate important parts of the BGP AS path, addressing route leaks that ordinary ROAs cannot detect.
From origin authorisation to provider authorisation
An ASPA object associates a customer AS with a set of authorised provider AS numbers. Networks can use collections of these signed relationships to evaluate the direction and plausibility of paths learned through BGP. This is different from a ROA, which says who may originate an IP prefix. ASPA is about relationships between autonomous systems along the path. The verification algorithm is designed to identify paths inconsistent with the published customer-provider information while remaining deployable incrementally as coverage grows.
Why ASPA targets route leaks
Route Origin Validation can tell that the last AS in a path is allowed to originate a prefix, yet a route leak can still send that valid route through the wrong sequence of networks. Provider authorisations add information that BGP itself traditionally lacks. If widely deployed, ASPA could make certain classes of route leaks and forged paths easier to reject without requiring every AS on earth to adopt the mechanism at once.
Current status: still an Internet-Draft
As of September 2026, ASPA path verification is still IETF work in progress rather than a finished RFC. That status matters: terminology, algorithms and deployment guidance can change between Internet-Draft revisions. Early RPKI ecosystems may already support ASPA objects, but an article or configuration guide should not present today's draft behaviour as an immutable internet standard.