3.4. Inbound Packet Processing (Eingehende Paketverarbeitung)

3.4.1. Reassembly (Wiederzusammensetzung)

Falls erforderlich, wird die Wiederzusammensetzung vor der ESP-Verarbeitung durchgeführt. Wenn ein Paket, das ESP zur Verarbeitung angeboten wird, als IP-Fragment erscheint, d.h. das OFFSET-Feld ungleich Null ist oder das MORE FRAGMENTS-Flag gesetzt ist, MUSS der Empfänger das Paket verwerfen; dies ist ein auditfähiges Ereignis. Der Audit-Log-Eintrag für dieses Ereignis SOLLTE den SPI-Wert, Datum/Uhrzeit des Empfangs, Quelladresse, Zieladresse, Sequenznummer und (in IPv6) die Flow-ID enthalten.

HINWEIS: Für die Paket-Wiederzusammensetzung verlangt die aktuelle IPv4-Spezifikation NICHT das Zurücksetzen des OFFSET-Feldes oder das Löschen des MORE FRAGMENTS-Flags. Damit ein wieder zusammengesetztes Paket von IPsec verarbeitet werden kann (anstatt als scheinbares Fragment verworfen zu werden), muss der IP-Code diese beiden Dinge tun, nachdem er ein Paket wieder zusammengesetzt hat.

3.4.2. Security Association Lookup (Sicherheitsassoziations-Suche)

Beim Empfang eines Pakets, das einen ESP-Header enthält, bestimmt der Empfänger die geeignete (unidirektionale) SA über eine Suche in der SAD. Für eine Unicast-SA basiert diese Bestimmung auf dem SPI oder dem SPI plus Protokollfeld, wie in Abschnitt 2.1 beschrieben. Wenn eine Implementierung Multicast-Verkehr unterstützt, wird auch die Zieladresse in der Suche verwendet (zusätzlich zum SPI), und die Absenderadresse kann ebenfalls verwendet werden, wie in Abschnitt 2.1 beschrieben. (Dieser Prozess wird im Security Architecture-Dokument detaillierter beschrieben.) Der SAD-Eintrag für die SA gibt auch an, ob das Sequence Number-Feld überprüft wird, ob 32- oder 64-Bit-Sequenznummern für die SA verwendet werden und ob das (explizite) ICV-Feld vorhanden sein sollte (und wenn ja, dessen Größe). Außerdem spezifiziert der SAD-Eintrag die Algorithmen und Schlüssel, die für Entschlüsselung und ICV-Berechnung (falls zutreffend) verwendet werden sollen.

Wenn keine gültige Security Association für dieses Paket existiert, MUSS der Empfänger das Paket verwerfen; dies ist ein auditfähiges Ereignis. Der Audit-Log-Eintrag für dieses Ereignis SOLLTE den SPI-Wert, Datum/Uhrzeit des Empfangs, Quelladresse, Zieladresse, Sequenznummer und (in IPv6) die Klartext-Flow-ID enthalten.

(Beachten Sie, dass SA-Verwaltungsverkehr, wie IKE-Pakete, nicht basierend auf SPI verarbeitet werden muss, d.h. man kann diesen Verkehr separat basierend auf Next Protocol- und Port-Feldern demultiplexen.)

3.4.3. Sequence Number Verification (Sequenznummern-Verifizierung)

Alle ESP-Implementierungen MÜSSEN den Anti-Replay-Dienst unterstützen, obwohl dessen Verwendung vom Empfänger auf SA-Basis aktiviert oder deaktiviert werden kann. Dieser Dienst DARF NICHT aktiviert werden, es sei denn, der ESP-Integritätsdienst ist auch für die SA aktiviert, da sonst das Sequence Number-Feld nicht integritätsgeschützt wurde. Anti-Replay ist sowohl auf Unicast- als auch auf Multicast-SAs anwendbar. Dieser Standard spezifiziert jedoch keine Mechanismen zur Bereitstellung von Anti-Replay für eine Multi-Sender-SA (Unicast oder Multicast). In Abwesenheit der Verhandlung (oder manuellen Konfiguration) eines Anti-Replay-Mechanismus für eine solche SA wird empfohlen, dass die Sender- und Empfängerprüfung der Sequenznummer für die SA deaktiviert wird (über Verhandlung oder manuelle Konfiguration), wie unten erwähnt.

Wenn der Empfänger Anti-Replay für eine SA nicht aktiviert, werden keine eingehenden Prüfungen der Sequence Number durchgeführt. Aus Sicht des Senders ist die Standardannahme jedoch, dass Anti-Replay beim Empfänger aktiviert ist. Um zu vermeiden, dass der Sender unnötige Sequenznummernüberwachung und SA-Einrichtung durchführt (siehe Abschnitt 3.3.3), SOLLTE der Empfänger, wenn ein SA-Einrichtungsprotokoll verwendet wird, den Sender während der SA-Einrichtung benachrichtigen, wenn der Empfänger keinen Anti-Replay-Schutz bietet.

