RPKI: Warum ist meine spezifischere Route trotz richtiger ASN Invalid?

Die Origin-ASN stimmt, trotzdem wird eine neue, spezifischere BGP-Route als RPKI-Invalid bewertet? Prüfen Sie neben der ASN auch Präfix und zulässige Präfixlänge. Eine Autorisierung für ein Aggregat erlaubt nicht automatisch alle enthaltenen Teilnetze. Wer für Traffic Engineering oder einen geplanten Ersatzweg zusätzliche Präfixe ankündigen möchte, sollte die passenden ROAs vor der Routingänderung vorbereiten und deren Wirkung kontrollieren.

Was maxLength tatsächlich erlaubt

Eine Route Origin Authorization (ROA) benennt eine Origin-ASN und autorisierte Präfixe. Für jedes Präfix kann maxLength festlegen, bis zu welcher Präfixlänge Teilnetze erlaubt sind. Ohne dieses optionale Feld gilt nur das exakte Präfix. RFC 9582 beschreibt diese Bedeutung für IPv4 und IPv6. Eine größere Zahl hinter dem Schrägstrich bezeichnet dabei ein kleineres, spezifischeres Netz, nicht eine größere Adressmenge.

Eine Oberfläche kann die exakte Autorisierung als identische Präfix- und Maximallänge darstellen. Entscheidend ist die veröffentlichte Berechtigung, nicht die Beschriftung eines Eingabefelds. maxLength ist auch keine Vorgabe, welche Präfixlängen ein Upstream annimmt: Seine Importfilter und Ihr vereinbarter Routingumfang gelten zusätzlich.

Valid, Invalid und NotFound sauber unterscheiden

• Valid: Mindestens ein validierter Autorisierungsdatensatz passt zu Präfix, Länge und Origin-ASN.
• Invalid: Mindestens ein Datensatz deckt das Präfix ab, aber keiner erlaubt die Kombination aus Präfixlänge und Origin-ASN.
• NotFound: Kein Datensatz deckt das angekündigte Präfix ab. Das ist keine positive Autorisierung.

RFC 6811 definiert diese Prüfung anhand validierter Daten, sogenannter VRPs. Invalid beschreibt hier die Route gegenüber diesem Datenbestand, nicht zwingend eine defekte Signatur der ROA. Welcher Verkehr tatsächlich ankommt, hängt außerdem von Routing-Policy und Erreichbarkeit ab. Ein grüner Valid-Status beweist weder einen authentischen vollständigen AS-Pfad noch einen funktionierenden Dienst.

Beispiel: Ein /40 erlaubt noch kein /48

Das folgende Szenario ist ausschließlich illustrativ. Die IPv6-Adressen aus 2001:db8::/32 und AS64496/AS64497 dienen der Dokumentation; es sind keine AS51202-Routen und keine Präfixe für einen Live-Test. Angenommen, der betrachtete validierte Datenbestand enthält nur eine Autorisierung für 2001:db8:1200::/40 mit Origin AS64496, ohne erweiterte Maximallänge.

• 2001:db8:1200::/40, Origin AS64496: Valid, weil das exakte Präfix und die ASN passen.
• 2001:db8:1201::/48, Origin AS64496: Invalid, weil /48 spezifischer als die erlaubte Länge /40 ist.
• 2001:db8:1200::/40, Origin AS64497: Invalid, weil die Origin-ASN nicht autorisiert ist.
• 2001:db8:3400::/40, Origin AS64496: NotFound, weil dieses Präfix außerhalb der einzigen Autorisierung liegt.

Soll künftig genau 2001:db8:1201::/48 aus AS64496 angekündigt werden, kann dafür eine zusätzliche exakte Autorisierung vorgesehen werden. Die bestehende /40-Autorisierung bleibt bestehen. Sobald der prüfende Datenbestand beide enthält, ist auch diese /48-Ankündigung Valid. Es ist nicht erforderlich, das ganze /40 pauschal bis /48 freizugeben.

Warum nicht vorsorglich eine große Maximallänge setzen?

