Resumen

  • La hoja de ruta de APNIC fija para el tercer trimestre de 2026 una función de REx que mostrará información actual e histórica de VRP para recursos numéricos individuales; la ficha pública aún no define campos, frecuencia, validador ni alcance del archivo.
  • Un ROA firmado, la carga VRP derivada por un relying party, el estado Valid, Invalid o NotFound de una ruta BGP y la política aplicada por un operador no son cuatro nombres para el mismo hecho.
  • La interfaz necesita una franja de procedencia en cada periodo: recurso consultado y relación de cobertura, prefijo, maxLength, ASN de origen, hora de observación, versión del conjunto, método, integridad de la captura y una advertencia de que no muestra la política ni el reenvío de una red concreta.

Las cronologías tienen una cortesía peligrosa: completan la historia por nosotros. Si una barra termina el lunes y otra empieza el martes, el lector supone que el hecho cambió entre ambos días. Si el color pasa de verde a rojo, también imagina una causa y un efecto. El diseño parece limitarse a ordenar fechas, pero en realidad distribuye verbos.

APNIC tiene la oportunidad de decidir esos verbos antes de que aparezca la pantalla. Su Product Roadmap incluye para el tercer trimestre de 2026 el objetivo de mostrar en REx información VRP presente e histórica de un recurso numérico individual. La ficha pertenece al equipo de Información, señala REx y RPKI como productos y promete dos resultados razonables: facilitar el acceso de la comunidad a la información de estado RPKI y aportar contexto histórico a cada recurso.

No conviene exigir a una tarjeta de hoja de ruta el detalle de una especificación. En la captura consultada, el changelog estaba vacío y el texto no indicaba columnas, cadencia de recolección, software de validación, anclas de confianza, identificadores de objetos fuente, reglas de comparación ni retención. Eso no demuestra que el diseño interno carezca de tales decisiones. Solo marca una frontera: la promesa pública aún no explica qué clase de memoria ofrecerá REx.

La pregunta debe resolverse pronto porque una función pública empieza a circular fuera de su contexto. Una captura llega a un ticket de abuso. Un gráfico aparece en una investigación de enrutamiento. Un comprador lo incorpora a la diligencia sobre un bloque. Un académico cuenta transiciones. La página ya no es únicamente una ayuda para navegar datos; se convierte en testigo.

Cuatro planos que comparten prefijo

La primera confusión nace del vocabulario. RPKI reúne objetos relacionados, pero cada uno tiene un sujeto y una autoridad propios.

El ROA es un objeto firmado. APNIC explica que autoriza a un sistema autónomo a originar rutas para un prefijo y que contiene el ASN autorizado, el prefijo y la longitud máxima. RFC 9582 exige que el relying party valide el objeto firmado y cumpla las comprobaciones específicas del ROA antes de usarlo para validar un anuncio. Si una comprobación falla, el ROA entero se considera inválido.

El VRP es una salida derivada. El artículo técnico de APNIC sobre la historia de RPKI describe cómo el software de relying party descarga y valida criptográficamente los objetos y extrae tuplas de ASN, prefijo, longitud y maxLength. La carga validada conserva la autorización que interesa al cálculo de origen, pero no es el fichero firmado ni una prueba autónoma de lo que recibió otro validador.

El estado de origen corresponde a una ruta. Según RFC 6811, se toma un prefijo BGP y su ASN de origen y se busca cobertura en el conjunto de VRP. Hay Valid cuando al menos una carga cubre el prefijo, permite su longitud y coincide con el origen. Hay Invalid cuando existe cobertura pero ninguna coincidencia. Hay NotFound cuando no existe una carga que cubra el prefijo. Sin ruta y origen concretos, esas palabras carecen del sujeto que requiere el algoritmo.

La acción final pertenece al operador. RFC 7115 deja a la política local el uso de la clasificación. Rechazar, reducir preferencia, observar antes de actuar o combinar el resultado con otros atributos son decisiones operativas. La clasificación no lleva incorporada una orden universal. Tampoco prueba por dónde circularon los paquetes: el plano de datos no está garantizado por el anuncio BGP.

Por tanto, un solo “estado” puede ocultar cuatro afirmaciones: el objeto era válido dentro de la PKI; este proceso derivó una determinada tupla; esta ruta fue clasificada frente a ese conjunto; este operador tomó una decisión. REx controla la última redacción de su propia observación, no los demás planos.

La ausencia es el dato más fácil de exagerar

Cuando aparece una tupla, la interfaz puede mostrarla. Cuando desaparece, la tentación es explicar el vacío.

Una observación sin VRP podría coincidir con la retirada deliberada de un ROA. También podría reflejar la expiración o invalidez de un certificado u objeto, un problema de publicación, una recolección incompleta, un reinicio de caché, una laguna histórica, una modificación del método o una consulta que no incluyó la relación de cobertura esperada. La cronología no sabe cuál de esas causas ocurrió a menos que conserve evidencia adicional.

La frase responsable sería: “REx no derivó una carga aplicable en esta observación”. La frase imprudente sería: “el titular dejó de autorizar el prefijo”. La primera describe un conjunto y una hora. La segunda atribuye intención y causa.

Esta diferencia no impide el análisis. Lo mejora. Si la interfaz ofrece la instantánea, el método y la tupla anterior, un operador puede comparar su propio registro y buscar la razón. Si solo ofrece una barra vacía, la discusión empieza por desmontar lo que el color parece afirmar.

