Quattro classi di attacchi al routing sfuggono ancora alla validazione, avverte un nuovo studio

Il 20 maggio 2025, un aggiornamento Border Gateway Protocol (BGP) contenente un attributo Prefix-SID corrotto, un campo opzionale e transitivo identificato dal codice 40, è stato originato da un Sistema Autonomo (AS) nella regione Asia-Pacifico. Un AS è una rete o un gruppo di reti sotto una singola amministrazione tecnica, identificato da un numero univoco, e BGP è il protocollo che queste reti usano per scambiare informazioni su come raggiungere ogni destinazione su internet. Quello che è successo dopo non è stato né un dirottamento di rotta tradizionale né una route leak. Cisco IOS-XR e Nokia SR-OS hanno fatto ciò che la RFC 7606 raccomanda: hanno scartato l'attributo malformato e sono andati avanti. Juniper JunOS ha inoltrato il messaggio intatto. I router Arista che lo hanno ricevuto hanno resettato le loro sessioni BGP. I route server in diversi Internet Exchange Point (IXP), i luoghi fisici dove diverse reti si connettono e scambiano traffico, hanno inoltrato l'attributo senza filtrarlo. Entro dieci secondi, il sistema di routing globale ha visto più di 150.000 aggiornamenti, e le sessioni BGP hanno avuto flapping presso Starlink, Disney, Zscaler e ByteDance, tra gli altri. Arista ha successivamente modificato questo comportamento in EOS 4.28.11 e versioni successive.

Niente di ciò che la Resource Public Key Infrastructure (RPKI), il principale sistema crittografico per la validazione dell'origine delle rotte, è progettata per controllare è stato violato in nessun punto di quella catena. Gli operatori spesso faticano a classificare l'evento: non un dirottamento, non una route leak, solo qualcosa di strano con un attributo. Questa lacuna è stato uno dei punti di partenza per un nuovo studio, pubblicato in accesso aperto su IEEE Communications Surveys & Tutorials con licenza CC BY 4.0 (DOI: 10.1109/COMST.2026.3714569). Gli autori, dell'Università Sapienza di Roma, Namex (Rome IXP) e dell'Agenzia per la Cybersicurezza Nazionale (ACN), riprendono le questioni aperte poste in uno studio sulla sicurezza del routing del 2011 di Huston, Rossi e Armitage, e si chiedono cosa sia cambiato in 15 anni. La risposta include una tassonomia che ha sorpreso anche loro.

Lo studio organizza gli attacchi al routing in quattro macro-categorie e otto micro-categorie, fornendo una nomenclatura coerente così che ogni classe possa essere mappata alle difese che la affrontano. La prima macro-categoria è la manipolazione delle rotte, che copre modifiche non autorizzate alle informazioni di prefisso o percorso. Include il dirottamento di prefisso (PRH), con varianti complete, incomplete, di intercettazione e abusive, e la manipolazione di AS_PATH (ASM), che copre avvelenamento, iniezione di origine falsificata, accorciamento del percorso ed estensione del percorso. La seconda è la coerenza del routing, attacchi alla stabilità della tabella di routing piuttosto che al suo contenuto. Questa include la volatilità dello stato (VOL), come flapping disruptive, flooding tramite oscillazione, churn amplification e convergenza ritardata, e la deaggregazione del prefisso (DEG), che può essere dannosa, negligente, sfruttativa o un fragmentation flood. La terza è la violazione delle policy, che include le route leak (RLK) nelle quattro direzioni definite nella RFC 7908, e la manipolazione delle policy (POL) tramite Local Preference, Multi-Exit Discriminator (MED), lunghezza AS_PATH e propagazione selettiva. La quarta è basata sulle sessioni, in particolare il reset di sessione basato su attributi (ATR), dove attributi opzionali transitivi malformati, sfruttamento di attributi specifici del vendor o abuso della gestione degli errori possono resettare le sessioni BGP. L'evento del maggio 2025 appartiene a questa quarta categoria.

