Summary

  • AFRINIC’s hosted Routinator interface can look up an origin ASN from BGP and then validate the resulting prefix–ASN pair against RPKI. That is a compound observation, not one lookup.
  • In a frozen public example, the search response named riswhois, selected AS33764 for 196.216.2.0/23 and labelled it an exact match, but returned no BGP snapshot time. The validity response returned valid and a generatedTime, but no BGP source or observation time.
  • The interface separately publishes freshness for RPKI, BGP and RIR allocation feeds. The issue is therefore not concealed freshness; it is that one query result does not bind the source snapshots that produced it.
  • AFRINIC should offer a compact compound-validation receipt: requested inputs, lookup mode, selected BGP tuple and snapshot, Routinator version and serial, VRP result, response time and a digest. This would document a diagnostic judgment without dictating routing policy.

A helpful checkbox changes the object being proved

Most route-origin checks begin with a pair: a prefix and an autonomous-system number. The pair is then compared with validated RPKI payloads. AFRINIC’s public Routinator interface offers a useful shortcut. A user may enter a prefix, enable “Validate Prefixes for ASN found in BGP”, and let the application find the origin ASN. The interface also lets the user choose whether that origin comes from an exact BGP prefix match or the longest matching prefix.

The convenience is real. It removes transcription, makes exploratory diagnosis quicker and helps a user who knows the address block but not the currently observed origin. AFRINIC’s Resource Certification page points readers toward validators, while the hosted interface describes itself as a place to perform a prefix check and inspect the last validation run. NLnet Labs’ documentation describes the same user-interface role. Nothing about this is inherently suspect.

But the checkbox changes the evidentiary object. If the user supplies both prefix and ASN, the checker evaluates an asserted tuple. If the application supplies the ASN, it first makes an observation about BGP, selects a tuple under a matching rule and only then asks the RPKI validator for a state. “Valid” is the final label on two operations:

  1. which route-origin pair the BGP source supplied; and
  2. what the current validated RPKI payload set said about that pair.

Those operations have different data owners, update rhythms and failure modes. A route collector can change while the RPKI set remains fixed. A ROA can change while the BGP observation remains fixed. The exact-match control can produce a different selected tuple from the longest-prefix control. A later screenshot of a green result cannot disclose which of those facts moved unless the result carries their provenance.

The live service already exposes most of the evidence

The strongest case for the existing design comes from the interface itself. Its Data Freshness section publishes separate rows for RPKI, BGP and RIR data. The RPKI status endpoint identifies the Routinator version, a validation serial, the start and completion fields for an update, its duration and detailed counts by trust anchor. The companion source-status endpoint identifies riswhois as the BGP source and publishes a serial and lastUpdated value. It does the same for allocation feeds from AFRINIC and the other RIRs.

The search result is also better structured than a generic web answer. It labels metadata by source type. In the frozen example, a query for 196.216.2.0/23 returned the same prefix. One metadata record identified an AFRINIC allocation source. A second identified a BGP source, riswhois, gave AS33764 as the origin and labelled the relationship exact-match.

The subsequent Routinator request evaluated AS33764 and 196.216.2.0/23. It returned valid, showed a matching VRP for AS33764 covering 196.216.2.0/23 with maximum length 24, and included a generatedTime. This is useful diagnostic evidence. It reveals the compared tuple and the authorization that matched it. It neither hides the RPKI state nor asks a reader to infer the reason from a colour.

The limitation is narrower. The BGP search object did not contain its feed’s lastUpdated value. The validity object did not contain riswhois, the selected match rule, a BGP observation time or the allocation snapshot. The user could visit the separate status endpoint and manually join those facts. The returned query result did not make that join durable.

This distinction matters because a global freshness row and a per-query receipt answer different questions. The global row says when a feed was last refreshed around the time someone looked. The receipt says which feed state, rule and selected tuple belonged to this result. If the feed updates after a screenshot but before an engineer opens the freshness page, the page describes a later world. Repeating the query creates a new observation; it does not reconstruct the old one.

Valid is not a routing instruction

Restraint is essential here. The observed result does not prove that any production router accepted the route. RPKI origin validation compares an observed route-origin tuple with validated authorization payloads. A valid state means at least one covering VRP matches the prefix length and origin ASN under the validator’s rules. It does not say that the path is short, stable, legitimate in every contractual sense, free of leaks, preferred by local policy or even selected by an operator.

Nor does the allocation feed decide RPKI validity. In the public interface it supplies classification and related-prefix context. That context can be valuable for navigation, but an allocation record, a BGP announcement and a VRP are separate claims. Combining them on one screen should not collapse their authority.

The frozen query is similarly bounded. It shows the shape of one public exchange on one day. It is not a census of AFRINIC resources, a claim about every origin observed by RIPE RIS, or evidence of an incorrect result. No outage, attack, stale route, member mistake or missing private log follows from it.

The proper claim is almost architectural: the service lets a result depend on a BGP-derived input, while the portable validity record retains only the RPKI-side generation time. That is enough to make reproducibility a legitimate design question without turning it into an incident.

Give the result a compound-validation receipt

AFRINIC need not publish a packet trace or a member’s private troubleshooting history. A small receipt can preserve the decision boundary:

  • the prefix entered by the user and any ASN entered explicitly;
  • whether BGP-assisted lookup was enabled;
  • exact-match or longest-matching-prefix selection;
  • the selected prefix, origin ASN and BGP source identifier;
  • the BGP source serial and lastUpdated timestamp;
  • any allocation source shown for context, with its serial and timestamp;
  • Routinator version, validation serial and completed-run time;
  • the validation state and digests of the matched or unmatched VRP tuples;
  • response generation time, receipt digest and a supersession link if a later correction is issued.

The receipt should say what each field proves. The BGP serial identifies an observation set; it does not certify global propagation. The allocation source identifies registry context; it does not authorize an origin. The RPKI serial identifies a validator state; it does not command a router. The result records a comparison, not an operational mandate.

This is more than a longer JSON response. It is a rule for preserving joins. The source-status endpoint can remain the broad operational view. The per-query endpoint can embed or reference the precise source versions it consumed. A user who saves the receipt can later show that the application selected a particular ASN under a particular match mode and evaluated it against a particular RPKI run. Someone who cannot disclose the prefix publicly can still retain the full receipt inside a ticket and share only its digest, source clocks and result class.

The right analogy is a measurement certificate, not a traffic light

A traffic light is designed for immediate action. Its colour is enough because the controller and the driver share the same moment. A route-origin diagnostic often travels. It enters a support ticket, an audit note, a change proposal or an incident timeline. Once it travels, the time and input lineage become part of the statement.

That is why the remedy should remain modest. AFRINIC does not need to promise that its hosted checker is the universal truth about BGP. It should make the checker’s own observation reproducible. A red or green state can remain prominent for a human reader, but the downloadable record should carry the facts from which that state was assembled.

The public service has already done the hard conceptual work by admitting that RPKI, BGP and allocation data have separate clocks. The next step is to stop those clocks from falling apart when one result leaves the page.

Sources

The service identity and AFRINIC context are documented on the AFRINIC Resource Certification page and the hosted Routinator interface. The frozen technical record uses the Routinator status endpoint, the BGP and RIR source-status endpoint, the sample prefix search and the corresponding RPKI validity response. The interface role is described in the NLnet Labs Routinator documentation, while the observed BGP lookup and freshness logic is visible in the versioned interface bundle.