168MC Javc PDF

S.E.P. S.E.I.T. D.G.I.T.
CENTRO NACIONAL DE INVESTIGACIÓN

Y DESARROLLO TECNOLÓGICO
cenidet
SEGURIDAD EN EL ENRUTAMIENTO DEL PROTOCOLO AODV

PARA REDES MÓVILES AD HOC
T E S I S
QUE PARA OBTENER EL GRADO DE :
MAESTRO EN CIENCIAS EN
INGENIERÍA ELECTRÓNICA
P R E S E N T A :
JOSÉ ALONSO VILLANUEVA CRUZ
DIRECTOR DE TESIS
M. C. CARLOS FELIPE GARCÍA HERNÁNDEZ
CUERNAVACA, MORELOS MARZO DE 2005

CONTENIDO
Lista de figuras ......................................................................................................... v

Lista de tablas ........................................................................................................... vii
Introducción
Problemática .................................................................................................................. 2
Motivación ..................................................................................................................... 2
Objetivo general............................................................................................................. 3
Objetivos particulares .................................................................................................... 3
Aportaciones .................................................................................................................. 3
Organización de la tesis ................................................................................................. 4
Capítulo 1: Tecnologías inalámbricas y móviles

Introducción ................................................................................................................... 5
1.1 Estándar IEEE 802.11x.......................................................................................... 5
1.1.1 Topologías ............................................................................................. 6
1.1.2 ESSID .................................................................................................... 7
1.1.3 Beacon Frames....................................................................................... 7
1.1.4 Medidas de seguridad ............................................................................ 7
1.1.4.1 WEP....................................................................................... 8
1.1.4.2 WPA ...................................................................................... 10
i
1.1.4.3 IEEE 802.11i ......................................................................... 12
1.2 Bluetooth................................................................................................................ 13
1.2.1 Arquitectura de seguridad Bluetooth ..................................................... 13
1.2.2 Autentificación....................................................................................... 15
1.2.3 Cifrado con el sistema de cifrado de flujo E0 ........................................ 15
1.3 Sistema Global de Comunicaciones Móviles ........................................................ 16
1.3.1 Arquitectura de red GSM....................................................................... 17
1.3.2 Modelo de seguridad GSM.................................................................... 19
1.4 Tendencias ............................................................................................................. 21
1.4.1 IEEE 802.16........................................................................................... 21
1.4.2 UWB ...................................................................................................... 22
1.4.3 UMTS .................................................................................................... 22
1.4.4 Redes móviles Ad hoc ........................................................................... 23
1.5 Sumario .................................................................................................................. 24
Capítulo 2: Redes móviles Ad hoc

Introducción ................................................................................................................... 25
2.1 Definición de red móvil Ad hoc ............................................................................ 25
2.2 Protocolos de enrutamiento ................................................................................... 26
2.3 Introducción al protocolo AODV .......................................................................... 27
2.3.1 Descubrimiento de rutas ........................................................................ 28
2.3.2 Mantenimiento de rutas ......................................................................... 31
2.4 Seguridad en redes móviles Ad hoc....................................................................... 32
2.4.1 Objetivos de seguridad .......................................................................... 32
2.4.2 Desafíos de seguridad ............................................................................ 33
2.4.3 Ataques en AODV ................................................................................. 33
2.5 Esquemas de seguridad .......................................................................................... 35
2.5.1 Seguridad en el enrutamiento ................................................................ 36
2.5.2 Detección de intrusos............................................................................. 36
2.6 Sumario .................................................................................................................. 38
ii
Capítulo 3: Entorno de simulación
Introducción ................................................................................................................... 39
3.1 El simulador ns-2 ................................................................................................... 39
3.2 Estructura de ns-2 .................................................................................................. 40
3.3 Redes móviles ........................................................................................................ 41
3.3.1 Nodos móviles ....................................................................................... 42
3.3.2 Transmisión de paquetes........................................................................ 43
3.3.3 Recepción de paquetes........................................................................... 44
3.4 Metodología de simulación.................................................................................... 44
3.4.1 Generador de movilidad ........................................................................ 45
3.4.2 Generador de tráfico .............................................................................. 47
3.4.3 Configuración de nodos......................................................................... 48
3.5 Archivos de traza ................................................................................................... 49
3.6 Herramienta Network Animator, nam ................................................................... 51
3.7 Herramientas para procesar datos .......................................................................... 53
3.7.1 Awk........................................................................................................ 53
3.7.2 Gnuplot .................................................................................................. 53
3.8 Sumario .................................................................................................................. 54
Capítulo 4: Diseño e implementación de simulaciones

Introducción ................................................................................................................... 55
4.1 Escenarios de simulación....................................................................................... 55
4.2 Implementación del ataque de número de secuencia............................................. 56
4.3 Diseño de solución................................................................................................. 61
4.3.1 Esquema propuesto ................................................................................ 61
4.3.2 Requerimientos del sistema de detección de intrusos ........................... 62
4.4 Implementación del módulo de detección de ataque ............................................. 63
4.5 Resultados de simulación....................................................................................... 66
4.6 Sumario .................................................................................................................. 75
iii
Capítulo 5: Conclusiones
Introducción ................................................................................................................... 77
5.1 Conclusiones .......................................................................................................... 77
5.2 Trabajos futuros ..................................................................................................... 80
Lista de acrónimos .................................................................................................. 81

Referencias ................................................................................................................ 87
Anexo A...................................................................................................................... 93
Anexo B ...................................................................................................................... 95
Anexo C ...................................................................................................................... 97
iv
Lista de figuras
1-1 Cifrado WEP.................................................................................................................... 9
1-2 Descifrado WEP............................................................................................................... 9
1-3 Autentificación mediante clave compartida..................................................................... 10
1-4 Autentificación en WPA .................................................................................................. 11
1-5 Arquitectura de seguridad Bluetooth ............................................................................... 14
1-6 Descripción del proceso de cifrado.................................................................................. 16
1-7 Arquitectura de una red GSM .......................................................................................... 17
1-8 Autentificación de la estación móvil................................................................................ 20
1-9 Algoritmos y llaves utilizados en GSM ........................................................................... 20
2-1 Ejemplo de red móvil Ad hoc .......................................................................................... 26
2-2 Formato del paquete de petición de ruta (RREQ)............................................................ 29
2-3 Descubrimiento de ruta en AODV................................................................................... 29
2-4 Formato del paquete de respuesta de ruta (RREP) .......................................................... 30
2-5 Camino de regreso en AODV .......................................................................................... 30
2-6 Ejemplo del ataque de número de secuencia ................................................................... 35
3-1 Perspectiva simplificada del ns-2..................................................................................... 41
3-2 Esquema de un nodo móvil en ns-2 ................................................................................. 42
3-3 Resumen de simulación ................................................................................................... 45
3-4 Herramienta nam.............................................................................................................. 52
4-1 Proceso que sigue un nodo normal cuando recibe un mensaje RREQ ............................ 58
4-2 Proceso que sigue el nodo malicioso cuando recibe un mensaje RREQ ......................... 59
4-3 Visualización del ataque en el archivo de traza ............................................................... 60
4-4 Módulo de detección de ataque incorporado en el método recvReply ............................ 62
4-5 Proceso normal que sigue un nodo al recibir un paquete RREP...................................... 63
4-6 Proceso al recibir un paquete RREP con módulo de detección de ataque incorporado .. 64
4-7 Visualización con nam - bajo ataque ............................................................................... 67
4-8 Visualización con nam – módulo de detección incorporado ........................................... 68
4-9 Tasa de entrega versus número de conexiones ................................................................ 68
4-10 Tasa de entrega versus movilidad de los nodos ............................................................. 69
4-11 Número de RREP enviados versus número de conexiones (condiciones normales)..... 69
4-12 Número de RREP enviados versus número de conexiones (bajo ataque) ..................... 70
v
4-13 Número de RREP enviados versus número de conexiones (módulo de detección y
bajo ataque) ................................................................................................................... 70
4-14 Número de RREP enviados versus movilidad de los nodos (condiciones normales).... 71
4-15 Número de RREP enviados versus movilidad de los nodos (bajo ataque) .................... 71
4-16 Número de RREP enviados versus movilidad de los nodos (módulo de detección y
bajo ataque) ................................................................................................................... 72
4-17 Tasa de entrega versus número de conexiones (precisión en detección)....................... 72
4-18 Tasa de entrega versus movilidad de los nodos (precisión en detección)...................... 73
4-19 Retardo promedio versus número de conexiones .......................................................... 74
4-20 Retardo promedio versus movilidad de los nodos ......................................................... 74
vi
Lista de tablas
1-1 Tres normas fundamentales de 802.11............................................................................. 6
3-1 Contenido de los archivos de traza .................................................................................. 50
3-2 Contenido de los archivos de traza para paquetes de enrutamiento................................. 51
4-1 Archivos que fueron modificados para implementar el ataque ....................................... 57
4-2 Parámetros de simulación ................................................................................................ 67
vii
Capítulo 1
Tecnologías inalámbricas y móviles
Introducción
En este capítulo se presenta una visión general de las principales tecnologías inalámbricas y
móviles, haciendo un enfoque en los mecanismos de seguridad que se utilizan. Primeramente el
apartado 1.1 se centra en el estándar IEEE 802.11 y algunas de sus variantes, se describen las
topologías y algunos conceptos importantes del estándar. Asimismo, se mencionan los
mecanismos de seguridad y la evolución que éstos han tenido en los últimos años. El apartado 1.2
se refiere a la tecnología Bluetooth, se describe la arquitectura de seguridad, la forma en que se
realiza la autentificación y el sistema de cifrado. En el apartado 1.3 se presenta la tecnología
GSM, se describe la arquitectura de la red y se definen los elementos principales que la
componen y que son fundamentales para entender la seguridad en este sistema. También se
describe el modelo de seguridad utilizado en GSM que corresponde a los métodos de
autentificación y cifrado. En el apartado 1.4 se presentan las tendencias del mercado de las redes
inalámbricas y móviles que parecen tener mayor futuro: IEEE 802.16, UWB, UMTS y redes
móviles Ad hoc. Por último, en el apartado 1.5 se proporciona un resumen de las principales
implicaciones y conceptos considerados en este capítulo.
1.1 Estándar IEEE 802.11x

Los sistemas 802.11 se denominan de forma genérica “Wi-Fi”. La alianza Wi-Fi es el organismo
responsable de la concesión del logotipo de certificación Wi-Fi, que garantiza la compatibilidad
5
con 802.11 y la interoperabilidad de equipos de distintos fabricantes. La norma original 802.11

establecida en junio de 1997 por el IEEE (Instituto de Ingenieros Eléctricos y Electrónicos),
definió un sistema de 2.4 GHz y tenía velocidades de datos de 1 y 2 Mbps. En la actualidad
existen dos categorías básicas de normas WLAN IEEE 802.11 (LAN inalámbrica). Por un lado
están aquellas normas que especifican los protocolos fundamentales para el sistema completo Wi-
Fi. Estas normas se denominan 802.11a, 802.11b y 802.11g. Y por otro lado están las
ampliaciones que surgen para resolver vulnerabilidades o para proporcionar funcionalidades
adicionales a las normas anteriores. Estas son las normas 802.11d, e, f, h, i y j.
La tabla 1-1 muestra las tres normas (estándares) fundamentales de 802.11 y sus principales
características [1].
Tabla 1-1 Tres normas fundamentales de 802.11.
Norma Banda de radio Modulación Cobertura máx. Velocidad máx.

802.11b 2.4 GHz DSSS 100 m. 11 Mbps
802.11a 5 GHz OFDM 50 m. 54 Mbps
802.11g 2.4 GHz OFDM 100 m. 54 Mbps
En un principio la expresión Wi-Fi era utilizada únicamente para los aparatos con tecnología
802.11b, el estándar dominante en el desarrollo de las redes inalámbricas de aceptación
prácticamente universal. Con el fin de evitar confusiones en la compatibilidad de los aparatos y la
interoperabilidad de las redes, el término Wi-Fi se extendió a todos los aparatos provistos con
tecnología 802.11 (ya sea 802.11a, 802.11b, 802.11g, 802.11i, 802.11h, etc, con diferentes
frecuencias y velocidades de transmisión). En la actualidad la mayoría de productos son de la
especificación b y g.
Con respecto a las extensiones del estándar, el IEEE 802.11i trata los temas relacionados con la
seguridad. Hablaremos de éste más adelante.
1.1.1 Topologías
Las redes IEEE 802.11x pueden adoptar dos tipos diferentes de topologías: Ad hoc e
infraestructura. La topología Ad hoc se caracteriza porque no hay Punto de Acceso (AP), las
6
estaciones se comunican directamente entre si, de esta manera el área de cobertura está limitada
por el alcance de cada estación individual. En el modo infraestructura como mínimo se dispone
de un AP, las estaciones inalámbricas no se pueden comunicar directamente, todos los datos
deben pasar a través del AP. Todas las estaciones deben ser capaces de “ver” al AP.
La mayoría de las redes inalámbricas que se encuentran en las empresas utilizan modo
infraestructura con uno o más Puntos de Acceso. El AP actúa como un HUB en una LAN,
redistribuye los datos hacia todas las estaciones. En este capítulo nos enfocamos en esta última
topología.
1.1.2 ESSID
Cada red inalámbrica tiene un ESSID (Identificación mediante el conjunto de servicios
extendidos), que la identifica. Es necesario conocer el ESSID del AP para poder formar parte de
la red inalámbrica, es decir, el ESSID configurado en el dispositivo móvil tiene que concordar
con el ESSID del AP.
1.1.3 Beacon Frames

Los Puntos de Acceso mandan constantemente anuncios de la red, para que los clientes móviles
puedan detectar su presencia y conectarse a la red inalámbrica. Estos “anuncios” son conocidos
como beacon frames (tramas de beacon). Si se monitorea las tramas de una red inalámbrica se
puede ver que normalmente el AP manda el ESSID de la red en los beacon frames, aunque esto
se puede deshabilitar por software en la mayoría de los AP que se comercializan actualmente.
1.1.4 Medidas de seguridad

En un principio las medidas de seguridad comúnmente utilizadas y que aún se continúan
utilizando son las siguientes:
• ACL’s (listas de control de acceso) basadas en MAC’s (control de acceso al medio) sólo
para permitir la comunicación con el AP a las direcciones MAC que el AP conoce.
• No emitir Beacon Frames o emitirlos sin el ESSID.
• Utilizar WEP (Wired Equivalent Privacy. - Privacía Equivalente Alámbrica) [2].
7
De los puntos anteriores, el protocolo WEP fue creado específicamente para proporcionar
seguridad a las redes basadas en el estándar IEEE 802.11x.
1.1.4.1 WEP
El propósito de WEP es garantizar que los sistemas WLAN dispongan de un nivel de

confidencialidad equivalente al de las redes LAN alámbricas, cifrando las señales de radio. Un
propósito secundario de WEP es el de evitar que usuarios no autorizados puedan acceder a las
redes WLAN (proporciona autentificación)
WEP proporciona funciones de cifrado de datos utilizando una clave secreta de 40 bits (débil) en
el estándar 802.11 ó de 128 bits (fuerte) en el estándar 802.11b y un generador de números
seudoaleatorios RC4. Dos procesos son aplicados a los datos en plano (sin cifrar): uno de ellos
cifra dichos datos y el otro lo protege frente a modificaciones no autorizadas mientras están en
tránsito (integridad). La clave secreta se concatena con un vector de inicialización (IV) aleatorio
que añade 24 bits a la clave resultante. Esta clave se inserta en el generador de números
seudoaleatorios que genera un flujo de clave seudoaleatorio de gran longitud. El emisor combina
mediante una operación XOR el flujo de clave con el texto plano para generar el texto cifrado, y
lo transmite al receptor junto con el IV. Al recibir el texto cifrado, el receptor utiliza el IV y su
propia copia de la clave secreta para generar un flujo de clave idéntico al generado por el
transmisor. El receptor combina entonces, mediante la operación XOR, el flujo de clave con el
texto cifrado para obtener el texto plano original.
Para proteger el texto cifrado frente a modificaciones no autorizadas mientras está en tránsito,
WEP aplica un algoritmo de comprobación de integridad (CRC-32) al texto plano, lo que genera
un valor de comprobación de integridad (ICV). El ICV se concatena con el texto plano antes de
ser cifrados con la clave y después se envía al receptor junto con el IV. Al aplicar el algoritmo de
integridad al texto plano y comparar la salida con el valor ICV recibido, se puede verificar si ha
ocurrido alguna modificación. Los procesos de cifrado y descifrado se resumen en las figuras 1-1
y 1-2.
Con respecto a la autentificación, WEP proporciona dos tipos de autentificación: un sistema

abierto, en el que todos los usuarios tienen permiso para acceder a la WLAN y una
autentificación mediante clave compartida que controla el acceso a la WLAN y evita accesos no
8
autorizados a la red. De los dos niveles, la autenticación mediante clave compartida es el modo
seguro. En este sistema se utiliza una clave secreta compartida entre todas las estaciones y AP’s.
Figura 1-1 Cifrado WEP.
Figura 1-2 Descifrado WEP.
Cuando una estación trata de conectarse con un AP, éste replica con un texto aleatorio que
constituye el desafío. La estación debe utilizar su copia de la clave secreta compartida para cifrar
el texto de desafío y devolverlo al AP, con el fin de autenticarse. El AP descifra la respuesta
utilizando la misma clave compartida y la compara con el texto de desafío enviado anteriormente.
Si los dos textos son idénticos, el AP envía un mensaje de confirmación a la estación y acepta a la
estación dentro de la red. Si la estación no dispone de una clave o si envía la respuesta incorrecta,
9
el AP la rechaza evitando que la estación acceda a la red. La autentificación mediante clave

compartida se ilustra en la figura 1-3 [3].
Figura 1-3 Autentificación mediante clave compartida.
En el año 2001 los grupos de investigación de la Universidad de Berkeley y la Universidad de

Maryland publicaron trabajos por separado que revelaban las fallas de seguridad en WEP [4] y
[5]. Al interceptar y decodificar los datos transmitidos, la clave WEP puede ser deducida y se
puede ganar acceso no autorizado. Esta situación desencadenó una serie de acciones por parte del
IEEE y participantes de la industria para mejorar la seguridad de WLAN.
1.1.4.2 WPA
Para solventar las debilidades de seguridad en WEP, la alianza Wi-Fi implementó una solución
provisional: WPA (Wi-Fi con acceso protegido). WPA fue presentado en abril de 2003 y es un
subconjunto de tecnologías que se extrajeron del IEEE 802.11i cuando éste se encontraba en
etapa de borrador. WPA incorpora autentificación mediante 802.1x y EAP (protocolo de
autentificación extensible) además de un nuevo protocolo TKIP (protocolo de integridad con
llave temporal) y un sistema de verificación de integridad llamado Michael [6].
El uso de 802.1x implica normalmente la utilización de un servidor de autentificación RADIUS

(servicio de usuario de acceso telefónico de autenticación remota). Básicamente el proceso que se
sigue para la autentificación es el siguiente:
1. El cliente se asocia con un AP.

2. El AP bloquea el acceso a la LAN hasta que el cliente es autentificado.
3. El cliente proporciona su identificación al servidor de autentificación (RADIUS).
10
• Si no es autentificado, el cliente permanece bloqueado.

• Si es autentificado, el proceso continúa.
4. El servidor de autentificación automáticamente distribuye claves de cifrado al AP y al
cliente.
5. El cliente accede a la red cifrando los datos.
En la figura 1-4 se ilustra el proceso de autentificación.
Figura 1-4 Autentificación en WPA.
Algunos fabricantes han desarrollado varios tipos de autentificación basada en EAP. Los más
comunes son los siguientes: EAP-MD5, EAP-TLS, EAP-TTLS, LEAP y PEAP [7].
Sin embargo en entornos domésticos o de pequeñas oficinas en los que no esté disponible un
servidor de autentificación, existe un modo de trabajo que no necesita nada especial para
funcionar, pero ofrece una cierta seguridad en el acceso de todas formas. Este modo específico de
trabajo se llama modo de clave compartida con antelación o Pre-Shared Key (PSK). Como su
propia denominación nos indica, su único requerimiento es compartir una clave entre los
diferentes clientes que se van a autentificar contra un determinado punto de acceso que también
la conoce. Si la clave de un cliente inalámbrico coincide con la del correspondiente AP se le
otorga acceso, denegándolo en caso contrario. Esta clave no se envía al AP al intentar la
autentificación sino que es el origen de un trabajo criptográfico que finalmente conduce a la
autentificación, por lo que no es posible averiguarla rastreando las emisiones [6].
11
En WPA el cifrado de datos es obligatorio, a diferencia con WEP que es opcional. El protocolo
TKIP utiliza claves de 128 bits y pasa de ser única y estática a ser generada de forma dinámica
para cada usuario, para cada sesión (teniendo una duración limitada) y por cada paquete enviado.
Conceptualmente el vector de inicialización pasa de 24 a 48 bits, minimizando la reutilización de
claves. TKIP utiliza el algoritmo Michael para garantizar la integridad, generando un bloque de 4
bytes (denominado MIC) a partir de la dirección MAC de origen, de destino y de los datos,
añadiendo el MIC calculado a la unidad de datos a enviar. Posteriormente los datos (que incluyen
el MIC) se fragmentan y se les asigna un número de secuencia. La mezcla del número de
secuencia con la clave temporal genera la clave que se utilizará para el cifrado de cada fragmento
[8].
1.1.4.3 IEEE 802.11i
Después de una larga espera finalmente fue ratificado en junio de 2004 el estándar IEEE 802.11i,
que cierra el ciclo de una serie de mejoras que eran necesarias para la seguridad en WLAN.
Varios de los conceptos de 802.11i ya estaban implementados en WPA y a los equipos que
cumplen con la norma se les otorga la certificación WPA2. La alianza Wi-Fi, que certifica a los
equipos, anunció en septiembre de 2004 el primer conjunto de productos certificados para WPA2.
La principal diferencia entre WPA y WPA2 es la introducción de un mejor algoritmo de cifrado,

