Zusammenfassung

  • Ein individueller Internet-Draft vom 20. September will ROAs um eine Region erweitern und sie mit einem am Routereingang ermittelten Kontext vergleichen.
  • Ein Unterschied kann ein wertvolles Warnsignal sein. Er beweist weder den physischen Ort noch einen unbefugten Ursprung oder die Sicherheit eines Route-Drops.

Die heutige ROA beantwortet absichtlich wenig: Welcher AS darf welches Präfix bis zu welcher Länge originieren? draft-geng-sidrops-regionalized-roa-00 ergänzt eine zweite Prüfung. Ein Angreifer könne den legitimen Origin-AS vortäuschen oder eine unbefugte Edge nutzen und dennoch Valid erhalten. R-ROV soll dann RegionMismatch liefern.

Datatracker weist das Dokument als individuellen Entwurf ohne formale IETF-Billigung aus. Es ist eine prüfbare Idee, keine eingeführte Norm.

Drei Codes, drei Autoritäten

RegionIdentifier darf RIR-Code, ISO-Ländercode oder UN-M49-Region sein. Der RIR-Code beschreibt Verwaltungs- und Zertifizierungsherkunft. RFC 7020 kennt LIRs, die mehrere Regionen und RIR-Beziehungen überspannen. ISO beschreibt Hoheitsgebiet, M49 statistische Gruppierung. Keiner der Codes legt automatisch fest, an welchem Peering eine Route zulässig ist.

Ein Inhaber kann einen Betriebsbereich erklären. Die Signatur belegt den Erklärenden, nicht die physische Wahrheit. Anycast, Remote Peering, weltweiter Transit und Disaster Recovery erzeugen legitime Pfade außerhalb der administrativen Karte.

Auch Region_Ctx ist eine Behauptung

Der Router soll Kontext aus Peer-Konfiguration, BGP Communities oder Topologie ableiten. Eine Schnittstellenbezeichnung kann veralten. Large Communities sind nach RFC 8092 opake Betriebsinformation. Ein physischer Austauschpunkt muss nicht dem entfernten Markt entsprechen.

Der Entwurf räumt Fehlalarme und übersehene Fälle bei falschem Kontext ein. Deshalb müssen signierte Region, Vokabular, Mapping-Regel, Eingang, UPDATE, AS-PATH, lokale Aktion, Ersatzpfad und Erreichbarkeit getrennt protokolliert werden. RegionMismatch ist ein Widerspruch zwischen Datensätzen, kein fertiges Angriffsurteil.

Eine signierte Geofeed vermisst keinen Standort

Die Out-of-Band-Option synthetisiert Daten aus Delegationsstatistik und Geolokation. RFC 9632 kann eine Geofeed optional per RPKI authentisieren und empfiehlt trotzdem Gegenprüfung. Signiert wird die Aussage eines für den Adressbereich autorisierten Schlüssels, nicht der Boden.

Die synthetische Tabelle bleibt lokale Policy. Sie braucht Herkunft, Ablauf und schnellen Rückbau. Ein falscher Ort darf nicht unbemerkt dieselbe Autorität wie die Origin-Freigabe erhalten.

Abwärtskompatibilität braucht einen Ablauf

Der Draft nennt neuen RTR-PDU oder erweiterten Prefix-PDU. RFC 8210 handelt Versionen aus und behandelt unbekannte PDU-Typen als fatal. Version 00 enthält noch keinen vollständigen Mechanismus für Aushandlung, Downgrade und gemischte Caches. Kompatibilität ist daher Ziel, noch kein Testergebnis.

Die letzte Entscheidung bleibt lokal

Hard Drop, LOCAL_PREF-Abzug oder Alarm sollen lokaler Policy folgen. Diese Grenze ist richtig. Pilotierung sollte mit nachvollziehbaren Alarmen beginnen und Anycast, Remote Peering, Failover, Fehlkonfiguration und echten Missbrauch getrennt messen. Drop braucht eine zusätzliche, reversible Entscheidung.

Der Entwurf zeigt eine echte Grenze von Origin-Validierung. Er sollte nun beweisen, wie Regionen definiert, verglichen, erneuert und zurückgenommen werden — und ob laufende Netze mit dem Signal tatsächlich sicherer werden. Kryptografie signiert eine Aussage; Running Code liefert das Ergebnis.

Quellen