Summary

  • El relying party RPKI deriva una vista local y temporal a partir de repositorios distribuidos, anclas configuradas, reglas, fallos de sincronización y posibles controles locales; no descarga un veredicto global único.
  • draft-su-sidrops-rpki-rp-requirements-00 propone exportar la caché validada en forma estable, explicar los rechazos y conservar estados históricos para comparación, reproducción y análisis.
  • Daniel Kade propone un recibo de estado de validación que una ejecución, entradas, ausencias, huella de caché, cambios locales, entrega a routers y retención. Es una propuesta editorial, no un requisito de la IETF.

El resultado final no revela el camino

RPKI separa publicación, validación y uso. Las autoridades publican certificados, CRL, manifiestos y objetos firmados. El relying party localiza los puntos de publicación, sincroniza material, verifica perfiles y cadenas, decide qué objetos acepta y forma una caché validada. Puede transformar esa vista mediante SLURM. Después, el protocolo RPKI-to-Router entrega datos a equipos que todavía aplican su propia política BGP.

Esa separación es una virtud, pero impide usar una capa como prueba automática de la siguiente. Una ROA válida no demuestra que todos los repositorios estuvieron accesibles. Un manifiesto corriente delimita los objetos actuales de un punto de publicación, no la observación completa de Internet. Una caché que ofrece datos a un router no demuestra que el router instaló o prefirió una ruta. El hecho de que una interfaz esté verde solo resume la evaluación de una implementación bajo una configuración y un momento.

RFC 8210 añade una advertencia especialmente útil. El número de serie de una caché expresa una versión lógica dentro de una sesión. No es comparable con el número de otra caché o versión del protocolo y puede no sobrevivir a un reinicio. Sin versión, Session ID y contexto temporal, “serie 417” carece de identidad global.

Una actualización que reconoce el trabajo operativo

El borrador individual del 12 de junio de 2026 intenta renovar RFC 8897 como punto único de referencia. Reúne requisitos que ahora abarcan claves sucesoras de anclas, sincronización RRDP, manifiestos, ROA, ASPA, RSC, TAK, certificados, CRL, distribución de caché y control local. También señala que varias referencias a trabajos de SIDROPS siguen siendo provisionales.

Su frontera institucional es clara: Datatracker no lo presenta como documento adoptado por un grupo ni como resultado del consenso de la IETF. No tiene flujo RFC, AD responsable ni telechat. El encabezado aspira a estado informativo y a actualizar RFC 8897 si algún día se aprueba. El artículo no atribuye al texto implantación ni cumplimiento real.

La novedad analítica aparece en tres verbos: exportar, explicar y conservar. El software debería poder exportar la caché validada en un formato estable y legible por máquinas. Debería ofrecer diagnóstico suficiente sobre fallos de repositorio, sincronización, análisis y validación. Y debería guardar estados históricos o registros equivalentes para comparar, reproducir y analizar después.

El conjunto convierte la observabilidad en una propiedad del producto de seguridad. Sin exportación no hay objeto comparable. Sin explicación no se conocen las exclusiones. Sin historia no se sabe qué cambió.

La sincronización también decide

Los repositorios RPKI son distribuidos y los mecanismos de recuperación no son neutros. El borrador exige controles de mismo origen para RRDP conforme a RFC 9674 y recomienda detectar y recuperar la desincronización conforme a RFC 9697. Un cliente puede necesitar una instantánea, cambiar de protocolo o declarar fallido un fetch.

El tratamiento de manifiestos muestra por qué importa la evidencia negativa. Un manifiesto ausente, inválido o obsoleto; un fichero listado que no aparece; una huella incorrecta; o un objeto alojado fuera del punto exigido cambian el resultado. La CRL pertinente debe estar vinculada al manifiesto válido y corriente. “Validé 40.000 objetos” no dice cuáles faltaron ni por qué.

