2.1. Security Parameters Index (Indice dei parametri di sicurezza, SPI)

Il SPI è un valore arbitrario di 32 bit utilizzato da un ricevitore per identificare la SA a cui è associato un pacchetto in arrivo. Il campo SPI è obbligatorio.

Per una SA unicast, il SPI può essere utilizzato da solo per specificare una SA, oppure può essere utilizzato insieme al tipo di protocollo IPsec (in questo caso ESP). Poiché il valore SPI è generato dal ricevitore per una SA unicast, se il valore sia sufficiente per identificare una SA da solo o se debba essere utilizzato insieme al valore del protocollo IPsec è una questione locale. Questo meccanismo per mappare il traffico in entrata alle SA unicast DEVE essere supportato da tutte le implementazioni ESP.

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 traffico unicast non devono implementare questo algoritmo di demultiplexing.

In molte architetture multicast sicure (ad esempio, [RFC3740]), un Group Controller/Key Server centrale assegna unilateralmente il SPI dell'associazione di sicurezza di gruppo. Questa assegnazione SPI non è negoziata o coordinata con i sottosistemi di gestione delle chiavi (ad esempio, IKE) che risiedono nei singoli sistemi terminali che compongono il gruppo. Di conseguenza, è possibile che un'associazione di sicurezza di gruppo e un'associazione di sicurezza unicast possano utilizzare simultaneamente lo stesso SPI. Un'implementazione IPsec in grado di gestire il multicast DEVE demultiplexare 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 la destinazione, o gli indirizzi IP di destinazione e origine, oltre al SPI. Per le SA multicast, il campo protocollo non viene utilizzato per le ricerche SA. Per ogni pacchetto in entrata protetto da IPsec, un'implementazione deve condurre la sua ricerca del 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 ESP in entrata con quella voce SAD corrispondente. Altrimenti, procedere al passaggio 2.

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

3. Cercare nel SAD una corrispondenza solo su {SPI} se il ricevitore ha scelto di mantenere un unico spazio SPI per AH ed ESP, o su {SPI, protocol} altrimenti. Se una voce SAD corrisponde, elaborare il pacchetto ESP 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 DEBBA 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 per il SPI. Le voci SAD nell'elenco collegato del bucket di ciascuna tabella hash sono mantenute ordinate in modo da avere quelle voci SAD con gli identificatori SA più lunghi per prime in quell'elenco collegato. Quelle voci SAD con gli identificatori SA più corti sono ordinate in modo che siano le ultime voci nell'elenco collegato. Un'implementazione basata su hardware può essere in grado di effettuare intrinsecamente la ricerca della corrispondenza più lunga, utilizzando funzionalità Ternary Content-Addressable Memory (TCAM) comunemente disponibili.

L'indicazione se la corrispondenza degli indirizzi di origine e destinazione è richiesta per mappare il traffico IPsec in entrata alle SA DEVE essere impostata come effetto collaterale della configurazione SA manuale 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 dei valori SPI nell'intervallo da 1 a 255 è riservato dall'Internet Assigned Numbers Authority (IANA) per uso futuro; un valore SPI riservato non sarà normalmente assegnato dall'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 sulla rete. (Ad esempio, un'implementazione di gestione delle chiavi potrebbe utilizzare il valore SPI zero per significare "Nessuna associazione di sicurezza 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 è ancora stata stabilita.)