A. F. Gómez Skarmeta,A. L. Mateo, P. M. Ruíz
Resumen
La utilización de IP Multicast es la mejor solución para la distribución de contenidos multimedia muchos-a-muchos, como por ejemplo audio/vídeo conferencia. Sin embargo, en la actualidad hay muy pocos proveedores de servicios de Internet que lo ofrezcan como un servicio a sus clientes. La principal razón es que actualmente el IP Multicast aún carece de muchos mecanismos como facturación, autenticación, seguridad, protección contra usuarios malignos, etc.. De hecho, las redes IP Multicast pueden ser fácilmente atacadas por mecanismos DoS. En este documento describimos cómo se puede solucionar este problema.
Palabras clave: IP, Multicast, IGMP, Mbone, seguridad, autenticación, control de acceso, videoconferencia
Summary
IP Multicast has proven to be very good for many-to-many multimedia communications like audio and videoconferencing. However, there are only a few Internet Service Providers offering it as a true Internet service to their customers. The reason is that nowadays, IP Multicast has many issues like billing, authentication, security, protection against malicious people and so on. In fact, DoS attacks can be easily caused in IP Multicast-enabled networks. In this paper we describe how to solve some of these problems.
Keywords: IP, Multicast, IGMP, Mbone, security, authentication, access control, videoconference.
1.- Introducción
En estos momentos, se puede pensar que el IP Multicast ha alcanzado un grado de madurez suficiente para su explotación comercial. Sin embargo, si realizamos un estudio más profundo, podemos observar que el IP Multicast tiene algunos aspectos, sobre todo relacionados con seguridad, que tienen que ser solucionados, de entre los cuales, cabe destacar el problema de la autenticación de usuarios.
Esto es así, porque la autenticación de usuarios es un elemento clave en cualquier campo en el que se piense utilizar IP Multicast: distribución de contenidos pay per view, tele-enseñanza,... de modo que se pueda controlar quién accede al sistema y se pueda evitar accesos no deseados.
2.- Trabajo relacionado
En agosto de 1998, Norihiro Ishikawa lanzó un Internet-Draft que se llamó Extension for Authentication of IP Multicast Senders and Receivers[1]. Este draft propone algunos añadidos sobre el protocolo IGMPv2[2] para controlar los paquetes IP Multicast que puede recibir y/o enviar un usuario de la red.
Skarmeta, Mateo y Ruiz[3] desarrollaron un mecanismo para poder ofrecer IP Multicast a los estudiantes de su Universidad de un modo controlado, de modo que aunque se podía recibir cualquier sesión multicast, estos no podían enviar datagramas hacia RedIRIS, mediante el control y la limitación del TTL en los paquetes multicast enviados. Este mecanismo estaba basado en un protocolo Call/Response que se utilizaba para instalar las políticas apropiadas en los routers multicast.
La última versión de IGMP la v3 [4], permite filtrar en base al origen de los datagramas, de modo que se puede utilizar para controlar quién se une a un grupo. Además, en mayo de 2000, B. Quinn propuso el Internet-Draft llamado Source Filters[5] que describe cómo adaptar el protocolo Session Description Protocol (SDP)[6] para expresar uno o más filtros en el origen de los datagramas en uno o varios destinos.
3.- Autenticación basada en IGMPv3
En los trabajos anteriores, la autenticación se realiza en base a la dirección IP de origen del datagrama. Este mecanismo de autenticación es muy poco fiable, debido a la facilidad de que una dirección IP se pueda falsificar (IP spoofing), de modo que proponemos un nuevo mecanismo de autenticación. Además, el hecho de que la dirección de origen no sea fiable implica que tampoco se pueda utilizar IPSec [7] en nuestro propósito.
La idea clave es extender IGMPv3 para que transporte información de autenticación de usuario, de modo que un router de una red pueda decidir si considera los mensajes IGMPv3 Report o no. Para esto, proponemos la utilización del Auxiliary Data Field del paquete IGMPv3 para transportar la información de autenticación, de modo que no es necesario introducir cambios en el protocolo IGMPv3.
Con esto, debe quedar claro que la definición de cómo se realiza la autenticación de los usuarios es un aspecto que queda fuera de este documento, cuyo objetivo es proporcionar los mecanismos para que se pueda realizar esta autenticación. Así, si, por ejemplo, la organización se basa en una infraestructura de clave pública (PKI, Public Key Infraestructure), se puede pensar en utilizar este campo para transportar la firma dell paquete IGMP basada en la clave privada del usuario, de modo que el router tendría que consultar la clave pública del usuario en un servidor de directorio (LDAP, por ejemplo) para poder comprobar si la firma es correcta o no (y por tanto, comprobar si el usuario es quién dice ser) y tomar la decisión oportuna sobre ese mensaje.
Este Auxiliary Data Field debe transportar, no sólo la información de autenticación (por ejemplo, la firma basada en PKI), sino también información propia del usuario para que el router pueda saber el usuario al que pertenece el paquete. De modo que, los primeros bytes del Auxiliary Data Field se corresponderán con la información de autenticación y el resto será la información de usuario. La Figura 1, muestra cómo se añade la identificación de usuario y un valor de hash en el primer Group Record del Auxiliary Data Field cuando se utiliza MD5 para garantizar la autenticación de usuario.
De esta manera, un router puede decidir si un usuario está autorizado o no para unirse a una sesión multicast. Por ejemplo, se puede utilizar este mecanismo para evitar ataques DoS en redes multicast, problema que no se puede resolver con ninguno de los métodos comentados anteriormente, en el caso de que por ejemplo, alguien de tu red decide conectarse a todos los grupos multicast activos. Ocurre el mismo problema cuando algún usuario de la red se pone de acuerdo con otra persona del exterior para inundar tu red cuando ambos se conectan a una misma sesión y el segundo inunda la red con un tráfico de gran ancho de banda. Nuestra propuesta evita este problema ya que el administrador puede decidir quién puede provocar qué flujos y quién no.
Este documento describe la utilización de IGMPv3 para proporcionar un cierto nivel de seguridad a redes multicast. Su principal objetivo es describir una extensión de IGMPv3, de modo que se pueda evitar el problema de ataques DoS y se pueda proporcionar un control de acceso de usuarios a la red multicast.
No obstante, no es más que el primer paso en el camino para conseguir una solución completa que ofrezca los servicios de seguridad típicos (autenticación, seguridad, integridad, etc.) en redes IP Multicast. De modo, que aún queda bastante trabajo por realizar. El siguiente paso consiste en implementar estas extensiones sobre alguna de las recientes implementaciones de IGMPv3, así como modificar el API de acceso a IGMPv3 para permitir el uso del Auxiliary Data Field.
Bibliografía
N. Ishikawa, N. Yamanouchi, O. Takahashi. "IGMP Extension for Authentication of IP Multicast Senders and Receivers". Internet-Draft. Agosto 1998.
W. Fenner. "Internet Group Management Protocol. Version 2". RFC 2236. Noviembre 1997.
A. Gómez Skarmeta, A. L. Mateo Martínez, P. M. Ruiz Martínez. "Access Control in Multicast Environments: an Approach to Senders Authentication". Proceedings of the IEEE LANOMS'99, pp 1-13. 1999
B. Cain, S. Deering, A. Thyagarajan. "Internet Group Management Protocol. Version 3". Internet-Draft. Noviembre 1999.
-
B. Quinn. "SDP Source-Filters". Internet-Draft. Mayo 2000.
M. Handley, V. Jacobson. "SDP: Session Description Protocol". RFC 2327. Abril 1998.
S. Kent, R. Atkinson. "Security Architecture for the Internet Protocol". RFC 2401. Noviembre 1998.
Antonio F. Gómez Skarmeta
skarmeta [at] dif [dot] um.esÁngel L. Mateo Martínez
amateo [at] um [dot] es,Dpto. de Informática, Inteligencia Artificial y Electrónica
Pedro M. Ruíz Martínez
pedrom [at] it [dot] uc3m.es
Área de Ingeniería Telemática
Universidad Carlos III de Madrid
Cuando se presentó este trabajo, Pedro M. Ruiz era profesor asociado en la Universidad Carlos III de Madrid. En estos momentos, Pedro trabaja en RedIRIS.