Resumen

  • Cloudflare informó que, alrededor de las 10:30 UTC del 24 de junio de 2019, una compañía pequeña se volvió un camino preferido para muchas rutas a través de Verizon AS701, incluidas rutas relacionadas con Cloudflare [1].
  • El análisis posterior de Cloudflare vinculó el problema con una capa de optimización de rutas y con la propagación por un gran proveedor de tránsito [2].
  • Noction publicó una respuesta porque su producto de optimización era parte de la discusión pública, lo que ayuda a separar intención del producto y gobierno del despliegue [3].
  • ThousandEyes/Catchpoint observó efectos externos de alcanzabilidad para usuarios de Cloudflare, anclando el impacto en mediciones públicas [4].
  • RFC 7908 y RFC 9234 explican por qué esta clase de evento es una fuga de relación BGP y por qué los roles explícitos y Only-to-Customer importan [6][7].

Qué ocurrió

Cloudflare describió un patrón en el que muchas rutas fueron enviadas por Verizon después de que una empresa pequeña apareció como camino preferido. En BGP, el problema público no fue simplemente que una red anunciara algo. El problema fue que otras redes trataron ese anuncio como utilizable y lo exportaron más allá de la relación donde pertenecía. Una mala ruta se vuelve incidente de Internet cuando las redes vecinas la aceptan, la prefieren y la vuelven a anunciar.

DQE importa por esa razón. Aunque Verizon era el proveedor grande en el titular, la cadena comenzó en una frontera de cliente, optimizador y tránsito. Un optimizador de rutas puede seleccionar caminos por precio, latencia o disponibilidad; también puede crear riesgo si su salida se acepta como evidencia ordinaria de rutas de cliente. La automatización no elimina la responsabilidad cuando puede influir en rutas exportadas.

Por qué importa

Una fuga de ruta puede conservar un origen válido y aun así violar la relación en medio del camino. Por eso RPKI Origin Validation ayuda, pero no basta. La reparación responsable tiene que incluir evidencia de relación, política de importación, política de exportación, límites de prefijos, monitoreo de anomalías y controles de fuga de rutas.

Las fuentes públicas pueden mostrar que ocurrió un evento de enrutamiento. No pueden sustituir los mapas de ruta, tickets de cambio, configuración del optimizador, registros de aceptación ni decisiones internas. Esa frontera evita conclusiones exageradas: no prueba intención de DQE, de Noction o de Verizon. Sí sostiene que la cadena de aceptación fue lo bastante débil para que una fuga del lado del cliente se propagara por un proveedor mayor.

La capa técnica

RFC 7908 define esta familia como propagación de rutas que rompe la relación prevista entre redes. RFC 9234 muestra una dirección de reparación: hacer explícitos los roles de proveedor, cliente y par mediante BGP Roles y Only-to-Customer. No repara todo por sí solo, pero convierte una suposición oculta en evidencia de protocolo.

Una investigación sólida debería enumerar prefijos, AS paths, hora de inicio y fin, ubicaciones de los colectores, sesiones BGP, filtros aplicados, límites de prefijos, objetos IRR, validación RPKI y mensajes de retiro. También debería explicar por qué una red cliente pudo parecer camino para rutas que no eran propias.

Quién se ve afectado

Los usuarios afectados son aquellos cuyas redes eligieron el camino filtrado o vieron degradación por la selección de ruta. Las fuentes no dan una lista completa de cada transacción. Por eso el daño debe medirse con duración, prefijos afectados, latencia, pérdida y alcance de propagación, no con una etiqueta universal de interrupción.

Qué vigilar

Conviene vigilar sesiones de cliente que exportan rutas fuera de su conjunto normal, optimizadores que cambian best path sin límites de relación, proveedores grandes que aceptan rutas anormales de clientes y cierres de incidente que no revelan clase de fuga, duración, prefijos y controles de recurrencia.

Sources

  1. https://blog.cloudflare.com/how-verizon-and-a-bgp-optimizer-knocked-large-parts-of-the-internet-offline-today/
  2. https://blog.cloudflare.com/the-deep-dive-into-how-verizon-and-a-bgp-optimizer-knocked-large-parts-of-the-internet-offline-monday/
  3. https://www.noction.com/news/incident-response
  4. https://www.thousandeyes.com/blog/cloudflare-users-burned-by-internet-routing-pile-up
  5. https://www.kentik.com/blog/a-brief-history-of-the-internets-biggest-bgp-incidents/
  6. https://www.rfc-editor.org/rfc/rfc7908
  7. https://www.rfc-editor.org/rfc/rfc9234