Ataque Protocolo RIP

ENGINYERIA TÈCNICA DE TELECOMUNICACIÓ

ESPECIALITAT TELEMÀTICA

PROYECTO FINAL DE CARRERA

Curso 2007-2008

ATAQUE AL PROTOCOLO RIP

Alumno: Salvador Álvarez Director: Francesc Sebè Fecha entrega: Abril 2008

2

ATAQUE AL PROTOCOLO RIP

3

ÍNDICE

PRESENTACION 5 1. INTRODUCCIÓN 6 1.1 Tabla de encaminamiento 6 1.2 Encaminamiento estático y dinámico 9 1.3 Protocolo de encaminamiento 10 1.4 Concepto de EGP E IGP 10 2. RIP 12 2.1 Introducción a RIP 12 2.2 Algoritmo del Vector de Distancia 12 2.2.1 Cambios en la topologia 17 2.2.2 Prevención de la inestabilidad: Cuenta a infinito 19 2.2.3 Horizonte dividido con actualización inversa envenenada 22 2.2.4 Trigger Update 26 2.3 Especificaciones del Protocolo RIP 27 2.4 Formato del mensaje 28 2.5 Consideraciones en el direccionamiento 30 2.6 Temporizadores 32 2.7 Proceso de entrada 33 2.7.1 Comando Request 34 2.7.2 Comando Response 35 2.8 Proceso de salida 36 2.9 Ejemplo RIP 37 2.10 RIP VERSION 2 40 2.10.1 Formato mensaje RIP version 2 40 2.10.2 Consideraciones y compatibilidades 43 2.11 Limitaciones del protocolo 44 3. DISEÑO DE ATAQUE 45 3.1 Introducción 45 3.2 Conocimiento de la red 45 3.3 Mensajeria falsa 46 3.4 Expansión de la mensajeria falsa 48 3.5 Provocar cancelación de rutas 50 3.6 Persistencia 51 4. DESARROLLO 52 4.1 Introduccion 52 4.2 Análisis funcional 52 4.3 Análisis técnico 55 4.4 Pruebas 58

4

4.4.1 Pruebas ST 59 4.4.2 Pruebas IT 59 4.4.3 Pruebas PR 61 5. CONCLUSIONES 64 6. RECURSOS UTILIZADOS 65 7. MANUAL 66 7.1 Introducción 66 7.2 Requisitos 66 7.3 Características 66 7.4 Descripción de la aplicación 67 7.5 Mensajes de error 69

5

PRESENTACIÓN

Una ruta, en telemática, es el camino que los datos deben seguir desde un origen hasta llegar a su destino. En una arquitectura o topología de red, es de gran importancia que todas las entidades que forman parte de la misma, ordenadores o routers, se puedan comunicar entre ellos. Una topología de red, puede ser tan simple como dos ordenadores conectados punto a punto, o una gran red conmutada. Por esta razón es necesario que exista un mecanismo que permita la comunicación, sea cual sea la topología de red. A este mecanismo se le denomina encaminamiento, y determina las rutas que deben seguir los datos.

En las redes que utilizan el protocolo TCP/IP, las máquinas encargadas de

encaminar la información se denominan routers. Los routers son máquinas que tienen diversos interfaces de red. Cuando un router recibe una trama de datos por una interfaz observa su cabecera IP para ver la dirección IP donde va dirigida la trama. Según el destino donde va dirigida la trama, ésta va a ser reenviada por un interfaz o por otro. La decisión sobre por qué lugar se debe reenviar una trama se toma a partir de la información contenida en las tablas de encaminamiento de un router. Esta información se puede configurar de forma manual (proceso muy laborioso) por parte del administrador o se puede obtener de forma automática mediante la utilización de protocolos de encaminamiento. Un protocolo de encaminamiento es utilitzado por los routers de una red para intercambiar la información necesaria para que cada router pueda configurar sus tablas de encaminamiento.

Uno de los protocolos de encaminamiento más antiguos y conocidos, es el

Protocolo RIP, de las siglas en inglés, Routing Informacition Protocol. Pero, ¿Es realmente RIP un buen protocolo de encaminamiento? Este proyecto, pretende demostrar las vulnerabilidades y problemas de seguridad que presenta la utilización del protocolo RIP en redes conmutadas.

Primeramente, se analiza el protocolo, como funciona, que particularidades

tiene. A continuación se hace un estudio de los posibles problemas de seguridad del protocolo. Y por último, se muestra la implementación de una aplicación para ejecutar un ataque de denegación de servicio en una red conmutada que utilice el protocolo RIP como protocolo de encaminamiento. Este ataque tiene como finalidad interferir en el correcto funcionamiento de la red en cuestión. El ataque consiste en introducir en la red un equipo que inserte mensajes falsos. Estos mensajes falsos, al ser recibidos y procesados por los routers causaran su desconfiguración de las tablas de encaminamiento.

Para una buena comprensión de los temas tratados en el presente

proyecto, se recomienda que el lector tenga conocimientos básicos en configuración de redes, conocimientos del protocolo TCP/IP, y conocimientos del lenguaje de programación JAVA.

6

1 INTRODUCCIÓN

1.1 TABLA DE ENCAMINAMIENTO

La función de encaminamiento de una red trata de encontrar las rutas de mínimo coste a través de la red, estando el parámetro de coste basado en el número de saltos, el retardo esperado u otras métricas.

Una red de comunicaciones puede ser muy simple. Por ejemplo, dos

ordenadores conectados mediante un cable determinan una red de comunicaciones. En una red de estas características es evidente que el flujo de datos que ira de un ordenador a otro será siempre por el cable que los une.

Fig 1.

Pero, lo habitual encontrarnos arquitecturas de red más complejas. En ese

caso, los routers deben estar configurados para que los datos enviados entre dos máquinas cualquiera lleguen a su destino. Por ejemplo, en la Fig 2. se muestra una red con 4 ordenadores.

Fig 2. Cada ordenador debe poder comunicarse con el resto de ordenadores de

la red. El ordenador A esta directamente conectado con B. Por lo tanto, utilizan el cable de red que los une para comunicarse. En el caso de que el ordenador A quiera comunicarse con el ordenador C, es necesario que el flujo de datos pase por el ordenador B. Entonces, en ordenador B debe ser el encargado de hacer llegar los datos que quiere enviar A a su destino. En este

7

caso como el destino es el ordenador C, reenviaría los datos por su interfaz 3. De manera similar se pueden determinar cada ruta necesaria para que todos los ordenadores de la red se puedan comunicar.

Se pueden presentar las rutas fácilmente en una tabla para cada

ordenador de la red. Por ejemplo, el ordenador A tendría la siguiente tabla de rutas:

La puerta de enlace es la máquina a través de la cual una máquina envía

sus datos para que lleguen a destinos con los cuales no está conectada directamente. En este caso, el ordenador A utiliza el ordenador B como puerta de enlace para comunicarse con el resto de la red. Según este esquema, es responsabilidad de B que los datos acaben llegando a su destino. La interfaz, es el medio físico que se utiliza en cada ruta. En el ejemplo, como el ordenador A solo dispone de una interfaz, enviará todos sus datos por esta. A cada ruta posible, también se le conoce con el nombre de Entrada de la tabla.

La tabla de rutas del ordenador B tendría la siguiente pinta: Como el ordenador B esta interconectado con todos los ordenadores de la

red en cuestión, no necesita puertas de enlace para comunicarse. De forma similar se puede determinar las tablas del ordenador C y del

ordenador D:

Destino Puerta enlace Interfaz B 1 C B 1 D B 1

Destino Puerta enlace Interfaz A 1 C 3 D 2

Destino Puerta enlace Interfaz B 2 D 1 D B 2

Destino Puerta enlace Interfaz C 1 B 3 A B 2

8

Se puede observar como utilizan B como puerta de enlace para comunicarse con A.

Según lo visto hasta el momento, una tabla de rutas contiene la

información que indica a una máquina como encaminar una trama de datos a partir del destino donde esta va dirigida. A esta tabla se le denomina Tabla de encaminamiento.

En una tabla de encaminamiento, se incluye el destino que se quiere

alcanzar, la puerta de enlace, si procede, y la interfaz que se utiliza para llegar al destino. Adicionalmente se incluyen otros parámetros útiles para el encaminamiento, que se verán más adelante. En las redes TCP/IP, el destino se indica mediante la dirección IP del ordenador de destino, y la puerta de enlace por la dirección IP del ordenador que hace tal función.

Fig. 3

La red representada en la Fig.3, esta constituida por tres ordenadores, y dos redes. Por una parte, tenemos la red 192.168.1.0/24, y por otra, la red 192.168.2.0/24. Se han asignado direcciones IP en las interfaces de los ordenadores respetando la singularidad en la red. La tabla de encaminamiento que obtendríamos del ordenador A seria similar a la siguiente:

Ordenador A

Destination Gateway Genmask Iface 192.168.1.0 0.0.0.0 255.255.255.0 eth0 192.168.2.0 192.168.1.2 255.255.255.0 eth0 Cuando una máquina esta directamente conectada a una red, no necesita puerta de enlace, gateway, para comunicarse con esta. En ese caso se utiliza la dirección 0.0.0.0 para indicar que no es necesario puerta de enlace. El ordenador A, como esta directamente conectado a la red 192.168.1.0 no necesita puerta de enlace. En cambio, para comunicar con la red 192.168.2.0, necesita de la puerta de enlace 192.168.1.2. Las tablas de encaminamiento de los ordenadores B y C tendrían la siguiente pinta:

9

Ordenador B Destination Gateway Genmask Iface 192.168.1.0 0.0.0.0 255.255.255.0 eth0 192.168.2.0 0.0.0.0 255.255.255.0 eth1 Como el ordenador B está directamente conectado a las dos redes no necesita de puertas de enlace. Ordenador C Destination Gateway Genmask Iface 192.168.1.0 192.168.2.1 255.255.255.0 eth0 192.168.2.0 0.0.0.0 255.255.255.0 eth0 Si el ordenador A desea enviar una trama de datos a la máquina C, consultará la tabla de encaminamiento para decidir donde tiene que dirigir los datos. En este caso enviará los datos por la única interfaz que tiene, la interfaz eth0, que conecta directamente con B. Cuando el ordenador B recibe los datos de A, ve que va dirigido al ordenador C en la cabecera IP. Entonces, consultará en las tablas de encaminamiento por que interfaz tiene que reencaminar los datos. En este caso por su interfaz eth1. Finalmente los datos llegan a su destino, el ordenador C.

1.2 ENCAMINAMIENTO ESTÁTICO Y DINÁMICO

En redes no demasiado grandes, es factible configurar las tablas de

encaminamiento de forma manual. Cuando las tablas de encaminamiento se configuran de forma manual, el encaminamiento se denomina Estático. En el encaminamiento estático la información de las tablas de encaminamiento se configuran una única vez. Esta información permanecerá inalterada a no ser que la modifiquemos manualmente.

Para redes más grandes y complejas, esto no es factible. En primer lugar,

un número mayor de ordenadores, implica un número mayor de rutas a configurar, siendo una tarea laboriosa, y en ocasiones difícil de hacer. Por otra parte, cambios en la topología, tales como incluir más ordenadores, suponen reconfigurar todos los ordenadores de la red para obtener comunicación con los ordenadores incluidos. Además, si un enlace falla, como las rutas son fijas, este método no es capaz de encontrar rutas alternativas para encaminar los datos. En definitiva, la técnica de encaminamiento estático no se adapta al estado de la red.

Por consiguiente, es necesario disponer de un mecanismo automático para

solucionar todos estos problemas. Este mecanismo debe rellenar la

10

información de las tablas de encaminamiento de los routers de forma automática. Además, en caso de cambios en la topología de la red, la información de las tablas debe actualizarse también de forma automática. De esta forma, evitamos que cambios en la topología de red, tales como fallos en enlaces o ampliaciones de red, provoquen problemas de comunicación. A este mecanismo se le denomina Encaminamiento Dinámico. El contenido de las tablas de encaminamiento cambia en la medida que lo hacen las condiciones de la red.

Para hacer posible el encaminamiento dinámico es necesario que las

estaciones intercambien información acerca del estado de la red.

1.3 PROTOCOLO DE ENCAMINAMIENTO

Un protocolo de encaminamiento define el mecanismo mediante el cual los routers de una red intercambian la información necesaria para configurar sus tablas de encaminamiento.

Es necesario que en una red, todos los routers utilicen el mismo protocolo

de encaminamiento para intercambiar información. Solo así se puede tener la certeza de que el mecanismo funcionará correctamente.

La meta de un protocolo de encaminamiento es muy simple: “Proporcionar la información necesaria para el encaminamiento”.

1.4 CONCEPTO DE EGP E IGP En una red tal como Internet, es inverosímil que se use un único protocolo

