Quando progetti connettività verso un cloud provider tramite un circuito dedicato (cross-connect in colocation, private interconnect, dedicated port), il traffico che scorre sul private peering viaggia in chiaro a livello fisico. È un errore diffuso assumere che “privato” significhi “cifrato”: il circuito è isolato logicamente (VLAN dedicata, VRF, routing privato) ma i frame Ethernet non sono protetti da riservatezza né da integrità crittografica. Se le policy di conformità (PCI-DSS, dati sanitari, requisiti interni di encryption-in-transit) impongono la cifratura, devi aggiungerla esplicitamente. In ENCC le due leve principali sono MACsec (Layer 2) e IPsec over interconnect (Layer 3).

MACsec (IEEE 802.1AE) cifra e autentica i frame Ethernet hop-by-hop tra due dispositivi direttamente adiacenti. Aggiunge un SecTAG e un ICV a ogni frame, garantendo confidentiality, integrity e replay protection sul singolo segmento. È la scelta naturale quando il link dedicato è un collegamento punto-punto tra il tuo router/switch di edge e la porta del provider (o l’apparato in colo).

Lo scambio delle chiavi avviene tramite MKA (MACsec Key Agreement), definito in 802.1X-2010. In ambito interconnect si usa quasi sempre la modalità pre-shared key: si configura una key-chain con CKN (Connectivity Association Key Name) e CAK; MKA da questa deriva le SAK di sessione. I cipher supportati sono GCM-AES-128/256 e, sui link ad alta velocità (100G+), i cipher con Extended Packet Numbering — GCM-AES-XPN-128/256 — necessari per evitare l’esaurimento del packet number a throughput elevati.

Un frammento essenziale su IOS-XE:

key chain KC macsec
 key 01
  cryptographic-algorithm aes-256-cmac
  key-string <CAK>
!
interface TenGigabitEthernet0/0/0
 mka pre-shared-key key-chain KC
 macsec

Punti di progetto da ricordare:

  • should-secure vs must-secure: la policy di default must-secure scarta il traffico non cifrato; should-secure consente fallback in chiaro durante il bring-up. In produzione conforme si resta su must-secure.
  • WAN MACsec: se il link dedicato attraversa una rete di trasporto del provider, quest’ultimo deve trasportare l’EtherType 0x88E5 (frame EAPoL/MKA) end-to-end. Serve spesso configurare l’indirizzo EAPoL come broadcast affinché i frame passino il bridging del carrier.
  • Confidentiality offset: puoi lasciare in chiaro i primi 30/50 byte (header L2/L3) se il provider deve leggerli per l’instradamento, cifrando solo il payload.

Prerequisiti: supporto su porta e apparato

MACsec non è ubiquo: dipende dall’ASIC/line card. Verifica sempre che la specifica porta e la piattaforma supportino MACsec e il cipher richiesto (XPN sui 100G non è disponibile ovunque), che sia presente la licenza adeguata e che entrambi i lati siano allineati su cipher, key-chain e policy. Un mismatch fa fallire silenziosamente la sessione MKA e, in must-secure, il link resta down per il traffico dati.

Alternativa: IPsec over interconnect

MACsec ha un limite architetturale: è Layer 2 e hop-by-hop. Non sopravvive a un hop routato. Se il circuito dedicato attraversa più segmenti L3 del provider, oppure il provider non partecipa a MACsec, la cifratura L2 copre solo il primo salto. Per riservatezza end-to-end su un percorso instradato si usa IPsec over interconnect: un tunnel IPsec (spesso IKEv2) costruito sopra il private peering, tra il tuo edge e il gateway cloud.

Criterio MACsec IPsec over interconnect
Livello L2 (802.1AE) L3 (IKEv2/ESP)
Ambito Hop-by-hop, link adiacenti End-to-end su rete routata
Overhead/latenza Minimo, in hardware Maggiore, dipende dall’HW
Uso tipico Cross-connect punto-punto Interconnect multi-hop / provider non MACsec

La scelta di design è: MACsec quando il link è un adiacenza fisica diretta e vuoi il minimo overhead a wire-speed; IPsec quando serve cifrare un percorso instradato o il provider non offre MACsec.

Trappole tipiche d’esame

  • Scenario: la policy richiede cifratura sul circuito privato, il team assume sia già protetto → risposta: il private peering non è cifrato di default; va aggiunto MACsec o IPsec in modo esplicito.
  • Scenario: link dedicato che attraversa più hop L3 del provider, serve confidenzialità end-to-end → risposta: MACsec è L2 hop-by-hop e non supera un hop routato; usa IPsec over interconnect.
  • Scenario: link a 100G, MACsec attivo ma drop/rollover del packet number → risposta: adotta il cipher GCM-AES-XPN-256 (Extended Packet Numbering).
  • Scenario: MACsec in must-secure ma un lato non supporta la feature o ha cipher diverso → risposta: il traffico viene scartato; verifica supporto HW su porta/line card, licenza e allineamento cipher/key.
  • Scenario: WAN MACsec configurato ma la sessione MKA non si stabilisce → risposta: il provider deve trasportare l’EtherType 0x88E5; senza bridging dei frame EAPoL non c’è key agreement.