Zusammenfassung

  • OpenBSD 8.0 erschien am 20. Oktober und hält fest, dass rpki-client Trust-Anchor-Constraints nun korrekt auf BGPsec-Routerzertifikate anwendet.
  • Die lokale Regel begrenzt, was ein einzelner Validator akzeptiert. Sie steuert weder die Veröffentlichung durch den Trust Anchor noch die Entscheidungen anderer Validatoren.

Der Zaun bekommt ein weiteres Tor

Die OpenBSD-8.0-Seite fasst die Änderung knapp: Constraints für BGPsec-Routerzertifikate in rpki-client(8) werden korrekt angewendet. Im ausführlichen Changelog steht derselbe Eintrag. OpenBSD 8.0 wurde am 20. Oktober veröffentlicht.

Der Unterschied zwischen vorhandener Funktion und wirksamer Prüfung liegt oft in einem Zertifikatstyp. Ein BGPsec-Routerzertifikat verbindet einen Schlüssel mit dem Einsatz von BGPsec und den zugehörigen Internetnummernressourcen. OpenBSD bestätigt mit der Release-Notiz, dass rpki-client die Constraints jetzt auch auf diese Zertifikate korrekt anwendet. Die öffentliche Notiz nennt weder ein betroffenes Netz noch einen Vorfall; belegt ist die Codekorrektur.

Die Änderung trifft auf den SIDROPS-Entwurf der IETF, „Constraining RPKI Trust Anchors“. Version -02 schlägt vor, dass jede RPKI-Prüfstelle (RP) lokal festlegt, welche Ressourcen sie von einem Trust Anchor (TA) erwartet. Der RP vergleicht IP-Adressen und AS-Nummern aus einem End-Entity-Zertifikat mit dieser Grenze. Liegen Ressourcen außerhalb, verwirft dieser RP das signierte Objekt bei seiner eigenen Prüfung.

„Alle Ressourcen“ ist eine großzügige Vollmacht

Laut Entwurf führen alle fünf Regional Internet Registries (RIRs) im normalen Betrieb alle Ressourcen unter ihren TA-Zertifikaten auf. Das senkt das Risiko einer ungültigen Zertifikatskette bei vorübergehenden Inkonsistenzen, besonders während Ressourcentransfers. Für einen RP kann die signierte Reichweite dadurch größer aussehen als der aktuelle Bestand des Registers.

Eine lokale .constraints-Datei gibt dem RP einen zweiten Entscheidungspunkt. Jede Datei gehört zu dem TA, dessen .tal denselben Namen trägt. Betreiber können Präfixe, Adressbereiche und AS-Nummern mit allow freigeben und mit deny Ausnahmen herausschneiden. deny hat Vorrang; was in keiner allow-Zeile steht, wird implizit abgelehnt. Niemand muss erst das ganze Internet als Positivliste eintragen, um einen Block auszunehmen.

Ein Formatfehler hat eine harte Folge. Der Entwurf verlangt, dass der RP eine fehlerhafte Datei vollständig verwirft und End-Entity-Zertifikate nicht anhand dieser Datei prüft. Bis die Datei korrigiert ist, greift die lokale Constraint-Schicht für diesen TA nicht. Syntaxprüfung, Paketverteilung und Aktualisierungsverantwortung gehören damit zur Sicherheitskontrolle.

Der Prüfbereich ist klar umrissen: Objekte, deren Profil IP- oder AS-Ressourcen ausdrücklich in RFC-3779-Erweiterungen aufführt. Dazu zählen ROAs, ASPAs, RSCs und BGPsec-Routerzertifikate. Signierte TALs und Manifeste stehen als Beispiele außerhalb des Bereichs, weil sie geerbte Ressourcen verwenden. Die Regel begrenzt die lokale RPKI-Prüfung; welche Route ein Router installiert, hängt anschließend von Datenzufuhr und Routing-Policy ab.

Der Code war vor dem Normtext da

Der aktuelle -02-Entwurf ist ein aktiver Internet-Draft. Datatracker führt den SIDROPS-Status als „Waiting for Write-Up Revised I-D Needed – Issue raised by WGLC“. Vor einer RFC-Veröffentlichung soll der Anhang zum Implementierungsstand entfernt werden.

Die Funktion ist bereits implementiert. Der Anhang berichtet, dass rpki-client in C das Verfahren seit 2023 standardmäßig aktiviert und nennt außerdem eine Rust-Umsetzung (panda-rpki) sowie eine Go-Umsetzung. Laut den Verfassern lieferten alle drei mit denselben OpenBSD-Fixtures gleiche Ergebnisse. Die IETF weist zugleich darauf hin, dass sie die von den Beitragsleistenden gelieferten Angaben nicht geprüft hat. Das belegt gemeldete Implementierungen und gemeinsame Testdaten, aber kein unabhängiges Interoperabilitäts-Audit. Das aktuelle OpenBSD-Handbuch beschreibt .constraints-Dateien je TA sowie lokale allow- und deny-Regeln.

Die Korrektur in 8.0 zeigt, wie eine etablierte Funktion bei einer Zertifikatsfamilie anders greifen kann. Der Changelog nennt weder frühere betroffene Versionen noch den genauen Codepfad; diese Details würden das historische Risikobild präzisieren. Fest steht: OpenBSD korrigierte die Anwendung auf BGPsec-Routerzertifikate. Ein Test muss deshalb jede Objektklasse abdecken, statt nur das Vorhandensein einer Option zu bestätigen.

Eine kleine Datei kann sechs Monate unterwegs sein

Der Entwurf empfiehlt Paketbetreuern, die Constraints mit einem Betriebssystem oder Drittanbieterpaket verteilen, mit sechs Monaten Verzögerung bis zur Aktualisierung beim Nutzer zu rechnen. Ressourcenbestände und Transferregeln ändern sich. Die lokale Liste muss dem Umfang folgen, den sie durchsetzen soll. Eine alte allow-Liste kann inzwischen legitime Ressourcen aussperren; eine fehlende Regel kann mehr freigeben, als der Betreiber wollte.

Die NRO-Strategie 2026–2028 nennt ein Trust-Anchor-Constraints-Dokument als geplante RPKI-Arbeit. Das NRO-RPKI-Programm hatte für 2025 bereits ein Lösungspapier zur Konsultation über Trust-Anchor-Konfiguration als Ziel geführt. Während die institutionelle Arbeit weiterläuft, ändert sich auch der Validator-Code. OpenBSD 8.0 liefert dafür einen frischen Beleg.

Für Netzbetreiber bleiben die Prüffragen handfest: Bildet die Datei den gewünschten Ressourcenbereich ab? Gehört sie zum richtigen TAL? Kommt sie mit Paketupdates an? Lässt sie sich fehlerfrei laden? Greift sie bei jeder verwendeten Zertifikatsklasse? Der OpenBSD-Eintrag macht die letzte Frage zum Pflichtpunkt.

Quellen