Caracoche Tesisdegradoingenieriainformatica

Redes M
oviles Seguras
en un Ambito
Urbano
Utilizando Protocolo OLSR
Tesis de Grado en Ingeniera Informatica
Orientacion en Sistemas Distribudos
Juan M. Caracoche
juan@caracoche.com.ar
Director:
Hugo Pagola
Facultad de Ingeniera
Universidad de Buenos Aires
Millones de personas vieron caer la manzana,

pero Newton fue el u
nico que se pregunt
o porque.
Bernard Baruch
Resumen
Las redes m
oviles (Mobile Ad-hoc NETworks -MANET-) son un tipo especial de redes en
la cual un conjunto de dispositivos moviles conforman de manera temporal una red de forma
autonoma sin la necesidad de una infraestructura. Para estos ambientes existen distintos protocolos 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 protocolos son variados y cada uno es propenso a distintos tipos de ataques. En particular las redes
Moviles Urbanas son un subgrupo de las redes moviles donde se encuentran nodos diseminados
por toda una ciudad, la geografa de una ciudad y las limitaciones del medio de trasmision de la
tecnologa 802.11 hacen que se deba armar una topologa particular, lo que hace que los nodos
que participen tengan distintos roles. En particular la red Urbana Buenos Aires Libre es el objeto
de estudio de esta tesis donde se analiza el protocolo OLSR utilizado por la red y se dise
na un
esquema de seguridad para hacerla lo mas inmune posible a ataques externos.
tica
Juan Manuel Caracoche - Tesis de grado Ingeniera Informa
Abstract
The mobile networks (Mobile Ad-hoc NETworks -MANET-) are a special kind of network
where a set of mobile devices build in a spontaneous way a temporary self-organized network
without any infraestruture to work. For this king of networks there are dierents routing protocols
to guide packets between nodes which are constantly moving. Some of this protocols not only
guarantee the routing, they also give security to the protocol. In particulary, a Urban Mobile
Networks are a subset of mobile networks where nodes are diseminated over all the city. The
citys geography and the transmision technology (802.11) bring into the scene some constraints
that makes to build specials topologies where each node in the net may take dierent roles. In
particulary the Urban Network Buenos Aires Libre, is the study target of this thesis. Over this
network is analyzed the OLSR protocol which is used as routing protocol and a security scheme
is designed to make this networks safer as possible against external attacks.
II
tica
Agradecimientos
Quiero agradecer a muchas personas por el apoyo durante el desarrollo de esta tesis y en la
vida misma
Al Ing. Hugo Pagola, tutor de esta tesis, quien a pesar de sus innumerables compromisos pudo
siempre hacerse el tiempo para atender mis consultas, realizar las correcciones y aportar ideas.
A mi familia, en especial a mis padres que sin medir privaciones o sacricios entendieron que
la educaci
on de un hijo es m
as que una inversion.
A mi novia que tuvo la paciencia de acompa
narme en el duro camino de mis u
ltimos a
nos de
la carrera.
Por supuesto no poda olvidarme del apoyo incondicional de mis amigos y compa
neros, que
me dieron durante los a
nos de facultad, los mejores a
nos de mi vida.
Juan Manuel Caracoche

Agosto 2008
tica
III
Acerca del Autor

Juan Manuel Caracoche naci
o en la ciudad de Pellegrini, provincia de Buenos Aires el 16
de Febrero de 1980. Realiz
o sus estudios primarios en la escuela Guillermo de Soldato y los
secundarios en el Instituto Jose Manuel Estrada, ambos establecimientos de su ciudad natal. En
el a
no 1998 se traslada a la ciudad de Buenos Aires para comenzar sus estudios universitarios en la
Facultad de Ingeniera de la Universidad de Buenos Aires, actualmente es estudiante de la carrera
Ingeniera Inform
atica. Adicionalmente es docente auxiliar del Departamento de Electronica de
la misma Universidad.
IV
tica
Indice general
Resumen
Abstract
II
Agradecimientos
III
Acerca del Autor
IV
1. Introducci
on
11
1.1. Motivaci
on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.2. Objetivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2. Redes M
oviles
2.1. Generalidades . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2. Protocolos de Ruteo . . . . . . . . . . . . . . . . . . . . . . . . .
2.3. Protocolos de Ruteo Proactivos, Reactivos e Hbridos . . . . . . .
2.3.1. Protocolos de Ruteo Proactivos . . . . . . . . . . . . . . .
2.3.1.1. Destination-Sequenced Distance-Vector (DSDV)
2.3.1.2. Optimized Link State Routing (OLSR) . . . . .
2.3.2. Protocolos de Ruteo Reactivos . . . . . . . . . . . . . . .
2.3.2.1. Ad hoc on-demand distance vector (AODV) . .
2.3.2.2. Dynamic Source Routing (DSR) . . . . . . . . .
2.3.3. Protocolos de Ruteo Hbridos . . . . . . . . . . . . . . . .
2.3.3.1. Zone Routing Protocol (ZRP) . . . . . . . . . .
2.3.4. Tecnicas de Ruteo . . . . . . . . . . . . . . . . . . . . . .
2.3.4.1. Multipath Routing . . . . . . . . . . . . . . . . .
2.4. Resumen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
13
13
14
15
15
16
17
18
19
23
26
26
28
28
29
3. Seguridad Inform
atica
3.1. Conceptos B
asicos de Criptografa . . .
3.1.1. Cifrados Simetricos . . . . . . . .
3.1.1.1. Seguridad . . . . . . . .
3.1.1.2. Ventajas y Desventajas
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
31
31
32
32
32
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

INDICE GENERAL
3.1.1.3. Algoritmos . . . . . . . . .
3.1.2. Cifrados Asimetricos . . . . . . . . .
3.1.2.1. Seguridad . . . . . . . . . .
3.1.2.2. Ventajas y Desventajas . .
3.1.2.3. Algoritmos . . . . . . . . .
3.1.3. Resumen Criptogr
aco . . . . . . . .
3.1.3.1. Hash . . . . . . . . . . . .
3.1.3.2. MAC . . . . . . . . . . . .
3.1.4. Firma Digital . . . . . . . . . . . . .
3.1.5. PKI . . . . . . . . . . . . . . . . . .
3.1.5.1. Prop
osito y funcionalidad .
3.1.5.2. Usos de la tecnologa PKI .
3.1.5.3. Certicados . . . . . . . . .
3.1.6. Componentes . . . . . . . . . . . . .
3.1.6.1. Consideraciones sobre PKI
3.2. Resumen . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
4. Seguridad en Redes M
oviles
4.1. Ataques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.1.1. Ataques Externos . . . . . . . . . . . . . . . . . . . . . .
4.1.1.1. Interceptaci
on Pasiva . . . . . . . . . . . . . .
4.1.1.2. Interferencia Activa . . . . . . . . . . . . . . .
4.1.2. Ataques Internos . . . . . . . . . . . . . . . . . . . . . .
4.1.2.1. Nodo Fallido . . . . . . . . . . . . . . . . . . .
4.1.2.2. Nodo Fallido Maligno . . . . . . . . . . . . . .
4.1.2.3. Nodo egosta . . . . . . . . . . . . . . . . . . .
4.1.2.4. Nodo Malicioso . . . . . . . . . . . . . . . . . .
4.2. Protocolos de Ruteo Seguros . . . . . . . . . . . . . . . . . . .
4.2.1. SRP - Secure Routing Protocol . . . . . . . . . . . . . .
4.2.1.1. Descubrimiento de la Ruta . . . . . . . . . . .
4.2.1.2. Otras Vulnerabilidades . . . . . . . . . . . . .
4.2.1.3. Ideas Rescatadas para el Desarrollo de la Tesis
4.2.2. ARIADNE . . . . . . . . . . . . . . . . . . . . . . . . .
4.2.2.1. Ideas Rescatadas para el Desarrollo de la Tesis
4.2.3. Resumen . . . . . . . . . . . . . . . . . . . . . . . . . .
5. Redes M
oviles Urbanas
5.1. Proyectos Comunitarios Libres
5.1.1. Buenos Aires Libre . . .
5.2. Topologa . . . . . . . . . . . .
5.2.1. Direccionamiento IP . .
5.3. Protocolos de Ruteos . . . . . .
2
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. .
.
. .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
32
33
33
34
34
34
34
35
35
36
36
37
37
38
38
38
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
41
42
42
42
43
43
43
43
44
44
46
46
46
48
48
48
50
50
.
.
.
.
.
51
52
52
53
54
55
tica

INDICE GENERAL
5.4. Servicios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
5.5. Administraci
on de la Red BAL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
5.6. Resumen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
6. Protocolo OLSR
6.1. Introducci
on . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.2. Terminologa Propia de OLSR . . . . . . . . . . . . . . . . . . .
6.3. Tablas del Protocolo . . . . . . . . . . . . . . . . . . . . . . . .
6.4. C
omo Funciona? . . . . . . . . . . . . . . . . . . . . . . . . . .
6.4.1. Mensajes de OLSR . . . . . . . . . . . . . . . . . . . . .
6.4.2. Etapa 1: Censado y Descubrimiento de Vecinos . . . . .
6.4.2.1. Mensaje de HELLO . . . . . . . . . . . . . . .
6.4.2.2. Mensaje MID . . . . . . . . . . . . . . . . . . .
6.4.2.3. Censado y Descubrimiento . . . . . . . . . . .
6.4.3. Etapa 2: Elecci
on de los MPRs . . . . . . . . . . . . . .
6.4.4. Etapa 3: Mantenimiento de la Topologa . . . . . . . . .
6.4.4.1. Mensaje TC . . . . . . . . . . . . . . . . . . .
6.4.4.2. Mecanismo de propagacion de los mensajes TC
6.4.5. Etapa 4: Formaci
on de las Rutas . . . . . . . . . . . . .
6.4.6. Etapa 5: Mantenimiento de las Rutas . . . . . . . . . .
6.4.7. Comunicaci
on con Otras Redes . . . . . . . . . . . . . .
6.4.7.1. Mensaje HNA . . . . . . . . . . . . . . . . . .
6.4.7.2. Asociaci
on de la redes . . . . . . . . . . . . . .
6.5. Seguridad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.5.1. Condencialidad . . . . . . . . . . . . . . . . . . . . . .
6.5.2. Integridad . . . . . . . . . . . . . . . . . . . . . . . . . .
6.5.3. Mensajes a Proteger . . . . . . . . . . . . . . . . . . . .
6.6. Vulnerabilidades . . . . . . . . . . . . . . . . . . . . . . . . . .
6.7. Resumen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
7. Dise
no de un Esquema de Seguridad para una Red M
ovil OLSR Urbana
7.1. Esquema de Seguridad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.2. Fundamentos del Dise
no . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.2.1. OLSR m
as Fuerte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.3. Esquema de Clave P
ublica y Privada . . . . . . . . . . . . . . . . . . . . . . . .
7.3.1. Autoridad Certicante . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.3.2. Esquema de Certicacion . . . . . . . . . . . . . . . . . . . . . . . . . .
7.4. Fortalecimiento de OLSR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.4.1. Prevenci
on de Ataques . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.5. Integraci
on del IDS y la CA . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.6. Interacci
on de los Nodos Clientes con Esquema de Seguridad Planteado . . . .
7.6.1. Esquema de conanza ganada . . . . . . . . . . . . . . . . . . . . . . . .
tica
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
57
57
57
58
60
60
61
61
63
64
65
68
69
69
70
71
71
71
72
72
72
73
73
74
77
.
.
.
.
.
.
.
.
.
.
.
79
79
80
80
81
81
81
83
83
84
84
84
3

INDICE GENERAL
7.7. Resumen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
8. Artculos m
as Relevantes Relacionados con la Seguridad de OLSR
8.1. Secure Extension to the OLSR protocol . . . . . . . . . . . . . . . . .
8.1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.1.2. Firma . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.1.3. Timestamps . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.2. Secure OLSR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.2.2. Detecci
on segura de vecino . . . . . . . . . . . . . . . . . . . .
8.2.3. Autenticacion de vecinos . . . . . . . . . . . . . . . . . . . . . .
8.2.4. Paquetes de Ruteo Seguros . . . . . . . . . . . . . . . . . . . .
8.3. Securing the OLSR protocol . . . . . . . . . . . . . . . . . . . . . . . .
8.3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.3.2. Firma de Mensajes . . . . . . . . . . . . . . . . . . . . . . . . .
8.3.3. Timestamping . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.3.4. PKI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.3.4.1. PKI Proactiva Simple para OLSR . . . . . . . . . . .
8.3.4.2. PKI Reactiva Simple para OLSR . . . . . . . . . . . .
8.4. Resumen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
9. Detalles de Implementaci
on del Esquema de Seguridad Propuesto
9.1. Esquema de Certicaci
on . . . . . . . . . . . . . . . . . . . . . . . . .
9.1.0.3. Procedimiento para la registracion de un nodo . . . .
9.2. Fortalecimiento del Protocolo OLSR . . . . . . . . . . . . . . . . . . .
9.3. Fortalecimiento de OLSR: Nivel 1 . . . . . . . . . . . . . . . . . . . . .
9.3.1. Tablas del Protocolo . . . . . . . . . . . . . . . . . . . . . . . .
9.3.2. Obtenci
on del Certicado . . . . . . . . . . . . . . . . . . . . .
9.3.2.1. Generaci
on del mensaje CADISCOVER . . . . . . . . . .
9.3.2.2. Procesamiento del mensaje CADISCOVER . . . . . . .
9.3.2.3. Generaci
on del CERTREQ . . . . . . . . . . . . . . .
9.3.2.4. Generaci
on del Certicado . . . . . . . . . . . . . . .
9.3.2.5. Renovaci
on de certicado . . . . . . . . . . . . . . . .
9.3.3. Detecci
on de Vecinos . . . . . . . . . . . . . . . . . . . . . . . .
9.3.3.1. Autenticaci
on de los vecinos . . . . . . . . . . . . . .
9.3.3.2. Elecci
on de MPR . . . . . . . . . . . . . . . . . . . .
9.3.4. Firma y encripci
on de los mensajes . . . . . . . . . . . . . . . .
9.3.4.1. Obtenci
on de la Clave de Sesion . . . . . . . . . . . .
9.3.4.2. Firma de los mensajes . . . . . . . . . . . . . . . . . .
9.3.4.3. Protocolo de encriptacion . . . . . . . . . . . . . . . .
9.3.5. Descubrimiento de la Topologa . . . . . . . . . . . . . . . . . .
9.3.6. Armado de la tabla de Ruteo . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
97
. 97
. 98
. 98
. 99
. 99
. 100
. 100
. 100
. 101
. 102
. 102
. 103
. 104
. 106
. 106
. 106
. 108
. 109
. 109
. 110
87
88
88
88
88
89
89
89
90
91
92
92
92
93
93
94
94
95
tica

INDICE GENERAL
9.3.7. Logros del Nivel 1 de securizacion . . . . . . . . . . . . . . .

9.4. Fortalecimiento de OLSR: Nivel 2 . . . . . . . . . . . . . . . . . . . .
9.4.1. Prevenci
on contra ataque Wormhole . . . . . . . . . . . . . .
9.4.2. Prevenci
on contra ataque de reenvo de mensajes: Timestamp
9.4.3. Prevenci
on contra ataques de DoS . . . . . . . . . . . . . . .
9.4.4. Otros ataques mitigados . . . . . . . . . . . . . . . . . . . . .
9.4.5. OLSR RFC 3226 vs. OLSR Seguro . . . . . . . . . . . . . . .
9.5. Fortalecimiento de OLSR: Nivel 3 . . . . . . . . . . . . . . . . . . . .
9.5.1. Mecanismo de Denuncia . . . . . . . . . . . . . . . . . . . . .
9.5.2. Sistema de Detecci
on de Intrusos . . . . . . . . . . . . . . . .
9.5.2.1. Interacci
on con las CAs . . . . . . . . . . . . . . . .
9.5.3. Sincronizaci
on de CRLs . . . . . . . . . . . . . . . . . . . . .
9.6. Debilidades del Esquema de Seguridad propuesto . . . . . . . . . . .
9.7. Resumen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10.Prueba de Contenido
10.1. Arquitectura . . . . . . . . . . . . . . . . . . . . . . . .
10.1.1. Certicados y Keystores . . . . . . . . . . . . . .
10.1.2. Conguraci
on del Nodo . . . . . . . . . . . . . .
10.1.3. Plugin olsrd para generar el archivo de topologa
10.1.4. Mensajes . . . . . . . . . . . . . . . . . . . . . .
10.1.5. M
odulo de Autoridad Certicante . . . . . . . .
10.1.6. M
odulo de Autenticacion con los vecinos . . . . .
10.1.7. M
odulo de Procesamiento de mensajes OLSR . .
10.2. Implementacion . . . . . . . . . . . . . . . . . . . . . . .
10.2.1. Descubrimiento de CAs y Vecinos . . . . . . . .
10.2.1.1. Demonio de Procesamiento de mensajes
10.2.2. Autoridad Certicante . . . . . . . . . . . . . . .
10.2.2.1. Interacci
on Nodo-CA . . . . . . . . . .
10.2.3. Autenticaci
on con los Vecinos . . . . . . . . . . .
10.3. Modos de Operaci
on del Simulador . . . . . . . . . . . .
10.4. Resumen . . . . . . . . . . . . . . . . . . . . . . . . . . .
11.Conclusiones
tica
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
OLSR
. . . .
. . . .
. . . .
. . . .
. . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 110
. 111
. 111
. 112
. 113
. 114
. 114
. 115
. 115
. 115
. 115
. 115
. 116
. 116
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
117
. 118
. 119
. 119
. 119
. 119
. 120
. 121
. 121
. 121
. 121
. 122
. 122
. 123
. 123
. 124
. 125
127

INDICE GENERAL
tica
Indice de guras
2.1.
2.2.
2.3.
2.4.
2.5.
2.6.
2.7.
Clasicaci
on de protocolos de ruteo . . . . . . . . .
Multipoint Relays . . . . . . . . . . . . . . . . . .
Ejemplo de la construcci
on de una ruta en AODV
Detecci
on de un enlace roto y envo del RERR . .
Ejemplo de la construcci
on de una ruta en DSR . .
Zona de un nodo usando ZRP . . . . . . . . . . .
Descubrimiento de una ruta con IERP . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
15
17
22
24
25
27
27
3.1. Proceso de Generaci

on y Vericacion de una Firma Digital . . . . . . . . . . . . . 36
4.1. Formato del encabezado de un protocolo de ruteo con la extension de SRP . . . . . 47
4.2. Encabezado de SRP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.3. Encabezado SRP con extension INRT . . . . . . . . . . . . . . . . . . . . . . . . . 48
5.1. Diagrama de una red M
ovil Urbana . . . . . . . . . . . . . . . . . . . . . . . . . . 54
6.1. Etapas del protocolo OLSR . . . . . . . . . . . . . . . . . . . . .
6.2. Formato del paquete de OLSR . . . . . . . . . . . . . . . . . . .
6.3. Campo de 8 bits para indicar el codigo del enlace . . . . . . . . .
6.4. Formato del mensaje de HELLO . . . . . . . . . . . . . . . . . .
6.5. Formato del mensaje MID . . . . . . . . . . . . . . . . . . . . . .
6.6. Censado y Descubrimiento de Vecinos - Parte 1 . . . . . . . . . .
6.7. Censado y Descubrimiento de Vecinos - Parte 1 . . . . . . . . . .
6.8. Multipoint Relays . . . . . . . . . . . . . . . . . . . . . . . . . .
6.9. Fase 1 : Selecci
on de MPRs que cubren nodos aislados del Nivel2.
6.10. Fase 2: Se completa la selecci
on de MPRs. . . . . . . . . . . . . .
6.11. Formato del mensaje TC . . . . . . . . . . . . . . . . . . . . . . .
6.12. Formato del mensaje HNA . . . . . . . . . . . . . . . . . . . . . .
6.13. Generaci
on incorrecta de mensajes HELLO . . . . . . . . . . . .
6.14. Generaci
on incorrecta de mensajes TC . . . . . . . . . . . . . . .
6.15. Ataque por t
unel (Wormhole) . . . . . . . . . . . . . . . . . . . .
6.16. Ataque al (MPR-Flooding) . . . . . . . . . . . . . . . . . . . . .
7
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
61
62
62
63
64
65
66
67
68
68
69
72
74
75
76
76

INDICE DE FIGURAS
7.1. Componentes participantes en el esquema de seguridad propuesto . . . . . . . . . 81

7.2. Esquema de Certicaci
on. CA de la comunidad expide certicados a los nodos
enrolados y estos expiden certicados a los clientes . . . . . . . . . . . . . . . . . . 82
7.3. Ejemplo de utilizaci
on de una red Movil Urbana Segura interconectando distintas
plazas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
8.1.
8.2.
8.3.
8.4.
Mensaje de rma b
asico . . . . .
Pasos para lograr una relaci
on de
Extensi
on del paquete OLSR . .
Formato del mensaje de rma . .
. . . . . . . .
conanza con
. . . . . . . .
. . . . . . . .
. . . . . .
un vecino
. . . . . .
. . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 100
. 101
. 101
. 103
. 104
. 105
. 107
. 107
. 108
. 109
. 110
. 111
. 113
. 114
10.1. Principales m
odulos del simulador . . . . . . . . . . . . . . .
10.2. Diagrama de Clases para los mensajes del protocolo . . . . .
10.3. Diagrama de Secuencia para la rma de un CertReq . . . . .
10.4. Diagrama de Secuencia de la obtencion de un certicado . . .
10.5. Instanciaci
on de m
odulos dependiendo el modo de operacion .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 118
. 120
. 122
. 123
. 124
9.1. Formato del mensaje CADISCOVER . . . . . .

9.2. Formato del mensaje CERTREQ . . . . . . . .
9.3. Formato del mensaje CERTREPLY . . . . . .
9.4. Formato del mensaje CERTRENEW . . . . . .
9.5. Formato del mensaje AUTH MESSAGE . . . .
9.6. Formato del mensaje AUTH MESSAGE FINISH
9.9. Generaci
on de la rma . . . . . . . . . . . .
9.10. Formato del mensaje rma . . . . . . . . .
9.11. Formato del paquete de OLSR rmado . . .
9.12. Firma + Encripci
on de un paquete . . . . .
9.13. Formato del mensaje rma con timestamp .
9.14. Etapas del protocolo OLSR . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
88
91
91
93
tica

INDICE DE FIGURAS
va
tica

INDICE DE FIGURAS
10
tica
Captulo 1
Introducci
on
El mundo de las telecomunicaciones crece da a da poniendo en nuestras manos distintas
alternativas de comunicaci
on. En estos u
ltimos tiempos el avance de la tecnologa ha puesto a
disposici
on del usuario nal tecnologas tan potentes como una maquina de escritorio en dispositivos de bolsillo. Estos dispositivos no son u
tiles o la mayora de sus utilidades no estan
disponibles si no est
an conectados a alguna red. La necesidad de interconectar estos dispositivos
es la causante de que la industria de las comunicaciones crezca tanto.
Los dispositivos m
oviles ser
an pronto el metodo preferido de acceso a la informacion. Las comunicaciones de estos dispositivos se hacen de manera inalambrica, brindando mayor comodidad
al usuario y pudiendo conectarse en cualquier lugar. Las conexiones inalambricas se hacen sobre
WLAN (Wireless Local Area Network) bajo el estandar 802.11. Este estandar permite dos modos
de operaci
on, uno es modo infraestructura y otro es modo ad-hoc. En modo infraestructura todos
los clientes de la red deben conectarse a un punto de acceso jo. En modo ad-hoc la comunicacion se hace directamente de dispositivo a dispositivo sin pasar por un punto de acceso jo. Esta
propiedad hace que las redes ad-hoc sean exibles y rapidas de desarrollar.
A medida que la demanda de conexiones crezca, estas van a ser mas necesarias, incluso en
lugares donde no exista una infraestructura para hacerlo. En este punto es donde entran en juego
las redes ad-hoc, las cuales brindan una manera agil para congurar una red autonoma.
Si bien la aplicaci
on de este tipo de redes esta pensada para un ambiente donde haya un gran
n
umero de dispositivos, y hoy en da sera difcil pensar un uso, en poco tiempo mas podramos
utilizar este tipo de redes por ejemplo para conectar todos los automoviles que circulan en una
autopista y en caso de haber un accidente todos los conductores se enteraran y podran evitar
congestiones utilizando desvos. Pensando en el futuro cuando todas las personas tengan un
dispositivo m
ovil, el uso de estas redes quedara limitada a la imaginacion y la creatividad.
Como cualquier red inal
ambrica, las redes ad-hoc estan expuestas a ataques de cualquier
persona ya que el medio fsico de propagacion es el aire. Las redes en modo infraestructura
cuentan con la ventaja de que todo el traco pasa por un punto de acceso jo en el cual se
pueden aplicar diferentes tecnicas y procedimientos de seguridad. Por el contrario, en las redes
ad-hoc, los mismos protocolos son los encargados de garantizar la seguridad de la red.
11
1.1. Motivaci
on
1.1.
Motivaci
on
Ya hace un tiempo que me he visto atrado por la tecnologa WiFi, la cual pertenece al
estandar 802.11. Luego de hacer distintas pruebas, armar diferentes antenas, probar diferentes
dispositivos es que me vi interesado por las redes ad-hoc y en particular las redes ad-hoc donde
los participantes de la misma estuviesen en movimiento. Otro aspecto importante por el que
siento curiosidad es por la seguridad en las redes inalambricas. Por otro lado, no existe ning
un
estandar sobre este tipo de redes, lo cual hace que una investigacion y analisis de los borradores
elaborados hasta el momento pueda hacer un aporte para la construccion de los protocolos. Estas
inquietudes sumadas al potencial uso de estas redes fueron los motivadores de esta tesis.
1.2.
Objetivo
El objetivo de la tesis es analizar las opciones y proponer alternativas para brindar seguridad
en una red m
ovil urbana basada en el protocolo OLSR.
El protocolo OLSR se utiliza en el proyecto BAL (Buenos Aires Libre) y en proyectos de redes
moviles urbanas en todo el mundo por lo que la aplicacion de su estudio y analisis de securizacion
tiene un uso potencial signicativo.
En el desarrollo de la tesis se analizaran protocolos de ruteo de redes moviles, se realizaran
comparaciones entre los mismos dando especial enfasis en los aspectos de seguridad con el objetivo
de tomar ideas para realizar el dise
no de un protocolo OLSR seguro.
Se estudiar
a y detallar
a como funciona una red movil basada en OLSR, principales tecnicas
de ataque y posibles alternativas de prevencion.
Del analisis de los protocolos de ruteo existentes, se propondra la manera de mejorar la
seguridad de una red m
ovil urbana, en particular para una topologa similar a la de BAL.
Para lograr este objetivo se trabajar
a en un esquema de arquitectura de seguridad de acuerdo
al uso de la red y al grado de participaci
on de los nodos en la misma.
La tesis tendr
a en mente lograr mejorar la capacidad del protocolo de obtener disponibilidad,
integridad, condencialidad, autenticaci
on y no repudio de sus paquetes de control.
12
tica
Captulo 2
Redes M
oviles
El objetivo del presente captulo es dar una introducci
on a las Redes M
oviles
y presentar los principales protocolos de ruteo para dar un marco te
orico al lector
y conocer distintas alternativas para un mismo objetivo, rutear nodos en un Red M
ovil.
Dentro del mundo de las redes las conguraciones mas conocidas son:
Redes Fijas: son aquellas redes donde los componentes que la integran son jos y estan
interconectados generalmente por cable.
Redes Inal
ambricas: en esta categora se encuentran las redes donde sus componentes
podran estar en movimiento pero siempre conectados de manera inalambrica a un punto
jo o las redes ad-hoc, en las cuales los integrantes de la red se comunican entre s mediante
una conexi
on inal
ambrica. Por u
ltimo y dentro de la categora de las redes inalambricas
(ad-hoc) est
an las Redes M
oviles (MANETs, Mobile ad-hoc NETwoks). Este tipo de redes
es el que analizaremos en detalle.
2.1.
Generalidades
Las MANETs son redes donde los nodos o integrantes de la red se mueven. Por esta razon, los
protocolos de ruteo existentes para redes jas no funcionan, ya que es necesario que la topologa
de la red se vaya cambiando din
amicamente. En estas redes, el concepto de Servidor utilizado
en una red ja cambia ya que en estas siempre logramos conectarnos, en cambio en una red con
estas caractersticas no siempre se puede acceder a un nodo, con lo cual en una MANET podra
no haber DNSs o Entidades Certicantes (CAs), etc.
13
2.2. Protocolos de Ruteo
2.2.
Protocolos de Ruteo
El ruteo en la redes m
oviles ha sido un desafo, ya que la naturaleza de la red tiene muchas
variables (tama
no, disposicion de los nodos, uso del ancho de banda, ahorro de energa, etc) que
son muy difciles de ser contempladas por todos los protocolos.
Protocolos como los utilizados en redes jas (Distance-Vector o Link-State) no se pueden
utilizar en las redes m
oviles ya que la informacion de la distancia de los integrantes de la red
vara con gran frecuencia. Esto insumira mucho ancho de banda y batera de los dispositivos
moviles para mantener esa informaci
on actualizada en cada nodo.
Para dise
nar un protocolo para redes ad-hoc se debera tener en cuenta las siguientes cuestiones
[1, Chap. 10.1]:
Mnimo overhead de paquetes de control: Si se disminuye el n
umero de paquetes de control,
se ahorra ancho de banda y batera en los dispositivos.
Mnimo tiempo de procesamiento: Los algoritmos elegidos tienen que ser simples, as de
esta manera no se insume tiempo de bateras en procesamiento.
Capacidad de ruteo con m
ultiples saltos: Como los dispositivos muchas veces no tienen
transmisi
on directa, se requiere que estos se puedan comunicar a traves de un tercero que
s esta en el rango de transmisi
on directa.
Mantenimiento din
amico de la topologa: Una vez que se tiene establecida una ruta es muy
com
un por la caracterstica de la red que se pierda el vnculo, ya sea con el destino o
entre algunos dispositivos que ayudan en el trayecto. Por lo tanto el protocolo tiene que
solucionar las perdidas de conexi
on con un overhead mnimo.
Prevenci
on de bucles: Se forma un bucle cuando se arma una ruta que elige como proximo
nodo uno que existe dentro de la ruta calculada hasta el momento. Los bucles hacen que
los datos y los paquetes de control pasen y sean procesados innecesariamente por un nodo
muchas veces.
Modo de operaci
on inactivo: El protocolo debe estar preparado para que en perodos donde
la actividad de la red baje sea capaz de dormirse y de esta manera consumir menos
energa.
Durante la evoluci
on de las MANETs se han desarrollado muchos protocolos teniendo en
cuenta las cuestiones listadas anteriormente. En las siguientes secciones ( 2.3.1, 2.3.2, 2.3.3) se
va a desarrollar la presentaci
on de distintos protocolos, clasicados en distintos grupos seg
un su
forma de generar las rutas. Luego se ver
an distintos protocolos que logran tener redundancia de
las rutas para minimizar los tiempos de rearmado de la ruta en caso de la perdida de la misma
( 2.3.4).
14
tica
Redes M
oviles
Figura 2.1: Clasicaci

