Resumen

  • ROV puede rechazar una ruta que no coincide con los ROA vigentes sin consultar al titular del prefijo. La red decide; la explicación quizá nunca vuelve.
  • iROV propone una autorización firmada a demanda y un canal de retroalimentación. La mejora de alcance citada procede de una simulación, no de un despliegue mundial.

La escena es habitual en una emergencia: un operador desvía tráfico hacia un servicio de mitigación, pero el anuncio nuevo contradice el ROA que los validadores aún tienen. ROV hace lo previsto: la red que valida marca la ruta como inválida y la descarta. El titular puede no enterarse de dónde ocurrió ni del daño a la conectividad.

Younsoo Kim, Seungjin Baek, Weitong Li, Tijay Chung y Min Suk Kang presentan iROV en su trabajo para USENIX Security 2026; Kang lo llevó a NANOG 98. El diseño permite que un validador consulte al titular y obtenga una autorización firmada y puntual. La respuesta puede viajar adherida a la ruta para que validadores posteriores la comprueben localmente, sin volver a consultar. Las consultas probabilísticas reducen la carga inicial.

El resultado más llamativo es un salto de 23% a casi 90% en alcance para cambios urgentes. Es la cifra de la simulación de los autores: fija adopción de iROV al 100% en redes de nivel 1, supone tasas de adopción de ROV y probabilidades de consulta por nivel, y usa un modelo simplificado de propagación y preferencia local. El artículo reconoce que no reproduce toda la variedad de políticas reales. El prototipo BIRD/FORT se probó en un laboratorio cerrado. Ninguno de los dos resultados demuestra rendimiento en producción mundial.

La contrapartida no es menor. La ruta inválida todavía necesita autorización criptográficamente verificable del titular; si falla la consulta o la firma, se aplica el rechazo ROV habitual. Pero alguien debe mantener el servidor del titular, proteger las claves, decidir la política de consultas, clasificar las alertas y responder si una avalancha de peticiones se convierte en el incidente. Los autores no cuantifican esos costos porque dependen del entorno operativo.

iROV es una propuesta seria y una buena pregunta para operadores, no una función ya desplegada. NANOG pregunta qué información de retorno debería ofrecer ROV y cómo añadirla sin riesgos operativos o de seguridad inaceptables. Queda la política: ¿quién fija los valores, quién soporta las alertas y qué situación justifica una excepción urgente?

Fuentes: trabajo de USENIX Security 2026 · sesión oficial de NANOG 98 · RFC 6811: ROV · RFC 6482: ROA. · PDF original