Rsum

Lvaluation et la mise en vidence de notre protocole se droule en

deux tapes. Tout dabord, notre protocole est vrifi formellement afin de
montrer quil rponde aux proprits de scurit spcifies. Ensuite, les
performances de ce protocole sont tudies et discutes.

1. Validation formelle de notre protocole

Avant tout dploiement, un protocole doit tre valid pour vrifier,
dune part, quil a bien le comportement voulu par les spcifications, et
dautre part quil respecte bien les proprits de scurit attendues.
Plusieurs outils de validation formelle de protocoles cryptographiques
existent. Nous avons choisi loutil AVISPA (Automated Validation of
Internet Security Protocols and Applications) car il est automatique et
assez expressive (permet de vrifier plusieurs proprits de scurit
comme par exemple lauthentification, le secret, la robustesse contre
certaines attaques). De plus, il permet dutiliser diffrentes techniques
de vrification sur une mme spcification de protocole.
AVISPA fournit un langage formel modulaire et expressif appel High
Level Protocol Specification Language (HLPSL) permettant de dcrire les
protocoles et spcifier les proprits de scurit attendues. HLPSL est un
langage bas sur les rles. Chaque rle est indpendant des autres : un
rle dfinit des actions qui seront excutes par un agent associ et il
reoit des informations initiales entres en paramtres et communique
avec les autres rles via des canaux (channels).
Pour animer les spcifications HLPSL et vrifier quelles correspondent
au protocole, nous avons utilis loutil SPAN.
Donc, nous avons install SPAN dans une machine UBUNTU et rdig
la spcification HLSPL de notre protocole. Cette description est faite dans
un fichier qui a pour extension .hlpsl et qui fera lobjet dune traduction
laide du traducteur laide dun traducteur HLPSL2IF afin de gnrer un
fichier

.if

(ltape

de

traduction

se

fait

automatiquement

i.e.

transparente pour lutilisateur). Ensuite, les diffrents outils de vrification

appels back-ends utilisent ce format pour vrifier le protocole spcifi.
Tous les back-ends ont trouv notre protocole scuris.

Figure 1 Lanimation SPAN du mcanisme de protection didentit

entre UE et P-CSCF

Figure 2 Rsultat d'analyse du mcanisme de protection d'identit

entre UE et P-CSFC

Figure 3 Animation SPAN de l'authentification mutuelle

Figure 4 Rsultat d'analyse du mcanisme d'authentification

En effet, les proprits de scurits que nous avons spcifi sont
lauthentification mutuelle, la confidentialit des cls, protection contre le
rejeu et MITM

2. Analyse des performances

Lide de lanalyse des performances consiste utiliser un Benchmark. Ce
dernier doit permettre de mesurer le comportement du rseau IMS quand un
nombre croissant d'utilisateurs exigent d'tre enregistrs peu prs au mme
moment.
Le benchmark choisit pour notre cas se compose :
-

Dun systme de test (Test System), qui simule un grand nombre d'UE 1
effectuant lenregistrement
Dun systme tester (System Under Test), qui ragit l'gard des
demandes denregistrement effectues par les utilisateurs du systme de
test

A. Technologies utilises :
1. Open IMS Core le systme testerCest une implmentation open source permettant de simuler larchitecture IMS.
Elle est compos de 3 serveurs de contrle (P-CSCF , I-CSCF , S-CSCF) et un
serveur de base de donnes (FHoSS)

2. IMS Bench SIPp le systme de testCest un gnrateur de trafic open source pour le protocole SIP, conue pour
mesurer les performances dun rseau IMS. Il se compose de 3 parties :
-Manager: contrle tout le droulement du benchmark en communiquant avec
les 2 autres composants.
-SIPp: Il se dispose dun nombre (x) dutilisateurs qui gnrent le trafic SIP
-System monitoring (CpuMem): collecte les informations sur la charge du CPU
et la consommation de mmoire
Il est noter quIMS Bench SIPp permet de gnrer un rapport dexcution aprs
la fin du benchmark. Ce rapport contient les diffrentes mesures collectes et
leurs reprsentations graphiques (des courbes).

