IPsec e IKEv2

Le VPN site-to-site sono uno dei pilastri del dominio “Secure Network Access, Visibility and Enforcement” del SCOR. Capire come IPsec costruisce i tunnel e come IKE negozia le chiavi è essenziale per distinguere, in uno scenario, quale protocollo o modalità applicare e perché.

Il framework IPsec

IPsec non è un singolo protocollo ma una suite. Due componenti forniscono la protezione dei dati:

• ESP (Encapsulating Security Payload, protocollo IP 50): offre confidenzialità (cifratura) e integrità/autenticazione del payload. È la scelta standard nelle VPN moderne.
• AH (Authentication Header, protocollo IP 51): fornisce solo integrità e autenticazione, nessuna cifratura. AH protegge anche parte dell’header IP esterno, e proprio per questo non attraversa il NAT: la traduzione dell’indirizzo altera i campi coperti dall’hash e l’ICV fallisce.

Ogni comunicazione protetta è governata da una SA (Security Association), unidirezionale e identificata dallo SPI. Un tunnel bidirezionale usa quindi almeno due SA IPsec.

Tunnel mode vs Transport mode

Nelle VPN site-to-site classiche fra due router/ASA/FTD si usa tunnel mode.

Le fasi IKE

IKE (Internet Key Exchange) è il protocollo di control plane che autentica i peer e negozia le SA. Lavora in due fasi logiche:

• Phase 1: stabilisce un canale sicuro e autenticato fra i peer — la IKE SA (o ISAKMP SA), la “SA di gestione”. Qui avviene lo scambio Diffie-Hellman, l’autenticazione (PSK o certificati) e la negoziazione dei parametri di cifratura del canale di controllo.
• Phase 2: dentro il canale protetto dalla Phase 1, negozia le IPsec SA che proteggeranno il traffico dati reale (quello selezionato dagli interesting traffic / proxy ID).

IKEv1 vs IKEv2

IKEv1 in Phase 1 prevede due modalità:

• Main mode: 6 messaggi, nasconde le identità dei peer, più sicuro.
• Aggressive mode: 3 messaggi, più veloce ma espone gli identificativi e l’hash PSK, vulnerabile a offline cracking. La Phase 2 (Quick Mode) usa 3 messaggi.

IKEv2 riprogetta tutto ed è lo standard preferito:

• Stabilisce IKE SA + prima IPsec SA in soli 4 messaggi (IKE_SA_INIT ×2, IKE_AUTH ×2).
• Non esiste aggressive mode: la distinzione main/aggressive è concettualmente superata.
• NAT-Traversal (NAT-T) integrato nativamente: rileva il NAT e incapsula ESP in UDP 4500 (il rilevamento parte da UDP 500).
• EAP integrato, utile per l’autenticazione remote-access (es. AnyConnect IKEv2).
• Supporta autenticazione asimmetrica (i due peer possono usare metodi diversi) e include anti-DoS (cookie) e liveness check nativi.

PFS e Diffie-Hellman

Il DH group determina la robustezza del materiale di chiave (group 14 = 2048-bit MODP, group 19/20/21 = ECDH). Group deboli (1, 2, 5) sono sconsigliati.

Con la Perfect Forward Secrecy (PFS), la Phase 2 esegue un nuovo scambio DH indipendente da quello di Phase 1: se una chiave viene compromessa in futuro, le sessioni passate non sono decifrabili retroattivamente. La PFS va abilitata su entrambi i peer e il DH group deve corrispondere, altrimenti la Phase 2 non si stabilisce.

Trappole tipiche d’esame

• Scenario: il tunnel deve passare attraverso un dispositivo NAT. → Non usare AH (incompatibile con NAT perché autentica l’header IP esterno). Usa ESP con NAT-T (incapsulamento in UDP 4500).
• Scenario: la domanda menziona “aggressive mode” con IKEv2. → Trabocchetto: IKEv2 non ha aggressive mode. Aggressive/main mode esistono solo in IKEv1.
• Scenario: serve confidenzialità del traffico dati. → AH non cifra. Solo ESP fornisce cifratura; AH dà esclusivamente integrità/autenticazione.
• Scenario: si vuole che la compromissione futura di una chiave non esponga il traffico registrato in passato. → Abilitare PFS (nuovo DH in Phase 2) su entrambi i peer con lo stesso group.
• Scenario: Phase 1 up ma Phase 2 non sale (o viceversa). → Verificare i mismatch per fase: transform-set/proposal, DH group PFS, e soprattutto i crypto ACL / proxy ID che devono essere speculari fra i due lati.