Etude et mise en place d'un plateforme IMS Sécurisée

REPUBLIQUE DU SENEGAL

Un peuple un but une foi

Ministère de l’Enseignement Supérieur et de la Recherche

Direction Générale de l’Enseignement Privé

Mémoire de fin de cycle pour l’obtention du master professionnel

Option : Réseaux Télécommunication

Sujet :

Présenté et soutenu par : Sous la direction de :

M. Hermann Orly GBILIMAKO M. Ahmed Youssef Khlil

Expert en Sécurité des SI

Année académique 2014-2015

Etude et mise en place d’une

plateforme IMS sécurisée

i

Rédigé et Présenté par M. Orly Hermann GBILIMAKO

Dédicace

A nos parents Faustin GBILIMAKO, Marie MODOEMONO, Berthe YAKALANGA qui

ont toujours été là pour nous ;

ii


Remerciements Nous tenons à exprimer notre profonde gratitude envers tous les cadres de

l’Institut Supérieur d’Informatique (ISI) qui ont su nous guider pendant tout

notre cursus. Ces remerciements vont à l’endroit de :

Ahmed Youssef notre directeur de mémoire pour son attention et son

apport à la réussite de ce projet ;

M. Lo Massamba pour ses conseils qui ont été très précieux ;

M. Aw Konaté qui a été plus qu’un enseignant pour nous ;

M. Kane pour sa disponibilité et se conseils

Tout le corps professoral d’ISI ;

Nos remerciements vont également à l’endroit de nos parents Faustin

GBILIMAKO, Marie MODOEMONON, Berthe YAKALAGNA ainsi que toute la

famille GBILIMAKO pour leurs conseils et apports financiers.

Tous nos remerciements à tous ceux qui de près ou de loin ont contribués à la

réussite de la rédaction de ce document.

iii


Avant-propos L'Institut Supérieur d'informatique est un institut d'enseignement supérieur

offrant des formations dans des domaines tels que l'informatique, la gestion, la

comptabilité et l'organisation des entreprises. ISI dispose d'un bureau qui

s'occupe des études de conception, d'expérimentation, de réalisation et de

conseil dans différents domaines.

ISI offre plusieurs formations aboutissant aux diplômes suivants :

Diplôme de Technicien Supérieur (DTS) ;

Licence professionnelle ;

Master professionnels ;

Cycle d’Ingénieur (DITI et MIAGE)

Pour l’obtention des diplômes de Master ou Licence, l’étudiant doit si possible

faire un stage à la suite duquel il devra rédiger un mémoire. Les étudiants n’ayant

pas eu de stage, doivent travailler sur des projets de fin d’étude dont les thèmes

doivent être axés sur leur filaire.

C’est dans ce contexte bien précis que nous avons rédigé ce document autour

du thème « Etude et mise en place d’une plateforme IMS sécurisée »

iv


Table des matières Dédicace ......................................................................................................................................................

Remerciements .............................................................................................................................................ii

Avant-propos .............................................................................................................................................. iii

LISTE DES TABLEAUX ............................................................................................................................ vii

LISTE DES FIGURES ................................................................................................................................ viii

LISTE DES ACRONYMES .......................................................................................................................... ix

INTRODUCTION ................................................................................................................................... 1

Partie I : Cadre Général ....................................................................................................................... 2

Chapitre I : Cadre théorique ................................................................................................................... 3

I. Problématique ............................................................................................................................ 3

II. Les objectifs ................................................................................................................................. 4

III. Pertinence du sujet ................................................................................................................. 4

IV. Délimitation du champ d’étude ............................................................................................. 5

Chapitre II : Généralités .......................................................................................................................... 6

I. Généralités sur les réseaux mobiles........................................................................................... 6

I.1.1 Le réseau 2G (GSM/DCS) .................................................................................................... 6

I.1.2 Les réseaux 2G+ (GPRS/EDGE).......................................................................................... 11

I.2 Les réseaux 3G/3G+ ......................................................................................................... 14

I.3 Les réseaux 4G ................................................................................................................. 18

II. Généralités sur la sécurité des systèmes d’information ......................................................... 21

II.1 Les règles de bases de la sécurité des systèmes d’information ............................................ 21

II.2 Notions de base sur la cryptographie .................................................................................... 23

Partie II : Cadre conceptuel ............................................................................................................... 26

Chapitre III : L’IMS ................................................................................................................................. 27

I. Définition et concepts .............................................................................................................. 27

II. Architecture de l’IMS ................................................................................................................ 28

III. Présentation de l’IMS ........................................................................................................... 30

III.1 Les entités fonctionnelles de l’IMS .................................................................................. 30

III.2 Architecture des services de l’IMS .................................................................................. 33

III.3 Profil des abonnés d’un réseau IMS ................................................................................. 35

IV. Les protocoles de communication et les interfaces utilisés par l’IMS ................................ 36

IV.1 Les interfaces .................................................................................................................... 36

IV.2 Les protocoles ................................................................................................................... 37

V. Enregistrement d’un abonné IMS ............................................................................................ 44

v


Chapitre IV : Sécurité au niveau des systèmes VOIP ........................................................................... 47

I. Les attaques sur les systèmes VOIP ......................................................................................... 47

I.1 Attaques sur les protocoles .............................................................................................. 47

I.2 Déni de service (DOS).................................................................................................... 49

II. Sécurisation des systèmes VOIP ............................................................................................... 51

Chapitre V : Etude comparative des solutions ..................................................................................... 54

I. Solutions.................................................................................................................................... 54

I.1 IMS AAA JUNIPER .............................................................................................................. 54

I.2 IMS par Ericsson ................................................................................................................ 55

I.3 OpenIMSCore ........................................................................................................................... 56

II. Etude comparative et Choix de la solution .............................................................................. 57

Partie III : Implémentation ................................................................................................................ 59

Chapitre VI : Mise en place de la solution OpenIMSCore ............................................................. 60

I. Architecture de la plateforme .................................................................................................. 60

II. Diagrammes de fonctionnement ............................................................................................. 61

II.1 Serveur de présence ....................................................................................................... 61

II.2 Serveur de messagerie ...................................................................................................... 62

III. Installation et configuration d’OpenIMSCore ...................................................................... 63

III.1 Les prérequis ..................................................................................................................... 63

III.2 Installation OpenIMSCore ................................................................................................ 64

III.3 Configuration d’openimscore ........................................................................................... 66

Chapitre VII : Mise en place des serveurs d’applications et sécurisation de la plateforme .............. 68

I. Les serveurs d’applications........................................................................................................... 68

I.1 Mise en place du serveur de présence .................................................................................... 68

I.2 Mise en place du serveur de streaming (Annexe3) ......................................................... 69

I.3 Mise en place d’un serveur IPTV ............................................................................................ 69

II. Sécurisation de la plateforme .................................................................................................. 72

II.1 Mise en place de la politique de filtrage .......................................................................... 72

II.1 Mise en place de la sécurité avec TLS .............................................................................. 76

III. Test de fonctionnement des services ................................................................................... 77

III.1 Test d’enregistrement ...................................................................................................... 77

III.2 Test du serveur de présence ............................................................................................. 79

III.3 Test de la messagerie instantanée ........................................................................................ 79

III.4 Test du serveur IPTV ......................................................................................................... 80

Conclusion ............................................................................................................................................. 83

vi


Bibliographie ......................................................................................................................................... 84

Webographie ........................................................................................................................................ 84

ANNEXES ............................................................................................................................................... 85

vii


LISTE DES TABLEAUX

Tableau I.1 Caractéristiques des réseaux 2G…………………………………………………………… 11

Tableau I.2 : Caractéristiques des réseaux 2G+………………………………………………………. 14

Tableau I.3 : Caractéristique des réseaux 4G…………………………………………………………... 21

Tableau I.4 : Les règles de la sécurité des SI……………………………………………………………. 22 Tableau II.1: Méthodes SIP de Base……………………………………………………………………….. 38 Tableau II.2: Méthodes SIP utilisées par IMS………………………………………………………….. 39 Tableau II.3 : Etude comparative des solutions………………………………………………………. 57

viii


LISTE DES FIGURES

Figure I.1.1 : Architecture GSM………………………………………………………………………………. 7 Figure I.1.2 : Architecture des réseaux 2G+……………………………………………………………. 12

Figure I.2 : Architecture de l’UMTS………………………………………………………………………… 16 Figure I.3 : Architecture d’un réseau LTE……………………………………………………………….. 19 Figure I.4.1 : Cryptographie symétrique………………………………………………………………… 23 Figure I.4.2 : Cryptographie Asymétrique……………………………………………………………… 24 Figure I.4.3 : Cryptographie Hybride……………………………………………………………………… 25 Figure II.1.1: Architecture de l’IMS………………………………………………………………………… 29 Figure II.1.2: Architecture des services IMS…………………………………………………………… 34 Figure II.1.3 : Les interfaces de l’IMS…………………………………………………………………….. 36 Figure II.1.4: Les nœuds diameter ………………………………………………………………………… 41 Figure II.1.5: Mécanisme de gestion des erreurs…………………………………………………... 42 Figure II.1.6: Commande de base Diameter………………………………………………………….. 43 Figure II.1.7: Commandes diameter de l’interface Cx……………………………………………. 44 Figure II.1.8: Enregistrement d’un abonné IMS……………………………………………………… 45

Figure II.2.1: Architecture de la solution IMS AAA de JUNIPER………………………………. 55

Figure II.2.2: Architecture OpenIMSCore………………………………………………………………. 56

Figure III.1: Architecture de déploiement……………………………………………………………… 60

Figure III.2: Diagramme de fonctionnement d’un serveur de présence…………………. 61

Figure III.3: Diagramme de fonctionnement de la messagerie ………………………………. 63

ix


LISTE DES ACRONYMES

3GPP : 3rd Generation Partnership Project

AAA: Authorization Authentification Accounting

ADSL: Asymmetric Digital Subscriber Line

AUC: Authentification Center

BTS: Base station

BSC: Base Station Controller

CSCF Call State Control Function

DOS: Deny Of Service

EDGE Enhanced Data rate for GSM Evolution

FDMA: Frequency Division Multiple Access

GPRS: General Packet Radio Service

GSM: Global System for Mobile Communication

GGSN: Gateway GPRS Support Node

HLR: Home Location Register

HSS: Home Subscriber Server

IP: Internet Protocol

IPTV: Internet Protocol Television

ISI: Institut Superieur d’Informatique

I-CSCF Interrogating CSCF

IMS: IP Multimedia Subsystem

ISIM: IMS Subscriber Identity Module

MRFC: Multimedia Resource Function Control

MSC: Mobile Swicthing Center

NGN: Next Generation Network

NSS: Network Subsystem

x


P-CSCF: Proxy CSCF

PCU: Packet Control Unit

RNC: Radio Network Controller

RTCP: Real Time Control Protocol

RTP: Real Time Protocol

RTSP: Real Time Streaming Protocol

SGSN: Serving GPRS Support Node

S-CSCF: Session CSCF

SIP: Session Initiation Protocol

SLF: Subscriber Location Functions

TDMA: Time Division Multiple Acces

UE: User Equipement

UMTS: Universal Mobile Telecommunication Service

VLR: Visitor Location Register

VoD: Video on Demand

1


INTRODUCTION

L’évolution de la technologie et des réseaux mobiles a toujours été influencée

par une forte demande des utilisateurs en applications multimédia (Données et

voix). Les réseaux fixes et mobiles ont connu une évolution majeure ces

dernières décennies afin de satisfaire à ces demandes si fortes des

consommateurs. Du coté des réseaux mobiles, on est passé des réseaux 1G aux

réseaux 4G afin d’avoir un débit de transfert de données considérable. Tandis

que du côté des réseaux fixes, les technologies XDSL permettent d’avoir un

transfert de données à haut débit.

Cependant, l’utilisation explosive d’internet et la convergence technologique qui

s’imposent de nos jours voudraient que tous les services ou applications soient

accessibles à tout utilisateur que ce dernier soit du réseau fixe ou mobile. Mais

les réseaux fixes et mobiles que nous avions énumérés ci-haut ne peuvent pas

répondre à ces besoins car les méthodes d’accès aux réseaux diffèrent. Ce qui

va nous emmener à nous poser les questions suivantes :

Comment faire pour avoir un environnement permettant d’offrir des

services (voix et données) accessibles à partir de n’importe quel

équipement terminal (mobile ou fixe) afin de favoriser la libre

concurrence?

Quelles sont les considérations à prendre en compte pour créer cet

environnement de convergence fixe-mobile?

Comment garantir l’intégrité des données?

Quels seront les impacts sur les architectures existantes?

C’est dans ce contexte bien précis que nous avions opté pour notre projet de fin

d’étude, de mettre en place une plateforme IMS (IP Multimedia Subsystem)

sécurisée, afin de répondre aux questions posées ci-haut et d’approfondir nos

connaissances dans ce domaine qui est celui des télécommunications.

Ainsi dans les lignes qui suivent, nous allons dans un premier temps présenter le

cadre théorique de notre travail qui s’articulera autour de la problématique, des

objectifs du travail et une étude des architectures réseaux existantes; Ensuite

présenter le cadre conceptuel dans lequel nous allons parler de l’IMS et des

techniques utilisées pour sécuriser cette plateforme. Enfin nous passerons à

l’implémentation de la solution.

2


Partie I : Cadre Général

3


Chapitre I : Cadre théorique

Le cadre théorique de ce projet de fin d’étude se détermine par la

problématique, la pertinence du sujet et les objectifs que nous nous sommes

fixés.

I. Problématique

Les réseaux fixes et mobiles ont connu des évolutions importantes afin de faire

face aux demandes si croissantes des utilisateurs en services multimédia. Ces

évolutions se manifestent par différentes techniques qui permettent

l’augmentation du débit du transfert des données, tant du côté des réseaux

mobiles et fixes. Du côté des réseaux mobiles, la 4G permet aujourd’hui de

répondre à ces besoins. Tandis que les technologies XDSL répondent aux besoins

des utilisateurs des réseaux fixes.

Mais les services (multimédia ou voix) développés par chaque réseau (fixe ou

mobile) ne sont accessibles que par des terminaux supportant les méthodes

d’accès de ce réseau. Ce qui ne permet pas aux opérateurs de fructifier

d’avantage leur chiffre d’affaire, vu le profil des abonnés. En d’autre terme, ceci

ne permet la libre concurrence.

Cependant la convergence technologique qui s’impose de nos jours voudrait que

tous les services soient accessibles à tout utilisateur peu importe le type

d’équipement (fixe ou mobile) utilisé et son emplacement. Cette convergence

ouvre la voie à la libre concurrence et permet aux opérateurs de mieux fructifier

leur chiffre d’affaire.

Or les réseaux fixes et mobiles cités ci-haut, ne peuvent pas répondre à ces

besoins de convergence technologiques car les techniques d’accès ne sont pas

identiques.

Ce qui veut dire qu’il faut avoir un environnement dans lequel les services ou

applications seront accessibles sans une contrainte liée aux équipements finaux

afin de favoriser la libre concurrence et la convergence technologique. Cet

environnement doit aussi être sécurisé afin de préserver l’identité des

utilisateurs et le trafic échangé par ces derniers. Vu que les réseaux mobiles et

fixes cités ci-haut ont une bonne qualité de service, leur convergence doit aussi

avoir une bonne qualité de service.

4


II. Les objectifs

Vus les problèmes énumérés ci-haut, l’objectif de notre projet sera de proposer

une solution visant à mettre en place une plate-forme de réseaux de nouvelles

générations (NGN : Next Generation of Network) orienté multimédia (IMS: IP

Multimedia Subsystem) en essayant aussi de gérer l’intégrité des données qui y

circulent. En d’autres termes, l’objectif final est la mise en place d’une plate-

forme IMS sécurisé.