el AES (Estándar de Cifrado Avanzado), el cual es un requerimiento para algunas corporaciones
y usuarios gubernamentales. Una característica importante es que los productos certificados para
WPA2 serán compatibles con los certificados para WPA. Es importante resaltar que la alianza
Wi-Fi considera que los productos certificados para WPA siguen siendo seguros.
Con respecto a WEP, la alianza Wi-Fi no la considera una solución segura. Por razones de
seguridad, al igual que WPA, los equipos con WPA2 no soportan dispositivos WEP al mismo
tiempo. Sin embargo, WEP todavía permanece en las certificaciones aunque es probable que en
poco tiempo la alianza Wi-Fi pueda descartarlo como un requerimiento para las certificaciones
[9].
12
1.2 Bluetooth
Bluetooth es un enlace de radio de bajo costo, baja potencia y corto alcance para conectividad
inalámbrica entre dispositivos móviles, por ejemplo: asistentes digitales personales (PDA),
teléfonos celulares e incluso periféricos de computadora como impresoras y teclados. El Grupo
de Interés Especial (SIG) Bluetooth sirve como organismo encargado de controlar la
especificación y está compuesto por líderes de la industria de las comunicaciones y de otros
sectores industriales. Bluetooth opera en la banda de 2.4 GHz y utiliza la tecnología de espectro
disperso por salto de frecuencia.
En 1999, el SIG publicó la versión 1.0 de la especificación Bluetooth y la última versión de la

especificación Bluetooth hasta hace unos meses era la 2.0. Recientemente el SIG presentó las
características de la nueva especificación: Bluetooth 2.0 + EDR (Enhanced Data Rate) entre las
que destacan una mayor velocidad de transmisión y un menor consumo de energía.
1.2.1 Arquitectura de seguridad Bluetooth

La arquitectura de seguridad Bluetooth, tal como lo ha especificado el SIG, incluye medidas de
autentificación y cifrado. La especificación también detalla tres modos de seguridad bajo los que
el protocolo puede operar:
• Modo 1. El protocolo no impone ninguna medida de seguridad.

• Modo 2. La seguridad es impuesta después del establecimiento del canal.
• Modo 3. La seguridad es impuesta antes del establecimiento del canal.
Existen dos posibilidades en el acceso de dispositivos a diferentes servicios:
• Dispositivos de confianza. Dispositivos que han sido previamente autentificados y están

marcados en la base de datos como de confianza. Disfrutan de una relación fija, con
acceso completo a los servicios para los cuales se haya configurado la relación de
confianza.
• Dispositivos de no confianza. Dispositivos que han sido anteriormente autentificados,
pero que no han sido marcados como de confianza en la base de datos de dispositivos.
Dispondrán de acceso restringido a los servicios. Es probable que estos dispositivos no
tengan una relación fija con el otro dispositivo.
13
Los servicios también pueden ser catalogados en tres niveles de seguridad:
• Servicios abiertos, a los cuales puede acceder cualquier dispositivo.

• Servicios que requieren sólo autentificación, a los cuales puede acceder cualquier
dispositivo que se haya autentificado, puesto que habrá demostrado que comparte una
clave de enlace con el proveedor de servicio.
• Servicios que requieren autentificación y autorización, a los cuales sólo tendrán acceso
aquellos dispositivos que sean de confianza (y así estarán marcados en la base de datos
del servidor).
Las políticas de seguridad Bluetooth se administran intercambiando una serie de consultas con el
administrador de seguridad. En la figura 1-5 se ilustra la arquitectura de seguridad Bluetooth, en
ella se muestra cómo se comunica el administrador de seguridad (security manager) con la
interfaz controladora de host (HCI), con el nivel de adaptación y control del enlace lógico
(L2CAP), con el protocolo de comunicaciones de radiofrecuencia (RFCOMM), con las
aplicaciones, con la interfaz de usuario y con las bases de datos de dispositivos y servicios [3].
Figura 1-5 Arquitectura de seguridad Bluetooth.
El administrador de seguridad almacena información relativa a la seguridad de los servicios y

dispositivos. Decide si hay acceso o desconexión y aplica autentificación y cifrado si son
14
necesarios. También consulta los valores PIN (número de identificación personal) introducidos
por el usuario [10].
1.2.2 Autentificación
Se utilizan cuatro elementos en el proceso de autenticación de Bluetooth: la dirección del
dispositivo (BD_ADDR), dos claves (una clave de cifrado privada y una clave de autentificación
privada) y un número aleatorio (RAND).
La autentificación da comienzo cuando una unidad verificadora envía una unidad de datos de
protocolo (PDU) que contiene un número aleatorio a la unidad solicitante (presente pero no
identificada). La unidad solicitante devuelve una respuesta que contiene una versión cifrada del
número aleatorio, su propia dirección de dispositivo Bluetooth y una clave secreta. Si la respuesta
es la esperada por el dispositivo verificador, la unidad solicitante se considera autentificada.
Opcionalmente, los dispositivos pueden entonces intercambiar sus papeles y se repite el proceso
completo, pero en sentido inverso.
Cuando la autentificación falla, debe pasar una cierta cantidad de tiempo antes de poder realizar
otro intento.
1.2.3 Cifrado con el sistema de cifrado de flujo E0

Bluetooth emplea el sistema de cifrado de flujo simétrico de 128 bits, denominado E0. El sistema
de cifrado está compuesto de tres partes:
• Generador de clave de carga útil. La generación de la clave de carga útil es la primera

parte del cifrado. Este proceso utiliza cuatro variables: la clave de cifrado KC; la dirección
del dispositivo Bluetooth BD_ADDR, el reloj y un número aleatorio RAND.
• Generador de flujo de clave. Después de calculada la clave de carga útil, el generador de
flujo de clave utiliza una serie de cuatro registros de desplazamiento con realimentación
lineal (LFSR) para generar el flujo de clave.
• Función XOR. A continuación, el texto plano se suma mediante una puerta XOR con el
flujo de clave para producir el texto cifrado (en el proceso de cifrado), o bien el texto
15
cifrado se suma mediante una puerta XOR con el flujo de clave para producir el texto
plano (en el proceso de descifrado) [3].
El proceso de cifrado puede verse en la figura 1-6.
Figura 1-6 Descripción del proceso de cifrado.
A pesar de los mecanismos anteriores, Bluetooth tiene algunas debilidades. En [10] y [11] se
mencionan algunas de ellas referentes a limitaciones en la autentificación y en el esquema de
cifrado, respectivamente.
1.3 Sistema Global de Comunicaciones Móviles

GSM (Sistema Global de Comunicaciones Móviles) es un sistema digital de telefonía móvil que
fue creado por la CEPT (Conferencia Europea de Administraciones de Correos y
Telecomunicaciones) y posteriormente desarrollado por ETSI (Instituto de Estándares de
Telecomunicación Europeos) como un estándar para los teléfonos móviles europeos, con la
intención de desarrollar una normativa que fuera adoptada mundialmente. El estándar es abierto,
no propietario y evolutivo (aún en desarrollo). Ha obtenido un amplio uso a nivel mundial, siendo
el estándar predominante en Europa. Opera en las bandas de frecuencia de 900MHz, 1800MHz y
1900MHz.
16
1.3.1 Arquitectura de red GSM

En la figura 1-7 se muestra de manera resumida la arquitectura de la red GSM. Esta arquitectura
es más compleja y dispone de más elementos que los presentados en esta figura. El objetivo es
conocer los elementos básicos y su funcionamiento para entender el mecanismo de seguridad
empleado, sin entrar en demasiados detalles de la red subyacente.
Figura 1-7 Arquitectura de una red GSM.
La arquitectura GSM está constituida fundamentalmente por tres partes: la estación móvil (MS),
el subsistema de estación base (BSS) y el subsistema de conmutación y red (NSS). A
continuación se definen los elementos que componen esta arquitectura así como otros acrónimos
empleados para la seguridad en GSM.
A3 El algoritmo de autentificación usado en GSM.
A5 El algoritmo de cifrado utilizado en el sistema GSM. Hay varias implementaciones

nombradas A5/1, A/2,...El A/1 es conocido como el algoritmo fuerte.
A8 El algoritmo de generación de clave usado en GSM.
AUC Centro de autentificación; proporciona los parámetros necesarios para las funciones de
autentificación y cifrado.
17
BSC Controlador de estaciones base; se utilizan como controladores de las BTS y tienen
como funciones principales las de estar a cargo de los handoff’s (cambio automático de
canal), los saltos de frecuencia y los controles de las frecuencias de radio de las BTS.
BSS Subsistema de estación base; conecta la estación móvil y el NSS. Son los encargados de
la transmisión y recepción. El BSS se divide en dos partes: BTS y BSC.
BTS Estación base; se comunica con la estación móvil.
EIR Registro de identidad de equipos; también se utiliza para proporcionar seguridad en las
redes GSM pero a nivel de equipos válidos. La EIR contiene una base de datos con
todas las terminales que son válidas para ser usadas en la red. Esta base de datos
contiene los IMEI de cada terminal, de manera que si un determinado móvil trata de
hacer uso de la red y su IMEI no se encuentra localizado en la base de datos del EIR no
puede hacer uso de la red.
GMSC Gateway del centro de conmutación de servicios móviles; sirve de enlace para la
comunicación con otras redes.
HLR Registro de localización local; es parte del AUC. El HLR es una base de datos que
contiene información sobre los usuarios conectados a un determinado MSC. Entre la
información que almacena el HLR se encuentra fundamentalmente la localización del
usuario y los servicios a los que tiene acceso.
Kc Es la llave secreta usada para cifrar el tráfico entre la BTS y la MS. Kc es generada
después de cada autentificación. Kc es calculada a partir de Ki y del desafío aleatorio
enviado por el MSC con el algoritmo A8. La MS y el HLR calculan Kc
independientemente uno del otro.
Ki Es la llave secreta compartida entre el SIM y el HLR.
IMEI Identificación de equipo móvil internacional.
MS Estación móvil o teléfono móvil.
18
MSC Centro de conmutación de servicio móvil; es el componente central del NSS y se

encarga de realizar las labores de conmutación dentro de la red, así como de
proporcionar conexión con otras redes.
NSS Subsistema de conmutación y red; este sistema se encarga de administrar las

comunicaciones que se realizan entre los diferentes usuarios de la red.
RTCP Red telefónica conmutada pública.
SIM Módulo de identidad del subscriptor; es una pequeña tarjeta inteligente que sirve para
identificar las características de la terminal.
SRES Señal de respuesta; es la respuesta que la estación móvil regresa a un desafío hecho por
el MSC durante la autentificación.
VLR Registro de localización de visitantes; almacena los parámetros generados por el HLR
cuando el suscriptor no está en su propia red. El VLR proporciona entonces éstos
parámetros al MSC cuando sea necesario [12].
1.3.2 Modelo de seguridad GSM

El modelo de seguridad GSM está basado en una llave secreta compartida entre el HLR (registro
de localización local) del operador de red y el SIM (módulo de identidad del subscriptor) del
usuario. Esta llave secreta, llamada Ki es una llave de 128 bits usada por la MS (estación móvil)
para generar una señal SRES (señal de respuesta), en respuesta a un desafío aleatorio hecho por
el MSC (centro de conmutación de servicio móvil).
Cuando la MS visita una célula transmite su IMSI (identidad de abonado) y posición al VLR
(registro de localización de visitantes) y al HLR. El HLR conoce las Ki secretas de las SIMs. El
HLR pide al AUC (centro de autentificación) tres parámetros: un número aleatorio RAND, una
respuesta SRES y la clave de sesión Kc las cuales se envían al MSC. El MSC envía a la MS
como desafío el número aleatorio RAND, utilizándose uno por cada autentificación.
El SIM calcula la respuesta SRES y la envía al MSC, si las SRESs calculadas son iguales se
autentifica positivamente al abonado y se comprueban los servicios contratados. Se utiliza el
algoritmo simétrico A3 para el cálculo de SRES. También se comprueba que la IMEI
19
(identificación de equipo móvil internacional) está autorizada en el EIR (registro de identidad de

equipos). Para asegurar la confidencialidad del tráfico, el usuario se registra con un TMSI
(identidad de suscriptor temporal) después de pasar su primer procedimiento de actualización de
ubicación. La voz se cifra mediante el algoritmo A5. La clave Kc o clave de cifrado se genera a
partir de Ki y el RAND con el algoritmo A8 [17]. En la figura 1-8 se puede apreciar el proceso de
autentificación.
Figura 1-8 Autentificación de la estación móvil.
El algoritmo A3 es el algoritmo de autentificación. Su función es generar la respuesta SRES al

desafío RAND enviado por el MSC. Con el RAND y el Ki (ambos de 128 bits) se genera la
salida SRES de 32 bits. El algoritmo A8 es el algoritmo de generación de clave usado en GSM.
El A8 genera la Kc de 64 bits a partir del mismo Ki y RAND. El algoritmo A5 se emplea para
cifrar la voz. A partir de Kc y la voz se genera la voz cifrada. En la figura 1-9 se muestra la
relación de estos algoritmos.
Figura 1-9 Algoritmos y llaves utilizados en GSM.
20
Se han presentado varias críticas al modelo de seguridad en GSM. Hace algunos meses
investigadores del Instituto de Tecnología de Haifa en Israel, reclaman haber descubierto un
modo de derrotar al sistema de seguridad GSM, aprovechando un pequeño defecto en la forma en
que es aplicado el cifrado [13]. Otro tipo de vulnerabilidades pueden encontrarse en [12] y [14]
referentes a ataques contra el algoritmo A5 y fallas en el proceso de autentificación,
respectivamente.
1.4 Tendencias
En este apartado se presentan de forma breve algunas tecnologías que al parecer, por sus
características tomarán un lugar importante en el mercado de las redes inalámbricas y móviles.
Existen otras tecnologías aparte de las que aquí se mencionan, pero sólo nos hemos enfocado en
las que se vislumbra, tendrán gran auge en los próximos años, tanto a nivel MAN, LAN y WAN.
1.4.1 IEEE 802.16

El estándar 802.16x conocido como WiMAX, es una especificación para redes metropolitanas
inalámbricas de banda ancha, que está siendo desarrollado y promovido por el grupo de la
industria WiMAX (Worldwide Interoperability for Microwave Access) [15]. Como sucedió con
Wi Fi, la etiqueta WiMax se asocia globalmente con el propio nombre del estándar.
El estándar 802.16 puede alcanzar una velocidad de comunicación de hasta 124 Mbit/s en un
canal con un ancho de banda de 28 MHz (en la banda de 10 a 66 GHz), mientras que el 802.16a
puede llegar a los 70 Mbit/s, operando en un rango de frecuencias más bajo (2 a 11 GHz). Estas
velocidades se consiguen gracias a utilizar la modulación OFDM (multiplexaje por división de
frecuencia ortogonal). El rango que alcanza se extiende desde 40 a 70 kilómetros. Es válido para
topologías punto a multipunto y, opcionalmente, para redes en malla y no requiere línea de vista
directa. En cuanto a seguridad, incluye medidas para la autentificación de usuarios (certificados
X.509) y el cifrado de datos mediante el algoritmo DES.
WiMax tiene competidores, y así una alternativa es el estándar Hiperaccess (por encima de 11
GHz) e HiperMAN (por debajo de 11 GHz) del ETSI, pero el auge que está tomando WiMax ha
hecho que se esté estudiando la posibilidad de armonizarlo con está última norma, que también
utiliza una modulación OFDM. Debido al apoyo que está recibiendo de parte de la industria,
21
WiMax parece ser el ganador [16]. El forum WiMax contempla para el año 2005 los primeros
productos certificados con esta norma [15].
1.4.2 UWB
Otra tecnología que comienza a demostrar su fuerza es la UWB (ultra banda ancha).
Técnicamente, la UWB se basa en el estándar, todavía no ratificado, IEEE 80.15.3a (PAN.- Red
de Área Personal). La tecnología UWB, basada en radiofrecuencia, puede utilizarse para
transmitir voz, vídeo u otro tipo de datos digitales. Su principal ventaja respecto a otras
tecnologías inalámbricas radica en el hecho de que puede transmitir más datos utilizando menos
potencia que el resto de sistemas disponibles. La velocidad que se menciona es de 110 Mbps a
una distancia de 10 metros y 480 Mbps a una distancia de 2 metros.
El principal campo de aplicación de UWB se orienta hacia la electrónica del hogar, por ejemplo
en la interconexión de periféricos tales como impresoras, escáneres o monitores con la PC, o en
la distribución de señales HDTV (Televisión de alta definición) a distintos receptores de TV y
dispositivos multimedia. De esta forma, UWB podría relegar a Wi-Fi al mercado empresarial. En
cierto modo, se puede considerar a UWB como la evolución de Bluetooth hacia una mayor
velocidad y capacidad de datos. El forum UWB espera tener los primeros productos en el
mercado en los próximos meses [17].
Con respecto a la seguridad, en UWB es necesario conocer la secuencia de transmisión de los bits
de información para poder escuchar las transmisiones. Además la relación señal/ruido es tan baja
que las transmisiones son confundidas con ruido de ambiente. Asimismo las transmisiones
pueden cifrarse sin ningún tipo de limitación y se pueden excluir de la escucha aquellas
terminales que se hallen más alejadas de una cierta distancia específica [18].
1.4.3 UMTS
Sin duda UMTS (Sistema de Telecomunicaciones Móviles Universales) se presenta hoy en día
como el principal sistema de 3G (3ª Generación), gracias a la gran aceptación que éste ha tenido
en toda Europa, Asia y parte de América. UMTS tendrá un papel protagonista en el mercado de
las comunicaciones multimedia inalámbricas de alta calidad, con lo cual se busca extender las
actuales tecnologías móviles, inalámbricas y satelitales, proporcionando mayor capacidad,
22
transmisión de datos y una gama de servicios mucho más extensa. La normalización del sistema
UMTS se lleva a cabo dentro del foro 3GPP (Proyecto de Sociedad para Tercera Generación). La
tarea del 3GPP consiste en la elaboración de las especificaciones técnicas de UMTS, con el
propósito de que posteriormente cada organismo de normalización afiliado, pueda trasponerlas en
los estándares correspondientes. En el caso de Europa, el organismo encargado de esta tarea es
ETSI [19].
En relación a la seguridad UMTS conserva algunas características de GSM, pero define un nuevo
método de autentificación y principalmente se definen nuevos algoritmos de cifrado con la
finalidad de solventar algunas vulnerabilidades descubiertas en GSM.
UMTS AKA (UMTS Authentication and Key Agreement) es un mecanismo de seguridad que es
usado para llevar a cabo la característica de autentificación. Este mecanismo está basado en un
protocolo de autentificación de desafío/respuesta concebido de tal forma que tenga
compatibilidad con el protocolo de autentificación de GSM, con el objeto de hacer más fácil la
transición de GSM a UMTS. La idea en este mecanismo es que cada entidad debe probar a la otra
que conoce la clave sin revelar o transmitir la clave.
El algoritmo f8 es el encargado de garantizar la confidencialidad de las transmisiones y el

algoritmo f9 se encarga de su integridad. Ambos algoritmos están basados en el bloque de cifrado
KASUMI que opera con claves de 128 bits. El desarrollo de KASUMI está basado en un bloque
de cifrado llamado MISTY1 el cual fue elegido por la 3GPP, debido a su probada resistencia en
contra de los más avanzados métodos para romper bloques de cifrado [20].
1.4.4 Redes móviles Ad hoc

