Zusammenfassung

  • draft-smyslov-ipsecme-ikev2-psp-02 sieht erst eine childless IKE-SA und vollständige Peer-Authentisierung vor. Danach transportiert ein geändertes CREATE_CHILD_SA in beiden Richtungen den PSP-Schlüssel, den der jeweilige Empfänger für eingehenden Verkehr gewählt hat.
  • Die Antwort bindet Peer, Traffic Selectors, SPI, PSP-Parameter und gewrapptes Material. Sie beobachtet weder die Installation im Sender-NIC noch Ableitung, ICV-Prüfung oder Nutzdatenempfang auf der Gegenseite.
  • PSP hat keine individuelle Sperre abgeleiteter Schlüssel und delegiert Replay-Schutz. SA-Umschaltung, doppelte Master-Key-Rotation, Replay-Urteil und Anwendungsergebnis brauchen deshalb eigene Nachweise.

Childless ist ein Sicherheitszustand, kein Betriebszustand

In IKE_SA_INIT handeln zwei Peers einen Key Wrap Algorithm aus. Der Responder signalisiert CHILDLESS_IKEV2_SUPPORTED. Anschließend beendet IKE_AUTH die Authentisierung, ohne bereits die PSP Child SA anzulegen. Das ist keine umständliche Vorstufe, sondern verhindert, dass der Initiator seinen Empfangsschlüssel an einen noch nicht authentisierten Responder sendet.

RFC 6023 schuf die childless Initiation für Situationen, in denen eine IKE-SA sinnvoll ist, bevor schützenswerter Verkehr existiert. Der PSP-Entwurf nutzt genau diese Trennung. Erst ein späteres CREATE_CHILD_SA darf die PSP-Schlüssel bewegen.

Damit hat das System nacheinander mehrere gültige Zustände: Fähigkeit angekündigt, IKE-Peer authentisiert, PSP-Material ausgetauscht, lokales Sendeobjekt installiert, erstes Paket geschützt, erstes Paket empfangen. Wer den zweiten oder dritten Zustand „Tunnel up“ nennt, überspringt die übrigen.

draft-smyslov-ipsecme-ikev2-psp-02 definiert die Schlüsselversorgung, nicht diesen ganzen Betriebsabschluss. HTML und XML enthalten keinen NIC-Installationsbeleg. Die Security Considerations stehen weiterhin auf „To be added“.

Beim PSP bestimmt der Empfänger den Sendeschlüssel der Gegenseite

Die PSP Architecture Specification vermeidet pro-SA Empfangsschlüssel im NIC. Der Empfänger hält zwei 256-Bit-Master-Keys. Das höchste SPI-Bit wählt einen davon; aus Master Key und SPI wird der SA-Schlüssel abgeleitet.

Nur der Empfänger kennt seine aktive Master-Key-Epoche und die noch freien SPI. Deshalb wählt er SPI und Schlüssel. Er übermittelt den abgeleiteten Schlüssel dem Peer, der damit Pakete zu ihm senden soll. Die Gegenrichtung benötigt eine zweite, ebenfalls unidirektionale SA.

Ein KD vom Host A an Host B enthält daher Material, das B zum Senden an A braucht. Diese Richtung muss in Logs erhalten bleiben. Ein einziges Feld „key exchange complete“ kann verschleiern, dass nur A→B im NIC programmiert wurde.

RFC 7296 leitet normale Child-SA-Schlüssel aus IKE-Geheimnissen und Nonces ab. PSP braucht empfängerbestimmtes Material. Der Entwurf verwendet dazu Key Download aus RFC 9838 in einer Unicast-Beziehung. Geschützter Transport beantwortet jedoch nicht die Frage, ob der Empfänger des Downloads das Material korrekt einsetzt.

Peer-Identität und Ausführungsobjekt sind nicht dasselbe

Die IKE-Authentisierung kann einen Controller, ein Gateway oder einen Hostdienst identifizieren. Hinter dieser Identität können mehrere NICs, Virtual Functions, VMs oder Accelerators stehen. Der Authentisierungsnachweis bestimmt daher nicht automatisch, welches Objekt PSP ausführt.

Auch die KWA-Aushandlung ist kein PSP-Exklusivvertrag. Der Entwurf erlaubt derselben IKE-SA, ESP- und PSP-SAs anzulegen. Ein korrektes Capability-Signal ist nicht die Absicht für diesen Traffic, und die Absicht ist noch keine lokale Installation.

Die Betriebsdaten sollten deshalb die Kette erhalten: IKE identity, IKE-SA, Proposal, Selectors, SPI, Key Download, lokales Device-Objekt und Ergebnis seiner Programmierung. Erst diese letzte Zuordnung verbindet den authentisierten Controller mit dem tatsächlichen Datenpfad.

Das Protokoll bindet Felder, nicht Hardwaretabellen

Das geänderte CREATE_CHILD_SA verwendet einen noch <TBA> markierten PSP Protocol Identifier und PSP-Parameter-Transform. Es transportiert Traffic Selectors, SPI und je einen KD-Payload pro Richtung. Der SPI eines Key Bag muss zu einem Proposal passen; SA_KEY ist mit SK_w = prf+(SK_d, "Key Wrap for PSP") geschützt.

Diese Struktur macht den Kontrollakt prüfbar. Sie sagt, welcher Peer welches Material für welchen Verkehr geliefert hat. Sie definiert nicht den Befehl zum NIC.

Das archivierte PSP Repository enthält Referenzcode und Tests. Die Architektur nennt verschiedene TX-Key-Modelle: on-chip Flow Table, SA-Datenbank im RAM oder Schlüssel beziehungsweise Verweis im Transmit Descriptor. Die Modelle haben andere Kapazitäten, Latenzen und Fehlerbelege. Öffentlicher Code belegt keine benannte Implementierung oder Produktion.

