Zusammenfassung

  • APNICs Product Roadmap sieht für das dritte Quartal 2026 vor, in REx gegenwärtige und historische VRP-Informationen zu einzelnen Internetnummernressourcen darzustellen. Die öffentliche Karte legt Felder, Beobachtungsrhythmus, Validator und Archivgrenze noch nicht fest.
  • Ein signiertes ROA, das daraus abgeleitete VRP, die Bewertung Valid, Invalid oder NotFound einer konkreten BGP-Route und die lokale Routingentscheidung eines Betreibers sind vier eigenständige Nachweise.
  • Jede historische Periode braucht einen knappen Provenienzstreifen: Abfrageressource und Überdeckungsverhältnis, Präfix–maxLength–Origin-AS-Tupel, Beobachtungszeit, Datenstand, Ableitungsmethode, Abrufvollständigkeit und den Hinweis, dass Betreiberpolitik und tatsächliche Weiterleitung nicht dargestellt werden.

Eine Zeitachse verteilt Ursachen, ohne sie auszusprechen. Endet ein grüner Abschnitt am Montag und beginnt am Dienstag ein roter, ergänzt der Leser den fehlenden Satz: Jemand änderte eine Autorisierung, das System empfing die Änderung, ein Router reagierte. Vielleicht stimmt dieser Ablauf. Vielleicht liegen auf dem Bildschirm lediglich zwei Beobachtungen eines verteilten Systems nebeneinander.

APNIC kann diese Mehrdeutigkeit lösen, bevor sich die Darstellung verfestigt. Die aktuelle Product Roadmap enthält für Q3 2026 den Punkt „Display RPKI VRP information for individual INR in REx“. Zuständig ist das Information-Team; als Produkte sind REx und RPKI genannt. Die angestrebten Ergebnisse sind vernünftig: RPKI-Statusinformationen leichter zugänglich machen und einzelnen Internetnummernressourcen einen historischen Kontext geben.

Eine Roadmap-Karte ist keine fertige Schnittstellenspezifikation. Zum Zeitpunkt der Erfassung war das Changelog im maschinenlesbaren Datensatz leer. Der öffentliche Eintrag nannte weder die späteren Felder noch Erhebungsfrequenz, Validator, Trust-Anchor-Satz, Quellobjektkennungen, Vergleichsregeln oder Aufbewahrungsdauer. Daraus folgt nicht, dass APNIC intern keine Antworten hat. Es folgt lediglich, dass das öffentliche Versprechen die Art dieser Historie noch nicht definiert.

Diese Definition wird mit der Veröffentlichung sofort praktisch. Ein Screenshot landet in einem Abuse-Ticket. Ein Incident-Team legt den Balken neben einen BGP-Zeitstempel. Ein Käufer nimmt ihn in die Due Diligence zu einem Adressblock auf. Forschende zählen Wechsel. Eine komfortable Auskunftsseite wird zum Beweismittel, sobald andere sie zitieren.

Vier Aussagen mit demselben Präfix

Im RPKI tauchen Präfix und ASN auf mehreren Ebenen auf. Die gemeinsamen Kennungen beseitigen die unterschiedlichen Zuständigkeiten nicht.

Zuerst steht das ROA. APNIC beschreibt die Route Origin Authorization als digital signiertes Objekt, das festlegt, welches autonome System eine Route für ein IP-Präfix originieren darf. Es enthält das autorisierte ASN, das Präfix und die maximale Präfixlänge. RFC 9582 verlangt, dass die Relying Party das signierte Objekt und die ROA-spezifischen Bedingungen prüft, bevor sie es zur Validierung einer Routingankündigung verwendet. Schlägt eine notwendige Prüfung fehl, ist das gesamte ROA ungültig.

Danach entsteht das VRP. Es ist nicht bloß ein neuer Name für die signierte Datei. APNICs technische Erklärung beschreibt, wie Relying-Party-Software RPKI-Objekte abruft, kryptografisch validiert und Tupel aus ASN, ROA-Präfix, Präfixlänge und maxLength extrahiert. Das Validated ROA Payload ist ein abgeleitetes Ergebnis an einem bestimmten Validierungspunkt. Es bewahrt die für die Ursprungskontrolle nötige Autorisierung, belegt aber nicht, dass jeder andere Validator zur selben Sekunde denselben Satz erzeugte.

Valid, Invalid und NotFound beziehen sich auf eine Route. RFC 6811 nimmt das BGP-Präfix und dessen Origin-AS. Deckt mindestens ein VRP das Präfix ab, erlaubt dessen Länge und stimmt mit dem Ursprung überein, lautet das Ergebnis Valid. Gibt es Abdeckung, aber keine Übereinstimmung, lautet es Invalid. Ohne abdeckendes VRP entsteht NotFound. Ohne Route und Ursprung fehlt diesen Wörtern ihr grammatisches und technisches Subjekt.