Una red móvil Ad hoc es un tipo de red formada por un grupo de nodos o hosts móviles que
forman una red temporal sin la ayuda de ninguna infraestructura externa. Para que esto se puede
llevar a la práctica es necesario que los nodos se puedan ayudar mutuamente para conseguir un
objetivo común: que cualquier paquete llegue a su destino aunque el destinatario no sea accesible
directamente desde el nodo fuente. El protocolo de enrutamiento es el responsable de descubrir
las rutas entre los nodos para hacer posible la comunicación. Este tema se analizará a detalle en el
capítulo 2.
23
1.5 Sumario
En este capítulo se proporcionó un panorama general sobre las tecnologías inalámbricas y
móviles, siendo los mecanismos de seguridad empleados la característica más importante a
considerar en el desarrollo de este trabajo de tesis. En este sentido, debemos mencionar que se
consideraron las tecnologías que tienen gran aceptación en el mercado de las redes inalámbricas y
móviles. Un punto importante a destacar es que en la mayoría de los casos los mecanismos de
seguridad han sido rotos y en cierta forma estos mecanismos han tenido que evolucionar de mano
con la tecnología. Debido a la preocupación de diversos sectores, la permanencia de las
tecnologías depende en gran parte del nivel de seguridad que puedan proporcionar a los usuarios.
Por último mencionar que el mercado se perfila hacia redes donde la banda ancha es la principal
característica y respecto a la seguridad de estas nuevas redes, habrá que esperar a que estén
ampliamente desplegadas para analizar si realmente son más seguras que las tecnologías
predecesoras.
24
Capítulo 2
Redes móviles Ad hoc
Introducción
En este capítulo se proporciona información relacionada a las redes móviles Ad hoc. En primer
lugar, en el apartado 2.1 se presenta la definición de éstas redes. En el apartado 2.2 se mencionan
los tipos de protocolos de enrutamiento que existen para las redes Ad hoc. Posteriormente en el
apartado 2.3, se proporcionan los principales aspectos de funcionamiento del protocolo AODV
como son: el proceso de descubrimiento de rutas y mantenimiento de rutas. En el apartado 2.4 se
presentan las cuestiones relacionadas con la seguridad: objetivos, desafíos y principales ataques
contra el protocolo AODV. En el apartado 2.5 se exponen los dos principales esquemas de
seguridad encontrados en el estado del arte: seguridad en el enrutamiento y detección de intrusos.
Finalmente en el apartado 2.6, se resumen los principales aspectos abordados en este capítulo.
2.1 Definición de red móvil Ad hoc

Una red móvil Ad hoc es un tipo de red formada por un grupo de nodos o hosts móviles que
forman una red temporal sin la ayuda de ninguna infraestructura externa. Para que esto se puede
llevar a la práctica es necesario que los nodos se puedan ayudar mutuamente para conseguir un
objetivo común: que cualquier paquete llegue a su destino aunque el destinatario no sea accesible
directamente desde el nodo fuente. El protocolo de enrutamiento es el responsable de descubrir
las rutas entre los nodos para hacer posible la comunicación.
25
Algunos ejemplos de uso de las redes Ad hoc son: aplicaciones militares, operaciones de
emergencia de búsqueda y rescate, convenciones, etc. En la figura 2-1 se muestra un ejemplo de
una red móvil Ad hoc.
Figura 2-1 Ejemplo de red móvil Ad hoc.
Esta figura muestra una sencilla red Ad hoc. El nodo fuente quiere enviar un paquete al nodo
destino, pero éste se encuentra fuera del alcance de su sistema de transmisión (representado por
círculos en la figura). Es necesario que los nodos intermedios participen y retransmitan el paquete
desde el nodo fuente hasta el destino. En el ejemplo, el camino por el que viaja el paquete de
datos está representado por flechas.
2.2 Protocolos de enrutamiento

Los protocolos de enrutamiento desarrollados para las redes alámbricas no pueden ser utilizados
en redes Ad hoc. Los protocolos clásicos presuponen que la topología de la red es poco
cambiante y en consecuencia, están basados en complicados algoritmos que tratan de conocer la
mejor ruta hacia cualquier destino. En las redes Ad-Hoc, debido a la movilidad de los nodos, no
es factible esta alternativa. Por este motivo se ha establecido dentro del Internet Engineering Task
Force (IETF), un grupo de trabajo denominado Mobile Ad hoc Network working group
(MANET) [21], cuyo principal objetivo es estimular la investigación en el área de las redes Ad
hoc. En este grupo de trabajo se han especificado varios protocolos de enrutamiento para redes
MANET.
Los protocolos de enrutamiento usados en las redes Ad hoc se pueden clasificar en dos grupos:
26
• Basados en tablas de enrutamiento o proactivos. Estos protocolos tratan de mantener la

información necesaria para el enrutamiento continuamente actualizada. Cada nodo
mantiene una o más tablas con los datos necesarios para enviar paquetes hacia cualquier
otro nodo de la red. Los cambios en la topología de la red propician el envío de paquetes
para mantener las tablas actualizadas. Un ejemplo es el protocolo DSDV (Destination
Sequenced Distance Vector).
• Basados en enrutamiento bajo demanda o reactivos. A diferencia con los protocolos

basados en tablas, las rutas son creadas sólo cuando se requieren. Cuando un nodo
requiere una ruta hacia un nodo destino se inicia un proceso de descubrimiento de ruta.
Este proceso termina cuando se encuentra un camino hacia el destino o cuando se
examinan todas las alternativas y ninguna lleva al destino final. Cuando la ruta es
descubierta, es necesario mantenerla hasta que el destino se vuelva inalcanzable o la ruta
deje de ser necesaria. Algunos ejemplos de este tipo de protocolos son AODV (Ad hoc
On-demand Distance Vector), DSR (Dynamic Source Routing) y TORA (Temporary
Ordered Routing Algorithm).
Para el desarrollo de la tesis, se eligió el protocolo reactivo “vector de distancia sobre demanda
Ad hoc” (AODV), ya que consideramos que presenta un mejor desempeño y ha alcanzado el
nivel de Request For Comments (RFC 3561) [22].
2.3 Introducción al protocolo AODV

Una de las características que define a AODV es el uso de tablas de enrutamiento en cada nodo
para evitar transportar rutas en los paquetes. Cada destino de la tabla de enrutamiento lleva
asociado un número de secuencia y un temporizador o tiempo de vida. El número de secuencia
permite distinguir entre información reciente e información antigua, de tal manera, que se evita la
formación de lazos y la transmisión de rutas antiguas o caducadas por la red. La función del
temporizador es evitar usar enlaces de los que no se conoce su estado desde hace mucho tiempo.
AODV no mantiene rutas para cada nodo de la red. Estas rutas son descubiertas según se vayan
necesitando. AODV es capaz de proveer de transmisión unicast, multicast y broadcast. La
transmisión unicast consiste en enviar datos de un nodo a otro, la transmisión multicast consiste
27
en enviar información de un nodo a un grupo de nodos y la transmisión broadcast consiste en

enviar datos de un nodo a todos los demás nodos de la red.
Los descubrimientos de rutas son siempre bajo demanda y siguen un ciclo de petición y respuesta
de ruta. Las peticiones son enviadas usando un paquete especial denominado RREQ (Route
Request). A su vez, las respuestas son enviadas en un paquete denominado RREP (Route Reply).
A continuación se resume la secuencia de pasos para descubrir una ruta:
1. Cuando un nodo desea conocer una ruta hacia un nodo destino, envía por broadcast un
RREQ.
2. Cualquier nodo que conozca una ruta hacia el destino solicitado (incluido el propio
destino) puede contestar enviando un RREP.
3. Esta información viaja de regreso hasta el nodo que originó el RREQ y sirve para
actualizar las rutas de los nodos que lo necesiten.
4. La información recibida por el nodo destino del RREP se almacena en su tabla de

enrutamiento.
Ahora, el nodo fuente ya podría encaminar su paquete de datos, pues ya conoce un camino hacia
su destino.
2.3.1 Descubrimiento de rutas

Cuando un nodo desea enviar datos a otro, primero checa si tiene alguna entrada en su tabla de
rutas para dicho destino. Si tiene alguna entrada activa, encamina los datos por el vecino que le
indica la tabla. Sin embargo, si el nodo fuente no dispone de una entrada activa porque es la
primera vez que se va a comunicar con él o bien porque el plazo para ese destino ha expirado (al
comprobar el campo lifetime y la fecha de la última modificación), se inicia un descubrimiento de
ruta. Para ello se debe crear un paquete RREQ que contiene información relativa al nodo destino
e información propia. Los campos del paquete RREQ se ilustran en la figura 2-2 [22].
El nodo fuente inicia el descubrimiento de ruta transmitiendo un paquete RREQ a sus vecinos,
los que a su vez se lo envían a sus vecinos y así sucesivamente hasta llegar al destino o algún
28
nodo intermedio que tenga una ruta al destino lo suficientemente “fresca” (reciente) en su tabla
de enrutamiento [23].
J y R.- banderas reservadas para multicast G.- RREP gratuito D.- indica que sólo el destino responde
U.- indica número de secuencia desconocido
Figura 2-2 Formato del paquete de petición de ruta (RREQ).
Cada paquete RREQ es identificado unívocamente con un identificador propio (RREQ ID). Este
identificador se incrementa cada vez que se genera un nuevo RREQ y lo utilizan los nodos
intermedios para saber si deben retransmitir el paquete o, por el contrario, descartarlo porque ya
lo retransmitieron con anterioridad. Si los nodos intermedios tienen información para llegar al
nodo destino, contestan al nodo fuente para evitar la propagación innecesaria del RREQ a través
de la red. Aún teniendo esta información, los nodos intermedios sólo responden a los RREQ si
ellos tienen en su tabla de enrutamiento una ruta al destino con un número de secuencia de
destino (Destination Sequence Number) mayor o igual al que trae el RREQ, es decir, sólo si
tienen rutas iguales en edad o más recientes. El proceso de descubrimiento de ruta se muestra en
la figura 2-3 [24].
Figura 2-3 Descubrimiento de ruta en AODV.
29
Mientras se va enviando el RREQ, los nodos intermedios van aumentando el campo “Hop
Count” (cuenta de saltos) y además, registran en su tabla de enrutamiento la dirección del vecino
del cual recibieron primero el mensaje, para así establecer un camino de regreso (reverse path).
Una vez que el nodo destino o un nodo intermedio con ruta reciente ha sido encontrado, éste
responde con un paquete unicast RREP al vecino del cual recibió el primer RREQ. La estructura
del paquete RREP se muestra en la figura 2-4 [22].
R.- bandera reservada para multicast A.- requiere reconocimiento
Figura 2-4 Formato del paquete de respuesta de ruta (RREP).
Si el nodo que genera el RREP es el destino, incrementa su número de secuencia (Destination

Sequence Number) en uno y coloca el valor cero en el campo cuenta de saltos (Hop Count) del
paquete RREP. Si algún nodo intermedio genera el RREP, coloca el número de secuencia de
destino que tiene almacenado en su tabla para dicho destino, así como los saltos requeridos para
llegar a él. Cuando el RREP viaja de regreso hacía el nodo fuente, se establece un camino directo
(forward path) al destino. Cada nodo por el que pasa el RREP, actualiza el número de secuencia
para el destino solicitado. El nodo fuente empieza a transmitir paquetes de datos tan pronto como
el primer RREP es recibido. El camino de regreso se ilustra en la figura 2-5 [24].
Figura 2-5 Camino de regreso en AODV.
30
La entrada en la tabla que mantiene el camino de regreso (reverse path) es borrada luego de un
intervalo de tiempo. De la misma manera, la entrada en la tabla que mantiene el camino directo es
borrada si no se usa dentro de un tiempo determinado.
Es posible que el nodo fuente reciba más de un RREP de los nodos vecinos. Cuando eso ocurre
se utiliza la ruta proporcionada por el primer RREP que recibe y cuando llega algún RREP
posterior, el nodo checa si el paquete contiene un número de secuencia de destino más grande o
el mismo número de secuencia con un menor número de saltos, si cumple cualquiera de estas
condiciones se actualiza la tabla con los nuevos valores, de lo contrario el paquete es descartado
[23].
2.3.2 Mantenimiento de rutas

Como se mencionó anteriormente, la ruta se considera válida durante un periodo de tiempo. Esto
es debido a que los nodos son móviles y un camino que antes era óptimo, pasado un tiempo
puede no ser válido. Para contrarrestar estas situaciones, AODV utiliza el mantenimiento de
rutas. Si el nodo fuente de un envío se mueve (y altera la topología de la red), él debe reiniciar un
nuevo descubrimiento de ruta hacia el destino. Sin embargo, si ha sido el nodo destino el que se
ha movido o algún nodo intermedio, y hay algún mensaje dirigido hacia él, un mensaje especial
de error (RERR) es enviado al nodo que originó el envío, por el nodo que advierta el cambio en
la topología de la red. Es importante resaltar que no todos los cambios de los nodos ocasionan
operaciones en el protocolo, debido que AODV encamina bajo demanda. Todos los nodos por los
que atraviese este paquete (RERR), cancelarán las rutas que pasan por el nodo que se ha vuelto
inaccesible. En el momento que el RERR llegue a su destino, éste puede decidir dar por
terminado el enlace o iniciar un nuevo RREQ si aún se necesita establecer la comunicación.
Es preciso mantener la información actualizada de quiénes son los vecinos de los nodos cada
cierto tiempo. Cada vez que un nodo recibe un paquete de algún vecino, la entrada para ese
vecino en la tabla de rutas se refresca, pues se sabe con seguridad que sigue en su lugar. Si no
hubiera entrada todavía para el vecino, se crearía una nueva en la tabla de enrutamiento. Además,
cada cierto intervalo de tiempo, se mandan paquetes “HELLO” a los vecinos para informarles
que el propio nodo sigue activo. Esta información es usada por los vecinos para actualizar los
temporizadores asociados a dicho nodo o en su defecto, para deshabilitar las entradas que se
encaminen por el nodo que no responde [23].
31
2.4 Seguridad en redes móviles Ad hoc

Las redes móviles Ad hoc presentan varias ventajas entre las que destacan la rapidez con la que
se pueden implementar y que no se requiere infraestructura externa. Sin embargo, investigaciones
recientes en el área inalámbrica han demostrado que las MANET presentan un conjunto de
desafíos en seguridad más grandes que las redes alámbricas e incluso que otros tipos de redes
inalámbricas, ya que por sus características tienen vulnerabilidades inherentes que las hacen más
susceptibles a ataques maliciosos.
2.4.1 Objetivos de seguridad

De forma similar a las redes alámbricas, las redes móviles Ad hoc consideran para la seguridad
los siguientes atributos [25, 26]:
• Disponibilidad: Asegura la supervivencia de la red a pesar de los ataques de denegación

de servicio. Un ataque de denegación de servicio puede llevarse a cabo en cualquier capa
de una red móvil Ad hoc. En la capa física y de control de acceso al medio, un adversario
puede colocar suficiente tráfico para interferir con la comunicación en el canal físico. En
la capa de red un atacante puede corromper el protocolo de enrutamiento en varias formas
que se presentan más adelante. Finalmente, en las capas superiores, un usuario malicioso
puede derribar los servicios de alto nivel tal como los servicios de administración de
claves.
• Confidencialidad: Asegura que la información nunca es revelada para usuarios no

autorizados. Este atributo es el más importante cuando se transmite información sensible
tal como tácticas militares. La información de enrutamiento también debe ser confidencial
en casos cuando la localización del usuario debe permanecer secreta.
• Integridad: garantiza que el mensaje que es transmitido alcanza su destino sin ser
modificado o alterado de alguna forma. La corrupción de mensajes puede ser causado ya
sea por un atacante malicioso en la red o por fallas en la propagación de radio.
• Autentificación: Permite a un nodo estar seguro de la identidad de los nodos con los que
establece comunicación. Cuando no hay un esquema de autentificación, un nodo puede
hacerse pasar por otro y ganar acceso a los recursos e información.
32
• No repudio: Asegura que algún nodo que originó un mensaje, no pueda refutar que envió
ese mensaje.
• Control de acceso y uso: El control de acceso asegura que el acceso a la información es

controlada por la red móvil Ad hoc. El control de uso asegura que el recurso de
información es usado correctamente por los nodos autorizados que tienen los permisos
correspondientes.
2.4.2 Desafíos de seguridad

Los protocolos de enrutamiento Ad hoc asumen que los nodos móviles en la red se comportan
apropiadamente y ejecutan adecuadamente el protocolo. No obstante, al considerar los entornos
en los que éstas redes operan (militares, misiones de rescate, etc.) el protocolo es propenso a
diversos ataques maliciosos. Se ha intentado transportar los mecanismos de seguridad de las
redes alámbricas a las redes Ad hoc, aunque éstas últimas presentan un nuevo conjunto de
fragilidades que no se aplican a su contraparte alámbricas. Algunos de esos mecanismos incluyen
cifrado y autentificación de usuarios. Pero esos métodos presentan las siguientes dificultades
[27]:
• La restricción de consumo de potencia y las capacidades computacionales limitadas de los

dispositivos móviles, restringe el uso de algoritmos de cifrado complejos.
• La topología altamente dinámica incrementa la dificultad en la autentificación y agrega

desafíos en la administración y distribución de claves.
• Esos métodos pueden proteger en contra de ataques externos, pero los ataques internos
que provienen de nodos comprometidos, tienen gran impacto en el desempeño de la red.
2.4.3 Ataques en AODV

AODV fue diseñado asumiendo que de los nodos que forman la red, ninguno es un nodo
malicioso. El mismo RFC 3561 menciona que no hay alguna medida de seguridad y que el
protocolo de enrutamiento presenta el riesgo de varios ataques. Los ataques pueden ser
clasificados de diferentes maneras. Algunas clasificaciones están basadas en las fuentes de los
33
ataques (ataques internos y externos) o en los métodos que utilizan los atacantes para adquirir
control. De forma general los ataques se clasifican en dos tipos:
• Ataques pasivos: Un nodo malicioso lleva a cabo un ataque pasivo cuando ignora algunas
operaciones, por ejemplo cuando no participa en el proceso de descubrimiento de ruta.
• Ataques activos: Un nodo malicioso lleva a cabo un ataque activo cuando introduce
información falsa en la red. Esto confunde el procedimiento y degrada el desempeño de la
red [27].
Nos hemos enfocado en los ataques activos. A continuación se presentan algunos ejemplos de
este tipo de ataques [27]:
• Vector de distancia falso. Un nodo malicioso forma este ataque cuando anuncia en un
RREP que se encuentra a uno o pocos saltos del nodo destino, aún cuando no tenga una
ruta disponible en su tabla de enrutamiento. Si ningún otro nodo proporciona una mejor
ruta, el nodo fuente escogerá la ruta proporcionada por el nodo malicioso. Los paquetes
de datos se perderán o estarán comprometidos por el atacante.
• Inundación malintencionada. Un nodo malicioso puede escoger una dirección que no

existe y enviar paquetes RREQ con mucha frecuencia. Los paquetes RREQ inundarán la
red porque ningún nodo puede dar una respuesta, esto retrasará la transmisión de otro
tráfico e incrementará el número de paquetes perdidos, afectando el desempeño de la red.
Para la realización de este trabajo se eligió un ataque específico al que el protocolo está expuesto.
Se optó por el ataque conocido como ataque de número de secuencia por varias razones: 1) es
uno de los ataques más reportados en la literatura, por ejemplo en [24] y [27], 2) un atacante no
requiere de grandes esfuerzos para realizar el ataque y 3) porque tiene un gran impacto en el
desempeño de la red.
• Ataque de número de secuencia. Protocolos como AODV y DSDV crean y mantienen

rutas al incrementar los números de secuencia hacía destinos específicos. Puesto que los
números de secuencia de los destinos determinan que tan reciente es una ruta y de acuerdo
al protocolo las rutas nuevas o recientes son prioritarias, un nodo malicioso puede
redireccionar una ruta al asignar un número secuencia grande en un RREP. Este ataque
también es conocido como “black hole” y es similar al ataque de vector de distancia falsa.
34
Pero éste afecta más el desempeño de la red, ya que de acuerdo al protocolo AODV son
preferibles las rutas recientes a las rutas cortas.
En la figura 2-6 el nodo fuente inicia un proceso de descubrimiento de ruta hacia el nodo destino
al enviar un paquete RREQ. Cuando el nodo malicioso recibe el RREQ, y aunque no tenga una
ruta reciente en su tabla de enrutamiento para el destino solicitado, crea un paquete RREP con
información falsa acerca del número de secuencia. Con el objetivo de que la información falsa
sea favorecida, el nodo malicioso coloca un número de secuencia grande en el campo número de
secuencia de destino. Si el RREP del nodo malicioso es recibido antes que un RREP legítimo,
entonces el nodo malicioso forma parte de la ruta y puede atraer el tráfico de datos. Incluso si el
RREP del nodo malicioso no llega antes que otros RREP al nodo fuente, se puede desempeñar el
ataque porque el número de secuencia es mayor que el de la ruta original y ésta será reemplazada
por la ruta falsa.
Figura 2-6 Ejemplo del ataque de número de secuencia.
La fortaleza de este ataque radica en que la ruta falsificada se propagará hacía otros nodos
legítimos, éstos actualizan su tabla y pueden responder a futuros RREQs con la información falsa
que existe en sus tablas de enrutamiento. De esta manera, la información falsa se propaga a otros
nodos sin la intervención del nodo malicioso.
2.5 Esquemas de seguridad

Hay dos esquemas principales que se emplean para proporcionar seguridad a las redes móviles
Ad hoc. El primero es la seguridad en el enrutamiento, y el segundo enfoque es la detección de
35
intrusos. En los siguientes apartados se describen brevemente éstos dos esquemas que se
identificaron en la literatura y que se emplean para suministrar seguridad a las redes móviles Ad
hoc.
2.5.1 Seguridad en el enrutamiento

