URL dieser Newsmeldung:

In dieser Folge wird ein Beispiel zum Einsatz der IPsec-Protokolle dargestellt. Nachdem mit IKEv2 (wie in About Security #94 beschrieben) eine Sicherheitsassoziation ausgehandelt wurde, muss ggf. die Security Policy Database (SPD) angepasst werden. Dies ist (wie in About Security #92 erwähnt) nicht die Aufgabe von IKE, sondern eigener Protokolle. IKE-Implementierungen können es jedoch trotzdem übernehmen. Die in den Traffic Selectors übertragenen Informationen können dann zur Aktualisierung der SPD verwendet werden, ansonsten erlauben sie die Kontrolle der Übereinstimmung der SPD-Einträge. Im Folgenden wird davon ausgegangen, dass die in der SPD gespeicherten Security Policies korrekt sind. Ob mit oder ohne Anpassung ist dabei unerheblich. Damit können alle in Zukunft übertragenen Pakete bei Bedarf durch IPsec-Protokolle geschützt werden.

Da zwei Gateways miteinander verbunden sind, wird IPsec im Tunnelmodus betrieben. Die Kommunikationspartner prüfen bei jedem ein- und ausgehenden Paket anhand von Quell- und Zieladresse und Protokoll, wie mit dem Paket zu verfahren ist. Enthält der zuständige SPD-Eintrag die Anweisung 'PROTECT' wird das Paket entsprechend der zugehörigen SA behandelt.

ESP im Tunnelmodus
Zuerst soll der Einsatz des Encapsulating Security Payload (ESP) Protokolls im Tunnelmodus betrachtet werden: Die angenommene SA legt dann fest, dass für die betreffenden Pakete das IPsec-Protokoll ESP verwendet werden soll. Als Krypto-Algorithmen soll AES-128 für die Verschlüsselung und SHA1 für die Authentifizierung verwendet werden. Die ebenfalls in der SA gespeicherten Schlüssel dafür wurden aus den mit IKEv2 ausgetauschten öffentlichen Diffie-Hellman- und Zufallswerten berechnet. Damit ergeben sich für die unter dieser SA zu übertragenen Pakete folgende Anpassungen:

Ursprüngliches IPv4-Paket:

Version (4 Bit)	Headerlänge (4 Bit)	Servicetype (8 Bit)	Gesamtlänge in Bytes (16 Bit)
Identifikation (16 Bit)			Flags (3 Bit)	Fragment-Offset (13 Bit)
Time to Live (8 Bit)		Protokoll (8 Bit)	Header-Prüfsumme (16 Bit)
Quell-IP-Adresse (32 Bit)
Ziel-IP-Adresse (32 Bit)
IP-Optionen und Füllzeichen (insgesamt 32 Bit)
Daten: TCP-Header + TCP-Payload

IPv4-Paket mit ESP im Tunnelmodus:

Version (4 Bit)	Headerlänge (4 Bit)	Servicetype (8 Bit)	Gesamtlänge in Bytes (16 Bit)
Identifikation (16 Bit)			Flags (3 Bit)	Fragment-Offset (13 Bit)
Time to Live (8 Bit)		Next Header = ESP (*) (8 Bit)	Header-Prüfsumme (16 Bit)
Quell-IP-Adresse (32 Bit)
Ziel-IP-Adresse (32 Bit)
IP-Optionen und Füllzeichen (insgesamt 32 Bit)
(*) Security Parameter Index (SPI) (32 Bit) Sequenznummer (32 Bit)   (**) ursprünglicher IP-Header, TCP-Header und -Payload     Padding                                 Padding Length (8 Bit) Next Header = IP (**) (8 Bit) Integrity Check Value (ICV) mit SHA1 über die gelb markierten Feldern berechnete Authentifizierungsdaten

Im Protokollfeld des neuen IP-Headers wird als 'Next Header' ESP eingetragen und damit auf das transportierte ESP-Paket (grau markiert) verwiesen (siehe die (*)-Markierungen). Der ursprüngliche IP-Header sowie TCP-Header und -Payload werden mit AES-128 verschlüsselt in den Datenbereich des ESP-Pakets kopiert. Im 'Next Header'-Feld des ESP-Headers wird IP eingetragen und damit auf das in ESP transportierte IP-Paket verwiesen (siehe die (**)-Markierungen).

Schutzmaßnahmen: Der ursprüngliche IP-Header, TCP-Header und -Payload, Padding, 'Padding Length'- und 'Next Header'-Feld werden mit AES-128 verschlüsselt (blau markiert), die verschlüsselten Daten sowie das SPI- und Sequenznummer-Feld danach durch mit SHA1 berechnete Authentifizierungsdaten vor unerkannten Änderungen geschützt (gelb markiert).

AH im Tunnelmodus
Statt ESP soll nur AH mit SHA1 als Authentifizierungsalgorithmus verwendet werden, da eine Verschlüsselung nicht notwendig ist:

IPv4-Paket mit AH im Tunnelmodus

Version (4 Bit)	Headerlänge (4 Bit)	Servicetype (8 Bit)	Gesamtlänge in Bytes (16 Bit)
Identifikation (16 Bit)			Flags (3 Bit)	Fragment-Offset (13 Bit)
Time to Live (8 Bit)		Protokoll = AH (8 Bit)	Header-Prüfsumme (16 Bit)
Quell-IP-Adresse (32 Bit)
Ziel-IP-Adresse (32 Bit)
IP-Optionen und Füllzeichen (insgesamt 32 Bit)
Next Header = IP (8 Bit) Payload-Length (8 Bit) Reserviert (16 Bit) Security Parameter Index (SPI) (32 Bit) Sequenznummer (32 Bit) Integrity Check Value (ICV): mit SHA1 über alle gelb markierten Feldern berechnete Authentifizierungsdaten Version (4 Bit) Headerlänge (4 Bit) Servicetype (8 Bit) Gesamtlänge in Bytes (16 Bit) Identifikation (16 Bit) Flags (3 Bit) Fragment-Offset (13 Bit) Time to Live (8 Bit) Protokoll = TCP (8 Bit) Header-Prüfsumme (16 Bit) Quell-IP-Adresse (32 Bit) Ziel-IP-Adresse (32 Bit) IP-Optionen und Füllzeichen (insgesamt 32 Bit) Daten: TCP-Header + TCP-Payload

Im Protokollfeld des neuen IP-Headers wird als Protokoll AH eingetragen und damit auf das transportierte AH-Paket (grau markiert) verwiesen. Der ursprüngliche IP-Header sowie TCP-Header und -Payload werden unverändert in den Datenbereich des AH-Pakets kopiert. Im 'Next Header'-Feld des AH-Headers wird IP eingetragen und damit auf das im AH-Paket transportierte IP-Paket verwiesen.

Schutzmaßnahmen: Alle außer den weiß markierten Feldern werden durch mit SHA1 berechnete Authentifizierungsdaten vor unerkannten Änderungen geschützt (gelb markiert).

Transport- statt Tunnelmodus
Wird IPsec statt im Tunnel- im Transportmodus betrieben, z.B. weil es sich um ein Host-to-Host-VPN handelt, entfallen die ursprünglichen IP-Header im ESP- bzw. AH-Paket und in den 'Next Header'-Feldern wird statt auf den IP- auf den TCP-Header verwiesen.

In der nächsten Folge wird ein weiteres VPN-Protokoll vorgestellt: PPTP, das 'Point-to-Point Tunneling Protocol'.

Carsten Eilers