UNIVERSIDAD SIMÓN BOLÍVAR DECANATO DE ESTUDIOS PROFESIONALES COORDINACIÓN DE INGENIERÍA DE LA COMPUTACIÓN

Transcripción

1 UNIVERSIDAD SIMÓN BOLÍVAR DECANATO DE ESTUDIOS PROFESIONALES COORDINACIÓN DE INGENIERÍA DE LA COMPUTACIÓN PROTOCOLO DE DESCUBRIMIENTO DE DISPOSITIVOS EN RED Por: Gianpaolo Alexander Valero Cianciarullo Carlos Américo Perez Ruiz Realizado con la asesoría de: Prof. Ricardo González Prof. Soraya Abad PROYECTO DE GRADO Presentado ante la Ilustre Universidad Simón Bolívar como requisito parcial para optar al título de Ingeniero de Computación Sartenejas, Mayo de 2011

2 I- r' UNIVERSIDAD SIMÓN BOLÍVAR DECANATO DE ESTUDIOS PROFESIONALES COORDINACIÓN DE INGENIERÍA DE COMPUTACIÓN ACTA FINAL PROYECTO DE GRADO PROTOCOLOS DE DESCUBRIMIENTO DE DISPOSITIVOS EN RED (EDDP). Presentado por: CARLOS AMÉRICO PÉREZ RUIZ GIANPAOLO ALEXANDER VALERO CIANCIARULLO Este Proyecto de Grado ha sido aprobado por el siguiente jurado examinador: Prof. Roger Clotet SARTENEJAS, 12/05/2011..

3 RESUMEN La empresa Cisco System Inc. está interesada en satisfacer las necesidades de sus clientes en las pequeñas y medianas empresas y en facilitar el uso de sus productos y servicios. En este sentido una de las actividades que puede ser complicada, en especial para usuarios no entrenados en el área de redes, es el descubrimiento y la configuración de los servicios, es por ello que se planteó la idea de automatizar actividades asociadas al descubrimiento y la configuración de servicios que se pueden ofertar en la red. Los primeros intentos de Cisco System Inc. se enfocaron en integrar las estrategias presentes en el mercado, sin embargo los resultados obtenidos no fueron los deseados. Por ello se le planteó, a la Universidad Simón Bolívar, un proyecto con el fin de analizar la factibilidad de realizar un protocolo de descubrimiento de dispositivos y servicios, que pudiera satisfacer las necesidades de sus clientes en cuanto a la configuración automática de servicios a partir de un nuevo diseño. Este proyecto se enfoca en la presentación del diseño de la arquitectura del protocolo planteado y del correspondiente análisis de factibilidad de su implementación. Se desarrolló e implementó un prototipo funcional de la arquitectura del protocolo, comprobando de esta forma la factibilidad de la realización del proyecto. El prototipo final permite la automatización del descubrimiento de dispositivos, y más aún, de los servicios que ellos poseen, además de la automatización de la configuración de esos servicios. Para demostrar esto, se implementaron dos servicios requeridos por Cisco System Inc. Estos son, el descubrimiento de la topología de la red y la transmisión de video de forma automática entre dos equipos. Se logró realizar una implementación 100% funcional basada en el diseño original y además se plantearon algunas mejoras que pueden permitir un mejor funcionamiento del protocolo creado. iii

4 ÍNDICE GENERAL ÍNDICE GENERAL... iv! ÍNDICE DE TABLAS... viii! ÍNDICE DE FIGURAS... ix! LISTA DE ABREVIATURAS... x! INTRODUCCIÓN... 1! CAPÍTULO 1 MARCO TEÓRICO... 5! 1.1! Definiciones... 5! 1.2! Antecedentes... 6! "#$#"! %&'()*!%*+,&-*!.&/-0,*+1! )!4%%.25############################################################################# 6! "#$#$! 78)3&-9/3!.:%!4'.:%5 ########################################################################################################## ;! "#$#<!.:%!=9/*>!%*+,&-*!.&/-0,*+1!4.:%?%.5 "#$#A! %*+,&-*!B0-93&0C! )!4%B25########################################################################################### ""! "#$#D! E&/-0!.&/-0,*+1! )!4E.25 ########################################################################################### "$! "#$#F! E0'(9+9-&GC!*C3+*!)0/!(+030-0)0/###################################################################################### "$! "#$#6! 2+0>8-30/!-0'*+-&9)*/######################################################################################################## "<! CAPÍTULO 2 PLANTEAMIENTO DEL PROBLEMA... 15! 2.1! Estrategia de desarrollo... 16! CAPÍTULO 3 PROTOCOLO EDDP... 18! 3.1! Requerimientos... 18! <#"#"! H*I8*+&'&*C30/!J8C-&0C9)*/ ############################################################################################### ";! <#"#$! H*I8*+&'&*C30/!>*!8/9K&)&>9> ############################################################################################ "@! <#"#<! H*I8*+&'&*C30/!>*!-0'(93&K&)&>9>##################################################################################### "@! iv