Wenn der Empfänger den Anti-Replay-Dienst für diese SA aktiviert hat, MUSS der Empfangs-Paketzähler für die SA auf Null initialisiert werden, wenn die SA eingerichtet wird. Für jedes empfangene Paket MUSS der Empfänger überprüfen, dass das Paket eine Sequence Number enthält, die nicht die Sequence Number eines anderen während der Lebensdauer dieser SA empfangenen Pakets dupliziert. Dies SOLLTE die erste ESP-Prüfung sein, die auf ein Paket angewendet wird, nachdem es mit einer SA abgeglichen wurde, um die Zurückweisung doppelter Pakete zu beschleunigen.

ESP erlaubt eine zweistufige Verifizierung von Paketsequenznummern. Diese Fähigkeit ist wichtig, wenn eine ESP-Implementierung (typischerweise der kryptographische Modul-Anteil davon) nicht in der Lage ist, Entschlüsselung und/oder Integritätsprüfung mit der gleichen Rate wie die Schnittstelle(n) zu ungeschützten Netzwerken durchzuführen. Wenn die Implementierung zu einer solchen "Line-Rate"-Operation fähig ist, ist es nicht notwendig, die unten beschriebene vorläufige Verifizierungsstufe durchzuführen.

Die vorläufige Sequence Number-Prüfung wird unter Verwendung des Sequence Number-Wertes im ESP-Header durchgeführt und vor Integritätsprüfung und Entschlüsselung ausgeführt. Wenn diese vorläufige Prüfung fehlschlägt, wird das Paket verworfen, wodurch die Notwendigkeit kryptographischer Operationen durch den Empfänger vermieden wird. Wenn die vorläufige Prüfung erfolgreich ist, kann der Empfänger seinen lokalen Zähler noch nicht ändern, da die Integrität der Sequence Number zu diesem Zeitpunkt noch nicht verifiziert wurde.

Duplikate werden durch die Verwendung eines gleitenden Empfangsfensters zurückgewiesen. Wie das Fenster implementiert wird, ist eine lokale Angelegenheit, aber der folgende Text beschreibt die Funktionalität, die die Implementierung aufweisen muss.

Die "rechte" Kante des Fensters repräsentiert den höchsten, validierten Sequence Number-Wert, der auf dieser SA empfangen wurde. Pakete, die Sequenznummern enthalten, die niedriger als die "linke" Kante des Fensters sind, werden zurückgewiesen. Pakete, die in das Fenster fallen, werden gegen eine Liste empfangener Pakete innerhalb des Fensters geprüft. Wenn die ESN-Option für eine SA ausgewählt ist, werden nur die niederwertigen 32 Bits der Sequenznummer explizit übertragen, aber der Empfänger verwendet die vollständige Sequenznummer, die unter Verwendung der höherwertigen 32 Bits für die angegebene SA (von seinem lokalen Zähler) berechnet wurde, wenn er die empfangene Sequence Number gegen das Empfangsfenster prüft. Bei der Konstruktion der vollständigen Sequenznummer nimmt der Empfänger an, dass die höherwertigen 32 Bits inkrementiert wurden und zu einem neuen Sequenznummern-Unterraum übergegangen sind, wenn die im Paket übertragenen niederwertigen 32 Bits niedriger im Wert sind als die niederwertigen 32 Bits der Sequenznummer des Empfängers. (Dieser Algorithmus berücksichtigt Lücken im Empfang für eine einzelne SA von bis zu 2**32-1 Paketen. Wenn eine größere Lücke auftritt, KÖNNEN zusätzliche, heuristische Prüfungen zur Re-Synchronisierung des Empfänger-Sequenznummernzählers eingesetzt werden, wie im Anhang beschrieben.)

Wenn das empfangene Paket in das Fenster fällt und kein Duplikat ist, oder wenn das Paket rechts vom Fenster liegt, und wenn ein separater Integritätsalgorithmus verwendet wird, geht der Empfänger zur Integritätsverifizierung über. Wenn ein combined mode algorithm verwendet wird, wird die Integritätsprüfung zusammen mit der Entschlüsselung durchgeführt. In beiden Fällen MUSS der Empfänger, wenn die Integritätsprüfung fehlschlägt, das empfangene IP-Datagramm als ungültig verwerfen; dies ist ein auditfähiges Ereignis. Der Audit-Log-Eintrag für dieses Ereignis SOLLTE den SPI-Wert, Datum/Uhrzeit des Empfangs, Quelladresse, Zieladresse, die Sequenznummer und (in IPv6) die Flow-ID enthalten. Das Empfangsfenster wird nur aktualisiert, wenn die Integritätsverifizierung erfolgreich ist. (Wenn ein combined mode algorithm verwendet wird, muss die integritätsgeschützte Sequence Number auch mit der für Anti-Replay-Schutz verwendeten Sequence Number übereinstimmen.)

