Redes Móviles Seguras en un Ambito Urbano´materias.fi.uba.ar/7500/caracoche-tesisdegradoin... · Móviles Urbanas son un subgrupo de las redes móviles donde se encuentran nodos

Redes Moviles Seguras

en un Ambito UrbanoUtilizando Protocolo OLSR

Tesis de Grado en Ingenierıa InformaticaOrientacion en Sistemas Distribuıdos

Juan M. [email protected]

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 pregunto porque.”

Bernard Baruch

Resumen

Las redes moviles (Mobile Ad-hoc NETworks -MANET-) son un tipo especial de redes enla cual un conjunto de dispositivos moviles conforman de manera temporal una red de formaautonoma sin la necesidad de una infraestructura. Para estos ambientes existen distintos proto-colos para el ruteo de paquetes donde los integrantes de la misma estan en continuo movimiento,hay protocolos que brindan a parte de ruteo, seguridad para los integrantes de la red. Estos pro-tocolos son variados y cada uno es propenso a distintos tipos de ataques. En particular las redesMoviles Urbanas son un subgrupo de las redes moviles donde se encuentran nodos diseminadospor toda una ciudad, la geografıa de una ciudad y las limitaciones del medio de trasmision de latecnologıa 802.11 hacen que se deba armar una topologıa particular, lo que hace que los nodosque participen tengan distintos roles. En particular la red Urbana Buenos Aires Libre es el objetode estudio de esta tesis donde se analiza el protocolo OLSR utilizado por la red y se disena unesquema de seguridad para hacerla lo mas inmune posible a ataques externos.

Juan Manuel Caracoche - Tesis de grado Ingenierıa Informatica I

Abstract

The mobile networks (Mobile Ad-hoc NETworks -MANET-) are a special kind of networkwhere a set of mobile devices build in a spontaneous way a temporary self-organized networkwithout any infraestruture to work. For this king of networks there are differents routing protocolsto guide packets between nodes which are constantly moving. Some of this protocols not onlyguarantee the routing, they also give security to the protocol. In particulary, a Urban MobileNetworks are a subset of mobile networks where nodes are diseminated over all the city. Thecity’s geography and the transmision technology (802.11) bring into the scene some constraintsthat makes to build specials topologies where each node in the net may take different roles. Inparticulary the Urban Network Buenos Aires Libre, is the study target of this thesis. Over thisnetwork is analyzed the OLSR protocol which is used as routing protocol and a security schemeis designed to make this networks safer as possible against external attacks.

II Juan Manuel Caracoche - Tesis de grado Ingenierıa Informatica

Agradecimientos

Quiero agradecer a muchas personas por el apoyo durante el desarrollo de esta tesis y en lavida misma

Al Ing. Hugo Pagola, tutor de esta tesis, quien a pesar de sus innumerables compromisos pudosiempre 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 sacrificios entendieron quela educacion de un hijo es mas que una inversion.

A mi novia que tuvo la paciencia de acompanarme en el duro camino de mis ultimos anos dela carrera.

Por supuesto no podıa olvidarme del apoyo incondicional de mis amigos y companeros, queme dieron durante los anos de facultad, los mejores anos de mi vida.

Juan Manuel CaracocheAgosto 2008

Juan Manuel Caracoche - Tesis de grado Ingenierıa Informatica III

Acerca del Autor

Juan Manuel Caracoche nacio en la ciudad de Pellegrini, provincia de Buenos Aires el 16de Febrero de 1980. Realizo sus estudios primarios en la escuela Guillermo de Soldato y lossecundarios en el Instituto Jose Manuel Estrada, ambos establecimientos de su ciudad natal. Enel ano 1998 se traslada a la ciudad de Buenos Aires para comenzar sus estudios universitarios en laFacultad de Ingenierıa de la Universidad de Buenos Aires, actualmente es estudiante de la carreraIngenierıa Informatica. Adicionalmente es docente auxiliar del Departamento de Electronica dela misma Universidad.

IV Juan Manuel Caracoche - Tesis de grado Ingenierıa Informatica

Indice general

Resumen I

Abstract II

Agradecimientos III

Acerca del Autor IV

1. Introduccion 111.1. Motivacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121.2. Objetivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2. Redes Moviles 132.1. Generalidades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.2. Protocolos de Ruteo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142.3. Protocolos de Ruteo Proactivos, Reactivos e Hıbridos . . . . . . . . . . . . . . . . . 15

2.3.1. Protocolos de Ruteo Proactivos . . . . . . . . . . . . . . . . . . . . . . . . . 152.3.1.1. Destination-Sequenced Distance-Vector (DSDV) . . . . . . . . . . 162.3.1.2. Optimized Link State Routing (OLSR) . . . . . . . . . . . . . . . 17

2.3.2. Protocolos de Ruteo Reactivos . . . . . . . . . . . . . . . . . . . . . . . . . 182.3.2.1. Ad hoc on-demand distance vector (AODV) . . . . . . . . . . . . 192.3.2.2. Dynamic Source Routing (DSR) . . . . . . . . . . . . . . . . . . . 23

2.3.3. Protocolos de Ruteo Hıbridos . . . . . . . . . . . . . . . . . . . . . . . . . . 262.3.3.1. Zone Routing Protocol (ZRP) . . . . . . . . . . . . . . . . . . . . 26

2.3.4. Tecnicas de Ruteo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282.3.4.1. Multipath Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

2.4. Resumen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

3. Seguridad Informatica 313.1. Conceptos Basicos de Criptografıa . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

3.1.1. Cifrados Simetricos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323.1.1.1. Seguridad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323.1.1.2. Ventajas y Desventajas . . . . . . . . . . . . . . . . . . . . . . . . 32

1

INDICE GENERAL

3.1.1.3. Algoritmos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323.1.2. Cifrados Asimetricos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

3.1.2.1. Seguridad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333.1.2.2. Ventajas y Desventajas . . . . . . . . . . . . . . . . . . . . . . . . 343.1.2.3. Algoritmos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

3.1.3. Resumen Criptografico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343.1.3.1. Hash . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343.1.3.2. MAC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

3.1.4. Firma Digital . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353.1.5. PKI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

3.1.5.1. Proposito y funcionalidad . . . . . . . . . . . . . . . . . . . . . . . 363.1.5.2. Usos de la tecnologıa PKI . . . . . . . . . . . . . . . . . . . . . . . 373.1.5.3. Certificados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

3.1.6. Componentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 383.1.6.1. Consideraciones sobre PKI . . . . . . . . . . . . . . . . . . . . . . 38

3.2. Resumen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

4. Seguridad en Redes Moviles 414.1. Ataques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

4.1.1. Ataques Externos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 424.1.1.1. Interceptacion Pasiva . . . . . . . . . . . . . . . . . . . . . . . . . 424.1.1.2. Interferencia Activa . . . . . . . . . . . . . . . . . . . . . . . . . . 43

4.1.2. Ataques Internos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 434.1.2.1. Nodo Fallido . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 434.1.2.2. Nodo Fallido Maligno . . . . . . . . . . . . . . . . . . . . . . . . . 434.1.2.3. Nodo egoısta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 444.1.2.4. Nodo Malicioso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

4.2. Protocolos de Ruteo Seguros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 464.2.1. SRP - Secure Routing Protocol . . . . . . . . . . . . . . . . . . . . . . . . . 46

4.2.1.1. Descubrimiento de la Ruta . . . . . . . . . . . . . . . . . . . . . . 464.2.1.2. Otras Vulnerabilidades . . . . . . . . . . . . . . . . . . . . . . . . 484.2.1.3. Ideas Rescatadas para el Desarrollo de la Tesis . . . . . . . . . . 48

4.2.2. ARIADNE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 484.2.2.1. Ideas Rescatadas para el Desarrollo de la Tesis . . . . . . . . . . 50

4.2.3. Resumen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

5. Redes Moviles Urbanas 515.1. Proyectos Comunitarios Libres . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

5.1.1. Buenos Aires Libre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 525.2. Topologıa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

5.2.1. Direccionamiento IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 545.3. Protocolos de Ruteos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

2 Juan Manuel Caracoche - Tesis de grado Ingenierıa Informatica

INDICE GENERAL

5.4. Servicios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 555.5. Administracion de la Red BAL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 555.6. Resumen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

6. Protocolo OLSR 576.1. Introduccion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 576.2. Terminologıa Propia de OLSR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 576.3. Tablas del Protocolo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 586.4. ¿Como Funciona? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

6.4.1. Mensajes de OLSR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 606.4.2. Etapa 1: Censado y Descubrimiento de Vecinos . . . . . . . . . . . . . . . . 61

6.4.2.1. Mensaje de HELLO . . . . . . . . . . . . . . . . . . . . . . . . . . 616.4.2.2. Mensaje MID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 636.4.2.3. Censado y Descubrimiento . . . . . . . . . . . . . . . . . . . . . . 64

6.4.3. Etapa 2: Eleccion de los MPRs . . . . . . . . . . . . . . . . . . . . . . . . . 656.4.4. Etapa 3: Mantenimiento de la Topologıa . . . . . . . . . . . . . . . . . . . . 68

6.4.4.1. Mensaje TC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 696.4.4.2. Mecanismo de propagacion de los mensajes TC . . . . . . . . . . . 69

6.4.5. Etapa 4: Formacion de las Rutas . . . . . . . . . . . . . . . . . . . . . . . . 706.4.6. Etapa 5: Mantenimiento de las Rutas . . . . . . . . . . . . . . . . . . . . . 716.4.7. Comunicacion con Otras Redes . . . . . . . . . . . . . . . . . . . . . . . . . 71

6.4.7.1. Mensaje HNA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 716.4.7.2. Asociacion de la redes . . . . . . . . . . . . . . . . . . . . . . . . . 72

6.5. Seguridad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 726.5.1. Confidencialidad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 726.5.2. Integridad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 736.5.3. Mensajes a Proteger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

6.6. Vulnerabilidades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 746.7. Resumen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

7. Diseno de un Esquema de Seguridad para una Red Movil OLSR Urbana 797.1. Esquema de Seguridad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 797.2. Fundamentos del Diseno . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

7.2.1. OLSR mas Fuerte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 807.3. Esquema de Clave Publica y Privada . . . . . . . . . . . . . . . . . . . . . . . . . . 81

7.3.1. Autoridad Certificante . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 817.3.2. Esquema de Certificacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

7.4. Fortalecimiento de OLSR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 837.4.1. Prevencion de Ataques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

7.5. Integracion del IDS y la CA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 847.6. Interaccion de los Nodos Clientes con Esquema de Seguridad Planteado . . . . . . 84

7.6.1. Esquema de confianza ganada . . . . . . . . . . . . . . . . . . . . . . . . . . 84

Juan Manuel Caracoche - Tesis de grado Ingenierıa Informatica 3

INDICE GENERAL

7.7. Resumen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

8. Artıculos mas Relevantes Relacionados con la Seguridad de OLSR 878.1. Secure Extension to the OLSR protocol . . . . . . . . . . . . . . . . . . . . . . . . 88

8.1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 888.1.2. Firma . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 888.1.3. Timestamps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

8.2. Secure OLSR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 898.2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 898.2.2. Deteccion segura de vecino . . . . . . . . . . . . . . . . . . . . . . . . . . . 898.2.3. Autenticacion de vecinos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 908.2.4. Paquetes de Ruteo Seguros . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

8.3. Securing the OLSR protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 928.3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 928.3.2. Firma de Mensajes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 928.3.3. Timestamping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 938.3.4. PKI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

8.3.4.1. PKI Proactiva Simple para OLSR . . . . . . . . . . . . . . . . . . 948.3.4.2. PKI Reactiva Simple para OLSR . . . . . . . . . . . . . . . . . . . 94

8.4. Resumen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

9. Detalles de Implementacion del Esquema de Seguridad Propuesto 979.1. Esquema de Certificacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

9.1.0.3. Procedimiento para la registracion de un nodo . . . . . . . . . . . 989.2. Fortalecimiento del Protocolo OLSR . . . . . . . . . . . . . . . . . . . . . . . . . . 989.3. Fortalecimiento de OLSR: Nivel 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

9.3.1. Tablas del Protocolo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 999.3.2. Obtencion del Certificado . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100

9.3.2.1. Generacion del mensaje CADISCOVER . . . . . . . . . . . . . . . . . 1009.3.2.2. Procesamiento del mensaje CADISCOVER . . . . . . . . . . . . . . 1009.3.2.3. Generacion del CERTREQ . . . . . . . . . . . . . . . . . . . . . . 1019.3.2.4. Generacion del Certificado . . . . . . . . . . . . . . . . . . . . . . 1029.3.2.5. Renovacion de certificado . . . . . . . . . . . . . . . . . . . . . . . 102

9.3.3. Deteccion de Vecinos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1039.3.3.1. Autenticacion de los vecinos . . . . . . . . . . . . . . . . . . . . . 1049.3.3.2. Eleccion de MPR . . . . . . . . . . . . . . . . . . . . . . . . . . . 106

9.3.4. Firma y encripcion de los mensajes . . . . . . . . . . . . . . . . . . . . . . . 1069.3.4.1. Obtencion de la Clave de Sesion . . . . . . . . . . . . . . . . . . . 1069.3.4.2. Firma de los mensajes . . . . . . . . . . . . . . . . . . . . . . . . . 1089.3.4.3. Protocolo de encriptacion . . . . . . . . . . . . . . . . . . . . . . . 109

9.3.5. Descubrimiento de la Topologıa . . . . . . . . . . . . . . . . . . . . . . . . . 1099.3.6. Armado de la tabla de Ruteo . . . . . . . . . . . . . . . . . . . . . . . . . . 110


INDICE GENERAL

9.3.7. Logros del Nivel 1 de securizacion . . . . . . . . . . . . . . . . . . . . . . . 1109.4. Fortalecimiento de OLSR: Nivel 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

9.4.1. Prevencion contra ataque Wormhole . . . . . . . . . . . . . . . . . . . . . . 1119.4.2. Prevencion contra ataque de reenvıo de mensajes: Timestamp . . . . . . . . 1129.4.3. Prevencion contra ataques de DoS . . . . . . . . . . . . . . . . . . . . . . . 1139.4.4. Otros ataques mitigados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1149.4.5. OLSR RFC 3226 vs. OLSR Seguro . . . . . . . . . . . . . . . . . . . . . . . 114

9.5. Fortalecimiento de OLSR: Nivel 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1159.5.1. Mecanismo de Denuncia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1159.5.2. Sistema de Deteccion de Intrusos . . . . . . . . . . . . . . . . . . . . . . . . 115

9.5.2.1. Interaccion con las CAs . . . . . . . . . . . . . . . . . . . . . . . . 1159.5.3. Sincronizacion de CRLs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115

9.6. Debilidades del Esquema de Seguridad propuesto . . . . . . . . . . . . . . . . . . . 1169.7. Resumen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116

10.Prueba de Contenido 11710.1. Arquitectura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118

10.1.1. Certificados y Keystores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11910.1.2. Configuracion del Nodo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11910.1.3. Plugin olsrd para generar el archivo de topologıa . . . . . . . . . . . . . . . 11910.1.4. Mensajes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11910.1.5. Modulo de Autoridad Certificante . . . . . . . . . . . . . . . . . . . . . . . 12010.1.6. Modulo de Autenticacion con los vecinos . . . . . . . . . . . . . . . . . . . . 12110.1.7. Modulo de Procesamiento de mensajes OLSR . . . . . . . . . . . . . . . . . 121

10.2. Implementacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12110.2.1. Descubrimiento de CAs y Vecinos . . . . . . . . . . . . . . . . . . . . . . . 121

10.2.1.1. Demonio de Procesamiento de mensajes OLSR . . . . . . . . . . . 12210.2.2. Autoridad Certificante . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122

10.2.2.1. Interaccion Nodo-CA . . . . . . . . . . . . . . . . . . . . . . . . . 12310.2.3. Autenticacion con los Vecinos . . . . . . . . . . . . . . . . . . . . . . . . . . 123

10.3. Modos de Operacion del Simulador . . . . . . . . . . . . . . . . . . . . . . . . . . . 12410.4. Resumen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125

11.Conclusiones 127


INDICE GENERAL


Indice de figuras

2.1. Clasificacion de protocolos de ruteo . . . . . . . . . . . . . . . . . . . . . . . . . . . 152.2. Multipoint Relays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.3. Ejemplo de la construccion de una ruta en AODV . . . . . . . . . . . . . . . . . . 222.4. Deteccion de un enlace roto y envıo del RERR . . . . . . . . . . . . . . . . . . . . 242.5. Ejemplo de la construccion de una ruta en DSR . . . . . . . . . . . . . . . . . . . . 252.6. Zona de un nodo usando ZRP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272.7. Descubrimiento de una ruta con IERP . . . . . . . . . . . . . . . . . . . . . . . . 27

3.1. Proceso de Generacion y Verificacion de una Firma Digital . . . . . . . . . . . . . 36

4.1. Formato del encabezado de un protocolo de ruteo con la extension de SRP . . . . . 474.2. Encabezado de SRP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 474.3. Encabezado SRP con extension INRT . . . . . . . . . . . . . . . . . . . . . . . . . 48

5.1. Diagrama de una red Movil Urbana . . . . . . . . . . . . . . . . . . . . . . . . . . 54

6.1. Etapas del protocolo OLSR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 616.2. Formato del paquete de OLSR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 626.3. Campo de 8 bits para indicar el codigo del enlace . . . . . . . . . . . . . . . . . . . 626.4. Formato del mensaje de HELLO . . . . . . . . . . . . . . . . . . . . . . . . . . . . 636.5. Formato del mensaje MID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 646.6. Censado y Descubrimiento de Vecinos - Parte 1 . . . . . . . . . . . . . . . . . . . . 656.7. Censado y Descubrimiento de Vecinos - Parte 1 . . . . . . . . . . . . . . . . . . . . 666.8. Multipoint Relays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 676.9. Fase 1 : Seleccion de MPRs que cubren nodos aislados del Nivel2. . . . . . . . . . . 686.10. Fase 2: Se completa la seleccion de MPRs. . . . . . . . . . . . . . . . . . . . . . . . 686.11. Formato del mensaje TC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 696.12. Formato del mensaje HNA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 726.13. Generacion incorrecta de mensajes HELLO . . . . . . . . . . . . . . . . . . . . . . 746.14. Generacion incorrecta de mensajes TC . . . . . . . . . . . . . . . . . . . . . . . . . 756.15. Ataque por tunel (Wormhole) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 766.16. Ataque al (MPR-Flooding) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

7

INDICE DE FIGURAS

7.1. Componentes participantes en el esquema de seguridad propuesto . . . . . . . . . 817.2. Esquema de Certificacion. CA de la comunidad expide certificados a los nodos

enrolados y estos expiden certificados a los clientes . . . . . . . . . . . . . . . . . . 827.3. Ejemplo de utilizacion de una red Movil Urbana Segura interconectando distintas

plazas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

8.1. Mensaje de firma basico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 888.2. Pasos para lograr una relacion de confianza con un vecino . . . . . . . . . . . . . . 918.3. Extension del paquete OLSR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 918.4. Formato del mensaje de firma . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

9.1. Formato del mensaje CADISCOVER . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1009.2. Formato del mensaje CERTREQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1019.3. Formato del mensaje CERTREPLY . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1019.4. Formato del mensaje CERTRENEW . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1039.5. Formato del mensaje AUTH MESSAGE . . . . . . . . . . . . . . . . . . . . . . . . . . 1049.6. Formato del mensaje AUTH MESSAGE FINISH . . . . . . . . . . . . . . . . . . . . . . 1059.7. Formato del mensaje AUTH MESSAGE FINISH . . . . . . . . . . . . . . . . . . . . . . 1079.8. Formato del mensaje AUTH MESSAGE FINISH . . . . . . . . . . . . . . . . . . . . . . 1079.9. Generacion de la firma . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1089.10. Formato del mensaje firma . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1099.11. Formato del paquete de OLSR firmado . . . . . . . . . . . . . . . . . . . . . . . . . 1109.12. Firma + Encripcion de un paquete . . . . . . . . . . . . . . . . . . . . . . . . . . . 1119.13. Formato del mensaje firma con timestamp . . . . . . . . . . . . . . . . . . . . . . . 1139.14. Etapas del protocolo OLSR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114

10.1. Principales modulos del simulador . . . . . . . . . . . . . . . . . . . . . . . . . . . 11810.2. Diagrama de Clases para los mensajes del protocolo . . . . . . . . . . . . . . . . . 12010.3. Diagrama de Secuencia para la firma de un CertReq . . . . . . . . . . . . . . . . . 12210.4. Diagrama de Secuencia de la obtencion de un certificado . . . . . . . . . . . . . . . 12310.5. Instanciacion de modulos dependiendo el modo de operacion . . . . . . . . . . . . . 124


INDICE DE FIGURAS

va


INDICE DE FIGURAS


Capıtulo 1

Introduccion

El mundo de las telecomunicaciones crece dıa a dıa poniendo en nuestras manos distintasalternativas de comunicacion. En estos ultimos tiempos el avance de la tecnologıa ha puesto adisposicion del usuario final tecnologıas tan potentes como una maquina de escritorio en dis-positivos de bolsillo. Estos dispositivos no son utiles o la mayorıa de sus utilidades no estandisponibles si no estan conectados a alguna red. La necesidad de interconectar estos dispositivoses la causante de que la industria de las comunicaciones crezca tanto.

Los dispositivos moviles seran pronto el metodo preferido de acceso a la informacion. Las co-municaciones de estos dispositivos se hacen de manera inalambrica, brindando mayor comodidadal usuario y pudiendo conectarse en cualquier lugar. Las conexiones inalambricas se hacen sobreWLAN (Wireless Local Area Network) bajo el estandar 802.11. Este estandar permite dos modosde operacion, uno es modo infraestructura y otro es modo ad-hoc. En modo infraestructura todoslos clientes de la red deben conectarse a un punto de acceso fijo. En modo ad-hoc la comunica-cion se hace directamente de dispositivo a dispositivo sin pasar por un punto de acceso fijo. Estapropiedad hace que las redes ad-hoc sean flexibles y rapidas de desarrollar.

A medida que la demanda de conexiones crezca, estas van a ser mas necesarias, incluso enlugares donde no exista una infraestructura para hacerlo. En este punto es donde entran en juegolas redes ad-hoc, las cuales brindan una manera agil para configurar una red autonoma.

Si bien la aplicacion de este tipo de redes esta pensada para un ambiente donde haya un grannumero de dispositivos, y hoy en dıa serıa difıcil pensar un uso, en poco tiempo mas podrıamosutilizar este tipo de redes por ejemplo para conectar todos los automoviles que circulan en unaautopista y en caso de haber un accidente todos los conductores se enterarıan y podrıan evitarcongestiones utilizando desvıos. Pensando en el futuro cuando todas las personas tengan undispositivo movil, el uso de estas redes quedara limitada a la imaginacion y la creatividad.

Como cualquier red inalambrica, las redes ad-hoc estan expuestas a ataques de cualquierpersona ya que el medio fısico de propagacion es el aire. Las redes en modo infraestructuracuentan con la ventaja de que todo el trafico pasa por un punto de acceso fijo en el cual sepueden aplicar diferentes tecnicas y procedimientos de seguridad. Por el contrario, en las redesad-hoc, los mismos protocolos son los encargados de garantizar la seguridad de la red.

11

1.1. Motivacion

1.1. Motivacion

Ya hace un tiempo que me he visto atraıdo por la tecnologıa WiFi, la cual pertenece alestandar 802.11. Luego de hacer distintas pruebas, armar diferentes antenas, probar diferentesdispositivos es que me vi interesado por las redes ad-hoc y en particular las redes ad-hoc dondelos participantes de la misma estuviesen en movimiento. Otro aspecto importante por el quesiento curiosidad es por la seguridad en las redes inalambricas. Por otro lado, no existe ningunestandar sobre este tipo de redes, lo cual hace que una investigacion y analisis de los borradoreselaborados hasta el momento pueda hacer un aporte para la construccion de los protocolos. Estasinquietudes 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 seguridaden una red movil urbana basada en el protocolo OLSR.

El protocolo OLSR se utiliza en el proyecto BAL (Buenos Aires Libre) y en proyectos de redesmoviles urbanas en todo el mundo por lo que la aplicacion de su estudio y analisis de securizaciontiene un uso potencial significativo.

En el desarrollo de la tesis se analizaran protocolos de ruteo de redes moviles, se realizarancomparaciones entre los mismos dando especial enfasis en los aspectos de seguridad con el objetivode tomar ideas para realizar el diseno de un protocolo OLSR seguro.

Se estudiara y detallara como funciona una red movil basada en OLSR, principales tecnicasde ataque y posibles alternativas de prevencion.

Del analisis de los protocolos de ruteo existentes, se propondra la manera de mejorar laseguridad de una red movil urbana, en particular para una topologıa similar a la de BAL.

Para lograr este objetivo se trabajara en un esquema de arquitectura de seguridad de acuerdoal uso de la red y al grado de participacion de los nodos en la misma.

La tesis tendra en mente lograr mejorar la capacidad del protocolo de obtener disponibilidad,integridad, confidencialidad, autenticacion y no repudio de sus paquetes de control.


Capıtulo 2

Redes Moviles

El objetivo del presente capıtulo es dar una introduccion a las Redes Movilesy presentar los principales protocolos de ruteo para dar un marco teorico al lectory conocer distintas alternativas para un mismo objetivo, rutear nodos en un Red Movil.

Dentro del mundo de las redes las configuraciones mas conocidas son:

Redes Fijas: son aquellas redes donde los componentes que la integran son fijos y estaninterconectados generalmente por cable.

Redes Inalambricas: en esta categorıa se encuentran las redes donde sus componentespodrıan estar en movimiento pero siempre conectados de manera inalambrica a un puntofijo o las redes ad-hoc, en las cuales los integrantes de la red se comunican entre sı medianteuna conexion inalambrica. Por ultimo y dentro de la categorıa de las redes inalambricas(ad-hoc) estan las Redes Moviles (MANETs, Mobile ad-hoc NETwoks). Este tipo de redeses el que analizaremos en detalle.

2.1. Generalidades

Las MANETs son redes donde los nodos o integrantes de la red se mueven. Por esta razon, losprotocolos de ruteo existentes para redes fijas no funcionan, ya que es necesario que la topologıade la red se vaya cambiando dinamicamente. En estas redes, el concepto de Servidor utilizadoen una red fija cambia ya que en estas siempre logramos conectarnos, en cambio en una red conestas caracterısticas no siempre se puede acceder a un nodo, con lo cual en una MANET podrıano haber DNSs o Entidades Certificantes (CAs), etc.

13

2.2. Protocolos de Ruteo

2.2. Protocolos de Ruteo

El ruteo en la redes moviles ha sido un desafıo, ya que la naturaleza de la red tiene muchasvariables (tamano, disposicion de los nodos, uso del ancho de banda, ahorro de energıa, etc) queson muy difıciles de ser contempladas por todos los protocolos.

Protocolos como los utilizados en redes fijas (Distance-Vector o Link-State) no se puedenutilizar en las redes moviles ya que la informacion de la distancia de los integrantes de la redvarıa con gran frecuencia. Esto insumirıa mucho ancho de banda y baterıa de los dispositivosmoviles para mantener esa informacion actualizada en cada nodo.

Para disenar un protocolo para redes ad-hoc se deberıa tener en cuenta las siguientes cuestiones[1, Chap. 10.1]:

Mınimo overhead de paquetes de control: Si se disminuye el numero de paquetes de control,se ahorra ancho de banda y baterıa en los dispositivos.

Mınimo tiempo de procesamiento: Los algoritmos elegidos tienen que ser simples, ası deesta manera no se insume tiempo de baterıas en procesamiento.

Capacidad de ruteo con multiples saltos: Como los dispositivos muchas veces no tienentransmision directa, se requiere que estos se puedan comunicar a traves de un tercero quesı esta en el rango de transmision directa.

Mantenimiento dinamico de la topologıa: Una vez que se tiene establecida una ruta es muycomun por la caracterıstica de la red que se pierda el vınculo, ya sea con el destino oentre algunos dispositivos que “ayudan” en el trayecto. Por lo tanto el protocolo tiene quesolucionar las perdidas de conexion con un overhead mınimo.

Prevencion de bucles: Se forma un bucle cuando se arma una ruta que elige como proximonodo uno que existe dentro de la ruta calculada hasta el momento. Los bucles hacen quelos datos y los paquetes de control pasen y sean procesados innecesariamente por un nodomuchas veces.

Modo de operacion inactivo: El protocolo debe estar preparado para que en perıodos dondela actividad de la red baje sea capaz de “dormirse” y de esta manera consumir menosenergıa.

Durante la evolucion de las MANETs se han desarrollado muchos protocolos teniendo encuenta las cuestiones listadas anteriormente. En las siguientes secciones ( 2.3.1, 2.3.2, 2.3.3) seva a desarrollar la presentacion de distintos protocolos, clasificados en distintos grupos segun suforma de generar las rutas. Luego se veran distintos protocolos que logran tener redundancia delas rutas para minimizar los tiempos de rearmado de la ruta en caso de la perdida de la misma( 2.3.4).


Redes Moviles

Figura 2.1: Clasificacion de protocolos de ruteo

2.3. Protocolos de Ruteo Proactivos, Reactivos e Hıbridos

