4.4.1.1. Selektoren (Selectors)
Eine SA kann fein- oder grobkörnig sein, abhängig von den Selektoren, die verwendet werden, um die Menge des Verkehrs für die SA zu definieren. Zum Beispiel kann der gesamte Verkehr zwischen zwei Hosts über eine einzige SA übertragen werden und einen einheitlichen Satz von Sicherheitsdiensten erhalten. Alternativ kann der Verkehr zwischen einem Paar von Hosts über mehrere SAs verteilt sein, abhängig von den verwendeten Anwendungen (wie durch das Next Layer Protocol und zugehörige Felder, z.B. Ports, definiert), wobei verschiedene SAs unterschiedliche Sicherheitsdienste bieten. Ebenso könnte der gesamte Verkehr zwischen einem Paar von Sicherheitsgateways über eine einzige SA übertragen werden, oder eine SA könnte für jedes kommunizierende Host-Paar zugewiesen werden.
Die folgenden Selectorparameter MÜSSEN von allen IPsec-Implementierungen unterstützt werden, um die Kontrolle der SA-Granularität zu erleichtern. Beachten Sie, dass sowohl lokale als auch entfernte Adressen entweder IPv4 oder IPv6 sein sollten, aber keine Mischung von Adresstypen. Beachten Sie auch, dass die lokalen/entfernten Port-Selektoren (und ICMP-Nachrichtentyp und -code sowie Mobility Header-Typ) als OPAQUE gekennzeichnet werden können, um Situationen zu berücksichtigen, in denen diese Felder aufgrund von Paketfragmentierung nicht zugänglich sind.
Entfernte IP-Adresse(n) (Remote IP Address(es))
Typ: IPv4 oder IPv6
Dies ist eine Liste von Bereichen von IP-Adressen (Unicast, Broadcast (nur IPv4)). Diese Struktur ermöglicht den Ausdruck von:
- Einer einzelnen IP-Adresse (über einen trivialen Bereich)
- Einer Liste von Adressen (jede ein trivialer Bereich)
- Einem Bereich von Adressen (niedrige und hohe Werte, inklusive)
- Einer Liste von Bereichen
Adressbereiche werden verwendet, um mehr als ein entferntes System zu unterstützen, das dieselbe SA teilt, z.B. hinter einem Sicherheitsgateway.
Lokale IP-Adresse(n) (Local IP Address(es))
Typ: IPv4 oder IPv6
Dies ist eine Liste von Bereichen von IP-Adressen (Unicast, Broadcast (nur IPv4)). Diese Struktur ermöglicht den Ausdruck von:
- Einer einzelnen IP-Adresse (über einen trivialen Bereich)
- Einer Liste von Adressen (jede ein trivialer Bereich)
- Einem Bereich von Adressen (niedrige und hohe Werte, inklusive)
- Einer Liste von Bereichen
Adressbereiche werden verwendet, um mehr als ein Quellsystem zu unterstützen, das dieselbe SA teilt, z.B. hinter einem Sicherheitsgateway. Lokal bezieht sich auf die Adresse(n), die durch diese Implementierung (oder Richtlinieneintrag) geschützt werden.
Hinweis: Die SPD enthält keine Unterstützung für Multicast-Adresseinträge. Um Multicast-SAs zu unterstützen, sollte eine Implementierung eine Gruppen-SPD (Group SPD, GSPD) verwenden, wie in [RFC3740] definiert. GSPD-Einträge erfordern eine andere Struktur, d.h. man kann die symmetrische Beziehung, die mit lokalen und entfernten Adresswerten für Unicast-SAs verbunden ist, nicht in einem Multicast-Kontext verwenden. Insbesondere würde ausgehender Verkehr, der an eine Multicast-Adresse auf einer SA gerichtet ist, nicht auf einer begleitenden eingehenden SA mit der Multicast-Adresse als Quelle empfangen werden.
Next Layer Protocol
Quelle: IPv4 "Protocol"-Feld oder IPv6 "Next Header"-Feld
Werte: Individuelle Protokollnummer, ANY oder (nur IPv6) OPAQUE
Das Next Layer Protocol ist das, was nach vorhandenen IP-Erweiterungs-Headern kommt. Um das Auffinden des Next Layer Protocol zu vereinfachen, SOLLTE es einen Mechanismus geben, um zu konfigurieren, welche IPv6-Erweiterungs-Header übersprungen werden sollen.
Standard-IPv6-Erweiterungs-Header zum Überspringen:
- 0 (Hop-by-hop-Optionen)
- 43 (Routing Header)
- 44 (Fragmentation Header)
- 60 (Destination Options)
Hinweis: Die Standardliste enthält NICHT 51 (AH) oder 50 (ESP). Aus der Perspektive der Selektor-Suche behandelt IPsec AH und ESP als Next Layer Protocols.
Vom Next Layer Protocol abhängige Selektoren
Mehrere zusätzliche Selektoren hängen vom Next Layer Protocol-Wert ab:
Ports (TCP, UDP, SCTP, etc.)
Wenn das Next Layer Protocol zwei Ports verwendet (wie TCP, UDP, SCTP und andere), gibt es Selektoren für lokale und entfernte Ports. Jeder dieser Selektoren hat eine Liste von Wertebereichen.
Wichtig: Die lokalen und entfernten Ports sind möglicherweise nicht verfügbar, wenn ein fragmentiertes Paket empfangen wird oder wenn die Port-Felder durch IPsec geschützt (verschlüsselt) wurden; daher MUSS auch ein Wert von OPAQUE unterstützt werden.
Fragmentierungsbehandlung:
- In einem nicht-initialen Fragment sind Port-Werte nicht verfügbar.
- Wenn ein Port-Selektor einen anderen Wert als ANY oder OPAQUE angibt, kann er keine Pakete abgleichen, die nicht-initiale Fragmente sind.
- Wenn die SA einen anderen Port-Wert als ANY oder OPAQUE erfordert, MUSS ein eintreffendes Fragment ohne Ports verworfen werden. (Siehe Abschnitt 7, "Behandlung von Fragmenten".)
Mobility Header-Typ (Mobility Header Type)
Wenn das Next Layer Protocol ein Mobility Header ist, gibt es einen Selektor für den IPv6 Mobility Header-Nachrichtentyp (MH type). Dies ist ein 8-Bit-Wert, der eine bestimmte Mobilitätsnachricht identifiziert.
Hinweis: Der MH-Typ ist möglicherweise nicht verfügbar, wenn ein fragmentiertes Paket empfangen wird. (Siehe Abschnitt 7, "Behandlung von Fragmenten".)
Für IKE: Der IPv6 Mobility Header-Nachrichtentyp (MH type) wird in den höchstwertigen acht Bits des 16-Bit-lokalen "Port"-Selektors platziert.
ICMP-Typ und -Code (ICMP Type and Code)
Wenn der Next Layer Protocol-Wert ICMP ist, gibt es einen 16-Bit-Selektor für den ICMP-Nachrichtentyp und -code.
Struktur:
- Nachrichtentyp (Message Type): Einzelner 8-Bit-Wert, der den Typ einer ICMP-Nachricht definiert, oder ANY
- ICMP-Code (ICMP Code): Einzelner 8-Bit-Wert, der einen spezifischen Subtyp für eine ICMP-Nachricht definiert
Für IKE:
- Der Nachrichtentyp wird in den höchstwertigen 8 Bits des 16-Bit-Selektors platziert
- Der Code wird in den niedrigstwertigen 8 Bits platziert
Erlaubte Kombinationen:
- Einzelner Typ und ein Bereich von Codes
- Einzelner Typ und ANY Code
- ANY Typ und ANY Code
Matching-Algorithmus: Gegeben einen Richtlinieneintrag mit einem Bereich von Typen (T-start bis T-end) und einem Bereich von Codes (C-start bis C-end), und einem ICMP-Paket mit Typ t und Code c, MUSS eine Implementierung auf eine Übereinstimmung testen mit:
(T-start*256) + C-start <= (t*256) + c <= (T-end*256) + C-end
Hinweis: Der ICMP-Nachrichtentyp und -code sind möglicherweise nicht verfügbar, wenn ein fragmentiertes Paket empfangen wird. (Siehe Abschnitt 7, "Behandlung von Fragmenten".)
Name
Wichtig: Dies ist kein Selektor wie die anderen oben. Er wird nicht aus einem Paket gewonnen. Ein Name kann als symbolischer Identifikator für eine lokale oder entfernte IPsec-Adresse verwendet werden.
Benannte SPD-Einträge werden auf zwei Arten verwendet:
Anwendungsfall 1: Responder (Zugriffskontrolle für Road Warriors)
Ein benannter SPD-Eintrag wird von einem Responder (nicht einem Initiator) zur Unterstützung der Zugriffskontrolle verwendet, wenn eine IP-Adresse für den Remote-IP-Adress-Selektor nicht geeignet wäre, z.B. für "Road Warriors".
Prozess:
- Der Name, der verwendet wird, um dieses Feld abzugleichen, wird während der IKE-Verhandlung in der ID-Payload kommuniziert.
- Die Quell-IP-Adresse des Initiators (innerer IP-Header im Tunnel-Modus) wird an die Remote-IP-Adresse im SAD-Eintrag gebunden, der durch die IKE-Verhandlung erstellt wurde.
- Diese Adresse überschreibt den Remote-IP-Adresswert in der SPD, wenn der SPD-Eintrag auf diese Weise ausgewählt wird.
Anforderung: Alle IPsec-Implementierungen MÜSSEN diese Verwendung von Namen unterstützen.
Unterstützte Namensformen:
- Fully Qualified Domain Name (FQDN)
- Distinguished Name (DN)
- RFC 822 E-Mail-Adresse
- Key ID
Anwendungsfall 2: Initiator (Multi-User-Identifikation)
Ein benannter SPD-Eintrag kann von einem Initiator verwendet werden, um einen Benutzer zu identifizieren, für den eine IPsec-SA erstellt wird (oder für den Verkehr umgangen werden kann). Die IP-Quelladresse des Initiators (aus dem inneren IP-Header im Tunnel-Modus) wird verwendet, um Folgendes zu ersetzen, wenn und wann sie erstellt werden:
- Lokale Adresse im SPD-Cache-Eintrag
- Lokale Adresse im ausgehenden SAD-Eintrag
- Remote-Adresse im eingehenden SAD-Eintrag
Unterstützung: Diese Verwendung ist optional für Multi-User-Native-Host-Implementierungen und nicht auf andere Implementierungen anwendbar.
Hinweis: Dieser Name wird nur lokal verwendet; er wird nicht durch das Schlüsselverwaltungsprotokoll kommuniziert. Auch Namensformen, die nicht für Fall 1 oben (Responder) verwendet werden, sind im Initiator-Kontext anwendbar.
Name in SPD-Einträgen
Ein SPD-Eintrag kann sowohl einen Namen (oder eine Liste von Namen) als auch Werte für die lokale oder entfernte IP-Adresse enthalten.
Für Fall 1 (Responder): Die in benannten SPD-Einträgen verwendeten Identifikatoren sind DNS-Namen, Distinguished Names oder RFC 822 E-Mail-Adressen.
Für Fall 2 (Initiator): Die Namensformen können dieselben sein wie für Fall 1 oder können eine Benutzer-ID (UID) oder eine andere lokale Namenskonvention sein.
Wichtige Namensregeln:
- Alle SPD-Einträge MÜSSEN in der Lage sein, die oben für die Responder-Verwendung definierten Namensformen zu unterstützen.
- Wenn eine Implementierung es ermöglicht, SPD-Einträge unter Verwendung lokal signifikanter Namensformen für die Initiator-Verwendung zu erstellen, ist dies eine lokale Angelegenheit.
- Ein SPD-Eintrag, der einen Namen enthält, kann nur verwendet werden, wenn der Name in eine lokale oder entfernte IP-Adresse aufgelöst wird, oder wenn der Name während der IKE-Verhandlung verwendet wird, um die ID-Payload abzugleichen.