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
