Zusammenfassung

  • Die von AFRINIC betriebene Routinator-Oberfläche kann eine Origin-ASN aus BGP ermitteln und das ausgewählte Präfix-ASN-Paar anschließend gegen RPKI prüfen.
  • Im gesicherten Beispiel lieferte riswhois für 196.216.2.0/23 die AS33764 als exakte Übereinstimmung. Die Suche enthielt keinen BGP-Aktualisierungszeitpunkt; die RPKI-Antwort enthielt valid und generatedTime, aber weder BGP-Quelle noch Beobachtungszeit.
  • Eine getrennte Tabelle veröffentlicht die Aktualität von RPKI, BGP und RIR-Zuteilungsdaten. Das Problem ist deshalb kein verborgenes Datenalter, sondern die fehlende Versionsbindung im einzelnen Prüfergebnis.
  • Ein kombinierter Validierungsbeleg sollte Eingabe, Auswahlregel, BGP-Tupel und Quellversion, Routinator-Version und -Serial, VRP-Ergebnis, Antwortzeit, Prüfsumme und Korrekturbezug festhalten.

Die Abkürzung erzeugt einen zweiten Beweisschritt

Bei einer klassischen Origin-Validierung stehen Präfix und ASN fest. Der Validator prüft, ob ein akzeptierter VRP die Route abdeckt und zu Origin und Länge passt. AFRINICs öffentliche Oberfläche bietet eine zweite Arbeitsweise: Der Nutzer gibt nur das Präfix ein und lässt die Origin-ASN aus BGP bestimmen.

Das ist praktisch. Störungsanalysen beginnen häufig bei einer Adresse, nicht bei einem vollständigen Routingdatensatz. Eine automatische Suche vermeidet Abschreibfehler. Außerdem macht die Oberfläche eine wichtige Wahl sichtbar: exakte Übereinstimmung oder längstes passendes Präfix. Diese Offenheit ist ein Pluspunkt des Produkts.

Mit der Auswahl ändert sich allerdings die Frage. Zuerst entscheidet eine BGP-Sicht, welches Paar geprüft wird. Danach klassifiziert Routinator genau dieses Paar anhand seiner validierten RPKI-Payloads. Die beiden Schritte können unabhängig fortschreiten. BGP kann einen neuen Origin zeigen, ohne dass sich ein ROA ändert. Ein ROA kann wechseln, während die beobachtete Route gleich bleibt. Auch die Matching-Regel kann das Prüfobjekt verändern.

Ein später gespeichertes valid ist deshalb das Ende einer Kette, nicht ihr vollständiger Nachweis. Wer nur die RPKI-Zeit kennt, weiß noch nicht, aus welchem BGP-Zustand die automatisch eingesetzte ASN stammte.

Das System liefert bereits fast alle Bausteine

Die stärkste Verteidigung des heutigen Dienstes ist seine eigene Transparenz. Der Bereich Data Freshness trennt RPKI, BGP und Zuteilungsquellen. Der Routinator-Status nennt Softwareversion, Validierungs-Serial, Aktualisierungsfelder und Zahlen je Trust Anchor. Der Status des Suchdienstes weist riswhois als BGP-Quelle aus und veröffentlicht Serial und lastUpdated. Auch die Zuteilungsdateien der fünf RIRs haben getrennte Zeitangaben.

Am 12. September 2026 wurde eine eng begrenzte öffentliche Transaktion gesichert. Die Suche nach 196.216.2.0/23 gab dasselbe Präfix zurück. Ein Metadatensatz nannte AFRINIC als Zuteilungsquelle. Ein zweiter nannte riswhois, die AS33764 und den Typ exact-match.

Die anschließende Routinator-Abfrage prüfte AS33764 und 196.216.2.0/23. Das Ergebnis war valid. Es zeigte einen passenden VRP mit derselben ASN, demselben Präfix und Maximallänge 24 sowie ein generatedTime. Der Dienst erklärt also die unmittelbare RPKI-Begründung und beschränkt sich nicht auf Ampelfarbe.

Im Übergang fehlt jedoch eine Naht. Das Suchobjekt enthielt nicht den lastUpdated-Wert von riswhois. Das Gültigkeitsobjekt enthielt weder riswhois noch den BGP-Beobachtungszeitpunkt oder die gewählte Matching-Regel. Die Version der Zuteilungsquelle, die der Oberfläche Kontext gab, war ebenfalls nicht Teil des Resultats.

