Le VPN, o reti private virtuali, vengono create per estendere e mettere in comunicazione diretta due o più reti private, attraverso reti esterne e/o pubbliche come Internet. In pratica si utilizza Internet come infrastruttura per connettere le proprie reti private.

Le comunicazioni passano sulla rete pubblica attraverso un canale detto tunnel; perchè sia garantita la sicurezza dei dati, i dati stessi devono essere adeguatamente protetti nel loro passaggio all'interno del tunnel. Concettualmente si potrebbe pensare alla VPN come ad un cavo virtuale che unisce due LAN. Il primo esempio di tunnel, che non include però meccanismi nativi di crittografia e autenticazione, è fornito dal protocollo GRE, Generic Routing Encapsulation, sviluppato da Cisco e poi reso standard con RFC 1701. Oggi l’implementazione di una VPN non può prescindere dall’uso di robusti meccanismi di sicurezza, comunque implementabili anche su GRE tramite alcuni accorgimenti (uso di IPSec su GRE).

L’infrastruttura IPSec

Per trasferire in maniera sicura dati tra due siti, c’è bisogno di IPsec, un’architettura di diversi standard e specifiche utilizzati per la costruzione di comunicazioni sicure su una rete non sicura: lavora al livello 3 della pila OSI (IP Layer) e si integra con la rete IP esistente. IPsec deve essere implementato solo agli endpoints, detti peers, ossia i dispositivi perimetrali che partecipano ad IPSec. Un peer può essere un router, un firewall o un dispositivo come un server, con servizi di accesso remoto e supporto ad IPsec. Tecnicamente le operazioni relative alla sicurezza sono trasparenti alle macchine delle reti private che comunicano per mezzo di un tunnel IPSec.

IPSec fornisce alcune funzioni di sicurezza essenziali:

• Riservatezza (Confidentiality), con l’uso della crittografia simmetrica. I principali algoritmi utilizzati sono DES, 3DES e AES.
• Integrità (Integrity), con l’uso di algoritmi di hash come MD5 o SHA. Qesti algoritmi vengono implementati nella loro versione HMAC, ossia HMAC-MD5 (a 128 bit)  e HMAC-SHA-1 (160 bit, più sicuro). In pratica la funzione di hash viene applicata congiuntamente ad una password precondivisa.
• Autenticazione (Authentication), necessaria per la reciproca conoscenza dei peers. Può essere stabilita tramite chiave precondivisa, detta pre-shared key, o tramite certificati digitali, utilizzando RSA. In pratica un peer locale che vuole comunicare con un peer remoto, applica una funzione di hash al suo certificato digitale; l’hash viene cifrato con la chiave privata e inviato al peer remoto insieme al certificato stesso. Il peer remoto decifra l’hash con la chiave pubblica e il valore ottenuto viene confrontato con quello dell’hash applicato nuovamente al certificato. Se i due valori sono identici, si ha l'autenticazione. Vedremo che tutti i meccanismi di autenticazione su IPSec sono gestiti dal protocollo IKE (Internet Key Exchange).
• Scambio sicuro delle chiavi (Secure key exchange), che consente ai due peers di stabilire una chiave condivisa e segreta utilizzando un canale di comunicazione insicuro (pubblico), senza la necessità che le due parti si siano scambiate informazioni precedentemente. Questo meccanismo viene messo in atto con il protocollo crittografico Diffie-Hellman. La chiave ottenuta verrà impiegata per cifrare con crittografia simmetrica le comunicazioni successive, e quindi i dati scambiati tra le reti locali messe in comunicazione da IPSec.

AH e ESP

I due principali protocolli dell’infrastruttura IPsec sono ESP (Encapsulating Security Payload) e AH (Authentication Header).

• ESP, Encapsulating Security Payload, è conosciuto come protocollo IP 50. Fornisce riservatezza (confidentiality), e opzionalmente integrità ed autenticazione. La riservatezza è fornita grazie all’uso di algoritmi di crittografia simmetrica quali DES, 3DES o AES, applicati però solo al payload del pacchetto IP: infatti ESP protegge tutto tranne l’IP header, che rimane inalterato.
• AH, Authentication Header, è conosciuto come protocollo IP 51. Fornisce integrità e autenticazione, usando algoritmi di hash come HMAC-MD5 e HMAC-SHA-1, ma non riservatezza (confidentiality). Pertanto non applica alcun tipo di crittografia sui pacchetti. E’ importante sottolineare che, a differenza di ESP, AH applica le sue funzioni all’intero pacchetto, compreso l’header IP. Per questo motivo AH genera problemi in presenza di NAT. Con il NAT, l’header di un pacchetto IP viene ricreato dal dispositivo che applica il NAT stesso,  e in tal caso si otterrà un hash non corrispondente a quello di partenza.