Los protocolos de ruteo para Redes Moviles tiene sus bases sobre los protocolos de redes ca-bleadas. Como fue comentado anteriormente (2.2) estos protocolos necesitan intercambiar muchainformacion para mantener las rutas haciendo que sea imposible ser implementados en un am-biente tan cambiante y con enlaces tan poco estables como los de las Redes Moviles. Para superarlos problemas asociados a los algoritmos Link-State y Distance-Vector se han desarrollado unavariedad de protocolos los cuales se pueden clasificar como lo indica la Figura 2.1 [2]. En los pro-tocolos proactivos las rutas hacia todos los destinos de la red (o gran parte de ella) son calculadasal principio y luego se mantiene utilizando procesos de actualizacion periodicos. En los protocolosreactivos las rutas son calculadas en el momento que son requeridas utilizando un procedimientode descubrimiento hacia el destino. Los protocolos hıbridos combinan las propiedades basicas decada 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 mantienenla informacion acerca de como llegar a todos los destinos (nodos) de la red. Esta informacion esalmacenada en tablas las cuales son actualizadas periodicamente cuando hay modificaciones enla topologıa de la red.

La diferencia entre los distintos protocolos de esta clase es la manera en la que actualizan lastablas, la cantidad de tablas que utilizan, la informacion de cada tabla y la manera de encontrarla informacion. Los protocolos mas importantes en esta clase son:

Destination Sequenced Distance Vector (DSDV): Basado en el algoritmo Distance-Vector.

Optimized Link State Routing (OLSR): Basado en el algoritmo Link-State.

.


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 protocoloproactivo de Distance-Vector. Este protocolo esta basado en el clasico protocolo de Distance-Vector de Bellman-Ford (DBF) [4] modificado para prevenir lazos cerrados (loops). Este proto-colo sirve para encontrar a partir del algoritmo de Distance-Vector cual es el camino mas cortohasta llegar al destino [3, Sec. 3]. El DSDV por ser un algoritmo proactivo mantiene una tablacon todos los destinos posibles de la red y la cantidad de saltos para llegar a cada uno. Cadaentrada en esta tabla esta etiquetada con un numero de secuencia el cual es generado por el nododestino. La tabla contiene los siguientes datos:

Direccion IP destino

Nro de secuencia de destino

Direccion IP del proximo salto hacia el destino

Nro de saltos hasta el destino

Time stamp

Esta tabla debe ser mantenida periodicamente para actualizar los cambios que puedan suce-derse en la red. Estas actualizaciones se realizan a traves de mensajes broadcast o multicast. Losdatos enviados por cada nodo contienen su nuevo numero de secuencia y la informacion referentea cada nueva ruta. Cuando el destino recibe esa informacion actualiza sus propias tablas de ruteo.Las tablas de ruteo tambien son enviadas si se detecta algun cambio en la topologıa. Los nodosutilizan los numeros de secuencia de destino para poder distinguir entre rutas antiguas y rutasnuevas hacia un mismo destino. Un nodo incrementa su numero de secuencia cuando se produceun cambio a nivel local en la topologıa de sus vecinos. La ruta hacia el destino que tenga elnumero de secuencia mas grande (mas reciente) sera la elegida. En caso que existan dos rutascon el mismo destino y mismo numero de secuencia, sera elegida la que tenga menos saltos haciael destino. En la redes con gran cantidad de nodos se generarıan muchas colisiones en el traficobroadcast (storm of broadcast), para ello el protocolo utiliza dos tipos de paquetes para actualizarla informacion:

full dump: Transporta la informacion de todas las rutas.

incremental : Transporta solo la informacion de las rutas nuevas (variacion desde un fulldump)

Los paquetes incrementals, por razones de diseno deben entrar dentro de una unidad de datosde protocolo (NPDU-Network Protocol Data Unit). Cuando las actualizaciones de las rutas sonvarias y el tamano de dicha informacion se acerca al tamano de la NPDU, el proximo paquetesera un full dump. De esta manera se optimiza el envıo de paquetes. Sin embargo este protocolono podra escalar hacia grandes redes ya que requiere de un envıo de paquetes de O(N2), dondeN es el numero de nodos de la red. Se podrıa dar el caso que un nodo reciba informacion de ruteo


Redes Moviles

sobre un destino que es mejor que la que tiene por lo que, este informara a sus vecinos antes derecibir todos los mensajes de actualizacion de la ruta. Por esto es que DSDV tiene un mecanismopara mitigar este tipo de comportamiento que consiste en establecer un tiempo fijo para informarlos cambios. Este tiempo es calculado como el tiempo promedio que tarda en recibir el nodotodos los paquetes de actualizacion de una ruta. De esta manera el nodo se asegura de enviar lainformacion de la nueva ruta luego que recibio todos los paquetes de actualizacion y disminuyeel uso de ancho de banda y consumo de energıa de los vecinos.

2.3.1.2. Optimized Link State Routing (OLSR)

El protocolo Optimized Link State Routing (OLSR) [1, Sec. 10.2] es un protocolo de ruteoproactivo basado en el protocolo Link-State. La principal caracterıstica es que utiliza multipointrelays (MPRs) para minimizar el flooding 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 delos vecinos reciben los mensajes pero no los reenvıan. Solo los MPRs reenvıan los mensajes. Elnodo debe elegir a los MPRs, de manera tal de llegar a traves de estos a todos los vecinos queestan a dos saltos de distancia. En la Figura 6.8 se ve que el nodo O elige los nodos 1, 2, 4 y 5ya que a traves de ellos puede llegar a todos los vecino de dos saltos de distancia.

Figura 2.2: Multipoint Relays

Eleccion de los Multipoints Relays El mecanismo de seleccion de los MPRs [6, Sec. 4.2] serealiza mediante el intercambio de mensajes de HELLO. Un mensaje de HELLO es el mensajeque se utiliza en OLSR para validar el estado de los enlaces de un nodo con su vecino. Elmensaje contiene una lista de los nodos con los cuales se tiene un enlace bidireccional y unalista de direcciones de vecinos de los cuales se ha recibido un mensaje de HELLO. Un enlace esunidimensional cuando un nodo recibe un mensaje de HELLO, pero si en ese mensaje figura sudireccion en la lista de direcciones de vecinos hace que ese enlace sea bidireccional y lo almacenaen la tabla neighbor table.

El algoritmo de seleccion de los MPRs es:

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 seleccionael nodo que cubra el mayor numero de nodos de Nivel 2. Esto se repite hasta que todos losnodos de Nivel 2 hayan sido cubiertos.

El conjunto de MPRs son recalculados cada vez que hay algun cambio en los enlaces con losvecinos.

Calculo de la tabla de ruteo Cada nodo necesita armar su propia tabla de ruteo. Para ello,utiliza mensajes de control llamados Topology Control (TC). Estos mensajes son distribuıdospor la red utilizando broadcast. Cada MPR envıa mensajes TC informando cuales nodos lo hanelegido a el como MPR (informa su MPR Selector).

La informacion difundida por la red a traves de los TC ayudan a cada nodo a armar su tablade topologıa (topology table). Esta tabla existe en todos los nodos de la red y es utilizada paraestablecer las rutas. Cada entrada en la tabla de topologıa contiene la direccion de un potencialdestino, la direccion del ultimo salto a ese destino (origen del mensaje TC ) y el numero desecuencia correspondiente al nodo que envio el mensaje. Cada entrada en la tabla de topologıatiene un timestamp para verificar la validez de la misma.

Para el armado de la tabla de ruteo, el nodo utiliza tanto la tabla de vecinos como la tabla detopologıa, en esta ultima utiliza la direccion de ultimo salto para armar el recorrido comenzandopor el destino y luego recorrer la tabla en orden descendente para armar el camino. Por ejemplo sise quiere unir un punto remoto R, primero se busca el par (X,R), luego el par (Y,X) y ası hastacompletar la ruta. En el momento del armado de la ruta se controlan los numeros de secuenciapara detectar cambios en la topologıa y ası invalidar rutas. Como la tabla de ruteo depende dela tabla de vecinos y de la tabla de topologıa, cualquier cambio en alguna de ellas implica lareconstruccion de las rutas.

Cada entrada en la tabla de ruteo contiene la direccion del destino, la direccion del proximosalto y el numero de saltos.


Los protocolos de ruteo reactivos [1, Sec 10.3] son aquellos que construyen las rutas bajodemanda, es decir en el momento en el que un nodo origen necesita enviar un mensaje a un nododestino se crean las rutas desde el origen al destino. Con este tipo de protocolos se optimiza eluso de recursos de ancho de banda y el uso de baterıa pero por otro lado se penaliza la latenciaen encontrar la ruta.

Cuando un nodo quiere enviar un mensaje y la ruta hacia el destino no existe comienza elprocedimiento de descubrimiento con un mensaje de peticion de ruta (Route Request) de tipobroadcast y recibira un mensaje de respuesta con la ruta (Route Reply). Si el mensaje de peticionde ruta viajo por un links bidireccionales, el mensaje Route Reply puede utilizar la misma rutaentonces el overhead introducido por el descubrimiento (en el peor de los casos) crecera conO(N + M) [2] donde N es el la cantidad de nodos de la red y M es el numero de nodos en el


Redes Moviles

camino de vuelta con la respuesta. Cuando los enlaces son unidireccionales el overhead introducidoes de O(2N).

Los protocolos reactivos pueden clasificarse en dos categorıa:

Basados Ruteo del origen (source routing): En esta modalidad cada paquete de datos trans-porta en su cabecera la ruta completa desde el origen al destino, es decir, todas la direccionesde los nodos intermedios. Cada nodo intermedio utilizara la cabecera del mensaje para sa-ber donde reenviarlo, de esta manera no es necesario que cada nodo mantenga una tablacon las rutas como en los protocolos proactivos. Por otro lado este tipo de protocolos no esrecomendado para redes moviles grandes donde haya mucha movilidad de los nodos ya quees mas probable que los enlaces se rompan y al haber tanta cantidad de nodos las cabecerasde los mensajes van a ser muy grandes.

Basados en salto a salto (hop-by-hop): En esta modalidad cada paquete lleva la direcciondel destino y la del proximo salto, de forma tal que cada nodo intermedio debera consultarsu tabla de ruteo para saber donde va a reenviar el paquete.

La ventaja de esta estrategia es que las rutas se adaptan dinamicamente a medida quecambia la red. La desventaja es que cada nodo intermedio debe almacenar y mantener lainformacion de cada una de rutas mediante el intercambio de mensajes con sus vecinos.

Los protocolos mas importantes en esta clase son:

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 lasrutas a todos los destinos de la red sino que solo mantiene las rutas necesarias para alcanzar undestino en particular.

AODV presenta las siguientes caracterısticas:

Bajo overhead : Al no realizarse actualizaciones periodicas de la informacion de todos losnodos, 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 muchocalculo.

Previene la formacion de bucles: Provee un mecanismo para la prevencion de formacion debucles utilizando numeros de secuencia en los mensajes.

Tipo de mensajes de control que utiliza AODV:



RREQ (Route Request): Mensaje que se envıa cuando se necesita una ruta.

RREP (Route Reply): Mensaje de respuesta a la solicitud de una ruta.

RERR (Route Error): Este mensaje se envıa cada vez que se detecta una rotura de enlacey deja a un destino inaccesible.

Con el fin de prevenir bucles cada nodo mantiene un numero de secuencia que sirve paraevaluar la vigencia de la informacion asociada a cada mensaje que envıa el nodo. El numero desecuencia aumenta en uno cada vez que un nodo envıa un mensaje RREQ. Si un nodo recibeun RREQ donde el destino es el mismo, antes de generar el mensaje de respuesta RREP debeactualizar el numero de secuencia Sec#D al valor maximo entre su numero de secuencia actualSec#D actual y el numero de secuencia del destino que se encuentra contenido en el RREQ(RREQ.Sec#) mas uno.

Los numeros de secuencia sirven para que siempre se seleccione la ruta mas reciente hacia undestino. En el caso que un nodo intermedio tenga dos rutas hacia un destino y estas tengan unmismo numero de secuencia, escogera la que tenga la mınima cantidad de saltos.

Descubrimiento de la ruta El descubrimiento de la ruta [8, Sec. 2.1] (Path Discovery) seinicia cuando un nodo necesita comunicarse con otro y no existe una entrada en su tabla deruteo. Cada nodo mantiene dos contadores independientes: un numero de secuencia del nodo(node sequence number) y un identificador 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 emision de un mensaje

broadcast de tipo RREQ (route request) a sus vecinos (Figura 2.3(b))El par < direccion origen, broadcast id > identifica unıvocamente al mensaje RREQ. El

broadcast id se incrementa cada vez que el origen genera un nuevo mensaje RREQSi alguno de los vecinos tiene una ruta hacia el destino solicitado, contesta con un mensaje

RREP y en caso contrario reenvıa el mensaje RREQ a sus vecinos (Figura 2.3(c)) luego deincrementar la cantidad de saltos. Como un nodo puede recibir muchas veces el mismo mensajeRREQ, descarta aquellos donde la direccion de origen y el broadcast id son iguales a los dos deun mensaje recibido con anterioridad (Figura 2.3(d)).

Cada vez que el nodo no puede satisfacer la ruta solicitada, guarda la informacion para luegoimplementar el armado del camino reverso (reverse path)

La informacion almacenada en esta tabla tiene un tiempo de vida limitado, cuando se cumpleese tiempo la informacion es eliminada de la misma. La ruta inversa sirve para cuando el nodorecibe un mensaje RREP (Figura 2.3(e)), este es enviado hacia el origen a traves de esta rutainversa.

El mensaje RREP contiene la direccion IP del origen y el destino.Este paquete es enviado al nodo origen a traves del nodo del cual provino el RREQ (Figu-

ra 2.3(g)) ya que este nodo tiene una ruta de camino inversoCuando un nodo intermedio recibe un mensaje RREP incrementa el numero de saltos del

mensaje RREP, inserta una entrada en la tabla de ruteo (Figura 2.3(h)). La entrada en la tabla


Redes Moviles

utiliza al nodo origen del mensaje RREP como proximo salto hacia el destino. A este paso se lollama definir un Forward Path [9].

Si un nodo recibe mas de un mensaje RREP para un destino por parte de mas de un vecino,este reenvıa el primer RREP.

Cuando el nodo origen recibe un mensaje RREP ya puede comenzar a utilizar la ruta pa-ra enviar datos. En el caso que el nodo origen reciba mas de una ruta hacia el destino, esteutilizara aquella que tenga menor numero de saltos y el mayor numero de secuencia del destino.

De esto se puede observar que AODV no siempre calcula la menor ruta en cuanto a saltosya que el hecho de descartar los RREQ que lleguen luego de un RREQ que tienen igual campobradcast id y direccion IP del nodo origen hace que rutas probablemente mas cortas no se lleguena descubrir, pero entre las rutas calculadas se elige la mas corta.

Mantenimiento de la Ruta El movimiento de los nodos puede hacer que se rompan losenlaces y de esta manera hacer que la ruta no pueda ser utilizada.

AODV envıa periodicamente mensajes de hello (es un mensaje RREP especial ya que noes respuesta de un RREQ) para asegurarse que los enlaces simetricos esten utilizables. Estemensaje de hello contiene la direccion IP del nodo, su numero de secuencia (no cambia el numerode secuencia con el envıo de estos mensaje) y el tiempo de vida del enlace. Si se recibe un mensajede hello de un nuevo vecino o no se recibe un mensaje de un nodo que pertenecıa al vecindariose asume que hubo cambios entre los vecinos. Para garantizar que el enlace sea simetrico obidireccional envıa un RREP y luego espera un RREP-ACK, si no se recibe el RREP-ACK elnodo pone en su blacklist (lista negra) al nodo vecino e ignora los proximos RREQs debido a launidireccionalidad del enlace.

Cuando el nodo detecta la rotura de la ruta, la invalida y envıa un mensaje RERR. En estemensaje se envıa todos los destinos que ya no pueden ser alcanzados. En el caso que haya nodosintermedios entre el nodo origen y el nodo que detecto la ruptura y estos estaban utilizando elenlace, el mensaje RERR se propaga en modo broadcast sino unicast.

Cuando un nodo recibe un mensaje RERR, este verifica que el nodo del cual recibio sea elproximo salto hacia alguno de los destinos informados, luego marca la entrada en la tabla comoinvalida y reenvıa el mensaje RERR hacia el origen. Una vez que el origen recibe el mensajeRERR, puede decidir reiniciar un proceso de busqueda de una nueva ruta en caso que la necesite.

Una de las caracterısticas de AODV es que cuando detecta una rotura de enlace, el nodo noenvıa un RERR en ese momento sino que reintenta reconstruir el enlace generando un RREQprevio incremento del numero de secuencia. En el caso que no pueda restablecerlo envıa el RERRal origen.

Otra caracterıstica que se incorpora al protocolo en los ultimos draft de Internet [7] es queen cada mensaje de RREQ o RERR adicionan en la cabecera la ruta, de esta manera los nodosque reciben mensajes de este tipo aprenden rutas no solo hacia el origen o hacia el destino sinohacia otros nodos de la red.



(a) El origen 1 quiere enviar datos a 10 (b) El nodo 1 envıa un mensaje RREQ a susvecinos

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

(d) Se continua la propagacion. Notar que 3 noreenvıa el RREQ porque ya lo recibio antes

(e) Se continua la propagacion. 5 no propagaRREQ

(f) Se llega al nodo 10 y este no reenvıa elRREQ porque es el destino

(g) 10 determina la ruta para enviar RREP (h) En cada salto que hace RREP, se estableceuna ruta hacia el destino. Se completa la rutacuando llega a 1

Figura 2.3: Ejemplo de la construccion de una ruta en AODV


Redes Moviles

2.3.2.2. Dynamic Source Routing (DSR)

El protocolo Dynamic Source Routing (DSR) [10] es un protocolo simple y eficiente disenadoespecıficamente para redes inalambricas de multiples saltos donde los nodos de la misma estanen continuo movimiento. El protocolo esta compuesto por dos mecanismos principales de ”Des-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ıa overhead cuando esnecesario. No se utiliza mensajes de control (hello messages)

Multiples Rutas a un mismo destino y el nodo origen puede decidir y controlar el uso delas rutas.

Loop Free: garantiza de manera facil y poco costosa la generacion de lazos.

Enlaces unidireccionales: puede funcionar con enlaces unidimensionales.

Rapido Recupero: recupero rapido de la ruta ante un cambio en la red.

escalabilidad esta disenado para operar en redes de cientos de nodos y con gran movilidad

Si bien DSR es similar a AODV, sin embargo existe una diferencia muy grande y es que DSRes un protocolo basado en ruteo desde el origen (source routed) en vez de ser un protocolo desalto en salto (hop-by-hop) donde cada paquete de datos sabe exactamente por que nodos va apasar hasta llegar al destino.

Descubrimiento de la Ruta El mecanismo de descubrimiento de la ruta [11, Sec 3.2], haceuso de un cache donde se almacenan todas las rutas descubiertas para un destino. Cuando elnodo desea enviar un paquete a un nodo destino primero busca en el cache si existe alguna ruta yla utiliza, en caso de que la ruta falle, puede utilizar otra ruta del cache. De esta manera previeneel descubrimiento de una nueva ruta y acelera el proceso del envıo del paquete en caso de unafalla. El mecanismo de descubrimiento comienza cuando un nodo quiere enviar un paquete a undestino y no existe ninguna ruta en el cache. El nodo origen envıa un mensaje RREQ (RouteRequest) con la direccion del nodo origen (Figura 2.5(b)), la direccion del nodo destino y unidentificador de RREQ. Un mensaje RREQ adicionalmente contiene las direcciones de todos losnodos intermedios que han reenviado el mensaje. Cuando un nodo vecino recibe el mensaje RREQbusca en su cache si no tiene una ruta hacia el destino solicitado, en caso que ası sea envıa unmensaje RREP (Route Reply) que contiene una copia de la ruta al destino y le concatena la rutaacumulada que traıa el RREQ (Figura 2.5(c)). En caso que el mensaje lo reciba el nodo destino,este envıa un RREP con la ruta que se acumulo en el RREQ desde el origen hasta el destino.

Si el nodo que recibe el RREQ no es el destino y no tiene una ruta hacia el destino, verifica siya ha recibido un mensaje con el mismo origen, mismo destino y mismo identificador de RREQo bien si su direccion esta en el registro de ruta del mensaje RREQ. En este caso y con el fin delimitar el numero de mensajes RREQ que viajan por la red, este es descartado (Figura 2.5(d)).



Por lo tanto los RREQs que se propagan durante el descubrimiento son los primeros en llegar aun determinado nodo. Si se elige como ruta optima la ruta del primer RREP que llegue al origen,se puede asegurar que esa ruta es, en ese momento, la mas rapida para alcanzar al destino. Sino se cumplen ninguna de las condiciones, el mensaje es retransmitido pero el nodo agrega sudireccion al registro de ruta.

Cuando un nodo debe devolver un mensaje RREP hacia el origen, se fija en su cache sitiene una ruta hacia el origen, en caso que la tenga la utiliza, en caso contrario el nodo destinodebera comenzar su propio mecanismo de descubrimiento, pero para evitar una recursion infinitade busquedas de rutas, el nodo destino debera hacer piggyback (ponerlo al final) del mensajeRREP en su propio RREQ. En el caso que se utilicen enlaces simetricos, el nodo destino puedeutilizar la ruta recibida dentro del RREQ para hacer el camino inverso (Figura 2.5(e)). Para losescenarios donde se utilizan protocolos de MAC como por ejemplo IEEE 802.11 que requierenun intercambio bidireccional de tramas como parte del protocolo MAC garantizando enlacesbidireccionales, se utiliza la tecnica de enviar el RREP a traves de la ruta incluida en el RREQya que es lo mas adecuado para evitar el overhead de descubrir una nueva ruta. El protocoloMAC ademas prueba que la ruta sea bidireccional antes de comenzar a utilizarla. Como DSResta pensado para redes inalambricas y muchas veces el enlace unidireccional es la unica manerade conectividad, este protocolo tambien puede hacer descubrimiento de rutas en estas condiciones.

Cuando un nodo origen recibe un mensaje RREP, almacena la ruta contenida en el mensajeen su cache para comenzar a enviar datos (Figura 2.5(g)). De esta manera un nodo origen puederecibir multiples rutas (Figura 2.5(f)) , las cuales son almacenadas para prevenir un descubri-miento de ruta en caso que una deje de estar disponible. Una caracterıstica que destaca a DSR delos otros protocolos reactivos es que las rutas no tienen un tiempo de vida, son utilizadas hastaque se reciba un mensaje indicando que la ruta no esta disponible. Esto hace que si los nodospermaneces relativamente estaticos el overhead generado por el descubrimiento es cero.

Los nodo intermedios cada vez que reciben un mensaje RREQ o RREP pueden crear o ac-tualizar sus tablas con las rutas recibidas en los mensajes. Tambien se puede activar una opcionllamada promiscuous listening [1, Sec 10.3.2] que le da la posibilidad al nodo de escuchar tantolos paquetes de datos como los de control a nivel MAC y ası aprender rutas hacia otros nodos dela red.

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


Redes Moviles

(a) El origen 1 quiere enviar datos a 10 (b) El nodo 1 envıa un mensaje RREQ a susvecinos especificando en la ruta su direccion

(c) Los nodos 2, 3 y 4 reciben RREQ y los pro-pagan a sus vecinos concatenando su direccionen la ruta (a los efectos del ejemplo no se espe-cifica la ruta enviada por 2)

(d) Se continua la propagacion. Notar que 3 noreenvıa el RREQ porque ya lo recibio antes

(e) El RREQ llega al destino 10 y este no lo re-transmite y arma el RREP y lo envıa al destino.9 continua la propagacion del RREQ

(f) Llega el segundo RREQ al nodo 10, armaun nuevo RREP y lo envıa al origen

(g) 1 recibe los RREP y elije enviar los datospor la primer ruta que recibe

Figura 2.5: Ejemplo de la construccion de una ruta en DSR


2.3.3. Protocolos de Ruteo Hıbridos

Mantenimiento de la Ruta Cuando un nodo transmite o reenvıa un mensaje, este debeasegurarse que fue entregado al proximo salto [11, Sec 3.3] (se puede definir un numero maximode reintentos en el envıo del paquete). Esta confirmacion de recepcion muchas veces es gratuitapara DSR cuando utiliza por debajo un protocolo de MAC como el de IEEE 802.11 ya que elprotocolo MAC es el encargado se asegurarse el envıo con la trama link-level acknowledgement.Si este mecanismo no esta disponible, se configura un bit indicando a DSR que se necesita unaconfirmacion a nivel protocolo DSR. Es muy probable que si esta opcion esta especificada esporque no se este trabajando sobre un protocolo MAC como el especificado anteriormente o setengan enlaces unidireccionales, con lo cual la respuesta puede viajar a traves de otra ruta.

Si un paquete es reenviado un numero maximo de veces y no se recibe respuesta, el nodoretorna un mensaje de error llamado RERR indicando a traves de que enlace no se pudo enviarel paquete (Figura 2.4). Cuando el nodo origen recibe este mensaje marca la ruta como invalidae intenta utilizar otra de las rutas de su cache, en caso de no tener ninguna inicia un nuevomecanismo de descubrimiento.

2.3.3. Protocolos de Ruteo Hıbridos

Las caracterısticas de los protocolos de ruteo reactivos y proactivos pueden combinarse devarias maneras y dan lugar a los protocolos de ruteo hıbridos. Un protocolo hıbrido utiliza ca-racterısticas de los protocolos reactivos y proactivos dependiendo las circunstancias. Uno de losprincipales 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 alcancede un protocolo proactivo para los nodos de su vecindad. Por otro lado utiliza el mecanismo dedescubrimiento de ruta de un protocolo reactivo para buscar nodos mas alla de su vecindario. Elprotocolo identifica diferentes rutas sin caer en un bucle capaces de alcanzar un destino, de estamanera hace que sea mas confiable y performante.

Cada nodo define un radio que es medido en cantidad saltos. Cada nodo utiliza un protocoloproactivo en su zona y uno reactivo fuera de ella. De esta manera un nodo conoce a todos susvecinos de sus zona y todas las rutas hacia ellos. Cuando un nodo quiere enviar un paquete dedatos primero busca en su tabla de rutas una ruta hacia el destino, si el destino pertenece a suzona la ruta la tiene. Si el destino no esta en su zona, comienza a buscar una ruta hacia el destino.

ZRP utiliza un protocolo para ruteo dentro de la zona, este protocolo se llama Intra ZoneRouting Protocol (IARP) [1, Sec 10.5.1]. IARP es un protocolo basado en el protocolo Link-Stateque mantiene actualizada la informacion de todos los nodos dentro de la zona. En la Figura 2.6se puede ver un ejemplo la definicion de una zona de un salto para el nodo O y como es una zonade un salto de distancia quedan definidos automaticamente los nodos frontera o perifericos (A, B,C). ZRP utiliza para el ruteo de paquetes fuera de la una zona un protocolo llamado InterzoneRouting Protocol (IERP). Este protocolo incorpora el termino bordercasting. Cuando un nododetermina que el nodo al que le quiere enviar un paquete esta fuera de su zona, el nodo origen


Redes Moviles

Figura 2.6: Zona de un nodo usando ZRP

hace un bordercast del pedido de ruta. El termino bordercast no es mas que enviar un mensajedirectamente al nodo frontera para que este luego haga el descubrimiento de la ruta.

El nodo frontera cuando recibe un mensaje de solicitud de ruta, verifica si el destino esta ensu zona, en caso que no este reenvıa el pedido a cada uno (uno por vez) de sus nodos frontera.Este procedimiento continua hasta que se localice el destino o hasta que se examina toda la red.Cuando un nodo encuentra al destino, este envıa un mensaje unicast hacia el origen.

Figura 2.7: Descubrimiento de una ruta con IERP

En la Figura 2.7 se ilustra un pedido de ruta utilizando IERP. En la figura, el nodo O haceuna busqueda de la direccion del nodo E. Utilizando IARP, se sabe que no esta dentro de su zona,por lo tanto hace un bordercast del requerimiento a los nodos perifericos. Los nodos perifericos,uno por vez, chequean su zona en busca de la direccion solicitada (los circulo solidos representanlas zonas hacia donde se envio el requerimiento). En caso que no este en su zona, reenvıa el pedidoa sus nodos perifericos. En la figura, cuando le llega el pedido al nodo D, este encuentra en suzona al nodo E y envıa una mensaje unicast hacia el nodo O con la respuesta.

ZRP tiene varios parametros y tecnicas para mejorar su performance y para prevenir lapropagacion de una busqueda cuando esta ya ha sido contestada por algun nodo. ZRP incorporo esu version 2 (ZRPv2) una manera diferente a las hora de hacer bordercasting. ZRPv2 hace que elnodo origen construya un arbol hacia los destinos que no pertenecen a su zona. En ese arbol y comoprimer hijo se encuentran los nodos perifericos. Cuando un nodo periferico recibe una consulta,


2.3.4. Tecnicas de Ruteo

primero construye su propio arbol. Este procedimiento se repite hasta alcanzar el destino.

2.3.4. Tecnicas de Ruteo

Todos los protocolos antes descriptos, en su mayorıa, fueron concebidos para lograr manteneruna ruta hacia el destino. En muchos escenarios donde la red es mediana a grande y dondelos nodos pueden tener mucha movilidad, estas rutas podrıan sufrir modificaciones contınuasy llevarıa a los nodos a estar continuamente ejecutando procedimientos de descubrimiento deruta. Para subsanar esta situacion existen variaciones de los protocolos originales que proveenredundancia de rutas. A estos protocololos se los conoce como Ruteo Multicamino (MultipathRouting).

2.3.4.1. Multipath Routing

En la mayorıa de los protocolos vistos en este capıtulo, los nodos registran las rutas hacia losdistintos destinos en tablas de ruteo, en casi todos los casos cada entrada de la tabla tiene unasola direccion como proximo salto para continuar el camino hacia el destino. La idea principal delos protocolos multi path es almacenar en un cache diferentes rutas hacia un mismo destino, y deesta manera no tener que recalcular o descubrir una ruta ante una eventual ruptura de enlace.

