2. Encapsulating Security Payload Packet Format (ESP-Paketformat)
Der (äußere) Protokollheader (IPv4, IPv6 oder Extension), der unmittelbar vor dem ESP-Header steht, MUSS den Wert 50 in seinem Protocol (IPv4)- oder Next Header (IPv6, Extension)-Feld enthalten (siehe IANA-Webseite unter http://www.iana.org/assignments/protocol-numbers). Abbildung 1 veranschaulicht das oberste Format eines ESP-Pakets. Das Paket beginnt mit zwei 4-Byte-Feldern (Security Parameters Index (SPI) und Sequence Number). Diesen Feldern folgen die Payload Data, die eine Unterstruktur haben, die von der Wahl des Verschlüsselungsalgorithmus und -modus sowie von der Verwendung von TFC-Padding abhängt, was später ausführlicher untersucht wird. Den Payload Data folgen die Felder Padding und Pad Length sowie das Feld Next Header. Das optionale Feld Integrity Check Value (ICV) vervollständigt das Paket.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ----
| Security Parameters Index (SPI) | ^Int.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cov-
| Sequence Number | |ered
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ----
| Payload Data* (variable) | | ^
~ ~ | |
| | |Conf.
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cov-
| | Padding (0-255 bytes) | |ered*
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| | Pad Length | Next Header | v v
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ------
| Integrity Check Value-ICV (variable) |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Abbildung 1. Oberste Ebene des ESP-Paketformats
* Wenn kryptografische Synchronisationsdaten im Payload-Feld enthalten sind, z.B. ein Initialisierungsvektor (IV, siehe Abschnitt 2.3), werden diese in der Regel nicht als solche verschlüsselt, obwohl sie oft als Teil des Chiffretextes bezeichnet werden.
Der (übertragene) ESP-Trailer besteht aus den Feldern Padding, Pad Length und Next Header. Zusätzliche implizite ESP-Trailer-Daten (die nicht übertragen werden) sind in der Integritätsberechnung enthalten, wie nachfolgend beschrieben.
Wenn der Integritätsdienst ausgewählt ist, umfasst die Integritätsberechnung den SPI, die Sequence Number, die Payload Data und den ESP-Trailer (explizit und implizit).
Wenn der Vertraulichkeitsdienst ausgewählt ist, besteht der Chiffretext aus den Payload Data (mit Ausnahme eventuell enthaltener kryptografischer Synchronisationsdaten) und dem (expliziten) ESP-Trailer.
Wie oben erwähnt, können die Payload Data eine Unterstruktur haben. Ein Verschlüsselungsalgorithmus, der einen expliziten Initialisierungsvektor (IV) erfordert, z.B. der Cipher Block Chaining (CBC)-Modus, stellt den zu schützenden Payload Data häufig diesen Wert voran. Einige Algorithmenmodi kombinieren Verschlüsselung und Integrität in einer einzigen Operation; dieses Dokument bezeichnet solche Algorithmenmodi als "Kombinationsmodus-Algorithmen". Die Berücksichtigung von Kombinationsmodus-Algorithmen erfordert, dass der Algorithmus die Payload-Unterstruktur, die zur Übermittlung der Integritätsdaten verwendet wird, explizit beschreibt.
Einige Kombinationsmodus-Algorithmen bieten Integrität nur für verschlüsselte Daten, während andere Integrität für einige zusätzliche Daten bieten können, die nicht zur Übertragung verschlüsselt werden. Da die Felder SPI und Sequence Number als Teil des Integritätsdienstes Integrität erfordern und sie nicht verschlüsselt sind, muss sichergestellt werden, dass ihnen Integrität gewährt wird, wann immer der Dienst ausgewählt wird, unabhängig vom Stil des verwendeten Kombinationsalgorithmus-Modus.
Wenn ein Kombinationsmodus-Algorithmus verwendet wird, wird erwartet, dass der Algorithmus selbst sowohl den entschlüsselten Klartext als auch eine Bestanden/Nicht-bestanden-Anzeige für die Integritätsprüfung zurückgibt. Bei Kombinationsmodus-Algorithmen kann der ICV, der normalerweise am Ende des ESP-Pakets erscheint (wenn Integrität ausgewählt ist), weggelassen werden. Wenn der ICV weggelassen wird und Integrität ausgewählt ist, liegt es in der Verantwortung des Kombinationsmodus-Algorithmus, in den Payload Data ein ICV-äquivalentes Mittel zur Überprüfung der Paketintegrität zu kodieren.
Wenn ein Kombinationsmodus-Algorithmus Integrität nur für verschlüsselte Daten bietet, ist es erforderlich, den SPI und die Sequence Number als Teil der Payload Data zu replizieren.
Schließlich wird eine neue Bestimmung getroffen, um Padding für Verkehrsfluss-Vertraulichkeit nach den Payload Data und vor dem ESP-Trailer einzufügen. Abbildung 2 veranschaulicht diese Unterstruktur für Payload Data. (Hinweis: Dieses Diagramm zeigt Bits auf der Leitung. Auch wenn erweiterte Sequenznummern verwendet werden, werden nur 32 Bits der Sequence Number übertragen (siehe Abschnitt 2.2.1).)
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Security Parameters Index (SPI) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+---
| IV (optional) | ^ p
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | a
| Rest of Payload Data (variable) | | y
~ ~ | l
| | | o
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | a
| | TFC Padding * (optional, variable) | v d
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+---
| | Padding (0-255 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Pad Length | Next Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Integrity Check Value-ICV (variable) |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Abbildung 2. Unterstruktur der Payload Data
* Wenn der Tunnelmodus verwendet wird, kann die IPsec-Implementierung Traffic Flow Confidentiality (TFC)-Padding (siehe Abschnitt 2.4) nach den Payload Data und vor dem Padding (0-255 Bytes)-Feld hinzufügen.
Wenn ein Kombinationsalgorithmus-Modus verwendet wird, kann der in Abbildungen 1 und 2 gezeigte explizite ICV weggelassen werden (siehe Abschnitt 3.3.2.2 unten). Da Algorithmen und Modi bei der Einrichtung einer SA festgelegt werden, ist das detaillierte Format der ESP-Pakete für eine gegebene SA (einschließlich der Payload-Data-Unterstruktur) für den gesamten Verkehr auf der SA festgelegt.
Die folgenden Tabellen beziehen sich auf die Felder in den vorhergehenden Abbildungen und veranschaulichen, wie mehrere Kategorien algorithmischer Optionen, jede mit einem anderen Verarbeitungsmodell, die oben genannten Felder beeinflussen. Die Verarbeitungsdetails werden in späteren Abschnitten beschrieben.
Tabelle 1. Getrennte Verschlüsselungs- und Integritätsalgorithmen
| Feld | Anzahl Bytes | Erforderlich [1] | Verschlüsselungsabdeckung | Integritätsabdeckung | Übertragen |
|---|---|---|---|---|---|
| SPI | 4 | M | Y | plain | |
| Seq# (niedrige Bits) | 4 | M | Y | plain | |
| IV | variable | O | Y | plain | |
| IP datagram [2] | variable | M or D | Y | Y | cipher[3] |
| TFC padding [4] | variable | O | Y | Y | cipher[3] |
| Padding | 0-255 | M | Y | Y | cipher[3] |
| Pad Length | 1 | M | Y | Y | cipher[3] |
| Next Header | 1 | M | Y | Y | cipher[3] |
| Seq# (hohe Bits) | 4 | if ESN [5] | Y | not xmtd | |
| ICV Padding | variable | if need | Y | not xmtd | |
| ICV | variable | M [6] | plain |
[1] M = obligatorisch; O = optional; D = Dummy
[2] Wenn Tunnelmodus -> IP-Datagramm; Wenn Transportmodus -> nächster Header und Daten
[3] Chiffretext, wenn Verschlüsselung ausgewählt wurde
[4] Kann nur verwendet werden, wenn Payload seine "echte" Länge angibt
[5] Siehe Abschnitt 2.2.1
[6] obligatorisch, wenn ein separater Integritätsalgorithmus verwendet wird
Tabelle 2. Kombinationsmodus-Algorithmen
| Feld | Anzahl Bytes | Erforderlich [1] | Verschlüsselungsabdeckung | Integritätsabdeckung | Übertragen |
|---|---|---|---|---|---|
| SPI | 4 | M | plain | ||
| Seq# (niedrige Bits) | 4 | M | plain | ||
| IV | variable | O | Y | plain | |
| IP datagram [2] | variable | M or D | Y | Y | cipher |
| TFC padding [3] | variable | O | Y | Y | cipher |
| Padding | 0-255 | M | Y | Y | cipher |
| Pad Length | 1 | M | Y | Y | cipher |
| Next Header | 1 | M | Y | Y | cipher |
| Seq# (hohe Bits) | 4 | if ESN [4] | Y | [5] | |
| ICV Padding | variable | if need | Y | [5] | |
| ICV | variable | O [6] | plain |
[1] M = obligatorisch; O = optional; D = Dummy
[2] Wenn Tunnelmodus -> IP-Datagramm; Wenn Transportmodus -> nächster Header und Daten
[3] Kann nur verwendet werden, wenn Payload seine "echte" Länge angibt
[4] Siehe Abschnitt 2.2.1
[5] Die Algorithmenwahl bestimmt, ob diese übertragen werden, aber in jedem Fall ist das Ergebnis für ESP unsichtbar
[6] Die Algorithmusspezifikation bestimmt, ob dieses Feld vorhanden ist
Die folgenden Unterabschnitte beschreiben die Felder im Header-Format. "Optional" bedeutet, dass das Feld weggelassen wird, wenn die Option nicht ausgewählt ist, d.h. es ist weder im übertragenen Paket noch im für die Berechnung eines ICV formatierten Paket vorhanden (siehe Abschnitt 2.7). Ob eine Option ausgewählt wird oder nicht, wird als Teil der Einrichtung der Sicherheitsassoziation (SA) bestimmt. Somit ist das Format der ESP-Pakete für eine gegebene SA für die Dauer der SA festgelegt. Im Gegensatz dazu sind "obligatorische" Felder immer im ESP-Paketformat vorhanden, für alle SAs.
Hinweis: Alle in IPsec verwendeten kryptografischen Algorithmen erwarten ihre Eingabe in kanonischer Netzwerk-Byte-Reihenfolge (siehe Anhang von RFC 791 [Pos81]) und erzeugen ihre Ausgabe in kanonischer Netzwerk-Byte-Reihenfolge. IP-Pakete werden ebenfalls in Netzwerk-Byte-Reihenfolge übertragen.
ESP enthält keine Versionsnummer. Wenn es daher Bedenken hinsichtlich der Rückwärtskompatibilität gibt, MÜSSEN diese durch Verwendung eines Signalisierungsmechanismus zwischen den beiden IPsec-Peers zur Sicherstellung kompatibler Versionen von ESP (z.B. Internet Key Exchange (IKEv2) [Kau05]) oder eines Out-of-Band-Konfigurationsmechanismus behoben werden.