5 <#"#A! H*I8*+&'&*C30/!>*!>*/*'(*L0########################################################################################## $M! 3.2! Arquitectura... 21! <#$#"! N/3+93*O&9!O*C*+9)!(9+9!*)!>*/-8K+&'&*C30!9830'P3&-0!>*!>&/(0/&3&,0/!1!/*+,&-&0/############ $"! <#$#"#"! N/3+93*O&9!O*C*+9)!(9+9!*)!>*/-8K+&'&*C30!>*!)9!30(0)0OQ9 ######################################## $"! <#$#$! N/3+93*O&9!O*C*+9)!(9+9!)9!-0CJ&O8+9-&GC!9830'P3&-9!>*!/*+,&-&0/###################################### $$! <#$#<! 7G>8)0/ ############################################################################################################################## $<! <#$#<#"! H*-*(30+###################################################################################################################### $A! <#$#<#$! N'&/0+ ######################################################################################################################### $A! <#$#<#<! R>'&C&/3+9>0+!N..2#################################################################################################### $A! <#$#<#A! <#$#<#D! <#$#<#F! E0C3+0)9>0+!>*!S9K)9/################################################################################################# $D! S9K)9!>*!.&/(0/&3&,0/################################################################################################### $D! S9K)9!>*!%*+,&-&0/######################################################################################################## $D! <#$#<#6! 2)9C3&))9!>*!E0CJ&O8+9-&GC ########################################################################################### $D! <#$#<#;! E0C3+0)9>0+!>*!E0CJ&O8+9-&GC##################################################################################### $F! R>'&C&/3+9>0+!>*)!.&/(0/&3&,0##################################################################################### $F! <#$#A! H0)*/#################################################################################################################################### $F! <#$#A#"! H0)!>*!-)&*C3*############################################################################################################### $6! <#$#A#$! H0)!>*!-0C3+0)9>0+ ###################################################################################################### $;! <#$#A#<! H0)!>*!/*+,&>0+ ############################################################################################################ $;! <#$#A#A! H0)!>*!!"#$%!>*!9C8C-&0############################################################################################## $;! 3.2.5! Formato de los mensajes del protocolo EDDP... 29! <#$#D#"! 7*C/9T*!UNS ############################################################################################################### <"! <#$#D#$! 7*C/9T*!%NS ################################################################################################################ <"! <#$#D#<! 7*C/9T*!V2.RSN######################################################################################################### <$! <#$#D#A! 7*C/9T*!REW ############################################################################################################### <$! v

6 <#$#D#D! 7*C/9T*!7R2############################################################################################################## <<! <#$#F! R)O0+&3'0/########################################################################################################################### <<! <#$#F#"! <#$#F#$! <#$#F#<! R)O0+&3'0!>*!-0C3+0)!>&/3+&K8&>0!(9+9!)9!-0CJ&O8+9-&GC!9830'P3&-9!>*!/*+,&-&0/ ####### <A! R)O0+&3'0!>*!9C8C-&0!1!+*/(8*/39 ############################################################################## <D! R)O0+&3'0!+*9-3&,0!(9+9!*)!>*/-8K+&'&*C30!>*!)9!30(0)0OQ9######################################## <F! <#$#6! S+9C/(0+3*!>*!'*C/9T*/###################################################################################################### <6! <#$#6#"! 78)3&-9/3!*C!N..2####################################################################################################### <6! CAPÍTULO 4 PROTOTIPO EDDP... 38! 4.1! Análisis de los protocolos estudiados con el diseño de EDDP... 39! A#"#"! =0CT08+!1!*)!(+0303&(0!N..2 ############################################################################################### A$! A#"#"#"! A#"#"#$! A#"#"#<! A#"#"#A! B0/!'G>8)0/!>*!N..2!1!=0CT08+ ################################################################################# A<! B0/!+0)*/!>*!N..2!1!=0CT08+ ####################################################################################### AA! B0/!9)O0+&3'0/!>*!N..2!1!=0CT08+############################################################################## AD! N)!J0+'930!>*!'*C/9T*/!>*!N..2!1!=0CT08+ ############################################################### AF! A#"#"#D! X*C39T9/!1!>*/,*C39T9/!>*)!8/0!>*!=0CT08+!(9+9!)9!&'()*'*C39-&GC!>*!N..2# ########## A6! 4.2! Implementación... 48! A#$#"! A#$#$! N39(9!"Y!RC8C-&0!1!+*/(8*/39############################################################################################## A;! N39(9!$Y!Z'()*'*C39-&0C*/!>*!/*+,&-&0/############################################################################# DM! A#$#$#"! A#$#$#$! %*+,&-&0!:*3[0+\!S0(0)0O1 ######################################################################################### DM! %*+,&-&0!>*!,&>*0 ######################################################################################################### D"! A#$#<! N39(9!<Y!E0CJ&O8+9-&GC######################################################################################################## D<! CAPITULO 5 PRUEBAS... 56! 5.1! Pruebas funcionales... 56! 5.2! Pruebas de integración... 58! 5.3! Pruebas de estrés... 59! vi

7 CAPÍTULO 6 CONCLUSIONES Y RECOMENDACIONES... 60! BIBLIOGRAFÍA... 63! APÉNDICE A GLOSARIO DE TÉRMINOS...! APÉNDICE B MODELO DINÁMICO DEL COMPORTAMIENTO DE EDDP...! APÉNDICE C AMBIENTE DE REDES EN LAS PYMES...! APÉNDICE D LISTA DE RIESGOS...! APÉNDICE E ESTUDIO DE PROTOCOLOS DE DESCUBRIMIENTOS EN EL MERCADO...! APÉNDICE F MÁS INFORMACIÓN SOBRE EL DISEÑO DE EDDP...! APENDICE G HERRAMIENTAS TECNOLÓGICAS UTILIZADAS EN LA IMPLEMENTACIÓN DEL PROTOTIPO EDDP...! APÉNDICE H MÁS INFORMACIÓN SOBRE LA INTEGRACIÓN DE BONJOUR Y EL PROTOTIPO EDDP...! vii

8 ÍNDICE DE TABLAS Tabla 1 Comparación entre los protocolo SSDP, mdns, DNS-SD, CDP, SLP... 13! Tabla 2 Análisis entre soluciones estudiadas y los requerimientos... 39! Tabla 3 Comparación entre protocolos y requerimientos no funcionales... 40! Tabla 4 Ventajas y desventajas de usar Bonjour... 47! Tabla 5 Pruebas funcionales realizadas al protocolo EDDP... 57! Tabla 6 Pruebas funcionales sobre los módulos de configuración... 58! Tabla 7 Pruebas de estrés realizadas al protocolo EDDP... 59! Tabla E.8. SSDP y los requerimientos de Cisco System Inc... 93! Tabla E.9 mdsn y los requerimientos de Cisco System Inc ! Tabla E.10 DNS-SD y los requerimientos de Cisco System Inc ! Tabla E.11 Identificadores de los mensajes SLP ! Tabla E.12 SLP y los requerimientos de Cisco System Inc ! Tabla E.13 Estructura básica del mensaje de anuncio CDP ! Tabla E.14 CDP y los requerimientos de Cisco System Inc ! viii

