Resumen

  • El proyecto organizó su prueba de ROV en torno a tres comprobaciones: operación normal, protección frente a rutas Invalid y capacidad de respuesta ante un fallo.
  • Los documentos sostienen una cadena limitada entre experimento y guía. No demuestran que las 18 empresas aplicaran rechazo en producción, que no hubiera incidentes ni que JANOG o JPNIC dirigieran la política de cada red.

La pregunta más importante de un control de enrutamiento no es solamente si bloquea lo que debería bloquear. También es qué ocurre cuando se equivoca, quién puede intervenir y cómo se recupera un estado conocido. El ensayo japonés de 2023 puso esas preguntas dentro de la prueba, antes de que el éxito pudiera darse por supuesto.

Sus «tres confirmaciones» exigían comprobar que la red siguiera funcionando normalmente tras introducir ROV, que el mecanismo protegiera contra rutas Invalid y que el operador pudiera responder si se producía un problema. No es una promesa de riesgo cero. Es una forma de tratar la reversibilidad como parte del diseño de seguridad.

JANOG52 hizo visible el trabajo el 5 de julio de 2023. JANOG convocó la conversación y publicó el programa y los materiales de Taiji Kimura, de JPNIC; Katsushi Yamaguchi, de BIGLOBE; y Osamu Nakamura, de la Universidad de Keio y WIDE. Esa función editorial y comunitaria no convirtió a JANOG en propietario del proyecto, regulador ni operador de las redes participantes.

La cadena real de autoridad tuvo varias capas. El Ministerio de Asuntos Internos y Comunicaciones de Japón patrocinó el proyecto. NTT Communications fue el contratista principal. Mitsubishi Research Institute y JPNIC participaron como subcontratistas de apoyo. JPNIC planificó partes de los experimentos de RPKI y DNSSEC, diseñó y operó entornos, recopiló resultados y más tarde publicó la guía. La Universidad de Keio, la Universidad de Osaka mediante Cyber Kansai Project y la Universidad de Nagasaki alojaron instalaciones. Las organizaciones participantes probaron. Cada sistema autónomo conservó la decisión sobre su propia política de rutas.

El informe de JPNIC para el ejercicio 2023 registra 18 empresas en RPKI, ocho en DNSSEC y diez en DMARC. Son cifras de participación en líneas del proyecto. No equivalen a 18 despliegues en producción, 18 políticas de rechazo activadas ni 18 resultados certificados de forma independiente.

Había tres modalidades: experiencia práctica, experimento en el entorno del proyecto y verificación en el entorno del participante. Esa separación evita presentar todo como una única prueba de producción. El expediente público no identifica qué empresa tomó cada modalidad, qué equipos llevaban tráfico ni si se modificó una sesión BGP operativa.

Los laboratorios sí podían introducir rutas BGP Invalid de forma deliberada y ejercitar ROV con datos ROA. Se usaron routers virtuales o físicos de Arista, Cisco, Juniper y Nokia. La cobertura de varios fabricantes aumenta el valor de aprendizaje. No garantiza igualdad de funciones, ausencia de defectos ni seguridad a cualquier escala.

La guía actual de JPNIC conserva la secuencia de la prueba. Primero propone aplicar la validación sin dejar de aceptar rutas Invalid, para observar la carga y las rutas afectadas. Después plantea verificar ejemplos Invalid intencionados. Por último, pide comprobar que SLURM o una política del router pueda restaurar una ruta clasificada por error.

La recuperación, por tanto, no queda fuera del control. La guía describe cómo retirar una política ROV, revisar el comportamiento después de reiniciar el router, medir la reconexión con la caché y responder a clasificaciones Invalid no deseadas. Si una desconexión de caché puede superar el tiempo de retención, contempla detener ROV para un vecino o router o usar SLURM para no descartar rutas Invalid o NotFound.

Pero una excepción local tiene un coste de gobernanza. SLURM crea una vista local personalizada de la información RPKI; no corrige el sistema global. Puede preservar conectividad y a la vez abrir una divergencia de confianza. Las fuentes no dicen quién aprobó cada excepción, cuánto duró ni cómo se reconcilió después.

RFC 6811 sitúa correctamente la autoridad. El estado de validación es una propiedad local de la ruta. La validación no debe excluirla por sí sola; filtrar o cambiar preferencias exige una política local explícita. El estándar también advierte del riesgo de denegación de servicio si se manipulan los datos de validación. ROV valida el origen del prefijo, no la trayectoria AS completa, y el resultado técnico no decide automáticamente la acción correcta.

Una presentación analizó una instantánea de la RIB de AS2500 tomada a las 09:00 del 8 de marzo de 2023. Encontró 905.690 rutas IPv4, 77 Invalid, y 170.405 IPv6, 231 Invalid. Es una vista almacenada de un AS en un instante. No mide paquetes, clientes ni pérdidas de alcance, y no permite inferir el impacto de rechazar esas rutas en todo Japón.

El proyecto dejó una continuación documental. El informe de JPNIC registra una sesión JANOG52.5 sobre el experimento y la guía. JPNIC terminó publicando formalmente el documento; la versión 1.1 estaba vigente el 27 de marzo de 2026 y mantenida por un equipo experto. Eso demuestra aprendizaje institucional, no adopción universal.

El resultado defendible es más pequeño que una proclamación de éxito: el operador debía poder observar un efecto inesperado, conservar la capacidad de decidir y volver atrás. Lo que aún no sabemos es cuántos participantes necesitaron hacerlo, cuánto tardaron y qué impacto real afrontaron.