Zum Hauptinhalt springen

4.4.1.2. Struktur eines SPD-Eintrags (Structure of an SPD Entry)

Dieser Abschnitt enthält eine Prosabeschreibung eines SPD-Eintrags. Darüber hinaus bietet Anhang C ein Beispiel für eine ASN.1-Definition eines SPD-Eintrags.

IKE-Kompatibilitätsüberlegungen​

Dieser Text beschreibt die SPD auf eine Weise, die direkt in IKE-Payloads abgebildet werden soll, um sicherzustellen, dass die von SPD-Einträgen geforderte Richtlinie über IKE ausgehandelt werden kann. Leider stimmen die Semantiken der Version von IKEv2, die gleichzeitig mit diesem Dokument [Kau05] veröffentlicht wurde, nicht genau mit denen überein, die für die SPD definiert wurden. Insbesondere ermöglicht IKEv2 nicht die Aushandlung einer einzigen SA, die mehrere Paare von lokalen und entfernten Adressen und Ports an eine einzige SA bindet. Stattdessen behandelt IKEv2, wenn mehrere lokale und entfernte Adressen und Ports für eine SA ausgehandelt werden, diese nicht als Paare, sondern als (ungeordnete) Mengen von lokalen und entfernten Werten, die beliebig gepaart werden können.

WICHTIG: Bis IKE eine Möglichkeit bereitstellt, die in der SPD über Selektorensätze (wie unten beschrieben) ausgedrückten Semantiken zu übermitteln, DÜRFEN Benutzer NICHT (MUST NOT) mehrere Selektorensätze in einen einzelnen SPD-Eintrag aufnehmen, es sei denn, die Zugriffskontrollabsicht stimmt mit der "Mix and Match"-Semantik von IKE überein. Eine Implementierung KANN (MAY) Benutzer warnen, um sie auf dieses Problem aufmerksam zu machen, wenn Benutzer SPD-Einträge mit mehreren Selektorensätzen erstellen, deren Syntax auf mögliche Konflikte mit aktuellen IKE-Semantiken hinweist.

Überlegungen zur Verwaltungsschnittstelle​

Die Verwaltungs-GUI kann dem Benutzer andere Formen der Dateneingabe und -anzeige bieten, z.B. die Option, Adresspräfixe sowie Bereiche und symbolische Namen für Protokolle, Ports usw. zu verwenden. (Verwechseln Sie die Verwendung symbolischer Namen in einer Verwaltungsschnittstelle nicht mit dem SPD-Selektor "Name".)

Hinweis: Remote/Lokal gelten nur für IP-Adressen und Ports, nicht für ICMP-Nachrichtentyp/-code oder Mobility Header-Typ. Wenn der reservierte, symbolische Selektorwert OPAQUE oder ANY für einen bestimmten Selektortyp verwendet wird, darf nur dieser Wert in der Liste für diesen Selektor erscheinen, und er muss nur einmal in der Liste für diesen Selektor erscheinen.

Hinweis: ANY und OPAQUE sind lokale Syntaxkonventionen —— IKEv2 verhandelt diese Werte über die unten angegebenen Bereiche:

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

SPD-Eintragsfelder​

Eine SPD ist eine geordnete Liste von Einträgen, von denen jeder die folgenden Felder enthält.

o Name​

Eine Liste von IDs. Dieser Quasi-Selektor ist optional. Die Formen, die unterstützt werden MÜSSEN, sind oben in Abschnitt 4.4.1.1 unter "Name" beschrieben.

o PFP-Flags (PFP flags)​

Eines pro Verkehrsselektor. Ein gegebenes Flag, z.B. für das Next Layer Protocol, gilt für den relevanten Selektor über alle "Selektorensätze" (siehe unten) hinweg, die in einem SPD-Eintrag enthalten sind. Beim Erstellen einer SA gibt jedes Flag für den entsprechenden Verkehrsselektor an, ob der Selektor aus dem entsprechenden Feld im Paket instanziiert werden soll, das die Erstellung der SA ausgelöst hat, oder aus dem/den Wert(en) im entsprechenden SPD-Eintrag (siehe Abschnitt 4.4.1, "Wie man die Werte für einen SAD-Eintrag ableitet"). Ob ein einzelnes Flag für z.B. Quellport, ICMP-Typ/-Code und MH-Typ verwendet wird oder ein separates Flag für jeden verwendet wird, ist eine lokale Angelegenheit.

