Filtración de rutas de Telekom Malaysia en 2015

Resumen

Monitoreo independiente sitúa el inicio de una gran ráfaga de anuncios BGP desde AS4788 de Telekom Malaysia alrededor de las 08:43 UTC del 12 de junio de 2015. BGPMon informó aproximadamente 179 000 prefijos anunciados, mientras que RFC 7908 citó posteriormente el evento como un ejemplo importante de fuga de rutas en el que Level 3 aceptó y propagó unos 179 000 prefijos. [2][10]
Diferentes análisis reportan diferentes recuentos de rutas porque utilizan distintos colectores, ventanas de tiempo y definiciones. El análisis de Geoff Huston discutió aproximadamente 2500 rutas recién visibles y examinó un conjunto de 22 577 rutas afectadas. Estas cifras no pueden fusionarse responsablemente en una sola precisión falsa. [1][2]
AS3549 de Level 3 no solo observó los anuncios de AS4788: los aceptó y propagó, extendiendo el radio de explosión a través de una importante red de tránsito global. ThousandEyes midió pérdida severa de paquetes y rutas terminales en múltiples puntos de presencia de Level 3. [2][3]
La evidencia respalda una fuga de política de relación: las rutas aprendidas de pares parecen haber sido reanunciadas a proveedores de tránsito ascendentes. La configuración exacta del router de Telekom Malaysia, el route-map, el comando, el software y la cadena de aprobación no son públicos en este paquete. [1]
La responsabilidad está dividida por control. AS4788 controló su política de exportación y el ciclo de vida del route-map. AS3549 controló lo que aceptaba de un cliente, los controles de volumen y ruta aplicados, y si las rutas aceptadas eran propagadas. Las redes aguas abajo controlaban su propia política de importación y monitoreo.
La Validación de Origen RPKI ordinaria no es una respuesta completa a este evento. La mayoría de las rutas filtradas conservaban orígenes legítimos. La autorización de origen puede ser válida mientras que la ruta viola la intención de exportación del cliente, par o proveedor. [1][15][16]
Estándares posteriores aclaran controles posibles. RFC 8212 hace explícita la política de importación y exportación como requisito predeterminado para eBGP, mientras que RFC 9234 añade Roles BGP conscientes de la relación y el atributo Only to Customer. Son guía de control retrospectiva, no prueba de una violación de cumplimiento en 2015. [11][12]
Una reclamación de reparación creíble requiere más que restauración. Necesita una reconstrucción congelada del conjunto de anuncios, la política de sesión prevista, evidencia de configuración antes y después, pruebas contra la misma clase de fuga, observación independiente de rutas y prueba de que tanto el lado exportador como el receptor pueden contener la recurrencia.

Un anuncio de ruta se convirtió en autoridad sobre el tráfico de otras personas

BGP se presenta a menudo como el protocolo que le dice a Internet dónde están las redes. Esa descripción es precisa pero incompleta. Un anuncio BGP es también una reclamación de autoridad operativa.

Cuando un sistema autónomo le dice a otro que un prefijo es alcanzable a través de él, el destinatario puede preferir esa ruta y anunciarla. Otras redes pueden entonces dirigir el tráfico hacia la ruta anunciada. La ruta no lleva garantía de que la red anunciante tenga suficiente capacidad, de que la ruta se ajuste a las relaciones comerciales, o de que cada operador intermedio tuviera la intención de proporcionar tránsito. BGP distribuye información de accesibilidad y datos de AS-path; la política determina qué reclamaciones acepta y repite una red. [8]

Esa capa de política es donde el evento de 2015 de Telekom Malaysia se volvió globalmente consecuente.

Fuentes independientes dicen que una gran ráfaga de anuncios comenzó alrededor de las 08:43 UTC del 12 de junio. AS4788 de Telekom Malaysia anunció un enorme conjunto de rutas a AS3549 de Level 3. Level 3 aceptó esas rutas y las propagó a pares y clientes. El tráfico siguió las rutas cambiadas. La ruta a través de AS3549 y AS4788 podía parecer atractiva bajo la política de enrutamiento aunque las interconexiones no pudieran transportar de manera segura el volumen resultante.

La pérdida de paquetes y la latencia aumentaron, y servicios mucho más allá de la propia base de clientes de Telekom Malaysia se volvieron difíciles o imposibles de alcanzar. [2][3]

El evento no fue un certificado falsificado, un compromiso de un nombre de dominio, o un origen de ruta fabricado en el sentido más simple. Muchos prefijos afectados aún terminaban en sus sistemas autónomos de origen legítimo. El cambio dañino fue que AS4788 se insertó como tránsito para rutas que no se esperaba que exportara en esa dirección. Una ruta puede ser sintácticamente válida, libre de bucles y válida en origen mientras viola la relación económica y operativa bajo la cual fue aprendida.

Esta distinción importa para la responsabilidad. Si el problema se describe solo como «Telekom Malaysia filtró rutas», la responsabilidad parece terminar en la red exportadora. Pero la propagación BGP es bilateral en cada sesión. Un lado anuncia; el otro decide qué aceptar, preferir y anunciar. Una gran red de tránsito tiene un mayor poder de propagación que un cliente aislado. Ese poder crea un correspondiente deber de filtrado y evidencia.

La pregunta central no es qué operador cometió primero el error. Es cuántos controles independientes tenían la capacidad práctica de detener el error antes de que se convirtiera en la interrupción de otras redes.

La cronología es clara en los bordes e incompleta dentro de las redes

BGPMon informó que AS4788 comenzó a anunciar un conjunto masivo de rutas a las 08:43 UTC. Su monitoreo vio un aumento brusco en los mensajes de actualización BGP al mismo tiempo que comenzaba la pérdida de paquetes. El análisis describió aproximadamente 179 000 prefijos anunciados y dio un prefijo afectado de Facebook como ejemplo de una ruta que pasaba por AS3549 y AS4788 antes de llegar al origen legítimo. [2]

ThousandEyes describió independientemente la misma secuencia general. Observó nuevas rutas a través de Telekom Malaysia y Level 3, pérdida severa de paquetes, y rutas terminales en ubicaciones como Ámsterdam, Chicago, Fráncfort, Londres, Los Ángeles, Seattle y Washington. Dijo que Level 3 dejó de aceptar las rutas alrededor de las 10:45 UTC y el servicio comenzó a normalizarse. [3]

