Resumen

  • Number Resource Society explica que un ROA vincula un prefijo con un ASN de origen autorizado, puede limitar anuncios más específicos mediante maxLength y debe cambiarse con un proceso controlado.
  • El resultado Valid, Invalid o NotFound observado por un validador describe un estado. Por sí solo no demuestra quién pidió o aprobó el cambio, qué valores se pretendían ni si terminó la retirada.
  • Un registro versionado de autorización y retirada puede enlazar la decisión humana con la publicación del RIR, las observaciones de validadores y las acciones de enrutamiento sin presentar una señal técnica como prueba de intención.

Valid no significa que la decisión esté documentada

La guía de RPKI de Number Resource Society parte de una función concreta: la infraestructura de clave pública de recursos vincula criptográficamente recursos numéricos de Internet con sus titulares legítimos. Una Route Origin Authorization indica qué sistema autónomo puede originar un prefijo. El campo opcional maxLength fija hasta qué longitud se permiten anuncios más específicos. La certificación y publicación pueden estar alojadas en un RIR o gestionarse mediante una autoridad de certificación delegada.

Ese mecanismo permite comparar el origen observado con una autorización publicada. No reconstruye automáticamente la decisión. Un resultado actual no identifica quién propuso otro ASN de origen, quién permitió ampliar maxLength, qué ventana se acordó, ni qué evidencia justificó una reversión de emergencia.

La guía de auditoría de NRS recomienda comprobar si existe el ROA, si coinciden origen y prefijo, si maxLength es adecuado y si la ruta figura como Valid, Invalid o NotFound. También pregunta quién puede crear, modificar o eliminar ROA. Un maxLength demasiado amplio puede autorizar anuncios más específicos de lo necesario; uno demasiado restrictivo puede convertir en Invalid una ruta legítima.

Esos puntos son hechos respaldados por las fuentes. El registro planteado aquí es una inferencia editorial. No afirma que NRS ya lo utilice ni que exista un ROA real incorrecto.

La unidad de control es el cambio versionado

Cada modificación debería tener un identificador estable y conservar los valores anteriores y posteriores de prefijo, ASN de origen y maxLength. El registro añadiría el titular responsable, solicitante, aprobador, hora, ventana y motivo. Si una emergencia acorta el circuito normal, debe constar la regla invocada y quién responde por aplicarla.

Autoridad y ejecución no son lo mismo. Quien solicita puede carecer de facultad para aprobar; quien aprueba puede no operar el portal del RIR; quien activa BGP puede no tener permiso para editar el ROA. Un estado final correcto puede ocultar esa diferencia si todas las funciones se resumen en un único usuario.

También debe escribirse el límite. Autorizar un cambio para un prefijo no autoriza otro. Permitir un nuevo ASN de origen no implica permitir un maxLength mayor. Una facultad temporal para una migración no debería continuar cuando el camino antiguo ya fue retirado.

Una huella del objeto aprobado puede ligar la decisión con los valores enviados. La huella no demuestra que la decisión fuese acertada o jurídicamente eficaz; demuestra algo más limitado y útil: que el objeto observado puede compararse con la versión que vio el aprobador.

Publicación, validación y activación son observaciones distintas

Tras la aprobación, el registro debería guardar la acción de publicación y una referencia autoritativa del RIR con hora de observación. NRS aconseja conservar registros fechados del RIR como evidencia de auditoría. Esa prueba supera al recuerdo de una pantalla, pero sigue describiendo lo observado, no el motivo de la autorización.

Las observaciones de validadores independientes deben registrarse por separado, con hora, punto de vista y software o servicio. Repositorios, cachés y ciclos de actualización diferentes pueden producir una divergencia temporal. Es una señal para investigar, no prueba automática de un fallo de publicación ni de una conducta incorrecta.

Conviene distinguir solicitado, aprobado, enviado, publicación observada, validación observada, ruta activada, retirada solicitada, retirada observada, reversión y sustitución. Cada transición tiene su actor u observador y su marca de tiempo.

NotFound muestra por qué importa la separación. Significa que la vista del validador no encontró un ROA que cubriera la ruta; no explica si la ausencia era deliberada, tardía, errónea o ajena al alcance del cambio. Valid confirma una coincidencia bajo esa vista, pero no la vigencia de la autoridad empresarial de la persona que inició la operación.

Toda migración necesita una secuencia de retirada

NRS indica que, durante una migración, la nueva autorización debería establecerse y validarse antes de retirar la ruta antigua o eliminar el ROA anterior. Un registro convierte ese orden recomendado en evidencia verificable.

Antes de ejecutar, se define el requisito: qué nuevo ROA debe aparecer, en qué validadores y qué control de ruta debe pasar. Después se asigna quién puede activar el nuevo origen, retirar la ruta anterior, reducir o eliminar el viejo ROA y confirmar cada paso.

Retirar no significa borrar. La autorización anterior se conserva, el evento de cierre explica por qué terminó y enlaza con su sustituta o con la reversión. Si se vuelve atrás, el historial muestra que la publicación inicial estaba autorizada en su momento, cuándo se activó el umbral de reversión y qué estado se restauró.

El plan de reversión debe existir antes de abrir la ventana. Sus disparadores pueden incluir un Invalid inesperado, falta de propagación tras el plazo acordado, pérdida de alcance, diferencia entre valores aprobados y observados o imposibilidad de confirmar al operador responsable. “Deshacer” no define un orden seguro cuando la publicación RPKI y la retirada BGP avanzan a ritmos distintos.

Hechos, inferencias e incógnitas deben seguir separados

Las fuentes de NRS sustentan la mecánica de los ROA, maxLength, los estados de validación, el cambio controlado y el orden de migración. No señalan a un operador deficiente, una cuenta comprometida, un prefijo disputado ni un proceso RIR fallido.

Los campos propuestos son una recomendación de gobernanza. Es razonable inferir que unir aprobación, publicación, validación y retirada facilita reconstruir el cambio. No sería razonable inferir que NRS o una entidad concreta carece de controles porque no los detalle en una página pública.

En cada caso siguen abiertas preguntas: quién tenía autoridad real, qué plataforma o CA se usó, cuánto tardó cada validador, qué redes observaron el cambio y qué efecto jurídico tuvo. El registro debe conservar esas incógnitas. Su propósito no es añadir burocracia a RPKI, sino acompañar la autorización criptográfica con responsabilidad humana y una salida ordenada.

Fuentes