Passa al contenuto principale

2.9. Negoziazione dei selettori di traffico

2.9. Negoziazione dei selettori di traffico​

Quando un sottosistema IPsec conforme a RFC 4301 riceve un pacchetto IP che corrisponde a un selettore "protect" nel suo Security Policy Database (SPD), il sottosistema protegge quel pacchetto con IPsec. Quando non esiste ancora alcuna SA, è compito di IKE crearla. La manutenzione della SPD di un sistema è al di fuori dello scopo di IKE, sebbene alcune implementazioni possano aggiornare la propria SPD in relazione all'esecuzione di IKE (per uno scenario di esempio, vedere la sezione 1.1.3).

I payload Traffic Selector (TS) consentono agli endpoint di comunicare alcune delle informazioni della loro SPD ai peer. Queste DEVONO essere comunicate a IKE dalla SPD (ad esempio, l'API PF_KEY [PFKEY] usa il messaggio SADB_ACQUIRE). I payload TS specificano i criteri di selezione per i pacchetti che saranno inoltrati sulla SA appena configurata. Ciò può servire come controllo di coerenza in alcuni scenari per assicurare che le SPD siano coerenti. In altri, guida l'aggiornamento dinamico della SPD.

Due payload TS compaiono in ciascuno dei messaggi dello scambio che crea una coppia di Child SA. Ciascun payload TS contiene uno o più selettori di traffico. Ciascun selettore di traffico consiste in un intervallo di indirizzi (IPv4 o IPv6), un intervallo di porte e un ID di protocollo IP.

Il primo dei due payload TS è noto come TSi (Traffic Selector-initiator). Il secondo è noto come TSr (Traffic Selector-responder). TSi specifica l'indirizzo sorgente del traffico inoltrato da (o l'indirizzo di destinazione del traffico inoltrato a) l'iniziatore della coppia di Child SA. TSr specifica l'indirizzo di destinazione del traffico inoltrato a (o l'indirizzo sorgente del traffico inoltrato da) il risponditore della coppia di Child SA. Ad esempio, se l'iniziatore originale richiede la creazione di una coppia di Child SA, e desidera tunnelizzare tutto il traffico dalla subnet 198.51.100.* lato iniziatore verso la subnet 192.0.2.* lato risponditore, l'iniziatore includerebbe un singolo selettore di traffico in ciascun payload TS. TSi specificherebbe l'intervallo di indirizzi (198.51.100.0 - 198.51.100.255) e TSr specificherebbe l'intervallo di indirizzi (192.0.2.0 - 192.0.2.255). Assumendo che la proposta fosse accettabile per il risponditore, esso invierebbe indietro payload TS identici.

IKEv2 consente al risponditore di scegliere un sottoinsieme del traffico proposto dall'iniziatore. Ciò può accadere quando le configurazioni dei due endpoint stanno venendo aggiornate ma solo un'estremità ha ricevuto le nuove informazioni. Poiché i due endpoint possono essere configurati da persone diverse, l'incompatibilità può persistere per un lungo periodo anche in assenza di errori. Consente inoltre configurazioni intenzionalmente diverse, come quando un'estremità è configurata per tunnelizzare tutti gli indirizzi e dipende dall'altra estremità per avere l'elenco aggiornato.

Quando il risponditore sceglie un sottoinsieme del traffico proposto dall'iniziatore, restringe i selettori di traffico a un sottoinsieme della proposta dell'iniziatore (purché l'insieme non diventi l'insieme vuoto). Se il tipo di selettore di traffico proposto è sconosciuto, il risponditore ignora quel selettore di traffico, in modo che il tipo sconosciuto non sia restituito nell'insieme ristretto.

Per consentire al risponditore di scegliere l'intervallo appropriato in questo caso, se l'iniziatore ha richiesto la SA a causa di un pacchetto dati, l'iniziatore DOVREBBE includere come primo selettore di traffico in ciascuno di TSi e TSr un selettore di traffico molto specifico che includa gli indirizzi nel pacchetto che ha provocato la richiesta. Nell'esempio, l'iniziatore includerebbe in TSi due selettori di traffico: il primo contenente l'intervallo di indirizzi (198.51.100.43 - 198.51.100.43) e la porta sorgente e il protocollo IP del pacchetto, e il secondo contenente (198.51.100.0 - 198.51.100.255) con tutte le porte e tutti i protocolli IP. L'iniziatore includerebbe similmente due selettori di traffico in TSr. Se l'iniziatore crea la coppia di Child SA non in risposta a un pacchetto in arrivo, ma piuttosto, ad esempio, all'avvio, potrebbe non esserci alcun indirizzo specifico che l'iniziatore preferisce per il tunnel iniziale rispetto a un altro. In tal caso, i primi valori in TSi e TSr possono essere intervalli anziché valori specifici.

Il risponditore esegue la restrizione come segue:

o Se la politica del risponditore non gli consente di accettare alcuna parte dei selettori di traffico proposti, risponde con un messaggio di notifica TS_UNACCEPTABLE.

o Se la politica del risponditore consente l'intero insieme di traffico coperto da TSi e TSr, non è necessaria alcuna restrizione, e il risponditore PUÒ restituire gli stessi valori TSi e TSr.

o Se la politica del risponditore consente di accettare il primo selettore di TSi e TSr, allora il risponditore DEVE restringere i selettori di traffico a un sottoinsieme che includa le prime scelte dell'iniziatore. Nell'esempio sopra, il risponditore potrebbe rispondere con TSi pari a (198.51.100.43 - 198.51.100.43) con tutte le porte e tutti i protocolli IP.

o Se la politica del risponditore non consente di accettare il primo selettore di TSi e TSr, il risponditore restringe a un sottoinsieme accettabile di TSi e TSr.

Quando viene effettuata la restrizione, possono esserci diversi sottoinsiemi accettabili ma la cui unione non lo è. In questo caso, il risponditore ne sceglie arbitrariamente uno, e PUÒ includere una notifica ADDITIONAL_TS_POSSIBLE nella risposta. La notifica ADDITIONAL_TS_POSSIBLE afferma che il risponditore ha ristretto i selettori di traffico proposti ma che altri selettori di traffico sarebbero stati anch'essi accettabili, sebbene solo in una SA separata. Non vi sono dati associati a questo tipo di notifica. Questo caso si verificherà solo quando l'iniziatore e il risponditore sono configurati diversamente l'uno dall'altro. Se l'iniziatore e il risponditore concordano sulla granularità dei tunnel, l'iniziatore non richiederà mai un tunnel più ampio di quanto il risponditore accetterà.

È possibile che la politica del risponditore contenga più intervalli più piccoli, tutti ricompresi dal selettore di traffico dell'iniziatore, e con la politica del risponditore che ciascuno di quegli intervalli dovrebbe essere inviato su una SA diversa. Continuando l'esempio sopra, il risponditore potrebbe avere una politica di disponibilità a tunnelizzare quegli indirizzi da e verso l'iniziatore, ma potrebbe richiedere che ciascuna coppia di indirizzi sia su una Child SA negoziata separatamente. Se l'iniziatore non ha generato la sua richiesta in base al pacchetto, ma (ad esempio) all'avvio, non ci sarebbero i selettori di traffico molto specifici che aiutano il risponditore a selezionare l'intervallo corretto. Non ci sarebbe alcun modo per il risponditore di determinare quale coppia di indirizzi dovrebbe essere inclusa in questo tunnel, e dovrebbe indovinare o rifiutare la richiesta con un messaggio di notifica SINGLE_PAIR_REQUIRED.

L'errore SINGLE_PAIR_REQUIRED indica che una richiesta CREATE_CHILD_SA è inaccettabile perché il suo mittente è disposto ad accettare solo selettori di traffico che specificano una singola coppia di indirizzi. Il richiedente è atteso a rispondere richiedendo una SA solo per il traffico specifico che sta cercando di inoltrare.

Poche implementazioni avranno politiche che richiedono SA separate per ciascuna coppia di indirizzi. Per questo motivo, se solo alcune parti dei TSi e TSr proposti dall'iniziatore sono accettabili per il risponditore, i risponditori DOVREBBERO restringere i selettori a un sottoinsieme accettabile piuttosto che usare SINGLE_PAIR_REQUIRED.

2.9.1. Selettori di traffico che violano la propria politica​

Quando si crea una nuova SA, l'iniziatore deve evitare di proporre selettori di traffico che violano la propria politica. Se questa regola non viene seguita, il traffico valido può essere scartato. Se usate le politiche decorrelate da [IPSECARCH], questo tipo di violazione di politica non può verificarsi.

Ciò è meglio illustrato con un esempio. Supponiamo che l'host A abbia una politica il cui effetto è che il traffico verso 198.51.100.66 è inviato tramite l'host B cifrato usando AES, e il traffico verso tutti gli altri host in 198.51.100.0/24 è anch'esso inviato tramite B, ma deve usare 3DES. Supponiamo inoltre che l'host B accetti qualsiasi combinazione di AES e 3DES.

Se ora l'host A propone una SA che usa 3DES, e include un TSr contenente (198.51.100.0-198.51.100.255), ciò sarà accettato dall'host B. Ora, l'host B può anche usare questa SA per inviare traffico da 198.51.100.66, ma quei pacchetti saranno scartati da A poiché richiede l'uso di AES per questo traffico. Anche se l'host A crea una nuova SA solo per 198.51.100.66 che usa AES, l'host B può continuare liberamente a usare la prima SA per il traffico. In questa situazione,

quando propone la SA, l'host A avrebbe dovuto seguire la propria politica, e incluso un TSr contenente ((198.51.100.0-198.51.100.65),(198.51.100.67-198.51.100.255)) invece.

In generale, se (1) l'iniziatore fa una proposta "per il traffico X (TSi/TSr), fai SA", e (2) per un sottoinsieme X' di X, l'iniziatore non accetta realmente il traffico X' con SA, e (3) l'iniziatore sarebbe disposto ad accettare il traffico X' con una SA' (!=SA), il traffico valido può essere scartato inutilmente poiché il risponditore può applicare sia SA che SA' al traffico X'.