Zum Hauptinhalt springen

4.4.1. Die Sicherheitsrichtliniendatenbank (The Security Policy Database, SPD)

Eine SA ist ein Verwaltungskonstrukt, das verwendet wird, um Sicherheitsrichtlinien für Verkehr durchzusetzen, der die IPsec-Grenze überschreitet. Daher ist ein wesentliches Element der SA-Verarbeitung eine zugrunde liegende Sicherheitsrichtliniendatenbank (Security Policy Database, SPD), die festlegt, welche Dienste IP-Datagrammen angeboten werden sollen und auf welche Weise. Die Form der Datenbank und ihre Schnittstelle liegen außerhalb des Geltungsbereichs dieser Spezifikation. Dieser Abschnitt spezifiziert jedoch die minimale Verwaltungsfunktionalität, die bereitgestellt werden muss, um einem Benutzer oder Systemadministrator zu ermöglichen, zu steuern, ob und wie IPsec auf Verkehr angewendet wird, der von einem Host übertragen oder empfangen wird oder ein Sicherheitsgateway durchläuft. Die SPD oder relevante Caches müssen während der Verarbeitung des gesamten Verkehrs (eingehend und ausgehend), einschließlich des nicht durch IPsec geschützten Verkehrs, der die IPsec-Grenze durchquert, konsultiert werden. Dies schließt IPsec-Verwaltungsverkehr wie IKE ein.

SPD-Anforderungen​

Eine IPsec-Implementierung MUSS mindestens eine SPD haben, und sie KANN mehrere SPDs unterstützen, wenn dies für den Kontext geeignet ist, in dem die IPsec-Implementierung arbeitet. Es besteht keine Anforderung, SPDs auf einer Pro-Schnittstellen-Basis zu verwalten, wie in RFC 2401 spezifiziert. Wenn eine Implementierung jedoch mehrere SPDs unterstützt, MUSS sie eine explizite SPD-Auswahlfunktion enthalten, die aufgerufen wird, um die geeignete SPD für die Verarbeitung ausgehenden Verkehrs auszuwählen. Die Eingaben für diese Funktion sind das ausgehende Paket und alle lokalen Metadaten (z.B. die Schnittstelle, über die das Paket angekommen ist), die erforderlich sind, um die SPD-Auswahlfunktion auszuführen. Die Ausgabe der Funktion ist eine SPD-Kennung (SPD-ID).

Geordnete Datenbank​

Die SPD ist eine geordnete Datenbank, konsistent mit der Verwendung von Zugriffskontrolllisten (Access Control Lists, ACL) oder Paketfiltern in Firewalls, Routern usw. Die Ordnungsanforderung entsteht, weil sich Einträge oft überschneiden, aufgrund des Vorhandenseins von (nicht-trivialen) Bereichen als Werte für Selektoren. Daher MUSS ein Benutzer oder Administrator in der Lage sein, die Einträge zu ordnen, um eine gewünschte Zugriffskontrollrichtlinie auszudrücken. Es gibt keine Möglichkeit, eine allgemeine, kanonische Ordnung für SPD-Einträge durchzusetzen, aufgrund der erlaubten Verwendung von Platzhaltern für Selektorwerte und weil die verschiedenen Arten von Selektoren nicht hierarchisch verbunden sind.

Verarbeitungsoptionen: DISCARD, BYPASS, PROTECT​

Eine SPD muss zwischen Verkehr unterscheiden, der IPsec-Schutz erhält, und Verkehr, der IPsec umgehen darf. Dies gilt sowohl für den IPsec-Schutz, der von einem Sender angewendet werden soll, als auch für den IPsec-Schutz, der beim Empfänger vorhanden sein muss. Für jedes ausgehende oder eingehende Datagramm sind drei Verarbeitungsoptionen möglich: DISCARD, BYPASS IPsec oder PROTECT mit IPsec.

  • DISCARD: Verkehr, der die IPsec-Grenze (in der angegebenen Richtung) nicht durchqueren darf.
  • BYPASS: Verkehr, der die IPsec-Grenze ohne IPsec-Schutz überschreiten darf.
  • PROTECT: Verkehr, der IPsec-Schutz erhält. Für solchen Verkehr muss die SPD die zu verwendenden Sicherheitsprotokolle, deren Modus, Sicherheitsdienstoptionen und die zu verwendenden kryptographischen Algorithmen spezifizieren.

SPD-S, SPD-I, SPD-O​

Eine SPD ist logisch in drei Teile unterteilt:

  • SPD-S (sicherer Verkehr secure traffic): Enthält Einträge für allen Verkehr, der dem IPsec-Schutz unterliegt.
  • SPD-O (ausgehend outbound): Enthält Einträge für allen ausgehenden Verkehr, der umgangen oder verworfen werden soll.
  • SPD-I (eingehend inbound): Wird auf eingehenden Verkehr angewendet, der umgangen oder verworfen wird.

Alle drei können dekorreliert werden, um das Caching zu erleichtern. Wenn eine IPsec-Implementierung nur eine SPD unterstützt, besteht die SPD aus allen drei Teilen. Wenn mehrere SPDs unterstützt werden, können einige davon partiell sein, z.B. können einige SPDs nur SPD-I-Einträge enthalten, um umgangenen eingehenden Verkehr auf einer Pro-Schnittstellen-Basis zu steuern. Die Aufteilung ermöglicht es, SPD-I zu konsultieren, ohne SPD-S konsultieren zu müssen, für solchen Verkehr.

