Resumen

  • ARIN otorgó 17.350 dólares a Virginia Tech para convertir un almacén longitudinal de RPKI en un panel público de salud operativa con actualización semanal.
  • El resumen aportado por el beneficiario afirma que la conformidad de revocación va del 9 % en AFRINIC a más del 99 % en ARIN desde 2023 y que la cadencia de nueva firma de ARIN pasó de 14 a 80 días.
  • La página no publica el universo, numerador, periodo ni regla de exclusión de esa conformidad. La API beta sí define métricas próximas, pero no una ruta reproducible hasta esos porcentajes.
  • Cada comparación entre RIR debería incluir un recibo versionado que identifique la pregunta, la población, el estado de validación, la cobertura, el código y el conjunto exacto de resultados.

Una subvención no convierte una afirmación en estándar

La noticia de ARIN registra un proyecto concreto y una cantidad: 17.350 dólares para el RPKI Operational Health Dashboard de Virginia Tech. La ficha ampliada aclara que los textos son resúmenes proporcionados por los beneficiarios. Esa frase pequeña separa tres autoridades: quien financia, quien mide y quien revisa.

El equipo describe un almacén de catorce años con los cinco RIR, cerca de 3.900 millones de observaciones de objetos y 139 GB en Parquet. También dice que su análisis está en revisión en IMC 2026. Es una descripción de escala y estado editorial, no una declaración de que la conferencia haya aceptado el trabajo o de que ARIN haya verificado sus resultados.

Luego llegan las comparaciones. Las ventanas de validez de CRL abarcarían un factor siete; las cadencias de nueva firma, un factor dieciséis; y la “conformidad de revocación”, del 9 % para AFRINIC a más del 99 % para ARIN desde 2023. El resumen atribuye a ARIN un cambio de 14 a 80 días en cadencia, una reducción de diez años a 825 días en la vida de certificados CA y un salto de menos del 5 % a más del 99 % en conformidad.

Esos resultados pueden ser importantes. Precisamente por eso requieren una identidad estable. Una observación de objeto no equivale a un objeto único, una CA, un punto de publicación ni un evento de revocación. Cuantas más veces se observa un objeto, mayor puede ser su peso si el cálculo se hace por filas.

Dos cadencias con el mismo nombre

El RPKI Warehouse enlazado se presenta como un observatorio beta alimentado por instantáneas diarias. Su estado beta impide tratarlo como si ya fuera la entrega definitiva de la subvención. Sin embargo, permite ver por qué el nombre de una métrica no basta.

El esquema de la API define la cadencia de firma como el tiempo entre valores consecutivos de this_update de las CRL de cada CA, identificada por su AKI. El 25 de septiembre, la consulta agregada de ARIN dio una mediana de 24 horas.

El resumen del proyecto habla de 80 días. No hay base para declarar que uno de los dos valores sea erróneo. Pueden usar objetos diferentes, ventanas históricas distintas, otra selección de CA o una agregación incompatible. Una cifra puede seguir CRL actuales; la otra, certificados o productos que se vuelven a firmar bajo otra política. Lo comprobable es más limitado: “cadencia de nueva firma” no identifica por sí sola el cálculo citado.

La API describe con más precisión el atraso de CRL: toma CRL actualmente vivas y resta next_update de la hora actual. Esa fórmula es auditable. No es una definición de conformidad de revocación. En la superficie pública revisada no había una operación con ese nombre ni los elementos para reconstruir el 9 % y el 99 %.

El objeto presente puede no ser el objeto válido

RFC 6487 perfila los certificados de recursos y las listas de revocación. Una CA debe emitir una CRL que cubre sus certificados, y el relying party la usa al validar una ruta de certificación. El RFC define estructura y comprobaciones; no prescribe un índice único para comparar cinco registros.

