UNIVERSIDAD DE GRANADA ESCUELA TECNICA SUPERIOR DE INGENIRERÍAS INFORMÁTICA Y DE TELECOMUNICACIÓN Ingeniería Informática PROYECTO DE FIN DE CARRERA
Análisis del rendimiento de ataques de violación de protocolo 802.11 a nivel DFC-MAC
- Memoria Departamento de Teoría de la Señal, Telemática y Comunicaciones
Autor:
D. Eusebio J. Aguilera Aguilera
Director: Dr. Gabriel Maciá Fernández Granada, Julio 2009
ii
Esta página ha sido puesto en blanco de forma intencionada.
iii
iv
Resumen Las redes inalámbricas son, en la actualidad, una solución estándar cuándo se quiere proveer de acceso a Internet de forma pública o privada. Debido al medio que usan este tipo de redes, es necesario tener en cuenta medidas de seguridad para que el funcionamiento sea correcto y equitativo para todos los nodos que acceden. Algunas técnicas violan el estándar con el objetivo de obtener mejores resultados que los nodos que utilizan el estándar correctamente. En el presente proyecto se realiza una evaluación empírica de los ataques de comportamiento egoísta que afectan al trá co de subida en redes que siguen el estándar IEEE 802.11. Estos ataques se describen en detalle, analizando su funcionamiento y detallando los mecanismos que los hacen posibles. Se han realizado una serie de mediciones para poder evaluar el rendimiento de dichos ataques sobre una red inalámbrica de tipo ad-hoc. Estas mediciones se han interpretado en profundidad con el n de extraer conclusiones sobre el funcionamiento de este tipo de ataques, sus potencialidades y sus limitaciones. Para el desarrollo del proyecto se ha utilizado el simulador de redes OPNET, con el cual se han implementado los ataques, y se han obtenidos los resultados. El trabajo muestra los detalles del diseño y la implementación en este entorno. Adicionalmente, se ilustran algunos aspectos imprescindibles para la realización de desarrollos en OPNET.
v
Abstract Wireless networks are now a standard solution when a public or private Internet access is needed. Due to such networks medium, it is necessary to do everything needed to ensure the fair access and the correct functioning of every node in the network. Attackers use techniques based on violating the standard in order to obtain better results than the nodes which implements the standard correctly. The present project makes an empirical assessment of the sel sh behavior attacks that aect the uplink tra c in 802.11 networks. These attacks will be described in detail, by analyzing their functioning and explaining the mechanisms that make them possible. A wide variety of measurements has been taken to evaluate the performance of such attacks on ad-hoc wireless networks. These measurements have been thoroughly interpreted in order to reach conclusions about the functioning of such attacks, their potential and their limitations. The OPNET simulator has been used in order to develop the project. Within it, the attacks have been implemented, and the results have been obtained. This work shows the details of the design and implementation in this environment. Additionally, some essential aspects to make further developments in OPNET are illustrated.
vi
Yo, D. Eusebio Jesús Aguilera Aguilera, alumno 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 D.N.I. 26974123-E, 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 los deseen.
Fdo. Eusebio Jesús Aguilera Aguilera
Granada, 8 de Julio de 2009
vii
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 D. Eusebio Jesús Aguilera Aguilera
INFORMO:
que el presente proyecto titulado Análisis del rendimiento de ataques de violación de protocolo 802.11 a nivel DFC-MAC ha sido realizado por el mencionado alumno bajo mi supervisión, y que autorizo la defensa de dicho proyecto ante el tribunal que corresponda. Y para que así conste, expido y rmo el presente informe en Granada a 8 de Julio de 2009.
Fdo: D. Gabriel Maciá Fernández
viii
Agradecimientos Quiero dar las gracias a mi familia, por todo el apoyo que siempre me dan y el cariño que me muestran. Quiero agradecer la ayuda prestada por mi director de Proyecto D. Gabriel Maciá Fernández, sin el cual este trabajo no habría sido posible. A todos mis amigos, y en especial a aquéllos que han estado más cerca durante esta etapa de mi vida y que tanto ratos buenos hemos pasado juntos: Carmen, Javi, José, Luismi, Maite. Gracias a todos por vuestra ayuda, sin ella no habría llegado aquí.
ix
x
Esta página ha sido puesto en blanco de forma intencionada.
xi
xii
Índice general
1. Introducción
1.1. Redes inalámbricas. . . . . . . . . . . . . . . . . . . . . . . . . 1.2. Control de acceso al medio en redes inalámbricas. . . . . . . . 1.2.1. Otras funciones de coordinación en redes inalámbricas. 1.3. Ataques sobre redes inalámbricas. . . . . . . . . . . . . . . . . 1.3.1. Ataques de comportamiento egoísta. . . . . . . . . . . 1.4. Objetivos del proyecto n de carrera. . . . . . . . . . . . . . .
2. Estado del arte
2.1. Simuladores de redes. . . . . . . 2.1.1. OMNET++. . . . . . . 2.1.2. Network Simulator. . . . 2.1.3. QualNet. . . . . . . . . 2.1.4. OpNet. . . . . . . . . . 2.1.5. Selección del simulador. 2.2. Antecedentes. . . . . . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
1
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. 1 . 2 . 8 . 8 . 9 . 13
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
17
17 17 18 19 20 21 22
3. Especi cación de requisitos
23
4. Plani cación y estimación de costes
27
3.1. Funcionalidades objetivo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 3.2. Restricciones. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 3.3. Resumen de requisitos del proyecto. . . . . . . . . . . . . . . . . . . . . . . . 25 4.1. Plani cación del proyecto. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 4.1.1. Paquetes de trabajo. . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 4.1.2. Diagrama de Gantt. . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 xiii
ÍNDICE GENERAL
xiv
4.2. Estimación de recursos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
5. Diseño
35
5.1. Arquitectura del sistema. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 5.2. Diseño del sistema. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 5.2.1. Máquina de estados nitos del módulo. . . . . . . . . . . . . . . . . . 37
6. Implementación
6.1. Herramientas para la implementación. . . . . . . . . . . . . . . . . . . . 6.2. Desarrollo de la solución. . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.2.1. Exportación de parámetros a la interfaz grá ca. . . . . . . . . . . 6.2.2. Inicialización y carga inicial de parámetros de ataque. . . . . . . 6.2.3. Ataques de modi cación de la ventana de contención. . . . . . . 6.2.4. Ataque de sobrestimación de tiempos en tramas de datos y RTS. 6.2.5. Ataque de violación de tiempo DIFS. . . . . . . . . . . . . . . . . 6.3. Instalación de la solución. . . . . . . . . . . . . . . . . . . . . . . . . . .
7. Evaluación del ataque
7.1. Descripción de las pruebas realizadas. . . . . . . . . . . . . . . . 7.1.1. Indicadores de evaluación del ataque. . . . . . . . . . . . . 7.2. Resultados obtenidos. . . . . . . . . . . . . . . . . . . . . . . . . 7.3. Análisis de las estrategias del ataque. . . . . . . . . . . . . . . . . 7.3.1. Modi cación en la ventana de contención. . . . . . . . . . 7.3.2. Envío de datos después de tiempo SIFS y antes de DIFS. 7.3.3. Modi cación de tiempos en las tramas RTS y de datos. .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . .
. . . . . . .
43
43 44 44 47 48 51 52 53
57
57 60 61 73 76 78 82
8. Conclusiones
87
Bibliografía
89
A. Desarrollo de módulos para OPNET. A.1. A.2. A.3. A.4. A.5.
Elementos del entorno. . . . . . . . . . El editor de proyectos. . . . . . . . . . Editor de nodos. . . . . . . . . . . . . Editor del modelo del proceso. . . . . . Simulación y obtención de resultados.
Universidad de Granada
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
91
91 92 93 94 99
Eusebio J. Aguilera Aguilera
Índice de guras
1.1. Arquitectura de red inalámbrica . . . . . . . . . . . . . . . . . . . 1.2. Distribución de capas en el estándar 802.11 . . . . . . . . . . . . 1.3. Esquema de duraciones de los distintos tiempos y contención. . . 1.4. Solicitud de envío con detección de portadora . . . . . . . . . . . 1.5. Diagrama de estados del protocolo CSMA/CA en el nodo origen 1.6. Diagrama de estados del protocolo CSMA/CA en el nodo destino 1.7. Ataque jamming a trama CTS . . . . . . . . . . . . . . . . . . . 1.8. Ataque de jamming a trama de datos (a) y ACK (b) . . . . . . . 1.9. Violación del tiempo DIFS de espera . . . . . . . . . . . . . . . . 1.10. Subestimaron de duración en las tramas RTS y datos . . . . . . . 1.11. Uso de ventana de contención pequeña y ja . . . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
2 3 5 6 7 7 10 11 12 13 14
2.1. Entorno de simulación OMNET++ . . . . . . . . . . . . . . . . . . . . . . . 18 2.2. Captura de pantalla de QualNet . . . . . . . . . . . . . . . . . . . . . . . . 20 5.1. Arquitectura software necesaria . . . . . . . . . . . . . . . . . . . . . . . . . 36 5.2. Máquina de estados nitos del módulo wlan_mac . . . . . . . . . . . . . 37 6.1. 6.2. 6.3. 6.4. 6.5.
Selección de atributos del modelo . . . . . . . Diálogo para de nir los atributos del modelo . Parámetros de nidos para el ataque . . . . . Añadir una ubicación de modelos (paso 1). . . Añadir una ubicación de modelos (paso 2). . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
45 45 46 54 55
7.1. Esquema de la red de la simulación. . . . . . . . . . . . . . . . . . . . . . . 58 7.2. Datos enviados por la capa WLAN MAC sin nodos egoístas . . . . . . . . . 62 7.3. Tramas de control en una red sin nodos egoístas . . . . . . . . . . . . . . . . 63 xv
ÍNDICE DE FIGURAS
xvi
7.4. Reparto de la capacidad del enlace (Comportamiento egoísta desactivado) . 7.5. Colas de los nodos de la red sin nodos egoístas . . . . . . . . . . . . . . . . 7.6. Retraso en el acceso al medio de la red sin nodos egoístas . . . . . . . . . . 7.7. Flujo de subida para la red sin nodos egoístas . . . . . . . . . . . . . . . . . 7.8. Flujo de bajada para la red sin nodos egoístas . . . . . . . . . . . . . . . . . 7.9. Tiempo de respuesta de petición PING en red sin nodos egoístas . . . . . . 7.10. Peticiones PING en red sin nodos egoístas . . . . . . . . . . . . . . . . . . . 7.11. Respuestas PING en la red sin nodos egoístas . . . . . . . . . . . . . . . . . 7.12. Datos enviados por la capa WLAN MAC con nodo egoísta activado . . . . . 7.13. Información de control enviada por la capa MAC . . . . . . . . . . . . . . . 7.14. Reparto de la capacidad del enlace en la red (Comportamiento egoísta activado) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.15. Retraso en el acceso al medio en la capa WLAN MAC . . . . . . . . . . . . 7.16. Trá co que se elimina en las colas de la capa MAC. . . . . . . . . . . . . . . 7.17. Flujo de subida con el nodo egoísta activado . . . . . . . . . . . . . . . . . . 7.18. Flujo de bajada egoísta. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.19. Flujo de subida normal con interfaces de 2 Mbps. . . . . . . . . . . . . . . . 7.20. Flujo de bajada normal con interfaces de 2 Mbps. . . . . . . . . . . . . . . . 7.21. Flujo de subida con nodo egoísta activado e interfaces de 2 Mbps. . . . . . . 7.22. Flujo de bajada con el nodo egoísta activado e interfaces de 2 Mbps. . . . . 7.23. Respuestas ping (ping replies). . . . . . . . . . . . . . . . . . . . . . . . . 7.24. Datos enviados por la capa MAC (nodo egoísta activado) . . . . . . . . . . 7.25. Retraso en el acceso al medio con la ventana de contención modi cada . . . 7.26. Respuestas PING recibidas con el comportamiento egoísta activado . . . . . 7.27. Datos recibidos en la capa IP por el nodo destino . . . . . . . . . . . . . . . 7.28. Datos enviados por la capa MAC . . . . . . . . . . . . . . . . . . . . . . . . 7.29. Retraso en el acceso al medio en la capa MAC . . . . . . . . . . . . . . . . . 7.30. Peticiones recibidas por la capa IP en el nodo destino . . . . . . . . . . . . . 7.31. Respuestas PING recibidas . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.32. Comparativa de respuestas PING recibidas (comportamiento egoísta desactivado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.33. Media de envíos de la capa MAC . . . . . . . . . . . . . . . . . . . . . . . . 7.34. Media en el retraso en el acceso al medio . . . . . . . . . . . . . . . . . . . . 7.35. Media de peticiones recibidas por el nodo destino . . . . . . . . . . . . . . . 7.36. Media de respuestas PING recibidas . . . . . . . . . . . . . . . . . . . . . .
63 64 65 65 66 67 67 68 68 69
A.1. A.2. A.3. A.4. A.5. A.6. A.7.
92 93 94 95 95 96 99
Ventana principal del editor de proyectos . Paleta de objetos . . . . . . . . . . . . . . Menú contextual . . . . . . . . . . . . . . Edición de atributos del elemento de red . Arquitectura de un nodo . . . . . . . . . . Transiciones y estados . . . . . . . . . . . Red de ejemplo. . . . . . . . . . . . . . . .
Universidad de Granada
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
70 71 71 72 72 74 74 75 75 76 77 77 78 79 79 80 81 81 82 83 83 84 84
Eusebio J. Aguilera Aguilera
ÍNDICE DE FIGURAS A.8. Selección de estadísticas (Paso 1). . . . . . . . . A.9. Selección de estadísticas (Paso 2). . . . . . . . . A.10.Diálogo de simulación simple. . . . . . . . . . . A.11.Selección de atributo que tomará varios valores A.12.Diálogo de simulación avanzada . . . . . . . . .
Universidad de Granada
xvii
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
100 100 101 102 102
Eusebio J. Aguilera Aguilera
xviii
Universidad de Granada
ÍNDICE DE FIGURAS
Eusebio J. Aguilera Aguilera
Cap´ıtulo
1
Introducción as redes inalámbricas han pasado en los últimos años de ser algo anecdótico, a ser
L el principal tipo de red de computadores a nivel doméstico, y uno de los tipos más
importantes a nivel corporativo. Teniendo esto en cuenta, no es de extrañar que la seguridad y el buen funcionamiento en general de este tipo de redes se haya convertido en la prioridad de muchos grupos de trabajo y empresas. El presente proyecto versa sobre técnicas para violar las especi caciones de la capa MAC del estándar IEEE 802.11, buscando como resultado obtener más recursos que los otros nodos que forman la red. Para una mejor comprensión del proyecto, es necesario un acercamiento a los conceptos necesarios para entender el funcionamiento de las técnicas y por qué funcionan las mismas. En este capítulo se van a presentar conceptos sobre las redes inalámbricas en general: tipos de redes inalámbricas, arquitectura de una red inalámbrica, arquitectura de las capas que forman el estándar IEEE 802.11, funcionamiento del control de acceso al medio en estas redes. Todos estos conceptos son necesarios, ya que los ataques se realizan sobre redes inalámbricas y más concretamente se ataca el control de acceso al medio; por lo que es imprescindible conocer como funcionan las redes inalámbricas en general y más en profundidad el control de acceso al medio de dichas redes.
1.1. Redes inalámbricas. Las redes inalámbricas se pueden descomponer en dos tipos diferentes: redes en modo
ad-hoc y en modo infraestructura (infrastructured mode ). El modo infraestructura se compone de un punto de acceso (AP Access Point ) y un conjunto de clientes. El modo ad-hoc
elimina el punto de acceso, pudiendo los nodos conectarse dinámicamente de una forma libre. A un conjunto de un punto de acceso y uno o varios nodos se le conoce como conjunto de servicio básico (o en inglés Basic Service Set ). Varios de estos conjuntos de servicios que pertenezcan a una misma red se denominarán como un conjunto de servicio extendido 1
Introducción
2
BSS ESS
Figura 1.1: Arquitectura de red inalámbrica (o en inglés Extended Service Set ). La composición típica de una red inalámbrica puede verse en la Figura 1.1. El estándar 802.11x de ne también como se organizan las capas de los dispositivos que lo implementan. Se puede diferenciar entre la capa física y la capa MAC. Así dentro de la capa física se pueden diferenciar varios tipos de capa física: FH1 , DS2 e Infrarrojos. Estos tipos de capa son distintas implementaciones que existen de la capa física en redes inalámbricas y que por tanto una red inalámbrica puede usar una u otra pero no varias a la vez. Así para acceder a todos estos tipos de capas físicas desde una misma capa MAC, es necesario que se implementen capas intermedias que posibiliten un trabajo transparente y limpio entre la capa MAC (que es única) y las distintas implementaciones de capa física. Por lo tanto se ha divido la capa física en dos subcapas: una subcapa física, que se denomina como subcapa física dependiente del medio (o en inglés Physical Medium Dependent ), y que es la implementación de la subcapa física mediante DS, FH o Infrarrojo; y otra subcapa que realiza una abstracción sobre la subcapa física y presenta una interfaz de comunicación única independiente de la subcapa física, denominada procedimiento de convergencia de la capa física (o en inglés Physical Layer Convergence Procedure ). Se puede observar una representación grá ca de la estructura en la Figura 1.2.
1.2. Control de acceso al medio en redes inalámbricas. Cuando las comunicaciones se realizan usando para ello un medio compartido, es necesario que se arbitre el acceso a dicho medio, pues de lo contrario no será posible que se realicen las transmisiones. Debido a que las comunicaciones inalámbricas se realizan por el aire, que es un medio compartido, es necesario implementar un control en el acceso al 1 2
Siglas en inglés de Frecuency Hopping Spread Spectrum. En inglés Direct Sequence Spread Spectrum.
Universidad de Granada
Eusebio J. Aguilera Aguilera
1.2 Control de acceso al medio en redes inalámbricas.
3
Figura 1.2: Distribución de capas en el estándar 802.11 medio para que se produzcan el número mínimo de colisiones (y cuando se produzcan el sistema se reponga). Un método simple para implementar un control de acceso al medio es comprobar si se está realizando una transmisión, y en caso a rmativo el nodo no transmite y en caso contrario el nodo transmite. A este método de control de acceso al medio se le conoce como CSMA3 . Sin embargo este método tiene una serie de problemas que evitan que se puedan implementar de una forma directa en redes LAN inalámbricas: El mecanismo necesita un canal en el que se pueda transmitir y recibir información al mismo tiempo, es decir, un canal full-duplex. Sin embargo las interfaces inalámbricas implementan canales half-duplex, en los que sólo se puede transmitir o recibir información, pero no ambas cosas al mismo tiempo. Esto es debido a que las tarjetas de red inalámbricas sólo disponen de un transceptor4 por cuestiones económicas, y por lo tanto sólo puede conmutar entre la transmisión y la recepción en un momento dado. En una red inalámbricas no es posible a rmar que una estación puede escuchar todas las transmisiones de todas las estaciones. Esto es debido a que una estación puede estar a una distancia en la que unas estaciones sí la escuchen pero otras no. Esta situación es conocida en el mundo de las comunicaciones inalámbricas como el problema de la estación oculta. Debido a esto cuando se escucha un canal y no se escucha ninguna transmisión no se puede asumir que no se esté realizando una, puesto que puede que no se escuche la estación que la está realizando. 3
Acrónimo en inglés de Carrier Sense Multiple Access o en español Acceso Múltiple por Detección de Portadora. 4 Un transceptor es una pareja de un transmisor y un receptor. Universidad de Granada
Eusebio J. Aguilera Aguilera
Introducción
4
Así pues, hay que implementar un método de control del acceso que pueda solventar estos dos problemas. Partiendo del método CSMA, es necesario una forma de asegurar que cuando en el canal no haya trá co no se esté produciendo ninguna transmisión que no sea posible percibir debido a una posición concreta de la estación. Para reducir el número de colisiones se usa un método para disminuir la posibilidad de que dos o más nodos quieran trasmitir al mismo tiempo. Para ello se utilizan los espacios entre tramas (en inglés Inter Frame Space ). Esto obliga a los nodos a esperar un tiempo que el medio esté libre antes de empezar una transmisión, es decir, que este tiempo sólo se tiene en cuenta si el canal está libre, en caso contrario no (reiniciándose de nuevo el contador de tiempo). Con esta técnica se disminuye la posibilidad de que dos nodos intenten acceder al medio al mismo tiempo. Existen además distintos tiempos dependiendo de la prioridad que tenga el mensaje a enviar. Estos son:
SIFS: Se denomina como espacio entre tramas corto (o en inglés Short Inter Frame Space ) y se usa para separar mensajes que pertenecen a la misma transmisión, es
decir, es el espacio de tiempo que separa la recepción correcta de una trama CTS y el envío de la trama de datos que le sucede. Es la mínima unidad de espacio temporal entre tramas y se usa para los mensajes que tienen una mayor prioridad (tramas RTS, CTS, RxBusy, ACK y NAK). Tiene un valor de tiempo jo dependiendo de la capa física que se implemente.
PIFS: Se llama espacio entre tramas de coordinación de punto (o en inglés Point Coordination Inter Frame Space ). Este tiempo sólo es usado por los puntos de acceso para acceder al medio. El PIFS es equivalente a P IF S = SIF S + SlotT ime, siendo un SlotTime una fracción de tiempo ja.
DIFS: Es el espacio entre tramas distribuido (en inglés Ditribuited Inter Frame Space ) y es el tiempo que usa una estación normal cuando quiera empezar una transmisión. Se calcula como DIF S = P IF S + SlotT ime.
EIFS: Conocido como espacio entre tramas extendido (en inglés Extended Inter Frame Space ). Este espacio de tiempo se usa cuando un nodo no entiende un mensaje para prevenir una futura colisión con un mensaje de la transmisión actual.
Sin embargo, aún usando todos estos métodos para evitar colisiones, éstas se producen, por lo que hay que disponer de un arbitraje que permite que el sistema se reponga de estos acontecimientos. Cuando se produce una situación en la que varios nodos quieren transmitir hay que decidir que nodo se queda con el medio para transmitir. Una forma fácil de realizar esta labor sería que el punto de acceso eligiera al nodo directamente. Sin embargo, esto puede ser parcial y además hay que tener en cuenta que no siempre se dispone de un punto de acceso (en redes en modo ad-hoc ). Por tanto, es necesario encontrar un método de arbitraje distribuido e imparcial. Existe un algoritmo usado para estos menesteres y que es conocido como algoritmo exponencial de parada (más conocido como Exponential Backo Algorithm ). La forma en que se resuelve la situación es mediante la elección por parte de cada nodo de un Universidad de Granada
Eusebio J. Aguilera Aguilera
1.2 Control de acceso al medio en redes inalámbricas.
5
Figura 1.3: Esquema de duraciones de los distintos tiempos y contención. número aleatorio entre el cero y N (N se conoce como ventana de contención). Entonces el nodo espera un tiempo igual a ese número de slots antes de iniciar una nueva transmisión (comprobando siempre que otro nodo no haya accedido al canal antes), es decir, cada vez que pasa un tiempo igual al de un slot se reduce en uno el contador, y cuando llega a cero sin que otro nodo haya accedido al medio realiza la transmisión. El valor de N en la ventana de contención se dobla cada vez que se produce una transmisión fallida, hasta llegar a un máximo de nido como CWmax + 1. Mientras que después de una transmisión correcta el valor de la ventana de contención vuelve a ser el inicial, que se denomina CWmin . Este algoritmo se aplica siempre que se produce alguna de las siguientes situaciones: Si el nodo comprueba el medio antes de la primera transmisión de un paquete y comprueba que el medio está ocupado. Después de cada retransmisión. Después de una transmisión correcta. Sólo existe una situación en la que una estación no aplica este algoritmo, y es cuando decide transmitir información y el medio ha estado libre más de un tiempo DIFS. La razón de que se use una unidad de tiempo ja conocida como slot, es para que un nodo no pueda transmitir cuando otro ya lo está haciendo, es decir, las colisiones sólo se podrán realizar cuando dos o más nodos intenten transmitir en el mismo slot. Esto reduce la probabilidad de colisión a la mitad como se demuestra en [Teodoro-2003]. Se puede ver una representación grá ca de como funciona el sistema de contención en la Figura 1.3. Todas estas técnicas y algoritmos que han sido explicados anteriormente, son las que conforman el método de acceso al medio en las redes inalámbricas que siguen el estándar IEEE 802.11x. Este sistema, que se denomina CSMA/CA, trata de evitar las colisiones, sin embargo aún así se siguen produciendo. Para poder disminuir la probabilidad de que dos estaciones colisionen por no poder escucharse la una a la otra, es necesario un método que permita determinar si un nodo está inmerso en una transmisión, teniendo en cuenta que no es posible sondear todas las transmisiones del medio. Así hay que centrarse en el nodo del cual se tiene que determinar si está teniendo una transmisión. Para poder determinar si un nodo está teniendo una transmisión lo más simple es un esquema en el que se le consulte a él directamente. El Universidad de Granada
Eusebio J. Aguilera Aguilera
Introducción
6
(a) Solicitud de envío aceptada.
(b) Solicitud de envío con respuesta fallida.
Figura 1.4: Solicitud de envío con detección de portadora nodo puede contestar o bien que está ocupado, o bien que puede realizar la transmisión. En caso de que el nodo esté disponible para realizar la transmisión, ésta se produce enviándose distintos mensajes, los cuáles pueden ser recibidos correctamente o no. El nodo que recibe los mensajes debe indicar si los ha recibido bien o no. El método anterior es conocido como Detección de Portadora Virtual (Virtual Carrier Sense en inglés.). Como se describe en [Harsal-1998], cuando se quiere realizar una transmisión el nodo origen de la misma envía una trama5 RTS6 , dónde especi ca la dirección origen y destino de la transmisión. En caso de que el nodo destino de la transmisión pueda atender al mensaje entonces manda una trama CTS7 al nodo origen indicándole su disponibilidad (con el mismo par de direcciones pero en orden inverso). Este comportamiento se puede ver con más claridad en la Figura 1.4. En caso de que el nodo no pueda atender la petición de envío, envía una trama RxBusy indicando que no puede atender peticiones pues se encuentra ocupado por alguna razón. Si la respuesta es positiva (si se recibe una trama CTS), entonces el nodo de origen transmite la trama de datos, que se encontraba en espera. En caso de recepción correcta, el nodo destino envía una trama ACK8 indicando que el mensaje le ha llegado bien, mientras que en caso contrario envía una con rmación negativa NAK9 . Si se produce la respuesta negativa el nodo origen intenta reenviar de nuevo los datos. Mientras se produce esta conversación los nodos ajenos a la misma, pero que se encuentran en la misma red, van ajustando su NAV10 . Este vector es un valor de tiempo almacenado en los nodos vecinos a una conversación activa y que se usa para predecir cuándo nalizará la misma. El valor de NAV se actualiza con el valor del campo de duración de las tramas RTS, CTS y de datos. Los diagramas de estados del protocolo CSMA/CA en los nodos origen y destino pueden verse en la Figura 1.5 y 1.6 respectivamente. 5
Se denomina trama (en inglés frame ) a un bloque jo de datos que se envían como una entidad, por parte de la capa de enlace. 6 Siglas Request To Send. 7 Siglas de Clear To Send. 8 ACKnowledgment en inglés. 9 Non AcKnowledgment en inglés. 10 Siglas de Net Allocation Vector. Universidad de Granada
Eusebio J. Aguilera Aguilera
1.2 Control de acceso al medio en redes inalámbricas.
7
Figura 1.5: Diagrama de estados del protocolo CSMA/CA en el nodo origen
Figura 1.6: Diagrama de estados del protocolo CSMA/CA en el nodo destino Universidad de Granada
Eusebio J. Aguilera Aguilera
Introducción
8
1.2.1. Otras funciones de coordinación en redes inalámbricas. Además de la función de coordinación DCF, existen otras funciones para coordinar el acceso al medio en redes inalámbricas que sólo se implementan en un pequeño grupo de dispositivos o en algún estándar concreto de la familia IEEE 802.11x. A continuación se explica otras funciones de coordinación existentes de una manera breve, ya que no van a ser objeto de estudio en este trabajo. Así, existe la llamada función de coordinación de punto (o en inglés Point Coordination Function ) que utiliza el punto de acceso como sistema de control de acceso al medio y que por tanto, es el punto de acceso él que otorga el acceso al medio a todos los nodos que pertenezcan a la red. Además de la función de coordinación PCF existe otra función que sólo se implementa en el estándar 802.11e, conocida como función de coordinación híbrida (o en inglés Hybrid Coordination Function ). Esta función de acceso al medio de ne dos técnicas de acceso al canal, la primera conocida como HCCA11 y la segunda como EDCA12 . Las dos técnicas de acceso de nen una serie de clases de trá co que dan más prioridad en la red al trá co más urgente o importante, como por ejemplo las transferencias voz sobre lo correos electrónicos.
1.3. Ataques sobre redes inalámbricas. Existen numerosos ataques a diferentes elementos que conforman las redes inalámbricas. Se pretende en la presente sección explicar las variedades que existen y centrar la atención sobre los ataques de los que versa este proyecto. Un tipo de ataques son los que intentan romper la seguridad de una red inalámbrica por el componente de cifrado. Para ello se pueden utilizar técnicas que aprovechan las debilidades del sistema concreto que usa la red. Así, existen técnicas para poder romper la seguridad en redes que usan el sistema de cifrado WEP13 . Este sistema ha sido vencido y no se aconseja su uso en la actualidad. Asimismo hay posibilidades de romper la seguridad de la familia de sistemas de cifrado WPA/WPA214 , aunque en este caso el punto débil es la contraseña proporcionada al sistema y no el propio sistema. Es posible atacar otras partes de una red inalámbrica, por ejemplo suplantando el punto de acceso de una red (haciendo que el punto de acceso original caiga y suplantándolo después) y desconectando a un nodo de la red, haciendo que ese nodo se tenga que conectar y obteniendo por tanto la clave de acceso a la red. Todos los tipos de ataques anteriormente descritos tienen como nalidad última el conseguir el acceso a una red que de otra forma sería imposible. Sin embargo existen otros tipos de ataques cuyo objetivo es obtener unos recursos de red mayores que los otros nodos, es decir, conseguir más tasa de transferencia que los nodos vecinos. Estos ataques son conocidos como ataques de comportamiento egoísta. 11
Siglas de Hybrid Coordination Function Controlled Channel Access. Enhanced Distribuited Channel Access. 13 Siglas en inglés de Wired Equivalent Privacy. 14 Siglas de Wi- Protected Access.
12
Universidad de Granada
Eusebio J. Aguilera Aguilera
1.3 Ataques sobre redes inalámbricas.
9
1.3.1. Ataques de comportamiento egoísta. Originariamente las redes inalámbricas se usaban en lugares muy protegidos, como por ejemplo o cinas y lugares por el estilo, dónde es más sencillo garantizar el uso limpio de la red y mantener unas condiciones de calidad del servicio. Sin embargo en los últimos años, estas redes se han convertido en la solución estándar para suministrar acceso público a Internet. Los ataques de comportamiento egoísta realizan un mal uso del estándar 802.11 y su capa MAC, para así obtener una serie de objetivos, como por ejemplo ganar en tasa de transferencia en perjuicio de otros nodos conectados. Los bene cios de este tipo de ataques se pueden resumir en los siguientes puntos: Aumento de la tasa de transferencia de datos, siendo por tanto, un ataque más e ciente que se realice sobre la capa de transporte o de red, ya que tratan directamente con el medio inalámbrico. Estos ataques no son visibles a capas superiores a la MAC, por lo tanto, no serán descubiertos por mecanismos desarrollados para estas capas. Estos ataques son válidos para todo tipo de redes inalámbricas, puesto que todas ellas implementan como mínimo la función de coordinación DFC-MAC. El uso de estos ataques acarrea graves problemas en el reparto de la tasa de transferencia y por lo tanto en pérdida de calidad en el servicio. Este es un serio problema sobre todo en redes públicas de acceso a Internet, en las cuáles se paga el acceso y por ello es interesante realizar los ataques para incrementar la tasa de transferencia pagando lo mismo. Inicialmente los ataques que se proponen e implementan en el presente trabajo se aplican sobre redes inalámbricas que usan la función de coordinación DFC-MAC, pero se podrían adaptar a cualquier tipo de redes que usen un medio compartido para la transferencia de información. Se pueden realizar ataques de comportamiento egoísta basándose en el trá co de subida (desde los nodos al punto de acceso) o basándose en el trá co de bajada (desde el punto de acceso al nodo) como aparece descrito en [Buttyan-2008]. En el presente trabajo se implementan ataques basados en el trá co de subida, pues ofrecen ventajas sobre los otros ataques. En concreto estos ataques funcionan igual sobre todo tipo de trá co, no como los ataques concretos al trá co TCP o UDP (ataques de comportamiento egoísta de bajada); además no precisa condiciones especiales (sólo una red que funcione bajo el estándar 802.11) y es transparente a las capas superiores. Dentro de los ataques de comportamiento egoísta en el trá co de subida existen dos subgrupos: los ataques que provocan interferencias (también conocidos como ataques de jamming ) y los ataques que violan las especi caciones de DCF-MAC. Los ataques de jamming en concreto funcionan inter riendo en las transmisiones que realizan otros nodos, con el objetivo de aumentar su ventana de contención, y así, obtener una probabilidad mayor de envío. Para realizar esta tarea se pueden usar las siguientes tramas: Universidad de Granada
Eusebio J. Aguilera Aguilera
Introducción
10
Figura 1.7: Ataque jamming a trama CTS 1. Tramas CTS: Cuando un nodo tramposo escucha una trama RTS enviado por otro nodo a un tercero tiene que interferir en la conexión produciendo una colisión, y por lo tanto, perdiéndose la trama CTS para así evitar una secuencia de envíos largos (normalmente un saludo RTS/CTS se usa para realizar transferencias largas). El resultado de esto es que el canal queda libre después de la recepción de la trama CTS corrupta, el nodo que envió la trama CTS interferida dobla su ventana de contención y el nodo tramposo obtiene una mayor probabilidad de enviar sus datos. Esto puede verse en la Figura 1.7. En la Figura se puede ver que el nodo A realiza el envío de una trama RTS al punto de acceso en el instante t1 . El nodo tramposo envía después de escuchar la trama RTS en el instante t2 antes de que se complete la transmisión en el instante t3 . Se debe cumplir que los tiempos sean t1 > t2 > t3 . 2. Tramas ACK y de datos: Aunque interferir estas tramas no evita el tiempo de transmisión de los datos, causa que la ventana de contención del nodo destino de la trama ACK (el nodo origen de los datos) se doble y por lo tanto el nodo seleccione un tiempo de espera más largo. Igual que en el caso anterior se obtiene una probabilidad mayor de acceder al canal. Este comportamiento puede verse en la Figura 1.8. Un nodo que implementa los ataques de comportamiento egoísta que violan las especi caciones de la función de coordinación DFC-MAC puede manipularla y utilizar las siguientes estrategias para aumentar su tasa de transferencia: 1. Cuando el canal está libre, transmitir después de un tiempo SIFS y antes de DIFS. Así el nodo consigue casi siempre el acceso al medio, ya que, como se explicó anteriormente, todos los nodos normales esperan al menos un tiempo DIFS antes de intentar transmitir. 2. Cuando envía tramas de datos o RTS, estableciendo la duración (en la cabecera del mismo) a un valor alto, para que de este modo todos los nodos actualicen su NAV a un valor mayor del real y se contengan de enviar información durante el tiempo establecido. Universidad de Granada
Eusebio J. Aguilera Aguilera
1.3 Ataques sobre redes inalámbricas.
(a) Ataque sobre marco ACK
11
(b) Ataque sobre marco de datos
Figura 1.8: Ataque de jamming a trama de datos (a) y ACK (b) 3. Disminuir el tiempo de espera en caso de colisión, para ello, se selecciona una ventana de contención ja y de un valor bajo, para que de este modo siempre se elija un valor pequeño para la ventana. El nodo tramposo debe combinar todos estas técnicas o adaptarlas dependiendo de la situación para que sea más difícil la detección por parte de algún sistema externo. Las técnicas de ataque basadas en la violación de las especi caciones del comportamiento DFC-MAC son las que se implementan y prueban en el presente trabajo.
1.3.1.1. Explicación teórica de los ataques de violación de las especi caciones. Se han comentado brevemente los ataques que violan las especi caciones, pero ¾cómo funcionan? y ¾por qué deben dar esos resultados? Como se ha comentado anteriormente, un nodo puede esperar a que el canal esté libre y enviar después de un tiempo SIFS y antes de un tiempo DIFS. Pero, ¾por qué debería funcionar esto concretamente? Como aparece en la Sección 1.2, existen diferentes tiempos de espera para los nodos antes de iniciar una transmisión después de una exitosa. Los nodos normales transmiten después de esperar un tiempo DIFS que el canal esté libre. Sin embargo, si un nodo egoísta inicia la transmisión antes de que se cumpla ese tiempo DIFS consigue quedarse con el canal. Esto se puede ver más claramente en la Figura 1.9. Se observa en la misma que dos nodos Nodo 1 y Nodo 2 luchan por el acceso al medio. Una vez que el nodo Nodo 1 naliza de transmitir datos, ambos empiezan la espera para volver a intentar transmitir. Sin embargo el nodo Nodo 1 espera un tiempo DIF S , mientras que el nodo Nodo 2 espera un tiempo DIF S 0 que es menor. Por lo tanto, el nodo Nodo 2 tramposo se queda con el control del canal. Otra posibilidad es que un nodo egoísta puede modi car el campo de duración en una trama de datos o RTS. Para entender los bene cios que se obtienen con esta técnica es necesario comprender el funcionamiento del vector NAV que se explica en la Sección 1.2. Este vector lo utilizan los nodos para predecir la duración de una transmisión que se está Universidad de Granada
Eusebio J. Aguilera Aguilera
Introducción
12
Figura 1.9: Violación del tiempo DIFS de espera produciendo. Este valor se va actualizando mediante las duraciones establecidas por las tramas RTS y de datos que se envían durante la transmisión. Así es posible que un nodo egoísta, cuando establece la duración de una trama RTS o de datos, lo haga utilizando un valor superior al necesario para transmitir esa información. Además hay que tener en cuenta que el nodo egoísta debe establecer el valor correcto de duración en su propio NAV, para así obtener ventaja sobre los demás nodos. Así como se puede ver en la Figura 1.10, el nodo N2 envía una trama RTS para establecer una transmisión con el nodo N3. El nodo N2 establece el campo de duración de RTS (que incluye toda la duración de la transmisión) a un valor t1 superior al necesario para realizar la transmisión. Los nodos N1 y N3 ajenos a esta práctica, actualizan su NAV con ese valor t1 sobrestimado. Sin embargo, el nodo N2 actualiza su NAV con el valor t2 correcto de la duración, lo que le permite al mismo obtener el control del acceso al medio la siguiente vez que lo necesite, puesto que los demás nodos están esperando a que se termine la transmisión que ya ha terminado. Por último un nodo egoísta puede usar una ventana de contención pequeña y ja que le permita que en el caso de que se produzca una colisión, la ventana de contención que use sea siempre menor que la de los nodos vecinos que conforman la red. Así por ejemplo, un nodo N1 que tiene unos valores mínimo y máximo para la ventana de contención de [1, 16] consigue el acceso al medio frente a un nodo N2 que dispone de unos valores de [16, 1023]. Así, supóngase un escenario con dos nodos que tienen unos valores como las descritos anteriormente. En un escenario de este tipo imagínese además que se produce una colisión entre ambos nodos, por lo que según el estándar deben doblar su ventana de contención inicial, es decir, el Nodo 1 pasa de una ventana de contención de 1 a 2, mientras que el Nodo 2 pasa de 16 a 32. Después se escoge un valor entre [0, ventana_actual], que es el número de slots a esperar por el nodo antes de transmitir. Como es evidente el nodo egoísta elige siempre un valor entre [0, 2] que la mayoría de las veces es menor que el elegido por el nodo normal (entre [0, 32]). Se puede apreciar mejor este desarrollo en la Figura 1.11, en la que los nodos N1 y N2 colisionan al realizar un envío de una trama RTS. Esto produce que ambas ventanas de colisión tengan que doblarse y lanzarse posteriormente el algoritmo de parada exponencial (Exponential Backo Algorithm ). El Universidad de Granada
Eusebio J. Aguilera Aguilera
1.4 Objetivos del proyecto n de carrera.
13
Figura 1.10: Subestimaron de duración en las tramas RTS y datos nodo N1 selecciona un valor de 2 mientras que el nodo N2 que tiene una ventana mayor (y por tanto mayores posibilidades de seleccionar un valor mayor) elige un valor de 4. Tras que pasen 2 slots estando el medio libre el nodo N1 está habilitado para poder transmitir, mientras que el nodo N2 sigue esperando. Cuando pasa el siguiente slot y el nodo N2 vuelve a comprobar si el medio está libre, comprueba que ya no es así, por lo que para el contador y actualizar su NAV.
1.4. Objetivos del proyecto n de carrera. Una vez se han de nido los principales elementos necesarios para la comprensión del proyecto se va delimitar en esta sección qué se pretende realizar con el presente proyecto n de carrera, y qué objetivos se quieren conseguir con la ejecución del mismo. En primer lugar se van a implementar los ataques sobre la función de coordinación en redes inalámbricas (conocida como DFC-MAC) que violan las especi caciones del estándar, es decir, que no respetan el tiempo DIFS, utilizan tiempos altos en el campo de duración de las tramas y usan una ventana de contención pequeña y ja. Para el desarrollo de este trabajo se usa una herramienta de simulación de redes que permite la visualización de los datos obtenidos y el estudio del comportamiento de la red en general. La elección de la herramienta es tratada en la Sección 2.1 con un mayor detalle. Con la realización de este proyecto se pretenden conseguir una serie de objetivos que se detallan a continuación: Universidad de Granada
Eusebio J. Aguilera Aguilera
Introducción
14
Figura 1.11: Uso de ventana de contención pequeña y ja Conseguir un conocimiento más detallado del funcionamiento de las redes inalámbricas en general y de los aspectos de acceso al medio inalámbrico en particular. Obtener destreza en el manejo de una herramienta de simulación de redes y en el despliegue de proyectos de redes en estos sistemas. Mejorar las habilidades de gestión de proyectos informáticos en general, realizando todas las tareas que comprenden este tipo de trabajo. Obtener un conocimiento detallado del comportamiento de los ataques egoístas basados en violación de especi caciones de DFC-MAC, con el n de poder encontrar soluciones que mitiguen sus efectos. Para la consecución de estos objetivos es necesario seguir una metodología clara y lo más simple posible. Así es necesario de nir una plani cación razonable que sirve de guía tanto al alumno que la crea y desarrolla, como al tutor que la use para el seguimiento del proyecto. Las tareas principales que componen este proyecto son las que a continuación se especi can: 1. Plani cación del proyecto: Como se ha comentado anteriormente se pretende con esto disponer de una guía para comprobar que el proyecto se está llevando a cabo bien y en los plazos jados. 2. Análisis del problema: Antes de desarrollar una solución hay que delimitar el problema y analizar que posibles soluciones pueden satisfacerlo. 3. Diseño: Una vez se de na una solución se puede diseñar la misma en base a unos requisitos y siempre razonando todas las decisiones de diseños que se deban de tomar. 4. Implementación: Después de diseñar la solución se está en condiciones de llevarla a la práctica mediante el simulador de redes que se use. Universidad de Granada
Eusebio J. Aguilera Aguilera
1.4 Objetivos del proyecto n de carrera.
15
5. Pruebas y recogida de datos: Cuando la solución funciona de forma correcta se puede realizar las pruebas pertinentes y recoger los datos necesarios para conocer como se comporta la red. 6. Conclusiones: Posteriormente a la recogida de datos se pueden llegar a conclusiones en base a los mismos. Mediante estas conclusiones se puede ver el alcance concreto de estas técnicas sobre redes inalámbricas. Las acciones, resultados y análisis derivadas de todas estas fases se recopilan en los capítulos que vienen a continuación.
Universidad de Granada
Eusebio J. Aguilera Aguilera
16
Universidad de Granada
Introducción
Eusebio J. Aguilera Aguilera
Cap´ıtulo
2
Estado del arte e pretende en el presente capítulo dar una visión general de que trabajos se han realizado
Sen el campo de los estudios y simulaciones de redes relacionados con el trabajo que se de ne en este documento. Asimismo se explican las causas que han llevado a la elección de un simulador sobre otros disponibles para desarrollar el trabajo.
2.1. Simuladores de redes. Los simuladores de redes se usan para realizar todo tipo de pruebas y estudios sobre una red de unas características determinadas antes de ser desplegada. Además son útiles para realizar pruebas sobre un nuevo elemento que componga la red antes de ser implementado y así comprobar que merece la pena el gasto de desarrollar el nuevo dispositivo. Existen distintos simuladores de redes en el mercado, de diversos tipos y características. En esta sección se pretende hacer un estudio sobre los diferentes simuladores, así como de sus características principales, razonando la elección nal para la realización del proyecto.
2.1.1. OMNET++. Es uno de los principales simuladores de código abierto que existen en la actualidad. Las características de las que hace gala se pueden resumir en las siguientes:
Interfaz grá ca: Este no es un aspecto imprescindible en el uso de un simulador,
pero al igual que en la mayoría de programas el uso de una interfaz de usuario grá ca, hace que el usuario trabaje más cómoda e intuitivamente. La interfaz permite el desarrollo de un proyecto de estas características al completo, es decir, permite diseñar, desarrollar, simular y obtener los resultados del mismo. Se puede ver una captura del entorno OMNET++ 4.0 para Windows XP de desarrollo en la Figura 2.1.
Basado en componentes: Esta característica indica que el simulador tiene una serie
de componentes que se pueden usar para formar la topología de red, los comporta17
Estado del arte
18
Figura 2.1: Entorno de simulación OMNET++ mientos de los nodos, etc. Esto tiene la gran ventaja de poder usar componentes que ya han sido realizado desarrollados y probados y no tener que desarrollar la mayoría de los componentes.
Herramienta propia para visualización de resultados: Este entorno de simulación permite visualizar cómodamente las estadísticas obtenidas por la simulación.
Documentación: La documentación que tiene este entorno es de buena calidad y
permite poder empezar a trabajar casi de inmediato. Provee de documentación tanto del uso del entorno de desarrollo como de la librería de clases y todo lo relacionado con el desarrollo del modelo.
Compatible con estándar 802.11x: Este requisito es imprescindible para la reali-
zación del presente proyecto, puesto que se van a realizar ataques sobre la capa MAC de este estándar.
2.1.2. Network Simulator. Network Simulator 3 (más conocido como NS-3) es un simulador basado en eventos de código abierto licenciado bajo GPL21 . Este simulador tiene varias características que lo hacen interesante y entre las que se encuentran las siguientes: 1
Siglas de General Public Licence.
Universidad de Granada
Eusebio J. Aguilera Aguilera
2.1 Simuladores de redes.
19
Esta basado en clases: Este simulador esta escrito completamente en C++ y
Python, por lo que usa el paradigma de orientación a objetos tanto para su implementación como para su uso. Esto ayuda a que el desarrollo de simulaciones sea más cómodo, ya que, con menos código se expresa más contenido.
Simulaciones reales: Este simulador usa dos modos distintos en la simulación: 1. Un modo en el que máquinas virtuales se ejecutan sobre dispositivos creados mediante el simulador y que permiten realizar la simulación en entornos reales. 2. Un modo en el que varias máquinas reales con interfaces creadas mediante NS-3 se interconectan mediante una red real para realizar un banco de pruebas.
Permite modi car la red y todos los elementos en tiempo de simulación:
Esto es útil en caso de que sea necesario realizar algunas simulaciones sobre entornos cambiantes que siguen un patrón o que varían de forma arbitraria.
Usa la API2 POSIX3 de programación de redes: Por lo que permite que el paso de aplicaciones o manejadores de dispositivos (también conocidos como drivers ) más fácil y directa.
Sin embargo este simulador cuenta con algunos inconvenientes que hacen que su uso sea algo más tedioso que otros simuladores de redes. Así uno de los principales inconvenientes con los que cuenta el mismo es que no posee una interfaz de usuario grá ca, sino que, todo el trabajo se realiza mediante la terminal de línea de comando. Así para realizar las simulaciones y la posterior recogida de datos existe este inconveniente, que se traduce en un proceso más largo y tedioso, y por lo tanto existe una probabilidad más alta errores humanos. Otro inconveniente derivado del anterior es que puesto que no existe interfaz de usuario grá ca tampoco existe una herramienta grá ca para poder comparar estadísticas, sino que, es tarea del desarrollador el recoger los datos en bruto que devuelve el sistema por la terminal para que luego sean usados para generar grá cas, y posteriormente ser usadas en un estudio comparativo.
2.1.3. QualNet. Este es un simulador de redes comercial que dispone de licencia gratuita para nes no comerciales. Este simulador ofrece características muy notables para el desarrollo de redes. Algunas características interesantes son las que a continuación se detallan:
Simulación en paralelo: Este simulador permite que una simulación muy compleja pueda realizarse mediante el uso de computación distribuida, consiguiéndose así 2
Siglas de Aplication Program Interface. Es un acrónimo de Portable Operating System Interface, proviniendo la X de UNIX. Son una familia de estándares que persiguen la portabilidad de aplicaciones entre distintos sistemas operativos que los implementan. 3
Universidad de Granada
Eusebio J. Aguilera Aguilera
Estado del arte
20
Figura 2.2: Captura de pantalla de QualNet mayor velocidad en la simulación. Además está preparado para su uso en distintos procesadores y sistemas distribuidos varios.
Simulaciones en 3D: Permite que se puedan diseñar escenarios más realistas en tres dimensiones que permiten obtener unas simulaciones y visualizaciones de gran calidad. Herramienta de análisis de paquetes propia: El simulador viene con un visualizador de paquetes integrado, lo cual es una herramienta útil para poder depurar las simulaciones. Se puede ver una captura de pantalla del simulador en la Figura 2.2.
2.1.4. OpNet. Este es un simulador comercial que dispone de licencia gratuita para desarrollos de investigaciones y que sean para nes no comerciales en general. Presenta unas características buenas en general y que son destacables en algunos aspectos importantes en este proyecto:
Documentación: Posee una extensa documentación y de buena calidad en general y en particular sobre como realizar simulaciones en redes inalámbricas.
Orientado a componentes: Permite que las simulaciones puedan ser de nidas de una forma más modular y estructurada. Inserción de modelos propios: Permite insertar objetos desarrollados por un tercero dentro del simulador y así poder realizar las simulaciones con componentes novedosos.
Universidad de Granada
Eusebio J. Aguilera Aguilera
2.1 Simuladores de redes. Simulador/Característica Simulación inalámbrica Interfaz grá ca Visualizar resultados Documentación Total
21 OMNET++ 10 8 10 8 36
NS-3 7 0 0 7 14
QualNet 10 8 9 8 35
OPNET 10 9 9 9 37
Cuadro 2.1: Valoraciones de los simuladores
2.1.5. Selección del simulador. Se ha mostrado un conjunto representativo de lo que se puede encontrar en materia de simulación de redes en el mercado. A continuación se de nen una serie de características que se consideran necesarias para el desarrollo del presente trabajo y que van a ser evaluadas entre 0 y 10 dependiendo de la calidad de la característica en cada simulador. 1. Permitir simulación de redes inalámbricas con el estándar IEEE 802.11: Esta característica es imprescindible y por lo tanto si algún simulador no lo permite debe ser descartado. Además de que se permita o no la simulación de este tipo de redes se valora el grado de madurez que tiene esta característica en el simulador, es decir, si es una funcionalidad nueva se valora menos que si se supone que está a anzada en el mismo. 2. Disponer de una interfaz grá ca de usuario: Esta característica aunque no es estrictamente imprescindible, si hay que tenerla muy en cuenta, ya que, el hecho de no disponer de una interfaz cómoda hace que el desarrollo de las pruebas sea más largo y complejo. Además también se debe valorar la usabilidad de la interfaz y la claridad de la misma. 3. Disponer de una herramienta propia para visualización de resultados y estadísticas: Esto es una característica muy a tener en cuenta, debido a que facilita en gran medida la obtención de conclusiones (y la rapidez del proceso). De no disponer de esta herramienta es necesario la obtención de grá cas y comparación de estadísticas mediante herramientas externas (conllevando una pérdida de tiempo). 4. Buena documentación: Es necesario considerar si la documentación suministrada con el simulador es de buena calidad, puesto que de lo contrario puede llegar a retrasar mucho el desarrollo de la solución. Hay que tener en cuenta además que la calidad y cantidad de documentación sea adecuada. A partir de estas características se puede determinar que simulador de los anteriormente citados es más idóneo para el desarrollo del este trabajo. Así en la tabla 2.1 se puede ver las valoraciones para cada apartado. En base a lo dispuesto en la tabla 2.1 se puede llegar a la conclusión de que el simulador mejor posicionado en la comparativa es OPNET. Existen sobre todo un punto fuerte que lo Universidad de Granada
Eusebio J. Aguilera Aguilera
22
Estado del arte
hace el más idóneo para el desarrollo de este proyecto y que es su documentación cuidada y extensa en materia de redes inalámbricas la cual permite que las posibles dudas que surjan en la implementación se puedan solucionar de una forma más rápida. Además dispone de una herramienta potente para la visualización de estadísticas y resultados.
2.2. Antecedentes. Anteriormente al presente trabajo ha habido otros documentos que han abordado el tema del comportamiento egoísta, sin embargo, se ha hecho desde un punto de vista más teórico que práctico. Así son más numerosos los trabajos que versan sobre la forma hipotética en que se puede resolver el problema, más que los que abordan el estudio del mismo. Este es el caso del trabajo de [Cagalj-2005], dónde se realiza un estudio de las posibles alternativas que ofrecen los autores para detectar y evitar que el comportamiento egoísta descrito en la Sección 1.3.1 tenga éxito. Además plantean varios escenarios posibles para la detección y supresión del mismo: uno en el que el comportamiento es estático (es decir no cambia) y otro dinámico (el comportamiento egoísta se va adaptando a la situación).
Universidad de Granada
Eusebio J. Aguilera Aguilera
Cap´ıtulo
3
Especi cación de requisitos n el presente capítulo se va a dar una descripción más profunda acerca de todas las
E características que tiene que cubrir el trabajo desarrollado. Asimismo se van a de nir las restricciones que pueden afectar al diseño de la solución nal para solucionar el problema planteado.
3.1. Funcionalidades objetivo. Debido a que el presente trabajo no es un desarrollo de aplicaciones informáticas al uso, hay que tener en cuenta que algunos funcionalidades a alcanzar no son iguales a las que se podría esperar. Así las principales funcionalidades que son necesarias son las siguientes:
Control de tiempos DIFS: Esta funcionalidad pertenece al ataque por lo que
se considera como una funcionalidad básica que se debe implementar. Consiste en que como se explica en la Sección 1.3.1, el nodo atacante sea capaz de poder enviar información antes que los demás nodos.
Modi cación de tiempos en las tramas RTS y de datos: Esta funcionalidad
pertenece al ataque y se considera por lo tanto indispensable. Consiste en la sobrestimación de los tiempos en las tramas RTS y de datos para contener del envío de información por parte de los demás nodos.
Reducción de la ventana de contención: Consiste en la reducción intencionada
de la ventana de contención del nodo egoísta, con el objetivo de proveer al mismo un método de ventaja sobre los nodos normales.
Parametrización del ataque: Esta funcionalidad es secundaria, pero si es muy
deseable, ya que, ayuda a que el desarrollo de las simulaciones sea más rápido y menos propenso a errores tipográ cos y otros derivados de las tareas repetitivas. Consiste en que en las simulaciones del ataque, se puedan modi car el comportamiento del mismo sin que sea necesario modi car el código. Por ejemplo, activar una parte del 23
Especi cación de requisitos
24
ataque o modi car la ventana de contención sin necesidad de modi car el código que implementa el ataque.
Integración con el simulador: Esta característica es optativa pero muy recomen-
dable, puesto que, aunque es posible realizar el ataque de una forma no reusable, es mejor adaptar el ataque a las características del simulador para que el código y los elementos desarrollados sean lo más reusables posible. Es decir, se puede implementar el ataque de tal forma que sólo se pueda usar en este trabajo, o se puede desarrollar de manera que se pueda integrar con cualquier módulo que ya exista en el simulador y pueda relacionarse con ellos.
Acceso y con guración del ataque mediante la interfaz grá ca: Una característica muy necesaria para que las pruebas se puedan realizar de una forma rápida y con menos errores posibles, es que el mismo se pueda con gurar desde la interfaz grá ca de usuario que dispone el simulador.
3.2. Restricciones. En la mayoría de proyectos que se emprenden se encuentran una serie de elementos, componentes o situaciones que no se pueden modi car y que por lo tanto hay que tenerlas en cuenta antes de realizar los diseños que intentan solventar el problema propuesto. La principal restricción con la que hay que contar es que como queda re ejado en la Sección 2.1.5, el simulador elegido para la implementación del ataque es OPNET, y por consiguiente, tanto el diseño de la implementación como la implementación misma se realizan teniendo en cuenta como este simulador organiza las funcionalidades de las redes. Así, OPNET organiza las redes en componentes (que pueden estar organizados a su vez en más subcomponentes). El ataque debe implementarse como un componente de OPNET, que represente un nodo en una red, como por ejemplo una estación de trabajo, un ordenador personal, o algún computador por el estilo. Este conjunto de nodos está compuesto por una serie de subcomponentes que representan las diferentes capas de red que implementan. El ataque sobre el que trata este trabajo se implementa en la capa MAC inalámbrica, por consiguiente es este subcomponente el que hay que modi car. Otra restricción, que viene de la mano del simulador, es el lenguaje de implementación del ataque, puesto que, los componentes del mismo están implementados en C. Debido a esto el lenguaje de implementación del ataque debe ser obligatoriamente C. Como se comenta en la Sección 3.1, se pretende parametrizar el ataque. Puesto que se va a realizar la implementación en OPNET hay que tener en cuenta que el simulador cuenta con una interfaz grá ca que permite un manejo más simple e intuitivo del mismo a los usuarios y que por tanto la parametrización del ataque debe ser visible y modi cable desde la misma interfaz. Universidad de Granada
Eusebio J. Aguilera Aguilera
3.3 Resumen de requisitos del proyecto.
25
3.3. Resumen de requisitos del proyecto. Implementación completa y correcta del ataque: Esto es imprescindible para poder llegar a una serie de conclusiones sobre la efectividad o no del ataque que es objeto del estudio.
Implementación del ataque con restricciones del simulador: Las restricciones a tener en cuenta son las expuestas en la Sección 3.2, es decir, el código debe estar organizado en un módulo que represente un computador que posea interfaz inalámbrica. Además la implementación del ataque sólo debe estar presente en la capa MAC inalámbrica. Por último hay que tener en cuenta que toda la implementación ha de realizarse en lenguaje de programación C.
Parametrización del ataque: Se pretende, como se ha expuesto, que el ataque sea lo más reusable posible y que por lo tanto se tenga que modi car lo menos posible el código para adaptarlo. Así el hecho de poder con gurar los parámetros del ataque o activar y/o desactivar ciertas partes del mismo de forma externa al módulo, permite minimizar los cambios internos del código. También hay que reseñar que toda esta con guración debe ser accesible desde la interfaz grá ca que tiene el simulador OPNET. Evaluación del ataque: Esta es la segunda parte importante del proyecto. Esta
parte abarca todas las tareas necesarias para poder emitir un juicio lo más completo y coherente posible sobre el funcionamiento y potencia del ataque.
Universidad de Granada
Eusebio J. Aguilera Aguilera
26
Universidad de Granada
Especi cación de requisitos
Eusebio J. Aguilera Aguilera
Cap´ıtulo
4
Plani cación y estimación de costes ara la realización del proyecto, primero se han tenido que realizar una serie de estima-
P ciones y plani caciones con el objetivo principal de conocer si el proyecto es viable, tanto desde el punto de vista económico como temporal.
4.1. Plani cación del proyecto. Para realizar la plani cación del proyecto inicialmente se han de nido una serie de fases que hay que realizar para considerar que el proyecto está completo. Estas fases que se han llevado a cabo son las que a continuación se listan:
Fase de plani cación: Incluye la plani cación y seguimiento de todos los pasos necesarios que se han de nido para el desarrollo del presente trabajo.
Fase de estudio: Puesto que este proyecto se dedica a un tema novedoso y del cual no se tiene experiencia previa, es necesaria una fase de estudio para poder conocer los aspectos más importantes de la nueva técnica y así poder hacer frente al trabajo.
Fase de diseño: Es necesario que antes de desarrollar una solución al problema se de na bien todos sus aspectos. En esta fase se de ne el diseño que tiene que seguir la solución a implementar.
Fase de implementación: La fase incluye todas las tareas de desarrollo y pruebas necesarias para poder implementar el ataque que se de ne en la Sección 1.3.1, que es sobre el que trata el presente trabajo.
Fase de simulación y pruebas: Se pretende aquí realizar las simulaciones y pruebas necesarias y que permitan recoger los datos útiles para poder comprobar que el ataque es efectivo o no, y en que medida.
Fase de documentación: Esta última etapa se corresponde con el proceso completo de desarrollo y confección de la memoria. 27
Plani cación y estimación de costes
28
Estas fases se han desglosado a su vez en tareas más simples de delimitar y plani car que conforman las fases.
4.1.1. Paquetes de trabajo. De la relación de tareas anterior se pueden extraer una serie de paquetes de trabajo y los elementos entregables necesarios. Los paquetes de trabajo que se han de nido son los siguientes: 1. Fase de plani cación: Dentro de la plani cación se de nen dos fases diferentes de plani cación, una inicial en la que se de nen las tareas iniciales y su duración sin tener realimentación previa, y una fase posterior que rede nen las tareas, su duración, dependencias, etc. Los subpaquetes de trabajo que han sido de nidos son los siguientes:
a ) Plani cación inicial: Esta tarea se compone de una plani cación inicial en la
que se dan a los paquetes de trabajo una duración estimada. b ) Entrega de la plani cación inicial (Entregable). c ) Revisión de la plani cación: Consiste en la revisión de la plani cación pasado un periodo de desarrollo del proyecto, para así tener realimentación y que las estimaciones sean más ables. d ) Entrega de la revisión de la plani cación (Entregable). 2. Fase de estudio: Esta fase comprende los pasos necesarios para poder entender el ataque y por lo tanto que sea posible llevar a cabo su implementación. Así, dentro de la misma se pueden diferenciar varios subpaquetes de trabajo:
a ) Estudio CSMA/CA: Se corresponde con la tarea de comprender el funciona-
miento de la técnica de acceso al medio de dicho nombre, ya que el acceso al medio en redes inalámbricas está basado en la misma. b ) Estudio ataques: Esta tarea comprende el estudio y comprensión de los ataques que se tienen que implementar. c ) Estudio módulo inalámbrico del simulador: Esta tarea incluye el estudio del funcionamiento del módulo inalámbrico del simulador, es decir, comprender como funcionan las redes inalámbricas en el simulador, conocer los componentes con lo que cuenta el simulador, etcétera. d ) Estudio API programación OPNET: Esta tarea es necesaria para el buen desarrollo del presente trabajo, puesto que, la solución a implementar tiene que hacer uso de dicha API y por lo tanto es necesario tener una visión amplia de lo que se puede conseguir con la misma. 3. Fase de diseño: Esta fase se compone de todas las tareas necesarias para desarrollar el diseño de la solución al problema planteado por el proyecto. Universidad de Granada
Eusebio J. Aguilera Aguilera
4.1 Plani cación del proyecto.
29
a ) Diseño: La tarea se corresponde con la realización del diseño de la solución al problema planteado.
4. Fase de implementación: La fase de implementación se corresponde con la programación y revisión del ataque anteriormente descrito. Esta fase se compone de los siguientes subpaquetes de trabajo:
a ) Implementación del ataque. b ) Entrega de la implementación del ataque (Entregable). 5. Fase de simulación y pruebas: Esta fase está formada por las tareas necesarias para realizar las simulaciones y las pruebas al ataque que se ha implementado en la fase anterior. Incluye los siguientes subpaquetes de trabajo:
a ) Simulación y recogida de datos: Esta tarea está formada por la realización de todas las simulaciones y la recogida de los resultados que ofrecen las mismas.
b ) Entrega y discusión de los datos obtenidos: Con esta tarea se pretende que
los datos sean veri cados tanto por el desarrollador del proyecto como por el director del mismo. Es necesario que sean veri cados y aprobados los datos que se van a mostrar.
6. Fase de documentación: Esta fase se corresponde con el desarrollo de la documentación que debe mostrar todo el desarrollo del trabajo realizado. Esta fase se compone de los siguientes subpaquetes de trabajo:
a ) Crear la plantilla LATEX: Esta tarea de ne la plantilla que se usa en el proyecto y que por tanto es el aspecto grá co del documento resultante.
b ) Crear estructura documental: Se pretende de nir aquí la estructura que debe tener el documento en cuanto a la división de la información. Con dicha división se pretende que la información este mejor organizada y distribuida.
c ) Introducción del proyecto: La tarea incluye la confección del Capítulo 1 de la memoria del proyecto.
d ) Entrega de la introducción de la introducción del proyecto (Entregable). e ) Revisión de la plani cación: Esta tarea se corresponde con la revisión de la
introducción del proyecto para la corrección de los posibles errores y fallos que existan.
f ) Estado del arte: Se corresponde con la confección del Capítulo 2. En este capítulo se presenta una descripción general de algunos trabajos relacionados con el presente proyecto, además se describen algunos simuladores existentes y las razones que han llevado a la elección de OPNET.
g ) Entrega del Estado del arte (Entregable). Universidad de Granada
Eusebio J. Aguilera Aguilera
Plani cación y estimación de costes
30
h ) Especi cación de requisitos: Esta tarea representa la realización del Capítulo 3,
dónde se realiza una de nición de los requisitos que se deben cumplir para que se considere nalizado el proyecto.
i ) Entrega de la Especi cación de requisitos (Entregable). j ) Plani cación y estimaciones de costes: La tarea incluye la realización del Capítulo 4.
k ) Entrega de la Plani cación y estimación de costes (Entregable). l ) Diseño: Esta tarea se corresponde con la confección del Capítulo 5, en el que se realiza una de nición del diseño que se utiliza para la implementación del ataque.
m ) Entrega del diseño (Entregable). n ) Implementación: La tarea la confección del Capítulo del proyecto 6, en el que se realiza una especi cación clara de cómo se lleva a cabo la implementación en base al diseño especi cado.
ñ ) Entrega de la implementación (Entregable). o ) Evaluación: Incluye la realización del Capítulo 7, que tratan acerca de los puntos positivos que se consiguen con la solución propuesta.
p ) Entrega de la Evaluación (Entregable). q ) Conclusiones: Representa la confección del Capítulo 8. r ) Entrega de la memoria completa (Entregable). s ) Como realizar un módulo para OPNET: Crear un documento anexo a la memoria que recoge todos los pasos principales para realizar un módulo nuevo en OPNET.
t ) Entrega de documento anexo (Entregable). 7. Preparación de la defensa: Este paquete de trabajo incluye la realización de las transparencias que acompañan a la exposición del trabajo realizado en el proyecto.
4.1.2. Diagrama de Gantt. A continuación se muestra el diagrama de Gantt resultante y que de ne la plani cación completa del proyecto. Universidad de Granada
Eusebio J. Aguilera Aguilera
6d
Work
5d
Name
Planificación inicial
Estudio CSMA/CA
10d
5d
5d
40d
1d
Fase de planificación
Entregar la planificación inicial Revisión de la planificación Entrega de la revisión de la planificación
Estudio ataques
20d
Fase de estudio
Estudio simulador del módulo inalámbrico
8d
30d
30d
14d
14d
Estudio API de programación OPNET
Diseño del ataque
Fase de diseño
Fase de implementación Implementación del ataque Entrega del ataque
oct 2008
Eusebio
Eusebio
Eusebio
nov 2008
Eusebio
dic 2008
Eusebio
2009, H1 ene 2009
Eusebio Eusebio
feb 2009
mar 2009
abr 2009
Eusebio Eusebio
may 2009
jun 2009
Eusebio
Eusebio
Fase de simulación y pruebas 7d
Eusebio
Eusebio
Eusebio
1d
Eusebio
Eusebio
Eusebio
Simulación y recogida de datos del primer ataque
10d
Eusebio
Eusebio
Eusebio
Eusebio
Eusebio
Eusebio
Eusebio
Eusebio
2009, H2
jul 2009
Eusebio
Eusebio
Eusebio
Eusebio
Eusebio
Eusebio
Eusebio
Entrega y discusión de los datos obtenidos
2d
3d
86d
Crear estructura documental 10d
Crear la plantilla LaTeX
Fase de documentación
Introducción del proyecto
14d
Entrega de la introducción del proyecto Revisión de la introducción
10d
7d
5d
10d
8d
5d
5d
7d
Estado del arte Entrega de Estado del Arte Especificación de requisitos Entrega de la especificación de requisitos Planificación y estimación de costes Entrega de la planificación y estimación de costes Diseño Entrega del diseño Implementación Entrega de la implementación Evaluación Entrega de la Evaluación Conclusiones Entrega de la memoria completa Como realizar un módulo para OPNET Entregar documento anexo Preparación de la defensa
ago 2009
sep 2009
oct …
Eusebio J. Aguilera Aguilera
Universidad de Granada
31
4.1 Plani cación del proyecto.
Plani cación y estimación de costes
32
4.2. Estimación de recursos. Para realizar la estimación de recursos del proyecto se ha tenido en cuenta el coste que supone tener a un ingeniero trabajando en el proyecto, suponiendo un sueldo medio. Asimismo, se han hecho unas estimaciones de la duración de cada una de las tareas en horas de trabajo. Además hay que tener en cuenta los recursos materiales y el material fungible. Con esto se consigue poder hacer una estimación aproximada del coste de los recursos humanos del proyecto. A continuación se presenta un listado de todos los elementos tanto materiales como humanos que son necesarios para llevar a cabo el proyecto: 1. Recursos humanos: A este apartado pertenece el desarrollador del proyecto que se encarga de todos las fases descritas anteriormente en la Sección 4.1. Además del esfuerzo del alumno desarrollador, hay que tener en cuenta el tiempo que se necesita para poder revisar el trabajo del desarrollador, realizado por el profesor director del proyecto. 2. Recursos materiales: En este apartado se pueden distinguir entre material inventariable, que es material que no se gasta diariamente; y material fungible, que se gasta a diario.
a ) Material inventariable: Dentro de este subapartado se encuentran los siguientes materiales: 1) 2) 3) 4) 5) 6) 7)
Ordenador portátil. Licencia de Opnet . Licencia de editor LYX. Licencia de sistema operativo Windows XP SP 2 Licencia del plani cador de tareas Planner. Licencia del paquete o mático OpenO ce. Licencia de la aplicación de diagramas DIA.
©
©.
b ) Material fungible: Aquí cabe mencionar todos los materiales necesarios para poder realizar el proyecto que tienen un gasto más frecuente como papel y tinta de impresora.
Para realizar la estimación económica de los recursos humanos del proyecto se debe seleccionar también un coste del trabajador por hora. Con esto y la estimación temporal se puede calcular una estimación económica de lo que costaría los recursos humanos en el desarrollo del proyecto. La estimación temporal da un número de horas de trabajo igual a 850 horas de trabajo, a lo que hay que añadir la estimación de la supervisión del trabajo, lo que se ha estimado en unas 30 horas; obteniéndose un total de 880 horas. Suponiendo un salario bruto de 2000 euros al mes se obtiene un coste de 12,5 euros a la hora. Así se obtiene la siguientes cifra:
¿
12,5 × 880 = 11000
Universidad de Granada
Eusebio J. Aguilera Aguilera
4.2 Estimación de recursos.
33
A esta cifra hay que añadir los costes de todos los materiales y software que se han empleado para el desarrollo del proyecto. En la Tabla 4.1 se puede ver un resumen de los materiales empleados para realizar el proyecto, así como las aplicaciones informáticas empleadas en el mismo. Una vez tenidos en cuenta todos los recursos necesarios para llevar a cabo el proyecto se puede hacer una estimación del coste total del desarrollo del mismo. Así si se suman todas las cantidades que se exponen en la Tabla 4.1 y a esto se le añade la estimación de los recursos humanos, se obtiene una cifra de 11000 + 585 + 80 + 100 = 11765 .
¿
Universidad de Granada
Eusebio J. Aguilera Aguilera
Plani cación y estimación de costes
34
Recurso
Descripción
Ordenador portátil Editor de textos LYX
Ordenador portátil MSI Mega Book VR 301x. Este editor de texto permite realizar la edición de documentos LATEX. http://www.lyx.org/ El desarrollo del proyecto se ha realizado sobre este sistema operativo debido a cuestiones de restricciones. Esta herramienta permite realizar la gestión de un proyecto mediante diagramas de Gantt.
Sistema Operativo Windows XP
©
Plani cador Planner
http://live.gnome.org/Planner
Simulador OPNET
©
OpenO ce Impress
0 80
0
0
Este programa permite crear diagramas varios, que van desde un diagrama de la arquitectura de red, a diagramas UML.
0
©
Gastos de impresión y encuadernación
585
Este simulador permite realizar los despliegues de la red y realizar las simulaciones del ataque. Se usa una licencia educativa. El coste asociado a la licencia es cero debido a que se usa una licencia académica. Esta aplicación permite realizar presentaciones al estilo de PowerPoint . http://es.openoffice.org/
DIA
Coste (euros)
http://projects.gnome.org/dia/
0
100
Cuadro 4.1: Recursos materiales empleados
Universidad de Granada
Eusebio J. Aguilera Aguilera
Cap´ıtulo
5
Diseño n el presente capítulo se va a realizar una descripción de la solución que ha sido sele-
E ccionada entre todas las posibilidades, además de explicar las razones que han llevado a seleccionar dicha solución sobre las demás propuestas.
5.1. Arquitectura del sistema. Como primera aproximación a la solución nal hay que comentar que debe tener una arquitectura que permita satisfacer las restricciones comentadas en la Sección 3.2. Como se comenta en esa sección, el ataque se debe emplazar de tal forma que coincida con la arquitectura del simulador y la organización que éste hace de las funcionalidades de red. Así y puesto que el ataque se realiza en la capa MAC inalámbrica de un nodo de la red, se tiene en cuenta que la arquitectura en la que se encuadra es la que aparece en la Figura 5.1. Como se aprecia en dicha gura el ataque se debe implementar en un nodo de OPNET que represente por ejemplo una estación de trabajo que disponga de una interfaz inalámbrica. Como se comenta en la Sección 2.1.5, el simulador OPNET ordena las funcionalidades de red en nodos, que representan elementos físicos de una red. Así, cada uno de estos nodos está formado a su vez por un conjunto de módulos que representan, cada uno de ellos, una funcionalidad concreta del nodo superior. Por lo tanto, el nodo que se ha presentado en la Figura 5.1 es un nodo de OPNET que representa una estación de trabajo, mientras que cada capa que se puede ver en el diagrama se implementa en un módulo aparte. De esta forma, queda claro que el ataque se debe implementar en un módulo que represente la capa MAC inalámbrica de una estación de trabajo (aunque puede ser cualquier nodo de OPNET que represente un nodo computador de una red inalámbrica). En este punto hay que tomar la primera decisión relacionada con la arquitectura del sistema. Hay dos posibles opciones para realizar un nuevo módulo que implemente el ataque dentro de la capa MAC inalámbrica: primero se puede desarrollar la implementación de un módulo que contenga lo mínimo para que funcione la capa MAC e implementar allí el ataque, mientras que la otra posibilidad es utilizar un módulo que ya tenga la capa MAC y modi carlo para añadir el ataque dentro. 35
Diseño
36 Nodo de red de OPNET
Capa TCP
Capa IP
Capa MAC
Implementación del ataque
Capa Física
Figura 5.1: Arquitectura software necesaria
Primero se analizan las ventajas e inconvenientes que presenta la primera de las opciones. Programar un nuevo módulo que implemente las características básicas de la capa MAC inalámbrica supone realizar un esfuerzo grande de documentación tanto sobre la programación de un nuevo módulo para OPNET como acerca del funcionamiento de la capa MAC inalámbrica en sí. Además es necesario un gran esfuerzo para llevar a cabo la implementación y depuración del nuevo módulo. Después de todo esto se tiene que realizar la implementación del ataque, lo que supone un esfuerzo mucho menor en comparación. La otra opción es seleccionar un módulo existente que implemente la capa MAC inalámbrica de un nodo de OPNET y modi carlo para añadirle el ataque. Esta opción requiere de un esfuerzo por conocer el funcionamiento de la capa MAC inalámbrica así como el de un módulo de OPNET. Sin embargo esta alternativa no necesita que se gaste el tiempo en el desarrollo y la depuración del módulo, puesto que se supone que funciona correctamente. La segunda de las opciones posibles es mejor que la primera, puesto que ahorra el tiempo de implementación y depuración de un módulo nuevo, que por otra parte ya está implementado en otros módulos. Así, en base a los argumentos expuestos, la opción más conveniente es realizar la implementación del ataque en un módulo existente y que implemente la capa MAC inalámbrica. Universidad de Granada
Eusebio J. Aguilera Aguilera
5.2 Diseño del sistema.
37
Figura 5.2: Máquina de estados nitos del módulo wlan_mac
5.2. Diseño del sistema. El sistema que se pretende diseñar es muy dependiente del módulo de OPNET que implementa la capa MAC inalámbrica, por lo tanto, es necesario conocer más en profundidad su funcionamiento. Todos los módulos que implementan una capa de red en OPNET están implementados mediante varios elementos lógicos. Así se pueden separar como mínimo dos de ellos: la máquina de estados nitos y las funciones. La máquina de estados nitos representa todos los estados en los que puede estar esa capa de red y cómo se realizan las transiciones entre esos estados. Por otra parte las funciones son las implementan el comportamiento de la capa en cada uno de los posibles estados que puede tener el módulo. Para realizar el diseño del sistema es necesario comprender ambas partes del módulo, para poder determinar como adaptar el ataque al comportamiento estándar del módulo.
5.2.1. Máquina de estados nitos del módulo. En esta subsección se analiza la máquina de estados nitos que posee el módulo que implementa la capa MAC inalámbrica en OPNET, conocido como wlan_mac. Los estados y transiciones que componen la máquina de estados nitos del módulo, son los que aparecen en la Figura 5.2. Se puede ver en la gura los estados (los nodos de colores) y las transiciones entre estados (las echas). En los estados se pueden diferenciar dos elementos distintos, el código de entrada al estado y el de salida. El código de entrada es el que se ejecuta cuando se Universidad de Granada
Eusebio J. Aguilera Aguilera
Diseño
38
inicia un determinado estado, mientras que el código de salida es aquel que se ejecuta justo antes de que se produzca la transición a otro. Se puede apreciar como aparecen dos tipos de nodos que representan estados. Unos nodos de color rojo y otros de color verde. Los nodos de color rojo son de tipo no forzado, lo que quiere decir que cuando estos nodos terminan de ejecutar el código de entrada en el estado, pasan el control de la ejecución al núcleo del simulador. Por contra los nodos verdes son los de tipo forzado y no pasan el control al kernel cuando se naliza el código de entrada, sino que se ejecutan por completo y pasan al estado correspondiente. Para saber más acerca de la máquina de estados nitos se puede consultar el Apéndice A, anexo de este documento. A continuación se de nen todos los estados que aparecen en la Figura 5.2 y se explica para que sirve cada uno de ellos. INIT: Este estado es el encargado de realizar la inicialización de algunos valores internos de la capa MAC, mediante la llamada a algunas funciones de nidas por el módulo. BSS_INIT: El estado inicializa los valores de la red, es decir, nombre de la red (Basic Service Set ). IDLE: Estado de inactividad de la capa MAC. Este estado está activo siempre que no existan más tramas a enviar y no se esté recibiendo otra. DEFER: Este estado espera hasta que el medio esté listo para transmitir. En este estado pueden ocurrir una serie de eventos: 1. Se lanza una interrupción, indicando que han llegado datos desde una capa superior. 2. Se lanza una interrupción que indica que se han recibido datos desde la capa física. 3. Se está recibiendo una trama. 4. Se lanza una interrupción que señala que ha habido una colisión, por que se está recibiendo más de una trama al mismo tiempo. 5. El temporizador de espera ha expirado, por lo que se considera el medio libre. BACKOFF_NEE: En este estado se determina si es necesario lanzar el algoritmo de parada binario o no, dependiendo de si ha pasado un tiempo superior a DIFS sin que nadie haya querido transmitir. BACKOFF: Procesa el algoritmo de parada binario. TRANSMIT: Este estado prepara las tramas para ser enviadas, estableciendo los datos de las cabeceras. FRM_END: Sirve para determinar cual es el estado siguiente después de terminar la transmisión de una trama. Se pueden dar las siguientes posibilidades: Universidad de Granada
Eusebio J. Aguilera Aguilera
5.2 Diseño del sistema.
39
1. Si se ha transmitido una trama RTS o de datos se pasa a esperar la respuesta adecuada. 2. Si se ha recibido la trama esperada, entonces se comprueba cual es la siguiente trama a enviar y se establece el temporizador de espera.
a ) Si se han enviado todas las tramas se comprueba si la cola está vacía o no. En caso de que no esté vacía, se selecciona la siguiente trama y se fragmenta (dependiendo del umbral de fragmentación) y se envía una trama RTS (dependiendo del umbral RTS). b ) Si no hay nada para enviar se pasa al estado IDLE.
3. Si no llega la trama esperada y aún no se ha alcanzado el límite de retransmisiones, se vuelve a enviar la trama que no ha obtenido una respuesta satisfactoria. WAIT_FOR: Este estado sirve para esperar la respuesta después de la transmisión. SCAN: Estado necesario para realizar una búsqueda de nuevas redes inalámbricas. Como se ha comprobado los estados sirven para saber en que fase se encuentra la capa MAC, pero no para realizar las acciones propiamente dichas. Es decir, cuando la capa MAC se encuentre en estado de transmisión, indica que se está transmitiendo, pero la transmisión la realizará una función aparte. Por tanto la implementación del ataque se debe realizar en la funciones que implementen determinadas partes. Se han de conocer, por tanto, las funciones que implementan algunas funcionalidades del estándar 802.11, entre las que se encuentran la inicialización de los valores mínimos y máximos para la ventana de contención, la función que prepara las tramas antes de ser enviadas y la función encargada de realizar la espera entre tiempos. Las funcionalidades de la capa MAC inalámbrica de nida en OPNET se dividen en dos módulos bien diferenciados. Así, existe uno de ellos que se denomina wlan_dispatch, mientras que el otro se llama wlan_mac. El primero de ellos realiza las comprobaciones iniciales de la capa MAC, así como determina que función de acceso al medio se va a usar en la red inalámbrica actual. El módulo wlan_mac es la implementación de la capa MAC inalámbrica que contiene las funciones de acceso al medio DCF y PCF. Por tanto es necesario modi car los dos módulos para la implementación del ataque, wlan_dispatch para que inicie los valores necesarios para funcionar y cargue el módulo wlan_mac modi cado, y wlan_mac que contendrá el ataque. Como se ha visto, el ataque se debe implementar en el módulo wlan_mac de OPNET. Sin embargo, antes de implementarlo hay que conocer como funciona este módulo. El módulo se divide en una serie de funciones que implementan las distintas partes de la capa MAC de nida en el estándar IEEE 802.11. Entre todas las funciones que se encuentran de nidas, las más relevantes son: wlan_mac_sv_init: Esta función realiza la inicialización de la capa MAC, tanto de los valores iniciales para determinados parámetros (entre los que se encuentran Universidad de Granada
Eusebio J. Aguilera Aguilera
Diseño
40
los valores mínimo y máximo de la ventana de contención), como de las estadísticas que la misma recoge durante el transcurso de la simulación. wlan_prepare_frame_to_send: Esta función es la que se encarga de crear una trama antes de ser enviada, es decir, la función que inicializa los valores de la cabecera de la trama antes de que sea insertada en la cola para que se envíe. Además es en esta función en la que los nodos actualizan su NAV, ya que, también es aquí dónde se calcula la duración en la transmisión. wlan_slot_time_set: Se calculan todos los valores asociados al valor que se le pasa como parámetro slot_time, es decir, se volverán a calcular valores de los tiempos DIFS, PIFS y EIFS. wlan_data_process: Esta función se encarga de realizar el procesamiento de los datos que llegan de capas inferiores, es decir, que realiza el proceso de ensamblado en caso de que se haya enviado un paquete fragmentado. wlan_schedule_deference: Esta función es la encargada de realizar la plani cación para que no se produzcan colisiones entre los nodos, además de comprobar que se esperan los tiempos DIFS entre transmisiones correctas y tiempos SIFS entre tramas de la misma conversación. wlan_frame_discard: La función comprueba que no se ha alcanzado el límite de retransmisiones para alguna trama. En caso contrario la función descarta esa trama que ya no es retransmitida más veces. wlan_begin_new_scan: Comprueba la existencia de otra red para poder realizar una conexión a la misma. wlan_ap_switch: La función realiza un cambio de un punto de acceso a otro nuevo que haya sido evaluado con la función wlan_begin_new_scan. Aunque existen más funciones dentro del módulo, son éstas las que tienen un mayor interés general. Para conocer más sobre las funciones que suministra OPNET se puede acceder al Apéndice A. Por último para realizar la parametrización del ataque, y que además sea accesible desde la interfaz grá ca de usuario, es necesario que primero se de nan los parámetros que se van a acceder mediante la interfaz, lo que se consigue mediante el editor de atributos del nodo que suministra OPNET; y segundo hay que cargar dichos parámetros para que sean accesibles al código de las funciones que de nen el comportamiento, lo cual se hace en la función de inicialización de la capa MAC wlan_mac_sv_init. Esto se explica con mayor detenimiento y profundidad en la Capítulo 6, dónde se describe la implementación del ataque, más concretamente en la Sección 6.2.1. Como se explica en la Sección 1.3.1, los ataques que se van a implementar consisten en el envío de las tramas después de SIFS pero antes de DIFS, la modi cación de la duración de las tramas RTS y de datos, y el establecimiento de una ventana de contención ja Universidad de Granada
Eusebio J. Aguilera Aguilera
5.2 Diseño del sistema.
41
y pequeña. Estas acciones se llevan a cabo en las funciones wlan_schedule_deference, wlan_prepare_frame_to_send y wlan_mac_sv_init respectivamente, por lo que son estas funciones las que hay que modi car.
Universidad de Granada
Eusebio J. Aguilera Aguilera
42
Universidad de Granada
Diseño
Eusebio J. Aguilera Aguilera
Cap´ıtulo
6
Implementación na vez de nido el diseño a seguir para la solución al problema, es necesario explicar cómo se ha implementado dicho diseño. Así, a continuación se pasa a hacer un comentario más profundo acerca de los detalles de la implementación de la solución elegida.
U
6.1. Herramientas para la implementación. Para el desarrollo de la solución han sido necesarias una serie de herramientas, algunas de ellas imprescindibles y otras que han sido complementarias para el proceso. En primer lugar se ha utilizado el simulador OPNET que dispone de las herramientas de simulación y el editor de código integrados dentro del entorno de simulación. Puesto que ya se ha realizado una descripción de cuáles eran las razones por las que se ha elegido este simulador en la Sección 2.1.5, no se van a volver a especi car las características del mismo. Es necesario para el uso de este simulador tener un compilador de C/C++ instalado en la máquina dónde se realiza el desarrollo. Así, los requisitos del simulador establecen que el compilador necesario es alguno de los compatibles con la versión de Windows: Microsoft Visual C/C++ 6.x, Microsoft Visual Studio .NET 2002, Microsoft Visual Studio .NET 2003, Microsoft Visual Studio 2005, Microsoft Visual Studio 2008, o Microsoft Visual C++ 2008 Express Edition. Para el desarrollo de la solución se ha usado Microsoft Visual Studio 2005 del cual se disponen licencias de uso. Puesto que es un requisito del simulador no hay posibilidad de usar otro compilador de C/C++, al menos si no se dispone de otra versión de OPNET para otro sistema operativo. Además para el desarrollo es necesario usar un depurador de código, el cual se ha usado el que provee el propio simulador OPNET. Para el desarrollo de la solución se ha estimado necesario el uso de un sistema de control de versiones, tanto para el código que implementa el ataque, como para la documentación generada. Así la herramienta elegida para este menester ha sido Bazaar Version Control (http://bazaar-vcs.org/). Este sistema de control de versiones distribuido, permite realizar el control de las versiones de un proyecto de forma más versátil que otras herramientas 43
Implementación
44
similares pero que tienen un modelo centralizado. Así, esta herramienta permite que el ujo de trabajo pueda ser con gurado de diversas formas, dependiendo de cuál sea la más indicada en cada caso.
6.2. Desarrollo de la solución. Para el desarrollo de la solución se han localizado las funcionalidades que se deben de modi car para conseguir como resultado la implementación del ataque.
6.2.1. Exportación de parámetros a la interfaz grá ca. Una de los requisitos que se especi can en la Sección 3.1 es que los parámetros del ataque sean accesibles desde la interfaz grá ca de usuario. Para poder realizar esta labor es necesario realizar dos tareas bien diferenciadas. En primer lugar hay que de nir los atributos que van a ser accesibles desde la interfaz grá ca de usuario. Para ello OPNET brinda un editor de atributos del modelo. De este modo, sólo es necesario dirigirse al modelo sobre el que se va a trabajar, en este caso el modelo wlan_dispatch_cheater, y seleccionar la opción Model attributes del menú Interfaces. Esto se puede ver en la Figura 6.1. Si se selecciona esta opción aparece un diálogo como el de la Figura 6.2, dónde se pueden ver los atributos del nodo a más alto nivel, es decir, aquellos que aparecen cuando se visualizan los atributos nodo de la red (botón derecho sobre el nodo y selección de la opción Edit Attributes). A partir de este momento se pueden de nir atributos compuestos o simples. Los atributos compuestos son atributos que representan un grupo de atributos relacionados. En este caso se ha de nido un grupo de atributos llamado Node cheats que representa todos los parámetros del ataque. Por otra parte los atributos simples representan los parámetros que se le pasan al nodo. Una vez de nido un grupo de de atributos se puede bajar en la jerarquía mediante el botón Edit Properties. Los parámetros de nidos dentro del grupo de parámetros Node cheats son los que aparecen en la Figura 6.3. En la gura se puede ver los siguientes parámetros de nidos: DIFS time percent: Es un grupo de parámetros que contiene los parámetros que representan el mínimo y el máximo valor que puede tomar el porcentaje de tiempo DIFS que se espera antes de enviar una trama. DATA and RTS time eld modi cator: Modi cador del campo de tiempo de las tramas de datos y RTS. Este parámetro actúa de multiplicador sobre el campo tiempo de las tramas de datos y RTS. Contention Window value: Grupo de valores que contiene los parámetros que representan los valores mínimo y máximo que puede tomar la ventana de contención del nodo egoísta. Sel sh behaviour parameter: Este parámetro establece el valor probabilístico de actuación del comportamiento egoísta. Es decir, representa el porcentaje de veces Universidad de Granada
Eusebio J. Aguilera Aguilera
6.2 Desarrollo de la solución.
45
Figura 6.1: Selección de atributos del modelo
Figura 6.2: Diálogo para de nir los atributos del modelo
Universidad de Granada
Eusebio J. Aguilera Aguilera
Implementación
46
Figura 6.3: Parámetros de nidos para el ataque que el nodo actúa con comportamiento egoísta. En caso de que el valor sea cero se desactiva completamente el comportamiento egoísta en el nodo, por lo que actuaría como un nodo normal. Log debugging: Activa o desactiva el depurado por consola del nodo egoísta. Si se activa este parámetro entonces el nodo egoísta registra información importante en el log del simulador, que posteriormente puede ser consultada. Todos estos parámetros se tienen que cargar en el código del módulo para que sean accesibles al mismo. Así esta labor se realiza en el código de inicialización del módulo wlan_mac_cheater (función wlan_mac_sv_init). Este código se puede ver en el Listado de código 6.1. El funcionamiento del código es sencillo: la función llamada op_ima_obj_attr_get devuelve el valor de un atributo (ya sea simple o complejo), mientras que la función op_topo_child devuelve el manejador de los atributos hijos del que se pasa por parámetro. Así para obtener el valor de los distintos parámetros sólo hay que moverse por la jerarquía de atributos y cuando se llegue al nivel dónde está el atributo obtener el valor. Por ejemplo, para el valor mínimo de la ventana de contención, hay que obtener el valor del atributo compuesto Contention Window values (lo cual se hace en la línea 15), posteriormente se baja en la jerarquía de ese atributo para acceder a los atributos hijos (acción que se hace en la línea 16). Por último se accede al valor del atributo llamado Contention Window min que es el que se quiere acceder, en la línea 18. Para el resto de atributos de nidos se actúa de forma similar. Listado de código 6.1: Código para obtener los valores de los parámetros del módulo 1
/* Obtain t h e v a l u e s a s s i g n e d t o t h e v a r i o u s a t t r i b u t e s */ Universidad de Granada
Eusebio J. Aguilera Aguilera
6.2 Desarrollo de la solución. 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
47
op_ima_obj_attr_get ( my_objid , "Node Cheats " , &cheater_attrs_cmp ) ; c h e a t e r _ a t t r s = op_topo_child ( cheater_attrs_cmp , OPC_OBJTYPE_GENERIC, 0 ) ; // Obtain DATA & RTS time f i e l d m o d i f i c a t o r , s e l f i s h b e h a v i o u r parameter and l o g debugging op_ima_obj_attr_get ( c h e a t e r _ a t t r s , "DATA and RTS time f i e l d m o d i f i c a t o r " , & cheater_time_field_modificator ) ; op_ima_obj_attr_get ( c h e a t e r _ a t t r s , " S e l f i s h b e h a v i o u r parameter " , & cheater_selfish_behaviour ) ; op_ima_obj_attr_get ( c h e a t e r _ a t t r s , "Log debugging " , &cheater_log_debugging ) ; op_ima_obj_attr_get ( c h e a t e r _ a t t r s , "DIFS time p e r c e n t " , &cheater_attrs_cmp ) ; c h e a t e r _ a t t r s = op_topo_child ( cheater_attrs_cmp , OPC_OBJTYPE_GENERIC, 0 ) ; // Obtain DIFS time p e r c e n t min and max op_ima_obj_attr_get ( c h e a t e r _ a t t r s , "DIFS min" , &cheater_DIFS_min ) ; op_ima_obj_attr_get ( c h e a t e r _ a t t r s , "DIFS max" , &cheater_DIFS_max ) ; op_ima_obj_attr_get ( my_objid , "Node Cheats " , &cheater_attrs_cmp ) ; c h e a t e r _ a t t r s = op_topo_child ( cheater_attrs_cmp , OPC_OBJTYPE_GENERIC, 0 ) ; op_ima_obj_attr_get ( c h e a t e r _ a t t r s , " C o n t e n t i o n Window v a l u e s " , &cheater_attrs_cmp ) ; c h e a t e r _ a t t r s = op_topo_child ( cheater_attrs_cmp , OPC_OBJTYPE_GENERIC, 0 ) ; // Obtain cW min and max v a l u e s op_ima_obj_attr_get ( c h e a t e r _ a t t r s , " C o n t e n t i o n Window min" , &cheater_CW_min ) ; op_ima_obj_attr_get ( c h e a t e r _ a t t r s , " C o n t e n t i o n Window max" , &cheater_CW_max ) ;
6.2.2. Inicialización y carga inicial de parámetros de ataque. Hay que distinguir las dos partes bien diferenciadas que componen la implementación de la capa MAC inalámbrica en OPNET. Estas partes son conocidas como wlan_dispatch (dónde se determina que tipo de función de acceso al medio se selecciona) y wlan_mac (que son la implementación de la funciones DCF y PCF de acceso al medio). En el caso del wlan_dispatch es necesario modi carlo para que cargue el código dónde se implementa el ataque. Las modi caciones son las que aparecen en el código que aparece en el Listado de código 6.2. En este listado de código fuente se puede ver como se obtiene el parámetro Sel sh behaviour parameter, que indica si se va a usar el comportamiento egoísta o no. En el caso de que no se haya activado el comportamiento egoísta este parámetro es igual a 0,0 (lo cual se comprueba en la línea 8), y se cargan los módulos correspondientes a este caso, es decir, wlan_mac_hcf (que implementa la capa MAC con la función de acceso al medio HCF) o wlan_mac (que implementa las capas MAC con la funciones DCF y PCF pero sin comportamiento egoísta). Esta operación se hace mediante el operador ternario de C en la línea 11, consultando un atributo que indica que la red va a usar una función de acceso al medio u otra. En caso de que se use el comportamiento egoísta, se carga el módulo wlan_mac_cheater en lugar del normal, lo cual se hace del mismo modo que en el caso anterior pero en la línea 14. Listado de código 6.2: Código egoista del módulo wlan_dispatch_cheater 1 2 3 4
// Cheater op_ima_obj_attr_get ( o p _ i d _ s e l f ( ) , "Node Cheats " , &comp_attr_objid ) ; comp_attr_row_objid = op_topo_child ( comp_attr_objid , OPC_OBJTYPE_GENERIC, 0 ) ; op_ima_obj_attr_get ( comp_attr_row_objid , " S e l f i s h b e h a v i o u r parameter " , & cheater_selfish ) ; Universidad de Granada
Eusebio J. Aguilera Aguilera
Implementación
48 5 6
p r i n t f ( " P r o c e s s name : %l f \n" , c h e a t e r _ s e l f i s h ) ; // Cheater
8 9 10 11
i f ( c h e a t e r _ s e l f i s h == 0 . 0 )
12 13 14
else
// Normal WLAN MAC p r o c e s s /* C r e a t e t h e a p p r o p r i a t e MAC p r o c e s s model . */ mac_prohandle = ( hcf_support_int == OPC_BOOLINT_ENABLED) ? op_pro_create ( " wlan_mac_hcf" , OPC_NIL) : op_pro_create ( "wlan_mac" , OPC_NIL) ; // S e l f i s h WLAN MAC p r o c e s s mac_prohandle = ( hcf_support_int == OPC_BOOLINT_ENABLED) ? op_pro_create ( " wlan_mac_hcf" , OPC_NIL) : op_pro_create ( " wlan_mac_cheater " , OPC_NIL) ;
6.2.3. Ataques de modi cación de la ventana de contención. Una vez que ha sido cargado el módulo correspondiente a la función de acceso al medio que va a usar la red, es necesario conocer de un modo más profundo el contenido de este módulo que se ha modi cado. El módulo wlan_mac contiene una serie de funciones que implementan las funcionalidades de la capa MAC inalámbrica. Así, las funciones más importantes que se han de conocer son las siguientes: wlan_mac_sv_init: Esta función realiza la inicialización de la capa MAC, tanto de los valores iniciales para determinados parámetros, como de las estadísticas que la misma recogerá durante el transcurso de la simulación. wlan_prepare_frame_to_send: Esta función es la que se encarga de crear una trama antes de ser enviada, es decir, la función que inicializa los valores de la cabecera de la trama antes de que sea insertada en la cola para que se envíe. Además es en esta función en la que los nodos actualizan su NAV, ya que, también es aquí dónde se calcula la duración en la transmisión. wlan_schedule_deference: Esta función es la encargada de realizar la plani cación para que no se produzcan colisiones entre los nodos, además de comprobar que se esperan los tiempos DIFS entre transmisiones correctas y tiempos SIFS entre transmisiones de tramas de la misma conversación. Estas funciones son principalmente dónde se tiene que realizar la implementación del ataque de comportamiento egoísta, debido a las características del mismo. Sin embargo existen otras funciones importantes, aunque no se van a modi car en este trabajo, ya que, no se necesita. Después de cargar los parámetros que han sido especi cados por la interfaz, hay que asegurarse de que todos estos parámetros están dentro de los valores posibles para los mismos, es decir, que no existan valores fuera del rango permitido. Esta tarea se realiza en el Listado de código 6.3, desde la línea 1 a la 33 comparando el valor del atributo obtenido con los valores límite posibles. Además si está activo el depurado por consola, se muestra Universidad de Granada
Eusebio J. Aguilera Aguilera
6.2 Desarrollo de la solución.
49
un mensaje indicando que se ha producido un error y que el atributo toma un valor distinto al indicado. Por otra parte, si está activado el depurado por consola, se muestran mensajes en los que aparecen los valores de los atributos antes de iniciar la simulación. Esto se realiza desde la línea 37 a la 49. Por último se crea un generador de números aleatorios para realizar algunas operaciones en funciones posteriores. Esto se realiza en la línea 52 mediante la función llamada Osys_Random_Stream_Handle_Create. Listado de código 6.3: Código de inicialización del módulo 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17
i f ( cheater_CW_min < 1 ) {
19 20 21 22 23 24 25 26 27
i f ( cheater_DIFS_max > 1 ) {
28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45
}
cheater_CW_min = 1 ; i f ( cheater_log_debugging ) p r i n t f ( " Using minimum v a l u e f o r c o n t e n t i o n window min : %d\n" , cheater_CW_min ) ;
i f ( cheater_CW_max > 1 0 2 3 ) {
}
cheater_CW_max = 1 0 2 3 ; i f ( cheater_log_debugging ) p r i n t f ( " Using maximum v a l u e f o r c o n t e n t i o n window max : %d\n" , cheater_CW_max ) ;
i f ( cheater_DIFS_min < 0 ) {
}
}
cheater_DIFS_min = 0 ; i f ( cheater_log_debugging ) p r i n t f ( " Using minimum v a l u e f o r DIFS p e r c e n t : %l f \n" , cheater_DIFS_min ) ;
cheater_DIFS_max = 1 ; i f ( cheater_log_debugging ) p r i n t f ( " Using maximum v a l u e f o r DIFS p e r c e n t : %l f \n" , cheater_DIFS_max ) ;
i f ( cheater_selfish_behaviour < 0) {
}
cheater_selfish_behaviour = 0; i f ( cheater_log_debugging ) p r i n t f ( " Using minimum v a l u e f o r s e l f i s h b e h a v i o u r : %l f \n" , cheater_selfish_behaviour ) ;
i f ( cheater_selfish_behaviour > 1) {
} /* */
cheater_selfish_behaviour = 1; i f ( cheater_log_debugging ) p r i n t f ( " Using maximum v a l u e f o r s e l f i s h b e h a v i o u r : %l f \n" , cheater_selfish_behaviour ) ;
I f l o g debugging i t ' s e n a b l e d p r i n t c h e a t e r p a r a m e t e r s v a l u e s
i f ( cheater_log_debugging ) { i f ( c h e a t e r _ s e l f i s h _ b e h a v i o u r == 0 . 0 ) {
p r i n t f ( "CW min e q u a l t o t h e s t a n d a r d ' s v a l u e \n" ) ; p r i n t f ( "CW max e q u a l t o t h e s t a n d a r d ' s v a l u e \n" ) ; } else { p r i n t f ( "CW min %d\n" , cheater_CW_min ) ; p r i n t f ( "CW max %d\n" , cheater_CW_max ) ; } p r i n t f ( " Cheater v a l u e time f i e l d m o d i f i c a t o r : %l f \n" ,
Universidad de Granada
Eusebio J. Aguilera Aguilera
Implementación
50
46 47 48 49 51 52
}
cheater_time_field_modificator ) ; p r i n t f ( " Cheater DIFS p e r c e n t : %l f , %l f \n" , cheater_DIFS_min , cheater_DIFS_max ) ; p r i n t f ( " Cheater s e l f i s h b e h a v i o u r %l f \n" , c h e a t e r _ s e l f i s h _ b e h a v i o u r ) ; p r i n t f ( " Cheater l o g debugging %d\n" , cheater_log_debugging ) ;
/* Generate a random number g e n e r a t o r */ selfish_random_handle = Osys_Random_Stream_Handle_Create ( ( int ) op_sim_time ( ) , 0 ) ;
Una de las técnicas que emplea este ataque es la modi cación de la ventana de contención a valores menores que los nodos normales. Para realizar la implementación de esta técnica, se modi ca la función de inicialización del módulo wlan_mac_sv_init. En esta función tenemos varios trozos de código como el que aparece en el Listado de código 6.4. Este código realiza las inicializaciones de valores que son dependientes del tipo de capa física que exista por debajo de la capa MAC. Así la modi cación realizada es la que aparece desde la línea 13 a la 13. En esas líneas se comprueba si el comportamiento egoísta está activado o no. En caso a rmativo asigna los valores del tamaño mínimo de ventana en cw_min. Se hace también lo propio con el tamaño máximo de ventana cw_max en las líneas 20 a 23. Todo esto se repite para los distintos tipos de capa física posibles en una red inalámbrica: Frecuency Hopping, Direct Secuence e Infrarrojos. Listado de código 6.4: Codigo para establecer los valores de la ventana de contención 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30
case WlanC_Frequency_Hopping :
{ /* S l o t d u r a t i o n i n terms o f s e c o n d s . */ s l o t _ t i m e = 50E− 06; /* S h o r t i n t e r f r a m e gap i n terms o f s e c o n d s . */ s i f s _ t i m e = 28E− 06; /* PLCP overheads , which i n c l u d e t h e preamble and header , i n */ /* terms o f s e c o n d s . */ p l c p _ o v e r h e a d _ c o n t r o l = WLANC_PLCP_OVERHEAD_FHSS; plcp_overhead_data = WLANC_PLCP_OVERHEAD_FHSS; /* Minimum c o n t e n t i o n window s i z e f o r s e l e c t i n g b a c k o f f s l o t s . */ i f ( c h e a t e r _ s e l f i s h _ b e h a v i o u r == 0 . 0 ) cw_min = 1 5 ;
else
cw_min = cheater_CW_min ; { c d g _ c o m p r o b a r _ e g o i s t a _ i n i c i a l i z a c i o n _ v e n t a n a _ f i n } * ) /* Maximum c o n t e n t i o n window s i z e f o r s e l e c t i n g b a c k o f f s l o t s . */ i f ( c h e a t e r _ s e l f i s h _ b e h a v i o u r == 0 . 0 ) cw_max = 1 0 2 3 ;
else
}
cw_max = cheater_CW_max ; /* S e t t h e PHY s t a n d a r d a s 11b f o r t h e t e c h n o l o g i e s s p e c i f i e d */ /* i n 8 0 2 . 1 1 and 8 0 2 . 1 1 b . */ phy_type = WlanC_11b_PHY ; break ;
Universidad de Granada
Eusebio J. Aguilera Aguilera
6.2 Desarrollo de la solución.
51
6.2.4. Ataque de sobrestimación de tiempos en tramas de datos y RTS. Otra técnica perteneciente al ataque es sobrestimar la duración de las tramas de datos y RTS. Para llevar a cabo esta técnica, es necesario moverse hasta la función wlan_prepare_frame_to_send que es la encargada de crear y preparar las tramas antes de ser enviadas, y por lo tanto, también calcula la duración de las mismas. En esta función se separan los tipos de tramas que hay que generar dependiendo además de que función de acceso al medio es la que está activa, DCF o PCF. Se puede ver el trozo de código que realiza estas comprobaciones en el Listado de código 6.5. Se ve como se comprueba que no está activa la función de acceso al medio PCF y que la trama a enviar sea de datos o ACK. Listado de código 6.5: Código para comprobar el tipo de tramas 1 2 3 4 5
/* I t t h i s i s a CP p e r i o d and t h e frame t o be t r a n s m i t t e d i s a data /ACK. */ i f ( ( wlan_flags −>p c f _ a c t i v e == OPC_FALSE) && ( ( frame_type == WlanC_Data ) | | ( frame_type == WlanC_Data_Ack) ) )
En este caso hay que modi car la duración de la trama, utilizando un parámetro que provee el usuario, y que indica el multiplicador a aplicar a la duración de la trama. Esto se implementa en el Listado de código 6.6. Este código obtiene un valor aleatorio llamado sel sh_value en la línea 7, que es usado para calcular si en esta ocasión se va a ejecutar o no el comportamiento egoísta. Si el valor aleatorio es menor que el parámetro de comportamiento egoísta cheater_sel sh_behaviour, entonces se multiplica el valor de la duración de la trama por el parámetro cheater_time_ eld_modi cator. Todo esto se produce desde la línea 12 a 19. Además si está activa la depuración por consola, se muestran los mensajes para indicar que se ha modi cado la duración de una trama, lo cual se produce desde las líneas 13 a 17. Listado de código 6.6: Código de implementación de sobrestimación en el campo de duración de las tramas 2
d u r a t i o n = 2 * d u r a t i o n + s i f s _ t i m e + TXTIME_DATA ( t x _ d a t a p a c k e t _ s i z e ) ;
4 5 6 7
/* * Cheater code b e g i n s */ s e l f i s h _ v a l u e = Osys_Random_Stream_Double_Generate ( selfish_random_handle ) ;
9 10
c o r r e c t D u r a t i o n = d u r a t i o n ; // This v a l u e w i l l be used // f o r u p d a t i n g t h e c h e a t e r ' s NAV v e c t o r
12 13 14 15
i f ( s e l f i s h _ v a l u e b a c k o f f _ f l a g = OPC_TRUE; // Destroy t h e random stream g e n e r a t o r Osys_Random_Stream_Handle_Destroy ( rand_handle ) ;
i f ( cheater_log_debugging )
p r i n t f ( " Normal DIFS time %l f m o d i f i e d DIFS time %l f \n" , d i f s _ t i m e , d i f s _ t i m e * temp_time ) ; } else { d e f e r e n c e _ e v h = o p _ i n t r p t _ s c h e d u l e _ s e l f ( ( nav_duration + ( d i f s _ t i m e ) ) , WlanC_Deference_Off ) ; }
6.3. Instalación de la solución. El ataque desarrollado en OPNET puede utilizarse en proyectos para este mismo simulador, ya que, ha sido desarrollado de forma modular, con lo que sólo es necesario instalar los módulos desarrollados para hacer uso de ellos. Esta sección trata de la forma de instalación de los módulos desarrollados. Para realizar la instalación de estos módulos es posible actuar de dos formas distintas, que buscan el mismo resultado: que el simulador pueda ver los módulos nuevos. Universidad de Granada
Eusebio J. Aguilera Aguilera
Implementación
54
Figura 6.4: Añadir una ubicación de modelos (paso 1).
Así es posible indicarle al simulador que existe una ubicación desde la que puede cargar módulos externos a los que dispone. Esto es posible desde el menú File del proyecto que se está desarrollando. Como puede verse en la Figura 6.4, al seleccionar la opción Add model directory de este mismo menú, el simulador muestra un diálogo como el de la Figura 6.5, para seleccionar la ubicación de los módulos desarrollados. Con este diálogo se debe seleccionar la ubicación de los cheros que implementan los módulos nuevos: wlan_dispatch_cheater, wlan_mac_cheater, wlan_wkstn_adv_cheater. Este último módulo es la implementación de un nodo de red seleccionable para modelar una red inalámbrica en la que se realizan ataques. Otra forma de realizar la instalación es copiando estos módulos al directorio en el que se encuentran los módulos inalámbricos del simulador OPNET, es decir, si es una instalación sobre Windows se encuentran en la ruta C:\Archivos de Programa\OPNET x.x\models\std\wireless_lan\1 , siendo ésta la ruta por defecto de instalación. Sólo con copiar esos cheros en la localización de los módulos inalámbricos, el simulador puede detectar su presencia y se esta posición de poder usarlos en un proyecto.
1
La x.x representa la versión de OPNET, por ejemplo 14.5.
Universidad de Granada
Eusebio J. Aguilera Aguilera
6.3 Instalación de la solución.
55
Figura 6.5: Añadir una ubicación de modelos (paso 2).
Universidad de Granada
Eusebio J. Aguilera Aguilera
56
Universidad de Granada
Implementación
Eusebio J. Aguilera Aguilera
Cap´ıtulo
7
Evaluación del ataque ara la evaluación de los efectos del ataque en el simulador, es necesario que se le apliquen pruebas que puedan determinar los efectos del mismo. El presente capítulo versa sobre todas las pruebas que se han realizado y los resultados obtenidos con las mismas.
P
7.1. Descripción de las pruebas realizadas. Para realizar las simulaciones se ha supuesto una red simple que se compone de tres nodos: dos emisores de trá co PING y otro receptor. Uno de los nodos emisores es un nodo que implementa el ataque tal y como se describe en el capítulo 6. A este nodo se le denominará como nodo egoísta a lo largo de este capítulo. El otro es un nodo normal que contiene la implementación estándar de la capa WLAN MAC. Las características de la red son las que aparecen en la Tabla 7.1. En la Figura 7.1 podemos ver un esquema representativo de la red de la simulación. Algunos de los parámetros de con guración que aparecen en la tabla han sido seleccionados especí camente puesto que tienen un n concreto, mientras que otros sólo aparecen a título informativo. Uno de los parámetros seleccionado es la capacidad de la interfaz, es decir, cuánta información es capaz de transmitir (o recibir) la interfaz por segundo, habiendo sido seleccionada una capacidad de 1 Mbps. El umbral RTS indica a los nodos cuándo tendrán que usar la portadora virtual, es decir, las tramas RTS/CTS para establecer la conexión con el nodo destino de la transmisión. Puesto que una parte muy importante del ataque es la modi cación del tiempo que se establece en las tramas RTS, se utiliza un valor de 1 para que siempre se use. Esto indica a los nodos que en caso de que el paquete a enviar sea de más de 1 byte, entonces se tendrá que usar el sondeo de portadora virtual (RTS+CTS). Sobre el umbral de fragmentación cabe decir que en este caso no se usará debido a que se quiere que las transmisiones sean lo más limpias posibles, es decir, que un paquete sea enviado y recibido de una sola vez (sin fragmentos que se puedan perder y degradar los resultados). Estos dos nodos envían información a un tercero llamado nodo destino, que es un nodo normal. Este trá co de información se implementa mediante unas peticiones PING desde 57
Evaluación del ataque
58 Petición PING Respuesta PING Nodo destino
Nodo normal
Petición PING Respuesta PING
Nodo egoísta
Figura 7.1: Esquema de la red de la simulación. los nodos que compiten hacia el nodo destino. La razón de usar un trá co generado por peticiones y respuestas PING es que es simétrico, es decir, un número N de peticiones PING correctamente enviadas y recepcionadas, genera un número N de respuestas PING. Además mediante el trá co PING podemos ver como afecta el ataque egoísta a una capa superior a la MAC, es decir, a la capa de transporte IP. En lo referente a las características IP/PING hay que decir que se han diseñado para que la red se sature, con el objetivo de que se pudieran apreciar las diferencias entre el nodo egoísta y el nodo normal en la información que podía enviar cada uno. Así se ha con gurado el trá co PING para que se realicen 100 peticiones PING cada segundo, siendo cada una de 1024 bytes concretamente. Las respuestas PING son del mismo tamaño; por lo tanto, si se supone un mismo número de envíos que de respuestas, se obtiene un trá co de 200 paquetes PING (petición más respuesta) de 1024 bytes cada uno. En esta red por tanto se ha con gurado una carga de red máxima de 400 paquetes PING por segundo, ya que hay peticiones PING desde el nodo normal al nodo destino, y desde el nodo egoísta al nodo destino (y el mismo número de respuestas del nodo destino a los nodos orígenes de la transmisión). El hecho de que el nodo destino sea común a los dos nodos orígenes de las transmisiones, es debido a que, de esta forma, existe un recurso compartido por el que los nodos deben competir, y por lo tanto se puede apreciar mejor la e cacia del ataque. Además de lo anterior cabe decir que las peticiones PING comienzan al principio de la simulación y sus características no varían durante la misma. Asimismo las peticiones están con guradas para que se realicen reintentos ilimitados si una petición PING no llegara correctamente. Sobre el nodo egoísta se de nen los parámetros que con guran y determinan el ataque Universidad de Granada
Eusebio J. Aguilera Aguilera
7.1 Descripción de las pruebas realizadas. Características WLAN
Características del trá co generado por los nodos de la red
Nodo egoísta
59
Capa física Capacidad de la interfaz Umbral RTS Umbral de fragmentación Tamaño de la cola
Direct Sequence 1 Mbps 1 (Siempre se usa) 0 (No se usa) 256000 bits
Versión IP Peticiones/segundo Tamaño paquete (bytes) Repetición Reintentos de transmisión Comienzo (segundos) Tiempo entre repeticiones
IPv4 100 1024 Ilimitada Ilimitados 1 0
Porcentaje DIFS Modi cador tiempo RTS/Datos Ventana de contención
[80 %, 90 %] 125 % [2, 16]
Cuadro 7.1: Características de la red que se va a realizar en la red. Así estos parámetros son lo que se listan a continuación:
Ventana de contención: Este parámetro representa el tamaño de ventana de contención mínimo y máximo respectivamente. El valor seleccionado es de [2, 16]. Este valor para un nodo normal depende de la capa física que exista por debajo: para FH es de [15, 1023], para DS es [31, 1023] y para Infrarrojos es de [63, 1023]. Porcentaje DIFS: Este parámetro controla cuándo el nodo egoísta inicia una trans-
misión después de que la última realizada haya sido correcta y sin con ictos de acceso al medio. Este valor representa un porcentaje a aplicar del tiempo DIFS para esperar antes de que se inicie un nuevo intento de transmisión. Sobre el porcentaje de tiempo DIFS que el nodo egoísta va a esperar antes de iniciar una transmisión, se ha seleccionado un porcentaje que no sea demasiado bajo, para que no se realicen una violación tan evidente del protocolo, ni demasiado alto, para que se tenga mayor seguridad de obtener el medio. Por estos motivos un porcentaje aleatorio entre el 80 % y el 90 % se considera adecuado. El motivo de usar estos valores es comprobar si el nodo egoísta tiene con una pequeña ventaja sobre el nodo normal para que el ataque sea efectivo. El hecho de seleccionar un porcentaje aleatorio se ha tenido en cuenta para que el ataque intente ser lo menos previsible posible.
Modi cador de tramas RTS y de datos: Este parámetro determina qué mul-
tiplicador se usa para el campo del tiempo de las tramas RTS y de datos, es decir,
Universidad de Granada
Eusebio J. Aguilera Aguilera
Evaluación del ataque
60
cómo se incrementa el valor del campo tiempo usado para reservar el canal durante la duración estimada del mensaje de datos. Así, si se establece un valor para el parámetro de 1,25 se está sobrestimando en un 25 % el tiempo necesario para realizar una conversación y se dispone del canal durante ese tiempo, ya que, los nodos vecinos actualizan su NAV con dicho tiempo incrementado arti cialmente por el nodo egoísta. El valor seleccionado para las pruebas ha sido de 1,25, por lo tanto se usará una sobrestimación del 25 %.
Comportamiento egoísta (0 % de las veces (desactivado), y 100 % de las veces): Se ha evaluado el comportamiento del nodo egoísta en dos situaciones di-
ferentes, una en la que el comportamiento egoísta estaba desactivado y otra en la que el comportamiento egoísta se usaba siempre. Este parámetro permite además realizar un comportamiento egoísta más liviano, ya que se podría con gurar para que se usara un 25 % de las veces. Esto serviría para que el comportamiento egoísta fuera más difícilmente detectable, puesto que no es tan activo.
Estos valores se han escogido debido a que se pretendían seleccionar los parámetros más realistas posibles. En lo referente a la ventana de contención es necesario seleccionar una que sea menor independientemente de la tecnología que se emplee para la implementación de la capa física que está bajo la capa MAC inalámbrica, siendo estos valores menores que los de nidos para FH, DS e infrarrojos.
7.1.1. Indicadores de evaluación del ataque. Antes de iniciar la presentación de los resultados obtenidos, es necesario realizar una descripción de las estadísticas que han sido usadas para obtener los resultados que a continuación serán presentados. Las estadísticas usadas se reparten en dos grandes grupos que identi can a qué capa del modelo hacen referencia: las estadísticas de la capa MAC y las estadísticas de la capa IP. 1. Estadísticas de la capa MAC. Tamaño de cola en la capa MAC: Esta estadística representa el tamaño (número de tramas) que tiene en cada momento la cola de tramas en espera de la capa MAC. Normalmente estas colas sólo contendrán las tramas de datos que provienen de capas superiores, aunque las tramas de control serán incluidas cuando sean insertadas en la cola para transmitirlas. Retraso en el acceso al medio: Para cada trama se calcula el retraso en el acceso al medio, como el tiempo que transcurre entre que esa trama es insertada en cola para transmisión y el tiempo en que la trama es enviada a la capa física para enviar. En esta medida in uye el tiempo que se tarda en realizar el intercambio de tramas RTS/CTS, en caso de que sea necesario para enviar la trama de datos. Este retraso incluirá periodos de contención en el caso de que el envío de la trama haya ocasionado colisiones. Universidad de Granada
Eusebio J. Aguilera Aguilera
7.2 Resultados obtenidos.
61
Datos enviados en la capa MAC: Esta estadística representa el tamaño (en bps) de la información enviada por la capa MAC, lo que incluye las cabeceras de las tramas. La estadística incluye como tramas de datos todas las que tienen esa consideración por el estándar IEEE 802.11. Datos recibidos en la capa MAC: La estadística indica el tamaño (en bps) de todos los datos que la capa MAC recibe correctamente de la capa física. Esta estadística toma todas las tramas de datos que de ne el estándar independientemente de la dirección de destino que tengan asignada. Trá co de control enviado por la capa MAC: Representa los bps de tramas de control (RTS, CTS y ACK) que envía la capa MAC. Trá co de control recibido por la capa MAC: Indica el tamaño en bps de las tramas de control (RTS, CTS y ACK) que la capa MAC recibe. 2. Estadísticas de la capa IP. Datos enviados por la capa IP: Representa el número de datagramas por segundo que envía el nodo por todas las interfaces IP que dispone. Datos recibidos por la capa IP: Indica cuántos datagramas por segundo recibe el nodo a través de todas las interfaces IP que posee. Tiempo de respuesta PING: Retraso en segundos que se produce entre el envío de una petición PING a la capa MAC hasta que se recibe la respuesta a esa petición. Peticiones PING enviadas: Número de peticiones PING que han sido enviadas por el nodo, es decir, número de paquetes ICMP Echo enviadas a un determinado destino. Respuestas PING recibidas: Indica el número de respuestas PING que se han recibido correctamente, es decir, el número de respuestas a paquetes ICMP Echo que se han recibido de forma correcta.
7.2. Resultados obtenidos. Con las pruebas realizadas dados los parámetros que han sido presentados anteriormente, se pretenden obtener resultados en los que el nodo egoísta aumenta sensiblemente su capacidad de enviar información con respecto a un nodo normal. Además, dado que se usa trá co PING para realizar la prueba, es de esperar que el nodo egoísta obtenga un mayor número respuestas PING que el nodo normal. Para que se entienda mejor como afecta el ataque a una red normal, primero es necesario que se vea el comportamiento de la misma sin un nodo egoísta. Una vez que se disponga de los resultados de una red sin nodos egoístas se podrá comparar con una red que dispone de un nodo egoísta. En las guras que acompañan la explicación los resultados de esta primera simulación, se puede apreciar que uno de los nodos se llama nodo egoísta, sin embargo Universidad de Granada
Eusebio J. Aguilera Aguilera
Evaluación del ataque
62 600000
Nodo normal Nodo egoista Nodo destino 500000
bps
400000
300000
200000
100000
0 0
10
20
30 Tiempo (s)
40
50
60
Figura 7.2: Datos enviados por la capa WLAN MAC sin nodos egoístas ese nodo no tiene activado el comportamiento egoísta, por lo que a efectos prácticos, se comporta como un nodo normal. La primera medida que se utiliza son los datos que envían desde la capa MAC cada uno de los nodos. Esta medida aparece en la Figura 7.2, en la que se puede ver como los tres nodos se reparten la tasa de transferencia disponible (1 Mbps). Sin embargo, toda la tasa de transferencia no la ocupan los nodos con el envío de datos, parte de la misma se emplea en el trá co de control que se produce entre ellos. Como información de control se consideran las tramas RTS, CTS, RxBusy, ACK y NAK (además de otras que no se usan en esta red por ser de tipo Ad-Hoc). Así en Figura 7.3 se puede ver la información de control que se transmiten los nodos de la red. Entre la información que envían los tres nodos (unos 900 Kbps) y las tramas de control que se envían (unos 100 Kbps) se obtiene la tasa de transferencia que permite el enlace inalámbrico. Se puede ver mejor el reparto de la capacidad del enlace entre los nodos de la red y los tipos de trá co (trá co de datos y de control) en la Figura 7.4. Otra medida de la calidad de las comunicaciones que se están produciendo en una red es el número de tramas que hay en la cola de envío de un nodo. Así en el caso de que la cola de un nodo se incremente hasta el máximo de forma rápida indica que la red se ha saturado y el ritmo de generación de información es superior al de envío de tramas. Para una red normal las colas de los nodos se comportan como se indica en la Figura 7.5. Se aprecia como los nodos normal y egoísta llegan al tope de tamaño que les permiten sus respectivas colas de envío, lo que indica que generan trá co a un ritmo mayor del que pueden enviar. Por otra parte el nodo destino se queda al borde del tope de su cola, lo Universidad de Granada
Eusebio J. Aguilera Aguilera
7.2 Resultados obtenidos.
63
80000 Nodo normal Nodo destino Nodo egoista 70000
60000
bps
50000
40000
30000
20000
10000
0 0
10
20
30 Tiempo (s)
40
50
60
Figura 7.3: Tramas de control en una red sin nodos egoístas
Figura 7.4: Reparto de la capacidad del enlace (Comportamiento egoísta desactivado)
Universidad de Granada
Eusebio J. Aguilera Aguilera
Evaluación del ataque
64 35
Nodo normal Nodo destino Nodo egoista 30
25
Tramas
20
15
10
5
0 0
10
20
30 Tiempo (s)
40
50
60
Figura 7.5: Colas de los nodos de la red sin nodos egoístas cual indica que llega un punto en el que hay un equilibrio entre información generada y transmitida. Una buena medida de la calidad de las comunicaciones es el Retraso en el acceso al medio que indicará si un nodo de la red está enviando menos información que los otros por alguna razón externa a él. En la Figura 7.6 se puede ver el Retraso en el acceso al medio de una red normal. Se ve como los tres nodos que componen dicha red tienen un retraso similar, por lo que se puede llegar a la conclusión de que ninguno de los nodos se está encontrando con ningún impedimento externo para enviar información. Posibles problemas externos que podrían hacer que aumentara el retraso podrían ser la perdida de conectividad, que un nodo viole las especi caciones y no permite enviar a algún otro, etcétera. Tras las medidas de la capa MAC mostradas, hay que pasar a comprobar como se comporta la red en la capa IP. Se pueden de nir dos ujos de información en la red de nida: un ujo de subida (entendiéndose como la información que envían los nodos normal y egoísta al nodo destino), y el ujo de bajada (la información que envía el nodo destino como respuesta a los nodos normal y egoísta). En la Figura 7.7 se puede ver el ujo de subida para la red sin nodos egoístas. Se puede ver como los nodos consiguen enviar el mismo número de paquetes por segundos, aunque el nodo destino no puede recibir todos esa información debido a que la tasa de transferencia no lo permite. El ujo de bajada de la red queda re ejado en la Figura 7.8, en la que se ve como el nodo destino envía el mismo número de respuestas PING que peticiones PING recibe. Una medida análoga al Retraso en el acceso al medio en la capa MAC, es el Tiempo Universidad de Granada
Eusebio J. Aguilera Aguilera
7.2 Resultados obtenidos.
65
1.6 Nodo normal Nodo egoista Nodo destino 1.4
1.2
Tiempo (s)
1
0.8
0.6
0.4
0.2
0 0
10
20
30 Tiempo (s)
40
50
60
Figura 7.6: Retraso en el acceso al medio de la red sin nodos egoístas
Nodo normal (Datos enviados) Nodo egoista (Datos enviados) Nodo destino (Datos recibidos)
140
120
paquetes/s
100
80
60
40
20 0
10
20
30 Tiempo (s)
40
50
60
Figura 7.7: Flujo de subida para la red sin nodos egoístas
Universidad de Granada
Eusebio J. Aguilera Aguilera
Evaluación del ataque
66 140
Nodo normal (Datos recibidos) Nodo egoista (Datos recibidos) Nodo destino (Datos enviados) 120
paquetes/s
100
80
60
40
20
0 0
10
20
30 Tiempo (s)
40
50
60
Figura 7.8: Flujo de bajada para la red sin nodos egoístas de respuesta de una petición PING en la capa IP. Así un tiempo de respuesta mayor para las peticiones PING indica que el nodo esta encontrándose con problemas para enviar y/o recibir la información. En la Figura 7.9 se ve el tiempo de respuesta que tienen los nodos de la red. En la gura se puede apreciar qué los nodos obtienen unos tiempos de respuesta similares. Por último para comprobar que los nodos normal y egoísta tienen un comportamiento similar se puede utilizar las medidas de Peticiones PING enviadas y Respuestas PING recibidas. En la Figura 7.10 se ven las peticiones que tienen cada uno de los nodos. Se puede observar que los nodos realizan las mismas peticiones por segundo. Además, en la Figura 7.11 se visualiza las respuestas que reciben cada uno de los nodos, pudiéndose comprobar que son similares y que no existe diferencias signi cativas. Una vez que se conoce cómo se comporta la red cuándo no existen nodos egoístas en la misma, se puede pasar a comprobar de qué manera afecta que el nodo egoísta active su comportamiento egoísta. En las guras que acompañan la explicación aparece el nodo egoísta que ahora sí tiene activado el comportamiento egoísta. Inicialmente se usa la medida de datos enviados por la capa MAC, lo cual se puede apreciar en la Figura 7.12. Como se puede ver en la gura, se produce un aumento muy signi cativo con respecto a la red que no tiene el nodo egoísta activado. Sin embargo ese aumento sacri ca la recepción de trá co, pues como se aprecia casi todo el trá co (una media de más de 850 Kbps.) los usa el nodo egoísta para el envío de información. Sin embargo si la interfaz que poseen los nodos es de 1 Mbps, ¾por qué razón no se alcanza 1 Mbps en la grá ca? Para poder responder a esa cuestión es necesario conocer Universidad de Granada
Eusebio J. Aguilera Aguilera
7.2 Resultados obtenidos.
67
2.5 Nodo normal Nodo egoista
2
Tiempo (s)
1.5
1
0.5
0 0
10
20
30 Tiempo (s)
40
50
60
Figura 7.9: Tiempo de respuesta de petición PING en red sin nodos egoístas
Nodo normal Nodo egoista
140
120
paquetes/s
100
80
60
40
20
0 0
10
20
30 Tiempo (s)
40
50
60
Figura 7.10: Peticiones PING en red sin nodos egoístas
Universidad de Granada
Eusebio J. Aguilera Aguilera
Evaluación del ataque
68
35 Nodo normal Nodo egoista 30
paquetes/s
25
20
15
10
5
0 0
10
20
30 Tiempo (s)
40
50
60
Figura 7.11: Respuestas PING en la red sin nodos egoístas
1.2e+06 Nodo normal Nodo egoista Nodo destino 1e+06
bps
800000
600000
400000
200000
0 0
10
20
30 Tiempo (s)
40
50
60
Figura 7.12: Datos enviados por la capa WLAN MAC con nodo egoísta activado
Universidad de Granada
Eusebio J. Aguilera Aguilera
7.2 Resultados obtenidos.
69
70000 Nodo normal Nodo destino Nodo egoista 60000
50000
bps
40000
30000
20000
10000
0 0
10
20
30 Tiempo (s)
40
50
60
Figura 7.13: Información de control enviada por la capa MAC cuánta información de control se envía. Así en la Figura 7.13 se puede apreciar que el trá co de control que envía el nodo egoísta es de unos 35 Kbps (siendo tramas RTS para pedir el acceso al canal). Además hay que tener en cuenta el trá co de control enviado por el nodo destino que asciende a unos 65 Kbps (correspondientes a tramas CTS y ACK/NAK). Así si sumamos obtendremos que el trá co de control de la red es en total de 100 Kbps. Se puede ver con mayor claridad el reparto de la capacidad del enlace entre los distintos nodos y los distintos tipos de trá co (trá co de datos y de control) en la Figura 7.14. Se puede realizar una comparación entre la situación normal que se ha visto anteriormente (sin nodo egoísta activado) y la actual (con nodo egoísta activado). Como se ha visto en la Figura 7.2, los tres nodos tienen una tasa de envío similar (de unos 300 Kbps). Así, se aprecia un incremento en la tasa de transferencia del nodo egoísta de 300 Kbps a 850 Kbps (con el comportamiento egoísta activado). Este aumento es debido, a una disminución muy importante del tiempo de acceso al medio que tiene el nodo egoísta sobre los demás nodos que componen la red. Esto se aprecia perfectamente en la Figura 7.15. En esta grá ca se puede ver cómo el retraso en el acceso al medio es muy alto en los nodos normal y destino, y prácticamente cero en el nodo egoísta, aunque no nulo. El hecho de que el retraso al acceso al medio no sea nulo en el nodo egoísta es debido a que como se aprecia en la Figura 7.16, la red está saturada de información y en todos los nodos se produce descartes de tramas por saturación de las colas, aunque en mucha menor medida en el nodo egoísta. Además hay que tener en cuenta que para el cálculo del retraso del acceso al medio se tiene en cuenta las tramas de control. Estas tramas tienen prioridad sobre las de información, incluso con el ataque egoísta activado, Universidad de Granada
Eusebio J. Aguilera Aguilera
70
Evaluación del ataque
Figura 7.14: Reparto de la capacidad del enlace en la red (Comportamiento egoísta activado) pues como es conocido las tramas de control se envían en un tiempo SIFS mientras que las tramas de datos se envían en un tiempo DIFS que es mayor incluso con el ataque activado. También se aprecia que el retraso en el acceso al medio crece de forma lineal hasta que llega a un límite en el que sigue un patrón no lineal. Esto es debido a que llega un momento en que las colas de envío están llenas y el tiempo de espera ya no puede crecer más, ya que no se permite que se inserten nuevas tramas en la cola. Por último, para comparar el retraso en el acceso al medio con los valores que nos muestra la red cuando no se activa el ataque se puede observar la Figura 7.6. En ella se puede ver que en esta red el retraso en el acceso al medio es en torno a 1 segundo de media. Si se compara con la Figura 7.15, se puede observar un aumento muy sensible para los nodos normal y destino, y un descenso muy acusado en el nodo que implementa el comportamiento egoísta. Se puede realizar un análisis de como se comporta la red teniendo en cuenta los ujos de trá cos de los nodos, es decir, el ujo de subida y el de bajada, entendiéndose como ujo de bajada los datos que envía el nodo destino y que reciben los nodos normal y egoísta, y ujo de subida al trá co que se produce a la inversa. Se puede apreciar estos ujos en la Figuras 7.7, 7.17, 7.8, 7.18 respectivamente. Primero hay que jarse en el trá co de subida, es decir, el trá co que generan los nodos al nodo destino y que éste recibe. En la Figura 7.7 se puede apreciar que ese trá co es más o menos homogéneo, enviando los nodos origen 100 paquetes/s y recibiendo el nodo destino una media de unos 70 paquetes/s, lo cual indica que aunque salen 200 paquetes/s Universidad de Granada
Eusebio J. Aguilera Aguilera
7.2 Resultados obtenidos.
71
20 Nodo normal Nodo egoista Nodo destino
Tiempo (s)
15
10
5
0 0
10
20
30 Tiempo (s)
40
50
60
Figura 7.15: Retraso en el acceso al medio en la capa WLAN MAC
1.2e+06 Nodo normal Nodo egoista Nodo destino 1e+06
bps
800000
600000
400000
200000
0 0
10
20
30 Tiempo (s)
40
50
60
Figura 7.16: Trá co que se elimina en las colas de la capa MAC.
Universidad de Granada
Eusebio J. Aguilera Aguilera
Evaluación del ataque
72
Datos enviados por la capa IP (Nodo normal) Nodo normal (Datos enviados) Nodo egoista (Datos enviados) Nodo destino (Datos recibidos)
140
120
paquetes/s
100
80
60
40
20 0
10
20
30 Tiempo (s)
40
50
60
Figura 7.17: Flujo de subida con el nodo egoísta activado
Datos enviados por la capa IP (Nodo normal) 120 Nodo normal (Datos recibidos) Nodo egoista (Datos recibidos) Nodo destino (Datos enviados) 100
paquetes/s
80
60
40
20
0 0
10
20
30 Tiempo (s)
40
50
60
Figura 7.18: Flujo de bajada egoísta.
Universidad de Granada
Eusebio J. Aguilera Aguilera
7.3 Análisis de las estrategias del ataque.
73
de los nodos origen, éstos no se pueden mandar ya que el enlace no lo permite (recordar que se dispone de 1 Mbps), sino que quedan en las colas de la capa inferior (capa WLAN MAC). En la gura 7.17 se puede ver el trá co de subida generado cuando se activa el comportamiento egoísta. Con el comportamiento egoísta el trá co recibido por el nodo destino se incrementa hasta sobrepasar holgadamente los 90 paquetes/s. Por lo visto en la Figura 7.12, se debe suponer que el trá co enviado procede casi en su totalidad del nodo egoísta. Así puesto que se incrementa el trá co recibido por el nodo destino (peticiones ping) se debe suponer también que aumentarán las respuestas a estás peticiones (respuestas ping). Sin embargo esto supone que no quede apenas capacidad en el enlace para realizar la recepción. Esto se puede apreciar en la Figura 7.18. La grá ca muestra que el nodo egoísta se queda con la poca tasa de transferencia que queda y recibe más respuestas ping que el nodo normal. Sin embargo que pasaría si se dispusiera de más tasa de transferencia en las interfaces, ¾se seguiría obteniendo menos de 200 paquetes/s en el nodo destino? Para responder a esta pregunta se pueden observar las Figuras 7.19, 7.20, 7.21, 7.22. En las guras que representan el ujo de información sin el nodo egoísta activado (Figuras 7.19 y 7.20) se puede ver que el número de paquetes correctamente recepcionados por el nodo destino es sensiblemente mayor, pero no se consiguen alcanzar los 200 paquetes/s sino que se obtienen unos 120. En cuanto al ujo de datos con el nodo egoísta activado (Figuras 7.21 y 7.22) se produce un aumento con respecto a la simulación con el nodo desactivado pero tampoco se alcanzan los 200 paquetes/s recepcionados por el nodo destino, sino que se alcanzan unos 140 paquetes/s. Se puede observar también que aumentan mucho las respuestas PING recibidas por el nodo egoísta con respecto a la misma simulación pero con interfaces de 1 Mbps. En conclusión se puede decir que cuando se activa en nodo egoísta en la red actual y con la con guración vista en la Tabla 7.1 se produce una carga de la red en el trá co de subida que proviene en su mayor parte (casi la totalidad) del nodo egoísta. Debido a que se están realizando una simulación usando el trá co PING se debe esperar que ese aumento en peticiones PING produzca una aumento igual en las respuestas PING. Sin embargo como se aprecia en la Figura 7.23, aunque el nodo egoísta recibe prácticamente todas las respuestas, éstas no alcanzan a igualar en número las peticiones. Esto es debido a que como se ha comentado anteriormente la mayor parte de la capacidad de la interfaz inalámbrica se emplea en el trá co de subida al nodo destino, es decir, peticiones PING.
7.3. Análisis de las estrategias del ataque. Puesto que el ataque se compone de tres estrategias distintas, es decir, enviar después de un tiempo SIFS y antes de DIFS, sobrestimar el tiempo en las tramas RTS y de datos, y usar una ventana de contención pequeña y ja; convendría analizarlas por separado para poder determinar así, que parte del ataque es la más efectiva. Esto es lo que se va a comentar en la presente sección. Universidad de Granada
Eusebio J. Aguilera Aguilera
Evaluación del ataque
74
180 Nodo normal (Datos recibidos) Nodo egoista (Datos recibidos) Nodo destino (Datos enviados)
160
140
paquetes/s
120
100
80
60
40
20
0 0
10
20
30 Tiempo (s)
40
50
60
Figura 7.19: Flujo de subida normal con interfaces de 2 Mbps.
180 Nodo normal (Datos recibidos) Nodo egoista (Datos recibidos) Nodo destino (Datos enviados)
160
140
paquetes/s
120
100
80
60
40
20
0 0
10
20
30 Tiempo (s)
40
50
60
Figura 7.20: Flujo de bajada normal con interfaces de 2 Mbps.
Universidad de Granada
Eusebio J. Aguilera Aguilera
7.3 Análisis de las estrategias del ataque.
75
180 Nodo normal (Datos enviados) Nodo egoista (Datos enviados) Nodo destino (Datos recibidos)
160
140
paquetes/s
120
100
80
60
40
20 0
10
20
30 Tiempo (s)
40
50
60
Figura 7.21: Flujo de subida con nodo egoísta activado e interfaces de 2 Mbps.
180 Nodo normal (Datos recibidos) Nodo egoista (Datos recibidos) Nodo destino (Datos enviados)
160
140
paquetes/s
120
100
80
60
40
20
0 0
10
20
30 Tiempo (s)
40
50
60
Figura 7.22: Flujo de bajada con el nodo egoísta activado e interfaces de 2 Mbps.
Universidad de Granada
Eusebio J. Aguilera Aguilera
Evaluación del ataque
76 5
Nodo normal Nodo egoista
4
paquetes/s
3
2
1
0 0
10
20
30 Tiempo (s)
40
50
60
Figura 7.23: Respuestas ping (ping replies).
7.3.1. Modi cación en la ventana de contención. Se han realizado simulaciones activando tan sólo las modi caciones sobre la ventana de contención. Así, después de realizar estas simulaciones, sólo con esta parte del ataque activada, se obtuvieron los resultados que a continuación se explican. Así se puede observar que el nodo egoísta envía más información con diferencia que los demás. Esto puede verse en la Figura 7.24, dónde está representada una comparativa entre los datos enviados por la capa MAC en cada nodo. Como se puede ver es el nodo egoísta él que realiza la mayor parte de los envíos no permitiendo que los demás nodos puedan realizar la transmisión de sus tramas. Esto se puede explicar teniendo en cuenta el razonamiento del punto 1.3.1.1, dónde entre otros se explica que pasa cuándo se usa una ventana de contención ja y pequeña. Para apoyar la explicación se puede ver lo que ocurre con el retraso en el acceso al medio. Esto se puede apreciar en la Figura 7.25, en la que se ve cómo el nodo egoísta es el que obtiene un retraso casi nulo, mientras que los otros nodos incrementan su retraso en el acceso al medio de una forma lineal hasta que alcanzan un máximo, y entonces empiezan a uctuar. Para determinar cuánta información recibe el nodo egoísta se puede tener en cuenta el número de respuestas PING recibidas. Esta estadística se puede ver en la Figura 7.26. En ella se aprecia que, estando activado el comportamiento egoísta de la ventana de contención, el nodo egoísta recibe respuestas PING mientras que el otro nodo no. Además para poder a rmar que cuando se activa este comportamiento egoísta el nodo egoísta es capaz de hacer llegar más información al nodo destino, es posible observar la Universidad de Granada
Eusebio J. Aguilera Aguilera
7.3 Análisis de las estrategias del ataque.
77
1.2e+06 Nodo normal Nodo egoista Nodo destino 1e+06
bps
800000
600000
400000
200000
0 0
10
20
30 Tiempo (s)
40
50
60
Figura 7.24: Datos enviados por la capa MAC (nodo egoísta activado)
60 Nodo normal Nodo egoista Nodo destino 50
Tiempo (s)
40
30
20
10
0 0
10
20
30 Tiempo (s)
40
50
60
Figura 7.25: Retraso en el acceso al medio con la ventana de contención modi cada
Universidad de Granada
Eusebio J. Aguilera Aguilera
Evaluación del ataque
78 3
Nodo normal Nodo egoista 2.5
paquetes/s
2
1.5
1
0.5
0 0
10
20
30 Tiempo (s)
40
50
60
Figura 7.26: Respuestas PING recibidas con el comportamiento egoísta activado Figura 7.27. En ella se puede apreciar que se produce un aumento de información recibida por la capa IP en el nodo destino. Este aumento de información recibida es atribuible al uso de la técnica de comportamiento egoísta que es la única diferencia entre una simulación y la otra. En base a estas explicaciones se puede a rmar que la modi cación de la ventana de contención es e caz dentro del ataque de comportamiento egoísta.
7.3.2. Envío de datos después de tiempo SIFS y antes de DIFS. Han sido realizadas simulaciones activando sólo la parte del ataque que intenta enviar datos después del tiempo SIFS y antes de DIFS. Utilizando esta parte del ataque se obtuvieron los resultados que a continuación se explican. Lo primero que se debe comprobar es que, efectivamente, el nodo egoísta consigue con esta técnica enviar más información que los otros nodos pertenecientes a la misma red. Esto se puede apreciar en la Figura 7.28, dónde aparece lo que cada nodo trans ere en media (se ha usado la media para que se vea más claro la diferencia, puesto que en este caso es más escasa que en otros). Como se puede observar el nodo egoísta consigue enviar más información que los otros nodos, pero en menor medida que en otros casos, ya que, en este caso el nodo egoísta consigue enviar una media de unos 350 Kbps mientras que en el caso del uso de la ventana de contención pequeña y ja se llega a alcanzar unos 850 Kbps. También se puede comprobar el retraso de acceso al medio que tienen los nodos. Esta estadística se puede comprobar en la Figura 7.29, en la que se presenta la media del retraso al acceso al medio (se usa la media para que sea apreciable la diferencia que hay entre los Universidad de Granada
Eusebio J. Aguilera Aguilera
7.3 Análisis de las estrategias del ataque.
79
120 Comportamiento egoista desactivado Comportamiento egoista activado 100
paquetes/s
80
60
40
20
0 0
10
20
30 Tiempo (s)
40
50
60
Figura 7.27: Datos recibidos en la capa IP por el nodo destino
500000 Nodo normal Nodo egoista Nodo destino 400000
bps
300000
200000
100000
0 0
10
20
30 Tiempo (s)
40
50
60
Figura 7.28: Datos enviados por la capa MAC Universidad de Granada
Eusebio J. Aguilera Aguilera
Evaluación del ataque
80 1.2
Nodo normal Nodo egoista Nodo destino 1
Tiempo (s)
0.8
0.6
0.4
0.2
0 0
10
20
30 Tiempo (s)
40
50
60
Figura 7.29: Retraso en el acceso al medio en la capa MAC distintos nodos). Como se puede apreciar el tiempo en media es menor en el nodo egoísta con respecto a los otros nodos. También en este caso el nodo destino incrementa el número de peticiones que recibe con el comportamiento egoísta activado, como se puede ver en la Figura 7.30 (se usa la media para ver la diferencia más claramente). En esta gura se puede comprobar como el nodo destino recibe más datos cuando se activa el comportamiento egoísta. Por último se debe comprobar que ese aumento de información recibida por parte del nodo destino se debe a la actuación del nodo egoísta. Esto se puede comprobar viendo la Figura 7.31, en la que aparece un aumento de las respuestas de PING que recibe el nodo egoísta sobre el nodo normal. Para comparar esta situación con la situación habitual de respuestas recibidas en un entorno normal (sin comportamiento egoísta) se puede ver la Figura 7.32, que muestra la misma grá ca pero sin comportamiento egoísta activado. Si se comparan los resultados, se puede apreciar un aumento muy signi cativo en las respuestas PING que recibe el nodo egoísta con respecto al nodo normal. En base a lo anteriormente expuesto se puede concluir que esta parte del ataque es efectiva, aunque en comparación con la anterior tiene una e cacia mucho menor. Se puede a rmar que la e cacia del ataque es menor puesto que, como se comentó en la sección 1.3.1, el objetivo principal de estos ataques es conseguir una tasa de envío mayor que los otros nodos que componen la red. Así si se comparan las Figuras 7.24 y 7.28, se puede comprobar fácilmente que la media de envío en el ataque que usa sólo la ventana de contención pequeña y ja, es muy superior al presente ataque. Universidad de Granada
Eusebio J. Aguilera Aguilera
7.3 Análisis de las estrategias del ataque.
81
120 Comportamiento egoista desactivado Comportamiento egoista activado 100
paquetes/s
80
60
40
20
0 0
10
20
30 Tiempo (s)
40
50
60
Figura 7.30: Peticiones recibidas por la capa IP en el nodo destino
22 Nodo normal Nodo egoista 20 18 16
paquetes/s
14 12 10 8 6 4 2 0 0
10
20
30 Tiempo (s)
40
50
60
Figura 7.31: Respuestas PING recibidas
Universidad de Granada
Eusebio J. Aguilera Aguilera
Evaluación del ataque
82 35
Nodo normal Nodo egoista 30
paquetes/s
25
20
15
10
5
0 0
10
20
30 Tiempo (s)
40
50
60
Figura 7.32: Comparativa de respuestas PING recibidas (comportamiento egoísta desactivado
7.3.3. Modi cación de tiempos en las tramas RTS y de datos. La última simulación hecha por separado sirve para comprobar si la modi cación de la duración de las tramas RTS y de datos es efectiva y además determinar en qué medida lo es. Los resultados obtenidos son los que a continuación van a ser detallados. En primer lugar se comprueba si el nodo egoísta consigue, de nuevo, enviar más información que los otros nodos que componen la red. En este sentido se comprueba que este hecho es cierto, si se observa lo que ocurre en la Figura 7.33, en la que se muestra la media de envíos de los tres nodos. En ella se ve claramente como el nodo egoísta consigue enviar signi cativamente más información que los otros. En cuanto al retraso del acceso al medio, se puede decir que en este caso no hay una diferencia signi cativa que pueda ser achacado al ataque. Esta a rmación se basa en los datos que re eja la Figura 7.34, en la que no aparece ninguna diferencia signi cativa en la media de retraso en el acceso al medio. No obstante, sí se aprecian diferencias en las peticiones que recibe el nodo destino. Este aumento se puede ver en la Figura 7.35, en la que aparece la media de peticiones que recibe el nodo destino en un entorno con el comportamiento egoísta desactivado y activado. Este aumento es consecuencia del aumento de peticiones que recibe por parte del nodo egoísta. A esta conclusión se puede llegar si se observa la Figura 7.36, en la que aparece la media de respuestas que reciben el nodo egoísta y el nodo normal (en un entorno de comportamiento egoísta activado). En base a lo que se ha expuesto se puede a rmar que, aunque el nodo egoísta consigue Universidad de Granada
Eusebio J. Aguilera Aguilera
7.3 Análisis de las estrategias del ataque.
83
800000 Nodo normal Nodo egoista Nodo destino 700000
600000
bps
500000
400000
300000
200000
100000
0 0
10
20
30 Tiempo (s)
40
50
60
Figura 7.33: Media de envíos de la capa MAC
1 Nodo normal Nodo egoista Nodo destino 0.8
Tiempo (s)
0.6
0.4
0.2
0 0
10
20
30 Tiempo (s)
40
50
60
Figura 7.34: Media en el retraso en el acceso al medio
Universidad de Granada
Eusebio J. Aguilera Aguilera
Evaluación del ataque
84
120 Comportamiento egoista desactivado Comportamiento egoista activado 100
paquetes/s
80
60
40
20
0 0
10
20
30 Tiempo (s)
40
50
60
Figura 7.35: Media de peticiones recibidas por el nodo destino
35 Nodo normal Nodo egoista 30
paquetes/s
25
20
15
10
5
0 0
10
20
30 Tiempo (s)
40
50
60
Figura 7.36: Media de respuestas PING recibidas
Universidad de Granada
Eusebio J. Aguilera Aguilera
7.3 Análisis de las estrategias del ataque.
85
enviar más información que los otros, no es tan efectivo como la modi cación de la ventana de contención.
Universidad de Granada
Eusebio J. Aguilera Aguilera
86
Universidad de Granada
Evaluación del ataque
Eusebio J. Aguilera Aguilera
Cap´ıtulo
8
Conclusiones inalizado el desarrollo del proyecto, sólo queda enumerar las aportaciones que se han conseguido mediante la consecución del mismo. Además de las aportaciones se listan los posibles trabajos de futuro que se pueden desarrollar en base al desarrollo del presente trabajo. Las aportaciones que ha hecho este proyecto se pueden dividir entre aquéllas que son de carácter personal y las globales. Entre las aportaciones personales que ha supuesto el proyecto se encuentran las que a continuación se lista:
F
Mayor conocimiento del despliegue de redes mediante el uso de simuladores y más concretamente haciendo uso de OPNET. Mejor entendimiento sobre el funcionamiento de las redes inalámbricas en general y el acceso al medio en la mismas en particular. Se ha adquirido un conocimiento más profundo sobre la función de acceso al medio DFC y todas las técnicas que usa para realizar su implementación. Un conocimiento más profundo sobre el funcionamiento de los ataques de comportamiento egoísta. Mejorar las destrezas de gestión de proyectos informáticos en general. Además de las aportaciones personales que ha supuesto la realización del presente trabajo, cabe señalar que también hay contribuciones de carácter no personal. Las aportaciones no personales que ha supuesto el desarrollo del proyecto son las que aparecen en la siguiente lista: Demostración empírica de que los ataques funcionan de forma correcta y hacen que otros nodos que forman una red no puedan mandar información apena, quedando prácticamente anulados. 87
88
Conclusiones
Tras la de nición de las contribuciones que ha tenido este trabajo cabe apuntar el trabajo futuro que el presente proyecto deja abierto. Así, después de demostrar empíricamente el funcionamiento de los ataques egoístas, es un paso instantáneo el hecho de realizar la demostración en un entorno real. Es decir, la implementación de los ataques dentro de los controladores de alguna interfaz inalámbrica que lo permita, para poder realizar pruebas similares a las que se han hecho en las simulaciones.
Universidad de Granada
Eusebio J. Aguilera Aguilera
Bibliografía
[Teodoro-2003] Teodoro García, Pedro (et. al). Transmisión de datos y redes de computadores. Primera edición. España: Pearson Educación. 2003. 405 pp. ISBN: 84-205-3919-8. [Harsal-1998]
Harsal, Fred. Comunicación de datos, redes de computadores y sistemas abiertos. Escalona García, Roberto (et. al). Cuarta edición. México: Pearson Educación, 1998. 955 pp. ISBN: 968-444-331-5.
[Buttyan-2008] Buttyán, Levente; Hubaux, Jean-Pierre. Security and Cooperation in Wireless Networks. Primera edición. Estados Unidos: Cambridge University. 2008. 485 pp. ISBN: 978-0-521-87471-0 hardback. [Cagalj-2005]
Cagalj, Mario (et. al.). On Sel sh Behavior in CSMA/CA Networks. INFOCOM 2005. 24th Annual Joint Conference of the IEEE Computer and Communications Societies. Proceedings IEEE. 13-17 de Marzo de 2005, 2005, p. 2513- 2524 vol. 4.
89
90
Universidad de Granada
BIBLIOGRAFÍA
Eusebio J. Aguilera Aguilera
´ Apendice
A
Desarrollo de módulos para OPNET. n este capítulo se pretende explicar cuales son los principales pasos para poder realizar
E el desarrollo de un módulo nuevo en el simulador OPNET. Este capítulo se considera
como un anejo del proyecto n de carrera, aunque se puede leer por separado, debido a que no guarda una relación directa con el mismo.
A.1. Elementos del entorno. Para poder desarrollar elementos del entorno de simulación OPNET, es necesario conocer primero las partes que lo forman; y para que sirven cada una de ellas. Así, es posible separar el simulador OPNET en las siguientes partes funcionales: El editor de proyectos: Representa el área de trabajo principal del simulador y es el editor que ayuda a desplegar las redes en el nivel más alto de abstracción, es decir, a nivel de redes, subredes y componentes de las mismas. El editor de nodos: Este editor permite de nir el comportamiento de un nodo de una red. El comportamiento de un nodo se de ne mediante distintos módulos, cada uno de los cuales representa una parte del mismo: creación de datos, almacenamientos, etcétera. El editor del modelo de proceso: Este editor permite crear procesos de modelo, que controlan la funcionalidad que existe dentro de cada nodo. Los procesos de modelo se representan mediante máquinas de estados nitos que se componen de estados y transiciones. Las operaciones se llevan a cabo en cada estado mediante bloques de código C. El editor de pruebas: Permite de nir las estadísticas que se quieres recoger durante la simulación. Esto además se puede hacer directamente en el editor de proyecto pulsando sobre los nodos de la red. 91
Desarrollo de módulos para OPNET.
92
Figura A.1: Ventana principal del editor de proyectos El editor de secuencia de simulación: Este editor habilita al usuario para de nir una secuencia de simulación, entendiéndose esto como una serie de simulaciones en las que se modi ca algunos de los parámetros que reciben. El editor de paquetes: Posibilita de nir nuevos formatos de paquete para tecnologías que estén en desarrollo. Aunque existen más editores dentro de OPNET, éstos son los principales que permiten de nir la mayoría de los proyectos que un usuario pueda necesitar.
A.2. El editor de proyectos. Como se ha comentado en la sección anterior, este editor permite desplegar una red, con todos los elementos que la conforman a un nivel de abstracción alto. Dentro de este editor encontraremos una ventana principal que es dónde se localizan la red, subredes y elementos de más alto nivel de abstracción de un despliegue de redes. En la Figura A.1 se puede apreciar la ventana principal de un proyecto que contiene una red que ha sido desplegada. Para poder de nir una red como la que se ha mostrado es necesario usar la paleta de objetos que nos provee con todo tipo de elementos de una red: estaciones de trabajo, enrutadores, concentradores, etcétera. La paleta de objetos se puede encontrar en la barra de herramientas del editor de proyectos, en el botón . Si se pulsa sobre ese botón se accede a la paleta de objetos que tiene un aspecto similar al que aparece en la Figura A.2. Esta paleta de objetos se puede presentar mediante un árbol (como aparece en la Figura A.2) o mediante iconos que representan cada uno de los elementos de una red. Universidad de Granada
Eusebio J. Aguilera Aguilera
A.3 Editor de nodos.
93
Figura A.2: Paleta de objetos Cada vez que se deposita sobre el proyecto un elemento de la red que se está de niendo aparece en la ventana del proyecto. Se pueden de nir las características de ese elemento pulsando el botón derecho del ratón sobre dicho objeto. En el menú contextual aparecen dos opciones posibles para modi car las características del objeto: Edit Attributes y Edit Attributes (Advanced), como se ve en la Figura A.3. La primera de las opciones muestra una versión reducida de las características que se pueden modi car sobre un objeto, mientras que la segunda opción ofrece más posibilidades que modi car. El diálogo de modi cación se muestra en la Figura A.4. Una vez posicionados los elementos físicos de la red (estaciones, servidores, enrutadores, etcétera) es necesario que se una mediante cables, siempre que no se haya de nido una red inalámbrica. Para unir dos nodos de una red cableada mediante cables, primero hay que seleccionar el tipo de enlace en la paleta de objetos. Una vez seleccionado el tipo de enlace basta con pulsar sobre uno de los nodos a unir y pulsar una segunda vez sobre el destino del enlace. Esta operación se puede repetir hasta que se unan todos los nodos de la red. Después de unirlos sólo queda cancelar la de nición de enlaces, que se consigue mediante la pulsación del botón derecho del ratón.
A.3. Editor de nodos. Este editor da la oportunidad de de nir modelos de nodo que describen el ujo interno de datos de un objeto de la red. Estos elementos están compuestos por módulos que separan las funcionalidades de un nodo. Esta arquitectura puede verse en el ejemplo que aparece en la Figura A.5, que muestra un nodo (un servidor ethernet) con todos los módulos que lo forman y que tienen una función concreta (implementan una capa del modelo, o Universidad de Granada
Eusebio J. Aguilera Aguilera
94
Desarrollo de módulos para OPNET.
Figura A.3: Menú contextual implementan una función dentro de una capa). Además de los módulos existen los ujos de paquetes por dónde circula la información entre las capas. Por último también están los cables estadísticos que permiten recoger todas las estadísticas que el simulador brinda al usuario.
A.4. Editor del modelo del proceso. Este editor permite al usuario del simulador de nir una capa dentro de un nodo que se está creando o modi cando. El comportamiento de las capa se de ne mediante las conocidas como máquinas de estados nitos. Para ello es necesario que se de nan una serie de estados por los que va a pasar la capa durante el desarrollo de una simulación. Así por ejemplo, existen una serie de estados que siempre se dan en cualquier capa de red de un nodo: Inicio, Inactivo, Llegada_datos. La de nición de estos estados establece, por tanto, las distintas etapas por las que pasa la capa de un módulo que está siendo de nida. Estos estados se componen de varias partes: las instrucciones de entrada y las de salida. Las instrucciones de entrada son aquellas que se ejecutan cuando se produce una transición de un estado a otro, más concretamente cuando se entra en el nuevo estado. Las instrucciones de salida, como es previsible, son las que se ejecutan cuando se sale del estado al que pertenecen. Existen además varios tipos de estados: los estados forzados (de color verde, que apareUniversidad de Granada
Eusebio J. Aguilera Aguilera
A.4 Editor del modelo del proceso.
95
Figura A.4: Edición de atributos del elemento de red
Figura A.5: Arquitectura de un nodo
Universidad de Granada
Eusebio J. Aguilera Aguilera
Desarrollo de módulos para OPNET.
96
Figura A.6: Transiciones y estados cen en una tonalidad más clara en la gura) y los no forzados (de color rojo, que aparecen en un tono más oscuro en la gura), como se puede ver en la Figura A.6. La diferencia entre ellos es que un estado no forzado devuelve el control de la ejecución al kernel de simulación, después de ejecutar las instrucciones de entrada; mientras que un estado forzado no. En una máquina de estados nitos, además de los estados, es necesario que sean de nidas las transiciones. Estas transiciones, son las que de nen cuando se produce el paso de un estado inicial a otro nal. Existen dos tipos de transiciones: transiciones condicionales e incondicionales. La diferencia entre ambas es que las transiciones condicionales exigen que la condición que de nen se cumpla para pasar del estado inicial al nal, mientras que las incondicionales producen el cambio de estado sin que se tenga que cumplir ninguna condición. Una transición puede albergar también las instrucciones de transición, que es el código que se ejecuta cuando se produce una transición. Como se ha visto, un módulo se de ne mediante una máquina de estados nitos, pero esto sólo de ne una pequeña parte del comportamiento, ya que, la mayor parte del mismo se de ne mediante el código que existe en cada estado y transición. Este código se de ne mediante el lenguaje de programación C, con lo cual es necesario conocer este lenguaje de programación antes de iniciar el desarrollo de un módulo nuevo para OPNET. Además de conocer este lenguaje es necesario saber que funciones existen y para que sirve cada una. El número de funciones a las que se puede acceder es muy alto, pero a continuación se va a proceder a una clasi cación y explicación de las más importantes. 1. Funciones de acceso al modelo: Estas funciones permiten acceder a un modelo de los que forman parte de un nodo de una red.
a ) Ets_Model_Create(): Esta función permite crear modelos de un tipo espe-
ci cado mediante parámetro. La función devuelve si el modelo ha sido creado correctamente o no.
Universidad de Granada
Eusebio J. Aguilera Aguilera
A.4 Editor del modelo del proceso.
97
b ) Ets_Model_Destroy(): Elimina un modelo que ya no sea útil para la simulación.
2. Funciones de atributos: Este grupo de funciones son las que permiten acceder a los atributos de los objetos. Así cada uno de los elementos de una red es un objeto que posee a su vez atributos.
a ) Ets_Obj_Attr_Get(): Esta función permite obtener de un objeto uno de sus
atributos. Los parámetros que recibe son el objeto y el nombre del atributo. La función devuelve el valor del atributo que se quiere obtener. b ) Ets_Obj_Attr_Set(): Establece el valor de un determinado atributo pasado como argumento. Los parámetros que recibe son el objeto, el nombre del atributo y el valor del mismo. Devolverá si se ha producido un error o no. c ) Ets_Obj_Attr_Exists(): Función que permite saber si un atributo existe antes de intentar acceder al mismo. Recibe como parámetro el objeto y el nombre del atributo que se intenta acceder. Devuelve si el atributo existe o no. d ) Ets_Obj_Extended_Attr_Add(): La función añade un nuevo atributo a un objeto de una red. Los parámetros son el objeto y el nombre del nuevo atributo. 3. Funciones sobre objetos: Son el grupo de funciones que manipulan los objetos que forman parte de las redes.
a ) Ets_Obj_Create(): Función que permite crear un objeto nuevo. El parámetro
principal es el tipo de objeto que quiere crear. Se devuelve el manejador para el nuevo objeto que se ha creado. b ) Ets_Obj_Destroy(): Elimina un objeto que existe y deja libre la memoria que ocupa. El parámetro que recibe es el propio objeto a eliminar. c ) Ets_Obj_Install(): Instala un objeto de reciente creación como hijo de otro objeto existente. Como parámetros recibe el objeto padre y el objeto hijo y devuelve si la operación se ha hecho de forma correcta o no. d ) Ets_Obj_Uninstall(): Elimina un objeto del modelo que no tenga atributos compuestos. Como parámetro recibe el objeto que se quiere desinstalar. 4. Funciones sobre estadísticas: Las estadísticas que se recogen se realizan mediante una serie de funciones que se encargan de crear las estadísticas, actualizar sus valores y eliminarlas.
a ) op_stat_reg(): Esta función es la que inicializa una estadística registrándola
como local o global en un módulo. Los parámetros que recibe es el nombre de la estadística, número de dimensiones de la estadísticas (si es escalar recibe una constante especial llamada OPC_STAT_INDEX_NONE) y el tipo de estadística (que puede ser OPC_STAT_GLOBAL o OPC_STAT_LOCAL). Como resultado devuelve el manejador de la estadística que se usa para actualizar el valor de la misma.
Universidad de Granada
Eusebio J. Aguilera Aguilera
Desarrollo de módulos para OPNET.
98
b ) op_stat_write(): Escribe el valor que se especi ca en la estadística, además
de almacenar el tiempo en el que se ha realizado la escritura. Como parámetros recibe la estadística a actualizar y el valor a añadir (el tiempo lo calcula con respecto a la última actualización). No devuelve nada. c ) op_stat_write_t(): Esta función al igual que la anterior permite actualizar el valor de una estadística utilizando el tiempo que se le pasa como parámetro. Los parámetros recibidos son la estadística, el valor de la misma y el tiempo. No devuelve nada.
5. Funciones de creación de paquetes de datos: Estas funciones permiten realizar distintas operaciones sobre los paquetes, como por ejemplo, crear paquetes, ver atributos, destruirlos, etcétera.
a ) op_pk_create_fmt(): La función crea un paquete predeterminado con una
b)
c)
d) e)
estructura estándar. El parámetro que se recibe es el nombre del paquete. Devuelve el paquete creado en caso de que sea correcta la operación o un error en caso contrario. op_pk_create(): Crea un nuevo paquete no formateado con un tamaño especi cado. El parámetro que se recibe es el tamaño del paquete. Se devuelve un puntero al paquete en caso de que todo sea correcto o un valor de error en caso de que no se consiga crear el paquete o haya un fallo en el parámetro. op_pk_get(): Esta función obtiene el paquete que ha llegado por un ujo de entrada, y lo elimina del ujo. Como parámetro recibe el ujo de entrada del que va a obtener el paquete. Devuelve el paquete que ha llegado o un error en caso de que no haya un paquete en el ujo de entrada. op_pk_send(): Envía un paquete a través de un ujo de salida. Los parámetros que la función recibe son el paquete y ujo de salida por el que envía el mismo. No devuelve nada. op_pk_type(): Determina el tipo de paquete que se le pasa como parámetro. Recibe como parámetro un paquete y devuelve el tipo de paquete del cual se trata: OPC_PACKET_TYPE_FORMATTED para un paquete con formato, OPC_PACKET_TYPE_UNFORMATTED para un paquete sin formato inicial o OPC_PACKET_TYPE_VVEC para un paquete de tipo vector.
6. Funciones para generación aleatoria: Estas funciones se pueden utilizar para la generación de números aleatorios.
a ) op_prg_random_gen_create(): Crea un generador de números aleatorios mediante el uso de una semilla que recibe como parámetro. Devuelve el generador de números aleatorios. b ) op_prg_random_gen_destroy(): Elimina un generador de números aleatorios que ya no sea necesario usar. Como parámetro recibe el propio generador de números aleatorios. No devuelve nada.
Universidad de Granada
Eusebio J. Aguilera Aguilera
A.5 Simulación y obtención de resultados.
99
Enrutador
Figura A.7: Red de ejemplo.
c ) op_prg_random_integer_gen() y op_prg_random_double_gen(): Estas
funciones se utilizan para generar los números aleatorios dependiendo del tipo de número que se quiere obtener, es decir, un número de tipo entero o de tipo real. Como parámetro recibe el generador de números aleatorios y devuelve el número aleatorio generado.
Esta es sólo una pequeña muestra del gran número de funciones que se pueden utilizar para realizar el desarrollo de nuevos módulos. Estas funciones representan las que en la mayoría de los casos se utilizan para realizar el desarrollo.
A.5. Simulación y obtención de resultados. La parte más importante de un simulador, es sin duda, la calidad en la simulación y la posibilidad de recoger estadísticas que ayuden a la obtención de unos resultados claros. Se pretende aquí dar un resumen de las formas de realizar simulaciones y recoger estadísticas en el simulador. Inicialmente para realizar la recogida de estadísticas es necesario establecer cuáles son las que se necesitan obtener, antes de iniciar la simulación. Para establecer que se recoja una estadística hay que seleccionar el nodo de la red sobre el que se quiere recoger una estadística. Por ejemplo supóngase una red con varios nodos: cuatro estaciones de trabajo que están unidas mediante una enrutador (como la que se ve en la Figura A.7). En esa red se pretende conocer cuánto trá co de tipo UDP se mueve. Para ello se selecciona el enrutador con el botón derecho del ratón y se pulsa sobre la opción Choose Individual DES Statistics, como aparece en la Figura A.8. Una vez seleccionada la opción aparece un diálogo para seleccionar aquellas estadísticas que se necesiten recoger, como el que aparece en la Figura A.9. En este diálogo se puede seleccionar las estadísticas que se quieran recoger, en este caso que se plantea es la estadística Tra c received del grupo de estadísticas UDP. Una vez que se han seleccionado todos las estadísticas necesarias para la obtención de resultados, se puede pasar a la simulación. OPNET ofrece varias posibilidades a la hora de realizar la simulación: realizar un sola simulación o realizar una batería de simulaciones en la que se modi ca un parámetro de forma automática. En el primero de los casos basta Universidad de Granada
Eusebio J. Aguilera Aguilera
Desarrollo de módulos para OPNET.
100
Figura A.8: Selección de estadísticas (Paso 1).
Figura A.9: Selección de estadísticas (Paso 2).
Universidad de Granada
Eusebio J. Aguilera Aguilera
A.5 Simulación y obtención de resultados.
101
Figura A.10: Diálogo de simulación simple. con pulsar sobre el botón de la barra de herramientas, apareciendo a continuación un diálogo para solicitar algunos parámetros como la duración de la simulación, el tipo de kernel a usar en la simulación, etcétera. Después de suministrar dichos valores y pulsar sobre el botón para ejecutar la simulación, debe aparecer un diálogo de simulación como el de la Figura A.10. En este diálogo se puede ver el progreso de la simulación mientras se está llevando a cabo, además de mostrar cuando se produzca una incidencia en la misma (un error de ejecución por ejemplo). Otra posibilidad para realizar las simulaciones es mediante la de nición de parámetros que se le van a asignar distintos valores en una batería de simulaciones. Para ello, primero se ha de indicar que parámetros son los que van a usar distintos valores. Esto se consigue en el diálogo de los atributos del nodo de la red correspondiente, pulsando el botón derecho del ratón sobre el valor del atributo. Entonces aparece la opción Promote attribute to higher level, como aparece en la Figura A.11, que permite que ese atributo se pueda seleccionar en el diálogo de simulación avanzado. Una vez que se hayan seleccionado todos los atributos que se pretendían utilizar con distintos valores en la batería de simulación, se puede pasar a la simulación. Cuando se pulse el botón de simulación, se pasa a establecer los valores de los distintos atributos. Esto se realiza mediante el diálogo que aparece en la Figura A.12, dónde se puede de nir los valores que se van a usar durante la batería de simulaciones (a más valores más permutaciones y más simulaciones). Además también es posible de nir varios baterías de simulaciones con diferentes valores de duración de la misma.
Universidad de Granada
Eusebio J. Aguilera Aguilera
Desarrollo de módulos para OPNET.
102
Figura A.11: Selección de atributo que tomará varios valores
Figura A.12: Diálogo de simulación avanzada Universidad de Granada
Eusebio J. Aguilera Aguilera