BGPMon reportó una mejora alrededor de las 10:40 y una limpieza más amplia alrededor de las 11:15. Esos tiempos deben permanecer atribuidos. Un colector de rutas, una plataforma de medición activa, un operador de tránsito y un usuario final no observan el mismo evento en el mismo instante. Un filtro puede detener nuevos anuncios mientras rutas obsoletas permanecen seleccionadas en otro lugar. Las retiradas pueden propagarse de manera desigual. La congestión puede persistir después de eliminar el desencadenante del plano de control. La recuperación es por tanto una secuencia, no una marca de tiempo universal.

El análisis de RIPE Atlas utilizó posteriormente el evento para examinar cómo las grandes fallas en la infraestructura central afectan la conectividad de extremo a extremo. Encontró evidencia tanto de tráfico enrutado alrededor de infraestructura bajo estrés como de fallas de extremo a extremo. Los autores fueron explícitos sobre la representatividad: incluso un sistema de medición global diverso observa solo un conjunto finito de rutas y destinos. [4]

La cronología pública tiene un registro externo sólido y un registro interno débil.

Los observadores externos pueden identificar el inicio aproximado, las rutas que cambiaron, el volumen de actualizaciones de ruta, la pérdida de paquetes, la latencia y la recuperación general. No pueden ver el route-map privado, el terminal del operador, el cambio aprobado, el límite de prefijos configurado, la cola de alertas, o la conversación de decisión entre Telekom Malaysia y Level 3.

Esa brecha debe dar forma al lenguaje del artículo.

Es defendible decir que AS4788 emitió las rutas, AS3549 las aceptó y propagó, y la accesibilidad global se vio afectada. Es defendible decir que el patrón es consistente con rutas aprendidas de pares siendo exportadas hacia un proveedor ascendente. No es defendible identificar el comando exacto, router, empleado, ticket de cambio o defecto de software sin un registro de operador autenticado.

El análisis de Geoff Huston utiliza un lenguaje probabilístico sobre una falla de política de ruta y contiene variantes tipográficas aparentes de números AS en algunos pasajes. La red de Telekom Malaysia es AS4788. El artículo no debe convertir referencias aparentes a AS4877 o AS4778 en actores adicionales ni usarlas para fabricar certeza sobre un dispositivo interno. [1]

Un registro de responsabilidad completo conectaría la cronología externa con evidencia interna:

la última política de exportación conocida como buena;
el cambio propuesto y normalizado;
la hora en que cada router o sesión lo recibió;
el número y tipo de prefijos seleccionados para exportación;
alertas por volumen de rutas y violaciones de relación;
estado de aceptación y máximo de prefijos en AS3549;
contactos y mensajes de escalada;
el comando o acción automatizada que detuvo la propagación;
evidencia del colector mostrando retirada y convergencia;
pruebas que demuestren que la política reparada rechaza la misma clase de ruta.

Sin esa cadena, la restauración es visible pero el aprendizaje institucional sigue siendo difícil de verificar.

Los recuentos de prefijos describen diferentes vistas, no un hecho disputado

Los grandes incidentes de Internet atraen un número memorable único. Aquí, ese instinto puede hacer que el registro sea menos preciso.

BGPMon escribió que AS4788 comenzó a anunciar alrededor de 179 000 prefijos y luego se refirió a aproximadamente 176 000 prefijos filtrados. RFC 7908 cita la «filtración masiva de rutas de Telekom Malaysia» de alrededor de 179 000 prefijos. ThousandEyes describió una gran porción de la tabla de enrutamiento global. [2][3][10]

El análisis de Huston utilizó diferentes vistas del evento. Mostró un cambio neto en la tabla de enrutamiento que involucra miles de rutas recién visibles y retiradas, luego examinó 22 577 rutas en un conjunto afectado específico. [1]

Estas cifras pueden coexistir porque un evento BGP no tiene una sola unidad natural.

Un observador puede contar cada mensaje UPDATE, cada prefijo único anunciado a través de una ruta inesperada, cada prefijo recién visible en un colector, cada mejor ruta cambiada, cada ruta más específica, cada ruta aún presente en un momento seleccionado, o cada origen afectado. Los colectores reciben diferentes feeds. Una ruta puede ser anunciada, retirada y reanunciada. Algunas rutas son visibles en un colector y no en otro. Una tabla completa y un conjunto afectado filtrado responden preguntas diferentes.

La elección editorial responsable es preservar la definición de la medición.

El artículo puede decir que BGPMon y RFC 7908 describieron aproximadamente 179 000 anuncios o prefijos filtrados en sus reconstrucciones. Puede decir que el análisis separado de Huston examinó un conjunto de 22 577 rutas y observó miles de adiciones y retiradas de tabla. No debe promediar los valores, elegir el mayor por dramatismo, o presentar uno como un censo completo del impacto en el usuario.

La misma disciplina se aplica a los servicios afectados. BGPMon y ThousandEyes identificaron ejemplos que involucran grandes plataformas y servicios financieros. Esos ejemplos demuestran el alcance y los efectos colaterales. No establecen que cada prefijo experimentara la misma pérdida de paquetes, que cada servicio se volviera no disponible, o que cada usuario se enrutara a través de AS4788.

Los recuentos se convierten en evidencia de responsabilidad cuando se retienen sus definiciones:

recuento de anunciosprueba si el volumen de exportación fue anómalo;
recuento de prefijos únicosprueba la amplitud de la autoridad de enrutamiento reclamada;
recuento de mejores rutas cambiadasprueba cuántas redes seleccionaron la fuga;
visibilidad del colectorprueba la propagación;
volumen de tráfico y pérdida de paquetesprueba el daño operativo;
recuento de clientes y aplicaciones afectadosprueba el impacto comercial;
duración de la retiradaprueba la contención.

Cada medida debe tener un propietario, un umbral y un registro conservado. Un proveedor de tránsito puede aceptar el conjunto normal de unos pocos miles de prefijos de un cliente pero poner en cuarentena un cambio repentino de orden de magnitud. Un sistema de monitoreo de rutas puede detectar rutas que violan las expectativas del cono del cliente incluso cuando el volumen bruto de prefijos se mantiene por debajo de un límite estático. Un informe post-mortem público puede explicar ambas medidas en lugar de ofrecer un titular total.

