RPKI para principiantes: cómo proteger sus bloques IP del secuestro BGP

Un sistema autónomo al otro lado del mundo anuncia sin más su subred como propia y, según lo lejos que se propague ese anuncio, su tráfico se redirige hacia él. Estos sucesos se conocen como secuestros BGP (BGP hijacking) y fugas de rutas (route leaks), y RPKI es el sistema que el sector creó para frenarlos. La mayoría ni siquiera son ataques: la causa más habitual es un error involuntario, una red que anuncia una subred que en realidad no le pertenece.

No es algo teórico. Los secuestros BGP han interrumpido gravemente YouTube a escala mundial durante unas dos horas, han desviado el tráfico DNS de Amazon para redirigir a los usuarios a un sitio de phishing que vació monederos de criptomonedas y han provocado caídas importantes en infraestructuras cloud. La superficie de ataque es la propia infraestructura de enrutamiento de internet, y el modelo de confianza por defecto con el que funciona BGP desde 1989 no ofrece ninguna protección criptográfica frente a ello.

RPKI (Resource Public Key Infrastructure) se puede desplegar en la región RIPE desde 2011, su adopción entre las grandes redes se ha acelerado notablemente desde 2020 y crear su primera ROA lleva menos de diez minutos una vez que entiende lo que está haciendo. Si es titular de bloques IP, o los compra, vende o arrienda, RPKI influye ya directamente en si sus direcciones se enrutan, en cuánto confían en ellas otras redes y en cuánto valen.

Esta guía explica qué es RPKI en términos sencillos, cómo funciona el secuestro BGP, cómo crear una Route Origin Authorization para su subred, cómo validar las rutas que recibe y qué cambia cuando el espacio IP con el que trabaja es arrendado y no propio. A lo largo del texto hablamos de titulares de IP (holders) y de clientes o arrendatarios de IP (tenants): las dos partes de todo arrendamiento.

¿Qué es RPKI?

RPKI son las siglas de Resource Public Key Infrastructure (infraestructura de clave pública de recursos). Es un marco criptográfico que permite a los titulares de IP demostrar (de forma verificable, no por mera afirmación) que un sistema autónomo concreto está autorizado a originar una subred concreta en BGP.

Funciona como una cadena de confianza. La IANA, la autoridad máxima de todas las direcciones IP, delega bloques en los cinco registros regionales de internet: ARIN, RIPE NCC, APNIC, LACNIC y AFRINIC. Después, cada RIR emite un certificado digital al titular de cada bloque. Ese certificado es la prueba criptográfica de la titularidad. No se puede falsificar y cualquiera en internet puede comprobarlo.

Piense en un registro de la propiedad. El registro no impide físicamente que alguien afirme ser dueño de una casa, pero permite que cualquier interesado consulte el registro oficial y vea quién es el verdadero propietario. RPKI hace lo mismo con los bloques IP.

¿Qué es una ROA (Route Origin Authorization)?

El certificado por sí solo no hace gran cosa. Lo útil es lo que el titular de IP crea con él: una Route Origin Authorization, o ROA. Dicho de forma sencilla, una ROA establece: «esta subred puede anunciarla esta red, hasta este tamaño».

Registra tres datos:

• la subred que se protege (a veces llamada «prefijo»),

• el ASN autorizado a anunciarla, y

• la longitud máxima de prefijo: el subbloque más pequeño y específico que ese ASN puede anunciar.

La ROA se firma con una cadena de claves que se remonta al registro regional de internet (el RIPE NCC en el caso de los titulares de IP de Europa y Oriente Medio), que actúa como ancla de confianza criptográfica. Una vez publicada, la ROA es visible para todos: cualquier operador puede descargarla y utilizarla para decidir si confía en una ruta. Para el lector que busque precisión técnica, el formato actual de ROA está definido en la RFC 9582, publicada en 2024.

Estados de validación RPKI: Valid, Invalid, NotFound

Cuando un router recibe un anuncio de ruta BGP, la validación RPKI lo coteja con las ROA publicadas. El resultado es uno de tres estados.

La consecuencia práctica es tajante: un resultado Invalid hace que todas las redes que aplican RPKI descarten su tráfico. Una ROA incorrecta es peor que no tener ninguna.

Cómo usan RPKI los routers: validadores y ROV

Los routers no realizan por sí mismos el trabajo criptográfico pesado. El operador ejecuta un software llamado validador (también denominado software de «relying party»). El validador descarga todas las ROA de los cinco RIR, comprueba todas las firmas y elabora una lista limpia y verificada.

