Resumen

  • El diseño RPKI/BGP Intelligence que ARIN aceptó en 2024 prevé que los usuarios de ARIN Online vean anuncios observados, estados de validez y posibles desajustes antes de confirmar un ROA; el texto mantiene a los usuarios de la API en herramientas externas para obtener la misma información.
  • La API REST actual de RPKI puede crear, modificar y borrar ROA mediante una transacción unificada y combinarla atómicamente con cambios de ASPA. No es un canal de lectura marginal, sino una vía de escritura pensada para operaciones de alto volumen.
  • La solución no consiste en bloquear una escritura porque un colector no vea lo esperado. Consiste en ofrecer un preanálisis opcional y legible por máquinas, basado en el mismo modelo de asesoramiento que la pantalla y acompañado por la identidad y caducidad de sus datos.

Una diferencia que aparece antes de escribir

La utilidad de Routing Intelligence no está en explicar RPKI desde cero. Está en crear una pausa cuando todavía se puede rectificar. El operador ya ha indicado prefijo, AS de origen y longitud máxima, pero aún no ha confirmado. Comparar ese proyecto con los anuncios visibles puede revelar que una ruta pasará a Invalid, que otra seguirá NotFound o que la intención escrita no coincide con la red observada.

ARIN formuló así el problema en enero de 2024. La consulta decía que ARIN Online mostraba solamente la información contenida en el ROA y que el cliente necesitaba herramientas de terceros para predecir el efecto en la tabla global. El nuevo panel debía reunir anuncios casi en tiempo real, el estado RPKI, las discrepancias con los ROA existentes y recomendaciones de buenas prácticas antes de efectuar el cambio.

La consulta también fijó el límite: el servicio sería para clientes de ARIN Online; quienes usaran la API tendrían que reunir la misma información en servicios externos. El resultado publicado el 11 de marzo aceptó la propuesta con ese límite intacto. Añadió creación rápida de ROA para anuncios NotFound o Invalid y una promesa de transparencia sobre las fuentes BGP y su frecuencia de actualización.

No cambia quién está autorizado. Tanto en la web como en la API, la organización autenticada debe controlar recursos incluidos en su certificado. Lo que cambia es la prueba disponible antes de actuar. La persona recibe un análisis integrado por ARIN. El sistema automatizado debe escoger vistas BGP, establecer una política de frescura, reproducir la comparación y guardar un resultado que quizá no pueda contrastarse luego con lo mostrado en la web.

La API actual da peso a esa diferencia. Su operación RPKI permite borrar y crear varios ROA en una sola transacción. Puede sumarle operaciones ASPA de modo que todo tenga éxito o todo falle. En ARIN 57, Reg-RWS fue descrita como la API de aprovisionamiento para transacciones de gran volumen. El canal que escala una decisión es precisamente el que mejor puede consumir una comprobación estructurada.

Nada de esto demuestra un incidente causado por la API. Las fuentes no identifican un corte, un ROA perjudicial ni un operador afectado. Tampoco describen cada validación del servidor. La cuestión es de arquitectura pública: la advertencia de impacto está prevista para una interfaz de escritura, no para la otra.

Por qué ARIN puede haber elegido bien el primer destino

Conviene empezar por la defensa más sólida. La mayoría de las organizaciones con RPKI alojado probablemente trabaja en ARIN Online. Una tabla visual permite explicar estados difíciles sin definir de inmediato un contrato programático que deberá versionarse, mantenerse disponible y recibir soporte. Entrega valor pronto a muchos usuarios.

Además, una organización que automatiza ROA suele tener más recursos para integrar RIPEstat, su propio validador, RouteViews, un producto comercial o sesiones BGP internas. ARIN no necesita competir con la amplitud de esas herramientas. En abril de 2026 aclaró que su función sería una ayuda dentro de ARIN Online, limitada a los recursos de la organización, no un sustituto de la visión global más amplia de terceros.

Hay una razón técnica más importante: la advertencia observa, no sabe. En ARIN 56, ARIN nombró a RIPE RIS y Route Views como fuentes y habló de una instantánea relativamente reciente. Sus colectores reciben rutas de pares concretos. No conocen todos los anuncios privados, los pasos futuros de una migración ni la política o el estado de caché de cada red receptora.

Convertir esa instantánea en una prohibición de API mezclaría capacidades distintas. ARIN sí puede establecer si el cliente controla los recursos del certificado. Un colector solo puede afirmar qué vio desde ciertos puntos y en ciertos momentos. Un cambio de emergencia o una transición por etapas puede separarse deliberadamente de esa fotografía.

Por eso el argumento no es “más bloqueo”. Es “el mismo asesoramiento, en una forma que el software pueda leer”.

La predicción no firma ni enruta

En esta cadena hay al menos cinco estados. Primero está la autoridad del titular para solicitar el objeto. Después, el preanálisis compara la propuesta con rutas observadas y VRP disponibles. Luego la escritura cambia la configuración alojada. La publicación lleva los objetos firmados al repositorio. Finalmente, cada relying party los descarga, valida y aplica conforme a su caché y su política.

