Zusammenfassung

  • Die IKE SA schützt Steuerungsaustausche, Child SAs schützen AH- oder ESP-Verkehr. Ein IKE-Rekey erzeugt neue Kontroll-SPIs, Schlüssel und Nachrichtenzähler; der überlebende Nachfolger erbt vorhandene Child SAs, ohne deren Schlüssel automatisch zu erneuern.
  • Ein Child-Rekey besitzt eine eigene SPI-Linie und eigene Kollisionsregeln. Starten beide Seiten gleichzeitig, wird die SA aus dem Austausch mit dem niedrigsten Nonce als redundanter Kandidat geschlossen. Das niedrigste Nonce gewinnt nicht.
  • Belastbare Wartung verbindet drei Belege: Kontrolllinie, Obhut über jede geerbte oder ersetzte Child SA und beobachtete Nutzung. Ein undifferenzierter Rekey-Zähler beweist weder Verkehrsschlüsselrotation noch Dienstkontinuität.

Die entscheidende Lücke entsteht zwischen zwei grünen Anzeigen. Die neue IKE SA ist eingerichtet, der ESP-Verkehr läuft weiter. Was nicht sichtbar ist: Wurden die bestehenden Children vollständig dem Nachfolger zugeordnet, oder ist lediglich eine neue Kontrollverbindung entstanden?

IKEv2 behandelt Steuerung und Pakettransport als verschiedene Sicherheitsassoziationen. Die IKE SA schützt die Nachrichten, mit denen Zustand gepflegt wird. Child SAs schützen die Daten in jeweils einer Richtung. Beim Wechsel des Kontroll-Elternteils können die Children ihre kryptografische Identität behalten.

Tero Kivinen ist neben Charlie Kaufman, Paul Hoffman, Yoav Nir und Pasi Eronen einer der fünf Autoren von RFC 7296. Seine Signatur macht einen Beitrag nachvollziehbar. Sie begründet weder Alleinautorenschaft am IETF-Standard noch gegenwärtige Kontrolle über Implementierungen.

Ein gemeinsamer Beginn verbirgt zwei Lebensläufe

IKE_AUTH richtet gewöhnlich die authentisierte IKE SA und die erste Child SA eng nacheinander ein. Daher erscheinen beide in vielen Oberflächen als ein Tunnel. Der Standard bewahrt jedoch getrennte Fehlerzustände: Die Child kann scheitern, ohne die abgeschlossene IKE SA aufzuheben; ein späterer Child-Fehler soll die Steuerung nicht automatisch abreißen.

RFC 6023 erlaubt sogar eine authentisierte IKE SA ohne Child. Sie kann Peer-Lebendigkeit, NAT-Erkennung, geschützte Mitteilungen und spätere Child-Erstellung unterstützen. Autoren sind Yoav Nir, Hannes Tschofenig, Hui Deng und Raj Singh, nicht Kivinen. Das experimentelle Dokument dient als Kontextbeleg für die Zustandsgrenze.

Eine laufende Child beweist umgekehrt nur einen nutzbaren Paketpfad. Sie beweist nicht, dass die alte IKE SA bereits gelöscht werden darf oder die nächste Wartungsnachricht vom richtigen Nachfolger geschützt wird.

Jedes Ereignis braucht daher zuerst den SA-Typ. Ohne ihn fehlt bei „erstellt“, „erneuert“ oder „gelöscht“ das Objekt, auf das sich das Verb bezieht.

CREATE_CHILD_SA bezeichnet mehr als sein Name

Nach dem ersten Austausch kann jede Seite CREATE_CHILD_SA initiieren. Der Austausch erstellt eine zusätzliche Child, rekeyt eine vorhandene Child oder rekeyt die IKE SA selbst. Payloads, Benachrichtigungen und SPIs bestimmen den Zweck.

Eine neue Child wird mit SA-Vorschlag, Nonce, optionalem Schlüsselaustauschmaterial und TSi/TSr ausgehandelt. Der Responder darf die Selektoren einschränken. Beim Child-Rekey benennt REKEY_SA die zu ersetzende eingehende SA durch Protokoll und SPI. Der Nachfolger soll Selektoren oder Algorithmen nicht heimlich ändern.