Existen varios protocolos que utilizan esta tecnica y son adaptaciones de los protocolos antesvistos para soportar multiples caminos hacia el destino. Como se vio antes DSR, en forma nativa,es decir sin ninguna adaptacion, soporta cache de rutas. Entre los protocolos adaptados parautilizar cache son: Ad Hoc On-Demand Multipath Distance Vector Routing (AOMDV), Ad HocOn-Demand Distance Vector Routing - Backup Routing (AODV-BR), Split Multipath Routing(SMR)

Ad Hoc On-Demand Multipath Distance Vector Routing (AOMDV) utiliza uncache con varias rutas para un mismo destino con un unico tiempo de vida para todas las rutas,es decir, cuando se vence una ruta se vencen todas las rutas almacenada para ese destino. El valoragregado que da AOMDV es que las rutas no utilizan un mismo enlace, es decir, todas las rutasdesde el origen al destino no repiten un enlace entre nodos (cada ruta son conjuntos dijuntos deenlaces)

Ad Hoc On-Demand Distance Vector Routing - Backup Routing (AODV-BR) pro-pone el uso de rutas de backup como alternativa ante una ruptura de enlace. Cuando ocurre unaruptura el nodo mas cercano al origen envıa un paquete de error hacia este y a la vez lo envıaen forma broadcast a todos los vecinos. El paquete, en la cabecera de datos, indica que el link seha roto y que el paquete necesita una ruta alternativa. Cuando los nodos del vecindario recibeneste mensaje, lo reenvıan hacia el destino si es que ellos tienen una ruta hacia el mismo.

Split Multipath Routing (SMR) [14] es un protocolo bajo demanda que arma las rutas demanera disjuntas. Utiliza dos rutas para cada sesion; una es la que tiene la menor latencia y otraque es la mas disjunta con esta, es decir la que menos enlaces en comun tenga. De esta manera


Redes Moviles

SMR provee rutas alternativas y por ser disjuntas se minimiza el riesgo de rotura de una rutapor tener la mınima cantidad de enlaces comunes.

SMR tiene dos esquemas de mantenimiento de las rutas. El primero crea un nuevo par derutas si una de las dos rutas se rompe y el segundo hace una reconstruccion de las rutas solocuando ambas rutas se hayan roto.

2.4. Resumen

A lo largo del Capıtulo se vieron los diferentes tipos de algoritmos disponibles para redesmoviles. Como se vio hay dos categorıas principales, los proactivos o basados en tablas y losreactivos o bajo demanda. Cada uno de ellos tiene sus ventajas y desventajas.

Los proactivos tienen un alto overhead de control y de actualizacion de rutas pero una mınimalatencia. Los reactivos tienen un mınimo overhead pero mayor latencia.

Llegada la discusion de cual tipo de algoritmo es mejor, habrıa que ver cual es la finalidadde la red, que servicios se van a montar sobre esta, que cantidad de nodos y que velocidad o conque frecuencia podrıa cambiar la topologıa.

Dentro de los protocolos proactivos se desarrollaron DSDV y OLSR. DSDV tiene un altooverhead de paquetes de control pero tiene deteccion de bucles. OLSR tiene menos overhead,tiene deteccion de bucles pero requiere conocer los vecinos que estan a dos saltos de distancia.

Dentro de los protocolos reactivos se trataron AODV y DSR. Ambos protocolos tienen enmismo tiempo de convergencias y la misma complejidad de comunicaciones. La diferencia radicaen la manera de formar las rutas. DSR tiene como ventaja que utiliza un cache de rutas con locual minimiza la latencia en caso de perder una. AODV tiene como virtud que se adapta rapi-damente a redes con nodos de mucha movilidad. Ambos protocolos tiene como contra problemasde escalabilidad en redes con muchos nodos.

Como una alternativa a estos dos tipos de algoritmos, se analizaron protocolos hıbridos loscuales usan un protocolo proactivo dentro de un vecindario y protocolos reactivos para llegara nodos fuera del vecindario. Estos protocolos son optimos para topologıas donde los nodos semueven pero siempre dentro de un mismo ambito.


2.4. Resumen


Capıtulo 3

Seguridad Informatica

En este capıtulo se hara una revision de los principales conceptos de la seguridad informati-ca [35, Sec. 2.1].

Cuando se habla de seguridad en redes de computadoras, hay tres objetivos o premisas basicasque se deben cumplir.

Confidencialidad: Se garantiza que la informacion sea accesible solo a aquellas personas quetienen acceso a la misma.

Integridad: Se salvaguarda la exactitud y totalidad de la informacion y los metodos deprocesamiento.

No Repudio: Se refiere a evitar que una entidad que haya enviado o recibido informacionalegue ante terceros que no la envio o no la recibio.

Existen otros objetivos mas difıciles de lograr pero que hacen a la seguridad de la informacion

Autenticacion: Garantizar el origen y el destino de la informacion, validando al emisor y alreceptor para evitar suplantacion de identidades.

Control de Acceso: Solo las partes autorizadas pueden participar en la comunicacion.

Disponibilidad de Servicio: Garantiza que todos los componentes de la red esten disponiblespara ser utilizado por las partes autorizadas.

La mayorıa de estos conceptos se garantizan por medio del uso de la criptografıa y algoritmoscriptograficos.

3.1. Conceptos Basicos de Criptografıa

Es preciso introducir conceptos basicos de criptografıa con el fin de que el lector se familiaricecon el lenguaje y adquiera los conceptos necesarios que luego seran aplicados en otros capıtulosde esta tesis.

31

3.1.1. Cifrados Simetricos

Por medio de la criptografıa se ha podido garantizar las premisas de la seguridad para redesde datos. A continuacion se presentan conceptos basicos e introductorios.

3.1.1. Cifrados Simetricos

Los algoritmos de cifrado simetricos utilizan la misma clave para cifrar y para descifrar men-sajes. Las dos partes que se comunican deben ponerse de acuerdo de antemano sobre la clave autilizar. Una vez que ambas tienen acceso a esta clave, el remitente cifra un mensaje usandola,lo envıa al destinatario, y este lo descifra con la misma.

3.1.1.1. Seguridad

La seguridad de este tipo de cifrados se encuentra en la clave y no en el algorimo. En otras pa-labras, no deberıa ser de ninguna ayuda para un atacante conocer el algoritmo que se esta usando.Solo si el atacante obtuviera la clave, le servirıa conocer el algoritmo.

3.1.1.2. Ventajas y Desventajas

El principal problema con los sistemas de cifrado simetrico no esta ligado a la seguridadintrınseca de los algoritmos, sino a la forma en la que se intercambian las claves. Una vez quelas partes hayan intercambiado las claves pueden usarlas para comunicarse con seguridad, perose debe asegurar que dicho intercambio se haya realizado de forma “segura”. Por ejemplo si fueun acuerdo verbal que nadie escucho la conversacion; Si fue por correo, asegurarse que nadieintercepto el sobre. Para un atacante es mas facil tratar de interceptar la clave en el momento deintercambio que probar el espacio posible de claves.

Otro problema es el numero de claves que se necesitan. Si tenemos un numero n de personasque necesitan comunicarse entre ellos, entonces se necesitan n(n − 1)/2 claves para cada parejade personas que tengan que comunicarse de modo privado. Esto puede funcionar con un gruporeducido de personas, pero serıa imposible llevarlo a cabo con grupos mas grandes.

La principal ventaja de estos cifradores es que son muy rapidos e implementables facilmentepor hardware.

3.1.1.3. Algoritmos

DES DES fue el algoritmo de cifrado por bloques mas usado, como todo cifrador simetricotoma un texto de una longitud fija de bits y lo transforma mediante una serie de operacionesen un texto cifrado de la misma longitud. Para el DES el tamano del bloque es de 64 bits y laclave es de 64 bits, de los cuales solo 56 de son empleados por el algoritmo ya que los ocho bitsrestantes son de paridad. El Algoritmo DES estaba estadarizado por la “FIPS PUB 46-2” 1 y fuereemplazado por el AES

1http://www.itl.nist.gov/fipspubs/fip46-2.htm



3DES El algoritmo 3DES consta de tres rondas de DES. Incrementa el tamano de la clave porun factor de 3 hasta 168 bits. Basicamente se usan tres claves de DES. El 3DES tiene hoy en dıaun nivel de seguridad aceptable y es utilizado por muchos dispositivos. Tiene el inconvenienteque es lento en comparacion con el AES.

AES AES [31, Cap. 5] es un esquema de cifrado por bloques,tiene un tamano de bloque fijo de128 bits y tamanos de clave de 128, 192 o 256 bits. La mayorıa de los calculos del algoritmo AESse hacen en un campo finito 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 Asimetricos

Los cifradores asimetricos tienen la particularidad de contar con un par de claves, donde unaclave es publica y se puede entregar a cualquier persona y la otra clave es privada y el propietariodebe guardarla de modo que nadie tenga acceso a ella. El remitente usa la clave publica deldestinatario para cifrar el mensaje, y una vez cifrado, solo la clave privada del destinatariopodra descifrar este mensaje.

Los criptosistemas asimetricos utilizan las denominadas funciones-trampa o de un solo sentido.Estas funciones de un solo sentido son aquellas cuya calculo es facil, mientras que su inversa no essimple. Por ejemplo, multiplicar dos numeros primos grandes es una operacion simple de realizar,pero factorizar el numero resultante en sus componentes primos es una operacion cuyo tiempode calculo puede llevar mucho tiempo al punto que para numeros de muchos bits puede llegar aser computacionalmente imposible es decir puede llevar anos de calculo. Con lo cual serıa en vanointentarlo.

Se trata de lograr que la generacion de las claves utilice la funcion trampa. Es decir generarla clave sea simple, pero romperla sea equivalente a obtener la inversa de la funcion-trampa.

Por ejemplo, dado un cifrado de clave publica basado en factorizacion de numeros primos, laclave publica contiene un numero compuesto de dos factores primos grandes, y el algoritmo decifrado usa ese compuesto para cifrar el mensaje. El algoritmo para descifrar el mensaje requiereel conocimiento de los factores primos para que el descifrado sea facil. Si poseemos la clave privadaque contiene uno de los factores sera facil su decodificacion, pero extremadamente difıcil en casocontrario.

3.1.2.1. Seguridad

Al igual que con los sistemas de cifrado simetricos, un buen sistema de cifrado de clave publicano debe basarse en esconder el algoritmo, este debe ser publico y la seguridad debe estar centradaen esconder la clave.

El tamano de la clave es una medida de la seguridad del sistema. Tener en cuenta que no sepuede comparar el tamano de claves de un asimetrico con el de un simetrico.

2http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf


3.1.3. Resumen Criptografico

En un ataque de fuerza bruta sobre un cifrado simetrico con una clave de un tamano de 80bits, el atacante debe probar hasta 281−1 claves para encontrar la clave correcta.

El esfuerzo para romper un cifrado es diferente segun el algoritmo utilizado. Mientras 128 bitsson suficientes para algoritmos con clave simetrica, los algoritmos de clase asimetrica necesitanclaves de por lo menos 1024 bits ya que la capacidad de calculo actual y los algoritmos conocidosde factorizacion impiden usar una clave menor.

3.1.2.2. Ventajas y Desventajas

La mayor ventaja de la criptografıa asimetrica es que se puede cifrar con una clave y descifrarcon la otra. Esto permite conseguir autenticacion de una manera muy simple. Si se obtiene untexto cifrado con la clave privada de alguien el unico que lo pudo generar es el dueno de la clavey todos podemos verificar 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 tamano que las simetricas.

Para textos pequenos, el mensaje cifrado ocupa mas espacio que el original.

3.1.2.3. Algoritmos

Existen varios algoritmos que utilizan el esquema de clave publica y clave privada, todos ellosutilizan la misma base, complejidad matematica en la factorizacion de numeros primos.

Diffie-Helman Diffie-Hellman (debido a Whitfield Diffie y Martin Hellman) permite generarclaves en conjunto entre las partes que participan en la comunicacion. Este algoritmo debe serutilizado sobre un canal de comunicacion autenticado.

RSA El sistema criptografico con clave publica RSA es un algoritmo asimetrico que utilizauna clave publica, la cual se distribuye, y otra privada, la cual es guardada en secreto por supropietario. La longitud de la clave puede variar, hoy en dıa se estan utilizando 1024 o 2048 bits.

3.1.3. Resumen Criptografico

3.1.3.1. Hash

Una funcion de Hash es una funcion que tiene por finalidad obtener una cadena de longitudfija 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 funcion sobre un texto se le llamahash o resumen criptografico. Los algoritmos de hash y las funciones son publicas y no necesitanclaves.

El objetivo principal del hash es detectar cambios en el mensaje para verificar su integridad.Una funcion puede ser usada como funcion de hash si cumple con las caracterısticas:



Es facil obtener el hash dado el mensaje.

Unidireccionalidad: conocido un resumen hash(M), debe ser computacionalmente imposibleencontrar un Mensaje que se corresponda con el resumen.

Otra propiedad de las funciones de hash es que una mınima modificacion al mensaje provocaun gran cambio en el resultado de la funcion. Esta propiedad se llama difusion y confusion [31,Cap. 12].

El hash por si solo no es util. Es un auxiliar que se utiliza en conjunto con otras primitivascriptograficas. Mas adelante se mostrara como en conjunto con un algoritmo asimetrico permiteconstruir la firma digital.

Algoritmos Los algoritmos mas populares son md5 y sha-1. La salida de md5 es de 128 bits,mientras que la de sha-1 es de 192 bits.

3.1.3.2. MAC

Message Authentication Code (MAC) es el resultado (codigo) de aplicar una funcion querecibe como parametros un texto y una clave secreta compartida entre las partes. Aplicando estafuncion se esta autenticando el mensaje. Adicionalmente, el MAC al igual que los algoritmos dehash, tambien previenen la manipulacion de los mensajes protegiendo la integridad de los mismos.

Los algoritmos de MAC no son reversibles, es decir, a partir de un codigo MAC es imposiblehallar un mensaje que se corresponda. EL objetivo del mismo no es ocultar la informacion sinoprotegerla y autenticar al origen.

Actualmente, dos de los mas grandes grupos de funciones MAC segun su modo de operacion:

CBC-MAC: La idea detras de este algoritmo es la de convertir un algoritmo de cifradosimetrico en una funcion MAC. El funcionamiento basico consiste en cifrar el mensajeusando un algoritmo en modo CBC y tirar todo el resultado de texto cifrado a excepciondel ultimo bloque.

HMAC: Dado que una funcion MAC es un mapeo aleatorio, y que las funciones hash se com-portan como tales, podemos explotar la idea de utilizar una funcion hash para implementaruna funcion MAC. La opcion mas popular hoy en dıa es la de usar HMAC-SHA-256.

3.1.4. Firma Digital

La firma digital es una manera de garantizar la autorıa y la integridad de un documentodigital (texto, correo, aplicaciones, etc). Al igual que una firma olografa, la firma digital es usadapara manifestar un acuerdo/desacuerdo, indicar que se ha leıdo un documento digital.

El mecanismo de firmado de un documento digital (Figura 3.1) se realiza aplicando unafuncion de hash al mismo y luego encriptandola con la clave privada del autor generando ası lafirma. El documento firmado consta de dos partes, el documento en sı y la firma. Los lectoresdel mismo, aplican la funcion de hash al documento y desencriptan la firma con la clave publica


3.1.5. PKI

del emisor. Compara el hash calculado con el desencriptado de la firma y si estos coinciden, segarantiza que el documento no fue modificado y fue emitido por el autor. Tambien se garantizaque el autor no puede negar su autorıa ya que es el el unico que pudo encriptar el hash con suclave privada

Figura 3.1: Proceso de Generacion y Verificacion de una Firma Digital

Resumiendo la firma digital garantiza integridad y no repudio.

3.1.5. PKI

Una infraestructura de clave publica (PKI, Public Key Infrastructure) son los elementos ne-cesarios (hardware, software, polıticas y procedimientos) para garantizar la identidad, cifradoasimetrico y firmas digitales [31, Cap. 13] en operaciones electronicas.

3.1.5.1. Proposito y funcionalidad

La tecnologıa PKI provee como servicio a los usuarios la posibilidad de autenticarse uno conotros por medio de certificados expedido por una entidad de confianza para ambos. Esto a lavez permite distribuir informacion (por ejemplo claves publicas) necesaria para los protocolos decomunicacion seguros, algoritmos de firma digital, cifrados y todas otras operaciones que requieranconocer la identidad y garantizar el no repudio de la otra parte de la operacion electronica.

En una operacion electronica que use los servicios brindados por PKI, tiene como participantesal menos tres partes:

Un usuario que desea realizar una operacion

Una entidad que da fe de la ocurrencia de la operacion y garantizan la validez de loscertificados de las partes.

Un usuario destinatario de los datos cifrados/firmados/enviados garantizados por parte delusuario que inicio de la operacion.



La seguridad de la tecnologıa PKI se centra en la privacidad de la clave privada (ya queesta infraestructura utiliza los mismos principios que los algoritmos de clave publica) y en losprocedimientos o polıticas de seguridad aplicadas a la gestion de los certificados.

Es de vital importancia ser rigurosos a la hora de establecer las polıticas de seguridad yaque dejar expuesta una clave privada invalida cualquier tecnologıa aplicada en el sistema o laseguridad del cifrador mas fuerte.

3.1.5.2. Usos de la tecnologıa PKI

La tecnologıa PKI, es utilizada para realizar autenticacion de personas, servidores, sistemas,etc; realizar firmado digital de documentos, software, correo, etc; Garantizar el no repudio; Cifradode datos y aseguramiento de canales de comunicaciones inseguros.

Basicamente el uso de esta tecnologıa se centra cuando es necesario autenticar a las partespara realizar una transaccion digital “segura”.

3.1.5.3. Certificados

Como se dijo anteriormente, la tecnologıa PKI se basa en Certificados Digitales expedidos poruna entidad de en la cual confıan ambas partes. Existes distintos tipos de certificados digitalesque varıan dependiendo el destino del mismo.

Certificado personal: Acredita la identidad del titular.

Certificado de pertenencia a una entidad: Ademas de la identidad del titular acredita suvinculacion con la entidad de la cual es miembro

Certificado de representante: Ademas de la pertenencia a la entidad acredita tambien lospoderes de representacion que el titular tiene sobre la misma.

Certificado de persona jurıdica: Identifica una entidad como tal a la hora de realizar tramitesante las administraciones o instituciones.

Certificado de atributo: Permite identificar una cualidad, estado o situacion. Este tipo decertificado va asociado al certificado personal. (p.ej. Medico, Director, Casado, etc.).

Los tipos de certificados antes mencionados son relacionados con un individuo o persona,tambien existen certificados digitales para fines mas especıficos y tecnicos como pueden ser:Ademas, existen otros tipos de certificado digital con fines mas tecnicos:

Certificado de servidor: Permiten asegurar al usuario del mismo que la conexion la estanrealizando a donde ellos quieren.

Certificado de firma: Garantiza la autorıa y la no modificacion de aplicaciones, documentos,etc.


3.1.6. Componentes

3.1.6. Componentes

Los componentes mas habituales de una infraestructura de clave publica son:

La autoridad de certificacion (CA, Certificate Authority): es la encargada de emitir y revocarcertificados. Es la entidad de confianza que da legitimidad a la relacion de una clave publicacon la identidad de un usuario o servicio.

La autoridad de registro (RA, Registration Authority): es la responsable de verificar el enlaceentre los certificados (concretamente, entre la clave publica del certificado) y la identidadde sus titulares.

Los repositorios: son las estructuras encargadas de almacenar la informacion relativa a laPKI. Los dos repositorios mas importantes son el repositorio de certificados y el repositoriode listas de revocacion de certificados. En una lista de revocacion de certificados (CRL,Certificate Revocation List) se incluyen todos aquellos certificados que por algun motivohan dejado de ser validos antes de la fecha establecida dentro del mismo.

La autoridad de validacion (VA, Validation Authority): es la encargada de comprobar lavalidez de los certificados digitales.

La autoridad de sellado de tiempo (TSA, TimeStamp Authority): es la encargada de firmardocumentos con la finalidad de probar que existıan antes de un determinado instante detiempo.

Los usuarios y entidades finales son aquellos que poseen un par de claves (publica y priva-da) y un certificado asociado a su clave publica. Utilizan un conjunto de aplicaciones quehacen uso de la tecnologıa PKI (para validar firmar digitales, cifrar documentos para otrosusuarios, etc.)

3.1.6.1. Consideraciones sobre PKI

Los Certificados Digitales deben ser emitidos por una Autoridad Certificante reconocida porlas partes para garantizar la validez del mismo. Ambas partes de la transaccion electronica debeconfiar en la Autoridad que emitio el certificado.

No es responsabilidad de la CA la conservacion del certificado y evitar que sea usado de formaindebida. Tampoco es responsabilidad de la CA la custodia de la clave privada correspondienteal mismo.

La infraestructura PKI es considerada segura por si sola si se aplican bien la polıticas deseguridad y no es necesario realizar ningun tipo de intercambio de clave para realizar una comu-nicacion segura.

3.2. Resumen

En este capıtulo se hizo una revision de los conceptos principales de seguridad informaticay de los conceptos basicos de criptografıa. Poniendo todo junto y considerando solo algunas



alternativas, podemos resumir que para garantizar los pilares de la seguridad, la criptografıa nosda las siguientes herramientas:

Confidencialidad: Algoritmos simetricos y asimetricos

Integridad: Funciones de Hash y MAC

No Repudio: Funciones de Hash o MAC encriptadas con un esquema PKI

Estos conceptos se van a ir afianzando a medida que se avance en la lectura de la presentetesis al ver la aplicacion de cada uno.


3.2. Resumen


Capıtulo 4

Seguridad en Redes Moviles

El objetivo del presente capıtulo es exponer distintos tipos de ataques a los queesta expuesta una red Movil y cuales son algunos de los protocolos de ruteo queexisten para hacer que este tipo de redes sean confiables. El estudio de estos protocolosson necesarios para el objetivo de esta tesis. Por ello es que de cada uno de ellos seresaltara que aspecto puede ser utilizado en esta tesis.

Como se vio en la Seccion 2.1 las redes moviles son una coleccion de dispositivos movilesformando momentaneamente una red sin la ayuda de una infraestructura. Estos dispositivosutilizan el aire como medio fısico de comunicacion, compartiendo con muchos otros el mismocanal de transmision. Los nodos participantes de una red movil estan mucho mas expuestos a unataque que una computadora dentro de una red cableada ya que cualquier intruso no tiene masque ponerse a escuchar el aire y puede comenzar su ataque.

Otra caracterıstica de este tipo de redes es que su topologıa en muy cambiante y dificultatener un control de los miembros de la red.

La naturaleza de las redes moviles hace que carezcan de un control de seguridad centralizado.Por esto es que el responsable de la seguridad de la red es el protocolo que se utilice paracomunicarse.

Para hacer de una red movil una red segura, hay que tener en cuenta los Servicios de Seguridaddescriptos en el Capıtulo 3 extendidos a Redes Moviles [15]:

Disponibilidad: garantiza la supervivencia de la red ante la hostigacion de nodos agresores.

Confidencialidad: garantiza que todo el trafico que circula por la red (paquetes de controly paquetes de datos) solo pueden ser leıdos por los nodos autorizados a verlo y por ningunotro nodo.

Integridad: garantiza que la informacion que viaja por la red no ha sido modificada duranteel trayecto del origen al destino.

41

4.1. Ataques

Autenticacion: garantiza a un nodo la identidad de otro nodo participante de la red.

No Repudio: grantiza que el nodo que envio el mensaje no puede negar que lo hizo.

4.1. Ataques

Los ataques en una red movil se pueden clasificar de dos maneras: por su origen o por el gradode participacion del nodo atacante.

La clasificacion por origen del atacante puede ser:

Ataque Externo: El nodo enemigo no es un nodo integrante de la red

Ataque Interno: El nodo enemigo es parte de la red

La clasificacion por el grado de participacion del nodo atacante puede ser:

Activo: Se considera activo cuando un nodo emite senal o datos con el objetivo de danar lared.

Pasivo: Se considera pasivo cuando el nodo no coopera y simplemente escuchan. A los nodospasivos se los llama egoıstas (selfish)

Dentro de cualquiera de las categorıas anteriores podrıan darse estos tipos de ataques:

Denegacion de Servicio (DoS): Consiste es dejar el nodo fuera de la red

Interceptacion Pasiva: Consiste en escuchar el medio (aire)

Interrupcion del Flujo: Consiste en alterar o modificar el flujo de los datos sin cambiar lasrutas

Integridad de los datos : Modificacion del contenido del mensaje

Ataque de Senalizacion: Modificacion de los paquetes de control

4.1.1. Ataques Externos

Los ataques externos [16, Sec. 5] en general son ataques de capa fısica y de enlace ya quelos protocolos de niveles superiores proveen autenticacion. Los ataques de capa fısica son muydifıciles de implementar por la naturaleza de la red.

Los ataques externos se pueden subdividir por el grado de participacion del nodo agresor endos categorıas: interceptacion pasiva (pasive eavesdropping) e interferencia activa.

4.1.1.1. Interceptacion Pasiva

Esta tecnica permite a los nodos agresores escuchar y recibir mensajes e informacion deactualizaciones de las tablas de ruteo y de esta manera inferir una topologıa de red, identidadeso cuales son los nodos que tienen mas participacion en la red.



4.1.1.2. Interferencia Activa

El objetivo de esta tecnica es causar una denegacion de servicio (DoS) causando un bloqueodel canal de comunicaciones o distorsionando la comunicacion. Las consecuencias de este ataquedepende del tiempo que se aplique y del tipo de protocolo de ruteo utilizado en la red. Si se utilizaun protocolo reactivo, este vera a la interferencia como una ruptura de enlace y el mecanismode mantenimiento de ruta eliminara el enlace con este nodo y no podra recibir mensajes. Si seutiliza un protocolo proactivo la reaccion no es inmediata y si la ruta se cree que esta rota,eventualmente puede expirar su tiempo de vida y ser eliminada.

El ataque mas serio de este tipo es uno llamado sleep deprivation torture que consiste eninterrumpir el perıodo de ocio del dispositivo de capa fısica y producir un consumo excesivode la energıa de la vıctima. Este tipo de ataques ya tiene muchos anos de estudio y la tecno-logıa de espectro ensanchado que utilizan las comunicaciones inalambricas son resistentes a lasinterferencias, 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 nodomalicioso repita mensajes fuera de tiempo, mensajes incompletos hacen un uso excesivo de lasfrecuencias de radio y producen un gasto de energıa y a la vez saturan el nodo con informacioninutil causando una denegacion de servicio.

4.1.2. Ataques Internos

Los ataques internos [16, Sec. 6] son los mas serios y los mas difıciles de defender ya que unnodo interno a la red tiene la informacion necesaria para participar en la red. Los nodos internospueden tener comportamientos maliciosos en diferentes sentidos. Para identificar estos compor-tamientos, se pueden considerar las siguientes categorıas: Nodo Fallido, Nodo Fallido Maligno,Nodo egoısta y Nodo Malicioso.

4.1.2.1. Nodo Fallido

Un nodo fallido es aquel nodo que simplemente no puede realizar una operacion, esto puede serpor varias razones, por ejemplo una falla de energıa o eventos ambientales. El problema principalque 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 comunicacion y puede ser queel resto de los nodos no se hayan enterado de una rotura de una ruta por ejemplo, porque elmensaje debıa pasar por un nodo fallido. Este problema es aun mas crıtico cuando el nodo fallidoes parte de una ruta de emergencia o parte de una ruta segura. Estos fallos pueden crear cuellosde 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 estecaso el nodo deja de operar de una manera consciente. Adicionalmente a este comportamientoun 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 puedenprovocar una ataque de denegacion de servicio (DoS).

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 unnodo no quiera cooperar en la red para preservar sus recursos (energıa) demostrando un com-portamiento similar al de un nodo fallido. La accion tıpica de un nodo egoısta es la de desecharlos paquetes recibidos. Este ataque es muy difıcil de detectar ya que los protocolos no preveen elcontrol de donde se perdio un paquete (a excepcion de DSR). Lo que hay que resaltar es que losnodos egoıstas no ponen en riesgo la integridad de la red inyectando informacion falsa.

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 mencionadosantes pueden estar presentes en un nodo malicioso. A continuacion se muestran distintos tiposde ataques que este tipo de nodos puede introducir:

Denegacion de Servicio El ataque de denegacion de servicio (Denial of Service -DoS-) in-duce a las vıctimas a caer en un ataque sleep deprivation torture que consiste en hacer realizaroperaciones innecesarias a las vıctimas haciendo agotar los recursos de energıa. Este ataque loprovocan enviando a sus vıctimas informacion valida o erronea en forma innecesaria. Los proto-colos proactivos son muy sensibles a este ataque ya que cuando les llega una actualizacion de unnodo deben actualizar todas sus rutas, por lo tanto si se les envıa informacion necesaria estosnodos consumirıan muchos recursos actualizando sus tablas.

Este tipo de ataque tambien atenta contra la integridad de la red porque el nodo atacantepuede enviar mensajes alterando las rutas.

Ataque a la Integridad de la Red Este ataque tiene lugar cuando el nodo agresor inyectaen la red informacion falsa de la topologıa de la red. Muchos otros ataques pueden tener comoconsecuencia este tipo de agresion.

Cuanto mayor es la densidad de la red donde el atacante se encuentra, mayor es la consecuen-cia. Los protocolos proactivos, en especial el OLSR, es muy sensible a este ataque ya que tiene unalgoritmo de flooding muy pobre, con lo cual informacion falsa puede ser reenviada a otro nodo.

