Memoria del proyecto - Departamento de Teoría de la Señal

ESCUELA TÉCNICA SUPERIOR DE INGENIERÍAS
INFORMÁTICA Y DE TELECOMUNICACIÓN
Departamento de Teorı́a de la Señal,
Telemática y Comunicaciones
PROYECTO FIN DE CARRERA
Simulación en OPNET de ataques
a la seguridad 802.11 mediante
técnicas de jamming
Marı́a del Carmen Pastor Morales
Director: Gabriel Maciá Fernández
Granada, 8 de julio de 2009
Simulación en OPNET de ataques
a la seguridad 802.11 mediante
técnicas de jamming
Marı́a del Carmen Pastor Morales
PALABRAS CLAVE: IEEE 802.11, comportamiento egoı́sta, capa MAC, CSMA/CA,
jamming, OPNET Modeler.
Resumen
El presente proyecto estudia el comportamiento egoı́sta en la capa MAC para redes con tecnologı́a IEEE 802.11.
El comportamiento egoı́sta consiste en que una estación realice deliberadamente
un uso incorrecto del protocolo CSMA/CA para ganar ancho de banda a expensas del
resto de estaciones. Para ello una alternativa es que la estación egoı́sta provoque colisiones que hagan que se pierdan las tramas legı́timas de las demás, llevando a cabo el
proceso conocido como jamming.
En este proyecto se estudia el comportamiento egoı́sta en la capa MAC realizando
una implementación de ataques mediante técnicas de jamming. Dicha implementación se efectúa sobre la herramienta software de simulación de redes OPNET Modeler. Además se desarrolla una utilidad de registro de mensajes que almacena tanto
información del comportamiento del protocolo CSMA/CA de la capa MAC, como del
proceso de jamming.
Por último, para comprobar la efectividad y analizar los detalles del funcionamiento de los ataques implementados, se realiza una baterı́a de simulaciones sobre OPNET
Modeler. A partir de estas simulaciones se obtienen resultados que permiten estudiar
las consecuencias de los ataques y sacar conclusiones.
Simulation in OPNET of 802.11 security
attacks with jamming techniques
Marı́a del Carmen Pastor Morales
KEYWORDS: IEEE 802.11, selfish behaviour, MAC layer, CSMA/CA, jamming, OPNET Modeler.
Abstract
This thesis is focused on the study of the selfish behaviour in IEEE 802.11 networks
at the MAC layer.
The selfish behaviour is that performed by a network station which deliberately
misuse the specifications of the CSMA/CA protocol. The purpose of the selfish station is either to gain throughput at the expense of other stations, or to deny the service
of certain network participants. In order to do this, one strategy consists in the selfish
node causing colisions and loss of other station’s legal frames. This process is known
as jamming.
This thesis evaluates selfish behaviour at MAC layer by using jamming techniques.
The implementation of these attacks is done within OPNET Modeler network simulator. Additionaly, a log tool has been developed for recording CSMA/CA protocol
behaviour and jamming process information.
Finally, in order to evaluate the performance and functioning of the implemented
attacks, a simulations set is performed within OPNET Modeler. With these simulations
we obtain results to study attacks consequences and to draw conclusions.
Yo, Marı́a del Carmen Pastor Morales, alumna de la titulación Ingenierı́a Informática de la Escuela Técnica Superior de Ingenierı́as Informática y de Telecomunicación de la Universidad de Granada, con DNI 45737691Y, autorizo la ubicación
de la siguiente copia de mi Proyecto Fin de Carrera en la biblioteca del centro,
para que pueda ser consultada por las personas que lo deseen.
Fdo: Marı́a del Carmen Pastor Morales
Granada, 8 de julio de 2009
D. Gabriel Maciá Fernández , Profesor del Departamento de Teorı́a de la
Señal, Telemática y Comunicaciones de la Escuela Técnica Superior de Ingenierı́as
Informática y de Telecomunicación de la Universidad de Granada, como director
del Proyecto Fin de Carrera de Marı́a del Carmen Pastor Morales
INFORMO:
que el presente proyecto titulado “Simulación en OPNET de ataques a la seguridad 802.11 mediante técnicas de jamming” ha sido realizado por la mencionada alumna bajo mi supervisión, y que autorizo la defensa de dicho proyecto
ante el tribunal que corresponda.
Y para que ası́ conste, expido y firmo el presente informe en Granada a 8
de julio de 2009.
Fdo: D. Gabriel Maciá Fernández
Agradecimientos
En primer lugar agradecer a mi madre y a mis hermanos, en especial a Juan,
el apoyo que durante todos mis estudios en Córdoba y Granada he recibido de
ellos.
Dar gracias también a todos mis amigos, sobretodo a Javi por su apoyo,
cariño y por la ayuda incondicional que me ha prestado durante todos estos
años. También a mi compañero y amigo Eusebio por soportarme y por los momentos de estrés que hemos superado juntos, y a mis “amigos de Granada”
Maite, Jose, Luismi y Fernando por los buenos ratos que me han hecho pasar
en esta ciudad.
Por último, dar gracias a mi director Gabriel Maciá por el interés, animo y
apoyo que me ha dedicado durante el desarrollo de este proyecto.
Sinceramente, gracias.
ÍNDICE GENERAL
1. Introducción
1.1. Presentación . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2. Descripción del problema . . . . . . . . . . . . . . . . . . . .
1.2.1. Estándares de comunicación en redes . . . . . . . . .
1.2.2. La arquitectura 802.11 . . . . . . . . . . . . . . . . . .
1.2.3. Subcapa MAC . . . . . . . . . . . . . . . . . . . . . . .
1.2.4. Comportamiento egoı́sta en el protocolo CSMA/CA
1.3. Objetivos del proyecto . . . . . . . . . . . . . . . . . . . . . .
1.4. Antecedentes y estado del arte . . . . . . . . . . . . . . . . .
1.4.1. Antecedentes en estudio de comportamiento egoı́sta
1.4.2. Estado del arte en simuladores de redes . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
1
1
2
2
3
5
10
13
14
14
15
2. Especificación de requisitos
19
2.1. Requisitos funcionales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.2. Requisitos no funcionales . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3. Recursos y planificación
3.1. Recursos . . . . . . . . . .
3.1.1. Recursos humanos
3.1.2. Recursos software
3.1.3. Recursos hardware
3.2. Planificación . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
4. Análisis de la arquitectura del simulador
4.1. Modelo de nodo . . . . . . . . . . . . . . .
4.2. Modelo de proceso . . . . . . . . . . . . .
4.2.1. Rutinas del modelo de proceso . .
4.2.2. Estados y transiciones del modelo
I
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
21
21
21
21
22
22
.
.
.
.
25
25
27
27
28
5. Diseño de la solución
5.1. Diseño de los ataques . . .
5.1.1. Tipos de jamming .
5.1.2. Modos de jamming
5.2. Diseño del log . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
33
33
33
35
36
6. Implementación
39
6.1. Técnicas de jamming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
6.2. Log de registro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
7. Evaluación de los ataques
7.1. Configuración de los escenarios . . . . . . . . .
7.1.1. Escenarios y roles de los nodos . . . . .
7.1.2. Atributos de los nodos . . . . . . . . . .
7.1.3. Perfiles de tráfico . . . . . . . . . . . . .
7.2. Estrategia de evaluación . . . . . . . . . . . . .
7.2.1. Medidas estadı́sticas . . . . . . . . . . .
7.2.2. Descripción de la estrategia . . . . . . .
7.3. Resultados de la evaluación . . . . . . . . . . .
7.3.1. Técnicas de jamming en modo continuo
7.3.2. Técnicas de jamming en modo normal .
7.3.3. Técnicas de jamming en modo aleatorio
7.4. Resumen de resultados . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
61
61
61
63
68
69
69
71
72
72
76
83
85
8. Conclusiones
87
Bibliografı́a
89
A. Guı́a breve de OPNET Modeler
91
A.1. Caracterı́sticas generales . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
A.2. Arquitectura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
A.3. Presentación de resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
II
ÍNDICE DE FIGURAS
1.1. Familia de estándares IEEE 802 . . . . . . . . . . . . . . . . . . . . . . .
1.2. Componentes 802.11. Esquema de dos IBSS . . . . . . . . . . . . . . . .
1.3. Componentes 802.11. Esquema de un ESS . . . . . . . . . . . . . . . . .
1.4. Funciones de coordinación para el acceso al medio en la subcapa MAC
1.5. Crecimiento de la ventana de contención . . . . . . . . . . . . . . . . .
1.6. Procedimiento de backoff . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.7. Comunicación mediante mecanismo RTS/CTS y NAV . . . . . . . . . .
1.8. Jamming a tramas CTS . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.9. Jamming a tramas de datos . . . . . . . . . . . . . . . . . . . . . . . . . .
1.10. Jamming a tramas ACK . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. 3
. 4
. 4
. 5
. 7
. 8
. 9
. 11
. 12
. 13
3.1. Planificación del proyecto: tareas . . . . . . . . . . . . . . . . . . . . . . . 23
3.2. Planificación del proyecto: diagrama de Gantt . . . . . . . . . . . . . . . 24
4.1. Modelo de nodo wlan station . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.2. Modelo de proceso de la capa MAC . . . . . . . . . . . . . . . . . . . . . 31
6.1. Interfaz de un nodo: parámetros de jamming . . . . . . . . . . . . . . . . 41
6.2. Interfaz de un nodo: parámetros de log . . . . . . . . . . . . . . . . . . . . 45
Escenario de jamming . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Escenario normal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Cálculo del retardo de acceso al medio . . . . . . . . . . . . . . . . . . .
Tasa de envı́o de datos de nodo tr para los distintos tipos de jamming
en modo continuo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.5. Tasa de recepción de datos en nodo rc para jamming a datos en modo
continuo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.6. Tasa de envı́o y de descarte de datos por exceder el lı́mite de retransmisiones para el nodo tr con jamming continuo a tramas ACK . . . . . .
7.1.
7.2.
7.3.
7.4.
III
. 62
. 62
. 70
. 73
. 74
. 75
7.7. Tasa de envı́o de datos del nodo jammer con tráfico de saturación para
los distintos tipos de jamming en modo normal . . . . . . . . . . . . . . . 77
7.8. Tamaño de la cola de transmisión del nodo jammer con tráfico de saturación para los distintos tipos de jamming en modo normal . . . . . . . . 78
7.9. Retardo de acceso al medio del nodo jammer con tráfico de saturación
para los distintos tipos de jamming en modo normal . . . . . . . . . . . . 79
7.10. Tasa de envı́o de datos de los nodos jammer, nodo tr y normal tr
con jamming a CTS en modo normal y perfil de tráfico a tasa media . . . 80
7.11. Tamaño de la cola de transmisión de nodos jammer, nodo tr y normal tr
con jamming a CTS en modo normal y perfil de tráfico de tasa media . . 81
7.12. Retardo de acceso al medio de los nodos jammer, nodo tr y normal tr
con jamming a CTS en modo normal y perfil de tráfico a tasa media . . . 82
7.13. Tasa de envı́o de datos del nodo jammer para distintos valores de jamming a CTS en modo aleatorio . . . . . . . . . . . . . . . . . . . . . . . . . 83
7.14. Retardo de acceso al medio del nodo jammer para distintos valores de
jamming a CTS en modo aleatorio . . . . . . . . . . . . . . . . . . . . . . . 84
A.1. Arquitectura de OPNET Modeler . . . . . . . . . . . . . . . . . . . . . . . 92
A.2. Tipos de estados del modelo de proceso . . . . . . . . . . . . . . . . . . . 93
A.3. Flujo de ejecución de un estado no forzado . . . . . . . . . . . . . . . . . 94
IV
ÍNDICE DE TABLAS
7.1.
7.2.
7.3.
7.4.
7.5.
7.6.
Atributos del nodo: parámetros generales . . . . . . . . . . . . . . . . . . 63
Atributos del nodo: parámetros de jamming . . . . . . . . . . . . . . . . . 64
Atributos del nodo: parámetros de log . . . . . . . . . . . . . . . . . . . . 65
Atributos del nodo: parámetros de generación de tráfico . . . . . . . . . 66
Atributos del nodo: parámetros WLAN . . . . . . . . . . . . . . . . . . . 68
Número de paquetes creados por el nodo nodo tr con jamming en modo continuo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
7.7. Número de paquetes destruidos por el nodo nodo tr con jamming en
modo continuo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
7.8. Número de paquetes creados por el nodo jammer con tráfico de saturación para los distintos tipos de jamming en modo normal . . . . . . . . 77
7.9. Número de paquetes creados por los nodos jammer, nodo tr y normal tr
con tráfico de tasa media y jamming a CTS en modo normal . . . . . . . . 81
7.10. Número de paquetes creados por el nodo nodo tr para distintos valores de jamming a CTS en modo aleatorio . . . . . . . . . . . . . . . . . . . 85
V
VI
LISTADOS DE CÓDIGO
6.1. Declaración de flags de jamming . . . . . . . . . . . . . . . . . . . . .
6.2. Declaración de variables de estado para jamming . . . . . . . . . . .
6.3. Inicialización de variables de estado para jamming . . . . . . . . . .
6.4. Inicialización de flags de jamming . . . . . . . . . . . . . . . . . . . .
6.5. Activación del jamming a CTS . . . . . . . . . . . . . . . . . . . . . .
6.6. Activación del jamming a datos . . . . . . . . . . . . . . . . . . . . .
6.7. Activación del jamming a ACK . . . . . . . . . . . . . . . . . . . . .
6.8. Función de jamming aleatorio . . . . . . . . . . . . . . . . . . . . . .
6.9. Finalización del jamming . . . . . . . . . . . . . . . . . . . . . . . . .
6.10. Reinicio de los flags de jamming . . . . . . . . . . . . . . . . . . . . .
6.11. Declaración de variables de estado del log . . . . . . . . . . . . . . .
6.12. Inicialización de variables de estado para el log . . . . . . . . . . . .
6.13. Función de registro de información de jamming en el log . . . . . . .
6.14. Función de registro de mensajes de información general en el log .
6.15. Llamada a función de registro de mensajes de información general
6.16. Función de registro de nombre de estados en el log . . . . . . . . . .
6.17. Ejemplo de fragmento del log . . . . . . . . . . . . . . . . . . . . . .
VII
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
40
40
41
41
42
43
43
43
44
44
45
46
46
47
49
49
50
VIII
CAPÍTULO
1
INTRODUCCIÓN
1.1.
Presentación
El mercado de las redes inalámbricas se ha ido ampliando en los últimos años y
está extendiéndose dentro de todos los ámbitos de las redes tradicionales. Cada vez
son más las empresas, instituciones públicas y hogares que optan por este sistema en
alternativa a las soluciones habituales que utilizan cableado.
Las redes inalámbricas poseen ventajas importantes, siendo las más obvias movilidad y flexibilidad, ya que los usuarios pueden conectarse a las redes disponibles
y desplazarse libremente mientras permanezcan dentro del área de cobertura de las
mismas. Además se eliminan las acciones de instalación de cables y tomas de red utilizadas en las redes cableadas, lo que supone un ahorro de tiempo y dinero.
La ventaja de no necesitar un medio fı́sico para funcionar se convierte también en
un inconveniente. Las redes inalámbricas deben validar cuidadosamente las unidades
de información recibidas para prevenir las pérdidas provocadas por la falta de fiabilidad del canal de comunicación. Además teniendo en cuenta que las transmisiones
están a disposición de cualquiera dentro del alcance de la red, la seguridad se vuelve
un asunto más que importante.
El presente proyecto fin de carrera se centrará en el estudio de la seguridad de
las redes inalámbricas a partir de su vulnerabilidad frente a ataques producidos sobre
la capa MAC. Dichos ataques serán realizados mediante envı́os malintencionados de
tramas que producirán interferencias en las comunicaciones entre las estaciones.
Los resultados del estudio teórico se implementarán con la herramienta de simulación gráfica de sistemas de comunicaciones OPNET Modeler 1 y posteriormente se
1
http://www.opnet.com/
1
1. Introducción
analizarán los resultados de la experimentación para obtener conclusiones.
1.2.
Descripción del problema
Con el fin de delimitar el ámbito del problema se va realizar una explicación teórica de las tecnologı́as empleadas en este proyecto. Para mayor claridad se seguirá un
enfoque de mayor a menor nivel de abstracción.
En primer lugar se hará una introducción a los estándares de comunicación en
redes con el objetivo de enmarcar el estándar 802.11, donde se detallan las especificaciones de las redes inalámbricas de área local. Seguidamente se profundizará en el
estudio del estándar explicando los detalles técnicos del protocolo CSMA/CA, necesarios la para comprensión del desarrollo del ataque. Por último se hablará acerca
de qué se considera comportamiento egoı́sta en dicho protocolo, y cómo se realizan
ataques al mismo mediante técnicas de jamming.
Si el lector está familiarizado con los detalles del funcionamiento del estándar
802.11 puede pasar a la Sección 1.2.4.
1.2.1.
Estándares de comunicación en redes
El Instituto de Ingenieros en Electricidad y Electrónica (Institute of Electrical and
Electronics Engineers, IEEE) 2 creó una serie de comités, en los que participa personal
de la industria informática y del ámbito académico, que establecieron un conjunto
de estándares para protocolos de comunicaciones en redes. Estos estándares fueron
ampliamente aceptados por la comunidad y por ello los fabricantes desarrollaron sus
equipos de acuerdo con las especificaciones definidas en ellos.
Uno de los estándares sobre redes de área local y metropolitana realizado por esta
organización fue la serie de normas 802 [1] que realizan una especificación detallada
de las capas más bajas del modelo de referencia de interconexión de sistemas abiertos
(Open Systems Interconection, OSI) de la Organización Internacional de Estándares (International Organization for Standardization, ISO)3 . El modelo OSI define siete capas, de
las cuales las normas 802 se centran en dos, la capa fı́sica y la capa de enlace de datos.
Dentro del la serie 802, tal y como se muestra en la Figura 1.1, destacan varias
especificaciones individuales que se identifican mediante uno o dos dı́gitos, algunas
de las más conocidas son la 802.3 que define la técnica de acceso múltiple por detección
de portadora con detección de colisiones (Carrier Sense Multiple Access network with
Collision Detection, CSMA/CD) usada en redes Ethernet, la 802.15 correspondiente a
las redes inalámbricas de área personal (Wireless Personal Area Networks, WPANs) o
la 802.11 que define la normativa para redes inalámbricas de área local (Wireless Local
2
3
2
http://www.ieee.org
http://www.iso.org
1.2. Descripción del problema
Figura 1.1: Familia de estándares IEEE 802
Area Networks, WLANs). El ámbito de estudio de este proyecto se centra en esta última
tecnologı́a.
1.2.2.
La arquitectura 802.11
Una red de área local (Local Area Network, LAN) es una red que cubre un área
geográfica pequeña (por ejemplo un edificio), cuya principal función es conectar ordenadores para compartir recursos e intercambiar información. Este tipo de redes tienen
tres caracterı́sticas que las diferencian del resto que son tamaño, topologı́a y tecnologı́a de transmisión. Esta última caracterı́stica, concretamente el cambio del cable por
el medio aéreo, es lo que conduce a la idea básica de las redes inalámbricas de área
local(Wireless Local Area Networks, WLANs).
La arquitectura 802.11 consta de varios componentes que interactúan para proporcionar a las estaciones de una WLAN transparencia para las capas superiores. Uno de
esos componentes es el conjunto básico de servicios (Basic Service Set, BSS) que es el
bloque básico de construcción de una WLAN y permite que un grupo de estaciones se
comuniquen. Estas comunicaciones inalámbricas están acotadas por las caracterı́sticas
de propagación del medio inalámbrico, por lo que se define además un área conceptual denominada área básica de servicio (Basic Service Area, BSA), donde los miembros
de un BSS pueden comunicarse entre ellos. El BSS mı́nimo que se puede construir
necesita al menos dos estaciones.
Cuando las estaciones se comunican directamente dentro de un único BSS, se constituye un BSS independiente (Independent Basic Service Set, IBSS). En ocasiones los IBSS
también se denominan redes ad-hoc cuando se montan espontáneamente con la idea
de mantener un sistema de comunicación sencillo entre varias estaciones durante un
periodo de tiempo corto (Figura 1.2).
3
1. Introducción
Figura 1.2: Componentes 802.11. Esquema de dos IBSS
Además de la configuración anterior un BSS puede formar parte de estructuras
más complejas junto a otros BSS, por lo que se necesita que haya comunicación entre
ellos. El sistema de distribución (Distribution System, DS) es el componente lógico del
estándar 802.11 usado para establecer dicha comunicación y lograr que las tramas
lleguen de un BSS a su destino en un BSS diferente. La red formada por distintos BSS
junto con el DS se denomina conjunto extendido de servicios (Extended Service Set,
ESS).
Un punto de acceso (Access Point, AP) es una entidad que tiene la misma funcionalidad que una estación de la WLAN, pero además habilita el acceso de las estaciones
autorizadas al DS a través del medio inalámbrico. Dentro de un ESS todas las comunicaciones pasan obligatoriamente por el AP, incluso si éstas involucran dos estaciones
que pertenecen a un mismo BSS. En la Figura 1.3 puede verse cómo se relacionan los
componentes 802.11 comentados.
Figura 1.3: Componentes 802.11. Esquema de un ESS
4
1.2. Descripción del problema
1.2.3.
Subcapa MAC
Como se comentó anteriormente, la serie IEEE 802 abarca la capa fı́sica y la capa
de enlace de datos del modelo OSI. La capa de enlace de datos (Data Link Layer, DLL)
recibe peticiones del nivel de red y utiliza los servicios del nivel fı́sico. El objetivo
del nivel de enlace es conseguir que la información fluya, libre de errores, entre dos
máquinas conectadas. Para lograr este objetivo tiene que formar bloques de información, dotarles de una dirección de nivel de enlace, gestionar la detección o corrección
de errores, y ocuparse del control de flujo entre equipos.
Cuando el medio de comunicación está compartido entre más de dos equipos es
necesario arbitrar el uso del mismo. Esta tarea se realiza en la subcapa de control de
acceso al medio (Medium Access Control, MAC). Sobre ésta se encuentra la subcapa de
control de enlace lógico (Logical Link Control, LLC) que maneja el control de errores,
control del flujo, entramado y direccionamiento de la subcapa MAC.
Dentro del grupo de normas IEEE 802, la subcapa de enlace lógico se recoge en la
norma IEEE 802.2 y es común para todos los demás tipos de redes (Ethernet, WPAN,
WLAN, etc.)
Dado que este proyecto se centrará en la capa MAC, en este apartado se explicará la
arquitectura de dicha capa definida por el estándar IEEE 802.11.
Según [2], la subcapa MAC incluye la función de coordinación puntual (Point Coordination Function, PCF) y la función de coordinación distribuida (Distributed Coordination Function, DCF), que son las técnicas en base a las cuales las estaciones acceden al
medio (ver Figura 1.4).
Ambas funciones de acceso al canal coexisten alternativamente utilizando diferentes intervalos de tiempo. Mientras que el periodo de contención (Contention Period,
CP) es utilizado por la función DCF, la función PCF utiliza el periodo libre de contención (Contention-free Period, CFP). Éste último se iniciará cuando la estación que actúa
como coordinadora mande una trama de administración denominada baliza o beacon
anunciando el comienzo y la máxima duración del CFP.
Figura 1.4: Funciones de coordinación para el acceso al medio en la subcapa MAC
5
1. Introducción
La función PCF es un método opcional de acceso centralizado que requiere la presencia de un AP que actúe como nodo coordinador (Point Coordinator, PC) y en consecuencia tan sólo puede ser utilizada en redes con infraestructura. Según [3] en la
práctica rara vez se utiliza esta función, por lo que tampoco se usará en este proyecto.
1.2.3.1.
Función de coordinación distribuida (DCF)
La función de coordinación distribuida es la función básica de la subcapa MAC y
debe ser implementada en todas las estaciones de la red de forma obligatoria. Especifica un mecanismo llamado protocolo de acceso múltiple con detección de portadora
y prevención de colisiones (Carrier Sense Multiple Access/ Collision Avoidance, CSMA/CA), que tiene como fin reducir la probabilidad de colisiones cuando varias estaciones
quieren acceder al medio para transmitir.
Antes de transmitir, una estación debe sondear el medio para saber si ya hay otra
transmisión en curso. Si el medio no está ocupado puede efectuarse la transferencia
pero antes el canal debe mantenerse inactivo durante un tiempo denominado espacio
entre tramas distribuido (Distributed Interframe Space, DIFS) o durante un tiempo espacio entre tramas extendido (Extended Interframe Space, EIFS) si la recepción de la trama
anterior fue errónea.
Existe la posibilidad de que más de una estación detecte el canal ocupado y retarde
su acceso, por lo que terminada la transmisión todas estas estaciones detectarán libre
el canal y transmitirán en el mismo instante produciendo colisiones. Para reducir esta
probabilidad, después de esperar el tiempo DIFS y antes de comenzar a transmitir, se
realiza un procedimiento de contienda por el que cada estación esperará un intervalo
de backoff. Este mecanismo es denominado retroceso exponencial (exponential backoff ) o
retroceso exponencial binario (binary exponential backoff )[4] y dicta que el intervalo de
backoff tendrá como valor un número aleatorio que, como se explicará más adelante,
se calcula dentro de unos márgenes que tendrán como lı́mite superior la ventana de
contención. Ası́ mismo el tiempo de backoff será múltiplo del tiempo que dura una
ranura de tiempo (slot time) definida en [2].
El contador de backoff irá disminuyendo por cada ranura de tiempo que el canal
permanezca inactivo. Si se detecta actividad en alguna de las ranuras de tiempo durante el transcurso de la cuenta atrás, ésta se suspenderá y tan sólo se reiniciará si el
canal se encuentra libre de nuevo durante un periodo DIFS. Cuando el contador de
backoff alcanza el valor cero la estación puede comenzar la transmisión de la trama.
Cada estación mantiene además una ventana de contención (Contention Window,
CW), la cual es usada para determinar el número máximo de ranuras que debe esperar
una estación antes de retransmitir una trama. Esta ventana depende de la historia de
las retransmisiones de la trama actual. Por cada transmisión exitosa se recibirá la trama
ACK (acknowledgment) correspondiente, indicando que el envı́o ha llegado correcto a
su destino, pero si falla (no se recibe el ACK), la ventana de contención aumentará.
6
1.2. Descripción del problema
Figura 1.5: Crecimiento de la ventana de contención
Como se muestra en la figura 1.5 en el primer intento de transmisión la ventana de
contención se sitúa en un valor aleatorio entre 0 y CWmin 4 . En caso de que el proceso
no tenga éxito y no se reciba la trama ACK correspondiente, la CW aumentará al doble
hasta que se alcance el valor máximo que será igual a CWmax. En caso de que la
transmisión de la trama sea correcta se volverá al un valor de CW entre 0 y CWmin.
Como se comentó anteriormente la CW será usada para calcular el tiempo de backoff. El cálculo se realiza de la forma siguiente:
Tiempo de Backoff = Random() x slot time
(1.1)
donde Random() es un número entero pseudo-aleatorio obtenido a partir de una distribución uniforme sobre el intervalo [0, CW]. De esta forma las penalizaciones por la
no recepción de la trama esperada se reflejarán al calcular el tiempo de backoff.
El proceso de backoff descrito anteriormente puede verse representado en la Figura
1.6.
4
Los valores CWmin y CWmax, ventana de contención mı́nima y máxima respectivamente, son dependientes de la capa fı́sica.
7
1. Introducción
Figura 1.6: Procedimiento de backoff
Las estaciones mantienen también un contador de retransmisiones de tramas largas (normalmente tramas de datos) denominado LRC (Long Retry Count). Este contador se incrementará en cada retransmisión de la trama de datos hasta alcanzar un
lı́mite de retransmisiones máximo determinado por el atributo dot11LongRetryLimit
(que puede ser configurado en cada estación), momento en el cual se descarta la trama. Este contador se pone a cero cada vez que se reciba el ACK esperado o después
de que se descarte una trama para comenzar de nuevo el proceso.
Respecto a la forma en que una estación determina si un canal está ocupado, denominado proceso de detección de portadora (Carrier Sense, CS), el estándar WLAN
describe dos mecanismos, uno fı́sico y otro virtual. El mecanismo fı́sico forma parte
de un servicio que proporciona la capa fı́sica del modelo de red, depende del medio y
la modulación usada y viene definido en [2]. El virtual, en cambio, es proporcionado
por la subcapa MAC.
El mecanismo virtual trata de distribuir información anunciando que el medio
está ocupado mediante el intercambio de tramas de solicitud de transmisión (Request
To Send, RTS) y preparado para transmitir (Clear To Send, CTS), antes del envı́o de la
trama de datos. Las tramas RTS y CTS contienen un campo de duración que define
el periodo de tiempo reservado para transmitir la trama de datos y su correspondiente ACK. Todas las estaciones de la red son entonces conscientes de la ocupación del
canal.
Según [5] el protocolo de comunicación es el siguiente (ver Figura 1.7), la estación
origen envı́a una trama RTS a la estación destino pidiéndole permiso para enviarle
una trama de datos. Cuando el destino recibe la trama espera un tiempo denominado espacio entre tramas pequeño (Short Interframe Space, SIFS), durante el cual el
resto de estaciones actualizan sus vectores de asignación de red (Network Allocation
Vector, NAV) que contienen la información que indica el tiempo que el canal virtual
estará ocupado. Si le concede permiso, el destino responderá al origen con una trama
8
1.2. Descripción del problema
Figura 1.7: Comunicación mediante mecanismo RTS/CTS y NAV
CTS. Al recibirla, el origen enviará su trama de datos y comenzará su temporizador
de ACK. Cuando se reciba la trama correctamente en el origen se enviará el ACK, con
lo que termina el intercambio. Si el temporizador de ACK del origen termina antes de
que haya recibido el ACK todo el protocolo anterior se ejecuta de nuevo.
Desde el punto de vista de las estaciones que no participan en la comunicación, si
una estación está dentro del alcance de la estación origen recibirı́a la trama RTS, por
lo que desistirı́a en enviar datos y actualizarı́a su NAV con la información contenida
en el campo de duración de la misma. En el caso de que la estación no estuviera al
alcance del origen pero sı́ del destino, actualizarı́a su NAV a partir del CTS.
Las estaciones mantienen también un contador de retransmisiones para tramas
cortas enviadas denominado SRC Short Retry Count (normalmente aplicado a las tramas de control). Este contador irá incrementándose cada vez que se retransmita un
RTS (por no recibir el CTS correspondiente) hasta alcanzar un lı́mite determinado por
el atributo dot11ShortRetryLimit presente en cada estación, momento en el cual se descarta la trama de datos que esperaba enviarse después del intercambio RTS/CTS.
Ası́ mismo cuando se recibe el CTS esperado, o se descarte una trama, el SRC se
pondrá de nuevo a cero.
El uso del mecanismo RTS/CTS está bajo el control del atributo dot11RTSThreshold
que es propio de cada estación. Dicho atributo puede ser configurado para usar RTS/CTS siempre, nunca o sólo para tramas mayores de un tamaño especı́fico. En este
proyecto se supondrá activado intercambio RTS/CTS para todas las tramas de datos.
Según todo lo explicado anteriormente es posible que una estación se pueda apropiar del canal injustamente, lo que perjudica al resto de estaciones. Sobre esta idea
nace el concepto de comportamiento egoı́sta, que se explicará a continuación.
9
1. Introducción
1.2.4.
Comportamiento egoı́sta en el protocolo CSMA/CA
El protocolo CSMA/CA, como otros muchos protocolos, está diseñado asumiendo que los nodos cumplirán con las reglas que él establece. Esta suposición puede ser
peligrosa, ya que estarı́a en manos de las propias estaciones, por ejemplo, el aplazamiento de sus transmisiones. La tentación de alterar el comportamiento de los nodos
está más presente si con ello puede conseguirse más ancho de banda a expensas del
resto de usuarios.
Según [3] algunos de los beneficios de este mal comportamiento, o comportamiento egoı́sta, pueden ser los siguientes:
- Al tratar directamente con la capa MAC, como ya se ha comentado, el beneficio
de esta conducta se traduce en ancho de banda, lo que la hace más eficiente que
el comportamiento egoı́sta en otras capas del modelo de red.
- Su actuación no puede ser detectada en capas superiores, y además puede ser
combinada con técnicas similares en dichas capas para mejorarlo.
- Puede ser utilizado en todas las configuraciones de redes inalámbricas, ya que
todas las estaciones implementan el protocolo 802.11 de la capa MAC. Si se realizará, por ejemplo sobre TCP, las fuentes que utilizaran UDP se librarı́an del
ataque.
El reparto injusto del ancho de banda que genera este comportamiento egoı́sta
puede llegar a ocasionar serios problemas en hotspots5 públicos de acceso a Internet
(aeropuertos, bibliotecas, centros de convenciones, etc.) en los que los usuarios reclaman todo el ancho de banda posible.
1.2.4.1.
Ataques mediante técnicas de jamming
Según [6], la técnica de generar deliberadamente una señal desde un dispositivo
wireless con la intención de que interfiera en las señales legı́timas también se conoce
como jamming. En este caso el jamming proviene de una estación avariciosa denominada jammer, que envı́a tramas selectivamente a otras estaciones para que se produzcan
recepciones erróneas y ası́ las estaciones aumenten su ventana de contención.
A continuación se explicarán tres ataques enmarcados dentro de las técnicas de
comportamiento egoı́sta en [3]. Estos ataques se basan en la generación de errores en
el protocolo CSMA/CA para interferir en las comunicaciones de estaciones inalámbricas y ası́ obtener beneficios en forma de ancho de banda.
5
Un hotspot es una zona de cobertura WI-FI, en la que un punto de acceso o varios proveen servicios
de red a través de un proveedor de servicios de Internet inalámbrico
10
1.2. Descripción del problema
Jamming a tramas CTS
Una de las tramas que puede ser objeto de jamming es la trama CTS. En este caso
la estación tramposa escucha un RTS enviado por otra estación e intencionadamente
envı́a una trama para que se produzca una colisión.
El proceso serı́a el siguiente (Figura 1.8): el nodo egoı́sta espera hasta recibir un
RTS destinado a otro nodo y después de un tiempo SIFS envı́a una trama para realizar
el jamming; el nodo destino del RTS envı́a el CTS correspondiente pero éste se pierde al
colisionar con la trama enviada por el nodo egoı́sta; el nodo fuente, al no recibir el CTS
esperado, esperará un tiempo EIFS, doblará su ventana de contención y la usará para
calcular su tiempo de backoff ; a continuación comenzará a realizar el backoff. El nodo
egoı́sta al detectar el canal libre enviará un RTS para iniciar la transmisión de sus
datos, en ese momento el nodo fuente detendrá su proceso de backoff hasta que vuelva
a estar el canal ocioso por un tiempo DIFS, cuando ésto ocurra realizará de nuevo el
backoff con el tiempo restante.
A medida que se va produciendo el jamming a las tramas CTS del nodo fuente, éste
irá retransmitiendo de nuevo un RTS después de cada intervalo de backoff hasta completar el número máximo de retransmisiones que dicte el atributo dot11ShortRetryLimit
de la estación. Ası́ mismo dado que la CW doblará su capacidad por cada retransmisión, también el tiempo de backoff tenderá a aumentar (aunque puede que no siempre,
ya que se calcula de forma aleatoria, ver Expresión 1.1). En general, mientras duren las
retransmisiones el nodo egoı́sta irá ganando posibilidades de acceder al medio para
transmitir sus datos.
Figura 1.8: Jamming a tramas CTS
11
1. Introducción
Jamming a tramas ACK y de datos
Además de ejecutarse sobre tramas CTS, se puede efectuar el jamming contra tramas ACK y de datos. Ası́ se consigue, al igual que en el caso anterior, que la estación
destino del ACK o de los datos doble su CW, y en consecuencia tenga que esperar
intervalos de backoff mayores. Gracias a ésto la estación avariciosa logra aumentar su
oportunidad de acceder al canal.
El proceso para realizar el jamming a tramas de datos es el mostrado en la Figura
1.9. El nodo egoı́sta esperarı́a hasta detectar un CTS de otro nodo, y después de un
tiempo SIFS transmitirı́a una trama para que colisionara con la trama de datos que
es emitida en ese momento. El nodo fuente, al no recibir la confirmación de los datos
enviados, asumirá que se ha producido un fallo, doblará su ventana de contención y la
usará para calcular su tiempo de backoff. Todo ésto conllevará la misma consecuencia
que el caso anterior de jamming, que es el aumento de posibilidades de acceso al medio
por parte del nodo egoı́sta.
El jamming a tramas ACK se efectúa de forma similar al anterior (ver Figura 1.10),
excepto que en este caso el nodo egoı́sta espera a detectar una trama de datos para otro
nodo y es entonces cuando, después de un tiempo SIFS, envı́a la trama para jamming.
Dicha trama colisiona con el ACK enviado por el nodo destino y como en los casos
anteriores el nodo fuente dobla su ventana de contención.
En estos dos últimos procesos de jamming el nodo vulnerado, después de realizar el backoff correspondiente, retransmitirá un RTS por no recibir el ACK esperado. En ambos casos podrá hacer tantas retransmisiones como le indique el atributo
dot11LongRetryLimit de la estación, es decir, a pesar de volver a retransmitir el RTS
se contabiliza como retransmisiones de tramas datos puesto que la trama perdida ha
sido un ACK.
Figura 1.9: Jamming a tramas de datos
12
1.3. Objetivos del proyecto
Figura 1.10: Jamming a tramas ACK
1.3.
Objetivos del proyecto
Descrito ya el problema, en este apartado se detallarán los objetivos que persigue el
proyecto, de los cuales el principal es implementar, mediante el simulador de sistemas
de comunicaciones OPNET Modeler, la ejecución de los ataques a la seguridad de una
red 802.11 utilizando las técnicas de jamming descritas en la Sección 1.2.4.1.
El objetivo principal se puede dividir en dos apartados: estudio teórico del problema e implementación en OPNET Modeler. Dentro de estas dos secciones se pueden
enumerar a su vez objetivos concretos, como son:
Respecto al estudio teórico del problema:
1. Realizar un acercamiento a las tecnologı́as de redes inalámbricas a través el
estudio del estándar 802.11.
2. Conocer el funcionamiento del protocolo CSMA/CA y la técnica de detección de portadora mediante intercambio de tramas RTS/CTS.
3. Estudiar los procedimientos de ataque a redes 802.11 mediante técnicas de
jamming enunciados en [3].
En este capı́tulo se han cumplido los objetivos de este primer apartado al realizar
tanto el estudio de la tecnologı́a 802.11, como el del funcionamiento teórico de
los ataques mediante técnicas de jamming.
Respecto a la implementación en OPNET Modeler:
1. Estudio de la interfaz de programación de aplicaciones de OPNET Modeler
14.5, en concreto de las librerı́as necesarias para llevar a cabo la implementación de los ataques mediante técnicas de jamming.
13
1. Introducción
2. Diseñar y realizar la implementación de los ataques.
3. Evaluar el funcionamiento y efectividad de los ataques implementados mediante el análisis de los resultados de simulaciones efectuadas en OPNET
Modeler.
1.4.
Antecedentes y estado del arte
En esta sección se explicará el estado actual de los temas relacionados con el proyecto abordado. En primer lugar se describirán algunos estudios relativos al comportamiento egoı́sta y a continuación se comentarán algunos de los simuladores de redes
más utilizados.
1.4.1.
Antecedentes en estudio de comportamiento egoı́sta
En general los textos encontrados relativos a esta temática están relacionados con
el ámbito académico. De entre ellos hay artı́culos tanto de estudio del comportamiento
egoı́sta en general, como de formas de llevarlo acabo o de detectarlo. A continuación
se comentarán los artı́culos más interesantes.
Una forma de implementar el comportamiento egoı́sta en la capa MAC es incumplir directamente los tiempos que dicta el estándar para regular el acceso al medio;
por ejemplo los nodos egoı́stas pueden realizar intervalos de backoff más pequeños de
los que deben para aprovechar más tiempo el canal, perjudicando ası́ al resto de nodos. En esta linea se han realizado algunos estudios como el de [7], que propone una
modificación del estándar 802.11 para la detección y penalización de comportamiento
egoı́sta. La idea que plantean Kyasanur y Vaidya es que sea el receptor el que asigne
el valor de backoff que debe esperar el transmisor en su siguiente envı́o. En el caso de
que el backoff realizado por un nodo se desvı́e sensiblemente de los resultados esperados en el receptor, éste penalizará al emisor con un intervalo todavı́a mayor para la
siguiente transmisión y al mismo tiempo reducirá el intervalo de backoff a los nodos
que sı́ cumplan los resultados asignados. Con este esquema se consigue asegurar un
rendimiento razonable para los nodos que cumplen las normas, a pesar de la presencia
de nodos egoı́stas.
Respecto a las técnicas de jamming, en la mayorı́a de textos se implementan mediante configuraciones de tecnologı́as de la capa fı́sica o simplemente generando ruidos continuos de alta potencia. En esta linea en Acharya et al. [8] se demuestra que
reduciendo los niveles de energı́a de las señales de jamming se pueden lograr los mismos efectos que con señales de alta potencia. Los resultados se obtienen simulando
técnicas de jamming con distintos valores de potencia y comparándolas con simulaciones de lo que en el estudio se denomina “jamming inteligente”, que consiste en realizar
el jamming sólo sobre mensajes de control e intervalos de tiempo cruciales. La conclu14
1.4. Antecedentes y estado del arte
sión a la que se llega en este artı́culo es que el jamming inteligente es más eficiente que
las técnicas de jamming trivial.
En [9] se proponen y evalúan cuatro modelos de ataques de jamming diferentes
desde el punto de vista de la detección de los mismos. En el estudio se experimenta
individualmente con distintas medidas para la detección del jamming (fuerza de la
señal, ratio de paquetes entregados y tiempo de detección de portadora) pero con
ninguna de ellas se consigue descubrir con éxito los casos de jamming. Para solucionar
ésto se diseñan unos esquemas de comprobación de consistencia (consistency checking),
de forma que el ratio de paquetes entregados se usa para determinar si un enlace o
link de radio actúa a baja capacidad y en ese caso se emplean dichos esquemas para
determinar si es debido a un ataque de jamming.
Por último, cabe destacar los trabajos realizados por Raya y Hubaux en [10], que
proponen el sistema software DOMINO (system for Detection Of greedy behavior in the
MAC layer of IEEE 802.11 public NetwOrks). Dicho sistema se instala en los puntos de
acceso de las redes inalámbricas y permite detectar e identificar estaciones egoı́stas
sin necesidad de modificar el estándar y sin revelar su presencia. El objetivo que se
persigue es identificar las distintas variedades de comportamiento egoı́sta descritas en
el propio artı́culo y coincidentes con las descritas en [3]. Entre ellas están los ataques
mediante técnicas de jamming estudiados en este proyecto (ver Sección 1.2.4.1). Para
detectar cuándo se producen los ataques, el sistema DOMINO cuantifica la media de
retransmisiones de las tramas de las estaciones, de esta forma las tramas emitidas por
las estaciones egoı́stas experimentarán menos retardos que las demás, por lo que el
sistema es capaz de detectar los nodos que realizan el jamming.
1.4.2.
Estado del arte en simuladores de redes
Los simuladores de redes son herramientas ampliamente usadas en el mundo de la
ingenierı́a. Permiten modelar redes de computadores completas definiendo los comportamientos especı́ficos de sus nodos, dispositivos y enlaces en un escenario virtual
con el que se puede interactuar. Es por ésto que se convierten en una herramienta relativamente barata y rápida en comparación con lo que supone el montaje de una red
real para experimentación. Los simuladores son también especialmente útiles para los
diseñadores, ya que les permiten probar nuevos protocolos o cambios en protocolos
existentes en un entorno controlado.
Los simuladores de redes suelen disponer de una amplia variedad de tecnologı́as
de red y de herramientas para ayudar al usuario a construir redes jerárquicas complejas a partir de bloques básicos (pueden ser nodos, enlaces, perfiles de tráfico, eventos
meteorológicos, etc.).
La mayorı́a de herramientas de simulación de redes se basan en el paradigma de
la simulación de eventos discretos (discrete event-based simulation). Esto implica que los
nodos de la red lanzan eventos para indicar su actuación, por ejemplo cuando envı́an
15
1. Introducción
un paquete a otro nodo, mientras que el simulador a su vez mantiene una lista de
eventos ordenada según el tiempo de ejecución. La simulación se termina correctamente cuando se procesan todos los eventos de la cola.
Uno de los simuladores más potentes y flexibles de los utilizados en el entorno
empresarial es OPNET Modeler. Esta herramienta es de pago, pero también se distribuye gratuitamente a universidades para su uso con fines docentes y de investigación.
Esta opción es la que ha permitido usar este simulador en el desarrollo del presente
proyecto. Para más detalles sobre OPNET Modeler consultar Apéndice A.
Entre los simuladores más populares, además de OPNET Modeler, están los siguientes:
OMNeT++6 . Es un simulador de redes modular de eventos discretos orientado
a objetos. Se usa habitualmente para modelar el tráfico de redes de telecomunicaciones, protocolos, sistemas multiprocesadores y distribuidos, validación de
arquitecturas hardware, evaluación del rendimiento de sistemas software y, en
general para modelar cualquier sistema que pueda simularse con eventos discretos. Dispone de extensiones para simulaciones en tiempo real, emulación de
redes, lenguajes de programación alternativos, integración con bases de datos y
otras muchas funciones.
Esta herramienta está disponible tanto para sistemas operativos basados en UNIX
como para Windows y se distribuye bajo Licencia Pública Académica para su
uso para fines docentes o no lucrativos. Su versión comercial, denominada OMNEST7 , es desarrollada actualmente por la empresa Simulcraft Inc.
Ns-28 . Es un simulador de eventos discretos orientado a la investigación con
redes de computadores. Ns proporciona un soporte sólido para simular sobre
TCP, encaminamiento, protocolos multicast sobre redes cableadas e inalámbricas,
etc.
Ns es software libre distribuido bajo licencia GNU GPL y puede instalarse en sistemas operativos basados en UNIX y sobre sistemas Windows usando el entorno
Cygwin9 .
En Ns-2 se utiliza el lenguaje de programación C++ para modelar el comportamiento de los nodos y el lenguaje de guiones Tcl para controlar la simulación y
especificar diferentes aspectos, como por ejemplo la topologı́a de red.
JiST10 . JiST es un motor de simulación de eventos discretos de alto rendimiento que se ejecuta sobre la máquina virtual de Java. Es un prototipo de la nueva
6
http://www.omnetpp.org/
http://www.omnest.com/
8
http://www.isi.edu/nsnam/ns/
9
http://www.cygwin.com/
10
http://jist.ece.cornell.edu/
7
16
1.4. Antecedentes y estado del arte
aproximación de propósito general para construir simuladores de eventos discretos que unifican los sistemas tradicionales con los diseños de simulaciones
basados en lenguajes. El resultado de las simulaciones es muy eficiente debido a que soporta muchas optimizaciones de tiempo de ejecución y consumo de
memoria.
Las simulaciones de JiST están escritas en lenguaje Java, se compilan utilizando
el compilador regular de Java y se ejecutan sobre la máquina virtual.
JiST es ampliamente usado en conjunto con SWANS que es un simulador de
redes inalámbricas construido sobre la plataforma JiST.
Aunque el desarrollo oficial de JiST actualmente está parado, según [11] una versión reciente desarrollada por la universidad de Ulm ha incorporado bastantes
mejoras.
17
1. Introducción
18
CAPÍTULO
2
ESPECIFICACIÓN DE REQUISITOS
Este capı́tulo tiene como objetivo identificar el conjunto de requerimientos que la
solución implementada debe cumplir. A continuación se describirán los necesarios.
2.1.
Requisitos funcionales
Los requisitos funcionales se encuentran orientados a identificar la funcionalidad
que debe desempeñar la utilidad desarrollada de cara al usuario final. Para este proyecto son los siguientes:
Implementación de ataques mediante técnicas de jamming sobre el software
de simulación de sistemas de comunicaciones OPNET Modeler 14.5. Este requisito representa el objetivo principal del proyecto (ver Sección 1.3). Para cumplirlo se deberá incluir, en los módulos de OPNET Modeler correspondientes, la
capacidad de realizar ataques mediante técnicas de jamming.
Experimentación con las técnicas de jamming implementadas y estudio de
los resultados. A partir de la implementación de las técnicas de jamming se diseñará una estrategia de evaluación para las mismas, de forma que se puedan
obtener resultados sobre distintas configuraciones para poder comparalos y obtener conclusiones.
Desarrollo de una utilidad de registro de información de actuación tanto del
del protocolo CSMA/CA como de los ataques mediante técnicas de jamming
sobre el software OPNET Modeler 14.5. Este tercer requisito se deriva de los
objetivos del proyecto relativos al estudio teórico del estándar 802.11 y de las
19
2. Especificación de requisitos
técnicas de jamming, ya que cumpliéndolo se dispondrá de un registro del funcionamiento tanto del protocolo CSMA/CA como de las técnicas de jamming
desarrolladas.
2.2.
Requisitos no funcionales
Los requisitos no funcionales están orientados a definir las caracterı́sticas que debe
cumplir el funcionamiento de las utilidades planteadas. Son los siquientes:
Transparencia y abstracción. Las utilidades desarrolladas deben ser integradas
en los elementos correspondiente del software OPNET Modeler de forma que el
usuario pueda activarlas o configurarlas desde las interfaces de dichos elementos.
Facilidad de uso. Ası́ mismo las opciones incluidas en la interfaz deben ser,
por su denominación y organización, lo suficientemente descriptivas para que
el usuario comprenda la labor que realizan.
20
CAPÍTULO
3
RECURSOS Y PLANIFICACIÓN
En este capı́tulo se definirán tanto los recursos de que se dispondrán para la realización del proyecto, como la planificación temporal estimada del mismo.
3.1.
Recursos
En esta sección se describirán todos los recursos que serán empleados durante el
desarrollo del proyecto. Los recursos podrán ser de tres tipos: humanos, software o
hardware.
3.1.1.
Recursos humanos
D. Gabriel Maciá Fernández, profesor del Departamento de Teorı́a de la Señal,
Telemática y Comunicaciones de la Universidad de Granada, como tutor del
proyecto.
Marı́a del Carmen Pastor Morales, alumna de la Escuela Técnica Superior de Ingenierı́as Informática y de Telecomunicación de la Universidad de Granada, que
será la encargada de realizar el proyecto siguiendo las directrices definidas por
el tutor del mismo.
3.1.2.
Recursos software
- Sistema Operativo Windows XP Home Edition.
21
3. Recursos y planificación
- Software de simulación gráfica de sistemas de comunicaciones OPNET Modeler
14.5.
- Compilador de Visual Studio C++ 2005.
- Paquete MiKTeX 2.7 (distribución de TEX/LATEX).
- Entorno de trabajo TeXnicCenter 1 Beta 7.50 para documentos escritos en LATEX.
- Programa para generar gráficas de funciones Wgnuplot 4.
- Intérprete del lenguaje perl para windows Active Perl 5.0
- Herramienta de creación de diagramas Dia 0.96.
- Herramienta de creación y retoque de imágenes GIMP 2.4.
- Herramienta de administración de proyectos Planner 0.14
- Sistema de control de versiones Bazaar 1.13.
3.1.3.
Recursos hardware
- Ordenador portátil con procesador Intel Pentium M 740 a 1.73 GHz, 1GB de
memoria RAM y 60 GB de disco duro.
- Conexión a Internet de 1Mb de ancho de banda.
3.2.
Planificación
Para estimar la planificación temporal el desarrollo del proyecto se ha dividido
en una serie de tareas a las que se les ha asignado una duración aproximada. Los
resultados de esta planificación se muestran en la Figura 3.1 por tareas y en la Figura
3.2 mediante un diagrama de Gantt .
22
3.2. Planificación
Figura 3.1: Planificación del proyecto: tareas
23
3. Recursos y planificación
Figura 3.2: Planificación del proyecto: diagrama de Gantt
24
CAPÍTULO
4
ANÁLISIS DE LA ARQUITECTURA DEL SIMULADOR
En este capı́tulo se ha realizado un estudio del simulador OPNET Modeler ya que,
para llevar a cabo los objetivos de implementación planteados, es necesario conocer
tanto la arquitectura del simulador como el funcionamiento de los modelos que deben
usarse.
A continuación se describirán algunos detalles especı́ficos de los modelos de nodo
y de proceso de OPNET Modeler que serán utilizados en el desarrollo del proyecto.
Para ver una breve introducción a OPNET Modeler y a la arquitectura de sus niveles
de desarrollo consultar Apéndice A.
4.1.
Modelo de nodo
Para decidir qué modelo de nodo deben implementar las estaciones de la simulación se analizaron las alternativas que proporciona OPNET Modeler para estaciones
de una red wireless LAN. Los modelos principales son wlan workstation adv y wlan station adv. La diferencia entre ellas es que mientras que las wlan workstation adv implementan todas las capas del modelo de red, las wlan station adv sólo implementan
la capa fı́sica y la capa MAC. Para ello las wlan station adv disponen de unos modelos
de proceso que se comportan como una abstracción de las capas superiores y pueden
configurarse de diferentes formas para generación de tráfico.
Según [12] con el modelo de nodo wlan station adv se puede: generar tráfico controlado en una red WLAN y evaluar los resultados en la capa MAC, simular el efecto de
los atributos de una red WLAN independientemente de las capas superiores y obtener
tiempos de simulación más cortos (respecto al modelo wlan workstation adv). También
se afirma que es el modelo de nodo más adecuado para los estudios enfocados en la
25
4. Análisis de la arquitectura del simulador
capa MAC y capa fı́sica. Por todo ésto se ha elegido wlan station adv como modelo de
nodo para el desarrollo del proyecto.
La estructura del modelo de nodo, mostrada en la Figura 4.1 consta a a su vez de
los siguientes módulos:
- source: módulo generador de tráfico. Será el encargado de crear los paquetes de
datos que se enviarán a la capa MAC para ser transmitidos.
- sink: módulo receptor de tráfico. Recibe los paquetes que han llegado con éxito
y posteriormente los destruye. Junto con el módulo anterior son los encargados
de reemplazar a las capas superiores del modelo de red.
- wlan mac intf : módulo que proporciona la interfaz necesaria para comunicar las
capas superiores (simuladas por los módulos source y sink) con la capa MAC y
permitir el flujo de paquetes en ambos sentidos entre ellas.
- wireless lan mac: módulo que implementa la capa MAC definida en el estándar
IEEE 802.11. Por defecto la configuración de este módulo en las wlan station adv
implementa la versión del estándar 802.11b con la tecnologı́a de la capa fı́sica
Direct Sequence.
- wlan port tx: módulo transmisor de radio. Transmite la información al medio
fı́sico.
- wlan port rx: módulo receptor de radio. Recibe la información del medio fı́sico.
Para conectar los módulos anteriores se utilizan los packet streams y los statistic wires
(ver Figura 4.1).
Los packet streams son conexiones fı́sicas que soportan las transferencias de paquetes entre los módulos del mismo nodo.
Los statistic wires transportan datos de un módulo a otro pero sólo valores individuales. Normalmente se usan como interfaces en los que el módulo fuente puede
compartir ciertos valores con el módulo destino y de ese modo proporcionar información acerca de su estado. También emplean un mecanismo de señalización que permite al módulo fuente notificar al módulo destino que se ha alcanzado una condición
particular.
Después de analizar el modelo de nodo que se va a utilizar se debe estudiar el
módulo que habrá que alterar para realizar la implementación de los ataques con
técnicas de jamming.
26
4.2. Modelo de proceso
Figura 4.1: Modelo de nodo wlan station
4.2.
Modelo de proceso
Cada uno de los módulos explicados en la sección anterior implementa un modelo
de proceso que permite definir su comportamiento (definición de modelo de proceso
en Apéndice A). Como se explicó en el apartado anterior, el módulo wireless lan mac
representa a la capa MAC del modelo de nodo wlan station adv. Este módulo a su vez
tiene asociado un modelo de proceso llamado wlan mac que es el que implementa el
comportamiento de la capa MAC siguiendo la definición del estándar 802.11.
Dado que los ataques planteados en este proyecto se ejecutan a nivel de la capa
MAC ha sido necesario estudiar en profundidad el código del modelo de proceso
wlan mac. Por ésto a continuación se hará un resumen del funcionamiento del módulo
citado, estructurándolo en dos partes a distinto nivel de abstracción. En el primer nivel
se comentarán algunas de las rutinas que son llamadas desde los estados que definen
el comportamiento del modelo y en el segundo nivel se describirán los estados más
importantes y sus transiciones.
4.2.1.
Rutinas del modelo de proceso
A continuación se explican algunas de las rutinas del modelo wlan mac necesarias
para realizar el diseño de la implementación propuesta en este proyecto.
27
4. Análisis de la arquitectura del simulador
El modelo de proceso wlan mac consta de una serie de rutinas que se llaman desde los estados del autómata finito que definen su comportamiento. Dichas rutinas
implementan el grueso de las definiciones del estándar 802.11. A continuación se comentarán las rutinas más importantes de entre las que intervienen en el proceso de
comunicación entre los nodos, ya que serán las susceptibles de ser modificadas para
la implementación planteada en este proyecto.
wlan interrupts process. Cómo se describe en el Apéndice A, cuando el nodo entra
en un estado del modelo de proceso se ejecuta un bloque de código de entrada
y a continuación se espera a recibir una interrupción. Estas interrupciones son
tratadas por la rutina wlan interrupts process y pueden ser de dos tipos:
- stream interrupt: interrupción procedente de la capa superior o inferior, se
produce para avisar de la llegada de datos. La rutina wlan interrupts process
identifica las interrupciones de este tipo y las despacha llamando al procedimiento wlan higher layer data arrival si proviene de la capa superior o al
procedimiento wlan physical layer data arrival en caso contrario.
- stat interrupt: son interrupciones procedentes del receptor o del transmisor
y se pueden producir por varios motivos: para informar si el canal está ocupado (y por tanto no se podrá usar para transmitir), para indicar que se ha
concluido un tiempo de espera que habı́a sido planificado, o bien para administrar los tiempos del periodo de contención o libre de contención. En el
caso del presente desarrollo no se producirán interrupciones de éste último
tipo al tener inhabilitada la función de coordinación puntual.
wlan physical layer data arrival. Procedimiento encargado de actuar cuando se recibe
una trama desde la capa fı́sica. Su función es desencapsular la trama y activar
los flags necesarios en caso de que se necesite una respuesta. Para ello primero
revisará el tipo de de trama, que puede ser de control (RTS, CTS o ACK), de
datos o de administración (asociación, autenticación, reserva, beacon, etc.), y a
continuación examinará el destino, si es el propio nodo actuará en consecuencia
activando el tipo de respuesta correspondiente.
wlan schedule deference. En esta rutina se planifican las esperas que debe realizar el
nodo, tanto para respetar el periodo de backoff, como las relativas a los intervalos
entre transmisiones de tramas (SIFS, DIFS, EIFS, etc.)
wlan frame transmit. Es el procedimiento que realiza la preparación y transmisión de
las tramas. Ası́ mismo fija las respuestas esperadas para cada tipo de trama enviada.
4.2.2.
Estados y transiciones del modelo
En OPNET Modeler los modelos de proceso se definen mediante un autómata finito (ver Apéndice A). El autómata que representa el modelo de proceso wlan mac es
28
4.2. Modelo de proceso
el mostrado en la Figura 4.2
Para comprender mejor el funcionamiento de este modelo se va poner un ejemplo
en el que se enviarán dos tramas de datos consecutivas entre dos estaciones, la estación transmisora se llamará T y la receptora R. Se irán comentado los estados por los
que pasa la estación T y sus transiciones.
La estación T recibe una interrupción informándole de que ha llegado un paquete de las capas superiores. Para poder transmitir se
supone que se cumplen dos condiciones:
1.
- READY TO TRANSMIT: la estación dispone de la trama (en
este caso de datos) lista para enviar.
- wlan flags→inmediate xmt: se puede realizar la transmisión si
el canal ha estado ocioso durante un tiempo mayor o igual a
DIFS.
2.
La estación T inicia la transmisión de la trama de datos. Al finalizar la propia estación generará una interrupción informando
de ello y de esta forma se cumplirá la condición TRANSMISSION COMPLETE necesaria para pasar al siguiente estado.
3.
La estación T programa una espera SIFS para recibir la trama ACK.
Esta trama le asegura que la recepción ha sido satisfactoria y que la
trama recibida por R no contiene ningún error. La condición de espera de trama WAIT FOR FRAME se cumple, por lo que se pasará al
estado siguiente.
4.
La estación T recibe la interrupción que le indica la llegada de la trama ACK esperada. Se cumple la condición FRAME RCVD de trama
recibida y se pasa al estado siguiente.
5.
La transmisión de la trama se ha completado, pero hay más datos para enviar, por lo que se planifica una espera DIFS antes de realizar la contienda por el canal. Se cumple la condición
FRM END TO DEFER y se pasa al estado siguiente.
6.
La estación T pasa a realizar la espera DIFS. Después de ésto se cumple la condición DEFERENCE OFF y se pasa al estado siguiente.
29
4. Análisis de la arquitectura del simulador
30
7.
En este estado se determina si se necesita realizar el procedimiento
de contienda por el que la estación debe esperar el intervalo de backoff (ver Sección 1.2.3.1). En este caso se debe realizar, debido a que
se trata de una nueva transmisión. Cómo la transmisión anterior se
realizó con éxito se usará para calcular el backoff el valor de CWmin
(fórmula de cálculo de backoff en 1.1). Se cumple la condición PERFORM BACKOFF y se pasa al estado siguiente.
8.
En este estado se realizarı́a la espera por causa de backoff planificada
en el estado anterior y una vez terminada se volverı́a a pasar por
los estados descritos en los pasos del 2 al 5. En este caso desde el
estado FRM END, al no tener más datos para enviar se cumplirı́a la
condición FRM END TO IDLE y se pasarı́a al estado siguiente.
9.
La estación T volverı́a a este estado hasta que recibiera una nueva
interrupción.
4.2. Modelo de proceso
Figura 4.2: Modelo de proceso de la capa MAC
31
4. Análisis de la arquitectura del simulador
32
CAPÍTULO
5
DISEÑO DE LA SOLUCIÓN
En este capı́tulo se van a tratar las cuestiones relativas al diseño de la solución para
la implementación tanto de los ataques mediante técnicas de jamming explicados en la
Sección 1.2.4.1, como de la utilidad de generación de mensajes de log (descritos ambos
como requisitos funcionales del proyecto en la Sección 2.1).
5.1.
Diseño de los ataques
La implementación de los ataques mediante técnicas de jamming se va a realizar
sobre el código fuente del modelo de proceso wlan mac de OPNET Modeler 14.5.
Para diseñar la solución de implementación se van a distinguir dos clasificaciones, según el tipo de jamming y según el modo de realizarlo, que serán explicadas a
continuación.
5.1.1.
Tipos de jamming
Los tipos de jamming se dividirán en función de las tramas que son objeto del
ataque, es decir, aquellas que son saboteadas con el envı́o de la trama perniciosa. Para
esta distribución se tomarán los tres tipos explicados en la Sección 1.2.4.1, que son:
jamming a tramas CTS, jamming a tramas de datos y jamming a tramas ACK.
Para la implementación de los tres tipos de jamming sobre el código fuente del
modelo de proceso wlan mac, se describirán a continuación una serie de cuestiones
de diseño seguidas de las soluciones adoptadas para las mismas. A través de ellas se
irá construyendo el diseño de la solución global. Las cuestiones son las siguientes:
33
5. Diseño de la solución
1. Identificar el lugar del código donde la estación detecta la llegada de la trama
previa a la que es objeto del ataque. Activar en este punto un indicador de comienzo de jamming.
SOLUCIÓN Se creará un flag que indique el comienzo del proceso y según el
tipo de jamming se activará: para el jamming a CTS a la llegada de una trama RTS para otra estación, para el jamming a datos a la llegada de una trama CTS para otra estación y para el jamming a ACK a la llegada de una trama de datos para otra estación. Este código se situará dentro del procedimiento
wlan physical layer data arrival (descripción en la Sección 4.2.1).
2. Seleccionar la trama que se que va a utilizar para realizar el jamming y planificar
la espera que debe realizar para que se emita en el mismo instante que la trama
objeto del ataque. Esta espera se corresponde con el tiempo SIFS (Short Interframe
Space).
SOLUCIÓN: Después de la activación del flag de comienzo de jamming, en el
procedimiento wlan physical layer data arrival, se definirá la trama para realizar
jamming. La empleada es una trama CTS, la elección de este tipo de trama se basa
en los siguientes motivos:
- Por ser una trama de control, ya que debe ser generada por la capa MAC.
Además es conveniente que se refleje en las tablas de estadı́sticas de paquetes que recoge OPNET Modeler (ver definición en 7.2.1).
- Por emitirse después de un tiempo SIFS. Antes del envı́o de una trama CTS,
según la norma 802.11, se debe esperar un tiempo SIFS igual que el necesario antes de enviar la trama para jamming por lo que se aprovecha esta
configuración.
Por todo lo anterior se usan tramas CTS para realizar los tres tipos de jamming.
De esta forma cuando el nodo objeto del jamming recibe un CTS que no es para
él lo toma como una trama errónea, por lo que deduce que se ha producido una
colisión y que la trama que él esperaba (ya sea un CTS o un ACK) se ha perdido.
3. Envı́o de la trama de jamming y activación de indicador de finalización de jamming.
SOLUCIÓN: En el procedimiento wlan frame transmit (descripción en la Sección
4.2.1) después de enviar la trama para jamming se activará un flag de jamming
finalizado.
4. Reinicio de los indicadores de jamming.
SOLUCIÓN: Las transmisiones se dan por finalizadas en el estado FRM END
(decripción en Sección 4.2.2) por lo que se incluirá en el código de este estado el
34
5.1. Diseño de los ataques
reinicio de los flags usados para seguir el proceso de jamming.
5. Requisito de activación del jamming desde la interfaz (ver Sección 2.2).
SOLUCIÓN: Se incluirá una variable, que pueda ser modificada desde la interfaz, que permita habilitar o inhabilitar cada tipo de jamming.
5.1.2.
Modos de jamming
Pensando en el periodo de evaluación, se ha considerado útil diferenciar varios
modos de realizar jamming. De esta forma resulta más sencillo planificar el estudio de
los resultados y obtener datos diferenciados para cada experimentación.
Los tres tipos de jamming anteriormente descritos podrán a su vez realizarse de
tres modos:
Modo continuo. Con este modo el nodo jammer realiza jamming a todas las tramas1
aunque no disponga de datos para enviar. De esta forma el jammer se dedica a sabotear las transmisiones ajenas realizando un ataque de denegación de servicio
(Denial of Service, DoS) a los demás participantes en la comunicación. El modo
continuo puede considerarse cómo un modo de experimentación, ya que con él
pueden verse aislados los resultados del jamming separándolos del resultado del
comportamiento egoı́sta, que es ganar ancho de banda a expensas de los demás
(definición en Sección 1.2.4).
Modo normal. Con el modo normal el nodo jammer realizará el jamming sólo cuando
tenga datos para enviar. De esta forma se lleva a cabo el comportamiento egoı́sta
descrito en la Sección 1.2.4, ya que el objetivo del jamming en este caso sı́ es la
obtención de mejora de ancho de banda a expensas del resto de usuarios.
Modo aleatorio. Con este modo se realiza el jamming en modo normal pero sólo en
algunas ocasiones. En este caso el objetivo del jammer también es ganar ancho
de banda, pero trata de ocultar su ataque realizándolo de forma menos agresiva
que en el modo normal. Para ello primero se definirá un parámetro que sirva de
umbral de probabilidad y después se generará un número aleatorio, a partir de
una distribución uniforme entre 0 y 1, de forma que si dicho número es menor
que el valor introducido para el umbral se realiza el jamming. En caso contrario
el jammer se comporta siguiendo la norma 802.11
Una vez descritos los modos que se deben desarrollar se comentará la estrategia de
implementación de los mismos. Se usará el método utilizado anteriormente de plantear las cuestiones de diseño y las soluciones a las mismas.
1
Dependiendo del tipo de jamming, si se trata por ejemplo de jamming a CTS realizará jamming a todas
las tramas CTS que no pertenezcan a sus transmisiones, es decir a las tramas CTS que no tengan al propio
nodo jammer como destino
35
5. Diseño de la solución
1. Definir los modos de jamming y habilitar su selección desde la interfaz
SOLUCIÓN: Se definirá una variable (para cada tipo de jamming) para almacenar el modo de jamming. El uso de la misma, junto con el flag de activación de
jamming descrito en la Sección 5.1.1, servirá para determinar si algún tipo de jamming está habilitado y en ese caso en que modo debe realizarse. Esta selección se
realizará desde la interfaz del nodo. Para el jamming aleatorio se recuperará también desde la interfaz el valor del umbral de probabilidad.
2. Identificar el lugar del código donde se debe realizar la comprobación de los
modos de jamming.
SOLUCIÓN: Deberá realizarse en el mismo momento que se activa el jamming
ya que la activación será condicionada al modo seleccionado.
5.2.
Diseño del log
Para cumplir el tercer requisito planteado en la Sección 2.1 se ha desarrollado para
este proyecto la utilidad de registrar mensajes de información en tiempo de ejecución
en un log. Esta información deberá ser descriptiva para ayudar a comprender, tanto el
funcionamiento del estándar 802.11 implementado en el modelo de proceso wlan mac
de OPNET Modeler 14.5, como el proceso de jamming comentado en las secciones anteriores. Para entender la implementación de la norma 802.11 que efectúa OPNET Modeler también se debe conocer el recorrido que realiza el autómata finito del modelo
de proceso por los estados que definen su comportamiento.
Para cumplir con los fines descritos la utilidad de registro de mensajes diferenciará tres tipos de información, la información general del estándar, los estados que
recorre el autómata y la información del proceso de jamming. A continuación se describen estos tipos con más detalle:
Información general: representa información del funcionamiento de la norma 802.11
registrando: acciones relativas al tráfico (recibido, enviado y descartado), información de retransmisiones e incremento de contadores de lı́mite de las mismas,
e información de proceso de backoff (inicio, duración y parada).
Estados por lo que pasa el autómata: se incluirán en el log los nombres de los estados
por los que transita el modelo de proceso, para comprender mejor el funcionamiento del mismo.
Información de jamming: si el nodo está realizando jamming se registrarán mensajes
de información relativos al comienzo de jamming (llegada de una trama previa
a la que es objeto del ataque), envı́o de trama para realizar el jamming y fin del
proceso.
Tiempo de ejecución: para completar los mensajes de información de los tipos anteriores es muy útil que se conozca el tiempo de ejecución en que se han realizado
36
5.2. Diseño del log
cada uno, por ésto antes de todos los demás mensajes de log se podrá imprimir
el tiempo de la ejecución en que se han producido.
Para definir la solución de implementación de la utilidad de log se procederá como en los casos anteriores, definiendo las cuestiones a resolver y las soluciones a las
mismas. Son las siguientes:
1. Requisito de configuración desde la interfaz (ver Sección 2.2).
SOLUCIÓN: Se incluirá en el interfaz un indicador para cada tipo de mensajes
de log, dicho indicador almacenará si los mensajes de cada tipo deben ser registrados o no. De esta forma puede configurarse la información que se registra en
el log para cada simulación. Los mensajes se imprimirán al finalizar la simulación en la consola de OPNET Modeler.
2. Identificar la forma en que se implementará el registro y los tipos de mensajes
que se imprimirán.
SOLUCIÓN: Para evitar que la implementación de los mensajes se repita o esté dispersa por el código del modelo se creará una rutina por cada tipo de mensaje que
se pueda registrar. Las llamadas a las rutinas se realizarán, dependiendo del tipo de mensaje, si el indicador del tipo correspondiente ha sido activado desde
la interfaz, y se colocarán siguiendo al código que implementa la actividad de la
que informan. Los mensajes serán los siguientes:
Mensajes de información general:
- Tipos de tramas transmitidas: podrán ser de control o de datos.
- Tipos de tramas retransmitidas y la causa: podrán ser de control o de
datos y la causa la no recepción de una trama esperada.
- Información de los contadores de retransmisiones.
- Información del proceso de backoff : comienzo y duración, interrupción
por receptor ocupado, reanudación y tiempo restante, y finalización.
Mensajes de jamming:
- Inicio de jamming: información con la trama recibida que desencadena
el jamming y tipo de jamming.
- Envı́o de la trama para jamming.
- Finalización del proceso.
Para la información de estados por los que pasa el proceso se imprimirá el nombre del estado correspondiente y para la información de tiempo de ejecución se
imprimirá el tiempo antes de todos los demás tipos de mensajes.
37
5. Diseño de la solución
38
CAPÍTULO
6
IMPLEMENTACIÓN
En este capı́tulo se explicará la implementación de los ataques mediante técnicas
de jamming y la utilidad de generación de mensajes de log realizados para este proyecto. El código que se comenta a continuación ha sido desarrollado para este proyecto y
se ha incluido en el modelo de proceso wlan mac de OPNET Modeler 14.5.
6.1.
Técnicas de jamming
A continuación se va a explicar el código desarrollado para implementar los ataques mediante técnicas de jamming. Para esta solución se ha seguido el proceso descrito en la Sección 1.2.4.1 junto con los pasos detallados en 5.1. En primer lugar se
describirán las variables necesarias para la implementación del proceso y a continuación los segmentos de código que se han incluido en el código fuente original.
La estructura de datos WlanT Mac Flags contiene todos los flags para determinar varias condiciones presentes en el modelo de proceso. A esta estructura se le han
añadido los flags que se usan para activar y desactivar cada tipo de jamming (definición
de tipos en Sección 5.1.1). Como se muestra en el Listado 6.1 se usarán tres, de los cuales tipo jamming on indica si el jamming de ese tipo ha sido activado desde la interfaz (requisito del proyecto, ver sección 2.2), tipo jamming ready se activará cuando
la trama previa a la que se le va a realizar el jamming sea recibida en el nodo jammer y
tipo jamming finished que se activará cuando la trama para realizar jamming se
envı́e.
39
6. Implementación
Boolean
Boolean
Boolean
Boolean
Boolean
Boolean
Boolean
Boolean
Boolean
cts jamming on ;
c t s j a m m in g r e a d y ;
cts jamming finished ;
data jamming on ;
data jamming ready ;
data jamming finished ;
ack jamming on ;
ack jamming ready ;
ack jamming finished ;
/∗
/∗
/∗
/∗
/∗
/∗
/∗
/∗
/∗
A c t i v a d o jamming
Trama d e jamming
Enviada trama de
A c t i v a d o jamming
Trama d e jamming
Enviada trama de
A c t i v a d o jamming
Trama d e jamming
Enviada trama de
a CTS ∗ /
l i s t a para ser enviada ∗/
jamming a CTS ∗ /
a datos ∗/
l i s t a para ser enviada ∗/
jamming a d a t o s ∗ /
a ACK∗ /
l i s t a para ser enviada ∗/
jamming a ACK∗ /
Listado 6.1: Declaración de flags de jamming
La estructura mi wlan mac jm state contiene las variables de estado del modelo. A esta estructura se añaden las variables que deben ser fijadas por el usuario desde
la interfaz. En la Figura 6.1 puede verse la forma en que dichas variables se representan en la interfaz (junto a los demás atributos del nodo). En el Listado 6.2 se muestra
el código de la declaración de las mismas. A continuación se explicará la función de
estas variables:
- tipo jamming mode: almacenará un entero correspondiente al tipo de modo
de jamming que se active desde la interfaz (definición de modos en Sección 5.1.2).
Será 0 si el jamming está inhabilitado, 1 si el modo seleccionado es normal, 2 si
es continuo y 3 si es aleatorio. En la interfaz se mostrarán las opciones Disabled,
Normal, Continuos y Random que se corresponderán, respectivamente, con los
valores anteriores.
- tipo jamming parameter: este valor se emplea si para la variable anterior se
ha seleccionado el tipo aleatorio y almacenará un valor entre 0 y 1 que determinará la probabilidad de que se realice jamming. En la interfaz este parámetro
recibirá el nombre Random TIPO Jamming.
i n t cts jamming mode ;
i n t data jamming mode ;
i n t ack jamming mode ;
double c t s jamming parameter ;
double data jamming parameter ;
double ack jamming parameter ;
/∗
/∗
/∗
/∗
/∗
/∗
Modo d e jamming a CTS ∗ /
Modo d e jamming a DATOS ∗ /
Modo d e jamming a ACK ∗ /
Umbral p a r a jamming a CTS a l e a t o r i o ∗ /
Umbral p a r a jamming a DATOS a l e a t o r i o ∗ /
Umbral p a r a jamming a ACK a l e a t o r i o ∗ /
Listado 6.2: Declaración de variables de estado para jamming
40
6.1. Técnicas de jamming
Figura 6.1: Interfaz de un nodo: parámetros de jamming
En la rutina de iniciación wlan mac sv init en primer lugar se obtendrán de
la interfaz los valores introducidos por el usuario asignándoselos a las variables correspondientes (ver Listado 6.3). Después se asignarán los valores iniciales a los flags
restantes (ver Listado 6.4).
/∗
op
op
op
op
op
op
Captura
ima obj
ima obj
ima obj
ima obj
ima obj
ima obj
d e p a r á m e t r o s p a r a jamming d e s d e l a i n t e r f a z ∗ /
a t t r g e t ( my objid , ”CTS Jamming Mode” ,& cts jamming mode ) ;
a t t r g e t ( my objid , ”CTS Random Parameter ” ,& cts jamming parameter ) ;
a t t r g e t ( my objid , ”DATA Jamming Mode” ,& data jamming mode ) ;
a t t r g e t ( my objid , ”DATA Random Parameter ” ,& data jamming parameter ) ;
a t t r g e t ( my objid , ”ACK Jamming Mode” ,&ack jamming mode ) ;
a t t r g e t ( my objid , ”ACK Random Parameter ” ,& ack jamming parameter ) ;
Listado 6.3: Inicialización de variables de estado para jamming
i f ( cts jamming mode ==0)
w l a n f l a g s −>cts jamming on = OPC FALSE ;
else
w l a n f l a g s −>cts jamming on = OPC TRUE ;
w l a n f l a g s −>c t s j a m m in g r e a d y
= OPC FALSE ;
w l a n f l a g s −>c t s j a m m i n g f i n i s h e d = OPC FALSE ;
i f ( data jamming mode ==0)
41
6. Implementación
w l a n f l a g s −>data jamming on = OPC FALSE ;
else
w l a n f l a g s −>data jamming on = OPC TRUE ;
w l a n f l a g s −>data jamming ready
= OPC FALSE ;
w l a n f l a g s −>d a t a j a m m i n g f i n i s h e d
= OPC FALSE ;
i f ( ack jamming mode ==0)
w l a n f l a g s −>ack jamming on = OPC FALSE ;
else
w l a n f l a g s −>ack jamming on = OPC TRUE ;
w l a n f l a g s −>ack jamming ready
= OPC FALSE ;
w l a n f l a g s −>a c k j a m m i n g f i n i s h e d = OPC FALSE ;
Listado 6.4: Inicialización de flags de jamming
En el procedimiento wlan physical layer data arrival se activarán los procesos de jamming. Según el tipo de jamming la activación se realizará en distintas circunstancias:
- Para el jamming a CTS se activará cuando se reciba un RTS destinado a otra
estación (ver Listado 6.5).
- Para el jamming a datos se activará cuando se reciba un CTS con otra estación
como destino (ver Listado 6.6).
- Para el jamming a ACK la activación se realizará al recibir una trama de datos
que tenga como destino otra estación (ver Listado 6.7).
Para todos los tipos se realizará el jamming, en caso de que esté habilitado, teniendo en cuenta el modo: para el jamming en modo continuo se realizará siempre, para el
modo normal sólo cuando la cola de transmisión no esté vacı́a y para el modo aleatorio cuando la función wlan random jamming devuelva CIERTO.
/ ∗ Jamming a CTS ∗ /
i f ( cts jamming mode = = 2 | | ( cts jamming mode==1 && total hlpk num > 0 ) | |
( cts jamming mode==3 && wlan random jamming ( cts jamming parameter ) ) )
{
f r e s p t o s e n d = WlanC Cts ;
w l a n f l a g s −>c t s j a m m i ng r e a d y=OPC TRUE ;
i f ( log jamming )
wlan log print jamming info ( 1 ) ;
}
Listado 6.5: Activación del jamming a CTS
42
6.1. Técnicas de jamming
/ ∗ Jamming a d a t o s ∗ /
i f ( data jamming mode = = 2 | | ( data jamming mode==1 && total hlpk num > 0 ) | |
( data jamming mode==3 && wlan random jamming ( data jamming parameter ) ) )
{
f r e s p t o s e n d = WlanC Cts ;
w l a n f l a g s −>data jamming ready=OPC TRUE ;
i f ( log jamming )
wlan log print jamming info ( 2 ) ;
}
Listado 6.6: Activación del jamming a datos
/ ∗ Jamming a ACK ∗ /
e l s e i f ( ack jamming mode = = 2 | | ( ack jamming mode==1 && total hlpk num > 0 ) | |
( ack jamming mode==3 && wlan random jamming ( ack jamming parameter ) ) )
{
f r e s p t o s e n d = WlanC Cts ;
w l a n f l a g s −>ack jamming ready=OPC TRUE ;
i f ( log jamming )
wlan log print jamming info ( 3 ) ;
FOUT ;
}
Listado 6.7: Activación del jamming a ACK
La función wlan random jamming ha sido implementada para el proceso de jamming aleatorio. En ella se obtiene un número aleatorio a partir de una distribución uniforme entre 0 y 1 y si es menor que el valor introducido para el parámetro de jamming
aleatorio (tipo jamming parameter) se realiza el jamming. El código de la función
es el mostrado en el Listado 6.8.
s t a t i c Boolean wlan random jamming ( double random parameter )
{
double random num ;
random num= o p d i s t u n i f o r m ( 1 ) ;
i f ( random num <= random parameter )
r e t u r n OPC TRUE ;
else
r e t u r n OPC FALSE ;
}
Listado 6.8: Función de jamming aleatorio
En en procedimiento wlan frame transmit se realizan las transmisiones de las
tramas. En él se ha incluido, después de los envı́os de las tramas CTS para jamming, el
código que actualiza los flags desactivando el de jamming listo (tipo jamming ready)
y activando el de jamming terminado (cts jamming finished). El código es el mostrado en el Listado 6.9.
43
6. Implementación
i f ( w l a n f l a g s −>cts jamming on && w l a n f l a g s −>c t s j a m m in g r e a d y )
{
w l a n f l a g s −>c t s j a m m i ng r e a d y=OPC FALSE ;
w l a n f l a g s −>c t s j a m m i n g f i n i s h e d =OPC TRUE ;
i f ( log jamming )
wlan log print jamming info ( 1 ) ;
}
i f ( w l a n f l a g s −>data jamming on && w l a n f l a g s −>data jamming ready )
{
w l a n f l a g s −>data jamming ready=OPC FALSE ;
w l a n f l a g s −>d a t a j a m m i n g f i n i s h e d =OPC TRUE ;
i f ( log jamming )
wlan log print jamming info ( 2 ) ;
}
i f ( w l a n f l a g s −>ack jamming ready )
{
w l a n f l a g s −>ack jamming ready=OPC FALSE ;
w l a n f l a g s −>a c k j a m m i n g f i n i s h e d =OPC TRUE ;
i f ( log jamming )
wlan log print jamming info ( 3 ) ;
}
Listado 6.9: Finalización del jamming
Para terminar el proceso de jamming se deben reiniciar los flags usados para que
estén listos para la siguiente oportunidad de jamming. Este proceso se realiza dentro
del estado FRM END mediante el código mostrado en el Listado 6.10.
i f ( w l a n f l a g s −>cts jamming on && w l a n f l a g s −>c t s j a m m i n g f i n i s h e d )
{
w l a n f l a g s −>c t s j a m m i n g f i n i s h e d =OPC FALSE ;
i f ( log jamming )
wlan log print jamming info ( 1 ) ;
}
e l s e i f ( w l a n f l a g s −>data jamming on && w l a n f l a g s −>d a t a j a m m i n g f i n i s h e d )
{
w l a n f l a g s −>d a t a j a m m i n g f i n i s h e d =OPC FALSE ;
i f ( log jamming )
wlan log print jamming info ( 2 ) ;
}
e l s e i f ( w l a n f l a g s −>ack jamming on && w l a n f l a g s −>a c k j a m m i n g f i n i s h e d )
{
w l a n f l a g s −>a c k j a m m i n g f i n i s h e d =OPC FALSE ;
i f ( log jamming )
wlan log print jamming info ( 3 ) ;
}
Listado 6.10: Reinicio de los flags de jamming
44
6.2. Log de registro
6.2. Log de registro
La utilidad de generación de mensajes de log ha sido implementada según la definición y pasos descritos en la Sección 5.2. A continuación se comentarán los detalles y
el código de implementación.
La estructura mi wlan mac jm state, como ya se ha comentado, contiene las variables de estado del modelo. A esta estructura se deben añadir tanto los flags de log
que deben ser fijados por el usuario desde la interfaz, como las variables para almacenar el nombre nodo y del estado anterior. El nombre del nodo se imprimirá antes
de cada mensaje de log, sea del tipo que sea, para reflejar qué nodo es el que está imprimiendo la información. En la Figura 6.2 puede verse la forma en que los flags se
representan en la interfaz y en el Listado 6.11 el código de la declaración de los mismos junto con las variables comentadas.
char node name [ 1 6 ] ;
char p r e v i o u s s t a t e n a m e [ 3 2 ] ;
Boolean l o g t i m e ;
Boolean log jamming ;
Boolean l o g g i n f o ;
Boolean log sname ;
/∗
/∗
/∗
/∗
/∗
/∗
Nombre nodo ∗ /
Nombre e s t a d o
I n c l u i r en l o g
I n c l u i r en l o g
I n c l u i r en l o g
I n c l u i r en l o g
a n t e r i o r ∗/
t i e m p o d e e j e c u c i ó n ∗ /
m e n s a j e s d e jamming ∗ /
m e n s a j e s d e i n f o r m a c i ó n ∗ /
nombres e s t a d o s ∗ /
Listado 6.11: Declaración de variables de estado del log
Figura 6.2: Interfaz de un nodo: parámetros de log
45
6. Implementación
En la rutina de iniciación wlan mac sv init, para el fragmento mostrado en el
Listado 6.12, en primer lugar se obtendrá el nombre del nodo del modelo superior y a
continuación se recogerán los valores introducidos por el usuario desde la interfaz y
se asignarán a las variables correspondientes.
/ ∗ Nombre d e l nodo ∗ /
o p i m a o b j a t t r g e t ( my node objid , ”name” , node name ) ;
/∗
op
op
op
op
P a r á m e t r o s d e l o g ∗ /
i m a o b j a t t r g e t ( my
i m a o b j a t t r g e t ( my
i m a o b j a t t r g e t ( my
i m a o b j a t t r g e t ( my
objid
objid
objid
objid
, ”Log
, ”Log
, ”Log
, ”Log
Time” , &l o g t i m e ) ;
S t a t e Name” , &log sname ) ;
General I n f o ” , &l o g g i n f o ) ;
Jamming” , &log jamming ) ;
Listado 6.12: Inicialización de variables de estado para el log
Una vez realizada la declaración e inicialización de las variables y flags necesarios
se pasarán a comentar las funciones implementadas para imprimir los mensajes de log
descritos en la Sección 5.2.
La función que imprime los mensajes de información de jamming es la mostrada en
el Listado 6.13. Dicha función recibe un parámetro que sirve para identificar el tipo de
jamming. Según el mismo y el flag de jamming que esté activo se imprimirá un mensaje
u otro.
Pueden verse ejemplos de llamadas a esta función en los Listados 6.5, 6.6, 6.7, etc.
siguiendo al código que implementa la parte del proceso de jamming del que informan.
Dichas llamadas, y por tanto el registro de los mensajes de información de jamming en
el log, se realizarán si el usuario ha activado el flag log jamming desde la interfaz.
s t a t i c void w l a n l o g p r i n t j a m m i n g i n f o ( i n t code )
{
FIN ( w l a n l o g p r i n t j a m m i n g i n f o ( i n t ) ) ;
i f ( log time )
p r i n t f ( ”[ % l f ] ” , c u r r e n t t i m e ) ;
switch ( code )
{
case 1 :
{
i f ( w l a n f l a g s −>c t s j a m m in g r e a d y )
p r i n t f ( ” %s − EMPIEZA JAMMING A CTS ( Llega RTS de o t r o nodo ) . \ n” ,
node name ) ;
e l s e i f ( w l a n f l a g s −>c t s j a m m i n g f i n i s h e d )
p r i n t f ( ” %s − Transmitiendo trama para Jamming a CTS . . . \ n” ,
node name ) ;
else
p r i n t f ( ” %s − TERMINA JAMMING A CTS . \ n” , node name ) ;
FOUT ;
}
case 2 :
46
6.2. Log de registro
{
i f ( w l a n f l a g s −>data jamming ready )
p r i n t f ( ” %s − EMPIEZA JAMMING A DATOS ( Llega CTS de o t r o
nodo ) . \ n” , node name ) ;
e l s e i f ( w l a n f l a g s −>d a t a j a m m i n g f i n i s h e d )
p r i n t f ( ” %s − Transmitiendo trama para Jamming a DATOS . . . \ n” ,
node name ) ;
else
p r i n t f ( ” %s − TERMINA JAMMING A DATOS. \ n” , node name ) ;
FOUT ;
}
case 3 :
{
i f ( w l a n f l a g s −>ack jamming ready )
p r i n t f ( ” %s − EMPIEZA JAMMING a ACK ( Llega trama de DATOS
de o t r o nodo ) . \ n” , node name ) ;
e l s e i f ( w l a n f l a g s −>a c k j a m m i n g f i n i s h e d )
p r i n t f ( ” %s − Transmitiendo trama para Jamming a ACK . . . \ n” ,
node name ) ;
else
p r i n t f ( ” %s − TERMINA JAMMING A ACK. \ n” , node name ) ;
FOUT ;
}
}
}
Listado 6.13: Función de registro de información de jamming en el log
La función wlan log print general info es la encargada de registrar en el log
los mensajes de información general (ver Listado 6.14). En este caso la función recibe
un parámetro que identificará el mensaje que debe imprimir y según donde se coloque la llamada a la función (mostrada en el Listado 6.15) el parámetro recibirá un
valor u otro. Las llamadas a esta función sólo se realizan si el usuario ha activado el
flag log ginfo desde la interfaz.
s t a t i c void w l a n l o g p r i n t g e n e r a l i n f o ( i n t code )
{
FIN ( w l a n l o g p r i n t g e n e r a l i n f o ( i n t ) ) ;
i f ( log time )
p r i n t f ( ”[ % l f ] ” , c u r r e n t t i m e ) ;
switch ( code )
{
case 1 :
p r i n t f ( ” %s − Transmitiendo DATOS . . . \ n” , node name ) ;
FOUT ;
case 2 :
p r i n t f ( ” %s − Transmitiendo RTS . . . \ n” , node name ) ;
FOUT ;
case 3 :
p r i n t f ( ” %s − R e t r a n s m i t i e n d o RTS ( por no r e c i b i r CTS ) . . . \ n” , node name ) ;
47
6. Implementación
FOUT ;
case 4 :
p r i n t f ( ” %s − R e t r a n s m i t i e n d o RTS ( por no r e c i b i r ACK ) . . . \ n” , node name ) ;
FOUT ;
case 5 :
p r i n t f ( ” %s − Va a comenzar B a c k o f f ( con CW a l minimo ) . Tiempo de
b a c k o f f = %l f . \ n” , node name , ( b a c k o f f s l o t s ∗ s l o t t i m e ) ) ;
FOUT ;
case 6 :
p r i n t f ( ” %s − Va a comenzar B a c k o f f ( con CW a l doble ) . Tiempo de
b a c k o f f = %l f . \ n” , node name , ( b a c k o f f s l o t s ∗ s l o t t i m e ) ) ;
FOUT ;
case 7 :
p r i n t f ( ” %s − Retoma B a c k o f f . Tiempo de b a c k o f f r e s t a n t e = %l f . \ n” ,
node name , ( b a c k o f f s l o t s ∗ s l o t t i m e ) ) ;
FOUT ;
case 8 :
p r i n t f ( ” %s − Termina b a c k o f f . \ n” , node name ) ;
FOUT ;
case 9 :
p r i n t f ( ” %s − B a c k o f f parado por r e c e p t o r ocupado . \ n” , node name ) ;
FOUT ;
case 1 0 :
p r i n t f ( ” %s − C o l i s i o n d e t e c t a d a . \ n” , node name ) ;
FOUT ;
case 1 1 :
p r i n t f ( ” %s − Transmitiendo ACK . . . \ n” , node name ) ;
FOUT ;
case 1 2 :
p r i n t f ( ” %s − Transmitiendo CTS . . . \ n” , node name ) ;
FOUT ;
case 1 3 :
p r i n t f ( ” %s − R e t r a n s m i t i e n d o DATOS ( por no r e c i b i r ACK ) . . . \ n” ,
node name ) ;
FOUT ;
case 1 4 :
p r i n t f ( ” %s − R e t r a n s m i t i e n d o DATOS . . . \ n” , node name ) ;
FOUT ;
case 1 5 :
p r i n t f ( ” %s − Trama de DATOS d e s c a r t a d a por e x c e s i v a s
r e t r a n s m i s i o n e s . \ n” , node name ) ;
FOUT ;
case 1 6 :
p r i n t f ( ” %s − Incremento d e l contador LRC por no r e c i b i r ACK
esperado . LRC= %i \n” , node name , l o n g r e t r y c o u n t ) ;
FOUT ;
case 1 7 :
p r i n t f ( ” %s − Incremento d e l contador SRC por no r e c i b i r CTS
esperado . SRC= %i \n” , node name , s h o r t r e t r y c o u n t ) ;
FOUT ; }
}
Listado 6.14: Función de registro de mensajes de información general en el log
48
6.2. Log de registro
if ( log ginfo )
wlan log print general info (11);
Listado 6.15: Llamada a función de registro de mensajes de información general
La función wlan log print state name imprimirá los nombres de los estados
por los que va pasando el nodo. Dado que los estados efectúan muchas transiciones a
sı́ mismos sólo se registrará en el log el nombre del estado cuando cambie, para evitar
que se imprima reiteradas veces el mismo nombre de estado.
Las llamadas a esta función se situarán dentro del código de cada estado del modelo de proceso wlan mac, y al igual que las funciones anteriores sólo se realiza la
llamada si el flag log sname ha sido activado por el usuario desde la interfaz.
s t a t i c void w l a n l o g p r i n t s t a t e n a m e ( )
{
FIN ( w l a n l o g p r i n t s t a t e n a m e ( ) ) ;
/ ∗ Imprime e l nombre d e l e s t a d o a c t u a l s i e s t e ha c a m b i a d o ∗ /
i f ( strcmp ( p r e v i o u s s t a t e n a m e , c u r r e n t s t a t e n a m e ) )
{
i f ( log time )
p r i n t f ( ”[ % l f ] ” , c u r r e n t t i m e ) ;
p r i n t f ( ” %s − Estado %s . \ n” , node name , c u r r e n t s t a t e n a m e ) ;
strcpy ( previous state name , current state name ) ; }
FOUT ;
}
Listado 6.16: Función de registro de nombre de estados en el log
Respecto al tiempo de ejecución, como puede verse en los Listados 6.13 6.14 y
6.16 de las tres funciones anteriores, se imprimirá delante de casa mensaje si el flag
log time ha sido activado por el usuario desde la interfaz.
Por último en el Listado 6.17 se muestra un fragmento del log obtenido para la
simulación de técnicas de jamming a tramas ACK en modo normal con perfil de tráfico de saturación (ver Sección 7.3.2.1). Se han marcado con flechas algunos mensajes
para identificar más fácilmente la información del proceso y efectos del jamming. En
este fragmento se muestran los mensajes desde el inicio de la simulación hasta que se
produce el descarte de la primera trama de datos por exceso de retransmisiones, que
tendrá lugar cuando el contador LRC (Long Retry Count) alcance el valor 4 correspondiente al lı́mite de transmisiones por trama.
En este ejemplo se recogen los mensajes de log de todos los tipos de información
(información general, de jamming, nombres de estados y tiempo de ejecución) para
todos los nodos, pero como ya se ha comentado podrı́a configurarse para que no se
muestren todos los tipos y ası́ poder centrarse en un tipo de información concreta.
49
6. Implementación
[0.000000]
[0.000000]
[0.000000]
[0.000000]
[0.000000]
[0.000000]
[0.000000]
[0.000000]
[0.000000]
[0.500000]
[0.500000]
[0.500000]
[0.500000]
[0.500352]
[0.500352]
[0.500666]
[0.500666]
[0.500666]
[0.500666]
[0.500666]
[0.500716]
[0.500716]
[0.500716]
[0.500716]
[0.500776]
[0.500776]
[0.500776]
[0.500776]
[0.501128]
[0.501128]
[0.501128]
[0.501138]
[0.501138]
[0.501442]
[0.501442]
[0.501452]
[0.501452]
[0.502409]
[0.502410]
[0.502420]
[0.502420]
[0.502724]
[0.502724]
[0.502774]
[0.502774]
[0.502774]
[0.502774]
[0.502894]
[0.502894]
50
n o d o t r − Estado INIT .
jammer − Estado INIT .
nodo rc − Estado INIT .
n o d o t r − Estado BSS INIT .
jammer − Estado BSS INIT .
nodo rc − Estado BSS INIT .
n o d o t r − Estado IDLE .
jammer − Estado IDLE .
nodo rc − Estado IDLE .
n o d o t r − Estado TRANSMIT .
n o d o t r − Transmitiendo RTS . . .
jammer − Estado TRANSMIT .
jammer − Transmitiendo RTS . . .
n o d o t r − Estado WAIT FOR RESPONSE .
jammer − Estado WAIT FOR RESPONSE .
nodo tr − Colision detectada .
n o d o t r − Incremento d e l contador SRC por no r e c i b i r
CTS esperado . SRC=1
n o d o t r − Estado DEFER .
jammer − C o l i s i o n d e t e c t a d a .
jammer − Estado DEFER .
n o d o t r − Va a comenzar B a c k o f f ( con CW a l doble ) .
Tiempo de b a c k o f f = 0 . 0 0 0 1 8 0 .
n o d o t r − Estado BACKOFF .
jammer − Va a comenzar B a c k o f f ( con CW a l doble ) .
Tiempo de b a c k o f f = 0 . 0 0 0 0 6 0 .
jammer − Estado BACKOFF .
jammer − Termina b a c k o f f .
jammer − Estado TRANSMIT .
jammer − R e t r a n s m i t i e n d o RTS ( por no r e c i b i r CTS ) . . .
n o d o t r − B a c k o f f parado por r e c e p t o r ocupado .
jammer − Estado WAIT FOR RESPONSE .
n o d o t r − Estado DEFER .
nodo rc − Estado DEFER .
nodo rc − Estado TRANSMIT .
nodo rc − Transmitiendo CTS . . .
nodo rc − Estado IDLE .
jammer − Estado DEFER .
jammer − Estado TRANSMIT .
jammer − Transmitiendo DATOS . . .
jammer − Estado WAIT FOR RESPONSE .
nodo rc − Estado DEFER .
nodo rc − Estado TRANSMIT .
nodo rc − Transmitiendo ACK . . .
nodo rc − Estado IDLE .
jammer − Estado DEFER .
jammer − Va a comenzar B a c k o f f ( con CW a l minimo ) .
Tiempo de b a c k o f f = 0 . 0 0 0 5 0 0 .
jammer − Estado BACKOFF .
n o d o t r − Retoma B a c k o f f . Tiempo de b a c k o f f r e s t a n t e = 0 . 0 0 0 1 2 0 .
n o d o t r − Estado BACKOFF .
n o d o t r − Termina b a c k o f f .
n o d o t r − Estado TRANSMIT .
6.2. Log de registro
[0.502894]
[0.502894]
[0.503246]
[0.503246]
[0.503246]
[0.503256]
[0.503256]
[0.503560]
[0.503560]
[0.503570]
[0.503570]
[0.504527]
[0.504527]
[0.504527]
[0.504537]
[0.504537]
[0.504537]
[0.504537]
[0.504841]
[0.504841]
[0.504841]
[0.504841]
[0.504841]
[0.504891]
[0.504891]
[0.505205]
[0.505205]
[0.505585]
[0.505585]
[0.505585]
[0.505585]
[0.505937]
[0.505937]
[0.505937]
[0.505947]
[0.505947]
[0.506251]
[0.506252]
[0.506262]
[0.506262]
[0.507219]
[0.507219]
[0.507229]
[0.507229]
[0.507533]
[0.507533]
[0.507583]
[0.507583]
[0.507583]
nodo tr
jammer
nodo tr
jammer
nodo rc
nodo rc
nodo rc
nodo rc
nodo tr
nodo tr
nodo tr
nodo tr
jammer
( Llega
nodo rc
jammer
jammer
nodo rc
nodo rc
jammer
jammer
nodo rc
nodo tr
por no
nodo tr
nodo tr
Tiempo
nodo tr
jammer
jammer
jammer
jammer
jammer
nodo tr
jammer
nodo tr
nodo rc
nodo rc
nodo rc
nodo rc
jammer
jammer
jammer
jammer
nodo rc
nodo rc
nodo rc
nodo rc
jammer
jammer
Tiempo
jammer
nodo tr
− R e t r a n s m i t i e n d o RTS ( por no r e c i b i r CTS ) . . .
− B a c k o f f parado por r e c e p t o r ocupado .
− Estado WAIT FOR RESPONSE .
− Estado DEFER .
− Estado DEFER .
− Estado TRANSMIT .
− Transmitiendo CTS . . .
− Estado IDLE .
− Estado DEFER .
− Estado TRANSMIT .
− R e t r a n s m i t i e n d o DATOS . . .
− Estado WAIT FOR RESPONSE .
− EMPIEZA JAMMING a ACK
<−−−−−
trama de DATOS de o t r o nodo ) .
− Estado DEFER .
− Estado TRANSMIT .
− Transmitiendo trama para Jamming a ACK . . .
− Estado TRANSMIT .
− Transmitiendo ACK . . .
− TERMINA JAMMING A ACK.
− Estado DEFER .
− Estado IDLE .
− Incremento d e l contador LRC
<−−−−−
r e c i b i r ACK esperado . LRC=1
− Estado DEFER .
− Va a comenzar B a c k o f f ( con CW a l doble ) .
<−−−−−
de b a c k o f f = 0 . 0 0 1 1 0 0 .
− Estado BACKOFF .
− Retoma B a c k o f f . Tiempo de b a c k o f f r e s t a n t e = 0 . 0 0 0 3 8 0 .
− Estado BACKOFF .
− Termina b a c k o f f .
− Estado TRANSMIT .
− Transmitiendo RTS . . .
− B a c k o f f parado por r e c e p t o r ocupado .
− Estado WAIT FOR RESPONSE .
− Estado DEFER .
− Estado DEFER .
− Estado TRANSMIT .
− Transmitiendo CTS . . .
− Estado IDLE .
− Estado DEFER .
− Estado TRANSMIT .
− Transmitiendo DATOS . . .
− Estado WAIT FOR RESPONSE .
− Estado DEFER .
− Estado TRANSMIT .
− Transmitiendo ACK . . .
− Estado IDLE .
− Estado DEFER .
− Va a comenzar B a c k o f f ( con CW a l minimo ) .
de b a c k o f f = 0 . 0 0 0 2 4 0 .
− Estado BACKOFF .
− Retoma B a c k o f f . Tiempo de b a c k o f f r e s t a n t e = 0 . 0 0 0 4 2 0 .
51
6. Implementación
[0.507583]
[0.507823]
[0.507823]
[0.507823]
[0.507823]
[0.508175]
[0.508175]
[0.508175]
[0.508185]
[0.508185]
[0.508489]
[0.508489]
[0.508499]
[0.508499]
[0.509456]
[0.509456]
[0.509466]
[0.509466]
[0.509770]
[0.509771]
[0.509821]
[0.509821]
[0.509821]
[0.509821]
[0.510001]
[0.510001]
[0.510001]
[0.510001]
[0.510353]
[0.510353]
[0.510353]
[0.510363]
[0.510363]
[0.510667]
[0.510667]
[0.510677]
[0.510677]
[0.511634]
[0.511634]
[0.511634]
[0.511644]
[0.511644]
[0.511644]
[0.511644]
[0.511948]
[0.511948]
[0.511948]
[0.511948]
[0.511948]
[0.511998]
52
n o d o t r − Estado BACKOFF .
jammer − Termina b a c k o f f .
jammer − Estado TRANSMIT .
jammer − Transmitiendo RTS . . .
n o d o t r − B a c k o f f parado por r e c e p t o r ocupado .
jammer − Estado WAIT FOR RESPONSE .
n o d o t r − Estado DEFER .
nodo rc − Estado DEFER .
nodo rc − Estado TRANSMIT .
nodo rc − Transmitiendo CTS . . .
nodo rc − Estado IDLE .
jammer − Estado DEFER .
jammer − Estado TRANSMIT .
jammer − Transmitiendo DATOS . . .
jammer − Estado WAIT FOR RESPONSE .
nodo rc − Estado DEFER .
nodo rc − Estado TRANSMIT .
nodo rc − Transmitiendo ACK . . .
nodo rc − Estado IDLE .
jammer − Estado DEFER .
jammer − Va a comenzar B a c k o f f ( con CW a l minimo ) .
Tiempo de b a c k o f f = 0 . 0 0 0 4 8 0 .
jammer − Estado BACKOFF .
n o d o t r − Retoma B a c k o f f . Tiempo de b a c k o f f r e s t a n t e = 0 . 0 0 0 1 8 0 .
n o d o t r − Estado BACKOFF .
n o d o t r − Termina b a c k o f f .
n o d o t r − Estado TRANSMIT .
n o d o t r − R e t r a n s m i t i e n d o RTS ( por no r e c i b i r ACK ) . . .
<−−−−−
jammer − B a c k o f f parado por r e c e p t o r ocupado .
n o d o t r − Estado WAIT FOR RESPONSE .
jammer − Estado DEFER .
nodo rc − Estado DEFER .
nodo rc − Estado TRANSMIT .
nodo rc − Transmitiendo CTS . . .
nodo rc − Estado IDLE .
n o d o t r − Estado DEFER .
n o d o t r − Estado TRANSMIT .
n o d o t r − R e t r a n s m i t i e n d o DATOS . . .
n o d o t r − Estado WAIT FOR RESPONSE .
jammer − EMPIEZA JAMMING a ACK
<−−−−−
Llega trama de DATOS de o t r o nodo ) .
nodo rc − Estado DEFER .
jammer − Estado TRANSMIT .
jammer − Transmitiendo trama para Jamming a ACK . . .
nodo rc − Estado TRANSMIT .
nodo rc − Transmitiendo ACK . . .
jammer − TERMINA JAMMING A ACK.
jammer − Estado DEFER .
nodo rc − Estado IDLE .
n o d o t r − Incremento d e l contador LRC
<−−−−−
por no r e c i b i r ACK esperado . LRC=2
n o d o t r − Estado DEFER .
n o d o t r − Va a comenzar B a c k o f f ( con CW a l doble ) .
<−−−−−
6.2. Log de registro
[0.511998]
[0.512312]
[0.512312]
[0.512612]
[0.512612]
[0.512612]
[0.512612]
[0.512964]
[0.512964]
[0.512964]
[0.512974]
[0.512974]
[0.513278]
[0.513278]
[0.513288]
[0.513288]
[0.514245]
[0.514246]
[0.514256]
[0.514256]
[0.514560]
[0.514560]
[0.514610]
[0.514610]
[0.514610]
[0.514610]
[0.514930]
[0.514930]
[0.514930]
[0.514930]
[0.515282]
[0.515282]
[0.515282]
[0.515292]
[0.515292]
[0.515596]
[0.515596]
[0.515606]
[0.515606]
[0.516563]
[0.516563]
[0.516573]
[0.516573]
[0.516877]
[0.516877]
[0.516927]
[0.516927]
[0.516927]
[0.516927]
[0.516967]
Tiempo
nodo tr
jammer
jammer
jammer
jammer
jammer
nodo tr
jammer
nodo tr
nodo rc
nodo rc
nodo rc
nodo rc
jammer
jammer
jammer
jammer
nodo rc
nodo rc
nodo rc
nodo rc
jammer
jammer
Tiempo
jammer
nodo tr
nodo tr
jammer
jammer
jammer
nodo tr
jammer
nodo tr
nodo rc
nodo rc
nodo rc
nodo rc
jammer
jammer
jammer
jammer
nodo rc
nodo rc
nodo rc
nodo rc
jammer
jammer
Tiempo
jammer
nodo tr
nodo tr
nodo tr
de b a c k o f f = 0 . 0 0 0 9 6 0 .
− Estado BACKOFF .
− Retoma B a c k o f f . Tiempo de b a c k o f f r e s t a n t e = 0 . 0 0 0 3 0 0 .
− Estado BACKOFF .
− Termina b a c k o f f .
− Estado TRANSMIT .
− Transmitiendo RTS . . .
− B a c k o f f parado por r e c e p t o r ocupado .
− Estado WAIT FOR RESPONSE .
− Estado DEFER .
− Estado DEFER .
− Estado TRANSMIT .
− Transmitiendo CTS . . .
− Estado IDLE .
− Estado DEFER .
− Estado TRANSMIT .
− Transmitiendo DATOS . . .
− Estado WAIT FOR RESPONSE .
− Estado DEFER .
− Estado TRANSMIT .
− Transmitiendo ACK . . .
− Estado IDLE .
− Estado DEFER .
− Va a comenzar B a c k o f f ( con CW a l minimo ) .
de b a c k o f f = 0 . 0 0 0 3 2 0 .
− Estado BACKOFF .
− Retoma B a c k o f f . Tiempo de b a c k o f f r e s t a n t e = 0 . 0 0 0 3 6 0 .
− Estado BACKOFF .
− Termina b a c k o f f .
− Estado TRANSMIT .
− Transmitiendo RTS . . .
− B a c k o f f parado por r e c e p t o r ocupado .
− Estado WAIT FOR RESPONSE .
− Estado DEFER .
− Estado DEFER .
− Estado TRANSMIT .
− Transmitiendo CTS . . .
− Estado IDLE .
− Estado DEFER .
− Estado TRANSMIT .
− Transmitiendo DATOS . . .
− Estado WAIT FOR RESPONSE .
− Estado DEFER .
− Estado TRANSMIT .
− Transmitiendo ACK . . .
− Estado IDLE .
− Estado DEFER .
− Va a comenzar B a c k o f f ( con CW a l minimo ) .
de b a c k o f f = 0 . 0 0 0 0 6 0 .
− Estado BACKOFF .
− Retoma B a c k o f f . Tiempo de b a c k o f f r e s t a n t e = 0 . 0 0 0 0 4 0 .
− Estado BACKOFF .
− Termina b a c k o f f .
53
6. Implementación
[0.516967]
[0.516967]
[0.516967]
[0.517319]
[0.517319]
[0.517319]
[0.517329]
[0.517329]
[0.517633]
[0.517634]
[0.517644]
[0.517644]
[0.518601]
[0.518601]
[0.518601]
[0.518611]
[0.518611]
[0.518611]
[0.518611]
[0.518915]
[0.518915]
[0.518915]
[0.518915]
[0.518915]
[0.518965]
[0.518965]
[0.519279]
[0.519279]
[0.519299]
[0.519299]
[0.519299]
[0.519299]
[0.519651]
[0.519651]
[0.519651]
[0.519661]
[0.519661]
[0.519965]
[0.519965]
[0.519975]
[0.519975]
[0.520932]
[0.520932]
[0.520942]
[0.520942]
[0.521246]
[0.521247]
[0.521297]
[0.521297]
54
nodo tr
nodo tr
jammer
nodo tr
jammer
nodo rc
nodo rc
nodo rc
nodo rc
nodo tr
nodo tr
nodo tr
nodo tr
jammer
( Llega
nodo rc
jammer
jammer
nodo rc
nodo rc
jammer
jammer
nodo rc
nodo tr
por no
nodo tr
nodo tr
Tiempo
nodo tr
jammer
jammer
jammer
jammer
jammer
nodo tr
jammer
nodo tr
nodo rc
nodo rc
nodo rc
nodo rc
jammer
jammer
jammer
jammer
nodo rc
nodo rc
nodo rc
nodo rc
jammer
jammer
Tiempo
jammer
− Estado TRANSMIT .
− R e t r a n s m i t i e n d o RTS ( por no r e c i b i r ACK ) . . .
<−−−−−
− B a c k o f f parado por r e c e p t o r ocupado .
− Estado WAIT FOR RESPONSE .
− Estado DEFER .
− Estado DEFER .
− Estado TRANSMIT .
− Transmitiendo CTS . . .
− Estado IDLE .
− Estado DEFER .
− Estado TRANSMIT .
− R e t r a n s m i t i e n d o DATOS . . .
− Estado WAIT FOR RESPONSE .
− EMPIEZA JAMMING a ACK
<−−−−−
trama de DATOS de o t r o nodo ) .
− Estado DEFER .
− Estado TRANSMIT .
− Transmitiendo trama para Jamming a ACK . . .
− Estado TRANSMIT .
− Transmitiendo ACK . . .
− TERMINA JAMMING A ACK.
− Estado DEFER .
− Estado IDLE .
− Incremento d e l contador LRC
<−−−−−
r e c i b i r ACK esperado . LRC=3
− Estado DEFER .
− Va a comenzar B a c k o f f ( con CW a l doble ) .
<−−−−−
de b a c k o f f = 0 . 0 0 5 1 8 0 .
− Estado BACKOFF .
− Retoma B a c k o f f . Tiempo de b a c k o f f r e s t a n t e = 0 . 0 0 0 0 2 0 .
− Estado BACKOFF .
− Termina b a c k o f f .
− Estado TRANSMIT .
− Transmitiendo RTS . . .
− B a c k o f f parado por r e c e p t o r ocupado .
− Estado WAIT FOR RESPONSE .
− Estado DEFER .
− Estado DEFER .
− Estado TRANSMIT .
− Transmitiendo CTS . . .
− Estado IDLE .
− Estado DEFER .
− Estado TRANSMIT .
− Transmitiendo DATOS . . .
− Estado WAIT FOR RESPONSE .
− Estado DEFER .
− Estado TRANSMIT .
− Transmitiendo ACK . . .
− Estado IDLE .
− Estado DEFER .
− Va a comenzar B a c k o f f ( con CW a l minimo ) .
de b a c k o f f = 0 . 0 0 0 5 4 0 .
− Estado BACKOFF .
6.2. Log de registro
[0.521297]
[0.521297]
[0.521837]
[0.521837]
[0.521837]
[0.521837]
[0.522189]
[0.522189]
[0.522189]
[0.522199]
[0.522199]
[0.522503]
[0.522503]
[0.522513]
[0.522513]
[0.523470]
[0.523470]
[0.523480]
[0.523480]
[0.523784]
[0.523784]
[0.523834]
[0.523834]
[0.523834]
[0.523834]
[0.524294]
[0.524294]
[0.524294]
[0.524294]
[0.524646]
[0.524646]
[0.524646]
[0.524656]
[0.524656]
[0.524960]
[0.524960]
[0.524970]
[0.524970]
[0.525927]
[0.525928]
[0.525938]
[0.525938]
[0.526242]
[0.526242]
[0.526292]
[0.526292]
[0.526292]
[0.526292]
[0.526752]
[0.526752]
[0.526752]
nodo tr
nodo tr
jammer
jammer
jammer
nodo tr
jammer
nodo tr
nodo rc
nodo rc
nodo rc
nodo rc
jammer
jammer
jammer
jammer
nodo rc
nodo rc
nodo rc
nodo rc
jammer
jammer
Tiempo
jammer
nodo tr
nodo tr
jammer
jammer
jammer
nodo tr
jammer
nodo tr
nodo rc
nodo rc
nodo rc
nodo rc
jammer
jammer
jammer
jammer
nodo rc
nodo rc
nodo rc
nodo rc
jammer
jammer
Tiempo
jammer
nodo tr
nodo tr
jammer
jammer
jammer
− Retoma B a c k o f f . Tiempo de b a c k o f f r e s t a n t e = 0 . 0 0 4 8 6 0 .
− Estado BACKOFF .
− Termina b a c k o f f .
− Estado TRANSMIT .
− Transmitiendo RTS . . .
− B a c k o f f parado por r e c e p t o r ocupado .
− Estado WAIT FOR RESPONSE .
− Estado DEFER .
− Estado DEFER .
− Estado TRANSMIT .
− Transmitiendo CTS . . .
− Estado IDLE .
− Estado DEFER .
− Estado TRANSMIT .
− Transmitiendo DATOS . . .
− Estado WAIT FOR RESPONSE .
− Estado DEFER .
− Estado TRANSMIT .
− Transmitiendo ACK . . .
− Estado IDLE .
− Estado DEFER .
− Va a comenzar B a c k o f f ( con CW a l minimo ) .
de b a c k o f f = 0 . 0 0 0 4 6 0 .
− Estado BACKOFF .
− Retoma B a c k o f f . Tiempo de b a c k o f f r e s t a n t e = 0 . 0 0 4 3 2 0 .
− Estado BACKOFF .
− Termina b a c k o f f .
− Estado TRANSMIT .
− Transmitiendo RTS . . .
− B a c k o f f parado por r e c e p t o r ocupado .
− Estado WAIT FOR RESPONSE .
− Estado DEFER .
− Estado DEFER .
− Estado TRANSMIT .
− Transmitiendo CTS . . .
− Estado IDLE .
− Estado DEFER .
− Estado TRANSMIT .
− Transmitiendo DATOS . . .
− Estado WAIT FOR RESPONSE .
− Estado DEFER .
− Estado TRANSMIT .
− Transmitiendo ACK . . .
− Estado IDLE .
− Estado DEFER .
− Va a comenzar B a c k o f f ( con CW a l minimo ) .
de b a c k o f f = 0 . 0 0 0 4 6 0 .
− Estado BACKOFF .
− Retoma B a c k o f f . Tiempo de b a c k o f f r e s t a n t e = 0 . 0 0 3 8 6 0 .
− Estado BACKOFF .
− Termina b a c k o f f .
− Estado TRANSMIT .
− Transmitiendo RTS . . .
55
6. Implementación
[0.526752]
[0.527104]
[0.527104]
[0.527104]
[0.527114]
[0.527114]
[0.527418]
[0.527418]
[0.527428]
[0.527428]
[0.528385]
[0.528385]
[0.528395]
[0.528395]
[0.528699]
[0.528699]
[0.528749]
[0.528749]
[0.528749]
[0.528749]
[0.528889]
[0.528889]
[0.528889]
[0.528889]
[0.529241]
[0.529241]
[0.529251]
[0.529251]
[0.529555]
[0.529556]
[0.529566]
[0.529566]
[0.530523]
[0.530523]
[0.530533]
[0.530533]
[0.530837]
[0.530837]
[0.530887]
[0.530887]
[0.530887]
[0.530887]
[0.531487]
[0.531487]
[0.531487]
[0.531487]
[0.531839]
[0.531839]
[0.531839]
[0.531849]
[0.531849]
56
nodo tr
jammer
nodo tr
nodo rc
nodo rc
nodo rc
nodo rc
jammer
jammer
jammer
jammer
nodo rc
nodo rc
nodo rc
nodo rc
jammer
jammer
Tiempo
jammer
nodo tr
nodo tr
jammer
jammer
jammer
nodo tr
jammer
nodo tr
nodo rc
nodo rc
nodo rc
jammer
jammer
jammer
jammer
nodo rc
nodo rc
nodo rc
nodo rc
jammer
jammer
Tiempo
jammer
nodo tr
nodo tr
jammer
jammer
jammer
nodo tr
jammer
nodo tr
nodo rc
nodo rc
nodo rc
− B a c k o f f parado por r e c e p t o r ocupado .
− Estado WAIT FOR RESPONSE .
− Estado DEFER .
− Estado DEFER .
− Estado TRANSMIT .
− Transmitiendo CTS . . .
− Estado IDLE .
− Estado DEFER .
− Estado TRANSMIT .
− Transmitiendo DATOS . . .
− Estado WAIT FOR RESPONSE .
− Estado DEFER .
− Estado TRANSMIT .
− Transmitiendo ACK . . .
− Estado IDLE .
− Estado DEFER .
− Va a comenzar B a c k o f f ( con CW a l minimo ) .
de b a c k o f f = 0 . 0 0 0 1 4 0 .
− Estado BACKOFF .
− Retoma B a c k o f f . Tiempo de b a c k o f f r e s t a n t e = 0 . 0 0 3 4 0 0 .
− Estado BACKOFF .
− Termina b a c k o f f .
− Estado TRANSMIT .
− Transmitiendo RTS . . .
− B a c k o f f parado por r e c e p t o r ocupado .
− Estado WAIT FOR RESPONSE .
− Estado DEFER .
− Estado TRANSMIT .
− Transmitiendo CTS . . .
− Estado IDLE .
− Estado DEFER .
− Estado TRANSMIT .
− Transmitiendo DATOS . . .
− Estado WAIT FOR RESPONSE .
− Estado DEFER .
− Estado TRANSMIT .
− Transmitiendo ACK . . .
− Estado IDLE .
− Estado DEFER .
− Va a comenzar B a c k o f f ( con CW a l minimo ) .
de b a c k o f f = 0 . 0 0 0 6 0 0 .
− Estado BACKOFF .
− Retoma B a c k o f f . Tiempo de b a c k o f f r e s t a n t e = 0 . 0 0 3 2 6 0 .
− Estado BACKOFF .
− Termina b a c k o f f .
− Estado TRANSMIT .
− Transmitiendo RTS . . .
− B a c k o f f parado por r e c e p t o r ocupado .
− Estado WAIT FOR RESPONSE .
− Estado DEFER .
− Estado DEFER .
− Estado TRANSMIT .
− Transmitiendo CTS . . .
6.2. Log de registro
[0.532153]
[0.532153]
[0.532163]
[0.532163]
[0.533120]
[0.533120]
[0.533130]
[0.533130]
[0.533434]
[0.533435]
[0.533485]
[0.533485]
[0.533485]
[0.533485]
[0.533525]
[0.533525]
[0.533525]
[0.533525]
[0.533877]
[0.533877]
[0.533877]
[0.533887]
[0.533887]
[0.534191]
[0.534191]
[0.534201]
[0.534201]
[0.535158]
[0.535158]
[0.535168]
[0.535168]
[0.535472]
[0.535472]
[0.535522]
[0.535522]
[0.535522]
[0.535522]
[0.535862]
[0.535862]
[0.535862]
[0.535862]
[0.536214]
[0.536214]
[0.536214]
[0.536224]
[0.536224]
[0.536528]
[0.536528]
[0.536538]
[0.536538]
[0.537496]
nodo rc
jammer
jammer
jammer
jammer
nodo rc
nodo rc
nodo rc
nodo rc
jammer
jammer
Tiempo
jammer
nodo tr
nodo tr
jammer
jammer
jammer
nodo tr
jammer
nodo tr
nodo rc
nodo rc
nodo rc
nodo rc
jammer
jammer
jammer
jammer
nodo rc
nodo rc
nodo rc
nodo rc
jammer
jammer
Tiempo
jammer
nodo tr
nodo tr
jammer
jammer
jammer
nodo tr
jammer
nodo tr
nodo rc
nodo rc
nodo rc
nodo rc
jammer
jammer
jammer
jammer
− Estado IDLE .
− Estado DEFER .
− Estado TRANSMIT .
− Transmitiendo DATOS . . .
− Estado WAIT FOR RESPONSE .
− Estado DEFER .
− Estado TRANSMIT .
− Transmitiendo ACK . . .
− Estado IDLE .
− Estado DEFER .
− Va a comenzar B a c k o f f ( con CW a l minimo ) .
de b a c k o f f = 0 . 0 0 0 0 4 0 .
− Estado BACKOFF .
− Retoma B a c k o f f . Tiempo de b a c k o f f r e s t a n t e = 0 . 0 0 2 6 6 0 .
− Estado BACKOFF .
− Termina b a c k o f f .
− Estado TRANSMIT .
− Transmitiendo RTS . . .
− B a c k o f f parado por r e c e p t o r ocupado .
− Estado WAIT FOR RESPONSE .
− Estado DEFER .
− Estado DEFER .
− Estado TRANSMIT .
− Transmitiendo CTS . . .
− Estado IDLE .
− Estado DEFER .
− Estado TRANSMIT .
− Transmitiendo DATOS . . .
− Estado WAIT FOR RESPONSE .
− Estado DEFER .
− Estado TRANSMIT .
− Transmitiendo ACK . . .
− Estado IDLE .
− Estado DEFER .
− Va a comenzar B a c k o f f ( con CW a l minimo ) .
de b a c k o f f = 0 . 0 0 0 3 4 0 .
− Estado BACKOFF .
− Retoma B a c k o f f . Tiempo de b a c k o f f r e s t a n t e = 0 . 0 0 2 6 2 0 .
− Estado BACKOFF .
− Termina b a c k o f f .
− Estado TRANSMIT .
− Transmitiendo RTS . . .
− B a c k o f f parado por r e c e p t o r ocupado .
− Estado WAIT FOR RESPONSE .
− Estado DEFER .
− Estado DEFER .
− Estado TRANSMIT .
− Transmitiendo CTS . . .
− Estado IDLE .
− Estado DEFER .
− Estado TRANSMIT .
− Transmitiendo DATOS . . .
− Estado WAIT FOR RESPONSE .
57
6. Implementación
[0.537496]
[0.537506]
[0.537506]
[0.537810]
[0.537810]
[0.537860]
[0.537860]
[0.537860]
[0.537860]
[0.538360]
[0.538360]
[0.538360]
[0.538360]
[0.538712]
[0.538712]
[0.538712]
[0.538722]
[0.538722]
[0.539026]
[0.539026]
[0.539036]
[0.539036]
[0.539993]
[0.539993]
[0.540003]
[0.540003]
[0.540307]
[0.540307]
[0.540357]
[0.540357]
[0.540357]
[0.540357]
[0.540457]
[0.540457]
[0.540457]
[0.540457]
[0.540809]
[0.540809]
[0.540809]
[0.540819]
[0.540819]
[0.541123]
[0.541124]
[0.541134]
[0.541134]
[0.542091]
[0.542091]
[0.542101]
[0.542101]
[0.542405]
[0.542405]
58
nodo rc
nodo rc
nodo rc
nodo rc
jammer
jammer
Tiempo
jammer
nodo tr
nodo tr
jammer
jammer
jammer
nodo tr
jammer
nodo tr
nodo rc
nodo rc
nodo rc
nodo rc
jammer
jammer
jammer
jammer
nodo rc
nodo rc
nodo rc
nodo rc
jammer
jammer
Tiempo
jammer
nodo tr
nodo tr
jammer
jammer
jammer
nodo tr
jammer
nodo tr
nodo rc
nodo rc
nodo rc
nodo rc
jammer
jammer
jammer
jammer
nodo rc
nodo rc
nodo rc
nodo rc
jammer
− Estado DEFER .
− Estado TRANSMIT .
− Transmitiendo ACK . . .
− Estado IDLE .
− Estado DEFER .
− Va a comenzar B a c k o f f ( con CW a l minimo ) .
de b a c k o f f = 0 . 0 0 0 5 0 0 .
− Estado BACKOFF .
− Retoma B a c k o f f . Tiempo de b a c k o f f r e s t a n t e = 0 . 0 0 2 2 8 0 .
− Estado BACKOFF .
− Termina b a c k o f f .
− Estado TRANSMIT .
− Transmitiendo RTS . . .
− B a c k o f f parado por r e c e p t o r ocupado .
− Estado WAIT FOR RESPONSE .
− Estado DEFER .
− Estado DEFER .
− Estado TRANSMIT .
− Transmitiendo CTS . . .
− Estado IDLE .
− Estado DEFER .
− Estado TRANSMIT .
− Transmitiendo DATOS . . .
− Estado WAIT FOR RESPONSE .
− Estado DEFER .
− Estado TRANSMIT .
− Transmitiendo ACK . . .
− Estado IDLE .
− Estado DEFER .
− Va a comenzar B a c k o f f ( con CW a l minimo ) .
de b a c k o f f = 0 . 0 0 0 1 0 0 .
− Estado BACKOFF .
− Retoma B a c k o f f . Tiempo de b a c k o f f r e s t a n t e = 0 . 0 0 1 7 8 0 .
− Estado BACKOFF .
− Termina b a c k o f f .
− Estado TRANSMIT .
− Transmitiendo RTS . . .
− B a c k o f f parado por r e c e p t o r ocupado .
− Estado WAIT FOR RESPONSE .
− Estado DEFER .
− Estado DEFER .
− Estado TRANSMIT .
− Transmitiendo CTS . . .
− Estado IDLE .
− Estado DEFER .
− Estado TRANSMIT .
− Transmitiendo DATOS . . .
− Estado WAIT FOR RESPONSE .
− Estado DEFER .
− Estado TRANSMIT .
− Transmitiendo ACK . . .
− Estado IDLE .
− Estado DEFER .
6.2. Log de registro
[0.542455]
[0.542455]
[0.542455]
[0.542455]
[0.543015]
[0.543015]
[0.543015]
[0.543015]
[0.543367]
[0.543367]
[0.543367]
[0.543377]
[0.543377]
[0.543681]
[0.543681]
[0.543691]
[0.543691]
[0.544648]
[0.544648]
[0.544658]
[0.544658]
[0.544962]
[0.544963]
[0.545013]
[0.545013]
[0.545013]
[0.545013]
[0.545213]
[0.545213]
[0.545213]
[0.545213]
[0.545565]
[0.545565]
[0.545565]
[0.545575]
[0.545575]
[0.545879]
[0.545879]
[0.545889]
[0.545889]
[0.546846]
[0.546846]
[0.546856]
[0.546856]
[0.547160]
[0.547160]
[0.547210]
[0.547210]
[0.547210]
[0.547210]
jammer
Tiempo
jammer
nodo tr
nodo tr
jammer
jammer
jammer
nodo tr
jammer
nodo tr
nodo rc
nodo rc
nodo rc
nodo rc
jammer
jammer
jammer
jammer
nodo rc
nodo rc
nodo rc
nodo rc
jammer
jammer
Tiempo
jammer
nodo tr
nodo tr
jammer
jammer
jammer
nodo tr
jammer
nodo tr
nodo rc
nodo rc
nodo rc
nodo rc
jammer
jammer
jammer
jammer
nodo rc
nodo rc
nodo rc
nodo rc
jammer
jammer
Tiempo
jammer
nodo tr
nodo tr
− Va a comenzar B a c k o f f ( con CW a l minimo ) .
de b a c k o f f = 0 . 0 0 0 5 6 0 .
− Estado BACKOFF .
− Retoma B a c k o f f . Tiempo de b a c k o f f r e s t a n t e = 0 . 0 0 1 6 8 0 .
− Estado BACKOFF .
− Termina b a c k o f f .
− Estado TRANSMIT .
− Transmitiendo RTS . . .
− B a c k o f f parado por r e c e p t o r ocupado .
− Estado WAIT FOR RESPONSE .
− Estado DEFER .
− Estado DEFER .
− Estado TRANSMIT .
− Transmitiendo CTS . . .
− Estado IDLE .
− Estado DEFER .
− Estado TRANSMIT .
− Transmitiendo DATOS . . .
− Estado WAIT FOR RESPONSE .
− Estado DEFER .
− Estado TRANSMIT .
− Transmitiendo ACK . . .
− Estado IDLE .
− Estado DEFER .
− Va a comenzar B a c k o f f ( con CW a l minimo ) .
de b a c k o f f = 0 . 0 0 0 2 0 0 .
− Estado BACKOFF .
− Retoma B a c k o f f . Tiempo de b a c k o f f r e s t a n t e = 0 . 0 0 1 1 2 0 .
− Estado BACKOFF .
− Termina b a c k o f f .
− Estado TRANSMIT .
− Transmitiendo RTS . . .
− B a c k o f f parado por r e c e p t o r ocupado .
− Estado WAIT FOR RESPONSE .
− Estado DEFER .
− Estado DEFER .
− Estado TRANSMIT .
− Transmitiendo CTS . . .
− Estado IDLE .
− Estado DEFER .
− Estado TRANSMIT .
− Transmitiendo DATOS . . .
− Estado WAIT FOR RESPONSE .
− Estado DEFER .
− Estado TRANSMIT .
− Transmitiendo ACK . . .
− Estado IDLE .
− Estado DEFER .
− Va a comenzar B a c k o f f ( con CW a l minimo ) .
de b a c k o f f = 0 . 0 0 0 6 2 0 .
− Estado BACKOFF .
− Retoma B a c k o f f . Tiempo de b a c k o f f r e s t a n t e = 0 . 0 0 0 9 2 0 .
− Estado BACKOFF .
59
6. Implementación
[0.547830]
[0.547830]
[0.547830]
[0.547830]
[0.548182]
[0.548182]
[0.548182]
[0.548192]
[0.548192]
[0.548496]
[0.548496]
[0.548506]
[0.548506]
[0.549464]
[0.549464]
[0.549474]
[0.549474]
[0.549778]
[0.549778]
[0.549828]
[0.549828]
[0.549828]
[0.549828]
[0.550128]
[0.550128]
[0.550128]
[0.550128]
[0.550480]
[0.550480]
[0.550480]
[0.550490]
[0.550490]
[0.550794]
[0.550794]
[0.550804]
[0.550804]
[0.551761]
[0.551761]
[0.551761]
[0.551771]
[0.551771]
[0.551771]
[0.551771]
[0.552075]
[0.552075]
[0.552075]
[0.552075]
[0.552075]
jammer
jammer
jammer
nodo tr
jammer
nodo tr
nodo rc
nodo rc
nodo rc
nodo rc
jammer
jammer
jammer
jammer
nodo rc
nodo rc
nodo rc
nodo rc
jammer
jammer
Tiempo
jammer
nodo tr
nodo tr
nodo tr
nodo tr
nodo tr
jammer
nodo tr
jammer
nodo rc
nodo rc
nodo rc
nodo rc
nodo tr
nodo tr
nodo tr
nodo tr
jammer
( Llega
nodo rc
jammer
jammer
nodo rc
nodo rc
jammer
jammer
nodo rc
nodo tr
por no
nodo tr
− Termina b a c k o f f .
− Estado TRANSMIT .
− Transmitiendo RTS . . .
− B a c k o f f parado por r e c e p t o r ocupado .
− Estado WAIT FOR RESPONSE .
− Estado DEFER .
− Estado DEFER .
− Estado TRANSMIT .
− Transmitiendo CTS . . .
− Estado IDLE .
− Estado DEFER .
− Estado TRANSMIT .
− Transmitiendo DATOS . . .
− Estado WAIT FOR RESPONSE .
− Estado DEFER .
− Estado TRANSMIT .
− Transmitiendo ACK . . .
− Estado IDLE .
− Estado DEFER .
− Va a comenzar B a c k o f f ( con CW a l minimo ) .
de b a c k o f f = 0 . 0 0 0 4 4 0 .
− Estado BACKOFF .
− Retoma B a c k o f f . Tiempo de b a c k o f f r e s t a n t e = 0 . 0 0 0 3 0 0 .
− Estado BACKOFF .
− Termina b a c k o f f .
− Estado TRANSMIT .
− R e t r a n s m i t i e n d o RTS ( por no r e c i b i r ACK ) . . .
− B a c k o f f parado por r e c e p t o r ocupado .
− Estado WAIT FOR RESPONSE .
− Estado DEFER .
− Estado DEFER .
− Estado TRANSMIT .
− Transmitiendo CTS . . .
− Estado IDLE .
− Estado DEFER .
− Estado TRANSMIT .
− R e t r a n s m i t i e n d o DATOS . . .
− Estado WAIT FOR RESPONSE .
− EMPIEZA JAMMING a ACK
<−−−−−
trama de DATOS de o t r o nodo ) .
− Estado DEFER .
− Estado TRANSMIT .
− Transmitiendo trama para Jamming a ACK . . .
− Estado TRANSMIT .
− Transmitiendo ACK . . .
− TERMINA JAMMING A ACK.
− Estado DEFER .
− Estado IDLE .
− Incremento d e l contador LRC
<−−−−−
r e c i b i r ACK esperado . LRC=4
− Trama de DATOS d e s c a r t a d a por e x c e s i v a s r e t r a n s m i s i o n e s .
Listado 6.17: Ejemplo de fragmento del log
60
CAPÍTULO
7
EVALUACIÓN DE LOS ATAQUES
En este capı́tulo se va a detallar la información referente a la experimentación con
los ataques mediante técnicas de jamming implementados. En primer lugar se explicará la configuración de los escenarios que se han diseñado para ejecutar las simulaciones, definiendo los roles, atributos y perfiles de tráfico de los nodos de la red.
Después se describirá la estrategia de evaluación que se usa para realizar las pruebas
y obtener resultados. Por último se analizan los resultados obtenidos.
7.1.
Configuración de los escenarios
En esta sección se van a describir los detalles de la configuración de los escenarios
que se han diseñado para la ejecución de las simulaciones. A continuación se comentarán los escenarios definidos, los roles y atributos de los nodos presentes en ellos y
los perfiles de tráfico usados en las simulaciones.
7.1.1.
Escenarios y roles de los nodos
Para la experimentación se han definido dos escenarios, un escenario de jamming
y un escenario normal de referencia.
En el escenario de jamming se realizarán las simulaciones de los ataques mediante
técnicas de jamming implementados para este proyecto. Este escenario es el mostrado
en la Figura 7.1 y consta de tres nodos:
- jammer: nodo que puede transmitir datos y realizar jamming.
- nodo tr: nodo que transmite datos y “sufre” las consecuencias del jamming.
61
7. Evaluación de los ataques
- nodo rc: nodo que recibe las transmisiones de datos de los dos anteriores.
El escenario normal tiene como objetivo servir de marco de referencia para comparar sus resultados con los obtenidos en el escenario de jamming. Este escenario será por
tanto similar al anterior excepto por el hecho de que ninguno de sus nodos realiza
jamming, es decir, todos los nodos se comportarán siguiendo el estándar 802.11. El
escenario normal es el mostrado en la figura 7.2 y consta de tres nodos de los cuales normal tr y normal tr2 transmiten ambos al mismo destino, normal rc. En
el análisis de resultados se emplearán en algunos casos las estadı́sticas recogidas en
normal tr para compararlas con los nodos nodo tr y jammer del escenario de jamming y ası́ poder estudiar cuánto se diferencian estos dos últimos del comportamiento
estándar.
Figura 7.1: Escenario de jamming
Figura 7.2: Escenario normal
62
7.1. Configuración de los escenarios
Los escenarios sobre los que se realizan las simulaciones son los ya descritos. Se
han diseñado con tres nodos para cubrir el mı́nimo número de roles necesarios para
la demostración de los ataques. Con otras configuraciones, con mayor número de nodos e incluyendo un nodo con función de punto de acceso, se ha comprobado que se
obtienen resultados similares y no se aporta nada nuevo a la experimentación.
7.1.2.
Atributos de los nodos
Como se comentó en la Sección 4.1 el modelo de los nodos es de tipo wlan station adv.
Cada nodo dispone de una serie de atributos que le van proporcionando los procesos
de los que está compuesto. Estos atributos se exportan al nivel del nodo para que se
puedan configurar desde el escenario.
A continuación se explicarán los atributos más significativos de los nodos y se justificarán los valores que se les han asignado para las ejecuciones de las simulaciones.
Parámetros generales: parámetros propios del nodo (ver Tabla 7.1).
- Nombre (Name): representan el nombre del nodo.
- Modelo (Model): modelo de nodo que implementa.
- Dirección de destino (Destination Address): es la dirección MAC de la estación a la que se enviarán las tramas desde este nodo. En el escenario de jamming los nodos jammer y nodo tr tendrán este atributo al valor de la dirección MAC del nodo rc definida en su atributo Wireless LAN MAC Addresss.
Ası́ mismo en el escenario normal los nodos normal tr y normal tr2
tendrán este atributo al valor de la dirección MAC del nodo normal rc
que al igual que el caso anterior está definida por su atributo Wireless LAN
MAC Addresss.
Tabla 7.1: Atributos del nodo: parámetros generales
Parámetros de jamming (CTS Jamming, Data Jamming y ACK Jamming): la utilidad
de generación de jamming ha sido desarrollada especı́ficamente para este proyecto. Estos parámetros (ver Tabla 7.2) permiten inhabilitar o elegir entre cada uno
de los tipos de jamming implementados seleccionando un modo (descripción de
los modos en Sección 5.1.2), que podrá ser uno de los siguientes:
- Inhabilitado (Disabled): el nodo no realiza jamming y se comportará según
el estándar.
63
7. Evaluación de los ataques
- Normal (Normal): el nodo realiza el jamming sólo cuando tenga datos esperando para ser enviados.
- Continuo (Continuous): el nodo realiza el jamming siempre, aunque no tenga
información que enviar.
- Aleatorio (Random): se realizará jamming en modo normal pero sólo en algunas ocasiones. Para esto se obtiene un número aleatorio a partir de una
distribución uniforme entre 0 y 1 y si es menor que el valor introducido para el parámetro de jamming aleatorio (Random CTS Jamming, Random DATA
Jamming o Random ACK Jamming según el tipo) se realiza el jamming.
Tabla 7.2: Atributos del nodo: parámetros de jamming
Parámetros de log (Log Parameters): la utilidad de generación de logs también ha
sido desarrollada para este proyecto. Los parámetros son los mostrados en la Tabla 7.3, cada uno de ellos habilita que se registre en el log un tipo de información
(ver descripción de los tipos en Sección 5.2), como puede ser:
- Tiempo de ejecución (Execution Time): muestra, antes de todos los demás
mensajes de log, el momento de la ejecución en que se están produciendo.
- Información general (General Info): registra en el log mensajes de información general, tales como envı́o de tramas, incremento de contadores de retransmisiones, descarte de tramas, etc.
- Nombres de estado (State Names): añade al log los nombres de los estados
por los que pasa el nodo durante la simulación.
- Información de jamming (Jamming Info): si el nodo está realizando jamming
se imprimen mensajes de información, que pueden ser: comienzo de jamming, envı́o de trama para jamming y fin de jamming.
64
7.1. Configuración de los escenarios
Tabla 7.3: Atributos del nodo: parámetros de log
Parámetros de generación de tráfico (Traffic Generation Parameters): permitirán
configurar el ritmo de generación de paquetes por las capas superiores. Los atributos y valores asignados pueden verse en la Tabla 7.4 y se definen a continuación:
- Tiempo de comienzo (Start Time): indica en qué momento de la ejecución
se comenzará a generar paquetes. Estará fijo para todos los nodos de las
simulaciones a 0,5 segundos, excepto en el caso de que se desee un perfil de
tráfico de no transmisión (ver Sección 7.1.3).
- Tiempo de actividad (ON State Time): tiempo durante el que la generación
de tráfico estará activa. Para todas las simulaciones estará a cualquier valor
mayor que el tiempo de simulación, para que siempre esté activa.
- Tiempo de no actividad (OFF State Time): tiempo en que la generación de
tráfico no está activa. Para todas las simulaciones estará a valor 0.
- Tiempo entre llegadas (Interarrival Time): representa el tiempo entre generaciones sucesivas de paquetes. Este valor se irá modificando según el perfil
de tráfico deseado (ver Sección 7.1.3).
- Tamaño de paquete (Packet Size): es el tamaño en Bytes que tendrán los
paquetes que se generen. Para todas las simulaciones se mantendrá a 1024
Bytes.
- Tamaño de segmentación (Segmentation Size): si los paquetes generados superan este número de Bytes se enviarán fragmentados. Para todas las simulaciones se ha fijado para que no se realice segmentación.
- Tiempo de parada (Stop Time): indican en qué momento de la simulación se
detendrá la generación de paquetes. Se fijará a valor Never para que nunca
se pare.
65
7. Evaluación de los ataques
Tabla 7.4: Atributos del nodo: parámetros de generación de tráfico
Parámetros WLAN: permitirán configurar los parámetros de la red WLAN (ver
Tabla 7.5). A continuación se comentarán los parámetros de este grupo que afectan a las simulaciones realizadas. Para los atributos relativos a las caracterı́sticas
fı́sicas del medio de transmisión se han conservado los valores definidos por
defecto en el modelo de nodo wlan station adv.
- Dirección MAC (Wireless LAN MAC Addres): como ya se comentó corresponde a la dirección MAC del nodo. En los escenarios los nodos transmisores tendrán para este atributo el valor Auto Assigned generado automáticamente, mientras que los nodos receptores tendrán asignada la dirección
MAC 799975189, que se corresponderá con el valor del atributo Destination
Address de los nodos transmisores.
- Identificador BSS (BSS Idenfier): identifica el BSS al que pertenece la dirección MAC de la WLAN. Se conserva el valor por defecto Auto Assigned y de
esta forma todas las estaciones pertenezcen al mismo BSS.
- Umbral RTS (RTS Threshold): define el umbral (en número de Bytes) a partir del que se realizará el intercambio RTS/CTS previo a las transmisiones
de datos. Se ha fijado a 256 Bytes, de esta forma el intercambio se realizará siempre ya que el tamaño de los paquetes de datos está establecido a
1024 Bytes.
- Umbral de fragmentación (Fragmentation Threshold): fija el tamaño que deben tener los fragmentos de los paquetes de datos para ser enviados. Se ha
fijado al valor None que indica que no se realizará fragmentación.
- Lı́mite de retransmisiones de tramas cortas (Short Retry Limit): especifica el
número máximo de intentos de retransmisión para las tramas cuyo tamaño
sea menor o igual que el determinado por el atributo RTS Threshold. En
nuestro caso este lı́mite afectará a las tramas de control de la capa MAC. Si
se alcanza este lı́mite se descartará la trama de datos correspondiente. Se
mantendrá el lı́mite por defecto, que es de 7 transmisiones.
66
7.1. Configuración de los escenarios
- Lı́mite de retransmisiones de tramas largas (Long Retry Limit): especifica el
número máximo de intentos de retransmisión para las tramas cuyo tamaño
sea mayor que el determinado por el atributo RTS Threshold. En nuestro
caso este lı́mite se aplicará a las retransmisiones de tramas de datos. Si se
alcanza este lı́mite se descartará la trama de datos. Se mantendrá el lı́mite
por defecto, que es de 4 transmisiones.
- Tamaño de la cola de transmisión (Buffer Size): define el tamaño máximo en
bits de la cola de transmisión de la capa superior. Cuando se alcanza este
lı́mite los paquetes que llegan de las capas superiores son descartados hasta
que se libere espacio en la cola. Se mantiene el valor por defecto de 256000
bits.
- Caracterı́sticas fı́sicas (Physical Characteristics): determina la tecnologı́a de
la capa fı́sica usada. Dicha tecnologı́a será empleada por la capa MAC para configurar algunos parámetros del protocolo 802.11, como son el tiempo
SIFS, el tiempo de duración de un slot, el tamaño de la ventana de contención máxima y mı́nima y otros parámetros derivados de los anteriores
(como el tiempo DIFS). El valor de este atributo también determina el ratio máximo de transmisión que de los paquetes de datos definido por el
atributo Data Rate. Como se comentó en la Sección 4.1 el modelo de nodo wlan station adv implementa por defecto la versión del estándar 802.11b
con la tecnologı́a de la capa fı́sica Direct Sequence por lo que el parámetro
Physical Characteristics se dejará al valor Direct Sequence (lo que implica los
valores de tiempo de slot a 20 µs, tiempo SIFS a 10 µs, CWmin a 31 slots
y CWmax a 1023 slots) e igualmente se conservará el valor por defecto del
ratio de envı́o de datos (Data Rate) a 11 Mbps.
- Ajustes del canal (Channel Settings): especifica la banda de frecuencia que
usará el transmisor y receptor de radio conectados a la capa MAC. Se mantendrá a los valores por defecto del modelo de nodo, que son ancho de banda (Bandwidth) a valor Physical Technology Dependent y frecuencia mı́nima
(Min Frequency) a valor BSS Based.
- Potencia de transmisión (Transmit Power): especifica la potencia de transmisión en vatios. Se conserva al valor por defecto de 0,005 vatios.
- Umbral de potencia de recepción de paquetes (Packet Reception-Power Threshold): define la sensibilidad del receptor de radio en dBm para detectar
la llegada de paquetes. Se deja al valor por defecto de -95 dBm.
67
7. Evaluación de los ataques
Tabla 7.5: Atributos del nodo: parámetros WLAN
7.1.3.
Perfiles de tráfico
Para la experimentación con las simulaciones se han definido distintos perfiles de
tráfico. Con ellos se representan tres situaciones de tráfico para nodos individuales
que ayudarán a definir las etapas de la experimentación y a sacar conclusiones de las
evaluaciones. Para configurarlos se usarán algunos de los atributos relacionados con
los parámetros de generación de tráfico (Traffic Generation Parameters) descritos en la
Sección 7.1.2. Los perfiles diseñados son los siguientes:
Perfil de saturación: este perfil se corresponde con un tráfico continuo, es decir, con él los nodos tendrán paquetes en su cola de transmisión durante toda la
simulación. El valor necesario al que se debe fijar el parámetro de tiempo entre
llegadas (Interarrival Time) para que se produzca este tráfico, en los escenarios definidos y para todas las condiciones de jamming, es de 0,002 segundos. Este perfil
será usado para obtener los mejores resultados de comportamiento egoı́sta, ya
que los nodos jammer podrán apropiarse del canal durante toda la simulación.
68
7.2. Estrategia de evaluación
Perfil de tasa media: este perfil se corresponde con un tráfico no continuo, en
el que algunos de los nodos transmisores de los escenarios definidos pueden
quedarse, en algún instante de la simulación, sin paquetes que enviar. El valor
asignado en este caso al parámetro Interarrival Time es de 0,003 segundos.
Perfil de no transmisión: con este perfil los nodos no transmiten ningún paquete
de datos durante la simulación. Para conseguirlo basta con fijar el atributo de
tiempo de comienzo (Start Time) al valor Never, para que nunca se comience la
generación de tráfico.
Cada uno de los nodos transmisores generará su tráfico siguiendo uno de estos
perfiles según se indique en cada etapa.
7.2.
Estrategia de evaluación
En esta sección se explicará la estrategia usada para la evaluación de los ataques
mediante técnicas de jamming estudiados. Para ello en primer lugar se comentarán los
tipos de estadı́sticas recogidas y a continuación se explicarán los apartados en que se
divide la experimentación y los resultados que se espera obtener.
7.2.1.
Medidas estadı́sticas
OPNET Modeler dispone de una amplia variedad de estadı́sticas para representar los resultados de las simulaciones. Éstas pueden obtenerse en forma de gráficas
de resultados y, si se desea más detalle, en forma de resumen de paquetes creados o
destruidos por módulos. De todas las estadı́sticas disponibles se han seleccionado las
consideradas más adecuadas para ilustrar los comportamientos en estudio, a continuación se explicará la información que representa cada una.
Tasa de envı́o de datos
En este caso se presenta, en paquetes por segundo, la tasa de envı́o de datos transmitida por la capa MAC de las estaciones. Para comparar mejor los resultados obtenidos para esta estadı́stica se le ha aplicado el filtro de sample sum predefinido en
OPNET Modeler. Mediante este filtro se genera, por cada entrada T0 una segunda
muestra Tout . En el eje de abscisas los valores para x0i y xouti estarán alineados, mientras que en el de ordenadas la relación es la indicada por la Expresión 7.1.
yout [n] =
n
X
y0i
(7.1)
i=0
Por tanto para esta medida los datos obtenidos son resultados acumulativos.
69
7. Evaluación de los ataques
Tamaño de la cola de transmisión
Representa el número total de paquetes que hay en la cola de transmisión de la
capa MAC de los nodos en cada instante de la simulación. Normalmente la cola sólo
contiene paquetes de las capas superiores.
Retardo de acceso al medio
Con esta estadı́stica se evalúa el retardo de acceso al medio (en segundos) que
representan las esperas que sufre el envı́o de datos en las estaciones. Dichas esperas
pueden ser debidas tanto a los retrasos en la cola de transmisión como los ocasionadas
por los procesos de contienda y administración de la capa MAC, es decir, el retardo de
acceso al medio se contabiliza desde que cada paquete entra en la cola de transmisión
hasta que comienza a ser enviado, como se muestra en la Figura 7.3.
Figura 7.3: Cálculo del retardo de acceso al medio
Tasa de recepción de datos
Tasa de datos recibidos en la capa MAC desde la capa fı́sica en paquetes por segundo. Esta estadı́stica incluye todo el tráfico de datos recibidos, sea cual sea su destino.
Al igual que para el caso de la tasa de envı́o de datos, a esta estadı́stica también se le
ha aplicado el filtro de OPNET Modeler sample sum.
Tasa de datos descartados por exceso de reenvı́os
Esta medida recoge la tasa de datos (en paquetes por segundo) de las capas superiores que son descartados porque la capa MAC no puede recibir los ACK correspondientes y los paquetes ya han alcanzado las cotas máximas de retransmisiones
permitidas por los lı́mites short retry limit o long retry limit. Al igual que para el caso de
las tasas de envı́o y recepción de datos, a esta estadı́stica también se le ha aplicado el
filtro de OPNET sample sum.
70
7.2. Estrategia de evaluación
Tablas de estadı́sticas de paquetes
OPNET Modeler también dispone de una utilidad para recoger estadı́sticas de paquetes creados y destruidos según módulos.
En el caso de los nodos que participan en las simulaciones, los módulos que crean
paquetes son: el módulo wireless lan mac que representa a la capa MAC y puede crear
tramas de control (RTS,CTS o ACK) y tramas MAC (para encapsular los datos), y el
módulo source que representa a las capas superiores y genera paquetes “sin formato”
(detalles de los módulos en la Sección 4.1). Asignarle a este último conjunto de paquetes el tipo “sin formato” es debido, como se explica en 4.1, a que el módulo source es
una abstracción de las capas superiores del modelo de red, por lo que los paquetes que
genera son de un tipo especial que no se corresponde con ningún formato estándar.
A su vez los módulos que destruyen paquetes son: el módulo wireless lan mac que
destruirá las tramas de control y MAC que reciba y tengan como destino el nodo actual; y el módulo sink que al igual que source es una abstracción de las capas superiores y destruirá los paquetes “sin formato” resultantes de desencapsular las tramas
MAC en el nivel inferior. Como se ha dicho la destrucción de paquetes se realiza en
los módulos del nodo destino de los mismos, por lo que un paquete destruido en el
módulo sink implica una recepción correcta de datos.
7.2.2.
Descripción de la estrategia
A continuación se pasará a explicar la estrategia seguida para la evaluación de
resultados. En todas las experimentaciones se mostrarán al menos los resultados para
las estadı́sticas de tasa de envı́o de datos y tamaño de la cola de transmisión, descritas
en la Sección 7.2.1. Además de estas se usarán las más apropiadas para ilustrar los
comportamientos estudiados en cada caso.
La duración de las simulaciones para todas las ejecuciones se ha establecido en 5
segundos. Con este tiempo se consigue producir una cantidad de tráfico necesaria para
obtener información de evaluación completa sin hacer que las ejecuciones se hagan
muy duraderas.
El proceso de jamming se describirá a través de la actuación del nodo egoı́sta, por lo
que la evaluación de los resultados se organiza en base a los tres modos de ejecución
de las técnicas de jamming (ver Sección 5.1.2). De esta forma en la primera etapa de
evaluación, el nodo jammer actuará en modo de jamming continuo (no enviará datos,
sólo perjudicará a nodo tr), en la siguiente actuará en modo normal (enviando datos
y aprovechando el canal) y en la última etapa utilizará el modo aleatorio (realizando
el jamming de forma aleatoria).
71
7. Evaluación de los ataques
Modo continuo
Se realizará la simulación en el escenario de jamming con nodo tr con perfil de
tráfico de tasa media y el nodo jammer realizando el jamming en modo continuo con
perfil de tráfico de no transmisión. Con esta configuración se pretende demostrar que
si se realiza jamming, aunque el nodo jammer no tenga datos para enviar, nodo tr no
consigue transmitir sus datos de forma correcta.
Modo normal
En este modo se distinguirán dos etapas, en la primera se usará el escenario de jamming con nodo tr con perfil de tráfico de tasa media y jammer con perfil de tráfico
de saturación. En ella se estudiará el aprovechamiento del canal que hará el jammer
con los distintos tipos de jamming y se demostrará cuál de ellos es más eficiente. En
la segunda etapa se realizarán las simulaciones tanto en el escenario de jamming como en el normal, con todos los nodos transmisores de los escenarios con perfiles de
tráfico de tasa media. En este caso se compararan los resultados de normal tr con
los obtenidos por nodo tr y por el nodo jammer efectuando el tipo de jamming que
se demostró cómo más eficiente en la etapa anterior.
Modo aleatorio
Por último para ilustrar el comportamiento del jamming en modo aleatorio se estudiarán los resultados del tipo de jamming más eficiente con nodos transmisores con
perfil de tráfico de saturación para distintos valores del parámetro de jamming aleatorio (Random CTS Jamming, Random DATA Jamming o Random ACK Jamming, dependiendo del tipo de jamming que se obtenga como más eficiente en la sección anterior).
7.3.
Resultados de la evaluación
A continuación se explicarán los resultados de la evaluación con la ayuda de las
estadı́sticas generadas por OPNET Modeler y siguiendo la estructura definida en 7.2.2.
7.3.1.
Técnicas de jamming en modo continuo
En este marco de evaluación el nodo jammer realiza el jamming en modo continuo
y a pesar de tener un perfil de tráfico de no transmisión consigue evitar que nodo tr
realice correctamente las transmisiones de datos. A continuación se pasará a demostrar esta cuestión para los tres tipos de jamming implementados.
Para el jamming a CTS, como muestra la Figura 7.4, la tasa de envı́o de datos 1 de
1
Se debe recordar que las medidas de tasas, tanto de envı́o de datos como de recepción y descarte, se
presentan en las gráficas en valores acumulativos por la aplicación del filtro sample sum de OPNET
72
7.3. Resultados de la evaluación
Figura 7.4: Tasa de envı́o de datos de nodo tr para los distintos tipos de jamming en
modo continuo
nodo tr permanece a cero durante toda la simulación . Ésto sucede a pesar de que
su módulo source genera 1500 paquetes de datos para ser enviados (ver Tabla 7.6).
Además intenta comenzar el intercambio RTS/CTS 907 veces, como indican los paquetes de control creados en su capa MAC (módulo wirelees lan mac), sin conseguirlo
ninguna. Por tanto el jamming a CTS en modo continuo cumple su objetivo.
En el caso del jamming a tramas de datos y ACK, como muestra la Figura 7.4,
nodo tr sı́ envı́a datos, prácticamente el mismo número de paquetes para ambos casos (355 con jamming a datos y 352 con jamming a ACK, ver Tabla 7.6). Ésto es lógico
ya que el primer jamming está enfocado a que las tramas de datos no lleguen al receptor (nodo rc) y el segundo a que las tramas ACK de confirmación enviadas por
nodo rc no sean recibidas en nodo tr pero en ambos casos las tramas de datos llegan
a enviarse.
Para demostrar que nodo tr no transmite de forma correcta en el caso de jamming
a datos en modo continuo, en la Figura 7.5 puede verse que la tasa de recepción de
datos en nodo rc es cero por lo que los datos enviados por nodo tr no se reciben en
su destino.
73
7. Evaluación de los ataques
nodo tr
XXX
XXX Formato
Control
XXX
Módulo
XX
Jamming a CTS
Jamming a datos
Jamming a ACK
source
wireless lan mac
source
wireless lan mac
source
wireless lan mac
MAC
sin formato
Total
1500
1500
907
1500
1775
1500
1760
907
1500
1420
355
1500
1408
352
Tabla 7.6: Número de paquetes creados por el nodo nodo tr con jamming en modo
continuo
Figura 7.5: Tasa de recepción de datos en nodo rc para jamming a datos en modo
continuo
En el caso del jamming a ACK en modo continuo es necesario estudiar la Figura
7.6, en ella pueden verse la tasa de envı́o de datos y la tasa de descarte de datos por
alcance del lı́mite de retransmisiones de nodo tr. Al compararlas se ve que la tasa de
envı́o es igual a la de descarte multiplicada por cuatro (este resultado se estudiará con
74
7.3. Resultados de la evaluación
Figura 7.6: Tasa de envı́o y de descarte de datos por exceder el lı́mite de retransmisiones para el nodo tr con jamming continuo a tramas ACK
más detalle a continuación), que se corresponde con el número de veces que se intenta
enviar una trama de datos antes de ser descartada, definido en el atributo Long Retry
Limit (ver atributos de los nodos en Sección 7.1.2).
Para ver más concretamente que los paquetes transmitidos por nodo tr finalmente se descartaron se pueden analizar también los paquetes destruidos por el nodo,
mostrados en la tabla 7.7.
nodo tr
XXX
Jamming a ACK
XXX Formato
Control
XXX
Módulo
XX
sink
wireless lan mac
2816
MAC
sin formato
Total
352
1117
4285
Tabla 7.7: Número de paquetes destruidos por el nodo nodo tr con jamming en modo
continuo
75
7. Evaluación de los ataques
En la tabla 7.7 se recoge que capa la MAC del nodo destruye las 352 tramas MAC
que encapsulaban los 352 paquetes de datos que fueron transmitidos. Además se puede comprobar que nodo tr nunca recibió las tramas ACK de nodo rc, ya que las
tramas de control que destruye la capa MAC son las correspondientes a los intentos
de reenvı́o de cada trama de datos en total 1408 (CTS enviados desde nodo rc) más
las tramas CTS usadas por el jammer para provocar la colisión con los ACK, en total
2816 tramas. Los 1117 paquetes sin formato destruidos se corresponden a los paquetes
que fueron descartados por desbordamiento de la cola de transmisión, éstos junto a
los 352 transmitidos y a los 31 que caben en la cola forman el total de 1500 paquetes
de datos generados por nodo tr (ver Tabla 7.6).
De nuevo se demuestra que el jamming continuo, en este caso a tramas ACK, cumple su función.
7.3.2.
Técnicas de jamming en modo normal
A continuación, como se comentó en 7.2.2, se mostrarán los resultados de las simulaciones de las técnicas de jamming en modo normal para los perfiles de tráfico de
saturación y tasa media respectivamente.
7.3.2.1.
Perfil de tráfico de saturación
Las simulaciones de esta sección se ha realizado con el nodo jammer con perfil de
tráfico de saturación y nodo tr con tasa media (definición de perfiles de tráfico en
Sección 7.1.3). Con esta configuración se espera obtener un aprovechamiento máximo
del canal por parte del nodo jammer, ya que con el perfil de tráfico de saturación
en todo momento tendrá datos para enviar. Además se estudiará cuál de los tipos de
jamming es más eficiente a la vista de los resultados.
En la Figura 7.7 se muestra el tráfico de datos enviado por el jammer para los distintos tipos de jamming; podemos ver que para los tres casos el nodo egoı́sta aprovecha
el canal enviando sus propias transmisiones. También se puede observar que el jamming a CTS consigue enviar más datos que los demás tipos, concretamente 217 más
que el jamming a datos y 390 más que el jamming a ACK (ver Tabla 7.8). Ésto se debe
a que sabotea antes las transmisiones de nodo tr (durante el intercambio RTS/CTS),
lo que le permite aprovechar más tiempo el canal. Por la misma razón el jamming a
datos mejora un poco la tasa de envı́o del jamming a ACK enviando 173 paquetes
más, ya que para el primer caso el jammer esperará a que se complete el intercambio
RTS/CTS y a que el nodo tr envı́e la trama de datos para realizar el jamming; y en el
segundo caso retrasará aún más su actuación esperando a que nodo rc envı́e el ACK
de confirmación.
76
7.3. Resultados de la evaluación
Figura 7.7: Tasa de envı́o de datos del nodo jammer con tráfico de saturación para los
distintos tipos de jamming en modo normal
jammer
XXX
XXX Formato
Control
XXX
Módulo
XX
Jamming a CTS
Jamming a datos
Jamming a ACK
source
wireless lan mac
source
wireless lan mac
source
wireless lan mac
2028
MAC
sin formato
Total
2251
2251
3911
2251
3671
2251
3456
1883
2251
2005
1666
2251
1963
1493
Tabla 7.8: Número de paquetes creados por el nodo jammer con tráfico de saturación
para los distintos tipos de jamming en modo normal
El tráfico de saturación hace que la cola de transmisión del jammer permanezca a
su capacidad máxima, prácticamente durante toda la simulación, para todos los tipos
de jamming (ver Figura 7.8). La diferencia se presenta en el momento en que se llena
la cola que en el caso del jamming a CTS tarda unas décimas de segundo más debido a
77
7. Evaluación de los ataques
Figura 7.8: Tamaño de la cola de transmisión del nodo jammer con tráfico de saturación para los distintos tipos de jamming en modo normal
que, cómo ya se ha comentado, con este tipo de jamming se consiguen transmitir más
datos por lo que la cola tardará más en alcanzar su lı́mite. El mismo razonamiento
se aplica para justificar que la cola de transmisión se llene más tarde para el caso del
jamming a datos que para el jamming a ACK.
Por todo lo anterior el jamming a CTS también necesita menos tiempo para acceder
al medio para transmitir sus datos cómo muestra la Figura 7.9. Aún ası́ los datos en
todos los tipos de jamming sufren un tiempo de espera para ser transmitidos. Ésto se
debe tanto al tiempo que deben permanecer en la cola de transmisión antes de ser
enviados, como al intervalo de backoff que debe esperar el nodo antes de acceder al
medio para realizar el envı́o (ver cálculo del retardo de acceso al medio en la Figura
7.3). Los primeros máximos de la gráfica se corresponden aproximadamente con el
momento en que se llenan las colas de transmisión, a partir de ahı́ las variaciones que
se muestran son debidas al carácter aleatorio del intervalo de backoff (ver Expresión
en 1.1).
78
7.3. Resultados de la evaluación
Figura 7.9: Retardo de acceso al medio del nodo jammer con tráfico de saturación para
los distintos tipos de jamming en modo normal
Los resultados obtenidos para el nodo tr son los mismos que para el caso de
jamming en modo continuo, puesto que no se permite en ningún caso que el nodo
transmita correctamente sus datos.
Después de todo lo comentado en esta sección se puede concluir que el nodo
egoı́sta consigue aprovechar el canal para transmitir sus datos mientras realiza el jamming llevando a cabo el comportamiento egoı́sta definido en la Sección 1.2.4. Además
con la experimentación anterior también se llega a la conclusión de que el jamming
a CTS es el tipo de jamming más eficiente de los implementados, dado que es el que
consigue aprovechar más el canal para sus propios envı́os.
7.3.2.2.
Perfil de tráfico de tasa media
A continuación se pasará a comprobar cuánto mejora su rendimiento un nodo
jammer realizando el jamming a tramas CTS (se ha elegido este tipo de jamming por
ser el más eficiente) frente un nodo normal tr que se comporta según el estándar
(roles de los nodos en Sección 7.1.1). Ası́ mismo se incluirá en el estudio el nodo tr
79
7. Evaluación de los ataques
para ver cuánto empeora su rendimiento también respecto a normal tr. Todos los
nodos transmisores implementan un tráfico de tasa media (perfiles de tráfico en Sección 7.1.3).
En la Figura 7.10 puede verse la tasa de envı́o de datos para los tres nodos estudiados. Se comprueba que los resultados de jammer mejoran a los de normal tr y éstos
a su vez a los de nodo tr.
En la Tabla 7.9 se pueden estudiar con más detalle los paquetes creados por los
módulos de cada nodo. El nodo jammer consigue enviar los 1500 paquetes que genera, mientras que nodo tr sólo consigue enviar 119.
De las 1899 tramas de control que crea la capa MAC del jammer, 1500 son tramas RTS que ha necesitado para realizar el intercambio RTS/CTS antes de sus propias transmisiones, y 399 son tramas CTS que ha enviado para realizar el jamming.
Ésto se corresponde con el número de tramas de control creadas por la capa MAC del
nodo tr, que de las 518 totales, 399 son las tramas RTS del intercambio RTS/CTS que
ha sido saboteado por el jammer y las 119 restantes son tramas RTS que ha necesitado
para enviar los paquetes que ha logrado transmitir.
Figura 7.10: Tasa de envı́o de datos de los nodos jammer, nodo tr y normal tr con
jamming a CTS en modo normal y perfil de tráfico a tasa media
80
7.3. Resultados de la evaluación
Jamming a CTS
XXX
XXX Formato
Control
XXX
Módulo
XX
jammer
normal tr
nodo tr
source
wireless lan mac
source
wireless lan mac
source
wireless lan mac
1899
1093
518
MAC
sin formato
Total
1500
1500
1500
1500
1500
1500
1500
1019
119
Tabla 7.9: Número de paquetes creados por los nodos jammer, nodo tr y normal tr
con tráfico de tasa media y jamming a CTS en modo normal
Con respecto al nodo normal tr el jammer consigue enviar 481 paquetes de datos
más, mientras que nodo tr empeora el resultado enviando 900 paquetes menos.
Figura 7.11: Tamaño de la cola de transmisión de nodos jammer, nodo tr y
normal tr con jamming a CTS en modo normal y perfil de tráfico de tasa media
81
7. Evaluación de los ataques
Respecto a las colas de transmisión, mientras que las de normal tr y nodo tr
permanecen saturadas durante toda la simulación (ver Figura 7.11), en la del nodo
jammer los paquetes apenas sufren espera para ser transmitidos, por lo que si la tasa
de envı́o aumentara el nodo egoı́sta podrı́a aprovechar aún más el canal como se ha
comprobado con el perfil de tráfico de saturación en la Sección 7.3.2.1.
Como se muestra en la Figura 7.12 el nodo jammer no experimenta retardo de acceso al medio en perjuicio de nodo tr que supera en más de un segundo el tiempo de
retardo de normal tr.
Como se ha comprobado con los resultados recopilados, con un tráfico de tasa media el nodo jammer consigue resultados mejores que un nodo estándar, pero a su vez
aprovecha menos el medio que con tráfico de saturación.
Figura 7.12: Retardo de acceso al medio de los nodos jammer, nodo tr y normal tr
con jamming a CTS en modo normal y perfil de tráfico a tasa media
82
7.3. Resultados de la evaluación
7.3.3.
Técnicas de jamming en modo aleatorio
Para terminar se experimentará con el comportamiento de jamming a CTS en modo aleatorio con perfil de saturación para los nodos transmisores y tres valores del
parámetro Random CTS Jamming que son: probabilidad de que se realice 1 (equivalente al jamming en modo normal, es decir siempre se realiza), probabilidad de 0,8 y
probabilidad de 0,2.
Los resultados de la estadı́stica de tasa de envı́o de datos es la mostrada en la
Figura 7.13. Se puede ver que con probabilidad baja de jamming la tasa de envı́o se
reduce considerablemente.
Figura 7.13: Tasa de envı́o de datos del nodo jammer para distintos valores de jamming
a CTS en modo aleatorio
El retardo de acceso al medio también se va incrementado a medida que baja la
probabilidad de jamming dado que los paquetes tendrán que esperar más tiempo a ser
transmitidos (ver Figura 7.14). Los primeros máximos se corresponden, aproximadamente, con el momento en que se llenan las colas de transmisión, a partir de ahı́ los
valores oscilarán debido a la espera del tiempo de backoff. Para probabilidad 1, después de que se llene la cola, el rango de oscilación de los valores es más pequeño que
en los demás casos debido a que el jammer calculará su backoff siempre con la venta83
7. Evaluación de los ataques
Figura 7.14: Retardo de acceso al medio del nodo jammer para distintos valores de
jamming a CTS en modo aleatorio
na de contención a valor mı́nimo, lo que normalmente le dará valores de backoff más
pequeños y similares que en el resto de casos.
Por último se verá cómo se refleja el comportamiento del jamming aleatorio en los
datos enviados por nodo tr (ver Tabla 7.10). Con probabilidad 1 no consigue enviar
ningún paquete de datos y apenas puede realizar intentos de intercambio RTS/CTS,
es decir, el nodo jammer es prácticamente dueño del canal. Para probabilidad 0,8 se
consiguen enviar 47 paquetes y además se realizan 32 intentos más de intercambio
que en el caso anterior, por lo que el jammer atacará en total a 184 tramas CTS. Con la
probabilidad de 0,2 se nota mejora en la transmisión aunque sigue siendo baja, de las
2251 sólo consigue enviar 725 y sufre 247 ataques a su intercambio RTS/CTS.
84
7.4. Resumen de resultados
nodo tr
XXX
XXX Formato
Control
XXX
Módulo
XX
Jamming (1)
Jamming (0,8)
Jamming (0,2)
source
wireless lan mac
source
wireless lan mac
source
wireless lan mac
MAC
sin formato
Total
2251
2251
152
2251
278
2251
1697
152
2251
231
47
2251
972
725
Tabla 7.10: Número de paquetes creados por el nodo nodo tr para distintos valores
de jamming a CTS en modo aleatorio
7.4.
Resumen de resultados
A lo largo de este capı́tulo se han evaluado las técnicas de jamming implementadas
para este proyecto. A continuación se realizará un resumen de los resultados derivados de esta experimentación.
Se ha demostrado que realizando jamming en modo continuo y con el nodo egoı́sta
sin datos que enviar (perfil de no saturación) se perjudica a nodo tr no permitiéndole
enviar correctamente sus datos. Además se ha comprobado que con jamming en modo
normal en el caso de que el nodo jammer tenga siempre datos que transmitir (tráfico
de saturación) éste se adueña del canal impidiendo, al igual que en el caso anterior,
que nodo tr realice correctamente ninguna de sus transmisiones.
Con esta experimentación se ha concluido también que el tipo de jamming más eficiente es el jamming a CTS. Ésto se debe a que el nodo egoı́sta sabotea las transmisiones
de nodo tr durante el intercambio RTS/CTS, antes que los demás tipos de jamming,
lo que le permite aprovechar más tiempo el canal.
Igualmente se ha demostrado que se obtiene una mejora considerable en la tasa de
envı́o de datos realizando jamming frente a los resultados que se obtienen respetando
el estándar 802.11. La mejora será mayor cuanto mayor sea la tasa de envı́o del nodo
egoı́sta.
Finalmente se ha experimentado con el funcionamiento de la técnica de jamming a
CTS introduciéndole un factor de aleatoriedad, llegando a la conclusión de que a más
probabilidad de realizar jamming mejores resultados se obtienen en el nodo jammer,
pero con menor probabilidad de jamming el comportamiento egoı́sta será menos evidente y por lo tanto más difı́cil de detectar.
Por tanto con los resultados obtenidos se demuestra el funcionamiento de las técnicas de jamming descritas en este proyecto (ver Sección 1.2.4.1) y se valida la implementación realizada de las mismas en el simulador OPNET Modeler.
85
7. Evaluación de los ataques
86
CAPÍTULO
8
CONCLUSIONES
En este capı́tulo se describen los logros y conclusiones principales que se derivan
de la realización del presente proyecto fin de carrera.
Con el desarrollo de este proyecto se han conseguido los siguientes resultados:
Comprender la función de coordinación distribuida implementada en el protocolo CSMA/CA, afrontando el estudio del estándar 802.11 (ver [2])
Estudiar el comportamiento egoı́sta en redes inalámbricas y en concreto los ataques mediante técnicas de jamming sobre la capa MAC planteados en [3].
Entender la arquitectura y funcionamiento del software OPNET Modeler ası́ como el código del módulo wlan mac de la biblioteca del simulador.
Diseñar la implementación de los ataques mediante técnicas de jamming estudiados y de la utilidad para registrar mensajes de log.
Realizar el código necesario para implementar las utilidades anteriores e incluirlas en el módulo wlan mac de OPNET Modeler.
Exportar las utilidades desarrolladas a la interfaz del modelo de nodo wlan station adv
de OPNET Modeler, para que puedan ser configuradas fácilmente por el usuario
junto con el resto de atributos del nodo.
Diseñar y realizar un proceso de evaluación de los ataques mediante técnicas de
jamming para probar su correcta implementación y obtener conclusiones de los
mismos.
Documentar todo el trabajo realizado en la memoria de desarrollo del proyecto
fin de carrera.
87
8. Conclusiones
A partir de los resultados obtenidos durante la realización de este proyecto se extraen las siguientes conclusiones, previamente expuestas a lo largo del desarrollo de
anteriores capı́tulos:
El software OPNET Modeler ha resultado ser una herramienta muy flexible, permitiendo la elección y modificación de los módulos necesarios para llevar a cabo
la implementación prevista.
El código implementado responde a los objetivos que debe cumplir el desarrollo
del proyecto.
Con la evaluación de los ataques mediante técnicas de jamming implementados
además se ha demostrado lo siguiente:
- El jamming en modo continuo implementa un ataque de denegación de servicio sobre los nodos vı́ctimas, impidiendo que éstos efectúen sus transmisiones.
- El jamming en modo normal permite que el nodo egoı́sta aproveche el canal
a expensas de los demás usuarios. Dicho aprovechamiento es proporcional
a la tasa de envı́o de datos del nodo egoı́sta, a mayor tasa de envı́o mayor
aprovechamiento y a su vez mayor perjuicio para el resto de nodos.
- El jamming en modo aleatorio con umbral de probabilidad bajo da resultados de aprovechamiento del canal por el jammer más bajos, pero al mismo
tiempo serı́a más difı́cil de detectar al no realizar el proceso de jamming
sobre todas las tramas posibles.
88
BIBLIOGRAFÍA
[1] IEEE Computer Society. LAN/MAN Standards Committee. IEEE Std 802-2001
Standard for Local and Metropolitan Area Networks: Overview and Architecture. The
Institute of Electrical and Electronics Engineers, Inc., New York, NY, USA,
2001. Disponible en la Web: http://standards.ieee.org/getieee802/
portfolio.html.
[2] IEEE Computer Society. LAN/MAN Standards Committee. Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications. The Institute of Electrical and Electronics Engineers, Inc., 2007. Disponible en la Web:
http://standards.ieee.org/getieee802/portfolio.html.
[3] Levente Buttyán y Jean-Pierre Hubaux. Security and cooperation in wireless networks. Thwarting malicious and selfish behavior in the age of ubiquitous computing.
Cambridge University Press, Cambridge, United Kingdom, 1 edition, 2008. ISBN:
978-0-521-87371-0.
[4] IEEE Computer Society. LAN/MAN Standards Committee. Carrier sense multiple
access with collision detection (CSMA/CD) access method and physical layer specifications. The Institute of Electrical and Electronics Engineers, Inc., 2002. Disponible
en la Web: http://standards.ieee.org/getieee802/portfolio.html.
[5] Andrew S. Tanenbaum. Redes de Computadoras. Pearson Educación, Naucalpán
de Juarez, México, 4, edition, 2003. ISBN: 9702601622.
[6] Tom Karygiannis y Les Owens. Wireless network security. NIST Special Publication, 2002.
[7] Pradeep Kyasanur and Nitin H. Vaidya. Detection and handling of mac layer
misbehavior in wireless networks. In In Proceedings of the International Conference
on Dependable Systems and Networks, pages 173–182, 2002. Disponible en la Web:
http://users.crhc.illinois.edu/nhv/papers/misbehave.pdf.
89
BIBLIOGRAFÍA
[8] Mithun Acharya, Tanu Sharma, David Thuente, and David Sizemore. Intelligent jamming in 802.11b wireless networks. In Proceedings of OPNETWORK,
August 2004. Disponible en la Web: http://www4.ncsu.edu/˜mpachary/
docs/acharya_OPNETWORK04.pdf.
[9] Wenyuan Xu, Yanyong Zhang, and Timothy Wood. The feasibility of launching
and detecting jamming attacks in wireless networks. In In ACM MOBIHOC,
pages 46–57, 2005. Disponible en la Web: http://www.ece.rutgers.edu/
˜yyzhang/research/papers/mobihoc05-xu.pdf.
[10] Maxim Raya, Jean-Pierre Hubaux, and Imad Aad. Domino: A system to detect
greedy behavior in ieee 802.11 hotspots. In MobiSys, 2004. Disponible en la Web:
lcawww.epfl.ch/Domino/Edomino_files/domino.pdf.
[11] Elias Weingärtner, Hendrik vom Lehn, and Klaus Wehrle. A performance comparison of recent network simulators. In ICC 2009: IEEE International Conference on Communications, 2009. Disponible en la Web: http://ds.informatik.
rwth-aachen.de/publications/2009/pdfs/icc-submission.pdf.
[12] Inc OPNET Technologies. OPNET Modeler Documentation Set. OPNET Technologies, Inc., Bethesda, MDU, USA, 2008.
[13] Matthew Gast. 802.11 Wireless Networks: The Definitive Guide. O’Reilly, Sebastopol,
CA, USA, 2002. ISBN: 0-596-00183-5.
[14] Neil Reid y Ron Seide. 802.11 (Wi-Fi) Manual de redes inalámbricas. Mc Graw Hill,
México D.F, México, 2003. ISBN: 0-07-222623-4.
90
APÉNDICE
A
GUÍA BREVE DE OPNET MODELER
En este apéndice se presenta una guı́a reducida de la herramienta software OPNET Modeler 14.5. El enfoque se se va a realizar pretende únicamente describir algunos aspectos generales sobre el programa y su arquitectura que ayuden a entender
su funcionamiento básico. De esta forma se comprenderán mejor las configuraciones
realizadas para el desarrollo de este proyecto.
A.1.
Caracterı́sticas generales
OPNET Modeler es un robusto simulador software de redes que sirve para modelar fácil e intuitivamente configuraciones de red. Además permite el análisis eficiente
del rendimiento de las configuraciones diseñadas. Algunas de las caracterı́sticas más
destacadas de OPNET Modeler son las siguientes:
- Posee una avanzada interfaz de usuario que soporta multi-ventana, ofrece iconos y menús desplegables y una paleta configurable con todos los modelos de
su biblioteca de componentes (estaciones, servidores, dispositivos, perfiles de
tráfico, etc).
- La biblioteca de componentes de OPNET Modeler dispone de más de 400 protocolos y dispositivos comerciales de empresas lı́deres como son Cisco Systems,
HP, IBM, Juniper, etc. Estos modelos están listos para ser usados en la simulaciones de OPNET por lo que se reduce el tiempo de desarrollo necesario.
- Dispone de un editor gráfico orientado a objetos que permite definir topologı́as
y arquitecturas totalmente paralelas a los sistemas reales, permitiendo un mapeado intuitivo entre el modelo de la simulación y el sistema.
91
A. Guı́a breve de OPNET Modeler
- Este simulador también permite representar los datos obtenidos en las simulaciones utilizando gráficas que facilitan la labor de estudio y clasificación de los
resultados.
A.2.
Arquitectura
Respecto a la arquitectura, como se muestra en la Figura A.1, la herramienta tiene básicamente tres niveles o modelos: proyecto, nodo y proceso. Para poder trabajar
sobre ellos OPNET Modeler dispone de un editor para cada nivel. A continuación se
hará un breve resumen de las caracterı́sticas y funciones de cada modelo.
Figura A.1: Arquitectura de OPNET Modeler
Modelo de proyecto
El modelo de proyecto es el área principal de diseño de OPNET Modeler. A través
del editor de proyectos se puede construir y editar la topologı́a de la comunicación
del modelo de red. Además para este nivel también se proporcionan capacidades de
análisis y simulación.
92
A. Guı́a breve de OPNET Modeler
Dentro del mismo proyecto se podrán tener varios escenarios con distinta configuraciones, por ejemplo para comparar los resultados obtenidos en cada uno de ellos.
El modelo de proyecto será por tanto el nivel donde se especificará el sistema que
será simulado.
Modelo de nodo
El modelo de nodo define el comportamiento de cada uno de los objetos de la red
construida mediante modelo anterior. Este comportamiento se define utilizando diferentes módulos cada uno de los cuales modela un aspecto interno como puede ser la
creación de datos o su almacenamiento.
Modelo de proceso
El modelo de proceso permite definir el comportamiento subyacente de cada uno
de los módulos definidos en el nivel anterior. Los modelos de proceso son autómatas finitos (AF), donde los estados son representados como iconos y las transiciones
entre estados como lı́neas. Las operaciones que se realizan en cada estado o por una
transición se describen en bloques de código C o C++ embebido.
En los AF del modelo de proceso se diferencian dos tipos de estados, los no forzados (Unforced) y los forzados (Forced) (ver Figura A.2). Un estado no forzado (en
rojo) ejecuta un bloque de instrucciones de entrada (enter executive) y se detiene, permitiendo que la simulación ponga su atención en otras entidades y acontecimientos
del modelo. Un proceso entra en un estado no forzado para esperar interrupciones de
la llegada de paquetes o la espiración de un contador de tiempo, cuanto ésto se produce se ejecuta un bloque de instrucciones de salida (exit executive) y se transita hacia
el estado siguiente.
Figura A.2: Tipos de estados del modelo de proceso
93
A. Guı́a breve de OPNET Modeler
Los estados forzados (en verde) son aquellos que se atraviesan necesariamente sin
ningún transcurso del tiempo de simulación, es decir, se ejecutan las instrucciones
correspondientes del bloque de entrada (enter executive) y se sale de ellos instantáneamente.
Otro elemento del modelo de proceso son las transiciones, que se utilizan para especificar los posibles cambios entre estados en respuesta a acontecimientos externos
y conforme a condiciones especı́ficas. Las transiciones pueden ser de dos tipos: condicionales o incondicionales. Las primeras ejecutan un test lógico que debe cumplirse
antes de que la transición ocurra y en el caso de las segundas no se ejecuta dicho test
lógico, si no que se pasa directamente al estado siguiente.
Como ya se ha mencionado, cada uno de los estados del AF se compone a su vez
de dos bloques de código que se denominan enter executive y exit executive. El bloque
enter executive contiene el código que se ejecuta cuando el módulo entra en un estado,
mientras que el bloque exit executive abarca el conjunto de instrucciones que se ejecutan cuando el módulo abandona el estado.
El flujo de ejecución de un estado no forzado es el mostrado en la Figura A.3, para
los estados forzados solo se ejecuta el bloque enter executive y a continuación se pasarı́a
al estado siguiente.
Figura A.3: Flujo de ejecución de un estado no forzado
94
A. Guı́a breve de OPNET Modeler
A.3.
Presentación de resultados
Respecto a las herramientas de representación de resultados OPNET Modeler ofrece cientos de estadı́sticas incorporadas para un análisis rápido de las simulaciones.
Los usuarios pueden crear estadı́sticas nuevas o usar las ya definidas. La representación de las salidas de la simulación es fácilmente manipulable y además dispone de
numerosos filtros matemáticos que se pueden aplicar sobre los resultados.
Los datos también se pueden exportar a hojas de cálculo para que puedan ser traducidos a otros formatos. En el caso de las gráficas mostradas en este proyecto los
datos obtenidos en las simulaciones de OPNET Modeler se han exportado y finalmente se representado con el programa Wgnuplot.
Con este anexo se han introducido algunas de las ideas necesarias para comprender mejor el proceso de desarrollo con la herramienta OPNET Modeler. Para más información se puede consultar la documentación oficial [12].
95