En los últimos años la adopción de RPKI ha crecido a nivel global, tanto por parte de los usuarios que firman sus recursos y generan sus ROA 1 2 , como por parte de las organizaciones que realizan validación de origen para los anuncios BGP. Un mayor número de implementaciones de software de validación RPKI surgieron en el último año. A su vez, hay propuestas en la IETF que presentan posibles extensiones a las funcionalidades básicas de RPKI. Todos estos son síntomas de la aceptación que RPKI está teniendo en los operadores para garantizar la seguridad del ruteo a nivel global.

Recientemente, grandes operadores como NTT o AT&T y proveedores importantes de contenido como Cloudflare han comenzado a descartar los anuncios BGP inválidos con respecto a la información de RPKI. Esta misma situación se extiende en la mayoría de los IXPs a nivel mundial. Es de vital importancia entonces verificar que la información definida en RPKI por parte de cada organización es la correcta: en caso de tener ROA mal creados, es posible que ciertos prefijos queden descartados, con lo cual no se podría llegar a las redes que están realizando validación, perdiendo eventualmente la conectividad con operadores importantes.

Esta situación ha sido advertida y explicada en la lista de correo de LACNOG (https://mail.lacnic.net/pipermail/lacnog/2018-September/006484.html) y en este sitio web: https://nusenu.github.io/RPKI-Observatory/index.html

Se describe a continuación en mayor nivel de detalle esta problemática.

¿Que son los ROA?

Los ROA (Route Origin Attestations) son objetos firmados digitalmente que describen una asociación entre un conjunto de prefijos (IPv4 o IPv6) y el sistema autónomo autorizado a originar esos prefijos en anuncios BGP. Adicionalmente, los ROA definen la longitud máxima con la que esos prefijos se pueden anunciar.

De esta forma, es posible contrastar la información que se recibe por BGP con las definiciones contenidas en los ROA de RPKI: al recibir un anuncio de un prefijo por BGP se puede chequear el sistema autónomo que origina el anuncio y la longitud del prefijo con lo declarado en RPKI. Si esta información coincide, el anuncio BGP será considerado válido; si no coincide –ya sea por originarse en un sistema autónomo distinto o por violar la longitud máxima de prefijo declarada– el anuncio BGP será considerado inválido; se agrega un tercer estado en caso de que el anuncio no esté cubierto por ningún ROA, es decir, no exista información en la RPKI: en este caso, el estado es denominado “unknown” o “not found”.

Para más información ver RFC 6482 y 6483.

¿Por qué es importante desplegar RPKI?

La base del ruteo en Internet es el protocolo BGP, el cual no incorpora mecanismos para verificar el derecho de uso de los recursos IP por parte de una organización. Para poder verificar que la información que se recibe por BGP es legítima se han utilizado distintas técnicas a lo largo del tiempo, desde las LoA (letter of authorization) hasta los IRRs (Internet Routing Registries) para declarar el conjunto de prefijos que un sistema autónomo va a anunciar a otro. RPKI es el método más reciente que se ha especificado como estándar en la IETF para poder verificar la información que se publica en BGP (ver RFC 6480 y siguientes).

Mediante el uso de RPKI las organizaciones pueden certificar sus recursos y sus anuncios de BGP, protegiéndose de un uso inadecuado o del secuestro de rutas (hijacking).

¿Qué es la validación de origen?

La validación de origen consiste en verificar cuál es el sistema autónomo autorizado a originar un anuncio de un prefijo en BGP. Mediante esta verificación es posible prevenir los anuncios no autorizados, descartando aquellas rutas originadas en sistemas autónomos diferentes a los autorizados. Para realizar validación de origen es necesario contar con una fuente externa de información, ya que BGP no tiene mecanismos embebidos en el protocolo para ello. Una de las formas más extendidas de realizar validación de origen es contrastar los anuncios recibidos con la información disponible en la base de datos de RPKI (repositorios RPKI, detallado en RFC 6481).

¿Qué es un ROA incorrecto?

Un ROA incorrecto es aquel que no cubra adecuadamente las publicaciones que una organización hace por BGP:

  • Un ROA que declara un sistema autónomo de origen distinto al sistema autónomo que publica el prefijo en BGP.

  • Un ROA que especifica una longitud máxima de prefijo más corta que la del anuncio por BGP (la ruta en BGP es más específica que la longitud máxima declarada en el ROA)..

En ambos casos, los prefijos anunciados que no se corresponden con el ROA podrán ser descartados por organizaciones que realizan validación de origen. Esto puede ocasionar problemas de conectividad en caso de no tener ninguna otra ruta que cubra esos prefijos.

Un ROA incorrecto puede haberse generado debido a un error de configuración o por desactualización de la información creada en el repositorio (ej: al cambiar de proveedor, cambiar de sistema autónomo, desagregación incorrecta, etc). Por esta razón es de suma importancia verificar que los ROA declarados en el sistema MiLACNIC se corresponden con las publicaciones BGP que se desea realizar.

¿Dónde verificar mi información?

En el sistema MiLACNIC se pueden ver los bloques IPv4 e IPv6 asignados a una organización. También en la solapa RPKI es posible verificar los ROA creados. Es importante verificar que los ROA cubren todos los prefijos que la organización está anunciando en Internet (o planea anunciar). Es conveniente también tener cubiertos todos los bloques IP con algún ROA, de manera que si un atacante pretende utilizar un prefijo de ese bloque, el anuncio por BGP sea declarado inválido.

En la página https://nusenu.github.io/RPKI-Observatory/unreachable-networks.html se pueden verificar los ROA incorrectos seleccionando por ROA, por prefijo o por sistema autónomo. En dicha página se utiliza el término “RPKI unreachable network” para denominar a aquellos prefijos cuya publicación en BGP no coincide con los ROA creados. Se puede usar este sitio para chequear que ninguno de los prefijos IP de nuestra organización esté en ese estado.

Referencias

1 Estadísticas de RIPE ↩

2 Sitio RPKI de NIST ↩