Ataque a los protocolos de deteccion de Vecinos Un nodo malicioso puede forzar a unnodo a agregar a un vecino inexistente o hacer que ignore a un vecino real. Este ataque se efectuacontra el protocolo de deteccion de vecinos. El nodo agresor puede enviar a la vıctima un mensajecon la informacion de censado de vecinos incorrectas.

Algunos protocolos como el DSR usan listas negras para bloquear transmisiones a nodos conlos cuales no se tiene un enlace bidireccional. En este protocolo un nodo malicioso podrıa provocaruna alteracion de los links en uno de los sentidos y el mismo protocolo pondrıa a ese vecino en



su lista negra y no le enviarıa ningun mensaje. De manera contraria un nodo malicioso podrıahacer que la vıctima remueva un nodo de la lista negra haciendose pasar por tal enviandole unroute-request con los datos de la cabecera del nodo que esta en la lista negra.

Redireccion de trafico El ataque consiste en que un nodo puede hacerse pasar por otro yası modificar 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 el es eldestino o que el tiene una ruta hacia el destino y de esta manera todo el trafico pasara a traves deel y los mensajes para el destino real lo recibe el. A este caso particular del ataque de redireccionde trafico se lo conoce como agujero negro.

Otra consecuencia de este ataque es que un nodo puede modificar las rutas para que todoel trafico vaya para un nodo y que este caiga en un ataque de sleep deprivation. Este efecto sepuede acentuar haciendo que el nodo agresor envıe al resto de los nodos un numero de saltopequeno hacia el destino y un numero de secuencia mas nuevo para asegurarse que todos losnodos prefieran las rutas que pasan por el nodo vıctima.

Una variante de este ataque que es muy difıcil de detectar es el ataque del tunel (wormholeattack) en el cual la informacion que llega a un nodo es “tuneleada” hacia otro nodo por un mediodirecto mas rapido. Si en un protocolo reactivo, el mensaje es “tuneleado” hacia las cercanıas deun nodo destino, este llegara mas rapido que cualquiera, por lo tanto el retorno de la ruta sera atraves del tunel y como consecuencia de esto el nodo mal intencionado esta dentro de la rutahacia ese destino. Para los protocolos proactivos ese ataque tambien es valido pero se sealiza el“tuneleado” de los mensajes de deteccion de vecinos como se vio en el ataque anterior.

Ataque a los Numeros de Secuencia La mayorıa de los protocolos utilizan numeros desecuencia para prevenir ataques en los cuales se les reenvıen mensajes viejos. Igualmente unnodo malicioso puede explotar esta caracterıstica enviando muchos mensajes con una direccionde destino falsa y un numero de secuencia muy alto, como consecuencia del ataque se produceuna denegacion del servicio porque cualquier mensaje valido de otros nodos seran rechazados portener un numero de secuencia viejo o duplicado.

Ataques a Protocolos Especıficos Existen distintos tipos de ataques para protocolos es-pecıficos. Cuando un nodo malicioso integra una red, ya tiene el conocimiento de que protocoloesta presente en esa red y ası puede ejecutar un ataque especıficamente al protocolo presente.De esta manera el ataque es mucho mas efectivo. Por ejemplo para DSR el nodo atacante puedeinyectar tantas rutas con tantos proximos saltos como sea posible hacia un destino inexistente.Luego el agresor envıa un mensaje hacia el falso destino. En este punto se produce un ataque dedenegacion de servicio, porque cada nodo intermedio va a intentar enviar a su proximo salto elerror de la ruta de los cuales esperara un ACK. El nodo intermedio va a intentar salvar la rutatratando de buscar una ruta alternativa y las rutas alternativas que encuentre van a ser falsas yva a llevar al nodo a incrementar el valor de MAX SALV AGE TIMES hasta su maximo y nova a intentar mas.


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 ruteopara MANETs, se comenzo a investigar como prevenir los ataques. En general se han investigado ydesarrollado mas protocolos seguros basados en los protocolos de ruteo reactivos (DSR o AODV).

Dentro de la variedad de protocolos desarrollados, todos tienen en comun que tratan demitigar los ataques activos producidos por los nodos atacantes que comprometen la integridadde la red, pero no los ataques de nodo egoısta. Otra caracterıstica de los protocolos actuales quees se desarrollan en un ambiente controlado, es decir todos los integrantes de la red que deseencomunicarse deben poder intercambiar algunos parametros de inicializacion (claves entre otros)de antemano.

A continuacion de describiran los protocolos seguros mas populares.

4.2.1. SRP - Secure Routing Protocol

SRP [23] fue concebido como una extension para los protocolos DSR 2.3.2.2 y para IARPparte del protocolo ZRP 2.3.3.1.

SRP garantiza la recoleccion correcta de la topologıa de la red aunque se encuentre en presen-cia de un nodo malicioso. Este protocolo es fuerte ante ataques que intenten modificar el procesode descubrimiento de la ruta.

El protocolo asume la existencia de una security association (SA) entre el nodo origen (S) yel nodo destino (T ). Esta relacion de confianza puede ser inicializada, por ejemplo, si un nodoconoce la clave publica del otro, luego por medio de algoritmos como puede ser Diffie-Hellmanpueden negociar una clave (KS,T ) y utilizarla como SA.

SRP como se dijo anteriormente combate los ataques contra el proceso de descubrimiento deruta y garantiza, teniendo en cuenta algunas asunciones [23, Sec. C.1], que la informacion quereciba un nodo sea correcta. Tambien incorpora algunos mecanismos que previene que se explotenfuncionalidades 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. Elnodo S el pedido de ruta (RREQ) mantiene un numero de secuencia de 32 bits(Query SecuenceNumber, Qsec), el cual es incrementado con cada pedido. Este numero permite a T detectarpedidos viejos y descartarlos. El numero de secuencia se inicializa cuando se establece la SA.

Por cada pedido de ruta, S generara un numero aleatorio de 32 bits (Query Identifier, QID)que es utilizado por los nodos intermedios para identificar el pedido. QID es generado de maneratal que sea imposible de predecir por un atacante.

Estos dos numeros, mas un identificador de tipo son agregados en el encabezado de SRP.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 ProtocolPacket) 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 extension de SRP

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, direccion origen y direccion destinopara insertarlos en una tabla (query table). Todos los pedidos que lleguen y se encuentren en estatabla son descartados, los demas seran retransmitidos para continuar el proceso de descubrimien-to.

Los nodos intermedios tambien controlan la frecuencia con la que se generan los pedidos paramantener un ranking que es inversamente proporcional a la frecuencia de pedido. Generalmenteun nodo malicioso genera muchas solicitudes de ruta con el fin de generar un DoS o utilizar elancho de banda de la red para transmitir paquetes de control. De esta manera, los nodos maliciosorankearan bajo y sus paquetes seran retransmitidos con baja prioridad o eventualmente no setransmitiran.

Una vez que el nodo destino recibe la peticion de ruta (RREQ), verifica la integridad y laautenticidad del mismo calculando el HMAC y comparandolo con el del paquete recibido. Si elpaquete es valido, comienza el proceso de respuesta. El paquete de respuesta (RREP) es generadoutilizando la cabecera SRP del mismo modo que la genero el nodo S cuando genero el pedido.EL nodo origen descartara todos aquellas respuestas que no se encuentren en su lista de pedidospendientes. Esto lo hace utilizando la direccion de origen, la de destino y los numeros QID yQsec.

La version basica de SRP es vulnerable a ataques de envenenamiento de cache de rutas(route cache poisoning) ya que nodos atacantes pueden generar informacion invalida y los nodosintermedios que operan en modo promiscuo para mejorar la eficiencia 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 generarun HMAC del paquete RREP. Con esta extension se agrega un nuevo campo al encabezadoSRP 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 extension INRT

4.2.1.2. Otras Vulnerabilidades

SRP no tiene una validacion para los mensajes de mantenimiento de ruta, los paquetes deerror no son verificados. De todos modos, para minimizar este efecto, SRP genera los paquetesde errores con un prefijo donde esta la ruta completa. Con este prefijo el nodo S puede verificarsi el nodo que genero el mensaje de error es parte de la ruta. Lo que no se puede verificar es si elmensaje es real, es decir un nodo intermedio puede decir que el enlace se rompio pero en realidadesta intacto.

SRP no tiene ninguna contramedida para el ataque del tunel (wormhole attack).

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 algun algoritmode intercambio de claves, en este caso Diffie-Hellman. Otro aspecto es el uso de HMAC paragarantizar integridad y autenticacion del mensaje.

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 utilizacriptografıa simetrica 3.1.1 para que el destino del proceso de descubrimiento de la ruta puedaautenticar al origen, para que el origen pueda autenticar a los nodos intermedios presentes en elmensaje de respuesta RREP y para que ningun nodo intermedio pueda remover algun nodo dela lista del mensaje RREP o RREQ.

Como se comentaba en la introduccion a los protocolos de ruteo seguros, ARIADNE necesitaalgun metodo de intercambio de claves previo. Se deben intercambiar las claves entre el origen S

y el destino D (KS,D).ARIADNE provee una autenticacion punto a punto del mensaje de ruteo usando autenticacion

MAC y una clave compartida entre las dos partes. Para la autenticacion de los paquetes broadcastutiliza un protocolo de autenticacion llamado TESLA [25].



ARIADNE previene la modificacion y el armado de informacion de ruteo, previene el uso dela impersonificacion y en versiones avanzadas del ataque del tunel (wormhole attack).

ARIADNE arma el paquete de solicitud de descubrimiento de ruta adicionandole siete campospara proporcionar autenticacion e integridad.

<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 respec-tivamente. Como en DSR, el id es un numero que no se haya utilizado en los procesosde descubrimiento recientes y el intervalo de tiempo es el intervalo de tiempo de TES-LA, un tiempo pesimista de arribo del pedido al destino. El origen inicia el hash conun MACKS,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 el no es el destino, busca en su tabla porla tupla <origen,id> para determinar si este paquete no lo vio antes, si lo vio descarta el paquete.Tambien verifica que el intervalo de tiempo sea valido, si no lo es descarta el pedido. En casocontrario, el nodo A modifica el pedido agregando su direccion en lista de nodos, reemplazandoel hash con H(A, hash anterior). En la lista de MAC agrega el MAC del pedido completo. Elnodo utilizara la clave TESLA KAi para computar el MAC, donde i es el ındice para el intervalode tiempo especificado en la peticion. Finalmente reenvıa el mensaje.

Cuando el nodo destino recibe la peticion, lo primero que hace es verificar la validez delmensaje calculando si el hash es valido realizando el siguiente calculo.

H[ηn, H[ηn−1, H[..., H[η1, MACKSD(origen, destino, id, intervalo de tiempo)]...]]]

Donde ηi es la direccion del nodo en la posicion i de la lista de nodos y n es la cantidad denodos en la lista.

Si el nodo destino determina que el mensaje es valido, arma el mensaje de respuesta el cualsera enviado al origen siguiendo la ruta reversa.

<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 sonlos mismos que recibio en el RREQ. El MAC destino es un MAC calculado sobre lista de MAC

utilizando la clave KDS y la lista de claves se inicializa vacıa.

Cuando el nodo destino recibe la respuesta, verifica que cada clave en la lista de claves seavalida, el MAC destino sea valido y cada uno de los MAC de la lista de MAC sean validos. Sitodas las verificaciones son exitosas, se acepta el mensaje, en caso contrario se descarta.

ARIADNE tambien se proteje contra ataques de DoS causado por la inyeccion de multiplespaquetes de RREQ. Los nodos pueden filtrar este tipo de ataques usando la cadenas de descubri-miento 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 descubri-miento de una ruta para prevenir ataques de DoS. Si bien esta idea se tuvo en cuenta duranteel desarrollo de la tesis no fue utilizada ya que OLSR es un protocolo proactivo y este tipo dedescubrimiento 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 enfrentarseuna red movil. Tambien se presentaron cuales son las cuestiones basicas que debe garantizar unprotocolo para que sea considerado seguros y finalmente se presentaron protocolos seguros. De losprotocolos desarrollados se indico de cada uno cuales aspectos son provechosos para el desarrollode la tesis. Si bien los protocolos seguros descriptos al final de este capıtulo son protocolos reactivosy el objetivo de la tesis es trabajar con un protocolo proactivo como es el caso del OLSR, algunasideas de estos fueron provechosas.


Capıtulo 5

Redes Moviles Urbanas

El objetivo del presente capıtulo es introducir el concepto de que es una Red MovilUrbana y cuales son los aspectos administrativos de este tipo de redes.

Las redes moviles tiene un uso potencial muy grande ya que los dispositivos de comunicacionmasivos (celulares, PDAs, etc) cada vez estan al alcance de mas personas y ganan popularidaddentro de la sociedad ya que en un solo dispositivo pueden reproducir contenidos multimedia,hablar por telefono y navegar por internet. Estos dispositivos en su mayorıa cuentan con interfacesde red inalambricas las cuales les permiten interconectarse o conectarse a un punto de acceso(Access Point).

Esta popularidad que van ganando los dispositivos moviles sumado a proyectos comunitariosrelacionados con armar redes inalambricas metropolitanas hacen que cualquier persona puedaestar conectada, a traves de una LAN, con otra persona en el otro extremo de la ciudad dondesin la ayuda de una red movil serıa imposible por razones inherentes a la naturaleza de lasconexiones y los dispositivos inalambricos.

La tecnologıa Wi-Fi (802.11) tiene como limitante para establecerse una comunicacion wirelessla lınea de vision, es decir, los dos elementos a comunicarse no deben tener ningun obstaculo queinterfiera entre los dos extremos. Este limitante es el peor enemigo que tiene las redes urbanaspor las caracterısticas edilicias que presenta una ciudad. Viendo un caso practico, una personaquiere comunicarse con un vecino que esta edificio de por medio, por mas que las distancias seancortas, existen paredes que obstaculizan la comunicacion directa entre estas dos personas.

Una red urbana debe combatir esa limitacion y para ello se instalan nodos en posicionesestrategicas que tengan lınea de vision entre sı y de esta manera extender la cobertura. En estecapıtulo se vera como se conforma una red urbana, como nacen y como trabajan redes movilesurbanas en distintas partes del mundo.

51

5.1. Proyectos Comunitarios Libres

5.1. Proyectos Comunitarios Libres

La comodidad de las redes inalambricas, sumado a la posibilidad de conectarse sin cables auna velocidad razonable y el espıritu aventurero de los fanaticos de las comunicaciones llevaronen primera medida a compartir una conexion con un vecino o con un amigo. Siendo esta primeraetapa satisfecha rapidamente, se ven con la necesidad de ir mas alla y conectarse con puntos cadavez mas lejanos y con mayor cantidad de personas. Como existen varias personas con el mismoespıritu aventurero, curioso y con ganas de aprender de comunicaciones o simplemente tienenuna coleccion de discos que quieren compartir con personas mas alla de su cırculo de amistadeses que nacen las comunidades.

Las comunidades conforman una simbiosis entre sus miembros, cada uno necesita de otro parapoder cubrir mas superficie con la red y es ası como nacen las redes urbanas, conformadas porpersonas, sin fines de lucro con el unico objetivo de cubrir cada vez mas superficie para que cadavez haya mas personas conectadas.

Teniendo una vision mas macro de estos grupos, existen en diferentes ciudades del mundogrupos de personas conformando comunidades de redes libres. Para dar algunos ejemplos, enLatinoamerica una de las comunidades mas grandes es BuenosAiresLibre 1, en Argentina otracomunidad 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ıan enumerar infinitascantidades de comunidades de redes urbanas libres en todo el mundo.

5.1.1. Buenos Aires Libre

Como se menciono anteriormente Buenos Aires Libre (BAL) es una de las comunidades deredes urbanas mas grandes de Latinoamerica. Esta comunidad nace como parte de un proyectomas ambicioso llamado Red Libre Argentina que tenıa como objetivo conformar una red abiertaen todo el paıs. El grupo de personas que encabezaban ese proyecto eran de Buenos Aires ydecidieron comenzar por conformar la red comenzando por la Ciudad de Buenos Aires y ası naceel grupo de Buenos Aires Libre.

He elegido esta comunidad como ejemplo de aplicacion de esta tesis ya que soy miembro dela misma desde hace 5 anos y conozco su arquitectura y su topologıa desde el comienzo.

La comunidad se organiza por grupos, actualmente existen dos grandes grupos, el grupo deOrganizacion y los que participan pasivamente en el proyecto o colaboran con un nodo pero noson parte del grupo organizativo. Dentro del grupo de Organizacion existen varios subgrupos contareas especıficas como por ejemplo Direccionamiento IP, Mantenimiento del Site del proyecto,Interrelacion con otros proyectos libres y otras comunidades wireless.

1http://www.buenosaireslibre.org2http://www.mendoza-wireless.net.ar3http://www.montevideolibre.org4http://www.chilesincales.org5http://www.nycwireless.net6http://www.seattlewireless.net



Una vez por mes se realiza una reunion del grupo de Organizacion donde se plantean inquietu-des y se resuelven decisiones consensuadas para la administracion de la comunidad. Por ejemplose determinan pautas para pertenecer al grupo de Organizacion, se decide el espıritu del proyecto,se fomenta e incentiva la instalacion de nuevos nodos entre otras tareas. En estas reuniones cadagrupo presenta nuevas ideas y se fijan objetivos para los diferentes grupos.

5.2. Topologıa

La topologıa de las redes urbanas son muy diferentes ya que se adaptan a la geografıa de laciudad o sencillamenta a donde es posible poner un nodo. Las redes en ciudades grandes dondeprevalecen los edificios de varios pisos es muy difıcil lograr extenderlas ya que es necesario muchosnodos ubicados en edificios altos para que puedan tener lınea de vision. La particularidad de unared urbana es que un dispositivo se puede comunicar con otros a miles de metros sin tener lineade vision y fuera del rango de cobertura del dispositivo utilizando nodos intermedios de la red.

Generalizando, las redes urbanas estan conformadas por dos tipos de nodos: Nodo y Cliente.Un nodo es en general un punto fijo ubicado en un punto estrategico que tiene lınea de vision conotro y son los encargados de extender la red conformando el backbone de la misma. Los Clientesson cualquier nodo (movil o fijo) que se conecta en general a un nodo. La figura 5.1 muestra unatopologıa de red tıpica de una red urbana.

Hasta ahora se desarrollo el concepto de red urbana donde los clientes se conectan general-mente a un nodo. Esta idea es la que se aplica en la actualidad en la mayorıa de las redes urbanasya que los protocolos de redes moviles no han sido estandarizados y no se distribuyen con losdrivers de las placas de red o con los sistemas operativos. Esta forma de conexion es la unica ma-nera que existe hasta el momento para los clientes. Sin embargo, los nodos cuentan con hardwareespecıfico y Sistemas Operativos no convencionales y sı implementan protocolos de redes movilescon lo cual cada nodo pertenece a una red autoconfigurada por estos.

La integracion de los clientes como participantes de la red movil es, por llamarlo de algunamanera, experimental, ya que las implementaciones de los protocolos estan en pleno desarrollo ysolo algunos pocos se aventuran a experimentar.

Cuando los protocolos sean estandarizados y se hagan mas populares, todos los clientes vana ser parte de una red movil. Esto va a permitir que un cliente pueda acceder a la red no soloa traves de un nodo sino a traves de otro cliente. En la Figura 5.1 se muestra una topologıa deuna Red Movil Urbana. En esta se puede observar que los clientes no tienen conectividad contodos los integrantes de la red pero sı tienen conectividad al menos con un cliente o un nodo. Enparticular se puede observar que si el Cliente 9 quiere acceder a internet, su peticion sera ruteadaa traves del Cliente 8, 7, 6 hasta llegar al Nodo 3, el cual no tiene conexion a Internet, peroconoce como llegar a ella, por lo tanto rutea la peticion hacia el Nodo 2, y este hacia el Nodo1 donde finalmente sale a Internet. Cabe destacar que el Cliente 9 sin la colaboracion del restode los intermedios por los que paso el pedido hubiera sido imposible llegar al Nodo 1 el cualgeograficamente podrıa estar a miles de metros.


5.2.1. Direccionamiento IP

Figura 5.1: Diagrama de una red Movil Urbana

5.2.1. Direccionamiento IP

En una red IP, es fundamental tener una direccion para poder comunicarse. En las redesmoviles la asignacion de direcciones IP es parte del desafıo de las funcionalidades que puedebrindar el protocolo de ruteo. En general los protocolos no brindan la capacidad de asignacionde IP sino que se asume que el dispositivo cuanta con una. Algunas implementaciones tienen lacaracterıstica de buscar que no hayan direcciones repetidas dentro de la red en el momento queun nodo se esta asociando.

En las redes urbanas y en especial en BAL, las direcciones IP estan distribuıdas en dos rangos,un rango para nodos y otro para clientes. Existe una entidad llamada freenetworks 7, en dondecada comunidad tiene asignado un rango de IP privadas. Esto garantiza que las redes comunitariasregistradas no tienen direcciones duplicadas. Buenos Aires Libre tiene los rangos asignados porfreenetworks.

A su vez, BAL asigna una subred a cada uno de los nodos para proveer direcciones IP a losclientes (servicio de DHCP en el nodo) y para comunicacion con otros nodos. Con esta asignacionllevada a cabo por un grupo de personas de la comunidad se asegura una homogeneidad dedirecciones dentro de la red.

Hasta el momento por la manera que se conectan los clientes (a un nodo fijo) es la manera deasignar IPs, en un futuro cuando toda la red sea idealmente una red movil se utilizara la tecnicade asignacion de ip estandarizada para este tipo de redes. Las pruebas experimentales se hacenasignando cualquier IP teniendo la precaucion que no sea una direccion repetida.

7http://www.freenetworks.org



5.3. Protocolos de Ruteos

Como se vio en la seccion 2.2 existen varios protocolos para rutear paquetes en una red movil.Tomar la decision de que protocolo usar queda fundamentalmente sujeto a que implementacioneshay disponibles. Existen muy pocos protocolos implementados, entre ellos OLSR y AODV. Laimplementacion de OLSR es actualmente la mas evolucionada e implementada en un proyectoopen source llamado olsrd 8. Muchos proyectos de redes libres lo utilizan, en particular BAL tieneimplementada la interconexion de los nodos con olsrd.

Las pruebas que se estan llevando a cabo con clientes moviles es con implementaciones deeste mismo protocolo, disponibles para diferentes sistemas operativos.

OLSR es un protocolo proactivo en el cual cada nodo conoce la ruta para llegar a cualquierdestino de la red. Actualmente las redes comunitarias no estan compuestas por muchos nodos,con lo cual pueden utilizar OLSR como unico protocolo.

En un futuro cuando se masifique la integracion de los protocolos de redes moviles en losdispositivos, el numero de integrantes crecera en forma desmedida y OLSR no podra ser utilizadocomo unico protocolo. OLSR es un protocolo que tiene como desventaja que en redes muy grandesse genera mucho overhead producto de la mantencion de todas las rutas. Cuando esto ocurraseguramente se utilizaran protocolos hı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 estase 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 dearchivos, otros nodos comparten ancho de banda de Internet. Fundamentalmente los proyectosde redes urbanas libres no tienen como fin proveer Internet a bajo costo ni vender ningun tipode servicio.

Uno de los proyectos comerciales mas importantes relacionado con las redes urbanas se llamaFON 9 en cual permite a los clientes de FON conectarse a Internet de manera inalambrica encualquier ciudad del mundo donde exista FON.

5.5. Administracion de la Red BAL

La red es administrada por los miembros de la comunidad. Los nodos son propiedad de cadauno, es decir cada dueno de su nodo es responsable del mismo como ası de los danos que estepudiese causar. La administracion del nodo es de cada uno pero siempre teniendo como premisacumplir con los lineamientos de la comunidad BAL. El nodo debe tener asignada una IP provistapor el grupo de Organizacion y debe dar servicio con un rango de IPs asignado como ası tambien

8http://www.olrd.org9http://www.fon.com


5.6. Resumen

existe una convencion de nombres para el ESSID del nodo. Cada propietario del nodo puedeprestar el servicio que quiera siempre y cuando este no este en contra del espıritu del proyecto.

En definitiva cualquiera puede tener un nodo pero para pertenecer a la red BAL debe seraprobado por el grupo de Organizacion y esto implica la asignacion de los rangos de IP y elnombre para el ESSID del nodo.

5.6. Resumen

En este capıtulo se hizo una explicacion acerca de las redes urbanas, que caracterısticastopologicas presentan, cuales son los recursos utilizados para sortear los obstaculos puestos por lageografıa de la ciudad y las limitantes del medio de transmision. Se presentaron algunos proyectoslibres que tienen por objetivo conformar una red movil urbana libre y otros proyectos comerciales.


Capıtulo 6

Protocolo OLSR

El objetivo del presente capıtulo es detallar el funcionamiento del protocolo OLSRy enumerar algunas vulnerabilidades del mismo.

El el capıtulo 2 se presento el protocolo OLSR como un protocolo proactivo o basado entablas, es decir todos los nodos de la red conocen la manera de llegar a todos los miembros de lamisma.

En este capıtulo se detallara el funcionamiento del protocolo como tambien se identificaranlos puntos en los cuales es necesario aplicar seguridad para mantener la integridad de la red ysus integrantes.

6.1. Introduccion

OLSR es un protocolo proactivo [5, Sec. 1.3] para redes moviles ad-hoc definido por la RFC3626. El protocolo hereda la estabilidad del protocolo Link-State y tiene la ventaja de disponerde las rutas en el momento que son requeridas.

El protocolo mejora de su predecesor el mecanismo de flooding para la distribucion de lospaquetes de control a traves de nodos especıficos llamados MPRs (Multi Points Relays), loscuales son los unicos que pueden reenviarlos. De esta manera se optimiza la distribucion de lospaquetes evitando retransmisiones. Los MPRs tienen la caracterıstica de tener un enlace solidocon su vecino haciendo que la comunicacion sea lo suficientemente estable.

El protocolo OLSR no necesita ninguna modificacion del stack de protocolos ya que se ubicapor encima de este modificando las tablas de ruteo del sistema.

6.2. Terminologıa Propia de OLSR

Para entender el desarrollo de las proximas secciones es necesario introducir algunos de losterminos del protocolo OLSR [5, Sec 1.1].

57

6.3. Tablas del Protocolo

Nodo: Router que implementa OLSR.

Interfase OLSR: Dispositivo de red que participa en la red corriendo OLSR. Un nodopuede tener mas de una interfase, cada una con una direccion IP distinta.

Direccion Principal: La direccion principal de un nodo es utilizada como direccionoriginadora del mensaje. Un nodo con multiples interfases OLSR debe elegir unaunica IP como direccion principal.

Nodo Vecino: Un nodo X es vecino de un nodo Y si el nodo Y puede escuchar al nodoX.

Vecino de 2-Saltos: Nodo vecino de un vecino.

Multipoint Relay (MPR): Es un nodo vecino del nodo X seleccionado para retrans-mitir los mensajes broadcast emitidos por X.

Multipoint Relay Selector (MPR Selector): El MPR Selector del nodo X, es el conjuntode nodos que eligieron al nodo X como MPR.

link: Es el par de interfaces OLSR (de distintos nodos) que pueden escucharse.

link simetrico: Es cuando el par de interfaces de distintos nodos pueden escucharseuna con otra.

link asimetrico: Es cuando el enlace de dos interfaces OLSR se da en un solo sentido.

Vecino simetrico: Es un nodo vecino con el cual al menos una interfase OLSR tieneun enlace simetrico.

Vecino simetrico de 2-Salto: Es un vecino simetrico de un vecino simetrico del nodoX.

6.3. Tablas del Protocolo

Como se explico en la Seccion 2.3.1, OLSR es un protocolo proactivo o basado en tablas, esdecir toda la informacion necesaria para su funcionamiento es almacenada en tablas. Las tablasdefinidas en la RFC, varıan con las tablas de la implementacion del protocolo, pero los datosalmacenados en ambas estructuras de tablas son los mismos. Esta simplificacion de tablas espara hacer mas rapido el mantenimiento de las tablas. Las tablas del protocolo OLSR son lassiguientes:

Multiple Interfase Association Information : En esta tabla se almacenan las interfacesOLSR de los vecinos, es decir, si un vecino tiene dos interfaces OLSR, las dos se asocian a unadireccion principal, que sera la utilizada para identificar al nodo.

I iface addr: Direccion de una de las interfaces de un nodo.I main addr: Direccion principal de un nodo.I time: Tiempo de expiracion de la tupla.

Link Set : En esta tabla se almacena el estado de los enlaces con los vecinos.


Protocolo OLSR

L local iface addr: Direccion de la interfase local del nodo (un extremo del enlace).L neighbor iface addr: Direccion de la interfase del nodo vecino (el otro extremodel enlace).L SYM time: Es el tiempo que se considera al enlace como simetrico.L ASYM time: Es el tiempo hasta que se considera como escuchada a la interfase delvecino.L time: Tiempo de expiracion de la tupla.

Neighbor Set : Esta tabla tiene por objetivo almacenar el estado de los vecinos, identificando-lo solo por la interfaz principal.

N neighbor main addr: Direccion principal del nodo vecino.N status: Especifica si el nodo esta en estado SYM=enlace simetrico o NOT SYM=enlaceno simetrico.N willigness: Es un entero entre 0 y 7 y especifica la confianza que se le tiene alnodo vecino para llevar el trafico.

2-hop Neighbor Set : Se almacena el estado de los vecinos de dos saltos de distancia, iden-tificandolo por la direccion de la interfaz principal.

N neighbor main addr: Direccion principal del nodo vecino.N 2hp addr: Direccion principal del nodo vecino de 2-Saltos que tiene enlace simetricocon N neighbor addr.N time: Tiempo de expiracion de la tupla.

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: Direccion principal del nodo.MS time: Tiempo de expiracion de la tupla.

Topology Information : Conformada por las tuplas {T dest addr, T last addr, T seq,T time}

