Resumen

  • El cambio de Rapport del 4 de septiembre de 2026 separó la falla de un manifiesto en dos casos, según cambie o no la instancia de la autoridad certificadora.
  • En el caso de la misma instancia, la prueba exige seis VRP, incluidas dos que deben continuar desde la caché después de retirar ca2.mft.
  • El propio script dice que el validador debe advertir la ausencia, pero la única comprobación del mensaje está comentada y no se ejecuta.
  • RFC 9286 exige el aviso y recomienda notificar a una persona, además de recomendar el uso temporal de objetos en caché. Son dos resultados que deben probarse por separado.

Hay una diferencia decisiva entre mantener una tabla de rutas utilizable y demostrar que alguien sabe por qué sigue siendo utilizable. El nuevo escenario de Rapport, el probador de relying parties de LACNIC, deja esa diferencia a la vista en dos líneas consecutivas.

La primera es un comentario: el validador debe avisar que falta el manifiesto de ca2. La segunda debería buscar ese aviso en el registro de FORT. Sin embargo, comienza con #. Para el intérprete de comandos, no es una aserción pendiente ni una comprobación tolerada; es texto que no se ejecuta.

Después viene una prueba real. Rapport exige seis VRP. Dos proceden de una primera autoridad certificadora, dos pertenecen a la autoridad cuyo manifiesto acaba de desaparecer y dos aparecen con una tercera autoridad añadida en el segundo ciclo. Las dos del caso afectado solo pueden permanecer porque existía una caché validada en el ciclo anterior.

La prueba, por tanto, confirma una propiedad valiosa: una falla de recuperación no borra de inmediato datos RPKI previamente aceptados. No confirma la otra propiedad que su comentario anuncia: que el estado degradado sea visible para la persona responsable.

No hay base para convertir esa omisión de cobertura en una acusación contra un validador. Los archivos revisados no demuestran que FORT haya dejado de emitir el aviso. Mucho menos permiten decirlo de Routinator, rpki-client o rpki-prover. Tampoco prueban que LACNIC use Rapport para certificar productos o operar su infraestructura. La afirmación exacta es más limitada: al commit público c682fd2, el script comprueba las VRP retenidas y no ejecuta la comprobación del aviso.

La caché es una decisión de seguridad

Un manifiesto RPKI no es un índice decorativo. Es un objeto firmado que enumera certificados, la lista de revocación y otros objetos firmados vinculados con el punto de publicación de una autoridad. Permite detectar material eliminado, sustituido o reproducido desde un estado anterior, situaciones que una firma válida por sí sola no siempre revela.

Si una consulta del repositorio falla, existen dos peligros. El relying party puede retirar de golpe autorizaciones que seguían siendo válidas, o puede conservar durante demasiado tiempo datos que ya no corresponden al estado actual. RFC 9286 adopta una respuesta temporal: detener el procesamiento de la instancia afectada, emitir un aviso con la razón y continuar usando los objetos de una recuperación anterior que estén en caché hasta que caduquen o un intento exitoso los reemplace.

La continuidad evita que un problema de transporte o repositorio se convierta automáticamente en una alteración del conjunto de VRP entregado a los routers. El artículo 6.6 no promete que el pasado sea verdadero para siempre. Compra tiempo bajo una condición de frescura y exige que la degradación tenga nombre.

Por eso el aviso no es un añadido cosmético. El router recibe un conjunto de datos; el operador necesita conocer su procedencia temporal. Las mismas seis VRP pueden significar “la publicación actual fue obtenida y validada” o “una recuperación falló y seguimos sirviendo el último estado válido”. El conteo no distingue esas historias.

Una supervisión que solo mira disponibilidad o cantidad de rutas puede permanecer en verde. La deuda de evidencia crece en silencio: último éxito más lejano, más reintentos fallidos, menor margen antes de que la caché se vuelva obsoleta. El aviso asigna ese estado a una instancia de AC, una causa y una acción siguiente.

Dos pruebas porque hay dos identidades

Rapport mejoró su suite el 4 de septiembre al dividir el caso original. La diferencia entre los dos nuevos escenarios no es el nombre del archivo, sino la identidad criptográfica y de publicación a la que pertenece la caché.

En el escenario de SIA roto, el certificado de la AC cambia y su URI de manifiesto apunta a un lugar que no lo contiene. Las notas de Rapport describen esa combinación como una instancia nueva, sin una caché anterior que pueda heredarse. El script activo busca un diagnóstico de FORT y espera que desaparezcan las VRP de la instancia afectada, mientras conserva las de las autoridades hermanas.

