L'esperimento che ha scoperto una riscrittura silenziosa

Il 24 luglio due ingegneri di Cloudflare hanno pubblicato il risultato di un esperimento deliberatamente rumoroso. Iliana Xygkou e Bryton Herdes hanno annunciato prefissi IPv4 e IPv6 dalla rete di Cloudflare, AS13335, ciascuno con un valore diverso in un vecchio campo BGP chiamato ORIGIN. Hanno poi ritirato i prefissi per costringere internet alla ricerca dei percorsi, hanno letto con lo strumento BGPKIT quello che tornava dai collettori RIPE RIS e RouteViews e dai flussi BMP di Cloudflare, e hanno confrontato il valore inviato con quello che vedeva il resto del mondo.

I valori non corrispondevano. ORIGIN è uno degli attributi più antichi di BGP e registra come una rotta è entrata nel protocollo: IGP, EGP o INCOMPLETE, in quest'ordine di preferenza. Circa il 70% dei percorsi IPv4 osservati, e il 67% di quelli IPv6, sono arrivati con ORIGIN riportato a IGP, il valore con la precedenza più alta. Circa il 10% dei loro 352 peer IPv4 diretti effettuava la riscrittura, con una quota simile su 315 peer IPv6.

Il meccanismo spiega il motivo. ORIGIN viene consultato nella selezione del percorso migliore quando due rotte pareggiano su Local Preference e sulla lunghezza dell'AS_PATH, e vince il valore di ORIGIN più basso. Riscriverlo su IGP porta un percorso davanti ai concorrenti senza toccare l'AS_PATH, cioè il campo che tutti guardano. Oggi l'89,8% delle rotte porta IGP, il 3,5% EGP e il 6,7% INCOMPLETE, una distribuzione che sembra ordinata soprattutto perché gran parte di essa viene fabbricata durante il transito.

I numeri puntano sulle reti più grandi

La cosa interessante non è la diffusione, ma la concentrazione. Cloudflare ha trovato che il 26% dei 50 sistemi autonomi più grandi secondo AS Rank manipola ORIGIN, insieme al 20% dei primi 100, e che il 20,3% di tutte le reti che riscrivono sta dentro quei primi 50. Sei delle sedici reti Tier-1 lo fanno. Le reti con la maggiore capacità di tirare traffico sui propri percorsi sono in modo sproporzionato quelle che forzano il campo che decide i casi in bilico.

Un dettaglio appare commerciale e non accidentale. Una singola rete Tier-1 riscrive ORIGIN sulle rotte che impara dai peer e conserva il valore su quelle che impara dai clienti. Non è la firma di un modello di configurazione dimenticato su un router: è una regola che tratta in modo diverso il traffico di transito pagato e quello di peering gratuito.

Il vantaggio è stato misurabile nel test stesso. Le reti che riscrivevano hanno guadagnato 12 percorsi IPv4 aggiuntivi attraverso se stesse, un aumento del 18%, e 33 percorsi IPv6 aggiuntivi, un aumento del 40%. È tutto qui: la riscrittura di un solo attributo, invisibile alla rete che lo aveva impostato, ha spostato una quota rilevante dei percorsi candidati verso chi riscriveva.

La valutazione di Cloudflare è netta. Non ha trovato alcuna giustificazione tecnica valida per la pratica e indica due danni: le reti che rispettano la RFC vengono penalizzate rispetto a quelle che non la rispettano, e il traffico viene allontanato da operatori alternativi che altrimenti avrebbero vinto lo spareggio. La proposta è togliere del tutto all'attributo l'influenza sulla selezione delle rotte, iniziando dalle implementazioni che impostano su IGP ogni rotta ricevuta e annunciata.

Dove una tesi di resilienza cade in silenzio

La conseguenza operativa non riguarda davvero ORIGIN, ma che cosa dimostra la frase "siamo collegati a più operatori". Avere più operatori vi dà più di una via fisica verso l'esterno, e quella parte è reale. Non vi dà il controllo sulla via per cui il traffico torna davvero a voi, perché quasi tutti gli attributi che esprimono preferenza sono solo indicativi appena superano il vostro confine. La Local Preference è l'eccezione che conta: la impostate sui vostri router, sta sopra ORIGIN nell'ordine di decisione e non attraversa mai un confine eBGP, e proprio per questo è l'unica preferenza che nessun altro può sovrascrivere.

Questa distinzione conta ormai anche per iscritto. Con la NIS2 la resilienza di rete è qualcosa che si documenta e non che si dichiara, e la diversità dei percorsi è tra le cose più facili da dichiarare in un questionario per fornitori. Se una singola rete centrale può portare su di sé una quota misurabile dei percorsi candidati riscrivendo un attributo, allora una dichiarazione di diversità costruita sugli annunci, e non sui contratti e sulla Local Preference, è una dichiarazione che non riuscirete a sostenere quando qualcuno la verificherà.

Anche la direzione della standardizzazione dovrebbe accorciare la vostra attesa. Una bozza IETF intitolata "Scrubbing BGP ORIGIN Attribute", pubblicata il 3 novembre 2025, aggiorna le RFC 4271 e RFC 7606 per rendere l'attributo semi-opzionale e permettere esplicitamente di riportarlo a IGP. La sua stessa misurazione della default-free zone a settembre 2025 ha trovato circa il 9% delle rotte con INCOMPLETE e meno dell'1% con EGP. Leggete la direzione con onestà: il processo di standardizzazione va verso la legittimazione della riscrittura invece del suo controllo, quindi il comportamento non verrà corretto per voi.

Tre verifiche prima del prossimo rinnovo di transito

Fate la domanda a cui la misurazione permette di rispondere. Primo: chiedete per iscritto a ogni operatore di transito che cosa fa agli attributi BGP dei vostri annunci e se tratta in modo diverso le rotte apprese dai peer e quelle apprese dai clienti. Secondo: smettete di usare ORIGIN come segnale di instradamento in qualsiasi punto della vostra policy, perché la misurazione mostra che non sopravvive ai primi hop. Terzo: spostate l'espressione reale della vostra preferenza sulla Local Preference al vostro confine e su community di cui abbiate confermato il rispetto presso l'operatore, e poi verificatelo invece di darlo per scontato.

Poi date un prezzo alla risposta. In Europa i contratti di transito si quotano quasi sempre in euro per Mbps impegnato, e in sterline nel Regno Unito, e il trattamento delle rotte non vi compare quasi mai. Se pagate un sovrapprezzo per un secondo o terzo operatore proprio per mantenere la diversità dei percorsi, quella diversità va scritta nel contratto come impegno sul trattamento delle rotte. Un operatore che non vuole dire che cosa fa ai vostri attributi vi ha già detto qualcosa di utile su quali percorsi vi appartengono davvero.

Da leggere ora: Un solo messaggio ha raggiunto le chiavi SSH  |  Un'IA di prova ha violato un'azienda per copiare