FONDO REGIONAL PARA LA INNOVACIÓN DIGITAL EN AMÉRICA LATINA Y EL CARIBE INFORME FINAL PROYECTO AIRE-6. "Acceso Inalámbrico a Redes IPv6"

Transcripción

1 FONDO REGIONAL PARA LA INNOVACIÓN DIGITAL EN AMÉRICA LATINA Y EL CARIBE INFORME FINAL PROYECTO AIRE-6 "Acceso Inalámbrico a Redes IPv6" Organización Proponente: Universidad Austral de Chile Jefe Proyecto: Christian Lazo Ramírez. Chile

2 INDICE Resumen Introducción Antecedentes Metodología Diseño de la Red Movilidad de Nodos Configuración Equipos Inalámbricos Control de Acceso e Identificación Presentación de Resultados Conclusiones Bibliografía Anexo Anexo Anexo Anexo

3 RESUMEN La tecnología de comunicación inalámbrica juega hoy un rol muy importante en la masificación, despliegue y uso de Internet. Es así que grandes empresas han impulsado el desarrollo de todo tipo de dispositivos móviles inalámbricos, especialmente los relacionados con el estándar IEEE b/g. Siguiendo esta tendencia, las empresas operadoras de comunicaciones y Proveedoras de Servicios de Internet (ISP), ofrecen estos productos inalámbricos y al mismo tiempo generan nuevos modelos de negocio asociados a esta tecnología. De esta manera, hoy es común hablar de Hot Spot o puntos de conexión a Internet inalámbricos. Por otra parte, estos mecanismos utilizados en la generación de Hot Spot comerciales han sido adoptados y adaptados por reparticiones públicas y privadas, con el fin de masificar su cartera de servicios mediante el uso de Internet. De esta manera, hoy encontramos hoteles, aeropuertos, reparticiones públicas y privadas, que ya cuentan con sistemas de portales cautivos para dar servicios de conectividad inalámbrica a sus clientes. En esta misma línea, pero en el ámbito académico, el tema de las tecnologías inalámbricas no está ausente y hoy día es común conectarse a Internet al interior de los planteles de educación, ya que bibliotecas, salones de conferencias, salas de clases y dependencias, cuentan con puntos de conexión inalambrica que ayudan a mejorar los canales de comunicación entre los miembros de la comunidad. Esta tendencia seguro seguirá creciendo y así lo demuestran estudios realizados por importantes consultoras como Pyramid Research que calcula que en el año 2008 serán 700 millones los usuarios de WI-FI; Garnert Group vaticina que para el 2005 existirán cerca de 71 mil puntos de acceso inalámbrico o Hot Spot funcionando; y Nop World concluyó que la utilización de esta tecnología en las empresas aumenta hasta un 20% la productividad de sus empleados. Siguiendo esta tendencia, un estudio realizado en agosto de 2003 por la Universidad Católica en Chile, concluye que el 45% de las empresas del país tiene planes para incorporar Wi-Fi. Desde el punto de vista legal, el Gobierno de Chile ha visto la importancia y potencial de esta tecnología (Wi-Fi). Esto se ha reflejado en la modificación de la legislación de telecomunicaciones, con el fin de regular y autorizar su uso (Resolución Nº 991). La normativa se refiere específicamente a los equipos que operan al interior de inmuebles, con técnicas de espectro ensanchado, con secuencia directa o con saltos de frecuencia, monitoreo previo o selección dinámica de canales. Por este motivo, la potencia máxima radiada por estos aparatos debe ser de 100 mw, al mismo tiempo se establece que, en la banda de frecuencias de 5150 a 5250 MHz, la operación de los equipos estará restringida al interior de los recintos cerrados (casas, edificios, oficinas, fábricas, almacenes, etc.). Además, la densidad de potencia máxima radiada, no deberá exceder 5mW/MHz en cualquier banda de 1MHz, o su valor equivalente de 0,125mW/25kHz, en cualquier banda de 25kHz. Pero todo este despliegue de nuevas tecnologías trae de la mano nuevos problemas y desafíos tecnológicos: Puntos de accesos inalámbricos que colapsan, porque los requerimientos de las conexiones sobrepasan su límite de servicio. Uso de direcciones IPv4 privadas con NAT (Network Address Translation), como mecanismos de asignación de direcciones para conexión a Internet, lo que trae consigo nuevos problemas. Sobre todo en la administración de seguridad en el uso de túneles y redes privadas virtuales (VPN). Imposibilidad de generar conectividad End to End E2E o conexiones de extremo a extremo, componente imprescindible en el uso de nuevas tecnologías como la Telefonía IP. Finalmente está el tema de la movilidad, la cual necesita tener siempre activo la 4-tupla (dirección, puerto origen dirección, puerto destino -) para no afectar las comunicaciones establecidas ni las características de ruteo y handover. Además, es imprescindible para poder dar un servicio transparente de Always On o siempre conectado

4 Estos factores son los que justamente generan un conjunto de condiciones poco favorables que no contribuyen para nada al desarrollo, despliegue y uso de Internet. Peor aún, ya que generan un marco de trabajo de aparente desarrollo, que sin lugar a dudas se convierte en una limitante al real desarrollo de Internet en nuestra zona. El análisis de esta problemática es uno de los factores que motivó la propuesta del proyecto AIRE-6. Para llevar a cabo el proyecto AIRE-6 se pensó en una solución innovadora, que utiliza el nuevo protocolo de comunicaciones para Internet: IPv6. Así, se realizó el diseño e instalación de un laboratorio piloto, que sirvió de plataforma de pruebas para analizar, desarrollar y evaluar todos los componentes de software y hardware, necesarios para generar un modelo de Hot Spot comercial similar al utilizado por las empresas, pero cuya principal característica fue que sólo utilizó para su despliegue direccionamiento IPv6 nativo, es decir, no se utilizó ninguna dirección IPv4. Esto trajo como consecuencia que se debieron evaluar, desarrollar o modificar, todos los mecanismos que utilizan las empresas actualmente para dar servicios de conectividad internet inalámbrica y hacerlos funcionar sobre la base del protocolo nativo IPv6. Para generar este modelo de comunicaciones, el grupo de investigación del proyecto AIRE-6, debió analizar, generar e instalar plataformas de ruteo y mecanismos de configuración de clientes bajo el protocolo IPv6. De la misma manera, se evaluó y configuró una completa plataforma de servicios telemáticos para Internet tales como: Web, Correo, FTP, DNS y Radius, todos ellos con soporte en forma nativa para el protocolo IPv6. Además, se trabajó en la reconfiguración de plataformas de sotfware IPv6 para equipos de comunicación inalámbrica AP (punto de acceso) y se trabajó con sistemas de firewall y portales web cautivos para proveer mecanismo de control de acceso a la red, mediante un sistema de control de usuarios a traves de páginas web. Todo este trabajo desarrollado por el grupo de investigación dio como resultado el cumplimiento de todos los objetivos propuestos en el proyecto AIRE-6, financiado por FRIDA. Además, consolidó una línea de investigación en el campo de las redes inalámbricas para IPv6 al interior de la Universidad Austral de Chile

