SYSTEM Cited by 1 source
ASPA (Autonomous System Provider Authorization)¶
ASPA is an IETF SIDROPS working-group draft standard (draft-ietf-sidrops-aspa-verification) for BGP path validation. It extends RPKI — previously used mostly for Route Origin Validation (ROV) — into a mechanism for detecting and rejecting route leaks on the global Internet.
The primitive¶
Each AS holder signs and publishes an ASPA object in RPKI that enumerates its authorized upstream provider ASNs. Consumers (validators, routers) download, validate, and consult these objects during BGP best-path selection.
An ASPA for AS X with providers {P1, P2, P3} asserts:
"My only authorized upstream providers are P1, P2, P3. Any
other AS that appears on a path … , P_other, X, ... where
P_other is supposed to be one of my upstreams is in
violation."
The AS0 member¶
A Tier-1 network — one that is transit-free (peers + its own customer cone, no upstreams) — uses the reserved AS0 in its ASPA provider list to explicitly declare "I have no upstream providers." This lets verifiers reject any path where the Tier-1 AS is downstream of some other AS.
From the Cloudflare Venezuela post:
"AS6762 is a Tier-1 transit-free network, and they would use the special reserved 'AS0' member in their ASPA signed object to communicate to the world that they have no upstream providers, only lateral peers and customers. Then, AS52320, the other provider of AS8048, would see routes from their customer with '6762' in the path and reject them by performing an ASPA verification process."
The validation algorithm¶
Given a received path P = A_n, A_{n-1}, ..., A_1, A_0
(origin A_0), ASPA verification checks each upflow
segment (customer-to-provider transitions):
- Walk the path from origin upward.
- For each consecutive pair
(A_i, A_{i+1})in the upflow direction, check whetherA_{i+1}is inA_i's ASPA provider list. - If any mismatch is found, the path is invalid (leak).
- At most one peer-peer transition is allowed mid-path; after that, only downflow (provider-to-customer) transitions may follow.
Relationship to other tools¶
- Complements OTC (RFC 9234): OTC is session-local and enforced in the protocol; ASPA is out-of-band (RPKI-signed) and validated at any vantage point that sees the route. Both wanted together.
- Supersedes Peerlock: Peerlock is operator-specific filter templates; ASPA is a globally- coordinated signing standard.
- Independent of ROV: ROV validates origin; ASPA validates path. Different anomaly classes, different objects.
Deployment status¶
As of the 2026-01-08 Cloudflare post:
- IETF SIDROPS draft, not yet a ratified RFC.
- RIPE released ASPA object creation in the RPKI Dashboard.
- Validator / router-side implementation still maturing.
Seen in¶
- sources/2026-01-08-cloudflare-a-closer-look-at-a-bgp-anomaly-in-venezuela — canonical wiki instance. Cloudflare's forward-looking mitigation pick for the exact class of leak dissected in the post. AS0 + AS6762 worked example spelled out.