Caracoche Tesisdegradoingenieriainformatica

Redes Mviles Seguras o en un Ambito Urbano
Utilizando Protocolo OLSR Tesis de Grado en Ingenier Informtica a a Orientacin en Sistemas Distribu o dos
Juan M. Caracoche
juan@caracoche.com.ar
Director: Hugo Pagola

Facultad de Ingenier a Universidad de Buenos Aires
Millones de personas vieron caer la manzana, pero Newton fue el unico que se pregunt porque. o Bernard Baruch
Resumen
Las redes mviles (Mobile Ad-hoc NETworks -MANET-) son un tipo especial de redes en o la cual un conjunto de dispositivos mviles conforman de manera temporal una red de forma o autnoma sin la necesidad de una infraestructura. Para estos ambientes existen distintos protoo colos para el ruteo de paquetes donde los integrantes de la misma estn en continuo movimiento, a hay protocolos que brindan a parte de ruteo, seguridad para los integrantes de la red. Estos protocolos son variados y cada uno es propenso a distintos tipos de ataques. En particular las redes Mviles Urbanas son un subgrupo de las redes mviles donde se encuentran nodos diseminados o o por toda una ciudad, la geograf de una ciudad y las limitaciones del medio de trasmisin de la a o tecnolog 802.11 hacen que se deba armar una topolog particular, lo que hace que los nodos a a que participen tengan distintos roles. En particular la red Urbana Buenos Aires Libre es el objeto de estudio de esta tesis donde se analiza el protocolo OLSR utilizado por la red y se disea un n esquema de seguridad para hacerla lo ms inmune posible a ataques externos. a
Juan Manuel Caracoche - Tesis de grado Ingenier Informatica a
Abstract
The mobile networks (Mobile Ad-hoc NETworks -MANET-) are a special kind of network where a set of mobile devices build in a spontaneous way a temporary self-organized network without any infraestruture to work. For this king of networks there are dierents routing protocols to guide packets between nodes which are constantly moving. Some of this protocols not only guarantee the routing, they also give security to the protocol. In particulary, a Urban Mobile Networks are a subset of mobile networks where nodes are diseminated over all the city. The citys geography and the transmision technology (802.11) bring into the scene some constraints that makes to build specials topologies where each node in the net may take dierent roles. In particulary the Urban Network Buenos Aires Libre, is the study target of this thesis. Over this network is analyzed the OLSR protocol which is used as routing protocol and a security scheme is designed to make this networks safer as possible against external attacks.
II
Agradecimientos
Quiero agradecer a muchas personas por el apoyo durante el desarrollo de esta tesis y en la vida misma Al Ing. Hugo Pagola, tutor de esta tesis, quien a pesar de sus innumerables compromisos pudo siempre hacerse el tiempo para atender mis consultas, realizar las correcciones y aportar ideas. A mi familia, en especial a mis padres que sin medir privaciones o sacricios entendieron que la educacin de un hijo es ms que una inversin. o a o A mi novia que tuvo la paciencia de acompaarme en el duro camino de mis ultimos aos de n n la carrera. Por supuesto no pod olvidarme del apoyo incondicional de mis amigos y compaeros, que a n me dieron durante los aos de facultad, los mejores aos de mi vida. n n
Juan Manuel Caracoche

Agosto 2008
III
Acerca del Autor

Juan Manuel Caracoche naci en la ciudad de Pellegrini, provincia de Buenos Aires el 16 o de Febrero de 1980. Realiz sus estudios primarios en la escuela Guillermo de Soldato y los o secundarios en el Instituto Jos Manuel Estrada, ambos establecimientos de su ciudad natal. En e el ao 1998 se traslada a la ciudad de Buenos Aires para comenzar sus estudios universitarios en la n Facultad de Ingenier de la Universidad de Buenos Aires, actualmente es estudiante de la carrera a Ingenier Informtica. Adicionalmente es docente auxiliar del Departamento de Electrnica de a a o la misma Universidad.
IV
Indice general
Resumen Abstract Agradecimientos Acerca del Autor
I
II
III
IV
1. Introduccin o 11 1.1. Motivacin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 o 1.2. Objetivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 2. Redes Mviles o 2.1. Generalidades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2. Protocolos de Ruteo . . . . . . . . . . . . . . . . . . . . . . . . . 2.3. Protocolos de Ruteo Proactivos, Reactivos e H bridos . . . . . . . 2.3.1. Protocolos de Ruteo Proactivos . . . . . . . . . . . . . . . 2.3.1.1. Destination-Sequenced Distance-Vector (DSDV) 2.3.1.2. Optimized Link State Routing (OLSR) . . . . . 2.3.2. Protocolos de Ruteo Reactivos . . . . . . . . . . . . . . . 2.3.2.1. Ad hoc on-demand distance vector (AODV) . . 2.3.2.2. Dynamic Source Routing (DSR) . . . . . . . . . 2.3.3. Protocolos de Ruteo H bridos . . . . . . . . . . . . . . . . 2.3.3.1. Zone Routing Protocol (ZRP) . . . . . . . . . . 2.3.4. Tcnicas de Ruteo . . . . . . . . . . . . . . . . . . . . . . e 2.3.4.1. Multipath Routing . . . . . . . . . . . . . . . . . 2.4. Resumen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3. Seguridad Informtica a 3.1. Conceptos Bsicos de Criptograf . . . a a 3.1.1. Cifrados Simtricos . . . . . . . . e 3.1.1.1. Seguridad . . . . . . . . 3.1.1.2. Ventajas y Desventajas 1 13 13 14 15 15 16 17 18 19 23 26 26 28 28 29 31 31 32 32 32
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
INDICE GENERAL
3.1.1.3. Algoritmos . . . . . . . . . 3.1.2. Cifrados Asimtricos . . . . . . . . . e 3.1.2.1. Seguridad . . . . . . . . . . 3.1.2.2. Ventajas y Desventajas . . 3.1.2.3. Algoritmos . . . . . . . . . 3.1.3. Resumen Criptogrco . . . . . . . . a 3.1.3.1. Hash . . . . . . . . . . . . 3.1.3.2. MAC . . . . . . . . . . . . 3.1.4. Firma Digital . . . . . . . . . . . . . 3.1.5. PKI . . . . . . . . . . . . . . . . . . 3.1.5.1. Propsito y funcionalidad . o 3.1.5.2. Usos de la tecnolog PKI . a 3.1.5.3. Certicados . . . . . . . . . 3.1.6. Componentes . . . . . . . . . . . . . 3.1.6.1. Consideraciones sobre PKI 3.2. Resumen . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
32 33 33 34 34 34 34 35 35 36 36 37 37 38 38 38 41 42 42 42 43 43 43 43 44 44 46 46 46 48 48 48 50 50 51 52 52 53 54 55
4. Seguridad en Redes Mviles o 4.1. Ataques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.1.1. Ataques Externos . . . . . . . . . . . . . . . . . . . . . . 4.1.1.1. Interceptacin Pasiva . . . . . . . . . . . . . . o 4.1.1.2. Interferencia Activa . . . . . . . . . . . . . . . 4.1.2. Ataques Internos . . . . . . . . . . . . . . . . . . . . . . 4.1.2.1. Nodo Fallido . . . . . . . . . . . . . . . . . . . 4.1.2.2. Nodo Fallido Maligno . . . . . . . . . . . . . . 4.1.2.3. Nodo ego sta . . . . . . . . . . . . . . . . . . . 4.1.2.4. Nodo Malicioso . . . . . . . . . . . . . . . . . . 4.2. Protocolos de Ruteo Seguros . . . . . . . . . . . . . . . . . . . 4.2.1. SRP - Secure Routing Protocol . . . . . . . . . . . . . . 4.2.1.1. Descubrimiento de la Ruta . . . . . . . . . . . 4.2.1.2. Otras Vulnerabilidades . . . . . . . . . . . . . 4.2.1.3. Ideas Rescatadas para el Desarrollo de la Tesis 4.2.2. ARIADNE . . . . . . . . . . . . . . . . . . . . . . . . . 4.2.2.1. Ideas Rescatadas para el Desarrollo de la Tesis 4.2.3. Resumen . . . . . . . . . . . . . . . . . . . . . . . . . . 5. Redes Mviles Urbanas o 5.1. Proyectos Comunitarios Libres 5.1.1. Buenos Aires Libre . . . 5.2. Topolog . . . . . . . . . . . . a 5.2.1. Direccionamiento IP . . 5.3. Protocolos de Ruteos . . . . . .
2
. . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
INDICE GENERAL
5.4. Servicios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 5.5. Administracin de la Red BAL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 o 5.6. Resumen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 6. Protocolo OLSR 6.1. Introduccin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . o 6.2. Terminolog Propia de OLSR . . . . . . . . . . . . . . . . . . . a 6.3. Tablas del Protocolo . . . . . . . . . . . . . . . . . . . . . . . . 6.4. Cmo Funciona? . . . . . . . . . . . . . . . . . . . . . . . . . . o 6.4.1. Mensajes de OLSR . . . . . . . . . . . . . . . . . . . . . 6.4.2. Etapa 1: Censado y Descubrimiento de Vecinos . . . . . 6.4.2.1. Mensaje de HELLO . . . . . . . . . . . . . . . 6.4.2.2. Mensaje MID . . . . . . . . . . . . . . . . . . . 6.4.2.3. Censado y Descubrimiento . . . . . . . . . . . 6.4.3. Etapa 2: Eleccin de los MPRs . . . . . . . . . . . . . . o 6.4.4. Etapa 3: Mantenimiento de la Topolog . . . . . . . . . a 6.4.4.1. Mensaje TC . . . . . . . . . . . . . . . . . . . 6.4.4.2. Mecanismo de propagacin de los mensajes TC o 6.4.5. Etapa 4: Formacin de las Rutas . . . . . . . . . . . . . o 6.4.6. Etapa 5: Mantenimiento de las Rutas . . . . . . . . . . 6.4.7. Comunicacin con Otras Redes . . . . . . . . . . . . . . o 6.4.7.1. Mensaje HNA . . . . . . . . . . . . . . . . . . 6.4.7.2. Asociacin de la redes . . . . . . . . . . . . . . o 6.5. Seguridad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.5.1. Condencialidad . . . . . . . . . . . . . . . . . . . . . . 6.5.2. Integridad . . . . . . . . . . . . . . . . . . . . . . . . . . 6.5.3. Mensajes a Proteger . . . . . . . . . . . . . . . . . . . . 6.6. Vulnerabilidades . . . . . . . . . . . . . . . . . . . . . . . . . . 6.7. Resumen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 57 57 58 60 60 61 61 63 64 65 68 69 69 70 71 71 71 72 72 72 73 73 74 77 79 79 80 80 81 81 81 83 83 84 84 84
3
. . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . .
7. Dise o de un Esquema de Seguridad para una Red Mvil OLSR Urbana n o 7.1. Esquema de Seguridad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.2. Fundamentos del Diseo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . n 7.2.1. OLSR ms Fuerte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . a 7.3. Esquema de Clave Pblica y Privada . . . . . . . . . . . . . . . . . . . . . . . . u 7.3.1. Autoridad Certicante . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.3.2. Esquema de Certicacin . . . . . . . . . . . . . . . . . . . . . . . . . . o 7.4. Fortalecimiento de OLSR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.4.1. Prevencin de Ataques . . . . . . . . . . . . . . . . . . . . . . . . . . . . o 7.5. Integracin del IDS y la CA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . o 7.6. Interaccin de los Nodos Clientes con Esquema de Seguridad Planteado . . . . o 7.6.1. Esquema de conanza ganada . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
INDICE GENERAL
7.7. Resumen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 8. Art culos ms Relevantes Relacionados con la Seguridad de OLSR a 8.1. Secure Extension to the OLSR protocol . . . . . . . . . . . . . . . . . 8.1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.1.2. Firma . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.1.3. Timestamps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.2. Secure OLSR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.2.2. Deteccin segura de vecino . . . . . . . . . . . . . . . . . . . . o 8.2.3. Autenticacin de vecinos . . . . . . . . . . . . . . . . . . . . . . o 8.2.4. Paquetes de Ruteo Seguros . . . . . . . . . . . . . . . . . . . . 8.3. Securing the OLSR protocol . . . . . . . . . . . . . . . . . . . . . . . . 8.3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.3.2. Firma de Mensajes . . . . . . . . . . . . . . . . . . . . . . . . . 8.3.3. Timestamping . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.3.4. PKI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.3.4.1. PKI Proactiva Simple para OLSR . . . . . . . . . . . 8.3.4.2. PKI Reactiva Simple para OLSR . . . . . . . . . . . . 8.4. Resumen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9. Detalles de Implementacin del Esquema de Seguridad Propuesto o 9.1. Esquema de Certicacin . . . . . . . . . . . . . . . . . . . . . . . . . o 9.1.0.3. Procedimiento para la registracin de un nodo . . . . o 9.2. Fortalecimiento del Protocolo OLSR . . . . . . . . . . . . . . . . . . . 9.3. Fortalecimiento de OLSR: Nivel 1 . . . . . . . . . . . . . . . . . . . . . 9.3.1. Tablas del Protocolo . . . . . . . . . . . . . . . . . . . . . . . . 9.3.2. Obtencin del Certicado . . . . . . . . . . . . . . . . . . . . . o 9.3.2.1. Generacin del mensaje CADISCOVER . . . . . . . . . . o 9.3.2.2. Procesamiento del mensaje CADISCOVER . . . . . . . 9.3.2.3. Generacin del CERTREQ . . . . . . . . . . . . . . . o 9.3.2.4. Generacin del Certicado . . . . . . . . . . . . . . . o 9.3.2.5. Renovacin de certicado . . . . . . . . . . . . . . . . o 9.3.3. Deteccin de Vecinos . . . . . . . . . . . . . . . . . . . . . . . . o 9.3.3.1. Autenticacin de los vecinos . . . . . . . . . . . . . . o 9.3.3.2. Eleccin de MPR . . . . . . . . . . . . . . . . . . . . o 9.3.4. Firma y encripcin de los mensajes . . . . . . . . . . . . . . . . o 9.3.4.1. Obtencin de la Clave de Sesin . . . . . . . . . . . . o o 9.3.4.2. Firma de los mensajes . . . . . . . . . . . . . . . . . . 9.3.4.3. Protocolo de encriptacin . . . . . . . . . . . . . . . . o 9.3.5. Descubrimiento de la Topolog . . . . . . . . . . . . . . . . . . a 9.3.6. Armado de la tabla de Ruteo . . . . . . . . . . . . . . . . . . .
4
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
87 88 88 88 88 89 89 89 90 91 92 92 92 93 93 94 94 95
. . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
97 . 97 . 98 . 98 . 99 . 99 . 100 . 100 . 100 . 101 . 102 . 102 . 103 . 104 . 106 . 106 . 106 . 108 . 109 . 109 . 110
INDICE GENERAL
9.3.7. Logros del Nivel 1 de securizacin . . . . . . . . . . . . . . . o 9.4. Fortalecimiento de OLSR: Nivel 2 . . . . . . . . . . . . . . . . . . . . 9.4.1. Prevencin contra ataque Wormhole . . . . . . . . . . . . . . o 9.4.2. Prevencin contra ataque de reenv de mensajes: Timestamp o o 9.4.3. Prevencin contra ataques de DoS . . . . . . . . . . . . . . . o 9.4.4. Otros ataques mitigados . . . . . . . . . . . . . . . . . . . . . 9.4.5. OLSR RFC 3226 vs. OLSR Seguro . . . . . . . . . . . . . . . 9.5. Fortalecimiento de OLSR: Nivel 3 . . . . . . . . . . . . . . . . . . . . 9.5.1. Mecanismo de Denuncia . . . . . . . . . . . . . . . . . . . . . 9.5.2. Sistema de Deteccin de Intrusos . . . . . . . . . . . . . . . . o 9.5.2.1. Interaccin con las CAs . . . . . . . . . . . . . . . . o 9.5.3. Sincronizacin de CRLs . . . . . . . . . . . . . . . . . . . . . o 9.6. Debilidades del Esquema de Seguridad propuesto . . . . . . . . . . . 9.7. Resumen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.Prueba de Contenido 10.1. Arquitectura . . . . . . . . . . . . . . . . . . . . . . . . 10.1.1. Certicados y Keystores . . . . . . . . . . . . . . 10.1.2. Conguracin del Nodo . . . . . . . . . . . . . . o 10.1.3. Plugin olsrd para generar el archivo de topolog a 10.1.4. Mensajes . . . . . . . . . . . . . . . . . . . . . . 10.1.5. Mdulo de Autoridad Certicante . . . . . . . . o 10.1.6. Mdulo de Autenticacin con los vecinos . . . . . o o 10.1.7. Mdulo de Procesamiento de mensajes OLSR . . o 10.2. Implementacin . . . . . . . . . . . . . . . . . . . . . . . o 10.2.1. Descubrimiento de CAs y Vecinos . . . . . . . . 10.2.1.1. Demonio de Procesamiento de mensajes 10.2.2. Autoridad Certicante . . . . . . . . . . . . . . . 10.2.2.1. Interaccin Nodo-CA . . . . . . . . . . o 10.2.3. Autenticacin con los Vecinos . . . . . . . . . . . o 10.3. Modos de Operacin del Simulador . . . . . . . . . . . . o 10.4. Resumen . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.Conclusiones
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. 110 . 111 . 111 . 112 . 113 . 114 . 114 . 115 . 115 . 115 . 115 . 115 . 116 . 116 117 . 118 . 119 . 119 . 119 . 119 . 120 . 121 . 121 . 121 . 121 . 122 . 122 . 123 . 123 . 124 . 125 127
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . OLSR . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
INDICE GENERAL
Indice de guras
2.1. 2.2. 2.3. 2.4. 2.5. 2.6. 2.7. Clasicacin de protocolos de ruteo . . . . . . . . . o Multipoint Relays . . . . . . . . . . . . . . . . . . Ejemplo de la construccin de una ruta en AODV o Deteccin de un enlace roto y env del RERR . . o o Ejemplo de la construccin de una ruta en DSR . . o Zona de un nodo usando ZRP . . . . . . . . . . . Descubrimiento de una ruta con IERP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 17 22 24 25 27 27
3.1. Proceso de Generacin y Vericacin de una Firma Digital . . . . . . . . . . . . . 36 o o 4.1. Formato del encabezado de un protocolo de ruteo con la extensin de SRP . . . . . 47 o 4.2. Encabezado de SRP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 4.3. Encabezado SRP con extensin INRT . . . . . . . . . . . . . . . . . . . . . . . . . 48 o 5.1. Diagrama de una red Mvil Urbana . . . . . . . . . . . . . . . . . . . . . . . . . . 54 o 6.1. Etapas del protocolo OLSR . . . . . . . . . . . . . . . . . . . . . 6.2. Formato del paquete de OLSR . . . . . . . . . . . . . . . . . . . 6.3. Campo de 8 bits para indicar el cdigo del enlace . . . . . . . . . o 6.4. Formato del mensaje de HELLO . . . . . . . . . . . . . . . . . . 6.5. Formato del mensaje MID . . . . . . . . . . . . . . . . . . . . . . 6.6. Censado y Descubrimiento de Vecinos - Parte 1 . . . . . . . . . . 6.7. Censado y Descubrimiento de Vecinos - Parte 1 . . . . . . . . . . 6.8. Multipoint Relays . . . . . . . . . . . . . . . . . . . . . . . . . . 6.9. Fase 1 : Seleccin de MPRs que cubren nodos aislados del Nivel2. o 6.10. Fase 2: Se completa la seleccin de MPRs. . . . . . . . . . . . . . o 6.11. Formato del mensaje TC . . . . . . . . . . . . . . . . . . . . . . . 6.12. Formato del mensaje HNA . . . . . . . . . . . . . . . . . . . . . . 6.13. Generacin incorrecta de mensajes HELLO . . . . . . . . . . . . o 6.14. Generacin incorrecta de mensajes TC . . . . . . . . . . . . . . . o 6.15. Ataque por tnel (Wormhole) . . . . . . . . . . . . . . . . . . . . u 6.16. Ataque al (MPR-Flooding) . . . . . . . . . . . . . . . . . . . . . 7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 62 62 63 64 65 66 67 68 68 69 72 74 75 76 76
INDICE DE FIGURAS
7.1. Componentes participantes en el esquema de seguridad propuesto . . . . . . . . . 81 7.2. Esquema de Certicacin. CA de la comunidad expide certicados a los nodos o enrolados y estos expiden certicados a los clientes . . . . . . . . . . . . . . . . . . 82 7.3. Ejemplo de utilizacin de una red Mvil Urbana Segura interconectando distintas o o plazas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 8.1. 8.2. 8.3. 8.4. Mensaje de rma bsico . . . . . a Pasos para lograr una relacin de o Extensin del paquete OLSR . . o Formato del mensaje de rma . . . . . . . . . . conanza con . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . un vecino . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 91 91 93
9.1. Formato del mensaje CADISCOVER . . . . . . 9.2. Formato del mensaje CERTREQ . . . . . . . . 9.3. Formato del mensaje CERTREPLY . . . . . . 9.4. Formato del mensaje CERTRENEW . . . . . . 9.5. Formato del mensaje AUTH MESSAGE . . . . 9.6. Formato del mensaje AUTH MESSAGE FINISH 9.7. Formato del mensaje AUTH MESSAGE FINISH 9.8. Formato del mensaje AUTH MESSAGE FINISH 9.9. Generacin de la rma . . . . . . . . . . . . o 9.10. Formato del mensaje rma . . . . . . . . . 9.11. Formato del paquete de OLSR rmado . . . 9.12. Firma + Encripcin de un paquete . . . . . o 9.13. Formato del mensaje rma con timestamp . 9.14. Etapas del protocolo OLSR . . . . . . . . .
. 100 . 101 . 101 . 103 . 104 . 105 . 107 . 107 . 108 . 109 . 110 . 111 . 113 . 114 . 118 . 120 . 122 . 123 . 124
10.1. Principales mdulos del simulador . . . . . . . . . . . . . . . o 10.2. Diagrama de Clases para los mensajes del protocolo . . . . . 10.3. Diagrama de Secuencia para la rma de un CertReq . . . . . 10.4. Diagrama de Secuencia de la obtencin de un certicado . . . o 10.5. Instanciacin de mdulos dependiendo el modo de operacin . o o o
INDICE DE FIGURAS
va
INDICE DE FIGURAS
10
Cap tulo 1
Introduccin o
El mundo de las telecomunicaciones crece d a d poniendo en nuestras manos distintas a a alternativas de comunicacin. En estos ultimos tiempos el avance de la tecnolog ha puesto a o a disposicin del usuario nal tecnolog tan potentes como una mquina de escritorio en diso as a positivos de bolsillo. Estos dispositivos no son utiles o la mayor de sus utilidades no estn a a disponibles si no estn conectados a alguna red. La necesidad de interconectar estos dispositivos a es la causante de que la industria de las comunicaciones crezca tanto. Los dispositivos mviles sern pronto el mtodo preferido de acceso a la informacin. Las coo a e o municaciones de estos dispositivos se hacen de manera inalmbrica, brindando mayor comodidad a al usuario y pudiendo conectarse en cualquier lugar. Las conexiones inalmbricas se hacen sobre a WLAN (Wireless Local Area Network) bajo el estndar 802.11. Este estndar permite dos modos a a de operacin, uno es modo infraestructura y otro es modo ad-hoc. En modo infraestructura todos o los clientes de la red deben conectarse a un punto de acceso jo. En modo ad-hoc la comunicacin se hace directamente de dispositivo a dispositivo sin pasar por un punto de acceso jo. Esta o propiedad hace que las redes ad-hoc sean exibles y rpidas de desarrollar. a A medida que la demanda de conexiones crezca, stas van a ser ms necesarias, incluso en e a lugares donde no exista una infraestructura para hacerlo. En este punto es donde entran en juego las redes ad-hoc, las cuales brindan una manera gil para congurar una red autnoma. a o Si bien la aplicacin de este tipo de redes est pensada para un ambiente donde haya un gran o a nmero de dispositivos, y hoy en d ser dif pensar un uso, en poco tiempo ms podr u a a cil a amos utilizar este tipo de redes por ejemplo para conectar todos los automviles que circulan en una o autopista y en caso de haber un accidente todos los conductores se enterar y podr evitar an an congestiones utilizando desv os. Pensando en el futuro cuando todas las personas tengan un dispositivo mvil, el uso de estas redes quedar limitada a la imaginacin y la creatividad. o a o Como cualquier red inalmbrica, las redes ad-hoc estn expuestas a ataques de cualquier a a persona ya que el medio f sico de propagacin es el aire. Las redes en modo infraestructura o cuentan con la ventaja de que todo el trco pasa por un punto de acceso jo en el cual se a pueden aplicar diferentes tcnicas y procedimientos de seguridad. Por el contrario, en las redes e ad-hoc, los mismos protocolos son los encargados de garantizar la seguridad de la red. 11
1.1. Motivacin o
1.1.
Motivacin o
Ya hace un tiempo que me he visto atra por la tecnolog WiFi, la cual pertenece al do a estndar 802.11. Luego de hacer distintas pruebas, armar diferentes antenas, probar diferentes a dispositivos es que me vi interesado por las redes ad-hoc y en particular las redes ad-hoc donde los participantes de la misma estuviesen en movimiento. Otro aspecto importante por el que siento curiosidad es por la seguridad en las redes inalmbricas. Por otro lado, no existe ningn a u estndar sobre este tipo de redes, lo cual hace que una investigacin y anlisis de los borradores a o a elaborados hasta el momento pueda hacer un aporte para la construccin de los protocolos. Estas o inquietudes sumadas al potencial uso de estas redes fueron los motivadores de esta tesis.
1.2.
Objetivo
El objetivo de la tesis es analizar las opciones y proponer alternativas para brindar seguridad en una red mvil urbana basada en el protocolo OLSR. o El protocolo OLSR se utiliza en el proyecto BAL (Buenos Aires Libre) y en proyectos de redes mviles urbanas en todo el mundo por lo que la aplicacin de su estudio y anlisis de securizacin o o a o tiene un uso potencial signicativo. En el desarrollo de la tesis se analizarn protocolos de ruteo de redes mviles, se realizarn a o a comparaciones entre los mismos dando especial nfasis en los aspectos de seguridad con el objetivo e de tomar ideas para realizar el diseo de un protocolo OLSR seguro. n Se estudiar y detallar como funciona una red mvil basada en OLSR, principales tcnicas a a o e de ataque y posibles alternativas de prevencin. o Del anlisis de los protocolos de ruteo existentes, se propondr la manera de mejorar la a a seguridad de una red mvil urbana, en particular para una topolog similar a la de BAL. o a Para lograr este objetivo se trabajar en un esquema de arquitectura de seguridad de acuerdo a al uso de la red y al grado de participacin de los nodos en la misma. o La tesis tendr en mente lograr mejorar la capacidad del protocolo de obtener disponibilidad, a integridad, condencialidad, autenticacin y no repudio de sus paquetes de control. o
12
Cap tulo 2
Redes Mviles o
El objetivo del presente cap tulo es dar una introduccin a las Redes Mviles o o y presentar los principales protocolos de ruteo para dar un marco terico al lector o y conocer distintas alternativas para un mismo objetivo, rutear nodos en un Red Mvil. o
Dentro del mundo de las redes las conguraciones ms conocidas son: a Redes Fijas: son aquellas redes donde los componentes que la integran son jos y estn a interconectados generalmente por cable. Redes Inalmbricas: en esta categor se encuentran las redes donde sus componentes a a podr estar en movimiento pero siempre conectados de manera inalmbrica a un punto an a jo o las redes ad-hoc, en las cuales los integrantes de la red se comunican entre s mediante una conexin inalmbrica. Por ultimo y dentro de la categor de las redes inalmbricas o a a a (ad-hoc) estn las Redes Mviles (MANETs, Mobile ad-hoc NETwoks). Este tipo de redes a o es el que analizaremos en detalle.
2.1.
Generalidades
Las MANETs son redes donde los nodos o integrantes de la red se mueven. Por esta razn, los o protocolos de ruteo existentes para redes jas no funcionan, ya que es necesario que la topolog a de la red se vaya cambiando dinmicamente. En estas redes, el concepto de Servidor utilizado a en una red ja cambia ya que en stas siempre logramos conectarnos, en cambio en una red con e estas caracter sticas no siempre se puede acceder a un nodo, con lo cual en una MANET podr a no haber DNSs o Entidades Certicantes (CAs), etc. 13
2.2. Protocolos de Ruteo
2.2.
Protocolos de Ruteo
El ruteo en la redes mviles ha sido un desaf ya que la naturaleza de la red tiene muchas o o, variables (tamao, disposicin de los nodos, uso del ancho de banda, ahorro de energ etc) que n o a, son muy dif ciles de ser contempladas por todos los protocolos. Protocolos como los utilizados en redes jas (Distance-Vector o Link-State) no se pueden utilizar en las redes mviles ya que la informacin de la distancia de los integrantes de la red o o var con gran frecuencia. Esto insumir mucho ancho de banda y bater de los dispositivos a a a mviles para mantener esa informacin actualizada en cada nodo. o o Para disear un protocolo para redes ad-hoc se deber tener en cuenta las siguientes cuestiones n a [1, Chap. 10.1]: M nimo overhead de paquetes de control: Si se disminuye el nmero de paquetes de control, u se ahorra ancho de banda y bater en los dispositivos. a M nimo tiempo de procesamiento: Los algoritmos elegidos tienen que ser simples, as de esta manera no se insume tiempo de bater en procesamiento. as Capacidad de ruteo con mltiples saltos: Como los dispositivos muchas veces no tienen u transmisin directa, se requiere que stos se puedan comunicar a travs de un tercero que o e e s est en el rango de transmisin directa. a o Mantenimiento dinmico de la topolog Una vez que se tiene establecida una ruta es muy a a: comn por la caracter u stica de la red que se pierda el v nculo, ya sea con el destino o entre algunos dispositivos que ayudan en el trayecto. Por lo tanto el protocolo tiene que solucionar las prdidas de conexin con un overhead m e o nimo. Prevencin de bucles: Se forma un bucle cuando se arma una ruta que elige como prximo o o nodo uno que existe dentro de la ruta calculada hasta el momento. Los bucles hacen que los datos y los paquetes de control pasen y sean procesados innecesariamente por un nodo muchas veces. Modo de operacin inactivo: El protocolo debe estar preparado para que en per o odos donde la actividad de la red baje sea capaz de dormirse y de esta manera consumir menos energ a. Durante la evolucin de las MANETs se han desarrollado muchos protocolos teniendo en o cuenta las cuestiones listadas anteriormente. En las siguientes secciones ( 2.3.1, 2.3.2, 2.3.3) se va a desarrollar la presentacin de distintos protocolos, clasicados en distintos grupos segn su o u forma de generar las rutas. Luego se vern distintos protocolos que logran tener redundancia de a las rutas para minimizar los tiempos de rearmado de la ruta en caso de la prdida de la misma e ( 2.3.4).
14 Juan Manuel Caracoche - Tesis de grado Ingenier Informatica a
Redes Mviles o
Figura 2.1: Clasicacin de protocolos de ruteo o
2.3.
Protocolos de Ruteo Proactivos, Reactivos e H bridos
Los protocolos de ruteo para Redes Mviles tiene sus bases sobre los protocolos de redes cao bleadas. Como fu comentado anteriormente (2.2) estos protocolos necesitan intercambiar mucha e informacin para mantener las rutas haciendo que sea imposible ser implementados en un amo biente tan cambiante y con enlaces tan poco estables como los de las Redes Mviles. Para superar o los problemas asociados a los algoritmos Link-State y Distance-Vector se han desarrollado una variedad de protocolos los cuales se pueden clasicar como lo indica la Figura 2.1 [2]. En los protocolos proactivos las rutas hacia todos los destinos de la red (o gran parte de ella) son calculadas al principio y luego se mantiene utilizando procesos de actualizacin peridicos. En los protocolos o o reactivos las rutas son calculadas en el momento que son requeridas utilizando un procedimiento de descubrimiento hacia el destino. Los protocolos h bridos combinan las propiedades bsicas de a cada uno de las otras dos clases de protocolos.
2.3.1.
Protocolos de Ruteo Proactivos
Los protocolos de ruteo proactivos [2, Sec. 2] o basados en tablas son aquellos que mantienen la informacin acerca de cmo llegar a todos los destinos (nodos) de la red. Esta informacin es o o o almacenada en tablas las cuales son actualizadas peridicamente cuando hay modicaciones en o la topolog de la red. a La diferencia entre los distintos protocolos de esta clase es la manera en la que actualizan las tablas, la cantidad de tablas que utilizan, la informacin de cada tabla y la manera de encontrar o la informacin. Los protocolos ms importantes en esta clase son: o a Destination Sequenced Distance Vector (DSDV): Basado en el algoritmo Distance-Vector. Optimized Link State Routing (OLSR): Basado en el algoritmo Link-State. .
Juan Manuel Caracoche - Tesis de grado Ingenier Informatica a 15
2.3.1. Protocolos de Ruteo Proactivos
2.3.1.1.
Destination-Sequenced Distance-Vector (DSDV)
El protocolo de ruteo de Destination-Sequenced Distance-Vector (DSDV) es un protocolo proactivo de Distance-Vector. Este protocolo est basado en el clsico protocolo de Distancea a Vector de Bellman-Ford (DBF) [4] modicado para prevenir lazos cerrados (loops). Este protocolo sirve para encontrar a partir del algoritmo de Distance-Vector cul es el camino ms corto a a hasta llegar al destino [3, Sec. 3]. El DSDV por ser un algoritmo proactivo mantiene una tabla con todos los destinos posibles de la red y la cantidad de saltos para llegar a cada uno. Cada entrada en esta tabla est etiquetada con un nmero de secuencia el cual es generado por el nodo a u destino. La tabla contiene los siguientes datos: Direccin IP destino o Nro de secuencia de destino Direccin IP del prximo salto hacia el destino o o Nro de saltos hasta el destino Time stamp Esta tabla debe ser mantenida peridicamente para actualizar los cambios que puedan suceo derse en la red. Estas actualizaciones se realizan a travs de mensajes broadcast o multicast. Los e datos enviados por cada nodo contienen su nuevo nmero de secuencia y la informacin referente u o a cada nueva ruta. Cuando el destino recibe esa informacin actualiza sus propias tablas de ruteo. o Las tablas de ruteo tambin son enviadas si se detecta algn cambio en la topolog Los nodos e u a. utilizan los nmeros de secuencia de destino para poder distinguir entre rutas antiguas y rutas u nuevas hacia un mismo destino. Un nodo incrementa su nmero de secuencia cuando se produce u un cambio a nivel local en la topolog de sus vecinos. La ruta hacia el destino que tenga el a nmero de secuencia ms grande (ms reciente) ser la elegida. En caso que existan dos rutas u a a a con el mismo destino y mismo nmero de secuencia, ser elegida la que tenga menos saltos hacia u a el destino. En la redes con gran cantidad de nodos se generar muchas colisiones en el trco an a broadcast (storm of broadcast), para ello el protocolo utiliza dos tipos de paquetes para actualizar la informacin: o full dump: Transporta la informacin de todas las rutas. o incremental : Transporta slo la informacin de las rutas nuevas (variacin desde un full o o o dump) Los paquetes incrementals, por razones de diseo deben entrar dentro de una unidad de datos n de protocolo (NPDU-Network Protocol Data Unit). Cuando las actualizaciones de las rutas son varias y el tamao de dicha informacin se acerca al tamao de la NPDU, el prximo paquete n o n o ser un full dump. De esta manera se optimiza el env de paquetes. Sin embargo este protocolo a o no podr escalar hacia grandes redes ya que requiere de un env de paquetes de O(N 2 ), donde a o N es el nmero de nodos de la red. Se podr dar el caso que un nodo reciba informacin de ruteo u a o
Redes Mviles o
sobre un destino que es mejor que la que tiene por lo que, ste informar a sus vecinos antes de e a recibir todos los mensajes de actualizacin de la ruta. Por esto es que DSDV tiene un mecanismo o para mitigar este tipo de comportamiento que consiste en establecer un tiempo jo para informar los cambios. Este tiempo es calculado como el tiempo promedio que tarda en recibir el nodo todos los paquetes de actualizacin de una ruta. De esta manera el nodo se asegura de enviar la o informacin de la nueva ruta luego que recibi todos los paquetes de actualizacin y disminuye o o o el uso de ancho de banda y consumo de energ de los vecinos. a 2.3.1.2. Optimized Link State Routing (OLSR)
El protocolo Optimized Link State Routing (OLSR) [1, Sec. 10.2] es un protocolo de ruteo proactivo basado en el protocolo Link-State. La principal caracter stica es que utiliza multipoint relays (MPRs) para minimizar el ooding en la red y la cantidad de links que se deben mantener. Cada nodo de la red elige un conjunto de nodos a los cuales los marca como MPRs, el resto de los vecinos reciben los mensajes pero no los reenv an. Slo los MPRs reenv los mensajes. El o an nodo debe elegir a los MPRs, de manera tal de llegar a travs de stos a todos los vecinos que e e estn a dos saltos de distancia. En la Figura 6.8 se ve que el nodo O elige los nodos 1, 2, 4 y 5 a ya que a travs de ellos puede llegar a todos los vecino de dos saltos de distancia. e
Figura 2.2: Multipoint Relays
Eleccin de los Multipoints Relays El mecanismo de seleccin de los MPRs [6, Sec. 4.2] se o o realiza mediante el intercambio de mensajes de HELLO. Un mensaje de HELLO es el mensaje que se utiliza en OLSR para validar el estado de los enlaces de un nodo con su vecino. El mensaje contiene una lista de los nodos con los cuales se tiene un enlace bidireccional y una lista de direcciones de vecinos de los cuales se ha recibido un mensaje de HELLO. Un enlace es unidimensional cuando un nodo recibe un mensaje de HELLO, pero si en ese mensaje gura su direccin en la lista de direcciones de vecinos hace que ese enlace sea bidireccional y lo almacena o en la tabla neighbor table. El algoritmo de seleccin de los MPRs es: o 1. Selecciona los nodos del Nivel 1 que cubren nodos aislados del Nivel 2. Nodo aislado es
2.3.2. Protocolos de Ruteo Reactivos
aquel nodo que pertenece al Nivel 2 y tiene como vecino a un solo nodo del Nivel 1. 2. Se toman los vecinos de Nivel 1 que no fueron seleccionados en el paso anterior y se selecciona el nodo que cubra el mayor nmero de nodos de Nivel 2. Esto se repite hasta que todos los u nodos de Nivel 2 hayan sido cubiertos. El conjunto de MPRs son recalculados cada vez que hay algn cambio en los enlaces con los u vecinos. Clculo de la tabla de ruteo Cada nodo necesita armar su propia tabla de ruteo. Para ello, a utiliza mensajes de control llamados Topology Control (TC). Estos mensajes son distribu dos por la red utilizando broadcast. Cada MPR env mensajes TC informando cuales nodos lo han a elegido a l como MPR (informa su MPR Selector ). e La informacin difundida por la red a travs de los TC ayudan a cada nodo a armar su tabla o e de topolog (topology table). Esta tabla existe en todos los nodos de la red y es utilizada para a establecer las rutas. Cada entrada en la tabla de topolog contiene la direccin de un potencial a o destino, la direccin del ultimo salto a ese destino (origen del mensaje TC ) y el nmero de o u secuencia correspondiente al nodo que envi el mensaje. Cada entrada en la tabla de topolog o a tiene un timestamp para vericar la validez de la misma. Para el armado de la tabla de ruteo, el nodo utiliza tanto la tabla de vecinos como la tabla de topolog en esta ultima utiliza la direccin de ultimo salto para armar el recorrido comenzando a, o por el destino y luego recorrer la tabla en orden descendente para armar el camino. Por ejemplo si se quiere unir un punto remoto R, primero se busca el par (X, R), luego el par (Y, X) y as hasta completar la ruta. En el momento del armado de la ruta se controlan los nmeros de secuencia u para detectar cambios en la topolog y as invalidar rutas. Como la tabla de ruteo depende de a la tabla de vecinos y de la tabla de topolog cualquier cambio en alguna de ellas implica la a, reconstruccin de las rutas. o Cada entrada en la tabla de ruteo contiene la direccin del destino, la direccin del prximo o o o salto y el nmero de saltos. u
2.3.2.
Protocolos de Ruteo Reactivos
Los protocolos de ruteo reactivos [1, Sec 10.3] son aquellos que construyen las rutas bajo demanda, es decir en el momento en el que un nodo origen necesita enviar un mensaje a un nodo destino se crean las rutas desde el origen al destino. Con este tipo de protocolos se optimiza el uso de recursos de ancho de banda y el uso de bater pero por otro lado se penaliza la latencia a en encontrar la ruta. Cuando un nodo quiere enviar un mensaje y la ruta hacia el destino no existe comienza el procedimiento de descubrimiento con un mensaje de peticin de ruta (Route Request) de tipo o broadcast y recibir un mensaje de respuesta con la ruta (Route Reply). Si el mensaje de peticin a o de ruta viaj por un links bidireccionales, el mensaje Route Reply puede utilizar la misma ruta o entonces el overhead introducido por el descubrimiento (en el peor de los casos) crecer con a O(N + M ) [2] donde N es el la cantidad de nodos de la red y M es el nmero de nodos en el u
Redes Mviles o
camino de vuelta con la respuesta. Cuando los enlaces son unidireccionales el overhead introducido es de O(2N ). Los protocolos reactivos pueden clasicarse en dos categor a: Basados Ruteo del origen (source routing): En esta modalidad cada paquete de datos transporta en su cabecera la ruta completa desde el origen al destino, es decir, todas la direcciones de los nodos intermedios. Cada nodo intermedio utilizar la cabecera del mensaje para saa ber donde reenviarlo, de esta manera no es necesario que cada nodo mantenga una tabla con las rutas como en los protocolos proactivos. Por otro lado este tipo de protocolos no es recomendado para redes mviles grandes donde haya mucha movilidad de los nodos ya que o es ms probable que los enlaces se rompan y al haber tanta cantidad de nodos las cabeceras a de los mensajes van a ser muy grandes. Basados en salto a salto (hop-by-hop): En esta modalidad cada paquete lleva la direccin o del destino y la del prximo salto, de forma tal que cada nodo intermedio deber consultar o a su tabla de ruteo para saber donde va a reenviar el paquete. La ventaja de esta estrategia es que las rutas se adaptan dinmicamente a medida que a cambia la red. La desventaja es que cada nodo intermedio debe almacenar y mantener la informacin de cada una de rutas mediante el intercambio de mensajes con sus vecinos. o Los protocolos ms importantes en esta clase son: a Ad hoc on-demand distance vector (AODV): Basado en DSDV Dynamic Source Routing (DSR) . 2.3.2.1. Ad hoc on-demand distance vector (AODV)
EL protocolo AODV es un protocolo basado en ruteo salto a salto (hop-by-hop routing) [7]. Este protocolo permite el armado de las rutas bajo demanda, es decir cada nodo no mantiene las rutas a todos los destinos de la red sino que solo mantiene las rutas necesarias para alcanzar un destino en particular. AODV presenta las siguientes caracter sticas: Bajo overhead : Al no realizarse actualizaciones peridicas de la informacin de todos los o o nodos, se garantiza un m nimo uso de ancho de banda para los paquetes de control. Bajo overhead de procesamiento: Los mensajes enviados son cortos y no requieren mucho clculo. a Previene la formacin de bucles: Provee un mecanismo para la prevencin de formacin de o o o bucles utilizando nmeros de secuencia en los mensajes. u Tipo de mensajes de control que utiliza AODV:
RREQ (Route Request): Mensaje que se env cuando se necesita una ruta. a RREP (Route Reply): Mensaje de respuesta a la solicitud de una ruta. RERR (Route Error): Este mensaje se env cada vez que se detecta una rotura de enlace a y deja a un destino inaccesible. Con el n de prevenir bucles cada nodo mantiene un nmero de secuencia que sirve para u evaluar la vigencia de la informacin asociada a cada mensaje que env el nodo. El nmero de o a u secuencia aumenta en uno cada vez que un nodo env un mensaje RREQ. Si un nodo recibe a un RREQ donde el destino es el mismo, antes de generar el mensaje de respuesta RREP debe actualizar el nmero de secuencia Sec#D al valor mximo entre su nmero de secuencia actual u a u Sec#D actual y el nmero de secuencia del destino que se encuentra contenido en el RREQ u (RREQ.Sec#) ms uno. a Los nmeros de secuencia sirven para que siempre se seleccione la ruta mas reciente hacia un u destino. En el caso que un nodo intermedio tenga dos rutas hacia un destino y stas tengan un e mismo nmero de secuencia, escoger la que tenga la m u a nima cantidad de saltos. Descubrimiento de la ruta El descubrimiento de la ruta [8, Sec. 2.1] (Path Discovery) se inicia cuando un nodo necesita comunicarse con otro y no existe una entrada en su tabla de ruteo. Cada nodo mantiene dos contadores independientes: un nmero de secuencia del nodo u (node sequence number ) y un identicador para los paquetes broadcast (broadcast id ). Los pasos para el descubrimiento de la ruta son: El nodo origen inicializa el proceso de descubrimiento mediante la emisin de un mensaje o broadcast de tipo RREQ (route request) a sus vecinos (Figura 2.3(b)) El par < direccion origen, broadcast id > identica un vocamente al mensaje RREQ. El broadcast id se incrementa cada vez que el origen genera un nuevo mensaje RREQ Si alguno de los vecinos tiene una ruta hacia el destino solicitado, contesta con un mensaje RREP y en caso contrario reenv el mensaje RREQ a sus vecinos (Figura 2.3(c)) luego de a incrementar la cantidad de saltos. Como un nodo puede recibir muchas veces el mismo mensaje RREQ, descarta aquellos donde la direccin de origen y el broadcast id son iguales a los dos de o un mensaje recibido con anterioridad (Figura 2.3(d)). Cada vez que el nodo no puede satisfacer la ruta solicitada, guarda la informacin para luego o implementar el armado del camino reverso (reverse path) La informacin almacenada en esta tabla tiene un tiempo de vida limitado, cuando se cumple o ese tiempo la informacin es eliminada de la misma. La ruta inversa sirve para cuando el nodo o recibe un mensaje RREP (Figura 2.3(e)), ste es enviado hacia el origen a travs de esta ruta e e inversa. El mensaje RREP contiene la direccin IP del origen y el destino. o Este paquete es enviado al nodo origen a travs del nodo del cual provino el RREQ (Figue ra 2.3(g)) ya que este nodo tiene una ruta de camino inverso Cuando un nodo intermedio recibe un mensaje RREP incrementa el nmero de saltos del u mensaje RREP, inserta una entrada en la tabla de ruteo (Figura 2.3(h)). La entrada en la tabla
Redes Mviles o
utiliza al nodo origen del mensaje RREP como prximo salto hacia el destino. A este paso se lo o llama denir un Forward Path [9]. Si un nodo recibe ms de un mensaje RREP para un destino por parte de ms de un vecino, a a ste reenv el primer RREP. e a Cuando el nodo origen recibe un mensaje RREP ya puede comenzar a utilizar la ruta para enviar datos. En el caso que el nodo origen reciba ms de una ruta hacia el destino, ste a e utilizar aquella que tenga menor nmero de saltos y el mayor nmero de secuencia del destino. a u u De esto se puede observar que AODV no siempre calcula la menor ruta en cuanto a saltos ya que el hecho de descartar los RREQ que lleguen luego de un RREQ que tienen igual campo o bradcast id y direccin IP del nodo origen hace que rutas probablemente mas cortas no se lleguen a descubrir, pero entre las rutas calculadas se elige la ms corta. a
Mantenimiento de la Ruta El movimiento de los nodos puede hacer que se rompan los enlaces y de esta manera hacer que la ruta no pueda ser utilizada. AODV env peridicamente mensajes de hello (es un mensaje RREP especial ya que no a o es respuesta de un RREQ) para asegurarse que los enlaces simtricos estn utilizables. Este e e mensaje de hello contiene la direccin IP del nodo, su nmero de secuencia (no cambia el nmero o u u de secuencia con el env de estos mensaje) y el tiempo de vida del enlace. Si se recibe un mensaje o de hello de un nuevo vecino o no se recibe un mensaje de un nodo que pertenec al vecindario a se asume que hubo cambios entre los vecinos. Para garantizar que el enlace sea simtrico o e bidireccional env un RREP y luego espera un RREP-ACK, si no se recibe el RREP-ACK el a nodo pone en su blacklist (lista negra) al nodo vecino e ignora los prximos RREQs debido a la o unidireccionalidad del enlace. Cuando el nodo detecta la rotura de la ruta, la invalida y env un mensaje RERR. En este a mensaje se env todos los destinos que ya no pueden ser alcanzados. En el caso que haya nodos a intermedios entre el nodo origen y el nodo que detect la ruptura y stos estaban utilizando el o e enlace, el mensaje RERR se propaga en modo broadcast sino unicast. Cuando un nodo recibe un mensaje RERR, ste verica que el nodo del cual recibi sea el e o prximo salto hacia alguno de los destinos informados, luego marca la entrada en la tabla como o invlida y reenv el mensaje RERR hacia el origen. Una vez que el origen recibe el mensaje a a RERR, puede decidir reiniciar un proceso de bsqueda de una nueva ruta en caso que la necesite. u Una de las caracter sticas de AODV es que cuando detecta una rotura de enlace, el nodo no env un RERR en ese momento sino que reintenta reconstruir el enlace generando un RREQ a previo incremento del nmero de secuencia. En el caso que no pueda restablecerlo env el RERR u a al origen. Otra caracter stica que se incorpora al protocolo en los ultimos draft de Internet [7] es que en cada mensaje de RREQ o RERR adicionan en la cabecera la ruta, de esta manera los nodos que reciben mensajes de este tipo aprenden rutas no solo hacia el origen o hacia el destino sino hacia otros nodos de la red.
(a) El origen 1 quiere enviar datos a 10
(b) El nodo 1 env un mensaje RREQ a sus a vecinos
(c) Los nodos 2, 3 y 4 reciben RREQ y los propagan a sus vecinos
(d) Se contina la propagacin. Notar que 3 no u o reenv el RREQ porque ya lo recibi antes a o
(e) Se contin a la propagacin. 5 no propaga u o RREQ
(f) Se llega al nodo 10 y ste no reenv el e a RREQ porque es el destino
(g) 10 determina la ruta para enviar RREP
(h) En cada salto que hace RREP, se establece una ruta hacia el destino. Se completa la ruta cuando llega a 1
Figura 2.3: Ejemplo de la construccin de una ruta en AODV o

