Resumen

  • La serie 23421 del Routinator 0.14.2 de AFRINIC registró 39.059 VRP válidas, 8.212 duplicadas y 30.847 finales para el ancla AFRINIC.
  • La serie 23422 registró 39.058, 8.211 y las mismas 30.847; la variación de una unidad ocurrió en IPv4.
  • Routinator llama duplicadas a las VRP procedentes de ROA con la misma autorización y advierte que su atribución puede variar según el orden de procesamiento.
  • Las capturas no identifican el tuple, la ROA ni un efecto en BGP. El control que falta es un recibo que enlace objetos fuente, multiplicidad, conjunto final y evidencia separada del router.

La aritmética coloca un límite antes de ofrecer una explicación

A las 06:37:53 UTC del 29 de agosto, la última validación completa que mostraba el servicio tenía el número de serie 23421. Bajo el ancla AFRINIC aparecían 39.059 VRP presentes y válidas. De ellas, 8.212 se atribuían como duplicadas. No había VRP peligrosas ni filtradas localmente. La resta daba exactamente las 30.847 que contribuían al conjunto final ofrecido a los routers.

Diecinueve minutos después terminó otra validación. La serie 23422 bajó el primer número a 39.058 y el segundo a 8.211. El tercero permaneció en 30.847. La tabla IPv4 explica toda la variación: 37.804 entradas se convirtieron en 37.803; 8.136 duplicadas, en 8.135; 29.668 finales, en las mismas 29.668. En IPv6 no cambió nada: 1.255 entradas, 76 duplicadas y 1.179 finales.

También cambió el recuento de objetos. La primera captura mostraba 12.171 ROA válidas y ninguna inválida. La segunda mostraba 12.170 válidas y una inválida. Es razonable preguntarse si se trata del mismo episodio. No es razonable responder que sí sin el identificador del objeto. El endpoint no vincula aquella ROA con la ocurrencia duplicada que falta, ni explica por qué cambió su estado.

La observación demostrable es pequeña: el validador contó una entrada válida menos y un duplicado menos, pero aportó el mismo número de VRP finales. No demuestra que un titular retirara una autorización, que AFRINIC arreglara un error o que una ruta cambiara de estado. Tampoco demuestra que el contenido completo del conjunto final fuera idéntico: dos conjuntos pueden tener el mismo tamaño y elementos distintos. Para eso hace falta un diff de tuples.

La tentación periodística consiste en rellenar ese hueco con un verbo. “Eliminó”, “corrigió”, “perdió” o “revocó” parecen dar vida a los números. Cada uno asigna una causa y un actor que la fuente no proporciona. Aquí la disciplina empieza por conservar la voz más modesta: el servicio reportó un estado diferente.

Antes de medir el efecto hay que nombrar bien los objetos

La ROA es un objeto firmado dentro de la RPKI. Contiene un AS de origen y una o varias autorizaciones de prefijo, cada una con su longitud y, si corresponde, una longitud máxima. Tiene un certificado y una ruta de publicación. Puede renovarse, sustituirse o dejar de validar sin que esas posibilidades sean intercambiables.

La VRP es la carga validada que se deriva para comprobar el origen: dirección IP, longitud de prefijo, longitud máxima y ASN de origen. Una sola ROA puede generar varias VRP. Dos objetos o dos recorridos de publicación pueden producir el mismo tuple. Que haya dos ocurrencias no significa que existan dos permisos distintos para el router.

El conjunto final elimina esa multiplicidad. Según la documentación de Routinator, las VRP locales filtradas, las duplicadas y, de acuerdo con la configuración, las consideradas peligrosas no contribuyen de la misma manera. El resultado es el conjunto único que el caché puede proporcionar. En las dos capturas, como no había filtros locales ni VRP peligrosas, la diferencia entre total y final coincide con el número de duplicadas.

La ruta BGP pertenece a otro registro. Se observa un prefijo y se deriva un origen del AS_PATH. La validación compara esa ruta con las VRP: Valid si al menos una coincide, Invalid si alguna la cubre pero ninguna coincide, y NotFound si ninguna la cubre. Un contador de duplicados no dice cuál de esos estados tuvo una ruta concreta.

El último objeto es la decisión del operador. Aunque un caché entregue una VRP, el router debe estar conectado al caché adecuado, recibir una serie, instalar los datos y aplicar una política a una ruta presente. El protocolo RPKI-router reduce trabajo en el equipo, pero no convierte al validador en propietario de la política de red.

Separar estas piezas también separa poderes. El titular firma; el repositorio publica; el validador comprueba y atribuye; el caché sirve; el router decide. AFRINIC opera el ancla y el servicio observado, pero no por ello puede hablar por cada titular ni por cada red consumidora.

“Duplicado” es una relación local, no una acusación

En una hoja de cálculo, una fila duplicada parece basura. En una infraestructura firmada y distribuida, la misma autorización puede aparecer más de una vez por razones muy distintas. Puede haber solapamiento, transición, reemisión, distribución redundante o un error. El total no distingue esas causas.

