Zusammenfassung

  • Der am 20. August veröffentlichte DOA-Vorschlag bindet Präfixe, Längen, Ursprungs-AS, optionale Peer-AS und BGP Communities an eine Signatur des Ressourceninhabers.
  • DOA und ROV blieben getrennte Bewertungen und lösten keine Standardaktion aus; der Text ist kein IETF-Beschluss, zudem fehlen Sicherheits-, Betriebs- und RPKI-RTR-Spezifikationen.

Beim Remote Triggered Blackholing soll eine absichtlich spezifische BGP-Route schädlichen Verkehr möglichst weit vor dem angegriffenen Anschluss verwerfen. Ausgerechnet diese Spezifität kann mit Route Origin Validation kollidieren. Ist die Route länger als der in der ROA erlaubte maxLength, wird sie als Invalid eingestuft, obwohl der Adressinhaber die Verwerfung veranlasst hat.

draft-spaghetti-grow-rpki-doa-00 stellt dafür seit dem 20. August ein eigenes Autorisierungsobjekt zur Diskussion. Eine Discard Origin Authorization würde unter den betroffenen RPKI-Ressourcen signiert. Sie nennt das berechtigte Ursprungs-AS, Adressbereiche und Präfixlängen, Classic oder Large BGP Communities sowie optional Peer-AS, die die Anfrage weitergeben dürfen.

Der institutionelle Status ist enger als die technische Idee. Der Datatracker kennzeichnet das Dokument als Individual Internet-Draft, ohne IETF-Unterstützung und ohne formelle Stellung im Standardisierungsprozess. Der neue Name richtet einen Vorschlag von 2022, der SIDROPS nannte, nun an GROW. Eine Übernahme als Working-Group-Dokument ist daraus nicht abzuleiten.

Die Überarbeitung beseitigt immerhin eine frühere Unklarheit. 2022 blieb offen, ob mehrere Communities mit UND oder ODER ausgewertet werden. Der aktuelle Text entscheidet sich für ein logisches ODER: Eine einzige gelistete Community auf der empfangenen Route genügt für diese Bedingung. Wenn der Aussteller keinen anderen Wert angibt, darf das Signierwerkzeug die well-known BLACKHOLE Community aus RFC 7999 einsetzen.

Für Matched reicht die Community nicht. Ursprung, zulässige Präfixlänge, empfangendes Peer-Verhältnis und mindestens eine Community müssen zusammenpassen. Die Route muss direkt vom Ursprungs-AS oder von einem im optionalen peerAsIDs-Feld genannten AS eintreffen. Ein deckendes Objekt mit abweichenden Bedingungen ergibt Unmatched; fehlt ein validiertes deckendes Objekt, lautet der Zustand NotFound.

ROV wird daneben weitergeführt. Eine beabsichtigte Blackhole-Route kann nach DOA Matched und nach ROV zugleich Invalid sein. Der Entwurf sieht eine frühe Prüfung der besonderen Erlaubnis vor und lässt nicht passende Fälle in die normale Policy einschließlich ROV zurückfallen. Er verlangt zudem, dass Implementierungen allein aufgrund eines DOA- oder ROV-Zustands keine Policy-Aktion voreinstellen. Der Betreiber muss Verwerfen, Installieren, Ablehnen oder Exportieren ausdrücklich konfigurieren.

Damit bleibt die Bedeutung der Signatur begrenzt. Sie belegt eine Ressourcenberechtigung für eine definierte Kombination. Sie beweist weder einen laufenden Angriff noch die aktuelle Absicht des Ankündigers, einen vollständigen AS-Pfad oder die Zweckmäßigkeit des Verwerfens. Zusätzliche lokale Kontrollen behalten ihren Platz.

Auch der Export wird nicht pauschal geöffnet. RFC 7999 empfiehlt grundsätzlich, eine Blackhole-Route nicht über das empfangende AS hinaus zu verbreiten. Nur wenn das lokale AS ausdrücklich als Peer autorisiert ist, könnte es die Anfrage einen weiteren Hop übertragen. Die übrigen Bedingungen gelten weiterhin; eine transitive Vollmacht entsteht nicht.

Der alternative Weg wäre, die ROA selbst zu erweitern. Ein größerer maxLength nimmt die spezifische Notfallroute in ROV auf, erweitert aber zugleich die gewöhnliche Ursprungserlaubnis. RFC 9319 warnt vor unnötig breiten maximalen Längen. DOA soll den erweiterten Bereich auf den Verwerfungszweck beschränken.

Für einen Einsatz fehlt jedoch noch die Kette. Die Verteilung über RPKI-RTR wird in ein weiteres Dokument ausgelagert. Die Betriebs- und Sicherheitsabschnitte sind noch nicht geschrieben, die IANA-Werte nicht zugewiesen. Genannt wird ein Python-Signierer; die Implementierungsangaben seien von Mitwirkenden geliefert, nicht unabhängig geprüft und kein Beleg für Unterstützung oder Interoperabilität.

Die Veröffentlichung macht somit ein Berechtigungsmodell greifbar. Ob daraus ein belastbarer Kontrollpfad wird, hängt von Widerruf, Aktualität, einheitlicher Validierung und nachvollziehbarer Betreiber-Policy ab. Keiner dieser Punkte lässt sich aus der Existenz des Entwurfs als erledigt ableiten.

Quellen