Se basa en el diseño e implementación de nuevos protocolos que incluyen funciones de
seguridad. Éstas propuestas utilizan protocolos conocidos como AODV y DSR, pero rediseñados
para incluir características de seguridad. A continuación se mencionan algunos de ellos.
El protocolo SEAD (Secure Efficient Ad hoc Distance vector.- Vector de Distancia Ad hoc
Eficiente y Seguro) [28] emplea funciones Hash para autentificar la cuenta de saltos y los
números de secuencia. Está basado en el protocolo DSDV, requiere mecanismos de
sincronización de reloj y el establecimiento de una clave compartida entre cada par de nodos. El
protocolo Ariadne [29] también asume la existencia de una clave compartida entre dos nodos y
utiliza un código de autentificación de mensaje. A diferencia de SEAD, Ariadne está basado en el
protocolo DSR. Otro protocolo que utiliza funciones Hash es el protocolo SAODV (Secure
AODV.- AODV Seguro) [30], en el cual se propone un conjunto de extensiones a los paquetes de
enrutamiento del protocolo AODV. SAODV también utiliza firmas digitales y requiere de un
mecanismo de administración de claves. El protocolo ARAN (Authenticated Routing for Ad hoc
Networks.- Enrutamiento Autentificado para Redes Ad hoc) [31] supone que cada nodo conoce
con antelación la llave pública de una autoridad certificadora, la cual es usada para autentificar a
los nodos participantes.
2.5.2 Detección de intrusos

Este esquema se basa en detectar y evitar el comportamiento malicioso en la red sin cambiar las
características del protocolo.
La detección de intrusos se puede entender como el método para identificar “cualquier conjunto
de acciones que intentan comprometer la integridad, confidencialidad o disponibilidad de los
recursos” y ha sido un tópico de investigación para redes alámbricas desde hace muchos años.
Debemos tener en cuenta la dificultad que envuelve aplicar las técnicas de detección de intrusos
desarrolladas para redes alámbricas a las redes móviles Ad hoc, debido a la gran diferencia entre
36
estos dos tipos de redes. La principal diferencia es que las últimas no tienen una infraestructura
fija y en las redes alámbricas el monitoreo de tráfico es hecho principalmente en switches, routers
y gateways. Las redes móviles Ad hoc no tienen puntos de concentración de tráfico donde se
pueda monitorear la red completa.
Un sistema de detección de intrusos puede clasificarse de diferentes maneras dependiendo de la

característica en la que nos fijemos [32]. Una clasificación la podemos realizar según los medios
que utilizan los sistemas de detección de intrusos para monitorear las incidencias:
• Basados en red. Detectan ataques capturando y analizando paquetes de red. Escuchan en

un segmento de red y pueden monitorear el tráfico de red que afecta a múltiples hosts que
están conectados a ese segmento de red, protegiendo así a estos hosts.
• Basados en host. Recaban información del sistema para realizar un análisis de las posibles
incidencias, pero siempre desde el punto de vista del propio sistema y con sus recursos.
Otra clasificación que existe es de acuerdo al análisis que se realiza:
• Detección de abusos o firmas. Los detectores de abusos analizan la actividad del sistema
buscando eventos que coincidan con un patrón predefinido o firma que describe un ataque
conocido. Una ventaja es que son muy efectivos en la detección sin que generen un
número elevado de falsas alarmas y una desventaja es que sólo detectan aquellos ataques
que conocen.
• Detección de anomalías. Se busca sobre el sistema alguna anomalía o comportamiento

inusual que pueda hacer creer que hay un incidente de seguridad, pero que puede no ser
provocada por esto. Una ventaja es que tienen la capacidad de detectar ataques para los
cuales no tienen un conocimiento específico y una desventaja es que producen una gran
cantidad de falsas alarmas, debido a los comportamientos no predecibles de usuarios y
redes.
Hay algunos sistemas de detección de intrusos que han sido propuestos para las redes móviles Ad
hoc y se describen a continuación.
El esquema “watchdog and pathrater” [33] consiste de dos extensiones al protocolo DSR que
intentan detectar y mitigar los efectos de los nodos que no retransmiten los paquetes. La
37
extensión watchdog es responsable de monitorear a los vecinos siguientes en las rutas que se
establecen e identifica a los nodos que no tienen un comportamiento adecuado. La extensión
pathrater evalúa el resultado de watchdog y selecciona la ruta más confiable para entregar los
paquetes. La suposición principal de este esquema es que nodos maliciosos no se pueden
confabular para desarrollar ataques más sofisticados. En [34] los autores proponen un sistema de
detección de intrusos para el protocolo AODV. El sistema se compone de un modelo de
detección de intrusos (IDM) y de un modelo de respuesta de intrusión (IRM). Aunque los autores
proporcionan algunos diagramas del modelo, sólo proporcionan detalles mínimos de
implementación. De esta forma si bien el modelo parece ser factible, el estudio no está
ampliamente documentado.
2.6 Sumario
En este capítulo se presentaron las características principales de las redes móviles Ad hoc. Es
importante destacar que los protocolos de enrutamiento son parte fundamental para el correcto
funcionamiento de estas redes, pero también son un punto muy vulnerable con respecto a la
seguridad. También se presentaron los objetivos de la seguridad y algunos ataques que se pueden
implementar. Se describió el funcionamiento del protocolo AODV, en el que se basa este trabajo
de tesis. Con respecto a la seguridad, algunas propuestas que se describieron brevemente, se
basan en algún tipo de relación preestablecida entre los nodos participantes. Sin embargo, en
algunos casos esta propuesta no es factible debido a que los nodos de la red pueden cambiar
arbitrariamente y no se puede decir de antemano los nodos que participarán. Además, en
ambientes hostiles como campos de batalla los nodos están propensos a ser capturados. La
detección de intrusos es un enfoque de seguridad que no introduce cambios en el protocolo, no
obstante es un campo que no ha sido investigado con profundidad para las redes móviles Ad hoc.
38
Capítulo 3
Entorno de simulación
Introducción
En este capítulo se detallan los aspectos considerados del entorno de simulación. Primeramente
en el apartado 3.1 se da una breve descripción del software elegido: el ns-2. Posteriormente en el
apartado 3.2 se menciona la estructura del simulador. Más adelante en el apartado 3.3 se presenta
la forma en que están constituidos internamente los nodos móviles, y se describe el envío y
recepción de paquetes. En el apartado 3.4 se proporciona la información necesaria para generar
archivos de tráfico y movimiento, así también la configuración de nodos móviles. Los puntos
anteriores son aspectos básicos para realizar simulaciones de redes móviles Ad hoc y forman
parte de la metodología de simulación. En lo que respecta al apartado 3.5 se muestra el formato
del archivo de traza que se genera cuando concluye la simulación y el significado de su
contenido. En el apartado 3.6 se proporciona lo relacionado a la herramienta nam utilizada para
ver gráficamente lo que ocurre en las simulaciones. En el apartado 3.7 se describen brevemente
las herramientas que se utilizaron para procesar datos. Por último en el apartado 3.8 se resumen
las principales consideraciones y aspectos abordados en este capítulo.
3.1 El simulador ns-2

Se llevó a cabo la búsqueda de una herramienta que nos permita recrear de la manera más
apropiada los escenarios de simulación para redes móviles Ad hoc. El simulador de eventos
discretos Network Simulator 2 (ns-2) fue elegido por las características que posee y por que se
39
observó que en varios artículos ha sido el software elegido para simular redes móviles Ad hoc. El
objetivo del simulador ns-2 es soportar la investigación en redes y educación. Es apropiado para
diseñar nuevos protocolos, comparar diferentes protocolos y evaluación de tráfico. Una gran
cantidad de institutos y gente que se dedica a la investigación mantiene y desarrolla éste
simulador, lo cual incrementa la confiabilidad del mismo. Hay versiones disponibles para
diferentes sistemas operativos como Linux, Windows y Mac OS x.
El simulador ns-2 fue originalmente desarrollado bajo la supervisión del proyecto VINT (Virtual
InterNetwork Testbed.- Pruebas de Interred Virtual). Este proyecto estuvo respaldado por la
DARPA (Defense Advanced Research Projects Agency.- Agencia de Investigación de Proyectos
Avanzados de Defensa) y actualmente ha quedado en manos de un grupo de investigadores y
desarrolladores de la Universidad de Berkeley, LBL (Lawrence Berkeley Laboratory), USC/ISI
(University of Southern California/Information Sciences Institute) y Xerox PARC (Palo Alto
Research Center). La versión actualmente en desarrollo es la 2 (de la cual existen múltiples
subversiones). El ns-2 es un simulador gratuito que se suministra con el código fuente completo.
El principal cambio desde la versión 1 ha sido una mejor subdivisión de las clases de objetos que
componen el núcleo del simulador y la adopción del lenguaje OTcl como lenguaje de scripting.
3.2 Estructura de ns-2

El simulador ns-2 utiliza métodos en C++ y OTcl (versión orientada a objetos de Tcl). Tcl (Tool
Command Language) es un lenguaje de programación de comandos muy popular para el
desarrollo de aplicaciones en entornos UNIX (aunque también existe una versión disponible para
Windows). Permite programar de forma rápida y sencilla aplicaciones no demasiado complejas.
Sin embargo, la velocidad de ejecución de éstas no es muy elevada ya que nos encontramos ante
un lenguaje interpretado y no ante un lenguaje compilado.
El simulador interpreta un script de simulación escrito en OTcl. El usuario tiene que configurar
los diferentes componentes (por ejemplo el programador de eventos y los componentes de red)
requeridos para completar la simulación. Algunas partes del simulador están escritas en C++ por
razones de eficiencia. A partir de las trazas o archivos que se obtienen como resultados de la
simulación, se pueden utilizar lenguajes como Perl y Awk para filtrar la traza y obtener los
índices de prestaciones que se deseen evaluar. Finalmente, herramientas tales como Network
Animator (nam) permiten realizar un análisis visual del envío y recepción de paquetes de datos y
40
control a medida que avanza la simulación. Una perspectiva simplificada del ns-2 se ilustra en la
figura 3-1 [35].
Figura 3-1 Perspectiva simplificada del ns-2.
El ns-2 utiliza dos lenguajes porque el simulador tiene dos maneras diferentes de hacer las cosas.
Por una parte, las simulaciones detalladas de los protocolos requieren un lenguaje de
programación el cual pueda de una forma eficiente manipular bytes, cabeceras de paquetes e
implementar algoritmos que puedan correr sobre una gran cantidad de datos. Para esas tareas la
velocidad de ejecución es importante y el tiempo empleado para la programación (compilación,
depuración, etc.) es menos importante. Por otra parte, gran parte de la investigación en redes
requiere variar parámetros y configuraciones, o también de una manera rápida explorar diferentes
escenarios. En esos casos, el tiempo de iteración (cambiar el modelo y volver a correr la
simulación) es más importante y el tiempo de ejecución no lo es tanto. Debido a lo anterior, el ns-
2 emplea dos lenguajes, C++ y OTcl. C++ es más rápido para la ejecución pero lento para
modificar, haciéndolo más apropiado para implementaciones detalladas de protocolos. OTcl corre
mucho más lento pero puede ser modificado rápidamente, haciéndolo apropiado para configurar
las simulaciones [36].
3.3 Redes móviles

Las redes móviles en ns-2 están basadas en extensiones de movilidad desarrolladas por el CMU
Monarch group [37]. Éstas extensiones introducen el concepto de nodos móviles conectados a
canales inalámbricos y permite la simulación de redes inalámbricas y móviles Ad hoc.
41
3.3.1 Nodos móviles

La figura 3-2 muestra el esquema de un nodo móvil en ns-2 con un agente adicional agregado
(para generación y procesamiento de paquetes) [36].
Figura 3-2 Esquema de un nodo móvil en ns-2.
La diferencia más importante entre los nodos alámbricos y los móviles es que éstos últimos se
conectan a canales inalámbricos para su comunicación, mientras que los primeros se conectan
mediante enlaces físicos. Los nodos móviles constan de los siguientes componentes:
42
• Un clasificador de direcciones utilizado para dirigir paquetes hacia el clasificador de

puertos o al agente de enrutamiento.
• Un clasificador de puertos utilizado para dirigir los paquetes al agente agregado en el

nodo móvil.
• Un agente de enrutamiento empleado para administrar las tablas y transmisiones de

paquetes.
• Una capa de enlace responsable de convertir las direcciones de red a direcciones físicas
(con la ayuda de un módulo ARP) y prepara los paquetes para colocarlos en el canal
inalámbrico.
• Un módulo ARP que convierte las direcciones de red a direcciones físicas (MAC).
• Una interfaz de cola utilizada para almacenar los paquetes que deben ser enviados.
• Una capa MAC para administrar el acceso al canal inalámbrico.
• Una interfaz de red que envía y recibe paquetes sobre el canal inalámbrico.
• Un modelo de propagación de radio que determina la intensidad de la señal de los

paquetes recibidos y resuelve si el paquete puede ser recibido por la inteface de red o no.
• Un canal inalámbrico sobre el cual los paquetes son distribuidos.
3.3.2 Transmisión de paquetes

Los paquetes son transmitidos por un nodo móvil en la siguiente forma. Los paquetes son
primero generados por un agente o fuente de tráfico en el nodo móvil. Cada paquete que se
genera es colocado a la entrada de nodo y de ahí pasa al clasificador de direcciones. Este
clasificador determina si los paquetes son destinados para el nodo actual o si deben ser
transmitidos. Los paquetes que son transmitidos son manejados por el agente de enrutamiento, el
cual procesa cada paquete y los envía a la capa de enlace. La capa de enlace convierte las
direcciones de destino a direcciones MAC con la ayuda del módulo ARP. Los paquetes son
entonces enviados a la interface de cola, la cual almacena los paquetes que deben ser
43
transmitidos. La longitud de la interface de cola puede ser especificada dependiendo del tipo de
cola utilizada. La capa MAC recupera los paquetes de la interface de cola cuando el canal
inalámbrico está disponible. Posteriormente, los paquetes se pasan a la interface de red, la cual
los coloca en el canal inalámbrico. Se entregan copias de los paquetes a todas las interfaces de
red conectadas al canal en ese momento. Sin embargo, esto no significa que los paquetes sean
correctamente recibidos por todos los nodos; el modelo de propagación de radio lo determina
durante la recepción de los paquetes.
3.3.3 Recepción de paquetes

Cuando un paquete es recibido por una interface de red, ésta consulta el modelo de propagación
de radio para determinar si el paquete puede ser recibido correctamente o no. Si el paquete es
correctamente recibido se pasa a la capa MAC. La capa MAC lo envía a la capa de enlace y a su
vez ésta lo coloca en la entrada del nodo. El clasificador de direcciones checa la dirección de
destino y si es la misma que el nodo actual el paquete se coloca en el clasificador de puertos, de
lo contrario se pasa al agente de enrutamiento. El clasificador de puertos pasa el paquete al agente
agregado del nodo móvil, basado en el número de puerto contenido en el paquete. Esto completa
la entrega del paquete.
3.4 Metodología de simulación

En este apartado se describen algunos requisitos necesarios para llevar a cabo las simulaciones.
Puesto que el simulador es un poco extenso, la explicación es resumida ya que para más detalles
en [35], [36] y [38] se profundiza en sus características. Estos manuales y tutoriales están
disponibles de forma gratuita en Internet. La versión actual del simulador (versión 2.27) con la
que trabajamos en la tesis tiene incorporado algunos protocolos de enrutamiento entre los que se
encuentra el protocolo AODV.
Para simular redes móviles Ad hoc en ns-2, antes de realizar un script en OTcl que configura la
simulación; creamos dos archivos:
• Un archivo que describe el patrón de movimiento de los nodos.

• Un archivo que describe el tráfico o patrón de comunicación en la red.
44
Los archivos de movimiento y tráfico son incluidos en el script que define la simulación. El
simulador tiene incorporados un generador de movimiento aleatorio para los nodos y un
generador de conexiones de tráfico. En el script también se tiene que especificar las
características de los nodos. Como resultado de la simulación se generan dos archivos, uno
conocido como traza, el cual es una especie de “radiografía” donde se registran todos los eventos
ocurridos durante la simulación y el otro permite una visualización gráfica con el Network
Animator (nam). En la figura 3-3 se resume el proceso simulación.
Figura 3-3 Resumen de simulación.
3.4.1 Generador de movilidad

Hay dos mecanismos para introducir movimiento en ns-2. En el primero método, el usuario
puede definir explícitamente la posición inicial y futura de los nodos. El segundo método emplea
movimiento aleatorio para los nodos. Las simulaciones desarrolladas en la tesis se basan en el
segundo método.
El modelo de movilidad que se utiliza es el Random Waypoint, el cual se caracteriza por manejar
un tiempo de pausa. Cada nodo comienza la simulación en un lugar elegido aleatoriamente dentro
45
del área de simulación. Después de que comienza la simulación, el nodo permanece estacionario
por un tiempo de pausa. Luego el nodo selecciona un destino aleatorio dentro del área de
simulación y se mueve hacia ese destino a una velocidad aleatoria uniformemente distribuida.
Una vez que se alcance el destino, el nodo espera nuevamente otro tiempo de pausa, selecciona
aleatoriamente otro destino y se mueve hacia él. Este comportamiento se repite hasta que finaliza
la simulación.
Los nodos móviles en ns-2 están diseñados para moverse en una topología de tres dimensiones.
Sin embargo la tercera dimensión (Z) no se usa. De esta forma se asume que los nodos se mueven
en un terreno plano y rectangular con la coordenada Z siempre igual a cero. Así, los nodos tienen
las coordenadas X, Y, Z(=0) que se ajustan continuamente de acuerdo al movimiento de los
nodos.
El generador de movimiento está disponible en el directorio ~ns/indep-utils/cmu-scen-

gen/setdest donde ~ns es el directorio donde se instaló el paquete del simulador. El archivo
setdest es un ejecutable al que se le proporcionan algunos parámetros para generar el archivo
de movimiento. Los parámetros que se especifican en la línea de comandos para emplear esta
utilería son las siguientes:
./setdest -v <2> -n <nodes> -s <speed type> -m <min speed> -M <max

speed> -t <simulation time> -P <pause type> -p <pause time>
-x <max X> -y <max Y> > [outdir/file]
Donde:
<2> es la versión del generador de movimiento

<nodes> es el número de nodos móviles en la simulación
<speed type> es el tipo de velocidad que emplean los nodos (1=Uniforme)
<min speed> es la velocidad mínima en metros/segundo
<max speed> es la velocidad máxima en metros/segundo
<pause type> es el tipo de pausa (1=Constante)
<pause time> es el tiempo de pausa en segundos
<max X> dimensión X del terreno en que se mueven los nodos en metros
<max Y> dimensión Y del terreno en que se mueven los nodos en metros
[outdir/file] es el directorio y el nombre del archivo de movimiento que se genera.
46
A manera de ejemplo se muestran algunos pequeños segmentos del archivo que se genera:
$node_(0) set X_ 216.679513098052

$node_(0) set Y_ 692.828245579329
$node_(0) set Z_ 0.000000000000
$node_(1) set X_ 803.672734825855
$node_(1) set Y_ 53.753012123198
$node_(1) set Z_ 0.000000000000
$node_(2) set X_ 567.831269397611
$node_(2) set Y_ 528.176759395461
$node_(2) set Z_ 0.000000000000
En el segmento anterior se observan las coordenadas iniciales para tres nodos (nodos 0, 1 y 2). El
número de nodos que aparecen en el archivo depende del parámetro que se haya especificado en
la línea de comandos. Cuando se produce un movimiento se tiene un segmento como el siguiente:
$ns_ at 50.000000000000 "$node_(0) setdest 589.631240592175

785.082058316811 3.515239374170"
Lo anterior significa que a los 50 segundos el nodo 0 se mueve a las coordenadas X=589.6,
Y=785.0 a una velocidad de 3.51 m/s.
3.4.2 Generador de tráfico

El modelo de comunicación es uno de los más importantes. Hay diferentes modelos y el que
utilizamos para la tesis es el CBR (tasa de bits constante). Hay una utilería para generar archivos
de tráfico CBR en el directorio: ~ns/indep-utils/cmu-scen-gen y consiste en un script de
Tcl al que se le proporcionan los siguientes parámetros en la línea de comandos:
ns cbrgen.tcl [-type cbr|tcp] [-nn nodes] [-seed seed] [-mc

connections] [-rate rate] > [outdir/file]
Donde:
cbr|tcp es el tipo de tráfico

nodes es el número de nodos en la simulación
47
seed es un semilla aleatoria

connections es el número de conexiones
rate es la velocidad de transferencia en paquetes/segundo
[outdir/file]es el directorio y el nombre del archivo de tráfico que se genera.
Por ejemplo el siguiente comando:
ns cbrgen.tcl -type cbr -nn 10 -seed 1.0 -mc 8 -rate 4.0 > cbr-10-test
genera un archivo de conexión de tráfico con el nombre cbr-10-test con tipo de tráfico cbr,
consta de 10 nodos, una semilla aleatoria con valor igual a 1, 8 conexiones y una velocidad de
transferencia de 4 paquetes por segundo. Un segmento del archivo que se genera con el comando
anterior se muestra a continuación:
# 2 connecting to 3 at time 82.557023746220864

