1 Neuerungen des Headers im neuen Internet-Protokoll IPv6

1.1 IPv6-Header

 

Abb. 1.1: Struktur des Ipv4-Headers

   

Abb. 1.2: Struktur des IPv6-Headers

 

Die Version ist 6.

 

Im Feld »Priorität« kann der Sender einem Paket 16 Prioritäten zuordnen. Ein Teil dieser Prioritäten ist bereits für zwei verschiedene Gruppen von Anwendungen reserviert:

 

 

1. Für »klassische« Anwendungen ohne Real-Zeit-Anforderungen, wie News, E-mail, Dateitransfer, Datenbankzugriff und Internetsteuerpakete. An diesen Anwendungen werden im allgemeinen keine Real-Zeit-Anforderungen gestellt. Der Kontext der höheren Priorität bedeutet, das Paket möglicherweise schneller zu bearbeiten. Zum Beispiel sollte der interaktive Verkehr des Telebanking (Priorität 6) bevorzugt gegenüber den Paketen der  elektronischen Post (Priorität 2) übertragen werden (Tab. 1.1). Ferner können diese Prioritäten zur Flußkontrolle verwendet werden. Im Fall eines Staus werden nur die wichtigeren Pakete (d. h. diejenigen mit höherer Priorität) bearbeitet. Die Pakete mit niedrigerer Priorität werden verworfen und entsprechend der Flußkontrollenstrategie zu einem späteren Zeitpunkt übertragen.

 

 

Priorität	Typ der Übertragung
0	nicht charakterisierter Verkehr
1	Füllverkehr (z.B. News)
2	unabhängige Datenpakete (z.B. E-Mail)
3	(reserviert)
4	abhängige Pakete größerer Datenblöcke (z.B. FTP, NFS)
5	(reserviert)
6	interaktiver Verkehr (z.B. Datenbankzugriff)
7	Internet Steuerverkehr (z.B. SNMP)

 

Tab. 1.1: Aktuelle Prioritäten für Anwendungen ohne Real-Zeit-Anforderungen

 

 

2. Für die Anwendungen mit Real-Zeit-Anforderungen werden die Prioritäten 8 bis 15 verwendet. Diese Prioritäten erlauben dem Sender, die Wichtigkeit der Real-Zeit-Ströme zu bestimmen. Solche Anwendungen stehen vor allem mit Multimedia wie Live-Audio und LiveVideo in Verbindung. Diese Prioritäten werden bei der Implementierung von Mechanismen für Flußkontrolle (network scheduling) und der Prozeßverwaltung (process scheduling) entlang des multimedialen Stromes gesetzt.

 

Das Feld »Flow Label« identifiziert einen Strom (flow), d. h. eine Kette von zusammenhängenden Paketen mit gleichem Sender und gleichem (Unicast- oder Multicast-) Empfänger, die von den Routern gesondert behandelt werden sollen. Diese gesonderte Behandlung könnten z. B. Garantien für QoS (Quality of Service, Dienstqualität) oder für Real-Zeit-Verkehr sein. Die Art dieser Behandlung kann explizit über ein spezielles Protokoll (z. B. das Reservierungsprotokoll RSVP für Multimediaströme) oder durch die Pakete mit diesem Flow Label selbst erfolgen. Ein Beispiel des letzteren wäre die Nutzung des Hop-by-Hop-Headers um spezielle Steueraktionen zu initiieren.

Das Feld ist 24 Bit lang. Es war ursprünglich mit dem Feld »Priorität als Identifikator des Stromes (Flow ID)« gedacht. Das Flow Label ist eine pseudo-zufällige Zahl (zwischen 1 und FFFFFF), die in Kombination mit der IP-Adresse des Senders einmalig ist. Alle Pakete eines Stromes müssen die gleiche Sender-Adresse, Empfänger-Adresse, Priorität und Flow Label haben. Der Wert 0 bedeutet, daß kein Flow Label genutzt wird. Ein Flow Label wird von einem Router entsprechend der zuvor vereinbarten Aktion interpretiert oder ignoriert, falls der Router Flow Label nicht unterstützt.

