ASPA: Autonomous System Provider Authorizations

ASPA: Autonomous System Provider Authorizations

Recognizing that BGPsec’s in-band cryptographic overhead rendered it operationally unviable, the IETF SIDROPS working group designed Autonomous System Provider Authorization (ASPA) (draft-ietf-sidrops-aspa-profile and draft-ietf-sidrops-aspa-verification). ASPA provides practical, scalable protection against both route leaks and forged-origin path hijacks using the existing out-of-band RPKI infrastructure.

What ASPA Is and the Problem It Solves

ASPA shifts the security verification model from signing every dynamic route announcement to publishing verified out-of-band statements of upstream provider relationships:

• In BGP, a route leak occurs when a customer forwards a route learned from one provider to another provider.
• A forged-origin hijack occurs when an attacker fakes an adjacency to a legitimate origin.
• Both attacks violate the fundamental commercial topology of the Internet: a customer only sends routes to its upstream providers; a provider never routes through a customer to reach the global transit web.

ASPA allows an Autonomous System to formally publish a signed object stating: “These are the only ASNs that are authorized to act as my upstream transit providers.”

ASPA Structure: Customer, Provider and Peer Relationships

An ASPA is an RPKI signed object cryptographically bound to a Customer ASN:

ASPA Object Payload:
  CustomerASID: AS65001
  ProviderASSet: [
    AS174 (Cogent),
    AS2914 (NTT),
    AS3356 (Lumen)
  ]

This simple list asserts that AS65001 only purchases transit from AS174, AS2914, and AS3356. If a route appears on the Internet with AS_PATH: [AS7018, AS65001, ...], but AS7018 is not listed in AS65001’s ASPA object, downstream routers know that AS7018 has no legitimate commercial authority to act as AS65001’s provider!

Integration with the RPKI Trust Infrastructure

Like ROAs, ASPA objects: - Are issued under the resource holder’s RPKI CA. - Are verified against the RIR Trust Anchor root certificates. - Are downloaded and validated by relying party validators (such as Routinator or rpki-client). - Are delivered to routers over the RPKI-to-Router (RTR) protocol version 2 (RFC 8210-bis).

Because ASPA objects represent static business contracts rather than dynamic route states, a single ASPA object covers all prefixes originated by that AS. The total global ASPA dataset requires only tens of thousands of records, fitting comfortably inside router RAM.

How ASPA Validation Affects Route Selection

When a router evaluates an incoming AS_PATH, it runs the ASPA Verification Algorithm:

[Inbound BGP Route]
         |
         v
Deconstruct AS_PATH into directional hop pairs: (AS_i -> AS_{i+1})
         |
         v
Compare hop pairs against local ASPA database:
- Is AS_{i+1} listed in ASPA(AS_i)? (Valid Upstream)
- Is AS_i listed in ASPA(AS_{i+1})? (Valid Downstream)
         |
         +---------------------------------------+
         |                                       |
         v                                       v
No valley violations found?             Illegal valley sequence detected:
State: VALID                            - Customer -> Provider -> Customer -> Provider
                                        - Forged direct adjacency
                                                 |
                                                 v
                                        State: INVALID -> REJECT ROUTE!

ASPA assigns one of three verification states to the path: 1. Valid: The sequence of AS hops complies strictly with the Gao-Rexford model of provider-customer hierarchy. 2. Invalid: At least one hop pair is demonstrably contradicted by an authoritative ASPA record (e.g., an unlisted AS acting as a provider, or an illegal valley route leak). 3. Unknown: Insufficient ASPA records exist to determine path validity.

Routers configure inbound policies to unconditionally drop ASPA Invalid routes, neutralizing route leaks and forged-origin hijacks before they can enter the Loc-RIB.

Current Deployment Status and Standardization Progress

As of 2026, ASPA represents the most actively developed and promising routing security protocol in the IETF: - Supported in open-source validators (Routinator, rpki-client, FORT). - Production implementations running on open routing platforms (BIRD 2.15+, FRR). - Active commercial trials and interoperability testing across Tier-1 backbones (NTT, Cloudflare, Lumen). - Widespread deployment of ASPA alongside RPKI ROV promises to close the path-manipulation loophole that has plagued BGP for thirty years.