Da SPD-I nur ein Teil der SPD ist, MUSS ein Paket, das in SPD-I nachgeschlagen wird und mit keinem Eintrag dort übereinstimmen kann, verworfen werden. Beachten Sie, dass für ausgehenden Verkehr, wenn keine Übereinstimmung in SPD-S gefunden wird, SPD-O überprüft werden muss, um zu sehen, ob der Verkehr umgangen werden sollte. Ähnlich, wenn SPD-O zuerst überprüft wird und keine Übereinstimmung gefunden wird, muss SPD-S überprüft werden. In einer geordneten, nicht dekorrelierten SPD sind die Einträge für SPD-S, SPD-I und SPD-O verschachtelt. Es gibt also eine Suche in der SPD.

SPD-Einträge​

Jeder SPD-Eintrag spezifiziert die Paketdisposition als BYPASS, DISCARD oder PROTECT. Der Eintrag wird durch eine Liste von einem oder mehreren Selektoren geschlüsselt. Die SPD enthält eine geordnete Liste dieser Einträge. Die erforderlichen Selektortypen sind in Abschnitt 4.4.1.1 definiert. Diese Selektoren werden verwendet, um die Granularität der SAs zu definieren, die als Reaktion auf ein ausgehendes Paket oder als Reaktion auf einen Vorschlag von einem Peer erstellt werden. Die detaillierte Struktur eines SPD-Eintrags wird in Abschnitt 4.4.1.2 beschrieben. Jede SPD SOLLTE einen nominalen, finalen Eintrag haben, der alles erfasst, was sonst nicht erfasst wird, und es verwirft.

Die SPD MUSS es einem Benutzer oder Administrator ermöglichen, Richtlinieneinträge wie folgt zu spezifizieren:

  • SPD-I: Für eingehenden Verkehr, der umgangen oder verworfen werden soll, besteht der Eintrag aus den Werten der Selektoren, die auf den umzugehenden oder zu verwerfenden Verkehr anwendbar sind.

  • SPD-O: Für ausgehenden Verkehr, der umgangen oder verworfen werden soll, besteht der Eintrag aus den Werten der Selektoren, die auf den umzugehenden oder zu verwerfenden Verkehr anwendbar sind.

  • SPD-S: Für Verkehr, der mit IPsec geschützt werden soll, besteht der Eintrag aus den Werten der Selektoren, die auf den über AH oder ESP zu schützenden Verkehr anwendbar sind, Kontrollen darüber, wie SAs basierend auf diesen Selektoren erstellt werden sollen, und den Parametern, die erforderlich sind, um diesen Schutz zu bewirken (z.B. Algorithmen, Modi usw.). Beachten Sie, dass ein SPD-S-Eintrag auch Informationen wie das „Aus Paket füllen"-Flag (populate from packet, PFP) und Bits enthält, die anzeigen, ob die SA-Suche zusätzlich zum SPI die lokalen und entfernten IP-Adressen verwendet.

Darstellung der Direktionalität in einem SPD-Eintrag​

Für durch IPsec geschützten Verkehr werden die lokalen und entfernten Adressen und Ports in einem SPD-Eintrag ausgetauscht, um die Direktionalität darzustellen, konsistent mit IKE-Konventionen. Im Allgemeinen haben die Protokolle, mit denen IPsec umgeht, die Eigenschaft, symmetrische SAs mit vertauschten lokalen/entfernten IP-Adressen zu erfordern. Für ICMP gibt es jedoch oft keine solche bidirektionale Autorisierungsanforderung. Dennoch werden SPD-Einträge für ICMP aus Gründen der Einheitlichkeit und Einfachheit auf die gleiche Weise wie für andere Protokolle spezifiziert. Beachten Sie auch, dass es für ICMP, Mobility Header und nicht-initiale Fragmente keine Portfelder in diesen Paketen gibt.

OPAQUE und ANY​

Für jeden Selektor in einem SPD-Eintrag gibt es zusätzlich zu den literalen Werten, die eine Übereinstimmung definieren, zwei spezielle Werte: ANY und OPAQUE.

  • ANY: Ein Platzhalter, der jeden Wert im entsprechenden Feld des Pakets erfasst oder Pakete erfasst, bei denen dieses Feld nicht vorhanden oder verdeckt ist.

  • OPAQUE: Zeigt an, dass das entsprechende Selektorfeld für die Untersuchung nicht verfügbar ist, weil es möglicherweise nicht in einem Fragment vorhanden ist, für das gegebene Next Layer Protocol nicht existiert oder die vorherige Anwendung von IPsec den Wert möglicherweise verschlüsselt hat.

Der ANY-Wert umfasst den OPAQUE-Wert. Daher muss OPAQUE nur verwendet werden, wenn es notwendig ist, zwischen dem Fall eines beliebigen erlaubten Werts für ein Feld und der Abwesenheit oder Nichtverfügbarkeit (z.B. aufgrund von Verschlüsselung) des Felds zu unterscheiden.

Verwandte Abschnitte​

Letztes Update am