Resumen

  • Desde octubre de 2023, ARIN notifica a los POC Admin, Tech y Routing cuando se elimina un ROA. En junio de 2024 elevó de 20.000 a 40.000 el máximo de eliminaciones permitido para una organización.
  • ACSP 2025.6 propone una bandera que suprima todo el correo de una llamada de retirada masiva. ACSP 2026.6 señala que la creación y la modificación no notifican a todos los POC.
  • La saturación de correo es un problema real, pero eliminar no es sinónimo de cambio material. Añadir o sustituir una autorización también puede cambiar la clasificación de anuncios de ruta.
  • ARIN podría emitir un único resumen duradero por transacción confirmada, con actor autorizado, diferencia antes/después, resultado atómico, estado de publicación y entrega a un canal independiente.

Dos fechas que no encajan en la misma regla

El 9 de octubre de 2023, ARIN añadió notificaciones en ARIN Online para los POC Admin, Tech y Routing cada vez que se eliminara una Route Origin Authorization. Ocho meses después, el 3 de junio de 2024, duplicó el máximo permitido de eliminaciones de ROA para una organización: de 20.000 a 40.000.

La primera fecha muestra la intención de control. La segunda muestra la escala que la plataforma está preparada para aceptar. Nada en ese registro prueba que una organización haya borrado 40.000 objetos en una operación real. Tampoco permite traducir ese límite en 40.000 rutas caídas. Sin embargo, al poner ambas decisiones juntas aparece un problema de diseño: una alerta definida por objeto puede crecer mucho más deprisa que la información útil que entrega.

Hay una razón seria para avisar de una eliminación. Un ROA expresa que el titular de ciertos prefijos autoriza a un sistema autónomo a originarlos. El RFC 8211 describe qué ocurre cuando desaparece esa vinculación del repositorio: una ruta que antes contaba con ella puede quedar NotFound si no existe otro ROA aplicable, o Invalid si otro ROA cubre el prefijo pero autoriza a un AS distinto.

No es una predicción automática de interrupción. Según los ROA restantes, un anuncio puede conservar el estado Valid, pasar a Invalid o quedar NotFound. Los validadores actualizan en momentos diferentes y cada operador decide qué hacer con una ruta Invalid. El efecto posible basta, no obstante, para justificar que el cambio no quede visible únicamente para la cuenta que lo ejecutó. El usuario de la API puede ser una automatización; el POC administrativo puede custodiar la relación con ARIN; el equipo de routing puede estar de guardia en otro sistema. Separar acción y observación es una defensa razonable.

Lo que deja de ser razonable es confundir esa separación con la multiplicación de mensajes.

La petición de silencio nace de un exceso de señal

ACSP 2025.6 fue presentada el 11 de julio de 2025 por un operador que describió listas de POC extensas, avisos previos a compañeros y una avalancha de correos durante retiradas masivas. La propuesta pide una opción en la API. Su valor predeterminado sería falso; al activarla, se suprimiría toda generación de correo para esa llamada.

ARIN respondió que la función sería beneficiosa y que la priorizaría en su calendario de desarrollo. La página seguía Open y pendiente de implementación cuando se congelaron las fuentes. Por tanto, la propuesta permite analizar una decisión de diseño, pero no afirmar que exista ya una bandera operativa.

El argumento del solicitante merece la mejor lectura. Una operación de mantenimiento no se convierte en miles de decisiones independientes porque contenga miles de objetos. Mandar una copia por objeto y por destinatario consume recursos y, sobre todo, atención. Quien sabe que llegará una ráfaga configura filtros o deja de leer. El canal conserva formalmente todos los avisos y pierde materialmente su capacidad de advertir.

La alternativa propuesta —ningún correo— reduce la carga. También puede borrar la única señal que sale del contexto de la cuenta que hizo el cambio. No es necesario aceptar esa disyuntiva.

Crear un ROA también puede alterar el resultado

ACSP 2026.6 introdujo la mitad que faltaba. Presentada el 23 de abril de 2026, afirma que ARIN y el correo notifican a todos los POC cuando se retira un ROA, pero no cuando se crea o modifica. Pide controles opcionales en las tres operaciones y sugiere incluso una preferencia global por cuenta.

ARIN agrupó la petición con otras mejoras pendientes de notificación, la remitió a priorización y planificación internas y cerró el expediente el 27 de abril. La palabra Closed describe el estado de la sugerencia, no el estado del software.

La asimetría importa porque un alta no equivale siempre a más seguridad. En la validación de origen, un nuevo ROA que cubre un bloque puede hacer que un anuncio originado por otro AS pase de NotFound a Invalid. Lo mismo ocurre si la longitud del anuncio supera el maxLength autorizado. Una modificación puede estrechar el conjunto de prefijos, cambiar el AS de origen o rehacer esa longitud máxima. La operación añade una fila, pero el conjunto comparativo puede retirar validez a otra ruta.

