2.4. Indice des paramètres de sécurité (SPI)

Le SPI est une valeur arbitraire de 32 bits qui est utilisée par un récepteur pour identifier la SA à laquelle un paquet entrant est lié. Pour une SA unicast, le SPI peut être utilisé seul pour spécifier une SA, ou il peut être utilisé conjointement avec le type de protocole IPsec (dans ce cas AH). Parce que pour les SA unicast, la valeur SPI est générée par le récepteur, le fait que la valeur soit suffisante pour identifier une SA par elle-même ou qu'elle doive être utilisée conjointement avec la valeur du protocole IPsec est une question locale. Le champ SPI est obligatoire, et ce mécanisme de mappage du trafic entrant vers les SA unicast décrit ci-dessus DOIT être pris en charge par toutes les implémentations AH.

Si une implémentation IPsec prend en charge le multicast, alors 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 ni négociée ni coordonnée avec les sous-systèmes de gestion de clés (par exemple, IKE) qui résident dans les systèmes finaux 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 de SPI.

Chaque entrée dans la base de données d'association de sécurité (SAD) [Ken-Arch] doit indiquer si la recherche de SA utilise les adresses IP de destination, ou de destination et de source, en plus du SPI. Pour les SA multicast, le champ de protocole n'est pas utilisé pour les recherches de 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 de SA "le plus long". Dans ce contexte, si deux entrées SAD ou plus correspondent en fonction de la valeur SPI, alors l'entrée qui correspond également en fonction de la comparaison d'adresse de destination, ou de destination et de source (comme indiqué dans l'entrée SAD) est la correspondance "la plus longue". Cela implique un ordre logique de recherche dans la SAD comme suit:

1. Rechercher dans la SAD une correspondance sur {SPI, adresse de destination, adresse source}. Si une entrée SAD correspond, alors traiter le paquet AH entrant avec cette entrée SAD correspondante. Sinon, passer à l'étape 2.

2. Rechercher dans la SAD une correspondance sur {SPI, adresse de destination}. Si une entrée SAD correspond, alors traiter le paquet AH entrant avec cette entrée SAD correspondante. Sinon, passer à l'étape 3.

3. Rechercher dans la SAD une correspondance sur seulement {SPI} si le récepteur a choisi de maintenir un espace SPI unique pour AH et ESP, ou sur {SPI, protocole} sinon. Si une entrée SAD correspond, alors traiter le paquet AH entrant avec cette entrée SAD correspondante. Sinon, rejeter le paquet et enregistrer 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é dans la SAD dans l'ordre ci-dessus. Par exemple, une implémentation logicielle pourrait indexer dans une table de hachage par le SPI. Les entrées SAD dans la liste chaînée de chaque bucket de table de hachage sont triées pour avoir ces entrées SAD avec les identifiants de SA les plus longs en premier dans cette liste chaînée. Ces entrées SAD ayant les identifiants de SA les plus courts sont triées de sorte qu'elles soient les dernières entrées dans la liste chaînée. Une implémentation matérielle peut être capable d'effectuer la recherche de correspondance la plus longue intrinsèquement, en utilisant des fonctionnalités de mémoire adressable par contenu ternaire (TCAM) couramment disponibles.

L'indication du fait que la correspondance d'adresse source et de 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 SA, soit via une négociation utilisant un protocole de gestion de SA, par exemple, IKE ou Group Domain of Interpretation (GDOI) [RFC3547]. Typiquement, les groupes Source-Specific Multicast (SSM) [HC03] utilisent un identifiant de 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 ne nécessite qu'un SPI et une adresse multicast de destination comme identifiant.

L'ensemble des valeurs SPI dans la plage de 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 pour 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é à son entité de gestion de clés d'établir une nouvelle SA, mais la SA n'a pas encore été établie.)