Zusammenfassung

  • maxLength legt fest, bis zu welcher Präfixlänge ein AS als Ursprung autorisiert ist; das Feld benennt nicht die tatsächlich beabsichtigten spezifischeren Routen.
  • Eine enge Autorisierung kann eine legitime, aber unvorbereitete Notfalldeaggregation Invalid machen; eine breite Autorisierung kann ein intern nie genehmigtes Präfix Valid erscheinen lassen.
  • Ein Ursprungsregister muss jedes Präfix mit ASN, Zweck, Aktivierungsfenster, ROA-Änderung, Beobachtung, Rücknahmeverantwortung und Rollback-Frist verbinden.

Im Normalbetrieb kündigt AS 64496 das Aggregat 203.0.0.0/16 an; seine ROA autorisiert genau dieses /16. Während eines Angriffs soll 203.0.113.0/24 einen Dienst zu einem Mitigation-Anbieter lenken. Die BGP-Änderung ist intern genehmigt, die RPKI-Autorisierung wurde jedoch nicht vorbereitet. Netze mit Ursprungsvalidierung können das /24 als Invalid einstufen, weil es spezifischer ist als erlaubt.

Die schnelle Lösung lautet, das /16 mit maxLength 24 zu versehen. Das Notfall-/24 wird gültig. Gleichzeitig darf das genannte AS nun jedes /24 innerhalb des /16 als Ursprung verwenden: 256 mögliche Blöcke dieser Länge. Die ROA unterscheidet das benötigte Präfix nicht von den übrigen 255 und weiß nichts über Dienste, Überwachung oder Rücknahmeverantwortung.

RFC 9582 definiert einen engeren Sachverhalt. Eine ROA hält fest, dass der Adressinhaber einem AS gestattet, die aufgeführten Präfixe zu originieren. Das optionale maxLength gibt die längste erlaubte Präfixlänge an; fehlt es, ist nur die aufgeführte Länge autorisiert. Ein Traffic-Engineering-Auftrag, ein Change-Fenster, ein Incident-Ticket oder eine Ablaufzeit sind nicht Teil des Objekts.

Auch RFC 6811 begrenzt die Aussage des Ergebnisses. Eine empfangene Route wird mit sie abdeckenden validierten ROA-Payloads, dem Ursprungs-AS und der erlaubten Länge verglichen. Valid bestätigt weder den vollständigen AS_PATH noch Paketlieferung, Nutzen der Deaggregation oder eine fortbestehende menschliche Genehmigung.

Minimale Autorisierung macht Absicht prüfbar

RFC 9319 empfiehlt nach Möglichkeit minimale ROAs: Autorisiert werden Präfixe, die tatsächlich in BGP originieren, nicht eine theoretische Menge. Im Allgemeinen soll maxLength vermieden werden, wobei bestimmte operative Ausnahmen beschrieben sind. Das Feld ist nicht ungültig; problematisch ist eine Kurzform, die über den realen Ursprungsplan hinausreicht.

Kündigt ein Betreiber ein /16 und vier bestimmte /24 für regionale Eingänge an, bilden vier exakte Autorisierungen den Plan sichtbar ab. Eine /16–24-Autorisierung umfasst diese vier, aber auch 252 weitere /24 derselben Länge. Da RPKI den Ursprung und nicht den gesamten Pfad prüft, kann ein Angreifer einen falschen Pfad mit dem autorisierten AS am Ende konstruieren und ein ungenutztes, aber breit autorisiertes Subpräfix anvisieren.

Exakte Objekte verlangen Abstimmung zwischen Ressourcenverwaltung, Routing, Sicherheit und Dienstleister. Jeder neue Ursprung muss mit seiner Autorisierung koordiniert werden. Dieser Aufwand schafft die entscheidende Evidenz: Wer wollte welches Präfix zu welchem Zweck und bis wann?

Notfallflexibilität braucht eine getestete Reihenfolge

DDoS-Mitigation erfordert gut gestaltete Ausnahmen. Ein Anbieter kann ein spezifischeres Präfix, ein anderes Ursprungs-ASN oder eine zielbasierte Verwerfungsroute verlangen. RFC 9319 behandelt solche Fälle. Der Kunde sollte die genauen Anforderungen vor dem Ereignis kennen und die Reihenfolge von RPKI-Änderung und BGP-Ankündigung testen.

Zuerst werden Präfix, ASN, Umfang und Dauer genehmigt. Dann wird die ROA erstellt oder ersetzt; anschließend wartet das Team, bis unabhängige Validatoren den erwarteten Payload anzeigen. Danach wird die Route in kontrolliertem Umfang angekündigt, ihr Status und ihre Ausbreitung werden beobachtet, erst dann wird erweitert. Nach dem Ereignis wird zuerst die BGP-Route zurückgenommen und ihr Verschwinden bestätigt; danach endet die temporäre Autorisierung gemäß Rollback-Plan.

RPKI-Repository, Validatorabruf, Ergebnisübergabe an Router und BGP-Ausbreitung konvergieren nicht gleichzeitig. Öffentliche RFCs belegen zudem nicht, wie jedes Netz Invalid behandelt. RFC 7115 versteht Ursprungsvalidierung deshalb als Einführung einer Betriebspolitik: Auswirkungen beobachten, lokale Ausnahmen verstehen und Konsequenzen stufenweise aktivieren.

Quellen