de encaminamiento. La red está organizada por diferentes Sistemas Autónomos. Se entiende por sistema autónomo un conjunto de redes y dispositivos que se encuentran administrados por una solo entidad, o al menos tiene un grado razonable de control a nivel técnico y de administración. Cada sistema autónomo tiene su propia tecnología de encaminamiento. Esta, por tanto, puede ser diferente o no para cada sistema autónomo. El protocolo de encaminamiento usado dentro de un sistema autónomo se le denomina un IGP (Interior Gateway Protocol). Este protocolo se ocupa de que el contenido de las tablas de encaminamiento de los routers del sistema autónomo sea correcto.

11

Fig. 4

Para interconectar sistemas autónomos se usa otro protocolo a parte. Los

protocolos usados en este caso, son los EGP (Exterior Gateway Protocol). Mediante estos protocolos, los distintos sistemas autónomos pueden intercambiar información sobre las redes que se encuentran en su interior.

12

2 RIP

2.1 INTRODUCCIÓN A RIP

RIP, de las siglas en ingles Routing Information Protocol, es un protocolo de encaminamiento dinámico basado en el Algoritmo de Bellman-Ford (o Vector de Distancia). La descripción de este algoritmo fue a manos de Ford and Fulkerson, de ahí que este algoritmo a veces también se le denomine como el Algoritmo Ford-Fulkerson. El término Bellman-Ford también es usado para referirse a este algoritmo. Viene del hecho que la formulación se basa en la ecuación del Bellman, la base de la “Programación Dinámica”. El algoritmo del Vector de Distancia, define los procedimientos utilizados en el protocolo RIP para llevar a cabo en encaminamiento, así como de otros protocolos de encaminamiento como IGRP y EIGRP de Cisco.

Este protocolo se ha utilizado para el encaminamiento de redes de ordenadores desde la aparición de ARPANET. La red ARPANET nació en 1969 como resultado de un proyecto de investigación del Departamento de Defensa norteamericano, que trataba de encontrar una vía de comunicación alternativa a la comunicación a través de radio, ya que se preveía que en el caso de una guerra nuclear, temor con fundamento en aquella época, las comunicaciones por radio se verían fuertemente afectadas. ARPANET se considera como el origen de Internet.

RIP Comenzó a ser un estándar de facto para intercambiar información de

encaminamiento entre routers y hosts. Se utilizó para dicho propósito por la mayoría de los vendedores comerciales de routers IP.

El protocolo RIP se usa como un IGP. Fue diseñado para trabajar con un

tamaño de red moderado. Por consiguiente, esta pensado para redes que no sean demasiado grandes. No está pensado para el uso en ambientes muy complejos.

2.2 ALGORITMO DEL VECTOR DE DISTANCIA

El algoritmo del vector de distancia, define un procedimiento que busca la mejor ruta para cada destino en una red cualquiera de computadores. Para llevar a cabo esto, los routers de la red intercambian un conjunto de mensajes. Con la información obtenida, cada router guarda una ruta hacia cada destinación posible en el sistema, es decir, construye una tabla de encaminamiento. En la práctica es necesario guardar la siguiente información para cada destinación: - Dirección de destino: En implementaciones IP de este algoritmo, esto se traduce como la dirección IP de destino del host o de la red. - Puerta de enlace: El siguiente router donde se deben enviar los datos para que este se encarge de reencaminarlos hasta su destino.

13

- Interfaz: La conexión física que se debe usar para alcanzar la primera puerta de enlace. - Métrica: Parámetro que mide el coste de la ruta. En RIP, la métrica utilizada es el número de saltos que se debe realizar para alcanzar el destino. -Temporizador: Indica cuando fue la última actualización de la ruta.

A este conjunto de información se le conoce como Vector de distancia, ya que para cada ruta posible se incluye la distancia hasta llegar al destino, mediante el parámetro de métrica. Por tanto los routers de la red intercambian vectores de distancia para que todos los participantes en el algoritmo obtengan información sobre el estado de la red.

La métrica es una medida que sirve para comparar rutas. Si se obtienen dos rutas para llegar al mismo destino, se dice que la mejor ruta para llegar a ese destino es la que consuma un número menor de recursos de la red, es decir la del mínimo coste. En el protocolo RIP, se utiliza una métrica que cuenta a través de cuantos routers deben pasar los datos hasta llegar a su destino, es decir, el número de saltos que se debe realizar para alcanzar el destino. Por tanto, ante dos rutas posibles, la mejor, la del mínimo coste, será la que realice un número menor de saltos hasta llegar a un destino dado.

Fig. 5

Por ejemplo, en la Fig. 5, la métrica de la ruta que va del ordenador A hasta el ordenador D es 2, ya que tiene que pasar a través del ordenador B hasta llegar a su destino. Para llegar al ordenador F, existen dos posibilidades, o dos rutas: a través de B o a través de C. Si se escoge a través de B la métrica de esa ruta es 3. En cambio si se escoge a través de C la métrica es 2. Por tanto esta última es la mejor ruta ya que su métrica es

14

menor. Por otra parte, se considera métrica 0 la ruta de ir de una estación a sí misma. Aunque esta ruta parezca inútil, se debe incluir en los vectores de distancia.

En el ejemplo anterior se ha considerado una métrica de 1 para cada

enlace de la red. En ocasiones la métrica puede ser diferente en cada enlace. Esto es así porque puede ser que un enlace sea más lento que otro, o simplemente menos fiable. Por esta razón se definen métricas diferentes. En cualquier caso, en RIP se utiliza por defecto métricas de valor 1 en todos los enlaces.

Inicialmente cada máquina de la red solamente tiene información de sí

misma. Con los primeros mensajes intercambiados obtienen información sobre sus vecinos. A medida que se van intercambiando más mensajes con las máquinas vecinas el conocimiento de la red es mayor. Es necesario que la información se reciba periódicamente para mantener las mejores rutas en todo momento. De esta forma, es posible mantener las rutas óptimas para todo el sistema entero solamente usando la información obtenida de routers vecinos.

Es de esperar que este algoritmo converja en las estimaciones correctas

sobre las rutas en un tiempo finito, siempre y cuando no haya cambios de la topología de red. No existe un orden sobre el envío de información entre entidades. Simplemente, es importante que las entidades no paren de enviar actualizaciones, y que las redes no retrasen los mensajes demasiado. Cada entidad puede enviar actualizaciones según su propio reloj. Ante un cambio de sistema o topología el algoritmo de encaminamiento comienza a moverse hacia un nuevo equilibrio, usando el viejo como su punto de partida.

Cogiendo como referencia la Fig. 5, veamos como evoluciona el algoritmo

partiendo desde el inicio.

Fig. 6

Primeramente, cada estación solo tiene información de sí misma, por tanto

la información que contendran los vectores de distancia será la siguiente:

15

ESTACION Vector de distancia A [A:0] B [B:0] C [C:0] D [D:0] E [E:0] F [F:0]

Cada estación puede llegar a ella misma con métrica 0. Con la información

enviada, las estaciones aprenderan las rutas a las estaciones vecinas que tienen directamente conectadas, con un coste de 1.

ESTACION Rutas aprendidas A [A:0, B:1:i1, C:1:i2] B [B:0, A:1:i1, D:1:i2] C [C:0, A:1:i1, E:1:i2] D [D:0, B:1:i1, E:1:i2] E [E:0, C:1:i3, D:1:i1, F:1:i2] F [F:0, E:1:i1]

En los vectores de distancia, se incluyen ahora las rutas aprendidas:

ESTACION Vector de distancia A [A:0, B:1, C:1] B [B:0, A:1, D:1] C [C:0, A:1, E:1] D [D:0, B:1, E:1] E [E:0, C:1, D:1, F:1] F [F:0, E:1]

Las estaciones aprenden rutas de sus vecinos, y actualizan sus tablas de

encaminamiento. En la siguiente actualización incluyen las rutas que han aprendido en sus vectores de distancia que envían:

ESTACION Rutas aprendidas A [A:0, B:1:i1, C:1:i2, D→B:2:i1, E→C:2:i2] B [B:0, A:1:i1, D:1:i2, C→A:2:i1, E→D:2:i2] C [C:0, A:1:i1, E:1:i2, B→A:2:i1, D→E:2:i2, F→E:2:i2] D [D:0, B:1:i1, E:1:i2, F→E:2:i2, C→E:2:i2, A→B:2:i1] E [E:0, C:1:i3, D:1:i1, F:1:i2, B→D:2:i1, A→C:2:i3] F [F:0, E:1:i1, D→E:2:i1, C→E:2:i1]

Cuando se aprende una ruta nueva, se debe almacenar la puerta de

enlace y el interfaz. Por ejemplo, La estación A, ha aprendido la ruta de D, pero para llegar a D debe enviar los datos a través de B. En la tabla se simboliza como D→B (D vía B). Se puede observar que la estación A y B aún

16

no saben de la existencia de la estación F, y al revés, la estación F no sabe de la existencia de A y B. Las estaciones envían sus vectores de distancia, con las rutas aprendidas:

ESTACION Vector de distancia A [A:0, B:1, C:1, D:2, E:2] B [B:0, A:1, D:1, C:2, E:2] C [C:0, A:1, E:1, B:2, D:2, F:2] D [D:0, B:1, E:1, F:2, C:2, A:2] E [E:0, C:1, D:1, F:1, B:2, A:2] F [F:0, E:1, D:2, C:2]

Obsérvese que en los vectores de distancia no se incluye la puerta de

enlace de la ruta ni el interfaz. Sola se informa la métrica de cada destinación. En la tercera iteración las estaciones siguen aprendiendo nuevas rutas:

ESTACION Rutas aprendidas A [A:0, B:1:i1, C:1:i2, D→B:2:i1, E→C:2:i2, F→C:3:i2] B [B:0, A:1:i1, D:1:i2, C→A:2:i1, E→D:2:i2, F→D:3:i2] C [C:0, A:1:i1, E:1:i2, B→A:2:i1, D→E:2:i2, F→E:2:i2] D [D:0, B:1:i1, E:1:i2, F→E:2:i2, C→E:2:i2, A→B:2:i1] E [E:0, C:1:i3, D:1:i1, F:1:i2, B→D:2:i1, A→C:2:i3] F [F:0, E:1:i1, D→E:2:i1, C→E:2:i1, B→E:3:i1, A→E:3:i1]

La red ha llegado al equilibrio en tres actualizaciones. Todas las

estaciones se pueden comunicar entre ellas, ya que han aprendido todas las rutas. Aun así es necesario seguir enviando actualizaciones para mantener el equilibrio de forma periódica para que las estaciones detecten cambios en la topología. Por ejemplo, si dejamos de recibir el vector de distáncia de un router vecino, esto se debe a que dicho router ya no resulta accesible para nosotros.

Se puede resumir las acciones que debe hacer cada estación que participa en el algoritmo en tres puntos:

- Mantener una tabla con una entrada para cada destinación posible en el sistema. La entrada contendrá la distancia a la destinación, y la primera puerta de enlace en la ruta de esa red y el interfaz. Conceptualmente, debe de haber una entrada para ella misma, con métrica 0, pero no será realmente incluida en la tabla de encaminamiento. - Periódicamente, enviar su vector de distancia a cada vecino. - Recibir los vectores de distancia de sus vecinos y comparar las entradas recibidas con las almacenadas en la tabla de encaminamiento. Si se encuentra alguna con una métrica menor, escoger la nueva ruta.

17

2.2.1 CAMBIOS EN LA TOPOLOGIA En una red, los routers y líneas fallan. Esto implica que la topología de red

cambia, y por el mismo motivo, el sistema de vecinos cambia. Por lo tanto, la próxima vez que se hace el cálculo de rutas, el cambio tiene que reflejarse. Para solventar este problema, el algoritmo del vector de distancia debe disponer de un mecanismo de caducidad de las rutas. Este mecanismo es propio del protocolo específico que se utilice. En el protocolo RIP, cada puerta de enlace que participa en el encaminamiento envía un mensaje de actualización a todos sus vecinos una vez cada 30 segundos. Si no se obtiene la actualización transcurridos 180 segundos, se considera que o la puerta de enlace se ha roto o que la red de conexión ha dejado de funcionar. Entonces, se marca la ruta como inválida. Si recibimos de otro vecino una ruta válida, se substituye por la ruta que esta marcada como inválida. Se espera 180 segundos antes de dar por caducada una ruta a pesar de esperar respuesta de nuestros vecinos cada 30 segundos. Desafortunadamente, en las redes, los datos se pierden de vez en cuando, por lo tanto, no es buena idea invalidar una ruta basándose en una sola actualización que falte.

Es útil tener una manera de notificar a nuestros vecinos que no hay

