Resumen

  • El 13 de noviembre de 2025, ARIN bloqueó administrativamente el acceso a los repositorios Hosted y RPS entre las 13:30 y las 14:30 EST. Informó del restablecimiento a las 14:30, de la redundancia completa a las 14:35 y de la vuelta al nivel previo a las 14:50.
  • La prueba demuestra recuperación ante una falta de acceso al repositorio. El registro público no identifica las clases de dependencia externa, los dominios comunes ni el conjunto de observadores planteados en la sugerencia ACSP 2025.7.
  • Una declaración versionada de servicio y dominio de fallo podría registrar el plano protegido, el límite de la prueba, los hitos, los supuestos residuales y el umbral de aviso sin revelar una topología aprovechable para atacar.

La mejor forma de leer el caso no empieza con la palabra «caída», sino con cuatro fechas.

El 23 de octubre de 2025 ARIN recibió el aviso de un cliente sobre Hosted RPKI después de desplegar la compatibilidad de ROA para transferencias. El informe publicado el día 27 acota el problema a una configuración concreta y a un cliente. ARIN detuvo transferencias en curso, encontró un defecto de código, aplicó la corrección y añadió validaciones.

El 28 de octubre, Ramakant Pandrangi presentó la sugerencia 2025.7. La petición miraba más allá del defecto: dependencias por servicio, posibles relaciones circulares, aviso previo de cambios operativos o arquitectónicos y objetivos de continuidad como RTO y RPO. Entre las clases mencionadas estaban DNS, CDN, direcciones IP, rutas BGP y proveedores.

ARIN respondió el 12 de noviembre que preparaba un plan y que lo presentaría a la comunidad para recibir comentarios y validarlo. El 13 de noviembre ejecutó en producción un ejercicio de conmutación de sus repositorios RPKI.

La cercanía temporal no convierte los tres registros en una sola prueba. Un informe de error de software, una solicitud de transparencia y un ensayo de recuperación responden a preguntas distintas.

Cinco horas de reloj para un resultado concreto

El aviso técnico de ARIN relata que a las 13:00 EST empezó a restringir el acceso a los sitios de los repositorios Hosted y RPS. A las 13:30 bloqueó todo acceso para simular una interrupción completa. A las 14:30 lo restableció. A las 14:35 confirmó la redundancia total y a las 14:50 declaró que el sistema había vuelto al nivel anterior.

La decisión de probar en producción también está explicada: para ARIN, un entorno separado no habría representado fielmente el rendimiento y la preparación ante una falla del repositorio. El registro contiene, por tanto, una intervención definida y varios momentos observables. Es evidencia mejor que una promesa genérica de alta disponibilidad.

Su límite es igual de preciso. El bloqueo administrativo reproduce la falta de acceso; no documenta qué proveedor, instalación, sistema de nombres, ruta o plano de identidad dejó de estar disponible. El aviso no dice si dos caminos redundantes comparten una capa externa. Tampoco expone qué validadores confirmaron la recuperación ni mide consecuencias en el enrutamiento.

No son defectos que invaliden el ensayo. Son afirmaciones que el ensayo no realizó.

La redundancia de un servicio y la independencia de su cadena

La sugerencia 2025.7 utiliza dos conceptos exigentes: dependencia sistémica y dependencia circular. Dos instancias pueden responder por separado y, sin embargo, necesitar el mismo DNS o el mismo control administrativo. También puede ocurrir lo contrario: una plataforma externa puede ser una dependencia conocida, diversificada y sustituible, no un punto débil.

Por eso un listado de proveedores sería insuficiente y, a veces, imprudente. La unidad útil es el invariante: qué propiedad debe mantenerse cuando falta una clase de dependencia.

En un repositorio RPKI puede ser la lectura continua del último estado aceptado, la integridad del material servido, un límite para la antigüedad de la publicación o la reconciliación de escrituras cuando vuelve el servicio. El invariante cambia según el plano. Quien descarga material, quien modifica un ROA, quien publica desde una CA delegada y quien restaura el sistema no dependen de la misma operación.

El aviso de mantenimiento de julio de 2026 permite ver esa separación. ARIN Online, RESTful Provisioning, RPKI Up/Down y RPS quedarían sin servicio, mientras el repositorio seguiría accesible sin publicar actualizaciones. Otro artículo de Theo March ya trató el reloj de disponibilidad frente al de frescura. Aquí la cuestión no es cuánto envejecen los datos, sino qué dominio de fallo puede afectar a cada plano y cuál se ejercitó realmente.

