• No se han encontrado resultados

9. Detalles de Implementaci´ on del Esquema de Seguridad Propuesto

9.3. Fortalecimiento de OLSR: Nivel 1

9.3.3. Detecci´ on de Vecinos

El proceso de detecci´on de vecinos ser´a de la misma manera que se realiza en el protocolo original mediante un censado de vecinos. Cuando el nodo se incorpora a la red env´ıa un mensaje de tipo CADISCOVER, cuando los vecinos responden, el nodo actualiza su tabla de enlacess con los vecinos poniendo el estado del enlace como ASYM LINK y tipo de vecino como NOT NEIGH y no confiable. Los nodos que reciben el mensaje CADISCOVER actualizan su tablas de enlaces con los vecinos y agregan al nuevo vecino como no confiable y el estado del enlace como ASYM LINK y tipo de vecino como NOT NEIGH. De esta manera un nodo nunca elegir´ıa al nuevo nodo como

9.3.3. Detecci´on de Vecinos

MPR ya que es condici´on que el nodo tenga un enlace sim´etrico para participar en la elecci´on de MPR.

En el procedimiento de censado de vecinos propuesto se incorpora una modificaci´on m´ınima al procedimiento original. Se agrega un nuevo tipo de vecino a los ya existentes (NOT NEIGH, MPR NEIGH y SYM NEIGH) llamado CA NEIGH. Es decir en un mensaje de HELLO se incorpora un nuevo Link Code donde se indica que ese enlace es con un vecino que es CA, es decir es una extensi´on de la informaci´on enviada en un mensaje HELLO del protocolo original.

Por ejemplo, si un nodo informa que tiene Link Code con tipo de enlace SYM LINK y tipo de vecino MPR NEIGH con un nodo y luego la direcci´on del nodo esta listada con Link Code correspondiente a CA NEIGH, se actualiza la tupla en la tabla de vecinos indicando que el vecino con el cual se tiene ese enlace es CA.

Un nodo puede informar que ´el es CA enviando su direcci´on en el listado de direcciones con Link Code CA NEIGH y cuando un nodo procese este mensaje comparar´a la direcci´on de origen del mensaje y la direcci´on listada como CA NEIGH y actualizar´a la entrada en la tabla de vecinos indicando que el origen del presente mensaje de HELLO es una CA.

No es necesario cambiar la cantidad de bits para representar ese nuevo Link Code ya que en el protocolo original se usan dos bits para representar cuatro tipo de enlaces y dos bits para representar tres tipos de vecinos, con lo cual al agregar un nuevo tipo de vecino se puede representar con los dos bits destinados para este fin.

9.3.3.1. Autenticaci´on de los vecinos

Una vez que el nodo obtiene un certificado, comienza el proceso de autenticaci´on. El nodo en esta etapa ya conoce a sus vecinos los cuales fueron reconocidos en la respuesta al mensaje de HELLO de tipo CADISCOVER. El nodo comienza la autenticaci´on con cada uno de los vecinos de su listado de vecinos.

Para intercambiar los par´ametros de autenticaci´on se utilizan dos nuevos mensaje AUTH MESSAGE (Figura 9.5), AUTH MESSAGE FINISH (Figura 9.6)

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | : Source Cert : | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Random Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | : Signature (160bits) : | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Detalles de Implementaci´on del Esquema de Seguridad Propuesto

Procedimiento de Autenticaci´on Para explicar el proceso de autenticaci´on llamaremos A al nodo que inicia el proceso y B a la otra parte.

1. A genera un paquete que contiene un n´umero al azar (RA), el certificado de A (CertA), los

identificadores de A y B, y un hash encriptado con clave privada de A (firma).

A→ B : A, B, CertA, RA, sign(H(A, B, CertA, RA))

Donde H() es una funci´on hash y sign() es una operaci´on de firma.

2. Cuando B recibe el paquete, primero verifica el certificado de A si corresponde a un cer- tificado firmado por una CA de confianza, luego extrae la clave p´ublica de A y verifica la firma del paquete. Una vez hecho esto, B env´ıa un paquete que contiene un n´umero al azar (RB), el certificado de B, los identificadores del A y B y un hash encriptado con la clave

privada de B (firma).

B → A : B, A, CertB, RB, sign(H(B, A, CertB, RA, RB))

3. Cuando A recibe la respuesta de B, verifica si el certificado de B es v´alido y fue firmado por una CA de la red, verifica la firma. Terminada esta etapa A conf´ıa que B es un vecino seguro y agrega el certificado, en la tabla de vecinos marc´andolo como confiable, actualiza el estado de los enlaces con B como SYM LINK y tipo de vecino SYM NEIGH. A env´ıa un ´ultimo mensaje a B. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | : Signature (160bits) : | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figura 9.6: Formato del mensaje AUTH MESSAGE FINISH

A→ B : A, B, sign(H(A, B, RA, RB))

4. Cuando B recibe la respuesta, confirma que A es un vecino seguro. Actualiza la tabla de vecinos con el certificado de A y marca a A como vecino seguro. Tambi´en actualiza el estado de los enlaces con A como SYM LINK y tipo de vecino SYM NEIGH.

En este punto un nodo malicioso o mal configurado puede enviar miles de mensajes de autenticaci´on seguidos, lo cual puede generar una Denegaci´on de Servicio. En el detalle del pr´oximo nivel de securizaci´on se detallar´a cual es la manera de prevenir este tipo de comportamiento.

Documento similar