Por eso la alerta no debería seguir la gramática CRUD de la base. Debería seguir la diferencia de autoridad: qué combinaciones de prefijo, origen y maxLength estaban autorizadas antes y cuáles quedaron autorizadas después.

La propia API revela la unidad correcta

La guía RESTful de RPKI de ARIN describe una única llamada por organización para crear, modificar y eliminar ROA. La transacción puede combinar además cambios de ASPA; todo el conjunto tiene éxito o fracasa. El payload distingue listas de objetos que se eliminan y objetos que se añaden.

Esa atomicidad protege una sustitución: si una parte falla, el sistema no debe dejar aceptada media intención. También ofrece un borde claro para la rendición de cuentas. ARIN puede saber que veinte mil eventos pertenecen a una solicitud, quién la envió y cuál fue el resultado común. Romper esa semántica en veinte mil correos no añade veinte mil veces más evidencia.

La misma idea permite interpretar una modificación sin depender del verbo. Una sustitución puede aparecer técnicamente como una eliminación y una adición, pero para el operador es un cambio coordinado. La notificación útil debe mostrar el efecto neto.

El Change Log es una base, no un sustituto de la señal

Desde septiembre de 2025, ARIN Online contiene un ROA Change Log. La documentación actual le atribuye una ventana de 365 días. Cada entrada muestra fecha y hora, operación Added o Removed, fuente Web User, API User o ARIN System, AS de origen, prefijo, maxLength y nombre de la cuenta que hizo el cambio. Las listas largas se paginan y el CSV completo se obtiene mediante una solicitud que ARIN tramita.

Es un registro valioso. Las fuentes no demuestran que sea incorrecto, manipulable o inaccesible. Cualquier propuesta seria debe reconocer que ARIN ya conserva una parte importante del historial operativo.

Pero el registro es una superficie de consulta. El destinatario debe entrar y buscar. Una notificación es una superficie de interrupción: lleva el hecho a otro administrador o a otro sistema. Si la misma cuenta que cambió el ROA está comprometida, la independencia del receptor es parte del control. Si el receptor recibe miles de mensajes sin una identidad común, la independencia existe pero el contexto se fragmenta.

La solución debe unir ambas propiedades: la precisión del registro y la salida independiente del aviso.

Un resumen que describa el cambio neto

Una transacción confirmada debería producir una sola pieza duradera. No hace falta convertirla en un documento público ni revelar datos personales. Debe ser legible por la organización y transportable a un canal de seguridad distinto de la sesión del actor.

Campo mínimo Decisión que permite verificar
Identificador y hora de la transacción Qué solicitud terminó y cuándo
Organización y clase de actor Bajo qué capacidad se ejecutó, sin publicar datos privados
Mezcla de operaciones Si hubo altas, sustituciones, bajas o cambios ROA/ASPA coordinados
Estado anterior y posterior Qué autorizaciones de prefijo, origen y maxLength cambiaron
Resultado atómico Si el conjunto completo se confirmó o falló
Observación de publicación Si el nuevo estado ya aparece en el repositorio o sigue pendiente de observación
Canales independientes Quién recibió el resumen y si la entrega funcionó
Enlace de corrección Qué operación posterior revierte o reemplaza la anterior

Las preferencias de usuario caben alrededor de este núcleo. Una persona puede pedir detalle por objeto; otra, un solo correo; un centro de operaciones, un webhook. Las alertas de bajo riesgo pueden agruparse. Una corrección urgente no debe esperar el consentimiento de todos los POC: notificación no es autorización y acuse de recibo no es veto.

La condición mínima es que una opción llamada suppress no pueda borrar a la vez el registro duradero y toda señal administrada de manera independiente. Silenciar copias redundantes es eficiencia. Silenciar la existencia de la operación es otra decisión.

Límites de la evidencia

No hay en estas fuentes un incidente de 40.000 eliminaciones, una cuenta comprometida, una alerta fallida ni una interrupción de ruta. ACSP 2025.6 sigue pendiente; el cierre de ACSP 2026.6 no prueba implementación. El Change Log está documentado y no se ha demostrado defectuoso. Tampoco todos los operadores aplican la misma política a una ruta Invalid.

La evidencia sí permite delimitar el problema antes del incidente. ARIN tiene una transacción atómica capaz de representar el cambio completo y un historial con campos relevantes. La notificación documentada sigue un solo tipo de operación, mientras las solicitudes públicas proponen ampliar controles o apagar el correo. Cambiar la unidad de objeto a transacción resuelve esa tensión sin entregar a ARIN control adicional sobre el enrutamiento.

Fuentes