Resumen

  • El evento observado el 8 de abril de 2010 debe tratarse como una falla de control de rutas entre dominios: AS23724 exportó un conjunto anómalo de prefijos, AS4134 apareció como el primer límite visible de importación y reanuncio, y redes externas propagaron solo una parte de esas rutas.
  • Las cifras centrales deben mantenerse acotadas: BGPMon atribuyó al evento aproximadamente 37.000 prefijos durante unos quince minutos y estimó que cerca del diez por ciento de esos prefijos se propagó fuera de redes chinas; esa proporción de prefijos no es una proporción de tráfico.

El 8 de abril de 2010, BGPMon observó un evento de plano de control en el que AS23724, identificado en registros públicos de enrutamiento como una red de centro de datos de China Telecom, originó un conjunto de prefijos muy superior al que normalmente anunciaba. La cuenta original de BGPMon situó la primera observación anómala a las 17:54:31 UTC y la última a las 18:10:14 UTC. Esas marcas deben leerse como observaciones de colectores, no como un reloj universal para cada router, sesión BGP, ruta de paquetes o usuario final.

La escala hizo que el evento fuera visible. Según BGPMon, AS23724 solía originar alrededor de cuarenta prefijos, pero durante el incidente anunció aproximadamente 37.000 prefijos únicos. Esa diferencia no es una variación ordinaria en una política de tránsito; es una señal de que un conjunto de rutas no asignadas a ese sistema autónomo cruzó una frontera de exportación. En términos de responsabilidad operativa, la pregunta no es solo quién emitió el anuncio inicial. También importa qué vecino aceptó esas rutas, qué rutas fueron preferidas, cuáles se reanunciaron y qué redes posteriores decidieron aceptarlas o filtrarlas.

El camino común observado contenía AS4134 seguido de AS23724. Esa secuencia establece una frontera técnica importante: AS23724 aparece como el origen anómalo, mientras AS4134 aparece como el primer límite visible de importación y de reanuncio hacia relaciones comerciales o de conectividad más amplias. La responsabilidad no se distribuye de manera idéntica. El exportador controla su conjunto autorizado de rutas y su política de salida. El vecino directo controla la importación, la selección local, los filtros de cliente o par y el reanuncio posterior.

Las redes que reciben esas rutas desde AS4134 conservan sus propios controles de aceptación, preferencia y propagación.

La cronología pública permite afirmar que hubo anuncios BGP anómalos y propagación parcial, pero no permite reconstruir una historia completa de datos. No prueba cuántos paquetes se reenviaron a través de AS23724 o AS4134. No prueba inspección, almacenamiento, alteración ni intención maliciosa. Tampoco prueba que una fracción fija del tráfico global fuera desviada. La evidencia pública es fuerte sobre anuncios de rutas y visibilidad en colectores. Es limitada sobre el plano de datos.

Esa distinción es el núcleo del caso. BGP transporta información de alcance y preferencia entre sistemas autónomos. Cuando un AS anuncia prefijos que no controla, otros routers pueden creer, seleccionar y propagar una ruta incorrecta si sus políticas lo permiten. Pero un conteo de prefijos no mide bytes, sesiones, aplicaciones, usuarios afectados ni contenido. Un prefijo pequeño puede transportar tráfico relevante; un prefijo visible puede transportar poco; muchos prefijos anunciados pueden no ser preferidos por redes externas. Por eso la cifra de aproximadamente 37.000 prefijos, aun siendo grave, no debe convertirse en una cifra de tráfico.

BGPMon publicó una aclaración posterior que separó explícitamente el porcentaje de prefijos del porcentaje de tráfico. En esa lectura, alrededor de 37.000 prefijos equivalían aproximadamente a once por ciento de la tabla de enrutamiento de la época, pero eso no significaba once por ciento de todo el tráfico de Internet. BGPMon también estimó que solo cerca del diez por ciento de los prefijos anunciados se propagó fuera de redes chinas. Además, indicó que 28 por ciento de los colectores RIPE RIS usados en su análisis detectaron alguna parte del evento. Esas cifras describen un conjunto de observación, no una verdad global sobre cada red.

La variación de conteos en informes posteriores no invalida el episodio; exige precisión. Distintos observadores usan diferentes colectores, ventanas temporales, reglas para prefijos más específicos, tratamiento de anuncios retirados y definiciones de lo que cuenta como ruta afectada. Una medición puede contar anuncios únicos. Otra puede contar rutas vistas desde más puntos. Otra puede agrupar o separar desagregaciones. Si una investigación de responsabilidad mezcla esos métodos sin atribución, transforma una falla de enrutamiento verificable en una cifra inflada o ambigua.

