La validación RPKI es ahora una parte importante de la seguridad del enrutamiento BGP moderno. Ayuda a los operadores de redes a determinar si un Número de Sistema Autónomo está autorizado para originar un prefijo IPv4 o IPv6 particular. Cuando un router recibe una notificación de ruta, puede comparar la notificación con la autorización RPKI publicada para ese rango de direcciones.
El resultado normalmente se muestra como Válido, Inválido o No encontrado. Estas tres etiquetas son simples, pero a menudo se malentendieron. Un resultado Válido no significa que cada parte del camino sea perfecta. Un resultado Inválido no siempre significa que alguien esté atacando la red. Un resultado No encontrado no significa automáticamente que la notificación sea insegura.
Las etiquetas solo describen la relación entre una notificación BGP y los datos de Autorización de Origen de Ruta disponibles. Para comprender correctamente el resultado, necesita comparar tres detalles: el prefijo IP anunciado, el ASN de origen y la longitud máxima de prefijo permitida por la autorización.
Este artículo explica cada estado de RPKI en términos prácticos, muestra por qué las rutas legítimas pueden volverse Inválidas y proporciona un proceso de solución de problemas para los operadores de red que gestionan su propio ASN, recursos IPv4, asignaciones IPv6 o enrutamiento superior. Si eres nuevo en el tema, empieza con nuestro guía a ¿Qué es RPKI? y luego leer ¿Qué es un ROA en RPKI? para una explicación detallada del registro de autorización en sí mismo.
¿Qué es la validación RPKI?
RPKI significa Infrastructure de Clave Pública de Recursos. Conecta los recursos numéricos de Internet con registros de autorización firmados digitalmente. El titular o gestor autorizado de un prefijo IP puede publicar un ROA indicando que un ASN determinado está autorizado para originar ese prefijo en BGP.
Un validador recopila estos registros firmados, comprueba su autenticidad y crea un conjunto de datos validado para los operadores de red. Cuando se recibe una ruta BGP, el sistema de enrutamiento del operador compara la ruta con ese conjunto de datos. La comparación plantea tres preguntas básicas: ¿Está cubierto el prefijo anunciado por una autorización? ¿Es el ASN de origen el que figura en dicha autorización? ¿La longitud del prefijo anunciado está dentro de la longitud máxima permitida?
La respuesta a esas preguntas produce el estado RPKI. El estado se aplica a la autorización de origen de ruta, no a cada atributo del camino BGP. RPKI no demuestra que todas las redes intermedias sean correctas, que el tráfico siga el mejor camino o que los recursos de dirección estén disponibles legalmente para su venta. Es una señal de seguridad enfocada que mejora la confianza en el origen de una ruta.
¿Qué Significa RPKI Válido?
Un camino es RPKI válido cuando la notificación BGP está cubierta por al menos una ROA aplicable, el ASN de origen coincide con el ASN autorizado y la longitud del prefijo anunciado es permitida por la longitud máxima de la ROA. En términos prácticos, la ruta es consistente con la autorización de enrutamiento publicada por el titular del recurso.
Por ejemplo, supongamos que una empresa controla 203.0.113.0/24 y publica un ROA autorizando AS64500 origenar eso /24. Si la empresa anuncia 203.0.113.0/24 desde AS64500, la notificación debe devolver Válida. Lo mismo es cierto para un ejemplo de IPv6 como 2001:db8:1200::/48 cuando se utilizan el ASN correcto y la longitud de prefijo permitida.
Un resultado válido es una señal positiva, pero no debe interpretarse como una garantía completa. La ruta podría seguir teniendo un camino incorrecto, una mala reputación empresarial, una descripción de registro obsoleta o un problema operativo fuera de la autorización de origen. Los operadores de red normalmente combinan RPKI con monitoreo de BGP, filtrado de prefijos, comprobaciones de registros y procedimientos de respuesta a incidentes.
Un estado válido también puede cambiar cuando la red cambia. Si una empresa mueve un prefijo a otro ASN, comienza a anunciar una ruta más específica o cambia su plan de direcciones, la ROA existente ya no podría coincidir con el nuevo anuncio. RPKI refleja los datos de autorización actuales, por lo tanto debe mantenerse como parte de las operaciones normales de la red.
¿Qué significa RPKI Inválido?
Un camino es RPKI no válido cuando existe una autorización aplicable, pero la notificación BGP entra en conflicto con ella. El conflicto suele implicar una de dos cosas: el ASN de origen no está autorizado, o el prefijo anunciado es más específico que la longitud máxima permitida por la ROA.
Por ejemplo, un ROA puede autorizar AS64500 originar 198.51.100.0/24. Si AS64510 anuncia que ese mismo prefijo, el ASN de origen no coincide y la ruta se convierte en Inválida. El resultado también puede ocurrir cuando AS64500 está autorizado para el /24 pero anuncia 198.51.100.0/25 mientras que la ROA no permite prefijos que específicos.
No válido no significa necesariamente que esté teniendo lugar un secuestro malicioso. Muchos caminos no válidos son causados por errores operativos ordinarios. Un ingeniero puede olvidarse de actualizar un ROA después de una migración de ASN, un proveedor puede anunciar un prefijo de cliente con el origen incorrecto, o la red puede comenzar a utilizar prefijos más específicos sin cambiar la longitud máxima.
Al mismo tiempo, un resultado inválido no debe ignorarse. Puede indicar una publicación no autorizada, una fuga de ruta que involucra un origen inesperado o un error de configuración que puede hacer que el prefijo sea inalcanzable a través de redes que utilizan filtrado estricto RPKI. La respuesta correcta es investigar el resultado rápidamente y compararlo con el diseño de enrutamiento previsto.
¿Qué significa que RPKI no se haya encontrado?
Un camino es No se ha encontrado RPKI cuando el validador no puede encontrar una ROA aplicable para el prefijo anunciado. No hay autorización publicada que pueda confirmar o negar el ASN de origen para esa ruta.
No encontrado a veces se llama "desconocido", porque el sistema de validación no tiene suficiente información de autorización para llegar a una conclusión. No significa que la ruta sea inválida, y no demuestra que el origen esté sin autorizar. Muchos prefijos legítimos en Internet aún no tienen ROA, ya sea porque el titular del recurso no ha creado uno o porque la autorización aún no es visible para el validador.
La ausencia de un ROA reduce la cantidad de información disponible para las redes que desean validar la ruta. Si un ASN no autorizado anuncia el mismo prefijo, una red que vea ambas notificaciones podría tener dificultad para distinguir la ruta legítima de la falsa utilizando solamente RPKI.
Los titulares de recursos deben publicar normalmente ROAs precisos para los prefijos que anuncian públicamente, especialmente cuando los prefijos respaldan servicios importantes. Sin embargo, los operadores deben evitar crear una autorización apresurada o excesivamente amplia simplemente para cambiar "No encontrado" a "Válido". Un ROA mal configurado puede convertir una ruta legítima en "Inválida", lo que podría tener un impacto operativo más inmediato.
La diferencia entre inválido y no encontrado
La distinción más importante es que Inválido es un conflicto, mientras No encontrado es la ausencia de datos de autorización. Inválido significa que el validador encontró una ROA relevante pero la ruta no cumple con ella. No encontrado significa que no se encontró ninguna ROA aplicable.
Considera dos ejemplos. En el primero, una empresa publica un ROA autorizando AS64500 para 192.0.2.0/24, pero AS64510 anuncia el prefijo. La ruta es inválida porque el origen entra en conflicto con la autorización. En el segundo, la empresa no ha publicado ningún ROA, y AS64500 anuncia el prefijo. La ruta no se encuentra porque no hay autorización para evaluar.
Esta diferencia es importante al crear políticas de enrutamiento. Muchas redes tratan especialmente a las rutas Inválidas porque una autorización existente indica que el titular del recurso ha expresado una expectativa específica. Las rutas No Encontradas pueden ser monitoreadas, darse menor prioridad o aceptarse según la política local. Cada red decide cómo aplicar el resultado.
Los operadores de red también deben recordar que los resultados de validación pueden variar temporalmente mientras los repositorios y los validadores se actualizan. Si un ROA fue creado o modificado hace solo unos minutos, diferentes herramientas pueden mostrar estados diferentes hasta que la actualización se haya propagado a través del sistema de validación.
¿Por qué una ruta legítima puede volverse inválida?
La causa más común es un cambio de ASN. Una empresa puede anunciar inicialmente un prefijo desde un ASN proporcionado por una organización superior o patrocinadora y luego mover el prefijo a su propio ASN. Si la ROA sigue autorizando el origen antiguo, el nuevo anuncio se convierte en inválido.
Una segunda causa es una longitud máxima de prefijo incorrecta. Una organización puede poseer un /20, publicar un ROA con una longitud máxima de /20, y más tarde anunciar dos /21 rutas para ingeniería de tráfico. Esas notificaciones más específicas pueden no estar cubiertas por la autorización original. La configuración BGP puede ser intencional, pero la política RPKI es demasiado restrictiva para el nuevo diseño.
Las transferencias de IPv4 pueden generar problemas similares. Durante una transferencia, el titular administrativo y el origen de enrutamiento pueden cambiar en momentos diferentes. Si la autorización del anterior titular sigue activa mientras el nuevo titular anuncia el prefijo desde un ASN diferente, la transición puede producir un estado inválido.
Registros obsoletos, límites de red incorrectos y malentendidos sobre el papel del proveedor de tránsito son otras causas frecuentes. Un proveedor puede transportar la ruta de un cliente sin ser el ASN de origen. La ROA normalmente necesita autorizar al ASN que aparece como origen de la ruta, no simplemente al transportista que transporta el tráfico.
Cómo solucionar un resultado inválido de RPKI
Comience registrando el prefijo exacto y el ASN de origen mostrados en la notificación BGP. No confíe en una visualización abreviada o en un documento de configuración anterior. Confirme la familia de direcciones, la longitud del prefijo y el origen observado por al menos un monitor de enrutamiento confiable.
A continuación, inspeccione los ROAs activos para ese prefijo. Compruebe la ASN autorizada y la longitud máxima del prefijo. Si la ASN de origen no coincide, determine si la ruta o la autorización están equivocadas. Si la ASN es correcta, compruebe si el prefijo anunciado es más específico que la longitud máxima permitida.
Revise los cambios recientes. Busque una migración de ASN, cambio de proveedor superior, transferencia de IPv4, despliegue de IPv6, cambio de centro de datos, cambio en la agregación de rutas o actualización de política BGP. La mayoría de los resultados Inválidos legítimos pueden estar relacionados con un cambio reciente que no se reflejó en la gestión RPKI.
Si el ROA es incorrecto, actualízalo a través del Registro Regional de Internet correspondiente, el LIR patrocinador o el sistema de gestión RPKI. Si la notificación BGP es incorrecta, corrige la política de ruta en su lugar. No resuelvas un error de enrutamiento publicando un ROA innecesariamente amplio, ya que esto podría autorizar notificaciones que nunca se pretendieron.
Tras realizar la corrección, dé tiempo para que el repositorio y el validador se actualicen. Compruebe los resultados nuevamente utilizando un servicio de validación externa y una fuente de monitoreo BGP. La ruta debe volver a ser "Válida" cuando el origen y la longitud del prefijo coincidan con la autorización publicada.
Cómo afectan los resultados de RPKI a la ruta BGP
La validación RPKI no retira automáticamente una ruta de Internet. La red receptora decide cómo utilizar los resultados en su política de enrutamiento. Algunos operadores rechazan las rutas inválidas, mientras que otros las marcan con una menor preferencia, generan alertas o continúan aceptándolas bajo condiciones específicas.
Una ruta válida puede recibir un tratamiento normal, pero aún compite con otras rutas según la preferencia local, la longitud del camino, las reglas de ingeniería de tráfico y la política del proveedor. Una ruta no encontrada puede ser aceptada por una red y tratada con más cuidado por otra. Una ruta inválida puede permanecer visible a través de algunos proveedores mientras que se vuelve inalcanzable a través de redes que aplican filtros estrictos.
Esta diferencia explica por qué una notificación no válida puede causar conectividad parcial. Un servicio puede funcionar desde una región pero fallar desde otra, ya que diferentes redes aplican políticas diferentes. Al diagnosticar un corte, es útil por lo tanto comparar el estado de validación con la visibilidad BGP desde múltiples ubicaciones.
RPKI debe considerarse como una entrada para la política de enrutamiento, en lugar de un reemplazo universal para los filtros de prefijos o el monitoreo de rutas. Los mejores resultados operativos suelen provenir de combinar datos RPKI precisos con registros de registros y enrutamiento cuidadosamente mantenidos.
RPKI Validation for IPv4 and IPv6
Los mismos tres estados se aplican tanto a IPv4 como a IPv6. En cada familia de direcciones, el validador compara el prefijo anunciado, el ASN de origen y la longitud de prefijo permitida con las ROAs disponibles.
Operaciones IPv4 suelen implicar prefijos relativamente pequeños, transferencias, acuerdos de arrendamiento y múltiples proveedores. Un cambio en el ASN de origen o el uso de anuncios más específicos puede afectar rápidamente el resultado de validación. Los titulares de recursos IPv4 deben revisar RPKI cada vez que un bloque sea transferido, arrendado, movido entre proveedores o anunciado desde una nueva ubicación.
Las redes IPv6 suelen recibir asignaciones más grandes y pueden anunciar un agregado mientras utilizan subredes internas más pequeñas. La ROA pública debe coincidir con los prefijos que se anuncian realmente a Internet. Si un operador IPv6 autoriza solo un agregado pero luego anuncia rutas más específicas, esas rutas pueden volverse Inválidas a menos que la longitud máxima lo permita.
A larger IPv6 address space does not remove the need for origin validation. IPv6 route hijacks and configuration mistakes can still interrupt services. Publishing precise ROAs during the initial IPv6 deployment makes future troubleshooting easier and gives upstream networks a clear authorization signal.
Cómo comprobar el estado de RPKI antes de un cambio de red
Antes de cambiar un ASN, proveedor de upstream, plan de agregación de rutas o titular de recursos de dirección, registre el estado actual de RPKI. Confirme qué ASN origina actualmente el prefijo y si la notificación es Válida, Inválida o No encontrada.
Tras preparar el nuevo diseño de enrutamiento, compara las longitudes de origen y prefijo esperadas con los ROAs planeados. Si el origen cambiará, publique o actualice la autorización antes de anunciar la nueva ruta siempre que el horario operativo lo permita. Durante una migración controlada, puede ser adecuado autorización temporal para ambos orígenes, pero el acuerdo debe documentarse y la antigua autorización eliminarse cuando la transición esté completa.
Una revisión técnica también puede revelar inconsistencias relacionadas. La Comprobador de preparación de recursos de IP puede ayudar a revisar la información del registro público, los datos del ASN de origen, los objetos de ruta, el estado RPKI y la visibilidad BGP para un prefijo IPv4 o IPv6 público. Es una verificación técnica en lugar de prueba de propiedad o elegibilidad para transferencia, por lo tanto, la verificación contractual y del registro sigue siendo necesaria.
Preguntas frecuentes sobre el estado de RPKI
¿Es lo mismo que RPKI no encontrado que inválido?
No. No encontrado significa que no se encontró ninguna ROA aplicable. Inválido significa que existe una ROA relevante, pero la notificación BGP entra en conflicto con ella. Lo inválido suele requerir una investigación más urgente, ya que representa un desajuste directo con la autorización publicada.
¿Puede tener un camino válido un problema?
Sí. Valido solo confirma que el ASN de origen y la longitud de prefijo coinciden con un ROA aplicable. No verifica cada parte del camino BGP, seguridad de la aplicación, reputación de la dirección IP, propiedad legal o disponibilidad del servicio.
¿Por qué mi ruta es inválida después de cambiar de proveedor?
Cambiar el operador solo puede no requerir un nuevo ROA si el ASN de origen permanece igual. Sin embargo, si el cambio de proveedor también cambia el ASN de origen, o si el nuevo proveedor anuncia una longitud de prefijo diferente, es posible que se deba actualizar el ROA.
¿Cuánto tiempo tarda en aparecer un cambio de ROA?
El cambio debe ser publicado por el sistema RPKI correspondiente y recuperado por los validadores. Es común que se produzca un breve retraso. Durante un cambio de producción, compruebe más de una fuente de validación y permita tiempo para los intervalos de actualización.
¿Debo rechazar cada ruta No encontrada?
Eso depende de su política de red y modelo de riesgo. No encontrado no demuestra que una ruta esté equivocada. Muchas rutas legítimas no tienen ROA. Algunas redes aceptan rutas "No encontrado" mientras aplican monitoreo o menor preferencia; otras utilizan políticas más estrictas para entornos seleccionados.
¿Puede RPKI proteger tanto IPv4 como IPv6?
Sí. RPKI admite la autorización de origen para ambos familias de direcciones. La configuración práctica debe coincidir con los prefijos y longitudes de prefijo que cada red anuncia realmente.
Etiquetas de estado RPKI son mucho más fáciles de entender cuando se recuerda la diferencia básica entre autorización y observación. Un resultado Válido significa que la ruta coincide con una autorización publicada. Un resultado Inválido significa que la ruta entra en conflicto con una autorización aplicable. Un resultado No encontrado significa que no había ninguna autorización disponible para que el validador la verificara.
Estos resultados son especialmente importantes durante las migraciones de ASN, cambios de proveedor, transferencias de IPv4, implementaciones de IPv6 y redes de rediseño. Una ruta legítima puede convertirse en inválida cuando el origen BGP cambia pero la ROA no se actualiza, o cuando la red comienza a anunciar prefijos más específicos que la longitud máxima permitida.
Para operaciones confiables, revise conjuntamente el prefijo anunciado, el ASN de origen y la longitud máxima del prefijo. Mantenga alineados los registros RPKI con el diseño real de enrutamiento, monitoree los cambios después de la publicación e investigue los resultados inválidos de forma oportuna. Utilice RPKI junto con los registros de registro, el monitoreo de BGP, los datos IRR y la gestión documentada de cambios, en lugar de considerarlo como un reemplazo completo de esos sistemas.
Si desea continuar con la serie, el siguiente artículo útil es Cómo solucionar una ruta RPKI no válida, que puede explicar con más detalle la planificación de la migración, las autorizaciones superpuestas, los cambios de proveedor y las comprobaciones de validación prácticas.