A continuación, el router se conecta al validador mediante un protocolo sencillo llamado RTR (RPKI-to-Router) y obtiene esa lista verificada. A partir de ese momento, puede etiquetar cada ruta entrante como Valid, Invalid o NotFound y actuar en consecuencia. Este proceso de cotejar las rutas con las ROA se denomina Route Origin Validation, o ROV.

Así pues, RPKI tiene dos mitades, y ambas deben producirse:

1. Los titulares de IP firman sus subredes creando ROA.

2. Los operadores de red validan las rutas entrantes con ROV.

Una ROA solo le protege si otras redes validan. La validación solo sirve si los titulares de IP han creado ROA. El sistema se refuerza a medida que participan más actores.

RPKI protege específicamente contra el secuestro del origen de la ruta: que un atacante origine falsamente su subred desde un ASN no autorizado. No protege contra las fugas de rutas, en las que un ASN legítimo redistribuye rutas que no debería. Al final de esta guía volvemos sobre lo que se está desarrollando para ese problema.

Cómo funciona el secuestro BGP

BGP (Border Gateway Protocol) es el protocolo de enrutamiento que conecta los sistemas autónomos en internet. Cada sistema autónomo opera con un ASN, y BGP es la forma en que esas redes intercambian información sobre qué subredes pueden alcanzar y por qué rutas.

La premisa de diseño de BGP es que las redes participantes dicen la verdad. No existe ningún mecanismo criptográfico integrado para verificar que el ASN que anuncia una subred está realmente autorizado a hacerlo. Cuando AS64496 anuncia que puede alcanzar 203.0.113.0/24, los routers de internet no tienen una forma intrínseca de comprobar si AS64496 es realmente el titular de ese espacio de direcciones.

El secuestro BGP explota esta laguna. Un sistema autónomo malicioso (o mal configurado) anuncia una subred que no le pertenece. Si el anuncio se propaga y los routers posteriores lo aceptan, el tráfico destinado a esa subred se redirige al secuestrador.

Hay dos variantes habituales:

Secuestro de prefijo exacto. El atacante anuncia la misma subred que el titular legítimo, por ejemplo 203.0.113.0/24. La selección de ruta BGP depende entonces de la longitud del AS path y de las políticas de enrutamiento locales. El ataque puede imponerse o no al anuncio legítimo según la topología de la red.

Secuestro de prefijo más específico. El atacante anuncia un prefijo más específico (203.0.113.0/25) derivado del bloque de la víctima. Como BGP siempre prefiere las rutas más específicas, esta variante es más fiable desde el punto de vista del atacante. El tráfico del /25 secuestrado se dirigirá al atacante allí donde se acepte el anuncio más específico.

Las consecuencias varían. En algunos casos, el secuestrador simplemente descarta el tráfico (blackholing), lo que provoca una caída del servicio para la víctima. En ataques más dirigidos, el tráfico se intercepta, se inspecciona o modifica y se reenvía, de modo que el secuestro resulta invisible para los usuarios finales mientras permite la vigilancia pasiva o la manipulación activa en tránsito.

Las configuraciones erróneas explican una parte significativa de los incidentes de secuestro BGP. Un ingeniero de red comete un error en un anuncio de ruta, y desde fuera el resultado es idéntico a un ataque intencionado. El impacto es el mismo, haya o no intención.

El incidente de Pakistan Telecom en 2008 (en el que un anuncio erróneo de un /24 más específico del /22 de YouTube se propagó a escala mundial a través de PCCW e interrumpió gravemente el acceso a YouTube durante unas dos horas) es el ejemplo más citado. El ataque de 2018 contra el servicio DNS Amazon Route 53, que secuestró las consultas DNS de myetherwallet.com y redirigió a los usuarios a un sitio de phishing controlado por el atacante que sustrajo unos $150,000 en Ethereum a quienes iniciaron sesión, es uno más deliberado. Ninguno de los dos habría tenido éxito contra una subred correctamente validada con RPKI y con el descarte de rutas Invalid activado.

Por qué RPKI importa en 2026

Durante años, RPKI fue opcional y apenas se utilizaba. Eso ha cambiado.

Desde mayo de 2024, todos los grandes proveedores tier-1 (transit-free) de internet salvo uno rechazan las rutas RPKI Invalid, un hito confirmado por MANRS y por el RPKI Monitor del NIST. Con ese nivel de aplicación, la propagación de un anuncio RPKI Invalid se reduce entre la mitad y dos tercios en comparación con una ruta sin cobertura RPKI.

