4.1. Definition und Umfang (Definition and Scope)

Eine SA ist eine Simplex-„Verbindung", die dem von ihr getragenen Verkehr Sicherheitsdienste bietet. Sicherheitsdienste werden einer SA durch die Verwendung von AH oder ESP bereitgestellt, aber nicht beides. Wenn sowohl AH- als auch ESP-Schutz auf einen Verkehrsstrom angewendet werden, müssen zwei SAs erstellt und koordiniert werden, um den Schutz durch iterative Anwendung der Sicherheitsprotokolle zu bewirken. Um die typische bidirektionale Kommunikation zwischen zwei IPsec-fähigen Systemen zu sichern, ist ein SA-Paar (eines in jede Richtung) erforderlich. IKE erstellt explizit SA-Paare in Anerkennung dieser gängigen Nutzungsanforderung.

SA-Identifikation

Für eine SA, die zum Transport von Unicast-Verkehr verwendet wird, reicht der Sicherheitsparameterindex (Security Parameters Index, SPI) allein aus, um eine SA anzugeben. (Informationen zum SPI finden Sie in Anhang A und den AH- und ESP-Spezifikationen [Ken05b, Ken05a].) Als lokale Angelegenheit kann eine Implementierung jedoch wählen, den SPI in Verbindung mit dem IPsec-Protokolltyp (AH oder ESP) zur SA-Identifikation zu verwenden. Wenn eine IPsec-Implementierung Multicast unterstützt, MUSS sie Multicast-SAs mit dem unten stehenden Algorithmus unterstützen, um eingehende IPsec-Datagramme SAs zuzuordnen. Implementierungen, die nur Unicast-Verkehr unterstützen, müssen diesen Demultiplexing-Algorithmus nicht implementieren.

Multicast-SA-Überlegungen

In vielen sicheren Multicast-Architekturen, z.B. [RFC3740], weist ein zentraler Gruppencontroller/Schlüsselserver (Group Controller/Key Server) einseitig den SPI der Gruppensicherheitsassoziation (Group Security Association, GSA) zu. Diese SPI-Zuweisung wird nicht mit den Schlüsselverwaltungs-(z.B. IKE-)Subsystemen ausgehandelt oder koordiniert, die in den einzelnen Endsystemen residieren, die die Gruppe bilden. Folglich ist es möglich, dass eine GSA und eine Unicast-SA gleichzeitig denselben SPI verwenden. Eine Multicast-fähige IPsec-Implementierung MUSS eingehenden Verkehr korrekt demultiplexen, selbst im Kontext von SPI-Kollisionen.

Jeder Eintrag in der SA-Datenbank (SA Database, SAD) (Abschnitt 4.4.2) muss angeben, ob die SA-Suche zusätzlich zum SPI die Ziel-IP-Adresse oder die Ziel- und Quell-IP-Adressen verwendet. Für Multicast-SAs wird das Protokollfeld nicht für SA-Suchen verwendet. Für jedes eingehende, IPsec-geschützte Paket muss eine Implementierung ihre Suche der SAD so durchführen, dass sie den Eintrag findet, der dem „längsten" SA-Identifikator entspricht. In diesem Kontext gilt: Wenn zwei oder mehr SAD-Einträge basierend auf dem SPI-Wert übereinstimmen, ist der Eintrag, der auch basierend auf der Zieladresse oder Ziel- und Quelladresse (wie im SAD-Eintrag angegeben) übereinstimmt, die „längste" Übereinstimmung. Dies impliziert eine logische Reihenfolge der SAD-Suche wie folgt:

1. Suchen Sie in der SAD nach einer Übereinstimmung für die Kombination aus SPI, Zieladresse und Quelladresse. Wenn ein SAD-Eintrag übereinstimmt, verarbeiten Sie das eingehende Paket mit diesem übereinstimmenden SAD-Eintrag. Andernfalls fahren Sie mit Schritt 2 fort.

2. Suchen Sie in der SAD nach einer Übereinstimmung für sowohl SPI als auch Zieladresse. Wenn der SAD-Eintrag übereinstimmt, verarbeiten Sie das eingehende Paket mit diesem übereinstimmenden SAD-Eintrag. Andernfalls fahren Sie mit Schritt 3 fort.

