Zusammenfassung

  • draft-geng-sidrops-bgp-drip-00 schlägt vier Mechanismen vor: assoziierte Pfade abwerten, Risiko vom Router an einen RP melden, risikomarkierte ROAs verteilen und Risiko zwischen BGP-Routern signalisieren.
  • Eine ROA kann kryptografisch gültig bleiben, während ein getrenntes operatives Urteil die Präferenz zugehöriger Routen senkt.
  • Der Text ist ein individueller Version-00-Entwurf ohne IETF-Endorsement oder formalen Status. Erkennung, Assoziation, Transport, Empfangs-Policy, Wirkung, Ablauf und Rollback müssen getrennt belegt werden.

Route Origin Validation beantwortet eine begrenzte Frage: Ist ein AS berechtigt, ein Präfix zu originieren? Sie bescheinigt weder den gesamten AS-Pfad noch die Integrität des Routers oder die Absicht eines Nachbarn. DRIP setzt an dieser Lücke zwischen Autorisierung und aktueller operativer Einschätzung an.

Der Entwurf verbindet vier Schritte. Ein Router kann eine verdächtige Route mit weiteren Routen desselben Origin AS, desselben unmittelbaren Nachbarn oder eines ähnlichen AS_PATH-Musters verknüpfen und deren Local_Pref reduzieren. Er kann Präfix, verdächtige Origin- oder Peer-AS, ROA-Kennung und Grundcode über RTR an eine RPKI Relying Party melden. Der RP kann den Risikozustand speichern und mit einer risikomarkierten ROA zurückgeben. Eine vorgeschlagene BGP Extended Community kann das Signal schließlich zu anderen Routern tragen.

Damit wandert nicht nur Telemetrie. Aus einer lokalen Beobachtung wird eine Empfehlung, die in einem anderen administrativen Bereich die Pfadauswahl verändern kann. Wenn die Import-Policy dieser Empfehlung automatisch folgt, hat das Signal faktisch Entscheidungswirkung.

Kryptografische Autorisierung und operatives Misstrauen

Der Entwurf trennt zu Recht zwei Ebenen. Eine gültige ROA besagt, dass die Ursprungsauthorisierung kryptografisch geprüft wurde. Ein Risikotag besagt, dass operative Informationen gegen eine unveränderte Bevorzugung sprechen.

Wer beide Ebenen zu einem einzigen Status zusammenfasst, verliert die Ursache. „Erhöhtes Risiko“ kann einen ROV-Fehler, einen unerwarteten AS_PATH-Hop, den Verdacht gegen einen Peer oder die Ausgabe einer Assoziationsregel meinen. Eine widerrufbare Bewertung sieht dann wie ein dauerhafter Fehler im RPKI-Objekt aus.

Der Datensatz muss deshalb das ROV-Ergebnis unverändert lassen und Beobachtung, Zeitpunkt, Prüfverfahren, Grund, Urheber und Konfidenz des Risikourteils separat führen. Auch die lokale Regel, die daraus eine Local_Pref-Änderung macht, braucht einen eigenen Beleg. Nur so lässt sich das Urteil zurücknehmen, ohne die Autorisierungsgeschichte umzudeuten.

Die Assoziationsregel bestimmt den Kollateralschaden

Gleicher Ursprung, gleicher Peer oder ein ähnlicher Pfad sind brauchbare Ermittlungsmerkmale. Sie beweisen keine gemeinsame Kontrolle. Ein AS kann unabhängige Kundenpräfixe originieren, ein Peer kann viele fremde Netze transportieren, und ein ähnlicher AS_PATH kann normale Topologie widerspiegeln.

Der Detektor kann bei der auslösenden Route richtig liegen und bei der abgeleiteten Gruppe falsch. Sobald die Gruppe automatisch abgewertet wird, wird ein Analysefehler zur Produktionswirkung. Betroffen sein können legitime Routen, die selbst nie invalid waren.

DRIP verlangt einen Mindestwert für Local_Pref und unterscheidet Depreference von hartem Filtern. Das reduziert das Risiko vollständigen Blackholings, garantiert aber keine brauchbare Alternative. Verkehr kann auf einen überlasteten, teuren oder schlechter überwachten Pfad wechseln. Der Ausführungsbeleg muss sichtbare Alternativen, die genaue Präferenzänderung, betroffene Präfixe und Dienste sowie gemessene Erreichbarkeit vor und nach dem Eingriff enthalten.

Ein geschützter Kanal kann ein falsches Urteil korrekt zustellen

Der Sicherheitsabschnitt nennt die Einspeisung falscher Risiken als DoS-Vektor. RTR-Verbindungen sollen geschützt werden; an eBGP-Grenzen soll das Signal ohne bilaterale Vertrauensvereinbarung entfernt werden; ein Präferenzboden soll den vollständigen Verlust legitimen Verkehrs verhindern.

Diese Maßnahmen schützen Herkunft und Transport des Signals. Sie validieren nicht seine Semantik. TLS oder SSH kann die Nachricht eines fehlkalibrierten Detektors unverändert zustellen. Die Authentität des Senders beweist weder Aktualität noch Qualität der Assoziation. Auch bilaterales Vertrauen benötigt Kriterien für Audit, Ablauf und Widerruf.

Ein belastbarer Lebenszyklus braucht Gültigkeitsdauer, Erneuerung, Rücknahme, Replay-Schutz, Einspruch, lokalen Override und vollständigen Rollback. Der RP muss vom abgeleiteten Score bis zum Originalbeleg zurückverweisen können.

Entwurfswerte sind keine IANA-Zuteilungen

Der Datatracker führt nur Version 00 als aktiven individuellen Internet-Draft. Es gibt keinen RFC Stream, keinen Intended RFC Status, kein IETF-Endorsement und keine formale Stellung im Standardisierungsprozess.

Der Text schlägt die RTR-PDU-Typen 0x0B und 0x0C vor und zeigt Version 2 im Risikopaket. Im aktuellen IANA-Register ist Typ 11 (0x0B) für Version 2 bereits ASPA zugeteilt; Typ 12 ist nicht zugeteilt. Der Sub-Type der transitive opaque BGP Extended Community bleibt „To Be Determined“, und es gibt keinen Eintrag mit dem vorgeschlagenen Namen.

Das ist kein Nachweis einer Ablehnung. Es zeigt, dass Kodierung, Kompatibilität und Verfahren offen sind. Die Zahlen dürfen nicht als standardisiert, interoperabel oder implementiert dargestellt werden.

Die empfangende Organisation behält die Verantwortung

Die Lu-Heng-Doktrin trennt Aufzeichnung und Herrschaft: Ein Eintrag beschreibt Wirklichkeit, er erzeugt sie nicht. Eine Warnung kann Evidenz liefern, ohne zum Mandat zu werden. Bei DRIP beobachtet der Detektor, der RP speichert, BGP transportiert. Die empfangende Organisation trägt jedoch Kunden-, Kosten- und Verfügbarkeitsfolgen.

Jede Wirkung muss daher auf Identität und Mandat des Detektors, Rohbeobachtung, Validierung, Assoziationsregel und Konfidenz, Signalschutz, Reichweite, Import-Policy, Präferenzdelta, Alternativen, Ablauf, Rücknahme, Einspruch, Rollback und gemessene Erreichbarkeit zurückführbar sein.

Der Entwurf erkennt richtig, dass Origin-Autorisierung nicht jedes operative Risiko erklärt. Eine sichere Architektur teilt Kontext, nicht Souveränität. Das empfangende Netz muss begründen können, warum es handelte, wie lange die Wirkung gilt und wie sie vollständig aufgehoben wird.

Quellen