La plate-forme IMS nous permettra d’atteindre les objectifs suivants :

Avoir un réseau réparti en couches, dans le but de faciliter la

maintenance ;

Avoir un réseau multi-accès;

Avoir un environnement ouvert à la concurrence ;

Déployer des services totalement IP (voix et donnés) ;

Favoriser la convergence fixe mobile ;

Favoriser une mutualisation des plates-formes au niveau des opérateurs ;

La mise en place de la sécurité au niveau de la plateforme nous permettra

d’atteindre les objectifs suivants :

Contrôler l’accès à la plate-forme IMS ;

Faire de la traçabilité ;

Assurer l’authentification des utilisateurs ;

Contrôler l’utilisation des services par les utilisateurs suivant leur profil ;

Garantir l’intégrité des données ;

III. Pertinence du sujet

Etant l’un des éléments clés de la convergence des réseaux fixe et mobile, l’IMS

est un sujet d’actualité qui a retenu particulièrement notre attention.

5


En effet, vu sa capacité à se mutualiser avec n’importe quel réseau (informatique

ou télécom), l’IMS permet aux opérateurs de développer des services à valeurs

ajoutées selon les besoins de leurs clients dans le but de fructifier leur chiffre

d’affaire.

Afin de tirer profit des bandes passantes offertes par les réseaux 3G, 4G ou XDSL,

des services tels la VOD (Vidéos à la demande), IPTV (la télévision sur Internet),

télémédecine pour ne citer que ceux-là, peuvent être implémentés par les

opérateurs. Vues les tendances actuelles du marché, ces services permettront

aux opérateurs de faire face à la concurrence car avec l’avènement des outils de

communication sur internet (Skype, Viber …), les revenus concernant les

communications voix ne cessent de baisser.

Fonctionnant sur IP, la sécurité au niveau de l’IMS doit être primordiale afin de

préserver l’identité des utilisateurs et l’intégrité des données circulant sur le

réseau.

IV. Délimitation du champ d’étude

L’objectif principal de cette section est de présenter l’environnement dans

lequel on a effectué notre travail. Mais n’ayant pas trouvé de stage dans une

société de la place, on a travaillé dans un environnement composé des machines

virtuelles et des outils d’émulation et de test. Toutes fois, il est à noter que la

solution présentée un peu plus bas, peut être adaptée aux petites et moyennes

entreprises œuvrant dans le domaine des télécommunications.

6


Chapitre II : Généralités

Dans ce chapitre, nous allons présenter de façon générale les réseaux de

télécommunications et parler des notions de base sur la sécurité des systèmes

d’information.

I. Généralités sur les réseaux mobiles

I.1 Les réseaux 2G/2G+

I.1.1 Le réseau 2G (GSM/DCS)

Global System for Mobile Communications (GSM) est une norme numérique de seconde génération pour la téléphonie mobile. Le groupe de travail chargé de la définir a été établi en 1982 par la Conférence européenne des administrations des postes et télécommunications (CEPT).

Elle a été spécifiée et mise au point par l'ETSI1 (European Telecommunications Standard Institut) pour la gamme de fréquences des 900 MHz. Une variante appelée Digital Communication System (DCS) utilise la gamme des 1 800 MHz. Cette norme est particulièrement utilisée en Europe, en Afrique, au Moyen-Orient et en Asie.

I.1.1.a Architecture du 2G

Le réseau GSM a pour première fonction de permettre des communications entre abonnés mobiles (GSM) et abonnés du réseau téléphonique commuté (réseau fixe). Il se distingue par un accès spécifique qui se fait par le biais des ondes radioélectriques et se compose de trois sous-systèmes à savoir :

Le sous-système BSS (Base Station Sub-system) qui assure et gère les transmissions radio ;

Le sous-système NSS (Network Sub-system) qui comprend l’ensemble des fonctions nécessaire à la gestion des appels et de la mobilité ;

Le sous-système OSS (Operating Sub-system) qui permet d’assurer la maintenance du réseau ;

Cette architecture est résumée par la figure qui suit :

1 Organisme de normalisation européen du domaine des télécommunications.

7


Figure I.1.1 : Architecture GSM

I.1.1.b Les entités du réseau GSM

BTS (Base Transceiver Station)

La BTS est l’un des éléments de base du GSM. Elle est chargée de la liaison radio

avec les stations mobiles et permet de jouer les rôles suivants :

L'activation et la désactivation d'un canal radio ;

Le multiplexage et la gestion des sauts de fréquences ;

Le codage canal, la modulation, démodulation et

décodage du signal radio ; La surveillance des niveaux de champ reçu et de la qualité

des signaux (nécessaire pour le handover) ;

le contrôle de la puissance d'émission (limiter la puissance

à ce qui est suffisant pour ne pas trop perturber les cellules

voisines) ;

La capacité d’une BTS est exprimée en TRX. Un TRX est un émetteur récepteur

qui gère une paire de fréquences porteuses (une en émission et une autre pour

8


la réception).Il peut multiplexer jusqu’à huit communications simultanées grâce

à la technique d’accès multiple TDMA

BSC (Base Station Controller)

La BSC (Contrôleur de Stations de base) permet de commander les stations de

base (BTS). Dans le réseau, la BSC fait office d’interface entre les BTS et le MSC

(Mobile Switch Center). L’interface entre un BSC et un MSC s'appelle interface A,

celle entre un BSC et une BTS s'appelle Abis (lien E1 à 2 Mbit).

La BSC est la partie intelligente du sous-système BSS. C'est lui qui décide de

l'activation ou de la désactivation d'un canal vers une station mobile, de la

puissance d'émission des BTS et des MS (Mobile Station) et qui gère les

changements de cellules (handover intra-BSC), la synchronisation de l'heure des

BTS.

MSC (Mobile Switching Center)

Le MSC est un équipement de téléphonie mobile chargé du routage dans le

réseau, de l'interconnexion avec les autres réseaux (réseau téléphonique fixe par

exemple) et de la coordination des appels. Il traite le trafic voix et signalisation

provenant de plusieurs BSC différents. Les rôles principaux d'un MSC sont :

Le MSC permet de faire de la commutation ;

La gestion des connexions à travers l’activation ou la désactivation

d'un canal vers une station mobile en utilisant les informations du

VLR ;

Le MSC assure la localisation et l'itinérance grâce au VLR ;

La gestion du handover intra-MSC ;

Le HLR (Home Location Register)

Le HLR est la base de données centrale au niveau des réseaux de téléphonie

mobiles. Il comporte les informations relatives à tout abonné autorisé à utiliser

le réseau et notamment sa localisation. Afin que les données soient cohérentes

9


sur l'ensemble du réseau, c'est elle qui sert de référence aux autres bases de

données locales (à l’exemple du VLR).

Le HLR contient d'une part des informations caractérisant l'utilisateur à savoir:

IMSI (International Mobile Subscriber Identity), identifiant unique

de l'utilisateur et qui est stocké dans la carte SIM (connu

uniquement de l’opérateur); L'IMEI définissant la Station Mobile utilisée ; MSISDN (Mobile Subscriber International ISDN Number), indiquant

le numéro d'appel international via lequel l'utilisateur est joignable ; Les services souscrits par l'abonné ;

Il contient d'autre part les informations indiquant la dernière position connue

(localisation) de l’utilisateur :

L'adresse MSRN (Mobile Station Roaming Number) désignant

l'abonné sur un réseau étranger ; Les adresses des MSC et VLR concernés pour avoir à chaque instant

la position approximative de l'abonné mobile;

Le VLR (Visitor Location Register)

Le VLR est une base de données temporaire contenant des informations sur tous

les utilisateurs du réseau, et est parfois intégré dans le MSC. Le VLR contient les

informations suivantes :

TMSI (Temporary Mobile Subscriber Identity), dérivé de l’IMSI ;

MSRN (Mobile Station Roaming Number) ;

LAI (Location Area Identification) ;

L'adresse du MSC ;

L'adresse du HLR ;

10


L’AUC (Authentification Center)

Souvent combiné avec le HLR, l’AUC permet de gérer la sécurité des

communications au sein du réseau. Il permet avec la complicité du HLR de

vérifier l’identité des abonnés en leur demandant de s’authentifier.

I.1.1.c Les caractéristiques d’un réseau 2G (GSM/DCS)

La norme GSM occupe deux bandes de fréquences aux alentours des 900 [MHz]:

la bande de fréquence 890 - 915 [MHz] pour les communications montantes (du mobile vers la station de base) ;

la bande de fréquence 935 - 960 [MHz] pour les communications descendantes (de la station de base vers le mobile) ;

Comme chaque canal fréquentiel utilisé pour une communication a une largeur

de bande de 200 [kHz], cela laisse la place pour 124 canaux fréquentiels à répartir

entre les différents opérateurs. Mais, le nombre d'utilisateurs augmentant, il

s'est avéré nécessaire d'attribuer une bande supplémentaire aux alentours

des 1800 [MHz]. On a donc porté la technologie GSM 900 [MHz] vers une bande

ouverte qui est celle des 1800MHZ avec le DCS (Digital Communication System)

dont les caractéristiques sont quasi identiques au GSM en termes de protocoles

et de service. En émission, la bande de fréquence de 1710-1785 [MHz] est

utilisée et celle de 1805-1880 [MHz] en réception.

Connaissant les différents canaux disponibles, il est alors possible d'effectuer un

multiplexage fréquentiel, appelé Frequency Division Multiple Access (FDMA), en

attribuant un certain nombre de fréquences porteuses par station de base. Mais

avec un tel système, si une source parasite émet un bruit à une fréquence bien

déterminée, le signal qui se trouve dans la bande de fréquence contenant le

parasite sera perturbé. Pour résoudre ce problème, on a combiné le

multiplexage fréquentiel à un multiplexage temporel

(appelé TimeDivision Multiple Access ou TDMA) consistant à diviser chaque

canal de communication en 8 intervalles de temps

Le tableau ci-dessous montre les caractéristiques des réseaux mobiles de deuxième

génération :

11


GSM DCS

Bande de fréquences en

émission

890, 2 - 915 [MHz] 1710-1785 [MHz]

Bande de fréquences en

réception

935, 2 - 960 [MHz] 1805-1880 [MHz]

Nombre d'intervalles de

temps par trame TDMA

8 8

Débit de la parole 13 [kb/s] 13 [kb/s]

Débit maximal de données 9 ,6 [kb/s] 9,6 [kb/s]

Technique de multiplexage FDMA/TDMA FDMA/TDMA

Rayon de cellules 0, 3 à 30 [km] 0, 1 à 4 [km]

Modulation GMSK (Gaussian

Minimum Shift Keying)

GMSK (Gaussian

Minimum Shift

Keying)

Tableau I.1 Caractéristiques des réseaux 2G

Pour des besoins de transfert de données, les réseaux 2G ont évolué vers les

réseaux 2G+ que nous allons présenter à la suite.

I.1.2 Les réseaux 2G+ (GPRS/EDGE)

Les réseaux 2G+ sont une évolution des réseaux 2G permettant d’avoir un trafic

de données à un débit un peu élevé. A la différence des réseaux 2G, les réseaux

2G+ ont introduit le trafic de données à travers l’utilisation de la commutation

des paquets au lieu de la commutation des circuits.

I.1.2.a Architecture des réseaux 2G+

Comme les réseaux 2G, les réseaux 2G+ se divisent en deux sous-systèmes

principaux :

Le sous-système radio, qui contrairement au GSM apporte un

service de support de commutation de paquet;

Le sous-système réseau qui comprend l’ensemble des fonctions

nécessaires au routage et à la facturation ;

12


Il est à noter que les réseaux 2G+ se présentent en deux catégories. Il y a le GPRS

(General Packet Radio Service) qui permet d’améliorer les réseaux 2G et EDGE

(Enhanced Data Rates for GSM Evolution) qui permet d’améliorer le GPRS.

L’architecture présentée ci-dessous est commune au GPRS et EDGE. Sauf que

pour ce dernier, il faut faire des mises à jour logicielles au niveau des

équipements GPRS pour prendre en compte les nouvelles techniques utilisées.

Figure I.1.2 : Architecture des réseaux 2G+

I.1.2.a Les entités des réseaux 2G+

Les réseaux 2G+ incluent dans leur architecture de nouveaux éléments

permettant de supporter le trafic des données et la commutation des paquets.

Ces éléments sont :

13


CCU

Etant défini comme l’unité qui se charge du codage canal, le CCU est placé au

niveau de la station de base (BTS) et assure les opérations telles que le codage

correcteur d’erreur, la modulation, le contrôle de la puissance….

Le CCU met à disposition du réseau quatre schémas de codage (CS) allant de CS1

à CS4 et pouvant offrir des débits allant de 9,05Kb/s à 171,2Kb/s en théorie pour

le GPRS et des schémas de modulation et de codage (MCS) allant de MCS1 à

MCS9 pour EDGE.

PCU

Il permet de contrôler les transferts de données en mode paquet. Le PCU peut

se trouver dans la BTS, le BSC ou le SGSN (Serving GPRS Support Node). Les

fonctions les plus importantes du PCU sont les suivantes:

Il dirige le trafic paquet vers le réseau de données ;

Il est responsable du découpage des paquets et de leur réassemblage ;

Il contrôle le trafic data, par exemple le contrôle d’accès ; Il contrôle le canal radio, par exemple le contrôle d’alimentation.

SGSN

Le SGSN (Serving GPRS Support Node) sert d’interface entre les utilisateurs

mobiles et un GGSN (Gateway GPRS support Node).

Ces fonctions principales sont l’obtention du profil de l’utilisateur (à partir du

HLR – Home Location Registrer), l’enregistrement des nouveaux abonnés

mobiles et la gestion des fonctions «attache» et «détache» des utilisateurs. De

plus, celui-ci se charge de transférer les paquets reçus d’un mobile par une

station de base vers le réseau IP de l’opérateur.

GGSN

Le GGSN (Gateway GPRS support Node) est utilisé comme interface entre le

réseau IP de l’opérateur et le réseau Internet public ou d’autres fournisseurs de

services mobiles.

14


Ces fonctions principales sont la recherche de différentes routes à travers le

réseau IP de l’opérateur, la mise à jour des informations de routage et le traçage

des différentes adresses se trouvant dans le réseau.

I.1.2.b Les caractéristiques des réseaux 2G+

A la différence des réseaux 2G, les réseaux 2G+ utilisent la commutation de paquet et des techniques de modulations différentes du 2G. Ce qui permet d’avoir un débit de transfert de données un peu important. Les caractéristiques des réseaux 2G+ sont présentées dans le tableau suivant

GPRS EDGE

Modulation GMSK 8-PSK Débit minimum (en théorie)

9,05Kb/s 8,8Kb/s

Débit maximum (en théorie)

171,2Kb/s 473,6Kb/s

Schéma de codage CS1 à CS4 MC1 à MCS9

Type de commutation paquet Paquet Type de multiplexage F/TDMA F/TDMA

Spécificité Adaptation dynamique des liens !

Redondance incrémentale

Tableau I.2 : Caractéristiques des réseaux 2G+

Mais pour des raisons d’augmentation des débits de transfert de données et un souci de normalisation au niveau international, ces réseaux ont laissé la place aux réseaux de troisième génération dont le principal est l’IMT 2000.

I.2 Les réseaux 3G/3G+

Apparue en 2000, la 3G désigne une génération de normes de téléphonie mobile

permettant de résoudre les problèmes de débits liés aux réseaux 2G. En plus

d’avoir un débit élevé, la 3G permet d’avoir une norme internationale, ce qui

15


permet de résoudre les problèmes d’incompatibilité posés par les différents

terminaux 2G. Elle est représentée principalement par les normes UMTS

(Universal Mobile Telecommunications System) et CDMA2000, permettant des