En cuanto a la firma, el NIST RPKI Monitor sitúa la cobertura de ROA de la tabla de enrutamiento global en aproximadamente el 54% de las subredes IPv4 e IPv6, Kentik estima que alrededor del 74% del tráfico de internet se dirige ya a destinos cubiertos y APNIC situó la cobertura media mundial en torno al 60% en APRICOT 2026.

La aplicación sigue concentrada en los grandes operadores, y la adopción en las redes tier-2 y regionales sigue siendo desigual. Pero la tendencia es clara, y tiene tres consecuencias para cualquiera que trabaje con bloques IP:

Cada vez más proveedores exigen ROA. Un número creciente de proveedores upstream y puntos de intercambio de internet no aceptarán sus anuncios (y, cada vez más, no harán negocios con usted) a menos que sus subredes estén correctamente firmadas.

La nube lo exige. Si lleva su propio bloque IP a AWS, Google Cloud o Azure, es obligatoria una ROA correcta que autorice el ASN del proveedor cloud. Sin ROA, no hay servicio.

Influye en lo que vale una subred. Un bloque con registros RPKI limpios y correctos se despliega más rápido y genera más confianza. Para los titulares de IP que quieren monetizar espacio IPv4 sin usar, y para los compradores que hacen due diligence antes de comprar bloques IPv4, el estado RPKI figura ya junto al historial de abusos y la reputación como comprobación estándar.

Cómo configurar RPKI: para titulares de IP

Antes de empezar, puede elegir entre dos modelos:

RPKI alojado (hosted): su RIR gestiona el sistema criptográfico por usted, y usted crea las ROA iniciando sesión en su portal (el portal del RIPE NCC, ARIN Online, MyAPNIC, etc.). Es la opción adecuada para casi todo el mundo.

RPKI delegado: usted gestiona su propia autoridad de certificación, por ejemplo con un software llamado Krill. Solo conviene a grandes operadores que necesitan un alto grado de automatización.

El procedimiento que sigue corresponde a RPKI alojado en la región RIPE. Necesita ser miembro activo del RIPE NCC (estatus de LIR), y la subred debe estar registrada bajo su certificado de recursos en la base de datos de RIPE.

1. Inicie sesión en el portal del RIPE NCC. Vaya a my.ripe.net e inicie sesión con sus credenciales de LIR. Acceda a la sección RPKI de su panel.

2. Localice su certificado de recursos. En él figuran los bloques IP asignados a su organización. Confirme que aparece la subred que quiere proteger antes de continuar.

3. Cree la ROA. Seleccione la subred, introduzca el ASN que la anunciará y establezca la longitud máxima de prefijo.

4. Establezca la longitud máxima con cuidado. Es el parámetro más trascendental, y de él proceden casi todas las caídas autoinfligidas en RPKI. La regla: ajústela exactamente a sus anuncios reales, sin holgura. Si la fija demasiado estricta, sus propios anuncios más específicos pasarán a Invalid. Si la fija demasiado amplia, deja un hueco que un atacante puede aprovechar: un subbloque más específico que sigue superando la validación. Ambos fallos se explican en la siguiente sección.

5. Publique y verifique. En el RIPE NCC, las ROA suelen llegar a los relying parties entre 15 y 30 minutos después de su publicación en condiciones normales. Los efectos en el plano de datos se producen aproximadamente en el mismo plazo; algunas implementaciones de validadores pueden tardar más. Confirme que la ROA aparece como Valid en bgp.tools antes de dar la configuración por terminada.

Para un recorrido detallado con capturas de pantalla e indicaciones campo por campo, consulte nuestra guía de creación de ROA en el Centro de ayuda →

Errores habituales

Longitud máxima demasiado estricta: fijarla en el bloque completo cuando anuncia subbloques. Si es titular de un /22 y piensa anunciarlo como cuatro /24, la longitud máxima de su ROA debe ser /24, no /22. Una ROA que cubre un /22 con longitud máxima /22 marcará como Invalid cualquier subanuncio /24, incluso desde su propio ASN. El resultado es que el titular de IP invalida por accidente sus propias rutas.

Longitud máxima demasiado amplia: fijarla por encima de lo que realmente anuncia. Es la imagen especular, e igual de dañina. Si es titular de un /22, lo anuncia como un único /22 y fija la longitud máxima en /24 «por si acaso», ha autorizado a un atacante a anunciar un /24 de su bloque, y ese anuncio se validará como Valid. Cada bit de margen en el campo de longitud máxima es margen que se le regala a un secuestrador.

