Por qué los ROA de RPKI siempre están a punto de expirar
17/06/2024
Escrito por Doug Madory & Job Snijders
Este artículo fue originalmente publicado en Kentik Blog
Resumen
En RPKI, determinar exactamente cuándo vence un ROA no es nada fácil. En esta nota, Doug Madory y Job Snijders de Fastly, dos expertos en BGP, analizan la diferencia entre las fechas de vencimiento indicadas en los ROA y las fechas de vencimiento efectivas utilizadas por los validadores, que son significativamente más cortas. También examinamos cómo las fechas de vencimiento efectivas cambian su comportamiento con el tiempo debido a diferencias de implementación a lo largo de la cadena de autoridades certificadoras.
En nuestra anterior colaboración sobre RPKI, celebramos el hito más reciente en la adopción de ROV (validación de origen de rutas) con RPKI: más del 50 % de las rutas IPv4 ya tienen ROA (autorizaciones de origen de ruta). En este artículo, analizaremos más detalladamente la mecánica de RPKI para comprender cómo la cadena criptográfica contribuye a la fecha de vencimiento efectiva de un ROA.
En RPKI, un ROA es un registro firmado criptográficamente que guarda el número de sistema autónomo (ASN) autorizado para originar un rango de direcciones IP en BGP. Junto con el ASN y uno o más prefijos de direcciones IP, el ROA también contiene un certificado de entidad final X.509 que —entre otras cosas— especifica la ventana de validez, es decir, las marcas de tiempo después y antes de las cuales el ROA es válido.
Si bien las fechas de vencimiento de algunos ROA individuales pueden ser dentro de un año, las fechas de vencimiento efectivas que utilizan los validadores de RPKI suelen ser dentro de unas pocas horas o de unos días. Esto se debe a que estas fechas de vencimiento efectivas son transitivas, es decir, son determinadas por la fecha de vencimiento más próxima de todos los eslabones de la cadena criptográfica.
Para entender cómo funciona, primero tenemos que ver qué implica ‘firmado criptográficamente’ en la definición de ROA ya presentada en esta nota.
Usando rpki-client, la herramienta de consola de Job, podemos investigar el ROA para 151.101.8.0/22 que afirma que AS54113 está autorizado para originar este prefijo IPv4.
asID: 54113
IP address blocks: 151.101.8.0/22 maxlen: 22Además, en ese primer bloque están nuestras primeras fechas relacionadas con la validez de este ROA.
Signing time: Sat 11 May 2024 01:00:27 +0000
ROA not before: Sat 11 May 2024 01:00:27 +0000
ROA not after: Fri 09 Aug 2024 01:00:27 +0000Por lo tanto, este ROA es válido hasta agosto del 2024, siempre que todos los demás elementos de la cadena también sean válidos hasta agosto del 2024. Aquí es donde entra en juego la siguiente sección Signature path.
Validation: OK
Signature path: rsync://rpki.arin.net/repository/arin-rpki-ta/5e4a23ea-e80a-403e-b08c-2171da2157d3/871da40f-793a-4a45-a0a9-978148321a07/e605f279-55f4-48ec-ba13-4845c0973a63/e605f279-55f4-48ec-ba13-4845c0973a63.crl
rsync://rpki.arin.net/repository/arin-rpki-ta/5e4a23ea-e80a-403e-b08c-2171da2157d3/871da40f-793a-4a45-a0a9-978148321a07/e605f279-55f4-48ec-ba13-4845c0973a63/e605f279-55f4-48ec-ba13-4845c0973a63.mft
rsync://rpki.arin.net/repository/arin-rpki-ta/5e4a23ea-e80a-403e-b08c-2171da2157d3/871da40f-793a-4a45-a0a9-978148321a07/e605f279-55f4-48ec-ba13-4845c0973a63.cer
rsync://rpki.arin.net/repository/arin-rpki-ta/5e4a23ea-e80a-403e-b08c-2171da2157d3/871da40f-793a-4a45-a0a9-978148321a07/871da40f-793a-4a45-a0a9-978148321a07.crl
rsync://rpki.arin.net/repository/arin-rpki-ta/5e4a23ea-e80a-403e-b08c-2171da2157d3/871da40f-793a-4a45-a0a9-978148321a07/871da40f-793a-4a45-a0a9-978148321a07.mft
rsync://rpki.arin.net/repository/arin-rpki-ta/5e4a23ea-e80a-403e-b08c-2171da2157d3/871da40f-793a-4a45-a0a9-978148321a07.cer
rsync://rpki.arin.net/repository/arin-rpki-ta/5e4a23ea-e80a-403e-b08c-2171da2157d3/5e4a23ea-e80a-403e-b08c-2171da2157d3.crl
rsync://rpki.arin.net/repository/arin-rpki-ta/5e4a23ea-e80a-403e-b08c-2171da2157d3/5e4a23ea-e80a-403e-b08c-2171da2157d3.mft
rsync://rpki.arin.net/repository/arin-rpki-ta/5e4a23ea-e80a-403e-b08c-2171da2157d3.cer
rsync://rpki.arin.net/repository/arin-rpki-ta/arin-rpki-ta.crl
rsync://rpki.arin.net/repository/arin-rpki-ta/arin-rpki-ta.mft
rsync://rpki.arin.net/repository/arin-rpki-ta.cer
Signature path expires: Fri 31 May 2024 14:00:00 +0000El camino de firmas (Signature path) anterior (también conocido como Certification path) describe el proceso de validación de firma criptográfica de varios pasos que se siguió para llegar desde este ROA hasta el ancla de confianza (en este caso, ARIN). Cada eslabón de esta cadena tiene su propia fecha de vencimiento, y la más distante es en el futuro lejano (¡en el 2025!). Pero es la más próxima la que determina el vencimiento general del camino de firmas y, por lo tanto, la fecha de vencimiento efectiva del ROA.
Hay tres tipos diferentes de archivos vinculados por la herramienta de consola: listas de revocación de certificados (.crl), manifiestos (.mft) y certificados (.cer).
Glosario Los manifiestos declaran de forma segura el contenido de un repositorio RPKI y hacen referencia a las CRL y los ROA actuales. Un manifiesto determinado es válido hasta el momento de la próxima actualización (nextUpdate). Cuando se encuentran con varias versiones válidas de un manifiesto, los validadores de RPKI deciden qué versión del manifiesto utilizar en función de un número de serie que aumenta monotónicamente dentro de la carga útil del manifiesto. Las CRL (Certificate Revocation Lists o listas de revocación de certificados) contienen la lista de números de serie de los certificados que han sido revocados por la Autoridad de Certificación (CA) emisora antes de su fecha de expiración programada. Para sacar un ROA de la rotación, una CA elimina el nombre de archivo del ROA del manifiesto y agrega el número de serie del certificado de entidad final del ROA a la CRL. Una CRL es válida hasta el momento especificado para la próxima actualización. Los certificados se utilizan para probar la validez de las claves públicas. Los certificados RPKI se definen usando el estándar X.509. Cada certificado contiene su propia ventana de validez, una clave pública, punteros a la ubicación de los repositorios en la red y algunos otros metadatos. Los validadores de RPKI utilizan la clave pública para validar el manifiesto, la CRL y los ROA en la ubicación del repositorio. A su vez, el contenido del certificado está protegido por una firma criptográfica de un emisor más alto en la cadena. En RPKI, el “certificado raíz” se conoce como el ancla de confianza. Se trata de un certificado autofirmado que se puede validar con un localizador de anclas de confianza.
Al seguir los enlaces, podemos construir la siguiente lista de fechas de expiración en ese camino de firmas:
Signature path: Fri 31 May 2024 23:00:00 rsync://rpki.arin.net/repository/arin-rpki-ta/5e4a23ea-e80a-403e-b08c-2171da2157d3/871da40f-793a-4a45-a0a9-978148321a07/e605f279-55f4-48ec-ba13-4845c0973a63/e605f279-55f4-48ec-ba13-4845c0973a63.crl
Fri 31 May 2024 23:00:00 rsync://rpki.arin.net/repository/arin-rpki-ta/5e4a23ea-e80a-403e-b08c-2171da2157d3/871da40f-793a-4a45-a0a9-978148321a07/e605f279-55f4-48ec-ba13-4845c0973a63/e605f279-55f4-48ec-ba13-4845c0973a63.mft
Mon 13 Apr 2026 22:13:58 rsync://rpki.arin.net/repository/arin-rpki-ta/5e4a23ea-e80a-403e-b08c-2171da2157d3/871da40f-793a-4a45-a0a9-978148321a07/e605f279-55f4-48ec-ba13-4845c0973a63.cer
Sat 01 Jun 2024 13:00:00 rsync://rpki.arin.net/repository/arin-rpki-ta/5e4a23ea-e80a-403e-b08c-2171da2157d3/871da40f-793a-4a45-a0a9-978148321a07/871da40f-793a-4a45-a0a9-978148321a07.crl
Sat 01 Jun 2024 13:00:00 rsync://rpki.arin.net/repository/arin-rpki-ta/5e4a23ea-e80a-403e-b08c-2171da2157d3/871da40f-793a-4a45-a0a9-978148321a07/871da40f-793a-4a45-a0a9-978148321a07.mft
Thu 25 Dec 2025 14:09:41 rsync://rpki.arin.net/repository/arin-rpki-ta/5e4a23ea-e80a-403e-b08c-2171da2157d3/871da40f-793a-4a45-a0a9-978148321a07.cer
Wed 31 May 2024 14:00:00 rsync://rpki.arin.net/repository/arin-rpki-ta/5e4a23ea-e80a-403e-b08c-2171da2157d3/5e4a23ea-e80a-403e-b08c-2171da2157d3.crl
Wed 31 May 2024 14:00:00 rsync://rpki.arin.net/repository/arin-rpki-ta/5e4a23ea-e80a-403e-b08c-2171da2157d3/5e4a23ea-e80a-403e-b08c-2171da2157d3.mft
Mon 04 May 2026 15:17:49 rsync://rpki.arin.net/repository/arin-rpki-ta/5e4a23ea-e80a-403e-b08c-2171da2157d3.cer
Mon 30 Sep 2024 15:17:49 rsync://rpki.arin.net/repository/arin-rpki-ta/arin-rpki-ta.crl
Mon 30 Sep 2024 15:17:49 rsync://rpki.arin.net/repository/arin-rpki-ta/arin-rpki-ta.mft
Mon 03 Nov 2025 rsync://rpki.arin.net/repository/arin-rpki-ta.cer
Signature path expires: Fri 31 May 2024 14:00:00 +0000¿Por qué es bueno tener ROA que siempre estén a punto de expirar?
Muchos de los elementos del camino de certificación anterior parecen tener períodos de validez relativamente cortos y expirarán en apenas unas horas o unos días. Estos períodos de validez breves y efectivos tienen un propósito.
Ayudan a evitar una situación donde uno de los eslabones de la cadena criptográfica sufre una interrupción de la distribución, es decir, el servidor rsync o rrdp se desconecta, impidiendo así la recuperación de información nueva. El resultado sería que los ROA quedarían estáticos en su último estado.
Si un ROA mal configurado hubiera contribuido a la interrupción, entonces haría falta una intervención manual para solucionar el problema. En este escenario, la interrupción de la distribución impediría el uso de la CRL para revocar un ROA problemático.
Si los períodos de validez son cortos, el ROA mal configurado acabará por expirar automáticamente, lo que potencialmente despejará la ruta de conexión al punto de publicación del ROA.
La reemisión se produce mucho antes de la expiración
Los emisores de ROA, manifiestos, CRL y certificados no esperan de brazos cruzados a que expire el producto firmado criptográficamente antes de emitir una nueva versión.
A modo de ejemplo de un posible cronograma, algunos emisores podrían volver a firmar su manifiesto y CRL cada hora con un momento de expiración ocho horas después y, al hacerlo, afirmar que los datos son válidos por otras ocho horas. Volver a emitir con frecuencia ayuda a superar problemas transitorios de la red entre el punto de publicación de los ROA y los validadores RPKI desplegados en las redes de los ISP.
Los validadores de RPKI utilizarán versiones de objetos almacenadas localmente en caché hasta el momento en que dejen de ser válidas, o que puedan ser reemplazados por objetos sucesores después de una sincronización exitosa con el punto de publicación.
Este comportamiento es análogo a la configuración del tiempo de vida (TTL) de DNS. Los TTL cortos permiten a los operadores de DNS redistribuir rápidamente el tráfico en el momento necesario, o garantizar que un registro DNS se elimine de los cachés para evitar que un registro desactualizado dirija el tráfico.
Análisis de las fechas de expiración efectivas de los ROA
Podemos usar rpkiviews.org para tomar una instantánea de los aproximadamente 528.000 ROA actualmente en uso. En formato CSV, el contenido de una instantánea se ve de la siguiente manera:
ASN,IP Prefix,Max Length,Trust Anchor,Expires
AS13335,1.0.0.0/24,24,apnic,1712499475
AS38803,1.0.4.0/24,24,apnic,1712532668
AS38803,1.0.4.0/22,22,apnic,1712532668
AS38803,1.0.5.0/24,24,apnic,1712532668
AS38803,1.0.6.0/24,24,apnic,1712532668
AS38803,1.0.7.0/24,24,apnic,1712532668
AS18144,1.0.64.0/18,18,apnic,1712358404
AS13335,1.1.1.0/24,24,apnic,1712499475
AS4134,1.1.4.0/22,22,apnic,1712508843La quinta y última columna contiene las fechas de expiración efectivas en formato epoch. Si agrupamos esas marcas de tiempo en períodos de una hora y graficamos las cantidades en función del tiempo, obtenemos el siguiente gráfico en el cual se ven varios picos.
Como se indica en el gráfico, cada pico de vencimientos de ROA corresponde a un RIR diferente. Esta visualización captura los efectos de las diferencias en las cadenas criptográficas empleadas por cada RIR.
Pero esta fue apenas una instantánea en un momento determinado. Para entender cómo estos vencimientos efectivos cambian con el tiempo, echemos un vistazo a la siguiente animación:
Como ya dijimos, cada pico corresponde a un RIR diferente, y la forma en que evoluciona a lo largo del tiempo depende del software utilizado para gestionar los ROA.
Dado que es difícil analizar un objetivo en movimiento, veamos una representación estática de esos vencimientos efectivos a lo largo del tiempo. En los gráficos siguientes, el eje “x” es el momento en que se toma la instantánea y el eje “y” son los picos de expiraciones efectivas, coloreados por RIR.
El gráfico a continuación muestra cómo las fechas de vencimiento efectivas de los ROA (eje “y”) cambian a lo largo del tiempo (eje “x”). La hora de expiración se ha redondeado a los 15 minutos anteriores. Para facilitar la interpretación, hemos marcado dos puntos en el gráfico (A y B). Ambos representan ROA publicados por RIPE (azul) que vencen a las 23:00 UTC del 13 de abril de 2024 (eje “y”). El punto A representa 2165 ROA con ese vencimiento, mientras que el punto B representa 15.852 ROA y está dibujado en un color más oscuro para reflejar la mayor cantidad de ROA.
| Punto A | Punto B | |
| RIR | RIPE (azul) | RIPE (azul) |
| Instantánea | 2024-04-10 22:56:22 | 2024-04-11 07:12:18 |
| Vencimiento | 2024-04-13 23:00:00 | 2024-04-13 23:00:00 |
| Conteo | 2165 | 15.852 |
Si volvemos a dibujar el gráfico durante varios días, podemos visualizar cómo las fechas de expiración efectivas de los ROA cambian con el tiempo. Cada RIR refleja su propio comportamiento de renovación sobre la base del software diferente que utiliza.
Analicemos algunos por separado.
ARIN
Si aislamos los vencimientos efectivos de los ROA publicados por ARIN, nos encontramos con dos comportamientos diferentes. El primero es una población más pequeña de vencimientos (menos apretada) que se distribuyen entre 8 y 24 horas en el futuro. En este grupo, los vencimientos se corren a 24 horas en el futuro al acercarse a las 8 horas en el futuro.
El segundo consiste en una población más grande de vencimientos que se visualizan en forma de escalera. En este grupo, cuando los vencimientos se acercan a las 24 horas en el futuro, todos se renuevan con vencimientos que oscilan entre 24 y 48 horas en el futuro. Las renovaciones continúan a medida que los vencimientos se acercan a las 24 horas en el futuro, pero nunca exceden el límite de tiempo superior anterior: así es que se crea la escalera. El límite de tiempo superior para el vencimiento se restablece cada 48 horas.
RIPE
A diferencia de lo que ocurre en ARIN, los vencimientos efectivos de RIPE se actualizan a un tiempo entre 8 y 18 horas en el futuro a medida que se acercan a las 8 horas posteriores a la hora actual. Los vencimientos de RIPE nunca son más de 24 horas en el futuro. Esto crea una distribución más apretada, como se puede ver en el gráfico siguiente.
APNIC
Las fechas de expiración efectivas de los ROA de APNIC se dividen en dos categorías. Una pequeña cantidad de vencimientos (banda inferior menos apretada) se distribuyen entre 8 y 24 horas en el futuro. Al igual que la banda inferior de ARIN, estos vencimientos se corren a 24 horas en el futuro cuando se acercan a 8 horas en el futuro.
Por lo demás, la mayoría de los ROA publicados por APNIC tienen los vencimientos efectivos más lejanos de cualquier RIR: están al menos cinco días en el futuro. A medida que los vencimientos llegan a los cinco días, se actualizan las fechas para que los vencimientos sean seis días en el futuro.
LACNIC
En la primera quincena de abril, los vencimientos efectivos de los ROA de LACNIC mostraron un comportamiento similar al de RIPE. Sin embargo, el 15 de abril LACNIC cambió para usar Krill como software de gestión de RPKI. Después del 15 de abril, los vencimientos comenzaron a parecerse a la forma escalonada de 48 horas de ARIN.
AFRINIC
A medida que los vencimientos efectivos de AFRINIC se acercan a 24 horas a partir de la hora actual, estos vencimientos se renuevan por 24 horas más en el futuro. Para la mayoría de los ROA, esta actualización se produce todos los días a la medianoche UTC.
Conclusiones
Como probablemente ya saben, la valiación de origen con RPKI sigue siendo la mejor defensa contra los secuestros de BGP y las fugas accidentales de rutas que han provocado numerosas interrupciones de servicio. Esta tecnología celebró un hito importante el 1.o de mayo de 2024, fecha en que el porcentaje de rutas IPv4 en la tabla de enrutamiento global con ROA superó el 50% (IPv6 lo logró el año pasado).
La validación de origen de rutas depende de una cadena criptográfica para transmitir con precisión la información contenida en los ROA a los validadores que evalúan los anuncios de BGP a medida que llegan. Como resultado, hay dos vencimientos que los ROA deben tener en cuenta. El primero es el vencimiento especificado en el propio ROA, pero también está el vencimiento visto desde la perspectiva del validador —lo que llamamos vencimiento efectivo— que corresponde al vencimiento más corto a lo largo de la cadena. Ambos tipos de vencimiento se pueden monitorear con herramientas de código abierto como BGPAlerter.
Estos vencimientos breves y efectivos (a veces dentro de unas pocas horas) son una característica que evita que los validadores se queden contaminados con información desactualizada en caso de una interrupción. Lo fascinante es la diferencia entre cómo cada RIR maneja estos vencimientos, que van desde apenas unas horas (RIPE) hasta varios días (APNIC).
Las opiniones expresadas por los autores de este blog son propias y no necesariamente reflejan las opiniones de LACNIC.