9 ÍNDICE DE FIGURAS Figura 1 Configuración automática en EDDP... 23! Figura 2 Arquitectura EDDP... 23! Figura 3.A Dispositivos una red PYME. Figura 3.B Roles cliente, sevidor y controlador... 27! Figura 4.A Anuncio de un dispositivo en otra interfaz. Figura 4.B Rol de proxy de anuncio... 28! Figura 5 Estructura de los mensajes EDDP... 29! Figura 6 Arquitectura de Bonjour... 42! Figura 7 Bonjour y EDDP... 44! Figura 8 Solicitud de Video... 52! Figura 9 Diagramas de secuencia del servicio de video... 53! Figura 10 Plantilla de Configuración EDDP... 54! Figura 11 Administrador de Configuración EDDP... 55! Figura B.12 Diagrama de estados basado en los cinco escenarios principales de la implementación... 74! Figura C.13 Topología plana de una red de Smallbusiness... 79! Figura E.14 Arquitectura SSDP... 90! Figura E.15. Formato del mensaje de anuncio de SSDP obtenido... 92! Figura E.16 Arquitectura del mdns... 96! Figura E.17 Formato del mensaje DNS... 99! ix

10 Figura E.18 Arquitectura DNS-SD ! Figura E.19 Comportamiento del protocolo SLP ! Figura E.20 Estructura del mensaje SLP ! Figura E.21 Arquitectura CDP ! Figura E.22 Funcionamiento de CDP en una red ! x

11 LISTA DE ABREVIATURAS ARP CDP DHCP DNS EDDP FPS GNU HTTP IMAP IP OAMP OSI PC PyME TCP TTL SDK SLP SSDP STP Address Resolution Protocol Cisco Discovery Protocol Dynamic Host Configuration Protocol Domain Name System Enhanced Device Discovery Protocol Frame Per Second GNU is Not Unix HyperText Transfor Protocol Internet Message Access Protocol Internet Protocol Operations, Administration, Maintenance and Provisioning Open System Interconnection Personal Computer Pequeña y mediana empresa Transmision Control Protocol Time To Life Software Development Kit Service Location Protocol Simple Service Discovery Protocol Spanning Tree Protocol x

12 INTRODUCCIÓN En la actualidad, el uso de la tecnología en los procesos de una empresa se ha vuelto cada vez más cotidiano. En las empresas con una modesta cantidad de empleados, mejor conocidas como PYMES (ver Apéndice C), el uso de la tecnología es importante. Sin embargo, como cada vez surgen nuevos productos y herramientas, la configuración de la red interna de la empresa es una actividad cada vez más demandante y compleja. Para el despliegue de una red empresarial, se necesita configurar cada dispositivo con una dirección IP, o en el mejor de los casos se debe instalar un servidor DHCP [1]. Si la empresa además tiene un dominio propio, se necesita instalar el(los) servidor(es) DNS correspondiente(s) [2], y de nuevo incluir en cada equipo la dirección IP de ese, o esos, servidores. Por otra parte, si hay cambio de equipos, o mudanzas de departamento, se necesita realizar todo el procedimiento de nuevo. Es decir, ni la configuración, ni el mantenimiento son tareas automáticas. Sin embargo, para redes privadas (redes pequeñas o de casa) se ha buscado una solución para este problema principalmente debido a que este tipo de usuario no posee la formación o la pericia necesaria para lograr una correcta configuración de los equipos que posee y adquiere. Es por ello que han surgido productos como UPnP [3] y Bonjour [4], que permiten configurar una red pequeña de manera sencilla, sin la necesidad de tener conocimientos avanzados sobre el tema y con muy poca información previa. Además, se ha logrado que el uso de los servicios entre los dispositivos se haga de manera automática. De esta forma, es posible encontrar un televisor mostrando un video que se encuentra en una computadora de la casa, sin que existan cables conectados al televisor y la computadora (en el caso de que se use comunicación inalámbrica en vez de ethernet).

13 2 Los intentos por llevar estas soluciones al mundo de las PYMES no han cubierto las expectativas de los usuarios. O bien porque hay problemas de seguridad (en el caso de UPnP) [5], o bien porque no hay configuración automática, ya que se necesitan servidores especializados que provean de información previa (el caso de Bonjour) [6]. Por otra parte, no sólo es de interés de las empresas minimizar los procesos en el mantenimiento y configuración de equipos. También es necesario para una PyME, 1) configurar de manera automática y usar los servicios que ofrece cada dispositivo y 2) recopilar información sobre la topología lógica de la red, por ejemplo, para verificar qué equipos están conectados a la red. Para el primer requerimiento se necesita de un protocolo capaz de poder descubrir los dispositivos, y los servicios que ellos ofrecen. Así se puede saber qué ofrece la red a sus usuarios. Luego se necesita de un protocolo que permita crear un mecanismo de comunicación entre quien posea el servicio y quien lo solicite para la negociación de los distintos parámetros del servicio en cuestión. Por ejemplo, para poder hacer streaming de video (que un dispositivo capture video y lo envíe a otro equipo) se necesita de más de 20 variables de configuración [7], por lo que tener un protocolo que permita la negociación automática de estas variables sería un gran avance. Para el segundo requerimiento se necesita un protocolo capaz de compartir la información, que cada dispositivo en la red conoce sobre la topología. De esta manera se puede remitir la información a quien la haya solicitado. Existen soluciones al problema de descubrir dispositivos y servicios en una red, en particular el protocolo Cisco Discovery Protocol (CDP, propiedad de Cisco System Inc.) [8], es capaz de descubrir dispositivos pero no servicios. El producto Bonjour, desarrollado por Apple Inc., es capaz de descubrir servicios pero no es capaz de saber cuál servicio se encuentra en cuál dispositivo. Es decir, no es capaz de descubrir dispositivos. En síntesis, las propuestas en el mercado, solucionan uno u otro requerimiento mas no ambos. Cisco System Inc. abocado a mejorar su servicio a las pequeñas y medianas empresas, ha tratado de buscar una solución que permita cumplir con todos los requerimientos, a saber, configuración automática y fácil mantenimiento de las redes. Su planteamiento inicial fue tratar

