SIMULACIONES Y RESULTADOS

En este capítulo se presentan las simulaciones que se llevaron a cabo para comprobar el dese- mepeño de la arquitectura propuesta, teniendo en cuenta dos factores principales, tales como: número de mensajes perdidos y número de saltos promedio. De esta forma se hicieron tablas y graneas explicativas para establecer comparaciones entre las ventajas y desventajas del sistema propuesto y las arquitecturas de la revisión bibliográfica. Así mismo, se analiza el comportamiento de la red con el caché compartido y con el caché no compartido, y se observan parámetros como: caché de usuarios, caché de red y caché combinado (usuarios y red).

Por medio de las simulaciones se comprobó el desem-peño del sistema y se pudieron obtener conclusiones acerca de las ventajas que las arquitectura propuesta puede brindar en cuanto a la protección del DNS, puesto que DNS tiene dos tipos de servicio. Uno es los DNS autoritativos que proporcionan información completa acerca de alguna parte del espacio de nombres de dominio, y el otro es los DNS recursivos que consultan la información en el DNS autoritativo y entregan la información de respuesta al cliente. Y el servidor DNS recursivo mantiene el caché DNS actualizado para realizar el servicio de preguntas y respuestas de manera eficiente [21]. Todo esto, con el afán de mostrar que los datos fueron tomados de un servidor recursivo real con preguntas y respuestas reales que siguen una distribución de Ley de Potencias, explicada en capítulos anteriores. Además, al simular entornos con nodos comprometidos se hizo más real un ataque preciso al DNS y el sis- tema se hizo reaccionar bajo diferentes parámetros controlados. Las simulaciones demuestran cómo es afectado el desempeño del DNS bajo condiciones de ataques. De acuerdo a los resultados se observó que la arquitectura eDNS reduce el daño causado por los ataques aumentando la disponi- bilidad de los recursos DNS, además de presentarse como un esquema de emergencia y ayuda al árbol DNS jerárquico.

4.1. Metodología

Para el desarrollo de las simulaciones se implemento el Lenguaje C++ puesto que en el Grupo de Investigación DNS, que es al que pertenece este proyecto de Tesis, se parte de una simulación con anillo simple para convertirla en un esquema de doble anillo P2P. Es por esto que esta Tesis se enfoca es a partir de la formación del anillo, creando varios parámetros de desempeño para obtener mejores ventajas en cuanto a rendimiento.

Se establecen varios tipos de simulaciones:

• En primer lugar se analiza el parámetro de cantidad de peticiones perdidas. Para esta sim- ulación se establece un porcentaje determinado de nodos coalicionados, es decir, nodos que actúan como barreras para la información evitando que la petición siga su curso para ser satisfecha. Aquí se observa el comportamiento de la red completa, lo que, el anillo de cliente y el anillo de servidores actuando en conjunto.

• Posteriormente se hace una simulación que analiza el número promedio de saltos que requiere una petición para ser satisfecha. Aquí también se comienza a incrementar el porcentaje de nodos coalicionados para observar cómo se va comportando el sistema cuando la información encuentra cada vez más obstáculos para ser satisfecha.

• Luego se hacen simulaciones con respecto al caché, donde se hace funcionar el sistema cuando los nodos comparten su caché y cuando no lo comparten. Cabe aclarar que aquí no se coali- cionan los nodos, sino que simplemente se analiza el número promedio de saltos con respecto al caché compartido y con respecto al caché no compartido. Además, otra prueba que se hace con respecto al caché es el hecho de compartirlo entre los nodos del sistema pero según sea este caché perteneciente al uso personal de cada usuario, o al uso frecuente de un área de trabajo, es decir, un caché de red, o simplemente, al uso compartido de un caché conformado por los recursos personales de los usuarios y el caché de red.

• Finalmente se analizan simulaciones de uso del caché basadas en niveles de replicación, es decir, los recursos se disponen en el sistema de forma que los más frecuentemente pedidos se distribuyen en mayor cantidad de nodos a lo largo de la red, mientras que los recursos menos frecuentemente pedidos se distribuyen en menor medida en la red. Así, se tiene un comportamiento más real del sistema y se puede analizar con más precisión el uso del caché. Es con todas estas pautas que se presentan que se van a tener en cuenta tres parámetros

importantes: cantidad de peticiones perdidas, número promedio de saltos y desempeño del caché en cuanto a los otros dos parámetros.

4.2. Consideraciones Preliminares