5 INTRODUCCION Para llevar a cabo el desarrollo del proyecto AIRE-6 en su conjunto, se procedió a la división de las actividades en cinco fases de trabajo, cada una de ellas claramente diferenciables una de la otra. Las tres primeras etapas de la evolución del proyecto correspondieron a fases de análisis, desarrollo y prueba de los distintos componentes de la tecnología necesaria para el funcionamiento del modelo final. En la cuarta etapa se procedió a la integración de los componentes y servicios desarrollados con sus respectivas pruebas de funcionalidad y mejoras necesarias para la integración de la maqueta funcional. Finalmente, y en forma paralela a todas las etapas anteriores, se realizó la divulgación de los resultados generados durante el desarrollo del proyecto. Cabe resaltar que durante las tres primeras etapas de desarrollo de los componentes y servicios del proyecto, no se estuvo excento de problemas. Esto se debió, principalmente, a que dos de los componentes principales de la arquitectura propuesta para el desarrollo del modelo final (Radius y Acces Point) no estaban perfectamente validados para funcionar con entornos IPv6 nativos, lo que generó en algún caso, problemas de retraso en la entrega de los resultados de los informes. Pero al mismo tiempo, este inconveniente permitió a los miembros del grupo de investigación de AIRE-6 profundizar los conocimientos sobre estos campos de investigación y su problemática, para así de esta manera generar soluciones alternativas innovadoras y de gran interés. De esta forma el esfuerzo mancomunado permitió el cumplimiento de todos los objetivos presentados en la propueta de AIRE-6. Por otro lado, no se puede dejar de mencionar que todo el software que se utilizó durante el desarrollo del proyecto AIRE-6, se generó sobre plataformas de software de código abierto, con software de uso libre. Este hecho permite que en futuras investigaciones o instalaciones de producción, nuestro trabajo pueda ser usado o replicado sin ningún inconveniente de tipo legal

6 ANTECEDENTES DEL TRABAJO El proyecto AIRE-6 fue presentado en el marco del concurso 2004, del Fondo Regional para la Innovación Digital en América Latina y el Caribe (FRIDA), y ejecutado entre los meses de octubre del año 2004 a noviembre del año El trabajo se realizó al alero del Grupo de Investigación de Redes del Instituto de Informática de la Universidad Austral de Chile (UACh). La UACh pertenece al Consejo de Rectores de Chile, entidad que reúne a todas las universidades tradicionales de Chile, además, en calidad de miembro fundador, pertenece al consorcio de Redes Universitarias de Chile (REUNA). Dicho consorcio ha sido y es el generador principal de políticas de acceso a Internet en Chile y referente nacional en la introducción a las Redes Académicas y de Investigación (NRENs). Las direcciones de redes IPv6 utilizadas durante la ejecución del proyecto AIRE-6 pertenecen al proyecto 6Bone y fueron asignadas a la Universidad Austral de Chile el 8 de agosto del año 2002, pudiendo ser utilizadas por la UACh hasta el 6 de junio del año 2006, fecha en que cierra el proyecto 6Bone. El proyecto 6Bone es el principal laboratorio de pruebas a gran escala (mundial) cuyo principal objetivo es el desarrollo de la tecnología IPv6. Dentro de la UACh, la administración de la red IPv6 asignada desde el 6Bone, recae en el Grupo de Redes del Instituto de Informática. La ejecución del proyecto AIRE-6 estuvo coordinada por Christian Lazo R. Durante el desarrollo del proyecto, se contó con la participación de investigadores de la unidad de Informática y alumnos ayudantes de investigación. Los fondos aportados por el Programa FRIDA para la ejecución del proyecto AIRE-6, fueron empleados de acuerdo a lo planificado, siendo estos gastados en gran medida, en la compra de equipamientos para el desarrollo del proyecto. El equipamiento adquirido durante el desarrollo del proyecto seguirá en operaciones durante toda su vida útil y será utilizado en labores de investigación y docencia, principalmente por los miembros del Grupo de Redes del Instituto de Informática, así como también por alumnos que desarrollen proyectos de fin de carrera en esta área. Otro ítem del presupuesto fue utilizado para el pago de incentivos de investigación para el personal involucrado en el proyecto

