3.3. Outbound Packet Processing (Ausgehende Paketverarbeitung)

Im Transportmodus kapselt der Sender die Protokollinformationen der nächsten Schicht zwischen den ESP-Header- und ESP-Trailer-Feldern und behält den angegebenen IP-Header (und alle IP-Erweiterungsheader im IPv6-Kontext) bei. Im Tunnelmodus können die äußeren und inneren IP-Header/Erweiterungen auf verschiedene Weise miteinander verknüpft sein. Der Aufbau des äußeren IP-Headers/der Erweiterungen während des Kapselungsprozesses wird im Security Architecture-Dokument beschrieben.

3.3.1. Security Association Lookup (Sicherheitsassoziations-Suche)

ESP wird nur dann auf ein ausgehendes Paket angewendet, nachdem eine IPsec-Implementierung festgestellt hat, dass das Paket mit einer SA verbunden ist, die eine ESP-Verarbeitung erfordert. Der Prozess zur Bestimmung, welche IPsec-Verarbeitung (falls vorhanden) auf ausgehenden Verkehr angewendet wird, wird im Security Architecture-Dokument beschrieben.

3.3.2. Packet Encryption and Integrity Check Value (ICV) Calculation (Paketverschlüsselung und ICV-Berechnung)

In diesem Abschnitt sprechen wir davon, dass Verschlüsselung immer angewendet wird, aufgrund der Formatierungsimplikationen. Dies geschieht unter der Annahme, dass "keine Vertraulichkeit" durch Verwendung des NULL-Verschlüsselungsalgorithmus (RFC 2410) geboten wird. Es gibt mehrere algorithmische Optionen.

3.3.2.1. Separate Confidentiality and Integrity Algorithms (Separate Vertraulichkeits- und Integritätsalgorithmen)

Wenn separate Vertraulichkeits- und Integritätsalgorithmen verwendet werden, geht der Sender wie folgt vor:

Kapseln (in das ESP Payload-Feld):
- für den Transportmodus -- nur die ursprünglichen Protokollinformationen der nächsten Schicht.
- für den Tunnelmodus -- das gesamte ursprüngliche IP-Datagramm.
Hinzufügen aller erforderlichen Paddings -- Optionales TFC-Padding und (Verschlüsselungs-) Padding
Verschlüsseln des Ergebnisses unter Verwendung des Schlüssels, des Verschlüsselungsalgorithmus und des für die SA spezifizierten Algorithmusmodus sowie aller erforderlichen kryptografischen Synchronisationsdaten.
- Wenn explizite kryptografische Synchronisationsdaten, z.B. ein IV, angegeben werden, werden sie gemäß der Algorithmusspezifikation in den Verschlüsselungsalgorithmus eingegeben und im Payload-Feld platziert.
- Wenn implizite kryptografische Synchronisationsdaten verwendet werden, werden sie gemäß der Algorithmusspezifikation konstruiert und in den Verschlüsselungsalgorithmus eingegeben.
- Wenn Integrität ausgewählt ist, wird die Verschlüsselung zuerst durchgeführt, bevor der Integritätsalgorithmus angewendet wird, und die Verschlüsselung umfasst nicht das ICV-Feld. Diese Verarbeitungsreihenfolge erleichtert die schnelle Erkennung und Ablehnung von wiedergegebenen oder gefälschten Paketen durch den Empfänger vor dem Entschlüsseln des Pakets und verringert möglicherweise die Auswirkungen von Denial-of-Service (DoS)-Angriffen. Sie ermöglicht auch die Möglichkeit der parallelen Verarbeitung von Paketen beim Empfänger, d.h. die Entschlüsselung kann parallel zur Integritätsprüfung stattfinden. Beachten Sie, dass, da der ICV nicht durch Verschlüsselung geschützt ist, ein Schlüssel-Integritätsalgorithmus verwendet werden muss, um den ICV zu berechnen.
Berechnen des ICV über das ESP-Paket minus des ICV-Feldes. Somit umfasst die ICV-Berechnung den SPI, die Sequenznummer, die Payload-Daten, das Padding (falls vorhanden), die Pad-Länge und den Next Header. (Beachten Sie, dass die letzten 4 Felder in Ciphertext-Form vorliegen, da die Verschlüsselung zuerst durchgeführt wird.) Wenn die ESN-Option für die SA aktiviert ist, werden die höherwertigen 32 Bits der Sequenznummer nach dem Next Header-Feld für Zwecke dieser Berechnung angehängt, aber nicht übertragen.