Redes Mviles o
2.3.2.2.
Dynamic Source Routing (DSR)
El protocolo Dynamic Source Routing (DSR) [10] es un protocolo simple y eciente diseado n espec camente para redes inalmbricas de multiples saltos donde los nodos de la misma estn a a en continuo movimiento. El protocolo est compuesto por dos mecanismos principales de Desa cubrimiento de la Ruta(Route discovery) y Mantenimiento de la Ruta(Route Maintenance), los cuales trabajan en conjunto. Algunas caracter sticas del protocolo son: Bajo Overhead : por ser un protocolo bajo demanda, solo se env overhead cuando es a necesario. No se utiliza mensajes de control (hello messages) Multiples Rutas a un mismo destino y el nodo origen puede decidir y controlar el uso de las rutas. Loop Free: garantiza de manera fcil y poco costosa la generacin de lazos. a o Enlaces unidireccionales: puede funcionar con enlaces unidimensionales. Rpido Recupero: recupero rpido de la ruta ante un cambio en la red. a a escalabilidad esta diseado para operar en redes de cientos de nodos y con gran movilidad n Si bien DSR es similar a AODV, sin embargo existe una diferencia muy grande y es que DSR es un protocolo basado en ruteo desde el origen (source routed ) en vez de ser un protocolo de salto en salto (hop-by-hop) donde cada paquete de datos sabe exactamente por que nodos va a pasar hasta llegar al destino. Descubrimiento de la Ruta El mecanismo de descubrimiento de la ruta [11, Sec 3.2], hace uso de un cach donde se almacenan todas las rutas descubiertas para un destino. Cuando el e nodo desea enviar un paquete a un nodo destino primero busca en el cach si existe alguna ruta y e la utiliza, en caso de que la ruta falle, puede utilizar otra ruta del cach. De esta manera previene e el descubrimiento de una nueva ruta y acelera el proceso del env del paquete en caso de una o falla. El mecanismo de descubrimiento comienza cuando un nodo quiere enviar un paquete a un destino y no existe ninguna ruta en el cach. El nodo origen env un mensaje RREQ (Route e a Request) con la direccin del nodo origen (Figura 2.5(b)), la direccin del nodo destino y un o o identicador de RREQ. Un mensaje RREQ adicionalmente contiene las direcciones de todos los nodos intermedios que han reenviado el mensaje. Cuando un nodo vecino recibe el mensaje RREQ busca en su cache si no tiene una ruta hacia el destino solicitado, en caso que as sea env un a mensaje RREP (Route Reply) que contiene una copia de la ruta al destino y le concatena la ruta acumulada que tra el RREQ (Figura 2.5(c)). En caso que el mensaje lo reciba el nodo destino, a ste env un RREP con la ruta que se acumul en el RREQ desde el origen hasta el destino. e a o Si el nodo que recibe el RREQ no es el destino y no tiene una ruta hacia el destino, verica si ya ha recibido un mensaje con el mismo origen, mismo destino y mismo identicador de RREQ o bien si su direccin est en el registro de ruta del mensaje RREQ. En este caso y con el n de o a limitar el nmero de mensajes RREQ que viajan por la red, ste es descartado (Figura 2.5(d)). u e
Por lo tanto los RREQs que se propagan durante el descubrimiento son los primeros en llegar a un determinado nodo. Si se elige como ruta ptima la ruta del primer RREP que llegue al origen, o se puede asegurar que esa ruta es, en ese momento, la ms rpida para alcanzar al destino. Si a a no se cumplen ninguna de las condiciones, el mensaje es retransmitido pero el nodo agrega su direccin al registro de ruta. o Cuando un nodo debe devolver un mensaje RREP hacia el origen, se ja en su cach si e tiene una ruta hacia el origen, en caso que la tenga la utiliza, en caso contrario el nodo destino deber comenzar su propio mecanismo de descubrimiento, pero para evitar una recursin innita a o de bsquedas de rutas, el nodo destino deber hacer piggyback (ponerlo al nal) del mensaje u a RREP en su propio RREQ. En el caso que se utilicen enlaces simtricos, el nodo destino puede e utilizar la ruta recibida dentro del RREQ para hacer el camino inverso (Figura 2.5(e)). Para los escenarios donde se utilizan protocolos de MAC como por ejemplo IEEE 802.11 que requieren un intercambio bidireccional de tramas como parte del protocolo MAC garantizando enlaces bidireccionales, se utiliza la tcnica de enviar el RREP a travs de la ruta incluida en el RREQ e e ya que es lo ms adecuado para evitar el overhead de descubrir una nueva ruta. El protocolo a MAC adems prueba que la ruta sea bidireccional antes de comenzar a utilizarla. Como DSR a est pensado para redes inalmbricas y muchas veces el enlace unidireccional es la unica manera a a de conectividad, este protocolo tambin puede hacer descubrimiento de rutas en estas condiciones. e Cuando un nodo origen recibe un mensaje RREP, almacena la ruta contenida en el mensaje en su cach para comenzar a enviar datos (Figura 2.5(g)). De esta manera un nodo origen puede e recibir mltiples rutas (Figura 2.5(f)) , las cuales son almacenadas para prevenir un descubriu miento de ruta en caso que una deje de estar disponible. Una caracter stica que destaca a DSR de los otros protocolos reactivos es que las rutas no tienen un tiempo de vida, son utilizadas hasta que se reciba un mensaje indicando que la ruta no est disponible. Esto hace que si los nodos a permaneces relativamente estticos el overhead generado por el descubrimiento es cero. a Los nodo intermedios cada vez que reciben un mensaje RREQ o RREP pueden crear o actualizar sus tablas con las rutas recibidas en los mensajes. Tambin se puede activar una opcin e o llamada promiscuous listening [1, Sec 10.3.2] que le da la posibilidad al nodo de escuchar tanto los paquetes de datos como los de control a nivel MAC y as aprender rutas hacia otros nodos de la red.
Figura 2.4: Deteccin de un enlace roto y env del RERR o o
24
Redes Mviles o
(a) El origen 1 quiere enviar datos a 10
(b) El nodo 1 env un mensaje RREQ a sus a vecinos especicando en la ruta su direccin o
(c) Los nodos 2, 3 y 4 reciben RREQ y los propagan a sus vecinos concatenando su direccin o en la ruta (a los efectos del ejemplo no se especica la ruta enviada por 2)
(d) Se contin a la propagacin. Notar que 3 no u o reenv el RREQ porque ya lo recibi antes a o
(e) El RREQ llega al destino 10 y este no lo retransmite y arma el RREP y lo env al destino. a 9 contina la propagacin del RREQ u o
(f) Llega el segundo RREQ al nodo 10, arma un nuevo RREP y lo env al origen a
(g) 1 recibe los RREP y elije enviar los datos por la primer ruta que recibe
Figura 2.5: Ejemplo de la construccin de una ruta en DSR o