Debido a la importancia de mostrar el desempeño de la arquitectura eDNS, fue necesario ali- mentar el sistema eDNS con peticiones reales. De esta forma las peticiones fueron capturadas de un servidor DNS de una red universitaria 1_{. Estas peticiones fueron capturadas durante cinco minutos}

de operación del servidor DNS y posteriormente el conjunto de peticiones fue computado teniendo conocimiento de los nombres de dominio requeridos y sus respectivas frecuencias, formando dos archivos con esta información. Un primer archivo con el conjunto de peticiones y sus respectivos tiempos de arribo y un segundo archivo con 13818 nombres de dominio y sus respectivas frecuencias. Así, el eDNS fue construido usando la información contenida en el segundo archivo y las peticiones del eDNS fueron tomadas del primer archivo. Se hicieron diferentes pruebas teniendo en cuenta la popularidad de los recursos, es decir, los recursos que tenían mayor frecuencia es porque son pregun- tados mayor número de veces, y los que presentan menor frecuencia son preguntados menor número de veces. Con las simulaciones de estos escenarios se pretende analizar factores de desempeño tales como: número de saltos y mensajes perdidos, con lo que se dispone construir ventajas y desventajas de la arquitectura que se propone. Además, se espera construir escenarios de caché compartido, donde los nodos comparten recursos que se usan comúnmente, para observar si la red llega a tener un mejor desempeño y si el costo se vuelve menor que el benificio que brinda el hecho de compartir el caché.

4.3. Construcción de la Arquitectura eDNS

La información DNS en el anillo de los clientes es distribuida usando listas DNS y cada nodo tiene una lista con nombres de dominio. Para el almacenamiento y la búsqueda de nombres de dominio se usa el protocolo Pastry, donde cada nodo tiene nombres de dominio con identificadores (llamados hash id o simplemente, IDs). En contraste, en el anillo de servidores, la información es almacenada usando el concepto de gTLDs y ccTLDs. Para nombres de dominio con g'TLD y ccTLD, tal como, www.google.com.co, un nodo será construido usando la combinación de gTLD,

ccTLD y el nombre de dominio; así, el nodo quedará construido como el dominio google.com.co. Por

otra parte, si el nombre de dominio sólo está conformado por un gTLD o por un ccTLD, tal como

1 _{El servidor DNS se encuentra operando en el ITESM Campus Monterrey}

www.mty.itesm.mx o www.network.ieee.org, el nombre de dominio tendrá solamente la combinación

del nombre de dominio con el gTLD o ccTLD respectivo; en este caso, el nodo quedará formado como itesm.mx e ieee.org, respectivamente. Posteriormente, los recursos que tengan dominios iguales

serán almacenados en el mismo nodo, formando un árbol DNS. Esto proporciona mayor rapidez y eficiencia en la búsqueda y la posibilidad de explotar las ventajas que brinda DNSSEC. Las peticiones fueron conducidas con los anillos operando conjuntamente, es decir, el anillo de clientes y el de servidores. La operación básica de este esquema es la siguiente: cuando una petición llega al eDNS ésta es pasada al anillo de clientes el cual contesta con una respuesta positiva o negativa según si posea o no la información que se le pide. Si el anillo de clientes responde postivamente, la petición ha quedado satisfecha. Pero, si por el contrario, la respuesta fue negativa, la petición pasa al anillo de servidores para que éste trate de satifacerla. De esta forma se evitan ciclos innecesarios en el sistema, y se reduce el problema de los cuellos de botella y la sobre carga en la red.

La simulación consta de ciertos parámetros importantes a tener en cuenta:

• N: Este parámetro está relacionado con la teoría de Hashing. Es el espacio de generación de IDs aleatorios.

• nodes: Es la cantidad de nodos que van a formar cada uno de los anillos, los cuales son recursos tomados de un archivo y que se van a organizar de forma que sus IDs tengan relación de cercanía.

• b: Es la base del protocolo Pastry, que para el caso de este trabajo siempre fue 2.

• regions: Es el número de regiones en las que se podría organizar el anillo. Para las simulaciones de este trabajo siempre se tomó una región.

• c-nodescli: Es el número de nodos coalicionados que se van a presentar en el anillo de clientes. • c-nodes: Es el número de nodos coalicionados que se van a presentar en el anillo de servidores. • seed: Es la semilla, que está relacionada con la generación de números aleatorios [20]. Para

efectos de esta simulación siempre se utilizó el valor de 1.

• messages: Es el número de peticiones que se van a hacer. Esta cantidad también es tomada de un

