Zusammenfassung

  • Validierungsserie 23421 des öffentlichen AFRINIC-Routinators 0.14.2 meldete 39.059 gültige Eingangs-VRPs, 8.212 Duplikate und 30.847 finale VRPs.
  • Serie 23422 meldete 39.058 Eingänge und 8.211 Duplikate, aber erneut 30.847 finale VRPs; die Einserbewegung lag vollständig bei IPv4.
  • Laut Routinator-Dokumentation entstehen Duplikate aus ROAs mit derselben Autorisierung. Bei mehreren Trust Anchors oder Repositories kann ihre Zuordnung mit der Verarbeitungsreihenfolge wechseln.
  • Die Aufnahmen nennen weder das betroffene Tupel noch die Quell-ROA und belegen keine BGP- oder Routerentscheidung. Nötig ist ein Herkunftsbeleg, der Quellen, Vielfachheit, finalen Satz und Routerbeobachtung getrennt verbindet.

Drei Zahlen, zwei Läufe und kein benanntes Objekt

Der erste abgeschlossene Lauf trägt die Seriennummer 23421 und endete am 29. August um 06:37:53 UTC. Für den AFRINIC Trust Anchor wies der Dienst 39.059 vorhandene und gültige VRPs aus. Davon wurden 8.212 als Duplikate gezählt. Unsichere und lokal gefilterte VRPs standen jeweils bei null. Die Rechnung war deshalb vollständig sichtbar: 39.059 minus 8.212 ergab 30.847 Beiträge zum finalen Satz.

Der nächste abgeschlossene Lauf, Serie 23422, endete um 06:57:08 UTC. Nun standen 39.058 Eingangs-VRPs und 8.211 Duplikate in der Tabelle. Das Ergebnis der Subtraktion blieb 30.847. Es hat sich also nicht bloß ein Gesamtwert um eins verschoben; zwei aufeinander bezogene Werte bewegten sich gemeinsam, bevor die Deduplizierung ihren finalen Output bildete.

Der Protokollfamilienvergleich grenzt die Stelle ein. Bei IPv4 sank total von 37.804 auf 37.803 und duplicate von 8.136 auf 8.135, während final 29.668 blieb. Die IPv6-Zeile blieb mit 1.255, 76 und 1.179 unverändert. Beide Läufe sahen 1.408 gültige und keine verworfenen Publikationspunkte.

Gleichzeitig änderte sich der ROA-Zähler: 12.171 gültige und keine ungültige ROA wurden zu 12.170 gültigen und einer ungültigen. Das sieht nach einer passenden Erklärung aus, ist aber noch keine. Der öffentliche Datensatz nennt nicht den Hash oder die URI dieses Objekts und verbindet es nicht mit der fehlenden Duplikatvorkommnis. Eine zeitgleiche Bewegung ist keine belegte Identität.

Damit endet die sichere Aussage früher, als es ein griffiges Verb nahelegt. Der Validator meldete in der späteren Serie eine gültige Eingangs-VRP und ein Duplikat weniger; die finale Anzahl blieb gleich. Nicht belegt sind Rücknahme, Neuemission, Reparatur, Absicht eines Ressourceninhabers oder Eingriff AFRINICs. Ebenso wenig ist eine Routenänderung belegt.

Selbst die Formulierung „derselbe finale Satz“ wäre stärker als die Beobachtung. Zwei Mengen können dieselbe Größe haben und unterschiedliche Elemente enthalten. Ein Tupel könnte ausgeschieden und ein anderes hinzugekommen sein. Die parallele Einserbewegung von Eingang und Duplikat passt gut zu einer verschwundenen redundanten Vorkommnis; beweisen kann das nur ein Inhaltsvergleich.

Das Wort Duplikat verdeckt vier unterschiedliche Ebenen

Eine Route Origin Authorisation ist ein signiertes RPKI-Objekt. Sie nennt ein Herkunfts-AS und enthält einen oder mehrere Präfixeinträge, gegebenenfalls mit Maximallänge. Das Objekt besitzt Zertifikats- und Publikationskontext. Es kann mehrere autorisierte Nutzlasten hervorbringen.

Eine Validated ROA Payload ist das verdichtete Ergebnis für die Herkunftsvalidierung: IP-Adresse, Präfixlänge, maximale Länge und Herkunfts-ASN. Dieses Tupel ist weder die ROA-Datei noch die BGP-Route. Mehrere gültige Objekte oder Publikationswege können dasselbe Tupel erzeugen.