Sovrapponendo le difese esistenti a questa struttura emerge un quadro squilibrato. Il dirottamento di prefisso ha visto i maggiori progressi, ma con importanti avvertenze. Gli Internet Routing Registries (IRR) e la RPKI forniscono la validazione dell'origine, e la copertura delle Route Origin Authorization (ROA) continua a salire. Tuttavia, la copertura non è enforcement: uno studio longitudinale su più di 28.000 AS ha rilevato che il 36,2% non implementa affatto la Route Origin Validation (ROV), e solo il 12,3% raggiunge una protezione completa. Impostazioni permissive di maxLength possono allargare la superficie di attacco invece di restringerla, motivo per cui è stata pubblicata la RFC 9319. Il dirottamento abusivo di spazio di indirizzi non annunciato rimane possibile dove gli oggetti non sono mantenuti. La manipolazione di AS_PATH è parzialmente affrontata in linea di principio da BGPsec, un protocollo che firma crittograficamente il percorso che un annuncio prende, ma è sostanzialmente non implementato. Un singolo AS non adottante nel percorso rimuove le informazioni di sicurezza, rendendo la distribuzione parziale quasi inutile. Le route leak mostrano il movimento più incoraggiante: gli oggetti Autonomous System Provider Authorization (ASPA), che consentono alle reti di elencare i loro provider upstream legittimi, sono pubblicabili nei repository dei Regional Internet Registry dal dicembre 2025, con 1.314 registrati al momento della scrittura. L'analisi suggerisce che la distribuzione da parte di AS strategicamente posizionati potrebbe ridurre il numero di AS colpiti dalle leak fino al 96%. L'attributo Only to Customer (OTC) e la community Down Only, entrambi basati sui ruoli definiti nella RFC 9234, potrebbero sopprimere oltre il 98% delle leak multi-hop se adottati selettivamente attraverso reti Tier-1 e Tier-2 ben connesse.

In netto contrasto, le restanti quattro classi, volatilità dello stato, deaggregazione del prefisso, manipolazione delle policy e reset di sessione basato su attributi, non hanno alcuna risposta crittografica. Non una parzialmente implementata, nessuna. Sono affrontate solo con indurimento operativo, control-plane policing, limiti di max-prefix, filtri sulla lunghezza del prefisso, igiene delle policy, gestione robusta degli errori e filtraggio degli attributi nei route server. Tutte queste sono locali, reattive e non verificabili dalla parte che subisce le conseguenze. Non esiste un equivalente del controllo di una ROA e del rilascio degli annunci non validi, e non esiste uno stato globale che si possa interrogare. Quando un operatore chiede se è protetto contro un fragmentation flood da un peer, la risposta onesta è che ha un limite di max-prefix e una speranza.

Due cambiamenti hanno reso queste classi scoperte più importanti di quanto non fossero. Il primo è l'aritmetica IPv6. Un blocco di indirizzi IPv6, il più recente e molto più grande schema di indirizzamento internet, può essere suddiviso in modo molto più aggressivo rispetto a IPv4. All'interno di una singola allocazione /29, fino a 524.288 blocchi /48 distinti possono essere generati e annunciati. La tabella BGP IPv6 globale contiene attualmente circa 219.000 voci. Una allocazione, un router, e la tabella più che raddoppia. La difesa, una soglia statica di max-prefix, rompe anche la crescita legittima se impostata troppo stretta, ed è proprio per questo che gli operatori la impostano in modo lasco. Il secondo cambiamento è che il successo parziale della validazione dell'origine ridistribuisce l'attenzione degli attaccanti. Man mano che l'enforcement della ROV cresce, il ritorno sul dirottamento di un prefisso diminuisce, mentre il ritorno sulle classi che nessuno valida aumenta. Questa non è un'affermazione sulle intenzioni di nessuno; è l'economia ordinaria di un controllo che copre bene una cosa.