Beim IKE-Rekey entstehen neue Initiator- und Responder-SPIs sowie neue Kontrollschlüssel. Message IDs und Fensterzustand beginnen in der neuen IKE SA erneut; die alte führt ihre Zähler für verbleibende Anfragen weiter. Die gemeinsame Austauschform löscht die Objektgrenzen nicht.

Eine Implementierung darf spätere CREATE_CHILD_SA-Anfragen verweigern. Kapazität und Richtlinie bleiben lokal. IANA registriert kollisionsfreie Nummern für Austauschtypen, Payloads, Transformationen und Benachrichtigungen, belegt aber weder Unterstützung noch Abschluss.

Der Nachfolger wird gebaut, bevor der Vorgänger geht

RFC 7296 beschreibt Rekey als Erstellung einer neuen SA mit anschließender Löschung der alten. Es ist keine Änderung am selben Datensatz. Make-before-break hält während des Übergangs einen wiederherstellbaren Zustand offen.

Gewinnt die neue IKE SA, erbt sie alle Children des Originals und schützt deren künftige Steuerungsnachrichten. Die Anfrage, sich selbst zu löschen, ist die letzte Anfrage der alten IKE SA.

Ein Beleg sollte Erstellung, Annahme durch die Gegenseite, Zuordnung des Child-Inventars, ersten gültigen Kontrollaustausch unter dem Nachfolger und Löschung des Vorgängers getrennt datieren. Zwischen „vorhanden“ und „sicher löschbar“ liegt eine prüfbare Übergangsphase.

IKEv2 handelt keine einheitliche Lebensdauer aus. Beide Endpunkte wenden lokale Vorgaben an; die kürzere löst üblicherweise den Rekey aus. Zeit-, Volumen- und Aktivitätsschwellen gehören in den lokalen Entscheidungsbeleg. Das gemeinsame Protokoll koordiniert, es zentralisiert die Lebensdauer nicht.

Geerbte Children behalten ihren Schlüsselstand

Eine geerbte Child SA behält eingehende und ausgehende SPIs, Selektoren, Modus, Algorithmen, Schlüsselepoche, Sequenz- und Replay-Zustand, Zähler und Lebensdauer. Nur ein eigener Child-Vorgang ersetzt diese Felder.

Neue IKE-SPIs belegen daher eine Kontrollrotation. Wer die Rotation aller Verkehrsschlüssel behauptet, muss alte und neue Child-SPI-Paare, Vorschläge, ausgewählte Transformationen, eine neue Schlüsselepoche, Aktivierung und Löschung des ersetzten Paares zeigen.

Auch die Dokumente trennen den Geltungsbereich. RFC 8247 gibt Algorithmusvorgaben für IKEv2 und aktualisiert ausdrücklich nicht die ESP-Verschlüsselung. RFC 8221 behandelt ESP und AH separat. Kivinen gehört mit jeweils anderen Mitautoren zu beiden Gruppen; die Kontroll- und Datenkryptografie bleiben dennoch verschiedene Bestände.

Eine Migration kann IKE auf modernere Algorithmen umstellen, während bestehende Children bis zu ihrer eigenen Frist weiterlaufen. Umgekehrt lässt sich eine Child erneuern, ohne die IKE SA anzufassen. Ein Lebenszyklusbericht benötigt zwei Uhren.

Authentisierung ist keine Vollmacht für Selektoren

Die IKE SA trägt Identitätsbelege und schützt die Aushandlung. Sie erlaubt dem authentisierten Peer nicht, beliebige Quell- und Zielbereiche zu beanspruchen. RFC 4301 verlangt, dass die Peer Authorization Database die zulässigen Verkehrselektoren begrenzt.

Der Responder kann TSi und TSr auf lokal erlaubte Bereiche verengen. Beim Übergang zu einem neuen IKE-Elternteil müssen Peer, genehmigter Selektorsatz und Richtlinienversion erhalten bleiben. Vererbung darf die Reichweite nicht erweitern.

