Resumen

  • Hacia las 02:24 UTC del 6 de noviembre de 2012, Cloudflare observó que servicios de Google no eran accesibles desde algunas partes de Internet. Una ruta publicada por su equipo atravesaba AS4436, PCCW/AS3491, Moratel/AS23947 y finalmente el origen legítimo Google/AS15169 [1].
  • Cloudflare describió una interrupción limitada de unos 27 minutos y estimó que pudo afectar al 3-5 % de la población de Internet, con mayor impacto alrededor de Hong Kong. La cifra es una estimación de Cloudflare, no un censo independiente [1].
  • El RFC 7908 cita el incidente Moratel-PCCW como ejemplo de fuga de tipo 4: prefijos aprendidos de un par se exportan hacia un proveedor de tránsito y superan su alcance previsto [2].
  • Cloudflare consideró inicialmente probable un anuncio erróneo. Una actualización recogió la explicación de Moratel: un fallo inesperado de hardware provocó la condición anormal y no hubo intención maliciosa [1]. El registro público no permite resolver la secuencia interna exacta.
  • La responsabilidad se reparte en el límite de la relación. Moratel debía impedir la exportación no autorizada; PCCW debía rechazar como ruta de cliente cualquier camino que procediera de una relación distinta.

La observación y sus límites

Cloudflare informó de que su personal detectó la caída hacia las 02:24 UTC. El síntoma inicial parecía relacionado con DNS, porque desde su red tampoco era posible llegar a 8.8.8.8. El diagnóstico cambió al plano de enrutamiento cuando una traza mostró una dirección de Moratel en Indonesia, un desvío inesperado para tráfico desde California hacia Google [1].

El camino registrado para un prefijo de Google incluía AS4436, AS3491, AS23947 y AS15169. Google seguía siendo el origen. El problema no era una sustitución sencilla del ASN de origen, sino una transición indebida en medio del camino. La dirección final podía ser auténtica mientras el tráfico era atraído hacia una red que no estaba prevista para transportarlo.

Cloudflare dijo que contactó con un ingeniero de Moratel. La ruta anormal se corrigió alrededor de las 02:50 UTC y unos tres minutos después el enrutamiento volvió a la normalidad [1]. El alcance no fue universal. Cloudflare tenía una posición operativa relevante, pero no visibilidad sobre todos los usuarios, redes o productos de Google. Por eso su cálculo del 3-5 % debe conservar la atribución.

También debe conservarse la corrección sobre la causa. El texto inicial hablaba de una posible equivocación al anunciar rutas. La actualización atribuye a Moratel un fallo de hardware inesperado y afirma que no fue un acto malicioso [1]. Sin alarmas de dispositivo, cambios de configuración, tablas de rutas y marcas de tiempo internas, no es posible determinar si el primer fallo estuvo en el equipo, el software, una configuración, un proceso de conmutación o la interacción de varios elementos.

La frontera de tipo 4

BGP permite que sistemas autónomos intercambien alcance. Cada sistema aplica su política y utiliza un ASN. Una actualización incluye un prefijo, un AS_PATH y otros atributos. El router decide qué aceptar, qué preferir y qué volver a anunciar.

Esas decisiones codifican relaciones operativas. Un cliente compra tránsito a un proveedor. Dos pares intercambian normalmente sus rutas y las de sus clientes, pero no se ofrecen tránsito completo entre sí. Una ruta recibida de un par puede ser correcta en esa sesión y, al mismo tiempo, estar prohibida al anunciarse a un proveedor.

El RFC 7908 define una fuga como propagación más allá del alcance previsto. El tipo 4 describe a un AS que anuncia a su proveedor de tránsito rutas aprendidas de un par lateral. El documento enumera expresamente la fuga Moratel-PCCW de prefijos de Google [2].

Esa clasificación explica por qué validar solo el origen no basta. AS15169 seguía al final del camino. Había que validar la relación de propagación: si AS23947 podía exportar la ruta a AS3491 y si AS3491 debía aceptarla como ruta de cliente. Una autorización del origen puede ser correcta y el camino seguir siendo ilegítimo.

El deber de prueba de Moratel

El operador exportador debe poder identificar la sesión, su rol, las rutas recibidas, las seleccionadas y las anunciadas al vecino. El registro debe separar prefijos propios, rutas autorizadas de clientes, rutas aprendidas de pares y rutas recibidas de proveedores.

Si un fallo de hardware activó la fuga, la explicación útil no termina en el nombre del componente. Debe mostrar cómo ese fallo alteró la política. ¿Un reinicio cargó una configuración incompleta? ¿Un mecanismo de respaldo activó una regla más amplia? ¿La convergencia anunció temporalmente una tabla que debía permanecer local? ¿Una política desapareció o fue omitida? Un buen diseño debe evitar que un estado inesperado convierta una sesión en exportación abierta.