7 METODOLOGÍA EMPLEADA Para lograr los objetivos propuestos por el proyecto AIRE-6, se procedió a la división de las actividades en cinco fases de trabajo claramente direfenciables una de otra. Las cuatro primeras etapas tienen relación directa con el desarrollo del proyecto, la quinta fase, tiene relación con la divulgación de los resultados. Cada una de estas etapas, se detallan a continuación: 1.- ETAPA DE DISEÑO DE LA RED Para llevar a cabo el desarrollo del proyecto AIRE6 se implantó una red prototipo de forma paralela a la red existente a la UACh. La finalidad de este prototipo fue investigar, desarrollar y validar una metodología de solución. Esta metodología permitió el acceso a redes inalámbricas, usando solamente el protocolo de comunicaciones IPv6 de forma nativa. Las características de esta red de direccionamiento global, permitieron validar los mecanismos necesarios para la implantación de una solución a gran escala. La figura 1 muestra el diagrama de conectividad utilizado por la red piloto del proyecto AIRE6. En ella se aprecia el esquema de conexión a Internet utilizado por el proyecto. Figura 1 FastEthernet0/0 IPv6=3FFE:400F:E001::A1/64 Red AIRE 6 3FFE:400F:EEEE::/48 Eth 0 MAC=00:0F:3D:CE:1F:F7 IPv6=3FFE:400F:E001::C/64 Red GAMMA 3FFE :400F:EEEE:C:/48 Eth 3 MAC=00:11:5B:03:12:32 IPv6=3FFE:400F:EEEE:C::1/64 Eth 1 MAC=00:0F:3D:CE:1F:F1 IPv6=3FFE:400F:EEEE:A::1/64 Red ALFA 3FFE:400F:EEEE:A:/48 Eth 2 MAC=00:0F:3D:CE:1F:F4 IPv6=3FFE :400F:EEEE:B::1/64 Red BETA 3FFE:400F:EEEE:B:/48 Figura 1 Prototipo Red AIRE-6 Dentro de este modelo se pueden identificar los siguientes componentes: El router Chile_6Bone, encargado de dar conectividad Internet a las redes nacionales e internacionales que utilizan los protocolos IPv4 e IPv6 a nivel de investigación y producción. El router AIRE-6, máquina central de las redes del proyecto encargada de la asignación a las subredes (alfa, beta, gama) que se utilizaron para las pruebas del proyecto. Este router tiene por un lado conexión a Internet y por otro a las redes utilizadas en el desarrollo del proyecto. Además, esta máquina es la encargada de albergar al Home Agent (HA), entidad encargada de proveer las componentes de soporte de movilidad

8 Las redes Alfa, Beta y Gama son las encargadas de proveer direccionamiento Internet IPv6, mediante enlaces inalámbricos a través de los AP a los clientes móviles del proyecto. Los clientes móviles son los encargados de probar el direccionamiento y la movilidad dentro de la red Funcionalidades del Router del Proyecto A continuación se detallan las diferentes funcionalidades que posee el router desarrollado en el marco del proyecto Zebra Zebra es un programa para el ruteo, el cual tiene une estructura sintáctica similar a routers/switches de CISCO. Soporta los protocolos de ruteo RIPv1, RIPv2, RIPng, OSPF, OSPF6, BGP4+, y BGP4- y aumenta las capacidades del ruteo estándar en sistemas Linux Tablas de ruta Las conexiones dentro de las subredes del proyecto con el router AIRE6 se configuran con rutas estáticas. Todo el tráfico para la subred Alfa sale por la interfaz eth1, el tráfico para la subred Beta sale por la interfaz eth2, el tráfico para la subred Gama sale por la interfaz eth3. Esto se especifica para direcciones globales, locales y de multidifusión. El tráfico para las conexiones externas del proyecto y la ruta por defecto salen por la interfaz eth Radvd Radvd es el demonio? para la advertencia del router (router advertisement) de IPv6. Escucha para router solicitations y manda router advertisements como se describe en la especificación de la autoconfiguración en IPv6 [4]. Mediante este protocolo, las otras máquinas clientes pueden configurar sus direcciones IPv6 y algunos otros parámetros de forma automática. Ellos también pueden escoger un router predefinido basado en estos anuncios. El funcionamiento correcto del radvd se puede verificar con el comando radvdump SNMP El Protocolo de Gestión de Red Simple (SNMP) es un protocolo de la capa de aplicación que facilita el intercambio de información de gestión entre los dispositivos de la red. SNMP les permite a administradores de la red manejar el rendimiento, encontrar y resolver problemas de la red, y planear su crecimiento. Es una forma estandardizada para coleccionar información, por ejemplo, del tráfico sobre las interfaces, del sistema y mucho más, para analizarla y guardarla por ejemplo en un servidor central. En el router está corriendo un agente SNMP, el cual acumula toda la información y permite que otras aplicaciones en otras máquinas puedan acceder a ella por medio de una comunidad pública. En nuestro caso, se usó como herramienta MRTG MRTG El Multi Router Traffic Grapher (MRTG) es una herramienta para supervisar la carga de tráfico en enlaces de red. MRTG genera páginas web en HTML conteniendo imágenes gráficas que proporcionan una representación visual EN LÍNEA de este tráfico, tal como se muestra en la figura 2. La información necesaria para crear esos gráficos se colecciona mediante SNMP. Lo importante, es guardar la información y actualizar los gráficos cada par de minutos para tener una representación actual del tráfico en el router

9 Figura 2 Estadísticas Web del Router Configuración de clientes Continuando con el desarrollo del proyecto y ya con el router del proyecto operativo, se comenzó a trabajar en la configuración de los clientes utilizados para las pruebas. Para ello, se utilizaron dos equipos portátiles con distintos sistemas operativos (Windows XP y Linux). Para este caso se probó y utilizó el mecanismo de auto configuración proporcionado por el formato EUI 64, apoyado por la dirección física de la misma interfaz. A continuación se detallan cada uno de los pasos seguidos en esta etapa del proyecto: Cliente con el protocolo IPv6 activo pero desconectados de la red En este caso se procedió a revisar la configuración de un cliente luego de habilitar el protocolo IPv6 en la configuración de la máquina. En ella se revisó el estado de auto configuración obtenida Cliente IPv6 activo enlazado en forma inalámbrica a la red Comprobada la disponibilidad de IPv6 en la máquina cliente, se procedió a activar la conectividad inalámbrica en el cliente, el cual, de forma automática, se autoconfiguró con una dirección IPv6 global utilizando para ello el formato EUI Pruebas Realizada la auto configuración, se procedió a revisar la tabla de rutas que se habían obtenido en el cliente, y se revisó la conectividad a escala local y global mediante el comando ping y tracert. Toda la información concerniente a la configuración de los componentes nombrados en este modelo se encuentra disponible en el ANEXO 1 de este informe. Para una información más detallada de los componentes, configuraciones y pruebas realizadas en esta etapa del proyecto, debe consultar: INFORME TÉCNICO 1 Modelo de Red e INFORME TÉCNICO 2 Routing Disponible en el sitio ETAPA DE MOVILIDAD DE LOS NODOS

