un réseau multi sauts
Avant de déployer le réseau multi sauts, nous avons étudié le comportement des pseudonymes dynamiques dans une topologie étoile. Tous les nœuds du WSN à l’exception du 6BR implémentent MT6D.
Le réseau multi sauts de la Figure 7.2 a ensuite été déployé. Dans cette configuration, quand le premier changement de pseudonyme apparait, les communications s’arrêtent.
Plusieurs constats ont pu être dressés par l’analyse du fichier mémorisant les trames brutes envoyées au niveau du 6BR. La trame DIO programmée après la création des pseudonymes est émise correctement. Le nouveau pseudonyme associé est bien ajouté à la table des voisins du récepteur du DIO. En revanche, la trame DAO est émise mais n’atteint jamais l’adresse destination du prochain saut. La table de routage n’est alors jamais mise à jour avec les nouvelles adresses.
Lors d’une association classique, un nœud choisi l’émetteur du premier DIO reçu comme parent préféré. L’OF de RPL défini néanmoins un protocole pour changer de parent préféré. RPL étant un protocole conser-vateur, il essaie de garder un maximum de chemins déjà établis afin de réduire la consommation inutile. C’est pourquoi, quand un nouveau nœud apparait, il ne peut prétendre devenir le parent préféré d’un nœud déjà associé que s’il revendique une métrique radio meilleure que celle de son parent actuel. En d’autre terme, seul un nœud possédant un rang plus faible pourra prétendre prendre la place du parent préféré. Ce problème est un problème connu de RPL. Dans la fonction de création des pseudonymes de MT6D, nous avons opté pour un comportement similaire à celui de RPL. Nous avons donc choisi l’adresse du destinataire du DAO comme l’adresse du parent préféré. Or, lors de la reconstruction de DODAG quand un nœud reçoit une trame DIO envoyée par un nouveau pseudonyme, il possède déjà une adresse enregistrée comme parent préféré. Cette adresse correspond à l’adresse réelle du parent préféré utilisée pendant la première association. Le réseau déployé est un réseau simulé. La couche radio est parfaite et ses métriques sont indisponibles. Contiki simule alors une valeur équivalente pour tous les nœuds en mode natif. Dans un réseau statique, le parent préféré n’est donc jamais mis à jour. Quand les pseudonymes sont changés, l’adresse de ce parent préféré n’est donc plus valable et le processus de routage est cassé. Ce problème vient de notre environnement de simulation. Afin de remédier à cela et de permettre l’utilisation du simulateur pour analyser les comportements des différentes contre mesures de dissimulation des identifiants, différentes solutions ont été testées.
Tout d’abord, nous avons tenté de changer l’adresse destination du DAO. En effet, dans l’implémentation de [115], l’adresse destination est l’adresse réelle du 6BR et lors du déploiement du réseau en topologie étoile, il n’y a pas eu de problèmes. Un chemin est bien ajouté à la table de routage du 6BR quand il reçoit un DAO.
La table du 6BR grossie à chaque nouveau pseudonyme créé. Nous avons donc tenté d’envoyer un DAO à chaque parent et pas seulement au parent préféré. Nous avons observé que les DAO étaient bien reçus par les nœuds one-hop et que leur table de routage est bien mise à jour. Il existe maintenant bien une route pour atteindre le nœud pour des communications du père vers le fils. Néanmoins, comme le mode par défaut de
Contiki est le mode storing, le DAO doit être transféré jusqu’au nœud root. Par exemple, dans la Figure 7.2, si le nœud "C" implémente notre nouvelle approche, le DAO qu’il émettra avec son nouveau pseudonyme sera bien reçu par le nœud "B". "B" va alors ajouter une route pour atteindre "C" via son nouveau pseudonyme. Dans un fonctionnement en mode storing de RPL, ce DAO doit ensuite être envoyé à "A" pour que celui-ci ajoute une route indiquant que pour atteindre "C" il faut passer par "B". Lors de ce processus, comme le DAO ne concerne pas le nœud lui-même mais un de ses enfants, RPL utilise le parent préféré comme adresse du prochain saut. Dans ce cas, la solution ne marche plus et le DAO n’est pas transmis jusqu’au 6BR. En effet, avec cette solution, "B" garde toujours l’ancienne adresse de "A" comme adresse de son parent préféré. Or "A" ne s’identifie plus avec cette adresse et va donc filtrer la trame. De même, lors de communications du fils vers le père (par exemple, si "B" veut communiquer avec "D"), le nœud ne connait pas la route et va utiliser la route par défaut pour atteindre la destination et va donc envoyer à son parent préféré. Cette solution présente l’inconvénient d’introduire un surcoût de trames DAO proportionnel au nombre de parents de chaque nœud.
La deuxième approche envisagée consiste à modifier les valeurs par défaut de RPL ou d’utiliser des fonctions propres à ce processus. Malheureusement, les solutions utilisées permettent la mise à jour du DODAG mais pas du parent préféré. Nous avons également essayé de procéder à une réparation locale, protocole prévu par RPL mais cette fonction invalide le parent préféré sans le supprimer. Si bien que le DODAG se reconstruit en utilisant l’adresse du parent préféré initial.
Finalement, afin d’empêcher ce comportement, nous forçons les nœuds à mettre à jour leur parent préféré en supprimant tous les parents choisis par un nœud après le changement de pseudonymes. Cette solution n’apporte pas de surcoût de trames, ni n’introduit de modifications indésirables des tables. De cette façon, le comportement naturel de RPL est préservé, les nœuds peuvent choisir leur parent préféré pendant la mise à jour du DODAG. Seule une étape supplémentaire est ajoutée à l’implémentation de [115] sans introduire de modification du comportement prévu. Nous avons donc pu valider le comportement décrit dans [115]. Une autre solution pourrait être d’enrichir la simulation en autorisant la modulation des métriques radios. Pour cela, il serait intéressant d’utiliser le modèle de couche radio fourni par WSNET à la place de notre couche posix radio.
Le deuxième problème dû à l’implémentation concerne également RPL et son fonctionnement par défaut dans Contiki et va impacter les performances de MT6D. Dans un déploiement réel, lorsque un nœud apparait, disparait ou est en mouvement, les routes sont mises à jour de manières différentes.
Quand un nouveau nœud rejoint le réseau, une nouvelle entrée le concernant est ajoutée dans la table de routage de tous les nœuds concernés. Ainsi, dans la Figure 7.2, "B" en rejoignant le réseau a ajouté une route le concernant dans la table de routage de "A" et du 6BR. En revanche, si un nœud venait à se déplacer ou disparaitre, les nœuds qui avaient un chemin par lui reconstruisent un nouveau chemin à travers un autre parent et les routes seraient mises à jour. Par exemple, si "B" disparait, "C" peut choisir de passer par "A" (si celui-ci est à sa portée). Dans ce cas, le 6BR mettra à jour la route pour atteindre "C" dans sa table de routage.
Dans MT6D, le changement de pseudonymes apparait pour les voisins comme l’ajout d’un nouveau nœud (car nouvelle adresse). La table de routage est donc mise à jour avec chaque nouveau pseudonyme. De plus, conformément à l’implémentation décrite dans l’article [115], la durée de vie du DAO est mise à une valeur infinie. Un élément de la table de routage n’est donc supprimé que si la taille maximale est atteinte. Néanmoins, les auteurs indiquent qu’il est possible de changer cette valeur pour un temps fini. Ainsi, si aucun DAO n’est reçu pendant un certain laps de temps, la route est supprimée de la table de routage. De même, RPL spécifie qu’un nœud peut être supprimé de la table des voisins si aucun DIO n’est reçu de sa part pendant une certaine période. Néanmoins, dans la version par défaut de Contiki, cette caractéristique n’est pas implémentée. Les parents tout comme les routes ne sont donc jamais supprimés. Lors du déploiement de MT6D, à chaque changement de pseudonymes, les tables utiles au routage vont donc grossir. Elles seront totalement reconstruites à chaque changement de pseudonymes même si le réseau n’évolue pas. De nombreuses entrées ne seront plus valables. Lorsque le maximum d’entrées est atteint, les voisins les plus anciens sont supprimés afin de libérer de la place pour les nouveaux. Le même procédé est utilisé sur la table de routage. Le but n’est pas de modifier Contiki ou le fonctionnement de RPL. Le déploiement de MT6D doit pouvoir se faire de manière à être comparé au déploiement d’Ephemeral. Il a donc été choisi de ne pas déployer de solutions pour contrer ce manque dans Contiki. Le comportement des tables de routage pour Ephemeral sera à regarder vis-à-vis de ce problème apporté par MT6D.
Annexe D
Implémentation d’Ephemeral dans
Contiki
D.1 Exemple d’utilisation d’Ephemeral
Figure D.1 – Exemple d’utilisation d’Ephemeral.
Voici un exemple d’un réseau implémentant Ephemeral.
La topologie du WSN est donnée dans la Figure D.1. Lors de l’initialisation, chaque nœud du réseau reçoit la clé secrète Kt utilisée pour générer les pseudonymes. Il reçoit ou génère également son R. Puis, chaque nœud stocke l’adresse MAC aj de ses q voisins ainsi que le Rj correspondant. Pour le nœud 4, cette table comporte 2 entrées alors que pour le nœud 5 seule 1 entrée est présente. La taille maximale de la table est identique à celle de la table des voisins. Cette table enregistre également la valeur du compteur courant cpti,j,t pour chaque communication hop-by-hop. Quand le nœud 4 envoie une trame Ephemeral au nœud 5, il calcule les pseudonymes à utiliser pour les adresses MAC source et destination.
Pour cela, le nœud 4 utilise son matériel de sécurité (cpt4,4,t et R4) mais également le matériel de sécu-rité associé au nœud 5 (cpt4,5,t et R5). Lors de la réception, le nœud 5 déchiffre le pseudonyme destination en utilisant la valeur R5 stockée dans sa table utilisée pour Ephemeral et le compteur cpt4,5,t inclut dans
l’en-tête de la trame. Il regarde alors si la valeur obtenue correspond à son adresse MAC réelle et si la valeur des compteurs ne diffère pas trop de celles qu’il stocke dans sa table. Si tout est bon, il peut alors déchiffrer la trame.
Nous avons donc déployé Ephemeral dans Contiki OS. Contrairement à MT6D, Ephemeral ne remplace pas définitivement l’adresse MAC du nœud par un pseudonyme. Il garde en mémoire la valeur initiale (réelle) de son adresse. La phase de setup reproduite par MT6D à chaque nouveau pseudonyme est donc inutile. Le nœud sera toujours identifié pour le routage par ses adresses réelles. Cet avantage pour la construction et le maintien des tables de routage impacte le bon déroulement de plusieurs protocoles qui utilisent les informations d’adresses pour créer ou parser une trame et donc plusieurs couches du modèle OSI. De plus, de nouvelles structures ont dues être mises en place.
Des choix d’implémentation ont donc dû être faits.