Una Autorización de Origen de Ruta es un documento firmado digitalmente RPKI Registro que identifica qué ASN está autorizado para originar un prefijo de IP en BGP. Es creado por, o en nombre de, la organización que posee los recursos numéricos de Internet correspondientes. Una ROA normalmente contiene tres elementos esenciales: el prefijo de IP, el ASN de origen autorizado y la longitud máxima del prefijo que el ASN puede anunciar. Por ejemplo, una organización puede controlar el prefijo IPv4 203.0.113.0/24 y utilizar AS64500 para anunciarlo. Una ROA correspondiente puede autorizar a AS64500 a originar ese /24. En términos simples, el registro comunica la siguiente instrucción al ecosistema de enrutamiento: “Este ASN tiene permiso para anunciar este prefijo”. Las redes que realizan validación RPKI pueden entonces comparar el registro con lo que observan en BGP. Una ROA no transfiere la propiedad de un bloque de direcciones IP. No reemplaza un contrato, una entrada en el registro, un registro de asignación ni un acuerdo de transferencia de IPv4. Solo publica una autorización relacionada con el origen de una ruta. El control legal y la autorización de enrutamiento están conectados, pero no son lo mismo. Las ROAs pueden crearse tanto para recursos IPv4 como IPv6. El formato es similar, aunque las longitudes de prefijo y el diseño operativo pueden diferir. Las redes IPv4 suelen trabajar con prefijos como /24, mientras que las redes IPv6 comúnmente anuncian agregaciones como /32, /36, /48 u otra longitud adecuada según su asignación y plan de enrutamiento.
¿Por qué se necesita un ROA?
Sin una ROA, otras redes no tienen autorización basada en RPKI para confirmar que un ASN de origen BGP está autorizado a anunciar un prefijo. La ruta puede seguir siendo legítima, pero generalmente producirá un resultado «Not Found» (No encontrado) durante la validación RPKI porque no existe ninguna autorización coincidente. Un resultado «Not Found» no es automáticamente un problema de enrutamiento. Muchas rutas válidas en Internet no tienen ROAs. Sin embargo, cuando una organización publica una ROA precisa, proporciona a otras redes una señal más sólida que puede utilizarse para distinguir el origen esperado de un origen no autorizado o mal configurado. Una ROA resulta especialmente útil cuando un prefijo es valioso, crítico para el negocio o ampliamente anunciado. Una empresa puede utilizar su propio espacio de direcciones para servicios públicos, una plataforma en la nube puede anunciar infraestructura de sus clientes o un proveedor de alojamiento puede anunciar grandes rangos de direcciones desde múltiples ubicaciones. En estas situaciones, un origen incorrecto puede afectar a muchos usuarios y servicios. Las ROAs también ayudan durante la respuesta a incidentes. Si un prefijo aparece repentinamente desde un ASN inesperado, un operador de red puede comprobar el estado RPKI y determinar rápidamente si el anuncio entra en conflicto con la intención publicada por el titular de los recursos. Esto no explica todos los detalles del incidente, pero proporciona un punto de partida importante para la investigación. Para las organizaciones que utilizan múltiples proveedores de acceso, una ROA puede proporcionar una autorización coherente independientemente de qué proveedor transporte la ruta. El proveedor puede cambiar, pero el ASN de origen puede permanecer igual. En ese caso, la ROA normalmente no necesita modificarse simplemente porque haya cambiado la ruta de tránsito.
¿Cómo funciona un ROA con BGP?
BGP distribuye anuncios de ruta entre sistemas autónomos. Un anuncio de ruta suele incluir un prefijo IP y un ASN de origen, junto con otra información sobre la ruta y las políticas. El ASN de origen es el sistema autónomo que afirma ser la fuente de la ruta. La validación RPKI opera junto con BGP. Un validador recupera datos de autorización firmados del sistema RPKI y verifica que los registros sean auténticos y estén actualizados. Luego, crea un conjunto de datos validado que puede ser utilizado por routers, servidores de rutas o sistemas de políticas de enrutamiento. Cuando una red recibe un anuncio BGP, compara el prefijo anunciado y el ASN de origen con la información ROA validada. Hay tres resultados principales. El anuncio puede ser Válido, Inválido o No Encontrado. Un resultado Válido significa que el anuncio está cubierto por una ROA y que el ASN de origen está autorizado. Un resultado Inválido significa que existe una ROA relevante, pero el anuncio entra en conflicto con ella. Un resultado No Encontrado significa que no se encontró ninguna ROA aplicable. La red receptora decide qué hacer con estos resultados. Algunos operadores rechazan las rutas inválidas. Otros les asignan una menor preferencia, generan alertas o aplican diferentes políticas dependiendo de la fuente. No hay una única política universal para todas las redes, pero muchos proveedores tratan los anuncios inválidos como un grave problema de seguridad de enrutamiento. El punto importante es que la ROA no controla directamente Internet global. Publica información de autorización. El efecto práctico depende de si otras redes recuperan, validan y utilizan esa información en sus decisiones de enrutamiento.
Las tres partes principales de un ROA
La primera parte de una ROA es el prefijo IP que se autoriza, el cual identifica el rango de direcciones que el ASN de origen puede anunciar. Para IPv4, un prefijo podría ser 198.51.100.0/24; para IPv6, podría ser 2001:db8:1234::/48. El prefijo debe corresponder a un recurso que la organización esté autorizada a gestionar a través del registro pertinente o de la relación de patrocinio correspondiente. El prefijo debe introducirse con precisión, ya que un error tipográfico, un límite de red incorrecto o una longitud de prefijo errónea pueden hacer que la ROA sea ineficaz o autorizar un rango diferente al previsto.
La segunda parte es el ASN de origen autorizado para originar el prefijo, que coincide con el ASN que aparece como origen del anuncio BGP. Si una empresa posee un bloque de direcciones pero lo anuncia a través del ASN de un proveedor de tránsito, el origen correcto depende del diseño de enrutamiento real. El ASN en la ROA debería ser normalmente el ASN que origina la ruta, no simplemente el ASN del proveedor ascendente. Esta distinción es importante porque un proveedor de tránsito puede transportar una ruta sin ser su origen; si el ASN del cliente origina el prefijo y el proveedor solo lo transporta, el ASN del cliente suele ser el valor que debe estar autorizado.
La tercera parte es la longitud máxima del prefijo, a menudo denominada maxLength, que define qué tan específico puede ser un anuncio mientras permanece cubierto por el ROA. Supongamos que un ROA autoriza 198.51.100.0/24 con una longitud máxima de /24: la ASN autorizada puede anunciar exactamente el /24, pero no está autorizada para anunciar sub-prefijos más pequeños como /25 o /26. Si el mismo prefijo se autoriza con una longitud máxima de /26, los anuncios para el /24, /25 y /26 pueden considerarse cubiertos dependiendo de la ruta exacta y las reglas de validación. Esto proporciona flexibilidad, pero también permite anuncios más específicos. Por lo tanto, la longitud máxima debe reflejar el plan de enrutamiento real, ya que establecerla demasiado corta puede hacer que rutas más específicas legítimas se vuelvan Inválidas, mientras que establecerla demasiado larga puede autorizar anuncios que la organización nunca tuvo intención de permitir.
¿Por qué es importante maxLength?
La longitud máxima del prefijo es uno de los ajustes ROA más importantes y frecuentemente malinterpretados, ya que controla el nivel de especificidad que la ASN autorizada puede utilizar al anunciar el recurso. Muchos operadores de red anuncian un prefijo agregado para reducir el crecimiento de las tablas de enrutamiento; por ejemplo, una organización puede tener asignado un /20 pero anunciarlo como un único agregado. En algunos casos, la organización también puede necesitar anunciar prefijos más específicos para ingeniería de tráfico, conectividad regional o separación de servicios. Si el ROA cubre únicamente el agregado mientras la red anuncia rutas más específicas, esas rutas pueden clasificarse como Inválidas. El anuncio BGP puede ser técnicamente correcto desde la perspectiva de la organización, pero no coincide con la autorización publicada en RPKI. Por otro lado, autorizar cada posible ruta más específica puede debilitar la precisión de la política, ya que un /20 autorizado con una longitud máxima extremadamente amplia permite que un subprefijo mucho más pequeño aparezca como autorizado incluso si está fuera del diseño previsto. Un enfoque práctico consiste en autorizar únicamente las longitudes de prefijo que la red espera realmente anunciar según su plan de direccionamiento, requisitos del proveedor, diseño de conmutación por error y estrategia de ingeniería de tráfico. Los cambios en la longitud máxima deben probarse cuidadosamente, confirmando que todos los anuncios en producción devuelvan el resultado de validación esperado antes de aplicar filtros estrictos.
ROAs for IPv4 and IPv6
Las ROA pueden crearse tanto para redes IPv4 como IPv6, y el principio de seguridad subyacente es el mismo: vincular un prefijo con un ASN de origen autorizado. La principal diferencia operativa radica en la estructura de direccionamiento. Los recursos IPv4 son escasos y suelen anunciarse en prefijos relativamente pequeños, siendo /24 el tamaño mínimo común de anuncio en Internet público. Las redes IPv6 generalmente reciben asignaciones más grandes y pueden dividirlas en segmentos por sitio, servicio o geografía, anunciando un único agregado mientras utilizan varios prefijos internos. La ROA debe alinearse con los prefijos anunciados públicamente. Los operadores IPv6 no deben asumir que un espacio de direcciones grande elimina el riesgo de enrutamiento, ya que un anuncio IPv6 no autorizado aún puede causar problemas de alcanzabilidad, redirección de tráfico o enrutamiento global inconsistente. RPKI ofrece a los operadores IPv6 la misma oportunidad de publicar autorización de origen que a los operadores IPv4. Antes de crear ROA IPv6, el equipo de red debe documentar qué prefijos agregados se anunciarán, si se esperan anuncios más específicos y qué ASN los originará, evitando registros que sean demasiado restrictivos o innecesariamente amplios.
¿Cuándo deberías crear un ROA?
Se debe crear una ROA antes de anunciar un prefijo en producción siempre que el titular del recurso tenga un plan de enrutamiento claro, lo que permite a las redes validadoras obtener la información antes de que la ruta sea ampliamente visible. Las organizaciones también deben revisar las ROAs cuando reciban una nueva asignación, adquieran un bloque IPv4, completen una transferencia de direcciones, cambien el ASN de origen o comiencen a utilizar una nueva asignación IPv6, ya que estos eventos alteran la relación entre el prefijo y la red de origen. Una migración de proveedor es otro desencadenante común: si la organización mantiene el mismo ASN de origen y solo cambia al proveedor upstream, la ROA puede seguir siendo válida; si la migración cambia el ASN de origen, el registro debe actualizarse antes o simultáneamente con el cambio de enrutamiento. Las ROAs deben revisarse durante fusiones, adquisiciones, cambios de centro de datos, modificaciones en el patrocinio del ASN y grandes rediseños de red para garantizar que la autorización pública coincida con la realidad operativa. Una revisión periódica es útil incluso cuando no se ha producido ningún cambio conocido, ya que la documentación de red queda desactualizada, las responsabilidades del personal cambian y las autorizaciones antiguas pueden permanecer activas mucho después de que el diseño original de enrutamiento haya sido reemplazado.
Errores comunes en la configuración de ROA
Uno de los errores más comunes es introducir el ASN de origen incorrecto, lo que ocurre cuando los ingenieros confunden el ASN del cliente con el del proveedor de tránsito o cuando un ASN antiguo permanece en la configuración tras una migración. Otro error frecuente es olvidar actualizar la ROA después de una transferencia de IPv4, donde el nuevo titular anuncia el prefijo desde su propio ASN mientras que la autorización antigua sigue apuntando al origen anterior, provocando que la ruta se vuelva Inválida. Una longitud máxima incorrecta genera problemas similares cuando una organización autoriza únicamente un /24 pero posteriormente anuncia un /25 para la ingeniería de tráfico. Algunas organizaciones crean múltiples ROAs superpuestas sin documentar su propósito; aunque son válidas en ciertos diseños, pueden producir resultados inesperados y complicar la resolución de problemas. No eliminar registros obsoletos permite que un ASN origine un prefijo mucho tiempo después de que el diseño de red haya cambiado. Por último, algunas organizaciones habilitan la rechazo estricto de rutas Inválidas sin probar primero sus propios anuncios; los prefijos de producción, las longitudes máximas y los ASNs de origen deben verificarse siempre antes de confiar en el filtrado automatizado.
ROA and IPv4 Transfer Planning
Las transferencias de IPv4 requieren una atención especial porque el titular administrativo, el acuerdo de patrocinio y el origen del enrutamiento pueden cambiar en diferentes etapas del proceso. Antes de una transferencia, el titular actual debe documentar las ROAs existentes y confirmar qué ASN origina actualmente el prefijo, mientras que el comprador prepara la información de origen prevista y coordina con los proveedores de tránsito. Durante la transición, ambas partes necesitan un plan claro para actualizar o reemplazar los registros de autorización: dejar la ROA anterior activa demasiado tiempo autoriza el antiguo origen después de la transferencia, mientras que eliminarla demasiado pronto hace que la ruta existente se vuelva Inválida antes de que la nueva ruta esté lista. El proceso exacto depende del registro, el tipo de recurso, el acuerdo de transferencia y el diseño operativo, lo que convierte a RPKI en un elemento esencial de la lista de verificación junto con la verificación del registro, la revisión contractual, los anuncios BGP, los objetos de ruta, el DNS inverso y la evaluación de reputación. Un comprobador público de disponibilidad ayuda a identificar el ASN de origen actual, el estado de RPKI, la información del registro y la visibilidad BGP de un prefijo para verificaciones técnicas previas, aunque no confirma la propiedad legal ni garantiza la elegibilidad para la transferencia.
Cambios en ROA y ASN
Un cambio de ASN afecta directamente a la validación RPKI. Si un prefijo anunciado previamente por AS64500 va a ser anunciado ahora por AS64510, la ROA debe autorizar el nuevo origen antes de que el anuncio BGP pueda ser aceptado como Válido. Esto es especialmente importante cuando una organización pasa de un ASN gestionado por su proveedor a su propio ASN o cambia su acuerdo con LIR patrocinador, lo que requiere revisar conjuntamente la relación en el registro y la autorización de enrutamiento. Una transición cuidadosamente planificada puede implicar autorizar temporalmente tanto los orígenes antiguos como los nuevos para crear una ventana de migración controlada, siempre que esté documentada y se elimine la autorización obsoleta una vez completada. El equipo de red debe probar el orden de las operaciones antes de realizar cambios en producción, asegurándose de que la nueva autorización se publique y valide antes de anunciar la nueva ruta BGP.
¿Cómo se verifica si un ROA está funcionando?
La primera comprobación consiste en confirmar que el ROA contiene el prefijo previsto, el ASN de origen y la longitud máxima del prefijo a través del portal del RIR correspondiente, la interfaz del LIR patrocinador o el sistema de gestión de RPKI. A continuación, se compara la autorización con el anuncio BGP real, verificando que la longitud del prefijo anunciado esté cubierta y que el ASN de origen coincida con el del ROA. Posteriormente, un validador RPKI externo puede confirmar el estado público, donde un anuncio correctamente configurado devuelve Valid (Válido). Si el resultado es Invalid (Inválido), se debe inspeccionar primero el ASN de origen y la longitud del prefijo; si es Not Found (No encontrado), se debe verificar que el ROA haya sido publicado y que los validadores hayan tenido tiempo para recuperarlo. Los resultados no se actualizan instantáneamente porque los repositorios, los validadores y los sistemas de enrutamiento dependen de intervalos de actualización, por lo que son normales pequeños retrasos durante la propagación. Comparar múltiples fuentes públicas, incluidos los datos del registro, los resultados de los validadores y las observaciones actuales de BGP, evita depender de información en caché y proporciona una visión completa.
¿Qué ocurre cuando un ROA es inválido?
Cuando un anuncio BGP entra en conflicto con una ROA existente, los validadores RPKI lo clasifican como Inválido. La ruta no se elimina automáticamente de Internet global, pero las redes que aplican políticas basadas en RPKI pueden rechazarla o asignarle una menor preferencia. El impacto operativo depende del alcance de la aplicación: algunas redes filtran estrictamente, mientras que otras utilizan el estado para monitorización, lo que significa que una ruta Inválida podría seguir siendo visible en partes de Internet mientras resulta inaccesible a través de otras. Si una ruta legítima se vuelve Inválida, la organización debe tratarla como un problema urgente de configuración, priorizando la revisión del ASN de origen, la longitud del prefijo anunciado y la longitud máxima de la ROA. No se debe asumir que la ruta es maliciosa, ya que la mayoría de los resultados Inválidos provienen de errores habituales como migraciones incompletas, registros desactualizados, detalles incorrectos del proveedor o anuncios accidentales de subprefijos más específicos. Una vez corregidos los problemas, los sistemas necesitan tiempo para actualizarse, y el equipo de red debe monitorizar la ruta hasta que se estabilice en todos los puntos de observación.
¿Cómo deberían gestionar las ROA las organizaciones?
La gestión de ROA requiere un propietario claro, ya sea el equipo de ingeniería de red, el equipo de seguridad, el LIR patrocinador, el proveedor de servicios gestionados u otro grupo responsable de los recursos numéricos de Internet. La organización debe mantener un inventario que detalle cada prefijo, ASN de origen, longitud máxima, ubicaciones de anuncio y contactos responsables para simplificar las revisiones de cambios y las respuestas a incidentes. Los cambios en ROA deben integrarse en los procedimientos estándar de cambio de red, tratando RPKI como un requisito explícito durante migraciones de ASN, cambios de proveedor, transferencias de IPv4 o despliegues de IPv6. Se deben configurar monitoreo y alertas para resultados inválidos, orígenes inesperados, autorizaciones eliminadas o cambios en la visibilidad BGP. Crucialmente, las organizaciones deben evitar autorizaciones excesivamente amplias: las ROA precisas son más fáciles de comprender, más simples de auditar y mucho menos propensas a permitir anuncios no deseados.
Preguntas frecuentes
¿Es un ROA lo mismo que un documento de propiedad de IP?
No. Una ROA es una autorización de enrutamiento que indica qué ASN puede originar un prefijo en BGP. No sustituye los registros del registro, contratos, documentos de transferencia ni pruebas de propiedad legal.
¿Puede un prefijo tener más de una ROA?
Sí. Puede ser apropiado emitir múltiples ROAs cuando un prefijo es originado intencionadamente por más de una ASN o cuando una migración controlada requiere autorización temporal para múltiples orígenes, aunque los registros superpuestos deben documentarse cuidadosamente.
¿Un anuncio ROA indica que mi prefijo está en BGP?
No. Crear un ROA no genera un anuncio BGP; la red aún debe configurar BGP a través de sus routers y proveedores de acceso.
¿Es necesario que un proveedor de tránsito figure en el ROA?
Por lo general, el ROA debería identificar el ASN que origina la ruta. Un proveedor que solo transporta la ruta no es necesariamente el ASN de origen, y el valor correcto depende de la arquitectura de enrutamiento real.
¿Cuánto tiempo tarda una ROA en ser visible?
El momento depende del sistema RIR, el repositorio de publicaciones, los intervalos de actualización del validador y el almacenamiento en caché. Las actualizaciones suelen ser visibles relativamente rápido, pero los cambios en producción deben permitir un tiempo suficiente para la validación.
¿Debería cada prefijo IPv4 e IPv6 tener una ROA?
Se recomienda encarecidamente publicar ROAs precisos para los prefijos anunciados en BGP. La organización debe primero confirmar su diseño de enrutamiento para que la autorización no invalide accidentalmente anuncios legítimos.
¿Puede una ROA proteger contra todos los ataques BGP?
No. Una ROA principalmente respalda la validación del origen. No valida cada parte de la ruta BGP, evita todas las filtraciones de rutas, cifra el tráfico ni garantiza que el tráfico siga una ruta física segura.
Una Autorización de Origen de Ruta (ROA) es un componente central del RPKI, que establece una relación firmada criptográficamente entre un prefijo de IP y el ASN autorizado para originar ese prefijo en BGP. El registro normalmente incluye el prefijo, el ASN de origen y una longitud máxima de prefijo; cada uno de estos elementos desempeña un papel decisivo en la identificación del recurso, la autorización del origen y la definición de lo específico que puede ser el anuncio. Las ROA precisas ayudan a las redes a identificar anuncios no autorizados o mal configurados, resultando vitales durante transferencias de IPv4, cambios de ASN, migraciones de proveedores, despliegues de IPv6 y operaciones de redes con múltiples enlaces. Al mismo tiempo, una ROA no constituye prueba de propiedad legal ni una solución autónoma de seguridad de enrutamiento; funciona mejor junto con registros de directorio precisos, configuraciones disciplinadas de BGP, datos IRR, monitoreo de rutas y procesos documentados de cambio. Para cualquier organización que anuncie espacio público IPv4 o IPv6, la regla práctica es sencilla: publicar únicamente los orígenes que se pretenden utilizar, autorizar únicamente las longitudes de prefijo que realmente se planean anunciar, y revisar los registros siempre que se produzcan cambios en la red. Esto mantiene los datos del RPKI alineados con el entorno real de enrutamiento y reduce la posibilidad de que una ruta legítima sea clasificada como Inválida.