La cifratura in transito è il cuore di ogni connettività ibrida verso il cloud. Prima di progettare tunnel verso un provider IaaS occorre padroneggiare i mattoni fondamentali: IKEv2 per la negoziazione delle chiavi e IPsec/ESP per la protezione del traffico.

IKEv2: IKE SA e Child SA

IKEv2 sostituisce IKEv1 con un handshake più snello e affidabile. Lo scambio iniziale richiede solo quattro messaggi in due exchange:

  • IKE_SA_INIT: negozia gli algoritmi di protezione del canale di controllo ed esegue lo scambio Diffie-Hellman. Nasce la IKE SA (equivalente concettuale della “Phase 1”).
  • IKE_AUTH: autentica i peer (PSK, certificati o EAP) e crea la prima Child SA (equivalente della “Phase 2”), cioè la coppia di SA IPsec che protegge il traffico dati reale.

La IKE SA è bidirezionale e protegge le successive negoziazioni; le Child SA sono unidirezionali (una per direzione) e trasportano i dati utente. Nuove Child SA o i rekey avvengono tramite l’exchange CREATE_CHILD_SA, senza rinegoziare l’intera IKE SA.

Vantaggi chiave rispetto a IKEv1: NAT-Traversal nativo, messaggi con acknowledgement (affidabilità), anti-DoS tramite cookie, supporto MOBIKE, e negoziazione asimmetrica dell’autenticazione.

ESP e algoritmi

Il traffico protetto viaggia quasi sempre in ESP (IP protocol 50), che offre cifratura + integrità + anti-replay. AH (protocol 51) fornisce solo integrità, non cifra, ed è di fatto deprecato negli scenari cloud.

Funzione Algoritmi consigliati Note
Cifratura AES-256-CBC, AES-GCM GCM è AEAD: cifra e autentica in un solo passaggio
Integrità SHA-256 / SHA-384 / SHA-512 Non necessaria se si usa AES-GCM
PRF (solo IKE SA) SHA-256+ Deriva il key material
DH group 14 (MODP 2048), 19/20/21 (ECP) Group 1/2/5 obsoleti, da evitare

La PFS (Perfect Forward Secrecy) impone un nuovo scambio Diffie-Hellman a ogni rekey della Child SA: la compromissione di una chiave non espone le sessioni passate né future. Va abilitata su entrambi i peer con lo stesso DH group, altrimenti il rekey fallisce.

Policy-based vs route-based

La distinzione è cruciale in ambito cloud.

  • Policy-based (crypto map): un ACL (“proxy ID” / traffic selector) definisce quale traffico entra nel tunnel. Ogni coppia di subnet richiede una SA dedicata; scala male e non supporta routing dinamico.
  • Route-based (VTI): il tunnel è un’interfaccia virtuale (Virtual Tunnel Interface). La decisione “cosa cifrare” è demandata alla routing table: qualunque pacchetto instradato nell’interfaccia tunnel viene protetto. I traffic selector diventano 0.0.0.0/0 ↔ 0.0.0.0/0.

Su IOS-XE il route-based si realizza con un crypto ipsec profile applicato a un’interfaccia tunnel:

interface Tunnel1
 ip address 169.254.21.2 255.255.255.252
 tunnel source GigabitEthernet1
 tunnel destination 203.0.113.10
 tunnel mode ipsec ipv4
 tunnel protection ipsec profile CLOUD-PROFILE

Perché il cloud predilige route-based: i gateway VPN dei principali provider IaaS espongono tunnel route-based e si aspettano BGP sull’interfaccia (spesso su indirizzi APIPA 169.254.x.x). Con la VTI puoi far girare OSPF/BGP dentro il tunnel, gestire ridondanza attivo/attivo, ECMP e failover senza riscrivere ACL a ogni nuova subnet annunciata. È il modello scalabile e dinamico richiesto dalle connettività ibride.

Rekey e lifetime

Ogni SA ha un lifetime a tempo e/o volume. Valori di default tipici su IOS/IOS-XE:

  • IKE SA: 86400 s (24 h)
  • IPsec/Child SA: 3600 s (1 h) oppure 4608000 KB

I lifetime non devono coincidere tra i peer: al rekey vince il valore più basso. Sono invece hard match gli algoritmi, il DH group e la scelta PFS.

Trappole tipiche d’esame

  • Il tunnel non passa mai in UP e IKE_SA_INIT fallisce → mismatch di Phase 1: encryption, integrity, PRF o DH group diversi tra i peer. Allinea la proposal IKEv2.
  • IKE SA su, ma nessun traffico dati → mismatch di Phase 2: transform set (ESP algo) o traffic selector/proxy ID non coincidenti. Nel policy-based gli ACL crypto devono essere speculari.
  • Il tunnel sale e cade a intervalli regolari → PFS group impostato su un solo peer o DH group PFS diverso: il rekey della Child SA fallisce. Abilitalo identico su entrambi.
  • Scenario “il cloud richiede BGP nel tunnel” → risposta corretta = route-based con VTI, non policy-based; il policy-based non instrada protocolli dinamici.
  • Lifetime diversi indicati come causa del down → falso: i lifetime si negoziano al minimo. La causa reale è quasi sempre un parametro crypto o un traffic selector disallineato.