Ein lokaler Installationsbeleg sollte SPI, Richtung, Algorithmus, Epoche, NIC/VF, Queue oder SA-Index und Driver-Ergebnis binden, ohne Schlüsselmaterial zu protokollieren. Bleibt dieser Beleg aus, darf die Steuerung den Zustand nicht als Datenpfad-Erfolg ausgeben.

Stateless verschiebt Zustand und Verantwortung

PSP spart Empfangsschlüssel pro SA. Master Keys, Aktivstatus, SPI-Allokation, SA-Lifetime und Rotation bleiben. Der Sender hält seine TX-Schlüssel. Obere Schichten können zugelassene SPI je Socket prüfen.

RFC 4301 trennt SA-Management, Policy und Paketverarbeitung. RFC 4303 macht eine ESP-SA nicht zum Beleg für jedes Paket. PSP ändert die Speicherökonomie, nicht diese Beweisgrenze.

Auch Skalierungsangaben bleiben Designüberlegungen. Millionen SAs oder hohe Update-Raten in der Spezifikation sind kein Benchmark eines bestimmten NIC. IKE kann erfolgreich antworten, während TX-Tabellen voll sind oder Device-Kommandos warten.

Ein Canary prüft den Übergang in den Datenpfad

Die PSP-Spezifikation verlangt Zähler für erfolgreiche TX/RX-Pakete und Bytes, Authentisierungs- und Verschlüsselungsfehler, Formatfehler und ungültige Master-Key-Auswahl. Außerdem sollen Authentisierungsflag und SPI-Metadaten an Software gelangen.

Nach dem Key Download kann ein begrenztes Testpaket die Kette schließen: IKE-Transaktion, Device Ack, gesendeter SPI und IV, TX-Zähler, Empfangsepoche, Key-Derivation, ICV-Urteil, RX-Zähler und Upper-Layer-Receipt.

Das beweist nur diesen Testpunkt, aber es lokalisiert Fehler. TX ohne authentisiertes RX lenkt auf Pfad, Encapsulation, PSP-Version, Master-Key-Epoche oder ICV. RX ohne Anwendungsempfang lenkt auf SPI-Allowlist, Transport oder Applikation.

Beide Richtungen brauchen eigene Canaries. Die Symmetrie des CREATE_CHILD_SA darf nicht als Symmetrie des Betriebsergebnisses gelten.

Rekey-Erfolg beginnt vor dem Cutover

REKEY_SA kann die zu ersetzende PSP-SA angeben. IKEv2 erzeugt allgemein eine neue SA, verschiebt Verkehr und löscht danach die alte. Die Erstellungsantwort belegt den ersten Schritt.

Ein Rekey-Ledger braucht Installationszeit, erstes akzeptiertes Paket auf dem neuen SPI, letztes Paket auf dem alten, Classifier-Umschaltung, Delete-Acks und Verlust beziehungsweise Reordering. Solange der alte Pfad ausgewählt wird, ist die neue SA nur verfügbar, nicht wirksam.

Die Master-Key-Rotation schafft eine zweite Überlappung. Nach dem Wechsel des aktiven Keys bleibt der alte für bestehende SAs erhalten. Erst eine „double rotation“ kann ihn verdrängen; zuvor müssen betroffene Verbindungen rekeyed sein.

PSP bietet keine individuelle Sperre eines abgeleiteten Schlüssels. Ein administratives „revoked“ ist deshalb kein kryptographischer Effekt. Migration, Ende alten Traffics und Eviction der Master-Key-Epoche sind getrennte Nachweise.

Replay ist eine explizite Abhängigkeit

PSP selbst stellt keinen Replay-Schutz bereit und erwartet ihn von Layer 4, beispielsweise TCP. Der IKEv2-Key-Download ändert das nicht. Ein gültiger ICV sagt, dass ein Paket zur SA passt; er sagt nicht, ob dasselbe Paket bereits verarbeitet wurde.

Das ist keine Behauptung, eine konkrete Implementierung sei ungeschützt. Es ist eine Pflicht zur Zuordnung. Wer Replay-Ablehnung behauptet, muss Schicht, Zustand, Beobachtung und Urteil nennen. SPI und IV ersetzen diesen Beleg nicht.

Auch Anwendungsduplikate bleiben separat. Transport kann ein Paket nur einmal anliefern, während eine wiederholte Operation trotzdem zweimal wirkt. Kryptographische Authentizität, Replay-Fenster und Geschäftsidempotenz dürfen nicht in einem Häkchen verschwinden.

Revision 02 erneuert den Entwurf, nicht die Zusicherung

Die Datatracker API datiert Revision 02 auf den 30. September 2026 und ihr Ablaufdatum auf den 3. April 2027. Die Dokumentseite nennt sie einen aktiven individuellen Internet-Draft; die History verzeichnet drei Revisionen.

Gegenüber 01 ändern sich Datum, Nummer, Ablauf und Seitenkopf, nicht der Protokolltext. Der Header nennt Experimental als Ziel, doch Datatracker zeigt keinen RFC, Stream, verantwortlichen AD oder Standards Level. Das neue Datum ist weder Adoption noch Security Review oder Deployment.

PSP Identifier und Transform stehen weiter auf <TBA>. Das IANA IKEv2 Registry ist für zugewiesene Werte maßgeblich. Ein Antrag im Draft ist keine Zuteilung.

Quellen und Grenzen

Grundlage sind Revision 02 in Text/HTML/XML, Datatracker, RFC 7296, RFC 6023, RFC 9838, RFC 4301, RFC 4303, IANA sowie PSP Repository und Architektur. Sie belegen keine Produktion, Performance, Konformität, Schwachstelle, Störung oder Servicewirkung.