El término “fuga de rutas” es útil cuando se define. En este caso, describe la salida de rutas que no debían cruzar una frontera de política. El término “hijack” aparece en análisis públicos porque un AS anunció prefijos que no le estaban asignados, pero el término puede sugerir intención. La evidencia pública disponible no establece intención. BGPMon consideró más probable una configuración accidental, pero presentó esa apreciación como especulación porque no había hablado con los ingenieros de la red.

La lectura responsable debe mantener ambas cosas juntas: el evento fue grave en el plano de control, y la motivación o causa interna permanece no probada.

La frontera AS23724-AS4134 es el punto de control más importante porque ahí se puede observar la transición entre una exportación anómala y una propagación con impacto externo. Si AS23724 originó rutas no autorizadas, el primer control esperado era impedir que una tabla aprendida, completa o no autorizada saliera como si fuera un conjunto propio. Si AS4134 aceptó esas rutas desde AS23724 y las reanunció, el segundo control esperado era aplicar filtros explícitos de importación, límites de volumen y políticas conscientes de relación. Después, cada red externa que aceptó los anuncios tomó decisiones propias de preferencia y filtrado.

Un filtro de prefijos autorizado habría reducido la superficie. El operador que acepta rutas desde un cliente, par o red interna necesita saber qué prefijos están permitidos para esa relación. Esa lista puede derivarse de registros internos, IRR, RPKI, contratos, tickets de provisión y validaciones operativas. Pero el punto decisivo no es que el dato exista en algún registro; es que se convierta en configuración efectiva. Si la política en ejecución acepta miles de prefijos inesperados desde una relación que no debería exportarlos, el registro funcionó como referencia, no como control.

Los límites máximos de prefijos son otro control de contención. Una sesión que normalmente recibe o exporta decenas de prefijos puede configurarse con advertencias y umbrales duros. Si el conteo se multiplica por cientos o miles, el router puede alarmar, cerrar la sesión o bloquear la propagación según la política elegida. Los umbrales no resuelven todos los casos: un límite demasiado estricto puede causar indisponibilidad legítima, y uno demasiado laxo puede no frenar el incidente. Pero en una transición de alrededor de cuarenta prefijos a aproximadamente 37.000, el valor de un control de volumen es evidente.

La política consciente de relación también importa. En BGP, no toda ruta aprendida desde una relación debe reanunciarse a todas las demás. Una red puede aceptar rutas de cliente y propagarlas a proveedores o pares; no debería convertir rutas aprendidas de un proveedor o par en rutas de tránsito global si la relación no lo permite. Los documentos técnicos posteriores sobre fugas de rutas y BGP Roles formalizan parte de esta lógica: la relación comercial o funcional debe influir en lo que se acepta y en lo que se exporta. El evento de 2010 es un ejemplo de por qué esa lógica no es académica.

RPKI ayuda, pero no es una cura completa. La validación de origen puede rechazar una ruta si existe un ROA válido que autoriza a otro AS y no al originador observado. En un incidente donde AS23724 origina prefijos no autorizados y hay ROAs correctos, un validador de origen puede marcar esas rutas como inválidas. Pero RPKI no prueba que toda la ruta AS_PATH sea legítima. Tampoco impide toda fuga si el origen sigue siendo válido pero el camino o la relación de exportación es incorrecta. La responsabilidad técnica requiere combinar validación de origen con filtros de relación, límites de volumen y monitoreo independiente.

Los colectores de rutas cumplen una función distinta: conservan evidencia. Un colector puede observar anuncios, retiros, cambios de AS_PATH y visibilidad desde determinados puntos. Puede mostrar que una ruta apareció, que se propagó a ciertos lugares y que desapareció de esos puntos. No controla el reenvío en redes de terceros. No mide todos los caminos de datos. No ve todas las decisiones locales. Por eso la retirada verificada debe hacerse desde varios puntos independientes: no basta con que el originador diga que corrigió la configuración, ni con que un solo colector deje de ver una ruta.