Routinator ofrece una advertencia especialmente importante: si una VRP aparece en múltiples anclas o repositorios, la ocurrencia que se contabiliza como duplicada depende del orden de procesamiento. Ese orden puede cambiar de una validación a otra, por lo que la atribución e incluso el número pueden variar de forma inesperada.

Esto cambia la lectura del dato. Un duplicado no es por sí mismo una ROA “mala”. Su desaparición no es por sí misma una mejora de seguridad. Puede no cambiar la autorización única disponible para comparar rutas, como sugieren los 30.847 finales constantes. Pero “sugieren” es la palabra correcta: sin identidad de cada tuple no sabemos si el conjunto quedó exactamente igual.

La cautela también impide comparar RIR como si las columnas fueran notas. Los números se obtienen en un validador concreto, con su versión, configuración, fuentes, momento y orden. Una ancla con más duplicados no es automáticamente menos competente. Una con cero no recibe un certificado de limpieza. Antes de evaluar instituciones habría que normalizar el instrumento y entender la topología de objetos.

Hay una diferencia política en esta precisión. Un registro que publica una cifra puede convertirse sin querer en autor de conclusiones que la cifra no sostiene. Un crítico puede usar el valor grande para insinuar desorden; una institución puede usar el final estable para afirmar que nada importa. Ambas posiciones borran la pregunta correcta: ¿qué objetos produjeron la multiplicidad y cambió alguna autorización única?

El estado exhaustivo no es una historia exhaustiva

El endpoint es una buena pieza de infraestructura pública. La documentación dice que ofrece información JSON exhaustiva sobre anclas, repositorios, conexiones RRDP y rsync, y sesiones RTR y HTTP. También alimenta la interfaz de usuario, que muestra estadísticas de la última validación. Gracias a la versión, la serie y la hora podemos fijar dos observaciones precisas.

Sin embargo, la palabra “exhaustiva” se refiere al estado expuesto por el servicio. No promete una genealogía de cada cambio. La respuesta no contiene un diff público entre 23421 y 23422 con hashes de ROA, URI, cadenas de certificados, multiplicidad antes y después, o una causa documentada. Los totales son verificables; su historia queda fuera.

Las sesiones RTR tampoco prueban una consecuencia. Saber que un cliente estuvo conectado no demuestra por sí solo qué serie recibió ni cómo trató una ruta. Una afirmación operacional requiere el recibo del cliente, la serie del caché, una observación BGP y la acción de política. El validador puede atestiguar su salida; no puede atribuirse la decisión posterior.

Esta frontera permite una interpretación proporcionada del dato. No hay indicio público de una ruta perjudicada o de una autorización única perdida. Tampoco hay prueba pública de que la variación sea irrelevante. Lo que falta es una unión que permita resolver la duda sin publicar secretos internos.

El recibo de linaje puede ser pequeño y suficiente

El encabezado debería identificar la medición: versión del software, huella de configuración, serie, hora de inicio y final, conjunto de anclas y huella de repositorios. Así, el número no se presenta como una verdad global separada de su instrumento.

Para cada tuple afectado, el recibo anotaría ASN de origen, prefijo y longitud máxima. Añadiría hashes y URI de los objetos ROA fuente, con referencias limitadas a la cadena de certificados. La multiplicidad mostraría cuántas ocurrencias existían en cada serie y cuál se atribuyó como duplicada.

La causa sería un campo controlado, no una narración automática. Retirada observada, reemisión, fallo de validación, repositorio no disponible o reasignación de atribución solo aparecerían si existe la prueba correspondiente. Sin resolver sería una respuesta válida hasta que un registro posterior la corrija o complete.

Después vendría el diff del conjunto final. No bastaría con repetir 30.847: se indicaría si cada tuple entró, salió o continuó, vinculado a la serie del caché. La sección de efecto en red empezaría únicamente cuando hubiera evidencia de un router o una ruta. Esa separación evita que una observación del validador se convierta en una voz prestada para terceros.

La versión pública no necesita exponer nombres de clientes, credenciales o diagnósticos sensibles. Los tuples, hashes de objetos, recuentos, estados y correcciones son información acotada. Para investigación interna puede conservarse más. Lo esencial es que un agregado tenga una ruta de regreso hacia el objeto.

El registro gana autoridad cuando no exagera

Estas capturas no nombran una red afectada. No muestran un anuncio BGP diferente. No identifican al titular de la ocurrencia ni una acción de AFRINIC para corregirla. Sí muestran que la aritmética de deduplicación cambió sin mover el resultado final contado.

El hallazgo, por tanto, no es que la RPKI “funcionó” o “falló”. Es que la misma palabra, duplicado, reúne una relación entre ocurrencias que puede cambiar por causas distintas. Para saber cuál importa, la evidencia debe atravesar tres fronteras: del objeto firmado al tuple, del tuple al conjunto final y del conjunto al router.

Ese recorrido encaja con una función registral estrecha. AFRINIC no necesita declarar qué intención tuvo un titular ni qué política ejecutó un operador. Puede conservar el recibo que permite a ambos demostrarlo. El valor público está en la continuidad y la corrección del registro, no en convertir una cifra de un instante en un veredicto.

Fuentes