7.4 Travail préparatoire aux simulations dans NS-2
7.4.2 Extension de NS-2 par une implémentation du protocole
tocole d’authentification
La difficulté essentielle dans la simulation de notre protocole d’authentifica- tion réside dans le fait qu’un JN doit attendre un certain nombre de réponses avant de lancer les messages de la deuxième phase. Ce comportement est, à notre connaissance, inexistant parmi les protocoles implémentés dans les simu- lateurs de réseaux. Pour cette raison, une première aventure d’implémentation avec OTCL en simulant les messages d’authentification par des messages UDP était difficile à mener jusqu’au bout.
Nous avons donc opté pour une implémentation en C++ au cœur de NS-2. Ce choix s’est avéré salutaire notamment en raison de la richesse de la biblio- thèque de classes lorsqu’il a fallu manipuler des temporisateurs et lorsqu’il a fallu distinguer les traitements des données d’authentification d’autres types de traitements. De plus, dans les fichiers de traces, il a ainsi été possible de marquer les messages d’authentification.
7.4.2.1 Cahier des charges et simplification
Il s’agit de développer le protocole d’authentification au niveau application. Selon le modèle en couches de protocoles (cf. section 2.2.3 du chapitre 2), les messages de cette application doivent pouvoir être traités par la couche de trans- port. A des fins de simplification et d’efficacité, nous avons choisi de la baser sur le protocole UDP. En effet, il nécessite moins de signalisation que TCP, qua- lité appréciable dans les MANETs. De plus, les cas de défaillances du protocole d’authentification sont déjà pris en charge grâce à l’algorithme à multiples ten- tatives, donc la possibilité de retransmission de paquets offerte par TCP n’est pas forcément utile.
D’autre part, comme le traitement des messages d’authentification prend un temps supposé négligeable (cf. tableau 6.2 et section 6.4.1 du chapitre 6), la couche application peut faire abstraction du détail du contenu de ces messages. Il lui suffit alors de connaître la taille des messages et l’ordre dans lequel ils doivent être envoyés. Elle doit aussi être capable de construire l’en-tête des messages qu’elle émettra à la couche de transport et de les traiter lorsqu’elle en recevra en provenance celle-ci . Enfin, elle doit manipuler des temporisateurs pour le lancement de nouvelles tentatives ou le renouvellement de l’authentification en cas d’expiration du jeton d’accès.
La couche de transport doit pouvoir distinguer un message d’authentification qui arrive ou qui doit être émis de tout autre type de message. Elle doit donc savoir analyser l’en-tête d’un message d’authentification. Elle doit, par ailleurs, segmenter et reconstituer un message en fonction de sa taille.
Enfin, la différence de comportements entre un client et un pair, au sens Dist-AAA (cf. sections 4.3 et 4 du chapitre 4.4), doit être considérée.
7.4 Travail préparatoire aux simulations dans NS-2 169 7.4.2.2 Création de nouvelles classes
Développer une telle application n’est pas une tâche simple car cela nécessite d’intervenir à divers niveaux de la hiérarchie de classes [133] de NS-2. Certaines directives peuvent, d’ailleurs, être consultées sur [144].
Hiérarchie de classes de NS-2 Process Application AAAClient AAAServer Agent UdpAgent UdpAAAagent
Figure 7.3 – Nouvelles sous-hiérarchies dans la hiérarchie de classe de NS-2 Nous appelons cette application AAAClient au niveau d’un client et AAA- Serverau niveau d’un pair AAA. Après examen de la hiérarchie de classes, nous avons décidé d’implémenter AAAClient et AAAServer comme deux classes dé- rivées de la classe Application. Afin que la couche transport soit compatible avec cette nouvelle application, nous avons dérivé une classe appelée UdpAAAagent de la classe UdpAgent. Deux nouvelles sous-hiérarchies ont été donc créées comme illustré, à titre indicatif, par la figure 7.3. On voit qu’elles ne sont pas issues des mêmes parents.
D’autres classes supplémentaires ont été définies pour refléter ces nouvelles sous-hiérarchies, le nouvel en-tête et les temporisateurs dans la hiérarchie symé- trique OTCL.
Afin que ces modifications de l’architecture de NS-2 soient prises en compte lors de l’installation, les fichiers objets relatifs à ce module ont été déclarés dans le fichier Makefile.in.
7.4.2.3 En-tête AAA et numéro de séquence
Un en-tête AAA, appelé hdraaa, a été défini dans la classe UdpAAAagent qui est aussi manipulé par les classes AAAClient AAAServer. Il s’agit d’une structure contenant le numéro de séquence du message AAA d’authentification envoyé, sa taille en octets et la date de son émission ou de sa réception. Afin qu’il soit connu dans NS-2, il a ajouté dans la pile de formats d’en-têtes définie dans le fichier "ns-packet.tcl".
Lorsqu’un client rejoint le réseau MANET, il ne s’est pas encore authentifié. Ses premiers messages d’authentification auront comme numéro de séquence 0. A chaque nouvelle étape, ce numéro est incrémenté de un. La valeur du numéro de séquence d’un message d’authentification se trouve alors définie ainsi :
– 0 mod 4 : si le message est envoyé par un JN à un pair AAA lors de la première étape d’une tentative d’authentification,
– 1 mod 4 : si le message est envoyé par un pair AAA lors de la deuxième étape de cette tentative en réponse à la demande du JN,
– 2 mod 4 : si le message est envoyé par le JN au pair AAA lors de la troisième étape de la tentative,
– 3 mod 4 : si le message est envoyé par le pair AAA lors de la quatrième étape de la tentative en réponse au message du JN émis à la troisième étape.
De plus, tous les messages envoyés lors d’une même étape, que ce soit par le JN ou par les pairs AAA, ont le même numéro de séquence.
L’incrémentation en continu des numéros de séquence sans retour à 0 permet de distinguer, plus tard, dans les fichiers de traces, les différentes tentatives d’authentification pour chaque client.
7.4.2.4 Classe UdpAAAagent
Cette classe étend la classe UdpAgent pour le support de l’application AAA. Pour cela, nous avons ajouté à sa classe mère, Agent (cf. Figure 7.3), les prototypes des méthodes : supportAAA() et enableAAA() définies dans Ud- pAAAagent. Ainsi, les fonctions suivantes sont devenues opérationnelles :
– envoi des données reçues de l’application AAA, que ce soit de la classe AAAClient ou de la classe AAAServer, après avoir mis en forme l’en-tête AAA et ajouté les ports et les adresses IP de la source et de la destination. – réception des données destinées à l’application AAA.
– segmentation ou assemblage des données si nécessaire.
La spécification des ports et des adresses IP permet à la classe AAAClient d’identifier les différents pairs AAA puisqu’une étape du protocole d’authentifi- cation implique plusieurs d’entre eux et non un seul.
7.4.2.5 Classe AAAClient
A travers le script maître de la figure 7.2 de la section 7.4.1, la classe du client prend en entrée les valeurs des variables : n, thM, thi, th, K, tmaxet T, la durée d’expiration d’un jeton (cf. tableau 7.5). Ces dernières doivent avoir été définies, auparavant, avec leurs valeurs par défaut, dans le fichier ns-default.tcl. AAAClient définit un certain nombre de méthodes permettant d’initialiser le client lorsqu’il arrive dans le réseau, de l’arrêter lorsqu’il part, de lancer une authentification, d’envoyer un message ou un ensemble de messages destinés à plusieurs pairs, de recevoir un message, de planifier la prochaine tentative d’authentification en cas d’échec et le prochain processus d’authentification à l’expiration du jeton, de compter le nombre de messages arrivés au cours d’une étape, d’initialiser ce nombre lorsque cette étape est terminée, de choisir les pairs à contacter, etc. Deux possibilités ont été prévues pour le choix des pairs à contacter lors de la première étape d’une authentification à un instant donné :
1. thM pairs les plus proches du JN
2. thM sélectionné aléatoirement parmi les n pairs
A la troisième étapes, les pairs contactés sont les thi qui ont été les plus réactifs c.-à-d. ceux qui ont répondu les premiers.
7.4 Travail préparatoire aux simulations dans NS-2 171
Modèle Nom Paramètres
protocole de transport UDP
protocole applicatif AAA d’authentification n, thM, thi, th, K, tmax, T, pairs AAA choisis parmi les plus proches, pairs choisis aléatoire- ment
Tableau 7.5 – Protocoles et paramètres associés (suite)
Envoi de messages Une trace de l’événement de lancement d’une nouvelle tentative est enregistrée dans un fichier de traces particulier, appelé authTraces.tr, que nous avons spécifié pour les seuls événements se rapportant aux authentifi- cations des clients. Les informations enregistrées incluent l’identifiant du client et la date de lancement récupérée par l’appel de l’ordonnanceur.
L’envoi des messages utilise deux types de temporisateurs :
– timeout : un temporisateur d’expiration de la durée maximale d’attente tmax, définie dans l’algorithme à tentatives multiples. Avant d’être pro- grammé, la classe AAAClient vérifie que le nombre de tentatives maximal K n’a pas été atteint.
– new_auth : un temporisateur d’expiration de la durée de validité du jeton. Réception de messages Le client n’effectue pas les même opérations selon qu’il est à la deuxième ou à la quatrième étape :
– à la 2e : les messages réponses des pairs sont reçus un à un de la classe
UdpAAAagent. Ils sont comptés et les identifiants des pairs, numérotés de 0 à n − 1, sont au fur et à mesure enregistrés dans un tableau. Ainsi les pairs se trouvent classés par ordre de réactivité. Lorsque leur nombre atteint thi, AAAClient lance la 3eétape.
– à la 4e : de la même manière, les réponses sont comptées. Lorsque leur
nombre atteint th, la tentative est considérée comme réussie et l’événement est enregistré dans le fichier authTraces.tr.
Numéro de séquence interne Un client tient un numéro de séquence, seq_, interne afin de savoir à tout moment où il en est dans le processus d’authentifi- cation. C’est la valeur de ce numéro qu’il copie dans ses messages.
La figure 7.4 montre l’évolution de la valeur de seq_ en fonction des événe- ments :
– au départ, quand le client arrive, son numéro de séquence seq_ est égal à 0. C’est la valeur qu’il copie dans les messages envoyés à la première étape.
– une fois ces messages émis, seq_ est incrémenté. Plus tard, lorsque les réponses des pairs arriveront, la valeur des numéros de séquence qu’elles contiennent est comparée à celle de seq_.
– seq_ garde la valeur 1 tant que le nombre de réponses n’a pas atteint thi. Si le temporisateur timeout expire, la valeur de seq_ revient à 0 et la ten- tative est abandonnée. Toute réponse ultérieure est supprimée silencieu- sement. Un enregistrement dans le fichier authTraces.tr note l’identifiant
0
envoi de thM messages à thM pairs
AAA réponses de thpairs AAA i envoi de thpairs les plus réactifsi messages aux thi
réponses de moins de thi pairs AAA
réponses de moins de th pairs AAA
réponses de th pairs AAA ou expiration de timeout expiration
de timeout
1 2 3
Figure 7.4 – Diagramme d’état du numéro de séquence interne de AAAClient
du client, la date à laquelle il a abandonné la tentative, l’étape à laquelle la tentative a été abandonnée et le nombre de réponses qui ont été reçues jusque là.
– si le nombre de réponses atteint thi, seq_ est incrémentée (seq_=2). Le client lance la 3eétape en émettant th
i messages vers les pairs qui étaient les plus rapides à répondre.
– une fois ces messages émis, seq_ est incrémenté à nouveau (seq_=3). Plus tard, lorsque les réponses des pairs arriveront, la valeur des numéros de séquence qu’elles contiennent est comparée à celle de seq_.
– seq_ garde la valeur 3 tant que le nombre de réponses n’a pas atteint th. Si le temporisateur timeout expire, la valeur de seq_ revient à 0 et la ten- tative est abandonnée. Toute réponse ultérieure est supprimée silencieu- sement. Un enregistrement dans le fichier authTraces.tr note l’identifiant du client, la date à laquelle il a abandonné la tentative, l’étape à laquelle la tentative a été abandonnée et le nombre de réponses qui ont été reçues jusque là.
– si le nombre de réponses atteint thi, seq_ est incrémentée. Sa valeur mo- dulo 4 vaut donc 0. C’est pourquoi une flèche allant vers 0 a été dessinée sur la figure 7.4. L’événement de réussite de la tentative est enregistré dans le fichier authTraces.tr comme décrit ci-dessus. Le client ne lancera plus de nouvelle tentative. Il est, en revanche, prêt à lancer un nouveau processus d’authentification dès que le temporisateur aura expiré new_auth. Il est à remarquer qu’ainsi définies, les valeurs prises par seq_ ne cessent en réalité de croître. Les valeurs affichées dans les cercles sur la figure 7.4 sont en fait les valeurs de seq_ modulo 4. Ce choix a été opéré afin de pouvoir plus tard distinguer les différentes tentatives dans le fichier authTraces.tr grâce au numéro de séquence.
7.5 Scénarios de simulations et résultats 173