Das Resultat dieser Aktion kann in einem Cache gespeichert werden, so daß die nachfolgenden Pakete dieses Stromes es erneut nutzen können. Das Flow Label kann dann als Schlüssel zum Hashing des Cachespeichers bei den Routern genutzt werden. Falls die Art der Behandlung jedoch nicht explizit spezifiziert ist, kann der Router bei einem gültigen Flow Label (unterschiedlich von 0) sie selbst festlegen. Diese Aktion kann auch für die Dauer von maximal 6 Sekunden ge-cached werden.

 

Das Feld »Payload-(»Nutzlast«)-Länge« bestimmt die Länge (in Byte) des Rests des Paketes nach dem IPv6-Header. Wie das Feld »Paketlänge« in IPv4 wird es mit 16 Bit kodiert, was einer maximalen Paketlänge von 64 KByte entspricht. Im Gegensatz zu IPv4 wird nicht die Länge des Datagramms, sondern nur der Rest nach dem Header erfaßt. Zum Übertragen von 1 000 Byte Nutzdaten wird z. B. die IPv6-Payload-Länge 1 000 sein, und die IPv4-Datagramm-Länge 1020. Die Jumbo-Payload-Option bei IPv6 erlaubt es aber, die Länge eines Datagramms mit mehr als 16 Bit zu kodieren, d. h. längere als 64 KByte Datagramme zu Übertragen (siehe Abschnitt 1.2.2).

 

Das Feld »nächster Header« (1 Byte) spezifiziert den Typ des Headers nach dem IPv6-Header. Im Gegensatz zu IPv4 ist der Typ des nächsten Headers nicht immer TCP (Code 6) oder UDP (Code 17). Das IPv6 sieht die sogenannten Erweiterungs-Header (Extension Header) vor, die nur dann in das Feld »nächster Header« einbezogen werden, wenn sie gebraucht werden. Beispiele solcher Header sind der Routing-Header (Code 43), Fragment-Header (Code 44), Authentication-Header, etc..

 

Das Feld »Hop Limit« stellt eine Korrektur des TTL-Feldes (Time-to-Live) bei IPv4 dar. Ursprünglich sollte der Sender die Lebensdauer eines Paketes TTL in Sekunden bestimmen. Dies wurde aber nie richtig genutzt. Vielmehr wird ein TTL-Feld eines IPv4-Datagramms bei jedem Router (d. h. bei jedem Hop) um eins verkleinert, bis es Null wird. Dann wird das Datagramm annulliert, so daß Datagramme mit fehlerhaften EmpfängerAdressen nicht ewig über das Internet irren. Mit anderen Worten wurde TTL schon immer als einer Art »Hop Limit« genutzt, so daß die Namensänderung bei IPv6 zu mehr Klarheit beiträgt.

 

 

 

1.2 Optionale Erweiterungs-Header statt Optionen

Die heutigen Router sind bemüht, im Standardfall eine höhere Leistung aufzuweisen. Deshalb wird eine Art Scheduling bei den Routern ausgeführt, indem die Standard-Datagramme ohne Optionen bevorzugt bearbeitet werden. Auch wenn die Optionen für den Empfänger bestimmt sind, wird das Datagramm in den Routern aufgehalten. Dies hat andererseits die Programmierer von Internetanwendungen gezwungen, keine IP-Optionen zu nutzen und ihre Funktionalität über höhere Protokolle zu implementieren. Aus der Sicht der Protokollarchitektur bedeutete das einen zusätzlichen Overhead, der aber durch die schnellere Bearbeitung von Standard-Datagrammen in den Routern kompensiert wurde.

IPv6 löst dieses Problem durch optionale Erweiterungs-Header nach dem IPv6-Header mit folgenden Merkmalen:

• Nur einer der Header, der Hop-by-Hop-Header, wird (wenn überhaupt präsent) von jedem Router bearbeitet.
• Die restlichen Erweiterungs-Header werden nur von den Endknoten bearbeitet, so daß keine Verzögerung durch die gesonderte Behandlung in den Routern entsteht. Es ist allerdings zu vermerken, daß der Source-Routing-Mechanismus mit dem Routing-Header bestimmte Router als Endknoten betrachtet.
• Ersetzen des Fragmentierungsfeldes im IPv4-Header durch Fragment-Header und die Optionen durch den optionalen Erweiterungs-Header. Dadurch sind die Router nicht mehr verpflichtet, diese Felder zu bearbeiten, was eine weitere Entlastung bedeutet.

1.2.1 Aufbau der Erweiterungs-Header

Die Erweiterungs-Header können auch semantisch miteinander verbunden sein. Zum Beispiel kann eine Berechnung durch einen Header initiiert und durch die Berechnungen eines nachfolgenden Headers fortgesetzt werden. Deshalb ist die Reihenfolge der Erweiterungs-Header nach dem IPv6-Header wichtig und wird bis jetzt wie folgt festgelegt:

• Hop-by-Hop-Options-Header:

Nur dieser erste Header wird, falls vorhanden, von jedem Router behandelt. Bis jetzt wird nur die Jumbo-Payload-Option vorgeschlagen, die es erlaubt, die Länge eines Datagramms mit mehr als 16 Bit zu kodieren.

• Routing-Header:

Er wird für Source Routing in IPv6 verwendet.

• Fragment-Header:

Der Fragment-Header wird nicht von den Routern berücksichtigt und dient nur zur Übertragung von Fragmentierungsinformation zum Empfänger. Er unterstützt dadurch eine Fragmentierung der größeren Pakete nur durch den Sender. Der Sender soll demzufolge die kleinste MTU (Maximum Transmission Unit) auf der Route kennen, um die Größe des Fragments einzustellen.

• Authentication-Header (Authentifizierungsinformation für den Empfänger):

Wird zur Übertragung von fälschungssicherer Unterschrift zur Authentifizierung des Senders genutzt.

• Encrypted security payload (Verschlüsselungsinformation für den Empfänger):

Das ist immer der letzte der verketteten Header, der teilweise noch im Klartext erscheint. Alle nachfolgenden Daten werden entsprechend verschlüsselt.

• Destination-Options-Header (weitere Optionen für den Empfänger):

Vorgegeben werden nur die ersten zwei Felder dieses Headers: nächster Header und Länge des Headers. Alle anderen Felder sowie der Kontext werden von den Anwendungen bestimmt.

• Header der oberen Schicht (ICMP, UDP,TCP, etc.).

1.2.2 Jumbo-Payload-Option

Die ersten zwei Felder sind für die meisten Erweiterungs-Header typisch: nächster Header und Länge des Headers. Es folgen der Typ 194 und die Länge der Daten - 4 Byte. Das Feld »Jumbo-Payload Länge« muß die Länge des zu übertragenden Datagramm, d. h. einen Wert größer als 65 535 Byte, beinhalten (siehe auch [RFC 2147]).

1.2.3 Source Routing

Zur Zeit wird nur der Routing-Mechanismus mit dem Typ des Routing = 0 spezifiziert. Die spezifischen Routing Daten beinhalten ein Feld starke oder schwache Abbildung und eine Liste von (maximal 24) Router-Adressen, wobei die Adresse des nächsten Routers als Empfängeradresse in den IP-Header eingetragen wird (Abb. 1.6).

Dieses Routing-Konzept stellt eine wesentliche Leistungsverbesserung gegenüber dem IPv4-Source-Routing dar. Der Routing-Header wird nur dann von einem Router bearbeitet, wenn er seine eigene Adresse im Empfängeradressenfeld des IP-Headers erkennt. Er überprüft dann, ob weitere nachfolgende Routeradressen in der Liste vorhanden sind:

• Wenn keine weiteren Router eingetragen sind (d. h. das Feld »restliche Segmente« in der Abb. 1.5 ist gleich 0), handelt es sich um den Endknoten der Route, so daß mit der Bearbeitung der nächsten Erweiterungs-Header fortgefahren wird.

• Wenn weitere Router eingetragen sind, werden die nächste Routeradresse aus der Liste mit der Empfängeradresse im IP-Header ausgetauscht und das Datagramm weitergeleitet. Wenn das Bit 0 im Feld »starke oder schwache Abbildung« in der Abb. 1.6 den Wert 1 hat (d. h. eine starke Abbildung darstellt), muß diese Adresse eine Nachbaradresse sein.

Zum Beispiel soll ein IPv6-Datagramm vom »Start« zum »Ziel« über »Router 1«, »Router 2«, und »Router 3« geleitet werden. Abb. 1.6 zeigt die Struktur des Routing-Headers als Überbau eines IPv6-Pakets (hell getönte Felder). Nach Erreichen des ersten Routers (Abb. 1.6 zeigt den Zustand nach Erreichen des zweiten Routers) mit IP-Adresse »Router l « wird die Adresse des nächsten Routers mit IP-Adresse [1] mit der Empfängeradresse im IP-Header ausgetauscht: der alte Inhalt in den Feldern »IP-Adresse« [2] und »Empfängeradresse« wird mit neuem, fett markiertem Inhalt versehen. Das Feld »restliche Segmente« wird um 1 verkleinert. Das Feld »nächster Header« im IPv6-Header bestimmt den Typ 43 (Routing Header) und im Routing-Header den Typ 6 (TCP-Header). Diese Felder bleiben während der ganzen Übertragung vom Start zum Ziel unverändert.

Abb. 1.6: Struktur des Routing-Headers als Überbau eines IPv6-Pakets (hell getönte Felder). Nach Erreichen des zweiten Routers mit IP-Adresse [1] wird die Adresse des nächsten Routers mit IP-Adresse [2] als Empfängeradresse in den IP-Header eingetragen.

1.2.4 Fragmentierung

In IPv4 wird die Fragmentierung »automatisch« von den Routern durchgeführt. Dieses »automatische« Herangehen hat aber den Nachteil, daß jeder Router die Notwendigkeit der Fragmentierung bei jedem Datagramm überprüfen muß. Wenn notwendig, sollen dann die betroffenen Router die Fragmentierung und Defragmentierung, vielleicht auch mehrfach, auf der Route vornehmen. Da der Sender und der Empfänger auch mehrere Datagramme miteinander austauschen, wird diese Prozedur jedesmal wiederholt.

Beim IPv6-Konzept ist nur eine Ende-zu-Ende-Fragmentierung vorgesehen. Der Sender führt, falls notwendig, die Fragmentierung eines Datagramms durch und übermittelt die entsprechende Information an den Empfänger über den Fragment-Header. Der Fragment-Header wird nicht von den Routern berücksichtigt, was eine wesentliche Vereinfachung und Leistungsverbesserung gegenüber der IPv4 darstellt.

Der IPv6-Fragmentierungsalgorithmus ist einfach. Falls ein Segment auf der Route Pakete dieser Länge nicht durchlassen kann, wird das Paket annulliert und eine ICMP-Fehlermeldung »Packet Too Big« zum Sender mit der Information über die erforderliche Länge zurückgesendet. Der Sender führt dann die erforderliche Fragmentierung durch, trägt sie in den Fragment-Header ein und sendet erneut das Paket in Form von mehreren Datagrammen. Jedes Datagramm hat dann den gleichen IPv6-Header, gefolgt von dem Fragment-Header, der das Fragment beschreibt (Abb. 1.7). Für diesen Zweck wird ein 32-Bit-langer Identifikator erzeugt, der die zusammenhängenden Datagramme mit den Fragmenten eindeutig markiert. Jedes Fragment wird unabhängig geroutet.
 
 