10 Cuando un nodo IPv6 cambia su punto de acceso a la red y llega a una red distinta, obtiene por los mecanismos de auto-configuración una dirección nueva, la cual es válida en la nueva red. De esa manera puede iniciar nuevas conexiones, pero pierde todas sus conexiones abiertas. Para solucionar este problema se estudió e implantó la solución de Mobile IPv6 (MIPv6). MIPv6 es el protocolo para la movilidad de nodos IPv6, trabajando en la misma capa de IP. Permite a dispositivos móviles cambiar dinámicamente sus puntos de acceso a la red en forma arbitraria. Un host IPv6 puede dejar su subred de origen y cambiarse de locación mientras mantiene transparentemente todas sus conexiones presentes, y sigue siendo alcanzable por el resto de Internet. Un nodo puede seguir usando su dirección de origen aunque esté en una red distinta. Para realizar esa funcionalidad se necesita soporte del protocolo en el nodo móvil (MN). Un router en su red de origen tiene que redireccionar los paquetes llegando en su ausencia en esa red. El demonio en el router que hace esa funcionalidad de proxy se llama Home Agent (HA). La contraparte en una conexión está denominada nodo correspondiente (CN). Cuando un nodo está fuera de su red de origen, avisa a su Home Agent de la nueva dirección obtenida por auto-configuración. Esa se llama "Care-of-Address" (CoA) y le da posibilidad de mandar y recibir paquetes con los mecanismos de IPv6. El mensaje que transfiere esos datos se llama "Binding Update". El HA crea un registro con esa nueva dirección y la dirección de origen "Home Address" (HoA) del nodo móvil, para servir como proxy para esa dirección. De este modo, recibe todos los paquetes destinados a la dirección de origen y los redirecciona, mediante un túnel, al nodo móvil en su punto de acceso a la red actual. Cada cambio de red resulta en una actualización del registro. El HA señaliza los cambios exitosos al MN mediante el mensaje "Binding Acknowledgement". Figura 3 Modelo de Movilidad La configuración de cada uno de los componentes utilizados en esta etapa del proyecto se muestra a continuación: MIPv6 Para las funcionalidades del protocolo Mobile IPv6 se usó la implementación para Linux mipl [1]. Había que recompilar el kernel para la instalación del paquete. Se usó el mismo paquete para todas las funcionalidades (HA, MN, CN) Home Agent (HA) El archivo de configuración del Home Agent tiene que determinar la funcionalidad de Home Agent y las interfaces en los cuales esa se efectuará. Por razones de seguridad, en entornos de producción se recomienda usar autenticación de los Binding Updates con el protocolo ipsec. En nuestro caso, como las redes usadas son experimentales, no se usa

11 Radvd - HA La funcionalidad de auto-configuración de los clientes se realiza, por el router, mediante la advertencia de prefijos de red en los mensajes "router advertisement". El router advertisement también tiene que advertir la funcionalidad de Home Agent en todas las subredes del proyecto. De esa manera, los clientes móviles pueden elegir su Home Agent en forma automática, e incluso, es posible advertir múltiples Home Agent para dividir la carga. Los clientes móviles tienen que escuchar los router advertisements para conocer su Home Agent (si no están configurados en forma estática), para darse cuenta de un cambio de red y obtener una dirección global válida, la cual se sirve como Care-of-Address Configuración Así como previamente se había configurado la advertencia de router, en esta etapa se agregó al demonio de Ravd la funcionalidad de Home Agent (HA). Así, cada vez que un cliente es autoconfigurado recibe las opciones de movilidad Control de router advertisement Para controlar si la configuración se efectuó, se utilizó de igual manera el comando radvdump mediante el cual se muestran los router advertisements transmitidos Mobile Node (MN) El archivo de configuración del nodo móvil tiene que determinar la funcionalidad de nodo móvil. Si un nodo correspondiente también usa Mobile IPv6, es posible activar la optimización de rutas. En este caso no lo hicimos para enfocar en la funcionalidad proxy del Home Agent. Cuando el MN está en su home link o red hogar, las funcionalidades de Mobile IPv6 no se necesitan y los paquetes viajan en forma directa utilizándose para ello el direccionamiento global IPv Movilidad del cliente Cuando el nodo móvil se conecta a una red nueva tiene que seguir los próximos pasos: o o Configurar una nueva dirección global válida, la cual le sirve para la conectividad y como Care-of-Address en la correspondencia por Mobile IPv6. Registrar esa dirección con el Home Agent, para que éste inicie los pasos para funcionar como proxy para los paquetes, llegando a la dirección de origen del nodo móvil. Esto se hace en el mensaje "Binding Update". Después de cierto intervalo de tiempo, ese registro tiene que actualizarse con el mismo mensaje. El Home Agent contesta con un "Binding Acknowledgement" si todo va bien. Si no le llega esa respuesta al nodo móvil, seguirá tratando de hacer el registro MIPv6 Daemon MN Cuando el nodo móvil detecta un nuevo router advirtiendo un prefijo de red distinto a su dirección actual, se da cuenta que se ha cambiado de red. Para tener una ruta válida al Home Agent y mantener conectividad con todas las conexiones abiertas, el cliente tiene que cambiar su túnel hacia el Home Agent. Esto se realiza cambiando la ruta por defecto para que use la interfaz lógica ip6tnl1 en vez de la interfaz física. Luego, tiene que mandar los datos de su nueva dirección (Care-of-Address) al Home Agent en el mensaje Binding Update", para que éste redireccione los paquetes llegando a la dirección de origen del MN al túnel entre el Home Agent y el nodo móvil. Cuando llega el "Binding Acknowledgement" del Home Agent, se actualizan los datos temporales con los atributos que llegan del Home Agent. Cuando llega el próximo router advertisement (en este caso antes de la actualización preparada en el paso anterior), hay que verificar si hubo un cambio de red, actualizar los datos y mandar nuevamente un mensaje "Binding Update". Pasan los mismos pasos que para el mensaje anterior