RFC 9319 empfiehlt möglichst präzise Autorisierungen statt unnötig vieler erlaubter Teilpräfixe. Eine großzügige maxLength-Einstellung erweitert die Angriffsfläche für Ankündigungen mit gefälschtem Origin: ROV prüft nicht den vollständigen AS-Pfad. Selten benötigte Ersatz- oder Mitigationsrouten sollten deshalb konkret geplant werden. Nur tatsächlich vorgesehene Präfix-/Origin-Kombinationen vorab freigeben und ungenutzte Freigaben regelmäßig überprüfen; eine Vorbereitung auf Notfälle rechtfertigt keine grenzenlose Autorisierung.

Überlappende ROAs sind keine geordnete Firewall-Regelliste. Eine zusätzliche enge Autorisierung hebt eine vorhandene breite nicht auf. Solange irgendein passender validierter Datensatz die Route erlaubt, kann sie Valid sein. Wer Berechtigungen einschränken möchte, muss deshalb den gesamten überdeckenden Bestand prüfen und überflüssige breite Freigaben gezielt ersetzen.

Ein neuer ROA kann auch bestehende Teilnetze betreffen

Vor einer Autorisierung für einen größeren Block müssen auch bereits angekündigte Kundenteilnetze berücksichtigt werden. RFC 7115 weist darauf hin, dass diese passende ROAs benötigen: Eine bisher nicht abgedeckte Ankündigung kann durch einen neuen überdeckenden ROA von NotFound zu Invalid wechseln. Eine Prüfung nur des eigenen Aggregats übersieht diesen Effekt. Erfassen Sie daher auch Teilnetze mit abweichender Origin-ASN.

Änderungen mit einem überprüfbaren Ablauf durchführen

1. 1Vorher-Zustand sichern: tatsächlich angekündigte Präfixe, Origin-ASNs, alle überdeckenden Autorisierungen und den beobachteten Validierungsstatus mit Zeitstempel festhalten.
2. 2Soll-Zustand definieren: Normalbetrieb, Umschaltung und Rückfall getrennt auflisten. Benötigte exakte Autorisierungen ergänzen, statt pauschal maxLength zu erhöhen.
3. 3Veröffentlichung und Verteilung prüfen: Ein gespeicherter Eintrag im Portal beweist noch nicht, dass Validator und Router ihn verwenden. Den gewünschten Datenstand am eigenen Validator und mit dem Upstream kontrollieren.
4. 4Erst dann die geplante BGP-Änderung durchführen. Bei einem Origin-Wechsel die benötigte alte Autorisierung für den vereinbarten Rückfall zunächst erhalten.
5. 5Nach der Umschaltung Validierungsstatus, sichtbare Routen und echte Dienst-Erreichbarkeit vergleichen. Bei Abweichungen den vorbereiteten Rückfall nutzen, nicht die ROV-Prüfung großflächig abschalten.
6. 6Nach bestätigtem Abschluss nicht mehr benötigte Autorisierungen entfernen und den verbleibenden Bestand erneut kontrollieren. Zuständigkeit und Änderung im Betriebsprotokoll festhalten.

Dieser Ablauf ist eine praktische Planungshilfe, keine Garantie für eine störungsfreie Umschaltung. RPKI-Daten werden verteilt und zwischengespeichert; verschiedene Validatoren können zeitweise unterschiedliche Stände sehen. RFC 9319 warnt insbesondere bei zeitkritischen Routingänderungen davor, erst im Ereignisfall eine notwendige Autorisierung anzulegen. Eine universelle Wartezeit lässt sich daraus nicht ableiten. Maßgeblich ist der beobachtete Datenstand.

Was Sie bei einer Transit-Anfrage mitgeben sollten

Senden Sie die geplanten IPv4-/IPv6-Präfixe, Origin-ASN, gewünschte spezifischere Ankündigungen und das Umschaltszenario. Bei einem konkreten Invalid-Befund helfen zusätzlich Zeitpunkt, beobachtender Router oder Validator und die überdeckenden ROA-Daten. So lassen sich Autorisierung, Importfilter und tatsächliche Ankündigung getrennt prüfen. Zugangsdaten zum RPKI-Portal gehören nicht in die Anfrage.