2.4. Security Parameters Index (SPI)

L'SPI è un valore arbitrario di 32 bit utilizzato da un ricevitore per identificare la SA a cui è associato un pacchetto in arrivo. Per una SA unicast, l'SPI può essere utilizzato da solo per specificare una SA, o può essere utilizzato in combinazione con il tipo di protocollo IPsec (in questo caso AH). Poiché per le SA unicast il valore SPI è generato dal ricevitore, se il valore è sufficiente per identificare una SA da solo o se deve essere utilizzato in combinazione con il valore del protocollo IPsec è una questione locale. Il campo SPI è obbligatorio, e questo meccanismo per mappare il traffico in entrata alle SA unicast descritto sopra DEVE essere supportato da tutte le implementazioni AH.

Se un'implementazione IPsec supporta il multicast, allora DEVE supportare le SA multicast utilizzando l'algoritmo seguente per mappare i datagrammi IPsec in entrata alle SA. Le implementazioni che supportano solo il traffico unicast non hanno bisogno di implementare questo algoritmo di de-multiplexing.

In molte architetture multicast sicure, ad esempio, [RFC3740], un Group Controller/Key Server centrale assegna unilateralmente l'SPI della security association di gruppo. Questa assegnazione SPI non è negoziata o coordinata con i sottosistemi di gestione delle chiavi (ad esempio, IKE) che risiedono nei singoli sistemi finali che compongono il gruppo. Di conseguenza, è possibile che una security association di gruppo e una security association unicast possano utilizzare simultaneamente lo stesso SPI. Un'implementazione IPsec con capacità multicast DEVE de-multiplexare correttamente il traffico in entrata anche nel contesto di collisioni SPI.

Ogni voce nel Security Association Database (SAD) [Ken-Arch] deve indicare se la ricerca SA utilizza gli indirizzi IP di destinazione, o di destinazione e origine, oltre all'SPI. Per le SA multicast, il campo del protocollo non viene utilizzato per le ricerche SA. Per ogni pacchetto in entrata protetto da IPsec, un'implementazione deve condurre la sua ricerca nel SAD in modo tale da trovare la voce che corrisponde all'identificatore SA "più lungo". In questo contesto, se due o più voci SAD corrispondono in base al valore SPI, allora la voce che corrisponde anche in base al confronto degli indirizzi di destinazione, o di destinazione e origine, (come indicato nella voce SAD) è la corrispondenza "più lunga". Ciò implica un ordinamento logico della ricerca SAD come segue:

1. Cercare nel SAD una corrispondenza su {SPI, indirizzo di destinazione, indirizzo di origine}. Se una voce SAD corrisponde, elaborare il pacchetto AH in entrata con quella voce SAD corrispondente. Altrimenti, procedere al passo 2.

2. Cercare nel SAD una corrispondenza su {SPI, indirizzo di destinazione}. Se una voce SAD corrisponde, elaborare il pacchetto AH in entrata con quella voce SAD corrispondente. Altrimenti, procedere al passo 3.

3. Cercare nel SAD una corrispondenza solo su {SPI} se il ricevitore ha scelto di mantenere un singolo spazio SPI per AH ed ESP, o su {SPI, protocollo} altrimenti. Se una voce SAD corrisponde, elaborare il pacchetto AH in entrata con quella voce SAD corrispondente. Altrimenti, scartare il pacchetto e registrare un evento verificabile.

In pratica, un'implementazione PUÒ scegliere qualsiasi metodo per accelerare questa ricerca, sebbene il suo comportamento visibile esternamente DEVE essere funzionalmente equivalente ad aver cercato nel SAD nell'ordine sopra indicato. Ad esempio, un'implementazione basata su software potrebbe indicizzare in una tabella hash tramite l'SPI. Le voci SAD nella lista concatenata di ogni bucket della tabella hash vengono mantenute ordinate per avere quelle voci SAD con gli identificatori SA più lunghi per prime in quella lista concatenata. Quelle voci SAD con gli identificatori SA più corti sono ordinate in modo che siano le ultime voci nella lista concatenata. Un'implementazione basata su hardware potrebbe essere in grado di effettuare la ricerca della corrispondenza più lunga intrinsecamente, utilizzando le funzionalità comunemente disponibili della Ternary Content-Addressable Memory (TCAM).

L'indicazione se è richiesta la corrispondenza degli indirizzi di origine e destinazione per mappare il traffico IPsec in entrata alle SA DEVE essere impostata come effetto collaterale della configurazione manuale della SA o tramite negoziazione utilizzando un protocollo di gestione SA, ad esempio, IKE o Group Domain of Interpretation (GDOI) [RFC3547]. Tipicamente, i gruppi Source-Specific Multicast (SSM) [HC03] utilizzano un identificatore SA a 3 tuple composto da un SPI, un indirizzo multicast di destinazione e un indirizzo di origine. Una SA di gruppo Any-Source Multicast richiede solo un SPI e un indirizzo multicast di destinazione come identificatore.

L'insieme di valori SPI nell'intervallo da 1 a 255 è riservato dall'Internet Assigned Numbers Authority (IANA) per uso futuro; un valore SPI riservato normalmente non sarà assegnato da IANA a meno che l'uso del valore SPI assegnato non sia specificato in un RFC. Il valore SPI di zero (0) è riservato per uso locale, specifico dell'implementazione e NON DEVE essere inviato sul cavo. (Ad esempio, un'implementazione di gestione delle chiavi potrebbe utilizzare il valore SPI zero per significare "Nessuna Security Association Esiste" durante il periodo in cui l'implementazione IPsec ha richiesto che la sua entità di gestione delle chiavi stabilisca una nuova SA, ma la SA non è stata ancora stabilita.)