Análisis de las demoras en la cadena de suministros de la validación de origen de rutas basada en RPKI
13/04/2023
Por Amreesh Phokeer, Internet Surveyor, Internet Society
¿Cuál es el ciclo de vida de los datos de la infraestructura de clave pública de recursos (RPKI, Resource Public Key Infrastructure) utilizada para proteger el enrutamiento de Internet? Más específicamente, ¿cuánto tiempo tarda en propagarse una autorización de origen de ruta (ROA, Route Origin Authorization) y qué tan rápido afecta el enrutamiento y la accesibilidad de Internet?
Estas son preguntas para las cuales los operadores de redes quisieran tener respuestas, ya que los cambios en el plano de gestión de RPKI pueden afectar la forma en que el tráfico fluye hacia o desde sus redes. Hace poco colaboré en un proyecto llamado Tiempo de vuelo en RPKI: análisis de las demoras en los planos de gestión, control y datos, cuyo objetivo era responder a estas preguntas analizando cada una de las etapas de la vida de los datos de RPKI.
A continuación, presentamos un resumen del ciclo de vida de RPKI y nuestros hallazgos.
Puntos clave: Los tiempos de creación varían significativamente entre los distintos Registros Regionales de Internet (RIR). El tiempo que lleva para que los nuevos ROA lleguen a los puntos de publicación va desde unos pocos minutos hasta más de una hora.Debido a un problema con las zonas horarias, en ARIN y LACNIC inicialmente se observaron grandes demoras en la publicación. Este problema fue reportado y ya ha sido solucionado. Los retrasos observados suelen ser inferiores a 20 minutos.Se observó que el retraso de la parte que confía (RP, Relying Party) es el paso que más tiempo lleva en el procesamiento de las ROA.La eliminación de ROA tarda más en reflejarse en el BGP, ya que los enrutadores exploran rutas alternativas que aún no han sido invalidadas.
Cadena de suministros de la validación de origen
Publicar las ROA es complejo. El proceso implica la participación de varios actores, no es instantáneo y suele estar dominado por decisiones administrativas ad hoc.
Comienza cuando un titular de recursos consulta a un RIR para crear o actualizar la información de RPKI para sus prefijos. Luego, las ROA y otros metaarchivos (manifiestos, CRL) se colocan en repositorios públicos llamados puntos de publicación.
Las RP recuperan y validan periódicamente todos los objetos de los repositorios de RPKI globales y después producen una lista de VRP (Validated ROA Payloads) validadas que los enrutadores usan para verificar los anuncios BGP entrantes. Los operadores que realizan validación de origen (sistemas autónomos que implementan ROV, en color verde en la Figura 1) recuperan estos cambios y utilizan esta nueva información para actualizar sus enrutadores. Solo entonces se empiezan a ver cambios en el plano de datos cuando los AS que implementan ROV aceptan o eliminan los anuncios de enrutamiento.
Figura 1. El flujo de datos desde que el titular del prefijo crea una ROA hasta las actualizaciones correspondientes del BGP se registra en los colectores de rutas (RIS/RouteViews). Las etiquetas rojas de la izquierda indican los puntos en los que se midió el tiempo.
El tiempo para crear o eliminar los ROV varía
Todos los pasos anteriores son comunes a todos los RIR y a todos los sistemas autónomos que implementan ROV, pero cada uno realiza (o puede realizar) estos pasos en diferentes intervalos de tiempo y con diferentes frecuencias.
Nuestro estudio encontró que los RIR generalmente publican la información nueva de RPKI en cinco minutos o menos, excepto APNIC, que fue en promedio diez minutos más lento (Tabla 1, columna 3). También observamos disparidades significativas en el tiempo de reacción de los ISP a la nueva información de RPKI, que varió desde unos pocos minutos hasta una hora.
| Sign (min) | NotBefore (min) | Publicación (min) | Parte que confía (min) | BGP (min) | |
| AFRINIC | 0 (0) | 0 (0) | 3 (2) | 14 (13) | 15 (16) |
| APNIC | 10 (13) | 14 (16) | 10 (13) | 34 (38) | 26 (28) |
| ARIN | – (-) | – (-) | 69 (97) | 81 (109) | 95 (143) |
| LACNIC | 0 (0) | – (-) | 54 (32) | 66 (42) | 51 (34) |
| RIPE | 0 (0) | 0 (0) | 4 (4) | 14 (13) | 18 (18) |
| Después del cambio | |||||
| ARIN | (-) | (-) | 8 (9) | 21 (22) | 28 (23) |
Encontramos que la demora es significativamente mayor al eliminar los ROA (Tabla 2, columna 4), excepto para ARIN y LACNIC (enseguida explicaré la razón de esta diferencia).
| Revocación (min) | Parte que confía (min) | BGP (min) | |
| AFRINIC | 0 (0) | 13 (14) | 34 (38) |
| APNIC | 10 (12) | 31 (36) | 51 (56) |
| ARIN | 0 (0) | 14 (16) | 45 (51) |
| LACNIC | 0 (0) | 18 (20) | 48 (49) |
| RIPE | 0 (0) | 14 (13) | 41 (50) |
Para la revocación de las ROA, observamos que el tiempo entre la eliminación de una ROA y su inaccesibilidad varía según la topología. Una vez más, las demoras en el BGP son significativamente mayores para la eliminación que para la creación de ROA. Probablemente esto se debe a que todos los vecinos deben retirar la ROA. Por ejemplo, la demora en el BGP por inaccesibilidad aumentó a 51 minutos para IPv4 y 56 minutos para IPv6, y rara vez observamos demoras cortas en el BGP.
Para esto propusimos dos posibles causas:
- El uso de múltiples de cachés (para redundancia) probablemente ralentizará más la eliminación que la creación de ROA.
- La búsqueda de caminos BGP (Figura 3): en algunos casos, observamos que el AS Path entre la sonda de RIPE Atlas y el destino cambió antes de que este quedara inalcanzable.
Problemas de ARIN y LACNIC con las zonas horarias
Antes de abril de 2022, las publicaciones de ARIN y LACNIC podían demorar varias horas debido a un problema de conversión de las zonas horarias.
Ambos RIR tenían la intención de configurar los valores NotBefore de las ROA a la medianoche. Sin embargo, ARIN venía configurando este valor a las 04:00 o 05:00 UTC (correspondiente a las 00:00 EDT y EST) y LACNIC a las 03:00 UTC (correspondiente a las 00:00 hora estándar de Uruguay).
Por ejemplo, una consulta realizada a la 01:00 UTC para crear una ROA en LACNIC creaba una ROA con un valor NotBefore de 03:00 UTC. Por lo tanto, el ROA era inválido durante las dos horas siguientes a su creación. Nuestro experimento reveló que el punto de publicación sabiamente no publica el ROA “aún no válido” en el repositorio, demorando así su disponibilidad para las partes que confían. Esto también era así en el caso de ARIN.
Cuando les informamos este problema, ARIN y LACNIC rápidamente lo reconocieron y solucionaron.
Mediciones en el plano de datos
A medida que se crean más ROA para proteger a los prefijos contra orígenes erróneos, uno se pregunta cuánto tardan los cambios en el RPKI en aparecer en el plano de datos.
Para responder esta pregunta, usamos un mecanismo de “alternancia de ROA”, donde utilizamos una ROA “invalidante” con AS666 para mantener el estado de validez RPKI de nuestros prefijos anunciados como “inválido”. Luego, cambiamos el estado de validez de RPKI ‘válido <-> inválido’ de los prefijos de prueba ya sea creando una ROA “de validación” con un AS de origen debidamente autorizado o bien eliminando la ROA.
Para probar la accesibilidad a nivel del plano de datos y la demora de los prefijos con alternancia de ROA, ejecutamos traceroutes cada 15 minutos desde RIPE Atlas con sondas en seis sistemas autónomos diferentes. Al crear un “ROA de validación”, la demora entre la consulta del usuario y la accesibilidad del plano de datos es similar al BGP. Observamos que la mediana de la demora estaba comprendida entre 23 minutos (RIPE) y 50 minutos (APNIC).
Para la revocación de las ROA, observamos que el tiempo entre la eliminación de una ROA y su inaccesibilidad varía según la topología. Una vez más, las demoras en el BGP son significativamente mayores para la eliminación que para la creación de ROA. Por ejemplo, el retraso de BGP por inaccesibilidad sube a 51 minutos para IPv4 y 56 minutos para IPv6, y rara vez observamos demoras cortas en el BGP. Para esto propusimos dos posibles causas:
- La búsqueda de caminos BGP (Figura 3): en algunos casos, observamos que el AS Path entre la sonda de RIPE Atlas y el destino cambió antes de que este quedara inalcanzable.
Demoras en las RP: ¿Un potencial cuello de botella?
Las partes que confían obtienen periódicamente datos de RPKI de los puntos de publicación.
Descubrimos que las demoras en las RP representan el paso que más tiempo consume en el procesamiento de las ROA. La demora entre la creación de una ROA y el momento en que una RP valida la nueva ROA era en general de menos de 15 minutos para la mayoría de los RIR. Esto representa 10 minutos más que la demora en la publicación y consistía principalmente en:
- Intervalo de sondeo (en promedio, 5 minutos de demora)
- Tiempo de descarga desde todas las Autoridades de Certificación (4 minutos)
- Tiempo de procesamiento de la ROA (1 minuto).
Otros factores que pueden afectar las demoras en las RP incluyen los tiempos de descarga variables debido a las condiciones de la red, los tiempos de espera de los puntos de publicación y la falta de operación en paralelo (multi-threading) en algunas de las implementaciones de las RP.
Si desea obtener más información sobre nuestra metodología y hallazgos, consulte nuestro paper y nuestro GitHub.
Este estudio fue financiado en parte por el programa de becas MANRS y fue una colaboración entre IIJ Research Lab, Internet Society, UCLouvain, LAAS-CNRS y Arrcus Inc.
Colaborador: Romain Fontugne.
Las opiniones expresadas por los autores de este blog son propias y no necesariamente reflejan las opiniones de LACNIC.