12 2.4.- Home Agent El Home Agent tiene que crear un registro para el nodo móvil e iniciar su funcionalidad de proxy para la dirección de origen del MN MIPv6 Daemon HA El demonio del HA recibe un "Binding Update" del MN y crea el túnel correspondiente. Se crea un registro con esa información y se manda el mensaje "Binding Acknowledgement". mh_binding_update: Binding Update Received Cuando llega la actualización del "Binding Update", pasan prácticamente los mismos pasos, solamente se modifica el túnel ya existente en vez de crearlo Cambios Direccionamiento HA Cuando el MN está conectado fuera de su punto de acceso de origen, se agrega un túnel del Home Agent al nodo móvil para la funcionalidad de proxy, porque ahora el nodo móvil reside en una red nueva usando una dirección obtenida en esa nueva red, y paquetes destinados a su home link no le llegarían si no por esta funcionalidad Control de conectividad El control de conectividad se realizó nuevamente mediante mensajes icmpv6 "echo request" entre el nodo móvil (MN) y el nodo correspondiente (CN). En el momento de movimiento de una red a la otra, había una demora por el handoff, en la cual todavía no llegaban los paquetes. Después se estableció nuevamente la conectividad mediante la redirección por el Home Agent. Como se puede ver en el paquete del "echo reply" en la figura xx, el nodo correspondiente mandó el paquete al home address del MN y el Home Agent redireccionó el paquete mediante un IPv6 "routing header". Figura 3 Paquete Echo Reply de CN a MN MN se conecta nuevamente a una red distinta Cuando el nodo móvil hace un segundo cambio de red, sigue los siguientes pasos: o o Configurar una nueva dirección global válida, la cual le sirve para la conectividad a la red actual y como Care-of-Address en la correspondencia por Mobile IPv6. Registrar esa dirección con el Home Agent, para que éste inicie los pasos para funcionar como proxy para los paquetes llegando a la dirección de origen del nodo móvil. Eso se hace en el mensaje "Binding Update". Después de cierto tiempo, ese registro tiene que

13 actualizarse con el mismo mensaje. El Home Agent contesta con un "Binding Acknowledgement" si todo va bien. Si no le llega esa respuesta al nodo móvil, seguirá tratando de hacer el registro Mobile Node MIPv6 Daemon MN Cuando el nodo móvil detecta un nuevo router, que está advirtiendo un prefijo de red distinto a su dirección actual, se da cuenta que se ha cambiado de red. Tiene que averiguar si llegó a su red de origen o si todavía está fuera de ella. En este caso, todavía está fuera de su red de origen. Para tener una ruta válida al Home Agent, tiene que cambiar su túnel hacia el Home Agent. En este caso, basta con cambiar el enrutamiento existente para mandar tráfico a la nueva red a la interfáz fisica, y el resto, incluyendo la red de la última dirección fuera de la red de origen, apuntando a la interfaz lógica ip6tnl Direccionamiento HA Como el MN está todavía conectado fuera de su punto de acceso de origen, se modifica el túnel del Home Agent al nodo móvil para la funcionalidad de proxy. En el direccionamiento no se refleja este cambio Nuevo Enrutamiento HA El tráfico hacia el MN tiene que seguir estando redireccionado al túnel. El cambio del túnel se refleja en la tabla de enrutamiento. Los cambios importantes son la agregación de una ruta directa hacia la nueva dirección. La ruta directa a la última direccion del MN desaparece MN vuelve a su red de origen Cuando el nodo móvil vuelve a su red de origen, se siguen los siguientes pasos: o o Borrar las direcciones no pertenecientes a su red de origen. Avisar al Home Agent el hecho de estar de vuelta, para que éste termine funcionando como proxy. Eso se hace en el mismo mensaje "Binding Update". El Home Agent contesta con un "Binding Acknowledgement" si todo va bien. Si no le llega esa respuesta al nodo móvil, seguirá tratando de hacer el registro Mobile Node MIPv6 Daemon MN Cuando el nodo móvil detecta un nuevo router advertiendo un prefijo de red distinto a su dirección actual, se da cuenta que se ha cambiado de red. Tiene que averiguar si llegó a su red de origen o si todavia está fuera de ella. En este caso, volvió a su red de origen. Tiene que desactivar su túnel hacia el Home Agent, así los paquetes viajan de forma directa hacia Internet Estadísticas de tráfico El tráfico generado en las pruebas está representado en los gráficos de la figura 4. Como se ocuparon las tres subredes alfa, beta y gama, se registró tráfico en todos. El tráfico promedio esta generado por los router advertisement

14 Figura 4 Estadísticas de tráfico durante la movilidad Toda la información concerniente a la configuración de los componentes nombrados en este modelo se encuentra disponible en el ANEXO 2 de este informe. Para información más detallada de los componentes, configuraciones y pruebas realizadas en esta etapa del proyecto, debe consultar el informe: INFORME TÉCNICO 3 Movilidad y Configuración de Clientes Disponible en el sitio ETAPA DE CONFIGURACIÓN DE EQUIPOS INALÁMBRICOS. Durante la ejecución del proyecto, uno de los grandes problemas que se debió resolver fue el de implementar un sistema de administración IPv6 a equipos inalámbricos, ya que estos de fábrica carecían de esa opción. Para ello se adquirieron y modificaron equipos AP Linksys. El AP Linksys WRT54g es un AP multifuncional con capacidades de router, switch, AP, Firewall y un módulo de gestión incluido. Internamente el AP usa el sistema operativo Linux. Cuando se encontró una manera de cargarle un firmware nuevo, se inició un proceso de desarrollo, el cual dio como resultado múltiples distribuciones disponibles basadas en Linux, con las cuales se puede cambiar el firmware original de este equipo de comunicación. Todas estas distribuciones pueden ser distribuidas en forma libre bajo GPL. OpenWRT es una distribución Linux modular para el AP Linksys WRT54g. Esta distribución permite la creación de un AP flexible instalando solamente los paquetes necesarios para el proyecto. Al contrario de otras distribuciones, el usuario tiene acceso a un sistema de archivos en modo de escritura. De esta manera, se da la oportunidad de configurar hardware y software en forma poderosa, pero en la configuración básica sin interfaz gráfica. En el desarrollo del proyecto se requiere un AP sin funcionalidades de seguridad ni tampoco de enrutamiento, pero sí la capacidad de gestión por IPv Memoria y sistema de archivos El AP Linksys WRT54g tiene una memoria NVRAM (Non-Volatile RAM) de 64K, en la cual se almacenan varios datos de la configuración básica

