Rechnernetze

Encapsulating Security Payload

Encapsulating Security Payload (ESP) bietet

verschiedene Sicherheitsdienste

	Verschlüsselung
	Authentisierung,
	in IPv4 und IPv6
	Transportmodus
	Tunnelmodus
	im Prinzip universell einsetzbar

ESP-Header

	hinter IP-Header
	vor Header der oberen Transportschicht

ESP bietet die folgenden Sicherheitsdienste an:

Vertraulichkeit,

Datenquellenauthentisierung,

Integrität bei verbindungsloser Kommunikation,

Antireplay-Dienst,

beschränkte Verkehrsflussvertraulichkeit.

Dienste hängen teilweise voneinander ab

Standard schreibt vor

	Vertraulichkeit oder
	Authentisierung
	oder beides!

Paketformat der Encapsulating Security Payload

	ESP-Pakete
	Wert 50 im Nextheader-Feld des vorhergehenden Pakets
	ESP-Paket hat folgenden Aufbau

Security Parameters Index (SPI)

	32 Bit-Wert
	in Kombination mit Zieladresse und Protokoll ESP eindeutig SA identifiziert
	Gewisse Werte (1..255) nicht, nur lokal (0) verwenden
	Wert des SPI von Zielrechner beim Aufbau der SA festgelegt
	Wert kommt in jedem ESP-Paket vor

Sequenznummer

	32 Bit-Wert
	Antireplay-Wert
	Sender muss diesen Wert einfügen
	beginnend bei 1 inkrementieren
	der Empfänger kann auswerten, braucht nicht
	Wert darf niemals über Höchstwert 2³²-1 inkrementiert werden
	Wert kommt in jedem ESP-Paket vor.

Payload-Data

Daten, Typ im Nextheader-Feld beschrieben

Initialisierungsvektor (Synchronisationsdaten) explizit angegeben

z.B. bei DES-CBC

RFC des Verschlüsselungsverfahren

wie Synchronisationsdaten aus Payload-Datenfeld/ESP-Header

Wert kommt in jedem ESP-Paket vor

Paddingdaten

	keine Bedeutung für übertragene Payload-Daten
	füllen Paket auf gewünscht Länge auf
	bei Blockchiffren und ähnlichen Verschlüsselungsverfahren verwendet
	können wahre Länge eines Datenfeldes verschleiern
	Wert optional (Länge null)
	Paddingfelder mit explizit oder implizit definierten Werten (1,2, ...) versehen

Pad-Length

	Anzahl der Padding-Oktette.
	0-255
	kommt in jedem ESP-Paket vor

Next Header

Typ der Payload-Daten

	z.B. Transportprotokoll oder
	Erweiterungsheader in IPv6

kommt in jedem ESP-Header vor

Authentication Data

Authentisierung des ESP-Feldes

ohne Authentisierungsdaten

Länge abhängig vom Authentisierungsalgorithmus

optional

Anordnung des ESP-Headers

Transportmodus

ESP-Header nach IP-Header

vor entsprechenden Daten der oberen Schichten

	z.B. TCP oder
	ICMP

vollständiges IP-Paket verschlüsseln

ESP-Header vor innerem IP-Header anordnen.

Beispiel: Einkapselung eines TCP-Pakets.

In IPv6

	Destination-Options-Header an verschiedenen Stellen stehen
	um mitzuverschlüsseln: hinter ESP-Header stellen
	mehrere Destination-Options-Header möglich
	Destination-Options-Header an verschiedenen Stellen

Tunnelmodus

innere Header enthält Zieladresse

äußerer IP-Header kann andere Adresse enthalten

z.B. eines Security-Gateways

für typische IPv4- und IPv6-Datagramme

folgende Anordnung des ESP-Headers im Tunnelmodus

im Tunnelmodus

gesamter innerer IP-Header verschlüsseln

einschließlich Zieladresse

auf diese Weise auch Verkehrsflussvertraulichkeit unterstützen

Funktionen beim Senden eines ESP-Pakets

ESP-Implementierung

mindestens DES-CBC zur Verschlüsselung anbieten;

Initialisierungsvektor im Payloadfeld ablegen.

NULL-Algorithmus (keine Verschlüsselung)

weitere Verschlüsselungsverfahren möglich

insbesondere zukünftig erweiterbar

sämtliche Parameter für Entschlüsselung in einem Block abgelegt

	als expliziter Wert im Payloadfeld oder
	aus ESP-Header ableitbar

Punkt-zu-Punkt-Kommunikation authentifiziert

schlüsselbasierte Message Authentication Codes

DES

Hashfunktionen wie MD5 oder SHA-1

müssen implementiert sein

Null-Authentisierung vorgeschrieben.

Wird ESP eingesetzt,

	verschlüsselt oder
	authentisiert oder
	beides

ausgehendes Paket

entsprechend Eintrag in Security Policy Database als ESP-Paket erkannt

zunächst entsprechendes Paket im Klartext konstruiert

Transportmodus

höheres Protokoll

Tunnelmodus

gesamtes IP-Datagramm einschließlich IP-Header

angehängt werden

	Padding-Bytes,
	Pad-Länge und
	Next-Header-Feld

mit gewähltem Algorithmus verschlüsseln (evtl. null)

Explizite oder implizite Verschlüsselungsparameter in Payloadfeld

Initialisierungsvektor beim DES-CBC

an festgelegter Stelle eingefügt oder

aus ESP-Header nach festgelegtem Verfahren

Sequenzzähler inkrementiert und in entsprechendes Feld übernommen

Überlauf des Zählers führt zu Alarm und Löschung der SA

Verlangt SA Authentisierung

Sender berechnet Integrity Check Value (ICV) aus Paket

ohne Authentisierungsdaten

fügt ICV in Feld für Authentisierungsdaten

Pakete vom Sender ggbfls. bei IPv6 fragmentiert

vor Entschlüsselung wieder reassembliert

Funktionen beim Empfangen eines ESP-Pakets

eingehendes Paket

aufgrund Eintrag in Security Policy Database als ESP-Paket erkannt

Sequenznummernfeld überprüfen (wenn SA vorschreibt)

Da Pakete in beliebiger Reihenfolge eintreffen können

	Fensterverfahren
	32 bis 64 Sequenznummern
	auf Duplikate überprüft.

bei dupliziertem Paket, in Logdatei protokollieren.

Authentisierung ( wenn SA vorschreibt)

ESP-Paket mit vereinbartem Algorithmus prüfen

ohne Authentisierungsdaten

gegen Authentisierungsdaten abgleichen

Fehler in Logdatei protokollieren unter Angabe von

	SPI,
	Empfangszeit,
	Quell- und Zieladresse und
	Sequenznummer .

Dechiffrierung ( wenn SA vorschreibt)

ESP-Paket ohne Authentisierungsdaten mit vereinbartem Algorithmus entschlüsselt

Aus Klartext Paddingdaten extrahiert und überprüft (1,2,.. bei impliziten Daten)

ursprüngliches Paket einschließlich IP-Header restauriert weiter an IP geleitetet

auch im Tunnelmodus

Datenteil an Transportprotokoll

im Tunnelmodus als neues IP-Paket weiterleiten

zu protokollierende Fehler auditable events,

in der Regel in Logdatei protokolliert

nicht verlangt wird

	jedes System protokolliert Fehler
	wenn, müssen Mechanismen zum Protokollieren von AH-Fehlern vorgesehen werden
	Administrator muss dieses ein- bzw. ausschalten
	bei Fehlern ist Empfänger nicht verpflichtet, an Absender melden
	Gefahr von Denial-of-Service-Angriffen verhindern