T dest addr: Direccion principal del nodo destino que es alcanzado en un salto porel nodo con direccion principal T last addr.T last addr: Es MPR de T dest addr.T seq: Numero de secuencia.T time: Tiempo de expiracion de la tupla.

Host and Network Asociation Base : Conformada por las tuplas {A gateway addr,A network addr, A netmask, A time}

A gateway addr: Direccion de la interfase OLSR del gataway.A network addr: Direccion de red.A netmask: Mascara de la red.A time: Tiempo de expiracion de la tupla.


6.4. ¿Como Funciona?

6.4. ¿Como Funciona?

OLSR es un protocolo independiente del stack TCP/UDP, es decir utiliza el stack pero nonecesita informacion de la capas inferiores para poder operar. El objetivo del protocolo es modi-ficar las tablas de ruteo del Sistema Operativo para poder llegar a todos los nodos de la red, paraello necesita recolectar informacion de su entorno. Esa informacion es relevada con el intercambiode mensajes con los vecinos. La comunicacion con los vecinos se realiza mediante paquetes UDPutilizando el puerto 698 [5, Sec. 3.1]. Los datos obtenidos son almacenados en las tablas descriptasanteriormente para un posterior procesamiento y armado de las rutas.

Los mensajes intercambiados son de tres tipos y con tres finalidades distintas. Los mensajesde HELLO son mensajes para relevar el estado de los vecinos de primer y segundo nivel, losmensajes de TC son para informar el estado de los vınculos mas alla de los lımites del nodoy por ultimo los mensajes MID por los cuales se informa a los nodos cuales son las interfacesdisponibles para un determinado nodo. Por medio de estos paquetes es que se conoce como llegara un determinado nodo. Estos tres tipos de mensajes son los principales para que OLSR puedafuncionar. Adicionalmente, existe la posibilidad de que la red se comunique con otras redes. Elarmado 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 censadoy la deteccion de los vecinos, segunda etapa la seleccion de los MPR, tercera etapa propagacionde la informacion de la topologia de la red, cuarta etapa armado de las rutas y por ultimo unaquinta etapa con el mantenimiento de las misma (Figura 6.1).

6.4.1. Mensajes de OLSR

El protocolo [5, Sec 3.3] define un formato de paquete para todos los mensajes del protocolo.Para cada tipo de mensaje lo que varıa es el contenido del campo MESSAGE que se muestra el laFigura 6.2.

Los campos del mensaje de OLSR son los siguientes:

Packet Length: Es el tamano en bytes del mensaje.

Packet Sequence Number: Numero de secuencia, el cual es incrementado en unocon el envıo de cada paquete.

Message Type: Indica que tipo de mensaje se encontrara en el campo MESSAGE.

Vtime: Este campo indica por cuanto tiempo despues de la recepcion debe considerarla informacion como valida.

Message Size: Indica el tamano del mensaje en bytes. Cuenta desde el campoMessage Type hasta el comienzo de otro Mesage Type.

Originator Address: Es la direccion principal del nodo que genero el mensaje.

Time to Live: Contiene el maximo numero de veces que el mensaje debe ser re-transmitido (cantidad de saltos que debe recorrer).

Hop Count: Numero de saltos por los que el paquete ha pasado.


Protocolo OLSR

Figura 6.1: Etapas del protocolo OLSR

Message Count Sequence: Numero de secuencia unico para cada mensaje. Estenumero se incrementa en uno con el envıo de cada mensaje.

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 tipode vınculo por el cual los alcanza. Como se comento anteriormente esta tarea es realizada por elintercambio de mensajes de HELLO.

6.4.2.1. Mensaje de HELLO

Este mensaje es parte del paquete OLSR descripto anteriormente en la Seccion 6.4.1 donde esincluıdo en el campo MESSAGE del mismo con Message Type=HELLO MESSAGE. La estructura del



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 :

| |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

: :

(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 emision de los mensajes de HELLO del nodo que lo origina.

Willingness: Es una valor del 0 al 7 que indica la confiabilidad de un nodo pararetransmitir un mensaje. Por ejemplo un nodo con valor WILL NEVER nunca va aser elegido como MPR, un nodo con WILL ALLWAYS, siempre va a ser elegido comoMPR. El valor por defecto es WILL DEFAULT.

Link Code: Este campo indica el tipo de vınculo que hay entre la interfase de quienenvıa el mensaje con el listado de interfaces de los vecinos. Este campo es de 8 bitde los cuales solo se interpretan los codigos menores o iguales a 15 como el par decodigos como se indica en la Figura 6.3

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 codigo del enlace

Los codigos de los posibles vınculos se definen como:


Protocolo OLSR

UNSPEC LINK: No se especifica informacion acerca del enlace.ASYM LINK: Link asimetrico.SYM LINK: Link simetrico.LOST LINK: Perdida del vınculo.

Los codigos de los tipos de vecinos se definen como:

SYM NEIGH: Indica que al menos una de la interfaces del vecino tiene unenlace simetrico con el nodo.MPR NEIGH: Indica que al menos una de la interfaces del vecino tiene unenlace simetrico con en nodo y a su vez el vecino fue seleccionado comoMPR por el originador del mensaje.NOT NEIGH: Todavıa no se tiene un vınculo simetrico con el vecino.

Link Message Size: Indica el tamano del mensaje en bytes. Cuenta desde el campoLink Code hasta el comienzo de otro Link Code.Neighbor Interfase: La direccion de una interfase de un vecino.

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 |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

: . . . :

: :

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Link Code | Reserved | Link Message Size |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

: :

: :

(etc.)

Figura 6.4: Formato del mensaje de HELLO

6.4.2.2. Mensaje MID

Cada nodo integrante de la red puede tener mas de una interfase OLSR, pero solo una direccionprincipal, por eso es que existe un mensaje que informa a los nodos que un determinado nodocuenta con determinadas interfaces OLSR y envıa las direcciones de las mismas.



Este mensaje es parte del paquete de OLSR donde es incluıdo en el campo MESSAGE del mismo.La estructura del mensaje MID que se muestra en la Figura 6.5 donde OLSR Interfase Address

es la direccion de cada una de la interfaces. En el header del mensaje OLSR se indica que la IPque envıa el mensaje es la direccion principal del nodo, por lo tanto el nodo que recibe el mensajeasocia esa direccion principal con las listadas en el mensaje.

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 sera analizado a partir de las Figuras 6.6 y la Figura 6.7 dondese plantea un ejemplo paso a paso donde el nodo A se incorpora a la red. En las Figuras se haceuna referencia cronologica de como se van intercambiando los mensajes y como estan las tablasde cada nodo en cada uno de los instantes. Para una mejor interpretacion y claridad en la figura,las tablas Neighbor Set , 2-hop Neighbor Set y MPR Set son agrupadas en una sola tablallamada Neightbor Table .

En la Figura 6.6 en el instante t1 se puede ver que el nodo A envıa el mensaje de HELLOvacıo y un mensaje MID indicando que solo tiene una interfase OLSR. El nodo B tiene comovecino 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 laLink Table donde indica que A es vecino, recibio el mensaje por la interfase A, es un vınculoasimetrico (notar que pone como valor tiempo de vida del enlace simetrico con un valor vencido,es decir t2 -1). En la tabla de vecinos agrega al nodo A indicando que es un vecino asimetrico yno es MPR ni vecino de segundo salto.

En ese mismo instante, B envıa un mensaje de HELLO informando el estado de sus enlacesclasificados por tipo y un mensaje MID diciendo que solo tiene la interfase con la direccion B.

En la Figura 6.7 en el instante t3, el nodo A recibe el mensaje de B y ve que su direccion esparte del mensaje recibido, por lo tanto agrega una entrada en la tabla de enlaces indicando queel enlace con B es simetrico. Agrega una entrada en la tabla de interfaces con la interfase de B.Agrego en la tabla de vecinos al nodo B como simetrico y al nodo C como vecino de 2-Saltos yaque este tiene enlace simetrico con B. El nodo C no actualiza la informacion del nodo A porqueel nodo B aun tiene un enlace asimetrico con A y un vecino de 2-Saltos es considerado cuandohay un enlace simetrico entre el vecino y el vecino de dos saltos de distancia.

En ese mismo instante A envıa un mensaje de HELLO con la informacion de sus enlaces.


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 direccion esta listada y actualizala entrada en tabla de enlaces indicando que el tiempo del enlace simetrico es un tiempo valido.En la tabla de vecino actualiza la entrada de A indicando que es un vecino simetrico.

En ese instante B envıa un mensaje de HELLO.En el instante t5 el nodo C se entera que existe un enlace simetrico entre A y B y agrega una

entrada en la tabla de vecinos para A indicando que es vecino de 2-Salto.

6.4.3. Etapa 2: Eleccion de los MPRs

OLSR mejora el mecanismo de flooding de otros algoritmos similares con la eleccion de denodos como Multi Point Realys para minimizar los paquetes de control en la red. Por lo tantocada nodo debe escoger un conjunto de nodos pertenecientes a sus vecinos de primer nivel comoMPR de manera tal que a traves de ellos pueda llegar a todos los vecinos de dos saltos de distancia(vecinos 2-Saltos).

Para la eleccion de los MPRs, el RFC [5, Sec. 8.3.1] define una heurıstica, la cual debe seraplicada por cada interfase OLSR del nodo. El conjunto de MPRs de un nodo es la union de los


6.4.3. Etapa 2: Eleccion de los MPRs

Figura 6.7: Censado y Descubrimiento de Vecinos - Parte 1

MPRs encontrados para cada interfase.

Para la definicion de la heurıstica es necesario definir algunos terminos:

Vecino de una Interfase: Vecino que tiene un enlace con el nodo local a traves de unainterfase 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 traves de la interfase I. exclu-yendo:

Los nodos que solo son alcanzados por los miembros de N con willignessdistinta de WILL NEVER

El nodo que realiza el calculo del MPR (nodo local)


Protocolo OLSR

Figura 6.8: Multipoint Relays

Todos los vecinos simetricos: todos los nodos que tengan un enlacesimetrico en alguna de la interfaces.

D(y): El grado del nodo y (donde y es miembro de N), esta definido por lacantidad de vecinos simetricos que tenga el nodo y (en todas sus interfaces),excluyendo todos los miembros de N y el nodo que esta realizando elcalculo.

La heurıstica de seleccion de los MPRs es:

1. Selecciona los nodos del Nivel 1 (N) que cubren nodos aislados del Nivel 2 (N2). Nodoaislado es aquel nodo que pertenece al Nivel 2 y tiene como vecino a un solo nodo del Nivel1. Ademas se seleccionaran todos los nodos de N con willigness igual a WILL ALWAYS

2. Se toman los vecinos de Nivel 1 que no fueron seleccionados en el paso anterior y se seleccionael nodo que cubra el mayor numero de nodos de Nivel 2. Esto se repite hasta que todoslos nodos de Nivel 2 hayan sido cubiertos. En caso de empate, se elige el nodo con mayorwilligness, en caso de que esto de multiples nodos, se va a elegir aquel nodo con mayor(D(y)). En caso que los criterios anteriores no elijan un unico nodo se seleccionara demanera aleatoria.

Ejemplo: Este ejemplo mostrara como se realiza la eleccion de los MPRs para el nodo O

donde todos los nodos tienen willigness igual a WILL DEFAULT. En la figura 6.9(a) se ve al nodo O

con la distribucion de vecinos. N = {1, 2, 3, 4, 5, 6} y N2 = {7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18}.En la primera fase se eligen aquellos vecinos que cubren los nodos aislados de Nivel 2 (2 y 5), esdecir MPR1(O) = {N(v) ∩ N2(O) ∧ | N(O) ∩ N(v) |= 1} donde v ∈ N(O) como se muestra enla Figura 6.9(b).

El algoritmo, al finalizar la primera fase, elimina de los conjuntos de nodos aquellos que yafueron elegidos como MPR y los nodos de Nivel 2 alcanzados por los MPRs seleccionados comose ve en la Figura 6.10(a).

El proximo paso es ejecutar la segunda fase donde selecciona de los nodos de Nivel 1 aquellosque cubran mas cantidad de nodos de Nivel 2 hasta cubrir todos los de Nivel 2. Para ello realiza


6.4.4. Etapa 3: Mantenimiento de la Topologıa

una iteracion donde elige como MPR un nodo que cumpla con MPR2(O) = {maxw∈N(O) |N2(O)∩N(w) |} como se ve en la Figura 6.10(a) y elimina del conjunto de nodos para la proximaiteracion el MPR seleccionado y los nodos de Nivel 2 alcanzables por el mismo (Figura 6.10(b)).Notar que en el momento de eleccion del nodos 4 y el nodo 1, se los elige porque estos tiene mayorcantidad de vecinos (D(y)).

Finalmente los MPRs seleccionados son los que se muestran en la Figura 6.8.

(a) Distribucion de vecinos: (b) Seleccion de los nodos de Nivel 1 que tienen ve-cinos aislados

Figura 6.9: Fase 1 : Seleccion de MPRs que cubren nodos aislados del Nivel2.

(a) Primera iteracion de la segunda fase (b) Segunda iteracion de la segunda fase

Figura 6.10: Fase 2: Se completa la seleccion de MPRs.

El conjunto de MPRs son recalculados cada vez que hay algun cambio en los enlaces con losvecinos.

Cuando un nodo recibe un mensaje de HELLO donde ve que el vecino lo selecciono a el comoMPR (tipo de vecino igual a MPR NEIGH), este agrega la direccion principal del nodo generadordel mensaje en la tabla de MPR Selector. Por medio de esa tabla un nodo pueda saber quien loeligio a el como MPR.

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 lared, para ello debe conocer cual es la topologıa de la misma. Como el dominio de cada nodo


Protocolo OLSR

es conocer la informacion de los nodos hasta dos saltos de distancia, necesita alguna manera deconocer la topologıa de la red mas a alla de ese lımite. OLSR implementa un sistema de mensajespara informar a los nodos la topologıa de la red y los cambios que se produzcan. Para transmitiresta informacion OLSR usa un tipo de mensaje llamado Topology Control (TC).

6.4.4.1. Mensaje TC

El mensaje TC es parte del paquete de mensaje de OLSR descripto en 6.4.1 en el campoMESSAGE con Message Type=TC MESSAGE. La estructura del mensaje TC es la que se muestra enla Figura 6.11 cuyos campos son:

Advertised Neighbor Sequence Number (ANSN): Numero de secuencia para el con-junto de enlaces informados. Este numero cambia cada vez que un enlace es agregadoo removido del conjunto.

Advertized Neighbor Main Address: Es la direccion principal de un nodo vecino.

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 propagacion de los mensajes TC

Para poder diseminar por la red y que cada nodo pueda completar las tablas de topologıaes necesario que cada nodo que haya sido seleccionado como MPR genere un mensaje TC y lotransmita en forma de broadcast. Cada nodo debe diseminar al menos el conjunto de enlaces conlos 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, sedeberan enviar tantos mensajes como sea necesario hasta informarlos todos.

Cuando un nodo recibe un mensaje TC realiza los siguientes pasos:

1. Si la interfase del que envıa el mensaje no esta entre los vecinos simetricos de un salto dedistancia, se descarta el mensaje.

2. Si existe alguna tupla en la tabla de topologıa donde T last addr sea igual a la direccionde origen del mensaje y exista un T seq mayor a ANSN, el mensaje se descarta. Es el casode un mensaje viejo.


6.4.5. Etapa 4: Formacion de las Rutas

3. Todas las tuplas donde T last addr sea igual a la direccion de origen del mensaje y existaun T seq menor al ANSN del mensaje son eliminadas.

4. Para cada una de las entradas de la tabla de topologıa donde T dest addr sea igual a lasdirecciones informadas en el mensaje y T last addr sea igual a la direccion de origen delmensaje, 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ıa, sonagregadas.

6.4.5. Etapa 4: Formacion de las Rutas

Cada nodo tiene una tabla de ruteo con la cual puede llegar a cualquier nodo de la red yrutear datos hacia cualquier destino. Esta tabla esta basada en la informacion recolectada en latabla de enlaces y en la tabla de topologıa. Por esa razon es que cualquier alteracion en dichastablas provocan un calculo de todas la ruta.

Cada una de las entradas en la tabla de ruteo tiene la siguiente forma:

1. R_dest_addr R_next_addr R_dist R_iface_addr

2. R_dest_addr R_next_addr R_dist R_iface_addr

3. ,, ,, ,, ,,

donde R dest addr es la direccion principal de un nodo que se espera que este a R dist saltosdel nodo actual, R next addr es un vecino que tiene un enlace simetrico con el nodo actual y esel proximo salto hacia el destino R dest addr y ese vecino lo alcanza a traves de la interfase localR iface addr.

Para construir una ruta, se utiliza el algoritmo de camino mas corto (Shortest Path Algorithm.Para la construccion de la tabla de ruteo se siguen los siguientes pasos:

1. Se borran todas la entradas de la tabla

2. Se agregan las rutas para todos los vecinos que tienen enlaces simetricos

3. Por cada nodo perteneciente a los vecinos de 2-Saltos se crea una entrada indicando

R dest addr=direccion principal del nodo de 2-SaltosR next addr=entrada de tabla de ruteo R dest addr dondeR dest addr=N neighbor main addr de la tabla 2-hop Neigbor SetR dist=2R iface addr=entrada en la tabla de ruteo dondeR iface addr=N neighbor main addr de la tabla 2-hop Neigbor Set

4. El siguiente procedimiento debe ser ejecutado desde h=2 hasta que no se existan mas en-tradas para agregar.


Protocolo OLSR

Para cada entrada de la tabla de topologıa, si existe T dest addr que es distintoa 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 dest addr=T dest addr

R next addr=R next addr de una entrada de tabla que cumpleR dest addr=T last addr

R dist=h+1

R iface addr=R iface addr de una entrada de la tabla que cumpleR dest addr=T last addr

5. Por cada entrada en la tabla de interfaces, cuando exista una entrada dondeR dest addr=I main addr (de una asociacion con varias interfaces) y no exista una en-trada para cada asociacion del tipo R dest addr=I iface addr, se crea una entrada en latabla a modo de alias para cada interfaz.

R dest addr = I iface addr

R next addr = R next addr de la entrada en la tablaR dist = R dist

R 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 automaticamente cada vez quese altera un enlace. La alteracion de un enlace puede ser que se haya agregado un nuevo vecinoo que alguna de las entradas de las tablas expiro con lo cual es necesario recalcular la tabla deruteo.

Por esta razon siempre que haya una tabla calculada, todas las entradas son validas.

6.4.7. Comunicacion con Otras Redes

El protocolo OLSR fue disenado para que los nodos de la red no solo se comuniquen entreellos, sino tambien da la posibilidad de poder comunicarse con otras redes. Para lograr esto, elprotocolo envıa mensajes llamados HNA.

6.4.7.1. Mensaje HNA

El mensaje HNA es enviado como MESSAGE en el paquete general de OLSR definido en la Sec-cion 6.4.1 con Message Type=HNA MESSAGE. El formato del mensaje se muestra en la Figura 6.12cuyos campos son:

Network Address: Direccion de la red asociada

Netmask: Mascara para la red asociada.


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. Asociacion de la redes

Los mensaje HNA, son emitidos por todos los nodos informando las redes externas a lascuales el nodo puede acceder. Estos mensajes son similares a los mensajes TC ya que indicanun camino hacia una nueva red. A diferencia de los mensajes TC los HNA incluyen el camponetmask correspondiente para la red.

De esta manera cuando un nodo recibe un mensaje HNA, agrega una entrada en la tabla deasociacion de nodos y redes con A gateway addr igual a la direccion principal de donde provinoel mensaje y con la direccion de la red y la mascara que vienen en el mensaje y se le coloca untiempo de expiracion a la tupla.

Estas nuevas rutas hacen que la tabla de ruteo las deba incluir. Por lo tanto, al procedimientode actualizacion de la tabla de ruteo descripto en la Seccion 6.4.6 se le debe agregar que paracada una de las entradas de la tabla de asociacion de nodos y redes se debe crear una nuevaentrada en la tabla de ruteo donde:

R dest addr=A network addr/A netmask

R next addr=R next addr de una entrada donde R dest addr=A gateway addr

R dist=R dist de la entrada al gatewayR iface addr=R iface addr de la entrada en la tabla dondeR dest addr=A gateway addr

6.5. Seguridad

El protocolo OLSR no tiene especificadas medidas de seguridad [5, Sec. 20]. Como OLSR esun protocolo proactivo es muy sensible a cualquier ataque y puede poner en peligro la integridadde la red.

6.5.1. Confidencialidad

OLSR envıa periodicamente mensajes con informacion de la topologıa de la red, esa informa-cion puede ser usada por un atacante y modificar la topologıa de la red. El RFC de OLSR no


Protocolo OLSR

define ninguna alternativa para garantizar la confidencialidad de los mensajes de control. Solopropone utilizar mecanismos de encriptacion de clave compartida o usar PGP sin brindar detallesde la forma de su implementacion.

6.5.2. Integridad

En OLSR cada nodo inyecta en la red informacion de la topologıa a traves de los mensajes deHELLO y TC. Por ser el medio de propagacion de los mensaje el aire, es un medio no controladoy cualquier nodo podrıa enviar informacion invalida con lo cual se compromete la integridad dela red. Por lo tanto, algun mecanismo de autenticacion debe ser implementado pero el RFC [5] noindica con que algoritmo, ni de que forma, solo recomienda el uso de autenticacion para preveniralguna 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 haciendose pasar por otro nodo

5. Un nodo reenvıa mensajes de control alterados

6. Un nodo no reenvıa un mensaje de control

7. Un nodo no selecciona su MPR correctamente

8. Un nodo replica mensajes de control grabados de otro nodo

La autenticacion previene alguna de estas situaciones pero no todas. Para prevenir el punto8 es necesario implementar algun mecanismo de informacion temporal para que un nodo puedaidentificar claramente los mensajes viejos.

En general los paquetes necesarios para la autenticacion, pueden ser enviados dentro delpaquete generico de OLSR como un tipo de mensaje distinto. De esta manera se podrıa hacerque 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, losTC y los HNA. Estos paquetes son los encargados de armar y diseminar por la red la informacionde la topologıa de la misma. Un atacante puede usar estos mensajes y modificarlos para beneficiopropio.

Es necesario que estos mensajes sean encriptados y autenticados para garantizar confidencia-lidad e integridad de los mensajes.

Aplicando seguridad sobre estos mensajes no garantiza que la red va a ser segura ya que nodosparticipantes de la red pueden causar intencionalmente o no ataques, pero eliminarıa muchosposibles atacantes externos.


6.6. Vulnerabilidades


OLSR por ser un protocolo que corre sobre el stack TCP/UDP, tiene las vulnerabilidadesintrınsecas con la tecnologıa en la cual se apoya para operar. Estos ataques son comunes a todoslos 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 deataques no son tenidos en cuenta por los protocolos ya que es tarea de las capas inferiores mitigarestas amenazas.

En OLSR cada nodo tiene dos responsabilidades fundamentales. La primera es que cada nododebe generar la informacion de ruteo de manera correcta y la segunda es que cada nodo esresponsable de reenviar los paquetes recibidos a otros nodos de la red. Cualquier alteracion deestas responsabilidades pueden terminar amenazando la integridad de la red.

(a) El nodo O envıa un mensaje de HELLO pre-tendiendo ser 3

(b) El nodo O envıa un mensaje de HELLO anuncia-do un link falso con 1

Figura 6.13: Generacion incorrecta de mensajes HELLO

Algunas de las vulnerabilidades presentes en OLSR [20, Sec. IV] son:

A. Generacion Incorrecta de Mensajes de Control

a) Generacion incorrecta de mensajes HELLO : Un posible ejemplo de este ataque es queun 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 travesde sus mensajes de HELLO y TC. El nodo O elige MPRs entre sus vecinos siempre ennombre del nodo 3, por lo tanto los nodos que fueron elegidos como MPR, informan ensus mensajes TC que ellos son el ultimo salto hacia 3. Esto genera conflictos en las rutashacia 3 y podrıa dejar al nodo con perdida de conexion.

Otro ataque con esta modalidad es la modificacion de enlaces [15, Sec. III.A] que tieneun nodo (Figura 6.13(b)). En este caso el nodo O envıa en su mensaje de HELLO quetiene un enlace con 1 (que no es vecino). Esto tiene como consecuencia que el nodo 3tenga un MPR Set incorrecto y los mensajes provenientes de 5 y reenvıados a traves delos MPRs nunca llegue a 1.

b) Generacion incorrecta de mensajes TC [15, Sec. III.B]: La generacion de mensajes TCcon direccion de origen incorrecta puede generar informacion erronea referente a la re-


Protocolo OLSR

Figura 6.14: Generacion incorrecta de mensajes TC

lacion de los vecinos (Figura 6.14). El nodo malicioso O envıa un mensaje TC en lugardel nodo 3 informando que el nodo 1 es su vecino. El nodo 4 concluye de manera erroneaque 3 y 1 son vecinos. La generacion de mensajes TC con informacion de enlaces falsostiene las mismas consecuencias.

c) Generacion incorrecta de mensajes MID/HNA: Un nodo podrıa enviar mensajes in-formando que tiene determinada interfase emitiendo el mensaje con una direccion deorigen perteneciente a otro nodo. Este ataque hace que los nodos que reciben el paqueteno puedan alcanzar al nodo real a traves de la interfase que envio el nodo malo ya queesa interfase no existe.

d) Ataque a los numeros de secuencia: Un nodo malicioso podrıa escuchar los mensajes TCde un nodo A y almacenar el ANSN (Advertised Neighbor Sequence Number) del mensaje,luego envıa mensajes falsificando la direccion de origen con ANSN mucho mayores que elalmacenado. Segun el protocolo, los nodos ignoraran los mensajes con ANSN menores alultimo recibido, por lo tanto los mensajes de A seran descartados porque seran tomadoscomo viejos.

B. Reenvıo Incorrecto de Mensajes de Control

a) Ataque del Agujero Negro: Este ataque se produce cuando un nodo no reenvıa los men-sajes como lo requiere el protocolo, de este modo se disminuye la informacion de losenlaces disponibles en la red. Si los mensajes TC no son reenviados, la red comienza atener problemas de conectividad y hasta podrıa llegar a dividirse. Si no se reenvıan losmensajes HNA, se podrıa perder el acceso hacia otras redes.

b) Ataque por Reenvıo de Mensajes: Un nodo atacante podrıa grabar todos los mensajesque pasaron por el durante un determinado perıodo y luego mas tarde reinyectarlos enla red modificando todas las tablas de ruteo de los nodos. Los mensajes TC no puedenser inyectado en la misma manera como fueron grabados, sino que de debe poner unnumero ANSN grande para que sean aceptados por los nodos, causando de esta maneraun ataque de numero de secuencia.

c) Ataque del tunel (wormhole attack) [18, Sec. 4]: Este ataque tiene mucho impacto en lared. Consiste en grabar el trafico en un sector de la red y reproducirlo tal cual en otra



(a) Tunel creado por O entre 3 y 4 (b) Tunel creado por O y O′ (complices) entre3 y 4

Figura 6.15: Ataque por tunel (Wormhole)

region de la misma. Se puede generar un enlace artificial entre el nodo 3 y el 4 a travesde un nodo atacante (Figura 6.15(a)) o si un nodo agresor tiene un complice y puedegenerar un tunel fuera de la red y conectarse a una region mas lejana (Figura 6.15(b)).El agresor puede explotar este ataque cuando los nodos 3 y 4 hayan intercambiado sufi-cientes mensajes de HELLO a traves del tunel como para establecer un enlace simetrico.Mientras el enlace no sea simetrico, los mensajes TC/MID/HNA son descartados. Conel enlace simetrico establecido, todos los paquetes que vayan de un extremo al otro de lared van a ser enviados a traves del tunel porque se va a creer que es la ruta mas corta yel trafico va a pasar todo por el nodo atacante.

d) Ataque al (MPR-Flooding): Una de las primeras reglas de transmision enunciada en laespecificacion de OLSR es que durante el proceso de flooding de los MPRs, los mensajesrecibidos son verificados si provienen de un nodo dentro del MPR Selector del nodo y losmensajes iguales recibidos posteriormente son descartados. Por ejemplo un nodo A envıaun mensaje B y X (nodo malicioso), donde B es MPR de A y X no el MPR. X reenvıa(sin tener que hacerlo segun la especificacion) el mensaje a C, luego B tiene como MPRa C y reenvıa el mensaje a A. Ese mensaje es descartado porque el mismo mensaje delo envio X con lo cual resulta que se interrumpe el flujo del paquete (Figura Bd).

Figura 6.16: Ataque al (MPR-Flooding)

C. Ganar posicion privilegiada: Cualquiera de los ataques antes mencionados pueden serexplotados de mejor manera si el nodo es posicionado como MPR, para ello el nodo primero


Protocolo OLSR

ingresa a la red y envıa los mensajes de HELLO con Willingness WILL ALWAYS. De estamanera es muy probable que algun nodo lo elija como MPR y una vez ubicado comienza concualquiera de los ataques.

6.7. Resumen

En este capıtulo se mostro el funcionamiento del protocolo OLSR, cuales son los mensajes quese intercambian, que informacion viaja en cada paquete y como utiliza cada nodo esa informacion.Se vio como construye cada nodo sus propias tablas de ruteo con la informacion recolectada delos nodos vecinos y de la red en general. Se realizo una presentacion de las vulnerabilidades quepresenta el protocolo, las cuales seran analizadas y se propondra una contramedida en el protocolopara hacerlo mas robusto.


6.7. Resumen


Capıtulo 7

Diseno de un Esquema de

Seguridad para una Red Movil

OLSR Urbana

El objetivo de este capıtulo es presentar el diseno del esquema de seguridad parauna Red Movil basada en OLSR teniendo en cuenta los aspectos organizacionales delas comunidades que las administran y cuestiones propias del protocolo.

