Resumen

  • Sesión, ubicación, serial y hash forman una coordenada de sincronización RRDP. Ninguno de esos datos, por separado, demuestra que todos los relying parties recibieron el mismo historial ni que los objetos RPKI resultantes sean válidos.
  • Ante un hash distinto para un delta ya visto, RFC 9697 exige tratar la continuidad incremental como no fiable: registrar el conflicto, cargar el snapshot actual y ejecutar de nuevo las validaciones. Solo después pueden compararse payloads y decidirse, mediante política local, los efectos sobre BGP.

La escena empieza en una sala de control. Dos validadores alimentan routers en centros de datos diferentes. La pantalla de flota muestra el mismo session_id, el mismo serial más reciente y la misma etiqueta verde. El turno de operaciones concluye que ambos nodos están alineados.

Entonces aparece una diferencia en un prefijo. No es un incidente real, sino un ejercicio deliberado. Un validador recuerda que el delta 1774 tenía el hash A. El otro recibió más tarde una notificación en la que esa misma sesión y ese mismo serial apuntaban al hash B. Cada descarga coincidió con la notificación visible en su momento. Los procesos no fallaron al comparar el archivo con su hash local; falló la premisa de que una coordenada histórica designaba bytes inmutables.

La consola comparaba el último peldaño. No comparaba la escalera.

RFC 9697 formaliza precisamente esa comprobación. El relying party conserva las parejas serial-hash de una notificación procesada con éxito. Cuando la siguiente notificación contiene seriales que se solapan con la anterior, compara sus hashes. Si uno cambia, emite una advertencia y deja de prolongar la cadena de deltas: procesa el snapshot más reciente.

Un serial no es un certificado de consenso

RFC 8182 define RRDP como un mecanismo para obtener el estado público del repositorio RPKI mediante HTTPS. La notificación anuncia una sesión, el serial actual, un snapshot y una secuencia retenida de deltas. Un cliente que ya dispone de estado compatible puede aplicar incrementos contiguos; un cliente nuevo o incapaz de continuar usa el snapshot.

El serial ordena cambios dentro de una sesión concreta. No es un reloj mundial y no declara que todos los validadores hayan observado los mismos bytes. El identificador de sesión tampoco es una identidad universal del repositorio: la especificación obliga a interpretarlo junto con la ubicación de la notificación. Un UUID reutilizado por otro servidor no puede fusionar dos historias.

La coordenada útil incluye origen y URL de notificación, sesión, serial, hash del snapshot, pares serial-hash de los deltas anunciados y el resultado local de su aplicación. Un panel que reduce todo eso a «serial actual» descarta la prueba que permitiría distinguir retraso normal de mutación histórica.

RFC 6811 reconoce que la visión RPKI global es débilmente consistente: los relying parties consultan y actualizan en momentos diferentes. Dos nodos pueden encontrarse legítimamente en puntos distintos de una secuencia. Eso no equivale a que un mismo punto de la secuencia contenga dos contenidos. La demora es una diferencia de tiempo; la mutación es una contradicción de evidencia.

La caché barata depende de una promesa cara

RRDP escala porque snapshots y deltas pueden distribuirse mediante servidores HTTP y CDN. La arquitectura supone que el contenido y la URL de un artefacto publicado no cambian. Así un edge puede retenerlo y muchos validadores pueden reutilizar exactamente los mismos bytes.

La inmutabilidad no es una preferencia estética. Es el contrato económico que hace segura la caché. Si un archivo cambia bajo una coordenada ya publicada, un cache hit deja de ser evidencia de reproducción. Un edge puede conservar la primera versión y otro la segunda. Los validadores convergen en el serial visible mientras arrastran repositorios locales distintos.

RFC 9697 no pide almacenar eternamente todo el repositorio. Pide memoria suficiente para comparar el solapamiento entre la notificación exitosa anterior y la nueva. Esa pequeña custodia convierte una promesa del distribuidor en una propiedad que el cliente puede verificar.

La alerta debe describir la infracción con precisión: ubicación, sesión, serial, hash anterior, hash nuevo y horas de observación. «Error de actualización» no permite saber si faltó un delta, falló una descarga, cambió el contenido esperado o se inició legítimamente otra sesión.

