Autonomous System Provider Authorization (ASPA) is a cryptographic framework that validates the full AS_PATH of BGP announcements, helping networks detect and block route leaks.

Path Validation Workflow

The process examines the advertised AS_PATH from both ends, confirming that each hop is an authorized provider. By comparing the upward and downward ramps, ASPA can identify valleys that indicate leaks.

• Up‑Ramp check: Starts at the origin and verifies each successive AS against its provider list.
• Down‑Ramp check: Begins at the destination and walks backward to confirm provider relationships.
• Both ramps must intersect otherwise the route is marked Invalid.
• Validation uses signed ASPA objects stored in the RPKI repository.
• Outcome influences route acceptance in BGP routers.

Key Components of ASPA Records

An ASPA record consists of a set of authorized upstream providers for a given AS, signed by the AS holder. These records are published alongside ROAs in the RPKI.

• Provider list: Enumerates AS numbers allowed to transit traffic for the holder.
• Signature: Cryptographic proof anchored in the holder's RPKI certificate.
• Validity period: Defines when the record is active.
• Versioning: Supports updates as business relationships change.
• Reference to ROA: Links the ASPA to the origin authorization for consistency.

Interaction with RPKI and ROA

RPKI provides the trust anchor for both ROA and ASPA objects, ensuring that origin and path checks share a common security base. While a ROA confirms who may announce a prefix, ASPA confirms who may carry it.

• ROA validates origin authenticity.
• ASPA validates AS_PATH relationships.
• Both rely on public key infrastructure defined by the RPKI.
• Mis‑aligned ROA and ASPA records trigger alerts in monitoring tools.
• Operators can withdraw or update records without affecting unrelated prefixes.

Deployment Monitoring with Cloudflare Radar

Cloudflare Radar offers a dashboard that tracks ASPA adoption across the five Regional Internet Registries (RIRs) and visualizes changes at the AS level. This view helps operators gauge ecosystem readiness.

• Time‑series graphs show ASPA deployment trends per RIR.
• Drill‑down to individual AS reveals current ASPA records and history.
• Alerts flag newly added or removed provider entries.
• Data is refreshed daily for near‑real‑time insight.
• Useful for audit trails during network redesigns.

Limitations and Future Directions

ASPA strengthens path validation but does not protect against every forged‑origin scenario, especially when a provider fabricates a peering link. Ongoing work aims to combine ASPA with additional attestations.

• Provider‑centric attacks remain a gap.
• Future proposals consider path‑authentication extensions.
• Integration with BGPsec could provide layered defense.
• Community adoption is critical monitoring tools encourage transparency.
• Operational guidelines are being drafted by IETF working groups.

For deeper technical guidance, see our Web Interoperability guide and the Service Worker deployment tutorial.