En el Capıtulo 5 se presento como es la topologıa y el funcionamiento de una Red Movil Urba-na. Teniendo en cuenta las caracterısticas de una red de este tipo y las cuestiones administrativasde la comunidad que la mantiene es que se va a disenar un esquema de seguridad para dichasredes.

7.1. Esquema de Seguridad

Un esquema de seguridad son combinaciones de primitivas (operaciones matematicas basi-cas) combinadas con metodos adicionales [22]. Los esquemas proveen seguridad teorica y esta esmejorada cuando es aplicada apropiadamente en un protocolo para poder cumplir con las ca-racterısticas de seguridad enumeradas en el Capıtulo 4. Es decir, todos los elementos auxiliarespara que un nodo, por ejemplo, pueda encriptar el trafico, autenticarse con el nodo remoto yestar seguro que el nodo remoto es al que se le quiere enviar la informacion. Para lograr esto esnecesario disenar y establecer un esquema de seguridad que especifique claramente los roles quetienen cada uno de los elementos que lo componen y de que manera se relacionan.

79

7.2. Fundamentos del Diseno

7.2. Fundamentos del Diseno

El diseno del esquema de seguridad utiliza la topologıa de una Red Movil Urbana y a la vezla forma de organizacion de la comunidad que la conduce.

Con lo que respecta a la topologıa de la red se tiene en cuenta que en una Red Movil Urbanase cuenta con un numero de nodos fijos, los cuales garantizan la intercomunicacion de los nodosque a nivel de tierra no pueden hacerlo debido a que la tecnologıa utilizada para la comunicacion(IEEE 802.11x) necesita linea de vision directa con el otro extremo del vınculo.

Estos nodos tienen un rol importante dentro de la red y deben estar dados de alta y ser recono-cidos por la Comunidad y haberles asignado una IP, un rango de IPs para poder brindar servicioy un ESSID (nombre de red) estandarizado dentro de la Comunidad. Este aspecto organizativoes el que se tiene en cuenta en el diseno del esquema.

El esquema de seguridad propuesto tiene como objetivo hacer una Red Movil Urbana Seguray para ello se necesita un protocolo de ruteo que sea seguro. Para cumplir con este requisito sevan a definir tres niveles o etapas de securizacion del protocolo. La primer etapa tiene en cuentabrindar los servicios basicos que debe tener una red segura como se describio en el Capıtulo 4. Lasegunda etapa tiene por objetivo mejorar las capacidades de defensa ante los ataques mas comunes(Sec. 6.6) y por ultimo la tercer etapa en la cual la red pueda ser capaz de autodefenderse anteun ataque.

Para lograr los objetivos de esquema de seguridad se plantea el uso de un esquema de clavepublica y privada, distribuidas por medio de certificados. Cada cliente de la red necesitara uncertificado para poder comunicarse. Ese certificado es expedido por una Autoridad Certificante(CA) perteneciente a la red.

El uso de un esquema de clave publica y privada es el pilar sobre el cual se va a basarla implementacion de un protocolo seguro para garantizar la seguridad de la primera etapa desecurizacion.

Un elemento importante a la hora de describir la tercera etapa de seguridad es un Sistemade Deteccion de Intrusos (Intrusion Detection System - IDS ) que es responsable de monitorearel comportamiento de los integrantes de la red. Este componente se basa en reglas de comporta-miento que son establecidas por el administrador o auto-aprendizaje. En caso que un miembrode la red tenga un comportamiento indebido, el IDS envıa dicha informacion a la AutoridadCertificante y se deniega su participacion en la red revocando su certificado.

Los componentes (CA, IDS) deben correr en nodos que la Comunidad establece como con-fiables. No siempre el IDS y la CA deben correr en el mismo nodo pero sı los nodos deben serseguros.

7.2.1. OLSR mas Fuerte

El corazon del diseno de una red movil segura es contar con un protocolo de ruteo confiabley seguro. Para ello y como se mencionaba antes se va tratar la seguridad del mismo por etapaso niveles de seguridad. El fortalecimiento de OLSR toma como punto de partida el esquemade certificacion que le va a proveer certificados para asegurar el canal de comunicacion entre


Diseno de un Esquema de Seguridad para una Red Movil OLSR Urbana

Figura 7.1: Componentes participantes en el esquema de seguridad propuesto

los nodos. En la segunda etapa el protocolo original es modificado para prevenir los ataquesmas comunes (timestamp attack, wormhole attack, DoS, etc). Por ultimo se propone un tercernivel de seguridad, en el cual la misma red se defiende de los intrusos. Este nivel sera descriptobrevemente y queda fuera del alcance de la presente tesis.

7.3. Esquema de Clave Publica y Privada

Como componente principal se busca lograr la autenticacion de cada uno de los nodos parapoder confiar y estar seguro que son nodos pertenecientes a la red. Para ello se utilizara unesquema de clave publica y privada mediante el uso de certificados digitales.

7.3.1. Autoridad Certificante

Como se enunciaba en la Sec 3.1.6 una Autoridad Certificante es un componente de PKI(Public Key Infreatructure) encargada de otorgar y revocar certificados digitales.

El rol de la CA dentro de la infraestructura es validar la autenticidad de claves publicas. Elproceso de generacion de claves comienza cuando un miembro genera un par de claves y solicitaa la CA que firme su clave publica, la CA genera un certificado incluyendo la clave publica de lasolicitud y firma este certificado con su clave privada. De esta manera cualquier nodo que tenga laclave publica de la CA puede estar seguro que la clave publica recibida de otro nodo es confiable.

Tıpicamente una CA es unica en la red y esto puede hacer que nodos no lleguen a esta debidoa interrupciones temporales de enlaces u otras cuestiones propias de la topologıa de las redesmoviles.

7.3.2. Esquema de Certificacion

El esquema de seguridad planteado tiene como punto de partida la utilizacion de certificadosdigitales para autenticar las partes. Para ellos va a existir una Autoridad Certificante pertene-ciente a la comunidad (por ejemplo Buenos Aires Libre).

Cada nodo que participa en la red, debe solicitar a la comunidad una serie de datos parapoder operar en la misma (IP para el nodo, rango de IPs para asignar a sus clientes, un SSID


7.3.2. Esquema de Certificacion

estandarizado). La comunidad enrola a este nuevo nodo, registra el nodo a la red, le da la infor-macion requerida y en conjunto con los datos solicitados se le da un certificado firmado por laCA de la comunidad. Por ser un nodo enrolado, y la comunidad “conoce” al dueno del nodo, esconsiderado “seguro”.

De esta manera el nodo con el certificado expedido por la CA de la comunidad va a poderfirmar requerimientos de certificados de los clientes que se conecten a el (Figura 7.2).

Figura 7.2: Esquema de Certificacion. CA de la comunidad expide certificados a los nodos enrolados yestos expiden certificados 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 disponiblesordenados por proximidad.

En la Figura 7.3 se representa un ejemplo practico donde se puede representar la interaccionde los nodos fijos, los nodos enrolados y los nodos moviles. Puede ser un campeonato de juegosen red a realizarse en todas las plazas de la Capital Federal. El propietario de un nodo enroladose moviliza con el mismo hasta la plaza mas cercana y aun tiene lınea de vision con algun nodofijo de la red para garantizar la conectividad hacia el backbound de la red. Los participantes quese acercan a su plaza mas cercana para participar del torneo van a ser clientes moviles que porprimera vez se van a conectar a la red, por lo tanto solicitaran un certificado al nodo enrolado mascercano para poder participar en el torneo. Cabe aclarar que toda la negociacion de certificadosy gestiones para que el cliente acceda a la red son transparentes al cliente, el protocolo es elencargado de la tarea. Una vez que este nuevo cliente ingresa a la red podra acceder al servidorde juegos que se encuentra a miles de metros al cual accede primero routeando a traves de losnodos cercanos en la plaza hasta llegar al nodo enrolado que se movilizo hasta la misma, el cualle provee acceso al backbound de nodos interconectados fijos hasta llegar al servidor de juegos.



Figura 7.3: Ejemplo de utilizacion de una red Movil Urbana Segura interconectando distintas plazas

7.4. Fortalecimiento de OLSR

Para poder lograr implementar el esquema de seguridad propuesto sobre el protocolo OLSR,sera necesario realizar cambios al protocolo [5]. Estos cambios no solo son cambios agregandoinformacion de las CA en los mensajes del protocolo sino que se firmaran los mensajes crıticos(HELLO, TC, MID, HNA) implementando lo expuesto en [21]. En [21] Hafslund y Tonnesen pro-ponen firmar los mensajes con una clave compartida, pero en el esquema propuesto se firmara conuna clave que se intercambia durante el proceso de autenticacion y luego son encriptados con unaclave de sesion generada entre las partes para garantizar autenticacion, integridad y confidencia-lidad.

7.4.1. Prevencion de Ataques

Con la firma de los mensajes se puede garantizar la integridad del mismo.

Con la encriptacion del mensaje con una clave de sesion negociada previa autenticacion delas partes, se garantiza la confidencialidad y no repudio.

Con el agregado de un algoritmo de timestamp se previene la retransmision de mensajesviejos.

Con un algoritmo heurıstico se puede inferir si el mensaje proviene de un nodo vecino o deuno lejano a traves de un tunel (prevencion de wormhole attack).

Se implementaran tecnicas para prevenir ataques de DoS y ataques que hagan realizar alnodo desgaste de energıa en el procesamiento de mensajes maliciosos.


7.5. Integracion del IDS y la CA

En el Capıtulo 9 se dara el detalle de la implementacion de todos los puntos antes mencionados.

7.5. Integracion del IDS y la CA

La comunicacion entre las CAs y los IDS se realiza de la misma manera que entre cualquiernodo. Primero se autentican uno con otro y se establece una clave se sesion y se encripta eltrafico. La interaccion de los IDSs con la CAs es mediante mensajes especıficos para informarcomportamientos de los nodos.

7.6. Interaccion de los Nodos Clientes con Esquema de Se-

guridad Planteado

En esta seccion se hara referencia a como un nodo se integra a la red. Como pre-requisito, aligual de cuando se navega por sitios seguros de Internet, el nodo cliente debe conocer de antemanola clave publica de la CA de la comunidad.

El primer paso que realiza el cliente es generar su propio par de claves. Segundo, inicializa elproceso de descubrimiento de vecinos (ya pertenecientes a la red). Durante dicho procedimientorecolectara informacion de los vecinos y a la vez de las CA mas cercanas. Una vez que conocecuales son la CAs, envıa un requerimiento de un certificado a la CA mas cercana para poderoperar en la red. Recibido el certificado, valida que este en la cadena de certificacion la CA dela comunidad y toma el certificado como valido y comienza una ronda de autenticacion con susvecinos. En la ronda de autenticacion se establece la clave se sesion entre cada par de nodos paracifrar los mensajes y se intercambian de manera segura los parametros de inicializacion para elalgoritmo de timestamp. Finalmente, cuando se autentican los vecinos, el nodo pasa a ser un nodoconfiable en la red salvo que detecte un comportamiento anomalo y sea excluido de la red.

Mientras que el nodo no se encuentre autenticado por otro nodo, este permanecera en estadono seguro y no participara en la eleccion de MPR ni se le aceptaran mensajes distintos a losmensajes de HELLO.

7.6.1. Esquema de confianza ganada

El esquema de “ganar” confianza se basa en el comportamiento del nodo en la red. Cuandoun nodo ingresa por primera vez a la red, se le asigna un certificado por un perıodo de tiempocorto, cuando ese certificado este por expirar, se vuelve a generar un nuevo pedido. La CA analizael comportamiento del nodo con la ayuda de los IDSs y si no tuvo comportamientos malos sele asigna un certificado con un tiempo de expiracion mas largo. Este procedimiento se repiteconstantemente pero vale aclarar que un nodo cliente de la red no puede convertirse en CA si nose enrola en la comunidad como tal.



7.7. Resumen

En este capıtulo se presento cual es el diseno del esquema de seguridad propuesto a nivelmacro y sin dar mayores detalles, solo se introdujo cuales serıan los actores involucrados y querol tiene cada uno dentro del esquema. En el Capıtulo 9 se daran los detalles de lo planteado enel presente capıtulo.


7.7. Resumen


Capıtulo 8

Artıculos mas Relevantes

Relacionados con la Seguridad de

OLSR

El objetivo de este capıtulo es realizar un resumen de los principales artıculosleıdos para el desarrollo de la presente tesis, los cuales fueron las principales fuentesde informacion e inspiracion para la creacion del Esquema de Seguridad para unaRed Movil Urbana basada en OLSR .

Las redes moviles hace anos que son objeto de estudio en todo el mundo, como parte de estasinvestigaciones, nunca queda de lado temas referentes a la seguridad, ya que por la tecnologıa yla naturaleza de este tipo de redes, los miembros de la misma se encuentran expuesto a ataquescontinuamente. Como se detallo en el Capıtulo 2, existen diferentes tipos de protolocolos de ruteo,los cuales en su mayorıa no preveen cuestiones de seguridad. En el Capıtulo 4 se detallaron losprincipales protocolos de ruteo seguros. Dentro de los protocolos disponibles, para el desarrollo deesta tesis se eligio el protocolo OLSR, el cual como se dijo en varias oportunidades no es seguropero es el mas popular en las redes moviles urbanas.

La seguridad del protocolo OLSR tambien ha inquietado a distintas personas y laboratoriosde investigacion en todo el mundo y han propuesto distintas alternativas de securizacion, lascuales fueron pilares para la elaboracion de la presente tesis.

Los principales trabajos sobre el tema son: Secure Extension to the OLSR protocol [21], SecureOLSR [18], Securing the OLSR protocol [30].

87

8.1. Secure Extension to the OLSR protocol

8.1. Secure Extension to the OLSR protocol

8.1.1. Overview

Este artıculo, que fue escrito por los implementadores del protocolo OLSR, propone unaextension del mismo asegurando la integridad y autententicando los mensajes.

Los autores asumen que cada nodo conoce una clave compartida con la cual autenticaran lospaquetes. La solucion propuesta es utilizar una firma por paquete OLSR y la solucion brindapaquetes firmados salto-a-salto y no una solucion de firmado de punta a punta. El fundamentode esta tecnica es que los paquetes son reenviados a traves de nodos seguros, con lo cual eldestinatario recibe un paquete firmado por el nodo anterior que no es el originador del mismo,pero este nodo previo confıa en el nodo que le reenvio el mensaje y ası sucesivamente.

Los nodos que no conozcan la clave compartida no podran verificar ni generar una firmaverificable.

8.1.2. Firma

Para generar la firma del paquete OLSR, se crea un nuevo mensaje, el cual se puede ver eldetalle en la Figura 8.1 y el ultimo mensaje del paquete OLSR. Como se puede entender, existeun mensaje de firma 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 firma basico

En el mensaje de firma se especifica que esquema de firma se esta usando y que algoritmo.Luego una marca de tiempo para prevenir ataque de reenvıo de paquetes (se explica mas adelante)y por ultimo una firma del paquete utilizando SHA-1. En realidad, no es una firma digital comose definio en el Capıtulo 3, lo que llama firma es un MAC donde usa como clave el timestamp.

Con el agregado de este mensaje, la longitud del paquete debe ser recalculada agregando allongitud del mensaje de firma.

8.1.3. Timestamps

La extension propuesta en el artıculo incluye la generacion de timestamps por cada paquetepara prevenir el reenvıo del mismo paquete en otro instante. Para calcular el timestamp se realizaun 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 mas Relevantes Relacionados con la Seguridad de OLSR

1. A → B : Cha, D(M,K)

2. B → A : Chb, T sb, D(IPb, Cha,K), D(M,K)

3. A → B : Tsa, D(IPa, Chb,K), D(M,K)

Cuando A recibe un mensaje firmado de B del cual no tiene registro de su reloj, envıa unmensaje de desafıo hacia B. El mensaje tiene como destino la IP de B, un numero aleatorio Cha

y el resumen del mensaje utilizando la clave compartida K (D(M,K)).B responde con un mensaje de respuesta de desafıo el cual tiene un numero aleatorio Chb, el

reloj de B, un resumen de la IP de B, el numero al azar generado por A y la clave. Por ultimoun resumen criptografico del mensaje generado con la clave compartida K.

Cuando A recibe la respuesta valida el resumen D(IPb, Cha,K) y D(M,K), si son correctasutiliza el reloj enviado por B. Por ultimo A envıa una respuesta a B similar a la enviada por B

y luego B valida las firmas y si con validas utiliza el reloj enviado por 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 calculo. El nodo receptor extrae el timestampdel paquete y calcula la diferencia con su reloj calculando TN = Tlocal −Tpaquete. A continuacionevalua T0 − S < TN y T0 + S > TN , donde T0 es la diferencia horaria almacenada. En caso quela validacion del timestamp sea correcta se procesa el mensaje, en caso contrario se descarta.

Para compensar algun desfasaje de los relojes, se realiza un ajuste de T0 calculando el promedioentre la diferencia horaria almacenada y la calculada para este paquete (T0 = (T0 + TN )/2).

8.2. Secure OLSR

8.2.1. Overview

En este artıculo se propone un mecanismo de deteccion de vecinos seguros teniendo en cuen-ta la posibilidad de ataque de tunel durante el descubrimiento. Una vez que los vecinos sondescubiertos se ingresa en una ronda de autenticacion de los mismos. Conocidos los vecinos yautenticados se comienzan a enviar paquetes de control, se propone un mecanismos de firma paralos mensajes de control ası se puede garantizar la integridad de los mismos.

El artıculo asume que cada nodo tiene un par de claves publica/privada expedida por algunaentidad, no se detalla cual es el mecanismo por el cual se garantiza la identidad de la clave publica.

8.2.2. Deteccion segura de vecino

Durante la etapa de descubrimiento de vecinos se puede ser objetivo de un ataque de tunel(wormhole attack), por lo tanto los autores proponen una forma heurıstica de determinar si elmensaje 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 lavelocidad de propagacion de un paquete es cercana a la velocidad de la luz, entonces la distanciarecorrida por el paquete es de L = t × c, al mismo tiempo se calcula que una placa de red de un


8.2.3. Autenticacion de vecinos

dispositivo movil tiene un radio de cobertura R (por ejemplo 100 metros), por lo tanto si L > R

entonces se esta en presencia de ataque y si L ≤ R no.La forma propuesta para implementar este mecanismo de defensa es la siguiente:

1. B envıa un mensaje de prueba a A e inicializa un contador.

2. Cuando A recibe el mensaje de prueba, envıa la respuesta e inmediatamente inicia uncontador.

3. Una vez que B recibe la respuesta de A, detiene el contador y envıa una respuesta a A. B

calcula el 4tb. La distancia S entre A y B es de (4tb/2) × c. Si S > R, B no inserta a A

como vecino, en caso contrario prosigue con el mecanismo de autenticacion.

4. Cuando A recibe la respuesta de B realiza el mismo calculo y toma las mismas decisionesque el punto anterior.

8.2.3. Autenticacion de vecinos

Una vez superada la etapa de deteccion de vecino, el nodo debe realizar una ronda de auten-ticacion. El mecanismo de autenticacion es por medio de un intercambio de mensajes.

1. A genera un paquete que contiene un numero al azar (RA), el certificado de A (CertA), losidentificadores de A y B, y un hash encriptado con clave privada de A (firma).

A → B : A, B,CertA, RA, sign(H(A,B,CertA, RA))

Donde H() es una funcion hash y sign() es una operacion de firma.

2. Cuando B recibe el paquete, primero verifica el certificado de A, luego extrae la clavepublica de A y verifica la firma del paquete. Una vez hecho esto, B envıa un paquete quecontiene un numero al azar grande (RB), el certificado de B, los identificadores del A y B

y un hash encriptado con la clave privada de B (firma).

B → A : B,A,CertB , RB , sign(H(B,A,CertB , RA, RB))

3. Cuando A recibe la respuesta de B, verifica si el certificado de B es valido, verifica la firma.Terminada esta etapa A confıa que B es un vecino seguro. A envıa un ultimo mensaje a B.

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 relacionde confianza con el vecino



Figura 8.2: Pasos para lograr una relacion de confianza con un vecino

8.2.4. Paquetes de Ruteo Seguros

OLSR utiliza un solo paquete para comunicar todos los tipos de mensajes. Este tiene una seriede campos que son modificables durante la propagacion del mismo y otros no. Para garantizar laintegridad de los campos que no deben cambiar durante la propagacion, se utiliza un algoritmode firma y para los campos variables se utiliza cadena de hash para securizar Hop Count y TTL.

La extension al paquete OLSR es la que se muestra en la Figura 8.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

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Hash_Hop |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Seed |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Signature |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figura 8.3: Extension del paquete OLSR

Cuando un nodo genera un nuevo paquete realiza los siguientes pasos:

Genera un numero aleatorio Seed.

Hash Hop = HTTL(Seed). donde H() es una funcion de hash.

signature = sign(campos estaticos)

Cada vez que un nodo recibe un paquete realiza las siguientes operaciones:

Primero se calcula HTTL−Hop Count(Seed), si el valor es igual a Hash Hop del paquete, severifica la firma, si es correcto se sigue con el proximo paso.

TTL = TTL − 1; HopCount = Hop Count + 1; Seed = H(Seed)


8.3. Securing the OLSR protocol

8.3. Securing the OLSR protocol

8.3.1. Overview

En este artıculo se presenta un framework que permite securizar el protocolo OLSR de lossiguientes ataques:

Generacion Incorrecta de Trafico de Control

Generacion de Mensajes de HELLO Incorrecta

Generacion de Mensajes de TC Incorrecta

Reenvıo de Trafico de Control Incorrecto

En el desarrollo de la solucion se asume que el comportamiento de un nodo seguro no se alteray mantiene su buena conducta en la red. La informacion de control generada por este tipo denodos es la que se conserva ıntegra.

Para lograr esto, se proponen requerimientos criptograficos como:

Una funcion que permita retornar la firma de un mensaje, por ejemplo sign(nodeid, key,

message).

Una funcion que permita verificar la firma, por ejemplo verif(originatorid, key,

message, signature).

Una clave compartida para poder firmar y validar la firma

8.3.2. Firma de Mensajes

Con los elementos descriptos, el nodo que genera un mensaje de control genera un mensaje defirma, el cual es enviado uno por cada mensaje generado (pueden generarse varios mensajes defirma para un paquete OLSR). Este mensaje de firma se envıa de forma independiente al mensajede control, con lo cual el nodo que recibe el mensaje de control no lo acepta hasta no recibir elmensaje de firma correspondiente al mensaje.

El mensaje de firma se puede ver en la Figura 8.4. Este es enviado en la porcion de datos delpaquete general de OLSR con el “Message Type” SIGNATURE MESSAGE. Para poder determinara que mensaje corresponde la firma, el mensaje de firma tiene un numero (MSN Referrer) quees el numero de secuencia del mensaje de control. En el campo Sign Method, se especifica quealgoritmos se van a utilizar para realizar el hash, que metodo de timestamping se va a utilizar einformacion sobre la clave utilizada.

Para calcular la firma del mensaje de control, se ignoran los campos del mensaje que puedenvariar durante la vida del mensaje (TTL y Hop Count) tomandolos como cero. En este esquemade firma se genera una autenticacion y validacion del mensaje de punta a punta.



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 firma

8.3.3. Timestamping

En el mismo artıculo, en la seccion V, se presentan distintos algoritmos de timestamping paraprevenir ataques de reenvıo de paquetes. Los diferentes tipos de algoritmos propuestos son:

No timestamp: Si se quiere no se utiliza esta proteccion y se pone un valor igual a cero

Real-time timestamp: Se toma el reloj de cada nodo, pero requiere algun mecanismo desincronismo de relojes entre los nodos

Non-volatile timestamp: Este algoritmo exige que cada nodo mantenga en memoria novolatil los relojes de cada uno de los nodos de la red, cada una de esas entradas es inicializadacuando recibe el primer mensaje. Mientras que el nodo emisor mantiene una tabla con todoslos relojes de los nodos de la red, el receptor tiene una tabla con todos los valores maximosde timestamp recibido de cada nodo. El emisor utiliza un valor de reloj de la tabla y luegolo incrementa.

Timestamp Exchange Protocol : Este mas que un algoritmo es un protocolo de intercambio derelojes, por medio del cual se generan mensajes con desafıos encriptados. Para el intercambiode mensajes se utilizara la notacion X → Y : {Z}SX , que significa que X envıa un mensajeZ 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 seccion IV, se proponen dos esquemas de PKI para redes moviles, uno esproactivo 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 confiables, Nodos Confiables, Auto-ridades Firmantes. Un nodo no es confiable si la clave publica de x no es conocida por a o sila clave publica de x es conocida pero no esta firmada por la Autoridad Firmante. Un nodo esconfiable si la clave publica de x es conocida por a y a la vez esta firmada por la AutoridadFirmante. La Autoridad Firmante es un nodo de la red que es conocido por todos los otros nodosy tiene la capacidad de registrar claves publicas para nuevos nodos. La Autoridad Firmante envıaperiodicamente un listado de las claves de los ”nodos confiables”.

Cada nodo que quiera participar en la red debera registrar su clave publica en la AutoridadFirmante, esta periodicamente distribuye el listado de claves. Cada nodo almacena las claveshasta que expiran. Este mecanismo requiere que las claves sean renovadas periodicamente.

Cuando la red se inicializa, ningun nodo conoce ninguna clave de la red, salvo la de la Auto-ridad Firmante, por lo tanto todos los nodos van a ignorar los mensajes de control de los otrosnodos, ningun nodo va a ser elegido como MPR y ningun mensaje broadcast va a ser reenviado.Todos los nodos tienen que esperar que la Autoridad Firmante comience a emitir mensajes conlas claves.

Durante la inicializacion de la red, la Autoridad Firmante envıa su certificado a todos losvecinos de un salto de distancia, seguido realiza un intercambio de mensajes de HELLO, los vecinosde un salto de distancia aceptan a los vecinos de dos saltos como simetricos pero no los eligencomo MPRs. La Autoridad Firmante elige MPRs entre los vecinos de un salto y ası el proximobroadcast de claves llega a los vecinos de dos saltos de distancia. Ası continua inundando la redpara que todos los nodos conozcan las claves publicas de los nodos confiables.

Todos los nodos deben mantener tablas con la informacion de claves de sus vecinos y si sonconfiables o no.

No se prevee un esquema de revocacion de claves.

8.3.4.2. PKI Reactiva Simple para OLSR

A diferencia del esquema PKI proactivo, en este cuando un nodo requiere una clave, la solicitaa 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 unnumero aleatorio, la identificacion del nodo y una lista de todas la claves solicitadas. El mensajees 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 firma del mensaje de A (si tiene la clave publica de A), yluego arma el mensaje de respuesta con el listado de claves publicas que conoce. P → all :{P,A,NA, (Bi1 , PKBi1

), ..., (Bim , PKBim)}SP

Cuando A recibe la respuesta, valida que el A sea realmente el destinatario del mensaje, queP sea a una Autoridad Firmante conocida, que la firma del mensaje sea correcta y que el NA seavalido.

La retransmision de los mensajes de solicitud y respuesta de claves se realizan mediante elmecanismo de inundacion convencional, por ejemplo si un nodo recibe un mensaje, lo reenvıa una



sola vez.

8.4. Resumen

En este capıtulo se resumieron distintos artıculos los cuales plantean distintas alternativas desecurizacion para el protocolo OLSR. Las soluciones aportadas por estos fueron utilizadas parael desarrollo de la presente tesis adaptandolas a las necesidades del protocolo propuesto.


8.4. Resumen


Capıtulo 9

Detalles de Implementacion del

Esquema de Seguridad Propuesto

En este capıtulo se dara un detalle de lo propuesto en el Capıtulo 7, llegando aprofundizar cuestiones relacionadas al protocolo OLSR como a los aspectos organiza-cionales de las comunidades de llevan adelante los proyectos de redes moviles urbanas.

Luego de la presentacion del esquema de seguridad planteado para una red movil urbana enel Capıtulo 7, en este capıtulo se dara los detalles de todos los puntos propuestos para lograr unared movil segura.

Se analizaran los detalles tanto organizativos que la comunidad debe realizar antes de dar dealta un nodo fijo en la red como ası las piezas de protocolo necesarias para que interactuen loselementos involucrados en el esquema.

Los elementos principales necesarios para la implementacion del esquema de seguridad pro-puesto son: Autoridad Certificante, el protocolo de ruteo, los clientes de la Red y el Sistema deDeteccion de Intrusos. El analisis de la implementacion del IDS, no es el objetivo del presentecapıtulo ni de la Tesis.

Se trataran en detalle los mecanismos organizativos de la comunidad a la hora de registrarun nodo como CA, con respecto al protocolo de ruteo se definiran tres niveles de securizacionde los cuales se hara un detalle minucioso de los dos primeros y el tercero se plantea como unaextension y es objeto de estudio futuro.

9.1. Esquema de Certificacion

Tal como se adelanto en el Capıtulo 7, uno de los principales componentes del esquemapropuesto es la existencia de certificados digitales para autenticar a los nodos pertenecientes ala red. Esto se logra teniendo una entidad responsable de emitir certificados garantizando que el

97

9.2. Fortalecimiento del Protocolo OLSR

nodo portador del mismo es confiable.

La comunidad va a tener un unico certificado con el cual va a firmar certificados para losnodos fijos de la red que se enrolen.

9.1.0.3. Procedimiento para la registracion de un nodo

