Resumen

  • Tras un fallo de RRDP, un validador puede conservar una caché previa, descargar una instantánea mucho mayor o recurrir a rsync; no existe un temporizador universal que imponga la misma salida.
  • La retención de deltas, la vigencia de los manifests y los umbrales del validador reparten el coste de recuperación entre servicios de publicación, operadores de red y titulares de recursos.
  • Hace falta un recibo de recuperación por repositorio y una comparación independiente de los resultados validados, no sólo un monitor HTTP en verde.

A las nueve, un validador solicita el siguiente delta pequeño de un repositorio RPKI. La notificación lo referencia, pero el archivo no está disponible. Un equipo sigue usando la caché de la última descarga correcta. Otro pide la instantánea completa. Un tercero espera un intervalo aleatorio y prueba rsync. Las tres decisiones pueden responder a políticas razonables; no garantizan la misma versión del presente en el mismo minuto.

Por eso la recuperación del repositorio se está convirtiendo en un punto de control del enrutamiento. RPKI suele explicarse a partir del objeto firmado: el titular de recursos autoriza un origen, una parte dependiente lo valida y el router aplica una política de validación de origen. La cadena real empieza antes.

La intención firmada debe salir de la autoridad certificadora, publicarse, atravesar el transporte del repositorio, superar las comprobaciones de manifest, certificado y revocación, y convertirse en una carga útil validada. La firma puede seguir intacta mientras un incidente de distribución cambia la evidencia que ve el siguiente eslabón.

Del delta a la instantánea y de ahí al respaldo

El RFC 8182 define tres piezas de RRDP. La notificación identifica sesión y número de serie; los deltas llevan cambios incrementales; la instantánea contiene una vista completa y actual. Si hay una cadena continua desde el número local hasta el último, el validador sigue el camino ligero. Si falta un delta o es rechazado, usa la instantánea.

Los costes no son simétricos. Un delta puede ser pequeño; una instantánea puede medir decenas o cientos de megabytes. La versión de mayo de 2026 del borrador SIDROPS sobre servicios de publicación describe una cascada: al fallar uno o varios deltas, la parte dependiente suele intentar la instantánea, que es mayor; si también falla, puede pasar a rsync; en la siguiente ejecución RRDP suele empezar de nuevo por la instantánea. Un servicio congestionado puede recibir más demanda precisamente por su mecanismo de recuperación. La carga de emergencia pesa más cuando la plataforma soporta menos peso.

El documento es un Internet-Draft de grupo de trabajo, no un RFC. Sus cifras sí tienen un alcance definido. En un repositorio grande observado en enero de 2024, una notificación con 144 deltas que cubrían 14 horas supuso 251 GB de 55,5 TB de tráfico total, menos del 0,5 %. Conservar más deltas permite que un validador atrasado se recupere de forma incremental, pero alarga la notificación que todos descargan.

Conservar menos abarata el régimen normal y empuja a más clientes hacia instantáneas. El borrador aconseja un mínimo de cuatro horas porque en 2024 se observaron instancias que sólo sincronizaban cada una o dos horas. El parámetro no elimina el coste: decide cuándo se paga y quién lo recibe.

El validador añade otra política. La documentación actual de Routinator ofrece never, stale y new para el respaldo rsync tras un fallo RRDP. El valor predeterminado documentado es stale: emplea la copia RRDP local mientras se considere actual y, después, prueba rsync en un momento elegido aleatoriamente para cada repositorio. El máximo predeterminado es de 3.600 segundos. La dispersión evita que todos los validadores llamen a la puerta secundaria a la vez.

Routinator también publica umbrales capaces de alterar la ruta: usar una instantánea si hacen falta más de 100 deltas; tratar como vacía una lista de más de 500; permitir 600 segundos para obtener un recurso RRDP, 10 segundos para una lectura y 300 para un comando rsync. Son valores de un producto, no constantes de RPKI. Al cambiarlos, el mismo fallo produce otra secuencia de solicitudes y decisiones de caché.

La caché forma parte de la evidencia

