Saulo.Net > Publicaciones > de investigación > Artículo

Seguridad en BGP

 

Saulo Barajas
Doctorado en Tecnologías de las Comunicaciones
Universidad Carlos III de Madrid
E-mail: correo at saulo net

Abstract. The autonomous systems that constitute Internet interchange their routes using BGP (Border Gateway Protocol).  BGP is responsible to determine the way that IP datagrams must follow to reach  a target address. The attacks to BGP protocol can allow a malicious person to receive IP datagrams of another autonomous system, modify them and even, leave networks inaccessible from all Internet.  The security in BGP is a crucial aspect for the accurate operation of Internet.  But attacks not only must be considered, but also misconfigurations from the network administrators.  The article explains the main vulnerabilities of BGP protocol and the solutions to avoid them. S-BGP (Secure BGP) extensions, proposed by BBN, are analyzed, describing their elements and operation. Finally, the article shows related works to S-BGP like soBGP (Secure Origin BGP).


1 Introducción a BGP

El protocolo BGP se ha constituido como el principal protocolo de encaminamiento externo utilizado en Internet. Prácticamente todo el tráfico que fluye entre unos ISPs y otros es encaminado a través de BGP. La versión actual, BGP-4, se encuentra descrita en las RFC 1771 [1] y 1772 [2].

Con el fin de reducir el tamaño de las tablas de encaminamiento y de facilitar su gestión, Internet se encuentra dividido en sistemas autónomos (AS).

Un sistema autónomo es un conjunto de redes administradas por una misma organización que tiene definida una única política de encaminamiento [3]. Esta política de encaminamiento decide las rutas admitidas desde los sistemas autónomos vecinos y las rutas que se envían hacia estos sistemas autónomos. En su interior, el AS utiliza un protocolo interno de encaminamiento como, por ejemplo, OSPF. El protocolo BGP un protocolo de encaminamiento entre sistemas autónomos.

Cada sistema autónomo en Internet tiene un identificador (ASN) formado por 16 bits, lo que permitiría hasta 65536 sistemas autónomos teóricos diferentes, si bien el rango de 64512 a 65535 se encuentra reservado para uso privado.

Las tablas de encaminamiento de BGP-4 almacenan rutas para alcanzar redes, más concretamente prefijos de cierto número de bits. Las rutas están formadas por una secuencia de números de sistemas autónomos que se deben seguir para alcanzar el prefijo indicado. El último número de AS de la ruta se corresponde con la organización que tiene registrado el prefijo. El principal motivo para almacenar la ruta completa es la detección y eliminación de bucles (loops), esto es, que los paquetes se reenvíen de forma infinita entre unos mismos sistemas autónomos (A-B-C-A-B-C-A...) sin alcanzar nunca el destino o, dicho de otra manera, que los mismos paquetes pasen varias veces por un mismo sistema autónomo.

Según el número de conexiones con otros sistemas autónomos y las políticas definidas, un sistema autónomo puede ser de diferentes tipos. El más sencillo (denominado stub AS) tiene una única conexión con otro AS, que será normalmente su ISP. Por este sistema autónomo únicamente circula tráfico local. Si el AS tuviese más de una conexión a otros sistemas, por motivos de redundancia generalmente, se denominaría multihomed. El tráfico que circula dentro del AS seguiría siendo local. Por último, un sistema autónomo de tránsito es un sistema con varias conexiones, el cual reenvía tráfico de una conexión a otra. Por supuesto, los sistemas autónomos pueden decidir y de hecho así lo hacen los tipos de tráfico que transportan, mediante el establecimiento de políticas.

2 Aspectos de seguridad

Supongamos una organización A que utiliza BGP para conexión redundante con dos ISPs. Esta organización se ha registrado como sistema autónomo y dispone por tanto de un ASN, el 60500, por ejemplo. Además, en este sistema autónomo, la organización utiliza la red de su propiedad 200.10.4.0/23. El sistema BGP anuncia el prefijo 200.10.4.0/23 a los dos routers vecinos (uno por cada ISP). Y cada ISP propaga las rutas hacia el exterior de forma que el resto de routers BGP de Internet serán informados de la mejor ruta para alcanzar la red 200.10.4.0/23.