La asignacion de certificados es una tarea de la comunidad que administra la red. Si unapersona tiene un nodo y quiere participar de la comunidad, esta necesitara darse de alta en lacomunidad para que se le asigne una IP para su nodo perteneciente al backbone de la red, unrango de IPs para asignar a los nodos clientes que se unan a la red a traves de el y un ESSIDestandarizado (opcional). Si el propietario del nodo va a participar activamente en la red, es decir,su nodo una vez configurado va a estar disponible sin interrupciones de servicio prolongadas,puede solicitar ser CA para poder firmar certificados para sus clientes. La Comunidad conocea los propietarios de los nodos porque en general tienen una participacion activa en los foros,listas de correos y reuniones organizativas, con lo cual se esta seguro cuales son los fines del nodosolicitante y se puede asumir que es un nodo seguro.

El objetivo cuando la red no tiene muchos nodos fijos es que todos los nodos fijos sean CAspara minimizar el trafico de backbone solicitando certificados a otros nodos de la red. Hoy en dıa,por ejemplo Buenos Aires Libre no cuenta con la cantidad de nodos suficiente como para que unnodo cliente pueda ver dos o mas nodos fijos y ası tener la posibilidad de que haya nodos fijosque no sean CAs. Por esto es que es necesario que todos los nodos fijos asuman la responsabilidadde ser CA.

9.2. Fortalecimiento del Protocolo OLSR

El protocolo OLSR como se vio en el Capıtulo 6 no dispone de ninguna prevencion contralos posibles ataques vistos en la Seccion 6.6, por lo tanto como parte del esquema de seguridadpropuesto no se puede dejar de lado la seguridad del protocolo de ruteo. Por eso es que en eldiseno se separo el fortalecimiento de OLSR en distintos niveles.

En el primer nivel se detallaran las modificaciones del protocolo para garantizar los servi-cios basicos que debe ofrecer una red segura: Disponibilidad, Confidencialidad, Autenticacion,Integridad y No Repudio ( [15]).

En el segundo nivel se realizaran las modificaciones al protocolo para mitigar las vulnerabili-dades mas crıticas que presenta el protocolo.

Por ultimo en el tercer nivel se tratara como podrıa funcionar el esquema propuesto para quela red tenga un mecanismo de autodefensa.

Los mensajes del protoloco original [5] van a ser los mismos (HELLO, TC, HNA y MID) y se leagregaran una serie de mensajes propios de la solucion propuesta, los cuales seran detallados enlas siguientes secciones.


Detalles de Implementacion del Esquema de Seguridad Propuesto

9.3. Fortalecimiento de OLSR: Nivel 1

A lo largo de esta seccion se detallaran todos los componentes, las interacciones y los mensajesnecesarios para hacer que OLSR garantice los servicios basicos de seguridad. Para garantizar estosservicios es necesario introducir modificaciones a las tablas originales del protocolo, a los mensajesy los mecanismos y formas de comunicacion. En esta seccion se especificaran las modificacionesa las distintas etapas del protocolo original: Deteccion de Vecinos, Descubrimiento de la Red yArmado de la Tabla de Ruteo.

9.3.1. Tablas del Protocolo

En la Seccion 6.3 se detallaron cuales son las tablas que utiliza el protocolo OLSR segun suRFC. En esta propuesta de fortalecimiento del protocolo, se modificaran las tablas existentes.

La tabla Neighbor Set quedara conformada por la tupla {N neighbor main addr, N status,N willingness, N trusted, N cert, N sessionKey, N deltaTimestamp, N localKey, N remoteKey,N neighbor trust level, N CA}

N neighbor main addr: Direccion principal del nodo vecino.N status: Especifica si el nodo esta en estado SYM=enlace simetrico o NOT SYM=enlaceno simetrico.N willingness: Es un entero entre 0 y 7 y especifica la confianza que se le tiene alnodo vecino para llevar el trafico.N trusted: Indica si el vecino es confiable o noN cert: Se almacena el certificado del vecinoN sessionKey: Se almacena la clave de sesion generadaN deltaTimestamp: Se almacena la diferencia entre el reloj local y el reloj del vecino.Esta columna sera usada para mitigar ataques de reenvıo de paquetesN localKey: Durante el proceso de autenticacion se genera una clave local para firmarlos mensajesN remoteKey: Durante el proceso de autenticacion el nodo remoto genera una clavecon la cual firmara sus mensajesN neighbor trust level: Indica el nivel confianza que la CA le dio al nodo vecino(informacion incluida en el certificado)N CA: Indica si el vecino es CA o no

La tabla Topology Information : quedara conformada por las tuplas {T dest addr,T last addr, T seq, T CA, T time}

T dest addr: Direccion principal del nodo destino que es alcanzado en un salto porel nodo con direccion principal T last addr.T last addr: Es MPR de T dest addr.T seq: Numero de secuencia.T CA: Indica si el nodo es CA o noT time: Tiempo de expiracion de la tupla.


9.3.2. Obtencion del Certificado


El nodo que ingresa a la red lo primero que hace es intentar obtener un certificado para poderautenticarse con sus vecinos. El proceso de obtencion del certificado comienza con la emisionde un nuevo mensaje llamado CADISCOVER. Los vecinos que reciban este mensaje devolveran elmensaje adjuntando al mismo el listado de CAs que tiene cada uno y la cantidad de saltos quetiene hasta llegar a esta.

9.3.2.1. Generacion del mensaje CADISCOVER

El nodo que desea participar en la red genera un mensaje como el que se muestra en laFigura 9.1 y lo incorpora en el paquete OLSR con tipo de mensaje CADISCOVER. El cuerpo delmensaje va a ser vacıo, es decir no se especificara direccion de destino ni listado de CAs.

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 informa-cion de la Tabla de Topologıa de la cual obtiene cuales son los nodos CAs y de la Tabla de Rutasde la cual obtiene el numero de saltos hacia el destino.

Para armar el mensaje de respuesta, se coloca en el destino del mensaje la direccion del nodoque realizo la peticion. Luego completa el mensaje incorporando el listado de las CAs conocidasagrupandolas por cantidad de saltos.

Los nodos solo generaran respuestas cuando los mensaje recibidos no contengan una direccionde destino y el listado de CAs esten vacıos. Un mensaje que cumple con estas condiciones esconsiderado una peticion.

Cuando un nodo recibe un mensaje considerado peticion realiza lo siguiente:

Actualiza la tabla de vecinos (Neighbor Set)



Confecciona el mensaje de respuesta.

Envıa el mensaje generado

Cuando un nodo recibe un mensaje que tiene una direccion de destino, verifica que dichadireccion le corresponda. En el caso que el nodo no sea destino del mensaje, este es desechado.En caso contrario se procede de la siguiente manera:

Se actualiza la tabla de vecinos (Neighbor Set)

Por cada direccion agrupada bajo cada cantidad de saltos se agrega una entrada en la tablade rutas colocando como R dest addr la direccion de la CA, como R next addr la direcciondel nodo de donde provino la respuesta, R dist igual a la cantidad de saltos y finalmentela R iface addr la direccion de la interfaz por la que recibio la respuesta.

Esta generacion de la tabla de rutas no es igual a la realizada por OLSR, pero es necesariagenerarla 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. Generacion del CERTREQ

El nodo que pretende obtener un certificado, genera un nuevo mensaje de tipo CERTREQ quees enviado en forma segura a la CA elegida por menor distancia. El formato de este mensaje sepuede ver en la Figura 9.2

Los nodos vecinos solo reenviaran de un nodo no confiable (no autenticado) mensajes condestino a una CA. Un nodo siempre va a conocer que el destino es una CA ya que este nodo ledijo al nodo que genera el mensaje que el sabıa como llegar a una CA y con cuantos saltos.

Para generar el mensaje, el nodo genera su propio par de claves y crea un requerimiento decertificado (CertReqMessage [27]). Para enviar la solicitud a la CA mas cercana debe hacerlo de



forma segura segun lo especifica el RFC 2511 de X.509[27, Sec. 2]. Para cumplir con la norma,se establece una conexion SSL [28] con la CA. Como el nodo cliente conoce el certificado de larootCA de la comunidad, verifica que el certificado presentado por la CA a la hora de establecerla sesion SSL este firmado por la rootCA. De esta manera el nodo cliente se asegura que seesta conectando a una CA segura. Cabe aclarar en este punto que solo es necesario que el nodoque intenta obtener un certificado sea el unico que verifique la identidad de la CA ya que noes necesario que la CA valide la identidad del nodo porque el proposito de este mecanismo esobtener una identidad temporal para un nodo anonimo.

Una vez establecido un canal seguro, el nodo crea un mensaje CERTREQ donde incluye elmensaje CertReqMessage de X509 definido en la Seccion 3 del RFC 2511 (Figura 9.2) y se loenvıa a la CA.

Un nodo cuenta con mas de una CA, en caso que existan, con lo cual comienza intentandoenviar el mensaje CERTREQ a la CA mas cercana y luego a las mas alejadas. Con esta caracterısticase gana disponibilidad de las CAs ya que sin la obtencion del certificado, el nodo nunca sera partede la red.

9.3.2.4. Generacion del Certificado

Como se menciono anteriormente una CA tiene un certificado expedido por la rootCA dela comunidad. Una vez que el nodo cliente establece una conexion segura con la CA, envıa elmensaje solicitando un certificado. La CA consulta en su CRL si este nodo esta presente. En casoque no este en la CRL, expide un certificado con una validez temporal.

La validez del primer certificado sera de una hora y el nivel de confianza es de uno. Esenivel de confianza es un parametro que la CA agrega como campo de texto en una extension delcertificado. El nivel de confianza permite a un nodo cambiar su rol de participacion en la red amedida que va ganandola con un buen comportamiento en la red.

Una vez que se tiene el certificado expedido, es enviado al nodo en la misma sesion SSL. Esdecir, el proceso de solicitud de un certificado es sincronico.

La respuesta con el certificado firmado es devuelto en un mensaje de tipo CERTREPLY comose muestra en la Figura 9.3.

9.3.2.5. Renovacion de certificado

Un nodo cuando esta por vencer su certificado debe solicitar una renovacion del mismo.El procedimiento para la renovacion es el mismo que para la solicitud, es decir, establece unaconexion SSL con la CA y envıa el mensaje. En este caso el mensaje que se envıa es de renovacion(tipo CERTRENEW). En el mensaje se envıa el certificado anterior para una renovacion (Figura 9.4).

Los perıodos de expiracion se calculan, de forma arbitraria, duplicando el perıodo de validezdel certificado anterior, es decir V ALIDEZ = V ALIDEZ ∗ 2, tomando como perıodo de validezinicial una hora. Con cada renovacion se gana un nivel mas de confianza. El nivel de confianzapermite a un nodo cambiar su rol de participacion en la red.

Con esta tabulacion de perıodos de validez, una CA puede saber por cuanto tiene que renovarun certificado sin necesidad que el certificado 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 Nivel de Confianza Ganado Valido por (hs)

0 1 1

1 2 2

2 3 4

3 4 8

4 5 16

... ... ...

Cuadro 9.1: Validez del certificado por renovacion

Autoridad puede saber la cantidad de renovaciones haciendo

Nro Renovaciones =ln (fecha expiracion − fecha emision)

ln (2)

y no es necesario que una CA mantenga un contador con la cantidad de certificados expedidospara un nodo.

La CA recibe el certificado y valida que haya sido expedido por una CA autorizada, verificapor cuanto tiempo tiene que ser expedido, incrementa el nivel de confianza, lo genera y se lo envıaal nodo en un mensaje CERTREPLY.

El perıodo de renovacion sera como maximo un ano, o sea cuando el nodo logra obtener uncertificado con una validez de un ano, en cada renovacion recibira un certificado de un ano.

Una vez que se tiene el nuevo certificado expedido, es enviado al nodo en la misma sesionSSL, es decir el proceso de renovacion del certificado es sincronico.

9.3.3. Deteccion de Vecinos

El proceso de deteccion de vecinos sera de la misma manera que se realiza en el protocolooriginal mediante un censado de vecinos. Cuando el nodo se incorpora a la red envıa un mensajede tipo CADISCOVER, cuando los vecinos responden, el nodo actualiza su tabla de enlacess conlos vecinos poniendo el estado del enlace como ASYM LINK y tipo de vecino como NOT NEIGH yno confiable. Los nodos que reciben el mensaje CADISCOVER actualizan su tablas de enlaces conlos vecinos y agregan al nuevo vecino como no confiable y el estado del enlace como ASYM LINK

y tipo de vecino como NOT NEIGH. De esta manera un nodo nunca elegirıa al nuevo nodo como


9.3.3. Deteccion de Vecinos

MPR ya que es condicion que el nodo tenga un enlace simetrico para participar en la eleccion deMPR.

En el procedimiento de censado de vecinos propuesto se incorpora una modificacion mınimaal 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 unnuevo Link Code donde se indica que ese enlace es con un vecino que es CA, es decir es unaextension de la informacion enviada en un mensaje HELLO del protocolo original.

Por ejemplo, si un nodo informa que tiene Link Code con tipo de enlace SYM LINK y tipode vecino MPR NEIGH con un nodo y luego la direccion del nodo esta listada con Link Codecorrespondiente a CA NEIGH, se actualiza la tupla en la tabla de vecinos indicando que el vecinocon el cual se tiene ese enlace es CA.

Un nodo puede informar que el es CA enviando su direccion en el listado de direcciones conLink Code CA NEIGH y cuando un nodo procese este mensaje comparara la direccion de origendel mensaje y la direccion listada como CA NEIGH y actualizara la entrada en la tabla de vecinosindicando 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 queen el protocolo original se usan dos bits para representar cuatro tipo de enlaces y dos bitspara representar tres tipos de vecinos, con lo cual al agregar un nuevo tipo de vecino se puederepresentar con los dos bits destinados para este fin.

9.3.3.1. Autenticacion de los vecinos

Una vez que el nodo obtiene un certificado, comienza el proceso de autenticacion. El nodo enesta etapa ya conoce a sus vecinos los cuales fueron reconocidos en la respuesta al mensaje deHELLO de tipo CADISCOVER. El nodo comienza la autenticacion con cada uno de los vecinos de sulistado de vecinos.

Para intercambiar los parametros de autenticacion se utilizan dos nuevos mensajeAUTH 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



Procedimiento de Autenticacion Para explicar el proceso de autenticacion llamaremos A

al nodo que inicia el proceso y B a la otra parte.

1. A genera un paquete que contiene un numero al azar (RA), el certificado de A (CertA), losidentificadores de A y B, y un hash encriptado con clave privada de A (firma).

A → B : A,B,CertA, RA, sign(H(A,B,CertA, RA))

Donde H() es una funcion hash y sign() es una operacion de firma.

2. Cuando B recibe el paquete, primero verifica el certificado de A si corresponde a un cer-tificado firmado por una CA de confianza, luego extrae la clave publica de A y verifica lafirma del paquete. Una vez hecho esto, B envıa un paquete que contiene un numero al azar(RB), el certificado de B, los identificadores del A y B y un hash encriptado con la claveprivada de B (firma).

B → A : B,A,CertB , RB , sign(H(B,A,CertB , RA, RB))

3. Cuando A recibe la respuesta de B, verifica si el certificado de B es valido y fue firmadopor una CA de la red, verifica la firma. Terminada esta etapa A confıa que B es un vecinoseguro y agrega el certificado, en la tabla de vecinos marcandolo como confiable, actualiza elestado de los enlaces con B como SYM LINK y tipo de vecino SYM NEIGH. A envıa un ultimomensaje 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 |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| |


| |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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, confirma que A es un vecino seguro. Actualiza la tabla devecinos con el certificado de A y marca a A como vecino seguro. Tambien actualiza el estadode los enlaces con A como SYM LINK y tipo de vecino SYM NEIGH.

En este punto un nodo malicioso o mal configurado puede enviar miles de mensajes deautenticacion seguidos, lo cual puede generar una Denegacion de Servicio. En el detalledel proximo nivel de securizacion se detallara cual es la manera de prevenir este tipo decomportamiento.


9.3.4. Firma y encripcion de los mensajes

9.3.3.2. Eleccion de MPR

La eleccion de MPR se realiza de la misma manera que en el protocolo original ya que conla modificacion incorporada, solo se va a lograr tener un enlace simetrico con un vecino luegoque se hayan autenticado. Es de mucha importancia que un MPR sea un nodo autenticado yaque va a ser el punto de ruteo hacia un sector de la red. Si este nodo no es seguro se pondrıaen riesgo el ruteo y la integridad de la red. Como un punto parametrizable para el protocolose puede establecer cual es el nivel de confianza mınimo que se tiene que tener con los vecinospara elegirlo como MPR. Este parametro debe ser configurable ya que en un red chica con pocosnodos, establecer un umbral alto dejarıa el nodo aislado pero ya es riesgo del usuario usar unumbral bajo.


Para implementar seguridad sobre OLSR, es preciso identificar cuales son los paquetes y losmensajes crıticos para poder securizarlos. Los mensajes que hay que proteger son aquellos quepor alguna manipulacion pueden poner en riesgo la integridad de la red. Los mensajes a protegerclaramente son los mensajes HELLO, TC, HNA y MID.

Para la implementacion de seguridad sobre estos mensajes se pueden plantear dos alternativas,una autenticando y encriptando el mensaje de punta a punta [30] o firmando y encriptando elpaquete OLSR [21] dando una autenticacion y encripcion salto por salto.

Para la encripcion de punta a punta es necesario que los dos extremos de la conexion seautentiquen mediante el intercambio de certificados y generar una clave de sesion para realizar unencriptado simetrico. Con el uso de claves asimetricas generarıa un desperdicio de energıa porqueharıa uso intensivo del procesador. Esta alternativa no es considerada viable ya que implicarıamucho overhead de control y en caso de ser un nodo remoto a varios saltos de distancia elintercambio de mensajes podrıa interrumpirse y requerirıa una nueva negociacion. La propuestade [30] utiliza un mensaje de firma por separado que requiere un seguimiento de los mensajesrecibidos y verificar la firma de los mismos. Esta tarea requiere tener almacenados esos mensajesy compararlos con los mensajes recibidos, con lo cual se tiene un gasto extra de procesador paraesta tarea.

La autenticacion y encripcion salto a salto es mas eficiente pero no permite una verificaciondel mensaje de punta a punta. En el analisis el funcionamiento de OLSR 6.4, se vio que elprotocolo en sı utiliza el reenvıo de paquetes para la propagacion de mensajes con lo cual utilizaruna encripcion y autenticacion salto a salto va de la mano con el funcionamiento del protocolo.Esta forma de securizar un paquete se basa en que los nodos por los cuales se reenvıa, son nodosconfiables y autenticados.

9.3.4.1. Obtencion de la Clave de Sesion

Una de las premisas de este diseno es generar un protocolo que garantice integridad y confi-dencialidad, para ello es necesario utilizar una firma y una clave para encriptar el mensaje. Comose vio en el Capıtulo 3, existen dos tipo de cifradores, los simetricos y los asimetricos. Como



la cantidad de mensajes intercambiados entre un nodo y su vecino es muy grande, utilizar unesquema de clave publica y privada generarıa un malgasto de la energıa del nodo, para ello esque se utiliza una clave se sesion para encriptar con un algoritmo simetrico.

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) :

| |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| |


| |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figura 9.7: Formato del mensaje AUTH MESSAGE RESPONSE

El algoritmo de intercambio para la generacion de una clave de sesion, toma lugar durante elproceso de autenticacion para minimizar los mensajes intercambiados. Para realizar el intercambiode claves se incorpora un nuevo mensaje, el AUTH MESSAGE RESPONSE (Figura 9.7) y se debemodificar 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) :

| |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| |


| |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figura 9.8: Formato del mensaje AUTH MESSAGE FINISH

En el Paso 2 del proceso de autenticacion, el nodo B ya tiene el certificado de A. B encriptaun numero al azar de un numero de bits fijos (N = 128 para esta implementacion) con su claveprivada y luego con la clave publica de A.



En el Paso 3 el nodo A hace lo mismo que el nodo B. Finalizada esta etapa, los dos nodostiene los dos numeros al azar (KA, KB) y ningun otro nodo pudo haber obtenido estos numeros.

1. A → B : A,B,CertA, RA, sign(H(A,B,CertA, RA))

2. B → A : B,A,CertB , RB , EPuA(EPrB (KB)), sign(H(B,A,CertB , RA, RB , EPuA(EPrB (KB))))

3. A → B : A,B,EPuB (EPrA(KA)), sign(H(A,B,RA, RB , EPuB (EPrA(KA))))

A partir de esta etapa los nodos utilizan como clave de sesion el producto de estos dos numerostruncados a N bits1. Una vez completado el calculo de la clave compartida, es almacenada en latabla de vecinos. El perıodo de validez de la clave de sesion es igual al valor de expiracion delenlace con el vecino (campo L time de la tabla Link Set). Cuando ese perıodo este proximo avencerse se procede nuevamente a realizarse la ronda de autenticacion.

9.3.4.2. Firma de los mensajes

Para prevenir que los mensajes sufran alteraciones por algun nodo intruso, se realiza el firmadodel mismo con el algoritmo HMAC 2. Como se describio en el capıtulo 3 el algoritmo HMAC es unalgoritmo que aplica una funcion al mensaje y se obtiene un resumen criptografico del mismo.La funcion que se aplica recibe como parametro un mensaje y una clave (Figura 9.9). HMAC

