RPKI y ROA: lo que realmente tienen que hacer compradores y arrendatarios

Por qué dejó de ser opcional

Durante años, RPKI fue algo que los operadores coincidían en que era buena idea y que nunca llegaban a hacer. Eso cambió cuando las grandes redes empezaron a aplicarlo de verdad. Los principales proveedores de tránsito, las grandes plataformas cloud y varias redes de contenidos grandes hacen ya Route Origin Validation y descartan las rutas que salen inválidas.

La consecuencia práctica es tajante. Un prefijo con un ROA roto no está simplemente desprotegido: es inalcanzable desde una parte creciente de internet. Y el fallo es parcial y confuso: algunos usuarios te alcanzan, otros no, y los traceroutes parecen correctos desde donde estés probando.

Si compras o alquilas espacio de direcciones, este es el detalle de configuración que con más probabilidad te costará un día.

Qué es realmente un ROA

RPKI es un sistema de certificaciones criptográficas vinculado al registro de direcciones. El objeto que importa en el día a día es la Route Origin Authorization, o ROA, y contiene exactamente tres cosas:

• El prefijo. Por ejemplo, 192.0.2.0/24.
• El AS de origen. El número de sistema autónomo autorizado a anunciarlo.
• Una longitud máxima. El prefijo más largo que puede anunciarse dentro de ese bloque.

Ese es todo el objeto. Es una declaración firmada por el titular de las direcciones que dice «este AS puede originar este espacio, hasta este tamaño concreto». Los routers no lo leen directamente. Los validadores descargan y verifican los datos RPKI y pasan el resultado a los routers, que clasifican cada ruta como valid, invalid o not-found.

Cada ruta sale en uno de tres estados. Valid: un ROA cubre el prefijo y el anuncio coincide con él. NotFound, que muchas herramientas muestran como Unknown: ningún ROA cubre el prefijo. Invalid: un ROA cubre el prefijo, pero el anuncio lo contradice, ya sea desde el AS equivocado o con un prefijo más largo de lo que permite la longitud máxima.

El orden de esos estados importa más de lo que se cree. Una ruta sin ROA sigue aceptándose casi en todas partes: está desprotegida, pero pasa. Una ruta que sale Invalid la descartan todas las redes que aplican la validación. Ninguna ROA es mejor que un ROA errónea. El objetivo es una correcta, pero si los detalles no están cerrados el día que anuncias, anunciar sin ROA y añadirla cuando lo estén es mucho más seguro que publicar una que contradiga lo que envías.

Quién lo crea depende de cómo conseguiste el espacio

Esto confunde constantemente, así que conviene ser explícitos.

Si compraste el bloque, está inscrito a tu nombre y creas el ROA tú mismo en el portal de tu registro, o pides a tu LIR patrocinador que la cree si mantiene la relación con el registro en tu nombre. Hazlo cuando se complete la transferencia, no antes, porque el objeto tiene que crearse bajo el nuevo titular. El espacio legacy comprado en la región del RIPE NCC necesita un contrato con el RIPE NCC o con un LIR patrocinador antes de poder tener ningún ROA (el RIPE NCC).

Si alquilas, el bloque no está inscrito a tu nombre y no puedes crear el ROA. Lo hace el titular, para tu ASN. Eso significa que tienes que decirle dos cosas de entrada: el ASN desde el que anunciarás y si piensas anunciar algo más específico que el bloque entero. Un alquiler en el que no se ha creado el ROA para tu ASN saldrá inválido en el momento en que lo anuncies.

Si anuncias a través de un proveedor cloud con BYOIP, el ROA suele tener que indicar el ASN del proveedor y no el tuyo, porque es su red la que origina la ruta: AS16509 y AS14618 en AWS, AS8075 en Azure, AS396982 en Google Cloud en su nivel Premium. Algunos proveedores te permiten originar desde tu propio ASN, ya sea por una sesión BGP propia (Vultr, Cherry Servers) o como opción de «bring your own ASN» además del BYOIP (AWS, Oracle Cloud, OVHcloud, IONOS Cloud, Gcore). En ese caso un ROA indica tu ASN, y AWS y Oracle Cloud quieren también una con el suyo. La mayoría de los proveedores documentan el ASN que debe indicar el ROA, y unos pocos, entre ellos Gcore, solo lo dan si lo pides, así que compruébalo antes de crear nada; nuestras guías por proveedor los recogen.

