Resumen

  • RFC 9589 exige signing-time en los objetos firmados de RPKI y excluye binary-signing-time.
  • El valor permite que la copia obtenida por RRDP y el archivo publicado por rsync utilicen el mismo mod-time, reduciendo retransmisiones cuando RRDP falla.
  • El valor firmado no acredita la hora real de firma, la publicación actual, la validez del objeto ni el resultado de BGP.

El puente entre una delta y un directorio

RRDP y rsync llevan material de repositorio; no dictan por sí mismos qué material es válido. RRDP puede fallar por XML incorrecto, TLS vencido o una conexión agotada. En ese momento el relying party puede acudir a rsync, aunque ya conserve los objetos DER que recibió por RRDP.

rsync trabaja sobre ficheros. En su comprobación rápida, tamaño y hora de modificación iguales bastan para omitir una transferencia. Si el relying party escribió su copia RRDP con la hora local de la descarga y el servidor rsync la escribió con otra hora, el primer cambio de vía puede volver a mover objetos idénticos y aumentar carga justo durante una avería.

RFC 9589 define una solución limitada. El emisor incluye signing-time en el objeto CMS. El operador del repositorio debería fijar el mod-time del fichero rsync a ese valor; el relying party debería fijar al mismo valor el fichero que materializa desde RRDP. La próxima comparación tiene un terreno común. Puede evitar tráfico, E/S y CPU que no añaden información.

Nada de eso otorga al atributo un poder mayor. Es una clave de coordinación para una comparación de entrega. No es una orden de aceptar el objeto ni una afirmación de que el repositorio está actualizado.

Una firma protege el valor, no el reloj

Que el atributo esté dentro de datos firmados significa que no puede cambiarse en tránsito sin romper la firma. No significa que el reloj del emisor estuviera bien, que la clave se usó en ese instante o que el fichero se publicó entonces. RFC 9589 no impone requisitos sobre la corrección de signing-time y declara que no ofrece información fiable sobre el momento de producción de la firma.

La frontera evita dos errores distintos. El primero es llamar a la etiqueta una prueba de frescura. El segundo es usar el atajo de rsync como prueba de igualdad criptográfica. Tamaño y mod-time son criterios de una decisión de transferencia; la validación CMS y RPKI sigue siendo la que examina firma, certificado y reglas del tipo de objeto.

Una marca temporal incorrecta pero usada de modo consistente en ambas serializaciones aún puede cumplir la tarea de ahorrar una retransmisión. Para demostrar una cronología operativa hacen falta registros controlados, observaciones de publicación y objetos retenidos. Para demostrar validez hacen falta los controles propios de RPKI.

Las pruebas que no desaparecen

El objeto debe superar el perfil común de RFC 6488 y su validación específica. El certificado EE debe encadenar correctamente y no estar revocado. El manifiesto vigente de RFC 9286 aporta el inventario firmado. RFC 9829 precisa que la CRL pertinente debe ser a la vez el destino indicado por el certificado y el objeto incluido, con hash coincidente, en el manifiesto actual de la CA.

Una ROA válida mantiene un alcance estrecho: autoriza a un AS a originar ciertos prefijos dentro de sus límites. No prueba que el anuncio esté visible, que otros AS lo seleccionen, que un router lo instale ni que un paquete llegue. Ni la caída de RRDP ni una transferencia omitida por rsync alteran ese alcance.

La cadena verificable es: bytes y URI, resultado de la transferencia, certificado, revocación, manifiesto, validación del objeto, huella de datos validados y posterior entrada de política. Un HTTP exitoso o un rsync económico prueban entrega o ahorro, no autoridad sobre cada eslabón.

Ensayar el fallo que se usará

La prueba útil no es una demostración de laboratorio con un único validador. Incluye adquisición RRDP normal y cambio a rsync con bytes iguales; XML inválido; TLS vencido; timeout; fichero ausente; tamaño o mod-time distinto; certificado revocado; objeto fuera del manifiesto vigente. Para cada versión se conservan URI, ruta, hash, signing-time, ambos mod-time, tamaño, decisión de transferencia, resultados de certificado/CRL/manifiesto y huella de salida.

Las diferencias entre validadores son evidencia. Menos bytes y un conjunto validado diferente no es éxito automático. Más bytes con el mismo conjunto puede ser ineficiencia, no una rotura de confianza. La afirmación de un proveedor no reemplaza la prueba del recorrido que realmente alimenta la política de la red.

Fuentes