Aquesta tarda, l'observatori públic d'encaminament de Cloudflare veia 1.445.943 rutes a la taula global de BGP. D'aquestes, 1.016.683 —el 70,31%— duien signatura RPKI vàlida. I 15.300 estaven cobertes per una signatura que deia just el contrari: invàlides, i allà seguien, visibles des de 79 punts d'observació. Aquest número petit resumeix l'estat real de l'encaminament millor que qualsevol percentatge d'adopció: signar és fàcil, validar és una altra cosa, i cap de les dues frena el segrest que de debò s'utilitza.
Escrivim això des del costat de qui sessiona BGP cada dia: operem xarxa pròpia amb trànsit i peering, i publiquem un looking glass obert a lg.everywan.com precisament perquè qualsevol pugui mirar què veiem i què anunciem. Amb aquesta perspectiva, la frase que més se sent a les reunions —«tranquil, ja tenim RPKI»— no és mentida, però està incompleta d'una manera perillosa. Un ROA signa qui pot originar un prefix. No signa per on viatja el trànsit, ni qui tenia dret a passar-te'l.
Què diu un ROA exactament (i què calla)
Un ROA és una afirmació signada amb tres camps: aquest prefix, aquest número de sistema autònom com a origen, i fins a aquesta longitud. El router compara l'anunci amb la signatura i li posa una etiqueta —vàlid, invàlid o no trobat— segons l'RFC 6811. El que decideixi fer amb aquesta etiqueta ja és política local, i aquí comencen els problemes. Tres coses que un ROA no cobreix i convé tenir presents:
- 1No diu res de l'
AS_PATH. La llista de sistemes pels quals ha passat l'anunci és un camp més del missatge, escrit per qui el propaga. Ningú no el signa. La validació d'origen mira l'últim element d'aquesta llista i dona per bona la resta. - 2No diu res de la política comercial. Que un anunci sigui criptogràficament correcte no vol dir que aquell veí tingués dret a reenviar-te'l. Una fuita de ruta està formada per anuncis perfectament vàlids que van on no havien d'anar.
- 3El
maxLengthgenerós juga en contra teva. Si signes un /20 amb longitud màxima /24, estàs declarant legítims anuncis més específics que tu no fas —i el més específic guanya en BGP—. Per això l'RFC 9319, que és Best Current Practice (BCP 185) des d'octubre de 2022, recomana no fer servirmaxLengthtret de casos concrets. És l'error de configuració més comú i el més silenciós.
El segrest que passa la validació en verd
Aquí hi ha el punt que trenca la tranquil·litat. Un atacant que vol el teu prefix no lluita contra el teu ROA: el copia. Anuncia el teu prefix posant el teu número de sistema autònom a la posició d'origen i col·locant el seu al davant, com si fos el veí que et dona trànsit. El router que rep això fa la seva validació d'origen, comprova l'origen de l'AS_PATH contra el teu ROA, i li surt vàlid. El semàfor es posa verd per a un anunci que no has fet tu. Quant trànsit se n'endú ja no depèn de la criptografia sinó de la geografia de l'assumpte: es queda amb el de les xarxes per a les quals el seu camí resulti preferible, o amb el de totes si a més anuncia un prefix més específic que el teu.
I la peça que signaria el camí sencer? Existeix sobre el paper —BGPsec— i continua sense desplegar-se, per un motiu que resumeix bé l'anàlisi publicada a RIPE Labs el 21 de juliol de 2026: n'hi ha prou que un sol sistema del camí no l'implementi perquè la informació de seguretat desaparegui. Una cadena que necessita que totes les baules existeixin, en una xarxa de més de cent mil actors independents, és una cadena que no es tanca. Mentrestant, l'atac costa el que costa una línia de configuració en un router.
El comptador d'avui, amb la seva lletra petita
Vam consultar l'API pública de Cloudflare Radar mentre escrivíem això, i els comptadors no deixen gaire marge a la interpretació: 3.188 esdeveniments de conflicte d'origen —el que Radar etiqueta com a segrest— en els últims 30 dies, i 6.537 fuites de ruta en el mateix període. En les últimes 24 hores, 88 i 515 respectivament. A això s'hi sumen 413.960 rutes sense ROA, el 28,6% de la taula: ni vàlides ni invàlides, senzillament sense signar. Gairebé un terç d'internet encara no ha arribat al punt de partida.
I ara el matís, que és la meitat del valor de qualsevol número: la majoria d'aquests esdeveniments no són atacs. Són deteccions automàtiques de conflictes d'origen i d'anuncis que van on no toca, i darrere de gairebé tots hi ha un dit gros, una desagregació mal pensada, un filtre que no hi era o un laboratori que es va escapar a producció. Qui ho llegeixi com «hi ha més de tres mil ciberatacs al mes contra l'encaminament» està exagerant. Però el consol dura poc, perquè la lectura correcta incomoda igual: si un error de configuració d'un desconegut pot desviar trànsit aliè fins que algú se n'adona, qui ho faci expressament aconsegueix el mateix amb menys soroll. La diferència entre l'accident i l'atac és la intenció, no la dificultat.
Les quatre famílies que ningú no valida
El treball de RIPE Labs que citàvem ordena els atacs a l'encaminament en quatre grans categories. Val la pena llegir-les seguides, perquè ensenyen d'un cop d'ull fins on arriba la criptografia i on no:
- 1Manipulació de ruta: canvis no autoritzats del prefix o del camí, inclosos els segrestos i les variants de manipulació de l'
AS_PATH. És l'única família on la validació d'origen aporta alguna cosa, i només en part. - 2Consistència de l'encaminament: no ataquen el contingut de la taula, sinó la seva estabilitat. Flapping, inundació d'anuncis, desagregació massiva. Res d'això és invàlid; senzillament fa mal.
- 3Violació de política: les fuites de ruta —l'RFC 7908 classifica sis tipus, des del client que reenvia a un proveïdor allò que li arriba d'un altre fins a l'escapada accidental de prefixos interns—, més la manipulació de política via local preference, MED, longitud artificial del camí o propagació selectiva. Anuncis legítims, destinacions equivocades.
- 4Atacs a la sessió: atributs opcionals transitius mal formats que provoquen reinicis de sessió, errors específics d'un fabricant, abús de les polítiques de gestió d'errors. Aquí la signatura de l'anunci és irrellevant: l'objectiu és la conversa, no el contingut.
I la dada que ordena tot això, de la mateixa anàlisi, mesurada en un estudi longitudinal sobre més de 28.000 sistemes autònoms: el 36,2% no implementa validació d'origen en absolut, i només el 12,3% aconsegueix protecció completa a les seves rutes. Llegeix-ho al costat del 70,31% de rutes signades del principi i veuràs l'escletxa: la comunitat ha signat set de cada deu rutes i valida del tot poc més d'una de cada deu xarxes. Signar és un tràmit administratiu que es fa un cop al panell del RIR. Validar és tocar la configuració de tots els teus routers i assumir que, si t'equivoques, tu mateix et quedes sense veure mig internet. Per això una xifra puja i l'altra no.
La llista amb què revisem una xarxa
No hi ha bala de plata, hi ha set coses avorrides que fan gairebé tota la feina. Aquest és el criteri amb què revisem una xarxa i el que demanem a un trànsit abans de signar res:
- →ROAs ajustats, sense
maxLengthper comoditat. Un ROA pel que anuncies de debò. Si necessites anunciar més específics, se signa el que s'anuncia, no un rang per si de cas. - →Descartar les invàlides, no «marcar-les i seguir». Etiquetar una ruta com a invàlida i acceptar-la igualment és tenir el detector de fums desconnectat del timbre.
- →Filtres d'entrada per client i per peer, generats des de l'inventari i no escrits a mà. Objectes IRR coherents amb els ROAs: si el registre diu una cosa i la signatura una altra, algú filtrarà malament.
- →Límit de prefixos amb llindar i acció a cada sessió. És el que evita que l'error de l'altre costat es converteixi en el teu incident a les tres de la matinada.
- →Rols BGP de l'RFC 9234 on l'altre extrem els suporti: el mateix protocol marca el que no ha de sortir del client al proveïdor i detecta la fuita tota sola, sense dependre que ningú es recordi d'un filtre.
- →Mirar el camí real, no l'estat de l'enllaç. Un segrest no tomba cap interfície: l'enllaç continua verd mentre el trànsit se'n va per on no toca. Això es veu amb anàlisi de fluxos i amb un looking glass, no amb un ping.
- →Una font de veritat, no tres. El que anuncies, el que signes i el que filtres han de sortir del mateix inventari, pel mateix motiu que explicàvem parlant de NetBox com a font de veritat de la xarxa: quan la documentació i la realitat se separen, la que mana és la realitat i ningú no se n'assabenta.
El car no és cap de les set: el car és que ningú no tingui l'encàrrec de revisar-les cada trimestre, que és on es podreixen. I el patró de fons és el mateix que ja vam explicar amb els atacs de denegació de servei: la caixa del rack no salva el teu enllaç perquè el problema passa aigües amunt, fora del teu perímetre. Amb l'encaminament passa igual: el que decideix si et segresten no és al teu tallafocs, és a la política dels veïns dels teus veïns.
Si no tens AS propi (que és el normal)
La immensa majoria de les empreses no parla BGP amb ningú, i no cal que ho faci. La seva palanca no és tècnica: és la conversa amb qui li dona la connectivitat. Hi ha una pregunta que val per totes les altres i es contesta en un correu: «descarteu les rutes RPKI invàlides o només les marqueu?». Si la resposta és que les marquen i les accepten igualment, ja saps què hi ha; i si és que les descarten, es pot comprovar des de fora. La segona, per a qui tingui adreces independents del proveïdor, és igual d'incòmoda: qui manté aquest ROA, amb quina longitud màxima, i qui el revisa el dia que canviïs d'operador? Aquest objecte sobreviu als contractes, i hem vist massa signatures apuntant a un sistema autònom que ja no dona servei a ningú.
ASPA: la peça que falta, i el seu matís honest
La resposta que s'està construint per al que RPKI no cobreix es diu ASPA: cada titular d'un sistema autònom declara, signat, qui són els seus proveïdors. Amb aquesta informació, un camí que passa per on no hauria de passar deixa de ser una sospita i passa a ser comprovable. Els objectes són publicables als repositoris dels registres regionals des de desembre de 2025, i l'anàlisi de RIPE Labs estima que un desplegament en sistemes estratègicament situats podria reduir fins a un 96% el nombre de sistemes autònoms afectats per les fuites —que no és el mateix que reduir les fuites—.
I ara la part que no surt a les presentacions: aquesta mateixa anàlisi comptava 1.314 objectes ASPA registrats. No són xifres directament comparables —una compta objectes publicats als repositoris i l'altra sistemes vistos anunciant—, però posades al costat surt l'ordre de magnitud de l'assumpte: 1.314 davant dels 116.353 orígens diferents que Radar veia avui a la taula global. És la direcció correcta, és barat de publicar i val la pena fer-ho. Però si algú et ven avui que ASPA et protegeix, t'està venent un desplegament que encara no existeix. Publica el teu pel que suma al conjunt, no perquè dormiràs millor aquesta nit.
L'últim mite: que això va amb tu
Hi ha un mite simètric al del principi, i també convé desmuntar-lo: el que diu que, després de llegir tot això, cal sortir corrents a muntar alguna cosa. Si les teves adreces te les dona l'operador, si no tens sistema autònom i si la teva connectivitat és una fibra amb un router del proveïdor, res d'això és una tasca teva. No muntis un validador ni demanis un AS «per seguretat»: la teva palanca és la conversa de dalt i el contracte. I si tens un /24 i un número de sistema autònom perquè un dia va semblar bona idea, però un sol trànsit i ningú que miri la taula, el teu risc real no és el segrest sofisticat: és que el dia que passi alguna cosa no hi haurà ningú de guàrdia que sàpiga on mirar. Això també s'ha de dir.
El que sí que pots fer
L'encaminament d'internet funciona perquè desenes de milers de desconeguts es creuen el que es diuen entre ells. RPKI no canvia això: només ha convertit una part d'aquesta confiança en una cosa comprovable. És molt i és poc alhora. Signar els teus prefixos amb criteri, descartar de debò l'invàlid, filtrar els teus veïns i mirar per on va el trànsit no impedeix l'atac, però escurça moltíssim l'estona en què ningú no se n'assabenta. I en encaminament, aquesta estona és tot el que hi ha.
Si vols que mirem com està la teva connectivitat —què s'anuncia en nom teu, què filtra el teu proveïdor i què passaria un diumenge—, això és part del que fem a xarxes i comunicacions.
Fonts (verificades): les xifres de la taula global de BGP i d'esdeveniments provenen de l'API pública de Cloudflare Radar, consultada per nosaltres el 6 d'agost de 2026 a les 15:30 UTC (79 punts d'observació): 1.445.943 rutes, 1.016.683 vàlides (70,31%), 413.960 sense ROA (28,6%), 15.300 invàlides, 116.353 orígens diferents; 3.188 esdeveniments de segrest i 6.537 fuites de ruta en 30 dies, i 88 i 515 respectivament en 24 hores. Són comptadors vius: es mouen entre consultes, així que les xifres valen per al moment en què les vam prendre, no per sempre. A més, els esdeveniments que Radar etiqueta com a segrest són deteccions automàtiques de conflictes d'origen: inclouen errors de configuració i no equivalen a atacs confirmats, i així ho hem escrit al post. El repartiment d'atacs en quatre famílies, les xifres de validació d'origen (36,2% de sistemes sense ROV i 12,3% amb protecció completa, mesurades en un estudi longitudinal sobre més de 28.000 sistemes autònoms), l'estat de BGPsec, la publicabilitat d'ASPA des de desembre de 2025, els 1.314 objectes registrats i l'estimació de reducció del nombre de sistemes afectats per fuites provenen de l'anàlisi d'Antonio Prado publicada a RIPE Labs el 21 de juliol de 2026. Els estàndards citats són l'RFC 6811 (validació d'origen de prefixos BGP), l'RFC 7908 (definició i classificació de les fuites de ruta, que en descriu sis tipus), l'RFC 9319 / BCP 185 (ús de maxLength a la RPKI, octubre de 2022) i l'RFC 9234 (prevenció i detecció de fuites mitjançant rols). Fotografia de la imatge social: vista aèria de l'enllaç entre les autopistes 401, 403 i 410 d'Ontàrio, de Coolcaesar, Wikimedia Commons, llicència CC BY 4.0.
Saps què s'anuncia avui en nom teu?
A everyWAN operem xarxa pròpia amb trànsit i peering, i portem la connectivitat d'empreses que no volen assabentar-se'n un diumenge. Si no saps qui manté els teus ROAs ni què filtra el teu proveïdor, comencem per aquí.
Parlar amb everyWAN