Ein Duplikat ist bei Routinator eine zusätzliche Vorkommnis einer bereits vertretenen Autorisierung. Der finale Satz braucht dieselbe Anweisung nicht mehrfach. Eine solche Vorkommnis herauszunehmen bedeutet nicht, die Autorisierung als falsch zu verwerfen. Es bedeutet zunächst nur, Vielfachheit auf Eindeutigkeit zu reduzieren.

Eine BGP-Route ist wiederum eine beobachtete Kombination aus Präfix und einem aus dem AS_PATH abgeleiteten Ursprung. Bei der Herkunftsvalidierung ist sie Valid, wenn mindestens eine VRP passt; Invalid, wenn sie abgedeckt wird, aber keine VRP passt; und NotFound, wenn keine VRP sie abdeckt. Aus der Duplikatzahl eines Trust Anchors lässt sich keiner dieser Zustände für eine konkrete Route ablesen.

Danach folgt noch die lokale Entscheidung. Ein Cache kann den finalen Satz über das RPKI-to-Router-Protokoll anbieten. Ein Netzwerkbetreiber entscheidet, welchem Cache er vertraut, welche Serie sein Router erhalten hat und welche Policy auf einen Validierungszustand folgt. Der Validator dokumentiert seinen Output, nicht die Entscheidung aller Empfänger.

Diese Unterscheidung verteilt Verantwortung realistisch. Ressourceninhaber signieren Autorisierungen. Repository-Betreiber halten Objekte verfügbar. Validator-Betreiber wählen Konfiguration, Zeitpunkt und Zuordnung. Router-Betreiber setzen Routing-Policy. AFRINIC betreibt hier den beobachteten Dienst und seinen Trust Anchor, ist aber dadurch nicht Urheber jeder darunter publizierten ROA und nicht Entscheider jedes angeschlossenen Routers.

Ein Duplikatzähler misst lokale Vielfachheit, keine institutionelle Güte

Im Alltagsgebrauch klingt „Duplikat“ nach einem Fehler, der bereinigt werden sollte. In einer verteilten signierten Publikationsstruktur kann derselbe Inhalt aus Überlappung, Erneuerung, Migration, redundanter Veröffentlichung oder einem Fehler entstehen. Der Zähler kennt den Unterschied nicht.

Die Routinator-Dokumentation setzt deshalb eine wichtige Warnung direkt an die Kennzahl. Erscheint eine VRP über mehrere Trust Anchors oder Repositories, hängt es von der Verarbeitungsreihenfolge ab, welche Vorkommnis als Duplikat gilt. Diese Reihenfolge kann zwischen Validierungen wechseln; Zuordnung und Zahl können sich unerwartet verändern.

Das macht den Wert nicht nutzlos. Es macht ihn instrumentengebunden. Ein Duplikat ist die Aussage dieses Validators unter dieser Version, Konfiguration, Quellmenge und Reihenfolge. Wer daraus eine Eigenschaft des Ressourceninhabers oder des RIR ableitet, muss die fehlenden Belege ergänzen.

Aus demselben Grund taugen die Spalten verschiedener Trust Anchors nicht als Rangliste. Hohe und niedrige Duplikatzahlen können auf unterschiedliche Objektgraphen und Zuordnungen zurückgehen. Null ist kein Gütesiegel; eine große Zahl ist kein Schuldspruch. Ein seriöser Vergleich müsste dieselben Tupel, Quellen und Messregeln über Zeit verfolgen.

Die unveränderten 30.847 ziehen in diesem Fall eine nützliche Grenze. Die beobachtete Veränderung ging nicht mit einer Verringerung der finalen Anzahl einher. Das spricht gegen die Behauptung, der Validator habe allein deshalb eine einzigartige Routerautorisierung verloren. Es schließt aber weder einen Elementtausch noch eine abweichende Routeraufnahme aus.

Die richtige Frage lautet also nicht: „Warum hat AFRINIC so viele Duplikate?“ Sie lautet: „Welche Quellobjekte erzeugen dasselbe eindeutige Tupel, wie änderte sich ihre Vorkommniszahl zwischen zwei Serien, und blieb das Tupel im finalen Satz?“ Erst dann wird aus einem Dashboardwert ein prüfbarer Befund.

Ein ausführlicher Status ist noch kein Änderungsjournal