Fijar la longitud máxima en /32 (o /128 en IPv6) como comodín. Es la versión extrema del mismo error. Autoriza cualquier anuncio más específico hasta una única dirección de host, justo el tipo de secuestro que RPKI está diseñado para evitar.

Crear una ROA y no verificar su propagación. Una ROA que existe en el portal del RIPE NCC pero no se ha propagado a los relying parties no ofrece ninguna protección. Valide siempre con una herramienta externa tras crearla, no solo con la confirmación del propio portal.

Usar una sola ROA para una subred anunciada desde varios ASN. Si su subred se va a anunciar desde más de un ASN (por redundancia, por BYOIP en un proveedor cloud o en configuraciones multihoming), necesita una ROA distinta para cada ASN autorizado. Una ROA cubre exactamente una combinación de subred y ASN.

Olvidar actualizar las ROA cuando cambia el ASN que anuncia. Si cambia de proveedor upstream, migra a un nuevo ASN o se incorpora al programa BYOIP de un proveedor cloud, la ROA debe actualizarse antes de que el nuevo anuncio entre en funcionamiento. Un anuncio Invalid desde su propia infraestructura es una caída del servicio.

Dejar que una ROA caduque sin darse cuenta. Automatice las renovaciones siempre que su RIR lo permita. Una ROA caducada no falla con elegancia: cambia el estado de su enrutamiento sin que nadie toque un router.

RPKI cuando arrienda IPv4: ¿quién crea la ROA?

Aquí es donde más se confunde la gente, así que conviene ser preciso.

Solo el titular de IP (la parte que el RIR reconoce como titular del bloque) puede crear o modificar una ROA. El cliente que arrienda las IP no puede. Las ROA las crea el titular del recurso, no quien esté utilizando o anunciando el espacio en ese momento. Por eso, cuando se arrienda una subred, la ROA debe crearse autorizando el ASN de origen del cliente, porque es el cliente quien realmente anunciará el bloque.

Una plataforma de arrendamiento o un bróker fiable gestiona esta coordinación como parte del arrendamiento, junto con la LOA y el objeto route. Si arrienda direcciones IPv4 y se le deja todo esto para que lo resuelva por su cuenta, considérelo una señal de alarma.

En IPbnb, la coordinación de la ROA forma parte de cada arrendamiento: el titular publica la ROA para el ASN del cliente antes de entregar el bloque, junto con la LOA y el objeto route. No sustituye a sus propias comprobaciones (debe seguir confirmando el estado de la ROA en bgp.tools antes de anunciar), pero elimina las conjeturas.

Un matiz: si el titular de IP anuncia en su nombre (algo habitual en el arrendamiento alojado o gestionado), la ROA cubrirá el ASN del titular y usted no necesita gestionarla directamente. Confirme que es así antes de darlo por hecho.

El BYOIP en proveedores cloud añade otra capa. AWS, GCP y Azure tienen sus propios requisitos de RPKI y LOA durante la incorporación. Los fallos de validación de la subred, incluido el estado RPKI Invalid, pueden bloquear o retrasar considerablemente la aceptación por parte del proveedor cloud.

Cómo configurar RPKI: para operadores de red

Firmar sus propias subredes solo las protege en la medida en que otras redes comprueban. Si utiliza BGP (lo que incluye a la mayoría de los clientes que anuncian sus propios bloques arrendados), también debería validar.

Cómo elegir un validador RPKI

A continuación:

Instale al menos dos validadores. Si un router pierde el contacto con todos sus validadores, todas las rutas pasan silenciosamente a NotFound y el filtrado se detiene. Un segundo validador le protege frente a ello.

Acepte el ancla de confianza de cada RIR. La de ARIN exige aceptar su Relying Party Agreement, un paso independiente de los demás.

Conecte sus routers a los validadores mediante RTR y configure la política para rechazar Invalid y aceptar Valid y NotFound. No rechace NotFound: una gran parte de las subredes sigue sin firmar, y descartarlas le dejaría sin acceso a buena parte de internet.

Trate RPKI como una capa, no como toda la defensa. RPKI comprueba quién origina una ruta, no el recorrido completo que sigue. Combínelo con filtros de prefijos, filtros de AS path y filtrado de bogons.

Herramientas para supervisar BGP