La falsa precisión no es solo un problema de redacción. Puede ocultar qué control falló.

La política de relaciones es la estructura invisible detrás de la accesibilidad BGP

Internet no es una malla plana en la que cada sistema autónomo ofrece tránsito gratuito a todos los demás. Las redes compran tránsito, venden tránsito y se interconectan bajo relaciones que dan forma a la política de rutas.

Una regla operativa simplificada funciona así:

las rutas aprendidas de clientes pueden anunciarse a clientes, pares y proveedores;
las rutas aprendidas de pares pueden anunciarse a clientes, pero normalmente no a otro par o proveedor;
las rutas aprendidas de proveedores pueden anunciarse a clientes, pero normalmente no a otro proveedor o par.

Estas reglas producen el modelo familiar «sin valles». Una ruta puede ascender de clientes a proveedores, cruzar como máximo una relación de par, y descender hacia clientes. Una ruta que desciende y luego asciende nuevamente puede indicar que una red está proporcionando tránsito no intencionado. [1][10]

Las relaciones comerciales reales son más complicadas. Dos redes pueden tener roles diferentes en diferentes lugares, familias de direcciones o servicios. El tránsito parcial, la interconexión paga, los servidores de rutas y los arreglos regionales no siempre encajan en una sola etiqueta. Esa complejidad es una razón para documentar y probar la política, no una razón para omitirla.

La reconstrucción de Huston dice que AS4788 parecía recolectar rutas de pares en puntos de intercambio y reanunciarlas a redes de tránsito ascendentes. En ese modelo, las rutas aprendidas lateralmente se exportaban «cuesta arriba». Level 3 luego aceptó y propagó las rutas. [1]

El protocolo en sí mismo no puede inferir cada relación comercial privada a partir de la ruta AS. Una secuencia de números AS legítimos no dice si una ruta estaba contractual y operativamente permitida para viajar a través de ellos. Ese conocimiento debe estar codificado en la política local, objetos de enrutamiento publicados, roles negociados, comunidades, datos de cono del cliente, u otro sistema de validación.

Por eso las fugas de rutas siguen siendo difíciles. Un router puede recibir un UPDATE BGP válido de un vecino autenticado, ver un origen legítimo, construir una ruta AS libre de bucles, y aún aceptar una ruta que viola la relación prevista.

La responsabilidad operativa requiere por tanto que las redes hagan sus expectativas verificables por máquina cuando sea posible:

clasificar cada sesión eBGP y cada política excepcional;
definir los prefijos y rutas de clientes esperados del vecino;
restringir las exportaciones según cómo se aprendieron las rutas;
comparar una política propuesta con la relación prevista;
rechazar o poner en cuarentena la expansión no explicada;
conservar una explicación legible para humanos para las excepciones;
probar la política contra condiciones representativas de tabla completa.

El evento público muestra lo que sucede cuando la intención de la relación permanece implícita o la aplicación es ineficaz. Una ruta puede cruzar una sesión y convertirse en una reclamación global antes de que un humano lea un ticket.

AS4788 controló la exportación, pero AS3549 controló la aceptación y propagación

Telekom Malaysia tenía el control más directo sobre el conjunto de anuncios que salió de AS4788. Una red exportadora debe saber qué rutas originó, cuáles aprendió de clientes, cuáles aprendió de pares o proveedores, y qué clases pueden enviarse a cada vecino.

Ese control comienza antes de la activación de la configuración.

Un cambio debe compilarse en la política real de prefijos y AS-path que un router aplicará. Una revisión debe comparar el resultado con los conos de clientes esperados, recuentos de rutas y reglas de relación. Un entorno de prueba o evaluador fuera de línea debe alimentar rutas representativas a través de la política y mostrar lo que se exportaría. Una verificación independiente debe marcar las rutas aprendidas de pares o proveedores seleccionadas para otra sesión que no sea de cliente.

El registro público no establece si tales controles existían en AS4788, si una configuración de rutina cambió, o si se desencadenó un estado latente. Establece la salida: se exportó un conjunto de rutas grande e inseguro.

El límite de control de Level 3 es separado e igualmente importante para la propagación global.

AS3549 eligió si las rutas recibidas de AS4788 eran elegibles, cómo se preferían, y dónde se anunciaban. Un gran proveedor de tránsito tiene conocimiento específico del cliente que terceros arbitrarios no tienen. Puede conocer el recuento de prefijos esperado, las rutas de clientes registradas, el historial observado, las relaciones de cono del cliente y el propósito de la sesión. Puede aplicar:

política de importación explícita;
listas de prefijos derivadas de datos de enrutamiento autenticados;
restricciones de ruta AS y cono del cliente;
umbrales de máximo de prefijos;
controles de longitud de ruta y bogon;
detección de fugas consciente de relaciones;
política de cuarentena o preferencia reducida para anomalías;
aprobación humana para expansión excepcional.

El relato de BGPMon dice que Level 3 aceptó los anuncios y los anunció a pares y clientes. Las rutas atrajeron tráfico y contribuyeron a la congestión en Level 3 y en las principales ubicaciones de interconexión. [2]

Esto no significa que un proveedor ascendente pueda garantizar que cada ruta de cliente sea correcta. Los filtros estáticos pueden volverse obsoletos. Los clientes multi-homed pueden cambiar anuncios legítimamente. El enrutamiento de emergencia puede expandir un conjunto. Una política compleja puede dificultar el cálculo de los conos de clientes. Un filtro demasiado estricto puede causar una interrupción por sí mismo.

Pero esos costos no borran la agencia del proveedor. Definen el problema de ingeniería.

Un proveedor de tránsito con poder de propagación global debe poder responder:

¿Qué rango de recuento de rutas y forma de ruta era normal para este cliente?
¿Qué cambios requerían precoordinación?
¿El conjunto aceptado incluía rutas con otros grandes pares o proveedores detrás del cliente?
¿Existía un umbral de máximo de prefijos, y se estableció contra una línea base realista?
¿La sesión tenía una excepción que deshabilitaba o debilitaba los controles?
¿Qué alerta se disparó primero?
¿Quién podía suprimir las rutas sin esperar al cliente?
¿Cómo se protegía el tráfico colateral durante la investigación?