Für einige Integritätsalgorithmen muss die Byte-Zeichenfolge, über die die ICV-Berechnung durchgeführt wird, ein Vielfaches einer vom Algorithmus spezifizierten Blockgröße sein. Wenn die Länge des ESP-Pakets (wie oben beschrieben) nicht den Blockgrößenanforderungen für den Algorithmus entspricht, MUSS implizites Padding an das Ende des ESP-Pakets angehängt werden. (Dieses Padding wird nach dem Next Header-Feld oder nach den höherwertigen 32 Bits der Sequenznummer hinzugefügt, wenn ESN ausgewählt ist.) Die Blockgröße (und damit die Länge des Paddings) wird durch die Integritätsalgorithmusspezifikation angegeben. Dieses Padding wird nicht mit dem Paket übertragen. Das Dokument, das einen Integritätsalgorithmus definiert, MUSS konsultiert werden, um festzustellen, ob implizites Padding wie oben beschrieben erforderlich ist. Wenn das Dokument keine Antwort auf diese Frage angibt, ist die Standardannahme, dass implizites Padding erforderlich ist (wie erforderlich, um die Paketlänge an die Blockgröße des Algorithmus anzupassen.) Wenn Padding-Bytes benötigt werden, der Algorithmus aber den Padding-Inhalt nicht angibt, MÜSSEN die Padding-Oktette einen Wert von Null haben.

3.3.2.2. Combined Confidentiality and Integrity Algorithms (Kombinierte Vertraulichkeits- und Integritätsalgorithmen)

Wenn ein kombinierter Vertraulichkeits-/Integritätsalgorithmus verwendet wird, geht der Sender wie folgt vor:

Kapseln in das ESP Payload Data-Feld:
- für den Transportmodus -- nur die ursprünglichen Protokollinformationen der nächsten Schicht.
- für den Tunnelmodus -- das gesamte ursprüngliche IP-Datagramm.
Hinzufügen aller erforderlichen Paddings -- umfasst optionales TFC-Padding und (Verschlüsselungs-) Padding.
Verschlüsseln und Integritätsschutz des Ergebnisses unter Verwendung des Schlüssels und des für die SA spezifizierten kombinierten Modus-Algorithmus sowie aller erforderlichen kryptografischen Synchronisationsdaten.
- Wenn explizite kryptografische Synchronisationsdaten, z.B. ein IV, angegeben werden, werden sie gemäß der Algorithmusspezifikation in den kombinierten Modus-Algorithmus eingegeben und im Payload-Feld platziert.
- Wenn implizite kryptografische Synchronisationsdaten verwendet werden, werden sie gemäß der Algorithmusspezifikation konstruiert und in den Verschlüsselungsalgorithmus eingegeben.
- Die Sequenznummer (oder erweiterte Sequenznummer, je nach Bedarf) und der SPI sind Eingaben für den Algorithmus, da sie in die Integritätsprüfungsberechnung einbezogen werden müssen. Die Art und Weise, wie diese Werte in diese Berechnung einbezogen werden, ist eine Funktion des verwendeten kombinierten Modus-Algorithmus und daher nicht in diesem Standard spezifiziert.
- Das (explizite) ICV-Feld KANN Teil des ESP-Paketformats sein, wenn ein kombinierter Modus-Algorithmus verwendet wird. Wenn keines verwendet wird, ist üblicherweise ein analoges Feld Teil der Ciphertext-Payload. Die Position aller Integritätsfelder und die Art und Weise, wie die Sequenznummer und der SPI in die Integritätsberechnung einbezogen werden, MÜSSEN in einem RFC definiert werden, der die Verwendung des kombinierten Modus-Algorithmus mit ESP definiert.

3.3.3. Sequence Number Generation (Sequenznummer-Generierung)

Der Zähler des Senders wird auf 0 initialisiert, wenn eine SA eingerichtet wird. Der Sender inkrementiert den Sequenznummer-(oder ESN-)Zähler für diese SA und fügt die niederwertigen 32 Bits des Wertes in das Sequence Number-Feld ein. Somit enthält das erste Paket, das unter Verwendung einer gegebenen SA gesendet wird, eine Sequenznummer von 1.

Wenn Anti-Replay aktiviert ist (die Standardeinstellung), prüft der Sender, ob der Zähler nicht rotiert ist, bevor der neue Wert in das Sequence Number-Feld eingefügt wird. Mit anderen Worten, der Sender DARF NICHT ein Paket auf einer SA senden, wenn dies dazu führen würde, dass die Sequenznummer rotiert. Ein Versuch, ein Paket zu übertragen, das zu einem Sequenznummer-Überlauf führen würde, ist ein prüfbares Ereignis. Der Prüfprotokolleintrag für dieses Ereignis SOLLTE den SPI-Wert, das aktuelle Datum/die aktuelle Uhrzeit, die Quelladresse, die Zieladresse und (in IPv6) die Klartext-Flow-ID enthalten.

Der Sender nimmt an, dass Anti-Replay standardmäßig aktiviert ist, es sei denn, der Empfänger teilt dies anders mit (siehe Abschnitt 3.4.3). Somit erfordert das typische Verhalten einer ESP-Implementierung, dass der Sender eine neue SA einrichtet, wenn die Sequenznummer (oder ESN) rotiert oder in Erwartung dieser Wertrotation.

