weidner/computer/netz/vpn/

Die IPsec SPD verstehen

In meinem aktuellen Buch beschäftige ich mich mit der Fehlersuche bei IPsec. Zu diesem Zweck versuche ich, ein Verständnis zu entwickeln, was bei IPsec passiert und welchen Einfluß die Policy auf die Entscheidungen hat, die für jedes einzelne Datagramm getroffen werden.

Eine IPsec-Implementation kann auf einem Host, als Security Gateway oder als unabhängiges Gerät arbeiten und bietet Schutz für IP-Traffic. Dieser Schutz unterliegt den Regeln der Security Policy Database (SPD).

Das Verarbeitungsmodell von IPsec unterscheidet zwischen ungeschützten Schnittstellen (schwarz), an denen verschlüsselte Daten gesendet und empfangen werden, sowie geschützten Schnittstellen (rot), an denen Daten unverschlüsselt übertragen werden.

Im Rahmen einer IPsec-Instanz bezeichnet "inbound" auf der schwarzen Seite ankommenden Datenverkehr, der entschlüsselt auf der roten Seite gesendet oder lokal verarbeitet wird. Dementsprechend meint "outbound" abgehenden Datenverkehr, der auf einer roten Schnittstelle ankommt oder lokal erzeugt wird und auf einer schwarzen Schnittstelle gesendet wird.

Die SPD entscheidet bei Traffic, der die IPsec-Boundary überquert, ob dieser

• ver- beziehungsweise entschlüsselt wird (PROTECT),
• verworfen wird (DISCARD)
• oder die Grenze unverändert passieren darf (BYPASS).

RFC 4301 erläutert die Aufgaben der SPD ausführlich, ohne auf die konkrete Form der Datenbank oder ihrer Schnittstelle einzugehen. Der Text spezifiziert nur die minimale Funktionalität, die eine IPsec-Implementation benötigt, um den Datenverkehr an einem Gateway oder Host zu steuern. Eine Implementation muss mindestens eine und kann mehrere SPD haben, die für sämtlichen Traffic, welcher die IPsec-Boundary überquert, konsultiert werden müssen.

Wie bestimmt die SPD, was mit dem Traffic passiert

Die SPD ist eine sortierte Datenbank, so wie Access Control Lists oder Paketfilter, deren Reihenfolge eine Policy explizit vorgibt. Die Sortierung ist notwendig, weil sich die Selektoren der Datensätze überlappen können und in diesem Fall die Reihenfolge in der Policy bestimmt, welcher Datensatz zur Anwendung kommt.

Die SPD ist logisch unterteilt in drei Teile:

• die SPD-S enthält Informationen für den durch IPsec geschützten Datenverkehr.

• die SPD-O entscheidet ob abgehender Datenverkehr verworfen oder unverändert durchgelassen werden soll.

• die SPD-I ist für ankommenden Datenverkehr zuständig.

Wenn eine IPsec-Implementation nur eine SPD enthält, besteht diese aus allen drei Teilen. Falls mehrere SPD unterstützt werden, können einige von diesen auch nur einzelne Teile enthalten, zum Beispiel um ankommenden Traffic pro Interface effizienter zu klassifizieren.

Für abgehende Datagramme werden immer SPD-O und SPD-S befragt, für ankommende Datagramme SPD-I und SPD-S.

Abgehender Datenverkehr

Kommt ein Datagramm, das auf der schwarzen Seite hinausgehen soll, auf der roten Seite an, muss die SPD entscheiden, ob dieser Traffic ignoriert, an IPsec vorbei geleitet oder mit IPsec geschützt werden soll.

Im ersten Fall sehe ich nichts auf der schwarzen Seite, im zweiten Fall sehe ich dort das unveränderte Datagramm. Beim dritten Fall sehe ich AH- beziehungsweise ESP-Traffic auf der schwarzen Seite, wenn bereits eine passende Security Association (SA) aktiv ist. Oder ich sehe IKE-Traffic, mit dem eine passende SA ausgehandelt wird. Dabei wird wiederum die SPD konsultiert, um die möglichen Parameter zu bestimmen.

Ankommender Datenverkehr

Kommt auf der schwarzen Seite Traffic an, wird dieser entsprechend der folgenden Kategorien verarbeitet:

1. IKE-Traffic
2. AH- beziehungsweise ESP-Traffic
3. ICMP-Fehlermeldungen
4. sonstiger Traffic

Bei IKE-Traffic reagiert das IKE-Subsystem entsprechend den ankommenden Nachrichten.

• IKE_SA_INIT und IKE_AUTH dienen der Einrichtung eines neuen Tunnels, zu dem wiederum die SPD befragt wird.

• CREATE_CHILD_SA dient dem Einrichten einer weiteren SA für zusätzlichen Traffic oder dem Erneuern einer bestehenden SA, deren Lebenszeit demnächst abläuft. Auch hier ist die SPD involviert.

• INFORMATIONAL schließlich dient der Dead-Peer-Detection, dem Löschen von nicht mehr benötigten SA und weiteren Managementfunktionen.

Beim AH- beziehungsweise ESP-Traffic wird die entsprechende SA konsultiert, die am mitgesendeten SPI erkennbar ist. Der Traffic wird entschlüsselt und durchgeleitet oder verworfen, wenn Fehler auftreten.

Kann bei ICMP-Fehlermeldungen eine passende SA ermittelt werden, werden gegebenenfalls die Parameter dieser SA angepasst. Ein Anwendungsfall dafür ist die Unterstützung der Path-MTU-Discovery für den geschützten Traffic.

Bei allem anderen Traffic wird die SPD-I konsultiert, ob dieser unverändert durchgelassen oder verworfen werden soll.

