Zusammenfassung

  • Der individuelle IETF-Entwurf vom 28. Oktober schlägt sechs neue RTR-Pakettypen sowie Ereignis- und Intervallbetrieb mit ausdrücklichem Abonnement vor.
  • Push Notify meldet einen neuen Stand, überträgt aber keine geänderten RPKI-Objekte. Periodic Update enthält den Datenstrom; RFC 8210 hat schon eine vom Cache ausgelöste Warnung.

Für einen Netzbetreiber zählt nach einer geänderten ROA die Zeit bis zu einer verwendbaren Aktualisierung im Router. Das Senden eines Alarms ist nur eine Zwischenstation. Der neue Push-Entwurf nennt Sicherheitsvorfälle als Grund für eine Reaktion binnen Sekunden. Seine Paketformate legen jedoch eine Lücke zwischen Eilmeldung und Datenannahme offen.

RFC 8210 lässt den Cache schon heute einen Serial Notify ohne vorherige Routeranfrage schicken. Der Router darf darauf sofort mit Serial Query oder Reset Query antworten, statt auf den Refresh-Timer zu warten. Der aktuelle 8210bis-Entwurf behält diese Trennung bei. Der Cache löst den Alarm aus, der Router fordert Änderungen an und erhält anschließend die Daten. Die Bezeichnung „Pull-Modell“ unterschlägt den ersten, aktiven Schritt des Cache.

Neu ist das Abonnement nach der ersten Synchronisierung. Ein Router kann ereignisgesteuerte Meldungen, regelmäßige Lieferungen oder beides verlangen und die Teilnahme wieder beenden. Sechs neue PDU-Typen sollen dafür registriert werden. Der Cache muss damit zusätzlichen Zustand für seine Abonnenten pflegen. Ein realer Zeitgewinn müsste diese Last rechtfertigen.

Der vorgeschlagene Push Notify enthält Abonnementkennung, Art der Änderung und Seriennummer. Als Beispiele nennt der Text ROAs, ASPAs und Routerschlüssel. Im Paketdiagramm findet sich keines dieser geänderten Objekte. Auch die anschließende Folge von Paketen, die nach dem Ereignis die Daten zum Router brächte, wird nicht festgelegt. Ein schnelleres Signal ist noch kein schnellerer neuer Validierungsstand. Die alte Serial-Notify-Nachricht konnte den Router bereits zu einer sofortigen Anfrage veranlassen.

Erst Periodic Update transportiert laut Entwurf Cache Response, mögliche Daten-PDUs und End of Data. Der Versand erfolgt im ausgehandelten Intervall. Dabei gibt der Cache die Seriennummer an, die er beim Router vermutet. Stimmt sie nicht mit dessen tatsächlichem Stand überein, muss der Router die Daten verwerfen. Dieser Abgleich schützt den Empfänger vor einer falsch angenommenen Ausgangslage. Er gehört deshalb zum Ende jeder seriösen Geschwindigkeitsmessung.

Im IETF-Datatracker steht der Text als individueller Standards-Track-Vorschlag mit I-D Exists. Reproduzierbare Latenzwerte und ein Einsatzversuch fehlen. Eine nächste Fassung könnte die Datenübergabe nach dem Ereignis und die Messbedingungen präzisieren. Bis dahin ist die dringende Spur ein Alarm, während die Datenspur einen Fahrplan hat.