2.3.3. Protocolos de Ruteo H bridos
Mantenimiento de la Ruta Cuando un nodo transmite o reenv un mensaje, ste debe a e asegurarse que fue entregado al prximo salto [11, Sec 3.3] (se puede denir un nmero mximo o u a de reintentos en el env del paquete). Esta conrmacin de recepcin muchas veces es gratuita o o o para DSR cuando utiliza por debajo un protocolo de MAC como el de IEEE 802.11 ya que el protocolo MAC es el encargado se asegurarse el env con la trama link-level acknowledgement. o Si este mecanismo no est disponible, se congura un bit indicando a DSR que se necesita una a conrmacin a nivel protocolo DSR. Es muy probable que si esta opcin est especicada es o o a porque no se est trabajando sobre un protocolo MAC como el especicado anteriormente o se e tengan enlaces unidireccionales, con lo cual la respuesta puede viajar a travs de otra ruta. e Si un paquete es reenviado un nmero mximo de veces y no se recibe respuesta, el nodo u a retorna un mensaje de error llamado RERR indicando a travs de que enlace no se pudo enviar e el paquete (Figura 2.4). Cuando el nodo origen recibe este mensaje marca la ruta como invlida a e intenta utilizar otra de las rutas de su cach, en caso de no tener ninguna inicia un nuevo e mecanismo de descubrimiento.
2.3.3.
Protocolos de Ruteo H bridos
Las caracter sticas de los protocolos de ruteo reactivos y proactivos pueden combinarse de varias maneras y dan lugar a los protocolos de ruteo h bridos. Un protocolo h brido utiliza caracter sticas de los protocolos reactivos y proactivos dependiendo las circunstancias. Uno de los principales ejemplos es el protocolo Zone Routing Protocol. 2.3.3.1. Zone Routing Protocol (ZRP)
ZRP [12, Sec II] es un ejemplo de un protocolo de ruteo h brido. Por un lado limita el alcance de un protocolo proactivo para los nodos de su vecindad. Por otro lado utiliza el mecanismo de descubrimiento de ruta de un protocolo reactivo para buscar nodos ms all de su vecindario. El a a protocolo identica diferentes rutas sin caer en un bucle capaces de alcanzar un destino, de esta manera hace que sea ms conable y performante. a Cada nodo dene un radio que es medido en cantidad saltos. Cada nodo utiliza un protocolo proactivo en su zona y uno reactivo fuera de ella. De esta manera un nodo conoce a todos sus vecinos de sus zona y todas las rutas hacia ellos. Cuando un nodo quiere enviar un paquete de datos primero busca en su tabla de rutas una ruta hacia el destino, si el destino pertenece a su zona la ruta la tiene. Si el destino no est en su zona, comienza a buscar una ruta hacia el destino. a ZRP utiliza un protocolo para ruteo dentro de la zona, este protocolo se llama Intra Zone Routing Protocol (IARP) [1, Sec 10.5.1]. IARP es un protocolo basado en el protocolo Link-State que mantiene actualizada la informacin de todos los nodos dentro de la zona. En la Figura 2.6 o se puede ver un ejemplo la denicin de una zona de un salto para el nodo O y como es una zona o de un salto de distancia quedan denidos automticamente los nodos frontera o perifricos (A, B, a e C). ZRP utiliza para el ruteo de paquetes fuera de la una zona un protocolo llamado Interzone Routing Protocol (IERP). Este protocolo incorpora el trmino bordercasting. Cuando un nodo e determina que el nodo al que le quiere enviar un paquete est fuera de su zona, el nodo origen a
Redes Mviles o
Figura 2.6: Zona de un nodo usando ZRP
hace un bordercast del pedido de ruta. El trmino bordercast no es ms que enviar un mensaje e a directamente al nodo frontera para que ste luego haga el descubrimiento de la ruta. e El nodo frontera cuando recibe un mensaje de solicitud de ruta, verica si el destino est en a su zona, en caso que no est reenv el pedido a cada uno (uno por vez) de sus nodos frontera. e a Este procedimiento contina hasta que se localice el destino o hasta que se examina toda la red. u Cuando un nodo encuentra al destino, ste env un mensaje unicast hacia el origen. e a
Figura 2.7: Descubrimiento de una ruta con IERP
En la Figura 2.7 se ilustra un pedido de ruta utilizando IERP. En la gura, el nodo O hace una bsqueda de la direccin del nodo E. Utilizando IARP, se sabe que no est dentro de su zona, u o a por lo tanto hace un bordercast del requerimiento a los nodos perifricos. Los nodos perifricos, e e uno por vez, chequean su zona en busca de la direccin solicitada (los circulo slidos representan o o las zonas hacia donde se envi el requerimiento). En caso que no est en su zona, reenv el pedido o e a a sus nodos perifricos. En la gura, cuando le llega el pedido al nodo D, ste encuentra en su e e zona al nodo E y env una mensaje unicast hacia el nodo O con la respuesta. a ZRP tiene varios parmetros y tcnicas para mejorar su performance y para prevenir la a e propagacin de una bsqueda cuando sta ya ha sido contestada por algn nodo. ZRP incorpor e o u e u o su versin 2 (ZRPv2) una manera diferente a las hora de hacer bordercasting. ZRPv2 hace que el o nodo origen construya un rbol hacia los destinos que no pertenecen a su zona. En ese rbol y como a a primer hijo se encuentran los nodos perifricos. Cuando un nodo perifrico recibe una consulta, e e
2.3.4. Tcnicas de Ruteo e
primero construye su propio rbol. Este procedimiento se repite hasta alcanzar el destino. a
2.3.4.
Tcnicas de Ruteo e
Todos los protocolos antes descriptos, en su mayor fueron concebidos para lograr mantener a, una ruta hacia el destino. En muchos escenarios donde la red es mediana a grande y donde los nodos pueden tener mucha movilidad, estas rutas podr sufrir modicaciones cont an nuas y llevar a los nodos a estar continuamente ejecutando procedimientos de descubrimiento de a ruta. Para subsanar esta situacin existen variaciones de los protocolos originales que proveen o redundancia de rutas. A estos protocololos se los conoce como Ruteo Multicamino (Multipath Routing). 2.3.4.1. Multipath Routing
En la mayor de los protocolos vistos en este cap a tulo, los nodos registran las rutas hacia los distintos destinos en tablas de ruteo, en casi todos los casos cada entrada de la tabla tiene una sola direccin como prximo salto para continuar el camino hacia el destino. La idea principal de o o los protocolos multi path es almacenar en un cach diferentes rutas hacia un mismo destino, y de e esta manera no tener que recalcular o descubrir una ruta ante una eventual ruptura de enlace. Existen varios protocolos que utilizan esta tcnica y son adaptaciones de los protocolos antes e vistos para soportar mltiples caminos hacia el destino. Como se vi antes DSR, en forma nativa, u o es decir sin ninguna adaptacin, soporta cach de rutas. Entre los protocolos adaptados para o e utilizar cach son: Ad Hoc On-Demand Multipath Distance Vector Routing (AOMDV), Ad Hoc e On-Demand Distance Vector Routing - Backup Routing (AODV-BR), Split Multipath Routing (SMR) Ad Hoc On-Demand Multipath Distance Vector Routing (AOMDV) utiliza un cach con varias rutas para un mismo destino con un unico tiempo de vida para todas las rutas, e es decir, cuando se vence una ruta se vencen todas las rutas almacenada para ese destino. El valor agregado que da AOMDV es que las rutas no utilizan un mismo enlace, es decir, todas las rutas desde el origen al destino no repiten un enlace entre nodos (cada ruta son conjuntos dijuntos de enlaces) Ad Hoc On-Demand Distance Vector Routing - Backup Routing (AODV-BR) propone el uso de rutas de backup como alternativa ante una ruptura de enlace. Cuando ocurre una ruptura el nodo ms cercano al origen env un paquete de error hacia ste y a la vez lo env a a e a en forma broadcast a todos los vecinos. El paquete, en la cabecera de datos, indica que el link se ha roto y que el paquete necesita una ruta alternativa. Cuando los nodos del vecindario reciben este mensaje, lo reenv hacia el destino si es que ellos tienen una ruta hacia el mismo. an Split Multipath Routing (SMR) [14] es un protocolo bajo demanda que arma las rutas de manera disjuntas. Utiliza dos rutas para cada sesin; una es la que tiene la menor latencia y otra o que es la ms disjunta con sta, es decir la que menos enlaces en comn tenga. De esta manera a e u
Redes Mviles o
SMR provee rutas alternativas y por ser disjuntas se minimiza el riesgo de rotura de una ruta por tener la m nima cantidad de enlaces comunes. SMR tiene dos esquemas de mantenimiento de las rutas. El primero crea un nuevo par de rutas si una de las dos rutas se rompe y el segundo hace una reconstruccin de las rutas solo o cuando ambas rutas se hayan roto.
2.4.
Resumen
A lo largo del Cap tulo se vieron los diferentes tipos de algoritmos disponibles para redes mviles. Como se vi hay dos categor principales, los proactivos o basados en tablas y los o o as reactivos o bajo demanda. Cada uno de ellos tiene sus ventajas y desventajas. Los proactivos tienen un alto overhead de control y de actualizacin de rutas pero una m o nima latencia. Los reactivos tienen un m nimo overhead pero mayor latencia. Llegada la discusin de cual tipo de algoritmo es mejor, habr que ver cual es la nalidad o a de la red, que servicios se van a montar sobre sta, que cantidad de nodos y que velocidad o con e qu frecuencia podr cambiar la topolog e a a. Dentro de los protocolos proactivos se desarrollaron DSDV y OLSR. DSDV tiene un alto overhead de paquetes de control pero tiene deteccin de bucles. OLSR tiene menos overhead, o tiene deteccin de bucles pero requiere conocer los vecinos que estn a dos saltos de distancia. o a Dentro de los protocolos reactivos se trataron AODV y DSR. Ambos protocolos tienen en mismo tiempo de convergencias y la misma complejidad de comunicaciones. La diferencia radica en la manera de formar las rutas. DSR tiene como ventaja que utiliza un cach de rutas con lo e cual minimiza la latencia en caso de perder una. AODV tiene como virtud que se adapta rpia damente a redes con nodos de mucha movilidad. Ambos protocolos tiene como contra problemas de escalabilidad en redes con muchos nodos. Como una alternativa a estos dos tipos de algoritmos, se analizaron protocolos h bridos los cuales usan un protocolo proactivo dentro de un vecindario y protocolos reactivos para llegar a nodos fuera del vecindario. Estos protocolos son optimos para topolog donde los nodos se as mueven pero siempre dentro de un mismo mbito. a
29
2.4. Resumen
30
Cap tulo 3
Seguridad Informtica a
En este cap tulo se har una revisin de los principales conceptos de la seguridad informtia o a ca [35, Sec. 2.1]. Cuando se habla de seguridad en redes de computadoras, hay tres objetivos o premisas bsicas a que se deben cumplir. Condencialidad: Se garantiza que la informacin sea accesible slo a aquellas personas que o o tienen acceso a la misma. Integridad: Se salvaguarda la exactitud y totalidad de la informacin y los mtodos de o e procesamiento. No Repudio: Se reere a evitar que una entidad que haya enviado o recibido informacin o alegue ante terceros que no la envi o no la recibi. o o Existen otros objetivos ms dif a ciles de lograr pero que hacen a la seguridad de la informacin o Autenticacin: Garantizar el origen y el destino de la informacin, validando al emisor y al o o receptor para evitar suplantacin de identidades. o Control de Acceso: Solo las partes autorizadas pueden participar en la comunicacin. o Disponibilidad de Servicio: Garantiza que todos los componentes de la red estn disponibles e para ser utilizado por las partes autorizadas. La mayor de estos conceptos se garantizan por medio del uso de la criptograf y algoritmos a a criptogrcos. a
3.1.
Conceptos Bsicos de Criptograf a a
Es preciso introducir conceptos bsicos de criptograf con el n de que el lector se familiarice a a con el lenguaje y adquiera los conceptos necesarios que luego sern aplicados en otros cap a tulos de esta tesis. 31
3.1.1. Cifrados Simtricos e
Por medio de la criptograf se ha podido garantizar las premisas de la seguridad para redes a de datos. A continuacin se presentan conceptos bsicos e introductorios. o a
3.1.1.
Cifrados Simtricos e
Los algoritmos de cifrado simtricos utilizan la misma clave para cifrar y para descifrar mene sajes. Las dos partes que se comunican deben ponerse de acuerdo de antemano sobre la clave a utilizar. Una vez que ambas tienen acceso a esta clave, el remitente cifra un mensaje usndola, a lo env al destinatario, y ste lo descifra con la misma. a e
3.1.1.1.
Seguridad
La seguridad de este tipo de cifrados se encuentra en la clave y no en el algorimo. En otras palabras, no deber ser de ninguna ayuda para un atacante conocer el algoritmo que se est usando. a a Slo si el atacante obtuviera la clave, le servir conocer el algoritmo. o a
3.1.1.2.
Ventajas y Desventajas
El principal problema con los sistemas de cifrado simtrico no est ligado a la seguridad e a intr nseca de los algoritmos, sino a la forma en la que se intercambian las claves. Una vez que las partes hayan intercambiado las claves pueden usarlas para comunicarse con seguridad, pero se debe asegurar que dicho intercambio se haya realizado de forma segura. Por ejemplo si fue un acuerdo verbal que nadie escucho la conversacin; Si fue por correo, asegurarse que nadie o intercept el sobre. Para un atacante es ms fcil tratar de interceptar la clave en el momento de o a a intercambio que probar el espacio posible de claves. Otro problema es el nmero de claves que se necesitan. Si tenemos un nmero n de personas u u que necesitan comunicarse entre ellos, entonces se necesitan n(n 1)/2 claves para cada pareja de personas que tengan que comunicarse de modo privado. Esto puede funcionar con un grupo reducido de personas, pero ser imposible llevarlo a cabo con grupos ms grandes. a a La principal ventaja de estos cifradores es que son muy rpidos e implementables fcilmente a a por hardware.
3.1.1.3.
Algoritmos
DES DES fue el algoritmo de cifrado por bloques ms usado, como todo cifrador simtrico a e toma un texto de una longitud ja de bits y lo transforma mediante una serie de operaciones en un texto cifrado de la misma longitud. Para el DES el tamao del bloque es de 64 bits y la n clave es de 64 bits, de los cuales slo 56 de son empleados por el algoritmo ya que los ocho bits o restantes son de paridad. El Algoritmo DES estaba estadarizado por la FIPS PUB 46-2 1 y fue reemplazado por el AES
1 http://www.itl.nist.gov/pspubs/p46-2.htm
32
3DES El algoritmo 3DES consta de tres rondas de DES. Incrementa el tamao de la clave por n un factor de 3 hasta 168 bits. Bsicamente se usan tres claves de DES. El 3DES tiene hoy en d a a un nivel de seguridad aceptable y es utilizado por muchos dispositivos. Tiene el inconveniente que es lento en comparacin con el AES. o AES AES [31, Cap. 5] es un esquema de cifrado por bloques,tiene un tamao de bloque jo de n 128 bits y tamaos de clave de 128, 192 256 bits. La mayor de los clculos del algoritmo AES n o a a se hacen en un campo nito determinado. Es el reemplazo de 3DES en los sistemas modernos. Se encuentra estandarizado por el NIST en FIPS 197, Advanced Encryption Standard (AES), 2001 2 .
3.1.2.
Cifrados Asimtricos e
Los cifradores asimtricos tienen la particularidad de contar con un par de claves, donde una e clave es pblica y se puede entregar a cualquier persona y la otra clave es privada y el propietario u debe guardarla de modo que nadie tenga acceso a ella. El remitente usa la clave pblica del u destinatario para cifrar el mensaje, y una vez cifrado, slo la clave privada del destinatario o podr descifrar este mensaje. a Los criptosistemas asimtricos utilizan las denominadas funciones-trampa o de un solo sentido. e Estas funciones de un solo sentido son aquellas cuya clculo es fcil, mientras que su inversa no es a a simple. Por ejemplo, multiplicar dos nmeros primos grandes es una operacin simple de realizar, u o pero factorizar el nmero resultante en sus componentes primos es una operacin cuyo tiempo u o de calculo puede llevar mucho tiempo al punto que para nmeros de muchos bits puede llegar a u ser computacionalmente imposible es decir puede llevar aos de calculo. Con lo cual ser en vano n a intentarlo. Se trata de lograr que la generacin de las claves utilice la funcin trampa. Es decir generar o o la clave sea simple, pero romperla sea equivalente a obtener la inversa de la funcin-trampa. o Por ejemplo, dado un cifrado de clave pblica basado en factorizacin de nmeros primos, la u o u clave pblica contiene un nmero compuesto de dos factores primos grandes, y el algoritmo de u u cifrado usa ese compuesto para cifrar el mensaje. El algoritmo para descifrar el mensaje requiere el conocimiento de los factores primos para que el descifrado sea fcil. Si poseemos la clave privada a que contiene uno de los factores ser fcil su decodicacin, pero extremadamente dif en caso a a o cil contrario. 3.1.2.1. Seguridad
Al igual que con los sistemas de cifrado simtricos, un buen sistema de cifrado de clave pblica e u no debe basarse en esconder el algoritmo, ste debe ser publico y la seguridad debe estar centrada e en esconder la clave. El tamao de la clave es una medida de la seguridad del sistema. Tener en cuenta que no se n puede comparar el tamao de claves de un asimtrico con el de un simtrico. n e e
2 http://csrc.nist.gov/publications/ps/ps197/ps-197.pdf
33
3.1.3. Resumen Criptogrco a
En un ataque de fuerza bruta sobre un cifrado simtrico con una clave de un tamao de 80 e n bits, el atacante debe probar hasta 2811 claves para encontrar la clave correcta. El esfuerzo para romper un cifrado es diferente segn el algoritmo utilizado. Mientras 128 bits u son sucientes para algoritmos con clave simtrica, los algoritmos de clase asimtrica necesitan e e claves de por lo menos 1024 bits ya que la capacidad de clculo actual y los algoritmos conocidos a de factorizacin impiden usar una clave menor. o 3.1.2.2. Ventajas y Desventajas
La mayor ventaja de la criptograf asimtrica es que se puede cifrar con una clave y descifrar a e con la otra. Esto permite conseguir autenticacin de una manera muy simple. Si se obtiene un o texto cifrado con la clave privada de alguien el unico que lo pudo generar es el dueo de la clave n y todos podemos vericar el origen ya que disponemos de su clave publica. Las principales desventajas son: Para una misma longitud de clave y mensaje se necesita mayor tiempo de proceso. Las claves deben ser de mayor tamao que las simtricas. n e Para textos pequeos, el mensaje cifrado ocupa ms espacio que el original. n a 3.1.2.3. Algoritmos
Existen varios algoritmos que utilizan el esquema de clave pblica y clave privada, todos ellos u utilizan la misma base, complejidad matemtica en la factorizacin de nmeros primos. a o u Die-Helman Die-Hellman (debido a Whiteld Die y Martin Hellman) permite generar claves en conjunto entre las partes que participan en la comunicacin. Este algoritmo debe ser o utilizado sobre un canal de comunicacin autenticado. o RSA El sistema criptogrco con clave pblica RSA es un algoritmo asimtrico que utiliza a u e una clave pblica, la cual se distribuye, y otra privada, la cual es guardada en secreto por su u propietario. La longitud de la clave puede variar, hoy en d se estn utilizando 1024 o 2048 bits. a a
3.1.3.
3.1.3.1.
Resumen Criptogrco a
Hash
Una funcin de Hash es una funcin que tiene por nalidad obtener una cadena de longitud o o ja de bits independientemente del texto que se use como entrada. La longitud de esa cadena, en general es de unos poco bytes. Al resultado de aplicar la funcin sobre un texto se le llama o hash o resumen criptogrco. Los algoritmos de hash y las funciones son pblicas y no necesitan a u claves. El objetivo principal del hash es detectar cambios en el mensaje para vericar su integridad. Una funcin puede ser usada como funcin de hash si cumple con las caracter o o sticas:
Es fcil obtener el hash dado el mensaje. a Unidireccionalidad: conocido un resumen hash(M ), debe ser computacionalmente imposible encontrar un Mensaje que se corresponda con el resumen. Otra propiedad de las funciones de hash es que una m nima modicacin al mensaje provoca o un gran cambio en el resultado de la funcin. Esta propiedad se llama difusin y confusin [31, o o o Cap. 12]. El hash por si solo no es util. Es un auxiliar que se utiliza en conjunto con otras primitivas criptogrcas. Mas adelante se mostrar como en conjunto con un algoritmo asimtrico permite a a e construir la rma digital. Algoritmos Los algoritmos ms populares son md5 y sha-1. La salida de md5 es de 128 bits, a mientras que la de sha-1 es de 192 bits. 3.1.3.2. MAC
Message Authentication Code (MAC) es el resultado (cdigo) de aplicar una funcin que o o recibe como parmetros un texto y una clave secreta compartida entre las partes. Aplicando esta a funcin se est autenticando el mensaje. Adicionalmente, el MAC al igual que los algoritmos de o a hash, tambin previenen la manipulacin de los mensajes protegiendo la integridad de los mismos. e o Los algoritmos de MAC no son reversibles, es decir, a partir de un cdigo MAC es imposible o hallar un mensaje que se corresponda. EL objetivo del mismo no es ocultar la informacin sino o protegerla y autenticar al origen. Actualmente, dos de los ms grandes grupos de funciones MAC segn su modo de operacin: a u o CBC-MAC: La idea detrs de este algoritmo es la de convertir un algoritmo de cifrado a simtrico en una funcin MAC. El funcionamiento bsico consiste en cifrar el mensaje e o a usando un algoritmo en modo CBC y tirar todo el resultado de texto cifrado a excepcin o del ultimo bloque. HMAC: Dado que una funcin MAC es un mapeo aleatorio, y que las funciones hash se como portan como tales, podemos explotar la idea de utilizar una funcin hash para implementar o una funcin MAC. La opcin ms popular hoy en d es la de usar HMAC-SHA-256. o o a a
3.1.4.
Firma Digital
La rma digital es una manera de garantizar la autor y la integridad de un documento a digital (texto, correo, aplicaciones, etc). Al igual que una rma olgrafa, la rma digital es usada o para manifestar un acuerdo/desacuerdo, indicar que se ha le un documento digital. do El mecanismo de rmado de un documento digital (Figura 3.1) se realiza aplicando una funcin de hash al mismo y luego encriptndola con la clave privada del autor generando as la o a rma. El documento rmado consta de dos partes, el documento en s y la rma. Los lectores del mismo, aplican la funcin de hash al documento y desencriptan la rma con la clave pblica o u
3.1.5. PKI
del emisor. Compara el hash calculado con el desencriptado de la rma y si estos coinciden, se garantiza que el documento no fue modicado y fue emitido por el autor. Tambin se garantiza e que el autor no puede negar su autor ya que es l el unico que pudo encriptar el hash con su a e clave privada
Figura 3.1: Proceso de Generacin y Vericacin de una Firma Digital o o
Resumiendo la rma digital garantiza integridad y no repudio.
3.1.5.
PKI
Una infraestructura de clave pblica (PKI, Public Key Infrastructure) son los elementos neu cesarios (hardware, software, pol ticas y procedimientos) para garantizar la identidad, cifrado asimtrico y rmas digitales [31, Cap. 13] en operaciones electrnicas. e o 3.1.5.1. Propsito y funcionalidad o
La tecnolog PKI provee como servicio a los usuarios la posibilidad de autenticarse uno con a otros por medio de certicados expedido por una entidad de conanza para ambos. Esto a la vez permite distribuir informacin (por ejemplo claves pblicas) necesaria para los protocolos de o u comunicacin seguros, algoritmos de rma digital, cifrados y todas otras operaciones que requieran o conocer la identidad y garantizar el no repudio de la otra parte de la operacin electrnica. o o En una operacin electrnica que use los servicios brindados por PKI, tiene como participantes o o al menos tres partes: Un usuario que desea realizar una operacin o Una entidad que da fe de la ocurrencia de la operacin y garantizan la validez de los o certicados de las partes. Un usuario destinatario de los datos cifrados/rmados/enviados garantizados por parte del usuario que inici de la operacin. o o
La seguridad de la tecnolog PKI se centra en la privacidad de la clave privada (ya que a esta infraestructura utiliza los mismos principios que los algoritmos de clave pblica) y en los u procedimientos o pol ticas de seguridad aplicadas a la gestin de los certicados. o Es de vital importancia ser rigurosos a la hora de establecer las pol ticas de seguridad ya que dejar expuesta una clave privada invalida cualquier tecnolog aplicada en el sistema o la a seguridad del cifrador ms fuerte. a 3.1.5.2. Usos de la tecnolog PKI a
La tecnolog PKI, es utilizada para realizar autenticacin de personas, servidores, sistemas, a o etc; realizar rmado digital de documentos, software, correo, etc; Garantizar el no repudio; Cifrado de datos y aseguramiento de canales de comunicaciones inseguros. Bsicamente el uso de esta tecnolog se centra cuando es necesario autenticar a las partes a a para realizar una transaccin digital segura. o 3.1.5.3. Certicados
Como se dijo anteriormente, la tecnolog PKI se basa en Certicados Digitales expedidos por a una entidad de en la cual conf ambas partes. Existes distintos tipos de certicados digitales an que var dependiendo el destino del mismo. an Certicado personal: Acredita la identidad del titular. Certicado de pertenencia a una entidad: Adems de la identidad del titular acredita su a vinculacin con la entidad de la cual es miembro o Certicado de representante: Adems de la pertenencia a la entidad acredita tambin los a e poderes de representacin que el titular tiene sobre la misma. o Certicado de persona jur dica: Identica una entidad como tal a la hora de realizar trmites a ante las administraciones o instituciones. Certicado de atributo: Permite identicar una cualidad, estado o situacin. Este tipo de o certicado va asociado al certicado personal. (p.ej. Mdico, Director, Casado, etc.). e Los tipos de certicados antes mencionados son relacionados con un individuo o persona, tambin existen certicados digitales para nes ms espec e a cos y tcnicos como pueden ser: e Adems, existen otros tipos de certicado digital con nes ms tcnicos: a a e Certicado de servidor: Permiten asegurar al usuario del mismo que la conexin la estn o a realizando a donde ellos quieren. Certicado de rma: Garantiza la autor y la no modicacin de aplicaciones, documentos, a o etc.
3.1.6. Componentes
3.1.6.
Componentes
Los componentes ms habituales de una infraestructura de clave pblica son: a u La autoridad de certicacin (CA, Certicate Authority): es la encargada de emitir y revocar o certicados. Es la entidad de conanza que da legitimidad a la relacin de una clave pblica o u con la identidad de un usuario o servicio. La autoridad de registro (RA, Registration Authority): es la responsable de vericar el enlace entre los certicados (concretamente, entre la clave pblica del certicado) y la identidad u de sus titulares. Los repositorios: son las estructuras encargadas de almacenar la informacin relativa a la o PKI. Los dos repositorios ms importantes son el repositorio de certicados y el repositorio a de listas de revocacin de certicados. En una lista de revocacin de certicados (CRL, o o Certicate Revocation List) se incluyen todos aquellos certicados que por algn motivo u han dejado de ser vlidos antes de la fecha establecida dentro del mismo. a La autoridad de validacin (VA, Validation Authority): es la encargada de comprobar la o validez de los certicados digitales. La autoridad de sellado de tiempo (TSA, TimeStamp Authority): es la encargada de rmar documentos con la nalidad de probar que exist antes de un determinado instante de an tiempo. Los usuarios y entidades nales son aquellos que poseen un par de claves (pblica y privau da) y un certicado asociado a su clave pblica. Utilizan un conjunto de aplicaciones que u hacen uso de la tecnolog PKI (para validar rmar digitales, cifrar documentos para otros a usuarios, etc.) 3.1.6.1. Consideraciones sobre PKI
Los Certicados Digitales deben ser emitidos por una Autoridad Certicante reconocida por las partes para garantizar la validez del mismo. Ambas partes de la transaccin electrnica debe o o conar en la Autoridad que emiti el certicado. o No es responsabilidad de la CA la conservacin del certicado y evitar que sea usado de forma o indebida. Tampoco es responsabilidad de la CA la custodia de la clave privada correspondiente al mismo. La infraestructura PKI es considerada segura por si sola si se aplican bien la pol ticas de seguridad y no es necesario realizar ningn tipo de intercambio de clave para realizar una comuu nicacin segura. o
3.2.
Resumen
En este cap tulo se hizo una revisin de los conceptos principales de seguridad informtica o a y de los conceptos bsicos de criptograf Poniendo todo junto y considerando solo algunas a a.
alternativas, podemos resumir que para garantizar los pilares de la seguridad, la criptograf nos a da las siguientes herramientas: Condencialidad: Algoritmos simtricos y asimtricos e e Integridad: Funciones de Hash y MAC No Repudio: Funciones de Hash o MAC encriptadas con un esquema PKI Estos conceptos se van a ir aanzando a medida que se avance en la lectura de la presente tesis al ver la aplicacin de cada uno. o
39
3.2. Resumen
40
Cap tulo 4
Seguridad en Redes Mviles o

El objetivo del presente cap tulo es exponer distintos tipos de ataques a los que est expuesta una red Mvil y cuales son algunos de los protocolos de ruteo que a o existen para hacer que este tipo de redes sean conables. El estudio de estos protocolos son necesarios para el objetivo de esta tesis. Por ello es que de cada uno de ellos se resaltar que aspecto puede ser utilizado en esta tesis. a
Como se vi en la Seccin 2.1 las redes mviles son una coleccin de dispositivos mviles o o o o o formando momentneamente una red sin la ayuda de una infraestructura. Estos dispositivos a utilizan el aire como medio f sico de comunicacin, compartiendo con muchos otros el mismo o canal de transmisin. Los nodos participantes de una red mvil estn mucho ms expuestos a un o o a a ataque que una computadora dentro de una red cableada ya que cualquier intruso no tiene ms a que ponerse a escuchar el aire y puede comenzar su ataque. Otra caracter stica de este tipo de redes es que su topolog en muy cambiante y diculta a tener un control de los miembros de la red. La naturaleza de las redes mviles hace que carezcan de un control de seguridad centralizado. o Por esto es que el responsable de la seguridad de la red es el protocolo que se utilice para comunicarse. Para hacer de una red mvil una red segura, hay que tener en cuenta los Servicios de Seguridad o descriptos en el Cap tulo 3 extendidos a Redes Mviles [15]: o Disponibilidad: garantiza la supervivencia de la red ante la hostigacin de nodos agresores. o Condencialidad: garantiza que todo el trco que circula por la red (paquetes de control a y paquetes de datos) solo pueden ser le dos por los nodos autorizados a verlo y por ningn u otro nodo. Integridad: garantiza que la informacin que viaja por la red no ha sido modicada durante o el trayecto del origen al destino. 41
4.1. Ataques
Autenticacin: garantiza a un nodo la identidad de otro nodo participante de la red. o No Repudio: grantiza que el nodo que envi el mensaje no puede negar que lo hizo. o
4.1.
Ataques
Los ataques en una red mvil se pueden clasicar de dos maneras: por su origen o por el grado o de participacin del nodo atacante. o La clasicacin por origen del atacante puede ser: o Ataque Externo: El nodo enemigo no es un nodo integrante de la red Ataque Interno: El nodo enemigo es parte de la red La clasicacin por el grado de participacin del nodo atacante puede ser: o o Activo: Se considera activo cuando un nodo emite seal o datos con el objetivo de daar la n n red. Pasivo: Se considera pasivo cuando el nodo no coopera y simplemente escuchan. A los nodos pasivos se los llama ego stas (selsh) Dentro de cualquiera de las categor anteriores podr darse estos tipos de ataques: as an Denegacin de Servicio (DoS): Consiste es dejar el nodo fuera de la red o Interceptacin Pasiva: Consiste en escuchar el medio (aire) o Interrupcin del Flujo: Consiste en alterar o modicar el ujo de los datos sin cambiar las o rutas Integridad de los datos: Modicacin del contenido del mensaje o Ataque de Sealizacin: Modicacin de los paquetes de control n o o
4.1.1.
Ataques Externos
Los ataques externos [16, Sec. 5] en general son ataques de capa f sica y de enlace ya que los protocolos de niveles superiores proveen autenticacin. Los ataques de capa f o sica son muy dif ciles de implementar por la naturaleza de la red. Los ataques externos se pueden subdividir por el grado de participacin del nodo agresor en o dos categor interceptacin pasiva (pasive eavesdropping) e interferencia activa. as: o 4.1.1.1. Interceptacin Pasiva o
Esta tcnica permite a los nodos agresores escuchar y recibir mensajes e informacin de e o actualizaciones de las tablas de ruteo y de esta manera inferir una topolog de red, identidades a o cuales son los nodos que tienen ms participacin en la red. a o
4.1.1.2.
Interferencia Activa
El objetivo de esta tcnica es causar una denegacin de servicio (DoS) causando un bloqueo e o del canal de comunicaciones o distorsionando la comunicacin. Las consecuencias de este ataque o depende del tiempo que se aplique y del tipo de protocolo de ruteo utilizado en la red. Si se utiliza un protocolo reactivo, ste ver a la interferencia como una ruptura de enlace y el mecanismo e a de mantenimiento de ruta eliminar el enlace con este nodo y no podr recibir mensajes. Si se a a utiliza un protocolo proactivo la reaccin no es inmediata y si la ruta se cree que est rota, o a eventualmente puede expirar su tiempo de vida y ser eliminada. El ataque ms serio de este tipo es uno llamado sleep deprivation torture que consiste en a interrumpir el per odo de ocio del dispositivo de capa f sica y producir un consumo excesivo de la energ de la v a ctima. Este tipo de ataques ya tiene muchos aos de estudio y la tecnon log de espectro ensanchado que utilizan las comunicaciones inalmbricas son resistentes a las a a interferencias, al ruido y a intrusos. Cabe a aclarar que la interferencia no es solo a nivel f sico sino que el hecho de que un nodo malicioso repita mensajes fuera de tiempo, mensajes incompletos hacen un uso excesivo de las frecuencias de radio y producen un gasto de energ y a la vez saturan el nodo con informacin a o intil causando una denegacin de servicio. u o
4.1.2.
Ataques Internos
Los ataques internos [16, Sec. 6] son los ms serios y los ms dif a a ciles de defender ya que un nodo interno a la red tiene la informacin necesaria para participar en la red. Los nodos internos o pueden tener comportamientos maliciosos en diferentes sentidos. Para identicar estos comportamientos, se pueden considerar las siguientes categor Nodo Fallido, Nodo Fallido Maligno, as: Nodo ego sta y Nodo Malicioso. 4.1.2.1. Nodo Fallido
Un nodo fallido es aquel nodo que simplemente no puede realizar una operacin, esto puede ser o por varias razones, por ejemplo una falla de energ o eventos ambientales. El problema principal a que estos nodos causan es que dejan de reenviar mensajes incluyendo los mensajes de control. Este comportamiento es muy cr tico ya que este nodo corta la comunicacin y puede ser que o el resto de los nodos no se hayan enterado de una rotura de una ruta por ejemplo, porque el mensaje deb pasar por un nodo fallido. Este problema es an ms cr a u a tico cuando el nodo fallido es parte de una ruta de emergencia o parte de una ruta segura. Estos fallos pueden crear cuellos de botella y llegar a extremo de desacoplar la red. 4.1.2.2. Nodo Fallido Maligno
El efecto provocado por un nodo fallido maligno es el mismo que el caso anterior pero en este caso el nodo deja de operar de una manera consciente. Adicionalmente a este comportamiento un nodo maligno puede enviar mensajes de rutas falsas o generar mensajes falsos para alterar
4.1.2. Ataques Internos
el comportamiento y el ruteo del resto de la red. Para algunos protocolos estos nodos pueden provocar una ataque de denegacin de servicio (DoS). o 4.1.2.3. Nodo ego sta
Un nodo ego sta explota los protocolos de ruteo para el bien propio. Es el caso de que un nodo no quiera cooperar en la red para preservar sus recursos (energ demostrando un coma) portamiento similar al de un nodo fallido. La accin t o pica de un nodo ego sta es la de desechar los paquetes recibidos. Este ataque es muy dif de detectar ya que los protocolos no preveen el cil control de donde se perdi un paquete (a excepcin de DSR). Lo que hay que resaltar es que los o o nodos ego stas no ponen en riesgo la integridad de la red inyectando informacin falsa. o 4.1.2.4. Nodo Malicioso
El objetivo de un nodo malicioso es alterar el correcto funcionamiento del protocolo de ruteo, denegando el acceso a los servicios de la red. Por lo tanto todos los comportamientos mencionados antes pueden estar presentes en un nodo malicioso. A continuacin se muestran distintos tipos o de ataques que este tipo de nodos puede introducir: Denegacin de Servicio El ataque de denegacin de servicio (Denial of Service -DoS-) ino o duce a las v ctimas a caer en un ataque sleep deprivation torture que consiste en hacer realizar operaciones innecesarias a las v ctimas haciendo agotar los recursos de energ Este ataque lo a. provocan enviando a sus v ctimas informacin vlida o errnea en forma innecesaria. Los protoo a o colos proactivos son muy sensibles a este ataque ya que cuando les llega una actualizacin de un o nodo deben actualizar todas sus rutas, por lo tanto si se les env informacin necesaria estos a o nodos consumir muchos recursos actualizando sus tablas. an Este tipo de ataque tambin atenta contra la integridad de la red porque el nodo atacante e puede enviar mensajes alterando las rutas. Ataque a la Integridad de la Red Este ataque tiene lugar cuando el nodo agresor inyecta en la red informacin falsa de la topolog de la red. Muchos otros ataques pueden tener como o a consecuencia este tipo de agresin. o Cuanto mayor es la densidad de la red donde el atacante se encuentra, mayor es la consecuencia. Los protocolos proactivos, en especial el OLSR, es muy sensible a este ataque ya que tiene un algoritmo de ooding muy pobre, con lo cual informacin falsa puede ser reenviada a otro nodo. o Ataque a los protocolos de deteccin de Vecinos Un nodo malicioso puede forzar a un o nodo a agregar a un vecino inexistente o hacer que ignore a un vecino real. Este ataque se efecta u contra el protocolo de deteccin de vecinos. El nodo agresor puede enviar a la v o ctima un mensaje con la informacin de censado de vecinos incorrectas. o Algunos protocolos como el DSR usan listas negras para bloquear transmisiones a nodos con los cuales no se tiene un enlace bidireccional. En este protocolo un nodo malicioso podr provocar a una alteracin de los links en uno de los sentidos y el mismo protocolo pondr a ese vecino en o a
su lista negra y no le enviar ningn mensaje. De manera contraria un nodo malicioso podr a u a hacer que la v ctima remueva un nodo de la lista negra hacindose pasar por tal envindole un e a route-request con los datos de la cabecera del nodo que est en la lista negra. a Redireccin de trco El ataque consiste en que un nodo puede hacerse pasar por otro y o a as modicar la integridad de la red haciendo pasar todas la rutas de la red por el nodo atacante. Cuando un nodo de la red hace un route-request el nodo maligno puede responder que l es el e destino o que l tiene una ruta hacia el destino y de esta manera todo el trco pasar a travs de e a a e l y los mensajes para el destino real lo recibe l. A este caso particular del ataque de redireccin e e o de trco se lo conoce como agujero negro. a Otra consecuencia de este ataque es que un nodo puede modicar las rutas para que todo el trco vaya para un nodo y que ste caiga en un ataque de sleep deprivation. Este efecto se a e puede acentuar haciendo que el nodo agresor env al resto de los nodos un nmero de salto e u pequeo hacia el destino y un nmero de secuencia ms nuevo para asegurarse que todos los n u a nodos preeran las rutas que pasan por el nodo v ctima. Una variante de este ataque que es muy dif de detectar es el ataque del tnel (wormhole cil u attack ) en el cual la informacin que llega a un nodo es tuneleada hacia otro nodo por un medio o directo ms rpido. Si en un protocolo reactivo, el mensaje es tuneleado hacia las cercan de a a as un nodo destino, ste llegar ms rpido que cualquiera, por lo tanto el retorno de la ruta ser a e a a a a travs del tnel y como consecuencia de esto el nodo mal intencionado est dentro de la ruta e u a hacia ese destino. Para los protocolos proactivos ese ataque tambin es vlido pero se sealiza el e a tuneleado de los mensajes de deteccin de vecinos como se vi en el ataque anterior. o o Ataque a los N meros de Secuencia La mayor de los protocolos utilizan nmeros de u a u secuencia para prevenir ataques en los cuales se les reenv mensajes viejos. Igualmente un en nodo malicioso puede explotar esta caracter stica enviando muchos mensajes con una direccin o de destino falsa y un nmero de secuencia muy alto, como consecuencia del ataque se produce u una denegacin del servicio porque cualquier mensaje vlido de otros nodos sern rechazados por o a a tener un nmero de secuencia viejo o duplicado. u Ataques a Protocolos Espec cos Existen distintos tipos de ataques para protocolos espec cos. Cuando un nodo malicioso integra una red, ya tiene el conocimiento de que protocolo est presente en esa red y as puede ejecutar un ataque espec a camente al protocolo presente. De esta manera el ataque es mucho ms efectivo. Por ejemplo para DSR el nodo atacante puede a inyectar tantas rutas con tantos prximos saltos como sea posible hacia un destino inexistente. o Luego el agresor env un mensaje hacia el falso destino. En este punto se produce un ataque de a denegacin de servicio, porque cada nodo intermedio va a intentar enviar a su prximo salto el o o error de la ruta de los cuales esperar un ACK. El nodo intermedio va a intentar salvar la ruta a tratando de buscar una ruta alternativa y las rutas alternativas que encuentre van a ser falsas y a va a llevar al nodo a incrementar el valor de M AX SALV AGE T IM ES hasta su mximo y no va a intentar ms. a
4.2. Protocolos de Ruteo Seguros
4.2.
Protocolos de Ruteo Seguros
Desde que se comenzaron a desarrollar los primeros manuscritos de los protocolos de ruteo para MANETs, se comenz a investigar como prevenir los ataques. En general se han investigado y o desarrollado ms protocolos seguros basados en los protocolos de ruteo reactivos (DSR o AODV). a Dentro de la variedad de protocolos desarrollados, todos tienen en comn que tratan de u mitigar los ataques activos producidos por los nodos atacantes que comprometen la integridad de la red, pero no los ataques de nodo ego sta. Otra caracter stica de los protocolos actuales que es se desarrollan en un ambiente controlado, es decir todos los integrantes de la red que deseen comunicarse deben poder intercambiar algunos parmetros de inicializacin (claves entre otros) a o de antemano. A continuacin de describirn los protocolos seguros ms populares. o a a
4.2.1.
SRP - Secure Routing Protocol
SRP [23] fue concebido como una extensin para los protocolos DSR 2.3.2.2 y para IARP o parte del protocolo ZRP 2.3.3.1. SRP garantiza la recoleccin correcta de la topolog de la red aunque se encuentre en preseno a cia de un nodo malicioso. Este protocolo es fuerte ante ataques que intenten modicar el proceso de descubrimiento de la ruta. El protocolo asume la existencia de una security association (SA) entre el nodo origen (S) y el nodo destino (T ). Esta relacin de conanza puede ser inicializada, por ejemplo, si un nodo o conoce la clave pblica del otro, luego por medio de algoritmos como puede ser Die-Hellman u pueden negociar una clave (KS,T ) y utilizarla como SA. SRP como se dijo anteriormente combate los ataques contra el proceso de descubrimiento de ruta y garantiza, teniendo en cuenta algunas asunciones [23, Sec. C.1], que la informacin que o reciba un nodo sea correcta. Tambin incorpora algunos mecanismos que previene que se exploten e funcionalidades del protocolo en contra de la integridad de la red. 4.2.1.1. Descubrimiento de la Ruta
SRP agrega al encabezado del protocolo de ruteo 4.1 una cabecera de SRP de 192 bits 4.2. El nodo S el pedido de ruta (RREQ) mantiene un nmero de secuencia de 32 bits(Query Secuence u Number, Qsec ), el cual es incrementado con cada pedido. Este nmero permite a T detectar u pedidos viejos y descartarlos. El nmero de secuencia se inicializa cuando se establece la SA. u Por cada pedido de ruta, S generar un nmero aleatorio de 32 bits (Query Identier, QID ) a u que es utilizado por los nodos intermedios para identicar el pedido. QID es generado de manera tal que sea imposible de predecir por un atacante. Estos dos nmeros, ms un identicador de tipo son agregados en el encabezado de SRP. u a Finalmente se genera el SRP MAC de 96 bits que es producto de la salida de aplicar HMAC [24] utilizando como entrada la IP de destino, el paquete del protocolo original (Basic Routing Protocol Packet) y la clave KS,T
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IP Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Basic Routing Protocol Packet | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SRP Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figura 4.1: Formato del encabezado de un protocolo de ruteo con la extensin de SRP o
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Query Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Query Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | SRP MAC | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figura 4.2: Encabezado de SRP
Los nodos intermedios abren el paquete y extraen el QID , direccin origen y direccin destino o o para insertarlos en una tabla (query table). Todos los pedidos que lleguen y se encuentren en esta tabla son descartados, los dems sern retransmitidos para continuar el proceso de descubrimiena a to. Los nodos intermedios tambin controlan la frecuencia con la que se generan los pedidos para e mantener un ranking que es inversamente proporcional a la frecuencia de pedido. Generalmente un nodo malicioso genera muchas solicitudes de ruta con el n de generar un DoS o utilizar el ancho de banda de la red para transmitir paquetes de control. De esta manera, los nodos malicioso rankearan bajo y sus paquetes sern retransmitidos con baja prioridad o eventualmente no se a transmitirn. a Una vez que el nodo destino recibe la peticin de ruta (RREQ), verica la integridad y la o autenticidad del mismo calculando el HMAC y comparndolo con el del paquete recibido. Si el a paquete es vlido, comienza el proceso de respuesta. El paquete de respuesta (RREP) es generado a utilizando la cabecera SRP del mismo modo que la gener el nodo S cuando gener el pedido. o o EL nodo origen descartar todos aquellas respuestas que no se encuentren en su lista de pedidos a pendientes. Esto lo hace utilizando la direccin de origen, la de destino y los nmeros QID y o u Qsec . La versin bsica de SRP es vulnerable a ataques de envenenamiento de cache de rutas o a (route cache poisoning) ya que nodos atacantes pueden generar informacin invlida y los nodos o a intermedios que operan en modo promiscuo para mejorar la eciencia del protocolo los reciben y
4.2.2. ARIADNE
retornan la ruta cacheada. Los autores del SRP poroponen como alternativa el uso de Intermediate Node Reply Token (INRT). INRT utiliza una clave KG compartida entre un grupo de nodos y la utiliza para generar un HMAC del paquete RREP. Con esta extensin se agrega un nuevo campo al encabezado o SRP 4.3.
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SRP Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IN Reply Token | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figura 4.3: Encabezado SRP con extensin INRT o
4.2.1.2.
Otras Vulnerabilidades
SRP no tiene una validacin para los mensajes de mantenimiento de ruta, los paquetes de o error no son vericados. De todos modos, para minimizar este efecto, SRP genera los paquetes de errores con un prejo donde est la ruta completa. Con este prejo el nodo S puede vericar a si el nodo que gener el mensaje de error es parte de la ruta. Lo que no se puede vericar es si el o mensaje es real, es decir un nodo intermedio puede decir que el enlace se rompi pero en realidad o est intacto. a SRP no tiene ninguna contramedida para el ataque del tnel (wormhole attack ). u 4.2.1.3. Ideas Rescatadas para el Desarrollo de la Tesis
De este protocolo se destaca el uso de una SA entre los nodos generada por algn algoritmo u de intercambio de claves, en este caso Die-Hellman. Otro aspecto es el uso de HMAC para garantizar integridad y autenticacin del mensaje. o
4.2.2.
ARIADNE
ARIADNE [1, Sec 12.2.2.2] es un protocolo de ruteo seguro basado en DSR 2.3.2.2 y utiliza criptograf simtrica 3.1.1 para que el destino del proceso de descubrimiento de la ruta pueda a e autenticar al origen, para que el origen pueda autenticar a los nodos intermedios presentes en el mensaje de respuesta RREP y para que ningn nodo intermedio pueda remover algn nodo de u u la lista del mensaje RREP o RREQ. Como se comentaba en la introduccin a los protocolos de ruteo seguros, ARIADNE necesita o algn mtodo de intercambio de claves previo. Se deben intercambiar las claves entre el origen S u e y el destino D (KS,D ). ARIADNE provee una autenticacin punto a punto del mensaje de ruteo usando autenticacin o o MAC y una clave compartida entre las dos partes. Para la autenticacin de los paquetes broadcast o utiliza un protocolo de autenticacin llamado TESLA [25]. o
ARIADNE previene la modicacin y el armado de informacin de ruteo, previene el uso de o o la impersonicacin y en versiones avanzadas del ataque del tnel (wormhole attack ). o u ARIADNE arma el paquete de solicitud de descubrimiento de ruta adicionndole siete campos a para proporcionar autenticacin e integridad. o
<ROUTE_REQUEST, origen, destino, id, intervalo_de_tiempo, hash, lista_de_nodos, lista_de_MAC>
El origen y el destino son las direcciones de los nodos de origen y destino respectivamente. Como en DSR, el id es un nmero que no se haya utilizado en los procesos u de descubrimiento recientes y el intervalo de tiempo es el intervalo de tiempo de TESLA, un tiempo pesimista de arribo del pedido al destino. El origen inicia el hash con un M ACKS,D (origen, destino, id, intervalo de tiempo) , la lista de nodos y la lista de MAC vac as. Cuando un nodo A recibe un mensaje RREQ, del cual l no es el destino, busca en su tabla por e la tupla <origen,id> para determinar si este paquete no lo vi antes, si lo vi descarta el paquete. o o a Tambin verica que el intervalo de tiempo sea vlido, si no lo es descarta el pedido. En caso e contrario, el nodo A modica el pedido agregando su direccin en lista de nodos, reemplazando o el hash con H(A, hash anterior). En la lista de MAC agrega el MAC del pedido completo. El nodo utilizar la clave TESLA KAi para computar el MAC, donde i es el a ndice para el intervalo de tiempo especicado en la peticin. Finalmente reenv el mensaje. o a Cuando el nodo destino recibe la peticin, lo primero que hace es vericar la validez del o mensaje calculando si el hash es vlido realizando el siguiente clculo. a a
H[n , H[n1 , H[..., H[1 , M ACKSD (origen, destino, id, intervalo de tiempo)]...]]]
Donde i es la direccin del nodo en la posicin i de la lista de nodos y n es la cantidad de o o nodos en la lista. Si el nodo destino determina que el mensaje es vlido, arma el mensaje de respuesta el cual a ser enviado al origen siguiendo la ruta reversa. a
<ROUTE_REPLY, destino,origen,intervalo_de_tiempo, lista_de_nodos, lista_de_MAC, MAC_destino, lista_de_claves>
El destino, el origen, el intervalo de tiempo, la lista de nodos y la lista de MAC son los mismos que recibi en el RREQ. El MAC destino es un MAC calculado sobre lista de MAC o utilizando la clave KDS y la lista de claves se inicializa vac a. Cuando el nodo destino recibe la respuesta, verica que cada clave en la lista de claves sea a a vlida, el MAC destino sea vlido y cada uno de los MAC de la lista de MAC sean vlidos. Si a todas las vericaciones son exitosas, se acepta el mensaje, en caso contrario se descarta. ARIADNE tambin se proteje contra ataques de DoS causado por la inyeccin de mltiples e o u paquetes de RREQ. Los nodos pueden ltrar este tipo de ataques usando la cadenas de descubrimiento de ruta, el cual es un mecanismo para autenticar el proceso de descubrimiento.
4.2.3. Resumen
4.2.2.1.
Ideas Rescatadas para el Desarrollo de la Tesis
De este protocolo se rescata la capacidad de poder autenticar el procedimiento de descubrimiento de una ruta para prevenir ataques de DoS. Si bien esta idea se tuvo en cuenta durante el desarrollo de la tesis no fue utilizada ya que OLSR es un protocolo proactivo y este tipo de descubrimiento se llevan a cabo en protocolos reactivos.
4.2.3.
Resumen
A lo largo del cap tulo se presentaron cuales son los ataques t picos a los que debe enfrentarse una red mvil. Tambin se presentaron cuales son las cuestiones bsicas que debe garantizar un o e a protocolo para que sea considerado seguros y nalmente se presentaron protocolos seguros. De los protocolos desarrollados se indic de cada uno cuales aspectos son provechosos para el desarrollo o de la tesis. Si bien los protocolos seguros descriptos al nal de este cap tulo son protocolos reactivos y el objetivo de la tesis es trabajar con un protocolo proactivo como es el caso del OLSR, algunas ideas de stos fueron provechosas. e
50
Cap tulo 5
Redes Mviles Urbanas o

