RPKI-ASPA Topology

About the RPKI-ASPA Topology Graph

This page visualizes the deployed RPKI-ASPA topology of the Internet — every published RFC 9582 Autonomous System Provider Authorization, with optional cross-validation against CAIDA's inferred AS relationships.

What's an ASPA?

An ASPA is a cryptographically signed object in the Resource Public Key Infrastructure that lets an AS attest the set of upstream provider ASes it authorizes to carry its traffic. Joining all of them produces a directed graph of customer → provider relationships across the deployed Internet.

Data sources

• Validated ASPAs — Cloudflare's rpki.json, refreshed by this service's roa-checker store. Each entry names a customer ASN and the list of provider ASNs the customer has signed an authorization for.
• AS-relationship data (CAIDA) — the .as-rel.txt.bz2 file from CAIDA's serial-1 dataset, refreshed every 24 hours. Each line encodes an inferred provider/peer/customer relationship for an AS pair, derived from BGP path analysis across hundreds of route collectors.
• AS names — CAIDA's AS-organization data for the in-memory store, with a fallback to RIPE Stat's as-overview API for ASNs CAIDA doesn't cover (resolved lazily when an AS is selected).

Reading the graph

• Nodes are colored by role: customer only, provider only, both. Size scales with the AS's ASPA-cone (count of transitive customers).
• Edges point customer → provider. That's the authorization direction; data-plane traffic flows the other way.
• Mutual edges (each AS lists the other as provider) collapse into one magenta double-headed line.
• Layout is a d3 force simulation: hub ASes are pulled to the centre by many neighbours; leaf customers fling out to the periphery. Drag a node to reposition it.

Filtering & sizing

The floating control panel in the top-left of the graph has four knobs that change how the simulation looks without re-running the data load:

• Size by — choose whether node radius scales with direct degree (customers + providers) or with ASPA-cone (transitive customer count). The label threshold below tracks whichever metric you pick.
• Show labels for {metric} ≥ N — only ASes whose chosen metric meets this threshold get a visible AS-number label. Higher = quieter graph, only the biggest hubs are named.
• Hide nodes with degree < N — drops every AS whose total degree is below the threshold, then re-runs the force layout around the survivors. Useful for stripping the long-tail of stubs.
• Hide nodes with ASPA-cone < N — same idea on cone size. Setting this to e.g. 10 leaves only ASes that have at least 10 transitive customers, which surfaces the transit backbone.

Both hide-thresholds AND with each other and with the region filter, so they stack: e.g. region = NA, degree ≥ 10, cone ≥ 5 shows only the moderately-connected transit-bearing ASes anchored in North America. Every slider's value is encoded in the URL hash, so a filtered view is shareable.

Working with selections

• Click a node (or use the search box) to focus on it. The view re-centres on that AS, hides everything outside its ASPA-or-CAIDA neighbourhood, and opens a side panel listing its providers and customers.
• 1-hop role layout — when focused on a single AS, its direct neighbours are pinned onto fixed lines: provider-only neighbours on a horizontal line above the focus, customer-only neighbours on a horizontal line below. ASes that are both a customer and a provider sit on the left of the focus and appear on both lines at once — the real node on the provider line and a dashed "ghost" copy directly below it on the customer line, with a dashed vertical connector joining them. Section headers (Providers for AS… / Customers of AS…) sit above and below their respective lines so the role of every visible neighbour is unambiguous.
• Isolation — while focused, only the focused AS and its visible neighbourhood contribute to the simulation geometry. Everything outside that set is frozen and exerts no force, so the layout you see depends only on the AS's own structure.
• The URL hash tracks the selection (#asn=174) so views can be shared. Loading a URL with a target AS jumps straight to its focused view.
• Dismiss the panel via its × button or by clicking the background — the selection clears, the search box empties, and the graph zooms back out.

ASPA-cone & ASPA Rank

Each AS has a cone in this graph: the set of every AS that reaches it as a downstream customer through chained ASPA relationships — direct customers plus customers-of-customers, recursively. The AS itself is not counted, so a stub AS that nobody names as a provider has a cone size of 0; a Tier-1 transit provider that hundreds of networks have authorised as their (direct or indirect) upstream has a cone size in the hundreds.

• ASPA Rank (header button) lists every AS in the graph ordered by cone size, largest first. Each row shows rank, ASN, organisation name, cone size, and direct degree (customers↓ / providers↑). Click any row to focus the graph on that AS.
• Side panel shows the focused AS's ASPA-cone size as a stat row. Toggle Show entire ASPA-cone to expand the visible set from "this AS plus its 1-hop neighbours" to "this AS plus its full transitive customer cone" — useful for seeing how far an authorisation chain actually reaches. In cone mode the role-line layout is dropped (it's only meaningful for 1-hop); the cone is allowed to self-organise via the force simulation, and the country-anchored geographic layout is suppressed so the cone arranges itself purely on its own ASPA topology rather than along national lines.

This is the ASPA analogue of CAIDA's customer-cone metric: same idea, but computed strictly over the published-ASPA graph rather than inferred BGP relationships. So as ASPA deployment grows, every AS's rank in this list reflects how much of the deployed topology has explicitly authorised transit through it.

Compare CAIDA mode

Toggle Compare CAIDA in the header to overlay CAIDA's inferences on top of the published ASPAs. Each relationship gets a status:

• Consistent — both ASPA and CAIDA see a provider relationship. Edge fades into the background; side-panel rows show ASPA CAIDA.
• CAIDA: peer / CAIDA: customer — both datasets contain the pair, but CAIDA disagrees on what kind of relationship it is. Edge is highlighted; row shows CAIDA: peer or CAIDA: customer.
• ASPA only — CAIDA has no record of either direction for this pair. Arrowhead becomes an ✕; row shows ASPA alone.
• CAIDA only — CAIDA infers a provider for an ASPA-publishing AS that the ASPA leaves out. Edge rendered as a dashed cyan line with a ＋ arrowhead; row shows CAIDA alone. These are candidate ASPA omissions worth investigating.

CAIDA relationships are inferred from BGP paths and can be stale or wrong; an ASPA may also legitimately exclude a backup provider that isn't visible in the global routing table. Treat the disagreements as hypotheses, not verdicts.

This material is based on research sponsored by the National Science Foundation (NSF) grant OAC-2530871. The views and conclusions contained herein are those of the authors and should not be interpreted as necessarily representing the official policies or endorsements, either expressed or implied, of NSF.