En el escenario de fallback, el certificado no cambia. Tampoco cambian el SIA ni el punto de publicación. Tras un primer ciclo bueno, Rapport elimina el manifiesto de la misma AC. En ese caso, las VRP previas sí permanecen. El script verifica el resultado de datos, pero deja inerte el control del aviso.

RFC 9286 explica por qué esa separación importa. Un mismo punto de publicación puede albergar más de una instancia de AC, por ejemplo durante una renovación de claves. Cada manifiesto describe solo los productos de su instancia. El procesamiento se realiza por separado y se guía por la URI del manifiesto en la extensión SIA del certificado.

No basta, entonces, con saber que un directorio se parece al de ayer. El fallback debe probar que los objetos retenidos pertenecen a la misma instancia, al último ciclo exitoso de esa instancia y a un periodo todavía admisible. El aviso debe transportar la misma identidad; de lo contrario, un mensaje genérico no permite relacionar la degradación con el conjunto que sigue alimentando al router.

Probar el significado, no una oración

Descomentar la línea actual sería un avance puntual. También expondría una debilidad de diseño: esa aserción busca una frase exacta de FORT. Rapport admite varios relying parties y reconoce que sus pruebas se construyeron inicialmente alrededor de FORT. La observabilidad no será portátil si todos deben escribir el mismo texto.

Los productos pueden comunicar el hecho mediante registros, JSON, métricas o estados de servicio. Incluso dentro de un producto, la redacción puede cambiar sin que cambie la conducta. Un test literal puede fallar por una coma; también puede pasar con una frase que no incluya la instancia, la edad de la caché ni la decisión de fallback.

La aserción común debe ser semántica. La prueba necesita saber que ocurrió una falla de adquisición de manifiesto, cuál fue su clase, qué instancia quedó afectada, que se eligió la caché, cuál es su frontera de frescura, cuándo se emitió el evento, qué reintento sigue y qué pasó con la notificación humana. Cada adaptador de Rapport puede demostrar esos campos en la interfaz real de su producto.

Así se evita imponer el vocabulario de FORT y, al mismo tiempo, se impide que “hubo algún warning” sustituya una evidencia útil. Un evento sin identidad ni decisión de caché apenas traslada el problema al operador.

Un recibo con dos estados

El resultado debería conservar dos columnas independientes.

La columna de continuidad enlaza el commit de Rapport, la versión del relying party, la huella del binario, el certificado y el SIA de la AC, la última recuperación buena, el conjunto de objetos en caché, el límite de frescura, el motivo de la falla, las VRP retenidas, el aislamiento de las AC hermanas y el próximo intento.

La columna de visibilidad registra un identificador semántico del evento, la razón, la referencia a la instancia, la decisión de fallback, la edad de la caché, la severidad, la hora, el adaptador y el camino de evidencia. Si se esperaba avisar a una persona, debe indicar entrega, limitación de frecuencia o supresión deliberada.

Una no puede aprobar a la otra. Es posible conservar las VRP correctas y no emitir un aviso comprobable. También es posible emitir un aviso y mantener el conjunto equivocado. Si una implementación no ofrece un dato observable, el recibo debe decir “no probado” o “no soportado”. Esa limitación es información, no un fracaso que deba ocultarse.

Continuidad sin ruido ni falsa normalidad

El objetivo no es inundar un centro de operaciones. Un aviso nuevo por cada reintento sería contraproducente. La unidad correcta es el episodio: abrirlo cuando falla el manifiesto de una instancia, actualizar duración y edad de caché mientras persiste, escalar antes de la caducidad y cerrarlo cuando una recuperación exitosa sustituye los objetos.

Ese ciclo convierte una línea de log en un estado gestionable. Permite distinguir una interrupción breve, una degradación prolongada y una recuperación. Además evita que la disponibilidad de VRP sea leída como frescura absoluta.

Rapport se presenta como software en desarrollo temprano. Su repositorio no tenía releases ni tags en la captura, y las modificaciones recientes muestran que el comportamiento esperado sigue afinándose. Esa franqueza es saludable. Obliga a evitar dos excesos: despreciar el test por no estar terminado o elevar un resultado parcial a certificación.

No sabemos por qué la línea está comentada. Podría ser una cadena inestable, una limitación del adaptador, una tarea pendiente o una decisión temporal. Tampoco sabemos si existe una comprobación fuera del repositorio público. La respuesta responsable no inventa la causa. Registra la cobertura actual y propone un criterio que sobrevivirá al texto concreto del log.

La suite ya conserva las rutas que debe conservar. La misma suite ya declara que debe haber un aviso. La aceptación completa empieza cuando ambas afirmaciones producen evidencia separada y terminan en un solo recibo.

Fuentes