Rivedendo le questioni aperte del 2011, quattro rimangono vive. Primo, può una parte che fa affidamento validare non solo che l'AS_PATH in un aggiornamento corrisponda al percorso che l'annuncio ha viaggiato, ma che lo stato effettivo di inoltro della rete sia allineato con esso? I meccanismi di validazione del percorso, inclusi ASPA e BGPsec, proteggono il control plane, la parte della rete che decide dove il traffico dovrebbe andare, ma non dicono nulla su dove i pacchetti effettivamente vanno. Proposte come FC-BGP e SBAS tentano di colmare questo divario, ma entrambe rimangono sperimentali. Questo è il problema aperto tecnicamente più difficile nel campo. Secondo, se un framework completo si sta dimostrando non implementabile, può uno meno completo produrre risultati accettabili? L'evidenza dice sì, ma l'efficacia dipende dalla policy dell'operatore. Un sondaggio su 100 operatori ha rilevato che la validazione parziale del percorso protegge bene quando le policy preferiscono rotte sicure, e molto meno quando preferiscono rotte brevi. La distribuzione parziale dovrebbe essere l'assunzione di base per i nuovi progetti, non il caso degradato. Terzo, migliorare ciò che già esiste: il costo computazionale non è più l'ostacolo principale, ma la complessità operativa lo è. Gestire ROA, record IRR, relazioni ASPA e certificati è un onere reale, sproporzionatamente per le reti più piccole con personale limitato. Proposte come le Signed Prefix Lists, che sostituiscono il maxLength permissivo con l'enumerazione esplicita degli annunci previsti, sono interessanti proprio perché scambiano un po' più di manutenzione per molta meno ambiguità. Quarto, strumenti ausiliari. Dato che la sicurezza a livello di protocollo è incompleta e rimarrà incompleta, il monitoraggio e la valutazione del rischio hanno più peso. Strumenti come ARTEMIS, ROSE-T, sistemi di rilevamento dei cambi di origine e scoring del rischio derivato dalle Routing Information Bases (RIB) dei route server IXP forniscono valore senza richiedere modifiche a BGP o coordinamento tra AS. La loro efficacia, però, dipende interamente dalla qualità dei record IRR, dei repository RPKI e dei dati sulle relazioni AS, che sono mantenuti in modo incoerente. Migliorare questi dataset è un prerequisito per tutto il resto.

Tre osservazioni tagliano trasversalmente tutto questo. Implementabile batte ottimale, costantemente: S-BGP, soBGP e psBGP offrivano garanzie più forti di qualsiasi cosa implementata oggi e non sono andati da nessuna parte, mentre RPKI, IRR e ora ASPA hanno guadagnato trazione perché possono essere adottati in modo incrementale. L'adozione universale non è un'assunzione realistica, e i progetti che la richiedono hanno una scarsa track record. I costi sono individuali e i benefici sono collettivi, un classico problema di azione collettiva, ed è per questo che i meccanismi ben progettati si bloccano. È qui che contano le leve istituzionali, come la direttiva NIS2 dell'Unione Europea, la proposta di Digital Networks Act e le strategie nazionali, anche se la loro efficacia dipende dall'enforcement e dal monitoraggio della conformità che rimane disomogeneo tra le giurisdizioni.

Gli autori invitano anche al dissenso. La parte di cui sono meno sicuri è il confine tra attacco e incidente. Quasi ogni incidente nelle classi scoperte ha una spiegazione innocente disponibile: una redistribuzione mal configurata, uno script eseguito due volte, un bug del vendor. Questa ambiguità è esattamente il motivo per cui queste classi sono sotto-studiate, ma potrebbe anche significare che il rischio è sovrastimato. Gli autori preferirebbero essere corretti dagli operatori di rete piuttosto che avere ragione in una rivista. Se l'esperienza operativa dice che il limite di max-prefix va bene, o che la conformità alla RFC 7606 è ora sufficiente, questa è la conversazione che sperano di iniziare.

Per le organizzazioni che gestiscono la propria infrastruttura di rete, tradurre questi risultati in azione spesso significa lavorare con una consulenza IT e infrastrutturale orientata alla sicurezza come AEU-I, che può aiutare a valutare i controlli di sicurezza del routing come la validazione RPKI e il filtraggio dei prefissi prima che un incidente esponga le lacune. Lo studio, 'Survey on Internet Routing Security: Stakeholder Interests, Current and Future Research Directions', è in accesso aperto con licenza CC BY 4.0 su IEEE Communications Surveys & Tutorials, DOI: 10.1109/COMST.2026.3714569. È una collaborazione tra l'Università Sapienza di Roma, Namex (Rome IXP) e l'Agenzia per la Cybersicurezza Nazionale (ACN). Flavio Luciani è Chief Technology Officer di Namex e co-autore del libro 'BGP: from theory to practice'.