Resumen

  • El número de manifiesto RPKI ordena localmente los inventarios firmados de una CA. No es un reloj mundial ni una descripción de las rutas que circulan. Su codificación tiene un máximo, y un fallo de emisión puede impedir que cualquier sucesor sea mayor que el valor ya aceptado.
  • RFC 9981 reconoce un nombre de archivo distinto como inicio de otra época de comparación. El relying party debe avisar al operador y el emisor no debe convertir ese recurso en una rotación rutinaria.
  • Solo cambia la referencia numérica recordada. Siguen vigentes la cadena criptográfica, un thisUpdate posterior, la lista de archivos y hashes, y la coincidencia exacta del URI firmado con la ubicación RRDP o rsync.

La declaración más nueva que no podía ser mayor

Una autoridad de certificación va a emitir el manifiesto 7.914, pero su software escribe 2^159 - 1, el máximo representable. La firma procede de la clave adecuada, las fechas son correctas y la lista refleja fielmente el punto de publicación. Varios relying parties lo aceptan y guardan el número.

El operador repara el contador y produce otro manifiesto. Este aparece después en el tiempo real, está bien firmado y contiene el inventario correcto. Sin embargo, ninguna cifra legal puede superar el máximo que los validadores recuerdan. El sucesor es nuevo y, al mismo tiempo, imposible dentro de la historia anterior.

La contradicción enfrenta dos evidencias. La firma atribuye el nuevo mensaje al emisor. La secuencia dice que no puede seguir al mensaje aceptado. Si el validador olvida la secuencia, reduce la defensa contra repeticiones. Si la aplica para siempre, congela el punto de publicación.

RFC 9981 fija la ruptura observable más pequeña: otro nombre de archivo. No autoriza a borrar estados incómodos. Declara una frontera de comparación y mantiene intactas las demás condiciones de confianza.

El alcance exacto de un manifiesto

Un manifiesto RPKI es el inventario firmado de los archivos que una CA pretende servir en un punto de publicación. Relaciona cada nombre con un hash y permite descubrir ausencias, sustituciones o una vista incompleta del repositorio.

Es también un objeto firmado RPKI, con un certificado EE de un solo uso. Incluye manifestNumber, thisUpdate, nextUpdate, el algoritmo de hash y los pares de nombre y huella. El certificado de la CA lo localiza mediante la SIA id-ad-rpkiManifest.

La afirmación termina ahí. Que un ROA figure en la lista no demuestra que la ruta exista en BGP. Que aparezca una CRL no prueba que todos la hayan descargado. Que un validador genere un VRP no acredita que un router lo esté usando. El manifiesto habla de publicación; la validación y el reenvío pertenecen a capas posteriores.

Esta precisión evita respuestas exageradas. No se ha roto toda la confianza RPKI. Se ha vuelto impracticable la secuencia de una CA bajo un nombre concreto. La intervención puede permanecer localizada.

Un campo enorme también puede quedar envenenado

RFC 9286 ordena incrementar en uno el número de cada nuevo manifiesto. El relying party espera que el valor observado supere al previamente aceptado. Un salto señala estados omitidos; una regresión puede delatar un objeto antiguo o repetido.

El número no se compara entre CA y tampoco sustituye al tiempo. Incluso dentro de una misma autoridad permanecen thisUpdate, nextUpdate, la vigencia y revocación de certificados y la validación general del objeto firmado.

RFC 9981 identifica el límite de 20 octetos para un INTEGER positivo: 2^159 - 1. A una emisión por segundo, agotarlo de forma normal llevaría unos 23.171.956.451.847.141.650.870 quintillones de años. No es una previsión de capacidad.

El riesgo real es un defecto: una suma desmedida, un bucle sin espera, la restauración de un estado corrupto o la asignación accidental del máximo. Un solo error puede recorrer la distancia astronómica.

Después, los validadores no tienen por qué reaccionar igual. Uno puede olvidar el estado al caducar; otro puede rechazar valores inferiores indefinidamente. El mismo repositorio queda actualizado para unos y detenido para otros. La memoria de cada relying party pasa a formar parte de la avería.

El nombre como frontera explícita

Cuando el nombre del manifiesto difiere del asociado anteriormente a la CA, RFC 9981 impide rechazarlo únicamente porque el número no sea mayor. Si supera los demás controles, el relying party guarda el nuevo valor bajo el nuevo nombre y comienza otra época.

Ese nombre no es una etiqueta libre. Es el último segmento del URI de la SIA id-ad-rpkiManifest en el certificado de la CA. La autoridad debe nombrar la nueva ubicación, publicar allí el objeto y mantener la correspondencia con el URI signed-object del certificado EE.

La transición deja tres hechos auditables: el certificado designa otro camino, el repositorio sirve el objeto en él y el validador cambia su clave de comparación. No hace falta una orden central para reiniciar todo RPKI ni una heurística que adivine que un número pequeño debe ser reciente.

El relying party debe emitir una alerta. Un cambio puede ser recuperación legítima, transición planificada, error operativo o indicio de compromiso. La firma responde quién emitió; no explica por qué abandonó la historia anterior.

