Security Associations

	Sicherheitsverbindung (security association, auch Sicherheitsassoziation, SA)  RFC 2401  beschreibt Umfang und Eigenschaften der gesicherten Datenübertragung Assoziation: ISO/OSI-Basisferenzmodell synonym für Verbindung  Eine Sicherheitsverbindung  Simplexverbindung für einen Dienst  Authentisierung (durch AH) oder  Verschlüsselung (durch ESP),  Parameter Sicherheitsparameterindex (Security Parameter Index, SPI),  IP-Zieladresse (IP Destination Address), Sicherheitsdienstkennzeichnung (Security protocol identifier (AH oder ESP)).
	mehrere Sicherheitsverbindungen aufzubauen mehrere Sicherheitsdienste (AH und ESP)  Duplexverbindungen
	Zieladresse  Unicastadressen oder  Multicastadressen  RFC 2401 nur Unicastadressen
	Sicherheitsverbindung zwischen zwei Hosts  Sicherheitsverbindungen im Transportmodus  auch Transitsystem als endgültiger Empfänger von Datagrammen  z.B. ICMP-Nachrichten  Sicherheitsheader in IPv4  stehen die direkt zwischen  IPv4-Header (mit Optionen) und  Header der Anwendungsschicht
	Zwischen Transitsystemen und Endsystemen  Sicherheitsverbindungen im Tunnelmodus  Im Tunnelmodus  äußerer IP-Header und  innerer IP-Header  dazwischen Sicherheitsheader  äußerer Header adressiert Ende des Tunnels innerer Header enthält eigentliche Zieladresse
	Kombination von Sicherheitsverbindungen technisch durch Verschachtelung der jeweiligen Sicherheitsdienste  SA-Bündel (SA bundle) Kombination von Sicherheitsverbindungen  2 prinzipielle Konzepte: Transport Adjacency   Verwendungen von zwei Sicherheitsverbindungen in einem Datagramm nur jeweils eine AH- und eine ESP-Sicherheitsverbindungen sinnvoll.  Datagramm läuft beim gleichen Empfänger auf  nur eine IP-Zieladresse  Anfangs- und Endpunkte gleich Reihenfolge der SAs  IP-AH-ESP empfohlen Authentisierung auf Teilen des IP-Headers sowie auf ESP

iterierte getunnelte Verbindung (iterated tunneling)  mehrere Datagramme enthalten gegebenenfalls ganze Datagramme  können mehrere Zieladressen enthalten mehrere Kombinationen denkbar

1. Beide Endpunkte aller Sicherheitsverbindungen sind gleich.
   
   
2. Ein Endpunkt aller Sicherheitsverbindungen ist gleich, die anderen verschieden.
   