Wie sieht ein SPD-Datensatz aus?

Jeder SPD-Datensatz spezifiziert die Bestimmung von Datagrammen entweder als BYPASS, DISCARD oder PROTECT. Der Schlüssel für den Datensatz besteht aus einem oder mehreren Selektoren.

Bei Traffic, über den mittels eines SPD-I- oder SPD-O-Datensatzes entschieden wird, ist genau eine Richtung vorgegeben. Bei Traffic, der durch IPsec geschützt wird, muss jedoch die Richtung beachtet werden. Üblicherweise benötigen die durch IPsec geschützten Protokolle symmetrische SA für ankommenden und abgehenden Verkehr. Hier werden nötigenfalls die lokalen und fernen Adressen des SPD-Eintrags vertauscht.

Der SPD-Datensatz enthält die folgenden Informationen

• einen Selektor, der erlaubt, ein Datagramm dem bestimmten Eintrag zuzuordnen
• die Entscheidung über das Datagramm: BYPASS, DISCARD oder PROTECT
• bei PROTECT-Einträgen (SPD-S)
  • PFP Flags - einen pro Traffic-Selektor
  • Parameter die für den Schutz des Datagramms notwendig sind (Algorithmen, Modi, ...).

PFP-Flags (Populate From Packet) legen fest, ob beim Aushandeln einer SA der Wert aus der SPD übernommen oder vom auslösenden Datagramm abgeleitet wird. Im zweiten Fall ist es möglich, gleichzeitig verschiedene SA aus dem gleichen SPD-Datensatz zu erzeugen, bei denen sich die Werte unterscheiden, für die das PFP-Flag in der SPD gesetzt ist.

Mögliche Werte für SPD-Datensätze sind neben den feldspezifischen wie Adressen oder Ports die Werte OPAQUE, der anzeigt, dass der Wert im Datagramm nicht verfügbar ist, und ANY, der auf jeden Wert passt, auch wenn der Wert nicht verfügbar ist. Damit umfasst ANY auch OPAQUE und letzteres ist nur notwendig, wenn es darauf ankommt diesen speziellen Fall zu unterscheiden, zum Beispiel für Fragmente von Datagrammen.

Bei IKEv2 werden diese beiden Werte mit Ranges wie folgt ausgehandelt:

ANY:	start = 0	end = max
OPAQUE:	start = max	end = 0

Woran unterscheidet die SPD den Traffic?

Prinzipiell unterscheidet die SPD den Traffic anhand von Selektoren, die entweder Eigenschaften der Datagramme beschreiben oder mit dem IKE-Protokoll ausgehandelt werden.

Folgende Selektoren müssen von allen IPsec-Implementationen unterstützt werden:

• Eigene IP-Adressen (Local IP Addresses)
• IP-Adressen der Gegenseite (Remote IP Addresses)
• das Protokoll der nächsten Ebene (Next Layer Protocol)
• vom Protokoll abhängige Selektoren
• ein Name

Local IP Addresses / Remote IP Addresses

Hierbei handelt es sich jeweils um eine Liste von Adressbereichen (IPv4 oder IPv6). Die Struktur erlaubt die Angabe von

• einzelnen Adressen
• einer Liste von Adressen
• einem Adressbereich mit Anfangs- und Endadresse
• einer Liste von Adressbereichen

Die SPD bietet keinen Support für Multicast-Adressen. Wenn Multicast über IPsec gesendet werden soll, muss man eine Group SPD, wie in RFC3740 definiert, verwenden.

Next Layer Protocol

Dieser Selektor entspricht dem Protocol-Feld bei IPv4 beziehungsweise dem Feld Next Header bei IPv6. Das kann eine einzelne Protokollnummer sein, ANY oder OPAQUE.

Verschiedene zusätzliche Selektoren hängen von den Werten bei Next Layer Protocol ab:

• Wenn das Next Layer Protocol zwei Ports verwendet (wie TCP, UDP und andere), gibt es Selektoren für Local Ports und Remote Ports.

• Ist das Next Layer Protocol ein Mobility Header, dann gibt es einen Selektor für den IPv6 Mobility Header Message Type.

• Wenn das Next Layer Protocol ICMP ist, gibt es einen Selektor für ICMP-Message-Type und -Code.

Name

Dieser Selektor unterscheidet sich von den anderen darin, dass er nicht von einem Datagramm abgeleitet wird. Ein Name kann als Identifikator für eine lokale oder entfernte Adresse bei IPsec verwendet werden.

Benannte SPD-Einträge werden auf zwei Arten verwendet:

1. Ein SPD-Eintrag mit Name wird beim Responder (nicht dem Initiator) zur Unterstützung der Zugangskontrolle verwendet, wenn eine Adresse für den Adress-Selektor nicht geeignet wäre, zum Beispiel bei einem "Road Warrior". In diesem Fall überschreibt der Wert der Remote IP Address in der SPD den Wert der Adresse im ESP-Tunnel.

2. Ein SPD-Eintrag mit Name wird vom Initiator einer IKE-Sitzung verwendet, um den Benutzer zu identifizieren, für den eine IPsec-SA angelegt werden soll. Diese Verwendung ist optional für IPsec auf einem Host in einer Multiuser-Umgebung. Der Name wird nur lokal verwendet und nicht über das Netz zum Peer kommuniziert.

Details hierzu finden sich auf Seite 28-29 von RFC4301.

Damit ist das Wesentliche zur Rolle und Wirkungsweise der Security Policy Database bei IPsec gesagt. Für Details und weitergehende Fragen empfehle ich einen Blick in das RFC4301 und gegebenenfalls in weitere RFCs zu IPsec und IKE.

Posted 2020-03-02