RFC 6811 define Valid, Invalid y NotFound a partir de una ruta y los VRP locales. RFC 7115 recuerda que la sincronización de cachés depende de cada operador. Por tanto, una previsión de ARIN puede ser correcta para el conjunto de entradas declarado y no ser el estado simultáneo que ven todos los routers.

La documentación de ARIN ya separa momentos. El proceso web incluye Review ROA. El repositorio se actualiza cada pocos minutos y el titular debe utilizar un validador para verificar la activación. Una eliminación se refleja de inmediato en la base RPKI de ARIN y después en el repositorio público dentro del plazo indicado. Revisar, escribir, publicar y usar no son sinónimos.

Un preanálisis de API debe ser una consulta sin efectos secundarios. Recibe la transacción propuesta y devuelve una comparación acotada. No debe crear, reservar, aprobar ni reescribir un ROA.

Qué necesita una respuesta mínima

El primer dato es una huella de la transacción. Si una unidad atómica elimina un ROA, crea dos y modifica un ASPA, la advertencia tiene que corresponder a esos bytes exactos. De otro modo, el informe podría acabar unido a otra versión de la intención.

El segundo es una referencia al estado del certificado de recursos que ARIN utilizó: una versión o un digest bastan. No hace falta exponer credenciales. Hace falta fijar qué recursos podían cubrirse en el momento del cálculo.

El tercero es el conjunto de observaciones. La respuesta debería nombrar las fuentes, fechar cada snapshot e indicar la frescura. Para cada anuncio visto, puede devolver prefijo, origen, estado actual, estado previsto y un código de advertencia estable. La explicación humana seguirá siendo útil; el código evita que un cambio de redacción rompa el pipeline.

El cuarto es la caducidad. Una fotografía de hace diez minutos no es una aprobación permanente. Si una fuente está retrasada o no responde, el resultado debe decir stale o unavailable. El silencio no puede convertirse automáticamente en permiso ni en denegación.

Un token opcional podría correlacionar esa huella con la escritura posterior. Su función sería probatoria, no normativa: demostrar que cierta predicción acompañó a cierta transacción, no certificar que el cambio era seguro.

El canal ya queda registrado después

ARIN ya conserva una parte de esta procedencia. El ROA Change Log etiqueta el origen como Web User, API User o ARIN System y registra fecha, operación Added o Removed, AS de origen, prefijo, maxLength y persona que hizo el cambio. Es un buen libro posterior: permite saber quién modificó qué y por qué entrada.

No dice qué información tuvo delante antes de decidir. No se le debe exigir esa función. El log acredita el linaje de la mutación; el preanálisis conservaría la evidencia disponible cuando todavía era reversible. Relacionar ambos digests permitiría reconstruir la secuencia sin elevar la predicción a veredicto.

La idea de paridad tampoco es nueva en ARIN. En 2023 anunció un nuevo endpoint REST que proporcionaría paridad con las mejoras del formulario web de ROA, incluido el auto-renovado. Aquella promesa no se extiende por sí sola a Routing Intelligence. Sí demuestra que la igualdad de capacidades entre web y API puede tratarse como una propiedad explícita del producto.

Lo que permite afirmar la cronología

ARIN dijo en octubre de 2025 que el desarrollo había comenzado el 30 de septiembre. En abril de 2026 seguía presentando Routing Intelligence como una capacidad cercana, pero futura, y el resumen oficial la enumeró entre los trabajos en curso. La lista de funciones implementadas hasta la versión del 28 de julio de 2026 no la anuncia.

La ausencia en esa lista no prueba que no haya una versión interna, limitada o posterior. Solo permite describir con prudencia una capacidad planificada según el último estado público explícito del paquete de fuentes.

En ARIN 57 también se mencionaron nuevas funciones de API en términos generales, sin asociarlas expresamente con Routing Intelligence. No hay base para prometer paridad ni para declarar que ARIN la ha descartado para siempre. La decisión específica aceptada es web primero y terceros para la API; el lenguaje general posterior deja abierta una modificación.

Una sugerencia comunitaria que sigue abierta pidió, además del análisis web, exportar a CSV prefijos y ASN candidatos antes de confirmar. ARIN respondió que una función web similar estaba en su cartera y que estudiaría el informe descargable. El CSV ayuda a transportar pruebas en un proceso humano. No equivale a un contrato repetible capaz de evaluar la transacción exacta que una aplicación está a punto de enviar.

La modestia hace útil la alerta

La pantalla y la respuesta programática deberían decir qué fuentes observan y cuántos minutos tienen sus datos. “No visto por estos colectores” no significa “no existe en Internet”. “Previsto como Valid” no significa “ya publicado”, y “publicado” no significa “aceptado por todas las redes”.

Con esos límites, la web y la API pueden ofrecer la misma clase de evidencia sin imponer la misma interfaz. Una persona lee la tabla. El programa compara el resultado con la intención local y sus propios feeds, detiene el proceso solo cuando su política lo exige y solicita revisión cuando hay desacuerdo.

ARIN conserva la función de emisor. El titular conserva la decisión. Los colectores siguen siendo observadores y las redes mantienen su política. La API no necesita un nuevo guardián: necesita poder leer la advertencia que el registro ya considera valiosa antes de una escritura humana.

Fuentes