on de protocolos de ruteo
2.3.
Protocolos de Ruteo Proactivos, Reactivos e Hbridos
Los protocolos de ruteo para Redes M

oviles tiene sus bases sobre los protocolos de redes cableadas. Como fue comentado anteriormente (2.2) estos protocolos necesitan intercambiar mucha
informaci
on para mantener las rutas haciendo que sea imposible ser implementados en un ambiente tan cambiante y con enlaces tan poco estables como los de las Redes M
oviles. Para superar
los problemas asociados a los algoritmos Link-State y Distance-Vector se han desarrollado una
variedad de protocolos los cuales se pueden clasicar como lo indica la Figura 2.1 [2]. En los protocolos proactivos las rutas hacia todos los destinos de la red (o gran parte de ella) son calculadas
al principio y luego se mantiene utilizando procesos de actualizacion periodicos. En los protocolos
reactivos las rutas son calculadas en el momento que son requeridas utilizando un procedimiento
de descubrimiento hacia el destino. Los protocolos hbridos combinan las propiedades basicas de
cada uno de las otras dos clases de protocolos.
2.3.1.
Protocolos de Ruteo Proactivos
Los protocolos de ruteo proactivos [2, Sec. 2] o basados en tablas son aquellos que mantienen
la informaci
on acerca de c
omo llegar a todos los destinos (nodos) de la red. Esta informacion es
almacenada en tablas las cuales son actualizadas periodicamente cuando hay modicaciones en
la topologa de la red.
La diferencia entre los distintos protocolos de esta clase es la manera en la que actualizan las
tablas, la cantidad de tablas que utilizan, la informacion de cada tabla y la manera de encontrar
la informaci
on. Los protocolos m
as 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.
.
tica
15
2.3.1. Protocolos de Ruteo Proactivos
2.3.1.1.
Destination-Sequenced Distance-Vector (DSDV)
El protocolo de ruteo de Destination-Sequenced Distance-Vector (DSDV) es un protocolo

