Resumen

  • En el caso SingNet–Innove de 2025, el looking glass de SEACOM tenía una ruta válida para 203.127.0.0/16 y ninguna para el /24 anunciado sin autorización. Una traza desde SEACOM, sin embargo, llegó a saltos del AS de Innove.
  • El control ROV de SEACOM no podía imponer a TISparkle la misma política. Una vez que el paquete entraba en ese vecino, su ruta más específica podía cambiar el destino.
  • BMP sirve para registrar las vistas BGP de los pares vigilados; ni da acceso automático al vecino ni prueba por sí solo el camino que recorrió el tráfico.

Dos respuestas correctas para dos preguntas distintas

Una herramienta de diagnóstico devolvió «Network not in table» al buscar 203.127.225.0/24 en SEACOM (AS37100). Otra consulta al mismo looking glass mostró el bloque mayor 203.127.0.0/16 con origen SingNet (AS3758). Si el objetivo era saber si el operador había instalado localmente el subprefijo de Innove Communications (AS17894), la respuesta era no. Pero ese no era el final de la trayectoria.

Los investigadores que publicaron la captura original lanzaron un traceroute desde SEACOM a 203.127.225.1. Registraron saltos de TISparkle (AS6762), FLAG Telecom (AS15412), Globe Telecom (AS4775) y finalmente AS17894. El resultado da una prueba de camino mucho más concreta que el mero aspecto limpio de la tabla, aunque no mide todas las sesiones de los usuarios ni demuestra que la aplicación final respondiera. El documento es un Internet-Draft individual, no una norma aprobada; sus autores comunicaron el caso a Globe el 10 de febrero de 2025, lo observaron hasta el 24 de abril y consideraron probable un error de configuración, sin atribuir intención maliciosa.

Ritesh Mukherjee retomó el episodio en la sesión técnica de APNIC 62. Sus diapositivas llaman a esto el problema del «buen vecino». No se trata de que ROV en SEACOM fallase al clasificar el /24. Se trata de que otra red tomó una decisión distinta sobre la misma información, con efectos para los paquetes que SEACOM le entregaba.

El salto que un ROA no gobierna

Innove anunciaba el /24 con un origen no autorizado, mientras SingNet anunciaba legítimamente el /16. RFC 6811 permite clasificar el origen mediante autorizaciones ROA validadas, pero deja a la política local la acción ante Invalid. SEACOM descartaba el subprefijo y podía elegir la ruta del /16 hacia AS6762. Al llegar allí, si TISparkle aceptaba el /24, la regla de prefijo más largo llevaba el paquete por el camino más estrecho. Un filtro local correcto no instala reglas en el router ajeno.

El contraste con Telegram ayuda a no llamar idénticos a dos incidentes. El 16 de junio de 2026, varios prefijos normalmente originados por redes de Telegram aparecieron con origen AS18101. BGPHorizon ofrece un evento verificable para 91.108.4.0/22 a las 07:17:27 UTC: origen observado AS18101 frente al AS62041 esperado, cuatro redes pares y cinco colectores, además de una segunda oleada de rutas más específicas. Esa evidencia documenta anuncios y propagación visible, no una cifra de usuarios afectados ni una motivación política. El caso Vodafone Idea de 2021, también incluido en la charla, añade el problema de aceptar una gran cantidad de rutas de un cliente; un límite de prefijos puede reducir ese volumen, pero no detectar por sí mismo un solo /24 falso.

No convertir la telemetría en testigo ocular

Mukherjee propone BMP en Adj-RIB-In y presenta RAVEN, una herramienta de Nokia. RFC 7854 distingue anuncios anteriores y posteriores a la política para los pares que el router haya configurado como vigilados. Permite reconstruir una oferta rechazada cuando se dispone de la vista adecuada. Sin embargo, los cambios pueden comprimirse, el tiempo de origen puede faltar y el colector puede no abarcar todos los pares. Incluso una vista local perfecta no incluye un anuncio recibido solo por TISparkle. Tampoco indica qué entrada instaló en su FIB ni por dónde salió cada paquete.

Un traceroute y el registro del vecino cubren preguntas diferentes de la captura BMP; correlacionarlos exige identificar router, par, familia de direcciones, etapa RIB, época del volcado y posibles pérdidas. El repositorio de RAVEN describe capacidades de observación y simulación. No ofrece una medición de uso en los operadores de este caso ni una demostración de que el producto lo hubiese prevenido. La salida de ejemplo en la presentación está marcada como ilustrativa.

ROV, límite de prefijos y ASPA tampoco son tres nombres para una sola barrera. RFC 7454 recomienda umbrales por sesión adecuados al crecimiento esperado; son un cortacircuitos ante una avalancha. La validación ASPA sigue en desarrollo para relaciones de proveedor en el AS_PATH. Ninguno de esos mecanismos sustituye la prueba de que un vecino concreto rechazó la ruta o de que el tráfico dejó de seguirla.

Base documental y alcance

La comparación esencial procede del borrador de Li y colaboradores, sección 4 y anexo A. APNIC documentó la charla; BGPHorizon aporta la reconstrucción separada de Telegram. RFC 6811, RFC 7854 y RFC 7454 fijan los límites técnicos. No hay aquí una medición completa de pérdidas, intención, adopción regional actual o eficacia desplegada de RAVEN.