• percentage: Es el porcentaje de nodos que van a formar el anillo, el resto sobrante del por- centaje se alojará en los nodos ya existentes como caché". Ejemplificando, esto quiere decir que si aquí se pone un 80 por ciento, y en nodes se escogieron 10000 nodos, entonces 8000 nodos van a formar el anillo y los 2000 restantes se van a ubicar en los nodos ya formados como caché de la red.

La simulación arroja los siguientes archivos:

• Un archivo en el que se observan los saltos en el anillo de servidor por cada petición que se hizo. Además este archivo pone el signo menos antes del número de saltos si la petición no fue satisfecha, tiene signo positivo si la petición fue satisfecha, y tiene un O si la petición fue satisfecha en el mismo nodo por donde entró a la red, es decir, no tuvo que acumular saltos. • Un archivo de servidores en el que se observan las mismas características de saltos y peticiones

perdidas que en el anillo de clientes.

• Un contador en el que se observa el tiempo de ejecución de la simulación en segundos. • Visualización del total de peticiones perdidas tanto en el anillo de clientes como en el anillo

de servidores.

• Es opcional ver cómo se van formando los anillos con sus respectivos caches, las rutas que toman las peticiones para ser satisfechas y los recursos que quedan satisfechos y los que no.

Para efecto de pruebas de robustez de la arquitectura eDNS se introdujeron al sistema nodos maliciosos en ambos anillos. Los nodos coalicionados son nodos maliciosos que desechan peticiones y hacen que la información no pase a través de ellos, es decir, son una barrera en el proceso de búsqueda y juegan un papel de puntos de falla en la arquitectura eDNS. En cuanto a este aspecto se pueden presentar varios tipos de nodos coalicionados. Se pueden encontrar nodos que bloquean la información totalmente y la destruyen, actuando como barreras. Otro tipo son los nodos que cambian la información que reciben y pasan otra información modificada a su manera. Otros nodos pueden tener páginas similares aparentemente a las que el usuario necesita, pero en realidad son páginas creadas por estos nodos maliciosos con la intención de capturar contraseñas o recibir números de tarjetas, etc. De esta forma, en todas las redes existe la posibilidad de que se introduzcan en ellas nodos maliciosos que traten de afectar la información que se transmite entre

ellos, esta suposición obliga a pensar en la necesidad de implementar protocolos o mecanismos de autenticación.

Algunos de los ataques principales a una red son:

• Modificación de datos o manipulación de datos: Se refiere a un ataque de red de datos confi-

denciales de la empresa donde se interpreta, elimina o modifica un conjunto de información. • Escucha: Este tipo de ataque de red se produce cuando un atacante monitorea o escucha el

tráfico de tránsito de la red y, a continuación, interpreta todos los datos no protegidos.

• Suplantación de identidad: Se produce cuando un atacante asume ser la fuente del Proto- colo Internet (IP) de los paquetes IP para que parezca como si el paquete se originó a partir de una dirección IP válida. El objetivo de la dirección IP de un posible ataque de suplantación es identificar a los computadores en una red. La mayoría de las redes IP utilizar la dirección IP del usuario para verificar las identidades.

• Ataques sniffer: se refiere al proceso utilizado por los atacantes para capturar y analizar el

tráfico de la red. Así, se analiza el contenido de los paquetes en una red. Las herramientas que utilizan los atacantes son los analizadores de protocolo. Los rastreadores de red se utilizan para controlar, capturar y obtener información de la red, tales como contraseñas e información valiosa de los clientes.

• Ataques de contraseña: Los ataques basados en la contraseña están destinadas a adivinar la

contraseña de un sistema hasta que la contraseña correcta se determina. Una de las principales debilidades de seguridad asociados con la contraseña de acceso basado en el control de la seguridad es que todo se basa en la identificación de usuario y contraseña que se utilizan. • Ataque de fuerza bruta: Estos ataques tratan de descifrar por un sistema de cifrado de claves

cada una de las posibles contraseñas tratando de encontrar la correcta. Este tipo de ataque de red sistematiza todos los usos posibles alfa-numéricos, caracteres especiales y combinaciones de teclas para encontrar una contraseña que sea válida para una cuenta de usuario.

En la figura 4.1 se mide el porcentaje de nodos coalicionados contra el porcentaje de peticiones o mensajes perdidos, con lo que se puede observar que a medida que los nodos coalicionados aumentan en la red, como se ve: O, 0.03, 0.3, 3, 30 y 45 por ciento de nodos coalicionados, los recursos que no se satisfacen son más. La línea de triángulos representa el desempeño en el anillo de clientes y