proactivo de Distance-Vector. Este protocolo esta basado en el clasico protocolo de DistanceVector de Bellman-Ford (DBF) [4] modicado para prevenir lazos cerrados (loops). Este protocolo sirve para encontrar a partir del algoritmo de Distance-Vector cual es el camino mas corto
hasta llegar al destino [3, Sec. 3]. El DSDV por ser un algoritmo proactivo mantiene una tabla
con todos los destinos posibles de la red y la cantidad de saltos para llegar a cada uno. Cada
entrada en esta tabla est
a etiquetada con un n
umero de secuencia el cual es generado por el nodo
destino. La tabla contiene los siguientes datos:
Direcci
on IP destino
Nro de secuencia de destino
Direcci
on IP del pr
oximo salto hacia el destino
Nro de saltos hasta el destino
Time stamp
Esta tabla debe ser mantenida peri
odicamente para actualizar los cambios que puedan sucederse en la red. Estas actualizaciones se realizan a traves de mensajes broadcast o multicast. Los
datos enviados por cada nodo contienen su nuevo n
umero de secuencia y la informacion referente
a cada nueva ruta. Cuando el destino recibe esa informaci
on actualiza sus propias tablas de ruteo.
Las tablas de ruteo tambien son enviadas si se detecta alg
un cambio en la topologa. Los nodos
utilizan los n
umeros de secuencia de destino para poder distinguir entre rutas antiguas y rutas
nuevas hacia un mismo destino. Un nodo incrementa su n
umero de secuencia cuando se produce
un cambio a nivel local en la topologa de sus vecinos. La ruta hacia el destino que tenga el
n
umero de secuencia m
as grande (m
as reciente) sera la elegida. En caso que existan dos rutas
con el mismo destino y mismo n
umero de secuencia, sera elegida la que tenga menos saltos hacia
el destino. En la redes con gran cantidad de nodos se generaran muchas colisiones en el traco
broadcast (storm of broadcast), para ello el protocolo utiliza dos tipos de paquetes para actualizar
la informaci
on:
full dump: Transporta la informacion de todas las rutas.
incremental : Transporta s
olo la informacion de las rutas nuevas (variacion desde un full
dump)
Los paquetes incrementals, por razones de dise
no deben entrar dentro de una unidad de datos
de protocolo (NPDU-Network Protocol Data Unit). Cuando las actualizaciones de las rutas son
varias y el tama
no de dicha informaci
on se acerca al tama
no de la NPDU, el proximo paquete
sera un full dump. De esta manera se optimiza el envo de paquetes. Sin embargo este protocolo
no podra escalar hacia grandes redes ya que requiere de un envo de paquetes de O(N 2 ), donde
N es el n
umero de nodos de la red. Se podra dar el caso que un nodo reciba informacion de ruteo
16
tica
Redes M
oviles
sobre un destino que es mejor que la que tiene por lo que, este informara a sus vecinos antes de
recibir todos los mensajes de actualizacion de la ruta. Por esto es que DSDV tiene un mecanismo
para mitigar este tipo de comportamiento que consiste en establecer un tiempo jo para informar
los cambios. Este tiempo es calculado como el tiempo promedio que tarda en recibir el nodo
todos los paquetes de actualizaci
on de una ruta. De esta manera el nodo se asegura de enviar la
informaci
on de la nueva ruta luego que recibio todos los paquetes de actualizacion y disminuye
el uso de ancho de banda y consumo de energa 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 ruteo
proactivo basado en el protocolo Link-State. La principal caracterstica es que utiliza multipoint
relays (MPRs) para minimizar el ooding en la red y la cantidad de links que se deben mantener.
Cada nodo de la red elige un conjunto de nodos a los cuales los marca como MPRs, el resto de
los vecinos reciben los mensajes pero no los reenvan. Solo los MPRs reenvan los mensajes. El
nodo debe elegir a los MPRs, de manera tal de llegar a traves de estos a todos los vecinos que
estan a dos saltos de distancia. En la Figura 6.8 se ve que el nodo O elige los nodos 1, 2, 4 y 5
ya que a traves de ellos puede llegar a todos los vecino de dos saltos de distancia.
Figura 2.2: Multipoint Relays
Elecci
on de los Multipoints Relays El mecanismo de seleccion de los MPRs [6, Sec. 4.2] se
realiza mediante el intercambio de mensajes de HELLO. Un mensaje de HELLO es el mensaje
que se utiliza en OLSR para validar el estado de los enlaces de un nodo con su vecino. El
mensaje contiene una lista de los nodos con los cuales se tiene un enlace bidireccional y una
lista de direcciones de vecinos de los cuales se ha recibido un mensaje de HELLO. Un enlace es
unidimensional cuando un nodo recibe un mensaje de HELLO, pero si en ese mensaje gura su
direcci
on en la lista de direcciones de vecinos hace que ese enlace sea bidireccional y lo almacena
en la tabla neighbor table.
El algoritmo de selecci
on de los MPRs es:
1. Selecciona los nodos del Nivel 1 que cubren nodos aislados del Nivel 2. Nodo aislado es
tica
17
2.3.2. Protocolos de Ruteo Reactivos
aquel nodo que pertenece al Nivel 2 y tiene como vecino a un solo nodo del Nivel 1.
2. Se toman los vecinos de Nivel 1 que no fueron seleccionados en el paso anterior y se selecciona
el nodo que cubra el mayor n
umero de nodos de Nivel 2. Esto se repite hasta que todos los
nodos de Nivel 2 hayan sido cubiertos.
El conjunto de MPRs son recalculados cada vez que hay alg
un cambio en los enlaces con los
vecinos.
C
alculo 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 distribudos
por la red utilizando broadcast. Cada MPR enva mensajes TC informando cuales nodos lo han
elegido a el como MPR (informa su MPR Selector ).
La informaci
on difundida por la red a traves de los TC ayudan a cada nodo a armar su tabla
de topologa (topology table). Esta tabla existe en todos los nodos de la red y es utilizada para
establecer las rutas. Cada entrada en la tabla de topologa contiene la direccion de un potencial
destino, la direcci
on del u
ltimo salto a ese destino (origen del mensaje TC ) y el n
umero de
secuencia correspondiente al nodo que envio el mensaje. Cada entrada en la tabla de topologa
tiene un timestamp para vericar la validez de la misma.
Para el armado de la tabla de ruteo, el nodo utiliza tanto la tabla de vecinos como la tabla de
topologa, en esta u
ltima utiliza la direccion de u
ltimo salto para armar el recorrido comenzando
por el destino y luego recorrer la tabla en orden descendente para armar el camino. Por ejemplo si
se quiere unir un punto remoto R, primero se busca el par (X, R), luego el par (Y, X) y as hasta
completar la ruta. En el momento del armado de la ruta se controlan los n
umeros de secuencia
para detectar cambios en la topologa y as invalidar rutas. Como la tabla de ruteo depende de
la tabla de vecinos y de la tabla de topologa, cualquier cambio en alguna de ellas implica la
reconstruccion de las rutas.
Cada entrada en la tabla de ruteo contiene la direccion del destino, la direccion del proximo
salto y el n
umero de saltos.
2.3.2.
Protocolos de Ruteo Reactivos
Los protocolos de ruteo reactivos [1, Sec 10.3] son aquellos que construyen las rutas bajo
demanda, es decir en el momento en el que un nodo origen necesita enviar un mensaje a un nodo
destino se crean las rutas desde el origen al destino. Con este tipo de protocolos se optimiza el
uso de recursos de ancho de banda y el uso de batera pero por otro lado se penaliza la latencia
en encontrar la ruta.
Cuando un nodo quiere enviar un mensaje y la ruta hacia el destino no existe comienza el
procedimiento de descubrimiento con un mensaje de peticion de ruta (Route Request) de tipo
broadcast y recibir
a un mensaje de respuesta con la ruta (Route Reply). Si el mensaje de peticion
de ruta viaj
o por un links bidireccionales, el mensaje Route Reply puede utilizar la misma ruta
entonces el overhead introducido por el descubrimiento (en el peor de los casos) crecera con
O(N + M ) [2] donde N es el la cantidad de nodos de la red y M es el n
umero de nodos en el
18
tica
Redes M
oviles
camino de vuelta con la respuesta. Cuando los enlaces son unidireccionales el overhead introducido
es de O(2N ).
Los protocolos reactivos pueden clasicarse en dos categora:
Basados Ruteo del origen (source routing): En esta modalidad cada paquete de datos transporta en su cabecera la ruta completa desde el origen al destino, es decir, todas la direcciones
de los nodos intermedios. Cada nodo intermedio utilizara la cabecera del mensaje para saber donde reenviarlo, de esta manera no es necesario que cada nodo mantenga una tabla
con las rutas como en los protocolos proactivos. Por otro lado este tipo de protocolos no es
recomendado para redes m
oviles grandes donde haya mucha movilidad de los nodos ya que
es m
as probable que los enlaces se rompan y al haber tanta cantidad de nodos las cabeceras
de los mensajes van a ser muy grandes.
Basados en salto a salto (hop-by-hop): En esta modalidad cada paquete lleva la direcci
on
del destino y la del pr
oximo salto, de forma tal que cada nodo intermedio debera consultar
su 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 que
cambia la red. La desventaja es que cada nodo intermedio debe almacenar y mantener la
informacion de cada una de rutas mediante el intercambio de mensajes con sus vecinos.
Los protocolos m
as 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 las
rutas a todos los destinos de la red sino que solo mantiene las rutas necesarias para alcanzar un
destino en particular.
AODV presenta las siguientes caractersticas:
Bajo overhead : Al no realizarse actualizaciones periodicas de la informacion de todos los
nodos, se garantiza un mnimo uso de ancho de banda para los paquetes de control.
Bajo overhead de procesamiento: Los mensajes enviados son cortos y no requieren mucho
calculo.
Previene la formaci
on de bucles: Provee un mecanismo para la prevencion de formacion de
bucles utilizando n
umeros de secuencia en los mensajes.
Tipo de mensajes de control que utiliza AODV:
tica
19
RREQ (Route Request): Mensaje que se enva cuando se necesita una ruta.
RREP (Route Reply): Mensaje de respuesta a la solicitud de una ruta.
RERR (Route Error): Este mensaje se enva cada vez que se detecta una rotura de enlace
y deja a un destino inaccesible.
Con el n de prevenir bucles cada nodo mantiene un n
umero de secuencia que sirve para
evaluar la vigencia de la informaci
on asociada a cada mensaje que enva el nodo. El n
umero de
secuencia aumenta en uno cada vez que un nodo enva un mensaje RREQ. Si un nodo recibe
un RREQ donde el destino es el mismo, antes de generar el mensaje de respuesta RREP debe
actualizar el n
umero de secuencia Sec#D al valor maximo entre su n
umero de secuencia actual
Sec#D actual y el n
umero de secuencia del destino que se encuentra contenido en el RREQ
(RREQ.Sec#) m
as uno.
Los n
umeros de secuencia sirven para que siempre se seleccione la ruta mas reciente hacia un
destino. En el caso que un nodo intermedio tenga dos rutas hacia un destino y estas tengan un
mismo n
umero de secuencia, escoger
a la que tenga la mnima cantidad de saltos.
Descubrimiento de la ruta El descubrimiento de la ruta [8, Sec. 2.1] (Path Discovery) se
inicia cuando un nodo necesita comunicarse con otro y no existe una entrada en su tabla de
ruteo. Cada nodo mantiene dos contadores independientes: un n
umero de secuencia del nodo
(node sequence number ) y un identicador para los paquetes broadcast (broadcast id ).
Los pasos para el descubrimiento de la ruta son:
El nodo origen inicializa el proceso de descubrimiento mediante la emision de un mensaje
broadcast de tipo RREQ (route request) a sus vecinos (Figura 2.3(b))
El par < direccion origen, broadcast id > identica unvocamente al mensaje RREQ. El
broadcast id se incrementa cada vez que el origen genera un nuevo mensaje RREQ
Si alguno de los vecinos tiene una ruta hacia el destino solicitado, contesta con un mensaje
RREP y en caso contrario reenva el mensaje RREQ a sus vecinos (Figura 2.3(c)) luego de
incrementar la cantidad de saltos. Como un nodo puede recibir muchas veces el mismo mensaje
RREQ, descarta aquellos donde la direccion de origen y el broadcast id son iguales a los dos de
un mensaje recibido con anterioridad (Figura 2.3(d)).
Cada vez que el nodo no puede satisfacer la ruta solicitada, guarda la informacion para luego
implementar el armado del camino reverso (reverse path)
La informaci
on almacenada en esta tabla tiene un tiempo de vida limitado, cuando se cumple
ese tiempo la informaci
on es eliminada de la misma. La ruta inversa sirve para cuando el nodo
recibe un mensaje RREP (Figura 2.3(e)), este es enviado hacia el origen a traves de esta ruta
inversa.
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 (Figura 2.3(g)) ya que este nodo tiene una ruta de camino inverso
Cuando un nodo intermedio recibe un mensaje RREP incrementa el n
umero de saltos del
mensaje RREP, inserta una entrada en la tabla de ruteo (Figura 2.3(h)). La entrada en la tabla
20
tica
Redes M
oviles
utiliza al nodo origen del mensaje RREP como proximo salto hacia el destino. A este paso se lo
llama denir un Forward Path [9].
Si un nodo recibe m
as de un mensaje RREP para un destino por parte de mas de un vecino,
este reenva el primer RREP.
Cuando el nodo origen recibe un mensaje RREP ya puede comenzar a utilizar la ruta para enviar datos. En el caso que el nodo origen reciba mas de una ruta hacia el destino, este
utilizar
a aquella que tenga menor n
umero de saltos y el mayor n
umero de secuencia del destino.
De esto se puede observar que AODV no siempre calcula la menor ruta en cuanto a saltos
ya que el hecho de descartar los RREQ que lleguen luego de un RREQ que tienen igual campo
on IP del nodo origen hace que rutas probablemente mas cortas no se lleguen
bradcast id y direcci
a 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 los
enlaces y de esta manera hacer que la ruta no pueda ser utilizada.
AODV enva peri
odicamente mensajes de hello (es un mensaje RREP especial ya que no
es respuesta de un RREQ) para asegurarse que los enlaces simetricos esten utilizables. Este
mensaje de hello contiene la direccion IP del nodo, su n
umero de secuencia (no cambia el n
umero
de secuencia con el envo de estos mensaje) y el tiempo de vida del enlace. Si se recibe un mensaje
de hello de un nuevo vecino o no se recibe un mensaje de un nodo que perteneca al vecindario
se asume que hubo cambios entre los vecinos. Para garantizar que el enlace sea simetrico o
bidireccional enva un RREP y luego espera un RREP-ACK, si no se recibe el RREP-ACK el
nodo pone en su blacklist (lista negra) al nodo vecino e ignora los proximos RREQs debido a la
unidireccionalidad del enlace.
Cuando el nodo detecta la rotura de la ruta, la invalida y enva un mensaje RERR. En este
mensaje se enva todos los destinos que ya no pueden ser alcanzados. En el caso que haya nodos
intermedios entre el nodo origen y el nodo que detecto la ruptura y estos estaban utilizando el
enlace, el mensaje RERR se propaga en modo broadcast sino unicast.
Cuando un nodo recibe un mensaje RERR, este verica que el nodo del cual recibio sea el
proximo salto hacia alguno de los destinos informados, luego marca la entrada en la tabla como
invalida y reenva el mensaje RERR hacia el origen. Una vez que el origen recibe el mensaje
RERR, puede decidir reiniciar un proceso de b
usqueda de una nueva ruta en caso que la necesite.
Una de las caractersticas de AODV es que cuando detecta una rotura de enlace, el nodo no
enva un RERR en ese momento sino que reintenta reconstruir el enlace generando un RREQ
previo incremento del n
umero de secuencia. En el caso que no pueda restablecerlo enva el RERR
al origen.
Otra caracterstica que se incorpora al protocolo en los u
ltimos draft de Internet [7] es que
en cada mensaje de RREQ o RERR adicionan en la cabecera la ruta, de esta manera los nodos
que reciben mensajes de este tipo aprenden rutas no solo hacia el origen o hacia el destino sino
hacia otros nodos de la red.
tica
21
(a) El origen 1 quiere enviar datos a 10
(b) El nodo 1 enva un mensaje RREQ a sus

vecinos
(c) Los nodos 2, 3 y 4 reciben RREQ y los propagan a sus vecinos
(d) Se contin
ua la propagaci
on. Notar que 3 no
reenva el RREQ porque ya lo recibi
o antes
(e) Se contin
ua la propagaci
on. 5 no propaga
RREQ
(f) Se llega al nodo 10 y

este no reenva el
RREQ porque es el destino
(g) 10 determina la ruta para enviar RREP
(h) En cada salto que hace RREP, se establece

una ruta hacia el destino. Se completa la ruta
cuando llega a 1
Figura 2.3: Ejemplo de la construcci

on de una ruta en AODV
22
tica
Redes M
oviles
2.3.2.2.
Dynamic Source Routing (DSR)
El protocolo Dynamic Source Routing (DSR) [10] es un protocolo simple y eciente dise
nado
especcamente para redes inal
ambricas de multiples saltos donde los nodos de la misma estan
en continuo movimiento. El protocolo esta compuesto por dos mecanismos principales de Descubrimiento de la Ruta(Route discovery) y Mantenimiento de la Ruta(Route Maintenance),
los cuales trabajan en conjunto. Algunas caractersticas del protocolo son:
Bajo Overhead : por ser un protocolo bajo demanda, solo se enva overhead cuando es
necesario. No se utiliza mensajes de control (hello messages)
Multiples Rutas a un mismo destino y el nodo origen puede decidir y controlar el uso de
las rutas.
Loop Free: garantiza de manera facil y poco costosa la generacion de lazos.
Enlaces unidireccionales: puede funcionar con enlaces unidimensionales.
R
apido Recupero: recupero r
apido de la ruta ante un cambio en la red.
escalabilidad esta dise
nado 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 DSR
es un protocolo basado en ruteo desde el origen (source routed ) en vez de ser un protocolo de
salto en salto (hop-by-hop) donde cada paquete de datos sabe exactamente por que nodos va a
pasar hasta llegar al destino.
Descubrimiento de la Ruta El mecanismo de descubrimiento de la ruta [11, Sec 3.2], hace
uso de un cache donde se almacenan todas las rutas descubiertas para un destino. Cuando el
nodo desea enviar un paquete a un nodo destino primero busca en el cache si existe alguna ruta y
la utiliza, en caso de que la ruta falle, puede utilizar otra ruta del cache. De esta manera previene
el descubrimiento de una nueva ruta y acelera el proceso del envo del paquete en caso de una
falla. El mecanismo de descubrimiento comienza cuando un nodo quiere enviar un paquete a un
destino y no existe ninguna ruta en el cache. El nodo origen enva un mensaje RREQ (Route
Request) con la direcci
on del nodo origen (Figura 2.5(b)), la direccion del nodo destino y un
identicador de RREQ. Un mensaje RREQ adicionalmente contiene las direcciones de todos los
nodos intermedios que han reenviado el mensaje. Cuando un nodo vecino recibe el mensaje RREQ
busca en su cache si no tiene una ruta hacia el destino solicitado, en caso que as sea enva un
mensaje RREP (Route Reply) que contiene una copia de la ruta al destino y le concatena la ruta
acumulada que traa el RREQ (Figura 2.5(c)). En caso que el mensaje lo reciba el nodo destino,
este enva 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, verica si
ya ha recibido un mensaje con el mismo origen, mismo destino y mismo identicador de RREQ
o bien si su direcci
on est
a en el registro de ruta del mensaje RREQ. En este caso y con el n de
limitar el n
umero de mensajes RREQ que viajan por la red, este es descartado (Figura 2.5(d)).
tica
23
Por lo tanto los RREQs que se propagan durante el descubrimiento son los primeros en llegar a
un determinado nodo. Si se elige como ruta 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. Si
no se cumplen ninguna de las condiciones, el mensaje es retransmitido pero el nodo agrega su
direccion al registro de ruta.
Cuando un nodo debe devolver un mensaje RREP hacia el origen, se ja en su cache si
tiene una ruta hacia el origen, en caso que la tenga la utiliza, en caso contrario el nodo destino
debera comenzar su propio mecanismo de descubrimiento, pero para evitar una recursion innita
de b
usquedas de rutas, el nodo destino debera hacer piggyback (ponerlo al nal) del mensaje
RREP en su propio RREQ. En el caso que se utilicen enlaces simetricos, el nodo destino puede
utilizar la ruta recibida dentro del RREQ para hacer el camino inverso (Figura 2.5(e)). Para los
escenarios donde se utilizan protocolos de MAC como por ejemplo IEEE 802.11 que requieren
un intercambio bidireccional de tramas como parte del protocolo MAC garantizando enlaces
bidireccionales, se utiliza la tecnica de enviar el RREP a traves de la ruta incluida en el RREQ
ya que es lo m
as adecuado para evitar el overhead de descubrir una nueva ruta. El protocolo
MAC adem
as prueba que la ruta sea bidireccional antes de comenzar a utilizarla. Como DSR
esta pensado para redes inalambricas y muchas veces el enlace unidireccional es la u
nica manera
de 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 mensaje
en su cache para comenzar a enviar datos (Figura 2.5(g)). De esta manera un nodo origen puede
recibir m
ultiples rutas (Figura 2.5(f)) , las cuales son almacenadas para prevenir un descubrimiento de ruta en caso que una deje de estar disponible. Una caracterstica que destaca a DSR de
los otros protocolos reactivos es que las rutas no tienen un tiempo de vida, son utilizadas hasta
que se reciba un mensaje indicando que la ruta no esta disponible. Esto hace que si los nodos
permaneces relativamente est
aticos el overhead generado por el descubrimiento es cero.
Los nodo intermedios cada vez que reciben un mensaje RREQ o RREP pueden crear o actualizar sus tablas con las rutas recibidas en los mensajes. Tambien se puede activar una opcion
llamada promiscuous listening [1, Sec 10.3.2] que le da la posibilidad al nodo de escuchar tanto
los paquetes de datos como los de control a nivel MAC y as aprender rutas hacia otros nodos de
la red.
Figura 2.4: Detecci

on de un enlace roto y envo del RERR
24
tica
Redes M
oviles
(a) El origen 1 quiere enviar datos a 10
(b) El nodo 1 enva un mensaje RREQ a sus

vecinos especicando en la ruta su direcci
on
(c) Los nodos 2, 3 y 4 reciben RREQ y los propagan a sus vecinos concatenando su direcci
on
en la ruta (a los efectos del ejemplo no se especica la ruta enviada por 2)
(d) Se contin
ua la propagaci
on. Notar que 3 no
reenva el RREQ porque ya lo recibi
o antes
(e) El RREQ llega al destino 10 y este no lo retransmite y arma el RREP y lo enva al destino.
9 contin
ua la propagaci
on del RREQ
(f) Llega el segundo RREQ al nodo 10, arma

un nuevo RREP y lo enva al origen
(g) 1 recibe los RREP y elije enviar los datos

por la primer ruta que recibe
Figura 2.5: Ejemplo de la construcci

on de una ruta en DSR
tica
25
2.3.3. Protocolos de Ruteo Hbridos
Mantenimiento de la Ruta Cuando un nodo transmite o reenva un mensaje, este debe

asegurarse que fue entregado al pr
oximo salto [11, Sec 3.3] (se puede denir un n
umero maximo
de reintentos en el envo del paquete). Esta conrmacion de recepcion muchas veces es gratuita
para DSR cuando utiliza por debajo un protocolo de MAC como el de IEEE 802.11 ya que el
protocolo MAC es el encargado se asegurarse el envo con la trama link-level acknowledgement.
Si este mecanismo no est
a disponible, se congura un bit indicando a DSR que se necesita una
conrmacion a nivel protocolo DSR. Es muy probable que si esta opcion esta especicada es
porque no se este trabajando sobre un protocolo MAC como el especicado anteriormente o se
tengan enlaces unidireccionales, con lo cual la respuesta puede viajar a traves de otra ruta.
Si un paquete es reenviado un n
umero maximo de veces y no se recibe respuesta, el nodo
retorna un mensaje de error llamado RERR indicando a traves de que enlace no se pudo enviar
el paquete (Figura 2.4). Cuando el nodo origen recibe este mensaje marca la ruta como invalida
e intenta utilizar otra de las rutas de su cache, en caso de no tener ninguna inicia un nuevo
mecanismo de descubrimiento.
2.3.3.
Protocolos de Ruteo Hbridos
Las caractersticas de los protocolos de ruteo reactivos y proactivos pueden combinarse de

varias maneras y dan lugar a los protocolos de ruteo hbridos. Un protocolo hbrido utiliza caractersticas de los protocolos reactivos y proactivos dependiendo las circunstancias. Uno de los
principales ejemplos es el protocolo Zone Routing Protocol.
2.3.3.1.
Zone Routing Protocol (ZRP)
ZRP [12, Sec II] es un ejemplo de un protocolo de ruteo hbrido. Por un lado limita el alcance
de un protocolo proactivo para los nodos de su vecindad. Por otro lado utiliza el mecanismo de
descubrimiento de ruta de un protocolo reactivo para buscar nodos mas alla de su vecindario. El
protocolo identica diferentes rutas sin caer en un bucle capaces de alcanzar un destino, de esta
manera hace que sea m
as conable y performante.
Cada nodo dene un radio que es medido en cantidad saltos. Cada nodo utiliza un protocolo
proactivo en su zona y uno reactivo fuera de ella. De esta manera un nodo conoce a todos sus
vecinos de sus zona y todas las rutas hacia ellos. Cuando un nodo quiere enviar un paquete de
datos primero busca en su tabla de rutas una ruta hacia el destino, si el destino pertenece a su
zona la ruta la tiene. Si el destino no est
a 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 Zone
Routing Protocol (IARP) [1, Sec 10.5.1]. IARP es un protocolo basado en el protocolo Link-State
que mantiene actualizada la informaci
on de todos los nodos dentro de la zona. En la Figura 2.6
se puede ver un ejemplo la denici
on de una zona de un salto para el nodo O y como es una zona
de un salto de distancia quedan denidos automaticamente los nodos frontera o perifericos (A, B,
C). ZRP utiliza para el ruteo de paquetes fuera de la una zona un protocolo llamado Interzone
Routing Protocol (IERP). Este protocolo incorpora el termino bordercasting. Cuando un nodo
determina que el nodo al que le quiere enviar un paquete esta fuera de su zona, el nodo origen
26
tica
Redes M
oviles
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 mensaje
directamente al nodo frontera para que este luego haga el descubrimiento de la ruta.
El nodo frontera cuando recibe un mensaje de solicitud de ruta, verica si el destino esta en
su zona, en caso que no este reenva el pedido a cada uno (uno por vez) de sus nodos frontera.
Este procedimiento contin
ua hasta que se localice el destino o hasta que se examina toda la red.
Cuando un nodo encuentra al destino, este enva 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 gura, el nodo O hace
una b
usqueda de la direcci
on 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 direcci
on solicitada (los circulo solidos representan
las zonas hacia donde se envi
o el requerimiento). En caso que no este en su zona, reenva el pedido
a sus nodos perifericos. En la gura, cuando le llega el pedido al nodo D, este encuentra en su
zona al nodo E y enva una mensaje unicast hacia el nodo O con la respuesta.
ZRP tiene varios par
ametros y tecnicas para mejorar su performance y para prevenir la
propagaci
on de una b
usqueda cuando esta ya ha sido contestada por alg
un nodo. ZRP incorporo e
su version 2 (ZRPv2) una manera diferente a las hora de hacer bordercasting. ZRPv2 hace que el
nodo origen construya un
arbol hacia los destinos que no pertenecen a su zona. En ese arbol y como
primer hijo se encuentran los nodos perifericos. Cuando un nodo periferico recibe una consulta,
tica
27
2.3.4. T
ecnicas de Ruteo
primero construye su propio

arbol. Este procedimiento se repite hasta alcanzar el destino.
2.3.4.
T
ecnicas de Ruteo
Todos los protocolos antes descriptos, en su mayora, fueron concebidos para lograr mantener
una ruta hacia el destino. En muchos escenarios donde la red es mediana a grande y donde
los nodos pueden tener mucha movilidad, estas rutas podran sufrir modicaciones contnuas
y llevara a los nodos a estar continuamente ejecutando procedimientos de descubrimiento de
ruta. Para subsanar esta situaci
on existen variaciones de los protocolos originales que proveen
redundancia de rutas. A estos protocololos se los conoce como Ruteo Multicamino (Multipath
Routing).
2.3.4.1.
Multipath Routing
En la mayora de los protocolos vistos en este captulo, los nodos registran las rutas hacia los
distintos destinos en tablas de ruteo, en casi todos los casos cada entrada de la tabla tiene una
sola direcci
on como pr
oximo salto para continuar el camino hacia el destino. La idea principal de
los protocolos multi path es almacenar en un cache diferentes rutas hacia un mismo destino, y de
esta 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 antes
vistos para soportar m
ultiples caminos hacia el destino. Como se vio antes DSR, en forma nativa,
es decir sin ninguna adaptaci
on, soporta cache de rutas. Entre los protocolos adaptados para
utilizar cache son: Ad Hoc On-Demand Multipath Distance Vector Routing (AOMDV), Ad Hoc
On-Demand Distance Vector Routing - Backup Routing (AODV-BR), Split Multipath Routing
(SMR)
Ad Hoc On-Demand Multipath Distance Vector Routing (AOMDV) utiliza un
cache con varias rutas para un mismo destino con un u
nico tiempo de vida para todas las rutas,
es decir, cuando se vence una ruta se vencen todas las rutas almacenada para ese destino. El valor
agregado que da AOMDV es que las rutas no utilizan un mismo enlace, es decir, todas las rutas
desde el origen al destino no repiten un enlace entre nodos (cada ruta son conjuntos dijuntos de
enlaces)
Ad Hoc On-Demand Distance Vector Routing - Backup Routing (AODV-BR) propone el uso de rutas de backup como alternativa ante una ruptura de enlace. Cuando ocurre una
ruptura el nodo m
as cercano al origen enva un paquete de error hacia este y a la vez lo enva
en forma broadcast a todos los vecinos. El paquete, en la cabecera de datos, indica que el link se
ha roto y que el paquete necesita una ruta alternativa. Cuando los nodos del vecindario reciben
este mensaje, lo reenvan 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 de
manera disjuntas. Utiliza dos rutas para cada sesion; una es la que tiene la menor latencia y otra
que es la mas disjunta con esta, es decir la que menos enlaces en com
un tenga. De esta manera
28
tica
Redes M
oviles
SMR provee rutas alternativas y por ser disjuntas se minimiza el riesgo de rotura de una ruta
por tener la mnima cantidad de enlaces comunes.
SMR tiene dos esquemas de mantenimiento de las rutas. El primero crea un nuevo par de
rutas si una de las dos rutas se rompe y el segundo hace una reconstruccion de las rutas solo
cuando ambas rutas se hayan roto.
2.4.
Resumen
A lo largo del Captulo se vieron los diferentes tipos de algoritmos disponibles para redes
moviles. Como se vi
o hay dos categoras principales, los proactivos o basados en tablas y los
reactivos 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 mnima
latencia. Los reactivos tienen un mnimo overhead pero mayor latencia.
Llegada la discusi
on de cual tipo de algoritmo es mejor, habra que ver cual es la nalidad
de la red, que servicios se van a montar sobre esta, que cantidad de nodos y que velocidad o con
que frecuencia podra cambiar la topologa.
Dentro de los protocolos proactivos se desarrollaron DSDV y OLSR. DSDV tiene un alto
overhead de paquetes de control pero tiene deteccion de bucles. OLSR tiene menos overhead,
tiene detecci
on 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 en
mismo tiempo de convergencias y la misma complejidad de comunicaciones. La diferencia radica
en la manera de formar las rutas. DSR tiene como ventaja que utiliza un cache de rutas con lo
cual minimiza la latencia en caso de perder una. AODV tiene como virtud que se adapta rapidamente a redes con nodos de mucha movilidad. Ambos protocolos tiene como contra problemas
de escalabilidad en redes con muchos nodos.
Como una alternativa a estos dos tipos de algoritmos, se analizaron protocolos hbridos los
cuales usan un protocolo proactivo dentro de un vecindario y protocolos reactivos para llegar
a nodos fuera del vecindario. Estos protocolos son optimos para topologas donde los nodos se
mueven pero siempre dentro de un mismo ambito.
tica
29
2.4. Resumen
30
tica
Captulo 3
Seguridad Inform
atica
En este captulo se har
a una revision de los principales conceptos de la seguridad informatica [35, Sec. 2.1].
Cuando se habla de seguridad en redes de computadoras, hay tres objetivos o premisas basicas
que se deben cumplir.
Condencialidad: Se garantiza que la informacion sea accesible solo a aquellas personas que
tienen acceso a la misma.
Integridad: Se salvaguarda la exactitud y totalidad de la informacion y los metodos de
procesamiento.
No Repudio: Se reere a evitar que una entidad que haya enviado o recibido informaci
on
alegue ante terceros que no la envio o no la recibio.
Existen otros objetivos m
as difciles de lograr pero que hacen a la seguridad de la informaci
on
Autenticaci
on: Garantizar el origen y el destino de la informacion, validando al emisor y al
receptor 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 disponibles
para ser utilizado por las partes autorizadas.
La mayora de estos conceptos se garantizan por medio del uso de la criptografa y algoritmos
criptogr
acos.
3.1.
Conceptos B
asicos de Criptografa
Es preciso introducir conceptos basicos de criptografa con el n de que el lector se familiarice

con el lenguaje y adquiera los conceptos necesarios que luego seran aplicados en otros captulos
de esta tesis.
31
3.1.1. Cifrados Sim

etricos
Por medio de la criptografa se ha podido garantizar las premisas de la seguridad para redes
de datos. A continuaci
on se presentan conceptos basicos e introductorios.
3.1.1.
Cifrados Sim
etricos
Los algoritmos de cifrado simetricos utilizan la misma clave para cifrar y para descifrar mensajes. Las dos partes que se comunican deben ponerse de acuerdo de antemano sobre la clave a
utilizar. Una vez que ambas tienen acceso a esta clave, el remitente cifra un mensaje usandola,
lo enva 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 palabras, no debera ser de ninguna ayuda para un atacante conocer el algoritmo que se esta usando.
Solo si el atacante obtuviera la clave, le servira conocer el algoritmo.
3.1.1.2.
Ventajas y Desventajas
El principal problema con los sistemas de cifrado simetrico no esta ligado a la seguridad
intrnseca de los algoritmos, sino a la forma en la que se intercambian las claves. Una vez que
las partes hayan intercambiado las claves pueden usarlas para comunicarse con seguridad, pero
se debe asegurar que dicho intercambio se haya realizado de forma segura. Por ejemplo si fue
un acuerdo verbal que nadie escucho la conversacion; Si fue por correo, asegurarse que nadie
intercepto el sobre. Para un atacante es mas facil tratar de interceptar la clave en el momento de
intercambio que probar el espacio posible de claves.
Otro problema es el n
umero de claves que se necesitan. Si tenemos un n
umero n de personas
que necesitan comunicarse entre ellos, entonces se necesitan n(n 1)/2 claves para cada pareja
de personas que tengan que comunicarse de modo privado. Esto puede funcionar con un grupo
reducido de personas, pero sera imposible llevarlo a cabo con grupos mas grandes.
La principal ventaja de estos cifradores es que son muy rapidos e implementables facilmente
por hardware.
3.1.1.3.
Algoritmos
DES DES fue el algoritmo de cifrado por bloques mas usado, como todo cifrador simetrico
toma un texto de una longitud ja de bits y lo transforma mediante una serie de operaciones
en un texto cifrado de la misma longitud. Para el DES el tama
no del bloque es de 64 bits y la
clave es de 64 bits, de los cuales s
olo 56 de son empleados por el algoritmo ya que los ocho bits
restantes son de paridad. El Algoritmo DES estaba estadarizado por la FIPS PUB 46-2 1 y fue
reemplazado por el AES
1 http://www.itl.nist.gov/pspubs/p46-2.htm
32
tica
Seguridad Inform
atica
3DES El algoritmo 3DES consta de tres rondas de DES. Incrementa el tama

no de la clave por
un factor de 3 hasta 168 bits. B
asicamente se usan tres claves de DES. El 3DES tiene hoy en da
un nivel de seguridad aceptable y es utilizado por muchos dispositivos. Tiene el inconveniente
que es lento en comparaci
on con el AES.
AES AES [31, Cap. 5] es un esquema de cifrado por bloques,tiene un tama
no de bloque jo de
128 bits y tama
nos de clave de 128, 192 o 256 bits. La mayora de los calculos del algoritmo AES
se hacen en un campo nito determinado. Es el reemplazo de 3DES en los sistemas modernos.
Se encuentra estandarizado por el NIST en FIPS 197, Advanced Encryption Standard (AES),
2001 2 .
3.1.2.
Cifrados Asim
etricos
Los cifradores asimetricos tienen la particularidad de contar con un par de claves, donde una
clave es p
ublica y se puede entregar a cualquier persona y la otra clave es privada y el propietario
debe guardarla de modo que nadie tenga acceso a ella. El remitente usa la clave p
ublica del
destinatario para cifrar el mensaje, y una vez cifrado, solo la clave privada del destinatario
podra 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 es
simple. Por ejemplo, multiplicar dos n
umeros primos grandes es una operacion simple de realizar,
pero factorizar el n
umero resultante en sus componentes primos es una operacion cuyo tiempo
de calculo puede llevar mucho tiempo al punto que para n
umeros de muchos bits puede llegar a
ser computacionalmente imposible es decir puede llevar a
nos de calculo. Con lo cual sera en vano
intentarlo.
Se trata de lograr que la generacion de las claves utilice la funcion trampa. Es decir generar
la clave sea simple, pero romperla sea equivalente a obtener la inversa de la funcion-trampa.
Por ejemplo, dado un cifrado de clave p
ublica basado en factorizacion de n
umeros primos, la
clave p
ublica contiene un n
umero compuesto de dos factores primos grandes, y el algoritmo de
cifrado usa ese compuesto para cifrar el mensaje. El algoritmo para descifrar el mensaje requiere
el conocimiento de los factores primos para que el descifrado sea facil. Si poseemos la clave privada
que contiene uno de los factores sera facil su decodicacion, pero extremadamente difcil en caso
contrario.
3.1.2.1.
Seguridad
Al igual que con los sistemas de cifrado simetricos, un buen sistema de cifrado de clave p
ublica
no debe basarse en esconder el algoritmo, este debe ser publico y la seguridad debe estar centrada
en esconder la clave.
El tama
no de la clave es una medida de la seguridad del sistema. Tener en cuenta que no se
puede comparar el tama
no de claves de un asimetrico con el de un simetrico.
2 http://csrc.nist.gov/publications/ps/ps197/ps-197.pdf
tica
33
3.1.3. Resumen Criptogr

aco
En un ataque de fuerza bruta sobre un cifrado simetrico con una clave de un tama
no de 80
bits, el atacante debe probar hasta 2811 claves para encontrar la clave correcta.
El esfuerzo para romper un cifrado es diferente seg
un el algoritmo utilizado. Mientras 128 bits
son sucientes para algoritmos con clave simetrica, los algoritmos de clase asimetrica necesitan
claves de por lo menos 1024 bits ya que la capacidad de calculo actual y los algoritmos conocidos
de factorizaci
on impiden usar una clave menor.
3.1.2.2.
Ventajas y Desventajas
La mayor ventaja de la criptografa asimetrica es que se puede cifrar con una clave y descifrar
con la otra. Esto permite conseguir autenticacion de una manera muy simple. Si se obtiene un
texto cifrado con la clave privada de alguien el u
nico que lo pudo generar es el due
no de la clave
y todos podemos vericar el origen ya que disponemos de su clave publica.
Las principales desventajas son:
Para una misma longitud de clave y mensaje se necesita mayor tiempo de proceso.
Las claves deben ser de mayor tama
no que las simetricas.
Para textos peque
nos, el mensaje cifrado ocupa mas espacio que el original.
3.1.2.3.
Algoritmos
Existen varios algoritmos que utilizan el esquema de clave p

ublica y clave privada, todos ellos
utilizan la misma base, complejidad matematica en la factorizacion de n
umeros primos.
Die-Helman Die-Hellman (debido a Whiteld Die y Martin Hellman) permite generar
claves en conjunto entre las partes que participan en la comunicacion. Este algoritmo debe ser
utilizado sobre un canal de comunicaci
on autenticado.
RSA El sistema criptogr
aco con clave p
ublica RSA es un algoritmo asimetrico que utiliza
una clave p
ublica, la cual se distribuye, y otra privada, la cual es guardada en secreto por su
propietario. La longitud de la clave puede variar, hoy en da se estan utilizando 1024 o 2048 bits.
3.1.3.
Resumen Criptogr
aco
3.1.3.1.
Hash
Una funci
on de Hash es una funci
on que tiene por nalidad obtener una cadena de longitud
ja de bits independientemente del texto que se use como entrada. La longitud de esa cadena,
en general es de unos poco bytes. Al resultado de aplicar la funcion sobre un texto se le llama
hash o resumen criptogr
aco. Los algoritmos de hash y las funciones son p
ublicas y no necesitan
claves.
El objetivo principal del hash es detectar cambios en el mensaje para vericar su integridad.
Una funcion puede ser usada como funcion de hash si cumple con las caractersticas:
34
tica
Seguridad Inform
atica
Es f
acil obtener el hash dado el mensaje.
Unidireccionalidad: conocido un resumen hash(M ), debe ser computacionalmente imposible
encontrar un Mensaje que se corresponda con el resumen.
Otra propiedad de las funciones de hash es que una mnima modicacion al mensaje provoca
un 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 u
til. Es un auxiliar que se utiliza en conjunto con otras primitivas
criptogr
acas. Mas adelante se mostrara como en conjunto con un algoritmo asimetrico permite
construir la rma digital.
Algoritmos Los algoritmos m
as 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 que
recibe como par
ametros un texto y una clave secreta compartida entre las partes. Aplicando esta
funcion se est
a autenticando el mensaje. Adicionalmente, el MAC al igual que los algoritmos de
hash, 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 imposible
hallar un mensaje que se corresponda. EL objetivo del mismo no es ocultar la informacion sino
protegerla y autenticar al origen.
Actualmente, dos de los m
as grandes grupos de funciones MAC seg
un su modo de operacion:
CBC-MAC: La idea detr
as de este algoritmo es la de convertir un algoritmo de cifrado
simetrico en una funci
on MAC. El funcionamiento basico consiste en cifrar el mensaje
usando un algoritmo en modo CBC y tirar todo el resultado de texto cifrado a excepci
on
del u
ltimo bloque.
HMAC: Dado que una funci
on MAC es un mapeo aleatorio, y que las funciones hash se comportan como tales, podemos explotar la idea de utilizar una funcion hash para implementar
una funci
on MAC. La opci
on mas popular hoy en da es la de usar HMAC-SHA-256.
3.1.4.
Firma Digital
La rma digital es una manera de garantizar la autora y la integridad de un documento

digital (texto, correo, aplicaciones, etc). Al igual que una rma olografa, la rma digital es usada
para manifestar un acuerdo/desacuerdo, indicar que se ha ledo un documento digital.
El mecanismo de rmado de un documento digital (Figura 3.1) se realiza aplicando una
funcion de hash al mismo y luego encriptandola con la clave privada del autor generando as la
rma. El documento rmado consta de dos partes, el documento en s y la rma. Los lectores
del mismo, aplican la funci
on de hash al documento y desencriptan la rma con la clave p
ublica
tica
35
3.1.5. PKI
del emisor. Compara el hash calculado con el desencriptado de la rma y si estos coinciden, se
garantiza que el documento no fue modicado y fue emitido por el autor. Tambien se garantiza
que el autor no puede negar su autora ya que es el el u
nico que pudo encriptar el hash con su
clave privada
Figura 3.1: Proceso de Generaci

on y Vericaci
on de una Firma Digital
Resumiendo la rma digital garantiza integridad y no repudio.
3.1.5.
PKI
Una infraestructura de clave p

ublica (PKI, Public Key Infrastructure) son los elementos necesarios (hardware, software, polticas y procedimientos) para garantizar la identidad, cifrado
asimetrico y rmas digitales [31, Cap. 13] en operaciones electronicas.
3.1.5.1.
Prop
osito y funcionalidad
La tecnologa PKI provee como servicio a los usuarios la posibilidad de autenticarse uno con
otros por medio de certicados expedido por una entidad de conanza para ambos. Esto a la
vez permite distribuir informaci
on (por ejemplo claves p
ublicas) necesaria para los protocolos de
comunicaci
on seguros, algoritmos de rma digital, cifrados y todas otras operaciones que requieran
conocer la identidad y garantizar el no repudio de la otra parte de la operacion electronica.
En una operaci
on electr
onica que use los servicios brindados por PKI, tiene como participantes
al 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 los
certicados de las partes.
Un usuario destinatario de los datos cifrados/rmados/enviados garantizados por parte del
usuario que inici
o de la operaci
on.
36
tica
Seguridad Inform
atica
La seguridad de la tecnologa PKI se centra en la privacidad de la clave privada (ya que

esta infraestructura utiliza los mismos principios que los algoritmos de clave p
ublica) y en los
procedimientos o polticas de seguridad aplicadas a la gestion de los certicados.
Es de vital importancia ser rigurosos a la hora de establecer las polticas de seguridad ya
que dejar expuesta una clave privada invalida cualquier tecnologa aplicada en el sistema o la
seguridad del cifrador m
as fuerte.
3.1.5.2.
Usos de la tecnologa PKI
La tecnologa PKI, es utilizada para realizar autenticacion de personas, servidores, sistemas,

etc; realizar rmado digital de documentos, software, correo, etc; Garantizar el no repudio; Cifrado
de datos y aseguramiento de canales de comunicaciones inseguros.
Basicamente el uso de esta tecnologa se centra cuando es necesario autenticar a las partes
para realizar una transacci
on digital segura.
3.1.5.3.
Certicados
Como se dijo anteriormente, la tecnologa PKI se basa en Certicados Digitales expedidos por
una entidad de en la cual confan ambas partes. Existes distintos tipos de certicados digitales
que varan dependiendo el destino del mismo.
Certicado personal: Acredita la identidad del titular.
Certicado de pertenencia a una entidad: Ademas de la identidad del titular acredita su
vinculacion con la entidad de la cual es miembro
Certicado de representante: Ademas de la pertenencia a la entidad acredita tambien los
poderes de representaci
on que el titular tiene sobre la misma.
Certicado de persona jurdica: Identica una entidad como tal a la hora de realizar tramites
ante las administraciones o instituciones.
Certicado de atributo: Permite identicar una cualidad, estado o situacion. Este tipo de
certicado va asociado al certicado personal. (p.ej. Medico, Director, Casado, etc.).
Los tipos de certicados antes mencionados son relacionados con un individuo o persona,
tambien existen certicados digitales para nes m
as especcos y tecnicos como pueden ser:
Adem
as, existen otros tipos de certicado digital con nes mas tecnicos:
Certicado de servidor: Permiten asegurar al usuario del mismo que la conexion la estan
realizando a donde ellos quieren.
Certicado de rma: Garantiza la autora y la no modicacion de aplicaciones, documentos,
etc.
tica
37
3.1.6. Componentes
3.1.6.
Componentes
Los componentes m
as habituales de una infraestructura de clave p
ublica son:
La autoridad de certicaci
on (CA, Certicate Authority): es la encargada de emitir y revocar
certicados. Es la entidad de conanza que da legitimidad a la relacion de una clave p
ublica
con la identidad de un usuario o servicio.
La autoridad de registro (RA, Registration Authority): es la responsable de vericar el enlace
entre los certicados (concretamente, entre la clave p
ublica del certicado) y la identidad
de sus titulares.
Los repositorios: son las estructuras encargadas de almacenar la informacion relativa a la
PKI. Los dos repositorios m
as importantes son el repositorio de certicados y el repositorio
de listas de revocaci
on de certicados. En una lista de revocacion de certicados (CRL,
Certicate Revocation List) se incluyen todos aquellos certicados que por alg
un motivo
han dejado de ser v
alidos antes de la fecha establecida dentro del mismo.
La autoridad de validaci
on (VA, Validation Authority): es la encargada de comprobar la
validez de los certicados digitales.
La autoridad de sellado de tiempo (TSA, TimeStamp Authority): es la encargada de rmar
documentos con la nalidad de probar que existan antes de un determinado instante de
tiempo.
Los usuarios y entidades nales son aquellos que poseen un par de claves (p
ublica y privada) y un certicado asociado a su clave p
ublica. Utilizan un conjunto de aplicaciones que
hacen uso de la tecnologa PKI (para validar rmar digitales, cifrar documentos para otros
usuarios, etc.)
3.1.6.1.
Consideraciones sobre PKI
Los Certicados Digitales deben ser emitidos por una Autoridad Certicante reconocida por
las partes para garantizar la validez del mismo. Ambas partes de la transaccion electronica debe
conar en la Autoridad que emiti
o el certicado.
No es responsabilidad de la CA la conservacion del certicado y evitar que sea usado de forma
indebida. Tampoco es responsabilidad de la CA la custodia de la clave privada correspondiente
al mismo.
La infraestructura PKI es considerada segura por si sola si se aplican bien la polticas de
seguridad y no es necesario realizar ning
un tipo de intercambio de clave para realizar una comunicacion segura.
3.2.
Resumen
En este captulo se hizo una revisi

on de los conceptos principales de seguridad informatica
y de los conceptos b
asicos de criptografa. Poniendo todo junto y considerando solo algunas
38
tica
Seguridad Inform
atica
alternativas, podemos resumir que para garantizar los pilares de la seguridad, la criptografa nos
da las siguientes herramientas:
Condencialidad: 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 aanzando a medida que se avance en la lectura de la presente
tesis al ver la aplicaci
on de cada uno.
tica
39
3.2. Resumen
40
tica
Captulo 4
Seguridad en Redes M
oviles
El objetivo del presente captulo es exponer distintos tipos de ataques a los que
est
a expuesta una red M
ovil y cuales son algunos de los protocolos de ruteo que
existen para hacer que este tipo de redes sean conables. El estudio de estos protocolos
son necesarios para el objetivo de esta tesis. Por ello es que de cada uno de ellos se
resaltar
a que aspecto puede ser utilizado en esta tesis.
Como se vi
o en la Secci
on 2.1 las redes moviles son una coleccion de dispositivos moviles
formando moment
aneamente una red sin la ayuda de una infraestructura. Estos dispositivos
utilizan el aire como medio fsico de comunicacion, compartiendo con muchos otros el mismo
canal de transmisi
on. Los nodos participantes de una red movil estan mucho mas expuestos a un
ataque que una computadora dentro de una red cableada ya que cualquier intruso no tiene mas
que ponerse a escuchar el aire y puede comenzar su ataque.
Otra caracterstica de este tipo de redes es que su topologa en muy cambiante y diculta
tener un control de los miembros de la red.
La naturaleza de las redes m
oviles 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 para
comunicarse.
Para hacer de una red m
ovil una red segura, hay que tener en cuenta los Servicios de Seguridad
descriptos en el Captulo 3 extendidos a Redes Moviles [15]:
Disponibilidad: garantiza la supervivencia de la red ante la hostigacion de nodos agresores.
Condencialidad: garantiza que todo el traco que circula por la red (paquetes de control
y paquetes de datos) solo pueden ser ledos por los nodos autorizados a verlo y por ning
un
otro nodo.
Integridad: garantiza que la informacion que viaja por la red no ha sido modicada durante
el trayecto del origen al destino.
41
4.1. Ataques
Autenticaci
on: 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 m

ovil se pueden clasicar de dos maneras: por su origen o por el grado
de participaci
on del nodo atacante.
La clasicaci
on 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 clasicaci
on por el grado de participacion del nodo atacante puede ser:
Activo: Se considera activo cuando un nodo emite se
nal o datos con el objetivo de da
nar la
red.
Pasivo: Se considera pasivo cuando el nodo no coopera y simplemente escuchan. A los nodos
pasivos se los llama egostas (selsh)
Dentro de cualquiera de las categoras anteriores podran darse estos tipos de ataques:
Denegaci
on de Servicio (DoS): Consiste es dejar el nodo fuera de la red
Interceptaci
on Pasiva: Consiste en escuchar el medio (aire)
Interrupci
on del Flujo: Consiste en alterar o modicar el ujo de los datos sin cambiar las
rutas
Integridad de los datos: Modicacion del contenido del mensaje
Ataque de Se
nalizaci
on: Modicacion de los paquetes de control
4.1.1.
Ataques Externos
Los ataques externos [16, Sec. 5] en general son ataques de capa fsica y de enlace ya que
los protocolos de niveles superiores proveen autenticacion. Los ataques de capa fsica son muy
difciles de implementar por la naturaleza de la red.
Los ataques externos se pueden subdividir por el grado de participacion del nodo agresor en
dos categoras: interceptaci
on pasiva (pasive eavesdropping) e interferencia activa.
4.1.1.1.
Interceptaci
on Pasiva
Esta tecnica permite a los nodos agresores escuchar y recibir mensajes e informacion de
actualizaciones de las tablas de ruteo y de esta manera inferir una topologa de red, identidades
o cuales son los nodos que tienen m
as participacion en la red.
42
tica
oviles
4.1.1.2.
Interferencia Activa
El objetivo de esta tecnica es causar una denegacion de servicio (DoS) causando un bloqueo
del canal de comunicaciones o distorsionando la comunicacion. Las consecuencias de este ataque
depende del tiempo que se aplique y del tipo de protocolo de ruteo utilizado en la red. Si se utiliza
un protocolo reactivo, este ver
a a la interferencia como una ruptura de enlace y el mecanismo
de mantenimiento de ruta eliminara el enlace con este nodo y no podra recibir mensajes. Si se
utiliza 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 m
as serio de este tipo es uno llamado sleep deprivation torture que consiste en
interrumpir el perodo de ocio del dispositivo de capa fsica y producir un consumo excesivo
de la energa de la vctima. Este tipo de ataques ya tiene muchos a
nos de estudio y la tecnologa de espectro ensanchado que utilizan las comunicaciones inalambricas son resistentes a las
interferencias, al ruido y a intrusos.
Cabe a aclarar que la interferencia no es solo a nivel fsico sino que el hecho de que un nodo
malicioso repita mensajes fuera de tiempo, mensajes incompletos hacen un uso excesivo de las
frecuencias de radio y producen un gasto de energa y a la vez saturan el nodo con informacion
in
util causando una denegaci
on de servicio.
4.1.2.
Ataques Internos
Los ataques internos [16, Sec. 6] son los mas serios y los mas difciles de defender ya que un
nodo interno a la red tiene la informacion necesaria para participar en la red. Los nodos internos
pueden tener comportamientos maliciosos en diferentes sentidos. Para identicar estos comportamientos, se pueden considerar las siguientes categoras: Nodo Fallido, Nodo Fallido Maligno,
Nodo egosta y Nodo Malicioso.
4.1.2.1.
Nodo Fallido
Un nodo fallido es aquel nodo que simplemente no puede realizar una operacion, esto puede ser
por varias razones, por ejemplo una falla de energa o eventos ambientales. El problema principal
que estos nodos causan es que dejan de reenviar mensajes incluyendo los mensajes de control.
Este comportamiento es muy crtico ya que este nodo corta la comunicacion y puede ser que
el resto de los nodos no se hayan enterado de una rotura de una ruta por ejemplo, porque el
mensaje deba pasar por un nodo fallido. Este problema es a
un mas crtico cuando el nodo fallido
es parte de una ruta de emergencia o parte de una ruta segura. Estos fallos pueden crear cuellos
de botella y llegar a extremo de desacoplar la red.
4.1.2.2.
Nodo Fallido Maligno
El efecto provocado por un nodo fallido maligno es el mismo que el caso anterior pero en este
caso el nodo deja de operar de una manera consciente. Adicionalmente a este comportamiento
un nodo maligno puede enviar mensajes de rutas falsas o generar mensajes falsos para alterar
tica
43
4.1.2. Ataques Internos
el comportamiento y el ruteo del resto de la red. Para algunos protocolos estos nodos pueden
provocar una ataque de denegaci
on de servicio (DoS).
4.1.2.3.
Nodo egosta
Un nodo egosta explota los protocolos de ruteo para el bien propio. Es el caso de que un
nodo no quiera cooperar en la red para preservar sus recursos (energa) demostrando un comportamiento similar al de un nodo fallido. La accion tpica de un nodo egosta es la de desechar
los paquetes recibidos. Este ataque es muy difcil de detectar ya que los protocolos no preveen el
control de donde se perdi
o un paquete (a excepcion de DSR). Lo que hay que resaltar es que los
nodos egostas 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 mencionados
antes pueden estar presentes en un nodo malicioso. A continuacion se muestran distintos tipos
de ataques que este tipo de nodos puede introducir:
Denegaci
on de Servicio El ataque de denegacion de servicio (Denial of Service -DoS-) induce a las vctimas a caer en un ataque sleep deprivation torture que consiste en hacer realizar
operaciones innecesarias a las vctimas haciendo agotar los recursos de energa. Este ataque lo
provocan enviando a sus vctimas informacion valida o erronea en forma innecesaria. Los protocolos proactivos son muy sensibles a este ataque ya que cuando les llega una actualizacion de un
nodo deben actualizar todas sus rutas, por lo tanto si se les enva informacion necesaria estos
nodos consumiran muchos recursos actualizando sus tablas.
Este tipo de ataque tambien atenta contra la integridad de la red porque el nodo atacante
puede enviar mensajes alterando las rutas.
Ataque a la Integridad de la Red Este ataque tiene lugar cuando el nodo agresor inyecta
en la red informaci
on falsa de la topologa de la red. Muchos otros ataques pueden tener como
consecuencia este tipo de agresi
on.
Cuanto mayor es la densidad de la red donde el atacante se encuentra, mayor es la consecuencia. Los protocolos proactivos, en especial el OLSR, es muy sensible a este ataque ya que tiene un
algoritmo de ooding muy pobre, con lo cual informacion falsa puede ser reenviada a otro nodo.
Ataque a los protocolos de detecci
on de Vecinos Un nodo malicioso puede forzar a un
nodo a agregar a un vecino inexistente o hacer que ignore a un vecino real. Este ataque se efect
ua
contra el protocolo de detecci
on de vecinos. El nodo agresor puede enviar a la vctima un mensaje
con la informaci
on de censado de vecinos incorrectas.
Algunos protocolos como el DSR usan listas negras para bloquear transmisiones a nodos con
los cuales no se tiene un enlace bidireccional. En este protocolo un nodo malicioso podra provocar
una alteraci
on de los links en uno de los sentidos y el mismo protocolo pondra a ese vecino en
44
tica
oviles
su lista negra y no le enviara ning

un mensaje. De manera contraria un nodo malicioso podra
hacer que la vctima remueva un nodo de la lista negra haciendose pasar por tal enviandole un
route-request con los datos de la cabecera del nodo que esta en la lista negra.
Redirecci
on de tr
aco El ataque consiste en que un nodo puede hacerse pasar por otro y
as modicar la integridad de la red haciendo pasar todas la rutas de la red por el nodo atacante.
Cuando un nodo de la red hace un route-request el nodo maligno puede responder que el es el
destino o que el tiene una ruta hacia el destino y de esta manera todo el traco pasara a traves de
el y los mensajes para el destino real lo recibe el. A este caso particular del ataque de redirecci
on
de traco se lo conoce como agujero negro.
Otra consecuencia de este ataque es que un nodo puede modicar las rutas para que todo
el traco vaya para un nodo y que este caiga en un ataque de sleep deprivation. Este efecto se
puede acentuar haciendo que el nodo agresor enve al resto de los nodos un n
umero de salto
peque
no hacia el destino y un n
umero de secuencia mas nuevo para asegurarse que todos los
nodos preeran las rutas que pasan por el nodo vctima.
Una variante de este ataque que es muy difcil de detectar es el ataque del t
unel (wormhole
attack ) en el cual la informaci
on que llega a un nodo es tuneleada hacia otro nodo por un medio
directo m
as r
apido. Si en un protocolo reactivo, el mensaje es tuneleado hacia las cercanas de
un nodo destino, este llegar
a m
as r
apido que cualquiera, por lo tanto el retorno de la ruta sera a
traves del t
unel y como consecuencia de esto el nodo mal intencionado esta dentro de la ruta
hacia 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 N
umeros de Secuencia La mayora de los protocolos utilizan n
umeros de
secuencia para prevenir ataques en los cuales se les reenven mensajes viejos. Igualmente un
nodo malicioso puede explotar esta caracterstica enviando muchos mensajes con una direcci
on
de destino falsa y un n
umero de secuencia muy alto, como consecuencia del ataque se produce
una denegaci
on del servicio porque cualquier mensaje valido de otros nodos seran rechazados por
tener un n
umero de secuencia viejo o duplicado.
Ataques a Protocolos Especcos Existen distintos tipos de ataques para protocolos especcos. Cuando un nodo malicioso integra una red, ya tiene el conocimiento de que protocolo
esta presente en esa red y as puede ejecutar un ataque especcamente al protocolo presente.
De esta manera el ataque es mucho mas efectivo. Por ejemplo para DSR el nodo atacante puede
inyectar tantas rutas con tantos pr
oximos saltos como sea posible hacia un destino inexistente.
Luego el agresor enva un mensaje hacia el falso destino. En este punto se produce un ataque de
denegaci
on de servicio, porque cada nodo intermedio va a intentar enviar a su proximo salto el
error de la ruta de los cuales esperara un ACK. El nodo intermedio va a intentar salvar la ruta
tratando de buscar una ruta alternativa y las rutas alternativas que encuentre van a ser falsas y
va a llevar al nodo a incrementar el valor de M AX SALV AGE T IM ES hasta su maximo y no
va a intentar m
as.
tica
45
4.2. Protocolos de Ruteo Seguros
4.2.
Protocolos de Ruteo Seguros
Desde que se comenzaron a desarrollar los primeros manuscritos de los protocolos de ruteo
para MANETs, se comenz
o a investigar como prevenir los ataques. En general se han investigado y
desarrollado m
as protocolos seguros basados en los protocolos de ruteo reactivos (DSR o AODV).
Dentro de la variedad de protocolos desarrollados, todos tienen en com
un que tratan de
mitigar los ataques activos producidos por los nodos atacantes que comprometen la integridad
de la red, pero no los ataques de nodo egosta. Otra caracterstica de los protocolos actuales que
es se desarrollan en un ambiente controlado, es decir todos los integrantes de la red que deseen
comunicarse deben poder intercambiar algunos parametros de inicializacion (claves entre otros)
de antemano.
A continuaci
on de describir
an 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 IARP
parte del protocolo ZRP 2.3.3.1.
SRP garantiza la recolecci
on correcta de la topologa de la red aunque se encuentre en presencia de un nodo malicioso. Este protocolo es fuerte ante ataques que intenten modicar el proceso
de descubrimiento de la ruta.
El protocolo asume la existencia de una security association (SA) entre el nodo origen (S) y
el nodo destino (T ). Esta relaci
on de conanza puede ser inicializada, por ejemplo, si un nodo
conoce la clave p
ublica del otro, luego por medio de algoritmos como puede ser Die-Hellman
pueden negociar una clave (KS,T ) y utilizarla como SA.
SRP como se dijo anteriormente combate los ataques contra el proceso de descubrimiento de
ruta y garantiza, teniendo en cuenta algunas asunciones [23, Sec. C.1], que la informacion que
reciba un nodo sea correcta. Tambien incorpora algunos mecanismos que previene que se exploten
funcionalidades del protocolo en contra de la integridad de la red.
4.2.1.1.
Descubrimiento de la Ruta
SRP agrega al encabezado del protocolo de ruteo 4.1 una cabecera de SRP de 192 bits 4.2. El
nodo S el pedido de ruta (RREQ) mantiene un n
umero de secuencia de 32 bits(Query Secuence
Number, Qsec ), el cual es incrementado con cada pedido. Este n
umero permite a T detectar
pedidos viejos y descartarlos. El n
umero de secuencia se inicializa cuando se establece la SA.
Por cada pedido de ruta, S generar
a un n
umero aleatorio de 32 bits (Query Identier, QID )
que es utilizado por los nodos intermedios para identicar el pedido. QID es generado de manera
tal que sea imposible de predecir por un atacante.
Estos dos n
umeros, m
as un identicador 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 Protocol
Packet) y la clave KS,T
46
tica
oviles
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 extensi