débits (de 2 à 42 Mb/s définis par la dernière génération des réseaux UMTS :

l'HSPA+) qui sont bien plus rapides que la génération précédente (2G). Dans la

suite, nous présenterons la norme UMTS.

I.2.1 Architecture de l’UMTS

Le réseau UMTS est composé d’un réseau d’accès UTRAN (UMTS Terrestrial Radio Access Network) et d’un réseau cœur.

Le réseau d’accès UTRAN est doté de plusieurs fonctionnalités. Sa fonction principale est de transférer les données générées par l’usager. Il est une passerelle entre l’équipement usager et le réseau cœur via les interfaces Uu et Iu. Cependant, il est chargé d’autres fonctions à savoir :

Sécurité Il permet la confidentialité et la protection des informations échangées par l’interface radio en utilisant des algorithmes de chiffrement et d’intégrité.

Mobilité Une estimation de la position géographique est possible à l’aide du réseau d’accès UTRAN.

Gestion des ressources radio Le réseau d’accès est chargé d’allouer et de maintenir des ressources radio nécessaires à la communication.

Synchronisation Il est aussi en charge du maintien de la base temps de référence des mobiles pour transmettre et recevoir des informations. Le cœur de réseau UMTS comprend l’ensemble des fonctions nécessaires au routage et à la facturation ; Ci-dessous nous avons l’architecture de l’UMTS

https://fr.wikipedia.org/wiki/D%C3%A9bit_binaire

16


Figure I.2 : Architecture de l’UMTS I.2.2 Les composants d’un réseau UMTS Le réseau d’accès UTRAN est composé de plusieurs éléments à savoir une ou plusieurs stations de base (appelée NodeB), des contrôleurs radio RNC (Radio Network Controller) et des interfaces de communication entre les différents éléments du réseau UMTS.

NodeB Le rôle principal du NodeB est d’assurer les fonctions de réception et de transmission radio pour une ou plusieurs cellules du réseau d’accès de l’UMTS avec un équipement usager. Le NodeB se charge du codage et décodage. Il sert aussi d’interface entre la station mobile et le RNC et le cœur du réseau.

RNC Le rôle principal du RNC (Radio Network Controller) est de router les communications entre le NodeB et le réseau cœur de l’UMTS. Il travaille au

17


niveau des couches 2 et 3 du modèle OSI (contrôle de puissance, allocation de codes). Deux fonctions ont été introduites dans le RNC afin de gérer la macro-diversité et le handover interRNC. Ces fonctions sont Le Serving RNC et le Drift RNC (un RNC joue l’un ou l’autre des deux rôles pour une communication). Chaque communication met en œuvre un Serving RNC, et passe par 0, 1 ou plusieurs Drift RNC.

Le Serving RNC gère les connexions radios avec le mobile et sert de point de rattachement au réseau de base. Il contrôle et exécute le handover.

Le Drift RNC, sur ordre du Serving RNC, gère les ressources radios des Node B qui dépendent de lui. Il effectue la recombinaison des liens lorsque du fait de la macro diversité plusieurs liens radios sont établis avec des Node B qui lui sont attachés. Il “route” les données utilisateur vers le Serving RNC dans le sens montant et vers les Node B dans le sens descendant.

Réseau Cœur

Le réseau cœur de l’UMTS est constitué de deux domaines à savoir :

Le domaine CS (Circuit Switched) utilisé pour la téléphonie et regroupant les équipements du réseau 2G ;

Le domaine paquet PS (Packet Switched) qui permet la commutation des paquets sur le réseau et regroupant des équipements tels que le SGSN (prend en charge l’enregistrement des usagers dans une zone géographique dans une zone de routage), le GGSN (passerelle vers les réseaux à commutation de paquets)

I.2.3 Les caractéristiques d’un réseau UMTS Les spécifications IMT-20002 (International Mobile Telecommunications for the year 2000) de l'Union Internationale des Communications (UIT), définissent les caractéristiques de la 3G. Ces caractéristiques sont notamment les suivantes :

un haut débit de transmission : 144 Kbps avec une couverture totale pour une utilisation mobile ; 384 Kbps avec une couverture moyenne pour une utilisation

piétonne ;

2 Sigle choisi par l'UIT pour désigner les cinq technologies d'accès radio des systèmes cellulaires 3G.

18


2 Mbps avec une zone de couverture réduite pour une utilisation fixe ;

Une compatibilité internationale; Compatibilité avec les services des réseaux 2G ;

En plus de ce qui est cité ci-haut, les réseaux 3G utilisent WCDMA (Wideband Code Division Multiple Access) comme technique de codage et chaque communication utilisent une bande de 5MHZ. La 3G introduit également les notions de macro diversité et de respiration de cellules. Le WCDMA permet l’utilisation des scrambling codes et des codes OVSF par les stations mobiles afin de communiquer sur le réseau. Les réseaux 3G+ permettent d’augmenter le débit de transmission des données dans le sens montant ou descendant.

Concernant la bande de fréquences, les réseaux 3G opèrent dans la bande 2 100 MHZ.

Offrant certes du haut débit, la 3G demeure un réseau de capacités et les rayons de couvertures des différents sites n’ont pas une longue portée. En plus de nos jours les hommes sont de plus en plus gourmands en matière de débit de transmission des données. C’est dans cette vision que les réseaux 4G ont vu le jour. Ainsi dans les lignes qui suivent, nous allons présenter les réseaux 4G et ses avantages.

I.3 Les réseaux 4G

La 4G est la quatrième génération des standards pour la téléphonie mobile. Succédant à la 2G et la 3G, elle permet le « très haut débit mobile », c'est-à-dire des transmissions de données à des débits théoriques supérieurs à 100 Mb/s, voire supérieurs à 1 Gb/s (débit défini par l'UIT pour les spécifications IMT-Advanced). En pratique, les débits sont de l'ordre de quelques dizaines de Mb/s selon le nombre d'utilisateurs, puisque la bande passante est partagée entre les terminaux actifs des utilisateurs présents dans une même cellule radio.

Une des particularités de la 4G est d'avoir un cœur de réseau basé sur IP et de ne plus offrir de mode commuté (établissement d'un circuit pour transmettre un appel "voix"), ce qui signifie que les communications téléphoniques utiliseront la voix sur IP (en mode paquet).

Il existe deux principales normes des réseaux 4G à savoir :

La LTE (Long Term Evolution) ;

Le WIMAX (Worldwide Interoperability for Microwave Access);

19


I.3.1 Architectures des réseaux 4G (LTE)

Les réseaux LTE sont des réseaux cellulaires constitués de milliers de cellules radio qui utilisent les mêmes fréquences hertziennes, grâce aux codages radio OFDMA (de la station de base vers le terminal) et SC-FDMA (du terminal vers la station de base) et l’utilisation de la technique MIMO3 (Multi Input Multi Output). Ceci permet d’affecter à chaque cellule une largeur spectrale plus importante qu'en 3G, variant de 3 à 20 MHz et donc d'avoir une bande passante plus importante et plus de débit dans chaque cellule.

Le réseau LTE est constitué de deux parties : une partie radio (eUTRAN) et un cœur de réseau EPC (Evolved Packet Core).

La figure ci-dessous présente l’architecture d’un réseau LTE :

Figure I.3 : Architecture d’un réseau LTE

I.3.2 Les composants d’un réseau 4G

E-NodeB

L’eNodeB est l’équivalent de la BTS dans le réseau GSM et du NodeB dans l’UMTS. Ce sont des antennes qui relient les UE (User Equipement) avec le 3 Technologie permettant d’avoir un équipement disposant plusieurs antennes à l’émission et à la réception.

20


cœur du réseau LTE en utilisant les ondes RF. La fonctionnalité du contrôleur radio réside dans l’eNodeB, ce qui permet de réduire le temps de latence du réseau. La mobilité et le handover sont déterminées par l’eNodeB en lieu et place des RNC et BSC dans les réseaux 2G et 3G.

MME : Mobility Management Entity

Cette entité permet de gérer la mobilité (attachement, détachement, mise à jour de localisation) et des sessions (établissement/libération de session de données). Elle est aussi responsable de l’authentification des UE à partir des informations reçues du HSS. Le MME est responsable du paging.

Serving Gateway

Les fonctions de l’entité Serving Gateway sont les suivantes :

Lors d’un handover inter-eNode, le trafic de l’usager qui s’échangeait entre l’ancien eNodeB et le Serving GW doit désormais être relayé du nouvel eNodeB au Serving GW.

Il relaie les paquets entre les systèmes 2G/3G et le PDN-GW. Lors d’une mobilité entre LTE et Les réseaux 2G/3G paquet, le SGSN du réseau 2G/3G s’interface avec le Serving GW pour la continuité du service de données.

Mise en mémoire des paquets entrants lorsque l’UE destinataire est dans l’état ECM-IDLE et initialisation de la procédure de demande de service initiée par le réseau.

Le Serving GW route les paquets sortant vers le PDN Gateway approprié et relaie les paquets entrants à l’eNodeB servant l’UE.

HSS

Avec les réseaux 4G, le HLR est réutilisé et renommé Home Subscriber Server (HSS). Le HSS est un HLR évolué et contient l’information de souscription pour les réseaux GSM, GPRS, 3G, LTE et IMS. A la différence de la 2G et de la 3G où l’interface vers le HLR est supportée par le protocole MAP (protocole du monde SS7), l’interface du HSS s’appuie sur le protocole DIAMETER (protocole du monde IP).

PDN GW (Packet Data Network Gateway)

Le PDN GW sert d’interface entre le réseau et les réseaux externes. Il gère aussi l’attribution des adresses ip aux UE et se charge de la taxation des flux de données.

21


I.3.3 Les caractéristiques d’un réseau 4G

Les réseaux 4G permettent une connectivité permanente par l’intermédiaire de deux porteurs de données à savoir le default bearer (Connectivité permanente au réseau mais sans débit garanti) et le dedicated bearer (connectivité permanente au réseau, débit et qualité de service garantis).

Avec les nouvelles applications nécessitant une connectivité permanente, un système 4G est capable de supporter grâce à la largeur de bande utilisé, un nombre important d’utilisateur par cellule.

Le débit avec la 4G est très important et le temps de latence court.

Ci-dessous, nous avons un tableau résumant les caractéristiques des réseaux 4G.

Débit maximum en Downlink 100Mbps

Débit minimum Uplink 50Mbps

Latence 10 ms

Largeur de canal 1 ,4 MHZ à 20MHZ

Méthode d’accès OFDMA/SC-FDMA

Bande de fréquence Bande inférieure à 1GHZ et bande supérieure à 2GHZ

Tableau I.3 : Caractéristique des réseaux 4G

II. Généralités sur la sécurité des systèmes d’information

II.1 Les règles de bases de la sécurité des systèmes d’information

La continuité des activités d’une entreprise appelle celle de son système d’information. Cette continuité ne peut être assurée que par la mise en place de moyens de protection apportant un niveau de sécurité adapté aux enjeux spécifiques de l’entreprise. La sécurité des réseaux est devenue l’un des éléments clés de la continuité des systèmes d’information d’une entreprise. Ainsi l’entreprise doit mettre en place une politique de sécurité tenant en compte tous les besoins d’accès à son réseau.

Il existe cinq règles principales à tenir en compte lors de la mise en place d’une politique de sécurité. Mais avant de mettre en place ces règles, il faut savoir ce que signifie la sécurité. L’expression sécurité regroupe deux notions distinctes à savoir:

La capacité à lutter contre des problèmes accidentels et naturels (sureté) ;

22


La capacité à lutter contre une action humaine malveillante ; Le premier problème est avant tout un problème d’infrastructure et le second requiert non seulement des mesures, mais fait également appel à de nombreux autres points techniques.

La sécurité doit être abordée dans un contexte global et notamment prendre en compte les aspects suivants : La sécurité physique, soit la sécurité au niveau des infrastructures

matérielles ; La sécurité personnelle : la sensibilisation des utilisateurs aux problèmes

de sécurité ; La sécurité logique: c'est-à-dire la sécurité au niveau des données,

notamment les données de l'entreprise, les applications ou encore les systèmes d'exploitation.

La sécurité des communications: technologies réseau, serveurs de l'entreprise, réseaux d'accès, etc.

La sécurité procédurale: sert de tampon entre les commandes juridiques et les livraisons technique

Il est à noter que les différentes attaques pouvant être subit par le réseau sont les suivantes : Attaques sur les systèmes ; Attaques sur les protocoles de communication ; Attaques sur l'information ; Attaques sur les applications ;

Le tableau ci-dessous présente les différentes règles de la sécurité des systèmes d’information.

Règles Actions Confidentialité Chiffrement

Authentification Hachage/Signature

Intégrité Identification/Signature Non répudiation Empreinte digitale

Disponibilité Redondance

Tableau I.4 : Les règles de la sécurité des SI

Parmi les cinq règles présentées dans le tableau ci-dessus, à l’exception de la dernière, toutes les autres sont gérées par les fonctions cryptographiques. Ainsi nous allons présenter dans les lignes qui suivent la cryptographie.

23


II.2 Notions de base sur la cryptographie

La cryptographie est une science très ancienne. Le mot cryptographie est un terme générique désignant l'ensemble des techniques permettant de chiffrer des messages, c'est-à-dire permettant de les rendre inintelligibles. Le verbe crypter est parfois utilisé mais on lui préfèrera le verbe chiffrer. Le fait de coder un message de telle façon à le rendre secret s'appelle chiffrement. La méthode inverse, consistant à retrouver le message original, est appelée déchiffrement Aujourd'hui, les réseaux informatiques exigent une phase de cryptographie comme mécanisme fondamental afin d'assurer la confidentialité de l’information numérique.

En cryptographie, pour les systèmes de chiffrement on utilise que des algorithmes qui fonctionnent avec des clés. Déjà, depuis la fin du 19eme siècle, Kerckoffs4 avait énoncé, un principe fondamental en cryptographie selon lequel « la sécurité d’un code cryptographique ne doit pas reposer sur le secret de l’algorithme, mais sur celui des clés utilisées ». D'ailleurs, en cryptographie académique, on suppose toujours que l'algorithme est connu de tous. Cela permet aux spécialistes de le tester afin de mettre en évidence ses faiblesses et de l'améliorer en conséquence ou lui trouver un successeur (cette partie est étudiée par la cryptanalyse). Ceci étant, les systèmes cryptographiques sont divisés en trois familles à savoir :

La cryptographie symétrique Elle utilise les algorithmes de chiffrement symétrique. Ce qui permet de chiffrer et de déchiffrer un message à partir de la même clé. Ces types de clés sont appelés des clés symétriques. Ce sont des systèmes à clé partagé. Le schéma ci-dessous montre le fonctionnement de la cryptographie symétrique.

Figure I.4.1 : Cryptographie symétrique

4 Un cryptologue militaire néerlandais du XIX siècle.

24


Pour communiquer, Bob et Alice doivent se mettre d’accord sur une clé partagé afin de chiffrer et déchiffrer leur message. Les algorithmes de chiffrement symétriques les plus utilisés sont : DES et AES. Le problème majeur qui touche la cryptographie symétrique est celui d’avoir un canal fiable sur lequel transférer la clé secrète.

La cryptographie asymétrique Les systèmes symétriques présentés ci-haut sont tous fiables mais ils posent un problème, c'est celui de l'échange de la clé secrète. Comment transmettre de manière fiable à mon interlocuteur la clé de chiffrement utilisée pour chiffrer le message que je lui envoie ? Les systèmes asymétriques ont été inventés pour résoudre ce problème de transmission sécurisée de la clé. Dans les systèmes asymétriques, chaque entité (émetteur ou récepteur) dispose d’une paire de clé. Une clé publique qui peut être connue de tout le monde et une clé privée. Les algorithmes de chiffrement asymétrique les plus utilisés sont : RSA et El Gamal. Par exemple pour communiquer sur un système asymétrique, Alice et Bernard disposent chacun de deux paires de clés. Pour envoyer un message à Bernard, Alice utilise la clé publique de Bernard pour le chiffrement et Bernard à son tour utilisera sa clé privé pour déchiffrer le message. En somme, la clé publique est utilisée pour le chiffrement et la clé privée pour le déchiffrement. Ceci est illustré ci-dessous :