Hasta aquí todo parece correcto, aunque desde el punto de vista de la seguridad nos podemos formular algunas preguntas [9]: ¿realmente el prefijo 200.10.0/23 pertenece a la organización A? ¿el router que dialoga con los routers vecinos de los ISPs es el que la organización A ha instalado y no es un suplantador que inyecte información maliciosa? ¿la ruta que utiliza un usuario final para conectarse a un servidor de la organización A es realmente la correcta y no ha sido modificada durante su propagación para redirigir el tráfico hacia un sistema autónomo comprometido B?

Realmente BGP-4 no tiene forma de garantizar la respuesta a estas preguntas. Los ataques de suplantación de prefijos, sistemas autónomos o routers pueden realizarse con relativa facilidad y tener repercusiones a nivel de Internet. Necesitamos mecanismos de autentificación que nos garanticen que cada elemento del sistema es quien dice ser.

BGP tiene otras carencias de seguridad como la falta de control temporal en sus mensajes. Sin este control, un atacante situado entre dos routers BGP vecinos podría capturar tráfico BGP (un mensaje UPDATE que elimine cierta ruta por ejemplo) y reproducirlo en un instante futuro.

Además, al estar BGP basado en TCP, hereda todos sus fallos de seguridad. Los routers vecinos mantienen establecida una conexión TCP permanentemente (sesión BGP). En caso de que esta conexión se interrumpa, el router vecino asumirá que el enlace se ha desconectado o el router del otro extremo ha dejado de funcionar, por lo que eliminará automáticamente todas las rutas afectadas. Un ataque conocido es la inyección de segmentos TCP con el bit de RST activado [6]. El router que recibe un RST considera que el otro extremo le solicita un cierre de conexión y cierra automáticamente la sesión. La consecuencia para la organización A que comentamos en el ejemplo anterior sería que su red quedaría inaccesible, puesto que se eliminarían todas las ruta hacia su red.

3 Soluciones parciales

Ante este abanico de problemas de seguridad, los administradores pueden tomar en la actualidad ciertas medidas; sin embargo, como veremos, se trata de medidas que reducen tan sólo una parte de los problemas y, realmente, lo que buscamos son soluciones globales de seguridad en BGP.

Mediante la utilización de reglas de filtrado podemos definir las rutas que aceptaremos y aquellas que anunciaremos. Un ISP debería filtrar todas las rutas que procedan de una organización final diferentes a las correspondientes a sus prefijos registrados. Una organización final deberá ajustar sus filtros para no anunciar rutas de otros sistemas autónomos (para no hacer tránsito). Los filtros siempre han existido en BGP y son ciertamente potentes, pero su configuración pormenorizada puede resultar compleja y no se descartan errores por parte del administrador.

La seguridad en BGP no sólo debe cubrir ataques intencionados sino también errores de configuración por parte del administrador. Estos últimos son en la actualidad más numerosos que los primeros y deben ser tenidos en cuenta en las políticas de seguridad.

Con el fin de evitar la suplantación de routers vecinos, una opción es la utilización de contraseñas en los extremos de la sesión. Sin embargo, esta solución acarrea dificultades añadidas: ¿cómo distribuir la contraseña? Si la enviamos de forma no segura por Internet podría ser interceptada. Pero no sólo eso: ¿cada cuánto tiempo se cambia la contraseña? ¿deben ponerse de acuerdo los administradores vecinos para realizar el cambio justo en el mismo instante? Como vemos, genera demasiados inconvenientes operacionales. Por otro lado, una contraseña utilizada únicamente al inicio de una sesión BGP no impide que se pueda interceptar una conexión ya validada y suplantar a uno de los dos extremos.

Desde luego, podemos asegurar el canal completo entre dos routers vecinos ya sea mediante una línea dedicada o bien mediante la utilización de IPSec u otras tecnologías. Aunque esto no haría nada contra la propagación de rutas inválidas que hayan sido inyectadas en algún tramo anterior.

Un método para garantizar que las rutas propagadas por un router tienen su origen en un sistema autónomo propietario de los prefijos anunciados es mediante la utilización de registros de enrutamiento como RADB [7]. El router puede consultar un registro para verificar que cada ruta tiene un origen válido y no está propagando rutas falsas. Esta opción no impide que se pueda modificar una ruta que debería ir del sistema autónomo 1 al 2 y hacerla pasar por un sistema autónomo malicioso, 3, entre ambos.

4 S-BGP

Entre las soluciones propuestas más completas para dotar de seguridad a BGP se destaca S-BGP (Secure BGP), desarrollado por BBN y promovido por NSA y DARPA. Su objetivo es dotar de autenticidad, integridad y autorizaciones a los mensajes BGP. Su último borrador data de enero de 2003 [4].