Wenn der zur Berechnung eines ICV verwendete Schlüssel manuell verteilt wird, SOLLTE eine konforme Implementierung KEINEN Anti-Replay-Dienst bereitstellen. Wenn ein Benutzer sich entscheidet, Anti-Replay in Verbindung mit SAs zu verwenden, die manuell verschlüsselt sind, MUSS der Sequenznummernzähler beim Sender über lokale Neustarts usw. hinweg korrekt gewartet werden, bis der Schlüssel ersetzt wird. (Siehe Abschnitt 5.)

Wenn Anti-Replay deaktiviert ist (wie oben angegeben), muss der Sender den Zähler nicht überwachen oder zurücksetzen. Der Sender inkrementiert jedoch weiterhin den Zähler, und wenn er den Maximalwert erreicht, rollt der Zähler auf Null zurück. (Dieses Verhalten wird für Multi-Sender-Multicast-SAs empfohlen, es sei denn, Anti-Replay-Mechanismen außerhalb des Geltungsbereichs dieses Standards werden zwischen Sender und Empfänger ausgehandelt.)

Wenn ESN (siehe Anhang) ausgewählt ist, werden nur die niederwertigen 32 Bits der Sequenznummer im Sequence Number-Feld übertragen, obwohl sowohl Sender als auch Empfänger vollständige 64-Bit-ESN-Zähler pflegen. Die höherwertigen 32 Bits sind auf algorithmus-/modusspezifische Weise in der Integritätsprüfung enthalten, z.B. können die höherwertigen 32 Bits nach dem Next Header-Feld angehängt werden, wenn ein separater Integritätsalgorithmus verwendet wird.

Hinweis: Wenn ein Empfänger sich entscheidet, Anti-Replay für eine SA nicht zu aktivieren, SOLLTE der Empfänger ESN NICHT in einem SA-Verwaltungsprotokoll aushandeln. Die Verwendung von ESN erzeugt eine Notwendigkeit für den Empfänger, das Anti-Replay-Fenster zu verwalten (um den korrekten Wert für die höherwertigen Bits des ESN zu bestimmen, die in der ICV-Berechnung verwendet werden), was im Allgemeinen der Vorstellung widerspricht, Anti-Replay für eine SA zu deaktivieren.

3.3.4. Fragmentation (Fragmentierung)

Falls erforderlich, wird die Fragmentierung nach der ESP-Verarbeitung innerhalb einer IPsec-Implementierung durchgeführt. Somit wird Transportmodus-ESP nur auf ganze IP-Datagramme angewendet (nicht auf IP-Fragmente). Ein IP-Paket, auf das ESP angewendet wurde, kann selbst von Routern unterwegs fragmentiert werden, und solche Fragmente müssen vor der ESP-Verarbeitung bei einem Empfänger wieder zusammengesetzt werden. Im Tunnelmodus wird ESP auf ein IP-Paket angewendet, das ein Fragment eines IP-Datagramms sein kann. Beispielsweise kann ein Sicherheitsgateway oder eine "Bump-in-the-Stack"- oder "Bump-in-the-Wire"-IPsec-Implementierung (wie im Security Architecture-Dokument definiert) Tunnelmodus-ESP auf solche Fragmente anwenden.

HINWEIS: Für den Transportmodus -- Wie am Ende von Abschnitt 3.1.1 erwähnt, müssen Bump-in-the-Stack- und Bump-in-the-Wire-Implementierungen möglicherweise zunächst ein von der lokalen IP-Schicht fragmentiertes Paket wieder zusammensetzen, dann IPsec anwenden und dann das resultierende Paket fragmentieren.

HINWEIS: Für IPv6 -- Für Bump-in-the-Stack- und Bump-in-the-Wire-Implementierungen ist es notwendig, alle Erweiterungsheader zu untersuchen, um festzustellen, ob ein Fragmentierungsheader vorhanden ist und daher das Paket vor der IPsec-Verarbeitung wieder zusammengesetzt werden muss.

Fragmentierung, ob von einer IPsec-Implementierung oder von Routern entlang des Pfades zwischen IPsec-Peers durchgeführt, reduziert die Leistung erheblich. Darüber hinaus schafft die Anforderung an einen ESP-Empfänger, Fragmente zur Wiederzusammensetzung zu akzeptieren, Denial-of-Service-Schwachstellen. Daher KANN eine ESP-Implementierung sich dafür entscheiden, die Fragmentierung nicht zu unterstützen, und kann übertragene Pakete mit dem DF-Bit markieren, um Path MTU (PMTU)-Erkennung zu erleichtern. In jedem Fall MUSS eine ESP-Implementierung die Erzeugung von ICMP-PMTU-Nachrichten (oder äquivalente interne Signalisierung für native Host-Implementierungen) unterstützen, um die Wahrscheinlichkeit einer Fragmentierung zu minimieren. Details der für die MTU-Verwaltung erforderlichen Unterstützung sind im Security Architecture-Dokument enthalten.