actualmente una ruta válida de una cierta red. RIP, como otros protocolos de esta clase, hace esto a través de un mensaje normal de actualización, marcando esa red como inalcanzable. Se elige una métrica específica para indicar una destinación inalcanzable; ese valor es más grande que la métrica válida más grande que esperamos ver. En la implementación existente del RIP, se utiliza 16. Este valor se refiere normalmente al ‘infinito’, puesto que es más grande que la métrica válida más grande. 16 puede parecer un número asombrosamente pequeño. Más adelante se verá porque se escoge este y no otro.

En la Fig. 7, tenemos una topología de red constituida por cuatro

ordenadores conectados.

Fig. 7

18

Con la red en equilibrio, las estaciones tienes las siguientes rutas aprendidas:

ESTACION Rutas aprendidas A [A:0, B:1:i1, C:1:i2, D→C:2:i2] B [B:0, A:1:i1, C:1:i2, D→C:2:i2] C [C:0, A:1:i3, B:1:i1, D:1:i2]

Por tanto, enviarián los siguientes vectores de distancia:

ESTACION Vector de distancia A [A:0, B:1, C:1, D:2] B [B:0, A:1, C:1, D:2] C [C:0, A:1, B:1, D:1]

En la Fig. 8 se ilustra el caso anterior, pero el enlace entre la estación A y C ha dejado de funcionar. Se simboliza con una ‘x’.

Fig. 8

La estación A y la estación C se ven afectadas por este cambio de topología y marcan sus rutas como inválidas. Se incluyen las rutas inválidas con una métrica de 16, es decir, inalcanzables:

ESTACION Rutas aprendidas A [A:0, B:1:i1, C:16, D:16 ] B [B:0, A:1:i1, C:1:i2, D→C:2:i2] C [C:0, A:16 , B:1:i1, D:1:i2]

En la siguiente actualización, las estaciones afectadas aprenden de la estación B una ruta alternativa. La red se vuelve a equilibrar.

19

ESTACION Rutas aprendidas A [A:0, B:1:i1, C→B:2:i1, D→B:3:i1 ] B [B:0, A:1:i1, C:1:i2] C [C:0, A→B:2:i1 , B:1:i1, D:1:i2]

Según lo visto hasta ahora, se puede garantizar que el algoritmo permite a las estaciones, que encuentren las rutas idóneas a las destinaciones de la red. En caso de un cambio de topología el algoritmo es capaz de equilibrarse en un cierto tiempo.

2.2.2 PREVENCIÓN DE LA INESTABILIDAD: CUENTA A INFI NITO

El valor de métrica escogido en RIP para representar un destino inalcanzable, es 16. Si suponemos que un destino es inaccesible, todas las puertas de enlace inmediatamente vecinas fijarán la métrica para ese destino a 16. Las puertas de enlace un salto más lejos de los vecinos directos terminarían con una métrica 17; las entradas dos saltos más lejos con 18, y así sucesivamente. Esto es debido a que el cálculo de la métrica es la suma de costes para esa ruta. Aún así en RIP el valor máximo permitido para una métrica es 16. Por tanto el sistema converge en una métrica de 16 para el destino inalcanzable, en todas las puertas de enlace, es decir, una puerta de enlace como máximo puede fijar una métrica 16 en sus rutas, y esta indica que el destino de esa ruta es inalcanzable. En el apartado anterior, se ha visto que el algoritmo del vector de distancia permite equilibrar la red en un cierto tiempo cuando se produce un cambio en la topología de red. En algunos casos, según la topología de red y el cambio de topología producido, el tiempo de convergencia no es aceptable. En la Fig. 9 se ilustra una topología de tres ordenadores.

Fig. 9

20

Las rutas aprendidas al inicio son:

ESTACION Rutas aprendidas A [A:0, B:1:i1] B [B:0, A:1:i1, C:1:i2] C [C:0, B:1:i1]

Desde este punto, A y C envían sus vectores de distancia:

Fig. 10

Vector de A: [A:0, B:1] Vector de C: [C:0, B:1] La estación B también envía su vector de distancia:

Fig. 11

Vector de B: [B:0, A:1, C:1] La estación A aprende la ruta a la estación C. Y la estación C aprende la ruta a la estación A.

ESTACION Rutas aprendidas A [A:0, B:1:i1, C→B:2:i1] B [B:0, A:1:i1, C:1:i2] C [C:0, B:1:i1, A→B:2:i1]

La red ha llegado al equilibrio, cada estación puede comunicarse con el resto de estaciones del sistema. Supóngase que la línea de comunicación entre la estación A y B deja de funcionar:

21

Fig. 12

En la siguiente actualización B no recibe el vector de distancia de A. Transcurrido un tiempo sin recibir información sobre la estación A, la ruta a la estación A que tiene almacenada la estación B, caduca, y se marca como inalcanzable, es decir con métrica 16. Recuérdese que en RIP, el tiempo de caducidad de una ruta, es de 180 segundos.

ESTACION Rutas aprendidas A [A:0, B:16 , C:16] B [B:0, A:16 , C:1:i2] C [C:0, B:1:i1, A→B:2:i1]

Como la estación A queda aislada, tampoco recibe vectores de distancia de B y marca sus rutas como inalcanzables. La estación C envía su vector de distancia.

Fig. 13

Vector de C: [C:0, B:1, A:2] Como C aún no sabe que la línea entre la estación A y la estación B ha fallado, tiene en su base de datos una ruta para llegar hasta la estación A , que para ella es válida. Por tanto se incluye esta ruta en su vector de distancia. B piensa que C tiene un camino alternativo para llegar a la estación A e incluye una nueva entrada en su base de datos con métrica 3.

ESTACION Rutas aprendidas A [A:0, B:16, C:16] B [B:0, A→C:3:i2 , C:1:i2] C [C:0, B:1:i1, A→B:2:i1]

En este punto, como la estación C no recibe de la estación B la ruta que aprendió para llegar a la estación A (A→B:2), después de un cierto tiempo

22

marcará esa ruta como inválida, y en la actualización siguiente aprenderá de nuevo la ruta de la estación B, pero esta vez, con métrica 4.

ESTACION Rutas aprendidas A [A:0, B:16, C:16] B [B:0, A→C:3:i2, C:1:i2] C [C:0, B:1:i1, A→B:4:i1 ]

Ahora es B quién no recibe actualización de la ruta A que aprendió de C (A→C:3). Por tanto, a la larga adoptara una métrica de 5 para esta ruta.

ESTACION Rutas aprendidas A [A:0, B:16, C:16] B [B:0, A→C:5:i2 , C:1:i2] C [C:0, B:1:i1, A→B:4:i1]

Por culpa de estos rebotes de información entre las estaciones, la métrica de la ruta a la estación A se va incrementando, y no es eliminada de las tablas de encaminamiento. No se cancelará por completo hasta que no se alcance una métrica de 16, la máxima permitida. Por tanto se puede concluir que el tiempo de convergencia es lento. A este tipo de problemas se le conoce como Cuenta a infinito.

Para prevenir este tipo de situaciones, en el protocolo RIP se implementa dos mecanismos: ‘Horizonte dividido con actualización inversa’, y ‘Trigger Update’.

2.2.3 HORIZONTE DIVIDIDO CON ACTUALIZACIÓN INVERSA ENVENENADA

El problema descrito en el apartado anterior es causado por el hecho de que las estaciones se engañan mutuamente sobre las estimaciones que hacen. Horizonte dividido, es una técnica para evitar estos problemas. Para conseguirlo, no se envía información sobre una ruta por el mismo enlace por el que ha llegado. Además se utiliza la técnica de ‘Inversa envenenada’. Si una ruta es inalcanzable si que se anuncia por la misma interfaz que se aprendió que la ruta es inalcanzable. Véase la evolución de la topología de la Fig. 12, aplicando estas técnicas. Partimos del equilibrio antes de que la estación A dejara de funcionar.

ESTACION Rutas aprendidas A [A:0, B:1:i1, C→B:2:i1] B [B:0, A:1:i1, C:1:i2] C [C:0, B:1:i1, A→B:2:i1]

23

Cuando la estación A deja de funcionar:

ESTACION Rutas aprendidas A [A:0, B:16 , C:16] B [B:0, A:16 , C:1:i2] C [C:0, B:1:i1, A→B:2:i1]

La estación C envía su vector de distancia:

Vector de C: [C:0, B:1]

Como C aprendió la ruta a la estación A por la interfaz que la une con la

estación B, en su vector de distancia no incluye esta ruta. Por lo tanto, la estación B no aprenderá de nuevo la ruta a la red que ha dejado de funcionar cuando C mande su vector. Con el tiempo C marcara su ruta a la estación A como no válida por el hecho de no recibir actualizaciones por parte de B:

ESTACION Rutas aprendidas A [A:0, B:16, C:16] B [B:0, A:16, C:1:i2] C [C:0, B:1:i1, A:16 ]

Se puede concluir que utilizando estas técnicas la convergencia es mucho más rápida. De todas formas, en algunas topologías no es suficiente con utilizar estas técnicas.

En la Fig. 15 se muestra un escenario con 5 estaciones.

Fig. 14

24

ESTACION Rutas aprendidas N [N:0, A:1:i1, C→A:2:i1, B→A:2:i1, D→A:3:i1] A [A:0, N:1:i3, B:1:i1, C:1:i2, D→B:2:i1] B [B:0, A:1:i2, D:1:i1, C→A:2:i2, N→A:2:i2] C [C:0, A:1:i2, D:1:i1, B→A:2:i2, N→A:2:i2] D [D:0, B:1:i1, C:1:i2, A→B:2:i1, N→B:3:i1]

La red funciona correctamente y todas las estaciones se pueden comunicar con el resto de estaciones del sistema. De repente, la línea que une estación N con la estación A deja de funcionar.

Fig. 15

Como consecuencia a esto la estación N queda aislada del sistema y con

el tiempo eliminará todas sus rutas por no recibir vectores de distancia de la estación vecina A. Por otra parte, la estación A marcará la ruta a la estación N como inválida al no recibir actualizaciones. A envía su vector de distancia indicando con métrica 16 la ruta a la estación N.

25

Fig. 16

Esto implica que las estaciones B y C marquen la ruta a la estación N

como inalcanzable. Supóngase en este punto que D envía su vector de distancia.

Fig. 17 Como la estación D aprendió la ruta a la estación N gracias a la estación

B, no incluye en el vector de distancia dirigido a B esta ruta. Pero, en el vector de distancia dirigido a la estación C si que incluye esta ruta. Debido a esto, la estación C cree encontrar una ruta alternativa a través de la estación D y activa de nuevo la ruta a la estación N con métrica 4 vía D.

En las siguientes actualizaciones se entra en un proceso de cuenta a infinito de la ruta N:

26

Fig. 18

En este ejemplo se puede observar que la convergencia ante cambios en la topología es lenta. Por tanto se necesita de otro mecanismo adicional para evitar estas situaciones. Este mecanismo es ‘Trigger Update’.

2.2.4 TRIGGER UPDATE

La técnica ‘Trigger Update’, consiste en enviar las actualizaciones inmediatamente ante un cambio de rutas. Es decir, si una estación cambia una ruta de su base de datos, inmediatamente informa a sus vecinos de dicho cambio. Con este tipo de técnica se evita el problema descrito en el ejemplo anterior.

27

Fig. 19

Retómese el ejemplo cuando la estación A envía sus vectores de

distancia, indicando que la ruta a la estación N es inalcanzable. Inmediatamente después de que B y C reciben la noticia de que la ruta a la estación N es inalcanzable, reenvían esta información. Con esto se consigue que la estación D se entere de que la ruta a la estación N es inalcanzable antes de su próxima actualización periódica, y se evita de esta forma la cuenta a infinito.

Hasta el momento se ha enseñado las bases de los protocolos de encaminamiento basados en vectores de distancia. Se han mostrados diversos ejemplos donde en las rutas de encaminamiento se incluyen rutas hacia diferentes máquinas. No obstante, en redes IP, las máquinas se agrupan en redes. Conceptualmente, el proceso de encaminamiento es igual al mostrado en los ejemplos del algoritmo del vector de distancia, pero se incluye información de como llegar a una determinada red.

2.3 ESPECIFICACIONES DEL PROTOCOLO RIP

El Protocolo RIP tiene 2 versiones. La versión 1 descrita en el RFC (Request For Comments) 1058, y la versión 2, descrita en el RFC 2453. En el presente texto se describe primeramente el protocolo basándose en la versión 1. Finalmente, se dedica un apartado adicional para indicar las ampliaciones y mejoras que aporta la versión 2 del protocolo.

Cada router que utilice RIP se entiende que tiene interfaces a una o más redes del sistema. La métrica que se usa en RIP es el número de saltos y es un número entero entre 1 y 15 inclusivos. Por defecto se utiliza una métrica de

28

1 por salto. Sin embargo, un administrador del sistema puede fijar la métrica de cada red manualmente.