Die Handlung gehört schließlich dem Betreiber. RFC 7115 überlässt der lokalen Policy, wie der Validierungszustand im Routing eingesetzt wird. Ein Netz verwirft Invalid, ein anderes beobachtet zunächst, ein drittes verbindet die Bewertung mit weiteren Attributen oder Ausnahmen. Im Zustand steckt kein universeller Befehl. Ebenso wenig beweist die BGP-Kontrollebene, welchen Weg Datenpakete tatsächlich nehmen.

Eine saubere Oberfläche hält diese Zuständigkeiten auseinander. Der Ressourcenhalter signiert eine Autorisierung. Eine Relying Party validiert und leitet ab. Ein Beobachter oder Router vergleicht eine konkrete Route mit dem Satz. Der Netzbetreiber entscheidet. REx kann verbindlich sagen, was sein dokumentiertes Verfahren beobachtet hat. Es kann nicht für alle nachgelagerten Systeme sprechen, nur weil überall dasselbe Präfix vorkommt.

Eine Lücke hat keinen eingebauten Grund

Ist ein VRP vorhanden, kann die Oberfläche seine Felder anzeigen. Ist es nicht vorhanden, entsteht ein Interpretationsraum.

Eine leere Periode kann auf die bewusste Rücknahme eines ROA folgen. Sie kann ebenso durch Ablauf oder Ungültigkeit eines Objekts, ein Zertifikats- oder Manifestproblem, verzögerten Abruf, einen Cache Reset, eine Archivlücke, einen Methodenwechsel oder eine unerwartete Beziehung zwischen Abfrageressource und abdeckendem Präfix entstehen. Der Balken allein kann diese Ursachen nicht unterscheiden.

Die belastbare Formulierung lautet: „In dieser REx-Beobachtung wurde kein anwendbares VRP abgeleitet.“ Sie ist nicht dasselbe wie: „Der Halter autorisierte das Präfix nicht mehr.“ Der erste Satz beschreibt einen Datensatz und einen Zeitpunkt. Der zweite schreibt einem Akteur Handlung und Ursache zu und benötigt dafür eigene Belege.

Diese Vorsicht behindert die Fehlersuche nicht. Mit Snapshot-Kennung, Methode und vorangegangenem Tupel kann ein Mitglied die Abweichung gegen lokale Daten prüfen. Forschende können eine Änderung im RPKI von einer Änderung des Archivs trennen. Ein unbeschriftetes Loch zwingt dagegen alle Beteiligten, zunächst die Behauptung zu zerlegen, die das Design nahelegt.

„Aktuell“ ist an eine Cache-Uhr gebunden

RFC 8210 macht den zeitlichen Charakter der Infrastruktur sichtbar. Ein RPKI-Cache ist dort eine zusammengeführte Kopie der veröffentlichten globalen RPKI-Daten, die Relying-Party-Software regelmäßig abruft. Die Seriennummer bezeichnet eine logische Version dieses Caches. Refresh-, Retry- und Expire-Intervalle steuern die nächste Abfrage, den erneuten Versuch und die maximale Nutzung älterer Daten. Kann der Cache kein inkrementelles Update mehr liefern, darf er einen Reset und eine vollständige Neuladung verlangen.

Die RFC hält auch fest, dass verteilte Caches nicht streng synchron sein können. REx kann zu einem bestimmten Zeitpunkt einen anderen Satz sehen als ein Validator in Tokio, Mumbai oder Auckland. Eine vorübergehende Differenz beweist weder Täuschung noch technischen Ausfall. Sie zeigt, dass Beobachtungsort und -zeit Teil des Ergebnisses sind.

Die im APNIC Blog veröffentlichte Untersuchung zur Synchronisation trennt Publication, Zwischen-Cache und Enforcement. Eine unvollständige oder alte Sicht könne falsche Validierungsresultate hervorbringen. Die Autoren definieren anschließend für ihre Messung, was als hinreichend frisch gilt. Sie verwandeln ein beruhigendes Adjektiv in eine prüfbare Bedingung.

REx sollte genauso vorgehen. Neben from und to braucht jede Periode einen tatsächlichen Beobachtungszeitpunkt, eine Zeitzone und eine Dataset-Version. Ändern sich Validator, relevante Trust-Konfiguration, Rekonstruktionslogik oder Vergleichsregel, muss ein Methodengrenzer sichtbar sein. Sonst sieht eine Änderung des Messinstruments aus wie eine Änderung der Autorisierung.

Der Beobachtungspunkt verlangt keine Offenlegung interner Serverstandorte, Zugangsdaten oder Schutzmechanismen. Er gibt nur dem öffentlichen Satz ein Subjekt: Dieser REx-Datensatz, nach dieser dokumentierten Methode erzeugt, war zu diesem Zeitpunkt vollständig oder in der angegebenen Weise eingeschränkt.

Eine Einzelabfrage kennt mehrere Präfixbeziehungen

