Zusammenfassung

  • Vorschlag 2026-02 befindet sich in der Diskussion und ist keine geltende Richtlinie. Auslöser sind eine authentifizierte Meldung und insgesamt 14 Tage auf einer anerkannten Infrastrukturliste innerhalb eines rollierenden Zeitraums von 30 Tagen.
  • Artikel 3.4 akzeptiert als erste Abhilfe entweder die Entfernung der Präfixe von der Liste oder eine nachgewiesene administrative Isolation. Für die Aufhebung der Beschränkungen nennt Artikel 3.6 die Listenentfernung oder – sofern RPKI betroffen ist – das Löschen des „geeigneten ROA“.
  • Ein ROA dokumentiert, dass ein Ressourceninhaber ein autonomes System zur Ankündigung bestimmter Präfixe autorisiert hat. Für sich genommen belegt dieser Datensatz nicht, dass ein Phishing-, Malware-, DDoS- oder Spambetrieb beendet wurde.

Ein Verfahren, drei unterschiedliche Beweisfragen

Die RIPE-Community hat die Diskussion über einen neuen Vorschlag zu missbräuchlicher Netzwerknutzung auf Infrastrukturebene eröffnet. Version 1.0 wurde am 13. Oktober 2026 veröffentlicht; laut offizieller Seite läuft die Diskussion bis zum 11. November. Zum Redaktionsstichtag gibt es keinen öffentlichen Beleg für eine Annahme, Umsetzung oder einen nach diesem Verfahren bearbeiteten Fall. Der Text beschreibt vorgesehene Pflichten, keine bereits geltende Maßnahme der RIPE NCC.

Der Entwurf grenzt vier Formen anhaltender Aktivität ab: DDoS-Kommando- und Kontrollstrukturen, systematische Malware-Hosting- oder Verteilungsnetze, Hosting-Farmen für Phishing-Seiten sowie systematische automatisierte Spam-Botnetze. Davon unterscheidet er den Einzelfall eines kompromittierten Verbrauchergeräts. Ausgenommen sind außerdem Wohnkunden- und dynamische Teilnehmerpools, soweit sie vom Inhaber oder einem globalen Routing-Register entsprechend ausgewiesen werden.

Diese Begrenzung ist ein wichtiger Teil des Designs. Vor Beschränkungen soll eine nachvollziehbare Dokumentationskette stehen: Ein betroffener Netzbetreiber oder ein nationales CERT sendet ein Support-Ticket an die RIPE NCC. Beigefügt werden überprüfbare automatisierte Telemetriedaten einer anerkannten Infrastrukturliste sowie Zeitstempel oder kryptografische Signaturen. Artikel 3.1 verlangt zusätzlich insgesamt 14 Tage auf einer solchen Liste innerhalb eines rollierenden 30-Tage-Fensters.

Die Security Working Group soll ein Register der Listen führen; Voraussetzung wären objektive automatisierte Telemetrie, der Ausschluss von Wohnkunden- und dynamischen Netzen sowie ein öffentlich überprüfbares Archiv.

Danach folgen drei Beweisstationen, die nicht gegeneinander austauschbar sind:

Stufe Vorgesehener Datensatz oder Schritt Was er belegen kann Was er allein nicht belegt
Einleitung 14 Tage innerhalb von 30 Tagen auf einer anerkannten Liste plus authentifizierte Meldung Dass eine bestimmte Adresse im geforderten Zeitraum auf einer konkreten Liste stand Ob die Adresse korrekt dem Inhaber zugeordnet wurde oder welche Maßnahme die Aktivität beendete
Erste Abhilfe Die betroffenen Präfixe von den Listen entfernen oder ihre administrative Isolation nachweisen Eine Änderung des Listenstatus oder eine mit der Abhilfefrist verbundene Isolationsmaßnahme Wer die Isolation wie geprüft hat oder warum der Listeneintrag verschwand
Wiederherstellung Listenentfernung oder, sofern RPKI betroffen ist, Löschen des „geeigneten ROA“ Eine Änderung der Liste oder des Routenautorisierungsdatensatzes Ob der gemeldete Betrieb beendet wurde und warum gerade dieses ROA die passende Abhilfe ist