15 En ella se define por ejemplo, la asignación de puertas en VLAN, el esquema de bridging, el SSID de la antena inalámbrica, las direcciones IPv4, las puertas de radius, rutas estáticas y varios datos más. Como ya se había mencionado, la distribución además crea en la memoria flash un sistema de archivos jffs2 en modo de escritura, lo cual permite trabajar en forma muy flexible Configuración de red Con las herramientas de los paquetes ip, wl y tcpdump se realizaron las configuraciones de red y pruebas. La configuración usada en el proyecto es la instalada por defecto. La interfaz denominada Wan, respectiva a Internet, solamente está activada para el uso con IPv4 para instalar paquetes. Para el trabajo en el proyecto no se necesita. Tampoco se necesitan las capacidades de enrutamiento. Figura 5 Configuración por defecto. La interfaz física eth0 está en modo promiscuo y está dividida por VLANs. Las puertas 1-4 corresponden a las puertas externas 1-4 del AP. La puerta 5 es la conexión hacia adentro y por eso tiene que ser parte de todos los VLAN definidos. La puerta 0 es la puerta externa WAN/Internet. Las interfaces eth2 y eth3 no tienen puertas asignadas, tal como se muestra en la figura Configuración Paquetes instalados La gestión de paquetes en OpenWRT se realiza mediante la herramienta ipkg. Para los fines del proyecto se instalaron los siguientes paquetes básicos: SSH con las bibliotecas necesarias para el acceso seguro tcpdump para el control de tráfico wl para la configuración de la interfaz inalámbrica ip para la configuración de direcciones y rutas IP Acceso al AP Por defecto, el acceso a un AP con OpenWRT se realiza mediante telnet. Como este tipo de acceso no es seguro, se instaló un servidor ssh. Éste está escuchando en IPv6 e IPv

16 3.5.-Configuración de Paquetes IPv6 Para las funciones de IPv6 se necesita Un módulo para el kernel El módulo del kernel y el programa para configurar las reglas de filtrado en IPv6. Sin éste, no es posible el forwarding de paquetes en IPv6. Opcional: el demonio de router advertisement para las pruebas Para cargar los módulos en el proceso de arranque hay que agregarlas a un script, por ejemplo /etc/init.d/s10boot. En OpenWRT todos archivos originales están en la memoria ROM (directorio /rom ) y cuando uno quiere editarlos, hay que borrar el link simbólico en el sistema de archivos de modo de escritura, crear una copia de escritura y modificarla Configuración de interfaz IPv6 Hay que configurar direcciones, rutas, el comportamiento de forwarding y el manejo de advertencia de rutas. Es posible ocupar las capacidades de auto-configuración para el AP, pero en este momento se usa una dirección estática de la red beta del proyecto Desactivación de IPv4 Una vez que hay conectividad vía IPv6, se puede desactivar el demonio para dhcp. Eso se hace borrando el archivo /etc/init.d/s50dnsmasq. También se puede desactivar el demonio de telnet. Para casos de error, se permite que el demonio corra dos minutos cuando el AP arranca. Toda la información concerniente a la configuración de los componentes nombrados en este modelo se encuentra disponible en el ANEXO 3 de este informe. Para información más detallada de los componentes, configuraciones y pruebas realizadas en esta etapa del proyecto, debe consultar el informe: INFORME TÉCNICO 5 Configuración de Linksys Disponible en el sitio ETAPA DE CONTROL DE ACCESO E INTEGRACIÓN Finalmente se llego a la etapa de puesta en marcha de los mecanismos de control de acceso a los recursos por parte de los usuarios. Esos procesos se pueden manejar en forma común con mecanismos AAAC (Authentication, Authorization, Accounting and Charging). El protocolo más usado para proveer las funcionalidades de AAAC se llama Radius (Remote Authentication Dial-In User Service). Existe otro protocolo más avanzado conocido como Diameter. En el proyecto se experimentó con Radius, pero por limitaciones de los puntos de acceso y de los clientes Radius disponibles, no se logró la implementación del modelo original (véase ANEXO 4). Se diseñó un modelo alternativo el cual se describe en este documento. En este nuevo modelo también se puede usar un servidor RADIUS, pero el costo de complejidad de la implementación versus la ganancia en funcionalidad no rectificó el uso de RADIUS y se usa una forma más simple para lograr el objetivo. Todos los usuarios con dispositivos inalámbricos WiFi b/g, y los cuales tengan el protocolo IPv6 habilitado cuando estén al alcance de la señal de un punto de acceso, se les auto-configura una dirección IPv6 mediante la advertencia de routers. (RADVD) Cuando un usuario quiere usar el servicio de acceso inalámbrico a redes IPv6 tiene que pasar por los mecanismos de AAA antes de tener conectividad

17 Para los mecanismos de autenticación es necesario que el usuario final ingrese sus credenciales electrónicas (login + password). Una forma muy cómoda y simple para el usuario final son los portales Web. Cuando un usuario trata de usar recursos de red, llega a la página portal. En ésta, ingresa sus credenciales y con un sólo clic inicia los procesos necesarios para la autenticación. La idea original era usar portales cautivos, parecidos al sistema implementado hace poco en la Universidad Austral de Chile con cooperación de los investigadores del proyecto. Al parecer, no hay ningún portal cautivo en este momento que soporte la operación en ambientes IPv6, así que se optó por un portal no cautivo, al cual el usuario final tiene que entrar conscientemente para poder acceder a los servicios de red. Este portal para IPv6, usa un script para modificar reglas del filtro de paquetes ip6tables, para implementar las funcionalidades de autorización necesarios Implementación El software usado consiste de librerías en perl, las cuales están disponibles en forma libre y gratuita en la página del sitio Perl MD5 Secure Login [2], las cuales se ajustaron a las necesidades del proyecto AIRE Configuración red La figura 6 muestra la configuración realizada. Al router se agregaron las funcionalidades de filtrado de paquetes y el portal Web. El portal, en teoría, también podría residir en una maquina distinta. Figura 6 Integración del Sistema Portal El portal tiene como objetivo ser la interfaz de autenticación, o sea, ofrecer el formulario para el ingreso de credenciales y enviarlos a un servidor de autenticación para la posterior verificación. Como ya habíamos anteriormente mencionado, el portal no es un portal cautivo. El usuario tiene que conocer su URL para poder ingresar sus credenciales y en el caso de recibir la autorización, usar el servicio de navegación