Cada entidad que usa RIP debe tener una tabla de encaminamiento. Esta tabla de encaminamiento debe tener una entrada para cada destinación posible en el sistema. Cada entrada contiene por lo menos la información siguiente:

- La dirección IP del destino o un rango de direcciones indicado mediante dirección de red + máscara - La métrica, o número de saltos hasta alcanzar el destino - La dirección IP de la puerta de enlace siguiente. Si el destino está en una de las redes directamente conectadas, este campo no será necesario.

- Una bandera para indicar que la información sobre la ruta ha cambiado recientemente.

- Temporizadores de tiempo asociados a la ruta.

La dirección IP de destino, puede ser tanto una dirección IP de una máquina como una dirección IP de una red o subred. Por tanto, en los vectores de distancia que intercambian los routers se puede anunciar rutas tanto de máquinas como de redes o subredes.

Inicialmente, las tablas de encaminamiento de cada router solo contienen entradas a las redes que están directamente conectadas. Después, cada router empieza a enviar vectores de distancia. Con los vectores de distancia recibidos los routers aprenden rutas nuevas de sus vecinos que van introduciendo en sus tablas de encaminamiento, siguiendo las pautas que marca el algoritmo del vector de distancia descrito en el apartado anterior.

2.4 FORMATO DEL MENSAJE

RIP envía su información encapsulada en datagramas del protocolo UDP (User Datagram Protocol). UDP es un protocolo del nivel de transporte para el intercambio de datagramas. Permite el envío de datagramas a través de la red sin que se haya establecido previamente una conexión, ya que el propio datagrama incorpora suficiente información de direccionamiento en su cabecera. Tampoco tiene confirmación, ni control de flujo, por lo que los paquetes pueden adelantarse unos a otros, y tampoco se sabe si ha llegado correctamente, ya que no hay confirmación de entrega o de recepción. Cada router que usa RIP tiene un proceso de encaminamiento que envía y recibe datagramas por el puerto 520 UDP. Por tanto, un datagrama RIP tendrá una cabecera IP y una cabecera UDP.

29

Además RIP permite procesos ‘silenciosos’. Un proceso silencioso normalmente no envía ningún mensaje. Sin embargo, escucha los mensajes enviados por otros. Estos procesos son utilizados habitualmente por ordenadores que no actúan como puertas de enlace, pero desean escuchar los mensajes de encaminamiento para supervisar las puertas de enlace locales y mantener sus tablas de encaminamiento actualizadas.

A continuación se muestra el formato que tienen los datagramas que se utilizan en RIP versión 1 para enviar información de la red. Los tamaños de campo están en octetos.

0 7 8 15 16 31 COMANDO (1) VERSIÓN (1) 0 (2) ADDRESS FAMILY IDENTIFIER 0 (2)

ADDRESS (4) 0 (4) 0 (4)

MÉTRICA (4)

Estos datagramas no son otra cosa que vectores de distancia. Cada datagrama contiene un comando, un número de versión, y otros argumentos referentes a una ruta. Cada datagrama puede contener hasta 25 rutas. Hay campos que quedan con valor 0. Estos campos están pensados para ampliaciones en futuras versiones del protocolo.

Si se tiene que enviar más de 25 entradas, se debe enviar en más de un mensaje.

30

A continuación se describirá el formato de la versión 1 del protocolo. Los

comandos utilizados en esta versión son: 1 – Request: Una petición al sistema para enviar toda o parte de su tabla de encaminamiento.

2 – Response: Mensaje que contiene toda o parte de la tabla de encaminamiento del remitente. Este mensaje se puede enviar en respuesta a una petición, o puede ser un mensaje de actualización generado por el remitente.

3 – Traceon: Obsoleto. Los mensajes que contienen este comando deben ser ignorados.

4 – Traceoff: Obsoleto. Los mensajes que contienen este comando deben ser ignorados.

5 – Reserved: Este comando reservado es utilizado por Sun Microsystems para propósitos suyos. Si se añaden nuevos comandos en alguna versión más actual, deben comenzar por el 6. Los mensajes que contienen este comando pueden ser ignorados si en las implementaciones utilizadas no esta definido.

Para Request y Response, el resto del datagrama contiene una lista de destinaciones, con información sobre cada una. Cada entrada en esta lista contiene: - Identificador de la familia: Específica el tipo de dirección de esa entrada. En direcciones IP el identificador de la familia es 2. - Dirección: Dirección destino de la ruta. - Métrica: Número de saltos hasta llegar a la dirección de destino. Debe ser un valor entre 1 y 16 inclusivos.

El tamaño máximo del datagrama es 512 octetos. Esto incluye solamente las partes del datagrama descritos arriba. No tiene en cuenta las cabeceras propias del IP o del UDP.

2.5 CONSIDERACIONES EN EL DIRECCIONAMIENTO

Los routers de una red RIP, intercambian mensajes de petición y de

respuesta para llevar a cabo el encaminamiento. Sin embargo, las destinaciones que aparecen en estos mensajes pueden ser de redes, de ordenadores, o una dirección por defecto (la dirección 0.0.0.0). Generalmente, la información de encaminamiento de ordenadores individuales no es necesaria. Si cada ordenador en una red o subred dada es accesible a través de una puerta de enlace, entonces no es necesario considerar a estos en las tablas de encaminamiento.

31

Fig. 20

En la Fig. 20 se muestran dos redes: La red 10.0.0.0 y la red 192.168.1.0. Para que el ordenador A se pueda comunicar con la red 192.168.1.0 no es necesario que almacene en su tabla de encaminamiento la ruta a cada uno de los ordenadores de esta red, ya que todos estos son accesibles a través de la puerta de enlace B, con dirección 10.0.0.2. Por lo tanto su tabla de encaminamiento sería:

RED GW Métrica 10.0.0.0 192.168.1.0

DC 10.0.0.2

0 1

GW: Gateway DC: Directamente conectado

Si se incluyen las rutas a los ordenadores individuales la tabla de encaminamiento sería más complicada:

RED GW Métrica 10.0.0.0 192.168.1.0 192.168.1.2 192.168.1.3 192.168.1.4

DC 10.0.0.2 10.0.0.2 10.0.0.2 10.0.0.2

0 1 1 1 1

Claramente se puede ver que en este caso se puede resumir las rutas a

los ordenadores individuales por la ruta a la red.

Por tanto, los routers que utilizan RIP, al encaminar un datagrama, primero deben comparar su dirección de destino con la lista de direcciones ya aprendida, para ver si es posible emparejarla con una dirección de subred o una red ya aprendida.

Cuando un router evalúa una destinación nueva que recibe, su interpretación dependerá de si conoce o no la máscara de subred que se le aplica. Si la conoce, es posible determinar que tipo de dirección es. Por ejemplo, considérese que la red 128.6.0.0 tiene una máscara de subred de 255.255.255.0. Por tanto la dirección 128.6.0.0 es de red, la 128.6.4.0 es de

32

subred, y la 128.6.4.1 es una dirección de un ordenador en particular. Sin embargo, si el router no sabe la máscara de subred, la interpretación de una dirección puede ser ambigua. En este tipo de casos, se considera que estas direcciones corresponden a direcciones de ordenador. Para evitar esta clase de ambigüedad, no se debe enviar rutas de subred a otros vecinos que no sepan la máscara apropiada. Por tanto, a menos que se hayan hecho las provisiones especiales, las rutas a una subred no se deben enviar fuera de la red de la cual forma parte dicha subred.

La dirección especial 0.0.0.0 es usada como la ruta por defecto. Esta dirección se utiliza para agrupar todas aquellas direcciones que no se sabe donde encaminarlas. Normalmente, es decisión del administrador la manera de manejar este tipo de entrada.

2.6 TEMPORIZADORES

Para determinar la caducidad de una ruta es necesario el uso de temporizadores. Cada router asocia tres temporizadores para cada ruta que tiene almacenada: - Tiempo de actualización cada 30 segundos. Cada vez que el temporizador llega a 30 segundos se produce una actualización. El proceso de RIP despierta y envía un mensaje de respuesta no solicitado con el vector de distancia, a todos los routers vecinos. - Tiempo de En cancelación a los 180 segundos. Una vez transcurridos 180 segundos sin recibir actualización de una ruta, se considera no válida. Sin embargo la ruta se retiene un cierto periodo de tiempo, lo cual permite advertir a los vecinos que la ruta ha sido eliminada. - El temporizador del ‘recolector de basura’, a los 120 segundos. Una vez transcurridos 120 segundos, después de que una ruta haya pasado al estado ‘En cancelación’, la ruta es definitivamente eliminada de la tabla de encaminamiento. El nombre de este temporizador, ‘recolector de basura’, viene del hecho que esta asociado a todas aquellas rutas residuales que se deben ir borrando de la tabla de encaminamiento.

Por consiguiente, para que una ruta pase al estado ‘En Cancelación’ deben transcurrir 6 períodos de actualización sin recibir noticias de esta ruta, y 120 segundos más para que sea definitivamente eliminada.

33

Una ruta puede ser marcada como no válida por dos razones: - El temporizador de ‘En cancelación’ expire. - La métrica de la ruta es 16. En cualquier caso, se sigue el siguiente proceso para cancelar una ruta: - El temporizador de ‘recolector de basura’ se fija a 120 segundos. - La métrica para la ruta se fija a 16 (infinito). Esto hace que la ruta sea quitada del servicio. - Se activa una bandera indicando que ha cambiado esta entrada. Esto implica el envío inmediato del nuevo vector de distancia (Trigger Update).

Hasta que expira el contador de tiempo de ‘recolector de basura’, la ruta se incluye en todas las actualizaciones enviadas, con una métrica de 16. Cuando expira el contador, la ruta se suprime de la base de datos y no se incluye en los vectores de distancia.

Si se encuentra una nueva ruta a esta red mientras el contador ‘recolector de basura’ esta activo, la nueva ruta substituye la que está a punto de ser suprimida, y el contador se desactiva.

2.7 PROCESO DE ENTRADA

El proceso de entrada del protocolo RIP se produce cuando un router que utiliza este protocolo recibe un vector de distancia RIP, y consiste en el procesamiento de este. Antes de procesar los vectores detalladamente, se debe observar el formato de estos. Para ello se mira el campo ‘Versión’ en el datagrama: Versión 0: Los datagramas con versión 0, son ignorados. Estos corresponden a una versión anterior del protocolo, en la que el formato del paquete era de una máquina específica. Versión 1: Los datagramas se procesarán. Todos los campos que tienen que ser 0 se comprueban. Si una de ellos no lo es, el mensaje entero se ignora. Versión >1: Versiones futuras del protocolo, que pueden utilizar los campos puestos a 0. Este es el caso de la versión 2 que veremos más adelante.

Después de comprobar la versión, el proceso dependerá del valor que tenga el campo ‘Comando’.

34

2.7.1 COMANDO REQUEST

La petición (Request) se usa para recibir toda o parte de la tabla de encaminamiento. Normalmente, se envía una petición broadcast por el puerto UDP 520. En este caso, los ordenadores que participan de forma pasiva, es decir, que solo están a la ‘escucha’ no responden a la petición. Sin embargo, puede haber situaciones que interese que respondan también. En ese caso, la petición se debe enviar por un puerto UDP que no sea el 520. Si la petición viene de cualquier otro puerto, deben responder.

La petición es procesada entrada a entrada. Si no hay entradas, no se da ninguna respuesta. Existe un caso especial. Si hay una sola entrada en la petición, con un identificador de la familia de la dirección de 0 (que significa sin especificar), y una métrica al infinito, es decir, a 16, esto es equivalente a una petición de toda la tabla de encaminamiento.

0 7 8 15 16 31 1 (Request) VERSIÓN 0

0 0 0 0 0

16 (Metrica)

Este tipo de mensaje suele ser enviado por routers que acaban de ser reiniciados o routers que se ponen en funcionamiento por primera vez. A excepción de este caso especial, el proceso es muy simple. Para cada entrada, se mira la destinación en la base de datos de encaminamiento. Si hay una ruta, poner la métrica de esa ruta en el campo métrica correspondiente del datagrama. Si no hay ruta para esa destinación especificada, poner a infinito, es decir, 16, en el campo métrica. Una vez que se hayan completado todas las entradas, poner el comando en respuesta, es decir comando a valor 2, y enviar el datagrama nuevo por el puerto por el cual vino.

Si la petición es de la tabla completa, se hace el proceso normal con horizonte dividido. Por tanto ciertas entradas de la tabla de encaminamiento no serán mostradas. En cambio, si la petición es de un número específico de entradas, se enviarán las pedidas, pero no se aplicara el proceso de horizonte dividido. Normalmente esto último se utiliza para hacer diagnósticos.

2.7.2 Comando Response

