Zusammenfassung

  • RFC 9611 erlaubt mehrere Child SAs mit identischen TSi/TSr, damit verschiedene Ressourcen eigene Schlüssel und Sequenzräume führen und keinen gemeinsamen Zähler sperren müssen.
  • SA_RESOURCE_INFO kennzeichnet die logische Gruppe; optionale Daten dienen nur der Fehlersuche. TS_MAX_QUEUE begrenzt diese Selektorkombination und ist keine globale SA-Sperre.
  • Verhandelte SAs belegen keine Kapazität. Erforderlich sind Nachweise für Ein- und Ausgangsinstallation, lokale Bindung, Paketverteilung, Replay/Drop, Rekey, Löschung, Wiederkehr und Dienstleistung.

Auf beiden Gateways stehen dieselben Selektoren, mehrere SPIs und grüne Statuszeilen. Trotzdem kann der kleinere Peer alle eingehenden SAs installieren und nur eine ausgehende nutzen. Der größere kann viele Kontexte besitzen, aber sein Scheduler speist fast ausschließlich den ersten. Die Aushandlung ist symmetrisch; die Ausführung nicht.

RFC 9611 setzt an einem konkreten Engpass an. Gemeinsame kryptografische Zustände, Zähler und Sequenznummern zwingen viele CPUs zur Synchronisierung. Mehrere reguläre Child SAs behalten dieselbe Verkehrspolitik, erhalten aber eigene Schlüssel, SPIs und Sequenzräume.

Die Gleichheit schützt den Vertrag: Algorithmen, TSi/TSr, Modus und Kompression müssen dem ersten Mitglied entsprechen. Die Unabhängigkeit schafft die Parallelität. Aus der ersten Eigenschaft darf man die zweite nicht ableiten.

Ein Debugwert ist kein Ressourcenvertrag

Der optionale Resource Identifier soll Mitglieder innerhalb der Gruppe unterscheiden. Der Peer darf ihn nur zur Fehlersuche verwenden. Eine echte CPU-Nummer würde Hardwaredetails offenlegen und könnte Verkehrszuordnung verraten. Außerdem hat eine lokale Queue-Bezeichnung auf der Gegenseite keine operative Bedeutung.

Das Protokoll legt daher den kleinsten gemeinsamen Sachverhalt fest: Diese SAs gehören zu derselben Selektorpolitik. Welche Ressource sie besitzt und welcher Verkehr sie erreicht, entscheidet jedes System selbst.

Separate Sequenzen lösen genau eine Sperre

RFC 4303 bindet ESP-Sequenzen an Replay-Schutz; RFC 6479 liefert Kontext zur Fensterverarbeitung. RFC 9611 beseitigt diese Sicherheitsanforderung nicht, sondern verteilt sie auf mehrere gültige Zustandsräume.

Das dokumentierte Beispiel von 5 Gbit/s auf einer CPU zu 40–60 Gbit/s auf 25–30 CPUs ist Motivation, kein Produktversprechen. CPU, NIC, Treiber, Algorithmus, Paketgröße und Lastbild ändern das Ergebnis. Eine belastbare Messung zeigt Pakete und Bytes je SA, Ressourcenauslastung, Integritäts- und Replayfehler, Verluste, Latenz und Anwendungsdurchsatz.

Richtungen und Übergänge erzeugen Asymmetrie

Ein Peer mit weniger Ressourcen kann eine ungenutzte ausgehende Kopie weglassen, muss aber jede ausgehandelte eingehende SA installieren. Bei einem Host sollten beide Richtungen meist auf derselben CPU bleiben; ein Gateway kann sie wegen asymmetrischen Verkehrs getrennt verschieben. Das spätere Ergänzen einer ausgelassenen Ausgangshälfte kann Schlüsselmaterial verlangen, das der IKE-Daemon sonst gelöscht hätte.

Bei bedarfsgesteuerter Erstellung können beide Seiten gleichzeitig starten. Das auslösende Paket läuft über die erste SA; seine Antwort löst die Gegenrichtung aus. Während Rekey überlappen alte und neue Mitglieder. Deshalb empfiehlt der RFC mindestens die doppelte CPU-Zahl als vorübergehenden Spielraum.

Ist das Limit einer TSi/TSr-Kombination erreicht, sagt TS_MAX_QUEUE genau dies. NO_ADDITIONAL_SAS könnte fälschlich auch andere Selektoren ausschließen.

Löschen braucht eine Rückkehrentscheidung

Nach einer Delete-Nachricht fehlt einer Implementierung ohne ressourcenspezifische Trigger möglicherweise der Anlass zum Wiederaufbau. Sofortiges Wiederanlegen kann mit dem löschenden Peer endlos pendeln; Untätigkeit lässt beide dauerhaft auf dem ersten Mitglied.

RFC 2367 beschreibt den Kontext von SADB_ACQUIRE. RFC 9611 empfiehlt, den lokalen Auslöser um CPU oder Queue zu ergänzen. Diese Information muss lokal wirksam sein, nicht zur globalen Hardwareidentität werden.

Der sinnvolle Einsatz liegt zwischen vertrauensvoll betriebenen Hochlast-Gateways. Viele SAs verbrauchen Zustand und können SAD-Suchen verlangsamen. Für Remote-Access mit weniger vertrauenswürdigen Clients rät der RFC vom per-CPU-Modell und von standardmäßiger Aktivierung ab.

Quellen