Zusammenfassung

  • Das EE-Zertifikat eines ROA muss explizite IP-Ressourcen enthalten, darf kein inherit verwenden und darf keine AS-Identifier-Delegation-Erweiterung tragen.
  • Die autorisierte AS-Nummer steht als asID im signierten Inhalt. Das belegt eine begrenzte Erlaubnis, nicht Identität, Nichtabstreitbarkeit oder eine aktive Route.
  • Validierung, VRP-Ableitung, BGP-Beobachtung, Routerzustand, lokale Policy, Pfadauswahl und Lieferung brauchen eigene Nachweise.

Die zusätzliche Erweiterung machte das Objekt ungültig

Ein Aussteller wollte vollständig sein. Neben den IP-Ressourcen nahm er die AS-Nummer als RFC-3779-Erweiterung in das Zertifikat auf. Die Signatur stimmte, die Werte passten zusammen – und trotzdem musste das ROA verworfen werden.

RFC 9582 verlangt diese Trennung. Das EE-Zertifikat muss die IP Address Delegation Extension enthalten; jeder Payload-Präfix muss in ihr liegen. inherit ist verboten. Die Autonomous System Identifier Delegation Extension wird dagegen für ROAs nicht verwendet und darf nicht vorhanden sein.

Das asID steht im signierten RouteOriginAttestation-Payload. Damit sagt die zertifizierte Adressautorität, welches AS die genannten Präfixe originieren darf. Das Zertifikat behauptet nicht, der Signierer sei das AS, kenne dessen Rechtsträger oder habe eine BGP-Sitzung gesehen.

Der Sicherheitsabschnitt setzt die sprachliche Grenze: Die PKI liefert Autorisierung, keine ausdrückliche Authentisierung; ein ROA soll auch keine Nichtabstreitbarkeit vermitteln. „AS authentisiert“ wäre daher keine Kurzfassung, sondern eine neue, unbelegte Behauptung.

Scope steckt in Objekt und Länge

Ein ROA nennt genau ein AS. Werden zwei ASes zugelassen, entstehen zwei Objekte. Ihre Lebenszyklen müssen getrennt bleiben, damit Widerruf und Fehler nicht als eine einzige Tabellenzeile verschwinden.

Jeder Adresseintrag hat einen Präfix und optional maxLength. Ohne Feld gilt nur die exakte Länge. Mit Feld werden spezifischere Präfixe bis zum Grenzwert zugelassen. RFC 9319 warnt vor unnötig großen Bereichen, weil sie unbeabsichtigte Ursprünge gültig erscheinen lassen können.

Diese Breite ist eine Berechtigung, keine Beobachtung. Selbst der engste Eintrag belegt nicht, dass ein Router den Präfix ankündigt oder wer das AS tatsächlich kontrolliert.

RFC 9582 definiert zudem eine kanonische Ordnung aus AFI, Startadresse, Präfixlänge und effektiver Maximallänge. Gleiche Tupel sind Duplikate. Dadurch werden semantisch gleiche Inhalte vergleichbar; Repository-Frische, Validatorstand und Routerzustand bleiben unberührt.

Ein Fehler betrifft das ganze signierte Objekt

Zuerst gelten RFC 6488, Zertifikatspfad, Signatur und generisches Objektprofil. Danach folgen Ressourcencontainment, kein inherit, keine AS-Erweiterung und vollständige Inhaltskonformität. Scheitert eine Prüfung, ist das gesamte ROA ungültig.

Eine lokale Reparatur einzelner Zeilen wäre gefährlich. Sie würde neuen Inhalt unter der Autorität einer Signatur verwenden, die genau diesen reparierten Inhalt nicht abdeckt. Der Fehlerbeleg muss zum Aussteller zurück, statt im Validator eine Ersatzautorität zu erzeugen.

Erst ein gültiges Objekt liefert VRPs. RFC 6811 vergleicht danach eine empfangene Route anhand von Präfix, Länge und Origin-AS. Valid, Invalid und NotFound beschreiben dieses Verhältnis zu einem bestimmten Datensatz, nicht den Charakter des AS und nicht die Korrektheit des gesamten AS_PATH.

Vom Cache zum Paket bleiben mehrere Grenzen

RFC 8210 transportiert Validierungsdaten zum Router. Eine bestehende Sitzung beweist nicht automatisch aktuelle Serien, und ein empfangenes VRP beweist keine Policy-Anwendung. RFC 7115 und RFC 8893 behandeln die lokale Nutzung bei Import und Export.

Ein Router kann einen Zustand berechnen, eine Ausnahme anwenden, einen anderen Pfad bevorzugen oder gar keine nutzbare Route haben. Danach müssen FIB, Weiterleitung und Anwendung separat beobachtet werden. Der ROA-Signer besitzt über diese späteren Schritte keine automatische Entscheidungsgewalt.

Die belastbare Aussage bleibt zeitgebunden: Unter diesem Trust Anchor und Repository-Snapshot bestand diese Autorisierung. Sie identifiziert keinen Betreiber und berichtet nicht, ob die autorisierte Handlung stattfand.

Quellen