Cada caché vive en un reloj

El protocolo entre caché RPKI y router hace visible la importancia del tiempo. RFC 8210 define la caché como una copia agregada de los datos globales publicados y atribuye a su número de serie una versión lógica. Los intervalos de refresco, reintento y expiración gobiernan cuándo se consulta de nuevo y cuánto tiempo puede conservarse una vista anterior. Cuando no existe el historial incremental necesario, la caché puede ordenar un reset y una carga completa.

Ese documento también reconoce que los sistemas distribuidos no pueden permanecer rigurosamente sincronizados. Una observación en REx no tiene por qué coincidir al segundo con la vista de un validador en Manila, Tokio o Auckland. La divergencia temporal no demuestra engaño ni fallo; demuestra que el punto de observación forma parte del dato.

El análisis publicado en el blog de APNIC sobre sincronización separa publicación, caché y aplicación de política. Advierte que una vista incompleta o antigua puede producir validaciones equivocadas, y luego define cómo mide la frescura dentro de su propio estudio. Esa práctica es ejemplar: la palabra “actual” viene acompañada de un criterio.

REx necesita hacer lo mismo. Cada periodo debería llevar un momento de observación y un identificador de snapshot. Si cambia el validador, la configuración relevante, el método de reconstrucción o la lógica de comparación, la línea debe mostrar una frontera metodológica. Sin ella, una mejora del instrumento podría parecer un cambio en la autorización.

No es necesario revelar servidores, credenciales ni topología interna. Basta con que el observador tenga nombre público: conjunto REx, método documentado, versión y hora, junto con una indicación de si la recuperación estuvo completa o sufrió una laguna conocida.

Una consulta puede ser exacta o estar cubierta

“Recurso individual” tampoco define por sí solo el alcance. Si alguien consulta un /24, puede querer saber si existe una carga cuyo prefijo sea exactamente ese /24; si una carga /16 con maxLength /24 lo cubre; o si hay cargas más específicas dentro del espacio. Las tres vistas son legítimas y distintas.

RFC 6811 convierte la cobertura en parte del cálculo. El prefijo de la carga debe ser igual o menos específico y compartir los bits pertinentes; después maxLength limita la longitud que puede coincidir. Ocultar esta relación detrás de un color elimina el dato que explica el resultado.

La interfaz debe etiquetar la relación: exacta, cubriente, más específica o agregada según una definición estable. Si hay varias cargas aplicables, debería mostrarlas sin elegir una como emblema. Si el conjunto cambia, la cronología debe señalar qué tupla entró o salió. El mismo número total puede ocultar el cambio de ASN, una reducción de maxLength o la eliminación de una autorización redundante.

La franja mínima de procedencia

La solución no exige un sistema paralelo. Exige que cada tramo histórico responda a diez preguntas breves:

  1. ¿Qué recurso introdujo el lector y qué relación tiene con el prefijo mostrado?
  2. ¿La fila representa un ROA firmado, un VRP derivado o el resultado aplicado a una ruta?
  3. ¿Cuál es la tupla completa de prefijo, maxLength y ASN de origen?
  4. ¿Cuándo empezó y terminó el periodo y en qué instante, con zona horaria, se observó?
  5. ¿Qué versión, publicación o snapshot de REx sostiene la cita?
  6. ¿Qué método o versión del validador produjo la derivación cuando sea relevante para comparar?
  7. ¿Qué anclas y qué estado de integridad de recuperación delimitan la observación?
  8. ¿Hubo cambio de método o vacío del archivo?
  9. ¿Dónde se encuentra la definición actual y la siguiente observación?
  10. ¿Qué no se muestra: caché de un operador, política local, ruta seleccionada y tránsito real de paquetes?

La lista protege información sensible. No pide claves privadas, credenciales de miembros, detalles inéditos de incidentes ni arquitectura interna. Solo describe con precisión el producto público.

Una prueba útil porque no lo prueba todo

Con la franja, REx podría demostrar que su proceso derivó una determinada tupla en una instantánea, que siguió presente, que fue sustituida por otra o que la observación tiene una laguna. También permitiría a terceros reproducir recuentos y distinguir cambios del mundo de cambios en el método.

No podría demostrar, sin otras fuentes, que el titular retiró la autorización exactamente cuando aparece el primer hueco. No podría asegurar que todos los relying parties vieron lo mismo. No podría calificar una ruta sin identificar prefijo y origen. No podría inferir que un operador rechazó esa ruta ni que se produjo un secuestro, una caída o una variación de tráfico.

La medición de ROA y ROV publicada por APNIC ofrece un ejemplo concreto de atribución. Si un proveedor ascendente filtra rutas Invalid, los usuarios que dependen únicamente de él pueden parecer redes que aplican ROV por sí mismas. La ausencia de conectividad se observa, pero la decisión pertenece a otro punto de la cadena. Una buena metodología conserva esa distancia.

El futuro historial de REx puede ser esa clase de testigo. Un equipo de incidente lo alineará con rutas BGP, salidas de validadores, registros de routers y declaraciones de titulares. Un investigador lo empleará como serie de observaciones, no como narración causal. Un miembro podrá disputar una línea con elementos reproducibles, no con impresiones.

APNIC prometió acceso y contexto histórico, no omnisciencia. Una procedencia visible permitirá cumplir la promesa sin asumir autoridad sobre cada router de Internet.

Fuentes