Der Fragment-Header ist in Abb. 1.8 dargestellt. In IPv6 erfolgt die Fragmentierung in den Bereichen von über 576 Byte langen Paketen durch die Endknoten. Bei unterliegenden Netzen, die kleinere Pakete als 576 Byte erfordern, wie etwa ATM, sollte die erforderliche Fragmentierung auf der

Link-Schicht erfolgen. IPv6-Datagramme dürfen die 576 Byte Grenze nicht unterschreiten. Das Feld »Offset des Fragments« gibt den Offset der Daten in diesem Datagramm bezüglich des Anfangs der fragmentierten Nutzdaten in Byte an. Das letzte Bit M markiert (bei M=l) das letzte Fragment.

1.2.5 Path MTU Discovery

2. Sicherheitskonzepte des neuen Internet-Protokolls IPv6

Die Sicherheitsdienste beim IPv6 werden durch zwei getrennte Header gesichert:

• IP-Authentication-Header (AH) sichert Integrität und Authentizität, ohne Vertraulichkeit (siehe Abschnitt 2.2) der IP-Datagramme, ausgetauscht zwischen zwei oder mehreren Stationen und Routern. Eine Vertraulichkeit über Verschlüsselung wird hier nicht vorgesehen, damit man die Einschränkungen mancher Länder für Export (USA) oder Verwendung (z. B. Frankreich) von bestimmten Verschlüsselungsverfahren nicht verletzt. Der Router mit einer AH-Implementierung kann dabei einen Sicherheits-Gateway zu einer Sicherheitszone darstellen.

• IP-Encapsulating Security Payload (ESP) sichert Integrität, Authentizität und Vertraulichkeit der IP-Datagramme, die zwischen zwei oder mehreren Stationen und Routern ausgetauscht werden. Eine verschlüsselte Kommunikation zwischen zwei Gateways könnte zur Verbindung von zwei Sicherheitsinseln verwendet werden. Dies schließt aber die gleichzeitige Verwendung einer Station-zu-Station-Verschlüsselung nicht aus. Der Router mit einer ESP-Implementierung kann dabei einen Sicherheits-Gateway zu einer Sicherheitszone darstellen. Wenn in einer verschlüsselten Ende-zu-Ende-Kommunikation die Router die Verschlüsselung nicht unterstützen, kann man nur den Inhalt des Datagramms, z. B. die TCP/UDP-Pakete, verschlüsseln.

2.1 Sicherheitsassoziationen

• Authentifizierungsalgorithmus und sein Modus für den IP-Authentication-Header (AH)

• Schlüssel für den Authentifizierungsalgorithmus für den IP-Authentication-Header (AH)

• Verschlüsselungsalgorithmus, sein Modus und »Transform« für die IP-Encapsulating Security Payload (ESP). Ein »Transform« ist in diesem Fall die opake Datentabelle, die bei der Verschlüsselung genutzt wird.

• Schlüssel für den Verschlüsselungsalgorithmus für die IP-Encapsulating Security Payload (ESP)

• Präsenz einer kryptographischen Synchronisation oder eines Initialisierungsvektors (IV) für die IP-Encapsulating Security Payload (ESP)

• Authentifizierungsalgorithmus und sein Modus für den ESP-Transform (falls vorhanden)

• Authentifizierungsschlüssel für den ESP-Transform (falls vorhanden)

• Lebensdauer der Schlüssel

• Lebensdauer der Sicherheitsassoziation

• Senderadresse der Sicherheitsassoziation

• Sensibilitätsebene, z. B. »streng geheim«, »geheim« oder »unbestimmt«, um mehrere Sicherheitsebenen zu erlauben.