El snapshot repara una trayectoria, no absuelve un contenido

Cuando la cadena incremental ya no merece confianza, el snapshot vigente ofrece una base completa. El cliente verifica que sus bytes correspondan al hash de la notificación y que sesión y serial cumplan las reglas. Si el snapshot también falla, RRDP no dispone de otra continuidad automática que pueda declarar sana.

Ese restablecimiento tiene coste. Miles de validadores que abandonan pequeños deltas al mismo tiempo pueden descargar objetos completos y cargar al origen, la CDN, la red y sus propios procesos. Reintentar sin límite convierte el mecanismo de recuperación en amplificador. Hacen falta backoff, capacidad, escalado por fases y un criterio explícito para dejar de automatizar.

También hace falta conservar el estado anterior. La notificación previa, la nueva, los hashes superpuestos, los tiempos, los redirects, el motivo de rechazo y el repositorio afectado permiten investigar si hubo error de publicación, incoherencia de CDN, defecto de software o interferencia. Restablecer servicio borrando la única prueba no es control operacional.

RFC 9674 añade otra frontera: las URI de snapshot y delta, además de sus redirecciones, deben compartir esquema, host y puerto con la notificación. La política same-origin impide que un repositorio haga gastar a un relying party recursos de un tercero. Identifica quién responde por el transporte, pero no convierte los bytes en objetos RPKI válidos.

Publicar, transportar y autorizar son trabajos distintos

En el lado de escritura, RFC 8181 permite que un motor de CA solicite a un servicio de publicación crear, reemplazar o retirar productos. La autenticación de ese intercambio usa una PKI de negocio; la validez pública de certificados, CRL y objetos firmados pertenece a RPKI. Una operación de publicación aceptada prueba que el servicio procesó una orden autorizada, no que el objeto superará la validación del relying party.

RFC 6480 sitúa los repositorios como sistema distribuido para hacer accesibles los materiales. RFC 6481 describe la estructura de los puntos de publicación y la necesidad de evitar estados intermedios incoherentes. RRDP mejora la recuperación de una vista, pero no corrige una coreografía de publicación defectuosa.

Después viene la validación de objetos. RFC 6488 exige comprobar la estructura CMS, el certificado end-entity, el tipo de contenido, el digest y la firma, además de las reglas específicas del producto. Una firma correcta detecta modificación no autorizada; por sí sola no demuestra actualidad, presencia o completitud.

Los manifests cubren esa ausencia. RFC 9286 define una lista firmada de archivos y hashes del punto de publicación. Si no están disponibles todos los archivos enumerados, el cliente no debe construir silenciosamente un conjunto con lo que llegó. RFC 9981 actualiza el tratamiento de números de manifest y replay, incluidas condiciones definidas de reinicio.

El número de manifest no es el serial RRDP. Tampoco lo es el serial de la sesión RPKI-to-Router. Cada número pertenece a una máquina de estados y a una autoridad distinta. Ponerlos en una sola columna llamada «versión RPKI» crea una precisión ficticia.

RFC 8897 reúne responsabilidades del relying party. Adquirir y validar pueden implementarse en componentes separados, pero el operador necesita una traza que conecte bytes, manifest, certificados, CRL, objetos aceptados y payloads producidos. El validador es un verificador con memoria, no un espejo pasivo ni el soberano de las rutas.

La ruta solo cambia cuando la política local decide

Una vez reconstruido el repositorio, los validadores pueden añadir o retirar asociaciones validadas de prefijo y origen. RFC 6811 establece que las rutas afectadas deben revalidarse y que la política de routing puede actuar según el estado resultante. La acción no viene prescrita por RRDP.

Una red puede rechazar Invalid, reducir preferencia, marcar, observar o aplicar excepciones más específicas. RPKI comprueba autorización de origen; no prueba el AS_PATH, el forwarding actual ni la experiencia del cliente. Por eso detectar una mutación RRDP no autoriza una purga instantánea.

La cadena de prueba continúa: snapshot aceptado, manifests y CRL vigentes, certificados y objetos válidos, diff de payloads, entrega completa a caches de routers, reejecución de política, cambio en Loc-RIB, instalación en FIB y observación de paquetes. Un estado verde en el validador solo describe un eslabón.

Fuentes