5.1. Traffic Selector Authorization (Autorizzazione dei Traffic Selector)
5.1. Traffic Selector Authorization (Autorizzazione dei Traffic Selector)
IKEv2 si affida alle informazioni nel PAD (Peer Authorization Database, database di autorizzazione dei pari) quando determina che tipo di Child SA un pari è autorizzato a creare. Questo processo è descritto nella Sezione 4.4.3 di [IPSECARCH]. Quando un pari richiede la creazione di una Child SA con alcuni Traffic Selector, il PAD deve contenere « Child SA Authorization Data » che collegano l'identità autenticata da IKEv2 e gli indirizzi consentiti per i Traffic Selector.
Ad esempio, il PAD potrebbe essere configurato in modo che l'identità autenticata « sgw23.example.com » sia autorizzata a creare Child SA per 192.0.2.0/24, il che significa che questo security gateway è un « rappresentante » valido per questi indirizzi. L'IPsec host-to-host richiede voci simili, collegando ad esempio « fooserver4.example.com » con 198.51.100.66/32, il che significa che questa identità è un « proprietario » o « rappresentante » valido dell'indirizzo in questione.
Come rilevato in [IPSECARCH], « è necessario imporre questi vincoli sulla creazione delle child SA per impedire a un pari autenticato di contraffare ID associati ad altri pari legittimi ». Nell'esempio sopra, una configurazione corretta del PAD impedisce a sgw23 di creare Child SA con indirizzo 198.51.100.66 e impedisce a fooserver4 di creare Child SA con indirizzi da 192.0.2.0/24.
È importante notare che il semplice invio di pacchetti IKEv2 usando un particolare indirizzo non implica il permesso di creare Child SA con quell'indirizzo nei Traffic Selector. Ad esempio, anche se sgw23 potesse contraffare il proprio indirizzo IP come 198.51.100.66, non potrebbe creare Child SA che corrispondono al traffico di fooserver4.
La specifica IKEv2 non definisce esattamente come l'assegnazione di indirizzi IP tramite payload di configurazione interagisce con il PAD. La nostra interpretazione è che quando un security gateway assegna un indirizzo usando payload di configurazione, crea anche una voce PAD temporanea che collega l'identità del pari autenticato e il nuovo indirizzo interno allocato.
Si è riconosciuto che configurare correttamente il PAD può essere difficile in alcuni ambienti. Ad esempio, se IPsec è usato tra una coppia di host i cui indirizzi sono allocati dinamicamente con DHCP (Dynamic Host Configuration Protocol), è estremamente difficile garantire che il PAD specifichi il « proprietario » corretto per ogni indirizzo IP. Ciò richiederebbe un meccanismo per trasmettere in modo sicuro le assegnazioni di indirizzo dal server DHCP e collegarle alle identità autenticate con IKEv2.
A causa di questa limitazione, alcuni fornitori hanno configurato i loro PAD per consentire a un pari autenticato di creare Child SA con Traffic Selector che contengono lo stesso indirizzo usato per i pacchetti IKEv2. In ambienti in cui lo spoofing IP è possibile (cioè quasi ovunque) ciò consente in sostanza a qualsiasi pari di creare Child SA con qualsiasi Traffic Selector. Questa non è una configurazione appropriata o sicura nella maggior parte dei casi. Vedere [H2HIPSEC] per una discussione approfondita su questo tema e sui limiti generali dell'IPsec host-to-host.