1 User equipement

B. Dploiement
Par limitation de ressources notre plateforme dessai est compose dun seul
hte hbergeant cinq rles. Le systme dexploitation utilis est Ubuntu 14.04 :
Hostname
Ubuntu 14.04

CPU

RAM

Rle
System under
test
manager
System
monotoring
SIPp
DNS2

Technologies
Open IMS
Core
IMS Bench
SIPp
Bind9

1. La configuration
Tel que mentionn ci-dessus tous les serveurs ont t dploy sur une seule
machine par consquent ils vont tous avoir 127.0.0.1 comme adresse IP. Les
ports sur lesquels ils vont recevoir le trafic sont rsums dans le tableau suivant :
Serveur
P-CSCF
I-CSCF
S-CSCF
FHoSS
I-CSCF
S-CSCF
Manager

Port
4060
5060
6060
3868
3869
3870
5000

Trafic reu
TCP/UDP

DIAMETER
TCP

Dautre part, FHoSS a t remplie par 2000 abonns afin davoir suffisamment
dutilisateurs disponibles.

C. Etapes et mthodologie de travail

Afin daboutir une valuation comparatives des performances nous avons trac
les grandes tapes suivantes :
2 Utilis pour dtermin le nom du domain : open-ims.test.

Etape 1 : Tester les performances en utilisant le protocole IMS-AKA comme

protocole denregistrement : puisque Open IMS Core et IMS Bench SIPp
implmentent tous les deux ce protocole nous avons qu lancer ce test en
simulant par exemple le lancement de 2000 enregistrements au mme temps et
voir les rsultats.
Etape 2 : Tester les performances en utilisant le protocole IMS-AKA+ comme
protocole denregistrement : beaucoup de changements doivent tre fait au
niveau de cette tape, nous citons les suivants :
-

Dfinir le format des messages SIP: prciser les champs ajouter ou

supprimer afin de construire un message SIP dans le cadre du protocole
IMS-AKA+.
Dfinir notre base de donnes (FHoSS) : en effet beaucoup
dinformations ne seront plus utiles dans le cadre de notre protocole
notamment (les numros de squence, AMF.). Ainsi les tables et les
champs de la nouvelle base de donnes doivent tre dfinis. De plus, les
diffrentes fonctions interrogeant la base de donnes doivent tre
rajustes.
Les serveurs CSCF : implmenter les diffrents messages SIP modifis au
niveau de chaque module (P-CSCF, I-CSCF, S-CSCF) afin quils supportent
le protocole IMS-AKA+
IMS Bench SIPp : implmenter les diffrents messages SIP modifis au
niveau dIMS BenchSIPp afin quil supporte le protocole IMS-AKA+
lancer le test en simulant par exemple le lancement de 2000
enregistrements au mme temps et comparer les rsultats avec ceux de
ltape 1.

D. Etat davancement et problmes rencontrs

1. Nous somme au niveau de ltape 1 o nous avons rencontr un problme
technique. En effet en lanant le test nous avons remarqus que les
messages (REGISTER, 401 Unautorized et le 2eme REGISTER) sont bien
transmises mais le 200 OK nest pas envoy. Ceci mne ce que
lenregistrement choue et donc limpossibilit davoir des rsultats fiable
et exacte. Ce problme nous coute jusqu prsent plus de 13 jours sans
pouvoir le rsoudre. Nous avons install un client IMS (MyMonster) afin de
rduire lenregistrement un seul client et donc pouvoir contourner le
problme. Nous avons remarqu que cest exactement le mme problme
le 200 OK nest pas reu et au lieu de cela un message 600 Busy everywhere
- Forwarding to S-CSCF failed est envoy. Peu de suggestions sur le web sont
proposes concernant cette erreur !
2. Le deuxime problme est la complexit du code Open IMS core : daprs
la lecture du code dOpen IMS Core il parait que le code source est un peu
complexe (beaucoup de fichiers et de fonctions) et donc dfinir
exhaustivement les fichiers modifier afin quOpen IMS core supporte le
nouveau protocole SIP reste une tache un peu fastidieuse.