14 3 de incorporar en una misma herramienta las distintas propuestas en el mercado. Sin embargo, las soluciones no son coherentes entre sí. Por ejemplo, CDP funciona con direcciones MAC (capa 2), mientras que UPnP y Bonjour con direcciones IP (capa 3). En consecuencia, aparte de incorporar las propuestas ya existentes, ha tenido que incluir otros protocolos para lograr la comunicación de las diferentes soluciones, en este caso el protocolo ARP. Este es sólo uno de los casos donde se muestra que la integración de las diferentes propuestas en el mercado puede ser una tarea complicada. Este modelo de solución no ha cumplido con las expectativas de la empresa. Es por ello, que se planteó un proyecto para analizar la factibilidad de crear un protocolo desde cero (o por lo menos que tuviera coherencia con otras propuestas) capaz de unificar todos los requerimientos propuestos para este producto. A este proyecto se le llamó EDDP (Enhanced Device Discovery Protocol) ya que su función principal es realizar descubrimiento de dispositivos y los servicios que estos ofrecen. Se le plantea a la Universidad Simón Bolívar el abordar este problema en un proyecto de grado, cuyo desarrollo y resultados se presentan en este informe. Dicho proyecto consiste en hacer un estudio de los protocolos que ya se encuentran en el mercado, determinando sus alcances, beneficios y deficiencias. Luego, a partir del estudio, realizar un diseño de un protocolo desde cero que cumpla con los requerimientos de la empresa y por último implementar un prototipo funcional que compruebe la veracidad y factibilidad de desarrollar un protocolo con esas características. El presente libro de proyecto está organizado de la siguiente manera: Capítulo 1: Presenta los diversos estudios acerca de los protocolos existentes para el descubrimiento automático de servicios y/o dispositivos, los cuales han sido desarrollados con el fin de ayudar a los operadores de red. Capítulo 2: Describe el planteamiento del problema, la descripción de los objetivos, el alcance de este proyecto de grado y las estrategias de desarrollo que se planificó usar. Capítulo 3: Describe el diseño del protocolo EDDP, los requerimientos de Cisco System Inc. y la arquitectura de EDDP.

15 4 Capítulo 4: Describe el proceso para el diseño del prototipo y los detalles de implementación del mismo. Capítulo 5: Presenta las pruebas realizadas al prototipo y los resultados de las mismas. Luego se presenta un pequeño análisis de los resultados esperados y los resultados obtenidos. En el último capítulo se muestran las conclusiones de este proyecto de grado y las recomendaciones para trabajos futuros.

16 CAPÍTULO 1 MARCO TEÓRICO Para comenzar con el análisis del proyecto planteado, se describe a continuación una serie de conceptos que darán al lector una mayor comprensión de los procesos involucrados en el desarrollo del proyecto. Estos conceptos se establecen como base para comprender el análisis realizado sobre algunos protocolos de descubrimiento que se han implementado hasta la actualidad. En dicho análisis se muestran algunas de las funciones principales y las limitaciones que presentan estos protocolos. Por último se presentará una comparación entre los protocolos estudiados con el fin de sentar las bases iniciales del proyecto. 1.1 Definiciones La comunicación entre los diferentes dispositivos (computadoras, teléfonos, impresoras, scaners, routers, etc.) se realiza a través de los protocolos. Existen diferentes tipos de protocolos, dependiendo el tipo de comunicación y la finalidad a la que se quiera llegar. En este caso el interés es investigar sobre los protocolos de descubrimiento de dispositivos. La mayoría de los protocolos de descubrimiento se comunican a través de mensajes multicast. A continuación se presenta una definición de estos tres conceptos. Protocolo: Un protocolo es el conjunto de reglas que se definen para transferir información de un dispositivo a otro. Los protocolos generalmente describen una serie de estándares que controlan la comunicación, la conexión y la transmisión de datos puntuales entre dos o más dispositivos. Protocolo de descubrimiento de dispositivos: Es un tipo de protocolo que le permite a un equipo enviar una serie de mensajes y esperar sus respectivas respuestas con el fin de identificar a

17 6 otros dispositivos en la misma red, evitando que usuarios o servidores especializados (servidores DNS, DHCP, etc.) provean esa información. Un ejemplo de una información solicitada para reconocer a otro dispositivo puede ser: obtención de direcciones IP dinámicas en ausencia de un servidor DHCP, descubrimiento de un nombre de máquina en ausencia de un servidor DNS, descubrimiento de servicios, entre otros [9]. La información que se descubra depende de la capa del modelo OSI [10] donde se esté ejecutando el protocolo. Así, si se ejecuta un protocolo de capa 2 se descubrirá información referente al equipo en esa capa, como por ejemplo direcciones MAC. Si se ejecuta un protocolo en capa 3, entonces se obtendrá información de direcciones IP y protocolos en capas superiores descubrirán elementos más abstractos, por ejemplo servicios. Mensajes multicast: Es el medio por el cual un dispositivo puede enviar un mensaje a un grupo de equipos a través de una dirección multicast. Los mensajes multicast son usados en los protocolos de descubrimiento como un medio para poder comunicarse con todos los equipos en la red sin necesidad de saber la dirección específica de cada uno. De esta manera un dispositivo puede anunciarse, o solicitar cierta información en espera de quién pueda responderle. 1.2 Antecedentes Luego de mostrar algunos conceptos básicos se presenta en esta sección el análisis de cinco protocolos con los cuales se ha intentado resolver el problema de descubrir dispositivos. El análisis presenta de forma muy general algunas características, funciones y limitaciones de los protocolos estudiados (si desea mayor detalle en el análisis, ver Apéndice E). Los protocolos de descubrimiento estudiados son: Simple Service Discovery Protocol (SSDP) Multicast DNS (mdns). DNS Based Service Discovvery (DNS-SD)