S-BGP está formado por tres elementos:

o        Certificados digitales. Se utilizan dos PKIs, una para autentificar los prefijos IP y otra para los sistemas autónomos. Los autores proponen que las autoridades de certificación se correspondan con los actuales organismos de gestión de direcciones IP y números de sistemas autónomos (ICANN, RIRs como RIPE o ARIN, etc.)

o        Attestations. Mediante este término se denominan las autorizaciones emitidas que, según se explica más adelante, pueden ser de dos tipos: de direcciones y de rutas.

o        IPSec. Su misión es aportar autenticidad e integridad en los enlaces entre dos routers. No se considera la confidencialidad puesto que no es necesaria para la difusión de rutas.

En los siguientes apartados se estudian cada uno de los elementos mencionados.

4.1 Certificados digitales

Se utilizan dos PKIs basadas en certificados X.509v3, una para direcciones y otra para sistemas autónomos. El motivo de establecer dos PKIs es porque las entidades que asignan prefijos de red y las que asignan sistemas autónomos podrían ser distintas. Esto es, una organización podría recibir de una entidad sus prefijos de red y de otra distinta, su número de sistema autónomo.

La estructura de cada PKI está encabezada por el ICANN como propietario de todo el espacio de direcciones IP y de números de sistemas autónomos, el cual va delegando en distintos entidades intermedias hasta llegar al ISP u organización final.

4.1.1 PKI para la asignación de direcciones

La primera PKI es para la asignación de direcciones. Está formada por certificados que asocian un conjunto de prefijos como propiedad de una organización.

Al contrario que un certificado tradicional que se utiliza para probar la identidad de su propietario, estos certificados prueban la pertenencia de un conjunto de prefijos de red. Para este fin los autores consideran la utilización de un atributo X.509 pero lo descartan por no estar soportado suficientemente, a favor de una extensión privada v3 al certificado de clave pública [4].

4.1.2 PKI para la asignación de  sistemas autónomos y routers asociados

La segunda PKI es para la asignación de sistemas autónomos y routers asociados. Los certificados almacenados en esta PKI pueden ser de tres tipos:

o        Certificado emitido por un registro (o el ICANN) a una organización que contiene su número de sistema autónomo y la clave pública de la organización. Prueba la propiedad de un sistema autónomo. Se firma con la clave privada del registro.

o        Certificado emitido por una organización (ISP) que contiene su número de sistema autónomo y su clave pública. Se firma con la clave privada de la organización.

o        Certificado emitido por una organización (ISP) que identifica a su router BGP, mediante su nombre DNS, un identificador, un número de sistema autónomo y la clave pública del router. Prueba que un router pertenece al sistema autónomo de una organización. Se firma con la clave privada de la organización.

El objetivo de esta PKI es probar que un sistema autónomo dado y un router pertenecen a cierta organización. Los routers intermedios utilizarán los certificados de las PKIs para asegurar la autenticidad de la información contenida en las rutas recibidas.

4.2 Attestations

Un attestation es un documento digital que emite una entidad para autorizar cierto comportamiento a un objeto. Se definen dos tipos de attestations: de direcciones y de rutas, los cuales se difunden mediante mecanismos diferentes.

4.2.1 Attestations de direcciones

Los attestations de direcciones (AA) son emitidos (firmados) por una organización para que un sistema autónomo de su propiedad pueda anunciar unos prefijos. Mediante la clave pública contenida en el correspondiente certificado de direcciones, un router intermedio puede verificar la validez de un AA.

El certificado es la prueba de la pertenencia de un prefijo a una organización y el AA, la autorización para que ese prefijo se pueda anunciar.

Debido a que los attestations de direcciones apenas se modifican, se prefiere su almacenamiento en un repositorio externo, en lugar de enviarlos en los propios mensajes BGP.

Cada vez que un router intermedio recibe una ruta contenida en un mensaje BGP de tipo UPDATE, verifica la pertenencia de los prefijos anunciados a una organización. Para ello necesitará consultar el certificado de la organización.

4.2.2 Attestations de rutas

Los attestations de rutas (RA) son firmados  por un router S-BGP para autorizar al siguiente router vecino a propagar una ruta. El objetivo aquí es asegurar la cadena de routers, de forma que no pueda alterarse la ruta en tránsito para incluir un sistema autónomo intermedio no autorizado.