Der Empfänger identifiziert die Sicherheitsassoziation durch den SPI und die Empfängeradresse. Auf dieser Basis werden alle ankommenden Pakete ausgewertet und verarbeitet. Mehrere Sender einer Multicast-Gruppe können eine einzige Sicherheitsassoziation zum Empfänger nutzen. Dann kann der Empfänger zwar nicht eindeutig den Sender identifizieren, er weiß nur, daß er die Sicherheitsassoziation der Multicastgruppe kennt. Der Empfänger kann weiterhin den Sender aus der Multicastgruppe nicht authentifizieren, wenn symmetrische Verschlüsselungsverfahren genutzt werden. Eine Authentifizierung durch die Sicherheitsassoziation kann dann erfolgen, wenn jeder der Sender seine eigene Sicherheitsassoziation startet und dabei asymmetrische Verschlüsselungsverfahren nutzt.

Eine Sicherheitsassoziation ist immer unidirektional. Eine Sitzung zwischen zwei Stationen muß dementsprechend zwei Sicherheitsassoziationen verwalten - für jede Richtung eine. Sie bemerken, daß ähnlich wie die asymmetrischen Verschlüsselungssysteme, der Empfänger der Initiator einer Sicherheitsassoziation ist, d. h. er wählt die SPI auf der Basis der Empfänger-Unicastadresse oder seiner Multicastgruppe.

2.2 IP-Authentication-Header

Der Authentication-Header befindet sich normalerweise bei IPv6-Datagrammen nach dem Fragmentation-Header und vor den ESP und dem Header der Transportebene (siehe Abschnitt 1.2.1). Bei den IPv4-Datagrammen wird der Authentication-Header gleich nach dem IPv4-Header plaziert.

  

Das Format des Authentication-Headers ist in der Abb. 2.1 gegeben. Das Feld »nächster Header« bestimmt den Typ des nächsten Header nach AH, entsprechend der von IANA zugewiesenen Nummern [RFC 1700].

Die Länge des AH wird als Anzahl von 32-Bit-Worten angegeben.

Der Security Parameter Index (SPI) stellt einen Identifikator der Sicherheitsassoziation dieses Datagramms dar.

Das Feld »Authentication Data« wird durch die Authentification Transform berechnet und wird hier allgemein Signatur genannt. Es wird entweder durch einen Message-Digest-Algorithmus (z. B. MD5) oder andere Hash-Algorithmen berechnet.

Bei der Verschlüsselung der Signatur können symmetrische und asymmetrische Verschlüsselungsverfahren verwendet werden. Dabei ist bei IPv6 keine direkte Nutzung von Schlüsselservern (KDC) vorgesehen. Dieses ergibt folgende zwei Szenarien:

• Der Sender einer Nachricht nutzt seinen geheimen Schlüssel, um die Signatur zu verschlüsseln
• Der Empfänger nutzt den entsprechenden öffentlichen Schlüssel, um die Signatur zu entschlüsseln und danach zu überprüfen. Dadurch wird die Integrität der Daten, die Authentizität der Nachricht nachgewiesen.
• Voraussetzung dafür ist es, daß der öffentliche Schlüssel durch IPRA zertifiziert ist. Andererseits könnte ein Eindringling dem Empfänger einen öffentlichen Schlüssel im Namen des regelmäßigen Senders zur Verfügung stellen (Spoofing).

Der Sender berechnet die Signatur über das Datagramm, so wie es bei dem Empfänger erscheinen soll. Die Felder, die während der Übertragung verändert oder zusätzlich angehängt werden, werden bei der Berechnung durch Nullen ersetzt.

Ein Problem bei der Nutzung des Authentication-Headers ist die Behandlung von ICMP-Fehlermeldungen, die als Inhalt die originale Nachricht, aber nicht unbedingt die ganze Nachricht einschließen. Im zweiten Fall wäre eine Authentifizierungsüberprüfung nicht möglich. Der Empfänger einer solchen ICMP-Nachricht kann sie entweder verarbeiten, d. h. ihr vertrauen mit den möglichen Sicherheitskonsequenzen oder ihr nicht vertrauen und demzufolge die ICMP-Nachricht nicht berücksichtigen. Dieses Problem hat vorläufig keine allgemeine Lösung.