Es gibt PFP-Flags für:

  • Lokale Adresse (Local Address)
  • Entfernte Adresse (Remote Address)
  • Next Layer Protocol
  • Lokaler Port, oder ICMP-Nachrichtentyp/-code oder Mobility Header-Typ (abhängig vom Next Layer Protocol)
  • Entfernter Port, oder ICMP-Nachrichtentyp/-code oder Mobility Header-Typ (abhängig vom Next Layer Protocol)

o Ein bis N Selektorensätze (One to N selector sets)​

Diese entsprechen der "Bedingung" für die Anwendung einer bestimmten IPsec-Aktion. Jeder Selektorensatz enthält:

  • Lokale Adresse (Local Address)
  • Entfernte Adresse (Remote Address)
  • Next Layer Protocol
  • Lokaler Port, oder ICMP-Nachrichtentyp/-code oder Mobility Header-Typ (abhängig vom Next Layer Protocol)
  • Entfernter Port, oder ICMP-Nachrichtentyp/-code oder Mobility Header-Typ (abhängig vom Next Layer Protocol)

Hinweis: Der "Next Protocol"-Selektor ist ein individueller Wert (im Gegensatz zu den lokalen und entfernten IP-Adressen) in einem Selektorensatz-Eintrag. Dies steht im Einklang damit, wie IKEv2 die Traffic Selector (TS)-Werte für eine SA verhandelt. Es macht auch Sinn, weil man möglicherweise verschiedene Portfelder mit verschiedenen Protokollen assoziieren muss. Es ist möglich, mehrere Protokolle (und Ports) mit einer einzigen SA zu assoziieren, indem mehrere Selektorensätze für diese SA angegeben werden.

o Verarbeitungsinformationen (Processing info)​

Welche Aktion erforderlich ist —— PROTECT (schützen), BYPASS (umgehen) oder DISCARD (verwerfen). Es gibt nur eine Aktion, die mit allen Selektorensätzen einhergeht, nicht eine separate Aktion für jeden Satz. Wenn die erforderliche Verarbeitung PROTECT ist, enthält der Eintrag die folgenden Informationen.

Verarbeitungsinformationsfelder (für PROTECT):

  • IPsec-Modus (IPsec mode) —— Tunnel- oder Transportmodus

  • (wenn Tunnelmodus) lokale Tunneladresse (local tunnel address) —— Für einen nicht-mobilen Host, wenn es nur eine Schnittstelle gibt, ist dies einfach; wenn es mehrere Schnittstellen gibt, muss dies statisch konfiguriert werden. Für einen mobilen Host wird die Spezifikation der lokalen Adresse extern zu IPsec behandelt.

  • (wenn Tunnelmodus) entfernte Tunneladresse (remote tunnel address) —— Es gibt keine Standardmethode, um dies zu bestimmen. Siehe 4.5.3, "Lokalisierung eines Sicherheitsgateways".

  • Erweiterte Sequenznummer (Extended Sequence Number) —— Verwendet diese SA erweiterte Sequenznummern?

  • Zustandsbehaftete Fragmentprüfung (stateful fragment checking) —— Verwendet diese SA zustandsbehaftete Fragmentprüfung? (Siehe Abschnitt 7 für weitere Details.)

  • DF-Bit umgehen (Bypass DF bit) (T/F) —— anwendbar auf Tunnelmodus-SAs

  • DSCP umgehen (Bypass DSCP) (T/F) oder auf ungeschützte DSCP-Werte (Array) abbilden falls erforderlich, um das Umgehen von DSCP-Werten einzuschränken —— anwendbar auf Tunnelmodus-SAs

  • IPsec-Protokoll (IPsec protocol) —— AH oder ESP

  • Algorithmen (algorithms) —— welche für AH zu verwenden sind, welche für ESP zu verwenden sind, welche für den kombinierten Modus zu verwenden sind, nach abnehmender Priorität geordnet

Hinweis: Es ist eine lokale Angelegenheit, welche Informationen bezüglich der Behandlung bestehender SAs aufbewahrt werden, wenn die SPD geändert wird.

Letztes Update am