set udp_(0) [new Agent/UDP]
$ns_ attach-agent $node_(2) $udp_(0)
set null_(0) [new Agent/Null]
$ns_ attach-agent $node_(3) $null_(0)
set cbr_(0) [new Application/Traffic/CBR]
$cbr_(0) set packetSize_ 512
$cbr_(0) set interval_ 0.25
$cbr_(0) set random_ 1
$cbr_(0) set maxpkts_ 10000
$cbr_(0) attach-agent $udp_(0)
$ns_ connect $udp_(0) $null_(0)
$ns_ at 82.557023746220864 "$cbr_(0) start"
De esta forma, se observa una conexión entre el nodo 2 y el nodo 3 (de las 10 conexiones
creadas). El segundo 82.5 en la última línea indica el instante en que se empieza a generar tráfico
CBR.
3.4.3 Configuración de nodos

Los nodos son fundamentales para las simulaciones. Éstos procesan y transmiten los paquetes, lo
que los convierte en uno de los componentes más importantes de ns-2. Antes de crear los nodos,
48
deben configurarse con el comando node-config, esto se hace mediante una API1 en el script
de OTcl donde se define el protocolo de enrutamiento, capa de enlace, capa MAC, etc. En el
siguiente segmento se muestra el formato típico para la configuración de los nodos con valores de
ejemplo. Después del símbolo # se encuentran comentarios que describen brevemente el
significado de cada línea.
$ns_ node-config -adhocRouting AODV # Tipo de protocolo

-llType LL # Tipo de capa de enlace
-macType Mac/802_11 # Tipo de capa MAC
-ifqType "Queue/DropTail/PriQueue" # Tipo de cola
-ifqLen 50 # Máximo número de paquetes en la cola
-antType "Antenna/OmniAntenna" # Tipo de antena
-propType "Propagation/TwoRayGround" #Tipo de propagación
-phyType "Phy/WirelessPhy" # Tipo de canal físico
-channelType "Channel/WirelessChannel" #Tipo de canal lógico
-topoInstance $topo # Topología
-agentTrace ON # Trazo a nivel de agente
-routerTrace ON # Trazo a nivel de enrutamiento
-macTrace ON # Trazo a nivel de MAC
-movementTrace ON # Trazo de movimiento
Después de configurar los nodos, éstos se crean con el comando node con las opciones de
configuración que se hayan especificado. Si se necesitan nodos con diferentes características, el
procedimiento de configuración puede repetirse y más nodos pueden ser creados.
3.5 Archivos de traza

Los archivos de traza proporcionan información de los eventos que ocurrieron durante la
simulación, por lo que es muy importante interpretarlos correctamente. Hay dos formatos de
salida para las simulaciones de redes inalámbricas. En el primero la información es resumida y se
conoce como formato antiguo y el otro es conocido como el formato nuevo, en el que la
información no es tan fácil de leer como en el formato antiguo, debido a que la información es
más amplia y consiste de un par etiqueta-valor donde etiqueta se refiere al significado del valor
1
Interfaz de Programa de Aplicación
49
obtenido. En las simulaciones de la tesis se utilizó el formato nuevo, el cual se habilita mediante
el comando $ns use-newtrace en el script de OTcl. A continuación se presenta a manera de
ejemplo un segmento del nuevo formato que se genera en el archivo de traza y en la tabla 3-1 se
da una descripción de los campos o columnas que puede tener ese formato [36].
s -t 2.556838879 -Hs 1 -Hd -2 -Ni 1 -Nx 803.18 -Ny 55.65 -Nz 0.00 -Ne
-1.000000 -Nl AGT -Nw --- -Ma 0 -Md 0 -Ms 0 -Mt 0 -Is 1.0 -Id 2.0 -It
cbr -Il 512 -If 0 -Ii 0 -Iv 32 -Pn cbr -Pi 0 -Pf 0 -Po 16777215
Tabla 3-1 Contenido de los archivos de traza.
Columna Contenido
1 Tipo de evento. r = recibe, s = envía,
f = retransmisión, D = pérdida.
Etiqueta Descripción
-t Tiempo
-Ni Identificación de nodo
-Nx Coordenada X del nodo
-Ny Coordenada Y del nodo
-Nz Coordenada Z del nodo
-Ne Nivel de energía del nodo
-Nl Nivel de traza
-Nw Razón de pérdida del paquete:
END = Fin de simulación
Etiquetas con información COL = Colisión
de los nodos DUP = Duplicado
ERR = Error
RET = Cuenta de entrada excedida
STA = Estado inválido
BSY = Ocupado
NRTE = No hay ruta disponible
LOOP = Hay un lazo de ruta
TTL = Tiempo de vida es cero
TOUT = El paquete expiró
CBK = Llamada de regreso a MAC
IFQ = Cola llena
ARP = Pérdida por ARP
OUT = Pérdida por estación base
-Ma Duración
Información a nivel MAC -Md Dirección Ethernet del destino
-Ms Dirección Ethernet del orígen
-Mt Tipo
-Is Dirección del origen, número de puerto
Información a nivel IP -Id Dirección del destino, número de puerto
-It Tipo de paquete
50
-Il Tamaño del paquete

-If Identificación de flujo
-Ii Identificación del paquete
-Iv Valor de TTL
Información a nivel de -Pi Número de secuencia
aplicación -Pf Número de veces de retransmisión
-Po Número óptimo de retransmisiones
Cuando se transmiten paquetes de enrutamiento se agregan algunos campos al formato anterior.

En el siguiente segmento se muestra un ejemplo y en la tabla 3-2 se da la descripción de los
campos que se aumentan.
s -t 4.500000000 -Hs 1 -Hd -2 -Ni 1 -Nx 802.81 -Ny 57.09 -Nz 0.00 -Ne -
1.000000 -Nl RTR -Nw --- -Ma 0 -Md 0 -Ms 0 -Mt 0 -Is 1.255 -Id -1.255 -
It AODV -Il 48 -If 0 -Ii 0 -Iv 30 -P aodv -Pt 0x2 -Ph 1 -Pb 2 -Pd 2 -
Pds 0 -Ps 1 -Pss 6 -Pc REQUEST
Tabla 3-2 Contenido de los archivos de traza para paquetes de enrutamiento.
Etiqueta Descripción
-P Protocolo empleado
-Pt Tipo
-Ph Cuenta de saltos
-Pb Identificación de transmisión
Formato para RREQ -Pd Destino
-Pds Número de secuencia del destino
-Ps Origen
-Pss Número de secuencia del origen
-Pc Nombre del paquete
-Pt Tipo
Formato para RREP y -Ph Cuenta de saltos
RERR -Pd Destino
-Pds Número de secuencia del destino
-Pl Tiempo de vida del paquete
-Pc Nombre del paquete
3.6 Herramienta Network Animator, nam

La herramienta nam es una herramienta de animación desarrollada en Tcl/TK que utilizando
como entrada las trazas generadas automáticamente por ns-2, permite realizar una animación de
la simulación realizada. Para invocar nam se utiliza el siguiente comando:
51
nam nombre_de_archivo.nam
Cuando se abre un fichero de traza con nam, se crea una ventana con la topología indicada en la
simulación. La Figura 3-4 muestra el aspecto general de la herramienta nam. Se han señalado con
flechas los comandos y zonas más importantes de la herramienta.
Figura 3-4 Herramienta nam.
Las principales áreas y funciones de la herramienta nam son las siguientes:
Área de animación: En esta zona de la ventana se visualiza el escenario y la animación del

mismo.
Zoom In y Zoom Out: Estos dos botones permiten acercar o alejar el escenario y poder abarcar
un mayor rango de visión de la simulación.
Animación Stop/Play: Como su nombre indica sirven para iniciar y detener la animación.
Tiempo: Indica el tiempo que llevamos de simulación. Su valor llegará hasta el tiempo que le
hubiéramos indicado en la simulación.
52
Step: Este valor nos indica lo rápido que evolucionará la simulación (en milisegundos). Su valor
se puede modificar con el slider que hay debajo del marcador.
Menú: Agrupa varias opciones como por ejemplo grabar la animación, imprimir el área de
animación, filtrar el tipo de paquetes a visualizar (datos, MAC, enrutamiento), etc.
Se debe señalar que ésta herramienta es una ayuda para entender lo que ocurre en la simulación,
pero no es indispensable para que la simulación se lleve a cabo.
3.7 Herramientas para procesar datos

Como se comentó anteriormente, para obtener índices de prestaciones a partir del archivo de traza
con extensión .tr, se deben procesar los valores obtenidos y graficar el índice que se desea
evaluar. Existen varios programas que realizan lo anterior. A continuación se describen
brevemente las herramientas que se utilizaron en la tesis.
3.7.1 Awk
Awk es un lenguaje de búsqueda y procesamiento de patrones. Dispone de características internas
para descomponer líneas de entrada en campos y comparar estos campos con patrones que se
especifiquen. Debido a estas posibilidades, resulta apropiado para trabajar con archivos que
contienen información estructurada en campos o columnas. Además de las características
anteriores, se trabajó con awk porque está incorporado en la versión de Linux que se utilizó.
La función básica de awk es buscar líneas en archivos que contienen ciertos patrones. Cuando en
una línea se encuentra un patrón, awk realiza las acciones especificadas para dicho patrón sobre
dicha línea. Awk sigue realizando el procesamiento de las líneas de entrada hasta que llega al
final del archivo. El lenguaje de programación awk incluye instrucciones como for, while e if-
else, así como un conjunto de funciones y variables incorporadas [39].
3.7.2 Gnuplot
Gnuplot es un programa que permite generar gráficas en dos y tres dimensiones. Sus principales
virtudes son la facilidad de uso y un acabado de alta calidad. El ns-2 incluye una utilería para
53
hacer gráficas, el Xgraph, pero el Gnuplot consta de más opciones de configuración, razón por la
que se utilizó este paquete. El programa es de distribución libre y cuenta con versiones para
varios sistemas operativos [40].
3.8 Sumario
En este capítulo se presentó todo lo concerniente al entorno de simulación enfocado hacía las
redes móviles Ad hoc. El ns-2 es un simulador de eventos centrado en la investigación sobre
redes. Su modularidad y flexibilidad lo ha hecho muy popular tanto en entornos de investigación
como educativos. Se mostró la estructura del ns-2 y lo más importante a destacar es que se
utilizan dos lenguajes de programación C++ y OTcl. Para definir una simulación se utiliza un
script en OTcl que nos va a permitir definir los distintos elementos de la red y como debe
comportarse. Una vez terminado el script se lo pasamos al ns-2 y este irá realizando la
simulación. De igual forma, se da una descripción de los nodos móviles en ns-2 y la forma en que
envían y reciben paquetes de datos. Con respecto a la metodología de simulación, se proporciona
la información básica para configurar una simulación de redes móviles: generación de archivos
de movimiento y tráfico, así como la configuración de los nodos móviles. Otro aspecto
importante es la interpretación de los archivos de traza, para ello se presenta el formato de
archivo que se genera. El ns-2 dispone de una interfaz gráfica para visualizar las simulaciones
llamada nam que nos da la posibilidad de observar los resultados de la simulación de una forma
gráfica fácilmente comprensible. Para procesar los archivos de traza se emplea el lenguaje de
búsqueda de patrones awk y con gnuplot se realizan las gráficas. El ns-2 es un simulador muy
potente y quizás su desventaja es que al principio es difícil de aprender, pero una vez entendido
es fácil de usar y reutilizar.
54
Capítulo 4
Diseño e implementación de simulaciones
Introducción
En este capítulo se detalla la implementación de las simulaciones realizadas en el ns-2 y se
presentan resultados. El apartado 4.1 describe los tres diferentes escenarios que se consideran
para evaluar. En el apartado 4.2 se presenta la implementación del ataque de número de secuencia
abarcando los cambios internos en los archivos del ns-2, diagramas de flujo que simplifican
procesos de programación y el análisis correspondiente. El apartado 4.3 se refiere al diseño de la
solución. Aquí se presenta el esquema propuesto, el cual es un módulo encargado de detectar el
ataque y los requerimientos que debe cumplir el módulo sugerido, que son los mismos de
cualquier sistema de detección de intrusos. En el apartado 4.4 se implementa el modulo de
detección de ataque, se describen diagramas de flujo de los métodos involucrados y se analizan
los cambios. Posteriormente, en el apartado 4.5 se describen las métricas que se emplean para
evaluar los resultados, los parámetros utilizados y las gráficas obtenidas de los resultados de
simulación. Finalmente, en el apartado 4.6 se presenta el resumen de este capítulo.
4.1 Escenarios de simulación

En el capítulo 2 (apartado 2.4.3) se describió el ataque de número de secuencia en contra del
protocolo AODV y se mencionaron las razones por las que se decidió trabajar con éste ataque en
particular. Con el propósito de comparar resultados en distintas condiciones, las simulaciones se
realizan bajo tres escenarios diferentes. En el primero la simulación se realiza en condiciones
55
normales, es decir, todos los nodos participan de manera correcta en las funciones de
enrutamiento. En el segundo escenario, uno de los nodos es un nodo malicioso que realiza el
ataque de número de secuencia. En el último escenario se introduce una solución al ataque
mencionado y se simula nuevamente. A diferencia del primer escenario, en los dos últimos se
necesitan hacer algunas implementaciones especiales en el ns-2.
4.2 Implementación del ataque de número de secuencia

Para implementar el ataque se ha modificado el código fuente del ns-2, específicamente se ha
desarrollado un nuevo agente que realiza el ataque. Los nodos normales utilizan el protocolo
AODV que trae el simulador y el nodo malicioso utiliza el nuevo agente.
El código principal del protocolo AODV que incluye el simulador se encuentra en los archivos
aodv.cc y aodv.h. En condiciones normales cuando un paquete es recibido, el método recv
analiza la cabecera y checa si es un paquete de datos o un paquete de enrutamiento. Si es un
paquete de datos destinado para el nodo que recibió el paquete, éste lo procesa, de lo contrario lo
retransmite hacia su destino. En el caso que sea un paquete de enrutamiento el que se recibe, se
invoca el método recvAODV que analiza su cabecera para determinar si es una petición de ruta
(RREQ), una respuesta de ruta (RREP) o un mensaje de error (RRER); entonces dependiendo del
tipo de paquete llama al método correspondiente para procesar el paquete.
El nodo malicioso en el ataque de número de secuencia, después de que recibe una petición de
ruta (RREQ), falsifica una respuesta (RREP) como si tuviera una ruta muy reciente hacia el nodo
destino en su tabla de enrutamiento y envía el RREP falsificado en la ruta de regreso establecida
por el mensaje RREQ. El nodo fuente puede ya haber recibido otros mensajes RREP, aún cuando
ese sea el caso, el nodo fuente actualizará su ruta hacia el nodo del cual recibió el mensaje RREP
falsificado, puesto que tiene un número de secuencia de destino más grande y esto significa una
ruta más reciente o nueva. Como resultado, los paquetes de datos serán enviados en la ruta
establecida por el nodo malicioso y no serán entregados en el destino, ya que el nodo atacante
descartará esos paquetes.
En [41] se presenta un estudio detallado de los ataques en contra del protocolo AODV y están
disponibles los archivos para realizar las simulaciones. En esos archivos se ha identificado el
correspondiente al ataque de número de secuencia y nos hemos basado en él para hacer nuestra
propia implementación. Sin embargo, hemos hecho algunas modificaciones. En ese trabajo el
56
ataque se realiza solamente contra un nodo, es decir, el nodo malicioso sólo falsifica mensajes
RREP cuando recibe mensajes RREQ de un nodo en específico (nodo víctima). Pero el mayor
impacto contra el desempeño de la red se tiene cuando el nodo malicioso realiza el ataque no
importando de qué nodo recibió el mensaje RREQ. Entonces, en nuestra implementación el nodo
malicioso realiza el ataque contra cualquier nodo que le envíe una petición de ruta. En la
implementación del nuevo agente en el ns-2, algunos archivos internos tienen que ser
modificados. En esos archivos, el agente malicioso llamado MYAODV fue agregado de forma
similar al agente de enrutamiento AODV. En la tabla 4-1 se muestran los archivos que fueron
modificados.
Tabla 4-1 Archivos que fueron modificados para implementar el ataque.
Localización de archivo Nombre de archivo Código agregado

PT_MYAODV en enum packet_t
y
(*)~ns/common packet.h name_ [PT_MYAODV] = “MYAODV” en
class p_info
~ns/tcl/lib ns-packet.tcl MYAODV en foreach prot
~ns/tcl/lib ns-default.tcl Agent/MYAODV set victimNode 200
MYAODV {
set ragent [$self
create-myaodv-agent $node]
} en switch -exact $routingAgent_
y
~ns/tcl/lib ns-lib.tcl Simulator instproc
create-myaodv-agent { node } {
set ragent [new Agent/MYAODV
[$node id]]
$self at 0.0 "$ragent start"
$node set ragent_ $ragent
return $ragent
}
friend class MYAODV en class Neighbor
y
~ns/routing rttable.h friend class MYAODV
friend class MyLocalRepairTimer
en class rt_entry
friend class MYAODV en class
AODV_Neighbor y class AODV_Precursor
~ns/aodv aodv_rtable.h y
friend class MYAODV
friend class MyLocalRepairTimer
en class aodv_rt_entry
(*)~ns es el directorio donde se instaló el simulador
57
En la figura 4-1 se muestra el proceso que se sigue en aodv.cc cuando un nodo recibe un RREQ
en condiciones normales. Para simplificar el código empleamos diagramas de flujo.
INICIO
Recibe RREQ
Extrae la cabecera del

paquete
¿Soy el nodo SI
fuente o ya Descarta el paquete
recibí esta
RREQ?
FIN
NO
Registra el broadcast_id y
la ruta de regreso
SI
¿Soy el
Incrementa Envía
nodo
dest_sequence_# RREP
destino?
NO FIN
¿Tengo SI Envía RREP con información

una ruta de la tabla
reciente al
destino?
NO FIN
Transmite RREQ a los

vecinos
FIN
Figura 4-1 Proceso que sigue un nodo normal cuando recibe un mensaje RREQ.
El proceso anterior corresponde al comportamiento del protocolo AODV descrito anteriormente.
58
El código principal del agente MYAODV se encuentra en dos archivos aparte: myaodv.cc y
myaodv.h, y su código es muy semejante al de los archivos aodv.cc y aodv.h con las
modificaciones necesarias para llevar a cabo el ataque. Los métodos que se modifican son recv,
recvRequest y sendReply. Los archivos myaodv.cc y myaodv.h se copian al directorio
~ns/aodv. En el anexo B al final de la tesis se encuentran los pasos para implementar el agente
y desarrollar las simulaciones, así como el listado de los programas. En la figura 4-2 se muestra el
proceso que realiza el nodo malicioso.
INICIO
Recibe RREQ
Extrae la cabecera del

paquete
¿Soy el nodo SI
fuente o ya Descarta el paquete
recibí esta
RREQ?
FIN
NO
Registra el broadcast_id y
la ruta de regreso
SI
¿Soy el
Incrementa Envía
nodo
dest_sequence_# RREP
destino?
NO FIN
Incrementa
dest_sequence_# (+10)
Envía RREP falsificado
FIN
Figura 4-2 Proceso que sigue el nodo malicioso cuando recibe un mensaje RREQ.
59
En la figura anterior se aprecia el comportamiento del nodo atacante y puede compararse con el
de los nodos normales. Cuando el nodo malicioso es el destino opera igual que los demás, pero
cuando no lo es, invariablemente incrementa el número de secuencia en un valor de +10 y envía
un RREP falsificado hacia el nodo origen. El valor de +10 que representa el incremento, está
basado en [41] y es un valor suficiente para desempeñar el ataque, dado que se supone que el
nodo destino es el único que puede incrementar este valor en +1. Con un incremento mínimo
puede darse el caso que el nodo malicioso no logre desempeñar el ataque, debido a que el número
de secuencia que porta el paquete RREQ es un poco antiguo y el nodo destino contesta con un
número de secuencia mucho más actualizado. En la figura 4-3 se muestra el segmento de un
archivo de traza que se genera al correr la simulación en presencia del nodo atacante.
Figura 4-3 Visualización del ataque en el archivo de traza.
Aunque no se muestra toda la información del archivo de traza (se ha colocado sólo un pequeño
segmento ya que el archivo es muy extenso), se ve claramente la información que interesa. El
nodo fuente transmitió un RREQ en donde el número de secuencia de destino es 11. El nodo
destino al recibir el RREQ incrementa el valor en uno y envía el RREP con el número de
secuencia igual a 12. El nodo malicioso lo incrementa en 10 y envía un RREP con el número de
secuencia igual a 21. El ataque se lleva a cabo.
60
4.3 Diseño de solución

Se han escrito diversos artículos proponiendo soluciones a los problemas de seguridad tanto del
protocolo AODV como de otros protocolos de enrutamiento, en el capítulo 2 (sección 2.5) se
describieron brevemente algunos de ellos. Sin embargo, en la mayoría se hacen modificaciones
importantes al protocolo y en algunos casos puede decirse que prácticamente se propone un
nuevo protocolo. Nuestro enfoque es diferente, intentamos conservar intacta la operación del
protocolo, pues a pesar de todo, el protocolo presenta un buen desempeño cuando no se encuentra
bajo ataque. Bajo esta premisa el esquema de seguridad está más orientado hacia un sistema de
detección de intrusos.
Por otra parte, mecanismos de prevención tal como el cifrado y la autentificación pueden reducir
las intrusiones pero no las eliminan. Estos mecanismos no pueden proteger en contra de nodos
comprometidos (atacante que conoce la clave). Entonces es necesario contar con otros
mecanismos que nos permitan neutralizar esas situaciones y la detección de intrusos representa
una segunda línea de defensa [42].
4.3.1 Esquema propuesto

