2.9. Traffic Selector Negotiation (Negoziazione dei Traffic Selector)

Quando un sottosistema IPsec conforme a RFC4301 riceve un pacchetto IP che corrisponde a un selettore « protect » nel Security Policy Database (SPD), protegge il pacchetto con IPsec. Se non esiste ancora una SA, spetta a IKE crearla. La manutenzione della SPD è fuori dall'ambito di IKE, sebbene alcune implementazioni possano aggiornare la SPD in connessione con IKE (esempio in Sezione 1.1.3).

I payload Traffic Selector (TS) consentono agli endpoint di comunicare parte delle informazioni della SPD ai peer. Devono essere comunicati 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 creata.

Ciò può servire da controllo di coerenza o guidare l'aggiornamento dinamico della SPD.

Due payload TS compaiono in ciascun messaggio dello scambio che crea una coppia di Child SA. Ogni payload TS contiene uno o più Traffic Selector, ciascuno con intervallo di indirizzi (IPv4 o IPv6), intervallo di porte e ID protocollo IP.

Il primo payload è TSi (Traffic Selector-initiator), il secondo TSr (Traffic Selector-responder). TSi specifica l'indirizzo sorgente del traffico inoltrato dall'iniziatore della coppia Child SA (o destinazione del traffico verso l'iniziatore). TSr la destinazione del traffico verso il risponditore (o sorgente dal risponditore). Esempio: tunnelizzare 198.51.100.* verso 192.0.2.* : un selettore per payload; se accettabile, il risponditore rimanda gli stessi TS.

IKEv2 permette al risponditore di scegliere un sottoinsieme del traffico proposto dall'iniziatore (aggiornamenti asimmetrici o configurazioni intenzionalmente diverse).

Il risponditore restringe i Traffic Selector a un sottoinsieme non vuoto della proposta. Tipi sconosciuti vengono ignorati e non restituiti nell'insieme ristretto.

Se l'iniziatore richiede la SA per un pacchetto dati, DOVREBBE includere come primo Traffic Selector in TSi e TSr un TS molto specifico con gli indirizzi del pacchetto che ha innescato la richiesta, poi intervalli più ampi. Senza pacchetto innescante (es. all'avvio), i primi valori possono essere intervalli.

Restrizione da parte del risponditore:

Nessuna parte accettabile → TS_UNACCEPTABLE.
Tutto accettabile → stessi TSi/TSr.
Primo selettore accettabile → restringere includendo le prime scelte dell'iniziatore.
Altrimenti → sottoinsieme accettabile di TSi/TSr.

Se esistono più sottoinsiemi accettabili la cui unione non lo è, il risponditore ne sceglie uno arbitrariamente e PUÒ includere ADDITIONAL_TS_POSSIBLE (senza dati).

Se la politica richiede una SA per ogni coppia di indirizzi ma l'iniziatore non ha fornito un primo TS preciso, il risponditore indovina o invia SINGLE_PAIR_REQUIRED.

Poche politiche richiedono SA separate per ogni coppia; se solo parte dei TS proposti è accettabile, i risponditori DOVREBBERO restringere invece di usare SINGLE_PAIR_REQUIRED.

2.9.1. Traffic Selectors Violating Own Policy

Creando una nuova SA, l'iniziatore deve evitare TS che violano la propria politica, altrimenti traffico valido può essere scartato. Politiche decorrelate [IPSECARCH] evitano questo.

Esempio: host A invia verso 198.51.100.66 via B con AES e il resto del /24 con 3DES; B accetta entrambi. Se A propone 3DES con TSr su tutto il /24, B può usare quella SA anche da .66 e A scarta. A avrebbe dovuto partizionare TSr.

In generale, se l'iniziatore propone SA per X ma non accetta una parte X' con quella SA pur accettando X' con un'altra SA', il traffico può essere perso.

2.9.2. Traffic Selectors in Rekeying

Il rekey sostituisce un Child SA esistente: una nuova SA con selettori più stretti farebbe cadere traffico consentito sulla vecchia, violando l'idea di « sostituzione ». La nuova SA NON DEVE avere selettori più stretti della originale. Se servisse un ambito più stretto, la politica è cambiata e la SA attuale sarebbe già dovuta essere eliminata.

Quando l'iniziatore tenta il rekey del Child SA, i TS proposti DOVREBBERO essere uguali o sovrainsieme di quelli del vecchio Child SA. Il risponditore NON DEVE restringere più strettamente dell'ambito attualmente in uso.

Poiché un SA rekey non può essere più stretto dell'uso corrente, i selettori dal pacchetto non servono e NON DOVREBBERO essere inviati.