18 7 Service Location Protocol (SLP). Cisco Discovery Protocol (CDP). Además, se estudian dos productos que han tratado de resolver el problema de descubrimiento mediante la integración de algunas de las características de los protocolos mencionados anteriormente. Estos productos son Bonjour y UPnP Simple Service Discovery Protocol (SSDP) SSDP se define como un protocolo que provee un mecanismo donde clientes en una red, con poca o ninguna configuración estática, pueden descubrir servicios en red [3]. En la actualidad, cuando un pendrive se conecta a una computadora, simplemente se observa que un evento activa una serie de opciones para el nuevo dispositivo (ver los archivos, ver las fotos, ejecutar un antivirus, etc.). Sin embargo, internamente se ejecutan varias operaciones. El pendrive se anuncia a sí mismo ante la computadora, y oferta el servicio de almacenamiento masivo. La computadora la reconoce, se establecen los parámetros por ejemplo sistemas de archivos y el dispositivo está listo para su uso. Cabe destacar que aunque la red en la que se efectúa este descubrimiento es una red interna de la computadora, el concepto aplica para redes más amplias. Con el objetivo de poder realizar las operaciones de descubrimiento y así enviar un requerimiento de información que llegue a todos los equipos de la red, SSDP emplea una dirección multicast y un puerto por defecto. El mensaje es recibido por los puntos de control del protocolo en cada dispositivo y dependiendo de la información solicitada en dicho mensaje se ejecuta una acción específica. Por ejemplo, si el mensaje recibido es una petición de búsqueda, cada equipo contesta con su información de anuncio (información del equipo y de sus servicios). Para mantener la comunicación constante y estar activos en la red, los equipos reenvían un mensaje de anuncio cada cierto tiempo. Sin embargo el protocolo SSDP presenta algunas limitaciones en base a sus funciones. La primera limitación que se tiene es la licencia. UPnP (producto del cual SSDP forma parte), nació

19 8 como una tecnología que requería adquisición de licencia para poder ser implementada dentro de otros dispositivos. Aunque en la actualidad existan varios SDK (Software Development Kit) para las plataformas Linux [11] y Windows [12], no se tiene acceso al código del protocolo SSDP. De nuevo, se necesita licencia para poder adquirir el protocolo SSDP. UPnP se creó, en principio, para redes internas. Ejemplo: un pendrive, cámara y/o impresora conectándose a una computadora por uno de los puertos internos. En la actualidad las nuevas especificaciones han permitido aumentar esa red a redes locales e inclusive llegar al internet. Sin embargo, eso ha generado algunos problemas de seguridad [5]. UPnP usa una funcionalidad llamada port forwarding [13], que consiste en abrir un puerto en un router o firewall, lo que permite que un dispositivo externo pueda comunicarse con un dispositivo interno de la red local. Aunque esta funcionalidad es usada por varias implementaciones, UPnP tenía el problema de que no realizaba ninguna autenticación entre los dispositivos, lo cual representa una vulnerabilidad en el sistema de seguridad. Luego, se estandarizó DCP (Device Control Protocol) [14], realizando las funciones de autenticación. Sin embargo, cuando un dispositivo hace el anuncio, lo hace a todos los dispositivos, sin determinar si es confiable o no. SSDP, permite que una vez que se haga el anuncio, cualquier dispositivo pueda pedir autorización, teniendo completo control del dispositivo, lo que representa un riesgo en la seguridad de la información contenida allí Multicast DNS (mdns) Multicast DNS es un protocolo cuyo objetivo es presentar una forma de uso familiar de las interfaces de programación y la semántica del funcionamiento del protocolo DNS [15]. La intención de esta tecnología no es desplazar a los servidores DNS sino aplicar sus funcionalidades (y otras) en ausencia de un servidor DNS convencional en la red. Es un protocolo que sirve de mensajero entre equipos que consultan y responden bajo una dirección multicast por defecto, y que emplean el formato de consultas del protocolo DNS. El dominio que se usa para las consultas y respuestas es el.local. Este dominio es creado por este protocolo para identificar

20 9 que las consultas y respuestas no vengan de un servidor DNS tradicional, sino de uno conforme a este protocolo. La función principal del Multicast DNS es establecer una correspondencia de dominios, contra direcciones IP en ausencia de un servidor DNS especializado, con sólo realizar mínimos cambios en el protocolo DNS tradicional. Al hacer esto, se mantienen los beneficios que brinda el protocolo DNS, es decir, se obtiene un protocolo maduro, bien entendido, con múltiples e independientes implementaciones de diferentes compañías, con una amplia selección de libros publicados sobre el tema, y una fuerza de trabajo experimentada en sus operaciones [16] Multicast DNS permite cambiar el paradigma tradicional de ver a los servidores DNS como una base de datos jerárquica. En cambio se opta por uno, donde la base de datos está distribuida en todos aquellos dispositivos capaces de responder y consultar bajo la dirección y puerto antes mencionado. A pesar de las ventajas que brinda el protocolo, tiene algunas limitantes. La primera de ellas es que el protocolo no realiza ningún tipo de descubrimiento por sí solo, razón por lo cual funciona en conjunto con su compañero tecnológico DNS-Based Service Discovery. El protocolo Multicast DNS fue desarrollado para automatizar un proceso de configuración. Este proceso es el de introducir información en cada dispositivo sobre dónde encontrar los servidores DNS para poder realizar consultas sobre otros dispositivos y/o servicios. Por otra parte, aunque bien es cierto que este es un protocolo que automatiza las consultas para establecer una correspondencia entre direcciones IP y nombres de dominio, está diseñado para trabajar en el dominio.local. Es decir, no hay intercambio de consultas y respuestas entre varias redes IP, ya que cada dominio.local está constituido por una red local DNS Based Service Discovery (DNS-SD) El protocolo DNS Based Service Discovery, o DNS-SD, es una manera de usar interfaces de programación, servidores, y formatos de mensajes estándar DNS para buscar servicios ofertados en la red [6].