También se mencionó en el capítulo 2 (sección 2.5.2) las clasificaciones de los sistemas de
detección de intrusos. Por las características de las redes móviles Ad hoc, nuestra solución está
basada en host y como conocemos la forma en que el nodo malicioso puede implementar el
ataque de número de secuencia, el análisis que se realiza está basado en la detección de abusos.
En lugar de sistema de detección de intrusos, hemos decidido nombrar al modelo “módulo de

detección de ataque” porque el primer nombre sugiere la idea de un sistema que puede detectar
cualquier tipo de ataque o intrusión, y ya que estamos trabajando con un ataque específico el
segundo nombre se adecua mejor al planteamiento de la solución, pero a partir de esta idea el
módulo pudiera extenderse para detectar otros ataques y también para operar con otros
protocolos. Antes de implementar nuestra solución se hizo un análisis profundo del protocolo
AODV y de su código fuente en el simulador ns-2, sobre todo en los métodos de envío y
recepción de paquetes que es donde se desarrolla el ataque. El método recvReply adquiere gran
importancia porque es el encargado de procesar los paquetes RREP cuando llegan a un nodo y el
ataque de número de secuencia se realiza por medio de estos paquetes.
61
A continuación se presenta en la figura 4-4 un esquema del método recvReply con una
modificación que representa el módulo encargado de detectar el ataque.
Figura 4-4 Módulo de detección de ataque incorporado en el método recvReply.
Como se puede observar en la figura 4-4, el módulo de detección de ataque se encuentra al

principio del método, de manera que se puedan procesar los paquetes antes de que un posible
ataque se lleve a cabo. Una vez que llega un paquete RREP al módulo de detección de ataque,
éste debe analizar si se trata de un paquete malicioso; si ese es el caso se toma una acción o
respuesta, de lo contrario el método continúa normalmente y a su vez cuando el método termina,
el protocolo AODV continúa operando de forma normal.
4.3.2 Requerimientos del sistema de detección de intrusos

Debido a las características de las redes móviles Ad hoc, un sistema de detección de intrusos,
independientemente de las especificaciones de la red, debe cumplir ciertos requerimientos [43]:
• No debe introducir nuevas vulnerabilidades en el sistema.

• Requiere recursos mínimos del sistema y no debe afectar el desempeño al introducir
carga adicional.
• Debe trabajar continuamente y permanecer transparente para el sistema y los usuarios.
• Debe ser confiable y minimizar las falsas alarmas.
Con base en lo anterior, nuestro propósito es que el módulo de detección cumpla esos
requerimientos.
62
4.4 Implementación del módulo de detección de ataque

Para ver con más detalle la forma en que se ha incrustado el módulo de detección de ataque, en la
figura 4-5 se muestra un diagrama de flujo del método recvReply en operación normal y en la
figura 4-6 se muestra la modificación que se realiza. Posteriormente se analizan los cambios.
INICIO
Recibe RREP
¿# _sec. en RREP No
es mayor que
# _sec. de tabla?
Si
Actualiza tabla
Envía paquetes
Si
¿Soy el nodo
fuente?
No
Envía RREP hacia Libera paquete

el nodo fuente
FIN
Figura 4-5 Proceso normal que sigue un nodo al recibir un paquete RREP.
63
INICIO
Recibe RREP
¿Soy el nodo Si ¿# _sec. tabla + 8 Si

fuente? es menor que
# _sec. en RREP?
No
No
Descarta paquete
¿# _sec. en RREP No
es mayor que
# _sec. de tabla?
Si
Actualiza tabla
Envía paquetes
Si
¿Soy el nodo
fuente?
No
Envía RREP hacia Libera paquete

el nodo fuente
FIN
Figura 4-6 Proceso al recibir un paquete RREP con el módulo de detección de ataque incorporado.
64
En la figura 4-5 observamos que cuando se recibe un paquete RREP, se compara el número de
secuencia que acarrea con el número de secuencia que se tiene en la tabla, si el número en el
RREP es mayor (no importa que tan mayor) se actualiza la tabla lo que permite crear una ruta por
el camino establecido por el RREP. Es aquí donde se aprovecha el nodo malicioso para aplicar el
ataque, al enviar un número de secuencia que es más grande que otro RREP que pueda recibirse.
En la figura 4-6 el rectángulo punteado representa el módulo de detección de ataque. Cuando un

nodo recibe un RREP examina si el paquete va dirigido finalmente hacia él, es decir, si él es el
nodo fuente que inició con anterioridad un descubrimiento de ruta. Si no es el nodo fuente, el
proceso que continúa es idéntico al de la figura 4-5 después de recibir el RREP. Si se cumple que
es el nodo fuente, se pasa a una segunda condición donde se analiza que tan grande es el número
de secuencia que viene en el RREP con respecto al número de secuencia almacenado en la tabla,
esto se hace con el conocimiento que tenemos de que el nodo malicioso debe incrementar el
número en un valor relativamente grande. Aquí se suma al número de secuencia de la tabla un
valor de más ocho. Si aún sumando este valor, el número en el RREP es mayor significa que algo
anormal está ocurriendo pues este número no debería ser tan grande. Entonces el nodo no
actualiza su tabla ni realiza otra acción del método, como respuesta el nodo descarta el paquete.
Si no se cumple la condición, el método continúa en su operación normal.
Si bien es cierto que se supone que no deberíamos saber en que valor aumentará el atacante el
número de secuencia (aunque en realidad para este caso de estudio sabemos que lo aumenta en un
valor de +10), también es cierto que el atacante tendrá que elegir un número que garantice que
pueda suplantar otras rutas. El número 8 representa un valor límite para determinar si el RREP es
malicioso o no. Se probaron otros valores límites a través de simulaciones y el número 8 fue el
que presentó una mejor eficiencia a la hora de detectar los ataques y también de evitar falsas
detecciones de ataques.
En la solución propuesta se está protegiendo al nodo fuente, sin embargo también los nodos
intermedios se ven afectados por el ataque, lo que significa que modifican sus tablas y los
paquetes de datos pueden ser entregados a través de la ruta establecida por el nodo malicioso,
aunque no necesariamente, pues el nodo malicioso puede estar muy alejado y no enviar un RREP
y también se puede presentar el caso que no haya nodos intermedios en una ruta. Originalmente
se pensó en un procedimiento similar al que protege al nodo fuente para los nodos intermedios y
se hicieron las simulaciones pero se presentaron algunos inconvenientes.
65
Debido a la característica de movilidad de las redes móviles Ad hoc y al comportamiento del

protocolo AODV, frecuentemente se pierden enlaces y se solicitan nuevas peticiones de ruta que
van incrementando el número de secuencia de los destinos. Algunos nodos intermedios se
mueven y salen de la ruta mientras que otros intentarán formar parte de las nuevas rutas que se
establezcan. Estos últimos tendrán en su tabla el número de secuencia igual a cero. El colocar el
módulo de detección tiene como consecuencia que rutas válidas sean consideradas como falsas.
De esta forma, no se entregan los paquetes al nodo atacante pero tampoco al nodo destino, y eso
afecta grandemente el desempeño de la red. Entonces, puesto que el nodo fuente puede llevar un
mejor control de los números de secuencia y por los resultados que se obtuvieron en las
simulaciones, se decidió retirar la protección para los nodos intermedios.
4.5 Resultados de simulación

Las métricas que se utilizaron para evaluar el desempeño del módulo de detección de ataque son
las siguientes:
• Tasa o porcentaje de paquetes entregados.
• Número de paquetes RREP enviados por el nodo 2.
• Precisión en la detección de ataques.
• Retardo promedio de los paquetes transmitidos.
En los escenarios de simulación se va variando la movilidad de los nodos y el número de

conexiones activas para observar su impacto en el desempeño de la red. En la tabla 4-2 se listan
los parámetros de simulación. Los parámetros son muy similares a los reportados en otros
proyectos de investigación, por ejemplo en [27]. La razón por la que decidimos utilizar valores
similares fue para tener una medida de comparación con los resultados obtenidos. No se
consideran velocidades muy rápidas porque la frecuencia en el cambio de rutas será muy grande e
influye en el efecto producido por el nodo malicioso. La tasa de envío de los paquetes es escogida
de tal manera que evite pérdidas de paquetes causados por alguna congestión. Se empleó una
computadora con procesador Pentium IV y 384 MB de memoria RAM. Se recomienda tener un
espacio considerable en el disco duro, ya que los archivos de traza que se generan son algo
grandes y mientras más fuentes de tráfico se especifique en la simulación mayor espacio ocupan.
66
Tabla 4-2 Parámetros de simulación
Sistema operativo Linux Red Hat 7.3

Simulador ns-2
Duración de la simulación 1000 segundos
Área de simulación 850 m∗850 m.
Número de nodos móviles 20
Rango de transmisión 250 m.
Modelo de movimiento Random waypoint
Velocidad máxima 4-20 m/s
Tipo tráfico CBR (UDP)
Tamaño paquetes datos 512 bytes
Tasa de envío 2 pkt/s
(*) Número de nodos maliciosos 0-1
Tiempo de pausa de los nodos 10 segundos
(*) 0 en condiciones normales y 1 en presencia del ataque.
En la figura 4-7 se muestra un ejemplo de lo que acontece durante las simulaciones con la
herramienta nam. El nodo 4 debe establecer una comunicación con el nodo 5, pero el nodo 2
realiza el ataque de número de secuencia. En la figura 4-8 se muestra un instante del mismo
escenario de simulación, pero ahora el ataque no tiene éxito y los paquetes se dirigen al nodo 5.
Figura 4-7 Visualización con nam - bajo ataque.
67
Figura 4-8 Visualización con nam – módulo de detección de ataque incorporado.
A continuación se presentan mediante gráficas, los resultados obtenidos en las simulaciones.
Tasa de entrega
En la gráfica de la figura 4-9 se muestra el porcentaje de paquetes entregados al variar el número

de conexiones. En ésta gráfica se incluyen los resultados de las tres condiciones de simulación.
100
80 AODV operación normal

AODV bajo ataque
AODV y módulo de detección bajo ataque
Tasa de entrega (%)
60
40
20
0
4 8 12 16 20
Número de conexiones
Figura 4-9 Tasa de entrega versus número de conexiones.
68
Se puede apreciar el impacto que se produce en la red cuando se encuentra bajo ataque, el
porcentaje de paquetes entregados en los destinos disminuye casi al 40%. Con el módulo de
detección de ataque incorporado, la tasa aumenta aproximadamente al 60%. En la gráfica de la
figura 4-10 se muestra la tasa de entrega al variar la velocidad de los nodos. También en este
caso, la tasa de entrega aumenta aproximadamente al 60% lográndose una mejora de casi 20%.
100

AODV bajo ataque
Tasa de entrega (%)
60
40
20
0
4 8 12 16 20
Máxima velocidad de movimiento de los nodos (m/s)
Figura 4-10 Tasa de entrega versus movilidad de los nodos.
Número de paquetes RREP enviados por el nodo 2
En la figura 4-11 se muestra la gráfica del número de paquetes RREP enviados por el nodo 2
versus el número de conexiones en condiciones normales.
50
45
Número de RREP enviados por el nodo 2
35
30
25
20
15
10
4 8 12 16 20
Figura 4-11 Número de RREP enviados versus número de conexiones (condiciones normales).
69
Para evaluar esta métrica se colocaron las gráficas en figuras separadas, con el objetivo de
observar mejor el comportamiento de las curvas. En las figuras 4-12 y 4-13 se muestran las
gráficas del número de paquetes RREP enviados versus el número de conexiones, sin y con el
módulo incorporado, respectivamente (ambas bajo ataque).
400
350
300 AODV bajo ataque
250
200
150
100
50
4 8 12 16 20
Figura 4-12 Número de RREP enviados versus número de conexiones (bajo ataque).
700
600 AODV y módulo de detección bajo ataque
500
400
300
200
100
4 8 12 16 20
Figura 4-13 Número de RREP enviados versus número de conexiones (módulo de detección y bajo ataque).
En las tres gráficas anteriores se aprecia un comportamiento proporcional entre el número de

conexiones y el número de RREP enviados por el nodo 2, esto es normal porque mientras más
conexiones de tráfico haya en la red, más oportunidad hay de que el nodo 2 pueda enviar un
mensaje RREP. Sin embargo, cuando se realiza el ataque, el número de mensajes RREP (falsos
70
en este caso) enviados es mucho mayor comparado bajo condiciones normales. Y es que el
ataque está implementado de manera que el nodo malicioso responde con un RREP falso a
cualquier petición de ruta que le llegue. Con el módulo incorporado el número es todavía mayor;
esto es porque llega un momento en que el nodo fuente descarta cualquier RREP que recibe
(debido a enlaces rotos e incrementos en el número de secuencia). Entonces, para el nodo fuente
no hay una ruta disponible y continuamente estará emitiendo peticiones de ruta, lo que explica el
aumento en el número de RREP.
En las figuras 4-14, 4-15 y 4-16 se muestran las gráficas del número de paquetes RREP enviados
versus la movilidad de los nodos para cada uno de los casos.
80
70
AODV operación normal
60
50
40
30
20
4 8 12 16 20
Figura 4-14 Número de RREP enviados versus movilidad de los nodos (condiciones normales).
400
350
300 AODV bajo ataque
250
200
150
100
50
4 8 12 16 20
Figura 4-15 Número de RREP enviados versus movilidad de los nodos (bajo ataque).
71
500

450
400
350
300
4 8 12 16 20
Figura 4-16 Número de RREP enviados versus movilidad de los nodos (módulo de detección y bajo ataque).
Comparando las últimas tres gráficas observamos que cuando se realiza el ataque, el número de
RREP enviados es mayor y aumenta con el módulo de detección por las mismas razones
mencionadas cuando se varía el número de conexiones.
Precisión en la detección de ataques
En las figuras 4-17 y 4-18 se muestran la tasa de entrega versus el número de conexiones y
movilidad de los nodos, respectivamente. En estos casos se consideran condiciones normales y el
módulo incorporado (ambas en ausencia de ataque).
100
80
AODV y módulo de detección (operación normal)
Tasa de entrega (%)
60
40
20
0
4 8 12 16 20
Figura 4-17 Tasa de entrega versus número de conexiones (precisión en detección).
72
100
80
Tasa de entrega (%) AODV y módulo de detección (operación normal)
60
40
20
0
4 8 12 16 20
Figura 4-18 Tasa de entrega versus movilidad de los nodos (precisión en detección).
Es importante que cuando la red no se encuentre bajo ataque y tenga incorporado el módulo de
detección, el desempeño de la red no disminuya significativamente, pues no serviría de mucho en
esos casos. Todos los sistemas de detección de intrusos sufren de falsas alarmas cuando
consideran que hay un comportamiento malicioso en la red y en realidad no lo hay. Los sistemas
basados en la detección de abusos, técnica que nuestro módulo de detección utiliza, incurren en
menos errores que otras técnicas. En estas gráficas se puede apreciar que no hay una gran
diferencia en las curvas que afecte el desempeño.
Retardo promedio de los paquetes transmitidos
En las figuras 4-19 y 4-20 se muestran las gráficas del retardo promedio de los paquetes versus el
número de conexiones y la movilidad de los nodos para cada condición de simulación.
Aquí se incluyen los posibles retardos causados por almacenamiento (buffer) durante el retardo
de descubrimiento de ruta, la cola en la interfaz, el retardo de transmisión en la capa MAC y por
los tiempos de transferencia.
De la figura 4-19 se observa que hay una disminución en el retardo promedio cuando el protocolo
se encuentra bajo ataque (comparado con la operación normal). Debemos mencionar que en este
caso se promedia una menor cantidad de paquetes, es decir, sólo los que son entregados en los
destinos. Cuando se incorpora el módulo de detección hay un ligero incremento que se debe al
tiempo que emplea el nodo fuente en determinar si se encuentra bajo ataque. En la figura 4-20 se
73
observa un comportamiento similar, aunque se aprecia que los retardos se incrementan al

aumentar la velocidad de los nodos. Esto se debe a que hay más pérdidas de enlaces y se tienen
que originar nuevas peticiones de ruta, por lo tanto los paquetes tienen que esperar para ser
transmitidos.
0.16
0.14
0.12
Retardo promedio (s)
0.1
0.08

0.06
AODV bajo ataque
0.04
0.02
0
4 8 12 16 20
Figura 4-19 Retardo promedio versus número de conexiones.
0.25
0.2
Retardo promedio (s)
0.15
0.1
AODV bajo ataque
0.05 AODV y módulo de detección bajo ataque
0
4 8 12 16 20
Figura 4-20 Retardo promedio versus movilidad de los nodos.
Con respecto a otros trabajos encontrados que se relacionan con esta problemática, en [27] se
describe el ataque de número de secuencia en AODV y se realizan simulaciones para evaluar el
impacto que ocasiona. Los resultados que se obtienen en condiciones normales y bajo ataque son
muy similares a los obtenidos en este trabajo de tesis. Sin embargo, a pesar de que se presenta un
74
buen análisis del ataque no se describe una propuesta de solución. En [34] se presenta un modelo
de detección y respuesta de intrusión para varios tipos de ataques contra el protocolo AODV. Los
autores proporcionan algunos diagramas del modelo y gráficas que se obtienen como resultado de
simulación. Aunque el modelo parece ser factible, el estudio no está ampliamente documentado y
no es apropiado comparar los resultados, además de que hay algunas diferencias en los
parámetros simulados como número de nodos, fuentes, etc. En [30] se propone un conjunto de
extensiones a los paquetes de enrutamiento del protocolo AODV para proteger contra diversos
ataques. Se utilizan firmas digitales, así como mecanismos de administración de claves. El único
inconveniente es que no se incluyen simulaciones o resultados que permitan justificar su
desempeño. [28], [29] y [31] son sólo algunos de los trabajos donde se presentan propuestas para
proporcionar seguridad a otros protocolos de enrutamiento como DSDV y DSR. No obstante, en
la mayoría se requiere algún tipo de relación preestablecida entre los nodos participantes,
requisito que a nuestro parecer no siempre es viable, debido a que los nodos están expuestos a ser
capturados y al robo de claves. A diferencia de esos mecanismos, en esta propuesta no se requiere
alguna relación previa entre los nodos.
4.6 Sumario
En este capítulo se han descrito los diferentes escenarios que se consideran para realizar las
simulaciones. Se presentan los detalles de implementación del ataque de número de secuencia y
los cambios que se deben hacer en el ns-2 para que el ataque se lleve a cabo. Se propone un
módulo de detección de ataque en el protocolo AODV y se mencionan los requerimientos que
debe cumplir dicho módulo. Tanto para la implementación del ataque como del módulo, se
analizan las modificaciones efectuadas en algunos métodos que contiene el protocolo AODV
incluido en el simulador. De igual forma, se describen las métricas consideradas para evaluar los
resultados de las simulaciones y los parámetros utilizados. Las gráficas que se presentan permiten
analizar los resultados obtenidos en las simulaciones para cada uno de los escenarios
considerados.
75
76
Capítulo 5
Conclusiones
Introducción
Como último capítulo de la tesis, se aportan las conclusiones así como los posibles trabajos que
se pueden continuar partiendo de la presente investigación realizada. En el apartado 5.1 se
presentan las conclusiones al trabajo desarrollado, donde se proporcionan algunos datos
importantes que justifican el tema de estudio. Por último en el apartado 5.2 se sugieren tres
propuestas como trabajos futuros.
5.1 Conclusiones
La seguridad en redes se ha convertido en un tema de alta prioridad en los últimos años y por sus
características, los sistemas inalámbricos son más propensos a algún tipo de ataque. Esto se
observó en los diferentes artículos analizados que hacían referencia a las vulnerabilidades de
estas tecnologías.
Cuando se habla de redes inalámbricas y móviles el reto de proporcionar seguridad es mayor. La

libertad que proporcionan los dispositivos inalámbricos y móviles es su principal ventaja e,
irónicamente, también su principal problema. Al contrario del caso de las redes alámbricas
tradicionales, un intruso no necesita acceso físico a la red para poder asaltarla. En algunos casos
debido a las presiones del mercado, los fabricantes y organismos encargados de emitir estándares
77
se han apresurado en obtener soluciones a los problemas de seguridad. En otros casos, el proceso
de implementar seguridad ha sido más lento.
En particular las redes móviles Ad hoc (MANET) presentan los siguientes desafíos: arquitectura
de red abierta, medio inalámbrico compartido, recursos computacionales limitados, duración
limitada de la batería, topología dinámica y no tienen una estructura fija. Las MANET están
expuestas a varios tipos de ataques y los protocolos de enrutamiento son quizá los puntos más
vulnerables. Aunque los protocolos de enrutamiento para redes móviles Ad hoc no son seguros,
su uso no está excluido de entornos donde la seguridad de la red no es absolutamente necesaria.
Sin embargo, existen otros entornos tal como militares o gubernamentales, donde la seguridad
adquiere mayor importancia.
En este trabajo nos enfocamos en el protocolo AODV, el cual ha adquirido gran popularidad y
aceptación por parte del IETF. Las propuestas de seguridad encontradas en el estado del arte, se
centran en incluir mecanismos de cifrado y autentificación. Un campo que no ha sido
ampliamente investigado es la detección de intrusos en redes móviles Ad hoc, la cual permite
establecer una segunda línea de defensa.
¾ En relación a la investigación desarrollada se desprenden las siguientes

