Zusammenfassung

  • Eine mit beiden ASN konfigurierte BGPsec-PE braucht gültige Schlüssel für beide und muss den alten Schlüssel bis zur Migration ihrer relevanten eBGP-Sitzungen behalten. Das ist eine Bedingung für Pfadauthentisierung, kein Unternehmensnachweis.
  • Gleichzeitige ROAs, Doppelsignaturen und pCount=0 sind eng begrenzte Routingfakten. Sie belegen weder Übernahme, Kontrolle, vollständige Migration, Zustimmung eines Peers noch Paket- oder Service-Erfolg.

Ein kryptographischer Nachweis wirkt oft stärker, als sein Gegenstand erlaubt. Er kann korrekt zeigen, dass eine bestimmte PE einen bestimmten BGPsec-Pfad unter bestimmten Schlüssel- und Policybedingungen konstruiert hat. Er zeigt nicht, weshalb die Schlüssel existieren, wie viele andere Router schon umgestellt wurden oder welchen rechtlichen Vorgang jemand daraus ableiten möchte.

RFC 8206 behandelt eine mögliche AS-Migration. Ein Provider kann AS zusammenführen, alte ASN eine Weile weiterverwenden und eine PE gegenüber einem Peer als alte ASN erscheinen lassen. Diese Möglichkeit ist ein Szenario im Standard, kein Bericht über eine konkrete Fusion. Die Migration kann sich hinziehen; sie verlangt weder einen gleichzeitigen Wechsel aller Router noch eine Koordination mit allen Kunden. Die alte ASN kann deshalb weiter benötigt werden, weil eine lokale eBGP-Nachbarschaft sie noch erwartet.

Auch eine doppelte Ursprungsermächtigung beantwortet nur ihre eigene Frage. Während PEs der alten ASN ein Präfix weiter originieren, kann die neue ASN einen ROA dafür benötigen. RFC 8206 erlaubt diese parallelen ROAs. Ein ROA ermächtigt eine ASN für die RPKI-Ursprungsvalidierung. Er ist keine Eigentumsurkunde, keine Registermitteilung, kein Nachweis über die Annahme beim Kunden und kein Bericht darüber, welcher Pfad später bevorzugt wird. Zwei erlaubte Ursprünge sind kein Zertifikat für eine abgeschlossene Übergabe.

RFC 8205 begrenzt auch den BGPsec-Teil. RPKI-Zertifikate bescheinigen Zuteilungen von AS-Nummern und IP-Adressraum; der Sender nutzt den dazugehörigen privaten Schlüssel, ein Validator braucht ihn nicht. Eine gültige Prüfung betrifft damit Secure_Path und die lokal eingerichtete Vertrauens- und Geschäftsbeziehung. Sie beweist nicht, dass die FIB diesen Weg auswählte, dass ein Paket sein Ziel erreichte, dass eine Anwendung funktionierte oder dass sich die Kontrolle über ein Unternehmen änderte.

Die konkrete Regel aus RFC 8206 ist bewusst klein. Sie gilt an einer lokal mit neuer und alter ASN konfigurierten PE und einer bestehenden eBGP-Grenze. Ausgehend signiert die PE für beide ASN; der Übergangsteil für die alte ASN erhält pCount=0. Gegenüber einem Nicht-BGPsec-Peer enthält der rekonstruierte AS_PATH diesen Teil nicht, während der BGPsec-Secure_Path ihn behält. Eingehend fügt die PE den Teil nur unter der festgelegten Bedingung hinzu, wenn die CE noch die alte ASN erwartet. So wird ein bekannter Rand korrekt behandelt, nicht eine Fusion an das gesamte Routing-System übermittelt.

Die RFC verwirft ausdrücklich die Annahme, dass eine unkoordinierte Kundendomäne pCount=0 akzeptieren müsse. Sie fordert weder eine Fernkonfiguration der CE noch globale Synchronität oder einen sichtbar längeren Pfad. Genau diese Zurückhaltung macht die Regel als gemeinsame minimale Interoperabilität brauchbar. Sie macht aber auch jede Behauptung über Implementierung oder Annahme außerhalb des Rands unbegründet.

Der alte Schlüssel bleibt nach der Norm so lange gültig, bis alle relevanten eBGP-Sitzungen migriert sind. Das ist eine Pflegepflicht für den PE-Betreiber, keine in einer Signatur veröffentlichte Fortschrittsanzeige. Ob alle Sitzungen migriert sind, zeigen nur Sitzungsinventar, PE-Konfiguration, Schlüsselzeiträume, Validator-Logs und unabhängige Weiterleitungs- oder Service-Beobachtungen. Jeder Empfänger bewertet einen Pfad zudem nach seiner eigenen Policy.

Heng Lus Gedanke der Minimum Initial Specification passt genau auf diese Arbeitsteilung. Die gemeinsame Schicht bestimmt nur die deterministischen Regeln für Interoperabilität und Sicherheit. Zeitplan, Schlüsselverwahrung, Peer-Policy, Kundeneinbindung und tatsächliche freiwillige Übernahme bleiben lokal. Real wird Adoption dort, wo kompatible Akteure implementieren, prüfen und akzeptieren — nicht dort, wo ein RFC oder Schlüssel bloß sichtbar ist.

Eine saubere Untersuchung trennt daher Norm, ROA, Schlüsselzustand, signierten Pfad, Validatorentscheidung, Sitzungsstand, beobachtete Weiterleitung und Service sowie gegebenenfalls Register- und Unternehmensbelege. Wesley George ist Mitautor der technischen Regel; seine Regel gibt einem alten Schlüssel keine Stimme für eine Fusion.

Quellen