2.1. Security Parameters Index (Sicherheitsparameter-Index, SPI)

Der SPI ist ein beliebiger 32-Bit-Wert, der von einem Empfänger verwendet wird, um die SA zu identifizieren, an die ein eingehendes Paket gebunden ist. Das SPI-Feld ist obligatorisch.

Für eine Unicast-SA kann der SPI allein zur Angabe einer SA verwendet werden, oder er kann in Verbindung mit dem IPsec-Protokolltyp (in diesem Fall ESP) verwendet werden. Da der SPI-Wert vom Empfänger für eine Unicast-SA generiert wird, ist es eine lokale Angelegenheit, ob der Wert ausreicht, um eine SA allein zu identifizieren, oder ob er in Verbindung mit dem IPsec-Protokollwert verwendet werden muss. Dieser Mechanismus zur Zuordnung von eingehendem Verkehr zu Unicast-SAs MUSS von allen ESP-Implementierungen unterstützt werden.

Wenn eine IPsec-Implementierung Multicast unterstützt, MUSS sie Multicast-SAs unter Verwendung des folgenden Algorithmus zur Zuordnung eingehender IPsec-Datagramme zu SAs unterstützen. Implementierungen, die nur Unicast-Verkehr unterstützen, müssen diesen Demultiplexing-Algorithmus nicht implementieren.

In vielen sicheren Multicast-Architekturen (z.B. [RFC3740]) weist ein zentraler Group Controller/Key Server den SPI der Gruppensicherheitsassoziation einseitig zu. Diese SPI-Zuweisung wird nicht mit den Schlüsselverwaltungs- (z.B. IKE) Subsystemen ausgehandelt oder koordiniert, die in den einzelnen Endsystemen vorhanden sind, aus denen die Gruppe besteht. Folglich ist es möglich, dass eine Gruppensicherheitsassoziation und eine Unicast-Sicherheitsassoziation gleichzeitig denselben SPI verwenden können. Eine multicast-fähige IPsec-Implementierung MUSS eingehenden Verkehr auch im Kontext von SPI-Kollisionen korrekt demultiplexen.

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

1. Durchsuchen Sie die SAD nach einer Übereinstimmung mit {SPI, Zieladresse, Quelladresse}. Wenn ein SAD-Eintrag übereinstimmt, verarbeiten Sie das eingehende ESP-Paket mit diesem übereinstimmenden SAD-Eintrag. Andernfalls fahren Sie mit Schritt 2 fort.

2. Durchsuchen Sie die SAD nach einer Übereinstimmung mit {SPI, Zieladresse}. Wenn der SAD-Eintrag übereinstimmt, verarbeiten Sie das eingehende ESP-Paket mit diesem übereinstimmenden SAD-Eintrag. Andernfalls fahren Sie mit Schritt 3 fort.

3. Durchsuchen Sie die SAD nach einer Übereinstimmung nur mit {SPI}, wenn der Empfänger sich entschieden hat, einen einzigen SPI-Raum für AH und ESP beizubehalten, oder mit {SPI, protocol} andernfalls. Wenn ein SAD-Eintrag übereinstimmt, verarbeiten Sie das eingehende ESP-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 wählen, um diese Suche zu beschleunigen, obwohl ihr extern sichtbares Verhalten funktional äquivalent sein MUSS zum Durchsuchen der SAD in der oben genannten Reihenfolge. Beispielsweise könnte eine softwarebasierte Implementierung über den SPI in eine Hash-Tabelle indizieren. Die SAD-Einträge in der verknüpften Liste jedes Hash-Tabellen-Buckets werden sortiert gehalten, sodass diese SAD-Einträge mit den längsten SA-Identifikatoren zuerst in dieser verknüpften Liste stehen. Diese SAD-Einträge mit den kürzesten SA-Identifikatoren werden so sortiert, dass sie die letzten Einträge in der verknüpften Liste sind. Eine hardwarebasierte Implementierung kann möglicherweise die Suche nach der längsten Übereinstimmung intrinsisch durchführen, indem sie allgemein verfügbare Ternary Content-Addressable Memory (TCAM)-Funktionen verwendet.

Die Angabe, ob Quell- und Zieladressübereinstimmung erforderlich ist, um eingehenden IPsec-Verkehr zu SAs zuzuordnen, MUSS entweder als Nebeneffekt der manuellen SA-Konfiguration oder über Verhandlung unter Verwendung eines SA-Verwaltungsprotokolls, z.B. IKE oder Group Domain of Interpretation (GDOI) [RFC3547], festgelegt werden. 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.

Die Menge der SPI-Werte im Bereich 1 bis 255 ist von der Internet Assigned Numbers Authority (IANA) für zukünftige Verwendung reserviert; ein reservierter SPI-Wert wird normalerweise nicht von IANA zugewiesen, es sei denn, die Verwendung des zugewiesenen SPI-Werts ist in einem RFC spezifiziert. Der SPI-Wert null (0) ist für lokale, implementierungsspezifische Verwendung reserviert und DARF NICHT über die Leitung gesendet werden. (Beispielsweise könnte eine Schlüsselverwaltungsimplementierung den SPI-Wert null verwenden, um "Keine Sicherheitsassoziation existiert" zu bedeuten, während der Zeitraum, in dem die IPsec-Implementierung angefordert hat, dass ihre Schlüsselverwaltungsentität eine neue SA einrichtet, die SA aber noch nicht eingerichtet wurde.)