on 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 destino
para insertarlos en una tabla (query table). Todos los pedidos que lleguen y se encuentren en esta
tabla son descartados, los dem
as seran retransmitidos para continuar el proceso de descubrimiento.
Los nodos intermedios tambien controlan la frecuencia con la que se generan los pedidos para
mantener un ranking que es inversamente proporcional a la frecuencia de pedido. Generalmente
un nodo malicioso genera muchas solicitudes de ruta con el n de generar un DoS o utilizar el
ancho de banda de la red para transmitir paquetes de control. De esta manera, los nodos malicioso
rankearan bajo y sus paquetes seran retransmitidos con baja prioridad o eventualmente no se
transmitir
an.
Una vez que el nodo destino recibe la peticion de ruta (RREQ), verica la integridad y la
autenticidad del mismo calculando el HMAC y comparandolo con el del paquete recibido. Si el
paquete es v
alido, comienza el proceso de respuesta. El paquete de respuesta (RREP) es generado
utilizando la cabecera SRP del mismo modo que la genero el nodo S cuando genero el pedido.
EL nodo origen descartar
a todos aquellas respuestas que no se encuentren en su lista de pedidos
pendientes. Esto lo hace utilizando la direccion de origen, la de destino y los n
umeros QID y
Qsec .
La versi
on b
asica 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 nodos
intermedios que operan en modo promiscuo para mejorar la eciencia del protocolo los reciben y
tica
47
4.2.2. ARIADNE
retornan la ruta cacheada.

Los autores del SRP poroponen como alternativa el uso de Intermediate Node Reply Token
(INRT). INRT utiliza una clave KG compartida entre un grupo de nodos y la utiliza para generar
un HMAC del paquete RREP. Con esta extension se agrega un nuevo campo al encabezado
SRP 4.3.
0
1
2
3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
SRP Header
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
IN Reply Token
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figura 4.3: Encabezado SRP con extensi

on INRT
4.2.1.2.
Otras Vulnerabilidades
SRP no tiene una validaci