„Peer authentisiert“, „Child installiert“ und „Selektoren autorisiert“ sind drei Entscheidungen. Wird nur die erste gespeichert, erscheint ein Identitätsnachweis fälschlich als Berechtigung für jedes Präfix.

Heng Lus Minimum Initial Specification ordnet diese Grenze ein: Der Standard teilt die kleinste für Interoperabilität nötige Sprache. Annahme, Umfang und Lebensdauer bleiben bei dem Teilnehmer, der die lokale Folge trägt.

Bereitschaft ist auf beiden Seiten zeitversetzt sichtbar

Der Responder muss Pakete auf der neuen SA annehmen können, bevor er die erfolgreiche Erstellungsantwort sendet. Der Initiator darf nach Verarbeitung der Antwort senden. Der Responder weiß in diesem Moment nicht, ob die Antwort ankam und die ausgehende Hälfte installiert wurde.

Beim Child-Rekey sendet er daher weiter über die alte SA, bis er gültigen Verkehr auf der Gegenhälfte des neuen Paars oder eine IKE-Anfrage zum Schließen des alten Paars erhält. Fehlt ein Anwendungspaket, kann der Initiator ein Dummy-ESP-Paket als Bereitschaftssignal senden.

Das Dummy-Paket ist Übergangsbeleg, nicht Nachweis einer nützlichen Transaktion. Eine erfolgreiche Aushandlung beweist ebenso wenig Rückweg, Replay-Verhalten, MTU oder Anwendungskontinuität. Betriebsergebnis und Verhandlungsergebnis brauchen eigene Messungen.

Peer und Selektoren identifizieren eine Child nicht eindeutig. IKEv2 erlaubt parallele SAs mit denselben Endpunkten und Selektoren, etwa für differenzierte Dienste. Ohne SPI und Linie verschmilzt die Telemetrie Vorgänger, Gewinner und redundanten Kandidaten.

Gleichzeitiger Child-Rekey erzeugt drei Paare

Ähnliche Lebensdauern können beide Seiten fast gleichzeitig zum Rekey veranlassen. Jitter reduziert die Wahrscheinlichkeit, beseitigt sie aber nicht. Vorübergehend existieren das alte Child-Paar und zwei neue Paare.

Solange mehrere eingehende SAs gültig sind, müssen Pakete über jede davon akzeptiert werden. Danach werden die vier Nonces der beiden Austausche oktettweise verglichen. Die präzise Regel lautet: Die SA aus dem Austausch mit dem niedrigsten Nonce ist redundant und wird geschlossen. Der niedrigste Wert verliert.

Der Ersteller des überlebenden Paars löscht das ersetzte alte Paar. Der Ersteller des redundanten Paars löscht den redundanten Kandidaten. Historie und Löschverantwortung aller drei Paare müssen erhalten bleiben.

Paketverlust kann eine verspätete Rekey-Anfrage für eine bereits ersetzte SA liefern. CHILD_SA_NOT_FOUND kann dann ein nicht fataler Kollisionsausgang sein. Ziel-SPI, Reihenfolge und Linie entscheiden über die Bewertung.

Beim IKE-Rennen steht auch die Obhut auf dem Spiel

Beide Seiten können die IKE SA gleichzeitig rekeyen. Neben dem alten Elternteil entstehen zwei neue Kandidaten. Die neue IKE SA, die zum niedrigsten Nonce gehört, wird geschlossen; der überlebende Kandidat muss alle Children erben.

Eine Einigung auf den Nonce-Vergleich reicht nicht. Vor der Löschung der alten Steuerung müssen beide Seiten denselben Nachfolger und dasselbe vollständige Child-Inventar sehen. Eine fehlende Child ist ein Obhutsfehler, auch wenn die neuen IKE-Schlüssel korrekt abgeleitet wurden.

In einem asymmetrischen Rennen kann eine Anfrage eintreffen, während die Gegenseite die alte IKE SA bereits schließt. RFC 7296 verwendet dafür TEMPORARY_FAILURE; nach Eingang der alten Löschung kann der Peer seinen eigenen Versuch aufgeben. Die vorübergehende Meldung kann geordnete Konvergenz statt Ausfall bedeuten.

