Summary

  • draft-acee-lsr-ospfv3-deprecate-ah-00 schlägt vor, AH in neuen OSPFv3-Implementierungen nicht mehr vorzusehen und zu ESP mit NULL-Verschlüsselung oder zum OSPFv3 Authentication Trailer zu wechseln. Revision 00 ist ein individueller Internet-Draft, kein verabschiedeter Standard.
  • Eine Abkündigung ändert keinen laufenden Link. Erst müssen alle Router das Ersatzverfahren empfangen können, dann darf der Versand wechseln; der alte Pfad wird erst nach Nachweisen für Authentisierung, Nachbarschaft, LSDB und Weiterleitung geschlossen.

Im Wartungsfenster sendet Router A sein erstes Hello mit dem neuen Verfahren. B besitzt den Schlüssel, aber nicht die richtige eingehende SA. C führt ein geeignetes Image aus, hat die Funktion auf dieser Schnittstelle jedoch nicht aktiviert. D erwartet weiterhin AH. Vier Inventarsysteme können Grün zeigen; das erste Paket zeigt, dass noch kein gemeinsamer Kompatibilitätssatz besteht.

Genau darin liegt die operative Bedeutung von Deprecation of the IPsec Authentication Header (AH) for OSPFv3 Authentication, Revision 00 vom 30. September 2026. Der individuelle Entwurf strebt Standards Track an und würde RFC 4552 im Fall einer Genehmigung aktualisieren. Er ist weder RFC noch Nachweis einer bereits erfolgten Einführung.

RFC 4552 verlangt ESP-Unterstützung und erlaubt AH. Der Entwurf rät neuen OSPFv3-Implementierungen von AH ab, gestattet bestehenden Implementierungen die weitere Unterstützung zur Rückwärtskompatibilität mit Warnhinweis und empfiehlt ESP-NULL oder den Authentication Trailer aus RFC 7166.

ESP mit NULL-Verschlüsselung liefert Integrität und Authentisierung, keine Vertraulichkeit. Der Trailer schützt in seiner Berechnung auch die IPv6-Quelladresse. Beide Verfahren helfen nicht gegen einen kompromittierten Router, der bereits über einen gültigen gemeinsamen Schlüssel verfügt.

Dokumentstatus und Linkstatus sind verschiedene Dinge

Der Entwurf begründet die Konsolidierung mit begrenzter AH-Verbreitung, dem optionalen Implementierungsstatus in RFC 8221 und dem Aufwand getrennter Code-, Konfigurations- und Betriebspfade. OSPFv3-Pakete bleiben üblicherweise mit Link-Local-Adressen und Hop Limit 1 auf einem Link; deshalb sei der Zusatznutzen der AH-Abdeckung unveränderlicher IPv6-Felder begrenzt.

Das ist die Begründung der Autoren, keine unabhängige Produktzählung. Vor allem ist es keine Aushandlung auf dem Draht. Eine Veröffentlichung installiert keinen Schlüssel, erzeugt keine eingehende SA und koordiniert keinen Sendebeginn.

Revision 00 formuliert die harte Grenze: Eine OSPFv3-Schnittstelle oder virtuelle Verbindung nutzt einen Authentisierungsmechanismus, und alle Router am Link müssen übereinstimmen. Sichere Änderungseinheit ist der ganze Link.

Erst neuen Empfang vorbereiten, dann neu senden

RFC 4552 liefert bereits eine Reihenfolge für Schlüsselwechsel. Zuerst erhält jeder Router eine neue eingehende SA. Nachdem alle sie annehmen können, werden die ausgehenden SAs gewechselt. Erst wenn alle neu senden, werden die alten eingehenden SAs entfernt.

Der Wechsel von AH zu ESP ist mehr als ein Schlüsselwechsel, doch die Ordnung bleibt: neu empfangen, neu senden, alt entfernen. An jeder Grenze braucht es Belege aller Linkmitglieder.

Der Entwurf nennt entweder ein koordiniertes Wartungsfenster oder eine schrittweise Einführung auf Implementierungen, die vorübergehend mehrere Verfahren annehmen können. Diese Fähigkeit muss am laufenden Build und an der betroffenen Schnittstelle nachgewiesen werden.

Überlappung kauft Kontinuität durch eine zeitweise breitere Annahme. Zu kurz zerlegt sie Nachbarschaften; zu lang hält sie den alten Pfad offen. Nötig sind Eigentümer, vollständige Mitgliedsliste, Beginn, Ablaufzeit und Abbruchbedingung.

Full verrät nicht den benutzten Annahmepfad

ESP-NULL bleibt Teil der IPsec-Architektur und des SA- und Hand-Keying-Profils von RFC 4552. Der Authentication Trailer wird mit OSPFv3 getragen und verwendet SA-ID sowie eine streng steigende kryptografische 64-Bit-Sequenznummer.

RFC 7166 kennt einen optionalen Übergangsmodus: mit Trailer senden, Pakete ohne Trailer weiterhin annehmen. Das hält alte Nachbarn erreichbar, kann während des Übergangs aber nicht authentisierte Daten zulassen. Der Zustand Full allein genügt daher nicht; der Annahmepfad muss bekannt sein.

Ein gültiger Digest belegt Zugang zum gemeinsamen Schlüssel. Er identifiziert keine konkrete Person, beweist keinen unkompromittierten Router und autorisiert nicht automatisch jede LSA.

Das Entfernen des alten Pfads gehört zur Migration

Die Beweiskette trennt: exakte Revision; tatsächliche Unterstützung jedes Images; eingehender Zustand, Algorithmus und Schlüsselepoche; Ausgangswahl; authentisierte Hello- und Database-Description-Pakete; stabile Full-Nachbarn; konvergierte LSDB; FIB und Verkehrstest; Entfernung von AH oder permissiver Annahme; erneute Prüfung.

Keine Stufe beweist die nächste. Eine Nachbarschaft kann über den alten Pfad Full bleiben. Gleiche LSDBs beweisen keine FIB. Erfolgreicher Verkehr während der Überlappung lässt sich nicht dem Ersatzverfahren zurechnen.

Heng Lus Rahmen aus minimaler gemeinsamer Spezifikation, lokaler Zukunftsentscheidung, freiwilliger Annahme und Vorrang laufenden Codes trennt Standard und Einführung. Der Standard setzt Interoperabilität; der Betreiber wählt Verfahren und Fenster. Angenommene Pakete, Nachbarschaften, Datenbank und Weiterleitung beweisen die tatsächliche Annahme.

Die Führungsfrage lautet nicht, ob AH als überholt markiert wurde. Sie lautet, ob alle Router denselben neuen Nachweis in derselben Schlüsselepoche akzeptieren und der alte Pfad wirklich geschlossen ist.

Sources