on para los mensajes de mantenimiento de ruta, los paquetes de
error no son vericados. De todos modos, para minimizar este efecto, SRP genera los paquetes
de errores con un prejo donde est
a la ruta completa. Con este prejo el nodo S puede vericar
si el nodo que gener
o el mensaje de error es parte de la ruta. Lo que no se puede vericar es si el
mensaje es real, es decir un nodo intermedio puede decir que el enlace se rompio pero en realidad
esta intacto.
SRP no tiene ninguna contramedida para el ataque del t
unel (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 alg
un algoritmo
de intercambio de claves, en este caso Die-Hellman. Otro aspecto es el uso de HMAC para
garantizar integridad y autenticaci
on 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 utiliza
criptografa simetrica 3.1.1 para que el destino del proceso de descubrimiento de la ruta pueda
autenticar al origen, para que el origen pueda autenticar a los nodos intermedios presentes en el
mensaje de respuesta RREP y para que ning
un nodo intermedio pueda remover alg
un nodo de
la lista del mensaje RREP o RREQ.
Como se comentaba en la introducci
on a los protocolos de ruteo seguros, ARIADNE necesita
alg
un metodo de intercambio de claves previo. Se deben intercambiar las claves entre el origen S
y el destino D (KS,D ).
ARIADNE provee una autenticaci
on punto a punto del mensaje de ruteo usando autenticacion
MAC y una clave compartida entre las dos partes. Para la autenticacion de los paquetes broadcast
utiliza un protocolo de autenticaci
on llamado TESLA [25].
48
tica
oviles
ARIADNE previene la modicacion y el armado de informacion de ruteo, previene el uso de

la impersonicaci
on y en versiones avanzadas del ataque del t
unel (wormhole attack ).
ARIADNE arma el paquete de solicitud de descubrimiento de ruta adicionandole siete campos
para proporcionar autenticaci
on 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 respectivamente. Como en DSR, el id es un n
umero que no se haya utilizado en los procesos
de descubrimiento recientes y el intervalo de tiempo es el intervalo de tiempo de TESLA, un tiempo pesimista de arribo del pedido al destino. El origen inicia el hash con
un M ACKS,D (origen, destino, id, intervalo de tiempo) , la lista de nodos y la lista de MAC
vacas.
Cuando un nodo A recibe un mensaje RREQ, del cual el no es el destino, busca en su tabla por
la tupla <origen,id> para determinar si este paquete no lo vio antes, si lo vio descarta el paquete.
Tambien verica que el intervalo de tiempo sea valido, si no lo es descarta el pedido. En caso
contrario, el nodo A modica el pedido agregando su direccion en lista de nodos, reemplazando
el hash con H(A, hash anterior). En la lista de MAC agrega el MAC del pedido completo. El
nodo utilizar
a la clave TESLA KAi para computar el MAC, donde i es el ndice para el intervalo
de tiempo especicado en la petici
on. Finalmente reenva el mensaje.
Cuando el nodo destino recibe la peticion, lo primero que hace es vericar la validez del
mensaje calculando si el hash es v
alido realizando el siguiente calculo.
H[n , H[n1 , H[..., H[1 , M ACKSD (origen, destino, id, intervalo de tiempo)]...]]]
Donde i es la direcci
on del nodo en la posicion i de la lista de nodos y n es la cantidad de
nodos en la lista.
Si el nodo destino determina que el mensaje es valido, arma el mensaje de respuesta el cual
sera 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 son

los mismos que recibi
o 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 vaca.
Cuando el nodo destino recibe la respuesta, verica que cada clave en la lista de claves sea
alido y cada uno de los MAC de la lista de MAC sean validos. Si
valida, el MAC destino sea v
todas las vericaciones son exitosas, se acepta el mensaje, en caso contrario se descarta.
ARIADNE tambien se proteje contra ataques de DoS causado por la inyeccion de m
ultiples
paquetes de RREQ. Los nodos pueden ltrar este tipo de ataques usando la cadenas de descubrimiento de ruta, el cual es un mecanismo para autenticar el proceso de descubrimiento.
tica
49
4.2.3. Resumen
4.2.2.1.
Ideas Rescatadas para el Desarrollo de la Tesis
De este protocolo se rescata la capacidad de poder autenticar el procedimiento de descubrimiento de una ruta para prevenir ataques de DoS. Si bien esta idea se tuvo en cuenta durante
el desarrollo de la tesis no fue utilizada ya que OLSR es un protocolo proactivo y este tipo de
descubrimiento se llevan a cabo en protocolos reactivos.
4.2.3.
Resumen
A lo largo del captulo se presentaron cuales son los ataques tpicos a los que debe enfrentarse
una red movil. Tambien se presentaron cuales son las cuestiones basicas que debe garantizar un
protocolo para que sea considerado seguros y nalmente se presentaron protocolos seguros. De los
protocolos desarrollados se indic
o de cada uno cuales aspectos son provechosos para el desarrollo
de la tesis. Si bien los protocolos seguros descriptos al nal de este captulo son protocolos reactivos
y el objetivo de la tesis es trabajar con un protocolo proactivo como es el caso del OLSR, algunas
ideas de estos fueron provechosas.
50
tica
Captulo 5
Redes M
oviles Urbanas
El objetivo del presente captulo es introducir el concepto de que es una Red M
ovil
Urbana y cuales son los aspectos administrativos de este tipo de redes.
Las redes m
oviles tiene un uso potencial muy grande ya que los dispositivos de comunicacion
masivos (celulares, PDAs, etc) cada vez estan al alcance de mas personas y ganan popularidad
dentro de la sociedad ya que en un solo dispositivo pueden reproducir contenidos multimedia,
hablar por telefono y navegar por internet. Estos dispositivos en su mayora cuentan con interfaces
de red inal
ambricas 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 comunitarios
relacionados con armar redes inal
ambricas metropolitanas hacen que cualquier persona pueda
estar conectada, a traves de una LAN, con otra persona en el otro extremo de la ciudad donde
sin la ayuda de una red m
ovil sera imposible por razones inherentes a la naturaleza de las
conexiones y los dispositivos inal
ambricos.
La tecnologa Wi-Fi (802.11) tiene como limitante para establecerse una comunicacion wireless
la lnea de visi
on, es decir, los dos elementos a comunicarse no deben tener ning
un obstaculo que
interera entre los dos extremos. Este limitante es el peor enemigo que tiene las redes urbanas
por las caractersticas edilicias que presenta una ciudad. Viendo un caso practico, una persona
quiere comunicarse con un vecino que esta edicio de por medio, por mas que las distancias sean
cortas, 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 posiciones
estrategicas que tengan lnea de vision entre s y de esta manera extender la cobertura. En este
captulo se ver
a como se conforma una red urbana, como nacen y como trabajan redes moviles
urbanas en distintas partes del mundo.
51
5.1. Proyectos Comunitarios Libres
5.1.
Proyectos Comunitarios Libres
La comodidad de las redes inal

ambricas, sumado a la posibilidad de conectarse sin cables a
una velocidad razonable y el espritu aventurero de los fanaticos de las comunicaciones llevaron
en primera medida a compartir una conexion con un vecino o con un amigo. Siendo esta primera
etapa satisfecha r
apidamente, se ven con la necesidad de ir mas alla y conectarse con puntos cada
vez mas lejanos y con mayor cantidad de personas. Como existen varias personas con el mismo
espritu aventurero, curioso y con ganas de aprender de comunicaciones o simplemente tienen
una colecci
on de discos que quieren compartir con personas mas alla de su crculo de amistades
es que nacen las comunidades.
Las comunidades conforman una simbiosis entre sus miembros, cada uno necesita de otro para
poder cubrir m
as supercie con la red y es as como nacen las redes urbanas, conformadas por
personas, sin nes de lucro con el u
nico objetivo de cubrir cada vez mas supercie para que cada
vez haya mas personas conectadas.
Teniendo una visi
on m
as macro de estos grupos, existen en diferentes ciudades del mundo
grupos de personas conformando comunidades de redes libres. Para dar algunos ejemplos, en
Latinoamerica una de las comunidades mas grandes es BuenosAiresLibre 1 , en Argentina otra
comunidad muy importante es Mendoza Wireless 2 . En Uruguay, Motevideo Libre 3 , en Chile,
ChileSinCables 4 . En Estados Unidos existe una innumerable cantidad de comunidades libres,
de las cuales sobresalen NYCWireless 5 y SeattleWireless 6 . As se podran enumerar innitas
cantidades de comunidades de redes urbanas libres en todo el mundo.
5.1.1.
Buenos Aires Libre
Como se mencion
o anteriormente Buenos Aires Libre (BAL) es una de las comunidades de
redes urbanas m
as grandes de Latinoamerica. Esta comunidad nace como parte de un proyecto
mas ambicioso llamado Red Libre Argentina que tena como objetivo conformar una red abierta
en todo el pas. El grupo de personas que encabezaban ese proyecto eran de Buenos Aires y
decidieron comenzar por conformar la red comenzando por la Ciudad de Buenos Aires y as nace
el grupo de Buenos Aires Libre.
He elegido esta comunidad como ejemplo de aplicacion de esta tesis ya que soy miembro de
la misma desde hace 5 a
nos y conozco su arquitectura y su topologa desde el comienzo.
La comunidad se organiza por grupos, actualmente existen dos grandes grupos, el grupo de
Organizacion y los que participan pasivamente en el proyecto o colaboran con un nodo pero no
son parte del grupo organizativo. Dentro del grupo de Organizacion existen varios subgrupos con
tareas especcas como por ejemplo Direccionamiento IP, Mantenimiento del Site del proyecto,
Interrelacion con otros proyectos libres y otras comunidades wireless.
1 http://www.buenosaireslibre.org
2 http://www.mendoza-wireless.net.ar
3 http://www.montevideolibre.org
4 http://www.chilesincales.org
5 http://www.nycwireless.net
6 http://www.seattlewireless.net
52
tica
Redes M
oviles Urbanas
Una vez por mes se realiza una reunion del grupo de Organizacion donde se plantean inquietudes y se resuelven decisiones consensuadas para la administracion de la comunidad. Por ejemplo
se determinan pautas para pertenecer al grupo de Organizacion, se decide el espritu del proyecto,
se fomenta e incentiva la instalaci
on de nuevos nodos entre otras tareas. En estas reuniones cada
grupo presenta nuevas ideas y se jan objetivos para los diferentes grupos.
5.2.
Topologa
La topologa de las redes urbanas son muy diferentes ya que se adaptan a la geografa de la
ciudad o sencillamenta a donde es posible poner un nodo. Las redes en ciudades grandes donde
prevalecen los edicios de varios pisos es muy difcil lograr extenderlas ya que es necesario muchos
nodos ubicados en edicios altos para que puedan tener lnea de vision. La particularidad de una
red urbana es que un dispositivo se puede comunicar con otros a miles de metros sin tener linea
de visi
on 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 jo ubicado en un punto estrategico que tiene lnea de vision con
otro y son los encargados de extender la red conformando el backbone de la misma. Los Clientes
son cualquier nodo (m
ovil o jo) que se conecta en general a un nodo. La gura 5.1 muestra una
topologa de red tpica de una red urbana.
Hasta ahora se desarroll
o el concepto de red urbana donde los clientes se conectan generalmente a un nodo. Esta idea es la que se aplica en la actualidad en la mayora de las redes urbanas
ya que los protocolos de redes m
oviles no han sido estandarizados y no se distribuyen con los
drivers de las placas de red o con los sistemas operativos. Esta forma de conexion es la u
nica manera que existe hasta el momento para los clientes. Sin embargo, los nodos cuentan con hardware
especco y Sistemas Operativos no convencionales y s implementan protocolos de redes moviles
con lo cual cada nodo pertenece a una red autocongurada por estos.
La integraci
on de los clientes como participantes de la red movil es, por llamarlo de alguna
manera, experimental, ya que las implementaciones de los protocolos estan en pleno desarrollo y
solo algunos pocos se aventuran a experimentar.
Cuando los protocolos sean estandarizados y se hagan mas populares, todos los clientes van
a ser parte de una red m
ovil. Esto va a permitir que un cliente pueda acceder a la red no solo
a traves de un nodo sino a traves de otro cliente. En la Figura 5.1 se muestra una topologa de
una Red M
ovil Urbana. En esta se puede observar que los clientes no tienen conectividad con
todos los integrantes de la red pero s tienen conectividad al menos con un cliente o un nodo. En
particular se puede observar que si el Cliente 9 quiere acceder a internet, su peticion sera ruteada
a traves del Cliente 8, 7, 6 hasta llegar al Nodo 3, el cual no tiene conexion a Internet, pero
conoce como llegar a ella, por lo tanto rutea la peticion hacia el Nodo 2, y este hacia el Nodo
1 donde nalmente sale a Internet. Cabe destacar que el Cliente 9 sin la colaboracion del resto
de los intermedios por los que paso el pedido hubiera sido imposible llegar al Nodo 1 el cual
geogracamente podra estar a miles de metros.
tica
53
5.2.1. Direccionamiento IP
Figura 5.1: Diagrama de una red M

ovil Urbana
5.2.1.
Direccionamiento IP
En una red IP, es fundamental tener una direccion para poder comunicarse. En las redes
moviles la asignaci
on de direcciones IP es parte del desafo de las funcionalidades que puede
brindar el protocolo de ruteo. En general los protocolos no brindan la capacidad de asignacion
de IP sino que se asume que el dispositivo cuanta con una. Algunas implementaciones tienen la
caracterstica de buscar que no hayan direcciones repetidas dentro de la red en el momento que
un nodo se est
a asociando.
En las redes urbanas y en especial en BAL, las direcciones IP estan distribudas en dos rangos,
un rango para nodos y otro para clientes. Existe una entidad llamada freenetworks 7 , en donde
cada comunidad tiene asignado un rango de IP privadas. Esto garantiza que las redes comunitarias
registradas no tienen direcciones duplicadas. Buenos Aires Libre tiene los rangos asignados por
freenetworks.
A su vez, BAL asigna una subred a cada uno de los nodos para proveer direcciones IP a los
clientes (servicio de DHCP en el nodo) y para comunicacion con otros nodos. Con esta asignacion
llevada a cabo por un grupo de personas de la comunidad se asegura una homogeneidad de
direcciones dentro de la red.
Hasta el momento por la manera que se conectan los clientes (a un nodo jo) es la manera de
asignar IPs, en un futuro cuando toda la red sea idealmente una red movil se utilizara la tecnica
de asignaci
on de ip estandarizada para este tipo de redes. Las pruebas experimentales se hacen
asignando cualquier IP teniendo la precaucion que no sea una direccion repetida.
7 http://www.freenetworks.org
54
tica
Redes M
oviles Urbanas
5.3.
Protocolos de Ruteos
Como se vi
o en la secci
on 2.2 existen varios protocolos para rutear paquetes en una red movil.
Tomar la decisi
on de que protocolo usar queda fundamentalmente sujeto a que implementaciones
hay disponibles. Existen muy pocos protocolos implementados, entre ellos OLSR y AODV. La
implementaci
on de OLSR es actualmente la mas evolucionada e implementada en un proyecto
open source llamado olsrd 8 . Muchos proyectos de redes libres lo utilizan, en particular BAL tiene
implementada la interconexi
on de los nodos con olsrd.
Las pruebas que se est
an llevando a cabo con clientes moviles es con implementaciones de
este mismo protocolo, disponibles para diferentes sistemas operativos.
OLSR es un protocolo proactivo en el cual cada nodo conoce la ruta para llegar a cualquier
destino de la red. Actualmente las redes comunitarias no estan compuestas por muchos nodos,
con lo cual pueden utilizar OLSR como u
nico protocolo.
En un futuro cuando se masique la integracion de los protocolos de redes moviles en los
dispositivos, el n
umero de integrantes crecera en forma desmedida y OLSR no podra ser utilizado
como u
nico protocolo. OLSR es un protocolo que tiene como desventaja que en redes muy grandes
se genera mucho overhead producto de la mantencion de todas las rutas. Cuando esto ocurra
seguramente se utilizar
an protocolos hbridos para minimizar el overhead de la red.
5.4.
Servicios
El objetivo de las redes urbanas es interconectar dispositivos y conformar la red. Sobre esta
se puede brindar cualquier tipo de servicio que se pueda prestar sobre una red IP tradicional.
En BAL por ejemplo hay nodos que tienen servidores de juegos en red, otros repositorios de
archivos, otros nodos comparten ancho de banda de Internet. Fundamentalmente los proyectos
de redes urbanas libres no tienen como n proveer Internet a bajo costo ni vender ning
un tipo
de servicio.
Uno de los proyectos comerciales mas importantes relacionado con las redes urbanas se llama
FON 9 en cual permite a los clientes de FON conectarse a Internet de manera inalambrica en
cualquier ciudad del mundo donde exista FON.
5.5.
Administraci
on de la Red BAL
La red es administrada por los miembros de la comunidad. Los nodos son propiedad de cada
uno, es decir cada due
no de su nodo es responsable del mismo como as de los da
nos que este
pudiese causar. La administraci
on del nodo es de cada uno pero siempre teniendo como premisa
cumplir con los lineamientos de la comunidad BAL. El nodo debe tener asignada una IP provista
por el grupo de Organizaci
on y debe dar servicio con un rango de IPs asignado como as tambien
8 http://www.olrd.org
9 http://www.fon.com
tica
55
5.6. Resumen
existe una convenci

on de nombres para el ESSID del nodo. Cada propietario del nodo puede
prestar el servicio que quiera siempre y cuando este no este en contra del espritu del proyecto.
En denitiva cualquiera puede tener un nodo pero para pertenecer a la red BAL debe ser
aprobado por el grupo de Organizaci
on y esto implica la asignacion de los rangos de IP y el
nombre para el ESSID del nodo.
5.6.
Resumen
En este captulo se hizo una explicacion acerca de las redes urbanas, que caractersticas
topologicas presentan, cuales son los recursos utilizados para sortear los obstaculos puestos por la
geografa de la ciudad y las limitantes del medio de transmision. Se presentaron algunos proyectos
libres que tienen por objetivo conformar una red movil urbana libre y otros proyectos comerciales.
56
tica
Captulo 6
Protocolo OLSR
El objetivo del presente captulo es detallar el funcionamiento del protocolo OLSR
y enumerar algunas vulnerabilidades del mismo.
El el captulo 2 se present
o el protocolo OLSR como un protocolo proactivo o basado en
tablas, es decir todos los nodos de la red conocen la manera de llegar a todos los miembros de la
misma.
En este captulo se detallar
a el funcionamiento del protocolo como tambien se identicaran
los puntos en los cuales es necesario aplicar seguridad para mantener la integridad de la red y
sus integrantes.
6.1.
Introducci
on
OLSR es un protocolo proactivo [5, Sec. 1.3] para redes moviles ad-hoc denido por la RFC
3626. El protocolo hereda la estabilidad del protocolo Link-State y tiene la ventaja de disponer
de las rutas en el momento que son requeridas.
El protocolo mejora de su predecesor el mecanismo de ooding para la distribucion de los
paquetes de control a traves de nodos especcos llamados MPRs (Multi Points Relays), los
cuales son los u
nicos que pueden reenviarlos. De esta manera se optimiza la distribucion de los
paquetes evitando retransmisiones. Los MPRs tienen la caracterstica de tener un enlace solido
con su vecino haciendo que la comunicacion sea lo sucientemente estable.
El protocolo OLSR no necesita ninguna modicacion del stack de protocolos ya que se ubica
por encima de este modicando las tablas de ruteo del sistema.
6.2.
Terminologa Propia de OLSR
Para entender el desarrollo de las proximas secciones es necesario introducir algunos de los
terminos 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 nodo
puede tener m
as de una interfase, cada una con una direccion IP distinta.
Direcci
on Principal: La direcci
on principal de un nodo es utilizada como direccion
originadora del mensaje. Un nodo con m
ultiples interfases OLSR debe elegir una
u
nica IP como direcci
on principal.
Nodo Vecino: Un nodo X es vecino de un nodo Y si el nodo Y puede escuchar al nodo
X.
Vecino de 2-Saltos: Nodo vecino de un vecino.
Multipoint Relay (MPR): Es un nodo vecino del nodo X seleccionado para retransmitir los mensajes broadcast emitidos por X.
Multipoint Relay Selector (MPR Selector): El MPR Selector del nodo X, es el conjunto
de nodos que eligieron al nodo X como MPR.
link: Es el par de interfaces OLSR (de distintos nodos) que pueden escucharse.
link simetrico: Es cuando el par de interfaces de distintos nodos pueden escucharse
una 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 tiene
un enlace simetrico.
Vecino simetrico de 2-Salto: Es un vecino simetrico de un vecino simetrico del nodo
X.
6.3.
Tablas del Protocolo
Como se explic
o en la Secci
on 2.3.1, OLSR es un protocolo proactivo o basado en tablas, es
decir toda la informaci
on necesaria para su funcionamiento es almacenada en tablas. Las tablas
denidas en la RFC, varan con las tablas de la implementacion del protocolo, pero los datos
almacenados en ambas estructuras de tablas son los mismos. Esta simplicacion de tablas es
para hacer m
as r
apido el mantenimiento de las tablas. Las tablas del protocolo OLSR son las
siguientes:
Multiple Interfase Association Information: En esta tabla se almacenan las interfaces
OLSR de los vecinos, es decir, si un vecino tiene dos interfaces OLSR, las dos se asocian a una
direccion principal, que ser
a la utilizada para identicar 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 expiraci
on de la tupla.
Link Set: En esta tabla se almacena el estado de los enlaces con los vecinos.
58
tica
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 extremo
del 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 del
vecino.
L time: Tiempo de expiraci
on de la tupla.
Neighbor Set: Esta tabla tiene por objetivo almacenar el estado de los vecinos, identicandolo solo por la interfaz principal.
N neighbor main addr: Direccion principal del nodo vecino.
N status: Especica si el nodo esta en estado SYM=enlace simetrico o NOT SYM=enlace
no simetrico.
N willigness: Es un entero entre 0 y 7 y especica la conanza que se le tiene al
nodo vecino para llevar el tr
aco.
2-hop Neighbor Set: Se almacena el estado de los vecinos de dos saltos de distancia, identicandolo por la direcci
on de la interfaz principal.
N 2hp addr: Direcci
on principal del nodo vecino de 2-Saltos que tiene enlace simetrico
con N neighbor addr.
N time: Tiempo de expiraci
on 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: Direcci
on principal del nodo.
MS time: Tiempo de expiraci
on 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 por
el nodo con direcci
on principal T last addr.
T last addr: Es MPR de T dest addr.
T seq: N
umero de secuencia.
on de la tupla.
T time: Tiempo de expiraci
Host and Network Asociation Base: Conformada por las tuplas {A gateway addr,
A network addr, A netmask, A time}
A
A
A
A
gateway addr: Direcci

on de la interfase OLSR del gataway.
network addr: Direcci
on de red.
netmask: Mascara de la red.
time: Tiempo de expiraci
on de la tupla.
tica
59
6.4. C
omo Funciona?
6.4.
C
omo Funciona?
OLSR es un protocolo independiente del stack TCP/UDP, es decir utiliza el stack pero no
necesita informaci
on de la capas inferiores para poder operar. El objetivo del protocolo es modicar las tablas de ruteo del Sistema Operativo para poder llegar a todos los nodos de la red, para
ello necesita recolectar informaci
on de su entorno. Esa informacion es relevada con el intercambio
de mensajes con los vecinos. La comunicacion con los vecinos se realiza mediante paquetes UDP
utilizando el puerto 698 [5, Sec. 3.1]. Los datos obtenidos son almacenados en las tablas descriptas
anteriormente para un posterior procesamiento y armado de las rutas.
Los mensajes intercambiados son de tres tipos y con tres nalidades distintas. Los mensajes
de HELLO son mensajes para relevar el estado de los vecinos de primer y segundo nivel, los
mensajes de TC son para informar el estado de los vnculos mas alla de los lmites del nodo
y por u
ltimo los mensajes MID por los cuales se informa a los nodos cuales son las interfaces
disponibles para un determinado nodo. Por medio de estos paquetes es que se conoce como llegar
a un determinado nodo. Estos tres tipos de mensajes son los principales para que OLSR pueda
funcionar. Adicionalmente, existe la posibilidad de que la red se comunique con otras redes. El
armado de esas rutas se hacen por medio del intercambio de mensajes HNA.
Se puede separar el funcionamiento del protocolo en distintas etapas. Primera etapa el censado
y la deteccion de los vecinos, segunda etapa la seleccion de los MPR, tercera etapa propagacion
de la informaci
on de la topologia de la red, cuarta etapa armado de las rutas y por u
ltimo una
quinta etapa con el mantenimiento de las misma (Figura 6.1).
6.4.1.
Mensajes de OLSR
El protocolo [5, Sec 3.3] dene un formato de paquete para todos los mensajes del protocolo.
Para cada tipo de mensaje lo que vara es el contenido del campo MESSAGE que se muestra el la
Figura 6.2.
Los campos del mensaje de OLSR son los siguientes:
Packet Length: Es el tama
no en bytes del mensaje.
Packet Sequence Number: N
umero de secuencia, el cual es incrementado en uno
con el envo 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 considerar
la informaci
on como v
alida.
Message Size: Indica el tama
no del mensaje en bytes. Cuenta desde el campo
Message 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 m
aximo n
umero de veces que el mensaje debe ser retransmitido (cantidad de saltos que debe recorrer).
Hop Count: N
umero de saltos por los que el paquete ha pasado.
60
tica
Protocolo OLSR
Figura 6.1: Etapas del protocolo OLSR
Message Count Sequence: N

umero de secuencia u
nico para cada mensaje. Este
n
umero se incrementa en uno con el envo 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 tipo
de vnculo por el cual los alcanza. Como se comento anteriormente esta tarea es realizada por el
intercambio 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 es
includo en el campo MESSAGE del mismo con Message Type=HELLO MESSAGE. La estructura del
tica
61
6.4.2. Etapa 1: Censado y Descubrimiento de Vecinos
0
1
2
3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Packet Length
|
Packet Sequence Number
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type |
Vtime
|
Message Size
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Originator Address
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time To Live |
Hop Count
|
Message Sequence Number
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
:
MESSAGE
:
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type |
Vtime
|
Message Size
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Originator Address
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time To Live |
Hop Count
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
:
MESSAGE
:
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
:
:
(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 emisi
on de los mensajes de HELLO del nodo que lo origina.
Willingness: Es una valor del 0 al 7 que indica la conabilidad de un nodo para
retransmitir un mensaje. Por ejemplo un nodo con valor WILL NEVER nunca va a
ser elegido como MPR, un nodo con WILL ALLWAYS, siempre va a ser elegido como
MPR. El valor por defecto es WILL DEFAULT.
Link Code: Este campo indica el tipo de vnculo que hay entre la interfase de quien
enva el mensaje con el listado de interfaces de los vecinos. Este campo es de 8 bit
de los cuales solo se interpretan los codigos menores o iguales a 15 como el par de
codigos 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 c

odigo del enlace
Los codigos de los posibles vnculos se denen como:

62
tica
Protocolo OLSR
UNSPEC LINK: No se especica informacion acerca del enlace.

ASYM LINK: Link asimetrico.
SYM LINK: Link simetrico.
LOST LINK: Perdida del vnculo.
Los c
odigos de los tipos de vecinos se denen como:
SYM NEIGH: Indica que al menos una de la interfaces del vecino tiene un
enlace simetrico con el nodo.
MPR NEIGH: Indica que al menos una de la interfaces del vecino tiene un
enlace simetrico con en nodo y a su vez el vecino fue seleccionado como
MPR por el originador del mensaje.
NOT NEIGH: Todava no se tiene un vnculo simetrico con el vecino.
Link Message Size: Indica el tama
no del mensaje en bytes. Cuenta desde el campo
Link 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 direcci
on
principal, por eso es que existe un mensaje que informa a los nodos que un determinado nodo
cuenta con determinadas interfaces OLSR y enva las direcciones de las mismas.
tica
63
6.4.2. Etapa 1: Censado y Descubrimiento de Vecinos
Este mensaje es parte del paquete de OLSR donde es includo 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 direcci
on de cada una de la interfaces. En el header del mensaje OLSR se indica que la IP
que enva el mensaje es la direcci
on principal del nodo, por lo tanto el nodo que recibe el mensaje
asocia esa direcci
on 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 ser

a analizado a partir de las Figuras 6.6 y la Figura 6.7 donde
se plantea un ejemplo paso a paso donde el nodo A se incorpora a la red. En las Figuras se hace
una referencia cronol
ogica de c
omo se van intercambiando los mensajes y como estan las tablas
de cada nodo en cada uno de los instantes. Para una mejor interpretacion y claridad en la gura,
las tablas Neighbor Set, 2-hop Neighbor Set y MPR Set son agrupadas en una sola tabla
llamada Neightbor Table.
En la Figura 6.6 en el instante t1 se puede ver que el nodo A enva el mensaje de HELLO
vaco y un mensaje MID indicando que solo tiene una interfase OLSR. El nodo B tiene como
vecino y MPR al nodo C y este tiene a B como vecino y MPR.
En el instante t2 el nodo B recibe el mensaje de HELLO de A, agrega una entrada en la
Link Table donde indica que A es vecino, recibio el mensaje por la interfase A, es un vnculo
asimetrico (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 y
no es MPR ni vecino de segundo salto.
En ese mismo instante, B enva un mensaje de HELLO informando el estado de sus enlaces
clasicados 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 es
parte del mensaje recibido, por lo tanto agrega una entrada en la tabla de enlaces indicando que
el 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 ya
que este tiene enlace simetrico con B. El nodo C no actualiza la informacion del nodo A porque
el nodo B a
un tiene un enlace asimetrico con A y un vecino de 2-Saltos es considerado cuando
hay un enlace simetrico entre el vecino y el vecino de dos saltos de distancia.
En ese mismo instante A enva un mensaje de HELLO con la informacion de sus enlaces.
64
tica
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 actualiza
la 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 enva 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: Elecci
on de los MPRs
OLSR mejora el mecanismo de ooding de otros algoritmos similares con la eleccion de de

nodos como Multi Point Realys para minimizar los paquetes de control en la red. Por lo tanto
cada nodo debe escoger un conjunto de nodos pertenecientes a sus vecinos de primer nivel como
MPR de manera tal que a traves de ellos pueda llegar a todos los vecinos de dos saltos de distancia
(vecinos 2-Saltos).
Para la elecci
on de los MPRs, el RFC [5, Sec. 8.3.1] dene una heurstica, la cual debe ser
aplicada por cada interfase OLSR del nodo. El conjunto de MPRs de un nodo es la union de los
tica
65
6.4.3. Etapa 2: Elecci

on de los MPRs
Figura 6.7: Censado y Descubrimiento de Vecinos - Parte 1
MPRs encontrados para cada interfase.

Para la denici
on de la heurstica es necesario denir algunos terminos:
Vecino de una Interfase: Vecino que tiene un enlace con el nodo local a traves de una
interfase OLSR en particular.
N: Subconjunto de vecinos de un nodo, los cuales son vecinos de la interfase I.
N2: Conjunto de vecinos 2-Saltos que son alcanzados a traves de la interfase I. excluyendo:
Los nodos que solo son alcanzados por los miembros de N con willigness
distinta de WILL NEVER
El nodo que realiza el c
alculo del MPR (nodo local)
66
tica
Protocolo OLSR
Figura 6.8: Multipoint Relays
Todos los vecinos simetricos: todos los nodos que tengan un enlace
simetrico en alguna de la interfaces.
D(y): El grado del nodo y (donde y es miembro de N ), esta denido por la
cantidad de vecinos simetricos que tenga el nodo y (en todas sus interfaces),
excluyendo todos los miembros de N y el nodo que esta realizando el
c
alculo.
La heurstica de selecci
on de los MPRs es:
1. Selecciona los nodos del Nivel 1 (N ) que cubren nodos aislados del Nivel 2 (N 2). Nodo
aislado es aquel nodo que pertenece al Nivel 2 y tiene como vecino a un solo nodo del Nivel
1. Adem
as se seleccionar
an 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 selecciona
el nodo que cubra el mayor n
umero de nodos de Nivel 2. Esto se repite hasta que todos
los nodos de Nivel 2 hayan sido cubiertos. En caso de empate, se elige el nodo con mayor
willigness, en caso de que esto de m
ultiples nodos, se va a elegir aquel nodo con mayor
(D(y)). En caso que los criterios anteriores no elijan un u
nico nodo se seleccionara de
manera 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 gura 6.9(a) se ve al nodo O
con la distribuci
on de vecinos. N = {1, 2, 3, 4, 5, 6} y N 2 = {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), es
decir M P R1 (O) = {N (v) N 2(O) | N (O) N (v) |= 1} donde v N (O) como se muestra en
la Figura 6.9(b).
El algoritmo, al nalizar la primera fase, elimina de los conjuntos de nodos aquellos que ya
fueron elegidos como MPR y los nodos de Nivel 2 alcanzados por los MPRs seleccionados como
se ve en la Figura 6.10(a).
El pr
oximo paso es ejecutar la segunda fase donde selecciona de los nodos de Nivel 1 aquellos
que cubran m
as cantidad de nodos de Nivel 2 hasta cubrir todos los de Nivel 2. Para ello realiza
tica
67
6.4.4. Etapa 3: Mantenimiento de la Topologa
una iteraci
on donde elige como MPR un nodo que cumpla con M P R2 (O) = {maxwN (O) |
N 2(O)N (w) |} como se ve en la Figura 6.10(a) y elimina del conjunto de nodos para la proxima
iteracion el MPR seleccionado y los nodos de Nivel 2 alcanzables por el mismo (Figura 6.10(b)).
Notar que en el momento de elecci
on del nodos 4 y el nodo 1, se los elige porque estos tiene mayor
cantidad de vecinos (D(y)).
Finalmente los MPRs seleccionados son los que se muestran en la Figura 6.8.
(b) Selecci
on de los nodos de Nivel 1 que tienen vecinos aislados
(a) Distribuci
on de vecinos:
Figura 6.9: Fase 1 : Selecci

on de MPRs que cubren nodos aislados del Nivel2.
(a) Primera iteraci

on de la segunda fase
(b) Segunda iteraci

on de la segunda fase
Figura 6.10: Fase 2: Se completa la selecci

on de MPRs.
El conjunto de MPRs son recalculados cada vez que hay alg

un cambio en los enlaces con los
vecinos.
Cuando un nodo recibe un mensaje de HELLO donde ve que el vecino lo selecciono a el como
MPR (tipo de vecino igual a MPR NEIGH), este agrega la direccion principal del nodo generador
del mensaje en la tabla de MPR Selector. Por medio de esa tabla un nodo pueda saber quien lo
eligio a el como MPR.
6.4.4.
Etapa 3: Mantenimiento de la Topologa
OLSR por ser un protocolo proactivo, debe conocer las rutas hacia todos los destinos de la
red, para ello debe conocer cual es la topologa de la misma. Como el dominio de cada nodo
68
tica
Protocolo OLSR
es conocer la informaci
on de los nodos hasta dos saltos de distancia, necesita alguna manera de
conocer la topologa de la red m
as a alla de ese lmite. OLSR implementa un sistema de mensajes
para informar a los nodos la topologa de la red y los cambios que se produzcan. Para transmitir
esta informaci
on 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 campo

MESSAGE con Message Type=TC MESSAGE. La estructura del mensaje TC es la que se muestra en
la Figura 6.11 cuyos campos son:
Advertised Neighbor Sequence Number (ANSN): N
umero de secuencia para el conjunto de enlaces informados. Este n
umero cambia cada vez que un enlace es agregado
o 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 propagaci
on de los mensajes TC
Para poder diseminar por la red y que cada nodo pueda completar las tablas de topologa
es necesario que cada nodo que haya sido seleccionado como MPR genere un mensaje TC y lo
transmita en forma de broadcast. Cada nodo debe diseminar al menos el conjunto de enlaces con
los nodos que lo eligieron como MPR, o sea los enlaces con su MPR Selector.
En el caso de que la cantidad de enlaces a informar sea mayor a la capacidad del mensaje, se
deberan 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 enva el mensaje no esta entre los vecinos simetricos de un salto de
distancia, se descarta el mensaje.
on
2. Si existe alguna tupla en la tabla de topologa donde T last addr sea igual a la direcci
de origen del mensaje y exista un T seq mayor a ANSN, el mensaje se descarta. Es el caso
de un mensaje viejo.
tica
69
6.4.5. Etapa 4: Formaci

on de las Rutas
3. Todas las tuplas donde T last addr sea igual a la direccion de origen del mensaje y exista
un T seq menor al ANSN del mensaje son eliminadas.
4. Para cada una de las entradas de la tabla de topologa donde T dest addr sea igual a las
direcciones informadas en el mensaje y T last addr sea igual a la direccion de origen del
mensaje, se actualiza el tiempo de vida de la tupla.
5. Para el resto de las direcciones informadas que no estaban en la tabla de topologa, son
agregadas.
6.4.5.
Etapa 4: Formaci
on de las Rutas
Cada nodo tiene una tabla de ruteo con la cual puede llegar a cualquier nodo de la red y
rutear datos hacia cualquier destino. Esta tabla esta basada en la informacion recolectada en la
tabla de enlaces y en la tabla de topologa. Por esa razon es que cualquier alteracion en dichas
tablas provocan un c
alculo de todas la ruta.
Cada una de las entradas en la tabla de ruteo tiene la siguiente forma:
1.
2.
3.
R_dest_addr
R_dest_addr
,,
R_next_addr
R_next_addr
,,
R_dist
R_dist
,,
R_iface_addr
R_iface_addr
,,
donde R dest addr es la direcci

on principal de un nodo que se espera que este a R dist saltos
del nodo actual, R next addr es un vecino que tiene un enlace simetrico con el nodo actual y es
el proximo salto hacia el destino R dest addr y ese vecino lo alcanza a traves de la interfase local
R iface addr.
Para construir una ruta, se utiliza el algoritmo de camino mas corto (Shortest Path Algorithm.
Para la construcci
on 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
R
R
R
R
R
dest addr=direccion principal del nodo de 2-Saltos

next addr=entrada de tabla de ruteo R dest addr donde
dest addr=N neighbor main addr de la tabla 2-hop Neigbor Set
dist=2
iface addr=entrada
en
la
tabla
de
ruteo
iface addr=N neighbor main addr de la tabla 2-hop Neigbor Set
donde
4. El siguiente procedimiento debe ser ejecutado desde h=2 hasta que no se existan mas entradas para agregar.
70
tica
Protocolo OLSR
Para cada entrada de la tabla de topologa, si existe T dest addr que es distinto
a todos los R dest addr de la tabla y el T last addr es igual a un R dest addr
de una entrada de la tabla de ruteo, se agrega una nueva entrada.
R
R
R
R
R
R
dest addr=T dest addr

next addr=R next addr de una entrada de tabla que cumple
dest addr=T last addr
dist=h+1
iface addr=R iface addr de una entrada de la tabla que cumple
dest addr=T last addr
5. Por cada entrada en la tabla de interfaces, cuando exista una entrada donde
R dest addr=I main addr (de una asociacion con varias interfaces) y no exista una entrada para cada asociaci
on del tipo R dest addr=I iface addr, se crea una entrada en la
tabla a modo de alias para cada interfaz.
R
R
R
R
6.4.6.
dest addr = I iface addr

next addr = R next addr de la entrada en la tabla
dist = R dist
iface addr = R iface addr de la entrada en la tabla
Etapa 5: Mantenimiento de las Rutas
El mantenimiento de las rutas es un proceso que se realiza automaticamente cada vez que
se altera un enlace. La alteraci
on de un enlace puede ser que se haya agregado un nuevo vecino
o que alguna de las entradas de las tablas expiro con lo cual es necesario recalcular la tabla de
ruteo.
Por esta raz
on siempre que haya una tabla calculada, todas las entradas son validas.
6.4.7.
Comunicaci
on con Otras Redes
El protocolo OLSR fue dise

nado para que los nodos de la red no solo se comuniquen entre
ellos, sino tambien da la posibilidad de poder comunicarse con otras redes. Para lograr esto, el
protocolo enva mensajes llamados HNA.
6.4.7.1.
Mensaje HNA
El mensaje HNA es enviado como MESSAGE en el paquete general de OLSR denido en la Seccion 6.4.1 con Message Type=HNA MESSAGE. El formato del mensaje se muestra en la Figura 6.12
cuyos campos son:
Network Address: Direcci
on de la red asociada
Netmask: Mascara para la red asociada.
tica
71
6.5. Seguridad
0
1
2
3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Network Address
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Netmask
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Network Address
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Netmask
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
...
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figura 6.12: Formato del mensaje HNA
6.4.7.2.
Asociaci
on de la redes
Los mensaje HNA, son emitidos por todos los nodos informando las redes externas a las
cuales el nodo puede acceder. Estos mensajes son similares a los mensajes TC ya que indican
un camino hacia una nueva red. A diferencia de los mensajes TC los HNA incluyen el campo
netmask correspondiente para la red.
De esta manera cuando un nodo recibe un mensaje HNA, agrega una entrada en la tabla de
asociacion de nodos y redes con A gateway addr igual a la direccion principal de donde provino
el mensaje y con la direcci
on de la red y la mascara que vienen en el mensaje y se le coloca un
tiempo de expiraci
on a la tupla.
Estas nuevas rutas hacen que la tabla de ruteo las deba incluir. Por lo tanto, al procedimiento
de actualizaci
on de la tabla de ruteo descripto en la Seccion 6.4.6 se le debe agregar que para
cada una de las entradas de la tabla de asociacion de nodos y redes se debe crear una nueva
entrada en la tabla de ruteo donde:
R
R
R
R
R
6.5.
dest addr=A network addr/A netmask

next addr=R next addr de una entrada donde R dest addr=A gateway addr
dist=R dist de la entrada al gateway
iface addr=R iface addr
de
la
entrada
en
la
tabla
donde
dest addr=A gateway addr
Seguridad
El protocolo OLSR no tiene especicadas medidas de seguridad [5, Sec. 20]. Como OLSR es
un protocolo proactivo es muy sensible a cualquier ataque y puede poner en peligro la integridad
de la red.
6.5.1.
Condencialidad
OLSR enva peri

odicamente mensajes con informacion de la topologa de la red, esa informacion puede ser usada por un atacante y modicar la topologa de la red. El RFC de OLSR no
72
tica
Protocolo OLSR
dene ninguna alternativa para garantizar la condencialidad de los mensajes de control. Solo
propone utilizar mecanismos de encriptacion de clave compartida o usar PGP sin brindar detalles
de la forma de su implementaci
on.
6.5.2.
Integridad
En OLSR cada nodo inyecta en la red informacion de la topologa a traves de los mensajes de
HELLO y TC. Por ser el medio de propagacion de los mensaje el aire, es un medio no controlado
y cualquier nodo podra enviar informacion invalida con lo cual se compromete la integridad de
la red. Por lo tanto, alg
un mecanismo de autenticacion debe ser implementado pero el RFC [5] no
indica con que algoritmo, ni de que forma, solo recomienda el uso de autenticacion para prevenir
alguna de estas situaciones:
1. Un nodo genera mensajes TC (o HNA) informando enlaces con nodos que son vecinos
2. Un nodo genera mensajes TC (o HNA) en nombre de otro nodo
3. Un nodo genera mensajes de HELLO informando que tiene vecinos que no lo son
4. Un nodo genera mensajes de HELLO haciendose pasar por otro nodo
5. Un nodo reenva mensajes de control alterados
6. Un nodo no reenva un mensaje de control
7. Un nodo no selecciona su MPR correctamente
8. Un nodo replica mensajes de control grabados de otro nodo
La autenticaci
on previene alguna de estas situaciones pero no todas. Para prevenir el punto
8 es necesario implementar alg
un mecanismo de informacion temporal para que un nodo pueda
identicar claramente los mensajes viejos.
En general los paquetes necesarios para la autenticacion, pueden ser enviados dentro del
paquete generico de OLSR como un tipo de mensaje distinto. De esta manera se podra hacer
que convivan nodos seguros y nodos inseguros.
6.5.3.
Mensajes a Proteger
Los mensajes que deben ser protegidos contra nodos malicioso son los mensajes de HELLO, los
TC y los HNA. Estos paquetes son los encargados de armar y diseminar por la red la informaci
on
de la topologa de la misma. Un atacante puede usar estos mensajes y modicarlos para benecio
propio.
Es necesario que estos mensajes sean encriptados y autenticados para garantizar condencialidad e integridad de los mensajes.
Aplicando seguridad sobre estos mensajes no garantiza que la red va a ser segura ya que nodos
participantes de la red pueden causar intencionalmente o no ataques, pero eliminara muchos
posibles atacantes externos.
tica
73
6.6. Vulnerabilidades
6.6.
Vulnerabilidades
OLSR por ser un protocolo que corre sobre el stack TCP/UDP, tiene las vulnerabilidades
intrnsecas con la tecnologa en la cual se apoya para operar. Estos ataques son comunes a todos
los protocolos que trabajan en esta modalidad, los ataques son ataques a la capa fsica y MAC,
generando interferencias sobre el canal y saturando a la vctima con mensajes. Este tipo de
ataques no son tenidos en cuenta por los protocolos ya que es tarea de las capas inferiores mitigar
estas amenazas.
En OLSR cada nodo tiene dos responsabilidades fundamentales. La primera es que cada nodo
debe generar la informaci
on de ruteo de manera correcta y la segunda es que cada nodo es
responsable de reenviar los paquetes recibidos a otros nodos de la red. Cualquier alteracion de
estas responsabilidades pueden terminar amenazando la integridad de la red.
(a) El nodo O enva un mensaje de HELLO pretendiendo ser 3
(b) El nodo O enva un mensaje de HELLO anunciado un link falso con 1
Figura 6.13: Generaci

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

A. Generaci
on Incorrecta de Mensajes de Control
a) Generaci
on incorrecta de mensajes HELLO: Un posible ejemplo de este ataque es que
un nodo malicioso puede tomar la identidad de otro nodo (Figura 6.13(a). El nodo O
se toma la identidad de 3. Los nodos 1 y 2 anuncian que pueden llegar a 3 a traves
de sus mensajes de HELLO y TC. El nodo O elige MPRs entre sus vecinos siempre en
nombre del nodo 3, por lo tanto los nodos que fueron elegidos como MPR, informan en
sus mensajes TC que ellos son el u
ltimo salto hacia 3. Esto genera conictos en las rutas
hacia 3 y podra dejar al nodo con perdida de conexion.
Otro ataque con esta modalidad es la modicaci
on de enlaces [15, Sec. III.A] que tiene
un nodo (Figura 6.13(b)). En este caso el nodo O enva en su mensaje de HELLO que
tiene un enlace con 1 (que no es vecino). Esto tiene como consecuencia que el nodo 3
tenga un MPR Set incorrecto y los mensajes provenientes de 5 y reenvados a traves de
los MPRs nunca llegue a 1.
b) Generaci
on incorrecta de mensajes TC [15, Sec. III.B]: La generacion de mensajes TC
con direcci
on de origen incorrecta puede generar informacion erronea referente a la re74
tica
Protocolo OLSR

on incorrecta de mensajes TC
laci
on de los vecinos (Figura 6.14). El nodo malicioso O enva un mensaje TC en lugar
del nodo 3 informando que el nodo 1 es su vecino. El nodo 4 concluye de manera erronea
que 3 y 1 son vecinos. La generacion de mensajes TC con informacion de enlaces falsos
tiene las mismas consecuencias.
c) Generaci
on incorrecta de mensajes MID/HNA: Un nodo podra enviar mensajes informando que tiene determinada interfase emitiendo el mensaje con una direccion de
origen perteneciente a otro nodo. Este ataque hace que los nodos que reciben el paquete
no puedan alcanzar al nodo real a traves de la interfase que envio el nodo malo ya que
esa interfase no existe.
d ) Ataque a los n
umeros de secuencia: Un nodo malicioso podra escuchar los mensajes TC
de un nodo A y almacenar el ANSN (Advertised Neighbor Sequence Number ) del mensaje,
luego enva mensajes falsicando la direccion de origen con ANSN mucho mayores que el
almacenado. Seg
un el protocolo, los nodos ignoraran los mensajes con ANSN menores al
u
ltimo recibido, por lo tanto los mensajes de A seran descartados porque seran tomados
como viejos.
B. Reenvo Incorrecto de Mensajes de Control
a) Ataque del Agujero Negro: Este ataque se produce cuando un nodo no reenva los mensajes como lo requiere el protocolo, de este modo se disminuye la informacion de los
enlaces disponibles en la red. Si los mensajes TC no son reenviados, la red comienza a
tener problemas de conectividad y hasta podra llegar a dividirse. Si no se reenvan los
mensajes HNA, se podra perder el acceso hacia otras redes.
b) Ataque por Reenvo de Mensajes: Un nodo atacante podra grabar todos los mensajes
que pasaron por el durante un determinado perodo y luego mas tarde reinyectarlos en
la red modicando todas las tablas de ruteo de los nodos. Los mensajes TC no pueden
ser inyectado en la misma manera como fueron grabados, sino que de debe poner un
n
umero ANSN grande para que sean aceptados por los nodos, causando de esta manera
un ataque de n
umero de secuencia.
c) Ataque del t
unel ( wormhole attack) [18, Sec. 4]: Este ataque tiene mucho impacto en la
red. Consiste en grabar el traco en un sector de la red y reproducirlo tal cual en otra
tica
75
6.6. Vulnerabilidades
(a) T
unel creado por O entre 3 y 4
(b) T
unel creado por O y O0 (c
omplices) entre
3y4
Figura 6.15: Ataque por t

unel (Wormhole)
regi
on de la misma. Se puede generar un enlace articial entre el nodo 3 y el 4 a traves
de un nodo atacante (Figura 6.15(a)) o si un nodo agresor tiene un complice y puede
generar un t
unel 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 sucientes mensajes de HELLO a traves del t
unel como para establecer un enlace simetrico.
Mientras el enlace no sea simetrico, los mensajes TC/MID/HNA son descartados. Con
el enlace simetrico establecido, todos los paquetes que vayan de un extremo al otro de la
red van a ser enviados a traves del t
unel porque se va a creer que es la ruta mas corta y
el tr
aco va a pasar todo por el nodo atacante.
d ) Ataque al ( MPR-Flooding): Una de las primeras reglas de transmision enunciada en la
especicaci
on de OLSR es que durante el proceso de ooding de los MPRs, los mensajes
recibidos son vericados si provienen de un nodo dentro del MPR Selector del nodo y los
mensajes iguales recibidos posteriormente son descartados. Por ejemplo un nodo A enva
un mensaje B y X (nodo malicioso), donde B es MPR de A y X no el MPR. X reenva
(sin tener que hacerlo seg
un la especicacion) el mensaje a C, luego B tiene como MPR
a C y reenva el mensaje a A. Ese mensaje es descartado porque el mismo mensaje de
lo envi
o X con lo cual resulta que se interrumpe el ujo del paquete (Figura Bd ).
Figura 6.16: Ataque al (MPR-Flooding)
C. Ganar posici
on privilegiada: Cualquiera de los ataques antes mencionados pueden ser
explotados de mejor manera si el nodo es posicionado como MPR, para ello el nodo primero
76
tica
Protocolo OLSR
ingresa a la red y enva los mensajes de HELLO con Willingness WILL ALWAYS. De esta
manera es muy probable que alg
un nodo lo elija como MPR y una vez ubicado comienza con
cualquiera de los ataques.
6.7.
Resumen
En este captulo se mostr

o el funcionamiento del protocolo OLSR, cuales son los mensajes que
se intercambian, que informaci
on 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 de
los nodos vecinos y de la red en general. Se realizo una presentacion de las vulnerabilidades que
presenta el protocolo, las cuales ser
an analizadas y se propondra una contramedida en el protocolo
para hacerlo m
as robusto.
tica
77
6.7. Resumen
78
tica
Captulo 7
Dise
no de un Esquema de
Seguridad para una Red M
ovil
OLSR Urbana
El objetivo de este captulo es presentar el dise
no del esquema de seguridad para
una Red M
ovil basada en OLSR teniendo en cuenta los aspectos organizacionales de
las comunidades que las administran y cuestiones propias del protocolo.
En el Captulo 5 se present
o como es la topologa y el funcionamiento de una Red Movil Urbana. Teniendo en cuenta las caractersticas de una red de este tipo y las cuestiones administrativas
de la comunidad que la mantiene es que se va a dise
nar un esquema de seguridad para dichas
redes.
7.1.
Esquema de Seguridad
Un esquema de seguridad son combinaciones de primitivas (operaciones matematicas basicas) combinadas con metodos adicionales [22]. Los esquemas proveen seguridad teorica y esta es
mejorada cuando es aplicada apropiadamente en un protocolo para poder cumplir con las caractersticas de seguridad enumeradas en el Captulo 4. Es decir, todos los elementos auxiliares
para que un nodo, por ejemplo, pueda encriptar el traco, autenticarse con el nodo remoto y
estar seguro que el nodo remoto es al que se le quiere enviar la informacion. Para lograr esto es
necesario dise
nar y establecer un esquema de seguridad que especique claramente los roles que
tienen cada uno de los elementos que lo componen y de que manera se relacionan.
79
7.2. Fundamentos del Dise

no
7.2.
Fundamentos del Dise

no
El dise
no del esquema de seguridad utiliza la topologa de una Red Movil Urbana y a la vez
la forma de organizaci
on de la comunidad que la conduce.
Con lo que respecta a la topologa de la red se tiene en cuenta que en una Red Movil Urbana
se cuenta con un n
umero de nodos jos, los cuales garantizan la intercomunicacion de los nodos
que a nivel de tierra no pueden hacerlo debido a que la tecnologa utilizada para la comunicacion
(IEEE 802.11x) necesita linea de visi
on directa con el otro extremo del vnculo.
Estos nodos tienen un rol importante dentro de la red y deben estar dados de alta y ser reconocidos por la Comunidad y haberles asignado una IP, un rango de IPs para poder brindar servicio
y un ESSID (nombre de red) estandarizado dentro de la Comunidad. Este aspecto organizativo
es el que se tiene en cuenta en el dise
no del esquema.
El esquema de seguridad propuesto tiene como objetivo hacer una Red Movil Urbana Segura
y para ello se necesita un protocolo de ruteo que sea seguro. Para cumplir con este requisito se
van a denir tres niveles o etapas de securizacion del protocolo. La primer etapa tiene en cuenta
brindar los servicios b
asicos que debe tener una red segura como se describio en el Captulo 4. La
segunda etapa tiene por objetivo mejorar las capacidades de defensa ante los ataques mas comunes
(Sec. 6.6) y por u
ltimo la tercer etapa en la cual la red pueda ser capaz de autodefenderse ante
un ataque.
Para lograr los objetivos de esquema de seguridad se plantea el uso de un esquema de clave
p
ublica y privada, distribuidas por medio de certicados. Cada cliente de la red necesitara un
certicado para poder comunicarse. Ese certicado es expedido por una Autoridad Certicante
(CA) perteneciente a la red.
El uso de un esquema de clave p
ublica y privada es el pilar sobre el cual se va a basar
la implementaci
on de un protocolo seguro para garantizar la seguridad de la primera etapa de
securizacion.
Un elemento importante a la hora de describir la tercera etapa de seguridad es un Sistema
de Deteccion de Intrusos (Intrusion Detection System - IDS ) que es responsable de monitorear
el comportamiento de los integrantes de la red. Este componente se basa en reglas de comportamiento que son establecidas por el administrador o auto-aprendizaje. En caso que un miembro
de la red tenga un comportamiento indebido, el IDS enva dicha informacion a la Autoridad
Certicante y se deniega su participaci
on en la red revocando su certicado.
Los componentes (CA, IDS) deben correr en nodos que la Comunidad establece como conables. No siempre el IDS y la CA deben correr en el mismo nodo pero s los nodos deben ser
seguros.
7.2.1.
OLSR m
as Fuerte
El coraz
on del dise
no de una red m
ovil segura es contar con un protocolo de ruteo conable
y seguro. Para ello y como se mencionaba antes se va tratar la seguridad del mismo por etapas
o niveles de seguridad. El fortalecimiento de OLSR toma como punto de partida el esquema
de certicaci
on que le va a proveer certicados para asegurar el canal de comunicacion entre
80
tica
Dise
ovil OLSR Urbana
Figura 7.1: Componentes participantes en el esquema de seguridad propuesto
los nodos. En la segunda etapa el protocolo original es modicado para prevenir los ataques
mas comunes (timestamp attack, wormhole attack, DoS, etc). Por u
ltimo se propone un tercer
nivel de seguridad, en el cual la misma red se deende de los intrusos. Este nivel sera descripto
brevemente y queda fuera del alcance de la presente tesis.
7.3.
Esquema de Clave P
ublica y Privada
Como componente principal se busca lograr la autenticacion de cada uno de los nodos para
poder conar y estar seguro que son nodos pertenecientes a la red. Para ello se utilizara un
esquema de clave p
ublica y privada mediante el uso de certicados digitales.
7.3.1.
Autoridad Certicante
Como se enunciaba en la Sec 3.1.6 una Autoridad Certicante es un componente de PKI