Los dos errores que causan caídas

Casi todas las roturas reales de RPKI se deben a la longitud máxima.

Ponerla demasiado permisiva. Un ROA para 192.0.2.0/24 con una longitud máxima de /32 significa que cualquier anuncio de cualquier tamaño dentro de ese bloque es válido. Eso anula buena parte de la utilidad: un secuestrador que anuncia una ruta más específica desde tu número AS sigue saliendo válido, y en BGP ganan las rutas más específicas. Lo seguro por defecto es poner la longitud máxima igual a la longitud del prefijo, salvo que tengas un motivo concreto para no hacerlo.

Ponerla demasiado estricta. Si anuncias un /24 cubierto por un ROA y más adelante necesitas desagregarlo en dos /25 para ingeniería de tráfico, esos /25 pasan a ser inválidos al instante y desaparecen de buena parte de internet. Si piensas anunciar rutas más específicas, el ROA tiene que permitirlo antes de empezar.

La regla que evita ambos: haz que el ROA describa exactamente lo que anuncias de verdad, y actualízala en la misma ventana de cambios que cualquier cambio de enrutamiento, no después.

ASPA: la siguiente capa

Un ROA protege el primer eslabón de una ruta: quién puede originarla. No dice nada del camino que sigue, que es donde se producen las fugas de rutas, cuando una red pasa rutas que debería haberse guardado. ASPA, Autonomous System Provider Authorization, cubre parte de ese hueco.

Un objeto ASPA lo firma el titular de un número AS y enumera los AS que son sus proveedores de tránsito. Las redes que lo validan pueden rechazar un camino en el que tu AS parece llegar a internet a través de alguien que no es tu proveedor. Es un estándar emergente del IETF. El RIPE NCC lo describe como listo para firmar, y ARIN y APNIC también permiten a los titulares firmar ASPA (los registros comparados).

• Si tienes tu propio ASN, publica un ASPA con todos los proveedores de tránsito que llevan tus rutas a internet. Deja fuera a los peers y a tus propios clientes.
• Mantenlo al día. Un proveedor que falta en el objeto puede hacer que las redes que aplican ASPA rechacen tus rutas a través de ese proveedor, así que añade un tránsito nuevo antes de activarlo y quita uno antiguo después de desactivarlo.
• ¿Llevas tu propio ASN a un cloud? AWS recomienda un ASPA que incluya AS16509 y AS14618 como proveedores de tu ASN; sin ellos, las rutas que reanuncia por ti no pasan la validación ASPA.
• ¿Alquilas? El ASPA pertenece a tu ASN, no al prefijo, así que te toca publicarlo a ti, no a nosotros.

La lista de comprobación

Antes de que el espacio lleve tráfico de producción:

• Existe un ROA para el prefijo correcto y el AS de origen correcto.
• La longitud máxima coincide con tu plan real de anuncios.
• También están los objetos route del IRR. RPKI no los ha sustituido. Muchos proveedores de tránsito siguen construyendo filtros de prefijos con datos del IRR, así que un ROA válido sin un objeto route que coincida sigue haciendo que te filtren.
• El ASPA incluye todos los proveedores de tránsito, si publicas uno, y ningún peer ni cliente.
• Valida desde fuera. Comprueba desde un looking glass externo o un validador RPKI, no desde tu propia red, que aceptará encantada tus propias rutas.
• Limpia al salir. Cuando termina un alquiler o dejas de anunciar un bloque, el ROA debería retirarse o actualizarse. Un ROA obsoleto que apunta a un ASN que ya no anuncia el espacio es un problema para quien lo reciba después.

Dónde encaja RTM Networks

Creamos y mantenemos los ROA como parte tanto del alquiler como del patrocinio, no como un extra (alquilar IPv4, patrocinio de PI y ASN). En un alquiler, dinos el ASN desde el que anunciarás, o el proveedor cloud al que llevas el espacio, y si necesitas rutas más específicas, y el ROA queda configurado antes de la entrega. Para los recursos patrocinados, gestionamos la configuración RPKI junto con los demás objetos del registro.

Si te haces cargo de espacio procedente de otro sitio, quién configura RPKI depende de la vía: un comprador lo hace para el propio bloque, y en un alquiler lo hace el arrendador. Podemos comprobar si existe un ROA para el bloque y, si existe, si es válida.