21 10 Los registros DNS son archivos que se guardan en la base de datos jerárquica que conforman los dispositivos que ejecutan el protocolo DNS con la función de guardar información sobre el dispositivo. Dependiendo del tipo de registro, la información que se consigue es distinta. Por ejemplo, los registros tipo a asignan relación entre direcciones IP y nombres de máquina. Los registros tipo srv indican la localidad de un servicio. La función principal de este protocolo es descubrir instancias de servicios mediante la interpretación de los formatos de varios registros DNS. Estos son: el registro srv, Service Record [17], y el registro txt, Text Record [18]. A partir de estos registros y del formato establecido para reconocer la información almacenada en ellos, DNS-SD puede realizar el reconocimiento de un servicio en un dispositivo de una red local. Cabe destacar que las consultas realizadas a los registros DNS mencionados, son hechas en conjunto con su compañero tecnológico Multicast DNS. Sin embargo, ambos protocolos son independientes, tal como puede observarse en la siguiente cita: DNS-Based Service Discovery está solamente relacionada de manera periférica con Multicast DNS, en que el DNS unicast estándar utilizado por las consultas DNS-SD se puede realizar también en multicast, que es particularmente beneficioso en entornos Zeroconf 1. [19]. Una de las limitaciones de este protocolo no reside en la escalabilidad de la red, es decir, si es en área local o fuera de ella. Incluso, es posible descubrir servicios que estén en los países más lejanos. Sin embargo, por sí solo necesita de servidores DNS para encontrar información. Para obtener esta configuración, los administradores de red, deben configurar el equipo para ingresar las direcciones IP de los servidores DNS. En consecuencia, no es un proceso automático. La única manera de obviar la configuración es usar Multicast DNS, pero entonces, se acotaría el descubrimiento sólo al dominio.local. Por otra parte, este protocolo sólo descubre servicios, pasando por alto cualquier información sobre los dispositivos. Por lo que, una consulta hecha a _http._tcp (un tipo especifico de servicio), devuelve todos los servicios registrados bajo este tipo, lista en la que no se puede identificar la información del dispositivo que lo presta. 1 Zeroconf es una serie de técnicas que configura automáticamente una red IP. La implementación de Apple Inc. de estas técnicas se llama Bonjour, la cual está conformada por los dos protocolos que se mencionaron en este trabajo (Multicast DNS y DNS- SD).

22 Service Location Protocol (SLP) SLP se define como un protocolo de descubrimiento de servicios que permite a las computadoras y otros dispositivos encontrar servicios en una red de área local, la cual no ha sido configurada previamente [20]. SLP ofrece un mecanismo de configuración dinámica de aplicaciones en redes de área local. Las solicitudes en SLP se modelan como clientes que necesitan encontrar servidores conectados a cualquiera de las redes disponibles dentro de la empresa [21]. SLP funciona a partir de tres componentes específicos, que son los agentes de usuario (UA), los agentes de servicio (SA) y los agentes de directorio (DA). Estos tres módulos, mediante el uso de una dirección multicast por defecto, establecen la comunicación para poder hacer el reconocimiento de los equipos. Los SA contienen la información de los servicios disponibles en el equipo, por lo que al momento de que un UA envíe un mensaje con la petición de descubrimiento, son los encargados de responder con la información de ubicación del servicio requerido. Los DA son utilizados como intermediarios de la comunicación en redes con mayor cantidad de equipos. Cabe destacar que aunque las peticiones son enviadas en mensajes multicast, las respuestas son enviadas en un mensaje unicast, evitando congestión en la red. El protocolo SLP presenta limitaciones cuando es ejecutado en redes grandes o redes de amplio crecimiento. A medida que la red aumenta, la interacción entre los elementos del protocolo SLP genera un alto tráfico en la red debido a la cantidad de mensajes SLP que se necesitan para ejecutar el protocolo. Adicionalmente, el descubrimiento de dispositivo se encuentra limitado por los routers presentes en la red. El protocolo SLP no brinda al usuario la posibilidad de hacer saltos de routing por lo que el descubrimiento llega hasta el primer router que encuentre el protocolo en la red. La única forma que se tiene en la actualidad de superar esta falla es habilitar el multicast forwarding [22] en los routers de la red.

23 Cisco Discovery Protocol (CDP) Se puede definir CDP como un protocolo, presentado por Cisco System en 1994, que proporciona un mecanismo para el sistema de gestión y aprendizaje de los dispositivos conectados a la red, es decir, permite a dos dispositivos vecinos aprender uno del otro [8]. CDP se ejecuta, por defecto, en los dispositivos Cisco (routers, switchs, teléfonos, entre otros), sin embargo, existen otras compañías que poseen las licencias para ejecutar este protocolo dentro de sus dispositivos. El protocolo CDP se basa en el envío de mensajes CDP entre dispositivos vecinos mediante un mensaje broadcast (no es multicast puesto que CDP se ejecuta en capa de enlace de datos [10]). Allí se envía la información con las capacidades del equipo con el objetivo de que el receptor reconozca, por medio de las características recibidas, si se trata de un router o switch, o cualquier otro equipo. Adicionalmente, una vez que la información es recibida, la misma es almacenada en una tabla persistente en el equipo, donde se almacena la información de todos los vecinos directos reconocidos. En resumen, la función principal de CDP es obtener información de los dispositivos vecinos, no obtener los servicios, es decir, CDP sólo descubre los dispositivos. La principal limitación del protocolo CDP viene dada por el hecho de que CDP funciona solamente en capa de enlace de datos. Como consecuencia de esto, el descubrimiento se encuentra limitado a los equipos que estén conectados al mismo segmento de red del dispositivo que ejecuta CDP, ya que son sólo ellos los que recibirán el mensaje broadcast. Por último, el protocolo CDP, no realiza descubrimiento de los servicios que ofrecen los dispositivos que encuentre en la red. Al no poder realizar el descubrimiento de servicios, las configuraciones de la red (en especial de servicios) no pueden realizarse de manera automatizada Comparación entre los protocolos En la Tabla 1 se presenta una comparación de los protocolos estudiados, basada en los aspectos más relevantes para este proyecto. Es importante resaltar que, con excepción de mdns y DNS- SD, ninguno de los otros protocolos tiene relación entre ellos. Cada implementación ha intentado