3. Suchen Sie in der SAD nach einer Übereinstimmung nur für SPI, wenn der Empfänger sich entschieden hat, einen einzigen SPI-Raum für AH und ESP zu verwalten, und für sowohl SPI als auch Protokoll andernfalls. Wenn ein SAD-Eintrag übereinstimmt, verarbeiten Sie das eingehende Paket mit diesem übereinstimmenden SAD-Eintrag. Andernfalls verwerfen Sie das Paket und protokollieren Sie ein auditierbares Ereignis.

In der Praxis kann eine Implementierung jede Methode (oder gar keine) wählen, um diese Suche zu beschleunigen, obwohl ihr von außen sichtbares Verhalten funktional äquivalent dazu sein MUSS, die SAD in der oben genannten Reihenfolge durchsucht zu haben. Beispielsweise könnte eine softwarebasierte Implementierung über den SPI in eine Hash-Tabelle indizieren. Die SAD-Einträge in der verketteten Liste jedes Hash-Tabellen-Buckets könnten sortiert gehalten werden, so dass diejenigen SAD-Einträge mit den längsten SA-Identifikatoren zuerst in dieser verketteten Liste stehen. Diejenigen SAD-Einträge mit den kürzesten SA-Identifikatoren könnten so sortiert werden, dass sie die letzten Einträge in der verketteten Liste sind. Eine hardwarebasierte Implementierung kann möglicherweise die Suche nach der längsten Übereinstimmung intrinsisch durchführen, indem sie üblicherweise verfügbare Ternäre inhaltsadressierbare Speicher-Funktionen (Ternary Content-Addressable Memory, TCAM) verwendet.

Die Angabe, ob Quell- und Zieladressabgleich erforderlich ist, um eingehenden IPsec-Verkehr SAs zuzuordnen, MUSS entweder als Nebeneffekt der manuellen SA-Konfiguration oder durch Verhandlung unter Verwendung eines SA-Verwaltungsprotokolls festgelegt werden, z.B. IKE oder Group Domain of Interpretation (GDOI) [RFC3547]. Typischerweise verwenden Source-Specific Multicast (SSM) [HC03]-Gruppen einen 3-Tupel-SA-Identifikator, der aus einem SPI, einer Ziel-Multicast-Adresse und einer Quelladresse besteht. Eine Any-Source Multicast-Gruppen-SA erfordert nur einen SPI und eine Ziel-Multicast-Adresse als Identifikator.

QoS und mehrere SAs

Wenn verschiedene Verkehrsklassen (unterschieden durch Differentiated Services Code Point (DSCP)-Bits [NiBlBaBL98], [Gro02]) auf derselben SA gesendet werden und wenn der Empfänger die optionale Anti-Replay-Funktion verwendet, die sowohl in AH als auch ESP verfügbar ist, könnte dies aufgrund des von dieser Funktion verwendeten Fenstermechanismus zur unangemessenen Verwerfung von Paketen niedrigerer Priorität führen. Daher SOLLTE ein Sender Verkehr unterschiedlicher Klassen, aber mit denselben Selector-Werten, auf verschiedene SAs legen, um Quality of Service (QoS) angemessen zu unterstützen. Um dies zu ermöglichen, MUSS die IPsec-Implementierung die Einrichtung und Wartung mehrerer SAs zwischen einem gegebenen Sender und Empfänger mit denselben Selektoren erlauben. Die Verteilung des Verkehrs unter diesen parallelen SAs zur Unterstützung von QoS wird lokal vom Sender bestimmt und nicht durch IKE ausgehandelt. Der Empfänger MUSS die Pakete von den verschiedenen SAs ohne Vorurteil verarbeiten. Diese Anforderungen gelten sowohl für Transport-Modus- als auch für Tunnel-Modus-SAs. Im Fall von Tunnel-Modus-SAs erscheinen die fraglichen DSCP-Werte im inneren IP-Header. Im Transport-Modus kann sich der DSCP-Wert unterwegs ändern, dies sollte jedoch keine Probleme hinsichtlich der IPsec-Verarbeitung verursachen, da der Wert nicht für die SA-Auswahl verwendet wird und NICHT als Teil der SA/Paket-Validierung überprüft werden darf (MUST NOT). Wenn jedoch eine signifikante Neuordnung von Paketen in einer SA auftritt, z.B. als Ergebnis von Änderungen der DSCP-Werte unterwegs, kann dies das Verwerfen von Paketen durch einen Empfänger aufgrund der Anwendung des Anti-Replay-Mechanismus auslösen.

