Radar adds RPKI ASPA path validation tool

Radar adds an ASPA validation tool ↗ to its Routing section ↗. Enter a BGP AS_PATH and the tool checks it against the Autonomous System Provider Authorization (ASPA) ↗ records currently published in the RPKI, returning a verdict of Valid, Invalid, or Unknown. An Invalid verdict means no chain of provider authorizations covers the whole path, which is the signature of a route leak.

Validation follows draft-ietf-sidrops-aspa-verification ↗, so verdicts match those produced by validators implementing the same draft. The draft is still a work in progress and not yet an RFC.

Enter a path

Paths are read in BGP wire order: the rightmost AS is the origin, and the leftmost AS is the one closest to the collector or router that observed the route. AS numbers can be separated by spaces, commas, or hyphens, with or without an AS prefix. The full ASPA snapshot is loaded into the browser once, so the verdict, graph, and trace update as the path is edited, with no further requests. A set of example paths covers the interesting cases, including a route leak with an AS0 ASPA, where an AS declares that it has no providers at all.

Choose an algorithm

The draft defines two verification algorithms that differ only in whether a down-ramp is permitted:

• Upstream (section 5.4 ↗) — for routes received from a customer, peer, route server client, or route server. Only an up-ramp is permitted.
• Downstream (section 5.5 ↗) — for routes received from a provider. Both an up-ramp and a down-ramp are permitted.

An up-ramp is the run of consecutive customer-to-provider hops from the origin to the apex of the path, and a down-ramp is the equivalent run from the announcing neighbor back to that apex. The tool evaluates both algorithms at once and labels each with its verdict, so a path that is legitimate when received from one session type and a leak when received from another is visible without switching modes. Selecting an algorithm drives the graph and the trace.

Read the result

The ASPA validation graph draws the path hop by hop, labeling each AS with its role, whether it publishes an ASPA, and how many providers that ASPA authorizes. Every hop is marked Provider+, Not Provider+, or No attestation, and the maximum and minimum bounds of each ramp are drawn against the length of the path. Hops that no ramp reaches are highlighted, because a path the ramps cannot cover end to end is Invalid. The accompanying ASPA records table lists every AS in the path with its ASPA status and its authorized providers, each linked to its Radar AS page.

Follow the algorithm

The Algorithm step by step section shows the derivation rather than just the answer. Two columns run the same scans under different stopping rules: the upper bounds, which test for Invalid and stop only on Not Provider+, and the lower bounds, which test for Unknown and also stop on No Attestation. A hop is Not Provider+ when the AS publishes an ASPA that does not list the next AS as a provider, and No Attestation when the AS publishes no ASPA at all. Each column lists the outcome for every hop scanned, marks where the scan stopped, gives the resulting ramp length, and then evaluates the verdict rule with the numbers filled in.

Share a validation

The path and the selected algorithm are kept in the URL, so a link reproduces a result exactly — for example, this route leak with an AS0 ASPA ↗. Appending &mode=upstream pins the link to the upstream algorithm. The graph is a standard Radar widget, so it can also be embedded or shared as an image.

The records behind the tool are the same ones served by the /bgp/rpki/aspa/snapshot endpoint of the ASPA API, and the number of records loaded and the snapshot timestamp are shown alongside the input.

Try the ASPA validation tool ↗ with a path of your own.