Der öffentliche Endpunkt ist bemerkenswert reich. Laut Dokumentation liefert er JSON-Informationen zu Trust Anchors, Repositories, RRDP- und rsync-Verbindungen sowie RTR- und HTTP-Sitzungen. Er ist die Datenquelle der Benutzeroberfläche, die Statistiken der letzten Validierung darstellt. Version, Seriennummer und Zeiten verankern die Beobachtung.

„Ausführlich“ bedeutet jedoch nicht, dass jede Differenz ihre Ursache mitführt. Zwischen 23421 und 23422 fehlt eine öffentliche Tabelle, die Quell-ROA-Hashes, Publikations-URIs, Zertifikatsbezüge, Tupel und Vorkommniszahlen verknüpft. Das System zeigt, dass der Zustand anders ist; es nennt das Subjekt der Änderung nicht.

Auch RTR-Sitzungsdaten schließen die Wirkungskette nicht. Eine Verbindung kann existieren, ohne zu beweisen, welche Serie vollständig übernommen oder wie eine konkrete Route behandelt wurde. Dafür wären ein Empfangsbeleg des Routers, die Cache-Serie, eine zeitgleiche BGP-Beobachtung und die angewandte Policy nötig.

Die Lösung besteht nicht in der Veröffentlichung interner Zugangsdaten oder vollständiger Topologie. Objekt-Hashes, öffentliche URIs, eindeutige Tupel, Statusübergänge und aggregierte Empfängerbelege lassen sich begrenzen. Das Ziel ist Rekonstruierbarkeit: Ein Dritter soll vom Zähler zum relevanten Objekt zurückgehen können.

Ein Herkunftsbeleg kann die Lücke mit wenigen Feldern schließen

Der Kopf des Belegs beschreibt das Messinstrument: Routinator-Version, Konfigurationsfingerprint, Validierungsserie, Start- und Endzeit, Trust-Anchor-Satz und Repository-Satz. Damit bleibt jede Zahl an ihren Kontext gebunden.

Für ein geändertes eindeutiges Tupel folgen Herkunfts-ASN, Präfix und maximale Länge. Dazu kommen Hashes und Publikations-URIs der Quell-ROAs sowie begrenzte Zertifikatsketten-Referenzen. Pro Lauf wird die Vorkommniszahl ausgewiesen und festgehalten, welche Vorkommnis der Validator welchem Repository oder Anchor als Duplikat zurechnete.

Ein Ursachenfeld darf nur belegte Kategorien annehmen: beobachtete Rücknahme, Neuemission, Validierungsfehler, nicht verfügbares Repository oder geänderte Zuordnung. Fehlt der Nachweis, ist ungeklärt ein korrekter Zustand. Spätere Erkenntnisse ergänzen oder ersetzen ihn nachvollziehbar, ohne den ursprünglichen Stand zu löschen.

Danach folgt der eigentliche Diff des finalen Satzes: Tupel eingetreten, ausgeschieden oder unverändert, gebunden an die Cache-Serie. Aussagen über Netzwerkwirkung stehen in einem getrennten Block und benötigen Routerempfang, Route und Policy. So spricht keine Ebene unbemerkt für die nächste.

Ein solcher Beleg könnte den aktuellen Fall schnell entdramatisieren: zwei Vorkommnisse wurden zu einer, das eindeutige Tupel blieb. Oder er könnte zeigen, dass die konstante Zahl einen Austausch verdeckt. Sein Zweck ist nicht, ein bestimmtes Ergebnis zu bevorzugen, sondern das Ergebnis beweisbar zu machen.

Schmale Registeraussagen sind stärker als große Deutungen

Die beiden Aufnahmen identifizieren weder ein betroffenes Netz noch einen Präfixinhaber. Sie zeigen keine geänderte BGP-Ankündigung und keine Routerentscheidung. Sie belegen auch nicht, dass AFRINIC eine fehlerhafte ROA korrigierte. Belegt ist nur die präzise Verschiebung im Validatorzustand.

Gerade darin liegt die institutionelle Aufgabe. Ein Register muss nicht aus jedem Messwert ein Urteil über die Welt ableiten. Es kann zuverlässig festhalten, welches signierte Objekt wann vorlag, welches Tupel daraus validiert wurde, wie der finale Satz aussah und welche Korrektur später hinzukam.

Die Autorität wächst nicht durch ein größeres Verb, sondern durch eine bessere Belegkette. Aus 39.059, 8.212 und 30.847 wird erst dann belastbare öffentliche Evidenz, wenn sich der eine verschwundene Zähleintrag zu seinem Objekt zurückverfolgen lässt.

Quellen