Tres modelos, varias custodias

La página actual de ARIN dice que más del 95 % de sus despliegues RPKI usan Hosted RPKI. En ese modelo, ARIN opera la autoridad de certificación y el repositorio de alta disponibilidad. En Delegated, el titular puede operar ambos. RPS permite una división: el titular conserva la CA y el control de la clave privada; ARIN mantiene la publicación.

La página de RPS presenta esa separación como una ventaja. Un repositorio consolidado puede estar fuera del ámbito administrativo del emisor. Una organización quizá quiera conservar la decisión criptográfica sin asumir la operación de un repositorio las veinticuatro horas.

La continuidad también debe dividirse. La CA debe poder crear material válido. El servicio de publicación debe aceptarlo y ponerlo a disposición. Un ejercicio sobre el acceso al repositorio informa de la segunda capacidad. No prueba por sí mismo la CA, el intercambio de publicación, el acceso de la cuenta o las comunicaciones necesarias para autorizar un cambio.

RPS perdería su significado si se tratara la disponibilidad del repositorio como certificado de toda la autoridad del emisor. Su diseño consiste, precisamente, en que las dos custodias no sean una sola.

El 99,9 % no dibuja la arquitectura

El informe anual de ARIN para 2025 asigna un 99,9 % de disponibilidad tanto al repositorio RRDP como al de Rsync. Es un dato sustancial. Permite comparar años y somete una afirmación de fiabilidad a una medida.

No identifica dominios comunes, objetivos de recuperación o pérdida tolerable de estado. Tampoco dice qué parte de ese resultado fue sometida a un escenario concreto. Una disponibilidad alta no demuestra independencia; la ausencia de un mapa público tampoco demuestra fragilidad.

El incidente de octubre sirve para recordar el método. ARIN atribuyó aquel caso a un defecto de código después de un despliegue, con una condición específica y un cliente afectado. El documento ayuda a evaluar el control de cambios. No autoriza a decir que falló un proveedor externo o la redundancia del repositorio.

Separar estos registros protege la exactitud. Una cifra de disponibilidad, un informe de incidente y una prueba de conmutación pueden reforzarse entre sí, siempre que ninguno sea presentado como sustituto del otro.

Transparencia por clases, no por coordenadas

ARIN tiene razones legítimas para no publicar un diagrama detallado. Los nombres de proveedores, las ubicaciones, los puntos de control, las rutas y los disparadores de conmutación pueden aumentar el riesgo. Los contratos también pueden limitar la divulgación.

La alternativa no es el silencio. Para cada servicio y plano, ARIN podría mantener una declaración corta y fechada con:

  1. la función pública y los actores que leen o escriben;
  2. las clases de dependencia y los supuestos de fallo común;
  3. el invariante que se espera conservar;
  4. el escenario y la frontera introducida en la última prueba;
  5. los hitos observados de restricción, restauración, redundancia y normalización;
  6. los modos no cubiertos;
  7. el objetivo de disponibilidad, RTO o RPO aplicable;
  8. el cambio material que obliga a avisar; y
  9. la versión, la fecha de revisión y la ruta de corrección.

«Servicio de nombres», «entrega de contenido», «conectividad», «identidad» e «instalación» pueden ser suficientes como clases públicas. No hace falta decir quién presta cada capa ni dónde está. La precisión procede de enlazar la clase con un invariante y una prueba fechada.

La declaración también debe caducar. Una arquitectura puede cambiar mientras la frase «redundancia completa» permanece en un archivo. Si no existe una revisión, el lector termina aplicando un resultado correcto de 2025 a una frontera que quizá ya no sea la misma. La gestión de cambios solicitada en 2025.7 es el mecanismo que evita esa deriva.

Un estado abierto no es un juicio sobre el trabajo interno

En el corte de esta investigación, la sugerencia 2025.7 seguía marcada como Open. ARIN había dicho que la dejaría abierta hasta la implementación. Eso permite describir el estado del registro. No permite afirmar que no exista trabajo interno, que haya retraso probado o que se oculte una dependencia concreta.

La próxima prueba pública útil puede ser modesta: una primera declaración con límites explícitos. Después, cada nuevo ejercicio añade una fila comparable en lugar de una promesa difícil de acumular.

El ensayo de noviembre ya contiene la disciplina esencial: servicio identificado, intervención real y cronología. Lo que falta para contestar la pregunta de las dependencias no es otra palabra tranquilizadora, sino el vínculo entre el escenario probado y los dominios que quedaron fuera.

Fuentes