Ein Mensch konnte den globalen Status parallel öffnen. Damit ist die Information auffindbar, aber nicht an den Befund gebunden. Sobald der Feed aktualisiert ist, beschreibt die Statusseite einen späteren Zustand. Eine Wiederholung ist eine neue Messung und keine Rekonstruktion der alten.

Was aus valid nicht folgt

Die beobachtete Einstufung sagt nicht, dass ein produktiver Router die Route angenommen hat. Sie sagt, dass mindestens ein validierter Payload Prefix, Länge und Origin abdeckte. Daraus folgen weder ein unverdächtiger AS-Pfad noch weltweite Sichtbarkeit, lokale Präferenz, störungsfreier Betrieb oder umfassende rechtliche Berechtigung.

Auch die AFRINIC-Zuteilungsdatei ist kein RPKI-Entscheider. Sie liefert Registrierungs- und Verwandtschaftskontext für Präfixe. Zuteilung, BGP-Ankündigung und kryptografische Autorisierung sind verschiedene Aussagen. Eine gemeinsame Darstellung darf ihre Verben nicht vereinheitlichen.

Das Beispiel belegt weder Ausfall noch Angriff, veraltete Route, Fehlverhalten eines Mitglieds oder falsche Validierung. Es sagt nichts darüber, welche internen Logs AFRINIC besitzt. Es zeigt nur, dass der öffentlich transportierbare Befund die beiden Quellzustände nicht selbst zusammenführt.

Ein Beleg für die konkrete Transaktion

Der vorgeschlagene Datensatz braucht keine vertraulichen Betriebsdetails. Er sollte enthalten:

  • angefragtes Präfix und gegebenenfalls manuell eingegebene ASN;
  • Status der BGP-Hilfssuche;
  • exakte oder längste Präfixübereinstimmung;
  • ausgewähltes Präfix, Origin-ASN und BGP-Quellkennung;
  • Serial und lastUpdated der BGP-Quelle;
  • Zuteilungsquelle und deren Version, soweit sie als Kontext angezeigt wird;
  • Routinator-Version, Validierungs-Serial und Abschlusszeit;
  • Zustand und Hashes passender beziehungsweise abweichender VRP-Tupel;
  • Generierungszeit, Hash des Belegs und Verweis auf eine spätere Korrektur.

Die Formulierungen sind Teil der Kontrolle. riswhois hat einen Origin „beobachtet“. AFRINIC hat Ressourcen „registriert“. Routinator hat ein Paar „verglichen“. Der Betreiber hat über Annahme, Warnung oder Filterung „entschieden“. Der Beleg darf keinen Beobachter zum Eigentümer einer fremden Entscheidung machen.

Ein solcher Beleg kann datensparsam bleiben. Bei öffentlichen Routendaten sind Präfix und ASN ohnehin sichtbar. In einem vertraulichen Kundenvorgang bleibt die vollständige Datei im Ticket; nach außen reichen Hash, Quellversionen, Zeiten und Ergebnisklasse. Interne Topologie und NOC-Kommunikation müssen nicht veröffentlicht werden.

Ein Diagnosewerkzeug soll kein zufälliger Schiedsrichter werden

Institutionelle Logos und einfache Farben erzeugen verkürzte Sätze. „Bei AFRINIC war die Route grün“ kann später zu „AFRINIC hat die Route genehmigt“ werden. Dabei verschwinden BGP-Sicht, Validatorzustand und lokale Betreiberentscheidung.

Der kombinierte Beleg schützt beide Seiten. Der Nutzer kann zeigen, was er gesehen hat. AFRINIC kann exakt begrenzen, was der gehostete Dienst geleistet hat. Softwaretests können feste Eingaben zwischen Versionen vergleichen. Audits können eine Quelländerung von einer Logikänderung trennen.

Die Oberfläche hat die richtige Einsicht bereits eingebaut: Ihre Daten haben verschiedene Uhren. Jetzt muss nur noch jedes Ergebnis die Uhren mitnehmen, von denen es tatsächlich abhing.

Quellen

Die AFRINIC-Seite zur Resource Certification stellt den institutionellen Zusammenhang her, die gehostete Routinator-Oberfläche bietet die Prüfung. Gesichert wurden der Routinator-Status, der Status der BGP- und RIR-Quellen, die Beispielsuche und die zugehörige RPKI-Gültigkeitsantwort. Die Routinator-UI-Dokumentation von NLnet Labs beschreibt die Aufgabe der Oberfläche; das versionierte UI-Bundle enthält die beobachtete BGP-Such- und Aktualitätslogik.