Proposition de solution pour ARIADNE contre l’attaque Wormhole

Rappel sur les insuffisances de ARIADNE

Comme nous l’avons remarqué, ARIADNE ne résiste point à l’attaque du trou de ver. Ainsi des études ont montré que la seule solution pour que ce protocole empêche cette attaque, est la mise en place d’une politique de synchronisation très précise des horloges dans TESLA.
Pour rappel, le mécanisme de synchronisation utilisé par TESLA est le suivant :
• Le récepteur envoie (sync, tr) au temps tr ;
• L’expéditeur répond à la demande avec son temps de réception ts (sync, tr, ts) ;
• Le récepteur, avec son temps courant tR, évalue la limite supérieure le temps de l’expéditeur courant comme suit : ts ≤ tR -tr + ∆

Avec ∆ l’erreur maximale (réelle) du temps de synchronisation.

Les bases de la solution proposée

La solution proposée se base sur le concept de packet leashes qui n’est rien d’autre qu’un mécanisme permettant de contrer l’attaque du trou de ver. Ce mécanisme peut être utilisé par tout protocole de routage sécurisé en vue de se protéger contre le wormhole. Cependant, l’idée s’inspire de l’approche temporelle (temporal leashes) qui se résume en deux phases qui sont :

Implémentation de la solution dans NS

