MANRS pide una ROA por ruta: prueban las redes heredadas

Resumen

En RIPE 93, Andrei Robachevsky describió una propuesta del grupo de revisión que convertiría Route Origin Validation en un MUST y pediría una ROA válida para cada prefijo anunciado por un participante de MANRS.
Algunos operadores no pueden crear esa prueba por sí solos: los titulares de recursos heredados sin acuerdo con ARIN carecen de acceso al RPKI de ARIN, y el cliente que alquila un prefijo puede no haber creado su ROA.

Análisis

Una ruta aparece en la red del operador. La autorización que la respalda puede depender de otra entidad. Ese desfase es la prueba real de una propuesta que apunta a cubrir con RPKI el 100 % de los prefijos anunciados por los participantes de MANRS.

El 27 de octubre, en RIPE 93, Andrei Robachevsky explicó el trabajo del grupo que revisa el programa MANRS para operadores de red. Las acciones no habían cambiado sustancialmente desde el lanzamiento de MANRS en 2014. El grupo separó el texto normativo de la guía de implementación y auditoría, y adoptó palabras de obligación de estilo IETF para reducir la ambigüedad. En el borrador que presentó, ROV sería MUST; la inscripción en IRR, SHOULD. Para la acción sobre información de enrutamiento, el grupo debatía cobertura RPKI total: cada prefijo que anuncia un participante debería contar con una ROA válida.

La propuesta seguía en revisión. Robachevsky describió una última llamada dentro del grupo y después una convocatoria de comentarios a toda la comunidad. Quería que el texto recogiera voces más allá de los miembros del grupo y de los participantes actuales de MANRS. El transcript oficial de RIPE deja claro que se trataba de trabajo en curso.

El sondeo de MANRS de marzo reunió 38 respuestas, en su mayoría de operadores. La precisión de los requisitos y una auditoría más clara aparecieron entre las prioridades; la mitad de quienes respondieron situó el programa de operadores en primer lugar para la revisión. La página publicada no dice cuántas personas fueron invitadas. Sin ese dato no se puede calcular la tasa de respuesta.

La barrera RPKI tiene un límite institucional concreto. ARIN indica que los titulares de recursos heredados sin un acuerdo con el registro no pueden usar sus servicios RPKI ni IRR. Quienes firman un acuerdo sí pueden acceder. ARIN también limita cada ROA a los recursos incluidos en el certificado del titular. Un operador que anuncia un prefijo ajeno no puede firmar esa autorización con su propio certificado.

Robachevsky señaló el problema en dos frentes: titulares heredados en la región de ARIN sin acceso a RPKI y prefijos alquilados por clientes que llegan a BGP sin ROA. El operador origina o transporta la ruta; el cliente o titular puede conservar el control del registro. Si falta la autorización, la etiqueta de incumplimiento puede caer sobre quien no controla el último paso.

IRR sigue dentro del diseño, pero con otro peso. El borrador lo trataba como SHOULD y el ROV como MUST. Algunos operadores todavía dependen de IRR, y el grupo no había cerrado qué registros y objetos contarían. Presentar IRR como sustituto universal borraría la diferencia que el propio grupo estaba proponiendo. Ignorarlo borraría una herramienta que aún sirve para documentar rutas y construir filtros.

Según Robachevsky, MANRS pasó de nueve operadores en 2014 a cerca de 1.400 en el momento de su charla. El valor del programa está en que muchas redes adopten un piso común, no en reservar una nota perfecta para unos pocos. Una lista de miembros más pequeña puede mejorar su porcentaje de cumplimiento y, a la vez, dejar fuera los prefijos más difíciles.

Por eso el “100 %” necesita una ruta de cumplimiento: qué anuncios requieren una ROA, quién debe crearla, qué hacer cuando el titular controla el registro y cuánto tiempo tendrán los miembros actuales para adaptarse. Sin esas respuestas, la regla reparte la culpa, pero no crea la autorización que falta.