La retirada independiente es parte de la responsabilidad posterior al incidente. Un cierre verificable debería establecer cuándo empezó el anuncio anómalo, cuándo lo aceptó el vecino directo, cuándo se propagó a redes externas, cuándo fue detectado, quién recibió la alerta, qué cambio de configuración se aplicó, cuándo se enviaron los withdrawals y cuándo colectores externos dejaron de observar las rutas anómalas. Esa secuencia no necesita revelar secretos comerciales, pero sí debe demostrar que la red puede reconstruir el fallo y probar que la clase de falla ya no cruza la misma frontera.

En abril de 2010, la evidencia pública no ofrece esa reconstrucción interna. Se observan anuncios y se observan límites de propagación. Se cita una hipótesis de error de configuración. Se reconocen incertidumbres sobre intención y datos. Para una investigación de responsabilidad, esa ausencia no autoriza a llenar vacíos con acusaciones. Autoriza a exigir mejores pruebas de control: registros de configuración, políticas de importación y exportación, excepciones, límites, alertas, tickets de escalación y resultados de replay controlado.

El análisis de propagación debe mantenerse en su escala correcta. BGPMon dijo que alrededor del diez por ciento de los prefijos anunciados se propagó fuera de redes chinas. Esa frase no significa que el noventa por ciento restante fuera seguro, ni que el diez por ciento transportara un porcentaje equivalente de tráfico. Significa que, desde el conjunto de observación usado, solo una porción del conjunto anómalo cruzó hacia visibilidad externa. El daño potencial se concentra precisamente en esa porción que logró atravesar fronteras de política y fue aceptada por redes que podían haber tenido controles propios.

El caso también muestra una diferencia entre exposición y aceptación. Un anuncio puede llegar a un colector porque fue propagado por una red, pero eso no significa que todos los routers del mundo lo prefirieran. La selección BGP depende de políticas locales, atributos, longitud de camino, preferencia local, comunidades, rutas alternativas y otros criterios. Una red puede ver una ruta y no usarla para tráfico. Otra puede preferirla. Sin mediciones de plano de datos, no se puede convertir visibilidad de plano de control en desvío efectivo de tráfico. Esa es la razón por la que “prefijo” y “tráfico” deben separarse en cada párrafo de este caso.

El incidente no debe mezclarse con otros eventos posteriores que involucren a AS4134 o a otros operadores. La frontera de este artículo es el evento AS23724-AS4134 observado el 8 de abril de 2010. Eventos de 2019 u otras fugas por rutas diferentes pueden iluminar patrones generales de seguridad de enrutamiento, pero no son evidencia directa de esta secuencia. La responsabilidad exige no acumular episodios para insinuar una intención que no está demostrada en el paquete de hechos de 2010.

Una prueba de control adecuada comienza antes de que haya incidente. Cada sesión externa debería tener una política de importación por defecto restrictiva, listas generadas desde fuentes autorizadas, validación de origen cuando existan ROAs, límites de prefijos con umbrales de advertencia y corte, filtros de relación, revisión de comunidades y pruebas de cambios. La configuración generada debe poder compararse con la configuración en ejecución. Las excepciones deben tener dueño y vencimiento. Sin esa trazabilidad, un operador puede tener documentación correcta y routers que hacen otra cosa.

También hay una responsabilidad del titular del prefijo, aunque no es simétrica. El titular puede publicar ROAs precisos, mantener registros IRR razonables, asegurar contactos de abuso y operación, contratar monitoreo y definir procedimientos de escalación. Pero el titular no controla los filtros de otro AS. Si una red externa acepta un origen no autorizado pese a que existe información de autorización clara, la falla principal está en la política de aceptación y propagación de esa red. La responsabilidad se reparte por capacidad de control, no por simple cercanía al número de recurso.

Desde la perspectiva de usuarios finales, el control directo es prácticamente inexistente. Un usuario no decide qué ruta BGP usa su proveedor para alcanzar un prefijo. Puede notar latencia, pérdida, indisponibilidad o rarezas de aplicación, pero no puede corregir una fuga interdominio. Por eso el estándar de responsabilidad debe dirigirse a operadores, vecinos de tránsito, pares, titulares de recursos, colectores y equipos de respuesta. La transparencia posterior al incidente sustituye parcialmente la falta de control del usuario, pero solo si incluye datos verificables y no solo garantías generales.

El resultado técnico más defendible es tratar el evento como una prueba de propagación. AS23724 exportó un conjunto que, según BGPMon, fue enorme respecto de su comportamiento normal. AS4134 apareció en el camino observado y, por tanto, como un límite donde una política de importación y reanuncio podía haber contenido parte del problema. Redes externas propagaron una parte del conjunto. Luego los anuncios desaparecieron de las observaciones. La pregunta operativa es si esa retirada fue simplemente el final del incidente o si produjo un aprendizaje demostrable en filtros, alertas y pruebas.

