4.1. Definizione e ambito (Definition and Scope)

Una SA è una "connessione" simplex che fornisce servizi di sicurezza al traffico che trasporta. I servizi di sicurezza vengono forniti a una SA mediante l'uso di AH o ESP, ma non entrambi. Se vengono applicate sia la protezione AH che ESP a un flusso di traffico, devono essere create e coordinate due SA per effettuare la protezione attraverso l'applicazione iterata dei protocolli di sicurezza. Per proteggere la tipica comunicazione bidirezionale tra due sistemi abilitati IPsec, è richiesta una coppia di SA (una in ciascuna direzione). IKE crea esplicitamente coppie di SA in riconoscimento di questo requisito di utilizzo comune.

Identificazione SA

Per una SA utilizzata per trasportare traffico unicast, l'indice dei parametri di sicurezza (Security Parameters Index, SPI) da solo è sufficiente per specificare una SA. (Per informazioni sull'SPI, vedere l'appendice A e le specifiche AH ed ESP [Ken05b, Ken05a].) Tuttavia, come questione locale, un'implementazione può scegliere di utilizzare l'SPI insieme al tipo di protocollo IPsec (AH o ESP) per l'identificazione della SA. Se un'implementazione IPsec supporta il multicast, 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 devono implementare questo algoritmo di demultiplexing.

Considerazioni sulle SA multicast

In molte architetture multicast sicure, ad esempio [RFC3740], un controller di gruppo/server di chiavi (Group Controller/Key Server) centrale assegna unilateralmente l'SPI dell'associazione di sicurezza di gruppo (Group Security Association, GSA). Questa assegnazione di SPI non viene negoziata o coordinata con i sottosistemi di gestione delle chiavi (ad esempio, IKE) che risiedono nei singoli sistemi terminali che costituiscono il gruppo. Di conseguenza, è possibile che una GSA e una SA unicast utilizzino simultaneamente lo stesso SPI. Un'implementazione IPsec con capacità multicast DEVE demultiplexare correttamente il traffico in entrata anche nel contesto di collisioni SPI.

Ogni voce nel database SA (SA Database, SAD) (sezione 4.4.2) deve indicare se la ricerca SA utilizza l'indirizzo IP di destinazione, o gli indirizzi IP di destinazione e di 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 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, la voce che corrisponde anche in base all'indirizzo di destinazione o agli indirizzi di destinazione e di 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 sulla combinazione di SPI, indirizzo di destinazione e indirizzo di origine. Se una voce SAD corrisponde, elaborare il pacchetto in entrata con quella voce SAD corrispondente. Altrimenti, procedere al passaggio 2.

2. Cercare nel SAD una corrispondenza su SPI e indirizzo di destinazione. Se la voce SAD corrisponde, elaborare il pacchetto 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 singolo spazio SPI per AH ed ESP, e su SPI e protocollo, altrimenti. Se una voce SAD corrisponde, elaborare il pacchetto in entrata con quella voce SAD corrispondente. Altrimenti, scartare il pacchetto e registrare un evento verificabile.

