Resumen

  • BGPMon relacionó los problemas de acceso a servicios de Google del 12 de marzo de 2015 con una fuga de rutas en la que prefijos originados por Google fueron aprendidos por Hathway AS17488 y filtrados hacia Airtel AS9498 [1].
  • La ventana observada fue corta, de 08:58 UTC a 09:14 UTC, pero BGPMon indicó que 336 prefijos IPv4 de Google resultaron afectados [1].
  • RFC 7908 citó después la fuga Hathway-Airtel como ejemplo de propagación de prefijos de par hacia un proveedor de tránsito, con interrupción de servicios de Google en Europa y Asia [2].
  • El artículo no presume intención maliciosa ni cuantifica pérdidas privadas. El foco está en filtros, relaciones, exportación, alarmas y evidencia de reparación.

Qué ocurrió

BGPMon presentó el incidente como una interrupción de servicio de Google visible en informes de usuarios y en datos de enrutamiento. Su análisis mostró que muchos caminos hacia prefijos de Google cambiaron entre 08:58 UTC y 09:14 UTC para incluir a Airtel AS9498 en India [1].

El detalle técnico clave es que los prefijos seguían siendo originados por Google AS15169. Por tanto, no era un secuestro simple de origen, en el que otra red fingiera ser Google. El fallo estaba en el camino de relación. BGPMon escribió que Google hacía peering con Hathway AS17488, que Hathway filtró esas rutas hacia su proveedor de tránsito Airtel AS9498, y que Airtel propagó los anuncios a pares en puntos de intercambio de Internet [1].

Para una operación de red, esa diferencia cambia la reparación. Un origen correcto no basta si una ruta sale de la relación en la que fue aprendida. Una red puede recibir una ruta para un uso limitado, pero no debe convertirla automáticamente en tránsito para otros vecinos.

Por qué importa

El incidente muestra cómo una plataforma global puede depender de decisiones de ruta tomadas fuera de su propia red. Google originaba los prefijos. Sin embargo, si una ruta aprendida en una relación limitada se entrega a un proveedor de tránsito y otros operadores la prefieren, los usuarios pueden experimentar problemas sin que Google haya cometido el error inicial de política.

También muestra una transferencia de costos. Un filtro permisivo puede ser cómodo para una relación cliente-proveedor porque reduce excepciones manuales. Pero cuando la ruta se amplifica, el costo de soporte, diagnóstico y continuidad se reparte entre redes y usuarios que no tenían control sobre esa relación.

La lección para RPKI es clara: la validación de origen no resuelve todos los escapes de ruta. Si el origen sigue siendo Google AS15169, una comprobación centrada solo en el origen puede pasar. La responsabilidad se desplaza al camino: quién aprendió la ruta, quién podía exportarla, quién la prefirió y qué prueba impide que el mismo tipo de ruta vuelva a propagarse.

La capa técnica

La forma más sencilla de entenderlo es como un libro de políticas de ruta. Cada operador necesita saber qué prefijos puede enviar cada cliente, par o proveedor, y hacia qué vecinos puede exportarse cada ruta. Una ruta aprendida de un par no debería convertirse en tránsito para otro par o proveedor. Una ruta aprendida de un cliente debe compararse con autorización de prefijos, objetos de ruta, caminos históricos y acuerdos explícitos.

BGPMon situó el camino en torno a Google AS15169, Hathway AS17488 y Airtel AS9498. También indicó que Airtel propagó los anuncios hacia pares en intercambios de Internet, y que algunas redes pudieron preferir el camino de Airtel porque las rutas de clientes suelen tener mayor preferencia que rutas de peering [1]. La zona de control se ubica entre economía de relación, preferencia local e higiene de exportación.

Las pruebas esperadas son concretas: listas de prefijos, route maps, límites max-prefix, etiquetas de relación, objetos IRR/RPKI, alarmas de fuga, hora de primer y último avistamiento, retiros y verificación posterior en colectores.

Quién resultó afectado

BGPMon dijo que los reportes indicaban principalmente usuarios europeos e indios, y RFC 7908 usó un lenguaje más amplio sobre interrupción de servicios de Google en Europa y Asia [1][2]. Vice presentó el episodio como una forma de explicar cómo el sistema mundial de rutas puede convertir decisiones de camino en una caída visible para usuarios [3].

Esas fuentes permiten hablar de impacto de alcanzabilidad, no de cifras inventadas. No prueban número exacto de usuarios, pérdidas comerciales ni que cada servicio de Google estuviera caído en todo el mundo. La evidencia pública más fuerte es el camino AS, el recuento de prefijos y la ventana temporal.

Qué vigilar

Lo primero es si los operadores pueden nombrar la clase de fallo: filtrado de prefijos de cliente, exportación de ruta aprendida de par, preferencia local, generación de objetos de ruta, excepción temporal o alarma ignorada. Una explicación genérica de "problema de enrutamiento" no demuestra cambio de control.

Lo segundo es si se usan controles sensibles a la relación. RFC 7908 definió el problema; mecanismos posteriores como BGP Roles, Only-to-Customer y enfoques tipo ASPA intentan codificar proveedor, cliente y par de forma más verificable.

Lo tercero es reconciliar colectores públicos con telemetría interna. Un evento visible durante dieciséis minutos debe poder compararse con logs de BGP, contadores, alertas, reportes de clientes y retiros de ruta.

Fuentes

[1] BGPMon, "What caused the Google service interruption?", https://www.bgpmon.net/what-caused-the-google-service-interruption/

[2] RFC 7908, "Problem Definition and Classification of BGP Route Leaks," https://www.rfc-editor.org/rfc/rfc7908.txt

[3] Vice, "Anatomy of a Globe-Spanning Google Outage," https://www.vice.com/en/article/anatomy-of-a-globe-spanning-google-outage/