Zusammenfassung

  • RFC 2401 trennte die geordnete Security Policy Database von der Datenbank aktiver Security Associations: Die erste entschied über Verwerfen, Umgehen oder Schützen, die zweite hielt Parameter einseitiger logischer Verbindungen.
  • Weder Regel noch Association waren ein Paketbeleg. Ausgehend musste AH oder ESP wirklich ausgeführt werden; eingehend folgte auf die kryptografische Verarbeitung die Prüfung, ob die tatsächlich genutzten Associations in ihrer Reihenfolge eine passende Richtlinie erfüllten.

Das Regelbuch konnte richtig sein und der Paketpfad trotzdem eine andere Behauptung liefern. Genau an dieser Grenze war RFC 2401 ungewöhnlich präzise. Es behandelte die konfigurierte Absicht, den installierten Zustand und die ausgeführte Paketoperation als verschiedene Dinge, die erst durch überprüfbare Übergänge zusammengehörten.

Die im November 1998 veröffentlichte Architektur fasste IP-Sicherheit für IPv4 und IPv6 zusammen. Sie beschrieb Zugriffskontrolle, verbindungslose Integrität, Datenursprungsauthentisierung, Schutz gegen Wiederholung, Vertraulichkeit und begrenzte Verkehrsflussvertraulichkeit. Diese Dienste waren kein einheitliches Paket. AH, ESP, Transport- und Tunnelmodus, Algorithmen und Schlüsselverwaltung konnten unterschiedliche Garantien erzeugen.

Die Security Policy Database musste praktisch den gesamten ein- und ausgehenden IP-Verkehr beherrschen, auch Verkehr ohne IPsec. Ihre Einträge waren vollständig geordnet und verwendeten Adressen sowie Felder höherer Schichten als Selektoren. Ein Treffer führte zu einer von drei Handlungen: verwerfen, IPsec umgehen oder IPsec anwenden. Eine Schutzregel legte zusätzlich Protokoll oder Bündel, Modus, Algorithmen und Verschachtelung fest.

Reihenfolge war damit ausführbare Semantik. Eine breite Regel vor einer engen konnte das Paket entscheiden, bevor die engere Regel betrachtet wurde. Auch die Richtung gehörte zum Beleg: Eine ausgehende Auswahl und eine eingehende Kontrolle waren keine Spiegelbilder. Für eine belastbare Aussage brauchte man Version, Schnittstelle, Richtung, Selektoren und Position der tatsächlich treffenden Regel.

Die Security Association Database erfüllte eine andere Aufgabe. Eine Security Association war simplex und galt für eine Richtung; beidseitiger Schutz verlangte gewöhnlich zwei. Identifiziert wurde sie durch Security Parameters Index, Zieladresse und AH- oder ESP-Protokollkennung. Der Eintrag konnte Sequenz- und Anti-Replay-Zustand, Schlüssel und Algorithmen, Lebensdauer, Modus und Pfad-MTU-Zustand enthalten.

Dieser Zustand war notwendig, aber kein Nutzungsnachweis. Ein SAD-Eintrag zeigte, dass eine Association mit bestimmten Parametern vorhanden war. Er zeigte nicht, welches Paket sie auswählte oder ob sie benutzt wurde. Ebenso wenig bewies er Empfang, Anwendungsautorisierung oder Dienstwirkung. RFC 2367 hatte mit PF_KEY die Verwaltung von Schlüsseln und Associations sichtbar gemacht; RFC 2401 ordnete diesen Zustand in einen längeren Verarbeitungsvertrag ein.

Ausgehend wurde das Paket zuerst gegen die SPD geprüft. Verwerfen beendete den Weg. Umgehen ließ es ohne IPsec normal weiterlaufen. Eine Schutzregel wählte eine geeignete Association oder stieß die Erzeugung der verlangten Association beziehungsweise des Bündels an. Erst danach mussten AH oder ESP in der geforderten Reihenfolge stattfinden, bevor Übertragung oder Weiterleitung folgte. Regel und aktiver Zustand lagen weiterhin vor der eigentlichen Transformation.

Eingehend wählten Zieladresse, Sicherheitsprotokoll und SPI zunächst eine Association. Die AH- oder ESP-Verarbeitung konnte Integrität und Ursprung prüfen, Wiederholungen behandeln und bei entsprechender Dienstwahl entschlüsseln. Kryptografischer Erfolg war jedoch noch keine vollständige Autorisierung.

Nach Verarbeitung der IPsec-Header musste das resultierende Paket zu einer eingehenden SPD-Regel passen. Dann war zu prüfen, ob die tatsächlich verwendeten Associations samt Reihenfolge deren Anforderungen erfüllten. Scheiterte eine Kandidatenregel an diesem Vergleich, kamen weitere passende Regeln in Betracht. Erst nach erfolgreicher Kontrolle durfte das Paket zur Transportschicht oder Weiterleitung gelangen. Kryptografische Gültigkeit unter einer Association und Zulässigkeit unter einer Richtlinie waren getrennte Belege.

Auch AH und ESP stützten nicht dieselbe Aussage. Der Authentication Header von 1998 bot Integrität und Ursprungsprüfung sowie optionalen Anti-Replay-Schutz, aber keine Vertraulichkeit. ESP konnte Vertraulichkeit und optional Authentisierung und Integrität bieten, mit einem anderen Schutzumfang. „IPsec hat das Paket verschlüsselt“ war daher keine allgemeine Beschreibung; Umgehen bedeutete ausdrücklich keinen IPsec-Schutz.

RFC 2401 benannte außerdem Abhängigkeiten außerhalb der Architektur: Implementierungsqualität, Betriebssystemsicherheit, Zufallsquellen und Administration. RFC 3168 änderte später den Umgang mit ECN. RFC 4301 ersetzte das Dokument 2005 und verfeinerte Richtlinienmodell, Selektoren, Fragmente und Peer-Autorisierung. Die Vorgaben von 1998 sind keine heutige Kryptografieempfehlung.

Historisch dauerhaft blieb die Trennung der Beweise. Richtlinienabsicht, installierter Zustand und Paketausführung liegen auf verschiedenen Realitätsebenen. Lu Hengs Texte über laufenden Code, lokale Entscheidung und Realitätsebenen liefern dafür eine spätere analytische Linse, nicht die Sprache des RFC. Daraus folgt eine elfstufige Kette: Quelle und Version, geladene Regel, geordneter Treffer, verlangter Schutz, aktuelle Association, ausgeführte Operation, eingehender Richtlinienvergleich, Übergabe an Netz- oder Transportgrenze, Peer-Empfang, Anwendungsverarbeitung und Dienstresultat. Keine frühe Stufe beweist eine spätere.

Quellen