Resumen

  • El Routinator público de AFRINIC permite buscar en BGP el ASN de origen de un prefijo y usar ese dato para la validación RPKI. La respuesta final depende de dos fotografías distintas.
  • En la captura verificada, la búsqueda de 196.216.2.0/23 eligió AS33764 desde riswhois mediante una coincidencia exacta. Esa respuesta no incluyó la hora de la fuente BGP; la validación devolvió valid y generatedTime, pero no identificó la instantánea BGP.
  • La página sí ofrece una tabla general con la frescura de RPKI, BGP y los datos de asignación de los RIR. El vacío está en la trazabilidad de cada consulta, no en la ausencia total de transparencia.
  • AFRINIC debería emitir un recibo descargable que una la entrada, el modo de coincidencia, el ASN seleccionado y la versión BGP con la versión de Routinator y los VRP que explican el resultado.

Antes del verde hubo una elección

La validación de origen parece una pregunta binaria solo cuando se omite su preparación. Dado un prefijo y un ASN, un validador puede comparar ese par con los payloads RPKI que ha aceptado. Pero la interfaz de AFRINIC admite otra forma de trabajo: el usuario escribe el prefijo, activa la búsqueda del ASN en BGP y deja que el sistema complete la identidad del origen.

Esa función resuelve un problema cotidiano. En una investigación rápida, el ingeniero puede conocer la dirección y desconocer qué origen observa un colector. El formulario también distingue entre la coincidencia exacta y el prefijo coincidente más largo. No es un detalle decorativo. Si el bloque exacto no aparece o si una ruta más específica cambia, las dos reglas pueden entregar objetos diferentes para la posterior comparación RPKI.

Por eso el resultado ya no responde únicamente «¿qué autoriza RPKI?». Responde «¿qué origen seleccionó esta vista BGP bajo esta regla, y qué estado RPKI obtuvo ese par?». Una sola palabra, valid, queda al final de dos decisiones que no comparten necesariamente reloj, responsable ni ritmo de actualización.

El propio servicio reconoce los relojes separados

Conviene empezar por lo que AFRINIC hace bien. La interfaz no finge que todas sus fuentes se refrescan a la vez. Su bloque Data Freshness muestra una hora para RPKI, otra para BGP y fechas independientes para los archivos de asignación de AFRINIC, APNIC, ARIN, LACNIC y RIPE NCC. El endpoint de estado de Routinator publica la versión del programa, un serial de validación y datos del ciclo de actualización. El endpoint de las fuentes identifica a riswhois como alimentación BGP y entrega un serial y un lastUpdated.

También hay semántica en la respuesta de búsqueda. Para el ejemplo público congelado el 12 de septiembre de 2026, la consulta 196.216.2.0/23 devolvió ese mismo prefijo. Una marca indicó que el contexto de asignación procedía de AFRINIC. Otra indicó sourceType: bgp, sourceID: riswhois, AS33764 y type: exact-match.

El paso siguiente consultó a Routinator por AS33764 y 196.216.2.0/23. La respuesta fue valid. Mostró un VRP coincidente con el mismo ASN y prefijo, y longitud máxima 24. Añadió una hora generatedTime. Es una respuesta bastante más informativa que un semáforo: permite ver el par evaluado y la autorización que coincidió.

Pero las piezas temporales quedaron en lugares distintos. La búsqueda BGP no llevó consigo el lastUpdated de riswhois. El objeto de validez no llevó el nombre de la fuente BGP, la hora de esa observación ni la regla que eligió el ASN. Tampoco incorporó la versión del archivo de asignación que la pantalla utilizó para contexto.

Un usuario diligente podía abrir la tabla de frescura y anotar los datos. Eso no equivale a que la consulta los conserve. La tabla dice cuál era el estado general cuando se visitó. El recibo tendría que decir qué estados concretos consumió el resultado que ahora figura en un ticket o una captura.

Repetir no es reproducir

Supongamos que, una hora después, alguien repite la prueba. BGP puede haber cambiado. Routinator puede haber concluido otro ciclo. La fuente de asignaciones puede haberse actualizado. Aunque la pantalla conserve el mismo color, no se trata de la misma observación. Si cambia de color, tampoco se sabe qué capa explica la diferencia.

