Zusammenfassung

  • Das Sicherheitspatch-Fenster von APNIC ist für den 13. Oktober von 08:00 bis 09:00 Uhr (UTC+10) angesetzt. Die Mitteilung erwartet bis zu zwei Minuten Ausfall von rsync auf rpki.sub.apnic.net, aber keine Unterbrechung anderer RPKI-Dienste.
  • Laut der veröffentlichten CPS gehört dieser Endpunkt zum Publikationsdienst für selbstbetriebene RPKI-Clients. Aus der Mitteilung lässt sich weder das Wiederholungsverhalten einzelner Clients noch eine Änderung ihrer Caches oder eine Routingwirkung ableiten.

Analyse

In ihrer Service-Mitteilung vom 9. Oktober setzt APNIC für Dienstag, den 13. Oktober, eine Stunde an: von 08:00 bis 09:00 Uhr (UTC+10) sollen Sicherheitspatches für das RPKI-System eingespielt werden. Innerhalb dieses Fensters nennt die Mitteilung eine engere mögliche Unterbrechung: Der rsync-Dienst unter rpki.sub.apnic.net kann bis zu zwei Minuten nicht verfügbar sein. Andere RPKI-Dienste sollen laut APNIC nicht unterbrochen werden.

Das sind drei getrennte Aussagen: ein einstündiges Arbeitsfenster, eine mögliche Unterbrechung von höchstens zwei Minuten bei einem benannten rsync-Dienst und eine Erwartung für die übrigen RPKI-Dienste. Eine „einstündige RPKI-Störung“ würde den angekündigten Umfang ausweiten. Von „keiner Beeinträchtigung“ zu sprechen, würde den Hinweis für Clients ignorieren, die diesen Endpunkt verwenden.

Der Hostname hat in der veröffentlichten Certification Practice Statement (CPS) von APNIC eine konkrete Funktion. Das Dokument unterscheidet das Repository der APNIC-Zertifizierungsstellen von einem Publikationsdienst für selbstbetriebene RPKI-Clients. Für diesen Dienst nennt es rpki.sub.apnic.net für rsync und rrdp.sub.apnic.net für RRDP. Die CPS gibt den 4. Mai 2021 als Inkrafttreten an. Sie bietet damit Architekturkontext, aber keine aktuelle Bestandsaufnahme der Client-Konfigurationen im Jahr 2026.

Diese Trennung bestimmt die richtige Lesart der Mitteilung. Betroffen ist weder jede RPKI-Funktion von APNIC noch jedes Netz, das RPKI-Daten nutzt. Genannt wird eine Abrufmethode an einem bestimmten Repository-Endpunkt. Dass andere RPKI-Dienste voraussichtlich nicht unterbrochen werden, ist eine Prognose von APNIC; die Mitteilung beschreibt nicht das Verhalten jedes einzelnen Clients oder Zugriffspfads.

Die Protokollebene erklärt, warum diese Abgrenzung zählt. RFC 8897 beschreibt, wie Relying-Party-Software über die vom Ziel-Repository unterstützten Mechanismen – etwa rsync oder RRDP – signierte Objekte abruft und einen lokalen Cache aktualisiert. RFC 8182 definiert RRDP als HTTPS-basiertes Protokoll für den Repository-Zugriff. Daraus geht nicht hervor, welche Methode ein bestimmter Betreiber eingerichtet hat, ob seine Software automatisch auf eine andere Methode wechselt oder wann sein Cache wieder aktualisiert wird.

Ein kurzer Abrufausfall kann daher einen Abrufversuch bei einem Client verzögern, der auf diesen rsync-Endpunkt angewiesen ist. Er belegt für sich genommen weder einen veralteten bestehenden Cache noch eine Änderung an einer Route-Origin-Autorisierung oder am Umgang eines Routers mit einer Route. Die Mitteilung nennt keine Zahl betroffener Clients, keine Validator-Beobachtung, keine Routenänderung und keine Auswirkungen auf Nutzer. Die Arbeiten sind noch geplant; ein Ergebnis nach der Wartung gibt es noch nicht.

Die belastbare Aussage bleibt der Umfang: eine Stunde Arbeitsfenster, bis zu zwei Minuten erwartete rsync-Nichtverfügbarkeit an einem Endpunkt und keine erwartete Unterbrechung anderer RPKI-Dienste. Nach dem 13. Oktober können APNICs Service-Aufzeichnung und die lokalen Protokolle der Relying Parties die Prognose durch Beobachtungen ersetzen.

Quellen