L’échange entre les serveurs CM Voisins

Afin de sécuriser le transfert de données entre les serveurs CM voisins, il faut garantir deux points essentiels d’abord le chiffrement des données et ensuite la vérification des

Figure 4.5 – Sécurisation de la communication entre les Serveurs CM voisins

identités des deux serveurs.

D’une part, pour assurer le chiffrement des données on peut utiliser le mécanisme OTP (One Time Password) [42]et également le mécanisme PGP (Pretty Good Privacy) [32].

D’autre part, puisqu’un protocole de transfert en clair n’est pas un moyen sûr et sécurisé pour éviter tout risque d’attaques, même au sein d’un canal crypté, alors FTP ou une synchronisation simple ne présentent pas une solution efficace. En effet, l’identité des deux serveurs CM peut être vérifiée à l’aide d’un simple serveur AAA placé dans AS2 et le transfert peut être sécurisé à l’aide d’un simple protocole SCP ou FTP via SSL.

La figure 4.5 résume la solution adoptée pour sécuriser la communication entre les serveurs CM voisins.

La solution proposée se déroule selon le processus suivant :

1. Le serveur CM1 cherche à se connecter au serveur CM2.

2. Le processus Handshake de SSL est exécuté pour authentifier les deux extrémités.

3. Le canal sécurisé est établi et les informations d’identification (Nom d’utilisateur/mot

de passe) sont envoyées au serveur CM2.

4. Le flux d’authentification AAA commence.

5. L’authentification est réussie et l’autorisation de transfert est envoyée au serveur

CM2.

6. et 7. Le transfert des données du serveur CM1 vers le serveur CM2 commence.

4.4 Conclusion

proposé afin de gérer la QoS dans un réseau inter-domaines. Cette proposition a donné lieu a une publication à « The Inernational Conference on NETworked Systems (NETYS) 2013, Springer’s LNCS 7853 » [10]. Notre nouveau mécanisme se base essentiellement sur l’implémentation d’un serveur nommé Serveur CM qui est chargé de collecter les infor- mations sur la QoS offertes aux différents trafics clients pour partager par la suite ces informations avec les AS voisins, de cette façon on peut garantir une certaine continuité des privilèges QoS garantis aux trafics clients dans son AS d’origine même au passage vers l’AS voisin. Nous avons alors présenté les différentes étapes nécessaires pour le fonctionne- ment de notre mécanisme, à savoir, la table CT et sa constitution, les messages échangés entre les serveurs CM voisins et leurs formats. En outre, nous avons relevé quelques vulné- rabilités concernant la sécurité du mécanisme QoS-CMS, et nous avons également proposé les solutions qui peuvent remédier à ces problèmes et assurer la sécurité des communica- tions dans notre mécanisme. Ceci a donné lieu a une publication à « First International Conference, C2SI 2015, Springer’s LNCS 9084 » [13].

L’objectif du chapitre suivant est d’évaluer les performances de notre nouveau méca- nisme à travers des études de cas par simulation. Ces études nous permettrons de prouver l’efficacité et l’amélioration des conditions d’acheminement des trafics en termes de QoS après l’implémentation de notre approche.

Simulation du mécanisme QoS-CMS

5.1 Introduction

Après avoir présenté dans le chapitre précèdent le nouveau mécanisme QoS-CMS, que nous avons proposé pour la gestion de QoS en inter-domaines, l’objectif de ce chapitre est d’évaluer ses performances. Nous rappelons que le mécanisme QoS-CMS se base sur l’introduction dans chaque AS du serveur CM qui va permettre aux différents domaines d’échanger les informations relatives à la QoS offerte à leurs trafics. Ainsi, dans nos si- mulations nous allons comparer à chaque fois deux scénarios le premier représente le cas d’un réseau usuel où nous n’avons aucun échange entre les différents ASs, et le deuxième représente l’implémentation du nouveau mécanisme en intégrant dans le même réseau les serveurs CM chargés des échanges QoS entre les ASs. On note que dans toutes nos simu- lations nous avons choisi d’implémenter le modèle DiffServ pour la QoS intra-domaine. A l’aide du simulateur ns2 , nous allons simuler différentes topologies, varier différents para- mètres, et mesurer l’impact de cette variation sur les performances du réseau en termes de délai et de taux de pertes. La comparaison des résultats obtenus pour les deux scénarios permet d’apprécier l’impact de notre mécanisme sur l’amélioration de la QoS. Dans ce cadre, nous avons effectué plusieurs études de cas. Le but de la première étude de cas était d’étudier la faisabilité de notre mécanisme et d’observer les premiers résultats avec une to- pologie simple, ceci a donné lieu à une publication dans la 18ème édition de « International Conference on Systems Science (ICSS 2013), Springer ’s Advances in Intelligent Systems and Computing 240 » [11]. Après les premiers résultats qui étaient encourageants, nous avons effectué d’autres études de cas plus approfondies avec des topologies plus dévelop- pées. Dans la deuxième étude nous avons mesuré les variations des performances réseau en fonction du temps , dans la troisième nous avons relevé l’impact de la variation des paramètres de QoS, et dans la dernière étude nous avons mesuré l’impact de la variation du nombre d’ASs.

Dans ce chapitre, nous allons présenter et décrire les topologies et les configurations de ces études de cas ainsi que les résultats que nous avons obtenus.

Figure 5.1 – La topologie de l’étude n° 1