Resumen

  • Al pasar de Invalid a Valid, las redes con varios proveedores recuperaron alcance desde la mitad de los puntos de medición en una mediana de nueve minutos; las de un solo proveedor tardaron doce.
  • Al pasar de Valid a Invalid, la mediana se invirtió: la mitad de los puntos dejó de alcanzar la ruta en 42 minutos con multihoming y en 30 minutos con un solo proveedor.

Dos puertas de salida pueden devolver una ruta antes y mantenerla en escena después de que su autorización ha cambiado. No es indecisión de Internet: cada proveedor actualiza su vista de RPKI con su propio calendario.

La charla de RIPE 93 midió cuánto tardaba un cambio de estado RPKI en reflejarse en el plano de datos. El estudio siguió unos 25.000 cambios del repositorio de RIPE que modificaron payloads validados y aisló alrededor de 1.500 eventos simples, adecuados para observar una sola transición de accesible a inaccesible o al revés. Tras detectar cada cambio, lanzó traceroutes desde más de 300 nodos CAIDA Ark durante una hora.

El cronómetro no arrancaba cuando alguien editaba el ROA ni cuando el primer validador lo descargaba. Medía cuándo la mitad de los puntos participantes volvía a alcanzar el prefijo o dejaba de hacerlo. Una base de datos puede actualizarse antes de que lo haga la red que transporta el tráfico.

La vuelta corre más con un segundo proveedor

Cuando una ruta pasaba de Invalid a Valid, las redes con varios proveedores alcanzaban el umbral del 50% de los puntos de medición en nueve minutos de mediana. Las redes conectadas a un solo proveedor necesitaban doce. El proveedor adicional abría otra posibilidad de que uno de sus validadores ya hubiera descargado y procesado el objeto nuevo.

La mediana no cuenta toda la historia: la cola lenta también fue más corta para las redes multihomed. Cada proveedor ejecuta su propio software relying-party y su propio ciclo de descarga. Dos ciclos independientes multiplican las oportunidades de que algún camino se entere antes de que la ruta está autorizada.

La red no vuelve válido el ROA por tener más proveedores. El ROA declara una autorización de origen; el validador calcula un estado a partir de los objetos publicados. La diferencia medida aparece después, cuando los proveedores y sus routers procesan ese estado nuevo.

La salida tarda más

Con la transición inversa, el orden cambió. Cuando una ruta antes válida pasó a Invalid, las redes de un solo proveedor tardaron 30 minutos de mediana en llevar a la mitad de los puntos al estado sin alcance. Las multihomed tardaron 42.

La ruta alternativa sigue haciendo su trabajo. Si un proveedor ya actualizó su vista de RPKI y cambia el tratamiento de la ruta, otro todavía puede anunciarla porque su validador no ha descargado el nuevo estado. Cuantos más caminos independientes haya, más oportunidades quedan para que alguno siga visible durante la transición.

En un incidente, Invalid no funciona como un botón mundial de apagado. Cada red aplica su propia política y los validadores no descargan los datos al mismo tiempo. BGP sigue eligiendo entre los anuncios disponibles. El plano de control puede mostrar un estado nuevo mientras el plano de datos todavía transporta tráfico.

El estudio midió casos de origen único y excluyó rutas cubiertas por un anuncio menos específico. Los traceroutes duraron una hora. La cifra describe esos casos y esa ventana; no es una cuenta atrás universal para todas las rutas.

Una actualización, varios relojes

Entre cambiar un ROA y alterar el alcance de una ruta hay varios pasos: publicación en el repositorio, descarga por el validador, cálculo del estado, entrega a los routers, aplicación de la política local y estabilización del plano de datos.

El equipo obtuvo una señal temprana vigilando el origen del repositorio de RIPE y usando un validador optimizado. Según el ponente, la señal llegó al menos 57 segundos antes que la de los validadores públicos comparados, y cinco minutos antes en la mediana. Así pudieron iniciar traceroutes antes de que reaccionara buena parte de la red. Fue una técnica de medición; no significa que RIPE NCC programe el intervalo de descarga de todos los validadores.

Para los operadores, «RPKI actualizado» no describe un solo nivel de servicio. Una hora de publicación no puede contestar por todos los proveedores cuándo surtió efecto una corrección. Y si un equipo espera que Invalid frene de inmediato un secuestro de ruta, la mediana de 30 a 42 minutos deja una ventana larga en la que algunos puntos todavía veían el prefijo.

Fuentes: Resumen y grabación de RIPE 93; transcripción oficial de la plenaria; RFC 6811, validación de origen de prefijos BGP.