2.4. Security Parameters 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. Für eine Unicast-SA kann der SPI allein verwendet werden, um eine SA zu spezifizieren, oder er kann in Verbindung mit dem IPsec-Protokolltyp (in diesem Fall AH) verwendet werden. Da bei Unicast-SAs der SPI-Wert vom Empfänger generiert wird, ist es eine lokale Angelegenheit, ob der Wert ausreicht, um eine SA für sich allein zu identifizieren, oder ob er in Verbindung mit dem IPsec-Protokollwert verwendet werden muss. Das SPI-Feld ist verpflichtend, und dieser oben beschriebene Mechanismus zur Zuordnung von eingehendem Verkehr zu Unicast-SAs MUSS von allen AH-Implementierungen unterstützt werden.

Wenn eine IPsec-Implementierung Multicast unterstützt, dann MUSS sie Multicast-SAs unter Verwendung des unten beschriebenen Algorithmus zur Zuordnung von eingehenden IPsec-Datagrammen 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 einseitig den SPI der Gruppensicherheitsassoziation 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 umfassen. 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 korrekt demultiplexen, selbst im Kontext von SPI-Kollisionen.

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, 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 Ziel- oder Ziel- und Quell-Adressenvergleich übereinstimmt (wie im SAD-Eintrag angegeben), die "längste" Übereinstimmung. Dies impliziert eine logische Reihenfolge der SAD-Suche wie folgt:

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

2. Durchsuchen Sie die SAD nach einer Übereinstimmung bei {SPI, Zieladresse}. Wenn ein SAD-Eintrag übereinstimmt, verarbeiten Sie das eingehende AH-Paket mit diesem übereinstimmenden SAD-Eintrag. Fahren Sie andernfalls mit Schritt 3 fort.

3. Durchsuchen Sie die SAD nach einer Übereinstimmung nur bei {SPI}, wenn der Empfänger gewählt hat, einen einzigen SPI-Raum für AH und ESP zu verwalten, oder bei {SPI, Protokoll} andernfalls. Wenn ein SAD-Eintrag übereinstimmt, verarbeiten Sie das eingehende AH-Paket mit diesem übereinstimmenden SAD-Eintrag. Verwerfen Sie andernfalls das Paket und protokollieren Sie ein auditfähiges Ereignis.

In der Praxis KANN eine Implementierung jede Methode wählen, um diese Suche zu beschleunigen, obwohl ihr extern sichtbares Verhalten funktional äquivalent dazu sein MUSS, die SAD in der obigen Reihenfolge durchsucht zu haben. Beispielsweise könnte eine softwarebasierte Implementierung durch den SPI in eine Hash-Tabelle indizieren. Die SAD-Einträge in der verketteten Liste jedes Hash-Tabellen-Buckets werden sortiert gehalten, sodass 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 werden so sortiert, 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 bewirken, indem sie allgemein verfügbare Ternary Content-Addressable Memory (TCAM)-Funktionen verwendet.

Die Angabe, ob eine Quell- und Zieladressenübereinstimmung erforderlich ist, um eingehenden IPsec-Verkehr SAs zuzuordnen, MUSS entweder als Nebeneffekt der manuellen SA-Konfiguration oder durch Aushandlung unter Verwendung eines SA-Verwaltungsprotokolls gesetzt werden, z.B. IKE oder Group Domain of Interpretation (GDOI) [RFC3547]. Typischerweise verwenden Source-Specific Multicast (SSM)-Gruppen [HC03] 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 der IANA zugewiesen, es sei denn, die Verwendung des zugewiesenen SPI-Werts ist in einem RFC spezifiziert. Der SPI-Wert von Null (0) ist für lokale, implementierungsspezifische Verwendung reserviert und DARF NICHT über das Netzwerk gesendet werden. (Beispielsweise könnte eine Schlüsselverwaltungsimplementierung den SPI-Wert Null verwenden, um "Keine Sicherheitsassoziation existiert" während des Zeitraums zu bedeuten, in dem die IPsec-Implementierung ihre Schlüsselverwaltungsinstanz aufgefordert hat, eine neue SA einzurichten, die SA aber noch nicht eingerichtet wurde.)