domingo, 10 de junio de 2012

SKYPE


Skype es un cliente P2P VoIP desarrollado por KaZaa que también es una red peer-to-peer overlay. Skype permite que sus usuarios realicen llamadas de voz y envíen mensajes del texto a otros usuarios clientes de Skype. Esencialmente, es muy similar a las aplicaciones MSN y Yahoo IM, pues tiene capacidades para llamadas de voz, mensajería instantánea, audio conferencia y listas de contactos. Sin embargo, los protocolos y las técnicas subyacentes que emplea son absolutamente diferentes.

Figura 2. Imagen del inicio de Skype


1.1.        Arquitectura Skype

La arquitectura Skype se basa en un tipo de red llamada “overlay network” o red de aplicación que es un ejemplo de red P2P.

Figura 3. Ejemplo de red overlay

La red overlay de Skype tiene 3 tipos de nodos:

  • Nodo Normal: nodo donde se ejecuta una aplicación o cliente Skype (SC) que se puede utilizar para realizar llamadas de voz y para enviar mensajes del texto.
  • Supernodo: nodo con una dirección IP pública que tiene suficiente CPU, memoria, y ancho de banda de red.
  • Skype login Server (Servidor de conexión): Servidor único y única entidad central dentro del esquema de Skype asegurándose de que los nombres de la conexión sean únicos a través del espacio de nombres de Skype. Su principal función es la de permitir la autentificación del usuario y almacenar los nombres de forma única y las contraseñas del usuario.
Figura 4. Red overlay de Skype
Aparte del servidor de conexión, no hay servidor central en la red de Skype. La información en línea y fuera de línea del usuario se almacena y se propaga de manera descentralizada y así como las búsquedas de los usuarios.

1.1.        Componentes de Skype

Como toda aplicación de red, un cliente Skype abre puertos de escucha TCP y UDP, pero Skype a diferencia de otros protocolos como HTTP, no tiene puertos de escucha por defecto, sino que el número de puerto del cliente es generado aleatoriamente durante la instalación.

Adicionalmente el SC abre los puertos de escucha TCP en los puertos 80 (HTTP) y 443 (http_over_TLS). La figura 5 muestra el cuadro de diálogo de conexión de Skype mostrando los puertos en los cuales un SC escucha las conexiones entrantes.


Figura 5. Tabla de conexiones de Skype, donde se muestran los números de puertos

Skype mantiene en la caché del cliente (Host Cache, HC) una tabla con pares de direcciones IP de supernodos y puertos, que se construye y refresca regularmente llegando a almacenar un máximo de 200 entradas. El mantener la caché del cliente es una de las operaciones más críticas de Skype. En las primeras versiones de Skype era necesario que al menos hubiera una entrada válida en la tabla, ya que durante el proceso de identificación tenia que establecer una conexión TCP e intercambiar información con cualquier entrada de la caché. De no ocurrir este intercambio, el programa daba un error en el proceso de identificación. A partir de la versión 1.2, este error se subsanó, de manera que si resultaba imposible realizar una conexión TCP con alguna entrada de la caché del cliente, entonces se intentaba establecer una conexión TCP e intercambiar información con alguna de los siete pares de direcciones IP y puertos alojados en el Bootstrap que se hallan codificados en el ejecutable de Skype.

Un cliente Skype en Windows XP almacena su caché de cliente en un fichero XML ‘shared.xml’ situado en ‘C:\Documents And Settings\<Usuario>\Application Data\Skype’’. En Linux se almacena el fichero XML en ‘$(HOME)/.Skype’.

Figura 6. Trozo del contenido de la tabla de la caché del cliente. (shared.xml)

Para la codificación de audio Skype se utilizan los códecs iLBC, iSAC y iPCM, todos ellos desarrollados por GlobalIPSound que permiten utilizar frecuencias comprendidas entre los 50 y los 8000 Hz. Este rango de frecuencias es característico de una codificación de banda ancha.

La lista de contactos o buddy list se almacena encriptada en otro fichero XML llamado ‘config.xml’. En Windows XP este fichero se aloja en ‘C:\Documents And Settings\<Usuario>\Application Data\Skype\<usuario skype>’’ mientras que en Linux está en ‘$(HOME)/.Skype/<usuario skype>’. A partir de la versión de Skype 1.2 para Windows XP, la lista de contactos también se almacena en el servidor central de Skype cuya dirección IP es 212.72.49.142.

Figura 7. Trozo del contenido de la lista de contactos. (config.xml)

En cuanto a la encriptación de datos, Skype utiliza AES (Advanced Encryption Standard), también conocida como Rijndael que es usado también por las organizaciones de protección de datos del gobierno de los Estados Unidos. Esta encriptación utiliza 256 bits que permiten un total de 1.1x1077 posibles claves para cifrar cada llamada o mensaje instantáneo.

1.1.        Funciones Skype

Dado que Skype no es un programa de código abierto, para averiguar las comunicaciones que se realizan entre clientes Skype, Basset y Schulzrinne utilizan dos clientes Skype usando las herramientas Ethereal y NetPeeker para analizar y controlar el tráfico de red. Especialmente se utiliza NetPeeker para analizar el funcionamiento de Skype en una red congestionada.

1.1.1.   Arranque

Cuando el cliente Skype funciona la primera vez después de la instalación, envía un HTTP 1.1 GET Request al servidor de Skype (skype.com). La primera línea de esta petición contiene la palabra clave 'installed’.

1.1.2.   Conexión

La conexión es quizás la función más crítica de la operación de Skype. Durante este proceso un cliente Skype autentifica su nombre y contraseña de usuario con el servidor de conexión, que anuncia su presencia a otros nodos y a sus contactos. Determina que tipo de NAT y de cortafuegos está detrás y descubre los nodos Skype con direcciones del IP públicas que están conectados.

1.1.2.1.       Proceso de conexión

Para comprobar el funcionamiento del proceso de conexión, primero se borra el fichero XML del cliente. Después se observa que éste manda un paquete UDP de 18 bytes de longitud a cada una de las siete entradas de la Bootstrap, todas ellas en el puerto 33033.

Si no recibe respuesta en 5 segundos, el cliente intenta establecer una conexión TCP sobre cada una de las siete entradas sobre el mismo puerto. Si este intento de conexión falla se repite el proceso después de 6 segundos. Skype puede quedarse infinitamente realizando estos intentos de conexión hasta que lo consiga, pues nunca devuelve un fallo de conexión.


Figura 8. Diagrama de flujo del intento de conexión

Cuando se realiza la conexión se observa cual es el número mínimo de mensajes intercambiados. El primer y el segundo mensaje intercambiado con el servidor de conexión son siempre los mismos para diferentes intentos de conexión e incluso para distintos usuarios de Skype.

Figura 9. Diagrama de flujo del intento de conexión
La representación decimal con el Ethereal del mensaje (1) es 22 3 1 0 0 y la representación del mensaje (2) es 23 3 1 0 0. En la mayoría de los experimentos realizados, sólo cuatro mensajes se intercambian entre el servidor de conexión y el cliente Skype, siendo estos normalmente de la misma longitud. Los mensajes (3) y (4) son distintos para cada intento de conexión, aun así mantienen 4 bytes en común que son los mismos que los primeros 4 bytes de los mensajes (1) y (2) respectivamente, correspondientes a la cabecera del mensaje. El valor 22 de la cabecera corresponde al tipo de mensaje SSL, lo cual indica que Skype utiliza SSL para los mensajes de conexión.

Cuando la conexión falla, la longitud de los mensajes (1), (2) y (3) es la misma que en el caso anterior, mientras que el mensaje (4) tiene una longitud de 18 bytes indicando el fallo en la conexión.

1.1.1.1.       Conexión al servidor

Después de que un cliente Skype se conecte a un supernodo, el cliente debe autentificarse mediante un nombre de usuario y contraseña con un servidor Skype. La conexión al servidor es el único componente centralizado existente en red P2P de Skype.

Este almacena los nombres de usuarios y contraseñas asegurándose que son únicos dentro del espacio de nombres de Skype. Durante los experimentos realizados se observó que siempre intercambia datos sobre TCP con los nodos cuya dirección IP son 212.72.49.141 o 195.245.8.141, suponiendo por tanto que estos son los servidores de conexión de Skype.

1.1.1.2.       Supernodos Bootstrap

Se listan las direcciones IP y los números de puertos de los siete supernodos por defecto que se observaron durante un intento fallido de conexión. Estas direcciones se muestran en la Tabla 1, obteniendo el hostname y la primera entrada de la sección de autoridad, mediante una búsqueda por reverse lookup. De aquí se muestra que uno sólo de los supernodos es mantenido por Skype.
Tabla 1. Direcciones IP del Bootstrap y los hostname obtenidos por reverse lookup

1.1.1.1.       Determinación del NAT y del cortafuegos

Se supone que el cliente Skype es capaz, durante el proceso de conexión, de determinar si esta detrás de un cortafuegos o de un NAT. Basset y Schulzrinne suponen que sólo hay dos maneras de saberlo. Una posibilidad es que el cliente intercambie mensajes con su supernodo utilizando una variación de protocolo STUN. Otra posibilidad es que durante la conexión, el cliente mande y reciba datos de algunos nodos después de establecer conexión con su supernodo, suponiendo entonces que el cliente utilice la  variación del protocolo STUN para determinar que tipo de NAT o cortafuegos hay detrás.

Una vez determinado, el cliente almacena la información en el fichero ‘shared.xml’ refrescando esta información periódicamente.

1.1.1.2.       Comprobación de la ultima versión de Skype

Durante la conexión, el cliente Skype solamente envía un HTTP 1.1 GET Request al servidor Skype (skype.com) para determinar si una nueva versión está disponible. La primera línea de esta petición contiene la palabra clave ' getlatestversion’. Junto con la petición del HTTP enviada al principio del arranque, éstos son los únicos mensajes basados en texto enviados por Skype.

1.1.2.   Búsqueda de un usuario

La tecnología de búsqueda de un usuario utilizada por Skype es Global Index (GI). Mediante esta tecnología se consigue una búsqueda distribuida que garantiza la localización de un usuario que exista y que se haya conectado a Skype durante las últimas 72 horas.

Skype no es un protocolo abierto y sus mensajes están encriptados. Mientras que para la conexión se podían deducir las diferentes entidades involucradas, para la búsqueda deusuarios no es factible puesto que no se pueden seguir los pasos de los mensajes más allá del supernodo.

Un cliente Skype tiene una ventana de dialogo para la búsqueda (Figura 10). Después de introducir el usuario Skype a buscar y presionar el botón de Buscar, el cliente comienza la búsqueda.

Figura 10. Ventana de dialogo para la búsqueda de un usuario

El cliente Skype manda un paquete TCP a su supernodo (SN). A continuación el supernodo le manda al cliente una lista de ocho nodos con sus direcciones IP y sus puertos como respuesta.

Tras este intercambio, el cliente manda paquetes UDP a los ocho nodos. Si no se encuentra al usuario en estos nodos, se vuelve a establecer una conexión TCP con el supernodo, devolviéndole este las direcciones de 16 nodos, repitiendo el proceso anterior. Este proceso continúa hasta que se encuentra al usuario o hasta que se resuelva que el usuario no existe. Un ejemplo de la búsqueda viene ejemplificado en la figura 11.


Figura 11. Flujo de mensajes en una búsqueda

1.1.1.   Establecimiento de llamada

Para el establecimiento de llamada, se considera únicamente que se realiza con un usuario de la lista de contactos. Si se realizase con un usuario que no estuviera en la lista de contactos, entonces sería equivalente a una búsqueda más un establecimiento de llamada.

Cuando un usuario establece una llamada a otro usuario, ambos en las listas de contacto propias, el usuario emisor establece una conexión TCP con el usuario receptor, de manera que toda la información entre los usuarios se intercambia sobre TCP tal como se muestra en la figura 12.

Figura 12. Flujo de mensajes en un establecimiento de llamada. El número de bytes corresponden al tamaño acumulativo de los mensajes intercambiados, siendo el número entre paréntesis, el número total de mensajes enviados en esa dirección.

El intercambio inicial de mensajes entre emisor y receptor indica la existencia de un mecanismo challenge-response. El emisor también manda algunos mensajes UDP (no mostrados en la figura 12) a nodos Skype alternativos.

Durante la finalización de la llamada también se realiza intercambio de mensajes sobre TCP entre emisor y receptor. Los mensajes observados durante el intercambio se muestran en la figura 13.
Figura 13. Flujo de mensajes en una finalización de la llamada. El número de bytes corresponden al tamaño acumulativo de los mensajes intercambiados, siendo el número entre paréntesis, el número total de mensajes enviados en esa dirección.

1.1.1.   Codificación y transferencia.

En la transferencia de voz, el tráfico fluye sobre UDP en el puerto configurado en el cuadro de dialogo Opciones. El tamaño del paquete de voz varia entre 40 y 120 bytes. Para dos usuarios conectados a Internet mediante una Ethernet de 100Mb/s sin saturación, se llegan a intercambiar alrededor de 85 paquetes de voz en un segundo. El total del ancho de banda de subida y de bajada es 5 Kbytes/s, que conviene con el ancho de banda demandado por Skype que se encuentra entre 3-16 Kbytes/s. La codificación utilizada es iSAC.

1.1.2.   Mensajes de tiempo de vida

El cliente Skype refresca su conexión con el supernodo mediante mensajes TCP espaciados en el tiempo por dos minutos.

Figura 14. Flujo de mensajes para el refresco de la conexión 





1 comentario: