Zusammenfassung

  • Der IESG genehmigte am 22. Juni 2026 eine Best Current Practice: RPKI-abgeleitete Validierungszustände dürfen nicht in BGP-Pfadattributen über EBGP zwischen Verwaltungsdomänen signalisiert werden. Revision 12 befindet sich in der RFC-Editor-Warteschlange.
  • Ein Validierungszustand ist das Ergebnis einer lokalen RPKI-Sicht. Ein unsigniertes Attribut macht daraus keinen portablen Nachweis, koppelt aber ROA-, Cache- und RTR-Änderungen an die erneute Ankündigung großer Teile der Routingtabelle.

Das Urteil entsteht in einer lokalen Akte

RFC 6811 beschreibt, wie ein BGP-Sprecher Präfix und Origin-AS einer Route mit lokal gespeicherten Validated ROA Payloads vergleicht. Daraus entstehen NotFound, Valid oder Invalid. Der RFC bezeichnet diesen Zustand ausdrücklich als lokale Eigenschaft der Route.

Zum Ergebnis gehören mehr Umstände als der Zustandsname zeigt: die abgerufenen signierten Objekte, ihr Validierungserfolg, der Zeitpunkt der Cache-Aktualisierung, die Verfügbarkeit der RTR-Sitzung und die lokale Routing-Policy. Kurzzeitig können zwei Netze unterschiedliche Ansichten haben, ohne dass eine davon absichtlich falsch ist.

Eine Community transportiert diese Akte nicht. Sie enthält weder die verwendeten VRPs noch Frische, Trust Anchor, Cache-Gesundheit oder Entscheidungsregel. Der Nachbar erhält das Urteil, kann es aus dem Attribut aber nicht nachvollziehen.

Hinzu kommt fehlende Authentizität. Gewöhnliche BGP-Pfadattribute über EBGP sind nicht signiert; Dritte können einen behaupteten Zustand hinzufügen oder verändern. Ein empfangenes Valid belegt daher nicht, wer es berechnet hat und ob es noch zur aktuellen lokalen Sicht des Empfängers passt.

Die alte Extended Community war nach innen gerichtet

RFC 8097 definierte eine nicht-transitive Origin Validation State Extended Community für die Weitergabe innerhalb eines AS. Vertrauenswürdige IBGP-Sprecher konnten ein intern berechnetes Ergebnis nutzen, ohne dass jedes Gerät separat validieren musste.

Standardmäßig muss eine Implementierung die Community bei Empfang von einem EBGP-Peer verwerfen und sollte sie nicht an EBGP-Peers senden. Eine konfigurierbare Ausnahme sind benachbarte AS unter derselben Verwaltung. Die maßgebliche Grenze ist also gemeinsame Kontrolle und Haftung, nicht allein die Art der BGP-Sitzung.

Die genehmigte Leitlinie zieht diese Grenze für alle Communities und künftigen Attribute, deren Zustandsänderung UPDATE über eine externe Grenze auslöst. Sie erfasst auch lokale Ergebnisse aus ASPA oder BGPsec, wenn Betreiber sie auf dieselbe Weise exportieren wollen.

Benötigt eine Plattform das Attribut intern, darf es dort bestehen bleiben. Vor der NLRI-Ankündigung an eine andere Verwaltungsdomäne muss es entfernt werden. Eine interne Implementierungshilfe erhält keine Außenwirkung.

Ein Ausfall, zwei Update-Wellen

Das Dokument illustriert die Kopplung mit AS65536 als Kunde von AS65537. Beide beziehen Daten von einem zentralen RTR-Dienst, beide arbeiten mit einem 300-Sekunden-Zyklus und beide setzen Communities nach Validierungszustand. Das ist ein analytisches Beispiel, kein gemeldeter Vorfall.

AS65536 aktualisiert sich eine Sekunde vor dem Dienstausfall. AS65537 wäre eine Sekunde danach an der Reihe. Der Provider verliert seine validierten Payloads zuerst, ändert seine Communities und schickt UPDATE in seinen Kundenkegel. AS65536 verarbeitet und verbreitet diese Änderungen.

Rund 300 Sekunden später läuft auch dessen lokale Sicht ab. Seine Communities wechseln nun ebenfalls, sodass aus derselben Abhängigkeit eine zweite Welle entsteht. Ein längerer Cache-TTL verschiebt den Ablauf; dauert der Ausfall länger, beseitigt er ihn nicht.

Weder Präfix noch Origin-AS mussten sich ändern. Das Ereignis lag im Validierungsdienst. Weil dessen lokales Ergebnis Teil des externen Pfads geworden war, wurde der Ausfall dem BGP-Kontrollplan in Rechnung gestellt.

Acht Prozent sind kein Randphänomen

Eine im Entwurf zitierte RIS-Messung vom Februar 2024 fand in 8 bis 10 Prozent der beobachteten BGP UPDATE öffentlich bekannte Communities für NotFound oder Valid. Nach Erstellung oder Entfernung eines ROA-Objekts zeigte sich zudem eine Update-Kette von ungefähr einer Stunde. Der Wert ist eine zeitgebundene Beobachtung, kein ewiger Netzanteil.

Für Mitte 2026 rechnet der Text mit etwa 1,3 Millionen IPv4- und IPv6-Präfixen, rund 65 Prozent davon ROA-gedeckt. Fällt ein RPKI-Cache aus und werden Zustände extern getragen, könnten mehr als 850.000 Routen erneut gesendet werden.

Lokale Neubewertung ist gewollt. Unnötig ist, dass Nachbarn ohne zusätzliche verifizierbare Evidenz dieselben Routen als neue Pfade verarbeiten müssen. Das belastet CPU, Speicher und Update-Warteschlangen und kann bei versetzten Ablaufzeiten kaskadieren.

Auch ein Angreifer kann die Kopplung nutzen. Wer signierte Objekte für eigene Präfixe ausstellen und zurückziehen kann, kann Zustände wiederholt ändern. Wer NLRI erneut ankündigt, kann unsignierte Attribute manipulieren. Der externe Zustand wird so zum Churn-Hebel.

Die Wirkung exportieren, nicht die Begründung

Validiert ein Netz RPKI und verwirft Invalid, sollte es solche Routen gar nicht an Kunden senden. Die exportierte Routenauswahl zeigt bereits die Wirkung seiner Policy. Eine zusätzliche Zustands-Community liefert dem Nachbarn keinen authentifizierten Beleg.

Der Nachbar sollte mit seiner eigenen aktuellen RPKI-Sicht validieren. Nur so bleiben Evidenz, Zeitpunkt und verantwortete Entscheidung verbunden. Kooperation bedeutet, interoperable Routen auszutauschen; sie bedeutet nicht, das lokale Urteil eines anderen Netzes als Erlaubnis zu übernehmen.

Die Betriebsregel ist überprüfbar: RPKI lokal erfassen und validieren, lokal entscheiden, Zustandsattribute innerhalb der gemeinsamen Verwaltung halten und an jeder externen Kante entfernen. Nach außen geht die Route, die die Policy bestanden hat — nicht die unsignierte Erzählung darüber, warum.

Quellen