Para generar un mensaje de respuesta el campo comando del mensaje debe ser 2. Las respuestas se pueden recibir por varias razones: - Respuesta a una consulta específica - Una actualización regular - Accionados por un cambio en la métrica

35

Indiferentemente de cómo fueron generadas las respuestas, el proceso a seguir es el mismo.

Como el proceso de respuesta puede actualizar la tabla de encaminamiento de un router, es importante comprobar que el mensaje de respuesta sea válido. La respuesta debe ser ignorada si viene por otro puerto que no sea el 520. La dirección IP de la respuesta se debe comprobar para que sea de un vecino válido.

Una vez el datagrama es considerado válido, se procesan las entradas una a una. Mirar la dirección de destino. Comprobar el identificador de la familia de la dirección. Si no es un valor esperado, por ejemplo direcciones IP, ignorar la entrada. También se tiene que comprobar que las direcciones no sean de la clase D o E, o si es la 127 ‘loopback’ o de ‘localhost’. Comprobar que la versión sea coherente con los campos a 0 que debe llevar.

Cuando el mensaje de respuesta recibido tiene el formato correcto según las comprobaciones anteriores, se cotejan las rutas recibidas por las ya aprendidas. Primeramente se mira si la ruta esta o no en la tabla de encaminamiento. En caso de que no este, generalmente se agregará una entrada nueva. Sin embargo, hay varias excepciones. Si la métrica es infinita, no se agregará la entrada. Se debe evitar agregar rutas a ordenadores si son parte de una red o subred para la cual ya se tiene entrada buena. En cualquier otro caso, se agregará una nueva entrada a la base de datos de encaminamiento. Esto incluye las acciones siguientes: - Insertar la destinación y la métrica. - Insertar la puerta de enlace. - Inicializar el temporizador de caducidad de la ruta. Si el temporizador ‘recolector de basura’ está funcionando en esa ruta, pararlo. - Activar la bandera de cambio de ruta, y señalar el proceso de salida para provocar una actualización.

Si hay una ruta ya existente, primero se tiene que comparar las puertas de enlace. Si es la misma, se inicializa el temporizador de caducidad. Después se compara la métrica. Si la métrica es más baja:

- Se actualiza la ruta por la del datagrama, Es decir, se pone la nueva métrica y la puerta de enlace nueva. - Inicializar el temporizador. - Activar la bandera de cambio de ruta, y señalar el proceso de salida para provocar una actualización.

Si la métrica nueva es 16, se inicia el proceso para suprimir la ruta. La ruta se utilizará solo para los paquetes de encaminamiento, y se inicializa el

36

temporizador de cancelación. Observar que una cancelación se produce solo cuando la métrica se pone por primera vez en 16. Si la métrica era ya 16, una futura cancelación será ignorada.

Si la métrica nueva es igual que la vieja, lo más simple es no hacer nada, solo se inicializa el temporizador de caducidad.

Cualquier entrada se ignora en el caso que fallen las comprobaciones, pues esta es considerada peor que la ruta actual.

2.8 Proceso de salida

En este apartado se detalla el proceso usado para crear los mensajes de respuesta que contienen toda o parte de una tabla de encaminamiento. Este proceso puede ser accionado por varios motivos: - Debido a una petición. En este caso, el mensaje solo se envía a una destinación. - Por una actualización regular. Cada 30 segundos, la tabla entera se envía a los vecinos. - Debido a actualizaciones accionadas. Siempre que la métrica de una ruta cambia, se acciona una actualización.

Cuando una respuesta se tiene que enviar a todas las destinaciones, es decir, la actualización regular o una actualización accionada, se envía un mensaje broadcast a todas las redes conectadas. En la mayoría de los casos esto equivale a todas las puertas de enlace vecinas. Sin embargo, hay algunos casos donde esto no es bueno, ya que puede llegar a redes que no interesa que lleguen mensajes de encaminamiento. Si este es el caso, se debería crear una lista real de los vecinos, y enviar un datagrama a cada uno explícitamente. Este mecanismo es definido por cada implementador.

Las actualizaciones accionadas pueden causar cargas excesivas en redes con capacidad limitada o con muchas puertas de enlace. Por consiguiente, el protocolo requiere que se incluyan provisiones para limitar la frecuencia de actualizaciones accionadas. Las actualizaciones accionadas se pueden anular si coincide al mismo tiempo con la actualización regular.

Las actualizaciones accionadas no necesitan incluir la tabla de encaminamiento entera. Solo las rutas que han cambiado. Más concretamente, en los mensajes generados se incluirán las rutas que tengan la bandera de cambio activada. Cuando se hacen actualizaciones accionadas o normales se usa el horizonte dividido. Una vez se hayan hecho las actualizaciones accionadas, las banderas de cambio se deben desactivar.

La única diferencia entre una actualización accionada y otros mensajes de actualización es la posible omisión de las rutas que no han cambiado. El resto de los mecanismos son similares.

37

A continuación se detalla como se genera un datagrama de respuesta para

una red directamente conectada en particular:

La dirección IP origen debe ser la del ordenador que envía la actualización. Esto es importante porque esta dirección se pone en las tablas de encaminamiento de otros routers. Si se utiliza una dirección incorrecta, otros routers pueden no encaminar bien los datagramas. Poner el número de la versión RIP. Poner el comando en respuesta. Poner los campos que deben ser cero, a cero. Ahora se van completando las entradas.

El tamaño máximo del datagrama es 512 octetos. Cuando no hay suficiente espacio hay que enviar dos datagramas.

Las rutas se deben incluir en el datagrama aunque sus métricas sean infinitas. Si la puerta de enlace de una ruta está en la red para la cual esta destinado el datagrama, la métrica se pone a 16, o se quita la entrada entera. Ignorar las entradas según horizonte dividido con retorno envenenado.

2.9 EJEMPLO RIP

A modo de ejemplo y para retener los procedimientos vistos anteriormente que usa el protocolo RIP, se propone un ejemplo de una red RIP, ilustrado en la Fig. 21.

Fig. 21

Se trata de un conjunto de 4 redes y 3 routers dispuestos en serie. Cada router tiene dos interfaces y se han asignado direcciones IP respetando la singularidad en la red.

Inicialmente los routers tienen en sus tablas de encaminamiento las redes a las que están directamente conectadas. Cada 30 segundos, los routers envían sus tablas por sus interfaces a todos sus vecinos. Para ello utilizan la dirección de broadcast. Router A

Destino Máscara Gateway IF Métrica 192.168.0.0 255.255.255.0 0.0.0.0 eth0 0 192.168.1.0 255.255.255.0 0.0.0.0 eth1 0

38

Router B


Router C


Supóngase que los routers acaban de encenderse. En este caso, envían un mensaje de petición de la tabla de encaminamiento a sus vecinos. El formato de este mensaje es de una sola entrada, con un identificador de la familia de la dirección de 0 y una métrica al infinito, es decir, a 16.

0 7 8 15 16 31 1 (Request) 1 (Versión) 0

0 (Cero) 0 0 0 0

16 (Métrica) Supóngase que el router B recibe una petición de la tabla del router A. El

router B construye su vector de distancia y lo envía al router A. El router A recibirá el siguiente datagrama:

0 7 8 15 16 31 2 (Response) 1 (Versión) 0

2 0 192.168.2.0

0 0

1 (Métrica)

Como se puede observar, en el datagrama enviado, no se incluye la ruta a la red 192.168.1.0. ya que se esta utilizando ‘horizonte dividido’. El router A actualiza su tabla de encaminamiento: Router A

Destino Máscara Gateway IF Métrica 192.168.0.0 255.255.255.0 0.0.0.0 eth0 0 192.168.1.0 255.255.255.0 0.0.0.0 eth1 0 192.168.2.0 255.255.255.0 192.168.1.2 eth1 1

39

De forma similar el resto de routers del sistema también aprenderán las rutas. Router B

Destino Máscara Gateway IF Métrica 192.168.1.0 255.255.255.0 0.0.0.0 eth0 0 192.168.2.0 255.255.255.0 0.0.0.0 eth1 0 192.168.3.0 255.255.255.0 192.168.2.2 eth1 1 192.168.0.0 255.255.255.0 192.168.1.1 eth0 1

Router C

Destino Máscara Gateway IF Métrica 192.168.2.0 255.255.255.0 0.0.0.0 eth0 0 192.168.3.0 255.255.255.0 0.0.0.0 eth1 0 192.168.1.0 255.255.255.0 192.168.2.2 eth0 1

Debido a las ‘Trigger Updates’, cuando se realiza un cambio en la tabla de

encaminamiento de cada router se genera automáticamente una actualización. Router A


Router B


Router C


Con esto, los routers aprenden todas las rutas del sistema, y la red llega a

su equilibrio con rapidez.

40

2.10 RIP VERSION 2

En este apartado se pretende describir las mejoras que ofrece RIP v2 respecto a su versión anterior.

2.10.1 FORMATO MENSAJE RIP VERSION 2

RIP v2 también usa el puerto 520 UDP para enviar y recibir datagramas. El formato de RIP v2 permite que los routers compartan información adicional importante. La cabecera del mensaje es el mismo para los RIP v1 y los RIP v2. En cambio el resto del mensaje cambia sustancialmente: 0 7 8 15 16 31

COMANDO (1) VERSIÓN (1) 0 (2) ADDRESS FAMILY IDENTIFIER ETIQUETA DE RUTA (2)

CABECERA EXTRA (20) IP ADDRESS (4)

MÁSCARA DE SUBRED (4) SIGUIENTE SALTO (4)

MÉTRICA (4)

Para especificar que se trata de RIP v2 se pone el número 2 en el campo versión. Campos que en la versión 1 del protocolo se dejaban a 0, ahora en la versión 2 se utilizan. Los campos añadidos son: - Etiqueta de ruta:

El campo de etiqueta de ruta proporciona un método para separar las rutas ‘internas’ de RIP, es decir, rutas para las redes dentro del dominio de encaminamiento RIP, y las rutas ‘externas’ de RIP, aprendidas por un EGP o de otro IGP.

Los routers que utilizan otros protocolos a parte de RIP se deben configurar con la etiqueta de ruta para importar rutas de otras fuentes. Las rutas importadas de un EGP deben marcarse con una etiqueta fijada arbitrariamente.

Serían posibles otras aplicaciones a la etiqueta de ruta, mientras todos los routers del dominio RIP las usen. - Cabecera extra para autenticación:

En la versión dos, el protocolo tiene una nueva funcionalidad de autentificación. RIP utiliza una entrada completa para realizar esta función. Si el identificador de la familia de la dirección de la primera y solamente de la primera entrada de un mensaje es 0xFFFF, el resto de la entrada contiene información de autentificación. Esto significa que como máximo habrá 24 entradas RIP en el resto del mensaje. Si no usamos autentificación en un mensaje, la secuencia 0xFFFF no debe aparecer en ningún identificador de la familia de dirección en ninguna entrada. Un mensaje con autentificación comenzaría como sigue:

41

0 7 8 15 16 31

COMANDO (1) VERSIÓN (1) SIN USO (2) 0XFFFF TIPO DE AUTENTIFICACIÓN (2)

AUTENTIFICACIÓN (16)

Actualmente, el único tipo de autentificación es una contraseña simple y corresponde al tipo 2. Los 16 octetos contienen la contraseña en texto plano. Si la contraseña ocupa menos de 16 octetos, se rellena con ceros a la izquierda.

Si un router no se configura para autentificar mensajes RIP v2, los mensajes RIP v1 y los RIP v2 no autentificados serán aceptados. Los mensajes RIP v2 autentificados serán rechazados. Si el router se configura para autentificar mensajes RIP v2, los mensajes RIP v1 y los RIP v2 que pasen la autentificación serán aceptados. Los no autentificados y los mensajes no válidos de RIP v2 serán rechazados. Para una seguridad máxima, los mensajes RIP v1 deben ser ignorados cuando se esta autentificando, si no, la información de encaminamiento de mensajes autentificados sería propagada por routers RIP v1 de forma no autentificada.

Como los mensajes que utilizan autentificación están marcados con una familia de dirección 0xFFFF, un sistema RIP v1 ignoraría este mensaje. - Máscara de Subred:

El campo de máscara de subred contiene la máscara de subred que se aplica a la dirección IP. Si este campo es cero, entonces quiere decir que no se ha incluido la máscara para esa entrada.

En un interfaz donde un router RIP v1 puede oír la información de otro RIP v2 las reglas que se aplican son las siguientes: - La información interna de una red nunca debe ser anunciada en otra red. - La información sobre una subred en particular no se puede anunciar donde los routers son RIP v1, donde se puede considerar una ruta de host. - Siguiente salto:

Es la siguiente dirección IP a la cual deben ser enviados los paquetes de una ruta. Un valor de 0.0.0.0 en este campo indica que el siguiente salto es vía el autor del anuncio RIP. Una dirección de salto siguiente, forzosamente, debe ser accesible directamente.