Figure I.4.2 : Cryptographie Asymétrique

25


Les systèmes asymétriques sont certes solides mais très gourmande en ressource. Ce qui peut parfois conduire à l’utilisation des systèmes hybrides qui permettent de combiner à la fois la souplesse des systèmes symétriques et la robustesse des systèmes asymétriques.

Les systèmes cryptographiques hybrides Les systèmes hybrides contiennent les deux systèmes (symétrique et asymétrique) et un générateur aléatoire des clés. Dans ce système, on bénéficie des avantages de deux autres systèmes à la fois. Le message sera chiffré symétriquement pour jouer sur la rapidité offerte par les systèmes symétriques. La clé symétrique sera chiffrée asymétriquement pour profiter de la robustesse des systèmes asymétriques. La solution de de chiffrement de mail PGP utilise un système hybride. Le schéma ci-dessous résume le fonctionnement des systèmes hybrides :

Figure I.4.3 : Cryptographie Hybride

26


Partie II : Cadre conceptuel

27


Chapitre III : L’IMS Dans ce chapitre, nous allons présenter l’IMS et ses différentes caractéristiques.

I. Définition et concepts

La technologie IMS (IP Multimédia Sub-system) est définie comme la clé de la convergence vers le tout IP des réseaux et services de télécommunication. Elle doit permettre aux opérateurs de proposer des services fonctionnant sur IP. IMS est une architecture de service standardisée et définie par le 3GPP5 basée sur le protocole SIP pour l'initialisation de sessions multimédias, utilisé pour la visioconférence ou la voix sur IP. L'IMS est adapté aussi bien aux réseaux filaires qu'aux réseaux mobiles. Ce qui fait de lui une architecture de référence pour la convergence fixe mobile.

Pour favoriser la convergence des réseaux de télécommunications et informatique, des accès multiples et hétérogènes sont amenés à évoluer vers le monde IP. L’IMS héritera des réseaux d’accès du 2G+, 3G et 4G ainsi que des réseaux RTC (Réseau Téléphonique Commuté) et des réseaux informatiques afin de favoriser cette convergence. Des solutions doivent alors être apportées en ce qui concerne la puissance des terminaux.

Avec la technologie IMS, un seul terminal serait en mesure d'être utilisé pour accéder à internet, regarder la télévision et en même temps servir de téléphone en utilisant un seul protocole de communication. Tous les équipements de communication seront en mesure de traiter l'information qu'ils transmettent en utilisant un langage et un protocole uniformisé.

Les concepts de l’IMS tournent autour des principes suivants :

Indépendance de l’accès :

L’IMS fonctionne avec tous les types de réseaux (fixe ou mobile), incluant des fonctions de commutation de paquets, comme le GPRS, l’UMTS, le CDMA 2000, les réseaux sans fil WiMAX, LTE, les réseaux fixes xDSL, en câble coaxial ou en fibres optiques… Les systèmes plus anciens de commutation de circuits (POTS, GSM) sont supportés grâce à des passerelles. Des interfaces ouvertes entre les couches de contrôle et de services permettent de multiplexer les appels et sessions venant de différents réseaux d’accès.

5 3GPP est un organisme de standardisation qui produit et publie les spécifications techniques pour les réseaux 3G et 4G.

28


Des architectures de réseaux différentes :

L’IMS permet aux opérateurs et aux fournisseurs de services d’utiliser les architectures des réseaux subjacents.

Terminaux et mobilité des utilisateurs :

Le réseau mobile fournit la mobilité des terminaux (handover, roaming) alors que la mobilité de l’utilisateur (utilisation de réseaux différents) est fournie par l'IMS et le protocole SIP.

Services basés sur des protocoles IP variés :

IMS facilite l’offre de presque tous les services basés sur IP. Parmi ceux-ci : la voix sur IP (VoIP), la voix sur réseau mobile LTE (VoLTE), le Push to talk sur téléphones cellulaires les jeux multi-joueurs, la vidéoconférence, la messagerie instantanée, les services communautaires, les informations de présence et partage de contenus…

II. Architecture de l’IMS

L'IMS a une architecture centralisée et divisée en plusieurs couches. Avant de pouvoir accéder aux plateformes de services, l'utilisateur doit s'authentifier auprès de l'opérateur. Pour cela le HSS (Home Subscriber Server) assure les fonctions d'authentification, de localisation, de proxy SIP... Le CSCF (Call Session Control Function) contrôle l'ouverture des sessions SIP et l'établissement des appels. On y trouve aussi les MGW (Media Gateway) et les MGCF (Media Gateway Control Function) qui vont permettre de s'interconnecter avec des réseaux RTC ainsi que le MRFC (Multimedia Resource Function Controller) qui contrôle les ressources utilisées par le client.

À la manière de l’approche NGN, l’architecture IMS reprend une approche en couches qui se décline en quatre plans à savoir :

Le plan d’Accès qui peut utiliser tout accès haut débit tel que l’UMTS, LTE, WIMAX, XDSL, RNIS, etc. L’IMS hérite des réseaux d’accès des architectures existantes.

Le plan Transport représente un réseau IP ou dérivé. Ce réseau IP pourra intégrer des mécanismes de qualité de service avec Diffserv, RSVP, MPLS, etc. La couche transport est constituée généralement des routeurs reliés à un réseau de transmission.

29


Le plan Contrôle consiste en des contrôleurs de session responsables du routage de la signalisation entre usagers et de l’invocation des services. Ces nœuds s’appellent des CSCF (Call State Control Function). IMS Introduit donc un environnement de contrôle de session sur le domaine paquet. Le contrôle et la gestion des sessions se font grâce aux protocoles SIP que nous présenterons un peu plus bas.

Le plan Application (ou de Service) introduit les applications (services à valeur ajoutée) proposées aux usagers. L’opérateur peut se positionner grâce à sa couche Contrôle en tant qu’agrégateur de services offerts par l’opérateur lui-même ou par des tiers. La couche de service est constituée des serveurs d’application (AS, Application Server, intégrant les services IMS et la souscription au serveur HSS) et serveurs de média IP (IP MS, IP Media Server). L’IP Media Server est aussi appelé MRF (Multimedia Resource Function).

La figure ci-dessous nous présente l’architecture de l’IMS

Figure II.1.1: Architecture de l’IMS

30


III. Présentation de l’IMS