24 13 atacar problemas distintos. Por ejemplo, CDP descubre dispositivos, mientras que DNS-SD descubre servicios. Aquellos, que descubren ambos tienen limitaciones de seguridad (SSDP) o escalabilidad (SLP). Además, CDP, mdns y SSDP fueron creados para funcionar en redes locales y, en el caso de SLP, en redes pequeñas. También, SSDP y DNS-SD, poseen limitaciones específicas para poder comunicar varias redes entre sí. SSDP comunica varias subredes pero generando el problema de seguridad mencionado en la sección Por su parte DNS-SD de forma independiente también comunica varias subredes, pero necesita de configuración previa, porque para poder realizar esta función se debe configurar servidores DNS tradicionales. Configuración previa SSDP mdns DNS-SD CDP SLP Ninguna Ninguna La misma que un servidor DNS Ninguna Descubre Servicios Si No Si No Si Descubre Disp. Si No No Si Si Niguna Área local Si Si Si Si Si Comunicación entre redes IP Si No Sólo si usa servidores DNS No No Licencia Propietaria Libre Libre Propietaria Libre Lenguaje de los API s Extra C#,.Net Framework Problemas de seguridad al comunicar redes IP No tiene API. Funciona como un protocolo de transporte para consultas DNS C, Objective-C, Java Define un formato de interpretación para algunos registros DNS C Funciona en la capa 2 de la pila OSI Tabla 1 Comparación entre los protocolo SSDP, mdns, DNS-SD, CDP, SLP C y Java No es escalable Por último, ninguno de esos protocolos estableció alguna manera para la configuración automática de servicios, sólo una estrategia para descubrirlos Productos comerciales Los protocolos descritos han servido para desarrollar productos que realicen el descubrimiento automático de servicios y dispositivos. Dos de estos productos son:

25 14 Universal Plug and Play (UPnP): Producto desarrollado por el foro UPnP. Es independiente del equipo y del medio donde se transmite la información. Además es independiente de la plataforma donde se ejecuta. UPnP implementa, en su módulo de descubrimiento, el protocolo SSDP para poder realizar el reconocimiento del dispositivo. Una vez obtenida la información del equipo, UPnP brinda un sistema de control donde se monitorean los eventos de la red (conexión y desconexión de equipos, por ejemplo) y además presenta una interfaz gráfica donde el usuario puede visualizar los resultados y pueda manipular directamente el dispositivo [3]. Bonjour: Este producto fue desarrollado por Apple Inc, y ha sido utilizado en los productos Apple para el reconocimiento de servicios en los equipos que conforman una red. Ha sido ampliamente reconocido, debido a su expansión a sistemas operativos como Linux, Windows y Solaris distintos de Mac OS (sistema operativo de los productos Apple) donde se ejecuta de manera nativa. Usando la tecnología de Bonjour, se han podido automatizar varios servicios, siendo el más relevante el de impresión. En la actualidad la mayoría de las impresoras ejecutan Bonjour [4]. Bonjour se basa en la implementación de los protocolos DNS- Based Service Discovery y Multicast DNS para realizar el descubrimiento de servicios, ya que su forma principal de trabajo es utilizar la tecnología de DNS y la interpretación de los datos almacenados en dicho servidor para poder realizar el reconocimiento de servicios. Como se vió en las secciones y ambos protocolos, aunque son independientes entre sí, tienen funciones que se complementan. Ambos productos, fueron muy buenos intentos de resolver el problema de descubrir los dispositivos y servicios de una red. Sin embargo, en ambos casos, no se pudo implementar una solución eficiente y segura que permita realizar el descubrimiento más allá de una red local.

26 CAPÍTULO 2 PLANTEAMIENTO DEL PROBLEMA En este capítulo se hace un planteamiento más detallado del problema que se debe resolver en este proyecto de grado. Se determina el alcance completo del proyecto de grado indicando cuáles son los objetivos y las actividades para lograrlos. Por último se explican las estrategias de desarrollo utilizadas. Dentro de las redes PyMES (Pequeña y mediana empresa. Ver Apéndice C) el descubrimiento de dispositivos y servicios, juegan un rol importante; más aún, la configuración automática de estos servicios. Usualmente se requiere del uso de personal especializado para configurar, en los equipos, los servicios anunciados en la red, lo cual se puede volver complicado. Por ejemplo, en casos como el de una cámara IP, se necesitan alrededor de unas 20 variables de configuración para que los clientes puedan hacer un uso adecuado de este servicio. En la actualidad, encontramos protocolos que realizan el descubrimiento o la configuración pero no ambas. Es por esto que este proyecto se plantea, como objetivo general, determinar si es posible mejorar la experiencia de instalación, al igual que la de mantenimiento de dispositivos y servicios, en el ámbito de las PyMES, creando un protocolo capaz de descubrir dispositivos, de descubrir los servicios asociados a éstos, y además permitir la configuración automática de los servicios. Además, tomando en cuenta que las soluciones existentes no tienen una arquitectura en común pero resuelven el descubrimiento o la configuración automática de servicios, se desea demostrar la factibilidad de desarrollar un prototipo que concilie estas funcionalidades. Partiendo del problema que se quiere resolver, en conjunto con Cisco System Inc. se decidió llamar al protocolo propuesto EDDP, Enhanced Device Discovery Protocol, en español Protocolo de Descubrimiento de Dispositivo Aumentado.

27 16 Este nombre se escogió, ya que la funcionalidad primordial del protocolo es descubrir dispositivos, sin servidores intermediarios, ni información agregada por el usuario, la palabra aumentada (Enhanced) viene por las siguientes razones: 1) se desea que no sólo se descubran los dispositivos sino también los servicios que éstos presten; 2) se desea que el descubrimiento se realice más allá del área local y 3) se desea que el protocolo permita crear un medio para poder implementar aplicaciones de configuración automática de servicios. Con el propósito de lograr los objetivos propuestos y determinar el alcance del proyecto se fijaron las siguientes actividades: Realizar el levantamiento de los requerimientos. Esta actividad consiste en especificar en detalle con Cisco System Inc. todos los requerimientos del proyecto. Estudiar cuáles soluciones disponibles en el mercado se acoplan bien a los requerimientos establecidos. Estudiar las soluciones escogidas. Determinar sus deficiencias, sus fortalezas y los requerimientos que no logran cumplir. Diseñar el módulo de descubrimiento de dispositivos y los servicios que prestan los mismos. Diseñar el módulo de configuración de servicios. Es decir, diseñar el protocolo de transmisión de parámetros de configuración. Realizar un prototipo funcional de los módulos diseñados, el módulo de descubrimiento y el módulo de configuración. Queda de parte de Cisco System Inc. realizar las actividades de revisión, implementación en sus equipos, y distribución del protocolo diseñado en este proyecto de grado. 2.1 Estrategia de desarrollo Para el desarrollo del protocolo de este proyecto de grado no existía en Cisco System Inc. una metodología formal específica que se pudiera seguir. Es por esto que, en conjunto con Cisco