In pratica, un'implementazione può scegliere qualsiasi metodo (o nessuno) per accelerare questa ricerca, sebbene il suo comportamento visibile dall'esterno 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 potrebbero essere mantenute ordinate in modo che quelle voci SAD con gli identificatori SA più lunghi siano per prime in quella lista concatenata. Quelle voci SAD con gli identificatori SA più corti potrebbero essere ordinate in modo che siano le ultime voci nella lista concatenata. Un'implementazione basata su hardware potrebbe essere in grado di effettuare intrinsecamente la ricerca della corrispondenza più lunga, utilizzando funzionalità di memoria indirizzabile per contenuto ternaria (Ternary Content-Addressable Memory, TCAM) comunemente disponibili.

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 multicast specifici della sorgente (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 multicast a sorgente qualsiasi (Any-Source Multicast) richiede solo un SPI e un indirizzo multicast di destinazione come identificatore.

QoS e SA multiple

Se diverse classi di traffico (distinte dai bit di punto di codice dei servizi differenziati (Differentiated Services Code Point, DSCP) [NiBlBaBL98], [Gro02]) vengono inviate sulla stessa SA e se il ricevitore sta utilizzando la funzionalità anti-replay opzionale disponibile sia in AH che in ESP, ciò potrebbe comportare lo scarto inappropriato di pacchetti a priorità inferiore a causa del meccanismo di finestre utilizzato da questa funzionalità. Pertanto, un mittente DOVREBBE inserire traffico di classi diverse, ma con gli stessi valori di selettore, su SA diverse per supportare adeguatamente la qualità del servizio (Quality of Service, QoS). Per consentire ciò, l'implementazione IPsec DEVE consentire l'istituzione e il mantenimento di più SA tra un dato mittente e ricevitore, con gli stessi selettori. La distribuzione del traffico tra queste SA parallele per supportare la QoS è determinata localmente dal mittente e non viene negoziata da IKE. Il ricevitore DEVE elaborare i pacchetti dalle diverse SA senza pregiudizi. Questi requisiti si applicano sia alle SA in modalità trasporto che in modalità tunnel. Nel caso delle SA in modalità tunnel, i valori DSCP in questione appaiono nell'intestazione IP interna. In modalità trasporto, il valore DSCP potrebbe cambiare in corso, ma ciò non dovrebbe causare problemi rispetto all'elaborazione IPsec poiché il valore non viene utilizzato per la selezione SA e NON DEVE essere controllato come parte della validazione SA/pacchetto. Tuttavia, se si verifica un riordino significativo dei pacchetti in una SA, ad esempio a causa di modifiche ai valori DSCP in corso, ciò potrebbe attivare lo scarto di pacchetti da parte di un ricevitore a causa dell'applicazione del meccanismo anti-replay.

DISCUSSIONE: Sebbene i campi DSCP [NiBlBaBL98, Gro02] e notifica di congestione esplicita (Explicit Congestion Notification, ECN) [RaFlBl01] non siano "selettori", come viene utilizzato quel termine in questa architettura, il mittente avrà bisogno di un meccanismo per indirizzare i pacchetti con un dato (insieme di) valori DSCP alla SA appropriata. Questo meccanismo potrebbe essere chiamato "classificatore" (classifier).

Modalità trasporto vs modalità tunnel

Come notato sopra, sono definiti due tipi di SA: modalità trasporto e modalità tunnel. IKE crea coppie di SA, quindi per semplicità scegliamo di richiedere che entrambe le SA in una coppia siano della stessa modalità, trasporto o tunnel.

SA in modalità trasporto

Una SA in modalità trasporto è una SA tipicamente impiegata tra una coppia di host per fornire servizi di sicurezza end-to-end. Quando è desiderata la sicurezza tra due sistemi intermedi lungo un percorso (rispetto all'uso end-to-end di IPsec), la modalità trasporto PUÒ essere utilizzata tra gateway di sicurezza o tra un gateway di sicurezza e un host. Nel caso in cui la modalità trasporto venga utilizzata tra gateway di sicurezza o tra un gateway di sicurezza e un host, la modalità trasporto può essere utilizzata per supportare il tunneling in-IP (ad esempio, IP-in-IP [Per96] o tunneling di incapsulamento di routing generico (Generic Routing Encapsulation, GRE) [FaLiHaMeTr00] o routing dinamico [ToEgWa04]) su SA in modalità trasporto. Per chiarire, l'uso della modalità trasporto da parte di un sistema intermedio (ad esempio, un gateway di sicurezza) è consentito solo quando applicato a pacchetti il cui indirizzo di origine (per i pacchetti in uscita) o indirizzo di destinazione (per i pacchetti in entrata) è un indirizzo appartenente al sistema intermedio stesso. Le funzioni di controllo degli accessi che sono una parte importante di IPsec sono significativamente limitate in questo contesto, poiché non possono essere applicate alle intestazioni end-to-end dei pacchetti che attraversano una SA in modalità trasporto utilizzata in questo modo. Pertanto, questo modo di utilizzare la modalità trasporto dovrebbe essere valutato attentamente prima di essere impiegato in un contesto specifico.

In IPv4, un'intestazione di protocollo di sicurezza in modalità trasporto appare immediatamente dopo l'intestazione IP e le eventuali opzioni, e prima di qualsiasi protocollo di livello successivo (ad esempio, TCP o UDP). In IPv6, l'intestazione del protocollo di sicurezza appare dopo l'intestazione IP di base e le intestazioni di estensione selezionate, ma può apparire prima o dopo le opzioni di destinazione; DEVE apparire prima dei protocolli di livello successivo (ad esempio, TCP, UDP, protocollo di trasmissione di controllo del flusso (Stream Control Transmission Protocol, SCTP)). Nel caso di ESP, una SA in modalità trasporto fornisce servizi di sicurezza solo per questi protocolli di livello successivo, non per l'intestazione IP o le intestazioni di estensione che precedono l'intestazione ESP. Nel caso di AH, la protezione è estesa anche a porzioni selezionate dell'intestazione IP che la precede, porzioni selezionate delle intestazioni di estensione e opzioni selezionate (contenute nell'intestazione IPv4, nell'intestazione di estensione hop-by-hop IPv6 o nelle intestazioni di estensione di destinazione IPv6). Per maggiori dettagli sulla copertura fornita da AH, vedere la specifica AH [Ken05b].

SA in modalità tunnel

Una SA in modalità tunnel è essenzialmente una SA applicata a un tunnel IP, con i controlli di accesso applicati alle intestazioni del traffico all'interno del tunnel. Due host POSSONO stabilire una SA in modalità tunnel tra loro. A parte le due eccezioni di seguito, ogni volta che una delle estremità di un'associazione di sicurezza è un gateway di sicurezza, la SA DEVE essere in modalità tunnel. Pertanto, una SA tra due gateway di sicurezza è tipicamente una SA in modalità tunnel, così come una SA tra un host e un gateway di sicurezza. Le due eccezioni sono le seguenti.

• Quando il traffico è destinato a un gateway di sicurezza, ad esempio comandi del protocollo di gestione di rete semplice (Simple Network Management Protocol, SNMP), il gateway di sicurezza sta agendo come un host e la modalità trasporto è consentita. In questo caso, la SA termina in una funzione host (gestione) all'interno di un gateway di sicurezza e merita quindi un trattamento diverso.

• Come notato sopra, i gateway di sicurezza POSSONO supportare una SA in modalità trasporto per fornire sicurezza per il traffico IP tra due sistemi intermedi lungo un percorso, ad esempio tra un host e un gateway di sicurezza o tra due gateway di sicurezza.

Diverse preoccupazioni motivano l'uso della modalità tunnel per una SA che coinvolge un gateway di sicurezza. Ad esempio, se ci sono più percorsi (ad esempio, tramite diversi gateway di sicurezza) verso la stessa destinazione dietro un gateway di sicurezza, è importante che un pacchetto IPsec venga inviato al gateway di sicurezza con cui è stata negoziata la SA. Allo stesso modo, un pacchetto che potrebbe essere frammentato in corso deve avere tutti i frammenti consegnati alla stessa istanza IPsec per il riassemblaggio prima dell'elaborazione crittografica. Inoltre, quando un frammento viene elaborato da IPsec e trasmesso, quindi frammentato in corso, è fondamentale che ci siano intestazioni interne ed esterne per conservare i dati sullo stato di frammentazione per i formati di pacchetto pre- e post-IPsec. Pertanto ci sono diversi motivi per utilizzare la modalità tunnel quando una delle estremità di una SA è un gateway di sicurezza. (L'uso di un tunnel IP-in-IP in combinazione con la modalità trasporto può anche affrontare questi problemi di frammentazione. Tuttavia, questa configurazione limita la capacità di IPsec di applicare politiche di controllo degli accessi sul traffico.)

Nota: AH ed ESP non possono essere applicati utilizzando la modalità trasporto a pacchetti IPv4 che sono frammenti. In tali casi può essere utilizzata solo la modalità tunnel. Per IPv6, sarebbe fattibile trasportare un frammento in chiaro su una SA in modalità trasporto; tuttavia, per semplicità, questa restrizione si applica anche ai pacchetti IPv6. Vedere la sezione 7 per maggiori dettagli sulla gestione dei frammenti in chiaro sul lato protetto della barriera IPsec.

Per una SA in modalità tunnel, c'è un'intestazione IP "esterna" che specifica la sorgente e la destinazione dell'elaborazione IPsec, più un'intestazione IP "interna" che specifica la sorgente e la destinazione (apparentemente) finali per il pacchetto. L'intestazione del protocollo di sicurezza appare dopo l'intestazione IP esterna e prima dell'intestazione IP interna. Se viene utilizzato AH in modalità tunnel, porzioni dell'intestazione IP esterna vengono protette (come sopra), così come tutto il pacchetto IP tunnelizzato (cioè, tutta l'intestazione IP interna è protetta, così come i protocolli di livello successivo). Se viene utilizzato ESP, la protezione viene fornita solo al pacchetto tunnelizzato, non all'intestazione esterna.

Requisiti di implementazione

In sintesi,

a) Un'implementazione IPsec per host DEVE supportare sia la modalità trasporto che la modalità tunnel. Ciò è vero per le implementazioni native, BITS e BITW per gli host.

b) Un gateway di sicurezza DEVE supportare la modalità tunnel e PUÒ supportare la modalità trasporto. Se supporta la modalità trasporto, dovrebbe essere utilizzata solo quando il gateway di sicurezza sta agendo come un host, ad esempio per la gestione della rete, o per fornire sicurezza tra due sistemi intermedi lungo un percorso.