(Public Key Infreatructure) encargada de otorgar y revocar certicados digitales.
El rol de la CA dentro de la infraestructura es validar la autenticidad de claves p
ublicas. El
proceso de generaci
on de claves comienza cuando un miembro genera un par de claves y solicita
a la CA que rme su clave p
ublica, la CA genera un certicado incluyendo la clave p
ublica de la
solicitud y rma este certicado con su clave privada. De esta manera cualquier nodo que tenga la
clave publica de la CA puede estar seguro que la clave p
ublica recibida de otro nodo es conable.
Tpicamente una CA es u
nica en la red y esto puede hacer que nodos no lleguen a esta debido
a interrupciones temporales de enlaces u otras cuestiones propias de la topologa de las redes
moviles.
7.3.2.
Esquema de Certicaci
on
El esquema de seguridad planteado tiene como punto de partida la utilizacion de certicados

digitales para autenticar las partes. Para ellos va a existir una Autoridad Certicante perteneciente a la comunidad (por ejemplo Buenos Aires Libre).
Cada nodo que participa en la red, debe solicitar a la comunidad una serie de datos para
poder operar en la misma (IP para el nodo, rango de IPs para asignar a sus clientes, un SSID
tica
81
7.3.2. Esquema de Certicaci

on
estandarizado). La comunidad enrola a este nuevo nodo, registra el nodo a la red, le da la informacion requerida y en conjunto con los datos solicitados se le da un certicado rmado por la
CA de la comunidad. Por ser un nodo enrolado, y la comunidad conoce al due
no del nodo, es
considerado seguro.
De esta manera el nodo con el certicado expedido por la CA de la comunidad va a poder
rmar requerimientos de certicados de los clientes que se conecten a el (Figura 7.2).
Figura 7.2: Esquema de Certicaci

on. CA de la comunidad expide certicados a los nodos enrolados y
estos expiden certicados a los clientes
Para garantizar disponibilidad (uno de los requisitos del los protocolos seguros) de las CAs,
hay varias distribudas a lo largo de la red. Cada nodo tiene un listado de CAs disponibles
ordenados por proximidad.
En la Figura 7.3 se representa un ejemplo practico donde se puede representar la interaccion
de los nodos jos, los nodos enrolados y los nodos moviles. Puede ser un campeonato de juegos
en red a realizarse en todas las plazas de la Capital Federal. El propietario de un nodo enrolado
se moviliza con el mismo hasta la plaza mas cercana y a
un tiene lnea de vision con alg
un nodo
jo de la red para garantizar la conectividad hacia el backbound de la red. Los participantes que
se acercan a su plaza m
as cercana para participar del torneo van a ser clientes moviles que por
primera vez se van a conectar a la red, por lo tanto solicitaran un certicado al nodo enrolado mas
cercano para poder participar en el torneo. Cabe aclarar que toda la negociacion de certicados
y gestiones para que el cliente acceda a la red son transparentes al cliente, el protocolo es el
encargado de la tarea. Una vez que este nuevo cliente ingresa a la red podra acceder al servidor
de juegos que se encuentra a miles de metros al cual accede primero routeando a traves de los
nodos cercanos en la plaza hasta llegar al nodo enrolado que se movilizo hasta la misma, el cual
le provee acceso al backbound de nodos interconectados jos hasta llegar al servidor de juegos.
82
tica
Dise
ovil OLSR Urbana
Figura 7.3: Ejemplo de utilizaci

on de una red M
ovil 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 agregando
informaci
on de las CA en los mensajes del protocolo sino que se rmaran los mensajes crticos
(HELLO, TC, MID, HNA) implementando lo expuesto en [21]. En [21] Hafslund y Tonnesen proponen rmar los mensajes con una clave compartida, pero en el esquema propuesto se rmara con
una clave que se intercambia durante el proceso de autenticacion y luego son encriptados con una
clave de sesi
on generada entre las partes para garantizar autenticacion, integridad y condencialidad.
7.4.1.
Prevenci
on de Ataques
Con la rma de los mensajes se puede garantizar la integridad del mismo.

Con la encriptacion del mensaje con una clave de sesion negociada previa autenticacion de
las partes, se garantiza la condencialidad y no repudio.
Con el agregado de un algoritmo de timestamp se previene la retransmision de mensajes
viejos.
Con un algoritmo heurstico se puede inferir si el mensaje proviene de un nodo vecino o de
uno lejano a traves de un t
unel (prevencion de wormhole attack ).
Se implementar
an tecnicas para prevenir ataques de DoS y ataques que hagan realizar al
nodo desgaste de energa en el procesamiento de mensajes maliciosos.
tica
83
7.5. Integraci
on del IDS y la CA
En el Captulo 9 se dar
a el detalle de la implementacion de todos los puntos antes mencionados.
7.5.
Integraci
on del IDS y la CA
La comunicaci
on entre las CAs y los IDS se realiza de la misma manera que entre cualquier
nodo. Primero se autentican uno con otro y se establece una clave se sesion y se encripta el
traco. La interacci
on de los IDSs con la CAs es mediante mensajes especcos para informar
comportamientos de los nodos.
7.6.
Interacci
on de los Nodos Clientes con Esquema de Seguridad Planteado
En esta secci
on se har
a referencia a como un nodo se integra a la red. Como pre-requisito, al
igual de cuando se navega por sitios seguros de Internet, el nodo cliente debe conocer de antemano
la clave p
ublica de la CA de la comunidad.
El primer paso que realiza el cliente es generar su propio par de claves. Segundo, inicializa el
proceso de descubrimiento de vecinos (ya pertenecientes a la red). Durante dicho procedimiento
recolectara informaci
on de los vecinos y a la vez de las CA mas cercanas. Una vez que conoce
cuales son la CAs, enva un requerimiento de un certicado a la CA mas cercana para poder
operar en la red. Recibido el certicado, valida que este en la cadena de certicacion la CA de
la comunidad y toma el certicado como valido y comienza una ronda de autenticacion con sus
vecinos. En la ronda de autenticaci
on se establece la clave se sesion entre cada par de nodos para
cifrar los mensajes y se intercambian de manera segura los parametros de inicializacion para el
algoritmo de timestamp. Finalmente, cuando se autentican los vecinos, el nodo pasa a ser un nodo
conable en la red salvo que detecte un comportamiento anomalo y sea excluido de la red.
Mientras que el nodo no se encuentre autenticado por otro nodo, este permanecera en estado
no seguro y no participar
a en la elecci
on de MPR ni se le aceptaran mensajes distintos a los
mensajes de HELLO.
7.6.1.
Esquema de conanza ganada
El esquema de ganar conanza se basa en el comportamiento del nodo en la red. Cuando

un nodo ingresa por primera vez a la red, se le asigna un certicado por un perodo de tiempo
corto, cuando ese certicado este por expirar, se vuelve a generar un nuevo pedido. La CA analiza
el comportamiento del nodo con la ayuda de los IDSs y si no tuvo comportamientos malos se
le asigna un certicado con un tiempo de expiracion m
as largo. Este procedimiento se repite
constantemente pero vale aclarar que un nodo cliente de la red no puede convertirse en CA si no
se enrola en la comunidad como tal.
84
tica
Dise
ovil OLSR Urbana
7.7.
Resumen
En este captulo se present

o cual es el dise
no del esquema de seguridad propuesto a nivel
macro y sin dar mayores detalles, solo se introdujo cuales seran los actores involucrados y que
rol tiene cada uno dentro del esquema. En el Captulo 9 se daran los detalles de lo planteado en
el presente captulo.
tica
85
7.7. Resumen
86
tica
Captulo 8
Artculos m
as Relevantes
Relacionados con la Seguridad de
OLSR
El objetivo de este captulo es realizar un resumen de los principales artculos
ledos para el desarrollo de la presente tesis, los cuales fueron las principales fuentes
de informaci
on e inspiraci
on para la creaci
on del Esquema de Seguridad para una
Red M
ovil Urbana basada en OLSR .
Las redes m
oviles hace a
nos que son objeto de estudio en todo el mundo, como parte de estas
investigaciones, nunca queda de lado temas referentes a la seguridad, ya que por la tecnologa y
la naturaleza de este tipo de redes, los miembros de la misma se encuentran expuesto a ataques
continuamente. Como se detall
o en el Captulo 2, existen diferentes tipos de protolocolos de ruteo,
los cuales en su mayora no preveen cuestiones de seguridad. En el Captulo 4 se detallaron los
principales protocolos de ruteo seguros. Dentro de los protocolos disponibles, para el desarrollo de
esta tesis se eligi
o el protocolo OLSR, el cual como se dijo en varias oportunidades no es seguro
pero es el m
as popular en las redes moviles urbanas.
La seguridad del protocolo OLSR tambien ha inquietado a distintas personas y laboratorios
de investigaci
on en todo el mundo y han propuesto distintas alternativas de securizacion, las
cuales fueron pilares para la elaboracion de la presente tesis.
Los principales trabajos sobre el tema son: Secure Extension to the OLSR protocol [21], Secure
OLSR [18], Securing the OLSR protocol [30].
87
8.1. Secure Extension to the OLSR protocol
8.1.
8.1.1.
Secure Extension to the OLSR protocol

Overview
Este artculo, que fue escrito por los implementadores del protocolo OLSR, propone una
extension del mismo asegurando la integridad y autententicando los mensajes.
Los autores asumen que cada nodo conoce una clave compartida con la cual autenticaran los
paquetes. La soluci
on propuesta es utilizar una rma por paquete OLSR y la solucion brinda
paquetes rmados salto-a-salto y no una solucion de rmado de punta a punta. El fundamento
de esta tecnica es que los paquetes son reenviados a traves de nodos seguros, con lo cual el
destinatario recibe un paquete rmado por el nodo anterior que no es el originador del mismo,
pero este nodo previo confa en el nodo que le reenvio el mensaje y as sucesivamente.
Los nodos que no conozcan la clave compartida no podran vericar ni generar una rma
vericable.
8.1.2.
Firma
Para generar la rma del paquete OLSR, se crea un nuevo mensaje, el cual se puede ver el
detalle en la Figura 8.1 y el u
ltimo mensaje del paquete OLSR. Como se puede entender, existe
un mensaje de rma por cada paquete OLSR.
0
1
2
3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
SCHEMA
|
ALGORITHM
|
Reserved
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
TIMESTAMP
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
SIGNATURE (160 bits)
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figura 8.1: Mensaje de rma b

asico
En el mensaje de rma se especica que esquema de rma se esta usando y que algoritmo.
Luego una marca de tiempo para prevenir ataque de reenvo de paquetes (se explica mas adelante)
y por u
ltimo una rma del paquete utilizando SHA-1. En realidad, no es una rma digital como
se denio en el Captulo 3, lo que llama rma es un MAC donde usa como clave el timestamp.
Con el agregado de este mensaje, la longitud del paquete debe ser recalculada agregando al
longitud del mensaje de rma.
8.1.3.
Timestamps
La extensi
on propuesta en el artculo incluye la generacion de timestamps por cada paquete
para prevenir el reenvo del mismo paquete en otro instante. Para calcular el timestamp se realiza
un intercambio de mensajes para establecer una diferencia en el reloj remoto y el del nodo.
El intercambio de relojes entre dos nodos A y B es el siguiente:
88
tica
Artculos m
1. A B : Cha , D(M, K)
2. B A : Chb , T sb , D(IPb , Cha , K), D(M, K)
3. A B : T sa , D(IPa , Chb , K), D(M, K)
Cuando A recibe un mensaje rmado de B del cual no tiene registro de su reloj, enva un
mensaje de desafo hacia B. El mensaje tiene como destino la IP de B, un n
umero aleatorio Cha
y el resumen del mensaje utilizando la clave compartida K (D(M, K)).
B responde con un mensaje de respuesta de desafo el cual tiene un n
umero aleatorio Chb , el
reloj de B, un resumen de la IP de B, el n
umero al azar generado por A y la clave. Por u
ltimo
un resumen criptogr
aco 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 correctas
utiliza el reloj enviado por B. Por u
ltimo A enva una respuesta a B similar a la enviada por B
y luego B valida las rmas 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 timestamp
del paquete y calcula la diferencia con su reloj calculando TN = Tlocal Tpaquete . A continuaci
on
eval
ua T0 S < TN y T0 + S > TN , donde T0 es la diferencia horaria almacenada. En caso que
la validaci
on del timestamp sea correcta se procesa el mensaje, en caso contrario se descarta.
Para compensar alg
un desfasaje de los relojes, se realiza un ajuste de T0 calculando el promedio
entre la diferencia horaria almacenada y la calculada para este paquete (T0 = (T0 + TN )/2).
8.2.
8.2.1.
Secure OLSR
Overview
En este artculo se propone un mecanismo de deteccion de vecinos seguros teniendo en cuenta la posibilidad de ataque de t
unel durante el descubrimiento. Una vez que los vecinos son
descubiertos se ingresa en una ronda de autenticacion de los mismos. Conocidos los vecinos y
autenticados se comienzan a enviar paquetes de control, se propone un mecanismos de rma para
los mensajes de control as se puede garantizar la integridad de los mismos.
El artculo asume que cada nodo tiene un par de claves p
ublica/privada expedida por alguna
entidad, no se detalla cual es el mecanismo por el cual se garantiza la identidad de la clave p
ublica.
8.2.2.
Detecci
on segura de vecino
Durante la etapa de descubrimiento de vecinos se puede ser objetivo de un ataque de t

unel
(wormhole attack ), por lo tanto los autores proponen una forma heurstica de determinar si el
mensaje proviene de un vecino real o de un vecino tuneleado.
Los vecinos son aquellos que se encuentran a un solo salto de distancia. Asumiendo que la
velocidad de propagaci
on de un paquete es cercana a la velocidad de la luz, entonces la distancia
recorrida por el paquete es de L = t c, al mismo tiempo se calcula que una placa de red de un
tica
89
8.2.3. Autenticaci
on de vecinos
dispositivo m
ovil tiene un radio de cobertura R (por ejemplo 100 metros), por lo tanto si L > R
entonces se est
a en presencia de ataque y si L R no.
La forma propuesta para implementar este mecanismo de defensa es la siguiente:
1. B enva un mensaje de prueba a A e inicializa un contador.
2. Cuando A recibe el mensaje de prueba, enva la respuesta e inmediatamente inicia un
contador.
3. Una vez que B recibe la respuesta de A, detiene el contador y enva 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 decisiones
que el punto anterior.
8.2.3.
Autenticaci
on de vecinos
Una vez superada la etapa de detecci

on de vecino, el nodo debe realizar una ronda de autenticacion. El mecanismo de autenticaci
on es por medio de un intercambio de mensajes.
1. A genera un paquete que contiene un n
umero al azar (RA ), el certicado de A (CertA ), los
identicadores de A y B, y un hash encriptado con clave privada de A (rma).
A B : A, B, CertA , RA , sign(H(A, B, CertA , RA ))
Donde H() es una funci
on hash y sign() es una operacion de rma.
2. Cuando B recibe el paquete, primero verica el certicado de A, luego extrae la clave
p
ublica de A y verica la rma del paquete. Una vez hecho esto, B enva un paquete que
contiene un n
umero al azar grande (RB ), el certicado de B, los identicadores del A y B
y un hash encriptado con la clave privada de B (rma).
B A : B, A, CertB , RB , sign(H(B, A, CertB , RA , RB ))
3. Cuando A recibe la respuesta de B, verica si el certicado de B es valido, verica la rma.
Terminada esta etapa A confa que B es un vecino seguro. A enva un u
ltimo 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 relacion
de conanza con el vecino
90
tica
Artculos m
Figura 8.2: Pasos para lograr una relaci

on de conanza 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 serie
de campos que son modicables durante la propagacion del mismo y otros no. Para garantizar la
integridad de los campos que no deben cambiar durante la propagacion, se utiliza un algoritmo
de rma y para los campos variables se utiliza cadena de hash para securizar Hop Count y TTL.
La extensi
on 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: Extensi

on del paquete OLSR
Cuando un nodo genera un nuevo paquete realiza los siguientes pasos:

Genera un n
umero aleatorio Seed.
Hash Hop = H T T L (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 H T T LHop Count (Seed), si el valor es igual a Hash Hop del paquete, se
verica la rma, si es correcto se sigue con el proximo paso.
T T L = T T L 1; HopCount = Hop Count + 1; Seed = H(Seed)
tica
91
8.3. Securing the OLSR protocol
8.3.
8.3.1.
Securing the OLSR protocol

Overview
En este artculo se presenta un framework que permite securizar el protocolo OLSR de los
siguientes ataques:
Generaci
on Incorrecta de Tr
aco de Control
Generaci
on de Mensajes de HELLO Incorrecta
Generaci
on de Mensajes de TC Incorrecta
Reenvo de Tr
aco de Control Incorrecto
En el desarrollo de la soluci
on se asume que el comportamiento de un nodo seguro no se altera
y mantiene su buena conducta en la red. La informacion de control generada por este tipo de
nodos es la que se conserva ntegra.
Para lograr esto, se proponen requerimientos criptogracos como:
Una funci
on que permita retornar la rma de un mensaje, por ejemplo sign(nodeid, key,
message).
Una funci
on que permita vericar la rma, por ejemplo verif(originatorid, key,
message, signature).
Una clave compartida para poder rmar y validar la rma
8.3.2.
Firma de Mensajes
Con los elementos descriptos, el nodo que genera un mensaje de control genera un mensaje de
rma, el cual es enviado uno por cada mensaje generado (pueden generarse varios mensajes de
rma para un paquete OLSR). Este mensaje de rma se enva de forma independiente al mensaje
de control, con lo cual el nodo que recibe el mensaje de control no lo acepta hasta no recibir el
mensaje de rma correspondiente al mensaje.
El mensaje de rma se puede ver en la Figura 8.4. Este es enviado en la porcion de datos del
paquete general de OLSR con el Message Type SIGNATURE MESSAGE. Para poder determinar
a que mensaje corresponde la rma, el mensaje de rma tiene un n
umero (MSN Referrer) que
es el n
umero de secuencia del mensaje de control. En el campo Sign Method, se especica que
algoritmos se van a utilizar para realizar el hash, que metodo de timestamping se va a utilizar e
informacion sobre la clave utilizada.
Para calcular la rma del mensaje de control, se ignoran los campos del mensaje que pueden
variar durante la vida del mensaje (TTL y Hop Count) tomandolos como cero. En este esquema
de rma se genera una autenticaci
on y validacion del mensaje de punta a punta.
92
tica
Artculos m
0
1
2
3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sign. Method |
Reserved
|
MSN Referrer
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
:
Timestamp
:
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
:
Signature
:
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figura 8.4: Formato del mensaje de rma
8.3.3.
Timestamping
En el mismo artculo, en la secci

on V, se presentan distintos algoritmos de timestamping para
prevenir ataques de reenvo 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 alg
un mecanismo de
sincronismo de relojes entre los nodos
Non-volatile timestamp: Este algoritmo exige que cada nodo mantenga en memoria no
vol
atil los relojes de cada uno de los nodos de la red, cada una de esas entradas es inicializada
cuando recibe el primer mensaje. Mientras que el nodo emisor mantiene una tabla con todos
los relojes de los nodos de la red, el receptor tiene una tabla con todos los valores maximos
de timestamp recibido de cada nodo. El emisor utiliza un valor de reloj de la tabla y luego
lo incrementa.
Timestamp Exchange Protocol : Este mas que un algoritmo es un protocolo de intercambio de
relojes, por medio del cual se generan mensajes con desafos encriptados. Para el intercambio
de mensajes se utilizar
a la notacion X Y : {Z}SX , que signica que X enva un mensaje
Z a Y encriptado con la clave privada de X
1. t0 : A B : {A, TA (t0 )}SA
2. t1 > t0 : B A : {B, TB (t1 ), A, TA (t0 )}SB
3. t2 > t1 : A B : {A, TA (t2 ), B, TB (t1 )}SA
8.3.4.
PKI
Finalmente en la secci
on IV, se proponen dos esquemas de PKI para redes moviles, uno es
proactivo y el otro es reactivo.
tica
93
8.3.4. PKI
8.3.4.1.
PKI Proactiva Simple para OLSR
Este PKI funciona con tres tipos de nodos: Nodos no conables, Nodos Conables, Autoridades Firmantes. Un nodo no es conable si la clave publica de x no es conocida por a o si
la clave p
ublica de x es conocida pero no esta rmada por la Autoridad Firmante. Un nodo es
conable si la clave publica de x es conocida por a y a la vez esta rmada por la Autoridad
Firmante. La Autoridad Firmante es un nodo de la red que es conocido por todos los otros nodos
y tiene la capacidad de registrar claves p
ublicas para nuevos nodos. La Autoridad Firmante enva
periodicamente un listado de las claves de los nodos conables.
Cada nodo que quiera participar en la red debera registrar su clave p
ublica en la Autoridad
Firmante, esta peri
odicamente distribuye el listado de claves. Cada nodo almacena las claves
hasta que expiran. Este mecanismo requiere que las claves sean renovadas periodicamente.
Cuando la red se inicializa, ning
un nodo conoce ninguna clave de la red, salvo la de la Autoridad Firmante, por lo tanto todos los nodos van a ignorar los mensajes de control de los otros
nodos, ning
un nodo va a ser elegido como MPR y ning
un mensaje broadcast va a ser reenviado.
Todos los nodos tienen que esperar que la Autoridad Firmante comience a emitir mensajes con
las claves.
Durante la inicializaci
on de la red, la Autoridad Firmante enva su certicado a todos los
vecinos de un salto de distancia, seguido realiza un intercambio de mensajes de HELLO, los vecinos
de un salto de distancia aceptan a los vecinos de dos saltos como simetricos pero no los eligen
como MPRs. La Autoridad Firmante elige MPRs entre los vecinos de un salto y as el proximo
broadcast de claves llega a los vecinos de dos saltos de distancia. As contin
ua inundando la red
para que todos los nodos conozcan las claves p
ublicas de los nodos conables.
Todos los nodos deben mantener tablas con la informacion de claves de sus vecinos y si son
conables 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 solicita
a la red. Para ello se incorporan dos nuevos mensaje, Key Request y Key Reply.
La solicitud de una clave se realiza con el mensaje Key Request que tiene un NA que es un
n
umero aleatorio, la identicaci
on del nodo y una lista de todas la claves solicitadas. El mensaje
es enviado a toda la red. A all : {A, NA , B1 , ..., BN }SA .
La respuesta es enviada en el mensaje Key Reply. La Autoridad Firmante cuando recibe
el requerimiento, primero valida la rma del mensaje de A (si tiene la clave p
ublica de A), y
luego arma el mensaje de respuesta con el listado de claves p
ublicas que conoce. P all :
{P, A, NA , (Bi1 , P KBi1 ), ..., (Bim , P KBim )}SP
Cuando A recibe la respuesta, valida que el A sea realmente el destinatario del mensaje, que
P sea a una Autoridad Firmante conocida, que la rma del mensaje sea correcta y que el NA sea
valido.
La retransmisi
on de los mensajes de solicitud y respuesta de claves se realizan mediante el
mecanismo de inundaci
on convencional, por ejemplo si un nodo recibe un mensaje, lo reenva una
94
tica
Artculos m
sola vez.
8.4.
Resumen
En este captulo se resumieron distintos artculos los cuales plantean distintas alternativas de
securizaci
on para el protocolo OLSR. Las soluciones aportadas por estos fueron utilizadas para
el desarrollo de la presente tesis adaptandolas a las necesidades del protocolo propuesto.
tica
95
8.4. Resumen
96
tica
Captulo 9
Detalles de Implementaci
on del
Esquema de Seguridad Propuesto
En este captulo se dar
a un detalle de lo propuesto en el Captulo 7, llegando a
profundizar cuestiones relacionadas al protocolo OLSR como a los aspectos organizacionales de las comunidades de llevan adelante los proyectos de redes m
oviles urbanas.
Luego de la presentaci
on del esquema de seguridad planteado para una red movil urbana en
el Captulo 7, en este captulo se dara los detalles de todos los puntos propuestos para lograr una
red m
ovil segura.
Se analizar
an los detalles tanto organizativos que la comunidad debe realizar antes de dar de
alta un nodo jo en la red como as las piezas de protocolo necesarias para que interact
uen los
elementos involucrados en el esquema.
Los elementos principales necesarios para la implementacion del esquema de seguridad propuesto son: Autoridad Certicante, el protocolo de ruteo, los clientes de la Red y el Sistema de
Detecci
on de Intrusos. El an
alisis de la implementacion del IDS, no es el objetivo del presente
captulo ni de la Tesis.
Se tratar
an en detalle los mecanismos organizativos de la comunidad a la hora de registrar
un nodo como CA, con respecto al protocolo de ruteo se deniran tres niveles de securizacion
de los cuales se har
a un detalle minucioso de los dos primeros y el tercero se plantea como una
extensi
on y es objeto de estudio futuro.
9.1.
Esquema de Certicaci
on
Tal como se adelant

o en el Captulo 7, uno de los principales componentes del esquema
propuesto es la existencia de certicados digitales para autenticar a los nodos pertenecientes a
la red. Esto se logra teniendo una entidad responsable de emitir certicados garantizando que el
97
9.2. Fortalecimiento del Protocolo OLSR
nodo portador del mismo es conable.

La comunidad va a tener un u
nico certicado con el cual va a rmar certicados para los
nodos jos de la red que se enrolen.
9.1.0.3.
Procedimiento para la registraci

on de un nodo
La asignaci
on de certicados es una tarea de la comunidad que administra la red. Si una
persona tiene un nodo y quiere participar de la comunidad, esta necesitara darse de alta en la
comunidad para que se le asigne una IP para su nodo perteneciente al backbone de la red, un
rango de IPs para asignar a los nodos clientes que se unan a la red a traves de el y un ESSID
estandarizado (opcional). Si el propietario del nodo va a participar activamente en la red, es decir,
su nodo una vez congurado va a estar disponible sin interrupciones de servicio prolongadas,
puede solicitar ser CA para poder rmar certicados para sus clientes. La Comunidad conoce
a los propietarios de los nodos porque en general tienen una participacion activa en los foros,
listas de correos y reuniones organizativas, con lo cual se esta seguro cuales son los nes del nodo
solicitante y se puede asumir que es un nodo seguro.
El objetivo cuando la red no tiene muchos nodos jos es que todos los nodos jos sean CAs
para minimizar el traco de backbone solicitando certicados a otros nodos de la red. Hoy en da,
por ejemplo Buenos Aires Libre no cuenta con la cantidad de nodos suciente como para que un
nodo cliente pueda ver dos o m
as nodos jos y as tener la posibilidad de que haya nodos jos
que no sean CAs. Por esto es que es necesario que todos los nodos jos asuman la responsabilidad
de ser CA.
9.2.
Fortalecimiento del Protocolo OLSR
El protocolo OLSR como se vi

o en el Captulo 6 no dispone de ninguna prevencion contra
los posibles ataques vistos en la Secci
on 6.6, por lo tanto como parte del esquema de seguridad
propuesto no se puede dejar de lado la seguridad del protocolo de ruteo. Por eso es que en el
dise
no se separ
o el fortalecimiento de OLSR en distintos niveles.
En el primer nivel se detallar
an las modicaciones del protocolo para garantizar los servicios basicos que debe ofrecer una red segura: Disponibilidad, Condencialidad, Autenticacion,
Integridad y No Repudio ( [15]).
En el segundo nivel se realizar
an las modicaciones al protocolo para mitigar las vulnerabilidades mas crticas que presenta el protocolo.
Por u
ltimo en el tercer nivel se tratara como podra funcionar el esquema propuesto para que
la red tenga un mecanismo de autodefensa.
Los mensajes del protoloco original [5] van a ser los mismos (HELLO, TC, HNA y MID) y se le
agregaran una serie de mensajes propios de la solucion propuesta, los cuales seran detallados en
las siguientes secciones.
98
tica
9.3.
Fortalecimiento de OLSR: Nivel 1
A lo largo de esta secci

on se detallaran todos los componentes, las interacciones y los mensajes
necesarios para hacer que OLSR garantice los servicios basicos de seguridad. Para garantizar estos
servicios es necesario introducir modicaciones a las tablas originales del protocolo, a los mensajes
y los mecanismos y formas de comunicacion. En esta seccion se especicaran las modicaciones
a las distintas etapas del protocolo original: Deteccion de Vecinos, Descubrimiento de la Red y
Armado de la Tabla de Ruteo.
9.3.1.
Tablas del Protocolo
En la Secci
on 6.3 se detallaron cuales son las tablas que utiliza el protocolo OLSR seg
un su
RFC. En esta propuesta de fortalecimiento del protocolo, se modicaran 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 status: Especica si el nodo esta en estado SYM=enlace simetrico o NOT SYM=enlace
no simetrico.
N willingness: Es un entero entre 0 y 7 y especica la conanza que se le tiene al
nodo vecino para llevar el tr
aco.
N trusted: Indica si el vecino es conable o no
N cert: Se almacena el certicado del vecino
N sessionKey: Se almacena la clave de sesion generada
N deltaTimestamp: Se almacena la diferencia entre el reloj local y el reloj del vecino.
Esta columna ser
a usada para mitigar ataques de reenvo de paquetes
N localKey: Durante el proceso de autenticacion se genera una clave local para rmar
los mensajes
N remoteKey: Durante el proceso de autenticacion el nodo remoto genera una clave
con la cual rmar
a sus mensajes
N neighbor trust level: Indica el nivel conanza que la CA le dio al nodo vecino
(informacion incluida en el certicado)
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 por
el nodo con direcci
on principal T last addr.
T last addr: Es MPR de T dest addr.
T seq: N
umero de secuencia.
T CA: Indica si el nodo es CA o no
T time: Tiempo de expiraci
on de la tupla.
tica
99
9.3.2. Obtenci
on del Certicado
9.3.2.
Obtenci
on del Certicado
El nodo que ingresa a la red lo primero que hace es intentar obtener un certicado para poder
autenticarse con sus vecinos. El proceso de obtencion del certicado comienza con la emision
de un nuevo mensaje llamado CADISCOVER. Los vecinos que reciban este mensaje devolveran el
mensaje adjuntando al mismo el listado de CAs que tiene cada uno y la cantidad de saltos que
tiene hasta llegar a esta.
9.3.2.1.
Generaci
on del mensaje CADISCOVER
El nodo que desea participar en la red genera un mensaje como el que se muestra en la
Figura 9.1 y lo incorpora en el paquete OLSR con tipo de mensaje CADISCOVER. El cuerpo del
mensaje va a ser vaco, es decir no se especicara direcci
on 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 informacion de la Tabla de Topologa de la cual obtiene cuales son los nodos CAs y de la Tabla de Rutas
de la cual obtiene el n
umero de saltos hacia el destino.
Para armar el mensaje de respuesta, se coloca en el destino del mensaje la direccion del nodo
que realizo la petici
on. Luego completa el mensaje incorporando el listado de las CAs conocidas
agrupandolas por cantidad de saltos.
Los nodos solo generar
an respuestas cuando los mensaje recibidos no contengan una direccion
de destino y el listado de CAs esten vacos. Un mensaje que cumple con estas condiciones es
considerado una petici
on.
Cuando un nodo recibe un mensaje considerado peticion realiza lo siguiente:
Actualiza la tabla de vecinos (Neighbor Set)
100
tica
Confecciona el mensaje de respuesta.

Enva el mensaje generado
Cuando un nodo recibe un mensaje que tiene una direccion de destino, verica que dicha
direcci
on 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 direcci
on agrupada bajo cada cantidad de saltos se agrega una entrada en la tabla
de rutas colocando como R dest addr la direccion de la CA, como R next addr la direccion
del nodo de donde provino la respuesta, R dist igual a la cantidad de saltos y nalmente
la R iface addr la direcci
on de la interfaz por la que recibio la respuesta.
Esta generaci
on de la tabla de rutas no es igual a la realizada por OLSR, pero es necesaria
generarla de esta manera en esta etapa y por u
nica 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.
Generaci
on del CERTREQ
El nodo que pretende obtener un certicado, genera un nuevo mensaje de tipo CERTREQ que
es enviado en forma segura a la CA elegida por menor distancia. El formato de este mensaje se
puede ver en la Figura 9.2
Los nodos vecinos solo reenviar
an de un nodo no conable (no autenticado) mensajes con
destino a una CA. Un nodo siempre va a conocer que el destino es una CA ya que este nodo le
dijo al nodo que genera el mensaje que el saba 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 de
certicado (CertReqMessage [27]). Para enviar la solicitud a la CA mas cercana debe hacerlo de
tica
101
9.3.2. Obtenci
on del Certicado
forma segura seg

un lo especica el RFC 2511 de X.509[27, Sec. 2]. Para cumplir con la norma,
se establece una conexi
on SSL [28] con la CA. Como el nodo cliente conoce el certicado de la
rootCA de la comunidad, verica que el certicado presentado por la CA a la hora de establecer
la sesion SSL este rmado por la rootCA. De esta manera el nodo cliente se asegura que se
esta conectando a una CA segura. Cabe aclarar en este punto que solo es necesario que el nodo
que intenta obtener un certicado sea el u
nico que verique la identidad de la CA ya que no
es necesario que la CA valide la identidad del nodo porque el proposito de este mecanismo es
obtener una identidad temporal para un nodo anonimo.
Una vez establecido un canal seguro, el nodo crea un mensaje CERTREQ donde incluye el
mensaje CertReqMessage de X509 denido en la Seccion 3 del RFC 2511 (Figura 9.2) y se lo
enva a la CA.
Un nodo cuenta con m
as de una CA, en caso que existan, con lo cual comienza intentando
enviar el mensaje CERTREQ a la CA m
as cercana y luego a las mas alejadas. Con esta caracterstica
se gana disponibilidad de las CAs ya que sin la obtencion del certicado, el nodo nunca sera parte
de la red.
9.3.2.4.
Generaci
on del Certicado
Como se mencion
o anteriormente una CA tiene un certicado expedido por la rootCA de
la comunidad. Una vez que el nodo cliente establece una conexion segura con la CA, enva el
mensaje solicitando un certicado. La CA consulta en su CRL si este nodo esta presente. En caso
que no este en la CRL, expide un certicado con una validez temporal.
La validez del primer certicado ser
a de una hora y el nivel de conanza es de uno. Ese
nivel de conanza es un par
ametro que la CA agrega como campo de texto en una extension del
certicado. El nivel de conanza permite a un nodo cambiar su rol de participacion en la red a
medida que va gan
andola con un buen comportamiento en la red.
Una vez que se tiene el certicado expedido, es enviado al nodo en la misma sesion SSL. Es
decir, el proceso de solicitud de un certicado es sincronico.
La respuesta con el certicado rmado es devuelto en un mensaje de tipo CERTREPLY como
se muestra en la Figura 9.3.
9.3.2.5.
Renovaci
on de certicado
Un nodo cuando est

a por vencer su certicado debe solicitar una renovacion del mismo.
El procedimiento para la renovaci
on es el mismo que para la solicitud, es decir, establece una
conexion SSL con la CA y enva el mensaje. En este caso el mensaje que se enva es de renovacion
(tipo CERTRENEW). En el mensaje se enva el certicado anterior para una renovacion (Figura 9.4).
Los perodos de expiraci
on se calculan, de forma arbitraria, duplicando el perodo de validez
del certicado anterior, es decir V ALIDEZ = V ALIDEZ 2, tomando como perodo de validez
inicial una hora. Con cada renovaci
on se gana un nivel mas de conanza. El nivel de conanza
permite a un nodo cambiar su rol de participacion en la red.
Con esta tabulaci
on de perodos de validez, una CA puede saber por cuanto tiene que renovar
un certicado sin necesidad que el certicado anterior haya sido expedido por la misma CA. La
102
tica
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 Conanza Ganado
Valido por (hs)
16
...
...
...
Cuadro 9.1: Validez del certicado por renovaci

on
Autoridad puede saber la cantidad de renovaciones haciendo

N ro Renovaciones =
ln (f echa expiracion f echa emision)

ln (2)
y no es necesario que una CA mantenga un contador con la cantidad de certicados expedidos

para un nodo.
La CA recibe el certicado y valida que haya sido expedido por una CA autorizada, verica
por cuanto tiempo tiene que ser expedido, incrementa el nivel de conanza, lo genera y se lo enva
al nodo en un mensaje CERTREPLY.
El perodo de renovaci
on ser
a como maximo un a
no, o sea cuando el nodo logra obtener un
certicado con una validez de un a
no, en cada renovacion recibira un certicado de un a
no.
Una vez que se tiene el nuevo certicado expedido, es enviado al nodo en la misma sesion
SSL, es decir el proceso de renovaci
on del certicado es sincronico.
9.3.3.
Detecci
on de Vecinos
El proceso de detecci
on de vecinos sera de la misma manera que se realiza en el protocolo
original mediante un censado de vecinos. Cuando el nodo se incorpora a la red enva un mensaje
de tipo CADISCOVER, cuando los vecinos responden, el nodo actualiza su tabla de enlacess con
los vecinos poniendo el estado del enlace como ASYM LINK y tipo de vecino como NOT NEIGH y
no conable. Los nodos que reciben el mensaje CADISCOVER actualizan su tablas de enlaces con
los vecinos y agregan al nuevo vecino como no conable y el estado del enlace como ASYM LINK
y tipo de vecino como NOT NEIGH. De esta manera un nodo nunca elegira al nuevo nodo como
tica
103
9.3.3. Detecci
on de Vecinos
MPR ya que es condici

on que el nodo tenga un enlace simetrico para participar en la eleccion de
MPR.
En el procedimiento de censado de vecinos propuesto se incorpora una modicacion mnima
al procedimiento original. Se agrega un nuevo tipo de vecino a los ya existentes (NOT NEIGH,
MPR NEIGH y SYM NEIGH) llamado CA NEIGH. Es decir en un mensaje de HELLO se incorpora un
nuevo Link Code donde se indica que ese enlace es con un vecino que es CA, es decir es una
extension de la informaci
on 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 tipo
de vecino MPR NEIGH con un nodo y luego la direccion del nodo esta listada con Link Code
correspondiente a CA NEIGH, se actualiza la tupla en la tabla de vecinos indicando que el vecino
con el cual se tiene ese enlace es CA.
Un nodo puede informar que el es CA enviando su direccion en el listado de direcciones con
Link Code CA NEIGH y cuando un nodo procese este mensaje comparara la direccion de origen
del mensaje y la direcci
on listada como CA NEIGH y actualizara la entrada en la tabla de vecinos
indicando que el origen del presente mensaje de HELLO es una CA.
No es necesario cambiar la cantidad de bits para representar ese nuevo Link Code ya que
en el protocolo original se usan dos bits para representar cuatro tipo de enlaces y dos bits
para representar tres tipos de vecinos, con lo cual al agregar un nuevo tipo de vecino se puede
representar con los dos bits destinados para este n.
9.3.3.1.
Autenticaci
on de los vecinos
Una vez que el nodo obtiene un certicado, comienza el proceso de autenticacion. El nodo en
esta etapa ya conoce a sus vecinos los cuales fueron reconocidos en la respuesta al mensaje de
HELLO de tipo CADISCOVER. El nodo comienza la autenticacion con cada uno de los vecinos de su
listado de vecinos.
Para intercambiar los par
ametros de autenticacion se utilizan dos nuevos mensaje
AUTH MESSAGE (Figura 9.5), AUTH MESSAGE FINISH (Figura 9.6)
0
1
2
3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Destination
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Source
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
:
Source Cert
:
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Random Value
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
:
Signature (160bits)
:
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figura 9.5: Formato del mensaje AUTH MESSAGE
104
tica
Procedimiento de Autenticaci
on 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 n
umero al azar (RA ), el certicado de A (CertA ), los
identicadores de A y B, y un hash encriptado con clave privada de A (rma).
A B : A, B, CertA , RA , sign(H(A, B, CertA , RA ))
Donde H() es una funci
on hash y sign() es una operacion de rma.
2. Cuando B recibe el paquete, primero verica el certicado de A si corresponde a un certicado rmado por una CA de conanza, luego extrae la clave p
ublica de A y verica la
rma del paquete. Una vez hecho esto, B enva un paquete que contiene un n
umero al azar
(RB ), el certicado de B, los identicadores del A y B y un hash encriptado con la clave
privada de B (rma).
B A : B, A, CertB , RB , sign(H(B, A, CertB , RA , RB ))
3. Cuando A recibe la respuesta de B, verica si el certicado de B es valido y fue rmado
por una CA de la red, verica la rma. Terminada esta etapa A confa que B es un vecino
seguro y agrega el certicado, en la tabla de vecinos marcandolo como conable, actualiza el
estado de los enlaces con B como SYM LINK y tipo de vecino SYM NEIGH. A enva un u
ltimo
mensaje a B.
0
1
2
3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Destination
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Source
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
:
Signature (160bits)
:
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figura 9.6: Formato del mensaje AUTH MESSAGE FINISH
A B : A, B, sign(H(A, B, RA , RB ))
4. Cuando B recibe la respuesta, conrma que A es un vecino seguro. Actualiza la tabla de
vecinos con el certicado de A y marca a A como vecino seguro. Tambien actualiza el estado
de los enlaces con A como SYM LINK y tipo de vecino SYM NEIGH.
En este punto un nodo malicioso o mal congurado puede enviar miles de mensajes de
autenticaci
on seguidos, lo cual puede generar una Denegacion de Servicio. En el detalle
del pr
oximo nivel de securizacion se detallara cual es la manera de prevenir este tipo de
comportamiento.
tica
105

on de los mensajes
9.3.3.2.
Elecci
on de MPR
La eleccion de MPR se realiza de la misma manera que en el protocolo original ya que con
la modicaci
on incorporada, solo se va a lograr tener un enlace simetrico con un vecino luego
que se hayan autenticado. Es de mucha importancia que un MPR sea un nodo autenticado ya
que va a ser el punto de ruteo hacia un sector de la red. Si este nodo no es seguro se pondra
en riesgo el ruteo y la integridad de la red. Como un punto parametrizable para el protocolo
se puede establecer cual es el nivel de conanza mnimo que se tiene que tener con los vecinos
para elegirlo como MPR. Este par
ametro debe ser congurable ya que en un red chica con pocos
nodos, establecer un umbral alto dejara el nodo aislado pero ya es riesgo del usuario usar un
umbral bajo.
9.3.4.
Firma y encripci
on de los mensajes
Para implementar seguridad sobre OLSR, es preciso identicar cuales son los paquetes y los
mensajes crticos para poder securizarlos. Los mensajes que hay que proteger son aquellos que
por alguna manipulaci
on pueden poner en riesgo la integridad de la red. Los mensajes a proteger
claramente son los mensajes HELLO, TC, HNA y MID.
Para la implementaci
on de seguridad sobre estos mensajes se pueden plantear dos alternativas,
una autenticando y encriptando el mensaje de punta a punta [30] o rmando y encriptando el
paquete OLSR [21] dando una autenticacion y encripcion salto por salto.
Para la encripci
on de punta a punta es necesario que los dos extremos de la conexion se
autentiquen mediante el intercambio de certicados y generar una clave de sesion para realizar un
encriptado simetrico. Con el uso de claves asimetricas generara un desperdicio de energa porque
hara uso intensivo del procesador. Esta alternativa no es considerada viable ya que implicara
mucho overhead de control y en caso de ser un nodo remoto a varios saltos de distancia el
intercambio de mensajes podra interrumpirse y requerira una nueva negociacion. La propuesta
de [30] utiliza un mensaje de rma por separado que requiere un seguimiento de los mensajes
recibidos y vericar la rma de los mismos. Esta tarea requiere tener almacenados esos mensajes
y compararlos con los mensajes recibidos, con lo cual se tiene un gasto extra de procesador para
esta tarea.
La autenticaci
on y encripci
on salto a salto es mas eciente pero no permite una vericacion
del mensaje de punta a punta. En el analisis el funcionamiento de OLSR 6.4, se vio que el
protocolo en s utiliza el reenvo de paquetes para la propagacion de mensajes con lo cual utilizar
una encripci
on y autenticaci
on 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 reenva, son nodos
conables y autenticados.
9.3.4.1.
Obtenci
on de la Clave de Sesi
on
Una de las premisas de este dise

no es generar un protocolo que garantice integridad y condencialidad, para ello es necesario utilizar una rma y una clave para encriptar el mensaje. Como
se vio en el Captulo 3, existen dos tipo de cifradores, los simetricos y los asimetricos. Como
106
tica
la cantidad de mensajes intercambiados entre un nodo y su vecino es muy grande, utilizar un

esquema de clave p
ublica y privada generara un malgasto de la energa del nodo, para ello es
que se utiliza una clave se sesi
on 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)
:
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
:
Signature (160bits)
:
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figura 9.7: Formato del mensaje AUTH MESSAGE RESPONSE
El algoritmo de intercambio para la generacion de una clave de sesion, toma lugar durante el
proceso de autenticaci
on para minimizar los mensajes intercambiados. Para realizar el intercambio
de claves se incorpora un nuevo mensaje, el AUTH MESSAGE RESPONSE (Figura 9.7) y se debe
modicar AUTH MESSAGE FINISH quedando como se muestra en la Figura 9.8
0
1
2
3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Destination
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Source
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
:
Encripted Key (A)
:
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
:
Signature (160bits)
:
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figura 9.8: Formato del mensaje AUTH MESSAGE FINISH
En el Paso 2 del proceso de autenticacion, el nodo B ya tiene el certicado de A. B encripta

un n
umero al azar de un n
umero de bits jos (N = 128 para esta implementacion) con su clave
privada y luego con la clave p
ublica de A.
tica
107

on de los mensajes
En el Paso 3 el nodo A hace lo mismo que el nodo B. Finalizada esta etapa, los dos nodos
tiene los dos n
umeros al azar (KA , KB ) y ning
un otro nodo pudo haber obtenido estos n
umeros.
1. A B : A, B, CertA , RA , sign(H(A, B, CertA , RA ))
2. B A : B, A, CertB , RB , EP uA (EP rB (KB )), sign(H(B, A, CertB , RA , RB , EP uA (EP rB (KB ))))
3. A B : A, B, EP uB (EP rA (KA )), sign(H(A, B, RA , RB , EP uB (EP rA (KA ))))
A partir de esta etapa los nodos utilizan como clave de sesion el producto de estos dos n
umeros
1
truncados a N bits . Una vez completado el calculo de la clave compartida, es almacenada en la
tabla de vecinos. El perodo de validez de la clave de sesion es igual al valor de expiracion del
enlace con el vecino (campo L time de la tabla Link Set). Cuando ese perodo este proximo a
vencerse 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 alg

un nodo intruso, se realiza el rmado
2
del mismo con el algoritmo HMAC . Como se describio en el captulo 3 el algoritmo HMAC es un
algoritmo que aplica una funci
on al mensaje y se obtiene un resumen criptograco del mismo.
La funcion que se aplica recibe como parametro un mensaje y una clave (Figura 9.9). HMAC
involucra una funci
on de hash aplicada al mensaje combinada con la clave HM ACK (m) =
h((K opad)k(h((K ipad)km)). La implementacion del algoritmo utilizada es HMAC-SHA-1, por
lo tanto en la expresi
on anterior h() es SHA-1 y el resultado nal sera una rma de 160 bits.

on de la rma
HMAC no solo garantiza que el mensaje no fue modicado sino que tambien lo autentica. En este
dise
no 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).
1 Este
c
alculo para la clave sesi
on es determinado de forma arbitraria y es parte del protocolo propuesto.
no es estrictamente una rma digital como se deni
o en el Captulo 3, pero en este caso ser
a utilizado
para garantizar integridad y autenticaci
on del mensaje.
2 HMAC
108
tica
Los paquetes de OLSR tiene dos tipos de campos, los que no varan entre salto y salto y
los que varan cuando son reenviados. Para esta propuesta de protocolo no es necesario tener en
cuenta estos campos ya que la autenticacion y la vericacion de la integridad del paquetes es
llevada a cabo salto-a-salto. Diferenciar estos campos es importante si la integridad del mensaje
es evaluada en el extremo de la ruta. En denitiva la rma se realizara sobre:
Encabezado del paquete OLSR (con el tama
no ajustado para incorporar la rma)
Todos los mensajes OLSR includos en el paquete
Las cabeceras del mensaje de rma.
0
1
2
3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
SCHEMA
|
ALGORITHM
|
Reserved
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figura 9.10: Formato del mensaje rma
Se genera un nuevo mensaje (Figura 9.10) con la rma y se agrega al nal del paquete OLSR.
El tama
no del paquete OLSR debe ser reajustado para incorporar la rma al nal como se ve en
la Figura 9.11. M
as adelante cuando se trate la prevencion de ataques en el nivel 2 de securizacion
se vera que el mensaje de rma sufre una ligera modicacion.
9.3.4.3.
Protocolo de encriptaci
on
Para garantizar la condencialidad de la informacion que viaja en el paquete, se aplica encripcion sobre el mismo. El algoritmo para encriptar los paquetes debe tener un cifrador simetrico
ya que hay que optimizar el uso de CPU del dispositivo movil. El algoritmo elegido para esta
tarea es el AES [31, Captulo 5]. AES es un cifrador por bloques y es el cifrador adoptado como
el cifrador est
andar para el gobierno de los Estados Unidos y es el sucesor del 3DES. Utiliza
una clave que puede ser de 128, 192 o 256 bits. Para este dise
no se utilizara una clave de 128
bits. La clave utilizada para encriptar los paquetes es la clave de sesion calculada en la ronda de
autenticaci
on truncada a 128 bits.
Cuando el nodo destino recibe el mensaje, la primera operacion que debera hacer es desencriptar el paquete con la misma clave que se utilizo para encriptarlo (Figura 9.12), luego contin
ua
el procesamiento del paquete validando la rma.
9.3.5.
Descubrimiento de la Topologa
Con la modicaci
on introducida, cada nodo tiene que conocer cuales son la CAs de la red,
para ello utilizan la tabla de topologa. Para diseminar esta informacion por la red, se generan
dos mensaje TC diferentes. Uno anunciando los enlaces de la misma manera que se hacen en el
tica
109
9.3.6. Armado de la tabla de Ruteo
0
1
2
3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Packet Length
|
Packet Sequence Number
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type |
Vtime
|
Message Size
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Originator Address
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time To Live |
Hop Count
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
:
MESSAGE
:
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type |
Vtime
|
Message Size
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Originator Address
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time To Live |
Hop Count
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
:
MESSAGE
:
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
SCHEMA
|
ALGORITHM
|
Reserved
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figura 9.11: Formato del paquete de OLSR rmado
protocolo OLSR original [5, Sec. 9] y otro mensaje informando de los enlaces conocidos cuales
son con una CA. Para diferenciar estos dos tipos se mensajes se utiliza el campo reservado en el
mensaje de TC y se le coloca un indicador para se
nalar que las direcciones contenidas en el mismo
correspondes a nodos que son CAs.
Para armar los mensajes TC con la informacion de la CAs, se hace de la misma manera que
en el protocolo original, con la modicacion que solo se tomaran las direcciones de los vecinos del
Neighbor Set que sean CAs.
La forma de reenvo de los mensaje TC no sufren ninguna modicacion con respecto al protocolo
original.
9.3.6.
Armado de la tabla de Ruteo
El procedimiento Armado de la tabla de Ruteo no sufre ninguna modicacion con respecto a

la especicaci
on del protocolo original [5, Sec. 10]
9.3.7.
Logros del Nivel 1 de securizaci

on
En lo detallado del Nivel 1 de securizacion se puede ver que es el nivel mas complejo ya que
hay que incorporar mecanismos y elementos de criptografa y comunicacion auxiliares para lograr
110
tica
Figura 9.12: Firma + Encripci

on de un paquete
un determinado nivel de seguridad. En este nivel se puede garantizar los servicios basicos de una
red segura:
Autenticaci
on: Con la fase de autenticacion entre los nodos, se produce el intercambio de
certicados rmados por CAs de la red, con lo cual ambos nodos estan seguros que estan
conectados con quienes dicen ser.
Integridad: Con el esquema de rmado de los mensajes los nodos estan seguros que nadie
ha modicado su contenido.
Condencialidad: Luego del procedimiento de autenticacion se establece una clave de sesi
on
entre los dos nodos, con lo cual el traco que es encriptado con esa clave solo puede ser
ledo por ellos.
No repudio: Ambos extremos de un enlace estan autenticados con certicados expedidos
por la CA, estos certicados son intercambiados para garantizar la identidad de cada uno.
Disponibilidad: Teniendo redundancia de las CAs, un nodo siempre va a tener donde solicitar
o renovar certicados.
Teniendo asegurados los paquetes de control el protocolo ya esta mas seguro pero no es inmune
a ataques, por ello es que se plantea el Nivel 2 de fortalecimiento donde se mitigan algunos ataques.
9.4.
Tener autenticados y encriptados los paquetes de control pone al protocolo OLSR mas solido
pero a
un as un nodo que permanece en la red durante un determinado tiempo podra realizar
distintos ataques como el Ataque del T
unel y el Ataque de Reenvo de Paquetes.
9.4.1.
Prevenci
on contra ataque Wormhole
Unos de los ataques analizados en la Seccion 6.6 es el Ataque del t

unel (wormhole attack ) en
donde un nodo utiliza los mensajes de HELLO generados en un sector de la red y los reproduce
en otro, enviando dichos mensajes a traves de un t
unel externo a la red. Esto hace que una
vctima crea que el nodo atacante sea un nodo vecino pero en realidad se encuentra a varios
tica
111
9.4.2. Prevenci
saltos de distancia. Este ataque genera una alteracion de la topologa de la red y el agresor con
este comportamiento hace que todos los nodos cambien sus tablas de ruteo y lo utilicen a el como
gateway hacia otro extremo de la red.
Este ataque se puede prevenir utilizando un mecanismo estadstico/heurstico [18, Sec. 4.4]
teniendo en cuenta algunas caractersticas del medio de fsico y de las interfaces de red. Teniendo
en cuenta que las placas de red utilizadas hoy en da tienen un radio de cobertura R, por ejemplo
maximo 100mts (este valor parametrizable en el protocolo) y suponiendo que la velocidad de
propagacion de la se
nal wireless c en el aire es cercana a la velocidad de propagacion de la luz en
el vaco, se puede calcular la distancia recorrida por un paquete como L = t c. Entonces si se
detecta que un paquete cumple con L > R, se esta en presencia de un ataque de t
unel y en caso
contrario, no (L <= R).
La implementaci
on de este sencillo algoritmo consiste en el siguiente procedimiento: Durante
el Procedimiento de Autenticaci
on, cuando B recibe el primer mensaje de A (Paso 1), B inicializa
un contador y enva la respuesta a A (Paso 2), cuando A le responde, B detiene el contador y
enva el mensaje a A (Paso 3). B calcula la distancia como S = (4tb /2) c, si S > R, B no
pone a A como vecino conable, en caso contrario y se completa satisfactoriamente el paso 4, B
inserta a A como vecino seguro.
El procedimiento seguido por A es analogo, con la diferencia que A inicializa el contador en
el Paso 1 antes de enviar el primer mensaje hacia B.
9.4.2.
Prevenci
Otro de los ataques analizados en la Seccion 6.6 es el Ataque por Reenvo de Mensajes, el cual
consiste en grabar traco de la red y reproducirlo en otro momento. Este ataque es posible porque
los n
umeros de secuencias, son n
umeros de 16 bits, con lo cual en un corto plazo comienza desde
cero nuevamente. Por esta vulnerabilidad es que no se puede garantizar la frescura (fresshness)
de un paquete.
Como soluci
on a este ataque, los paquetes de OLSR necesitan un nuevo mecanismo para validar su frescura. Para esto se utiliza un timestamp de 32 bits en cada uno de los paquetes. Existen
varias alternativas para la implementaci
on de timestamps. En [30, Sec. V] se proponen distintas
alternativas de implementaci
on. En esta propuesta se utilizara la idea desarrollada en [21], la cual
no depende de la sincronizaci
on de relojes y es un intercambio simple de mensajes.
La propuesta planteada en [21], consiste en un dialogo para intercambiar los relojes de cada
extremo. Para esto utiliza mensajes especiales.
En esta tesis se utilizar
a la idea de [21] pero no se utilizaran mensajes especiales sino que el
intercambio de relojes se llevar
a a cabo durante el proceso de autenticacion donde se agregara a
los mensajes la hora de cada nodo (notar que la modicacion se hizo sobre los mensajes de
autenticaci
on b
asicos y no sobre los detallados en el proceso de intercambio de claves del nivel 1
de securizaci
on). De esta manera, el nodo receptor del mensaje puede calcular la diferencia horaria
y almacenarla en la tabla de vecinos. Para llevar a cabo este intercambio de debe modicar el
mensaje AUTH MESSAGE para agregar un campo para el timestamp.
112
tica
1. A B : A, B, CertA , RA , T imeA , sign(H(A, B, CertA , RA , T imeA ))

2. B A : B, A, CertB , RB , T imeB sign(H(B, A, CertB , RA , RB , T imeA ))
3. A B : A, B, sign(H(A, B, RA , RB , T imeA , T imeB ))
Se toma en cuenta un factor de error S (parametrizable con el protocolo) que determina una
tolerancia para el c
alculo del timestamp. Cada paquete recibido tiene su propio timestamp. El
nodo receptor extrae el timestamp del paquete y calcula la diferencia con su reloj calculando
TN = Tlocal Tpaquete . A continuacion eval
ua T0 S < TN y T0 + S > TN , donde T0 es la
diferencia horaria almacenada en la tabla de vecinos. En caso que la validacion del timestamp
sea correcta se procesa el mensaje, en caso contrario se descarta.
Para compensar alg
un desfasaje de los relojes, se realiza un ajuste de T0 calculando el promedio
entre la diferencia horaria almacenada y la calculada para este paquete (T0 = (T0 + TN )/2).
Con la implementaci
on del timestamp, se modica el mensaje de rma del paquete generado
en el nivel 1 de securizaci
on ya que es necesario que el timestamp pertenezca a este mensaje para
garantizar la frescura del paquete. El nuevo mensaje de rma (Figura 9.13) contiene el timestamp,
el cual es parte de los campos a tener en cuenta en para la rma ya que es necesario que ese
campo no sea alterado.
0
1
2
3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
SCHEMA
|
ALGORITHM
|
Reserved
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
TIMESTAMP
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figura 9.13: Formato del mensaje rma con timestamp
9.4.3.
Prevenci
on contra ataques de DoS
Uno de los ataques m

as comunes son los ataques de Denegacion de Servicio. Estos ataques
pueden ser realizados de distantas maneras, por ejemplo un nodo malicioso o mal congurado
podra enviar docenas de mensajes de autenticacion por segundo haciendo un desgaste de energa
procesando el mensaje en el nodo receptor.
Una manera sencilla de mitigar este tipo de ataque es mantener un contador por cada direcci
on
de origen que enva 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 del
nodo agresor en el lapso de tiempo en el cual en contador todava esta activo rechaza el mensaje.
Esta prevenci
on no tiene efecto si el nodo agresor realiza un spoong de IP. En este caso el
protocolo cuenta con un mecanismo de aceptacion de paquetes de manera estadstica para no
saturar el nodo. Se establecen umbrales que son congurables para el protocolo y en base a esos
umbrales se calcula cuando comienza a atender de manera estadstica.
tica
113
9.4.4. Otros ataques mitigados
9.4.4.
Otros ataques mitigados
Con el solo hecho de la securizaci

on alcanzada en el Nivel 1, se pueden prevenir los ataques
que involucran la modicaci
on de los paquetes como Generacion Incorrecta de Mensajes HELLO,
Generacion Incorrecta de Mensajes TC, ya que ning
un nodo puede hacerse pasar por otro porque
los nodos est
an autenticados. Otros ataques pasivos son mitigados porque nodos que escuchan el
traco no pueden interpretarlo ya que esta encriptado.
9.4.5.
OLSR RFC 3226 vs. OLSR Seguro
Realizando una comparaci

