La validaci\u00f3n RPKI es ahora una parte importante de la seguridad del enrutamiento BGP moderno. Ayuda a los operadores de redes a determinar si un N\u00famero de Sistema Aut\u00f3nomo est\u00e1 autorizado para originar un prefijo IPv4 o IPv6 particular. Cuando un router recibe una notificaci\u00f3n de ruta, puede comparar la notificaci\u00f3n con la autorizaci\u00f3n RPKI publicada para ese rango de direcciones.<\/p>\n\n\n\n
El resultado normalmente se muestra como V\u00e1lido, Inv\u00e1lido o No encontrado. Estas tres etiquetas son simples, pero a menudo se malentendieron. Un resultado V\u00e1lido no significa que cada parte del camino sea perfecta. Un resultado Inv\u00e1lido no siempre significa que alguien est\u00e9 atacando la red. Un resultado No encontrado no significa autom\u00e1ticamente que la notificaci\u00f3n sea insegura.<\/p>\n\n\n\n
Las etiquetas solo describen la relaci\u00f3n entre una notificaci\u00f3n BGP y los datos de Autorizaci\u00f3n 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\u00e1xima de prefijo permitida por la autorizaci\u00f3n.<\/p>\n\n\n\n
Este art\u00edculo explica cada estado de RPKI en t\u00e9rminos pr\u00e1cticos, muestra por qu\u00e9 las rutas leg\u00edtimas pueden volverse Inv\u00e1lidas y proporciona un proceso de soluci\u00f3n 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\u00eda a \u00bfQu\u00e9 es RPKI?<\/a> y luego leer \u00bfQu\u00e9 es un ROA en RPKI?<\/a> para una explicaci\u00f3n detallada del registro de autorizaci\u00f3n en s\u00ed mismo.<\/p>\n\n\n\n RPKI significa Infrastructure de Clave P\u00fablica de Recursos. Conecta los recursos num\u00e9ricos de Internet con registros de autorizaci\u00f3n firmados digitalmente. El titular o gestor autorizado de un prefijo IP puede publicar un ROA indicando que un ASN determinado est\u00e1 autorizado para originar ese prefijo en BGP.<\/p>\n\n\n\n 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\u00f3n plantea tres preguntas b\u00e1sicas: \u00bfEst\u00e1 cubierto el prefijo anunciado por una autorizaci\u00f3n? \u00bfEs el ASN de origen el que figura en dicha autorizaci\u00f3n? \u00bfLa longitud del prefijo anunciado est\u00e1 dentro de la longitud m\u00e1xima permitida?<\/p>\n\n\n\n La respuesta a esas preguntas produce el estado RPKI. El estado se aplica a la autorizaci\u00f3n de origen de ruta, no a cada atributo del camino BGP. RPKI no demuestra que todas las redes intermedias sean correctas, que el tr\u00e1fico siga el mejor camino o que los recursos de direcci\u00f3n est\u00e9n disponibles legalmente para su venta. Es una se\u00f1al de seguridad enfocada que mejora la confianza en el origen de una ruta.<\/p>\n\n\n\n Un camino es RPKI v\u00e1lido<\/strong> cuando la notificaci\u00f3n BGP est\u00e1 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\u00e1xima de la ROA. En t\u00e9rminos pr\u00e1cticos, la ruta es consistente con la autorizaci\u00f3n de enrutamiento publicada por el titular del recurso.<\/p>\n\n\n\n Por ejemplo, supongamos que una empresa controla Un resultado v\u00e1lido es una se\u00f1al positiva, pero no debe interpretarse como una garant\u00eda completa. La ruta podr\u00eda seguir teniendo un camino incorrecto, una mala reputaci\u00f3n empresarial, una descripci\u00f3n de registro obsoleta o un problema operativo fuera de la autorizaci\u00f3n 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.<\/p>\n\n\n\n Un estado v\u00e1lido tambi\u00e9n puede cambiar cuando la red cambia. Si una empresa mueve un prefijo a otro ASN, comienza a anunciar una ruta m\u00e1s espec\u00edfica o cambia su plan de direcciones, la ROA existente ya no podr\u00eda coincidir con el nuevo anuncio. RPKI refleja los datos de autorizaci\u00f3n actuales, por lo tanto debe mantenerse como parte de las operaciones normales de la red.<\/p>\n\n\n\n Un camino es RPKI no v\u00e1lido<\/strong> cuando existe una autorizaci\u00f3n aplicable, pero la notificaci\u00f3n BGP entra en conflicto con ella. El conflicto suele implicar una de dos cosas: el ASN de origen no est\u00e1 autorizado, o el prefijo anunciado es m\u00e1s espec\u00edfico que la longitud m\u00e1xima permitida por la ROA.<\/p>\n\n\n\n Por ejemplo, un ROA puede autorizar No v\u00e1lido no significa necesariamente que est\u00e9 teniendo lugar un secuestro malicioso. Muchos caminos no v\u00e1lidos son causados por errores operativos ordinarios. Un ingeniero puede olvidarse de actualizar un ROA despu\u00e9s de una migraci\u00f3n de ASN, un proveedor puede anunciar un prefijo de cliente con el origen incorrecto, o la red puede comenzar a utilizar prefijos m\u00e1s espec\u00edficos sin cambiar la longitud m\u00e1xima.<\/p>\n\n\n\n Al mismo tiempo, un resultado inv\u00e1lido no debe ignorarse. Puede indicar una publicaci\u00f3n no autorizada, una fuga de ruta que involucra un origen inesperado o un error de configuraci\u00f3n que puede hacer que el prefijo sea inalcanzable a trav\u00e9s de redes que utilizan filtrado estricto RPKI. La respuesta correcta es investigar el resultado r\u00e1pidamente y compararlo con el dise\u00f1o de enrutamiento previsto.<\/p>\n\n\n\n Un camino es No se ha encontrado RPKI<\/strong> cuando el validador no puede encontrar una ROA aplicable para el prefijo anunciado. No hay autorizaci\u00f3n publicada que pueda confirmar o negar el ASN de origen para esa ruta.<\/p>\n\n\n\n No encontrado a veces se llama \"desconocido\", porque el sistema de validaci\u00f3n no tiene suficiente informaci\u00f3n de autorizaci\u00f3n para llegar a una conclusi\u00f3n. No significa que la ruta sea inv\u00e1lida, y no demuestra que el origen est\u00e9 sin autorizar. Muchos prefijos leg\u00edtimos en Internet a\u00fan no tienen ROA, ya sea porque el titular del recurso no ha creado uno o porque la autorizaci\u00f3n a\u00fan no es visible para el validador.<\/p>\n\n\n\n La ausencia de un ROA reduce la cantidad de informaci\u00f3n 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\u00eda tener dificultad para distinguir la ruta leg\u00edtima de la falsa utilizando solamente RPKI.<\/p>\n\n\n\n Los titulares de recursos deben publicar normalmente ROAs precisos para los prefijos que anuncian p\u00fablicamente, especialmente cuando los prefijos respaldan servicios importantes. Sin embargo, los operadores deben evitar crear una autorizaci\u00f3n apresurada o excesivamente amplia simplemente para cambiar \"No encontrado\" a \"V\u00e1lido\". Un ROA mal configurado puede convertir una ruta leg\u00edtima en \"Inv\u00e1lida\", lo que podr\u00eda tener un impacto operativo m\u00e1s inmediato.<\/p>\n\n\n\n La distinci\u00f3n m\u00e1s importante es que Inv\u00e1lido es un conflicto<\/strong>, mientras No encontrado es la ausencia de datos de autorizaci\u00f3n<\/strong>. Inv\u00e1lido significa que el validador encontr\u00f3 una ROA relevante pero la ruta no cumple con ella. No encontrado significa que no se encontr\u00f3 ninguna ROA aplicable.<\/p>\n\n\n\n Considera dos ejemplos. En el primero, una empresa publica un ROA autorizando Esta diferencia es importante al crear pol\u00edticas de enrutamiento. Muchas redes tratan especialmente a las rutas Inv\u00e1lidas porque una autorizaci\u00f3n existente indica que el titular del recurso ha expresado una expectativa espec\u00edfica. Las rutas No Encontradas pueden ser monitoreadas, darse menor prioridad o aceptarse seg\u00fan la pol\u00edtica local. Cada red decide c\u00f3mo aplicar el resultado.<\/p>\n\n\n\n Los operadores de red tambi\u00e9n deben recordar que los resultados de validaci\u00f3n 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\u00f3n se haya propagado a trav\u00e9s del sistema de validaci\u00f3n.<\/p>\n\n\n\n La causa m\u00e1s com\u00fan es un cambio de ASN. Una empresa puede anunciar inicialmente un prefijo desde un ASN proporcionado por una organizaci\u00f3n 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\u00e1lido.<\/p>\n\n\n\n Una segunda causa es una longitud m\u00e1xima de prefijo incorrecta. Una organizaci\u00f3n puede poseer un 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\u00f3n del anterior titular sigue activa mientras el nuevo titular anuncia el prefijo desde un ASN diferente, la transici\u00f3n puede producir un estado inv\u00e1lido.<\/p>\n\n\n\n Registros obsoletos, l\u00edmites de red incorrectos y malentendidos sobre el papel del proveedor de tr\u00e1nsito 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\u00e1fico.<\/p>\n\n\n\n Comience registrando el prefijo exacto y el ASN de origen mostrados en la notificaci\u00f3n BGP. No conf\u00ede en una visualizaci\u00f3n abreviada o en un documento de configuraci\u00f3n anterior. Confirme la familia de direcciones, la longitud del prefijo y el origen observado por al menos un monitor de enrutamiento confiable.<\/p>\n\n\n\n A continuaci\u00f3n, inspeccione los ROAs activos para ese prefijo. Compruebe la ASN autorizada y la longitud m\u00e1xima del prefijo. Si la ASN de origen no coincide, determine si la ruta o la autorizaci\u00f3n est\u00e1n equivocadas. Si la ASN es correcta, compruebe si el prefijo anunciado es m\u00e1s espec\u00edfico que la longitud m\u00e1xima permitida.<\/p>\n\n\n\n Revise los cambios recientes. Busque una migraci\u00f3n de ASN, cambio de proveedor superior, transferencia de IPv4, despliegue de IPv6, cambio de centro de datos, cambio en la agregaci\u00f3n de rutas o actualizaci\u00f3n de pol\u00edtica BGP. La mayor\u00eda de los resultados Inv\u00e1lidos leg\u00edtimos pueden estar relacionados con un cambio reciente que no se reflej\u00f3 en la gesti\u00f3n RPKI.<\/p>\n\n\n\n Si el ROA es incorrecto, actual\u00edzalo a trav\u00e9s del Registro Regional de Internet correspondiente, el LIR patrocinador o el sistema de gesti\u00f3n RPKI. Si la notificaci\u00f3n BGP es incorrecta, corrige la pol\u00edtica de ruta en su lugar. No resuelvas un error de enrutamiento publicando un ROA innecesariamente amplio, ya que esto podr\u00eda autorizar notificaciones que nunca se pretendieron.<\/p>\n\n\n\n Tras realizar la correcci\u00f3n, d\u00e9 tiempo para que el repositorio y el validador se actualicen. Compruebe los resultados nuevamente utilizando un servicio de validaci\u00f3n externa y una fuente de monitoreo BGP. La ruta debe volver a ser \"V\u00e1lida\" cuando el origen y la longitud del prefijo coincidan con la autorizaci\u00f3n publicada.<\/p>\n\n\n\n La validaci\u00f3n RPKI no retira autom\u00e1ticamente una ruta de Internet. La red receptora decide c\u00f3mo utilizar los resultados en su pol\u00edtica de enrutamiento. Algunos operadores rechazan las rutas inv\u00e1lidas, mientras que otros las marcan con una menor preferencia, generan alertas o contin\u00faan acept\u00e1ndolas bajo condiciones espec\u00edficas.<\/p>\n\n\n\n Una ruta v\u00e1lida puede recibir un tratamiento normal, pero a\u00fan compite con otras rutas seg\u00fan la preferencia local, la longitud del camino, las reglas de ingenier\u00eda de tr\u00e1fico y la pol\u00edtica del proveedor. Una ruta no encontrada puede ser aceptada por una red y tratada con m\u00e1s cuidado por otra. Una ruta inv\u00e1lida puede permanecer visible a trav\u00e9s de algunos proveedores mientras que se vuelve inalcanzable a trav\u00e9s de redes que aplican filtros estrictos.<\/p>\n\n\n\n Esta diferencia explica por qu\u00e9 una notificaci\u00f3n no v\u00e1lida puede causar conectividad parcial. Un servicio puede funcionar desde una regi\u00f3n pero fallar desde otra, ya que diferentes redes aplican pol\u00edticas diferentes. Al diagnosticar un corte, es \u00fatil por lo tanto comparar el estado de validaci\u00f3n con la visibilidad BGP desde m\u00faltiples ubicaciones.<\/p>\n\n\n\n RPKI debe considerarse como una entrada para la pol\u00edtica 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.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n Operaciones IPv4 suelen implicar prefijos relativamente peque\u00f1os, transferencias, acuerdos de arrendamiento y m\u00faltiples proveedores. Un cambio en el ASN de origen o el uso de anuncios m\u00e1s espec\u00edficos puede afectar r\u00e1pidamente el resultado de validaci\u00f3n. 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\u00f3n.<\/p>\n\n\n\n Las redes IPv6 suelen recibir asignaciones m\u00e1s grandes y pueden anunciar un agregado mientras utilizan subredes internas m\u00e1s peque\u00f1as. La ROA p\u00fablica debe coincidir con los prefijos que se anuncian realmente a Internet. Si un operador IPv6 autoriza solo un agregado pero luego anuncia rutas m\u00e1s espec\u00edficas, esas rutas pueden volverse Inv\u00e1lidas a menos que la longitud m\u00e1xima lo permita.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n Antes de cambiar un ASN, proveedor de upstream, plan de agregaci\u00f3n de rutas o titular de recursos de direcci\u00f3n, registre el estado actual de RPKI. Confirme qu\u00e9 ASN origina actualmente el prefijo y si la notificaci\u00f3n es V\u00e1lida, Inv\u00e1lida o No encontrada.<\/p>\n\n\n\n Tras preparar el nuevo dise\u00f1o de enrutamiento, compara las longitudes de origen y prefijo esperadas con los ROAs planeados. Si el origen cambiar\u00e1, publique o actualice la autorizaci\u00f3n antes de anunciar la nueva ruta siempre que el horario operativo lo permita. Durante una migraci\u00f3n controlada, puede ser adecuado autorizaci\u00f3n temporal para ambos or\u00edgenes, pero el acuerdo debe documentarse y la antigua autorizaci\u00f3n eliminarse cuando la transici\u00f3n est\u00e9 completa.<\/p>\n\n\n\n\u00bfQu\u00e9 es la validaci\u00f3n RPKI?<\/h2>\n\n\n\n
\u00bfQu\u00e9 Significa RPKI V\u00e1lido?<\/h2>\n\n\n\n
203.0.113.0\/24<\/code> y publica un ROA autorizando AS64500<\/code> origenar eso \/24<\/code>. Si la empresa anuncia 203.0.113.0\/24<\/code> desde AS64500<\/code>, la notificaci\u00f3n debe devolver V\u00e1lida. Lo mismo es cierto para un ejemplo de IPv6 como 2001:db8:1200::\/48<\/code> cuando se utilizan el ASN correcto y la longitud de prefijo permitida.<\/p>\n\n\n\n\u00bfQu\u00e9 significa RPKI Inv\u00e1lido?<\/h2>\n\n\n\n
AS64500<\/code> originar 198.51.100.0\/24<\/code>. Si AS64510<\/code> anuncia que ese mismo prefijo, el ASN de origen no coincide y la ruta se convierte en Inv\u00e1lida. El resultado tambi\u00e9n puede ocurrir cuando AS64500<\/code> est\u00e1 autorizado para el \/24<\/code> pero anuncia 198.51.100.0\/25<\/code> mientras que la ROA no permite prefijos que espec\u00edficos.<\/p>\n\n\n\n\u00bfQu\u00e9 significa que RPKI no se haya encontrado?<\/h2>\n\n\n\n
La diferencia entre inv\u00e1lido y no encontrado<\/h2>\n\n\n\n
AS64500<\/code> para 192.0.2.0\/24<\/code>, pero AS64510<\/code> anuncia el prefijo. La ruta es inv\u00e1lida porque el origen entra en conflicto con la autorizaci\u00f3n. En el segundo, la empresa no ha publicado ning\u00fan ROA, y AS64500<\/code> anuncia el prefijo. La ruta no se encuentra porque no hay autorizaci\u00f3n para evaluar.<\/p>\n\n\n\n\u00bfPor qu\u00e9 una ruta leg\u00edtima puede volverse inv\u00e1lida?<\/h2>\n\n\n\n
\/20<\/code>, publicar un ROA con una longitud m\u00e1xima de \/20<\/code>, y m\u00e1s tarde anunciar dos \/21<\/code> rutas para ingenier\u00eda de tr\u00e1fico. Esas notificaciones m\u00e1s espec\u00edficas pueden no estar cubiertas por la autorizaci\u00f3n original. La configuraci\u00f3n BGP puede ser intencional, pero la pol\u00edtica RPKI es demasiado restrictiva para el nuevo dise\u00f1o.<\/p>\n\n\n\nC\u00f3mo solucionar un resultado inv\u00e1lido de RPKI<\/h2>\n\n\n\n
C\u00f3mo afectan los resultados de RPKI a la ruta BGP<\/h2>\n\n\n\n
RPKI Validation for IPv4 and IPv6<\/h2>\n\n\n\n
C\u00f3mo comprobar el estado de RPKI antes de un cambio de red<\/h2>\n\n\n\n