2.1. Security Parameters Index (Index des paramètres de sécurité, SPI)

Le SPI est une valeur arbitraire de 32 bits utilisée par un récepteur pour identifier la SA à laquelle un paquet entrant est lié. Le champ SPI est obligatoire.

Pour une SA unicast, le SPI peut être utilisé seul pour spécifier une SA, ou il peut être utilisé en conjonction avec le type de protocole IPsec (dans ce cas ESP). Étant donné que la valeur SPI est générée par le récepteur pour une SA unicast, la question de savoir si la valeur est suffisante pour identifier une SA par elle-même ou si elle doit être utilisée en conjonction avec la valeur du protocole IPsec est une question locale. Ce mécanisme de mappage du trafic entrant vers les SA unicast DOIT être pris en charge par toutes les implémentations ESP.

Si une implémentation IPsec prend en charge le multicast, elle DOIT prendre en charge les SA multicast en utilisant l'algorithme ci-dessous pour mapper les datagrammes IPsec entrants vers les SA. Les implémentations qui ne prennent en charge que le trafic unicast n'ont pas besoin d'implémenter cet algorithme de démultiplexage.

Dans de nombreuses architectures multicast sécurisées (par exemple, [RFC3740]), un contrôleur de groupe/serveur de clés central attribue unilatéralement le SPI de l'association de sécurité de groupe. Cette attribution de SPI n'est pas négociée ou coordonnée avec les sous-systèmes de gestion des clés (par exemple, IKE) qui résident dans les systèmes terminaux individuels qui composent le groupe. Par conséquent, il est possible qu'une association de sécurité de groupe et une association de sécurité unicast puissent utiliser simultanément le même SPI. Une implémentation IPsec capable de multicast DOIT démultiplexer correctement le trafic entrant même dans le contexte de collisions SPI.

Chaque entrée de la base de données d'association de sécurité (SAD) [Ken-Arch] doit indiquer si la recherche SA utilise l'adresse de destination, ou les adresses IP de destination et source, en plus du SPI. Pour les SA multicast, le champ de protocole n'est pas utilisé pour les recherches SA. Pour chaque paquet entrant protégé par IPsec, une implémentation doit effectuer sa recherche dans la SAD de manière à trouver l'entrée qui correspond à l'identifiant SA "le plus long". Dans ce contexte, si deux entrées SAD ou plus correspondent sur la base de la valeur SPI, l'entrée qui correspond également sur la base de la comparaison des adresses de destination, ou de destination et source (comme indiqué dans l'entrée SAD) est la correspondance "la plus longue". Cela implique un ordre logique de recherche SAD comme suit:

1. Recherchez dans la SAD une correspondance sur {SPI, adresse de destination, adresse source}. Si une entrée SAD correspond, traitez le paquet ESP entrant avec cette entrée SAD correspondante. Sinon, passez à l'étape 2.

2. Recherchez dans la SAD une correspondance sur {SPI, adresse de destination}. Si l'entrée SAD correspond, traitez le paquet ESP entrant avec cette entrée SAD correspondante. Sinon, passez à l'étape 3.

3. Recherchez dans la SAD une correspondance uniquement sur {SPI} si le récepteur a choisi de maintenir un espace SPI unique pour AH et ESP, ou sur {SPI, protocol} sinon. Si une entrée SAD correspond, traitez le paquet ESP entrant avec cette entrée SAD correspondante. Sinon, jetez le paquet et enregistrez un événement auditable.

En pratique, une implémentation PEUT choisir n'importe quelle méthode pour accélérer cette recherche, bien que son comportement visible de l'extérieur DOIVE être fonctionnellement équivalent à avoir recherché la SAD dans l'ordre ci-dessus. Par exemple, une implémentation basée sur logiciel pourrait indexer dans une table de hachage par le SPI. Les entrées SAD dans la liste chaînée de chaque compartiment de table de hachage sont triées de manière à avoir ces entrées SAD avec les identifiants SA les plus longs en premier dans cette liste chaînée. Ces entrées SAD ayant les identifiants SA les plus courts sont triées de sorte qu'elles soient les dernières entrées de la liste chaînée. Une implémentation basée sur matériel peut être capable d'effectuer intrinsèquement la recherche de correspondance la plus longue, en utilisant des fonctionnalités Ternary Content-Addressable Memory (TCAM) couramment disponibles.

L'indication de savoir si la correspondance des adresses source et destination est requise pour mapper le trafic IPsec entrant vers les SA DOIT être définie soit comme effet secondaire de la configuration manuelle de la SA, soit via une négociation utilisant un protocole de gestion SA, par exemple IKE ou Group Domain of Interpretation (GDOI) [RFC3547]. En règle générale, les groupes Source-Specific Multicast (SSM) [HC03] utilisent un identifiant SA à 3 tuples composé d'un SPI, d'une adresse multicast de destination et d'une adresse source. Une SA de groupe Any-Source Multicast nécessite uniquement un SPI et une adresse multicast de destination comme identifiant.

L'ensemble des valeurs SPI dans la plage 1 à 255 est réservé par l'Internet Assigned Numbers Authority (IANA) pour une utilisation future; une valeur SPI réservée ne sera normalement pas attribuée par l'IANA à moins que l'utilisation de la valeur SPI attribuée ne soit spécifiée dans une RFC. La valeur SPI de zéro (0) est réservée à une utilisation locale, spécifique à l'implémentation et NE DOIT PAS être envoyée sur le réseau. (Par exemple, une implémentation de gestion de clés pourrait utiliser la valeur SPI zéro pour signifier "Aucune association de sécurité n'existe" pendant la période où l'implémentation IPsec a demandé que son entité de gestion de clés établisse une nouvelle SA, mais la SA n'a pas encore été établie.)