Zusammenfassung

  • Eine Antwort in der Routing-Working-Group meldete, Ben Cartwright-Cox habe als Erster die neue RIPE-NCC-API genutzt, um ein BGPsec-Router-Schlüsselzertifikat zu veröffentlichen. Das RIPE-Repository enthält ein am 22. Oktober für AS212232 ausgestelltes Zertifikat.
  • RFC 8634 gliedert den Wechsel in fünf Phasen: Ersatz-Zertifikat veröffentlichen, Verteilung an RPKI-Caches abwarten, Router umstellen und UPDATEs auffrischen, das alte Zertifikat bei Bedarf widerrufen und den alten Schlüssel nach Ablauf seiner Validierung zurückziehen.

Das erste Zertifikat hat den Schalter verlassen

BGPsec ist von der Funktionsmeldung zu einer Datei geworden, die Netzbetreiber prüfen können. Am 22. Oktober kündigte RIPE NCC an, BGPsec-Routerzertifikate über die RPKI-API anlegen und verwalten zu können. Stunden später gratulierte eine Antwort im selben Routing-Working-Group-Thread Ben Cartwright-Cox, weil er die API für die erste Veröffentlichung genutzt hatte. Das öffentliche RIPE-Repository enthält ein an diesem Tag ausgestelltes BGPsec-Routerzertifikat für AS212232. Eine kleine Datei, dann eine heikle Operation: den Schlüssel eines laufenden Routers wechseln, ohne die signierte Route verschwinden zu lassen.

Die Dokumentation beschreibt den ganzen kleinen Werkzeugkasten: Router-Schlüssel anlegen, die bei einer CA konfigurierten Schlüssel auflisten, einen einzelnen Schlüssel abrufen, widerrufen und Zertifikat samt Ausstellerkette beziehen. Jede LIR braucht einen API-Schlüssel mit dem Recht Resource Certification (RPKI) API. Der Auftrag enthält ASN, BGP Identifier routerId und eine PKCS#10 Certificate Signing Request. Die CA vergibt die routerKeyId.

Die CSR ist kein Formularanhang. Sie enthält einen Zertifikatsantrag auf Grundlage eines öffentlichen Schlüssels; der Router-Private-Key wird laut API-Schema nicht hochgeladen. Das Zertifikat bindet die autorisierte AS-Nummer an den öffentlichen Schlüssel. RFC 8209 beschreibt das Profil; RFC 8205 legt fest, wie BGPsec Signaturen entlang eines AS-Pfads mitgeführt werden.

ROA und Origin Validation prüfen, ob ein AS ein Präfix ankündigen darf. ASPA beschreibt Providerbeziehungen und hilft, Route Leaks zu erkennen. BGPsec signiert den AS-Pfad, sodass ein kompatibler Router prüfen kann, ob jedes AS die Weitergabe der Route an das nächste AS autorisiert hat. Drei Werkzeuge in derselben Familie, drei verschiedene Fragen.

Das Zertifikat muss noch auf die Straße

Die API hilft beim Beantragen und Abrufen des Zertifikats. Bis eine Route signiert ankommt, braucht es mehr: Die CA veröffentlicht das Zertifikat im RPKI, der Router hält den zugehörigen privaten Schlüssel, die BGP-Sitzung handelt BGPsec aus und die Nachbarn verarbeiten den signierten Pfad. Ein ordentlich gespeichertes Zertifikat signiert kein UPDATE von allein. Es wartet auf seinen Router.

RIPE NCC benennt die Engpässe selbst: Hardware-Unterstützung in Routern hinkt hinterher, außerdem bleiben schrittweiser Rollout und Leistung schwierig. RFC 8207 erklärt den Grund: BGPsec kann mehr Speicher oder modernere CPUs erfordern. Betreiber können einzelne Border-Router zuerst ausstatten und die Auswirkungen beobachten. Bei Teilbetrieb entstehen Inseln signierter Pfade; ein nicht unterstütztes AS unterbricht die Signaturkette.

Die API automatisiert einen notwendigen Schritt. Sie kann weder die Produktplanung der Routerhersteller beschleunigen noch Nachbarn zur Aushandlung einer ungenutzten Funktion bewegen. Das nächste Stück Arbeit liegt bei den Netzen und ihren Geräten an den Grenzen.

Beim Schlüsselwechsel zählt die Reihenfolge

RFC 8634 gliedert den Schlüsselwechsel in fünf Phasen. Zuerst das neue Zertifikat veröffentlichen; dann warten, bis RPKI-Caches weltweit es abgeholt haben; den Router auf den neuen Schlüssel umstellen und ausgehende BGPsec-UPDATEs auffrischen; das alte Zertifikat bei Bedarf widerrufen, wenn alte Signaturen ungültig werden sollen; schließlich nach Ablauf seiner Validierung den Schlüssel über das RPKI-Router-Protokoll zurückziehen lassen, damit Router alte, damit signierte Routen entfernen. Die Wartephase sorgt dafür, dass Nachbarn den neuen öffentlichen Schlüssel kennen, bevor die neuen Signaturen eintreffen.

Die API automatisiert Aufrufe, aber nicht die Verteilungszeit. Ein brauchbares Änderungsprotokoll verbindet Veröffentlichung, Sichtbarkeit in den Caches, Routerwechsel, aufgefrischte UPDATEs und einen möglichen Widerruf. Der endgültige Schlüsselentzug folgt erst nach Ablauf der Validierung des alten Zertifikats. Ein Skript, das von „anlegen“ direkt zu „widerrufen“ springt, wäre beim Auslösen eines Ausfalls bemerkenswert effizient.

Die API identifiziert eine Schlüsselinstanz über ASN, routerId und key identifier. Laut Dokumentation kann dasselbe ASN verschiedene Schlüssel verwenden; derselbe Schlüssel kann auch mehreren ASNs zugeordnet sein, abhängig vom Betrieb. Das passt zu echten Netzen und verlangt saubere Inventare. „Schlüssel 12“ ist kein Notfallplan. ASN, Router, Fingerabdruck, Zertifikatsstatus und Umschaltzeitpunkt schon.

Vom Pilot in den Netzbetrieb

Die öffentliche Anleitung nennt localcert.ripe.net als RPKI-Pilot für BGPsec; im RIPE-Repository liegt das am 22. Oktober ausgestellte Zertifikat für AS212232. Der öffentlichen Dokumentation fehlt eine datierte Roll-over-Spur, die Zertifikatsfingerabdruck und Veröffentlichungszeit mit Routerwechsel, erneuertem signiertem UPDATE und Prüfung durch benannte BGPsec-Peers verbindet; sie würde zeigen, wie weit die API den Weg ins laufende Routing geebnet hat.

Der Erfolg misst sich nicht an der Zahl ausgegebener Zertifikate. Ein Betreiber muss einen Schlüssel anfordern, die Veröffentlichung sehen, den Routerwechsel planen, den signierten Pfad bei relevanten Peers prüfen und die Rotation ohne Verlust der Routen-Authentifizierung abschließen können. Die API beseitigt Reibung in einem Schritt. Die anspruchsvolle Technik bleibt bei Routern, Netzübergängen und der Zeit, die ein neuer Schlüssel braucht, um überall bekannt zu sein.

Quellen: Ankündigung der RIPE Routing Working Group vom 22. Oktober 2026; RIPE NCC BGPsec-API-Dokumentation; IETF RFC 8209; IETF RFC 8205; IETF RFC 8207; IETF RFC 8634.; RIPE-Routerzertifikat im Rohformat