Una retirada verificada debería incluir mediciones activas y pasivas. Las pasivas muestran withdrawals y ausencia de anuncios anómalos desde colectores. Las activas pueden comprobar alcance desde puntos elegidos, aunque tampoco agotan toda Internet. Ambas deben relacionarse con el cambio operativo: no basta ver que la ruta desaparece; hay que saber qué política cambió o qué sesión se cerró. Si la causa fue una exportación accidental de una tabla aprendida, la prueba de recurrencia debe intentar recrear esa condición en laboratorio o entorno controlado y demostrar que ahora se bloquea.

El estándar mínimo de cierre debería ser falsable. Una red podría decir: este conjunto de prefijos era el único autorizado para esa relación; esta fuente generó el filtro; esta versión de configuración estaba en ejecución antes del cambio; este evento superó el umbral; esta alerta llegó a este equipo; este cambio se aplicó; estos withdrawals se observaron; estos colectores independientes ya no ven las rutas; esta prueba de replay confirma que la misma clase de exportación no puede pasar. Si otra medición contradice cualquiera de esos puntos, el cierre debe cambiar.

La lección de 2010 no es que un solo mecanismo habría resuelto todo. RPKI sin filtros de relación no valida caminos completos. Filtros de prefijos sin registros correctos se degradan. Máximos de prefijos sin procedimientos pueden convertirse en cortes bruscos o alarmas ignoradas. Colectores sin dueño de respuesta solo producen evidencia tardía. BGP Roles y mecanismos de prevención de fugas ayudan a codificar relaciones, pero dependen de adopción y configuración. La defensa real es acumulativa: registros correctos, políticas por defecto restrictivas, validación, límites, monitoreo y ejercicios de retiro.

Esa acumulación también debe respetar el funcionamiento real de Internet. BGP no es un sistema centralizado con un árbitro que aprueba cada camino. Es un conjunto de acuerdos y políticas locales que producen conectividad global. Por eso los registros son necesarios pero no suficientes. El plano real de decisión vive en routers, plantillas, generadores de configuración, sesiones, comunidades, excepciones y procedimientos humanos. Cuando un conjunto de aproximadamente 37.000 prefijos puede salir de una red que normalmente anuncia alrededor de cuarenta, la falla no es solo documental.

Es una falla entre autorización registrada y política ejecutada.

El análisis de responsabilidad debe evitar dos errores opuestos. El primero es minimizar el evento porque duró unos quince minutos según la observación de BGPMon. Quince minutos pueden bastar para exponer fragilidad de control, activar rutas incorrectas y obligar a respuesta externa. El segundo es magnificarlo como si el once por ciento de la tabla equivaliera a once por ciento del tráfico mundial. Esa equivalencia no está respaldada. La gravedad está en la posibilidad de propagación no autorizada a gran escala, no en una cifra de tráfico que el plano de control no mide por sí solo.

También debe evitarse el lenguaje de certeza donde solo hay hipótesis. Si una configuración accidental parece más probable, debe citarse como hipótesis atribuida, no como causa confirmada. Si la intención es desconocida, se dice desconocida. Si el volumen de tráfico no se midió, no se inventa. Si no hay prueba pública de inspección o almacenamiento, no se sugiere. Este rigor no suaviza la responsabilidad; la hace más fuerte, porque enfoca la discusión en controles verificables que los operadores sí pueden demostrar.

El evento AS23724-AS4134 sigue siendo relevante porque condensa una falla de frontera. Un origen anómalo no se convierte en evento global solo por existir. Necesita aceptación, preferencia y reanuncio. Cada una de esas etapas tiene dueño operativo. El control moderno de rutas no debe limitarse a preguntar si una ruta “aparece” en la tabla. Debe preguntar si esa ruta estaba autorizada para esa relación, si el origen tenía ROA válido, si el camino era coherente con el contrato, si el volumen era plausible y si la red puede probar que una retirada llegó a los puntos donde el anuncio había sido visto.