Wer ein /24 eingibt, kann drei verschiedene Fragen stellen. Existiert ein VRP, dessen Präfix genau dem /24 entspricht? Deckt ein breiteres /16 das /24 ab und erlaubt maxLength diese Länge? Gibt es innerhalb des abgefragten Raums noch spezifischere Autorisierungen?

Alle drei Ansichten sind sinnvoll, aber nicht austauschbar. Die Abdeckungsregel aus RFC 6811 arbeitet mit Präfixbits und -längen; maxLength begrenzt anschließend, welche spezifischeren Ankündigungen passen können. Verschwindet die Beziehung hinter einer Farbe, fehlt gerade die Information, die das Ergebnis erklärt.

REx sollte das Verhältnis als eigenes Feld zeigen: exact, covering, more-specific oder eine klar definierte aggregierte Ansicht. Mehrere anwendbare VRPs müssen als Satz erhalten bleiben. Ändert er sich, sollte die Historie sagen, welches Tupel hinzukam, verschwand oder wechselte. Eine unveränderte Anzahl kann einen neuen Origin-AS, eine engere maxLength oder die Entfernung einer redundanten Autorisierung verdecken.

Der nötige Provenienzstreifen

Die Lösung ist kleiner als ein zweites Dashboard. Jeder aktuelle Zustand und jede historische Periode braucht zehn Antworten:

  1. Welche Nummernressource wurde eingegeben, und wie steht sie zum dargestellten Präfix?
  2. Wird ein signiertes ROA, ein abgeleitetes VRP oder das Resultat einer benannten Route gezeigt?
  3. Wie lautet das vollständige Tupel aus Präfix, maxLength und Origin-AS?
  4. Wann beginnt und endet die Periode, wann wurde tatsächlich beobachtet, und in welcher Zeitzone?
  5. Welche stabile REx-Release-, Dataset- oder Snapshot-Kennung kann zitiert werden?
  6. Welche Ableitungsmethode und Version war im Einsatz, sofern dies die Vergleichbarkeit berührt?
  7. Welche Trust Anchors und welcher begrenzte Abrufvollständigkeitsstatus gelten für den Snapshot?
  8. Liegt ein Methodenwechsel oder eine Archivlücke vor, damit fehlende Daten nicht als fehlendes VRP erscheinen?
  9. Wo stehen die aktuelle Definition und die nächste Beobachtung?
  10. Welche Grenze gilt: Kein bestimmter Betreiber-Cache, keine lokale Policy, keine gewählte Route und kein tatsächlicher Paketpfad werden nachgewiesen.

Diese Metadaten beschreiben die öffentliche Aussage. Sie fordern weder private Schlüssel und Mitgliederzugänge noch unveröffentlichte Vorfalldetails, interne Sammlungstopologie oder vertrauliche Netzpolitik.

Was die Historie belastbar belegen kann

Mit diesem Streifen darf REx starke, aber begrenzte Feststellungen treffen. In einem identifizierbaren Snapshot leitete die dokumentierte Methode dieses Tupel ab. Es blieb über mehrere Beobachtungen erhalten. Ein Tupel verschwand, während ein anderes auftauchte. Eine Periode ist wegen einer Sammlungslücke oder Methodenänderung nicht direkt vergleichbar. Dritte können Zählungen reproduzieren und Betreiber ihre lokale Sicht danebenlegen.

Nicht belegt wäre, dass der Halter beim ersten leeren Punkt absichtlich eine Autorisierung entzog. Ebenso wenig ist bewiesen, dass alle Relying Parties den Wechsel gleichzeitig sahen. Eine Route kann ohne genanntes Präfix und Origin-AS nicht als Invalid bezeichnet werden. Ob ein Netz sie verwarf, ob ein Hijack, eine Störung, eine Verkehrsverlagerung oder ein Diensteffekt folgte, verlangt andere Daten.

APNICs Beitrag zur Messung von ROAs und ROV liefert ein anschauliches Beispiel. Filtert ein Upstream Invalid-Routen, können alle single-homed Netze dahinter so aussehen, als betrieben sie selbst ROV. Das beobachtete Ausbleiben ist real; die Zuschreibung der Entscheidung ist falsch. Ein verschwundener Beobachtungspunkt verwandelt eine korrekte Messung in eine falsche Erzählung.

Die REx-Historie sollte daher als zuverlässiger Zeuge auftreten, nicht als allwissender Erzähler. Ein Incident-Team kann den Snapshot mit BGP-Beobachtungen, lokalen Validator-Ausgaben, Routerprotokollen, Aussagen des Halters und Datenebenenmessungen verbinden. Forschende erhalten eine versionierte Beobachtungsreihe. Mitglieder können eine reproduzierbare Zeile anfechten.

APNIC hat besseren Zugang und historischen Kontext versprochen, kein Urteil über jeden Router. Ein sichtbarer Provenienzstreifen hält dieses Versprechen exakt in seinem legitimen Umfang.

Quellen