Zusammenfassung

  • Job Snijders und Ties de Kock vom RIPE NCC verfassten RFC 9697, einen IETF-Standard vom Dezember 2024.
  • Ein Validator vergleicht bereits gesehene Seriennummern und Hashwerte; bei einer Änderung warnt er und lädt den neuesten vollständigen Snapshot.

Nummer 1774 hat ein Gedächtnisproblem

Das Beispiel in RFC 9697 lässt die Versionsnummer von 1774 auf 1775 steigen. So weit, so alltäglich. In der neuen Mitteilung hat aber das alte Delta 1774 einen anderen Hash als zuvor. Die 1773 bleibt unverändert. Die Schublade trägt dasselbe Schild, doch ihr Inhalt wurde ausgetauscht. Die Zahlen bilden einen erklärenden Standardfall. Job Snijders und sein Mitautor Ties de Kock vom RIPE NCC leiteten daraus eine konkrete Kontrollfrage für Validatoren ab.

RPKI liefert signierte Objekte, mit denen Netze den Ursprung von Routen bewerten. RRDP verteilt diese Objekte als Folge kleiner Änderungsdateien, der Deltas. Ein Validator lädt zunächst einen vollständigen Snapshot und danach nur noch die fehlenden Änderungen. Eine Aktualisierungsmitteilung nennt Sitzung, Seriennummern und Hashwerte. Statische Dateien lassen sich bequem über Webserver und Caches verteilen. Dafür muss eine alte Datei unter derselben Kennung ihren Inhalt behalten.

Zwei Validatoren können zu verschiedenen Zeiten jeweils eine andere Fassung der 1774 erhalten und trotzdem dieselbe Sitzung und dieselbe neueste Seriennummer anzeigen. Eine Überwachung, die nur diese beiden Werte vergleicht, meldet Einigkeit. Lokal liegen bereits zwei verschiedene Bestände. Snijders und de Kock empfehlen, die Paare aus Nummer und Hash der letzten erfolgreich gelesenen Mitteilung aufzubewahren. Bei der nächsten Abfrage werden die Nummern verglichen, die in beiden Mitteilungen stehen. Ändert sich ein alter Hash, soll der Validator warnen und den aktuellen vollständigen Snapshot laden.

Snijders hatte die Tücken der Verteilung schon in seinem Bericht über OpenBSD rpki-client von 2021 beschrieben. Hinter einem Load Balancer waren RRDP-Server nicht immer gleich weit: Der eine kündigte ein neues Delta an, das der andere noch gar nicht liefern konnte. Dieser Wettlauf ist ein anderes Problem als das nachträglich veränderte Delta aus RFC 9697. Beide führen an dieselbe nüchterne Stelle: Signierte Objekte müssen auch verlässlich und in der richtigen Reihenfolge ankommen.

Ein auseinandergeratener Cache kann laut RFC gültige Nutzdaten auslassen oder Daten behalten, die eine Zertifizierungsstelle zurückziehen wollte. Eine eigentlich gültige Routenankündigung kann dadurch auf unbestimmte Zeit als unbekannt oder ungültig erscheinen. Solche Sitzungen dauern mitunter Monate. Wer die Gegenwart prüfen will, muss die Fingerabdrücke von gestern aufheben.