En este artículo, Doug Madory de Kentik y Job Snijders de Fastly, dos expertos en BGP, repasan las últimas métricas de despliegue de validación de origen (ROV) con RPKI a la luz de un hito importante.
A partir de hoy, 1.º de mayo de 2024, la seguridad del enrutamiento de Internet superó un mojón significativo. Por primera vez en la historia de RPKI (infraestructura de clave pública de recursos), la mayoría de las rutas IPv4 en la tabla de enrutamiento global están cubiertas por autorizaciones de origen de ruta (ROA), de acuerdo con el monitor de RPKI del NIST. IPv6 superó este hito a finales del año pasado.
Aprovechemos este momento para actualizar las cifras de adopción de validación de origen de rutas (ROV) con RPKI que venimos publicando en los últimos años.
Como probablemente sepan, la validación de origen de rutas con RPKI sigue siendo la mejor defensa contra los secuestros de BGP accidentales y las fugas de origen. Para que ROV haga su trabajo (rechazar rutas no válidas para RPKI), hay dos pasos:
(Acceso libre, no requiere suscripción)
Hay que crear las ROA
Los AS deben rechazar las rutas que no sean coherentes con las ROA.
La primera parte de este análisis comenzó cuando exploramos el primer paso de ROV: Creación de ROA. Hace dos años, Doug presentó en NANOG 84 un análisis que mostraba que en realidad estábamos más avanzados en la creación de ROA de lo que mostraba un simple análisis del BGP. Utilizando el NetFlow agregado de Kentik, demostró que la mayoría del tráfico (medido en bits/seg) se dirigía a rutas con ROA, a pesar de que solo un tercio de las rutas BGP tenían ROA.
Esta discrepancia se debía a que los principales proveedores de contenido y redes eyeball habían desplegado RPKI en los últimos años y representan una parte desproporcionada del volumen de tráfico de Internet. Obviamente, el volumen de tráfico no es el único criterio para hablar de logro: hay mucho tráfico que es crítico, pero no de gran volumen (por ejemplo, DNS). La idea era simplemente presentar otra dimensión para valorar nuestro avance en el despliegue de la validación de origen de rutas con RPKI.
Para medir el segundo paso de ROV (rechazar las rutas no válidas), observamos las diferencias en la propagación considerando la evaluación de las rutas con RPKI. En ese momento, la conclusión fue que las rutas no válidas podrían lograr una propagación menor al 50% de las fuentes BGP en RouteViews, el repositorio público de BGP de la Universidad de Oregón. Muchas veces las rutas no válidas se propagan mucho menos que el 50%; todo depende de los prefijos aguas arriba.
Hay que crear las ROA
Los AS deben rechazar las rutas que no sean coherentes con las ROA.
La primera parte de este análisis comenzó cuando exploramos el primer paso de ROV: Creación de ROA. Hace dos años, Doug presentó en NANOG 84 un análisis que mostraba que en realidad estábamos más avanzados en la creación de ROA de lo que mostraba un simple análisis del BGP. Utilizando el NetFlow agregado de Kentik, demostró que la mayoría del tráfico (medido en bits/seg) se dirigía a rutas con ROA, a pesar de que solo un tercio de las rutas BGP tenían ROA.
Esta discrepancia se debía a que los principales proveedores de contenido y redes eyeball habían desplegado RPKI en los últimos años y representan una parte desproporcionada del volumen de tráfico de Internet. Obviamente, el volumen de tráfico no es el único criterio para hablar de logro: hay mucho tráfico que es crítico, pero no de gran volumen (por ejemplo, DNS). La idea era simplemente presentar otra dimensión para valorar nuestro avance en el despliegue de la validación de origen de rutas con RPKI.
Para medir el segundo paso de ROV (rechazar las rutas no válidas), observamos las diferencias en la propagación considerando la evaluación de las rutas con RPKI. En ese momento, la conclusión fue que las rutas no válidas podrían lograr una propagación menor al 50% de las fuentes BGP en RouteViews, el repositorio público de BGP de la Universidad de Oregón. Muchas veces las rutas no válidas se propagan mucho menos que el 50%; todo depende de los prefijos aguas arriba.
La drástica reducción en la propagación de rutas no válidas para RPKI se puede atribuir principalmente a los proveedores de backbone Tier 1 que las rechazan. Estos proveedores tienen una enorme influencia en el enrutamiento de Internet. De todos modos, la reducción en la propagación significa que la ROV con RPKI está haciendo su trabajo: suprimir las rutas problemáticas para que no provoquen interrupciones.
Estado actual de la creación de ROA
Como ya se mencionó, ahora más del 50% de las rutas IPv4 en la tabla de enrutamiento global tienen ROA (autorización de origen de rutas) y se evalúan como válidas (52% en el caso de las rutas IPv6). Veamos qué significa esto para el NetFlow agregado de Kentik.
Según nuestro análisis de hace dos años, alrededor de un tercio de las rutas tenían ROA y poco más del 50% del tráfico de Internet era “válido” (tráfico a rutas evaluadas como válidas en bits/segundo). Ahora que más de la mitad de las rutas IPv4 tienen ROA, nuestro NetFlow agregado actual muestra que el 70,3% del tráfico de Internet es válido.
¿Cuánto más puede aumentar esta métrica? Eso está por verse. Como se muestra a continuación en otro diagrama del NIST, la pendiente ascendente del porcentaje de rutas con ROA se ha mantenido estable durante los últimos cuatro años. Es lógico que con el tiempo veamos que la pendiente se aplana a medida que ya no sea tan fácil seguir avanzando. Sin embargo, es importante reconocer el avance logrado hasta la fecha.
Estado actual de la propagación de rutas no válidas
El avance en la creación de ROA es inútil si las redes no rechazan las rutas BGP no válidas para RPKI. Por lo tanto, el siguiente paso para comprender cómo vamos con la adopción de ROV con RPKI es comprender mejor hasta qué punto Internet rechaza las rutas no válidas para RPKI.
Entre los proveedores de tránsito más grandes de Internet (es decir, proveedores sin tránsito), prácticamente todos rechazaban las rutas no válidas para RPKI cuando publicamos nuestro artículo titulado How much does RPKI ROV reduce the propagation of invalid routes? Por lo tanto, concluimos que evaluar una ruta como no válida reduce su propagación entre un 50% y un 65%.
Dos años después, podemos analizar cómo evolucionó esta métrica. Utilizando datos históricos de RPKI disponibles a través del sitio RPKIviews de Job y datos de enrutamiento BGP de RouteViews, evaluamos la tabla de enrutamiento global IPv4 todos los meses desde principios del 2022 para determinar cómo la propagación de rutas no válidas para RPKI fue cambiando con el tiempo.
Es importante recordar que en esta metodología medimos la propagación de una ruta al contar cuántos puntos de observación de RouteViews contienen la ruta en sus tablas. Más puntos de observación significa una mayor propagación. Si desea saber más sobre este enfoque, consulte nuestro análisis de propagación de rutas no válidas.
El siguiente gráfico muestra el número promedio de puntos de observación de RouteViews para cada ruta no válida para RPKI en función del tiempo. Para evitar las rutas internas compartidas con los puntos de observación de RouteViews, solo incluimos las rutas vistas por al menos 10 puntos de observación. Al inicio del gráfico, identificamos 4978 rutas no válidas para RPKI que fueron vistas, en promedio, desde 82,5 puntos de observación. El último dato del 1.º de abril del 2024 indica 4211 rutas no válidas para RPKI vistas desde 62,5 puntos estratégicos. Notar que utilizamos un prefijo enrutado globalmente conocido (8.8.8.0/24 de Google) como prefijo de control para ver los efectos de los cambios temporales en el número de puntos de observación de RouteViews.
El principal desafío de este tipo de análisis es que hay bastante “ruido”. El conjunto de rutas persistentemente no válidas para RPKI no permanece constante y la propagación está muy influenciada por los proveedores que transitan una ruta. Dejando a un lado esos desafíos, el análisis anterior muestra que la propagación de rutas no válidas para RPKI disminuyó un 24% desde principios de 2022.
Para estudiar este fenómeno en mayor profundidad, podemos analizar el enrutamiento de rutas intencionalmente no válidas para RPKI a lo largo del tiempo y ver que su propagación también disminuye.
RIPE NCC anuncia numerosas “balizas de enrutamiento” (routing beacons) con fines de medición. Estas incluyen rutas que intencionalmente son inválidas para RPKI (y otra que son válidas para RPKI a modo de control). Para no quedarse atrás, Job también anuncia rutas no válidas para RPKI junto con una ruta de control desde su red, AS15562.
La figura siguiente muestra la cantidad de puntos de observación de RouteViews para cada una de estas rutas de medición en función del tiempo. Las curvas correspondientes a las rutas no válidas para RPKI aparecen en la parte inferior de los gráficos, lo que condice con nuestra observación de que las rutas no válidas para RPKI se propagan significativamente menos.
Los tres gráficos en esta figura muestran una disminución apreciable del número de puntos que observan las diferentes rutas no válidas para RPKI. Esta disminución coincide con la caída del número promedio de puntos que observan una ruta RPKI determinada de la figura anterior.
De este análisis se desprende una última observación. En el panel de la derecha (“Job’s Beacons”), hay dos rutas no válidas para RPKI con grados de propagación un poco diferentes.
La ROA de 209.24.0.0/24 (verde) está publicada a través del TAL de ARIN, mientras que la de 194.32.71.0/24 (naranja) es accesible a través del TAL de RIPE. Un TAL es un archivo con una clave pública que utilizan las partes que confían para recuperar datos RPKI de un repositorio.
El problema es que para utilizar el TAL de ARIN puede que sea necesario aceptar un extenso Acuerdo de parte que confía, algo que algunos proveedores no están dispuestos a hacer. Por lo tanto, las ROA publicadas por ARIN son vistas por un número ligeramente menor de redes que rechazan rutas no válidas para RPKI, lo que disminuye la eficacia de RPKI para el espacio IP administrado por ARIN.
La fuerte cláusula de indemnización de ARIN surge de su preocupación por posibles demandas derivadas de los datos que publican en el RPKI. Esta barrera para la adopción de ROV con RPKI se discutió en un artículo académico publicado en 2019, Lowering Legal Barriers to RPKI Adoption, de los profesores Christopher S. Yoo y David A. Wishnick de la Universidad de Pensilvania.
Pero volvamos al avance que estamos viendo en el rechazo de las rutas no válidas para RPKI.
Al comienzo de esta sección, mencionamos que, a excepción de dos, todos los proveedores sin tránsito estaban rechazando las rutas no válidas para RPKI. El mes pasado se produjo otro hito: este número se redujo a uno cuando el operador de telecomunicaciones estadounidense Zayo (AS6461) empezó a rechazar las rutas no válidas para RPKI de sus clientes.
En el 2022, Zayo anunció que había empezado a rechazar las rutas no válidas para RPKI de quienes no tenían un acuerdo de peering igualitario gratuito. Sin embargo, dado que casi todos los “grandes” con quienes hacían peering ya estaban rechazando esas rutas, el impacto fue relativamente pequeño.
Pero el 1.º de abril empezamos a ver que el AS6461 comenzaba a rechazar las rutas no válidas para RPKI de los clientes por primera vez. En el gráfico de Kentik a continuación, la ruta no válida para RPKI 103.36.106.0/24 dejó de ser transitada por el AS6461 a las 16:24 UTC.
Zayo desplegó el rechazo de las rutas no válidas para RPKI por etapas y en un par de semanas empezamos a ver que otras partes de su red global también las rechazaban. A las 18:54 UTC del 12 de abril, observamos que el AS6461 empezaba a rechazar las balizas no válidas para RPKI de RIPE, 93.175.147.0/24 y 2001:7fb:fd03::/48, por primera vez.
Una vez finalizado el despliegue, esperamos que el hecho de que Zayo rechace las rutas no válidas para RPKI de su base de clientes continúe reduciendo la propagación de estas rutas problemáticas, lo que a su vez disminuirá el riesgo de interrupción o desvío del tráfico debido a diferentes tipos de contratiempos en el enrutamiento.
Por último, en caso de que queden dudas sobre el grado de rechazo de las rutas no válidas, recomendamos leer sobre la caída del servicio que sufrió Orange España en el mes de enero. Resumí este incidente en un artículo que se publicó el día después del ataque.
Utilizando una contraseña que encontró en una filtración pública de credenciales robadas, un hacker pudo iniciar sesión en el portal de RIPE NCC como Orange España utilizando la contraseña “ripeadmin”. ¡Ups! Una vez que ingresó al sistema, el hacker empezó a modificar la configuración de RPKI de Orange España, con lo cual muchas de sus rutas BGP dejaron de ser válidas para RPKI.
El uso de RPKI como herramienta para la denegación de servicio solo fue posible gracias al amplio rechazo de las rutas no válidas para RPKI por parte de los ASN.
La propagación de una ruta de Orange España se redujo a menos del 20% durante el ataque.
Conclusión: Beneficios del despliegue de RPKI
En un artículo que escribimos un año atrás, fuimos audaces y pronosticamos lo siguiente:
Si asumimos un crecimiento constante de la proporción de rutas BGP con ROA, este debería ser el caso mayoritario dentro de aproximadamente un año (mayo del 2024). ¡Anótenlo en sus calendarios!
En diciembre, hicimos una encuesta para preguntarles a otros nerds de BGP en Twitter/X y LinkedIn cuándo pensaban que llegaríamos a este mojón y ellos fueron bastante más pesimistas que nuestro pronóstico:
El avance que se detalla en este artículo llevó años e involucró los esfuerzos dedicados de cientos de ingenieros en decenas de empresas. Mejorar la seguridad del sistema global de enrutamiento de Internet no es una tarea menor y es un esfuerzo que durará muchos años más.
Cada una de las dos líneas de análisis de esta publicación debería servir como motivación para que otras redes desplieguen validación de origen de rutas con RPKI.
Rechazar rutas BGP no válidas para RPKI en las sesiones EBGP. Dado que la mayoría de las rutas de Internet están cubiertas por ROA (incluida una gran mayoría del tráfico), los operadores de redes deben rechazar las rutas no válidas para RPKI para así evitar que el tráfico de los clientes salga por error hacia rutas mal originadas.
Crear ROA. Dada la gran proporción de rutas no válidas para RPKI que se suprimen, sería beneficioso para los titulares de recursos crear ROA para sus rangos de direcciones de manera de permitir que las redes de todo el mundo rechacen automáticamente las rutas mal originadas.
¡Las redes que lo hacen disfrutan inmediatamente de los beneficios!
Pero la validación de origen de rutas con RPKI no resuelve todos los problemas en torno a la seguridad del enrutamiento de Internet. De hecho, esto es apenas un comienzo para abordar los diferentes escenarios de “adversario determinado”, mejor caracterizados por los recientes ataques contra los servicios de criptomonedas. Estos ataques aprovechan las debilidades existentes en la seguridad de Internet, por lo que deberemos trabajar para limitarlas, aprovechando el avance logrado con ayuda de mecanismos de seguridad del enrutamiento como ROV con RPKI.
Las opiniones expresadas por los autores de este blog son propias y no necesariamente reflejan las opiniones de LACNIC.