A diferencia del anterior tipo de attestation, los RA son muy cambiantes, por lo que se envían en el propio mensaje UPDATE, utilizando para ello un nuevo atributo.

Este nuevo atributo se ha definido de tipo opcional y transitivo para que aquellos sistemas BGP intermedios que no soporten S-BGP, puedan no interpretarlo pero sí se lo pasen al siguiente sistema BGP.

Cada sistema BGP añade un RA al mensaje UPDATE antes de pasarlo al siguiente sistema autónomo. De esta manera, el router BGP que recibe el mensaje debe verificar cada uno de los RA recibidos, lo que le permitirá validar toda la cadena de saltos entre cada sistema autónomo y el siguiente. Para ello necesitará garantizar la validez de los RA, consultando los respectivos certificados de routers BGP.

4.3 IPSec

Finalmente, el último elemento de S-BGP es IPSec. Su misión es asegurar las sesiones BGP entre dos routers vecinos proporcionando integridad y autenticidad. Se utilizan los componentes ESP e IKE de IPSec.

S-BGP no garantiza la confidencialidad, por lo que se configura IPSec para no hacer encriptación en los mensajes BGP. Realmente, la encriptación no es necesaria puesto que las rutas son públicas y además ni siquiera sería aconsejable puesto que supondría una carga extra de proceso el cifrado y descifrado de mensajes.

Una ventaja adicional de IPSec es que, al funcionar en la capa de red, subsana las vulnerabilidades de TCP explicadas anteriormente. Los segmentos TCP enviados fuera de una conexión IPSec a un host no se llegan siquiera a procesar, por lo que BGP deja de verse afectado por el envío de segmentos RST falsos, inundaciones de SYN u otras deficiencias inherentes a TCP.

5 Implementación de S-BGP

La puesta en funcionamiento de S-BGP en Internet es compleja. Por un lado, requiere la colaboración de las entidades de registro para hacerse cargo de los procedimientos asociados a una PKI: emisión de certificados, revocación de los mismos, mantenimiento y publicación de listas de revocación (CRL), etc. Esto requiere nueva infraestructura en equipos y personal, así como una cuidada política de seguridad, por parte no sólo del ICANN sino del resto de autoridades de registro delegadas incluyendo ISPs.

En caso de que la colaboración de estas entidades supusiera un grave impedimento, se podría estudiar la fórmula para utilizar autoridades de certificación independientes, aunque esta posibilidad no está contemplada por los autores y supondría replantear todas las especificaciones.

Por parte de las organizaciones se requiere la actualización de sus routers BGP, no sólo de software sino también de hardware. La ampliación de hardware es necesaria puesto que S-BGP requiere que los routers almacenen certificados digitales (mayor memoria) y tengan potencia suficiente para la realización de funciones criptográficas (mayor capacidad de proceso). Una posibilidad para no tener que cambiar los costosos routers BGP es anexarles un PC que les proporcione memoria adicional e incluso, CPU.

Los certificados, CRLs y attestations de direcciones se almacenan de forma externa en un repositorio. Los routers sin embargo requieren estos elementos para validar las rutas. Esto nos lleva a un problema operacional, que no queda claramente resuelto por los autores, de cómo se inicializa un router para comenzar a funcionar estando el repositorio hospedado en otra red, si para validar las rutas requiere certificados y para tener certificados requiere rutas. Quizás sea necesaria una inicialización con certificados instalados offline, aunque su almacenamiento es problemático puesto que los certificados tienen una fecha de caducidad y además podrían ser revocados en cualquier momento.

Por otro lado, podemos pensar en el mayor ancho de banda ocupado por los UPDATE de S-BGP, los cuales transmiten además ahora los attestations de rutas. Se requiere también mayor capacidad de proceso y de memoria para el almacenamiento de certificados, como hemos comentado anteriormente. Sin embargo, los autores demuestran estadísticamente [4] que estos incrementos de ancho de banda, proceso y memoria no son significativos.

Las actualizaciones de software y hardware resultan costosas para las organizaciones, las cuales no ven una mejora inmediata que puedan repercutir a sus clientes. Probablemente sean necesarios varios ataques al protocolo BGP antes de que las organizaciones afectadas consideren la necesidad de asegurar sus sistemas.

6 Trabajos relacionados con S-BGP

