THÈSE l`ÉCOLE NATIONALE SUPÉRIEURE DES

N° d’ordre : 2009telb0144
THÈSE
Présentée à
l’ÉCOLE NATIONALE SUPÉRIEURE DES TÉLÉCOMMUNICATIONS
DE BRETAGNE
en habilitation conjointe avec l’Université de Bretagne Sud
pour obtenir le grade de
DOCTEUR de Télécom Bretagne
Mention « Sciences et Technologies de l’Information et de la Communication »
par
Abdallah HANDOURA
CRÉATION ET SÉCURISATION DES SERVICES TÉLÉCOMS FIXES
ET MOBILES SUR IP
Soutenue le 17 décembre 2009 devant la Commission d’Examen :
Composition du Jury
-
Rapporteurs
:
Noémie SIMONI, Professeur, Institut Telecom ParisTech - France
Bouabid El OUAHIDI, Professeur, Faculté des sciences de Rabat - Maroc
-
Examinateurs
:
Isabelle BORNE, Professeur, Université de Bretagne Sud - France
Julien BOURGEOIS, Professeur, Université Franche Comté - France
Serge GERLATI, Professeur, Institut Telecom Bretagne - France
Daniel BOURGET, Maitre de conférence, Institut Telecom Bretagne - France
Dédicace
A tous ceux qui me sont les plus chers : mon père, ma mère, mes sœurs et mes
frères.
A ma femme et mes enfants Mohamed et Mahmoud.
Abdallah Handoura
Remerciements
Au moment où je présente ce travail, il convient de rendre hommage à tous ceux et celles
qui m’ont apporté aide afin de mener cette thèse dont des meilleures conditions. Je voudrais
d’abord remercier tous les enseignants en particulier ceux du département Informatique ainsi que
tous les cadres, enseignants et administratifs à Telecom Bretagne.
Au terme de ce travail qui a nécessité le soutien de tous, je tiens à remercier et à exprimer
ma profonde gratitude à Monsieur Daniel Bourget, Maître de conférences à Telecom Bretagne, et
mon encadreur, qui n’a ménagé aucun effort lors de la réalisation de cette thèse à travers son
implication, son soutien, ses encouragements, ses conseils et orientations.
Mes remerciements sont adressés aussi à Monsieur Serge Garlatti, Professeur à Telecom
Bretagne, et Directeur de cette thèse, qui m’a conseillé efficacement tout en me laissant travailler
très librement. Pour cela, je lui suis très reconnaissant.
Mes profonds remerciements à Monsieur Bouabid El Ouahidi, Professeur à la faculté des
sciences de Rabat au Maroc et à Madame Noémie Simoni, Professeur à Telecom Paris Tech pour
avoir acceptés la lourde tâche d’être rapporteurs de cette thèse.
En outre, je remercie Monsieur Julien Bourgeois, Professeur à l’université de franche comté et
Madame Isabelle Borne, Professeur à l’université de Bretagne Sud, pour avoir accepté d’être
membres du jury de cette thèse.
Pour conclure, je garde une place toute particulière pour toute ma famille. Je les remercie pour
leur soutien de tous les instants.
Mes derniers remerciements vont à mon épouse Amany. Comment pourrais-je suffisamment la
remercier pour son amour sans limites, pour sa grande confiance, pour son constant
encouragement, pour ses idées remarquables, pour ses précieux conseils, pour ses remarques
pertinentes, pour ses différentes lectures avisées et commentées de mes travaux, pour sa patience
sur les différents dépassements que peut être j’ai fait.
Merci à tous…
Résumé :
L’évolution des réseaux intelligents vers les nouvelles générations de réseaux NGN (Next
Generation Network), nécessite des méthodes avancées permettant l’intégration des ser vices des
télécommunications de multi-operateurs et multi- fournisseurs sur un environnement distribué et
ouvert tel que IP, ainsi que la sécurisation des opérateurs et des services. Cette thèse entre dans ce
cadre : elle a été consacrée à l’interconnection des réseaux intelligents sur IP et sur les réseaux
télécoms (PSTN), à l’utilisation de la technologie des Web services pour la création et la
sécurisation des services télécoms, ainsi qu'à la sécurisation des services et des opérateurs pour
les terminaux fixes et mobiles.
Le premier axe de la thèse a abouti à l’élaboration des méthodes qui permettent
l’interconnection des réseaux intelligents sur IP, ainsi que la création des services à valeur
ajoutée avec la technologie des Web services, et ceci indépendamment des opérateurs classiques
des télécommunications.
Contrairement aux méthodes existantes, qui sont basées sur un nombre limité de services
indépendants appelés SIB (Service Independent building Block), et qui sont relatifs aux
différentes normes CS-n (Capability Set) des réseaux intelligents. Nos méthodes sont basées sur
une combinaison des aspects protocolaires et fonctionnels des protocoles SIP, TRIP et ENUM
pour assurer un scénario d’interconnection IP-IN-PSTN a fin d’intégrer les services intelligents
sur IP : nous avons employé le protocole de signalisation SIP et un module SIN (SIP-IN), qui
assure l’interconnexion de IN avec IP, le protocole de routage des paquets VoIP, TRIP
(Telephony Routing over IP) pour assurer le routage des requêtes des signalisations à travers les
différents serveurs de localisations LS ou Gateways, et enfin pour assurer une traduction des
adresses IP (DNS) en format E.164 (adresse PSTN) ou vise versa, nous avons proposé
l’utilisation de protocole ENUM (tElephony NUmbering Mapping).
Nous avons ensuite employé la technologie du Web service et du VoiceXML pour créer et
modifier des services à valeur ajoutée du réseau intelligent, en exploitant une combinaison entre
le protocole de transfert des données SOAP, qui permet de découvrir les URI des services, et le
protocole SIP ainsi que l’IMS au niveau du réseau mobile.
Le deuxième axe de la thèse a été consacré aux problèmes de la sécurité des opérateurs et des
services pour les terminaux fixes et mobiles dans une invocation d’un service intelligent. Cette
étude a abouti premièrement à l’identification des différents éléments dans le réseau intelligent
qui nécessitent de la sécurité, ainsi que les attaques potentielles. Deuxièmement, et pour faire
suite aux techniques présentées dans la première partie, nous avons employé la technique de
sécurité définie dans SIP, pour assurer la sécurisation de la requête de signalisation ainsi que les
outils de sécurités proposés par la technologie Web service, tels que WS-security et WSE pour la
sécurisation des opérateurs et des services sans oublier de présenté les différents paramètres
d’identification et d’authentification des utilisateurs, des opérateurs et des services.
Avec ces différents paramètres de sécurisation qui seront intégrés dans le message d’invocation
d’un service intelligent, s’ajoute celles nécessaires pour la sécurisation des requêtes entre les
différents domaines IMS des réseaux mobiles, ou nous proposons l’utilisation d’IPsec.
Abstract
The evolution of the intelligent network to the new generations network (NGN), necessitate
an advanced methods allowing the integration of telecommunication services of the multioperators and the multi-providers on an open and distributed environment such as IP, the
security of operators and services. This thesis has been devoted to interconnect the intelligent
network on IP and on telecommunication network (PSTN), to use the Web services
technologies for the creation and the security a telecommunication services, also to secure a
service and an operator for mobile station and terminal equipment.
The first axis of the thesis led to the elaboration of methods that allowed interconnect the
intelligent network over IP, as well as the creation of services to values added with the Web
service technologies independent of classic telecommunication operators,
Contrarily to the existent methods, which are based on a limited number of independent
services (SIB : Service Independent building Block) relative to the different norm CS-n
(Capability Set) of intelligent network, our methods are based on a combination of the formal
and functional aspect of SIP protocol, TRIP and ENUM for insure a scenario of
interconnected IP-IN-PSTN has fine to integrate intelligent services over IP : The protocol of
signaling, SIP and owing to a SIN (SIP-IN) module, that ensures the interconnection of IN
with IP, We have employed the routing protocol of VoIP Gateways, TRIP (Telephony
Routing over IP) to insure the routing of signaling requests through the different location
server LS or Gateways, and finally, and for insure a translation a IP address (DNS) in format
E.164 (PSTN address ) or the contrary, we have proposed the utilization, the ENUM protocol
(tElephony NUmbering Mapping).
We have then employed the technology of Web service and VoiceXML to create, modify a
service in the intelligent network, by exploiting a combination between the protocol of data
transfer SOAP, that allows to discovering URI of services and the SIP protocol and the IMS
for the mobile network.
The second axis of the thesis has been devoted to these problems of the operators and services
security for mobile and PSTN in an invocation of an intelligent service. This study firstly has
leaded to the identification of the different elements in the intelligent network that necessitates
the security, as well as the potential attack known possible. Secondly, to follow to these
techniques presented in the first part, we have employed the security technique defined in SIP,
to ensure the security in the signaling request, as well as the tool of securities proposed by the
Web services technologies, such as, WS-security, WSE, to secure the operator and service
without forgetting the different parameters presented in identification and authentication of
users, operators and services.
With these different parameters of security, which will be integrated in the message of
invocation of an intelligent service itself, is added that necessary for the security of requests
between the different IMS domains of mobile network, or we propose the use of IPsec.
Table des matières
Chapitre 1 : Contexte général ....................................................................................... 1
1.1 Introduction .......................................................................................................... 1
1.2 Problématique considérée ................................................................................... 4
1.3 Démarche proposée ............................................................................................. 5
Chapitre 2 : Outils des créations des services télécoms sur NGN ............................... 8
2.1 Introduction .......................................................................................................... 8
2.2 Les réseaux intelligents et ses limites .................................................................. 9
2.3 Le protocole SIP .................................................................................................. 11
2.4 Les concepts VHE et OSA.................................................................................... 13
2.4.1 VHE .......................................................................................................... 13
2.4.2 OSA .......................................................................................................... 14
2.5 L’IMS ou la convergence fixe mobile .................................................................. 16
2.5.1 Architecture IMS ..................................................................................... 16
2.5.1.1 Architecture de service IMS ..................................................... 19
2.5.1.2 Entités de l’architecture de service IMS................................... 19
2.5.2 Limitations de l”IMS ................................................................................ 21
2.6 Les Web services................................................................................................. 22
2.6.1 Le Protocole SOAP ................................................................................... 23
2.6.2 Les inconvénients SOAP .......................................................................... 24
2.7 Conclusion .......................................................................................................... 26
Chapitre 3 : Intégration des services télécoms sur IP avec SIP.................................. 27
3.1 Introduction ........................................................................................................ 27
3.2 Correspondance et intégration entre SIP et IN .................................................. 28
i
3.3 ENUM ou Correspondance DNS-E164 ................................................................ 31
3.4 Le Problème de localisation des Gateways ........................................................ 35
3.5 La Solution TRIP pour la localisation des Gateways ........................................... 37
3.6 Intégration des services télécoms sur IP avec SIP .............................................. 42
3.7 Conclusion .......................................................................................................... 44
Chapitre 4 : Création des services télécoms avec Web services ............................... 45
4.1 Introduction ........................................................................................................ 45
4.2 Combinaison du SIP avec SOAP .......................................................................... 45
4.3 Architecture existantes à base de Web services ................................................ 48
4.3.1 IBM Web service Services Server ............................................................ 49
4.3.2 IMS-SOAP Gateway ................................................................................. 50
4.3.3 Mobile Web services ............................................................................... 51
4.4 Les solutions proposées ..................................................................................... 56
4.4.1 Accès à des bases de données hétérogènes ........................................... 56
4.4.2 Accès vocale avec VoiceXML ................................................................... 58
4.4.3 Solutions pour les réseaux mobiles......................................................... 62
4.5 Conclusion .......................................................................................................... 70
Chapitre 5 : Sécurité des services télécoms .............................................................. 71
5.1 Introduction ........................................................................................................ 71
5.2 Les Paramètres de sécurité sur les services du réseau intelligent ..................... 72
5.3 Les techniques de sécurité existantes sur les réseaux mobiles ......................... 74
5.3.1 GSM/GPRS ............................................................................................... 74
5.3.2 UMTS ....................................................................................................... 77
5.4 Les Outils proposés pour la sécurisation des services télécoms ........................ 79
5.4.1 Les Mécanismes de la sécurité SIP .......................................................... 79
5.4.2 Les Mécanismes de la sécurité avec les Web services............................ 82
5.4.2.1 Architecture de WSE................................................................. 83
ii
5.4.2.2 WS-Security .............................................................................. 83
5.4.3 Sécurité de média.................................................................................... 85
5.5 Implantation de la sécurisation des services télécoms au niveau domaine ...... 86
5.6 Implantation de la sécurisation des services télécoms entre domaines ........... 89
5.6.1 La Solution existante ............................................................................... 90
5.4.2 La Solution proposée............................................................................... 93
5.7 Conclusion ......................................................................................................... 95
Chapitre 6 : Conclusion générale ................................................................................ 97
6.1 Conclusion .......................................................................................................... 97
6.2 Perspectives........................................................................................................ 98
Bibliographie................................................................................................................ 99
Liste des figures
Liste des abréviations
Liste des Publications
Synthèse de la thèse
iii
Chapitre 1
Contexte général
Résumé du contenu
1.1. Introduction
1.2. Problématique considérée
1.3. Démarche proposée
1.1 Introduction
La mise en œuvre des réseaux de prochaine génération (NGN : Next Generation
Networks), utilisant le protocole Internet (IP) pour acheminer des services téléphoniques
fixes, sans fil et mobiles, des images et des données, devrait ouvrir le champ des possibilités
aux consommateurs. En effet, les consommateurs veulent des systèmes de facturation qui
soient plus simples et qui prennent en compte tous les services qu’ils reçoivent par le réseau;
ils veulent aussi des services plus personnalisés et de meilleure qualité. La demande est
alimentée également par l’augmentation des communications transfrontalières, de la part des
particuliers comme des entreprises, d’où la nécessité de services téléphoniques et de services
de transmission de données sécurisés, hautement performants et largement disponibles. Les
entreprises ainsi que les utilisateurs souhaitent, en plus, des services novateurs et des réseaux
intelligents, dont les capacités de sécurité et de stockage permettront une meilleure intégration
des systèmes réseaux et d’information. Une des raisons qui incitent les opérateurs à passer aux
réseaux NGN est la concurrence croissante à laquelle ils ont à faire face sur les marchés tant
anciens que nouvellement libéralisés; la baisse des recettes qu’ils tirent des communications
téléphoniques (et la multiplicité des réseaux pouvant les acheminer par la technologie du
VoIP) amène les opérateurs à opter pour une architecture fondée entièrement sur le protocole
IP. Les opérateurs traditionnels de lignes fixes ont, en général, été les premiers à s’implanter
sur le marché de l’accès à l’Internet large bande utilisant la technologie des lignes d’abonnés
numériques (DSL), mais aujourd’hui ils doivent faire face à la concurrence des opérateurs
mobiles, des nouveaux fournisseurs de services VoIP ainsi qu’aux services à valeur ajouté.
Dans ce nouveau contexte, le service de télécommunication est devenu une application
informatique s’exécutant sur des environnements et sur des composants hétérogènes. Ce
contexte vise à permettre, dans un réseau de communication, la coexistence de
communications hétérogènes aussi bien en termes de contenus qu'en termes de contraintes de
transmission. Au niveau du réseau de télécommunication, les nœuds du réseau PSTN sont
répartis et échangent entre eux, au moyen du système de signalisation SS7 (Signalisation
System 7), un minimum réduit d’information. Au niveau informatique, deux grandes
approches de la VoIP sont standardisées ; l'une issue de l'International Telecommunication
1
Union (ITU) et dont les diverses composantes sont regroupées sous l'appellation H.323 ;
l'autre proposée par la communauté Internet au travers de l'Internet Engineering Task Force
(IETF), regroupée sous le nom du système SIP. Ces deux approches ont en commun la
définition d’une procédure de signalisation permettant l'établissement, le contrôle et le
relâchement d'appels téléphoniques avec ou sans extensions multimédias. Ces deux approches
facilitent l'intégration des communications de type téléphonique au sein des services variés en
émergeant l’Internet comme réseau de transport de données multimédia et comme plateforme
de développement d’applications, et des services de télécommunication. Or au niveau système
d’information, chaque entité communiquant doit ouvrir son système d’information vers les
autres systèmes qui peuvent être distants ou multisites. Cette ouverture requiert une forte
maitrise de l’architecture aussi bien fonctionnelle que technique, ainsi qu’une volonté
d’intégration des systèmes d’information distants et hétérogènes.
Des différentes approches permettent l’intégration des systèmes d’information.
Toutefois, lorsque les communications entre applications dépassent le cadre du point à point
et lorsque les échanges deviennent complexes entre systèmes souvent hétérogènes, les
mécanismes d’intégration existants n’apportent plus une réponse à cette problématique. Il
devient alors nécessaire de proposer un nouveau modèle de collaboration offrant une
interopérabilité entre les systemes d’information. C’est là l’objectif des architectures
orientées services (SOA : Service Oriented Architecture), qui aujourd’hui avec les Web
services bénéficient d’un socle technologique favorisant leur avènement.
L’architecture des services Web définit des méthodes standards pour créer des
systèmes orientés vers les services, dynamiques et faiblement couplés. L’arc hitecture orientée
vers les services, offre un modèle de programmation standard qui permet, à des composants
logiciels développés séparément, d’être publiés, identifiés et invoqués les uns à l’aide des
autres[34]. Ces composants peuvent résider sur un même réseau ou sur des réseaux distincts.
Il s'agit d'une technologie permettant à des applications de dialoguer à distance via Internet, et
ceci indépendamment des plateformes et des langages sur lesquelles elles reposent. Pour faire
cela, les services Web s'appuient sur un ensemble de protocoles standardisant les modes
d'invocation mutuels de composants applicatifs. Les services Web, sont donc des races
d'applications nouvelles du Web. Ils sont indépendants et décrivent des applications
modulaires qui peuvent être publiées, situées et invoquées à travers le Web. Les services Web
exécutent des fonctions qui peuvent être des requêtes simples ou des processus compliqués. Il
sera important par conséquent d’exploiter cette technologie pour l’intégration des services à
valeur ajoutée via les protocoles de signalisations SIP ou H.323 sur la plateforme Internet.
Pour faire cela il faut tout d’abord élaborer une architecture ouverte autour des réseaux
intelligents permettant la création des services indépendamment des réseaux et des accès
empruntés.
Aujourd’hui, avec l’apparition des nouveaux réseaux d’accès (UMTS, xDSL, WLAN,
Ethernet longue distance) et leur convergence vers un réseau cœur tout IP, le développement
de l’Internet et de ses applications, l’hétérogénéité des terminaux communicants (téléphone
mobile, GPRS/UMTS, PDA…) adaptables et portables et l’augmentation des utilisateurs
mobiles, les demandes des clients pour accéder à un ensemble riche de services avec une
certaine qualité de service deviennent de plus en plus exigeantes. C’est ainsi que le groupe
3GPP dans ses spécifications a défini l’interface OSA (Open Service Access). Cette interface
permet à un fournisseur de services l’accès à l’architecture UMTS tout en introduisant le
concept de la portabilité des services par l’intermédiaire du VHE (Virtual Home
2
Environment). En effet, grâce au VHE, les utilisateurs pourront retrouver leurs services avec
la même ergonomie quel que soit le réseau d’accès ou le terminal utilisé.
En fait la release 4 et la release 5 définies par le 3GPP ont conduit à la convergence du
réseau cœur vers le tout IP grâce à l'introduction de nouveaux éléments tels que le sous
système multimédia (IMS), les serveurs (CSCF, MGCF) et les média gateways (MG) dans
l'architecture du réseau cœur UMTS. Ainsi, avec l'apparition des nouveaux réseaux d'accès,
l'hétérogénéité des terminaux communicants, la grande mobilité des utilisateurs, et la
convergence des réseaux d'accès vers un réseau tout IP, il sera nécessaire de déployer des
nouvelles architectures des plateformes de services pour faire le lien entre les fournisseurs de
services et les utilisateurs mobiles connectés au réseau.
L'IMS inter-réagit avec tous types de réseaux (fixe, mobile ou sans fil), incluant les
fonctions de commutations de paquets et de circuits. Les systèmes les plus anciens de
commutation de circuit (POTS, GSM) sont aussi supportés grâce à des passerelles
(Gateways). Des interfaces ouvertes entre les couches de contrôle et de service, permettent de
mélanger les appels/sessions de différents réseaux d’accès. L’IMS utilise le protocole SIP
dans le cœur du réseau pour l'établissement, le maintien et la terminaison des sessions
(voix/multimédia) et comme protocole de contrôle d'appel. Donc une interconnexion entre
l’IMS qui utilise les technologies cellulaires pour fournir un accès en tout lieu, et les
technologies Internet pour fournir les services et les Web services pour la création et la
publication des services, sera efficace pour toute opération de création et d’invocation des
services multi-domaine, multi fournisseur via les réseaux fixes ou mobiles. Avec cette
intégration des systèmes informatiques distribués et hétérogènes dans des applications de
télécommunications pour les terminaux fixes et mobiles, le secteur des télécommunications, a
permis d'améliorer sa productivité et de mettre en liaison des communautés dans le monde
entier et dans presque tous les secteurs industriels. Vendre des services et des informations sur
un réseau, ne définit pas uniquement un accroissement considérable de la somme de
l'information coulant sur le réseau, mais aussi une question de confidentialité. La globalisation
croissante et la libéralisation du marché des télécommunications, nécessitent fortement une
infrastructure plus globale d’IN qui satisfait les besoins des différents abonnés légalement
impliqués, surtout pour les services multinationaux des abonnés. Cette ouverture définit des
exigences en terme de sécurité de l’information au sein des organisations et des applications.
Quelques fonctions de sécurité ont été déjà introduites dans des réseaux actuels, mais elles
définissent des contraintes liées à l'équipement propriétaire et aux algorithmes propriétaires
ou secrets. En réseau GSM par exemple, le protocole GSM spécifie les phases
d'authentification et de chiffrement entre le mobile et la station de base. La sécurité de ce
protocole repose sur des mécanismes cryptographiques non publiés, ce qui permet de réaliser
plusieurs types d’attaques ; notamment l’attaque Man-In- The-Middle. Cette attaque, consiste
à s'intercaler entre le mobile et la station et permet de prendre connaissance des IMSI d'une
cellule. Ce type d'attaque, connu sous le nom de IMSI-Catcher, est réalisable par exemple à
l'aide des produits GA900 ou CTS55 de Rohde & Schwarz.
Les exigences en termes de sécurité deviennent donc de plus en plus indispensables.
Ce qui nécessite l’introduction de méthodes avancées d’authentification, de gestion et de
distribution des clés entre les différentes entités sur le réseau, tout en respectant les contraintes
imposées par les réseaux sans fil, telles que la capacité de l’interface radio et les ressources
des terminaux mobiles. Concernant le réseau IN, il doit offrir ses services à un monde public,
ouvert, et surtout à offrir des services qui permettent à des utilisateurs de communiquer par la
transmission publique et de changer d’équipement sans épuiser leur intimité et leur aisance
3
d'emploi. Les services de sécurité fournis sur le réseau actuel ne seront pas suffisants pour IN,
le but est plus long. Les nouveaux aspects des fonctions de sécurité doivent garantir qu’ ils
soient publiquement utilisables, économiquement faisables et doivent assurer tout cela en
même temps. Dans cette optique, quels sont les protocoles de sécurité à choisir parmi les
protocoles standards connus (IPsec, TLS, SSL, AAA, …) et qui peuvent établir des sessions
sécurisées avec peu d’influence sur la performance globale du réseau, tout en fournissant les
différents services de sécurité pour différents types d’application ?
1.2 Problématique considérée
Dans cette thèse nous nous sommes focalisés, sur la nécessité d’élaborer une
architecture ouverte, permettant la création rapide de services de télécommunications dans un
environnement multi-acteurs. Cette architecture sera nécessaire pour introduire des
développements informatiques sur les services de télécommunications [1], pour permettre
l’évolution des services existants et la création des nouveaux services indépendamment des
réseaux et des accès empruntés. Cette architecture est présentée par une intégration de
protocole de signalisation SIP sur le réseau intelligent et plus exactement entre la machine
d’état SIP et le modèle d’état d’appel de base BCSM (Basic Call State Model) du réseau
intelligent. Cette intégration est possible d’après [1,13,16] ; il est donc important de tester une
interconnexion plus large, entre le réseau PSTN et IP permettant l’invocation d’un service à
valeur ajoutée à partir d’un terminal IP ou PSTN. Pour réaliser cette interconnexion, il faut
tout d’abord résoudre trois problèmes : comment faire une correspondance entre l’adresse
d’un terminal SIP et l’adresse téléphonique classique PSTN ?, comment faire acheminer ces
différentes adresses sur les deux réseaux PSTN et IP? Et comment peut-on localiser les
Gateways correspondants aux différents serveurs SIP ?
Avec cette interconnexion de l’IN sur IP, plusieurs concepts et aspects techniques
propres au réseau IP peuvent être aussi exploitables pour les réseaux intelligents. Dans ce
contexte, nous nous sommes intéressés à l’intégration de la technologie distribuée des services
Web sur les réseaux intelligents en exploitant les éléments constituants un service Web, tels
que l’UDDI comme annuaire des services et le WSDL comme une description d’un service.
La problématique considérée dans cette intégration est la suivante : comment rendre la
création des services à valeur ajoutée, plus flexible, plus rapide et indépendamment des SIBs
standards ? Ces SIBs standards définissent, en réalité, un obstacle aux développements et aux
créations des nouveaux services par le fait qu’ils ne sont pas des composants objets et sont
généralement trop chères et propres aux opérateurs télécoms.
Aux niveaux des réseaux mobiles, et malgré les avantages considérables de l’IMS, qui
permettent de converger vers tout IP et de fournir des services multimédias sur différents
réseaux. Plusieurs limites rendent l’IMS seul incapable d’être bénéfique pour la création et
l’exploitation des services par les opérateurs au près des utilisateurs [112]. Parmi ces
désavantages, l’IMS ne peut pas fournir des accès éloignés aux services mobiles fournis par
des tierces personnes des différents domaines administratifs. Cet inconvénient provoque une
perte de revenu pour les opérateurs par la perte de la fourniture des services aux autres
opérateurs. Un autre inconvénient est que l’IMS est incapable de fournir à l’utilisateur du
terminal une possibilité de partager leurs services sur le réseau, comme ils le font sur Internet.
Pour remédier à ceci, il faut faire de telle sorte que l’IMS puisse communiquer avec
des modèles qui permettent d'offrir des services multi-réseaux et multi-terminaux. Ces
modèles sont :
4
o Un modèle centrée sur le «softswitch», basée sur l'interface de services
normalisées du modèle OSA/Parlay. Ce modèle est plutôt adapté pour des
services de type télécoms.
o Un modèle orienté «Web Service», basé sur des technologies et des protocoles
issus du monde Internet (XML, SOAP) avec une architecture distribuée plus
adaptée à la fourniture de services en mode transparent sur IP, avec une
coopération forte du terminal.
Avec quel modèle faut- il interconnecter l’IMS ? Comment les dialogues seront- ils
réalisés ? Et comment cette interconnexion permettra la création, la modification et
l’exploitation des services multi-opérateurs, multi- terminaux ?
Dans ce contexte d’intégration du nouveau concept réseau intelligent sur des
environnements distribués et ouverts avec une indépendance presque totale aux opérateurs
classiques des télécommunications, ce que le réseau intelligent classique ne le supporte pas,
l’introduction des paramètres de sécurisation pour les différents services offerts devient
nécessaire. Ces paramètres de sécurité peuvent être appliqués soit au niveau des terminaux
origines de la demande, soit au niveau des nœuds réseaux acheminant les données d’un
service. Dans le cadre des réseaux intelligents, trois niveaux de sécurité sont impliqués, la
sécurisation de service demandé, la sécurisation des opérateurs (qui publient un service) et la
sécurisation des données du service. Le problème qui se pose dans cette partie est : comment
un client peut- il invoquer un service dans un environnement multi- fournisseurs et multiopérateurs sans menaces actives ou passives et comment les opérateurs peuvent ils fournir
leurs services auprès des clientèles avec une authenticité et confidentialité adéquate ?
Les différents mécanismes qui existent pour la sécurisation, soient aux niveaux des
opérateurs soient aux niveaux des services dans l’infrastructure réseau intelligent, sont
limitées à certains mécanismes d’authentification et d’autorisation, qui sont généralement
réalisés par des calculateurs classiques qui opèrent une technique relative à chaque service.
Des serveurs qui appliquent des algorithmes de cryptographie propres à chaque opérateur
télécoms sont également utilisés. Cette situation rend la publication d’un service sécurisé,
indépendamment des opérateurs classiques connus, une tâche difficile. La question est donc :
y a t- il un (des) moyen(s) permettant d’intégrer des mécanismes de sécurisations au niveau
terminal ou au niveau fournisseur de service lui- même pour réaliser la sécurisation des
services et des opérateurs, tout en sachant l’existence de multi- fournisseurs et de multiservices totalement indépendants?
Les différents problèmes soulevés précédemment seront traités dans cette thèse dans
l’ordre dans lequel ils viennent d’être évoqués.
1.3 Démarche proposée
Pour couvrir ces différentes problématiques d’intégration, de création et de
sécurisation des services de télécommunications pour les terminaux fixes et mobiles sur un
environnement distribué ouvert, nous proposons des méthodes et des techniques spécifiques
qui prennent en considération les différents travaux publiés et réalisés dans ces domaines.
5
L’organisation de ce document reflète la démarche que nous avons adoptée lors de la
réalisation de notre travail. Le document est composé de six chapitres incluant celui de
l’introduction générale :
-
Après la présente introduction, nous nous intéressons aux outils nécessaires pour
l’intégration et la création des services télécoms en NGN.
-
Le chapitre 2, est consacré aux outils estimés nécessaires pour construire notre
atelier de travail : le protocole de signalisation SIP, L’architecture orientée services
(SOA), les services Web et l’IMS (IP multimedia SubSystem), et ceci après une
présentation des limites des réseaux intelligents.
-
Dans le troisième chapitre, nous discutons les techniques de l’intégration SIP sur le
réseau intelligent [1, 12, 13, 14] à base des modèles d’état d’appel de base de
réseau intelligent et de la machine à état du SIP dans le cas client ou serveur.
Ensuite nous introduisons le protocole ENUM, protocole de traduction des
numéros PSTN ou E.164 en DNS ou vis versa puis le protocole TRIP, protocole de
routage et de localisation des gateways VoIP. Enfin, nous proposons une
technique permettant d’interconnecter les réseaux de télécommunication PSTN sur
les réseaux IP. Le but de cette interconnexion est de rendre les services de
télécommunication prédéfinis pour les clients PSTN joignables pour les clients IP.
-
Dans le chapitre 4, nous présentons la technique de la combinaison SIP avec
SOAP pour toute opération de découverte des URI des services publiés et ceci
avant de formuler les requêtes SOAP nécessaires. Avec la technique présentée
dans le chapitre 2, nous proposons une méthode permettant de généraliser et de
faciliter la technique de la création des services à valeur ajoutée. Dans cette
méthode trois architectures sont présentés. La première est pour la découverte des
services distincts dans des bases de données hétérogènes et distribuées. La
deuxième est l’utilisation de la technologie du VoiceXML pour réaliser toute
opération de communication interactive. Cette communication interactive est
nécessaire pour plusieurs types d’opérations, tels que la demande
d’authentification auprès de l’operateur ou toute autre demande, au niveau client,
supportée par le service. La troisième est relative aux réseaux mobiles, dans laquelle nous montrons comment Le Parlay X Web service peut s’interconnecter
avec l’IMS pour créer, invoquer et publier des services multi-domaines, multifournisseurs.
-
Dans le chapitre 5, nous étudions en premier temps, les problématiques liées à la
sécurité des services télécoms. Nous examinons les différentes menaces aux
niveaux réseaux fixes et mobiles. Puis, nous présentons les différentes techniques
de sécurisation propre de chaque réseau (GSM, GPRS, UMTS). Enfin, nous
proposons une solution permettant de sécuriser l’opérateur de service et le service
lui- même. Cette solution présente trois niveaux de sécurité. Niveau 1, est
l’authentification du client en tant qu’un utilisateur qui demande une connexion
aux réseaux des services. Le niveau 2, est le contrôle d’accès aux services au
niveau paquet acheminant la demande entre entité réseau. Le niveau 3, est la
sécurité des données propres du service une fois qu’une connexion est établie.
Egalement, nous proposons une technique permettant la sécurisation entre
6
domaines pour un service multi-domaines, en tenant compte des spécifications
standard des réseaux mobiles.
Nous concluons nos travaux dans le chapitre 6, par une synthèse sur les différentes
méthodes et techniques proposées pour la création et la sécurisation des services des réseaux
intelligents fixes et mobiles. Nous notons également des ouvertures et des perspectives
possibles pour le domaine de la recherche qui porte nt sur l’intégration et la sécurisation des
services de télécommunication sur le réseau IP pour les différents environnements fixes et
mobiles.
7
Chapitre 2
Outils des créations des services télécoms
sur NGN
Résumé du contenu
2.1. Introduction
2.2. Les réseaux intelligents et leurs limites
2.3. Le protocole SIP
2.4. Les concepts VHE et OSA
2.5 L’IMS ou la convergence fixe mobile
2.6 Les Web services
2.7. Conclusion
2.1Introduction
L’UIT définit un réseau de prochaine génération (NGN) comme un réseau en mode
paquet qui est en mesure d’assurer des services de télécommunication et d’utiliser de
multiples technologies de transport à large bande à qualité de service imposée et dans lequel
les fonctions liées aux services sont indépendantes des technologies sous-jacentes liées au
transport.
En fait la release 4 et la release 5 définies par le 3GPP ont conduit à la convergence du
réseau cœur vers le tout IP grâce à l'introduction de nouveaux éléments tels que le sous
système multimédia (IMS), les serveurs (CSCF, MGCF) et les média Gateways (MG) dans
l'architecture du réseau cœur de l’UMTS [107]. Ainsi, avec l'apparition des nouveaux réseaux
d'accès, l'hétérogénéité des terminaux communicants (téléphone mobile, GPRS/UMTS,
PDA...), la grande mobilité des utilisateurs, et la convergence des réseaux d'accès vers un
réseau tout IP comme le montre la figure 2.1, il sera nécessaire de déployer des nouvelles
architectures de plates- formes de services pour faire le lien entre les fournisseurs de services
et les utilisateurs fixes/mobiles connectés au réseau.
Ces architectures doivent être utilisables dans des contextes très divers et
doivent répondent aux différents besoins liés à la nature des environnements fixes/mobiles et
aux spécificités de l'application de fourniture des services. C'est pourquoi, ces différents
réseaux inter connectés via des interfaces standardisées (OSA/PARLAY, Web Services...),
8
doivent offrir de manière transparente et avec une certaine qualité des services adaptables aux
utilisateurs dans leur mobilité.
Dans ce chapitre, nous allons axer notre étude dans un premier temps sur le réseau
intelligent ainsi que sur ses limites qui ne lui permettent pas de répondre aux exigences des
nouvelles architectures réseaux, puis nous présentons le protocole de signalisation de l’IETF
SIP qui est l’un des protocoles les plus utilisés pour l’invocation des appels sur IP, puis nous
présentons la philosophie du VHE tout en abordant aussi certains concepts liés à cette
philosophie. Ensuite, nous étudions l’environnement Web service. Enfin, la dernière partie de
ce chapitre sera consacrée à l’architecture de l’IMS, ainsi qu’à ses limites pour la création des
services télécoms.
Système d’accès Media
Coeur Réseau
UMTS
GSM/GPRS
SAT
WiFi
Services et Applications
Terminal
Figure 2.1 : Convergence dans NGN
2.2. Les réseaux intelligents et leurs limites
L’architecture du réseau intelligent défini par l’ensemble de recommandation [ITUQ12xx] repose par défaut sur le réseau de signalisation SS7, destiné à fournir des services au
près des clientèles PSTN. Le réseau intelligent est spécifie par un modèle de t ype top-down,
dit «modèle conceptuel», INCM (Intelligent Network Conceptual Model). Ce modèle est
destiné à servir comme une démarche méthodologique pour concevoir et décrire une
architecture détaillée du réseau intelligent, pour la création et la mise en fonctionnement des
services télécoms. Toutes les opérations relatives aux services se réalisent autour d’une
fonctionnalité du traitement d’appel de base appelé BCP (BCP : Basic Call Process). Ce BCP
exécute un ensemble de services spécifiques indépendant connus sous le nom SIB (SIB :
service Independant Building Block) selon des recommandations techniques connues sous le
nom de l’ensemble de capacités (CS-1, 2, 3 ou 4 : Capabilities Set).
Les opérations de commutation au niveau du réseau PSTN ainsi qu’au niveau du
réseau intelligent sont réalisées par des commutateurs permettant selon une requête de
signalisation SS7 (Signalisation System 7) d’atteindre la destination correcte des appels
émises par un client et localiser le terminal destiné. La localisation est selon un plan de
numérotation standardisé au niveau national et international sous le format E.164. Les nœuds
de réseau PSTN sont répartis et échangent entre eux au moyen du système de signalisation
SS7 un minimum réduit d’information. Ces nœuds sont hétérogènes et peuvent être gérés par
des opérateurs différents, ce qui rend leur modification une tâche difficile ainsi que la
9
synchronisation de la mise à jour et la cohérence des données entre eux. De ce fait, le délai et
le coût du développement et de la modification des services sont très élevés. L’idée sera donc
de créer un nœud SCP (Service Control Point) central parallèle aux réseaux de commutation,
facile à modifier, pour l’ajout et la modification des services et permettant d’agir sur le
commutateur SSP (Service Switching Point) pour réaliser un tel service. C’est le concept du
réseau intelligent qui permet d’établir une séparation entre le service (le programme et ses
données) et le traitement d’appel de base. Les figures 2.2 et 2.3 illustrent les composants du
réseau intelligent ainsi que le modèle conceptuel.
Figure 2.2 : Architecture physique simplifiée du réseau intelligent
Figure 2.3 : Le modèle conceptuel du réseau Intelligent
De point de vue réseaux intelligents, certains problèmes restent à résoudre :
10
-
-
-
Le réseau intelligent est trop dépendant du traitement d’appel de base, ce qui rend
certains services non concevables, tels que les services multimédias.
L’absence d’une indépendance entre le service demandé et sa mise en relation est
un obstacle à la séparation du support. Ce qui nécessite une évolution au niveau de
l’architecture du réseau intelligent pour séparer la connexion de la fourniture de
services
Le modèle conceptuel du réseau intelligent est un ensemble de définition qui ne
spécifie pas un langage standard pour la modélisation et par conséquent pour la
création des services. Ce défaut est un manque, soit pour les concepteurs soit pour
les créateurs des services
Ajoutons à tous cela les nombres limités des SIBs responsables à la création des
services (CS-1 : 14 SIBs), ce qui rend la création des nouveaux services une tâche
très difficile.
Pour faire évoluer le réseau intelligent vers la réalisation des services indépendants du réseau
sous-jacent, ainsi que pour répondre aux exigences de l’architecture NGN, nous proposons
dans la suite, des outils estimés nécessaires pour notre atelier de travail.
2.3 Le protocole SIP
Lors de la recherche d’un protocole, capable de prendre en charge la signalisation
associée au fonctionnement des services et à la fois extensible, notre choix s’est porté sur SIP
(session Intiation Protocol). Ce protocole de signalisation est proposé par la communauté
Internet, (Internet Engineering Task Force (IETF)). Il définit une procédure de signalisation
permettant l'établissement, le contrôle et le relâchement d'appel téléphonique avec ou sans
extension multimédia. Il a été aussi retenu pour l'UMTS par le groupe 3GPP, afin de
permettre un transport de la voix et des applications multimédia en temps réel sur un réseau
paquet dans le monde mobile. Il est également pressenti par la plupart des opérateurs pour être
le protocole le plus utilisé dans le cadre de l'évolution du réseau vers le NGN. SIP sera donc
utilisable dans tous les réseaux IP, à la fois sur Internet et dans les réseaux mobiles.
Une transaction SIP (RFC3261) est un ensemble de requêtes d’un client invoquant des
méthodes sur un serveur SIP. Les requêtes et les réponses sont textuelles et comportent des
en-têtes et éventuellement un corps décrivant la session en utilisant un protocole de
description de la session SDP (Session Description Protocol, RFC2237) qui met à la
disposition des utilisateurs plusieurs services tels que le nom du media (m=), l’attribut du
media (a=), une information sur la session (i=), une clé de chiffrement (k=), etc.
Pour faire cela, plusieurs éléments contribuent au fonctionnement de SIP : l’agent
utilisateur UA (User Agent) et le serveur réseau NS (Network Server) qui peut être un serveur
redirect, un serveur proxy ou un serveur de localisation. Pour faire ces opérations, SIP définit
plusieurs types des requêtes appelées « méthodes » dont les principaux sont :
-
INVITE : Invite un usager et établit la connexion.
ACK : Termine et confirme la demande de la liaison INVITE.
Bye : Coupe la communication, l’agent arrête l’envoi de paquet de type media.
Options : Demande à un autre agent ces comptabilités, la réponse contiendra la liste
des méthodes qu’il supporte, ces codecs,…
Cancel : Termine une communication en cours d’établissement.
11
-
Register : Permet l’enregistrement d’un agent ou mettre à jour sa localisation et son
URL auprès d’un serveur d’enregistrement, celui-ci pourra à son tour mette à jour le
serveur de localisation.
La réponse à une méthode est un code entier et une phrase. Ces codes sont groupés en
six classes allant de 100 à 600, elles ont été crées sur le modèle des réponses HTTP. Les
codes qui indiquent des informations sont 1xx, les codes succès sont 2xx, les codes de
redirection sont 3xx, les codes d’erreur client sont 4xx, les codes d’erreur serveur sont 5xx et
les codes d’erreur générale sont 6xx.
Notons aussi, que les adresses SIP peuvent prendre plusieurs types :
x
x
x
x
x
userID@hostname
user@domain
user@host
user@IP_address
Phone_number@gateway (si le numéro appelé est sur le PSTN).
Les opérations typiques du SIP entre utilisateurs (UA) peuvent être soit en mode
proxy soit en mode redirection (figure 2.4) La transaction SIP typique, où un terminal (UA1)
invite un second terminal (UA2) à une session, est modélisée par la syntaxe : INVITE, ex :
sip : user@domain où user est l’identificateur du correspondant sur un terminal du domaine
domain. Cette requête est émise vers le serveur proxy local qui recherche auprès d’un DNS,
des informations concernant le domaine domain. Ces informations reprennent l’adresse IP du
serveur du domaine pour traiter la requête SIP. Le proxy local, une fois qu’il retrouve les
informations, émet vers le second proxy du second domaine la requête d’invitation de l’UA1.
L’adresse utilisée pour appeler un utilisateur ne donne aucune indication sur la position
actuelle de celui-ci, il se peut même qu’il y ait simultanément plusieurs positions enregistrées.
Deux cas peuvent se présenter : soit le UA2 est connecté au domaine trouvé (mode proxy),
soit pour cet instant est connecté sous un autre domaine (mode redirection). Dans le premier
cas, l’UA2 est localisé et une requête OK est émise d’UA2 à UA1 à travers le proxy et
l’opération de communication est établie après une requête ACK de UA1 à UA2 [11,12].
Dans le deuxième cas (mode de redirection) le proxy 2 envoie une requête à UA1 sur la
nouvelle adresse d’UA2 et après une acquisition d’UA1 de la requête (ACK) une nouvelle
INVITE sera émise sous la nouvelle adresse.
Figure 2.4 : Les deux modes de fonctionnement SIP
12
Les besoins au niveau des terminaux et au niveau des réseaux ont largement contribués à
la définition de plusieurs documents de référence pour le protocole SIP, on trouve :
-
RFC 3263
RFC 6265
RFC 2915
RFC 3455
…
: localisation des serveurs SIP,
: SIP, transporteurs des tonalités DTMF,
: NAPTR DNS
: extensions SIP pour 3GPP,
2.4 Les Concepts VHE et OSA
Les objectifs fondamentaux des réseaux NGN, et plus particulièrement pour les
UMTS/IMT-2000 est de permettre la fourniture des services multimédias en mode paquet ou
circuit sur une infrastructure mobile. Ces réseaux doivent prendre en charge le support global,
ce qui signifie que l’usager dispose d’un ensemble de services qui possèdent le même aspect
et la même interface.
Dans ce contexte l’UMTS offre :
-
Un environnement de rattachement virtuel, VHE
-
Une possibilité d’accéder au réseau grâce à des API.
Nous développons dans ce paragraphe les concepts clés pour offrir des services dans
l’environnement de la troisième génération.
2.4.1 VHE
Le VHE, ou l'environnement de service personnalisé, est un concept d'environnement
de service personnalisé qui a été défini par le 3GPP dans le cadre de la normalisation de
l'UMTS. Il définit un système qui permet à des utilisateurs nomades d'accéder e t d'utiliser,
d'une manière personnalisée, un ensemble de services quels que soient le réseau d'accès et le
terminal utilisé (dans les limites et les capacités du réseau et du terminal) et avec les mêmes
paramètres de personnalisation. Autrement dit, le VHE supporte l'idée d'une universalité du
service qui s'adapte d'une part aux paramètres de personnalisation de l'utilisateur, et d'autre
part à son terminal et son réseau d'accès.
Le concept du VHE est développé dans le projet CAMEL (Customized Applicatio ns
for Mobile Network Enhanced Logic)[122] dont l’objectif est de permettre à un usager
d’accéder aux services spécifiques offerts, grâce à la fonction HLR (Home Location
Register), par son opérateur même lorsqu’il est accueilli sur un réseau tiers.
Dans VHE, les profils de l'utilisateur sont fournis et contrôlés par son réseau nominal
qui peut avoir des contrats d'accord avec des fournisseurs de service à valeur ajoutée. En plus
des services offerts par le réseau nominal, l'utilisateur peut utiliser d'a utres services fournis
par des fournisseurs de services au sein des réseaux visités (autres que son réseau nominal).
L'environnement nominal HE (Home Environment), gère tous les services qui sont
accessibles dans le réseau nominal. L'environnement nominal a un accès aux profils de
l'utilisateur pour adapter tous les services aux préférences de l'utilisateur. Le VHE exporte les
13
services de l'environnement nominal et les adapte aux capacités du réseau visité et du terminal
utilisé.
Le concept VHE, tient compte du fait que la fourniture du service et l’exploitation du
réseau peuvent se faire de manière séparée, ce qui remédie un des problèmes des réseaux
intelligents. Les usagés peuvent se déplacer au sein des réseaux et accéder aux services, ce qui
définie les différentes notions de la mobilité :
x
La mobilité personnelle ou de l'utilisateur : Elle correspond à la capacité de
l'utilisateur d'accéder à des services personnalisés à partir de n'importe quel terminal
fixe ou mobile disponible et la capacité du réseau de fournir ces services selon les
préférences de l'utilisateur. La mobilité personnelle permet à un utilisateur d'utiliser
ces services personnalisés indépendamment du terminal utilisé et ce, dans n'importe
quel réseau d'accès. Elle est liée à la gestion de la localisation de l'utilisateur et à la
gestion de la portabilité des services.
x
La mobilité du terminal : Correspond à l'aptitude du terminal à accéder aux services
quels que soient l'endroit où il se trouve et la vitesse de son déplacement. La mobilité
du terminal permet à un terminal mobile de changer son point d'attachement au réseau
sans perdre la connexion en cours.
x
La mobilité des services : Aussi appelée portabilité des services, elle fait référence à
la capacité du réseau à fournir les services souscrits à l'endroit où se trouvent le
terminal et l'utilisateur. Les services exacts que l'utilisateur peut demander sur son
terminal dépendent des propriétés du terminal (que l'on appelle les capacités du
terminal) et du réseau qui sert ce terminal.
En outre, le 3GPP demande la définition d'une architecture permettant d'offrir le concept
VHE; il a identifié le modèle OSA (Open Service Architecture) comme un des outils
nécessaires à la mise en place du concept VHE.
2.4.2 OSA (Open Service Architecture)
La norme OSA est une initiative conjointe de la troisième génération (3GPP), des
Normes ETSI de TISPAN et le groupe Parlay qui définissent un plateforme de fonctionnalités
au cœur du réseau de 3G à être accessible au développement des applications de services
standard et flexible de façon facile[115]. Toutes les fonctions réseaux comme le contrôle
d’appel, le contrôle des ressources spécialisées, deviennent accessibles depuis les
applications. OSA permet aussi, à des fournisseurs de services tiers de proposer des services
sur l’infrastructure d’un operateur mobile traditionnel. Chaque ensemble de caractéristique du
réseau est groupé dans une aptitude de service (SCF : Service Capability Function) et offert
aux développeurs de services dans un API ouvert. Le SCF est réalisé par un ou plusieurs de
serveurs (SCS), qui sont les entités fonctionnelles qui offrent les interfaces OSA aux
applications. Voire figure 2.5.
14
Service
OSA API
HLR
Plate- forme
CSCF
OSA Gateway
PSTN/GPRS/UMTS
Figure 2.5 : API OSA
Cette nouvelle architecture doit offrir la possibilité aux clients d'accéder aux services, quels
que soient la nature des terminaux et le type de protocole utilisé et aux plates- formes de
services, via un réseau de transport unifié, en mode paquet ou circuit. Le service rendu doit
être adapté aux besoins et aux moyens des clients.
Cette nécessité d'offrir des services multi-réseaux et multi-terminaux a conduit à
l'émergence de deux modèles principaux et complémenta ires:
–
Une architecture centrée sur le «softswitch», basée sur l'interface de services
normalisée du modèle OSA/Parlay. Ce modèle est plutôt adapté pour des services
de type ''télécoms''.
–
Un modèle orienté «Web Service», basé sur des technologies et des protocoles
issus du monde Internet (XML, SOAP) avec une architecture distribuée plus
adaptée à la fourniture de services en mode transparent sur IP, avec une
coopération forte du terminal.
L’OSA permet aussi la séparation entre les services et le contrôle de la connectivité et
donne la possibilité aux applications d’accéder au réseau à travers une API. Il sera possible
donc à un utilisateur mobile d’interagir avec des plate-formes distribuées comme Corba,
dotNet, etc, et de bénéficier de leurs différents avantages.
L’élément normalisé par le monde des télécommunications, qui intègre le concept de
convergence de services supportés indifféremment par des réseaux de natures différentes :
fixe, mobile ou Internet, supporte sur un réseau tout IP, des sessions applicatives temps réels
(voix, vidéo, conférence,…) et non temps réel (Push To Talk, Présence, messagerie
instantanée,…), et utilise le protocole SIP dans le réseau cœur pour l'établissement, le
maintien, la terminaison des sessions (voix/multimédia) et comme un protocole de contrôle
d'appel est l'IMS (IP Multimedia Subsytem).
15
2.5 L’IMS ou la convergence fixe mobile
L’IMS a été conçu à l'origine pour les réseaux mobiles, mais avec l'ajout des travaux
de TISPAN dans la version 7, les réseaux fixes sont également supportés. On appelle cela la
convergence Fixe/Mobile, qui est devenue une des tendances-clés de l'industrie des télécoms
en 2005.
L'IMS est une partie structurée de l'architecture des réseaux de nouvelle génération
(NGN) qui permet l'introduction progressive des applications voix et données multimédia
dans les réseaux fixes et mobiles. L'IMS inter-fonctionne avec tous types de réseaux (fixe,
mobile ou sans fil), incluant les fonctions de commutations de paquets, comme le GPRS,
l’UMTS, CDMA 2000, WLAN, WiMAX, DSL, le câble… Les systèmes plus anciens de
commutation de circuit (POTS, GSM) sont aussi supportés grâce à des passerelles
(Gateways). Des interfaces ouvertes entre les couches de contrôle et de service permettent de
mélanger les appels/sessions de différents réseaux d’accès [102]. L’IMS utilise les
technologies cellulaires pour fournir un accès en tout lieu, et les technologies Internet pour
fournir les services
L'architecture IMS est constituée par un ensemble d'équipements et de protocoles dont
les fonctions et les rôles se complètent. Les interfaces sur les différentes liaisons internes et
externes à cette architecture font également l'objet des spécifications évolutives. Le principe
de l'IMS consiste, d'une part à séparer nettement la couche transport de la couche des services
et d'autre part à utiliser la couche transport pour des fonctions de contrôle et de signalisation
afin d'assurer la qualité de service souhaitée pour l'application désirée. L'IMS a pour ambition
de constituer une plate- forme unique pour toute une gamme de services et d'être en mesure
d'offrir de nouvelles applications en un temps minimum. IMS vise, à faire du réseau une sorte
de couche middleware entre les applications et l'accès. Les applications sont soit SIP, soit non
SIP, elles passent alors par une passerelle avant la connexion au contrôleur de sessions.
2.5.1 Architecture IMS
L’architecture IMS peut être structurée en quatre couches :
¾ La couche Acces, qui représente tout accès haut débit tel que : UTRAN (UMTS
Terrestrial Radio Access Network), CDMA2000, xDSL, réseau câble, Wirelless IP,
WiFi, etc.
¾ La couche Transport, qui représente le réseau IP. La couche transport consiste à des
routeurs reliés par un réseau de transmission. Différentes piles de transmission
peuvent être considérées pour le réseau IP: IP/ATM/SDH, IP/Ethernet, IP/SDH, etc.
¾ La couche Contrôle, qui consiste à des contrôleurs de session responsables du routage
de la signalisation entre usagers et de l’invocation des services. Ces nœuds sont les
CSCF (Call State Control Function). IMS Introduit par conséquent un environnement
de contrôle de session sur le domaine paquet.
¾ La couche Application, qui introduit les applications (service à 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
16
couche application consiste à des serveurs d’application (AS : Application Server) et
des MRF (Multimedia Resource Function).
Le cœur IMS est accessible indépendamment, ce qui signifie que les mêmes services
peuvent être livrés sur des différents types de technologies d'accès. Dans la spécification IMS,
le «cœur» de l’IMS comprend deux nœuds principaux: la fonction de contrôle de session
d'appel (CSCF : Call Session Control Function) et le Serveur Natal d'abonné (HSS : Home
Subscriber Server) qui regroupe les fonctions du HLR, AuC (Authentivation Center) et les
fonctions nécessaires pour assister les serveurs CSCF. Dans l’aperçu d'architecture d’IMS
(figure 2.6), le réseau PSTN est connecté à la fonction de contrôle de portail de médias
(MGCF : Media Gateway Control Function) et au portail de médias (MGW : Media Gateway)
qui ont été connecté au Cœur IMS.
Figure 2.6 : Architecture IMS
Le mode de fonctionnement de l’IMS peut être résumé très sommairement de la façon
suivante :
x
L’utilisateur est identifié par le réseau de deux façons, une identité publique (USIM)
liée à son adresse Internet ou à son numéro de téléphone et une identité privée (ISIM)
qui n’est pas utilisée pour le routage, ces deux identités étant enregistrées sur la même
carte (UICC). A l’identité publique est associé un profil de service et d’abonnement,
qui est mémorisé dans la base de donnée du réseau (serveur d’application), appelé
HSS (ou UPSF). L’IMS autorise ou non l’accès à une ressource de réseau ou à une
application selon le profil de l’abonné.
x
L’intelligence active de l’IMS est concentrée dans un serveur d’appel constitué d’un
trio d’équipements logiques appelés « CSCF » (Call Session Control Function ou Call
State Control Function). On distingue le « I-CSCF » (Interrogating), qui est le point
d’aiguillage intermédiaire pour l’initialisation des connexions, et qui, via le DNS,
fournit la destination recherchée pour les requêtes orientées vers les multiples S-CSCF
des réseaux. Le « S-CSCF » (Serving) est utilisé pour la commutation vers
17
l’application, l’enregistrement, le contrôle des sessions SIP, le service ou le réseau
(« serving in charge ») demandés. Le P-CSCF (Proxy) sert d’extension logique vers le
réseau de l’abonné ou vers le réseau visité et sert au contrôle le réseau d’accès. Il
assure les fonctions de liaison aux réseaux de paquets et au PDF (recherche des profils
de l’usager). Dans la cinquième version de la norme TISPAN, le PDF est séparé de
l’I-CSCF afin de permettre l’ouverture de nouvelles applications liées à la qualité de
service hors IMS. Cette interface P-CSCF existe dans tous les réseaux fixes ou
mobiles. En fixe, il sert à la voix sur IP et en réseau mobile, il est utilisé pour toutes
les connexions.
x
Les deux CSCF (le I et le S) sont connectés à la base de données du réseau
(HSS/UPSP) afin de recevoir les informations nécessaires aux autorisations de
connexion. Le I-CSCF est relié aussi aux I-CSCF de réseaux voisins afin d’assurer les
communications sortantes ou entrantes au réseau considéré, en particulier celles qui
sont destinées au réseau téléphonique classique (RTPC/RNIS).
x
Les abonnés sont reliés au réseau d’accès à haut débit à travers l’UTRAN (à gauche et
en bas, sur le schéma 2.7, pour le demandeur et à droite, pour le demandé) et par deux
équipements (ou passerelles) en cascade, le SGSN et le GGSN.
x
Deux chemins d’information sont à distinguer entre ces équipements. Les flux de
signalisation en protocole SIP (en pointillés sur le schéma) vont du terminal de
l’abonné demandeur, via le SGSN, le GGSN, le trio des CSCF associés au HSS et au
PDF, puis le GGSN et le SGSN de l’abonné demandé. L’échange bilatéral des
données voix et données multimédia s’effectue directement sur la chaîne « demandeur
– SGSN – GGSN –GGSN – SFSN – demandé », grâce aux autorisations fournies par
la chaîne de signalisation.
x
Le trio d’équipements de signalisation CSCF et les informations du HSS ouvrent
l’accès aux serveurs d’application SIP, OSA et CAMEL. Les données relatives à
l’abonné (identité, droits et état de la session) sont enregistrées dans le HSS (ancien
HLR des réseaux mobiles), lequel ouvre les tickets de tarification à l’aide du protocole
Diameter, basé sur IP. Le HSS assure ainsi trois fonctions de sécurité :
authentification, autorisation et comptabilité, essentielles à l’IMS.
18
Figure 2.7 Architecture 3GPP.
2.5.1.1. Architecture de service IMS
L’architecture de service IMS de base est constituée d’entités serveurs d’application,
de serveurs de média IP et de S-CSCF équivalents à des serveurs d’appels. Le serveur
d’application SIP (AS : Application Server) exécute des services (e.g, Push To Talk,
Présence, Prépaid, Instant messaging, etc.) et peut influencer le déroulement de la session à la
demande du service. Le serveur d’application correspond à l’entité SCF (Service Control
Function) du Réseau Intelligent. Le serveur media IP met en œuvre l’entité fonctionnelle
MRF (Multimedia Resource Function). Il s’agit de l’évolution de l’entité SRF (Specialized
Resource Function) du Réseau Intelligent dans le monde multimédia. Le serveur d’appel SIP
appelé S-CSCF (Serving - Call State Control Function) joue le rôle du point depuis lequel un
service peut être invoqué. Il dispose du profil de service de l’abonné qui lui indique les
services souscrits par l’abonné et sous quelle condition il devrait invoquer ces services. Il
correspond à l’entité SSF de l’architecture Réseau Intelligent.
2.5.1.2. Entités de l’architecture de service IMS
L'architecture de service IMS consiste en un ensemble de serveurs d'application
interagissant avec le réseau IMS à travers l'interface ISC (IP Multimedia Service Control)
supportée par le protocole SIP (Figure 2.8).
Les serveurs d'application sont :
x
Les serveurs d'application SIP (SIP AS) qui exécutent des services et qui peuvent
influencer le déroulement de la session à la demande du service.
x
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
19
signalisation SIP sur l'interface ISC d'une part et qui joue le rôle de SSP RI/CAMEL
d'autre part. Il dispose des modèles d'appel O-IM-BCSM et T-IM-BCSM, des points
de détection RI/CAMEL et du protocole INAP/CAP pour interagir avec les SCP
RI/CSE CAMEL.
x
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.
x
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.
Tous les serveurs d'applications (IM-SSF et OSA SCS inclus) 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.
Figure 2.8 : Architecture de service IMS
Les mécanismes mis en œuvre dans l’établissement des sessions de communications IMS,
sont analogue à celle du SIP ajoutant à ceci les composants spécifique de l’IMS. Nous
présentons dans les figures suivantes les deux mécanismes fondamentaux du l’IMS, qui sont :
-
L’enregistrement d’un usager mobile auprès de son réseau IMS (figure 2.9)
L’établissement d’une session IMS (figure 2.10)
20
Figure 2.9 : Enregistrement d’un usager mobile auprès de son réseau IMS
Figure 2.10 : Etablissement d’une session IMS
2.5.2 Limitations de l’IMS
Malgré les avantages considérables de l’IMS, plusieurs limites rendent l’IMS tout seul
incapable d’être bénéfique pour la création et l’exploitation des services par les opérateurs
auprès des utilisateurs :
-
Un manque de l’architecture de l’IMS est qu'il ne fournit pas d'accès éloigné aux
services mobiles fournis par des tierces personnes des différents domaines
administratives. Les interfaces utilisées pour ces services mobiles ne sont pas
standardisées à travers le réseau de différents domaines administratifs et il n’y a
aucune voie ordinaire de publication de ces services [112]. C'est aussi important si les
21
services mobiles offert aux utilisateurs, peuvent construire d'autres services mobiles à
temps réel.
-
Une conséquence de ces désavantages est la perte de revenu pour les opérateurs, du
fait qu’ils perdent l'occasion d’offrir des services à autres opérateurs. Une autre
conséquence est la possibilité limitée à améliorer les expériences d'utilisateurs, car le
système est incapable de leurs fournir la création des services, et il serait convenable
de savoir leurs besoins. Enfin, un utilisateur mobile de service pourrait avoir des
différentes expériences en utilisant des services mobiles fournies dans des domaines
différents de réseau.
-
La courante architecture IMS est aussi incapable de fournir à l’utilisateur d u terminal
une possibilité de partager leurs services sur le réseau, comme ils le peuvent faire sur
Internet.
L’élément le plus connu, et qui permet de résoudre ces différents manques et favorise r
l’opération de création et de publication des services sur IP, est la technologie Web service.
Les développeurs d’applications sont soutenus par le concept du service orienté architecture
(SOA) et la technologie Web service. Utilisant ces technologies, une application distribuée est
aussi simple à manier qu'un composant de logiciel local. Les Web services sont fournis et
publiés comme des services conventionnels.
2.6 Les Web services
L’architecture des services Web définit des méthodes standard pour créer des systèmes
orientés vers les services, dynamiques et faiblement couplés. L’architecture orientée vers les
services offre un modèle de programmation standard qui permet à des composants logiciels
développés séparément d’être publiés, identifiés et invoqués les uns par les autres. Ces
composants peuvent résider sur un même réseau ou sur des réseaux distincts [34]. Il s'agit
d'une technologie qui permet à des applications distantes de dialoguer via Internet, et ceci
indépendamment des plate-formes, des langages sur lesquelles elles reposent, de l’architecture
sous-jacente (dot.Net, J2EE,…) et permettent l’interopérabilité entre des systèmes
hétérogènes grâce aux standard XML et Web (http, https,…). Pour faire cela, les services
Web s'appuient sur un ensemble de protocoles standardisant les modes d'invocation mut uels
de composants applicatifs :
Un projet d’un service Web (figure 2.11) passe notamment par l'élaboration du WSDL
et du SOAP. Reposant sur le langage de balisage XML (eXtensible Markup Language), le
protocole SOAP (Simple Object Access Protocol) définit la structure des messages échangés
par les applications via Internet, quant au WSDL (Web Services Descriptio n Language), il
fournit un mode de description des composants applicatifs permettant d'invoquer leurs
fonctions à distance par l'échange des messages au format SOAP. A ces deux protocoles
s’ajoute UDDI (Universal Description, Discovery and Integration) qui est l’annuaire mondial
d'entreprises basé sur le Web. UDDI intègre toutes sortes d'entrées (nom, carte d'identité des
sociétés, description des produits et des services, etc.) ; son objectif est d'automatiser les
communications entre prestataires, clients, etc. Le tout, en fournissant les références des
connexions permettant d'invoquer dynamiquement et à distance les services Web proposés par
les sociétés. En quelque sorte, UDDI propose d'industrialiser les services Web en
automatisant toute la procédure de recherche et de découverte de ces services.
22
Implmentation of
Services (Components)
1: Demander
5: Invoquer
2: Trouver
6: Répondre
3: Obtenir
7: La réponse
4: Demander
8: La réponse
Registry
UDDI
UDDI
2
Routing
3
1
Service
Request
8
Interface
Description
With WSDL
Service
Service
Broker
5
4
7
Web
Server
For
SOAP
6
Se
rvi
ce
s
Figure 2.11 : Implantation et exécution de Web service [25].
L’un des plus gros avantages des Web services est qu’il repose sur des protocoles
standardisés. Cela rend cette technologie exploitable par de nombreux langages et sur
différentes plateformes. En effet, les Web services se reposent sur des protocoles tels que
http, XML et SOAP. Ce dernier permet de faire circuler du XML via http. A l’heure actuelle,
la quasi-totalité des langages informatiques supporte ces protocoles ; ils disposent en effet de
fonctions pour lire un fichier XML. Par conséquent un Web service développé sous une
plateforme dotNet peut être utilisé via les différents langages Perl, PHP, Python, Delphi, etc.
En effet, l’objectif du Web service est de remplacer les protocoles actuels (RPC, DCOM,
RMI) par une approche entièrement ouverte et interopérable, basée sur la généralisation des
serveurs Web avec scripts CGI et de faire interagir des composants hétérogènes, distants, et
indépendants avec un protocole standard (SOAP) dédiés aux applications B2B (B2B :
Business to Business), EAI (EAI : Enterprise Application Integration), P2P (P2P : Peer to
Peer).
2.6.1. Le protocole SOAP
SOAP est un protocole de transmission de message qui définit un ensemble de règles
et d’extensions [125]. Il est utilisé pour exécuter des dialogues requête-réponse RPC (Remote
Procedure Call). Il n'est pas lié à un protocole particulier mais http est le plus utilisé. Il n'est
pas non plus lié à un système d'exploitation ni à un langage de programmation. Donc,
théoriquement, les clients et les serveurs d ’un dialogue peuvent tourner sur n'importe quelle
plateformes et être écrits dans n'importe quel langage du moment qu'ils pourraient formuler et
comprendre des messages SOAP. Il s'agit donc d'un important composant de base pour
développer des applications distribuées qui exploitent des fonctionnalités publiées comme des
services par des Intranets ou Internet.
La spécification SOAP se divise en quatre parties :
¾ l’enveloppe SOAP, qui définit le contexte d’un message, son destinataire, son contenu
et différentes options :
23
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
;
¾ les règles de codage SOAP, définissant la représentation des données d’une
application dans le corps d’un message SOAP (en particulier leur structure) :
SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" ;
¾ le protocole RPC, qui définit la succession des requêtes et des réponses ;
¾ la définition de l’utilisation de http comme couche de transport des messages SOAP.
POST / HTTP/1.1
SOAPAction: "http://…"
Content-Type: text/xml; charset=utf-8
Host: localhost:…
Content-length: …
¾ Les règles de codage utilisant XML Schéma pour décrire la structure des données
constitutives des messages SOAP.
¾ Les extensions SOAP : des mécanismes d’extensibilité qui permettent d’étendre les
fonctions d’un service Web XML en modifiant directement le message SOAP émis ou
reçu, sans altérer les performances. Il est ainsi possible d’implémenter des algorithmes
de chiffrement ou de codage sur un service Web existant (ceci sera explicité dans le
dernier chapitre)
2.6.2. Les inconvénients SOAP
Même si SOAP ressemble beaucoup en terme de fonctionnalité à des protocoles
comme IIOP pour CORBA, ORPC pour DCOM, ou JRMP (Java Remote Method Protocol)
pour Java, il possède un avantage indéniable. En effet, SOAP utilise un mode texte alors que
les autres fonctionnent en mode binaire, cela facilite le passage des équipements de s écurité.
De même il faut mentionner que l’utilisation du protocole SOAP pose des problèmes qui
concernent principalement l’interopérabilité des messages SOAP de type RPC. Sous entendu,
une requête SOAP non traitée convenablement implique un service (quelque soit la source ou
la destination) non exploitable. La plupart des problèmes posés par SOAP ne concernent pas
directement le protocole en lui- même mais plutôt les protocoles utilisés, comme XML ou
http. Ces problèmes peuvent être divisés en trois catégories :
a) Problèmes liés à HTTP
Certaines balises spécifiques à SOAP ne seront pas bien interprétées par tous les
clients http. Cela va dépendre du client et peut ne pas fonctionner dans certains cas. On peut
prendre l’exemple de la fonction SOAPAction : la valeur de SOAPAction doit être entre
guillemets sauf s’il s’agit d’une valeur nulle.
Exemple : « SOAPAction: http://test.org/ » ou « SOAPAction: »
Cependant certains clients ne sont pas capables de fournir une valeur d’entête http nulle, si
le serveur est en attente.
b) Problèmes liés à XML
24
Les problèmes d’interopérabilité XML concernent l’analyse du langage XML.
SOAP repose sur l’utilisation de ce langage, donc si XML pose des problèmes
d’implémentations, ceux-ci vont poser des problèmes pour SOAP[28].
c) Problèmes liés à SOAP
En lui- même, SOAP est relativement simple ; il requiert que les messages soient
placés dans une enveloppe avec un texte inclus dans un élément dit corps. Cependant il existe
un certain nombre de problèmes d’interopérabilité comme par exemple le problème lié à
l’implémentation de l’attribut « mustUnderstand ». Les spécifications de SOAP indiquent que
si cet attribut est défini sur la valeur «1», il devra être traité. Pourtant certaines
implémentations de SOAP ne le font pas. De nombreux autres problèmes d’interopérabilité
ont été découverts, ils sont consultables sur le forum http://groups.yahoo.Com
/group/soapbuilders. Cette liste contribue grandement à l’amélioration de protocole SOAP.
De nombreux fabricants, y compris Microsoft et IBM, ont accepté SOAP comme
protocole standard pour accéder à des objets distants. Mais SOAP n’aborde pas pour des
raisons de simplicité les aspects concernant la construction d’un modèle objet. Il n’est rien
aussi à propos du nettoyage distribué de la mémoire, de la sécurité du type ou du versionnig
des communications http bidirectionnelle et de l’activation d’objet par référence ou sans objet
[31]. La figure 2.12 représente les opérations client et serveur pour la transmission d’un
message SOAP.
1-Passage de données en SAOP-XM L.
2-Convertir la représentation des
données en ASCII
3-Ecrire ASCII en Buffer
4-Initialisation du réseau de
transmission
Client
Serveur
Requête SOAP
1-Lire du réseau dans le buffer.
2-Prasseur XML
3-Manier des éléments
4-Convertir ASCII à la représentation
machine
Figure 2.12 : Opérations pour émission et réception d’un message SOAP
Actuellement, et vue l’utilisation croissante du protocole SOAP, un autre protocole est
élaboré, C’est le protocole REST (REpresentational State Transfer). REST en réalité n'est pas
un protocole en soi, ni une technologie, mais une «philosophie» de l'utilisation du Web. Il
défini une architecture de services Web qui fonctionne de la même manière que SOAP et
XML-RPC. Cette architecture part du principe selon lequel Internet est composé de
ressources accessibles à partir d'une URL. A la requête d’URL sera renvoyée une
25
représentation de la ressource demandée. Cette représentation place l'application cliente dans
un état (state) donné. Si l'application cliente lance un appel sur un des liens de la
représentation en cours, une autre ressource est appelée, dont une représentation est envoyée.
Ainsi, l'application cliente change d'état (state transfer) pour chaque représentation de
ressource. Il faut bien noter que REST n'est pas en soi un standard : il n'existe pas de
spécification du W3C pour le décrire. Il s'agit plutôt d'un style d'architecture, d'un «mode de
compréhension du Web» sur lequel le développeur construit ses services (Web). REST fait en
revanche usage à des standards Web : protocole http, URLs, formats de fichiers pour la
représentation des ressources (XML, HTML, JPEG...), types MIME pour la description de ces
représentations. SOAP et XML-RPC ne suivent pas la spécification http, car ils ajoutent une
nouvelle couche d'abstraction par-dessus le protocole, plutôt que de l'utiliser tel qu'il a été
conçu. De même, leur utilisation des URIs n'est pas idéale comme il est déjà mentionné. Mais
aujourd'hui, tous les langages modernes disposent de fonctionnalités qui leurs permettent
d'exploiter des services Web de type SOAP ou XML-RPC sans se soucier de la verbosité de
leurs messages sortants et entrants. C'est d'ailleurs la raison pour laquelle ces deux techniques
ont tant de succès vis-à-vis de REST : les outils sont disponibles, tandis que REST nécessite
de mettre en place ses propres méthodes (même si le protocole, existe déjà).
De SOAP ou XML-RPC, le choix des développeurs tend à se porter sur la première
méthode, du fait de certains défauts dans la spécification de la seconde : manque de
précisions, confusions sur certains aspects (support Unicode, notamment), mots de passe
transmis en clair. XML-RPC reste un format très utilisé par de nombreux développeurs, et est
largement implémenté. La meilleure direction à prendre lors de la construction d'un service
Web serait bien entendu d'implémenter les trois, mais en l'état actuel des choses, les méthodes
à implémenter sont REST pour la simplicité, et SOAP pour le support (Microsoft/W3C).
XML-RPC semble ne plus être qu'un bonus donné aux développeurs qui ne souhaite pas
manipuler ces deux autres méthodes.
2.7 Conclusion
Lorsque les communications entre les applications dépassent le cadre du point à point
et lorsque les échanges entre des systèmes hétérogènes deviennent complexes, les
mécanismes d’intégration existants n’apportent plus une réponse satisfaisante à cette
problématique. Il devient alors nécessaire de proposer un nouveau modèle de collaboration
offrant une interopérabilité entre les différentes sources d’informations. C’est l’objectif des
architectures orientées vers les services SOA (Service Oriented Architecture), qui
actuellement, avec les Web services bénéficient d’un socle technologique favorisant leur
avènement.
L’objectif d’une telle intégration entre de différents réseaux purement hétérogènes
(PSTN, IP, réseaux intelligents, réseaux mobiles,…) est d’étendre le périmètre restreint d’une
telle application à celui de l’autre, en la connectant aux autres applications pour qu’elle puisse
échanger des informations afin de favoriser la cohérence des données concernant les clients,
les fournisseurs, partenaires,…
Dans les chapitres suivants, nous proposons des méthodes et des architectures à base
de SIP, Web services, IMS pour assurer l’intégration, la création et la sécurité des services
télécoms sur réseau IP.
26
Chapitre 3
Intégration des services télécoms sur IP avec SIP
Résumé du contenu
3.1. Introduction
3.2. Correspondance et intégrations entre SIP et IN
3.3 ENUM ou la correspondance DNS-E164.
3.4. Problème de localisation des Gateways
3.5 La solution TRIP
3.6 Intégration des services télécoms sur IP avec SIP
3.7 Conclusion
3.1 Introduction
Les opérations de commutation au niveau du réseau PSTN ainsi que au niveau de
réseau intelligent sont réalisées par des commutateurs permettant selon la requête de
signalisation SS7 d’atteindre la destination correcte des appels émis par un client et localisé le
terminal destiné. La localisation est selon un plan de numérotation standardisé au niveau
national et international sous le format E.164. Or au niveau du réseau IP sur lequel repose le
protocole de signalisation SIP, le routage est assuré par un des protocoles de routage, RIP,
OSPF, EGB,… où chaque terminal est spécifie par son adresse IP (@IP). Le protocole de
routage permet d’acheminer une requête de la source jusqu’au la destination voulue, en se
référant à un nom de domaine, appelé DNS (Domain Name Server) qui permet de convertir
l’adresse IP de la machine en un nom et vise versa.
Ces deux plans d’adressage différents, ainsi que ces deux techniques de localisation
des terminaux différents, nécessitent plusieurs règles des communications (protocole s)
standards ainsi que des Gateways d’adaptations pour faire une correspondance physique et
logique entre eux. L‘objectif de cette correspondance est ne pas faire de la téléphonie sur IP
ou de la communication vocale entre un terminal PSTN et un terminal IP ou entre deux
terminaux IP, ceci est déjà fait, et il existe actuellement plusieurs logiciels qui présente
chacun son propre interface graphique pour ces opérations. L’objectif de cette correspondance
qui contribue notre première tâche de travail est de permettre aux clients IP d’être similaire à
ceux du PSTN vis avis ou service à valeur ajoutée (services télécoms) disposé par le réseau
intelligent.
27
Dans ce qui suit, nous explicitons cette tâche, et nous introduisons en premier lieu la
correspondance SIP–IN, SIP-Intelligent Network ainsi que la technique d’interconnexion. En
deuxième lieu, nous présentons une méthode qui permet d’intégrer les services télécoms sur le
réseau IP, et nous explicitons des méthodes qui permettent la correspondance adéquates entre
les deux plans d’adressages et la localisation des terminaux et de Gateways.
3.2 Correspondance et intégration entre SIP et IN
La création d’un service par SIP est possible par les trois méthodes INVITE, Bye et
options et les champs d’entête SIP Contact, Also, Call-Disposition Replaces et Requested-by
qui sont des extensions de SIP spécifiées par IETF [9,10]. Certains services sont déjà spécifiés
par l’IETF [9] en utilisant les méthodes et les champs d’entête déjà cités, tels que, Call Hold,
transfert d’appel, renvoi d’appel et third party control.
SIP ne peut pas faire fonctionner le modèle d’appel IN directement pour accéder à ces
services. La solution sera alors de contourner la machine d'états de l'entité SIP avec la couche
IN en sorte que l’acceptation d'appel et le routage soient exécutés par la machine d’états et les
services accèdent aux couches IN avec le modèle d’appel IN [13]. Le modèle de la
programmation des services avec SIP consiste donc à ajouter sur les serveurs SIP une couche
IN pour gérer l’interconnexion avec le réseau intelligent qu’on appelle SIN (SIP Intelligent
Network) [12]. Cette opération nécessite la définition d’une correspondance entre le modèle
d’appel de l’IN et le modèle d’appel de SIP c’est à dire une correspondance entre la machine à
états du protocole SIP et la machine à états de l’IN. Il sera nécessaire ici de rappelé que
l’entité SIP définit l’entête Record_Route qui permet de rendre les serveurs SIP fonctionnels
en mode avec états jusqu’à libération de l’appel. Un appel sera donc traité par les deux
machines. La machine à état SIP qui traite l’initiation d’appel et la délivrance de réponses
finales, et la couche IN qui interagit avec le nœud intelligent SCP pour fournir les services
lors du traitement de l’appel [14]. La figure 3.1 illustre cette interconnexion, SIP-IN.
Parallèlement au machine à état de l'IN, on définit du coté appelant et appelé l’entité
(O-SIP) et (T-SIP) qui sont les entités correspondant, respectivement, au O_BCSM et
T_BCSM du modèle d’appel IN (figure 3.2)
SCP
SCP
SIN
PS
O-SIP
TN
SIN
GW
GW
Figure 3.1 : interconnexion SIP-IN
28
T-SIP
Serveur
INVITE
T_BCSM
O_BCSM
Initial
O_NULL
Proceeding
Auth_O_Att
T_NULL
Client
Initial
100 Trying
Collect_Inf
Route Req
Service call Req
Analyse_Inf
Auth_T_Att
Route Res
Select_Route
Select_Facil
Auth_Call_Set
180 Ringing
Send_Call
Service call Resp
O_Alerting
200 OK
Service call Resp
Success
Confirmed
Bye
Service call Resp
T_Alerting
Service call Resp
O_Active
T_Active
O_NULL
T_NULL
Completed
Initial
INVITE
Present_Call
Service Call
Request
Calling
180 Ringing
Call Proceeding
200 OK
ACK
Completed
Bye
Initial
Figure 3.2 : Correspondance entre modèle d’appel IN et l’état d’appel SIP.
Les 11 PICs dans O_BCSM se déclenchent quand une requête d'appel (INVITE de
message SIP) est envoyée par UAC et reçue par le serveur SIP de la partie demandeur O-SIN
qui initialise le modèle d’appel d’IN. Ce serveur SIP crée un objet O_BCSM qui l’initialise au
PIC O_NULL. Les PICs suivants dans l’appel : AUTH_ORIG_ATT, COLLECT_INFO,
ANALYZE_INFO, SELECT_ROUTE, AUTH_CALL_SETUP, CALL_SENT, O_Alerting et
O_Active se déclenchent respectivement.
La figure suivante, 3.3 représente la cartographie visuelle de la machine à état de
protocole SIP interconnecté avec la machine à état du modèle d’appel O_BCSM, c’est à dire
du réseau intelligent et la figure 3.4, donne la cartographie visuelle de la machine à états de
protocole SIP interconnecté avec la machine d’états du modèle d’appel T_BCSM.
Quand le serveur SIP de terminaison reçoit le message INVITE, il c rée l’objet TBCSM et l’initialise au PIC T_Null, cette opération est réalisée par l’état « Proceeding » qui
commande les cinq PICs : T_NULL, Authorize_Termination_Attempt , Select_Facility,
Present_Call, T_Alerting, T_Active .
Le PIC Select_Route de modèle de la communication de la figure 3.3 permet de
sélectionner une route pour passer à un serveur adéquat à fin d’établir une communication. La
route ou le chemin peut être selon la requête INVITE un URI ou un nombre E.164, c’est à
dire un numéro de la téléphonie classique PSTN.
Pour la localisation de domaine de l’UA appelé ainsi que leurs adresses, le serveur SIP
utilisé, le cherche dans un serveur d‘enregistrement où l’UA est enregistré (REGITER) en
utilisant la procédure DNS pour trouver l’URI du SIP. Le protocole SIP emploi cette
procédure DNS pour permettre à un client de résoudre URI SIP en une adresse IP, un numéro
29
Figure 3.3 : modèle de communication du SIP à l’O_BCSM.
Figure 3.4 : modèle de communication du SIP à T_BCSM
de port et un protocole de transport du prochain client à contacter. Dans la section suivante on
explicite cette procédure.
Dans ce contexte, est- il possible de faire intégrer les services télécoms classiques de
réseau PSTN sous IP et de faire convertir les adresses téléphoniques PSTN en un nom du
domaine ? Et comment faire pour localiser ces différents DNS ? Dans ce qui suit, nous
présentons une méthode qui permet d’interroger les services télécoms prédéfinis pour le
réseau PSTN avec SIP sous IP.
30
3.3 ENUM ou correspondance DNS-E164
Le standard ENUM décrit dans le RFC2916 de l'IETF définit un protocole et une
architecture basée sur le système de serveurs de nom de domaine d'Internet DNS permettant
de faire une correspondance à de numéros de téléphone E.164, de identifiants de services de
communication, avec un ordre de priorité (e- mail, URL, adresse SIP de serveur de téléphonie
sur IP, messagerie vocale, autres numéros de téléphone,…). Le protocole ENUM permet donc
de trouver, à partir d'un simple numéro de téléphone classique, les diverses adresses de
l'utilisateur recherché. L'utilisateur final peut aussi personnaliser la manière dont il peut être
joignable. Il est facile d'ajouter ou de modifier ces informations supplémentaires sans changer
le numéro utilisé pour l'accès. De ce fait, le protocole ENUM est vu comme une passerelle
technique de correspondance entre le réseau Internet et le réseau de télécommunication
commuté PSTN permettant ainsi l'interopérabilité entre ces deux réseaux [20]. Pour la
recherche des services associés, le protocole ENUM utilise une convention selon laquelle les
chiffres d'un numéro E.164 sont écrits à l'envers et sont tous placés dans des "zones" DNS
distinctes, et sont ensuite concaténés avec un autre domaine. L'IAB (Internet architecture
board) a proposé que ce domaine soit « e164.arpa » [19]. Le nombre est converti au nom du
domaine en utilisant un plan [17]. La figure 3.5 illustre la méthode ENUM :
Soient A, un terminal classique de type PSTN et B, un UAC SIP
Le scénario de l’appel est le suivant :
1 : A numérote B et initie un appel
2 : Le réseau RTC achemine l’appel jusqu’au une passerelle disposant de la fonctionnalité
ENUM.
3 : La passerelle convertit le numéro de B en une adresse Internet x.x.x.x.x.x.e164.arpa
4 : La passerelle lance une requête auprès du serveur DNS
5 : Le serveur DNS renvoi l’adresse associée au nom du domaine x.x.x.x.x.x.e164.arpa par
laquelle le correspond est joignable (une adresse SIP)
6 : Le DNS renvoi l’adresse IP du serveur SIP associée à l’adresse URL.
7 : Le serveur SIP est consulté par son adresse.
8 : Le serveur SIP achemine l’appel à B.
B
7
2
3
8
6
A
RTC
R éseaux
IP
1
S erveur S I P
P asserelle
4
5
S erveur DNS
Figure 3.5 : Réseaux utilisant ENUM
31
ENUM définit plusieurs types de services. Un de ces services est nommé «E.164 to
URI», désigné par “E2U” et qui permet la translation de l’E.164 en une adresse URI. Ce
service répond à notre besoin pour une telle opération d’invocation des services télécoms
PSTN par un terminal IP. La table 3.6 représente les différents services proposés par ENUM:
catégories Type
Subtype
Talk
Msg
Info
Srs
All
Tel: ,SIP: ,H323:
mailto: ,tel:
Http: ,Https: ,Ftp:
SIP:, H323: ,LDAP:
ENUM:
Voice, Video
Email, Fax, SMS
Web, Ftp
SIP, H323, Ldap
Figure 3.6 : Table des services ENUM.
Le modèle de répertoire de numéro de téléphone et des services basé sur ENUM, est
partagé en quatre niveaux :
x
Le premier niveau est un plan de numéro de téléphone à la structure d’arbre. La
structure hiérarchique de DNS est employée et le plan peut impliquer un ou plusieurs
DNS. On trace dans ce niveau l’hiérarchie de nombre E.164 à l’hiérarchie DNS en
utilisant les codes du pays.
x
Le deuxième niveau est l’autorité de ce nombre au service d’enregistrement. Le
service d’enregistrement est l’ensemble des services enregistrés pour un numéro de
téléphone donné. Le second niveau emploi le DNAME et CNAME du DNS pour
fournir la redirection de l’autorité désignée à l’enregistrement [17].
x
Le troisième niveau est un ensemble de services. Il indique les services qui sont
disponibles pour un numéro de téléphone spécifique. Il peut y avoir des consignes
multiples pour le même service, en indiquant d’une manière compétitive ou
redondante des fournisseurs des services. Le NAPTR (Naming Authority Pointer
Record) est employé au troisième niveau. La réponse à la question d’un client est un
ensemble de NAPTR records, et le client sélectionne le service à employer pour
l’action destinée.
x
Enfin, le quatrième niveau, qui peut être fourni si nécessaire. Ce niveau fournit des
attributs spécifiques pour les services qui sont connus seulement par le fournisseur du
service. La figure 3.7 représente ces différents niveaux.
Pour établir un appel à un terminal SIP sur un réseau IP, l’adresse IP de la destination
doit être connue (RFC 3261). La RFC 3263 (locating SIP servers) apporte des changements
substantiels, elle commence par préciser que si l’URI contient une adresse IP, mais sans
spécifier de protocole, alors UDP doit être utilisé pour joindre cette adresse. De même si le
cible n’est une adresse IP, mais un port est spécifie, alors UDP doit être utilisé. Dans les
autres cas, c'est-à-dire si l’URI ne contient pas d’adresse IP, ni un numéro de port, ni de
spécificateur de protocole de transport, c’est le cas d’un domaine utilisé par ENUM, alors il
faut utiliser le mécanisme des enregistrements DNS de type NAPTR défini dans RFC 2915
pour résoudre l’URI en une adresse de transport où envoyer le message INVITE.
32
TIER 0
".xxx"
TIER 1
".3.3.xxx"
".4.4.xxx"
"0. 0.0. 7. 7.4.0. 4.1.3. 3.xxx"
TIER 2
.. .. .
-- -- ->SIP URL po ur la t élép ho n ie IP ,
adr esse e-m ail, adresse web,
…
email
web
téléphone
pager
TIER 3
Figure 3.7 : Différents niveaux ENUM [18]
Lorsqu’un système est en besoin de localisé la ressource appropriée pour joindre le
numéro téléphonique x.x.x.x.x.x.x, il doit d’abord interroger le DNS pour obtenir
l’enregistrement de type NAPTR (numéro de type est 35 défini par les RFC 2168 et 2915)
correspondant au pseudo-nom de la machine x.x.x.x.x.xe164.arpa.
L’enregistrement de type NAPTR permet d’attacher au nom DNS une règle de
réécriture sous forme d’une expression régulière. Le résultat de cette réécriture est une chaine
de caractères qui peut être interprétée comme un nouveau nom de domaine ou bien comme un
URI qui peut être utilisé pour effectuer des recherches.
La syntaxe de l’enregistrement de type NAPTR est de la forme :
Domaine TTL Classe Type Ordre Préférence Drapeaux Service ExpReg Remplacement
Les champs Domaine TTL et Classe sont présents dans tous les enregistrements DNS. Le
champ Type vaut 35 pour NAPTR. Les champs Ordre et Préférence spécifient l’ordre dans
lequel traite les enregistrements si une requête retourne plusieurs enregistrements. Les valeurs
du champ Drapeaux (S, A, P et U) indiquent comment traité la requête suivante. La requête
suivante devrait rechercher des enregistrements de type SRV (Drapeau S), de type A
(Drapeau A) ou bien un protocole spécifique (Drapeau P). Si le drapeau est U alors
l’expression régulière définie dans le champ ExpReg doit être appliquée au nom de domaine
courant afin d’obtenir une nouvelle URI. ENUM utilise ce drapeau U où on précise dans le
champ Service, le protocole qui doit être utilisé pour l’étape suivante de l’algorithme de
résolution (SIP, tel, …) ainsi que le type de service qui sera fourni. C’est «E2U» dans le cas
ENUM.
Pour une application de type «SIP + E2U» ou «tel + E2U» ou autre, si nous supposons qu’un
utilisateur veut être un SIP UA ou un abonné SIP dans un domaine domain. L'agent SIP doit
premièrement s’enregistrer avec le serveur SIP dans ce domaine pour bénéficier des services
SIP. Puis il doit s’enregistrer auprès du serveur de domaine DNS (figure 3.8) pour avoir
l’accès aux services prédéfinis par ENUM, de la façon suivante (figure 3.9) :
33
$ORIGIN 2.2.7.3.5.3.8.9.6.1.2.e164.arpa.
IN NAPTR 100 10
IN NAPTR 100 10
IN NAPTR 100 10
IN NAPTR 100 10
IN NAPTR 100 10
"u" "sip+E2U"
"u" "mailto+E2U"
"u" "http+E2U"
"u" "tel+E2U"
"u" "ldap+E2U"
sip:[email protected]"
.
mailto:[email protected]" .
http://hand.enig.tn".
tel:+216-98-353722"
.
ldap://ldap.tn/”
Figure 3.8 : Enregistrement pour accès à un service ENUM (différents cas)
IN A @IP
ou
IN SRV 0 1 5060 server.domain
Figure 3.9: Enregistrement d’un client dans un domaine
Le DNS resolver dans l’enregistrement NAPTR, contient aussi l’UA SIP, donc il fait
un NAPTR QUERY pour les serveurs de SIP dans le domaine qui lui correspond suivant le
service demandé. La figure suivante, figure 3.10 représente l’échange entre le serveur DNS et
le DNS resolver selon le service défini dans NRPTR (cas «SIP + E2U»).
SIP proxy ou UA
DNS resolver
DNS Server
DNS QUERY (NAPTR)
2.2.7.3.5.3.8.9.6.1.2.e164.arpa
DNS RESPONSE (NAPTR)
IN NAPTR 100 10 "u" "sip+E2U" sip:[email protected]
DNS QUERY (NAPTR)
enig.tn
DNS RESPONSE (NAPTR)
0 10 "s" "sip+D2U"
_sip._udp.enig.tn
_sip._udp.enig.tn
DNS RESPONSE (SRV)
10 0 5060 sip.enig.tn
DNS QUERY (A)
sip.enig.tn
DNS RESPONSE (A)
198.168.200.4
Figure 3.10 : Exemple de DNS et NAPTR services
34
L’un de problèmes majeurs dans les applications SIP, est la localisation des serveurs
SIP (serveur d’enregistrement, serveur proxy, serveur de redirection, etc). Ces serveurs
peuvent contenir une base de données où les différentes informations relatives au client sont
stockées, une méthodologie de détermination de Gateways ou une technique d’interprétation
de différentes informations contenues dans une requête lors d’une opération SIP [12].
3.4 Le problème de localisation des Gateways
Le réseau IP ainsi que les réseaux PSTN sont liés avec un grand nombre de Gateway
et des nœuds publiquement disponible. Dans le but de faire une connexion entre tout IP,
PSTN et les terminaux possibles, le problème de l’emplacement du terminal et de
l’emplacement du Gateway doit être résolu [13]. On parlera donc, dans ce qui suit des
problèmes de la détermination du meilleur chemin à la destination, dans une combinaison IP
et réseau PSTN.
Pour identifier une destination d’un appel à PSTN, le visiteur compose le numéro de
téléphone dans le format E164, le numéro de téléphone est analysé chiffre par chiffre à travers
les commutateurs dans le réseau PSTN jusqu'à ce qu’il atteint la destination. La différence
principale entre PSTN et IP est qu’un nom est un identificateur pour l’utilisateur de terminal
et une adresse est un locateur et l’adresse devrait avoir une certaine forme de structure pour
permettre une opération de routage ciblée. Tandis que dans Internet, le nom est un nom de
domaine. Ce domaine est désigné par une adresse IP employée pour les opérations de routage.
Dans les appels de terminaux de téléphone IP, l’adresse de la hôte de la destination,
doit être trouvée et un Gateway doit être situé, de même dans le sens contraire, du PSTN au
réseau IP, la destination doit être trouvée et un Gateway doit être aussi sélectionné. Ce
problème sera d’avantage plus compliqué, par l’existence de différents protocoles de
signalisation, de différents codecs et de mécanismes de cryptographie et de sécurités
différentes pour des différents opérateurs. Dans la figure 3.11 on trouve quatre pays
différents, c’est à dire quatre opérateurs différents au minimum. Si on suppose que chacun
d’entre eux utilise leur propre technique d’adressage, de sécurisation, de numérisation et de
localisation de Gateways, la communication internationale est possible mais nationale sera
irréalisable pratiquement.
Figure 3.11 : Illustration de problème de localisation des Gateways
35
Ce problème de localisation peut être subdivisé en deux sous problèmes :
¾ Le problème de la découverte de Gateways : il faut obtenir les adresses des différents
Gateways disponibles, qui sont capables de complétés l'appel à la destination donnée
et qui soutiennent le protocole de signalisation et le codec utilisés.
¾ Le problème de la sélection de Gateway : il faut sélectionner un de ces Gateways en
respectant les politiques de l'opérateur et les opérateurs intermédiaires et en observant
l'emplacement du Gateway qui satisfait les conditions imposées par l’appel.
Le problème de la découverte des Gateways pourrait être résolu par un répertoire
global de tous les Gateways disponibles dans le monde. Ce répertoire doit être distribué.
Cependant, tous les opérateurs ne sont pas prêts de publié les informations sur les positions
des Gateways ainsi que leurs fonctions. La méthode de découverte des Gateways devrait donc
montrer seulement les Gateways qu'un réseau donné peut l’employer. Cela, implique la
sélection d’un Gateway à partir d’un ensemble réduit des Gateways sélectionnés.
Le problème de la sélection de Gateway est conduit généralement par les politiques
des opérateurs. L'opérateur prévoit généralement des préférences concernant la sélection de
Gateway, selon les exigences du visiteur, qui est un client provenant du réseau, ou selon un
contrat de co-opération avec un autre opérateur. Généralement, un opérateur possède les
Gateways qui peut lés contrôlés et peut l'employés.
En général, il est difficile de savoir qui devrait exécuter la sélection. Préférablement,
tous opérateurs le long de parcours de l’appel devraient être capables d'influencer sur la
sélection des Gateways. Cependant, dans le cas le plus simple, les politiques sont concentrées
au réseau origine d’appel. Les politiques des autres réseaux sont selon le contrat de coopération fait avec le réseau origine d’appel. La sélection donc de quel Gateway à employer
est influencée par de nombreux facteurs :
Premièrement, l’emplacement du Gateway est important. Il faut que le Gateway soit près des
terminaux pour minimiser l’usage des ressources.
Deuxièmement, le rapport d’affaire : le service de Gateway implique des coûts quand des
appels sont complétés à une destination PSTN. Les fournisseurs de Gateway, dans la plupart
des cas, veulent utiliser leurs Gateways. A cause de cela, l’usage des Gateways peut être
limité aux groupes des utilisateurs. Toutes ces politiques et tous ces rapports influencent dans
la sélection du Gateway [13].
En outre, l’utilisateur du terminal peut avoir des exigences sur le Gateway. L’utilisateur du
terminal peut préférer un certain fournisseur qui fourni une caractéristique spécifique. Le
visiteur peut employer un protocole spécifique ou un codec qui est soutenu par certains
Gateways seulement. De même, il ne faut pas oublier que la capacité du Gatewa y est limitée.
Il est évident qu’une méthode automatique pour la sélection des Gateways et un protocole
pour échanger de l’information entre Gateways et les opérateurs sont nécessaires.
Plusieurs protocoles ont été développés par le IETF pour résoudre le problème de
localisation, parmi eux, on trouve, PINT (PSTN and Internet INTerworking), SPIRITS
(Servers in the PSTN Initiating Requests to InTernet Servers) et TRIP (Telephony Routing
over IP). Ce dernier est celui qui a été adopté pour notre application. Ce protocole permet de
36
résoudre le problème d’emplacement de Gateway en distribuant le routage de l’information
entre des entités sur le réseau IP. Dans la suite nous présentons ce protocole et nous montrons
comment est exploité pour assurer la localisation des serveurs SIP et la détermination du
meilleur chemin pour atteindre la destination correcte.
3.5 La solution TRIP pour la localisation des Gateways
Dans le réseau SIP, on trouve une entité logique appelée, serveur d'emplacement (LS).
Le serveur d’emplacement permet de situé le prochain saut pour une session d’appel. Le
serveur d'emplacement (LS) co-réside avec le proxy SIP, et fait suivre les requêtes d’un
service. Pour une opération SIP de base, le LS emploi les cartographies d’emplacements
installées lors d’enregistrement d’un agent utilisateur. Chaque agent utilisateur doit
périodiquement enregistrer son adresse actuelle de réseau avec le service SIP register. Le
procédé d'enregistrant permet à LS de connaître tous les agents utilisateurs et les adresses
associées dans son domaine local. Si la destination d’un agent utilisateur est dehors du
domaine local, un DNS doit normalement situer la prochaine information sur le saut à faire.
Le LS non aucune possibilité de faire router les décisions de bases sur les informations
dynamiques de ressource de réseau SIP de différents domaines. Cette incapacité du LS était la
raison pour le développement d’un nouveau protocole de routage de la téléphonie sur IP
(TRIP). La tâche de TRIP est donc, de bâtir une table de routage pour les proxys SIP. Les
proxys utilisent cette table pour prendre des décisions pour acheminer de requêtes de sessions
SIP. Le transport des messages TRIP est réalisée par le protocole TCP, ceci élimine le besoin
de faire la fragmentation, retransmission, acknowledgement, et les séquences dans TRIP. Ces
différentes opérations sont faites par TCP.
Dans le réseau TRIP, le serveur d’emplacement (LS), est un nœud de TRIP, il permet
l’échange de l’information avec d’autres serveurs d’emplacement (LS). Cette information
inclut des données sur le chemin jusqu’au la destination, les itinéraires vers ces destinations et
les propriétés de Gateways reliant le PSTN et le réseau IP.
Par analogie avec les protocoles des routages du modèle TCP/IP (RIP, OSPF, EGP,
IGP,…), TRIP emploi le concept du domaine administratif de la téléphonie IP (IP telephony
Administrative Domain : ITAD) qui est équivalent au AS (Autonomous System) pour les
réseaux IP, où un ITAD regroupe les différents serveurs d’emplacement, qui sont gérés par un
seul opérateur, comme le montre la figure 3.12. Le protocole TGREP (Telephony Gateway
REgistration Protocol) qui figure dans le schéma est un protocole d'enregistrement d'itinéraire
pour des destinations téléphonique, il contient deux interfaces, une de l’origine d’appel et une
autre liée avec le système de routage TRIP.
La fonction principale de TRIP est la distribution de l’information entre les ITADs.
TRIP contient aussi des fonctions pour la synchronisation de domaine et le routage de
l’information. Il n’est pas nécessaire que tous ITADs dans le monde soient reliés (figure
3.13). Le serveur d’emplacement sélectionne les itinéraires à employés dans son propre
domaine et le chemin d’envoi du domaine selon ses politiques locales. Les serveurs
d’emplacements recueillent les informations et l’emploient pour répondre aux questions près
des itinéraires aux destinations. C’est pour cette raison TRIP emplo i deux types des
protocoles, I-TRIP (Interior TRIP) pour le routage à l’intérieur d’un ITAD et E-TRIP
(Exterior TRIP) pour router les informations entre les ITADs.
37
ITAD
SIP Proxy
SIP Proxy
TRIP
a
upd
LS
te
TR
IP
I-TRIP
LS
SIP Proxy
up
dat
e
TRIP up
date
LS
TGREP
TGREP
GW
GW
GW
PSTN/SS7
Figure 3.12 : Routage TRIP dans un ITAD.
ITAD B
ITAD A
SIP Proxy
SIP Proxy
SIP Proxy
SIP Proxy
LS
TRIP
upd
ate
LS TR
IP
I-TRIP
TRIP up
date
E-TRIP
SIP Proxy
up
da
LS
te
u pd
ate
IP SIP Proxy
up
da
te
LS
TGREP
TGREP
TGREP
GW
LS TR
I-TRIP
TRIP up
date
LS
TGREP
TRIP
GW
GW
GW
GW
PSTN/SS7
Figure 3.13 : Communication avec TRIP entre deux ITADs
TRIP traite trois types de routage selon une base d’information TRIB ( Telephony
Routing Information Base), comme il le montre la figure 3.14 [4] :
1- Les routages externes reçus des pairs externes (Adj-TRIBs-in external).
2- Les routages internes reçus d’un autre serveur d’emplacement dans le même ITAD
(Adj-TRIBs- in internal).
3- Les routages locaux qui sont localement configurés ou reçus d’un autre protocole de
routage (Local routes).
38
Loc-TRIB
Decision Process
Adj-T RIBs-In
In
(Internal LSs)
Adj-T RIBs-out
Ext-TRIB
TRIB
In
Adj-T RIBs-In
(External LSs)
Local Routes
Figure 3.14 : TRIB et routage
De point de vue format de protocole TRIP (Figure 3.15), l’entête TRIP est de 3 octets,
2 octets pour s’informer de la longueur du datagramme TRIP (lenght), et un octet pour
designer le type de message TRIP qui peut être selon l’opération :
1. OPEN : pour établir une connexion
2. UPDATE : pour l’échange des informations sur les routes.
3. NOTIFICATION : pour l’information sur une erreur.
4. KEEPALIVE : Pour assurer que le proche nœud fonctionne
@MAC
IP header
TCP header
TRIP header
lenght Type
Data :::
Data :::
Cas du message OPEN
Version (= 1)
Reserved
My ITAD
TRIP Identifier
Hold Time
Optional Parameters length
Optional Parameters (variable
Figure 3.15 : Format TRIP
39
De point de vue format de route TRIP, elle est définie comme la combinaison d’une
adresse de destination de téléphone et un protocole d'application : dans notre cas, c’est SIP.
L'adresse de transport associée avec cette destination de téléphone est inclue dans l’attribut
"NextHopServer" de l'itinéraire dans le format de message UPDATE de TRIP. Le message
UPDATE de TRIP est employé pour transférer les informations de routage entre les LSs et
pour construire la cartographie des ITADs. Figure 3.16
2 octets
Address Family
SIP
2 octets
Application Protocol
TRIP
TCP/IP
Type des routes TRIP et piles TRIP
…
2 octets
2 octets
Next Hop ITAD
Length
Server (variable)
Syntaxe NextHopServer
First Route Attribute
…….
Second Route Attribute
Figure 3.16 : Format de message UPDATE
Une opération typique de TRIP peut être expliquée de la façon suivante (figures
suivantes 3.17 et 3.18) :
Mise à jour : Soient deux ITADs, ITADA et ITADB, chacun à ses propres LS gérés par
TRIP. Les Gateways dans chaque ITAD registrent les préfixes de téléphone ou les adresses IP
qui correspondent avec leurs LSs. Un message UPDATE de TRIP informe les différents LSs
voisins des adresses supportées par son Gateway. En outre, les Gateways demandent de LS
des informations sur la localisation d’une destination si un appel est reçu.
ITAD B
ITAD A
SIP Proxy
SIP Proxy
SIP Proxy
SIP Proxy
LS2
UPDATE
LS2
SIP Proxy
SIP Proxy
LS1
LS3
LS3
LS1
GW1
GW5
GW5
GW1
GW4
GW3
GW2
GW2
Figure 3.17 : Mise à jour TRIP
40
GW3
GW4
Routage : Si le Gateway GW3 dans ITADB reçoit un appel d’adresse 192.130.12.* d’un
terminal pour un terminal 120.111.10.5
Le GW3 demande LS2.
Le LS2 renvoi à l’itinéraire NextHop: GW1.
Le GW3 envoi un message de SETUP au Gateway GW1.
Et l’appel abouti à leur destination
ITAD B
ITAD A
SIP Proxy
SIP Proxy
120.111.10.5,...
SIP Proxy
SIP Proxy
LS3
SIP Proxy
UPDATE
LS2
UPDATE
LS2
UPDATE
LS1
192.130.12.*
SIP Proxy
UPDATE
TRIP
LS1
TGREP
GW1
GW5
GW1
GW4
GW3
GW2
Setup 120.11
1.10.5
Destination
LS3
GW5
GW3
GW4
192.130.12.*
Figure 3.18 : Routage TRIP
Ces différentes opérations sont réalisées grâce à un algorithme de sélection d'itinéraire
qui parcourt les serveurs d'emplacements. Le but de cet algorithme est de généré le meilleur
itinéraire pour un préfixe donné et un protocole d'application (SIP) basé sur l'information
emmagasinée dans la base de données. LS retourne ceci comme l'itinéraire pour un préfixe
quand il est demandé par un protocole d'application. L'itinéraire obtenu ainsi, doit être
annoncé par le LS à ses pairs. L'algorithme assure aussi les changements d'information
d’itinéraire quand de nouvelles mises à jour, introduisant ou retirant des itinéraires à certains
préfixes doivent être assurées. Il est aussi la base de décision sur cer tains attributs associés
avec les itinéraires qui définissent les caractéristiques du chemin associés avec l'itinéraire.
La notion d'attributs dans TRIP joue un rôle important dans le fonctionnement efficace
et correct du protocole. L’attribut RoutedPath est employé pour préciser l'intermédiaire ITAD
qui doit être pris par SIP pour porter le préfixe de la destination. RoutedPath peut être
employé dans la sélection d'un itinéraire quand des itinéraires multiples sont présents : un LS
peut préférer l'itinéraire avec un nombre bas des ITADs. Le AdvertisementPath trace les
ITADs quand une annonce d'itinéraire (UPDATE) va voyager si loin. AdvertisementPath est
utile en détectant des boucles dans les itinéraires. Les attributs de préférences locales aident
dans la détermination du particulier LS préférée pour un itinéraire. Cela peut aider le routage
inter-domaine. TRIP soutient aussi l’équilibre de la charge de circulation à travers deux ou
plus de maillons entre deux ITADs. Cela est réalisé par l'emploi d'un attribut appelé
MultiExitDisc. Autres attributs comme Atomic Agregate et Communities sont aussi utilisés, ils
permettent de faciliter efficacement le routage.
Pour une paire session, il est possible de définir des filtres pour les entrées et les
sorties des informations de routage. Un serveur d'emplacement peut vouloir accepter un mis à
41
jour seulement si les attributs associés avec l'itinéraire suggèrent que la circulation de SIP ne
parcoure pas certain ITADs. Cela peut être assuré en vérifiant le RoutedPath attribut pour le
prohibited ITADs aussitôt que la mise à jour de routage est reçue sur la session TRIP.
Cette aptitude de filtrée des itinéraires, basée sur des attributs (pour les deux mises à
jour sortantes et entrantes) peut être très obligeante en planifiant et en optimisant des modèles
réseau pour la planification des capacités critiques. Elle peut aussi devenir accessible en
appliquant des règles entre des domaines administratifs.
3.6 Intégration des services télécoms sur IP avec SIP
Apres avoir présenté les différents outils nécessaires pour la localisation, le routage et
la numérotation IP, PSTN, on termine par la proposition d’une méthode basée sur les
différents outils déjà cités, pour intégrer et interroger les services télécoms définis pour le
réseau PSTN par IP. Nos clients peuvent être des terminaux SIP, tel PSTN ou IP. Les
éléments qui nous permettent de réaliser ceci sont :
¾ SIP REGISTER ou SIP NOTIFY pour l’enregistrement d’un client SIP ($ 3.2).
¾ ENUM ($ 3.3)
¾ DNS A, SRV, NAPTR pour serveur SIP ou l’enregistrement des services ($ 3.3)
¾ TRIP pour la localisation des Gateways ou des serveurs ($ 3.5)
¾ TRIB pour les bases de données locales de routage ($ 3.5)
Ces standards permettent de rendre l’interconnexion réseaux PSTN et réseaux Internet
facile et interopérable et par conséquent une interconnexion PSTN-IN-IP pour l’invocation
des services télécoms. La figure suivante 3.19 représente une proposition pour une
architecture de cette interconnexion.
Dans cette architecture, le ISG (Intelligent service Gateway), est un Gateway
présentant le processeur qui permet de réaliser les différentes transitions entre la machine à
états SIP de l’appelant et de l’appelé O, T et le modèle d’appel O, T du BCSM de réseaux
intelligents c’est à dire les éléments SIN présentés dans le paragraphe 3.2
Le schéma de la figure 3.19 permet de réaliser l’interconnexion PSTN-IN-IP ainsi que
et les opérations suivantes :
¾ Communication classique entre client SIP et client SIP : les liens mis en jeux dans cette
connexion sont respectivement : 1 + 2 + 3 + 4 + 5 + 7 + 13 + 14.
Dans ce cas le DNS avec LS jouent le rôle d’un serveur de localisation et permettent de
localiser le correspondant client SIP.
¾ Communication client SIP et client PSTN et vis versa : les liens mis en jeux dans cette
connexion sont respectivement : 1 + 2 + 3 + 4 + 5 + 7 + 10 + 11
Dans cette communication, l’ENUM est invoqué pour la conversion URI, E.164 ($ 3.3)
42
Figure 3.19 : Interconnexion PSTN-IN-IP
¾ Accéder à des services télécoms par un client PSTN : les liens mis en jeux sont : 11 + 10 +
12 + 9 : c’est le réseau intelligent classique.
¾ Accéder à des services télécoms par un client SIP : les liens mis en jeux dans cette
connexion sont respectivement : 1 + 2 + 15 + 8 + 8 + 15 + 3 + 4 + 5 + 7 + 13 + 14. La
figure suivante 3.20 illustre cet accès.
Figure 3.20 : Méthode d’accès aux services télécoms par SIP.
43
Dans cette architecture les trois protocoles SIP, TRIP et ENUM ainsi que le Gateway
ISG sont mis en jeux pour l’accès à des services de réseau intelligent normalement réalisés
pour des abonnés PSTN, par des clients SIP. Cette proposition permet aussi d’invoquer le
client SIP par des abonnés PSTN ou le contraire, sans accès au réseau intelligent.
Le diagramme de fonctionnement permettant l’accès aux services télécoms par un
client SIP est donné dans la figure 3.21.
Figure 3.21 : Accès à la IN par un client SIP.
3.7 Conclusion
L’approche d’intégration SIP et IN permet d’exploiter les services intelligents déjà
déployés dans IN, par des clients IP, à partir des mêmes états et événement décrit dans le
modèle d’appel de base BCSM.
TRIP et ENUM proposent théoriquement une solution idéale, qui permet de palier aux
problèmes de la translation E164, DNS et l’emplacement de Gateways. Ces deux protocoles
permettent de prolonger les solutions pour IP vers les réseaux PSTN et interconnecté ces deux
réseaux hétérogènes. Cette interconnexion définie une évolution technologique importante au
niveau des services offerts par chaque réseau ainsi que au niveau d’exploitation de ces
différents services.
De point de vue réseaux intelligents, certains autres problèmes restent à résoudre.
Avec les avancées technologiques certains services ne sont pas concevables par le réseau
intelligent tel que les services multimédias. L’absence d’une indépendance entre le service
demandé et sa mise en relation est un obstacle à la séparation du support. De même, le modèle
conceptuel du réseau intelligent est un ensemble de définition qui ne spécifie pas un langage
standard pour la modélisation et par conséquent pour la création des services. Ajoutons à tous
44
cela les nombres limités de SIBs responsables à la création des services, ce qui rend la
création de nouveaux services une tâche difficile.
Dans le chapitre suivant nous présentons une méthode définissant une souplesse aux
niveaux de la création de nouveaux services indépendamment des opérateurs et des
contraintes techniques PSTN.
45
Chapitre 4
Création des services télécoms avec Web services
Résumé du contenu
4.1. Introduction
4.2. Combinaison du SIP avec SOAP
4.3. Architectures existantes à base de Web service
4.4 Les architectures et les solutions proposées
4.5. Conclusion
4.1Introduction
Dans ce chapitre, nous proposons des méthodes et des techniques qui permettent la
création des services télécoms avec les Web services. Dans la première section nous
présentons la technique de combinaison de protocole SIP avec le protocole d’échange SOAP.
Dans la deuxième section nous rappelons les différentes architectures existantes et qui
permettent de créer certains services télécoms à base de Web service. Dans la dernière section
nous présentons notre contribution pour créer des services télécoms pour les différents
terminaux fixes ou mobiles.
4.2Combinaison du SIP avec SOAP
Le protocole SOAP permet l’échange des informations hautement flexible et
extensible sur des plate- formes indépendantes. Il peut être aussi employé non seulement
comme un porteur de données, mais aussi pour interroger des procédures éloignées sur des
serveurs, des services, des composants et des objets écrits dans des différents langages et les
diffusés sur différentes plate- formes. Or SIP est le protocole de signalisation qui permet, de
créer, de modifier et d’ouvrir des sessions de communications intégrées entre des agents UAs
(User Agent). SIP peut inclure différents types de données (acoustiques, vidéo ou un texte
traditionnel) basé sur le protocole Internet. SIP fournit alors les aptitudes pour trouver les
composants particuliers nécessaires pour le contrôle de session SOAP à fin de lui fournir les
moyens pour accéder à un URI. Bien que les messages SOAP soient décrits en format XML,
ils sont aussi destinés pour un traitement automatisé. Il est donc attendu qu'une combinaison
du SIP et du SOAP soit bénéfique quand on l’examine dans la combinaison des agents
automatisés et comme opposé aux agents nécessitant l'interaction immédiate de l'utilisateur.
La figure 4.1 présente les piles SIP et SOAP.
46
Services
SOAP
PROTOCOLE
SIP
TCP
Figure 4.1 : Exemples des piles SIP-SOAP [3]
Le défi fondamental derrière les messages SOAP est la livraison à une destination
correcte, c’est à dire la découverte dynamique des services. Autre problème de SOAP est qu’il
ne spécifie pas comment passer de la combinaison de l’URI de l’objet destinataire de la valeur
SAOPAction au code exécutable [34]. Le routage de la couche d'application fourni par SIP est
capable de réaliser ceci. SIP travaille en deux temps, il identifie tout d'abord le contact
demandé, puis envoi le message qui ouvre les canaux SOAP selon la nature des requêtes et
l'application. Plusieurs solutions ainsi que des propositions sont conçues pour une telle
combinaison SIP-SOAP pour l’invocation des services Web.
La plus simple, est le développement d’un composant qui fonctionne comme un
coordinateur d’exécution des différents services d’app lication entre SIP et SOAP [31]. Ce
composant est généralement désigné par ASB (Application Services Broker) ; il permet de
faire la supervision de passage des requêtes et l’accomplissement des tâches à fin d’avoir un
retour des résultats. Un modèle d’application Web services avec SIP et SOAP selon cette
technique peut être donné par la figure 4.2 où :
1 : Le client (UA1) demande un service (traduction, image,…) par la requête INVITE
publié dans un serveur Web pour le transmettre à UA2
2 : Le service s’exécute par l’intermédiaire d u serveur ASB, qui est l’interface avec le
service (la requête et la réponse sont des messages SOAP).
3 : UA2 reçoit le message réponse y compris le résultat du service grâce à SIP.
Service web
SOAP
2
UA1
SIP
1
3
ASB
SIP
UA2
Figure 4.2 : Application Web services [2]
Le diagramme d’échange entre les différents composants est représenté par la figure
suivante : figure 4.3
47
.
UA1
ASB
INVIT E
Avec Rq
SOAP
SA
UA2
Rq SOAP
Rp SOAP
INVIT E
avec Rp
SOAP
OK
SA : Serveur d’application
Figure 4.3 : SOAP dans SIP.
Une autre solution, consiste à incorporé le message d’invocation dans la requête SIP
elle même. Pour éviter tout problème de congestion réseau ; on utilise généralement le
protocole IMTP (Internet Message Transport Protocol) comme protocole de transport [32] :
INVITE
sip:… SIP/2.0
To:
From:
…
m=message IMTP/TCP application/soap+xml
Mais la solution la plus utilisée, consiste à inséré le message SOAP lui- même dans le message
SIP grâce au champ content-Type :
INVITE sip: URI SIP/2.0
From:
To:
Call-ID:
Content-type: application/soap+xml
<SOAP-ENV: Body>
<xml_Body>
<action>
</action>
<request>
</request>
</xml_body>
</SOAP-ENV:Body>
4.3. Architectures existantes à base de Web services
Actuellement, on trouve trois approches qui sont connues pour une combinaison SIP,
IMS et Web services :
-
IBM Telecom Web Services Server ( TWSS)
IMS-SOAP Gateway
Mobile Web service
48
Malgré que ces différentes approches suivent les concepts du VHE, chacune d’entre elle
définis sa propre méthode pour s’interfacer avec l’IMS :
4.3.1 IBM Telecom Web Services Server (TWSS)
Le Telecom Web Services Serveur (TWSS) est un des composants de plateforme IBM
WebSphere pour la télécommunication [122]. Il permet l'exposition de réseau et des services
avec des langages et des technologies des interfaces indépendante du Web service. Ces
interfaces peuvent être accédées par SIP, par des fonctionnalités PSTN comme dans Parlay ou
OSA Gateway.
TWSS consiste par la présence des:
¾ Une implémentation du Telecom Web Services : elle consiste en plusieurs
composants qui sont déployés au sommet de l’application du Serveur
WebSphere. Ces composants fournissent les services d’interface et les
implémentations qui exposent les services de réseau pour l’accès au Web
service.
¾ Un Gateway d’accès Telecom Web services : qui fournit la politique de
circulation, de surveillance, d’autorisation, et l’aptitude de gestion. Il agit
comme un intermédiaire entre des services et les clients, en appliquant les
politiques d'ensemble sur toutes les réponses et les requêtes du Web service qui
passe à travers le Gateway.
Le Gateway d’accès Telecom Web services inclut un nombre de composants primitifs
appelés médiation qui peuvent être rassemblés en un message qui traite des flux. La médiation
est une nouvelle fonction de service d'entreprise qui permet le traitement des messages entre
les requêtes de service et les fournisseurs de service [122]. Les applications de service de
médiation sont réalisées en utilisant des modules de médiation qui interceptent et modifient
des messages qui sont passés entre les requêtes et les fournisseurs.
Les primitifs de médiation reçoivent les messages, les traitent et propage les messages
traités au prochain primitif ou au nœud.
Les primitifs de médiation sont partagés en deux ensembles:
¾ Primitifs obligatoires de médiation : ces primitifs de médiation forment la base
de configuration de Gateway d’accès Telecom Web services. Ils fournissent les
services de base support pour l’ajouter sur la fonction de médiation primitive.
¾ Primitifs Optionnels de médiation tel que :
-
-
Diffuser la statistique primitive de médiation : l’enregistrement des
messages d’entrées et l’information de sortie dans une base de données
pour les employer par des opérations de réseau
Service d’autorisation de primitif de médiation : fournit l'autorisation pour
des opérations de Web service.
49
-
Groupe de résolution de primitif de médiation (Parlay X) : Ce primitif de
médiation est employé pour l’implémentation de service Parlay X, qui
accepte le groupe URI dans une liste de cibles pour une opération donnée.
La figure suivante (figure 4.4) présente l’architecture IBM Telecom Web service du
WebSphere.
Figure 4.4 : Telecom Web service Architecture
Comme il été mentionné au début, le toolkit Telecom Web Service Server est un composant
du IBM Websphere server, ceci implique que son utilisation est limitée uniquement aux
environnements Websphere et la définition du groupe URI Websphere Server.
4.3.2 IMS-SOAP Gate way
L’IMS-SOAP Gateway, est un Gateway, il permet l'intégration d’IMS en un Service
Orientée Architecture (OSA). IMS-SOAP Gateway soutient les normes ouvertes, incluant le
SOAP/HTTP 1.1 et WSDL 1.1.
Dans IMS-SOAP Gateway, les messages peuvent être transportés à IMS comme un XML
et IMS connect peut traduire le message en format IMS [123]. L’IMS-SOAP Gateway fournit
une utilité de déploiement pour un raccordement, Par la présence des:
-
Donner un nom au raccordement
Fournir un nom d’hôte ou adresse IP
Fournir un numéro de port
Fournir le nom d’enregistrement
Fournir un identificateur user, un mot de passe et nom de groupe (tous optionnel)
Tout ceci est précisé dans le dossier server.xml de l’IMS-SOAP Gateway.
50
La figure 4.5 fournit un aperçu de l’IMS-SOAP Gateway et l'intégration avec IMS
Figure 4.5: Architecture IMS-SOAP Gateway
Jusqu'à nos jours les performances de ce Gateway n’ont pas encore vérifiés, ce qui
donne à cette architecture un aperçu purement théorique.
4.3.3 Mobile Web services
Le Framework Mobile Web service porte sur les points de contact de IMS et la
technologie Web service au niveau interconnexion et au niveau amélioration. Ces adaptations
permettre une intégration de Mobile Web service Mobile dans le IMS et une communication
améliorée de Web service sur des réseaux mobiles.
Le terme «Mobile Web Services » n'est pas clairement défini. Il est employé avec des
significations différentes dans les différents contextes et domaines. Le terme «Mobile Web
Services » est employé en tout cas où les dispositifs et les réseaux mobiles sont impliqués
dans des interactions de Web service [108]. Un «Mobile Web Services » (Mob-WS) est un
composant logiciel indépendant identifié par un URI, une adresse Internet ou un SIP URI, qui
est déployé sur un dispositif mobile dans un réseau sans fil/mobile. Le Mobile Web Services
est un Web service qui est déployé sur un mobile et publié dans un réseau sans fil/mobile.
La figure 4.6 montre qu'une nouvelle couche de Web service est placée entre
l'application première et la couche de raccordement à SIP. Cela résulte dans une légère
modification au niveau de l'architecture logiciel dans le dispositif d'utilisateur. La couche
Web service représente les services mobiles d'un éloignés AS. La couche Web service, expose
ses services locaux au monde externe en envoyant une information WSDL par le message
NOTIFY (ou PUBLSH) de la pile SIP [114]. Pour les requêtes de message SOAP reçus de la
couche d'application, la couche Web service envoie ces requêtes SOAP par la pile SIP. Avec
cette architecture, les services à valeur ajoutée AS seront disponibles aux utilisateurs en
dehors du domaine de l'opérateur. Cependant, l’usage des services d'un existant AS est encore
limité, et pourrait être employé principalement pour le contrôle de réseau de l'opérateur.
51
Figure 4.6 : Architecture SOA modifié
L'interaction entre la couche d'application et la couche de Web service est dans de ux
directions. La couche d'application demande des services éloignés de la couche de Web
service et la couche de Web service demande des services locaux de la couche d'application.
Dans la représentation de l’IMS de la figure 4.7, le «Proxy Remote service» dans la
couche d'application est un objet qui représente les services locaux de Web service dans la
couche de Web service. Ceci est un objet de correspondance dans la couche Web service
représentant le service éloigné AS et il agit comme un appel en e nvoyant toutes requêtes
SOAP de l'utilisateur au distant AS. Le «SOAP message constructor » est un composant de la
couche Web service qui appelle l'origine des requêtes SOAP et le message WSDL maintient
l’état du distant AS contre un message SIP ID. En outre, ce composant à la responsabilité à
combiné le message reçu de WSDL de divers sources externes et présente une interface
composite de Web service pour les actuels services éloignés qui sont disponibles. Il y a des
outils disponibles pour construire la classe de proxy automatiquement de la description
WSDL d'un Web service [108]. Par exemple, dans Microsoft l'ASP.NET, contient un outil
nommais wsdl.exe peut construire la classe de proxy. Cependant, pour réaliser la disponibilité
des ces caractéristiques en plein potentiel, il nécessité une mise à jour des états des services en
temps-réel. Dans l'ordre d’avoir ces caractéristiques, les composants pertinents dans la couche
d'application et la couche de Web service devrait être dynamiquement mis à jour avec le
WSDL de la couche Web service. La création dynamique et la mise à jour de classe sont
possibles aujourd'hui avec beaucoup des langues de programmation (dotNet, Java).
52
Figure 4.7 : Module IMS de terminal Mobile Web Service
Figure 4.8 : Etablissement d’une session dans Mobile Web services
53
Figure 4.9 : Support mobilité et invocation d’un service
Il y a 3 contraintes d'implantation au terminal. Le terminal devrait être équipé avec
toutes les caractéristiques nécessaires pour communiquer avec le dispositif IMS et le
dispositif SIP-UA. En outre, il doit contenir un serveur Web qui peut envoyer et recevoir des
messages http et il doit avoir aussi l’environnement run-time pour un niveau haut de langage
qui soutient (Java runtime, dotNet framework) [106].
Les mobiles Web Services peuvent être employés pour simplifier le partage des
applications avec d’autres paires. Ces services doivent être bien définis, précisés et identifiés
par un unique Mobile Web service ID. S'il y a différentes interfaces de Mobile Web Service
avec la même fonctionnalité, une standardisation doit avoir lieu ou il faut développer et
implémenter une application pour qu’une autre interface d’application différente puisse
interconnecte aux éléments de ce domaine.
Dans l'ordre de soutenir les changements et l’extension de la technologie de Web
service à l’architecture de Mobile Web service. Les terminaux Mobile Web service sont des
SIP URI qui supportent l’infrastructure IMS à l’actuelle URI basé dans l’adresse IP du
terminal. Un unique Web service ID est employé pour chaque Mobile Web service pour
identifier aisément et enregistrer un Mobile Web service. Cet ID est employé dans la session
d'établissement d'une session Mobile Web service (intérieur de SDP) et enregistrant le Mobile
Web service dans l'infrastructure de réseau (SIP/IMS).Voire figure 4.8 et 4.9. L'intégration de
Mobile Web service en IMS entraîne un modèle d'interfaces entre Web service, IMS et les
54
composants SIP. Le composant de Mobile Web service d’un terminal agit comme un proxy
Web service et de l’autre coté fournit les Web services mobile. Généralement, chaque
terminal est capable de fournir et employé des Mobile Web services en même temps et dans la
même session SIP [116]. Le Mobile Web service et les composants de proxy sont non
seulement connectés aux nœuds SOAP, mais aussi au SIP UA. Figure 4.10
Figure 4.10 : Mobile Web service et SIP-SOAP
Une caractéristique distinguée de Mobile Web service est la mobilité de service.
Un même Mobile Web service peut être déployé sur différents terminaux (seulement les
interfaces sont les mêmes). Cela permet à l'utilisateur de commencer une session Mob-WS
sur un terminal et continué ultérieurement la session avec un autre terminal (terminal
handover). Pendant l'établissement de session SIP, l’unique Mobile Web Services ID sont
partagés dans les termes d’un modèle OFFER/ANSWER du protocole de description de
session(SDP). Le SDP est porté à l'intérieur de message SIP : INVITE. La réponse SDP
pourrait déjà être transmise avec la réponse. L'exemple suivant illustre un SDP OFFER
pour une session de Mobile Web Service. L’unique Mob-WS ID :
http://www.connects.services.com/Mob-WS/IDs/jeuxaa1234
L’étiquette de service est employée pour enregistrer le service avec IMSresp et le serveur
SIP REGISTRAR. En outre, la description d'interface Mob-WS et le format des messages
SOAP est défini dans le document WSDL situé à wsdl:http://schemas.
connects.services.com/example.wsdl.
v=0 o=- 2890124 2890124 IN IP4 connects.services.com
s=t=0 0
c=IN IP4 0.0.0.0 m=data 80 HTTP application/soap+xml
a=contact:http://www.connets...com/Mob-WS/jeuxaa1234
a=direction:passive
a=Mob-WS-ID:http://www. connects.services.com /Mob-WS/IDs/ jeuxaa1234
a=wsdl:http://www. jeuxaa1234/Mob-WS/schemas/MChess.wsdl
55
4.4 Les Solutions proposées.
Dans ce qui suit, nous proposons trois techniques permettant l’intégration et la
création des services télécoms en se basant sur la technologie des Web services. La première
méthode résout le problème d’accès d’un client à des bases de données hétérogènes. Une base
de données peut contenir des informations et des paramètres d’un tel service : informations
sur un service, données d’un service, paramètres d’authentifications, SDF du réseau
intelligent, etc. cette base de données est équivalente à la composante SDF du réseau
intelligent. La deuxième méthode permet l’utilisation de la technologie de VoiceXML
(information vocale) soit pour accéder à un service ou pour réaliser le SIB UI du réseau
intelligent. La troisième méthode est dédie aux applications mobiles.
Dans le paragraphe 4.2, l’élément ASB (Application Services Broker) est la partie
fondamentale et essentielle d’une telle réalisation. Cet élément qui fait la coordination entre
SIP et SOAP, il faut le modifié au niveau programme pour chaque application à un service.
Ces différentes modifications rendent l’industrialisation ou la commercialisation de ce
produit pour des environnements hétérogènes et distribués une tâche difficile. Ces difficultés
nous obligent à pensée à des technologies standard et évolutives. Actuellement les Web
services sont les plus connus pour une telle application distribuée. Les Web service sont bâtis
sur des normes ouvertes et fournissent des solutions pour intégrer des applications et des
services à travers des entreprises et sur la technologie Internet.
4.4.1 Accès à des bases de données hétérogènes.
La fonctionnalité d’un système traditionnel de la recherche multiple selon des mots
clés, dans des bases de données hétérogènes est basée sur le protocole SOAP. Dans le cadre
de l’appel à des procédures éloignées, le message SOAP présente les paramètres des
méthodes, les valeurs de retour et tous les messages d'erreur reliée aux procédés [41, 42,44].
La figure 4.11 représente des bases de données hétérogènes distribuées sur des
environnements différents (URL1, URL2 et URL3) ainsi que le script de la recherche
traditionnelle réalisé autour d’un service Web [41]. Il faut noter que ce script peut être intégré
à l’intérieur du message SOAP lui- même [42].
L’approche que nous proposons peut fournir l'aptitude à la découverte des composants,
grâce à l’aspect de signalisation réalisé par SIP. Elle permet aussi de résoudre le défi de la
livraison, à une destination correcte, des messages transportés par SOAP et d’évite r tout
problème de congestion de réseau et de contrôle de la session. Notons que le défi fondamental
derrière les messages SOAP est la livraison à une destination correcte, c’est à dire la
découverte dynamique des services, ce qui SIP peut l’offrir. SOAP est décrit en XML ce qui
permet de transporter des différentes requêtes délivrées par un client ou par un serveur sans
restriction. La découverte des URL par SIP permet de bien formuler les requêtes SOAP du
client et de faciliter la détermination du chemin de destination des messages SOAP et évite
ainsi les problèmes de bidirectionnalité, d’interopérabilité et l’exécution des codes contenus
dans le message.
SOAP n'est ni lié à un système d'exploitation ni à un langage de programmation.
Théoriquement, les clients et les serveurs peuvent tourner sur n'importe quelle plate- forme et
peuvent être écrits dans n'importe quel langage du moment qu'ils pouvaient formuler et
comprendre des messages SOAP. SIP permet la détermination et la localisation d’une base de
données publiée dans l’annuaire UDDI dans laquelle des informations recherchées existent.
56
$Soapserver URL1=……/SoapServer.php
$Soapserver URL2=……/SoapServer.php
$Soapserver URL3=……/SoapServer.php
if($hits=$soapclient1->
call(“Searching”,array
(“pattern”=>$pattern),
”urn:nusphere-webservices”))
{
foreach($hits as $data)
{
$result=$data[title] $data[…]
}
}
Figure 4.11 : Base de données distribuée avec le script de recherche SOAP uniquement
La proposition illustrée dans la figue 4.12 est une combinaison de la transaction SIP
avec SOAP où on trouve la base de donnée cible qui contient l’information recherchée. On
trouve aussi un serveur lié à l’annuaire UDDI qui contient des informations sur les différentes
bases de données. La procédure de fonctionnement de se système est la suivante :
c+d : Le client envoi une requête INVITE contenant les mots clés recherchés écrit avec
XML à l’intérieur du message SOAP comme il est montré dans la requête SIP ci-dessous, à
un serveur ou à l’annuaire UDDI dans lequel sont publiés les différentes bases de donnée.
La requête envoyée est la suivante :
INVITE sip: URI SIP/2.0
From:
To:
Call-ID:
Content-type: application/soap+xml
<SOAP-ENV: Body>
<xml_Body>
<action>
Search
</action>
<request>
mots clés à cherchés
if
</request>
</xml_body>
</SOAP-ENV:Body>
e+f : l’annuaire envoi une réponse au client après vérification de son contrat WSDL, sur la
localisation du serveur où la base de donnée contenant le mot recherché existant.
g+h : après avoir localisé l’URL de la base de donnée, une requête SOAP sera envoyée au
serveur localisé par son URL et une opération de recherche peut être faite dans cette base de
donnée. Le mot clé recherche peut être dans une des applications possible, un service.
57
UDDI
UDDI
Client
c
Domaine
d
e
f
Base de donnée
g
h
Figure 4.12 : Recherche dans des bases de données par SIP et SOAP
4.4.2 Accès Vocale avec VoiceXML.
VoiceXML permet l'intégration de la voix avec les services de données en utilisant
l’architecture client-serveur. Un service de voix est vu comme une séquence des dialogues
entre un utilisateur et une plateforme. XML est le langage du VoiceXML développé sous
W3C pour décrire un dialogue par la voie. Il est par conséquent très logique de p révoir un
Context interpreter du type VoIP qui utilise SIP et RTP pour communiquer avec le monde
extérieur. SIP basé sur VoiceXML browser (ou SIP/VoiceXML browser) permet à l'utilisateur
SIP d’être élément dans une application spécifique d’un système d’interaction voix/réponse.
SIP/VoiceXML browser est similaire à un browser Web pour le téléphone (figure 4.13). Le
browser cherche les pages VoiceXML dans le serveur Web où le fichier média préenregistré
et présente un dialogue interactif à l’utilisateur SIP.
Web
server
Figure 4.13 : Les opérations du browser SIP/VoiceXML
58
Elargir cette application pour le développement d’une application de communication
avec des Web services est une tendance dans l'industrie de communication. Les technologies
du Web telles que HTML, HTTP et IP sont combinées avec des langues de discours tel que
VoiceXML et de nouvelles interfaces standard XML tels que WSDL, SOAP et UDDI qui
accélèrent le mouvement de développement modulaire d'application de la communication
vocale [47].
Dans SIP, la requête URL identifie l'utilisateur et/ou le service pour qui l'appel est
destiné. Dans le cas d'un serveur de dialogue, le dialogue lui- même est la cible pour l'appel, la
requête URL devrait contenir l'identificateur pour ce dialogue [50]. Cet URL peut être dans
l’un des deux formats : Dans le premier, le script VoiceXML est identifié directement par un
URL HTTP, dans le second, le script n'est pas précisé. Si le serveur (serveur de dialogue :
VoiceXML server) reçoit INVITE, il devrait authentifier le visiteur et vérifier s’il est autorisé
pour accéder au service demandé. Après l'autorisation du serveur de dialogue, la requête est
permise. Le serveur valide, et transmet un REFER contenant l’adresse de service. Le client reINVITE selon la nouvelle adresse vers le service demandé.
Le diagramme suivant figure 4.14, illustre les opérations SIP/VoiceXML.
SIP client
Vo iceXM L browser
Service
INVITE SIP : [email protected]
DB
Authentification
REFER to SIP : service@domain
INVITE SIP : service@domain
200 OK
Figure 4.14 : Connexion à un service via VoiveXML browser.
Cette technique peut être élargie pour des applications de type Web services et aussi pour la
réalisation des services aux niveaux des réseaux intelligents. Plus exactement, les services qui
nécessitent des interactions vocales, comme par exemple le SIB numéro 12 du CS-1, SIB UI
(User Interaction).
La réalisation d’un tel SIB qui compose le plan fonctionnel global de l’INCM de
réseau intelligent permet aux développeurs des services télécoms de dépassé les contraintes
imposés par la technologie SIB elle- même ainsi que les limites imposées par les différentes
ensembles de capacités CS1-2-3 et 4 (Capabilities Set). La réalisation du SIB User
interaction implique les entités SCF (Service Control Function), SRF (Specialized Ressource
Functiom) et SSF (Service Switching Function)/CCF (Call Control Function) du plan
fonctionnel réparti. Le but étant de permettre à l’entité SCF de diriger la connexion d’un
utilisateur vers une ressource spécialisée (c’est à-dire l’entité SRF) pour la diffusion d’un
message vocal ou la collecte d’information provenant de cet utilisate ur. L’entité SRF reçoit
les instructions de la fonction SCF et diffuse le message ou collecte les données ou réalise les
59
deux opérations à la fois. Si une donnée est collectée, elle est alors renvoyée à l’entité SCF.
L’entité SRF dispose d’une relation avec l’entité SSF/CCF et d’une relation avec l’entité SCF.
La première est une interface à travers le réseau téléphonique commuté public alors que la
seconde est une interface à travers le réseau sémaphore SS7. Initialement, la fonction SCF
demande à l’entité SSF/CCF à travers le flux Connect to resource d’établir une connexion en
direction d’une entité SRF afin que l’interaction puisse avoir lieu avec l’utilisateur final.
L’entité SSF/CCF émet alors un message Set-up à travers le PSTN en direction de la fonction
SRF qui renvoie une confirmation de réponse Set-up, une fois la SRF est connectée à
l’utilisateur. L’entité SCF produit alors soit le flux Play announcement soit le flux prompt and
collect user information selon qu’elle souhaite que la fonction SRF diffuse une annonce ou
qu’elle diffuse une annonce et collecte une donnée utilisateur. Dans le premier cas, la
confirmation de la fonction SRF est représentée par le flux d’information Specialized
resource report, et dans le second cas par le flux Collected user information. La diffusion
d’un message peut être arrêtée à tout moment par l’entité SCF à travers l’émission du flux
d’informations Cancel announcement à l’entité SRF. L’entité SSF peut par ailleurs
déconnecter l’entité SRF en produisant le flux non co nfirmé Disconnect forward connection
émis à la fonction SSF/CCF. Cette dernière relaye alors un flux Release à travers le PSTN à
l’entité SRF. La figure 4.15 illustre les deux plans logiques du service et du fonctionnel global
du SIB UI.
Figure 4.15 : Plan fonctionnel global et logique de service de SIB User Interaction
Dans ce qui suit, nous proposons une méthode permettant d’exploiter les
caractéristiques de VoiceXML et des Web services pour réaliser le SIB UI, ou un tel service
de dialogue interactif, où on va remplacer l’SRF par un VoiceXML browser et le SDF par
une base de donnée sur un réseau tout IP. Cette base de données contient les informations
recherchées par la méthode proposée dans le paragraphe précédente. Par conséquents les
différentes SDF (Service Data Function) du réseau intelligent peuvent être distribuées et aussi
hétérogènes, ce qui réduit le problème d’interopérabilité entre les différents SCP des
différents réseaux intelligents.
L’architecture que nous proposons est la suivante, figure 4.16 où on trouve à gauche le plan
fonctionnel reparti du réseau intelligent et à droite la nouvelle architecture que nous
proposons.
60
Figure 4.16 : Réseaux Intelligents traditionnels et la configuration proposée.
Client SIP
Vo iceXM L browser = SRF
Web Services
Service
INVITE SIP : [email protected]
http://list.dialog.vxml.Webservices.net
Voici les différents services interactifs
INVITE SIP : [email protected]
http://service1.dialog.vxml.Webservices.net
PIN
Entre votre PIN sur 4 digits suivit par #
1234#
200 OK
ACK
REFER to SIP : Webservices.service1.net
Bye
INVITE SIP : Webservices.service1.net
200 OK
Bye
200 OK
Figure 4.17 : Diagramme d’échange d’un SIB UI avec VoiceXML et Web services
Le schéma proposé consiste à remplacé le SRF par un VoiceXML browser qui assure
les mêmes fonctions que celle de SRF IN, de plus elle est connecté à un Web service qui lui
61
permet de présenter les services interactifs qui existent et propre au plate forme dotNet. Le
Web services est aussi connecté au SSF, ce qui lui permet de traiter les messages SOAP du
SIP.
Dans le diagramme de la figure 4.17, nous présentons les dialogues mis en jeux pour
interroger un service existant, ou pour la création d’un nouveau service à une valeur ajoutée.
Ce service sera développé avec la technologie Web service par un fournisseur
indépendamment de l’infrastructure réseaux intelligents. La requête portant la demande de ce
service sera placé dans le troisième INVITE.
4.4.3 Solution pour les réseaux mobiles
La spécification OSA/PARLAY définit une architecture permettant aux applications
de services d'utiliser les ressources du réseau telles que le contrôle d'appel, la gestion de
conférence, les informations de localisation.
Concrètement, l'interface standardisée OSA/PARLAY:
o est le lien des plate-formes de services avec la couche contrôle pour la
signalisation, avec la couche transport pour le trafic et simplifie l'accès au
réseau pour les applications de services.
o offre des outils nécessaires au bon fonctionnement des services, tels que la
gestion de la sécurité (authentification, autorisation), des utilisateurs (pro fil,
état) et le contrôle d'appel.
Les deux modèles OSA/Parlay et Web Services ont un même objectif (figure 4.18),
permettent un accès personnalisé aux services multimédia adaptés au terminal utilisé [110].
Pour cela, il est nécessaire d'utilisé une couche d'adaptation permettant de gérer l'interface
entre les applications fournissant les services et les ressources réseaux: c'est l'interface API
OSA/Palay pour le modèle OSA et une suite des protocoles (SOAP, WSDL, et UDDI) pour
les Web services.
Le modèle Parlay X Web Services est actuellement le meilleur de la technologie Web
service. Il fournit la découverte et l’accès aux services par la norme (UDDI) et considère des
précautions de sécurité par le standard WS-security. Par conséquent, Parlay ne nécessite pas
d’explicite Framework d'interfaces comme dans OSA/Parlay. Parlay X Web Services fournit
une fonctionnalité abstraite et simplifiée en comparaison avec OSA/Parlay.
Le modèle OSA/Parlay X Web services n’est d’autre qu’une utilisation conjointe de
deux modèles précédents. L’OSA Parlay X Web services est une extension de la plateforme
OSA défini par les mêmes organisations : 3GPP, ETSI TISPAN, et le groupe Parlay. Bien que
les deux solutions partagent le but global de rendre les caractéristiques de réseau accessibles
aux tierces personnes pour le développement de service d'application [115]. OSA Parlay X
Web services présentent une approche différente dans les termes de niveau d'accès et l’usage
cible de l’API OSA.
62
Figure 4.18: Architecture Parlay X Web services
Les interfaces OSA fournissent un ensemble riches et détaillées d'APIs qui permettent
le contrôle des caractéristiques fourni par l'infrastructure réseau. Cet ensemble d'APIs est
organisé selon des groupes de caractéristique offerts par le réseau; donc, les développeurs
peuvent facilement se familiarisés avec ces caractéristiques, et sélectionne manuellement et
compose les éléments des APIs différents pour créer le service désiré.
Parlay X Web services est destiné à offrir un plus haut niveau d'abstraction de
l'infrastructure de réseau en fournissant un ensemble d'interfaces où les fonctions sont
groupées selon le type de services, ils permettent de diriger vers le réseau original, les
aptitudes auxquelles chaque fonction est liée. En outre, une approche plus proche au
développement de service Internet est réalisée par l'adaptation d'un modèle de programmation
synchrone des technologies de Web services. L’adaptation au Web service a beaucoup
d'avantages. Principalement, il permet aux développeurs des services Internet de programmé
des applications de télécommunications en utilisant un ensemble de technologies qu’il
maîtrisé déjà, En outre, les développeurs peuvent établir des nouveaux services si nécessaire.
Enfin, les Web services permettent la composition et la découverte dynamique des interfaces
nécessaire de Parlay X. Toutes ces aptitudes font de l’OSA/Parlay X Web services un support
convenable pour rendre le réseau cœur disponible à un plus large audience, permettant
l'incorporation de nouveau service des fournisseurs de l'industrie des télécommunications
[109].
Comme le montre les figures 4.19 et 4.20, Parlay X Web services peut être introduit dans le
réseau sous différentes configurations possibles:
x
Par l'adaptation d'un nouveau réseau d’élément indépendant, prenant le rôle du
Gateway Web service. Un tel Gateway fournit l'infrastructure de Web service et
trace les opérations de Parlay X en interaction natale IMS, directement ou par les
APIs OSA.
x
Chaque fonction natal IMS peut aussi implémenter directement les interfaces
Parlay X qui correspond à ses aptitudes. Cette configuration applique AS SIP.
63
x
Une combinaison des deux options précédentes peut être employées, dans lequel
certain Parlay X Web services sont offerts directement par la fonction natal IMS,
tandis que d'autres sont fournis par un Gateway de Web services.
Figure 4.19 : Déploiement Parlay Web Services
Figure 4.20: Parlay Web Services avec Parlay Proxy Application Server
Les Web service complètent l'image en fournissant un mécanisme flexible,
interopérable pour la livraison de l'ordre. Ils bénéficient du cadre de notification SIP, qui
fournit l'information sémantique d’invocation de Web services. La proximité des technologies
Web services au modèle de développement de service Internet permet de tirer une partie de
l'expertise actuelle, ressources et services complémentaires. En outre, un des avantages
principaux qui peut être attribué aux Web services est son performance, depuis l'information
64
qui est codée en XML, renfermée dans SOAP et transporter sur http [117]. Cependant, la
plupart des informations transportées dans un ordre de contrôle sont de nature textuelle.
Le chemin du Parlay X Web services est http, son domaine est www.csapi.org et son root est
parlayx. Son XML schema Namespaces est «http://www.csapi.org/schema/parlayx» et pour le
WSDL est «http://www.csapi.org/wsdl/parlayx». La figure suivante, figure 4.21, donne une
architecture pour la création des services télécoms.
UDDI
SO
AP
,
XM
L
Environnement Web service
W
SD
L,
Service
AS
Parlay Web Service Gateway
HSS
G-F
I-CSCF
P-CSCF
S-CSCF
MRFC
Client
SRTP
Media
Server
PSTN, GSM
MGCF
SRTP
Media Gateway
Figure 4.21 : Environnement de création et publication des services
Les différentes méthodes proposées dans les paragraphes précédents ($4.4.2 et $4.4.3)
peuvent être intégrés dans cette architecture, c’est l’environnement Web service qui
l’accueillir soit pour les bases de données distribuées et hétérogènes soit pour les interactions
vocales.
Les premiers spectacles de création et d’invocation des services est la configuration
des interfaces et des services et leurs aptitudes (figure 4.22). Une fois ces opérations sont
faites, la publication sera faite au sein d’un annuaire UDDI ou autre supporté par la
plateforme Web service. L’invocation d’un service est faite par les requêtes SIP, comme il est
montré dans les paragraphes précédents.
Les différents Namespaces du Paralay X Web services nécessaires pour une telle
configuration sont :
65
http://www.csapi.org/wsdl/parlayx/device_capabilities/
http://www.csapi.org/wsdl/parlayx/device_capabilities/notification_manager/
http://www.csapi.org/wsdl/parlayx/device_capabilities/notification/
http://www.csapi.org/wsdl/parlayx/device_capabilities/device_configuration/
http://www.csapi.org/schema/parlayx/device_capabilities/
Les éléments nécessaires pour une telle structure de configuration sont résumés dans les
tableaux suivants :
Element Name
configurationId
name
description
configurationRefer
ence
Element Type
xsd:string
xsd:string
xsd:string
Description
Un unique identifier pour une Configuration
Le de la configuration
La description de cette configuration
xsd:anyURI
Le URL le fichier de configuration XML e xiste
Element Name
Element Type
Description
configuration
ConfigurationDescription
La Configuration
timestamp
xsd:dateTime
Le date/time : option
Element Name
deviceId
name
userAgentProfileRefere
nce
Element Type
xsd:string
xsd:string
Description
Le unique identifier pour le modèle device
Le nom de ce modèle
xsd:anyURI
Le URL ou le fichier de profile XML de UA L file est situé
Ce que peut être représenté par le diagramme suivant :
Figure 4.22 : Diagramme de configuration Parlay X Web service
66
Dans ce qui suit nous montrons des extraits les différents programmes de configuration des
interfaces pour un tel service :
a) Configuration des interfaces :
<?xml version="1.0" encoding="UTF-8"?>
<wsdl:definitions
name="parlayx_device_capabilities_device_configuration_interface"
targetNamespace="http://www.csapi.org/wsdl/parlayx/device_capabilities/device_configuration/v3_0/interface"
xmlns="http://schemas.xmlsoap.org/wsdl/"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:parlayx_device_capabilities_device_configuration="http://www.csapi.org/wsdl/parlayx/device_capabilities/device_configuration/v3_
0/interface"
xmlns:parlayx_common_faults="http://www.csapi.org/wsdl/parlayx/common/v3_0/faults"
xmlns:parlayx_device_capabilities_xsd="http://www.csapi.org/schema/parlayx/device_capabilities/v3_0"
xmlns:parlayx_device_capabilities_device_configuration_local_xsd="http://www.csapi.org/schema/parlayx/device_capabilities/device_conf
iguration/v3_0/local">
<wsdl:import namespace="http://www.csapi.org/wsdl/parlayx/common/v3_0/faults" location="parlayx_common_faults_3_0.wsdl"/>
<wsdl:types>
<xsd:schema elementFormDefault="qualified" xmlns:xsd="http://www.w3.org/2001/XMLSchema"
targetNamespace="http://www.csapi.org/schema/parlayx/device_capabilities/device_configuration/v3_0/local">
<xsd:import namespace="http://www.csapi.org/schema/parlayx/device_capabilities/v3_0"
schemaLocation="parlayx_device_capabilities_types_3_0.xsd"/>
<xsd:element name="pushConfiguration" type="parlayx_device_capabilities_device_configuration_local_xsd:pushConfiguration "/>
<xsd:complexType name="pushConfiguration">
<xsd:sequence>
<xsd:element name="address" type="xsd:anyURI"/>
<xsd:element name="configuration" type="parlayx_device_capabilities_xsd:ConfigurationDescription"/>
</xsd:sequence>
</xsd:complexType>
<xsd:element name="pushConfigurationResponse"
type="parlayx_device_capabilities_device_configuration_local_xsd:pushConfigurationResponse"/>
<xsd:complexType name="pushConfigurationResponse">
<xsd:sequence/>
</xsd:complexType>
<xsd:element name="getConfigurationList"
type="parlayx_device_capabilities_device_configuration_local_xsd:getConfigurationList"/>
<xsd:complexType name="getConfigurationList">
<xsd:sequence>
<xsd:element name="deviceId" type="xsd:string"/>
</xsd:sequence>
</xsd:complexType>
<xsd:element name="getConfigurationListResponse"
type="parlayx_device_capabilities_device_configuration_local_xsd:getConfigurationListResponse"/>
<xsd:complexType name="getConfigurationListResponse">
<xsd:sequence>
<xsd:element name="result" type="parlayx_device_capabilities_xsd:ConfigurationDescription" minOccurs="1"
maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>
<xsd:element name="getConfigurationHistory"
type="parlayx_device_capabilities_device_configuration_local_xsd:getConfigurationHistory"/>
<xsd:complexType name="getConfigurationHistory">
<xsd:sequence>
<xsd:element name="address" type="xsd:anyURI"/>
</xsd:sequence>
</xsd:complexType>
<xsd:element name="getConfigurationHistoryResponse"
type="parlayx_device_capabilities_device_configuration_local_xsd:getConfigurationHistoryResponse"/>
<xsd:complexType name="getConfigurationHistoryResponse">
<xsd:sequence>
<xsd:element name="result" type="parlayx_device_capabilities_xsd:ConfigurationHistory" minOccurs="1"
maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>
67
</xsd:schema>
</wsdl:types>
<wsdl:message name="DeviceCapabilitiesDeviceConfiguration_pushConfigurationRequest">
<wsdl:part name="parameters" element="parlayx_device_capabilities_device_configuration_local_xsd:pushConfiguration "/>
</wsdl:message>
<wsdl:message name="DeviceCapabilitiesDeviceConfiguration_pushConfigurationResponse">
<wsdl:part name="result" element="parlayx_device_capabilities_device_configuration_local_xsd:pushConfigurationResponse"/>
</wsdl:message>
<wsdl:message name="DeviceCapabilitiesDeviceConfiguration_getConfigurationListRequest">
<wsdl:part name="parameters" element="parlayx_device_capabilities_device_configuration_local_xsd:getConfigurationList"/>
</wsdl:message>
<wsdl:message name="DeviceCapabilitiesDeviceConfiguration_getConfigurationListResponse">
<wsdl:part name="result" element="parlayx_device_capabilities_device_configuration_local_xsd:getConfigurationListResponse"/>
</wsdl:message>
<wsdl:message name="DeviceCapabilitiesDeviceConfiguration_getConfigurationHistoryRequest">
<wsdl:part name="parameters" element="parlayx_device_capabilities_device_configuration_local_xsd:getConfigurationHistory"/>
</wsdl:message>
<wsdl:message name="DeviceCapabilitiesDeviceConfiguration_getConfigurationHistoryResponse">
<wsdl:part name="result" element="parlayx_device_capabilities_device_configuration_local_xsd:getConfigurationHistoryResponse"/>
</wsdl:message>
<wsdl:portType name="DeviceCapabilitiesDeviceConfiguration">
<wsdl:operation name="pushConfiguration">
<wsdl:input
message="parlayx_device_capabilities_device_configuration:DeviceCapabilitiesDeviceConfiguration_pushConfigurationRequest"/>
<wsdl:output
message="parlayx_device_capabilities_device_configuration:DeviceCapabilitiesDeviceConfiguration_pushConfigurationResponse"/>
<wsdl:fault name="ServiceException" message="parlayx_common_faults:ServiceException"/>
<wsdl:fault name="PolicyException" message="parlayx_common_faults:PolicyException"/>
</wsdl:operation>
<wsdl:operation name="getConfigurationList">
<wsdl:input
message="parlayx_device_capabilities_device_configuration:DeviceCapabilitiesDeviceConfiguration_getConfigurationListRequest"/>
<wsdl:output
message="parlayx_device_capabilities_device_configuration:DeviceCapabilitiesDeviceConfiguration_getConfigurationListResponse"/>
<wsdl:fault name="ServiceException" message="parlayx_common_faults:ServiceException"/>
<wsdl:fault name="PolicyException" message="parlayx_common_faults:PolicyException"/>
</wsdl:operation>
<wsdl:operation name="getConfigurationHistory">
<wsdl:input
message="parlayx_device_capabilities_device_configuration:DeviceCapabilitiesDeviceConfiguration_getConfigurationHistoryRequest"/>
<wsdl:output
message="parlayx_device_capabilities_device_configuration:DeviceCapabilitiesDeviceConfiguration_getConfigurationHistoryResponse "/
>
<wsdl:fault name="ServiceException" message="parlayx_common_faults:ServiceException"/>
<wsdl:fault name="PolicyException" message="parlayx_common_faults:PolicyException"/>
</wsdl:operation>
</wsdl:portType>
</wsdl:definitions>
a) Configuration service :
<?xml version="1.0" encoding="UTF-8"?>
<wsdl:definitions
name="parlayx_device_capabilities_device_configuration_service"
targetNamespace="http://www.csapi.org/wsdl/parlayx/device_capabilities/device_configuration/v3
_0/service"
xmlns="http://schemas.xmlsoap.org/wsdl/"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:tns="http://www.csapi.org/wsdl/parlayx/device_capabilities/device_configuration/v3_0/ser
vice"
xmlns:interface="http://www.csapi.org/wsdl/parlayx/device_capabilities/device_configuration/v3
_0/interface">
68
<wsdl:import
namespace="http://www.csapi.org/wsdl/parlayx/device_capabilities/device_configuration/v3_0/int
erface" location="parlayx_device_capabilities_device_configuration_interface_3_0.wsdl "/>
<wsdl:binding name="DeviceCapabilitiesDeviceConfigurationBinding"
type="interface:DeviceCapabilitiesDeviceConfiguration ">
<soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>
<wsdl:operation name="pushConfiguration">
<soap:operation soapAction="" style="document"/>
<wsdl:input>
<soap:body use="literal"/>
</wsdl:input>
<wsdl:output>
<soap:body use="literal"/>
</wsdl:output>
<wsdl:fault name="ServiceException">
<soap:fault name="ServiceException" use="literal"/>
</wsdl:fault>
<wsdl:fault name="PolicyException">
<soap:fault name="PolicyException" use="literal"/>
</wsdl:fault>
</wsdl:operation>
<wsdl:operation name="getConfigurationList">
<soap:operation soapAction="" style="document"/>
<wsdl:input>
<soap:body use="literal"/>
</wsdl:input>
<wsdl:output>
<soap:body use="literal"/>
</wsdl:output>
<wsdl:fault name="ServiceException">
<soap:fault name="ServiceException" use="literal"/>
</wsdl:fault>
<wsdl:fault name="PolicyException">
<soap:fault name="PolicyException" use="literal"/>
</wsdl:fault>
</wsdl:operation>
<wsdl:operation name="getConfigurationHistory">
<soap:operation soapAction="" style="document"/>
<wsdl:input>
<soap:body use="literal"/>
</wsdl:input>
<wsdl:output>
<soap:body use="literal"/>
</wsdl:output>
<wsdl:fault name="ServiceException">
<soap:fault name="ServiceException" use="literal"/>
</wsdl:fault>
<wsdl:fault name="PolicyException">
<soap:fault name="PolicyException" use="literal"/>
</wsdl:fault>
</wsdl:operation>
</wsdl:binding>
<wsdl:service name="DeviceCapabilitiesDeviceConfigurationService">
<wsdl:port name="DeviceCapabilitiesDeviceConfiguration"
binding="tns:DeviceCapabilitiesDeviceConfigurationBinding">
<soap:address
location="http://localhost:9080/DeviceCapabilitiesDeviceConfigurationService/services/DeviceCa
pabilitiesDeviceConfiguration"/>
</wsdl:port>
</wsdl:service>
</wsdl:definitions>
Avec ces programmes s’ajoute d’autre tel que :
- La notification,
- Les aptitudes,
- La gestion,
69
4.5. Conclusion
Une Combinaison du SIP avec SOAP permette de consulter des services multimédias,
des bases de données hétérogènes et de réaliser une opération de dialogue interactif avec un
client indépendamment des opérateurs. Cette nouvelle architecture présente une nouvelle
définition des services intelligents par comparaison avec celle du réseau intelligent classique.
L’intégration des services télécoms avec la technologie de Web service, permet de
dépasser plusieurs contraintes qui étaient auparavant des obstacles, tels que la dépendance
totale des services aux opérateurs télécoms soit au niveau création, soient au niveau
exploitation et bénéfice. Avec les différentes méthodes citées dans ce chapitre, la création
ainsi que l’intégration des services est plus souple et l’opérateur ne fournit que l’infrastructure
physique pour l’acheminement des données.
Malgré les différents avantages du Web service, plusieurs questions restent jusqu'à nos
jours sans réponse. La première question est concernant le protocole SOAP qui transporte de
l’information utile soit au niveau invocation soit au niveau donnée de service. Ce protocole à
un degré d’inefficacité aux applications qui sont géographiquement distribuée [29] ce qui le
rend inefficace pour des applications nationales. De même, et à cause de sa nat ure textuelle, il
surmonte les équipements de sécurité ce qui peut engendrer des problèmes de contrôle d’accès
et d’authentification. La deuxième question est liée à l’annuaire des services UDDI et au
contrat WSDL. La question est selon quel contexte ou stratégie on peut publier nos services
sans perdre ni droit ni bénéfice ?
Malgré les différentes approches qui existent pour l’intégration et la création des
services dans des environnements, mobiles. Le Parlay X web service paraît la plateforme la
plus adéquate pour une telle intégration. Avec ces outils, il assure la création, la publication et
simplifie les tâches d’utilisations. Mais un service restera toujours non fiable si ces paramètres
d’invocation, d’identification et de publication ne sont pas séc urisés. Dans le prochain
chapitre nous présentons les différentes menaces des réseaux intelligents et nous proposons
une méthode pour la sécurisation.
70
Chapitre 5
Sécurité des services télécoms
Résumé du contenu
5.1. Introduction
5.2. Les paramètres de sécurité sur les services de réseau Intelligent.
5.3. Les Techniques des sécurités existantes sur les réseaux mobiles
5.4. Les outils proposés pour la sécurisation des services télécoms
5.5. Implantation de la sécurité des services télécoms au niveau domaine
5.6 Implantation de la sécurité des services télécoms inter domaines
5.7. Conclusion.
5.1Introduction
Les réseaux intelligents, sont une base pour établir et commercialiser des services par
le réseau de télécommunication. Vendant des services et des informations sur un réseau, ne
définit pas un accroissement considérable de la somme de l'information coulant sur le réseau,
mais aussi une question de confidentialité. La globalisation croissante et la libéralisation du
marché des télécommunications, nécessitent fortement une infrastructure plus globale d’IN
qui satisfait les besoins de différents abonnés légalement impliqués, surtout pour les services
multinationaux. Quelques fonctions de sécurité ont été déjà introduites dans des réseaux
actuels, mais elles définissent des contraintes liées à des équipements et des algorithmes
privés et propres aux fournisseurs. Cependant, l’IN doit offrir ses services à un monde public,
ouvert, et surtout à offrir des services qui permettent à des utilisateurs de communiquer par la
transmission publique et de changer d’équipement sans décharger leur intimité et leur aisance
d'emploi. Les nouveaux aspects des fonctions de sécurité doivent garantir qu’elles soient
publiquement utilisables, économiquement faisables et doivent assurer tous cela en même
temps.
En réseau GSM par exemple, le protocole GSM spécifie des phases d'authentification
et de chiffrement entre le mobile et la station de base. Les sécurités de ce protocole reposent
sur des mécanismes cryptographiques non publiés, ce qui permet de réaliser plusieurs types
d’attaques ; notamment l’attaque Man-In-The-Middle. Cette attaque, consiste à s'intercaler
entre le mobile et la station et permet de prendre connaissance de l’IMSI d'une cellule. Ce
type d'attaque, connu sous le nom de IMSI-Catcher, est réalisable par exemple à l'aide des
produits GA900 ou CTS55 de Rohde & Schwarz. En plus, l’absence de l’intégrité des
71
données durant la phase de la signalisation rend possible la réalisation des autres attaques de
type DoS (Denial of Service).
Au niveau GPRS (General Packet Radio Service) La sécurité, est très similaire au
réseau GSM. Une des mesures de sécurité est l’utilisation d’une carte à puce (SIM) protégée
par un mot de passe (PIN). Les services de sécurité généralement déployés dans le réseau
GPRS sont : l’authentification du terminal mobile quand un abonné GPRS se connecte pour la
première fois au réseau, la confidentialité des données transmises entre le mobile et le SGSN
(Serving GPRS Support Node) par l’algorithme de chiffrement GEA (GPRS Encryption
Algorithm) qui est une version de l’algorithme A5 utilisé dans GSM, e t la sécurisation des
terminaux mobiles contre les attaques en provenance de l’extérieur du réseau GPRS au niveau
de routeur GGSN (Gateway GPRS Support Node) par des filtres de paquets (firewalls) GGSN
est de NAT (Network AddressTranslation) pour protéger les adresses IP.
Comme le GSM, l’UMTS utilise un module d’identification qui est une carte à puce
appelé USIM. Dans cette USIM, les applications, les certificats, les signatures numériques, les
algorithmes de chiffrement et les autres types de données sont sauvegardées dans la mémoire
de cette carte. Les services de sécurité offerts par le réseau UMTS sont l’authentification d u
l’usager par le réseau et du réseau par l’usager et l’échange de clés (AKA) et la confidentialité
et l’intégrité des données.
Nous avons passé très rapidement sur la sécurité offerte dans le réseau GSM, GPRS et
UMTS. Nous constations bien que tout comme GSM, la confidentialité est surtout assurée au
niveau du lien radio. Ce qui différencie l’authentification de l’UMTS du celle de GSM est qui
montre que le réseau UMTS offre aussi l’authentification du réseau à l’usager et assure
l’intégrité des données de signalisation mais ignore celle des données (voix et donnée) de
l’usager, qui sont pour nous des informations très utiles et doivent être bien sécurisées, car ces
sont les données des services télécoms.
Beaucoup de travaux et d’efforts ont été consentis, ces dernières années, afin d’aboutir
à des solutions immédiates pour sécuriser les échanges des données dans les réseaux fixes
ainsi que les réseaux mobiles. Ces solutions ont été ainsi conçues dans un co ntexte où les
équipements et les entités sont performants, on trouve les protocoles TLS, IPSec, SSL, etc, et
des équipements tels que firewalls, zone DMZ et des algorithmes standards de chiffrement.
Malgré la diversité de ces solutions, elles demeurent encore limitées, et ne répondent pas ainsi
suffisamment aux besoins spécifiques des applications de la communication dans les
environnements fixes/mobiles. Nous avons donc opté pour des solutions d’adaptation qui
permettent d’adapter des mécanismes de sécurité, que nous les proposons pour les réseaux
fixes au départ puis aux réseaux mobiles. Ce choix est appuyé sur deux raisons principales. La
première est que les réseaux mobiles sont par défaut reliés aux réseaux fixes et la seconde,
réside par le fait que la réutilisation de ces solutions nous permet de réduire les problèmes
d’interopérabilité et les coûts d’exploitation.
5.2 Les paramètres de sécurité sur les services du réseau intelligent
Du point de vue réseaux intelligents, l'analyse et l’évaluation des risques sont basées
sur les différentes réalisations possibles dans le plan fonctionnel réparti (DFP : Distributed
Functional Plane) et dans le plan physique. Les principaux problèmes de la sécurisation qui se
posent dans le réseau intelligent sont les suivants :
72
x
Authentification de l'utilisateur et du terminal par les fournisseurs.
x
Authentification du serveur par les usagés.
Avec ces problèmes. Il est nécessaire de s’avoir les paramètres qu’il faut sécuriser :
‰
Le processus d’autorisation d'appel qui consiste à déterminer si l'utilisateur/le terminal est
réellement autorisé à utiliser les ressources du service, par exemple une fonctionnalité du
service (appel dans le RTC, etc.) ou une ressource du réseau (qualité de service, largeur de
bande, codec etc.). Le plus souvent, les fonctions d'authentification et d'autorisation sont
rassemblées afin qu'une décision puisse être prise au niveau du contrôle d'accès.
L'authentification et l'autorisation aident à surmonter les attaques du type usurpation
d'identité, mauvaise utilisation et fraude, manipulation et déni du service.
‰
La signalisation qui concerne la protection des protocoles de signalisation contre les
manipulations et les mauvaises utilisations ainsi que la protection en terme de
confidentialité et de respect de la vie privée. Les protocoles de signalisation sont
généralement protégés par des moyens cryptographiques et font l'objet d'une protection
d'intégrité et d'une protection contre les ré-exécutions. Il faut particulièrement veiller à ce
que les facteurs critiques de la qualité des communications en temps réel soient respectés,
pour cela, il faut utiliser des procédures courtes de prise de contact et des temps de
transmission aller-retour courts pour éviter que la durée d'établissement d'une
communication soit trop longue ou que la qualité téléphonique soit dégradée par suite de
retards de paquets ou de gigue en raison d'un traitement de sécurité.
‰
La confidentialité téléphonique qui est assurée généralement par le chiffrement des
paquets téléphoniques, c'est-à-dire les charges utiles RTP et par la contre-écoute des
données téléphoniques surveillées. En général, les paquets de média (par exemple vidéo)
d'applications multimédias sont également chiffrés. La protection des paquets médias
comprend généralement l'authentification et la protection d'intégrité des charges utiles.
‰
La gestion de clés qui inclut non seulement toutes les tâches qui sont nécessaires pour que
les opérateurs puissent distribuer de manière sécurisée les informations relatives a ux clés
aux utilisateurs et aux serveurs, mais aussi les tâches liées à la mise à jour de clé s en cas
d'expiration des clés perdues.
‰
La sécurité interdomaine qui se rapporte au problème découlant du fait que, des systèmes
appartenant à des environnements hétérogènes mettent en œuvre des fonctionnalités de
sécurité différentes en raison de leurs besoins différents, de politiques de sécurité
différentes et de capacités de sécurité différentes. Il faut donc négocier dynamiquement
des profils et des capacités de sécurité tels que des algorithmes de chiffrement et leurs
paramètres. Cela devient notamment important lorsque des frontières entre domaines sont
franchies et que des fournisseurs et des réseaux différents interviennent. En ce qui
concerne les communications interdomaines, il est important, de pouvoir traverser les
pare-feux sans encombrement et de pouvoir faire face aux contraintes liées aux dispositifs
de la traduction d'adresse du réseau NAT.
La liste peut ne pas être complète. En pratique, on peut se retrouver confronté à
d'autres problèmes de sécurité qui sont considérés comme «ne faisant pas partie» de domaine
d'application d’un protocole tels que les problèmes liés à la politique de sécurité, à la sécurité
73
de la gestion du réseau, à la mise en œuvre de la sécurité, à la sécurité de l'implémentation, à
la sécurité opérationnelle. De même, l’évolution technologique sur le plan protocolaire et
logiciel ainsi que sur le plan technologique ne cesse pas d’accroître d’une manière non
estimable ; ce qui a multiplié les outils technologiques de la connexion au réseau et la
naissance d'autres types d'attaques passives et actives.
5.3 Les techniques des sécurités existantes sur les réseaux mobiles.
5.3.1 GSM/GPRS
En réseau fixe, à chaque numéro, correspond une adresse physique fixe, alors
que pour le réseau GSM, le numéro d’un terminal mobile est une adresse logique constante à
laquelle il faut associer une adresse physique qui varie au près des déplacements de l’usager
du terminal. La gestion de cette itinérance nécessite la mise en œuvre d’une identification
spécifique de l'utilisateur. De plus, l'emploi d’un canal radio rend les communications
vulnérables aux écoutes et aux utilisations frauduleuses.
Le système GSM à donc recours aux procédés suivants :
x
L’authentification de chaque abonné avant toute opération sur les services,
x
L’utilisation d’une identité temporaire,
x
Le chiffrement (ou cryptage) des communications.
Le système GSM (figure 5.1) utilise quatre types d’adressage liés à l’abonné : L’IMSI
(International Mobile Suscriber Indentity), identité invariante de l’abonné n’est connue qu’à
l’intérieur du réseau GSM, le TMSI (Temporary Mobile Suscriber Indentity), identité
temporaire utilisée pour identifier le mobile lors des interactions Station Mobile / Réseau, le
MSISDN (Mobile Station International ISDN Number), numéro de l’abonné ; c’est le seul
identifiant de l’abonné mobile connu à l’extérieur du réseau GSM, et le MSRN (Mobile
Station Roaming Number) qui est le numéro attribué lors de l’établissement d’un appel, sa
principale fonction est de permettre l’acheminement des appels par les commutateurs (MSC et
GMSC).
Le protocole GSM spécifie des phases d'authentification et de chiffrement entre le
mobile et la station de base. Il utilise des mécanismes de cryptographiques non publiés,
reposant sur un secret enregistré dans une carte à puce et un code unique composé de quinze
chiffres identifiant le poste mobile, c’est le code IMEI (IMEI : International Mobile
Equipment Identity). La carte SIM contient principalement deux informations : la clé secrète
Ki connue de l'opérateur et utilisée par le chiffrement, et un identifiant international unique
IMSI permettant la portabilité d'un utilisateur vers d'autres opérateurs : le roaming.
Pour mettre en œuvre les fonctions d’authentification et de chiffrement des
informations transmises sur la voie radio, GSM utilise les éléments suivants :
x
Des nombres aléatoires RAND,
x
Une clé Ki pour l’authentification et la détermination de la clé Kc,
74
x
Un algorithme A3 fournissant un nombre SRES à partir des arguments d’entrée
RAND et de la clé Ki,
x
Un algorithme A8 pour la détermination de la clé Kc à partir des arguments d’entrée
RAND et Ki,
x
Un algorithme A5 pour le chiffrement / déchiffrement des données à partir de la clé
Kc.
Figure 5.1 : Architecture des réseaux GSM et GPRS
A chaque abonné, est attribuée une clé Ki propre. Les algorithmes A3, A5 et A8 sont
les mêmes pour tous les abonnés d’un même réseau. L’utilisation de ces différents éléments
pour la mise en œuvre des fonctions de la sécurité peut être schématisée par la figure suivante
(Figure 5.2). Notons qu’il existe trois variantes de ce chiffrement : le chiffrement fort A5/1
utilisé en Europe, faible A5/2 utilisé aux USA, et l'absence du chiffrement A5/0.
Dans chaque établissement d’appel et avant d’activer ou de désactiver certains
services supplémentaires, se déroule la procédure suivante :
x
Le réseau transmet un nombre aléatoire RAND au mobile ;
x
La carte SIM du mobile calcule la signature de RAND grâce à l’algorithme A3 et la
clé Ki. Le résultat calculé, noté SRES, est envoyé par le mobile au réseau ;
x
Le réseau compare SRES au résultat calculé de son côté. Si les deux résultats sont
identiques, l’abonné est identifié.
75
L’algorithme A5 est implanté dans la BTS. L’activation se fait sur demande du MSC
mais le dialogue est géré par la BTS. On peut noter que ce chiffrement ne peut être activé dès
les premiers messages mais se fait après une procédure d’authentification puisqu’il nécessite
la connaissance de la clé Kc par le mobile.
Figure 5.2 : Confidentialité des données transmises sur la voie radio
Certains de ces mécanismes cryptographiques utilisés, ont été cryptanalysés. En avril
1998, Ian Goldberg et David Wagner de Berkeley ont analysé le mécanisme COMP128 [84]
et ont démontré que les implémentations A3 et A8 reposant sur ce mécanisme peuvent être
mises en défaut en posant 219 requêtes à la carte SIM. L'utilisation d'un lecteur de cartes à
puce et d'un logiciel exploitant la faiblesse de ces mécanismes permet, avec une carte SIM et
son code PIN, d'en extraire le secret en moins d'une heure en utilisant le logiciel SimScan
v1.33. Cette dernière version prend en compte les protections des cartes SIM récentes en
réduisant le nombre des accès afin de ne pas les détruire, les limites se situent en général entre
10.000 et 65.536 accès. Une carte à puce générique, Gold Wafer de type PIC 16f84 et
EEPROM 24lc64 ou Silver Wafer de type PIC 16f876 et EEPROM 24lc64, un
programmateur de carte et le logiciel SimScan permettent la duplication totale de la carte SIM
cible [88].
Un autre problème est l’attaque de type man- in-the- middle. Une attaque de type manin-the- middle, consiste à s'intercaler entre le mobile et la station, et permet de prendre
connaissance de l’IMSI d'une cellule. Ce type d'attaque, connu sous le nom de IMSI-Catcher,
est réalisable par exemple à l'aide de produits GA900 ou CTS55 de Ro hde & Schwarz,
produits qui est destinés au test et permettant d'une part, la simulation d'une station de base,
d'autre part, l'enregistrement des données numériques de l'interface air pour une analyse
ultérieure.
Au-delà de la simple interception de l'identifiant IMSI, on trouve, la possibilité de
passer au chiffrement A5/0, c'est-à-dire annuler le chiffrement de l'interface air. Il est
possible, sur certains mobiles, de déterminer si le chiffrement est actif ou non. Ceci nécessite
cependant, d'activer des menus non accessibles par l'utilisateur normal. En raison des
faiblesses des mécanismes cryptographiques, la connaissance de 64 bits en mode clair et
chiffré, est suffisante pour casser la clé dynamique Kc, et donc de décrypter la communication
76
entre le mobile et la station de base. En raison d'informations protocolaires dans la
transmission, l'obtention de ces 64 bits est rendue possible.
La société G-Com Technologies à été la première à commercialiser du matériel
professionnel destiné à l'interception passive des communications mobiles. La vente de ces
produits, est d'abord libre, mais maintenant est contrôlée. Certains produits, tels que le
GSM2060TP ou les historiques GSM2000 et GSTA1400, sont accessibles sur Internet.
Un autre problème dans le réseau mobile est relatif aux SMS (Short Message Service).
Un SMS identifie l'auteur du message en indiquant le numéro de téléphone source de ce
message. Dans certains cas, ce numéro correspond à celui de la passerelle surtout dans le cas
de passerelle Internet, et ne permet pas d'authentifier l'origine du message. De façon générale,
cette identification de l'émetteur n'est pas sécurisée, et ne peut pas être utilisée pour certifier
l'origine du message SMS. A titre indicatif, le logiciel SMS Spoof v1.1 permet d'envoyer des
SMS depuis un Palm en falsifiant le numéro de l'émetteur.
Enfin et malgré ces différents problèmes, les mécanismes de sécurité mis en œuvre
dans GSM permettent d’obtenir un niveau de protection élevé pour le système et pour les
abonnés. En effet il faudrait par exemple plusieurs milliards de couples (RAND, SRES) pour
déterminer l’algorithme A3. Mais aucun système de sécurité n'est fiable à 100%. Cependant
l’opérateur du réseau GSM peut vérifier l’identité IMEI d’un terminal. Si celle-ci n’est pas
reconnue par le réseau ou si elle fait partie d’une liste de terminaux dérobés ou pirates, l’accès
du mobile au réseau sera refusé.
Les mécanismes au niveau GPRS, sembles identiques aux ceux utilisés pour le réseau
GSM : le premier est utilisé pour le transport des données, et le second pour les services
classiques de voix. Tous les deux utilisent les mêmes équipements du sous-système radio.
C’est ensuite qu’ils se distinguent. C’est pour cette raison que ces deux réseaux aux nivaux
BSS, les attaques ainsi que les techniques de sécurité sont les mêmes, mais aux niveaux NSS
sont différents.
En GPRS, le routeur SGSN (Serving GPRS Support Node) contrôle le chiffrement et
l’authentification du terminal mobile. De la même façon que le GSM, un nombre aléatoire est
utilisé pour générer la clé d’authentification afin de rehausser la sécurité. Cette clé n’est pas
transmise sur aucune partie du réseau. Les données transmises entre le mobile (MS) et le
SGSN sont cryptées, le chiffrement est établi en générant la clé de chiffrement. L’algorithme
utilisé pour le chiffrement est le GEA (GPRS Encryption Algorithm) qui est une version de
l’algorithme A5 utilisé dans GSM.
Le routeur GGSN (Gateway GPRS Support Node) qui est le point d’entrée entre le réseau
Internet et le réseau GPRS, protège l’utilisateur contre les attaques provenant des autres
mobiles. Pour sécuriser les terminaux mobiles contre les attaques en provenance de l’extérieur
des filtres de paquets, NAT (Network Address Translation), firewalls GGSN sont placés pour
filtrer le trafic.
5.3.2 UMTS
L’UMTS comme GSM utilise un module d’identification qui est une carte à puce
appelé USIM. Dans cette USIM, les applications, les certificats, les signatures numériques, les
algorithmes de chiffrement et d’autres types de données sont sauvegardés dans la mémoire de
cette carte. Les vulnérabilités du réseau UMTS sont moins que celle définies pour les réseaux
77
GSM et GPRS, ajouton à eux, le haut débit offert par le réseau UMTS qui aide les
malveillants à gagner du temps [113].
Les services de sécurité offerts par le réseau UMTS sont :
ƒAuthentification
et échange de clés (AKA) : l’authentification prouve l’identité entre
l’usager et le réseau et entre le réseau et l’usager. La technique utilisée est appelée one-pass
authentication qui permet de réduire les échanges de messages. Suite à cette procédure
d’authentification, l’usager est sûr du réseau et vice versa. L’authentification est nécessaire
aux autres mécanismes de sécurité comme la confidentialité et l’intégrité [120].
ƒLa
confidentialité : elle est assurée par le chiffrement des données des usagers et de
signalisation entre l’usager et le réseau en utilisant l’identité temporaire ( TMSI/P-TMSI) de
l’usager à la place de son identité globale (IMSI). Le cryptage se fait entre la carte USIM et le
RNC. La confidentialité de l’usager est assurée entre l’abonné et la VLR/SGSN. Si le réseau
n’offre pas le service de confidentialité, l’usager est notifié et aura alors le choix d’accepter
ou de refuser les connexions. Les éléments qui sont confidentiels sont l’identité de l’abonné,
la localisation courante de l’usager, les informations (voix et données) de l’usager et les
données de signalisation.
ƒL’intégrité
: elle permet de s’assurer que le message entre l’usager et le réseau n’ont pas
été manipulé, même si le message n’est pas confident en soi. Ceci est assuré par un condensât
ajouté à chaque message de signalisation. Pour cela, le réseau UMTS utilise une clé prépartagée qui est enregistrée dans la carte USIM et l’AuC pour générer le condensât. Au
niveau du transport, l’intégrité est assurée par le calcul du CRC.
Au niveau du réseau fixe sur lequel les réseaux GPRS et UMTS peuvent
s’interconnectés, des différentes autres techniques existent pour la sécurisation des données
transportés vers ou de réseau mobile. Dans le domaine de la sécurité réseau, on parle
généralement d’une zone appelée, zone démilitarisée DMZ (DeMilitarized Zone) pour
désigner une zone isolée hébergeant des applications mises à la disposition des publics. La
DMZ fait ainsi office de « zone tampon » entre le réseau à protéger et le réseau hostile. Cette
technique permet de protéger le réseau interne contre certaines attaques. De même, on parle
aussi de la technologie VPN bout à bout, qui encrypte les données entre le PC ou PDA et le
réseau informatique d’entreprise ; elle constitue une solution appropriée pour les entreprises
ayant un réseau ouvert sur Internet grâce à la mise en œuvre d’une infrastructure du type VPN
applicatif terminal- terminal.
Ce modèle nécessite l’intégration d’un terminateur VPN et la mise en place d’un
logiciel client IPsec sur les postes utilisateurs. Cette technique permet une authentification du
type client serveur sur VPN. Les bénéfices de cette solution sont la rapidité de la mise en
œuvre, le faible niveau d’investissement nécessaire et la sécurité des données qui est assurée
par le chiffrement SSL. On trouve également des autres techniques de sécurisation de
transport des données, comme avec une liaison dédiée, ligne LS, RNIS.
Après cette présentation rapide de ce qu’il propose chaque terminal o u chaque réseau,
comme techniques de sécurisation selon leur standard. Nous proposons dans ce qui suit des
méthodes qui permettent la sécurisation des services télécoms dans des environnements fixes
et mobiles
78
5.4 Les outils proposés pour la sécurisation des services télécoms
L’architecture de réseau intelligent et par défaut distribué et constitue par plusieurs
nœuds de contrôle et d’administration. Il faut garantir donc que les pouvoirs de contrôle et/ou
la décision ne soient fournis qu’à des nœuds identifiés pour s’assurer que n’importe quel
nœud ne puisse pas envoyer des règles erronées et assure en même temps l’intégrité et la
confidentialité des données transmises. Pour réaliser ces opérations, nous avons envisagé trois
niveaux de sécurité : Le premier niveau concerne la sécurité de la requête de signalisation
elle- même, le deuxième niveau est la sécurité des données utile envoyée ou reçus par l’
opérateur télécoms, et en fin un troisième niveau qui concerne la sécurité des medias écoulés
entre le UAC et l’opérateur après avoir authentifié l’utilisateur et le service demandé auprès
de fournisseur des services. Pour faire cela nous commençant premièrement par la
sécurisation de la requête de signalisation SIP.
Les communications SIP sont susceptibles aux plusieurs types d’attaques. L'attaque la
plus simple dans SIP, est celle qui permet à un agresseur de gagner de l’information sur des
identités des utilisateurs, des services et des médias. L’attaque survient quand un agresseur
intercepte le parcourt de la signalisation et modifie le message SIP dans l'ordre de changer
certaines caractéristiques d’un service. Cette attaque peut être employée pour détourner le
flux de la signalisation ou pour changer l’enregistrement de l'utilisateur ou pour modifier le
profil d’un service. Cette attaque dépend du type de la sécurité (ou de l’insécurité) employé
(le type de d’authentification, nombre des entêtes protégés, etc.). Un autre type d’attaque est
le spoofing, qui est employé pour modifier une session (ex, terminer un appel) ou pour
exécuter un déni du service. Enfin, SIP est surtout encliné aux attaques de déni de service qui
peut être exécuté de plusieurs manières, et qui peut endommager les deux, les agents
utilisateurs et les serveurs.
5.4.1 Les Mécanismes de la sécurité SIP
Les mécanismes qui fournissent la sécurité dans SIP peuvent être classés en deux
sortes de protection : de terminal-au–terminal ou de proxy-par-proxy [57]. Les mécanismes
Terminal-au–terminal impliquent les agents utilisateurs SIP. Les mécanismes proxy-parproxy assurent la communication entre deux entités SIP successives dans le parcourt de
message de signalisation. SIP ne fournit pas de caractéristiques spécifiques pour la protection
proxy-par-proxy et compte sur la sécurité dans la couche réseau ou la couche du transport
(Figure 5.3). Les mécanismes proxy-par-proxy sont requis parce que des éléments
intermédiaires peuvent jouer un rôle actif dans le traitement SIP en lisant et/ou en écrivant
certaines parties des messages SIP.
Deux principales techniques de sécurité sont employées par SIP: l’authentification et
le cryptage des données :
™ L’authentification est employée pour authentifier l'envoyeur du message et pour
assurer qu’une certaine information critique de message soit non modifiée dans le
transit. Elle doit empêcher un agresseur de modifier et/ou d’écouter des requêtes et
des réponses SIP (Enregistrement Hijacking[84]). Le protocole SIP emploi :
Proxy-Authentication, Proxy-Autorization, WWW-Authentication dans le domaine
de l’entête, similaire à ceux des HTTPs pour l’authentification de système terminal
(RFC2617) au moyen d'une signature numérique (réponse 401 ou 407). La figure
79
5.4 illustre une technique d’authentification avec SIP où deux mécanismes sont
utilisés Proxy-Authentication et WWW-Authentication.
™ Le cryptage de données permet seulement au donataire destiné de décrypter et de
lire les données. Le cryptage terminal-au-terminal fournit une confidentialité pour
toute les informations (certaines entête et le corps de message SIP) qui n’on pas
besoin d'être lues par des serveurs intermédiaires de proxy. Le cryptage dans
terminal-au-terminal est exécuté par le mécanisme S/MIME ou PGP décrit dans
l’RFC 2543. Au contraire, le cryptage dans proxy-par-proxy de tous les messages
SIP est employé pour protéger l'information à qui on devrait accéder par des
entités intermédiaires, telles que les entêtes From, To et Via. Ce cryptage est
exécuté par des mécanismes de sécurité externe à SIP tels que l’IPsec ou TLS.
Mé canismes de sé curité
Mé canismes de la
couche Application
Mécanismes de la
couche réseaux
Mécanismes de la
couche du Transport
HTTP Digest
HTTP Authentication S/MIME Authentication
IPsec
TLS
Figure 5.3 : Les mécanismes des sécurités SIP
SIP UA
SIP UA
Proxy Server
INVITE
407 Proxy Authentication Required
ACK
INVITE Proxy-Auth :1
INVITE
Trying
401 Unauthorized
401 Unauthorized
ACK
ACK
INVITE Proxy-Auth:1, WWW-Auth:2
INVITE WWW-Auth:2
Trying
Ringing
Ringing
OK
OK
ACK
ACK
Autenticated media session
Figure 5.4 : Authentification SIP avec HTTP Digest
80
Entête WWW-Authenticate :
WWW-Authenticate: Digest
realm="uri",
qop="auth,auth-int",
nonce="abba234243e2n m234joobvu85332",
x
x
x
x
Le Digest dans l’entête indique que HTTP Digest Authentication est utilisé.
Le realm est un indicateur prés de l’utilisateur concernant l’username et le mot de
passe employés.
Le champ qop défini le degré de protection utilisé dans la transaction des messages
entre le UAC et UAS. La valeur par défaut est qop=auth. On peut de même ajouter
auth-int qui permet de vérifie l’intégrité de données tout le long de service
d’authentification.
Le nonce est une chaine de caractère pseudo aléatoire que le client doit l’utiliser, avec
son secret, pour calculer une valeur de hachage qui permet au serveur de vérifier que
le client est bien en possession du secret.
Entête Proxy-Authenticate :
Pro xy-Authorization: Digest username="bob",
realm="uri",
nonce="ad7a24ks9f909ff3fas31af4qda4c093",
uri="sip:",
qop=auth,
nc=00000001,
cnonce="a782kn 9",
response="asd8af87a9f85a72jh124hlk2hb412",
Sur des lignes similaires, l’entête Proxy-Authenticate est envoyé dans le code de la
réponse 407 par un proxy serveur uniquement, qui compte la décision sur l’authentification
d’UAC. Le challenge est envoyé par le proxy au UAC est traité de la même façon par le
UAC. Ce dernier incorpore les champs de son entête dans l’entête proxy-Authorization et
envoi le second INVITE. Les valeurs de code réponse de l’entête peuvent être 401 et 407. Le
401 peut être classé comme une authentification utilisateur- à– utilisateur, tandis que le 407
peut être classé comme une authentification Proxy- au- utilisateur.
Cette multiplicité des techniques de sécurité proposée autour du protocole SIP,
nécessite un accord sur le choix d’un mécanisme de sécurité commun entre deux entités
(agents utilisateur et/ou proxy). Pour cette raison, il est très important de définir comment une
entité SIP peut sélectionner un mécanisme approprié pour communiquer avec une prochaine
entité proxy. Une des propositions pour un mécanisme d'accord qui permet à deux agents
d’échanger leurs aptitudes propres de sécurité dans le but est de sélectionner et d’appliquer un
mécanisme commun de sécurité [61], se manifeste où un client initié la procédure de
communication, et inclut dans sa première requête envoyée au prochain proxy la liste de ses
mécanismes de sécurité soutenus. L'autre élément (côté serveur) répond par une autre liste de
ses propres mécanismes de sécurité et ses paramètres. Le client sélectionne alors un
mécanisme commun de sécurité préférée. Après l’utilisation de ce mécanisme choisi, le client
initie un nouvel appel au serveur en utilisant ce nouveau mécanisme de sécurité.
81
Bien que les mécanismes de la sécurité fournis par SIP puissent réduire certains
risques d'attaques, il y a certaines limites dans les étendues des ces mécanismes. Les
premières limitations sont liées à l'emploi du HTTP : premièrement, les mécanismes
d'intégrité dans HTTP ne travaillent pas très bien pour SIP, ils offrent la protection seulement
pour certains paramètres SIP ; deuxièmement, HTTP nécessite qu'une association de sécurité
SA (Security Association) préexiste et soit configurée et employée dans les serveurs SIP ou
dans les terminaux.
Avec les mécanismes de sécurité SIP, IETF propose deux protocoles de sécurité IP :
x
IPsec qui est un mécanisme de couche réseau qui peut être employé pour introduire la
sécurité directement sur la couche IP. Habituellement IPsec est employé pour fournir
la sécurité basée sur l'identité du nœud réseau et c'est indépendamment de
l'architecture SIP. Pour cela, IPsec peut être employé essentiellement dans SIP entre
des entités SIP qui ont une configuration et une association de sécurité assez statique.
x
TLS (Transport Layer Security), qui fournit de la sécurité au niveau de la couche de
transport sur une connexion orientée TCP. Noter que si un agent utilisateur emploi
IPsec ou TLS pour envoyer des requêtes SIP à un serveur proxy (proxy-par-proxy),
cela ne garantit que la volonté de la sécurité de la couche transport.
La topologie d’une solution distribuée des services télécoms fondée sur les services
Web (soit pour la création soit pour l’invocation) qui est notre cas, peut inclure de nombreux
périphériques et des systèmes intermédiaires. Il est donc primordial de pouvoir sécuriser les
échanges entre application et services transitant entre ces nœuds intermédiaires. Dans ce type
de configuration le protocole SIP ainsi que https ne gère qu’une sécurité de point à point (avec
potentiellement une clé de session modifiée à chaque étape), pas de bout en bout. Comment
par conséquent faut- il procéder pour maintenir le contexte de la sécurité sur la globalité de
système et des services télécoms ?
Adresser la problématique de sécurité à un niveau indépendant de la couche transport
permet de palier à ses limites. En se fondant sur une sécurité de niveau messages, WSSecurity de Web services Architecture permet de sécuriser une solution mettant en œuvre une
multiplicité de plate-formes, sans nécessité d’avoir la maitrise de la configuration des
différents nœuds intermédiaires intervenant dans l’échange et offre des compléments en terme
de chiffrement et de non-répudiation.
5.4.2 Les Mécanisme de la sécurité avec les Web services
Nous proposons dans cette section un mécanisme de sécurité à base de la technologie
Web service pour sécuriser les données utile d’un service télécoms, dans une transaction entre
un UAC et un opérateur télécoms. Ce choix est basé sur deux critères : premièrement les
insuffisances constatées aux niveaux des mécanismes de sécurité proposés par les protocoles
SIP, TLS ainsi que la richesse constatée aux niveaux des outils de sécurité proposée par
l’architecture Web services. Deuxièmement, et afin d’éviter tous les problèmes
d’interopérabilités entre plate- formes et d’éliminer les contraintes qui d’autres outils étranges
peuvent les créés aux niveaux protocolaires ou aux niveaux développement avec les services
télécoms, il sera idéale d’utiliser la même technique pour la création et pour la sécurisation
des services télécoms, si ces outils le permettent.
82
Microsoft propose avec les Web Service Enhancements (WSE) [118] une amélioration
au framework dotNet. Il permet au développeur de construire des Web services sécurisés
basés sur les derniers standards. Les WSE étendent les fonctionnalités de sécurité, de routage
et d’intégration de pièces jointes dans des messages SOAP. Il permet aux développeurs de
construire des applications basées sur les dernières spécifications publiées par Microsoft et les
différents acteurs de l’industrie tels que WS-Security, WS-policy, WS-SecurityPolicy, WSTrust, WS-SecureConversation et WS-Addressing.
En utilisant le WSE pour les Web services XML on peut :
x
x
x
Sécuriser les applications tout au long d’un domaine.
Modifier d’une façon transparente, au niveau des nœuds, le chemin que peut prendre
un message SOAP pour arriver au Web service.
Attacher un fichier avec un message SOAP, durant une communication entre les
services Web XML, sans le sérialiser en XML.
5.4.2.1 Architecture de WSE
Le WSE est constitué des :
x
x
x
Un jeu de classes qui implémentent de nouveaux protocoles (WS-Security, WS-policy,
WS-SecurityPolicy,…).
Un jeu de filtres hébergés par ASP.Net qui interceptent les messages SOAP entrants et
sortants.
Un contexte qui est le canal de communication entre une application et
l’infrastructure.
Le paquet SOAP sortant du client (respectivement du Web service) sera intercepté par le
pipeline WSE et traité par les différents filtres selon un ordre précise : «Custom Output
Filters», «Routing Output Filter», «Security Output Filter» puis enfin le «Trace Output
Filter», ce dernier une fois activé, il permet de sauvegarder dans un fichier de trace tous les
messages SOAP traversant le pipeline WSE. Le paquet traité par le pipeline WSE sera
transmis vers le réseau sous forme d’une requête (respectivement d’une réponse) SOAP. A
l’arrivé du paquet à un service (respectivement à un client), il sera de nouveau intercepté par
le pipeline WSE et traité par les mêmes filtres mais dans le sens inverse: le «Trace Input
Filter», le «Security Input Filter», le «Routing Input Filter» et les «Custom Input Filters».
5.4.2.2 WS-Security
WSE utilise les mécanismes définis dans les spécifications WS-Security [29] pour
permettre à une application de sécuriser les Web services et :
x
x
x
x
D’identifier un utilisateur qui demande l’exécution d’un Web service
(authentification).
De vérifier le rôle de l’utilisateur et les droits qui lui sont attribués (autorisation).
De s’assurer qu’un message n’a pas été corrompu durant le transport (signature).
De s’assurer que seul le destinataire d’un message peut le lire (chiffrement).
Un client doit obtenir un jeton de sécurité d’une source (qui doit avoir la confiance de
l’expéditeur et du récepteur). Quand un client envoi une requête SOAP, les jetons de sécurité
83
(Security tokens) sont placés dans le message SOAP. Quand le serveur Web reçoit la requête,
le pipeline WSE vérifie que les jetons sont authentifiés avant d’envoyer le message vers le
serveur Web et cela sans envoyer une requête vers le client pour vérifier l’intégrité du jeton de
sécurité.
Le WSE fournit 3 mécanismes pour sécuriser un message SOAP :
x
Des jetons de sécurité pour identifier un utilisateur. Les informations permettant la
mise en œuvre de cette sécurité sont placées directement dans les entêtes SOAP. En
effet les jetons peuvent utilisés de multiples formats : couple utilisateur/mot de passe,
certificats X509 v3, Tickets Kerberos, jetons XML.
x
La signature numérique qui permet à un destinataire de vérifier que le message SOAP
n’a pas été modifié depuis qu’il a été signé en se fondant sur le standard XML
Signature. Il faut noter que la signature numérique peut vérifier si le message n’a pas
été modifié, mais elle ne chiffre pas le message; le message est transmis en texte clair.
x
Le chiffrement de message SOAP afin de garantir la confidentialité des échanges en se
fondant sur le standard XML Encryption. Pour chiffrer un message SOAP,
l’expéditeur doit avoir la clé publique de récepteur qui à son tour doit posséder sa clé
privée pour déchiffrer le message. Le WSE supporte en réalité les deux types de
chiffrement symétrique et asymétrique et par défaut, le WSE chiffre la partie <Body >
d’un message, mais on peut spécifier la partie d’un message SOAP à chiffrer.
La figure 5.5 montre que seulement le récepteur d’un message SOAP chiffré peut avoir accès
à la partie chiffrée car il est le seul qui possède la clé privée.
Figure 5.5 : Message Chiffré
Pour assurer la haute disponibilité des services actifs, il faut implémenter une
topologie de réseau transparente qui permet aux paquets de changer leur route en cas de
coupure de lien. Cette technique s’appelle la redirection. Il est réalisé à l’aide d’un routeur
WSE implémenté conformément à la spécification WS-Routing [30]. Cette technique permet
84
d’offrir des différentes fonctions qui peuvent être nécessaire selon l’application. On trouve la
répartition de charge où le service cible est distribué sur des multiples serveurs, le dataflow ou
routage en fonction du continu, la traçabilité des échanges, etc.
Après l’installation d’un routeur WSE au niveau d’un ordinateur intermédiaire, le
client transmet les messages SOAP vers ce routeur intermédiaire au lieu de le transmettre
directement vers le service Web. Ensuite le routeur transmet ces messages vers le service Web
destinataire, dont l’emplacement peut être changé de façon transparente par simple
modification de fichier de configuration (« Referral Cache ») de ce routeur intermédiaire.
Ainsi, si le service Web destinataire tombe en panne, il suffit de l’arrêter et d’acheminer le
message SOAP vers un serveur de secours. Une fois le serveur principal est réparé, les
messages SOAP sont re-acheminés vers ce serveur principal de façon flexible et transparente.
La figure 5.6 nous montre la transmission d’un message SOAP vers un routeur WSE, qui à
son tour transmet le message vers un autre serveur Web en se basant sur le contenu de son
fichier referral cache. Dans notre cas le referral cache indique que le message doit être
transmis vers le serveur B. Dans le cas où le serveur B ne répond pas aux requêtes, le contenu
de ce referral cache sera mis à jour pour que la transmission de ce message se fasse vers le
serveur C par exemple.
Figure 5.6 : Routage WSE
5.4.3 Sécurité de media
Nous abordons dans cette section la sécurisation de données multimédias après avoir
faire l’authentification et l’identification du client et du service. La circulation des donnes
multimédia est différente de la traditionnelle circulation IP. Pour les applications temps-réel,
tel que la VoIP, qui est hautement sensible au retard de la diffusion et des retards du paquet.
Le retard d’une voie acceptable pour une qualité approximative de ne pas péager un discours
ne doit pas dépasser 150 ms [65]. Les retards Codec, retard de la sérialisation, retard de la
propagation, etc, contribuent tous aux retards généraux du paquet de réseau. Ces retards sont
variables et dépendent de la dynamique du réseau : Cryptage, authentification et algorithmes
des échanges des clés de chiffrement et des sessions. Le choix doit être fait donc, de sorte que
le protocole de la sécurité employé n’ajoute pas un retard au-delà des limites acceptables avec
le négatif associé d'impact sur la qualité de la transmission de la voix. Cependant, le problème
survient avec la gestion de système, l’échange de la clé, l’investissement et le coût de service.
85
Dans ce scénario, nous proposons l’utilisation du protocole SRTP (Secure Real-time
Transport Protocol)[ 86] pour la sécurisation des médias et de la conversation vocale. Ce
dernier en lui- même, il assure le chiffrement et l’authentification des paquets en temps réel.
La figure 5.7 illustre le format du paquet SRTP.
Figure 5.7 : Format de paquet SRTP
5.5 Implantation de la sécurisation des services télécoms au niveau domaine
Après avoir présenté les différents mécanismes permettant la sécurisation des requêtes
de signalisation SIP et aussi l’authentification des UACs, ainsi que les méthodes que
permettent de sécurisée les données des services télécoms avec WSE et WS-Security, nous
présentons dans ce qui suit, une architecture physique et logique permettent la sécurisation
des services télécoms ainsi que les opérateurs.
Avec les techniques déjà citées et les exigences en termes de la sécurisation, nous
suggérons qu’une structure physique pour la mise en œuvre d’une plate-forme de sécurité des
réseaux et des services intelligents peut être donnée comme celle de la figure 5.8. La
description de cette architecture est la suivante :
Chaque abonné A dispose de son code d’accès à un service (SAC : Service Access
Code), de son code PIN (Personal Identification Number) et de son identificateur de la session
ID [55]. Un serveur sécurisé calcule à partir de ces trois paramètres le code d’authentification
du message MAC et le ticket de l’opérateur réseau associé à l’abonnée A, To. Les différentes
requêtes, sont des messages SOAP sécurisés, par la technique WS-Security du WSE. Ces
messages SOAP sont intégrés dans les requêtes SIP par la technique de combinaison SIPSOAP. Les deux paramètres (MAC, To) seront vérifiés à travers le SSP puis le SCP
(vérification de l’utilisateur). Si l’utilisateur est accepté, on vérifie s’il à le droit ou non à ce
service. Cette vérification est assurée par un serveur d’autorisation de services. Une fois,
l’accès au service est autorisé, Un ticket Ts est envoyé au serveur d’autorisation de l’opérateur
réseau à travers le SSP et l’SCP. Si l’opérateur lé valide, l’utilisateur sera au cœur de service
en question et une session sécurisé sera établie.
Le service en question peut selon l’application, un service télécoms classique, défini
dans le réseau intelligent classique ou un service télécoms développé par un opérateur de
télécommunication par la méthode SIP-SOAP-Web service présentée dans le chapitre
précédent.
86
Le Browser VoiceXML, joue dans notre application le rôle d’un serveur vocal, pour toute
opération d’interaction vocale avec l’utilisateur soit pour faire entrer de s codes ou recevoir
des résultats des certaines opérations.
Soient :
Un Serveur de l’autorisation opérateur (SAO)
Un Serveur de l’autorisation des services (SOS).
AKA : clé d’authentification
MACA = f(ToA, AKA) : code d’authentification du message
ToA : g(SAC, IDA, ) : Ticket opérateur
TsA : (h(ToA), MACA) : Ticket service
Les opérations :
¾ Serveur d’autorisation des services (SOS)
1. vérifier si A est enregistré
2. calculer MAC SOS pour ToA
3. Générer du ticket TiA si MACSOS = MACA
4. Générer du ticket TiA
5. envoyer TiA à SAO
¾ Serveur d’autorisation de l’opérateur réseau (SAO)
1. vérifier TiA
et
2. SCP autorise ou non
Le diagramme du fonctionnement de ce mécanisme est donné dans la figure suivante,
figure 5.9 ou :
F1 : INVITE SIP avec authentification et ID
F2 : 407 Authentification Proxy
F3 : ACK
F4 : INVITE une session avec le service
F5 : http://service1.dialog.v xml.Webservices.net
F6 : donner vos identificateurs ( SAC, PIN, ID)
F7 : donner vos identificateurs ( SAC, PIN, ID)
F8 : donner vos identificateurs ( SAC, PIN, ID)
F9 : Voici mes identificateurs
F10 : calcul de To et MAC
F 11 : To et MAC transmis vers SSP
F12 : puis vers SCP
F13 : validation ou non
F 14 : Si validé ; envoyer vers SOS
F15 : calcul de Ti
F16 : Ti vers SCP
F17 : vérification de Ti par SOA
F18 : Validation ou non de Ti
87
F19 : Si valider, interroge SSP.
F20 : INVITE
F21 : OK.
Figure 5.8 : Implantation d’un mécanisme de sécurisation
88
Client SIP
SAO
SCP
SOS
SSP
Web Service
VoiceXML Browse
SIP serveur/Proxy
Client SIP
F1
F2
F3
F4
F5
F6
F7
F8
F9
F10
F11
F12
F13
F14
F15
F16
F17
F18
F19
F20
F21
Figure 5.9 : Diagramme de fonctionnement des services télécoms sécurisés.
5.6 Implantation de la sécurisation des services télécoms entre domaines
Actuellement, on trouve plusieurs opérateurs télécoms qui emplois les ressources de
domaines multiples pour livrer leurs services. L'autorisation du terminal est importante pour
un tel service, parce que plusieurs domaines sont impliqués. Il y a aucune courante solution
pour livrer l’authentification, l’autorisation et la comptabilité aux services multi-domaine.
Dans notre étude nous présentons deux architectures pour la livraison de l’AAA
(Authentication Autorisation Accounting) pour un tel service. Les architectures sont
89
analysées sur leurs aspects qualitatifs. Dans le courant multi-domaine IMS, l'interconnexion
directe de serveur AAA, au logement des serveurs d’abonné (HSS), n'est pas encore possible.
Dans l’emploi des ressources multi domaines, l'interaction entre les domaines est
nécessaire pour soutenir et livrer un service. Une essentielle propriété de l'interaction de
service multi domaines est qu'il y à au moins deux parties qui ont une relation de comptabilité
avec le terminal. Cela résulte dans des identités différentes de client sous lesquelles les
terminaux sont connus aux fournisseurs de service. L'autorisation de terminal est nécessaire à
tous les domaines pour permettre l'usagé à des ressources par un spécifique terminal. La
notion des services multi domaines est appliquée uniquement dans les architectures IMS.
5.6.1 La Solution existante : Le serveur AAA
Pour fournir l’authentification, l’autorisation et la comptabilité (AAA) des services
dans les réseaux IMS, la plateforme AAA doit être normalement employée [121]. Le défi
principal est lié à l'emploi de l’architecture AAA pour le service multi-domaine. Le défi
principal lié à l'intégration de l’architecture multi domaines AAA et l’IMS, est le fait que
actuellement, l’architecture IMS est développée dans un seul domaine administratif sous la
gestion d'une seule zone. Donc il n'est pas possible à fendre l’architecture IMS et le partager
sur des domaines administratifs multiples qui sont gérer par des zones différentes.
Principalement, on trouve trois séquences de messages différents pour l'autorisation de
terminal par un fournisseur service : séquence agent (Figue. 5.10a), séquence push (Figue.
5.10b) et séquence pull (Figue. 5.10c)
Figure 5.10 : Les différentes séquences AAA
Dans le scénario de la séquence agent, l'utilisateur contacte premièrement le serveur
AAA. Le serveur AAA autorise l'utilisateur, et l'équipement de service est notifié.
L'équipement de service peut établir le service et notifie le serveur AAA qu'il est prêt et
notifie postérieurement l'utilisateur. L'utilisateur et l’équipement de service peuvent précéder
à la communication directement, sans faire fonctionner le serveur AAA comme un agent. Un
exemple de cette situation, est similaire à une requête d'utilisateur pour accès à l’Internet.
L'utilisateur est premièrement relié au serveur AAA du fournisseur de service Internet. Quand
le serveur AAA à authentifié l'utilisateur, le proxy de fournisseur de service est notifié et le
raccordement est établit.
Dans le scénario de la séquence push, l'utilisateur demande directement le service de
l'équipement de service, qu’est l’autorisé par une requête de serveur AAA.
90
Dans le scénario de la séquence pull, l'utilisateur reçoit un témoignage de serveur
AAA avec lequel l'utilisateur peut demander le service et prouve qu'il est autorisé d’employer
le service.
Ces différentes architectures AAA considèrent des domaines multiples, mais la
situation où plusieurs rapports de comptabilité d'un terminal existent dans un service qui
croise des domaines multiples n'est pas encore décrite. De plus, l’architecture AAA n'est pas
capable de soutenir efficacement la fédération d'identité où l'utilisateur est connu sous des
identités multiples aux services. La fédération d'identité est un groupe d'organisation ou un
système qui échange l'information d'identité dans une voie assurée.
Dans la plate- forme architecturale d’IMS, le profil HSS d'utilisateur emmagasine
l’authentification et l’autorisation faite pour le terminal. Do nc, le HSS peut être considéré
comme un serveur AAA. Voire figure 5.11.
Dans les domaines administratifs IMS, seule une relation de client est présumée.
Actuellement, il n’y a pas de cas que soutenu le terminal à des identités multiples avec des
fournisseurs multiples de service pour un seul service IMS [123]. C'est dû à la façon de
comment l'utilisateur est enregistré dans le HSS. Le HSS est contacté par l'utilisateur qui à
une comptabilité support. La multiplicité d'identités est employée dans IMS pour des
utilisateurs qui ont des profils ou des dispositifs multiples.
Figure 5.11 : AAA en multi domaine
Deux solutions sont possibles pour implémenter les architectures AAA dans un réel
multi–fournisseur :
-
La solution saut-par-saut
La solution terminal-au-terminal
La solution "AAA saut par saut", voire la figure 5.12, est une répétition de la séquence pull,
tandis que la solution "AAA terminal au terminal", voire la figure 5.13, est la combinaison de
la séquence pull et la séquence agent.
Trois phases pourraient être distinguées pour chaque solution. La phase initiale, où un
raccordement de confiance entre les différentes zones est établit, et les identités sont
91
échangées. Dans cette phase l'utilisateur est enregistré et l’architecture AAA doit vérifier si
l'utilisateur est aussi connu avec les fournisseurs de service pour lesquels l'interaction aura
lieu. Car l'utilisateur est connu sous des identités différentes avec les différentes zones. La
deuxième phase, survient chaque fois si l'utilisateur demande le service. Dans cette phase
l’authentification, l’autorisation et la compatibilité du terminal doit être fait. La troisième
phase représente le normal comportement du service. La comptabilité et éventuellement la
réauthentification aura lieu pendant cette phase.
Dans la solution "AAA saut par saut" l’authentification du terminal, pendant la phase de
service d'interaction, survient par chaque domaine. Chaque domaine peut arranger son propre
AAA, et envoi alors la requête au prochain domaine. Les interactions 2,3 et 5,6 sont
accomplies en utilisant le protocole Diameter. Dans la solution "AAA terminal au terminal",
les serveurs AAA sont communiqués avec les interfaces Diameter. Pendant cette phase, les
serveurs AAA authentifient le terminal et envoient la requête au prochain domaine.
Figure 5.12: Solution AAA saut par saut
Dans l’IMS plusieurs interfaces de HSS sont définies pour l’emploi de protocole
Diameter. Le HSS est le serveur AAA d'un domaine administratif IMS, authentifie et autorise
et emmagasine les profils d'utilisateur. Les interfaces transportent l’authentification et
l’autorisation de l'information d'équipement de service, qui contient les clients AAA comme
serveurs d'application et CSCF, au HSS. Les applications spécifiques de Diameter sont
définies pour ces interfaces.
Figure 5.13: Solution AAA terminal au terminal
92
L’IMS et les serveurs d'application contiennent de multiples clients AAA qui
communique avec le HSS. Le HSS fournit l’AAA pour les utilisateurs qui sont enregistrés
dans un domaine administratif IMS. Si un autre domaine administratif est impliqué, alors ce
domaine devrait manier ses propres interactions AAA. Dans la spécification IMS, la solution
"AAA saut par saut" peut être aisément réalisée. Les domaines administratifs IMS peuvent
déjà être communiqués. Le cœur IMS et les serveurs d'application appartenant aux différents
domaines administratif sont reliés selon la solution "AAA saut par saut". Dans la spécification
IMS, la solution "AAA terminal au terminal", n'est pas possible car le HSS ne soutient pas
une interface qui peut être employée pour l'interconnexion aux autres HSS (serveurs AAA). Il
sera donc avantageux d’ajouter une interface au HSS qui peut être employée pour leur
interconnexion au autre HSS/AAA situées dans différent domaines administratifs IMS. Noter
que cette interface peut aussi être employée pour communiquer un HSS/AAA situé dans un
domaine administratif IMS à un externe serveur AAA situé dans un non domaine
administratif IMS. Actuellement le corps de standardisation 3GPP ne précise pas une
interface pour l’interconnexion multi domaines de HSS serveurs AAA.
5.6.2 La solution proposée : IPsec
Un domaine de sécurité est définit généralement comme un réseau opéré par une seule
autorité administrative qui entretient une politique de sécurité uniforme dans ce domaine. Le
niveau de sécurité et les services disponibles de sécurité seront généralement les mêmes dans
ce domaine de sécurité. Cependant, il est possible d'entretenir plusieurs plus petits domaines
de sécurité, que chacun constitue un sous-ensemble du cœur réseau entier d'opérateur. L’IMS
applique le concept familier d'un réseau natal et d’un réseau visité. Deux scénarios différents
qui existent, dépendant, si l'utilisateur est en raoming ou non. Dans le premier scénario, son
premier point de contact de l'utilisateur à l’IMS est P-CSCF qui est située dans son réseau
natal et dans le deuxième scénario, son P-CSCF est situé dans le réseau visité. Donc, le
premier point de contact avec l’IMS n’est pas son réseau natal. Voire la figure 5.14.
Figure 5.14 : Architecture de sécurité Inter-Domaine
93
Pour protéger les opérateurs IMS ainsi que la circulation des flux entre le visité et le
natal. L'idée fondamentale est de fournir une sécurité saut par saut, où les entités de réseau
établissent entre eux une association de sécurité (SA) pour négocier les paramètres des
sécurisations entre domaines suivis d’une technique de confidentialité des échanges aux
niveaux des données acheminées. Ces deux outils : association de sécurité ainsi qu’une
technique de confidentialité peuvent être réalisé entièrement par le protocole IPsec.
IP Security est un ensemble de mécanismes et de protocoles permettant de sécuriser la
couche IP. Il a été développé pour fonctionner de la même façon avec IPv4 et IPv6 [118]. Il
offre les fonctions suivantes : authentification de l'expéditeur d'un paquet, Intégrité du
contenu des paquets échangés et la confidentialité des données transportées. IPsec ajoute de la
sécurité dans la couche 3 sans changer les interfaces vers les couches supérieures, ainsi les
applications peuvent bénéficier des fonctionnalités d'IPsec sans aucune adaptation. Il permet
de sécuriser le trafic, entre deux stations, entre une station et un routeur, ou entre deux
routeurs. Il implémente donc un mécanisme de tunnel.
L’IPsec contient les éléments suivants :
x
x
x
x
AH (Autenthication Header) : Protocole qui permet d'assurer l'intégrité des paquets
ainsi que l'authentification de l'expéditeur en ajoutant un en-tête supplémentaire au
paquet IP
ESP (Encapsulated Security Payload) : Protocole qui permet d'assurer la
confidentialité des échanges en chiffrant les données et en ajoutant un en-tête
supplémentaire au paquet IP
SA (Security Association) : Association de sécurité, concept représenté par un
contexte commun entre un émetteur de un récepteur de paquets IP, le contexte
comprend entre autre, les clefs utilisées pour le chiffrement et l'authentification.
IKE (Internet Key Exchange) Protocole de niveau applicatif qui permet d'établir et de
négocier automatiquement les SA (type de service, algorithmes, clefs…). L’IKE
s'appuie sur trois autres protocoles :
o ISAKMP (Internet Security Association Key Management Protocole):
un protocole qui fixe un cadre générique pour la gestion des SA et
l'échange de clefs, mais il ne définit pas les algorithmes utilisés ni les
paramètres qui peuvent être négociés pour les SA (RFC 2408, RFC
2407)
o OAKLEY : Un ensemble mécanismes cryptographiques pour générer et
échanger des clefs (RFC 2412)
o SKEME : Un ensemble mécanismes cryptographiques pour générer et
échanger des clefs.
Le fonctionnement de l’IKE est en deux phases : Durant la phase 1, les deux systèmes
négocient l'établissement d'une SA IKE. La SA IKE permet d'établir un canal d'échange
sécurisé entre les deux systèmes. Dans la phase 2, le canal négocié lors de la phase 1 est
utilisé pour créer et négocier les SA IPsec ainsi que pour échanger toutes les clefs nécessaires.
Contrairement à une SA IPsec, la SA IKE est bidirectionnelle. La SA IKE ne véhicule que des
informations de contrôle. Les paquets des utilisateurs circulent sur les SA IPsec. Figure 5.15.
Ces différents mécanismes de IPsec opèrent et fonctionnent dans l’environnement d’un
Gateway de security (SEG : Security Gateway) et fournissent la protection de la circulation
IP tout le long du réseau.
94
Figure 5.15 : Architecture SEG
La AS (Association Security) entre les différents domaines présente un contexte
commun entre l’émetteur et le récepteur de paquet IP pour mettre en œuvre les protocoles AH
et ESP. La SA est unidirectionnelle c'est à dire que pour protéger les deux sens de
communication, il faut deux SA, une dans chaque sens. Sur chaque SA on définit un seul
protocole, AH ou ESP. Si on veut mettre en œuvre AH et ESP en même temps, il faudra 2
SA. Toutes les données des SA d'un système sont regroupées dans une base appelée SAD
(Sécurity Association Database), le triplet : adresse de destination, protocole (AH ou ESP,
transport ou tunnel), et SPI identifie une SA de manière unique dans cette base.
Dans ce qui suit, nous proposons une architecture (figure 5.16) qui permet la sécurité
des services aux niveaux de domaine natal et aussi dans des multi domaines. Nous proposons
l’utilisation de la technique déjà évoquée dans la section 5. 5 au niveau d’un domaine natal et
IPsec entre domaines.
5.7 Conclusion
Avec la multiplicité de services crées et publiés par de différents opérateurs et aussi par
des personnels sur les réseaux des télécommunications ou Internet, la nécessité d’avoir des
fonctions de sécurité est accentuée. Les créateurs des services ont besoin de donner un aperç u
claire à chaque utilisateur ou à chaque abonné, où ses informations et ses ordres seront traités
correctement et que ses requêtes seront traitées solidement dans le réseau. Une telle
architecture de sécurité doit tenir en compte d u fait que les différents composants réseaux
s’interconnectent avec un minimum des Gateways d’interfaçages et d’adaptations. Dans ce
contexte, les mécanismes de sécurité proposée WS-security au niveau domaine et IPsec au
niveau multi-domaine sont très efficaces. La configuration ainsi que les implémentations sont
faciles et à la porté de différents spécialistes du domaine informatique et réseaux. Avec les
différents mécanismes de chiffrement, de l’authentification, des associations des sécurités, qui
ces protocoles utilises, des Firewalls peuvent être intègres au sein du réseau pour ajouter
d’autres mécanismes tel que le NAT et PAT.
95
Environnement Web
service
UDDI
IKE and ESP
L
IKE and ESP
L
XM
UDDI
XM
Environnement Web
service
Service
WS-Security
Service
W
SD
L,
W
SD
L,
SO
AP
,
SO
AP
,
IP
WS-Security
AS
G-F
I-CSCF
P-CSCF
AS
HSS
Parlay Web Service
Gateway
Parlay Web Service
Gateway
HSS
G-F
S-CSCF
I-CSCF
P-CSCF
S-CSCF
MRFC
MRFC
MGCF
MGCF
Media
Server
SRTP
Media
Server
SRTP
Media Gateway
Client
SRTP
SRTP
Media Gateway
Domaine
B
Domaine
A
Client
Figure 5.16 : Sécurisation entre domaines
96
Chapitre 6
Conclusion et perspectives
Résumé du contenu
61. Conclusion
6.2. Perspectives
6.1 Conclusion
Cette thèse s’inscrit dans le cadre des études et des recherches sur l’intégration des
services des télécommunications sur un réseau IP en se basant sur la technologie des services
Web, ainsi que sur la sécurisation des services à valeur ajoutée sur les terminaux fixes et
mobiles.
Notre contribution consiste à définir des techniques qui permettent d’intégrer le
service intelligent classique PSTN sur le réseau Internet IP et d’utiliser la technologie de Web
service soit pour remplacer certaines fonctions relatives aux réseaux intelligents soit pour
créer d’autres fonctions équivalentes. Deux approches sont ensuite proposées pour définir des
niveaux de la sécurité adéquate pour les terminaux fixes et mobiles.
Nos principales contributions portent sur :
1. L’intégration des services télécoms sous IP : grâce aux propriétés spécifiques du
protocole SIP. Nous proposons une méthode qui utilise SIP comme protocole de
signalisation d’appel, TRIP comme protocole de routage des requêtes d’appel pour
permettre d’atteindre la destination désirée. Cette technique de routage utilise des
domaines distribués appelé ITAD. Ceci est au niveau IP, au niveau PSTN, le
protocole ENUM est utilisé pour permettre la traduction des numéros E.164 en
DNS (e164.arpa) ou vis versa, suivant la source de la demande du PSTN vers IP
ou de l’IP vers PSTN.
2.
L’intégration des services télécoms avec les Web services : dans le contexte, de
Web service, nous proposons une méthode à base de la combinaison du SIP avec
SOAP pour permettre un Web service de jouer un rôle fondamental dans les
opérations d’intégration ou de création des services télécoms : Premièrement le
Web service est exploité pour permettre la découverte des différents services
publiés dans des bases des données distribuées et hétérogènes et ceci par la
97
publication des différents services dans UDDI. Deuxièmement le Web service avec
le browser VoiceXML jouent le rôle d’un dispositif de communication interactive
équivalent à l’SRF du réseau intelligent. Ceci nous permet soit de remplacer
l’SRF existant soit de créer de nouveaux services demandant du dialogue
interactive. Troisièmement nous abordons la création des services télécoms dans
les réseaux mobiles. Dans ce contexte, notre contribution porte sur
l’interconnexion de la plateforme Parlay X Web service pour créer, invoquer et
publier des différents services pour les terminaux mobiles dans un environnement
multi-domaines, multi-terminaux et multi- fournisseurs en se basant sur
l’architecture IMS.
3. Sécurisation des services télécoms : Nous proposons pour réponde aux exigences
de la sécurité, deux techniques différentes. La première technique est relative à un
domaine : dans cette technique nous proposons trois niveaux de sécurité : le
premier niveau concerne la sécurité de la signalisation où les mécanismes de
sécurité SIP sont explicités. Le deuxième niveau concerne la sécurité des données
services où on utilise l’outil WS-security qui permet la sécurisation des messages
sans tenir compte des nœuds externes. Enfin le troisième niveau où nous
proposons l’utilisation de la SRTP pour assurer l’acheminement des données
media en temps réel ainsi que l’authentification. La deuxième technique est
consacrée à la sécurisation entre domaines: Deux approches sont discutées dans
cette partie, l’approche avec un serveur AAA et l’approche par les mécanismes
proposées par IPsec. Après avoir montré les difficultés techniques relatives aux
serveurs AAA, nous proposons le scénario de sécurisation proposé par l’IPsec pour
la sécurisation des services intelligents mobiles entre domaines.
6.2 Perspectives
Avec l’intégration des réseaux intelligents sur IP et la technologie des Web services, il
est possible théoriquement de rendre la création et l’invocation des services télécoms une
opération assez facile et non plus restreinte uniquement aux grands opérateurs.
Ce qui est important dans ce qui on a proposé est l’implémentation des différentes
méthodes sur des plates formes distribuées auprès des clientèles. Certaines sociétés telles que,
ZTE, Ericson, M5T, etc, proposent leur propre architecture d’implantation et de protection
des services intelligents sur des terminaux fixes et mobiles, mais l’ouverture de cette
implantation même restreinte vers la majorité des citoyens, n’est pas encore possible.
Même si le protocole de signalisation SIP et IMS définissent un certain degré de
sécurisation, il soufre de différents problèmes liés à IP et UDP. Dans ce contexte, nous
proposons d’exploiter la technique de WS-Security ainsi que les opérations de routages
sécurisées faite avec WSE. La signature numérique, l’authentification et l’autorisation sont
aisément facile au niveau configuration et implémentation avec XMLsecurity. Ce qui permet
aux différents créateurs des services ou opérateurs de définir ses propres paramètres de
sécurisation, sans recours aux protocoles standards dont les avantages, les inconvénients et les
failles sont connus.
98
Bibliographie
[1] B. El Ouahidi : Modèle de types et langages de modélisation de QoS pour les systèmes
repartis ouverts ; thèse de doctorat d’état à l’université de Mohammed V- Agdal ; 28 janvier
2002.
[2] S. Znaty : Les réseaux intelligents, ingénierie des services de télécommunication. Editions
Hermes, Paris, 1997.
[3] Technique de l’ingénieur : réseaux télécommunications ; Edition technique de l’ingénieur,
2003
[4] ART : Etude technique, économique et réglementaire de l’évolution vers les réseaux de
nouvelle génération (NGN, Next Generation Networks) ; Septembre 2002.
[5] H. Schulzrinne, J.Rosenberg : A comparison of SIP and H.323 for Internet Telephony, in
Proc. International Workshop on Network and Operating System Support for Digital Audio
and Video (NOSSDAV), cambridge, England, July 1998, pp. 83–86.
[6]I.Dagic, H.fang : Comparison of H.323 and SIP for IP telephony signalling, Multimedia
systems and applications. Conference No2, Boston MA, Etats-unis (20/09/1999)
1999 , vol. 3845, pp. 106-122. ISBN 0-8194-3438-8 ; SPIE proceedings series
[7] j.Chapron, B.Chatras : An analysis of the IN call model suitability in the context of VoIP;
Compter Networks 35, 2001.
[8] H. Schulzrinne: The Session Initiation Protocol (SIP); hgs/SIP Tutorial may 2001.
[9] A.Johnston & al, Internet Engineering Task Force : SIP service examples; draft-ietf-sipservice-examples-03.txt; June 2002.
[10] Henning.S & Jonathan.R : The session Initiation Protocol : Providing Advanced
telephony services Across the Internet, Bell Labs Technical Journal. October-December 1998.
[11] J.Rosenberg, J.Lennox, H.Schulzrinne: Programming Internet Telephony Services ; TechReport Number CUCS-010-99.
[12] W.Wang, S.Cheng: Accessing traditional intelligent services from SIP network; 0-78037010-4/01 IEEE 2001.
[13] Internet Draft , VK. Gurbani : Interworking SIP and Intelligent Network (IN)
Applications; RFC 3978; June 2002
99
[14] H. Schulzrinne, L. Slutsman¸ I. Faynberg, H. Lu : Interworking between SIP and INAP;
draft-schulzrinne-sin-00.txt; January 2005.
[15] B.El ouahidi & al : Extending the Internet with the Intelligent Network capabilities; 07803-6419-8/00. IEEE2000.
[16] EEEurescom Project P916 Supporting of H323 by IN: Providing IN functionality for
H323 telephony calls, October 2000.
[17J. Peterson : Telephone Number Mapping (ENUM) Service Registration for Presence
Services. RFC 3953, January 2005.
[18] Fing: Principes et conditions de mise en oeuvre du standard ENUM en France;
http://www.art-telecom.fr/publications/index-cp-enum.htm. 18 juin 2001.
[19] Faltstrom.P : E.164 number and DNS; Network working Group; RFC 2916; September
2000.
[20] Zenkri.j & Marine.S : Téléphonie sur IP ; UIT groupe d’Experts aspects techniques 10
octobre 2001.
[21] Lind.S & AT&T : ENUM call flows for VoIP Interworking; IETF February 2002.
[22] Yongtae. S : TRIP Telephony aver IP, VoIP Workshop 2000.
[23] Schweizer.L :
23/12/2001.
Scripts et APIs pour la gestion de serveurs SIP ; www.tcom.ch;
[24] W. Van Leekwijck D. Brouns: Siplets : la programmation de services de téléphonie sur
IP avec Java. Revue des Télécommunications d’Alcatel - 2e trimestre 2000.
[25] M.Aoyama, S.Weerawarana et H.Maruyama : Web Services Engineering : Promises and
Challenges, ICSE’02 May 19-25, 2002, Orlando, Florida, USA.
[26] Dorgham S: Eurescom Project report : Next-Gen open Service Solutions over IP (NGOSSIP); Project P1111; june 2002.
[27] Mittelette.E : B r i e f . N E T « Tour d’horizon .NET » ; 27 Mars 2002.
[28] De Jong.I (and others) Web Services/SOAP and CORBA; April 15, 2002.
[29] Kenneth.C, Madhusudhan.G, Randall.B: Investigating the Limits of SOAP Performance
for Scientific Computing; Proceedings of the 11 th IEEE International Symposium on High
Performance Distributed Computing HPDC-11 2002 (HPDC’02).
[30] Robert.E, Ulf.P and Lars.L : Performance of SOAP in Web Service Environment
compared to CORBA; Proceedings of the Ninth Asia-Pacific Software Engineering
Conference (APSEC’02) IEEE 2002.
100
[31] Deason.N : White paper SIP and SOAP; ubiquity software corporation, may 2001.
[32] Deason.N: SIP for SOAP Sessions; Ubiquity Software Corporation Ltd; draft-deasonsipping-soap-sessions-00.txt. 23 April 2002 .
[33] Deason.N: SIP and SOAP; Ubiquity Software Corporation Ltd; draft-deason-sip-soap00.txt. June 30, 2000.
[34] Chauvet.J.M : Services Web avec SOAP, WSDL, UDDI, ebXML.…Eyrolles, 2002.
[35] Handley, Schulzrinne, Schooler, Rosenberg : SIP: Session Initiation Protocol, IETF SIP
WG Internet-Draft; draft-ietf-sip-rfc2543bis-01; ACIRI/Columbia U./Caltech/dynamicsoft
August 6, 2000.
[36] Handoura.A, Bourget.D : Combinaison de SIP et de SOAP via les Web Services ;
Journée scientifique 21-22 mai 2003 à Borj elamri, JS2003.
[37] Arabshian.K, Schulzinne.H : A generic event notification system using XML and SIP.
12/9/2003, Nyman Workshop
[38] Liu.F,Chou.W, Li.L and Li.J: WSIP – Web Service SIP Endpoint for Converged
Multimedia/Multimodal Communication over IP; Proceedings of the IEEE International
Conference on Web Services 2004 (ICWS’04).
[39] Cai.C, Lu.W, Yang.B, Tang.L : Session Initiation Protocol and Web Services for Next
Generation Multimedia Applications; Proceedings of the IEEE Fourth International
Symposium on Multimedia Software Engineering (MSE’02) IEEE 2002.
[40]Zhang.G, Hillenbrand.M : Implementing SIP and H323 signalling as Web services;
Euromicro Conference, 2004.
[41] Ivanova.E : SOAP based multiple search ; International Conference on Computer
Systems and Technologies-CompSysTech’2003.
[42] Tsenov.M : WAN communication using SOAP protocol ; International Conference on
Computer Systems and Technologies-CompSysTech’2003.
[43] Handoura.A, Bourget.D : Invocation des bases de donnée hétérogènes et distribuée par
SIP-SOAP via web services ; Journées JTEA-IEEE France12-14mai 2006. HammametTunisie.
[44] Tsenov.M : Application of SOAP protocol in E-commerce solution ; First international
IEEE symposium” Intelligent System” September 2002.
[45] Dong.W, Newmarch.J: Adding session and transaction management to Web services by
using SIP
[46] VoiceXML Forum; Version: 1.00 ; 07 March 2000.
101
[47] White paper: Communications Web services: bringing the value of the Web to voice
solutions; Intel corporation 2004.
[48] Singh.K, Nambi.A and Schulzrinne.H : Integrating VoiceXML with SIP services. IEEE
International Conference on Communications, 2003. ICC’03
[49] Bond.W.G, Cheung.E, Purdy.K.H, Zave.P, Ramming.J.C: An Open Architecture for
Next-Generation Telecommunication Services; ACM Transactions on Internet Technology,
Vol. 4, No. 1, February 2004, Pages 83–123.
[50] Rosenberg, Mataga, Ladd : A SIP Interface to VoiceXML Dialog Servers; draftrosenberg-sip-vxml-00.txt; July 13, 2001 dynamicsoft; IETF draft.
[51] Profos.D : Security requirements and concepts for Intelligents networks; International
Zurich Seminar on Digital Communications, 1992 ‘Intelligent Networks and their
Applications.
[52] Mavropodi.R, Douligeris.C : Intelligent Networks Security Issues and Performance
Evaluation; department of Informatics, University of Piraeus, Annual review of
communication, Volume 57, 2004 .
[53] Gundlach.M: How to secure user access and the communication between IN components;
Siemens AG, Munich; IN ’97: Intelligent Network Security; 4 - 7 My 1997.
[54] UIT ; Secteur de la normalisation des télécommunications de l’UIT : Sécurité dans les
télécommunications et les technologies de l'information ; Décembre 2003.
[55] Herrigel.A, Lai.X : Authentication and authorisation in the IN; R3 Security Engineering
AG. IEEE IN ‘94, Workshop pages: 1-21.
[56] Herrigel.A : A Security Architecture for the Core Part of CS – 2; IEEE Intelligent
Network Workshop 1996. 0-7803-3230-x/96 IEEE.
[57] Salsano.S, Veltri.L, and Papalilo.D: SIP Security Issues: The SIP Authentication
Procedure and its Processing Load; IEEE Network • November/December 2002, 08908044/02/ 2002 IEEE.
[58] Ranganathan.M.K, Kilmartin.L : Performance analysis of secure session initiation
protocol based VoIP networks; Computer Communications 26 (2003) 552–565; 2002 Elsevier
Science PII: S0 1 40 -3 66 4 (0 2) 00 1 46 –9.
[59] Handoura.A, Bourget.D : Implementing Intelligent Network Services in VoIP application
with SIP, TRIP and ENUM; 2nd IEEE International Conference on Information &
Communication Technologies : From theory to applications. 24-28 April 2006 Damascus,
Syria.
[60] Handoura.A, Bourget.D : Contrôle des sessions SOAP par SIP ; 6ème Journées
Scientifiques des jeunes chercheurs en GEI 2006 ; 24-26 mars Hammamet-Tunisie.
102
[61] J. Arkko et al., “Security Mechanism Agreement for SIP Sessions,” <draft-ietfsip-secagree-04.txt>, June 2002.
[62] C. Jennings, J. Peterson, and M. Watson, “Private Extensions to the Session Initiation
Protocol (SIP) for Asserted Identity within Trusted Networks,” <draft-ietf-sip-assertedidentity-01>, June 2002.
[63] M. Handley et al., “SIP: Session Initiation Protocol,” IETF RFC 2543, Mar.1999.
[64] J. Rosenberg, SIP Security, URL http://www.dynamicsoft.com/resources/pdf/SIP2000Security.pdf.
[65] G.114: One-way Transmission Time, ITU-T Recommendation, G Series, 2000.
[66] M. Laitinen and J. Rantala : Integration of Intelligent Network Services into Future GSM
Networks; 0163-6804/95/$04.00, IEEE Communications Magazine June 1995. pages 76-86.
[67] M. Badra : Le transport et la sécurisation des échanges sur les réseaux sans fil ; Thèse
de doctorat de l’Ecole Nationale Supérieure des Télécommunications- France, Spécialité :
Informatique et Réseaux, 05/11/2004.
[68] P.Samuel : Réseaux et systèmes informatiques mobiles ; Presses internationales,
Polytechnique 2003.
[69] N.Cédric : i-mode services multimédias pour téléphones mobiles ; Eyrolles edition 2003
[70] G.Carpentier, T.Coustenoble et B.Crombe : Solutions mobiles avec les logiciels IBM
Lotus, DB2, Websphere, Tivoli et Rational; Dunod 2003.
[71] Marc J.J. van Nielen : The impact of. mobility on Intelligent Network functions; P T T
Research. International Zunich Seminair on Digital Communication 1992. Pages A2/1-A2/11.
[72] L. Isotalo : Applying Intelligent Networks to GSM; 0-7803-1820-XI94 $4.00 0 1994
IEEE. Pages : 1253-1258.
[73] C. Rigault : L’intelligence dans les réseaux fixes et mobiles ; Département informatique
et réseaux, ENST, GET-Télécom Paris, France, Support de cours 2004.
[74] T. Aubonnet : Du réseau intelligent aux nouvelles générations de réseaux : création et
qualité de service ; Thèse en informatique et réseaux à l’école nationale supérieure des
télécommunications- France. Janvier 2002.
[75] R. Pandya : Network standards for emerging mobility services; ICUPC '93 0-7803-13968/93/ 1993 IEEE.
[76] M.P. Gervais and B. Jabbari : A Framework for Mobility in Wireless Personal
Communications; proceedings of the IEEE International Conference on Communications
(ICC’96), June 96.
103
[77] Y. Yongqing and J. Xiaojun : IN Technology in Mobile Network;
02000 IEEE.
0-7803-6394-9/00/
[78] M.C. Ciancetta, N. Gatti, E. Venuti : IN and Mobile : Security aspects in the merging of
two worlds. Intelligent Network '94 Workshop
[79] M.L.F. Grech : Providing seamless services for VoIP mobile data networks using
CAMEL/IN concepts; 3G Mobile Communication Technologies, Conference Publication
No. 471 IEEE 2000.
[80] P. Betouin, N. Fischbach : Sécurité de la Voix sur IP :Attaques et défenses ; EUROSEC
2005.
[81] N. Fischbach : sécurité de la Voix sur IP (VoIP) ; Actes du symposium SSTIC04.
[82] Qi Qiu : Study of Digest Authentication for Session Initiation Protocol (SIP); Master‘s
Project Report, SITE, University of Ottawa, December 2003.
[83] Samfat. D : Architecture de sécurité pour réseaux mobiles; thèse de l’école nationale
supérieure des télécommunications de Paris. 1997.
[84] http://jf.morreeuw.free.fr/security/a3a8.txt.
[85] Hamad El Allali.H and Hesselman.C : Multicasting with Mobile IP & The Session
Initiation Protocol; Department of Computer Science; The university of Dublin. Interne report
1996.
[86] Ericsson.E.W and Schulzrinne.H: Mobility Support using SIP; Second ACM/IEEE
International Conference on Wireless and Mobile Multimedia (WoWMoM'99), Seattle,
Washington, August, 1999
[87] Iuliana Popescu : Supporting Multimedia Session Mobility using SIP; CNSR 2003,
moncton, New brunswick, Canada.
[88] Duanfeng.S, Qin.L, Xinhui.H, Wei.Z : Security Mechanisms for SIP-Based Multimedia
Communication Infrastructure ; 0-7803-8647- juillet 2004 IEEE.
[89] Thernelius.F: SIP, NAT, and Firewalls; Master’s Thesis, May 2000. Department of
Teleinformatics, Kungl Tekniska Hogskolan.
[90] Steffen.A, Kaufmann.D, Stricker.A : SIP Security; Security Group, Zürcher Hochschule
Winterthur Gesellschaft für Informatik e.V. (GI), Ahrstrasse 45, D-53175 Bonn.2004.
[91] Jiang.W : A Lightweight Secure SIP Model for End-to-End Communication; in Proc. the
10th International Symposium on Broadcasting Technology (ISBT '05): 413-419, August
2005.
[92] Lagrange.X, Godlewski. P, Tabbane. S : Réseaux GSM : des principes à la norme (5°
Ed.) ; Lavoisier 2006.
104
[93] ITU-T : SERIES X: Data Networks and open System Communications – Security; date
30 august 2005.
[94] 3RD Generation Partnership, Projet 2’’3GPP2’’: Wireless Intelligent Networks; March
2004.
[95] Gerry.C: Mobile Intelligent Networking; 2000, http://www.mobilein.com.
[96] Daniel Amyot.D and Andrade.R : Description of Wireless Intelligent Network Services
with Use Case Maps; sbrc 1999.
[97] Schulzrinne. H, Wedlund.E : Application-Layer Mobility Using SIP ; 0-7803-71 33X/00/. 2000 IEEE.
[98] Sisalem.D, Kuthan.J: Understanding SIP; Mobile Integrated Services GMD Fokus.
http://www.fokus.gmd.de/mobis/siptutorial/.
[99] Howard.M, LeBlanc.D : Ecrire du code sécurisé; Microsoft 2003.
[100] Elthea.T.L, Johnson.I.Agbinya : Security Issues in SIP Signaling in Wireless Networks
and Services; 0-7695-2367-6/05 2005 IEEE.
[101] Lucent Technologies : International Networks Review ; Conférence SEE du 17 Janvier
2006.
[102] Znaty.S, Dauphin.J.L : IP Multimedia Subsystem : Principes et Architecture ; EFORT,
http://www.efort.com/r_tutoriels/IMS_EFORT.pdf
[103]Miguel Gómez, Tomás P. de Miguel, Spanish National Research Network (RedIRIS),
Advanced IMS Multipoint Conference Management Using Web Services. Communications
Magazine IEEE july 2007, Volume:45, Issue:7, pages: 51-57
[104] Camarillo.G, Kauppinen.T,Kuparinen.M,Más Ivars.I: Towards an Innovation Oriented
IP Multimedia Subsystem ; IEEE Communications Magazine. March 2007.
[105] Abhayawardhana.V.S, Babbage.R : A Traffic Model for the IP Multimedia Subsystem
(IMS) ; Vehicular Technology Conference, 2007. VTC2007-Spring. IEEE 65th. 22-25 April
2007 Page(s):783 – 787.
[106] Gourraud.C : Using IMS as a service Framework ;
Magazine. MARCH 2007.
IEEE Vehicular Technology
[107] Kühne.R, Görmer.G, Schläger.M, Carle.G : Charging in the IP Multimedia Subsystem:
A Tutorial ; IEEE Communications Magazine • July 2007.
[108] Baravaglio.A, Alberto Licciardi.C, Venezia.C : Web Service Applicability in
Telecommunication Service Platforms ; Proceedings of the International Conference on Next
Generation Web Services Practices (NWeSP’05), 2005.
105
[109] Chou.W, Liu.F, Li.L : Web Service for Tele-Communication; Proceedings of the
Advanced International Conference on Telecommunications and International Conference on
Internet and Web Applications and Services (AICT/ICIW 2006). 2006.
[110] Yim.J,Choi.Y, Lee.B: Third Party Call Control in IMS using Parlay Web Service
Gateway ; Feb. 20-22, 2006 ICA0T2006.
[111] Sur.A, Skidmore.D, Chakravarty.S : Web Services based SOA for Next Generation
Telecom Networks; IEEE International Conference on Services Computing (SCC'06). 2006.
[112] Gómez.M, Miguel.T : Advanced IMS Multipoint Conference Management Using Web
Services ; IEEE Communications Magazine • July 2007.
[113] Holtmanns.S, Phan-Anh.S: Access Authentication to IMS Systems in Next Generation
Networks; Sixth International Conference on Networking (ICN'07). 2007 .
[114] Radovanovic.I, Ray.A, Lukkien.J, Chaudron.M : Facilitating Mobile Service
Provisioning in IP Multimedia Subsystem (IMS) Using Service Oriented Architecture ;
ICSOC 2007, LNCS 4749, pp. 383–390, 2007. Springer-Verlag Berlin Heidelberg 2007.
[115] Lee.S, Leaney.J, O’Neill.T, Hunter.M: Open Service Access for QoS Control
in Next Generation Networks – Improving the OSA/Parlay Connectivity Manager ; IPOM
2005, LNCS 3751, pp. 29–38, 2005. Springer-Verlag Berlin Heidelberg 2005.
[116] Chande.S : Mobile Web Services ; December 2006.
[117] Draft ETSI ES 202 504-18 v0.0.1 (2007-06) : Open Service Access (OSA); Parlay X
Web Services.
[118] Sher.M,Magedanz.T,Penzhorn.W : Inter-Domains Security Management (IDSM)
Model for IP Multimedia Subsystem (IMS) ; Proceedings of the First International
Conference on Availability, Reliability and Security (ARES’06). 2006.
[119] Veltri.L , Salsano.S , Martiniello.G : Wireless LAN-3G Integration: Unified
Mechanisms for Secure Authentication based on SIP; IEEE ICC 2006 proceedings.2006.
[120] Huang.C, Li.J : One-Pass Authentication and Key Agreement Procedure in IP
Multimedia Subsystem for UMTS ; 21st International Conference on Advanced Networking
and Applications(AINA'07). 2007.
[121] Ooms.W, Karagiannis.G, Deventer.V, Veldhuizen.J: AAA architectures applied in
multi-domain IMS (IP Multimedia Subsystem) ; Globecom Workshops, 2007 IEEE26-30
Nov. 2007 Page(s):1 – 6. 2007.
[122] Jäntti.J, Matthews.D, Prag.J, Viguers.D, Yi.Y, Ziegenfelder.P: IMS Performance and
Tuning Guide ; Draft Document for Review November 17, 2006.
[123] Oguejiofor.E, Bazot.P, Georges.B, Huber.R, Jackson.C, Kappel.J, Martin.C,
Subramanian.C : Developing SIP and IP Multimedia Subsystem (IMS) Applications ; Draft
Document for Review January 9, 2007.
106
[124] Sinnreich.H, Johnston.A : Internet Communications Using SIP : Delivering VoIP and
Multimedia Services with Session Initiation Protocol ; Copyright 2006 by Wiley Publishing,
Inc., Indianapolis, Indiana, Published simultaneously in Canada ISBN-13: 978-0-471-776574, ISBN-10: 0-471-77657-2. Second Edition.
[125] Monfort Valérie, Goudeau Stéphane : Web service et interopérabilité des SI ; Dunod,
2004, ISBN 210008240X.
107
Liste des figures
2.1. Convergence dans NGN
2.2. Architecture physique simplifiée du réseau intelligent
2.3. Le modèle conceptuel du réseau intelligent
2.4. Les deux modes de fonctionnement SIP
2.5. API OSA
2.6. Architecture IMS
2.7. Architecture 3GPP
2.8. Architecture de service IMS
2.9. Enregistrement d’un usager mobile auprès de son réseau IMS
2.10. Etablissement d’une session IMS
2.11. Implantation et exécution de Web service
2.12. Opérations pour émission et réception d’un message SOAP
3.1. Interconnexion SIP - IN.
3.2. Correspondance entre modèle d’appel IN et l’état d’appel SIP
3.3. Modèle de communication du SIP au O_BCSM
3.4. Modèle de communication du SIP au T_BCSM
3.5. Réseaux utilisant ENUM
3.6. Table des services ENUM
3.7. Différents niveaux ENUM
3.8. Enregistrement pour accès à un service ENUM
3.9. Enregistrement du client dans un domaine
3.10.Exemple de DNS et NAPTR services
3.11.Illustration de problème de localisation des Gateways
3.12.Routage TRIP dans un ITAD
3.13.Communication avec TRIP entre deux ITADs
3.14.TRIB et routage
3.15.Format TRIP
3.16.Format de message UPDATE
3.17.Mise à jour TRIP
3.18.Routage TRIP
3.19.Interconnexion PSTN-IN-IP
3.20.Méthode d’invocation des services par SIP
3.21.Accès à la IN par un client SIP
4.1.
4.2.
4.3.
4.4.
4.5.
4.6.
4.7.
Exemple des piles SOAP-SIP
Application Web services
SOAP dans SIP
Telecom Web service Architecture
Architecture IMS-SOAP Gateway
Architecture SOA modifié
Module IMS du terminal Mobile Web Service
108
4.8. Etablissement d’une session dans MWS
4.9. Support mobilité et invocation d’un service
4.10.Mobile Web service et SIP-SOAP
4.11.Base de données distribuée avec le script de recherche
4.12.Recherche dans des bases des données par SIP – SOAP
4.13.Les opérations du browser SIP/VoiceXML
4.14.Connexion à un service via VoiceXML browser
4.15.Plan fonctionnel global et logique de service de SIB User Interaction
4.16.Réseaux intelligent traditionnels et la configuration proposée
4.17.Digramme d’échange d’un SIB UI avec VoiceXML et Web services
4.18.Architecture Parlay X Web services
4.19.Déploiement Parlay Web Services
4.20.Parlay Web Services avec Parlay Proxy Application Server
4.21.Environnement de création et publication des services
4.22.Diagramme de configuration Parlay X Web service
5.1 Architecture réseaux GSM et GPRS
5.2 Confidentialité des données transmises sur la voie radio
5.3 Les mécanismes des sécurités SIP
5.4 Authentification SIP avec http Digest
5.5 Message chiffré
5.6 Routage WSE
5.7 Format du paquet SRTP
5.8 Implantation d’un mécanisme de sécurisation
5.9 Diagramme de fonctionnement des réseaux intelligents sécurisé
5.10 Les différentes séquences AAA
5.11 AAA en multi domaine
5.12 Solution AAA hop-by- hop
5.13 Solution AAA end-to-end
5.14 Architecture de sécurité Inter-Domaine
5.15 Architecture SEG
5.16 Sécurisation entre domaines
109
Liste des Abréviations
AC
ACL
API
ASN.1
ATM
ANSI
AUC
BSC
BSS
BSSAP
BTS
B2B
B2E
BCSM
CA
CAMEL
CCAF
CCF
CSCF
CFU
DCSl800
DECT
DTMF
DL
DoS
EIR
ETSI
EURESCOM
FPLMTS
GPRS
GGSN
GMSC
GSM
HLR
HSS
I-CSCF
IETF
IMEl
IMS
IMSl
IN
Access Control
Access Control List
Application Programming Interface
Abstract Syntax Notation One
Automated Teller Machine
American National Standards Institute
Authentication Center
Base Station Controller
Base Station Subsystem
Base Station Subsystem Application Part
Base Transceiver Station
Business to Business
Business to Employee
Basic Call State Model
Certifying Authority
Customized Application for Mobile Enhanced Logic
Call Control Agent Function
Call Control Function
Call Session Control Function
Call Forwarding Unconditional
Digital Communications System
Digital European Cordless Telephone
Dual-Tone Multi-Frequency
Discrete Logarithm
Denial of Service
Equipment Identity Register
European Telecommunications Standards Institute
European Institute for Research and Strategic Studies in
Telecommunications GmbH
Future Public Land Mobile Telecommunications System
General Packet Radio Service
General GPRS Support Node (ou Media Gateway)
Gateway MSC
Global System for Mobile Communications
Home Location Register
Home Subscriber Server
Interrogating CSCF
Internet Engineering Task Force
International Mobile Equipment Identity
IP Multimedia Subsystem
International Mobile Subscriber Identity
Intelligent Network
110
INAP
INCM
ISDN
ISUP
ITU
IWF
Intelligent Network Application Part
IN Conceptual Model
Integrated Services Digital Network
ISDN Subscriber User Part
International Telecommunications Union
Inter-Working Function
IDS
IrDA
J2ME
JCE
JDK
JNI
JSR
JVM
KP
KS
LAPD
MAC
MAP
M FA
MGCF
MINCM
MONET
MS
MSC
NGN
NSS
OCSP
OMC
OSA
P2P
PAN
PDA
PGP
PIN
PKI
PAD
PCN
PCS
P-CSCF
PDF
Intrusion Detection System
Infrared Data Association
Java 2 Micro Edition
Java Cryptographic Extension
Java Development Kit
Java Native Interface
Java Specification Request
Java Virtual Machine
Public Key
Private Key
Link Access Protocol for the D-channel
MAC address: Media Access Control address
Mobile Application Part
Management Functional Areas
Media Gateway Control Function
Management IN Conceptual Model
Mobile Network
Mobile Station
Mobile Switching Center
Next Genaration Network
Network and Switching Subsystem
On-line Certificate Status Protocol
Operation and Maintenance Center
Open Services Architecture
Peer-to-Peer
Personal Area Network
Personal Digital Assistant
Pretty Good Privacy
Personal Identification Number
Public Key Infrastructure
Packet Assem bler/Disassembler
Personal Communications Network
Personal Communications Services
Packet CSCF
Police Decision Functions
PIN
PLMN
PNO
POTS
PSTN
RF
RFID
Personal Identification Number
Public Land Mobile Network
Public Network Operator
Plain Ordinary Telephone Service
Public Switched Telephone Network
Radio Frequency
Radio Frequency Identification
111
RMI
RSA
SIM
SIB
SOAP
SPK
SPKI
SCCP
SCEF
SCF
SCP
SDF
SIM
S-CSCF
SGSN
SMAF
SMF
SMS
SMS-GMSC
SRF
SS7
SSF
SSP
TCAP
TISPAN
TMN
TMSl
TRIP
TUP
TTP
USIM
UPT
UMTS
VLR
VPN
WAN
WiFi
WLAN
X.25
XACML
XML
XSLT
3GPP
3GPP2
Rivest-Shamir-Adleman public key cryptosystem
Subscriber Identity Module
Service Independent building Block
Simple Object Access Protocol
Signature based on a Proof of Knowledge
Simple Public Key Infrastructure
Signaling Connection Control Part
Service Creation Environment Function
Service Control Function
Service Control Point
Service Data Function
Subscriber Identity Module
Serving CSCF
Serving GPRS Support Node (ou Softswich)
Service Management Access Function
Service Management Function
Short Message Service
Short-Message-Service Gateway-MSC
Special Resource Function
Signaling System 7
Service Switching Function
Service Switching Point
Transaction Capabilities Applications Part
Telephony and Internet converged Services and Protocols for Advanced
Networking
Telecommunication Management Network
Temporary Mobile Subscriber Identity
Telephony Routing over IP
Telephone User Part
Trusted Third Party
Universal Subscriber Identity Module
Universal Personal Telecommunications
Universal Mobile Telecommunications System
Visitor Location Register
Virtual Private Network
Wide Area Network
Wireless Fidelity
Wireless Local Area Network
Access Protocol of Packet-Switched Data Network
Extensible Access Control Markup Language
Extensible Markup Language
Extensible Style-sheet Language Transformation
Third Generation Partnership Project
Second groupe 3GPP
112
Publications de l’auteur
Publications associées à cette thèse :
9 Integration and creation of intelligent network services in NGN:
Submitted to International Journal for the computer and
Telecommunications Industry.
9 IMS security in intelligent network mobile: Submitted to International
Journal of Computer Science and Information Security.
9 1- Intelligent network security with SIP and web services:
WORLDCOMP'09 - The 2009 World Congress in Computer Science,
Computer Engineering, and Applied Computing (The 2009 International
Conference on Security and Management (SAM'09); Las Vegas – Nevada
USA July 13-16/2009.
9 Chapitre dans un livre: Secure Intelligent Network Services: SIP
Handbook: Services, Technologies, and Security; Editors: Syed Ahson
and Mohammad Ilyas. Publisher: CRC; 1 edition (Nov 2008), ISBN-10:
142006603X, ISBN-13: 978-1420066036.
9 2- Mobile Intelligent Network security with SIP Authentication
Procedure: 9th International Conference on Advanced Communication
Technology ICTTA’08. Damascus – Syria 24-28 April 2008
9 3- Securing the SIP communications with XML security mechanisms in
intelligent network applications:
4th International Conference on
Information Technology: New Generations (ITNG) April 2-4, 2007, Las
Vegas, Nevada, USA (Proceedings to be published by the IEEE Computer
Society.)
9 4-Telecommunications services security with SIP in VoIP Application :
XIX. International Conference on Computer and Information Science and
Engineering, January 29-31, 2007, Bangkok Thailand
9 5- Implementing Intelligent Network Services in VoIP application with
SIP, TRIP and ENUM: 2nd IEEE International Conference on Information
113
& Communication Technologies: from Theory to Application-ICTTA’06.
Damascus – Syria 24-28 April 2006.
9 6- Implementing a SIB Intelligent Network with VoiceXML, SIP and
Web services: 2006 IEEE International Conference on System of Systems
Engineering: Control, Command, Communication, Computing and
Information; Los Angeles 24-26 April 2006.
9 7- Invocation des bases de données hétérogènes dans un environnement
distribué
par SIP via Web services : Journées Tunisiennes de
l’Electrotechnique et de l’Automatique, JTEA-IEEE France, 12-14 mai
2006, Hammamet – Tunisie.
9 8- Contrôle des sessions SOAP par SIP : 6ème Journées Scientifiques des
Jeunes chercheurs en Génie Electrique et Informatique, ENIS Sfax Tunisie 24-26 mars 2006.
9 9- Combinaison de SIP et de SOAP via les Web Services : 3ème Journées
Scientifique Borj Elamri - Tunisie mai 2003.
Publications associées au DEA :
9 10- Estimation d’un signal de la parole bruitée par la technique de WignerVille : Journées Scientifique Francophone, Tozeur – Tunisie 20-22/12/2003.
9 11- An Approach for the Realization of Sentences in Arabic Language
Phonetically Balanced for a speech recognition system: The 1st International
Conference on Digital Communications and Computer Applications
(DCCA2007) 19-22 march 2007- Jordan.
Publications pédagogique et industrielle:
9 12- L’enseignement de la télécommunication à l’ISET de Gabès dans les
besoins d’un établissement supérieur : Journées Scientifique
&
technologiques Cotes d’Armor-Gabès Saint-Brieuc & Lannion - France 1416/05/2001.
9 13- Les ondes acoustiques de surface (SAW) et leurs applications
industrielles : Journées Scientifique & technologiques Cotes d’Armor-Gabès
Saint-Brieuc & Lannion - France 14-16/05/2001
9
Un livre de 300 pages, résumé des cours, exercices et problèmes corrigés :
Précis d’électricité industrielle ; février 1999 ; ISBN : 9973-31-179-5
114
Synthèse de la thèse
Nous nous intéressons dans cette thèse à l’évolution des réseaux intelligents vers les
nouvelles générations de réseaux NGN (Next Generation Network) qui s’appuient sur les
différents réseaux de transport. Dans ce contexte, une architecture ouverte est nécessaire à la
création rapide et à la sécurisation de services dans un environnement muti-opérateurs, multifournisseurs, permettant l’évolution des services existants, indépendamment des réseaux et
des accès empruntés.
Depuis l’avènement des réseaux SIP et la mise en œuvre de ces services, l’intégration
des réseaux intelligents (services intelligents au dessus du PSTN) et des réseaux SIP (Session
Initiation Protocol sur IP) est devenue primordiale [1,4,7,8]. C’est ainsi que plusieurs travaux
ont été réalisés permettant cette intégration. Nous citons les travaux qui portent sur la
connexion entre le modèle d’appel du réseau intelligent (machine à états fini) et le modèle
d’états SIP [1,12,13,14,15]. Ces travaux constituent une étape importante pour l’intégration,
néanmoins, la description d’un service IN (Intelligent Network) et son utilisation dans un
environnement réel n’a jamais fait l’objet d’étude. Dans ce contexte nous proposons un
schéma complet d’invocation d’un service IN à travers des réseaux SIP, réseaux PSTN et
réseaux IN. Ceci en utilisant les protocoles ENUM (tElephony NUmbering Mapping) et
TRIP (Telephony Routing over IP). En effet ENUM permet de réaliser une traduction entre
les deux plans d’adressages IP et E.164 (PSTN) et de définir un identificateur unique pour les
différents utilisateurs SIP et PSTN, ce qui permet une utilisation conjointe de deux adresses
SIP et PSTN. TRIP permet de résoudre les problèmes de routage et de localisation des
Gateways en division les réseaux SIP en plusieurs ITAD (IP Telephony Administrative
Domain) ; où chaque ITAD regroupe plusieurs serveurs de localisation LS (Localisation
Server) administré par un seul opérateur. La mise à jour entre ces différents LS est réalisée
par la requête UPDATE (entre les LS du même ITAD ou entre les LS de différents ITADs).
Le schéma proposé décrit aussi la difficulté de la localisation de la bonne SCP (Service
Control Point) en question pour un service IN et pour un opérateur télécoms. C’est ainsi que
notre proposition consiste à utiliser l’ISG (Intelligent Service Gateway) pour localiser les
SCPs. L’ISG est un pont entre les opérateurs de réseaux des télécommunications et les
réseaux intelligents.
Notre deuxième contribution permet de remplacer les deux composants du réseau intelligent à
savoir SDF (Service Data Function) et SRF (Service Ressource Function) par l’utilisation
combinée de SIP, SOAP et VoiceXML.
En fait SIP permet de déterminer le trajet permettant à une requête (englobant des données
SOAP) d’atteindre la destination souhaitée. Une combinaison de SIP et SOAP (Simple
Object Access Protocol) est nécessaire pour toute opération de recherche de données dans des
serveurs ou base de données [30,31,32,]. Cette combinaison est possible de plusieurs
manières [33]. La technique la plus utilisée est l’insertion du message SOAP dans le contenttype du message SIP.
En outre, pour résoudre le problème de création de services télécoms indépendamment des
composants IN, plusieurs travaux de recherche [72, 74, 77] proposent des Gateways
permettant l’adaptation (utilisation) des composants du réseau IN (l’SDF, l’SRF et l’SCP) à
travers SIPs. Notre proposition remplace complètement ces composants par des composants
de la technologie Internet sans recours à des Gateways spécifiques.
115
C’est ainsi nous proposons dans un premier temps de remplacer la base de donnée SDF (qui
contient généralement les différentes informations relatives aux utilisateurs ainsi qu’aux
services en question) par des bases de donnée distribuées. La technique proposée est basée sur
trois composants :
-
Un annuaire UDDI (Universal Desceiption Discovery and Integration) contenant les
URLs de différentes bases de données (SDF)
Une base de données contenant les informations relatives à un service, à un client, ou
à un opérateur.
Un client SIP.
Le client invoque l’annuaire par un message SIP-SOAP contenant l’information cherchée.
L’annuaire répond en donnant l’URL de la base de données qui contient l’information
recherchée. Le client envoie alors une requête SOAP à la base de données en question.
En second lieu, nous proposons de remplacer la fonction de ressource spécifique SDF (qui en
réalité un serveur vocale permettant de faire un dialogue interactif avec un client) par un
browser VoiceXML. Les différentes informations habituellement enregistrées dans l’SRF
telles que UI (User Interaction) ou toutes autres informations vocales nécessaires pour l’accès
à un service IN seront enregistrées dans le browser VoiceXML avec le langage VXML. C’est
qu’une fois un programme est enregistré, le client SIP et à travers SIN et SCP accède
directement au browser VoiceXML qui interagit avec lui par des messages vocale, tels que :
donner votre code PIN, donner votre code d’accès, etc, afin de valider ou non son accès.
Par ailleurs, au niveau des réseaux mobiles, plusieurs travaux de recherches se reposant sur
les concepts VHE ont contribué à l’élaboration de trois modèles :
-
-
Un modèle à base de Telecom Web Services Server (TWSS) [123] qui utilise la
plateforme IBM Websphere permettant l’accès aux réseaux télécoms fixes et mobiles
grâce à un Gateway OSA ou Parlay.
Un modèle à base d’un Gateway IMS-SOAP permettant l’intégration de l’IMS sur
un service orienté OSA ainsi que d’autres normes ouvertes [122.123]
Un modèle à base de la combinaison SIP-SOAP au niveau d’un terminal mobile
permettant l’accès au service de données dans un réseau mobile. Ce modèle est appelé
Mobile Web Services(MWS) [116,123].
Ces différents modèles constituent une étape très importante pour la création et
l’intégration des services télécoms sur le réseau NGN. Néanmoins leurs implémentations
ainsi que leurs utilisations sont encore restreintes à certaine architecture (TWSS), ou à des
modifications et des configurations pour chaque application (IMS-SOAP, MWS).
Dans ce contexte nous proposons un schéma complet permettant l’interconnexion du
réseau IMS avec un environnement de création de service IN constitué par les modules :
SIN, SOAP, UDDI, VoiceXML à travers un Gateway proposé par le Groupe Parlay :
Parlay Web service Gateway. Le modèle Parlay Web service défini par le groupe Parlay
en 2003 dispose des APIs qui lui permettent de s’interconnecter avec les outils de la
technologie Web service utilisés dans notre travail pour la création des services télécoms.
116
Ces différents modules permettent d’intégrer un service télécoms sur le réseau mobile
avec SIN, SOAP, VoiceXML ou de publier un service avec UDDI, SOAP, ou de créer un
service par SOAP, UDDI, WSDL sur un environnement fixe ou mobile.
Pour terminer notre travail et proposer ainsi une architecture complète aux niveaux
intégration, création et sécurisation des services télécoms, nous proposons des techniques
qui portent sur la sécurisation des trois composants actifs dans une invocation d’un
service à savoir, le client, le service et l’opérateur.
Plusieurs travaux de recherche portent sur la sécurisation des différents composants
mises en jeux au cours d’une activation d’un service télécoms, mais jamais pour tous les
composants en même temps lors d’une utilisation réelle d’un service [51,52,53,55].
Au niveau de réseau fixe, la sécurisation d’un service implique la sécurisation de la
requête de signalisation SIP, la sécurisation de données service ainsi que la sécurisation
de données clients et opérateur. Les travaux de recherches dans ce contexte portent sur :
- La sécurisation de la signalisation SIP par Proxy –Autentication au niveau serveur
proxy et WWW-Authentication au niveau client [57,61]. On trouve également
d’autres techniques telles que l’utilisation du PGP ou S/MIME au sein de protocole de
description SDP [64]
- L’utilisation du protocole SRTP pour la protection du media [79]
- L’utilisation du protocole SSL ou TLS pour la protection de données transportées
dans le réseau IP [58,80]
- L’utilisation du protocole IPsec pour la protection du paquet IP co ntenant les données
client, service, opérateur [80].
- L’utilisation d’autres techniques conçues par les opérateurs eux même et qui sont
généralement des techniques de cryptographie non standard [77].
Ces différentes techniques constituent une étape importante pour la sécurisation d’un service
télécoms. Néanmoins leur utilisation en même temps constitue un problème au niveau
d’interopérabilité, de latence pour les services multimédias et nécessite l’ajout d’une étape de
négociation des techniques employées afin de choisir une, avant chaque invocation.
La méthode que nous proposons, traite le problème de la sécurité par un schéma complet
contenant, le client SIP, l’environnement du service (création, intégration, transfert data
service), fournisseur ou opérateur et le réseau support IP. Cette vision globale et complète
pour la sécurisation des services télécoms n’a pas été faite dans les anciens travaux de
recherche malgré qu’elle soit nécessaire pour valider les solutions proposées.
Pour faire suite à nos travaux dans les thèmes d’intégration et de création de services
télécoms et éviter tous les problèmes qui peuvent être engendrés par l’utilisation d’une
technique efficace pour un des composants (client/donnée/service/opérateur) et qui n’est pas
supportée par les autres, nous proposons :
- L’utilisation de la technique de sécurité proposée par SIP déjà citée, pour sécuriser la
signalisation.
- L’utilisation de la technique WS-Security, pour la sécurisation des données service
ainsi que la requête de transport et les opérations de routage SOAP. Cette technique
est très efficace [83,126], par le fait qu’elle repose sur la technique du monde Internet
XML Security (défini dans http://www.w3.org/TR/xml..../). XML Security assure la
confidentialité ainsi que l’intégrité de donnée par des techniques standards où le client
117
-
ou l’opérateur peut choisir l’information à protéger, ainsi que la clé à utiliser et la
technique à employer. Avec ceci WS-Security permet la protection de la requête
donnée tout le long de son trajet par la technique de SeurityToken qui peut être
ajoutée facilement au message SOAP de base.
L’utilisation d’une technique inspirée de la méthode Kerberos pour avoir l’accès au
service à travers un serveur d’autorisation de service (analogue à KDC pour Kerberos)
et un serveur d’autorisation de l’opérateur (analogue à TGS pour Kerberos).
Au niveau réseau mobile et plus exactement au niveau de réseau de convergence fixe et
mobile IMS, on a déduit à partir de certaines recherches qui portent sur cet axe que le
problème principal est la sécurité entre plusieurs domaine IMS [113,115,118]. Malgré que ces
travaux proposent généralement la technique AAA (Authentication, Authorization
Accounting)[120] pour assurer la sécurité entre domaines, elles reposent aussi sur certaines
hypothèses qui ne sont pas généralement valables, à savoir :
Le HSS est le serveur AAA pour un domaine,
L’utilisation de la technique saut par saut ou terminal au terminal pour la sécurité
entre domaine.
Ces deux hypothèses ne sont pas toujours valables pour deux raisons :
-
1- Chaque domaine utilise ses propres AAA, ce qui rend possible un conflit entre Multi
domaine
2- Le HSS ne soutient pas une interface qui peut être employée par d’autres HSS, par
conséquent les deux techniques saut par saut et terminal au terminal ne peuvent pas
être exploitées.
C’est pour cela que nous proposons l’utilisation du protocole IPsec et ses outils : l’association
de la sécurité entre nœuds IMS, l’authentification de l’entête, l’encapsulation du paquet de
données et la gestion de clés IKE, tout en supposant que la sécurité au niveau d’un domaine
IMS est assurée.
Les différents schémas proposés dans cette thèse sont basés sur des architectures protocolaires
(IP, TRIP, DNS, SIP,…) ce qui rend leurs validations est évidente et ne nécessitent pas
l’utilisation des techniques de vérification et de modélisation des échanges entre entités
communicantes telles que, LOTOS (Language of Temporal Ordering Specification),
ESTELLE (Extended State Transition Language) de l’ISO, et l’SDL (Specification and
Description Language) de l’ITU.
Les perspectives de cette thèse est l’implémentation de ces différents schémas sur des
architectures réelles. Les outils nécessaires et disponibles sont les suivants :
- Plate forme dotNet et Web service
- Parlay X Web services et les API nécessaires
- Browser VoiceXML
- Les protocoles TRIP, ENUM, IPsec,
La seule contrainte est le Gateway ISG. On trouve actuellement chez la majorité des
opérateurs un ISG et un simulateur ISG (ISG Simulator). Ces différents ISG de différents
opérateurs contiennent les fonctions de base nécessaires, mais sont différents de point de vue
nature et nombre d’interface avec les autres réseaux d’accès.
118