Es geht weder darum, Listen für nutzlos zu erklären, noch darum, eine administrative Reaktion auf anhaltende Meldungen grundsätzlich auszuschließen. Die Frage lautet, ob in jeder Phase derselbe Sachverhalt gemessen wird. Artikel 3.1 setzt bei der Listenhistorie an. Artikel 3.4 akzeptiert eine Listenänderung oder bestätigte Isolation. Artikel 3.6 kehrt zur Liste zurück und ergänzt einen Datensatz zur Routenautorisierung. Der Entwurf erläutert nicht, ob diese letzte Möglichkeit Isolation belegt, eine Behauptung über den Routenursprung behebt oder einen eigenständigen Verwaltungsweg darstellt.

Das ROA beantwortet eine engere Frage

RFC 9582 beschreibt die Funktion einer Route Origin Authorization: Eine prüfende Stelle kann feststellen, ob der Inhaber eines Adressblocks ein autonomes System dazu ermächtigt hat, Routen für bestimmte Präfixe anzukündigen. Diese Beziehung ist für die Routingsicherheit wichtig. Sie sagt aber nichts darüber aus, welcher Dienst an der Adresse lief, welcher Datenverkehr entstand, ob ein Host kompromittiert wurde oder ob der Betreiber ihn nach einer Meldung isolierte.

RPKI kann unmittelbar relevant sein, wenn eine Meldung einen nicht autorisierten Routenursprung betrifft oder die Routenautorisierung Teil des behaupteten Mechanismus ist. Dann könnte eine Zuordnung von Präfix, autonomem System, ROA und Meldung erklären, warum das Löschen oder Ersetzen einer Autorisierung eine sinnvolle Maßnahme wäre. Die vier Bedrohungsklassen des Vorschlags sind jedoch nicht sämtlich Probleme des Routenursprungs. Eine Phishing-Hosting-Farm kann über eine ordnungsgemäß autorisierte Route erreichbar sein. Allein das ROA zeigt nicht, dass die Autorisierung das beschriebene Verhalten ermöglicht hat.

Zwei Verbindungen bleiben offen. Wann genau ist RPKI „betroffen“? Und welches ROA ist „geeignet“, wenn ein Inhaber mehrere Präfixe, Ursprungs-AS oder Autorisierungen verwaltet? Das sind keine bloßen Begriffsfragen. Davon hängt ab, welche Änderung der Betreiber vornehmen soll und worauf die RIPE NCC eine Entfernung des öffentlichen Nichtkonformitätsstatus stützen würde.

Das Löschen eines ROA ändert einen Autorisierungsdatensatz. Je nach übrigen Autorisierungsdaten und lokalen Routingrichtlinien kann sich dadurch ändern, wie manche Netze eine Routenankündigung bewerten. Die Quellen belegen keine einheitliche Wirkung. Vor allem beweist keine dieser möglichen Folgen, dass der auf einer Liste genannte Dienst beendet wurde. Das System kann weiterlaufen, eine Route kann auf anderem Weg angekündigt werden, oder der Inhaber kann das ROA aus einem anderen Grund löschen. Ein RPKI-Objekt ersetzt keine fallbezogene Erklärung.

Die abuse-c-Regelung ist ein anderer Mechanismus

RIPE-705 regelt die Kontaktaufnahme: Für einschlägige Ressourceneinträge sieht sie das abuse-c-Attribut, ein erreichbares Postfach für Meldungen sowie eine jährliche Validierung und Nachverfolgung nach den geltenden Richtlinien und Verfahren vor. Die RIPE NCC beschreibt den Eintrag als Weg, Meldungen an den passenden Ressourceninhaber zu leiten.

Eine Meldung zuzustellen heißt nicht, ihre Tatsachen zu bestätigen. Es sagt auch nicht, ob ein Betreiber ein Präfix isoliert hat oder welche Registerbeschränkung folgen sollte. Vorschlag 2026-02 würde eine eigene Verwaltungskette schaffen: elektronische Nachricht an rechtliche, administrative und Rechnungsstellungskontakte; sieben Arbeitstage zur Abhilfe ab bestätigter Zustellung; danach gegebenenfalls Zwischenbeschränkungen und ein öffentlich sichtbarer Status „nicht konform bei Missbrauch“ in der RIPE-Datenbank.