La responsabilidad sigue a esta capacidad práctica de limitar el daño. El error de exportación de AS4788 y la aceptación de AS3549 no son explicaciones mutuamente excluyentes. Son fallas de control sucesivas en la misma cadena de propagación.

La concentración de tránsito convirtió el error de política en daño compartido

No toda fuga de rutas causa un incidente global. El radio de explosión depende de dónde se acepte la fuga, qué tan atractiva se vuelva la ruta, qué tan ampliamente se propague, y si las redes receptoras tienen capacidad para transportar el tráfico redirigido.

Level 3 era un importante proveedor de tránsito global. Una vez que AS3549 propagó las rutas, redes y clientes lejos de Malasia podían seleccionarlas. El tráfico que normalmente seguía rutas directas, regionales o mejor aprovisionadas fue atraído hacia una ruta a través de Level 3 y AS4788. [2][3]

Dos mecanismos de daño siguieron.

El primero fue la desviación directa de rutas. Un prefijo de destino podía adquirir una ruta seleccionada a través de AS3549 y AS4788. Los paquetes viajaban hacia Telekom Malaysia aunque no estuviera destinado a proporcionar tránsito global para ese destino. La interconexión podía saturarse, los paquetes podían perderse y la latencia podía aumentar.

El segundo fue la congestión colateral. Un servicio no necesitaba seleccionar una ruta filtrada en sí mismo para sufrir. Si dependía de la capacidad de Level 3 o de un punto de presencia congestionado, la carga de tráfico extraordinaria podía afectar su ruta normal. ThousandEyes describió ejemplos en los que la propia ruta de un servicio permanecía sin cambios pero la congestión dentro de Level 3 reducía la disponibilidad. [3]

Este segundo mecanismo es importante porque amplía el lente de responsabilidad más allá de una lista de prefijos filtrados. La infraestructura de tránsito compartida puede transmitir daño a clientes cuya política de enrutamiento no es directamente incorrecta. La capacidad, el aislamiento y la ingeniería de tráfico se convierten en parte del problema de contención.

Las redes no pueden aprovisionar cada enlace para una fracción arbitraria de la tabla global que de repente lo elija. Los límites económicos son reales. Sin embargo, un proveedor de tránsito puede diseñar controles para que un conjunto de rutas anómalo no adquiera esa autoridad de tráfico en primer lugar.

El evento conecta por tanto la seguridad del enrutamiento con el riesgo de concentración. Una red de tránsito altamente conectada mejora la accesibilidad en condiciones normales. La misma conectividad amplifica una falla de política cuando se aceptan y propagan rutas inseguras. La escala es tanto un activo de resiliencia como un multiplicador del radio de explosión.

La operación responsable debe tratar el alcance de propagación como una variable de riesgo:

un anuncio pequeño de un cliente local puede usar manejo automatizado normal;
un anuncio repentino de un cliente de rutas de muchas grandes redes no relacionadas debe requerir cuarentena o validación;
un cambio que alteraría rutas a través de muchas regiones debe activar mediciones externas;
un proveedor debe saber qué puntos de presencia e interconexiones recibirían tráfico redirigido;
la contención debe ser posible sin deshabilitar innecesariamente rutas de clientes saludables.

El objetivo no es eliminar la automatización. Es hacerla proporcional a la autoridad que otorga.

Los controles de máximo de prefijos ayudan, pero no son una política completa

Los límites de máximo de prefijos son una defensa intuitiva contra una fuga enorme. Si un cliente normalmente anuncia un conjunto acotado y de repente envía una tabla enorme, el proveedor puede advertir, rechazar nuevas rutas o cerrar la sesión.

BGPMon sugirió que el volumen anómalo de rutas también podría hacer que los límites de máximo de prefijos en las sesiones de Level 3 con otras grandes redes se activaran, produciendo más agitación y cambios de ruta. [2]

Esa observación revela tanto el valor como el peligro de los umbrales simples.

En el borde del cliente, un control de máximo de prefijos bien calibrado puede detener una expansión inverosímil antes de una propagación amplia. En sesiones aguas abajo, el mismo mecanismo puede reaccionar después de que las rutas malas ya hayan entrado en un gran proveedor, potencialmente cayendo toda la sesión y desplazando el tráfico a otro lugar. Un límite puede contener una ruta mientras desestabiliza otra.

Los límites efectivos requieren contexto:

el agregado normal del cliente y los prefijos más específicos;
el crecimiento esperado;
escenarios de mantenimiento y emergencia;
comportamiento separado de IPv4 e IPv6;
si las rutas rechazadas fallan de manera cerrada o mantienen el último conjunto conocido como bueno;
escalada de alertas antes de una parada dura;
un proceso de anulación seguro con vencimiento;
pruebas de la respuesta bajo tráfico realista.

El recuento de rutas tampoco puede detectar todas las fugas. Un cliente podría filtrar un pequeño número de rutas más específicas altamente atractivas. Podría exportar rutas de un par poderoso sin aumentar mucho el volumen total. Podría reemplazar rutas legítimas de clientes con un conjunto no autorizado de tamaño similar.

El máximo de prefijos es por tanto una capa. La propiedad de prefijos, la validación del cono del cliente, las relaciones de ruta AS, las etiquetas de origen de rutas y la detección de anomalías abordan diferentes formas de falla.

Un registro posterior al incidente debe decir qué capas existían, no meramente que «los filtros se mejoraron». Un umbral de máximo de prefijos añadido después del evento sería evidencia significativa si el operador publicara la línea base, la lógica del umbral, el modo de respuesta y una prueba usando el conjunto de anuncios reconstruido.

La validación de origen RPKI no habría resuelto la falla de política de ruta

Las discusiones sobre seguridad de enrutamiento a menudo usan RPKI como una respuesta general a incidentes BGP. Ese atajo es peligroso aquí.

La Infraestructura de Clave Pública de Recursos permite a los titulares de recursos numéricos de Internet crear declaraciones criptográficamente verificables. Una Autorización de Origen de Ruta identifica qué sistema autónomo está autorizado a originar un prefijo, sujeto a las reglas de longitud de prefijo de la autorización. La Validación de Origen de Ruta puede clasificar un anuncio recibido comparando su prefijo y AS de origen con esas autorizaciones. [15][16]