El propósito de este campo es eliminar los paquetes que son encaminados a través de saltos adicionales del sistema. Es especialmente útil para redes donde RIP no esta funcionando en todos los routers.

42

Fig. 22

En la Fig. 22, se muestra un ejemplo de aplicación del campo ‘Siguiente

salto’. En este ejemplo se están usando dos protocolos de encaminamiento diferentes. Por una parte se esta utilizando RIPv2, y por otra, se esta utilizando el protocolo OSPF. Como A y C utilizan un protocolo de encaminamiento diferente no se entienden y entonces A no puede aprender nuevas rutas a través de C. Por tanto todas las rutas las debe aprender a través de B. No obstante, B puede utilizar el campo ‘Siguiente salto’ para indicar al router A que reencamine directamente sus paquetes al router C, y de esta forma conseguir un encaminamiento más óptimo.

Obsérvese que el salto siguiente es un campo de consulta. Es decir, si se ignora la información proporcionada, se puede encaminar pero es posible que no de la forma óptima. Si el salto siguiente recibido no es directamente accesible, debe ser tratado como 0.0.0.0.

2.10.2 CONSIDERACIONES Y COMPATIBILIDADES

Para reducir la carga innecesaria, se usa una dirección multicast en las actualizaciones periódicas. La dirección multicast es 224.0.0.9.

Si un router RIP v2 recibe una petición RIP v1, debe responder con una respuesta RIP v1. Si el router se configura para enviar solamente mensajes RIP v2, no debe responder la petición de RIP v1.

La versión 1 del protocolo específica que los mensajes RIP de la versión 0 son ignorados, que las de versión 1 son ignorados cuando se encuentre un campo definido como 0 y es diferente a cero, y que los mensajes RIP de versión mayor a 1 no deben ser descartados si no se encuentra un campo definido como 0 con valor diferente de cero. Por tanto la versión 2 de RIP es totalmente compatible con la versión antigua.

Un router compatible es necesario por dos razones. Primero, en implementaciones de RIP v1 no se siguen algunas reglas propias de RIP v2. En segundo lugar, el uso de multicasting evitaría que los sistemas RIP v1 recibieran las actualizaciones RIP v2. Por consiguiente un router debe ser configurado interfaz a interfaz según corresponda. Un router tiene cuatro configuraciones:

43

- RIP v1, en el cual solamente se envían los mensajes RIP v1 - Compatibilidad RIP v1, en el cual los mensajes RIP v2 son broadcast. - RIP v2, en el cual los mensajes RIP v2 son multicast - ‘Ninguno’, que inhabilita enviar mensajes RIP.

Se recomienda fijar por defecto RIP v1 o RIP v2, pero nunca Compatibilidad RIP v1. Esto es así debido a los problemas potenciales que pueden ocurrir en algunas topologías.

Los routers deben también configurarse, para aceptar RIP v1 solamente, RIP v2 solamente, o ninguno. Debe configurarse por interfaz. Se recomienda que por defecto se escoja el elegido para enviar actualizaciones.

Como los paquetes de la versión 1 no contienen información de subred, la semántica empleada por los routers en las redes que contienen la versión 1 y las redes de la versión 2 se debe limitar al de la versión 1.

2.11 LIMITACIONES DEL PROTOCOLO

El protocolo RIP no soluciona todos los problemas del encaminamiento. Según lo mencionado en la introducción, está previsto para el uso como IGP, en redes razonablemente homogéneas y de tamaño moderado. A continuación se enumeran algunas limitaciones específicas del protocolo: - El protocolo esta limitado para redes que no superen los 15 saltos en sus rutas. Los diseñadores pensaron que el diseño básico del protocolo era inapropiado para redes más grandes. Nótese que este límite asume un coste unitario para cada salto. Esta es la manera que RIP se configura normalmente. Si el administrador del sistema elige utilizar costes más grandes, el límite superior de 15 puede convertirse en un problema. - Otro limitación es la ‘cuenta al infinito’ en ciertas situaciones inusuales. Si en un sistema, una ruta de encaminamiento implicará a todos los routers, la resolución de la ruta requeriría mucho tiempo (si la frecuencia de las actualizaciones de la información de encaminamiento es limitada) o ancho de banda (si las actualizaciones fueran enviadas siempre que los cambios fueran detectados). Tal ruta consumiría una cantidad grande de ancho de banda de la red antes de que la ruta fuera corregida. Creemos que en casos realistas, esto no será un problema excepto en líneas lentas. Incluso entonces, el problema será bastante inusual, puesto que se toman varias precauciones para prevenir estos problemas. - Este protocolo usa ‘métrica’ fija para comparar rutas alternativas. Esto no es apropiado para situaciones donde se requiere un servicio a tiempo real, fiabilidad, o balanceo de carga.

44

Hasta aquí llega la descripción del protocolo RIP. En el siguiente bloque se presenta el diseño de ataque utilizado para vulnerar la seguridad del protocolo, y provocar de esta forma una denegación del servicio en una red cualquiera.

45

3. DISEÑO DE ATAQUE

3.1 INTRODUCCIÓN

Una vez se tienen todos los detalles del funcionamiento del protocolo RIP, descritos en el apartado anterior, ya se está en condiciones para iniciar el diseño de una estrategia para provocar una denegación de servicio en una red conmutada que utilice este protocolo para enrutar.

Se parte de la idea de que se dispone de una entidad o PC, dentro de la red, la cual se controla completamente. La red podrá ser cualquier topología posible, por lo tanto, se debe determinar cuando será posible y cuando no una denegación de servicio utilizando la estrategia de ataque que se define en este apartado.

La definición de la estrategia de ataque presentada en este apartado es teórica. Esto quiere decir que hace falta una puesta a la práctica para confirmar el correcto funcionamiento.

3.2 CONOCIMIENTO DE LA RED

La primera condición para realizar un buen ataque, es conocer la red a la que se esta atacando. No obstante, se ha mencionado como premisa que la red atacada puede presentar cualquier topología. Por tanto se debe buscar un mecanismo que permita conocer la red, sea cual sea la topología de la misma.

Supóngase que tenemos control de una entidad dentro de una red

cualquiera donde se utiliza el protocolo RIP. Si se actuara como un sistema silencioso o pasivo, es decir, sin participar en las actualizaciones de las tablas, llegarían actualizaciones de los vecinos por lo menos cada 30 segundos. Por consiguiente, el primer paso para realizar el ataque será aprender de los vecinos el estado de la red. Y que mejor forma para conocer el estado de la red que realizando una petición de vector de distancia directamente a los routers que se encuentran en nuestro segmento de red.

Como ya se vio en la definición del protocolo, para realizar una petición de toda la tabla se construye un datagrama con el campo comando ‘01’, y una sola entrada. El identificador de la familia de esta entrada será 0 (sin especificar), y con métrica 16. 0 7 8 15 16 31

01 VERSIÓN (1) 0 (2) 0 0 (2)

IP ADDRESS (4) 0 (4) 0 (4) 16

46

Si se encuentran routers conectados directamente a nuestra entidad controlada, se recibirá como mínimo un vector de encaminamiento de cada uno.

3.3 MENSAJERIA FALSA

Gracias a la información recibida por la petición de las tablas de encaminamiento la entidad controlada tendrá conocimiento de las LANs que hay interconectadas en el sistema que tiene que atacar.

Para provocar una denegación de servicio en una red, hay que provocar que los routers de la red no reencaminen bien los datos. Para conseguir esto, se debe conseguir que las tablas de encaminamiento de los routers no sean correctas, es decir, las rutas no sean las adecuadas para encaminar.

El parámetro métrica es el utilizado para determinar si una ruta es mejor que otra, y por tanto, es el parámetro que utilizan los routers para actualizar sus rutas, el parámetro que es capaz de cambiar una ruta de las tablas de encaminamiento. Aprovecharemos este aspecto para modificar las tablas de encaminamiento de los routers de forma fraudulenta.

Por consiguiente, la entidad controlada tiene que ser capaz de forzar a los routers de la red a reencaminar mal los datos. Para ello, puede enviar vectores de distancia con métricas falsas, especialmente escogidas, que hagan cambiar las rutas que estos tienen almacenadas en sus tablas de encaminamiento.

Fig. 23

Supóngase que el ordenador A de la Fig. 23 es la entidad controlada dentro de un sistema RIP. El ordenador B presentaría la siguiente tabla de encaminamiento:

Destino Máscara Gateway IF Métrica 1.0.0.0 255.0.0.0 0.0.0.0 eth0 0 2.0.0.0 255.0.0.0 0.0.0.0 eth1 0 3.0.0.0 255.0.0.0 2.0.0.2 eth1 1 4.0.0.0 255.0.0.0 2.0.0.2 eth1 2 5.0.0.0 255.0.0.0 2.0.0.2 eth1 3 6.0.0.0 255.0.0.0 2.0.0.2 eth1 4

47

Con el fin de cambiar las tablas de encaminamiento del ordenador B, la entidad controlada A debe proporcionar rutas mejores a las que tiene B almacenadas. Para proporcionar una ruta mejor debe tener una métrica menor. La menor métrica permitida en el protocolo RIP es 1. Por tanto, la entidad controlada debe construir un vector falso de actualización con las métricas a 1:

0 7 8 15 16 31 02 VERSIÓN (1) 0 (2)

2 0 (2) 1.0.0.0 0 (4) 0 (4)

1 2 0 (2)

2.0.0.0 0 (4) 0 (4)

1 2 0 (2)

3.0.0.0 0 (4) 0 (4)

1 2 0 (2)

4.0.0.0 0 (4) 0 (4)

1 2 0 (2)

5.0.0.0 0 (4) 0 (4)

1 2 0 (2)

6.0.0.0 0 (4) 0 (4)

1

Cuando el ordenador B reciba este vector, mirará si hay alguna ruta mejor que las que tiene almacenadas en su tabla de encaminamiento. En este caso, encontrará que la ruta a la red 4.0.0.0 es mejor, ya que la entidad controlada le esta proporcionando una alternativa con métrica 1 y el ordenador B tiene esta ruta con métrica 2. Por tanto el ordenador B actualizara su tabla de encaminamiento. Por el mismo motivo, la ruta a la red 5.0.0.0 y la red 6.0.0.0 también cambiaran:

48


A partir de este momento los datos que el ordenador B quiera enviar a la

red 4.0.0.0 a la red 5.0.0.0 o a la red 6.0.0.0, los enviará por su interfaz eth0 vía 1.0.0.1, y como es de esperar, los datos no llegarán nunca, es decir, se ha provocado una denegación de servicio entre el ordenador B y la red 4.0.0.0, 5.0.0.0 y 6.0.0.0. A efectos de B la topología de red es como la de la Fig. 24:

Fig. 24

El ordenador B no ha actualizado más rutas porque las alternativas que le daba la entidad controlada A eran a igual de condiciones o peores. Por tanto, por ahora se puede concluir que es posible provocar una denegación a los vecinos de la entidad controlada enviando métricas 1, pero solo en las redes que se encuentren como mínimo a dos saltos de los ordenadores atacados.

3.4 EXPANSIÓN DE LA MENSAJERIA FALSA

Como ya se vio anteriormente, el protocolo RIP implementa ‘Triggered Update’. Esta técnica consiste en enviar actualizaciones inmediatamente después de sufrir un cambio de rutas. En el caso que nos ocupa en el ejemplo anterior, cuando el ordenador B sufre un cambio de sus rutas informará a sus vecinos de dichos cambios:

Fig. 25

49

Como el protocolo también implementa horizonte dividido solo enviara la actualización a su ordenador vecino C. Las rutas que cambiaron en el ordenador B eran las rutas con destinación a la red 4.0.0.0, a la red 5.0.0.0, y a la red 6.0.0.0. Con la actualización enviada, C recibirá estas tres rutas nuevas con métrica 2. Antes de la actualización C tenía la siguiente tabla de encaminamiento:


El ordenador C compara sus rutas almacenadas con las rutas recibidas en

la actualización, y realiza los cambios cuando encuentra una ruta mejor:


Como era de esperar el ordenador C ha cambiado su ruta a la red 6.0.0.0

puesto que el ordenador B le ofrecía una alternativa mejor, aunque falsa, ya que esta información ha sido transmitida mediante el ataque iniciado por la entidad controlada A. En este caso se provoca una denegación de servicio entre el ordenador C y la red 6.0.0.0. El resto de rutas no se han visto afectadas, ya que el ordenador B no puede ofrecer una ruta mejor al ordenador atacado C.

Con este ejemplo, se puede concluir que los mensajes falsos enviados por una entidad controlada dentro de un sistema RIP se extenderán por la red y pueden provocar cambios en las rutas y por tanto denegación del servicio, siempre y cuando la ruta que ofrece el vecino sea mejor que la ruta que tiene almacenada el ordenador atacado en cada caso.