La RFC 2385 describe TCP/MD5 [5], una extensión a TCP para incluir firmas MD5 en sus mensajes. La utilización de TCP/MD5 en los segmentos TCP intercambiados entre dos pares BGP proporciona integridad y autentificación en los mensajes BGP. Sin embargo, no resuelve otros problemas de BGP como la validación de las rutas anunciadas. El principal problema de TCP/MD5 es la distribución de las claves entre los pares BGP, lo que en la práctica provoca que se utilice un “secreto compartido” entre ambos extremos (clave simétrica) y que ésta no se modifique tan periódicamente como sería recomendable.

Una alternativa a S-BGP es soBGP (Secure Origen BGP) [6][7]. Utiliza certificados digitales y un nuevo tipo de mensaje BGP denominado “Security Message”. Valida el origen de las rutas anunciadas pero no considera ataques que alteren los saltos intermedios de una ruta.

7 Conclusiones

El correcto funcionamiento de BGP es crucial para el funcionamiento de Internet. De BGP depende que cuando un host envíe un paquete a otro host situado en un sistema autónomo diferente, éste llegue correctamente a su destino.

Los ataques al protocolo BGP no son frecuentes en la actualidad, aunque podrían popularizarse en un futuro poniendo contra las cuerdas a toda la infraestructura de Internet, desviando rutas y dejando redes inaccesibles.

Sin embargo, no sólo se deben considerar los ataques al protocolo, sino también los fallos de configuración por parte de los administradores. El objetivo de la seguridad en BGP es que un ataque a un sistema autónomo  o fallo de configuración no se propague al resto de Internet y se mantenga local.

S-BGP son unas extensiones de seguridad que proporcionan integridad, autenticidad y autorizaciones a BGP.

Sus elementos constituyentes son: PKI para la asignación de direcciones, PKI para la asignación de sistemas autónomos y routers asociados, attestations de direcciones, attestations de rutas e IPSec. El sostenimiento de las PKIs se asigna a las mismas entidades responsables de la asignación de direcciones IP y sistemas autónomos (ICANN y registros delegados).

Cada vez que un router BGP recibe una ruta, verifica que la cadena de saltos entre sistemas autónomos anteriores esté autorizada, así como que los prefijos y sistema autónomo inicial de la ruta sea válido. Para ello necesita consultar los certificados digitales. La función de IPSec es asegurar los canales entre pares de routers.

S-BGP constituye unas extensiones complejas que requieren la colaboración de numerosas organizaciones, las cuales deben realizar inversiones para actualizar sus routers. Si comparamos S-BGP con otras soluciones, como soBGP, encontramos que es el protocolo que cubre el mayor número de posibles ataques, a costa de un aumento en complejidad, infraestructura y procesamiento.

La seguridad tiene siempre un coste, aunque su implantación no debe ser excesivamente compleja puesto que no sería práctico [8]. Queda por determinar el compromiso entre el grado de seguridad necesario y factores como complejidad, rendimiento y costes. Aunque no cubra el 100% de las vulnerabilidades conocidas, otra solución podría ser finalmente puesta en marcha si abarca las principales vulnerabilidades pero con un coste considerablemente menor.

Referencias

[1]     Y. Rekhter y T. Li, “A Border Gateway Protocol 4 (BGP-4)”, RFC 1771, marzo de 1995.

[2]     Y. Rekhter y P. Gross, “Application of the Border Gateway Protocol in the Internet”, RFC 1772, marzo de 1995.

[3]     J. Hawkinson y T. Bates, “Guidelines for creation, selection, and registration of an Autonomous System (AS)”, RFC 1930, marzo de 1996.

[4]     C. Lynn, J. Mikkelson y K. Seo, “Secure BGP (S-BGP)”, draft-clynn-s-bgp-protocol-01, junio de 2003.

[5]     A. Heffernan, “Protection of BGP Sessions via the TCP MD5 Signature Option”, RFC 2385, agosto de 1998.

[6]     Iljitsch Van Beijnum, Building Reliable Networks with the Border Gateway Protocol, O’Reilly, ISBN: 0596002548 (2002).         

[7]     Routing Assets Database: http://www.radb.net/

[8]     Lakshmi Subramanian, Security and Predictability, octubre de 2003.

[9]     Sargon Elias, “Is the Border Gateway Protocol Safe?”, 5 de abril de 2003.

[10]   BGP - the Border Gateway Protocol Advanced Internet Routing Resources: http://www.bgp4.as/