El evento de AS4788 de 2015 fue en gran medida una fuga de política de ruta, no una simple originación no autorizada.

Para muchas rutas filtradas, el origen legítimo permanecía al final de la ruta AS. AS4788 se insertó como tránsito y anunció la ruta a una relación donde no se esperaba. Un validador de origen podría ver un origen autorizado y clasificarlo como válido aunque la ruta violara la intención de exportación del par/proveedor.

El análisis de Huston hizo este punto directamente. En el conjunto de rutas que examinó, solo una minoría involucraba a AS4788 apareciendo como origen de una manera que el filtrado ROA ordinario podría abordar. La mayor parte del problema involucraba información de tránsito. [1]

Esto no hace que RPKI sea poco importante. La validación de origen puede detener originaciones no autorizadas, errores de origen accidentales y muchos secuestros. Puede reducir una clase de accesibilidad falsa. También proporciona información de recursos autenticada que puede respaldar controles más amplios.

Sí significa que la declaración de control debe ser precisa.

«Desplegamos ROV» no prueba protección contra rutas que tienen orígenes válidos pero rutas de relación inválidas. Una red necesita información adicional sobre quién puede proporcionar tránsito para quién y qué rutas son consistentes con la política. RPSL, datos de cono del cliente, comunidades, Roles BGP, el atributo Only to Customer, trabajos relacionados con ASPA y filtros específicos del operador abordan partes de ese problema en diferentes niveles de madurez.

El mensaje responsable es en capas:

RPKI valida la autoridad de origen;
la política explícita de importación y exportación restringe las sesiones;
los controles conscientes de relaciones restringen la propagación de rutas;
el monitoreo detecta anomalías que los datos estáticos pasan por alto;
la coordinación operativa contiene lo que la prevención no detiene.

Conflar esas capas produce una falsa seguridad y un aprendizaje débil post-incidente.

Los registros de rutas pueden publicar intención, pero la intención obsoleta no es control

El Lenguaje de Especificación de Política de Enrutamiento fue diseñado para describir política de enrutamiento en los Registros de Enrutamiento de Internet. RPSL y RPSLng pueden expresar política de importación y exportación, conjuntos de sistemas autónomos, conjuntos de rutas e intenciones relacionadas. [13][14]

En principio, un proveedor puede usar datos de política autenticados y mantenidos para generar filtros para un cliente. Un cliente puede publicar los prefijos y relaciones AS que espera anunciar. Los pares pueden comparar las rutas observadas con la intención declarada.

El análisis de Huston explica la atracción y las limitaciones. Los datos del registro pueden estar incompletos, obsoletos, duplicados en bases de datos o ser demasiado gruesos para relaciones específicas de sesión. La política compleja puede ser difícil de expresar y mantener. Algunos registros históricamente permitían entradas de terceros con autoridad débil. [1]

La lección incorrecta es que los registros de rutas son inútiles. La lección correcta es que un objeto de registro es evidencia solo cuando su propiedad, actualidad, alcance y uso son verificables.

Un pipeline de filtrado maduro debe registrar:

el registro y objetos utilizados;
autoridad de autenticación y mantenimiento;
la última actualización exitosa;
expansión de conjuntos AS en prefijos y rutas concretos;
conflictos entre registros;
excepciones locales;
el diff del filtro generado;
el resultado del despliegue en el router;
monitoreo de divergencia entre política publicada y observada.

MANRS enmarca la seguridad del enrutamiento como responsabilidad operativa colectiva. Sus acciones para operadores enfatizan filtrar anuncios, mantener contactos de coordinación y publicar información que otros puedan validar. La guía de implementación actual discute la granularidad de prefijos y rutas AS y recomienda controles que eviten que rutas aprendidas de clientes o intermedias sean exportadas a pares no clientes inapropiados. [17][18]

Esos documentos actuales son posteriores al evento de 2015 en su forma actual. Deben usarse como un marco de control, no como evidencia legal retroactiva.

El evento muestra por qué el marco importa. Una política conocida solo por una configuración de router es difícil de validar para otra red. Una política publicada pero nunca compilada en filtros es solo documentación. Un filtro compilado a partir de datos obsoletos puede rechazar rutas válidas o aceptar inválidas. La responsabilidad requiere la cadena desde la intención declarada hasta el comportamiento desplegado y las rutas observadas.

El rechazo predeterminado cambia el modo de falla

RFC 8212, publicado en 2017, actualiza el comportamiento BGP para que las rutas en una sesión eBGP no se importen ni exporten a menos que se haya configurado una política explícita. [11]

Esta es una elección de diseño engañosamente importante.

Un valor predeterminado permisivo hace que la accesibilidad sea fácil durante la configuración inicial. También significa que una política faltante puede convertirse silenciosamente en «aceptar todo» o «anunciar todo». Un operador debe recordar añadir cada regla protectora antes de que la sesión transporte rutas.

Una postura de rechazo predeterminado cambia el modo de falla. Una política faltante produce ningún intercambio de rutas, que es visible y local, en lugar de una propagación global no intencionada. Los operadores aún pueden escribir una política explícita incorrecta. RFC 8212 lo dice. El control no resuelve errores semánticos, filtros obsoletos o excepciones intencionales.

Sin embargo, codifica un principio de responsabilidad sólido: la accesibilidad global debe requerir una decisión de política afirmativa.

Para una sesión cliente-tránsito, esa decisión debe ser revisable:

qué prefijos pueden aceptarse;
qué orígenes y rutas de clientes se esperan;
qué rutas pueden exportarse de vuelta;
cómo se aprueban las excepciones;
qué sucede cuando los datos de política no están disponibles;
qué sistema posee la reversión;
qué evidencia prueba el despliegue.

Si cada borde eBGP relevante hubiera usado un valor predeterminado estricto con una política explícita correcta, un filtro faltante habría fallado de manera cerrada. La evidencia pública no puede mostrar si un comportamiento similar a RFC 8212 habría prevenido este incidente exacto porque no expone las configuraciones reales de 2015. El RFC sigue siendo una prueba retrospectiva útil: ¿el intercambio de rutas requería autoridad explícita y acotada en ambos lados?

Roles BGP y Only to Customer abordan la información de relación