La prueba tiene que unir intención y ejecución. Además del cambio de configuración, hacen falta las rutas anunciadas, atributos y comunidades relevantes, alarmas del equipo, propietarios del cambio y secuencia de retirada. Así se distingue una reparación duradera de la simple eliminación del síntoma.

El deber de aceptación de PCCW

Cloudflare describió a PCCW como el proveedor ascendente que confió en las rutas de Moratel y las propagó [1]. El RDAP actual identifica AS3491 como PCCWG-APAC-HK y lo asocia con PCCW Global (HK) Limited [6]. Es una evidencia actual de identidad, no una reconstrucción completa del contrato en 2012.

Un proveedor de tránsito decide qué anuncios de cliente acepta y hacia dónde los distribuye. Debe conservar la autorización de prefijos y orígenes, el cono de cliente esperado, los patrones de camino permitidos, límites de volumen, alertas y excepciones. Cuando un cliente transporta legítimamente rutas de terceros, la lista puede ser compleja. Esa complejidad exige mejores datos de relación y reconciliación, no ausencia de filtro.

Una red ascendente de gran alcance amplifica una fuga local. Por eso «el cliente la anunció» no cierra la responsabilidad. El servicio del proveedor consiste en propagación controlada. Debe poder mostrar cuándo recibió la ruta, por qué la aceptó, qué preferencia le dio y a qué vecinos la anunció.

Registro y realidad operativa

El RDAP de APNIC identifica actualmente AS23947 como MORATELINDONAP-AS-ID y lo relaciona con PT. Mora Telematika Indonesia [5]. El registro de AS3491 identifica PCCWG-APAC-HK y PCCW Global (HK) Limited [6]. Esos registros ayudan a mantener la identidad y el contacto de los recursos numéricos.

No muestran el estado del router a las 02:24 UTC. Un registro dice quién opera un ASN; no revela qué política estaba cargada ni qué ruta salió por una sesión. Esta es la superficie Heng.lu: el registro es un libro de control y continuidad, no el soberano de la red. La prueba nace al reconciliar identidad, relación prevista y código o configuración realmente ejecutados.

La respuesta histórica de RIPEstat para 8.8.8.0/24 muestra visibilidad de AS15169 como origen durante el día consultado [4]. Su granularidad de ocho horas no resuelve una fuga de minutos y no se usa aquí como prueba del camino. El camino anormal se atribuye a la observación contemporánea de Cloudflare y la clasificación al RFC 7908.

Controles de cierre seguro

Toda sesión externa necesita políticas explícitas de importación y exportación. La ausencia de una política no debe equivaler a aceptar o anunciar la tabla completa. Una ruta de par no debe transformarse por defecto en ruta exportable a un proveedor.

El aprovisionamiento debe conservar ASN vecino, rol, prefijos u orígenes autorizados, límites, responsable, aprobación y caducidad de excepciones. La automatización debe generar la configuración a partir de ese registro y comparar periódicamente el resultado con el estado del router.

Los operadores deben vigilar el conjunto realmente anunciado. Un aumento brusco de rutas, un origen externo inesperado o una secuencia incompatible con el rol debe producir una alerta y, cuando el riesgo sea claro, un rechazo automático.

El RFC 9234, posterior al incidente, define BGP Roles y el atributo Only-to-Customer. Esos mecanismos hacen más legibles ciertas relaciones y pueden ayudar a detectar propagaciones incompatibles [3]. Son una referencia para controles actuales, no una afirmación sobre lo desplegado en 2012.

La observación externa completa el control. Un colector o una red remota puede ver que la ruta escapó incluso cuando cada operador considera correcta su vista local. Esa señal debe relacionarse con Adj-RIB-In, decisión local y Adj-RIB-Out, no sustituirlos.

Un cierre público verificable

El cierre debería publicar una cronología en UTC: primer síntoma, alerta interna, identificación de la ruta, contacto, detención del anuncio, retirada visible y estabilidad. También debería describir la clase de política que falló sin exponer secretos: ruta de par exportada a tránsito, filtro ausente o eludido y aceptación demasiado amplia.

La corrección debe tener prueba. Son útiles el estado previsto, la configuración generada, la huella del despliegue, una prueba negativa con una ruta equivalente, el umbral de alerta, el propietario del rollback y la verificación externa de la retirada. Recuperar el servicio cierra la urgencia; demostrar que el mismo camino será rechazado cierra el riesgo.

Fuentes

  1. https://blog.cloudflare.com/why-google-went-offline-today-and-a-bit-about/
  2. https://www.rfc-editor.org/rfc/rfc7908.txt
  3. https://www.rfc-editor.org/rfc/rfc9234.txt
  4. https://stat.ripe.net/data/routing-history/data.json?resource=8.8.8.0/24&starttime=2012-11-06T00:00:00&endtime=2012-11-07T00:00:00
  5. https://rdap.apnic.net/autnum/23947
  6. https://rdap.arin.net/registry/autnum/3491