Zusammenfassung

  • Eine peer-reviewte Studie von 2026 schätzt UPDATEs rund um rekonstruierte RPKI-Ereignisse auf weniger als 1 Prozent des beobachteten Volumens.
  • Die Methode rechnet alle UPDATEs im gewählten Konvergenzfenster dem Ereignis zu und kann den Anteil dadurch erhöhen.
  • Die Quote misst weder Aufwand je Peer noch Pfadwechsel, Route Refresh oder Erreichbarkeit.

Die kleine Quote beantwortet eine konkrete Frage

Der Befund verdient Anerkennung. Samuele Quinzi, Cristel Pelsser und Giuseppe Di Battista schätzen in einer peer-reviewten Veröffentlichung in Proceedings of the ACM on Networking das BGP-UPDATE-Volumen rund um ROA-Änderungen. Das Abstract berichtet, dass zugehörige Updates trotz wachsender RPKI-Nutzung und Routingtabelle unter einem Prozent des beobachteten Gesamtvolumens bleiben. Die konkrete Frage lautet: Dominieren diese Ereignisse den beobachteten Strom der Routingmeldungen? In der untersuchten Reihe nicht.

Quinzi erläutert im APNIC Blog, dass die Autoren Ereignisse aus historischen RPKI-Daten rekonstruieren und sämtliche UPDATEs innerhalb eines gewählten Konvergenzfensters als zugehörig zählen. Manche haben andere Ursachen. Das erweitert tendenziell den Zähler. Die Quote ist daher eine breite zeitliche Zuordnung, kein Nachweis, dass jede Meldung durch RPKI ausgelöst wurde.

Netzstabilität hat mehrere Maße

Die Quote vergleicht ereignisbezogene UPDATEs mit allen beobachteten UPDATEs. Sie bezeichnet weder betroffene Router noch Präfixe mit geändertem Validierungsstatus, veränderte ausgewählte Pfade oder unterbrochenen Kundenverkehr. Ein UPDATE transportiert Routinginformationen, misst aber nicht unmittelbar, ob eine Anwendung erreichbar bleibt.

RIPE RIS sammelt Routingdaten über BGP-Peerings. RRC00 ist als Multihop-Kollektor in Amsterdam mit globalem Umfang aufgeführt. „Global“ beschreibt seine Reichweite, nicht eine Messung jedes Weiterleitungspfads, der CPU-Last jedes Peers oder jeder Nutzersitzung. Die aggregierte Quote zeigt auch nicht, ob sich Meldungen auf wenige Peers konzentrieren.

Auch die Gegenbehauptung wäre zu weitgehend: Viele UPDATEs beweisen keinen Dienstausfall. Nachrichtenvolumen, Aufwand je Peer, Pfadwechsel, Konvergenzdauer und Erreichbarkeit sind verbunden, aber nicht austauschbar.

Route Refresh ist eine andere Belastung

RFC 9324 beschreibt einen getrennten Mechanismus: Nach neuen Validierungsdaten haben manche Implementierungen bei Peers Route Refresh angefordert, damit Routen neu bewertet werden. Der RFC warnt vor erheblicher Ressourcenlast für diese Peers und empfiehlt, betroffene Routen vorzuhalten, um unnötige Anfragen zu vermeiden. Er nennt auch Fälle, in denen ROV deaktiviert und Peerings beendet wurden.

Das ist ein konkretes Betriebsrisiko samt Gegenmaßnahme, keine Aussage über alle Implementierungen und keine Widerlegung der UPDATE-Quote. Route-Refresh-Anfragen und erneute Bekanntgaben müssen getrennt von den UPDATEs im Ereignisfenster gezählt werden.

Mehr Evidenz verlangt getrennte Messungen

Sinnvoll wären mehrere klar abgegrenzte Größen: UPDATEs je Ereignis und Peer; Route-Refresh-Anfragen und erneut bekanntgegebene Routen; Zeit bis zum stabilen Routingzustand; Häufigkeit und Dauer von Pfadwechseln; und, soweit verfügbar, unabhängige Erreichbarkeitssignale. Jede Messung braucht Beobachtungspunkt, Zeitraum, Nenner und Umgang mit Lücken.

Das historische RPKI-Archiv von RIPE arbeitet mit täglichen Snapshots. Laut APNIC können kurzlebige Änderungen dazwischenliegen. RPKI-Flutter beobachtet Ereignisse häufiger, aber über einen kürzeren jüngeren Zeitraum; der Gastbeitrag meldet ähnliche UPDATE-Schätzungen im Überlappungszeitraum. Das stützt die Rekonstruktion des verglichenen Nachrichtenvolumens, nicht automatisch Aussagen über Peer-Aufwand oder Nutzererlebnis.

Die faire Folgerung lautet weder „RPKI ist risikofrei“ noch „RPKI destabilisiert BGP“. Die Studie beruhigt bei einer engeren Frage: In der beobachteten Reihe stellen RPKI-Ereignisse keinen großen Anteil der UPDATEs. Für ein umfassendes Stabilitätsurteil muss klar sein, welche Ressource, Route oder welcher Dienst gemeint ist.

Quellen

Primärquellen und Protokollreferenzen: