UNIVERSIDAD POLITÉCNICA DE MADRID FACULTAD DE INFORMÁTICA

TRABAJO FINAL DE CARRERA

ESTUDIO DEL PROTOCOLO XMPP DE MESAJERÍA ISTATÁEA, DE SUS ATECEDETES, Y DE SUS APLICACIOES CIVILES Y MILITARES

Autor: José Carlos Díaz García Tutor: Rafael Martínez Olalla

Madrid, Septiembre de 2008

2

A mis padres, Francisco y Pilar, que me empujaron siempre a terminar esta licenciatura y que tanto me han enseñado sobre la vida

A mis abuelos (q.e.p.d.)

A mi hijo icolás, que me ha dejado terminar este trabajo a pesar de robarle su tiempo de juego conmigo

Y muy en especial, a Susana, mi fiel y leal compañera, y la luz que ilumina mi camino

Agradecimientos

En primer lugar, me gustaría agradecer a toda mi familia la comprensión y confianza que me han dado, una vez más, para poder concluir definitivamente esta etapa de mi vida. Sin su apoyo, no lo hubiera hecho.

En segundo lugar, quiero agradecer a mis amigos Rafa y Carmen, su interés e insistencia para que llegara este momento. Por sus consejos y por su amistad, les debo mi gratitud.

Por otra parte, quiero agradecer a mis compañeros asesores militares de Nextel Engineering sus explicaciones y sabios consejos, que sin duda han sido muy oportunos para escribir el capítulo cuarto de este trabajo.

Del mismo modo, agradecer a Pepe Hevia, arquitecto de de Alhambra Eidos, los buenos ratos compartidos alrrededor de nuestros viejos proyectos sobre XMPP y que encendieron prodigiosamente la mecha de este proyecto.

A Jaime y a Bernardo, del Ministerio de Defensa, por haberme hecho descubrir las bondades de XMPP.

Y por último, quiero enviarles un grato reconocimiento a todos mis antiguos compañeros de la Facultad de Informática y a los que coincidieron conmigo en su Club de Informática y Telemática, el Capítulo de Estudiantes de ACM, el Grupo de Modelos y Software para el Medio Ambiente (los “Adivinos del Aire” como nos llamó El País en aquel artículo sobre nuestras investigaciones), a los amigos del Laboratorio de Comunicación Oral “Robert Wayne Newcomb” y a muchos más compañeros de la promoción de 1.991 que hicieron de la FIUPM un lugar entrañable y con una ambición de excelencia académica a la que nunca debe renunciar.

José Carlos Díaz García Universidad Politécnica de Madrid Facultad de Informática

Madrid, 29 de Septiembre de 2.008

I

II

Índice general

1. Introducción ...... 1 2. Objetivos ...... 5 3. Estado del arte ...... 7 3.1. Fundamentos generales de la MI ...... 7 3.2. Antecedentes ...... 8 3.2.1. Talkomatic y Term- ...... 9 3.2.2. Talk de ...... 12 3.2.2.1. Orígenes ...... 12 3.2.2.2. Descripción técnica ...... 13 3.2.3. Relay Chat (IRC) ...... 14 3.2.3.1. Orígenes ...... 14 3.2.3.2. Descripción técnica ...... 15 3.2.3.3. Clientes ...... 18 3.2.3.4. Servidores ...... 18 3.2.4. ICQ y el comienzo de la era moderna de la MI...... 19 3.2.4.1. Fundamentos del protocolo OSCAR ...... 20 3.2.4.2. Formato de los paquetes ...... 21 3.2.4.3. Funcionamiento general del protocolo ...... 28 3.2.4.4. Servicios de mensajería y estructura de los mensajes ...... 29 3.2.5. Jabber y XMPP ...... 32 3.2.5.1. Introducción ...... 32 3.2.5.2. Orígenes ...... 33 3.3. Fundamentos técnicos de XMPP ...... 35 3.3.1. Arquitectura general del protocolo ...... 35 3.3.2. Direccionamiento ...... 37 3.3.3. Estructura de la comunicación basada en XML: Streams y Stanzas ...... 38 3.3.3.1. Negociación de la comunicación: XML Streams ...... 39 3.3.3.2. TLS: La seguridad en la capa de transporte ...... 40 3.3.3.3. Autenticación con SASL ...... 46 3.3.3.4. Comandos: XML Stanzas ...... 52 3.3.4. La mensajería Instantánea en XMPP ...... 53

III

3.3.4.1. Direccionamiento de los mensajes ...... 53 3.3.4.2. Estructura de los mensajes ...... 54 3.3.4.3. Listas de Privacidad ...... 59 3.3.5. La Presencia en XMPP ...... 60 3.3.5.1. El concepto de presencia ...... 60 3.3.5.2. Descripción técnica del protocolo de presencia ...... 62 3.3.5.3. Cambios en el estado de presencia de los clientes ...... 63 3.3.5.4. Suscripciones de presencia ...... 64 3.3.5.5. Manejo del Roster ...... 67 3.3.5.5.1. Descarga del roster ...... 69 3.3.5.5.2. Actualización del roster: inserción, modificación y borrado ...... 71 3.3.5.6. Prioridades de los recursos ...... 73 3.3.5.7. Presencia dirigida ...... 74 3.3.5.8. Presencia final ...... 75 3.3.5.9. Ejemplos de presencia ...... 75 3.3.6. Consideraciones de seguridad en XMPP ...... 80 3.3.7. Extensiones del protocolo: JEPs/XEPs ...... 81 3.3.7.1. Introducción ...... 82 3.3.7.2. Tipos de XEPs ...... 84 3.3.7.3. Algunas de las XEPs más importantes ...... 84 3.3.8. Ejemplo de una sesión XMPP ...... 88 3.3.8.1. Conectar con el servidor de GMail e iniciar sesión ...... 88 3.3.8.2. El mecanismo de autenticación segura de Gtalk ...... 97 3.3.8.3. Enviar un mensaje a uno de los contactos ...... 100 3.3.8.4. Cambiar el estatus de presencia ...... 101 3.3.8.5. Asociar un Nuevo grupo a un contacto del roster ...... 102 3.3.8.6. Enviar un fichero a un contacto del roster ...... 103 3.3.8.7. Cerrar la sesión ...... 104 3.3.9. Roadmap...... 104 3.3.10. Software existente ...... 106 3.3.10.1. Clientes XMPP ...... 106 3.3.10.2. Servidores XMPP ...... 110 3.3.10.3. Librerías para el desarrollo de software...... 113

IV

3.3.11. Posibilidades del protocolo XMPP ...... 115 3.3.11.1. Transporte entre Jabber/XMPP y otros servidores de MI ...... 116 3.3.11.2. Robots XMPP ...... 118 3.3.11.3. XMPP como facilitador de los Cloud Services ...... 119 3.3.11.4. La capacidad P2P ...... 120 4. Aplicaciones del protocolo XMPP ...... 123 4.1. Introducción ...... 123 4.2. Aplicaciones civiles ...... 124 4.2.1. Aplicaciones en el área de la salud ...... 125 4.2.1.1. Sistemas Integrados en el Entorno ...... 125 4.2.1.2. Sistemas de localización y alerta por MI ...... 128 4.2.2. Aplicaciones en el área de finanzas, seguros y comercio ...... 130 4.2.3. Aplicaciones en el área de cooperación y ONGs ...... 131 4.2.4. El Proyecto de Investigación Hesperia ...... 134 4.2.4.1. Resumen del Proyecto ...... 134 4.2.4.2. Líneas y objetivos de investigación ...... 135 4.2.4.3. Utilidad de la mensajería instantánea y el protocolo XMPP ...... 138 4.3. Aplicaciones para la defensa y la seguridad ...... 139 4.3.1. Introducción a las necesidades de las fuerzas armadas ...... 139 4.3.2. Los sistemas NEC ...... 141 4.3.3. La superioridad en la gestión de la inteligencia ...... 145 4.3.4. Estudios en contra y a favor del empleo de MI en el nivel táctico...... 148 4.3.5. Aspectos de interés militar del protocolo XMPP ...... 151 4.3.5.1. XEP-0045: Multi-User Chat (MUC) ...... 151 4.3.5.2. XEP-0060: Publicación-Subscripción ...... 155 4.3.5.3. XEP-0080: Geolocalización de Usuarios ...... 159 4.3.5.4. XEP-0124: HTTP Binding ...... 159 4.3.5.5. XEP-0138: Compresión de Streams ...... 160 4.3.5.6. XEP-0116: Cifrado de Sesiones ...... 161 4.3.5.7. XEP-0009: Jabber-RPC ...... 161 4.3.5.8. XEP-0072: SOAP sobre XMPP...... 162 4.3.5.9. XEP-0171: Traducción de Idiomas ...... 162 4.3.6. Referencias ...... 163 4.3.6.1. Interconexión de cuerpos de seguridad y emergencias: CAPWin ... 163

V

4.3.6.2. Interoperabilidad de Simuladores ...... 165 4.3.6.3. Otros ejemplos ...... 167 5. Conclusiones y trabajo futuro ...... 171 6. Bibliografía ...... 175 7. Apéndices ...... 181 Apéndice A. Lista de Extensiones del Protocolo XMPP ...... 181 Apéndice B. Lista de Extensiones del Protocolo XMPP ...... 189 Apéndice . Clientes MI clasificados por plataforma ...... 197 Apéndice D. Clientes MI con capacidad multiprotocolo ...... 204 Apéndice E. Comparativa de Clientes MI ...... 208 Tabla 1/2 ...... 208 Tabla 2/2 ...... 212

VI

Índice de ilustraciones

Ilustración 1. Predicción de usuarios globales de MI hasta 2010 ...... 3

Ilustración 2. Terminal PLATO ...... 10

Ilustración 3. Anuncio de 1979 del sistema PLATO ...... 11

Ilustración 4. Arquitectura del sistema TALK ...... 13

Ilustración 5. Arquitectura de IRC ...... 16

Ilustración 6. Topología de una red IRC ...... 17

Ilustración 7. Arquitectura del sistema AIM y el protocolo OSCAR ...... 21

Ilustración 8. Formato de un paquete FLAP del protocolo OSCAR ...... 22

Ilustración 9. Formato de un paquete SNAC del protocolo OSCAR ...... 23

Ilustración 10. Formato de los paquetes en el protocolo OSCAR ...... 28

Ilustración 11. Ejemplo de paquete SNAC conteniendo un mensaje de un cliente .... 31

Ilustración 12. Hitos en la breve historia de los protocolos Jabber y XMPP ...... 33

Ilustración 13. Federación de redes MI a través de gateways ...... 35

Ilustración 14. Arquitectura de comunicaciones del protocolo XMPP ...... 36

Ilustración 15. Posibilidades de uso de TLS en el cifrado de datos ...... 42

Ilustración 16. Esnifando datos transmitidos como texto en claro ...... 43

Ilustración 17. Funcionamiento de la negociación de TLS ...... 45

Ilustración 18. Negociación del protocolo SASL ...... 49

Ilustración 19. Estados del ciclo de vida de un XEP ...... 83

Ilustración 20. Vista general de una sesión XMPP ...... 88

Ilustración 21. Arquitectura de una red XMPP ...... 106

Ilustración 22. Federación de redes AMQP y XMPP ...... 117

VII

Ilustración 23. Detalle de bajo nivel del gateway RabbitMQ que tiene el servidor XMPP ...... 117

Ilustración 24. Arquitectura de los servicios de "nube" ...... 119

Ilustración 25. Arquitectura federada cliente-servidor ...... 126

Ilustración 26. Arquitectura de alto nivel de la solución de Labidi et al. (2007) ..... 127

Ilustración 27. Aplicación de XMPP y la tecnología de Redes de Área Personal a la medicina deportiva ...... 128

Ilustración 28. Arquitectura del sistema noruego MediMob de MI para hospitales129

Ilustración 29. Aspecto del interfaz del cliente XMPP de Net Energy Exchange .... 131

Ilustración 30. Arquitectura de alto nivel del Proyecto Sahana...... 133

Ilustración 31. Aproximación NEC/NCW al campo de batalla del futuro ...... 142

Ilustración 32. Representación de los nodos de publicación/suscripción ...... 156

Ilustración 33. Arquitectura de un bus de datos pub/sub ...... 158

Ilustración 34. Detalle del interfaz de usuario de CapWIN ...... 164

Ilustración 35. Ejemplo de un mensaje DIS-XML ...... 166

VIII

Índice de tablas

Tabla 1. Familias de paquetes SNAC del protocolo OSCAR ...... 26

Tabla 2. Formato de un paquete TLV del protocolo OSCAR ...... 27

Tabla 3.- Errores más comunes del núcleo de Jabber ...... 58

Tabla 4. Clientes de protocolo único Jabber/XMPP de software libre ...... 107

Tabla 5. Clientes monoprotocolo XMPP propietarios y gratuitos ...... 108

Tabla 6. Clientes de MI multiprotocolo compatibles con Jabber/ XMPP ...... 110

Tabla 7. Implementaciones más importantes de XMPP ...... 113

IX

X

Resumen

Desde la década de 1.960 aparecieron los primeros sistemas de mensajería instantánea (en adelante MI), en los ámbitos de la formación asistida por ordenador y el soporte técnico a usuarios. Estos sistemas fueron evolucionando y mutando, dando origen a su vez a nuevas soluciones y tecnologías hasta llegar a nuestros días, donde tenemos decenas de soluciones comerciales o abiertas para el mismo problema: el envío de mensajes de texto y multimedia de un usuario a otro o a otros, y todo ello a través de redes IP, haciendo un uso eficiente de los recursos disponibles, en tiempo real, sin renunciar a requisitos de seguridad en del tráfico de mensajes, rendimiento, escalabilidad hasta Internet.

En los años recientes, además, a dichas necesidades de comunicación se ha unido otra: la presencia. Además de comunicarse, los usuarios de redes de mensajería instantánea y algunas otras soluciones de comunicaciones unificadas, requieren conocer el estado de disponibilidad o estado de la presencia que tienen el resto de los usuarios de su red con los que se comunica, así como comunicar su propia presencia aquellos a aquellos usuarios que han pedido ser informados.

La especificación base de Jabber (que más tarde se convertiría en el protocolo XMPP1) fue inventada en 1998 por Jeremie Miller y tomada como protocolo por la comunidad open-source en 1999, donde ha ido creciendo y evolucionando hasta nuestros días. Su originalidad consistió en que empleaba estándares abiertos como XML y que, por definición, era un protocolo extensible, lo que le ha dado mucho recorrido a lo largo de los últimos diez años.

El protocolo Jabber de mensajería instantánea y presencia era una tecnología abierta basada en XML, para la comunicación en tiempo real, lo cual proporcionaba potencialmente un amplio rango de aplicaciones, incluyendo: mensajería instantánea, presencia, negociación de múltiples medios, pizarras compartidas, colaboración, middleware ligero, distribución de datos en entornos distribuidos, sindicación de contenidos, y enrutamiento XML genérico, entre otras.

1 eXtensible Messaging and Presence Protocol

XI

Hasta la fecha, Jabber y XMPP han sido los proyectos más aceptados como alternativas libres serias al sistema MSN Messenger de Microsoft, al AIM de AOL, al Yahoo! Messenger y, por supuesto al ICQ. Y aunque XMPP todavía es un protocolo algo desconocido, está creciendo más cada día, gracias a los usuarios y, por supuesto, a , que ha creado , un cliente de mensajería instantánea que maneja el protocolo XMPP

Este trabajo se ha centrado en describir y comentar el protocolo XMPP a nivel de arquitectura, esquema de direccionamiento, gramática de los mensajes del protocolo, funcionamiento del establecimiento de las sesiones, aspectos y mecanismos de seguridad de las sesiones y sus datos, mecanismos de comunicación de la presencia, manejo del roster y la extensibilidad del protocolo, para poder ofrecer al lector la base teórica necesaria para abordar la discusión que incluye esta obra sobre sus posibles usos.

En resumen, las características de XMPP más importantes son: - Protocolo abierto y fundado sobre estándares IETF - Sus extensiones son múltiples y controladas por una fundación que vigila el desarrollo del estándar - XML nativo - Admite esquemas de federación de redes, pudiendo interoperar con otras redes de MI públicas como Google Talk y propietarias como IBM Lotus Sametime - Muchas implementaciones abiertas de servidores, clientes y librerías; para toda clase de plataformas y lenguajes - Capacidad para utilizar HTTP o TCP como protocolos de transporte de los mensajes - Seguridad extremo a extremo TLS que permite cifrar los mensajes empleando diferentes algoritmos como RSA y DSS - Posibilidad de comprimir los mensajes mediante los mecanismos de compresión de TLS - Buena alternativa cuando se trata de hacer multicasting de datos - Buena alternativa a los modelos de publicación-suscripción comerciales

XII

- Capacidad de utilizarlo como protocolo de transporte para mensajes SOAP, de manera alternativa a SMTP y HTTP - Capacidad de funcionar como una cola de mensajes distribuida - Capacidad de utilizarse como protocolo de transporte para la negociación de sesiones RTP de streaming de video y audio, gracias a la especificación .

En este trabajo aparecen citados decenas de proyectos civiles y militares que han empleado XMPP como espina dorsal de sus comunicaciones.

Es de especial interés en esta obra el análisis de necesidades de la Defensa Militar respecto a los nuevos problemas y retos tecnológicos a los que se están enfrentando todos los ejércitos y armadas del mundo. Este análisis, explica por qué XMPP puede hacer frente a iniciativas como NNEC de la OTAN, que persigue la interconexión de todas las unidades tácticas presentes en el campo de batalla, cosa que aún no la ha permitido la tecnología militar existente.

Entre los casos civiles que se comentan en este trabajo, el Autor destaca aquellos que tienen que ver con aplicaciones médicas como las monitorización de redes de sensores vitales o los sistemas de alerta y notificaciones, las aplicaciones financieras. Una mención especial recibe el proyecto de investigación tecnológica más importante realizado en España para desarrollar tecnologías en el ámbito de la Seguridad Nacional: el proyecto Hesperia, en el que participa la Universidad Politécnica de Madrid.

A modo de conclusión, XMPP es un protocolo con pasado, presente y futuro que ha sido subestimado por gran parte de la comunidad de desarrollo y ha sido parcialmente ignorado por todo el mundo. En cambio, a la vista de los hechos y de toda la literatura existente, se permite adivinar un futuro más próspero a XMPP que, poco a poco, se está convirtiendo en una pieza fundamental de muchos de los servicios de la Web 2.0 y que está demostrando pasar las pruebas más exigentes en el entorno de la Defensa Militar.

XIII

1. INTRODUCCIÓN

1. ITRODUCCIÓ

En 1969, Peter Drucker, uno de los autores más importantes de la literatura moderna del “management”, en su libro más conocido “La era de la discontinuidad” escribió una sección sobre “la Sociedad del Conocimiento”, basándose en una serie de datos y proyecciones económicas de Fritz Machlup2 (uno de los primeros autores en acuñar la expresión "Sociedad de la Información"). Drucker se interesó siempre por la creciente importancia de los trabajadores que trabajaban con sus mentes más que con sus manos, lo que vendría a denominarse posteriormente Trabajadores del Conocimiento. A diferencia del trabajador manual, el Trabajador del Conocimiento es dueño de los medios de producción que son precisamente sus conocimientos.

Actualmente vivimos en la era de los Trabajadores del Conocimiento. Muchos de nosotros lo somos en las organizaciones para las que trabajamos, bien sean AA.PP. o empresas.

Trabajamos exclusivamente con información y para ello necesitamos emplear una amplia variedad de herramientas y sistemas de comunicaciones. Estos sistemas han ido evolucionando a medida que se han planteado nuevos retos de gestión en las organizaciones con la mejora de la competitividad y la productividad siempre presentes.

La Mensajería Instantánea (en adelante, MI) es precisamente la herramienta de comunicación entre Trabajadores del Conocimiento que más se está extendiendo por sus bondades, que nos permiten intercambiar, compartir o distribuir información de forma fiable, inmediata y segura. La MI está creciendo más rápido que el uso del teléfono y el teléfono móvil, más rápido que el uso del e-mail. A pesar de que se tiende a asociar esta forma de comunicación con un uso adolescente, la mensajería instantánea está cada vez

2 Economista estadounidense de origen austríaco (Wiener Neustadt, Austria, 1902- 1983). Establecido en EE UU a partir de 1960, estudió la naturaleza de los factores de producción y las motivaciones empresariales.

1 ESTUDIO DEL PROTOCOLO XMPP DE MENSAJERÍA INSTANTÁNEA

mejor establecida en el mundo de la empresa como una eficiente herramienta de colaboración y la realidad demuestra que usuarios online de todas las edades confían en ella como una tecnología de comunicación clave.

Para muchos trabajadores del conocimiento, la mensajería instantánea es ya una necesidad tan crítica como el acceso a un teléfono o al correo electrónico.

Un factor decisivo en la rápida propagación de este tipo de mensajería lo ha constituido el hecho de que fuera muy popular, desde finales de los años 90, entre los adolescentes y la población más joven. A medida que dicha generación de jóvenes se ha ido incorporando al mundo laboral, han traído consigo sus medios preferidos de comunicación, entre los que ya no está el teléfono, o el correo electrónico tradicionales. En el mundo actual, la MI rivaliza protagonismo con el E-Mail, siendo mayores las ventajas que aporta a la comunicación:

- Posibilidad de comunicarse a través de redes IP entre dispositivos tanto fijos como móviles.

- Comunicación basada en voz, video y datos

- Incorporación de los últimos estándares de seguridad, tanto en el cifrado de datos como la autenticación del usuario

- Permitir la comunicación a través de servidores públicos, privados o P2P dependiendo de cada solución de mensajería y el protocolo de MI empleado.

- Permitir mensajes offline, cuando los destinatarios están desconectados

- Posibilidad de habilitar un control de presencia de usuarios

- Capacidad de acceder a herramientas y servicios

- Capacidad de distribución de nuevos productos y servicios

Por tanto, se puede decir que, en cierto modo, la MI es al correo electrónico tradicional lo que el video a la fotografía.

De la misma manera que el despliegue del correo electrónico en las corporaciones a principios de la década de los 90 ha demostrado ser una de las contribuciones

2 1. INTRODUCCIÓN

incuestionables a la mejora de las relaciones y los negocios entre las personas y entre las organizaciones, muchos analistas consideran que ya está ocurriendo un fenómeno similar con la mensajería instantánea.

Algunos analistas de Gartner3 predicen que a finales de 2011, la mensajería instantánea se convertirá en la herramienta por excelencia para las comunicaciones de voz, vídeo y texto en tiempo real con fines de negocio. Según la consultora, las organizaciones que aún no la hayan incorporado a sus procesos críticos de negocio, deberían de comenzar a planteárselo.

13,43% 12,65% 9,06% 700 7,97%

600 650 552 602 490 500 432

400

300

200

100 0

2006 2007

2008 ususarios deNº (millones) 2009 2010 Años (los datos de 2007 a 2010 son estimados)

Ilustración 1. Predicción de usuarios globales de MI hasta 20104 Todo ello hará que, de cumplirse las previsiones (Gartner, 2007), en 2013 más del 95% de los trabajadores de las principales organizaciones globales utilicen MI como principal interfaz para las comunicaciones en tiempo real. En cuanto al valor del mercado mundial de MI empresarial, la firma estima que crecerá desde los 267 millones de dólares que generó en 2005 hasta los 688 millones de dólares en 2010.

3 Gartner Inc. Es una de las principales y más prestigiosas compañías de consultoría y análisis de mercados del mundo. Sus estudios y análisis multisectoriales se toman como referencia en el mundo de los negocios. Ver http://www.gartner.com. 4 Fuente: Radicati Group

3 ESTUDIO DEL PROTOCOLO XMPP DE MENSAJERÍA INSTANTÁNEA

Hoy en día, las tecnologías disponibles y la oferta de productos comerciales de MI existente permiten ofrecer una gama de soluciones muy amplia a las necesidades de comunicación online y offline de las organizaciones y las personas que las forman.

En su Trabajo Final de Carrera, el Autor, que dispone de 10 años de experiencia profesional en el campo de la innovación y las nuevas tecnologías, ha podido explorar a fondo uno de los protocolos de MI más extendidos en el mundo: el protocolo XMPP. La experiencia y bagaje del Autor (muy ligada a las Administraciones Públicas y la industria de la Defensa), le ha permitido poner en el contexto militar esta tecnología, ilustrando el estado del arte alcanzado con cada programa o proyecto en el que se ha utilizado tecnología XMPP.

4 2. OBJETIVOS

2. OBJETIVOS

Este trabajo pretende ofrecer, a los lectores interesados en la materia, una introducción a la mensajería instantánea, su historia, sus tecnologías (en especial, XMPP) y sus aplicaciones actuales, así como la previsión de su evolución en el futuro.

Hacerlo desde un enfoque divulgativo pero riguroso es otro de los objetivos que se propuso el Autor al comprobar, durante su investigación previa del Estado del Arte, que no existía demasiada literatura rigurosa y documentada en la que basarse, y mucho menos que integrara en un solo texto todo aquello que representa la mensajería instantánea como tecnología capacitadora de las relaciones entre personas, entre aplicaciones y entre ambas, a través de la cada día más imprescindible Red de Redes.

Un objetivo secundario de este texto que se conseguirá o no, a partir de su difusión en el Archivo Digital de la Universidad Politécnica de Madrid y medios similares, consiste en dar a conocer XMPP y su entorno a la comunidad de ingenieros de sistemas e ingenieros de software que dedican sus vidas profesionales a hacer del nuestro un mundo mejor, conectado y más justo y seguro.

Igualmente importante es descubrir al público general algunas de las utilidades de XMPP menos conocidas, especialmente aquellas que tienen que ver con la Defensa Militar y la Seguridad Nacional, de las que muy poco se ha escrito.

Y por último, otro de los objetivos perseguidos con este trabajo de investigación es la selección cuidadosa de referencias bibliográficas para que este trabajo sea un punto de partida muy ventajoso para el estudioso de la mensajería instantánea en todas sus formas.

5 ESTUDIO DEL PROTOCOLO XMPP DE MENSAJERÍA INSTANTÁNEA

6 3. ESTADO DEL ARTE

3. ESTADO DEL ARTE

3.1. Fundamentos generales de la MI

La mensajería instantánea es un sistema de comunicación que permite la transmisión de datos en tiempo real entre grupos cerrados de usuarios, incluso cuando el destinatario no está conectado.

La mensajería instantánea requiere el uso de un cliente informático que realiza el servicio de MI y que se diferencia del correo electrónico en que las conversaciones se realizan en tiempo real. Existe una gran variedad de clientes de MI (también llamados mensajeros instantáneos) en el mercado (gratuitos o de pago, como aplicación de escritorio o web).

La gran innovación de la MI es el agrupamiento de todos estos sistemas en uno solo. Además, poco a poco, la MI ha ido incorporando mejoras como la presencia, transferencia de ficheros, conversaciones con voz y video, pizarras compartidas, etc.

Además, un sistema de MI nos ofrece un nombre único en la red, característica que no tenían los primeros Chat de Internet. La MI nos ofrece un nombre único en la red, y nos permite identificarnos bajo una contraseña para que nadie pueda pasarse por nosotros. Gracias a esta innovación podemos agregar nuestros contactos en el sistema de MI para poder hablar con ellos sin necesidad de acordarnos de sus identificadores.

Esto a su vez conlleva a que, gracias al protocolo de presencia, se puede conocer en cada momento el estado de un contacto, es decir, cada usuario podrá estar conectado o no. De estar conectado, podrá adoptar diferentes estados como pueden ser, “en línea”, “ocupado” o “ausente”.

Además la MI no sirve únicamente para la comunicación entre personas, también permite la comunicación entre ordenadores, así máquinas autónomas como bien pueden ser estaciones meteorológicas pueden comunicarse con un ordenador central para comunicar un cambio en su estado, o el ordenador central ir recorriendo todas las estaciones y preguntándoles por sus variables de temperatura, presión… Esto permite

7 ESTUDIO DEL PROTOCOLO XMPP DE MENSAJERÍA INSTANTÁNEA

un diálogo entre un ordenador central y una estación meteorológica, y así podemos encontrar muchos más usos en campos como la robótica, sistemas expertos de Inteligencia Artificial, B2B, juegos, domótica…

Los mensajeros instantáneos más utilizados son ICQ, Yahoo! Messenger, , AIM (AOL Instant Messenger) y Google Talk (que usa el protocolo abierto Jabber). Estos servicios han heredado algunas ideas del viejo, aunque aún popular, sistema de conversación IRC. Cada uno de estos mensajeros permite enviar y recibir mensajes de otros usuarios usando los mismos software clientes, sin embargo, últimamente han aparecido algunos clientes de mensajerías que ofrecen la posibilidad de conectarse a varias redes al mismo tiempo (aunque necesitan registrar usuario distinto en cada una de ellas). También existen programas que ofrecen la posibilidad de conectarse a varias cuentas de usuario a la vez como MSN.

La mayoría de estos mensajeros usan las redes propietarias de las diferentes clases de software que ofrecen este servicio. Por otra parte, existen programas de mensajería instantánea que utilizan protocolos abiertos como Jabber, con un conjunto descentralizado de servidores.

3.2. Antecedentes

Hay que retroceder casi 40 años en el tiempo para encontrar las primeras aplicaciones de mensajería instantánea: Talkomatic y Term-Talk.

Pero hubo otras aplicaciones de MI pioneras como lo la aplicación TALK de UNIX (a comienzos de los años 80), el archiconocido protocolo IRC de internet (en los 90), el revolucionario concepto de ICQ (finales de los 90) y el relevo de éste tomado por Messenger (a comienzos del año 2000). Aplicaciones que en la actualidad han demostrado ser más utilizadas casi que el propio correo electrónico, visto que mantienen un nivel de interacción más efectivo que dichas herramientas.

La primera forma de mensajería instantánea fue la implementación en el sistema PLATO usado al principio de la década de 1970. Más tarde, el sistema Talk implementado en UNIX/ comenzó a ser ampliamente usado por ingenieros y académicos en las décadas de 1980 y 1990 para comunicarse a través de internet. Años

8 3. ESTADO DEL ARTE

más tarde, ICQ fue el primer sistema de mensajería instantánea para ordenadores con sistema operativo distinto de UNIX/LINUX en noviembre de 1996. A partir de su aparición, un gran número de variaciones de mensajería instantánea han surgido y han sido desarrollados en paralelo en otras partes, cada aplicación teniendo su propio protocolo. Esto ha llevado a los usuarios a tener que usar un cliente para cada servicio simultáneamente para estar conectado a cada red de mensajería. Alternativamente, han surgido programas multicliente que soportan varios protocolos como Gaim o .

Recientemente, algunos servicios de mensajería han comenzado a ofrecer telefonía IP (VoIP), videoconferencia, que permiten integrar capacidades de transmitir audio y vídeo junto con las palabras.

3.2.1. Talkomatic y Term-Talk

Ambas fueron dos de las muchas aplicaciones desarrolladas bajo el sistema operativo de tiempo compartido PLATO (Programmed Logic for Automated Teaching Operations) que fue a su vez el primer sistema de colaboración multiusuario y de enseñanza asistida por ordenador.

PLATO se desarrolló en 1962 en la Universidad de Illinois. Tras 14 años de desarrollo con financiación de la Marina de los Estados Unidos, la empresa Control Data Corporation (CDC), constructora de supercomputadoras, adquirió los derechos de comercialización y la marca del software PLATO.

A comienzos de la década de 1970, un gran número de empresas comenzaron a desarrollar software para los mainframe que fabricaba CDC. Durante los años 70, se creó una gran variedad de courseware y todo tipo de software de colaboración relacionado con la teleenseñanza (se desarrollaron aplicaciones de correo electrónico, juegos interactivos multijugador, foros y chats), que se emergía como alternativa innovadora para la formación en el ejército, las universidades y las grandes corporaciones, como la Boeing o Lockheed Martin, que podían permitirse pagar los más de 12.000 USD que costaba cada terminal y los más de 50 USD/hora que costaba la conexión a los mainframes de CDC. Durante esa década, PLATO se extendió por todo

9 ESTUDIO DEL PROTOCOLO XMPP DE MENSAJERÍA INSTANTÁNEA

el mundo, constituyendo la primera gran comunidad conectada, veinte años antes del debut público de Internet.

En 1978, el sistema PLATO había evolucionado hasta terminales de alta resolución de 512x512 pixeles, pantalla táctil de 16x16 sensores infrarrojos, teclado, impresora matricial de gráficos y comunicaciones mediante un modem de 1200 baudios de ancho de banda. Con la llegada de los PC, se desarrollaron emuladores de terminal para los IBM PC, Atari, Zenith Z-100 y muchos otros microordenadores míticos. La conexión a Homelink, la red de servicios de CDC, se abarató hasta los 5 USD/hora, lo que hizo crecer aún más el tamaño de la comunidad de usuarios en el mundo.

Uno de los programas disponibles sobre PLATO que más éxito tuvo fue Talkomatic (1973, Doug Brown), un programa que permitía a un grupo de personas mantener, en tiempo real, conversaciones simultáneas basadas en mensajes de texto.

La magia de Talkomatic consistía en que transmitía los caracteres instantáneamente, a medida que los usuarios tecleaban, en lugar de esperar a completar una línea de texto. La pantalla se dividía en varias ventanas

Ilustración 2. Terminal PLATO horizontales, una para cada participante en la conversación. Esto permitía que los mensajes se fueran componiendo en tiempo real a medida que los usuarios tecleaban sus mensajes.

A medida que fue evolucionando el programa, se fueron incorporando nuevas características tales como el soporte de múltiples canales, pudiendo cada canal soportar hasta 5 usuarios y un número ilimitado de monitores que podían ver pero no escribir. Existían canales libres que se dejaban abiertos para ser utilizados por cualquier usuario

10 3. ESTADO DEL ARTE

de la red aunque una vez dentro, estos podían proteger el canal, deshabilitando la monitorización y pudiendo elegir a quien admitir en la conversación.

Talkomatic fue un éxito inmediato aunque nunca fue oficialmente parte del sistema PLATO y ya en aquellos años, los administradores de sistemas detectaban usos frívolos de esta aplicación. Al no existir forma de de contactar con un usuario específico de la red para conversar con él a través del programa, no podía erigirse como sustituto del teléfono. La gente se enganchaba a un canal e intercambiaba mensajes con cualquiera que se dejase caer por allí.

Ilustración 3. Anuncio de 1979 del sistema PLATO Sin embargo, la popularidad de la aplicación fue tal que CDC decidió implementar un sistema de mensajería instantánea mejorado que se conoció con el nombre de “TERM-TALK”. Una conversación “term-talk” se limitaba a dos personas, pero tenía sus propias ventajas: se podía localizar y contactar a un usuario concreto con el que quisiéramos hablar, y utilizar este programa de chat sin tener que cerrar la aplicación que estuviéramos utilizando. La persona recibiría un aviso luminoso en forma de

11 ESTUDIO DEL PROTOCOLO XMPP DE MENSAJERÍA INSTANTÁNEA

mensaje parpadeante en la parte inferior de su pantalla, identificando al llamante y ofreciendo la opción a contestar. Si se aceptaba, la parte inferior de la pantalla se transformaba en una ventana del tipo de las que Talkomatic empleaba para las conversaciones, reservando en este caso dos líneas a tal efecto. Las invitaciones podían declinarse, comunicando explícitamente un estado de “terminal ocupado” o simplemente ignorarse.

Una de las últimas características que fueron añadidas fue la capacidad de conmutar a un modo “monitorizado” en el que el usuario podía compartir su pantalla con el resto de usuarios, lo que permitía al usuario que conmutaba a tal estado moverse libremente por el sistema PLATO, ejecutando aplicaciones, editando ficheros, etc., mientras mantenía una ventana de conversación con el otro usuarios, que podía observar lo que hacía el primero y, mediante el Chat, ofrecerle soporte remoto.

3.2.2. Talk de UNIX

3.2.2.1. Orígenes

Talk era un programa de chat originalmente utilizado para la comunicación en tiempo real entre diferentes usuarios de un ordenador multiusuario ejecutando el sistema operativo UNIX. Eventualmente, se utilizaba para establecer conversaciones entre usuarios cuyos terminales se conectaban a diferentes máquinas. Talk estuvo disponible para los primeros DEC PDP-11, a comienzos de la década de 1970.

Al programa Talk le siguieron talk e Ytalk. Ytalk fue el primero que permitió conversaciones entre más de dos usuarios. Todos esos programas funcionaban dividiendo la pantalla en secciones diferente, una por cada participante en la conferencia de texto. Unos de los principales problemas de este tipo de interfaz consistían en la dificultad de establecer un orden en las frases intercambiadas por cada participante. Además, estos programas transmitían los caracteres tal cual se iban tecleando por los participantes, lo que podía comprometer en ocasiones a los participantes.

A principios de los años 90, existió un exploit o programa maligno llamado Flash que empleaba a su vez el programa Talk para enviar comandos de terminal a los ordenadores

12 3. ESTADO DEL ARTE

de sus víctimas, aprovechando que cuando un usuario recibía una invitación a conversar con Talk, el nombre de la persona se mostraba en la pantalla del destinatario y esto, debido a un fallo de diseño del programa, permitía enviar toda clase de comandos de terminal que se ejecutaban en destino. Nacieron así los primeros troyanos que se aprovechaban de la mensajería instantánea como vehículo para la penetración ilícita en otras computadoras.

3.2.2.2. Descripción técnica

A nivel de arquitectura, Talk utilizaba el protocolo UDP para negociar las conexiones entre los dos extremos para, luego, emplear un socket persistente TCP como canal de transmisión de los mensajes entre los participantes.

Ilustración 4. Arquitectura del sistema TALK Talk se compone de un cliente y un servidor. En resumen, el protocolo de negociación de la sesión funciona así:

1) El usuario que origina la llamada ejecuta el cliente talk y marca la dirección del destinatario (destino@servidor) para ser contactado.

2) El cliente talk del llamante, contacta vía UDP con el servidor talk del usuario destino

3) El cliente talk del llamante, envía a su servidor por UDP el número de puerto TCP que deberá emplearse en la comunicación

4) El servidor del destinatario, señaliza a su cliente que existe una llamada desde origen@servidor.

13 ESTUDIO DEL PROTOCOLO XMPP DE MENSAJERÍA INSTANTÁNEA

5) El usuario destino acepta o no la llamada. Si la acepta, inicia el cliente de talk y elige a qué usuario y host va a responder.

6) El cliente del usuario destino pregunta por UDP al servidor del llamante el número de puerto TCP por el que desea recibir los mensajes

7) El cliente del usuario llamante envía por UDP al cliente destino el número de puerto TCP especificado en el paso 3.

8) El cliente destino establece un socket persistente TCP contra el cliente del llamante.

9) La conexión bidireccional queda establecida.

3.2.3. (IRC)

3.2.3.1. Orígenes

IRC (Internet Relay Chat) es otro protocolo de comunicación en tiempo real basado en texto, que permite la conferencia de texto entre dos o más personas y que está clasificado dentro de la Mensajería instantánea. Las conversaciones se desarrollan en los llamados canales de IRC, que pueden ser locales al servidor al que se conectan los clientes o no. Es un sistema de charlas ampliamente utilizado por personas de todo el mundo.

Los usuarios del IRC utilizan una aplicación cliente para conectarse con un servidor, en el que funciona una aplicación IRCd (IRC o servidor de IRC) que gestiona los canales y las conversaciones.

Hay canales que están disponibles en toda la red de IRC y otros que sólo son locales al servidor al que se conecta directamente un cliente. Los canales y los usuarios tienen modos, los cuales son un tipo de atributos que especifican el modo en que operan los canales, así como las características de los usuarios de dichos canales.

IRC fue creado por (Finlandia, 1967) en agosto de 1988 con el motivo de reemplazar al programa MUT (Multi User Talk) en un BBS llamado OuluBox en Finlandia. Oikarinen se inspiró en el Bitnet Relay Chat el cual operaba en la red Bitnet.

14 3. ESTADO DEL ARTE

Fue documentado formalmente por primera vez en Mayo de 1993 por el RFC 1459, y ha evolucionado constantemente desde entonces, hasta los presentes RFC 2810, RFC 2811, RFC 2812 y RFC 2813.

El IRC ganó popularidad cuando fue utilizado en el intento de golpe de estado en la Unión Soviética de 1991 para informar a través de un periodo de censura en los medios. Fue utilizado de similar manera por los Kuwatíes durante la Invasión a Irak.

3.2.3.2. Descripción técnica

IRC es un Protocolo de red que utiliza TCP así como opcionalmente SSL. Un servidor de IRC se puede conectar a otros servidores IRC para expandir la red IRC. Los usuarios acceden a las redes de IRC conectando un cliente a un servidor. Existen muchas implementaciones de clientes IRC así como de servidores. La mayoría de los servidores IRC no necesitan que los usuarios se registren, aunque de cualquier manera se necesita que los usuarios establezcan un alias antes de conectarse.

El protocolo IRC se basa en el modelo cliente-servidor y es adecuado para funcionar sobre varias máquinas de un modo distribuido. Una configuración típica involucra un proceso único (el servidor) que actúa como punto central para los clientes (u otros servidores) que se conectan a él, realizando el multiplexado y envío de mensajes necesarios así como otras funciones.

Este modelo distribuido, que requiere que cada servidor tenga una copia de la información sobre el estado global, es uno de los mayores problemas de este protocolo ya que es un serio hándicap que limita el tamaño máximo de una red. Si las redes existentes han conseguido ir creciendo a pasos agigantados, es gracias a los fabricantes de hardware que nos han dado sistemas más potentes.

Un servidor de IRC retransmite las conversaciones de cada canal a cada uno de los usuarios conectados a dicho canal para ofrecer la ilusión de que los participantes están directamente conectados.

En una especie de superestructura, los servidores de IRC se interconectan formando redes de gran dimensión de forma que pueden compartir canales, permitiendo combinar

15 ESTUDIO DEL PROTOCOLO XMPP DE MENSAJERÍA INSTANTÁNEA

muchos servidores individuales así como incrementar el número máximo soportado de salas de chat y de usuarios.

Una red de IRC está definida como un grupo de servidores conectados entre ellos. Un único servidor forma la red de IRC más simple.

La única configuración permitida para los servidores de IRC es la de un árbol donde cada servidor actúa de nodo central para el resto de la red que él "ve".

Ilustración 5. Arquitectura de IRC El protocolo original de IRC no proporcionaba medios para comunicación directa entre clientes. Toda la comunicación entre clientes está basada en el servidor o servidores. En la actualidad, muchos clientes de IRC soportan lo que se denomina Direct Connections (DCC). DCC permite a dos clientes negociar y establecer una conexión directa TCP entre ellos, saltándose tras la negociación de la sesión todos los servidores intermedios que los conectan en la red IRC.

16 3. ESTADO DEL ARTE

Debido a que las implementaciones de IRC utilizan árboles (grafos sin ciclos) como su modelo de conexión, se carece de redundancia y por ese motivo la caída de algún servidor da como resultado un “”.

Ilustración 6. Topología de una red IRC Cada servidor perteneciente a una misma red se conecta a otro de ellos e intercambia todo su tráfico con él, de modo que todos los servidores de una red IRC tienen copia de todos los mensajes del total de salas de chat. Así, de nuevo, la ilusión que se crea en el lado de los clientes es que se conectan a un único y gran servidor.

Las redes IRC más grandes tienen varias decenas de servidores, soportando tráfico de varias decenas de miles de usuarios concurrentes.

17 ESTUDIO DEL PROTOCOLO XMPP DE MENSAJERÍA INSTANTÁNEA

Las redes IRC más grandes conocidas son: DALnet, EFnet (la primera en tamaño, con más de 60 servidores), IRCnet.org y IRCnet.com, QuakeNet.org, . En España, la red más grande y conocida se llama IRC-Hispano y está formada por Arrakis/BT, Lleida.net, Mundo-R, Ono, Telecable y Altecom.

3.2.3.3. Clientes

Después de la primera implementación de Jarkko Oikarinende, han surgido una gran cantidad de implementaciones distintas de clientes IRC, tanto como programas independientes, como mIRC o X-Chat de los más populares, como integradas dentro de otros programas, como Chatzilla.

3.2.3.4. Servidores

Algunos de los servidores más usados en IRC son:

- Unreal IRCd

- Inspire IRCd

- IRC-Hispano IRCd - Servidor IRC de esta fabulosa red española

- UnrealIRCD - Página web del UnrealIRCD

- TerraIRCU - el que usan en el IRC de Terra España

- Dancer IRCd

- IRCd de DALnet - Servidor FTP de DALnet

- wIRCDs.com - Lista de servidores para Win32

- ConferenceRoom - Servidor IRC comercial bajo Win32

- IRCPlus - Página web de IRCPlus

- wIRCd2k - Servidor IRC avanzado para Win32, compatible con

- ircu - Universal IRCd Development homepage

- IRCd Hybrid - IRCd para el sistema operativo linux

18 3. ESTADO DEL ARTE

3.2.4. ICQ y el comienzo de la era moderna de la MI

Muchos estudiosos de la historia de la informática coinciden en señalar a la empresa israelí Mirabilis como precursora de la mensajería Instantánea moderna. Esta compañía, lanzó en noviembre de 1996 el software cliente ICQ (que pronunciado suena como “I seek you”/”yo te busco a ti”). Causó una auténtica revolución, llegando a alcanzar la cifra de 100 millones de usuarios en 5 años. Desde la aparición de ICQ, la inmensa mayoría de usuarios de MI han dependido de protocolos propietarios cerrados.

El protocolo de comunicaciones utilizado por ICQ es conocido como OSCAR, utilizado también por AIM (el sistema de MI de AOL), a raíz de la compra en 1998 de Mirabilis por el gigante America On (AOL).

Entre las características del software se destacaban los mensajes offline, el envío de SMS, conversaciones multiusuario y mensajes personales, entre otros. Uno de los factores de su éxito fue el desarrollo de UIN (Universal Internet Number) con el cual cada usuario era registrado con un número único al cual se le podía sumar información relevante para facilitar la búsqueda de contactos por rango de edad, ubicación, intereses, nacionalidad, etc.

De su popularidad, dan cuenta algunas anécdotas curiosas como que en algunos casos, los números más simples y fáciles de recordar han sido vendidos en subastas por Internet o incluso secuestrados por otros usuarios. Actualmente se desconoce el tamaño de la comunidad de usuarios de AIM/ICQ, aunque, según algunas fuentes no contrastadas podría disponer aún, en nuestros días, de una comunidad de usuarios numerosa, en torno a los 150 millones de usuarios registrados y unos 60 millones de usuarios activos. Las fuentes oficiales sitúan en 800 millones los mensajes intercambiados cada día.

Durante años, ICQ, fue el sistema de MI número uno, hasta que comenzó a ser desplazado lentamente por el Messenger de Microsoft, software que fue copiando las distintas características del mismo hasta ser hoy prácticamente una copia fiel del mensajero de Mirabilis pero sin lograr la calidad y originalidad de este.

19 ESTUDIO DEL PROTOCOLO XMPP DE MENSAJERÍA INSTANTÁNEA

En la actualidad, ICQ está disponible en su versión 6 pero poco queda de la comunidad original en nuestro país, siendo hoy en día sólo un lindo tema para recordar con amigos.

3.2.4.1. Fundamentos del protocolo OSCAR

Al contrario de lo que indica su nombre, OSCAR (Open System for Communications in Real-Time) es un protocolo propietario que fue originalmente creado para el cliente AIM sobre las versiones anteriores del protocolo de ICQ, con el fin de poder compatibilizar los clientes software de AOL y de Mirabilis, posibilitando una experiencia de uso única a las comunidades de usuarios de ambos sistemas de MI.

OSCAR utiliza paquetes binarios de longitud variable, de forma que permite una cierta extensibilidad para ofrecer la base de una amplia variedad de servicios (de chat, de directorio, de gestión, de localización, etc.)

La red consiste en múltiples servidores centrales BOS (Basic OSCAR Service) y un servidor de autorizaciones disponible en login.oscar.aol.com (o login.icq.com). El puerto TCP por defecto es el 5190, aunque los servidores pueden escuchar por todos los puertos. Además, hay otros servidores de propósito específico como por ejemplo la publicidad y las sesiones de chat. Los clientes no se conectan nunca directamente entre sí, sino que lo que lo hace a través de los servidores, que se responsabilizan de la entrega de los mensajes a sus destinatarios.

En 1999, AOL lanzó un protocolo llamado TOC (de “Talk to OSCAR”) que pretendía ser un protocolo abierto en modo texto basado sobre el propio protocolo OSCAR. Si bien, originalmente se lanzó TOC bajo licencia GPL, pasado un tiempo, AOL cambió de opinión debido a los intentos de Microsoft y otros rivales por capacitar a sus clientes software de MI para que se comunicaran de forma efectiva con la red de AIM/ICQ.

Actualmente, AOL sólo desarrolla y ofrece soporte de OSCAR.

20 3. ESTADO DEL ARTE

Ilustración 7. Arquitectura del sistema AIM y el protocolo OSCAR

3.2.4.2. Formato de los paquetes

El subprotocolo de más bajo nivel que fundamenta la comunicación a través de los canales de AIM/ICQ es FLAP. Generalmente, los 6 primeros bytes de cada comando AIM se corresponden con un paquete FLAP.

En el momento que el protocolo deja de seguirse, el servidor OSCAR interrumpe la comunicación con el cliente que ha enviado el paquete corrupto o mal formado, lo que no es muy útil, entre otras cosas, a efectos de depuración.

Un paquete TCP puede contener más de un paquete FLAP.

Las cabeceras de un paquete FLAP son: (en orden de aparición)

• Identificador de protocolo/Comienzo de comando (8 bits de longitud; cuyo valor siempre es ‘0x2a’)

• Identificador de Canal (8 bits de longitud)

• Número de Secuencia (16 bits de longitud)

• Tamaño de los datos del paquete FLAP (16 bits de longitud)

21 ESTUDIO DEL PROTOCOLO XMPP DE MENSAJERÍA INSTANTÁNEA

2A byte FLAP id byte xx byte FLAP channel

xx xx word FLAP datagram seq number

xx xx word FLAP data size

...... FLAP data

Ilustración 8. Formato de un paquete FLAP del protocolo OSCAR Los canales son análogos a los puertos TCP/UDP y hacen posible la multiplexación de paquetes en una única conexión TCP. Los canales se organizan según el tipo de contenido que se incluye en el campo de datos. Así por ejemplo, la negociación nuevas conexiones se corresponde con el canal 0x01. Los datos normales se corresponden por el canal 0x02. Los errores se corresponden con el canal 0x03. Las conexiones se terminan empleando el canal 0x04.

Los números de secuencia son números aleatorios que se van incrementando por 1 por cada paquete FLAP enviado. No existe relación alguna entre la numeración que emplea el lado del cliente y que emplea el lado del servidor. Igualmente, son independientes de los canales.

El campo de datos de un paquete FLAP contiene un paquete SNAC. Los paquetes SNAC son la unidad mínima de intercambio de información entre clientes y servidores. Cada paquete representa un único comando o acción. La capa de comunicación SNAC se sitúa por encima de la capa FLAP. Solamente puede haber un paquete SNAC dentro cada paquete FLAP. Los paquetes SNAC son el contenido natural del campo de datos de un paquete FLAP con canal especificado 0x02.

22 3. ESTADO DEL ARTE

xx xx word Family service id number

xx xx word Family subtype id number

xx xx word SNAC flags

xx xx xx xx xx dword SNAC request id

...... SNAC data

Ilustración 9. Formato de un paquete SNAC del protocolo OSCAR Prácticamente, todos los comandos empleados en AIM se encapsulan dentro de paquetes SNAC, cada uno de los cuales tiene su propia estructura interna. Hay cerca de 200 comandos diferentes, que se dividen en unas 20 familias. La nueva funcionalidad se puede añadir mediante la definición de nuevos comandos (de ahí la extensibilidad del protocolo), así como mediante la descatalogación de otros. No obstante, el núcleo del protocolo no ha cambiado en todos los años posteriores a su introducción.

Los subtipos (Subtypes) son una subdivisión de las familias. Cada identificador de subtipo es diferente, dependiendo del servicio específico provisto en la sección de datos del paquete SNAC. Subtype Source Function Family 0x0001: Generic Service Controls 0x0001 Client or Error 0x0002 Client Client is now online and ready for normal function 0x0003 Server Server is now ready for normal functions 0x0004 Client Request for new service (the server will redirect the client to a new host where the service is available) 0x0005 Server Redirect (response to subtype 0x0004 from client) 0x0006 Client Request Rate Information (request rate at which client can send SNACs) 0x0007 Server Rate information response (response to subtype 0x0006) 0x0008 Client Rate Information Response Ack

23 ESTUDIO DEL PROTOCOLO XMPP DE MENSAJERÍA INSTANTÁNEA

0x000A Server Rate information change 0x000B Server Pause 0x000D Server Resume 0x000E Client Request information on the screen name you've been authenticated under. 0x000F Server Information the screen name you've been authenticated under. 0x0010 Server Evil notification 0x0012 Server Migration notice/request 0x0013 Server Message of the day 0x0014 Client Set Privacy flags 0x0015 Server Well known 0x0016 Server No op Family 0x0002: Location Services 0x0001 Client or Error Server 0x0002 Client Request rights information 0x0003 Server Rights information 0x0004 Client Set user information 0x0005 Client Request user information 0x0006 Server User information 0x0007 Client Watcher sub request 0x0008 Server Watcher notification Family 0x0003: Buddy List Management 0x0001 Client or Error Server 0x0002 Client Request rights information 0x0003 Server Rights information 0x0004 Client Add buddy to buddy list 0x0005 Client Remove buddy from buddy list 0x0006 Client Watcher list query 0x0007 Server Watcher list response 0x0008 Client Watcher sub request 0x0009 Server Watcher notification 0x000A Server Reject notification 0x000B Server Oncoming buddy 0x000C Server Offgoing buddy Family 0x0004: Messaging 0x0001 Client or Error Server 0x0002 Client Add ICBM parameter 0x0003 Client Remove ICBM parameter 0x0004 Client Request parameter information 0x0005 Server Parameter information 0x0006 Client Message from the client 0x0007 Server Message to the client

24 3. ESTADO DEL ARTE

0x0008 Client Evil request 0x0009 Server Evil reply 0x000A Server Missed calls 0x000B Client or Client error Server 0x000C Server Host ack Family 0x0005: Advertisments 0x0001 Client or Error Server 0x0002 Client Request advertisments 0x0003 Server Advertisment data (GIFs) Family 0x0006: Invitation and ClienttoClient 0x0002 Client Invite a friend to join AIM 0x0003 Server Invite a friend to join AIM ack Family 0x0007: Administrative 0x0001 Server Admin error 0x0002 Client Information request 0x0003 Server Information reply 0x0004 Client Information change request 0x0005 Server Information change reply 0x0006 Client Account confirm request 0x0007 Server Account confirm reply 0x0008 Client Account delete request 0x0009 Server Account delete reply Family 0x0008: Popup otices 0x0001 Client or Error Server 0x0002 Server Display popup Family 0x0009: BOSspecific 0x0001 Client or Error Server 0x0002 Client Request BOS Rights 0x0003 Server BOS Rights 0x0004 Client Set group permission mask 0x0005 Client Add permission list entries 0x0006 Client Delete permission list entries 0x0007 Client Add deny list entries 0x0008 Client Delete deny list entries 0x0009 Server BOS error Family 0x000A: User Lookup 0x0001 Client or Error (often Search Failed) Server 0x0002 Client Search for screen name by address 0x0003 Server Search Response Family 0x000B: Stats

25 ESTUDIO DEL PROTOCOLO XMPP DE MENSAJERÍA INSTANTÁNEA

0x0001 Client or Error Server 0x0002 Server Set minimum report interval 0x0003 Client Report events 0x0004 Server Report ack Family 0x000C: Translate 0x0001 Client or Error Server 0x0002 Client Translate request 0x0003 Server Translate reply Family 0x000D: Chat avigation 0x0001 Client or Error Server 0x0002 Client Request chat rights 0x0003 Client Request exchange information 0x0004 Client Request room information 0x0005 Client Request more room information 0x0006 Client Request occupant list 0x0007 Client Search for room 0x0008 Client Create room 0x0009 Server Navigation information Family 0x000E: Chat 0x0001 Client or Error Server 0x0002 Server Room information update 0x0003 Server Users joined 0x0004 Server Users left 0x0005 Client Channel message from client 0x0006 Server Channel message to client 0x0007 Server Evil request 0x0008 Server Evil reply 0x0009 Client or Client error Server Family 0x0045: Unknown (Client Something?) 0x0002 Client Add to notify list Tabla 1. Familias de paquetes SNAC del protocolo OSCAR Los identificadores de solicitudes (Request IDs) son valores de 32bit empleados para identificar respuestas a múltiples solicitudes pendientes. Estos identificadores pueden ser completamente aleatorios. Generalmente, los resultados de un comando SNAC son irrelevantes, y por tanto los Request ID pueden ser ignorados. Otras veces, cuando es necesario esperar una respuesta, constituyen la única forma de mantener la

26 3. ESTADO DEL ARTE

correspondencia entre peticiones y respuestas. Los paquetes SNAC iniciados por el servidor se diferencian del resto porque su bit más significativo (MSB) está puesto a 1.

El campo Flags describe la function y la estructura del paquete SNAC. Por ejemplo, el bit menos significativo (LSB) especifica que el receptor debe esperar recibir más paquetes SNAC como respuesta a una petición determinada.

Los datos de longitud variable que contienen los paquetes SNAC y los paquetes FLAP se suelen codificar dentro de uno o más paquetes TLV (Type-Length-Value). El protocolo permite su anidamiento o encadenamiento cuando es preciso.

xx xx word TLV type number

xx xx word TLV length value

...... TLV data

Tabla 2. Formato de un paquete TLV del protocolo OSCAR

27 ESTUDIO DEL PROTOCOLO XMPP DE MENSAJERÍA INSTANTÁNEA

TLV TLV TLV TLV RAWRAW

SNAC SNAC RAW FLAP FLAP FLAP TCP IP

Ilustración 10. Formato de los paquetes en el protocolo OSCAR America Online migró el cliente de ICQ a OSCAR gracias a la capacidad de definir nuevos tipos de paquetes SNAC para implementar la funcionalidad que faltaba. Además de estos cambios, se tuvo que sustituir los números UIN por los identificadores alfanuméricos de AIM, mucho más amigables. Gracias a emplear OSCAR, los clientes de ICQ pueden comunicarse con clientes AIM y viceversa.

3.2.4.3. Funcionamiento general del protocolo

Antes de que un cliente se pueda conectar a cualquiera de los servidores BOS o cualquier otro de propósito especial, el servidor de autorizaciones debe autorizarlo primero. El servidor proveerá primero al cliente de una ‘cookie’ que le permitirá conectarse automáticamente al resto de servidores, para poder utilizar el resto de los servicios disponibles en la red de MI. A esto se le denomina ‘single-login’.

El servidor de autorizaciones también redirige el cliente a un servidor BOS predeterminado según las preferencias de conexión del cliente, pudiendo ser redirigido a cualquier otro disponible para facilitar el reparto de la carga de trabajo entre servidores.

28 3. ESTADO DEL ARTE

Tras introducir usuario y clave de acceso, el cliente debe desconectarse del servidor BOS.

Hay muchos pasos que un cliente debe completar cuando se conecta a un servidor BOS. Cada paso consiste en el intercambio de uno o más paquetes FLAP con el servidor. Primero, debe enviar un paquete de login. Hay dos formas de enviar la cookie a los servidores BOS. El cliente debe usar el canal FLAP 0x01 para transmitir una petición estándar de login con la palabra clave de acceso más o menos protegida, según la versión de protocolo (en algunos casos se envía la firma HASH MD5 de las password, en otros se envía la clave cifrada por un método de traslación de caracteres). El servidor contestará con una lista de los servicios soportados. A partir de ahí, el cliente enviará al servidor una lista de los servicios que solicita y negociará los parámetros de conexión, tales como la tasa de envío de paquetes (cada cuanto tiempo al cliente puede enviar paquetes). El tercer paso consiste en la negociación de las limitaciones del servicio y las capacidades del cliente (p.e. cuantos contactos se permiten en la lista de contactos y cuál es la longitud máxima permitida de los mensajes). El paso final consiste en que el cliente envía al servidor su versión de la librería de enlace dinámico (DLL) así como una notificación de que está lista para recibir mensajes. En el caso de clientes ICQ, hay un paso adicional que consiste en chequear la llegada de mensajes offline.

3.2.4.4. Servicios de mensajería y estructura de los mensajes

Los mensajes instantáneos se transmiten utilizando los servicios de la familia 0x04 que se denominan ICBM (Inter-Client Basic Message). Los servicios consisten en una serie de definiciones de paquetes SNAC, los cuales permiten a los clientes la construcción de mensajes dentro de paquetes FLAP. Dentro de la zona de datos de un paquete de mensajes hay una definición de canal que especifica el tipo y las estructuras de datos propias del mensaje. El canal 0x01 es para mensajes de texto comunes, mientras que el canal 0x02 está pensado para mensajes de contenido complejo que deba estar estructurado, tal como texto formateado en RTF o codificado como UTF-8. Los mensajes pueden contener también invitaciones a grupos de chat o de transferencia de

29 ESTUDIO DEL PROTOCOLO XMPP DE MENSAJERÍA INSTANTÁNEA

ficheros. El canal 0x03 es para mensajes de chat y el canal 0x04 es para características específicas de ICQ, tales como el envío de enlaces web con formato de URL.

Los servidores no modifican el contenido de los mensajes. El servicio ICBM tiene definidos una serie de parámetros tales como la longitud máxima de los mensajes (por defecto 2048 bytes). El texto de los mensajes se transporta en un formato propietario cuyo identificador MIME es “text/x-aol-rtf”. El formato está inspirado en HTML.

30 3. ESTADO DEL ARTE

00 04 word SNAC family 00 06 word SNAC subtype

00 00 word SNAC flags

xx xx xx xx xx dword SNAC request id

SNAC data

xx xx xx xx dword message id cookie xx xx xx xx 00 01 word message channel xx byte screenname string length xx ... string screenname string

TLV header 00 02 word TLV type number xx xx word TLV length value

TLV data 05 byte fragment identifier (array of required capabilities) 01 byte fragment version xx xx word length of rest data xx ... array byte array of required capabilities

01 byte fragment identifier (text message) 01 byte fragment version xx xx word length of rest data 00 00 word message charset number FF FF word message language number xx ... string() message text string

TLV header 00 03 word TLV type (request an ack from server) 00 00 word TLV length value

TLV data NULL

TLV header 00 06 word TLV type (store message if recipient offline) 00 00 word TLV length value

TLV data NULL

Ilustración 11. Ejemplo de paquete SNAC conteniendo un mensaje de un cliente

31 ESTUDIO DEL PROTOCOLO XMPP DE MENSAJERÍA INSTANTÁNEA

3.2.5. Jabber y XMPP

3.2.5.1. Introducción

Si Internet se ha convertido en la revolución de los canales de comunicaciones mundiales, ha sido precisamente por su carácter abierto, estándar y accesible a las tecnologías. El no haber sido desarrollado con carácter propietario ha hecho que Internet evolucione como un ecosistema en el que hemos participado –y estemos participando- todos. En el concepto de la MI ocurre lo mismo. Así nació Jabber, el primer protocolo de MI con carácter abierto.

La especificación base de Jabber (que más tarde se convertiría en el protocolo XMPP) fue inventada en 1998 por Jeremie Miller y tomada como protocolo por la comunidad open-source en 1999, donde ha ido creciendo y evolucionando hasta nuestros días.

La originalidad de Jabber consistió en que empleaba estándares abiertos como XML y que, por definición, era un protocolo extensible, lo que le ha dado mucho recorrido a lo largo de los últimos diez años.

El protocolo de mensajería y presencia en el que se basaba Jabber era una tecnología abierta basada en XML, para la comunicación en tiempo real, lo cual proporcionaba potencialmente un amplio rango de aplicaciones, incluyendo: mensajería instantánea, presencia, negociación de múltiples medios, pizarras compartidas, colaboración, middleware ligero, sindicación de contenidos, y enrutamiento XML genérico.

Hasta la fecha, Jabber y XMPP han sido los proyectos más aceptados como alternativas libres serias al sistema MSN Messenger de Microsoft, al AIM de AOL, al Yahoo! Messenger y, por supuesto al ICQ. Y aunque XMPP todavía es un protocolo algo desconocido, está creciendo más cada día, gracias a los usuarios y, por supuesto, a Google, que ha creado Google Talk, un cliente de mensajería instantánea que maneja el protocolo XMPP.

32 3. ESTADO DEL ARTE

3.2.5.2. Orígenes

Jeremie Miller publicó Jabber en Enero de 1999. Se trataba por aquel entonces de una tecnología abierta para la mensajería instantánea y la presencia en fase de desarrollo. Un año después, en Febrero de 2000, el Grupo de Trabajo en Protocolos de Mensajería Instantánea y Presencia del IETF (IMPP Working Group) publicó los resultados de los trabajos de Miller, dando lugar a dos RFC muy conocidas: la RFC 2778 y la RFC 2779. La primera de ellas contenía un modelo de sistema de mensajería instantánea y presencia, mientras que la segunda recogía un conjunto de requisitos para tales sistemas.

Ilustración 12. Hitos en la breve historia de los protocolos Jabber y XMPP Debido a diferentes puntos de vista del mencionado grupo de trabajo del IETF, nunca se produjo ningún protocolo real. La comunidad de desarrolladores que existía en torno

33 ESTUDIO DEL PROTOCOLO XMPP DE MENSAJERÍA INSTANTÁNEA

a Jabber elaboró un borrador del protocolo que remitió a la IETF para su estandarización, pero dicha comunidad no estaba suficientemente organizada, y el borrador presentado a la IETF nunca fue actualizado y expiró sin más alternativas.

A pesar de todo esto, nuevas versiones de Jabber iban saliendo a la luz y el Octubre de 2000 se presentó la versión 1.2 del servidor abierto de MI jabberd (término que viene de Jabber Daemon).

En Agosto de 2001 se constituyó, debido a la presión de la creciente comunidad, la Jabber Software Foundation (JSF), con el objetivo de coordinar el desarrollo y la documentación de los protocolos basados en XML que se empleaban en Jabber.

En Febrero de 2002 la JSF envió a la IETF un nuevo borrador (Internet Draft) del protocolo Jabber. Los resultados fueron prometedores y, en Junio de ese mismo año se enviaron tres más. En todos estos borradores, la JSF cambió el nombre del protocolo por uno más neutral: eXtensible Messaging and Presence Protocol (XMPP).

Muy pronto se solicitó al IESG (Internet Engineering Steering Group) la constitución de un grupo de trabajo específico sobre XMPP, lo que se aprobó en Octubre de 2002, dando lugar al XMPP Working Group.

El XMPP Working Group hizo muchas mejoras sobre los borradores presentados a la IETF, sobre todo en lo que concernía a seguridad y arquitectura interna del protocolo. En paralelo, la JSF trabajó en la creación de las primeras extensiones del protocolo Jabber que eran trasladables a XMPP.

En Octubre de 2004, la IETF publica finalmente el conjunto de RFCs que definen actualmente el protocolo XMPP:

- RFC 3920, que define el núcleo del protocolo XMPP;

- RFC 3921, que define los servicios de mensajería instantánea y de presencia previstos en XMPP

Además, la IETF publicó dos RFCs complementarias:

- RFC 3922, que define una trasposición de XMPP a CPIM (RFC 3860, Common Profile for );

34 3. ESTADO DEL ARTE

- RFC 3923, que define un mecanismo extremo a extremo de firma y cifrado de los objetos.

3.3. Fundamentos técnicos de XMPP

3.3.1. Arquitectura general del protocolo

Generalmente, XMPP se implementa y se usa como una arquitectura cliente- servidor, pero XMPP no fuerza a hacerlo así. Uno puede emplear XMPP para establecer una comunicación directa, de extremo a extremo (P2P), entre los clientes.

En cuanto a los protocolos de transporte que sustentan la comunicación en XMPP, normalmente tenemos las conexiones puras de TCP, aunque podrían emplearse otros protocolos como HTTP Polling o HTTP Binding (también llamado BOSH), que se basan en usos muy particulares del protocolo de aplicación HTTP.

Un ejemplo de red de mensajería instantánea se presenta en la Ilustración 13. La red puede tener múltiples clientes y servidores que se comuniquen por XMPP pero, además, puede contar con una serie de pasarelas o gateways que traducen de XMPP a otros protocolos de MI de diferentes redes. Es posible, por tanto, comunicar usuarios de redes XMPP con redes de otros protocolos de MI, y viceversa, siempre que existan dichos gateways.

Ilustración 13. Federación de redes MI a través de gateways

35 ESTUDIO DEL PROTOCOLO XMPP DE MENSAJERÍA INSTANTÁNEA

Ilustración 14. Arquitectura de comunicaciones del protocolo XMPP El principal rol en XMPP consiste en gestionar las conexiones y los envíos de paquetes XML hacia los clientes y hacia otros servidores Los servidores también tienen capacidad de enrutado de mensajes entre ellos. De hecho, el Internet Assigned Numbers Authority (IANA) tiene reservado el puerto TCP número 5269 a efectos de este tipo de tráfico XMPP entre servidores.

En el ejemplo que aparece en la Ilustración 14 se puede apreciar cómo el servidor nº 1 es capaz de enrutar mensajes dirigidos a los clientes pertenecientes al dominio del servidor nº 2.

36 3. ESTADO DEL ARTE

Los clientes XMPP inician la conexión contra un servidor u otro cliente. Y para ello usan el puerto reservado TCP número 5222.

3.3.2. Direccionamiento

Para permitir el direccionamiento entre los clientes de las redes MI, cada usuario de MI emplea un tipo de identificador que se denomina Uniform Resource Identifier (URI), que es una cadena de caracteres compacta y sujeta al formato , donde resource es opcional. También se emplean URIs con el formato y . Estas últimas se emplean para dirigirse a una sala de conversación de un determinado servicio de chat y para dirigirse a un participante de dicha conversación, respectivamente.

Las URIs también se denominan JIDs (Jabber IDs) por razones históricas. Los formatos que hemos comentado se basan en tres partes: un nodo, un dominio, y un recurso. Existen algunos límites en las longitudes de las partes de un JID: 1023 bytes por cada identificador de nodo, dominio, o recurso. Por tanto, las URIs o JIDs tendrán una longitud máxima de 3071 bytes, incluyendo los símbolos ‘@’ y ‘/’.

La definición de las URIs en notación BNF es la siguiente: jid = [ node "@" ] domain [ "/" resource ] domain = fqdn / address-literal fqdn = (sub-domain 1*("." sub-domain)) sub-domain = (internationalized domain label) address-literal = IPv4address / IPv6address

De un JID, la única parte que debe declararse obligatoriamente es el dominio. Las otras dos son opcionales. La forma de especificar un dominio puede ser una de las siguientes: dirección IP completa o el nombre cualificado completo (FQDN). El identificador de nodo es opcional y, generalmente, representa al cliente, aunque también se puede usar para representar una sala de chat perteneciente a un servicio de multichat. El identificador de recurso sirve para representar una sesión, una conexión, o un objeto.

37 ESTUDIO DEL PROTOCOLO XMPP DE MENSAJERÍA INSTANTÁNEA

3.3.3. Estructura de la comunicación basada en XML: Streams y Stanzas

El servidor participa en todas las comunicaciones XMPP. Su principal responsabilidad es la de proveer de servicios XMPP a los clientes de su dominio como pueden ser la redirección de sus paquetes y la gestión de sus cuentas de usuario.

El cliente XMPP es quien interactúa directamente con el usuario. Es el programa que muestra las respuestas del servidor y que recoge las peticiones del cliente y las envía al servidor para que las trate. Normalmente, estas peticiones son mensajes que el usuario quiere que lleguen a otro usuario, para lo que el servidor deberá localizar al destinatario y proceder a hacerle llegar el paquete por la ruta adecuada.

La conexión se realiza entre cliente y servidor, y por ella viajan paquetes XML con las peticiones, mensajes, etc. que envían o reciben los usuarios, en forma de fragmentos de XML correctamente formados. El protocolo XMPP es quien especifica el formato de estos paquetes.

En el protocolo XMPP, toda la comunicación se hace a través de lo que denominan flujos XML o XML streams, representados por su sentencia XML .

Los XML streams son los contenedores XML de más alto nivel que permiten el intercambio de elementos XML entre dos hosts pertenecientes a una red de MI basada en protocolo XMPP. Son como un documento XML normal y corriente que tiene el tamaño tal que contiene toda la sesión, incluyendo cada mensaje enviado dentro de la sesión. Los streams no son documentos XML completos hasta que no se cierran dichas sesiones. El elemento raíz es .

Cuando un cliente establece una conexión con el servidor (o con otro cliente) abre un XML stream. Entonces, el otro host abre otro stream de vuelta hacia el host llamante, de forma que cada conexión XMPP tiene dos XML streams abiertos, uno en cada dirección.

Los streams se emplean para enviar stanzas o comandos, de un host a otro. Las stanzas son los elementos hijos de primer nivel del documento XML del stream. Fundamentalmente, hay tres tipos principales de stanzas: , y .

38 3. ESTADO DEL ARTE

Un ejemplo simple de XMPP stream es el siguiente: Hello! ...

3.3.3.1. egociación de la comunicación: XML Streams

El servidor XMPP, como todo servidor, se arranca y se mantiene esperando conexiones de usuarios en el puerto 5222.

El cliente comienza la negociación del flujo “stream” mandando al servidor el elemento XML de versión y el elemento de apertura de flujo . Esto representa el inicio de una sesión del cliente con el servidor. Cuando un servidor XMPP acepta una conexión de un cliente responderá con para confirmar el inicio de la sesión.

Actualmente, los elementos necesitan declaración de un espacio de nombres, por lo que se añade el prefijo stream: al elemento , de forma que el nombre del elemento completo es .

Si hubiera un error en la sesión se enviaría la etiqueta explicando el problema y cerrando la conexión por parte del servidor.

Los atributos del flujo están definidos dentro del elemento . Entre sus atributos se tienen el espacio de nombres, como ya hemos destacado, y la información de versión.

Una vez que se ha establecido el flujo entre el cliente y el servidor pueden enviarse paquetes de acuerdo con los múltiples protocolos de XMPP. En la mayoría de los casos el servidor sólo le dejará al cliente enviar unos pocos tipos de mensajes hasta que se autentifique.

39 ESTUDIO DEL PROTOCOLO XMPP DE MENSAJERÍA INSTANTÁNEA

El estándar de XMPP no especifica el conjunto de protocolos disponibles para un usuario sin autentificar, pero como mínimo es normal que los usuarios puedan utilizar los protocolos de autentificación y registro.

Tanto el servidor como el cliente pueden cerrar el flujo de datos en cualquier momento enviando una etiqueta de cierre . En ese momento, cada uno podrá cerrar la conexión y terminar la sesión XMPP. Es conveniente dejar a la otra entidad terminar de enviar un paquete que esté en curso antes de cerrar la conexión.

Tal y como hemos explicado esta sería una conexión típica de XMPP:

- Conectarse con el puerto 5222 del servidor

- Enviar una etiqueta de sesión abierta

- Esperar la respuesta del servidor

- Negociación TLS

- Autenticación mediante SASL

- Enviar y recibir paquetes XMPP o stanzas

- Enviar la etiqueta de cierre para terminar la sesión.

- Cerrar la conexión

3.3.3.2. TLS: La seguridad en la capa de transporte

El protocolo TLS5 es un protocolo para establecer una conexión segura entre un cliente y un servidor, o entre dos servidores. TLS es capaz de autenticar en ambos lados de la comunicación, y crea una conexión cifrada entre las dos. El protocolo TLS puede ser extendido, esto es que nuevos algoritmos pueden ser utilizados para cualquiera de los propósitos, con la condición de que tanto el cliente como el servidor conozcan dichos algoritmos.

5 Security, definido en el RFC 2246

40 3. ESTADO DEL ARTE

La principal propiedad del protocolo TLS, es ofrecer privacidad e integridad de los datos, entre dos aplicaciones que se comunican; el protocolo está compuesto por dos capas, el TLS Record Protocol y el TLS Handshake Protocol.

El TLS Record Protocol ofrece seguridad en las conexiones y tiene dos propiedades básicas:

1. La conexión es privada; se utiliza criptografía simétrica para el cifrado de los datos (DES, AES, RC4, etc), las llaves para los algoritmos simétricos son generadas una sola vez para cada sesión, y están basadas en un secreto negociado por otro protocolo (TLS Handshake), el TLS Record Protocol puede ser utilizado sin cifrado también.

2. La conexión es confiable, el transporte de mensajes, incluye una verificación de integridad de mensajes, utilizando una MAC con llave, para esto se utilizan algoritmos de funciones de hash seguros como SHA1, SHA256, MD5.

El TLS Record Protocol, es utilizado para la encapsulación de varios protocolos de nivel superior, uno de tales protocolos encapsulados, es el TLS Handshake Protocol, el cual es utilizado para autenticar tanto a los clientes como a los servidores, y para negociar un algoritmo de cifrado así como las llaves criptográficas, antes de que el protocolo de la aplicación transmita o reciba el primer byte de datos. El protocolo TLS Handshake Protocol ofrece seguridad en la conexión, y tiene 3 propiedades básicas:

1. La identidad de la otra parte puede ser verificada utilizando criptografía asimétrica (RSA o DSS), esta autenticación puede ser opcional, pero generalmente se requiere por al menos una de las partes.

2. La negociación de un secreto compartido es segura: el secreto negociado no está disponible para ningún atacante, incluso si el atacante utilizara un ataque hombre en el medio.

3. La negociación es confiable: ningún atacante puede modificar la comunicación sin ser detectado por las partes que intervienen en la comunicación.

Una ventaja de TLS, es que es independiente del protocolo de la aplicación, los protocolos de más alto nivel pueden tener capas encima del protocolo TLS de forma

41 ESTUDIO DEL PROTOCOLO XMPP DE MENSAJERÍA INSTANTÁNEA

transparente, sin embargo, el estándar TLS no especifica de qué forma los protocolos definen la seguridad en TLS, las decisiones de cómo inicializar handshaking, y cómo interpretar los certificados de autenticación intercambiados, se dejan a juicio de los diseñadores y los implementadores de los protocolos que corren por encima de TLS.

Ilustración 15. Posibilidades de uso de TLS en el cifrado de datos Tal y como se muestra en la Ilustración 15, los mensajes transmitidos hacia y desde otros servidores XMPP pueden ser interceptados en el caso de que las conexiones cliente a servidor (C2S) o las conexiones servidor a servidor (S2S) no estén cifradas. Si se da esta situación, es tremendamente fácil para un cracker interceptor las conversaciones de los usuarios, como se puede demostrar con la captura de pantalla de la Ilustración 16, que demuestra un volcado de paquetes obtenido con la herramienta Ethereal.

42 3. ESTADO DEL ARTE

Ilustración 16. Esnifando datos transmitidos como texto en claro XMPP incluye un método para asegurar el flujo de datos de la conexión entre las dos partes y evitar el robo o uso fraudulento de los datos incluidos en la transmisión. Este método de cifrado del canal hace uso del protocolo TLS, junto con la extensión STARTTLS que se describe en la RFC 2595. El espacio de nombres para la esta extensión es 'urn:ietf:params::ns:-tls'.

Un administrador de un dominio puede requerir el uso de TLS para las comunicaciones cliente a servidor y/o servidor a servidor.

Los clientes XMPP deben emplear TLS para asegurar los flujos de información antes de proceder a la negociación de la autenticación con SASL y los servidores de MI deben utilizar TLS para asegurar de igual modo los flujos de información entre dominios XMPP.

La secuencia de negociación TLS es la siguiente:

1. La entidad origen (por ejemplo, un cliente XMPP) abre una conexión TCP en el puerto 5222 hacia la entidad destino (el servidor XMPP) e inicia el flujo de información, enviando un elemento .

43 ESTUDIO DEL PROTOCOLO XMPP DE MENSAJERÍA INSTANTÁNEA

2. La entidad destino (el servidor XMPP) abre otra conexión TCP contra la entidad origen y envía de vuelta otro elemento así como un elemento que contiene una lista con las características soportadas por el servidor XMPP, incluyendo la extensión STARTTLS. Si la entidad destino está configurada para requerir TLS, esta incluirá como un elemento hijo del elemento . Como ejemplo de un elemento tendríamos: ...

3. La entidad origen enviará de vuelta entonces el comando STARTTLS mediante la sentencia:

4. La entidad destino responderá con una sentencia de confirmación del comienzo de negociación:

Si se hubiera producido un fallo durante la ejecución de la sentencia STARTTLS, la entidad destino tendría que replicar con una sentencia y cerrar la conexión TCP.

5. Después de haber enviado el elemento , ambas partes terminarán de enviar elementos XML y comenzarán una negociación TLS sobre la conexión TCP existente.

44 3. ESTADO DEL ARTE

Si la negociación TLS no tiene éxito (situación marcada como A en la Ilustración 17), el lado destino terminará la conexión TCP. En otro caso (situación B en la Ilustración 17), la entidad origen abrirá un nuevo flujo de información , del mismo modo que se realizó en el primer paso, aunque utilizando la misma conexión de TCP que hay abierta.

6. La entidad destino replicará enviando una nueva cabecera , como en el segundo paso, solo que omitiendo la parte del STARTTLS.

Por último, la entidad origen, continuará con la negociación SASL, para la autenticación de las partes.

Ilustración 17. Funcionamiento de la negociación de TLS

45 ESTUDIO DEL PROTOCOLO XMPP DE MENSAJERÍA INSTANTÁNEA

3.3.3.3. Autenticación con SASL

XMPP incluye autenticación mediante SASL6. En los inicios del protocolo Jabber la autentificación se realizaba mediante el protocolo jabber:iq:auth, pero hoy en día esto se realiza empleando SASL.

SASL provee a XMPP de un método generalizado para la autenticación. Para ello se han aplicado ciertas normas:

- Si la autenticación SASL se da entre dos servidores, la comunicación no se establecerá hasta que cada servidor se asegure de la auténtica DNS del otro.

- Si quien quiere autenticarse soporta SASL, deberá incluir el atributo ‘version’ con el valor ‘1.0’ por lo menos, en la cabecera del stream inicial.

- Si el servidor soporta SASL, deberá informar de sus tipos de autentificaciones con la etiqueta en la contestación de la etiqueta de inicio de sesión, si es que el cliente soporta la conexión SASL.

- Durante la negociación SASL, ninguno de los dos deberá enviar algún carácter en blanco como separación entre elementes, esta prohibición ayuda a asegurar la precisión a nivel de byte.

- Cualquier carácter XML contenido en los elementos XML deberá estar codificado usando el algoritmo base64.

El proceso de autentificación mediante SASL sería el siguiente: 1) La entidad que pida una autentificación SASL deberá incluir el atributo ‘version’ en la etiqueta de inicio de sesión enviada al servidor con el valor ‘1.0’ como mínimo. 2) Cuando el servidor recibe la etiqueta de inicio de sesión con el atributo ‘version’ deberá comunicar los tipos de autentificación SASL que implementa, cada uno de ellos irá dentro de un hijo del tipo .

6 Simple Authentication and Security Layer, definido en la RFC 2222

46 3. ESTADO DEL ARTE

3) El cliente deberá seleccionar uno de los mecanismos enviando el elemento con un valor adecuado para el mecanismo de autentificación SASL elegido. Si el cliente debe responder con un elemento vacío responderá con el carácter ‘=’, que indicará que la respuesta no contiene datos. 4) Si fuera necesario, el servidor enviará el elemento al cliente que contendrá datos en formato XML, esto dependerá del tipo de autentificación SASL que el cliente haya elegido. 5) El cliente responderá al “desafío” enviando la etiqueta al servidor. 6) Si fuera necesario el servidor enviaría más elementos y el cliente respondería a los mismos.

Esta serie de desafíos y respuestas continuaría hasta que ocurriera una de estas tres cosas:

- Que el cliente que quería autentificarse aborte la autentificación enviando la etiqueta al servidor. En cuyo caso el servidor dejará al cliente enviar un número configurable de peticiones más, normalmente dos, antes de cerrar la conexión TCP. Así el cliente podrá volver a autentificarse sin necesidad de reiniciar la sesión como pasaba con el protocolo Jabber original.

- Que el servidor responda con la etiqueta , con la que comunicaría al cliente que la autentificación ha fallado. Como en el caso anterior, le dejará enviar un limitado número de peticiones más para que, si lo desea, vuelva a intentarlo.

- Que el servidor responda con la etiqueta , con la que comunicaría al cliente que la autentificación se ha realizado correctamente, y además contendría datos en formato XML dependiendo del tipo de autentificación SASL. Una vez realizada la autentificación el cliente deberá enviar una etiqueta vacía de inicio de sesión, sin necesidad de cerrar la sesión anterior, a la que contestará el servidor y comenzará la conexión.

47 ESTUDIO DEL PROTOCOLO XMPP DE MENSAJERÍA INSTANTÁNEA

La autentificación SASL puede generar diferentes errores:

- : autentificación abortada, explicada anteriormente.

- : los datos enviados por el cliente no pueden ser procesados por el servidor debido a que la codificación base64 es incorrecta.

- : el authzid dado por el cliente es inválido debido a que está mal formado o a que el cliente no tiene permisos.

- : el cliente tiene o solicita un mecanismo que no está implementado en el servidor.

- : el mecanismo está considerado como débil por la política de seguridad del servidor.

- : la autentificación ha fallado debido a que el cliente no tiene credenciales válidos.

- : la autentificación ha fallado debido a un error temporal del servidor.

48 3. ESTADO DEL ARTE

(1) Envía cabecera del XML Stream Esto hace de petición de autenticación SASL

(2)(3) Se envia cabecera XML Stream y a continuación los con los mecanismos soportados de autenticación SASL ()

(4) Se envia el mecanismo seleccionado con un paquete

(5) El servidor envía el challenge al cliente en base64 Lo hace con un paquete

(6) El cliente envia la respuesta en base64 con un

(7) Se intercambian más pares de y (si se necesita)

FINALIZACION: ALGO VA MAL

(8) El emisor envia un paquete o el receptor envia un paquete de Se reintenta N veces

FINALIZACION: TODO OK

(9) El servidor le dice al cliente que la autentificación ha sido correcta con un paquete

(10) El cliente envía una nueva etiqueta de inicio de sesión con un XML Stream

(11) El servidor responde al cliente con una cabecera de sesión con más opciones (o si no con la etiqueta vacía

[email protected] Jabber.org

Ilustración 18. Negociación del protocolo SASL De forma gráfica, el protocolo de autenticación de SASL es el que se muestra en la Ilustración 18.

Por tanto, la secuencia tipo de autenticación SASL entre un cliente y un servidor podría ser la siguiente:

1. El cliente envía la etiqueta de inicio de sesión al servidor:

49 ESTUDIO DEL PROTOCOLO XMPP DE MENSAJERÍA INSTANTÁNEA

2. El servidor responde al cliente con la etiqueta de inicio:

3. El servidor informa al cliente de los mecanismos disponibles: DIGEST-MD5 PLAIN

4. El cliente selecciona el mecanismo deseado:

5. El servidor envía el challenge al cliente en base64: cmVhbG09InNvbWVyZWFsbSIsbm9uY2U9Ik9BNk1HOXRFUUdtMmhoIixxb3A9ImF1dGgi LGNoYXJzZXQ9dXRmLTgsYWxnb3JpdGhtPW1kNS1zZXNzCg==

El challenge decodificado es: realm="somerealm",nonce="OA6MG9tEQGm2hh",\ qop="auth",charset=utf-8,algorithm=md5-sess

Aunque el servidor podría haber respondido con un error:

6. El cliente envía la respuesta en base64: dXNlcm5hbWU9InNvbWVub2RlIixyZWFsbT0ic29tZXJlYWxtIixub25jZT0i T0E2TUc5dEVRR20yaGgiLGNub25jZT0iT0E2TUhYaDZWcVRyUmsiLG5jPTAw MDAwMDAxLHFvcD1hdXRoLGRpZ2VzdC11cmk9InhtcHAvZXhhbXBsZS5jb20i LHJlc3BvbnNlPWQzODhkYWQ5MGQ0YmJkNzYwYTE1MjMyMWYyMTQzYWY3LGNo YXJzZXQ9dXRmLTgK

50 3. ESTADO DEL ARTE

La respuesta decodificada es: username="somenode",realm="somerealm",\ nonce="OA6MG9tEQGm2hh",cnonce="OA6MHXh6VqTrRk",\ nc=00000001,qop=auth,digest-uri="xmpp/example.com",\ response=d388dad90d4bbd760a152321f2143af7,charset=utf-8

7. El servidor envía otro challenge codificado al cliente: cnNwYXV0aD1lYTQwZjYwMzM1YzQyN2I1NTI3Yjg0ZGJhYmNkZmZmZAo=

El challenge decodificado es: rspauth=ea40f60335c427b5527b84dbabcdfffd

El servidor también podría haber respondido con un error:

8. El cliente responde:

9. El servidor le dice al cliente que la autentificación ha sido correcta:

El servidor podría haber respondido con error:

10. El cliente envía una nueva etiqueta de inicio de sesión:

51 ESTUDIO DEL PROTOCOLO XMPP DE MENSAJERÍA INSTANTÁNEA

11. El servidor responde al cliente con una cabecera de sesión con más opciones (o si no con la etiqueta “features” vacía):

3.3.3.4. Comandos: XML Stanzas

Una vez abierto el nuevo stream, tras la negociación SASL, y la posible negociación TLS (dependiendo de la configuración del servidor), las XML stanzas o comandos pueden enviarse a continuación.

Hay tres tipos fundamentales de stanzas definidas para los dos espacios de nombres jabber:client y jabber:server. Son los elementos , , y .

Estos elementos tienen una serie de atributos comunes, que no siempre están presentes:

1. to especifica el destinatario de la stanza.

2. from especifica el remitente de la stanza, que debe validar la veracidad de este atributo. El servidor puede añadir o definir el atributo ‘from’ en una stanza enviada por un cliente.

3. id puede ser utilizado por la entidad remitente a efectos de ordenamiento/identificación de los mensajes.

4. type especifica información sobre la propia stanza. Sus valores dependerán del tipo concreto de stanza, siendo ‘error’ el único tipo común a las tres stanzas.

5. xml:lang especifica el lenguaje en el que se ha escrito/codificado la información que contiene la stanza (p.e. para el Español será xml:lang=’es’)

52 3. ESTADO DEL ARTE

3.3.4. La mensajería Instantánea en XMPP

Los mensajes son la parte más importante de cualquier sistema de mensajería instantánea. XMPP es un protocolo muy orientado a los mensajes, que pueden ser de seis tipos diferentes:

- ‘normal’: que serían mensajes parecidos a los del correo electrónico.

- ‘chat’: mensajes persona a persona que serían los mensajes utilizados en una conversación entre dos personas.

- ‘groupchat’: mensajes enviados a un grupo de personas

- ‘headline’: que serían los mensajes de marquesina

- ‘error’: para los mensajes de error

- ‘jabber:x:oob’: para las conexiones directas entre clientes para envío de archivos

Los cinco primeros son los tipos más normales de mensajes en los sistemas XMPP. Los mensajes ‘jabber:x:oob’ se denominan outof , y facilitan un mecanismo para intercambio de datos directamente entre dos usuarios, estos mensajes usan el servidor XMPP para intercambiar datos de la conexión entre los dos clientes, normalmente el usuario que va a servir un fichero enviaría un mensaje de este tipo al otro cliente con la IP y el puerto al que se debe conectar el cliente que va a descargarse el fichero. Se pueden enviar etiquetas de ‘oob’ dentro de la extensión ‘x’ de un mensaje normal, o empaquetadas dentro de un paquete del tipo Info/Query.

3.3.4.1. Direccionamiento de los mensajes

El protocolo de mensajes es extremadamente sencillo, los paquetes son enviados por un usuario a un receptor. Por defecto, no se reciben confirmaciones de que el mensaje ha sido recibido por el destinatario para reducir el tráfico en el servidor, además si el receptor no se encuentra disponible, el servidor guardará el mensaje hasta que se conecte. A este comportamiento particular del protocolo se le denomina “store and forward”.

53 ESTUDIO DEL PROTOCOLO XMPP DE MENSAJERÍA INSTANTÁNEA

Cuando un usuario genera un mensaje, es responsabilidad de los servidores la entrega de dicho mensaje al destinatario pretendido. El destinatario puede estar conectado al mismo servidor que el remitente del mensaje, o no. En el último caso, el remitente necesita establecer una conexión con el otro servidor y entregar el mensaje, que tendrá que ser enrutado hacia el servidor destino.

El cliente de MI debería especificar el destinatario mediante su JID en el atributo to de la stanza . Si el mensaje es una réplica de otro mensaje recibido con anterioridad cuyo remitente tenía un JID determinado (con el formato user@domain/resource), entonces la réplica deberá dirigirse a la misma dirección, incluyendo el resource. Si el mensaje está siendo enviado fuera del contexto de un chat, la parte resource del JID puede obviarse (user@domain).

3.3.4.2. Estructura de los mensajes

Un mensaje básico consiste en un elemento con los atributos from, to e id. Además los elementos se componen de varios subelementos:

- : pensado para indicar el título o asunto relativo al mensaje

- : para identificar la conversación a la que pertenece el mensaje

- : para especificar el contenido del mensaje

- : para especificar que ha ocurrido un error

Un mensaje típico sería el siguiente: ¡Romeo, Romeo! ¿Por qué eres tú Romeo? ¿Por qué no reniegas del nombre de tu padre y de tu madre? Y si no tienes valor para tanto, ámame, y no me tendré por Capuleto.

54 3. ESTADO DEL ARTE

O Romeo, Romeo! wherefore art thou Romeo? Deny thy father and refuse thy name; Or, if thou wilt not, be but sworn my love, And I’ll no longer be a Capulet.

Y su respuesta sería:

¿Qué hago, seguirla oyendo o hablar? Shall I hear more, or shall I speak at this?

Pero muchos de estos campos no son obligatorios. Así, por ejemplo, el id y el son para un manejo más fácil de los mensajes en los clientes, no todos los mensajes tienen por qué tener y, además, el campo from no es necesario, ya que para evitar que una persona envíe mensajes poniendo como origen un Jabber ID que no es el suyo el servidor reescribirá el campo from del paquete antes de enviarlo a su destinatario, así pues, si Julieta se hubiera conectado como el usuario ‘Señora_de_Capuleto’ y enviamos este paquete, a Romeo, a este último no le llegará ningún mensaje con ‘Señ[email protected]/balcon’ en el campo from, sino ‘[email protected]/balcon’.

También es importante señalar que los mensajes pueden contener más de un elemento de cuerpo del mensaje o , dependiendo del idioma utilizado, lo que se especifica con el atributo xml:lang.

En el caso de que la conversación tenga lugar en un contexto de chat, lo que significa que el atributo de tipo del mensaje es type='chat', el emisor de un mensaje es

55 ESTUDIO DEL PROTOCOLO XMPP DE MENSAJERÍA INSTANTÁNEA

responsable de generar un valor de hilo y de copiar dicho valor en los sucesivos mensajes enviados dentro de la sesión, con el fin de vincular todos aquellos mensajes que son réplica del primero.

El tipo por defecto de mensajes es el ‘normal’. Como en el correo electrónico, estos mensajes se pueden enviar sin que el destinatario esté conectado en ese momento, siendo responsabilidad de su servidor de MI el encolamiento y la posterior entrega de dichos mensajes.

Los mensajes que no tienen especificado el tipo son considerados como normales.

Los usuarios usan los mensajes de tipo ‘chat’ para enviarse entre ellos mensajes instantáneos. Estos mensajes suelen ser cortos, ya que se utilizan para llevar a cabo una conversación entre dos personas. Estos mensajes son normalmente mostrados en una interfaz de tipo chat, en la que el usuario puede ir viendo lo que escribe él y lo que escribe su contacto.

Los mensajes de tipo ‘chat’ deben de llevar puesto obligatoriamente el campo del tipo con el valor y no suelen especificar el campo del título del mensaje. Estos mensajes son para conversaciones entre dos clientes únicamente, para conversaciones entre más de dos clientes se usan los mensajes ‘groupchat’.

Los mensajes del tipo ‘groupchat’ son similares a los mensajes del tipo ‘chat’, pero están diseñados para mantener conversaciones entre un grupo de personas sobre un tema en concreto. Por ello, cuando un cliente envía un mensaje al grupo, todos los clientes que se hayan unido al grupo recibirán el mensaje. También se pueden escribir mensajes de tipo ‘groupchat’ de ámbito privado, dirigidos a un usuario en concreto. Para formar parte de un grupo es necesario unirse a él con un sobrenombre ‘nickname’, que será mostrado al resto de los usuarios. De esta forma, es posible ocultar la identidad real de los participantes ya que, si un usuario se conecta al grupo ‘[email protected]’ como ‘July’, a los demás usuarios no les aparecerá su verdadero Jabber ID: ‘[email protected]’, sino que lo que realmente les aparecerá será ‘[email protected]/July’ y todos los mensajes que se envíen al

56 3. ESTADO DEL ARTE

grupo llegarán con ese identificativo, que deberá emplearse para la comunicación efectiva de los miembros del grupo con dicho usuario.

Así, un mensaje que envía el usuario ‘[email protected]’ del grupo ‘[email protected]’ con nick ‘July’, aunque sea privado, le llegará al usuario ‘[email protected]’, que se ha conectado al grupo ‘[email protected]’ con el nick de ‘Romy’, de la siguiente manera: - Mensaje enviado desde el cliente de Julieta:

threadid_04 ¡Romeo, Romeo! ¿Por qué eres tú Romeo?...

- Mensaje recibido en el cliente de Romeo: threadid_04 ¡Romeo, Romeo! ¿Por qué eres tú Romeo?...

Como puede verse el servidor ha cambiado el usuario destino por el Jabber ID original del destinatario, y en el mensaje que ha llegado a Romeo, el origen del mensaje también ha sido cambiado para ocultar su identidad. Si se hubiera querido enviar un mensaje al grupo entero sería igual, salvo el campo to que no llevaría ‘/Romy’.

Los mensajes del tipo ‘headline’ están pensados para enviar información de titulares de noticias para mostrar en la barra de estado o en otras partes de la interfaz de usuarios. Son una especie de servicio de news ticker. Los usan comúnmente los ‘’ para informar de noticias, alertas del tiempo… a los usuarios que se den de alta en estos servicios automatizados. No requieren del las etiquetas o .

57 ESTUDIO DEL PROTOCOLO XMPP DE MENSAJERÍA INSTANTÁNEA

Otro tipo de mensajes son los mensajes de tipo ‘error’, que se envían Cuando un cliente envía un mensaje y se produce un error, ya sea que el cliente al que va dirigido no existe, o que sencillamente el mensaje ha sido rechazado por el cliente destinatario.

Legacy Meaning XMPP error condition XMPP error error code type

302 Redirect (temporary) or modify (permanent)

400 Bad Request modify

401 Not Authorized auth

402 Payment Required auth

403 Forbidden auth

404 Not Found cancel

405 Not Allowed cancel

406 Not Acceptable modify

407 Registration Required auth

408 Request Timeout wait

409 Conflict cancel

500 Internal Server Error wait

501 Not Implemented cancel

502 Remote Server Error wait

503 Service Unavailable cancel

504 Remote Server Timeout wait

510 Disconnected cancel Tabla 3.- Errores más comunes del núcleo de Jabber

Por último están los mensajes de tipo ‘out-of-band’, que no son realmente un mensaje convencional de XMPP, sino una extensión especial de los mensajes que se envía dentro de un mensaje normal. Un mensaje de este tipo contiene información (normalmente una URL) que el cliente desea usar para realizar una transferencia de datos punto-a-punto, sin pasar por el servidor. Los clientes, normalmente, lo suelen implementar arrancando un servidor Web o un FTP separadamente o como parte del cliente Jabber/XMPP. Por lo tanto están dando a otro cliente la información de su IP y el puerto que han abierto para que el otro cliente se descargue el archivo.

58 3. ESTADO DEL ARTE

Esto es ideal para el intercambio de ficheros entre clientes (P2P ) ya que, con ello, consigues reducir el tráfico que pasa por el servidor. Sin embargo, como siempre que un cliente revela su IP tiene sus riesgos, si la persona a la que el usuario envía esta información es un usuario malintencionada podría utilizar la IP con otros fines muy distintos a los de descargarse el fichero que el cliente le está ofreciendo.

3.3.4.3. Listas de Privacidad

Tal y como se requiere en el RFC 2779 (“A model for Presence and Instant Messaging”), es posible que los usuarios bloqueen los envíos de mensajes de otros usuarios. Para ello se utilizan las listas de privacidad.

Las listas de privacidad se gestionan en el servidor y permiten implementar muchas posibilidades de bloqueo, tales como el bloqueo basado en JID, grupo o tipo de suscripción. Se permite el bloqueo de notificaciones de presencia entrantes o salientes basadas en JID, grupo o tipo de suscripción.

Los usuarios pueden definir tantas listas de privacidad como deseen, pudiendo definir reglas diferentes para usuarios diferentes.

Una lista de privacidad consta de:

- : la lista de reglas. Este elemento puede contener una o más reglas <ítem/>. Tiene un atributo ‘name’ que sirve para identificarla.

- <ítem/>: una regla, que se define mediante los atributos ‘type’ (tipo), ‘value’ (valor) , ‘action’ (acción) y ‘order’ (orden).

Los posibles valores del atributo ‘type’ que representa al tipo de regla pueden ser ‘group’, ‘jid’ y ‘suscription’.

Los valores del atributo ‘action’ pueden ser: ‘allow’o ‘deny’, que definen el comportamiento de la regla (permitir o denegar).

Las listas de privacidad se distribuyen siempre dentro de una stanza , tal y como se muestra en el siguiente ejemplo, que podría haber sido enviado por el propio servidor de MI.

59 ESTUDIO DEL PROTOCOLO XMPP DE MENSAJERÍA INSTANTÁNEA

3.3.5. La Presencia en XMPP

3.3.5.1. El concepto de presencia

Por sí solas, las tecnologías de MI actuales, como el protocolo XMPP, contribuyen a aumentar la productividad de las organizaciones que las emplean. Pero cuando además se combinan con información de presencia sobre dónde se encuentran sus usuarios, qué dispositivos o aplicaciones están usando y cómo mejor contactar con ellos, esas herramientas ayudan a crear un espacio de trabajo virtual en el que los usuarios pueden conseguir rápidamente la información que necesitan y donde, sobre la marcha, se pueden organizar y mantener reuniones virtuales.

Para muchos expertos, la presencia tiene todo el potencial para convertirse en la “killer application” que revolucionará el modo en que las organizaciones se comunican y colaboran entre sí. Los usuarios de sistemas de MI ya sacan buen partido de ella, pero estas tecnologías poco a poco van dejando de estar asociadas exclusivamente a estos sistemas y convirtiéndose en parte de los sistemas de gestión de estas organizaciones, así como de sus sistemas de comunicaciones corporativas (e incluso de las tácticas, en el caso de los usos militares que están teniendo estas tecnologías) como lo son la telefonía móvil y la telefonía IP. Como afirma la consultora Nemertes Research, en el futuro, la

60 3. ESTADO DEL ARTE

presencia será la capacidad de red subyacente, e MI será solo una de las muchas aplicaciones que se beneficien de sus ventajas.

Dado que la presencia es un concepto y no una tecnología en sí, no existe una definición de consenso respecto a lo que significa. En pocas palabras, la detección de presencias en la red o, más abreviadamente, de presencia, se puede definir como la capacidad de los sistemas de mensajería instantánea que permite a los usuarios y dispositivos encontrarse y, en consecuencia, contactarse rápidamente, con independencia de la localización física. Para ello, un servidor o servidores centrales hacen el seguimiento de los usuarios en función de cuando entran y salen de la red.

Veamos un ejemplo real: un ejecutivo de ventas apaga su teléfono móvil de tipo Smartphone cuando va a visitar a un cliente. No puede responder a ninguna llamada. Cuando termina la reunión, si se acuerda de activar el teléfono de nuevo, el ejecutivo ya estará disponible para que cualquiera le llame al teléfono móvil, pero sin información de presencia, nadie sabrá en qué momento podrá llamar con cierta seguridad de que podrá atenderle. Ahora imagine que puede seleccionar una función del teléfono que le permite saber en qué momento sus compañeros pueden atender sus llamadas. Imagine que otras personas pueden saber en qué momentos está ocupado y no puede responder llamadas. Eso es precisamente de lo que se ocupa la tecnología de presencia, que permite a unas personas saber en qué momentos otras personas están conectadas a la red y cuándo están disponibles. Los teléfonos móviles de hoy día, disponen de software que permite conectarse al calendario personal y cambiar automáticamente su estado a "ocupado" al comenzar una reunión y devolver el estado a "disponible" cuando la reunión haya terminado. Además, puede cambiar el estado a "no disponible" al irse a dormir. Esto permite, por ejemplo, enrutar inteligentemente las llamadas que se reciban en la oficina hacia su móvil, cuando el ejecutivo esté reunido fuera de ella, o permitir que sus contactos se suscriban a su información de presencia, por lo que al término de la reunión, se publique la ubicación y disponibilidad de este ejecutivo para localizarlo en el móvil, en su despacho, etc.

61 ESTUDIO DEL PROTOCOLO XMPP DE MENSAJERÍA INSTANTÁNEA

3.3.5.2. Descripción técnica del protocolo de presencia

XMPP se ha preocupado de la intimidad de los usuarios. Si un usuario quiere agregar a otro en su lista de contactos, esto implica recibir su presencia, por lo que debe solicitarlo a través del servidor. Los usuarios tienen derecho a la intimidad y serán ellos mismos quienes decidan quién puede conocer su estado actual y quién no.

El protocolo de presencia es usado principalmente en dos contextos:

- Presence update: actualización de la presencia debido a un cambio de estado del usuario.

- Presence subscription management: permite a los usuarios subscribirse a las actualizaciones de presencia de otros usuarios y controlar quien está accediendo a su propia presencia.

En ambos casos el servidor de XMPP actúa como árbitro entre el emisor de la actualización de presencia y los destinatarios de la misma. El servidor tiene la obligación de hacer llegar el paquete de actualización de presencia a todos los contactos del cliente que lo generó, pero sólo a los contactos que el cliente emisor ha confirmado que le gustaría que recibieran su presencia.

El servicio de actualización de presencia usa un simple mensaje unidireccional del emisor al servidor de su dominio. El servidor tendrá que copiar y reenviar ese mensaje de presencia a todos los clientes del emisor. Para ello, el servidor puede consultar la lista de contactos del emisor para conocer quiénes son sus contactos. Esta lista de contactos en XMPP recibe el nombre de Roster.

Así, la lista de contactos (roster), se guarda en el servidor XMPP. La ventaja que tiene este modelo centralizado es mantener siempre los rosters actualizados, aunque se cambie de aplicación cliente XMPP o de ordenador.

Los mensajes de presencia viajan en stanzas . Estas stanzas, a diferencia de las de tipo , no se dirigen a un usuario específico. Pueden incluir un atributo ‘to’, pero, generalmente, las stanzas se envían al servidor, que es el que luego notificará la presencia a los contactos del cliente.

62 3. ESTADO DEL ARTE

La presencia de XMPP funciona como un mecanismo de publicación-subscripción (publish/subscribe o PUB/SUB). Así, los clientes enviarán y recibirán mensajes de suscripción de presencia de dos tipos: ‘subscribe’ y ‘unsubscribe’. Este tipo de suscripción de presencia también se emplea en los mensajes de grupo ‘groupchat’.

Cuando cambia el estado de presencia en un cliente, este lo publica en el servidor para que este último lo notifique a los suscriptores de esa presencia.

Una vez que se establece una sesión con el servidor, el cliente XMPP debe enviar primero su información de presencia al servidor de forma que se comunica su disponibilidad para la comunicación. Esta notificación inicial de presencia permite al servidor enviar una prueba de disponibilidad a los usuarios suscritos a la presencia del cliente que acaba de conectarse.

3.3.5.3. Cambios en el estado de presencia de los clientes

Si el usuario quiere cambiar su estatus, el proceso sigue unos sencillos pasos. Así, desde el cliente XMPP del usuario se genera una stanza con toda la información necesaria.

En cualquier momento, durante la sesión, el cliente puede enviar una stanza de presencia al servidor sin especificar ningún atributo de tipo, de forma que funciona como un keepalive o mensaje de notificación de que el usuario continúa conectado, u ocupado.

En el caso de recibir un mensaje de presencia, el servidor difunde el mismo mediante broadcasting a cada una de las entidades del roster del remitente cuyo atributo de tipo de suscripción es ‘from’ o ‘both’. Más información de la disponibilidad de los usuarios se especifica mediante los elementos y .

Los elementos incluyen datos legibles expresados en lenguaje natural que describan el estado de la disponibilidad, que puede expresarse en varios idiomas tal y como permite el atributo ‘xml:lang’.

63 ESTUDIO DEL PROTOCOLO XMPP DE MENSAJERÍA INSTANTÁNEA

Los elementos incluyen ciertos valores que expresan diferentes estados de disponibilidad de una entidad, están codificados para que puedan ser interpretados por el servidor.

Los clientes XMPP usarán normalmente el estado para mostrar iconos de presencia estándar, alertas sonoras y lanzar eventos. Si el estado no está indicado, el usuario se encuentra en estado normal u online. Los estados estándar para son:

- ‘chat’: el usuario está intentando hablar con alguien.

- ‘away’: el usuario está fuera del cliente XMPP por un corto periodo de tiempo.

- ‘xa’ (extended away): el usuario está fuera por un periodo prolongado de tiempo.

- ‘dnd’ (do not disturb): el usuario no desea recibir mensajes.

El protocolo permite la extensibilidad de estados codificados, ya que pueden definirse otros espacios de nombres para añadir otros subelementos a la stanza .

Un ejemplo de mensaje de notificación de presencia podría ser el siguiente: dnd Viendo las estrellas con Julieta… Watching the stars with Juliet…

3.3.5.4. Suscripciones de presencia

Las suscripciones de presencia y sus respectivas cancelaciones se realizan empleando la stanza de . Las suscripciones se dirigen a un destinatario mediante el

64 3. ESTADO DEL ARTE

atributo ‘to’ del elemento e indicando un tipo de mensaje mediante el atributo ‘type’, que admite los siguientes valores:

- ‘available’: mensaje de actualización que indica que el usuario está listo para recibir mensajes;

- ‘unavailable’: mensaje de actualización que indica que el usuario no está disponible para recibir mensajes;

- ‘subscribe’: mensaje de petición de suscripción de presencia, el usuario que lo envía desea suscribirse a la presencia del destinatario;

- ‘unsubscribe’: mensaje de cancelación de suscripción de presencia, el usuario que lo envía desea cancelar su suscripción a la presencia del destinatario;

- ‘subscribed’: respuesta que recibirá un usuario que ha realizado una petición de suscripción, que indica el estado actual de la suscripción;

- ‘unsubscribed’: respuesta que recibirá un usuario que ha realizado una petición de suscripción y le ha sido negada, o bien una petición de cancelación de la suscripción aceptada;

- ‘error’: mensaje estándar de error de XMPP que indica problemas en la presencia;

- ‘probe’: petición Servidor-a-Servidor que envía toda la información de presencia de un servidor a otro.

Un ejemplo de actualización de presencia es el siguiente: Estoy aburrida, que alguien me hable… 10 chat

65 ESTUDIO DEL PROTOCOLO XMPP DE MENSAJERÍA INSTANTÁNEA

Normalmente se están mostrando los campos opcionales en todos los ejemplos para hacerlos más claros, pero un ejemplo mucho más corto de presencia podría ser simplemente , en el que el cliente simplemente indicaría a sus contactos que está presente. Pero un ejemplo mucho más típico y compacto que el primero sería el siguiente: Estoy aburrida, que alguien me hable… chat

El efecto sería prácticamente el mismo que el primero, salvo la prioridad del mensaje, y como puede observarse este ejemplo consumiría bastante menos ancho de banda de la red empresarial que el primero. Y en ambos casos a los contactos, les llegaría el mismo mensaje: Estoy aburrida, que alguien me hable… chat

Esto es debido a que como en el protocolo de mensajes, el servidor reescribirá el atributo ‘from’ y añadirá el campo ‘to’ para cada uno de los contactos que deban recibir la presencia.

Los paquetes de suscripción de presencia usan un protocolo de peticiónrespuesta. Este sería un ejemplo de una petición de suscripción:

Y, a continuación, esta podría ser la respuesta de confirmación de la suscripción:

66 3. ESTADO DEL ARTE

3.3.5.5. Manejo del Roster

La suscripción de presencia tiene la ventaja de reducir considerablemente el tráfico de red de un sistema de MI al no tener que hacer broadcasting o difusión masiva de los estados de presencia de los usuarios.

Para organizar y administrar las suscripciones de cada usuario, XMPP ha definido unas estructuras de datos estándar conocidas como roster. Un XMPP roster no es más que una lista de contactos identificados por su Jabber ID. El protocolo de suscripción de presencia permite a los usuarios suscribirse a la presencia de otros usuarios, sea cual sea su dominio en una red XMPP. Los servidores usan el protocolo de suscripción de presencia para sincronizar los rosters para sus usuarios tanto fuera como dentro de su dominio.

Los diferentes tipos de relaciones de suscripción tratados por el roster son los siguientes:

- ‘to’: el usuario está interesado en recibir las actualizaciones de presencia del suscriptor.

- ‘from’: el suscriptor está interesado en recibir las actualizaciones de presencia del usuario.

- ‘both’: el usuario y el suscriptor tienen un mutuo interés en recibir las presencias entre ellos.

- ‘none’: ni el usuario ni el suscriptor tienen interés por recibir presencias entre ellos.

Además de la información básica de suscripción, el roster permite al usuario almacenar información estándar del interfaz de ese suscriptor. Esta información incluye un sobrenombre puesto por el usuario a su suscriptor y el grupo o grupos al que pertenece el suscriptor a la hora de mostrarlo en la interfaz.

Una de las cosas más importantes es que toda esta información está almacenada y administrada por el servidor. Esto simplifica notablemente la implementación y permite al usuario tener disponible dicha información allí donde se encuentre. Cualquier cambio

67 ESTUDIO DEL PROTOCOLO XMPP DE MENSAJERÍA INSTANTÁNEA

realizado en el roster en uno de los clientes será automáticamente actualizado en los demás clientes iniciados con el mismo Jabber ID. El protocolo roster fue desarrollado para permitir a los clientes XMPP la administración de sus contactos.

A pesar de la estrecha relación entre el roster y la presencia, son conceptos diferentes. Digamos que el roster es todo el conjunto de contactos relacionados con una cuenta Jabber o XMPP. Además podemos guardar datos de cada contacto como un sobrenombre puesto por el usuario o el grupo o grupos al que pertenece para poder así buscar todos los contactos de un grupo, y no tener que recorrernos todos los contactos. Como cada usuario tendrá su propio roster, si enviamos una actualización de presencia al servidor, éste buscará en nuestro roster todos los contactos que tengan los tipos de suscripción ‘both’ o ‘from’ para reenviarles sólo a ellos nuestra presencia.

Como todo se almacena en el servidor, el cliente comenzará nada más autentificarse pidiendo todo el roster al servidor con un ‘roster reset’. Mostrará entonces todos los contactos del roster en la aplicación. Si más adelante el usuario desea hacer cambios en algún contacto del roster enviará un ‘roster update’ al servidor y se quedará esperando un ‘roster push’ del servidor para confirmar la actualización a todos los clientes abiertos con el mismo Jabber ID, ya que, si uno de ellos realiza un cambio, éste se tiene que reflejar en el resto.

El protocolo roster es una extensión del protocolo IQ. Los tres tipos básicos de protocolos de gestión del roster son:

- ‘Roster get’: usado por los clientes para obtener una copia del roster almacenado en el servidor.

- ‘Roster update’: usado por los clientes para actualizar el roster almacenado en el servidor.

- ‘Roster push’: actualizaciones asíncronas del roster que el servidor envía a los clientes.

Los cambios del roster pueden suceder en cualquier momento desde que un usuario se autentifica, por lo tanto los clientes deben estar preparados para recibir del servidor

68 3. ESTADO DEL ARTE

‘roster push’ y actualizar los contactos que muestran en ese momento. El servidor enviará un ‘roster push’ cuando:

- Una actualización del roster cambie los atributos del mismo, y se deba actualizar los clientes mostrados o alguno de sus atributos.

- Cuando por algún cambio en el tipo de suscripción de presencia se deba crear o borrar un contacto.

Como se ha visto el protocolo de suscripción de presencia tiene grandes efectos sobre el roster, tantos que una actualización del tipo de suscripción puede hacer desaparecer de la pantalla del usuario un contacto, ya que si el contacto no desea ser visto por el usuario y envía una cancelación de la suscripción de presencia poniéndola a ‘none’ el usuario debe de dejar de ver el estado de ese contacto lo antes posible.

Los clientes sólo pueden modificar el apodo de sus contactos y el grupo o grupos a los que pertenecen mediante el protocolo roster. Además, como hemos visto pueden influir en el roster mediante el protocolo de suscripción de presencia.

El diseño de las suscripciones de presencia y los roster de XMPP facilitan el desarrollo de los clientes Jabber/XMPP, ya que los clientes no deben almacenar esos datos, ni tampoco se deben de preocupar de cómo modificarlos o administrarlos, lo único que deben hacer es realizar peticiones al servidor y será éste quien se encargue de su procesamiento. Además el servidor se debe encargar de que cuando el usuario se desconecte o conecte, todos sus suscriptores reciban una actualización de presencia.

Aun así los clientes son libres de enviar de por sí actualizaciones de presencia a otros usuarios. Sin embargo si esto se realiza, el cliente deberá gestionar que actualiza la presencia de todos sus contactos, mientras que si lo hace a través del roster, sólo le enviará la actualización de presencia al servidor y será éste quien lo gestione.

3.3.5.5.1. Descarga del roster

Permite a los clientes obtener una copia completa del roster almacenado en su servidor XMPP. Para ello se debe enviar un mensaje IQ de tipo get vacío especificando el protocolo ‘jabber:iq:roster’.

69 ESTUDIO DEL PROTOCOLO XMPP DE MENSAJERÍA INSTANTÁNEA

Lo primero que hará un cliente XMPP al establecer una sesión con su servidor, será, normalmente, solicitarle su roster (algunos clientes XMPP pueden no hacerlo para reducir el tráfico de red cuando no hay mucho ancho de banda disponible y tienen forma de almacenar localmente los roster).

Y el servidor contestará con una copia completa del roster. Amigos Amigos Amigos

Hay que tener en cuenta que el paquete puede tener cero o más paquetes . Cada paquete representa una suscripción de un contacto, y ese contacto pertenecerá a cero o más grupos, identificados por cero o más paquetes . La etiqueta es opcional aunque generalmente siempre se utiliza para que el cliente muestre un nombre en los contactos en lugar del Jabber ID del contacto.

70 3. ESTADO DEL ARTE

3.3.5.5.2. Actualización del roster: inserción, modificación y borrado

En cualquier momento, un usuario puede añadir un contacto a su roster. Para hacer esto, el cliente enviará un mensaje a su servidor de la siguiente manera: Sirvientes

Para modificar su roster, los clientes XMPP deben enviar también una stanza IQ de tipo ‘set’ conteniendo dentro del paquete el item a actualizar.

El servidor deberá actualizar la información del roster del usuario en su base de datos y además tendrá que hacer un roster push hacia todos los recursos disponibles del usuario que ha solicitado el roster. Este ‘roster push’ consiste en un mensaje IQ del tipo ‘set’ que se lanza desde el servidor al cliente y permite que todos los recursos disponibles del cliente se sincronicen con el roster que almacena el servidor. Este mensaje ‘roster push’ es de los únicos mensajes IQ que no obtienen respuesta, sólo van del servidor a los clientes y éstos no tienen que responder.

En el ejemplo siguiente se muestra, en primer lugar, cómo el Servidor XMPP hace un push de la información actualizada del roster hacia todos los recursos de un usuario y, en segundo lugar, cómo responde con un IQ de resultado al remitente. Sirvientes

71 ESTUDIO DEL PROTOCOLO XMPP DE MENSAJERÍA INSTANTÁNEA

Sirvientes

El protocolo requiere, demás, que cada recurso que reciba el roster replique con una stanza IQ de tipo ‘result’ o ‘error’:

Si un cliente borra su suscripción del roster usando el protocolo de suscripción, el ‘roster ítem’ de esa suscripción sería borrado del servidor. El servidor enviaría un ‘roster push’ a todos los clientes indicando lo acontecido con un mensaje IQ de tipo ‘set’ y poniendo el atributo subscription con el valor ‘remove’. El cliente entonces borraría ese ítem de entre los contactos que está mostrando.

Para borrar un ítem de su roster, el cliente envía el siguiente mensaje al servidor:

72 3. ESTADO DEL ARTE

De la misma forma que al añadir un ítem al roster, cuando se borra un ítem del roster, el servidor debe actualizar la información del roster en su base de datos, iniciando un protocolo de ‘roster push’ hacia todos los recursos disponibles del usuario (especificando subscription='remove' en el ítem borrado), y enviar un resultado IQ al recurso que inició el borrado.

3.3.5.6. Prioridades de los recursos

Al contrario que otras redes de MI, las redes basadas en XMPP permiten a sus usuarios conectarse simultáneamente desde varios dispositivos, desde lugares diferentes. Para hacer esto, cada vez que un usuario inicia sesión, se etiqueta esa sesión con una etiqueta de recurso. Por ejemplo, se puede llamar a un recurso “casa”, a otro “trabajo” y a otro “portátil”. A cada uno de esos “recursos” se les puede asignar un número de prioridad que servirá para discriminar a qué sesión se entregan los mensajes cuando el usuario tiene abierta más de una.

El elemento opcional contiene un valor relacionado con el nivel de prioridad del recurso. Dicho valor debe ser un número entero entre -128 y +127. Las stanzas de presencia no pueden tener más de un elemento , que a su vez no puede tener atributos. Cuando no se especifica ningún elemento como hijo de un elemento , el servidor XMPP considerará un valor cero de prioridad.

Cuando un servidor recibe una stanza que va dirigida a un JID con la forma y hay al menos un recurso disponible del usuario, el elemento de prioridad sirve para determinar lo que hay que hacer.

Un ejemplo de actualización de presencia es el siguiente: Estoy aburrida, que alguien me hable… 10 chat

73 ESTUDIO DEL PROTOCOLO XMPP DE MENSAJERÍA INSTANTÁNEA

En el caso de stanzas de mensaje, el servidor debe entregar la stanza al recurso de más alta prioridad. Si hay dos o más recursos disponibles con la misma prioridad, el servidor aplicará cualquier otra regla que implemente (por ejemplo, el recurso que menos tiempo lleve conectado o aquel que muestre un nivel de disponibilidad mayor en su cláusula ) o bien entregará el mensaje a todos los recursos disponibles. En el caso de que el mensaje fuera dirigido a un JID en el que el recurso tiene una calificación negativa de la prioridad, dicho mensaje no deberá ser entregado a ese recurso. En el caso de que no hubiera disponible ningún recurso con prioridades positivas, entonces serán de aplicación las reglas de manejo de las stanzas por el servidor, tal y como se definen en el RFC 3921.

3.3.5.7. Presencia dirigida

Un usuario puede también enviar un mensaje de presencia que incluya un atributo ‘to’ según una serie de casos especiales. En esos casos, el valor del atributo de tipo tiene que ser ‘unavailable’ (type=’unavailable’) o bien no especificar ningún valor en absoluto. Los casos en que se permite esto son los siguientes:

Si el usuario envía un mensaje de presencia dirigido a un contacto que está en su roster marcado con una suscripción del tipo ‘from’ o ‘both’ después de haber enviado la presencia inicial y antes de enviar el broadcast final de presencia no disponible (type=‘unavailable’), el servidor XMPP deberá enrutar o entregar el mensaje de presencia completo e inalterado (sujeto a las reglas de las listas de privacidad existentes), así como tener en cuenta a dicho contacto en futuros broadcast de presencia del usuario.

Si el usuario envía un mensaje de presencia dirigido a un contacto que no está en su roster marcado con una suscripción del tipo ‘from’ o ‘both’ después de haber enviado la presencia inicial y antes de enviar el broadcast final de presencia no disponible, el servidor XMPP deberá enrutar o entregar el mensaje de presencia completo e inalterado (sujeto a las reglas de las listas de privacidad existentes), así como tener en cuenta a dicho contacto en futuros broadcast de presencia del usuario (para no incluir al contacto en los mismos). Cuando cambie a ‘unavailable’ la

74 3. ESTADO DEL ARTE

disponibilidad del recurso desde el que el usuario haya enviado el mensaje de presencia dirigido, el servidor deberá hacer broadcast de dicho cambio al contacto al que iba destinado el mensaje de presencia dirigido.

Si el usuario envía el mensaje de presencia dirigido antes de enviar primero la presencia inicial o después de haber enviado un broadcast de indisponibilidad (el recurso está activo pero marcado como no disponible), el servidor XMPP debe tratar las entidades destinatarias a las que el usuario envió presencia dirigida de la misma forma que en el caso anterior.

3.3.5.8. Presencia final

Antes de terminar su sesión XMPP con el servidor, un cliente debe informar al servidor, así como a todas aquellas entidades suscritas a sus datos de presencia, enviando un mensaje al servidor. Esta stanza no tiene un atributo ‘to’ y el atributo type tiene que tener asignado el valor ‘unavailable’. También puede incluir un elemento especificando la razón por la que el usuario abandona. El servidor de los usuarios envía la stanza final de presencia a todas las entidades que tienen valores de suscripción ‘from’ y ‘both’. También, si el usuario ha enviado una presencia dirigida a una serie de entidades, el servidor deberá enviar la información de presencia a todas ellas aunque no estuvieran en el roster del usuario.

3.3.5.9. Ejemplos de presencia

Los ejemplos que se presentan a continuación ilustran el comportamiento del protocolo de presencia descrito en los apartados anteriores. Para todos ellos, se asume que el usuario es [email protected], que tiene un recurso disponible llamado ‘huerto’ y que tiene a los siguientes contactos almacenados en su roster:

- ‘[email protected]’, con atributo de suscripción de tipo ’both’ y que tiene dos recursos disponibles llamados ‘habitacion’ y ‘balcon’

- ‘[email protected]’, con atributo de suscripción de tipo ’to’)

- ‘[email protected]’, con atributo de suscripción de tipo ’from’)

75 ESTUDIO DEL PROTOCOLO XMPP DE MENSAJERÍA INSTANTÁNEA

Ejemplo Nº 1: Romeo, el usuario, envía su presencia inicial:

Ejemplo Nº 2: El servidor del usuario envía pruebas de presencia a sus contactos cuyos atributos de suscripción cumplen subscription=’to’ y subscription=’both’ incluyendo en el remite el recursos disponible del usuario:

Ejemplo Nº 3: El servidor del usuario envía pruebas de presencia a sus contactos cuyos atributos de suscripción cumplen subscription=’to’ y subscription=’both’ incluyendo en el remite el recursos disponible del usuario:

Ejemplo Nº 4: Los servidores de los contactos contestan la prueba de presencia en nombre de todos sus recursos: away vuelvo enseguida 0

76 3. ESTADO DEL ARTE

1

dnd durmiendo

Ejemplo Nº 5: Los servidores de los contactos entregan la presencia inicial de todos los recursos disponibles de los contactos, o bien devuelven un error al usuario:

Ejemplo Nº 6: El usuario envía un mensaje de presencia dirigido a otro usuario que no está en el roster del primero:

77 ESTUDIO DEL PROTOCOLO XMPP DE MENSAJERÍA INSTANTÁNEA

[email protected]' xml:lang='en'> dnd cortejando a Julieta 0

Ejemplo nº 7: El usuario hace broadcast de su disponibilidad: away ¡Volveré en un par de horas! 1

Ejemplo Nº 8: El servidor del usuario hace broadcast con la información actualizada de presencia sólo a un contacto (que no puede ser ninguno de los que se haya recibido un error o a los que se hubiera enviado directamente la información de presencia): away ¡Volveré en un par de horas! 1

Ejemplo Nº 9: El servidor de los contactos entrega información actualizada de presencia a todos los recursos disponibles del contacto: away ¡Volveré en un par de horas! 1

78 3. ESTADO DEL ARTE

from='[email protected]/huerto' to='[email protected]/habitacion' xml:lang='en'> away ¡Volveré en un par de horas! 1

Ejemplo Nº 10: Uno de los recursos del contacto hace broadcast de la presencia final:

Ejemplo Nº 11: El servidor del contacto envía estado no disponible al usuario Romeo:

Ejemplo Nº 12: El usuario Romeo envía su estado final de presencia: gone home

Ejemplo Nº 13: El servidor del usuario hace broadcast de su estado de no disponibilidad a todos sus contactos así como a todos aquellos que hubieran recibido presencia dirigida a ellos: me he marchado…

79 ESTUDIO DEL PROTOCOLO XMPP DE MENSAJERÍA INSTANTÁNEA

[email protected]' xml:lang='en'> me he marchado…

3.3.6. Consideraciones de seguridad en XMPP

La mensajería instantánea se ha convertido en una tecnología ampliamente utilizada. El incremento de su uso ha venido acompañado de de una serie de amenazas para la seguridad de los usuarios y, especialmente, de las redes de las organizaciones en las que se emplea.

La mensajería instantánea en el lugar de trabajo puede ser peligrosa, aunque también muy útil y productiva.

El empleo de la mensajería instantánea en el lugar de trabajo podría conducir a un compromiso en la confidencialidad de los datos que se transmitieran por este medio. Así, cuando se transmite un fichero por MI, existe el riesgo de que un hacker estuviera escuchando el tráfico e interceptase el fichero desde la red, dado que algunas de las redes de MI de las que se ha descrito su arquitectura en este documento están basadas en una arquitectura pura de cliente-servidor, como ocurre con XMPP.

Con los últimos clientes de MI es posible que los usuarios puedan compartir archivos, carpetas o, incluso, una unidad de disco de la red. Exponiendo su contenido a posibles intrusos o programas maliciosos.

No obstante, es posible para una organización disponer de su propio servidor, que maneje todo el tráfico internamente, en la red privada, no permitiendo conexiones hacia fuera, hacia otros dominios, a través de Internet.

Generalmente, las redes MI presentan, al menos, los siguientes riesgos de seguridad: 1) Es un medio de comunicación controlado externamente. Los clientes de MI más habituales se instalan por los propios usuarios, configurando así conexiones entre el software cliente que corre en sus dispositivos y el software de servidor que corre en un servidor en alguna parte de Internet. Una vez que el tráfico llega al servidor, se pasa al cliente de MI de destino, que

80 3. ESTADO DEL ARTE

también estará en cualquier otra parte de Internet. Esto significa el proveedor de servicios tiene la ventaja de poder escudriñar entre el tráfico de mensajes generado por sus usuarios, pudiendo interceptar si se lo propone el envío de ficheros adjuntos. Por supuesto, también sería posible interceptar la comunicación, dado que se transmite a través de Internet, utilizando el típico ataque de tipo maninthemiddle, en el que el atacante esnifa paquetes TCP/IP de la red, los modifica y los retransmite de nuevo, lo que recibe el nombre de TCP hijacking. 2) Punto de entrada de código malicioso. Los usuarios de MI pueden intercambiar fácilmente ficheros entre sí. Dichos ficheros podrían estar infectados con un virus informático, pudiendo contener código malicioso en forma de gusano, troyano, etc. En la actualidad, existen cientos de virus clasificados que se propagan a través de las redes de intercambio de ficheros P2P y de las redes de MI. A pesar de que la mayoría lo hace, todavía existen antivirus que no entienden los protocolos de MI. Ese desconocimiento podría resultar en un robo de información si uno de los virus que se transmitan en uno de esos ficheros logra localizar datos sensibles almacenados en el equipo local del cliente y transmitirlos a través de Internet a otras entidades. En el caso de troyanos y gusanos, también podría derivar la situación en un ataque de denegación de servicio, cuyo objetivo es disminuir la disponibilidad de un sistema o una red. 3) Suplantación de identidad. Con las soluciones más comunes de MI, una vez que se instala el software del cliente, se pueden añadir contactos al roster del usuario y este se puede comenzar a comunicar con ellos. Todo lo que se necesita por parte de esos contactos para ser incluidos en el roster del usuario es la confirmación de los mismos, que suele ser aprovechado por usuarios maliciosos para tratar de suplantar la identidad.

3.3.7. Extensiones del protocolo: JEPs/XEPs

Los protocolos Jabber/XMPP han estado evolucionando dentro de Jabber y de otras comunidades de internet desde 1999. Los protocolos base de comenzaron su proceso de

81 ESTUDIO DEL PROTOCOLO XMPP DE MENSAJERÍA INSTANTÁNEA

estandarización en el año 2002. El XMPP Working Group continuó trabajando en las áreas de seguridad internacionalización y privacidad mucho después de que los protocolos fueran aprobados por el IETF como RFCs 3920 y 3921 en el año 2004. Independientemente de esto, el XMPP Working Group desarrollo los RFCs 3922 y 3923 que establecían el protocolo de interoperabilidad segura para MI y presencia. Desde 2001, la Jabber Software Foundation (JSF) ha venido gestionando los protocolos Jabber mediante un proceso de estándares abiertos orientado al desarrollo de propuestas de mejora llamadas XMPP Enhancement Proposals (XEPs), también llamadas Jabber Enhancement Proposals (JEPs) en los inicios de la historia del protocolo XMPP.

Hay dos tipo de extensiones XMPP, las que promueve la propia XMPP Standards Foundation (antes JSF), y el segundo grupo es el que se deriva del trabajo, la investigación y las implementaciones de la comunidad de desarrolladores de XMPP.

3.3.7.1. Introducción

La XMPP Standards Foundation (XSF) nació para desarrollar extensiones XMPP a través de procesos de estándares abiertos. Para regular la forma de proponer y mantener estas extensiones a lo largo de su ciclo de vida, se definió lo que ha venido a llamarse proceso de estándares abiertos u “open standards process”, cuyas especificaciones contiene la XEP-0001 (“XMPP Extension Protocols”).

En la práctica la mayoría del trabajo se realiza durante la elaboración de los XMPP Enhancement Proposals (XEPs), según el cual una extensión a XMPP atraviesa una serie de fases hasta su aprobación definitiva. El proceso, lo mantiene el XEP Editor, que es el responsable de todo el mantenimiento de las XEPs. El editor gestiona proceso trabajando con los autores de las XEPs y manteniendo actualizada toda la información retroceso. El Standards SIG es un medio para la discusión del desarrollo del protocolo XMPP. La mayoría de las comunicaciones relacionadas con el desarrollo del protocolo tienen lugar en la lista de correo del Standards SIG, hasta que son revisadas por el XMPP Council. El XMPP Council es un grupo de dirección técnica elegido por los miembros de la XSF.

82 3. ESTADO DEL ARTE

El proceso de estándares abiertos que se emplea define una serie de estados por los que pasa una propuesta de extensión del protocolo XMPP: - Final/Definitivo: El protocolo definido debe considerarse una tecnología estable, lista para ser implementada y desplegada. - Draft/Borrador: El protocolo definido se recomienda y es apropiado para su implementación y despliegue en un sistema de producción, pero todavía se realizarán algunos cambios antes de cambiar al estado Standard Final/Definitivo. - Experimental/Experimental: No existe ninguna garantía de que pueda ser aprobado. Sólo se recomienda a efectos de prueba de concepto. No se recomienda su implementación y despliegue en sistemas de producción hasta que alcance el estado de Draft/Borrador. - Proposed/Propuesto: El JEP está en este momento en fase de Last Call o bien bajo consideración del Jabber Council. - Active/Activo: El proceso o actividad definida ha sido aprobada. Este estado significa que se está trabajando sobre el JEP. Este estado perdura hasta descatalogue el JEP (deprecated/obsolete).

Ilustración 19. Estados del ciclo de vida de un XEP

83 ESTUDIO DEL PROTOCOLO XMPP DE MENSAJERÍA INSTANTÁNEA

El proceso de estándares abiertos, en este contexto, significa que cualquier persona interesada en contribuir al desarrollo de XMPP, enviando propuestas de definición de nuevos protocolos que extiendan XMPP, o documentando los protocolos existentes, pueden hacerlo de una manera efectiva y ordenada.

3.3.7.2. Tipos de XEPs

De un modo muy general, se pueden clasificar las extensiones del protocolo o XEPs en cinco tipos: Históricas, Humorísticas, Informativas, Procedimentales y Estándares.

De todas ellas, las de tipos Informativas y Estándares son las que realmente importan a los desarrolladores de aplicaciones de XMPP. Las extensiones de tipo Históricas y Procedimentales son de interés para la comunidad de miembros de la XSF.

En el Apéndice A, se puede consultar una lista de las extensiones catalogadas por la XSF, con su estado actual y fechas de introducción.

3.3.7.3. Algunas de las XEPs más importantes

Las siguientes extensiones son algunas de las más implementadas en el software comercial de aplicaciones XMPP: - XEP0004: Data Forms. Esta especificación define una extensión de protocolo XMPP para formularios de datos que pueden utilizarse para el intercambio de datos estructurados. El protocolo 'jabber:x:data' descrito por esta extensión define un formato muy flexible para permitir tal intercambio de datos estructurados entre entidades XMPP, siendo un enfoque más elaborado que las listas de pares atributo-valor (tiene en cuenta una serie de tipos de datos específicos de Jabber/XMPP) pero menos complejo que el estándar XForms 1.0. El protocolo incluye semánticas ligeras para el procesamiento de los formularios (solicitud, respuesta, envío, cancelación), define muchos tipos de datos comunes, tal y como se definen los formularios en XHTML (booleanos, listas de opciones de única o múltiple elección, texto con o sin múltiples líneas, JabberIDs únicos o múltiples, campos ocultos,

84 3. ESTADO DEL ARTE

etc.), proporciona extensibilidad para tipos de datos futuros, y puede emplearse en una serie amplia de aplicaciones. - XEP0030: Service Discovery. Esta especificación define una extensión al protocolo XMPP que permite el descubrimiento de información entre entidades XMPP. Se puede descubrir dos tipos de información: (1) la identidad y capacidades de una entidad, incluyendo los protocolos y funcionalidades que soporta; y (2) los elementos asociados a la entidad, tales como la lista de salas en un servicio de chat multiusuario. Funciona de un modo similar a los servicios de descubrimiento que define el protocolo SOAP. Esta extensión es una evolución de dos anteriores, la XEP0011 (Jabber Browsing) y la XEP0094 (Agent Information). - XEP0045: MultiUser Chat. Esta es una extensión al protocolo XMPP que permite el establecimiento de sesiones de chat entre múltiples usuarios (no 1 a 1, como define el core del protocolo XMPP). Los múltiples usuarios acceden a una sala o canal, de una manera muy similar al IRC. Además de las típicas características de las salas de chat tales como los temas de conversación de las salas y las invitaciones, el protocolo define un modelo de control de las salas más poderoso, que incluye la posibilidad de reprensión y expulsión de participantes, la delegación de poderes en moderadores de salas y administradores, el establecimiento de controles de acceso a las salas, etc. - XEP0071: XHTMLIM. Esta especificación define la integración con la norma W3C XHTML 1.0 de forma que los mensajes intercambiados entre entidades XMPP contengan marcas de formato estándares. El protocolo permite a una entidad XMPP formatear un mensaje utilizando un pequeño juego de etiquetas HTML, atributos y propiedades de estilo, que encajan bien su uso en mensajería instantánea. El protocolo excluye construcciones HTML que puedan dar lugar a la inyección de código malicioso en la entidad o entidades de destino, así como a cualquier otra vulnerabilidad inducida. - XEP0096: File Transfer. El mecanismo tradicional de transferencia de ficheros en la comunidad Jabber siempre ha sido el protocolo OutofBand Data (XEP0066), que tiene una serie de problemas tales como su poca

85 ESTUDIO DEL PROTOCOLO XMPP DE MENSAJERÍA INSTANTÁNEA

fiabilidad, la poca tolerancia a los firewalls y la limitación sobre los metadatos de los ficheros. La XEP0096 es una extensión que define un perfil de uso de la extensión de iniciación de XMPPstreams (XEP0095) para la transferencia de ficheros entre dos entidades XMPP. El protocolo proporciona un marco de especificaciones que permite el intercambio robusto y fiable de información sobre el fichero a transmitir así como la negociación de parámetros tales como el protocolo de transporte que será utilizado. - XEP0115: Entity Capabilities. Es frecuente que una aplicación XMPP deba ejecutar diferentes acciones dependiendo de las capacidades de la entidad XMPP de la que está recibiendo información de presencia. Así, por ejemplo podría querer mostrar diferentes juegos de iconos dependiendo de la capacidad gráfica de las otras entidades; enviar texto plano en lugar de XHTML-IM porque se trate de un teléfono móvil el dispositivo de la entidad descubierta; permitir el inicio de una sesión Voice over IP (VoIP) porque el cliente soporte los protocolos Jingle y RTP; no mostrar un botón de adjuntar ficheros si la otra parte no soporta el servicio de transferencia de ficheros; filtrar las notificaciones de Publicación-Suscripción dependiendo de los intereses del suscriptor; y un largo etcétera. En el pasado, después de realizar el login, un cliente XMPP enviaba solicitudes de descubrimiento de servicios (XEP0030 Service Discovery) y solicitudes de versión de software (XEP 0092 Software Version) a cada entidad de la cual se recibía información de presencia y disponibilidad. Esta práctica resultaba en un uso ineficiente y excesivo del ancho de banda disponible en la red, lo que lo hacía en impracticable a gran escala, sobre todo cuando los tamaños de los roster pudieran ser grandes. La extensión de XMPP XEP0115 se pensó para aprovechar el mecanismo de broadcasting de XMPP en el descubrimiento dinámico de clientes, dispositivos, o capacidades de las distintas entidades XMPP conectadas a una red. Con el fin de minimizar el impacto sobre la red, el mecanismo de transporte es el propio broadcast de información de presencia del protocolo XMPP (evitando así emplear técnicas de polling para el descubrimiento de los servicios, optimizando el uso del ancho de banda

86 3. ESTADO DEL ARTE

disponible). La información de estas capacidades de las entidades XMPP puede almacenarse en cache ya sea para ser empleada dentro de la misma sesión o entre diferentes sesiones, siendo el formato de esta información muy reducido. - XEP0124: Bidirectionalstreams Over Synchronous HTTP. Este protocolo, también conocido como HTTP Binding o BOSH, define un protocolo de transporte que emula un canal bidireccional entre dos entidades XMPP (como un cliente y un servidor) mediante el uso de múltiples pares síncronos de peticiones/respuestas HTTP, evitando el uso de técnicas de polling o asynchronous chunking. Algunas aplicaciones a menudo se encuentran con que no se pueden establecer comunicaciones por sockets TCP (ver RFC 793: Transmission Control Protocol), como ocurre, por ejemplo, con las aplicaciones que tienen restringido, bien por un firewall, bien por el sistema operativo, el uso de todos los puertos TCP excepto el 8080 para navegación web. BOSH puede usarse como una alternativa a los sockets TCP. Es un protocolo maduro, muy difundido y que tiene implementaciones abiertas y comerciales por igual. Además, se salta las restricciones de comunicaciones empleando el mecanismo de “cookies” definido en el RFC 2965 (HTTP State Management Mechanism) cómo transporte con los protocolos HHTP 1.0 y HTTP 1.1 (ver RFC 1945 y RFC 2616). El transporte por BOSH es muy eficiente y tiene una mínima latencia en cualquiera de las dos direcciones de la comunicación. En aplicaciones que requieren tanto comunicaciones tipo “push” como tipo “pull”, BOSH es significativamente mucho más eficiente en el aprovechamiento del ancho de banda y fiable que otros protocolos bidireccionales basados en HTTP como Jabber HTTP Polling y las técnicas ahora conocidas como AJAX.

Otras extensiones al protocolo XMPP en las que se está trabajando actualmente desde la XSF y la comunidad de desarrollo de XMPP tienen que ver con la gestión de la negociación y señalización de la Voz sobre protocolo IP (VoIP). En concreto, existe un protocolo llamado Jingle, creado por Google para dotar de capacidad VoIP a su Google Talk y que es compatible (interoperable) con el protocolo Session Initiation Protocol (SIP).

87 ESTUDIO DEL PROTOCOLO XMPP DE MENSAJERÍA INSTANTÁNEA

3.3.8. Ejemplo de una sesión XMPP

Este apartado del documento pretende mostrar y explicar un ejemplo de sesión de MI, utilizando para ello los clientes Psi y , y los servidores GTalk de Google y jabber.org.

Ilustración 20. Vista general de una sesión XMPP

3.3.8.1. Conectar con el servidor de GMail e iniciar sesión

1) Envío del Cliente:

2) Respuesta del servidor: X-GOOGLE-TOKEN

88 3. ESTADO DEL ARTE

3) Envió del cliente:

4) Respuesta del servidor confirmando el comienzo de la negociación TLS:

5) El cliente comienza un nuevo stream para enviar su configuración

6) El servidor contesta e informa de sus mecanismos de autenticación soportados, indicando que los mensajes pueden viajar en texto plano (PLAIN) o bien el mecanismo de Single SignOn de Google (X-Google-Token) PLAIN X-GOOGLE-TOKEN

7) El cliente elige el mecanismo PLAIN e informa al servidor: AGpvc2VjYXJsb3MuZGlhemdhcmNpYQB4cHN0XzUwMA==

8) El servidor confirma que el mecanismo es aceptado:

9) El cliente inicia otro nuevo stream

89 ESTUDIO DEL PROTOCOLO XMPP DE MENSAJERÍA INSTANTÁNEA

10) El servidor contesta abriendo otro stream de respuestas en el que advierte al cliente de que soporta vinculación de recursos (resource binding):

11) El cliente comunica el recurso desde el que va a participar. En muchos clientes de MI, se toma este nombre automáticamente del nombre del host. SONY_VAIO

12) El servidor envía el acuse de recibo, y, aunque acepta el nombre de recurso propuesto por el cliente, le concatena un identificador alfanumérico para asegurar su unicidad (este comportamiento depende del servidor de MI empleado): [email protected]/SONY_VAIOF2903CC0

13) El cliente solicita una sesión al servidor:

14) Si todo va bien, el servidor envía un acuse de recibo.

15) El cliente solicita al servidor la descarga del roster, con todos sus contactos:

90 3. ESTADO DEL ARTE

16) El servidor devuelve la información del roster: TRABAJO

17) El cliente envía su presencia, que será recibida por todos los contactos con suscripción de tipo both o from: 5

Un cliente XMPP puede almacenar todo tipo de datos en XML en su servidor XMPP (si soporta la XEP-0049) mediante el envío al servidor de una stanza de tipo set seguida de un elemento sujeto al espacio de nombres

91 ESTUDIO DEL PROTOCOLO XMPP DE MENSAJERÍA INSTANTÁNEA

‘jabber:iq:private’. El elemento puede contener cualquier fragmento de XML siempre que su elemento raíz vaya ligado a un espacio de nombres privado. Los datos pueden recuperarse enviando un de tipo get seguido de un elemento y su correspondiente espacio de nombres.

El uso más típico de esta funcionalidad que tienen algunos servidores es almacenar las preferencias de los clientes, así como bookmarks o enlaces a favoritos (URLs, JIDs de chatrooms, etc.).

En este ejemplo, el cliente está solicitando la descarga de esos elementos favoritos.

Empleando esta misma capacidad de almacenamiento en el espacio privado del servidor, existe una extensión que permite hacer lo propio con el formato de tarjeta de visita (vCard) del usuario.

La especificación XEP-0054 establece que la información de una vCard puede ser almacenada mediante el envío al servidor de una stanza de tipo set seguida de un elemento sujeto al espacio de nombres ‘vcard-temp’. Para recuperarla se procede igual que en el caso anterior, utilizando una stanza de tipo get.

Cualquier usuario puede solicitar ver esta información.

Por último, el cliente envía una solicitud especial al servidor para descubrir los servicios y protocolos que implementa.

Este tipo de solicitudes las define la extensión XEP-0030 de Descubrimiento de Servicios. Se permite el descubrimiento automático de información de dos tipos, fundamentalmente: (1) la identidad y capacidades de una entidad, incluyendo los

92 3. ESTADO DEL ARTE

protocolos y características que soporta; y (2) los elementos asociados con una entidad, tales como la lista de salas de chat alojadas en un servicio de chat multiusuario.

18) Respuesta del servidor a las solicitudes anteriores.

El servidor devolvería un mensaje con los bookmarks hallados en el espacio privado del usuario en el servidor. Pero en este caso se devuelve un error porque el servidor no implementa la XEP-0049.

Respecto a la solicitud que se hizo de recuperar la vCard del usuario, el servidor contesta enviando la información que establece el DTD del espacio de nombres ‘vcard-temp’. José Carlos Díaz Díaz José Carlos Joca http://www.linkedin.com/profile?viewProfile=&key=23243178&t rk=tab_pro

93 ESTUDIO DEL PROTOCOLO XMPP DE MENSAJERÍA INSTANTÁNEA

1973-12-18 NEXTEL ENGINEERING SYSTEMS S.A. ACCOUNT MANAGER – NADS DIVISION 918-033-802 NEXTEL ENGINEERING Avenida de Manoteras, 18 Madrid 28050 Spain 915-111-033 Madrid 28054 Spain

[email protected] [email protected] Puedes localizar más información mía en mi sitio web personal http://www.facebook.com/profile.php?id=704575969

94 3. ESTADO DEL ARTE

Respecto a la solicitud de descubrimiento de servicios, el servidor contesta al cliente con una relación de identificadores, servicios y protocolos que soporta.

Las entidades, cuando son una extensión de agentes o aplicaciones de software que usan XMPP para comunicarse entre sí, tienen que intercambiar información de una manera estructurada, exponiendo una serie de interfaces para que dichas entidades puedan interactuar entre sí, enviándose comandos e intercambiando información. De esto se ocupan dos extensiones muy particulares de XMPP que son las extensiones XEP-0050 (AdHoc Commands) y la XEP-0004 (Data Forms).

Si una entidad solicita encontrar los comandos que proporciona otra entidad, debe hacer uso del Descubrimiento de Servicios. Cada comando de la entidad es un nodo, hijo del nodo fijo "http://jabber.org/protocol/commands". El uso de un nodo fijo para todos los comando de una entidad permite recuperar inmediatamente los comandos.

Cada comando es un elemento y el atributo ‘name’ es la etiqueta del comando.

95 ESTUDIO DEL PROTOCOLO XMPP DE MENSAJERÍA INSTANTÁNEA

La entidad que solicita los comandos de otra, lo hace mediante una query sobre el nodo http://jabber.org/protocol/commands.

La respuesta de la otra entidad es parecida a lo siguiente:

19) Respuesta del cliente a la solicitud de descubrimiento de comandos.

En el caso que se trata en este ejemplo, al tratarse de un cliente de MI, sin capacidad de automatización, se contesta con una lista vacía de comandos:

20) El servidor retransmite al cliente la presencia de los usuarios disponibles:

96 3. ESTADO DEL ARTE

24

1

3.3.8.2. El mecanismo de autenticación segura de Gtalk

X-GOOGLE-TOKEN es un mecanismo de autenticación que lo emplea sólo el cliente de GTalk. Mediante un procedimiento sencillo y seguro (HTTPS), es posible obtener de Google el token único asociado a un JID, de forma que, empleando este token en la autenticación con mecanismo X-GOOGLE-TOKEN, podemos evitar el paso de las credenciales del usuario en claro. Este mecanismo de SSO comienza a ser empleado fuera del ámbito de la MI, ya que reporta muchas ventajas.

Para obtener el token SSO de un usuario registrado de Google, el procedimiento es sencillo. Debe llevarse a cabo el siguiente protocolo de HTTPS REQUEST/RESPONSE:

1) HTTPS POST para enviar a Google el JID y la password del usuario del que se quiere obtener su X-GOOGLE-TOKEN: POST /accounts/ClientAuth HTTP/1.1 Host: www.google.com Content-Type: application/x-www-form-urlencoded

97 ESTUDIO DEL PROTOCOLO XMPP DE MENSAJERÍA INSTANTÁNEA

Content-Length: 112 Cookie: PREF=ID=6446dfbb7446f909:TM=1216989713:LM=1216989713:S=WmPYVsY86xEFn U-F

Email=josecarlos.diazgarcia%40gmail.com&Passwd=%78%70%73%74%5f%35%30 %30&PersistentCookie=false&source=googletalk

cuya respuesta de Google es la siguiente: HTTP/1.1 200 OK Content-Type: text/plain Cache-control: no-cache, no-store Pragma: no-cache Expires: Mon, 01-Jan-1990 00:00:00 GMT Date: Fri, 25 Jul 2008 14:02:30 GMT Content-Length: 417 Server: GFE/1.3

SID=DQAAAIMAAAA56VXNgPSPT2OCTE94fxbIKd5e6oXYNdrnT- IjhvmA6YHJb4T451kHn23AAp5ROzRiEotR_a- uDt93GMBA1YYT7NpYTBE1AkpuJp4ePKQDsx8vg5b7qScFKU1M64L9NARc1XWvdBhfVBJ 6IE-dmBEKubQlAgiRcETq1YjPNGX5yvZ1dNmxnhV8Kz-qMl491eQ LSID=DQAAAIYAAAC_JHGS6cPZv0Y_9JX1WBgLLxGt9RbdzRWFm8e_Wht4y7WyfTBKEWH lo3DnH5wGN4vnlaF33gXC2TlwMToPUdrokk7yx0EMduMrg86gpyQ8hNzSzQf1Vdhktxr IQhn-MNkQb09WbsA- vAyQdVPF4YpWtFbQq9wmmEuYGShCifybVds7AjW4mRrJZR5drFuotqQ

2) HTTPS POST para enviar a Google el ID de Sesión HTTPS y obtener su X- GOOGLE-TOKEN asociado: POST /accounts/IssueAuthToken HTTP/1.1 Host: www.google.com Content-Type: application/x-www-form-urlencoded User-Agent: Google Talk Content-Length: 446 Cookie: PREF=ID=6446dfbb7446f909:TM=1216989713:LM=1216989713:S=WmPYVsY86xEFn U-F

98 3. ESTADO DEL ARTE

SID=DQAAAIMAAAA56VXNgPSPT2OCTE94fxbIKd5e6oXYNdrnT- IjhvmA6YHJb4T451kHn23AAp5ROzRiEotR_a- uDt93GMBA1YYT7NpYTBE1AkpuJp4ePKQDsx8vg5b7qScFKU1M64L9NARc1XWvdBhfVBJ 6IE-dmBEKubQlAgiRcETq1YjPNGX5yvZ1dNmxnhV8Kz-qMl491eQ &LSID=DQAAAIYAAAC_JHGS6cPZv0Y_9JX1WBgLLxGt9RbdzRWFm8e_Wht4y7WyfTBKEW Hlo3DnH5wGN4vnlaF33gXC2TlwMToPUdrokk7yx0EMduMrg86gpyQ8hNzSzQf1Vdhktx rIQhn-MNkQb09WbsA- vAyQdVPF4YpWtFbQq9wmmEuYGShCifybVds7AjW4mRrJZR5drFuotqQ&service=mail &Session=true

a lo que el servidor de Google responde con una cadena de caracteres que concatenada a continuación del JID formará el token que permitirá la autenticación basada en mecanismo X-GOOGLE-TOKEN: HTTP/1.1 200 OK Content-Type: text/plain; charset=UTF-8 Cache-control: no-cache, no-store Pragma: no-cache Expires: Mon, 01-Jan-1990 00:00:00 GMT Date: Fri, 25 Jul 2008 14:18:51 GMT Content-Length: 204 Server: GFE/1.3

DQAAAIgAAADSDCvgEJrBnX932cTq8l1FwjzpmsTM6WweRrppbxpVU4uRQGPHXYOBY7rN dNAoqIku5OAb49ZVUL_Q4lYA_LPm7BjFnQSfJaUUa94- 1R7YN_q1eSayl0c3C_96YCmy0JAl_ZqVnZbpznk658TX2j3F0wMQ3zq7dmNEo4L1OcTg 5C7_R-7S7OCakN_z4Vk5NqU

Para hallar el token debemos concatenar por delante el JID así (con un carácter 0x00 delante y detrás del JID): [email protected] q8l1FwjzpmsTM6WweRrppbxpVU4uRQGPHXYOBY7rNdNAoqIku5OAb49ZVUL_Q4 lYA_LPm7BjFnQSfJaUUa941R7YN_q1eSayl0c3C_96YCmy0JAl_ZqVnZbpznk6 58TX2j3F0wMQ3zq7dmNEo4L1OcTg5C7_R-7S7OCakN_z4Vk5NqU

Y transformarlo a BASE64 (asumiendo que la codificación de caracteres es UTF-8), por lo que el token sería: MDBqb3NlY2FybG9zLmRpYXpnYXJjaWFAZ21haWwuY29tMDBEUUFBQUlnQUFBRFNEQ3Zn RUpyQm5YOTMyY1RxOGwxRndqenBtc1RNNld3ZVJycHBieHBWVTR1UlFHUEhYWU9CWTdy

99 ESTUDIO DEL PROTOCOLO XMPP DE MENSAJERÍA INSTANTÁNEA

TmROQW9xSWt1NU9BYjQ5WlZVTF9RNGxZQV9MUG03QmpGblFTZkphVVVhOTQtMVI3WU5f cTFlU2F5bDBjM0NfOTZZQ215MEpBbF9acVZuWmJwem5rNjU4VFgyajNGMHdNUTN6cTdk bU5FbzRMMU9jVGc1QzdfUi03UzdPQ2FrTl96NFZrNU5xVQ==

Y por tanto, la autenticación que admite XMPP según el mecanismo X-GOOGLE- TOKEN sería algo así: MDBqb3NlY2FybG9zLmRpYXpnYXJjaWFAZ21haWwuY29tMDBEUUFBQUlnQUFBR FNEQ3ZnRUpyQm5YOTMyY1RxOGwxRndqenBtc1RNNld3ZVJycHBieHBWVTR1UlFHUEhYW U9CWTdyTmROQW9xSWt1NU9BYjQ5WlZVTF9RNGxZQV9MUG03QmpGblFTZkphVVVhOTQtM VI3WU5fcTFlU2F5bDBjM0NfOTZZQ215MEpBbF9acVZuWmJwem5rNjU4VFgyajNGMHdNU TN6cTdkbU5FbzRMMU9jVGc1QzdfUi03UzdPQ2FrTl96NFZrNU5xVQ==

3.3.8.3. Enviar un mensaje a uno de los contactos

El envío de un mensaje se realice mediante la stanza de tipo “chat”. Los atributos id son fundamentales a la hora de establecer un orden en el receptor.

El XEP-0085 (Chat State Notifications) establece unas especificaciones para comunicar el estado de un usuario en una conversación de chat de forma que el otro usuario (o usuarios en un multiuser chat) pueda tener información de presencia del primero que le indique si el usuario está tecleando, se ha parado, o se ha ido.

Por ello, cuando un usuario abre una ventana de chat para hablar con otro usuario, antes de que teclee nada, se envía este mensaje a este último:

El mensaje en sí, se envía una vez que el usuario pulsa el botón de envío. Hola... ¿Cómo estás?

El servidor responderá retransmitiendo los mensajes de estatus del otro usuario y el mensaje de respuesta si lo hubiera, como en este ejemplo.

100 3. ESTADO DEL ARTE

Bien, gracias. Bien, gracias.

3.3.8.4. Cambiar el estatus de presencia

El usuario, haciendo uso de la funcionalidad de notificaciones de estado de presencia que tienen todos los clientes de MI, puede notificar un cambio de disponibilidad, acompañado de una descripción del estatus actual. away Estoy en el reunido con Pepe, en la sala de conferencias. Terminaré sobre las 14.00h 5

El servidor responde con una solicitud de descubrimiento de servicios del destinatario:

101 ESTUDIO DEL PROTOCOLO XMPP DE MENSAJERÍA INSTANTÁNEA

El cliente responderá a la solicitud. En este caso no hay nada que notificar:

3.3.8.5. Asociar un uevo grupo a un contacto del roster

Cuando un usuario desea asignar grupo a un contacto, el mensaje de solicitud de actualización del roster que debe enviar a su servidor es similar al siguiente: TRABAJO

El servidor envía una actualización del item afectado: TRABAJO

El cliente responde con una confirmación de actualización:

102 3. ESTADO DEL ARTE

Y el servidor, del mismo modo, confirma el primer mensaje de solicitud de actualización de roster:

3.3.8.6. Enviar un fichero a un contacto del roster

El envío de ficheros sucede de la siguiente forma. Primero, el cliente que remite el fichero, envía un mensaje similar al siguiente: Memoria del proyecto fin de carrera de Jose Carlos Diaz

El servidor responde con: http://jabber.org/protocol/bytestreams

103 ESTUDIO DEL PROTOCOLO XMPP DE MENSAJERÍA INSTANTÁNEA

El cliente replica con un:

Y, finalmente, el servidor, si todo va bien, contesta con un:

3.3.8.7. Cerrar la sesión

Cuando un usuario abandona el programa cliente XMPP o pasa a estado offline, el cliente envía los siguientes mensajes al servidor: Logged out

3.3.9. Roadmap

La misión de la XSF, como ya se ha comentado anteriormente, es construir una infraestructura abierta, estándar, segura, rica en funcionalidades, de amplio despliegue y descentralizada para la comunicación en tiempo real y la colaboración por Internet

104 3. ESTADO DEL ARTE

La XSF ha identificado bastantes iniciativas de alta prioridad para ayudar a lograr su misión: - Completar la definición de Jingle como tecnología abierta para la federación de servicios de voz, video, y comunicación multimedia en general. - Incorporar la implementación y el despliegue de experiencia dentro de las especificaciones del núcleo de XMPP mediante la finalización de las revisiones de la RFC 3920bis y RFC 3921bis. - Quedan por definir aún muchas optimizaciones al core de XMPP, en cuanto a streaming, presencia, y protocolos del roster, de modo que se mejore el rendimiento en entornos de movilidad (por ejemplo, como se define en la XEP0237) - Respecto a la seguridad del protocolo XMPP, también queda por completar la definición de los protocolos (XEP0158, XEP0159 y XEP0161) y mejores prácticas (XEP0165 y XEP0205) para la prevención del spam, phising, y los ataques de denegación de servicio (DoS attacks) en la red XMPP. - Continuar con el desarrollo de una autoridad de certificación para la red XMPP, desplegando un cifrado de canales ubicuos en la red abierta de servidores XMPP) - Continuar desarrollando una suite completa de extensiones XMPP para comunicación y colaboración en tiempo real, así como recomendar la integración de estas extensiones en otras tecnologías abiertas y servicios de Internet, siendo los siguientes objetivos los que la XSF tiene más interés en lograr a corto plazo: o Ampliar el despliegue del protocolo de publicación-suscripción para el broadcasting de eventos relacionados con el cambio de estado en la presencia de los usuarios de la mensajería instantánea. o Lograr el consenso en lo relacionado con la transferencia de archivos del protocolo Jingle de XMPP (XEP0234).

105 ESTUDIO DEL PROTOCOLO XMPP DE MENSAJERÍA INSTANTÁNEA

3.3.10. Software existente

De acuerdo con la arquitectura de XMPP, que podemos ver en la Ilustración 21, podemos distinguir entre tres tipos de software diferentes: - Clientes - Servidores - Gateways o pasarelas

Los dos primeros son los que forman la base de la red XMPP. El tercer tipo es el que permite que las redes de MI basadas en XMPP se puedan federar con otras redes de MI como Google Talk, Yahoo! Messenger o el AOL Instant Messenger.

Ilustración 21. Arquitectura de una red XMPP

3.3.10.1. Clientes XMPP

Existe una gran variedad de clientes7 que admiten el protocolo Jabber/XMPP. Muchos de ellos incluso admiten otros protocolos.

Además, existen implementaciones en cualquiera de las formas de licencia del software (software libre de código abierto, software gratuito, y software propietario).

7 Ver apéndices C y D

106 3. ESTADO DEL ARTE

Las siguientes tablas recogen las implementaciones más importantes, aunque se remite al lector al apéndice B para mayor detalle sobre las características de cada uno de estos clientes.

Nombre Plataforma Detalles de implementación

Bombus J2ME (MIDP2.0)/WinCE

Bombusmod J2ME (MIDP2.0)

Coccinella Multiplataforma Tcl/

Exodus Windows

Gabber Linux/Unix GTK+

Gajim Multiplataforma PyGTK

GOIM Multiplataforma Eclipse Rich Client Platform

Gossip Linux/Unix GTK+

JabberMixClien J2ME (MIDP2.0) t

Jabbim Multiplataforma PyQt

Jabbin Multiplataforma

Jeti Multiplataforma , browser-based

MCabber Multiplataforma Cabber fork, console client (ncurses)

Mobber J2ME (MIDP1.0)

MOO-XMPP MOO Se ejecuta como un objeto MOO

Psi Multiplataforma Qt

Spark Java

Tkabber Multiplataforma Tcl/Tk wija Java Tabla 4. Clientes de protocolo único Jabber/XMPP de software libre

107 ESTUDIO DEL PROTOCOLO XMPP DE MENSAJERÍA INSTANTÁNEA

Nombre Plataforma Detalles de implementación

Chikka

GCN Windows

Google Talk Windows

Gush Multiplataforma Producto discontinuado

Jabbear XP/Vista

JAJC Windows

Joost Windows

Pandion Windows Producto discontinuado Tabla 5. Clientes monoprotocolo XMPP propietarios y gratuitos Entre los clientes multiprotocolo que son compatibles con XMPP, tenemos los de la Tabla 6, que se muestra a continuación.

Nombre Plataforma Detalles de implementación

Adium MAC OS X Desarrollado en Cocoa. Licencia GNU GPL. Disponible en http://www.adiumx.com

Ayttm Multiplataforma Desarrollado en C con la librería GTK-2. Licencia GNU GPL. Disponible en http:// .sourceforge.net

BitlBee Gateway IRC UI en modo texto. Desarrollado en multiplataforma C. Licencia GPL. Disponible en http://www.bitlbee.org

Digsby Windows. Capacidad Desarrollado en wxPython. de multiplataforma Disponible en (versiones de MAC http://www.digsby.com y Linux anunciadas)

108 3. ESTADO DEL ARTE

Nombre Plataforma Detalles de implementación

Ebuddy Multiplataforma Desarrollado con Java y J2ME. (ASP) Software propietario.

Mobile

IBM Lotus Multiplataforma Producto comercial desarrollado Sametime por IBM sobre la plataforma Eclipse. El IBM Lotus Sametime Gateway añade soporte de la comunicación con redes de MI como AOL, Yahoo, Google Talk y XMPP. iChat MAC OS X Desarrollado por Apple. Código fuente no disponible. imeem Multiplataforma Servicio de intercambio de (ASP) playlists y tags, perteneciente al ámbito de las redes sociales. Desarrollado en C# sobre Microsoft .NET y Mono.

IMVU Windows Mensajería instantánea sobre mundos virtuales en 3D con avatares personalizables. Disponible en http://www.imvu.com/

Instantbird Multiplataforma Desarrollado en C++ sobre Mozilla XULRunner y la librería libpurple. Disponible en http://www.instantbird.com Multiplataforma Desarrollado con AJAX. Gateway (ASP) hacia Yahoo! Messenger, .NET Messenger Service, Google Talk, AIM, ICQ, y Jabber. Disponible en http://www.meebo.com

Miranda IM Windows Desarrollado con C++. Licencia GNU GPL. Disponible en http://www.miranda-im.org/

109 ESTUDIO DEL PROTOCOLO XMPP DE MENSAJERÍA INSTANTÁNEA

Nombre Plataforma Detalles de implementación

QuteCom Multiplataforma con capacidad MI (antes multiprotocolo basado sobre la OpenWengo) librería libpurple. Open Source. Disponible más información en http://www.qutecom.org/

Proteus MAC OS X Desarrollado en Cocoa. Licencia GNU GPL. Disponible en http://www.proteusx.org/

QIP Infium Windows Desarrollado en Delphi. Licencia . Disponible en http://www.qipim.com

Simple Windows Desarrollado con C++ sobre Instant librerías QT. Licencia GNU GPL. Messenger Disponible en http://www.sim- (SIM) im.org Tabla 6. Clientes de MI multiprotocolo compatibles con Jabber/ XMPP

3.3.10.2. Servidores XMPP

Entre las implementaciones Open Source de software de servidor XMPP tenemos las siguientes: - chime. Programada en entorno Java. Esta implementación se encuentra discontinuada. Está disponible en http://www.codecobra.com/chime/ - Citadel. Programada en lenguaje C. Disponible en http://www.citadel.org/ - DJabberd. Programada en y disponible en http://danga.com/djabberd/ - Ejabberd. Programada en Erlang, mantenida por una empresa llamada ProcessOne y por una comunidad de desarrolladores cuya sede web se encuentra en http://www.ejabberd.im/ - iChat Server. Programada en lenguaje C. Disponible en http://www.apple.com/server/macosx/features/ichat.html

110 3. ESTADO DEL ARTE

- jabberd14. Programada en lenguaje C. Disponible en http://jabberd.org/ - . Programada en lenguaje C. Disponible en http://jabberd2.xiaoka.com/ - (Wildfire Server). Programada en lenguaje Java. Disponible en http://www.igniterealtime.org/projects/openfire/ - OpenIM. Programada en lenguaje Java. Disponible en http://www.open- im.net/ - pretzel. Programada en lenguaje Python. Disponible en http://code.google.com/p/pretzel/ - psyced. Programada en lenguaje LPC. Disponible en http://www.psyced.org/ - Tigase. Programada en lenguaje Java. Disponible en http://www.tigase.org/ - WPJabber. Programada en lenguaje C. Disponible en http://spik.wp.pl/jabber.html - xmppd.py. Programada en lenguaje Python. Disponible en http://xmpppy.sourceforge.net/

Entre las implementaciones propietarias/comerciales de software de servidor XMPP tenemos estas otras: - Antepo OP. Programada en Java. La compañía fue adquirida por Adobe en 2007. El software no está disponible desde entonces., aunque Adobe continúa ofreciendo soporte a los usuarios que adquirieron este software de presencia. - CommuniGate Pro. http://www.CommuniGate.com/ - IceWarp Server (Merak). Programado en Delphi y disponible en la dirección http://www.icewarp.com/products/instant_messaging/ - IceWarp (Merak) Versión para China, similar a la implementación China QQ (programada en C). Está disponible en la página web http://www.icewarp.cn/Products/Instant_Messaging/index.h tml

111 ESTUDIO DEL PROTOCOLO XMPP DE MENSAJERÍA INSTANTÁNEA

- Jabber XCP. Líder absoluto de todas las implementaciones comerciales. Se trata de una implemementación en lenguaje C y puede encontrarse más información en la dirección http://www.jabber.com/ - Jerry Messenger. Esta implementación está desarrollada en Java y puede encontrarse más información sobre el producto en la página web http://www.j-LiveSupport.com/ - SoapBox Server. Implementación sobre .NET Framework 1.1. Puede encontrarse más información en la dirección http://www.coversant.net/Products/SoapBoxServer/Overview /tabid/99/Default.aspx - Sun Java System Instant Messaging. Implementada en Java. Disponible en http://www.sun.com/software/products/instant_messaging/ - symlynX psyced. Disponible en http://www.symlynX.com/ - TIMP.ET. Implementación sobre .NET Framework. Puede encontrarse más información en la dirección http://www.tipic.com/ (Sólo disponible versión de evaluación. Ha dejado de estar disponible la versión licenciada)

Las más importantes implementaciones de servidores XMPP se recogen en la siguiente tabla.

Nombre del Software Version Plataforma /OS djabberd 0.83 UNIX, GNU/Linux ejabberd 2.0.1 GNU/Linux, Mac OS X, Windows, AIX, BSD, HP- UX, Solaris Isode M-Link R14.2 Linux, Solaris, Windows Jabber XCP: The Extensible 5.2 Windows, Solaris, Communications Platform GNU/Linux jabberd 2.1.24.1 UNIX, GNU/Linux jabberd14 1.6.1.1 UNIX, GNU/Linux jabberd2 2.1.17 UNIX, GNU/Linux Openfire 3.4.5 GNU/Linux, Mac OS X, Windows, AIX, BSD, HP- UX, Java, Solaris psyced 20080116 UNIX, GNU/Linux, Windows, Mac OS X

112 3. ESTADO DEL ARTE

Nombre del Software Version Plataforma /OS Tigase 3.3.2 GNU/Linux, Mac OS X, Windows, AIX, BSD, Java, Mac OS 9, Solaris Tabla 7. Implementaciones más importantes de XMPP

3.3.10.3. Librerías para el desarrollo de software

Existe un buen número de librerías de código abierto para el desarrollo de software cliente y servidor, empleando el protocolo XMPP.

Para lenguaje C tenemos las librerías:

- iksemel

- libstrophe

- Loudmouth (software)

En el caso de Microsoft .NET, los desarrolladores de esta plataforma disponen de:

- C#

- agsXMPP

- Jabber-NET

- goodwarejabber (library, client, server)

Para C++:

- gloox

- IP*Works

- Iris (software)

- jabberoo

- oajabber

Como componentes COM existen los siguientes:

- JabberCOM

113 ESTUDIO DEL PROTOCOLO XMPP DE MENSAJERÍA INSTANTÁNEA

Para Erlang:

- Jabberlang

Para la plataforma Java existe una variedad muy grande de librerías:

- Echomine Feridian

- Echomine Muse

- JabberWookie

- JSO (software)

- micro-Jabber

- Smack (librería)

- Tweeze (software)

- Yaja (software)

Para aplicaciones HTA, desarrolladas en HTML y JavaScript, también existen alternativas:

- JSJaC (JSJaC web site)

- xmpp4moz (xmpp4moz on mozilla.org)

En lenguaje Perl se tienen bastantes alternativas:

- Net::Jabber::Loudmouth

- Net::XMPP2

- Net:XMPP

- XML::Stream

- Jabber::Lite

- POE::Component::Jabber

En cuanto al lenguaje de páginas web dinámicas PHP, se tienen un par de alternativas:

114 3. ESTADO DEL ARTE

- Class.Jabber.PHP

- jabberclass

En Python:

- jabber.py

- PyXMPP

- sleekxmpp

- Words (software)

- xmpppy

En Ruby:

- Action Messenger

- Jabber4R

- Jabber::Simple

- XMPP4R

También existen librerías para entornos más minoritarios como por ejemplo:

- Tcl (JabberLib)

- Framework XPCOM (JabXPCOM)

- LPC (psyced)

- Macromedia Flash (XIFF)

- Lisp (cl-xmpp)

- Haskell (hsxmpp)

3.3.11. Posibilidades del protocolo XMPP

Son muchas las posibilidades de aplicación de XMPP en el mundo real. En la base de esta afirmación reside el hecho de que la MI proporciona un marco de envío de

115 ESTUDIO DEL PROTOCOLO XMPP DE MENSAJERÍA INSTANTÁNEA

mensajes, y esto se puede aplicar a virtualmente cualquier contexto de comunicaciones, simplemente variando el contenido del mensaje. Por ejemplo:

- Comunicaciones entre capas de arquitecturas cliente/servidor alternativas a las existentes.

- Conexiones entre clientes ricos (richclients) para intercambiar cualquier tipo de contenido (texto, imágenes, ficheros de documentos, etc.)

- Comunicación mediante paso de mensajes entre aplicaciones distribuidas.

- Interconexión Business-to-Business o B2B (empleados-clientes, empleados- proveedores, etc.)

- Aplicaciones de atención al usuario/ciudadano por las cuales se puede atender en tiempo real a una persona y a través de los canales multimedia asistirle gráficamente, enviarles documentación, compartir recursos, etc.

- Implementación de sistemas de VoIP, Videoconferencia, intercambio de ficheros, acceso remoto… etc. Todo depende del uso que haga la aplicación cliente de la información que viaje encapsulada en la trama XMPP.

Todo ello en un marco en el que las comunicaciones pueden ser on-line, off-line y, mejor aún, compatibles con múltiples clientes de MI de otros fabricantes, pues otro de los grandes alicientes de una red XMPP es su capacidad de adaptación a protocolos de terceros empleando Gateways. Esto hace factible conectar una red Jabber con una red Google de forma transparente a la aplicación.

3.3.11.1. Transporte entre Jabber/XMPP y otros servidores de MI

Una de las características que distingue al XMPP de estos días del Jabber de los comienzos es la existencia de gateways o pasarelas entre la red Jabber y los servicios de mensajería como AOL Instant Messenger (AIM), ICQ, Windows Live Messenger, y Yahoo! Messenger.

Además de estos servicios de MI tan populares, IBM decidió hace algún tiempo implementar su propio gateway IBM Lotus Sametime Gateway.

116 3. ESTADO DEL ARTE

Por su parte, Zion Software lanzó al mercado su JBuddy XMPP Gateway para permitir la conexión a redes XMPP de usuarios AIM, ICQ, MSN y Yahoo! Messenger.

La tendencia, en sistemas de gestión de colas, consiste en utilizar AMQP y XMPP mediante el gateway8 que se ha liberado recientemente. El beneficio de juntar ambos es dotar a AMQP de la escalabilidad de Internet para implementar sistemas distribuidos de colas persistentes de mensajes (MQ).

Ilustración 22. Federación de redes AMQP y XMPP

Ilustración 23. Detalle de bajo nivel del gateway RabbitMQ que tiene el servidor XMPP ejabberd

8 RabbitMQ gateway module for ejabberd

117 ESTUDIO DEL PROTOCOLO XMPP DE MENSAJERÍA INSTANTÁNEA

Los gateways actúan como intermediarios entre protocolos de MI, recibiendo mensajes en un protocolo y traduciéndolos adecuadamente para poder reenviarlos de acuerdo a las reglas del otro protocolo.

3.3.11.2. Robots XMPP

Un robot XMPP, es un agente que implementa internamente un cliente XMPP y que, dependiendo de la inteligencia con la que se dote, puede simular el comportamiento de un usuario humano en una red de MI.

Hace más de dos décadas, los chatbots, que es como se denominaban este tipo de agentes, servían para proporcionar ayuda a los usuarios de los chats mediante comandos que se les enviaban en forma de mensajes. Algunos de ellos, dotados de analizadores de lenguaje natural, eran incluso capaces de proporcionar conversación a los demás usuarios, simulando ser un usuario-humano. Otros de ellos se convertían en “mayordomos”, empleándose por los usuarios para enviarles tareas como “dame un informe sobre el usuario X” o “dame la cotización de Repsol en el IBEX 35”.

Son estos últimos usos los que acabaron por resucitar paradigmas tan en desuso como la línea de comandos clásica. Sentencias como find /haystack -exec grep -l needle \{} \; 2>/dev/null son simples, potentes y versátiles.

El mundo hiperconectado actual demanda mecanismos de ejecución remota de comandos para poder consultar bases de datos y servicios web desde nuestros clientes de MI (móviles o no), o bien para ejecutar remotamente una tarea (“publica en mi esto…” o “actualiza mi disponibilidad en mi perfil de con esto otro…”).

La forma de interactuar con los bots también está cambiando, de forma que hoy día es posible utilizar la voz para comunicarse con ellos y solicitar, por ejemplo, que nos diga qué actividades tenemos hoy, o que reserve una sala de reunión).

Las posibilidades que se abren con el uso de bots son múltiples.

118 3. ESTADO DEL ARTE

3.3.11.3. XMPP como facilitador de los Cloud Services

El Cloud Computing es, sin duda, el paradigma de servicios a escala Internet que más está dando que hablar en la actualidad.

Las ventajas del Cloud Computing parecen evidentes, al permitir a las empresas y organizaciones escalar rápidamente, en función de sus necesidades, sin tener que añadir equipamiento, software ni personal. A través de la “nube” (una red pública, generalmente Internet), los clientes pueden acceder bajo demanda (siguiendo o no el modelo de pago por uso) a un gran número de recursos informáticos asignados dinámicamente, dotándose así de una enorme capacidad de procesamiento y almacenamiento sin necesidad de instalar máquinas localmente, lo que se traduce en considerables ahorros de todo tipo, incluso de consumo energético.

Ilustración 24. Arquitectura de los servicios de "nube" Las tecnologías habilitadoras del Cloud Computing son el XML y los servicios web, que pueden implementarse mediante protocolos SOAP, REST, XML-RPC y XMPP, entre otros. Lo que hace a XMPP el mejor entre todos ellos es que es el único capaz de ofrecer altos niveles de rendimiento, interoperabilidad, capacidad de federarse con redes de otros protocolos (SIP, SIMPLE, ICQ, IRC, etc.), seguridad, facilidad de programación y características innovadoras. Además, XMPP puede actuar como protocolo de transporte de SOAP (mejor que SMTP y mejor que HTTP).

119 ESTUDIO DEL PROTOCOLO XMPP DE MENSAJERÍA INSTANTÁNEA

3.3.11.4. La capacidad P2P

Como se indicó en el apartado 3.3.6.3, Jingle es el nombre coloquial que recibe el protocolo definido en las extensiones XEP-01669, XEP-016710, XEP-018011 y XEP- 023412, y que permite la transferencia de información multimedia peer-to-peer (p2p).

A través de este protocolo se pueden transmitir datos multimedia extremo-a- extremo13 entre entidades XMPP. Jingle emplea XMPP como protocolo de negociación y UDP14, RTP15 o ICE16 como protocolos de transporte del streaming multimedia.

Así, Jingle permite la adopción de servicios de Videoconferencia y de VoIP en los clientes que ya lo implementan.

Una de las posibilidades que abre la aplicación de Jingle es el chat de voz. Si bien Jingle no pretende articularse como una solución de telefonía que deba implementar las características propias de las soluciones típicas de ToIP (llamada en espera, redirección de llamadas, música en espera, IVR17 o sistemas de operadora automática, multiconferencia, etc.).

Jingle está diseñado de forma modular para que los desarrolladores puedan fácilmente añadir soporte para otros tipos de sesiones multimedia como el video chat (ver XEP-180; Jingle Video vía RTP), intercambio de archivos y aplicaciones, edición colaborativa & whiteboarding, así como broadcasting. Los métodos de transporte son también modulares, lo que permite que las implementaciones de jingle puedan usar cualquier transporte apto para streams de audio y video (incluyendo aquellos que no están estandarizados por la XSF18).

El protocolo jingle fue diseñado inicialmente por Google junto con la XMPP Standards Foundation y liberado (bajo licencia similar a la de BSD) tras la salida de

9 Jingle 10 Jingle RTP Sessions 11 Jingle Video via RTP 12 Jingle File Transfer 13 Peer-to-peer 14 (RFC 768) 15 Real-time Transport Protocol (RFC 3550) 16 Interactive Connectivity Establishment (ICE) 17 Interactive Voice Response 18 XMPP Standard Foundation

120 3. ESTADO DEL ARTE

Google Talk en 2006 para su uso en Jabber. Google Talk y ya implementa este protocolo mientras que otros clientes Jabber como Jabbin o Psi están aún en proceso de implementación.

121 ESTUDIO DEL PROTOCOLO XMPP DE MENSAJERÍA INSTANTÁNEA

122 4. APLICACIONES DEL PROTOCOLO XMPP

4. APLICACIOES DEL PROTOCOLO XMPP

4.1. Introducción

Este capítulo tiene la intención de abrir ante el lector el amplio de abanico de aplicaciones que XMPP está encontrando en entornos civiles y militares, utilizando para ello una cuidadosa selección de ejemplos reales y documentados pertenecientes a escenarios muy diversos como lo son la defensa, la seguridad, la sanidad y los mercados financieros.

Inicialmente, este Proyecto Final de Carrera se iba a centrar exclusivamente en desvelar los proyectos más interesantes de las áreas de seguridad y emergencias, salud, educación, finanzas y cooperación. Campos en los que no es difícil imaginar la utilidad y aplicaciones del protocolo XMPP.

En cambio, a medida que la investigación avanzaba, la mayoría de referencias encontradas en Internet sobre proyectos de temática XMPP llevados a término (y para los que se construían y probaban prototipos en entornos de explotación real) tenían relación con el mundo militar.

Y efectivamente, una vez concluida la investigación, se puede afirmar que ha sido la comunidad de I+D militar de los Países Aliados la que más ha contribuido en los últimos años a avanzar en el desarrollo de XMPP. Incluso más que Google al adoptar este protocolo para su sistema de MI, más allá del poder que tiene asociar una marca tan potente y reconocida como lo es Google. Por ello, el autor ha creído más justo dedicar mayor espacio a las aplicaciones de XMPP para la Defensa y la Seguridad, a la vez que ha considerado que son estos usos militares los más desconocidos y de los que resulta mucho más difícil investigar ejemplos reales, dada la complejidad que rodea al I+D militar.

123 ESTUDIO DEL PROTOCOLO XMPP DE MENSAJERÍA INSTANTÁNEA

4.2. Aplicaciones civiles

Citando nuevamente a Gartner (2007), la mensajería instantánea está pasando de ser un “extra” utilizado por determinados grupos de empleados a convertirse en parte clave de la infraestructura de colaboración empresarial y está erigiéndose como una alternativa cada vez más robusta a las comunicaciones “ad hoc” tradicionales, como las llamadas telefónicas y correos electrónicos, para resolver determinados asuntos en los que la inmediatez de una interacción en tiempo real constituye un valor esencial. Constituye sobre todo una valiosa herramienta para compartir ideas y opiniones en encuentros virtuales y videoconferencias organizadas. La MI, debido a su riqueza digital posibilita establecer en una misma sesión intercambio de mensajes, voz, pizarras, control remoto… etc.

Las organizaciones que apuestan por introducir este tipo de plataformas de MI, tradicionalmente eligen soluciones de mensajería instantánea de nivel empresarial que ofrecen diferentes fabricantes, incluidos IBM y Microsoft. Pero la creciente aceptación de la mensajería instantánea en las empresas está llevando a muchos proveedores de IT a desarrollar aplicaciones MI capaces de satisfacer los requerimientos propios de estos entornos, más allá de las herramientas originariamente diseñadas para el segmento de consumo. Gartner (2007) también espera que el nivel de penetración de las herramientas de MI de clase empresarial aumente desde el 25% actual hasta casi el 100% a finales de la década.

Pero las aplicaciones civiles de la MI van mucho más allá de la propia comunicación humana. Mediante la MI, es posible comunicar entre sí los sistemas de información de una organización, creando así un entorno convergente que en el que intercambiar cualquier tipo de información, en cualquier contexto y de la misma forma. La convergencia aportará niveles de colaboración excepcionales y nunca vistos en las relaciones humanas, empresariales e institucionales.

En los siguientes apartados, el lector podrá conocer tan sólo algunas de las aplicaciones más meritorias del protocolo XMPP llevadas a cabo en la sociedad civil. La lista es inmensa y está en constante desarrollo. Tanto como el número de

124 4. APLICACIONES DEL PROTOCOLO XMPP

desarrolladores que se unen cada día a la amplia comunidad que desarrolla nuevas extensiones al protocolo.

4.2.1. Aplicaciones en el área de la salud

4.2.1.1. Sistemas Integrados en el Entorno

La Inteligencia Ambiental (AmI) se alcanza cuando un entorno “electrónico”, compuesto por toda clase de dispositivos electrónicos, software y comunicaciones, es sensible y responde a la presencia de las personas, colaborando de manera transparente para el usuario.

Prestando atención a aquellos Sistemas Integrados en el Entorno19 formados por redes de sensores médicos20, tenemos que su aplicación en la monitorización remota de bio-señales de pacientes, deportistas, soldados o trabajadores en entornos de riesgo o críticos, es más que evidente.

Las Redes de Sensores Corporales (BAN21) han sido objeto de numerosos estudios (Labidi, Susini, Setton, Paradinas, & Setton, 2007), y existen muchos precedentes como: CodeBlue22, MobiHealth23, Awareness24, uMiddle25, IBM Personal Care Connect, Microsoft Research Integrated Systems, Intel Personal Health, y otro de Oracle & Toumaz Personal Healh Monitoring System. Si bien algunos de ellos se basaban en arquitecturas de distribución de datos vía mecanismos de pubsub, la mayoría de ellos26 no contemplaban la necesidad de poder desplegar a escala Internet federaciones de redes de sensores (redes de área corporal). También es importante destacar que muy pocos se basaban en protocolos de transporte por Internet estándares y, mucho menos, extensibles, como es el caso de XMPP.

19 Integrated Ambient Systems (Labidi, Susini, Setton, Paradinas, & Setton, 2007) 20 Estos sensores pueden ser termómetros, medidores de pulso y presión arterial, ECC, EEG, etc. 21 Redes de Area Corporal o Body Area Networks (BAN) 22 M. Welsh: Sensor Networks for Emergency Response Challenges and Opportunities (IEEE 2004) 23 D. Konstantas, et al.: Mobile Health Care Towards Commercialization of Research Results (2006). 24 M. Wegdam: AWARENESS A project on Context AWARE mobile NEtworks and ServiceS (14th Mobile & Wireless Communications Summit 2005, Germany) 25 J. Nakazawa, W. Keith Edwards: A Bridging Framework for Universal Interoperability in Pervasive Systems Distributed Computing Systems (ICDCS 2006) 26 Sólo CodeBlue y uMiddle ofrecen esa posibilidad

125 ESTUDIO DEL PROTOCOLO XMPP DE MENSAJERÍA INSTANTÁNEA

El trabajo de Labidi et al. (2007) demuestra un uso muy apropiado del protocolo XMPP, proporcionando una arquitectura SOA en la que las redes BAN, que constan de un gateway27 y un número indeterminado de sensores portátiles, forman federaciones que se pueden ir agregando y desagregando según la necesidad.

Ilustración 25. Arquitectura federada cliente-servidor28 En concreto, Labidi et al. (2007) propone un sistema de monitorización de pacientes donde cada BAN se conecta a un Centro Médico (MC), que se encarga de almacenar los datos localmente para posteriores recuperaciones. En el MC, además, se fusiona la información médica del HIS29 con los datos recibidos de los sensores.

27 Realmente es un cliente XMPP, que actúa con el rol de “publicador” 28 MC es el Centro Médico que recibe las notificaciones de publicación de datos de las BAN, así como enruta los datos hacia otras redes federadas. Se observa que gracias a la federación de redes, los médicos pueden recibir los datos de cualquier paciente desde cualquier centro. 29 Health Information System o Sistema de Información Sanitario que contiene el historial del paciente.

126 4. APLICACIONES DEL PROTOCOLO XMPP

Ilustración 26. Arquitectura de alto nivel de la solución de Labidi et al. (2007) La solución creada por Labidi et al. (2007) se basa en el servidor Openfire y el cliente móvil Mobber. Para la implementación de las redes BAN optaron por un desarrollo sobre una plataforma IPOX de sistemas embarcados.

Gracias a la característica de XMPP de permitir el descubrimiento automático de servicios (XEP-0030 y XEP-0128), se hace posible que las aplicaciones médicas puedan descubrir automáticamente esos servicios y su disponibilidad. El enrutamiento se realiza conforme al mecanismo de publicación-suscripción, con el que los BANs publican los datos leídos de los sensores en un nodo específico y las aplicaciones de monitorización se suscriben a esos nodos de información.

Otro grupo de investigación español (Arriola et al., 2008), ha desarrollado una solución técnicamente más avanzada, haciendo uso de hardware embarcado Texas Instruments CC2430 de tipo Systems-on-Chip con transceiver IEEE 802.15.4 para las comunicaciones30 y pila de protocolos ZigBee31. La principal aportación de este grupo ha sido la incorporación de Sistemas-en-Chip para implementar tanto sensores móviles (Mobile Sensor Nodes) como el dispositivo también móvil al que se conectan inalámbricamente estos sensores (Mobile Personal Device), teniendo esta conexión una topología en malla (Mesh). En cambio, no mencionan en su trabajo futuro el empleo de

30 Banda estrecha: máximo de 250Kbps. Téngase en cuenta que se utilizará para transmitir lecturas de sensores, en los que se depende de los requisitos de muestreo. Alto muestreo = Alto consumo de ancho de banda. 31 ZigBee es una especificación relativamente reciente que define una solución para comunicaciones inalámbricas de bajo coste y consumo con vistas a constituir la base del desarrollo de redes ubicuas. ZigBee Alliance desarrolla la especificación y certifica sus implementaciones. Ya comienzan a surgir algunas implementaciones abiertas de gateways IP para ZigBee.

127 ESTUDIO DEL PROTOCOLO XMPP DE MENSAJERÍA INSTANTÁNEA

XMPP. Gracias que existen gateways IP para ZigBee, sería posible implementar XMPP para la comunicación a nivel de Red de Area Personal (BAN como la estamos denominando) para aprovecharse del mecanismo de publicación-suscripción.

T ráf ico P XM P P M X P o ic f á r T Tráfico XMPP BAN

Tr áf i co X M MC PP

Ilustración 27. Aplicación de XMPP y la tecnología de Redes de Área Personal a la medicina deportiva

4.2.1.2. Sistemas de localización y alerta por MI

La MI ha demostrado cualidades suficientes para operar en entornos relacionados con la salud, como hospitales y clínicas, en los que existe una necesidad permanente de tener localizados e informados a sus recursos (especialistas, médicos, enfermeras, auxiliares de servicios, etc.) así como de fusionar toda la información que producen continuamente los pacientes (sensores vitales, resultados de las pruebas analíticas, estado anímico, etc.)

Basándose en estudios preliminares que demostraban que el uso de la MI en entornos de trabajo (Nardi, Whittaker, & Bradner, 2000) (Isaacs, Walendowski, Whittaker, Schiano, & Kamm, 2002) (Hofte, Mulder, Poot, & Langley, 2003)(Vos, Hofte, & Poot, 2004), el Centro Noruego de Telemedicina, perteneciente al Hospital Universitario de Noruega del Norte, en colaboración con la empresa local Well Diagnostics AS, llevaron

128 4. APLICACIONES DEL PROTOCOLO XMPP

a cabo un proyecto para implantar un sistema de MI para dicho hospital, llamado MediMob (Bønes, Hasvold, Henriksen, & Strandenæs, 2006).

Ilustración 28. Arquitectura del sistema noruego MediMob de MI para hospitales En el sistema MediMob, los clientes XMPP se desarrollaron para la plataforma Java MIDP 2.0 de forma que pudieran desplegarse sobre una amplia gama de teléfonos móviles. El hecho de emplear clientes móviles con conexión a Internet directa por GSM/GPRS fue garantizar la conectividad cuando los terminales estuvieran fuera del alcance de la WLAN32 del hospital.

Un proyecto en entornos de este tipo, y por la naturaleza de los datos que se transmiten, tiene una serie de requisitos de seguridad de la información y protección de los datos personales: secreto profesional, acuerdos de confidencialidad impuestos a todos los trabajadores sanitarios, directiva europea 95/46/EC en materia de protección de datos, la HIPAA33 norteamericana, etc.

Para asegurar la confidencialidad de los datos se empleó el cifrado extremo a extremo que proporciona el mecanismo SSL/TLS del protocolo XMPP, además de otras medidas de seguridad propias del aseguramiento de las redes del hospital.

32 Wireless Local Area Network 33 American Health Insurance Portability and Accountability Act, 1996

129 ESTUDIO DEL PROTOCOLO XMPP DE MENSAJERÍA INSTANTÁNEA

4.2.2. Aplicaciones en el área de finanzas, seguros y comercio

Esta es un área muy poco tradicional de aplicación de XMPP y de los sistemas de MI en general.

No obstante, han sido varias las agencias de brokering que han experimentado con XMPP y desarrollado herramientas de trabajo para facilitar a sus clientes el seguimiento de las cotizaciones de valores en bolsa, materias primas, derivados, etc. Un ejemplo de lo anterior lo fue sido la iniciativa de la start-up canadiense Net Energy34, una empresa que nació en los primeros años de esta década con vocación de articular un mercado OTC35 para reproducir a escala regional y local el mercado New York Mercantile Exchange (NYMEX). Esta empresa utilizó XMPP para crear un sistema de trading basado en MI.

XMPP ofrece un marco de tecnologías excepcionalmente asequible para desarrollar aplicaciones de trading y subastas electrónicas, en cambio, hoy día existen mejores opciones como AMQP36 y su implementación abierta RabbitMQ37. El motivo es que este tipo de aplicaciones requieren de calidad de servicio (QoS) y garantías de entrega de los mensajes. No basta tampoco que XMPP ofrezca mensajería en “casi tiempo real”, sino que debe ser “tiempo real”. Por otro lado, la escalabilidad de las implementaciones de XMPP, a pesar de ser más que aceptable su rendimiento38 no llega ni de lejos a la que se necesitaría en un mercado de cambio de valores.

34 La empresa ya no existe, aunque tiene todavía activa su página web en http://www.netenergy.com 35 Over the Counter Market. Mercado financiero descentralizado, sin una localización espacial concreta, en el que la contratación se realiza telefónicamente o por procedimientos electrónicos, por lo que no suele formarse un precio único. 36 Advanced Message Queuing Protocol un protocolo estándar de mensajería de alto rendimiento creado por importantes empresas como JP Morgan Chase, Cisco y RedHat, para ofrecer una alternativa a los middleware empresariales como IBM Websphere MQ o TIBCO. Existe ya más de una implementación abierta: OpenAMQ (la de referencia), Apache Incubator, Apache Qpid, y una última RabbitMQ, todas ellas software libre. 37 Ver http://www.rabbitmq.com 38 Algunos benchmarks lo situan en 7000 usuarios simultáneos con un throughput de más de 2000 mensajes por segundo, utilizando como servidor un Bi-Xeon 2,5Ghz con 1Gb RAM y SO Linux.

130 4. APLICACIONES DEL PROTOCOLO XMPP

Ilustración 29. Aspecto del interfaz del cliente XMPP de Net Energy Exchange En cambio, en lo que XMPP podría añadir mucho valor es como protocolo de publicación y suscripción de noticias en tiempo real (cotizaciones, noticias, etc), alternativa al RSS39 o ATOM.

4.2.3. Aplicaciones en el área de cooperación y ONGs

Cada vez más, España, como el resto de los países de su entorno, participan en una serie de coaliciones internacionales como las formadas para servir en Bosnia, Kosovo, Iraq y Afganistán. Además, es común que estos mismos países desplieguen sus fuerzas armadas para dar soporte en grandes catástrofes naturales que requieren de una extraordinaria movilización de recursos para prestar asistencia humanitaria (como por ejemplo el huracán Mitch de 1998, el tsunami del Océano Índico de 2004 o el terremoto de Kashmir de 2005)

En este tipo de operaciones existe la necesidad de coordinar a múltiples cuerpos civiles y militares de más de una nacionalidad, entre los que se incluyen ejércitos, cuerpos de policía, bomberos, protección civil, agencias del gobierno local e

39 Really Simple Syndication

131 ESTUDIO DEL PROTOCOLO XMPP DE MENSAJERÍA INSTANTÁNEA

internacionales, ONGs, voluntarios de la sociedad civil… y por supuesto hay atender a las víctimas de manera urgente y eficaz.

La tecnología IM y los protocolos XMPP pueden ayudar a coordinar equipos de trabajo así como a enrutar por Internet mensajes entre las plataformas de las diferentes unidades operativas.

Actualmente ya existen varias plataformas tecnológicas de gestión y coordinación de desastres que emplean XMPP en distinto grado: SIFP-ShareInfoForPeople (US DoD) y Sahana Project ( Foundation).

De nuevo, resulta curioso que de los dos proyectos citados en este trabajo, uno haya sido promovido también por el Departamento de Defensa de los Estados Unidos. Sin embargo, el proyecto SIFP-ShareInfoForPeople está controlado al 100% por el Gobierno USA, que restringe su uso y monopoliza su gestión.

En cambio, el proyecto Sahana, como software libre que es, tiene mayor interés por su empleo de tecnologías Web 2.0 conjuntamente con las bondades del protocolo XMPP para la MI y la distribución de datos vía mecanismo pub-sub.

El proyecto Sahana, merecedor de varios premios40, ofrece las siguientes funcionalidades: - Registro de Personas Perdidas. Boletín online de personas perdidas y halladas. El sistema es capaz de poner en contacto a dos miembros separados de una familia que estén buscando a la misma persona. - Registro de la Organización. Básicamente, se trata de un registro capaz de responder “quién está haciendo qué cosas y dónde”. Es el registro que guarda toda la información de organización y recursos de las entidades que colaboran en la operación de ayuda humanitaria. - Registro de refugios y tiendas. Es la base de datos que permite conocer la ubicación exacta de cada tienda en un GIS, sus ocupantes y la dotación de equipamiento de la misma.

40 Ver el documental de la BBC “The Codebreakers”, disponible en la página web del Programa de Desarrollo de la región Asia-Pacífico de Naciones Unidas accesible en la URL http://www.apdip.net/news/fossdoc

132 4. APLICACIONES DEL PROTOCOLO XMPP

- Sistema de Gestión de Peticiones de Ayuda. Es un repositorio central donde todas las ONGs, voluntarios y agentes de los gobiernos pueden solicitar ayudas y suministros. Se ha diseñado como un sistema de compras y aprovisionamiento logístico. - Sistema de Coordinación de Voluntarios. Este sistema ayuda a las ONGs a realizar el seguimiento y la planificación de todos sus voluntarios, su información de contacto, localización de sus proyectos, disponibilidad y conocimientos. - Sistema para el Conocimiento de la Situación (Situation Awareness). Este módulo, al igual que los sistemas de mando y control militares, sirve para ofrecer un mapa de la situación del teatro de operaciones, permitiendo a la gente añadir información de contexto sobre lo que está ocurriendo sobre el terreno. Permite asimismo pinchar notas y fotografías sobre lugares en mapa, de forma que se complementa mejor ese mapa de la situación o Common- Operational Picture que se comparte entre todos los usuarios autorizados.

Su arquitectura de alto nivel es la siguiente:

Ilustración 30. Arquitectura de alto nivel del Proyecto Sahana

133 ESTUDIO DEL PROTOCOLO XMPP DE MENSAJERÍA INSTANTÁNEA

4.2.4. El Proyecto de Investigación Hesperia

El proyecto Hesperia41 es la mayor iniciativa que ha abordado España en materia de investigación técnica relacionada con la seguridad.

La razón por la que se cita en este trabajo es porque se trata de una gran oportunidad de aplicación para XMPP que podría contribuir a seguir avanzando en el desarrollo del protocolo, con nuevas extensiones que, por ejemplo, introdujeran reglas de garantías de calidad del servicio (QoS) en el protocolo pub-sub, o que se impulsara el intercambio de datos estructurados y fuertemente tipados, para transportar las lecturas de los múltiples sensores que puede tener un sistema de seguridad.

4.2.4.1. Resumen del Proyecto

Hesperia tiene por objeto el desarrollo de tecnologías que permitan la creación de sistemas punteros de seguridad, vídeo vigilancia y control de operaciones de infraestructuras y espacios públicos42.

El objetivo general del proyecto es el desarrollo de tecnologías que incrementen drásticamente la seguridad de las infraestructuras públicas especialmente sensibles, como subestaciones eléctricas, en gas, depósitos de agua o estaciones de telecomunicaciones. Por otro, incrementarán de forma sustancial los niveles de seguridad de grandes espacios públicos, como aeropuertos, estaciones de ferrocarril, puertos, centros de ciudades especialmente en zonas peatonales, centros comerciales, etc.

Este proyecto de I+D43 surgió en el año 2006 para dar respuesta a una demanda sostenida a medio y largo plazo, en particular, en los Países Occidentales, en los que estas futuras tecnologías encontrarían un nicho en el cada vez más importante mercado de la “Homeland Security”44.

41 Ver sitio del proyecto en ://www.proyecto-hesperia.org 42 Se encuadraría dentro del área de Homeland Security, si lo ponemos en un contexto internacional. 43 Uno de los 16 consorcios estratégicos nacionales de investigación técnica (CENIT). Tiene un presupuesto de 28.3 millones de euros, financiado por el CDTI y su duración es de 4 años (2006-2009). 44 Seguridad Nacional.

134 4. APLICACIONES DEL PROTOCOLO XMPP

La gestión integrada de seguridad y control de operaciones permitirá la implantación de sistemas rentables que, en este momento, no existen en el mercado.

El consorcio del proyecto está integrado por las empresas Indra Software Labs, Unión Fenosa, Tecnobit, SAC Control, Technosafe, Visual Tools y Brainstorm Multimedia. Asimismo, participan las universidades de Castilla La Mancha, de Granada, de Extremadura, la Politécnica de Madrid, la de las Palmas, la Politécnica de Valencia y la Politécnica de Cataluña. La lista se completa con la colaboración del Centro Superior de Investigaciones Científicas (CSIC) y el Centro Tecnológico del País Vasco (Ikerlan).

4.2.4.2. Líneas y objetivos de investigación

Para lograr la consecución de los objetivos previamente expuestos, en el proyecto Hesperia se está investigando principalmente sobre tres familias de tecnologías: - Tecnologías de Arquitecturas y Sistemas - Tecnologías de Conocimiento, Visión y Audio Cognitivos - Tecnologías de Presentación de Contenidos

Respecto a las Tecnologías de Arquitecturas y Sistemas, los objetivos que se persiguen son los siguientes: - Desarrollo de las innovaciones relacionadas con la integración de sistemas heterogéneos y tecnologías de fusión de información, desarrollando un middleware específico que cubra todas las necesidades del proyecto. - Construcción de Arquitecturas y Sistemas confiables que supongan un avance con respecto a la situación actual de las arquitecturas convencionales. - Desarrollo de un sistema eficaz de gestión de crisis que ayude a la toma de decisiones en situaciones de riesgo, apoyándose en técnicas de Inteligencia Artificial y Sistemas Expertos. - Desarrollo de un sistema de computación ubicua donde ciertos dispositivos (cámaras, etc.) se conviertan a su vez en agentes que tomen algunas decisiones, es decir, funcionen como agentes activos.

135 ESTUDIO DEL PROTOCOLO XMPP DE MENSAJERÍA INSTANTÁNEA

Se están siguiendo las siguientes líneas de investigación en Tecnologías de Arquitecturas y Sistemas: - Integración de sistemas heterogéneos y tecnologías de fusión de la información. o Sistemas Operativos de Tiempo Real para Sistemas Embarcados45, específicamente en el Software Libre y/o de Código Abierto. o Lenguajes y plataformas de desarrollo en Sistemas de Tiempo Real, especialmente las basadas en Java. o Mecanismos de seguridad de las comunicaciones o Arquitecturas de objetos distribuidos o Middlewares de integración de dispositivos. - Arquitectura y Sistemas confiables o plataforma Hesperia o computación en Grid o protocolos de despliegue y gestión OGSI46 en sistemas empotrados o arquitecturas SOA - Sistemas de gestión de crisis y modelado de decisiones o gestión de crisis desde la perspectiva técnica, social y psicológica o sistemas de gestión de emergencias y crisis o sistemas GIS para la representación de la información o tecnologías para la toma de decisiones espaciales o sistemas multiestrategia o tecnologías para la fusión de datos de fuentes múltiples o herramientas de gestión y descubrimiento de conocimiento - Computación Ubicua y Pervasiva

45 Sistemas Empotrados o Embebidos 46 Un servicio Grid es un servicio Web que sigue unconjunto de convenciones que le permiten una gestión controlada, resistente a fallos y segura, deservicios que mantienen estado. La especificación OGSA (Open Grid Service Architecture) pretende establecer la arquitectura común para aplicaciones basadas en el Grid, refinando elmodelo de los servicios Web. OGSA define qué son los servicios Grid, de qué deben de ser capaces, y enqué tipos de tecnologías deben de basarse, aunqueno proporciona una especificación técnica detallada.Por otro lado, OGSI (Open Grid ServiceInfrastructure) proporciona laespecificación formal y técnica de los conceptosdescritos en OGSA, incluyendo los servicios Grid. Existe software libre como Globus Toolkit para construir grids computacionales.

136 4. APLICACIONES DEL PROTOCOLO XMPP

o entornos de desarrollo de aplicaciones basadas en movilidad o dispositivos móviles o transmisión de vídeo a terminales móviles o tecnología RFID

Los objetivos que persigue la investigación en la familia de Tecnologías de Conocimiento, Visión y Audio Cognitivos, son muy ambiciosos, aunque no guardan relación con este trabajo. Estos objetivos son: - Desarrollo de las innovaciones relacionadas con la visión cognitiva, en particular con el análisis de alto y bajo nivel de video-secuencias. - Desarrollo de tecnologías de separación de fuentes sonoras, caracterización de registros humanos y no humanos, e identificación del interlocutor. - Desarrollo de tecnologías semánticas y de razonamiento de sistemas basados en el conocimiento. - Integración de tecnologías audiovisuales y de sistemas basados en el conocimiento para mejorar las funciones cognitivas de los sistemas.

Por último, los objetivos que se deberán alcanzar respecto a la investigación en Tecnologías de la Presentación, si el proyecto culmina con éxito, son: - Trasladar requerimientos y necesidades gráficas al desarrollo de aplicaciones gráficas para la visualización e interacción avanzada de sistemas de vigilancia - Desarrollar algoritmos para una rápida integración de elementos tridimensionales en las aplicaciones gráficas y que permitan la personalización de las mismas por parte del usuario. - Establecer mecanismos de acceso a bases de datos audiovisuales para su representación en entornos avanzados de visualización e interacción. - Evaluar entornos y tecnologías adecuadas para presentar la información gráfica al usuario e interaccionar con ella de la manera más eficiente posible.

137 ESTUDIO DEL PROTOCOLO XMPP DE MENSAJERÍA INSTANTÁNEA

4.2.4.3. Utilidad de la mensajería instantánea y el protocolo XMPP

Algunas partes del proyecto Hesperia guardan tremendas similitudes con los usos civiles comentados anteriormente, así como con aquellos militares que veremos más adelante. Por todo no es difícil concluir que XMPP puede ser una alternativa más a tener en cuenta, sobre todo dentro de los paquetes de trabajo de investigación en Tecnologías de Arquitecturas y Sistemas.

En lo que se refiere a la integración de sistemas heterogéneos y tecnologías de fusión de la información, XMPP podría ser uno más de los protocolos de transporte para el middleware de la Plataforma Hesperia, permitiendo la integración de aplicaciones a escala LAN, WAN e Internet, empleando software 100% libre y de código abierto, con conectividad opcional directa a otras redes de MI abiertas (Google Talk, Jabber, etc.) o conectividad a redes MI propietarias a través de de múltiples pasarelas o gateways (IBM Lotus Sametime, Microsoft OCS, etc.).

Respecto a las arquitecturas de sistemas confiables, XMPP puede jugar también un papel como protocolo de transporte de paquetes o mensajes XML (serializados o no, con datos estructurados y fuertemente tipados o no) que pueden servir para definir una arquitectura GRID propia.

138 4. APLICACIONES DEL PROTOCOLO XMPP

4.3. Aplicaciones para la defensa y la seguridad

Otro de los escenarios de uso de los protocolos de MI tiene que ver con las agencias y organismos vinculados a la defensa nacional y la seguridad. Precisamente ha sido este ámbito, el de la defensa, uno de los que más iniciativas han tomado en la evaluación de los usos de los protocolos de MI así como en aplicaciones de diversos de sus protocolos. Para entender el contexto que rodea las aplicaciones de protocolos de mensajería como XMPP, es conveniente explicar las necesidades de las fuerzas armadas así como la forma en que se trabaja en este tipo de organizaciones.

4.3.1. Introducción a las necesidades de las fuerzas armadas

Las Fuerzas Armadas españolas, así como las Fuerzas Armadas de los países de nuestro entorno, especialmente de la Organización del Tratado del Atlántico Norte (OTAN), tienen la necesidad de transformarse para hacer frente a la complejidad, incertidumbres y riesgos que el entorno de seguridad del siglo XXI ha planteado. Dicha transformación tiene como objetivo lograr una Fuerzas Armadas más ágiles, interoperables, conjuntas y capaces de ejecutar sus misiones, cubriendo un amplio espectro de operaciones diferentes en entornos muy dinámicos.

Estas fuerzas necesitan dotarse de unas capacidades compatibles con las de los países de la OTAN, así como la de otros países no pertenecientes a dicha organización y a las de organizaciones civiles con las que deben colaborar sobre el terreno de operaciones frecuentemente.

Para alcanzar todo lo anterior y para que los mandos puedan decidir en el tiempo oportuno y lo más rápidamente posible, las fuerzas deben dotarse de los medios tecnológicos adecuados para gestionar la información tanto en el nivel47

47 Los niveles de decisión de las Fuerzas Armadas se corresponden con los niveles de la guerra (o niveles de conflicto), que, según se describen en el primer volumen de operaciones de la Doctrina Militar Británica (Army Doctrine Publication, referencia DGD&D/18/34/46, Army Code No 71565) son cuatro: Gran Estrategia, Estratégico Militar, Operativo y Táctico. El nivel de Gran Estrategia se fija en la consecución de objetivos políticos mediante recursos diplomáticos, económicos y militares). El nivel Estratégico Militar es la aplicación de los recursos militares para conseguir los objetivos de la Gran Estrategia. Es común unir los dos niveles anteriores en uno sólo que denominamos Estratégico. El nivel Operativo se fija en la dirección de las campañas y grandes operaciones encomendadas por el nivel Estratégico Militar. El nivel Táctico se ocupa de dirigir y ejecutar misiones sobre el teatro de operaciones.

139 ESTUDIO DEL PROTOCOLO XMPP DE MENSAJERÍA INSTANTÁNEA

estratégico/operativo, como en el nivel táctico para el cumplimiento de la misión. De esta forma, la información fluirá apropiadamente desde el más alto escalón de mando hasta el nivel subordinado que se determine en cada momento.

Estos medios tecnológicos son, hoy día, críticos para alcanzar la victoria frente al enemigo y obligan a las Fuerzas Armadas a contar con las fuertes capacidades en: - Comunicaciones seguras y dinámicas - Medidas y contramedidas electrónicas, y en general, capacidades de guerra electrónica destinadas a la protección del espacio electromagnético y la destrucción de elementos para impedir o reducir la utilización enemiga de dicho espectro. - Sistemas de Telecomunicaciones e Información (CIS) - Sistemas de Mando, Control, Comunicaciones y Ordenadores (C4) - Sistemas de Inteligencia, Vigilancia y Reconocimiento (ISR)

La victoria depende en gran medida del principio de Superioridad de la Información48, asegurando que el enemigo tenga el menor control posible sobre lo que en términos anglosajones se denomina Situation Awareness (SA) o Conciencia de la Situación.

Para ello, la esfera de control no debe basarse una reducción de los niveles jerárquicos, agilizando la organización y mejorando el flujo de información, aislando en lo posible este flujo de datos de la cadena de mando en beneficio del ritmo en el planeamiento y conducción de las operaciones.

Se debe asegurar igualmente que el nivel táctico tenga un conocimiento preciso de la SA, ya que cualquier acción en este ámbito tiene consecuencias estratégicas.

La situación, planes, potencia de combate, preparación de las fuerzas propias y sus datos logísticos, se pueden obtener mediante la transmisión en tiempo oportuno (en ocasiones real) de los datos necesarios empleando Sistemas de Información (SI) y GPS

48 La OTAN definió en 2003 la Superioridad de la Información como la capacidad propia para obtener, procesar y distribuir la información precisa para satisfacer las necesidades de los diferentes escalones de mando, así como para prever los cambios en las necesidades de información del enemigo, al mismo tiempo que se niega al enemigo la capacidad para realizar lo anterior.

140 4. APLICACIONES DEL PROTOCOLO XMPP

(Global Positioning System) apropiados que, además, pueden recibir la información desde los niveles superiores y de otros países. Lo mismo ocurre con los datos meteorológicos y los datos proporcionados por los sensores de los sistemas de armas49.

Toda esta información sobre la situación debe ser compartida en los diferentes escalones de mando: cuarteles generales, órganos y unidades que tengan necesidad de ella. Asimismo se debe conocer la intención del mando, la doctrina y las capacidades de las fuerzas propias y enemigas.

Por todo lo anterior, se debe formar una red informativa para poder compartir la información requerida.

4.3.2. Los sistemas NEC

Para que toda la información necesaria sea aprovechable, es imperativa la optimización de los procesos de gestión y los flujos de información así como las características de las redes por donde esta información se difunde y comparte.

En la actualidad, los ejércitos desarrollan e implantan sus propios sistemas CIS por medio de los cuales se explota la información para hacer un uso privativo de cada ejército. De esta forma se compromete la interoperabilidad conjunta y, más aún, la combinada.

Un ejemplo de lo que representaría la interoperabilidad conjunta y combinada lo constituye un helicóptero no tripulado50 que detecta carros de combate enemigos y transmite la información, directamente, a una unidad antiaérea o a un puesto de mando apropiado para ordenar, en tiempo real o casi real, una acción aérea de apoyo aéreo próximo. Las acciones en el campo de batalla como esta requieren el entendimiento entre los sistemas, las plataformas de armas, los ejércitos y los aliados. Lamentablemente, a pesar de que el estado del arte actual de la ingeniería de sistemas de armas está muy avanzado, dicha interconexión y los niveles de automatización en la transmisión de la información por la cadena de mando no es trivial.

49 Conjunto de armas, equipamientos militares y de los componentes nece-sarios para su operación, empleados como una entidad para desempeñar una misión militar. 50 Unmanned Aerial Vehicle o UAV

141 ESTUDIO DEL PROTOCOLO XMPP DE MENSAJERÍA INSTANTÁNEA

Para compartir información y definir los medios empleados en gestionarla, a finales de los años noventa surgió en Estados Unidos, extendiéndose con posterioridad a otros países, el novedoso concepto de NCW (Network Centric Warfare), que en términos OTAN se denomina NNEC (NATO Network-Enabled Capability51), o red que consiste en una serie de nodos conectados entre sí en la que cada nodo realiza actividades y recibe la información que, una vez procesada, sirve de base para decidir y actuar y pone a disposición de otros o entidades el resultado de estos procesos.

Para lograr sus objetivos, la red precisa de una potente red de datos (data link o enlace de datos) como herramienta básica para compartir información entre sensores, plataformas de mando y control y vectores o sistemas de armas.

Ilustración 31. Aproximación NEC/NCW al campo de batalla del futuro

51 Según la definición de la propia OTAN, el concepto NNEC se refiere a “la habilidad técnica y cognitive de la Alianza para federar los diferentes components de un entorno operative, desde el nivel estratégico (incluyendo el Cuartel General de la OTAN) hasta los niveles tácticos, a través de una Infraestructura de Redes de Información (networking and information infrastructure, NII)”

142 4. APLICACIONES DEL PROTOCOLO XMPP

Como consecuencia de la aplicación del concepto NNEC, los entornos operativos del futuro (e ideales) serian tales que se permitiría el intercambio de información táctica entre aliados, que tendrían sistemas y redes de comunicaciones interoperables. Ello posibilitaría, por ejemplo, que la información táctica recogida por los sensores de un UAV de un país “X” en un teatro de operaciones determinado, podría enviarse por enlace satélite a su Cuartel General, para ser retransmitida por una línea punto a punto de fibra óptica submarina a otro país “Y”, que a su vez podría retransmitirla por satélite a otro país “Z”, quien por enlace LOS (Line Of Sight) la haría llegar a un avión AWACS52, que a su vez y por fin, y también por LOS, la despacharía hacia sus aviones de combate para el cumplimiento de la misión.

El concepto NNEC permite la dispersión de la fuerza; estas pueden moverse sin perder conexión, recibir apoyo logístico, gestionar mejor los objetivos, reducir riesgos por menores vestigios en el terreno o footprint. De esta forma se consigue un dominio mayor de la información frente al enemigo, a la vez que las fuerzas tendrán mayor conocimiento del espacio de batalla. Habrá también un enlace efectivo entre las diferentes entidades que actúan sobre el teatro de operaciones, por medio de una infoestructura o esfera de información en los ámbitos político-estratégico, operacional y táctico.

La información del enemigo puede obtenerse de diferentes fuentes: Plataformas de Inteligencia, Vigilancia y Reconocimiento (ISR); como partes de una red de sensores o de sistemas de armas; e inteligencia obtenida por medios humanos (HUMINT).

Para una adecuada explotación de la información, se deben emplear redes y protocolos de comunicaciones que permitan transmitir y actualizar la información entre los nodos de la red con una velocidad tal que la imagen de la situación (COP53) sea la misma en todos los nodos y se posibilite a los sistemas de armas el cumplimiento de la misión encomendada. La criticidad de las misiones encomendadas a esos sistemas de armas, en las que se puede poner en riesgo la vida de civiles inocentes si no se cuenta

52 Airborne Warning and Control System. Son aviones dotados de equipamiento de comunicaciones muy avanzado, preparados para realizar labors de inteligencia, vigilancia, reconocimiento y guerra electrónica. 53 Common Operational Picture

143 ESTUDIO DEL PROTOCOLO XMPP DE MENSAJERÍA INSTANTÁNEA

con la información correcta, hace que la infraestructura de comunicaciones soporte Calidad de Servicio (QoS54), así como la interconexión de los Sistemas de Mando y Control (C2) a la red común, junto con los sensores y los sistemas de armas.

Estas redes comunes están actualmente formadas por una serie de redes de diferentes tecnologías y con serios problemas de interoperabilidad y escasez de ancho de banda en muchos casos. En la actualidad, las redes IP ya comienzan a dominar este ámbito; en el futuro se espera que todas las demás tecnologías de redes se vayan sustituyendo por tecnología IP.

En el caso de las Fuerzas Armadas españolas, se dispone de una Red Global de Telecomunicaciones (RGT), compuesta de: - Redes de Voz y Datos de propósito general, basados en Redes Privadas Virtuales de voz (fija y móvil) y datos. Son contratadas a operadores públicos y gestionadas desde el Centro Corporativo de Explotación y Apoyo (CCEA). - Redes propias del Ministerio de Defensa (telecomunicaciones de mando y control):  Red Conjunta de Telecomunicaciones (RCT) del Sistema Conjunto de Telecomunicaciones Militares (SCTM). Red militar multiservicio y de alta disponibilidad a nivel nacional que llega a los principales emplazamiento del Ministerio de Defensa y que ofrece enlaces vía satélite a través del Sistema Español de Comunicaciones Militares por Satélite (SECOMSAT). Su gestión depende directamente del Estado Mayor de la Defensa.  Red de Área Extensa (WAN) para mando y control militar, que se conecta a los entornos tácticos.  Redes de Telecomunicaciones Tácticas. Su gestión y explotación la realizan cada uno de los Ejércitos y la Armada. - Radio enlaces de banda ancha (ATM, WiMAX), con velocidades de 54 Mbps en distancias de hasta 50 Km. Estas tecnologías se emplean para la comunicación con escalones superiores.

54 Quality of Service

144 4. APLICACIONES DEL PROTOCOLO XMPP

- Radio enlaces y Radios de banda ancha de hasta 512 Mbps para proporcionar conectividad hacia escalones subordinados. - Enlaces satélite en movimiento (SOTM55) y fijos (SOTP56), a través del SECOMSAT - Red Radio de Combate (RRC), actualmente basada en el sistema PR4G v3, que en las bandas VHF. La PR4G es una Radio Definida por Software (SDR) que incluye conectividad IP con capacidad de enrutamiento automático adaptativo. - Red de Radio Trunking Digital. Sistemas Tetra57 y Tetrapol para transmisión de voz y datos en las distintas modalidades previstas por dicho estándar (mensajes de estado, datos cortos, y datos en modo paquete). El sistema TETRA está constituido básicamente por dos tipos de emplazamientos denominados Emplazamiento Maestro (Centro de Gestión y Conmutación) y Emplazamientos Remotos (las Bases de Cobertura Radio). Contempla Voz sobre IP, WiMAX y WiFi (IEEE 802.11E)

4.3.3. La superioridad en la gestión de la inteligencia

El mando de doctrina del Ejército de Tierra español señala, al hablar del campo de batalla futuro58, que la gestión del conocimiento trata de alcanzar, frente al enemigo, la superioridad en el uso y manejo de la información, gestionando con superioridad la inteligencia. Así, los Sistemas CIS59 que se ocupan de gestionar información y conocimiento, proporcionarán en el espacio de batalla: - Una mayor precisión en el conocimiento de la situación - Mejorar el conocimiento de los efectos producidos, antes, durante y después de las acciones - Gran velocidad en la observación de la realidad y la toma de decisiones

55 Satellite On The Move 56 Satellite Ont The Pause 57 Transeuropean Trunking Radio 58 MADOC: Campo de Batalla Futuro, 2005 59 Communication and Information Systems

145 ESTUDIO DEL PROTOCOLO XMPP DE MENSAJERÍA INSTANTÁNEA

- Mayor agilidad, eficiencia y rapidez en la agrupación y/o dispersión de los recursos empleados.

La gestión del conocimiento implica que se debe compartir la información de la situación entre las diferentes unidades del espacio de batalla. A pesar de ello, no se debe realizar la misma difusión en todos los escalones de mando, sino que se debe compartimentar, estructurar y catalogar dicha información, proporcionando a cada escalón únicamente aquello que sea relevante y procedente.

En la actualidad, los medios técnicos disponibles (arquitecturas SOA, servicios web, REST, y, claro está XMPP) harán posible que la esfera de la información táctica que se mencionaba con anterioridad sea dinámica y se alimente de datos en demanda o vía eventos (de forma síncrona o asíncrona).

Los sistemas C2 deben ser los que aglutinan y ordenan dicha información, descartando mensajes no prioritarios o cuyo tiempo de vida está caducado, eliminando la información basura y detectando la posible presencia en el medio de “ladrones de recursos” que deben ser convenientemente tratados.

Además, los sistemas de C2 deben ocuparse de filtrar los mensajes para que cada jefe de escalón de mando, así como los oficiales de los cuarteles generales tengan acceso a la información necesaria para cumplir su misión, que llegará a los usuarios de forma transparente, independientemente de los estrictos mecanismos de seguridad que podrían darse en el caso de una coalición de Naciones en el que cada ejército de cada nación debe interconectar sus Sistemas CIS al resto.

Por último, la Seguridad de la Información (INFOSEC60) es un factor muy importante para mantener la superioridad en la gestión de la inteligencia. Los procedimientos, aplicaciones y sistemas de cifrado de INFOSEC deben asegurar que la información precisa llega a la persona adecuada en el momento oportuno, así como que se garantiza la disponibilidad, integridad, confidencialidad, autenticación, identificación y no repudio en la gestión de la información, prohibiendo el acceso a la misma de las fuerzas hostiles.

60 En la actualidad se emplea el término, más amplio que el de INFOSEC, Information Assurance

146 4. APLICACIONES DEL PROTOCOLO XMPP

Las tendencias recientes en adquisiciones militares vienen demostrando desde hace años un alto interés en introducir las tecnologías de colaboración en los entornos de mando y control (Kaufman, 2005). El personal participante en este tipo de entornos puede estar dispersado en términos de rango, empleo e incluso ubicación geográfica, aunque se espera de ellos que puedan formar rápidamente equipos de trabajo para cumplir las misiones que les sean asignadas (Boiney, 2005). Así, se ha propuesto (Alberts & Hayes, 2003) que la integración y el rendimiento pueden lograrse mediante el empleo de las tecnologías colaborativas hasta hace muy poco consideradas como emergentes, tales como el e-mail, la mensajería instantánea (MI), las pizarras virtuales61 y la videoconferencia. Los defensores de la filosofía NEC y de las Operaciones en Red62 han argumentado que este tipo de tecnologías podrían contribuir significativamente a la descentralización del mando, lo que podría resultar en un incremento de la SA63 y la flexibilidad en la asignación y cumplimiento de las tareas de la misión (Alberts & Hayes, 2003). Sin embargo, cada vez existe más preocupación acerca del impacto potencialmente negativo sobre el rendimiento que podría tener el uso de herramientas colaborativas en entornos distribuidos (y en movimiento) donde las de las decisiones que se toman dependen objetivos estratégicos, vidas humanas y donde el tiempo es un factor en contra y la constante adaptación a una situación cambiante hacen que cualquier distracción o barrera en la comunicación lleven al fracaso una misión. Lo anterior desde el punto de vista táctico. Técnicamente, además, existe un problema de escasez y alto coste del ancho de banda en el nivel táctico, sobre todo a nivel de Red Radio de Combate, donde el ancho de banda disponible puede ser de unos exiguos 38 Kbps, como es el caso de las radios de combate PR4G V3 que fabrica Amper para el Ejército de Tierra, las cuales implementan un protocolo F@stnet con conectividad IP.

Dicha preocupación está apoyada por diversos estudios empíricos de los que existe literatura disponible. Los dos principales estudios sobre el impacto de las tecnologías de

61 Virtual Whiteboards en su denominación original. Se trata de aplicaciones con un interfaz gráfico de dibujo más o menos avanzado (según modelos) en el que todos los usuarios actúan sobre el mismo canvas. Suele ir acompañado de otras utilidades tales como IM y audio/video multiconferencia. 62 Network-Centric Operations 63 Situational Awareness, ver página 120

147 ESTUDIO DEL PROTOCOLO XMPP DE MENSAJERÍA INSTANTÁNEA

colaboración en los procesos de trabajo en equipo son los de Bordia (1997) y Baltes, Dickson, Sherman, Bauer, & LaGanke (2002).

4.3.4. Estudios en contra y a favor del empleo de MI en el nivel táctico

Bordia (1997) examinó los efectos de las tecnologías de colaboración basadas en texto (no multimedia) sobre los procesos de trabajo en equipo. Específicamente, Bordia examinó 18 estudios experimentales, en los cuales comparó la efectividad en la toma de decisiones del equipo, el tiempo hasta alcanzar una decisión y la satisfacción de los miembros, entre equipos a los que se les había restringido las posibilidades de colaboración a las ofrecidas por las tecnologías de colaboración no-multimedia (como la MI y el e-mail) y otros equipos a los que se les había permitido el trabajo presencial conjunto. El estudio de Bordia (1997) concluyó que los equipos cuya comunicación se restringía a herramientas de colaboración en red tomaban peores decisiones y en más tiempo, además de generar insatisfacción en sus miembros.

El estudio de Baltes, Dickson, Sherman, Bauer, & LaGanke (2002) se basó en un meta-análisis en el que se exploraron las diferencias en el rendimiento de los dos tipos de equipos. En su meta-análisis, Baltes et al. (2002) examinó 27 estudios experimentales relativos a tecnologías de colaboración orientadas a texto, analizándolos en términos similares a los empleados por Bordia (1997). Los resultados fueron similares a los hallados por Bordia (1997), favoreciendo con mucha diferencia a la comunicación tradicional presencial, cara a cara, frente al uso de la MI.

Sin embargo, ambos estudios habían sido realizados sobre una hipótesis de tipo de tareas para el trabajo en equipo que no podía ser asumido en proyectos de colaboración remota en sistemas C2.

Los experimentos de Bordia (1997) y Baltes et al. (2002) cubren una matriz determinada de tareas, la mayoría de ellas del mismo tipo, en su investigación. Refiriéndonos al modelo circumplejo de McGrath (1984), el tipo de tarea debe ser de uno de los siguientes cuatro tipos (en un cuadrante):

a) de generación (tareas de planificación y de creatividad);

148 4. APLICACIONES DEL PROTOCOLO XMPP

b) de elección (tareas intelectuales y de toma de decisiones); c) de negociación (tareas de resolución de conflictos de punto de vista o intereses); d) de ejecución (tareas de competición –inter/intra-equipos– o de rendimiento medido contra un estándar de excelencia).

En los experimentos de de Bordia (1997) y Baltes et al. (2002), todas las tareas que aparecían en la misión encomendada a los equipos pertenecían al tipo de tareas de elección definido por McGrath (1997). Y esto era un error de base, ya que, según McGrath (1984), la mayor parte del tiempo, y con mayor energía, los equipos del mundo real se ocupaban de tareas de tipo de ejecución. Esto es significativamente importante en el caso de entornos de mando y control (C2). A favor de esta hipótesis los autores Funke, Galster, Nelson y Dukes (2006) firman un artículo en el que se argumenta todo lo anteriormente expuesto, añadiendo que, el propio McGrath (1984) ya argumentaba que la única forma de evaluar el éxito de una tarea de tipo elección era evaluarlo en términos de rendimiento del equipo. El rendimiento sobre las tareas de ejecución, por otro lado, depende simultáneamente del rendimiento de cada equipo y de su oponente, haciendo la situación más dificil de examinar y evaluar.

Funke, Galster, Nelson y Dukes (2006) realizaron un experimento en el que lograron probar que el empleo de tecnologías de colaboración basadas en MI no afectaba prácticamente al desempeño de las tareas de la misión, ni en cuanto al rendimiento del equipo, ni en cuanto a la carga de trabajo, y que, cuando la naturaleza de las misiones obligaba a una readaptación continua de las estrategias, el ratio de mensajes de contenido irrelevantes (socializadores) por mensajes de contenido estratégico era muy bajo. Sólo coincidieron con el estudio de Bordia (1997) en que el número de mensajes intercambiados por los equipos con acceso restringido a sólo el MI fue mucho mayor que los mensajes verbales registrados en sus oponentes.

Dicen en su artículo Funke, Galster, Nelson y Dukes (2006) que debe investigarse más acerca de los tipos de tareas de ejecución ya que debe recogerse la naturaleza

149 ESTUDIO DEL PROTOCOLO XMPP DE MENSAJERÍA INSTANTÁNEA

dinámica y adversa de muchas circunstancias del mundo real en los cuales se espera de los equipos que encajen y operen sin problemas. Por ejemplo, las situaciones de guerra urbana, que se encuentran frecuentemente las tropas de coalición en Iraq (Batiste & Daniels, 2005), ponen de manifiesto que existen al menos dos equipos enfrentados con metas similares pero contrarias (eliminar fuerzas enemigas, preservar las tropas aliadas) que se desarrollan sobre un marco de tiempo determinado por las metas de las tareas de la misión (p.e. luchar hasta vencer). Tales escenarios requieren de los equipos una agilidad en el diseño y ejecución de estrategias y contraestretagias, con un encadenamiento de cambios de esas estrategias, adaptándolas a las circunstancias del combate y de los objetivos y las tareas de la misión. Por último, los autores también señalan que debe investigarse mucho más sobre el impacto que tiene el empleo de tecnologías de colaboración sobre la SA compartida entre los miembros de equipos remotos, así como sobre la carga de trabajo de los equipos.

150 4. APLICACIONES DEL PROTOCOLO XMPP

4.3.5. Aspectos de interés militar del protocolo XMPP

A finales del año 2005, el Information Technology Standards Council (ITSC) del Departamento de Defensa de los Estados Unidos64 aprobó la inclusión del protocolo XMPP como un estándar obligatorio del DoD IT Standards Registry (DISR). Este hecho tiene especial relevancia porque XMPP es el único estándar de MI aprobado por el DISR. Desde entonces han sido decenas de agencias gubernamentales las que han adoptado XMPP como protocolo de MI. Sin embargo, como se ha descrito en el apartado anterior, no fue fácil convencer a las fuerzas armadas estadounidenses primero, y a la propia OTAN después, de las bondades de este tipo de tecnologías.

El protocolo XMPP tiene muchas funcionalidades de MI que resultan interesante para innumerables aplicaciones civiles, tal es el caso del chat multiusuario o MUC (XEP-0045). Sin embargo entre las decenas de extensiones XEP que tiene XMPP, hay unas cuantas de especial interés militar, ya que pueden ser potencialmente útiles en sistemas C2, así como en otros sistemas tácticos.

4.3.5.1. XEP0045: MultiUser Chat (MUC)

Como ya se comentó en el apartado “3.3.7.3. Algunas de las XEPs más importantes”, el XEP-0045 describe una implementación estándar de chat en grupo sobre el protocolo de mensajería XMPP.

Existen numerosos precedentes del uso de este tipo de chats en la Marina de los Estados Unidos desde los tiempos del IRC.

En concreto, el MUC está implementado de acuerdo a las siguientes reglas: (Saint- Andre P. , XEP-0045: Multi-User Chat, 2008)

- Cada sala de conversación se identifica con un JID room@service (p.e., [email protected]) donde room es el nombre de la sala de conversación y service es el host que aloja el servicio MUC. - Existen varios tipos de sala:

64 US DoD

151 ESTUDIO DEL PROTOCOLO XMPP DE MENSAJERÍA INSTANTÁNEA

 Visible u oculta: las salas ocultas no aparecen en las listas de salas, mientras que las visibles sí.  Permanente o temporal: si es temporal, se eliminará en cuanto quede vacía.  Solo para miembros o abierta: si es para miembros, sólo pueden acceder aquellos que estén en la lista de miembros de la sala. Si es abierta no es necesario.  Protegida por contraseña o no: para acceder será necesario introducir una contraseña.  Moderada o no moderada: si es moderada, solo podrán hablar aquellos usuarios con voz.  No anónima o semi-anónima: si no es anónima cualquier usuario puede ver el JID de otro. si es semi anónima, sólo pueden verlo los administradores de la sala. También sería posible la adopción de salas totalmente anónimas, donde nadie puede ver el JID de ninguno de los integrantes, pero esto no ha sido avalado por el XEP. - Todo usuario en una red MUC posee, respecto a cada sala, dos aspectos que definen su relación con esta: el rol que actualmente juega en ella y la afiliación que tiene con esta sala. - El rol del usuario en la sala tiene relación con el estado actual respecto a ella, no poseen una persistencia clara y cambian con cada entrada del usuario en la red o por acciones llevadas a cabo por usuarios con los debidos privilegios. - Existen los siguientes roles:  Moderador: suelen poseer un mayor número de privilegios.  Participante: es el rol que adquiere un usuario no afiliado al entrar en una sala no moderada. Poseen menos privilegios que los moderadores, pero siempre tienen permitido el enviar mensajes.  Visitante: es el rol que adquiere un usuario no afiliado al entrar en una sala moderada. Posee menos privilegios que el participante.  Ninguno (sin rol en la sala): son los usuarios que no están dentro de la sala.

152 4. APLICACIONES DEL PROTOCOLO XMPP

- La afiliación de cada usuario en la sala queda registrada en el servidor de un modo más persistente, sin verse alterada tras la salida del usuario de la red. Para cada tipo de afiliación existe una lista de usuarios afiliados que sólo puede ser modificada por aquellos con los debidos privilegios. - Se definen los siguientes tipos de afiliaciones: 1. Propietario 2. Administrador 3. Miembro 4. Usuario inadmitido 5. Ninguno (sin afiliación en la sala) - Cada ocupante de una sala se identifica con un nick de la siguiente manera room@service/nick, donde nick es el descriptor o nickname que ha elegido el ocupante (p.e., nuestro personaje, Romeo podría elegir [email protected]/amante_bandido1595) - Los usuarios acceden a una sala de conversación enviando su información de presencia a un JID room@service/nick - Los mensajes enviados desde dentro de salas de conversación MUC son de un tipo especial ‘groupchat’ se remiten a la propia sala (p.e., [email protected]) por lo que cada uno de los ocupantes recibe una copia del mensaje. - Un ocupante puede cambiar su nickname y estado de disponibilidad mientras está dentro de la sala. Para ello envía su presencia al JID room@service/newnick, donde newnick es el nuevo nickname elegido. - Un ocupante abandona una sala MUC enviando una actualización de su presencia a ‘unavailable’ al JID room@service/nick.

Además, la extensión XEP-0045 define una larga serie de funciones administrativas de las salas de chat, que regulan lo que un usuario (ocupante) puede hacer y lo que no. Básicamente se resumen en las siguientes: - Registro de conversaciones nativo (no se requiere un bot en la sala)

153 ESTUDIO DEL PROTOCOLO XMPP DE MENSAJERÍA INSTANTÁNEA

- Se permite a los usuarios solicitar el ingreso en una sala de conversación - Se permite a los ocupantes ver el JID completo de otro en las salas de tipo no anónimas - Habilitar a los moderadores para ver el JID completo de otro en las salas de tipo semi-anónimas - Permitir sólo a los moderadores cambiar el asunto o tema de conversación de una sala - Permitir a los moderadores reprender a participantes y visitantes de la sala - Permitir a los moderadores y revocar la concesión de la palabra (es decir, el privilegio de hablar) en una habitación moderada, así como gestionar la lista de revocaciones - Permitir a los administradores otorgar y revocar privilegios de moderador, así como gestionar la lista de moderadores - Permitir a los administradores prohibición de acceso a usuarios de la sala, así como gestionar la lista negra correspondiente - Permitir a los administradores otorgar y revocar privilegios de miembro, así como gestionar las listas de miembros en las salas reservadas a miembros - Permitir a los propietarios delimitar el número de ocupantes - Permitir a los propietarios de especificar otros propietarios - Permitir a los propietarios de la concesión y revocación de privilegios administrativos, y así como gestionar la lista - Permitir a los propietarios de eliminar la sala

Entre estas características básicas que define la extensión XEP-0045 del protocolo XMPP, se ha citado una que merece una atención especial en proyectos militares y que es la que tiene que ver con los tipos de salas de conversación, ya que, con algunas adaptaciones, es posible modular la

154 4. APLICACIONES DEL PROTOCOLO XMPP

seguridad en el acceso a la información en entornos operacionales y tácticos.

Como conclusión, la funcionalidad de la extensión XEP-0045 proporciona un conjunto muy rico de herramientas para la gestión y configuración de salas de conversación MUC, que a su vez cumplen muchos de los requisitos de gestión de la información que se necesitan en entornos militares. Estas herramientas pueden permitir a las fuerzas armadas la construcción de soluciones de colaboración e MI de muy alto nivel y con arquitecturas abiertas y escalables.

4.3.5.2. XEP0060: PublicaciónSubscripción

A medida que la tecnología XMPP ha ido madurando, la necesidad de contar con un mecanismo de publicación-suscripción65 se ha manifestado en muchos dominios de soluciones, entre otros: flujos de noticias66, sindicación de contenidos, presencia extendida, geolocalización, gestión de avatares, favoritos67 y enlaces compartidos, subastas electrónicas, mercados regulados electrónicos68, sistemas de workflow69, sistemas de gestión de redes, gateways NNTP y, en general, cualquier aplicación que necesite comunicarse asíncronamente mediante notificaciones de eventos.

En todos estos dominios de soluciones, es deseable para la comunicación de datos que se siga el clásico patrón de diseño del “observador” o de “publicación-subscripción: una persona o aplicación publica información, y un evento de notificación (con o sin datos asociados) se difunde a todos los suscriptores autorizados a los datos de esas notificaciones.

En general, la relación entre el publicador y el suscriptor la intermedia un servicio que recibe las peticiones de publicación, hace broadcast de los eventos de notificación a

65 PUBSUB, de Publish-Subscribe 66 News Feeds. RSS/Atom es un mecanismo parecido con el que es compatible el mecanismo pubsub de XMPP 67 Muchas redes sociales se basan en los fenómenos del bookmarking y tagging (compartir enlaces y cualificarlos) 68 Muchos de los sistemas de trading de los brokers de bolsa emplean mecanismos pubsub con capacidad QoS y en tiempo real 69 Microsoft Workflow Collaboration foundation (WCF) emplea un mecanismo similar

155 ESTUDIO DEL PROTOCOLO XMPP DE MENSAJERÍA INSTANTÁNEA

los suscriptores, y permite a ciertas entidades con privilegios la administración de las listas de personas o aplicaciones que están autorizadas a escribir (publicadores) o leer (suscriptores) sobre ese bus de datos.

En la mayoría de los servicios de PubSub, lo que se publica o a lo que se suscribe uno es un node ("nodo"), que no es más que una estructura de datos sobre la que los editores envían sus datos70 y en la que los suscriptores reciben las notificaciones. Además, algunos nodos también pueden albergar un historial de eventos y prestar otros servicios que complementan el modelo puro PubSub.

RESOURCE Topic LIMITS R

Data S1 HISTORY Data Writer Reader S2 R R S3

S4 S5

Publisher S6 Subscriber S7

LATENCY

S7 XS7 S6 S5 S4 S3 S2 S1

COHERENCY RELIABILITY

Ilustración 32. Representación de los nodos de publicación/suscripción Los nodos que producen información (publicadores) crean “topics” (por ejemplo, temperatura, localización, presión…) y publican “samples” (muestras) de estos tópicos.

70Un lugar virtual donde se puede publicar información y desde el cual se reciben notificaciones y datos asociados (tópicos, como los denomina el protocolo DDS/Data Distributed Services del OMG /Object Modelling Group)

156 4. APLICACIONES DEL PROTOCOLO XMPP

El bus PUBSUB que implementa XMPP entrega estos “samples” a todos los suscriptores que declaren su interés en el tópico en cuestión.

Sin embargo, como XMPP no es un protocolo originalmente diseñado para mensajería en entornos de misión crítica (a pesar de rendir un comportamiento excelente, que lo sitúa a la cabeza de las arquitecturas MI), no implementa mecanismos de QoS, que son de extrema necesidad cuando se trata de sistemas en tiempo real, en los que se debe garantizar un nivel de servicio en todo momento.

El paradigma Data Distribution Service (DDS71) define una serie de propiedades de calidad de servicio (QoS) a la medida de la distribución de datos en los sistemas de tiempo real:

- Fiabilidad (Reliability: Best_Effort, Reliable) permite el uso de transportes eficientes para datos repetitivos

- Plazo (Deadline) establece contratos acerca de la tasa a la que se refrescan los datos repetitivos

- Presupuesto de latencia (Latency_Budget) establece las guías para obtener retardos aceptables

- Límites a los recursos (Resource_Limits) controla los recursos usados por el servicio

- Filtro basado en tiempo (Time_Based_Filter) desacopla a productores rápidos de consumidores lentos

- Historia (History: Keep_Last, Keep_All) soporta las semánticas de los datos de estado - Durabilidad (Durability: Volatile, Transient, Persistent)

Las implementaciones72 de Data Distribution Service (DDS) gestionan todas las fases de la transferencia: direccionamiento de los mensajes, la serialización y

71 Supuso la alternativa al CORBA en la programación de sistemas distribuidos (OMG, 2007) y en la actualidad dispone de varias implementaciones que son ampliamente utilizadas como middleware de comunicaciones en importantes sistemas de armas.

157 ESTUDIO DEL PROTOCOLO XMPP DE MENSAJERÍA INSTANTÁNEA

deserialización a formato estándar (así, los suscriptores pueden estar en diferentes plataformas a la del publicador), entrega, control de ancho de banda, reintentos, etc. Cualquier nodo puede ser un publicador, suscriptor, o ambas cosas simultáneamente. Así se gestionan automáticamente todos los aspectos de la entrega de mensajes (sin requerir de ninguna intervención por parte de la aplicación), incluyendo:

- Determinar quien debe recibir los mensajes,

- donde están localizados los destinatarios,

- y qué ocurre si los mensajes no pueden ser entregados.

Esto es posible por el hecho de que estas implementaciones del paradigma pubsub permiten al usuario especificar parámetros de calidad de servicio (QoS) como una forma de configurar los mecanismos de descubrimiento automático y de especificar el comportamiento deseado en el envío y recepción de mensajes.

Topic Topic Topic

Domain Data Participant Data Data Data Data Data Reader Writer Writer Reader Reader Writer

Subscriber Publisher Subscriber Publisher

Data Domain

Ilustración 33. Arquitectura de un bus de datos pub/sub No obstante, y a pesar de lo anterior, el mecanismo PUBSUB que define el XEP- 0060 para XMPP puede suponer un avance significativo en la interoperabilidad de los Sistemas de Mando y Control donde el número de mensajes intercambiados entre nodos no llega a ser tan alto como para requerir la inclusión de mecanismos QoS muy sofisticados (siempre está la opción de crear una nueva extensión del protocolo XMPP para implementar políticas de QoS en los servidores y clientes XMPP).

72 Existen varias implementaciones de DDS con presencia importante en la industria de la Defensa. Entre ellas están una de Thales y otra de Real Time Innovations.

158 4. APLICACIONES DEL PROTOCOLO XMPP

Por último, cabe decir que en el paradigma PUBSUB de comunicación de datos entre entidades está siendo actualmente empleada profusamente en muchos sistemas militares, entre los que destacan: (Millard, Saint-Andre, & Meijer, 2008) - Interconexión en tiempo real de módulos de simulación - Como parte de middleware de comunicaciones en sistemas NEC73 - Como parte de sistemas de protocolos de alerta masiva - Como pieza fundamental en la construcción de sistemas C2 con capacidades NEC que permitan ofrecer una Common Operational Picture exacta e idéntica a todos los actores del teatro de operaciones en el que se desarrolla una misión74

4.3.5.3. XEP0080: Geolocalización de Usuarios

Tal y como se mencionó en la sección sobre el mecanismo de publicación- suscripción, la geolocalización es uno de los posibles casos de uso del mencionado mecanismo de distribución de datos. La extensión XEP-008075 define un formato para capturar datos geográficos de una entidad. La extensión define (Hildebrand & Saint- Andre, 2008) dicho formato de datos de geolocalización como coordenadas GPS. Adicionalmente, se puede desarrollar un XML Schema específico que defina un namespace alternativo para los mensajes de geolocalización que permita manejar el sistema de referencia Military Grid Reference System empleado por las Fuerzas Armadas de los países de la OTAN.

4.3.5.4. XEP0124: HTTP Binding

Este XEP es de particular interés para el concepto de Chat Táctico XML (Armold, 2006), ya que muchas de las actividades vitales que se llevan a cabo en una operación militar se apoyan en redes inalámbricas muy austeras en las que mantener las conexiones persistentes TCP que define el Core del protocolo XMPP (Saint-Andre P. , Extensible Messaging and Presence Protocol: Core, 2004) no es viable.

73 Sistemas de Sensores ISR con capacidad NEC que difunden los datos de Inteligencia a los nodos de la red 74 Lo que contribuye al objetivo de mejorar la Situation Awareness (SA) 75 XEP-0080: User Location

159 ESTUDIO DEL PROTOCOLO XMPP DE MENSAJERÍA INSTANTÁNEA

La extensión XEP-0124 (véase “3.3.7.3. Algunas de las XEPs más importantes”) proporciona un mecanismo estándar para conectar una red de nodos con conectividad limitada o intermitente. Con arquitecturas de MI como la que se propone en esta definición de extensión del protocolo, implementada en todos los niveles de un Sistema de Mando y Control, permitiría una económica transición de la información desde las redes tácticas de alta capacidad a las redes móviles de banda estrecha.

4.3.5.5. XEP0138: Compresión de Streams

Una de las principales razones por las que XML se critica en ocasiones es por lo poco eficiente que es este formato en el encapsulamiento de los datos, ya que al ser un formato basado en texto, los mensajes bastante espacio debido, fundamentalmente, a las etiquetas de texto que se emplean para definir la estructura de la información.

Por eso, es conveniente emplear mecanismos de compresión como alternativa a los mecanismos propuestos por TLS76 que especifica el Core del estándar XMPP.

Con la aparición del XEP-013877 se proporcionó a XMMP de un marco extensible para la compresión de streams XML y se definió un registro78 para albergar métodos de compresión. Sin embargo, el XEP-0138 sólo ha registrado los métodos de compresión ZLIB79 y LZW80. Otro método de compresión es el Efficient XML Interchange (EXI81), una tecnología producida por el World Wide Web Consortium (W3C).

EXI es una representación muy compacta de XML que está pensada para optimizar el rendimiento a la vez que el aprovechamiento de los recursos computacionales. El formato EXI resulta un método de compresión alternativo al cifrado en TLS muy efectivo, que puede contribuir a reducir ostensiblemente el tamaño de los mensajes, y por ende, a optimizar el uso del ancho de banda disponible.

76 , RFC 4346 77 Stream Compression 78 Ver http://www.xmpp.org/registrar/compress.html 79 Ver RFC 1950: ZLIB Compressed Data Format Specification, http://tools.ietf.org/html/rfc1950 80 El método de compression LZW (DCLZ) está documentado en el estándar ECMA-151 (Adaptive Coding with Embedded Dictionary - DLCZ Algorithm) 81 Efficient XML Interchange (EXI) Format, http://www.w3.org/TR/exi.

160 4. APLICACIONES DEL PROTOCOLO XMPP

4.3.5.6. XEP0116: Cifrado de Sesiones

El Aseguramiento de Información y la Seguridad son requisitos fundamentales en cualquier sistema de comunicaciones militares. Dado que XMPP se diseñó para establecer sesiones seguras entre servidores, XMPP no se diseñó con el objetivo de ofrecer seguridad y cifrado extremo-a-extremo.

Este cifrado en las comunicaciones de los clientes con los servidores elimina cualquier vulnerabilidad que se pudiera producir de un acceso del servidor al tráfico de mensajes que por el mismo pasan, mediante el cifrado de los mensajes de modo que sólo los pueda descifrar el destinatario. Así, el RFC 392382 y el XEP-0116 establecen estándares en este sentido.

Sin lugar a dudas, para que el XMPP pueda ser adoptado como protocolo de comunicaciones en un Programa de Armamento y Material para la Defensa, tiene que demostrar que dispone de métodos efectivos de seguridad en las comunicaciones. El XEP-0116, si bien está en estado “deferred” (“diferido”), después de haber pasado por el estado de “experimental”, demuestra que es posible extender el protocolo para emplear mecanismos adecuados de seguridad y cifra. Por su parte, los mecanismos TLS y los definidos en el RFC 3923, son lo suficientemente robustos como para avalar el uso de XMPP en tales entornos militares.

4.3.5.7. XEP0009: JabberRPC

Las llamadas a procedimiento remoto (RPC) son métodos muy útiles en la combinación de funcionalidades de múltiples aplicaciones y bases de datos. Se usan de manera extensiva para crear interoperabilidad entre plataformas y lenguajes diferentes.

XML-RPC83 es un protocolo de llamada a procedimiento remoto que usa XML para codificar los datos y HTTP como protocolo de transmisión de mensajes (St.Laurent, Johnston, & Dumbill, 2001). Es un protocolo muy simple ya que sólo define unos

82 End-to-End Signing and Object for the XMPP 83 Fue creado por Dave Winer, de la empresa UserLand Software, en asociación con Microsoft en el año 1998. Al considerar Microsoft que era muy simple decidió añadirle funcionalidades, tras las cuales, después de varias etapas de desarrollo, el estándar dejó de ser sencillo y se convirtió en lo que es actualmente se conoce como SOAP.

161 ESTUDIO DEL PROTOCOLO XMPP DE MENSAJERÍA INSTANTÁNEA

cuantos tipos de datos y comandos útiles, además de una descripción completa de corta extensión. La simplicidad del XML-RPC está en contraste con la mayoría de protocolos RPC que tienen una documentación extensa y requieren considerable soporte de software para su uso.

El XEP-0009 define un método estándar para implementar XML-RPC sobre redes XMPP.

Dado el amplio número de sistemas stand-alone que las fuerzas armadas despliegan como soporte de cualquier operación militar, XMPP puede ser una forma de comunicar esos sistemas entre sí, contribuyendo al concepto de interoperabilidad que subyace en la filosofía NEC.

4.3.5.8. XEP0072: SOAP sobre XMPP

El protocolo SOAP84 es un es un protocolo estándar que define cómo dos objetos en diferentes procesos pueden comunicarse por medio de intercambio de datos XML. SOAP fue creado por Microsoft, IBM y otros y está actualmente bajo el auspicio de la W3C. Es uno de los protocolos utilizados en los servicios Web.

Del mismo modo que con XML-RPC sobre XMPP, SOAP puede implementarse sobre XMPP. El XEP-0072 y el XEP-0009 permiten dos métodos alternativos para la interoperabilidad de los sistemas utilizando mensajería XML sobre redes XMPP.

Adicionalmente, cabe decir que, dado que XMPP soporta comunicaciones tanto síncronas como asíncronas, ofrece un protocolo de transporte más potente que HTTP y SMTP a los paquetes XML-RPC y SOAP.

4.3.5.9. XEP0171: Traducción de Idiomas

Hasta la creación de esta extensión al protocolo XMPP no existía ningún estándar para describir las traducciones de idiomas sobre un protocolo de chat. Mientras que siempre han existido numerosos servicios y aplicaciones que automatizan la traducción

84 Simple Object Access Protocol

162 4. APLICACIONES DEL PROTOCOLO XMPP

de textos, no existía ningún protocolo estándar para solicitar una traducción y expresar los detalles de la misma sobre XMPP.

Se puede emplear traducción cliente (traducción realizada en el lado cliente, previa al envío de u mensaje) o traducción “al vuelo”85 en el que la traducción se realiza de forma transparente a los usuarios.

Los Servicios de Descubrimiento XMPP permiten a los clientes localizar qué entidades de su red XMPP disponen de esta capacidad de traducción. Las entidades pueden solicitarse traducciones unas a otras. Las entidades remotas pueden ser automáticas (bots de traducción) o humanas (un traductor profesional).

Este tipo de funcionalidades de traducción resultan de interés capital en entornos de operaciones multinacionales, en las que una coalición de ejércitos y organizaciones civiles deben colaborar.

4.3.6. Referencias

Del análisis de fuentes abiertas86 realizado para la realización del presente estudio, cabe destacar el alto número de referencias disponibles acerca de qué entidades vinculadas a la defensa y seguridad están utilizando o han utilizado XMPP en sus proyectos y/o programas.

A continuación, se muestran algunos de los proyectos y/o programas más importantes en los que XMPP tiene un papel importante.

4.3.6.1. Interconexión de cuerpos de seguridad y emergencias: CAPWin

Hechos como los atentados terroristas del 11 de Septiembre de 2001 pusieron en evidencia la falta de coordinación de los servicios de emergencia (policía, bomberos, servicios de evacuación y rescate de heridos). Un año después, en Washington D.C., se

85 On-the-fly translation 86 Documentos no clasificados extraidos fundamentalmente de Internet

163 ESTUDIO DEL PROTOCOLO XMPP DE MENSAJERÍA INSTANTÁNEA

puso en marcha un proyecto denominado Capital Wireless Integrated Network (CapWIN87) que contó con un presupuesto inicial de 20 millones de dólares.

Ilustración 34. Detalle del interfaz de usuario de CapWIN La red CapWIN88 se pensó como un sistema de coordinación basado en MI con XMPP que permitiera, a las decenas de agencias de seguridad y emergencias (más de 40 entidades de seguridad y emergencias entre policías, bomberos, asistencia sanitaria, y otros cuerpos), hacer tres cosas, fundamentalmente: comunicarse entre sí a través de una red segura de MI; realizar búsquedas en bases de datos de todo tipo; y permitir una mejor coordinación entre las diferentes agencias y efectivos sobre el terreno que atiendan una emergencia.

Por ejemplo, un oficial de policía que acaba de llegar a la escena de una emergencia, podría emplear la MI para obtener un informe resumen de la situación, así como enviar

87 En realidad, el proyecto CapWIN comenzó a diseñarse mucho antes del 11 de Septiembre, fue en 1999 cuando un hombre que amenazaba con saltar al río Potomac desde el puente de Woodrow Wilson (que conecta los estados de Virginia y Maryland) provocó un colapso de tráfico que duró 7 horas. El hecho de que el colapso fuese de tal magnitud tuvo que ver con que los oficiales de policía de ambos lados del puente no podían siquiera hablar directamente ya que utilizaban redes de radio independientes e incompatibles. Eso, unido a la compleja división administrativa de Washington DC, con 3 jurisdicciones y además sede del gobierno federal, hizo que algunas autoridades se plantearan que había que hacer algo para que situaciones como esta que hemos comentado no volvieran a ocurrir.

88 Ver http://www.capwin.org/index.cfm?fuseaction=WhatIs

164 4. APLICACIONES DEL PROTOCOLO XMPP

información exacta en tiempo real al centro de control de emergencias a la vez que otros efectivos procesan dicha información, realizando las pertinentes consultas en las bases de datos de cada una de las agencias coordinadas.

En la actualidad, se está trabajando para incorporar otros estándares al sistema, que permitan el intercambio de datos estructurados:

• National Information Exchange Model (NIEM)

• Global Justice XML Data Model (GJXDM)

• IEEE 1512 en lo que respecta a los Transportation Incident Management Message Sets

• Common Alerting Protocol (CAP) de la Organization for the Advancement of Structured Information Standards (OASIS), así como Emergency Data Exchange Language (EDXL)

• Varios protocolos de sensores autónomos como los que despliegan habitualmente las entidades y cuerpos de seguridad nacional, policías, bomberos y emergencias

• Otros modelos de datos y diccionarios de datos que sean interesantes

4.3.6.2. Interoperabilidad de Simuladores

Distributed Interactive Simulation (DIS) es un conjunto de protocolos IEEE89 diseñados para la interoperabilidad en tiempo real entre plataformas de simulación civil/militar y juegos serios de guerra90.

Estos estándares se utilizan mucho en simulación militar. Recientemente, se ha trabajado en la creación de una representación XML den los paquetes de datos DIS. Expresar los datos DIS como XML tiene, entre otras, las ventajas de simplificar el acceso a través de interfaces compatibles XML así como permitir la consulta,

89 Institute of Electrical and Electronics Engineers 90 Proviene del término “Serious Games”, que a su vez acuñó la “Serious Games Initiative”, que fue una iniciativa del Woodrow Wilson International Center for Scholars, tomada en 2002 para fomentar la creación de videojuegos con propósitos educativos y de entrenamiento. Hoy en día es el término con el que se refieren los juegos de guerra implementados sobre motores de videojuegos, y con la apariencia y la sencillez de manejo de los videojuegos. Estos “juegos serios” pueden ser o no de simulación.

165 ESTUDIO DEL PROTOCOLO XMPP DE MENSAJERÍA INSTANTÁNEA

transformación, almacenamiento y publicación web de los datos (McGregor, Brutzman, Armold, & C. Blais, 2006).

Ilustración 35. Ejemplo de un mensaje DIS-XML Los paquetes de datos DIS, generalmente se transmiten por multicasting en redes de área local (LAN). A medida que Internet, mediante el empleo de protocolos punto a punto como TCP91 y UDP92 se ha convertido en el medio de interconexión más extendido, resulta una obligación conectar los simuladores entre sí a través de Internet, donde la mayoría de routers no enrutan paquetes .

La conversión de DIS-XML no se ha completado aún, pero su comunidad de desarrolladores y usuarios está muy interesada en demostrar el potencial de XMPP como un protocolo de transporte de XML más versátil que TCP y HTTP.

91 Transmission Control Protocol 92 User Datagram Protocol

166 4. APLICACIONES DEL PROTOCOLO XMPP

La utilización de DIS-XML en lugar del DIS nativo, reduce el rendimiento de la CPU y consume más ancho de banda,, pero sin embargo, DIS-XML ha demostrado ser tremendamente útil en al menos dos casos: el simulador del Autonomous Underwater Workbench y el demostrador L-3 que se mostró al público en la feria más importante del sector IITSEC93 2005 (McGregor, Brutzman, Armold, & C. Blais, 2006).

El principal beneficio de DIS-XML es lograr una capacidad similar al multicasting a escala Internet, de forma amigable con los firewalls.

El trabajo de innovación que se está llevando a cabo continuamente en el área de Efficient XML Interchange (EXI) para lograr un formato de XML serializado que mejore el aprovechamiento de los recursos de la red, facilitará que DIS-XML extienda su uso a muchas más aplicaciones en el terreno de la interoperabilidad de simuladores.

4.3.6.3. Otros ejemplos

- USJFCOM J9 CDCIE Project: sistema de chat de texto en múltiples dominios y con traducción automática

- TRiM/Coalition Chat Line: Chat de texto con traducción multilingüe

- EUCOM’s Multinational Collaboration Environment (MNCE)

- Naval Research Lab’s Multi-Level Chat Server. Servidor de Chat para sistema operativo STOP 6.194 que implementa XMPP y tiene la seguridad como leivmotiv, permitiendo establecer políticas de seguridad muy estrictas por niveles.

- Iniciativa ForceNET de la US Navy. ForceNET es el framework NEC de construcción de Sistemas de Combate Naval creado por la US Navy para afrontar los retos del siglo XXI. Como dice una de las definiciones que de

93 Interservice/Industry Training, Simulation and Education Conference. Se trata del mayor congreso y feria comercial del sector de la simulación en el mundo. Se celebra una vez al año en Orlando (Florida, USA), el mayor polo de desarrollo de las tecnologías de la simulación del mundo. 94 STOP es un sistema operativo para sistemas empotrados de BAE SYSTEMS que implementa seguridad multinivel y cumple EAL 5+. Lo usan toda la gama de dispositivos XTS (BAE SYSTEMS, 2008)

167 ESTUDIO DEL PROTOCOLO XMPP DE MENSAJERÍA INSTANTÁNEA

ella aparecen en su sitio web95, permite integrar sistemas C2, sensores, redes, plataformas y sistemas de armas como una sola fuerza de combate distribuida, capaz de operar desde las profundidades del océano al espacio exterior, y desde el mar hasta tierra.

- Air Force TBMCS96. Es el motor del sistema conjunto de mando y control (C2) del Centro de Operaciones de la Fuerza Aérea de EE.UU. Integra una serie de sistemas que cubren la planificación, asignación de tareas, recogida de información de inteligencia y ejecución de misiones, en un solo interfaz común.

- Mitre Collaborative Data Objects (CDO) Programa de investigación federal estadounidense que se ocupó de implementar una extensión a XMPP97 para que fuera posible el intercambio de datos estructurados o Collaborative Data Objects mediante un protocolo basado en conversaciones MI. El protocolo define un método de sincronización de los objetos CDO (Winkowski & Krutsch, 2006) que se convirtió en una extensión experimental del protocolo XMPP (Bryson, Winkowski, Krutsch, Smith, Jacobsen, & Huss, 2007)

- La Comunidad de Inteligencia (IC) de muchas de las principales potencias han experimentado con XMPP para su empleo en comunicaciones seguras hombre-hombre, hombre máquina y máquina-máquina basadas en MI (chats tácticos, redes de sensores, manejo remoto de sistemas, etc.) Por su parte, los norteamericanos comenzaron hace años el desarrollo de XMPP sobre JWICS98. La CIA emplea XMPP para comunicación de texto entre ciertos dominios (Thornton & Marenic, 2007).

- Dentro de algunos sistemas del Programa de modernización del Ejército de los Estados Unidos “Future Combat Systems”

95 Ver http://forcenet.navy.mil/fn-definition.htm 96 Theater Battle Management Core Systems (TBMCS) 97 Ver XEP-0204: Collaborative Data Objects

98 Joint Worldwide Intelligence Communications System. Es una versión aislada y privada de Internet para la transmisión por TCP/IP de información de alto secreto entre el DoS y el DoD

168 4. APLICACIONES DEL PROTOCOLO XMPP

- Dentro del Programa MITRE, en algunos sistemas norteamericanos y de la OTAN del proyecto Multi-Sensor Aerospace-Ground Joint Interoperable ISR Coalition (MAJIIC99)

- Horizontal Fusion100. Sistemas NEC para la fusión de la información táctica y de sensores ISR.

- US Department of Homeland Security

- Proyecto “Morning Calm” del Centro de Operaciones de Inteligencia Conjunto estadounidense (Joint Intelligence Operations Center), que se probó en la península de Korea y posteriormente fue adaptado a las necesidades de la II Guerra del Golfo, en la que existía una amplia necesidad de incrementar el soporte de inteligencia en red a las unidades de combate, para combatir en mejores condiciones a la insurgencia iraquí.

- DISA CMO101 comenzó en 2003 a desplegar XMPP sobre la red SIPRnet102

99 Ver detalles del proyectoMAJIIC en http://www.nato.int/docu/update/2007/pdf/majic.pdf 100 Horizontal Fusion es el programa del US DoD equivalente al NNEC de la OTAN 101 Collaboration Management Office es una iniciativa creada por la Agencia de Sistemas de Información para la Defensa de los EE.UU. (DISA, en inglés) para promover el uso y la implementación de herramientas de trabajo colaborativo en red. 102 Secret Router Network. Red privada para la transmisión de información reservada y secreta entre las entidades del Departamento de Defensa y Departamento de Estado estadounidenses.

169 ESTUDIO DEL PROTOCOLO XMPP DE MENSAJERÍA INSTANTÁNEA

170 5. CONCLUSIONES Y TRABAJO FUTURO

5. COCLUSIOES Y TRABAJO FUTURO

El estudio realizado en este Proyecto Fin de Carrera presenta el protocolo XMPP como una solución viable y recomendable para cubrir las necesidades de mensajería instantánea, chat, monitorización e interoperabilidad de sistemas en red, tanto en el terreno de las aplicaciones civiles como las militares, si bien está siendo en este último ámbito donde está encontrando una mayor aplicación, más allá de la propia mensajería instantánea, para el que fue inicialmente diseñado.

Sobre su uso militar, cabe destacar una serie de hechos.

En primer lugar, el protocolo XMPP representa una solución efectiva para implementar chats y mensajería instantánea táctica, así como un protocolo de transporte de datos XML que puede ser empleado en la mejora de los Sistemas de Mando y Control, Inteligencia, Vigilancia y Reconocimiento (C2ISR)

La miríada de servidores y clientes existentes, ya sean de software abierto o propietario, son una muestra inconfundible de la madurez de este protocolo.

Más interesante, sin embargo, son los ejemplos de los clientes XMPP que se han desarrollado para uso estrictamente militar, proporcionando no solo las características básicas del protocolo, sino que han desarrollado algunas de las extensiones del mismo o modificaciones sobre las especificaciones de forma que se implementen funcionalidades específicas del dominio militar.

La habilidad de construir tales capacidades específicas sobre un marco abierto y estándar de protocolos y tecnologías es vital para satisfacer las necesidades de los muchos tipos de usuarios (militares), sin comprometer la interoperabilidad entre los diferentes servicios o unidades organizativas que existen en los ejércitos.

Todos los programas, iniciativas militares y proyectos de I+D que se citan en este trabajo, así como los prototipos y productos que fueron desarrollados, probados y puestos en explotación en algún periodo de tiempo y en alguna zona de operaciones determinada, han dejado un legado importante acerca de la procedencia y efectividad de este protocolo en una serie de casos de uso, y además, han sometido a este protocolo a

171 ESTUDIO DEL PROTOCOLO XMPP DE MENSAJERÍA INSTANTÁNEA

situaciones operacionales complejas, siendo probado en situaciones reales de combate, o de labores de inteligencia, en entornos de operaciones donde se dispone de banda ancha o de banda estrecha, a través de medios hostiles para una red IP como lo son las radiocomunicaciones HF y VHF.

Actualmente, existen otros mecanismos de mensajería corta militar, como los definidos en los estándares de la OTAN ACP 127103, ACP 142104 y STANAG 4406105. Pero, dada la capacidad actual de soportar aplicaciones IP que se conectan a través de Radio HF, puede tener mucho que decir un protocolo ligero como XMPP, basado en texto, extensible, con eficiencia de consumo de ancho de banda y que aporta funcionalidades tan interesantes como las definidas en la XEP-0060, XEP-0072 y la XEP-0080.

Dada la tendencia cada vez mayor de adquisición de sistemas militares que se obtienen de sistemas civiles ya existentes106, el empleo del protocolo XMPP en la nueva generación de sistemas C4ISR107 puede ser una alternativa interesante de explorar debido a que: 1) es el estándar de MI aprobado por el DoD estadounidense (véase “4.3.5. Aspectos de interés militar del protocolo XMPP”);

103 El ACP 127 es el estándar más antiguo de mensajería instantánea de texto de la OTAN. Puede funcionar sobre Radio HF. Es tan primitivo que no dispone de mecanismos de detección/corrección de errores en la comunicación, por lo que un error debido al ruido en la transmisión, se traduce en un error en la trasncripción de los mensajes. 104 El ACP 142 “P_Mul – A Protocol for Reliable Multicast Messaging in Constrained Bandwidth and Delayed Acknowledgement (EMCON) Environments” es un standard de la CCEB (Combined Communications-Electronics Board – AU, CA, NZ, US, UK) para multicast y soporte EMCON (Emision Control), específicamente diseñado para interoperar con la STANAG 4406 (anexo E) de la OTAN. 105 La STANAG 4406 emplea el estándar X.400 sobre canales de alto ancho de banda. La comunicación entre MTAs (Message Transfer Agents) hace uso del protocol X.400 P1 operando sobre una pila de protocolos completa, la cual incluye las capas OSI de Sesión y Presentación, e Internet Standard ITOT (ISO Transport over TCP) mapeado a TCP (Internet Transmission Control Protocol) sobre IP. El anexo E de la STANAG 4406 especifica la operación sobre ACP 142. En este caso, las comunicaciones MTA a MTA usan también X.400 P1, pero con una pila simplificada y reducida a mínimos. Las funciones definidas en el anexo E permiten reducer al mínimo la cantidad de datos transmitidos, así como integrar funcionalidad multicast del ACP 142 y EMCON dentro de un MTA de X.400. 106 Son los llamados sistemas militares COTS (Commercial Off the Shelf), donde la expresión podría traducirse como sistemas "comerciales ya hechos" o, para el caso, "ya inventados". 107 Command, Control, Communications, Computers, Intelligence, Surveillance and Reconnaissance. El ejército británico lo denomina C4ISTAR (que equivale a C4ISR más Target Acquisition).

172 5. CONCLUSIONES Y TRABAJO FUTURO

2) el core del protocolo es un estándar IETF(Saint-Andre P. , Extensible Messaging and Presence Protocol: Core, 2004)(Saint-Andre P. , Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence, 2004)(Saint-Andre P. , Mapping the Extensible Messaging and Presence Protocol to Common Presence and Instant Messaging - CPIM, Octubre)(Saint-Andre P. , End-to-End Signing and Object Encryption for the Extensible Messaging and Presence Protocol, 2004) 3) es un protocolo abierto, gratuito, con una comunidad bastante amplia de contribuyentes, entre empresas y desarrolladores individuales, para el que existe suficiente literatura e implementaciones propietarias o libres de librerías para una variedad de plataformas (UNIX-like, Linux, Mac, Windows…) y lenguajes (C, C++, Java, Python, CoCoA, Delphi, etc.) pero que, por su naturaleza de estándar, se puede implementar para muchas otras (sistemas operativos en tiempo real, sistemas empotrados, etc.) 4) está basado en XML y es extensible; su comunidad de desarrollo no para de proponer a la XSF nuevas extensiones; 5) su mensajería instantánea se federa con plataformas de Im líderes de mercado, públicas o privadas, como, por ejemplo, Google o IBM Lotus Sametime; 6) facilita a través de JINGLE la transición barata a VoIP de aplicaciones heredadas; 7) se ha empleado con éxito en diversos ejercicios de interoperabilidad JWID108 2005 y 2007, así como Trident Warrior109 2006 por parte de la Marina de los Estados Unidos;

108 Los ejercicios Joint Warrior Interoperability Demonstration (JWID) son demostraciones conjuntas entre la industria y las fuerzas armadas y agencias de seguridad aliadas, organizadas por la OTAN, acerca de las tecnologías C4ISR así como las soluciones conjuntas/combinadas de interoperabilidad. Se cofinancian entre la industria y el ejército y sus resultados se presentan a toda la comunidad de la defensa. A nivel NATO, existen iniciativas similares. 109 Los Trident Warrior consisten en una serie de ejercicios navales diseñados para explorar y poner a prueba capacidades de C2, así como Tacticas, Technicas, y Procedimientos (TTPs), para optimizar las operaciones de guerra naval. Los organiza el DoD norteamericano aunque invitan a otros países aliados a los diferentes ejercicios.

173 ESTUDIO DEL PROTOCOLO XMPP DE MENSAJERÍA INSTANTÁNEA

8) tiene un interés especial para emplearlo como sistema de mensajería instantánea militar:

- con redes IP sobre infraestructura de redes de comunicaciones de banda ancha (xDSL, FTTx, HFC, LMDS, WiMAX, Satélite, WiFi, TDT, UMTS) o estrecha (Radio HF, GSM, etc.)

- como soporte de comunicaciones bridge-to-bridge

- como soporte de la Logística

- en Planificación de Misiones

- como enlace de comunicaciones y vehículo de la sincronización de los cambios sobre la COP en Sistemas C2

- como bus de comunicaciones para Redes de Sensores ISR

- Distributed Interactive Simulation (transporte de paquetes DIS-XML)

- Remote Biomonitoring (Telemedicina Militar, Programa COMFUT110)

- Operational Medical Support – Asistencia Médica Telemática en situaciones de combate

Por tanto, cabe esperar que, en los próximos años, debido al empuje de iniciativas como la NNEC impulsada por la NATO C3 Agency, se conozca y se difunda mucho más el protocolo XMPP entre la comunidad militar de I+D y en concreto entre la comunidad de ingenieros de sistemas de la industria militar que funciona, hoy día, a remolque de la industria civil, debido a la inexistencia de economías de escala y las barreras en la exportación de tecnología militar.

110 El programa COMFUT (Combatiente del Futuro) es un programa de adquisición de lo que será el equipamiento del futuro combatiente del Ejército de Tierra español, dirigido por la Dirección General de Armamento y Material (DGAM) del Ministerio de Defensa español, en tres fases cuyo objetivo es la modernización general del Ejército Español y liderado por EADS CASA y que cuenta con las empresas Indra, Fedur, GMV, Iturri y Amopack como subcontratistas.

174 6. BIBLIOGRAFÍA

6. BIBLIOGRAFÍA

Alberts, D., & Hayes, R. (2003). Power to the Edge. Washington D.C.: CCRP Publication Services.

Armold, A. D. (2006). XML TACTICAL CHAT: extensible messaging and presence protocol for command and control applications. MONTEREY, CALIFORNIA: NAVAL POSTGRADUATE SCHOOL.

Arriola, A., Brebels, S., Valderas, D., Blasco, J. M., Hernández, J. F., & Montón, E. (2008). A Wireless Sensor Network Infrastructure for Personal Monitoring. International Workshop on Wearable Micro and anosystems for Personalised Health. Valencia: pHEALTH.

BAE SYSTEMS. (2008). STOP Version 7 Platform for Secure CrossDomain Application Development. Obtenido de BAE Systems Information Technology: http://www.baesystems.com/BAEProd/groups/public/documents/bae_publication/bae_p df_csit_xts_stop7.pdf

Baltes, B., Dickson, M., Sherman, M., Bauer, C., & LaGanke, J. (2002). Computer- mediated communication and group decision making: A meta-analysis. Organizational Behavior and Human Decision Processes , 87, 156-179.

Batiste, J., & Daniels, P. (2005). The fight for Samarra: Full-spectrum operations. Military Review (85), 13-21.

Boiney, L. (2005). Team decision making in time-sensitive environments. Proceedings of the 10th International Command and Control Research and Technology Symposium: The Future of C2, (pág. 175). McLean, VA.

Bønes, E., Hasvold, P., Henriksen, E., & Strandenæs, T. (2006). Risk analysis of information security in a mobile instant messaging and presence system for healthcare. International Journal of Medical Informatics .

175 ESTUDIO DEL PROTOCOLO XMPP DE MENSAJERÍA INSTANTÁNEA

Bordia, P. (1997). Face-to-face versus computer-mediated communication: A synthesis of. The Journal of Business Communication (34), 99-120.

Bowers, C., Jentsch, F., Salas, E., & Braun, C. (1998). Studying communication patterns among aircrews: Implications for team training needs assessment. Human Factors (40), 672-679.

Bryson, D., Winkowski, D., Krutsch, M., Smith, C., Jacobsen, J., & Huss, M. (17 de Enero de 2007). XEP0204: Collaborative Data Objects. Obtenido de http://www.xmpp.org/extensions/xep-0204.html

Drucker, P. F. (1969). The Age of Discontinuity: Guidelines to Our Changing Society. N.Y.: Harper & Row.

Ferrández Aragües, Tomás. (2007). La Gestión de la Información como área tecnológica de interés crítico: necesidades de las fuerzas armadas. En TECOLOGIA Y FUERZAS ARMADAS. Madrid: Centro Superior de Estudios de la Defensa Nacional CESEDEN, Fundación Sagardoy, Cátedra "Marqués de Santa Cruz de Marcenado".

Funke, G. J., Galster, S. M., Nelson, W. T., & Dukes, A. W. (2006). Instant Messaging and Team Performance in a Simulated Command. Proceedings of the Command and Control Research and Technical Symposium. Wright-Patterson AFB OH.

Gartner. (2007). Gartner Predicts Instant Messaging Will Be De Facto Tool for Voice, Video and Text Chat by The End of 2011. 2007 PRESS RELEASES. Obtenido de http://www.gartner.com/it/page.jsp?id=507731

Hart & Staveland, L. (1988). Development of a multidimensional workload. En H. &. Meshkati, Human mental workload (págs. 139-183). Amsterdam: Elsevier Science.

Hart, S., & Staveland, L. (1988). Development of a multidimensional workloadscale: Results of empirical and theo retical research. En P. Hancock, & N. Meshkati, Human mental workload (págs. 139-183). Amsterdam: Elsevier Science.

176 6. BIBLIOGRAFÍA

Hildebrand, J., & Saint-Andre, P. (30 de Enero de 2008). XEP0080: User Location. Recuperado el 27 de Agosto de 2008, de XMPP Standards Foundation: http://www.xmpp.org/extensions/xep-0080.html

Hofte, H., Mulder, I., Poot, H., & Langley, D. (2003). IM mobile, where R U. Proceedings of the 2003 European Conference on Computer. Helsinki, : ECSCW .

Isaacs, E., Walendowski, A., Whittaker, S., Schiano, D., & Kamm, C. (2002). The character, functions and styles of instant. Proceedings of the 2002 ACM Conference on Computer Supported Cooperative Work. New Orleans, Louisiana, USA: ACM .

Karppanen, J. (2005). Propietary Instant Messaging and Presence Protocols. Seminar on Instant Messaging and Presence Architectures in the Internet. Helsinki: University of Helsinki.

Kaufman, A. (February de 2005). Caugh in the network: How the doctrine of network-centric warfare allows doctrine to dictate military strategy. Armed Forces Journal , 20-22.

Labidi, W., Susini, J.-F., Setton, Paradinas, P., & Setton, M. (2007). XMPP based Health Care Integrated Ambient Systems Middleware. Proceedings of the International Conference on Ambient Intelligence Developments (AmI.d’07). Sophia-Antipolis, France: Springer.

Liuhto, L., & Mäntysaari, V. (2005). Extensible Messaging and Presence Protocol (XMPP). Seminar on Instant Messaging and Presence Architectures in the Internet. Helsinki: University of Helsinki, Department of Computer Science.

McGrath, J. (1984). Groups: Interaction and performance. Englewood Cliffs, NJ: Prentice-Hall.

McGregor, D., Brutzman, D., Armold, A., & C. Blais, C. (2006). DIS-XML: Moving DIS to Open Data Exchange Standards. SISO, 2006 Spring Simulation Interoperability Workshop. Huntsville, Alabama.

177 ESTUDIO DEL PROTOCOLO XMPP DE MENSAJERÍA INSTANTÁNEA

Millard, P., Saint-Andre, P., & Meijer, R. (5 de Marzo de 2008). XEP0060: Publish Subscribe. Recuperado el 27 de Agosto de 2008, de XMPP Standards Foundation: http://www.xmpp.org/extensions/xep-0060.html

Nardi, B., Whittaker, S., & Bradner, E. (2000). Interaction and outeraction: instant messaging in action. Proceedings of the 2000 ACM Conference on Computer. Philadelphia, Pennsylvania, USA: ACM.

Nie, P. (2006). An Open Standard for Instant Messaging: eXtensible Messaging and Presence Protocol. Seminar on Internetworking. Helsinki: Helsinki University of Technology.

Ojaluoma, J. (2005). XMPP Extensions. Seminar on Instant Messaging and Presence Architectures in the Internet. Helsinki: University of Helsinki.

OMG. (1 de Enero de 2007). Data Distribution Service for Realtime Systems, Version 1.2. Obtenido de Catalog of OMG Data Distribution Service [DDS] Specifications: http://www.omg.org/technology/documents/formal/data_distribution.htm

Saint-Andre, P. (Octubre de 2004). EndtoEnd Signing and Object Encryption for the Extensible Messaging and Presence Protocol. Obtenido de : 3923: http://www.ietf.org/rfc/rfc3923.txt?number=3923

Saint-Andre, P. (Octubre de 2004). Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence. Obtenido de Request for Comments: 3921: http://www.ietf.org/rfc/rfc3921.txt?number=3921

Saint-Andre, P. (Octubre de 2004). Extensible Messaging and Presence Protocol: Core. Obtenido de Request for Comments: 3920: http://www.ietf.org/rfc/rfc3920.txt?number=3920

Saint-Andre, P. (2004 de Octubre). Mapping the Extensible Messaging and Presence Protocol to Common Presence and Instant Messaging CPIM. Obtenido de Request for Comments: 3922: http://www.ietf.org/rfc/rfc3922.txt?number=3922

178 6. BIBLIOGRAFÍA

Saint-Andre, P. (16 de Julio de 2008). XEP0045: MultiUser Chat, 1.24. Recuperado el 27 de Agosto de 2008, de http://www.xmpp.org/extensions/xep- 0045.html

Saint-Andre, P. (Octubre de 2004). XMPP extensions for basic instant messaging and presence . Obtenido de Request for Comments: 3921: http://www.ietf.org/rfc/rfc3921.txt?number=3921

Saint-Andre, P., & Meijer, R. (2005). Streaming XML with Jabber/XMPP. Internet Computing, IEEE , Volume 9, Issue 5, Sept.-Oct. 2005 Page(s): 82 - 89.

St.Laurent, S., Johnston, J., & Dumbill, E. (2001). Programming Web Services with XMLRPC. O'Reilly.

Taylor, R. (1990). Situational awareness rating technique (SART): The development of a tool for aircrew systems design. En NATO, In Situational Awareness in Aerospace Operations (AGARDCP478) (págs. 3/1 - 3/17). Neuilly Sur Seine, France: NATO.

Thornton, K., & Marenic, T. (2007). Intelligence Dissemination to the Warfighter. Monterey: Naval Postgraduate School.

Vos, H., Hofte, H., & Poot, H. (2004). IM[@Work] adoption of instant messaging in a knowledge worker organisation. Hawaii International Conference on System Sciences. Big Island, Hawaii.

Winkowski, D., & Krutsch, M. C. (2006). Collaborative Data Objects. Obtenido de MITRE Technology Program: http://www.mitre.org/news/events/tech06/briefings/2686.pdf

179 ESTUDIO DEL PROTOCOLO XMPP DE MENSAJERÍA INSTANTÁNEA

180 7. APÉNDICES

7. APÉDICES

Apéndice A. Lista de Extensiones del Protocolo XMPP

Number Name Type Status Date

XEP-0001 XMPP Extension Protocols Procedural Active 2008-01-23

XEP-0002 Jabber Interest Groups Procedural Active 2001-07-09

XEP-0004 Data Forms Standards Final 2007-08-13 Track

XEP-0009 Jabber-RPC Standards Final 2006-02-09 Track

XEP-0012 Last Activity Standards Draft 2007-02-16 Track

XEP-0013 Flexible Offline Message Standards Draft 2005-07-14 Retrieval Track

XEP-0016 Privacy Lists Standards Draft 2007-02-15 Track

XEP-0019 Streamlining the JIGs Procedural Active 2002-03-19

XEP-0020 Feature Negotiation Standards Draft 2006-11-21 Track

XEP-0027 Current Jabber OpenPGP Historical Active 2006-11-29 Usage

XEP-0030 Service Discovery Standards Final 2008-06-06 Track

XEP-0033 Extended Stanza Standards Draft 2004-09-16 Addressing Track

XEP-0045 Multi-User Chat Standards Draft 2008-01-14 Track

XEP-0047 In-Band Bytestreams (IBB) Standards Draft 2006-11-29 Track

XEP-0048 Bookmarks Standards Draft 2007-11-07 Track

XEP-0049 Private XML Storage Historical Active 2004-03-01

XEP-0050 Ad-Hoc Commands Standards Draft 2005-06-30 Track

XEP-0053 XMPP Registrar Function Procedural Active 2006-12-07

XEP-0054 vcard-temp Historical Active 2003-03-26

XEP-0055 Jabber Search Historical Active 2004-03-22

XEP-0059 Result Set Management Standards Draft 2006-09-20 Track

XEP-0060 Publish-Subscribe Standards Draft 2008-03-05 Track

181 ESTUDIO DEL PROTOCOLO XMPP DE MENSAJERÍA INSTANTÁNEA

Number Name Type Status Date

XEP-0065 SOCKS5 Bytestreams Standards Draft 2007-05-21 Track

XEP-0066 Out of Band Data Standards Draft 2006-08-16 Track

XEP-0068 Field Standardization for Informatio Active 2004-07-07 Data Forms nal

XEP-0070 Verifying HTTP Requests Standards Draft 2005-12-14 vía XMPP Track

XEP-0071 XHTML-IM Standards Draft 2007-08-29 Track

XEP-0072 SOAP Over XMPP Standards Draft 2005-12-14 Track

XEP-0076 Malicious Stanzas Humorous Active 2003-04-01

XEP-0077 In-Band Registration Standards Final 2006-01-24 Track

XEP-0079 Advanced Message Standards Draft 2005-11-30 Processing Track

XEP-0080 User Location Standards Draft 2008-01-30 Track

XEP-0082 XMPP Date and Time Informatio Active 2003-05-28 Profiles nal

XEP-0083 Nested Roster Groups Informatio Active 2004-10-11 nal

XEP-0084 User Avatar Standards Draft 2007-11-07 Track

XEP-0085 Chat State Notifications Standards Draft 2006-07-12 Track

XEP-0092 Software Version Standards Draft 2007-02-16 Track

XEP-0095 Stream Initiation Standards Draft 2004-04-13 Track

XEP-0096 File Transfer Standards Draft 2004-04-13 Track

XEP-0100 Gateway Interaction Informatio Active 2005-10-05 nal

XEP-0106 JID Escaping Standards Draft 2007-06-18 Track

XEP-0107 User Mood Standards Draft 2007-06-04 Track

XEP-0108 User Activity Standards Draft 2007-07-11 Track

XEP-0114 Jabber Component Protocol Historical Active 2005-03-03

182 7. APÉNDICES

Number Name Type Status Date

XEP-0115 Entity Capabilities Standards Draft 2008-02-25 Track

XEP-0118 User Tune Standards Draft 2008-01-30 Track

XEP-0122 Data Forms Validation Standards Draft 2004-09-22 Track

XEP-0124 Bidirectional-streams Standards Draft 2007-02-28 Over Synchronous HTTP Track (BOSH)

XEP-0126 Invisibility Informatio Active 2005-08-19 nal

XEP-0127 Common Alerting Protocol Informatio Active 2004-12-09 (CAP) Over XMPP nal

XEP-0128 Service Discovery Informatio Active 2004-10-20 Extensions nal

XEP-0130 Waiting Lists Historical Active 2006-09-13

XEP-0131 Stanza Headers and Standards Draft 2006-07-12 Internet Metadata (SHIM) Track

XEP-0132 Presence Obtained vía Humorous Active 2004-04-01 Kinesthetic Excitation (POKE)

XEP-0133 Service Administration Informatio Active 2005-08-19 nal

XEP-0134 Protocol Design Informatio Active 2004-10-22 Guidelines nal

XEP-0136 Message Archiving Standards Propos 2008-05-19 Track ed

XEP-0137 Publishing SI Requests Standards Draft 2005-08-26 Track

XEP-0138 Stream Compression Standards Draft 2007-09-26 Track

XEP-0141 Data Forms Layout Standards Draft 2005-05-12 Track

XEP-0143 Guidelines for Authors of Procedural Active 2004-12-09 XMPP Extension Protocols

XEP-0144 Roster Item Exchange Standards Draft 2005-08-26 Track

XEP-0145 Annotations Historical Active 2006-03-23

XEP-0146 Remote Controlling Informatio Active 2006-03-23 Clients nal

XEP-0147 XMPP URI Scheme Query Informatio Active 2006-09-13 Components nal

183 ESTUDIO DEL PROTOCOLO XMPP DE MENSAJERÍA INSTANTÁNEA

Number Name Type Status Date

XEP-0148 Instant Messaging Humorous Active 2005-04-01 Intelligence Quotient (IM IQ)

XEP-0149 Time Periods Informatio Active 2006-01-24 nal

XEP-0153 vCard-Based Avatars Historical Active 2006-08-16

XEP-0154 User Profile Standards Experi 2008-04-18 Track mental

XEP-0155 Stanza Session Standards Draft 2008-01-14 Negotiation Track

XEP-0156 Discovering Alternative Standards Draft 2007-06-12 XMPP Connection Methods Track

XEP-0157 Contact Addresses for Informatio Active 2007-01-31 XMPP Services nal

XEP-0158 Robot Challenges Standards Propos 2008-05-12 Track ed

XEP-0159 Spim-Blocking Control Standards Experi 2007-07-11 Track mental

XEP-0160 Best Practices for Informatio Active 2006-01-24 Handling Offline Messages nal

XEP-0161 Abuse Reporting Standards Experi 2008-05-06 Track mental

XEP-0163 Personal Eventing vía Standards Draft 2007-09-26 Pubsub Track

XEP-0165 Best Practices to Informatio Experi 2007-12-13 Discourage JID Mimicking nal mental

XEP-0166 Jingle Standards Propos 2008-06-16 Track ed

XEP-0167 Jingle RTP Sessions Standards Propos 2008-06-09 Track ed

XEP-0168 Resource Application Standards Experi 2008-01-23 Priority Track mental

XEP-0169 Twas The Night Before Humorous Active 2005-12-19 Christmas (Jabber Version)

XEP-0170 Recommended Order of Informatio Active 2007-01-04 Stream Feature nal Negotiation

XEP-0171 Language Translation Standards Draft 2008-05-09 Track

XEP-0172 User Nickname Standards Draft 2006-06-05 Track

184 7. APÉNDICES

Number Name Type Status Date

XEP-0174 Serverless Messaging Standards Draft 2008-03-05 Track

XEP-0175 Best Practices for Use of Informatio Active 2007-11-07 SASL nal

XEP-0176 Jingle ICE-UDP Transport Standards Propos 2008-06-04 Method Track ed

XEP-0177 Jingle Raw UDP Transport Standards Propos 2007-11-27 Method Track ed

XEP-0178 Best Practices for Use of Informatio Active 2007-02-15 SASL EXTERNAL with nal Certificates

XEP-0181 Jingle DTMF Standards Propos 2008-05-30 Track ed

XEP-0182 Application-Specific Procedural Active 2008-03-05 Error Conditions

XEP-0183 Jingle Humorous Active 2006-04-01 Transport Method

XEP-0184 Message Receipts Standards Draft 2007-09-26 Track

XEP-0185 Dialback Key Generation Informatio Active 2007-02-15 and Validation nal

XEP-0186 Invisible Command Standards Experi 2008-05-12 Track mental

XEP-0189 Public Key Publishing Standards Propos 2008-03-05 Track ed

XEP-0190 Best Practice for Closing Informatio Active 2007-01-04 Idle Streams nal

XEP-0191 Simple Communications Standards Draft 2007-02-15 Blocking Track

XEP-0192 Proposed Stream Feature Standards Draft 2007-01-17 Improvements Track

XEP-0193 Proposed Resource Binding Standards Draft 2007-01-17 Improvements Track

XEP-0194 User Chatting Standards Experi 2007-10-02 Track mental

XEP-0195 User Browsing Standards Experi 2007-10-02 Track mental

XEP-0196 User Gaming Standards Experi 2007-10-02 Track mental

XEP-0197 User Viewing Standards Experi 2007-10-02 Track mental

XEP-0198 Stanza Acknowledgements Standards Experi 2007-10-03

185 ESTUDIO DEL PROTOCOLO XMPP DE MENSAJERÍA INSTANTÁNEA

Number Name Type Status Date Track mental

XEP-0199 XMPP Ping Standards Draft 2007-06-12 Track

XEP-0201 Best Practices for Informatio Experi 2008-02-06 Message Threads nal mental

XEP-0202 Entity Time Standards Draft 2007-03-28 Track

XEP-0203 Delayed Delivery Standards Draft 2007-03-29 Track

XEP-0205 Best Practices to Informatio Experi 2007-07-10 Discourage Denial of nal mental Service Attacks

XEP-0206 XMPP Over BOSH Standards Draft 2007-06-04 Track

XEP-0207 XMPP Eventing vía Pubsub Humorous Active 2007-04-01

XEP-0208 Bootstrapping Informatio Experi 2008-01-23 Implementation of Jingle nal mental

XEP-0209 Metacontacts Standards Experi 2007-04-10 Track mental

XEP-0211 XMPP Basic Client 2008 Standards Draft 2007-07-11 Track

XEP-0212 XMPP Basic Server 2008 Standards Draft 2007-07-11 Track

XEP-0213 XMPP Intermediate IM Standards Draft 2007-07-11 Client 2008 Track

XEP-0215 External Service Standards Experi 2007-08-30 Discovery Track mental

XEP-0216 XMPP Intermediate IM Standards Draft 2007-07-11 Server 2008 Track

XEP-0220 Server Dialback Standards Experi 2008-06-18 Track mental

XEP-0221 Data Forms Media Standards Propos 2008-06-18 Track ed

XEP-0222 Best Practices for Informatio Propos 2008-06-20 Persistent Storage of nal ed Public Data vía Publish- Subscribe

XEP-0223 Best Practices for Informatio Propos 2008-06-20 Persistent Storage of nal ed Private Data vía Publish- Subscribe

XEP-0224 Attention Standards Experi 2007-08-08

186 7. APÉNDICES

Number Name Type Status Date Track mental

XEP-0225 Component Connections Standards Experi 2007-08-08 Track mental

XEP-0226 Message Stanza Profiles Informatio Experi 2007-08-08 nal mental

XEP-0227 Portable Import/Export Standards Experi 2007-12-13 Format for XMPP-IM Track mental Servers

XEP-0228 Requirements for Shared Standards Experi 2007-08-22 Editing Track mental

XEP-0229 Stream Compression with Standards Draft 2007-09-26 LZW Track

XEP-0230 Service Discovery Standards Experi 2008-01-30 Notifications Track mental

XEP-0231 Data Element Standards Propos 2008-06-18 Track ed

XEP-0232 Software Information Standards Experi 2008-03-14 Track mental

XEP-0233 Use of Domain-Based Standards Experi 2008-01-30 Service Names in XMPP Track mental SASL Negotiation

XEP-0234 Jingle File Transfer Standards Experi 2008-06-05 Track mental

XEP-0235 Authorization Tokens Standards Experi 2008-03-31 Track mental

XEP-0237 Roster Sequencing Standards Experi 2008-04-21 Track mental

XEP-0238 XMPP Protocol Flows for Informatio Experi 2008-03-31 Inter-Domain Federation nal mental

XEP-0239 Binary XMPP Humorous Active 2008-04-01

XEP-0240 Auto-Discovery of Standards Experi 2008-04-30 JabberIDs Track mental

XEP-0241 Encryption of Archived Standards Experi 2008-04-30 Messages Track mental

XEP-0242 XMPP Client Compliance Standards Experi 2008-06-18 2009 Track mental

XEP-0243 XMPP Server Compliance Standards Experi 2008-06-18 2009 Track mental

XEP-0244 IO Data Standards Experi 2008-06-18 Track mental

XEP-0245 The /me Command Historical Experi 2008-06-18 mental

187 ESTUDIO DEL PROTOCOLO XMPP DE MENSAJERÍA INSTANTÁNEA

Number Name Type Status Date

XEP-0246 End-to-End XML Streams Standards Experi 2008-06-18 Track mental

XEP-0247 Jingle XML Streams Standards Experi 2008-06-18 Track mental

188 7. APÉNDICES

Apéndice B. Lista de Clientes XMPP

Nombre del Autor / Fecha Tipo Versión Coste Licenciamiento Software Creador primera estable (USD) versión A-Talk Robert 2006 Protocolo 1.0.3 Gratuito GPL Edworthy único Adam Iser, September Multiprotocolo 1.2.7 (4 de Gratuito GPL v2 Evan 2001 Julio de Schoenberg 2008) de (Mac OS X) aMSN The aMSN team may-02 Protocolo 0.97.1 Gratuito GPL único AOL Instant AOL may-97 Protocolo 6.5.9.1 Gratuito - Clickwrap Messenger (AIM) único (Windows) Financiado license con 1.0.2 Build publicidad 110 Beta (Pro (Win))

1.3.30.1 (Triton (Win))

4.7.1333 (Mac OS X) 1.5.286(Linux ) Ayttm Colin Leroy abr-03 Multiprotocolo 0.5.0-10 Gratuito GPL and Philip (Linux) Tellis 0.4.6-17 (Windows) BigAnt Instant BigAntSoft 20/02/2008 Protocolo 2.2 $14 Commercial Messenger único license 189 ESTUDIO DEL PROTOCOLO XMPP DE MENSAJERÍA INSTANTÁNEA

Nombre del Autor / Fecha Tipo Versión Coste Licenciamiento Software Creador primera estable (USD) versión BitlBee Wilmer van der 09/08/2002 IRC Gateway, 1.0.3 Gratuito GPL Gaast Multiprotocolo BitWise IM BitWise 17/03/2002 Protocolo 1.7.2 Gratuito Clickwrap Communications único/Encrypte license , LLC d Konstantin 1999 Multiprotocolo 4.21.0 Gratuito GPL Klyagin (September 2, 2005) Mattew D. 1997(?); Dual protocol 0.6.2 Gratuito GPL v2 Smith (up to 2001 ICQv5); Rüdiger Kuhlmann Coccinella Mats Bengtsson 01/12/1999 Protocolo 0.96.8 Gratuito GPL v3 único (April 30, 2008) Cspace Cspace 28/07/2006 Protocolo 1.26 Gratuito GPL único Digsby Steven Shapiro ene-08 Multiprotocolo Beta Gratuito Clickwrap license Ebuddy Paulo Taylor 09/03/2003 Multiprotocolo Beta v5.0.1 Gratuito Clickwrap license emesene Luis Mariano 24/05/2006 Protocolo 1.0 Beta Gratuito GPL Guerra único EQO EQO 06/02/2006 Multiprotocolo 1.4 Gratuito Clickwrap Communications license Exodus Peter Millard 2002 Protocolo 0.10.0.0 Gratuito GPL único Fire Eric Peyton 01/04/1999 Multiprotocolo 1.5.6 Gratuito GPL (February 15th, 2006) Fring Multiprotocolo Gratuito Clickwrap license

190 7. APÉNDICES

Nombre del Autor / Fecha Tipo Versión Coste Licenciamiento Software Creador primera estable (USD) versión Gabtastik Mesa Dynamics, may-08 HTTP 0.2 Gratuito Clickwrap LLC license Gadu-Gadu Łukasz Foltyn Protocolo 7.7 Gratuito Clickwrap único license (?) Yann Le 21/05/2004 Protocolo 0.11.4 Gratuito GPL Boulanger único (December 6, 2007) GCN Jason K. Resch 18/11/2000 Protocolo 2.9.1 Gratuito - Clickwrap único Financiado license con publicidad GOIM Herbert Poul 16/08/2005 Protocolo 1.1.0 (July Gratuito GPL único 2, 2006) Goofey Tim Mackenzie Protocolo 2.08 Gratuito Clickwrap (comienzos) único license Google Talk Google, Inc. 24/08/2005 Dual protocol 1.0.0.104 Gratuito Clickwrap (January 1, license 2007) Gyachi 26/01/2006 Protocolo 1.1.35 June Gratuito GPL único 15, 2008 IBM Lotus IBM, Ubique 1998 Multiprotocolo 8.0; March depends Clickwrap Sametime -- proprietary 2008 license T.120, SIP, XMPP iChat Apple Inc. ago-02 Multiprotocolo 4.0 (601) Gratuito Clickwrap (October 26, license 2007) ICQ Mirabilis nov-96 Protocolo 6.0 Gratuito - Clickwrap (AOL) único Financiado license con publicidad IMVU Will Harvey jul-01 Single- beta Gratuito Clickwrap protocol license

191 ESTUDIO DEL PROTOCOLO XMPP DE MENSAJERÍA INSTANTÁNEA

Nombre del Autor / Fecha Tipo Versión Coste Licenciamiento Software Creador primera estable (USD) versión Instantbird Florian Quèze 2007 Multiprotocolo 0.1.1 Gratuito GPL v2 and Quentin Castier Interaction Chat Auriance ago-06 HTTP 1.0 Gratuito Clickwrap license Jabbin Jabbin Team dic-05 Multiprotocolo none Gratuito GPL v2 Kadu Kadu Team ago-01 Protocolo 0.6.0.1 Gratuito GPL v2 único Konnekt Stamina 2002 Multiprotocolo 0.6.22.137 Gratuito Clickwrap license Kopete Team 03/03/2002 Multiprotocolo 0.50.2 Gratuito GPL Licq Graham Roff 22/06/1998 Multiprotocolo 1.3.2 Gratuito GPL (up to v1.0) Jon Keating Mail.ru Agent Mail.ru may-03 Single- 5.0 (Windows) Gratuito Clickwrap protocol 1.0 (Windows license Mobile) 2.1 (J2ME) MCabber Mikael Berthe 07/06/2005 Single- 0.9.7 (April Gratuito GPL protocol 17, 2008) MECA Messenger ? Multiprotocolo 5.2 Gratuito Clickwrap license meebo Meebo, Inc. 2005 Multiprotocolo alpha v19 Gratuito Clickwrap , Web-based license Meetro Paul Bragiel & 2005 Multiprotocolo 0.96 Beta Gratuito Clickwrap Samuel (Win) license Stauffer 0.53 Beta (Mac OS X) Mercury Danny 2003 Multiprotocolo 1.9 Final Gratuito Clickwrap Messenger (October 20, license 2007)

192 7. APÉNDICES

Nombre del Autor / Fecha Tipo Versión Coste Licenciamiento Software Creador primera estable (USD) versión Microsoft Microsoft ? Protocolo 7.0 Gratuito Clickwrap Messenger for único license Mac MindSpring Earthlink 03/04/2006 Multiprotocolo 1.0 (v53.0) Gratuito Clickwrap license Miranda IM Miranda IM 06/02/2000 Multiprotocolo 0.7.7 Gratuito GPL project MySpaceIM MySpace 09/05/2006 Protocolo 1.0.754.0 Gratuito Clickwrap único (February 7, license 2008) Financiado con publicidad Daniel Reed 05/10/1998 Multiprotocolo 0.11.8.3.1 Gratuito GPL (2007-07-09) Ometheus Ometheus 2007 Multiprotocolo alpha v0.1 n/a Commercial , Web-based license OpenWengo 2004 Multiprotocolo 2.1.2 Gratuito GPL Paltalk Jason Katz 1998 Multiprotocolo 9.0 Gratuito Clickwrap license Pandion Dries 28/06/2004 Protocolo 2.5 (2006- Gratuito Clickwrap Staelens, único 01-07) license Sebastiaan Deckers Pidgin (formerly Mark Spencer nov-98 Multiprotocolo 2.4.3 (July Gratuito GPL Gaim) 1, 2008) pork Ryan McCabe 06/12/2006 AIM, IRC 0.99.8.1 Gratuito GPL v2 Gateway Proteus Justin Wood, nov-01 Multiprotocolo 4.20 (June Gratuito GPL et al. 08, 2008) Psi Justin 2001 Protocolo 0.11 Gratuito GPL Karneges único (October 15, 2007)

193 ESTUDIO DEL PROTOCOLO XMPP DE MENSAJERÍA INSTANTÁNEA

Nombre del Autor / Fecha Tipo Versión Coste Licenciamiento Software Creador primera estable (USD) versión psyced psyced.org 1997 IRC+XMPP+PSYC 0.99 Gratuito GPL Project Gateway, Multiprotocolo QIP Ilgam 2004 Single- 8060 Gratuito Clickwrap Zyulkorneev protocol (Windows) license 2000 () 1040 (Symbian S60 and UIQ3) QIP infium Ilgam 2007 Multiprotocolo 9008 Gratuito Clickwrap Zyulkorneev license Qnext Qnext Corp. 28/06/2004 Multiprotocolo 3.0.1.36 Gratuito Clickwrap (Beta)(March license 1, 2007) Financiado con publicidad RealTimeQuery realtimequery. 2005-2007 Protocolo v3.0 - 2007 $99.95 Clickwrap com único license SIM SIM project ? Multiprotocolo 0.9.4.3 Gratuito GPL (March 5, 2007)

194 7. APÉNDICES

Nombre del Autor / Fecha Tipo Versión Coste Licenciamiento Software Creador primera estable (USD) versión Niklas 2003 Protocolo 3.8.0.139 Gratuito Clickwrap Zennström and único (Windows, license Janus Friis / June 4, 2008) eBay 2.7.0.330 (Mac OS X, May 14, 2008)

2.0.0.72 (Linux x86, March 27, 2008)

2.2.0.37 (Windows Mobile, May 9, 2008) Solixa www.solixa.com ? Single- Template:Late Gratuito GPL protocol st stable release/Solix a talk Kipp Hickman 1982 Protocolo 1.7 (BSD Gratuito BSD único version) Tencent QQ Tencent feb-99 Protocolo 2008 贺 岁版 Gratuito Clickwrap único license Financiado con publicidad Financiado por los SVA Trillian Cerulean 01/07/2000 Multiprotocolo 3.1.10.0 Gratuito Clickwrap Studios (May 20, license 2008)

195 ESTUDIO DEL PROTOCOLO XMPP DE MENSAJERÍA INSTANTÁNEA

Nombre del Autor / Fecha Tipo Versión Coste Licenciamiento Software Creador primera estable (USD) versión Trillian Astra Cerulean ? Multiprotocolo Alpha ? Clickwrap Studios license Trillian Pro Cerulean 10/09/2002 Multiprotocolo 3.1.10.0 $25 Clickwrap Studios (May 20, license 2008) Windows Live Microsoft jul-99 Dual protocol 8.5.1302 Gratuito - Clickwrap Messenger (Windows Financiado license (formerly MSN XP/Vista) con Messenger) publicidad 1.0.6141 (Windows Live for Nokia S60) Windows Microsoft 25/10/2001 Multiprotocolo 5.1.0701 Gratuito Clickwrap Messenger (Windows XP license SP2) Xfire Inc. 2004 Protocolo 1.92 Gratuito - Clickwrap único Financiado license con publicidad Yahoo! Messenger Yahoo! 21/06/1999 Dual protocol 8.1.0.244 Gratuito - Clickwrap (Win) Financiado license 2.5.3 (Mac) con 1.0.4 (Unix) publicidad Project Athena 1987 Protocolo 2.0 Gratuito MIT único

196 7. APÉNDICES

Apéndice C. Clientes MI clasificados por plataforma

Nombre del Windows Mac OS X Linux BSD Unix Windows BlackBerry Otros Software Mobile

A-Talk Sí No No No No No No

Adium No Sí No No No No No

AIM Sí 4.7.1333 1.5.286 No No Sí ? Palm, iPhone aMSN Sí Sí Sí Sí Sí No No Nokia N770, N800, N810

Ayttm Versión Sí Sí Sí Sí ? ? antigua

BigAnt Sí No No No No No No Instant Messenger

BitlBee Sí Sí Sí Sí Sí ? ? AmigaOS

BitWise IM Sí Sí Sí No No No ?

Centericq Sí Sí Sí Sí Sí ? ? climm Sí (2) Sí Sí Sí Sí ? ? AmigaOS

197 ESTUDIO DEL PROTOCOLO XMPP DE MENSAJERÍA INSTANTÁNEA

Nombre del Windows Mac OS X Linux BSD Unix Windows BlackBerry Otros Software Mobile

Coccinella Sí Sí Sí Sí Sí Sí ?

Digsby Sí TBA TBA No No No No

Ebuddy Sí Sí Sí ? Sí Sí Sí iPhone/Sony PSP/Nintendo DS/Palm/Mobile Phones

EQO No No No No No Sí Sí Symbian S40/S60/S80, Java mobile

Exodus Sí No No No No ? ?

Fire No Sí No No No ? ? fring No No No No No No No Symbian OS

Gadu-Gadu Sí No No No No No No

Gajim Sí Sí (1) Sí Sí Sí ? ?

GCN Sí No No No No ? ?

GOIM Sí Sí Sí No No ? ?

Goofey (6) No Sí (7) Sí Sí Sí ? ?

Google Talk Sí Sí Sí Sí Sí Sí ?

198 7. APÉNDICES

Nombre del Windows Mac OS X Linux BSD Unix Windows BlackBerry Otros Software Mobile (Gmail)

Google Talk Sí No No No No ? Sí (standalone)

Gyachi No No Sí No No No No

IBM Lotus Sí Sí Sí Sí Sí Sí Sí Nokia Eseries / Sametime Symbian OS, Sony Ericcson M600/P900/P1i Series iChat No Included No No No No No

ICQ Sí Dropped No No No Sí Sí (3.4.23) imeem Sí Sí No No No ? ?

IMVU Sí No No No No ? ?

Instantbird Sí Sí Sí ? ? ? ?

Interaction Sí Sí Sí Sí Sí ? ? Chat

Jabberwocky No No No No No No No AmigaOS, MorphOS

Kadu No Sí Sí Sí Sí ? ?

199 ESTUDIO DEL PROTOCOLO XMPP DE MENSAJERÍA INSTANTÁNEA

Nombre del Windows Mac OS X Linux BSD Unix Windows BlackBerry Otros Software Mobile

Kopete Aún no Sí (1) Sí Sí Sí ? ?

Licq No No Sí Sí Sí ? ?

Mail.ru Agent Sí No No No No Sí No Java Mobile

MCabber No Sí Sí Sí Sí No ?

MECA Sí No No No No ? ? Messenger meebo Sí Sí Sí Sí Sí ? ? iPhone

Meetro Sí Sí No No No ? ?

Mercury Sí Sí Sí Sí Sí ? ? Messenger (Unof (Unoffi ficia cially, lly, Java) Java)

Microsoft No (3) Sí No (3) No No (3) No No Messenger for (3) Mac

MindSpring Sí No No No No ? ?

Miranda IM Sí No No No No No ?

200 7. APÉNDICES

Nombre del Windows Mac OS X Linux BSD Unix Windows BlackBerry Otros Software Mobile

MySpaceIM Sí No No No No ? ? naim Sí Sí Sí Sí Sí ? ?

Ometheus Sí Sí Sí Sí Sí ? ?

OpenWengo Sí Sí (5) Sí Sí Sí ? ?

Paltalk Sí No No No No ? ?

Pandion Sí No No No No ? ?

Pidgin Sí Sí (1) Sí Sí Sí No No AmigaOS (formerly Gaim) pork No Sí Sí Sí Sí ? ?

Proteus No Sí No No No ? ?

Psi Sí Sí Sí Sí Sí No No psyced Sí Sí Sí Sí Sí ? ?

QIP Sí No No No No Sí No S60 y UIQ3 sobre Symbian OS

QIP infium Sí No No No No No No

Qnext Sí Sí Sí Sí Sí ? ?

201 ESTUDIO DEL PROTOCOLO XMPP DE MENSAJERÍA INSTANTÁNEA

Nombre del Windows Mac OS X Linux BSD Unix Windows BlackBerry Otros Software Mobile

QQ Sí Sí No No No ? ? (beta)

RealTimeQuery Sí No No No No ? ?

SIM Sí Sí Sí Sí Sí ? ?

Skype Sí Sí Sí No No Sí ? talk Sí (4) Sí Sí Sí Sí ? ?

Trillian Sí No No No No ? ?

Trillian Sí Sí Sí Sí Sí ? ? iPhone Astra

Trillian Pro Sí No No No No ? ?

Windows Live Sí No No No No Sí No S60 sobre Symbian OS Messenger

Windows Incluído Sí (8) No No No Sí ? Messenger (XP)

Xfire Sí No No No No No No

Yahoo! Sí Sí No No No ? Sí Messenger

202 7. APÉNDICES

Nombre del Windows Mac OS X Linux BSD Unix Windows BlackBerry Otros Software Mobile

Zephyr Sí Sí Sí Sí Sí ? ?

Nota 1: No se trata de un versión pura para Mac OS X, sino de una aplicación POSIX: necesitará un servidor X y librerías adicionales instaladas, y no tendrá el aspecto de de una aplicación nativa Mac OS X

Nota 2: Requiere un terminal ANSI

Nota 3: MSN Web messenger puede utilizarse con un navegador compatible y una cuenta válida de Microsoft Passport

Nota 4: Numerosos clientes talk/ytalk existen para Win32; otros están disponibles bajo un entorno

Nota 5: Sólo estará disponible en la próxima versión de OpenWengo-NG

Nota 6: Generalmente sólo está disponible el código, no como un binario listo para instalar

Nota 7: El cliente sólo trabajará en Mac OS X dentro de una sesión de terminal (Terminal.app, Xterm, iTerm, o similares)

Nota 8: Se llama Messenger para Mac, actualment en versión 7

203 ESTUDIO DEL PROTOCOLO XMPP DE MENSAJERÍA INSTANTÁNEA

Apéndice D. Clientes MI con capacidad multiprotocolo

Nombre Núm. AIM ICQ Windows Yahoo! IRC XMPP Novell Lotus Gadu- QQ OTR Otros del Proto- Live Messeng Jabber Rendezvous GroupWise Same- Gadu Software colos Messenger er GTalk Messenger time sopor- MSN etc tados Messenger Adium 18 Sí Sí Sí (16) Sí No Sí Sí (10) Sí Sí Sí Sí Sí .Mac, LiveJournal, , MySpace, Yahoo! Japan, Zephyr; NateOn, Skype, Tlen, XFire (Con plugins) AIM 2 Sí Sí No No No No No No No No No With No proxy Ayttm 6 Parcial Parcial Sí Sí Sí Sí No No No No No No No mente mente (6) (6) BitlBee 5 Sí Sí Sí Sí No Sí No No No No No Sí No (20) Carrier 14 Sí Sí Sí (16) Sí Sí Parcial Sí (10) Sí Sí Sí Sí Con SILC, XFire, (antes mente plugi Zephyr, Funpidgin (15) n Blizzard Battle-Net ) (1) Chat (Con plugins) Centericq 6 Parcial Sí Sí Sí Sí Sí No No No Sí No No ? mente (6) climm 2 Parcial Sí No No No Parcial No No No No No Sí No mente mente (12) (13) Digsby 8 Sí Sí Sí Sí No Sí No No No No No No MySpace, Facebook Ebuddy 5 Sí No Sí Sí No Sí No No No No No No MySpace IM

Fire 7 Sí Sí Sí Sí Sí Sí Sí (10) No No No No No No

IBM Lotus 3 Sí (18) No No Sí (18) No Sí (18) No No Sí No No No SIP Sametime iChat 4 Sí No No No No Sí Sí No No No No No .Mac

ICQ 2 Sí Sí No No No No No No No No No No No imeem 4 Sí No Sí Sí No Sí No No No No No No ?

IMVU 6 Sí Sí Sí Sí No Sí No No No No No No IMVU

Instantbi 6 Sí Sí Sí Sí Sí Sí No No No Sí Sí No No rd 204 7. APÉNDICES

Nombre Núm. AIM ICQ Windows Yahoo! IRC XMPP Bonjour Novell Lotus Gadu- QQ OTR Otros del Proto- Live Messeng Jabber Rendezvous GroupWise Same- Gadu Software colos Messenger er GTalk Messenger time sopor- MSN etc tados Messenger Jabberwoc 4 Sí Sí Sí Sí No No No No No No No No No ky Kopete 10 Sí Sí Sí Sí Sí Parcial No Sí Sí Sí No Sí Skype mente (deprecated), (15) WinPopup Licq 3 Sí Sí Sí No No No No No No No No No ?

MECA 5 Sí Sí Sí Sí No Sí No No No No No No No Messenger meebo 5 Sí Sí Sí Sí No Sí No No No No No No Livejournal (via jabber) Meetro 4 Sí Sí Sí Sí No No No No No No No No No

Miranda 16 Sí Sí Sí Sí Sí Sí Sí No Sí Sí Co Sí Skype, Tlen, IM n LAN,5 Chat,5 pl XFire, MySpace IM ug in (2 1) Naim 3 Sí Parcial No No Sí No No No No No No No Lily mente OpenWengo 6 Sí Sí Sí Sí No Sí No No No No No No SIP/SIMPLE

Paltalk 3 Sí Sí No Sí No No No No No No No No

Pidgin 13 Sí Sí Sí (16) Sí Sí Parcial Sí 10 Sí Sí Sí Sí Con MySpace; (antes mente plugi Blizzard Gaim) (15) n Battle-Net Chat, NateOn, (1) SILC, Tlen, XFire, Zephyr (con plugins), Skype (con plugin) (19), Facebook (con plugin) (22) pork 2 Sí No No No Sí No No No No No No No

Proteus 8 Sí Sí Sí Sí No Sí Parcialmente No Sí Sí No With Yahoo! Japan (9) proxy QIP 2 Sí Sí No No No No No No No No No No No

QIP 6 Sí Sí No No Sí Sí No No No No No No Mail.ru Agent, Infium Phoning Qnext 6 Sí Sí Sí Sí Sí No No No No No No No Qnext SIM 6 Sí Sí Sí Sí No Sí No No No No No No LiveJournal

205 ESTUDIO DEL PROTOCOLO XMPP DE MENSAJERÍA INSTANTÁNEA

Nombre Núm. AIM ICQ Windows Yahoo! IRC XMPP Bonjour Novell Lotus Gadu- QQ OTR Otros del Proto- Live Messeng Jabber Rendezvous GroupWise Same- Gadu Software colos Messenger er GTalk Messenger time sopor- MSN etc tados Messenger talk 2 No No No No No No No No No No No No ntalk, ytalk

Trillian 5 Sí Sí Sí Sí Sí No No No No No No No No

Trillian 9 Sí Sí Sí Sí Sí Parcial Sí 10 Sí Sí Con Co No Skype, Astra mente plugi n ASTRA, (14, n (1) pl MySpace, 15) ug XFire (con in plugin) (1 ) Trillian 8 Sí Sí Sí Sí Sí Parcial Sí 10 Sí Sí Con Co Con Skype, XFire Pro mente plugi n plugi (con plugin) (14, n (1) pl n 15) ug (1) in (1 ) Windows 2 No No Sí (16) Sí No No No No No No No No No Live Messenger Windows 3 No No Sí No No No No No No No No No SIP, EIM Messenger Yahoo! 3 No No Sí Sí (17) No No No No Sí No No No No Messenger

Nota 1: Plugin disponible

Nota 2: Plugin disponible

Nota 3: La interoperabilidad con protocolos propietarios puede conseguirse utilizando gateways en el lado del servidor

Nota 4: Plugin disponible; pero requiere instalar y ejecutar Skype

Nota 5: Protocolos LAN y de Chat soportados por miranda incluyen NetSend, WinPopup, Novell Netware NCP, BattleNet, Vypress Chat, Quick Chat, y Walla Chat.

Nota 6: Usa el protocolo AIM TOC2, que tiene menos funcionalidades que OSCARwhich has fewer features than the Oscar protocol the official client uses. An Oscar plugin is available, but is still in early development.

Nota 7: Plugin disponible 206 7. APÉNDICES

Nota 8: Sólo puede acceder a una cuenta ICQ/AOL IM, de tal forma que los usuarios que tienen ICQ y AIM, no pueden usarlos simultáneamente

Nota 9: Mensajería de texto únicamente; no soporta la funcioanlidad de audio de Bonjour/iChat

Nota 10: Probablemente mensajería de texto únicamente, sin soporte de audio Bonjour/iChat

Nota 11: Plugin disponible, pero requiere Skype

Nota 12: Interoperabilidad entre AIM e ICQ

Nota 13: El soporte es opcional. Actualmente sólo dispone de un conjunto de funcionalidades mínimas

Nota 14: Se espera que sea soportado. Actualmente falla al recibir o entregar mensajes, y tiende a bloquearse cuando se recibe una invitación a chat multiusuario o una solicitud de transferencia de fichero

Nota 15: Caracteristica incompleta. Le falta soporte de "service discovery" y de transporte, haciando que las búsquedas de los usuarios, el chat multiusuario o las conexiones a otras redes MI via XMPP sean dificultosas o imposibles

Nota 16: Interoperabilidad de Yahoo! Messenger: puede enviar/recibir a Yahoo! Messenger desde una cuenta de Windows Live Messenger

Nota 17: Windows Live Messenger interoperability: can always send/receive to Windows Live Messenger from a Yahoo! Messenger account.

Nota 18: Mediante IBM Sametime Gateway se puede establecer una comunicación servidor a servidor con otras redes de MI

Nota 19: Mediante el plug-in. Hace falta tener Skype en ejecución. No hay soporte de voz/video

Nota 20: Ver post 2008-02-19 02:39 en http://bugs.bitlbee.org/bitlbee/ticket/115#comment:25

Nota 21: Usando el pug-in MirandaQQ, desarrollado por Stark Wong de Hong Kong

Nota 22: Plug-in Facebook Chat para Pidgin

207 ESTUDIO DEL PROTOCOLO XMPP DE MENSAJERÍA INSTANTÁNEA

Apéndice E. Comparativa de Clientes MI Tabla 1/2

Software Toolki Cifrado Transfe- Proxy- Smileys Juegos Skins Sistema Add-ons Scrip- Logging Mensajería ts o rencia server Gráficos (UTF-8) embeb. Temas de de ting de de Voz SDKs de Plugins terceros mensajes ficheros (1) (2) Adium Cocoa Sí (11) Parcialm Sí Sí No Sí Sí Sí Sí Sí No ente AIM W32 Sí Sí Sí Sí Parcialm Sí Sí Sí ? Sí Sí ente aMSN Tcl/Tk ? Sí http, Sí Sí Parcialm Sí Sí Sí Sí Sí Sí (17) socks5, ente gateway BitlBee n/a No No No Sí No Parcialm Sí No ? Parcialme ? ente nte (18) (18) BitWise IM W32, Sí (7) Sí No ? Sí Sí No No ? Sí Sí GTK2, Carbon Centericq ncurse Parcialm Parcialm No ? No Sí Sí ? Sí Sí No s ente (9) ente climm line Sí Sí N/A Sí No Sí No No Sí Sí N/A based (5,11) Coccinella Tcl/Tk Sí Sí http, Sí Sí Sí Sí Sí ? No Sí Sí socks4, 5 Ebuddy ? Sí No Sí ? No No ? ? ? ? No

EQO n/a Sí No Sí Sí No No No No No No Sí

Exodus W32 No Sí Sí Sí No No Sí No ? ? ?

Fire Cocoa Sí (6) Sí Sí Sí No Sí Sí Sí Sí Sí ?

Gadu-Gadu W32 ? Sí Sí No No ? No Sí No Sí Sí

Gajim GTK2 Sí (9) Sí Sí Sí No Sí No No No Sí No

GCN W32 Sí (4) Sí Sí ? Sí Parcialm No Sí ? ? ? ente GOIM Java/S Sí No Sí Sí No Parcialm Sí No No No No WT ente Google W32 No Sí Parcialm Sí No Sí No Sí No Sí Sí Talk ente Gyachi GTK2 Sí Sí https Sí Sí No No Sí ? No Sí Sí

208 7. APÉNDICES

Software Toolki Cifrado Transfe- Proxy- Smileys Unicode Juegos Skins Sistema Add-ons Scrip- Logging Mensajería ts o rencia server Gráficos (UTF-8) embeb. Temas de de ting de de Voz SDKs de Plugins terceros mensajes ficheros (1) (2) IBM Lotus Sí Sí Sí Sí Sí No Sí Sí Sí Sí Sí Sí Sametime iChat Cocoa Sí Sí Sí Sí No No No Sí Sí Sí Sí

ICQ W32 No Sí Sí Sí Sí Sí Sí Sí Sí Sí Sí imeem ? No Parcialm Sí ? No No No No ? Sí ? ente IMVU ? ? No Sí Sí Parcialm Sí No Sí (13) No Sí (14) No ente Jabberwock No No Parcialm No No No No No No Sí No No y ente (19) Kadu Qt Sí Sí Sí ? No Parcialm Sí Sí ? Sí Sí ente Kopete Qt/KDE Sí Parcialm No Sí Parcialm No Sí Sí Sí ? Sí Parcialmen (9,11) ente ente te (with plugin) Licq Qt Sí (5) Sí https Sí Sí No Sí Sí Sí ? Sí ?

MCabber Curses Sí (11) No No Sí No ? ? No ? Sí No

MECA ? ? Sí Sí Sí Parcialm Sí No No No Sí ? Messenger ente meebo ? ? ? ? ? ? ? ? ? ? ? ? ?

Meetro ? Sí No Sí ? No No No No ? Sí ?

Mercury Swing Sí (4) Sí Sí Sí Sí Sí Sí Sí No Sí No Messenger Miranda IM W32 Sí Sí Sí Sí Sí Sí Sí Sí Sí Sí Parcialmen (10,11) te (15) Microsoft Carbon No Sí Sí Sí No No No No No Sí No Messenger for Mac MindSpring ? ? ? ? ? ? ? ? ? ? ? ? ?

MySpaceIM ? ? ? ? ? ? ? ? ? ? ? ? ?

Naim ? ? ? ? ? ? ? ? ? ? ? ? ?

OpenWengo Qt Sí Sí Sí Sí No Sí No No ? ? ?

Paltalk n/a Sí Sí Sí No Sí Sí No No No Sí Sí

Pandion ? Sí Sí Sí Sí Sí Sí Sí Sí Sí Sí No

Pidgin GTK2 Sí Parcialm Sí Sí No Sí Sí Sí Sí Sí No (formerly (8,11) ente Gaim)

209 ESTUDIO DEL PROTOCOLO XMPP DE MENSAJERÍA INSTANTÁNEA

Software Toolki Cifrado Transfe- Proxy- Smileys Unicode Juegos Skins Sistema Add-ons Scrip- Logging Mensajería ts o rencia server Gráficos (UTF-8) embeb. Temas de de ting de de Voz SDKs de Plugins terceros mensajes ficheros (1) (2) pork ncurse ? Sí No ? ? No No No No Sí Sí s Proteus Cocoa ? Parcialm Sí ? No Sí Sí Sí ? ? ? ente Psi KDE/Qt Sí (9) Sí Sí Sí No Parcialm No (will No No Sí No ente be (Icon included sets in solo) future release) psyced n/a Sí No No Sí No No Sí Sí Sí Sí No

QIP W32, Sí Sí http(s), Sí No No Sí No Sí No Sí No VCL socks4, 4A, 5 QIP Infium W32, Sí Sí http(s), Sí Sí No Sí Sí Sí No Sí Sí VCL socks4, 4A, 5 Qnext Swing Sí Sí Sí Sí Sí Sí Sí Sí ? ? Sí

QQ W32 No Sí Sí No Sí Sí No Sí No Sí Sí

RealTimeQu N/A Aún no Sí No No No Sí No No No Sí Aún no ery SIM Qt/KDE Sí (5,6) Sí Sí Sí No Sí Sí No ? Sí ?

Skype Qt/KDE Sí Sí Sí Parcialm Sí No Sí Sí ? Sí Sí (Skype , W32 (Skype ente solo) solo) talk curses No No No No No No No No No No No

Trillian W32 Sí Sí Sí Parcialm No Sí No Sí ? Sí ? Basic 3.0 ente Trillian W32 Sí Sí Sí Parcialm Sí Sí Sí Sí Parcia Sí Sí Pro 3.0 ente lmente Trillian W32 Sí Sí Sí Sí Sí Sí Sí Sí Sí ? Sí Sí Astra Windows W32 No Sí Sí Sí Sí Sí Sí Sí Sí Sí Sí Live Messenger (antes MSN Messenger) Windows W32 No Sí Sí Sí No No Parcialm No ? No Sí Messenger ente Xfire W32 No Sí No Sí No Sí Parcialm Sí No Sí Sí ente Yahoo! W32, No Sí Sí Sí Sí Sí Sí No ? Sí Sí Messenger Cocoa, GTK 210 7. APÉNDICES

Software Toolki Cifrado Transfe- Proxy- Smileys Unicode Juegos Skins Sistema Add-ons Scrip- Logging Mensajería ts o rencia server Gráficos (UTF-8) embeb. Temas de de ting de de Voz SDKs de Plugins terceros mensajes ficheros (1) (2) Zephyr ? ? ? ? ? ? ? ? ? ? ? ? ?

211 ESTUDIO DEL PROTOCOLO XMPP DE MENSAJERÍA INSTANTÁNEA

Tabla 2/2

Software Voice Mail Soporte de Mensajería Asistencia Whiteboard Modo de Resúmenes Multicuen- Comproba- Smileys Animacion Offline Escritorio escritura apilables ta ción de gráficos Remoto a mano ortografía definidos por el usuario Adium Sí No Parcialmen ? ? No ? Sí Sí Parcialmen Parcialmen te te te AIM ? Sí Sí ? ? ? ? No ? ? ? aMSN No Sí Sí No No Sí Sí Sí Sí Sí Sí

BitlBee ? No Sí ? ? No ? ? ? ? ?

BitWise IM ? ? Sí ? Sí ? ? ? ? ? ?

Centericq No No Sí ? ? ? ? ? ? ? ? climm N/A N/A Sí N/A No N/A ? Sí ? ? ?

Coccinella No No Sí No Sí ? Sí Sí Sí ? ?

Ebuddy No No Sí ? ? ? ? ? ? ? ?

EQO No No Sí No No n/a n/a Sí No No No

Exodus ? No Sí ? ? ? ? ? ? ? ?

Fire ? ? ? ? ? ? ? ? ? ? ?

Gadu-Gadu ? ? Sí No No ? ? ? ? ? ?

Gajim ? No Sí ? ? ? ? Sí ? ? ?

GCN ? ? ? ? ? ? ? ? ? ? ?

GOIM ? No Sí ? ? ? ? ? ? ? ?

Google Sí Plugin de Sí No No No ? ? No No Sí Talk terceros (Gmail) Gyachi No Sí Sí No No No Sí No No No Sí

IBM Lotus disponible Sí Sí Sí Sí ? ? ? ? ? ? Sametime iChat ? Sí Sí Sí Parcialmen No Sí No Sí No Sí: tZer te (3) ICQ No Sí Sí No No ? ? ? ? ? ?

212 7. APÉNDICES

Software Voice Mail Soporte de Mensajería Asistencia Whiteboard Modo de Resúmenes Multicuen- Comproba- Smileys Animacion Webcam Offline Escritorio escritura apilables ta ción de gráficos Remoto a mano ortografía definidos por el usuario imeem ? ? ? ? ? ? Sí ? ? ? ?

IMVU ? No Sí ? ? ? ? ? ? ? ?

Jabberwock No No No No No ? ? ? ? ? ? y Kadu ? No No ? ? No ? Sí Sí ? ?

Kopete ? Sí Sí ? ? ? ? ? ? ? ?

Licq ? ? Sí ? ? ? ? ? ? ? ?

MCabber No No Sí No No ? ? ? ? ? ?

MECA ? ? ? ? ? ? ? ? ? ? ? Messenger meebo ? ? ? ? ? ? ? ? ? ? ?

Meetro ? ? Sí ? ? Sí Sí Sí No ? ?

Mercury ? Sí Sí ? ? Sí Sí Sí Sí Sí Sí Messenger Miranda IM No Parcialmen Sí No Sí ? ? ? ? ? ? te (15) Microsoft ? No No ? ? ? ? ? ? ? ? Messenger for Mac MindSpring ? ? ? ? ? ? ? ? ? ? ?

MySpaceIM ? ? ? ? ? No ? ? ? ? ?

Naim ? ? ? ? ? ? ? Sí ? ? ?

OpenWengo ? Sí ? ? ? ? ? ? ? ? ?

Pandion ? Sí Sí ? ? ? ? ? ? ? ?

Paltalk ? No Sí ? ? No Sí Sí Sí Sí Sí:smileys

Pidgin No No Parcialmen No Parcialmen ? ? ? ? ? ? (formerly te te Gaim) pork ? No ? ? ? ? ? ? ? ? ?

Proteus ? ? Sí ? ? No ? Sí Sí ? ?

Psi No No Sí No No No No No No ? ?

213 ESTUDIO DEL PROTOCOLO XMPP DE MENSAJERÍA INSTANTÁNEA

Software Voice Mail Soporte de Mensajería Asistencia Whiteboard Modo de Resúmenes Multicuen- Comproba- Smileys Animacion Webcam Offline Escritorio escritura apilables ta ción de gráficos Remoto a mano ortografía definidos por el usuario psyced No No Sí No No ? ? ? ? ? ?

Qnext No No Sí No No Sí Sí Sí Sí Sí Sí:smileys

QIP No No Sí No No Sí Sí Sí Sí Sí Sí:smileys

QIP Infium ? Sí ? ? ? No Sí Sí No Sí ?

QQ No Sí Sí Sí Sí No ? Sí ? ? ?

RealTimeQu No Aún no Aún no No ? ? Sí Sí Sí Sí No ery SIM ? ? Sí ? ? No No No No ? ?

Skype ? Sí (Skype No ? ? ? ? ? ? ? ? solo) talk No No No No No Sí Sí Sí No ? ?

Trillian ? No Sí ? ? Sí Sí Sí Sí ? ?

Trillian ? Sí Sí ? ? Sí Sí Sí Sí ? ? Pro Trillian ? Sí Sí ? ? Sí No No No Sí Sí: Astra Animated , winks Windows Sí Sí Sí Sí Sí No No No No ? ? Live Messenger Windows ? No No Sí Sí ? ? ? No ? ? Messenger Xfire No No No No No ? ? ? ? ? ?

Yahoo! Sí Sí Sí ? ? ? ? ? ? ? ? Messenger Zephyr ? ? ? ? ? ? ? ? ? ? ?

Nota 1: Sistema de Plug-in para añadir/expandir las carácterísticas por defecto que trae la aplicación o el protocolo

Nota 2: Add-ons de terceros que generalmente no son aprovados por el autor de la aplicación y que generalmente son standalone

214 7. APÉNDICES

Software Voice Mail Soporte de Mensajería Asistencia Whiteboard Modo de Resúmenes Multicuen- Comproba- Smileys Animacion Webcam Offline Escritorio escritura apilables ta ción de gráficos Remoto a mano ortografía definidos por el usuario Nota 3: Utilizando software y add-on de terceros. Consultar la web del cliente para ampliar detalles

Nota 4: Propietario; compatible sólo con él mismo

Nota 5: ICQ: conexiones directas cifradas por SSL; compatibles entre climm, licq and SIM

Nota 6: Cualquier protocolo: mensajes cifrados GPG

Nota 7: Conexión directa cifrada por un algoritmo Blowfisf; compatible sólo con él mismo

Nota 8: Nueva versión de Pidgin: el plugin de cifrado de Pidgin. Vieja versión de Gaim: el plug-in de cifrado de Gaim. Disponible en http://pidgin-encrypt.sf.net. Este plug-in sólo es compatible con clientes de Pidgin/Gaim

Nota 9: Compatible con todos los clientes de Jabber que impolementan la XEP-0027 (estándar de cifrado de Jabber)

Nota 10: El plug-in SecureIM proporciona cifrado AES de 128 bit, compatible únicamente entre clientes Miranda

Nota 11: Cifrado extremo a extremo mediante cifrado "Off The Record" (OTR). Audium: Plug-in (embebido), Kopete: Plug-in disponible en http://kopete-otr.follefuder.org. Pidgin: Plug-in disponible en http://www.cypherpunks.ca/otr. Miranda: Plugin disponible en http://addons.miranda-im.org/details.php?action=viewfile&id=2644. Climm: lug-in incrustado desde mICQ 0.5.4. Trillian Pro: Plug-in disponible en http://trillianotr.kittyfox.net

Nota 13: Mientras IMVU no permita add-ons para extender las funcionalidades del cliente, los usuarios con cuentas registradas pueden crear nuevos contenidos para su uso dentro de la simulación

Nota 14: IMVU guarda en un log todas las acciones que realiza el cliente, incluyendo aquellas que no tienen un resultado explícito de texto, haciendo así difícil el empleo del log para la lectura de los mensajes

215 ESTUDIO DEL PROTOCOLO XMPP DE MENSAJERÍA INSTANTÁNEA

Software Voice Mail Soporte de Mensajería Asistencia Whiteboard Modo de Resúmenes Multicuen- Comproba- Smileys Animacion Webcam Offline Escritorio escritura apilables ta ción de gráficos Remoto a mano ortografía definidos por el usuario Nota 15: WebCam Video, un plug-in para Miranda IM, permite chat de video entre dos usuarios del cliente Miranda IM a través de otro protocolo diferente

Note 16: Conexión directa cifrada con AES de 256 bits; sólo compatible con él mismo

Nota 17: Clips de voz soportados en la versión estable, mientras que la carácterística de audio conferencia sólo está disponible en la versión beta de desarrollo

Nota 18: El cliente IRC conectado al servidor bitlbee debería tener en cuenta esta característica

Nota 19: El cliente Jabberwocky permite scripting en lenguaje Arexx

216 7. APÉNDICES

217