Il NAT fa si che gli host dietro un router o un firewall (con NAT abilitato) siano privi di connettività diretta end-to-end. Il NAT altera gli header dei pacchetti, in contrasto con IPsec che ha tra i suoi obiettivi il controllo dell'integrità del pacchetto. Il NAT è incompatibile con AH sia in tunnel mode che in transport mode, in quanto AH verifica l'integrità di tutto il pacchetto IP. ESP, invece, non controlla l'header IP né in Tunnel mode né in Transport mode, ma risulta adatto solo nel caso in cui il NAT sia di tipo statico, cioè quando ad un IP pubblico viene associato uno ed un solo IP locale; se la modifica apportata dal router coinvolge anche la porta del livello superiore, come nel port forwarding, deve essere abilitata la funzione NAT-Traversal.

Se l'integrità dell'ip header risulta importante tanto quanto la riservatezza, si possono usare AH e ESP insieme. Questo comporta il doppio delle SA rispetto ad usare solo ESP. IMPORTANTE: una SA può supportare AH o ESP ma non entrambi.

Transport mode e Tunnel mode.

Sia ESP che AH possono essere applicati ai pacchetti in due modalità differenti, transport mode e tunnel mode.

• Nel transport mode, la sicurezza è fornita al livello 4 della pila OSI. L’IP payload (carico dei pacchetti IP) è protetto ma l’header originale viene lasciato intatto. Viene utilizzato per le comunicazioni end-to-end (ad esempio per le comunicazioni tra un client e un server). La modalità di trasporto assicura la protezione di un payload IP tramite un'intestazione AH o ESP. I payload IP sono in genere rappresentati da segmenti TCP contenenti un'intestazione TCP e dati del segmento TCP, oppure da un messaggio UDP contenente un'intestazione UDP e dati del messaggio UDP, o infine da un messaggio ICMP contenente un'intestazione ICMP e dati del messaggio ICMP.
• Nel tunnel mode l’intero pacchetto IP è protetto e diventa payload di un nuovo pacchetto. Il tunnel mode è principalmente utilizzato per la creazione di VPN dedicate tra due router.

IKE, Internet Key Exchange

Le soluzioni VPN con IPsec prevedono la negoziazione di molti parametri, relativi allo scambio delle chiavi, all’autenticazione dei peers e alla scelta degli algoritmi di crittografia. I parametri negoziati tra due peers definiscono una security association (SA). Una SA viene tenuta nel SA database o SADB, creato su ogni peer.

Abbiamo già indicato che la creazione di una chiave precondivisa per cifrare i messaggi si ottiene con Diffie-Hellman. C’è da aggiungere che tutti i processi di scambio delle chiavi fanno parte del più ampio processo IKE, Internet Key Exchange.

IKE si basa su tre ulteriori protocolli di gestione delle chiavi: ISAKMP (Internet Security Association e Key Management Protocol), Oakley e Skeme. Di questi, ISAKMP è il principale, tanto che in letteratura si cita spesso ISAKMP in luogo di IKE.

Affinché due peers possano instaurare una VPN IPSec, devono avere parametri ISAKMP e IPsec identici. Quando due peers devono comunicare utilizzando IPsec, prima si autenticano reciprocamente usando IKE, stabiliscono quindi una IKE SA per lo scambio delle chiavi e infine negoziano le IPsec SA (le SA che proteggono il flusso di dati degli utenti tra i peers).

Diversamente dalle IPsec SA, che sono unidirezionali, la IKE SA è bidirezionale. Pertanto solo una IKE SA è necessaria tra due peers per supportare IPsec SA multiple, mentre per una comunicazione bidirezionale sicura tra due peer c’è bisogno di due IPsec SA.

IKE viene eseguito in 2 fasi: IKE Phase 1 e IKE Phase 2

Fase 1.

