1. Introduction (Einführung)

1. Introduction

Dieses Dokument setzt voraus, dass der Leser mit den Begriffen und Konzepten vertraut ist, die in der "Security Architecture for the Internet Protocol" [Ken-Arch] beschrieben sind, im Folgenden als Sicherheitsarchitektur-Dokument bezeichnet. Insbesondere sollte der Leser mit den Definitionen der von der Encapsulating Security Payload (ESP) und dem IP Authentication Header (AH) angebotenen Sicherheitsdienste, dem Konzept der Security Associations, den Möglichkeiten, wie ESP in Verbindung mit AH verwendet werden kann, und den verschiedenen für ESP und AH verfügbaren Schlüsselverwaltungsoptionen vertraut sein.

Die Schlüsselwörter MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY und OPTIONAL sind, wenn sie in diesem Dokument erscheinen, so zu interpretieren, wie in RFC 2119 [Bra97] beschrieben.

Der Encapsulating Security Payload (ESP) Header ist so konzipiert, dass er eine Mischung von Sicherheitsdiensten in IPv4 und IPv6 [DH98] bereitstellt. ESP kann allein, in Kombination mit AH [Ken-AH] oder in verschachtelter Form angewendet werden (siehe Sicherheitsarchitektur-Dokument [Ken-Arch]). Sicherheitsdienste können zwischen einem Paar kommunizierender Hosts, zwischen einem Paar kommunizierender Sicherheitsgateways oder zwischen einem Sicherheitsgateway und einem Host bereitgestellt werden. Weitere Einzelheiten zur Verwendung von ESP und AH in verschiedenen Netzwerkumgebungen finden Sie im Sicherheitsarchitektur-Dokument [Ken-Arch].

Der ESP-Header wird nach dem IP-Header und vor dem Header des nächsten Layer-Protokolls (Transportmodus) oder vor einem gekapselten IP-Header (Tunnelmodus) eingefügt. Diese Modi werden unten ausführlicher beschrieben.

ESP kann verwendet werden, um Vertraulichkeit, Datenursprungsauthentifizierung, verbindungslose Integrität, einen Anti-Replay-Dienst (eine Form partieller Sequenzintegrität) und (begrenzte) Verkehrsfluss-Vertraulichkeit bereitzustellen. Der Satz der bereitgestellten Dienste hängt von den zum Zeitpunkt der Einrichtung der Security Association (SA) ausgewählten Optionen und vom Standort der Implementierung in einer Netzwerktopologie ab.

Die Verwendung von nur Verschlüsselung für Vertraulichkeit ist durch ESP erlaubt. Es sollte jedoch beachtet werden, dass dies im Allgemeinen nur Schutz gegen passive Angreifer bietet. Die Verwendung von Verschlüsselung ohne einen starken Integritätsmechanismus darüber (entweder in ESP oder separat über AH) kann den Vertraulichkeitsdienst gegen einige Formen aktiver Angriffe unsicher machen [Bel96, Kra01]. Darüber hinaus schützt ein zugrunde liegender Integritätsdienst wie AH, der vor der Verschlüsselung angewendet wird, die nur verschlüsselte Vertraulichkeit nicht notwendigerweise gegen aktive Angreifer [Kra01]. ESP erlaubt nur verschlüsselte SAs, weil dies erheblich bessere Leistung bieten und dennoch angemessene Sicherheit gewährleisten kann, z.B. wenn eine höherschichtige Authentifizierungs-/Integritätsschutz unabhängig angeboten wird. Dieser Standard verlangt jedoch nicht, dass ESP-Implementierungen einen nur verschlüsselten Dienst anbieten.

Datenursprungsauthentifizierung und verbindungslose Integrität sind gemeinsame Dienste, im Folgenden zusammen als "integrity" (Integrität) bezeichnet. (Dieser Begriff wird verwendet, weil die pro Paket durchgeführte Berechnung direkt verbindungslose Integrität bereitstellt; Datenursprungsauthentifizierung wird indirekt als Ergebnis der Bindung des zur Überprüfung der Integrität verwendeten Schlüssels an die Identität des IPsec-Peers bereitgestellt. Typischerweise wird diese Bindung durch die Verwendung eines gemeinsam genutzten symmetrischen Schlüssels bewirkt.) Nur Integrität ESP MUSS als Dienstauswahlsoption angeboten werden, z.B. muss es in SA-Verwaltungsprotokollen verhandelbar sein und MUSS über Verwaltungsschnittstellen konfigurierbar sein. Nur Integrität ESP ist in vielen Kontexten eine attraktive Alternative zu AH, z.B. weil es in vielen Implementierungen schneller zu verarbeiten und besser für Pipeline-Verarbeitung geeignet ist.

Obwohl Vertraulichkeit und Integrität unabhängig angeboten werden können, wird ESP typischerweise beide Dienste einsetzen, d.h. Pakete werden hinsichtlich Vertraulichkeit und Integrität geschützt. Daher gibt es drei mögliche ESP-Sicherheitsdienstkombinationen, die diese Dienste betreffen:

• confidentiality-only (nur Vertraulichkeit) (KANN unterstützt werden)
• integrity only (nur Integrität) (MUSS unterstützt werden)
• confidentiality and integrity (Vertraulichkeit und Integrität) (MUSS unterstützt werden)

Der Anti-Replay-Dienst kann für eine SA nur ausgewählt werden, wenn der Integritätsdienst für diese SA ausgewählt ist. Die Auswahl dieses Dienstes liegt ausschließlich im Ermessen des Empfängers und muss daher nicht ausgehandelt werden. Um jedoch die erweiterte Sequenznummernfunktion auf interoperable Weise nutzen zu können, verlangt ESP von SA-Verwaltungsprotokollen, dass sie diese Funktion aushandeln können (siehe Abschnitt 2.2.1 unten).

Der Verkehrsfluss-Vertraulichkeitsdienst (TFC) ist im Allgemeinen nur dann effektiv, wenn ESP auf eine Weise eingesetzt wird, die die ultimativen Quell- und Zieladressen der Kommunikationspartner verbirgt, z.B. im Tunnelmodus zwischen Sicherheitsgateways, und nur wenn ausreichend Verkehr zwischen IPsec-Peers fließt (entweder natürlich oder als Ergebnis der Erzeugung von maskierendem Verkehr), um die Merkmale spezifischer individueller Teilnehmer-Verkehrsflüsse zu verbergen. (ESP kann als Teil eines höherschichtigen TFC-Systems eingesetzt werden, z.B. Onion Routing [Syverson], aber solche Systeme liegen außerhalb des Geltungsbereichs dieses Standards.) Neue TFC-Funktionen, die in ESP vorhanden sind, erleichtern die effiziente Erzeugung und Verwerfung von Dummy-Verkehr und besseres Padding von echtem Verkehr auf rückwärtskompatible Weise.

Abschnitt 7 bietet eine kurze Übersicht über die Unterschiede zwischen diesem Dokument und RFC 2406.