El objetivo del presente cap tulo es introducir el concepto de que es una Red Mvil o Urbana y cuales son los aspectos administrativos de este tipo de redes.
Las redes mviles tiene un uso potencial muy grande ya que los dispositivos de comunicacin o o masivos (celulares, PDAs, etc) cada vez estn al alcance de ms personas y ganan popularidad a a dentro de la sociedad ya que en un solo dispositivo pueden reproducir contenidos multimedia, hablar por telfono y navegar por internet. Estos dispositivos en su mayor cuentan con interfaces e a de red inalmbricas las cuales les permiten interconectarse o conectarse a un punto de acceso a (Access Point). Esta popularidad que van ganando los dispositivos mviles sumado a proyectos comunitarios o relacionados con armar redes inalmbricas metropolitanas hacen que cualquier persona pueda a estar conectada, a travs de una LAN, con otra persona en el otro extremo de la ciudad donde e sin la ayuda de una red mvil ser imposible por razones inherentes a la naturaleza de las o a conexiones y los dispositivos inalmbricos. a La tecnolog Wi-Fi (802.11) tiene como limitante para establecerse una comunicacin wireless a o la l nea de visin, es decir, los dos elementos a comunicarse no deben tener ningn obstculo que o u a interera entre los dos extremos. Este limitante es el peor enemigo que tiene las redes urbanas por las caracter sticas edilicias que presenta una ciudad. Viendo un caso prctico, una persona a quiere comunicarse con un vecino que est edicio de por medio, por ms que las distancias sean a a cortas, existen paredes que obstaculizan la comunicacin directa entre estas dos personas. o Una red urbana debe combatir esa limitacin y para ello se instalan nodos en posiciones o estratgicas que tengan l e nea de visin entre s y de esta manera extender la cobertura. En este o cap tulo se ver como se conforma una red urbana, como nacen y como trabajan redes mviles a o urbanas en distintas partes del mundo. 51
5.1. Proyectos Comunitarios Libres
5.1.
Proyectos Comunitarios Libres
La comodidad de las redes inalmbricas, sumado a la posibilidad de conectarse sin cables a a una velocidad razonable y el esp ritu aventurero de los fanticos de las comunicaciones llevaron a en primera medida a compartir una conexin con un vecino o con un amigo. Siendo esta primera o etapa satisfecha rpidamente, se ven con la necesidad de ir ms all y conectarse con puntos cada a a a vez ms lejanos y con mayor cantidad de personas. Como existen varias personas con el mismo a esp ritu aventurero, curioso y con ganas de aprender de comunicaciones o simplemente tienen una coleccin de discos que quieren compartir con personas ms all de su c o a a rculo de amistades es que nacen las comunidades. Las comunidades conforman una simbiosis entre sus miembros, cada uno necesita de otro para poder cubrir ms supercie con la red y es as como nacen las redes urbanas, conformadas por a personas, sin nes de lucro con el unico objetivo de cubrir cada vez ms supercie para que cada a vez haya mas personas conectadas. Teniendo una visin ms macro de estos grupos, existen en diferentes ciudades del mundo o a grupos de personas conformando comunidades de redes libres. Para dar algunos ejemplos, en Latinoamrica una de las comunidades ms grandes es BuenosAiresLibre 1 , en Argentina otra e a comunidad muy importante es Mendoza Wireless 2 . En Uruguay, Motevideo Libre 3 , en Chile, ChileSinCables 4 . En Estados Unidos existe una innumerable cantidad de comunidades libres, de las cuales sobresalen NYCWireless 5 y SeattleWireless 6 . As se podr enumerar innitas an cantidades de comunidades de redes urbanas libres en todo el mundo.
5.1.1.
Buenos Aires Libre
Como se mencion anteriormente Buenos Aires Libre (BAL) es una de las comunidades de o redes urbanas ms grandes de Latinoamrica. Esta comunidad nace como parte de un proyecto a e ms ambicioso llamado Red Libre Argentina que ten como objetivo conformar una red abierta a a en todo el pa El grupo de personas que encabezaban ese proyecto eran de Buenos Aires y s. decidieron comenzar por conformar la red comenzando por la Ciudad de Buenos Aires y as nace el grupo de Buenos Aires Libre. He elegido esta comunidad como ejemplo de aplicacin de esta tesis ya que soy miembro de o la misma desde hace 5 aos y conozco su arquitectura y su topolog desde el comienzo. n a La comunidad se organiza por grupos, actualmente existen dos grandes grupos, el grupo de Organizacin y los que participan pasivamente en el proyecto o colaboran con un nodo pero no o son parte del grupo organizativo. Dentro del grupo de Organizacin existen varios subgrupos con o tareas espec cas como por ejemplo Direccionamiento IP, Mantenimiento del Site del proyecto, Interrelacin con otros proyectos libres y otras comunidades wireless. o
1 http://www.buenosaireslibre.org 2 http://www.mendoza-wireless.net.ar 3 http://www.montevideolibre.org 4 http://www.chilesincales.org 5 http://www.nycwireless.net 6 http://www.seattlewireless.net
52
Una vez por mes se realiza una reunin del grupo de Organizacin donde se plantean inquietuo o des y se resuelven decisiones consensuadas para la administracin de la comunidad. Por ejemplo o se determinan pautas para pertenecer al grupo de Organizacin, se decide el esp o ritu del proyecto, se fomenta e incentiva la instalacin de nuevos nodos entre otras tareas. En estas reuniones cada o grupo presenta nuevas ideas y se jan objetivos para los diferentes grupos.
5.2.
Topolog a
La topolog de las redes urbanas son muy diferentes ya que se adaptan a la geograf de la a a ciudad o sencillamenta a donde es posible poner un nodo. Las redes en ciudades grandes donde prevalecen los edicios de varios pisos es muy dif lograr extenderlas ya que es necesario muchos cil nodos ubicados en edicios altos para que puedan tener l nea de visin. La particularidad de una o red urbana es que un dispositivo se puede comunicar con otros a miles de metros sin tener linea de visin y fuera del rango de cobertura del dispositivo utilizando nodos intermedios de la red. o Generalizando, las redes urbanas estn conformadas por dos tipos de nodos: Nodo y Cliente. a Un nodo es en general un punto jo ubicado en un punto estratgico que tiene l e nea de visin con o otro y son los encargados de extender la red conformando el backbone de la misma. Los Clientes son cualquier nodo (mvil o jo) que se conecta en general a un nodo. La gura 5.1 muestra una o topolog de red t a pica de una red urbana. Hasta ahora se desarroll el concepto de red urbana donde los clientes se conectan generalo mente a un nodo. Esta idea es la que se aplica en la actualidad en la mayor de las redes urbanas a ya que los protocolos de redes mviles no han sido estandarizados y no se distribuyen con los o drivers de las placas de red o con los sistemas operativos. Esta forma de conexin es la unica mao nera que existe hasta el momento para los clientes. Sin embargo, los nodos cuentan con hardware espec co y Sistemas Operativos no convencionales y s implementan protocolos de redes mviles o con lo cual cada nodo pertenece a una red autocongurada por estos. La integracin de los clientes como participantes de la red mvil es, por llamarlo de alguna o o manera, experimental, ya que las implementaciones de los protocolos estn en pleno desarrollo y a solo algunos pocos se aventuran a experimentar. Cuando los protocolos sean estandarizados y se hagan ms populares, todos los clientes van a a ser parte de una red mvil. Esto va a permitir que un cliente pueda acceder a la red no solo o a travs de un nodo sino a travs de otro cliente. En la Figura 5.1 se muestra una topolog de e e a una Red Mvil Urbana. En esta se puede observar que los clientes no tienen conectividad con o todos los integrantes de la red pero s tienen conectividad al menos con un cliente o un nodo. En particular se puede observar que si el Cliente 9 quiere acceder a internet, su peticin ser ruteada o a a travs del Cliente 8, 7, 6 hasta llegar al Nodo 3, el cual no tiene conexin a Internet, pero e o conoce como llegar a ella, por lo tanto rutea la peticin hacia el Nodo 2, y este hacia el Nodo o 1 donde nalmente sale a Internet. Cabe destacar que el Cliente 9 sin la colaboracin del resto o de los intermedios por los que pas el pedido hubiera sido imposible llegar al Nodo 1 el cual o geogrcamente podr estar a miles de metros. a a
5.2.1. Direccionamiento IP
Figura 5.1: Diagrama de una red Mvil Urbana o
5.2.1.
Direccionamiento IP
En una red IP, es fundamental tener una direccin para poder comunicarse. En las redes o mviles la asignacin de direcciones IP es parte del desaf de las funcionalidades que puede o o o brindar el protocolo de ruteo. En general los protocolos no brindan la capacidad de asignacin o de IP sino que se asume que el dispositivo cuanta con una. Algunas implementaciones tienen la caracter stica de buscar que no hayan direcciones repetidas dentro de la red en el momento que un nodo se est asociando. a En las redes urbanas y en especial en BAL, las direcciones IP estn distribu a das en dos rangos, un rango para nodos y otro para clientes. Existe una entidad llamada freenetworks 7 , en donde cada comunidad tiene asignado un rango de IP privadas. Esto garantiza que las redes comunitarias registradas no tienen direcciones duplicadas. Buenos Aires Libre tiene los rangos asignados por freenetworks. A su vez, BAL asigna una subred a cada uno de los nodos para proveer direcciones IP a los clientes (servicio de DHCP en el nodo) y para comunicacin con otros nodos. Con esta asignacin o o llevada a cabo por un grupo de personas de la comunidad se asegura una homogeneidad de direcciones dentro de la red. Hasta el momento por la manera que se conectan los clientes (a un nodo jo) es la manera de asignar IPs, en un futuro cuando toda la red sea idealmente una red mvil se utilizar la tcnica o a e de asignacin de ip estandarizada para este tipo de redes. Las pruebas experimentales se hacen o asignando cualquier IP teniendo la precaucin que no sea una direccin repetida. o o
7 http://www.freenetworks.org
54
5.3.
Protocolos de Ruteos
Como se vi en la seccin 2.2 existen varios protocolos para rutear paquetes en una red mvil. o o o Tomar la decisin de qu protocolo usar queda fundamentalmente sujeto a qu implementaciones o e e hay disponibles. Existen muy pocos protocolos implementados, entre ellos OLSR y AODV. La implementacin de OLSR es actualmente la ms evolucionada e implementada en un proyecto o a 8 open source llamado olsrd . Muchos proyectos de redes libres lo utilizan, en particular BAL tiene implementada la interconexin de los nodos con olsrd. o Las pruebas que se estn llevando a cabo con clientes mviles es con implementaciones de a o este mismo protocolo, disponibles para diferentes sistemas operativos. OLSR es un protocolo proactivo en el cual cada nodo conoce la ruta para llegar a cualquier destino de la red. Actualmente las redes comunitarias no estn compuestas por muchos nodos, a con lo cual pueden utilizar OLSR como unico protocolo. En un futuro cuando se masique la integracin de los protocolos de redes mviles en los o o dispositivos, el nmero de integrantes crecer en forma desmedida y OLSR no podr ser utilizado u a a como unico protocolo. OLSR es un protocolo que tiene como desventaja que en redes muy grandes se genera mucho overhead producto de la mantencin de todas las rutas. Cuando esto ocurra o seguramente se utilizarn protocolos h a bridos para minimizar el overhead de la red.
5.4.
Servicios
El objetivo de las redes urbanas es interconectar dispositivos y conformar la red. Sobre esta se puede brindar cualquier tipo de servicio que se pueda prestar sobre una red IP tradicional. En BAL por ejemplo hay nodos que tienen servidores de juegos en red, otros repositorios de archivos, otros nodos comparten ancho de banda de Internet. Fundamentalmente los proyectos de redes urbanas libres no tienen como n proveer Internet a bajo costo ni vender ningn tipo u de servicio. Uno de los proyectos comerciales ms importantes relacionado con las redes urbanas se llama a FON 9 en cual permite a los clientes de FON conectarse a Internet de manera inalmbrica en a cualquier ciudad del mundo donde exista FON.
5.5.
Administracin de la Red BAL o
La red es administrada por los miembros de la comunidad. Los nodos son propiedad de cada uno, es decir cada dueo de su nodo es responsable del mismo como as de los daos que ste n n e pudiese causar. La administracin del nodo es de cada uno pero siempre teniendo como premisa o cumplir con los lineamientos de la comunidad BAL. El nodo debe tener asignada una IP provista por el grupo de Organizacin y debe dar servicio con un rango de IPs asignado como as tambin o e
8 http://www.olrd.org 9 http://www.fon.com
55
5.6. Resumen
existe una convencin de nombres para el ESSID del nodo. Cada propietario del nodo puede o prestar el servicio que quiera siempre y cuando ste no est en contra del esp e e ritu del proyecto. En denitiva cualquiera puede tener un nodo pero para pertenecer a la red BAL debe ser aprobado por el grupo de Organizacin y esto implica la asignacin de los rangos de IP y el o o nombre para el ESSID del nodo.
5.6.
Resumen
En este cap tulo se hizo una explicacin acerca de las redes urbanas, que caracter o sticas topolgicas presentan, cuales son los recursos utilizados para sortear los obstculos puestos por la o a geograf de la ciudad y las limitantes del medio de transmisin. Se presentaron algunos proyectos a o libres que tienen por objetivo conformar una red mvil urbana libre y otros proyectos comerciales. o
56
Cap tulo 6
Protocolo OLSR
El objetivo del presente cap tulo es detallar el funcionamiento del protocolo OLSR y enumerar algunas vulnerabilidades del mismo.
El el cap tulo 2 se present el protocolo OLSR como un protocolo proactivo o basado en o tablas, es decir todos los nodos de la red conocen la manera de llegar a todos los miembros de la misma. En este cap tulo se detallar el funcionamiento del protocolo como tambin se identicarn a e a los puntos en los cuales es necesario aplicar seguridad para mantener la integridad de la red y sus integrantes.
6.1.
Introduccin o
OLSR es un protocolo proactivo [5, Sec. 1.3] para redes mviles ad-hoc denido por la RFC o 3626. El protocolo hereda la estabilidad del protocolo Link-State y tiene la ventaja de disponer de las rutas en el momento que son requeridas. El protocolo mejora de su predecesor el mecanismo de ooding para la distribucin de los o paquetes de control a travs de nodos espec e cos llamados MPRs (Multi Points Relays), los cuales son los unicos que pueden reenviarlos. De esta manera se optimiza la distribucin de los o paquetes evitando retransmisiones. Los MPRs tienen la caracter stica de tener un enlace slido o con su vecino haciendo que la comunicacin sea lo sucientemente estable. o El protocolo OLSR no necesita ninguna modicacin del stack de protocolos ya que se ubica o por encima de este modicando las tablas de ruteo del sistema.
6.2.
Terminolog Propia de OLSR a
Para entender el desarrollo de las prximas secciones es necesario introducir algunos de los o trminos del protocolo OLSR [5, Sec 1.1]. e 57
6.3. Tablas del Protocolo
Nodo: Router que implementa OLSR. Interfase OLSR: Dispositivo de red que participa en la red corriendo OLSR. Un nodo puede tener ms de una interfase, cada una con una direccin IP distinta. a o Direccin Principal: La direccin principal de un nodo es utilizada como direccin o o o originadora del mensaje. Un nodo con mltiples interfases OLSR debe elegir una u unica IP como direccin principal. o Nodo Vecino: Un nodo X es vecino de un nodo Y si el nodo Y puede escuchar al nodo X. Vecino de 2-Saltos: Nodo vecino de un vecino. Multipoint Relay (MPR): Es un nodo vecino del nodo X seleccionado para retransmitir los mensajes broadcast emitidos por X. Multipoint Relay Selector (MPR Selector): El MPR Selector del nodo X, es el conjunto de nodos que eligieron al nodo X como MPR. link: Es el par de interfaces OLSR (de distintos nodos) que pueden escucharse. link simtrico: Es cuando el par de interfaces de distintos nodos pueden escucharse e una con otra. link asimtrico: Es cuando el enlace de dos interfaces OLSR se da en un solo sentido. e Vecino simtrico: Es un nodo vecino con el cual al menos una interfase OLSR tiene e un enlace simtrico. e Vecino simtrico de 2-Salto: Es un vecino simtrico de un vecino simtrico del nodo e e e X.
6.3.
Tablas del Protocolo
Como se explic en la Seccin 2.3.1, OLSR es un protocolo proactivo o basado en tablas, es o o decir toda la informacin necesaria para su funcionamiento es almacenada en tablas. Las tablas o denidas en la RFC, var con las tablas de la implementacin del protocolo, pero los datos an o almacenados en ambas estructuras de tablas son los mismos. Esta simplicacin de tablas es o para hacer ms rpido el mantenimiento de las tablas. Las tablas del protocolo OLSR son las a a siguientes: Multiple Interfase Association Information: En esta tabla se almacenan las interfaces OLSR de los vecinos, es decir, si un vecino tiene dos interfaces OLSR, las dos se asocian a una direccin principal, que ser la utilizada para identicar al nodo. o a o I iface addr: Direccin de una de las interfaces de un nodo. o I main addr: Direccin principal de un nodo. I time: Tiempo de expiracin de la tupla. o Link Set: En esta tabla se almacena el estado de los enlaces con los vecinos.
Protocolo OLSR
L local iface addr: Direccin de la interfase local del nodo (un extremo del enlace). o L neighbor iface addr: Direccin de la interfase del nodo vecino (el otro extremo o del enlace). L SYM time: Es el tiempo que se considera al enlace como simtrico. e L ASYM time: Es el tiempo hasta que se considera como escuchada a la interfase del vecino. L time: Tiempo de expiracin de la tupla. o Neighbor Set: Esta tabla tiene por objetivo almacenar el estado de los vecinos, identicndoa lo solo por la interfaz principal. N neighbor main addr: Direccin principal del nodo vecino. o N status: Especica si el nodo est en estado SYM=enlace simtrico o NOT SYM=enlace a e no simtrico. e N willigness: Es un entero entre 0 y 7 y especica la conanza que se le tiene al nodo vecino para llevar el trco. a 2-hop Neighbor Set: Se almacena el estado de los vecinos de dos saltos de distancia, identicndolo por la direccin de la interfaz principal. a o N neighbor main addr: Direccin principal del nodo vecino. o N 2hp addr: Direccin principal del nodo vecino de 2-Saltos que tiene enlace simtrico o e con N neighbor addr. N time: Tiempo de expiracin de la tupla. o MPR Set: Conformada por las direcciones principales de los nodos seleccionados como MPR. MPR Selector Set: Las direcciones de los nodos que eligieron al nodo donde reside esta tabla como MPR son almacenados en esta tabla. MS main addr: Direccin principal del nodo. o MS time: Tiempo de expiracin de la tupla. o Topology Information: Conformada por las tuplas {T dest addr, T last addr, T seq, T time} T dest addr: Direccin principal del nodo destino que es alcanzado en un salto por o el nodo con direccin principal T last addr. o T last addr: Es MPR de T dest addr. T seq: Nmero de secuencia. u o T time: Tiempo de expiracin de la tupla. Host and Network Asociation Base: Conformada por las tuplas {A gateway addr, A network addr, A netmask, A time} A A A A gateway addr: Direccin de la interfase OLSR del gataway. o network addr: Direccin de red. o netmask: Mscara de la red. a time: Tiempo de expiracin de la tupla. o
59
6.4. Cmo Funciona? o
6.4.
Cmo Funciona? o
OLSR es un protocolo independiente del stack TCP/UDP, es decir utiliza el stack pero no necesita informacin de la capas inferiores para poder operar. El objetivo del protocolo es modio car las tablas de ruteo del Sistema Operativo para poder llegar a todos los nodos de la red, para ello necesita recolectar informacin de su entorno. Esa informacin es relevada con el intercambio o o de mensajes con los vecinos. La comunicacin con los vecinos se realiza mediante paquetes UDP o utilizando el puerto 698 [5, Sec. 3.1]. Los datos obtenidos son almacenados en las tablas descriptas anteriormente para un posterior procesamiento y armado de las rutas. Los mensajes intercambiados son de tres tipos y con tres nalidades distintas. Los mensajes de HELLO son mensajes para relevar el estado de los vecinos de primer y segundo nivel, los mensajes de TC son para informar el estado de los v nculos ms all de los l a a mites del nodo y por ultimo los mensajes MID por los cules se informa a los nodos cuales son las interfaces a disponibles para un determinado nodo. Por medio de estos paquetes es que se conoce como llegar a un determinado nodo. Estos tres tipos de mensajes son los principales para que OLSR pueda funcionar. Adicionalmente, existe la posibilidad de que la red se comunique con otras redes. El armado de esas rutas se hacen por medio del intercambio de mensajes HNA. Se puede separar el funcionamiento del protocolo en distintas etapas. Primera etapa el censado y la deteccin de los vecinos, segunda etapa la seleccin de los MPR, tercera etapa propagacin o o o de la informacin de la topologia de la red, cuarta etapa armado de las rutas y por ultimo una o quinta etapa con el mantenimiento de las misma (Figura 6.1).
6.4.1.
Mensajes de OLSR
El protocolo [5, Sec 3.3] dene un formato de paquete para todos los mensajes del protocolo. Para cada tipo de mensaje lo que var es el contenido del campo MESSAGE que se muestra el la a Figura 6.2. Los campos del mensaje de OLSR son los siguientes: Packet Length: Es el tamao en bytes del mensaje. n Packet Sequence Number: Nmero de secuencia, el cual es incrementado en uno u con el env de cada paquete. o Message Type: Indica que tipo de mensaje se encontrar en el campo MESSAGE. a Vtime: Este campo indica por cuanto tiempo despus de la recepcin debe considerar e o la informacin como vlida. o a Message Size: Indica el tamao del mensaje en bytes. Cuenta desde el campo n Message Type hasta el comienzo de otro Mesage Type. Originator Address: Es la direccin principal del nodo que gener el mensaje. o o Time to Live: Contiene el mximo nmero de veces que el mensaje debe ser rea u transmitido (cantidad de saltos que debe recorrer). Hop Count: Nmero de saltos por los que el paquete ha pasado. u
Protocolo OLSR
Figura 6.1: Etapas del protocolo OLSR
Message Count Sequence: Nmero de secuencia unico para cada mensaje. Este u nmero se incrementa en uno con el env de cada mensaje. u o
6.4.2.
Etapa 1: Censado y Descubrimiento de Vecinos
En esta etapa del protocolo es donde el nodo analiza su entorno en busca de vecinos y el tipo de v nculo por el cual los alcanza. Como se coment anteriormente esta tarea es realizada por el o intercambio de mensajes de HELLO. 6.4.2.1. Mensaje de HELLO
Este mensaje es parte del paquete OLSR descripto anteriormente en la Seccin 6.4.1 donde es o inclu en el campo MESSAGE del mismo con Message Type=HELLO MESSAGE. La estructura del do
6.4.2. Etapa 1: Censado y Descubrimiento de Vecinos
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Packet Length | Packet Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Type | Vtime | Message Size | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Originator Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Time To Live | Hop Count | Message Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | : MESSAGE : | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Type | Vtime | Message Size | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Originator Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Time To Live | Hop Count | Message Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | : MESSAGE : | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : (etc.)
Figura 6.2: Formato del paquete de OLSR
mensaje de HELLO que se muestra en la Figura 6.4 contiene los siguientes campos: Reserved: Campo completado por 0000000000000000. Htime: Indica el tiempo de emisin de los mensajes de HELLO del nodo que lo origina. o Willingness: Es una valor del 0 al 7 que indica la conabilidad de un nodo para retransmitir un mensaje. Por ejemplo un nodo con valor WILL NEVER nunca va a ser elegido como MPR, un nodo con WILL ALLWAYS, siempre va a ser elegido como MPR. El valor por defecto es WILL DEFAULT. Link Code: Este campo indica el tipo de v nculo que hay entre la interfase de quien env el mensaje con el listado de interfaces de los vecinos. Este campo es de 8 bit a de los cuales solo se interpretan los cdigos menores o iguales a 15 como el par de o cdigos como se indica en la Figura 6.3 o
7 6 5 4 3 2 1 0 +-------+-------+-------+-------+-------+-------+-------+-------+ | 0 | 0 | 0 | 0 | Neighbor Type | Link Type | +-------+-------+-------+-------+-------+-------+-------+-------+
Figura 6.3: Campo de 8 bits para indicar el cdigo del enlace o
Los cdigos de los posibles v o nculos se denen como:

Protocolo OLSR
UNSPEC LINK: No se especica informacin acerca del enlace. o ASYM LINK: Link asimtrico. e SYM LINK: Link simtrico. e LOST LINK: Prdida del v e nculo. Los cdigos de los tipos de vecinos se denen como: o SYM NEIGH: Indica que al menos una de la interfaces del vecino tiene un enlace simtrico con el nodo. e MPR NEIGH: Indica que al menos una de la interfaces del vecino tiene un enlace simtrico con en nodo y a su vez el vecino fu seleccionado como e e MPR por el originador del mensaje. NOT NEIGH: Todav no se tiene un v a nculo simtrico con el vecino. e Link Message Size: Indica el tamao del mensaje en bytes. Cuenta desde el campo n Link Code hasta el comienzo de otro Link Code. Neighbor Interfase: La direccin de una interfase de un vecino. o
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Htime | Willingness | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link Code | Reserved | Link Message Size | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Neighbor Interfase Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Neighbor Interfase Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : . . . : : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link Code | Reserved | Link Message Size | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Neighbor Interfase Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Neighbor Interfase Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : : : (etc.)
Figura 6.4: Formato del mensaje de HELLO
6.4.2.2.
Mensaje MID
Cada nodo integrante de la red puede tener ms de una interfase OLSR, pero solo una direccin a o principal, por eso es que existe un mensaje que informa a los nodos que un determinado nodo cuenta con determinadas interfaces OLSR y env las direcciones de las mismas. a
6.4.2. Etapa 1: Censado y Descubrimiento de Vecinos
Este mensaje es parte del paquete de OLSR donde es inclu en el campo MESSAGE del mismo. do La estructura del mensaje MID que se muestra en la Figura 6.5 donde OLSR Interfase Address es la direccin de cada una de la interfaces. En el header del mensaje OLSR se indica que la IP o que env el mensaje es la direccin principal del nodo, por lo tanto el nodo que recibe el mensaje a o asocia esa direccin principal con las listadas en el mensaje. o
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OLSR Interfase Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OLSR Interfase Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figura 6.5: Formato del mensaje MID
6.4.2.3.
Censado y Descubrimiento
El proceso de descubrimiento ser analizado a partir de las Figuras 6.6 y la Figura 6.7 donde a se plantea un ejemplo paso a paso donde el nodo A se incorpora a la red. En las Figuras se hace una referencia cronolgica de cmo se van intercambiando los mensajes y cmo estn las tablas o o o a de cada nodo en cada uno de los instantes. Para una mejor interpretacin y claridad en la gura, o las tablas Neighbor Set, 2-hop Neighbor Set y MPR Set son agrupadas en una sola tabla llamada Neightbor Table. En la Figura 6.6 en el instante t1 se puede ver que el nodo A env el mensaje de HELLO a vac y un mensaje MID indicando que solo tiene una interfase OLSR. El nodo B tiene como o vecino y MPR al nodo C y este tiene a B como vecino y MPR. En el instante t2 el nodo B recibe el mensaje de HELLO de A, agrega una entrada en la Link Table donde indica que A es vecino, recibi el mensaje por la interfase A, es un v o nculo asimtrico (notar que pone como valor tiempo de vida del enlace simtrico con un valor vencido, e e es decir t2 -1). En la tabla de vecinos agrega al nodo A indicando que es un vecino asimtrico y e no es MPR ni vecino de segundo salto. En ese mismo instante, B env un mensaje de HELLO informando el estado de sus enlaces a clasicados por tipo y un mensaje MID diciendo que solo tiene la interfase con la direccin B. o En la Figura 6.7 en el instante t3, el nodo A recibe el mensaje de B y ve que su direccin es o parte del mensaje recibido, por lo tanto agrega una entrada en la tabla de enlaces indicando que el enlace con B es simtrico. Agrega una entrada en la tabla de interfaces con la interfase de B. e Agreg en la tabla de vecinos al nodo B como simtrico y al nodo C como vecino de 2-Saltos ya o e que ste tiene enlace simtrico con B. El nodo C no actualiza la informacin del nodo A porque e e o el nodo B an tiene un enlace asimtrico con A y un vecino de 2-Saltos es considerado cuando u e hay un enlace simtrico entre el vecino y el vecino de dos saltos de distancia. e En ese mismo instante A env un mensaje de HELLO con la informacin de sus enlaces. a o
Protocolo OLSR
Figura 6.6: Censado y Descubrimiento de Vecinos - Parte 1
En el instante t4, el nodo B recibe el mensaje de A y ve que su direccin est listada y actualiza o a la entrada en tabla de enlaces indicando que el tiempo del enlace simtrico es un tiempo vlido. e a En la tabla de vecino actualiza la entrada de A indicando que es un vecino simtrico. e En ese instante B env un mensaje de HELLO. a En el instante t5 el nodo C se entera que existe un enlace simtrico entre A y B y agrega una e entrada en la tabla de vecinos para A indicando que es vecino de 2-Salto.
6.4.3.
Etapa 2: Eleccin de los MPRs o
OLSR mejora el mecanismo de ooding de otros algoritmos similares con la eleccin de de o nodos como Multi Point Realys para minimizar los paquetes de control en la red. Por lo tanto cada nodo debe escoger un conjunto de nodos pertenecientes a sus vecinos de primer nivel como MPR de manera tal que a travs de ellos pueda llegar a todos los vecinos de dos saltos de distancia e (vecinos 2-Saltos). Para la eleccin de los MPRs, el RFC [5, Sec. 8.3.1] dene una heur o stica, la cual debe ser aplicada por cada interfase OLSR del nodo. El conjunto de MPRs de un nodo es la unin de los o
6.4.3. Etapa 2: Eleccin de los MPRs o
Figura 6.7: Censado y Descubrimiento de Vecinos - Parte 1
MPRs encontrados para cada interfase. Para la denicin de la heur o stica es necesario denir algunos trminos: e Vecino de una Interfase: Vecino que tiene un enlace con el nodo local a travs de una e interfase OLSR en particular. N: Subconjunto de vecinos de un nodo, los cuales son vecinos de la interfase I. N2: Conjunto de vecinos 2-Saltos que son alcanzados a travs de la interfase I. exclue yendo: Los nodos que solo son alcanzados por los miembros de N con willigness distinta de WILL NEVER El nodo que realiza el clculo del MPR (nodo local) a
Protocolo OLSR
Figura 6.8: Multipoint Relays
Todos los vecinos simtricos: todos los nodos que tengan un enlace e simtrico en alguna de la interfaces. e D(y): El grado del nodo y (donde y es miembro de N ), est denido por la a cantidad de vecinos simtricos que tenga el nodo y (en todas sus interfaces), e excluyendo todos los miembros de N y el nodo que est realizando el a clculo. a La heur stica de seleccin de los MPRs es: o 1. Selecciona los nodos del Nivel 1 (N ) que cubren nodos aislados del Nivel 2 (N 2). Nodo aislado es aquel nodo que pertenece al Nivel 2 y tiene como vecino a un solo nodo del Nivel 1. Adems se seleccionarn todos los nodos de N con willigness igual a WILL ALWAYS a a 2. Se toman los vecinos de Nivel 1 que no fueron seleccionados en el paso anterior y se selecciona el nodo que cubra el mayor nmero de nodos de Nivel 2. Esto se repite hasta que todos u los nodos de Nivel 2 hayan sido cubiertos. En caso de empate, se elige el nodo con mayor willigness, en caso de que esto de mltiples nodos, se va a elegir aquel nodo con mayor u (D(y)). En caso que los criterios anteriores no elijan un unico nodo se seleccionar de a manera aleatoria. Ejemplo: Este ejemplo mostrar como se realiza la eleccin de los MPRs para el nodo O a o donde todos los nodos tienen willigness igual a WILL DEFAULT. En la gura 6.9(a) se ve al nodo O con la distribucin de vecinos. N = {1, 2, 3, 4, 5, 6} y N 2 = {7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18}. o En la primera fase se eligen aquellos vecinos que cubren los nodos aislados de Nivel 2 (2 y 5), es decir M P R1 (O) = {N (v) N 2(O) | N (O) N (v) |= 1} donde v N (O) como se muestra en la Figura 6.9(b). El algoritmo, al nalizar la primera fase, elimina de los conjuntos de nodos aquellos que ya fueron elegidos como MPR y los nodos de Nivel 2 alcanzados por los MPRs seleccionados como se ve en la Figura 6.10(a). El prximo paso es ejecutar la segunda fase donde selecciona de los nodos de Nivel 1 aquellos o que cubran ms cantidad de nodos de Nivel 2 hasta cubrir todos los de Nivel 2. Para ello realiza a
6.4.4. Etapa 3: Mantenimiento de la Topolog a
una iteracin donde elige como MPR un nodo que cumpla con M P R2 (O) = {maxwN (O) | o N 2(O)N (w) |} como se ve en la Figura 6.10(a) y elimina del conjunto de nodos para la prxima o iteracin el MPR seleccionado y los nodos de Nivel 2 alcanzables por el mismo (Figura 6.10(b)). o Notar que en el momento de eleccin del nodos 4 y el nodo 1, se los elige porque estos tiene mayor o cantidad de vecinos (D(y)). Finalmente los MPRs seleccionados son los que se muestran en la Figura 6.8.
(a) Distribucin de vecinos: o
(b) Seleccin de los nodos de Nivel 1 que tienen veo cinos aislados
Figura 6.9: Fase 1 : Seleccin de MPRs que cubren nodos aislados del Nivel2. o
(a) Primera iteracin de la segunda fase o
(b) Segunda iteracin de la segunda fase o
Figura 6.10: Fase 2: Se completa la seleccin de MPRs. o
El conjunto de MPRs son recalculados cada vez que hay algn cambio en los enlaces con los u vecinos. Cuando un nodo recibe un mensaje de HELLO donde ve que el vecino lo seleccion a l como o e e o MPR (tipo de vecino igual a MPR NEIGH), ste agrega la direccin principal del nodo generador del mensaje en la tabla de MPR Selector. Por medio de esa tabla un nodo pueda saber quien lo eligi a l como MPR. o e
6.4.4.
Etapa 3: Mantenimiento de la Topolog a
OLSR por ser un protocolo proactivo, debe conocer las rutas hacia todos los destinos de la red, para ello debe conocer cual es la topolog de la misma. Como el dominio de cada nodo a
Protocolo OLSR
es conocer la informacin de los nodos hasta dos saltos de distancia, necesita alguna manera de o conocer la topolog de la red ms a all de ese l a a a mite. OLSR implementa un sistema de mensajes para informar a los nodos la topolog de la red y los cambios que se produzcan. Para transmitir a esta informacin OLSR usa un tipo de mensaje llamado Topology Control (TC). o 6.4.4.1. Mensaje TC
El mensaje TC es parte del paquete de mensaje de OLSR descripto en 6.4.1 en el campo MESSAGE con Message Type=TC MESSAGE. La estructura del mensaje TC es la que se muestra en la Figura 6.11 cuyos campos son: Advertised Neighbor Sequence Number (ANSN): Nmero de secuencia para el conu junto de enlaces informados. Este nmero cambia cada vez que un enlace es agregado u o removido del conjunto. Advertized Neighbor Main Address: Es la direccin principal de un nodo vecino. o Reserved: Campo completado por 0000000000000000.
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ANSN | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Advertised Neighbor Main Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Advertised Neighbor Main Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figura 6.11: Formato del mensaje TC
6.4.4.2.
Mecanismo de propagacin de los mensajes TC o
Para poder diseminar por la red y que cada nodo pueda completar las tablas de topolog a es necesario que cada nodo que haya sido seleccionado como MPR genere un mensaje TC y lo transmita en forma de broadcast. Cada nodo debe diseminar al menos el conjunto de enlaces con los nodos que lo eligieron como MPR, o sea los enlaces con su MPR Selector. En el caso de que la cantidad de enlaces a informar sea mayor a la capacidad del mensaje, se debern enviar tantos mensajes como sea necesario hasta informarlos todos. a Cuando un nodo recibe un mensaje TC realiza los siguientes pasos: 1. Si la interfase del que env el mensaje no est entre los vecinos simtricos de un salto de a a e distancia, se descarta el mensaje. o 2. Si existe alguna tupla en la tabla de topolog donde T last addr sea igual a la direccin a de origen del mensaje y exista un T seq mayor a ANSN, el mensaje se descarta. Es el caso de un mensaje viejo.
6.4.5. Etapa 4: Formacin de las Rutas o
3. Todas las tuplas donde T last addr sea igual a la direccin de origen del mensaje y exista o un T seq menor al ANSN del mensaje son eliminadas. 4. Para cada una de las entradas de la tabla de topolog donde T dest addr sea igual a las a direcciones informadas en el mensaje y T last addr sea igual a la direccin de origen del o mensaje, se actualiza el tiempo de vida de la tupla. 5. Para el resto de las direcciones informadas que no estaban en la tabla de topolog son a, agregadas.
6.4.5.
Etapa 4: Formacin de las Rutas o
Cada nodo tiene una tabla de ruteo con la cual puede llegar a cualquier nodo de la red y rutear datos hacia cualquier destino. Esta tabla esta basada en la informacin recolectada en la o tabla de enlaces y en la tabla de topolog Por esa razn es que cualquier alteracin en dichas a. o o tablas provocan un clculo de todas la ruta. a Cada una de las entradas en la tabla de ruteo tiene la siguiente forma: 1. 2. 3. R_dest_addr R_dest_addr ,, R_next_addr R_next_addr ,, R_dist R_dist ,, R_iface_addr R_iface_addr ,,
donde R dest addr es la direccin principal de un nodo que se espera que est a R dist saltos o e e del nodo actual, R next addr es un vecino que tiene un enlace simtrico con el nodo actual y es el prximo salto hacia el destino R dest addr y ese vecino lo alcanza a travs de la interfase local o e R iface addr. Para construir una ruta, se utiliza el algoritmo de camino ms corto (Shortest Path Algorithm. a Para la construccin de la tabla de ruteo se siguen los siguientes pasos: o 1. Se borran todas la entradas de la tabla 2. Se agregan las rutas para todos los vecinos que tienen enlaces simtricos e 3. Por cada nodo perteneciente a los vecinos de 2-Saltos se crea una entrada indicando R R R R R R dest addr=direccin principal del nodo de 2-Saltos o next addr=entrada de tabla de ruteo R dest addr donde dest addr=N neighbor main addr de la tabla 2-hop Neigbor Set dist=2 iface addr=entrada en la tabla de ruteo iface addr=N neighbor main addr de la tabla 2-hop Neigbor Set
donde
4. El siguiente procedimiento debe ser ejecutado desde h=2 hasta que no se existan ms ena tradas para agregar.
Protocolo OLSR
Para cada entrada de la tabla de topolog si existe T dest addr que es distinto a, a todos los R dest addr de la tabla y el T last addr es igual a un R dest addr de una entrada de la tabla de ruteo, se agrega una nueva entrada. R R R R R R dest addr=T dest addr next addr=R next addr de una entrada de tabla que cumple dest addr=T last addr dist=h+1 iface addr=R iface addr de una entrada de la tabla que cumple dest addr=T last addr
5. Por cada entrada en la tabla de interfaces, cuando exista una entrada donde R dest addr=I main addr (de una asociacin con varias interfaces) y no exista una eno trada para cada asociacin del tipo R dest addr=I iface addr, se crea una entrada en la o tabla a modo de alias para cada interfaz. R R R R dest addr = I iface addr next addr = R next addr de la entrada en la tabla dist = R dist iface addr = R iface addr de la entrada en la tabla
6.4.6.
Etapa 5: Mantenimiento de las Rutas
El mantenimiento de las rutas es un proceso que se realiza automticamente cada vez que a se altera un enlace. La alteracin de un enlace puede ser que se haya agregado un nuevo vecino o o que alguna de las entradas de las tablas expir con lo cual es necesario recalcular la tabla de o ruteo. Por esta razn siempre que haya una tabla calculada, todas las entradas son vlidas. o a
6.4.7.
Comunicacin con Otras Redes o
El protocolo OLSR fue diseado para que los nodos de la red no solo se comuniquen entre n ellos, sino tambin da la posibilidad de poder comunicarse con otras redes. Para lograr esto, el e protocolo env mensajes llamados HNA. a 6.4.7.1. Mensaje HNA
El mensaje HNA es enviado como MESSAGE en el paquete general de OLSR denido en la Seccin 6.4.1 con Message Type=HNA MESSAGE. El formato del mensaje se muestra en la Figura 6.12 o cuyos campos son: Network Address: Direccin de la red asociada o Netmask: Mascara para la red asociada.
71
6.5. Seguridad
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Network Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Netmask | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Network Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Netmask | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figura 6.12: Formato del mensaje HNA
6.4.7.2.
Asociacin de la redes o
Los mensaje HNA, son emitidos por todos los nodos informando las redes externas a las cuales el nodo puede acceder. Estos mensajes son similares a los mensajes TC ya que indican un camino hacia una nueva red. A diferencia de los mensajes TC los HNA incluyen el campo netmask correspondiente para la red. De esta manera cuando un nodo recibe un mensaje HNA, agrega una entrada en la tabla de o asociacin de nodos y redes con A gateway addr igual a la direccin principal de donde provino o el mensaje y con la direccin de la red y la mscara que vienen en el mensaje y se le coloca un o a tiempo de expiracin a la tupla. o Estas nuevas rutas hacen que la tabla de ruteo las deba incluir. Por lo tanto, al procedimiento de actualizacin de la tabla de ruteo descripto en la Seccin 6.4.6 se le debe agregar que para o o cada una de las entradas de la tabla de asociacin de nodos y redes se debe crear una nueva o entrada en la tabla de ruteo donde: R R R R R dest addr=A network addr/A netmask next addr=R next addr de una entrada donde R dest addr=A gateway addr dist=R dist de la entrada al gateway iface addr=R iface addr de la entrada en la tabla donde dest addr=A gateway addr
6.5.
Seguridad
El protocolo OLSR no tiene especicadas medidas de seguridad [5, Sec. 20]. Como OLSR es un protocolo proactivo es muy sensible a cualquier ataque y puede poner en peligro la integridad de la red.
6.5.1.
Condencialidad
OLSR env peridicamente mensajes con informacin de la topolog de la red, esa informaa o o a cin puede ser usada por un atacante y modicar la topolog de la red. El RFC de OLSR no o a
Protocolo OLSR
dene ninguna alternativa para garantizar la condencialidad de los mensajes de control. Solo propone utilizar mecanismos de encriptacin de clave compartida o usar PGP sin brindar detalles o de la forma de su implementacin. o
6.5.2.
Integridad
En OLSR cada nodo inyecta en la red informacin de la topolog a travs de los mensajes de o a e HELLO y TC. Por ser el medio de propagacin de los mensaje el aire, es un medio no controlado o y cualquier nodo podr enviar informacin invlida con lo cual se compromete la integridad de a o a la red. Por lo tanto, algn mecanismo de autenticacin debe ser implementado pero el RFC [5] no u o indica con qu algoritmo, ni de que forma, slo recomienda el uso de autenticacin para prevenir e o o alguna de estas situaciones: 1. Un nodo genera mensajes TC (o HNA) informando enlaces con nodos que son vecinos 2. Un nodo genera mensajes TC (o HNA) en nombre de otro nodo 3. Un nodo genera mensajes de HELLO informando que tiene vecinos que no lo son 4. Un nodo genera mensajes de HELLO hacindose pasar por otro nodo e 5. Un nodo reenv mensajes de control alterados a 6. Un nodo no reenv un mensaje de control a 7. Un nodo no selecciona su MPR correctamente 8. Un nodo replica mensajes de control grabados de otro nodo La autenticacin previene alguna de estas situaciones pero no todas. Para prevenir el punto o 8 es necesario implementar algn mecanismo de informacin temporal para que un nodo pueda u o identicar claramente los mensajes viejos. En general los paquetes necesarios para la autenticacin, pueden ser enviados dentro del o paquete genrico de OLSR como un tipo de mensaje distinto. De esta manera se podr hacer e a que convivan nodos seguros y nodos inseguros.
6.5.3.
Mensajes a Proteger
Los mensajes que deben ser protegidos contra nodos malicioso son los mensajes de HELLO, los TC y los HNA. Estos paquetes son los encargados de armar y diseminar por la red la informacin o de la topolog de la misma. Un atacante puede usar estos mensajes y modicarlos para benecio a propio. Es necesario que estos mensajes sean encriptados y autenticados para garantizar condencialidad e integridad de los mensajes. Aplicando seguridad sobre estos mensajes no garantiza que la red va a ser segura ya que nodos participantes de la red pueden causar intencionalmente o no ataques, pero eliminar muchos a posibles atacantes externos.
6.6. Vulnerabilidades
6.6.
Vulnerabilidades
OLSR por ser un protocolo que corre sobre el stack TCP/UDP, tiene las vulnerabilidades intr nsecas con la tecnolog en la cual se apoya para operar. Estos ataques son comunes a todos a los protocolos que trabajan en esta modalidad, los ataques son ataques a la capa f sica y MAC, generando interferencias sobre el canal y saturando a la v ctima con mensajes. Este tipo de ataques no son tenidos en cuenta por los protocolos ya que es tarea de las capas inferiores mitigar estas amenazas. En OLSR cada nodo tiene dos responsabilidades fundamentales. La primera es que cada nodo debe generar la informacin de ruteo de manera correcta y la segunda es que cada nodo es o responsable de reenviar los paquetes recibidos a otros nodos de la red. Cualquier alteracin de o estas responsabilidades pueden terminar amenazando la integridad de la red.
(a) El nodo O env un mensaje de HELLO prea tendiendo ser 3
(b) El nodo O env un mensaje de HELLO anunciaa do un link falso con 1
Figura 6.13: Generacin incorrecta de mensajes HELLO o
Algunas de las vulnerabilidades presentes en OLSR [20, Sec. IV] son: A. Generacin Incorrecta de Mensajes de Control o a) Generacin incorrecta de mensajes HELLO: Un posible ejemplo de este ataque es que o un nodo malicioso puede tomar la identidad de otro nodo (Figura 6.13(a). El nodo O se toma la identidad de 3. Los nodos 1 y 2 anuncian que pueden llegar a 3 a travs e de sus mensajes de HELLO y TC. El nodo O elige MPRs entre sus vecinos siempre en nombre del nodo 3, por lo tanto los nodos que fueron elegidos como MPR, informan en sus mensajes TC que ellos son el ultimo salto hacia 3. Esto genera conictos en las rutas hacia 3 y podr dejar al nodo con prdida de conexin. a e o Otro ataque con esta modalidad es la modicacin de enlaces [15, Sec. III.A] que tiene o un nodo (Figura 6.13(b)). En este caso el nodo O env en su mensaje de HELLO que a tiene un enlace con 1 (que no es vecino). Esto tiene como consecuencia que el nodo 3 tenga un MPR Set incorrecto y los mensajes provenientes de 5 y reenv ados a travs de e los MPRs nunca llegue a 1. b) Generacin incorrecta de mensajes TC [15, Sec. III.B]: La generacin de mensajes TC o o con direccin de origen incorrecta puede generar informacin errnea referente a la reo o o
Protocolo OLSR
Figura 6.14: Generacin incorrecta de mensajes TC o
lacin de los vecinos (Figura 6.14). El nodo malicioso O env un mensaje TC en lugar o a del nodo 3 informando que el nodo 1 es su vecino. El nodo 4 concluye de manera errnea o que 3 y 1 son vecinos. La generacin de mensajes TC con informacin de enlaces falsos o o tiene las mismas consecuencias. c) Generacin incorrecta de mensajes MID/HNA: Un nodo podr enviar mensajes ino a formando que tiene determinada interfase emitiendo el mensaje con una direccin de o origen perteneciente a otro nodo. Este ataque hace que los nodos que reciben el paquete no puedan alcanzar al nodo real a travs de la interfase que envi el nodo malo ya que e o esa interfase no existe. d ) Ataque a los nmeros de secuencia: Un nodo malicioso podr escuchar los mensajes TC u a de un nodo A y almacenar el ANSN (Advertised Neighbor Sequence Number ) del mensaje, luego env mensajes falsicando la direccin de origen con ANSN mucho mayores que el a o almacenado. Segn el protocolo, los nodos ignorarn los mensajes con ANSN menores al u a ultimo recibido, por lo tanto los mensajes de A sern descartados porque sern tomados a a como viejos. B. Reenv Incorrecto de Mensajes de Control o a) Ataque del Agujero Negro: Este ataque se produce cuando un nodo no reenv los mena sajes como lo requiere el protocolo, de este modo se disminuye la informacin de los o enlaces disponibles en la red. Si los mensajes TC no son reenviados, la red comienza a tener problemas de conectividad y hasta podr llegar a dividirse. Si no se reenv los a an mensajes HNA, se podr perder el acceso hacia otras redes. a b) Ataque por Reenv de Mensajes: Un nodo atacante podr grabar todos los mensajes o a que pasaron por l durante un determinado per e odo y luego ms tarde reinyectarlos en a la red modicando todas las tablas de ruteo de los nodos. Los mensajes TC no pueden ser inyectado en la misma manera como fueron grabados, sino que de debe poner un nmero ANSN grande para que sean aceptados por los nodos, causando de esta manera u un ataque de nmero de secuencia. u c) Ataque del tnel ( wormhole attack) [18, Sec. 4]: Este ataque tiene mucho impacto en la u red. Consiste en grabar el trco en un sector de la red y reproducirlo tal cual en otra a
6.6. Vulnerabilidades
(a) Tnel creado por O entre 3 y 4 u
(b) T nel creado por O y O (cmplices) entre u o 3y4
Figura 6.15: Ataque por tnel (Wormhole) u
regin de la misma. Se puede generar un enlace articial entre el nodo 3 y el 4 a travs o e de un nodo atacante (Figura 6.15(a)) o si un nodo agresor tiene un cmplice y puede o generar un tnel fuera de la red y conectarse a una regin ms lejana (Figura 6.15(b)). u o a El agresor puede explotar este ataque cuando los nodos 3 y 4 hayan intercambiado sucientes mensajes de HELLO a travs del tnel como para establecer un enlace simtrico. e u e Mientras el enlace no sea simtrico, los mensajes TC/MID/HNA son descartados. Con e el enlace simtrico establecido, todos los paquetes que vayan de un extremo al otro de la e red van a ser enviados a travs del tnel porque se va a creer que es la ruta ms corta y e u a el trco va a pasar todo por el nodo atacante. a d ) Ataque al ( MPR-Flooding): Una de las primeras reglas de transmisin enunciada en la o especicacin de OLSR es que durante el proceso de ooding de los MPRs, los mensajes o recibidos son vericados si provienen de un nodo dentro del MPR Selector del nodo y los mensajes iguales recibidos posteriormente son descartados. Por ejemplo un nodo A env a un mensaje B y X (nodo malicioso), donde B es MPR de A y X no el MPR. X reenv a (sin tener que hacerlo segn la especicacin) el mensaje a C, luego B tiene como MPR u o a C y reenv el mensaje a A. Ese mensaje es descartado porque el mismo mensaje de a lo envi X con lo cual resulta que se interrumpe el ujo del paquete (Figura Bd ). o
Figura 6.16: Ataque al (MPR-Flooding)
C. Ganar posicin privilegiada: Cualquiera de los ataques antes mencionados pueden ser o explotados de mejor manera si el nodo es posicionado como MPR, para ello el nodo primero
Protocolo OLSR
ingresa a la red y env los mensajes de HELLO con Willingness WILL ALWAYS. De esta a manera es muy probable que algn nodo lo elija como MPR y una vez ubicado comienza con u cualquiera de los ataques.
6.7.
Resumen
En este cap tulo se mostr el funcionamiento del protocolo OLSR, cuales son los mensajes que o se intercambian, que informacin viaja en cada paquete y como utiliza cada nodo esa informacin. o o Se vi como construye cada nodo sus propias tablas de ruteo con la informacin recolectada de o o los nodos vecinos y de la red en general. Se realiz una presentacin de las vulnerabilidades que o o presenta el protocolo, las cuales sern analizadas y se propondr una contramedida en el protocolo a a para hacerlo ms robusto. a
77
6.7. Resumen
78
Cap tulo 7
Dise o de un Esquema de n Seguridad para una Red Mvil o OLSR Urbana