RFC 9286 obliga a situar esa CRL dentro del manifiesto del punto de publicación. El manifiesto enumera objetos y marca thisUpdate y nextUpdate. Un fallo de descarga puede hacer que un relying party conserve objetos en caché. Otro observador, en otra hora o con otra historia de caché, puede obtener un conjunto distinto.

Por eso el panel debe declarar el estado contado. ¿Basta con que la CRL aparezca en el repositorio? ¿Debe figurar en un manifiesto vigente? ¿Tiene que aceptar el objeto una implementación concreta de relying party? ¿Se excluyen los puntos cuya descarga falló? La diferencia entre “presente” y “válido para un RP” puede alterar tanto numerador como denominador.

También hace falta una unidad. Contar instantáneas pondera mucho a las CA observadas durante más tiempo. Contar CA da el mismo peso a estructuras de tamaños muy distintos. Contar eventos de revocación exige decidir qué acontecimiento crea la obligación. Y atribuir CA alojadas o delegadas a una región puede cambiar el mapa sin que nadie modifique una operación.

El 99 % necesita decir “99 % de qué”

Una posible métrica verificaría si el certificado sustituido aparece en la siguiente CRL. Otra preguntaría si todos los certificados revocados y aún vigentes constan en la CRL actual. Una tercera mediría si se emite una lista nueva dentro de un plazo después del evento. Cada una usa la palabra conformidad de manera plausible.

El tratamiento de lo no observado es igual de decisivo. Un hueco de recolección puede convertirse en incumplimiento, quedar fuera del cálculo o heredar un estado de caché. La expiración puede sacar un certificado del denominador. Una corrección retroactiva puede reescribir la serie o quedar anotada como una versión nueva.

El panel no solo informa a investigadores. Un contraste entre 9 % y más de 99 % puede afectar confianza, auditorías, financiación y reputación. Un lector entenderá que existe una diferencia operativa gigantesca. Para sostenerla, debe poder separar conducta institucional, arquitectura de CA, cobertura del colector y regla de cálculo.

Eso no debilita el proyecto: define su mayor oportunidad. Un panel común puede dar a los operadores una alerta antes que un artículo académico o un informe anual. La condición es que la actualización semanal preserve la procedencia. Si el código o la población cambian detrás de la misma etiqueta, la línea histórica deja de representar una sola pregunta.

Un recibo de medición al lado del gráfico

El recibo empezaría con un identificador permanente y una versión de la métrica. Formularía la pregunta en lenguaje normal y nombraría el objeto o evento. Registraría el perfil RFC aplicable, colector, instantánea, periodo, unidad, numerador y denominador.

Después mostraría inclusiones, exclusiones, deduplicación, atribución regional y manejo de descargas fallidas, caché, objetos expirados y datos ausentes. Separaría CA alojadas de delegadas y presencia en repositorio de validez para el relying party. La versión del código y de los datos, una consulta reproducible, las limitaciones, un historial de correcciones y la huella del resultado cerrarían la prueba.

No hace falta llenar la portada de detalles. “Más del 99 %, RC-2.1, población N, periodo X” puede ser una etiqueta clara con acceso a la receta. Si la cobertura cae, el panel puede mostrarla en lugar de fabricar un éxito o un fracaso.

La disciplina protege a todos. Evita que un cambio de colector parezca una mejora de ARIN y que una CA delegada defectuosa se transforme sin explicación en un veredicto sobre toda la región. También permite que Virginia Tech revise una métrica durante la fase beta sin borrar lo que significaban las versiones anteriores.

Fuentes

  1. ARIN — anuncio de las subvenciones de 2026
  2. ARIN — información detallada de los beneficiarios
  3. RPKI Warehouse beta
  4. Esquema OpenAPI de RPKI Warehouse
  5. Cadencia de firma de ARIN
  6. Atraso de CRL de ARIN
  7. Estado de datos de RPKI Warehouse
  8. RFC 6487 — perfil de certificados de recursos
  9. RFC 9286 — manifiestos de RPKI