Notre plus grand problème dans ce travail résidait sur comment intégrer les protocoles sécurisés ARIADNE, SEAD, ARAN dans NS2 pour effectuer la simulation.
Comme nous le savons bien, les seuls protocoles implémentés dans ns-allinone sont les protocoles qui n’ont aucun mécanisme de sécurité à l’image de DSR, DSDV, TORA, AODV.
Le travail a pu être effectif grâce à une extension découverte dans le site de Rice Monarch Project Software Distributions (http://www.monarch.cs.cmu.edu/software.html).
Cette extension permet de simuler les protocoles ARIADNE et SEAD. Après téléchargement du patch nommé ariadne-sead.tgz qui est un fichier zippé, il faudra déziper suivant les instructions se trouvant de le fichier README. Pour déziper, la commande tar zxvf ariadne-sead.tgz a été utilisée. Ainsi on voit deux répertoires nommés dsr et dsdv. Dans ces répertoires se trouvent respectivement les fichiers hdr_sr.h, dsragent.h, dsragent.cc, teslacache.cc et le fichier dsdv.cc. En fait, à l’exception de fichier teslacache.cc, tous les autres existaient déjà dans les répertoires dsr et dsdv qui se trouvent dans ns-2.29. Mais il faudra les remplacer avec les nouveaux fichiers du patch.
Après avoir mis ces fichiers dans les répertoires dsr et dsdv qui ont pour chemin d’accès (/home/taphakane/ns-allinone-2.29/ns-2.29). Il faut faire une recompilation de ns-allinone2.29 en faisant à nouveau un (./install).
Cette nouvelle opération signalera des erreurs causées par l’intégration de ces nouveaux fichiers. Donc il faudra suivre les messages d’erreurs et essayer d’entrer dans les fichiers et corriger au fur et à mesure. Ceci demande une bonne connaissance du langage C++, car des modifications devront se faire au niveau des codes sources.
De même, l’implémentation de cette variante d’ARIADNE, n’a pas été très facile dans la mesure où les mêmes problèmes que précédemment seront rencontrés. Certains fichiers de configuration de TESLA seront modifiés afin de changer l’ancienne version de la synchronisation pour une adaptation à la solution proposée.

Tests et validation

Afin de tester et de valider notre travail, nous avons procédé à une simulation de la proposition qui est une variante de ARIADNE. Cette simulation a été effectuée avec nsallinone-2.29.
Ensuite nous avons effectué une étude de performance pour pouvoir valider ce travail. Les aspects de performance évalués dans le cadre de ce travail sont principalement : la fraction de paquets délivrés, le délai des paquets transmis de bout en bout, et la charge normale de routage.

Les mesures de performance

Trois mesures de performance ont été évaluées durant notre étude :
• La fraction de paquets délivrés : est le rapport des paquets de données livrés aux destinations par rapport à ceux produits par les sources comme suit : fraction de paquets délivrés (pdf %) = (Nbrpreçus / Nbrpenvoyés) *100 ;
• Délai des paquets transférés de bout en bout : Ceci donne le temps moyen que doit prendre les paquets de transfert de la source à la destination. Il peut être basé sur les paquets de routage (exécution du protocole) ou le paquet de données (efficacité du protocole de routage) ;
• Charge normale de routage : le nombre de paquets de routage transmis par paquet de données livré à la destination comme suit : charge normale de routage = (paquets de routage envoyés) / Nbrpenvoyés.
Ces mesures sont importantes pour les trafics de type best-effort14 car elles permettent l’évaluation de la capacité des protocoles de routage. Cependant, il faut noter que ces trois métriques de performances ne sont complètement indépendantes.

Modèle de simulation avec ns-allinone-2.29

Effectuer une simulation dans ns2 est assez difficile et exige beaucoup de connaissances et de travaux. Des difficultés ont été rencontrées au cours de l’installation au niveau de l’inscription du code de simulation. De même obtenir des résultats utiles était plus compliqué. En effet, l’élément clé d’un réseau radio [37] est l’objet « Mobilenode » constitué de composantes comme le Link Layer (LL), Interface Queue (IfQ), MAC layer. Pour compléter le scénario il faut en outre, définir le type d’antenne employée, le type de modèle de propagation voulu, le type de protocole routage ad hoc employé par les terminaux mobiles.
Un réseau radio possède aussi un objet appelé « God » (General Operation Director) [36, 37], unique pour chaque simulation. Il s’agit d’un objet qui mémorise toutes les informations inhérentes de l’état du réseau et des nœuds et est inconnu pour tous les participants de la simulation. Tous ces paramètres ont été pris en compte dans le script de simulation comme illustré dans le tableau 4 suivant :

Le script de simulation

Ecrire un code de simulation pour un réseau mobile ad hoc avec NS2 nécessite une définition de plusieurs paramètres à savoir : les types des composants réseaux, le type des antennes utilisées, le protocole de routage à étudier, le modèle de trafic dans le réseau, le modèle de mouvement utilisé par les nœuds etc. Le code pour ce document est visible au niveau de l’annexe. L’exécution de ce script de simulation génère deux fichiers à savoir le fichier trace et le fichier nam [36] (voir annexe).
Cependant avec ce fichier trace [36, 37], l’évaluation de performance n’a pas été un rude travail dans la mesure où nous avons écrit un programme java (voir annexe) qui permet de parcourir toutes les lignes (voir annexe) depuis le début pour calculer le nombre de paquets envoyés (Nbrpenvoyés), le nombre de paquets reçus (Nbrpreçus), nombre de paquets perdus (Nbrpperdus) et le nombre de paquets de routage envoyés et reçus, les délais etc. Ces données calculées permettront l’évaluation des différents critères de performance à savoir:

Résultats et discussion

L’exécution de notre programme java a permis de récupérer les valeurs inscrites dans les tableaux (voir annexe) qui suivent et de tracer les courbes de variation des critères de performance relatés ci dessus en fonction du nombre de nœuds malicieux.

La fraction de paquets délivrés

Les courbes de variation pour la fraction de paquets délivrés sont visibles sur la figure 7 cidessous.
Le graphe nous montre que ARIADNE délivre moins de paquets que sa variante avec une augmentation de 19.14 % au fur et à mesure que le nombre de nœuds malicieux augmente. Ceci est la conséquence de la synchronisation des horloges dans TESLA qui en plus d’avoir apporté une protection contre l’attaque Wormhole, résiste aussi à plusieurs autres attaques à l’image de blackhole, d’où une diminution considérable des pertes de paquets.
Les résultats montrent que la charge normale est beaucoup plus grande avec ARIADNE qu’avec la variante. Ce qui était prévisible dans la mesure où l’attaque du trou de ver augmente le nombre de paquets à router avec un nombre de nœuds malicieux considérable. En fait, avec la synchronisation précise des horloges, les nœuds malicieux vont voir leurs activités anéanties. Ainsi les fonctions réseaux vont finalement être identiques à celles avec le protocole ARIADNE.

Le délai de bout en bout

Nous avons les courbes de variation du délai de bout en bout illustrées par la figure ci-dessous.
On note ici qu’au niveau de la variante de ARIADNE, le délai est plus considérable du fait que certaines opérations de calcul sont ajoutées, en l’occurrence le calcul du temps d’expiration au niveau de la synchronisation. Cependant, il apparaît assez clairement que la solution reste gourmande en ressources. L’utilisation d’un mécanisme de synchronisation est coûteuse dans la mesure où elle nécessite plus de 10% de la charge CPU. Bien que conscient que toute sécurité à un prix, qu’elle se fait au détriment par exemple de la qualité de service, il serait intéressant de faire une étude plus approfondie sur cette contribution puis des simulations afin d’évaluer à quel point cette solution perd en performance pour pouvoir ainsi déterminer si en pratique elle est viable.