Zusammenfassung

  • ROV kann eine Route verwerfen, die nicht zu den aktuellen ROAs passt, ohne den Präfixinhaber zu fragen. Das Netz entscheidet; eine Erklärung kommt womöglich nie zurück.
  • iROV schlägt eine signierte Sofortfreigabe samt Rückmeldung vor. Die genannten Erreichbarkeitsgewinne stammen aus einer Simulation, nicht aus einem weltweiten Produktivbetrieb.

Eine dringende Routenänderung macht die Lücke sichtbar. Während eines Angriffs lenkt ein Betreiber den Verkehr zu einem Abwehrdienst um, doch die neue Ankündigung widerspricht noch dem ROA, das Validatoren gespeichert haben. ROV handelt wie vorgesehen: Es markiert die Route als ungültig und verwirft sie. Der Inhaber erfährt möglicherweise weder den Ort noch das Ausmaß der Filterung.

Younsoo Kim, Seungjin Baek, Weitong Li, Tijay Chung und Min Suk Kang beschreiben iROV in ihrer Arbeit für USENIX Security 2026; Kang stellte sie auf der NANOG 98 vor. Ein Validator kann den Inhaber um eine zeitlich begrenzte, signierte Freigabe bitten. Die Antwort lässt sich an die Route heften, sodass nachgelagerte iROV-Netze sie lokal prüfen, statt erneut anzufragen. Zufallsbasierte Abfragen sollen die anfängliche Last begrenzen.

Die auffälligste Zahl: Die Erreichbarkeit bei dringenden Änderungen steigt der Arbeit zufolge von 23 Prozent auf beinahe 90 Prozent. Das ist das Ergebnis der groß angelegten Simulation der Autoren. Im zentralen Szenario ist die iROV-Nutzung auf Tier-1-Netzen auf 100 Prozent gesetzt; ROV-Nutzung und Abfragewahrscheinlichkeit werden je Netzebene angenommen. Die Weiterleitung folgt einem vereinfachten Modell mit Valley-free-Regeln und lokaler Präferenz. Die Autoren räumen ein, dass damit nicht die ganze Vielfalt realer Richtlinien abgebildet wird. Ihr BIRD/FORT-Prototyp lief in einer abgeschlossenen Testumgebung.

Beides belegt keine Leistung im weltweiten Betrieb.

Die Gegenleistung ist klar: Eine ungültige Route braucht weiterhin die kryptografisch prüfbare Zustimmung des Inhabers; bei fehlender oder fehlerhafter Antwort greift wieder die normale ROV-Verwerfung. Dafür muss jemand den Antwortserver betreiben, Schlüssel schützen, Abfragequoten festlegen, Meldungen triagieren und auf Anfragewellen reagieren, die selbst zum Vorfall werden können. Die Autoren beziffern diese Kosten nicht, weil sie vom jeweiligen Betrieb abhängen.

iROV ist ein ernst zu nehmender Entwurf und eine sinnvolle Betreiberfrage, aber kein bereits ausgerollter Schalter. NANOG fragt, welche Rückmeldung ROV liefern sollte und wie sich diese ohne untragbares Betriebs- oder Sicherheitsrisiko ergänzen lässt. Offen bleibt auch: Wer setzt die Parameter, wer trägt die Antwortarbeit und wann gilt eine Ausnahme als dringend?

Quellen: Arbeit bei USENIX Security 2026 · offizielle NANOG-98-Sitzung · RFC 6811: ROV · RFC 6482: ROA. · PDF original