involucra una funcion de hash aplicada al mensaje combinada con la clave HMACK(m) =h((K⊕opad)‖(h((K⊕ ipad)‖m)). La implementacion del algoritmo utilizada es HMAC-SHA-1, porlo tanto en la expresion anterior h() es SHA-1 y el resultado final sera una firma de 160 bits.

Figura 9.9: Generacion de la firma

HMAC no solo garantiza que el mensaje no fue modificado sino que tambien lo autentica. En estediseno HMAC es utilizado con una clave de N bits, en particular A utilizara KA y B utilizara KB

(valores intercambiados durante la ronda de autenticacion).

1Este calculo para la clave sesion es determinado de forma arbitraria y es parte del protocolo propuesto.2HMAC no es estrictamente una firma digital como se definio en el Capıtulo 3, pero en este caso sera utilizado

para garantizar integridad y autenticacion del mensaje.



Los paquetes de OLSR tiene dos tipos de campos, los que no varıan entre salto y salto ylos que varıan cuando son reenviados. Para esta propuesta de protocolo no es necesario tener encuenta estos campos ya que la autenticacion y la verificacion de la integridad del paquetes esllevada a cabo salto-a-salto. Diferenciar estos campos es importante si la integridad del mensajees evaluada en el extremo de la ruta. En definitiva la firma se realizara sobre:

Encabezado del paquete OLSR (con el tamano ajustado para incorporar la firma)

Todos los mensajes OLSR incluıdos en el paquete

Las cabeceras del mensaje de firma.

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

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figura 9.10: Formato del mensaje firma

Se genera un nuevo mensaje (Figura 9.10) con la firma y se agrega al final del paquete OLSR.El tamano del paquete OLSR debe ser reajustado para incorporar la firma al final como se ve enla Figura 9.11. Mas adelante cuando se trate la prevencion de ataques en el nivel 2 de securizacionse vera que el mensaje de firma sufre una ligera modificacion.

9.3.4.3. Protocolo de encriptacion

Para garantizar la confidencialidad de la informacion que viaja en el paquete, se aplica encrip-cion sobre el mismo. El algoritmo para encriptar los paquetes debe tener un cifrador simetricoya que hay que optimizar el uso de CPU del dispositivo movil. El algoritmo elegido para estatarea es el AES [31, Capıtulo 5]. AES es un cifrador por bloques y es el cifrador adoptado comoel cifrador estandar para el gobierno de los Estados Unidos y es el sucesor del 3DES. Utilizauna clave que puede ser de 128, 192 o 256 bits. Para este diseno se utilizara una clave de 128bits. La clave utilizada para encriptar los paquetes es la clave de sesion calculada en la ronda deautenticacion truncada a 128 bits.

Cuando el nodo destino recibe el mensaje, la primera operacion que debera hacer es desen-criptar el paquete con la misma clave que se utilizo para encriptarlo (Figura 9.12), luego continuael procesamiento del paquete validando la firma.

9.3.5. Descubrimiento de la Topologıa

Con la modificacion introducida, cada nodo tiene que conocer cuales son la CAs de la red,para ello utilizan la tabla de topologıa. Para diseminar esta informacion por la red, se generandos 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 :

| |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| |

: MESSAGE :

| |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figura 9.11: Formato del paquete de OLSR firmado

protocolo OLSR original [5, Sec. 9] y otro mensaje informando de los enlaces conocidos cualesson con una CA. Para diferenciar estos dos tipos se mensajes se utiliza el campo reservado en elmensaje de TC y se le coloca un indicador para senalar que las direcciones contenidas en el mismocorrespondes a nodos que son CAs.

Para armar los mensajes TC con la informacion de la CAs, se hace de la misma manera queen el protocolo original, con la modificacion que solo se tomaran las direcciones de los vecinos delNeighbor Set que sean CAs.

La forma de reenvıo de los mensaje TC no sufren ninguna modificacion con respecto al protocolooriginal.

9.3.6. Armado de la tabla de Ruteo

El procedimiento Armado de la tabla de Ruteo no sufre ninguna modificacion con respecto ala especificacion del protocolo original [5, Sec. 10]

9.3.7. Logros del Nivel 1 de securizacion

En lo detallado del Nivel 1 de securizacion se puede ver que es el nivel mas complejo ya quehay que incorporar mecanismos y elementos de criptografıa y comunicacion auxiliares para lograr



Figura 9.12: Firma + Encripcion de un paquete

un determinado nivel de seguridad. En este nivel se puede garantizar los servicios basicos de unared segura:

Autenticacion: Con la fase de autenticacion entre los nodos, se produce el intercambio decertificados firmados por CAs de la red, con lo cual ambos nodos estan seguros que estanconectados con quienes dicen ser.

Integridad: Con el esquema de firmado de los mensajes los nodos estan seguros que nadieha modificado su contenido.

Confidencialidad: Luego del procedimiento de autenticacion se establece una clave de sesionentre los dos nodos, con lo cual el trafico que es encriptado con esa clave solo puede serleıdo por ellos.

No repudio: Ambos extremos de un enlace estan autenticados con certificados expedidospor la CA, estos certificados son intercambiados para garantizar la identidad de cada uno.

Disponibilidad: Teniendo redundancia de las CAs, un nodo siempre va a tener donde solicitaro renovar certificados.

Teniendo asegurados los paquetes de control el protocolo ya esta mas seguro pero no es inmunea ataques, por ello es que se plantea el Nivel 2 de fortalecimiento donde se mitigan algunos ataques.


Tener autenticados y encriptados los paquetes de control pone al protocolo OLSR mas solidopero aun ası un nodo que permanece en la red durante un determinado tiempo podrıa realizardistintos ataques como el Ataque del Tunel y el Ataque de Reenvıo de Paquetes.

9.4.1. Prevencion contra ataque Wormhole

Unos de los ataques analizados en la Seccion 6.6 es el Ataque del tunel (wormhole attack) endonde un nodo utiliza los mensajes de HELLO generados en un sector de la red y los reproduceen otro, enviando dichos mensajes a traves de un tunel externo a la red. Esto hace que unavıctima crea que el nodo atacante sea un nodo vecino pero en realidad se encuentra a varios


9.4.2. Prevencion contra ataque de reenvıo de mensajes: Timestamp

saltos de distancia. Este ataque genera una alteracion de la topologıa de la red y el agresor coneste comportamiento hace que todos los nodos cambien sus tablas de ruteo y lo utilicen a el comogateway 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. Teniendoen cuenta que las placas de red utilizadas hoy en dıa tienen un radio de cobertura R, por ejemplomaximo 100mts (este valor parametrizable en el protocolo) y suponiendo que la velocidad depropagacion de la senal wireless c en el aire es cercana a la velocidad de propagacion de la luz enel vacıo, se puede calcular la distancia recorrida por un paquete como L = t × c. Entonces si sedetecta que un paquete cumple con L > R, se esta en presencia de un ataque de tunel y en casocontrario, no (L <= R).

La implementacion de este sencillo algoritmo consiste en el siguiente procedimiento: Duranteel Procedimiento de Autenticacion, cuando B recibe el primer mensaje de A (Paso 1), B inicializaun contador y envıa la respuesta a A (Paso 2), cuando A le responde, B detiene el contador yenvıa el mensaje a A (Paso 3). B calcula la distancia como S = (4tb

/2) × c, si S > R, B nopone a A como vecino confiable, en caso contrario y se completa satisfactoriamente el paso 4, B

inserta a A como vecino seguro.

El procedimiento seguido por A es analogo, con la diferencia que A inicializa el contador enel Paso 1 antes de enviar el primer mensaje hacia B.

9.4.2. Prevencion contra ataque de reenvıo de mensajes: Timestamp

Otro de los ataques analizados en la Seccion 6.6 es el Ataque por Reenvıo de Mensajes, el cualconsiste en grabar trafico de la red y reproducirlo en otro momento. Este ataque es posible porquelos numeros de secuencias, son numeros de 16 bits, con lo cual en un corto plazo comienza desdecero nuevamente. Por esta vulnerabilidad es que no se puede garantizar la frescura (fresshness)de un paquete.

Como solucion a este ataque, los paquetes de OLSR necesitan un nuevo mecanismo para vali-dar su frescura. Para esto se utiliza un timestamp de 32 bits en cada uno de los paquetes. Existenvarias alternativas para la implementacion de timestamps. En [30, Sec. V] se proponen distintasalternativas de implementacion. En esta propuesta se utilizara la idea desarrollada en [21], la cualno depende de la sincronizacion de relojes y es un intercambio simple de mensajes.

La propuesta planteada en [21], consiste en un dialogo para intercambiar los relojes de cadaextremo. Para esto utiliza mensajes especiales.

En esta tesis se utilizara la idea de [21] pero no se utilizaran mensajes especiales sino que elintercambio de relojes se llevara a cabo durante el proceso de autenticacion donde se agregara alos mensajes la hora de cada nodo (notar que la modificacion se hizo sobre los mensajes deautenticacion basicos y no sobre los detallados en el proceso de intercambio de claves del nivel 1de securizacion). De esta manera, el nodo receptor del mensaje puede calcular la diferencia horariay almacenarla en la tabla de vecinos. Para llevar a cabo este intercambio de debe modificar elmensaje 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 imeBsign(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 unatolerancia para el calculo del timestamp. Cada paquete recibido tiene su propio timestamp. Elnodo receptor extrae el timestamp del paquete y calcula la diferencia con su reloj calculandoTN = Tlocal − Tpaquete. A continuacion evalua T0 − S < TN y T0 + S > TN , donde T0 es ladiferencia horaria almacenada en la tabla de vecinos. En caso que la validacion del timestampsea correcta se procesa el mensaje, en caso contrario se descarta.

Para compensar algun desfasaje de los relojes, se realiza un ajuste de T0 calculando el promedioentre la diferencia horaria almacenada y la calculada para este paquete (T0 = (T0 + TN )/2).

Con la implementacion del timestamp, se modifica el mensaje de firma del paquete generadoen el nivel 1 de securizacion ya que es necesario que el timestamp pertenezca a este mensaje paragarantizar la frescura del paquete. El nuevo mensaje de firma (Figura 9.13) contiene el timestamp,el cual es parte de los campos a tener en cuenta en para la firma ya que es necesario que esecampo 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

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| TIMESTAMP |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figura 9.13: Formato del mensaje firma con timestamp

9.4.3. Prevencion contra ataques de DoS

Uno de los ataques mas comunes son los ataques de Denegacion de Servicio. Estos ataquespueden ser realizados de distantas maneras, por ejemplo un nodo malicioso o mal configuradopodrıa enviar docenas de mensajes de autenticacion por segundo haciendo un desgaste de energıaprocesando el mensaje en el nodo receptor.

Una manera sencilla de mitigar este tipo de ataque es mantener un contador por cada direccionde origen que envıa un mensaje. Cuando el nodo recibe un mensaje de un determinado origen,guarda ese registro en una tabla e inicializa un contador. Si este nodo recibe mas mensajes delnodo agresor en el lapso de tiempo en el cual en contador todavıa esta activo rechaza el mensaje.

Esta prevencion no tiene efecto si el nodo agresor realiza un spoofing de IP. En este caso elprotocolo cuenta con un mecanismo de aceptacion de paquetes de manera estadıstica para nosaturar el nodo. Se establecen umbrales que son configurables para el protocolo y en base a esosumbrales 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 securizacion alcanzada en el Nivel 1, se pueden prevenir los ataquesque involucran la modificacion de los paquetes como Generacion Incorrecta de Mensajes HELLO,Generacion Incorrecta de Mensajes TC, ya que ningun nodo puede hacerse pasar por otro porquelos nodos estan autenticados. Otros ataques pasivos son mitigados porque nodos que escuchan eltrafico no pueden interpretarlo ya que esta encriptado.

9.4.5. OLSR RFC 3226 vs. OLSR Seguro

Realizando una comparacion rapida entre el protocolo original (RFC 3626) y el fortalecimientopropuesto, se puede ver que no se modifica el funcionamiento pero sı se agregan capas de seguridady algunas modificaciones mınimas a las Etapa 1 (Censado y Descubrimiento de Vecinos) y laEtapa 2 (Eleccion de MPR). En la Figura 9.14 se puede ver de manera esquematica como se haempaquetado el protocolo original para hacerlo seguro.

Figura 9.14: Etapas del protocolo OLSR




Ya a esta altura con los dos niveles de seguridad especificados se tiene un protocolo seguro einmune a algunos ataques. El objetivo del tercer nivel es proponer mecanismos de autodefensapara la red. Para ello se definen dos mecanismos. Uno, el mismo protocolo implementa un me-canismo de denuncia de los nodos que estan intentando un ataque o tienen un comportamientoincorrecto y el otro es el agregado de un componente externo al protocolo que es un Sistema deDeteccion de Intrusos. Los mecanismos descriptos en este nivel es una opcion mas planteada enesta tesis para hacer la red segura pero no sera analizada en profundidad con lo cual son objetode estudio futuro.

9.5.1. Mecanismo de Denuncia

Una alternativa de autodefensa serıa que si un nodo detecta que esta siendo vıctima de unataque pueda reportar este incidente a una CA. Las CAs que estan conectadas al backbonede la red mantienen un dialogo sobre los reportes enviados por los nodos. Las CAs recibenestos incidentes pero solo toman como validos los que provienen de algun nodo con un nivel deconfiabilidad alto (umbral parametrizable en el protocolo) y se tomara una accion cuando mas deun nodo (valor parametrizable) confiable realice una denuncia (Voto Calificado). En ese momentose genera una revocacion del certificado y es anunciado a todas las CAs de la red.

9.5.2. Sistema de Deteccion de Intrusos

Un Sistema de Deteccion de Intrusos es muy utilizado en el ambito de grandes redes, tienecomo objetivo detectar intrusos en base a comportamiento de los clientes de la red. A diferencia delmecanismo de denuncia, el IDS puede ser configurado para que actualice la base de conocimientoso el mismo IDS puede aprender, en cambio el mecanismo de denuncia es algo fijo que tiene elprotocolo y cualquier cambio que se quiera realizar requiere una modificacion del protocolo yredistribucion del mismo.

9.5.2.1. Interaccion con las CAs

El IDS, es un nodo mas que pertenece a la red y los clientes lo ven como un cliente mas. ElIDS debe correr en un nodo seguro de la red y poseer un certificado especial para comunicarsecon las CAs.

El IDS detecta un comportamiento extrano de un determinado nodo y envıa la noticia a lasCAs que tiene a su alcance. La conexion con las CAs se hace con una conexion SSL de dos vıas(el nodo valida la identidad de la CA y la CA la del nodo mediante los certificados). Una vez quela CA recibio el mensaje actualiza su CRL.

9.5.3. Sincronizacion de CRLs

Las CAs, en una red movil urbana van a ser nodos interconectados a traves del backbone dela red y van a tener un enlace estable, con lo cual garantiza cierta confiabilidad de interconexion.


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 conocencuales son las CAs de la red con lo cual pueden comunicarse con cada una de ellas. Periodicamenteuna CA recorre el las CAs disponibles y establece una conexion SSL de dos vıas con otra CAy le pide su CRL y actualiza la propia agregando las entradas que no tiene. Antes de procedercon la actualizacion de la CRL, verifica si la fecha de actualizacion de la CRL descargada de laCA remota en mas vieja que la se tiene no se hace nada, en caso contrario se procede con laactualizacion.

9.6. Debilidades del Esquema de Seguridad propuesto

El esquema de seguridad propuesto en esta tesis garantiza los servicios basicos que debeprestar una red de datos segura y es inmune a cierto tipo de ataques pero no es infalible y tienedebilidades.

El protocolo no previene los ataques a las capas inferiores como por ejemplo ataques de capafısica, donde un nodo puede ser vıctima de interferencias del nodo agresor (jamming) impidiendola comunicacion con el resto de sus vecinos, ataques de capa dos (enlace) donde el nodo agresorpuede hacer spoofing de MAC address o en capa de red spoofing de IP.

Con esta debilidad expuesta, un nodo que fue excluido de la red podrıa reingresar como unnodo nuevo cambiandose su direccion IP y su MAC address. En este caso la red lo reconoce comoun nodo nuevo y la confianza que habıa ganado dentro de la red con su identidad anterior lapierde.

9.7. Resumen

A lo largo de este capitulo se dieron detalles de la implementacion del esquema de seguridadpropuesto para una red movil urbana. Este esquema se divide en dos partes, la primera queinvolucra el aspecto organizacional de una red movil urbana y la segunda es la modificacion delprotocolo OLSR para ser inmune a distintos ataques. Este fortalecimiento del protocolo se divideen tres niveles, los cuales atacan distintos aspectos de seguridad. Nivel 1 introduce algoritmos ymecanismos criptograficos para garantizar autenticacion, confidencialidad y no repudio. El Nivel2 mitiga distintos ataques y por ultimo el Nivel 3, el cual es objeto de estudio futuro incorporaun mecanismo de autodefensa de la red.


Capıtulo 10

Prueba de Contenido

El objetivo de este capıtulo es describir como se realizo la prueba de contenidopara demostrar el funcionamiento de algunas modificaciones introducidas al protocoloOLSR para mejorar su seguridad dentro de un ambito urbano .

En el Capıtulo 9 se dieron los detalles sobre los distintos niveles de securizacion propuestos enesta tesis para el protocolo OLSR. Para confirmar el correcto funcionamiento de la modificacional protocolo original, se realizo una prueba de contenido donde se implementaron algunas de lasnuevas funcionalidades. A lo largo de este capıtulo se detallara como fue implementada la pruebade contenido.

Para realizar la prueba es necesario contar con una red movil funcionando con una cantidadde nodos determinada y distribuıdos de manera tal que un nodo deba rutear a traves de otropara llegar al destino. Este escenario en un ambiente de laboratorio es muy difıcil de conseguircon lo cual se desarrollo un simulador para poder probar el protocolo.

Las funcionalidades implementadas en el simulador son:

Implementacion de la Autoridad Certificante.

Descubrimiento de Autoridades Certificantes.

Solicitud de un certificado por parte del nodo.

Firmado del Requerimiento y emision del certificado valido para la red.

Descubrimiento de Vecinos.

Autenticacion de Vecinos.

117

10.1. Arquitectura

10.1. Arquitectura

El protocolo OLSR es un programa que es ejecutado en la capa de aplicacion, es decir utilizalas capas inferiores para enviar mensajes y en base a ellos modifica la tabla de rutas del SistemaOperativo sobre el cual corre.

La implementacion de la prueba de contenido se realizo de la misma manera pero en este casono es parte del objetivo de la misma realizar la modificacion de la tabla de rutas del SO base.Otra de las premisa de la implementacion es que no contempla cambios de topologıa durante cadauna de las etapas. La prueba asume que el escenario se mantiene estatico y no sufre alteraciones.

El simulador fue codificado en Java, utilizando librerıas open source para la manipulacion decertificados.

La arquitectura basica del simulador esta constituida por cuatro modulos (Figura 10.1). Elmodulo de procesamiento de mensajes OLSR (MulticastDaemon), el modulo de la AutoridadCertificante (CAModule), el modulo de autenticacion con los vecinos (AuthDaemon) y el nodopropiamente dicho (Node).

Figura 10.1: Principales modulos del simulador


Prueba de Contenido

10.1.1. Certificados y Keystores

Como un nodo debe manejar certificados y la prueba de contenido fue desarrollada en Java,este lenguaje hace uso de Keystores para almacenar los certificados del programa Java [33].

En particular en esta implementacion se eligio usar dos Keystore independientes, uno con el finde almacenar la identidad del nodo y el otro para almacenar los certificados de los nodo confiados.Ası el proceso Java cuando establece una conexion SSL o necesita verificar algun certificado quele fue presentado hace uso de estos repositorios para validarlos.

10.1.2. Configuracion del Nodo

Cada nodo cuenta con un archivo de configuracion en el cual se le especifica entre otras cosascuales son los Keystores del nodo (identidad y confianza), parametros necesarios para hacer usode los mismos, direccion IP principal del nodo, si el nodo va a actuar como CA o no y el path alarchivo de topologıa de la red.

El archivo de topologıa de red es un archivo en formato XML en el cual esta el escenariobasico sobre el cual se inicia el nodo. En este archivo esta el listado de vecinos, la tabla de ruteo,el listado de links con los vecinos, tabla de topologıa, etc. En particular en esta implementacionese archivo contiene la estructura de un red vacıa, sin ningun vecino.

10.1.3. Plugin olsrd para generar el archivo de topologıa

Para crear el archivo de topologıa se creo un plugin de olsrd el cual imprime en formato XMLtoda la informacion de las tablas del protocolo. El formato del archivo XML fue disenado paraser usado luego con XStream1 y poder construir el objeto Nodo.

El plugin fue programado en base a las facilidades que da la implementacion de olsrd pararealizar este tipo de extensiones. Esta extension escucha en un socket y cuando se establece unaconexion, imprime el contenido de las tablas en formato XML.

Desde el simulador existe un modulo llamado DataCollector, el cual podrıa ser utilizado paraactualizar en cualquier momento la topologıa de la red del simulador con la topologıa real dela red en la cual esta participando el nodo. Esta funcionalidad fue desarrollada para generar elarchivo de topologıa que usa el simulador para cada nodo, pero no se utiliza para actualizar lainformacion del nodo.

10.1.4. Mensajes

El diseno de los mensajes se hizo teniendo en cuenta los originales del protocolo y extendiendoestos con los mensajes modificados para adaptarse a la propuesta de esta tesis. Como se puedever en la Figura 10.2, todos los mensajes heredan de una clase llamada GenericMessage, el cualtiene entre otras cosas un metodo abastracto llamado processMessage(), el cual obliga a cadamensaje que lo extiende a implementar este metodo que tiene como objetivo que cada mensajesepa como procesarse. De esta manera los servidores que reciben algun mensaje no tienen que

1http://xstream.codehaus.org/


10.1.5. Modulo de Autoridad Certificante

Figura 10.2: Diagrama de Clases para los mensajes del protocolo

tener la logica de procesamiento, sino que cada uno sabe cual es su funcion y se procesa a simismo y genera una respuesta.

10.1.5. Modulo de Autoridad Certificante

El modulo de Autoridad Certificante, es una clase que se ejecuta en un thread independiente,establece un socket y se queda esperando por peticiones de certificados. El nodo tiene un archivo


Prueba de Contenido

de configuracion donde uno de las propiedades a configurar es si el nodo va a actuar como CAo no. En caso que ası sea, se especifica cual el es Keystore donde se encuentra su certificadoexpedido por la Root CA de la comunidad.

Este modulo no solo tiene la responsabilidad de lanzar el servidor, sino que cuenta con todoslos metodos necesarios para manipular los certificados.

10.1.6. Modulo de Autenticacion con los vecinos

Una vez que el nodo tiene un certificado valido para participar en la red, necesita autenticarsecon los vecinos para hacer uso de la misma. Para ello el nodo cuenta con este modulo que lanzaun servidor el cual queda a la espera de mensajes de autenticacion. Este modulo utiliza los dosKeystores configurados para el nodo. El de identidad lo utiliza para enviar su propio certificadoen el mensaje AUTH MESSAGE y utiliza el de confianza para almacenar los certificados de los vecinosconfiados.

Para simplificar la implementacion del proceso de autenticacion de los vecinos, se imple-mento las primeras dos fases 9.3.3.1 como un handshaking de SSL en el cual se realiza unaautenticacion de SSL de dos vıas. La autenticacion SSL de dos vıas [34, Cap. 10] consiste en queel server cuando recibe una peticion de conexion, obliga al cliente a presentar su certificado ya la vez el servidor le envıa su certificado al cliente. De esta manera en ambos lados se evaluala cadena de certificacion de los mismos y la validez. Una vez que ambos nodos se autenticaronenvıan el mensaje AUTH MESSAGE FINISH y los nodos confıan entre si. Este modulo utiliza losmetodos del Modulo de CA para validar la cadena de certificacion.

10.1.7. Modulo de Procesamiento de mensajes OLSR

El modulo de procesamiento de los mensajes del protocolo, como se puede ver en la Figura 10.1,corre un servidor que escucha en un socket multicast (MCastReader) y con cada mensaje quellega ejecuta el metodo processMessage() de cada uno de ellos para que se auto-procesen y luegopoder enviar el mensaje de respuesta.

10.2. Implementacion

A lo largo de esta seccion se van a presentar algunos detalles de implementacion del simuladorpara dar una idea al lector sobre como fue desarrollado sin entrar en detalles propios de laprogramacion.

10.2.1. Descubrimiento de CAs y Vecinos

El nodo que quiere ingresar a la red realiza como primera accion un descubrimiento de lasAutoridades Certificantes de la red para realizar posteriormente el pedido del certificado. Elprocedimiento de descubrimiento se realiza enviando un mensaje de tipo CA DISCOVER por mediouna trama de multicast. Para hacer esto se instancia un mensaje de tipo CADiscoverMsg, seagrega el mensaje a un paquete OLSR y luego es enviado a la red.



Cuando un vecino recibe el mensaje, agrega al nodo que origino el mensaje como vecino,inserta en el mensaje recibido el listado de CAs que el conoce y luego envıa la respuesta perocon direccion de destino la del nodo solicitante, ası cualquier nodo que reciba la respuesta y noes para el, la descarta.

El nodo que intenta ingresar a la red recibe la respuesta del nodo vecino y agrega a este comovecino e inserta en la tabla de topologıa las CAs informadas por el vecino.

De esta manera el proceso de descubrimiento tiene doble proposito, descubrir los vecinos ylas CAs de la red.

Todos los nodos tienen el demonio de procesamiento de mensajes OLSR escuchando en lamisma IP y puerto de multicast. Para la implementacion del simulador el demonio escucha en ladireccion 228.0.0.23:4444

10.2.1.1. Demonio de Procesamiento de mensajes OLSR

La implementacion del demonio de procesamiento de mensajes de OLSR es muy sencilla. Laclase MulticastDaemon tiene un metodo para inyectar paquetes OLSR en la red y lanza un threadcon la clase MCastReader que recibe los mensajes multicast de los vecinos. Cada vez que recibeuno, invoca el metodo processMessage() del mensaje recibido, el cual sabe que es lo que tiene quehacer.

Figura 10.3: Diagrama de Secuencia para la firma de un CertReq


La Autoridad Certificante fue implementada dentro del modulo CAModule. Cuando se ins-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 Certificante solo es iniciada si en el archivo de configuracion del nodo

(config.properties), se especifico la propiedad enableCA=true.Como se dijo anteriormente, la clase CAModule, no solo laza la clase CAServer, sino que tiene

metodos estaticos para realizar la gestion de certificados.Cuando el servidor recibe una conexion de un nodo, invoca el metodo precessMessa-

ge()(Figura 10.3) el cual valida que el mensaje sea tipo CERT REQ y luego firma el requerimientoinvocando el metodo de clase signCertReq() de la clase CAModule. Finalmente con el certificadofirmado, genera un mensaje de respuesta (CERT REPLY) y se lo envıa al nodo.

Figura 10.4: Diagrama de Secuencia de la obtencion de un certificado

10.2.2.1. Interaccion Nodo-CA

El servidor de la CA crea un socket de tipo SSLServerSocket en cual utiliza el keystore deidentidad para enviar su certificado al cliente que establece la conexion. En este punto, el nodocliente, valida la cadena de certificacion del certificado presentado por la CA. El nodo puederealizar esta tarea ya que en el keystore de confianza tiene el certificado de la Root CA de lacomunidad. Una vez validada la identidad de la CA, se envıa el mensaje CERT REQ. El nodocliente utiliza la clase Tools que tiene el metodo makeSSLConnection() que realiza la conexionSSL y valida la cadena de certificacion del servidor.

La CA envıa el mensaje CERT REPLY con el certificado firmado para poder participar de la red.El nodo cliente valida el certificado recibido, lo almacena e inicia el demonio de Autenticacioncon los Vecinos. En la Figura 10.4 se puede ver el diagrama de secuencia simplificado para laobtencion de un certificado.

10.2.3. Autenticacion con los Vecinos

Una vez que el nodo que quiere ingresar a la red obtiene un certificado valido, inicializa eldemonio de Autenticacion con los vecinos. El demonio de autenticacion inicia un servidor con unsocket SSL (puerto 4444), pero en este caso a diferencia del modulo de CA, se instancia para que


10.3. Modos de Operacion del Simulador

solicite al cliente que presente su certificado y ası validar que este tiene un certificado expedidopor una CA valida (Autenticacion SSL de dos vıas). Esta autenticacion se realizo para simplificarla implementacion y realiza los pasos 1 y 2 de la autenticacion propuesta en la Seccion 9.3.3.1.

Ambos nodos luego de autenticarse, actualizan su tabla de vecinos indicando que el vecino esconfiable y almacena el certificado en el keystore de confianza.

Para realizar la autenticacion SSL de dos vıas, se utilizan los dos keystores, uno para enviarsu identidad y el otro para validar la cadena de certificacion del certificado del vecino.

10.3. Modos de Operacion del Simulador

(a) Modulos instanciados por el nodo en modoCA

(b) Modulos instanciados por el nodo en modocliente

Figura 10.5: Instanciacion de modulos dependiendo el modo de operacion

Como se dijo en varias oportunidades, el simulador puede operar como CA o como nodocliente de la red.

En caso que el nodo sea ejecutado como CA, se inicializan los siguientes modulos (Figu-ra 10.5(a)):

Modulo de CA (CAModule), el cual contiene el sservidor que atiende las peticiones de losclientes (CAServer).

Modulo de procesamiento de mensajes multicast (MulticastDaemon), el cual contiene elservidor de mensajes multicast que recibe la informacion y peticiones de los nodos vecinos.


Prueba de Contenido

Modulo de Autenticacion con los vecinos (AuthDaemon).

En caso que el nodo sea ejecutado como cliente, se inicializan los siguientes modulos (Figu-ra 10.5(b)):

Modulo de procesamiento de mensajes multicast (MulticastDaemon).

Modulo de Autenticacion con los vecinos (AuthDaemon).

10.4. Resumen

A lo largo de este capıtulo de dieron detalle de las mejoras propuestas en la tesis para elprotocolo OLSR implementadas en la prueba de contenido. Para fundamentar la propuesta deesta tesis, se realizo un simulador que implementa algunas de las mejoras. Con este simuladorse muestra que la propuesta funciona, pero la misma no tiene como objetivo realizar un juiciosobre la performance del nuevo protocolo ya que por la naturaleza misma de la implementacionen Java dista de la real desarrollada en C.


10.4. Resumen


Capıtulo 11

Conclusiones

En este trabajo de tesis se presento un Esquema de Seguridad para una Red Movil Urbana.Para la elaboracion de esquema se pasaron por distintas instancias, las cuales son presentadasdurante el desarrollo de este trabajo.

El primer paso dado fue profundizar sobre los diferentes protocolos de ruteo existentes o enestudio disponibles. Esto fue necesario para enriquecer lenguaje tecnico y diferentes alternativaspara realizar un mismo objetivo, rutear paquetes sobre una Red Movil. Superada esta etapa yviendo que los protocolos de ruteo de redes moviles en su mayorıa no contemplaban cuestionesrelacionadas con la seguridad es que se vio la necesidad de investigar como solucionar estosaspectos ya que en un medio hostil como lo es el aire un protocolo puede estar en riesgo si no setiene en cuenta los posibles ataques. Para saber que requisitos debe cumplir una Red Movil huboque remontarse a conceptos basicos de seguridad para saber cuales son los servicios basicos quedebe brindar una red segura. Con los concepto de seguridad basicos dentro de las herramientasdisponibles para allanar el camino hacia el objetivo de la tesis, se extendieron esos conceptos aRedes Moviles donde se vio que hay que agregar variables como que los nodos son a baterıas, semueven, y no tienen grandes capacidades de procesamiento.

Ya a esta altura se cuenta con los conocimiento de Redes Moviles, con los requisitos basicosque debe cumplir un protocolo para ser considerado seguro. El siguiente paso fue estudiar queprotocolos “seguros” habıa disponibles y ver de que manera cumplıan con los requisitos.

Un aspecto clave para alcanzar el objetivo es estudiar como son, como se comportan y comose organizan las redes Urbanas, donde se encontro que en su mayorıa estan administradas porcomunidad sin fines de lucro. Fue fundamental conocer como es en particular la administracion yorganizacion de una Red Movil Urbana como lo es Buenos Aires Libre para saber que el protocolomas difundido entre las Redes Moviles Urbanas es el OLSR.

El siguiente paso fue profundizar sobre el funcionamiento de este protocolo y analizar cualesserıan los posibles ataques que podrıa sufrir.

Con el conocimiento tecnico del funcionamiento y vulnerabilidades del protocolo OLSR maslos aspectos organizativos de una Red Movil Urbana ya se contaba con los elementos suficientespara enfrentarse a la ultima parte hacia el objetivo final.

127

Luego de la lectura de varios artıculos con propuestas de securizacion para OLSR, tomandoideas de cada uno de ellos y poniendolas dentro del marco de una Red Movil Urbana es quedesarrollo la propuesta de securizacion del protocolo OLSR.

Dentro de los artıculos leıdos, ninguno de ellos daba una solucion completa como la propuestaen esta tesis. La propuesta incluye:

La distribucion de claves por medio de certificados digitales.

Se especifico una polıtica organizacional para distribuir entidades certificadoras

Elaboracion de un esquema de confianza de un nodo y la participacion del mismo en la red.

Se especifico un mecanismo de reconocimiento y autenticacion con los vecinos.

Se especifico un mecanismo de intercambio de claves

Se utilizo una forma para firmar mensajes de control

Se utilizo un algoritmo de encriptacion simetrico combinado con la clave compartida parala encripcion de los mensajes de control

Prevencion de Ataques

Alta disponibilidad de CAs

El esquema propuesto presenta distintos niveles de seguridad, los cuales pueden ser imple-mentados en distintas etapas y podrıan conformar modulos agregados a la implementacion actualdel protocolo OLSR.

La propuesta muestra como se pueden prevenir ataques tıpicos al protocolo OLSR. Se in-corporaron mecanismos como por ejemplo un algoritmo simple de timestanping, una heurısticasencilla para detectar si un nodo esta intentando hacer un ataque de tunel, un esquema de firmaspara garantizar la integridad de los mensajes y un mecanismo de encripcion para garantizar laconfidencialidad de los paquetes de OLSR.

La solucion puede ser escalable para incorporar mecanismos de autodefensa como el uso deun IDS.

Se construyo una solucion que cumple con la premisas basicas para que una Red Movil seaconsiderada segura. Se mejoraron aspectos existentes en algunas soluciones y se agregaron nuevassoluciones.

Finalmente para asegurar el funcionamiento de la propuesta, se implemento un simuladorpara realizar la prueba de contenido donde se muestra el funcionamiento del protocolo durante laincorporacion de un nodo a la red. Esta prueba incluye el descubrimiento de las CAs, la obtencionde un certificado para participar en la red y la autenticacion con los vecinos


Bibliografıa

[1] Stefano Basagni, Marco Conti, Silvia Giordano, Ivan Stojmenovic.Mobile Ad-Hoc Networ-king, IEEE Press, 2004.

[2] Mehran Abolhasan, Tadeusz Wysocki, Eryk Dutkiewcz. A review of routing protocols for adhoc networks, Elsevier, 2004.

[3] Charles E. Perkins, Pravin Bhagwat. Highly Dynamic Desditation-Sequenced Distance-VectorRouting (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. Muhlethaler, T. Clausen, A. Laouiti, A. Qayyum, L. Viennot Optimized LinkState 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 WMC-SA, 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 HocNetworks for IPv4, RFC, 2007

[11] David B. Johnson, David A. Maltz, Josh Broch. DSR: The Dynamic Source Routing Protocolfor Multi-Hop Wireless Ad Hoc Networks, 2004

[12] Marc R. Pearlman, Zygmunt J. Haas. Determining the Optimal Configuration for the ZoneRouting Protocol, IEEE, 1999

[13] Zygmunt J. Haas, Marc R. Pearlman, Prince Samar.The Zone Routing Protocol (ZRP) forAd Hoc Networks, RFC DRAFT, 1999

129

BIBLIOGRAFIA

[14] Sung-Ju Lee, Mario Gerla.Split Multipath Routing with Maximally Disjoint Paths in Ad hocNetworks

[15] Lidong Zhou, Zygmunt J Hass. Securing Ad Hoc Networks, IEEE Network Magazine, pp24-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 Cer-tificate Authority in an OLSR MANET, IEEE Communication Society, WCNC 2004 pp682-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 MDM2006.

[20] Cedric Adjih, Daniele Raffo, Paul Muhlether. Attack Against OLSR: Distributed Key Ma-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 Specifications for Public-Key Cryptography. IEEE-SA Stan-dandards Boards, 2004.

[23] P. Papadimitratos and Z. J. Haas. Secure Routing for Mobile Ad Hoc Networks. In Procee-dings of CNDS, 2002.

[24] Krawczyk, H., Bellare, M., and R. Canetti, HMAC: Keyed-Hashing for Message Authenti-cation. RFC 2104, February 1997.

[25] A. Perrig, D. Song, R. Canetti, J. D. Tygar, B. Briscoe. Timed Efficient Stream Loss-TolerantAuthentication (TESLA). RFC 4082, Junio 2005.

[26] Haiyun Luo, Songwu Lu. Ubiquitous and Robust Authentication Service for Ad Hoc WirelessNetworks, Octubre 2000.

[27] M. Myers, C. Adams, D. Solo, D. Kemp. Internet X.509 Certificate 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 Certificateand CRL Profile, RFC 2459, 1999.

[30] Cedric Adjih, Thomas Clausen, Philippe Jacquet, Anis Laouiti, Paul Muhlethaler, DanieleRaffo. Securing the OLSR protocol. INRIA Rocquencourt, Project Hipercom.


BIBLIOGRAFIA

[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. O’Reilly, 2da Edicion, 2001

[34] David Hook. Beginning Cryptography in Java, John Wiley & Sons, 2005.

[35] Oficina Nacional de Tecnologıa de la Informacion Republica Argentina (ONTI). Modelode Polıtica de Seguridad de la Informacion para Organismos de la Administracion PublicaNacional, Version 1, Julio 2005


Documents

Redes Móviles Seguras en un Ambito Urbano´materias.fi.uba.ar/7500/caracoche-tesisdegradoin... · Móviles Urbanas son un subgrupo de las redes móviles donde se encuentran nodos