Eine minimale Fenstergröße von 32 Paketen MUSS unterstützt werden, wenn 32-Bit-Sequenznummern verwendet werden; eine Fenstergröße von 64 wird bevorzugt und SOLLTE als Standard verwendet werden. Eine andere Fenstergröße (größer als das Minimum) KANN vom Empfänger gewählt werden. (Der Empfänger benachrichtigt den Sender NICHT über die Fenstergröße.) Die Empfangsfenstergröße sollte für Hochgeschwindigkeitsumgebungen erhöht werden, unabhängig von Sicherheitsfragen. Werte für minimale und empfohlene Empfangsfenstergrößen für sehr hohe Geschwindigkeiten (z.B. Multi-Gigabit/Sekunde) Geräte werden in diesem Standard nicht spezifiziert.

3.4.4. Integrity Check Value Verification (Integritätsprüfwert-Verifizierung)

Wie bei der ausgehenden Verarbeitung gibt es mehrere Optionen für die eingehende Verarbeitung, basierend auf den Merkmalen der verwendeten Algorithmen.

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

Wenn separate Vertraulichkeits- und Integritätsalgorithmen eingesetzt werden, läuft die Verarbeitung wie folgt ab:

Wenn Integrität ausgewählt wurde, berechnet der Empfänger den ICV über das ESP-Paket minus den ICV unter Verwendung des spezifizierten Integritätsalgorithmus und verifiziert, dass er mit dem im Paket übertragenen ICV übereinstimmt. Details der Berechnung werden unten bereitgestellt.

Wenn die berechneten und empfangenen ICVs übereinstimmen, ist das Datagramm gültig und wird akzeptiert. Wenn der Test fehlschlägt, MUSS der Empfänger das empfangene IP-Datagramm als ungültig verwerfen; dies ist ein auditfähiges Ereignis. Die Log-Daten SOLLTEN den SPI-Wert, Datum/Uhrzeit des Empfangs, Quelladresse, Zieladresse, die Sequenznummer und (für IPv6) die Klartext-Flow-ID enthalten.

Implementierungshinweis:

Implementierungen können jeden Satz von Schritten verwenden, der zum gleichen Ergebnis wie der folgende Satz von Schritten führt. Beginnen Sie damit, das ICV-Feld zu entfernen und zu speichern. Prüfen Sie als Nächstes die Gesamtlänge des ESP-Pakets minus das ICV-Feld. Wenn implizites Padding erforderlich ist, basierend auf der Blockgröße des Integritätsalgorithmus, fügen Sie mit Nullen gefüllte Bytes an das Ende des ESP-Pakets direkt nach dem Next Header-Feld oder nach den höherwertigen 32 Bits der Sequenznummer an, wenn ESN ausgewählt ist. Führen Sie die ICV-Berechnung durch und vergleichen Sie das Ergebnis mit dem gespeicherten Wert unter Verwendung der von der Algorithmusspezifikation definierten Vergleichsregeln.
Der Empfänger entschlüsselt die ESP Payload Data, Padding, Pad Length und Next Header unter Verwendung des Schlüssels, Verschlüsselungsalgorithmus, Algorithmusmodus und kryptographischer Synchronisationsdaten (falls vorhanden), die von der SA angegeben werden. Wie in Abschnitt 3.3.2 sprechen wir hier davon, dass Verschlüsselung immer angewendet wird, wegen der Formatierungsimplikationen. Dies geschieht mit dem Verständnis, dass "keine Vertraulichkeit" durch Verwendung des NULL-Verschlüsselungsalgorithmus (RFC 2410) angeboten wird.
- Wenn explizite kryptographische Synchronisationsdaten, z.B. ein IV, angegeben sind, werden sie aus dem Payload-Feld entnommen und gemäß der Algorithmusspezifikation in den Entschlüsselungsalgorithmus eingegeben.
- Wenn implizite kryptographische Synchronisationsdaten angegeben sind, wird eine lokale Version des IV konstruiert und gemäß der Algorithmusspezifikation in den Entschlüsselungsalgorithmus eingegeben.
Der Empfänger verarbeitet jedes Padding wie in der Verschlüsselungsalgorithmusspezifikation spezifiziert. Wenn das Standard-Padding-Schema (siehe Abschnitt 2.4) verwendet wurde, SOLLTE der Empfänger das Padding-Feld überprüfen, bevor das Padding entfernt wird, bevor die entschlüsselten Daten an die nächste Schicht übergeben werden.
Der Empfänger prüft das Next Header-Feld. Wenn der Wert "59" (no next header) ist, wird das (Dummy-) Paket ohne weitere Verarbeitung verworfen.
Der Empfänger rekonstruiert das ursprüngliche IP-Datagramm aus:
- für Transportmodus -- äußerer IP-Header plus die ursprüngliche nächste Schichtprotokoll-Information im ESP Payload-Feld
- für Tunnelmodus -- das gesamte IP-Datagramm im ESP Payload-Feld.
Die genauen Schritte zur Rekonstruktion des ursprünglichen Datagramms hängen vom Modus (Transport oder Tunnel) ab und werden im Security Architecture-Dokument beschrieben. Mindestens SOLLTE der Empfänger in einem IPv6-Kontext sicherstellen, dass die entschlüsselten Daten 8-Byte-ausgerichtet sind, um die Verarbeitung durch das im Next Header-Feld identifizierte Protokoll zu erleichtern. Diese Verarbeitung "verwirft" jedes (optionale) TFC-Padding, das für Verkehrsfluss-Vertraulichkeit hinzugefügt wurde. (Falls vorhanden, wurde dies nach dem IP-Datagramm (oder Transport-Schicht-Frame) und vor dem Padding-Feld eingefügt (siehe Abschnitt 2.4).)