18 En usos comerciales, este portal puede contener información del servicio y/o publicidad para el proveedor y/o sus patrocinadores. En nuestro caso, no contiene información de tal tipo. En este momento el portal reside en la siguiente URL: Como se puede apreciar, el portal reside en el router de AIRE6, pero en el modelo también podría estar en otra maquina y los comandos se podrían iniciar de forma remota. Figura 7 Página de inicio del portal El portal (figura 7) consiste de dos campos, en los cuales el usuario final puede ingresar su nombre de usuario y contraseña. Al apretar el botón Submit se inicia el script de autenticación contenido en las librerías. En el caso de una autenticación exitosa se verifica que el usuario no tenga una sesión abierta ya. Si no tiene, se le muestra la siguiente pantalla de éxito (Figura 8). En ella se muestra aparte de describir la acción exitosa y un mensaje de bienvenida, el nombre de usuario, la dirección IPv6 del cliente (por razones de depuración) y las instrucciones para terminar la sesión presiona logout. Al final del proceso de apertura exitosa de sesión, se registra el evento en un log, se agrega la sesión en el archivo de sesiones abiertas y se inicia la autorización. El script de autenticación requiere que la URL contenga el nombre y no la dirección IPv6. Así que es necesario configurar el servidor DNS antes de poder usar el portal. Figura 8 Mensaje de éxito del portal En el caso de una autenticación no exitosa, se muestra el siguiente mensaje, el cual permite volver a la página de inicio para ingresar nuevamente los credenciales (figura 9). Figura 9 Mensaje de autenticación invalida del portal

19 Cuando el usuario presiona el botón logout, se inicia un script para las acciones necesarias en el cierre de sesión, las cuales son: borrar la sesión en el registro de sesiones activas, retirar la autorización y mostrar la siguiente pantalla de logout. En esta pantalla se muestra también un enlace para volver a iniciar sesión en la página de inicio. (Figura 10) Figura 10 Mensaje de termino de sesión del portal Cuando un usuario con una sesión activa bajo la misma IP y consecuencialmente con derechos de navegación activas, quiere iniciar la sesión nuevamente, se le notifica de este hecho y se le da la opción de cerrar la sesión e iniciar una nueva sesión, si así lo desea. (figura 11). Figura 11 Mensaje de sesión simultanea del portal Base de datos de usuarios En la base de datos de usuarios se almacenan los datos de autenticación además de datos personales de los usuarios. En detalle, se tienen los siguientes datos: Hash md5 de la contraseña Dirección de correo electrónico Nombre de usuario Para agregar usuarios a la base de datos, existe un script simple al cual se le pasan los 3 parámetros y el cual genera el hash y agrega los datos. También existe un script simple para eliminar usuarios Control de sesión activa Cada vez que un usuario inicie con éxito una sesión, se agrega en un archivo de sesiones su dirección y la hora

20 Si un usuario con una sesión abierta intenta abrir una segunda sesión con la misma dirección IPv6, la información contenida en este archivo permite descubrir la sesión abierta. En este caso aparece el mensaje mostrado en la sección del portal y se le consulta al usuario si quiere mantener su sesión abierta o si quiere cerrarla e iniciar nuevamente. Cuando el usuario cierra su sesión, se borran los datos relacionados a su sesión y se retira la autorización Expiración de sesión También se implementó una expiración de sesión con un concepto muy simple. Se restringe la duración de una sesión mediante un tiempo límite. Un proceso automático y regular, realizado mediante un cron, verifica en todas las sesiones abiertas si han sobrepasado ese tiempo límite. Si este es el caso, se cierra la sesión, se borran los datos relacionados a ella y se retira la autorización Autorización El concepto de autorización consiste en manejar reglas del filtro de paquetes. Para todo el tráfico desde redes externas (entrando por la interfaz eth0) hacia las redes inalámbricas se permite el reenvío en el router. Para el tráfico saliendo desde las redes inalámbricas se permite DNS y el acceso a servicios Web de la máquina en la cual reside el portal. Para todas las direcciones IPv6 sin sesión iniciada, o sea no autenticadas, el resto del tráfico queda bloqueado. El script para eso se describe en el capítulo Cuando la autenticación es exitosa, se le abre el filtro de paquetes para este usuario basado en su dirección IPv6 y se le permite cualquier tráfico. El script para este proceso se muestra en el capítulo Cuando el usuario cierra su sesión, se elimina la regla del firewall que le permitió todo el tráfico y él vuelve al estado de un usuario no autenticado. Esto se realiza con el mismo script que realiza el permiso Iniciar filtrado de paquetes El script inicia.sh elimina reglas anteriormente definidas en el firewall y establece la política para la autorización. Este script tiene que ser ejecutado en el proceso de arranque de la máquina. #!/bin/sh ip6tables -F ip6tables -A FORWARD -t filter -p udp -m udp --dport 53 -j ACCEPT ip6tables -A FORWARD -t filter -i eth0 -j ACCEPT ip6tables -A FORWARD -t filter -p tcp -d 3ffe:400f:eeee:a::1 -m tcp --dport 80 -j ACCEPT ip6tables -A FORWARD -t filter -p tcp -d 3ffe:400f:eeee:b::1 -m tcp --dport 80 -j ACCEPT ip6tables -A FORWARD -t filter -p tcp -d 3ffe:400f:eeee:c::1 -m tcp --dport 80 -j ACCEPT ip6tables -A FORWARD -t filter -j DROP ip6tables -L Modificar filtrado de paquetes Para que este script funcione cuando es llamado desde una página Web, es necesario que tenga el SUID seteado, o sea, que cuente con derechos de administrador cuando se ejecuta. Esto se hace necesario por la restricción de modificar reglas del filtrado de paquetes en el kernel a usuarios con derechos administrativos. El script modifica.sh crea las reglas necesarias para autorizar tráfico de un usuario. Para que estos scripts funcionen cuando son llamados desde una página Web, es necesario que tengan el SUID seteado, o sea, que cuenten con derechos de administrador cuando se ejecutan. Esto se hace necesario por la restricción de modificar reglas de filtrado de paquetes en el kernel a usuarios con derechos administrativos