on r
apida entre el protocolo original (RFC 3626) y el fortalecimiento
propuesto, se puede ver que no se modica el funcionamiento pero s se agregan capas de seguridad
y algunas modicaciones mnimas a las Etapa 1 (Censado y Descubrimiento de Vecinos) y la
Etapa 2 (Elecci
on de MPR). En la Figura 9.14 se puede ver de manera esquematica como se ha
empaquetado el protocolo original para hacerlo seguro.
Figura 9.14: Etapas del protocolo OLSR
114
tica
9.5.
Ya a esta altura con los dos niveles de seguridad especicados se tiene un protocolo seguro e
inmune a algunos ataques. El objetivo del tercer nivel es proponer mecanismos de autodefensa
para la red. Para ello se denen dos mecanismos. Uno, el mismo protocolo implementa un mecanismo de denuncia de los nodos que estan intentando un ataque o tienen un comportamiento
incorrecto y el otro es el agregado de un componente externo al protocolo que es un Sistema de
Detecci
on de Intrusos. Los mecanismos descriptos en este nivel es una opcion mas planteada en
esta tesis para hacer la red segura pero no sera analizada en profundidad con lo cual son objeto
de estudio futuro.
9.5.1.
Mecanismo de Denuncia
Una alternativa de autodefensa sera que si un nodo detecta que esta siendo vctima de un
ataque pueda reportar este incidente a una CA. Las CAs que estan conectadas al backbone
de la red mantienen un di
alogo sobre los reportes enviados por los nodos. Las CAs reciben
estos incidentes pero solo toman como validos los que provienen de alg
un nodo con un nivel de
conabilidad alto (umbral parametrizable en el protocolo) y se tomara una accion cuando mas de
un nodo (valor parametrizable) conable realice una denuncia (Voto Calicado). En ese momento
se genera una revocacion del certicado y es anunciado a todas las CAs de la red.
9.5.2.
Sistema de Detecci
on de Intrusos
Un Sistema de Detecci
on de Intrusos es muy utilizado en el ambito de grandes redes, tiene
como objetivo detectar intrusos en base a comportamiento de los clientes de la red. A diferencia del
mecanismo de denuncia, el IDS puede ser congurado para que actualice la base de conocimientos
o el mismo IDS puede aprender, en cambio el mecanismo de denuncia es algo jo que tiene el
protocolo y cualquier cambio que se quiera realizar requiere una modicacion del protocolo y
redistribuci
on del mismo.
9.5.2.1.
Interacci
on con las CAs
El IDS, es un nodo m
as que pertenece a la red y los clientes lo ven como un cliente mas. El
IDS debe correr en un nodo seguro de la red y poseer un certicado especial para comunicarse
con las CAs.
El IDS detecta un comportamiento extra
no de un determinado nodo y enva la noticia a las
CAs que tiene a su alcance. La conexion con las CAs se hace con una conexion SSL de dos vas
(el nodo valida la identidad de la CA y la CA la del nodo mediante los certicados). Una vez que
la CA recibi
o el mensaje actualiza su CRL.
9.5.3.
Sincronizaci
on de CRLs
Las CAs, en una red m

ovil urbana van a ser nodos interconectados a traves del backbone de
la red y van a tener un enlace estable, con lo cual garantiza cierta conabilidad de interconexion.
tica
115
9.6. Debilidades del Esquema de Seguridad propuesto
Las CAs, por ser nodos que pertenecen a la red y la red utiliza un protocolo proactivo conocen
cuales son las CAs de la red con lo cual pueden comunicarse con cada una de ellas. Periodicamente
una CA recorre el las CAs disponibles y establece una conexion SSL de dos vas con otra CA
y le pide su CRL y actualiza la propia agregando las entradas que no tiene. Antes de proceder
con la actualizaci
on de la CRL, verica si la fecha de actualizacion de la CRL descargada de la
CA remota en m
as vieja que la se tiene no se hace nada, en caso contrario se procede con la
actualizacion.
9.6.
Debilidades del Esquema de Seguridad propuesto
El esquema de seguridad propuesto en esta tesis garantiza los servicios basicos que debe
prestar una red de datos segura y es inmune a cierto tipo de ataques pero no es infalible y tiene
debilidades.
El protocolo no previene los ataques a las capas inferiores como por ejemplo ataques de capa
fsica, donde un nodo puede ser vctima de interferencias del nodo agresor (jamming) impidiendo
la comunicaci
on con el resto de sus vecinos, ataques de capa dos (enlace) donde el nodo agresor
puede hacer spoong de MAC address o en capa de red spoong de IP.
Con esta debilidad expuesta, un nodo que fue excluido de la red podra reingresar como un
nodo nuevo cambi
andose su direcci
on IP y su MAC address. En este caso la red lo reconoce como
un nodo nuevo y la conanza que haba ganado dentro de la red con su identidad anterior la
pierde.
9.7.
Resumen
A lo largo de este capitulo se dieron detalles de la implementacion del esquema de seguridad

propuesto para una red m
ovil urbana. Este esquema se divide en dos partes, la primera que
involucra el aspecto organizacional de una red movil urbana y la segunda es la modicacion del
protocolo OLSR para ser inmune a distintos ataques. Este fortalecimiento del protocolo se divide
en tres niveles, los cuales atacan distintos aspectos de seguridad. Nivel 1 introduce algoritmos y
mecanismos criptogr
acos para garantizar autenticacion, condencialidad y no repudio. El Nivel
2 mitiga distintos ataques y por u
ltimo el Nivel 3, el cual es objeto de estudio futuro incorpora
un mecanismo de autodefensa de la red.
116
tica
Captulo 10
Prueba de Contenido
El objetivo de este captulo es describir como se realiz
o la prueba de contenido
para demostrar el funcionamiento de algunas modicaciones introducidas al protocolo
OLSR para mejorar su seguridad dentro de un
ambito urbano .
En el Captulo 9 se dieron los detalles sobre los distintos niveles de securizacion propuestos en
esta tesis para el protocolo OLSR. Para conrmar el correcto funcionamiento de la modicaci
on
al protocolo original, se realiz
o una prueba de contenido donde se implementaron algunas de las
nuevas funcionalidades. A lo largo de este captulo se detallara como fue implementada la prueba
de contenido.
Para realizar la prueba es necesario contar con una red movil funcionando con una cantidad
de nodos determinada y distribudos de manera tal que un nodo deba rutear a traves de otro
para llegar al destino. Este escenario en un ambiente de laboratorio es muy difcil de conseguir
con lo cual se desarroll
o un simulador para poder probar el protocolo.
Las funcionalidades implementadas en el simulador son:
Implementaci
on de la Autoridad Certicante.
Descubrimiento de Autoridades Certicantes.
Solicitud de un certicado por parte del nodo.
Firmado del Requerimiento y emision del certicado valido para la red.
Descubrimiento de Vecinos.
Autenticaci
on 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 utiliza

las capas inferiores para enviar mensajes y en base a ellos modica la tabla de rutas del Sistema
Operativo sobre el cual corre.
La implementaci
on de la prueba de contenido se realizo de la misma manera pero en este caso
no es parte del objetivo de la misma realizar la modicacion de la tabla de rutas del SO base.
Otra de las premisa de la implementaci
on es que no contempla cambios de topologa durante cada
una de las etapas. La prueba asume que el escenario se mantiene estatico y no sufre alteraciones.
El simulador fue codicado en Java, utilizando libreras open source para la manipulacion de
certicados.
La arquitectura b
asica del simulador esta constituida por cuatro modulos (Figura 10.1). El
modulo de procesamiento de mensajes OLSR (MulticastDaemon), el modulo de la Autoridad
Certicante (CAModule), el m
odulo de autenticacion con los vecinos (AuthDaemon) y el nodo
propiamente dicho (Node).
Figura 10.1: Principales m

odulos del simulador
118
tica
Prueba de Contenido
10.1.1.
Certicados y Keystores
Como un nodo debe manejar certicados y la prueba de contenido fue desarrollada en Java,
este lenguaje hace uso de Keystores para almacenar los certicados del programa Java [33].
En particular en esta implementacion se eligio usar dos Keystore independientes, uno con el n
de almacenar la identidad del nodo y el otro para almacenar los certicados de los nodo conados.
As el proceso Java cuando establece una conexion SSL o necesita vericar alg
un certicado que
le fue presentado hace uso de estos repositorios para validarlos.
10.1.2.
Conguraci
on del Nodo
Cada nodo cuenta con un archivo de conguraci

on en el cual se le especica entre otras cosas
cuales son los Keystores del nodo (identidad y conanza), parametros necesarios para hacer uso
de los mismos, direcci
on IP principal del nodo, si el nodo va a actuar como CA o no y el path al
archivo de topologa de la red.
El archivo de topologa de red es un archivo en formato XML en el cual esta el escenario
basico 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 topologa, etc. En particular en esta implementaci
on
ese archivo contiene la estructura de un red vaca, sin ning
un vecino.
10.1.3.
Plugin olsrd para generar el archivo de topologa
Para crear el archivo de topologa se creo un plugin de olsrd el cual imprime en formato XML
toda la informaci
on de las tablas del protocolo. El formato del archivo XML fue dise
nado para
1
ser usado luego con XStream y poder construir el objeto Nodo.
El plugin fue programado en base a las facilidades que da la implementacion de olsrd para
realizar este tipo de extensiones. Esta extension escucha en un socket y cuando se establece una
conexion, imprime el contenido de las tablas en formato XML.
Desde el simulador existe un modulo llamado DataCollector, el cual podra ser utilizado para
actualizar en cualquier momento la topologa de la red del simulador con la topologa real de
la red en la cual est
a participando el nodo. Esta funcionalidad fue desarrollada para generar el
archivo de topologa que usa el simulador para cada nodo, pero no se utiliza para actualizar la
informaci
on del nodo.
10.1.4.
Mensajes
El dise
no de los mensajes se hizo teniendo en cuenta los originales del protocolo y extendiendo
estos con los mensajes modicados para adaptarse a la propuesta de esta tesis. Como se puede
ver en la Figura 10.2, todos los mensajes heredan de una clase llamada GenericMessage, el cual
tiene entre otras cosas un metodo abastracto llamado processMessage(), el cual obliga a cada
mensaje que lo extiende a implementar este metodo que tiene como objetivo que cada mensaje
sepa como procesarse. De esta manera los servidores que reciben alg
un mensaje no tienen que
1 http://xstream.codehaus.org/
tica
119
10.1.5. M
odulo de Autoridad Certicante
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 si
mismo y genera una respuesta.
10.1.5.
M
odulo de Autoridad Certicante
El modulo de Autoridad Certicante, es una clase que se ejecuta en un thread independiente,

establece un socket y se queda esperando por peticiones de certicados. El nodo tiene un archivo
120
tica
Prueba de Contenido
de conguraci
on donde uno de las propiedades a congurar es si el nodo va a actuar como CA
o no. En caso que as sea, se especica cual el es Keystore donde se encuentra su certicado
expedido por la Root CA de la comunidad.
Este m
odulo no solo tiene la responsabilidad de lanzar el servidor, sino que cuenta con todos
los metodos necesarios para manipular los certicados.
10.1.6.
M
odulo de Autenticaci
on con los vecinos
Una vez que el nodo tiene un certicado valido para participar en la red, necesita autenticarse
con los vecinos para hacer uso de la misma. Para ello el nodo cuenta con este modulo que lanza
un servidor el cual queda a la espera de mensajes de autenticacion. Este modulo utiliza los dos
Keystores congurados para el nodo. El de identidad lo utiliza para enviar su propio certicado
en el mensaje AUTH MESSAGE y utiliza el de conanza para almacenar los certicados de los vecinos
conados.
Para simplicar la implementacion del proceso de autenticacion de los vecinos, se implemento las primeras dos fases 9.3.3.1 como un handshaking de SSL en el cual se realiza una
autenticaci
on de SSL de dos vas. La autenticacion SSL de dos vas [34, Cap. 10] consiste en que
el server cuando recibe una petici
on de conexion, obliga al cliente a presentar su certicado y
a la vez el servidor le enva su certicado al cliente. De esta manera en ambos lados se eval
ua
la cadena de certicaci
on de los mismos y la validez. Una vez que ambos nodos se autenticaron
envan el mensaje AUTH MESSAGE FINISH y los nodos confan entre si. Este modulo utiliza los
metodos del M
odulo de CA para validar la cadena de certicacion.
10.1.7.
M
odulo 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 que
llega ejecuta el metodo processMessage() de cada uno de ellos para que se auto-procesen y luego
poder enviar el mensaje de respuesta.
10.2.
Implementaci
on
A lo largo de esta secci

on se van a presentar algunos detalles de implementacion del simulador
para dar una idea al lector sobre como fue desarrollado sin entrar en detalles propios de la
programaci
on.
10.2.1.
Descubrimiento de CAs y Vecinos
El nodo que quiere ingresar a la red realiza como primera accion un descubrimiento de las
Autoridades Certicantes de la red para realizar posteriormente el pedido del certicado. El
procedimiento de descubrimiento se realiza enviando un mensaje de tipo CA DISCOVER por medio
una trama de multicast. Para hacer esto se instancia un mensaje de tipo CADiscoverMsg, se
agrega el mensaje a un paquete OLSR y luego es enviado a la red.
tica
121
10.2.2. Autoridad Certicante
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 enva la respuesta pero
con direccion de destino la del nodo solicitante, as cualquier nodo que reciba la respuesta y no
es para el, la descarta.
El nodo que intenta ingresar a la red recibe la respuesta del nodo vecino y agrega a este como
vecino e inserta en la tabla de topologa las CAs informadas por el vecino.
De esta manera el proceso de descubrimiento tiene doble proposito, descubrir los vecinos y
las CAs de la red.
Todos los nodos tienen el demonio de procesamiento de mensajes OLSR escuchando en la
misma IP y puerto de multicast. Para la implementacion del simulador el demonio escucha en la
direccion 228.0.0.23:4444
10.2.1.1.
Demonio de Procesamiento de mensajes OLSR
La implementaci
on del demonio de procesamiento de mensajes de OLSR es muy sencilla. La
clase MulticastDaemon tiene un metodo para inyectar paquetes OLSR en la red y lanza un thread
con la clase MCastReader que recibe los mensajes multicast de los vecinos. Cada vez que recibe
uno, invoca el metodo processMessage() del mensaje recibido, el cual sabe que es lo que tiene que
hacer.
Figura 10.3: Diagrama de Secuencia para la rma de un CertReq
10.2.2.
Autoridad Certicante
La Autoridad Certicante fue implementada dentro del modulo CAModule. Cuando se instancia esta clase, se inicia un thread que lanza la clase CAServer, la cual establece un socket que
122
tica
Prueba de Contenido
espera peticiones SSL en el puerto 4443.

La Autoridad Certicante solo es iniciada si en el archivo de conguracion del nodo
(config.properties), se especic
o la propiedad enableCA=true.
Como se dijo anteriormente, la clase CAModule, no solo laza la clase CAServer, sino que tiene
metodos est
aticos para realizar la gestion de certicados.
Cuando el servidor recibe una conexion de un nodo, invoca el metodo precessMessage()(Figura 10.3) el cual valida que el mensaje sea tipo CERT REQ y luego rma el requerimiento
invocando el metodo de clase signCertReq() de la clase CAModule. Finalmente con el certicado
rmado, genera un mensaje de respuesta (CERT REPLY) y se lo enva al nodo.
Figura 10.4: Diagrama de Secuencia de la obtenci

on de un certicado
10.2.2.1.
Interacci
on Nodo-CA
El servidor de la CA crea un socket de tipo SSLServerSocket en cual utiliza el keystore de

identidad para enviar su certicado al cliente que establece la conexion. En este punto, el nodo
cliente, valida la cadena de certicacion del certicado presentado por la CA. El nodo puede
realizar esta tarea ya que en el keystore de conanza tiene el certicado de la Root CA de la
comunidad. Una vez validada la identidad de la CA, se enva el mensaje CERT REQ. El nodo
cliente utiliza la clase Tools que tiene el metodo makeSSLConnection() que realiza la conexion
SSL y valida la cadena de certicacion del servidor.
La CA enva el mensaje CERT REPLY con el certicado rmado para poder participar de la red.
El nodo cliente valida el certicado recibido, lo almacena e inicia el demonio de Autenticacion
con los Vecinos. En la Figura 10.4 se puede ver el diagrama de secuencia simplicado para la
obtencion de un certicado.
10.2.3.
Autenticaci
on con los Vecinos
Una vez que el nodo que quiere ingresar a la red obtiene un certicado valido, inicializa el
demonio de Autenticaci
on con los vecinos. El demonio de autenticacion inicia un servidor con un
socket SSL (puerto 4444), pero en este caso a diferencia del modulo de CA, se instancia para que
tica
123
10.3. Modos de Operaci

on del Simulador
solicite al cliente que presente su certicado y as validar que este tiene un certicado expedido
por una CA v
alida (Autenticaci
on SSL de dos vas). Esta autenticacion se realizo para simplicar
la implementaci
on 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 es
conable y almacena el certicado en el keystore de conanza.
Para realizar la autenticaci
on SSL de dos vas, se utilizan los dos keystores, uno para enviar
su identidad y el otro para validar la cadena de certicacion del certicado del vecino.
10.3.
Modos de Operaci
on del Simulador
(a) M
odulos instanciados por el nodo en modo
CA
(b) M
odulos instanciados por el nodo en modo
cliente
Figura 10.5: Instanciaci

on de m
odulos dependiendo el modo de operaci
on
Como se dijo en varias oportunidades, el simulador puede operar como CA o como nodo
cliente de la red.
En caso que el nodo sea ejecutado como CA, se inicializan los siguientes modulos (Figura 10.5(a)):
Modulo de CA (CAModule), el cual contiene el sservidor que atiende las peticiones de los
clientes (CAServer).
Modulo de procesamiento de mensajes multicast (MulticastDaemon), el cual contiene el
servidor de mensajes multicast que recibe la informacion y peticiones de los nodos vecinos.
124
tica
Prueba de Contenido
Modulo de Autenticaci
on con los vecinos (AuthDaemon).
En caso que el nodo sea ejecutado como cliente, se inicializan los siguientes modulos (Figura 10.5(b)):
Modulo de procesamiento de mensajes multicast (MulticastDaemon).
Modulo de Autenticaci
on con los vecinos (AuthDaemon).
10.4.
Resumen
A lo largo de este captulo de dieron detalle de las mejoras propuestas en la tesis para el
protocolo OLSR implementadas en la prueba de contenido. Para fundamentar la propuesta de
esta tesis, se realiz
o un simulador que implementa algunas de las mejoras. Con este simulador
se muestra que la propuesta funciona, pero la misma no tiene como objetivo realizar un juicio
sobre la performance del nuevo protocolo ya que por la naturaleza misma de la implementacion
en Java dista de la real desarrollada en C.
tica
125
10.4. Resumen
126
tica
Captulo 11
Conclusiones
En este trabajo de tesis se presento un Esquema de Seguridad para una Red Movil Urbana.
Para la elaboraci
on de esquema se pasaron por distintas instancias, las cuales son presentadas
durante el desarrollo de este trabajo.
El primer paso dado fue profundizar sobre los diferentes protocolos de ruteo existentes o en
estudio disponibles. Esto fue necesario para enriquecer lenguaje tecnico y diferentes alternativas
para realizar un mismo objetivo, rutear paquetes sobre una Red Movil. Superada esta etapa y
viendo que los protocolos de ruteo de redes moviles en su mayora no contemplaban cuestiones
relacionadas con la seguridad es que se vio la necesidad de investigar como solucionar estos
aspectos ya que en un medio hostil como lo es el aire un protocolo puede estar en riesgo si no se
tiene en cuenta los posibles ataques. Para saber que requisitos debe cumplir una Red Movil hubo
que remontarse a conceptos b
asicos de seguridad para saber cuales son los servicios basicos que
debe brindar una red segura. Con los concepto de seguridad basicos dentro de las herramientas
disponibles para allanar el camino hacia el objetivo de la tesis, se extendieron esos conceptos a
Redes M
oviles donde se vio que hay que agregar variables como que los nodos son a bateras, se
mueven, y no tienen grandes capacidades de procesamiento.
Ya a esta altura se cuenta con los conocimiento de Redes Moviles, con los requisitos basicos
que debe cumplir un protocolo para ser considerado seguro. El siguiente paso fue estudiar que
protocolos seguros haba disponibles y ver de que manera cumplan con los requisitos.
Un aspecto clave para alcanzar el objetivo es estudiar como son, como se comportan y como
se organizan las redes Urbanas, donde se encontro que en su mayora estan administradas por
comunidad sin nes de lucro. Fue fundamental conocer como es en particular la administracion y
organizaci
on de una Red M
ovil Urbana como lo es Buenos Aires Libre para saber que el protocolo
mas difundido entre las Redes M
oviles Urbanas es el OLSR.
El siguiente paso fue profundizar sobre el funcionamiento de este protocolo y analizar cuales
seran los posibles ataques que podra sufrir.
Con el conocimiento tecnico del funcionamiento y vulnerabilidades del protocolo OLSR m
as
los aspectos organizativos de una Red Movil Urbana ya se contaba con los elementos sucientes
para enfrentarse a la u
ltima parte hacia el objetivo nal.
127
Luego de la lectura de varios artculos con propuestas de securizacion para OLSR, tomando
ideas de cada uno de ellos y poniendolas dentro del marco de una Red Movil Urbana es que
desarrollo la propuesta de securizaci
on del protocolo OLSR.
Dentro de los artculos ledos, ninguno de ellos daba una solucion completa como la propuesta
en esta tesis. La propuesta incluye:
La distribuci
on de claves por medio de certicados digitales.
Se especic
o una poltica organizacional para distribuir entidades certicadoras
Elaboraci
on de un esquema de conanza de un nodo y la participacion del mismo en la red.
Se especic
o un mecanismo de reconocimiento y autenticacion con los vecinos.
Se especic
o un mecanismo de intercambio de claves
Se utiliz
o una forma para rmar mensajes de control
Se utiliz
o un algoritmo de encriptacion simetrico combinado con la clave compartida para
la encripci
on de los mensajes de control
Prevenci
on de Ataques
Alta disponibilidad de CAs
El esquema propuesto presenta distintos niveles de seguridad, los cuales pueden ser implementados en distintas etapas y podran conformar modulos agregados a la implementacion actual
del protocolo OLSR.
La propuesta muestra como se pueden prevenir ataques tpicos al protocolo OLSR. Se incorporaron mecanismos como por ejemplo un algoritmo simple de timestanping, una heurstica
sencilla para detectar si un nodo est
a intentando hacer un ataque de t
unel, un esquema de rmas
para garantizar la integridad de los mensajes y un mecanismo de encripcion para garantizar la
condencialidad de los paquetes de OLSR.
La soluci
on puede ser escalable para incorporar mecanismos de autodefensa como el uso de
un IDS.
Se construy
o una soluci
on que cumple con la premisas basicas para que una Red Movil sea
considerada segura. Se mejoraron aspectos existentes en algunas soluciones y se agregaron nuevas
soluciones.
Finalmente para asegurar el funcionamiento de la propuesta, se implemento un simulador
para realizar la prueba de contenido donde se muestra el funcionamiento del protocolo durante la
incorporacion de un nodo a la red. Esta prueba incluye el descubrimiento de las CAs, la obtencion
de un certicado para participar en la red y la autenticacion con los vecinos
128
tica
Bibliografa
[1] Stefano Basagni, Marco Conti, Silvia Giordano, Ivan Stojmenovic.Mobile Ad-Hoc Networking, IEEE Press, 2004.
[2] Mehran Abolhasan, Tadeusz Wysocki, Eryk Dutkiewcz. A review of routing protocols for ad
hoc networks, Elsevier, 2004.
[3] Charles E. Perkins, Pravin Bhagwat. Highly Dynamic Desditation-Sequenced Distance-Vector
Routing (DSDV) for Mobile Computers, SIGCOMM 94, pp 234-244, 1994.
[4] D. Bertsekas, R. Gallager. Data Networks, Prentice-Hall, pp 297-333, 1987.
[5] T. Clausen, P. Jacquet. Optimized Link State Routing Protocol (OLSR), RFC 3626, 2003.
[6] P. Jacquet, P. M
uhlethaler, T. Clausen, A. Laouiti, A. Qayyum, L. Viennot Optimized Link
State Routing Protocol for Ad Hoc Networks, IEEE, 2001
[7] Charles Perkins, E. Belding-Royer, S. Das. Ad hoc On-demand Distance Vector (AODV)
Routing, RFC 3561, 2003
[8] Charles Perkins, E. Royer. Ad hoc On-demand Distance Vector Routing, Proc IEEE WMCSA, 1999.
[9] R. Ogier, F. Templin, M. Lewis. Topology Dissemination Based on Reverse-Path Forwarding
(TBRPF). RFC 3684, 2004
[10] D. Johnson, D. Maltz. The Dynamic Source Routing Protocol (DSR) for Mobile Ad Hoc
Networks for IPv4, RFC, 2007
[11] David B. Johnson, David A. Maltz, Josh Broch. DSR: The Dynamic Source Routing Protocol
for Multi-Hop Wireless Ad Hoc Networks, 2004
[12] Marc R. Pearlman, Zygmunt J. Haas. Determining the Optimal Conguration for the Zone
Routing Protocol, IEEE, 1999
[13] Zygmunt J. Haas, Marc R. Pearlman, Prince Samar.The Zone Routing Protocol (ZRP) for
Ad Hoc Networks, RFC DRAFT, 1999
129
BIBLIOGRAF
IA
[14] Sung-Ju Lee, Mario Gerla.Split Multipath Routing with Maximally Disjoint Paths in Ad hoc
Networks
[15] Lidong Zhou, Zygmunt J Hass. Securing Ad Hoc Networks, IEEE Network Magazine, pp
24-30, 1999
[16] Po-Wah Yau, Chris Mitchel. Security Vulnerabilities in Ad Hoc Networks
[17] D. Dhillon, T. S. Randhawa, M. Wang L. Lamont. Implementing a Fully Distributed Certicate Authority in an OLSR MANET, IEEE Communication Society, WCNC 2004 pp
682-688
[18] Fan Hong, Liang Hong, Cai Fu. Secure OLSR, IEEE AINA 2005.
[19] Jean-Marie Orset, Ana Cavalli. A Security model for OLSR MANET Protocol. IEEE MDM
2006.
[20] Cedric Adjih, Daniele Rao, Paul M
uhlether. Attack Against OLSR: Distributed Key Management for Security. INRIA, Domaine de Voluceau.
[21] Adread Hafslund, Adreas Tonnesen, Roar Bjorgum Rotvik, Jon Andersson, Oivind Kure.
Secure Extension to the OLSR protocol. OLSR Interon and Workshop, 2004.
[22] IEEE Comitee. IEEE Standard Specications for Public-Key Cryptography. IEEE-SA Standandards Boards, 2004.
[23] P. Papadimitratos and Z. J. Haas. Secure Routing for Mobile Ad Hoc Networks. In Proceedings of CNDS, 2002.
[24] Krawczyk, H., Bellare, M., and R. Canetti, HMAC: Keyed-Hashing for Message Authentication. RFC 2104, February 1997.
[25] A. Perrig, D. Song, R. Canetti, J. D. Tygar, B. Briscoe. Timed Ecient Stream Loss-Tolerant
Authentication (TESLA). RFC 4082, Junio 2005.
[26] Haiyun Luo, Songwu Lu. Ubiquitous and Robust Authentication Service for Ad Hoc Wireless
Networks, Octubre 2000.
[27] M. Myers, C. Adams, D. Solo, D. Kemp. Internet X.509 Certicate Request Message Format.
RFC 2511 ,1999.
[28] T. Dierks, C. Allen. The TLS Protocol. RFC 2246, 1999.
[29] R. Housley, W. Ford, W. Polk, D. Solo. Internet X.509 Public Key Infrastructure Certicate
and CRL Prole, RFC 2459, 1999.
[30] Cedric Adjih, Thomas Clausen, Philippe Jacquet, Anis Laouiti, Paul M
uhlethaler, Daniele
Rao. Securing the OLSR protocol. INRIA Rocquencourt, Project Hipercom.
130
tica
BIBLIOGRAF
IA
[31] William Stallings. Cryptography and Network Security. 4ta Edicion, 2006.
[32] Douglas R. Stinson. Cryptography : Theory and Practice, 3era Edicion, 2002.
[33] Scott Oaks. Java Security. OReilly, 2da Edicion, 2001
[34] David Hook. Beginning Cryptography in Java, John Wiley & Sons, 2005.
[35] Ocina Nacional de Tecnologa de la Informacion Rep
ublica Argentina (ONTI). Modelo
de Poltica de Seguridad de la Informaci
on para Organismos de la Administraci
on P
ublica
Nacional, Versi
on 1, Julio 2005
tica
131

Caracoche Tesisdegradoingenieriainformatica

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Caracoche Tesisdegradoingenieriainformatica

Uploaded by

Copyright:

Available Formats

Redes M

Millones de personas vieron caer la manzana,

Juan Manuel Caracoche

Acerca del Autor

Acerca del Autor

9.3.7. Logros del Nivel 1 de securizacion . . . . . . . . . . . . . . .

3.1. Proceso de Generaci

7.1. Componentes participantes en el esquema de seguridad propuesto . . . . . . . . . 81

9.1. Formato del mensaje CADISCOVER . . . . . .

2.2. Protocolos de Ruteo

Figura 2.1: Clasicaci

Protocolos de Ruteo Proactivos, Reactivos e Hbridos

Los protocolos de ruteo para Redes M

Protocolos de Ruteo Proactivos

2.3.1. Protocolos de Ruteo Proactivos

Destination-Sequenced Distance-Vector (DSDV)

El protocolo de ruteo de Destination-Sequenced Distance-Vector (DSDV) es un protocolo

Optimized Link State Routing (OLSR)

Figura 2.2: Multipoint Relays

2.3.2. Protocolos de Ruteo Reactivos

Protocolos de Ruteo Reactivos

Ad hoc on-demand distance vector (AODV)

2.3.2. Protocolos de Ruteo Reactivos

2.3.2. Protocolos de Ruteo Reactivos

(a) El origen 1 quiere enviar datos a 10

(b) El nodo 1 enva un mensaje RREQ a sus

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

(f) Se llega al nodo 10 y

(g) 10 determina la ruta para enviar RREP

(h) En cada salto que hace RREP, se establece

Figura 2.3: Ejemplo de la construcci

Dynamic Source Routing (DSR)

2.3.2. Protocolos de Ruteo Reactivos

Figura 2.4: Detecci

(a) El origen 1 quiere enviar datos a 10

(b) El nodo 1 enva un mensaje RREQ a sus

(f) Llega el segundo RREQ al nodo 10, arma

(g) 1 recibe los RREP y elije enviar los datos

Figura 2.5: Ejemplo de la construcci

2.3.3. Protocolos de Ruteo Hbridos

Mantenimiento de la Ruta Cuando un nodo transmite o reenva un mensaje, este debe

Protocolos de Ruteo Hbridos

Las caractersticas de los protocolos de ruteo reactivos y proactivos pueden combinarse de

Zone Routing Protocol (ZRP)

Figura 2.6: Zona de un nodo usando ZRP

Figura 2.7: Descubrimiento de una ruta con IERP

primero construye su propio

Es preciso introducir conceptos basicos de criptografa con el n de que el lector se familiarice

3.1.1. Cifrados Sim

3DES El algoritmo 3DES consta de tres rondas de DES. Incrementa el tama

3.1.3. Resumen Criptogr

Existen varios algoritmos que utilizan el esquema de clave p

La rma digital es una manera de garantizar la autora y la integridad de un documento

Figura 3.1: Proceso de Generaci

Resumiendo la rma digital garantiza integridad y no repudio.

Una infraestructura de clave p

La seguridad de la tecnologa PKI se centra en la privacidad de la clave privada (ya que

Usos de la tecnologa PKI

La tecnologa PKI, es utilizada para realizar autenticacion de personas, servidores, sistemas,

Consideraciones sobre PKI

En este captulo se hizo una revisi

Los ataques en una red m

Nodo Fallido Maligno