I due peers iniziano a negoziare una IKE SA, contrattando policies e modalità di autenticazione al fine di stabilire un tunnel di comunicazione sicuro. Una sessione IKE prevede che un primo router, detto initiator, invii una proposal-list ad un altro router, detto responder. La lista proposta, detta ISAKMP policy, definisce i protocolli supportati per la crittografia e l’autenticazione, per quanto tempo le chiavi devono essere considerate valide, e se deve essere applicato il metodo perfect forward secret (PFS). Con PFS la compromissione di una chiave non aiuta l’attaccante a scoprire le altre chiavi. In altre parole, ogni chiave non è derivata da altre chiavi. Il responder verifica se c'è corrispondenza di policies: in caso positivo la fase 1 continua, altrimenti il tunnel viene chiuso.

Se le corrispondenze vengono soddisfate, viene avviato il processo di scambio sicuro delle chiavi, Secure key exchange. Il processo di scambio utilizza l’algoritmo Diffie-Hellman, di cui sono supportati diversi livelli di complessità. Questi livelli vengono identificati in gruppi, ossia: DH Group 1 da 768 bit, DH Group 2 da 1024 bit, DH Group 5 da 1536 bit, DH Group 7 con crittografia ellitica.

L’ultimo scambio della fase 1 prevede l’autenticazione dei peers, in base ad una chiave precondivisa (PSK), memorizzata su entrambi i peers, o tramite certificati digitali con l’uso di RSA, o tramite meccanismo RSA encrypted nonce. Non bisogna confondere l'autenticazione dei peers, che è quella di cui si occupa IKE nella fase 1 e alla quale stiamo facendo riferimento ora, con la cifratura dei dati, che è quella garantita da ESP nella fase 2. IKE, con l'uso di un certificato o di una pre-shared key, garantisce che il peer è effettivamente chi sostiene di essere. A questo punto viene creato un tunnel sicuro grazie a ISAKMP e può avere inizio la fase 2 di IKE.

C'è da aggiungere che la fase 1 può essere portata avanti in main-mode o aggressive mode: quest’ultimo metodo è più veloce del primo, poiché effettua meno scambi e riduce la negoziazione IKE SA ad uno scambio di tre soli pacchetti.

Fase 2.

Nella fase 2 vengono negoziate le IPsec SA. Ovviamente questa fase viene portata avanti solo se la fase 1 è stata conclusa. Poiché le IPSec SA sono unidirezionali, per una comunicazione bidirezionale sicura tra due peer c’è bisogno di due Security Associations di tipo IPsec. Le security associations IPsec sono come tunnel virtuali: il traffico che entra in una SA da un peer è incapsulato, protetto e trasportato dall’altra parte, sull’altro peer. Poiché IPsec permette l’utilizzo di diversi protocolli e algoritmi, un peer deve dichiarare e negoziare con gli altri peer quali protocolli e algoritmi può supportare. Per far questo vengono scambiati e condivisi dei Transform Set, che contengono:

• Il protocollo IPsec per la sicurezza, ossia AH o ESP. E’ possibile usare AH e ESP insieme.
• Gli algoritmi di integrity/authentication, come HMAC-MD5 o  HMAC-SHA-1.
• Gli algortimi crittografici, come DES, 3DES o AES. Si può anche non criptare i dati proponendo un null encryption algorithm.

Le IPsec SA sono mantenute da IKE. Poco prima che una IPsec SA scada, una nuova SA con nuove chiavi viene creata e la comunicazione è trasportata sopra la nuova SA in modo trasparente (rekeing IKE). Ribadiamo che ogni qualvolta un peer ha bisogno di spedire dati, deve stabilire una IPsec SA con l'altro peer, perché le IPsec SA sono unidirezionali.

Schema riepilogativo

Cerchiamo ora di riassumere in breve come avviene l'instaurazione di una VPN IPSec, facendo riferimento agli argomenti trattati.

1. Un tunnel IPSec viene iniziato nel momento in cui un host A vuole inoltrare traffico ad un host B utilizzando un canale sicuro. Inizia quindi la fase 1 di IKE, nella quale i peers (router o firewall) negoziano e stabiliscono una IKE Security Association (SA) policy.
2. I peers stabiliscono delle chiavi di comunicazione segrete, scambiate con Diffie-Helmann, e poi si autenticano tra loro usando RSA o una pre-shared key (PSK).
3. Viene creato un tunnel sicuro grazie a ISAKMP e può avere inizio la fase 2 di IKE.
4. I peers usano il tunnel per negoziare le IPSec SA (transform sets). Viene quindi creato un tunnel IPSec in base ai parametri configurati nelle transform sets. All'interno di questo tunnel possono transitare i dati.