conclusiones:
• La seguridad en las MANET se encuentra en una etapa temprana.
• La seguridad en MANET es una tarea con varios desafíos, particularmente al hecho de

que los nodos móviles están sujetos a ser capturados.
• El protocolo AODV fue diseñado asumiendo que todos los nodos cooperan entre sí para
realizar las funciones de enrutamiento y transferencia de paquetes. Por lo anterior, cuando
se diseñó el protocolo no se consideró ninguna medida de seguridad.
• Los nuevos protocolos deben diseñarse tomando en cuenta desde un principio los
objetivos de seguridad.
• Una solución más completa debe combinar mecanismos de seguridad como el cifrado y la
autentificación con los sistemas de detección de intrusos.
78
¾ Referente a la aportación las conclusiones son:
• Se realizó una investigación del estado del arte sobre los mecanismos de seguridad
empleados en las tecnologías inalámbricas y móviles que han alcanzado mayor auge en el
mercado.
• Se utilizó el simulador ns-2 y su documentación.
Con el ns-2 se implementaron escenarios de simulación bajo tres condiciones diferentes:
• En condiciones normales, se obtuvieron resultados que se utilizaron como parámetro para

evaluar el desempeño de la red bajo otras condiciones.
• Se desarrolló un nuevo agente en el simulador que realiza el ataque de número de

secuencia. Al evaluar el desempeño de la red se puso de manifiesto la vulnerabilidad de la
red y la importancia de proporcionar algún mecanismo que proteja la red.
• Se propuso un módulo que detecta el ataque mencionado y se evaluó su desempeño.
¾ Y en relación al módulo de detección de ataque implementado se desprenden

las siguientes conclusiones:
• No introduce grandes cambios en el protocolo, por lo que su modo de operación

permanece prácticamente igual y transparente para los usuarios.
• Detecta el ataque de número de secuencia y mejora en aproximadamente 20% el

porcentaje de paquetes entregados.
• No genera una cantidad elevada de detecciones falsas.
• Las simulaciones mostraron que hay un incremento insignificante en el retardo promedio

de los paquetes transmitidos después de incorporar el módulo.
• El módulo pudiera extenderse para proteger contra otros ataques.
• Al evaluar el desempeño del módulo propuesto se logró el objetivo principal de la tesis, el

cual se refiere al desarrollo de un mecanismo que mejore la seguridad de la red. Como
79
característica a resaltar en comparación con otros mecanismos de seguridad, no se

requiere algún tipo de relación previa entre los nodos.
5.2 Trabajos futuros

Como posibles trabajos futuros que se pueden llevar a cabo con base en este trabajo desarrollado
se tienen:
1. Implementar un mecanismo que permita aislar al nodo atacante.
2. Llevar a cabo la implementación del esquema propuesto para otros ataques.
3. Llevar a cabo simulaciones para casos donde haya más de un nodo malicioso.
80
Lista de acrónimos
3G Tercera Generación
3rd Generation
3GPP Proyecto de Sociedad para Tercera Generación
Third Generation Partnership Project
A
ACL Lista de Control de Acceso
Access Control List
AODV Vector de Distancia Sobre Demanda Ad hoc
Ad hoc On-demand Distance Vector
AP Punto de Acceso
Access Point
API Interfaz de Programación de Aplicaciones
Application Program Interface
ARAN Enrutamiento Autentificado para Redes Ad hoc
Authenticated Routing for Ad hoc Networks
ARP Protocolo de Resolución de Direcciones
Address Resolution Protocol
AUC Centro de Autentificación
Authentication Center
B
BD_ADDR Dirección del Dispositivo Bluetooth
Bluetooth Device Address
BSC Controlador de Estaciones Base
Base Station Controller
BSS Subsistema de Estación Base
Base Station Subsystem
BTS Estación Base
Base Station
C
CBR Tasa de bits Constante
Constant Bit Rate
CEPT Conferencia Europea de Administraciones de Correos y Telecomunicaciones
European Conference of Postal and Telecommunications Administrations
CMU Universidad Carnegie Mellon
Carnegie Mellon University
81
D
DARPA Agencia de Investigación de Proyectos Avanzados de Defensa
Defense Advanced Research Projects Agency
DSDV Vector de Distancia con Secuencia de Destino
Destination Sequenced Distance Vector
DSR Enrutamiento de Fuente Dinámica
Dynamic Source Routing
DSSS Espectro Disperso de Secuencia Directa
Direct Sequence Spread Spectrum
E
EAP Protocolo de Autentificación Extensible
Extensible Authentication Protocol
EDR Tasa de Datos Mejorada
Enhanced Data Rates
EIR Registro de Identidad de Equipos
Equipment Identity Register
ESSID Identificación mediante el Conjunto de Servicios Extendidos
Extended Service Set IDentifier
ETSI Instituto de Estándares de Telecomunicaciones Europeo
European Telecommunications Standards Institute
G
GSM Sistema Global de Comunicaciones Móviles
Global System for Mobile Communications
GMSC Gateway del Centro de Conmutación de servicios Móviles
Gateway Mobile Switching Center
H
HCI Interfaz Controladora de Host
Host Controller Interface
HDTV Televisión de Alta Definición
High Definition Television
HLR Registro de Localización Local
Home Location Register
I
ICV Valor de Comprobación de Integridad
Integrity Check Value
IETF Grupo de Tareas de Ingeniería en Internet
Internet Engineering Task Force
82
IMEI Identificación de Equipo Móvil Internacional
International Mobile Equipment Identity
IMSI Identidad de Suscriptor Móvil Internacional (Identidad de abonado)
International Mobile Subscriber Identity
IV Vector de Inicialización
Initialization Vector
L
L2CAP Nivel de Adaptación y Control del Enlace Lógico
Logical Link Control and Adaptation Protocol
LBL Laboratorio Lawrence Berkeley
Lawrence Berkeley Laboratory
LFSR Registro de Desplazamiento con Realimentación Lineal
Linear Feedback Shift Register
M
MAC Control de Acceso al Medio
Medium Access Control
MAN Red de Área Metropolitana
Metropolitan Area Network
MANET Red Móvil Ad hoc
Mobile Ad hoc Network
MIC Comprobación de Integridad de Mensaje
Message Integrity Check
MS Estación Móvil
Mobile Station
MSC Centro de Conmutación de servicio Móvil
Mobile services Switching Center
N
nam Animador de Red
Network Animator
ns-2 Simulador de Red 2
Network Simulator 2
NSS Subsistema de Conmutación y Red
Network and Switching Subsystem
O
OFDM Acceso Múltiple por División de Frecuencia
Frequency Division Multiple Access
OTcl Tcl orientado a Objetos
83
Object Tcl
P
PARC Centro de Investigación de Palo Alto
Palo Alto Research Center
PDA Asistente Digital Personal
Personal Digital Assistant
PDU Unidad de Datos de Protocolo
Protocol Data Unit
PIN Número de Identificación Personal
Personal Identification Number
PSK Clave Compartida con Antelación
Pre-Shared Key
R
RADIUS Servicio de Usuario de Acceso Telefónico de Autenticación Remota
Remote Authentication Dial-In User Service
RERR Error de Ruta
Route Error
RFCOMM Protocolo de Comunicaciones de Radiofrecuencia
Radio Frequency Communications Protocol
RREP Respuesta de Ruta
Route Reply
RREQ Petición de Ruta
Route Request
RTCP Red Telefónica Pública Conmutada
S
SAODV AODV Seguro
Secure AODV
SEAD Vector de Distancia Ad hoc Eficiente y Seguro
Secure Efficient Ad hoc Distance vector
SIG Grupo de Interés Especial
Special Interest Group
SIM Módulo de Identidad del Subscriptor
Subscriber Identity Module
SRES Señal de Respuesta
Signal Response
84
T
Tcl Herramientas del Lenguaje de Comandos
Tool Command Language
TKIP Protocolo de Integridad con Llave Temporal
Temporal Key Integrity Protocol
TORA Algoritmo de Enrutamiento Ordenado Temporalmente
Temporary Ordered Routing Algorithm
U
UMTS Sistema de Telecomunicaciones Móviles Universales
Universal Mobile Telecommunications System
USC/ISI Universidad del Sur de California/Instituto de Ciencias de la Información
University of Southern California/Information Sciences Institute
UWB Ultra Banda Ancha
Ultra Wideband
V
VINT Pruebas de Interred Virtual
Virtual InterNetwork Testbed
VLR Registro de Localización de Visitantes
Visitor Location Register
W
WAN Red de Área Amplia
Wide Area Network
Wi-Fi Fidelidad Inalámbrica
Wireless Fidelity
WiMAX Interoperabilidad Mundial para Acceso por Microondas
Worldwide Interoperability for Microwave Access
WLAN Red de Área Local Inalámbrica
Wireless Local Area Network
WEP Privacidad Equivalente Alámbrica (Protocolo de Cifrado Inalámbrico)
Wired Equivalency Privacy
WPA Wi-Fi con Acceso Protegido
Wi-Fi Protected Access
85
86
Referencias
[1] 3Com, Corporación de redes con información relacionada a las redes WLAN,
“Despliegue de LANs inalámbricas 802.11”, [en línea], [fecha de consulta: 26 de
Agosto de 2003]. Disponible en: http://www.3com.es
[2] Oliva, Pau, “(In)seguridad en redes 802.11b”, [en línea], [fecha de consulta: 4 de
Septiembre de 2003]. Disponible en: http://www.eslack.org/pof/
[3] Nichols, Randall K., et al., “Seguridad para comunicaciones inalámbricas”, McGraw
Hill, 2003.
[4] Borisov, Nikita, et al., “Intercepting Mobile Communications: The Insecurity of

802.11”, publicado en la 7th Annual International Conference on Mobile Computing
And Networking (ACM MobiCom’01), Julio de 2001.
[5] Arbaugh, William A., et al., “Your 802.11 wireless network has no clothes”, IEEE
Wireless Communications Magazine, vol. 9, no. 6, December 2002, pp. 44 – 51.
[6] Alarcón, José M., “Seguridad inalámbrica avanzada 3”, WindowsTI Magazine
Edición Noviembre 2003 no. 81, octavo año, [en línea], [fecha de consulta: 3 de
Diciembre de 2003]. Disponible en: http://www.windowstimag.com
[7] Intel Corporation, información de productos Intel “Wireless Security - 802.1x and
EAP Types”, [en línea], [fecha de consulta: 4 de Diciembre de 2003]. Disponible en:
http://support.intel.com/support/wireless/wlan/sb/CS-008413.htm
[8] García, Francisco, “WPA, seguridad en redes inalámbricas”, Revista Antena número
154-Diciembre de 2003 del Colegio-Asociación de Ingenieros Técnicos de
Telecomunicación, [en línea], [fecha de consulta: 12 de Noviembre de 2004].
Disponible en: http://www.coitt.es/
[9] Wi-Fi Alliance, información relacionada al proceso de certificación de productos

WLAN, “Wi-Fi Protected Access 2”, [en línea], [fecha de consulta: 7 de Noviembre
de 2004]. Disponible en: http://www.wi-fi.org
87
[10] Träskbäck, Marjaana, “Security of Bluetooth: An overview of Bluetooth Security”,
Artículo publicado por Helsinki University of Technology, [en línea], [fecha de
consulta: 8 de Noviembre de 2003]. Disponible en: http://www.cs.hut.fi/Opinnot/Tik-
86.174/
[11] Vainio, Juha T., “Bluetooth Security”, Artículo publicado por Helsinki University of
Technology, [en línea], [fecha de consulta: 11 de Noviembre de 2003]. Disponible en:
http://www.niksula.cs.hut.fi/~jiitv/bluesec.html
[12] Pesonen, Lauri, “GSM Interception”, Artículo publicado por Helsinki University of
Technology, [en línea], [fecha de consulta: 1 de Octubre de 2003]. Disponible en:
http://www.dia.unisa.it/professori/ads/corso-security/www/CORSO-9900/a5/Netsec/netsec.html
[13] Barkan, Elad, et al., “Instant Ciphertext-Only Cryptanalysis of GSM Encrypted

Communication”, Artículo publicado por el Instituto de Tecnología de Haifa en Israel,
[en línea], [fecha de consulta: 21 de Mayo de 2004]. Disponible en: http://www.gsm-
security.net/gsm-security-papers.shtml
[14] Quirke, Jeremy, “Security in the GSM System”, Artículo publicado en AusMobile,
portal dedicado a reportar información de redes móviles, [en línea], [fecha de
consulta: 21 de Septiembre de 2004]. Disponible en: http://www.ausmobile.com/
[15] WiMAX Forum, información relacionada al desarrollo y certificación de productos

inalámbricos de banda ancha, “Redes metropolitanas inalámbricas de banda ancha”,
[en línea], [fecha de consulta: 24 de Noviembre de 2004]. Disponible en:
http://www.wimaxforum.org/
[16] Huidobro, José Manuel, “WiMAX. Un estándar emergente”, Revista Antena número
157-Septiembre de 2004 del Colegio-Asociación de Ingenieros Técnicos de
Telecomunicación, [en línea], [fecha de consulta: 12 de Noviembre de 2004].
Disponible en: http://www.coitt.es/
[17] UWB Forum, información relacionada al proceso de certificación de productos UWB,

“Ultra-Wideband”, [en línea], [fecha de consulta: 6 de Octubre de 2004]. Disponible
en: http://www.uwbforum.org/
88
[18] Millán, Ramón, “UWB (Ultra Wide-Band)”, [en línea], [fecha de consulta: 6 de
Octubre de 2004]. Disponible en: http://www.coit.es/publicaciones/bit/bit147/quees.pdf
[19] Zaleta Alejandre, Efraín, “Esquema Eficiente de Administración de la Calidad de

Servicio para el Sistema de Telecomunicaciones Móviles Universales”, Tesis de
Maestría, CENIDET, 2004.
[20] Balderas, Tomás, et al., "Security Architecture in UMTS Third Generation Cellular
Networks", Reporte Técnico CCC-04-002, Coordinación de Ciencias de la
Computación, INAOE, Tonantzintla, Puebla. México, 2004.
[21] Internet Engineering Task Force, información relacionada a la estandarización de los