El objetivo de este cap tulo es presentar el diseo del esquema de seguridad para n una Red Mvil basada en OLSR teniendo en cuenta los aspectos organizacionales de o las comunidades que las administran y cuestiones propias del protocolo.
En el Cap tulo 5 se present como es la topolog y el funcionamiento de una Red Mvil Urbao a o na. Teniendo en cuenta las caracter sticas de una red de este tipo y las cuestiones administrativas de la comunidad que la mantiene es que se va a disear un esquema de seguridad para dichas n redes.
7.1.
Esquema de Seguridad
Un esquema de seguridad son combinaciones de primitivas (operaciones matemticas bsia a cas) combinadas con mtodos adicionales [22]. Los esquemas proveen seguridad terica y sta es e o e mejorada cuando es aplicada apropiadamente en un protocolo para poder cumplir con las caracter sticas de seguridad enumeradas en el Cap tulo 4. Es decir, todos los elementos auxiliares para que un nodo, por ejemplo, pueda encriptar el trco, autenticarse con el nodo remoto y a estar seguro que el nodo remoto es al que se le quiere enviar la informacin. Para lograr esto es o necesario disear y establecer un esquema de seguridad que especique claramente los roles que n tienen cada uno de los elementos que lo componen y de qu manera se relacionan. e 79
7.2. Fundamentos del Dise o n
7.2.
Fundamentos del Dise o n
El diseo del esquema de seguridad utiliza la topolog de una Red Mvil Urbana y a la vez n a o la forma de organizacin de la comunidad que la conduce. o Con lo que respecta a la topolog de la red se tiene en cuenta que en una Red Mvil Urbana a o se cuenta con un nmero de nodos jos, los cuales garantizan la intercomunicacin de los nodos u o que a nivel de tierra no pueden hacerlo debido a que la tecnolog utilizada para la comunicacin a o (IEEE 802.11x) necesita linea de visin directa con el otro extremo del v o nculo. Estos nodos tienen un rol importante dentro de la red y deben estar dados de alta y ser reconocidos por la Comunidad y haberles asignado una IP, un rango de IPs para poder brindar servicio y un ESSID (nombre de red) estandarizado dentro de la Comunidad. Este aspecto organizativo es el que se tiene en cuenta en el diseo del esquema. n El esquema de seguridad propuesto tiene como objetivo hacer una Red Mvil Urbana Segura o y para ello se necesita un protocolo de ruteo que sea seguro. Para cumplir con este requisito se van a denir tres niveles o etapas de securizacin del protocolo. La primer etapa tiene en cuenta o brindar los servicios bsicos que debe tener una red segura como se describi en el Cap a o tulo 4. La segunda etapa tiene por objetivo mejorar las capacidades de defensa ante los ataques ms comunes a (Sec. 6.6) y por ultimo la tercer etapa en la cual la red pueda ser capaz de autodefenderse ante un ataque. Para lograr los objetivos de esquema de seguridad se plantea el uso de un esquema de clave pblica y privada, distribuidas por medio de certicados. Cada cliente de la red necesitar un u a certicado para poder comunicarse. Ese certicado es expedido por una Autoridad Certicante (CA) perteneciente a la red. El uso de un esquema de clave pblica y privada es el pilar sobre el cual se va a basar u la implementacin de un protocolo seguro para garantizar la seguridad de la primera etapa de o securizacin. o Un elemento importante a la hora de describir la tercera etapa de seguridad es un Sistema de Deteccin de Intrusos (Intrusion Detection System - IDS ) que es responsable de monitorear o el comportamiento de los integrantes de la red. Este componente se basa en reglas de comportamiento que son establecidas por el administrador o auto-aprendizaje. En caso que un miembro de la red tenga un comportamiento indebido, el IDS env dicha informacin a la Autoridad a o Certicante y se deniega su participacin en la red revocando su certicado. o Los componentes (CA, IDS) deben correr en nodos que la Comunidad establece como conables. No siempre el IDS y la CA deben correr en el mismo nodo pero s los nodos deben ser seguros.
7.2.1.
OLSR ms Fuerte a
El corazn del diseo de una red mvil segura es contar con un protocolo de ruteo conable o n o y seguro. Para ello y como se mencionaba antes se va tratar la seguridad del mismo por etapas o niveles de seguridad. El fortalecimiento de OLSR toma como punto de partida el esquema de certicacin que le va a proveer certicados para asegurar el canal de comunicacin entre o o
Dise o de un Esquema de Seguridad para una Red Mvil OLSR Urbana n o
Figura 7.1: Componentes participantes en el esquema de seguridad propuesto
los nodos. En la segunda etapa el protocolo original es modicado para prevenir los ataques ms comunes (timestamp attack, wormhole attack, DoS, etc). Por ultimo se propone un tercer a nivel de seguridad, en el cual la misma red se deende de los intrusos. Este nivel ser descripto a brevemente y queda fuera del alcance de la presente tesis.
7.3.
Esquema de Clave P blica y Privada u
Como componente principal se busca lograr la autenticacin de cada uno de los nodos para o poder conar y estar seguro que son nodos pertenecientes a la red. Para ello se utilizar un a esquema de clave pblica y privada mediante el uso de certicados digitales. u
7.3.1.
Autoridad Certicante
Como se enunciaba en la Sec 3.1.6 una Autoridad Certicante es un componente de PKI (Public Key Infreatructure) encargada de otorgar y revocar certicados digitales. El rol de la CA dentro de la infraestructura es validar la autenticidad de claves pblicas. El u proceso de generacin de claves comienza cuando un miembro genera un par de claves y solicita o a la CA que rme su clave pblica, la CA genera un certicado incluyendo la clave pblica de la u u solicitud y rma este certicado con su clave privada. De esta manera cualquier nodo que tenga la clave publica de la CA puede estar seguro que la clave pblica recibida de otro nodo es conable. u T picamente una CA es unica en la red y sto puede hacer que nodos no lleguen a sta debido e e a interrupciones temporales de enlaces u otras cuestiones propias de la topolog de las redes a mviles. o
7.3.2.
Esquema de Certicacin o
El esquema de seguridad planteado tiene como punto de partida la utilizacin de certicados o digitales para autenticar las partes. Para ellos va a existir una Autoridad Certicante perteneciente a la comunidad (por ejemplo Buenos Aires Libre). Cada nodo que participa en la red, debe solicitar a la comunidad una serie de datos para poder operar en la misma (IP para el nodo, rango de IPs para asignar a sus clientes, un SSID
7.3.2. Esquema de Certicacin o
estandarizado). La comunidad enrola a este nuevo nodo, registra el nodo a la red, le da la informacin requerida y en conjunto con los datos solicitados se le da un certicado rmado por la o CA de la comunidad. Por ser un nodo enrolado, y la comunidad conoce al dueo del nodo, es n considerado seguro. De esta manera el nodo con el certicado expedido por la CA de la comunidad va a poder rmar requerimientos de certicados de los clientes que se conecten a l (Figura 7.2). e
Figura 7.2: Esquema de Certicacin. CA de la comunidad expide certicados a los nodos enrolados y o estos expiden certicados a los clientes
Para garantizar disponibilidad (uno de los requisitos del los protocolos seguros) de las CAs, hay varias distribu das a lo largo de la red. Cada nodo tiene un listado de CAs disponibles ordenados por proximidad. En la Figura 7.3 se representa un ejemplo prctico donde se puede representar la interaccin a o de los nodos jos, los nodos enrolados y los nodos mviles. Puede ser un campeonato de juegos o en red a realizarse en todas las plazas de la Capital Federal. El propietario de un nodo enrolado se moviliza con el mismo hasta la plaza ms cercana y an tiene l a u nea de visin con algn nodo o u jo de la red para garantizar la conectividad hacia el backbound de la red. Los participantes que se acercan a su plaza ms cercana para participar del torneo van a ser clientes mviles que por a o primera vez se van a conectar a la red, por lo tanto solicitarn un certicado al nodo enrolado ms a a cercano para poder participar en el torneo. Cabe aclarar que toda la negociacin de certicados o y gestiones para que el cliente acceda a la red son transparentes al cliente, el protocolo es el encargado de la tarea. Una vez que este nuevo cliente ingresa a la red podr acceder al servidor a de juegos que se encuentra a miles de metros al cual accede primero routeando a travs de los e nodos cercanos en la plaza hasta llegar al nodo enrolado que se moviliz hasta la misma, el cual o le provee acceso al backbound de nodos interconectados jos hasta llegar al servidor de juegos.
Figura 7.3: Ejemplo de utilizacin de una red Mvil Urbana Segura interconectando distintas plazas o o
7.4.
Fortalecimiento de OLSR
Para poder lograr implementar el esquema de seguridad propuesto sobre el protocolo OLSR, ser necesario realizar cambios al protocolo [5]. Estos cambios no solo son cambios agregando a informacin de las CA en los mensajes del protocolo sino que se rmarn los mensajes cr o a ticos (HELLO, TC, MID, HNA) implementando lo expuesto en [21]. En [21] Hafslund y Tonnesen proponen rmar los mensajes con una clave compartida, pero en el esquema propuesto se rmar con a una clave que se intercambia durante el proceso de autenticacin y luego son encriptados con una o clave de sesin generada entre las partes para garantizar autenticacin, integridad y condenciao o lidad.
7.4.1.
Prevencin de Ataques o
Con la rma de los mensajes se puede garantizar la integridad del mismo. Con la encriptacin del mensaje con una clave de sesin negociada previa autenticacin de o o o las partes, se garantiza la condencialidad y no repudio. Con el agregado de un algoritmo de timestamp se previene la retransmisin de mensajes o viejos. Con un algoritmo heur stico se puede inferir si el mensaje proviene de un nodo vecino o de uno lejano a travs de un tnel (prevencin de wormhole attack ). e u o Se implementarn tcnicas para prevenir ataques de DoS y ataques que hagan realizar al a e nodo desgaste de energ en el procesamiento de mensajes maliciosos. a
7.5. Integracin del IDS y la CA o
En el Cap tulo 9 se dar el detalle de la implementacin de todos los puntos antes mencionados. a o
7.5.
Integracin del IDS y la CA o
La comunicacin entre las CAs y los IDS se realiza de la misma manera que entre cualquier o nodo. Primero se autentican uno con otro y se establece una clave se sesin y se encripta el o trco. La interaccin de los IDSs con la CAs es mediante mensajes espec a o cos para informar comportamientos de los nodos.
7.6.
Interaccin de los Nodos Clientes con Esquema de Seo guridad Planteado
En esta seccin se har referencia a como un nodo se integra a la red. Como pre-requisito, al o a igual de cuando se navega por sitios seguros de Internet, el nodo cliente debe conocer de antemano la clave pblica de la CA de la comunidad. u El primer paso que realiza el cliente es generar su propio par de claves. Segundo, inicializa el proceso de descubrimiento de vecinos (ya pertenecientes a la red). Durante dicho procedimiento recolectar informacin de los vecinos y a la vez de las CA ms cercanas. Una vez que conoce a o a cuales son la CAs, env un requerimiento de un certicado a la CA ms cercana para poder a a operar en la red. Recibido el certicado, valida que est en la cadena de certicacin la CA de e o la comunidad y toma el certicado como vlido y comienza una ronda de autenticacin con sus a o vecinos. En la ronda de autenticacin se establece la clave se sesin entre cada par de nodos para o o cifrar los mensajes y se intercambian de manera segura los parmetros de inicializacin para el a o algoritmo de timestamp. Finalmente, cuando se autentican los vecinos, el nodo pasa a ser un nodo conable en la red salvo que detecte un comportamiento anmalo y sea excluido de la red. o Mientras que el nodo no se encuentre autenticado por otro nodo, ste permanecer en estado e a no seguro y no participar en la eleccin de MPR ni se le aceptarn mensajes distintos a los a o a mensajes de HELLO.
7.6.1.
Esquema de conanza ganada
El esquema de ganar conanza se basa en el comportamiento del nodo en la red. Cuando un nodo ingresa por primera vez a la red, se le asigna un certicado por un per odo de tiempo corto, cuando ese certicado est por expirar, se vuelve a generar un nuevo pedido. La CA analiza e el comportamiento del nodo con la ayuda de los IDSs y si no tuvo comportamientos malos se le asigna un certicado con un tiempo de expiracin ms largo. Este procedimiento se repite o a constantemente pero vale aclarar que un nodo cliente de la red no puede convertirse en CA si no se enrola en la comunidad como tal.
7.7.
Resumen
En este cap tulo se present cual es el diseo del esquema de seguridad propuesto a nivel o n macro y sin dar mayores detalles, slo se introdujo cuales ser los actores involucrados y que o an rol tiene cada uno dentro del esquema. En el Cap tulo 9 se darn los detalles de lo planteado en a el presente cap tulo.
85
7.7. Resumen
86
Cap tulo 8
Art culos ms Relevantes a Relacionados con la Seguridad de OLSR

El objetivo de este cap tulo es realizar un resumen de los principales art culos le dos para el desarrollo de la presente tesis, los cuales fueron las principales fuentes de informacin e inspiracin para la creacin del Esquema de Seguridad para una o o o Red Mvil Urbana basada en OLSR . o
Las redes mviles hace aos que son objeto de estudio en todo el mundo, como parte de estas o n investigaciones, nunca queda de lado temas referentes a la seguridad, ya que por la tecnolog y a la naturaleza de este tipo de redes, los miembros de la misma se encuentran expuesto a ataques continuamente. Como se detall en el Cap o tulo 2, existen diferentes tipos de protolocolos de ruteo, los cuales en su mayor no preveen cuestiones de seguridad. En el Cap a tulo 4 se detallaron los principales protocolos de ruteo seguros. Dentro de los protocolos disponibles, para el desarrollo de esta tesis se eligi el protocolo OLSR, el cual como se dijo en varias oportunidades no es seguro o pero es el ms popular en las redes mviles urbanas. a o La seguridad del protocolo OLSR tambin ha inquietado a distintas personas y laboratorios e de investigacin en todo el mundo y han propuesto distintas alternativas de securizacin, las o o cuales fueron pilares para la elaboracin de la presente tesis. o Los principales trabajos sobre el tema son: Secure Extension to the OLSR protocol [21], Secure OLSR [18], Securing the OLSR protocol [30]. 87
8.1. Secure Extension to the OLSR protocol
8.1.
8.1.1.
Secure Extension to the OLSR protocol

