RPKI: El pilar Invisible que mantiene a Internet unido

11/02/2025

Por Carlos Martínez, Gerente de Tecnología de LACNIC

Internet son millones de dispositivos que intercambian información conectados a una red, la cual resulta suficiente para enviar y recibir datos desde y hacia cualquier lado. ¿Cómo se construye y cómo se mantiene unida la Red?

A medida que nos adentramos al corazón de Internet, nos encontramos con dispositivos cuya función es básicamente reenviar paquetes de información, es decir, recibir paquetes por un lado y enviarlos por otro. ¿Cómo toma forma este proceso? Cada dispositivo que reenvía paquetes posee una tabla que indica que, si un paquete tiene cierto destino, entonces hay que sacarlo por determinada puerta de salida. Esta se trata en efecto de una de las funciones claves de Internet, lo que llamamos el forwarding.

La siguiente pregunta es, ¿cómo se llena esa tabla? Una opción es escribirla a mano (enrutamiento estático), situación que fue la norma mucho tiempo atrás, en los albores de Internet; sin embargo, en una red a gran escala el proceso se realiza automáticamente a través de protocolos de enrutamiento.

Si miramos Internet como una colección de grandes redes o de una suerte de “nubes” de equipos interconectados, el BGP (Border Gateway Protocol) es el protocolo de enrutamiento que permite que las redes o nubes hablen entre sí. El BGP es lo que le permite a cada una de las nubes decirle a la nube de al lado “yo conozco todas estas direcciones IP y te ofrezco llevar tu tráfico a estas direcciones IP” y la nube de al lado le contesta en similar sintonía. Y a su vez esas nubes o redes hablan con otras nubes con las que intercambian su propia información y la información de las otras que tienen cerca y así es que los datos se van propagando.

El BGP que usamos hoy tiene unos 30 años de existencia ¿Qué ocurre con este protocolo? Durante un montón de años, BGP funcionó sin problema, pero en algún momento a mediados de los 2000 comenzó a ser evidente que estas nubes o sistemas autónomos se referían a sus propias direcciones IP pero también a otras, las cuales desconocían. ¿Cuál es el efecto de esto? Que parte del tráfico termina yendo a un lugar donde no tiene que ir. Si tenemos en cuenta que todo el objetivo del enrutamiento es llevar los paquetes a su destino legítimo, cuando una de las nubes que participa en Internet refiere información incorrecta respecto de un IP lo que resulta es que parte del tráfico se dirige a un lugar que no es legítimo.

Los primeros casos que reflejaron esta situación fueron errores de operación, sin embargo, en 2008 tiene lugar uno de los secuestros de BGP más famosos, que involucró a la empresa estatal de telecomunicaciones de Pakistán, PTCL y YouTube. El gobierno de Pakistán ordenó que se bloqueara el acceso de los ciudadanos pakistaníes a YouTube debido a un video que consideró antiislámico. Para implementar el bloqueo, PTCL anunció rutas más específicas de las rutas BGP de YouTube para secuestrar intencionalmente el tráfico de Pakistán al servicio de streaming de video. Una vez secuestrado, el objetivo de PTCL era enviar el tráfico a un agujero negro, evitando que los pakistaníes pudieran acceder a YouTube. Pero las cosas empeoraron cuando PTCL transmitió estas rutas a sus proveedores de tránsito internacional, quienes propagaron las rutas al mundo entero, bloqueando así YouTube para una gran parte de la Internet global.

Este es un ejemplo del fenómeno conocido como “secuestro de rutas” (route hijacking), en el que un sistema autónomo anuncia que conoce cómo llegar a destinos a los que en realidad o no sabe, o no tendría la capacidad para cursar la totalidad del tráfico.

El caso de Pakistan Telecom se trató de un secuestro de rutas no intencional producto de un error en la operación de su red. Sin embargo, también existe la posibilidad de casos donde estos secuestros sean realizados con malicia.

Básicamente si alguien captura el tráfico de otro puede usufructuar ese tráfico, analizarlo, etc. Por ejemplo, en el caso de los blockchain, su funcionamiento depende de que sus nodos hablen entre sí. Existe un ataque documentado contra una blockchain que se hizo justamente realizando un secuestro de parte de las rutas de comunicación de sus nodos.

¿Cómo se protegió durante un montón de años a Internet de este tipo de cosas? Básicamente asumiendo que cada nube hacía algún chequeo manual de las cosas que otra nube vecina le anunciaba. Ejemplo, si yo soy Antel y levanto una sesión BGP con Telecom Argentina se supone que Telecom Argentina debería hacer alguna verificación de algún tipo de las rutas que Antel le dice que le va a publicar y lo mismo al revés.

El problema es que ese tipo de supervisión manual es muy difícil de mantener. Luego de los sucesos de 2008, la IETF (Internet Engineering Task Force) se dispuso a mejorar todo este circuito y fue ahí que RPKI emergió como la primera aproximación a una solución, un conjunto de tecnologías que permiten que los enrutadores hagan algún tipo de chequeo ellos mismos de la información que están recibiendo y calculen en función de eso la tabla de enrutamiento.

En concreto, RPKI es una infraestructura de clave pública que brinda más herramientas a un proveedor para verificar el derecho de uso de un recurso de Internet por parte de un cliente. Incorpora los certificados ROA (Route Origin Attestations), 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.  De esta forma, es posible contrastar la información que se recibe por BGP con las definiciones contenidas en los ROA de RPKI de manera automática.

Vale destacar que los RIRs -que somos los que asignamos las direcciones IP- obramos de alguna manera como ancla de confianza de esa información, porque lo que necesita saber un enrutador para poder clasificar un anuncio válido o inválido en términos de RPKI es si el sistema autónomo de origen que menciona cierto prefijo IP efectivamente es el titular de esas direcciones IP. Adicionalmente, una cadena de firmas digitales certifica que esa afirmación está emitida apropiadamente.

En este sentido, otro punto que quiero subrayar es que existe una importancia y una insistencia en que los operadores de la región activen sus políticas de enrutamiento y lograr un crecimiento en la cobertura de validación en el espacio IP anunciado por los asociados de LACNIC, por lo que parte de nuestros esfuerzos está dirigido a verificar la validez de todos sus certificados. Un dato alentador en este sentido es que la evolución del porcentaje de rutas anunciadas por nuestra región que están cubiertas por ROAs de RPKI es muy positiva: a noviembre de 2024 tenemos un 54.6% de las rutas IPv4 de la región cubiertas por ROAs y un 55.4% en IPv6.

Vemos que a utilización por parte de los asociados de LACNIC de los servicios de IRR (Internet Routing Registry, base de datos global que documenta la información de rutas entre los operadores de red) y RPKI continúa creciendo, acompañando la adopción de los proveedores de contenido y carriers y de chequeos de seguridad basados en IRR y RPKI como requisito para establecer relaciones de peering o de tránsito.

Las opiniones expresadas por los autores de este blog son propias y no necesariamente reflejan las opiniones de LACNIC.