DISKUSSION: Obwohl die DSCP [NiBlBaBL98, Gro02]- und Explicit Congestion Notification (ECN) [RaFlBl01]-Felder keine „Selektoren" sind, wie dieser Begriff in dieser Architektur verwendet wird, benötigt der Sender einen Mechanismus, um Pakete mit einem gegebenen (Satz von) DSCP-Werten zur entsprechenden SA zu leiten. Dieser Mechanismus könnte als „Klassifikator" (classifier) bezeichnet werden.

Transport-Modus vs Tunnel-Modus

Wie oben erwähnt, sind zwei Arten von SAs definiert: Transport-Modus und Tunnel-Modus. IKE erstellt SA-Paare, daher wählen wir zur Vereinfachung, dass beide SAs in einem Paar vom selben Modus sein müssen, Transport-Modus oder Tunnel-Modus.

Transport-Modus-SA

Eine Transport-Modus-SA ist eine SA, die typischerweise zwischen einem Paar von Hosts eingesetzt wird, um End-to-End-Sicherheitsdienste bereitzustellen. Wenn Sicherheit zwischen zwei Zwischensystemen entlang eines Pfads gewünscht wird (im Gegensatz zur End-to-End-Verwendung von IPsec), KANN der Transport-Modus zwischen Sicherheitsgateways oder zwischen einem Sicherheitsgateway und einem Host verwendet werden. In dem Fall, in dem der Transport-Modus zwischen Sicherheitsgateways oder zwischen einem Sicherheitsgateway und einem Host verwendet wird, kann der Transport-Modus verwendet werden, um In-IP-Tunneling (z.B. IP-in-IP [Per96] oder Generic Routing Encapsulation (GRE)-Tunneling [FaLiHaMeTr00] oder dynamisches Routing [ToEgWa04]) über Transport-Modus-SAs zu unterstützen. Zur Klarstellung: Die Verwendung des Transport-Modus durch ein Zwischensystem (z.B. ein Sicherheitsgateway) ist nur erlaubt, wenn sie auf Pakete angewendet wird, deren Quelladresse (für ausgehende Pakete) oder Zieladresse (für eingehende Pakete) eine Adresse ist, die zum Zwischensystem selbst gehört. Die Zugriffskontrollfunktionen, die ein wichtiger Teil von IPsec sind, sind in diesem Kontext erheblich eingeschränkt, da sie nicht auf die End-to-End-Header der Pakete angewendet werden können, die eine auf diese Weise verwendete Transport-Modus-SA durchqueren. Daher sollte diese Art der Verwendung des Transport-Modus sorgfältig bewertet werden, bevor sie in einem bestimmten Kontext eingesetzt wird.

In IPv4 erscheint ein Transport-Modus-Sicherheitsprotokoll-Header unmittelbar nach dem IP-Header und allen Optionen und vor allen Protokollen der nächsten Schicht (z.B. TCP oder UDP). In IPv6 erscheint der Sicherheitsprotokoll-Header nach dem Basis-IP-Header und ausgewählten Erweiterungs-Headern, kann aber vor oder nach Zieloptionen erscheinen; er MUSS vor Protokollen der nächsten Schicht (z.B. TCP, UDP, Stream Control Transmission Protocol (SCTP)) erscheinen. Im Fall von ESP bietet eine Transport-Modus-SA Sicherheitsdienste nur für diese Protokolle der nächsten Schicht, nicht für den IP-Header oder Erweiterungs-Header vor dem ESP-Header. Im Fall von AH wird der Schutz auch auf ausgewählte Teile des davor liegenden IP-Headers, ausgewählte Teile von Erweiterungs-Headern und ausgewählte Optionen (enthalten im IPv4-Header, IPv6-Hop-by-Hop-Erweiterungs-Header oder IPv6-Ziel-Erweiterungs-Headern) erweitert. Weitere Details zur von AH gebotenen Abdeckung finden Sie in der AH-Spezifikation [Ken05b].

Tunnel-Modus-SA

Eine Tunnel-Modus-SA ist im Wesentlichen eine SA, die auf einen IP-Tunnel angewendet wird, wobei die Zugriffskontrollen auf die Header des Verkehrs innerhalb des Tunnels angewendet werden. Zwei Hosts KÖNNEN eine Tunnel-Modus-SA zwischen sich einrichten. Abgesehen von den beiden Ausnahmen unten, MUSS die SA im Tunnel-Modus sein, wenn eines der Enden einer Sicherheitsassoziation ein Sicherheitsgateway ist. Daher ist eine SA zwischen zwei Sicherheitsgateways typischerweise eine Tunnel-Modus-SA, ebenso wie eine SA zwischen einem Host und einem Sicherheitsgateway. Die beiden Ausnahmen sind wie folgt.