Fig. 4.1: Porcentaje de nodos coalicionados contra porcentaje de peticiones perdidas

la línea de círculos representa el desempeño del anillo de servidores. Este comportamiento es de esperarse debido a que mientras más nodos maliciosos haya en un sistema, será menor el desempeño en cuanto a la satisfacción de las peticiones. Sin embargo, se puede notar que en el anillo de clientes el número de peticiones perdidas aumenta más rápidamente que en el anillo de servidores, puesto que gracias a la organización del anillo de servidores el desempeño de esta pequeña red mejora, lo que se puede observar con la comparación de ambas líneas en la granea.

En la figura 4.2 se analiza el porcentaje de nodos coalicionados (los mismos porcentajes que en la figura 4.1) contra el número promedio de saltos. Este es un factor bastante importante en cuanto a la observación del desempeño de un sistema, porque mientras mayor sea el número promedio de saltos en una red, mayor va a ser su latencia, lo que puede ser consecuencia de cuellos de botella y sobrecarga en la red. De esta forma, se observa que mientras el porcentaje de nodos coalicionados en la red es O, el anillo de clientes va a tener determinado número de saltos promedio, es decir, determinada carga, pero a medida que los nodos coalicionados van aumentando, el anillo de clientes no es capaz de satisfacer las peticiones así que recurre al anillo que es el de servidores, en el que ya va aumentando la carga, hasta que tratan de buscar un equilibrio de cargas en el sistema.

52

Porcentaje de nodos coalicionados

Fig. 4.2: Porcentaje de nodos coalicionados contra número promedio de saltos

La tabla 4.1 muestra los cuadros 1, 2, 3 y 4. E cuadro 1 presenta el resultado de una prueba con los recursos de mayor frecuencia, es decir, las peticiones más populares, y donde se analiza el porcentaje de peticiones perdidas en el anillo de clientes y en el de servidores con respectos a la característica de tener su caché compartido y no tener su caché compartido. Se puede observar entonces que cuando los nodos comparten su caché, hay menor porcentaje de peticiones perdidas, puesto que hay una interacción en la red lo que la hace más enciente en cuanto a la búsqueda de soluciones. En el cuadro 2 se muestra la misma prueba que el cuadro 1, pero ahora con los recursos menos populares. Ocurre el mismo fenómeno, es decir, cuando comparten el caché se pierden menos peticiones, además se puede ver que presenta menor porcentaje de peticiones perdidas el anillo de servidores, puesto que, como se ha venido comentando, este anillo de respaldo funciona de una forma más organizada y rápida. Los cuadros 3 y 4 muestran los recuros más populares y los menos populares, respectivamente, pero ahora se analiza el número de saltos promedio en cada uno de los anillos, y como es de esperarse, cuando comparten el caché, las peticiones dan menos saltos para ser satisfechas puesto que hay más nodos en la red con la misma información. Aquí se sigue presentando que el anillo de servidores muestra una eficiencia mayor que el de clientes, lo que concuerda con la

realidad, donde los servidores deben formar una red más organizada y robusta.

Como resultados de este estudio podemos decir que, en relación con las pruebas, el anillo de clientes siempre tiene la mayor cantidad de pérdida de peticiones y la mayor cantidad promedio de saltos. Esto se debe a que el anillo de servidores sólo tiene dos niveles de dominio, máximo tres, lo que hace que la búsqueda de información sea más general. Además, el anillo de clientes trata de asemejarse a un comportamiento real en el que los clientes son caóticos y desordenados y a veces la red presenta conexiones y desconexiones repentinas.

Se hicieron 3 niveles de replicación a lo largo del anillo de clientes, de esta forma: para el nivel 1 se tiene una replicación del recurso en un 75 por ciento del anillo, para un nivel 2, se tiene una replicación del 50 por ciento, para un nivel 3, se tiene una replicación del 25 por ciento, y el resto de recursos no se replican sino que se mantienen en su nodo original. En la tabla 4.2 se muestran 3 recursos representativos de cada nivel de replicación, con sus respectivas frecuencias, es decir, popularidades, y en la tercera columna se presenta el número promedio de saltos con lo que se observa que a medida que el recurso se replica más a lo largo del anillo, los saltos para satisfacer su petición disminuyen, puesto que hay más nodos que tienen esa información, mientras que los nodos que sólo se encuentran en su nodo original, presentan mayor cantidad de saltos para satisfacer una petición. Gráficamente estos resultados se muestran en la figura ??. Estos resultados se realizaron con pruebas de 13000 nodos formando el anillo de clientes y cada petición se preguntó 10000 veces