3. Alle Endpunkt der Sicherheitsverbindungen sind verschieden.
   
   
   

	Die Reihenfolge der SAs ist hier beliebig,
	abhängig von jeweiligen Sicherheitsanforderungen.

	Kombinationen von Sicherheitsverbindungen
	Beispiele zwischen Routern verschlüsselte Tunnelverbindungen aufbauen zu verschiedenen Endsystemen in den jeweiligen lokalen Netzen  ungeschützte Verbindungen oder auch  authentisierte Verbindungen betreiben.  Verwendung verschachtelter Sicherheitsverbindungen  jeder Grad an Sicherheit erreichbar Im Prinzip kann beispielsweise die Verschlüsselungsstärke auch durch die Verwendung verschachtelter ESP-Header verbessert werden (Produktchiffren), wenngleich dieses Verfahren u.U. nicht die erhoffte zusätzliche Sicherheit bringt (s. a. Meet-in-the-Middle Angriff).
	vier Basiskonfigurationen von SAs definiert müssen unterstützt werden weitere können optional hinzugefügt werden

	Schlüsselverteilung und SA-Management manuell oder automatisiert manuelles Vorgehen nachteilig Antireplaydienst nicht bei manuellem SA-Management  Zähler nicht zu synchronisieren
	Manuelles Management  nur in kleinen, lokal beschränkten Netzen  oder wenn manuell Kommunikation zwischen zwei oder wenigen Security Gateways mit Tunneling aufgebaut werden soll. aus Sicherheits- und Effizienzgründen automatisches Management sinnvoller.
	Automatisches SA- und Schlüsselmanagement  benötigt, wenn Antireplaydienst verwendet werden soll  wenn Anwender spontan neue SAs kreieren und benutzen wollen IPsec führt Standard zum Schlüsselmanagement ein erlaubt Verwendung weiterer Standards gemeinsame Schlüssel erzeugen aus Bitstring ("Masterkey")  abzuleiten
	IPsec Standards zum Schlüsselmanagement sind IKE: The Internet Key Exchange, RFC 2409. ISAKMP: Internet Security Association an Key Management Protocol, RFC 2408. The Oakley Key Determination Protocol, RFC 2412. The Internet IP Security Domain of Interpretation for ISAKMP, RFC 2407.

	Datagramm senden entsprechender Eintrag in SPD (Security Policy Database) suchen kein passender Eintrag, Datagramm verwerfen.  Datagramm nicht durch IPsec schützen: unverändert weiterreichen im Tunnel-Modus innere Header nicht verändert Außer Time to Live-Feld (+ Prüfsumme)  einschließlich Erweiterungsheader äußerer und innerer Header können bezüglich Version (IPv4 und IPv6) verschieden sein gegebenenfalls Paket fragmentieren zusammen mit Erweiterungsheadern zu groß Danach Verschlüsselung und Authentisierung  entsprechend gewählter SA  entsprechenden Header anlegen mit berechneten Werten versehen Paket an nächsten Router senden
	Eingehender Verkehr  zunächst reassembliert  SA in der SA-Database zugeordnet (Parameter) Paket authentisiern und entschlüsseln anhand Eintrag in SPD überprüfen Sicherheitsstrategie für dieses Paket eingehalten  u.U. mehrere Sicherheitsstrategien überprüfen, ehe passende gefunden  überprüftes/entschlüsseltes Paket weiterreichen an  Anwendungsschicht  oder an einen anderen Router oder  Host  Information in bearbeiteten Headern entsprechend zu behandeln  Absender oder  Prüfungsreihenfolge  in folgenden IPsec-Prozessen benötigt oder  in Firewalls benötigt Sonderfall ICMP-Nachrichten  im wesentlichen wie normale IPsec-Datagramme behandeln in der Regel Tunnel-Modus  Absenderadressen und  Empfängeradresse unverändert belassen Standard sieht auch ausdrücklich vor,  auch unauthentifizierte oder  unverschlüsselte ICMP-Nachrichten  ICMP-Nachrichten zur Bestimmung der maximalen Paketlänge auf einem Pfad PMTU, path maximum transport unit gesondert behandelt werden wichtige Information über maximale Paketgrößen  reicht Information in der ICMP-Nachricht zur Bestimmung des sendenden Routers nicht aus  Header zu viele IPsec-Daten  entsprechende Router genauere Informationen senden Berechnung der PMTU  Zusatzinformation durch die IPsec-Header berücksichtigen nicht zu kleine Datagramme  erst nach der Authentifizierung bzw. Verschlüsselung Fragmentierung durchführen
	Multi-Level Security (MLS) Sicherheitsanforderungen differenziert abhängig von der Wichtigkeit einer Nachricht Grad der geforderten Sicherheit als zusätzlicher Parameter zur Spezifizierung einer SA  zusätzliche Bearbeitung bei zu sendenden und empfangenen Paketen
	IPsec erfordert relativ aufwendige Behandlung von Datagrammen zusätzliche Bearbeitungszeit  zusätzlicher Speicher für Algorithmen  zusätzlicher Speicher für Sicherheitsdatenbanken  absichtliche Verfälschung zu schützen.  Bearbeitungszeitaufwand für  Host akzeptabel(?) Router bzw. Security Gateways könnte mit spezieller Hardware ausgestattet Bandbreitenbelastung nimmt zu  zusätzliche Verzögerungen beim Aufbau einer SA  TCP  mehr SYN-Pakete als nötig  Verbindungsaufbau abzubrechen.  UDP weniger Probleme  langsame Datenverbindung  Telefonleitung zur Zeit noch nicht unterstützte Kompression  sehr lange Verbindungszeiten  Kompression von Anwendungsschicht durchführen lassen