Ein anderes Sicherheitsproblem stellt das Source-Routing dar. IP-Spoofing ist hier ohne weiteres möglich. Eine sehr aufwendige Lösung scheint hier, jedes über Source-Routing empfangene Paket über separate Authentication Headers zu überprüfen.

2.3 IP-Encapsulating Security Payload

Im Tunnel-Modus bildet das originale Datagramm den verschlüsselten Teil von ESP, wobei der ganze ESP dann über ein Datagramm mit unverschlüsseltem Header übertragen wird.

Im Transport-Modus wird ein ESP-Header direkt nach dem IP-SchichtHeader (d. h. vor dem TCP-, UDP- oder ICMP-Header) plaziert (Abb. 2.2). Die IP-Header oder die Optionen werden demzufolge nicht verschlüsselt.

Die Verschlüsselung erfolgt auf der Basis eines Schlüssels, der auf der Basis eines Key-Management-Mechanismus (oder KDC) vor der Verschlüsselung vereinbart werden soll. Falls der Empfänger über keinen Schlüssel für diese Sicherheitssitzung verfügt, wird die verschlüsselte ESP annulliert und der Fehler in einem Log gespeichert. Der Empfänger antwortet nicht mit einer Fehlermeldung, um eine Dienstblockade seitens eines Eindringlings zu umgehen.

Wenn zwei Stationen ESP direkt implementieren und sie zueinander Link-lokal sind (es wird kein Router benötigt), wird der Transportmodus empfohlen, der einen wesentlich kleineren Aufwand für die Verschlüsselung und Entschlüsselung benötigt.

Am ESP kann weiterhin ein IP-Pseudo-Header angehängt werden, der im Klartext übertragen und von den Routern wie ein normaler IP-Header interpretiert wird. ESP kann zwischen Stationen, einer Station und einem Router (Sicherheitsrouter) oder zwischen zwei Routern betrieben werden. Die Nutzung von ESP ist immer mit einer Leistungsminderung verbunden, die von der konkreten Implementierung, von dem verwendeten Verschlüsselungsverfahren und von der Länge des Schlüssels abhängt. ESP überläßt die Wahl des Verschlüsselungssystems den Anwendern. Alle Systeme im Internet müssen allerdings DES mit CBC (Cipher Block Chaining) unterstützen.
 

Das Feld »Security Parameter Index (SPI)« in der Abb. 2.3 identifiziert eindeutig die Sicherheitsassoziation. Der konkrete Wert von SPI wird zufällig bestimmt, wobei die Werte 00000001₁₆ bis 000000FF₁₆ für IANA reserviert sind.

Das Feld  »Opaque Transform Data« hängt vom konkreten Verschlüsselungsverfahren ab. Das Format des Feldes für das obligatorische ESP DES-CBC (Data Encryption Standard Cipher Block Chaining) [RFC 1829] ist in der Abb. 2.4 gegeben.

Das Feld »VI« beinhaltet dabei die Anfangsdaten für die XOR-Operation mit dem ersten über DES verschlüsselten Datenblock.

Das Feld »Payload Data« sind die zu verschlüsselnden Daten, deren Typ im Feld »Payload Type« spezifiziert wird. Wenn z. B. der ESP-Tunnel-Mode eingesetzt wird, beinhaltet Payload Data das ganze IP-Datagramm und das Feld »Payload Type« hat den Wert 4 (IP-in-IP-encapsulation).

Das Feld »Padding« beinhaltet Füllbits für die Payload, dahinter wird die Länge des Paddings definiert..

Die kombinierte Verwendung von ESP und AH ist zulässig und für die Fälle erforderlich, bei denen Integrität, Authentizität, Vertraulichkeit und Nichtwiderrufbarkeit der IP-Datagramme gesichert werden sollen. In diesem Fall wird zuerst ein Authentication Header eingefügt, dessen Platz festlegt, welcher Teil des IP-Datagramms authentifiziert wird. Erst dann wird das Datagramm über ESP verschlüsselt.