Das Encapsulating Security Payload (ESP)-Modul bietet Vertraulichkeit für Inhalte, die durch ESP eingekapselt sind. ESP stellt auch Services bereit, die vom AH angeboten werden. ESP stellt seinen Schutz jedoch nur dem Teil des Datagramms zur Verfügung, den ESP einkapselt. ESP bietet optionale Authentifizierungsservices, um die Integrität des geschützten Pakets sicherzustellen. Da ESP eine verschlüsselungskonforme Technologie verwendet, könnte ein System zur ESP-Bereitstellung den Gesetzen zu Exportbeschränkungen unterliegen.
ESP kapselt seine Daten ein, so dass ESP nur die Daten schützt, die seinem Anfang im Datagramm folgen, wie in der folgenden Abbildung gezeigt.
In einem TCP-Paket kapselt ESP nur den TCP-Header und dessen Daten ein. Handelt es sich bei dem Paket um ein IP-in-IP-Datagramm, schützt ESP das innere IP-Datagramm. Die für einen Socket geltende Richtlinie ermöglicht eine Selbst-Einkapselung, so dass ESP gegebenenfalls auch IP-Optionen einkapseln kann.
Bei aktivierter Selbst-Einkapselung wird eine Kopie des IP-Headers erstellt, um ein IP-in-IP-Datagramm zu konstruieren. Ist die Selbst-Einkapselung nicht auf ein TCP-Socket gesetzt, wird das Datagramm in dem folgenden Format gesendet:
[ IP(a -> b) options + TCP + data ] |
Ist die Selbst-Einkapselung auf ein TCP-Socket gesetzt, wird das Datagramm in dem folgenden Format gesendet:
[ IP(a -> b) + ESP [ IP(a -> b) options + TCP + data ] ] |
Weitere Informationen finden Sie unter Transport- und Tunnelmodi in IPsec.
In der folgenden Tabelle werden AH und ESP hinsichtlich des gebotenen Schutzes miteinander verglichen.
Tabelle 19–2 Von AH und ESP in IPsec gebotener Schutz