3.5 PROVOCAR CANCELACIÓN DE RUTAS

Como se vio anteriormente en la definición del protocolo, el proceso de cancelación de una ruta se puede dar en los siguientes casos: - No se recibe actualización de una ruta y esta caduca - Se recibe una actualización de la ruta con métrica 16.

50

Si se recibe un vector de distancia cuyas rutas tienen métrica 16 se inicia el proceso de cancelación de las rutas, y estas no son utilizadas por la tabla de encaminamiento hasta que se consiga una ruta alternativa. Retómese el ejemplo de la Fig. 23. La tabla de encaminamiento de B seria:


Supóngase que el ordenador controlado A envía un vector cuyas rutas

tienen métrica 16 al ordenador B:

0 7 8 15 16 31 02 VERSIÓN (1) 0 (2)

2 0 (2) 1.0.0.0 0 (4) 0 (4) 16

2 0 (2) 2.0.0.0 0 (4) 0 (4) 16

2 0 (2) 3.0.0.0 0 (4) 0 (4) 16

2 0 (2) 4.0.0.0 0 (4) 0 (4) 16

2 0 (2) 5.0.0.0 0 (4) 0 (4)

1 2 0 (2)

6.0.0.0 0 (4) 0 (4) 16

Debido a este vector, el ordenador B iniciaría el proceso de cancelación de las rutas:

51


Por tanto las rutas desaparecen de la tabla de encaminamiento hasta que se encuentra una alternativa. Se ha provocado una denegación de servicio entre el ordenador B y las redes 3.0.0.0, 4.0.0.0, 5.0.0.0 y 6.0.0.0.

Se puede ver, que enviando vectores con métrica 16 es posible provocar una denegación de servicio entre un vecino y una red, siempre y cuando la red no este directamente conectada a este vecino.

La expansión de la mensajería falsa sería similar a la descrita en el apartado anterior.

3.6 PERSISTENCIA

Hasta el momento se ha visto que es posible realizar una denegación de servicio enviando mensajería falsa, y provocando la actualización de las tablas de encaminamiento de nuestros vecinos.

No obstante, para conservar la denegación de servicio es necesario enviar

mensajes falsos periódicamente. Esto es así, ya que en RIP las rutas tienen una caducidad. Por tanto, para conservar la denegación de servicio, la entidad controlada dentro del sistema RIP debe enviar mensajeria falsa periodicamente.

52

4. DESARROLLO

4.1 INTRODUCCION

Tomando como punto de partida la estrategia de ataque definida en el

bloque anterior, ha llegado la hora de implementar una aplicación que ayude a demostrar la base teórica de la estrategia de ataque, y provoque una denegación de servicio en una red RIP.

Como lenguaje de programación se ha escogido Java. Para ello se ha instalado un kit de desarrollo y el programa IDE NetBeans como apoyo. El kit de desarrollo java utilizado es el ‘JAVA 2 SDK’ en su versión 1.3.1. Java 2 SDK incluye herramientas útiles para desarrollar y probar programas escritos en el lenguaje de programación Java y que se ejecutan en la plataforma Java. Estas herramientas están diseñadas para que se utilicen desde la línea de comandos. Para desarrollar de una manera más cómoda se ha utilizado el programa Netbeans. NetBeans es una plataforma para el desarrollo de aplicaciones usando Java y un Entorno integrado de desarrollo (IDE) desarrollado por la Plataforma NetBeans.

Para simplificar la implementación se ha considerado que la entidad controlada dentro del sistema RIP tiene una única interfaz. Esto es así porque se entiende que la entidad controlada será un ordenador personal.

La aplicación dispone, por una parte, de una interfaz gráfica donde se informa de los eventos y de los posibles errores, y por otra parte, la lógica que trata los datagramas o paquetes de datos RIP que se reciben y se envían a la red atacada. Recuérdese que el protocolo RIP utiliza el puerto UDP 520. Por lo tanto, para recibir y enviar datagramas se utilizan ‘sockets’ UDP configurados en el puerto 520. Este puerto es posible que este ocupado por alguna otra aplicación a la hora de ejecutar la aplicación. Si es así, se debe ‘matar’ el proceso para dejar libre el puerto 520.

4.2 ANÁLISIS FUNCIONAL En este apartado se describen los aspectos funcionales que reúne la aplicación de ataque al protocolo RIP. Infraestructura Técnica: La aplicación de ataque al protocolo RIP esta programada íntegramente en JAVA. Definición funcional: La aplicación debe provocar una denegación de servicio enviando mensajería RIP falsa de forma persistente. Las entradas a la aplicación serán la versión RIP utilizada (RIPv1 o RIPv2) y la métrica falsa utilizada (métrica 1 o métrica 16). El programa mostrará los resultados que va obteniendo del ataque por pantalla.

53

RIPv1 / RIPv2: Según la versión escogida por el usuario, la forma de enviar los datagramas cambia. En el caso de RIP versión 1, se utilizará la dirección broadcast. En cambio, si se utiliza RIP versión 2, se utilizará la dirección multicast (224.0.0.9). Por otra parte se debe tener en cuenta el formato de los mensajes descritos en la definición del protocolo según la versión escogida. Interfaz gráfica: La interfaz gráfica es el mecanismo que se utiliza para interactuar con el usuario de la aplicación. Consta de dos botones: Uno para iniciar el ataque: ‘Conectar’ y otro para pararlo: ‘Stop’. Además el usuario puede escoger que tipo de ataque quiere realizar: vectores con métrica 1, o vectores con métrica 16, y si la red a la que quiere atacar utiliza RIPv1 o RIPv2. También dispone de una pantalla donde se informa de los eventos que se suceden en el transcurso del ataque o posibles errores que puedan ocasionarse.

La elección de la versión RIP, así como el tipo de ataque que se desea realizar se escogen mediante listas desplegables.

Fig. 26

Es posible realizar cualquier tipo de configuración:

Ataque Métrica 0 Ataque Métrica 16 RIP1 RIP1 + Ataque Métrica 1 RIP1 + Ataque Métrica 16 RIP2 RIP2 + Ataque Métrica 1 RIP2 + Ataque Métrica 16

En la pantalla se informa, mediante mensajes, de todos los eventos que se produzcan a lo largo del ataque. En todos los mensajes se incluye la hora. La pantalla también sirve para informar de posibles fallos o errores y que opciones tiene el usuario para solventarlos.

A continuación se muestra un esquema de la interacción entre el usuario y la aplicación:

54

Fig. 27

El programa finaliza cuando se produce un error o cuando el usuario presiona el botón ‘Stop’. Diagrama funcional de actividades: El usuario indica los parámetros de entrada e inicia el ataque. La aplicación hace una petición de la tabla de encaminamiento según el parámetro de entrada V (versión RIP). Cuando la aplicación obtiene la tabla de encaminamiento, informa al usuario por pantalla del estado de la red. Acto seguido envía la mensajería falsa dependiendo de los parámetros de entrada V (versión RIP) y M (Métrica).

A continuación se muestra un esquema de la interacción entre el usuario, la aplicación y la red RIP atacada.

55

Fig. 28

Este esquema representa un ciclo de ejecución. Esto quiere decir que la petición de la tabla de encaminamiento y el ataque se hará indefinidamente hasta que se pare la ejecución de la aplicación, ya sea debido a un error o a la finalización manual por parte del usuario. Excepciones controladas: Se controlan las excepciones que puedan surgir informando al usuario a través de la pantalla de la interfaz gráfica. Las excepciones pueden ser de formato RIP, de red, de código...

Una excepción, implicará la parada automática del proceso de ataque y por tanto de la ejecución del programa, dando la posibilidad al usuario de iniciar un nuevo ataque cuando lo desee. Riesgos: Se pueden encontrar problemas de comunicación con el router vecino, ocasionados por: - Problemas a nivel de IP.

- Problemas de sincronismo al enviar y recibir datagramas.

4.3 ANÁLISIS TÉCNICO En este apartado se describen los aspectos técnicos que debe reunir la aplicación de ataque al protocolo RIP.

56

Classes JAVA: La aplicación consta de tres classes bien diferenciadas. La primera clase, ‘atac.class’, se trata de la clase principal. Se encarga de la interfaz gráfica y la gestión del hilo de ejecución del ataque. ‘recibirUDP.class’, se encarga de la comunicación en red mediante sockets UDP. Además en esta clase se implementarán las actividades del ataque. ‘entrada.class’, se trata de una clase que almacena de forma ordenada las datos de una entrada RIP. La clase ‘atac.class’, contiene además una lista o vector de ‘entradas’.

57

Diagrama técnico de actividades:

Fig. 29

58

Excepciones controladas: Los errores más comunes en la aplicación, o mejor dicho las excepciones, son las de comunicación. Todas las excepciones se controlan con try – catch en el código Java. En caso de producirse excepciones se procede siempre de la misma manera: - Se reporta el mensaje de error a la pantalla de la interfaz gráfica. - Se para el hilo de ejecución del ataque RIP.

Para hacerlo más inteligible, no se muestran los mensajes de error que reporta Java, sino que se controla para mostrar por pantalla un mensaje más claro, para que el usuario lo entienda. Sin embargo, si un error no se ha tenido en cuenta, se mostrará el mensaje de error que proporciona Java. A continuación se enumeran las excepciones java que se controlan: SocketException: Exception Java Mensaje mostrado Address already in use: Cannot bind

Socket: El puerto 520 lo esta usando otra aplicación, ciérrela para poder iniciar el ataque

No route to host: Datagram send failed

Socket: No se ha podido enviar la petición. Revise las conexiones de red

socket closed Socket: Socket cerrado IOException Exception Java Mensaje mostrado Receive timed out E/S: Los vecinos no están

contestando a la petición RIP

4.4 PRUEBAS

Un plan de pruebas es necesario para demostrar el correcto funcionamiento de la aplicación. Se definen tres entornos de pruebas: - ST (SystemTest): Abarca el proceso de desarrollo y programación de la aplicación. Se ha comprobado la compilación del programa y el buen funcionamiento a nivel local. - IT (Integración): Abarca la comunicación del programa con la red. Se han hecho pruebas de comunicación con un router. - PR (Producción): Se ha escogido un caso real para probar el ataque.

59

4.4.1 PRUEBAS ST

Las pruebas ST, consisten en comprobar el buen funcionamiento del código de la aplicación a nivel local. Estas pruebas se reducen a que el código compile correctamente, y se comporte según lo descrito en el análisis funcional y análisis técnico. Se han realizado las siguientes comprobaciones: - Botones de ‘conectar’ y ‘stop’: Se ha comprobado que se inicie el hilo de ejecución al hacer clic a ‘conectar’, y que finalice al hacer clic en ‘stop’. - Desplegables: Se ha comprobado que se recoge la versión y el tipo de ataque de forma correcta, desde la interfaz gráfica. - Formato mensajes: Se ha comprobado que los mensajes que salen por la pantalla tengan el formato deseado, en especial, los retornos de carro y la hora que se produjo el evento. - Datagramas: Se ha comprobado que la confección de los datagramas sea la correcta, para prevenir posibles errores en las pruebas IT.

4.4.2 PRUEBAS IT

Las pruebas IT, consisten en comprobar la correcta comunicación entre la entidad controlada y el router vecino, verificando que se están realizando las actividades esperadas.

Para ello es necesario disponer de un router que disponga de RIP, tanto la versión 1 como la versión 2. En este caso, se ha utilizado un ordenador Linux del laboratorio, instalando la aplicación routed.

Routed es una implementación en código libre del protocolo RIP. En los ordenadores de laboratorio no viene instalado por defecto en el SO Linux. Pero no es difícil de conseguir e instalar. Para la instalación se realizan los siguientes pasos:

./configure –with-c-compiler=cc make make install Una vez instalado se ubica en "/usr/sbin". Ejecutarlo es tan fácil como:

/usr/sbin/routed

Una vez el ordenador esta configurado para que utilice RIP, enviará un

mensaje de actualización de sus tablas de encaminamiento cada 30 segundos. Lo podemos comprobar mediante un análisis con el programa Wireshark.

60

Fig. 30

El programa Wireshark es un analizador de protocolos utilizado para realizar análisis y solucionar problemas en redes de comunicaciones para desarrollo de software y protocolos, y como una herramienta didáctica para educación. Cuenta con todas las características estándar de un analizador de protocolos.

Como otros analizadores de protocolos, Wireshark soporta la utilización de filtros. En este caso, para capturar solo el tráfico del protocolo RIP se ha utilizado el siguiente filtro:

- udp port 520

Con este filtro solo se captura el tráfico UDP que venga del puerto 520, el utilizado por el protocolo RIP.