Además, certificados y objetos tienen tiempo. El canal caché-router incorpora intervalos de refresco, reintento y caducidad. La salud actual puede coexistir con un período anterior incompleto que todavía influyó en routers. Solo una secuencia histórica permite medir la ventana.

Una excepción local debe llevar apellido

RFC 8897 y RFC 8416 permiten filtros y aserciones locales mediante SLURM. La facultad responde a necesidades reales: contener una acción adversa, salvar una interrupción conocida o expresar una excepción operativa delimitada. No reescribe, sin embargo, el objeto global.

La red que aplica el cambio posee una vista local. Si no se marca esa transformación, el lenguaje traslada responsabilidad hacia el publicador o titular del recurso. Si se documenta, la excepción puede tener propietario, justificación, vigencia y retirada.

La divergencia tampoco demuestra por sí sola un fallo. Puede señalar versiones distintas, conjuntos de anclas diferentes, un repositorio inaccesible, una recuperación en curso o una política local. El trabajo del registro de auditoría es mantener abiertas esas hipótesis hasta que la evidencia permita cerrarlas.

Un recibo que una las capas

El recibo propuesto por Daniel Kade no figura en el borrador. Sería un resumen verificable, no un volcador de secretos.

Primero identifica la ejecución: producto y versión, perfil de validación, huella de configuración, familias de objeto, anclas de confianza y condición del reloj. Después registra adquisición: puntos intentados, protocolo, última observación satisfactoria, intento actual, fallback y motivos acotados de fallo.

La sección de validación conserva estado de manifiestos y CRL, conteos aceptados y rechazados por tipo, categorías de rechazo, transición de ancla y huella canónica de la caché. La sección local incorpora el identificador y digest de filtros o aserciones, su aprobación y vigencia.

La entrega necesita versión de RPKI-to-Router, Session ID, serie, momento de exportación y alcance de consumidores. No basta con el número de serie. Por último, el recibo apunta al estado anterior, horizonte de retención, responsable y corrección posterior.

Las claves privadas, credenciales y topología que no sea necesaria quedan fuera. Una organización puede conservar ciertos detalles bajo acceso restringido y publicar solo digest, tiempos y clases de resultado. Descentralizar la validación no obliga a centralizar la auditoría.

Una prueba útil porque reconoce su límite

El recibo no certifica que el objeto de origen sea verdadero, que todos los validadores deban coincidir o que el router utilizó el dato. Tampoco explica una decisión humana de excepción si esa aprobación no tiene expediente propio. Su mérito es menor y más práctico: permite reconstruir cuál fue la vista local ofrecida al sistema de encaminamiento.

La seguridad del enrutamiento necesita respuestas operables, y las interfaces necesitan síntesis. El problema empieza cuando la síntesis sustituye al rastro. Un verde sin historia no se puede contrastar después de un cambio. Una caché exportable, acompañada de rechazos, transformaciones y contexto de entrega, sí puede entrar en una revisión responsable.

Sources

  1. Lu Heng — The Policy Mirror
  2. Lu Heng — Minimum Initial Specification
  3. Lu Heng — Why BTW Media Exists
  4. Borrador de requisitos RPKI RP, revisión 00
  5. Estado en Datatracker
  6. Historial del borrador
  7. Grupo SIDROPS
  8. RFC 8897 — Requisitos para relying parties RPKI
  9. RFC 6480 — Infraestructura para el encaminamiento seguro
  10. RFC 9286 — Manifiestos RPKI
  11. RFC 9674 — Política de mismo origen para RRDP
  12. RFC 9697 — Desincronización de sesiones RRDP
  13. RFC 9691 — Claves de ancla de confianza RPKI
  14. RFC 8416 — SLURM
  15. RFC 8210 — Protocolo RPKI-to-Router v1
  16. RFC 9582 — Autorizaciones de origen de ruta
  17. RFC 9829 — Extensiones de número CRL RPKI