RFC 9234, publicado en 2022, estandariza los Roles BGP y el atributo Only to Customer. Los vecinos pueden negociar roles como proveedor, cliente, par, servidor de rutas y cliente de servidor de rutas. Las rutas propagadas pueden llevar información que ayuda a aplicar la dirección de relación esperada y detectar fugas. [12]

Este mecanismo apunta a la brecha visible en el evento AS4788. Un origen legítimo y una ruta libre de bucles no revelan si una ruta aprendida de un par puede enviarse a un proveedor. La información de relación hace que esa política sea más explícita en el intercambio de protocolo.

El estándar aún depende de una configuración y despliegue correctos. Las redes deben asignar roles con precisión. Las relaciones complejas requieren cuidado. La adopción parcial limita la protección. Las rutas y equipos heredados permanecen. Ninguna característica de protocolo elimina la necesidad de monitoreo y coordinación operativa.

El valor es que ambos lados pueden comparar expectativas. Una etiqueta local unilateral puede ser incorrecta sin retroalimentación inmediata. Un rol negociado puede fallar el establecimiento de la sesión o marcar una ruta cuando los dos extremos no están de acuerdo. El atributo Only to Customer puede ayudar a identificar rutas que no deberían viajar a otro proveedor o par.

Una vez más, esto es guía posterior. Sería históricamente inexacto decir que AS4788 o AS3549 no usaron un estándar de 2022 en 2015.

El incidente en cambio proporciona el caso de prueba:

¿Puede una ruta aprendida de un par ser exportada a un ascendente sin una violación de política detectable?
¿Puede el ascendente identificar que la ruta del cliente incluye rutas fuera de la relación de cliente esperada?
¿Puede cualquiera de los lados detener la ruta antes de la propagación global?
¿La evidencia distingue una excepción de política de una fuga accidental?

Los mecanismos modernos conscientes de roles deben evaluarse contra un conjunto de rutas reconstruido similar a AS4788, no solo contra ejemplos sintéticos que coinciden con una topología limpia.

El monitoreo debe comparar rutas con la intención, no solo la disponibilidad

El monitoreo de disponibilidad detecta el daño después de que los usuarios comienzan a perder accesibilidad. El monitoreo de rutas puede identificar la anomalía del plano de control antes.

El registro público de 2015 fue preservado por varias formas de observación:

BGPMon procesó flujos de actualización e identificó la ráfaga de anuncios;
RouteViews y RIPE RIS conservaron archivos BGP sin procesar;
ThousandEyes combinó mediciones de rutas y red;
RIPE Atlas proporcionó mediciones activas de extremo a extremo;
analistas independientes compararon rutas, recuentos de prefijos y tiempos. [2][3][4][5][6]

Estos sistemas vieron diferentes porciones. Esa diversidad es una fortaleza. La vista interna de un solo proveedor puede perder cómo aparecen sus rutas en otros lugares. Una sonda activa puede ver pérdida de paquetes pero no la política que la causó. Un colector de rutas puede ver una ruta AS pero no cada ruta de tráfico o sesión privada.

Los sistemas de detección modernos pueden buscar fugas de rutas usando topología, relaciones AS, historial de rutas y propagación anómala. Cloudflare describe la detección pública de fugas de rutas como una forma de detectar rutas anómalas, mientras que la documentación de RIPE Atlas apoya la medición reproducible desde sondas distribuidas. [19][20]

La detección debe estar vinculada a la acción.

Una alerta que dice «el recuento de rutas aumentó» es débil si nadie es dueño del umbral o puede suprimir la ruta. Un camino de incidente útil define:

la relación esperada y el conjunto de rutas;
la condición de anomalía;
confianza y manejo de falsos positivos;
el operador autorizado para poner en cuarentena;
una acción de contención segura;
confirmación externa;
conservación de evidencia;
revisión posterior al evento.

La primera respuesta no siempre necesita caer toda la sesión. Un proveedor puede reducir la preferencia, poner en cuarentena rutas inesperadas, preservar el último conjunto aceptado conocido como bueno, o rechazar solo rutas fuera del cono del cliente. La acción correcta depende de la capacidad del router y el diseño del cliente.

El monitoreo también debe distinguir prevención de detección. Publicar una alerta de fuga de rutas después de la propagación global es valiosa evidencia pública. No prueba que el proveedor tuviera un control previo a la propagación. Los informes de responsabilidad deben decir qué etapa detectó el evento y qué etapa lo detuvo.

Un cambio seguro de política de rutas necesita evidencia de bytes actuales

La configuración de enrutamiento a menudo pasa por plantillas, bases de datos, automatización, compiladores de políticas y sintaxis específica del proveedor antes de llegar a un router. Un revisor humano puede aprobar una representación mientras el dispositivo recibe otra.

La cadena de evidencia debe vincular los bytes actuales en cada etapa:

política fuente o solicitud de cambio;
datos de relación y prefijos normalizados;
route-map generado o lenguaje de política;
configuración específica del dispositivo;
diff de configuración candidato;
hash de configuración confirmada;
conjunto de rutas anunciado y aceptado resultante;
observación del colector externo.

Esto importa porque «la política fue revisada» es ambiguo. ¿Qué versión fue revisada? ¿Un trabajo de automatización expandió un conjunto AS después de la aprobación? ¿Una instantánea de registro obsoleta produjo el filtro? ¿Un comando manual de emergencia omitió el pipeline normal? ¿Todos los routers recibieron la misma salida?

Un sistema de cambios responsable debe fallar si esos vínculos divergen.

Antes del despliegue, debe reproducir rutas representativas a través de la política compilada. Para condiciones similares a AS4788, las pruebas deben incluir:

rutas originadas por el cliente;
rutas del cono del cliente;
rutas aprendidas de pares;
rutas aprendidas de proveedores;
rutas que contienen grandes redes de tránsito;
más específicos inesperados;
una entrada repentina a escala de tabla completa;
anuncios mixtos válidos e inválidos.

La prueba debe afirmar tanto el comportamiento positivo como el negativo. Las rutas válidas de clientes deben seguir pasando. Las rutas aprendidas de pares y proveedores no deben escapar hacia un ascendente. El proveedor que acepta debe rechazar independientemente las rutas inconsistentes con el rol esperado del cliente.