El RFC 9286 indica que, si falla una descarga, la parte dependiente debería usar los datos de una descarga anterior correcta hasta que otra tenga éxito. Así evita convertir una vista incompleta en una interpretación falsa de la intención de enrutamiento. También implica que la disponibilidad instantánea de un endpoint no revela la edad de la evidencia que acabará ante el router.

Los manifests limitan esa continuidad. Enumeran los objetos que el emisor pretende publicar y permiten detectar desapariciones, sustituciones o supresión de versiones nuevas. Detectan una diferencia, pero no reparan el archivo ausente. thisUpdate, nextUpdate, las CRL y la vigencia de los objetos forman una ventana finita para reutilizar la caché.

El borrador de 2026 expone la compensación: una vigencia más larga da más tiempo para restaurar el servicio, pero amplía la oportunidad de replay; una vigencia corta reduce esa exposición y aumenta las reemisiones. En un repositorio grande, pasar de reemitir cada 24 horas a hacerlo cada 48 redujo cerca de un 50 % el uso de datos, porque la mayoría de cambios eran reemisiones de manifests y CRL, no ROA o ASPA nuevas. No es un coeficiente mundial. Sí muestra el reparto de poder: la CA elige el ritmo, mientras el repositorio y todas las partes dependientes procesan la carga.

Las normas siguen cerrando bordes de recuperación. El RFC 9981, publicado en mayo de 2026, trata el caso excepcional en que el número de manifest llega al máximo. Registra que antes algunas implementaciones aceptarían un reemplazo sólo después de caducar el vigente y otras rechazarían los siguientes indefinidamente. El conteo normal casi nunca llegaría al límite; el riesgo real es un error o una mala configuración. El valor del ejemplo no es su frecuencia, sino que demuestra cómo un borde mal especificado permite resultados operativos distintos.

Capacidad y seguridad no mejoran en la misma dirección

Pasar a rsync puede mejorar la accesibilidad y debilitar el límite de transporte. RRDP usa HTTPS y distribuye deltas e instantáneas inmutables que se pueden almacenar en caché. Rsync exige más trabajo por conexión y no aporta confidencialidad e integridad de canal propias. El modelo de amenazas de Routinator contempla que un adversario en ruta degrade RRDP y provoque el descenso a rsync. Las firmas y los manifests asumen entonces una parte mayor de la defensa.

NLnet Labs ilustró la cuestión de capacidad en 2020 con un modelo prospectivo: 150.000 validadores consultando cada diez minutos producirían unas 250 solicitudes por segundo, frente a un servicio rsync de respaldo acostumbrado entonces a unas tres. No son datos de tráfico de 2026. Explican por qué un respaldo inmediato y simultáneo era una mala idea y por qué el plazo actual se aleatoriza.

Puede medirse la sensibilidad sin inventar el tamaño de Internet. Supongamos 10.000 validadores, un delta ordinario de 1 MB y una instantánea comprimida de 100 MB. Si todos siguen la vía incremental, una ronda transfiere 10 GB. Si sólo el 20 % pasa a instantáneas, sube a unos 208 GB: 8.000 MB de deltas más 200.000 MB de instantáneas. Los reintentos y el trabajo de rsync van aparte. El pico no depende sólo del número de clientes, sino del estrecho intervalo en que se recuperan.

Un repositorio puede estar «arriba» y ofrecer una recuperación rota. Un balanceador puede mostrar la notificación de un backend antes de que el delta o la instantánea referenciados lleguen a los demás. Una conexión persistente vieja puede cruzar un failover y devolver una sesión anterior. El borrador SIDROPS exige vistas coherentes entre nodos y señala que el RFC 8182 no define una respuesta universal a la regresión del número de serie; algunas implementaciones piden una instantánea para resincronizar. El monitor ve un 200. El validador ve una línea temporal quebrada.

Las fuentes no ofrecen una tasa global de divergencia ni prueban que un repositorio concreto haya causado una caída de rutas. Confirman el mecanismo, los parámetros y la transferencia de costes. Es suficiente para diseñar una prueba reproducible.