Redes Móviles Seguras en un´Ambito Urbano

Redes Móviles Seguras
en un Ámbito Urbano
Utilizando Protocolo OLSR
Tesis de Grado en Ingenierı́a Informática
Orientación en Sistemas Distribuı́dos
Juan M. Caracoche
[email protected]
Director:
Hugo Pagola
Facultad de Ingenierı́a
Universidad de Buenos Aires
“Millones de personas vieron caer la manzana,
pero Newton fue el único que se preguntó porque.”
Bernard Baruch
Resumen
Las redes móviles (Mobile Ad-hoc NETworks -MANET-) son un tipo especial de redes en
la cual un conjunto de dispositivos móviles conforman de manera temporal una red de forma
autónoma sin la necesidad de una infraestructura. Para estos ambientes existen distintos protocolos para el ruteo de paquetes donde los integrantes de la misma están 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
Móviles Urbanas son un subgrupo de las redes móviles donde se encuentran nodos diseminados
por toda una ciudad, la geografı́a de una ciudad y las limitaciones del medio de trasmisión de la
tecnologı́a 802.11 hacen que se deba armar una topologı́a 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ña un
esquema de seguridad para hacerla lo más inmune posible a ataques externos.
Juan Manuel Caracoche - Tesis de grado Ingenierı́a Informática
I
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 differents 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
city’s 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 different 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
Juan Manuel Caracoche - Tesis de grado Ingenierı́a Informá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 sacrificios entendieron que
la educación de un hijo es más que una inversión.
A mi novia que tuvo la paciencia de acompañarme en el duro camino de mis últimos años de
la carrera.
Por supuesto no podı́a olvidarme del apoyo incondicional de mis amigos y compañeros, que
me dieron durante los años de facultad, los mejores años de mi vida.
Juan Manuel Caracoche
Agosto 2008
Juan Manuel Caracoche - Tesis de grado Ingenierı́a Informática
III
Acerca del Autor
Juan Manuel Caracoche nació en la ciudad de Pellegrini, provincia de Buenos Aires el 16
de Febrero de 1980. Realizó sus estudios primarios en la escuela Guillermo de Soldato y los
secundarios en el Instituto José Manuel Estrada, ambos establecimientos de su ciudad natal. En
el año 1998 se traslada a la ciudad de Buenos Aires para comenzar sus estudios universitarios en la
Facultad de Ingenierı́a de la Universidad de Buenos Aires, actualmente es estudiante de la carrera
Ingenierı́a Informática. Adicionalmente es docente auxiliar del Departamento de Electrónica de
la misma Universidad.
IV
Juan Manuel Caracoche - Tesis de grado Ingenierı́a Informática
Índice general
Resumen
I
Abstract
II
Agradecimientos
III
Acerca del Autor
IV
1. Introducción
11
1.1. Motivación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.2. Objetivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2. Redes Móviles
2.1. Generalidades . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2. Protocolos de Ruteo . . . . . . . . . . . . . . . . . . . . . . . . .
2.3. Protocolos de Ruteo Proactivos, Reactivos e Hı́bridos . . . . . . .
2.3.1. Protocolos de Ruteo Proactivos . . . . . . . . . . . . . . .
2.3.1.1. Destination-Sequenced Distance-Vector (DSDV)
2.3.1.2. Optimized Link State Routing (OLSR) . . . . .
2.3.2. Protocolos de Ruteo Reactivos . . . . . . . . . . . . . . .
2.3.2.1. Ad hoc on-demand distance vector (AODV) . .
2.3.2.2. Dynamic Source Routing (DSR) . . . . . . . . .
2.3.3. Protocolos de Ruteo Hı́bridos . . . . . . . . . . . . . . . .
2.3.3.1. Zone Routing Protocol (ZRP) . . . . . . . . . .
2.3.4. Técnicas 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ática
3.1. Conceptos Básicos de Criptografı́a . . .
3.1.1. Cifrados Simétricos . . . . . . . .
3.1.1.1. Seguridad . . . . . . . .
3.1.1.2. Ventajas y Desventajas
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
31
31
32
32
32
1
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
ÍNDICE GENERAL
3.1.1.3. Algoritmos . . . . . . . . .
3.1.2. Cifrados Asimétricos . . . . . . . . .
3.1.2.1. Seguridad . . . . . . . . . .
3.1.2.2. Ventajas y Desventajas . .
3.1.2.3. Algoritmos . . . . . . . . .
3.1.3. Resumen Criptográfico . . . . . . . .
3.1.3.1. Hash . . . . . . . . . . . .
3.1.3.2. MAC . . . . . . . . . . . .
3.1.4. Firma Digital . . . . . . . . . . . . .
3.1.5. PKI . . . . . . . . . . . . . . . . . .
3.1.5.1. Propósito y funcionalidad .
3.1.5.2. Usos de la tecnologı́a PKI .
3.1.5.3. Certificados . . . . . . . . .
3.1.6. Componentes . . . . . . . . . . . . .
3.1.6.1. Consideraciones sobre PKI
3.2. Resumen . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
4. Seguridad en Redes Móviles
4.1. Ataques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.1.1. Ataques Externos . . . . . . . . . . . . . . . . . . . . . .
4.1.1.1. Interceptación 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 egoı́sta . . . . . . . . . . . . . . . . . . .
4.1.2.4. Nodo Malicioso . . . . . . . . . . . . . . . . . .
4.2. Protocolos de Ruteo Seguros . . . . . . . . . . . . . . . . . . .
4.2.1. SRP - Secure Routing Protocol . . . . . . . . . . . . . .
4.2.1.1. Descubrimiento de la Ruta . . . . . . . . . . .
4.2.1.2. Otras Vulnerabilidades . . . . . . . . . . . . .
4.2.1.3. Ideas Rescatadas para el Desarrollo de la Tesis
4.2.2. ARIADNE . . . . . . . . . . . . . . . . . . . . . . . . .
4.2.2.1. Ideas Rescatadas para el Desarrollo de la Tesis
4.2.3. Resumen . . . . . . . . . . . . . . . . . . . . . . . . . .
5. Redes Móviles Urbanas
5.1. Proyectos Comunitarios Libres
5.1.1. Buenos Aires Libre . . .
5.2. Topologı́a . . . . . . . . . . . .
5.2.1. Direccionamiento IP . .
5.3. Protocolos de Ruteos . . . . . .
2
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. .
.
. .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
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
Juan Manuel Caracoche - Tesis de grado Ingenierı́a Informática
ÍNDICE GENERAL
5.4. Servicios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
5.5. Administración de la Red BAL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
5.6. Resumen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
6. Protocolo OLSR
6.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.2. Terminologı́a Propia de OLSR . . . . . . . . . . . . . . . . . . .
6.3. Tablas del Protocolo . . . . . . . . . . . . . . . . . . . . . . . .
6.4. ¿Cómo 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ón de los MPRs . . . . . . . . . . . . . .
6.4.4. Etapa 3: Mantenimiento de la Topologı́a . . . . . . . . .
6.4.4.1. Mensaje TC . . . . . . . . . . . . . . . . . . .
6.4.4.2. Mecanismo de propagación de los mensajes TC
6.4.5. Etapa 4: Formación de las Rutas . . . . . . . . . . . . .
6.4.6. Etapa 5: Mantenimiento de las Rutas . . . . . . . . . .
6.4.7. Comunicación con Otras Redes . . . . . . . . . . . . . .
6.4.7.1. Mensaje HNA . . . . . . . . . . . . . . . . . .
6.4.7.2. Asociación de la redes . . . . . . . . . . . . . .
6.5. Seguridad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.5.1. Confidencialidad . . . . . . . . . . . . . . . . . . . . . .
6.5.2. Integridad . . . . . . . . . . . . . . . . . . . . . . . . . .
6.5.3. Mensajes a Proteger . . . . . . . . . . . . . . . . . . . .
6.6. Vulnerabilidades . . . . . . . . . . . . . . . . . . . . . . . . . .
6.7. Resumen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
7. Diseño de un Esquema de Seguridad para una Red Móvil OLSR Urbana
7.1. Esquema de Seguridad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.2. Fundamentos del Diseño . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.2.1. OLSR más Fuerte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.3. Esquema de Clave Pública y Privada . . . . . . . . . . . . . . . . . . . . . . . .
7.3.1. Autoridad Certificante . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.3.2. Esquema de Certificación . . . . . . . . . . . . . . . . . . . . . . . . . .
7.4. Fortalecimiento de OLSR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.4.1. Prevención de Ataques . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.5. Integración del IDS y la CA . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.6. Interacción de los Nodos Clientes con Esquema de Seguridad Planteado . . . .
7.6.1. Esquema de confianza ganada . . . . . . . . . . . . . . . . . . . . . . . .
Juan Manuel Caracoche - Tesis de grado Ingenierı́a Informá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
ÍNDICE GENERAL
7.7. Resumen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
8. Artı́culos más 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ón segura de vecino . . . . . . . . . . . . . . . . . . . .
8.2.3. Autenticación 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ón del Esquema de Seguridad Propuesto
9.1. Esquema de Certificación . . . . . . . . . . . . . . . . . . . . . . . . .
9.1.0.3. Procedimiento para la registración 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ón del Certificado . . . . . . . . . . . . . . . . . . . . .
9.3.2.1. Generación del mensaje CADISCOVER . . . . . . . . . .
9.3.2.2. Procesamiento del mensaje CADISCOVER . . . . . . .
9.3.2.3. Generación del CERTREQ . . . . . . . . . . . . . . .
9.3.2.4. Generación del Certificado . . . . . . . . . . . . . . .
9.3.2.5. Renovación de certificado . . . . . . . . . . . . . . . .
9.3.3. Detección de Vecinos . . . . . . . . . . . . . . . . . . . . . . . .
9.3.3.1. Autenticación de los vecinos . . . . . . . . . . . . . .
9.3.3.2. Elección de MPR . . . . . . . . . . . . . . . . . . . .
9.3.4. Firma y encripción de los mensajes . . . . . . . . . . . . . . . .
9.3.4.1. Obtención de la Clave de Sesión . . . . . . . . . . . .
9.3.4.2. Firma de los mensajes . . . . . . . . . . . . . . . . . .
9.3.4.3. Protocolo de encriptación . . . . . . . . . . . . . . . .
9.3.5. Descubrimiento de la Topologı́a . . . . . . . . . . . . . . . . . .
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
4
87
88
88
88
88
89
89
89
90
91
92
92
92
93
93
94
94
95
Juan Manuel Caracoche - Tesis de grado Ingenierı́a Informática
ÍNDICE GENERAL
9.3.7. Logros del Nivel 1 de securización . . . . . . . . . . . . . . .
9.4. Fortalecimiento de OLSR: Nivel 2 . . . . . . . . . . . . . . . . . . . .
9.4.1. Prevención contra ataque Wormhole . . . . . . . . . . . . . .
9.4.2. Prevención contra ataque de reenvı́o de mensajes: Timestamp
9.4.3. Prevención 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ón de Intrusos . . . . . . . . . . . . . . . .
9.5.2.1. Interacción con las CAs . . . . . . . . . . . . . . . .
9.5.3. Sincronización de CRLs . . . . . . . . . . . . . . . . . . . . .
9.6. Debilidades del Esquema de Seguridad propuesto . . . . . . . . . . .
9.7. Resumen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10.Prueba de Contenido
10.1. Arquitectura . . . . . . . . . . . . . . . . . . . . . . . .
10.1.1. Certificados y Keystores . . . . . . . . . . . . . .
10.1.2. Configuración del Nodo . . . . . . . . . . . . . .
10.1.3. Plugin olsrd para generar el archivo de topologı́a
10.1.4. Mensajes . . . . . . . . . . . . . . . . . . . . . .
10.1.5. Módulo de Autoridad Certificante . . . . . . . .
10.1.6. Módulo de Autenticación con los vecinos . . . . .
10.1.7. Módulo de Procesamiento de mensajes OLSR . .
10.2. Implementación . . . . . . . . . . . . . . . . . . . . . . .
10.2.1. Descubrimiento de CAs y Vecinos . . . . . . . .
10.2.1.1. Demonio de Procesamiento de mensajes
10.2.2. Autoridad Certificante . . . . . . . . . . . . . . .
10.2.2.1. Interacción Nodo-CA . . . . . . . . . .
10.2.3. Autenticación con los Vecinos . . . . . . . . . . .
10.3. Modos de Operación del Simulador . . . . . . . . . . . .
10.4. Resumen . . . . . . . . . . . . . . . . . . . . . . . . . . .
11.Conclusiones
Juan Manuel Caracoche - Tesis de grado Ingenierı́a Informá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
5
ÍNDICE GENERAL
6
Juan Manuel Caracoche - Tesis de grado Ingenierı́a Informática
Índice de figuras
2.1.
2.2.
2.3.
2.4.
2.5.
2.6.
2.7.
Clasificación de protocolos de ruteo . . . . . . . . .
Multipoint Relays . . . . . . . . . . . . . . . . . .
Ejemplo de la construcción de una ruta en AODV
Detección de un enlace roto y envı́o del RERR . .
Ejemplo de la construcción 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ón y Verificación de una Firma Digital . . . . . . . . . . . . . 36
4.1. Formato del encabezado de un protocolo de ruteo con la extensión de SRP . . . . . 47
4.2. Encabezado de SRP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.3. Encabezado SRP con extensión INRT . . . . . . . . . . . . . . . . . . . . . . . . . 48
5.1. Diagrama de una red Móvil Urbana . . . . . . . . . . . . . . . . . . . . . . . . . . 54
6.1. Etapas del protocolo OLSR . . . . . . . . . . . . . . . . . . . . .
6.2. Formato del paquete de OLSR . . . . . . . . . . . . . . . . . . .
6.3. Campo de 8 bits para indicar el código 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ón de MPRs que cubren nodos aislados del Nivel2.
6.10. Fase 2: Se completa la selección de MPRs. . . . . . . . . . . . . .
6.11. Formato del mensaje TC . . . . . . . . . . . . . . . . . . . . . . .
6.12. Formato del mensaje HNA . . . . . . . . . . . . . . . . . . . . . .
6.13. Generación incorrecta de mensajes HELLO . . . . . . . . . . . .
6.14. Generación incorrecta de mensajes TC . . . . . . . . . . . . . . .
6.15. Ataque por túnel (Wormhole) . . . . . . . . . . . . . . . . . . . .
6.16. Ataque al (MPR-Flooding) . . . . . . . . . . . . . . . . . . . . .
7
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
61
62
62
63
64
65
66
67
68
68
69
72
74
75
76
76
ÍNDICE DE FIGURAS
7.1. Componentes participantes en el esquema de seguridad propuesto . . . . . . . . . 81
7.2. Esquema de Certificación. CA de la comunidad expide certificados a los nodos
enrolados y estos expiden certificados a los clientes . . . . . . . . . . . . . . . . . . 82
7.3. Ejemplo de utilización de una red Móvil Urbana Segura interconectando distintas
plazas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
8.1.
8.2.
8.3.
8.4.
Mensaje de firma básico . . . . .
Pasos para lograr una relación de
Extensión del paquete OLSR . .
Formato del mensaje de firma . .
. . . . . . . .
confianza con
. . . . . . . .
. . . . . . . .
. . . . . .
un vecino
. . . . . .
. . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 100
. 101
. 101
. 103
. 104
. 105
. 107
. 107
. 108
. 109
. 110
. 111
. 113
. 114
10.1. Principales módulos del simulador . . . . . . . . . . . . . . .
10.2. Diagrama de Clases para los mensajes del protocolo . . . . .
10.3. Diagrama de Secuencia para la firma de un CertReq . . . . .
10.4. Diagrama de Secuencia de la obtención de un certificado . . .
10.5. Instanciación de módulos dependiendo el modo de operación .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 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.7. Formato del mensaje AUTH MESSAGE FINISH
9.8. Formato del mensaje AUTH MESSAGE FINISH
9.9. Generación de la firma . . . . . . . . . . . .
9.10. Formato del mensaje firma . . . . . . . . .
9.11. Formato del paquete de OLSR firmado . . .
9.12. Firma + Encripción de un paquete . . . . .
9.13. Formato del mensaje firma con timestamp .
9.14. Etapas del protocolo OLSR . . . . . . . . .
8
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
88
91
91
93
Juan Manuel Caracoche - Tesis de grado Ingenierı́a Informática
ÍNDICE DE FIGURAS
va
Juan Manuel Caracoche - Tesis de grado Ingenierı́a Informática
9
ÍNDICE DE FIGURAS
10
Juan Manuel Caracoche - Tesis de grado Ingenierı́a Informática
Capı́tulo 1
Introducción
El mundo de las telecomunicaciones crece dı́a a dı́a poniendo en nuestras manos distintas
alternativas de comunicación. En estos últimos tiempos el avance de la tecnologı́a ha puesto a
disposición del usuario final tecnologı́as tan potentes como una máquina de escritorio en dispositivos de bolsillo. Estos dispositivos no son útiles o la mayorı́a de sus utilidades no están
disponibles si no están 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óviles serán pronto el método preferido de acceso a la información. Las comunicaciones de estos dispositivos se hacen de manera inalámbrica, brindando mayor comodidad
al usuario y pudiendo conectarse en cualquier lugar. Las conexiones inalámbricas se hacen sobre
WLAN (Wireless Local Area Network) bajo el estándar 802.11. Este estándar permite dos modos
de operación, 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 fijo. En modo ad-hoc la comunicación se hace directamente de dispositivo a dispositivo sin pasar por un punto de acceso fijo. Esta
propiedad hace que las redes ad-hoc sean flexibles y rápidas de desarrollar.
A medida que la demanda de conexiones crezca, éstas van a ser más 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 ágil para configurar una red autónoma.
Si bien la aplicación de este tipo de redes está pensada para un ambiente donde haya un gran
número de dispositivos, y hoy en dı́a serı́a difı́cil pensar un uso, en poco tiempo más podrı́amos
utilizar este tipo de redes por ejemplo para conectar todos los automóviles que circulan en una
autopista y en caso de haber un accidente todos los conductores se enterarı́an y podrı́an evitar
congestiones utilizando desvı́os. Pensando en el futuro cuando todas las personas tengan un
dispositivo móvil, el uso de estas redes quedará limitada a la imaginación y la creatividad.
Como cualquier red inalámbrica, las redes ad-hoc están expuestas a ataques de cualquier
persona ya que el medio fı́sico de propagación es el aire. Las redes en modo infraestructura
cuentan con la ventaja de que todo el tráfico pasa por un punto de acceso fijo en el cual se
pueden aplicar diferentes técnicas 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ón
1.1.
Motivación
Ya hace un tiempo que me he visto atraı́do por la tecnologı́a WiFi, la cual pertenece al
estándar 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 inalámbricas. Por otro lado, no existe ningún
estándar sobre este tipo de redes, lo cual hace que una investigación y análisis de los borradores
elaborados hasta el momento pueda hacer un aporte para la construcción 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óvil urbana basada en el protocolo OLSR.
El protocolo OLSR se utiliza en el proyecto BAL (Buenos Aires Libre) y en proyectos de redes
móviles urbanas en todo el mundo por lo que la aplicación de su estudio y análisis de securización
tiene un uso potencial significativo.
En el desarrollo de la tesis se analizarán protocolos de ruteo de redes móviles, se realizarán
comparaciones entre los mismos dando especial énfasis en los aspectos de seguridad con el objetivo
de tomar ideas para realizar el diseño de un protocolo OLSR seguro.
Se estudiará y detallará como funciona una red móvil basada en OLSR, principales técnicas
de ataque y posibles alternativas de prevención.
Del análisis de los protocolos de ruteo existentes, se propondrá la manera de mejorar la
seguridad de una red móvil urbana, en particular para una topologı́a similar a la de BAL.
Para lograr este objetivo se trabajará en un esquema de arquitectura de seguridad de acuerdo
al uso de la red y al grado de participación de los nodos en la misma.
La tesis tendrá en mente lograr mejorar la capacidad del protocolo de obtener disponibilidad,
integridad, confidencialidad, autenticación y no repudio de sus paquetes de control.
12
Juan Manuel Caracoche - Tesis de grado Ingenierı́a Informática
Capı́tulo 2
Redes Móviles
El objetivo del presente capı́tulo es dar una introducción a las Redes Móviles
y presentar los principales protocolos de ruteo para dar un marco teórico al lector
y conocer distintas alternativas para un mismo objetivo, rutear nodos en un Red Móvil.
Dentro del mundo de las redes las configuraciones más conocidas son:
Redes Fijas: son aquellas redes donde los componentes que la integran son fijos y están
interconectados generalmente por cable.
Redes Inalámbricas: en esta categorı́a se encuentran las redes donde sus componentes
podrı́an estar en movimiento pero siempre conectados de manera inalámbrica a un punto
fijo o las redes ad-hoc, en las cuales los integrantes de la red se comunican entre sı́ mediante
una conexión inalámbrica. Por último y dentro de la categorı́a de las redes inalámbricas
(ad-hoc) están las Redes Móviles (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 razón, los
protocolos de ruteo existentes para redes fijas no funcionan, ya que es necesario que la topologı́a
de la red se vaya cambiando dinámicamente. En estas redes, el concepto de Servidor utilizado
en una red fija cambia ya que en éstas siempre logramos conectarnos, en cambio en una red con
estas caracterı́sticas no siempre se puede acceder a un nodo, con lo cual en una MANET podrı́a
no haber DNSs o Entidades Certificantes (CAs), etc.
13
2.2. Protocolos de Ruteo
2.2.
Protocolos de Ruteo
El ruteo en la redes móviles ha sido un desafı́o, ya que la naturaleza de la red tiene muchas
variables (tamaño, disposición de los nodos, uso del ancho de banda, ahorro de energı́a, etc) que
son muy difı́ciles de ser contempladas por todos los protocolos.
Protocolos como los utilizados en redes fijas (Distance-Vector o Link-State) no se pueden
utilizar en las redes móviles ya que la información de la distancia de los integrantes de la red
varı́a con gran frecuencia. Esto insumirı́a mucho ancho de banda y baterı́a de los dispositivos
móviles para mantener esa información actualizada en cada nodo.
Para diseñar un protocolo para redes ad-hoc se deberı́a tener en cuenta las siguientes cuestiones
[1, Chap. 10.1]:
Mı́nimo overhead de paquetes de control: Si se disminuye el número de paquetes de control,
se ahorra ancho de banda y baterı́a en los dispositivos.
Mı́nimo tiempo de procesamiento: Los algoritmos elegidos tienen que ser simples, ası́ de
esta manera no se insume tiempo de baterı́as en procesamiento.
Capacidad de ruteo con múltiples saltos: Como los dispositivos muchas veces no tienen
transmisión directa, se requiere que éstos se puedan comunicar a través de un tercero que
sı́ está en el rango de transmisión directa.
Mantenimiento dinámico de la topologı́a: Una vez que se tiene establecida una ruta es muy
común por la caracterı́stica de la red que se pierda el vı́nculo, ya sea con el destino o
entre algunos dispositivos que “ayudan” en el trayecto. Por lo tanto el protocolo tiene que
solucionar las pérdidas de conexión con un overhead mı́nimo.
Prevención de bucles: Se forma un bucle cuando se arma una ruta que elige como próximo
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ón inactivo: El protocolo debe estar preparado para que en perı́odos donde
la actividad de la red baje sea capaz de “dormirse” y de esta manera consumir menos
energı́a.
Durante la evolución 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ón de distintos protocolos, clasificados en distintos grupos según su
forma de generar las rutas. Luego se verán distintos protocolos que logran tener redundancia de
las rutas para minimizar los tiempos de rearmado de la ruta en caso de la pérdida de la misma
( 2.3.4).
14
Juan Manuel Caracoche - Tesis de grado Ingenierı́a Informática
Redes Móviles
Figura 2.1: Clasificación de protocolos de ruteo
2.3.
Protocolos de Ruteo Proactivos, Reactivos e Hı́bridos
Los protocolos de ruteo para Redes Móviles tiene sus bases sobre los protocolos de redes cableadas. Como fué comentado anteriormente (2.2) estos protocolos necesitan intercambiar mucha
información 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óviles. Para superar
los problemas asociados a los algoritmos Link-State y Distance-Vector se han desarrollado una
variedad de protocolos los cuales se pueden clasificar 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 actualización periódicos. En los protocolos
reactivos las rutas son calculadas en el momento que son requeridas utilizando un procedimiento
de descubrimiento hacia el destino. Los protocolos hı́bridos combinan las propiedades básicas 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ón acerca de cómo llegar a todos los destinos (nodos) de la red. Esta información es
almacenada en tablas las cuales son actualizadas periódicamente cuando hay modificaciones en
la topologı́a 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 información de cada tabla y la manera de encontrar
la información. Los protocolos más 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.
.
Juan Manuel Caracoche - Tesis de grado Ingenierı́a Informá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 está basado en el clásico protocolo de DistanceVector de Bellman-Ford (DBF) [4] modificado para prevenir lazos cerrados (loops). Este protocolo sirve para encontrar a partir del algoritmo de Distance-Vector cuál es el camino más 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á etiquetada con un número de secuencia el cual es generado por el nodo
destino. La tabla contiene los siguientes datos:
Dirección IP destino
Nro de secuencia de destino
Dirección IP del próximo salto hacia el destino
Nro de saltos hasta el destino
Time stamp
Esta tabla debe ser mantenida periódicamente para actualizar los cambios que puedan sucederse en la red. Estas actualizaciones se realizan a través de mensajes broadcast o multicast. Los
datos enviados por cada nodo contienen su nuevo número de secuencia y la información referente
a cada nueva ruta. Cuando el destino recibe esa información actualiza sus propias tablas de ruteo.
Las tablas de ruteo también son enviadas si se detecta algún cambio en la topologı́a. Los nodos
utilizan los números de secuencia de destino para poder distinguir entre rutas antiguas y rutas
nuevas hacia un mismo destino. Un nodo incrementa su número de secuencia cuando se produce
un cambio a nivel local en la topologı́a de sus vecinos. La ruta hacia el destino que tenga el
número de secuencia más grande (más reciente) será la elegida. En caso que existan dos rutas
con el mismo destino y mismo número de secuencia, será elegida la que tenga menos saltos hacia
el destino. En la redes con gran cantidad de nodos se generarı́an muchas colisiones en el tráfico
broadcast (storm of broadcast), para ello el protocolo utiliza dos tipos de paquetes para actualizar
la información:
full dump: Transporta la información de todas las rutas.
incremental : Transporta sólo la información de las rutas nuevas (variación desde un full
dump)
Los paquetes incrementals, por razones de diseño 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ño de dicha información se acerca al tamaño de la NPDU, el próximo paquete
será un full dump. De esta manera se optimiza el envı́o de paquetes. Sin embargo este protocolo
no podrá escalar hacia grandes redes ya que requiere de un envı́o de paquetes de O(N 2 ), donde
N es el número de nodos de la red. Se podrı́a dar el caso que un nodo reciba información de ruteo
16
Juan Manuel Caracoche - Tesis de grado Ingenierı́a Informática
Redes Móviles
sobre un destino que es mejor que la que tiene por lo que, éste informará a sus vecinos antes de
recibir todos los mensajes de actualización de la ruta. Por esto es que DSDV tiene un mecanismo
para mitigar este tipo de comportamiento que consiste en establecer un tiempo fijo para informar
los cambios. Este tiempo es calculado como el tiempo promedio que tarda en recibir el nodo
todos los paquetes de actualización de una ruta. De esta manera el nodo se asegura de enviar la
información de la nueva ruta luego que recibió todos los paquetes de actualización y disminuye
el uso de ancho de banda y consumo de energı́a de los vecinos.
2.3.1.2.
Optimized Link State Routing (OLSR)
El protocolo Optimized Link State Routing (OLSR) [1, Sec. 10.2] es un protocolo de ruteo
proactivo basado en el protocolo Link-State. La principal caracterı́stica es que utiliza multipoint
relays (MPRs) para minimizar el flooding en la red y la cantidad de links que se deben mantener.
Cada nodo de la red elige un conjunto de nodos a los cuales los marca como MPRs, el resto de
los vecinos reciben los mensajes pero no los reenvı́an. Sólo los MPRs reenvı́an los mensajes. El
nodo debe elegir a los MPRs, de manera tal de llegar a través de éstos a todos los vecinos que
están 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 través de ellos puede llegar a todos los vecino de dos saltos de distancia.
Figura 2.2: Multipoint Relays
Elección de los Multipoints Relays El mecanismo de selección 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 figura su
dirección 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ón de los MPRs es:
1. Selecciona los nodos del Nivel 1 que cubren nodos aislados del Nivel 2. Nodo aislado es
Juan Manuel Caracoche - Tesis de grado Ingenierı́a Informá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úmero 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ún cambio en los enlaces con los
vecinos.
Cálculo de la tabla de ruteo Cada nodo necesita armar su propia tabla de ruteo. Para ello,
utiliza mensajes de control llamados Topology Control (TC). Estos mensajes son distribuı́dos
por la red utilizando broadcast. Cada MPR envı́a mensajes TC informando cuales nodos lo han
elegido a él como MPR (informa su MPR Selector ).
La información difundida por la red a través de los TC ayudan a cada nodo a armar su tabla
de topologı́a (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 topologı́a contiene la dirección de un potencial
destino, la dirección del último salto a ese destino (origen del mensaje TC ) y el número de
secuencia correspondiente al nodo que envió el mensaje. Cada entrada en la tabla de topologı́a
tiene un timestamp para verificar la validez de la misma.
Para el armado de la tabla de ruteo, el nodo utiliza tanto la tabla de vecinos como la tabla de
topologı́a, en esta última utiliza la dirección de ú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úmeros de secuencia
para detectar cambios en la topologı́a y ası́ invalidar rutas. Como la tabla de ruteo depende de
la tabla de vecinos y de la tabla de topologı́a, cualquier cambio en alguna de ellas implica la
reconstrucción de las rutas.
Cada entrada en la tabla de ruteo contiene la dirección del destino, la dirección del próximo
salto y el número 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 baterı́a 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 petición de ruta (Route Request) de tipo
broadcast y recibirá un mensaje de respuesta con la ruta (Route Reply). Si el mensaje de petición
de ruta viajó 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) crecerá con
O(N + M ) [2] donde N es el la cantidad de nodos de la red y M es el número de nodos en el
18
Juan Manuel Caracoche - Tesis de grado Ingenierı́a Informática
Redes Móviles
camino de vuelta con la respuesta. Cuando los enlaces son unidireccionales el overhead introducido
es de O(2N ).
Los protocolos reactivos pueden clasificarse en dos categorı́a:
Basados Ruteo del origen (source routing): En esta modalidad cada paquete de datos transporta en su cabecera la ruta completa desde el origen al destino, es decir, todas la direcciones
de los nodos intermedios. Cada nodo intermedio utilizará la cabecera del mensaje para 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óviles grandes donde haya mucha movilidad de los nodos ya que
es más 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ón
del destino y la del próximo salto, de forma tal que cada nodo intermedio deberá consultar
su tabla de ruteo para saber donde va a reenviar el paquete.
La ventaja de esta estrategia es que las rutas se adaptan dinámicamente a medida que
cambia la red. La desventaja es que cada nodo intermedio debe almacenar y mantener la
información de cada una de rutas mediante el intercambio de mensajes con sus vecinos.
Los protocolos más 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 caracterı́sticas:
Bajo overhead : Al no realizarse actualizaciones periódicas de la información de todos los
nodos, se garantiza un mı́nimo uso de ancho de banda para los paquetes de control.
Bajo overhead de procesamiento: Los mensajes enviados son cortos y no requieren mucho
cálculo.
Previene la formación de bucles: Provee un mecanismo para la prevención de formación de
bucles utilizando números de secuencia en los mensajes.
Tipo de mensajes de control que utiliza AODV:
Juan Manuel Caracoche - Tesis de grado Ingenierı́a Informática
19
2.3.2. Protocolos de Ruteo Reactivos
RREQ (Route Request): Mensaje que se envı́a cuando se necesita una ruta.
RREP (Route Reply): Mensaje de respuesta a la solicitud de una ruta.
RERR (Route Error): Este mensaje se envı́a cada vez que se detecta una rotura de enlace
y deja a un destino inaccesible.
Con el fin de prevenir bucles cada nodo mantiene un número de secuencia que sirve para
evaluar la vigencia de la información asociada a cada mensaje que envı́a el nodo. El número de
secuencia aumenta en uno cada vez que un nodo envı́a 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úmero de secuencia Sec#D al valor máximo entre su número de secuencia actual
Sec#D actual y el número de secuencia del destino que se encuentra contenido en el RREQ
(RREQ.Sec#) más uno.
Los números 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 éstas tengan un
mismo número de secuencia, escogerá la que tenga la mı́nima cantidad de saltos.
Descubrimiento de la ruta El descubrimiento de la ruta [8, Sec. 2.1] (Path Discovery) se
inicia cuando un nodo necesita comunicarse con otro y no existe una entrada en su tabla de
ruteo. Cada nodo mantiene dos contadores independientes: un número de secuencia del nodo
(node sequence number ) y un identificador para los paquetes broadcast (broadcast id ).
Los pasos para el descubrimiento de la ruta son:
El nodo origen inicializa el proceso de descubrimiento mediante la emisión de un mensaje
broadcast de tipo RREQ (route request) a sus vecinos (Figura 2.3(b))
El par < direccion origen, broadcast id > identifica unı́vocamente al mensaje RREQ. El
broadcast id se incrementa cada vez que el origen genera un nuevo mensaje RREQ
Si alguno de los vecinos tiene una ruta hacia el destino solicitado, contesta con un mensaje
RREP y en caso contrario reenvı́a el mensaje RREQ a sus vecinos (Figura 2.3(c)) luego de
incrementar la cantidad de saltos. Como un nodo puede recibir muchas veces el mismo mensaje
RREQ, descarta aquellos donde la dirección 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 información para luego
implementar el armado del camino reverso (reverse path)
La información almacenada en esta tabla tiene un tiempo de vida limitado, cuando se cumple
ese tiempo la información es eliminada de la misma. La ruta inversa sirve para cuando el nodo
recibe un mensaje RREP (Figura 2.3(e)), éste es enviado hacia el origen a través de esta ruta
inversa.
El mensaje RREP contiene la dirección IP del origen y el destino.
Este paquete es enviado al nodo origen a través 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úmero de saltos del
mensaje RREP, inserta una entrada en la tabla de ruteo (Figura 2.3(h)). La entrada en la tabla
20
Juan Manuel Caracoche - Tesis de grado Ingenierı́a Informática
Redes Móviles
utiliza al nodo origen del mensaje RREP como próximo salto hacia el destino. A este paso se lo
llama definir un Forward Path [9].
Si un nodo recibe más de un mensaje RREP para un destino por parte de más de un vecino,
éste reenvı́a 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 más de una ruta hacia el destino, éste
utilizará aquella que tenga menor número de saltos y el mayor número 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
bradcast id y dirección IP del nodo origen hace que rutas probablemente mas cortas no se lleguen
a descubrir, pero entre las rutas calculadas se elige la más 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 envı́a periódicamente mensajes de hello (es un mensaje RREP especial ya que no
es respuesta de un RREQ) para asegurarse que los enlaces simétricos estén utilizables. Este
mensaje de hello contiene la dirección IP del nodo, su número de secuencia (no cambia el número
de secuencia con el envı́o 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 pertenecı́a al vecindario
se asume que hubo cambios entre los vecinos. Para garantizar que el enlace sea simétrico o
bidireccional envı́a 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 próximos RREQs debido a la
unidireccionalidad del enlace.
Cuando el nodo detecta la rotura de la ruta, la invalida y envı́a un mensaje RERR. En este
mensaje se envı́a todos los destinos que ya no pueden ser alcanzados. En el caso que haya nodos
intermedios entre el nodo origen y el nodo que detectó la ruptura y éstos estaban utilizando el
enlace, el mensaje RERR se propaga en modo broadcast sino unicast.
Cuando un nodo recibe un mensaje RERR, éste verifica que el nodo del cual recibió sea el
próximo salto hacia alguno de los destinos informados, luego marca la entrada en la tabla como
inválida y reenvı́a el mensaje RERR hacia el origen. Una vez que el origen recibe el mensaje
RERR, puede decidir reiniciar un proceso de búsqueda de una nueva ruta en caso que la necesite.
Una de las caracterı́sticas de AODV es que cuando detecta una rotura de enlace, el nodo no
envı́a un RERR en ese momento sino que reintenta reconstruir el enlace generando un RREQ
previo incremento del número de secuencia. En el caso que no pueda restablecerlo envı́a el RERR
al origen.
Otra caracterı́stica que se incorpora al protocolo en los ú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.
Juan Manuel Caracoche - Tesis de grado Ingenierı́a Informática
21
2.3.2. Protocolos de Ruteo Reactivos
(a) El origen 1 quiere enviar datos a 10
(b) El nodo 1 envı́a un mensaje RREQ a sus
vecinos
(c) Los nodos 2, 3 y 4 reciben RREQ y los propagan a sus vecinos
(d) Se continúa la propagación. Notar que 3 no
reenvı́a el RREQ porque ya lo recibió antes
(e) Se continúa la propagación. 5 no propaga
RREQ
(f) Se llega al nodo 10 y éste no reenvı́a 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ón de una ruta en AODV
22
Juan Manuel Caracoche - Tesis de grado Ingenierı́a Informática
Redes Móviles
2.3.2.2.
Dynamic Source Routing (DSR)
El protocolo Dynamic Source Routing (DSR) [10] es un protocolo simple y eficiente diseñado
especı́ficamente para redes inalámbricas de multiples saltos donde los nodos de la misma están
en continuo movimiento. El protocolo está 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 caracterı́sticas del protocolo son:
Bajo Overhead : por ser un protocolo bajo demanda, solo se envı́a 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 fácil y poco costosa la generación de lazos.
Enlaces unidireccionales: puede funcionar con enlaces unidimensionales.
Rápido Recupero: recupero rápido de la ruta ante un cambio en la red.
escalabilidad esta diseñado 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 caché 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 caché si existe alguna ruta y
la utiliza, en caso de que la ruta falle, puede utilizar otra ruta del caché. De esta manera previene
el descubrimiento de una nueva ruta y acelera el proceso del envı́o 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 caché. El nodo origen envı́a un mensaje RREQ (Route
Request) con la dirección del nodo origen (Figura 2.5(b)), la dirección del nodo destino y un
identificador de RREQ. Un mensaje RREQ adicionalmente contiene las direcciones de todos los
nodos intermedios que han reenviado el mensaje. Cuando un nodo vecino recibe el mensaje RREQ
busca en su cache si no tiene una ruta hacia el destino solicitado, en caso que ası́ sea envı́a un
mensaje RREP (Route Reply) que contiene una copia de la ruta al destino y le concatena la ruta
acumulada que traı́a el RREQ (Figura 2.5(c)). En caso que el mensaje lo reciba el nodo destino,
éste envı́a un RREP con la ruta que se acumuló en el RREQ desde el origen hasta el destino.
Si el nodo que recibe el RREQ no es el destino y no tiene una ruta hacia el destino, verifica si
ya ha recibido un mensaje con el mismo origen, mismo destino y mismo identificador de RREQ
o bien si su dirección está en el registro de ruta del mensaje RREQ. En este caso y con el fin de
limitar el número de mensajes RREQ que viajan por la red, éste es descartado (Figura 2.5(d)).
Juan Manuel Caracoche - Tesis de grado Ingenierı́a Informática
23
2.3.2. Protocolos de Ruteo Reactivos
Por lo tanto los RREQs que se propagan durante el descubrimiento son los primeros en llegar a
un determinado nodo. Si se elige como ruta óptima la ruta del primer RREP que llegue al origen,
se puede asegurar que esa ruta es, en ese momento, la más rápida para alcanzar al destino. Si
no se cumplen ninguna de las condiciones, el mensaje es retransmitido pero el nodo agrega su
dirección al registro de ruta.
Cuando un nodo debe devolver un mensaje RREP hacia el origen, se fija en su caché si
tiene una ruta hacia el origen, en caso que la tenga la utiliza, en caso contrario el nodo destino
deberá comenzar su propio mecanismo de descubrimiento, pero para evitar una recursión infinita
de búsquedas de rutas, el nodo destino deberá hacer piggyback (ponerlo al final) del mensaje
RREP en su propio RREQ. En el caso que se utilicen enlaces simétricos, 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 técnica de enviar el RREP a través de la ruta incluida en el RREQ
ya que es lo más adecuado para evitar el overhead de descubrir una nueva ruta. El protocolo
MAC además prueba que la ruta sea bidireccional antes de comenzar a utilizarla. Como DSR
está pensado para redes inalámbricas y muchas veces el enlace unidireccional es la única manera
de conectividad, este protocolo también 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 caché para comenzar a enviar datos (Figura 2.5(g)). De esta manera un nodo origen puede
recibir múltiples rutas (Figura 2.5(f)) , las cuales son almacenadas para prevenir un descubrimiento de ruta en caso que una deje de estar disponible. Una caracterı́stica que destaca a DSR de
los otros protocolos reactivos es que las rutas no tienen un tiempo de vida, son utilizadas hasta
que se reciba un mensaje indicando que la ruta no está disponible. Esto hace que si los nodos
permaneces relativamente estáticos 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. También se puede activar una opción
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ón de un enlace roto y envı́o del RERR
24
Juan Manuel Caracoche - Tesis de grado Ingenierı́a Informática
Redes Móviles
(a) El origen 1 quiere enviar datos a 10
(b) El nodo 1 envı́a un mensaje RREQ a sus
vecinos especificando en la ruta su dirección
(c) Los nodos 2, 3 y 4 reciben RREQ y los propagan a sus vecinos concatenando su dirección
en la ruta (a los efectos del ejemplo no se especifica la ruta enviada por 2)
(d) Se continúa la propagación. Notar que 3 no
reenvı́a el RREQ porque ya lo recibió antes
(e) El RREQ llega al destino 10 y este no lo retransmite y arma el RREP y lo envı́a al destino.
9 continúa la propagación del RREQ
(f) Llega el segundo RREQ al nodo 10, arma
un nuevo RREP y lo envı́a 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ón de una ruta en DSR
Juan Manuel Caracoche - Tesis de grado Ingenierı́a Informática
25
2.3.3. Protocolos de Ruteo Hı́bridos
Mantenimiento de la Ruta Cuando un nodo transmite o reenvı́a un mensaje, éste debe
asegurarse que fue entregado al próximo salto [11, Sec 3.3] (se puede definir un número máximo
de reintentos en el envı́o del paquete). Esta confirmación de recepción 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 envı́o con la trama link-level acknowledgement.
Si este mecanismo no está disponible, se configura un bit indicando a DSR que se necesita una
confirmación a nivel protocolo DSR. Es muy probable que si esta opción está especificada es
porque no se esté trabajando sobre un protocolo MAC como el especificado anteriormente o se
tengan enlaces unidireccionales, con lo cual la respuesta puede viajar a través de otra ruta.
Si un paquete es reenviado un número máximo de veces y no se recibe respuesta, el nodo
retorna un mensaje de error llamado RERR indicando a través de que enlace no se pudo enviar
el paquete (Figura 2.4). Cuando el nodo origen recibe este mensaje marca la ruta como inválida
e intenta utilizar otra de las rutas de su caché, en caso de no tener ninguna inicia un nuevo
mecanismo de descubrimiento.
2.3.3.
Protocolos de Ruteo Hı́bridos
Las caracterı́sticas de los protocolos de ruteo reactivos y proactivos pueden combinarse de
varias maneras y dan lugar a los protocolos de ruteo hı́bridos. Un protocolo hı́brido utiliza caracterı́sticas de los protocolos reactivos y proactivos dependiendo las circunstancias. Uno de los
principales ejemplos es el protocolo Zone Routing Protocol.
2.3.3.1.
Zone Routing Protocol (ZRP)
ZRP [12, Sec II] es un ejemplo de un protocolo de ruteo hı́brido. Por un lado limita el alcance
de un protocolo proactivo para los nodos de su vecindad. Por otro lado utiliza el mecanismo de
descubrimiento de ruta de un protocolo reactivo para buscar nodos más allá de su vecindario. El
protocolo identifica diferentes rutas sin caer en un bucle capaces de alcanzar un destino, de esta
manera hace que sea más confiable y performante.
Cada nodo define un radio que es medido en cantidad saltos. Cada nodo utiliza un protocolo
proactivo en su zona y uno reactivo fuera de ella. De esta manera un nodo conoce a todos sus
vecinos de sus zona y todas las rutas hacia ellos. Cuando un nodo quiere enviar un paquete de
datos primero busca en su tabla de rutas una ruta hacia el destino, si el destino pertenece a su
zona la ruta la tiene. Si el destino no está en su zona, comienza a buscar una ruta hacia el destino.
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ón de todos los nodos dentro de la zona. En la Figura 2.6
se puede ver un ejemplo la definición de una zona de un salto para el nodo O y como es una zona
de un salto de distancia quedan definidos automáticamente los nodos frontera o periféricos (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 término bordercasting. Cuando un nodo
determina que el nodo al que le quiere enviar un paquete está fuera de su zona, el nodo origen
26
Juan Manuel Caracoche - Tesis de grado Ingenierı́a Informática
Redes Móviles
Figura 2.6: Zona de un nodo usando ZRP
hace un bordercast del pedido de ruta. El término bordercast no es más que enviar un mensaje
directamente al nodo frontera para que éste luego haga el descubrimiento de la ruta.
El nodo frontera cuando recibe un mensaje de solicitud de ruta, verifica si el destino está en
su zona, en caso que no esté reenvı́a el pedido a cada uno (uno por vez) de sus nodos frontera.
Este procedimiento continúa hasta que se localice el destino o hasta que se examina toda la red.
Cuando un nodo encuentra al destino, éste envı́a un mensaje unicast hacia el origen.
Figura 2.7: Descubrimiento de una ruta con IERP
En la Figura 2.7 se ilustra un pedido de ruta utilizando IERP. En la figura, el nodo O hace
una búsqueda de la dirección del nodo E. Utilizando IARP, se sabe que no está dentro de su zona,
por lo tanto hace un bordercast del requerimiento a los nodos periféricos. Los nodos periféricos,
uno por vez, chequean su zona en busca de la dirección solicitada (los circulo sólidos representan
las zonas hacia donde se envió el requerimiento). En caso que no esté en su zona, reenvı́a el pedido
a sus nodos periféricos. En la figura, cuando le llega el pedido al nodo D, éste encuentra en su
zona al nodo E y envı́a una mensaje unicast hacia el nodo O con la respuesta.
ZRP tiene varios parámetros y técnicas para mejorar su performance y para prevenir la
propagación de una búsqueda cuando ésta ya ha sido contestada por algún nodo. ZRP incorporó e
su versión 2 (ZRPv2) una manera diferente a las hora de hacer bordercasting. ZRPv2 hace que el
nodo origen construya un árbol hacia los destinos que no pertenecen a su zona. En ese árbol y como
primer hijo se encuentran los nodos periféricos. Cuando un nodo periférico recibe una consulta,
Juan Manuel Caracoche - Tesis de grado Ingenierı́a Informática
27
2.3.4. Técnicas de Ruteo
primero construye su propio árbol. Este procedimiento se repite hasta alcanzar el destino.
2.3.4.
Técnicas de Ruteo
Todos los protocolos antes descriptos, en su mayorı́a, 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 podrı́an sufrir modificaciones contı́nuas
y llevarı́a a los nodos a estar continuamente ejecutando procedimientos de descubrimiento de
ruta. Para subsanar esta situación 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 mayorı́a de los protocolos vistos en este capı́tulo, los nodos registran las rutas hacia los
distintos destinos en tablas de ruteo, en casi todos los casos cada entrada de la tabla tiene una
sola dirección como próximo salto para continuar el camino hacia el destino. La idea principal de
los protocolos multi path es almacenar en un caché 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 técnica y son adaptaciones de los protocolos antes
vistos para soportar múltiples caminos hacia el destino. Como se vió antes DSR, en forma nativa,
es decir sin ninguna adaptación, soporta caché de rutas. Entre los protocolos adaptados para
utilizar caché 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
caché con varias rutas para un mismo destino con un ú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ás cercano al origen envı́a un paquete de error hacia éste y a la vez lo envı́a
en forma broadcast a todos los vecinos. El paquete, en la cabecera de datos, indica que el link se
ha roto y que el paquete necesita una ruta alternativa. Cuando los nodos del vecindario reciben
este mensaje, lo reenvı́an hacia el destino si es que ellos tienen una ruta hacia el mismo.
Split Multipath Routing (SMR) [14] es un protocolo bajo demanda que arma las rutas de
manera disjuntas. Utiliza dos rutas para cada sesión; una es la que tiene la menor latencia y otra
que es la más disjunta con ésta, es decir la que menos enlaces en común tenga. De esta manera
28
Juan Manuel Caracoche - Tesis de grado Ingenierı́a Informática
Redes Móviles
SMR provee rutas alternativas y por ser disjuntas se minimiza el riesgo de rotura de una ruta
por tener la mı́nima cantidad de enlaces comunes.
SMR tiene dos esquemas de mantenimiento de las rutas. El primero crea un nuevo par de
rutas si una de las dos rutas se rompe y el segundo hace una reconstrucción de las rutas solo
cuando ambas rutas se hayan roto.
2.4.
Resumen
A lo largo del Capı́tulo se vieron los diferentes tipos de algoritmos disponibles para redes
móviles. Como se vió hay dos categorı́as 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 actualización de rutas pero una mı́nima
latencia. Los reactivos tienen un mı́nimo overhead pero mayor latencia.
Llegada la discusión de cual tipo de algoritmo es mejor, habrı́a que ver cual es la finalidad
de la red, que servicios se van a montar sobre ésta, que cantidad de nodos y que velocidad o con
qué frecuencia podrı́a cambiar la topologı́a.
Dentro de los protocolos proactivos se desarrollaron DSDV y OLSR. DSDV tiene un alto
overhead de paquetes de control pero tiene detección de bucles. OLSR tiene menos overhead,
tiene detección de bucles pero requiere conocer los vecinos que están 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 caché de rutas con lo
cual minimiza la latencia en caso de perder una. AODV tiene como virtud que se adapta rápidamente a redes con nodos de mucha movilidad. Ambos protocolos tiene como contra problemas
de escalabilidad en redes con muchos nodos.
Como una alternativa a estos dos tipos de algoritmos, se analizaron protocolos hı́bridos los
cuales usan un protocolo proactivo dentro de un vecindario y protocolos reactivos para llegar
a nodos fuera del vecindario. Estos protocolos son óptimos para topologı́as donde los nodos se
mueven pero siempre dentro de un mismo ámbito.
Juan Manuel Caracoche - Tesis de grado Ingenierı́a Informática
29
2.4. Resumen
30
Juan Manuel Caracoche - Tesis de grado Ingenierı́a Informática
Capı́tulo 3
Seguridad Informática
En este capı́tulo se hará una revisión de los principales conceptos de la seguridad informática [35, Sec. 2.1].
Cuando se habla de seguridad en redes de computadoras, hay tres objetivos o premisas básicas
que se deben cumplir.
Confidencialidad: Se garantiza que la información sea accesible sólo a aquellas personas que
tienen acceso a la misma.
Integridad: Se salvaguarda la exactitud y totalidad de la información y los métodos de
procesamiento.
No Repudio: Se refiere a evitar que una entidad que haya enviado o recibido información
alegue ante terceros que no la envió o no la recibió.
Existen otros objetivos más difı́ciles de lograr pero que hacen a la seguridad de la información
Autenticación: Garantizar el origen y el destino de la información, validando al emisor y al
receptor para evitar suplantación de identidades.
Control de Acceso: Solo las partes autorizadas pueden participar en la comunicación.
Disponibilidad de Servicio: Garantiza que todos los componentes de la red estén disponibles
para ser utilizado por las partes autorizadas.
La mayorı́a de estos conceptos se garantizan por medio del uso de la criptografı́a y algoritmos
criptográficos.
3.1.
Conceptos Básicos de Criptografı́a
Es preciso introducir conceptos básicos de criptografı́a con el fin de que el lector se familiarice
con el lenguaje y adquiera los conceptos necesarios que luego serán aplicados en otros capı́tulos
de esta tesis.
31
3.1.1. Cifrados Simétricos
Por medio de la criptografı́a se ha podido garantizar las premisas de la seguridad para redes
de datos. A continuación se presentan conceptos básicos e introductorios.
3.1.1.
Cifrados Simétricos
Los algoritmos de cifrado simétricos 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 usándola,
lo envı́a al destinatario, y éste 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 deberı́a ser de ninguna ayuda para un atacante conocer el algoritmo que se está usando.
Sólo si el atacante obtuviera la clave, le servirı́a conocer el algoritmo.
3.1.1.2.
Ventajas y Desventajas
El principal problema con los sistemas de cifrado simétrico no está ligado a la seguridad
intrı́nseca de los algoritmos, sino a la forma en la que se intercambian las claves. Una vez que
las partes hayan intercambiado las claves pueden usarlas para comunicarse con seguridad, pero
se debe asegurar que dicho intercambio se haya realizado de forma “segura”. Por ejemplo si fue
un acuerdo verbal que nadie escucho la conversación; Si fue por correo, asegurarse que nadie
interceptó el sobre. Para un atacante es más fácil tratar de interceptar la clave en el momento de
intercambio que probar el espacio posible de claves.
Otro problema es el número de claves que se necesitan. Si tenemos un número 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 serı́a imposible llevarlo a cabo con grupos más grandes.
La principal ventaja de estos cifradores es que son muy rápidos e implementables fácilmente
por hardware.
3.1.1.3.
Algoritmos
DES DES fue el algoritmo de cifrado por bloques más usado, como todo cifrador simétrico
toma un texto de una longitud fija de bits y lo transforma mediante una serie de operaciones
en un texto cifrado de la misma longitud. Para el DES el tamaño del bloque es de 64 bits y la
clave es de 64 bits, de los cuales sólo 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/fipspubs/fip46-2.htm
32
Juan Manuel Caracoche - Tesis de grado Ingenierı́a Informática
Seguridad Informática
3DES El algoritmo 3DES consta de tres rondas de DES. Incrementa el tamaño de la clave por
un factor de 3 hasta 168 bits. Básicamente se usan tres claves de DES. El 3DES tiene hoy en dı́a
un nivel de seguridad aceptable y es utilizado por muchos dispositivos. Tiene el inconveniente
que es lento en comparación con el AES.
AES AES [31, Cap. 5] es un esquema de cifrado por bloques,tiene un tamaño de bloque fijo de
128 bits y tamaños de clave de 128, 192 ó 256 bits. La mayorı́a de los cálculos del algoritmo AES
se hacen en un campo finito determinado. Es el reemplazo de 3DES en los sistemas modernos.
Se encuentra estandarizado por el NIST en “FIPS 197, Advanced Encryption Standard (AES),
2001” 2 .
3.1.2.
Cifrados Asimétricos
Los cifradores asimétricos tienen la particularidad de contar con un par de claves, donde una
clave es pública 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ública del
destinatario para cifrar el mensaje, y una vez cifrado, sólo la clave privada del destinatario
podrá descifrar este mensaje.
Los criptosistemas asimétricos utilizan las denominadas funciones-trampa o de un solo sentido.
Estas funciones de un solo sentido son aquellas cuya cálculo es fácil, mientras que su inversa no es
simple. Por ejemplo, multiplicar dos números primos grandes es una operación simple de realizar,
pero factorizar el número resultante en sus componentes primos es una operación cuyo tiempo
de calculo puede llevar mucho tiempo al punto que para números de muchos bits puede llegar a
ser computacionalmente imposible es decir puede llevar años de calculo. Con lo cual serı́a en vano
intentarlo.
Se trata de lograr que la generación de las claves utilice la función trampa. Es decir generar
la clave sea simple, pero romperla sea equivalente a obtener la inversa de la función-trampa.
Por ejemplo, dado un cifrado de clave pública basado en factorización de números primos, la
clave pública contiene un número 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 fácil. Si poseemos la clave privada
que contiene uno de los factores será fácil su decodificación, pero extremadamente difı́cil en caso
contrario.
3.1.2.1.
Seguridad
Al igual que con los sistemas de cifrado simétricos, un buen sistema de cifrado de clave pública
no debe basarse en esconder el algoritmo, éste debe ser publico y la seguridad debe estar centrada
en esconder la clave.
El tamaño de la clave es una medida de la seguridad del sistema. Tener en cuenta que no se
puede comparar el tamaño de claves de un asimétrico con el de un simétrico.
2 http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf
Juan Manuel Caracoche - Tesis de grado Ingenierı́a Informática
33
3.1.3. Resumen Criptográfico
En un ataque de fuerza bruta sobre un cifrado simétrico con una clave de un tamaño de 80
bits, el atacante debe probar hasta 281−1 claves para encontrar la clave correcta.
El esfuerzo para romper un cifrado es diferente según el algoritmo utilizado. Mientras 128 bits
son suficientes para algoritmos con clave simétrica, los algoritmos de clase asimétrica necesitan
claves de por lo menos 1024 bits ya que la capacidad de cálculo actual y los algoritmos conocidos
de factorización impiden usar una clave menor.
3.1.2.2.
Ventajas y Desventajas
La mayor ventaja de la criptografı́a asimétrica es que se puede cifrar con una clave y descifrar
con la otra. Esto permite conseguir autenticación de una manera muy simple. Si se obtiene un
texto cifrado con la clave privada de alguien el único que lo pudo generar es el dueño de la clave
y todos podemos verificar el origen ya que disponemos de su clave publica.
Las principales desventajas son:
Para una misma longitud de clave y mensaje se necesita mayor tiempo de proceso.
Las claves deben ser de mayor tamaño que las simétricas.
Para textos pequeños, el mensaje cifrado ocupa más espacio que el original.
3.1.2.3.
Algoritmos
Existen varios algoritmos que utilizan el esquema de clave pública y clave privada, todos ellos
utilizan la misma base, complejidad matemática en la factorización de números primos.
Diffie-Helman Diffie-Hellman (debido a Whitfield Diffie y Martin Hellman) permite generar
claves en conjunto entre las partes que participan en la comunicación. Este algoritmo debe ser
utilizado sobre un canal de comunicación autenticado.
RSA El sistema criptográfico con clave pública RSA es un algoritmo asimétrico que utiliza
una clave pública, 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 dı́a se están utilizando 1024 o 2048 bits.
3.1.3.
Resumen Criptográfico
3.1.3.1.
Hash
Una función de Hash es una función que tiene por finalidad obtener una cadena de longitud
fija 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 función sobre un texto se le llama
hash o resumen criptográfico. Los algoritmos de hash y las funciones son públicas y no necesitan
claves.
El objetivo principal del hash es detectar cambios en el mensaje para verificar su integridad.
Una función puede ser usada como función de hash si cumple con las caracterı́sticas:
34
Juan Manuel Caracoche - Tesis de grado Ingenierı́a Informática
Seguridad Informática
Es fácil 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 mı́nima modificación al mensaje provoca
un gran cambio en el resultado de la función. Esta propiedad se llama difusión y confusión [31,
Cap. 12].
El hash por si solo no es útil. Es un auxiliar que se utiliza en conjunto con otras primitivas
criptográficas. Mas adelante se mostrará como en conjunto con un algoritmo asimétrico permite
construir la firma digital.
Algoritmos Los algoritmos más 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 (código) de aplicar una función que
recibe como parámetros un texto y una clave secreta compartida entre las partes. Aplicando esta
función se está autenticando el mensaje. Adicionalmente, el MAC al igual que los algoritmos de
hash, también previenen la manipulación de los mensajes protegiendo la integridad de los mismos.
Los algoritmos de MAC no son reversibles, es decir, a partir de un código MAC es imposible
hallar un mensaje que se corresponda. EL objetivo del mismo no es ocultar la información sino
protegerla y autenticar al origen.
Actualmente, dos de los más grandes grupos de funciones MAC según su modo de operación:
CBC-MAC: La idea detrás de este algoritmo es la de convertir un algoritmo de cifrado
simétrico en una función MAC. El funcionamiento básico consiste en cifrar el mensaje
usando un algoritmo en modo CBC y tirar todo el resultado de texto cifrado a excepción
del último bloque.
HMAC: Dado que una función MAC es un mapeo aleatorio, y que las funciones hash se comportan como tales, podemos explotar la idea de utilizar una función hash para implementar
una función MAC. La opción más popular hoy en dı́a es la de usar HMAC-SHA-256.
3.1.4.
Firma Digital
La firma digital es una manera de garantizar la autorı́a y la integridad de un documento
digital (texto, correo, aplicaciones, etc). Al igual que una firma ológrafa, la firma digital es usada
para manifestar un acuerdo/desacuerdo, indicar que se ha leı́do un documento digital.
El mecanismo de firmado de un documento digital (Figura 3.1) se realiza aplicando una
función de hash al mismo y luego encriptándola con la clave privada del autor generando ası́ la
firma. El documento firmado consta de dos partes, el documento en sı́ y la firma. Los lectores
del mismo, aplican la función de hash al documento y desencriptan la firma con la clave pública
Juan Manuel Caracoche - Tesis de grado Ingenierı́a Informática
35
3.1.5. PKI
del emisor. Compara el hash calculado con el desencriptado de la firma y si estos coinciden, se
garantiza que el documento no fue modificado y fue emitido por el autor. También se garantiza
que el autor no puede negar su autorı́a ya que es él el único que pudo encriptar el hash con su
clave privada
Figura 3.1: Proceso de Generación y Verificación de una Firma Digital
Resumiendo la firma digital garantiza integridad y no repudio.
3.1.5.
PKI
Una infraestructura de clave pública (PKI, Public Key Infrastructure) son los elementos necesarios (hardware, software, polı́ticas y procedimientos) para garantizar la identidad, cifrado
asimétrico y firmas digitales [31, Cap. 13] en operaciones electrónicas.
3.1.5.1.
Propósito y funcionalidad
La tecnologı́a PKI provee como servicio a los usuarios la posibilidad de autenticarse uno con
otros por medio de certificados expedido por una entidad de confianza para ambos. Esto a la
vez permite distribuir información (por ejemplo claves públicas) necesaria para los protocolos de
comunicación seguros, algoritmos de firma digital, cifrados y todas otras operaciones que requieran
conocer la identidad y garantizar el no repudio de la otra parte de la operación electrónica.
En una operación electrónica que use los servicios brindados por PKI, tiene como participantes
al menos tres partes:
Un usuario que desea realizar una operación
Una entidad que da fe de la ocurrencia de la operación y garantizan la validez de los
certificados de las partes.
Un usuario destinatario de los datos cifrados/firmados/enviados garantizados por parte del
usuario que inició de la operación.
36
Juan Manuel Caracoche - Tesis de grado Ingenierı́a Informática
Seguridad Informática
La seguridad de la tecnologı́a PKI se centra en la privacidad de la clave privada (ya que
esta infraestructura utiliza los mismos principios que los algoritmos de clave pública) y en los
procedimientos o polı́ticas de seguridad aplicadas a la gestión de los certificados.
Es de vital importancia ser rigurosos a la hora de establecer las polı́ticas de seguridad ya
que dejar expuesta una clave privada invalida cualquier tecnologı́a aplicada en el sistema o la
seguridad del cifrador más fuerte.
3.1.5.2.
Usos de la tecnologı́a PKI
La tecnologı́a PKI, es utilizada para realizar autenticación de personas, servidores, sistemas,
etc; realizar firmado digital de documentos, software, correo, etc; Garantizar el no repudio; Cifrado
de datos y aseguramiento de canales de comunicaciones inseguros.
Básicamente el uso de esta tecnologı́a se centra cuando es necesario autenticar a las partes
para realizar una transacción digital “segura”.
3.1.5.3.
Certificados
Como se dijo anteriormente, la tecnologı́a PKI se basa en Certificados Digitales expedidos por
una entidad de en la cual confı́an ambas partes. Existes distintos tipos de certificados digitales
que varı́an dependiendo el destino del mismo.
Certificado personal: Acredita la identidad del titular.
Certificado de pertenencia a una entidad: Además de la identidad del titular acredita su
vinculación con la entidad de la cual es miembro
Certificado de representante: Además de la pertenencia a la entidad acredita también los
poderes de representación que el titular tiene sobre la misma.
Certificado de persona jurı́dica: Identifica una entidad como tal a la hora de realizar trámites
ante las administraciones o instituciones.
Certificado de atributo: Permite identificar una cualidad, estado o situación. Este tipo de
certificado va asociado al certificado personal. (p.ej. Médico, Director, Casado, etc.).
Los tipos de certificados antes mencionados son relacionados con un individuo o persona,
también existen certificados digitales para fines más especı́ficos y técnicos como pueden ser:
Además, existen otros tipos de certificado digital con fines más técnicos:
Certificado de servidor: Permiten asegurar al usuario del mismo que la conexión la están
realizando a donde ellos quieren.
Certificado de firma: Garantiza la autorı́a y la no modificación de aplicaciones, documentos,
etc.
Juan Manuel Caracoche - Tesis de grado Ingenierı́a Informática
37
3.1.6. Componentes
3.1.6.
Componentes
Los componentes más habituales de una infraestructura de clave pública son:
La autoridad de certificación (CA, Certificate Authority): es la encargada de emitir y revocar
certificados. Es la entidad de confianza que da legitimidad a la relación de una clave pública
con la identidad de un usuario o servicio.
La autoridad de registro (RA, Registration Authority): es la responsable de verificar el enlace
entre los certificados (concretamente, entre la clave pública del certificado) y la identidad
de sus titulares.
Los repositorios: son las estructuras encargadas de almacenar la información relativa a la
PKI. Los dos repositorios más importantes son el repositorio de certificados y el repositorio
de listas de revocación de certificados. En una lista de revocación de certificados (CRL,
Certificate Revocation List) se incluyen todos aquellos certificados que por algún motivo
han dejado de ser válidos antes de la fecha establecida dentro del mismo.
La autoridad de validación (VA, Validation Authority): es la encargada de comprobar la
validez de los certificados digitales.
La autoridad de sellado de tiempo (TSA, TimeStamp Authority): es la encargada de firmar
documentos con la finalidad de probar que existı́an antes de un determinado instante de
tiempo.
Los usuarios y entidades finales son aquellos que poseen un par de claves (pública y privada) y un certificado asociado a su clave pública. Utilizan un conjunto de aplicaciones que
hacen uso de la tecnologı́a PKI (para validar firmar digitales, cifrar documentos para otros
usuarios, etc.)
3.1.6.1.
Consideraciones sobre PKI
Los Certificados Digitales deben ser emitidos por una Autoridad Certificante reconocida por
las partes para garantizar la validez del mismo. Ambas partes de la transacción electrónica debe
confiar en la Autoridad que emitió el certificado.
No es responsabilidad de la CA la conservación del certificado 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 polı́ticas de
seguridad y no es necesario realizar ningún tipo de intercambio de clave para realizar una comunicación segura.
3.2.
Resumen
En este capı́tulo se hizo una revisión de los conceptos principales de seguridad informática
y de los conceptos básicos de criptografı́a. Poniendo todo junto y considerando solo algunas
38
Juan Manuel Caracoche - Tesis de grado Ingenierı́a Informática
Seguridad Informática
alternativas, podemos resumir que para garantizar los pilares de la seguridad, la criptografı́a nos
da las siguientes herramientas:
Confidencialidad: Algoritmos simétricos y asimétricos
Integridad: Funciones de Hash y MAC
No Repudio: Funciones de Hash o MAC encriptadas con un esquema PKI
Estos conceptos se van a ir afianzando a medida que se avance en la lectura de la presente
tesis al ver la aplicación de cada uno.
Juan Manuel Caracoche - Tesis de grado Ingenierı́a Informática
39
3.2. Resumen
40
Juan Manuel Caracoche - Tesis de grado Ingenierı́a Informática
Capı́tulo 4
Seguridad en Redes Móviles
El objetivo del presente capı́tulo es exponer distintos tipos de ataques a los que
está expuesta una red Móvil y cuales son algunos de los protocolos de ruteo que
existen para hacer que este tipo de redes sean confiables. El estudio de estos protocolos
son necesarios para el objetivo de esta tesis. Por ello es que de cada uno de ellos se
resaltará que aspecto puede ser utilizado en esta tesis.
Como se vió en la Sección 2.1 las redes móviles son una colección de dispositivos móviles
formando momentáneamente una red sin la ayuda de una infraestructura. Estos dispositivos
utilizan el aire como medio fı́sico de comunicación, compartiendo con muchos otros el mismo
canal de transmisión. Los nodos participantes de una red móvil están mucho más expuestos a un
ataque que una computadora dentro de una red cableada ya que cualquier intruso no tiene más
que ponerse a escuchar el aire y puede comenzar su ataque.
Otra caracterı́stica de este tipo de redes es que su topologı́a en muy cambiante y dificulta
tener un control de los miembros de la red.
La naturaleza de las redes móviles 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óvil una red segura, hay que tener en cuenta los Servicios de Seguridad
descriptos en el Capı́tulo 3 extendidos a Redes Móviles [15]:
Disponibilidad: garantiza la supervivencia de la red ante la hostigación de nodos agresores.
Confidencialidad: garantiza que todo el tráfico que circula por la red (paquetes de control
y paquetes de datos) solo pueden ser leı́dos por los nodos autorizados a verlo y por ningún
otro nodo.
Integridad: garantiza que la información que viaja por la red no ha sido modificada durante
el trayecto del origen al destino.
41
4.1. Ataques
Autenticación: garantiza a un nodo la identidad de otro nodo participante de la red.
No Repudio: grantiza que el nodo que envió el mensaje no puede negar que lo hizo.
4.1.
Ataques
Los ataques en una red móvil se pueden clasificar de dos maneras: por su origen o por el grado
de participación del nodo atacante.
La clasificación 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 clasificación por el grado de participación del nodo atacante puede ser:
Activo: Se considera activo cuando un nodo emite señal o datos con el objetivo de dañar la
red.
Pasivo: Se considera pasivo cuando el nodo no coopera y simplemente escuchan. A los nodos
pasivos se los llama egoı́stas (selfish)
Dentro de cualquiera de las categorı́as anteriores podrı́an darse estos tipos de ataques:
Denegación de Servicio (DoS): Consiste es dejar el nodo fuera de la red
Interceptación Pasiva: Consiste en escuchar el medio (aire)
Interrupción del Flujo: Consiste en alterar o modificar el flujo de los datos sin cambiar las
rutas
Integridad de los datos: Modificación del contenido del mensaje
Ataque de Señalización: Modificación de los paquetes de control
4.1.1.
Ataques Externos
Los ataques externos [16, Sec. 5] en general son ataques de capa fı́sica y de enlace ya que
los protocolos de niveles superiores proveen autenticación. Los ataques de capa fı́sica son muy
difı́ciles de implementar por la naturaleza de la red.
Los ataques externos se pueden subdividir por el grado de participación del nodo agresor en
dos categorı́as: interceptación pasiva (pasive eavesdropping) e interferencia activa.
4.1.1.1.
Interceptación Pasiva
Esta técnica permite a los nodos agresores escuchar y recibir mensajes e información de
actualizaciones de las tablas de ruteo y de esta manera inferir una topologı́a de red, identidades
o cuales son los nodos que tienen más participación en la red.
42
Juan Manuel Caracoche - Tesis de grado Ingenierı́a Informática
Seguridad en Redes Móviles
4.1.1.2.
Interferencia Activa
El objetivo de esta técnica es causar una denegación de servicio (DoS) causando un bloqueo
del canal de comunicaciones o distorsionando la comunicación. 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, éste verá a la interferencia como una ruptura de enlace y el mecanismo
de mantenimiento de ruta eliminará el enlace con este nodo y no podrá recibir mensajes. Si se
utiliza un protocolo proactivo la reacción no es inmediata y si la ruta se cree que está rota,
eventualmente puede expirar su tiempo de vida y ser eliminada.
El ataque más serio de este tipo es uno llamado sleep deprivation torture que consiste en
interrumpir el perı́odo de ocio del dispositivo de capa fı́sica y producir un consumo excesivo
de la energı́a de la vı́ctima. Este tipo de ataques ya tiene muchos años de estudio y la tecnologı́a de espectro ensanchado que utilizan las comunicaciones inalámbricas son resistentes a las
interferencias, al ruido y a intrusos.
Cabe a aclarar que la interferencia no es solo a nivel fı́sico sino que el hecho de que un nodo
malicioso repita mensajes fuera de tiempo, mensajes incompletos hacen un uso excesivo de las
frecuencias de radio y producen un gasto de energı́a y a la vez saturan el nodo con información
inútil causando una denegación de servicio.
4.1.2.
Ataques Internos
Los ataques internos [16, Sec. 6] son los más serios y los más difı́ciles de defender ya que un
nodo interno a la red tiene la información necesaria para participar en la red. Los nodos internos
pueden tener comportamientos maliciosos en diferentes sentidos. Para identificar estos comportamientos, se pueden considerar las siguientes categorı́as: Nodo Fallido, Nodo Fallido Maligno,
Nodo egoı́sta y Nodo Malicioso.
4.1.2.1.
Nodo Fallido
Un nodo fallido es aquel nodo que simplemente no puede realizar una operación, esto puede ser
por varias razones, por ejemplo una falla de energı́a 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 crı́tico ya que este nodo corta la comunicación y puede ser que
el resto de los nodos no se hayan enterado de una rotura de una ruta por ejemplo, porque el
mensaje debı́a pasar por un nodo fallido. Este problema es aún más crı́tico cuando el nodo fallido
es parte de una ruta de emergencia o parte de una ruta segura. Estos fallos pueden crear cuellos
de botella y llegar a extremo de desacoplar la red.
4.1.2.2.
Nodo Fallido Maligno
El efecto provocado por un nodo fallido maligno es el mismo que el caso anterior pero en este
caso el nodo deja de operar de una manera consciente. Adicionalmente a este comportamiento
un nodo maligno puede enviar mensajes de rutas falsas o generar mensajes falsos para alterar
Juan Manuel Caracoche - Tesis de grado Ingenierı́a Informá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ón de servicio (DoS).
4.1.2.3.
Nodo egoı́sta
Un nodo egoı́sta explota los protocolos de ruteo para el bien propio. Es el caso de que un
nodo no quiera cooperar en la red para preservar sus recursos (energı́a) demostrando un comportamiento similar al de un nodo fallido. La acción tı́pica de un nodo egoı́sta es la de desechar
los paquetes recibidos. Este ataque es muy difı́cil de detectar ya que los protocolos no preveen el
control de donde se perdió un paquete (a excepción de DSR). Lo que hay que resaltar es que los
nodos egoı́stas no ponen en riesgo la integridad de la red inyectando información 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 continuación se muestran distintos tipos
de ataques que este tipo de nodos puede introducir:
Denegación de Servicio El ataque de denegación de servicio (Denial of Service -DoS-) induce a las vı́ctimas a caer en un ataque sleep deprivation torture que consiste en hacer realizar
operaciones innecesarias a las vı́ctimas haciendo agotar los recursos de energı́a. Este ataque lo
provocan enviando a sus vı́ctimas información válida o errónea en forma innecesaria. Los protocolos proactivos son muy sensibles a este ataque ya que cuando les llega una actualización de un
nodo deben actualizar todas sus rutas, por lo tanto si se les envı́a información necesaria estos
nodos consumirı́an muchos recursos actualizando sus tablas.
Este tipo de ataque también 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ón falsa de la topologı́a de la red. Muchos otros ataques pueden tener como
consecuencia este tipo de agresión.
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 flooding muy pobre, con lo cual información falsa puede ser reenviada a otro nodo.
Ataque a los protocolos de detección 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úa
contra el protocolo de detección de vecinos. El nodo agresor puede enviar a la vı́ctima un mensaje
con la información 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 podrı́a provocar
una alteración de los links en uno de los sentidos y el mismo protocolo pondrı́a a ese vecino en
44
Juan Manuel Caracoche - Tesis de grado Ingenierı́a Informática
Seguridad en Redes Móviles
su lista negra y no le enviarı́a ningún mensaje. De manera contraria un nodo malicioso podrı́a
hacer que la vı́ctima remueva un nodo de la lista negra haciéndose pasar por tal enviándole un
route-request con los datos de la cabecera del nodo que está en la lista negra.
Redirección de tráfico El ataque consiste en que un nodo puede hacerse pasar por otro y
ası́ modificar la integridad de la red haciendo pasar todas la rutas de la red por el nodo atacante.
Cuando un nodo de la red hace un route-request el nodo maligno puede responder que él es el
destino o que él tiene una ruta hacia el destino y de esta manera todo el tráfico pasará a través de
él y los mensajes para el destino real lo recibe él. A este caso particular del ataque de redirección
de tráfico se lo conoce como agujero negro.
Otra consecuencia de este ataque es que un nodo puede modificar las rutas para que todo
el tráfico vaya para un nodo y que éste caiga en un ataque de sleep deprivation. Este efecto se
puede acentuar haciendo que el nodo agresor envı́e al resto de los nodos un número de salto
pequeño hacia el destino y un número de secuencia más nuevo para asegurarse que todos los
nodos prefieran las rutas que pasan por el nodo vı́ctima.
Una variante de este ataque que es muy difı́cil de detectar es el ataque del túnel (wormhole
attack ) en el cual la información que llega a un nodo es “tuneleada” hacia otro nodo por un medio
directo más rápido. Si en un protocolo reactivo, el mensaje es “tuneleado” hacia las cercanı́as de
un nodo destino, éste llegará más rápido que cualquiera, por lo tanto el retorno de la ruta será a
través del túnel y como consecuencia de esto el nodo mal intencionado está dentro de la ruta
hacia ese destino. Para los protocolos proactivos ese ataque también es válido pero se sealiza el
“tuneleado” de los mensajes de detección de vecinos como se vió en el ataque anterior.
Ataque a los Números de Secuencia La mayorı́a de los protocolos utilizan números de
secuencia para prevenir ataques en los cuales se les reenvı́en mensajes viejos. Igualmente un
nodo malicioso puede explotar esta caracterı́stica enviando muchos mensajes con una dirección
de destino falsa y un número de secuencia muy alto, como consecuencia del ataque se produce
una denegación del servicio porque cualquier mensaje válido de otros nodos serán rechazados por
tener un número de secuencia viejo o duplicado.
Ataques a Protocolos Especı́ficos Existen distintos tipos de ataques para protocolos especı́ficos. Cuando un nodo malicioso integra una red, ya tiene el conocimiento de que protocolo
está presente en esa red y ası́ puede ejecutar un ataque especı́ficamente al protocolo presente.
De esta manera el ataque es mucho más efectivo. Por ejemplo para DSR el nodo atacante puede
inyectar tantas rutas con tantos próximos saltos como sea posible hacia un destino inexistente.
Luego el agresor envı́a un mensaje hacia el falso destino. En este punto se produce un ataque de
denegación de servicio, porque cada nodo intermedio va a intentar enviar a su próximo salto el
error de la ruta de los cuales esperará 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 máximo y no
va a intentar más.
Juan Manuel Caracoche - Tesis de grado Ingenierı́a Informá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ó a investigar como prevenir los ataques. En general se han investigado y
desarrollado más protocolos seguros basados en los protocolos de ruteo reactivos (DSR o AODV).
Dentro de la variedad de protocolos desarrollados, todos tienen en común 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 egoı́sta. Otra caracterı́stica de los protocolos actuales que
es se desarrollan en un ambiente controlado, es decir todos los integrantes de la red que deseen
comunicarse deben poder intercambiar algunos parámetros de inicialización (claves entre otros)
de antemano.
A continuación de describirán los protocolos seguros más populares.
4.2.1.
SRP - Secure Routing Protocol
SRP [23] fue concebido como una extensión para los protocolos DSR 2.3.2.2 y para IARP
parte del protocolo ZRP 2.3.3.1.
SRP garantiza la recolección correcta de la topologı́a de la red aunque se encuentre en presencia de un nodo malicioso. Este protocolo es fuerte ante ataques que intenten modificar 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ón de confianza puede ser inicializada, por ejemplo, si un nodo
conoce la clave pública del otro, luego por medio de algoritmos como puede ser Diffie-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 información que
reciba un nodo sea correcta. También 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úmero de secuencia de 32 bits(Query Secuence
Number, Qsec ), el cual es incrementado con cada pedido. Este número permite a T detectar
pedidos viejos y descartarlos. El número de secuencia se inicializa cuando se establece la SA.
Por cada pedido de ruta, S generará un número aleatorio de 32 bits (Query Identifier, QID )
que es utilizado por los nodos intermedios para identificar el pedido. QID es generado de manera
tal que sea imposible de predecir por un atacante.
Estos dos números, más un identificador de tipo son agregados en el encabezado de SRP.
Finalmente se genera el SRP MAC de 96 bits que es producto de la salida de aplicar HMAC [24]
utilizando como entrada la IP de destino, el paquete del protocolo original (Basic Routing Protocol
Packet) y la clave KS,T
46
Juan Manuel Caracoche - Tesis de grado Ingenierı́a Informática
Seguridad en Redes Móviles
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ón 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 , dirección origen y dirección destino
para insertarlos en una tabla (query table). Todos los pedidos que lleguen y se encuentren en esta
tabla son descartados, los demás serán retransmitidos para continuar el proceso de descubrimiento.
Los nodos intermedios también 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 fin 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 serán retransmitidos con baja prioridad o eventualmente no se
transmitirán.
Una vez que el nodo destino recibe la petición de ruta (RREQ), verifica la integridad y la
autenticidad del mismo calculando el HMAC y comparándolo con el del paquete recibido. Si el
paquete es válido, comienza el proceso de respuesta. El paquete de respuesta (RREP) es generado
utilizando la cabecera SRP del mismo modo que la generó el nodo S cuando generó el pedido.
EL nodo origen descartará todos aquellas respuestas que no se encuentren en su lista de pedidos
pendientes. Esto lo hace utilizando la dirección de origen, la de destino y los números QID y
Qsec .
La versión básica de SRP es vulnerable a ataques de envenenamiento de cache de rutas
(route cache poisoning) ya que nodos atacantes pueden generar información inválida y los nodos
intermedios que operan en modo promiscuo para mejorar la eficiencia del protocolo los reciben y
Juan Manuel Caracoche - Tesis de grado Ingenierı́a Informá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 extensión 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ón INRT
4.2.1.2.
Otras Vulnerabilidades
SRP no tiene una validación para los mensajes de mantenimiento de ruta, los paquetes de
error no son verificados. De todos modos, para minimizar este efecto, SRP genera los paquetes
de errores con un prefijo donde está la ruta completa. Con este prefijo el nodo S puede verificar
si el nodo que generó el mensaje de error es parte de la ruta. Lo que no se puede verificar es si el
mensaje es real, es decir un nodo intermedio puede decir que el enlace se rompió pero en realidad
está intacto.
SRP no tiene ninguna contramedida para el ataque del túnel (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ún algoritmo
de intercambio de claves, en este caso Diffie-Hellman. Otro aspecto es el uso de HMAC para
garantizar integridad y autenticación 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
criptografı́a simétrica 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ún nodo intermedio pueda remover algún nodo de
la lista del mensaje RREP o RREQ.
Como se comentaba en la introducción a los protocolos de ruteo seguros, ARIADNE necesita
algún método de intercambio de claves previo. Se deben intercambiar las claves entre el origen S
y el destino D (KS,D ).
ARIADNE provee una autenticación punto a punto del mensaje de ruteo usando autenticación
MAC y una clave compartida entre las dos partes. Para la autenticación de los paquetes broadcast
utiliza un protocolo de autenticación llamado TESLA [25].
48
Juan Manuel Caracoche - Tesis de grado Ingenierı́a Informática
Seguridad en Redes Móviles
ARIADNE previene la modificación y el armado de información de ruteo, previene el uso de
la impersonificación y en versiones avanzadas del ataque del túnel (wormhole attack ).
ARIADNE arma el paquete de solicitud de descubrimiento de ruta adicionándole siete campos
para proporcionar autenticación 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úmero 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
vacı́as.
Cuando un nodo A recibe un mensaje RREQ, del cual él no es el destino, busca en su tabla por
la tupla <origen,id> para determinar si este paquete no lo vió antes, si lo vió descarta el paquete.
También verifica que el intervalo de tiempo sea válido, si no lo es descarta el pedido. En caso
contrario, el nodo A modifica el pedido agregando su dirección 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á la clave TESLA KAi para computar el MAC, donde i es el ı́ndice para el intervalo
de tiempo especificado en la petición. Finalmente reenvı́a el mensaje.
Cuando el nodo destino recibe la petición, lo primero que hace es verificar la validez del
mensaje calculando si el hash es válido realizando el siguiente cálculo.
H[ηn , H[ηn−1 , H[..., H[η1 , M ACKSD (origen, destino, id, intervalo de tiempo)]...]]]
Donde ηi es la dirección del nodo en la posición 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 válido, arma el mensaje de respuesta el cual
será 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ó en el RREQ. El MAC destino es un MAC calculado sobre lista de MAC
utilizando la clave KDS y la lista de claves se inicializa vacı́a.
Cuando el nodo destino recibe la respuesta, verifica que cada clave en la lista de claves sea
válida, el MAC destino sea válido y cada uno de los MAC de la lista de MAC sean válidos. Si
todas las verificaciones son exitosas, se acepta el mensaje, en caso contrario se descarta.
ARIADNE también se proteje contra ataques de DoS causado por la inyección de múltiples
paquetes de RREQ. Los nodos pueden filtrar este tipo de ataques usando la cadenas de descubrimiento de ruta, el cual es un mecanismo para autenticar el proceso de descubrimiento.
Juan Manuel Caracoche - Tesis de grado Ingenierı́a Informá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 capı́tulo se presentaron cuales son los ataques tı́picos a los que debe enfrentarse
una red móvil. También se presentaron cuales son las cuestiones básicas que debe garantizar un
protocolo para que sea considerado seguros y finalmente se presentaron protocolos seguros. De los
protocolos desarrollados se indicó de cada uno cuales aspectos son provechosos para el desarrollo
de la tesis. Si bien los protocolos seguros descriptos al final de este capı́tulo son protocolos reactivos
y el objetivo de la tesis es trabajar con un protocolo proactivo como es el caso del OLSR, algunas
ideas de éstos fueron provechosas.
50
Juan Manuel Caracoche - Tesis de grado Ingenierı́a Informática
Capı́tulo 5
Redes Móviles Urbanas
El objetivo del presente capı́tulo es introducir el concepto de que es una Red Móvil
Urbana y cuales son los aspectos administrativos de este tipo de redes.
Las redes móviles tiene un uso potencial muy grande ya que los dispositivos de comunicación
masivos (celulares, PDAs, etc) cada vez están al alcance de más personas y ganan popularidad
dentro de la sociedad ya que en un solo dispositivo pueden reproducir contenidos multimedia,
hablar por teléfono y navegar por internet. Estos dispositivos en su mayorı́a cuentan con interfaces
de red inalámbricas las cuales les permiten interconectarse o conectarse a un punto de acceso
(Access Point).
Esta popularidad que van ganando los dispositivos móviles sumado a proyectos comunitarios
relacionados con armar redes inalámbricas metropolitanas hacen que cualquier persona pueda
estar conectada, a través de una LAN, con otra persona en el otro extremo de la ciudad donde
sin la ayuda de una red móvil serı́a imposible por razones inherentes a la naturaleza de las
conexiones y los dispositivos inalámbricos.
La tecnologı́a Wi-Fi (802.11) tiene como limitante para establecerse una comunicación wireless
la lı́nea de visión, es decir, los dos elementos a comunicarse no deben tener ningún obstáculo que
interfiera entre los dos extremos. Este limitante es el peor enemigo que tiene las redes urbanas
por las caracterı́sticas edilicias que presenta una ciudad. Viendo un caso práctico, una persona
quiere comunicarse con un vecino que está edificio de por medio, por más que las distancias sean
cortas, existen paredes que obstaculizan la comunicación directa entre estas dos personas.
Una red urbana debe combatir esa limitación y para ello se instalan nodos en posiciones
estratégicas que tengan lı́nea de visión entre sı́ y de esta manera extender la cobertura. En este
capı́tulo se verá como se conforma una red urbana, como nacen y como trabajan redes móviles
urbanas en distintas partes del mundo.
51
5.1. Proyectos Comunitarios Libres
5.1.
Proyectos Comunitarios Libres
La comodidad de las redes inalámbricas, sumado a la posibilidad de conectarse sin cables a
una velocidad razonable y el espı́ritu aventurero de los fanáticos de las comunicaciones llevaron
en primera medida a compartir una conexión con un vecino o con un amigo. Siendo esta primera
etapa satisfecha rápidamente, se ven con la necesidad de ir más allá y conectarse con puntos cada
vez más lejanos y con mayor cantidad de personas. Como existen varias personas con el mismo
espı́ritu aventurero, curioso y con ganas de aprender de comunicaciones o simplemente tienen
una colección de discos que quieren compartir con personas más allá de su cı́rculo de amistades
es que nacen las comunidades.
Las comunidades conforman una simbiosis entre sus miembros, cada uno necesita de otro para
poder cubrir más superficie con la red y es ası́ como nacen las redes urbanas, conformadas por
personas, sin fines de lucro con el único objetivo de cubrir cada vez más superficie para que cada
vez haya mas personas conectadas.
Teniendo una visión más macro de estos grupos, existen en diferentes ciudades del mundo
grupos de personas conformando comunidades de redes libres. Para dar algunos ejemplos, en
Latinoamérica una de las comunidades más 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 podrı́an enumerar infinitas
cantidades de comunidades de redes urbanas libres en todo el mundo.
5.1.1.
Buenos Aires Libre
Como se mencionó anteriormente Buenos Aires Libre (BAL) es una de las comunidades de
redes urbanas más grandes de Latinoamérica. Esta comunidad nace como parte de un proyecto
más ambicioso llamado Red Libre Argentina que tenı́a como objetivo conformar una red abierta
en todo el paı́s. 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 aplicación de esta tesis ya que soy miembro de
la misma desde hace 5 años y conozco su arquitectura y su topologı́a desde el comienzo.
La comunidad se organiza por grupos, actualmente existen dos grandes grupos, el grupo de
Organización y los que participan pasivamente en el proyecto o colaboran con un nodo pero no
son parte del grupo organizativo. Dentro del grupo de Organización existen varios subgrupos con
tareas especı́ficas como por ejemplo Direccionamiento IP, Mantenimiento del Site del proyecto,
Interrelación 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
Juan Manuel Caracoche - Tesis de grado Ingenierı́a Informática
Redes Móviles Urbanas
Una vez por mes se realiza una reunión del grupo de Organización donde se plantean inquietudes y se resuelven decisiones consensuadas para la administración de la comunidad. Por ejemplo
se determinan pautas para pertenecer al grupo de Organización, se decide el espı́ritu del proyecto,
se fomenta e incentiva la instalación de nuevos nodos entre otras tareas. En estas reuniones cada
grupo presenta nuevas ideas y se fijan objetivos para los diferentes grupos.
5.2.
Topologı́a
La topologı́a de las redes urbanas son muy diferentes ya que se adaptan a la geografı́a de la
ciudad o sencillamenta a donde es posible poner un nodo. Las redes en ciudades grandes donde
prevalecen los edificios de varios pisos es muy difı́cil lograr extenderlas ya que es necesario muchos
nodos ubicados en edificios altos para que puedan tener lı́nea de visión. La particularidad de una
red urbana es que un dispositivo se puede comunicar con otros a miles de metros sin tener linea
de visión y fuera del rango de cobertura del dispositivo utilizando nodos intermedios de la red.
Generalizando, las redes urbanas están conformadas por dos tipos de nodos: Nodo y Cliente.
Un nodo es en general un punto fijo ubicado en un punto estratégico que tiene lı́nea de visión con
otro y son los encargados de extender la red conformando el backbone de la misma. Los Clientes
son cualquier nodo (móvil o fijo) que se conecta en general a un nodo. La figura 5.1 muestra una
topologı́a de red tı́pica de una red urbana.
Hasta ahora se desarrolló 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 mayorı́a de las redes urbanas
ya que los protocolos de redes móviles no han sido estandarizados y no se distribuyen con los
drivers de las placas de red o con los sistemas operativos. Esta forma de conexión es la única manera que existe hasta el momento para los clientes. Sin embargo, los nodos cuentan con hardware
especı́fico y Sistemas Operativos no convencionales y sı́ implementan protocolos de redes móviles
con lo cual cada nodo pertenece a una red autoconfigurada por estos.
La integración de los clientes como participantes de la red móvil es, por llamarlo de alguna
manera, experimental, ya que las implementaciones de los protocolos están en pleno desarrollo y
solo algunos pocos se aventuran a experimentar.
Cuando los protocolos sean estandarizados y se hagan más populares, todos los clientes van
a ser parte de una red móvil. Esto va a permitir que un cliente pueda acceder a la red no solo
a través de un nodo sino a través de otro cliente. En la Figura 5.1 se muestra una topologı́a de
una Red Móvil 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 petición será ruteada
a través del Cliente 8, 7, 6 hasta llegar al Nodo 3, el cual no tiene conexión a Internet, pero
conoce como llegar a ella, por lo tanto rutea la petición hacia el Nodo 2, y este hacia el Nodo
1 donde finalmente sale a Internet. Cabe destacar que el Cliente 9 sin la colaboración del resto
de los intermedios por los que pasó el pedido hubiera sido imposible llegar al Nodo 1 el cual
geográficamente podrı́a estar a miles de metros.
Juan Manuel Caracoche - Tesis de grado Ingenierı́a Informática
53
5.2.1. Direccionamiento IP
Figura 5.1: Diagrama de una red Móvil Urbana
5.2.1.
Direccionamiento IP
En una red IP, es fundamental tener una dirección para poder comunicarse. En las redes
móviles la asignación de direcciones IP es parte del desafı́o de las funcionalidades que puede
brindar el protocolo de ruteo. En general los protocolos no brindan la capacidad de asignación
de IP sino que se asume que el dispositivo cuanta con una. Algunas implementaciones tienen la
caracterı́stica de buscar que no hayan direcciones repetidas dentro de la red en el momento que
un nodo se está asociando.
En las redes urbanas y en especial en BAL, las direcciones IP están distribuı́das en dos rangos,
un rango para nodos y otro para clientes. Existe una entidad llamada freenetworks 7 , en donde
cada comunidad tiene asignado un rango de IP privadas. Esto garantiza que las redes comunitarias
registradas no tienen direcciones duplicadas. Buenos Aires Libre tiene los rangos asignados por
freenetworks.
A su vez, BAL asigna una subred a cada uno de los nodos para proveer direcciones IP a los
clientes (servicio de DHCP en el nodo) y para comunicación con otros nodos. Con esta asignación
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 fijo) es la manera de
asignar IPs, en un futuro cuando toda la red sea idealmente una red móvil se utilizará la técnica
de asignación de ip estandarizada para este tipo de redes. Las pruebas experimentales se hacen
asignando cualquier IP teniendo la precaución que no sea una dirección repetida.
7 http://www.freenetworks.org
54
Juan Manuel Caracoche - Tesis de grado Ingenierı́a Informática
Redes Móviles Urbanas
5.3.
Protocolos de Ruteos
Como se vió en la sección 2.2 existen varios protocolos para rutear paquetes en una red móvil.
Tomar la decisión de qué protocolo usar queda fundamentalmente sujeto a qué implementaciones
hay disponibles. Existen muy pocos protocolos implementados, entre ellos OLSR y AODV. La
implementación de OLSR es actualmente la más 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ón de los nodos con olsrd.
Las pruebas que se están llevando a cabo con clientes móviles 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 están compuestas por muchos nodos,
con lo cual pueden utilizar OLSR como único protocolo.
En un futuro cuando se masifique la integración de los protocolos de redes móviles en los
dispositivos, el número de integrantes crecerá en forma desmedida y OLSR no podrá ser utilizado
como único protocolo. OLSR es un protocolo que tiene como desventaja que en redes muy grandes
se genera mucho overhead producto de la mantención de todas las rutas. Cuando esto ocurra
seguramente se utilizarán protocolos hı́bridos para minimizar el overhead de la red.
5.4.
Servicios
El objetivo de las redes urbanas es interconectar dispositivos y conformar la red. Sobre 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 fin proveer Internet a bajo costo ni vender ningún tipo
de servicio.
Uno de los proyectos comerciales más importantes relacionado con las redes urbanas se llama
FON 9 en cual permite a los clientes de FON conectarse a Internet de manera inalámbrica en
cualquier ciudad del mundo donde exista FON.
5.5.
Administración 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ño de su nodo es responsable del mismo como ası́ de los daños que éste
pudiese causar. La administración 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ón y debe dar servicio con un rango de IPs asignado como ası́ también
8 http://www.olrd.org
9 http://www.fon.com
Juan Manuel Caracoche - Tesis de grado Ingenierı́a Informática
55
5.6. Resumen
existe una convención de nombres para el ESSID del nodo. Cada propietario del nodo puede
prestar el servicio que quiera siempre y cuando éste no esté en contra del espı́ritu del proyecto.
En definitiva cualquiera puede tener un nodo pero para pertenecer a la red BAL debe ser
aprobado por el grupo de Organización y esto implica la asignación de los rangos de IP y el
nombre para el ESSID del nodo.
5.6.
Resumen
En este capı́tulo se hizo una explicación acerca de las redes urbanas, que caracterı́sticas
topológicas presentan, cuales son los recursos utilizados para sortear los obstáculos puestos por la
geografı́a de la ciudad y las limitantes del medio de transmisión. Se presentaron algunos proyectos
libres que tienen por objetivo conformar una red móvil urbana libre y otros proyectos comerciales.
56
Juan Manuel Caracoche - Tesis de grado Ingenierı́a Informática
Capı́tulo 6
Protocolo OLSR
El objetivo del presente capı́tulo es detallar el funcionamiento del protocolo OLSR
y enumerar algunas vulnerabilidades del mismo.
El el capı́tulo 2 se presentó el protocolo OLSR como un protocolo proactivo o basado en
tablas, es decir todos los nodos de la red conocen la manera de llegar a todos los miembros de la
misma.
En este capı́tulo se detallará el funcionamiento del protocolo como también se identificarán
los puntos en los cuales es necesario aplicar seguridad para mantener la integridad de la red y
sus integrantes.
6.1.
Introducción
OLSR es un protocolo proactivo [5, Sec. 1.3] para redes móviles ad-hoc definido 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 flooding para la distribución de los
paquetes de control a través de nodos especı́ficos llamados MPRs (Multi Points Relays), los
cuales son los únicos que pueden reenviarlos. De esta manera se optimiza la distribución de los
paquetes evitando retransmisiones. Los MPRs tienen la caracterı́stica de tener un enlace sólido
con su vecino haciendo que la comunicación sea lo suficientemente estable.
El protocolo OLSR no necesita ninguna modificación del stack de protocolos ya que se ubica
por encima de este modificando las tablas de ruteo del sistema.
6.2.
Terminologı́a Propia de OLSR
Para entender el desarrollo de las próximas secciones es necesario introducir algunos de los
términos 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ás de una interfase, cada una con una dirección IP distinta.
Dirección Principal: La dirección principal de un nodo es utilizada como dirección
originadora del mensaje. Un nodo con múltiples interfases OLSR debe elegir una
única IP como dirección 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 simétrico: Es cuando el par de interfaces de distintos nodos pueden escucharse
una con otra.
link asimétrico: Es cuando el enlace de dos interfaces OLSR se da en un solo sentido.
Vecino simétrico: Es un nodo vecino con el cual al menos una interfase OLSR tiene
un enlace simétrico.
Vecino simétrico de 2-Salto: Es un vecino simétrico de un vecino simétrico del nodo
X.
6.3.
Tablas del Protocolo
Como se explicó en la Sección 2.3.1, OLSR es un protocolo proactivo o basado en tablas, es
decir toda la información necesaria para su funcionamiento es almacenada en tablas. Las tablas
definidas en la RFC, varı́an con las tablas de la implementación del protocolo, pero los datos
almacenados en ambas estructuras de tablas son los mismos. Esta simplificación de tablas es
para hacer más rápido 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
dirección principal, que será la utilizada para identificar al nodo.
I iface addr: Dirección de una de las interfaces de un nodo.
I main addr: Dirección principal de un nodo.
I time: Tiempo de expiración de la tupla.
Link Set: En esta tabla se almacena el estado de los enlaces con los vecinos.
58
Juan Manuel Caracoche - Tesis de grado Ingenierı́a Informática
Protocolo OLSR
L local iface addr: Dirección de la interfase local del nodo (un extremo del enlace).
L neighbor iface addr: Dirección de la interfase del nodo vecino (el otro extremo
del enlace).
L SYM time: Es el tiempo que se considera al enlace como simétrico.
L ASYM time: Es el tiempo hasta que se considera como escuchada a la interfase del
vecino.
L time: Tiempo de expiración de la tupla.
Neighbor Set: Esta tabla tiene por objetivo almacenar el estado de los vecinos, identificándolo solo por la interfaz principal.
N neighbor main addr: Dirección principal del nodo vecino.
N status: Especifica si el nodo está en estado SYM=enlace simétrico o NOT SYM=enlace
no simétrico.
N willigness: Es un entero entre 0 y 7 y especifica la confianza que se le tiene al
nodo vecino para llevar el tráfico.
2-hop Neighbor Set: Se almacena el estado de los vecinos de dos saltos de distancia, identificándolo por la dirección de la interfaz principal.
N neighbor main addr: Dirección principal del nodo vecino.
N 2hp addr: Dirección principal del nodo vecino de 2-Saltos que tiene enlace simétrico
con N neighbor addr.
N time: Tiempo de expiración 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ón principal del nodo.
MS time: Tiempo de expiración de la tupla.
Topology Information: Conformada por las tuplas {T dest addr, T last addr, T seq,
T time}
T dest addr: Dirección principal del nodo destino que es alcanzado en un salto por
el nodo con dirección principal T last addr.
T last addr: Es MPR de T dest addr.
T seq: Número de secuencia.
T time: Tiempo de expiración de la tupla.
Host and Network Asociation Base: Conformada por las tuplas {A gateway addr,
A network addr, A netmask, A time}
A
A
A
A
gateway addr: Dirección de la interfase OLSR del gataway.
network addr: Dirección de red.
netmask: Máscara de la red.
time: Tiempo de expiración de la tupla.
Juan Manuel Caracoche - Tesis de grado Ingenierı́a Informática
59
6.4. ¿Cómo Funciona?
6.4.
¿Cómo Funciona?
OLSR es un protocolo independiente del stack TCP/UDP, es decir utiliza el stack pero no
necesita información de la capas inferiores para poder operar. El objetivo del protocolo es modificar las tablas de ruteo del Sistema Operativo para poder llegar a todos los nodos de la red, para
ello necesita recolectar información de su entorno. Esa información es relevada con el intercambio
de mensajes con los vecinos. La comunicación 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 finalidades distintas. Los mensajes
de HELLO son mensajes para relevar el estado de los vecinos de primer y segundo nivel, los
mensajes de TC son para informar el estado de los vı́nculos más allá de los lı́mites del nodo
y por último los mensajes MID por los cuáles 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 detección de los vecinos, segunda etapa la selección de los MPR, tercera etapa propagación
de la información de la topologia de la red, cuarta etapa armado de las rutas y por ú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] define un formato de paquete para todos los mensajes del protocolo.
Para cada tipo de mensaje lo que varı́a es el contenido del campo MESSAGE que se muestra el la
Figura 6.2.
Los campos del mensaje de OLSR son los siguientes:
Packet Length: Es el tamaño en bytes del mensaje.
Packet Sequence Number: Número de secuencia, el cual es incrementado en uno
con el envı́o de cada paquete.
Message Type: Indica que tipo de mensaje se encontrará en el campo MESSAGE.
Vtime: Este campo indica por cuanto tiempo después de la recepción debe considerar
la información como válida.
Message Size: Indica el tamaño del mensaje en bytes. Cuenta desde el campo
Message Type hasta el comienzo de otro Mesage Type.
Originator Address: Es la dirección principal del nodo que generó el mensaje.
Time to Live: Contiene el máximo número de veces que el mensaje debe ser retransmitido (cantidad de saltos que debe recorrer).
Hop Count: Número de saltos por los que el paquete ha pasado.
60
Juan Manuel Caracoche - Tesis de grado Ingenierı́a Informática
Protocolo OLSR
Figura 6.1: Etapas del protocolo OLSR
Message Count Sequence: Número de secuencia único para cada mensaje. Este
número se incrementa en uno con el envı́o de cada mensaje.
6.4.2.
Etapa 1: Censado y Descubrimiento de Vecinos
En esta etapa del protocolo es donde el nodo analiza su entorno en busca de vecinos y el tipo
de vı́nculo por el cual los alcanza. Como se comentó 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 Sección 6.4.1 donde es
incluı́do en el campo MESSAGE del mismo con Message Type=HELLO MESSAGE. La estructura del
Juan Manuel Caracoche - Tesis de grado Ingenierı́a Informá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 Sequence Number
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
:
MESSAGE
:
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
:
:
(etc.)
Figura 6.2: Formato del paquete de OLSR
mensaje de HELLO que se muestra en la Figura 6.4 contiene los siguientes campos:
Reserved: Campo completado por 0000000000000000.
Htime: Indica el tiempo de emisión de los mensajes de HELLO del nodo que lo origina.
Willingness: Es una valor del 0 al 7 que indica la confiabilidad de un nodo para
retransmitir un mensaje. Por ejemplo un nodo con valor WILL NEVER nunca va a
ser elegido como MPR, un nodo con WILL ALLWAYS, siempre va a ser elegido como
MPR. El valor por defecto es WILL DEFAULT.
Link Code: Este campo indica el tipo de vı́nculo que hay entre la interfase de quien
envı́a el mensaje con el listado de interfaces de los vecinos. Este campo es de 8 bit
de los cuales solo se interpretan los códigos menores o iguales a 15 como el par de
códigos 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ódigo del enlace
Los códigos de los posibles vı́nculos se definen como:
62
Juan Manuel Caracoche - Tesis de grado Ingenierı́a Informática
Protocolo OLSR
UNSPEC LINK: No se especifica información acerca del enlace.
ASYM LINK: Link asimétrico.
SYM LINK: Link simétrico.
LOST LINK: Pérdida del vı́nculo.
Los códigos de los tipos de vecinos se definen como:
SYM NEIGH: Indica que al menos una de la interfaces del vecino tiene un
enlace simétrico con el nodo.
MPR NEIGH: Indica que al menos una de la interfaces del vecino tiene un
enlace simétrico con en nodo y a su vez el vecino fué seleccionado como
MPR por el originador del mensaje.
NOT NEIGH: Todavı́a no se tiene un vı́nculo simétrico con el vecino.
Link Message Size: Indica el tamaño del mensaje en bytes. Cuenta desde el campo
Link Code hasta el comienzo de otro Link Code.
Neighbor Interfase: La dirección 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
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Neighbor Interfase Address
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
:
. . .
:
:
:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Link Code
|
Reserved
|
Link Message Size
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Neighbor Interfase Address
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Neighbor Interfase Address
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
:
:
:
:
(etc.)
Figura 6.4: Formato del mensaje de HELLO
6.4.2.2.
Mensaje MID
Cada nodo integrante de la red puede tener más de una interfase OLSR, pero solo una dirección
principal, por eso es que existe un mensaje que informa a los nodos que un determinado nodo
cuenta con determinadas interfaces OLSR y envı́a las direcciones de las mismas.
Juan Manuel Caracoche - Tesis de grado Ingenierı́a Informática
63
6.4.2. Etapa 1: Censado y Descubrimiento de Vecinos
Este mensaje es parte del paquete de OLSR donde es incluı́do en el campo MESSAGE del mismo.
La estructura del mensaje MID que se muestra en la Figura 6.5 donde OLSR Interfase Address
es la dirección de cada una de la interfaces. En el header del mensaje OLSR se indica que la IP
que envı́a el mensaje es la dirección principal del nodo, por lo tanto el nodo que recibe el mensaje
asocia esa dirección 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á 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ógica de cómo se van intercambiando los mensajes y cómo están las tablas
de cada nodo en cada uno de los instantes. Para una mejor interpretación y claridad en la figura,
las tablas Neighbor Set, 2-hop Neighbor Set y MPR Set son agrupadas en una sola tabla
llamada Neightbor Table.
En la Figura 6.6 en el instante t1 se puede ver que el nodo A envı́a el mensaje de HELLO
vacı́o 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, recibió el mensaje por la interfase A, es un vı́nculo
asimétrico (notar que pone como valor tiempo de vida del enlace simétrico con un valor vencido,
es decir t2 -1). En la tabla de vecinos agrega al nodo A indicando que es un vecino asimétrico y
no es MPR ni vecino de segundo salto.
En ese mismo instante, B envı́a un mensaje de HELLO informando el estado de sus enlaces
clasificados por tipo y un mensaje MID diciendo que solo tiene la interfase con la dirección B.
En la Figura 6.7 en el instante t3, el nodo A recibe el mensaje de B y ve que su dirección es
parte del mensaje recibido, por lo tanto agrega una entrada en la tabla de enlaces indicando que
el enlace con B es simétrico. Agrega una entrada en la tabla de interfaces con la interfase de B.
Agregó en la tabla de vecinos al nodo B como simétrico y al nodo C como vecino de 2-Saltos ya
que éste tiene enlace simétrico con B. El nodo C no actualiza la información del nodo A porque
el nodo B aún tiene un enlace asimétrico con A y un vecino de 2-Saltos es considerado cuando
hay un enlace simétrico entre el vecino y el vecino de dos saltos de distancia.
En ese mismo instante A envı́a un mensaje de HELLO con la información de sus enlaces.
64
Juan Manuel Caracoche - Tesis de grado Ingenierı́a Informá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 dirección está listada y actualiza
la entrada en tabla de enlaces indicando que el tiempo del enlace simétrico es un tiempo válido.
En la tabla de vecino actualiza la entrada de A indicando que es un vecino simétrico.
En ese instante B envı́a un mensaje de HELLO.
En el instante t5 el nodo C se entera que existe un enlace simétrico 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ón de los MPRs
OLSR mejora el mecanismo de flooding de otros algoritmos similares con la elección 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 través de ellos pueda llegar a todos los vecinos de dos saltos de distancia
(vecinos 2-Saltos).
Para la elección de los MPRs, el RFC [5, Sec. 8.3.1] define una heurı́stica, la cual debe ser
aplicada por cada interfase OLSR del nodo. El conjunto de MPRs de un nodo es la unión de los
Juan Manuel Caracoche - Tesis de grado Ingenierı́a Informática
65
6.4.3. Etapa 2: Elección de los MPRs
Figura 6.7: Censado y Descubrimiento de Vecinos - Parte 1
MPRs encontrados para cada interfase.
Para la definición de la heurı́stica es necesario definir algunos términos:
Vecino de una Interfase: Vecino que tiene un enlace con el nodo local a través 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 través 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álculo del MPR (nodo local)
66
Juan Manuel Caracoche - Tesis de grado Ingenierı́a Informática
Protocolo OLSR
Figura 6.8: Multipoint Relays
Todos los vecinos simétricos: todos los nodos que tengan un enlace
simétrico en alguna de la interfaces.
D(y): El grado del nodo y (donde y es miembro de N ), está definido por la
cantidad de vecinos simétricos que tenga el nodo y (en todas sus interfaces),
excluyendo todos los miembros de N y el nodo que está realizando el
cálculo.
La heurı́stica de selección 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ás se seleccionarán 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úmero 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últiples nodos, se va a elegir aquel nodo con mayor
(D(y)). En caso que los criterios anteriores no elijan un único nodo se seleccionará de
manera aleatoria.
Ejemplo: Este ejemplo mostrará como se realiza la elección de los MPRs para el nodo O
donde todos los nodos tienen willigness igual a WILL DEFAULT. En la figura 6.9(a) se ve al nodo O
con la distribución 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 finalizar 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óximo paso es ejecutar la segunda fase donde selecciona de los nodos de Nivel 1 aquellos
que cubran más cantidad de nodos de Nivel 2 hasta cubrir todos los de Nivel 2. Para ello realiza
Juan Manuel Caracoche - Tesis de grado Ingenierı́a Informática
67
6.4.4. Etapa 3: Mantenimiento de la Topologı́a
una iteración donde elige como MPR un nodo que cumpla con M P R2 (O) = {maxw∈N (O) |
N 2(O)∩N (w) |} como se ve en la Figura 6.10(a) y elimina del conjunto de nodos para la próxima
iteración el MPR seleccionado y los nodos de Nivel 2 alcanzables por el mismo (Figura 6.10(b)).
Notar que en el momento de elección 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ón de los nodos de Nivel 1 que tienen vecinos aislados
(a) Distribución de vecinos:
Figura 6.9: Fase 1 : Selección de MPRs que cubren nodos aislados del Nivel2.
(a) Primera iteración de la segunda fase
(b) Segunda iteración de la segunda fase
Figura 6.10: Fase 2: Se completa la selección de MPRs.
El conjunto de MPRs son recalculados cada vez que hay algún cambio en los enlaces con los
vecinos.
Cuando un nodo recibe un mensaje de HELLO donde ve que el vecino lo seleccionó a él como
MPR (tipo de vecino igual a MPR NEIGH), éste agrega la dirección principal del nodo generador
del mensaje en la tabla de MPR Selector. Por medio de esa tabla un nodo pueda saber quien lo
eligió a él como MPR.
6.4.4.
Etapa 3: Mantenimiento de la Topologı́a
OLSR por ser un protocolo proactivo, debe conocer las rutas hacia todos los destinos de la
red, para ello debe conocer cual es la topologı́a de la misma. Como el dominio de cada nodo
68
Juan Manuel Caracoche - Tesis de grado Ingenierı́a Informática
Protocolo OLSR
es conocer la información de los nodos hasta dos saltos de distancia, necesita alguna manera de
conocer la topologı́a de la red más a allá de ese lı́mite. OLSR implementa un sistema de mensajes
para informar a los nodos la topologı́a de la red y los cambios que se produzcan. Para transmitir
esta información 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úmero de secuencia para el conjunto de enlaces informados. Este número cambia cada vez que un enlace es agregado
o removido del conjunto.
Advertized Neighbor Main Address: Es la dirección 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ón de los mensajes TC
Para poder diseminar por la red y que cada nodo pueda completar las tablas de topologı́a
es necesario que cada nodo que haya sido seleccionado como MPR genere un mensaje TC y lo
transmita en forma de broadcast. Cada nodo debe diseminar al menos el conjunto de enlaces con
los nodos que lo eligieron como MPR, o sea los enlaces con su MPR Selector.
En el caso de que la cantidad de enlaces a informar sea mayor a la capacidad del mensaje, se
deberán enviar tantos mensajes como sea necesario hasta informarlos todos.
Cuando un nodo recibe un mensaje TC realiza los siguientes pasos:
1. Si la interfase del que envı́a el mensaje no está entre los vecinos simétricos de un salto de
distancia, se descarta el mensaje.
2. Si existe alguna tupla en la tabla de topologı́a donde T last addr sea igual a la dirección
de origen del mensaje y exista un T seq mayor a ANSN, el mensaje se descarta. Es el caso
de un mensaje viejo.
Juan Manuel Caracoche - Tesis de grado Ingenierı́a Informática
69
6.4.5. Etapa 4: Formación de las Rutas
3. Todas las tuplas donde T last addr sea igual a la dirección 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 topologı́a donde T dest addr sea igual a las
direcciones informadas en el mensaje y T last addr sea igual a la dirección 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 topologı́a, son
agregadas.
6.4.5.
Etapa 4: Formación 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 información recolectada en la
tabla de enlaces y en la tabla de topologı́a. Por esa razón es que cualquier alteración en dichas
tablas provocan un cálculo 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ón principal de un nodo que se espera que esté a R dist saltos
del nodo actual, R next addr es un vecino que tiene un enlace simétrico con el nodo actual y es
el próximo salto hacia el destino R dest addr y ese vecino lo alcanza a través de la interfase local
R iface addr.
Para construir una ruta, se utiliza el algoritmo de camino más corto (Shortest Path Algorithm.
Para la construcción 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 simétricos
3. Por cada nodo perteneciente a los vecinos de 2-Saltos se crea una entrada indicando
R
R
R
R
R
R
dest addr=dirección 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 más entradas para agregar.
70
Juan Manuel Caracoche - Tesis de grado Ingenierı́a Informática
Protocolo OLSR
Para cada entrada de la tabla de topologı́a, 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 asociación con varias interfaces) y no exista una entrada para cada asociación 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 automáticamente cada vez que
se altera un enlace. La alteración de un enlace puede ser que se haya agregado un nuevo vecino
o que alguna de las entradas de las tablas expiró con lo cual es necesario recalcular la tabla de
ruteo.
Por esta razón siempre que haya una tabla calculada, todas las entradas son válidas.
6.4.7.
Comunicación con Otras Redes
El protocolo OLSR fue diseñado para que los nodos de la red no solo se comuniquen entre
ellos, sino también da la posibilidad de poder comunicarse con otras redes. Para lograr esto, el
protocolo envı́a mensajes llamados HNA.
6.4.7.1.
Mensaje HNA
El mensaje HNA es enviado como MESSAGE en el paquete general de OLSR definido en la Sección 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ón de la red asociada
Netmask: Mascara para la red asociada.
Juan Manuel Caracoche - Tesis de grado Ingenierı́a Informá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ón 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
asociación de nodos y redes con A gateway addr igual a la dirección principal de donde provino
el mensaje y con la dirección de la red y la máscara que vienen en el mensaje y se le coloca un
tiempo de expiración a la tupla.
Estas nuevas rutas hacen que la tabla de ruteo las deba incluir. Por lo tanto, al procedimiento
de actualización de la tabla de ruteo descripto en la Sección 6.4.6 se le debe agregar que para
cada una de las entradas de la tabla de asociación 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 especificadas 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.
Confidencialidad
OLSR envı́a periódicamente mensajes con información de la topologı́a de la red, esa información puede ser usada por un atacante y modificar la topologı́a de la red. El RFC de OLSR no
72
Juan Manuel Caracoche - Tesis de grado Ingenierı́a Informática
Protocolo OLSR
define ninguna alternativa para garantizar la confidencialidad de los mensajes de control. Solo
propone utilizar mecanismos de encriptación de clave compartida o usar PGP sin brindar detalles
de la forma de su implementación.
6.5.2.
Integridad
En OLSR cada nodo inyecta en la red información de la topologı́a a través de los mensajes de
HELLO y TC. Por ser el medio de propagación de los mensaje el aire, es un medio no controlado
y cualquier nodo podrı́a enviar información inválida con lo cual se compromete la integridad de
la red. Por lo tanto, algún mecanismo de autenticación debe ser implementado pero el RFC [5] no
indica con qué algoritmo, ni de que forma, sólo recomienda el uso de autenticación 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 haciéndose pasar por otro nodo
5. Un nodo reenvı́a mensajes de control alterados
6. Un nodo no reenvı́a un mensaje de control
7. Un nodo no selecciona su MPR correctamente
8. Un nodo replica mensajes de control grabados de otro nodo
La autenticación previene alguna de estas situaciones pero no todas. Para prevenir el punto
8 es necesario implementar algún mecanismo de información temporal para que un nodo pueda
identificar claramente los mensajes viejos.
En general los paquetes necesarios para la autenticación, pueden ser enviados dentro del
paquete genérico de OLSR como un tipo de mensaje distinto. De esta manera se podrı́a 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ón
de la topologı́a de la misma. Un atacante puede usar estos mensajes y modificarlos para beneficio
propio.
Es necesario que estos mensajes sean encriptados y autenticados para garantizar confidencialidad e integridad de los mensajes.
Aplicando seguridad sobre estos mensajes no garantiza que la red va a ser segura ya que nodos
participantes de la red pueden causar intencionalmente o no ataques, pero eliminarı́a muchos
posibles atacantes externos.
Juan Manuel Caracoche - Tesis de grado Ingenierı́a Informática
73
6.6. Vulnerabilidades
6.6.
Vulnerabilidades
OLSR por ser un protocolo que corre sobre el stack TCP/UDP, tiene las vulnerabilidades
intrı́nsecas con la tecnologı́a 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 fı́sica y MAC,
generando interferencias sobre el canal y saturando a la vı́ctima con mensajes. Este tipo de
ataques no son tenidos en cuenta por los protocolos ya que es tarea de las capas inferiores mitigar
estas amenazas.
En OLSR cada nodo tiene dos responsabilidades fundamentales. La primera es que cada nodo
debe generar la información 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 alteración de
estas responsabilidades pueden terminar amenazando la integridad de la red.
(a) El nodo O envı́a un mensaje de HELLO pretendiendo ser 3
(b) El nodo O envı́a un mensaje de HELLO anunciado un link falso con 1
Figura 6.13: Generación incorrecta de mensajes HELLO
Algunas de las vulnerabilidades presentes en OLSR [20, Sec. IV] son:
A. Generación Incorrecta de Mensajes de Control
a) Generación 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 través
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 último salto hacia 3. Esto genera conflictos en las rutas
hacia 3 y podrı́a dejar al nodo con pérdida de conexión.
Otro ataque con esta modalidad es la modificación de enlaces [15, Sec. III.A] que tiene
un nodo (Figura 6.13(b)). En este caso el nodo O envı́a 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 reenvı́ados a través de
los MPRs nunca llegue a 1.
b) Generación incorrecta de mensajes TC [15, Sec. III.B]: La generación de mensajes TC
con dirección de origen incorrecta puede generar información errónea referente a la re74
Juan Manuel Caracoche - Tesis de grado Ingenierı́a Informática
Protocolo OLSR
Figura 6.14: Generación incorrecta de mensajes TC
lación de los vecinos (Figura 6.14). El nodo malicioso O envı́a un mensaje TC en lugar
del nodo 3 informando que el nodo 1 es su vecino. El nodo 4 concluye de manera errónea
que 3 y 1 son vecinos. La generación de mensajes TC con información de enlaces falsos
tiene las mismas consecuencias.
c) Generación incorrecta de mensajes MID/HNA: Un nodo podrı́a enviar mensajes informando que tiene determinada interfase emitiendo el mensaje con una dirección de
origen perteneciente a otro nodo. Este ataque hace que los nodos que reciben el paquete
no puedan alcanzar al nodo real a través de la interfase que envió el nodo malo ya que
esa interfase no existe.
d ) Ataque a los números de secuencia: Un nodo malicioso podrı́a escuchar los mensajes TC
de un nodo A y almacenar el ANSN (Advertised Neighbor Sequence Number ) del mensaje,
luego envı́a mensajes falsificando la dirección de origen con ANSN mucho mayores que el
almacenado. Según el protocolo, los nodos ignorarán los mensajes con ANSN menores al
último recibido, por lo tanto los mensajes de A serán descartados porque serán tomados
como viejos.
B. Reenvı́o Incorrecto de Mensajes de Control
a) Ataque del Agujero Negro: Este ataque se produce cuando un nodo no reenvı́a los mensajes como lo requiere el protocolo, de este modo se disminuye la información de los
enlaces disponibles en la red. Si los mensajes TC no son reenviados, la red comienza a
tener problemas de conectividad y hasta podrı́a llegar a dividirse. Si no se reenvı́an los
mensajes HNA, se podrı́a perder el acceso hacia otras redes.
b) Ataque por Reenvı́o de Mensajes: Un nodo atacante podrı́a grabar todos los mensajes
que pasaron por él durante un determinado perı́odo y luego más tarde reinyectarlos en
la red modificando 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úmero ANSN grande para que sean aceptados por los nodos, causando de esta manera
un ataque de número de secuencia.
c) Ataque del túnel ( wormhole attack) [18, Sec. 4]: Este ataque tiene mucho impacto en la
red. Consiste en grabar el tráfico en un sector de la red y reproducirlo tal cual en otra
Juan Manuel Caracoche - Tesis de grado Ingenierı́a Informática
75
6.6. Vulnerabilidades
(a) Túnel creado por O entre 3 y 4
(b) Túnel creado por O y O0 (cómplices) entre
3y4
Figura 6.15: Ataque por túnel (Wormhole)
región de la misma. Se puede generar un enlace artificial entre el nodo 3 y el 4 a través
de un nodo atacante (Figura 6.15(a)) o si un nodo agresor tiene un cómplice y puede
generar un túnel fuera de la red y conectarse a una región más lejana (Figura 6.15(b)).
El agresor puede explotar este ataque cuando los nodos 3 y 4 hayan intercambiado suficientes mensajes de HELLO a través del túnel como para establecer un enlace simétrico.
Mientras el enlace no sea simétrico, los mensajes TC/MID/HNA son descartados. Con
el enlace simétrico establecido, todos los paquetes que vayan de un extremo al otro de la
red van a ser enviados a través del túnel porque se va a creer que es la ruta más corta y
el tráfico va a pasar todo por el nodo atacante.
d ) Ataque al ( MPR-Flooding): Una de las primeras reglas de transmisión enunciada en la
especificación de OLSR es que durante el proceso de flooding de los MPRs, los mensajes
recibidos son verificados si provienen de un nodo dentro del MPR Selector del nodo y los
mensajes iguales recibidos posteriormente son descartados. Por ejemplo un nodo A envı́a
un mensaje B y X (nodo malicioso), donde B es MPR de A y X no el MPR. X reenvı́a
(sin tener que hacerlo según la especificación) el mensaje a C, luego B tiene como MPR
a C y reenvı́a el mensaje a A. Ese mensaje es descartado porque el mismo mensaje de
lo envió X con lo cual resulta que se interrumpe el flujo del paquete (Figura Bd ).
Figura 6.16: Ataque al (MPR-Flooding)
C. Ganar posición 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
Juan Manuel Caracoche - Tesis de grado Ingenierı́a Informática
Protocolo OLSR
ingresa a la red y envı́a los mensajes de HELLO con Willingness WILL ALWAYS. De esta
manera es muy probable que algún nodo lo elija como MPR y una vez ubicado comienza con
cualquiera de los ataques.
6.7.
Resumen
En este capı́tulo se mostró el funcionamiento del protocolo OLSR, cuales son los mensajes que
se intercambian, que información viaja en cada paquete y como utiliza cada nodo esa información.
Se vió como construye cada nodo sus propias tablas de ruteo con la información recolectada de
los nodos vecinos y de la red en general. Se realizó una presentación de las vulnerabilidades que
presenta el protocolo, las cuales serán analizadas y se propondrá una contramedida en el protocolo
para hacerlo más robusto.
Juan Manuel Caracoche - Tesis de grado Ingenierı́a Informática
77
6.7. Resumen
78
Juan Manuel Caracoche - Tesis de grado Ingenierı́a Informática
Capı́tulo 7
Diseño de un Esquema de
Seguridad para una Red Móvil
OLSR Urbana
El objetivo de este capı́tulo es presentar el diseño del esquema de seguridad para
una Red Móvil basada en OLSR teniendo en cuenta los aspectos organizacionales de
las comunidades que las administran y cuestiones propias del protocolo.
En el Capı́tulo 5 se presentó como es la topologı́a y el funcionamiento de una Red Móvil Urbana. Teniendo en cuenta las caracterı́sticas de una red de este tipo y las cuestiones administrativas
de la comunidad que la mantiene es que se va a diseñar un esquema de seguridad para dichas
redes.
7.1.
Esquema de Seguridad
Un esquema de seguridad son combinaciones de primitivas (operaciones matemáticas básicas) combinadas con métodos adicionales [22]. Los esquemas proveen seguridad teórica y ésta es
mejorada cuando es aplicada apropiadamente en un protocolo para poder cumplir con las caracterı́sticas de seguridad enumeradas en el Capı́tulo 4. Es decir, todos los elementos auxiliares
para que un nodo, por ejemplo, pueda encriptar el tráfico, autenticarse con el nodo remoto y
estar seguro que el nodo remoto es al que se le quiere enviar la información. Para lograr esto es
necesario diseñar y establecer un esquema de seguridad que especifique claramente los roles que
tienen cada uno de los elementos que lo componen y de qué manera se relacionan.
79
7.2. Fundamentos del Diseño
7.2.
Fundamentos del Diseño
El diseño del esquema de seguridad utiliza la topologı́a de una Red Móvil Urbana y a la vez
la forma de organización de la comunidad que la conduce.
Con lo que respecta a la topologı́a de la red se tiene en cuenta que en una Red Móvil Urbana
se cuenta con un número de nodos fijos, los cuales garantizan la intercomunicación de los nodos
que a nivel de tierra no pueden hacerlo debido a que la tecnologı́a utilizada para la comunicación
(IEEE 802.11x) necesita linea de visión directa con el otro extremo del vı́nculo.
Estos nodos tienen un rol importante dentro de la red y deben estar dados de alta y ser 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ño del esquema.
El esquema de seguridad propuesto tiene como objetivo hacer una Red Móvil Urbana Segura
y para ello se necesita un protocolo de ruteo que sea seguro. Para cumplir con este requisito se
van a definir tres niveles o etapas de securización del protocolo. La primer etapa tiene en cuenta
brindar los servicios básicos que debe tener una red segura como se describió en el Capı́tulo 4. La
segunda etapa tiene por objetivo mejorar las capacidades de defensa ante los ataques más comunes
(Sec. 6.6) y por ú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ública y privada, distribuidas por medio de certificados. Cada cliente de la red necesitará un
certificado para poder comunicarse. Ese certificado es expedido por una Autoridad Certificante
(CA) perteneciente a la red.
El uso de un esquema de clave pública y privada es el pilar sobre el cual se va a basar
la implementación de un protocolo seguro para garantizar la seguridad de la primera etapa de
securización.
Un elemento importante a la hora de describir la tercera etapa de seguridad es un Sistema
de Detección 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 envı́a dicha información a la Autoridad
Certificante y se deniega su participación en la red revocando su certificado.
Los componentes (CA, IDS) deben correr en nodos que la Comunidad establece como confiables. 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ás Fuerte
El corazón del diseño de una red móvil segura es contar con un protocolo de ruteo confiable
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 certificación que le va a proveer certificados para asegurar el canal de comunicación entre
80
Juan Manuel Caracoche - Tesis de grado Ingenierı́a Informática
Diseño de un Esquema de Seguridad para una Red Móvil OLSR Urbana
Figura 7.1: Componentes participantes en el esquema de seguridad propuesto
los nodos. En la segunda etapa el protocolo original es modificado para prevenir los ataques
más comunes (timestamp attack, wormhole attack, DoS, etc). Por último se propone un tercer
nivel de seguridad, en el cual la misma red se defiende de los intrusos. Este nivel será descripto
brevemente y queda fuera del alcance de la presente tesis.
7.3.
Esquema de Clave Pública y Privada
Como componente principal se busca lograr la autenticación de cada uno de los nodos para
poder confiar y estar seguro que son nodos pertenecientes a la red. Para ello se utilizará un
esquema de clave pública y privada mediante el uso de certificados digitales.
7.3.1.
Autoridad Certificante
Como se enunciaba en la Sec 3.1.6 una Autoridad Certificante es un componente de PKI
(Public Key Infreatructure) encargada de otorgar y revocar certificados digitales.
El rol de la CA dentro de la infraestructura es validar la autenticidad de claves públicas. El
proceso de generación de claves comienza cuando un miembro genera un par de claves y solicita
a la CA que firme su clave pública, la CA genera un certificado incluyendo la clave pública de la
solicitud y firma este certificado con su clave privada. De esta manera cualquier nodo que tenga la
clave publica de la CA puede estar seguro que la clave pública recibida de otro nodo es confiable.
Tı́picamente una CA es única en la red y ésto puede hacer que nodos no lleguen a ésta debido
a interrupciones temporales de enlaces u otras cuestiones propias de la topologı́a de las redes
móviles.
7.3.2.
Esquema de Certificación
El esquema de seguridad planteado tiene como punto de partida la utilización de certificados
digitales para autenticar las partes. Para ellos va a existir una Autoridad Certificante 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
Juan Manuel Caracoche - Tesis de grado Ingenierı́a Informática
81
7.3.2. Esquema de Certificación
estandarizado). La comunidad enrola a este nuevo nodo, registra el nodo a la red, le da la información requerida y en conjunto con los datos solicitados se le da un certificado firmado por la
CA de la comunidad. Por ser un nodo enrolado, y la comunidad “conoce” al dueño del nodo, es
considerado “seguro”.
De esta manera el nodo con el certificado expedido por la CA de la comunidad va a poder
firmar requerimientos de certificados de los clientes que se conecten a él (Figura 7.2).
Figura 7.2: Esquema de Certificación. CA de la comunidad expide certificados a los nodos enrolados y
estos expiden certificados a los clientes
Para garantizar disponibilidad (uno de los requisitos del los protocolos seguros) de las CAs,
hay varias distribuı́das a lo largo de la red. Cada nodo tiene un listado de CAs disponibles
ordenados por proximidad.
En la Figura 7.3 se representa un ejemplo práctico donde se puede representar la interacción
de los nodos fijos, los nodos enrolados y los nodos móviles. 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 más cercana y aún tiene lı́nea de visión con algún nodo
fijo de la red para garantizar la conectividad hacia el backbound de la red. Los participantes que
se acercan a su plaza más cercana para participar del torneo van a ser clientes móviles que por
primera vez se van a conectar a la red, por lo tanto solicitarán un certificado al nodo enrolado más
cercano para poder participar en el torneo. Cabe aclarar que toda la negociación de certificados
y gestiones para que el cliente acceda a la red son transparentes al cliente, el protocolo es el
encargado de la tarea. Una vez que este nuevo cliente ingresa a la red podrá acceder al servidor
de juegos que se encuentra a miles de metros al cual accede primero routeando a través de los
nodos cercanos en la plaza hasta llegar al nodo enrolado que se movilizó hasta la misma, el cual
le provee acceso al backbound de nodos interconectados fijos hasta llegar al servidor de juegos.
82
Juan Manuel Caracoche - Tesis de grado Ingenierı́a Informática
Diseño de un Esquema de Seguridad para una Red Móvil OLSR Urbana
Figura 7.3: Ejemplo de utilización de una red Móvil Urbana Segura interconectando distintas plazas
7.4.
Fortalecimiento de OLSR
Para poder lograr implementar el esquema de seguridad propuesto sobre el protocolo OLSR,
será necesario realizar cambios al protocolo [5]. Estos cambios no solo son cambios agregando
información de las CA en los mensajes del protocolo sino que se firmarán los mensajes crı́ticos
(HELLO, TC, MID, HNA) implementando lo expuesto en [21]. En [21] Hafslund y Tonnesen proponen firmar los mensajes con una clave compartida, pero en el esquema propuesto se firmará con
una clave que se intercambia durante el proceso de autenticación y luego son encriptados con una
clave de sesión generada entre las partes para garantizar autenticación, integridad y confidencialidad.
7.4.1.
Prevención de Ataques
Con la firma de los mensajes se puede garantizar la integridad del mismo.
Con la encriptación del mensaje con una clave de sesión negociada previa autenticación de
las partes, se garantiza la confidencialidad y no repudio.
Con el agregado de un algoritmo de timestamp se previene la retransmisión de mensajes
viejos.
Con un algoritmo heurı́stico se puede inferir si el mensaje proviene de un nodo vecino o de
uno lejano a través de un túnel (prevención de wormhole attack ).
Se implementarán técnicas para prevenir ataques de DoS y ataques que hagan realizar al
nodo desgaste de energı́a en el procesamiento de mensajes maliciosos.
Juan Manuel Caracoche - Tesis de grado Ingenierı́a Informática
83
7.5. Integración del IDS y la CA
En el Capı́tulo 9 se dará el detalle de la implementación de todos los puntos antes mencionados.
7.5.
Integración del IDS y la CA
La comunicación 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 sesión y se encripta el
tráfico. La interacción de los IDSs con la CAs es mediante mensajes especı́ficos para informar
comportamientos de los nodos.
7.6.
Interacción de los Nodos Clientes con Esquema de Seguridad Planteado
En esta sección se hará 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ública 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
recolectará información de los vecinos y a la vez de las CA más cercanas. Una vez que conoce
cuales son la CAs, envı́a un requerimiento de un certificado a la CA más cercana para poder
operar en la red. Recibido el certificado, valida que esté en la cadena de certificación la CA de
la comunidad y toma el certificado como válido y comienza una ronda de autenticación con sus
vecinos. En la ronda de autenticación se establece la clave se sesión entre cada par de nodos para
cifrar los mensajes y se intercambian de manera segura los parámetros de inicialización para el
algoritmo de timestamp. Finalmente, cuando se autentican los vecinos, el nodo pasa a ser un nodo
confiable en la red salvo que detecte un comportamiento anómalo y sea excluido de la red.
Mientras que el nodo no se encuentre autenticado por otro nodo, éste permanecerá en estado
no seguro y no participará en la elección de MPR ni se le aceptarán mensajes distintos a los
mensajes de HELLO.
7.6.1.
Esquema de confianza ganada
El esquema de “ganar” confianza se basa en el comportamiento del nodo en la red. Cuando
un nodo ingresa por primera vez a la red, se le asigna un certificado por un perı́odo de tiempo
corto, cuando ese certificado esté 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 certificado con un tiempo de expiración más 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
Juan Manuel Caracoche - Tesis de grado Ingenierı́a Informática
Diseño de un Esquema de Seguridad para una Red Móvil OLSR Urbana
7.7.
Resumen
En este capı́tulo se presentó cual es el diseño del esquema de seguridad propuesto a nivel
macro y sin dar mayores detalles, sólo se introdujo cuales serı́an los actores involucrados y que
rol tiene cada uno dentro del esquema. En el Capı́tulo 9 se darán los detalles de lo planteado en
el presente capı́tulo.
Juan Manuel Caracoche - Tesis de grado Ingenierı́a Informática
85
7.7. Resumen
86
Juan Manuel Caracoche - Tesis de grado Ingenierı́a Informática
Capı́tulo 8
Artı́culos más Relevantes
Relacionados con la Seguridad de
OLSR
El objetivo de este capı́tulo es realizar un resumen de los principales artı́culos
leı́dos para el desarrollo de la presente tesis, los cuales fueron las principales fuentes
de información e inspiración para la creación del Esquema de Seguridad para una
Red Móvil Urbana basada en OLSR .
Las redes móviles hace años 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 tecnologı́a y
la naturaleza de este tipo de redes, los miembros de la misma se encuentran expuesto a ataques
continuamente. Como se detalló en el Capı́tulo 2, existen diferentes tipos de protolocolos de ruteo,
los cuales en su mayorı́a no preveen cuestiones de seguridad. En el Capı́tulo 4 se detallaron los
principales protocolos de ruteo seguros. Dentro de los protocolos disponibles, para el desarrollo de
esta tesis se eligió el protocolo OLSR, el cual como se dijo en varias oportunidades no es seguro
pero es el más popular en las redes móviles urbanas.
La seguridad del protocolo OLSR también ha inquietado a distintas personas y laboratorios
de investigación en todo el mundo y han propuesto distintas alternativas de securización, las
cuales fueron pilares para la elaboración 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 artı́culo, que fue escrito por los implementadores del protocolo OLSR, propone una
extensión del mismo asegurando la integridad y autententicando los mensajes.
Los autores asumen que cada nodo conoce una clave compartida con la cual autenticarán los
paquetes. La solución propuesta es utilizar una firma por paquete OLSR y la solución brinda
paquetes firmados salto-a-salto y no una solución de firmado de punta a punta. El fundamento
de esta técnica es que los paquetes son reenviados a través de nodos seguros, con lo cual el
destinatario recibe un paquete firmado por el nodo anterior que no es el originador del mismo,
pero este nodo previo confı́a en el nodo que le reenvió el mensaje y ası́ sucesivamente.
Los nodos que no conozcan la clave compartida no podrán verificar ni generar una firma
verificable.
8.1.2.
Firma
Para generar la firma del paquete OLSR, se crea un nuevo mensaje, el cual se puede ver el
detalle en la Figura 8.1 y el último mensaje del paquete OLSR. Como se puede entender, existe
un mensaje de firma por cada paquete OLSR.
0
1
2
3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
SCHEMA
|
ALGORITHM
|
Reserved
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
TIMESTAMP
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
SIGNATURE (160 bits)
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figura 8.1: Mensaje de firma básico
En el mensaje de firma se especifica qué esquema de firma se está usando y qué algoritmo.
Luego una marca de tiempo para prevenir ataque de reenvı́o de paquetes (se explica más adelante)
y por último una firma del paquete utilizando SHA-1. En realidad, no es una firma digital como
se definió en el Capı́tulo 3, lo que llama firma es un MAC donde usa como clave el timestamp.
Con el agregado de este mensaje, la longitud del paquete debe ser recalculada agregando al
longitud del mensaje de firma.
8.1.3.
Timestamps
La extensión propuesta en el artı́culo incluye la generación de timestamps por cada paquete
para prevenir el reenvı́o 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
Juan Manuel Caracoche - Tesis de grado Ingenierı́a Informática
Artı́culos más Relevantes Relacionados con la Seguridad de OLSR
1. A → B : Cha , D(M, K)
2. B → A : Chb , T sb , D(IPb , Cha , K), D(M, K)
3. A → B : T sa , D(IPa , Chb , K), D(M, K)
Cuando A recibe un mensaje firmado de B del cual no tiene registro de su reloj, envı́a un
mensaje de desafı́o hacia B. El mensaje tiene como destino la IP de B, un número aleatorio Cha
y el resumen del mensaje utilizando la clave compartida K (D(M, K)).
B responde con un mensaje de respuesta de desafı́o el cual tiene un número aleatorio Chb , el
reloj de B, un resumen de la IP de B, el número al azar generado por A y la clave. Por último
un resumen criptográfico 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 último A envı́a una respuesta a B similar a la enviada por B
y luego B valida las firmas y si con válidas 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 cálculo. El nodo receptor extrae el timestamp
del paquete y calcula la diferencia con su reloj calculando TN = Tlocal − Tpaquete . A continuación
evalúa T0 − S < TN y T0 + S > TN , donde T0 es la diferencia horaria almacenada. En caso que
la validación del timestamp sea correcta se procesa el mensaje, en caso contrario se descarta.
Para compensar algún 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 artı́culo se propone un mecanismo de detección de vecinos seguros teniendo en cuenta la posibilidad de ataque de túnel durante el descubrimiento. Una vez que los vecinos son
descubiertos se ingresa en una ronda de autenticación de los mismos. Conocidos los vecinos y
autenticados se comienzan a enviar paquetes de control, se propone un mecanismos de firma para
los mensajes de control ası́ se puede garantizar la integridad de los mismos.
El artı́culo asume que cada nodo tiene un par de claves pública/privada expedida por alguna
entidad, no se detalla cual es el mecanismo por el cual se garantiza la identidad de la clave pública.
8.2.2.
Detección segura de vecino
Durante la etapa de descubrimiento de vecinos se puede ser objetivo de un ataque de túnel
(wormhole attack ), por lo tanto los autores proponen una forma heurı́stica de determinar si el
mensaje proviene de un vecino real o de un vecino “tuneleado”.
Los vecinos son aquellos que se encuentran a un solo salto de distancia. Asumiendo que la
velocidad de propagación 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
Juan Manuel Caracoche - Tesis de grado Ingenierı́a Informática
89
8.2.3. Autenticación de vecinos
dispositivo móvil tiene un radio de cobertura R (por ejemplo 100 metros), por lo tanto si L > R
entonces se está en presencia de ataque y si L ≤ R no.
La forma propuesta para implementar este mecanismo de defensa es la siguiente:
1. B envı́a un mensaje de prueba a A e inicializa un contador.
2. Cuando A recibe el mensaje de prueba, envı́a la respuesta e inmediatamente inicia un
contador.
3. Una vez que B recibe la respuesta de A, detiene el contador y envı́a una respuesta a A. B
calcula el 4tb . La distancia S entre A y B es de (4tb /2) × c. Si S > R, B no inserta a A
como vecino, en caso contrario prosigue con el mecanismo de autenticación.
4. Cuando A recibe la respuesta de B realiza el mismo cálculo y toma las mismas decisiones
que el punto anterior.
8.2.3.
Autenticación de vecinos
Una vez superada la etapa de detección de vecino, el nodo debe realizar una ronda de autenticación. El mecanismo de autenticación es por medio de un intercambio de mensajes.
1. A genera un paquete que contiene un número al azar (RA ), el certificado de A (CertA ), los
identificadores de A y B, y un hash encriptado con clave privada de A (firma).
A → B : A, B, CertA , RA , sign(H(A, B, CertA , RA ))
Donde H() es una función hash y sign() es una operación de firma.
2. Cuando B recibe el paquete, primero verifica el certificado de A, luego extrae la clave
pública de A y verifica la firma del paquete. Una vez hecho esto, B envı́a un paquete que
contiene un número al azar grande (RB ), el certificado de B, los identificadores del A y B
y un hash encriptado con la clave privada de B (firma).
B → A : B, A, CertB , RB , sign(H(B, A, CertB , RA , RB ))
3. Cuando A recibe la respuesta de B, verifica si el certificado de B es válido, verifica la firma.
Terminada esta etapa A confı́a que B es un vecino seguro. A envı́a un ú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 relación
de confianza con el vecino
90
Juan Manuel Caracoche - Tesis de grado Ingenierı́a Informática
Artı́culos más Relevantes Relacionados con la Seguridad de OLSR
Figura 8.2: Pasos para lograr una relación de confianza con un vecino
8.2.4.
Paquetes de Ruteo Seguros
OLSR utiliza un solo paquete para comunicar todos los tipos de mensajes. Este tiene una serie
de campos que son modificables durante la propagación del mismo y otros no. Para garantizar la
integridad de los campos que no deben cambiar durante la propagación, se utiliza un algoritmo
de firma y para los campos variables se utiliza cadena de hash para securizar Hop Count y TTL.
La extensión 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ón del paquete OLSR
Cuando un nodo genera un nuevo paquete realiza los siguientes pasos:
Genera un número aleatorio Seed.
Hash Hop = H T T L (Seed). donde H() es una función de hash.
signature = sign(campos estaticos)
Cada vez que un nodo recibe un paquete realiza las siguientes operaciones:
Primero se calcula H T T L−Hop Count (Seed), si el valor es igual a Hash Hop del paquete, se
verifica la firma, si es correcto se sigue con el próximo paso.
T T L = T T L − 1; HopCount = Hop Count + 1; Seed = H(Seed)
Juan Manuel Caracoche - Tesis de grado Ingenierı́a Informática
91
8.3. Securing the OLSR protocol
8.3.
8.3.1.
Securing the OLSR protocol
Overview
En este artı́culo se presenta un framework que permite securizar el protocolo OLSR de los
siguientes ataques:
Generación Incorrecta de Tráfico de Control
Generación de Mensajes de HELLO Incorrecta
Generación de Mensajes de TC Incorrecta
Reenvı́o de Tráfico de Control Incorrecto
En el desarrollo de la solución se asume que el comportamiento de un nodo seguro no se altera
y mantiene su buena conducta en la red. La información de control generada por este tipo de
nodos es la que se conserva ı́ntegra.
Para lograr esto, se proponen requerimientos criptográficos como:
Una función que permita retornar la firma de un mensaje, por ejemplo sign(nodeid, key,
message).
Una función que permita verificar la firma, por ejemplo verif(originatorid, key,
message, signature).
Una clave compartida para poder firmar y validar la firma
8.3.2.
Firma de Mensajes
Con los elementos descriptos, el nodo que genera un mensaje de control genera un mensaje de
firma, el cual es enviado uno por cada mensaje generado (pueden generarse varios mensajes de
firma para un paquete OLSR). Este mensaje de firma se envı́a 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 firma correspondiente al mensaje.
El mensaje de firma se puede ver en la Figura 8.4. Este es enviado en la porción de datos del
paquete general de OLSR con el “Message Type” SIGNATURE MESSAGE. Para poder determinar
a que mensaje corresponde la firma, el mensaje de firma tiene un número (MSN Referrer) que
es el número de secuencia del mensaje de control. En el campo Sign Method, se especifica que
algoritmos se van a utilizar para realizar el hash, que método de timestamping se va a utilizar e
información sobre la clave utilizada.
Para calcular la firma del mensaje de control, se ignoran los campos del mensaje que pueden
variar durante la vida del mensaje (TTL y Hop Count) tomándolos como cero. En este esquema
de firma se genera una autenticación y validación del mensaje de punta a punta.
92
Juan Manuel Caracoche - Tesis de grado Ingenierı́a Informática
Artı́culos más Relevantes Relacionados con la Seguridad de 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sign. Method |
Reserved
|
MSN Referrer
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
:
Timestamp
:
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
:
Signature
:
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figura 8.4: Formato del mensaje de firma
8.3.3.
Timestamping
En el mismo artı́culo, en la sección V, se presentan distintos algoritmos de timestamping para
prevenir ataques de reenvı́o de paquetes. Los diferentes tipos de algoritmos propuestos son:
No timestamp: Si se quiere no se utiliza esta protección y se pone un valor igual a cero
Real-time timestamp: Se toma el reloj de cada nodo, pero requiere algún mecanismo de
sincronismo de relojes entre los nodos
Non-volatile timestamp: Este algoritmo exige que cada nodo mantenga en memoria no
volátil 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 máximos
de timestamp recibido de cada nodo. El emisor utiliza un valor de reloj de la tabla y luego
lo incrementa.
Timestamp Exchange Protocol : Este más que un algoritmo es un protocolo de intercambio de
relojes, por medio del cual se generan mensajes con desafı́os encriptados. Para el intercambio
de mensajes se utilizará la notación X → Y : {Z}SX , que significa que X envı́a 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ón IV, se proponen dos esquemas de PKI para redes móviles, uno es
proactivo y el otro es reactivo.
Juan Manuel Caracoche - Tesis de grado Ingenierı́a Informá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 confiables, Nodos Confiables, Autoridades Firmantes. Un nodo no es confiable si la clave publica de x no es conocida por a o si
la clave pública de x es conocida pero no está firmada por la Autoridad Firmante. Un nodo es
confiable si la clave publica de x es conocida por a y a la vez está firmada 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úblicas para nuevos nodos. La Autoridad Firmante envı́a
periódicamente un listado de las claves de los ”nodos confiables”.
Cada nodo que quiera participar en la red deberá registrar su clave pública en la Autoridad
Firmante, esta periódicamente distribuye el listado de claves. Cada nodo almacena las claves
hasta que expiran. Este mecanismo requiere que las claves sean renovadas periódicamente.
Cuando la red se inicializa, ningún 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ún nodo va a ser elegido como MPR y ningún 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ón de la red, la Autoridad Firmante envı́a su certificado 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 simétricos pero no los eligen
como MPRs. La Autoridad Firmante elige MPRs entre los vecinos de un salto y ası́ el próximo
broadcast de claves llega a los vecinos de dos saltos de distancia. Ası́ continúa inundando la red
para que todos los nodos conozcan las claves públicas de los nodos confiables.
Todos los nodos deben mantener tablas con la información de claves de sus vecinos y si son
confiables o no.
No se prevee un esquema de revocación 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úmero aleatorio, la identificación 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 firma del mensaje de A (si tiene la clave pública de A), y
luego arma el mensaje de respuesta con el listado de claves públicas 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 firma del mensaje sea correcta y que el NA sea
válido.
La retransmisión de los mensajes de solicitud y respuesta de claves se realizan mediante el
mecanismo de inundación convencional, por ejemplo si un nodo recibe un mensaje, lo reenvı́a una
94
Juan Manuel Caracoche - Tesis de grado Ingenierı́a Informática
Artı́culos más Relevantes Relacionados con la Seguridad de OLSR
sola vez.
8.4.
Resumen
En este capı́tulo se resumieron distintos artı́culos los cuales plantean distintas alternativas de
securización para el protocolo OLSR. Las soluciones aportadas por estos fueron utilizadas para
el desarrollo de la presente tesis adaptándolas a las necesidades del protocolo propuesto.
Juan Manuel Caracoche - Tesis de grado Ingenierı́a Informática
95
8.4. Resumen
96
Juan Manuel Caracoche - Tesis de grado Ingenierı́a Informática
Capı́tulo 9
Detalles de Implementación del
Esquema de Seguridad Propuesto
En este capı́tulo se dará un detalle de lo propuesto en el Capı́tulo 7, llegando a
profundizar cuestiones relacionadas al protocolo OLSR como a los aspectos organizacionales de las comunidades de llevan adelante los proyectos de redes móviles urbanas.
Luego de la presentación del esquema de seguridad planteado para una red móvil urbana en
el Capı́tulo 7, en este capı́tulo se dará los detalles de todos los puntos propuestos para lograr una
red móvil segura.
Se analizarán los detalles tanto organizativos que la comunidad debe realizar antes de dar de
alta un nodo fijo en la red como ası́ las piezas de protocolo necesarias para que interactúen los
elementos involucrados en el esquema.
Los elementos principales necesarios para la implementación del esquema de seguridad propuesto son: Autoridad Certificante, el protocolo de ruteo, los clientes de la Red y el Sistema de
Detección de Intrusos. El análisis de la implementación del IDS, no es el objetivo del presente
capı́tulo ni de la Tesis.
Se tratarán en detalle los mecanismos organizativos de la comunidad a la hora de registrar
un nodo como CA, con respecto al protocolo de ruteo se definirán tres niveles de securización
de los cuales se hará un detalle minucioso de los dos primeros y el tercero se plantea como una
extensión y es objeto de estudio futuro.
9.1.
Esquema de Certificación
Tal como se adelantó en el Capı́tulo 7, uno de los principales componentes del esquema
propuesto es la existencia de certificados digitales para autenticar a los nodos pertenecientes a
la red. Esto se logra teniendo una entidad responsable de emitir certificados garantizando que el
97
9.2. Fortalecimiento del Protocolo OLSR
nodo portador del mismo es confiable.
La comunidad va a tener un único certificado con el cual va a firmar certificados para los
nodos fijos de la red que se enrolen.
9.1.0.3.
Procedimiento para la registración de un nodo
La asignación de certificados es una tarea de la comunidad que administra la red. Si una
persona tiene un nodo y quiere participar de la comunidad, ésta necesitará 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 través de él y un ESSID
estandarizado (opcional). Si el propietario del nodo va a participar activamente en la red, es decir,
su nodo una vez configurado va a estar disponible sin interrupciones de servicio prolongadas,
puede solicitar ser CA para poder firmar certificados para sus clientes. La Comunidad conoce
a los propietarios de los nodos porque en general tienen una participación activa en los foros,
listas de correos y reuniones organizativas, con lo cual se está seguro cuales son los fines del nodo
solicitante y se puede asumir que es un nodo seguro.
El objetivo cuando la red no tiene muchos nodos fijos es que todos los nodos fijos sean CAs
para minimizar el trafico de backbone solicitando certificados a otros nodos de la red. Hoy en dı́a,
por ejemplo Buenos Aires Libre no cuenta con la cantidad de nodos suficiente como para que un
nodo cliente pueda ver dos o más nodos fijos y ası́ tener la posibilidad de que haya nodos fijos
que no sean CAs. Por esto es que es necesario que todos los nodos fijos asuman la responsabilidad
de ser CA.
9.2.
Fortalecimiento del Protocolo OLSR
El protocolo OLSR como se vió en el Capı́tulo 6 no dispone de ninguna prevención contra
los posibles ataques vistos en la Sección 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ño se separó el fortalecimiento de OLSR en distintos niveles.
En el primer nivel se detallarán las modificaciones del protocolo para garantizar los servicios básicos que debe ofrecer una red segura: Disponibilidad, Confidencialidad, Autenticación,
Integridad y No Repudio ( [15]).
En el segundo nivel se realizarán las modificaciones al protocolo para mitigar las vulnerabilidades más crı́ticas que presenta el protocolo.
Por último en el tercer nivel se tratará como podrı́a 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
agregarán una serie de mensajes propios de la solución propuesta, los cuales serán detallados en
las siguientes secciones.
98
Juan Manuel Caracoche - Tesis de grado Ingenierı́a Informática
Detalles de Implementación del Esquema de Seguridad Propuesto
9.3.
Fortalecimiento de OLSR: Nivel 1
A lo largo de esta sección se detallarán todos los componentes, las interacciones y los mensajes
necesarios para hacer que OLSR garantice los servicios básicos de seguridad. Para garantizar estos
servicios es necesario introducir modificaciones a las tablas originales del protocolo, a los mensajes
y los mecanismos y formas de comunicación. En esta sección se especificarán las modificaciones
a las distintas etapas del protocolo original: Detección de Vecinos, Descubrimiento de la Red y
Armado de la Tabla de Ruteo.
9.3.1.
Tablas del Protocolo
En la Sección 6.3 se detallaron cuales son las tablas que utiliza el protocolo OLSR según su
RFC. En esta propuesta de fortalecimiento del protocolo, se modificarán las tablas existentes.
La tabla Neighbor Set quedará conformada por la tupla {N neighbor main addr, N status,
N willingness, N trusted, N cert, N sessionKey, N deltaTimestamp, N localKey, N remoteKey,
N neighbor trust level, N CA}
N neighbor main addr: Dirección principal del nodo vecino.
N status: Especifica si el nodo está en estado SYM=enlace simétrico o NOT SYM=enlace
no simétrico.
N willingness: Es un entero entre 0 y 7 y especifica la confianza que se le tiene al
nodo vecino para llevar el tráfico.
N trusted: Indica si el vecino es confiable o no
N cert: Se almacena el certificado del vecino
N sessionKey: Se almacena la clave de sesión generada
N deltaTimestamp: Se almacena la diferencia entre el reloj local y el reloj del vecino.
Esta columna será usada para mitigar ataques de reenvı́o de paquetes
N localKey: Durante el proceso de autenticación se genera una clave local para firmar
los mensajes
N remoteKey: Durante el proceso de autenticación el nodo remoto genera una clave
con la cual firmará sus mensajes
N neighbor trust level: Indica el nivel confianza que la CA le dio al nodo vecino
(información incluida en el certificado)
N CA: Indica si el vecino es CA o no
La tabla Topology Information: quedará conformada por las tuplas {T dest addr,
T last addr, T seq, T CA, T time}
T dest addr: Dirección principal del nodo destino que es alcanzado en un salto por
el nodo con dirección principal T last addr.
T last addr: Es MPR de T dest addr.
T seq: Número de secuencia.
T CA: Indica si el nodo es CA o no
T time: Tiempo de expiración de la tupla.
Juan Manuel Caracoche - Tesis de grado Ingenierı́a Informática
99
9.3.2. Obtención del Certificado
9.3.2.
Obtención del Certificado
El nodo que ingresa a la red lo primero que hace es intentar obtener un certificado para poder
autenticarse con sus vecinos. El proceso de obtención del certificado comienza con la emisión
de un nuevo mensaje llamado CADISCOVER. Los vecinos que reciban este mensaje devolverán el
mensaje adjuntando al mismo el listado de CAs que tiene cada uno y la cantidad de saltos que
tiene hasta llegar a ésta.
9.3.2.1.
Generación 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 vacı́o, es decir no se especificará dirección 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 información de la Tabla de Topologı́a de la cual obtiene cuales son los nodos CAs y de la Tabla de Rutas
de la cual obtiene el número de saltos hacia el destino.
Para armar el mensaje de respuesta, se coloca en el destino del mensaje la dirección del nodo
que realizó la petición. Luego completa el mensaje incorporando el listado de las CAs conocidas
agrupándolas por cantidad de saltos.
Los nodos solo generarán respuestas cuando los mensaje recibidos no contengan una dirección
de destino y el listado de CAs estén vacı́os. Un mensaje que cumple con estas condiciones es
considerado una petición.
Cuando un nodo recibe un mensaje considerado petición realiza lo siguiente:
Actualiza la tabla de vecinos (Neighbor Set)
100
Juan Manuel Caracoche - Tesis de grado Ingenierı́a Informática
Detalles de Implementación del Esquema de Seguridad Propuesto
Confecciona el mensaje de respuesta.
Envı́a el mensaje generado
Cuando un nodo recibe un mensaje que tiene una dirección de destino, verifica que dicha
dirección 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ón agrupada bajo cada cantidad de saltos se agrega una entrada en la tabla
de rutas colocando como R dest addr la dirección de la CA, como R next addr la dirección
del nodo de donde provino la respuesta, R dist igual a la cantidad de saltos y finalmente
la R iface addr la dirección de la interfaz por la que recibió la respuesta.
Esta generación 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 ú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ón del CERTREQ
El nodo que pretende obtener un certificado, 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án de un nodo no confiable (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 él sabı́a como llegar a una CA y con cuantos saltos.
Para generar el mensaje, el nodo genera su propio par de claves y crea un requerimiento de
certificado (CertReqMessage [27]). Para enviar la solicitud a la CA más cercana debe hacerlo de
Juan Manuel Caracoche - Tesis de grado Ingenierı́a Informática
101
9.3.2. Obtención del Certificado
forma segura según lo especifica el RFC 2511 de X.509[27, Sec. 2]. Para cumplir con la norma,
se establece una conexión SSL [28] con la CA. Como el nodo cliente conoce el certificado de la
rootCA de la comunidad, verifica que el certificado presentado por la CA a la hora de establecer
la sesión SSL esté firmado por la rootCA. De esta manera el nodo cliente se asegura que se
está conectando a una CA segura. Cabe aclarar en este punto que solo es necesario que el nodo
que intenta obtener un certificado sea el único que verifique la identidad de la CA ya que no
es necesario que la CA valide la identidad del nodo porque el propósito de este mecanismo es
obtener una identidad temporal para un nodo anónimo.
Una vez establecido un canal seguro, el nodo crea un mensaje CERTREQ donde incluye el
mensaje CertReqMessage de X509 definido en la Sección 3 del RFC 2511 (Figura 9.2) y se lo
envı́a a la CA.
Un nodo cuenta con más de una CA, en caso que existan, con lo cual comienza intentando
enviar el mensaje CERTREQ a la CA más cercana y luego a las más alejadas. Con esta caracterı́stica
se gana disponibilidad de las CAs ya que sin la obtención del certificado, el nodo nunca será parte
de la red.
9.3.2.4.
Generación del Certificado
Como se mencionó anteriormente una CA tiene un certificado expedido por la rootCA de
la comunidad. Una vez que el nodo cliente establece una conexión segura con la CA, envı́a el
mensaje solicitando un certificado. La CA consulta en su CRL si este nodo está presente. En caso
que no esté en la CRL, expide un certificado con una validez temporal.
La validez del primer certificado será de una hora y el nivel de confianza es de uno. Ese
nivel de confianza es un parámetro que la CA agrega como campo de texto en una extensión del
certificado. El nivel de confianza permite a un nodo cambiar su rol de participación en la red a
medida que va ganándola con un buen comportamiento en la red.
Una vez que se tiene el certificado expedido, es enviado al nodo en la misma sesión SSL. Es
decir, el proceso de solicitud de un certificado es sincrónico.
La respuesta con el certificado firmado es devuelto en un mensaje de tipo CERTREPLY como
se muestra en la Figura 9.3.
9.3.2.5.
Renovación de certificado
Un nodo cuando está por vencer su certificado debe solicitar una renovación del mismo.
El procedimiento para la renovación es el mismo que para la solicitud, es decir, establece una
conexión SSL con la CA y envı́a el mensaje. En este caso el mensaje que se envı́a es de renovación
(tipo CERTRENEW). En el mensaje se envı́a el certificado anterior para una renovación (Figura 9.4).
Los perı́odos de expiración se calculan, de forma arbitraria, duplicando el perı́odo de validez
del certificado anterior, es decir V ALIDEZ = V ALIDEZ ∗ 2, tomando como perı́odo de validez
inicial una hora. Con cada renovación se gana un nivel más de confianza. El nivel de confianza
permite a un nodo cambiar su rol de participación en la red.
Con esta tabulación de perı́odos de validez, una CA puede saber por cuanto tiene que renovar
un certificado sin necesidad que el certificado anterior haya sido expedido por la misma CA. La
102
Juan Manuel Caracoche - Tesis de grado Ingenierı́a Informática
Detalles de Implementación del Esquema de Seguridad Propuesto
0
1
2
3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
:
Expired Cert
:
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figura 9.4: Formato del mensaje CERTRENEW
Nro Renovaciones
Nivel de Confianza Ganado
Valido por (hs)
0
1
1
1
2
2
2
3
4
3
4
8
4
5
16
...
...
...
Cuadro 9.1: Validez del certificado por renovación
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 certificados expedidos
para un nodo.
La CA recibe el certificado y valida que haya sido expedido por una CA autorizada, verifica
por cuanto tiempo tiene que ser expedido, incrementa el nivel de confianza, lo genera y se lo envı́a
al nodo en un mensaje CERTREPLY.
El perı́odo de renovación será como máximo un año, o sea cuando el nodo logra obtener un
certificado con una validez de un año, en cada renovación recibirá un certificado de un año.
Una vez que se tiene el nuevo certificado expedido, es enviado al nodo en la misma sesión
SSL, es decir el proceso de renovación del certificado es sincrónico.
9.3.3.
Detección de Vecinos
El proceso de detección de vecinos será de la misma manera que se realiza en el protocolo
original mediante un censado de vecinos. Cuando el nodo se incorpora a la red envı́a 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 confiable. Los nodos que reciben el mensaje CADISCOVER actualizan su tablas de enlaces con
los vecinos y agregan al nuevo vecino como no confiable y el estado del enlace como ASYM LINK
y tipo de vecino como NOT NEIGH. De esta manera un nodo nunca elegirı́a al nuevo nodo como
Juan Manuel Caracoche - Tesis de grado Ingenierı́a Informática
103
9.3.3. Detección de Vecinos
MPR ya que es condición que el nodo tenga un enlace simétrico para participar en la elección de
MPR.
En el procedimiento de censado de vecinos propuesto se incorpora una modificación mı́nima
al procedimiento original. Se agrega un nuevo tipo de vecino a los ya existentes (NOT NEIGH,
MPR NEIGH y SYM NEIGH) llamado CA NEIGH. Es decir en un mensaje de HELLO se incorpora un
nuevo Link Code donde se indica que ese enlace es con un vecino que es CA, es decir es una
extensión de la información 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 dirección del nodo esta listada con Link Code
correspondiente a CA NEIGH, se actualiza la tupla en la tabla de vecinos indicando que el vecino
con el cual se tiene ese enlace es CA.
Un nodo puede informar que él es CA enviando su dirección en el listado de direcciones con
Link Code CA NEIGH y cuando un nodo procese este mensaje comparará la dirección de origen
del mensaje y la dirección listada como CA NEIGH y actualizará 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 fin.
9.3.3.1.
Autenticación de los vecinos
Una vez que el nodo obtiene un certificado, comienza el proceso de autenticación. 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 autenticación con cada uno de los vecinos de su
listado de vecinos.
Para intercambiar los parámetros de autenticación 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
Juan Manuel Caracoche - Tesis de grado Ingenierı́a Informática
Detalles de Implementación del Esquema de Seguridad Propuesto
Procedimiento de Autenticación Para explicar el proceso de autenticación llamaremos A
al nodo que inicia el proceso y B a la otra parte.
1. A genera un paquete que contiene un número al azar (RA ), el certificado de A (CertA ), los
identificadores de A y B, y un hash encriptado con clave privada de A (firma).
A → B : A, B, CertA , RA , sign(H(A, B, CertA , RA ))
Donde H() es una función hash y sign() es una operación de firma.
2. Cuando B recibe el paquete, primero verifica el certificado de A si corresponde a un certificado firmado por una CA de confianza, luego extrae la clave pública de A y verifica la
firma del paquete. Una vez hecho esto, B envı́a un paquete que contiene un número al azar
(RB ), el certificado de B, los identificadores del A y B y un hash encriptado con la clave
privada de B (firma).
B → A : B, A, CertB , RB , sign(H(B, A, CertB , RA , RB ))
3. Cuando A recibe la respuesta de B, verifica si el certificado de B es válido y fue firmado
por una CA de la red, verifica la firma. Terminada esta etapa A confı́a que B es un vecino
seguro y agrega el certificado, en la tabla de vecinos marcándolo como confiable, actualiza el
estado de los enlaces con B como SYM LINK y tipo de vecino SYM NEIGH. A envı́a un ú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, confirma que A es un vecino seguro. Actualiza la tabla de
vecinos con el certificado de A y marca a A como vecino seguro. También 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 configurado puede enviar miles de mensajes de
autenticación seguidos, lo cual puede generar una Denegación de Servicio. En el detalle
del próximo nivel de securización se detallará cual es la manera de prevenir este tipo de
comportamiento.
Juan Manuel Caracoche - Tesis de grado Ingenierı́a Informática
105
9.3.4. Firma y encripción de los mensajes
9.3.3.2.
Elección de MPR
La elección de MPR se realiza de la misma manera que en el protocolo original ya que con
la modificación incorporada, solo se va a lograr tener un enlace simétrico 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 pondrı́a
en riesgo el ruteo y la integridad de la red. Como un punto parametrizable para el protocolo
se puede establecer cual es el nivel de confianza mı́nimo que se tiene que tener con los vecinos
para elegirlo como MPR. Este parámetro debe ser configurable ya que en un red chica con pocos
nodos, establecer un umbral alto dejarı́a el nodo aislado pero ya es riesgo del usuario usar un
umbral bajo.
9.3.4.
Firma y encripción de los mensajes
Para implementar seguridad sobre OLSR, es preciso identificar cuales son los paquetes y los
mensajes crı́ticos para poder securizarlos. Los mensajes que hay que proteger son aquellos que
por alguna manipulación 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ón de seguridad sobre estos mensajes se pueden plantear dos alternativas,
una autenticando y encriptando el mensaje de punta a punta [30] o firmando y encriptando el
paquete OLSR [21] dando una autenticación y encripción salto por salto.
Para la encripción de punta a punta es necesario que los dos extremos de la conexión se
autentiquen mediante el intercambio de certificados y generar una clave de sesión para realizar un
encriptado simétrico. Con el uso de claves asimétricas generarı́a un desperdicio de energı́a porque
harı́a uso intensivo del procesador. Esta alternativa no es considerada viable ya que implicarı́a
mucho overhead de control y en caso de ser un nodo remoto a varios saltos de distancia el
intercambio de mensajes podrı́a interrumpirse y requerirı́a una nueva negociación. La propuesta
de [30] utiliza un mensaje de firma por separado que requiere un seguimiento de los mensajes
recibidos y verificar la firma 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ón y encripción salto a salto es más eficiente pero no permite una verificación
del mensaje de punta a punta. En el análisis el funcionamiento de OLSR 6.4, se vió que el
protocolo en sı́ utiliza el reenvı́o de paquetes para la propagación de mensajes con lo cual utilizar
una encripción y autenticación salto a salto va de la mano con el funcionamiento del protocolo.
Esta forma de securizar un paquete se basa en que los nodos por los cuales se reenvı́a, son nodos
confiables y autenticados.
9.3.4.1.
Obtención de la Clave de Sesión
Una de las premisas de este diseño es generar un protocolo que garantice integridad y confidencialidad, para ello es necesario utilizar una firma y una clave para encriptar el mensaje. Como
se vió en el Capı́tulo 3, existen dos tipo de cifradores, los simétricos y los asimétricos. Como
106
Juan Manuel Caracoche - Tesis de grado Ingenierı́a Informática
Detalles de Implementación del Esquema de Seguridad Propuesto
la cantidad de mensajes intercambiados entre un nodo y su vecino es muy grande, utilizar un
esquema de clave pública y privada generarı́a un malgasto de la energı́a del nodo, para ello es
que se utiliza una clave se sesión para encriptar con un algoritmo simétrico.
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 generación de una clave de sesión, toma lugar durante el
proceso de autenticación 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
modificar 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 autenticación, el nodo B ya tiene el certificado de A. B encripta
un número al azar de un número de bits fijos (N = 128 para esta implementación) con su clave
privada y luego con la clave pública de A.
Juan Manuel Caracoche - Tesis de grado Ingenierı́a Informática
107
9.3.4. Firma y encripción 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úmeros al azar (KA , KB ) y ningún otro nodo pudo haber obtenido estos números.
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 sesión el producto de estos dos números
truncados a N bits1 . Una vez completado el cálculo de la clave compartida, es almacenada en la
tabla de vecinos. El perı́odo de validez de la clave de sesión es igual al valor de expiración del
enlace con el vecino (campo L time de la tabla Link Set). Cuando ese perı́odo esté próximo a
vencerse se procede nuevamente a realizarse la ronda de autenticación.
9.3.4.2.
Firma de los mensajes
Para prevenir que los mensajes sufran alteraciones por algún nodo intruso, se realiza el firmado
del mismo con el algoritmo HMAC 2 . Como se describió en el capı́tulo 3 el algoritmo HMAC es un
algoritmo que aplica una función al mensaje y se obtiene un resumen criptográfico del mismo.
La función que se aplica recibe como parámetro un mensaje y una clave (Figura 9.9). HMAC
involucra una función de hash aplicada al mensaje combinada con la clave HM ACK (m) =
h((K ⊕ opad)k(h((K ⊕ ipad)km)). La implementación del algoritmo utilizada es HMAC-SHA-1, por
lo tanto en la expresión anterior h() es SHA-1 y el resultado final será una firma de 160 bits.
Figura 9.9: Generación de la firma
HMAC no solo garantiza que el mensaje no fue modificado sino que también lo autentica. En este
diseño HMAC es utilizado con una clave de N bits, en particular A utilizará KA y B utilizará KB
(valores intercambiados durante la ronda de autenticación).
1 Este
cálculo para la clave sesión es determinado de forma arbitraria y es parte del protocolo propuesto.
no es estrictamente una firma digital como se definió en el Capı́tulo 3, pero en este caso será utilizado
para garantizar integridad y autenticación del mensaje.
2 HMAC
108
Juan Manuel Caracoche - Tesis de grado Ingenierı́a Informática
Detalles de Implementación del Esquema de Seguridad Propuesto
Los paquetes de OLSR tiene dos tipos de campos, los que no varı́an entre salto y salto y
los que varı́an cuando son reenviados. Para esta propuesta de protocolo no es necesario tener en
cuenta estos campos ya que la autenticación y la verificación 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 definitiva la firma se realizará sobre:
Encabezado del paquete OLSR (con el tamaño ajustado para incorporar la firma)
Todos los mensajes OLSR incluı́dos en el paquete
Las cabeceras del mensaje de firma.
0
1
2
3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
SCHEMA
|
ALGORITHM
|
Reserved
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
SIGNATURE (160 bits)
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figura 9.10: Formato del mensaje firma
Se genera un nuevo mensaje (Figura 9.10) con la firma y se agrega al final del paquete OLSR.
El tamaño del paquete OLSR debe ser reajustado para incorporar la firma al final como se ve en
la Figura 9.11. Más adelante cuando se trate la prevención de ataques en el nivel 2 de securización
se verá que el mensaje de firma sufre una ligera modificación.
9.3.4.3.
Protocolo de encriptación
Para garantizar la confidencialidad de la información que viaja en el paquete, se aplica encripción sobre el mismo. El algoritmo para encriptar los paquetes debe tener un cifrador simétrico
ya que hay que optimizar el uso de CPU del dispositivo móvil. El algoritmo elegido para esta
tarea es el AES [31, Capı́tulo 5]. AES es un cifrador por bloques y es el cifrador adoptado como
el cifrador estándar 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ño se utilizará una clave de 128
bits. La clave utilizada para encriptar los paquetes es la clave de sesión calculada en la ronda de
autenticación truncada a 128 bits.
Cuando el nodo destino recibe el mensaje, la primera operación que deberá hacer es desencriptar el paquete con la misma clave que se utilizó para encriptarlo (Figura 9.12), luego continúa
el procesamiento del paquete validando la firma.
9.3.5.
Descubrimiento de la Topologı́a
Con la modificación introducida, cada nodo tiene que conocer cuales son la CAs de la red,
para ello utilizan la tabla de topologı́a. Para diseminar esta información por la red, se generan
dos mensaje TC diferentes. Uno anunciando los enlaces de la misma manera que se hacen en el
Juan Manuel Caracoche - Tesis de grado Ingenierı́a Informá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 Sequence Number
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
:
MESSAGE
:
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type |
Vtime
|
Message Size
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Originator Address
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time To Live |
Hop Count
|
Message Sequence Number
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
:
MESSAGE
:
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
SCHEMA
|
ALGORITHM
|
Reserved
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
SIGNATURE (160 bits)
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figura 9.11: Formato del paquete de OLSR firmado
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ñalar que las direcciones contenidas en el mismo
correspondes a nodos que son CAs.
Para armar los mensajes TC con la información de la CAs, se hace de la misma manera que
en el protocolo original, con la modificación que solo se tomaran las direcciones de los vecinos del
Neighbor Set que sean CAs.
La forma de reenvı́o de los mensaje TC no sufren ninguna modificación 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 modificación con respecto a
la especificación del protocolo original [5, Sec. 10]
9.3.7.
Logros del Nivel 1 de securización
En lo detallado del Nivel 1 de securización se puede ver que es el nivel más complejo ya que
hay que incorporar mecanismos y elementos de criptografı́a y comunicación auxiliares para lograr
110
Juan Manuel Caracoche - Tesis de grado Ingenierı́a Informática
Detalles de Implementación del Esquema de Seguridad Propuesto
Figura 9.12: Firma + Encripción de un paquete
un determinado nivel de seguridad. En este nivel se puede garantizar los servicios básicos de una
red segura:
Autenticación: Con la fase de autenticación entre los nodos, se produce el intercambio de
certificados firmados por CAs de la red, con lo cual ambos nodos están seguros que están
conectados con quienes dicen ser.
Integridad: Con el esquema de firmado de los mensajes los nodos están seguros que nadie
ha modificado su contenido.
Confidencialidad: Luego del procedimiento de autenticación se establece una clave de sesión
entre los dos nodos, con lo cual el tráfico que es encriptado con esa clave solo puede ser
leı́do por ellos.
No repudio: Ambos extremos de un enlace están autenticados con certificados expedidos
por la CA, estos certificados son intercambiados para garantizar la identidad de cada uno.
Disponibilidad: Teniendo redundancia de las CAs, un nodo siempre va a tener donde solicitar
o renovar certificados.
Teniendo asegurados los paquetes de control el protocolo ya está más 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.
Fortalecimiento de OLSR: Nivel 2
Tener autenticados y encriptados los paquetes de control pone al protocolo OLSR más sólido
pero aún ası́ un nodo que permanece en la red durante un determinado tiempo podrı́a realizar
distintos ataques como el Ataque del Túnel y el Ataque de Reenvı́o de Paquetes.
9.4.1.
Prevención contra ataque Wormhole
Unos de los ataques analizados en la Sección 6.6 es el Ataque del túnel (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 través de un túnel externo a la red. Esto hace que una
vı́ctima crea que el nodo atacante sea un nodo vecino pero en realidad se encuentra a varios
Juan Manuel Caracoche - Tesis de grado Ingenierı́a Informática
111
9.4.2. Prevención contra ataque de reenvı́o de mensajes: Timestamp
saltos de distancia. Este ataque genera una alteración de la topologı́a de la red y el agresor con
este comportamiento hace que todos los nodos cambien sus tablas de ruteo y lo utilicen a él como
gateway hacia otro extremo de la red.
Este ataque se puede prevenir utilizando un mecanismo estadı́stico/heurı́stico [18, Sec. 4.4]
teniendo en cuenta algunas caracterı́sticas del medio de fı́sico y de las interfaces de red. Teniendo
en cuenta que las placas de red utilizadas hoy en dı́a tienen un radio de cobertura R, por ejemplo
máximo 100mts (este valor parametrizable en el protocolo) y suponiendo que la velocidad de
propagación de la señal wireless c en el aire es cercana a la velocidad de propagación de la luz en
el vacı́o, 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únel y en caso
contrario, no (L <= R).
La implementación de este sencillo algoritmo consiste en el siguiente procedimiento: Durante
el Procedimiento de Autenticación, cuando B recibe el primer mensaje de A (Paso 1), B inicializa
un contador y envı́a la respuesta a A (Paso 2), cuando A le responde, B detiene el contador y
envı́a 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 confiable, en caso contrario y se completa satisfactoriamente el paso 4, B
inserta a A como vecino seguro.
El procedimiento seguido por A es análogo, con la diferencia que A inicializa el contador en
el Paso 1 antes de enviar el primer mensaje hacia B.
9.4.2.
Prevención contra ataque de reenvı́o de mensajes: Timestamp
Otro de los ataques analizados en la Sección 6.6 es el Ataque por Reenvı́o de Mensajes, el cual
consiste en grabar trafico de la red y reproducirlo en otro momento. Este ataque es posible porque
los números de secuencias, son números 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ón 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ón de timestamps. En [30, Sec. V] se proponen distintas
alternativas de implementación. En esta propuesta se utilizará la idea desarrollada en [21], la cual
no depende de la sincronización de relojes y es un intercambio simple de mensajes.
La propuesta planteada en [21], consiste en un diálogo para intercambiar los relojes de cada
extremo. Para esto utiliza mensajes especiales.
En esta tesis se utilizará la idea de [21] pero no se utilizarán mensajes especiales sino que el
intercambio de relojes se llevará a cabo durante el proceso de autenticación donde se agregará a
los mensajes la hora de cada nodo (notar que la modificación se hizo sobre los mensajes de
autenticación básicos y no sobre los detallados en el proceso de intercambio de claves del nivel 1
de securización). 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 modificar el
mensaje AUTH MESSAGE para agregar un campo para el timestamp.
112
Juan Manuel Caracoche - Tesis de grado Ingenierı́a Informática
Detalles de Implementación del Esquema de Seguridad Propuesto
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álculo 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 continuación evalúa T0 − S < TN y T0 + S > TN , donde T0 es la
diferencia horaria almacenada en la tabla de vecinos. En caso que la validación del timestamp
sea correcta se procesa el mensaje, en caso contrario se descarta.
Para compensar algún 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ón del timestamp, se modifica el mensaje de firma del paquete generado
en el nivel 1 de securización ya que es necesario que el timestamp pertenezca a este mensaje para
garantizar la frescura del paquete. El nuevo mensaje de firma (Figura 9.13) contiene el timestamp,
el cual es parte de los campos a tener en cuenta en para la firma ya que es necesario que ese
campo no sea alterado.
0
1
2
3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
SCHEMA
|
ALGORITHM
|
Reserved
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
TIMESTAMP
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
SIGNATURE (160 bits)
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figura 9.13: Formato del mensaje firma con timestamp
9.4.3.
Prevención contra ataques de DoS
Uno de los ataques más comunes son los ataques de Denegación de Servicio. Estos ataques
pueden ser realizados de distantas maneras, por ejemplo un nodo malicioso o mal configurado
podrı́a enviar docenas de mensajes de autenticación por segundo haciendo un desgaste de energı́a
procesando el mensaje en el nodo receptor.
Una manera sencilla de mitigar este tipo de ataque es mantener un contador por cada dirección
de origen que envı́a un mensaje. Cuando el nodo recibe un mensaje de un determinado origen,
guarda ese registro en una tabla e inicializa un contador. Si este nodo recibe más mensajes del
nodo agresor en el lapso de tiempo en el cual en contador todavı́a está activo rechaza el mensaje.
Esta prevención no tiene efecto si el nodo agresor realiza un spoofing de IP. En este caso el
protocolo cuenta con un mecanismo de aceptación de paquetes de manera estadı́stica para no
saturar el nodo. Se establecen umbrales que son configurables para el protocolo y en base a esos
umbrales se calcula cuando comienza a atender de manera estadı́stica.
Juan Manuel Caracoche - Tesis de grado Ingenierı́a Informática
113
9.4.4. Otros ataques mitigados
9.4.4.
Otros ataques mitigados
Con el solo hecho de la securización alcanzada en el Nivel 1, se pueden prevenir los ataques
que involucran la modificación de los paquetes como Generación Incorrecta de Mensajes HELLO,
Generación Incorrecta de Mensajes TC, ya que ningún nodo puede hacerse pasar por otro porque
los nodos están autenticados. Otros ataques pasivos son mitigados porque nodos que escuchan el
tráfico no pueden interpretarlo ya que está encriptado.
9.4.5.
OLSR RFC 3226 vs. OLSR Seguro
Realizando una comparación rápida entre el protocolo original (RFC 3626) y el fortalecimiento
propuesto, se puede ver que no se modifica el funcionamiento pero sı́ se agregan capas de seguridad
y algunas modificaciones mı́nimas a las Etapa 1 (Censado y Descubrimiento de Vecinos) y la
Etapa 2 (Elección de MPR). En la Figura 9.14 se puede ver de manera esquemática como se ha
empaquetado el protocolo original para hacerlo seguro.
Figura 9.14: Etapas del protocolo OLSR
114
Juan Manuel Caracoche - Tesis de grado Ingenierı́a Informática
Detalles de Implementación del Esquema de Seguridad Propuesto
9.5.
Fortalecimiento de OLSR: Nivel 3
Ya a esta altura con los dos niveles de seguridad especificados 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 definen dos mecanismos. Uno, el mismo protocolo implementa un mecanismo de denuncia de los nodos que están 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ón de Intrusos. Los mecanismos descriptos en este nivel es una opción más planteada en
esta tesis para hacer la red segura pero no será analizada en profundidad con lo cual son objeto
de estudio futuro.
9.5.1.
Mecanismo de Denuncia
Una alternativa de autodefensa serı́a que si un nodo detecta que está siendo vı́ctima de un
ataque pueda reportar este incidente a una CA. Las CAs que están conectadas al backbone
de la red mantienen un diálogo sobre los reportes enviados por los nodos. Las CAs reciben
estos incidentes pero solo toman como válidos los que provienen de algún nodo con un nivel de
confiabilidad alto (umbral parametrizable en el protocolo) y se tomará una acción cuando más de
un nodo (valor parametrizable) confiable realice una denuncia (Voto Calificado). En ese momento
se genera una revocación del certificado y es anunciado a todas las CAs de la red.
9.5.2.
Sistema de Detección de Intrusos
Un Sistema de Detección de Intrusos es muy utilizado en el ámbito 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 configurado para que actualice la base de conocimientos
o el mismo IDS puede aprender, en cambio el mecanismo de denuncia es algo fijo que tiene el
protocolo y cualquier cambio que se quiera realizar requiere una modificación del protocolo y
redistribución del mismo.
9.5.2.1.
Interacción con las CAs
El IDS, es un nodo más que pertenece a la red y los clientes lo ven como un cliente más. El
IDS debe correr en un nodo seguro de la red y poseer un certificado especial para comunicarse
con las CAs.
El IDS detecta un comportamiento extraño de un determinado nodo y envı́a la noticia a las
CAs que tiene a su alcance. La conexión con las CAs se hace con una conexión SSL de dos vı́as
(el nodo valida la identidad de la CA y la CA la del nodo mediante los certificados). Una vez que
la CA recibió el mensaje actualiza su CRL.
9.5.3.
Sincronización de CRLs
Las CAs, en una red móvil urbana van a ser nodos interconectados a través del backbone de
la red y van a tener un enlace estable, con lo cual garantiza cierta confiabilidad de interconexión.
Juan Manuel Caracoche - Tesis de grado Ingenierı́a Informá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. Periódicamente
una CA recorre el las CAs disponibles y establece una conexión SSL de dos vı́as con otra CA
y le pide su CRL y actualiza la propia agregando las entradas que no tiene. Antes de proceder
con la actualización de la CRL, verifica si la fecha de actualización de la CRL descargada de la
CA remota en más vieja que la se tiene no se hace nada, en caso contrario se procede con la
actualización.
9.6.
Debilidades del Esquema de Seguridad propuesto
El esquema de seguridad propuesto en esta tesis garantiza los servicios básicos 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
fı́sica, donde un nodo puede ser vı́ctima de interferencias del nodo agresor (jamming) impidiendo
la comunicación con el resto de sus vecinos, ataques de capa dos (enlace) donde el nodo agresor
puede hacer spoofing de MAC address o en capa de red spoofing de IP.
Con esta debilidad expuesta, un nodo que fue excluido de la red podrı́a reingresar como un
nodo nuevo cambiándose su dirección IP y su MAC address. En este caso la red lo reconoce como
un nodo nuevo y la confianza que habı́a 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 implementación del esquema de seguridad
propuesto para una red móvil urbana. Este esquema se divide en dos partes, la primera que
involucra el aspecto organizacional de una red móvil urbana y la segunda es la modificación 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áficos para garantizar autenticación, confidencialidad y no repudio. El Nivel
2 mitiga distintos ataques y por último el Nivel 3, el cual es objeto de estudio futuro incorpora
un mecanismo de autodefensa de la red.
116
Juan Manuel Caracoche - Tesis de grado Ingenierı́a Informática
Capı́tulo 10
Prueba de Contenido
El objetivo de este capı́tulo es describir como se realizó la prueba de contenido
para demostrar el funcionamiento de algunas modificaciones introducidas al protocolo
OLSR para mejorar su seguridad dentro de un ámbito urbano .
En el Capı́tulo 9 se dieron los detalles sobre los distintos niveles de securización propuestos en
esta tesis para el protocolo OLSR. Para confirmar el correcto funcionamiento de la modificación
al protocolo original, se realizó una prueba de contenido donde se implementaron algunas de las
nuevas funcionalidades. A lo largo de este capı́tulo se detallará como fue implementada la prueba
de contenido.
Para realizar la prueba es necesario contar con una red móvil funcionando con una cantidad
de nodos determinada y distribuı́dos de manera tal que un nodo deba rutear a través de otro
para llegar al destino. Este escenario en un ambiente de laboratorio es muy difı́cil de conseguir
con lo cual se desarrolló un simulador para poder probar el protocolo.
Las funcionalidades implementadas en el simulador son:
Implementación de la Autoridad Certificante.
Descubrimiento de Autoridades Certificantes.
Solicitud de un certificado por parte del nodo.
Firmado del Requerimiento y emisión del certificado válido para la red.
Descubrimiento de Vecinos.
Autenticación de Vecinos.
117
10.1. Arquitectura
10.1.
Arquitectura
El protocolo OLSR es un programa que es ejecutado en la capa de aplicación, es decir utiliza
las capas inferiores para enviar mensajes y en base a ellos modifica la tabla de rutas del Sistema
Operativo sobre el cual corre.
La implementación de la prueba de contenido se realizó de la misma manera pero en este caso
no es parte del objetivo de la misma realizar la modificación de la tabla de rutas del SO base.
Otra de las premisa de la implementación es que no contempla cambios de topologı́a durante cada
una de las etapas. La prueba asume que el escenario se mantiene estático y no sufre alteraciones.
El simulador fue codificado en Java, utilizando librerı́as open source para la manipulación de
certificados.
La arquitectura básica del simulador esta constituida por cuatro módulos (Figura 10.1). El
módulo de procesamiento de mensajes OLSR (MulticastDaemon), el módulo de la Autoridad
Certificante (CAModule), el módulo de autenticación con los vecinos (AuthDaemon) y el nodo
propiamente dicho (Node).
Figura 10.1: Principales módulos del simulador
118
Juan Manuel Caracoche - Tesis de grado Ingenierı́a Informática
Prueba de Contenido
10.1.1.
Certificados y Keystores
Como un nodo debe manejar certificados y la prueba de contenido fue desarrollada en Java,
este lenguaje hace uso de Keystores para almacenar los certificados del programa Java [33].
En particular en esta implementación se eligió usar dos Keystore independientes, uno con el fin
de almacenar la identidad del nodo y el otro para almacenar los certificados de los nodo confiados.
Ası́ el proceso Java cuando establece una conexión SSL o necesita verificar algún certificado que
le fue presentado hace uso de estos repositorios para validarlos.
10.1.2.
Configuración del Nodo
Cada nodo cuenta con un archivo de configuración en el cual se le especifica entre otras cosas
cuales son los Keystores del nodo (identidad y confianza), parámetros necesarios para hacer uso
de los mismos, dirección IP principal del nodo, si el nodo va a actuar como CA o no y el path al
archivo de topologı́a de la red.
El archivo de topologı́a de red es un archivo en formato XML en el cual está el escenario
básico sobre el cual se inicia el nodo. En este archivo está el listado de vecinos, la tabla de ruteo,
el listado de links con los vecinos, tabla de topologı́a, etc. En particular en esta implementación
ese archivo contiene la estructura de un red vacı́a, sin ningún vecino.
10.1.3.
Plugin olsrd para generar el archivo de topologı́a
Para crear el archivo de topologı́a se creo un plugin de olsrd el cual imprime en formato XML
toda la información de las tablas del protocolo. El formato del archivo XML fue diseñado para
ser usado luego con XStream 1 y poder construir el objeto Nodo.
El plugin fue programado en base a las facilidades que da la implementación de olsrd para
realizar este tipo de extensiones. Esta extensión escucha en un socket y cuando se establece una
conexión, imprime el contenido de las tablas en formato XML.
Desde el simulador existe un modulo llamado DataCollector, el cual podrı́a ser utilizado para
actualizar en cualquier momento la topologı́a de la red del simulador con la topologı́a real de
la red en la cual está participando el nodo. Esta funcionalidad fue desarrollada para generar el
archivo de topologı́a que usa el simulador para cada nodo, pero no se utiliza para actualizar la
información del nodo.
10.1.4.
Mensajes
El diseño de los mensajes se hizo teniendo en cuenta los originales del protocolo y extendiendo
éstos con los mensajes modificados 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 método abastracto llamado processMessage(), el cual obliga a cada
mensaje que lo extiende a implementar este método que tiene como objetivo que cada mensaje
sepa como procesarse. De esta manera los servidores que reciben algún mensaje no tienen que
1 http://xstream.codehaus.org/
Juan Manuel Caracoche - Tesis de grado Ingenierı́a Informática
119
10.1.5. Módulo de Autoridad Certificante
Figura 10.2: Diagrama de Clases para los mensajes del protocolo
tener la lógica de procesamiento, sino que cada uno sabe cuál es su función y se procesa a si
mismo y genera una respuesta.
10.1.5.
Módulo de Autoridad Certificante
El módulo de Autoridad Certificante, es una clase que se ejecuta en un thread independiente,
establece un socket y se queda esperando por peticiones de certificados. El nodo tiene un archivo
120
Juan Manuel Caracoche - Tesis de grado Ingenierı́a Informática
Prueba de Contenido
de configuración donde uno de las propiedades a configurar es si el nodo va a actuar como CA
o no. En caso que ası́ sea, se especifica cual el es Keystore donde se encuentra su certificado
expedido por la Root CA de la comunidad.
Este módulo no solo tiene la responsabilidad de lanzar el servidor, sino que cuenta con todos
los métodos necesarios para manipular los certificados.
10.1.6.
Módulo de Autenticación con los vecinos
Una vez que el nodo tiene un certificado válido para participar en la red, necesita autenticarse
con los vecinos para hacer uso de la misma. Para ello el nodo cuenta con este módulo que lanza
un servidor el cual queda a la espera de mensajes de autenticación. Este módulo utiliza los dos
Keystores configurados para el nodo. El de identidad lo utiliza para enviar su propio certificado
en el mensaje AUTH MESSAGE y utiliza el de confianza para almacenar los certificados de los vecinos
confiados.
Para simplificar la implementación del proceso de autenticación de los vecinos, se implementó las primeras dos fases 9.3.3.1 como un handshaking de SSL en el cual se realiza una
autenticación de SSL de dos vı́as. La autenticación SSL de dos vı́as [34, Cap. 10] consiste en que
el server cuando recibe una petición de conexión, obliga al cliente a presentar su certificado y
a la vez el servidor le envı́a su certificado al cliente. De esta manera en ambos lados se evalúa
la cadena de certificación de los mismos y la validez. Una vez que ambos nodos se autenticaron
envı́an el mensaje AUTH MESSAGE FINISH y los nodos confı́an entre si. Este módulo utiliza los
métodos del Módulo de CA para validar la cadena de certificación.
10.1.7.
Módulo de Procesamiento de mensajes OLSR
El módulo 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 método processMessage() de cada uno de ellos para que se auto-procesen y luego
poder enviar el mensaje de respuesta.
10.2.
Implementación
A lo largo de esta sección se van a presentar algunos detalles de implementación del simulador
para dar una idea al lector sobre como fue desarrollado sin entrar en detalles propios de la
programación.
10.2.1.
Descubrimiento de CAs y Vecinos
El nodo que quiere ingresar a la red realiza como primera acción un descubrimiento de las
Autoridades Certificantes de la red para realizar posteriormente el pedido del certificado. 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.
Juan Manuel Caracoche - Tesis de grado Ingenierı́a Informática
121
10.2.2. Autoridad Certificante
Cuando un vecino recibe el mensaje, agrega al nodo que originó el mensaje como vecino,
inserta en el mensaje recibido el listado de CAs que él conoce y luego envı́a la respuesta pero
con dirección 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 éste como
vecino e inserta en la tabla de topologı́a las CAs informadas por el vecino.
De esta manera el proceso de descubrimiento tiene doble propósito, 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 implementación del simulador el demonio escucha en la
dirección 228.0.0.23:4444
10.2.1.1.
Demonio de Procesamiento de mensajes OLSR
La implementación del demonio de procesamiento de mensajes de OLSR es muy sencilla. La
clase MulticastDaemon tiene un método 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 método processMessage() del mensaje recibido, el cual sabe que es lo que tiene que
hacer.
Figura 10.3: Diagrama de Secuencia para la firma de un CertReq
10.2.2.
Autoridad Certificante
La Autoridad Certificante fue implementada dentro del módulo CAModule. Cuando se instancia esta clase, se inicia un thread que lanza la clase CAServer, la cual establece un socket que
122
Juan Manuel Caracoche - Tesis de grado Ingenierı́a Informática
Prueba de Contenido
espera peticiones SSL en el puerto 4443.
La Autoridad Certificante solo es iniciada si en el archivo de configuración del nodo
(config.properties), se especificó la propiedad enableCA=true.
Como se dijo anteriormente, la clase CAModule, no solo laza la clase CAServer, sino que tiene
métodos estáticos para realizar la gestión de certificados.
Cuando el servidor recibe una conexión de un nodo, invoca el método precessMessage()(Figura 10.3) el cual valida que el mensaje sea tipo CERT REQ y luego firma el requerimiento
invocando el método de clase signCertReq() de la clase CAModule. Finalmente con el certificado
firmado, genera un mensaje de respuesta (CERT REPLY) y se lo envı́a al nodo.
Figura 10.4: Diagrama de Secuencia de la obtención de un certificado
10.2.2.1.
Interacción Nodo-CA
El servidor de la CA crea un socket de tipo SSLServerSocket en cual utiliza el keystore de
identidad para enviar su certificado al cliente que establece la conexión. En este punto, el nodo
cliente, valida la cadena de certificación del certificado presentado por la CA. El nodo puede
realizar esta tarea ya que en el keystore de confianza tiene el certificado de la Root CA de la
comunidad. Una vez validada la identidad de la CA, se envı́a el mensaje CERT REQ. El nodo
cliente utiliza la clase Tools que tiene el método makeSSLConnection() que realiza la conexión
SSL y valida la cadena de certificación del servidor.
La CA envı́a el mensaje CERT REPLY con el certificado firmado para poder participar de la red.
El nodo cliente valida el certificado recibido, lo almacena e inicia el demonio de Autenticación
con los Vecinos. En la Figura 10.4 se puede ver el diagrama de secuencia simplificado para la
obtención de un certificado.
10.2.3.
Autenticación con los Vecinos
Una vez que el nodo que quiere ingresar a la red obtiene un certificado válido, inicializa el
demonio de Autenticación con los vecinos. El demonio de autenticación inicia un servidor con un
socket SSL (puerto 4444), pero en este caso a diferencia del módulo de CA, se instancia para que
Juan Manuel Caracoche - Tesis de grado Ingenierı́a Informática
123
10.3. Modos de Operación del Simulador
solicite al cliente que presente su certificado y ası́ validar que éste tiene un certificado expedido
por una CA válida (Autenticación SSL de dos vı́as). Esta autenticación se realizó para simplificar
la implementación y realiza los pasos 1 y 2 de la autenticación propuesta en la Sección 9.3.3.1.
Ambos nodos luego de autenticarse, actualizan su tabla de vecinos indicando que el vecino es
confiable y almacena el certificado en el keystore de confianza.
Para realizar la autenticación SSL de dos vı́as, se utilizan los dos keystores, uno para enviar
su identidad y el otro para validar la cadena de certificación del certificado del vecino.
10.3.
Modos de Operación del Simulador
(a) Módulos instanciados por el nodo en modo
CA
(b) Módulos instanciados por el nodo en modo
cliente
Figura 10.5: Instanciación de módulos dependiendo el modo de operación
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 módulos (Figura 10.5(a)):
Módulo de CA (CAModule), el cual contiene el sservidor que atiende las peticiones de los
clientes (CAServer).
Módulo de procesamiento de mensajes multicast (MulticastDaemon), el cual contiene el
servidor de mensajes multicast que recibe la información y peticiones de los nodos vecinos.
124
Juan Manuel Caracoche - Tesis de grado Ingenierı́a Informática
Prueba de Contenido
Módulo de Autenticación con los vecinos (AuthDaemon).
En caso que el nodo sea ejecutado como cliente, se inicializan los siguientes módulos (Figura 10.5(b)):
Módulo de procesamiento de mensajes multicast (MulticastDaemon).
Módulo de Autenticación con los vecinos (AuthDaemon).
10.4.
Resumen
A lo largo de este capı́tulo de dieron detalle de las mejoras propuestas en la tesis para el
protocolo OLSR implementadas en la prueba de contenido. Para fundamentar la propuesta de
esta tesis, se realizó un simulador que implementa algunas de las mejoras. Con este simulador
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 implementación
en Java dista de la real desarrollada en C.
Juan Manuel Caracoche - Tesis de grado Ingenierı́a Informática
125
10.4. Resumen
126
Juan Manuel Caracoche - Tesis de grado Ingenierı́a Informática
Capı́tulo 11
Conclusiones
En este trabajo de tesis se presentó un Esquema de Seguridad para una Red Móvil Urbana.
Para la elaboración 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 técnico y diferentes alternativas
para realizar un mismo objetivo, rutear paquetes sobre una Red Móvil. Superada esta etapa y
viendo que los protocolos de ruteo de redes móviles en su mayorı́a no contemplaban cuestiones
relacionadas con la seguridad es que se vió 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 Móvil hubo
que remontarse a conceptos básicos de seguridad para saber cuales son los servicios básicos que
debe brindar una red segura. Con los concepto de seguridad básicos dentro de las herramientas
disponibles para allanar el camino hacia el objetivo de la tesis, se extendieron esos conceptos a
Redes Móviles donde se vio que hay que agregar variables como que los nodos son a baterı́as, se
mueven, y no tienen grandes capacidades de procesamiento.
Ya a esta altura se cuenta con los conocimiento de Redes Móviles, con los requisitos básicos
que debe cumplir un protocolo para ser considerado seguro. El siguiente paso fue estudiar que
protocolos “seguros” habı́a disponibles y ver de que manera cumplı́an con los requisitos.
Un aspecto clave para alcanzar el objetivo es estudiar como son, como se comportan y como
se organizan las redes Urbanas, donde se encontró que en su mayorı́a están administradas por
comunidad sin fines de lucro. Fue fundamental conocer como es en particular la administración y
organización de una Red Móvil Urbana como lo es Buenos Aires Libre para saber que el protocolo
más difundido entre las Redes Móviles Urbanas es el OLSR.
El siguiente paso fue profundizar sobre el funcionamiento de este protocolo y analizar cuales
serı́an los posibles ataques que podrı́a sufrir.
Con el conocimiento técnico del funcionamiento y vulnerabilidades del protocolo OLSR más
los aspectos organizativos de una Red Móvil Urbana ya se contaba con los elementos suficientes
para enfrentarse a la última parte hacia el objetivo final.
127
Luego de la lectura de varios artı́culos con propuestas de securización para OLSR, tomando
ideas de cada uno de ellos y poniéndolas dentro del marco de una Red Móvil Urbana es que
desarrolló la propuesta de securización del protocolo OLSR.
Dentro de los artı́culos leı́dos, ninguno de ellos daba una solución completa como la propuesta
en esta tesis. La propuesta incluye:
La distribución de claves por medio de certificados digitales.
Se especificó una polı́tica organizacional para distribuir entidades certificadoras
Elaboración de un esquema de confianza de un nodo y la participación del mismo en la red.
Se especificó un mecanismo de reconocimiento y autenticación con los vecinos.
Se especificó un mecanismo de intercambio de claves
Se utilizó una forma para firmar mensajes de control
Se utilizó un algoritmo de encriptación simétrico combinado con la clave compartida para
la encripción de los mensajes de control
Prevención de Ataques
Alta disponibilidad de CAs
El esquema propuesto presenta distintos niveles de seguridad, los cuales pueden ser implementados en distintas etapas y podrı́an conformar módulos agregados a la implementación actual
del protocolo OLSR.
La propuesta muestra como se pueden prevenir ataques tı́picos al protocolo OLSR. Se incorporaron mecanismos como por ejemplo un algoritmo simple de timestanping, una heurı́stica
sencilla para detectar si un nodo está intentando hacer un ataque de túnel, un esquema de firmas
para garantizar la integridad de los mensajes y un mecanismo de encripción para garantizar la
confidencialidad de los paquetes de OLSR.
La solución puede ser escalable para incorporar mecanismos de autodefensa como el uso de
un IDS.
Se construyó una solución que cumple con la premisas básicas para que una Red Móvil sea
considerada segura. Se mejoraron aspectos existentes en algunas soluciones y se agregaron nuevas
soluciones.
Finalmente para asegurar el funcionamiento de la propuesta, se implementó un simulador
para realizar la prueba de contenido donde se muestra el funcionamiento del protocolo durante la
incorporación de un nodo a la red. Esta prueba incluye el descubrimiento de las CAs, la obtención
de un certificado para participar en la red y la autenticación con los vecinos
128
Juan Manuel Caracoche - Tesis de grado Ingenierı́a Informática
Bibliografı́a
[1] Stefano Basagni, Marco Conti, Silvia Giordano, Ivan Stojmenovic.Mobile Ad-Hoc Networking, IEEE Press, 2004.
[2] Mehran Abolhasan, Tadeusz Wysocki, Eryk Dutkiewcz. A review of routing protocols for ad
hoc networks, Elsevier, 2004.
[3] Charles E. Perkins, Pravin Bhagwat. Highly Dynamic Desditation-Sequenced Distance-Vector
Routing (DSDV) for Mobile Computers, SIGCOMM 94, pp 234-244, 1994.
[4] D. Bertsekas, R. Gallager. Data Networks, Prentice-Hall, pp 297-333, 1987.
[5] T. Clausen, P. Jacquet. Optimized Link State Routing Protocol (OLSR), RFC 3626, 2003.
[6] P. Jacquet, P. Mühlethaler, 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 Configuration 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ÍA
[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 Certificate 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] Cédric Adjih, Daniele Raffo, Paul Mühlether. 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 Specifications 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 Efficient 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 Certificate Request Message Format.
RFC 2511 ,1999.
[28] T. Dierks, C. Allen. The TLS Protocol. RFC 2246, 1999.
[29] R. Housley, W. Ford, W. Polk, D. Solo. Internet X.509 Public Key Infrastructure Certificate
and CRL Profile, RFC 2459, 1999.
[30] Cedric Adjih, Thomas Clausen, Philippe Jacquet, Anis Laouiti, Paul Mühlethaler, Daniele
Raffo. Securing the OLSR protocol. INRIA Rocquencourt, Project Hipercom.
130
Juan Manuel Caracoche - Tesis de grado Ingenierı́a Informática
BIBLIOGRAFÍA
[31] William Stallings. Cryptography and Network Security. 4ta Edicion, 2006.
[32] Douglas R. Stinson. Cryptography : Theory and Practice, 3era Edicion, 2002.
[33] Scott Oaks. Java Security. O’Reilly, 2da Edicion, 2001
[34] David Hook. Beginning Cryptography in Java, John Wiley & Sons, 2005.
[35] Oficina Nacional de Tecnologı́a de la Información República Argentina (ONTI). Modelo
de Polı́tica de Seguridad de la Información para Organismos de la Administración Pública
Nacional, Versión 1, Julio 2005
Juan Manuel Caracoche - Tesis de grado Ingenierı́a Informática
131