Wenn Integritätsprüfung und Verschlüsselung parallel durchgeführt werden, MUSS die Integritätsprüfung abgeschlossen sein, bevor das entschlüsselte Paket zur weiteren Verarbeitung weitergegeben wird. Diese Verarbeitungsreihenfolge erleichtert die schnelle Erkennung und Zurückweisung von wiederabgespielten oder gefälschten Paketen durch den Empfänger, vor der Entschlüsselung des Pakets, wodurch potenziell die Auswirkungen von Denial-of-Service-Angriffen reduziert werden.

Hinweis: Wenn der Empfänger Entschlüsselung parallel zur Integritätsprüfung durchführt, muss darauf geachtet werden, mögliche Race-Conditions in Bezug auf Paketzugriff und Extraktion des entschlüsselten Pakets zu vermeiden.

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

Wenn ein kombinierter Vertraulichkeits- und Integritätsalgorithmus eingesetzt wird, verfährt der Empfänger wie folgt:

Entschlüsselt und integritätsprüft die ESP Payload Data, Padding, Pad Length und Next Header unter Verwendung des Schlüssels, Algorithmus, Algorithmusmodus und kryptographischer Synchronisationsdaten (falls vorhanden), die von der SA angegeben werden. Der SPI aus dem ESP-Header und der (Empfänger-) Paketzählerwert (angepasst wie erforderlich aus der in Abschnitt 3.4.3 beschriebenen Verarbeitung) sind Eingaben in diesen Algorithmus, da sie für die Integritätsprüfung erforderlich sind.
- Wenn explizite kryptographische Synchronisationsdaten, z.B. ein IV, angegeben sind, werden sie aus dem Payload-Feld entnommen und gemäß der Algorithmusspezifikation in den Entschlüsselungsalgorithmus eingegeben.
- Wenn implizite kryptographische Synchronisationsdaten, z.B. ein IV, angegeben sind, wird eine lokale Version des IV konstruiert und gemäß der Algorithmusspezifikation in den Entschlüsselungsalgorithmus eingegeben.
Wenn die vom combined mode algorithm durchgeführte Integritätsprüfung fehlschlägt, MUSS der Empfänger das empfangene IP-Datagramm als ungültig verwerfen; dies ist ein auditfähiges Ereignis. Die Log-Daten SOLLTEN den SPI-Wert, Datum/Uhrzeit des Empfangs, Quelladresse, Zieladresse, die Sequenznummer und (in IPv6) die Klartext-Flow-ID enthalten.
Verarbeite jedes Padding wie in der Verschlüsselungsalgorithmusspezifikation spezifiziert, wenn der Algorithmus dies nicht bereits getan hat.
Der Empfänger prüft das Next Header-Feld. Wenn der Wert "59" (no next header) ist, wird das (Dummy-) Paket ohne weitere Verarbeitung verworfen.
Extrahiere das ursprüngliche IP-Datagramm (Tunnelmodus) oder den Transport-Schicht-Frame (Transportmodus) aus dem ESP Payload Data-Feld. Dies verwirft implizit jedes (optionale) Padding, das für Verkehrsfluss-Vertraulichkeit hinzugefügt wurde. (Falls vorhanden, wurde das TFC-Padding nach der IP-Payload und vor dem Padding-Feld eingefügt (siehe Abschnitt 2.4).)