III.1 Les entités fonctionnelles de l’IMS L’IMS introduit une nouvelle entité fonctionnelle dans le réseau, appelée CSCF (Call State Control Function). Elle joue le rôle de Proxy Server SIP, et ses trois principales fonctions sont La localisation des usagers, le routage (des messages SIP pour l'établissement, la modification et la libération de sessions multimédias) et le maintien des informations d'état de la session (afin de pouvoir invoquer les services souscrits par les usagers et de contrôler la session pendant sa durée de vie pour la facturation.) Dans cette section nous allons présenter les différentes entités constituant le réseau IMS afin de comprendre leur fonctionnent.

Terminaux IMS Il s’agit d’une application sur un équipement usager qui émet et reçoit des requêtes SIP. Il se matérialise par un logiciel installé sur un PC, sur un téléphone IP ou sur une station mobile UMTS ou LTE.

P-CSCF (Proxy CSCF) : Le P-CSCF est le premier point de contact entre un usager et un réseau IMS. Son adresse est découverte par le terminal lors de l'activation d'un contexte PDP pour l'échange de messages de signalisation SIP. Le P-CSCF se comporte comme un Proxy Server SIP lorsqu'il relaye les messages SIP vers le destinataire approprié et comme un User Agent SIP lorsqu'il termine l'appel. Les fonctions réalisées par l'entité P-CSCF comprennent :

L'acheminement de la méthode SIP REGISTER émise par le terminal à l'entité I-CSCF à partir du nom du domaine nominal.

L'acheminement des méthodes SIP émises par le terminal au S-CSCF dont le nom a été obtenu dans la réponse à la procédure d'enregistrement.

Le routage des méthodes SIP ou réponses SIP au terminal. La génération de CDRs (Call Detailed Record). La compression ou décompression des messages SIP

Un réseau IMS peut inclure plusieurs P-CSCF pour assurer une évolutivité et une redondance dans le réseau. Chaque P-CSCF peut servir un certain nombre de terminaux IMS dépendamment de la capacité du nœud

31


I-CSCF (L'Interrogating-CSCF) :

Il est le point de contact au sein d'un réseau d'opérateur pour toutes les sessions destinées à un utilisateur de cet opérateur. Il masque la topologie du réseau et achemine l'appel vers le S-CSCF adéquat. Les fonctions réalisées par l'entité I-CSCF comprennent :

L'assignation d'un S-CSCF à un utilisateur qui s'enregistre ; L'acheminement des méthodes SIP reçues depuis un autre réseau,

au S-CSCF ; L'obtention de l'adresse du S-CSCF auprès du HSS. La génération de CDRs ;

Il s’interface avec le SLF et le HSS en utilisant le protocole DIAMETER et se sert des informations sur la localisation de l’utilisateur pour router les requêtes SIP vers le S-CSCF adéquat. Un réseau IMS peut inclure plusieurs ICSCF pour assurer une évolutivité et une redondance.

Le S-CSCF (Le Serving-CSCF): Le S-CSCF prend en charge le contrôle de la session. Il maintient un état de session afin de pouvoir invoquer des services. Dans un réseau d'opérateur, différents SCSCF peuvent présenter des fonctionnalités différentes. Les fonctions réalisées par le S-CSCF pendant une session sont les suivantes :

L'émulation de la fonction Register puisqu'il accepte les méthodes SIP d'enregistrement et met à jour le HSS ;

L'émulation de la fonction Proxy server puisqu'il accepte les méthodes SIP et les achemine ;

L'émulation de la fonction User Agent puisqu'il peut terminer des méthodes SIP par exemple lorsqu'il exécute des services complémentaires ;

L'interaction avec des serveurs d'application après avoir analysé les critères de déclenchement des services correspondants ;

La génération de CDRs ; Il obtient l’adresse de l’I-CSCF dans le réseau destinataire lors de

l’établissement de session ; Il implémente une interface DIAMETER avec le HSS pour télécharger les vecteurs d’authentification de l’utilisateur qui veut accéder au réseau et pour informer le HSS des terminaux qui lui ont été alloués. Avant de pouvoir utiliser les services du domaine IMS, tels qu'établir une session multimédia ou recevoir une demande de session, l’usager doit d’abord s'enregistrer au réseau. Que l'usager soit dans son réseau nominal ou dans un

32


réseau visité, cette procédure fait intervenir un P-CSCF. Par ailleurs, tous les messages de signalisation émis par le terminal ou à destination du terminal sont relayés par le P-CSCF. Le terminal n'a jamais la connaissance des adresses des autres CSCFs (I-CSCF et S-CSCF).

Les bases de données Dans une architecture IMS, les bases de données sont le HSS (Home Subscriber Server) et le SLF (Subscription Locator Function).

L’entité HSS (Home Subscriber Server) est la principale base de stockage des données des usagers et des services auxquels ils ont souscrit. Les principales données stockées sont les identités de l’usager, les informations d’enregistrement, les paramètres d’accès et les informations permettant l’invocation des services de l’usager. Les identités des utilisateurs sont du type privés et publics. Les identités privées sont attribuées aux utilisateurs par l’opérateur et servent à des fins d’enregistrement et d’authentification. Tandis que l'identité publique est celle que les autres utilisateurs peuvent utiliser pour demander à communiquer avec l'utilisateur final. Le HSS fournit également des exigences spécifiques à l'utilisateur pour les capacités du S-CSCF. Cette information est utilisée par le contrôleur I-CSCF pour sélectionner le S-CSCF le plus approprié pour un utilisateur. L’entité HSS interagit avec les entités du réseau à travers le protocole Diameter. Elle contient :

Table SVP (Service Profile) : contient le profil de service qui est associé à chaque utilisateur ;

Table IP Multimédia Private Identity (IMPI) : contient les identifiants qui représentent les adresses publiques et privées de l’utilisateur avec les informations d'authentification et autorisation ;

Table IMS Public User identity (IMPU) : contient des informations d’enregistrement ;

Table IMS Subscription User (IMSU) : contient des informations de souscription.

Table Charging information (Chginfo) : contient des informations de tarification.

Table Networks : contient la localisation qui représente le réseau dans lequel l’utilisateur est abonné.

Table Roam : pour les réseaux avec lesquels des accords de roaming sont passés.

Table as_perm_list : contient les services autorisés qui identifient les services auxquels l’utilisateur est abonné.

33


Table Application Server (APSVR) : contient l’adresse de l’AS à contacter si les trigger points ont été conforme. Des informations sur le comportement par défaut de la session sont données si le contact avec l’AS a échoué.

Table Initial Filter Criteria (IFC): qui représentent les informations de filtrage initial, caractérisant un certain service pour l'utilisateur. Cette table fait correspondre un trigger point (table Trigpt) qui associe un ensemble de service

point trigger (table spt) à un serveur d’application.

Le SLF est utilisée comme un mécanisme de résolution qui permet à l'I-CSCF, le S-CSCF et l'AS de trouver l'adresse du HSS qui contient les données d'abonné pour une identité d'utilisateur donné lorsque des HSSs multiples et adressables séparément ont été déployés par l’opérateur de réseau.

III.2 Architecture des services de l’IMS

L’architecture de service IMS de base est constituée des serveurs d’application, des serveurs de média IP et des S-CSCF qui sont les équivalents des serveurs d’appels. Les serveurs d’applications interagissent avec les S-CSCF à travers l’interface ISC (IP Multimedia Service Control) en utilisant le protocole SIP. Les serveurs d’application présents dans un réseau sont les suivants :

Les serveurs d'application SIP (SIP AS) qui exécutent des services (Présence, Messagerie instantanée, vidéoconférence, IPTV, etc.) et qui peuvent influencer le déroulement de la session à la demande du service ;

Le point de commutation au service IM (IM-SSF, IP Multimedia Service Switching Function) qui est un type particulier de serveur d'application SIP qui termine la signalisation SIP sur l'interface ISC d'une part et qui joue le rôle de SSP RI/CAMEL d'autre part pour interagir avec les entités utilisant CAMEL ;

La passerelle OSA (OSA SCS : OSA Service Capability Server) qui est un type particulier de serveur d'application SIP qui termine la signalisation SIP sur l'interface ISC et qui interagit avec des serveurs d'application OSA en utilisant l'API OSA ;

Un type spécialisé de serveur d'application SIP appelé gestionnaire d'interaction de service (SCIM, Service Capability Interaction Manager) qui permet la gestion des interactions entre serveurs d'application SIP ;

34


En plus des serveurs d'application, il existe un serveur de média appelé MRF (Multimedia Resource Function). Il établit des conférences multimédias, joue des annonces vocales ou multimédia et collecte des informations utilisateur. L'entité MRF est décomposée en deux fonctions à savoir :

La fonction MRFP (MRF Processor) qui traite le média à travers le transport RTP/UDP/IP ;

La fonction MRFC (MRF Controller) qui traite la signalisation. L'interface Mr entre les entités S-CSCF et MRFC est supportée par le protocole SIP ;

Tous les serveurs d'applications présents dans l’IMS se comportent comme des serveurs d'application SIP. Par ailleurs ces serveurs d'application peuvent interagir avec l'entité MRFC à travers le S-CSCF afin de contrôler les activités média mises en œuvre par l'entité MRFP. Ci-dessous, nous avons l’architecture des services de l’IMS

Figure II.1.2: Architecture des services IMS

35


III.3 Profil des abonnés d’un réseau IMS

Comme dans tout type de réseau, il est impératif de pouvoir identifier les

utilisateurs d’une façon unique de telle manière qu’ils soient joignables de

n’importe quel réseau. Dans IMS il y a un nouveau concept d’identification par

rapport à ce qui se faisait dans les réseaux mobile. Un utilisateur a deux types

d’adresse à savoir une identité publique et privée.

Public User Identity

C’est une adresse publique définie par l’opérateur qui permet d’identifier un

utilisateur IMS. L’identité publique de l’utilisateur est l’équivalent du MSISDN en

GSM, donc c’est une adresse de contact qui permet de joindre l’abonné, elle sert

à router les messages SIP. L’identité publique de l’utilisateur IMS peut se

présenter sous deux formats à savoir :

o SIP URI qui se présente sous la forme « sip:username@domaine ». Il est

aussi possible d’inclure un numéro de téléphone dans une SIP URI. o TEL URL qui permet de représenter un numéro de téléphone dans un

format international «tel:+1-961-007-007». Il est impossible de

s’enregistrer avec un TEL URL dans un réseau IMS, il faut toujours une SIP

URI. Mais le TEL URL est utilisé pour faire des appels entre le monde RTC

et le monde IMS. Or en RTC les téléphones sont identifiés par des numéros

et ne peuvent composer que des numéros. Donc l’opérateur IMS doit

allouer à chaque utilisateur au moins une SIP URI et un TEL URL. Private User Identity

On affecte une identité privée pour chaque utilisateur. Cette identité joue le même rôle que l’IMSI en GSM, elle permet l’authentification de l’abonné et son enregistrement. Elle prend le format suivant : « username@domaine ». L’identité privée de l’utilisateur est stockée dans la carte à puce.

Il est à noter qu’un abonné IMS doit avoir les deux types d’identités cités ci haut. Une identité privée peut être reliée à un ou plusieurs identités publiques.

36


Les abonnés IMS peuvent être des clients mobiles se servant d’un accès 3G ou 4G et disposant des cartes USIM (intégrant ou non un module ISIM : IMS SIM module) pour l’enregistrement. Ils peuvent également utiliser un accès fixe ou sans fil (ne disposant pas de carte USIM ou de module ISIM) pour l’enregistrement.

IV. Les protocoles de communication et les interfaces utilisés par l’IMS Dans un réseau IMS, plusieurs protocoles de communication sont utilisés. Parmi ces protocoles, nous avons SIP et diameter. Ces différents protocoles transitent sur des interfaces bien spécifiques. Dans cette section, nous allons voir dans un premier temps les différentes interfaces au sein d’un réseau IMS et ensuite les différents protocoles utilisés par IMS. IV.1 Les interfaces Tout comme dans les réseaux 2G et 3G, les différentes entités de l’architecture IMS sont reliées via des interfaces spécifiques. Ces différentes interfaces sont présentées sur la figure suivante :

Figure II.1.3 : Les interfaces de l’IMS

Ces interfaces sont nombreuses mais nous allons présenter quelques une d’entre elles dans les lignes qui suivent.

37


Interface GM : Cette interface permet l’acheminement des messages SIP entre l’UE (User Equipement) et le P-CSCF. Ces requêtes SIP servent principalement pour l’enregistrement de l’abonné, le contrôle de la session et les transactions SIP.

Interface Cx : Basée sur le protocole diameter, cette interface permet de relier le S-CSCF ou I-CSCF à la base de données HSS. Cette interface permet l’authentification, la localisation et la gestion du profil des abonnées.

Interface Sh : Basée sur le protocole diameter, cette interface relie les serveurs d’application au HSS. Un AS (SIP AS ou OSA SCS) peut avoir besoin de données (relatives à une identité particulière de l’abonné ou relatives à l’identité public d’un service) ou a besoin de savoir à quel S-CSCF envoyer une requête SIP. D’où le besoin d’avoir de les interfacer avec le HSS. Le HSS a une liste d’AS qui sont autorisés à obtenir ou sauvegarder des données.

Interface ISC : Basée sur le protocole SIP, cette interface relie le S-CSCF aux serveurs d’applications. Elle permet le routage des requêtes SIP vers les AS appropriés et la gestion des requêtes SIP initiées par les AS.

Interface Mw : Basée sur le protocole SIP, cette interface permet de relier les différents blocs CSCF. Il permet l’enregistrement, le contrôle de session et les transactions.

IV.2 Les protocoles

Les protocoles utilisés dans un réseau IMS peuvent remplir trois fonctions bien spécifiques à savoir l’authentification (Diameter), le transport des flux multimédia (RTP ou RTCP) et le transport de la signalisation (SIP). Dans cette section nous allons voir les protocoles SIP et Diameter.

SIP (Session Initiation Protocol)

SIP est un protocole de signalisation défini par l’IETF (Internet Engineering Task Force) permettant l’établissement, la libération et la modification de sessions multimédias (ceci est spécifié dans le RFC6 3261). Il hérite de certaines fonctionnalités des protocoles http (Hyper Text Transport Protocol), et SMTP (Simple Mail Transport Protocol). SIP s’appuie sur un modèle transactionnel client/serveur comme HTTP. L’adressage utilise le concept d’URL SIP (Uniform Resource Locator) qui ressemble à une adresse E-mail. Chaque participant dans

6 Les RFC sont une série numérotée de documents officiels décrivant les aspects techniques d’une technologie.

38


un réseau SIP est donc adressable par une URL SIP. Par ailleurs, les requêtes SIP sont acquittées par des réponses identifiées par un code numérique. Il a été étendu afin de supporter de nombreux services tels que la présence, la messagerie instantanée, le transfert d’appel, la conférence, les services complémentaires de téléphonie, etc. SIP a été retenu par le 3GPP pour l’architecture IMS (IP Multimedia Subsystem) comme protocole de signalisation. Tout comme http, SIP fonctionne en mode client-serveur et dispose de deux types d’entités dont un User Agent (Cleint SIP) et un serveur (Register, Proxy Redirect). Ces différentes entités communiquent en utilisant des méthodes et réponses

SIP. Les méthodes SIP sont résumées dans le tableau qui suit :

Méthodes Rôles

INVITE Elle est utilisée afin d’établir une session entre les clients SIP (User Agent)

ACK Elle permet de confirmer la réception d’une méthode

BYE Elle permet la libération d’une session préalablement établie

REGISTER Elle est utilisée par un UA afin d’indiquer au serveur Registrar la correspondance entre son adresse SIP et son adresse de contact

CANCEL Elle est utilisée pour demander l’abandon d’un appel en cours mais n’a aucun effet sur un appel déjà accepté. En effet, seule la méthode BYE peut terminer un appel établi.

OPTIONS Elle est utilisée afin d’interroger les capacités et l’état d’un User agent ou d’un serveur

Tableau II.1: Méthodes SIP de Base

Dans IMS, le protocole SIP est utilisé avec ses extensions et ceci de manière intensive. Pour des exigences d’IMS, il y a aussi l’ajout de nouveaux champs

39


d’entête (Path, Service Route et les P-Headers) aux messages SIP. Le tableau ci-dessous présente quelques extensions SIP utilisées par IMS.

Méthodes Rôles SUBSCRIBE Demande de souscription

NOTIFY Notifier un évènement

UPDATE Mise à jour des paramètres de session REFER Renvoie du récepteur vers une

ressource identifiée dans la méthode PUBLISH Publier l’état d’une entité

MESSAGE Transfert pour la messagerie instantanée

PRACK Acquitter la réception des messages provisoires

Tableau II.2: Méthodes SIP utilisées par IMS

Cependant la gestion de l’authentification des abonnés et de la sécurité est assurée par le protocole diameter sur les interfaces sh, cx et Dx.

Le protocole diameter Etant défini dans la RFC 3588, le protocole diameter est un successeur de radius. Il définit les prérequis nécessaires pour la mise en place d’un protocole AAA (protocole réalisant les trois fonctions suivantes: l'authentification, l'autorisation, et la traçabilité). Il est un protocole utilisé en particulier par le 3GPP pour ses architectures LTE (Long Term Evolution of 3G) et IMS (IP Multimedia Subsystem). DIAMETER est défini à travers un protocole de base et un ensemble d’applications. Cette conception permet une extension du protocole de base pour de nouvelles applications. Le protocole de base fournit un format de commande et d’AVP (Attribute Value Pair qui sont des éléments d’informations), des mécanismes pour un transport fiable, la livraison des commandes et le traitement des erreurs. Le protocole de base doit être utilisé conjointement avec une application DIAMETER. Chaque application s’appuie sur les services du protocole de base. Les commandes du protocole de base sont soit liées à des aspects authentification, autorisation, soit à des aspects taxation.

40


Les commandes du protocole de base relatives aux aspects d’autorisation et d’authentification ont un « Application Id » égal à 0. Celles relatives aux aspects taxation offline ont un Application Id égal à 3 et 4 pour celles relatives aux aspects de taxation online. Les entités implémentant le protocole diameter sont appelées nœuds diameter. Suivant leur rôle, le nœud peut être un client ou un serveur. Il est client lorsqu’il émet une requête et est serveur lorsqu’il reçoit et traite des requêtes. Le protocole DIAMETER peut être utilisé en mode associé ou peer to peer (sans agent) ou en mode quasi associé (avec un agent). Tous les nœuds et agent diameter doivent supporter le protocole de base qui inclut les aspects authentification, autorisation et taxation (Le protocole AAA). Par ailleurs, ils doivent supporter chaque application diameter nécessaire à la mise en œuvre du service du nœud.

Un agent DIAMETER est un nœud qui fournit des services de relai, de proxy ou de traduction. Ces différents nœuds sont présentés dans les lignes qui suivent :

Agent relai Un agent relai est un agent DIAMETER qui accepte des requêtes, et les relaie soit à un autre agent, soit au nœud DIAMETER de destination à partir des informations présentes dans les requêtes. Cette décision de routage est réalisée grâce à la table de routage basée sur le Destination Realm (nom de domaine de la destination), qui indique le nœud suivant pour une destination donnée. Les agents Relai ne réalisent aucun traitement de niveau application. Les agents relai modifient les messages DIAMETER en y insérant et en y supprimant des informations de routage, mais ne modifient aucune autre partie des messages. Les agents relai ne maintiennent pas d’état de session mais doivent maintenir un état de transaction. Le maintien de l’état de transaction permet de garantir qu’une requête et une réponse appartenant à une même transaction suivent le même chemin.

Agent proxy Un agent proxy tout comme un agent relai route le message DIAMETER en utilisant les tables de routage contenant les domaines de destination (Realm). Cependant, il est différent puisqu’il peut modifier les messages DIAMETER afin d’implanter des politiques de communication définies par l’opérateur. Un agent proxy peut maintenir un état de session et doit maintenir un état de transaction. Puisque la mise en œuvre de politiques requiert la compréhension du service rendu, un agent Proxy doit publier les applications qu’il supporte et doit comprendre la sémantique des commandes DIAMETER qu’il route. Par analogie

41


par rapport à SS77, un agent relai est un PTS (Point de Transfert Sémaphore) qui route au niveau 3 en utilisant le DPC (Destination Point Code) alors qu’un agent proxy est un PTS qui route au niveau SCCP (Signaling Connection Control Part) et réalise des opérations GTT (Global Title Translation).

Agent de redirection Un agent de redirection fournit aussi une fonction de routage. Il permet généralement la traduction de nom de domaine en l’adresse du serveur. A la différence des autres types d’agent (relai et proxy) qui acheminent les messages DIAMETER, l’agent de redirection retourne un type particulier de message de réponse à l’émetteur de la requête. La réponse contient l’information de routage afin que l’émetteur puisse retransmettre son message directement au serveur destinataire. Un agent de redirection ne modifie donc pas le message DIAMETER. Il ne maintient ni un état de transaction ni un état de session.

Agent de traduction Un agent de traduction traduit les protocoles tels que DIAMETER en RADIUS ou DIAMETER en MAP (Mobile Application Part) à des fins d’authentification et d’autorisation ou DIAMETER en CAP (CAMEL Application Part) pour réaliser la taxation online. La figure qui suit représente les différents nœuds diameter

Figure II.1.4: Les nœuds diameter

7 Protocole de signalisation utilisée dans les réseaux traditionnels

42


Il est à noter que diameter implémente nativement des mécanismes de gestion d'erreurs. Ainsi, si deux nœuds adjacents ne communiquent pas pendant un certain temps, ils initient périodiquement des requêtes et réponses pour s'assurer de la bonne connectivité. Cela permet de détecter d'éventuelles ruptures de lien. Si un nœud envoie une requête à un voisin sans obtenir de réponse, il retransmet ce message à un nœud alternatif dans la mesure du possible. Le schéma ci-dessous illustre ce scénario :

Figure II.1.5: Mécanisme de gestion des erreurs

Les commandes de base diameter Diameter définit un ensemble de commandes d’authentification, d’autorisation et de taxation offline et online génériques.

Il y a le groupe de commandes connexion management qui permet la mise en relation DIAMETER entre deux peers et la supervision de cette relation. Ces commandes ne sont pas routables puisqu’elles ne peuvent subir qu’un seul saut.

Le groupe Session Operations quant à lui permet d’établir une session DIAMETER d’authentification et d’autorisation entre un client et un serveur. Ces commandes sont de bout en bout et routables via des agents.

Les groupes accounting (offline ou online) permettent l’envoi d’informations de taxation (offline ou online) par un client à un serveur. Les commandes sont de bout en bout routables via des agents. Ces différentes commandes sont présentées sur la figure ci-dessous :

43


Figure II.1.6: Commande de base Diameter A ces commandes de bases peuvent s’ajouter des commandes spécifiques aux nœuds ou applications implémentant diameter. A titre d’exemple, considérons l’interface Cx entre les entités I-CSCF ou S-CSCF et le HSS dans l’architecture IMS. Cette interface permet l’autorisation d’enregistrement pour l’usager (I-CSCF vers HSS), la demande des vecteurs d’authentification pour l’usager (S-CSCF vers HSS), la notification d’état d’enregistrement (S-CSCF vers HSS), L’annulation d’enregistrement initiée par le réseau (HSS vers S-CSCF), La demande de localisation de l’usager (I-CSCF vers HSS), et la mise à jour du profil de l’usager (HSS vers S-CSCF). Ces différentes commandes sont illustrées par la figure ci-dessous :

44


Figure II.1.7: Commandes diameter de l’interface Cx

V. Enregistrement d’un abonné IMS Pour pouvoir utiliser et bénéficier des services qu’offrent l’IMS, l’utilisateur, doit d’abord s’enregistrer. Le premier pas dans l’enregistrement de l’utilisateur est la découverte du P-CSCF qui fait office d’interface entre le réseau IMS et les périphériques finaux. Pour un usager se trouvant dans un réseau d’accès 3G/3G+, la découverte du P-CSCF passe par l’activation d’un contexte PDP nécessaire pour l’échange de la signalisation SIP. Les procédures d’authentification et d’établissement dans l ’IMS sont directement liées aux procédures d’enregistrement SIP. Il est à noter que l’IMS permet une grande mobilité des abonnés. Ce qui veut dire qu’un abonné peut s’enregistrer depuis son réseau nominal (Réseau de son opérateur) ou depuis un réseau visité. La figure ci-dessous illustre les procédures d’enregistrement d’un abonné IMS :

45


Figure II.1.8: Enregistrement d’un abonné IMS La procédure d’enregistrement présentée ci-haut fait intervenir à la fois le protocole SIP (pour l’échange des messages de signalisation) et le protocole diameter (pour l’authentification de l’abonné) dont les types de messages ont été présentés ci-haut. Les messages SIP « 401 Unauthorized » sont des réponses négatives d’enregistrement envoyées par le S-CSCF aux UEs. Ces réponses contiennent d’une part une valeur random (RAND) à utiliser par l’UE pour calculer un résultat d’authentification usager et d’autre part un résultat d’authentification réseau (AUTN) permettant au réseau IMS de s’authentifier auprès de l’usager car l’authentification IMS est mutuelle. Grâce à cet enregistrement : Le HSS est notifié de la localisation de l'UE par rapport au réseau nominal

et met à jour le profil de l'abonné correspondant ; L'usager, grâce aux informations d’enregistrement sera authentifié avant

de pouvoir accéder aux services IMS;

46


Le réseau nominal de l'usager sélectionne un S-CSCF approprié qui invoquera les services de l'UE auprès de serveurs d'application, et ce, grâce au profil de l'usager retourné par le HSS au S-CSCF sélectionné ;

Cependant, fonctionnant dans un monde IP, l’IMS peut être sujet à plusieurs attaques visant à arrêter son fonctionnement ou aux vols d’identité des abonnées. Le chapitre qui suit parlera des différentes attaques pouvant subir un réseau IMS et les précautions à prendre afin de corriger ces failles.

47


Chapitre IV : Sécurité au niveau des systèmes VOIP Fonctionnant dans un réseau totalement IP, l’IMS qui est considéré comme le point d’entrée de la convergence fixe mobile peut être victime des attaques visant à nuire ou non à son fonctionnement. Dans ce chapitre, nous allons parler des différents types d’attaque que peuvent subir les systèmes VOIP comme l’IMS et proposer des solutions permettant de préserver le réseau.

I. Les attaques sur les systèmes VOIP La voix sur IP permet le transport de la voix comme n’importe quel genre de données sur l'ensemble du réseau qui implémente TCP/IP, tels qu’Internet publique, un réseau d’entreprise ou un réseau local. VoIP est l’abréviation anglaise de Voice over Internet Protocol.

Alors que les attaques sur les systèmes de VoIP sont en constante

augmentation, les vulnérabilités observées augmentent elles aussi. On

peut décomposer ces attaques en deux parties à savoir: les attaques au

niveau protocolaire et les attaques au niveau applicatif . Les attaques

informatiques visent le plus souvent à voler des informations (en faisant

de l’écoute), arrêter le fonctionnement d’un service (déni de service :

DOS) ou à utiliser frauduleusement le réseau (usurpation d’identité).

I.1 Attaques sur les protocoles

Un appel téléphonique VoIP est constitué de deux parties : la signalisation, qui instaure l'appel, et les flux de media, qui transporte les données.

La signalisation, en particulier SIP, transmet les entêtes et la charge utile (Payload) du paquet en texte clair, ce qui permet à un attaquant de lire et falsifier facilement les paquets. Elle est donc vulnérable aux attaques qui essaient de voler ou perturber le service, et à l'écoute clandestine qui recherche des informations sur un compte utilisateur valide, pour passer des appels gratuits par exemple. La signalisation utilise, en général, le port par défaut UDP/TCP 5060.

Le protocole RTP utilisé pour le transport des flux multimédia, présente également plusieurs vulnérabilités dues à l'absence d'authentification et de chiffrement. Chaque entête d'un paquet RTP contient un numéro de séquence qui permet au destinataire de reconstituer les paquets de la voix dans l'ordre approprié. Cependant, un attaquant peut facilement injecter des paquets

48


artificiels avec un numéro de séquence plus élevé. En conséquence, ces paquets seront diffusés à la place des vrais paquets.

Généralement, les flux multimédias contournent les serveurs proxy et circulent directement entre les points finaux. Les menaces habituelles conte le flux de la voix sont l'interruption de transport et l'écoute clandestine.

Les protocoles de la VoIP utilisent TCP et UDP comme moyen de transport et par conséquent sont aussi vulnérables à toutes les attaques contre ces protocoles, telles le détournement de session (TCP) (session Hijacking) et la mystification (UDP) (Spoofing), etc.

SNIFFING

Un reniflement (Sniffing) peut avoir comme conséquence un vol d'identité et la révélation d'informations confidentielles. Il permet également aux utilisateurs malveillants perfectionnés de rassembler des informations sur les systèmes VoIP. Ces informations peuvent par exemple être employées pour mettre en place une attaque contre d'autres systèmes ou données.

Suivi des appels

Appelé aussi Call tracking, cette attaque se fait au niveau des réseaux LAN et cible les terminaux (soft/hard phone). Elle a pour but de connaître qui est en train de communiquer et quelle est la période de la communication. Pour réaliser cette attaque, L'attaquant doit être capable d'écouter le réseau et récupérer les messages SIP INVITE et BYE.

Injection des paquets RTP

Cette attaque cible généralement le serveur register, et a pour but de perturber une communication en cours.

L'attaquant devra tout d'abord écouter un flux RTP de l'appelant vers l'appelé, analyser son contenu et générer un paquet RTP contenant un en-tête similaire mais avec un plus grand numéro de séquence et timestamp, afin que ce paquet soit reproduit avant les autres paquets (s'ils sont vraiment reproduits). Ainsi, la communication sera perturbée et l'appel ne pourra pas se dérouler correctement.

49


Pour réaliser cette attaque, l'attaquant doit être capable d'écouter le réseau afin de repérer une communication ainsi que les timestamps des paquets RTP. Il doit aussi être capable d'insérer des messages RTP qu'il a généré ayant un timestamp modifié.

I.2 Déni de service (DOS)

Une attaque par déni de service (denial of service attack, d'où l'abréviation DoS) est une attaque informatique ayant pour but de rendre indisponible un service, d'empêcher les utilisateurs légitimes d'un service de l'utiliser. Il peut s'agir de :

l’inondation d’un réseau afin d'empêcher son fonctionnement ;

la perturbation des connexions entre deux machines, empêchant l'accès à un service particulier ;

l'obstruction d'accès à un service à une personne en particulier ;

Dans le cas des systèmes VOIP, cette attaque peut servir à arrêter ou empêcher le serveur VOIP de répondre aux requêtes des utilisateurs normaux. Ces attaques peuvent être de plusieurs manières à savoir :

Attaque de déni de service SYN Flood

Une attaque SYN Flood est une attaque visant à provoquer un déni de service en émettant un nombre important de demandes de synchronisation TCP incomplète avec un serveur. Quand un système (client) tente d'établir une connexion TCP vers un système offrant un service (serveur), le client et le serveur échangent une séquence de messages. Le système client commence par envoyer un message SYN au serveur. Le serveur reconnaît ensuite le message en envoyant un SYN-ACK message au client. Le client finit alors d’établir la connexion en répondant par un message ACK. La connexion entre le client et le serveur est alors ouverte, et le service de données spécifiques peut être échangé entre le client et le serveur.

Créer des connexions semi-ouvertes s’accomplit facilement avec l'IP spoofing. Le système de l'agresseur envoie des messages SYN à la machine victime ; ceux-ci semblent être légitimes, mais font référence à un système client incapable de

50


répondre au message SYN-ACK. Cela signifie que le message ACK final ne sera jamais envoyé au serveur victime.

Dans la plupart des cas, la victime aura des difficultés à accepter toute nouvelle connexion réseau entrante. Dans ce cas, l'attaque n'affecte pas les connexions entrantes, ni la possibilité d'établir des connexions réseau sortant. Toutefois, le système peut saturer la mémoire, ce qui provoque un crash rendant le système inopérant.

UDP Flooding

Ce déni de service exploite le mode non connecté du protocole UDP. Il crée un "UDP Packet Storm" (génération d’une grande quantité de paquets UDP) soit à destination d’une machine soit entre deux machines. Une telle attaque entre deux machines entraîne une congestion du réseau ainsi qu’une saturation des ressources des deux hôtes victimes. La congestion est plus importante du fait que le trafic UDP est prioritaire sur le trafic TCP. En effet, le protocole TCP possède un mécanisme de contrôle de congestion, dans le cas où l’acquittement d’un paquet arrive après un long délai, ce mécanisme adapte la fréquence d’émission des paquets TCP et le débit diminue. Le protocole UDP ne possède pas ce mécanisme. Au bout d’un certain temps, le trafic UDP occupe donc toute la bande passante, ne laissant qu’une infime partie au trafic TCP.

L’exemple le plus connu d’UDP Flooding est le « Chargen Denial of Service Attack ». La mise en pratique de cette attaque est simple, il suffit de faire communiquer le service chargen d’une machine avec le service echo d’une autre.

Attaque du type Smurfing

Cette attaque utilise le protocole ICMP. Quand un ping (message ICMP ECHO) est envoyé à une adresse de broadcast, celui-ci est envoyé à chacune des machines du réseau. Le principe de l’attaque est de truquer les paquets ICMP ECHO REQUEST envoyés en mettant comme adresse IP source celle de la cible. Le hacker envoie un flux continu de ping vers l’adresse de broadcast d’un réseau et toutes les machines répondent alors par un message ICMP ECHO REPLY en direction de la cible. Le flux est alors multiplié par le nombre d’hôtes composant le réseau. Dans ce cas tout le réseau cible subit le déni de service, car l’énorme quantité de trafic générée par cette attaque entraîne une congestion du réseau.

51


Attaque par la méthode Cancel

C'est un type de déni de service lancé contre l'utilisateur, l'attaquant surveille l'activité du proxy SIP et attend qu'un appel arrive pour un utilisateur spécifique. Une fois que le dispositif de l'utilisateur reçoit la requête INVITE, l'attaquant envoie immédiatement une requête CANCEL. Cette requête produit une erreur sur le dispositif de l'appelé et annule l'appel. Ce type d'attaque est employé pour interrompre la communication.

Attaque par la méthode BYE

L'attaque par la méthode du BYE est dirigée contre les usagers. L'attaquant génère un BYE et interrompt une conversation. Pour réaliser cette attaque, le pirate écoute le trafic et prend les informations nécessaires (comme par exemple le Call-Id, le From ou encore le To) pour générer un BYE frauduleux correspondant à la session qui est injecté sur le réseau. Le BYE n'étant pas authentifié, celui qui reçoit l'information l'exécute.

Attaques sur le serveur Register

Le serveur d'enregistrement lui-même est une source potentielle de déni de service pour les utilisateurs. En effet, ce serveur peut accepter des enregistrements de tous les dispositifs. Un nouvel enregistrement avec une «*» dans l'entête remplacera tous les précédents enregistrements pour ce dispositif. Les attaquants, de cette façon, peuvent supprimer l'enregistrement de quelques-uns des utilisateurs, ou tous, dans un domaine, empêchant ainsi ces utilisateurs d'être invités à de nouvelles sessions.

D’autres failles de sécurité au niveau des systèmes VOIP, peuvent être liées aux systèmes d’exploitation, aux logiciels clients ou à une méconnaissance du fonctionnement des protocoles. Nous allons dans les lignes qui suivent proposer quelques solutions permettant de combler les failles présentées ci-haut.

II. Sécurisation des systèmes VOIP

Pour corriger les différentes failles présentées ci-haut, nous avons opté pour les solutions suivantes :

52


Garantir l’intégrité et la confidentialité des échanges sur le réseau

La prévalence et la facilité de sniffer des paquets et d'autres techniques pour la capture des paquets IP sur un réseau pour la voix sur IP fait que, le chiffrement soit une nécessité pour la protection des personnes qui sont interconnectées.

Le protocole IPsec peut être utilisé pour protéger l'identité des deux points terminaux et protéger les données une fois que les paquets quittent le réseau local. Ceci peut être faisable par la mise en place d’un VPN (Virtual Private Network) qui est un réseau privé et virtuel. Ce réseau est dit privé car les informations qui y circulent sont confidentielles. Il existe plusieurs solutions permettant de mettre en place un VPN. Certaines sont gratuites (open) et d’autres propriétaires.

Une autre solution est d’utiliser le protocole SSL/TLS qui était utilisé au début pour sécuriser les protocoles de communication afin d’éviter l’échange des messages en clair. L'utilisation de SSL/TLS permet l'authentification mutuelle du serveur et du client, le chiffrement et la vérification de l'intégrité des connexions. SSL/TLS est constitué de deux sous-protocoles à savoir le protocole TLS Record et le protocole TLS Handshake. Le protocole TLS Record a pour but de chiffrer les connexions avec un algorithme symétrique, et de vérifier leur intégrité à l'aide d'une fonction de type HMAC. Le protocole TLS Handshake a pour rôle d'authentifier les deux parties, de leur permettre de négocier les algorithmes et les clés de session utilisées par le protocole TLS Record et de remonter des alertes. L'authentification peut avoir lieu à l'aide de certificats.

Cependant il faut choisir des UE supportant les protocoles de sécurité cités ci-haut.

Mettre en place un filtrage

Afin d’éviter les attaques de types DOS qui visent à rendre inaccessible les serveurs, il faut mettre en place une politique de filtrage afin de ne permettre que les trafics utiles et ignorer les autres. Cette politique peut être mise en place en ajoutant un firewall dans le réseau. Un firewall n’est qu’un système informatique qui sert à protéger les accès (entrée ou sortie) à un réseau local ou distant.

En mettant en place ce filtrage, on doit faire de telles sortes que toutes les requêtes ping vers les serveurs puissent échouer. Ceci permettra d’empêcher le déni de service (utilisant le protocole ICMP). Il faut aussi bloquer tous les ports

53


et n’autoriser que ceux utilisés par les protocoles de communications utilisés sur le réseau.

Pour mettre en place cette plateforme IMS, plusieurs solutions s’offrent à nous. Dans les lignes qui suivent, nous allons faire une étude comparative de ces solutions afin de faire un choix définitif pour l’implémentation.

54


Chapitre V : Etude comparative des solutions

Pour mettre en place un réseau IMS, on peut utiliser plusieurs solutions. Ces solutions peuvent être propriétaires ou open source. Dans ce chapitre, nous allons faire une étude comparative des ces solutions afin d’en retenir une pour la mise en place de notre plate-forme IMS.

I. Solutions

Les solutions IMS sont le plus souvent proposées par des équipementiers et permettent généralement d’insérer l’IMS dans une architecture NGN (Next Generation Network) déjà implémentée ou un réseau 3G/4G. Il est à noter qu’un réseau NGN a la même architecture que celle de l’IMS présentée en haut sauf que les blocs CSCF sont remplacés par des softswitchs. Il existe plusieurs solutions mais nous allons dans les lignes qui suivent présenter quelques-unes.

I.1 IMS AAA JUNIPER

Cette solution est proposée par JUNIPER. JUNIPER est une société américaine proposant des solutions d’interconnexion et de sécurité.

Le serveur IMS AAA de Juniper permet aux opérateurs mobiles (2G, 3G ou 4G) de supporter les technologies 3GPP WLAN afin d’assurer en collaboration avec la base de données (HSS ou HLR) l’authentification des abonnés.

Cette solution implémente les protocoles du type AAA (Authentification, Accounting, Authorization). Ces protocoles permettent généralement de gérer l’authentification, la facturation et l’autorisation des abonnés aux services. La figure ci-dessous montre l’architecture et le fonctionnement de la solution IMS AAA JUNIPER.

55


Figure II.2.1: Architecture de la solution IMS AAA de JUNIPER

L’avantage de cette solution est qu’elle supporte plusieurs protocoles dont radius, diameter, IP (IPV4 et IPV6), ipsec, TLS et TCP/UDP. La sécurité y est renforcée via l’utilisation de radius ou de diameter qui sont des protocoles AAA. Mais elle ne permet pas autant de simuler un cœur de réseau IMS.

IMS AAA JUNIPER (3GPP AAA Server sur la figure) s’interconnecte aux différents blocs (HSS, HLR, SLF, OCS ….) via des interfaces spécifiques qui supportent soit le protocole diameter ou le protocole raduis.

I.2 IMS par Ericsson

Ericsson est l’un des leaders du marché en termes de fourniture d’équipement des réseaux de télécommunication. Ainsi il propose plusieurs solutions permettant la migration vers l’IMS et l’une de ces solutions est : Ericsson Call Session Control Function (Ericsson CSCF).

La solution Ericsson CSCF permet d’introduire un cœur de réseau IMS. Ces blocs CSCF se chargeront des opérations de signalisation et permettront aussi d’authentifier ensemble avec le HSS les abonnés et leur position. Mise sur le marché depuis 2015, cette solution favorise la convergence et dispose d’une

56


bonne interopérabilité. Elle offre également une grande flexibilité, prend en charge une grande variété de procédure d’authentification, et fournit une haute disponibilité. Elle offre également des possibilités de tarification souples pour soutenir de nombreux modèles de trafic, y compris post-payé, prépayé, basé sur le volume, l'heure, par événement, etc.

I.3 OpenIMSCore

La plateforme OPENIMSCORE contient les fonctionnalités de base d’un serveur SIP. Elle a été conçue de façon modulaire et est composée d’un noyau fortement efficace responsable de la réception, de l’analyse SIP et des routages des messages. L'OpenIMSCore est une implémentation des Call Session Control Functions (CSCFs) et du HSS (Home Subscriber Server), qui forment ensemble le réseau coeur des architectures IMS comme spécifié par le 3GPP, le 3GPP2, l'ETSI et TISPAN. Les CSCF sont essentiellement le P-CSCF, l’I-CSCF, et le S-CSCF. L’architecture d’OpenIMSCore est présentée sur la figure ci-dessous :

Figure II.2.2: Architecture OpenIMSCore

57


II. Etude comparative et Choix de la solution

Les solutions présentées ci-haut ne sont pas les seules permettant la migration vers IMS mais sont les plus utilisées. Cependant certaines sont propriétaires tandis que d’autres sont libres.

Le tableau qui suit, fait une étude comparative de ces différentes solutions afin de faire sortir leurs points forts et faibles et nous permettre de retenir un seul candidat pour la mise en place de la plateforme.

Solutions Protocoles supportés

Accessibilité Niveau de Sécurité

flexibilité

IMS-AAA-JUNIPER

TCP, UDP, Diameter, Raduis, IP, SSL/TLS, IPSec

Requiert une Licence car c’est un produit propriétaire

Elevé grâce à l’utilisation de l’AAA (Authentification, Authorization, Accounting)

Bonne

Ericsson CSCF TCP, UDP, Diameter, IP, SIP, SSL/TLS, IPSec

Requiert une Licence car c’est un produit propriétaire

sécurité standard de l’IMS. Procédure AKA pour l’authentification

Bonne

OpenIMSCore TCP, UDP, Diameter, IP, SIP, SSL/TLS, IPSec, RTP, RTSP

Produit Open Source (Libre)

sécurité standard de l’IMS. Procédure AKA pour l’authentification

Bonne

Tableau II.3 : Etude comparative des solutions

58


Le tableau ci-dessus montre les différentes caractéristiques des solutions permettant la mise en place de l’IMS. Cependant, on se rend compte que toutes les solutions ont des caractéristiques acceptables et faire un choix définitif serait un peu difficile. Mais compte tenu de nos moyens et de l’environnement de notre travail, nous avons opté pour la solution OpenIMSCore.

Cette solution a beaucoup retenu notre attention pour les raisons suivantes :

Elle a un noyau open source qu’on peut modifier selon nos besoins ; Elle peut s’interconnecter avec plusieurs types de base de données

(Mysql, Oracle…) faisant office de HSS ; Elle supporte plusieurs protocoles de communications ; Elle a une bonne flexibilité… Avec la présence des blocs CSCF, elle permet de simuler au mieux un cœur

de réseau IMS

Ainsi dans la suite, nous allons passer à la mise en place de la plateforme.

59


Partie III : Implémentation

60


Chapitre VI : Mise en place de la solution OpenIMSCore

Dans ce chapitre, nous allons parler de la mise en place de notre plateforme, des outils utilisés et des tests de fonctionnement.

I. Architecture de la plateforme

La plateforme s’articulera autour de l’architecture suivante :

Figure III.1: Architecture de déploiement

Hormis les blocs CSCF (P-CSCF, S-CSCF, I-CSCF) et la base de donnée HSS que nous avons présenté dans les paragraphes précédentes, on a inséré dans l’architecture un serveur DNS, deux serveurs d’applications et un pare-feu.

Le serveur DNS nous permet de faire de la résolution des noms. Pour des raisons de performance liées à nos équipements, nous avons implémenté ce service sur le même serveur où est implémenté OpenIMCore.

61


Le pare-feu nous permettra de mettre en place une bonne politique de sécurité afin de faire face aux attaques provenant de l’extérieur. Ces politiques serviront à protéger notre réseau local des utilisateurs malveillants. Nous avons utilisé un pare-feu de l’équipementier FORTIGATE pour sa robustesse et sa bonne résistance aux attaques.

Pour mettre en exergue la capacité de l’IMS à intégrer des services à valeurs ajoutés, nous avons introduit dans notre architecture deux serveurs d’applications (Serveur de présence et serveur IPTV). Ces deux serveurs permettront respectivement aux utilisateurs du réseau d’avoir des services de présence et de faire de l’iptv (la télévision sur IP).

Mais avant de passer à l’implémentation proprement dite, il est important de présenter le fonctionnement des serveurs d’application (serveur de présence et messagerie) que nous avons dans l’architecture ci-haut.

II. Diagrammes de fonctionnement

II.1 Serveur de présence

Le serveur de présence permet en général à un utilisateur de connaitre tous ces contacts qui sont en ligne (Connectés). L’exemple le plus simple est illustré sur facebook. Tous les utilisateurs connectés ont un point vert devant leur nom. Ceci permet généralement l’utilisation de la messagerie instantanée. Dans une architecture IMS, le fonctionnement d’un serveur de présence est illustré par la figure ci-dessous :

Figure III.2: Diagramme de fonctionnement d’un serveur de présence

62


Sur le diagramme, on deux utilisateurs Joan et Alice qui sont connectés. Pour connaitre l’état de Joan, Alice envoie une requête SIP SUBSCRIBE afin de souscrire dans un premier au service de présence (étape 1 à 4).

Le serveur de présence à son tour envoi à Alice un message SIP NOTIFY pour l’informer de son nouveau état (étape 5 à 8).

Joan à son tour ayant déjà souscris au service de présence, envoi son état par un message du type SIP PUBLISH au serveur de présence (étape 9 à 12).

Ayant connaissance de l’état de Joan, le serveur de présence informe Alice par un message du type SIP NOTIFY (étape 13 à 16).

II.2 Serveur de messagerie

Le service de messagerie instantanée est implémenté automatiquement dans openIMSCore. Il permet aux utilisateurs connectés de s’envoyer des messages et d’échanger de manière interactive.

Le fonctionnement d’un serveur de messagerie instantanée est très simple car il ne fait pas appel à beaucoup de méthodes sip comme le serveur de présence.

Les deux méthodes sip auxquelles le service fait appels sont : message et 200 OK.

La méthode message est utilisée pour l’envoi des messages instantanés, et 200 OK pour l’acquittement de la réception.

Ci-dessous, nous avons le diagramme de fonctionnement de la messagerie instantanée d’OpenIMSCore :

63


Figure III.3: Diagramme de fonctionnement de la messagerie

La figure ci-dessus décrit un scénario d’envoi de message entre deux utilisateurs (Joan et Alice). L’expéditeur du message est Joan et Alice est le récepteur.

De l’étape 1 et 2, Joan envoie un message à Alice.

De l’étape 3 à 4, Alice envoie un accusé de réception à Joan afin de l’indiquer que le message a été bien reçu.

III. Installation et configuration d’OpenIMSCore

L’installation d’openIMSCore requiert quelques logiciels et ressources matérielles comme dépendances.

III.1 Les prérequis

Pour installer openIMSCore, certaines dépendances sont requises.

La configuration matérielle doit au moins respecter les exigences suivantes :

Une machine Linux Opérationnelle (Avec un système Ubuntu dans notre Cas) ;

64


Environ 100 à 150 Mo d’espace libre sur le disque de la machine ; De préférence 1Go de RAM Un serveur DNS configurable préinstallé ; Un accès internet est requis pour l’installation des paquets ;

En ce qui concerne les prérequis logiciels, nous aurons besoin des paquets suivants :

SVN pour la récupération des packages sources d’openIMSCore ;

GCC3/4, make, ant pour la compilation ; Flex, bison comme analyseur lexical et syntaxique ; JDK pour simuler une machine virtuelle java ; Les paquets libmysql, libmysql-dev, libxml2, curl, libcurl4-gnutls-dev et libxml2-dev sont aussi nécessaires ;

Le paquet ipsec-tools, openssl sont utiles pour la sécurité ; Les paquets mysql-server et binnd9 serviront respectivement de base de données et de serveur DNS ;

Vu que nous avons utilisé un système ubuntu (version 15), tous les paquets précités vont s’installer en utilisant la commande apt-get install « nom du paquet ».

Une fois toutes les dépendances satisfaites, nous pourrons passer à l’installation d’openIMSCore.

III.2 Installation OpenIMSCore

Pour installer openIMSCore, nous allons d’abord récupérer les codes sources. Ces codes sources peuvent être récupérés en allant sur ce lien https://sourceforge.net/p/openimscore/code. Mais nous allons ici les récupérer en utilisant l’interface console.

Ainsi avant de récupérer les paquets, nous devons dans un premier temps créer un répertoire dans lequel nous allons mettre les paquets. Ceci se fait en utilisant la commande :

mkdir /opt/OpenIMSCore

Après la création, on se déplace dans le nouveau répertoire afin de créer deux autres répertoires à l’intérieur :

65


cd /opt/OpenIMSCore

mkdir ser_ims

mkdir FHoSS

Les deux répertoires crées serviront respectivement à contenir les paquets nécessaires pour l’installation des blocs CSCFs (P-CSCF, I-CSCF, S-CSCF) (répertoire ser_ims) et la base de données HSS (FHoSS).

Pour récupérer les codes sources des paquets qui concernent les blocs CSCFs, on

se rend dans le répertoire /opt/OpenIMSCore et on exécute via l’interface

console la commande suivantes :

svn checkout https://svn.code.sf.net/p/openimscore/code/ser_ims/trunk ser_ims

En restant toujours dans le répertoire /opt/OpenIMSCore, nous allons récupérer les paquets responsable de la mise en place de la base de données HSS. Ceci se fait en utilisant la commande suivante :

svn checkout https://svn.code.sf.net/p/openimscore/code/FHoSS/trunk FHoSS

Après la récupération des codes sources, nous devons maintenant passer à la compilation de ces codes. Pour la compilation, nous allons nous rendre dans le répertoire /opt/OpenIMSCore/ser_ims et taper la commande suivante :

make install-libs all

Cette commande permet de mettre en place les différents blocs CSCF à savoir P-CSCF, I-CSCF, S-CSCF. Il ne reste plus qu’à les configurer.

Une autre compilation est celle de la base de données HSS. Pour cela, il faut se rendre dans le répertoire /opt/OpenIMSCore/FHoSS et exécuter les commandes suivantes :

ant compile

ant deploy

Mais avant la compilation du HSS, il faut s’assurer que JDK est installé et que la variable d’environnement pointe vers le bon répertoire.

66


III.3 Configuration d’openimscore

La configuration d’openIMSCore consistera essentiellement à configurer les serveurs DNS, Mysql et de renseigner les paramètres au niveau des fichiers de configurations des blocs CSCF et du HSS.

La configuration complète est décrite à l’annexe1 du document.

Après la configuration, nous pouvons maintenant démarrer le serveur. Les captures ci-dessous illustrent le demarrage des différents blocs CSCFs.

Démarrage p-cscf

Démarrage S-CSCF

Démarrage I-CSCF

67


Démarrage FHoSS

Après installation et configuration, nous allons passer à la mise en place des serveurs d’application et de la sécurisation de la plateforme.

68


Chapitre VII : Mise en place des serveurs d’applications et sécurisation de la

plateforme

I. Les serveurs d’applications

Dans cette section, nous allons voir comment installer les serveurs d’applications

et les intégrer dans OpenIMSCore. Ces serveurs d’applications seront

principalement :

Un serveur de présence ;

Un serveur VOD (Vidéo à la demande) ;

Un serveur IPTV ;

I.1 Mise en place du serveur de présence

La mise en place du serveur de présence se fait en utilisant OpenSIPS qui est une

implémentation open source d’un serveur SIP. Il est la continuité du projet

OpenSER. OpenSIPS est basé sur des modules, c’est-à-dire que pour chaque

fonctionnalité, il suffit de télécharger le module nécessaire et de l’intégrer au

serveur. Les fonctionnalités d’opensips sont nombreuses, mais celle qui nous

intéresse pour l’instant est le serveur de présence.

Installation des dépendances

Ainsi pour mettre en place le serveur de présence, il faut d’abord installer les

prérequis nécessaires. Ces prérequis sont les suivants :

libconfuse0 libconfuse-dev libxmlrpc-c3 libxmlrpc-c3-dev libxml2 libncurses5-dev m4 libmysqlclient & libz(zlib) libsctp1 openssl tar sed & tr make flex bison gcc libperl mysql-server

Plusieurs moyens peuvent être utilisés pour l’installation des paquets, soit

l'utilisation d'un gestionnaire de fichier graphique (synaptic) ou la ligne de

commande.

69


Il est à noter que nous avons installé le serveur de présence sur une machine

virtuelle doté d’un système d’exploitation linux (debian7), de 1GB de RAM et

ayant une capacité de 20GB.

Installation et Configuration d’OPenSIPS (Voir annexe2)

Avant d’installer le paquet, il faut d’abord le télécharger. Une fois téléchargé, on

le décompresse dans un répertoire de notre choix.

Après la décompression, on peut maintenant procéder à installation.

L’installation complète et la configuration sont décrites à l’annexe2 du

document.

Le paquet opensips peut être téléchargé en utilisant le lien suivant :

http://opensips.org/pub/opensips/1.5.0/src/opensips-1.5.0-notls_src.tar.gz

Après installation et configuration, il faut démarrer le serveur. Si toutes les

configurations sont bonnes, on doit avoir un résultat similaire à la capture

suivante :

I.2 Mise en place du serveur de streaming (Annexe3)

Pour la mise en place du serveur de streaming, on a utilisé un serveur VLC.

L’installation et la configuration sont décrites à l’annexe 3 du document.

I.3 Mise en place d’un serveur IPTV

Installation

Pour mettre en place le serveur IPTV, il faut d’abord installer les prérequis

nécessaires. Ces prérequis sont :

Libosip2-2

Libosip2-dev

Libexosip2-4

Libexosip2-dev

Ces paquets s’installent en utilisant l’interface console.

70


Il est à noter que nous avons installé ce serveur sur une machine virtuelle linux.

Après l’installation des prérequis, il faut télécharger le paquet uctiptv_advanced

en utilisant la commande suivante :

Après téléchargement, on peut maintenant installer le paquet en exécutant la

commande suivante en tant que root :

dpkg –i uctiptv_advanced1.0.0.deb

Configuration et intégration du serveur IPTV dans OpenIMSCore

Une fois le serveur en place, on peut le configurer et l’intégrer dans

OpenIMSCore.

La configuration du serveur se fait en éditant le fichier key_value. Dans ce fichier,

nous allons faire une correspondance entre les noms des médias et leur

emplacement sur le serveur de streaming (adresse rstp vers le serveur de

streaming). Dans notre cas, nous avons ajouté deux correspondances comme le

montre la capture suivante :

Le serveur de media ici est iptv.herdo.net.

71


Après configuration, on peut maintenant l’intégrer dans OpenIMSCore. Pour

cela, il faut acceder à l’interface web du FHoSS et insérer le serveur d’application

comme suit :

Nous avons créé un serveur d’application

Création du trigger point.

72


Et pour finir, nous allons créer l’IFC comme suit :

Après avoir mis en place les serveurs d’applications, nous allons passer à la

sécurisation de la plateforme.

II. Sécurisation de la plateforme

Etant conscient qu’il n’existe aucune politique de sécurité parfaite, nous allons

ici mettre en place une politique nous permettant de garantir l’intégrité et la

confidentialité des données échangées entre les utilisateurs. Afin d’éviter les

dénis de service (DOS). Pour cela nous allons utiliser un pare-feu de

l’équipementier FORTIGATE que nous allons placer à la périphérie de notre

réseau.

II.1 Mise en place de la politique de filtrage

En mettant en place cette politique, nous allons bloquer tous les ports inutilisés

et n’autoriser que ceux que nos protocoles de communication utilisent. Nous

allons aussi bloquer quelques types de DOS connus afin de protéger notre

serveur. Pour cela, on se connecte à notre pare-feu en utilisant l’interface web

comme le montre la capture suivante :

73


Après connexion, on se rend sur l’onglet policy afin de mettre en place les

politiques de communications entre les différents ports.

Une fois sur l’onglet policy, on choisit Create New afin de créér une nouvelle

politique de communication. Etant un pare-feu, chaque port appartient à un

réseau différént et la communication entre ces différents réseaux est par défaut

bloquée bien qu’ils sont directement connectés. La création de la politique de

communication se fait comme suit :

74


Ici on a précisé le type de policy qui est firewall, les interfaces d’entrée et de

sortie, les adresses sources et de destination, la plage de temps durant laquelle

on doit appliquer la politique (tout le temps), et les services concernés.

En ce qui concerne l’action à mener, on a choisi « ACCEPT ». Ce qui permettra de

laisser passer les services précisés et de bloquer tous les autres.

Ici nous avons autorisé les services SIP pour la signalisation, RTSP pour le

transport des flux de données et DNS pour la résolution des noms.

Mais vu que le P-CSCF au niveau d’OpenIMSCore utilise le port 4060, il faut

changer le port du service SIP au niveau de notre firewall car c’est le port par

défaut qui est utilisé. Ceci est illustré par la capture qui suit :

On se rend au niveau de l’onglet « Firewall Objects », on clique sur service et

éditer le service SIP afin de remplacer le port par défaut (5060) par 4060.

75


Pour éviter les dénis de services, on a procédé comme suit :

Dans l’onglet policy, on clique DOS Policy qui permet de mettre en place une

politique de sécurité contre le déni de services. Fortigate a répertorié les types

de DOS les plus courants et a développé une politique de sécurité afin de les

bloquer. Pour créer une politique, on clique sur « Create New ». Ceci est illustré

par la capture suivante :

76


Ici, on a choisi de bloquer tous les attaques de types DOS répertoriées sur la

capture ci-dessous.

Maintenant nous allons passer à la mise en place d’une technique nous

permettant de garantir la confidentialité des données. Pour cela, nous allons

utiliser TLS.

II.1 Mise en place de la sécurité avec TLS

TLS est un protocole de sécurisation des données utilisé sur internet. Il

fonctionne en mode client-serveur et son implémentation nous permettra

d’assurer les fonctions de confidentialités, d’authentification du serveur et

d’intégrité des données. Ainsi pour l’implémentation nous devons d’abord

installer le paquet openssl sur le serveur où est implémenté notre OpenIMSCore

comme suit :

apt-get install openssl

Après installation d’openssl, nous pouvons maintenant faire la configuration. Se

référer à l’annexe4 pour la configuration.

Voici la capture d’écran du P-CSCF après la mise en place de la sécurité TLS.

77


Sur cette capture, on remarque que la configuration de TLS est bien faite.

III. Test de fonctionnement des services

Dans cette section, nous allons présenter le résultat des tests effectués.

III.1 Test d’enregistrement

Pour l’enregistrement d’un abonné IMS, il faut d’abord configurer le client. Nous

devons faire cette configuration en utilisant les comptes existants au niveau du

HSS. Dans notre cas, nous avons trois comptes au niveau du HSS. Ces trois

comptes sont illustrés sur les captures suivantes :

Sur les captures, on remarque que les abonnés ne sont pas encore enregistrés et

par conséquent, ne sont rattachés à aucun S-CSCSF.

Nous avons utilisé un client myMonster pour l’enregistrement. Sa configuration

se fait comme suit :

78


Une écoute du trafic avec wireshark montre les différentes méthodes SIP

utilisées pour l’enregistrement.

Après Enregistrement de tous les abonnés, leur statut au niveau du HSS doit

changer comme suit :

79


III.2 Test du serveur de présence

Après enregistrement, on a fait tester le serveur de présence. Le résultat est

illustré par la capture suivante :

Sur la capture, le point vert signifie que l’utilisateur est connecté et le point gris

signifie qu’il n’est pas en ligne. Ainsi dans la liste de contact d’Alice, elle a deux

utilisateurs dont un est en ligne et l’autre hors ligne.

III.3 Test de la messagerie instantanée

Le test concernant la messagerie est illustré par les captures suivantes :

80


Sur ces captures, on a un échange entre deux utilisateurs (Alice et Hermann). On

remarque que la messagerie instantanée marche.

III.4 Test du serveur IPTV

Pour tester le serveur iptv, nous avons utilisé le client UCT IMS. Les captures ci-

dessous montrent que le service IPTV marche :

81


III.4 Test d’appel

82


Les captures ci-dessous montrent que les appels (vocaux ou vidéo) marchent

bien. Nous avons utilisé un client BogheIMS pour ce test.

En somme, dans ce chapitre, nous avons mis en place un serveur de présence,

un serveur iptv, une politique de sécurité et effectué les tests qui vont avec.

83


Conclusion

En sommes nous pouvons retenir que l’IMS de nos jours est perçu par beaucoup

d’expert en télécommunication et informatique comme étant une des clés vers

la convergence des réseaux fixes et mobiles, informatiques et télécoms. De ce

fait, il a une valeur capitale pour les opérateurs car il ouvre la voie à la libre

concurrence et permet à ces derniers de fructifier leur chiffre d’affaire en créant

des services à valeurs ajoutées.

La réalisation de ce travail nous a permis de mettre en exergue nos

connaissances théoriques acquises en classe et de comprendre l’architecture et

le fonctionnement d’IMS. En plus de cette compréhension, l’outil OpenIMSCore

nous a permis de simuler un cœur de réseau IMS et d’intégrer quelques services

à valeurs ajoutées.

Nous avons également grâce à ce travail, acquis des connaissances sur les

différents types d’attaques informatiques que peuvent subir les systèmes VOIP.

Par la suite, pour éviter ces attaques, on a intégré un pare-feu dans le réseau afin

de lutter contre les attaques venant de l’extérieur.

Pour garantir l’intégrité des données, nous avons utilisé TLS qui permet de

sécuriser la couche transport afin que les données qui y circulent ne soient pas

lues par de tierces personnes.

Cependant, l’IMS reste un sujet d’actualités qui peut être traité suivant plusieurs

contextes. Certaines perspectives peuvent s’orienter dans le sens d’intégrer

d’autre services afin de gérer la facturation par exemple. Ceci peut être fait en

couplant OpenIMSCore et mobicents. On peut aussi travailler dans le sens de le

coupler avec asterisk ou medooze. Medooze permettra de faire de la vidéo-

conférence.

84


Bibliographie

[1] Claude Severin « Réseau et Télécoms » 4ième édition Consulté le 10 Mai 2015 ;

[2] WILEY «THE IMS IP MULTIMEDIA CONCEPTS AND SERVICES » THIRD EDITION

Consulté le 25 Juillet 2015;

[3] Abd-Elhamid M, Najah Abu Ali, Hossam Hassanein « LTE, LTE-ADVANCED AND WiMAX » Consulté le 10 Aout 2015; [5] Cours de M. AW : Les Réseaux NGN. Année académique 2014-2015 ; [6] Cours de M. AW : Evolution des réseaux Année académique 2013-2014 ; Webographie [1] http://www.openimscore.org/ Consulté le 10 Juin 2015 ; [2] http://www.openimscore.org/documentation/installation-guide/ Consulté le 20 Juin 2015 ; [3] http://www.ims-way.com/2011/04/open-ims-first-install/ Consulté le 30 Juin 2015 ; [4] https://sites.google.com/site/haninemati/developing-ims/installing-openimscore-on-ubunto-12-04 Consulté le 30 Juin 2015 ; [6] http://www.ims-way.com/2011/05/install-iptv-server/ Consulté le 15 Juillet 2015 ; [7] http://www.efort.com/r_tutoriels/NGN_EFORT.pdf Consulté le 10 Juin 2015 ; [8] http://www.efort.com/r_tutoriels/SIP_EFORT.pdf Consulté le 20 Juin 2015 ; [9] http://www.efort.com/r_tutoriels/DIAMETER_EFORT.pdf Consulté le 30 Juillet 2015 ; [10] http://www.blog-des-telecoms.com/edito-securite-attaques-des-systemes-telephoniques-voip-ou-traditionnel/ Consulté le 30 Aout 2015 ; [11] https://www.clusif.asso.fr/fr/production/ouvrages/pdf/clusif-menaces-VoIP-2009-securite.pdf Consulté le 12 Septembre 2015 ; [12]http://www.nolot.eu/Download/Cours/reseaux/m2pro/SESY0708/securite_voip.pdf Consulté le 20 Septembre 2015 ;

http://www.openimscore.org/

http://www.openimscore.org/documentation/installation-guide/

http://www.ims-way.com/2011/04/open-ims-first-install/

https://sites.google.com/site/haninemati/developing-ims/installing-openimscore-on-ubunto-12-04

https://sites.google.com/site/haninemati/developing-ims/installing-openimscore-on-ubunto-12-04

http://www.ims-way.com/2011/05/install-iptv-server/

http://www.efort.com/r_tutoriels/NGN_EFORT.pdf

http://www.efort.com/r_tutoriels/SIP_EFORT.pdf

http://www.efort.com/r_tutoriels/DIAMETER_EFORT.pdf

http://www.blog-des-telecoms.com/edito-securite-attaques-des-systemes-telephoniques-voip-ou-traditionnel/

http://www.blog-des-telecoms.com/edito-securite-attaques-des-systemes-telephoniques-voip-ou-traditionnel/

https://www.clusif.asso.fr/fr/production/ouvrages/pdf/clusif-menaces-VoIP-2009-securite.pdf

https://www.clusif.asso.fr/fr/production/ouvrages/pdf/clusif-menaces-VoIP-2009-securite.pdf

http://www.nolot.eu/Download/Cours/reseaux/m2pro/SESY0708/securite_voip.pdf

http://www.nolot.eu/Download/Cours/reseaux/m2pro/SESY0708/securite_voip.pdf

85


ANNEXES

Annexe1 : Installation et configuration d’openIMSCore

Après installation de tous les prérequis, on peut passer à l’installation et la configuration d’OpenSer

I. Récupération des codes sources Le code source est configuré pour fonctionner selon un chemin de fichier standard. Créer le dossier /opt/OpenIMSCore/ et s’y rendre : # mkdir /opt/OpenIMSCore # cd /opt/OpenIMSCore Créer le dossier ser_ims et y placer les serveurs CSCF : # mkdir ser_ims

#svn co http://svn.berlios.de/svnroot/repos/openimscore/ser_ims/trunkser_ims

Créer le dossier FHoSS et y placer le serveur HSS : mkdir FHoSS

# svn co http://svn.berlios.de/svnroot/repos/openimscore/FHoSS/trunk FHoSS

II. Compilation

Compilation des serveurs p-cscf, i-cscf, s-cscf (ser_ims) :

# cd ser_ims

# make install-libs all

Note: Si une erreur survient lors de la compilation, c’est probablement qu’une dépendance est manquante.

Compilation du serveur FHoSS :

Un JDK >=1.5 doit être installé sur la machine. Pour s’en assurer :

# java -version

Compilation et déploiement :

# cd ../FHoSS

# ant compile

# ant deploy

86


III. Configuration de l’environnement DNS et Mysql

1. Configuration du DNS

OpenIMSCore vient par défaut avec un nom de domaine qui est open-ims.test.

Pour le modifier, on doit suivre les étapes qui suivent.

Se déplacer dans le répertoire /opt/OpenIMSCore/ser_ims/cfg et lancer le script

de configuration comme suit :

Se mettre dans le répertoire /opt/OpenIMSCore et exécuter les commandes

illustré par la capture suivante :

Se déplacer dans le répertoire /opt/OpenIMSCore/FHoSS/deploy/ et excécuter

les commandes suivantes :

Editer le fichier named.conf et insérer le nom du nouveau domaine

Test du DNS

87


2. Configuration de Mysql

Pour mettre en place la base de données, il faut se placer dans le répertoire /opt/OpenIMSCore et exécuter les commandes suivantes :

88


Annexe 2 : Installation et configuration d’openSIPS

Après installation de tous les prérequis, nous pouvons installer OpenSIPS

I. Installation

Nous devons d’abord télécharger le fichier opensips à l’adresse suivante :


Ensuite le décompresser dans un répertoire de notre choix en utilisant la comme suis :

# tar xvfz opensips-1.5.0-notls_src.tar.gz

Après decompression, se déplacer dans le nouveau répertoire et modifier la ligne 52 du fichier Makefile afin qu’elle soit similaire à la capture

Ensuite exécuter les commandes suivantes pour compiler et installer opensips

# make

# make install

Pour finir l’installation, copier les fichiers suivants :

# cp packaging/debian-etch/opensips.default /etc/default/opensips

# cp packaging/debian-etch/opensips.init /etc/init.d/opensips

II. Configuration du serveur de presence

Editer le fichier /etc/default/opensips et remplacer la ligne 6 par :

RUN_OPENSIPS=yes

Editer le fichier /etc/init.d/opensips et remplacer respectivement les lignes 19 et 25 par :

DAEMON=/usr/local/sbin/opensips

RUN_OPENSIPS=yes


89


Ajouter le droit d’exécution au fichier /etc/init.d/opensips

Chmod +x /etc/init.d/opensips

Créer un répertoire opensips

# mkdir /var/run/opensips

# chmod 777 /var/run/opensips

Editer le fichier /usr/local/etc/opensips/opensipsctlrc et décommenter les lignes suivantes:

Remplacer opensips.org par le nom du domaine. Dans notre cas, le domaine est herdo.net

Décommenter et modifier la ligne suivante

Editer le fichier /usr/local/etc/opesnsips/opensips.cfg . Commenter la lige 122 de ce fichier et modifier le port d’écoute du serveur à la ligne 54 par 5065. Décommenter les lignes suivantes

90


Nous avons indiqué l’adresse de notre serveur et le port d’écoute.

Toujours dans ce fichier, remplacer la fonction route par le code suivant :

Remplacer la fonction route[2] par le code suivant :

91


Exécutons la commande suivante afin d’initialiser la base de données :

# opensipsdbctl create

La capture suivante montre le démarrage du serveur de présence :

92


Annexe 3 : Mise en place du serveur de streaming

Pour mettre en place ce serveur, on a utilisé VLC. Nous devons dans un premier

faire l’installation. Elle se fait comme suit :

# apt-get install vlc

Après Nous devons configurer le serveur. Cette configurer se résume à l’ajout

des fichiers médias au serveur. Pour cela, nous devons dans un premier temps

démarrer le serveur et nous connecter en utilisant telnet afin d’ajouter les

fichiers médias. Les captures suivantes montrent comment démarrer le serveur

et comment ajouter des fichiers médias.

Démarrage du serveur

Connection au serveur en utilisant telnet

Ajout des médias au serveur

93


Vérification des médias

Test du serveur de streaming

Technology

Etude et mise en place d'un plateforme IMS Sécurisée