protocolos de enrutamiento en MANET, “MANET WG Charter”, [en línea], [fecha de
consulta: 16 de Febrero de 2004]. Disponible en:
http://www.ietf.org/html.charters/manet-charter.html
[22] Perkins, Charles E., et al., “Ad hoc On-Demand Distance Vector (AODV) Routing”,
Request For Comments (RFC) 3561, July 2003, [en línea], [fecha de consulta: 20 de
Febrero de 2004]. Disponible en: http://www.ietf.org/rfc/rfc3561.txt
[23] Perkins, Charles E., et al., “Ad hoc On-Demand Distance Vector Routing”, [en línea],
[fecha de consulta: 24 de Febrero de 2004]. Disponible en:
http://www.cs.brown.edu/courses/cs295-1/aodv.pdf
[24] Deng, Hongmei, et al., “Routing security in wireless ad hoc networks”, IEEE
Communications Magazine, vol. 40, no. 10, October 2002, pp. 70 – 75.
[25] Zhou, Lidong, et al., “Securing ad hoc networks”, IEEE Network, vol. 13, no. 6,
November/December 1999, pp. 24 – 30.
[26] Yan, Zheng, “Security in ad hoc networks”, [en línea], [fecha de consulta: 1 de Marzo
de 2004]. Disponible en: http://citeseer.ist.psu.edu/update/536945
[27] Wang, Weichao, et al., “On Vulnerability and Protection of Ad Hoc On-demand
Distance Vector Protocol”, publicado en la 10th International Conference on
Telecommunications (ICT'2003), Febrero de 2003.
89
[28] Hu, Yih-Chun, et al., “SEAD: secure efficient distance vector routing for mobile
wireless ad hoc networks”, [en línea], [fecha de consulta: 27 de Feberero de 2004].
Disponible en: http://www.ece.cmu.edu/~adrian/projects/secure-routing/sead-
journal.pdf
[29] Hu, Yih-Chun, et al., “Ariadne: A Secure On-demand Routing Protocol for Ad hoc
Networks”, publicado en la 8th Annual International Conference on Mobile Computing
And Networking (ACM MobiCom’02), Septiembre de 2002.
[30] Guerrero, Manel, et al., “Securing Ad Hoc Routing Protocols”, publicado en ACM
Workshop on Wireless Security (WiSe) in conjunction with ACM MobiCom’02,
Septiembre de 2002.
[31] Sanzgiri, Kimaya, et al., “A Secure Routing Protocol for Ad Hoc Networks”,
publicado en la 10th IEEE International Conference on Network Protocols (ICNP'02),
Noviembre de 2002.
[32] Mira, Emilio, “Sistemas de Detección de Intrusos”, [en línea], [fecha de consulta: 14
de Julio de 2004]. Disponible en: http://www.uv.es/~montanan/ampliacion/trabajos/
[33] Marti, Sergio, et al., “Mitigating Routing Misbehavior in Mobile Ad Hoc Networks”,
publicado en la 6th Annual International Conference on Mobile Computing And
Networking (ACM MobiCom’00), Agosto de 2000.
[34] Bhargava, Sonali, et al., “Security Enhancements in AODV protocol for Wireless Ad
hoc Networks”, publicado en IEEE Semi-annual Proceedings of Vehicular
Technology Conference (VCT’01), 2001.
[35] Chung, Jae, et al., “NS by Example”, Tutorial del simulador ns-2, [en línea], [fecha de
consulta: 22 de Abril de 2004]. Disponible en: http://nile.wpi.edu/NS/
[36] Fall, Kevin, et al., “The ns Manual (formerly ns Notes and Documentation)”, Manual
oficial del simulador ns-2, Diciembre de 2003, [en línea], [fecha de consulta: 22 de
Abril de 2004]. Disponible en: http://www.isi.edu/nsnam/ns/ns-documentation.html
90
[37] CMU Monarch group, información relacionada a las extensiones del simulador ns-2,
“Wireless and Mobility Extensions to ns-2”, [en línea], [fecha de consulta: 4 de Mayo
de 2004]. Disponible en: http://www.monarch.cs.cmu.edu/cmu-ns.html
[38] Greis, Marc, “Tutorial of the Network Simulator ns”, Tutorial del simulador ns-2, [en
línea], [fecha de consulta: 4 de Mayo de 2004]. Disponible en:
http://www.isi.edu/nsnam/ns/tutorial/
[39] Vidal, Jesús, “El Lenguaje de Programación AWK-GAWK”, Una guía de Usuario para
AWK, [en línea], [fecha de consulta: 6 de Julio de 2004]. Disponible en:
http://www.todo-linux.com/
[40] Gnuplot, página oficial del programa, “gnuplot homepage”, [en línea], [fecha de
consulta: 3 de Septiembre de 2004]. Disponible en: http://www.gnuplot.info/
[41] Ning, Peng, et al., “How to Misuse AODV: A Case Study of Insider Attacks against
Mobile Ad hoc Routing Protocols”, publicado en la 4th Annual IEEE Information
Assurance Workshop, pp. 60-67, Junio de 2003.
[42] Zhang, Yongguang, et al., “Intrusion Detection for Wireless Ad-Hoc Networks”,
publicado en la 6th Annual International Conference on Mobile Computing And
Networking (ACM MobiCom’00), Agosto de 2000.
[43] Albers, Patrick, et al., “Security in Ad Hoc Networks: a General Intrusion Detection
Architecture Enhancing Trust Based Approaches”, publicado en el 1st International
workshop on Wireless Information Systems" (WIS 2002), in the 4rth International
Conference on Enterprise Information Systems, Abril de 2002.
91
ANEXO A: Instalación del ns-2
El proceso de instalación del simulador puede ser un poco complejo la primera vez, sobre todo si
no se está familiarizado con Linux. En el manual del ns-2 no se incluye información al respecto
y la información que viene en un archivo del simulador es limitada. Por tal motivo, se presenta
este anexo como una ayuda en el proceso de instalación. El simulador puede descargarse en la
página http://www.isi.edu/nsnam/ns/ns-build.html y también se incluye en el disco
con los programas. Viene en un paquete llamado ns-allinone-2.27.tar.gz y se encuentra
empaquetado y comprimido. El paquete contiene los componentes requeridos y algunos
componentes opcionales utilizados en las simulaciones. Los componentes que trae el paquete son
los siguientes:
Tcl release 8.4.5 (componente requerido)

Tk release 8.4.5 (componente requerido)
Otcl release 1.8 (componente requerido)
TclCL release 1.15 (componente requerido)
Ns release 2.27 (componente requerido)
TclDebug release 1.9 (componente opcional)
Nam release 1.10 (componente opcional)
Xgraph version 12 (componente opcional)
Gt-itm gt-itm and sgb2ns 1.1 (componente opcional)
SGB (componente opcional)
CWeb version 3.4g (componente opcional)
Zlib version 1.1.4 (componente opcional)
Empleamos la versión 2.27 del simulador que era la más reciente al momento de realizar la tesis.
Una vez descargado el paquete en el directorio donde se quiere instalar el simulador, se teclea en
la línea de comandos la siguiente instrucción:
93
gunzip ns-allinone-2.27.tar.gz
La orden anterior descomprime el archivo y le quita la extensión .gz. Luego se teclea la siguiente
instrucción:
tar xvf ns-allinone-2.27.tar
Esta orden desempaqueta el archivo con extensión .tar en el directorio donde estemos
actualmente. Posteriormente, cambiamos de directorio con la siguiente orden:
cd ns-allinone-2.27
En el nuevo directorio hay un script llamado install el cual automáticamente configura,

compila e instala todos los componentes. El script se invoca simplemente con la siguiente orden:
./install
Con la finalidad de no cambiar de directorios para ejecutar el simulador, actualizamos las

variables del entorno de trabajo en Linux, para ello se debe modificar el archivo
.bash_profile. Linux Red hat 7.3 tiene incorporado un editor llamado kate, que empleamos
para hacer la modificación. Se agregan las siguientes instrucciones al final del archivo
.bash_profile y se guardan los cambios (se presentan los directorios que utilizamos).
export NS_HOME=/home/alonso/ns2/ns-allinone-2.27/
export PATH=$NS_HOME/tcl8.4.5/unix:$NS_HOME/tk8.4.5/unix:$NS_HOME/bin:$PATH
export LD_LIBRARY_PATH=$NS_HOME/tcl8.4.5/unix:$NS_HOME/tk8.4.5/unix:$NS_HOME/otcl-
1.8:$NS_HOME/lib:$LD_LIBRARY_PATH
export TCL_LIBRARY=$NS_HOME/tcl8.4.5/library
La primera línea representa la ruta del directorio donde se desempaquetó el paquete y sirve para
simplificar las rutas en las líneas posteriores, las cuales indican los directorios donde se instalaron
los componentes que requiere el simulador. Opcionalmente, se puede verificar si el simulador se
instaló correctamente, para ello en el directorio ~ns/ns-2.27/ se escribe la siguiente orden:
./validate
El script realiza una serie de pruebas para validar la instalación y va informando los resultados.
Este proceso tarda varios minutos y varía dependiendo de la computadora que se utilice.
94
92
ANEXO B: Implementación del agente
malicioso y del módulo de detección de ataque
En este anexo se presentan los pasos requeridos para implementar el agente malicioso y el
módulo de detección de ataque en el ns-2. Los archivos que se describen están disponibles en el
disco que se incluye con la tesis. Los pasos para la implementación se presentan con el objetivo
de que se puedan repetir las simulaciones de una forma rápida y sencilla, pues en la mayoría de
los casos no será necesario modificar archivos, sino simplemente copiarlos y pegarlos.
Implementación del agente malicioso: En el capítulo 4 se indicaron los archivos que se deben
modificar y el código que se debe agregar para implementar el nuevo agente llamado MYAODV.
En el disco se encuentran los archivos ya modificados. A continuación se presentan los pasos
para implementar el agente. Se asume que el simulador está correctamente instalado y ~ns es el
directorio donde se instaló.
1. Copiar los archivos que se encuentran en la carpeta ataque/archivos del disco en los
siguientes directorios:
a. “packet.h” → ~ns/ns-2.27/common/
b. “ns-packet.tcl → ~ns/ns-2.27/tcl/lib/
c. “ns-default.tcl → ~ns/ns-2.27/tcl/lib/
d. “ns-lib.tcl → ~ns/ns-2.27/tcl/lib/
e. “rttable.h” → ~ns/ns-2.27/routing/
f. “aodv_rtable.h” → ~ns/ns-2.27/aodv/
Al copiar los archivos anteriores en esos directorios estamos reemplazando los archivos que ahí
se encuentran con el mismo nombre, pero los nuevos archivos ya tienen los cambios necesarios
para implementar el ataque.
95
2. Agregar “aodv/myaodv.o” en el archivo makefile que se encuentra en ~ns/ns-2.27/. Se
agrega bajo el segmento “OBJ_CC” del código y después de “aodv/aodv.o”
3. Copiar los archivos que se encuentran en la carpeta ataque/agente del disco en los siguientes
directorios:
a. “myaodv.cc” → ~ns/ns-2.27/aodv/
b. “myaodv.h” → ~ns/ns-2.27/aodv/
En estos archivos se encuentra el código del agente MYAODV con el que se implementa el
ataque y es muy similar al código del protocolo AODV que se incluye en el simulador, pero con
las modificaciones necesarias para desarrollar el ataque de número de secuencia.
4. En el directorio ~ns/ns-2.27/, teclear lo siguiente:
make depend
y posteriormente:
make clean
5. En el directorio ~ns/, teclear lo siguiente:
. /install
Con este comando estamos instalando de nuevo el simulador, pero con el nuevo agente incluido.
Implementación del módulo de detección de ataque: En este caso no fue necesario agregar un
nuevo agente en el ns-2, sino que se modificó un método del protocolo AODV que viene en el
simulador ya que todos los nodos, excepto el malicioso, lo utilizan. Los pasos para instalar son:
1. Copiar los archivos que se encuentran en la carpeta módulo en los siguientes directorios:
a. “aodv.cc” → ~ns/ns-2.27/aodv/
b. “aodv.h” → ~ns/ns-2.27/aodv/
2. Se repiten los pasos 4 y 5 del proceso anterior.
96
ANEXO C: Listado de programas
En este anexo se presentan los programas en Tcl que fueron empleados para desarrollar las
simulaciones y otros aspectos relacionados a las mismas que consideramos significativos.
Primero se presenta información del generador de movimiento y de tráfico. Posteriormente se
muestran los scripts de Tcl que se utilizaron para simular en condiciones normales y bajo ataque.
Luego se presenta el programa en awk empleado para evaluar el porcentaje de paquetes
entregados. No se incluye en el anexo el código C++ del agente malicioso y del módulo de
detección de ataque incorporado en el protocolo AODV, debido a que el código del protocolo es
muy extenso, pero en el disco puede checarse este código donde se ha resaltado con comentarios
las modificaciones efectuadas. Así también se recuerda que en el capitulo 4 (ver figuras 4-2 y 4-
6) se presentaron diagramas de flujo los cuales pueden ayudar para el mejor entendimiento de las
modificaciones al protocolo AODV.
Generador de archivos de movimiento y tráfico: En el capítulo 3 se mencionó que para

simular redes MANET, debemos generar patrones de movimiento y tráfico y se indicó la forma
en que se generan. A continuación se presentan las instrucciones específicas que se utilizaron.
Para generar un archivo que contiene un patrón de movimiento, nos cambiamos al directorio
~ns/indep-utils/cmu-scen-gen/setdest. Bajo este directorio y en la línea de comandos
tecleamos lo siguiente:
./setdest -v 2 –n 20 –s 1 -m 0.5 -M 4.0 -t 1000.0 -P 1 -p 10 -x 850 -y

850 > scen-20-10-4a
La instrucción anterior crea el archivo con nombre scen-20-10-4a que describe el movimiento
de los nodos. El número 20 en el nombre del archivo representa el número de nodos, el número
10 el tiempo de pausa y el número 4 la velocidad máxima a la que se pueden desplazar los nodos.
La letra a al final del nombre indica el primer patrón de movimiento. Utilizamos esta
97
nomenclatura para tener un orden en la forma que nombramos los archivos. Los resultados de
nuestras simulaciones no se basan en un solo patrón de movimiento, sino que son el promedio de
5 diferentes escenarios. Entonces se repite la instrucción anterior 4 veces más y a los nombres de
los archivos se les coloca al final las letras b, c, d y e. Los archivos que se generan describen
diferentes movimientos de los nodos y se incluyen en el disco.
Para generar el archivo de tráfico, nos cambiamos al directorio ~ns/indep-utils/cmu-scen-

gen y tecleamos lo siguiente:
ns cbrgen.tcl -type cbr -nn nodes 19 –seed 1 –mc 4 –rate 2.0 > cbr-20-
1-4
Se crea el archivo con nombre cbr-20-1-4. El número 20 representa el número de nodos, el

número 1 la semilla aleatoria y el número 4 el número de conexiones. Para crear patrones de
tráfico con diferente número de conexiones se cambia el campo -mc por 8, 12, 16 y 19 que
indican respectivamente el número de fuentes de tráfico o conexiones.
Programa en condiciones normales: Este programa es un script en Tcl que lleva por nombre
20-4-4a-normal.tcl y es donde se configuran las diferentes opciones de simulación. El
script se escribió con el editor kate. Para simular diferentes escenarios de movimiento y
patrones de tráfico con diferente número de conexiones, solo se cambia el nombre de éstos
archivos y se emplean los requeridos. En éste caso, los archivos deben encontrarse en el mismo
directorio donde se encuentra el script de Tcl. En el disco se colocaron en carpetas los archivos
requeridos para cada escenario de simulación, de manera que solo se tenga que cambiar de
carpeta para realizar la simulación en diferentes escenarios. En la línea de comandos se escribe
ns 20-4-4a-normal.tcl y la simulación se lleva a cabo. Aquí se presenta el programa en Tcl.
# ======================================================================
# Define opciones
# ======================================================================
set val(chan) Channel/WirelessChannel # tipo de canal

set val(prop) Propagation/TwoRayGround # tipo de propagación
set val(netif) Phy/WirelessPhy # tipo de interface
set val(mac) Mac/802_11 # tipo de capa MAC
set val(ifq) Queue/DropTail/PriQueue # tipo de cola
set val(ll) LL # capa de enlace
set val(ant) Antenna/OmniAntenna # tipo de antena
98
set val(x) 850 ; # dimension X de la topografía
set val(y) 850 ; # dimensión Y de la topografía
set val(ifqlen) 50 ; # número máximo de paquetes en ifq
set val(seed) 1.0 # semilla aleatoria
set val(adhocRouting) AODV # protocolo de enrutamiento
#set val(adhocRouting2) MYAODV inhabilitado
set val(nn) 20 ; # número de nodos
set val(cp) "cbr-20-1-4" # archivo de tráfico
set val(sc) "scen-20-10-4a" # archivo de movimiento
set val(stop) 1000.0 ;# tiempo de simulación
# =====================================================================
# Programa principal
# ======================================================================
# Inicializa variables globales

# crea instancias del simulador
set ns_[new Simulator]
# configura objeto de topografía
set topo[new Topography]
# crea objeto de trazo para ns y nam
set tracefd[open 20n.tr w]

$ns_ use-newtrace
set namtrace [open 20n.nam w]
$ns_ trace-all $tracefd
$ns_ namtrace-all-wireless $namtrace $val(x) $val(y)
# define topología
$topo load_flatgrid $val(x) $val(y)
#
# Crea God
#
set god_ [create-god $val(nn)]
#Configuración global de nodos
$ns_ node-config -adhocRouting $val(adhocRouting) \

-llType $val(ll) \
-macType $val(mac) \
-ifqType $val(ifq) \
-ifqLen $val(ifqlen) \
-antType $val(ant) \
-propType $val(prop) \
-phyType $val(netif) \
-channelType $val(chan) \
-topoInstance $topo \
-agentTrace ON \
-routerTrace ON \
-macTrace OFF
99
#
# Crea el número especificado de nodos [$val(nn)] y los agrega al canal
set node_(0) [$ns_ node]

$ns_ node-config -adhocRouting $val(adhocRouting)

for {set i 2} {$i < 3 } {incr i} {
set node_($i) [$ns_ node]
$node_($i) random-motion 0;# disable random motion
}
$ns_ node-config -adhocRouting $val(adhocRouting)

for {set i 3} {$i < $val(nn) } {incr i} {
$node_($i) random-motion 0;# disable random motion
}
#
# Define el modelo de movimiento de los nodos
#
puts "Loading connection pattern..."
source $val(cp)
#
# Define el modelo de tráfico
#
puts "Loading scenario file..."
source $val(sc)
# Define posición inicial de los nodos en nam

$ns_ initial_node_pos $node_($i) 30
}
#
# Dice a los nodos cuando termina la simulación
#
$ns_ at $val(stop).0 "$node_($i) reset";
}
$ns_ at $val(stop).0002 "puts \"NS EXITING...\" ; $ns_ halt"
puts $tracefd "M 0.0 nn $val(nn) x $val(x) y $val(y) rp $val(adhocRouting)"

puts $tracefd "M 0.0 sc $val(sc) cp $val(cp) seed $val(seed)"
puts $tracefd "M 0.0 prop $val(prop) ant $val(ant)"
puts "Starting Simulation..."

$ns_ run
100
Programa bajo ataque: Este programa es casi el mismo que se emplea en condiciones normales,
pero el nodo 2 debe emplear el nuevo agente llamado MYAODV que realiza el ataque. El
nombre del script es 20-4-4a.tcl. Si se quiere correr la simulación sólo se escribe en la línea
de comandos ns 20-4-4a.tcl. Para no repetir todo el código del script, sólo se muestra los
segmentos donde cambia el código y se han resaltado las líneas para poder distinguirlas.
# ======================================================================
# Define opciones
# ======================================================================
set val(chan) Channel/WirelessChannel # tipo de canal

set val(prop) Propagation/TwoRayGround # tipo de propagación
set val(netif) Phy/WirelessPhy # tipo de interface
set val(mac) Mac/802_11 # tipo de capa MAC
set val(ifq) Queue/DropTail/PriQueue # tipo de cola
set val(ll) LL # capa de enlace
set val(ant) Antenna/OmniAntenna # tipo de antena
set val(x) 850 ; # dimension X de la topografía
set val(y) 850 ; # dimensión Y de la topografía
set val(ifqlen) 50 ; # número máximo de paquetes en ifq
set val(seed) 1.0 # semilla aleatoria
set val(adhocRouting) AODV # protocolo de enrutamiento
set val(adhocRouting2) MYAODV # El AGENTE MYAODV AHORA ESTÁ HABILITADO
set val(nn) 20 ; # número de nodos
set val(cp) "cbr-20-1-4" # archivo de tráfico
set val(sc) "scen-20-10-4a" # archivo de movimiento
set val(stop) 1000.0 ;# tiempo de simulación
En las opciones anteriores se observa que set val(adhocRouting2) se encuentra habilitado, pues a
diferencia de cuando se encuentra en condiciones normales, ahora no tiene el símbolo # al
principio de la línea, lo que significa que no es un comentario. Otra parte que se modifica es la
siguiente:
# Crea el número especificado de nodos [$val(nn)] y los agrega al canal

$ns_ node-config -adhocRouting $val(adhocRouting2)

for {set i 2} {$i < 3 } {incr i} {
En el segmento anterior, el nodo 2 se configura para utilizar el valor de adhocRouting2 que

corresponde al agente MYAODV declarado anteriormente en las opciones de simulación. La
diferencia con el código en condiciones normales, es que ahí el nodo 2 utiliza el mismo agente
que todos los demás nodos, es decir, el protocolo AODV.
101
Programa en awk que calcula el porcentaje de paquetes entregados: Con la finalidad de
presentar un ejemplo de cómo se evalúan las métricas con awk, se presenta el programa de la
métrica más importante, correspondiente al porcentaje de paquetes entregados en los destinos. El
programa se llama pdf.awk. Este programa y los otros utilizados para calcular las métricas se
encuentran en el disco y están incluidos en cada carpeta que corresponden a los escenarios de
simulación. Después de que finaliza la simulación, se genera un archivo de traza con extensión .tr
en donde se encuentra la información de los eventos ocurridos durante la misma. Como ejemplo
utilizamos el nombre de los archivos de traza que se generan en condiciones normales y llevan
por nombre 20n.tr. La sintaxis que se utiliza en la línea de comandos es la siguiente:
awk -f pdf.awk 20n.tr > nombre_de_archivo
Se genera un archivo con la información que se quiere obtener. El código del programa pdf.awk
es el siguiente:
BEGIN {
highest_packet_id = 0;
}
{
action = $1; # Se analiza el tipo de evento ocurrido
time = $3; # Registra el tiempo en que ocurrió el evento
Nl = $19; # Analiza a que nivel ocurre el evento
packet_type = $35; # Analiza el tipo de paquete
packet_id = $41; # Identificación del paquete
if ($2 == "-t") {
if (packet_id > highest_packet_id) highest_packet_id = packet_id;
if (action == "s" && Nl == "AGT" && packet_type == "cbr") {

start_time[packet_id] = time;
sends++; # Cuenta los paquetes que fueron enviados
}
if (action == "r" && Nl == "AGT" && packet_type == "cbr") {

end_time[packet_id] = time;
receives++; # Cuenta los paquetes que se entregaron en los destinos
} else {
end_time[packet_id] = -1;
}
}
}
END {
pdfraction = (receives)/(sends) * 100; # Calcula el porcentaje
printf("%f %f %f\n", sends, receives, pdfraction); # Muestra los paquetes
# envíados, recibidos y
} # el porcentaje entregado
102

168MC Javc PDF

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

168MC Javc PDF

Cargado por

Copyright:

Formatos disponibles

S.E.P. S.E.I.T. D.G.I.T.

CENTRO NACIONAL DE INVESTIGACIÓN

SEGURIDAD EN EL ENRUTAMIENTO DEL PROTOCOLO AODV

M. C. CARLOS FELIPE GARCÍA HERNÁNDEZ

CUERNAVACA, MORELOS MARZO DE 2005

Lista de figuras ......................................................................................................... v

Capítulo 1: Tecnologías inalámbricas y móviles

Capítulo 2: Redes móviles Ad hoc

Capítulo 4: Diseño e implementación de simulaciones

Lista de acrónimos .................................................................................................. 81

Tecnologías inalámbricas y móviles

1.1 Estándar IEEE 802.11x

con 802.11 y la interoperabilidad de equipos de distintos fabricantes. La norma original 802.11

Tabla 1-1 Tres normas fundamentales de 802.11.

Norma Banda de radio Modulación Cobertura máx. Velocidad máx.

1.1.3 Beacon Frames

1.1.4 Medidas de seguridad

El propósito de WEP es garantizar que los sistemas WLAN dispongan de un nivel de

Con respecto a la autentificación, WEP proporciona dos tipos de autentificación: un sistema

Figura 1-1 Cifrado WEP.

Figura 1-2 Descifrado WEP.

el AP la rechaza evitando que la estación acceda a la red. La autentificación mediante clave

Figura 1-3 Autentificación mediante clave compartida.

En el año 2001 los grupos de investigación de la Universidad de Berkeley y la Universidad de

El uso de 802.1x implica normalmente la utilización de un servidor de autentificación RADIUS

1. El cliente se asocia con un AP.

• Si no es autentificado, el cliente permanece bloqueado.

En la figura 1-4 se ilustra el proceso de autentificación.

Figura 1-4 Autentificación en WPA.

1.1.4.3 IEEE 802.11i

La principal diferencia entre WPA y WPA2 es la introducción de un mejor algoritmo de cifrado,

En 1999, el SIG publicó la versión 1.0 de la especificación Bluetooth y la última versión de la

1.2.1 Arquitectura de seguridad Bluetooth

• Modo 1. El protocolo no impone ninguna medida de seguridad.

Existen dos posibilidades en el acceso de dispositivos a diferentes servicios:

• Dispositivos de confianza. Dispositivos que han sido previamente autentificados y están

Los servicios también pueden ser catalogados en tres niveles de seguridad:

• Servicios abiertos, a los cuales puede acceder cualquier dispositivo.

Figura 1-5 Arquitectura de seguridad Bluetooth.

El administrador de seguridad almacena información relativa a la seguridad de los servicios y

1.2.3 Cifrado con el sistema de cifrado de flujo E0

• Generador de clave de carga útil. La generación de la clave de carga útil es la primera

El proceso de cifrado puede verse en la figura 1-6.

Figura 1-6 Descripción del proceso de cifrado.

1.3 Sistema Global de Comunicaciones Móviles

1.3.1 Arquitectura de red GSM

Figura 1-7 Arquitectura de una red GSM.

A3 El algoritmo de autentificación usado en GSM.

A5 El algoritmo de cifrado utilizado en el sistema GSM. Hay varias implementaciones

A8 El algoritmo de generación de clave usado en GSM.

BTS Estación base; se comunica con la estación móvil.

Ki Es la llave secreta compartida entre el SIM y el HLR.

IMEI Identificación de equipo móvil internacional.

MS Estación móvil o teléfono móvil.

MSC Centro de conmutación de servicio móvil; es el componente central del NSS y se

NSS Subsistema de conmutación y red; este sistema se encarga de administrar las

RTCP Red telefónica conmutada pública.

1.3.2 Modelo de seguridad GSM

(identificación de equipo móvil internacional) está autorizada en el EIR (registro de identidad de

Figura 1-8 Autentificación de la estación móvil.

El algoritmo A3 es el algoritmo de autentificación. Su función es generar la respuesta SRES al

Figura 1-9 Algoritmos y llaves utilizados en GSM.

1.4.1 IEEE 802.16