Después del despliegue, los colectores de rutas o looking glasses deben verificar el resultado observable. Un hash de configuración solo no prueba que el router anunció solo las rutas previstas. El estado del plano de control, los errores del dispositivo y la interacción con otra política pueden cambiar el comportamiento efectivo.

Esta disciplina de bytes actuales no es burocracia por sí misma. Es cómo una organización demuestra que el código, la política y las rutas que se discuten son los mismos objetos que produjeron o evitaron el daño.

La restauración no es lo mismo que la reparación verificada

Las fuentes públicas muestran que las rutas fueron retiradas o dejaron de ser aceptadas y el servicio se recuperó durante las horas siguientes. Eso es restauración operativa.

La reparación pregunta una pregunta más difícil: ¿podría la misma clase de ruta escapar de nuevo?

Un programa de remediación creíble congelaría un conjunto de incidentes representativo de RouteViews, RIPE RIS y registros internos. Identificaría la relación prevista para cada ruta y reproduciría las decisiones de exportación e importación en un entorno de prueba.

Para AS4788, la prueba verificaría que las rutas aprendidas de pares o proveedores no pueden seleccionarse para exportación hacia AS3549 a menos que se aplique una excepción explícita y revisada. Para AS3549, verificarla que un cliente no puede anunciar rutas fuera del cono de cliente esperado o exceder un volumen justificado sin cuarentena.

El programa entonces generaría evidencia:

pruebas fallidas antes de la corrección;
cambios de política o sistema;
pruebas exitosas después de la corrección;
versiones de dispositivo y software;
cobertura de despliegue;
ejercicios de alerta y contención;
observaciones externas de rutas;
inventario de excepciones y vencimiento;
propiedad del monitoreo continuo.

La reparación también debe probar condiciones degradadas. ¿Qué sucede si los datos del registro no están disponibles? ¿El sistema falla de manera cerrada, usa un último conjunto conocido como bueno, o acepta todo? ¿Qué sucede si el detector de anomalías está caído? ¿Puede un operador aislar la sesión a través de una ruta de gestión independiente? ¿Una parada de máximo de prefijos preserva las rutas críticas del cliente o las elimina todas?

La divulgación pública no necesita exponer términos comerciales privados o configuración explotable. Puede declarar la clase de falla, el límite de política afectado, los controles añadidos, el método de prueba, la cobertura de despliegue y la fecha de verificación.

Sin esa evidencia, «arreglamos el filtro» es una afirmación sobre la intención. Con ella, los clientes y pares pueden evaluar si el operador cambió el sistema que permitió la propagación global.

La responsabilidad no debe colapsar en culpa personal

Una fuga de rutas de Internet a menudo se convierte en una historia sobre un ingeniero ingresando un comando incorrecto. El registro público aquí no establece esa historia. Incluso si una sola acción desencadenó el evento, el impacto global requirió múltiples sistemas y decisiones organizativas.

Un operador diseña la interfaz de configuración. Elige si los cambios se generan o se escriben a mano. Define las relaciones de pares y proveedores. Decide qué pruebas son obligatorias, si se requiere un segundo revisor, qué tan rápido se propaga la política, y si la reversión es independiente.

Un proveedor de tránsito decide cuánta confianza depositar en un anuncio de cliente, qué filtros son económica y operativamente factibles, y qué anomalía desencadenará la contención. El liderazgo decide si el trabajo de seguridad de enrutamiento tiene personal, ventanas de mantenimiento y autoridad para interrumpir el tráfico de ingresos.

La culpa personal puede oscurecer estos controles. También puede desalentar la divulgación. Un mejor modelo de responsabilidad pregunta:

¿Quién tenía la capacidad de evitar que la ruta saliera?
¿Quién tenía la capacidad de rechazarla?
¿Quién tenía la capacidad de limitar su propagación?
¿Quién podía detectar el daño de forma independiente?
¿Quién podía retirar o poner en cuarentena?
¿Quién conservó evidencia?
¿Quién tenía autoridad para financiar y verificar la remediación?

Estas preguntas pueden identificar responsabilidad sin reclamar intención o negligencia que las fuentes públicas no prueban.

También evitan que la responsabilidad se disuelva en «Internet es descentralizada». La descentralización significa que ningún operador controla cada ruta. No significa que cada operador carezca de control sobre sus propios anuncios, sesiones y decisiones de propagación.

Lo que los clientes y pares pueden exigir razonablemente

La mayoría de los clientes no pueden auditar los routers de un proveedor de tránsito. Los pares no pueden ver cada proceso de cambio privado. Aún pueden exigir evidencia apropiada a la dependencia.

Antes de un incidente, un operador puede publicar:

contactos de enrutamiento precisos;
prefijos y sistemas autónomos registrados;
conjuntos de rutas y AS;
una política de interconexión y filtrado de alto nivel;
cobertura RPKI;
soporte para mecanismos de rol y validación relevantes;
canales de estado e incidentes.

Durante un incidente, puede comunicar:

la clase de ruta o sesión afectada;
si los anuncios aún se están propagando;
la acción de contención;
regiones y servicios conocidos;
incertidumbre de medición;
evidencia de recuperación;
la hora de la próxima actualización.

Después de un incidente, puede proporcionar:

límites de fuente y aceptación;
definiciones de recuento de rutas;
cronología con procedencia;
controles que fallaron;
controles que contuvieron el daño;
remediación comprobable;
limitaciones restantes.

Los clientes también deben probar su propia exposición. La multi-homing no garantiza independencia si ambos proveedores dependen del mismo ascendente. Una ruta de respaldo puede existir pero perder bajo preferencia local. Los anuncios más específicos pueden anular la diversidad prevista. El tráfico puede evitar una ruta filtrada pero sufrir congestión en un proveedor de tránsito compartido.

El monitoreo independiente de rutas, las mediciones de RIPE Atlas y los looking glasses pueden revelar parte de esa exposición. [4][5][6][20]

El deber es proporcional. Un servicio público crítico o plataforma financiera debe entender la concentración ascendente más profundamente que un sitio personal de bajo impacto. Pero ningún cliente puede compensar completamente por un proveedor de tránsito que acepta y difunde un conjunto masivo de rutas inseguras.

Lo que el registro público no puede probar