Der Entwurf will Zuweisungen erhalten und eine sofortige Trennung vom Netz vermeiden. Zugleich räumt seine Begründung ein, dass konkrete Beschränkungen eine Einigung der Community und ein weiteres RIPE-Dokument erfordern. Ein öffentlicher Status kann dennoch von Dritten in Werkzeuge oder Geschäftsentscheidungen übernommen werden, auch wenn die Zuweisung bestehen bleibt. Deshalb muss nachvollziehbar sein, welcher Beleg den Status trägt, wie er korrigiert wird und wann seine Entfernung dokumentiert ist.

Der Antragsteller bezeichnet anhaltende Nichtabhilfe als Vertragsverletzung. Das ist Teil seiner Begründung, keine bereits feststehende rechtliche Schlussfolgerung. Das RIPE-Verfahren ist weiterhin öffentlich und konsensorientiert. Die praktische Frage ist enger: Welche Nachweise sollten jeden Statuswechsel begleiten?

Ein Belegvermerk pro Meldung

Das Verfahren könnte seine Phasen beibehalten und zugleich einen nachvollziehbaren Belegvermerk pro Fall verlangen, ohne sensible Telemetrie zu veröffentlichen. Er sollte die Meldungs-ID mit dem genauen Präfix, der Listenfassung und ihrer Historie, den Beobachtungszeitpunkten, der Zuordnung zum Inhaber, einer Isolationsmaßnahme und deren Prüfer verbinden. Gehört Routing zum Vorwurf, sollte auch das betreffende ROA dokumentiert werden. Zustellung, Frist, Beschränkungen, Abhilfe und Wiederherstellung brauchen ebenfalls Zeitstempel.

So bleiben vier Fragen getrennt: Welches Verhalten wurde beobachtet? Welche Routenautorisierung bestand? Welche Eindämmung erfolgte? Welchen Verwaltungsstatus veröffentlichte die RIPE NCC? Bei einem Vorwurf zum Routenursprung kann eine ROA-Änderung Teil der Antwort sein; dann braucht es Belege dafür, wie sich das Problem dadurch verändert hat. Betrifft die Meldung einen Hosting-Dienst, sollte eine nachweislich unverbundene Autorisierungsänderung nicht als Isolationsnachweis gelten.

Eine Adresse kann aus einer Liste verschwinden, weil die Aktivität endete, die Liste einen Fehler korrigierte, ihre Kriterien änderte oder der Beobachtungszeitraum auslief. Für den Inhaber bedeuten diese Gründe Unterschiedliches. Ein öffentliches Archiv hilft, den Ablauf zu rekonstruieren, erklärt aber nicht zwingend, warum ein Eintrag entfernt wurde.

RIPE-781 sieht vier offene Phasen der Richtlinienentwicklung, Konsensentscheidungen und administrative Unterstützung durch die RIPE NCC vor, darunter Folgenabschätzung und Analyse des Implementierungsaufwands. Die Diskussion kann daher nicht nur die 14-Tage-Schwelle prüfen, sondern auch die Belege, die eine Adresse dem Inhaber, ein Verhalten einem Autorisierungsobjekt und eine Abhilfe der Entfernung eines öffentlichen Status zuordnen.

Die Diskussion hat gerade erst begonnen. Die deutlichste Grenze des Vorschlags ist der Fokus auf anhaltende Infrastrukturaktivität bei gleichzeitigem Ausschluss von Wohnkunden- und dynamischen Pools. Die Beweislücke ist konkreter: Das Verfahren startet mit einem Listeneintrag, akzeptiert bei der ersten Abhilfe eine Isolation und führt bei der Wiederherstellung einen anderen Datensatz ein. Solange diese Verbindung fehlt, belegt das Löschen eines ROA nur eine geänderte Routenautorisierung. Einen Missbrauchsfall schließt es nicht.

Quellen