28 17 System Inc., se elaboró una estrategia de desarrollo que implicó en mantener una constante comunicación entre todos los actores del proyecto, tutores, tesistas y la empresa. Se comenzó con un levantamiento de requerimientos y partiendo de ellos se determinaban objetivos semanales. Plantear estos objetivos, conllevó a la creación de entregables que eran revisados tanto por los tutores como por la empresa y dependiendo de los resultados se establecían las acciones y/o cambios en los requerimientos, los cuales se presentaban en la reunión siguiente. Además tanto para la empresa como para los tutores, era imperativo que, además de presentar los entregables, se documentara todo el trabajo realizado. Es por ello que, aunque no se usó la metodología de RUP [23] en su totalidad, si se usaron varias de las estrategias y artefactos que ésta plantea. Los artefactos usados de dicha metodología fueron los siguientes: Especificación de requerimientos. Documento de Arquitectura que fue utilizado para documentar la arquitectura y el diseño del protocolo. Diagrama de Estados utilizado para mostrar el comportamiento del protocolo. Diagramas de Secuencia que se realizaron para mostrar el intercambio de mensajes entre los dispositivos. Documento de riesgos que se encuentra en el Apéndice D.

29 CAPÍTULO 3 PROTOCOLO EDDP A continuación se presenta el diseño conceptual del protocolo EDDP. En la sección 3.1 se presentan los requerimientos exigidos por Cisco System Inc. para la implementación de este proyecto. En la sección 3.2 se describe la arquitectura del diseño EDDP basada en los requerimientos explicados previamente. En la misma sección también se describen los roles que pueden adquirir los dispositivos durante la ejecución del protocolo, el formato de mensaje que usa EDDP y los distintos algoritmos que se deben ejecutar para cumplir con las funcionalidades mencionadas en los requerimientos. 3.1 Requerimientos Los requerimientos abarcan todas y cada una de las especificaciones y exigencias que, Cisco System Inc., dió en las reuniones sostenidas con ellos. Dichos requerimientos fueron clasificados en cuatro grandes grupos según el enfoque planteado, a saber: requerimientos funcionales, requerimientos de usabilidad, requerimientos de compatibilidad, requerimientos de desempeño. En las secciones a continuación se explican cada uno de los requerimientos Requerimientos funcionales Los requerimientos de tipo funcional de EDDP son los siguientes: Descubrimiento automático de dispositivos: Uno de los objetivos principales de este proyecto es que los dispositivos electrónicos de una PyME puedan comunicarse entre sí y reconocerse automáticamente unos a otros.

30 19 Descubrimiento automático de servicios: El descubrimiento del dispositivo también involucra el hecho de reconocer los servicios presentes en los dispositivos descubiertos. Reacción automática a la desconexión de un dispositivo de la red: Se desea que EDDP vea sólo aquellos dispositivos que estén conectados a la red, y en el caso que uno deje de estarlo entonces EDDP debe dejar de ver el dispositivo (y sus servicios asociados). Reconocimiento de la topología de la red: Para Cisco System Inc. es importante realizar un protocolo que pueda obtener información de la topología de la red. En este trabajo, las referencias a la topología de la red, son a la topología lógica [24] 2. Realizar saltos de routing: EDDP debe estar en la capacidad de que sus mensajes puedan realizar salto en los routers internos de la empresa con el fin de poder tener acceso a todos los dispositivos de la misma. Por ejemplo, usando multicast fowarding [22]. Permitir la configuración automática de servicios: con este protocolo se busca, ir más allá de simplemente descubrir. Se desea que también habilite un mecanismo para que se pueda implementar la configuración automática de cualquier servicio presente en la red Requerimientos de usabilidad Entre los requerimientos de usabilidad están los siguientes: Poder habilitar o deshabilitar el protocolo: EDDP debe ser opcional en el equipo. Disminuir la complejidad de despliegue de la red: Específicamente se desea con este requerimiento que el protocolo EDDP sea de fácil instalación y configuración. Poseer un módulo de configuración: El protocolo debe tener una interfaz gráfica o página web que permita configurar algunos parámetros de configuración del protocolo Requerimientos de compatibilidad Cisco System Inc. plantea las siguientes especificaciones de compatibilidad para garantizar que el protocolo pueda ser ejecutado en sus equipos: 2 Las topologías lógicas están ligadas a protocolos de red, capa 3 de la pila OSI.

31 20 Compatibilidad con los equipos Cisco ya existentes: Cisco System Inc, desea que EDDP sea compatible con los equipos Cisco para poder comercializarlo. Modularidad: Se desea que el desarrollo del protocolo, es decir su implementación, sea modular para garantizar que el protocolo sea extensible y de fácil modificación en próximas versiones. Licencias: se deben minimizar los gastos en licencias de software Requerimientos de desempeño Los requerimientos de desempeño marcan el patrón que debe seguir el protocolo para que su trabajo sea eficiente y bien visto por la empresa. Éstos son: Rápida convergencia: Puesto que EDDP es un protocolo para redes PyME, se desea que el tiempo de convergencia 3 del mismo sea rápido. Mínima cantidad de mensajes: Se desea que la cantidad de envíos de mensajes de un dispositivo sea la mínima posible. Realizar trabajos por demanda: EDDP debe trabajar sólo en el momento que se requieren sus operaciones. Seguridad: EDDP no debe permitir que un dispositivo aunque use un servicio de otro, sea capaz de configurar otros parámetros, que no sean el del servicio. De todos los requerimientos expuestos se consideraron más relevantes los relacionados al descubrimiento de dispositivos y servicios, así como permitir un medio para la configuración automática de los servicios descubiertos. Estos por ser los más importantes son los que van a guiar las principales estrategias y herramientas que se usarán para crear el diseño del protocolo y la elaboración del prototipo asociado al diseño. 3 En este contexto, el tiempo de convergencia es el tiempo en que tarda el protocolo en realizar las funciones de descubrimiento de dispositivos y servicios.