Overview
Este art culo, que fue escrito por los implementadores del protocolo OLSR, propone una extensin del mismo asegurando la integridad y autententicando los mensajes. o Los autores asumen que cada nodo conoce una clave compartida con la cual autenticarn los a paquetes. La solucin propuesta es utilizar una rma por paquete OLSR y la solucin brinda o o paquetes rmados salto-a-salto y no una solucin de rmado de punta a punta. El fundamento o de esta tcnica es que los paquetes son reenviados a travs de nodos seguros, con lo cual el e e destinatario recibe un paquete rmado por el nodo anterior que no es el originador del mismo, pero este nodo previo conf en el nodo que le reenvi el mensaje y as sucesivamente. a o Los nodos que no conozcan la clave compartida no podrn vericar ni generar una rma a vericable.
8.1.2.
Firma
Para generar la rma del paquete OLSR, se crea un nuevo mensaje, el cual se puede ver el detalle en la Figura 8.1 y el ultimo mensaje del paquete OLSR. Como se puede entender, existe un mensaje de rma por cada paquete OLSR.
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SCHEMA | ALGORITHM | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TIMESTAMP | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SIGNATURE (160 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figura 8.1: Mensaje de rma bsico a
En el mensaje de rma se especica qu esquema de rma se est usando y qu algoritmo. e a e Luego una marca de tiempo para prevenir ataque de reenv de paquetes (se explica ms adelante) o a y por ultimo una rma del paquete utilizando SHA-1. En realidad, no es una rma digital como se deni en el Cap o tulo 3, lo que llama rma es un MAC donde usa como clave el timestamp. Con el agregado de este mensaje, la longitud del paquete debe ser recalculada agregando al longitud del mensaje de rma.
8.1.3.
Timestamps
La extensin propuesta en el art o culo incluye la generacin de timestamps por cada paquete o para prevenir el reenv del mismo paquete en otro instante. Para calcular el timestamp se realiza o un intercambio de mensajes para establecer una diferencia en el reloj remoto y el del nodo. El intercambio de relojes entre dos nodos A y B es el siguiente:
Art culos ms Relevantes Relacionados con la Seguridad de OLSR a
1. A B : Cha , D(M, K) 2. B A : Chb , T sb , D(IPb , Cha , K), D(M, K) 3. A B : T sa , D(IPa , Chb , K), D(M, K) Cuando A recibe un mensaje rmado de B del cual no tiene registro de su reloj, env un a mensaje de desaf hacia B. El mensaje tiene como destino la IP de B, un nmero aleatorio Cha o u y el resumen del mensaje utilizando la clave compartida K (D(M, K)). B responde con un mensaje de respuesta de desaf el cual tiene un nmero aleatorio Chb , el o u reloj de B, un resumen de la IP de B, el nmero al azar generado por A y la clave. Por ultimo u un resumen criptogrco del mensaje generado con la clave compartida K. a Cuando A recibe la respuesta valida el resumen D(IPb , Cha , K) y D(M, K), si son correctas utiliza el reloj enviado por B. Por ultimo A env una respuesta a B similar a la enviada por B a y luego B valida las rmas y si con vlidas utiliza el reloj enviado por A. a Luego, cada vez que se recibe un paquete se valida el timestamp teniendo en cuenta un factor de error S que determina una tolerancia para el clculo. El nodo receptor extrae el timestamp a del paquete y calcula la diferencia con su reloj calculando TN = Tlocal Tpaquete . A continuacin o evala T0 S < TN y T0 + S > TN , donde T0 es la diferencia horaria almacenada. En caso que u la validacin del timestamp sea correcta se procesa el mensaje, en caso contrario se descarta. o Para compensar algn desfasaje de los relojes, se realiza un ajuste de T0 calculando el promedio u entre la diferencia horaria almacenada y la calculada para este paquete (T0 = (T0 + TN )/2).
8.2.
8.2.1.
Secure OLSR
Overview
En este art culo se propone un mecanismo de deteccin de vecinos seguros teniendo en cueno ta la posibilidad de ataque de tnel durante el descubrimiento. Una vez que los vecinos son u descubiertos se ingresa en una ronda de autenticacin de los mismos. Conocidos los vecinos y o autenticados se comienzan a enviar paquetes de control, se propone un mecanismos de rma para los mensajes de control as se puede garantizar la integridad de los mismos. El art culo asume que cada nodo tiene un par de claves pblica/privada expedida por alguna u entidad, no se detalla cual es el mecanismo por el cual se garantiza la identidad de la clave pblica. u
8.2.2.
Deteccin segura de vecino o
Durante la etapa de descubrimiento de vecinos se puede ser objetivo de un ataque de tnel u (wormhole attack ), por lo tanto los autores proponen una forma heur stica de determinar si el mensaje proviene de un vecino real o de un vecino tuneleado. Los vecinos son aquellos que se encuentran a un solo salto de distancia. Asumiendo que la velocidad de propagacin de un paquete es cercana a la velocidad de la luz, entonces la distancia o recorrida por el paquete es de L = t c, al mismo tiempo se calcula que una placa de red de un
8.2.3. Autenticacin de vecinos o
dispositivo mvil tiene un radio de cobertura R (por ejemplo 100 metros), por lo tanto si L > R o entonces se est en presencia de ataque y si L R no. a La forma propuesta para implementar este mecanismo de defensa es la siguiente: 1. B env un mensaje de prueba a A e inicializa un contador. a 2. Cuando A recibe el mensaje de prueba, env la respuesta e inmediatamente inicia un a contador. 3. Una vez que B recibe la respuesta de A, detiene el contador y env una respuesta a A. B a calcula el tb . La distancia S entre A y B es de ( tb /2) c. Si S > R, B no inserta a A como vecino, en caso contrario prosigue con el mecanismo de autenticacin. o 4. Cuando A recibe la respuesta de B realiza el mismo clculo y toma las mismas decisiones a que el punto anterior.
8.2.3.
Autenticacin de vecinos o
Una vez superada la etapa de deteccin de vecino, el nodo debe realizar una ronda de auteno ticacin. El mecanismo de autenticacin es por medio de un intercambio de mensajes. o o 1. A genera un paquete que contiene un nmero al azar (RA ), el certicado de A (CertA ), los u identicadores de A y B, y un hash encriptado con clave privada de A (rma). A B : A, B, CertA , RA , sign(H(A, B, CertA , RA )) Donde H() es una funcin hash y sign() es una operacin de rma. o o 2. Cuando B recibe el paquete, primero verica el certicado de A, luego extrae la clave pblica de A y verica la rma del paquete. Una vez hecho esto, B env un paquete que u a contiene un nmero al azar grande (RB ), el certicado de B, los identicadores del A y B u y un hash encriptado con la clave privada de B (rma). B A : B, A, CertB , RB , sign(H(B, A, CertB , RA , RB )) 3. Cuando A recibe la respuesta de B, verica si el certicado de B es vlido, verica la rma. a Terminada esta etapa A conf que B es un vecino seguro. A env un ultimo mensaje a B. a a A B : A, B, sign(H(A, B, RA , RB )) En la Figura 8.2 se pueden ver las etapas por la que se debe pasar hasta establecer una relacin o de conanza con el vecino
Figura 8.2: Pasos para lograr una relacin de conanza con un vecino o
8.2.4.
Paquetes de Ruteo Seguros
OLSR utiliza un solo paquete para comunicar todos los tipos de mensajes. Este tiene una serie de campos que son modicables durante la propagacin del mismo y otros no. Para garantizar la o integridad de los campos que no deben cambiar durante la propagacin, se utiliza un algoritmo o de rma y para los campos variables se utiliza cadena de hash para securizar Hop Count y TTL. La extensin al paquete OLSR es la que se muestra en la Figura 8.3 o
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Hash_Hop | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Seed | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Signature | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figura 8.3: Extensin del paquete OLSR o
Cuando un nodo genera un nuevo paquete realiza los siguientes pasos: Genera un nmero aleatorio Seed. u Hash Hop = H T T L (Seed). donde H() es una funcin de hash. o signature = sign(campos estaticos) Cada vez que un nodo recibe un paquete realiza las siguientes operaciones: Primero se calcula H T T LHop Count (Seed), si el valor es igual a Hash Hop del paquete, se verica la rma, si es correcto se sigue con el prximo paso. o T T L = T T L 1; HopCount = Hop Count + 1; Seed = H(Seed)
8.3. Securing the OLSR protocol
8.3.
8.3.1.
Securing the OLSR protocol

Overview
En este art culo se presenta un framework que permite securizar el protocolo OLSR de los siguientes ataques: Generacin Incorrecta de Trco de Control o a Generacin de Mensajes de HELLO Incorrecta o Generacin de Mensajes de TC Incorrecta o Reenv de Trco de Control Incorrecto o a En el desarrollo de la solucin se asume que el comportamiento de un nodo seguro no se altera o y mantiene su buena conducta en la red. La informacin de control generada por este tipo de o nodos es la que se conserva ntegra. Para lograr esto, se proponen requerimientos criptogrcos como: a Una funcin que permita retornar la rma de un mensaje, por ejemplo sign(nodeid, key, o message). Una funcin que permita vericar la rma, por ejemplo verif(originatorid, key, o message, signature). Una clave compartida para poder rmar y validar la rma
8.3.2.
Firma de Mensajes
Con los elementos descriptos, el nodo que genera un mensaje de control genera un mensaje de rma, el cual es enviado uno por cada mensaje generado (pueden generarse varios mensajes de rma para un paquete OLSR). Este mensaje de rma se env de forma independiente al mensaje a de control, con lo cual el nodo que recibe el mensaje de control no lo acepta hasta no recibir el mensaje de rma correspondiente al mensaje. El mensaje de rma se puede ver en la Figura 8.4. Este es enviado en la porcin de datos del o paquete general de OLSR con el Message Type SIGNATURE MESSAGE. Para poder determinar a que mensaje corresponde la rma, el mensaje de rma tiene un nmero (MSN Referrer) que u es el nmero de secuencia del mensaje de control. En el campo Sign Method, se especica que u algoritmos se van a utilizar para realizar el hash, que mtodo de timestamping se va a utilizar e e informacin sobre la clave utilizada. o Para calcular la rma del mensaje de control, se ignoran los campos del mensaje que pueden variar durante la vida del mensaje (TTL y Hop Count) tomndolos como cero. En este esquema a de rma se genera una autenticacin y validacin del mensaje de punta a punta. o o
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sign. Method | Reserved | MSN Referrer | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | : Timestamp : | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | : Signature : | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figura 8.4: Formato del mensaje de rma
8.3.3.
Timestamping
En el mismo art culo, en la seccin V, se presentan distintos algoritmos de timestamping para o prevenir ataques de reenv de paquetes. Los diferentes tipos de algoritmos propuestos son: o No timestamp: Si se quiere no se utiliza esta proteccin y se pone un valor igual a cero o Real-time timestamp: Se toma el reloj de cada nodo, pero requiere algn mecanismo de u sincronismo de relojes entre los nodos Non-volatile timestamp: Este algoritmo exige que cada nodo mantenga en memoria no voltil los relojes de cada uno de los nodos de la red, cada una de esas entradas es inicializada a cuando recibe el primer mensaje. Mientras que el nodo emisor mantiene una tabla con todos los relojes de los nodos de la red, el receptor tiene una tabla con todos los valores mximos a de timestamp recibido de cada nodo. El emisor utiliza un valor de reloj de la tabla y luego lo incrementa. Timestamp Exchange Protocol : Este ms que un algoritmo es un protocolo de intercambio de a relojes, por medio del cual se generan mensajes con desaf encriptados. Para el intercambio os de mensajes se utilizar la notacin X Y : {Z}SX , que signica que X env un mensaje a o a Z a Y encriptado con la clave privada de X 1. t0 : A B : {A, TA (t0 )}SA 2. t1 > t0 : B A : {B, TB (t1 ), A, TA (t0 )}SB 3. t2 > t1 : A B : {A, TA (t2 ), B, TB (t1 )}SA
8.3.4.
PKI
Finalmente en la seccin IV, se proponen dos esquemas de PKI para redes mviles, uno es o o proactivo y el otro es reactivo.
8.3.4. PKI
8.3.4.1.
PKI Proactiva Simple para OLSR
Este PKI funciona con tres tipos de nodos: Nodos no conables, Nodos Conables, Autoridades Firmantes. Un nodo no es conable si la clave publica de x no es conocida por a o si la clave pblica de x es conocida pero no est rmada por la Autoridad Firmante. Un nodo es u a conable si la clave publica de x es conocida por a y a la vez est rmada por la Autoridad a Firmante. La Autoridad Firmante es un nodo de la red que es conocido por todos los otros nodos y tiene la capacidad de registrar claves pblicas para nuevos nodos. La Autoridad Firmante env u a peridicamente un listado de las claves de los nodos conables. o Cada nodo que quiera participar en la red deber registrar su clave pblica en la Autoridad a u Firmante, esta peridicamente distribuye el listado de claves. Cada nodo almacena las claves o hasta que expiran. Este mecanismo requiere que las claves sean renovadas peridicamente. o Cuando la red se inicializa, ningn nodo conoce ninguna clave de la red, salvo la de la Autou ridad Firmante, por lo tanto todos los nodos van a ignorar los mensajes de control de los otros nodos, ningn nodo va a ser elegido como MPR y ningn mensaje broadcast va a ser reenviado. u u Todos los nodos tienen que esperar que la Autoridad Firmante comience a emitir mensajes con las claves. Durante la inicializacin de la red, la Autoridad Firmante env su certicado a todos los o a vecinos de un salto de distancia, seguido realiza un intercambio de mensajes de HELLO, los vecinos de un salto de distancia aceptan a los vecinos de dos saltos como simtricos pero no los eligen e como MPRs. La Autoridad Firmante elige MPRs entre los vecinos de un salto y as el prximo o broadcast de claves llega a los vecinos de dos saltos de distancia. As contina inundando la red u para que todos los nodos conozcan las claves pblicas de los nodos conables. u Todos los nodos deben mantener tablas con la informacin de claves de sus vecinos y si son o conables o no. No se prevee un esquema de revocacin de claves. o 8.3.4.2. PKI Reactiva Simple para OLSR
A diferencia del esquema PKI proactivo, en este cuando un nodo requiere una clave, la solicita a la red. Para ello se incorporan dos nuevos mensaje, Key Request y Key Reply. La solicitud de una clave se realiza con el mensaje Key Request que tiene un NA que es un nmero aleatorio, la identicacin del nodo y una lista de todas la claves solicitadas. El mensaje u o es enviado a toda la red. A all : {A, NA , B1 , ..., BN }SA . La respuesta es enviada en el mensaje Key Reply. La Autoridad Firmante cuando recibe el requerimiento, primero valida la rma del mensaje de A (si tiene la clave pblica de A), y u luego arma el mensaje de respuesta con el listado de claves pblicas que conoce. P all : u {P, A, NA , (Bi1 , P KBi1 ), ..., (Bim , P KBim )}SP Cuando A recibe la respuesta, valida que el A sea realmente el destinatario del mensaje, que P sea a una Autoridad Firmante conocida, que la rma del mensaje sea correcta y que el NA sea vlido. a La retransmisin de los mensajes de solicitud y respuesta de claves se realizan mediante el o mecanismo de inundacin convencional, por ejemplo si un nodo recibe un mensaje, lo reenv una o a
sola vez.
8.4.
Resumen
En este cap tulo se resumieron distintos art culos los cuales plantean distintas alternativas de securizacin para el protocolo OLSR. Las soluciones aportadas por estos fueron utilizadas para o el desarrollo de la presente tesis adaptndolas a las necesidades del protocolo propuesto. a
95
8.4. Resumen
96
Cap tulo 9
Detalles de Implementacin del o Esquema de Seguridad Propuesto

En este cap tulo se dar un detalle de lo propuesto en el Cap a tulo 7, llegando a profundizar cuestiones relacionadas al protocolo OLSR como a los aspectos organizacionales de las comunidades de llevan adelante los proyectos de redes mviles urbanas. o
Luego de la presentacin del esquema de seguridad planteado para una red mvil urbana en o o el Cap tulo 7, en este cap tulo se dar los detalles de todos los puntos propuestos para lograr una a red mvil segura. o Se analizarn los detalles tanto organizativos que la comunidad debe realizar antes de dar de a alta un nodo jo en la red como as las piezas de protocolo necesarias para que interacten los u elementos involucrados en el esquema. Los elementos principales necesarios para la implementacin del esquema de seguridad proo puesto son: Autoridad Certicante, el protocolo de ruteo, los clientes de la Red y el Sistema de Deteccin de Intrusos. El anlisis de la implementacin del IDS, no es el objetivo del presente o a o cap tulo ni de la Tesis. Se tratarn en detalle los mecanismos organizativos de la comunidad a la hora de registrar a un nodo como CA, con respecto al protocolo de ruteo se denirn tres niveles de securizacin a o de los cuales se har un detalle minucioso de los dos primeros y el tercero se plantea como una a extensin y es objeto de estudio futuro. o
9.1.
Esquema de Certicacin o
Tal como se adelant en el Cap o tulo 7, uno de los principales componentes del esquema propuesto es la existencia de certicados digitales para autenticar a los nodos pertenecientes a la red. Esto se logra teniendo una entidad responsable de emitir certicados garantizando que el 97
9.2. Fortalecimiento del Protocolo OLSR
nodo portador del mismo es conable. La comunidad va a tener un unico certicado con el cual va a rmar certicados para los nodos jos de la red que se enrolen.
9.1.0.3.
Procedimiento para la registracin de un nodo o
La asignacin de certicados es una tarea de la comunidad que administra la red. Si una o persona tiene un nodo y quiere participar de la comunidad, sta necesitar darse de alta en la e a comunidad para que se le asigne una IP para su nodo perteneciente al backbone de la red, un rango de IPs para asignar a los nodos clientes que se unan a la red a travs de l y un ESSID e e estandarizado (opcional). Si el propietario del nodo va a participar activamente en la red, es decir, su nodo una vez congurado va a estar disponible sin interrupciones de servicio prolongadas, puede solicitar ser CA para poder rmar certicados para sus clientes. La Comunidad conoce a los propietarios de los nodos porque en general tienen una participacin activa en los foros, o listas de correos y reuniones organizativas, con lo cual se est seguro cuales son los nes del nodo a solicitante y se puede asumir que es un nodo seguro. El objetivo cuando la red no tiene muchos nodos jos es que todos los nodos jos sean CAs para minimizar el traco de backbone solicitando certicados a otros nodos de la red. Hoy en d a, por ejemplo Buenos Aires Libre no cuenta con la cantidad de nodos suciente como para que un nodo cliente pueda ver dos o ms nodos jos y as tener la posibilidad de que haya nodos jos a que no sean CAs. Por esto es que es necesario que todos los nodos jos asuman la responsabilidad de ser CA.
9.2.
Fortalecimiento del Protocolo OLSR
El protocolo OLSR como se vi en el Cap o tulo 6 no dispone de ninguna prevencin contra o los posibles ataques vistos en la Seccin 6.6, por lo tanto como parte del esquema de seguridad o propuesto no se puede dejar de lado la seguridad del protocolo de ruteo. Por eso es que en el diseo se separ el fortalecimiento de OLSR en distintos niveles. n o En el primer nivel se detallarn las modicaciones del protocolo para garantizar los servia cios bsicos que debe ofrecer una red segura: Disponibilidad, Condencialidad, Autenticacin, a o Integridad y No Repudio ( [15]). En el segundo nivel se realizarn las modicaciones al protocolo para mitigar las vulnerabilia dades ms cr a ticas que presenta el protocolo. Por ultimo en el tercer nivel se tratar como podr funcionar el esquema propuesto para que a a la red tenga un mecanismo de autodefensa. Los mensajes del protoloco original [5] van a ser los mismos (HELLO, TC, HNA y MID) y se le agregarn una serie de mensajes propios de la solucin propuesta, los cuales sern detallados en a o a las siguientes secciones.
Detalles de Implementacin del Esquema de Seguridad Propuesto o
9.3.
Fortalecimiento de OLSR: Nivel 1
A lo largo de esta seccin se detallarn todos los componentes, las interacciones y los mensajes o a necesarios para hacer que OLSR garantice los servicios bsicos de seguridad. Para garantizar estos a servicios es necesario introducir modicaciones a las tablas originales del protocolo, a los mensajes y los mecanismos y formas de comunicacin. En esta seccin se especicarn las modicaciones o o a a las distintas etapas del protocolo original: Deteccin de Vecinos, Descubrimiento de la Red y o Armado de la Tabla de Ruteo.
9.3.1.
Tablas del Protocolo
En la Seccin 6.3 se detallaron cuales son las tablas que utiliza el protocolo OLSR segn su o u RFC. En esta propuesta de fortalecimiento del protocolo, se modicarn las tablas existentes. a La tabla Neighbor Set quedar conformada por la tupla {N neighbor main addr, N status, a N willingness, N trusted, N cert, N sessionKey, N deltaTimestamp, N localKey, N remoteKey, N neighbor trust level, N CA} N neighbor main addr: Direccin principal del nodo vecino. o a e N status: Especica si el nodo est en estado SYM=enlace simtrico o NOT SYM=enlace no simtrico. e N willingness: Es un entero entre 0 y 7 y especica la conanza que se le tiene al nodo vecino para llevar el trco. a N trusted: Indica si el vecino es conable o no N cert: Se almacena el certicado del vecino N sessionKey: Se almacena la clave de sesin generada o N deltaTimestamp: Se almacena la diferencia entre el reloj local y el reloj del vecino. Esta columna ser usada para mitigar ataques de reenv de paquetes a o N localKey: Durante el proceso de autenticacin se genera una clave local para rmar o los mensajes N remoteKey: Durante el proceso de autenticacin el nodo remoto genera una clave o con la cual rmar sus mensajes a N neighbor trust level: Indica el nivel conanza que la CA le dio al nodo vecino (informacin incluida en el certicado) o N CA: Indica si el vecino es CA o no La tabla Topology Information: quedar conformada por las tuplas {T dest addr, a T last addr, T seq, T CA, T time} T dest addr: Direccin principal del nodo destino que es alcanzado en un salto por o el nodo con direccin principal T last addr. o T last addr: Es MPR de T dest addr. T seq: Nmero de secuencia. u T CA: Indica si el nodo es CA o no T time: Tiempo de expiracin de la tupla. o
9.3.2. Obtencin del Certicado o
9.3.2.
Obtencin del Certicado o
El nodo que ingresa a la red lo primero que hace es intentar obtener un certicado para poder autenticarse con sus vecinos. El proceso de obtencin del certicado comienza con la emisin o o de un nuevo mensaje llamado CADISCOVER. Los vecinos que reciban este mensaje devolvern el a mensaje adjuntando al mismo el listado de CAs que tiene cada uno y la cantidad de saltos que tiene hasta llegar a sta. e 9.3.2.1. Generacin del mensaje CADISCOVER o
El nodo que desea participar en la red genera un mensaje como el que se muestra en la Figura 9.1 y lo incorpora en el paquete OLSR con tipo de mensaje CADISCOVER. El cuerpo del mensaje va a ser vac es decir no se especicar direccin de destino ni listado de CAs. o, a o
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Hop Count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Advertised CA Main Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Hop Count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Advertised CA Main Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figura 9.1: Formato del mensaje CADISCOVER
9.3.2.2.
Procesamiento del mensaje CADISCOVER
El nodo que recepciona el mensaje construye el mensaje de respuesta obteniendo la informacin de la Tabla de Topolog de la cual obtiene cuales son los nodos CAs y de la Tabla de Rutas o a de la cual obtiene el nmero de saltos hacia el destino. u Para armar el mensaje de respuesta, se coloca en el destino del mensaje la direccin del nodo o que realiz la peticin. Luego completa el mensaje incorporando el listado de las CAs conocidas o o agrupndolas por cantidad de saltos. a Los nodos solo generarn respuestas cuando los mensaje recibidos no contengan una direccin a o de destino y el listado de CAs estn vac Un mensaje que cumple con estas condiciones es e os. considerado una peticin. o Cuando un nodo recibe un mensaje considerado peticin realiza lo siguiente: o Actualiza la tabla de vecinos (Neighbor Set)
Confecciona el mensaje de respuesta. Env el mensaje generado a Cuando un nodo recibe un mensaje que tiene una direccin de destino, verica que dicha o direccin le corresponda. En el caso que el nodo no sea destino del mensaje, este es desechado. o En caso contrario se procede de la siguiente manera: Se actualiza la tabla de vecinos (Neighbor Set) Por cada direccin agrupada bajo cada cantidad de saltos se agrega una entrada en la tabla o de rutas colocando como R dest addr la direccin de la CA, como R next addr la direccin o o del nodo de donde provino la respuesta, R dist igual a la cantidad de saltos y nalmente la R iface addr la direccin de la interfaz por la que recibi la respuesta. o o Esta generacin de la tabla de rutas no es igual a la realizada por OLSR, pero es necesaria o generarla de esta manera en esta etapa y por unica vez para alcanzar una CA.
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | : CertReqMessage (X.509) : | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figura 9.2: Formato del mensaje CERTREQ
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | : Signed Cert : | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figura 9.3: Formato del mensaje CERTREPLY
9.3.2.3.
Generacin del CERTREQ o
El nodo que pretende obtener un certicado, genera un nuevo mensaje de tipo CERTREQ que es enviado en forma segura a la CA elegida por menor distancia. El formato de este mensaje se puede ver en la Figura 9.2 Los nodos vecinos solo reenviarn de un nodo no conable (no autenticado) mensajes con a destino a una CA. Un nodo siempre va a conocer que el destino es una CA ya que este nodo le dijo al nodo que genera el mensaje que l sab como llegar a una CA y con cuantos saltos. e a Para generar el mensaje, el nodo genera su propio par de claves y crea un requerimiento de certicado (CertReqMessage [27]). Para enviar la solicitud a la CA ms cercana debe hacerlo de a
9.3.2. Obtencin del Certicado o
forma segura segn lo especica el RFC 2511 de X.509[27, Sec. 2]. Para cumplir con la norma, u se establece una conexin SSL [28] con la CA. Como el nodo cliente conoce el certicado de la o rootCA de la comunidad, verica que el certicado presentado por la CA a la hora de establecer la sesin SSL est rmado por la rootCA. De esta manera el nodo cliente se asegura que se o e est conectando a una CA segura. Cabe aclarar en este punto que solo es necesario que el nodo a que intenta obtener un certicado sea el unico que verique la identidad de la CA ya que no es necesario que la CA valide la identidad del nodo porque el propsito de este mecanismo es o obtener una identidad temporal para un nodo annimo. o Una vez establecido un canal seguro, el nodo crea un mensaje CERTREQ donde incluye el mensaje CertReqMessage de X509 denido en la Seccin 3 del RFC 2511 (Figura 9.2) y se lo o env a la CA. a Un nodo cuenta con ms de una CA, en caso que existan, con lo cual comienza intentando a enviar el mensaje CERTREQ a la CA ms cercana y luego a las ms alejadas. Con esta caracter a a stica se gana disponibilidad de las CAs ya que sin la obtencin del certicado, el nodo nunca ser parte o a de la red. 9.3.2.4. Generacin del Certicado o
Como se mencion anteriormente una CA tiene un certicado expedido por la rootCA de o la comunidad. Una vez que el nodo cliente establece una conexin segura con la CA, env el o a mensaje solicitando un certicado. La CA consulta en su CRL si este nodo est presente. En caso a que no est en la CRL, expide un certicado con una validez temporal. e La validez del primer certicado ser de una hora y el nivel de conanza es de uno. Ese a nivel de conanza es un parmetro que la CA agrega como campo de texto en una extensin del a o certicado. El nivel de conanza permite a un nodo cambiar su rol de participacin en la red a o medida que va ganndola con un buen comportamiento en la red. a Una vez que se tiene el certicado expedido, es enviado al nodo en la misma sesin SSL. Es o decir, el proceso de solicitud de un certicado es sincrnico. o La respuesta con el certicado rmado es devuelto en un mensaje de tipo CERTREPLY como se muestra en la Figura 9.3. 9.3.2.5. Renovacin de certicado o
Un nodo cuando est por vencer su certicado debe solicitar una renovacin del mismo. a o El procedimiento para la renovacin es el mismo que para la solicitud, es decir, establece una o conexin SSL con la CA y env el mensaje. En este caso el mensaje que se env es de renovacin o a a o (tipo CERTRENEW). En el mensaje se env el certicado anterior para una renovacin (Figura 9.4). a o Los per odos de expiracin se calculan, de forma arbitraria, duplicando el per o odo de validez del certicado anterior, es decir V ALIDEZ = V ALIDEZ 2, tomando como per odo de validez inicial una hora. Con cada renovacin se gana un nivel ms de conanza. El nivel de conanza o a permite a un nodo cambiar su rol de participacin en la red. o Con esta tabulacin de per o odos de validez, una CA puede saber por cuanto tiene que renovar un certicado sin necesidad que el certicado anterior haya sido expedido por la misma CA. La
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | : Expired Cert : | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figura 9.4: Formato del mensaje CERTRENEW

Nro Renovaciones 0 1 2 3 4 ... Nivel de Conanza Ganado 1 2 3 4 5 ... Valido por (hs) 1 2 4 8 16 ...
Cuadro 9.1: Validez del certicado por renovacin o
Autoridad puede saber la cantidad de renovaciones haciendo N ro Renovaciones = ln (f echa expiracion f echa emision) ln (2)
y no es necesario que una CA mantenga un contador con la cantidad de certicados expedidos para un nodo. La CA recibe el certicado y valida que haya sido expedido por una CA autorizada, verica por cuanto tiempo tiene que ser expedido, incrementa el nivel de conanza, lo genera y se lo env a al nodo en un mensaje CERTREPLY. El per odo de renovacin ser como mximo un ao, o sea cuando el nodo logra obtener un o a a n certicado con una validez de un ao, en cada renovacin recibir un certicado de un ao. n o a n Una vez que se tiene el nuevo certicado expedido, es enviado al nodo en la misma sesin o SSL, es decir el proceso de renovacin del certicado es sincrnico. o o
9.3.3.
Deteccin de Vecinos o
El proceso de deteccin de vecinos ser de la misma manera que se realiza en el protocolo o a original mediante un censado de vecinos. Cuando el nodo se incorpora a la red env un mensaje a de tipo CADISCOVER, cuando los vecinos responden, el nodo actualiza su tabla de enlacess con los vecinos poniendo el estado del enlace como ASYM LINK y tipo de vecino como NOT NEIGH y no conable. Los nodos que reciben el mensaje CADISCOVER actualizan su tablas de enlaces con los vecinos y agregan al nuevo vecino como no conable y el estado del enlace como ASYM LINK a y tipo de vecino como NOT NEIGH. De esta manera un nodo nunca elegir al nuevo nodo como
9.3.3. Deteccin de Vecinos o
MPR ya que es condicin que el nodo tenga un enlace simtrico para participar en la eleccin de o e o MPR. En el procedimiento de censado de vecinos propuesto se incorpora una modicacin m o nima al procedimiento original. Se agrega un nuevo tipo de vecino a los ya existentes (NOT NEIGH, MPR NEIGH y SYM NEIGH) llamado CA NEIGH. Es decir en un mensaje de HELLO se incorpora un nuevo Link Code donde se indica que ese enlace es con un vecino que es CA, es decir es una extensin de la informacin enviada en un mensaje HELLO del protocolo original. o o Por ejemplo, si un nodo informa que tiene Link Code con tipo de enlace SYM LINK y tipo o de vecino MPR NEIGH con un nodo y luego la direccin del nodo esta listada con Link Code correspondiente a CA NEIGH, se actualiza la tupla en la tabla de vecinos indicando que el vecino con el cual se tiene ese enlace es CA. Un nodo puede informar que l es CA enviando su direccin en el listado de direcciones con e o Link Code CA NEIGH y cuando un nodo procese este mensaje comparar la direccin de origen a o del mensaje y la direccin listada como CA NEIGH y actualizar la entrada en la tabla de vecinos o a indicando que el origen del presente mensaje de HELLO es una CA. No es necesario cambiar la cantidad de bits para representar ese nuevo Link Code ya que en el protocolo original se usan dos bits para representar cuatro tipo de enlaces y dos bits para representar tres tipos de vecinos, con lo cual al agregar un nuevo tipo de vecino se puede representar con los dos bits destinados para este n. 9.3.3.1. Autenticacin de los vecinos o
Una vez que el nodo obtiene un certicado, comienza el proceso de autenticacin. El nodo en o esta etapa ya conoce a sus vecinos los cuales fueron reconocidos en la respuesta al mensaje de HELLO de tipo CADISCOVER. El nodo comienza la autenticacin con cada uno de los vecinos de su o listado de vecinos. Para intercambiar los parmetros de autenticacin se utilizan dos nuevos mensaje a o AUTH MESSAGE (Figura 9.5), AUTH MESSAGE FINISH (Figura 9.6)
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | : Source Cert : | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Random Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | : Signature (160bits) : | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figura 9.5: Formato del mensaje AUTH MESSAGE
104
Procedimiento de Autenticacin Para explicar el proceso de autenticacin llamaremos A o o al nodo que inicia el proceso y B a la otra parte. 1. A genera un paquete que contiene un nmero al azar (RA ), el certicado de A (CertA ), los u identicadores de A y B, y un hash encriptado con clave privada de A (rma). A B : A, B, CertA , RA , sign(H(A, B, CertA , RA )) Donde H() es una funcin hash y sign() es una operacin de rma. o o 2. Cuando B recibe el paquete, primero verica el certicado de A si corresponde a un certicado rmado por una CA de conanza, luego extrae la clave pblica de A y verica la u rma del paquete. Una vez hecho esto, B env un paquete que contiene un nmero al azar a u (RB ), el certicado de B, los identicadores del A y B y un hash encriptado con la clave privada de B (rma). B A : B, A, CertB , RB , sign(H(B, A, CertB , RA , RB )) 3. Cuando A recibe la respuesta de B, verica si el certicado de B es vlido y fue rmado a por una CA de la red, verica la rma. Terminada esta etapa A conf que B es un vecino a seguro y agrega el certicado, en la tabla de vecinos marcndolo como conable, actualiza el a estado de los enlaces con B como SYM LINK y tipo de vecino SYM NEIGH. A env un ultimo a mensaje a B.
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | : Signature (160bits) : | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figura 9.6: Formato del mensaje AUTH MESSAGE FINISH
A B : A, B, sign(H(A, B, RA , RB )) 4. Cuando B recibe la respuesta, conrma que A es un vecino seguro. Actualiza la tabla de vecinos con el certicado de A y marca a A como vecino seguro. Tambin actualiza el estado e de los enlaces con A como SYM LINK y tipo de vecino SYM NEIGH. En este punto un nodo malicioso o mal congurado puede enviar miles de mensajes de autenticacin seguidos, lo cual puede generar una Denegacin de Servicio. En el detalle o o del prximo nivel de securizacin se detallar cual es la manera de prevenir este tipo de o o a comportamiento.
105
9.3.4. Firma y encripcin de los mensajes o
9.3.3.2.
Eleccin de MPR o
La eleccin de MPR se realiza de la misma manera que en el protocolo original ya que con o la modicacin incorporada, solo se va a lograr tener un enlace simtrico con un vecino luego o e que se hayan autenticado. Es de mucha importancia que un MPR sea un nodo autenticado ya que va a ser el punto de ruteo hacia un sector de la red. Si este nodo no es seguro se pondr a en riesgo el ruteo y la integridad de la red. Como un punto parametrizable para el protocolo se puede establecer cual es el nivel de conanza m nimo que se tiene que tener con los vecinos para elegirlo como MPR. Este parmetro debe ser congurable ya que en un red chica con pocos a nodos, establecer un umbral alto dejar el nodo aislado pero ya es riesgo del usuario usar un a umbral bajo.
9.3.4.
Firma y encripcin de los mensajes o
Para implementar seguridad sobre OLSR, es preciso identicar cuales son los paquetes y los mensajes cr ticos para poder securizarlos. Los mensajes que hay que proteger son aquellos que por alguna manipulacin pueden poner en riesgo la integridad de la red. Los mensajes a proteger o claramente son los mensajes HELLO, TC, HNA y MID. Para la implementacin de seguridad sobre estos mensajes se pueden plantear dos alternativas, o una autenticando y encriptando el mensaje de punta a punta [30] o rmando y encriptando el paquete OLSR [21] dando una autenticacin y encripcin salto por salto. o o Para la encripcin de punta a punta es necesario que los dos extremos de la conexin se o o autentiquen mediante el intercambio de certicados y generar una clave de sesin para realizar un o encriptado simtrico. Con el uso de claves asimtricas generar un desperdicio de energ porque e e a a har uso intensivo del procesador. Esta alternativa no es considerada viable ya que implicar a a mucho overhead de control y en caso de ser un nodo remoto a varios saltos de distancia el intercambio de mensajes podr interrumpirse y requerir una nueva negociacin. La propuesta a a o de [30] utiliza un mensaje de rma por separado que requiere un seguimiento de los mensajes recibidos y vericar la rma de los mismos. Esta tarea requiere tener almacenados esos mensajes y compararlos con los mensajes recibidos, con lo cual se tiene un gasto extra de procesador para esta tarea. La autenticacin y encripcin salto a salto es ms eciente pero no permite una vericacin o o a o del mensaje de punta a punta. En el anlisis el funcionamiento de OLSR 6.4, se vi que el a o protocolo en s utiliza el reenv de paquetes para la propagacin de mensajes con lo cual utilizar o o una encripcin y autenticacin salto a salto va de la mano con el funcionamiento del protocolo. o o Esta forma de securizar un paquete se basa en que los nodos por los cuales se reenv son nodos a, conables y autenticados. 9.3.4.1. Obtencin de la Clave de Sesin o o
Una de las premisas de este diseo es generar un protocolo que garantice integridad y conn dencialidad, para ello es necesario utilizar una rma y una clave para encriptar el mensaje. Como se vi en el Cap o tulo 3, existen dos tipo de cifradores, los simtricos y los asimtricos. Como e e
la cantidad de mensajes intercambiados entre un nodo y su vecino es muy grande, utilizar un esquema de clave pblica y privada generar un malgasto de la energ del nodo, para ello es u a a que se utiliza una clave se sesin para encriptar con un algoritmo simtrico. o e
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | : Source Cert (B) : | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Random Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | : Encripted Key (B) : | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | : Signature (160bits) : | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figura 9.7: Formato del mensaje AUTH MESSAGE RESPONSE
El algoritmo de intercambio para la generacin de una clave de sesin, toma lugar durante el o o proceso de autenticacin para minimizar los mensajes intercambiados. Para realizar el intercambio o de claves se incorpora un nuevo mensaje, el AUTH MESSAGE RESPONSE (Figura 9.7) y se debe modicar AUTH MESSAGE FINISH quedando como se muestra en la Figura 9.8
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | : Encripted Key (A) : | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | : Signature (160bits) : | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figura 9.8: Formato del mensaje AUTH MESSAGE FINISH
En el Paso 2 del proceso de autenticacin, el nodo B ya tiene el certicado de A. B encripta o un nmero al azar de un nmero de bits jos (N = 128 para esta implementacin) con su clave u u o privada y luego con la clave pblica de A. u
9.3.4. Firma y encripcin de los mensajes o
En el Paso 3 el nodo A hace lo mismo que el nodo B. Finalizada esta etapa, los dos nodos tiene los dos nmeros al azar (KA , KB ) y ningn otro nodo pudo haber obtenido estos nmeros. u u u 1. A B : A, B, CertA , RA , sign(H(A, B, CertA , RA )) 2. B A : B, A, CertB , RB , EP uA (EP rB (KB )), sign(H(B, A, CertB , RA , RB , EP uA (EP rB (KB )))) 3. A B : A, B, EP uB (EP rA (KA )), sign(H(A, B, RA , RB , EP uB (EP rA (KA )))) A partir de esta etapa los nodos utilizan como clave de sesin el producto de estos dos nmeros o u 1 truncados a N bits . Una vez completado el clculo de la clave compartida, es almacenada en la a tabla de vecinos. El per odo de validez de la clave de sesin es igual al valor de expiracin del o o enlace con el vecino (campo L time de la tabla Link Set). Cuando ese per odo est prximo a e o vencerse se procede nuevamente a realizarse la ronda de autenticacin. o 9.3.4.2. Firma de los mensajes
Para prevenir que los mensajes sufran alteraciones por algn nodo intruso, se realiza el rmado u 2 del mismo con el algoritmo HMAC . Como se describi en el cap o tulo 3 el algoritmo HMAC es un algoritmo que aplica una funcin al mensaje y se obtiene un resumen criptogrco del mismo. o a La funcin que se aplica recibe como parmetro un mensaje y una clave (Figura 9.9). HMAC o a involucra una funcin de hash aplicada al mensaje combinada con la clave HM ACK (m) = o h((K opad) (h((K ipad) m)). La implementacin del algoritmo utilizada es HMAC-SHA-1, por o lo tanto en la expresin anterior h() es SHA-1 y el resultado nal ser una rma de 160 bits. o a
Figura 9.9: Generacin de la rma o
HMAC no solo garantiza que el mensaje no fue modicado sino que tambin lo autentica. En este e diseo HMAC es utilizado con una clave de N bits, en particular A utilizar KA y B utilizar KB n a a (valores intercambiados durante la ronda de autenticacin). o
clculo para la clave sesin es determinado de forma arbitraria y es parte del protocolo propuesto. a o no es estrictamente una rma digital como se deni en el Cap o tulo 3, pero en este caso ser utilizado a para garantizar integridad y autenticacin del mensaje. o
2 HMAC 1 Este
108
Los paquetes de OLSR tiene dos tipos de campos, los que no var entre salto y salto y an los que var cuando son reenviados. Para esta propuesta de protocolo no es necesario tener en an cuenta estos campos ya que la autenticacin y la vericacin de la integridad del paquetes es o o llevada a cabo salto-a-salto. Diferenciar estos campos es importante si la integridad del mensaje es evaluada en el extremo de la ruta. En denitiva la rma se realizar sobre: a Encabezado del paquete OLSR (con el tamao ajustado para incorporar la rma) n Todos los mensajes OLSR inclu dos en el paquete Las cabeceras del mensaje de rma.
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SCHEMA | ALGORITHM | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SIGNATURE (160 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figura 9.10: Formato del mensaje rma
Se genera un nuevo mensaje (Figura 9.10) con la rma y se agrega al nal del paquete OLSR. El tamao del paquete OLSR debe ser reajustado para incorporar la rma al nal como se ve en n la Figura 9.11. Ms adelante cuando se trate la prevencin de ataques en el nivel 2 de securizacin a o o se ver que el mensaje de rma sufre una ligera modicacin. a o 9.3.4.3. Protocolo de encriptacin o
Para garantizar la condencialidad de la informacin que viaja en el paquete, se aplica encripo cin sobre el mismo. El algoritmo para encriptar los paquetes debe tener un cifrador simtrico o e ya que hay que optimizar el uso de CPU del dispositivo mvil. El algoritmo elegido para esta o tarea es el AES [31, Cap tulo 5]. AES es un cifrador por bloques y es el cifrador adoptado como el cifrador estndar para el gobierno de los Estados Unidos y es el sucesor del 3DES. Utiliza a una clave que puede ser de 128, 192 o 256 bits. Para este diseo se utilizar una clave de 128 n a bits. La clave utilizada para encriptar los paquetes es la clave de sesin calculada en la ronda de o autenticacin truncada a 128 bits. o Cuando el nodo destino recibe el mensaje, la primera operacin que deber hacer es deseno a criptar el paquete con la misma clave que se utiliz para encriptarlo (Figura 9.12), luego contina o u el procesamiento del paquete validando la rma.
9.3.5.
Descubrimiento de la Topolog a
Con la modicacin introducida, cada nodo tiene que conocer cuales son la CAs de la red, o para ello utilizan la tabla de topolog Para diseminar esta informacin por la red, se generan a. o dos mensaje TC diferentes. Uno anunciando los enlaces de la misma manera que se hacen en el
9.3.6. Armado de la tabla de Ruteo
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Packet Length | Packet Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Type | Vtime | Message Size | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Originator Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Time To Live | Hop Count | Message Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | : MESSAGE : | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Type | Vtime | Message Size | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Originator Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Time To Live | Hop Count | Message Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | : MESSAGE : | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SCHEMA | ALGORITHM | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SIGNATURE (160 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figura 9.11: Formato del paquete de OLSR rmado
protocolo OLSR original [5, Sec. 9] y otro mensaje informando de los enlaces conocidos cuales son con una CA. Para diferenciar estos dos tipos se mensajes se utiliza el campo reservado en el mensaje de TC y se le coloca un indicador para sealar que las direcciones contenidas en el mismo n correspondes a nodos que son CAs. Para armar los mensajes TC con la informacin de la CAs, se hace de la misma manera que o en el protocolo original, con la modicacin que solo se tomaran las direcciones de los vecinos del o Neighbor Set que sean CAs. La forma de reenv de los mensaje TC no sufren ninguna modicacin con respecto al protocolo o o original.
9.3.6.
Armado de la tabla de Ruteo
El procedimiento Armado de la tabla de Ruteo no sufre ninguna modicacin con respecto a o la especicacin del protocolo original [5, Sec. 10] o
9.3.7.
Logros del Nivel 1 de securizacin o
En lo detallado del Nivel 1 de securizacin se puede ver que es el nivel ms complejo ya que o a hay que incorporar mecanismos y elementos de criptograf y comunicacin auxiliares para lograr a o
Figura 9.12: Firma + Encripcin de un paquete o
un determinado nivel de seguridad. En este nivel se puede garantizar los servicios bsicos de una a red segura: Autenticacin: Con la fase de autenticacin entre los nodos, se produce el intercambio de o o certicados rmados por CAs de la red, con lo cual ambos nodos estn seguros que estn a a conectados con quienes dicen ser. Integridad: Con el esquema de rmado de los mensajes los nodos estn seguros que nadie a ha modicado su contenido. Condencialidad: Luego del procedimiento de autenticacin se establece una clave de sesin o o entre los dos nodos, con lo cual el trco que es encriptado con esa clave solo puede ser a le por ellos. do No repudio: Ambos extremos de un enlace estn autenticados con certicados expedidos a por la CA, estos certicados son intercambiados para garantizar la identidad de cada uno. Disponibilidad: Teniendo redundancia de las CAs, un nodo siempre va a tener donde solicitar o renovar certicados. Teniendo asegurados los paquetes de control el protocolo ya est ms seguro pero no es inmune a a a ataques, por ello es que se plantea el Nivel 2 de fortalecimiento donde se mitigan algunos ataques.
9.4.
Tener autenticados y encriptados los paquetes de control pone al protocolo OLSR ms slido a o pero an as un nodo que permanece en la red durante un determinado tiempo podr realizar u a distintos ataques como el Ataque del Tnel y el Ataque de Reenv de Paquetes. u o
9.4.1.
Prevencin contra ataque Wormhole o
Unos de los ataques analizados en la Seccin 6.6 es el Ataque del tnel (wormhole attack ) en o u donde un nodo utiliza los mensajes de HELLO generados en un sector de la red y los reproduce en otro, enviando dichos mensajes a travs de un tnel externo a la red. Esto hace que una e u v ctima crea que el nodo atacante sea un nodo vecino pero en realidad se encuentra a varios
9.4.2. Prevencin contra ataque de reenv de mensajes: Timestamp o o
saltos de distancia. Este ataque genera una alteracin de la topolog de la red y el agresor con o a este comportamiento hace que todos los nodos cambien sus tablas de ruteo y lo utilicen a l como e gateway hacia otro extremo de la red. Este ataque se puede prevenir utilizando un mecanismo estad stico/heur stico [18, Sec. 4.4] teniendo en cuenta algunas caracter sticas del medio de f sico y de las interfaces de red. Teniendo en cuenta que las placas de red utilizadas hoy en d tienen un radio de cobertura R, por ejemplo a mximo 100mts (este valor parametrizable en el protocolo) y suponiendo que la velocidad de a propagacin de la seal wireless c en el aire es cercana a la velocidad de propagacin de la luz en o n o el vac se puede calcular la distancia recorrida por un paquete como L = t c. Entonces si se o, detecta que un paquete cumple con L > R, se esta en presencia de un ataque de tnel y en caso u contrario, no (L <= R). La implementacin de este sencillo algoritmo consiste en el siguiente procedimiento: Durante o el Procedimiento de Autenticacin, cuando B recibe el primer mensaje de A (Paso 1), B inicializa o un contador y env la respuesta a A (Paso 2), cuando A le responde, B detiene el contador y a env el mensaje a A (Paso 3). B calcula la distancia como S = ( tb /2) c, si S > R, B no a pone a A como vecino conable, en caso contrario y se completa satisfactoriamente el paso 4, B inserta a A como vecino seguro. El procedimiento seguido por A es anlogo, con la diferencia que A inicializa el contador en a el Paso 1 antes de enviar el primer mensaje hacia B.
9.4.2.
Prevencin contra ataque de reenv de mensajes: Timestamp o o
Otro de los ataques analizados en la Seccin 6.6 es el Ataque por Reenv de Mensajes, el cual o o consiste en grabar traco de la red y reproducirlo en otro momento. Este ataque es posible porque los nmeros de secuencias, son nmeros de 16 bits, con lo cual en un corto plazo comienza desde u u cero nuevamente. Por esta vulnerabilidad es que no se puede garantizar la frescura (fresshness) de un paquete. Como solucin a este ataque, los paquetes de OLSR necesitan un nuevo mecanismo para valio dar su frescura. Para esto se utiliza un timestamp de 32 bits en cada uno de los paquetes. Existen varias alternativas para la implementacin de timestamps. En [30, Sec. V] se proponen distintas o alternativas de implementacin. En esta propuesta se utilizar la idea desarrollada en [21], la cual o a no depende de la sincronizacin de relojes y es un intercambio simple de mensajes. o La propuesta planteada en [21], consiste en un dilogo para intercambiar los relojes de cada a extremo. Para esto utiliza mensajes especiales. En esta tesis se utilizar la idea de [21] pero no se utilizarn mensajes especiales sino que el a a intercambio de relojes se llevar a cabo durante el proceso de autenticacin donde se agregar a a o a los mensajes la hora de cada nodo (notar que la modicacin se hizo sobre los mensajes de o autenticacin bsicos y no sobre los detallados en el proceso de intercambio de claves del nivel 1 o a de securizacin). De esta manera, el nodo receptor del mensaje puede calcular la diferencia horaria o y almacenarla en la tabla de vecinos. Para llevar a cabo este intercambio de debe modicar el mensaje AUTH MESSAGE para agregar un campo para el timestamp.
1. A B : A, B, CertA , RA , T imeA , sign(H(A, B, CertA , RA , T imeA )) 2. B A : B, A, CertB , RB , T imeB sign(H(B, A, CertB , RA , RB , T imeA )) 3. A B : A, B, sign(H(A, B, RA , RB , T imeA , T imeB )) Se toma en cuenta un factor de error S (parametrizable con el protocolo) que determina una tolerancia para el clculo del timestamp. Cada paquete recibido tiene su propio timestamp. El a nodo receptor extrae el timestamp del paquete y calcula la diferencia con su reloj calculando TN = Tlocal Tpaquete . A continuacin evala T0 S < TN y T0 + S > TN , donde T0 es la o u diferencia horaria almacenada en la tabla de vecinos. En caso que la validacin del timestamp o sea correcta se procesa el mensaje, en caso contrario se descarta. Para compensar algn desfasaje de los relojes, se realiza un ajuste de T0 calculando el promedio u entre la diferencia horaria almacenada y la calculada para este paquete (T0 = (T0 + TN )/2). Con la implementacin del timestamp, se modica el mensaje de rma del paquete generado o en el nivel 1 de securizacin ya que es necesario que el timestamp pertenezca a este mensaje para o garantizar la frescura del paquete. El nuevo mensaje de rma (Figura 9.13) contiene el timestamp, el cual es parte de los campos a tener en cuenta en para la rma ya que es necesario que ese campo no sea alterado.
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SCHEMA | ALGORITHM | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TIMESTAMP | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SIGNATURE (160 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figura 9.13: Formato del mensaje rma con timestamp
9.4.3.
Prevencin contra ataques de DoS o
Uno de los ataques ms comunes son los ataques de Denegacin de Servicio. Estos ataques a o pueden ser realizados de distantas maneras, por ejemplo un nodo malicioso o mal congurado podr enviar docenas de mensajes de autenticacin por segundo haciendo un desgaste de energ a o a procesando el mensaje en el nodo receptor. Una manera sencilla de mitigar este tipo de ataque es mantener un contador por cada direccin o de origen que env un mensaje. Cuando el nodo recibe un mensaje de un determinado origen, a guarda ese registro en una tabla e inicializa un contador. Si este nodo recibe ms mensajes del a nodo agresor en el lapso de tiempo en el cual en contador todav est activo rechaza el mensaje. a a Esta prevencin no tiene efecto si el nodo agresor realiza un spoong de IP. En este caso el o protocolo cuenta con un mecanismo de aceptacin de paquetes de manera estad o stica para no saturar el nodo. Se establecen umbrales que son congurables para el protocolo y en base a esos umbrales se calcula cuando comienza a atender de manera estad stica.
9.4.4. Otros ataques mitigados
9.4.4.
Otros ataques mitigados
Con el solo hecho de la securizacin alcanzada en el Nivel 1, se pueden prevenir los ataques o que involucran la modicacin de los paquetes como Generacin Incorrecta de Mensajes HELLO, o o Generacin Incorrecta de Mensajes TC, ya que ningn nodo puede hacerse pasar por otro porque o u los nodos estn autenticados. Otros ataques pasivos son mitigados porque nodos que escuchan el a trco no pueden interpretarlo ya que est encriptado. a a
9.4.5.
OLSR RFC 3226 vs. OLSR Seguro
Realizando una comparacin rpida entre el protocolo original (RFC 3626) y el fortalecimiento o a propuesto, se puede ver que no se modica el funcionamiento pero s se agregan capas de seguridad y algunas modicaciones m nimas a las Etapa 1 (Censado y Descubrimiento de Vecinos) y la Etapa 2 (Eleccin de MPR). En la Figura 9.14 se puede ver de manera esquemtica como se ha o a empaquetado el protocolo original para hacerlo seguro.
Figura 9.14: Etapas del protocolo OLSR
114
9.5.
Ya a esta altura con los dos niveles de seguridad especicados se tiene un protocolo seguro e inmune a algunos ataques. El objetivo del tercer nivel es proponer mecanismos de autodefensa para la red. Para ello se denen dos mecanismos. Uno, el mismo protocolo implementa un mecanismo de denuncia de los nodos que estn intentando un ataque o tienen un comportamiento a incorrecto y el otro es el agregado de un componente externo al protocolo que es un Sistema de Deteccin de Intrusos. Los mecanismos descriptos en este nivel es una opcin ms planteada en o o a esta tesis para hacer la red segura pero no ser analizada en profundidad con lo cual son objeto a de estudio futuro.
9.5.1.
Mecanismo de Denuncia
Una alternativa de autodefensa ser que si un nodo detecta que est siendo v a a ctima de un ataque pueda reportar este incidente a una CA. Las CAs que estn conectadas al backbone a de la red mantienen un dilogo sobre los reportes enviados por los nodos. Las CAs reciben a estos incidentes pero solo toman como vlidos los que provienen de algn nodo con un nivel de a u conabilidad alto (umbral parametrizable en el protocolo) y se tomar una accin cuando ms de a o a un nodo (valor parametrizable) conable realice una denuncia (Voto Calicado). En ese momento se genera una revocacin del certicado y es anunciado a todas las CAs de la red. o
9.5.2.
Sistema de Deteccin de Intrusos o
Un Sistema de Deteccin de Intrusos es muy utilizado en el mbito de grandes redes, tiene o a como objetivo detectar intrusos en base a comportamiento de los clientes de la red. A diferencia del mecanismo de denuncia, el IDS puede ser congurado para que actualice la base de conocimientos o el mismo IDS puede aprender, en cambio el mecanismo de denuncia es algo jo que tiene el protocolo y cualquier cambio que se quiera realizar requiere una modicacin del protocolo y o redistribucin del mismo. o 9.5.2.1. Interaccin con las CAs o
El IDS, es un nodo ms que pertenece a la red y los clientes lo ven como un cliente ms. El a a IDS debe correr en un nodo seguro de la red y poseer un certicado especial para comunicarse con las CAs. El IDS detecta un comportamiento extrao de un determinado nodo y env la noticia a las n a CAs que tiene a su alcance. La conexin con las CAs se hace con una conexin SSL de dos v o o as (el nodo valida la identidad de la CA y la CA la del nodo mediante los certicados). Una vez que la CA recibi el mensaje actualiza su CRL. o
9.5.3.
Sincronizacin de CRLs o
Las CAs, en una red mvil urbana van a ser nodos interconectados a travs del backbone de o e la red y van a tener un enlace estable, con lo cual garantiza cierta conabilidad de interconexin. o
9.6. Debilidades del Esquema de Seguridad propuesto
Las CAs, por ser nodos que pertenecen a la red y la red utiliza un protocolo proactivo conocen cuales son las CAs de la red con lo cual pueden comunicarse con cada una de ellas. Peridicamente o una CA recorre el las CAs disponibles y establece una conexin SSL de dos v con otra CA o as y le pide su CRL y actualiza la propia agregando las entradas que no tiene. Antes de proceder con la actualizacin de la CRL, verica si la fecha de actualizacin de la CRL descargada de la o o CA remota en ms vieja que la se tiene no se hace nada, en caso contrario se procede con la a actualizacin. o
9.6.
Debilidades del Esquema de Seguridad propuesto
El esquema de seguridad propuesto en esta tesis garantiza los servicios bsicos que debe a prestar una red de datos segura y es inmune a cierto tipo de ataques pero no es infalible y tiene debilidades. El protocolo no previene los ataques a las capas inferiores como por ejemplo ataques de capa f sica, donde un nodo puede ser v ctima de interferencias del nodo agresor (jamming) impidiendo la comunicacin con el resto de sus vecinos, ataques de capa dos (enlace) donde el nodo agresor o puede hacer spoong de MAC address o en capa de red spoong de IP. Con esta debilidad expuesta, un nodo que fue excluido de la red podr reingresar como un a nodo nuevo cambindose su direccin IP y su MAC address. En este caso la red lo reconoce como a o un nodo nuevo y la conanza que hab ganado dentro de la red con su identidad anterior la a pierde.
9.7.
Resumen
A lo largo de este capitulo se dieron detalles de la implementacin del esquema de seguridad o propuesto para una red mvil urbana. Este esquema se divide en dos partes, la primera que o involucra el aspecto organizacional de una red mvil urbana y la segunda es la modicacin del o o protocolo OLSR para ser inmune a distintos ataques. Este fortalecimiento del protocolo se divide en tres niveles, los cuales atacan distintos aspectos de seguridad. Nivel 1 introduce algoritmos y mecanismos criptogrcos para garantizar autenticacin, condencialidad y no repudio. El Nivel a o 2 mitiga distintos ataques y por ultimo el Nivel 3, el cual es objeto de estudio futuro incorpora un mecanismo de autodefensa de la red.
116
Cap tulo 10
Prueba de Contenido
El objetivo de este cap tulo es describir como se realiz la prueba de contenido o para demostrar el funcionamiento de algunas modicaciones introducidas al protocolo OLSR para mejorar su seguridad dentro de un mbito urbano . a
En el Cap tulo 9 se dieron los detalles sobre los distintos niveles de securizacin propuestos en o esta tesis para el protocolo OLSR. Para conrmar el correcto funcionamiento de la modicacin o al protocolo original, se realiz una prueba de contenido donde se implementaron algunas de las o nuevas funcionalidades. A lo largo de este cap tulo se detallar como fue implementada la prueba a de contenido. Para realizar la prueba es necesario contar con una red mvil funcionando con una cantidad o de nodos determinada y distribu dos de manera tal que un nodo deba rutear a travs de otro e para llegar al destino. Este escenario en un ambiente de laboratorio es muy dif de conseguir cil con lo cual se desarroll un simulador para poder probar el protocolo. o Las funcionalidades implementadas en el simulador son: Implementacin de la Autoridad Certicante. o Descubrimiento de Autoridades Certicantes. Solicitud de un certicado por parte del nodo. Firmado del Requerimiento y emisin del certicado vlido para la red. o a Descubrimiento de Vecinos. Autenticacin de Vecinos. o 117
10.1. Arquitectura
10.1.
Arquitectura
El protocolo OLSR es un programa que es ejecutado en la capa de aplicacin, es decir utiliza o las capas inferiores para enviar mensajes y en base a ellos modica la tabla de rutas del Sistema Operativo sobre el cual corre. La implementacin de la prueba de contenido se realiz de la misma manera pero en este caso o o no es parte del objetivo de la misma realizar la modicacin de la tabla de rutas del SO base. o Otra de las premisa de la implementacin es que no contempla cambios de topolog durante cada o a una de las etapas. La prueba asume que el escenario se mantiene esttico y no sufre alteraciones. a El simulador fue codicado en Java, utilizando librer open source para la manipulacin de as o certicados. La arquitectura bsica del simulador esta constituida por cuatro mdulos (Figura 10.1). El a o mdulo de procesamiento de mensajes OLSR (MulticastDaemon), el mdulo de la Autoridad o o Certicante (CAModule), el mdulo de autenticacin con los vecinos (AuthDaemon) y el nodo o o propiamente dicho (Node).
Figura 10.1: Principales mdulos del simulador o
118
Prueba de Contenido
10.1.1.
Certicados y Keystores
Como un nodo debe manejar certicados y la prueba de contenido fue desarrollada en Java, este lenguaje hace uso de Keystores para almacenar los certicados del programa Java [33]. En particular en esta implementacin se eligi usar dos Keystore independientes, uno con el n o o de almacenar la identidad del nodo y el otro para almacenar los certicados de los nodo conados. As el proceso Java cuando establece una conexin SSL o necesita vericar algn certicado que o u le fue presentado hace uso de estos repositorios para validarlos.
10.1.2.
Conguracin del Nodo o
Cada nodo cuenta con un archivo de conguracin en el cual se le especica entre otras cosas o cuales son los Keystores del nodo (identidad y conanza), parmetros necesarios para hacer uso a de los mismos, direccin IP principal del nodo, si el nodo va a actuar como CA o no y el path al o archivo de topolog de la red. a El archivo de topolog de red es un archivo en formato XML en el cual est el escenario a a bsico sobre el cual se inicia el nodo. En este archivo est el listado de vecinos, la tabla de ruteo, a a el listado de links con los vecinos, tabla de topolog etc. En particular en esta implementacin a, o ese archivo contiene la estructura de un red vac sin ningn vecino. a, u
10.1.3.
Plugin olsrd para generar el archivo de topolog a
Para crear el archivo de topolog se creo un plugin de olsrd el cual imprime en formato XML a toda la informacin de las tablas del protocolo. El formato del archivo XML fue diseado para o n 1 ser usado luego con XStream y poder construir el objeto Nodo. El plugin fue programado en base a las facilidades que da la implementacin de olsrd para o realizar este tipo de extensiones. Esta extensin escucha en un socket y cuando se establece una o conexin, imprime el contenido de las tablas en formato XML. o Desde el simulador existe un modulo llamado DataCollector, el cual podr ser utilizado para a actualizar en cualquier momento la topolog de la red del simulador con la topolog real de a a la red en la cual est participando el nodo. Esta funcionalidad fue desarrollada para generar el a archivo de topolog que usa el simulador para cada nodo, pero no se utiliza para actualizar la a informacin del nodo. o
10.1.4.
Mensajes
El diseo de los mensajes se hizo teniendo en cuenta los originales del protocolo y extendiendo n stos con los mensajes modicados para adaptarse a la propuesta de esta tesis. Como se puede e ver en la Figura 10.2, todos los mensajes heredan de una clase llamada GenericMessage, el cual tiene entre otras cosas un mtodo abastracto llamado processMessage(), el cual obliga a cada e mensaje que lo extiende a implementar este mtodo que tiene como objetivo que cada mensaje e sepa como procesarse. De esta manera los servidores que reciben algn mensaje no tienen que u
1 http://xstream.codehaus.org/
119
10.1.5. Mdulo de Autoridad Certicante o
Figura 10.2: Diagrama de Clases para los mensajes del protocolo
tener la lgica de procesamiento, sino que cada uno sabe cul es su funcin y se procesa a si o a o mismo y genera una respuesta.
10.1.5.
Mdulo de Autoridad Certicante o
El mdulo de Autoridad Certicante, es una clase que se ejecuta en un thread independiente, o establece un socket y se queda esperando por peticiones de certicados. El nodo tiene un archivo
Prueba de Contenido
de conguracin donde uno de las propiedades a congurar es si el nodo va a actuar como CA o o no. En caso que as sea, se especica cual el es Keystore donde se encuentra su certicado expedido por la Root CA de la comunidad. Este mdulo no solo tiene la responsabilidad de lanzar el servidor, sino que cuenta con todos o los mtodos necesarios para manipular los certicados. e
10.1.6.
Mdulo de Autenticacin con los vecinos o o
Una vez que el nodo tiene un certicado vlido para participar en la red, necesita autenticarse a con los vecinos para hacer uso de la misma. Para ello el nodo cuenta con este mdulo que lanza o un servidor el cual queda a la espera de mensajes de autenticacin. Este mdulo utiliza los dos o o Keystores congurados para el nodo. El de identidad lo utiliza para enviar su propio certicado en el mensaje AUTH MESSAGE y utiliza el de conanza para almacenar los certicados de los vecinos conados. Para simplicar la implementacin del proceso de autenticacin de los vecinos, se impleo o ment las primeras dos fases 9.3.3.1 como un handshaking de SSL en el cual se realiza una o autenticacin de SSL de dos v La autenticacin SSL de dos v [34, Cap. 10] consiste en que o as. o as el server cuando recibe una peticin de conexin, obliga al cliente a presentar su certicado y o o a la vez el servidor le env su certicado al cliente. De esta manera en ambos lados se evala a u la cadena de certicacin de los mismos y la validez. Una vez que ambos nodos se autenticaron o env el mensaje AUTH MESSAGE FINISH y los nodos conf entre si. Este mdulo utiliza los an an o mtodos del Mdulo de CA para validar la cadena de certicacin. e o o
10.1.7.
Mdulo de Procesamiento de mensajes OLSR o
El mdulo de procesamiento de los mensajes del protocolo, como se puede ver en la Figura 10.1, o corre un servidor que escucha en un socket multicast (MCastReader ) y con cada mensaje que llega ejecuta el mtodo processMessage() de cada uno de ellos para que se auto-procesen y luego e poder enviar el mensaje de respuesta.
10.2.
Implementacin o
A lo largo de esta seccin se van a presentar algunos detalles de implementacin del simulador o o para dar una idea al lector sobre como fue desarrollado sin entrar en detalles propios de la programacin. o
10.2.1.
Descubrimiento de CAs y Vecinos
El nodo que quiere ingresar a la red realiza como primera accin un descubrimiento de las o Autoridades Certicantes de la red para realizar posteriormente el pedido del certicado. El procedimiento de descubrimiento se realiza enviando un mensaje de tipo CA DISCOVER por medio una trama de multicast. Para hacer esto se instancia un mensaje de tipo CADiscoverMsg, se agrega el mensaje a un paquete OLSR y luego es enviado a la red.
10.2.2. Autoridad Certicante
Cuando un vecino recibe el mensaje, agrega al nodo que origin el mensaje como vecino, o inserta en el mensaje recibido el listado de CAs que l conoce y luego env la respuesta pero e a con direccin de destino la del nodo solicitante, as cualquier nodo que reciba la respuesta y no o es para el, la descarta. El nodo que intenta ingresar a la red recibe la respuesta del nodo vecino y agrega a ste como e vecino e inserta en la tabla de topolog las CAs informadas por el vecino. a De esta manera el proceso de descubrimiento tiene doble propsito, descubrir los vecinos y o las CAs de la red. Todos los nodos tienen el demonio de procesamiento de mensajes OLSR escuchando en la misma IP y puerto de multicast. Para la implementacin del simulador el demonio escucha en la o direccin 228.0.0.23:4444 o 10.2.1.1. Demonio de Procesamiento de mensajes OLSR
La implementacin del demonio de procesamiento de mensajes de OLSR es muy sencilla. La o clase MulticastDaemon tiene un mtodo para inyectar paquetes OLSR en la red y lanza un thread e con la clase MCastReader que recibe los mensajes multicast de los vecinos. Cada vez que recibe uno, invoca el mtodo processMessage() del mensaje recibido, el cual sabe que es lo que tiene que e hacer.
Figura 10.3: Diagrama de Secuencia para la rma de un CertReq
10.2.2.
Autoridad Certicante
La Autoridad Certicante fue implementada dentro del mdulo CAModule. Cuando se inso tancia esta clase, se inicia un thread que lanza la clase CAServer, la cual establece un socket que
Prueba de Contenido
espera peticiones SSL en el puerto 4443. La Autoridad Certicante solo es iniciada si en el archivo de conguracin del nodo o (config.properties), se especic la propiedad enableCA=true. o Como se dijo anteriormente, la clase CAModule, no solo laza la clase CAServer, sino que tiene mtodos estticos para realizar la gestin de certicados. e a o Cuando el servidor recibe una conexin de un nodo, invoca el mtodo precessMessao e ge()(Figura 10.3) el cual valida que el mensaje sea tipo CERT REQ y luego rma el requerimiento invocando el mtodo de clase signCertReq() de la clase CAModule. Finalmente con el certicado e rmado, genera un mensaje de respuesta (CERT REPLY) y se lo env al nodo. a
Figura 10.4: Diagrama de Secuencia de la obtencin de un certicado o
10.2.2.1.
Interaccin Nodo-CA o
El servidor de la CA crea un socket de tipo SSLServerSocket en cual utiliza el keystore de identidad para enviar su certicado al cliente que establece la conexin. En este punto, el nodo o cliente, valida la cadena de certicacin del certicado presentado por la CA. El nodo puede o realizar esta tarea ya que en el keystore de conanza tiene el certicado de la Root CA de la comunidad. Una vez validada la identidad de la CA, se env el mensaje CERT REQ. El nodo a cliente utiliza la clase Tools que tiene el mtodo makeSSLConnection() que realiza la conexin e o SSL y valida la cadena de certicacin del servidor. o La CA env el mensaje CERT REPLY con el certicado rmado para poder participar de la red. a El nodo cliente valida el certicado recibido, lo almacena e inicia el demonio de Autenticacin o con los Vecinos. En la Figura 10.4 se puede ver el diagrama de secuencia simplicado para la obtencin de un certicado. o
10.2.3.
Autenticacin con los Vecinos o
Una vez que el nodo que quiere ingresar a la red obtiene un certicado vlido, inicializa el a demonio de Autenticacin con los vecinos. El demonio de autenticacin inicia un servidor con un o o socket SSL (puerto 4444), pero en este caso a diferencia del mdulo de CA, se instancia para que o
10.3. Modos de Operacin del Simulador o
solicite al cliente que presente su certicado y as validar que ste tiene un certicado expedido e por una CA vlida (Autenticacin SSL de dos v a o as). Esta autenticacin se realiz para simplicar o o la implementacin y realiza los pasos 1 y 2 de la autenticacin propuesta en la Seccin 9.3.3.1. o o o Ambos nodos luego de autenticarse, actualizan su tabla de vecinos indicando que el vecino es conable y almacena el certicado en el keystore de conanza. Para realizar la autenticacin SSL de dos v se utilizan los dos keystores, uno para enviar o as, su identidad y el otro para validar la cadena de certicacin del certicado del vecino. o
10.3.
Modos de Operacin del Simulador o
(a) Mdulos instanciados por el nodo en modo o CA
(b) Mdulos instanciados por el nodo en modo o cliente
Figura 10.5: Instanciacin de mdulos dependiendo el modo de operacin o o o
Como se dijo en varias oportunidades, el simulador puede operar como CA o como nodo cliente de la red. En caso que el nodo sea ejecutado como CA, se inicializan los siguientes mdulos (Figuo ra 10.5(a)): Mdulo de CA (CAModule), el cual contiene el sservidor que atiende las peticiones de los o clientes (CAServer). Mdulo de procesamiento de mensajes multicast (MulticastDaemon), el cual contiene el o servidor de mensajes multicast que recibe la informacin y peticiones de los nodos vecinos. o
Prueba de Contenido
Mdulo de Autenticacin con los vecinos (AuthDaemon). o o En caso que el nodo sea ejecutado como cliente, se inicializan los siguientes mdulos (Figuo ra 10.5(b)): Mdulo de procesamiento de mensajes multicast (MulticastDaemon). o Mdulo de Autenticacin con los vecinos (AuthDaemon). o o
10.4.
Resumen
A lo largo de este cap tulo de dieron detalle de las mejoras propuestas en la tesis para el protocolo OLSR implementadas en la prueba de contenido. Para fundamentar la propuesta de esta tesis, se realiz un simulador que implementa algunas de las mejoras. Con este simulador o se muestra que la propuesta funciona, pero la misma no tiene como objetivo realizar un juicio sobre la performance del nuevo protocolo ya que por la naturaleza misma de la implementacin o en Java dista de la real desarrollada en C.
125
10.4. Resumen
126
Cap tulo 11
Conclusiones
En este trabajo de tesis se present un Esquema de Seguridad para una Red Mvil Urbana. o o Para la elaboracin de esquema se pasaron por distintas instancias, las cuales son presentadas o durante el desarrollo de este trabajo. El primer paso dado fue profundizar sobre los diferentes protocolos de ruteo existentes o en estudio disponibles. Esto fue necesario para enriquecer lenguaje tcnico y diferentes alternativas e para realizar un mismo objetivo, rutear paquetes sobre una Red Mvil. Superada esta etapa y o viendo que los protocolos de ruteo de redes mviles en su mayor no contemplaban cuestiones o a relacionadas con la seguridad es que se vi la necesidad de investigar como solucionar estos o aspectos ya que en un medio hostil como lo es el aire un protocolo puede estar en riesgo si no se tiene en cuenta los posibles ataques. Para saber que requisitos debe cumplir una Red Mvil hubo o que remontarse a conceptos bsicos de seguridad para saber cuales son los servicios bsicos que a a debe brindar una red segura. Con los concepto de seguridad bsicos dentro de las herramientas a disponibles para allanar el camino hacia el objetivo de la tesis, se extendieron esos conceptos a Redes Mviles donde se vio que hay que agregar variables como que los nodos son a bater se o as, mueven, y no tienen grandes capacidades de procesamiento. Ya a esta altura se cuenta con los conocimiento de Redes Mviles, con los requisitos bsicos o a que debe cumplir un protocolo para ser considerado seguro. El siguiente paso fue estudiar que protocolos seguros hab disponibles y ver de que manera cumpl con los requisitos. a an Un aspecto clave para alcanzar el objetivo es estudiar como son, como se comportan y como se organizan las redes Urbanas, donde se encontr que en su mayor estn administradas por o a a comunidad sin nes de lucro. Fue fundamental conocer como es en particular la administracin y o organizacin de una Red Mvil Urbana como lo es Buenos Aires Libre para saber que el protocolo o o ms difundido entre las Redes Mviles Urbanas es el OLSR. a o El siguiente paso fue profundizar sobre el funcionamiento de este protocolo y analizar cuales ser los posibles ataques que podr sufrir. an a Con el conocimiento tcnico del funcionamiento y vulnerabilidades del protocolo OLSR ms e a los aspectos organizativos de una Red Mvil Urbana ya se contaba con los elementos sucientes o para enfrentarse a la ultima parte hacia el objetivo nal. 127
Luego de la lectura de varios art culos con propuestas de securizacin para OLSR, tomando o ideas de cada uno de ellos y ponindolas dentro del marco de una Red Mvil Urbana es que e o desarroll la propuesta de securizacin del protocolo OLSR. o o Dentro de los art culos le dos, ninguno de ellos daba una solucin completa como la propuesta o en esta tesis. La propuesta incluye: La distribucin de claves por medio de certicados digitales. o Se especic una pol o tica organizacional para distribuir entidades certicadoras Elaboracin de un esquema de conanza de un nodo y la participacin del mismo en la red. o o Se especic un mecanismo de reconocimiento y autenticacin con los vecinos. o o Se especic un mecanismo de intercambio de claves o Se utiliz una forma para rmar mensajes de control o Se utiliz un algoritmo de encriptacin simtrico combinado con la clave compartida para o o e la encripcin de los mensajes de control o Prevencin de Ataques o Alta disponibilidad de CAs El esquema propuesto presenta distintos niveles de seguridad, los cuales pueden ser implementados en distintas etapas y podr conformar mdulos agregados a la implementacin actual an o o del protocolo OLSR. La propuesta muestra como se pueden prevenir ataques t picos al protocolo OLSR. Se incorporaron mecanismos como por ejemplo un algoritmo simple de timestanping, una heur stica sencilla para detectar si un nodo est intentando hacer un ataque de tnel, un esquema de rmas a u para garantizar la integridad de los mensajes y un mecanismo de encripcin para garantizar la o condencialidad de los paquetes de OLSR. La solucin puede ser escalable para incorporar mecanismos de autodefensa como el uso de o un IDS. Se construy una solucin que cumple con la premisas bsicas para que una Red Mvil sea o o a o considerada segura. Se mejoraron aspectos existentes en algunas soluciones y se agregaron nuevas soluciones. Finalmente para asegurar el funcionamiento de la propuesta, se implement un simulador o para realizar la prueba de contenido donde se muestra el funcionamiento del protocolo durante la incorporacin de un nodo a la red. Esta prueba incluye el descubrimiento de las CAs, la obtencin o o de un certicado para participar en la red y la autenticacin con los vecinos o
128
Bibliograf a
[1] Stefano Basagni, Marco Conti, Silvia Giordano, Ivan Stojmenovic.Mobile Ad-Hoc Networking, IEEE Press, 2004. [2] Mehran Abolhasan, Tadeusz Wysocki, Eryk Dutkiewcz. A review of routing protocols for ad hoc networks, Elsevier, 2004. [3] Charles E. Perkins, Pravin Bhagwat. Highly Dynamic Desditation-Sequenced Distance-Vector Routing (DSDV) for Mobile Computers, SIGCOMM 94, pp 234-244, 1994. [4] D. Bertsekas, R. Gallager. Data Networks, Prentice-Hall, pp 297-333, 1987. [5] T. Clausen, P. Jacquet. Optimized Link State Routing Protocol (OLSR), RFC 3626, 2003. [6] P. Jacquet, P. Mhlethaler, T. Clausen, A. Laouiti, A. Qayyum, L. Viennot Optimized Link u State Routing Protocol for Ad Hoc Networks, IEEE, 2001 [7] Charles Perkins, E. Belding-Royer, S. Das. Ad hoc On-demand Distance Vector (AODV) Routing, RFC 3561, 2003 [8] Charles Perkins, E. Royer. Ad hoc On-demand Distance Vector Routing, Proc IEEE WMCSA, 1999. [9] R. Ogier, F. Templin, M. Lewis. Topology Dissemination Based on Reverse-Path Forwarding (TBRPF). RFC 3684, 2004 [10] D. Johnson, D. Maltz. The Dynamic Source Routing Protocol (DSR) for Mobile Ad Hoc Networks for IPv4, RFC, 2007 [11] David B. Johnson, David A. Maltz, Josh Broch. DSR: The Dynamic Source Routing Protocol for Multi-Hop Wireless Ad Hoc Networks, 2004 [12] Marc R. Pearlman, Zygmunt J. Haas. Determining the Optimal Conguration for the Zone Routing Protocol, IEEE, 1999 [13] Zygmunt J. Haas, Marc R. Pearlman, Prince Samar.The Zone Routing Protocol (ZRP) for Ad Hoc Networks, RFC DRAFT, 1999 129
BIBLIOGRAF IA
[14] Sung-Ju Lee, Mario Gerla.Split Multipath Routing with Maximally Disjoint Paths in Ad hoc Networks [15] Lidong Zhou, Zygmunt J Hass. Securing Ad Hoc Networks, IEEE Network Magazine, pp 24-30, 1999 [16] Po-Wah Yau, Chris Mitchel. Security Vulnerabilities in Ad Hoc Networks [17] D. Dhillon, T. S. Randhawa, M. Wang L. Lamont. Implementing a Fully Distributed Certicate Authority in an OLSR MANET, IEEE Communication Society, WCNC 2004 pp 682-688 [18] Fan Hong, Liang Hong, Cai Fu. Secure OLSR, IEEE AINA 2005. [19] Jean-Marie Orset, Ana Cavalli. A Security model for OLSR MANET Protocol. IEEE MDM 2006. [20] Cdric Adjih, Daniele Rao, Paul Mhlether. Attack Against OLSR: Distributed Key Mae u nagement for Security. INRIA, Domaine de Voluceau. [21] Adread Hafslund, Adreas Tonnesen, Roar Bjorgum Rotvik, Jon Andersson, Oivind Kure. Secure Extension to the OLSR protocol. OLSR Interon and Workshop, 2004. [22] IEEE Comitee. IEEE Standard Specications for Public-Key Cryptography. IEEE-SA Standandards Boards, 2004. [23] P. Papadimitratos and Z. J. Haas. Secure Routing for Mobile Ad Hoc Networks. In Proceedings of CNDS, 2002. [24] Krawczyk, H., Bellare, M., and R. Canetti, HMAC: Keyed-Hashing for Message Authentication. RFC 2104, February 1997. [25] A. Perrig, D. Song, R. Canetti, J. D. Tygar, B. Briscoe. Timed Ecient Stream Loss-Tolerant Authentication (TESLA). RFC 4082, Junio 2005. [26] Haiyun Luo, Songwu Lu. Ubiquitous and Robust Authentication Service for Ad Hoc Wireless Networks, Octubre 2000. [27] M. Myers, C. Adams, D. Solo, D. Kemp. Internet X.509 Certicate Request Message Format. RFC 2511 ,1999. [28] T. Dierks, C. Allen. The TLS Protocol. RFC 2246, 1999. [29] R. Housley, W. Ford, W. Polk, D. Solo. Internet X.509 Public Key Infrastructure Certicate and CRL Prole, RFC 2459, 1999. [30] Cedric Adjih, Thomas Clausen, Philippe Jacquet, Anis Laouiti, Paul Mhlethaler, Daniele u Rao. Securing the OLSR protocol. INRIA Rocquencourt, Project Hipercom.
BIBLIOGRAF IA
[31] William Stallings. Cryptography and Network Security. 4ta Edicion, 2006. [32] Douglas R. Stinson. Cryptography : Theory and Practice, 3era Edicion, 2002. [33] Scott Oaks. Java Security. OReilly, 2da Edicion, 2001 [34] David Hook. Beginning Cryptography in Java, John Wiley & Sons, 2005. [35] Ocina Nacional de Tecnolog de la Informacin Repblica Argentina (ONTI). Modelo a o u de Pol tica de Seguridad de la Informacin para Organismos de la Administracin Pblica o o u Nacional, Versin 1, Julio 2005 o
131

Caracoche Tesisdegradoingenieriainformatica

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Caracoche Tesisdegradoingenieriainformatica

Uploaded by

Copyright:

Available Formats

Redes Mviles Seguras o en un Ambito Urbano

Director: Hugo Pagola

Juan Manuel Caracoche - Tesis de grado Ingenier Informatica a

Juan Manuel Caracoche - Tesis de grado Ingenier Informatica a

Juan Manuel Caracoche

Juan Manuel Caracoche - Tesis de grado Ingenier Informatica a

Acerca del Autor

Juan Manuel Caracoche - Tesis de grado Ingenier Informatica a

Juan Manuel Caracoche - Tesis de grado Ingenier Informatica a

Juan Manuel Caracoche - Tesis de grado Ingenier Informatica a

Juan Manuel Caracoche - Tesis de grado Ingenier Informatica a

Juan Manuel Caracoche - Tesis de grado Ingenier Informatica a

Juan Manuel Caracoche - Tesis de grado Ingenier Informatica a

Juan Manuel Caracoche - Tesis de grado Ingenier Informatica a

Juan Manuel Caracoche - Tesis de grado Ingenier Informatica a

Juan Manuel Caracoche - Tesis de grado Ingenier Informatica a

2.2. Protocolos de Ruteo

Figura 2.1: Clasicacin de protocolos de ruteo o

Protocolos de Ruteo Proactivos, Reactivos e H bridos

Protocolos de Ruteo Proactivos

2.3.1. Protocolos de Ruteo Proactivos

Destination-Sequenced Distance-Vector (DSDV)

Figura 2.2: Multipoint Relays

2.3.2. Protocolos de Ruteo Reactivos

Protocolos de Ruteo Reactivos

2.3.2. Protocolos de Ruteo Reactivos

2.3.2. Protocolos de Ruteo Reactivos

(a) El origen 1 quiere enviar datos a 10

(b) El nodo 1 env un mensaje RREQ a sus a vecinos

(c) Los nodos 2, 3 y 4 reciben RREQ y los propagan a sus vecinos

(e) Se contin a la propagacin. 5 no propaga u o RREQ

(f) Se llega al nodo 10 y ste no reenv el e a RREQ porque es el destino

(g) 10 determina la ruta para enviar RREP

Figura 2.3: Ejemplo de la construccin de una ruta en AODV o

Dynamic Source Routing (DSR)

2.3.2. Protocolos de Ruteo Reactivos

Figura 2.4: Deteccin de un enlace roto y env del RERR o o

Juan Manuel Caracoche - Tesis de grado Ingenier Informatica a

(a) El origen 1 quiere enviar datos a 10

Figura 2.5: Ejemplo de la construccin de una ruta en DSR o

2.3.3. Protocolos de Ruteo H bridos

Protocolos de Ruteo H bridos

Figura 2.6: Zona de un nodo usando ZRP

Figura 2.7: Descubrimiento de una ruta con IERP

2.3.4. Tcnicas de Ruteo e

Juan Manuel Caracoche - Tesis de grado Ingenier Informatica a

Juan Manuel Caracoche - Tesis de grado Ingenier Informatica a

Conceptos Bsicos de Criptograf a a

3.1.1. Cifrados Simtricos e

Juan Manuel Caracoche - Tesis de grado Ingenier Informatica a

Juan Manuel Caracoche - Tesis de grado Ingenier Informatica a

3.1.3. Resumen Criptogrco a

Figura 3.1: Proceso de Generacin y Vericacin de una Firma Digital o o

Resumiendo la rma digital garantiza integridad y no repudio.

Juan Manuel Caracoche - Tesis de grado Ingenier Informatica a

Juan Manuel Caracoche - Tesis de grado Ingenier Informatica a

Seguridad en Redes Mviles o

Seguridad en Redes Mviles o

4.1.2. Ataques Internos

Seguridad en Redes Mviles o

4.2. Protocolos de Ruteo Seguros

Protocolos de Ruteo Seguros

SRP - Secure Routing Protocol