Este es el punto que vuelve insuficiente a una captura de pantalla. El tiempo se ve, pero no queda unido. Cuando las fuentes vivas avanzan, ya no existe una forma honesta de volver al conjunto anterior salvo que el servicio o el operador hayan conservado sus identificadores.

No se desprende de aquí que el resultado observado fuese erróneo. Tampoco que AFRINIC carezca de registros internos. El ejemplo no demuestra una ruta obsoleta, una caída, un ataque o un daño para un miembro. Solo demuestra una propiedad del contrato público: la respuesta que selecciona el origen y la respuesta que lo valida no transportan juntas sus versiones.

Hay que acotar también valid. El término indica que al menos un VRP cubre la ruta y coincide con el ASN y la longitud. No certifica el camino AS completo, la visibilidad mundial, la ausencia de fuga, la preferencia de un router ni la legitimidad económica del anuncio. El operador sigue decidiendo qué hacer con ese dato.

La fuente de asignación ocupa una tercera posición. Ayuda a clasificar el bloque y a mostrar prefijos relacionados; no autoriza la ruta ni interviene como prueba criptográfica en el veredicto RPKI. Incluir su versión en el recibo serviría para mantener esa frontera, no para borrarla.

Qué debe contener el recibo

El diseño no exige un archivo voluminoso. Basta con fijar los elementos que ya existen mientras la consulta está viva:

  1. prefijo solicitado y ASN escrito por el usuario, si lo hubo;
  2. activación de la búsqueda automática en BGP;
  3. regla exacta o de prefijo más largo;
  4. prefijo y ASN finalmente seleccionados;
  5. identificador, serial y fecha de actualización de la fuente BGP;
  6. fuente y versión del contexto de asignación, cuando se muestre;
  7. versión de Routinator, serial y finalización del ciclo de validación;
  8. estado y huellas de los VRP coincidentes o no coincidentes;
  9. hora de generación, huella del recibo y referencia a una corrección posterior.

Cada dato necesita además un verbo. riswhois observó un origen desde una vista de BGP. AFRINIC clasificó el recurso en su archivo. Routinator comparó un par con su conjunto validado. El operador decidió una política. Si el recibo mezcla esos verbos, la precisión técnica terminará produciendo una afirmación institucional falsa.

La privacidad no es un obstáculo esencial. Los prefijos y ASN de la prueba pública ya son datos de encaminamiento públicos. Cuando la consulta forme parte de una investigación confidencial, el NOC puede conservar el recibo completo y compartir solo la huella, los seriales, los tiempos y la clase de resultado. No hace falta publicar la identidad del cliente ni sus notas operativas.

La herramienta merece una prueba tan buena como su interfaz

El peligro no es que un comprobador público exista. Es que su facilidad convierta una observación limitada en una autoridad accidental. «La página de AFRINIC salía en verde» puede mutar en «AFRINIC aprobó la ruta». En esa frase desaparecen el colector BGP, el ciclo de Routinator y la política local.

El recibo protege a todos. Al usuario le permite defender qué vio. A AFRINIC le permite limitar su afirmación a lo que hizo el servicio. Al desarrollador le permite probar una actualización con entradas fijadas. Al auditor le permite distinguir entre un cambio de origen, un cambio de ROA, un nuevo ciclo del validador y una modificación de la regla de selección.

AFRINIC ya presenta en la pantalla la intuición correcta: hay varias fuentes y cada una tiene su edad. Solo falta que, al salir de la pantalla, el resultado se lleve esa genealogía consigo.

Fuentes

La página de certificación de recursos de AFRINIC sitúa el servicio, y la interfaz Routinator ofrece la comprobación. El registro congelado incluye el estado de Routinator, el estado de las fuentes BGP y RIR, la búsqueda del prefijo de muestra y la respuesta RPKI correspondiente. La documentación de la interfaz de NLnet Labs explica la función del producto; el bundle versionado de la interfaz expone la lógica observada de búsqueda y frescura.