Zusammenfassung

  • draft-ietf-idr-bgp-rpki-yang-02 sieht Origin-Validation-Gauges an fünf BGP-RIB-Stufen vor. YANG-Pfad, Nachbar und Adressfamilie gehören zur Aussage.
  • Derselbe Zählwert kann andere Routen meinen. Validierung beweist außerdem weder Auswahl und Export noch Annahme durch den Nachbarn oder tatsächliche Paketweiterleitung.

Vor der Änderung zeigte das System 10.000 origin-valid Routen. Danach ebenfalls. Die Zahl blieb richtig, obwohl eine geschützte Route verschwunden und eine beliebige andere hinzugekommen sein konnte.

Das ist kein Messfehler, sondern der Unterschied zwischen Anzahl und Identität. Genau diesen Unterschied macht draft-ietf-idr-bgp-rpki-yang-02 vom 30. September 2026 operativ relevant. Der IDR-Entwurf definiert getrennte YANG-Modelle für Origin-AS-Validierung, BGPsec und ASPA. Das Origin-Modell führt Gauges für unverified, unknown, invalid und valid an fünf Stellen.

Fünf Pfade, fünf Aussagen

Die Statistik liegt in adj-rib-in-pre, adj-rib-in-post, loc-rib, adj-rib-out-pre und adj-rib-out-post, jeweils für IPv4 und IPv6.

Inbound vor Policy beschreibt das Angebot des Nachbarn; inbound nach Policy den verbleibenden Bestand. Das lokale RIB enthält die lokale Sicht. Die Outbound-Stufen rahmen die Policy für einen bestimmten Nachbarn ein.

Ein Eingangswert beweist daher nicht den lokalen Bestand. Der lokale Bestand beweist keine Ankündigung. Der Post-Policy-Export beweist keine Annahme am anderen Ende. Keine dieser Messungen beweist für sich den Datenpfad.

Pfad, AFI/SAFI und Nachbar sind keine UI-Dekoration. Ohne sie wird eine gebundene Beobachtung zu einer unbegrenzten Behauptung. Ein Aggregat kann den Verlust eines Upstreams durch gleich viele Routen eines anderen ausgleichen und dabei Kosten, Geografie und Ausfallrisiko verbergen.

Ein Gauge kennt keine Mitglieder

gauge32 liefert eine aktuelle Anzahl, keine Routenliste und keinen Hash dieser Liste. Zwei Mengen gleicher Größe können andere Mitglieder haben. Eine Route geht, eine kommt; die Kurve bleibt flach. Eine Policy tauscht ganze Präfixklassen; die Summe kann gleich bleiben.

Wer Kontinuität nachweisen muss, braucht deshalb einen Mitgliedschaftsbeleg: etwa einen kanonischen Hash über Präfix, Ursprung, AS_PATH und Next Hop, eine begrenzte Liste oder gezielte Prüfungen kritischer Präfixe. Entscheidend ist, rekonstruieren zu können, was gezählt wurde.

Auch die Zeit gehört in den Beleg. Der eingefrorene Entwurf verspricht keinen transaktional synchronen Snapshot über alle fünf Pfade. Während der Konvergenz können wenige Sekunden Versatz Unterschiede erfinden oder verdecken.

„Valid“ ist kein Gesamturteil

RPKI-Origin-Validierung prüft Präfix und Origin-AS gegen validierte ROA-Daten. RFC 6811 legt das Verfahren an; RFC 8481 grenzt Validierung von einer nicht konfigurierten Policy-Aktion ab.

Eine origin-valide Route ist nicht automatisch schneller, günstiger, leak-frei, BGPsec-valid oder ASPA-valid. Sie beweist weder Cache-Frische noch Best-Path-Sieg, Export, Remote-Installation oder Forwarding.

Die drei getrennten Modelle bewahren diese Unterschiede. Ein einziges grünes „sicher“-Symbol würde sie vernichten.

Dieselbe Verteilung, andere Entscheidung

Origin-Validierung lässt sich pro Adressfamilie aktivieren und durch eligible-prefix-policy einschränken. Ein eigener Container bestimmt die Beteiligung am Best-Path. allow-invalid und allow-not-found steuern, welche Zustände berücksichtigt werden dürfen.

Der Versand der Extended Community aus RFC 8097 ist eine weitere Entscheidung. Die Exportbehandlung ist wiederum eigenständig, einschließlich Not-found-Regel und eigener Präfix-Policy mit Bezug auf RFC 8893.

Damit kann dieselbe Validierungsverteilung zu anderem Routing führen. Eine Änderung an allow-invalid, allow-not-found oder Export-Policy kann Auswahl und Ankündigungen austauschen, ohne den Valid-Zähler zu bewegen.

Ein Audit-Beleg muss deshalb die tatsächlich wirksame Konfiguration und Policy-Epoche binden. Die Controller-Absicht genügt nicht. RFC 8342 unterscheidet konfigurierte und operative Werte gerade deshalb, weil Verarbeitung, Protokolle und Hardware Abweichungen erzeugen können.

Eine Kette statt einer Ampel

Die Nachweiskette trennt Validierungseingaben und Frische, angewandte Konfiguration, exakten Messpfad und Zeitpunkt, Routenmitgliedschaft, Auswahlentscheidung, exportierte Menge und UPDATE, Annahme beim Nachbarn sowie beobachtete Erreichbarkeit.

Kein Glied beweist das nächste. Frische Daten beweisen keine Policy. Ein Zähler beweist keine Mitglieder. Mitglieder beweisen keine Auswahl. Auswahl beweist keinen Export. Export beweist keine Annahme. Annahme beweist keinen Dienst.

Bei Störungen wird dadurch die erste abweichende Grenze sichtbar. Das Dashboard kann über seine kleine Frage korrekt und über das größere Führungsversprechen völlig stumm gewesen sein.

Status und Running Code

Datatracker führt Revision 02 als aktiven Standards-Track-Internet-Draft im Status I-D Exists. Sie ist kein RFC. Die Quellen belegen weder eine Herstellerimplementierung noch einen Produktionseinsatz.

Bestehende Telemetrie kann dennoch schon heute Stufe, Peer, Familie, Policy-Epoche und Mengenidentität erhalten. Der Entwurf bietet eine gemeinsame Form, nicht die erste Existenz des Problems.

Heng Lus Minimum Initial Specification und Running-Code Primacy liefern die Linse: deterministische Validierungsregeln können gemeinsam sein, während Auswahl und Export lokale, überprüfbare Entscheidungen bleiben. Ein veröffentlichtes Modell ist keine Betriebsrealität. Implementierung und Nutzung sind es.

Die Abschlussfrage lautet daher nicht: „Blieb der Zähler grün?“ Sondern: Welche Routen wurden an welcher Stufe unter welcher wirksamen Policy ausgewählt und angekündigt—und wohin gingen die Pakete?

Quellen