El conjunto de fuentes respalda un análisis sólido de responsabilidad de red, pero no respalda una autopsia interna completa.

No puede probar:

el router o ubicación exacta de Telekom Malaysia;
el comando de configuración o plantilla exacta;
si el desencadenante fue un cambio planificado, un estado obsoleto, una falla de automatización o un error manual;
la versión de software o hardware;
los términos de relación privados entre AS4788 y AS3549;
la configuración exacta de importación, exportación y máximo de prefijos en ambos lados;
la primera alerta interna y respuesta del operador;
mensajes de coordinación privados;
un recuento de prefijos reconciliado entre todos los colectores;
un censo completo de usuarios afectados o pérdidas financieras;
responsabilidad legal o incumplimiento contractual;
la remediación duradera desplegada por cualquiera de los operadores.

El paquete tampoco debe convertir controles posteriores en requisitos históricos. RFC 8212 se publicó en 2017, RFC 9234 en 2022, y la guía de implementación actual de MANRS refleja trabajo operativo posterior. Definen pruebas útiles del presente. No prueban qué configuraciones u obligaciones existían en 2015. [11][12][18]

Del mismo modo, los datos actuales de RIPEstat son contexto actual de recursos de red, no una instantánea de registro congelada de 2015. [7]

Estos límites hacen que la conclusión sea más creíble. La falla observable es suficiente para identificar el control dividido. El registro interno faltante es en sí mismo una brecha de responsabilidad, pero no es permiso para inventar uno.

Una prueba reutilizable de responsabilidad de filtrado ascendente

El evento respalda una prueba práctica para cualquier cliente, proveedor de tránsito o par que opere BGP a escala significativa.

1. Definir la relación para cada sesión.
Registrar proveedor, cliente, par, servidor de rutas y roles excepcionales a la granularidad donde la política difiere.

2. Vincular las rutas previstas a evidencia autenticada.
Mantener prefijos, orígenes, conos de clientes, conjuntos AS y excepciones con propiedad, actualidad y procedencia.

3. Compilar la política antes del despliegue.
Mostrar las rutas y caminos concretos que la política de importación y exportación aceptará. Revisar el comportamiento efectivo, no solo el texto de la plantilla.

4. Fallar de manera cerrada cuando falta política explícita.
Ninguna ruta eBGP debe ganar autoridad global porque un filtro estaba ausente o la recuperación de datos falló.

5. Probar violaciones de relación.
Reproducir rutas aprendidas de pares y proveedores contra sesiones de clientes y ascendentes. Verificar que la dirección inválida sea rechazada tanto en el exportador como en el receptor.

6. Calibrar controles de volumen.
Establecer el máximo de prefijos y umbrales de anomalía contra el comportamiento normal, el crecimiento justificado y los casos de emergencia. Definir una contención segura en lugar de depender solo del cierre completo de la sesión.

7. Separar validación de origen y ruta.
Usar RPKI para la autoridad de origen, pero no describir ROV como prueba de propagación válida según la relación. Añadir controles de ruta y cono del cliente.

8. Monitorear desde afuera.
Usar colectores independientes y mediciones activas para comparar las rutas observadas y la accesibilidad con la política prevista.

9. Dar a la contención un propietario.
Identificar quién puede poner en cuarentena rutas, reducir preferencia, restaurar un último conjunto conocido como bueno o restablecer una sesión, incluso fuera de las ventanas de cambio ordinarias.

10. Preservar evidencia de bytes actuales.
Vincular la política aprobada, la configuración generada, los bytes desplegados, el estado de la ruta, las alertas, las decisiones y las observaciones externas.

11. Probar la reparación con la clase de evento original.
Ejecutar la fuga reconstruida a través de ambos lados de la sesión y mostrar dónde se detiene. Probar variantes semánticas, no solo una lista de prefijos guardada.

12. Publicar suficiente para que las redes dependientes puedan verificar.
Explicar el límite de control, las definiciones de recuento de rutas, la remediación y la incertidumbre restante sin exponer términos privados sensibles.

Esta prueba no promete que las fugas de rutas desaparezcan. Hace que los deberes de prevención, contención y evidencia sean explícitos en cada red que puede otorgar a la ruta mayor autoridad.

Conclusión

La fuga de rutas de Telekom Malaysia del 12 de junio de 2015 demostró qué tan rápido la política de enrutamiento local puede convertirse en daño global a la infraestructura.

AS4788 emitió un conjunto muy grande de rutas. AS3549 las aceptó y propagó. El tráfico se desplazó hacia rutas a través de Level 3 y Telekom Malaysia. La pérdida de paquetes, la latencia y los fallos de accesibilidad se extendieron por todas las regiones y afectaron tanto a servicios directamente redirigidos como a usuarios expuestos a la congestión en una red de tránsito compartida. Colectores de rutas independientes y plataformas de medición preservaron el esquema público. [1][2][3][4]

El evento no puede explicarse responsablemente como un simple mal anuncio de una red. La exportación y la importación son controles separados. Un cliente tiene el deber de anunciar solo rutas autorizadas. Un proveedor de tránsito tiene un deber proporcional a su poder para aceptar y difundir esas rutas. Los pares y las redes aguas abajo tienen controles adicionales de monitoreo e importación. Ninguna capa puede garantizar perfección, pero cada una puede evitar que un solo error adquiera más alcance.

La validación de origen RPKI es valiosa e insuficiente para esta falla de política de ruta. Los registros de rutas pueden publicar intención y aún volverse obsoletos. Los controles de máximo de prefijos pueden contener volumen y aún pasar por alto fugas más pequeñas. Los estándares posteriores de rechazo predeterminado y conscientes de relaciones mejoran el modelo de control pero no prueban retroactivamente una violación de 2015. La respuesta duradera es en capas: política explícita, datos de rutas autenticados, controles de relación, límites calibrados, monitoreo independiente, contención rápida y reparación reproducible.

El riesgo sigue al alcance que un anuncio puede adquirir. La responsabilidad sigue a quién podría haber limitado ese alcance, quién eligió propagarlo, y quién puede demostrar que la misma clase de falla ahora se detendrá antes de que el tráfico de otras personas se convierta en la prueba.

La filtración de rutas de Telekom Malaysia en 2015 convirtió el filtrado ascendente en una prueba de responsabilidad del tránsito