Crear una ROA es el primer paso. La supervisión continua es lo que le indica si su subred se está anunciando correctamente, si han aparecido anuncios no autorizados y si su configuración RPKI funciona como se espera.

RIPEstat (stat.ripe.net): la herramienta gratuita más completa para los operadores de la región RIPE. Datos de enrutamiento BGP, anuncios, información de AS path y estado RPKI de cualquier subred. La vista del historial de enrutamiento resulta especialmente útil para detectar anuncios anómalos que aparecieron y desaparecieron, que es como suelen manifestarse los incidentes de secuestro. No requiere cuenta.

bgp.tools: limpia y rápida, para la visibilidad de subredes, información de AS y datos de enrutamiento. La forma más rápida de comprobar qué ASN anuncian una subred determinada y desde dónde, y de confirmar que una nueva ROA aparece como Valid.

Cloudflare RPKI Validator (rpki.cloudflare.com): muestra el estado actual de la ROA de cualquier subred, junto con las ROA que la cubren y las anclas de confianza de las que proceden. Útil antes de arrendar o adquirir un bloque. Su herramienta complementaria, isbgpsafeyet.com, le indica si sus propios upstreams descartan realmente las rutas Invalid.

Cloudflare Radar (radar.cloudflare.com): supervisión más amplia de BGP y del estado de internet, con estadísticas de despliegue de RPKI y detección de anomalías de enrutamiento. Menos útil subred a subred, más útil para la visión de conjunto.

NIST RPKI Monitor: la fuente de referencia para las estadísticas mundiales de cobertura y aplicación de RPKI, y una comprobación rápida de dónde se sitúan sus subredes respecto al resto de la tabla.

Alertas tipo BGPalerter y BGPmon: supervisión en tiempo real que le avisa cuando una subred que sigue empieza a anunciarse desde un nuevo ASN, o cuando sus anuncios y sus ROA dejan de estar sincronizados. En entornos de producción, las herramientas pasivas no bastan; necesita alertas que detecten las anomalías en minutos, no cuando ya ha notado una interrupción del servicio.

La configuración mínima viable: RIPEstat para la visibilidad básica y el historial, bgp.tools para confirmar el estado de la ROA tras cualquier cambio y al menos un mecanismo de alertas para anuncios inesperados.

RPKI frente a filtrado IRR

IRR (Internet Routing Registry) es el sistema más antiguo. Las redes registran objetos route en bases de datos IRR (el IRR de RIPE, RADB, el IRR de ARIN y otras) que describen qué ASN está autorizado a anunciar cada subred. Los proveedores upstream y los peers utilizan esos objetos route para construir filtros de prefijos y aceptar solo los anuncios que coinciden con los objetos registrados.

La debilidad estructural del IRR es que no está protegido criptográficamente. Cualquiera puede registrar un objeto route para una subred que no le pertenece, y las bases de datos IRR han contenido históricamente gran cantidad de datos obsoletos, inexactos o fraudulentos. El filtrado que ofrece depende por completo de la exactitud de unos datos de registro mantenidos mediante autodeclaración voluntaria.

RPKI está protegido criptográficamente. Las ROA las firma el titular del recurso con claves que se remontan al RIR, y una ROA solo puede crearla quien posee el certificado de recursos correspondiente. Eso hace que RPKI sea mucho más fiable que el IRR como fuente de datos de autorización de enrutamiento.

La relación es complementaria, no competitiva. Muchas redes utilizan ambos: objetos route del IRR por compatibilidad con implementaciones de filtrado más antiguas y ROA de RPKI para la validación criptográfica allí donde se aplica. Mantener ambos no es redundante: sirven a partes distintas del ecosistema de filtrado.

Para los operadores de la región RIPE, la recomendación práctica es crear primero las ROA de RPKI y mantener en paralelo los objetos route del IRR para las redes que filtran por IRR pero aún no han desplegado ROV por completo. Si hereda una subred (mediante arrendamiento, adquisición o transferencia), compruebe tanto su estado RPKI como sus registros IRR como parte de la due diligence. Una incoherencia entre ellos (por ejemplo, una ROA válida pero un objeto route del IRR obsoleto que apunta a un ASN anterior) provoca problemas de enrutamiento difíciles de diagnosticar.

Lo que viene: ASPA

RPKI valida el origen de una ruta, no el recorrido completo que sigue. Eso deja abierta la brecha de las fugas de rutas: el origen es correcto, pero el tráfico pasa por redes por las que no debería.

La respuesta emergente es ASPA (Autonomous System Provider Authorization), un nuevo objeto RPKI en el que una red firma una declaración con la lista de sus proveedores upstream autorizados.