Para comprobar el buen funcionamiento del programa se han testeado los siguientes temas: - Comprobar que se envía el datagrama de petición de la tabla de encaminamiento y se recibe una respuesta correcta por parte del router. - Comprobar el formateo de la tabla de encaminamiento, y la correcta inserción en la lista de entradas. - Comprobar el buen funcionamiento del programa en la confección de los datagramas de ataque, prestando atención en la versión y el tipo de ataque que se debe realizar en cada caso. - Comprobar que los datagramas falsos de ataque se envían correctamente.

Para realizar las pruebas se han utilizado trazas en el código, para mostrar por consola las actividades que se realizaban, y se ha utilizado el programa Wireshark para ver la comunicación entre la entidad controlada que ejecuta la aplicación y el router.

61

4.4.3 PRUEBAS PR Se ha configurado una red de pruebas:

Fig. 31

Se trata de una topología de red constituido por 5 ordenadores. La entidad controlada es un portátil con sistema operativo windowsXP, que tiene instalado el programa de ataque. Todos los ordenadores tienen sistema operativo linux, con tres interfaces de red, y el demonio routed instalado. En este caso solo necesitaremos 2 interfaces de red para los ordenadores A, B y C, y una interfaz para el ordenador D.

Con esta topología se consigue la entidad atacada A obtenga mediante aprendizaje dinámico de rutas una ruta de métrica 2, la ruta a la red 192.168.4.0. Esto es útil para realizar pruebas con mensajes falsos de métrica 1 desde la entidad controlada.

Se han asignado direcciones IP en las interfaces de red de cada ordenador respetando la singularidad en cada red. De esta forma, en la red 192.168.3.0, el ordenador B tiene la dirección 192.168.3.1 asignada en su interfaz, y el ordenador C tiene la dirección 192.168.3.2. Para configurar cada ordenador se ha utilizado la siguiente metodología: #Deshabilitamos las interfaces que se están utilizando ifconfig eth2 down #Habilitamos la redirección de paquetes echo 1 > /proc/sys/net/ipv4/ip_forward #Configuramos las interfaces ifconfig eth0 192.168.1.2 up ifconfig eth1 192.168.2.1 up

62

Esto es un guión de ejemplo para el ordenador A. Se ha configurado de forma similar el resto de ordenadores.

Para configurar el portátil, la entidad controlada, se le ha asignado la IP 192.168.1.1 desde el panel de control de windows.

Antes de arrancar routed la tabla de encaminamiento de A tenia la siguiente pinta: Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 192.168.2.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1

La tabla de encaminamiento de B: Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 192.168.3.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 192.168.2.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1 La tabla de encaminamiento de C: Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 192.168.4.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 192.168.3.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1

La tabla de encaminamiento de D: Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 192.168.4.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1

Se arranca routed y se obtiene lo siguiente en el ordenador A: Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 192.168.4.0 192.168.2.2 255.255.255.0 UG 2 0 0 eth0 192.168.3.0 192.168.2.2 255.255.255.0 UG 1 0 0 eth0 192.168.2.0 192.168.2.1 255.255.255.0 UG 0 0 0 eth0 192.168.2.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 192.168.1.0 192.168.1.2 255.255.255.0 UG 0 0 0 eth1 192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1

En el ordenador B: Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 192.168.4.0 192.168.3.2 255.255.255.0 UG 1 0 0 eth0 192.168.3.0 192.168.3.1 255.255.255.0 UG 0 0 0 eth0 192.168.3.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 192.168.2.0 192.168.2.2 255.255.255.0 UG 0 0 0 eth1 192.168.2.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1 192.168.1.0 192.168.2.1 255.255.255.0 UG 1 0 0 eth1 En el ordenador C: Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 192.168.4.0 192.168.4.1 255.255.255.0 UG 0 0 0 eth0 192.168.4.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 192.168.3.0 192.168.3.2 255.255.255.0 UG 0 0 0 eth1 192.168.3.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1 192.168.2.0 192.168.3.1 255.255.255.0 UG 1 0 0 eth1

63

192.168.1.0 192.168.3.1 255.255.255.0 UG 2 0 0 eth1 En el ordenador D: Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 192.168.4.0 192.168.4.2 255.255.255.0 UG 0 0 0 eth1 192.168.4.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1 192.168.3.0 192.168.4.1 255.255.255.0 UG 1 0 0 eth1 192.168.2.0 192.168.4.1 255.255.255.0 UG 2 0 0 eth1 192.168.1.0 192.168.4.1 255.255.255.0 UG 3 0 0 eth1

Se observa que se han aprendido rutas nuevas vía RIP. Además, en el

ordenador A se ha obtenido una ruta con métrica 2.

Iniciamos el ataque utilizando mensajes falsos con métrica 1. Se observa lo siguiente en la tabla de encaminamiento del ordenador A: Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 192.168.4.0 192.168.1.1 255.255.255.0 UG 1 0 0 eth1 192.168.3.0 192.168.2.2 255.255.255.0 UG 1 0 0 eth0 192.168.2.0 192.168.2.1 255.255.255.0 UG 0 0 0 eth0 192.168.2.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 192.168.1.0 192.168.1.2 255.255.255.0 UG 0 0 0 eth1 192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1

La ruta con métrica 2 ha sido atacada. Ahora cada vez que A se quiera comunicar con la red 192.168.4.0 enviara los paquetes hacia nuestra entidad controlada. Según este experimento se puede afirmar que la estrategia de ataque enviando mensajes falsos con métrica 1 es efectiva para atacar rutas con métricas igual o mayor de 2.

El ataque tiene que ser persistente. Si no lo fuera el ordenador A vuelve a tomar la ruta correcta.

Una posible aplicación, aparte de denegar el servicio, con este tipo de ataque es poder ‘escuchar’ datos de una red que en cualquier otro caso no tenemos acceso. Según este caso se puede capturar el tráfico que el ordenador A envía a la red 192.168.4.0, y luego redireccionar los paquetes otra vez a su destinación real.

Iniciamos el ataque enviando mensajes con métrica 16. Obtenemos lo siguiente: Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 192.168.2.0 192.168.2.1 255.255.255.0 UG 0 0 0 eth0 192.168.2.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 192.168.1.0 192.168.1.2 255.255.255.0 UG 0 0 0 eth1 192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1

Se observa que las rutas que se aprendieron vía RIP han desaparecido de la tabla de encaminamiento. Han sido añadidas en el proceso de cancelación y ya no se usan para encaminar.

64

5. CONCLUSIONES

Tras realizar las pruebas, se puede observar que el protocolo RIP es

vulnerable tanto utilizando el ataque de métrica 16 como utilizando el ataque de métrica 1.

No obstante, en las pruebas se han configurado los routers para que utilice

RIP en todas las redes que tiene directamente conectadas. Esto, en un caso real no seria necesario. Retomemos el caso de pruebas:

Fig. 32

El protocolo RIP participa en todas las interfaces. Pero se puede ver que en la interfaz Ethernet, que conecta con la red donde se encuentra la entidad controlada no sería necesario configurar RIP. Esto es así porque no hay ningún router que le pueda interesar la información que envía RIP. Además, en el caso que el administrador de la red le interesase que la red Ethernet utilizará RIP, puede configurarlo de forma pasiva, de esta forma los mensajes de respuesta que reciba el ordenador A por esa interfaz son rechazados directamente.

Por lo tanto, se puede concluir que RIP, aunque es vulnerable, es útil en

un entorno de confianza, y hay que prestar especial atención a la hora de configurarlo y no utilizarlo en las interfaces donde no haga falta.

6. RECURSOS UTILIZADOS

Para desarrollar el presente proyecto se han utilizado diferentes tipos de recursos. Por una parte, se ha hecho uso de recursos bibliográficos para la documentación sobre el protocolo RIP. Para ello se han consultado los RFCs (Request For Comments) número 1058 y 2453. Internet también ha sido en diversas ocasiones una fuente de inspiración.

65

En cuanto a los programas empleados, se ha utilizado el kit de desarrollo java SDK 1.3.1_13. Además se ha utilizado el IDE NetBeans. Por otro lado, ha sido de mucha utilidad la aplicación Wireshark, para el estudio de los datagramas UDP RIP. También ha sido de gran apoyo la aplicación cports, para matar puertos cuando ha sido necesario.

Para las pruebas de Integración y Producción, se ha utilizado cuatro PC’s

con Linux, un portátil con Windows XP y el programa ‘routed’. El programa routed, es una implementación del protocolo RIP en código abierto.

66

7. MANUAL 7.1 INTRODUCCIÓN

Este documento recoge la guía de usuario de la aplicación Java de ataque al protocolo de encaminamiento RIP.

Mediante esta herramienta, el usuario puede realizar un ataque a una red

conmutada que utilice RIP como protocolo de encaminamiento, desde un ordenador conectado a dicha red.

7.2 REQUISITOS

Para al ejecución correcta de la aplicación se debe disponer de la máquina virtual java instalada en el ordenador que vaya a realizar el ataque. Además se debe disponer de acceso a la red atacada.

7.3 CARACTERÍSTICAS

La principal característica de la aplicación de ataque al protocolo RIP, es la capacidad para realizar un ataque de red sin necesidad de tener conocimientos técnicos del protocolo, simplemente utilizando una sencilla interfaz gráfica. El ataque es posible en cualquier topología de red, desde un ordenador conectado a la red.

Además la aplicación soporta tanto RIP en su versión 1, como la versión

2. El tipo de ataque que se consigue es una denegación de servicio en la red, y es posible realizarlo siguiendo dos estrategias diferentes.

67

7.4 DESCRIPCIÓN DE LA APLICACIÓN

Elementos de la aplicación:

Fig. 33

1.- Conectar: Mediante este botón iniciamos un ataque 2.- Stop: Mediante este botón paramos un ataque 3.- Selección de versión: Selección de la versión del protocolo RIP que utiliza la red que queremos atacar. RIP1: Selección de la versión 1 del protocolo RIP RIP2: Selección de la versión 2 del protocolo RIP 4.- Selección de tipo de ataque: Selección del tipo de ataque que deseamos realizar.

- Ataque métrica 16: La aplicación enviará mensajes falsos con el campo métrica 16. - Ataque métrica 1: La aplicación enviará mensajes falsos con el campo métrica 1.

5.- Pantalla: Se muestra mediante mensajes el proceso del ataque y los mensajes de error.

Inicio del ataque:

Para iniciar un ataque presionar el botón conectar. Se mostrará por pantalla el siguiente mensaje:

68

Fig. 34

-Intentando crear Socket UDP 520...: La aplicación intenta iniciar una conexión por el puerto 520, utilizado por el protocolo RIP.

-Versión escogida: Se muestra la versión que se ha escogido.

-Ataque escogido: Se muestra el tipo de ataque escogido.

-Socket creado con éxito: Indica que la aplicación ha conseguido iniciar la conexión.

-Ejecutando rutina: Petición de tabla de encaminamiento: La aplicación envía un mensaje RIP solicitando al router la tabla de encaminamiento. El formato del mensaje dependerá de la versión escogida antes de conectar.

Fig. 35

69

- Datagrama request enviado: Informa de que el datagrama de petición de la tabla de encaminamiento ha sido enviada con éxito.

- Datagrama recibido: Informa de que el router ha contestado y se ha recibido la tabla de encaminamiento con éxito.

- Red RIP: Tabla de encaminamiento recibida: Informa de que se ha recibido una tabla de encaminamiento con el formato correcto.

- Entrada aprendida: x.x.x.x – Métrica: x: Indica que una nueva ruta ha sido aprendida, especificando la dirección IP y la métrica.

- Ejecutando rutina: Enviar datagrama falso: Envío de un datagrama falso. Con las rutas aprendidas se construye un datagrama falso según el tipo de ataque y la versión RIP escogida, para ser enviado a la red atacada.

- Datagrama falso enviado: Indica que el datagrama falso ha sido enviado con éxito.

7.5 MENSAJES DE ERROR

Mensaje Descripción Socket: El puerto 520 lo esta usando otra aplicación, ciérrela para poder iniciar el ataque

El programa no se puede ejecutar porque el puerto 520, que utiliza RIP, esta ocupado por otra aplicación.

Socket: No se ha podido enviar la petición. Revise las conexiones de red.

Se ha producido un problema de comunicación con la red.

Socket: Socket cerrado El socket se ha cerrado. Normalmente cuando se clica en el botón stop.

E/S: Los vecinos no están contestando a la petición RIP

Si los vecinos tardan más de 30 segundos en contestar una petición

Error comando: No se ha recibido un datagrama response

Si se recibe un datagrama que no es de respuesta.

Error versión: La red no es compatible con RIP1

La red que se esta intentando atacar no utiliza RIP1

Error versión: La red no es compatible con RIP2

La red que se esta intentando atacar no utiliza RIP2

Documents

Ataque Protocolo RIP