• Wenn der Verkehr für ein Sicherheitsgateway bestimmt ist, z.B. Simple Network Management Protocol (SNMP)-Befehle, agiert das Sicherheitsgateway als Host und der Transport-Modus ist erlaubt. In diesem Fall endet die SA an einer Host-(Verwaltungs-)Funktion innerhalb eines Sicherheitsgateways und verdient daher eine andere Behandlung.

• Wie oben erwähnt, KÖNNEN Sicherheitsgateways eine Transport-Modus-SA unterstützen, um Sicherheit für IP-Verkehr zwischen zwei Zwischensystemen entlang eines Pfads bereitzustellen, z.B. zwischen einem Host und einem Sicherheitsgateway oder zwischen zwei Sicherheitsgateways.

Mehrere Bedenken motivieren die Verwendung des Tunnel-Modus für eine SA, die ein Sicherheitsgateway einbezieht. Wenn es beispielsweise mehrere Pfade (z.B. über verschiedene Sicherheitsgateways) zum selben Ziel hinter einem Sicherheitsgateway gibt, ist es wichtig, dass ein IPsec-Paket an das Sicherheitsgateway gesendet wird, mit dem die SA ausgehandelt wurde. Ebenso muss ein Paket, das unterwegs fragmentiert werden könnte, alle Fragmente an dieselbe IPsec-Instanz liefern lassen, um vor der kryptographischen Verarbeitung wieder zusammengesetzt zu werden. Wenn außerdem ein Fragment von IPsec verarbeitet und übertragen wird und dann unterwegs fragmentiert wird, ist es entscheidend, dass es innere und äußere Header gibt, um die Fragmentierungszustandsdaten für die Paketformate vor und nach IPsec zu erhalten. Daher gibt es mehrere Gründe für die Verwendung des Tunnel-Modus, wenn eines der Enden einer SA ein Sicherheitsgateway ist. (Die Verwendung eines IP-in-IP-Tunnels in Verbindung mit dem Transport-Modus kann diese Fragmentierungsprobleme ebenfalls beheben. Diese Konfiguration schränkt jedoch die Fähigkeit von IPsec ein, Zugriffskontrollrichtlinien auf den Verkehr anzuwenden.)

Hinweis: AH und ESP können nicht im Transport-Modus auf IPv4-Pakete angewendet werden, die Fragmente sind. In solchen Fällen kann nur der Tunnel-Modus verwendet werden. Für IPv6 wäre es machbar, ein Klartext-Fragment auf einer Transport-Modus-SA zu tragen; jedoch gilt diese Einschränkung zur Vereinfachung auch für IPv6-Pakete. Weitere Details zur Handhabung von Klartext-Fragmenten auf der geschützten Seite der IPsec-Barriere finden Sie in Abschnitt 7.

Für eine Tunnel-Modus-SA gibt es einen „äußeren" IP-Header, der die IPsec-Verarbeitungsquelle und das Ziel angibt, sowie einen „inneren" IP-Header, der die (scheinbar) ultimative Quelle und das Ziel für das Paket angibt. Der Sicherheitsprotokoll-Header erscheint nach dem äußeren IP-Header und vor dem inneren IP-Header. Wenn AH im Tunnel-Modus verwendet wird, werden Teile des äußeren IP-Headers geschützt (wie oben), sowie das gesamte getunnelte IP-Paket (d.h. der gesamte innere IP-Header ist geschützt, ebenso wie Protokolle der nächsten Schicht). Wenn ESP verwendet wird, wird der Schutz nur dem getunnelten Paket gewährt, nicht dem äußeren Header.

Implementierungsanforderungen

Zusammenfassend:

a) Eine Host-Implementierung von IPsec MUSS sowohl Transport- als auch Tunnel-Modus unterstützen. Dies gilt für native, BITS- und BITW-Implementierungen für Hosts.

b) Ein Sicherheitsgateway MUSS den Tunnel-Modus unterstützen und KANN den Transport-Modus unterstützen. Wenn es den Transport-Modus unterstützt, sollte dieser nur verwendet werden, wenn das Sicherheitsgateway als Host agiert, z.B. für die Netzwerkverwaltung oder um Sicherheit zwischen zwei Zwischensystemen entlang eines Pfads bereitzustellen.