En una red nacional grande, la responsabilidad aumenta porque las decisiones de política tienen alcance. AS4134, como frontera visible en el camino observado, no es solo un nombre en un AS_PATH; representa un punto donde rutas aceptadas pueden ganar salida hacia otras redes. Eso no prueba intención ni datos desviados. Sí convierte la política de importación, la clasificación de relaciones y el control de reanuncio en objetos legítimos de escrutinio. Una explicación defensible debe mostrar por qué esas rutas fueron aceptadas o por qué no volverían a ser aceptadas bajo las políticas actuales.

La misma lógica aplica a AS23724. Si el AS normalmente originaba un conjunto pequeño y de pronto originó decenas de miles de prefijos, la explicación necesita mostrar cómo se definía su conjunto autorizado, cómo se impedía exportar rutas aprendidas, qué cambio abrió la puerta y qué control fue agregado después. Sin esa cadena, el público solo ve el síntoma: un origen que no debía aparecer para muchos prefijos. El estándar de recuperación pide más que una desaparición del síntoma. Pide relación entre causa, corrección y verificación independiente.

Los titulares de prefijos afectados también pueden aprender de la medición. Publicar ROAs precisos reduce el espacio para orígenes no autorizados cuando las redes validadoras aplican rechazo o políticas de preferencia. Mantener registros claros en IRR ayuda a construir filtros, aunque esos registros no se ejecutan solos. Tener monitoreo propio reduce el tiempo hasta la escalación. Pero ningún titular puede asumir que todos los vecinos del mundo aplicarán correctamente sus datos. La defensa del titular es aportar evidencia autorizativa y detectar desvíos; la contención depende de quienes aceptan y propagan rutas.

La investigación académica y operativa posterior sobre hijacks, fugas y medición de AS_PATH aporta el marco conceptual: observar BGP desde muchos puntos permite reconstruir partes de la propagación, detectar inconsistencias y estudiar la eficacia de políticas. Pero incluso los mejores estudios tienen límites de cobertura. La red completa no está instrumentada de manera uniforme. Algunas decisiones locales nunca llegan a colectores públicos. Las rutas pueden cambiar más rápido que la resolución de un informe.

Por eso una conclusión madura debe incluir condiciones que la harían cambiar: nuevos logs de router, mediciones de plano de datos, reconstrucciones de colectores más completas o pruebas actuales de contención.

Para este caso, esas condiciones son claras. Si registros internos demostraran una causa diferente, la atribución de la hipótesis de configuración tendría que ajustarse. Si mediciones contemporáneas de datos mostraran una propagación materialmente distinta, la evaluación de impacto tendría que cambiar. Si configuración actual, con hash y pruebas de replay, demostrara que la misma clase de ruta no puede cruzar la frontera AS23724-AS4134, la lectura de riesgo residual sería menor. Si una reconstrucción más amplia de colectores alterara el alcance externo, el mapa de propagación tendría que corregirse.

Hasta entonces, la conclusión responsable es limitada y firme. El 8 de abril de 2010, BGPMon observó que AS23724 anunció aproximadamente 37.000 prefijos durante unos quince minutos, con AS4134 en el camino común observado y propagación parcial hacia fuera de redes chinas. BGPMon atribuyó a su conjunto de observación una propagación externa cercana al diez por ciento de esos prefijos y separó esa cifra de cualquier proporción de tráfico. La evidencia pública prueba una anomalía de enrutamiento y una falla de contención por capas; no prueba intención, inspección de paquetes, almacenamiento de datos ni porcentaje global de tráfico.

La responsabilidad, por tanto, no está en una frase acusatoria. Está en un estándar operativo. Un exportador debe impedir que rutas no autorizadas salgan como propias. Un vecino directo debe importar con filtros explícitos, límites plausibles y conciencia de relación. Los reanunciadores deben evitar convertir rutas incompatibles con su relación en rutas de alcance más amplio. Los titulares deben mantener autorizaciones precisas y vigilancia. Los colectores deben preservar evidencia independiente. Y el cierre del incidente debe mostrar retirada verificada, no solo silencio posterior.

El caso de China Telecom en 2010 sigue siendo una advertencia precisamente porque resiste la simplificación. Fue lo bastante grande para mostrar cómo un error de política puede atravesar varias fronteras. Fue lo bastante limitado en evidencia pública para recordar que BGP no mide tráfico ni intención por sí mismo. La disciplina correcta es sostener ambas verdades. En el plano de control, el evento exige responsabilidad por exportación, importación, propagación y retirada. En el plano de datos, exige humildad: sin medición directa, prefijo no es tráfico, visibilidad no es interceptación y una cifra llamativa no sustituye una prueba.