Zusammenfassung

  • Das RIPE NCC hat die Ausstellung und Verwaltung von BGPsec-Routerschlüsselzertifikaten über seine RPKI-API eingeführt.
  • Die Ausstellung ist nur ein Teil der Kette: Pfadprüfung braucht kompatible Router und BGPsec-fähige Sitzungen auf beiden Seiten.

Ein Schlüsselzertifikat lässt sich nun beim RIPE NCC bestellen. Ob der Nachbarrouter damit etwas anfangen kann, ist die spannendere Frage. RPKI-Ingenieur Tim Bruijnzeels meldete am 22. Oktober die Unterstützung für BGPsec-Routerschlüssel in der API. Gleichzeitig benannte er die langsame Unterstützung in Hardware-Routern sowie Leistungs- und Einführungsprobleme. Im Mitgliederbericht vom 23. Oktober steht die Funktion bereits als neue Leistung.

Das Zertifikat bindet einen öffentlichen Routerschlüssel an eine AS-Nummer. Das Profil RFC 8209 erlaubt dem Router mit dem passenden privaten Schlüssel, sichere Ankündigungen für dieses AS zu signieren. Ein BGPsec-fähiger Router am anderen Ende einer entsprechenden Sitzung prüft die signierte AS-Folge. ROAs und Origin Validation beantworten die Frage nach dem Ursprung eines Präfixes; ASPA betrifft Providerbeziehungen. BGPsec betrachtet den Weg der Ankündigung.

Die API-Anleitung des RIPE NCC zeigt die Macht des AS-Inhabers im Detail: Ein LIR-API-Schlüssel mit RPKI-Berechtigung kann einen PKCS#10-Antrag senden, Schlüssel abrufen, Zertifikat und Kette herunterladen und einen Schlüssel gezielt widerrufen. Mehrere Schlüssel pro AS sind möglich. Die dokumentierten Beispielaufrufe verwenden den RPKI-Pilotserver. Diese Angabe begrenzt, was sich allein aus der Anleitung über erreichbare Betriebsumgebungen ablesen lässt.

Für Filterbetreiber und Peering-Partner ist die Trennung handfest. Das RIPE NCC schafft die Berechtigung, der AS-Inhaber bringt sie auf einen Router, der Nachbar prüft die Unterschrift. Erst dieses Zusammenspiel schützt den AS-Pfad. Die neue API öffnet die erste Tür; wie viele weitere aufgehen, zeigen die Netze.