La CA no debería rotar nombres con normalidad. Si cada reinicio o actualización abre una nueva época, la secuencia deja de denunciar retrocesos y aumenta la posibilidad de presentar un historial antiguo como un comienzo nuevo.

Las comprobaciones que cruzan la frontera

La regla no significa «nombre nuevo, aceptación automática». Solo determina contra qué manifestNumber guardado debe compararse.

El manifiesto todavía necesita una firma válida, un certificado EE válido y una cadena hasta la CA. Continúan la vigencia, la revocación, el perfil RPKI, la estructura, el algoritmo de hash, el inventario y el tratamiento de archivos ausentes o incompatibles.

La frescura no se reinicia. El thisUpdate del nuevo manifiesto debe ser posterior al del último aceptado. Un atacante no puede mover un inventario viejo firmado a otra ruta para saltarse el tiempo. nextUpdate sigue acotando la ventana declarada.

La ubicación tampoco se reinicia. El URI signed-object del certificado EE debe corresponder exactamente al publish URI de RRDP o a la ruta rsync por la que se obtuvo el objeto. Copiar los bytes a otro nombre sin alinear las referencias firmadas no crea la época descrita por la RFC.

El manifiesto tampoco modifica lo que inventaría. Puede permitir validar una nueva lista, pero no cambia los recursos de un certificado, los prefijos de un ROA, una revocación o la entrada que recibe el router.

La ambigüedad de varias SIA

Un certificado de CA puede contener varias descripciones SIA de manifiesto. Los relying parties pueden elegir ubicaciones distintas. Si el certificado nuevo elimina un nombre antiguo pero conserva otro, una parte observa el cambio de época y otra cree que la época anterior sigue vigente.

Ambas pueden ejecutar correctamente sus reglas sobre el URI escogido y discrepar. Quien sigue el nuevo nombre acepta el número bajo; quien conserva el antiguo lo compara con el máximo y lo rechaza. El incidente puede confundirse con caché, retraso RRDP o un fallo de producto.

Por eso RFC 9981 exige que no sobreviva ningún nombre anterior cuando la recuperación depende del cambio. Hay que inventariar todas las SIA, caminos y preferencias de validadores. Cambiar solo la ubicación llamada «principal» es insuficiente.

RRDP y rsync son transportes, no verdades alternativas. Snapshot, delta y vista rsync deben converger en objetos cuyos bytes y URI firmados coincidan. Un HTTP exitoso prueba entrega, no autorización criptográfica de la ubicación.

La dificultad especial del ancla de confianza

Una CA subordinada suele poder ejecutar una renovación de clave bajo su padre y construir otra identidad de CA con nueva historia de manifiestos. Sigue necesitando solapamiento y continuidad, pero existe una autoridad superior que vincula la transición.

Un ancla de confianza no tiene padre. Su clave y las ubicaciones del certificado llegan al relying party normalmente mediante un TAL. Cambiar la clave o distribuir otro TAL expone ritmos de actualización diferentes, instalaciones antiguas y el riesgo de que validadores con material viejo pierdan todo el árbol.

RFC 9691 mejora las transiciones planificadas con objetos TAK. El ancla actual puede anunciar una clave sucesora y sus ubicaciones; los validadores comprueban las referencias recíprocas y esperan un plazo de aceptación antes de cambiar.

TAK no es, sin embargo, una puerta lateral para saltar un punto de publicación averiado. El relying party parte de la clave ya confiada, recupera el certificado, valida manifiesto y CRL, y después procesa TAK. La continuidad debe prepararse antes de la urgencia y no confundirse con el cambio de nombre de RFC 9981.

Recuperarse significa converger

La recuperación no termina cuando la CA firma otro archivo. Termina cuando implementaciones independientes obtienen el objeto exacto, reconocen la nueva época, validan el inventario y producen resultados esperados y compatibles.

Las pruebas deben usar material capturado o sintético, nunca acercar un contador de producción al máximo. Deben cubrir secuencia normal, salto, máximo, número bajo con el mismo nombre, número bajo con otro nombre, thisUpdate antiguo, URI firmado incompatible y certificado que conserva una antigua SIA.

Por producto y versión se registran URI, nombres, número guardado, comparación temporal, alerta, resultado, objetos admitidos y delta de VRP. Las diferencias son evidencia de soporte y estado; conviene encontrarlas antes de depender de la salida en una emergencia.

En producción se preservan certificado y manifiesto anteriores, todas las URI, números, tiempos y huellas de salida. Se documentan motivo, aprobadores, nuevas SIA y efectos previstos. RRDP snapshot, delta, rsync, validadores y alimentación de routers se comparan antes de retirar material viejo.

Si el nuevo objeto falla en firma, tiempo, URI o inventario, otro cambio de nombre no es una reversión. Se detiene la emisión, se conservan las pruebas y se regresa, cuando las reglas lo permiten, al último estado demostrado. Encadenar reinicios convierte una excepción controlada en historia incomprensible.

Fuentes