21 modifica.sh #!/bin/sh metodo=$1 ip=$2 if [ "$metodo" = "aceptar" ]; then /sbin/ip6tables -I FORWARD -t filter -s "$ip" -j ACCEPT elif [ "$metodo" = "denegar" ]; then /sbin/ip6tables -D FORWARD -t filter -s "$ip" -j ACCEPT else echo "FATAL: Bad action: $metodo!" exit Resultados Cambio de reglas en el Firewall Ningún usuario conectado ip6tables -L -v Tue Oct 25 13:51: Chain INPUT (policy ACCEPT 538K packets, 93M bytes) pkts bytes target prot opt in out source destination Chain FORWARD (policy ACCEPT packets, 7988K bytes) pkts bytes target prot opt in out source destination 0 0 ACCEPT udp any any anywhere anywhere udp dpt:domain 0 0 ACCEPT all eth0 any anywhere anywhere 0 0 ACCEPT tcp any any anywhere 3ffe:400f:eeee:a::1/128tcp dpt:http 0 0 ACCEPT tcp any any anywhere 3ffe:400f:eeee:b::1/128tcp dpt:http 0 0 ACCEPT tcp any any anywhere 3ffe:400f:eeee:c::1/128tcp dpt:http 0 0 DROP all any any anywhere anywhere Chain OUTPUT (policy ACCEPT 589K packets, 267M bytes) pkts bytes target prot opt in out source destination Cambio de reglas en el Firewall usuario conectado Come se puede apreciar en el listado de reglas, se le otorgaron derechos de navegación al usuario con la dirección 3ffe:400f:eeee:b::abc. ip6tables -L -v Tue Oct 25 13:53: Chain INPUT (policy ACCEPT 538K packets, 93M bytes) pkts bytes target prot opt in out source destination Chain FORWARD (policy ACCEPT packets, 7988K bytes) pkts bytes target prot opt in out source destination 0 0 ACCEPT all any any 3ffe:400f:eeee:b::abc/128 anywhere 0 0 ACCEPT udp any any anywhere anywhere udp dpt:domain 0 0 ACCEPT all eth0 any anywhere anywhere 0 0 ACCEPT tcp any any anywhere 3ffe:400f:eeee:a::1/128tcp dpt:http 0 0 ACCEPT tcp any any anywhere 3ffe:400f:eeee:b::1/128tcp dpt:http 0 0 ACCEPT tcp any any anywhere 3ffe:400f:eeee:c::1/128tcp dpt:http 0 0 DROP all any any anywhere anywhere Chain OUTPUT (policy ACCEPT 589K packets, 267M bytes) pkts bytes target prot opt in out source destination Logout del mismo usuario

22 ip6tables -L -v Tue Oct 25 13:55: Chain INPUT (policy ACCEPT 538K packets, 93M bytes) pkts bytes target prot opt in out source destination Chain FORWARD (policy ACCEPT packets, 7988K bytes) pkts bytes target prot opt in out source destination 0 0 ACCEPT udp any any anywhere anywhere udp dpt:domain 0 0 ACCEPT all eth0 any anywhere anywhere 0 0 ACCEPT tcp any any anywhere 3ffe:400f:eeee:a::1/128tcp dpt:http 0 0 ACCEPT tcp any any anywhere 3ffe:400f:eeee:b::1/128tcp dpt:http 0 0 ACCEPT tcp any any anywhere 3ffe:400f:eeee:c::1/128tcp dpt:http 0 0 DROP all any any anywhere anywhere Chain OUTPUT (policy ACCEPT 589K packets, 267M bytes) pkts bytes target prot opt in out source destination Toda la información concerniente a la configuración de los componentes nombrados en este modelo se encuentra disponible en el ANEXO 4 de este informe. Para información más detallada de los componentes, configuraciones y pruebas realizadas en esta etapa del proyecto, debe consultar el informe: INFORME TÉCNICO 4 Mecanismos de configuración de AAA e Integración del sistema Disponible en el sitio

23 5.- ETAPA DE PRESENTACIÓN DE RESULTADOS Los resultados de esta investigación fueron presentados en diferentes eventos y congresos, tanto nacionales como internacionales, en forma evolutiva, es decir, en la medida que se lograba algún hito importante, se generaba una presentación pública de los resultados logrados por el proyecto. Tal es así que los resultados se presentaron en los siguientes eventos: 28 y 29 de abril Tercer Encuentro Tecnológico Universitario. Concón, Chile. 27 al 30 de Junio LACNIC VIII, Organizado por El Registro de Direcciones de Internet para América Latina y el Caribe y hospedado por la Red Científica Peruana (RCP) y el NAP Perú. Ciudad de Lima, Perú. 29 de agosto de IPv6 Tour Chile, Evento Organizado por El Registro de Direcciones de Internet para América Latina y el Caribe (LACNIC), NIC Chile, y la Subsecretaría de Telecomunicaciones. Santiago, Chile. 5 al 8 de octubre Tour IPv6 Cuba, organizado por el Ministerio de la Informática y las Comunicaciones y la Universidad de la Habana de ese país. Ciudad de la Habana, Cuba. Además, se presentaron Charlas para estudiantes universitarios al interior de la Universidad Austral de Chile en las cuales se mostró el proyecto y sus alcances. De estas reuniones se generaron líneas de desarrollo de trabajo de Tesis de fines de carrera, las cuales se encuentran en fase de desarrollo. Del trabajo en su total queda material para el desarrollo de una publicación, la cual se encuentra en fase de producción y será presentada para su publicación en una revista de carácter científico tecnológico. Finalmente, los autores quieren agradecer a LACNIC y FRIDA por la financiación del proyecto y al mismo tiempo agradecer a todas aquellas personas que directa e indirectamente estuvieron involucrados en el desarrollo y éxito del proyecto