Zusammenfassung

  • RIPE-Vorschlag 2026-02 startet das Verfahren, wenn eine IP-Adresse innerhalb eines rollierenden 30-Tage-Zeitraums insgesamt 14 Tage auf einer genehmigten Infrastrukturliste steht. Danach erhält der Ressourcennutzer sieben Geschäftstage zur Abhilfe; nach bestätigter Compliance müssen Beschränkungen binnen eines Arbeitstags fallen.
  • Artikel 3.4 akzeptiert eine verifizierte Isolation der betroffenen Präfixe. Artikel 3.6 nennt diesen Weg nicht: Dort zählen das Entfernen von der Liste oder, falls RPKI betroffen ist, das Löschen des passenden ROA. Das Löschen eines ROA verändert den Nachweis der Ursprungsvalidierung; BGP-Routenrückzug und Präfixisolation sind getrennte Netzmaßnahmen.

Drei Fristen, zwei Prüfungen

Für einen betroffenen Ressourceninhaber klingt diese Fristenkette zunächst erfreulich konkret. Eine IP-Adresse muss in einem rollierenden 30-Tage-Zeitraum insgesamt 14 Tage auf einer genehmigten Infrastrukturliste stehen. Ein betroffener Netzbetreiber oder ein National CERT meldet den Treffer über ein RIPE-NCC-Supportticket, belegt mit automatisierter Telemetrie und Zeitstempeln oder kryptografischen Signaturen. RIPE NCC schickt eine nachverfolgbare Mitteilung an die Rechts-, Verwaltungs- und Abrechnungskontakte des Inhabers. Danach bleiben sieben Geschäftstage zur Abhilfe.

Nach bestätigter Compliance sollen die Beschränkungen binnen eines Arbeitstags fallen. Der Haken trifft den Inhaber, der den betroffenen Präfix am Netzrand bereits isoliert hat: Der Reparaturschritt ist anerkannt, der Start der Rückkehrfrist bleibt offen.

Die Abfolge passt auf eine Folie. Schwieriger ist die letzte Zeile: Was muss der Nutzer belegen, um die normale Arbeit mit dem Register zurückzubekommen?

Isolation zählt bei der Abhilfe, fehlt aber bei der Rückkehr

Artikel 3.4 räumt dem Nutzer während der Frist zwei Wege ein. Die betroffenen Präfixe können von den genehmigten Listen verschwinden, oder der Nutzer kann sie durch eine verifizierte administrative Maßnahme isolieren. Artikel 3.6 formuliert den Wiederherstellungstest anders. Die Beschränkungen werden aufgehoben, wenn die Präfixe nicht mehr auf den Listen stehen oder, falls RPKI beteiligt ist, das passende Route Origin Authorization (ROA) gelöscht wurde.

Der zweite Weg aus Artikel 3.4 ist verschwunden. Ein Betreiber kann ein Präfix an seiner Netzgrenze isolieren, während der öffentliche Listenverlauf den Eintrag noch enthält. Artikel 3.4 nennt das Compliance; Artikel 3.6 führt es nicht als Weg zurück auf. Für diese anerkannte Abhilfe fehlt in Artikel 3.6 ein Ereignis, das die Ein-Tages-Frist startet.

Das Löschen eines ROA wirft eine andere Frage auf. RFC 9582 beschreibt ein ROA als signiertes Objekt, das ein Autonomous System berechtigt, Routen für bestimmte Präfixe zu originieren. RFC 6811 setzt den Status NotFound, wenn kein validiertes VRP das Präfix einer Route abdeckt. Das beschreibt den Stand der Validierungsdaten. BGP-Routenrückzug und Präfixisolation erfordern getrennte Netzmaßnahmen; die Routerrichtlinie bestimmt, ob ein Validierungszustand Routenauswahl oder Weiterleitung verändert.

Die binäre Prüfung in Artikel 3.6 lässt sich schnell abarbeiten. Sie kann trotzdem zu einem anderen Ergebnis kommen als die Abhilfe, die Artikel 3.4 bereits anerkannt hat.

Die Liste gehört zum Durchsetzungsapparat

Der Vorschlag überträgt dem Security Working Group die Pflege eines Verzeichnisses genehmigter Listen. Eine Liste muss objektive automatisierte Telemetrie verwenden, Wohn- und dynamische Teilnehmerbereiche ausschließen und einen öffentlich prüfbaren historischen Verlauf behalten. Das sind brauchbare Grenzen. Die Arbeitsregeln bleiben offen: Wie wird eine Liste aufgenommen? Wie lässt sich ein falscher Eintrag anfechten? Welche historische Fassung zählt für die 14 Tage? Wie werden Überschneidungen behandelt?

Artikel 3.5 macht die Zwischenmaßnahmen von der Registerarchitektur des Ressourcennutzers abhängig. Sie sollen dessen operative Registeragilität einschränken und in der RIPE Database einen öffentlichen Status „non-compliant abuse status“ setzen, zugleich aber die Ressourcenzuweisungen erhalten und nachgelagerte Netze vor einer sofortigen Trennung schützen. Die Begründung des Vorschlags sagt selbst, dass die Maßnahmen noch in einem separaten RIPE-Dokument klar vereinbart und definiert werden müssen, damit keine mehrdeutigen oder unbrauchbaren Abläufe entstehen. Das ist Teil der Macht, kein Kleingedrucktes.

Der Vorschlag ist weiterhin in der Diskussionsphase. RIPE NCC nennt in seinem Mitglieder-Update für Oktober den 11. November als Frist für Rückmeldungen; der RIPE-93-Plan setzt die Debatte für den 27. Oktober im Security Working Group an. Die nächste Fassung kann den Rückkehrtest vereinheitlichen, bevor die Uhr anläuft.

Quellen