Una aclaración realista, porque aquí la precisión importa: en 2026, ASPA aún se está ultimando en el IETF, todavía no es un estándar publicado y su uso real sigue siendo muy reducido. BGPsec, la respuesta anterior al mismo problema, tampoco tiene despliegue en producción. Conviene seguir de cerca ASPA, pero no desplegarlo. Por ahora, lo que protege sus subredes son unas ROA correctas y una validación activa.

Lista de comprobación RPKI para titulares de IP

1. Confirme que todas las subredes de su titularidad aparecen bajo su certificado de recursos en el portal de su RIR.

2. Cree una ROA para cada subred, con RPKI alojado salvo que tenga un motivo concreto para no hacerlo.

3. Ajuste la longitud máxima exactamente a sus anuncios reales: nunca más amplia, nunca más estricta.

4. Cree una ROA distinta para cada ASN autorizado a anunciar la subred (redundancia, multihoming, BYOIP).

5. Verifique la propagación externamente en bgp.tools o RIPEstat, no solo en el portal de su RIR.

6. Mantenga el objeto route del IRR coherente con la ROA.

7. Configure alertas (BGPalerter o equivalente) para anuncios desde ASN inesperados y para desviaciones de la ROA.

8. Automatice las renovaciones y actualice las ROA antes de cualquier cambio de ASN, no después.

Conclusión

La eficacia de RPKI es proporcional a su grado de despliegue. Cada titular de IP que crea ROA y cada red que descarta las rutas Invalid hacen el sistema más robusto para todos los demás.

Ha pasado de ser «deseable» a «lo esperado». Para los titulares de IP, una ROA correcta protege sus subredes de secuestros y las mantiene fiables y valiosas. Para los clientes, confirmar que un bloque arrendado está correctamente firmado marca la diferencia entre direcciones que se enrutan sin problemas y direcciones que se descartan. Configurarlo lleva minutos. El cuidado debe ponerse en un detalle: acertar con la longitud máxima de prefijo.

Si es titular de bloques IP o los arrienda y no está seguro de que sus registros RPKI sean correctos, eso es lo primero que debe comprobar. Cada vez más, el resto de internet ya lo está comprobando por usted.

Preguntas frecuentes

¿Qué es RPKI, explicado de forma sencilla?

RPKI (Resource Public Key Infrastructure) es una forma de demostrar criptográficamente quién puede anunciar un bloque IP determinado en internet. Cada registro regional de internet emite un certificado digital al titular de un bloque, y el titular lo utiliza para firmar declaraciones sobre quién puede enrutar ese espacio. Piense en ello como un registro de la propiedad para direcciones IP: no impide físicamente una reclamación falsa, pero permite que cualquiera consulte el registro oficial.

¿Qué es una ROA (Route Origin Authorization)?

Una ROA es una breve declaración firmada digitalmente que crea el titular de IP. Registra tres datos: la subred, el ASN autorizado a anunciarla y la longitud máxima de prefijo que ese ASN puede anunciar. Una vez publicada, cualquier red puede descargarla y utilizarla para decidir si confía en una ruta.

¿Puede un cliente crear una ROA para una subred arrendada?

No. Solo el titular de IP (la parte que el RIR reconoce como titular del bloque) puede crear o modificar una ROA. En un arrendamiento, el titular debe publicar una ROA que autorice el ASN de origen del cliente antes de que este empiece a anunciar. Si cambia el ASN del cliente o finaliza el arrendamiento, el titular la actualiza o la elimina.

¿Qué ocurre si una ruta es RPKI Invalid?

Todas las redes que aplican RPKI rechazan una ruta Invalid, incluidos todos los proveedores de tránsito tier-1 de internet salvo uno. En la práctica, eso significa que su tráfico se descarta. Invalid suele indicar un secuestro o, con más frecuencia, una configuración errónea, normalmente una longitud máxima que no coincide con lo que realmente anuncia. Una ROA incorrecta es peor que no tener ninguna.

¿Exigen AWS, Google Cloud y Azure RPKI para BYOIP?

Sí. Los tres exigen una ROA correcta que autorice el ASN del proveedor cloud como parte de la incorporación a BYOIP, junto con una carta de autorización (LOA). Una subred con estado RPKI Invalid será rechazada o sufrirá retrasos considerables. Si arrienda el espacio, el titular de IP debe crear la ROA antes de que usted inicie el proceso de incorporación.