Der Beleg verbindet beide Austausche, Nonces, redundanten Kandidaten, endgültigen Nachfolger, alte Löschung und die von beiden Seiten beobachtete Erbmenge. Ein Unterschied bleibt ein eigenständiger Fehler.

Mehrere Schlüsselaustausche verlangen noch genauere Belege

RFC 9370 ergänzt mehrere Schlüsselaustausche und IKE_FOLLOWUP_KE bei IKE- oder Child-Erstellung und -Rekey. Gleichzeitige Rekey-Kollisionen müssen gelöst sein, bevor die zusätzlichen Austausche fortgesetzt werden.

RFC 9370 stammt von einer anderen siebenköpfigen Autorengruppe und darf Kivinen nicht zugeschrieben werden. Sein Beitrag zu dieser Analyse ist strukturell: Je länger die Kette, desto weniger sagt ein allgemeines Erfolgsflag. Erweiterung, abgeschlossene Schritte, Gewinner und SA-Typ gehören in den Beleg.

Ein IANA-Codepunkt beweist weder Verbreitung noch Produktkonformität noch brauchbaren Verkehr. Registrierung, Implementierung, Aushandlung und Betrieb sind getrennte Evidenzstufen.

Die Autorengrenze folgt derselben Präzision. RFC 6023 und RFC 9370 liefern Nachbarkontext, werden dadurch aber nicht Teil einer einzelnen Biografie.

Kivinens Beitrag und seine institutionelle Grenze

Das am 31. August 2026 geprüfte IETF-Profil nennt Tero Kivinen als IPsecme chair, Tools-Team-Mitglied sowie Reviewer und Secretary des Security Area Directorate. Es listet 16 RFCs und keine aktiven Internet-Drafts. Das sind datierte Rollen, keine Zertifizierung.

RFC 7296 hat fünf Autoren. RFC 8247 und RFC 8221 besitzen eigene Autorengruppen; RFC 6023 und RFC 9370 wurden von anderen verfasst. Saubere Zuordnung macht Beiträge sichtbar, ohne Protokolleigentum zu erfinden.

Unter Heng Lus Agency-Perspektive liefern Autoren und Standardisierung eine begrenzte Koordinationshilfe. Betreiber bleiben für lokale Lebensdauern, Autorisierung, Algorithmen, Einsatz und Beurteilung des laufenden Codes verantwortlich.

Auch die Aussage dieses Artikels bleibt begrenzt. Die Quellen belegen keine Implementierungsquote, keine universelle VPN-Konformität und keine aktuelle Konfiguration eines konkreten Netzes.

Drei Bücher statt eines Rekey-Zählers

Das Kontrollbuch speichert Peer-Identitätsbelege, alte und neue IKE-SPIs, Algorithmen, Nonces, Message IDs, lokalen Auslöser, Kandidaten, Nachfolgerentscheidung, erste geschützte Nutzung und alte Löschung. Es beantwortet, wer die Steuerung übernahm.

Das Obhutsbuch führt jedes Child-SPI-Paar, Selektoren, PAD/SPD-Entscheidung, Modus, Algorithmus, Schlüsselepoche, lokale Lebensdauer, alten und neuen Elternteil, geerbt-oder-ersetzt sowie Löschzustand. Es beantwortet, was umzog und was wirklich neue Schlüssel erhielt.

Das Betriebsbuch beobachtet Pakete auf alten und neuen Children, Sequenz und Replay, Drop-Gründe, Dummy-Signal, ersten nützlichen bidirektionalen Verkehr und Anwendungskontinuität. Es beantwortet, was funktionierte.

Über SPI-Linie und Zeit lassen sich die Bücher verbinden, aber nicht gleichsetzen. Running-Code Primacy bedeutet hier: Die Spezifikation macht den Übergang prüfbar; der beobachtete Zustand liefert das Ergebnis. IKE-Rekey ist kein Child-Rekey-Beleg, und laufender Child-Verkehr kein Beleg korrekter künftiger Steuerung.

Quellen