THÈSE. Présentée à L UNIVERSITÉ BORDEAUX I ÉCOLE DOCTORALE DE MATHÉMATIQUES ET D INFORMATIQUE POUR OBTENIR LE GRADE DE DOCTEUR

Dimension: px
Commencer à balayer dès la page:

Download "THÈSE. Présentée à L UNIVERSITÉ BORDEAUX I ÉCOLE DOCTORALE DE MATHÉMATIQUES ET D INFORMATIQUE POUR OBTENIR LE GRADE DE DOCTEUR"

Transcription

1 N d ordre: 3905 THÈSE Présentée à L UNIVERSITÉ BORDEAUX I ÉCOLE DOCTORALE DE MATHÉMATIQUES ET D INFORMATIQUE Par Mohamed Aymen Chalouf POUR OBTENIR LE GRADE DE DOCTEUR SPÉCIALITÉ : INFORMATIQUE Offre de service dans les réseaux de nouvelle génération : Négociation sécurisée d un niveau de service de bout en bout couvrant la qualité de service et la sécurité Soutenue le : 3 Décembre 2009 Devant la commission d examen composée de : Anne Wei Professeur, Laboratoire LATTIS Présidente du jury José Neuman De Souza Professeur, Université Fédérale de Ceará Rapporteur Guy Pujolle Professeur, Université Paris 6 Rapporteur Toufik Ahmed Professeur, Université Bordeaux 1 Examinateur Christophe Dousson Ingénieur de Recherche, Orange Labs Examinateur Francine Krief Professeur, Université Bordeaux 1 Directrice de Thèse

2

3 Abstract Based on the IP technology, the next generation networks (NGN) must overcome the main drawbacks of this technology consisting in the lack of quality of service (QoS), security and mobility management. To ensure a service offer in an NGN, a protocol for negotiating a service level can be used. However, most of the existing negotiation protocols allow the establishment of a service level which includes only QoS. As for security and mobility, they were often not covered by these negotiations, and therefore managed independently. However, securing a service can cause degradation of the QoS, and the mobility of a user can change the service needs in terms of QoS and security. Thus, we need to simultaneously manage QoS and security while taking into account user s mobility. In this context, we rely on a QoS signaling protocol, called SLNP, in order to propose a mechanism that allows fixed and mobile users to negotiate a service level covering both QoS and security, in a dynamic, automatic and secure manner. Our contribution is achieved in three steps. Initially, we extend the service level negotiated with SLNP to security in order to enable the negotiation of both security and QoS while taking into account the impact of security on QoS. Then, this negotiation, using web services, is automated by basing it on a user profile. This allows adjusting the service level according to changes which can occur on the user context. Thus, the service offer is more dynamic and can be adapted to changes of access network resulting from the mobility of the user. Finally, we propose to secure the negotiation flows in order to prevent the different attacks that can target the exchanged messages during a negotiation process. Keywords: Next generation networks, service level negotiation, quality of service, security, mobility, web services. iv

4 Résumé Fondés sur la technologie IP, les réseaux de nouvelle génération (NGN) doivent surmonter les principaux défauts inhérents à cette technologie, à savoir l absence de la qualité de service (QoS), la sécurité et la gestion de la mobilité. Afin de garantir une offre de service dans un réseau NGN, un protocole de négociation de niveau de service peut être utilisé. Cependant, la majorité des protocoles de négociation existants permettent l établissement d un niveau de service qui ne couvre que la QoS. Quant à la sécurité et la mobilité, elles ont été souvent exclues de ces négociations, et donc gérées d une manière indépendante. Cependant, la sécurisation d un service peut causer la dégradation de la QoS, et la mobilité de l utilisateur peut modifier ses besoins. D où, l intérêt de gérer simultanément la QoS et la sécurité tout en prenant en considération la mobilité des utilisateurs. Dans ce contexte, nous nous basons sur un protocole permettant la signalisation de la QoS, appelé SLNP, afin de proposer un mécanisme qui permet à des clients fixes et mobiles de négocier, d une manière dynamique, automatique et sécurisée, un niveau de service couvrant à la fois la QoS et la sécurité. Notre contribution est composée de trois parties. Dans un premier temps, nous étendons le niveau de service négocié avec SLNP à la sécurité afin de permettre la négociation conjointe de la sécurité et de la QoS tout en tenant compte de l impact de la sécurité sur la QoS. Par la suite, cette négociation, qui utilise les services web, est automatisée en la basant sur un profil utilisateur qui permet d adapter le niveau de service au contexte de l utilisateur. Ainsi, l offre de service est plus dynamique et peut s adapter aux changements de réseau d accès suite à la mobilité de l utilisateur. Enfin, nous proposons de sécuriser le flux de négociation afin de pallier aux différents types d attaques qui peuvent viser les messages de négociation échangés. Mot clés: Les réseaux de nouvelle génération, la négociation de niveau de service, la qualité de service, la sécurité, la mobilité, les services web. v

5

6 Table des matières Abstract... iv Résumé... v Table des matières... vii Liste des figures... xiii Liste des tableaux... xvi Remerciements...xviii Liste des Publications... xix Chapitre 1 Introduction Contexte et motivations Contributions Organisation de la thèse... 3 Chapitre 2 Les principaux besoins des réseaux NGN Introduction Evolution des réseaux Des réseaux dédiés L Internet La convergence des réseaux Résumé Les réseaux de nouvelle génération Définition et principes fondamentaux Architectures des réseaux NGN Caractéristiques des réseaux NGN Des terminaux de plus en plus sophistiqués Des réseaux d accès supportant des débits de plus en plus élevés Des services de types variés Résumé La qualité de service (QoS : Quality of Service) Définition et mécanismes élémentaires de la QoS La QoS dans les réseaux IP Le service garanti (IntServ : Integrated Services) La différenciation de services (DiffServ : Differentiated Services) MPLS (MultiProtocol Label Switching) La QoS dans les réseaux d accès Mécanismes de QoS dans les réseaux Wi-Fi vii

7 Mécanismes de QoS dans les réseaux WiMax Mécanismes de QoS dans les réseaux Satellite La QoS dans les réseaux NGN Résumé La sécurité Attaques, services et opérations cryptographiques Attaques de sécurité Services de sécurité Notions de cryptographie La sécurité dans les réseaux IP Le protocole IPSec Le protocole TLS Le protocole DTLS La sécurité dans les réseaux d accès La sécurité dans les réseaux mobiles La sécurité dans les réseaux Wi-Fi La sécurité dans les réseaux NGN Résumé La mobilité Mobilité au niveau «Réseau» Fonctionnement de MIP Le protocole MIPv Mobilité au niveau «Transport» Le protocole I-TCP (Indirect TCP) Le protocole M-TCP (Mobile TCP) Le protocole M-UDP (Mobile UDP) Mobilité au niveau «Application» Mobilité au niveau «Liaison de données» Architecture du MIH Les services MIH Résumé Conclusion Chapitre 3 La garantie de l offre de service dans les réseaux NGN Introduction Niveau de service Définition Les paramètres du niveau de service Résumé Négociation de niveau de service Projets de recherche traitant de la négociation Le projet TEQUILA Le projet AQUILA viii

8 Le projet EURESCOM Le projet MESCAL Le projets CADENUS Protocoles de négociation Le protocole RNAP Le protocole COPS-SLS Le protocole PPP IPCP Le protocole SrNP Le protocole DSNP Le protocole QoS-NSLP Le protocole QoS-GSLP Le protocole QoS-SIP Discussion Le protocole SLNP Les services web Architecture des services web Les standards des services web Les plateformes de développement des services web Principales caractéristiques du protocole SLNP Satisfaction des besoins de négociation Utilisation des services web Une signalisation hors-bande Indépendance vis-à-vis des modèles de QoS Transparence et extensibilité du SLS Paramètres de QoS négociés avec SLNP Les paramètres obligatoires Les paramètres optionnels Messages de négociation SLNP Le message Negotiate Le message Revision Le message Modify Le message Notify Le message Release Le message Response Architecture du protocole SLNP Terminologie Modèle de fonctionnement Composition d une entité SLNP Scénario de négociation de QoS avec SLNP Résumé Conclusion Chapitre 4 Négociation conjointe de la sécurité et de la QoS via SLNP ix

9 4.1 Introduction Motivations Travaux associant la QoS et la sécurité Négociation de sécurité IPSec tenant compte de la QoS Négociation de sécurité avec IPSec Intégration de la QoS dans la négociation IPSec Association de la sécurité à la QoS dans la gestion par politique Résumé Intégration de la sécurité dans la négociation SLNP Définition des paramètres de sécurité négociés via SLNP Portée de la sécurité Protocole de sécurité Paramètres de sécurité IPSec Paramètres de sécurité TLS-DTLS Définition d un SLS de QoS et de sécurité Scénarios d utilisation de SLNP pour offrir la QoS et la sécurité Exemple d une négociation intra-domaine Exemples de négociations inter-domaines Nouveau fonctionnement du protocole SLNP Modification de l application cliente de négociation Modification du service web de négociation Tests et évaluations des performances Plateforme de tests Tests du fonctionnement Evaluation du temps de négociation Evaluation de la taille des messages Résumé Etude de l impact de la sécurité sur la QoS Travaux portant sur l impact de la sécurité sur la QoS Impact du protocole IPSec sur la QoS Surcoût des services de sécurité Impact des traitements de sécurité Tests réalisés Plateforme de tests Résultats des tests Résumé Conclusion Chapitre 5 Adaptation du protocole SLNP aux réseaux NGN Introduction Gestion de la QoS et de la sécurité dans une architecture pour les services IPTV Architecture pour la fourniture des services IPTV Les services IPTV x

10 L architecture IPTV Offre de la QoS et de la sécurité Négociation du niveau de service dans le cœur du réseau Consommation du service dans le réseau d accès Résumé Négociation de niveau de service dans les environnements NGN Contexte et motivations Profil utilisateur Profil «CC/PP» pour l adaptation des flux Profil «UED» pour l adaptation des flux Profil pour la négociation de QoS Définition d un profil utilisateur pour la négociation SLNP Préférences de l utilisateur Caractéristiques de l application Caractéristiques du terminal Caractéristiques des réseaux d accès Négociation SLNP basée sur le profil utilisateur Couche de négociation Le point de décision et de mise en correspondance (MNDP) L entité de négociation (SE) Le générateur de SLS (SG) Fonctionnement de la négociation fondée sur le profil Les responsables de domaines Le client initial Tests et évaluations de performances Plateforme de tests Tests du fonctionnement Evaluation du temps de négociation Evaluation de la taille des messages Utilisation du protocole SLNP dans un environnement NGN Résumé Conclusion Chapitre 6 Sécurité de la négociation assurée par le protocole SLNP Introduction Motivations Mécanismes de sécurisation du protocole SLNP Sécurité du protocole SLNP au niveau «Application» (WSS) Implémentation de la spécification WSS Principe de fonctionnement de WSS4J Configuration de la sécurité WSS au niveau des entités SLNP Tests et résultats Plateforme de tests xi

11 Tests de fonctionnement Tests d évaluation des performances en fonction du niveau de sécurité Tests d évaluation des performances en fonction de l algorithme utilisé Résumé Sécurité du protocole SLNP aux niveaux «Transport» (SSL) et «Réseau» (IPSec) Implémentation du protocole SSL/TLS Implémentation du protocole IPSec Tests et résultats Plateforme de tests Tests de fonctionnements Tests d évaluation des performances en fonction du type de sécurité Fonctionnement de la négociation sécurisée Conclusion Chapitre 7 Conclusion et Perspectives Principales contributions Perspectives et nouveaux défis Références Annexes Annexe 1 : Outils utilisés dans la mesure de l impact de la sécurité sur la QoS Annexe 2 : Les standards de sécurisation des services web au niveau applicatif Annexe 3 : Exemple d un message SLNP sécurisé avec WSS Liste des abréviations xii

12 Liste des figures Figure 2-1 : Architecture générique des réseaux NGN... 9 Figure 2-2 : Plan de contrôle d un routeur IntServ Figure 2-3 : Architecture DiffServ Figure 2-4 : Le conditionnement du trafic DiffServ Figure 2-5 : Fonctionnement MPLS Figure 2-6 : Architecture de QoS dans les réseaux NGN Figure 2-7 : Fonctionnement du protocole IPSec Figure 2-8 : Couches protocolaires de TLS Figure 2-9 : Flux de messages échangés lors d une poignée de main TLS Figure 2-10 : Principe du protocole MIP Figure 2-11 : Architecture du standard IEEE [IEE 08] Figure 3-1 : Négociation de SLS avec COPS-SLS [NGU 04] Figure 3-2 : Exemple de négociation avec SrNP [TEQ 03] Figure 3-3 : Exemple de négociation avec DSNP Figure 3-4 : Architecture QoS-SIP Figure 3-5 : Architecture des services web Figure 3-6 : Pile protocolaire des services web [BOO 04] Figure 3-7 : Structure d un message SOAP Figure 3-8 : Structure d un document WSDL [CHR 01] Figure 3-9 : Une négociation de type hors-bande Figure 3-10 : Structure du SLS de QoS Figure 3-11 : Structure de l élément flowid Figure 3-12 : Structure de l élément scope Figure 3-13 : Structure de l élément serviceschedule Figure 3-14 : Structure de l élément performanceguarantee Figure 3-15 : Structure de l'élément trafficconformity Figure 3-16 : Structure de l élément negotiationparameters Figure 3-17 : Structure de l élément reliability Figure 3-18 : Structure des messages Negotiate, Revision, Release, Modify, Notify Figure 3-19 : Structure du message Response Figure 3-20 : Fonctionnement général au niveau d une SE Figure 3-21 : Schéma de la description WSDL du service web de négociation Figure 3-22 : Représentation simplifiée d un message SLNP Figure 3-23 : Exemple de négociation avec SLNP Figure 4-1 : Exemple de négociations indépendantes de QoS et de sécurité Figure 4-2 : Exemple de négociation de paramètres de sécurité avec IPSec Figure 4-3 : Exemple d une négociation de sécurité IPSec en associant la QoS Figure 4-4 : Structure de l élément securityscope xiii

13 Figure 4-5 : Structure de l élément securityprotocol Figure 4-6 : Structure de l élément ipsec Figure 4-7 : Structure de l élément salifetime Figure 4-8 : Structure de l élément noreplay Figure 4-9 : Structure de l élément tls-dtls Figure 4-10 : Structure d un SLS de QoS et de sécurité Figure 4-11 : Structure supposée de l élément salifetime Figure 4-12 : Structure réelle de l élément securityprotocol Figure 4-13 : Scénario 1 - négociation intra-domaine Figure 4-14 : SLS négocié dans le scénario Figure 4-15 : MSC du scénario Figure 4-16 : Scénarios 2 et 3 - négociations inter-domaines Figure 4-17 : SLS négocié dans le scénario Figure 4-18 : MSC du scénario Figure 4-19 : SLS négocié dans le scénario Figure 4-20 : MSC du scénario Figure 4-21 : Algorithme de l établissement d un SLS (QoS) Figure 4-22 : Traitements nécessaires à la création du message Negotiate Figure 4-23 : Algorithme de l établissement d un SLS (QoS + Sécurité) Figure 4-24 : Algorithme de l opération de négociation Figure 4-25 : Traitements nécessaires à la modification du SLS Figure 4-26 : Plateforme de tests du fonctionnement du protocole SLNP Figure 4-27 : Un message Negotiate visualisé à l aide de SOAP Monitor Figure 4-28 : Temps de négociation en fonction du type de négociation (100 essais) Figure 4-29 : Taille moyenne du message Negotiate Figure 4-30 : Comparaison du délai de bout en bout entre IPv4 et IPSec [VAN 05] Figure 4-31 : Plateforme de tests de l'impact de la sécurité sur la QoS Figure 4-32 : Impact de la sécurité sur la QoS pour un trafic UDP Figure 4-33 : Impact de la sécurité sur la QoS pour un trafic TCP Figure 5-1 : Architecture IPTV [DJA 08] Figure 5-2 : Gestion de l offre de service IPTV Figure 5-3 : Structure de l élément securityprotocol adaptée au cas de l IPTV Figure 5-4 : La négociation SLNP au sein d un groupe multicast IPTV Figure 5-5 : Composition des caractéristiques de l utilisateur Figure 5-6 : Composition des caractéristiques du réseau Figure 5-7 : Composition des capacités du terminal Figure 5-8 : Messages RTSP échangés entre l AG et le Client Figure 5-9 : Négociation SLNP dans les réseaux NGN Figure 5-10 : Composition du profil utilisateur pour la négociation Figure 5-11 : Vue d ensemble de la couche de négociation Figure 5-12 : Interactions de la composante MNDP Figure 5-13 : Interactions de la composante SE Figure 5-14 : Interactions de la composante SG xiv

14 Figure 5-15 : Fonctionnement de la négociation dans le NGN Figure 5-16 : Traitements au niveau du client initial Figure 5-17 : Algorithme des traitements de la composante MNDP Figure 5-18 : Plateforme de tests du fonctionnement dans le NGN Figure 5-19 : Interface graphique pour récupérer les préférences de l utilisateur Figure 5-20 : Préférences d un utilisateur privilégiant la sécurité Figure 5-21 : Evaluation du temps de négociation (100 essais) Figure 5-22 : Taille moyenne du message Negotiate Figure 5-23 : Exemple de négociation dans un environnement NGN Figure 6-1 : Les standards de sécurisation des services web Figure 6-2 : Exemple d un fichier de déploiement WSDD Figure 6-3 : Exemple de descripteur de déploiement d une partie cliente Figure 6-4 : Exemple de fichier de propriétés (crypto-encrypt.properties) Figure 6-5 : Exemple de descripteur de déploiement d une partie serveur Figure 6-6 : Modèle de communication pour les tests de fonctionnement Figure 6-7 : Evaluation du temps de négociation (100 essais) Figure 6-8 : Evaluation de la taille des messages Figure 6-9 : Fichier de configuration du serveur Tomcat (server.xml) Figure 6-10 : Extrait du fichier de configuration IPSec (racoon.conf) Figure 6-11 : Plateforme de tests Figure 6-12 : Visualisation des échanges sécurisés avec IPSec (TCPdump) Figure 6-13 : Exemple d association de sécurité IPSec Figure 6-14 : Temps de négociation en fonction du type de sécurité Figure 6-15 : Taille des messages en fonction du type de sécurité Figure 6-16 : Nouvelle structure de la couche de négociation Figure A-1 : Structure d une signature XML Figure A-2 : Exemple de signature XML Figure A-3 : Structure d un chiffrement XML Figure A-4 : Exemeple de chiffrement d une partie d un document XML Figure A-5 : Exemple de chiffrement d une clé de chiffrement XML Figure A-6 : Emplacement de l entête WSS dans un message SOAP Figure A-7 : Exemple de signature d un message SOAP avec WSS Figure A-8 : Exemple de chiffrement d un message SOAP avec WSS xv

15 Liste des tableaux Tableau 3-1 : Modèle graphique du schéma XML Tableau 3-2 : Calcul des valeurs offertes des différents attributs de QoS Tableau 4-1 : Valeurs possibles des éléments de sécurité Tableau 4-2 : Probabilité de succès et nombre moyen de passes de négociation Tableau 4-3 : Temps moyen de négociation en fonction du type de négociation Tableau 4-4 : Qualification de la consommation des ressources Tableau 4-5 : Impact d IPSec sur la bande passante (trafic UDP) [DUF 07] Tableau 4-6 : Performances en termes de traitements cryptographiques [KON 03] Tableau 4-7 : Politiques de sécurité Tableau 5-1 : Protocoles et algorithmes de sécurité utilisés pour un flux IPTV Tableau 5-2 : Paramètres du profil utilisateur pour la négociation Tableau 5-3 : Paramètres de QoS pour une application de type VoIP Tableau 5-4 : Paramètres de QoS pour une application de type VoD Tableau 5-5 : Tableau de mapping pour les services d intégrité et de confidentialité Tableau 5-6 : Temps moyen de négociation Tableau 5-7 : Paramètres du profil utilisateur à la position Tableau 5-8 : Paramètres du SLS correspondant au profil Tableau 6-1 : Les différents scénarios de sécurité WSS Tableau 6-2 : Impact de la sécurité WSS sur les performances du protocole SLNP Tableau 6-3 : Impact sur les performances suivant l algorithme de chiffrement Tableau 6-4 : Impact des différents types de sécurité sur les performances de SLNP Tableau A-1 : Quelques types d erreur définis par WSS xvi

16 À mes grands parents, Hamadi, que dieu te prête longue vie, Khmaies, Habiba et Zohra, que dieu vous accepte dans son paradis éternel. À mes chers parents, Lanouar et Chédia, sans vous, rien n aurait pu être possible, que dieu vous protège et vous prête une longue vie pleine de santé et de prospérité. À mon frère unique, Ilyes, que dieu nous garde unis pour que nos parents soient toujours fiers de nous. À ma chère fiancée, Rahma, merci de m avoir soutenu tout au long de cette aventure, que dieu te protège. À tous les membres de ma famille et à tous mes amis. xvii

17 Remerciements Je voudrais tout d abord exprimer ma profonde gratitude envers ma directrice de thèse, le professeur Francine Krief, qui m a proposé cette thèse et m a accompagné tout au long de ces trois années. Son aide, ses encouragements, sa disponibilité et son soutien sans faille ont été déterminants pour la réalisation de cette thèse. J adresse également mes plus sincères remerciements aux professeurs José Neuman De Souza, Guy Pujolle, Toufik Ahmed, Christophe Dousson et Anne Wei qui m ont fait l honneur d évaluer les travaux de cette thèse et de participer au jury de soutenance. Je tiens à remercier aussi tous les membres de l équipe COMET et tous le personnel administratif du LaBRI. Cette liste n étant pas exhaustive, je remercie tous ceux qui, de près ou de loin, ont contribué à la réalisation de ce travail, par leur aide, leur encouragement ou par leur simple présence. xviii

18 Liste des Publications Journaux et chapitres de livre Mohamed Aymen Chalouf, «Communications Security in embedded systems», in the book «Communicating Embedded Systems for Networks», Edited by: Francine Krief, Wiley-ISTE, April Mohamed Aymen Chalouf, I. Djama, T. Ahmed, F. Krief, An IPTV Architecture with End-to- End Garantees on QoS and Security, to appear in the International Journal of Autonomous and Adaptive Communications Systems (IJAACS). Mohamed Aymen Chalouf and Francine Krief, A Secured Service Level Negotiation In Ubiquitous Environments, in the International Journal of Communication Networks and Information Security, IJCNIS, Vol. 1, No. 2, August Mohamed Aymen Chalouf, «La sécurité des communications dans les systèmes embarqués», Dans le livre «Les systèmes embarqués communicants : mobilité, sécurité, autonomie», Auteur : Francine Krief, Traité IC2, série réseaux et télécoms, Hermès, Septembre Conférences internationales avec actes et comité de lecture Mohamed Aymen Chalouf, F. Krief, Service Level Negotiation in Ubiquitous Environments, The 14 th IEEE Symposium on Computers and Communications, Proc. ISCC 2009, Sousse, Tunisia, July Mohamed Aymen Chalouf, F. Krief, La négociation de niveau de service dans un environnement ubiquitaire, 9ème Conférence Internationale sur les NOuvelles TEchnologies de la REpartition, Actes NOTERE 2009, Montréal, Canada, Juin-Juillet Mohamed Aymen Chalouf, F. Krief, SSLNP: Secure Service Level Negotiation Protocol, The 2 nd IEEE Global Information Infrastructure Symposium, Proc. GIIS 2007, Hammamet, Tunisia, June Mohamed Aymen Chalouf, I. Djama, T. Ahmed, F. Krief, On Tightly Managing End-to-End QoS and Security for IPTV Service Delivery, The 5 th ACM International Wireless Communications and Mobile Computing Conference, Proc. IWCMC 2009, Leipzig, Germany, June Mohamed Aymen Chalouf, X. Delord, F. Krief, Introduction of Security in the Service Level Negotiated with SLNP Protocol, The 2 nd IFIP International Conference on New Technologies, Mobility and Security, Proc. NTMS 2008, Tangier, Morocco, November Mohamed Aymen Chalouf, N. Mbarek, X. Delord, F. Krief, Peer-to-Peer Service Level Negotiation: towards QoS and Security Guarantee, The International Conference on TElecommunications and MUltimedia, Workshop: Adaptive Multimedia and IPTV Streaming over peer-to-peer NETworks (AMIS-NET 2008), Proc. TEMU 2008, Ierapetra, Crete, Greece, July xix

19 N. Mbarek, F. Krief, Mohamed Aymen Chalouf, Enabling Service Level Negotiation in a Self Management Framework, The IEEE International Conference on Signal Processing and Communication, Proc. ICSPC 2007, Dubai UAE, November N. Mbarek, F. Krief, Mohamed Aymen Chalouf, A Negotiation Protocol Using Web Services in a Self-Management Framework, The IEEE Global Information Infrastructure Symposium, Proc. GIIS 2007, Marrakech Morocco, July Conférences nationales avec actes et comité de lecture Mohamed Aymen Chalouf, X. Delord, F. Krief, Définition d un SLS de Sécucrité et de QoS pour la Négociation de Niveau de Service, 8 ème Colloque Francophone de Gestion de REseaux et de Services, Actes GRES 2007, Page(s) : , Hammamet, Tunisie, Novembre Mohamed Aymen Chalouf, N. Mbarek, F. Krief, Utilisation des Services Web dans la Négociation de Niveau de Service, 8 èmes Journées Doctorales en Informatique et Réseau, Actes JDIR 2007, Page(s): , Janvier 2007, Marne-la-Vallée, France. Note : Conférence sponsorisée par IEEE France. xx

20 Chapitre 1 Introduction 1.1 Contexte et motivations Actuellement, les architectures de communication sont basées principalement sur le modèle TCP/IP. Ce modèle est caractérisé par sa structure modulaire mettant en œuvre plusieurs couches distinctes t Jusqu à il y a quelques années, les différents moyens de télécommunications, à savoir le réseau de données Internet, le réseau téléphonique et le réseau de diffusion TV, étaient caractérisés par ce qu on appelle la spécialisation. En effet, chaque réseau permettait l accès à un service particulier à travers une infrastructure particulière, ce qui obligeait les utilisateurs à s abonner aux trois réseaux et à utiliser un terminal spécifique pour accéder aux services offerts par chacun de ces trois réseaux. Depuis quelques années, les acteurs des télécommunications ont pris conscience de la nécessité de faire évoluer les différentes infrastructures de communications vers une seule infrastructure permettant de réaliser une convergence totale des différents réseaux et de tous les services offerts par ces réseaux. Cette nouvelle infrastructure, fondée sur ce qu on appelle l architecture des réseaux de nouvelle génération (NGN : Next Generation Networks), permettra aux fournisseurs de services de réduire les coûts de développement en réutilisant des composants communs aux services. Elle permettra, également, aux fournisseurs réseaux de réduire les coûts d exploitation en offrant plusieurs services avec une seule infrastructure. L architecture des réseaux NGN sera basée sur la technologie IP parce que c est un protocole simple et puissant qui offre une connectivité de bout en bout indépendamment de la nature des réseaux sous-jacents. De plus, c est un protocole qui se caractérise par sa neutralité vis-à-vis des applications puisqu il ne suppose rien des services qu il transporte. Toutefois, la réalisation effective d une architecture NGN passe par la résolution des différents problèmes résultant de l adoption de la technologie IP. En effet, il faut surmonter l un des principaux défauts de l IP, à savoir son incapacité à offrir une qualité de service (QoS : Quality of Service) de bout en bout. Il faut, également, pallier aux différentes failles de sécurité en protégeant les données transmises sur les réseaux NGN ainsi que les systèmes communicants. De plus, il faut résoudre les problèmes qui se rapportent à la mobilité des utilisateurs en permettant de réaliser le handover (horizontal entre plusieurs domaines et vertical entre plusieurs technologies) tout en préservant la continuité de service. Dans un environnement NGN, les fournisseurs de services doivent fournir à leurs clients des garanties en matière de QoS et de sécurité tout en assurant la mobilité de ces clients. Cependant, les besoins d un client sont de plus en plus dynamiques, et peuvent varier en fonction de plusieurs paramètres 1

21 liés à son environnement de connexion. Ainsi, l offre de service de bout en bout est caractérisée par une grande «dynamicité», et peut donc nécessiter une reconfiguration rapide et fréquente, ce qui demande une gestion dynamique pouvant être fondée sur un protocole de signalisation. Dans ce contexte, la notion de niveau de service a été introduite afin de permettre de réaliser un engagement entre un client et son fournisseur de services ou entre deux fournisseurs de services. Pour permettre la négociation de ce niveau de service, plusieurs protocoles de signalisation ont été spécifiés. Toutefois, le niveau de service négocié grâce à ces protocoles ne couvre que l aspect QoS de l offre de service. Ceci est dû aux besoins imminents en matière de QoS qui ne cessent d augmenter avec le développement des nouveaux services tels que les services multimédia et les services temps réel. La sécurité des services offerts par les réseaux NGN a été identifiée, dés l apparition de ces réseaux, comme l un des besoins les plus importants, mais elle a été négligée dans l offre de service. Aujourd hui, avec tous les risques et les attaques qui peuvent menacer le transport des services sur les réseaux NGN, la sécurité doit être prise en considération dans l offre de service de bout en bout. Par ailleurs, l architecture des réseaux NGN est caractérisée par la multitude et la diversité des réseaux d accès qui peuvent coexister dans un même lieu, et par des utilisateurs de plus en plus mobiles pouvant se connecter grâce à différents types de terminaux. Ainsi, dans cet environnement très dynamique, l offre de service, qui peut être garantie avec un protocole de négociation, doit s adapter au contexte de l utilisateur (terminal utilisé, réseau d accès, préférences de l utilisateur, etc.) en assurant une négociation automatique et plus dynamique. Ces différents constats peuvent être résumés dans l importance de la négociation de niveau de service dans les réseaux NGN, ainsi que le besoin grandissant de garantir simultanément la qualité de service et la sécurité pour des utilisateurs de plus en plus mobiles. Partant de ces constats, nos travaux portent sur la définition d une architecture qui permet à des clients fixes ou mobiles de négocier, d une manière dynamique, automatique, fiable et optimisée, un niveau de service couvrant à la fois leurs besoins en termes de QoS et de sécurité, tout en assurant la gestion de leur éventuelle mobilité. 1.2 Contributions Dans le cadre de cette thèse, nous nous sommes intéressés, dans un premier temps, à l offre de service garantissant à la fois la QoS et la sécurité. Pour cela, nous avons considéré un protocole de négociation de niveau de service de bout en bout couvrant la QoS, afin d introduire des aspects de sécurité dans le niveau de service qu il permet de négocier. Notre choix s est porté sur le protocole SLNP (Service Level Negotiation Protocol), parce que c est un protocole qui utilise les services web afin de fournir l interopérabilité aux différents acteurs d une négociation (client, fournisseur de services et fournisseurs réseaux). L introduction des paramètres de sécurité dans le niveau de service négocié en utilisant SLNP a demandé des changements dans le fonctionnement du processus de négociation. Ces changements sont, essentiellement, dus à la nécessité de prendre en compte l impact des mécanismes de sécurité sur les paramètres de la QoS. Ainsi, il nous a fallu réaliser des tests permettant d estimer cet impact, dans le but de pouvoir le considérer lors d une négociation conjointe de la sécurité et de la QoS. La négociation permise par le protocole SLNP ne facilite pas la participation des clients à la négociation du niveau de service dont ils ont besoin. En effet, un client doit avoir une certaine expertise pour pouvoir négocier le niveau de service par lui-même. De plus, les changements fréquents des besoins des clients ainsi que leur mobilité, nécessitent des interventions de plus en plus fréquentes de ces clients. 2

22 Ce qui représente un handicap, non seulement, à la participation des clients à la négociation, mais aussi à l adaptation rapide de l offre de service aux changements des besoins et à la mobilité de ces clients. Afin de surmonter tous ces problèmes, nous proposons, dans un second temps, de définir un nouveau fonctionnement du processus de négociation afin d adapter le protocole SLNP aux environnements très dynamiques caractérisant les réseaux NGN. Ainsi, nous proposons de fonder la négociation sur un profil utilisateur afin de permettre aux clients de négocier le niveau de service nécessaire d une manière simple, automatique et optimisée. Nous spécifions, également, comment le protocole SLNP peut coopérer avec le standard MIH (Media Independant Handover) afin d assurer la mobilité des utilisateurs et de pouvoir considérer l impact de cette mobilité sur le niveau de service. Par ailleurs, nous avons considéré une architecture d un service NGN particulier, à savoir l architecture IPTV. Cette architecture est divisée en deux segments (réseau de cœur et réseau d accès) afin de pouvoir délivrer le flux IPTV aux différents utilisateurs mobiles connectés grâce à un réseau d accès sans fil. Afin de garantir la sécurité et la QoS de bout en bout pour les différents clients de cette architecture, nous proposons de gérer ces deux aspects différemment sur chacun de deux segments composant l architecture IPTV. Etant donné que le transport de l IPTV au niveau du réseau de cœur s effectue en mode multicast, nous proposons d adapter le protocole SLNP afin de pouvoir garantir un niveau de service pour un groupe multicast. Au niveau du réseau d accès les flux IPTV sont adaptés aux terminaux des clients, et donc transmis en unicast. Cette adaptation est fondée sur un outil du standard MPEG-21, appelé UED (User Environment Description). L UED, tel qu il a été défini par la norme MPEG-21, ne permet de décrire que les paramètres du profil qui sont reliés à la QoS. Ainsi, nous proposons d étendre la description UED aux différents paramètres reliés à la sécurité, afin de permettre de réaliser des adaptations tout en garantissant la QoS et la sécurité. En utilisant les services web, la négociation du protocole SLNP est fondée sur l échange de messages SOAP (Simple Object Access Protocol). Cependant, dans le cadre d une négociation inter-domaines, plusieurs acteurs sont impliqués dans une négociation de niveau de service, et les messages SOAP échangés entre ces acteurs peuvent être attaqués par un tiers malveillant. A titre d exemple, ces attaques peuvent viser à désactiver le niveau de sécurité requis par le client afin de pouvoir espionner sa communication. Elles peuvent, également, viser à modifier ou résilier le niveau de service négocié par un client, dans le but de libérer des ressources. Pour pallier à ce genre d attaque, nous proposons, dans un dernier temps, d étudier la sécurité du flux de la négociation SLNP. Ce qui permet aux différents acteurs d une négociation de niveau de service de se mettre d accord sur l offre de ce service d une manière fiable et sécurisée. 1.3 Organisation de la thèse Afin de détailler d avantage les concepts, les problématiques et les solutions introduits ci-dessus, cette thèse est organisée comme suit : Chapitre 2 «Les principaux besoins des réseaux NGN» : Dans ce premier chapitre, nous rappelons le contexte de l évolution des architectures de télécommunications traditionnelles vers les réseaux de nouvelle génération. Ensuite, nous décrivons les principales caractéristiques de l architecture des réseaux NGN, afin d identifier les principaux besoins de ces réseaux, à savoir la 3

23 gestion de la QoS, de la sécurité et de la mobilité. Puis, nous présentons un état de l art sur les mécanismes définis durant ces dernières années afin d assurer la QoS, la sécurité et la mobilité. Ceci nous permet d identifier les différents défis à relever pour permettre une gestion optimale de ces différents aspects (QoS, sécurité et mobilité) dans les environnements NGN. Chapitre 3 «La garantie de l offre de service dans les réseaux NGN» : Dans ce chapitre, nous commençons par rappeler la définition de la notion de niveau de service avant de détailler les principaux paramètres qui peuvent le caractériser. Ensuite, nous présentons quelques projets qui se rapportent à la négociation de niveau de service, ainsi qu un ensemble de protocoles de négociation. Puis, nous nous intéressons au protocole SLNP qui assure la négociation d une QoS de bout en bout en utilisant les services web permettant de fournir une interopérabilité entre les différents acteurs d une négociation. Nous décrivons ainsi les paramètres de QoS inclus dans le niveau de service négocié, avant de détailler l architecture de ce protocole ainsi que son modèle de fonctionnement. Chapitre 4 «Négociation conjointe de la sécurité et de la QoS via SLNP» : Dans ce chapitre, nous décrivons notre première contribution qui consiste à associer la sécurité à la QoS dans la négociation assurée par le protocole SLNP. Pour cela, nous commençons par souligner la nécessité de cette association, avant de présenter quelques travaux qui ont tenté de considérer la QoS lors de la négociation de la sécurité ou vice versa. Ensuite, nous définissons les paramètres de sécurité pouvant être négociés avec SLNP qui seront, par la suite, introduit dans le niveau de service négocié. Puis, nous définissons le nouveau fonctionnement de cette négociation qui permet de tenir compte de l impact de la sécurité sur la QoS, lorsque cette sécurité est associée à la QoS dans le niveau de service négocié. Par la suite, les détails du nouveau fonctionnement du protocole SLNP seront donnés et les résultats des tests de performances de ce nouveau fonctionnement seront présentés. La prise en compte de l impact de la sécurité sur la QoS lors d une négociation SLNP nécessite que les acteurs de la négociation disposent d une estimation de cet impact. Ainsi, une étude est réalisée. Nous présentons les travaux qui ont permis de souligner l importance de l impact de la sécurité sur la QoS, et d identifier les facteurs liés à cet impact. Puis, nous détaillons nos propres travaux qui ont permis de trouver de réelles estimations de cet impact. Chapitre 5 «Adaptation du protocole SLNP aux réseaux NGN» : Ce chapitre est divisé en deux grandes parties. Dans la première partie, nous utilisons le protocole SLNP afin de garantir une offre de service (QoS et sécurité) pour un service NGN bien particulier, à savoir l IPTV. Nous commençons par présenter l architecture IPTV. Ensuite, nous définissons le modèle de fonctionnement d une négociation SLNP au sein d un groupe multicast, ceci permet de garantir la QoS et la sécurité pour les flux IPTV au niveau du réseau de cœur. Puis, nous décrivons les différents paramètres reliés à la sécurité que nous avons introduits dans l UED, afin de permettre de garantir la sécurité des flux IPTV adaptés aux différents clients mobiles. Dans la deuxième partie de ce chapitre nous décrivons notre contribution qui consiste à adapter le protocole SLNP aux environnements NGN. Nous commençons par rappeler les différents défis à relever. Ensuite, nous introduisons quelques travaux portant sur les profils utilisateurs qui nous ont aidés dans la définition du profil utilisateur sur lequel se fondera la négociation SLNP. Le nouveau fonctionnement de la négociation SLNP est ensuite défini. Nous détaillons le processus qui permet de déterminer le niveau de service requis par le client à partir des paramètres du profil. Nous décrivons, également, l utilisation du 4

24 standard MIH afin d assurer la mobilité des clients et de pouvoir considérer l impact de cette mobilité dans le niveau de service négocié. Puis, nous présentons la nouvelle composition que doivent avoir les acteurs de négociation, ainsi que le fonctionnement de la négociation adapté à l ubiquité des environnements NGN. Nous présentons, par la suite, les nouveaux tests de performances effectués, avant de donner un exemple de négociation montrant l utilité de l utilisation du profil utilisateur et de la coopération avec le protocole MIH dans la négociation. Chapitre 6 «Sécurité de la négociation assurée par le protocole SLNP» : Dans ce chapitre, nous décrivons notre dernière contribution, à savoir l étude et la mise en œuvre de la sécurisation de la négociation assurée par le protocole SLNP. Nous commençons, tout d abord, par présenter les types d attaques spécifiques aux protocoles de signalisation qui ont motivé notre démarche de sécurisation du protocole SLNP. Puis, nous identifions les protocoles de sécurité qui permettent de faire face aux attaques de sécurité pouvant viser une négociation SLNP. Après cela, nous décrivons les différentes étapes qui nous ont permis d implémenter les protocoles de sécurité que nous avons sélectionnés pour sécuriser SLNP. Enfin, les différents types de sécurité mis en place sont testés afin de pouvoir évaluer leurs impacts respectifs sur les performances du processus de négociation et choisir la solution la mieux adaptée. Enfin, nous décrivons les modifications apportées au protocole SLNP dans le but d optimiser de la configuration de la sécurité de ce protocole. Chapitre 7 «Conclusion et Perspectives» : Nous présentons dans ce chapitre une conclusion générale pour les travaux décrits dans ce mémoire et nous proposons quelques perspectives pour de futurs travaux de recherche s inscrivant dans la continuité de cette thèse. 5

25 Chapitre 2 Les principaux besoins des réseaux NGN 2.1 Introduction Actuellement, l ensemble des architectures de communication est en train d évoluer vers une infrastructure globale fondée sur IP : les réseaux de nouvelle génération (NGN : Next Generation Networks). Le modèle IP est caractérisé par une structure modulaire composée de plusieurs couches distinctes qui communiquent à travers des interfaces bien définies. L évolution vers les réseaux NGN s explique par la capacité du modèle IP d offrir un mode d acheminement des données indépendant, d une part, du type de technologies réseaux sous-jacentes (Ethernet, Fibre optique, Wi-Fi, WiMax, Satellite, 3G/2G, etc.) et, d autre part, du type de données véhiculées (audio, vidéo, données). L objectif est ainsi de réaliser, à travers les réseaux NGN, le support de multiples services (téléphonie, télévision, services Internet) au sein d une unique infrastructure tirant parti de l hétérogénéité des technologies d accès. Cette architecture a donc pour objectif de permettre à des utilisateurs utilisant différents terminaux d accéder à plusieurs types de services via des réseaux d accès variés. Dans ce contexte, l un des défis majeurs est de gérer les besoins des différents utilisateurs en termes de qualité de service (QoS : Quality of Service), de sécurité des services fournis, mais aussi de mobilité des utilisateurs. Dans ce chapitre, nous rappelons le contexte de l évolution des architectures de télécommunications traditionnelles vers les réseaux de nouvelle génération, avant d évoquer les principales caractéristiques de ces nouveaux réseaux. La deuxième partie de ce chapitre est consacrée à la présentation des notions de QoS, de sécurité et de mobilité qu on se doit de gérer dans un tel contexte, tout en détaillant les différents mécanismes qui permettent de fournir des garanties en matière de QoS, de sécurité et de mobilité. 2.2 Evolution des réseaux Des réseaux dédiés Jusqu au milieu des années 80, les services de télécommunications traditionnels possèdent chacun leur réseau dédié optimisé pour le transport d un type d information pour lequel il a été conçu, et 6

26 l interconnexion entre ces réseaux a été très limitée ou inexistante. Ainsi, le monde des réseaux était constitué de trois sous-réseaux distincts et indépendants, à savoir les réseaux de diffusion, les réseaux de télécommunications et les réseaux de données. En effet, la voix est transportée sur les réseaux téléphoniques commutés (RTC) qui répondent alors parfaitement aux impératifs de QoS, de fiabilité et d interactivité en se basant sur un plan de contrôle rigide. La télévision est diffusée par satellite ou par voie hertzienne qui apparaît comme le mode de transmission le plus adapté vue leur nature diffusive intrinsèque caractérisée par une communication unidirectionnelle qui permet la scalabilité en supportant un grand nombre d utilisateurs. Enfin, les réseaux de données, basés sur X.25, représentent un intermédiaire entre la fiabilité du réseau de télécommunications et la mise à l échelle du réseau de diffusion tout en permettant une certaine interactivité. Cette vision des réseaux de communication se révèle progressivement étroite puisqu elle entraîne des situations de «monopole naturel» caractérisées par la mise en œuvre systématique de solutions propriétaires et d infrastructures qu il est difficile de faire évoluer ou d interconnecter. Par conséquent, l infrastructure dédiée au transfert de données va proposer une nouvelle vision des architectures de communication ; il s agit de l architecture Internet qui se fonde sur le modèle TCP/IP L Internet Au cours des années 90, l explosion du volume du trafic véhiculé sur Internet et l accroissement de son hétérogénéité en termes de services (données, voix, vidéo), ont favorisé l adoption de l architecture d Internet. Basé sur le modèle TCP/IP et la commutation de paquets, le développement de protocoles et de services sur Internet est largement simplifié puisque ce modèle est ouvert, indépendant d une architecture particulière et propose une hiérarchie protocolaire qui permet à chaque couche de s abstraire des difficultés soulevées et résolues par la couche inférieure. En effet, le protocole IP, offre une connectivité en mode paquet indépendante du réseau sous-jacent permettant d interconnecter tout type de réseau. Avec les protocoles de niveau «Transport» (UDP et TCP), les applications disposent alors d une interface standard pour transmettre sur un réseau IP. Graduellement, des protocoles de niveau applicatif (FTP, SMTP, HTTP) ont été standardisés ; ce qui a permis le développement des services «classiques» d Internet (mail, Web, FTP). Finalement, l augmentation en puissance des terminaux utilisateurs, conjointement avec l accroissement des débits et portées des réseaux d accès, a permis d envisager non seulement la réplication, sur Internet, des services RTC ou télévisuels mais aussi le développement de nouveaux services large bande multimédia La convergence des réseaux Durant ces dernières années, les trois réseaux ont connu des évolutions conséquentes. Le réseau de télécommunications est devenu numérique, sans fil et mobile grâce à l émergence des réseaux mobiles de 2 ème et 3 ème générations qui ont augmenté le débit de transmission, et par la même, le nombre de services. Le même constat peut être fait pour le réseau de diffusion qui migre actuellement vers la télévision et la radio numérique. Ainsi, les frontières entre les trois réseaux tendent à disparaître et les services se généralisent sur tous les réseaux. Par exemple, l Internet et la TV sont disponibles sur les réseaux de télécommunications, les communications téléphoniques peuvent être effectuées sur Internet, etc. 7

27 Cette nouvelle mouvance a fait émerger la notion de convergence des réseaux qui a pour objectif de définir un cadre global pour le regroupement des trois types de réseaux sous une seule architecture Résumé Actuellement, il n existe ni une définition précise de la convergence des réseaux, ni une architecture définitive pour réaliser cette convergence. Cependant, il y a un consensus qui se précise sur la technologie IP pour permettre une interconnexion et une interopérabilité entre les réseaux traditionnels. Ce consensus se concrétise par deux points principaux. Le premier est le concept du Tout-IP, ou ALL-IP, qui englobe le développement de nouveaux services basés sur le protocole IP et la migration des services traditionnels sur les réseaux IP (VoIP, IPTV, etc.). Le deuxième point est la définition des réseaux de nouvelle génération (NGN) qui exploitent le protocole IP dans leur couche «Transport». Les nouveaux défis techniques des réseaux de nouvelle génération sont alors la convergence des services (voix, vidéo et données), la convergence des réseaux autour du mode paquet, l offre de service sans couture d un réseau à un autre (handovers horizontal et vertical), l ubiquité, le support de terminaux multimédias, le déploiement de services disponibles de bout en bout accessibles depuis n importe quel réseau d accès, etc. 2.3 Les réseaux de nouvelle génération Définition et principes fondamentaux Les réseaux NGN représentent la prochaine génération de réseaux censée réaliser la convergence totale des services en une seule architecture. Cependant, il n existe pas encore une définition unique de la notion de NGN. L ITU-T a publié deux recommandations concernant les réseaux NGN. La première recommandation, Y.2001 [ITU 04a], définit les principales caractéristiques d un réseau NGN, tandis que la deuxième, Y.2011 [ITU 04b], propose une architecture fonctionnelle. Le comité technique TISPAN de l ETSI (European Telecommunications Standards Institute) a aussi défini une architecture fonctionnelle pour les réseaux NGN largement inspirée de celle proposée par l ITU-T. Les définitions des organismes de normalisation tels que l ETSI et l ITU-T restent assez vagues et dressent une liste générale des principales caractéristiques des réseaux NGN qui se veulent multi-réseaux, multiservices, multi-protocoles et multi-terminaux. Ces caractéristiques communes sont : la convergence ou intégration des réseaux, le «tout IP», le découplage des fonctions applicatives du réseau de transport sous-jacent, la distribution de l intelligence dans le réseau, l ubiquité Architectures des réseaux NGN Afin de répondre aux différentes exigences citées précédemment et d intégrer ainsi les infrastructures de télécommunication existantes avec celles à venir au sein d une seule et unique infrastructure commune, flexible et évolutive, des impératifs ont été clairement identifiés par les organismes œuvrant pour les réseaux NGN (3GPP, ITU-T, ETSI, ATIS, etc.) : Un cœur de réseau unique et mutualisé pour tous les types de réseaux d accès et de services, 8

28 Une architecture de cœur de réseau en 2 couches : «Transport» / «Services», Une évolution du transfert des données vers le mode paquet, Des interfaces ouvertes et standardisées entre chaque couche afin de réaliser l indépendance des services vis-à-vis du réseau, Un découplage entre la fourniture de service et la fourniture de réseau. Le support de technologies d accès multiples, Le support de la convergence des réseaux voix/données et fixe/mobile, Le support de terminaux multiples (modulaires, multi-mode, multimédia et adaptatifs). Ainsi, la principale caractéristique d un réseau de nouvelle génération est son fondement sur IP qui offre un mode de transfert homogène de bout en bout indépendant, d une part, des réseaux sous-jacents et, d autre part, du type de données applicatives véhiculées. Après l évolution du cœur de réseau vers le «tout-ip», la notion la plus importante reste la décomposition en plans fonctionnels séparés par des interfaces ouvertes qui assure à la fois le passage à l échelle et la flexibilité d une telle architecture en offrant une facilité d interconnexion et d intégration de nouveaux services. La Figure 2-1 offre une représentation communément admise de l architecture des réseaux NGN. Figure 2-1 : Architecture générique des réseaux NGN Le plan de «Transport» regroupe l ensemble des ressources mises en place pour assurer le transfert de données. Ainsi, il gère l acheminement du trafic vers sa destination en fournissant une connectivité IP aux différents composants d un réseau NGN tout en garantissant une QoS de bout en bout. Ce plan dépend directement de la technologie du réseau de transport utilisé pour acheminer les paquets. 9

29 Le plan de «Service» fournit les fonctionnalités de base pour l exécution des services avec ou sans session. En effet, il regroupe les plateformes d exécution de service et de diffusion de contenu tout en masquant la diversité technologique aux clients et aux fournisseurs de services. Après ces plans horizontaux, on peut différencier les réseaux d accès des réseaux de transit. En effet, les premiers ont pour but de concentrer le trafic des différents utilisateurs vers des équipements centraux. Alors que, les deuxièmes ont pour vocation d acheminer des volumes de trafic importants entre quelques entités limitées. Dans la Figure 2-1, nous pouvons noter la diversité des technologies permettant à l utilisateur d accéder aux services ; ce qui peut former ce qu on appelle parfois le plan d accès. Il est important de noter que l interaction entre les réseaux de nouvelle génération est les réseaux traditionnels est prise en charge par différentes passerelles d interconnexion afin d assurer une compatibilité avec les technologies déployées actuellement Caractéristiques des réseaux NGN Un réseau NGN doit pouvoir supporter n importe quel réseau d accès, filaire ou sans fil, et n importe quel équipement terminal, fixe ou mobile. Par ailleurs, dans un tel environnement, la définition d un service est indépendante des technologies des réseaux sous-jacents ainsi que des différents terminaux utilisés afin d accéder à ces services Des terminaux de plus en plus sophistiqués Un terminal peut être défini comme est un équipement situé en extrémité d un réseau de télécommunication, permettant à un utilisateur de communiquer sur ce réseau en assurant l interface avec cet utilisateur. Aujourd hui, les terminaux sont de plus en plus nombreux et sophistiqués tels que les téléphones (fixe, GSM, Wi-Fi, etc.) les PDA, les ordinateurs (fixe et portable) ; et supportent des applications de types très variés comme le texte, la parole, l image et la vidéo. En s équipant de divers types d interfaces de connexion (Ethernet, Wi-Fi, WiMax, Bluetooth, etc.), ces terminaux permettent d utiliser différents types de réseaux d accès pour qu un utilisateur puisse se connecter aux réseaux NGN Des réseaux d accès supportant des débits de plus en plus élevés Les réseaux d accès multiplient les technologies d accès (fixe, mobile, sans fil, etc.), évoluant constamment pour supporter de plus hauts débits (technologies ADSL, b, a, g) indispensables au support de services large bande et offrant des services adaptés à IP. En effet, le RTC, initialement conçu pour le service de téléphonie (voix), a permis une ouverture à des services haut débit de type voix et données grâce aux technologies xdsl (ADSL, HDSL, VDSL, etc.). Les réseaux ADSL ou câblés ont constitué, par ailleurs, un des premiers exemples opérationnels de la convergence des services Voix/Vidéo/Donnée. D un autre coté, les réseaux d accès sans fil ont connu des évolutions importantes leur permettant d offrir des débits de plus en plus élevés tout en gérant la mobilité des utilisateurs. Par ailleurs, les réseaux mobiles 2G (GSM) et 2.5G (GPRS) ont largement contribué à habituer l utilisateur à un usage mobile du service voix. La migration vers les technologies 3G (UMTS : Universal Mobile Telecommunication System), qui fournit des débits plus élevés en utilisant de nouvelles bandes de fréquence, a impliqué l implémentation d un cœur de réseau unifié pour les services voix et données. Ainsi, cette technologie (UMTS) représente le premier système global entièrement normalisé avec une architecture de réseau et de services NGN. Par ailleurs, il existe d autres technologies d accès telles que le 10

30 WiMax (Worldwide Interoperability for Microwave Access) et le LTE (Long Term Evolution) qui émergent Des services de types variés L évolution vers les réseaux NGN, fondés sur des technologies de transmission haut débit avec des garanties en matière de QoS, a permis de supporter des types variés de services tels que la voix, la vidéo et les données. La variété des services envisageables dans les réseaux de nouvelle génération est due aux multiples possibilités qu ils offrent en termes de média, de mode de communication, de mobilité, de réseaux d accès et de terminaux. Ces services incluent les services IP traditionnels comme le mail et le web, mais aussi des services émergents comme : la voix sur IP (VoIP : Voice over IP), la diffusion de la télé sur IP (IPTV), et les applications fondées sur la présence tels que la messagerie instantanée (Instant Messaging) et les services de localisation (Location-Based Services) Résumé L apparition des réseaux de nouvelle génération a été principalement motivée par l évolution des réseaux d accès et des équipements terminaux, mais surtout par le besoin des clients de pouvoir accéder aux plateformes des différents services quel que soit le type de terminal et la technologie du réseau d accès. L architecture NGN décrite ci-dessus est loin d être achevée. Héritée en grande partie d Internet, cette architecture va se heurter aux mêmes problèmes, notamment ceux de la QoS et de la sécurité. En effet, les services supportés par les réseaux NGN ne pourront se déployer sans fournir aux clients des garanties en matière de QoS et de sécurité. Pour ce faire, les fournisseurs de services doivent pouvoir disposer d outils permettant de gérer ces services (facturation, authentification, profil des utilisateurs, garantie de la qualité de service et de sécurité de bout en bout, etc.). Avant d introduire les mécanismes proposés dans le but de permettre aux fournisseurs de services d offrir des garanties en matière de QoS et de sécurité à leurs clients, nous allons, dans ce qui suit, décrire les différents mécanismes qui permettent de gérer la QoS et la sécurité des communications ainsi que la mobilité des utilisateurs. 2.4 La qualité de service (QoS : Quality of Service) Dans une architecture NGN, le transport des services de nouveaux types (multimédia, conversationnels, temps réel, etc.) est basé sur le protocole IP (Internet Protocol). Cependant, IP souffre d un inconvénient qui réside dans le routage de toutes les données d une manière équivalente. En effet, le protocole IP fournit un acheminement au mieux (Best-Effort) qui n offre aucun contrôle, ni garantie, sur les conditions de transport de bout en bout des paquets IP. Grâce à sa simplicité, ce service a rencontré un grand succès dans le passé pour le transport des données asynchrones. Cependant, ce succès est de plus en plus contesté, actuellement, par la multiplication des flux synchrones, ou temps réel, qui exigent une certaine QoS pour leur transport. Etant donné que ces nouveaux services, essentiellement les services multimédia et les services temps réel, répondent à des exigences très strictes en termes de délai de 11

31 transport et de bande passante, il devient primordial de gérer l offre de QoS dans les réseaux fondés sur IP tels que les réseaux NGN. La qualité de service (QoS) est un concept incontournable dans le monde des télécommunications, qui a pour but de donner la possibilité à un utilisateur de disposer d une qualité de transmission supérieure à celle d un utilisateur quelconque. Bien que complexe, le concept de la QoS n a rien de révolutionnaire puisqu il se fonde sur des technologies préexistantes qu il vise à rationaliser et souvent à simplifier afin d en faciliter la mise en œuvre. Le nouveau cadre de travail introduit par les réseaux NGN est caractérisé par une segmentation des tâches entre différents opérateurs et fournisseurs (services et réseaux) à travers différentes couches verticales (terminal utilisateur, réseau d accès et réseau de transit) et horizontales («Transport» / «Service»). Cette segmentation permet d envisager des solutions de QoS de bout en bout résultant de l agrégation des solutions déjà proposées par la communauté scientifique pour l Internet. C est pourquoi, avant de décrire une vision de l offre de QoS dans la cadre de l architecture NGN, nous allons dans un premier temps rappeler les principales architectures de QoS développées par l IETF Définition et mécanismes élémentaires de la QoS La définition de la qualité de service, notée QoS en abrégé, n est pas unique et chaque communauté a sa propre définition pour ce terme. Dans la norme ITU-T (International Telecommunications Union - Telecommunication), la qualité de service est perçue comme un ensemble de critères de qualité requis pour le fonctionnement d un ou plusieurs objets. Dans la terminologie ATM (Asynchronous Transfer Mode), la QoS est définie à travers un ensemble de paramètres de performances et de qualité caractérisant une connexion virtuelle. Enfin, l IETF fait référence à la qualité de service pour désigner les paramètres caractérisant les exigences et les contraintes des applications et celles de l ensemble du réseau. La mise en œuvre d une solution globale de QoS nécessite l introduction de mécanismes élémentaires que nous introduisons brièvement dans ce qui suit. En se référant à la recommandation Y.1291 [ITU 04c] définie par l ITU-T, ces blocs élémentaires peuvent être regroupés en différents plans (Données/Contrôle/Administration). Le plan de données comprend tous les mécanismes au niveau élément de réseau interagissant avec les données. Ces différentes fonctionnalités sont : la classification, le conditionnement, le marquage, l ordonnancement, la gestion de files d attente et le contrôle de congestion. Le plan de contrôle comprend l ensemble des mécanismes qui vont permettre de configurer les ressources le long du parcours des données. Ces différentes fonctionnalités sont : le routage basé sur des informations de QoS, le contrôle d admission basé sur l état des ressources disponibles, le contrôle d admission basé sur une politique de contrôle et la signalisation de QoS qui regroupe la découverte, la négociation, la réservation et l allocation de ressources. Enfin le plan de gestion contient l ensemble des mécanismes concernant les aspects de gestion et d administration du trafic. Ceci comprend la métrologie qui permet le contrôle et la supervision de la QoS dans le réseau, la gestion de contrat, la mise en correspondance des paramètres de QoS d un service en paramètres réseau et la politique de QoS. 12

32 2.4.2 La QoS dans les réseaux IP Les paramètres qui caractérisent les performances d un réseau IP sont multiples. Parmi ces paramètres, nous trouvons un ensemble de paramètres qui permet d évaluer la QoS de bout en bout. Le groupe «IP Performance Metrics» de l IETF et le groupe d étude 13 de l ITU-T (recommandation Y.1541) ont défini des métriques de qualité de service ainsi que des méthodes pour mesurer ces métriques. Les principales métriques caractérisant la qualité de service d un service IP sont : Le délai de transmission (la latence) : Il représente le temps nécessaire pour qu un paquet traverse le réseau de bout en bout, de l émetteur jusqu au récepteur. La gigue (Variation du délai) : Il s agit de la variation des délais d acheminement de bout en bout entre deux paquets consécutifs. La bande passante : Elle représente le débit de bout en bout disponible sur le réseau. Le taux de perte : Il correspond au rapport du nombre de paquets perdus sur le nombre de paquets émis durant la transmission. Afin de pouvoir évaluer la QoS perçue par l utilisateur à travers une application de voix ou de vidéo, des paramètres complémentaires ont été définis. Ces paramètres prennent en compte le caractère subjectif de la perception de l utilisateur. Ainsi la qualité de service d une communication vocale ou d un streaming vidéo peut être mesurée grâce à ce qu on appelle le MOS (Mean Opinion Score). La valeur de ce critère de mesure varie entre 1 (inacceptable) et 5 (excellent) et elle est obtenue à partir d un ensemble de tests subjectifs [ITU 96]. Parmi les architectures qui permettent de prendre en compte la qualité de service dans les réseaux IP, nous décrivons, dans ce qui suit, trois architectures. La première architecture (IntServ) a pour objectif de fournir une architecture de QoS homogène de bout en bout. Ceci implique que l ensemble des routeurs d Internet supporte les mêmes mécanismes de QoS qui sont configurés à l aide d une signalisation de QoS unique, explicite et hors-bande. La deuxième architecture (DiffServ) voit Internet comme une concaténation de domaines administrativement et technologiquement différents. Pour surmonter cette hétérogénéité de QoS, une signalisation à 2 étages va être introduite afin d offrir une interface homogène de négociation de QoS de bout en bout (signalisation inter-domaines) tout en permettant à chaque domaine de gérer sa QoS de manière souveraine au sein de son réseau (signalisation intra-domaine). Enfin la dernière architecture (MPLS) repose également sur une architecture de QoS hétérogène mais s appuie sur un ensemble de mécanismes et de protocoles afin d améliorer le fonctionnement d un réseau en exploitant plus efficacement les ressources disponibles Le service garanti (IntServ : Integrated Services) Le modèle IntServ [BRA 94] a marqué historiquement la volonté de l IETF de définir une architecture capable de prendre en charge la QoS temps réel et le contrôle du partage de la bande passante sur les liens du réseau. C est une architecture de QoS qui permet la réservation de ressources dans le réseau pour un flux spécifique. Un flux IntServ correspond à une séquence de messages possédant les mêmes adresses IP source(s) et destination(s) et les mêmes besoins de QoS. Pour décrire les besoins d un flux en termes de QoS, 13

33 IntServ se base sur la description du trafic TSpec [SHE 97a] qui représente une structure de données utilisée pour demander des services au réseau. Cette structure de données inclut plusieurs informations : p (débit crête, octets/seconde), b (taille maximale du burst, octets), r (débit moyen, octets/seconde), m (unité minimum contrôlée, octets), M (taille maximum d un paquet, octets). Le modèle Int Serv définit deux types principaux de services, en plus du service Best-Effort : Le service de charge contrôlée (CLS: Controlled Load Service) [WRO 97]: Ce service fournit approximativement la même QoS pour un flux indépendamment de l état du réseau : état normal ou état de surcharge. La différence entre ce service et le service Best-Effort est décelable uniquement quand le réseau est surchargé. Le service garanti (GS : Guaranteed Service) [SHE 97b]: Ce service assure une bande passante stricte, un délai de transmission de bout en bout borné et une perte de paquet nulle pour un flux. Pour son déploiement, IntServ a défini trois types d éléments réseaux (NE, Network Element) : le NE QoS-capable qui implémente un ou plusieurs services IntServ, le NE QoS-aware qui offre un service QoS équivalent à celui offert par IntServ et enfin le NE Non-QoS qui n offre aucun service QoS. Afin d assurer une QoS spécifique à chaque flux, les NEs QoS-capable (routeurs IntServ) mettent en œuvre un certain nombre de fonctions pour la gestion des paquets, par exemple, un ordonnanceur, un classificateur et un gestionnaire de files d attente. De plus, le NE QoS-capable doit contenir un plan de contrôle pour la réservation de ressources, le contrôle d admission et le contrôle d accès (Figure 2-2). Ces fonctionnalités se basent principalement sur le protocole de réservation de ressources RSVP (ReSerVation Protocol) [BRA 97a]-[MAN 97]-[BRA 97b] recommandé par l IETF. Figure 2-2 : Plan de contrôle d un routeur IntServ Le protocole de signalisation RSVP permet la réservation dynamique de ressources sur le réseau en mettant en place une connexion logique, appelée session. Cette dernière est identifiée par trois paramètres : l adresse de destination, l identifiant du protocole (IP) et le port de destination (optionnel). Dans RSVP, l initialisation et le maintien de la réservation des ressources sont contrôlés par le récepteur et la réservation est unidirectionnelle, de l émetteur vers le récepteur. Autrement dit, la réservation, déclenchée par l application réceptrice, configure l ensemble des routeurs traversés le long du chemin des données en fonction de la nature du trafic spécifié. Les paramètres de contrôle du trafic (QoS) et les politiques de 14

34 contrôle véhiculés par RSVP sont définis en dehors de ce dernier. Ces paramètres sont documentés dans des spécifications propres à IntServ. Cette architecture offre la gestion de la QoS de bout en bout la plus fine qui soit puisqu elle supporte des degrés de service non prédéfinis et contrôlés qui correspondent exactement aux besoins d un flux applicatif. Par ailleurs, elle réduit au maximum l hétérogénéité des protocoles de signalisation à supporter en offrant un cadre de référence homogène d un domaine à un autre. La gestion de la QoS est ainsi entièrement distribuée dans l ensemble du réseau. Par ailleurs, son contrôle d admission, qui reposait uniquement sur la disponibilité ou non de ressource, a été complété par un contrôle d accès aux ressources basé sur des règles de contrôle [BOY 00]. Malgré sa robustesse, l architecture IntServ n a pas rencontré le succès escompté pour assurer la QoS au niveau IP. L inconvénient majeur de RSVP reste le problème de passage à l échelle. En effet ce mécanisme se révèle totalement inadéquat en cœur de réseau où la concentration de flux est telle que la charge due à la signalisation induite et le nombre d états dans le plan de contrôle et de données à gérer au sein des routeurs explosent [PAN 02]. Les autres reproches concernent sa complexité de mise en oeuvre et l overhead introduit sur le réseau en utilisant un protocole de réservation de ressources. Des solutions alternatives se basant sur les mêmes principes fondamentaux (architecture de QoS homogène, un protocole de signalisation unique, déclenchement de la réservation de ressource par l utilisateur) ont déjà été proposées notamment à travers YESSIR (YEt another Sender Session Internet Reservation) [PAN 98] ou Boomerang [FEH 99] mais ces solutions, bien que mieux adaptées, supportent difficilement le passage à l échelle. De ce fait, un autre paradigme a été proposé par opposition à ce modèle d architecture à service intégré pour résoudre le problème de passage à l échelle ; il s agit de l architecture DiffServ [BLA 98] qui introduit la notion de l agrégation de flux La différenciation de services (DiffServ : Differentiated Services) Afin de surmonter le problème de passage à l échelle posé par la gestion d une QoS par flux dans les routeurs du cœur de réseau, l IETF a introduit un autre modèle de QoS plus simple à déployer, appelé DiffServ [BLA 98]. Au lieu d offrir une QoS pour chaque flux comme le propose IntServ, DiffServ offre des services par agrégats en repoussant aux extrémités du réseau le traitement par flux. Ainsi, à la frontière d un réseau, les micro-flux applicatifs sont agrégés en quelques macro-flux associés chacun à une classe de service. Les routeurs de cœur ne traitent alors plus que des agrégats limités en nombre ce qui permet de réduire considérablement le nombre d états maintenus sur le réseau de transit et les réseaux d opérateurs. L architecture DiffServ s appuie sur le découpage actuel d Internet en domaines autonomes, c est-àdire un regroupement de nœuds qui répondent à une seule et même autorité administrative. La Figure 2-3 illustre une architecture DiffServ qui définit des domaines, des régions et des routeurs. Le domaine DiffServ (DS Domain) représente une zone administrative (domaine autonome), avec plusieurs routeurs partageant la même définition de services et de PHB (Per Hop Behavior). Un ensemble de domaines DiffServ constitue une région DiffServ (DS Region). Au sein d un domaine DiffServ, on distingue les routeurs de bordure (DS boundary nodes) incluant des routeurs d entrée et de sortie qui peuvent être reliés directement à un réseau utilisateur ou à un autre domaine et les routeurs de cœur (DS interior nodes). 15

35 Figure 2-3 : Architecture DiffServ Au sein d un domaine DiffServ, les routeurs de cœur traitent les paquets en fonction de la classe de ce paquet. En effet, DiffServ distingue différentes classes de trafic en se basant sur le champ DSCP (DiffServ Code Point) défini sur 6 bits et présent au niveau de l entête des paquets IP [NIC 98]. Ceci constitue une sorte de signalisation dans la bande (in-band). Les paquets appartenant à la même classe identifiée par le DSCP sont traités suivant un comportement approprié, appelé PHB. Un PHB est une description du comportement de transmission d un nœud DiffServ, face à une classe particulière de trafic. La mise en œuvre d un PHB au niveau des nœuds DiffServ se fait grâce à des mécanismes de gestion et d ordonnancement de files d attentes. L architecture DiffServ définit deux types principaux de PHB : Expedited Forwarding (EF) [JAC 99] : le PHB EF correspond à la plus forte priorité et assure le transfert de flux à fortes contraintes temporelles en garantissant une bande passante avec un taux de perte, un délai et une gigue très faibles. Pour ce service, il est important de bien connaître le débit minimum sortant d un nœud DiffServ. Ce débit doit être supérieur au débit entrant. Le DSCP correspondant à ce service est : Assured Forwarding (AF) [HEI 99]: le PHB AF garantit l acheminement de certains paquets en cas de congestion. Il permet la définition de plusieurs classes de trafic en utilisant plusieurs PHB. Il est possible de définir N classes (AF) indépendantes avec M niveaux de priorités différents (drop precedence) pour chacune d elles. Actuellement, quatre classes de traitement (N=4 : AF1, AF2, AF3 et AF4) sont définies et chacune d elles comprend trois niveaux de priorité (M=3). Les classes AF sont configurées pour consommer davantage de ressources lorsqu elles sont disponibles. En cas de surcharge, le nœud DiffServ supprime les paquets dans les classes AF en fonction de leur niveau de priorité. La mise en œuvre du PHB AF doit minimiser la surcharge permanente de chaque classe tout en autorisant les pics de trafic. En dehors du PHB, un routeur de cœur implémente un classificateur de type «Behavior Aggregate» qui sélectionne les paquets uniquement en fonction de la valeur du champ DSCP. Ce marquage, sur lequel s appuient les routeurs, de cœur est effectué par les routeurs de bordure. Les routeurs de bordure adoptent généralement des mécanismes plus sophistiqués qu en cœur de domaine. Ils mettent en œuvre deux principaux mécanismes : la classification et le conditionnement du trafic. 16

36 La classification vise à associer des classes d application ou d utilisateur à telle ou telle classe de service DiffServ ou à des mécanismes de régulation spécifiques. Ainsi, cette classification peut s effectuer suivant deux techniques : BA (Behavior Aggregate) : La classification est établie en fonction de la valeur DSCP. MF (Multi-Field) : La classification peut prendre en considération d autres champs comme l adresse source ou destination, le numéro de port, etc. Le conditionnement du trafic effectué par les routeurs de bordure est illustré par la Figure 2-4 qui permet de distinguer les différents composants contenus dans ce type de routeur : Le métreur (Meter) : Il mesure le trafic afin de s assurer qu il est conforme au profil contracté avec l utilisateur. Les mesures sont communiquées aux autres composants pour appliquer la politique de contrôle appropriée. Le marqueur (Marker) : Il modifie la valeur du champ DSCP. Le lisseur (Shaper) : Il se charge de lisser le trafic en retardant l envoi de certains paquets pour les rendre conforme à leur profil. Pour cela, il stocke les paquets dans un buffer de taille limitée. Le suppresseur (Dropper) : (il supprime le trafic non conforme) Il supprime les paquets dans le cas où le débit défini dans le profil est dépassé. Figure 2-4 : Le conditionnement du trafic DiffServ DiffServ propose de gérer un certain nombre de niveaux de QoS prédéfinis par le responsable du domaine. Le traitement différencié au sein d un domaine DiffServ, fondé sur le champ DSCP, se fait grâce à l agrégation de trafics aux exigences similaires en bordure de ce domaine. En plus du passage à l échelle que permet l architecture DiffServ, elle peut être considérée comme l architecture la plus adaptée aux réseaux IP d aujourd hui, contrairement à l architecture de QoS homogène proposé par IntServ. Cependant, elle présente des lacunes au niveau du plan de contrôle. En effet, chaque domaine sous l autorité d un opérateur de réseau offre des services (DiffServ) et tout client (opérateur ou particulier) qui veut en bénéficier doit négocier un accord avec l opérateur concrétisé par un contrat appelé SLA (Service Level Agreement) (cf. section 3.2.1). Au début, la négociation des SLA s effectuait manuellement (fax, , courrier, etc.), ce qui fait d elle une procédure lourde et relativement statique (mise à jour une fois par mois). De plus, l allocation des ressources n étant pas automatisée, la reconfiguration des ressources au sein d un domaine DiffServ pour supporter de nouveaux services est une procédure relativement longue (des heures, voire des jours). Cette configuration manuelle implique, au niveau des routeurs périphériques, une politique statique associant des classes d application et des utilisateurs à des classes de services ce qui n est 17

37 pas suffisant pour répondre aux changements dynamiques qui s opèrent au sein d un réseau. Afin d y remédier et d offrir une QoS de bout en bout, une solution hybride IntServ/DiffServ [BER 00] a été proposée afin de combiner une gestion par flux selon le modèle IntServ dans les réseaux périphériques (réseau d entreprise ou LAN) et une gestion par agrégat selon le modèle DiffServ dans les réseaux de transit. Cependant elle impose le support de RSVP par les applications, ce qui n est toujours pas le cas actuellement et ne résout pas le problème d allocation dynamique des ressources dans les domaines DiffServ. Afin de répondre à ces lacunes, de nombreuses solutions ont été proposées par l IETF et des projets de recherche tels que Cadenus, Aquila, Tequila et Internet2-Qbone (cf. section 3.3.1). Le point commun de l ensemble de ces propositions est qu elles se rejoignent sur le concept d une architecture de gestion des ressources à deux étages [TER 99] reposant sur une signalisation intra-domaine pour l allocation des ressources au sein d un même domaine et une signalisation inter-domaines pour les ressources partagées entre les domaines. Chaque opérateur est ainsi à même de gérer l allocation des ressources dans son domaine, comme il l entend MPLS (MultiProtocol Label Switching) Contrairement aux deux architectures précédentes, IntServ et DiffServ, MPLS ne constitue pas une architecture de QoS proprement dite, mais plutôt une architecture qui appartient à l ingénierie de trafic. C est une architecture qui déploie des mécanismes ainsi que des protocoles dans un réseau afin d améliorer son fonctionnement en exploitant plus efficacement les ressources disponibles. Ceci conduit indirectement à améliorer la qualité de service d un réseau. L architecture MPLS (MultiProtocol Label Switching) [ROS 01] a été définie par l IETF pour unifier le monde de la commutation de circuits et le monde de la commutation de paquets en utilisant une commutation de labels. Ceci signifie que dans un réseau MPLS, le routage des paquets se base sur des labels qui sont inclus dans leurs entêtes. Le fonctionnement MPLS se base essentiellement sur les trois notions suivantes : La FEC (Forwarding Equivalence Class) : Une FEC regroupe un certain nombre de paquets possédant des caractéristiques communes qui déterminent leur cheminement dans le réseau. La constitution des FEC par MPLS peut se baser sur des critères comme la destination, la source, la QoS, l application, etc. L assignation d un paquet à une FEC est effectuée une seule fois à l entrée du réseau. Le label MPLS : Appelé MPLS Shim, ce label constitue un entête de paquet dont le format dépend essentiellement du réseau sur lequel MPLS est mis en œuvre. Le label MPLS contient un champ label de 20 bits qui permet d identifier une FEC sur un routeur particulier. En fait, une FEC peut être identifiée par différents labels sur différents routeurs. Le LSP (Label Switch Path) : Il représente le chemin d une FEC dans un réseau MPLS. Ce chemin est constitué de succession de labels attribués par chaque routeur pour une FEC. L architecture MPLS définit deux types de routeurs : LSR (Label Switch Router) et LER (Label Edge Router). Le LSR, se trouvant à l intérieur d un réseau MPLS, est capable de commuter les paquets suivant leur label, tandis que le LER, localisé à l extrémité du réseau, se charge de l assignation des labels aux paquets entrants et de la suppression de ces labels sur les paquets sortants. 18

38 Chaque routeur doit gérer deux tables : une table de routage et une table de labels. La table de routage est construite en utilisant les protocoles de routage IP standards (RIP, OSPF, BGP, etc.). En ce qui concerne la table de labels, sur laquelle repose la commutation, l IETF propose deux solutions, soit l utilisation d un protocole de distribution de labels spécifique, LDP (Label Distribution Protocol) [AND 01], soit l extension des protocoles existants pour assurer la distribution de labels, par exemple RSVP [AWD 01]. Le principe de fonctionnement d un réseau MPLS peut être résumé comme suit (Figure 2-5) : lorsqu un paquet entre dans un réseau MPLS, un routeur LER l affecte à une FEC selon la politique déployée dans le réseau en lui assignant le label de cette FEC. Le LER transmet le paquet au prochain routeur suivant sa table de labels. Les LSR font suivre le paquet suivant son label en lui affectant à chaque fois le label local qui identifie la FEC auquel il appartient. Ceci se répète, jusqu au routeur LER de sortie qui supprime le label sur le paquet. Figure 2-5 : Fonctionnement MPLS MPLS est un protocole très répandu dans les réseaux IP qui repose uniquement sur la commutation par paquets. Cependant, il existe une généralisation de ce protocole appelée GMPLS (Generalized MPLS) [MAN 04]. L objectif de GMPLS est d étendre le fonctionnement de MPLS afin de supporter plusieurs types de commutation, ce qui permet de transmettre non plus uniquement des paquets mais aussi des circuits comme la voix. GMPLS, qui s inscrit dans l évolution vers les réseaux de nouvelle génération, permet d avoir une structure de contrôle unique sur les trois premières couches du réseau. Le nombre d interfaces entre ces couches va donc pouvoir être réduit, d où la baisse importante des coûts opérationnels du réseau mais aussi la croissance de l efficacité de transport des paquets. Synthèse : Les trois architectures et mécanismes de QoS que nous avons détaillés ci-dessus ; à savoir IntServ, DiffServ et MPLS/GMPLS, ont permis de comprendre comment la QoS peut être gérée dans les réseaux IP. Ces modèles vont largement inspirer les organismes de normalisation des réseaux de nouvelle génération ainsi que les travaux de recherche dans la définition d une architecture de QoS NGN. En effet, ce qui caractérise l architecture NGN, c est essentiellement la segmentation du réseau global qui peut être divisé en un réseau d accès et un réseau de cœur qui peut être vu comme une concaténation de domaines administratifs dans lesquels la QoS est gérée par niveau. Nous notons qu un réseau d accès peut avoir ses propres mécanismes de gestion de QoS qui ne dépendent que de la technologie implémentée par ce 19

39 réseau. Par conséquent, nous rappelons dans la section suivante quelques mécanismes de QoS propres à certains types de réseaux d accès La QoS dans les réseaux d accès Dans cette partie, nous allons nous intéresser aux mécanismes de QoS implémentés par différentes technologies d accès comme le Wi-Fi (IEEE ), le WiMax (IEEE ) ou encore la technologie Satellite de type DVB-S2/RCS Mécanismes de QoS dans les réseaux Wi-Fi Le réseau WLAN (Wi-Fi) permet la transmission de données en utilisant des liens sans fil. Ce réseau définit deux modes d utilisation : le mode infrastructure et le mode ad-hoc. Le mode infrastructure inclut une station de base qui assure la liaison entre le réseau Wi-Fi et le réseau filaire. Ainsi, tous les terminaux sans fil des utilisateurs du réseau Wi-Fi doivent être associés à cette station de base. Quant au mode ad-hoc, il est caractérisé par une communication directe entre les terminaux sans fil. Lorsqu un terminal sans fil d un réseau veut transmettre des données, il doit pouvoir accéder au canal de communication. Ce dernier est divisé en intervalles temporels appelés supertrames. Une supertrame est divisée en deux périodes : une période d accès sans contention (CFP : Contention Free Period) à laquelle les terminaux sans fil accèdent en utilisant le mécanisme d accès centralisé (PCF : Point Coordination Function), et une période d accès avec contention (CP : Contention Period) à laquelle les terminaux sans fil accèdent en utilisant le mécanisme d accès distribué (DCF : Distributed Coordination Function). Le mécanisme PCF est fondé sur un point de coordination (généralement le point d accès) qui gère l accès au canal en interrogeant à tour de rôle les terminaux sans fil afin de leur offrir l opportunité de transmettre. Quant au mécanisme DCF, il se base sur CSMA/CA (Carrier Sense Multiple Access/Collision Avoidance) pour que les terminaux sans fil puissent gérer eux-mêmes l accès distribué et équitable au canal. Les méthodes d accès proposées par le (PCF et DCF) présentent un certain nombre de limitations. Par exemple, dans le cadre d un accès centralisé PCF, lorsque le canal est occupé par une communication d un terminal sans fil, le point de coordination n a plus le contrôle du canal ; ce qui peut engendrer des délais imprévisibles. De plus, dans le cadre d un accès décentralisé DCF, il est difficile d obtenir des garanties en termes de délai, de gigue et de bande passante, parce qu il n y a aucune notion de priorité à cause d un partage équitable de la bande passante entre les terminaux sans fil du réseau. Afin de pouvoir fournir des garanties en termes de QoS, des mécanismes de QoS ont été introduits grâce au standard IEEE e. Il s agit des deux nouvelles fonctions : EDCF (Enhanced Distributed Coordination Function) et HCF (Hybrid Coordination Function). Le mode d accès EDCA (Enhanced Distributed Channel Access) se base sur la fonction EDCF afin de proposer un service de différentiation définissant quatre catégories d accès au niveau MAC. Au sein d un même terminal sans fil, chaque catégorie d accès peut être considérée comme une entité de transmission indépendante avec ses propres paramètres de transmission, comme le délai backoff représentant l inactivité du canal. Chaque catégorie d accès est implémentée sous forme d une file d émission. Ainsi, les données à transmettre doivent être étiquetées avec la priorité adéquate afin d être redirigées vers la file d attente avec la QoS correspondante. 20

40 Le mode d accès HCCA (HCF Controlled Channel Access) se fonde sur la fonction HCF afin de gérer l accès des terminaux sans fil au canal. Les terminaux sans fil sont toujours interrogés à tour de rôle par le point d accès qui devient un coordinateur hybride (HC : Hybrid Coordinator). L accès d un terminal sans fil au canal de transmission ne dépend que du paramètre TXOP qu il possède. La notion de TXOP, introduite dans le standard e, représente l opportunité de transmission d un terminal sans fil, et détermine une date de début de la transmission ainsi qu une durée pendant laquelle le terminal peut transmettre Mécanismes de QoS dans les réseaux WiMax Le standard de transmission radio (WiMax) a été proposé dans le cadre des nouvelles technologies réseau sans fil offrant de hauts débits. L architecture d un réseau WiMax implique deux types d équipements : le terminal utilisateur et la station de base qui possède des fonctionnalités de gestion et de contrôle du réseau. La transmission de données de la station de base vers les terminaux mobiles se fonde sur le mécanisme de multiplexage temporel (TDD : Time Division Duplex), tandis que la transmission dans le sens inverse est basée sur le mécanisme d accès multiple à division dans le temps (TDMA : Time Division Multiple Access). Afin d accéder au canal de transmission, les terminaux doivent demander l autorisation auprès de la station de base qui s occupe de l allocation des ressources en utilisant un des trois mécanismes suivants : allocation de bande non sollicitée (unsolicited bandwidth grants), allocation de bande par système d interrogation des terminaux, appelée allocation sans contention (polling) ou encore allocation avec contention (contention procedure). Afin de répondre aux besoins des applications gourmandes en termes de QoS, la couche MAC du propose des services de QoS différentiés. Chacun de ces services est associé à un type d application et propose d utiliser une méthode d accès : Le service UGS (Unsolicited Grant Service) : Ce service supporte les flots temps réel qui génèrent périodiquement des paquets de données de taille fixe tel que la voix sur IP. L accès au canal ne nécessite pas de requête de bande passante de la part du terminal, car cette ressource est négociée lors de l initialisation du terminal et lui est allouée statiquement pendant toute la durée d activation. Le service RTPS (Real Time Polling Service) : Ce service offre des requêtes d opportunités temps réel périodiques permettant aux terminaux de spécifier la taille de leurs données. L accès au canal se fait grâce à l attribution des opportunités de transmission périodiques par la station de base. Le service NRTPS (Non Real Time Polling Service) : Les flots NRTPS reçoivent le même service que les flots RTPS et utilisent la même méthode d accès (polling). Le service BE (Best-Effort) : Le service BE ou le service minimal concerne les flux qui ne nécessitent pas un niveau de QoS particulier. L accès au canal se fait grâce à la transmission de requêtes de bande passante par le terminal (mode contention) Mécanismes de QoS dans les réseaux Satellite Bien que les réseaux satellite aient longtemps été dédiés aux services de diffusion, ils sont devenus aujourd hui une technologie complémentaire aux infrastructures terrestres. Ceci est dû à l ajout d une voie 21

41 retour (terminal utilisateur vers satellite) en 1999 grâce au standard DVB-RCS (Digital Video Broadcast Return Channel over Satellite). Couplée avec la voie aller (satellite vers terminal utilisateur) s appuyant sur la norme DVB-S2 (DVB Satellite Second Generation), les réseaux satellite ont permis d offrir des services IP multimédia large bande dans les zones géographiques non couvertes ou à couverture difficile. Un réseau d accès Internet par satellite implique essentiellement les entités suivantes : un terminal satellite qui se comporte comme un routeur d accès à la voie retour pour le trafic utilisateur, et une passerelle qui centralise l ensemble du trafic dans le réseau satellite et établit l interconnexion avec les réseaux terrestres. Cette passerelle comporte souvent une deuxième fonction, à savoir celle de l entité NCC (Network Control Center) qui consiste à gérer les ressources du réseau satellite. Dans un système satellite, la méthode d accès et la gestion de la QoS sont différentes entre la voie aller et la voie retour. Sur la voie aller, la passerelle centralise l ensemble des données et la signalisation, occupant ainsi toute la largeur de bande offerte sur la voie aller. Sur la voie retour, le point d entrée est distribué entre plusieurs terminaux Satellite dont l accès aux ressources est contrôlé par l algorithme DAMA (Demand Assignment Multiple Access). En effet, sur cette voie retour, la norme DVB-RCS propose un mécanisme de résolution des contentions d accès entre les différents terminaux Satellite voulant accéder simultanément au lien retour du satellite. Il s agit d utiliser la méthode MF-TDMA (Multi Frequency Time Division Multiple Access) qui se base sur une division fréquentielle où chaque porteuse est divisée en «supertrames», puis en unités temporelles de durée fixe appelés «timeslots». Ce sont ces timeslots qui sont utilisés par les terminaux Satellite afin de transmettre leurs donnés. Afin de permettre une allocation dynamique de la bande passante, des techniques d allocation à la demande (BoD : Bandwidth on Demand) sont introduites dans le standard DVB-RCS. En effet, le protocole DAMA permet aux terminaux satellite de demander la «capacité d émission» auprès du NCC. Ceci est basée sur un modèle client/serveur où un client DAMA, installé au niveau d un terminal satellite, transmet des requêtes de capacité vers le serveur DAMA, se trouvant au sein du NCC, afin de réserver des timeslots pendant lesquels le terminal satellite pourra émettre sur la voie retour. Le standard DVB-RCS définit également des classes de trafic au niveau MAC qui peuvent être implémentées au sein du terminal satellite par des files d émission MAC distinctes. Ces classes sont au nombre de quatre : la classe RT (Real Time) dédiée aux applications temps réel, la classe VR-RT (Variable Rate) correspondant au trafic sensible au débit variable, la classe VR-JT dédiée au trafic tolérant à la gigue et la classe JT (Jitter Tolerant) pour le reste du trafic. Synthèse : Après avoir rappelé les mécanismes de QoS mis en place dans les réseaux IP et dans certain types de réseau d accès, nous allons nous focaliser sur les mécanismes permettant d offrir des garanties en matière de QoS dans un environnement de réseaux de nouvelle génération La QoS dans les réseaux NGN Afin de surmonter l hétérogénéité des technologies de chaque domaine et afin d offrir des services globaux avec une QoS homogène de bout en bout, le modèle de QoS dans les réseaux NGN doit intégrer: Une décomposition horizontale spatiale en différents niveaux hiérarchiques de description des services regroupés en deux plans principaux «Service» et «Transport» 22

42 Une décomposition spatiale verticale en plusieurs zones : Terminal Utilisateur, Réseau Utilisateur, Réseau d accès et Réseau de cœur Dans les réseaux NGN, on note également que plusieurs modèles de réservation de QoS sont disponibles en fonction des capacités du terminal utilisateur et des équipements supportés par les opérateurs de service et de réseau : Un modèle où le fournisseur de service prend en charge la réservation de ressource auprès des opérateurs réseau Un modèle où l utilisateur, après l autorisation préalable du fournisseur de service, réserve lui-même ses ressources auprès de l opérateur de réseau à travers un protocole de réservation de ressource de bout en bout (e.g. signalisation NSIS (Next Step In Signaling) de l IETF) Un modèle où l opérateur de réseau prend en charge la propagation d opérateur en opérateur de la signalisation des besoins applicatifs d une session. La Figure 2-6 expose une vue d ensemble simplifiée de l ensemble des architectures de QoS proposées par l ITU, l ETSI, 3GPP [IST 04]. Figure 2-6 : Architecture de QoS dans les réseaux NGN Le point commun de ces architectures est de décomposer le plan de «Transport» en deux couches de gestion des ressources : la couche NTI (Network Technology Independant) gérée par le SN (SLS Negotiator) afin de pouvoir offrir au client et au fournisseur de services des interfaces génériques masquant l hétérogénéité des réseaux et des politiques de QoS sous-jacentes, et la couche NTD (Network Technology Dependant) gérée par le NC (Network Controller) qui permet une gestion des ressources par l opérateur de réseau optimisée pour le type de réseau concerné. 23

43 Le contrôle dans les réseaux NGN, initialement présenté sous forme d une couche, est divisé en deux parties : l une appartenant aux opérateurs de réseau (au niveau de la couche de «Transport») et l autre aux fournisseurs de services (rattaché à la couche de Service). Le SCF (Service Control Function) constitue une couche intermédiaire permettant aux fournisseurs de services de piloter la couche de «Transport» via une interface de négociation de «services supports» génériques offertes par les SN. Quant au modèle de déclenchement et de propagation de la signalisation des besoins applicatifs exprimés en termes de QoS génériques dans l ensemble des domaines traversés lors d une communication multi-domaines, cela ne rentre pas dans la portée des travaux normalisation des organismes travaillant sur les réseaux NGN, et nous allons voir dans la section 3.3 comment cela constitue un domaine de recherche ainsi que les différentes solutions proposées. Généralement, les réseaux d accès et les réseaux de transit ne mettent pas en œuvre les mêmes protocoles de contrôle des ressources. En effet, les réseaux de transit sont généralement surdimensionnés, leurs principales préoccupations en terme de QoS sont, d une part, l interfaçage entre les réseaux d accès et les fournisseurs de services et, d autre part, les problématiques de signalisation multi-domaines (négociation dynamique de SLA entre opérateurs de cœur) Résumé La qualité de service est devenue une notion incontournable dans les réseaux de nouvelle génération. Ceci est dû non seulement aux exigences des services très gourmands en matière de QoS (IPTV, VoD, ToIP, etc.), mais aussi à la variété des besoins des différents services en termes de QoS. La gestion de la QoS dans les réseaux NGN s inspire grandement des mécanismes définis pour la gestion de la QoS dans les réseaux IP. La nature de l architecture des réseaux NGN et le changement fréquent des besoins de QoS dans un tel environnement nécessitent une gestion dynamique de ces aspects qui n est possible qu avec l utilisation de protocoles de signalisation. Cette signalisation ainsi que les protocoles qui permettent de l assurer seront détaillés dans la section Mais avant cela nous allons, dans ce qui suit, introduire une autre notion qui n est pas d une moindre importance dans les réseaux NGN : la sécurité. 2.5 La sécurité Les réseaux NGN utilisent essentiellement IP pour le transport des différents services qu ils fournissent. Etant donné qu IP n offre aucune sécurité par défaut, les services transportés par les réseaux NGN peuvent avoir besoin de garanties en matière de sécurité. Cette sécurité devient même indispensable du fait que les utilisateurs se connectent de plus en plus via des réseaux sans fil fondés sur des média ouverts. Afin de pallier aux failles de sécurité et de résister aux attaques malveillantes, le transport des données doit être sécurisé de bout en bout. Aujourd hui, un grand nombre de protocoles de sécurisation des services (SSL/TLS, DTLS, IPSec, RADIUS, etc.) est disponible, et la sécurité peut être implémentée à divers niveaux de la pile protocolaire des services. Dans cette partie, nous introduisons les menaces de sécurité des communications avant de décrire les services de sécurité qui permettent de protéger les services transportés sur les réseaux IP. Ensuite, nous présentons quelques notions de cryptographie. Ces notions sont nécessaires pour comprendre les 24

44 protocoles et les mécanismes de sécurité que nous détaillons dans la section réservée à la sécurité dans les réseaux IP. Puis, nous décrivons des mécanismes de sécurité proposés pour protéger certains types de réseau d accès. Dans la dernière section de cette partie, nous décrivons comment la sécurité peut être fournie aux services offerts par les réseaux de nouvelle génération Attaques, services et opérations cryptographiques Nous pouvons distinguer deux sortes d attaques qui peuvent menacer la sécurité des communications : les attaques passives et les attaques actives [STA 06] Attaques de sécurité Les attaques passives Le but de ce genre d attaque est d obtenir des informations qui ont été transmises sur le réseau. Ces attaques sont au nombre de deux : La capture de contenu des messages : C est une attaque portée à la confidentialité des communications. Il peut s agir d une tierce partie non autorisée qui accède aux données échangées sur le réseau. L analyse de trafic : C est une attaque plus subtile que la première. Supposons que le contenu des messages échangés soit protégé contre «la capture de contenu des messages» en mettant en place, par exemple, un processus de chiffrement. En observant les entêtes des messages échangés ainsi que leur longueur et leur fréquence, une tierce partie peut déterminer l identité des systèmes communicants et deviner la nature de la communication. Les attaques passives sont très difficiles à détecter parce qu elles ne causent aucune altération des données échangées sur le réseau Les attaques actives Les attaques actives impliquent des modifications dans le flot des données ou la création d un faux flot. Ce type d attaque peut regrouper quatre catégories : La mascarade : C est une attaque qui se produit lorsqu une entité prétend être une autre entité. Une mascarade inclut toujours l une des autres formes d attaques actives. Le rejeu : Cette attaque consiste à capturer des données et à les retransmettre ultérieurement dans le but de produire un effet non autorisé. Par exemple, un message permettant la mise à jour d une entrée dans une base de données peut être rejoué afin de revenir à un état antérieur différent de l état actuel. La modification de messages : Il s agit d une attaque qui menace l intégrité. Elle implique l altération de certaines parties d un message légitime, ou le retard ou la réorganisation des messages, dans le but de produire un effet non autorisé. Par exemple, le message «autoriser ALICE à lire le fichier confidentiel comptes» peut être modifié en «autoriser BOB à lire le fichier confidentiel comptes». Le déni de service : C est une attaque qui menace la disponibilité du réseau. Elle vise à prévenir ou empêcher l utilisation normale de fonctionnalités de communication. Cela peut consister, par exemple, à mettre hors-service le réseau en le surchargeant de messages. 25

45 Contrairement aux attaques passives, il est très difficile de se prémunir parfaitement des attaques actives. Ainsi, l objectif est de détecter ces attaques et de corriger, par la suite, tout dérangement ou retard qu elles peuvent causer. Les termes : disponibilité, confidentialité, intégrité et authenticité que nous avons utilisés dans les définitions des attaques ne sont autres que des services de sécurité. Ces services de sécurité seront définis dans la section suivante Services de sécurité Dans le contexte des communications, un service de sécurité est un service fourni grâce à un protocole de communication entre systèmes ouverts. Il assure la sécurité adéquate des systèmes communicants et des données échangées entre ces systèmes. Ces services peuvent être classés en six catégories [STA 06] Authentification Ce service permet d assurer l authenticité d une communication. Deux services d authentification ont été définis : Authentification du vis-à-vis : Ce service assure que les deux entités d une association sont authentiques. Cela revient à certifier que chaque entité est ce qu elle dit être. Authentification de l origine des données : Ce service assure que le message reçu a bien pour origine la source dont il prétend être issu. Cela ne fournit aucune protection contre la duplication ou la modification des messages Contrôle d accès Cela consiste à limiter et contrôler l accès à des systèmes ou des applications via des interfaces de communication. Pour cela, chaque entité doit être authentifiée afin de pouvoir adapter les droits d accès à chaque cas Confidentialité des données C est la protection des données transmises contre les attaques passives. Plusieurs niveaux de protection sont identifiés. Le service le plus général protège toutes les données transmises entre deux entités. Des formes restreintes de ce service peuvent également être définies, incluant la protection d un message entier ou même de champs spécifiques à l intérieur d un message. L autre aspect de la confidentialité est la protection du flot contre l analyse de trafic. Cela requiert qu un attaquant ne puisse observer les sources et destinations, les fréquences, longueurs ou autres caractéristiques du trafic existant sur un équipement de communication Intégrité des données C est la protection des données transmises contre les attaques actives. Il s agit de détecter ce genre d attaques plutôt que de les prévenir. Un service d intégrité orienté connexion permet d assurer que les messages échangés sont reçus aussitôt qu envoyés sans duplication, insertion, modification, réorganisation, répétition ou destruction. Un service d intégrité non orienté connexion fournit une protection contre la modification des données. 26

46 Non-répudiation Cela permet d empêcher n importe quelle extrémité d une communication (expéditeur ou receveur) de nier avoir transmis un message. Ainsi, lorsqu un expéditeur E envoie un message à un receveur R, ce dernier peut prouver que le message a bien été envoyé par l expéditeur E. De la même manière, lorsque le receveur R reçoit un message, l expéditeur de ce message E peut prouver que le message a bien été reçu par le receveur R Disponibilité La disponibilité est la possibilité d accéder à un système et de pouvoir utiliser ses ressources par une entité autorisée. La perte ou la réduction de cette disponibilité est une forme d attaque. Certaines de ces attaques entrainent des contre-mesures automatiques, telles que l authentification et le chiffrement, alors que d autres nécessitent une intervention humaine pour se rétablir de la perte de disponibilité. Les services de sécurité sont implémentés par des mécanismes et des protocoles de sécurité. Les protocoles de sécurisation des échanges les plus utilisés seront présentés dans la section Mais avant cela, nous rappelons, dans ce qui suit (cf. section ), quelques notions cryptographiques Notions de cryptographie La mise en œuvre de la sécurité des communications nécessite en général l utilisation de différents algorithmes cryptographiques. Pour comprendre comment les différents services de sécurité sont mis en place, nous introduisons, dans cette section, quelques notions de cryptographie [STA 06] telles que les algorithmes de cryptage, les codes d authentification et les fonctions de hachage Confidentialité des messages La confidentialité des messages est assurée grâce aux algorithmes de chiffrement. Ces algorithmes peuvent être divisés en deux classes : le chiffrement symétrique et le chiffrement à clé publique. Bien que le chiffrement à clé publique ait été développé après le chiffrement symétrique, ce dernier reste le plus largement répandu des deux types parce qu il est plus robuste. Chiffrement symétrique Le chiffrement symétrique est un procédé qui peut être divisé en deux phases : chiffrement et déchiffrement. La première phase a lieu sur le système de l expéditeur. Elle consiste à générer le texte chiffré à partir du texte en clair en utilisant un algorithme de chiffrement et une clé secrète. Le texte chiffré, transmis sur le canal de communication, arrive au receveur qui procède au déchiffrement. Le déchiffrement consiste à retrouver le message originel (texte en clair) à partir du texte chiffré en utilisant un algorithme de déchiffrement et une clé secrète. Notons que l algorithme de déchiffrement est essentiellement l algorithme de chiffrement exécuté à l envers et que la clé utilisée par l expéditeur dans le chiffrement est la même que celle employée par le récepteur dans le déchiffrement, d où la désignation du système sous le terme de symétrique. Cette clé doit être absolument maintenue secrète et connue uniquement par l expéditeur et le récepteur. Au contraire, l algorithme n a pas besoin d être gardé secret. Ainsi, les fabricants peuvent développer des implémentations peu coûteuses d algorithmes de chiffrement sous formes de circuits intégrés. Ces circuits peuvent être incorporés dans des systèmes embarqués. 27

47 Il existe deux façons de traiter le texte en clair : par blocs ou par flot. Un chiffrement par bloc divise le texte en clair en blocs de taille fixe et applique les opérations de transformation (substitution et transposition) à chaque bloc afin de produire un bloc chiffré de la même taille. Un chiffrement par flot traite le texte en clair sans interruption afin de produire le texte chiffré en une seule fois. Les algorithmes de chiffrement symétrique les plus utilisés sont des chiffrements par blocs. Parmi ces algorithmes, nous pouvons citer : DES (Data Encryption Standard), 3DES (Triple DES) et AES (Advanced Encryption Standard). Data Encryption Standard : C est l algorithme de chiffrement le plus largement employé. Il traite des blocs de 64 bits en utilisant une clé de taille 56 bits. L algorithme DES est un algorithme qui présente une grande résistance à une cryptanalyse, mais avec une clé de longueur 56 bits, la EFF (Electronic Frontier Foundation) à annoncé en Juillet 1998 la vulnérabilité du chiffrement DES a une attaque par force brute (recherche de clé) en utilisant une machine conçue à ce but. Triple DES : L algorithme 3DES emploie trois clés et trois exécutions de l algorithme DES. Pour le chiffrement des données, la fonction suit une séquence : chiffrement [clé 1] --- déchiffrement [clé 2] -- - chiffrement [clé 3]. Ainsi, pour le déchiffrement, le traitement suit la séquence inverse : déchiffrement [clé 1] --- chiffrement [clé 2] --- déchiffrement [clé 3]. La force de l algorithme 3DES est évidente. D abord, parce que l algorithme sous-jacent est DES. Ensuite, avec l emploi d une clé de longueur 168 bits, les attaques par force brute sont impossibles. Les inconvénients de cet algorithme sont sa lenteur par rapport à DES et la taille des blocs qui, comme avec DES, est égale à 64 bits. Advanced Encryption Standard : AES a été proposé pour remplacer 3DES. Il utilise des blocs de taille 128 bits et une clé de longueur : 128, 192 ou 256 bits. Le bon fonctionnement du chiffrement symétrique nécessite l utilisation d une même clé par les deux extrémités d un échange de données et la protection de cette clé. Par conséquent, un système cryptographique est fort lorsqu il est capable de livrer une clé aux deux extrémités d une communication, sans permettre aux autres de la voir. La distribution des clés peut se faire de plusieurs manières : Une partie choisit sa clé et la livre physiquement à l autre partie, Un tiers choisit la clé et la livre physiquement aux deux parties, Si les deux parties ont déjà une clé, alors cette clé peut être utilisée pour transmettre la nouvelle clé d une extrémité à l autre, Si les deux parties ont chacune une connexion chiffré avec un tiers, alors ce dernier pourrait livrer la nouvelle clé aux deux parties via les liaisons chiffrées. Chiffrement à clé publique Contrairement au chiffrement symétrique, le chiffrement à clé publique est fondé sur des fonctions mathématiques et l utilisation de deux clés séparées. En effet, le chiffrement à clé publique repose sur une paire de clés : une clé pour le chiffrement et une autre clé différente mais liée pour le déchiffrement. Le principe de la cryptographie à clé publique est le suivant ; chaque extrémité d une communication produit une paire de clés. Une de ces deux clés est rendue publique alors que l autre est tenue privée (elle est la seule entité à la connaître). Si une entité A veut envoyer un message privé à une entité B alors elle chiffre 28

48 le message en utilisant un algorithme de chiffrement et la clé publique de B. A la réception, l entité B peut déchiffrer le message en utilisant un algorithme de déchiffrement et sa clé privée et elle est la seule entité à pouvoir le faire. Parmi les algorithmes à clés publiques les plus utilisés, nous trouvons : RSA et Diffie-Hellman. RSA (Rivest Shamir Adleman) : C est un algorithme asymétrique de chiffrement à clé publique par blocs dans lequel le texte en clair et le texte chiffré sont des entiers entre 0 et n-1 pour n quelconque. Cet algorithme est fondé sur l utilisation d une paire de clés composée d une clé publique et d une clé privée pour chiffrer et déchiffrer les données confidentielles. La clé publique correspond à une clé qui est accessible par n importe quelle personne souhaitant chiffrer des informations, la clé privée est, quant à elle, réservée à la personne ayant créé la paire de clés. Diffie-Hellman : C est un algorithme d échange de clés. Il permet aux deux extrémités d une communication d échanger une clé secrète en toute sécurité. Cette clé peut être utilisée pour le chiffrement ultérieur des données. Certificats numériques : Pour qu un algorithme de chiffrement à clé publique, comme RSA, soit largement répandu, il faut que n importe quel participant puisse envoyer sa clé publique à un autre participant. De ce fait, n importe qui peut falsifier une annonce publique, et lire ainsi des messages destinés à une autre entité. Par exemple, un utilisateur pourrait feindre être l utilisateur A et publier une clé publique. Avant que l utilisateur A ne découvre la contrefaçon, le faussaire peut lire tous les messages chiffrés destinés à l utilisateur A. La solution à ce problème est le certificat à clé publique. Cela consiste en une clé publique plus un identifiant utilisateur du propriétaire de la clé, avec le bloc entier signé par un tiers de confiance. Ce tiers de confiance peut être une autorité de certification en qui les utilisateurs ont confiance. Distribution des clés secrètes avec des clés publiques : L échange de clés Diffie-Hellman peut être utilisé dans le partage d une clé secrète par deux utilisateurs. Cependant, cela ne fournit aucune authentification des deux partenaires en communication. La solution est d utiliser les certificats à clé publique. Si A veut communiquer avec B, alors il prépare un message qu il chiffre en employant le chiffrement symétrique avec une clé secrète jetable. Ensuite, la clé secrète finale est chiffrée en utilisant le chiffrement à clé publique avec la clé publique de B. Une fois chiffrée, cette clé est attachée au message et le tout est envoyé à B. Seule B est capable de déchiffrer la clé secrète finale. Si la clé publique de B est obtenue à l aide du certificat à clé publique, alors A est assuré de la validité de cette clé Authentification des messages Comme la confidentialité, l authentification des messages est une fonction de sécurité des communications très importante. Ce service consiste à vérifier que le contenu des messages n a pas été changé et que la source est authentique. L authentification peut être réalisé avec ou sans chiffrement. Authentification des messages avec chiffrement symétrique En utilisant le chiffrement symétrique, si le message contient un code de détection d erreur et un numéro d ordre, alors le récepteur est assuré qu aucune altération n a été faite et que le séquençage est correct. Ceci est du au fait que seul l expéditeur véritable est capable de chiffrer un message avec succès pour le récepteur. 29

49 Authentification des messages sans chiffrement L authentification des messages sans chiffrement consiste à rajouter une étiquette d authentification au message à émettre. Pour l authentification des messages, nous pouvons utiliser un code MAC (Message Authentication Code) ou une fonction de hachage à sens unique. Code d authentification de message : Produit en utilisant une clé secrète, ce code est ajouté au message d origine. Cette technique suppose que les deux extrémités de la communication partagent une clé secrète commune. L expéditeur calcule le code MAC qu il ajoute au message à transmettre. Le récepteur exécute le même calcul sur le message reçu. Si le code MAC reçu dans le message correspond à celui calculé par le récepteur, alors celui-ci est assuré que le message n a pas été altéré. Si le message contient un numéro d ordre alors le destinataire est assuré que l ordre est correct car un attaquant ne peut pas changer le numéro d ordre. Il existe plusieurs algorithmes qui permettent le calcul des codes MAC, et notamment l algorithme DEA. Fonction de hachage à sens unique : Une fonction de hachage prend en entrée un message de taille variable et produit en sortie un résumé de taille fixe qui sera ajouté au message à transmettre. Pour assurer l authenticité du message, on peut utiliser une des trois méthodes suivantes : chiffrer le résumé du message en utilisant le chiffrement symétrique, chiffrer le résumé du message en employant le chiffrement à clé publique (signature numérique), ou calculer le résumé a partir du message plus une valeur secrète connue des deux parties et non envoyé avec le message. Il existe plusieurs algorithmes de hachage qui permettent le calcul de résumé du message tels que SHA-1 et MD5. Le chiffrement à clé publique peut servir à l authentification des messages en utilisant ce qu on appelle la signature numérique. Cela consiste à chiffrer le résumé d un message en utilisant la clé privée de l expéditeur. Le récepteur du message peut déchiffrer le résumé en utilisant la clé publique de l expéditeur et vérifier que le message est bien envoyé par ce dernier La sécurité dans les réseaux IP Après avoir classé les différents types d attaques qui peuvent être portées aux données échangées lors d une communication, nous avons défini les services de sécurité qui permettent de pallier à ces attaques. Lorsque l échange de données implique des réseaux IP, les services de sécurité peuvent être offerts en employant des protocoles de sécurité. En effet, plusieurs protocoles permettent de pallier aux vulnérabilités de sécurité des communications. Les plus connus sont IPSec, SSL/TLS et DTLS. Ces protocoles permettent d ajouter de la sécurité de différentes manières parce qu ils opèrent à différents niveaux de la pile protocolaire. Le protocole IPsec permet de sécuriser les transferts de données au niveau réseau, tandis que les protocoles SSL/TLS et DTLS opèrent au niveau de la couche «Transport» pour protéger des services basés respectivement sur TCP et UDP. Nous réservons cette section à la description de ces protocoles de sécurité Le protocole IPSec Le protocole IPSec (IP Security Protocol) [KEN 05a] permet de protéger le trafic au niveau IP (IPv4 ou IPv6). Les services de sécurité qu offre ce protocole sont l intégrité, l authentification de l origine des données, la protection contre le rejeu et la confidentialité. IPSec peut être implémenté sur un terminal ou 30

50 une passerelle de sécurité (SG : Security Gateway). Ainsi, il permet de sécuriser une communication entre deux terminaux, deux passerelles de sécurité ou un terminal et une passerelle de sécurité. Pour fournir des services de sécurité, IPSec utilise deux mécanismes : AH (Authentification Header) et ESP (Encapsulating Security Payload). Le mécanisme AH [KEN 05b] offre l intégrité et l authentification de l origine des données, avec en option la protection contre le rejeu. Quant à ESP [KEN 05c], il propose le même ensemble de services, et offre également la confidentialité. Ces deux mécanismes peuvent être appliqués seuls ou combinés pour fournir les services de sécurité désirés. Chaque mécanisme supporte deux modes d utilisation : le mode transport dans lequel on protège uniquement les données transportées et le mode tunnel qui protège en plus les entêtes IP Association de sécurité Le concept d association de sécurité (SA : Security Association) est fondamental à IPsec. En effet, une SA est une «connexion» simplexe qui offre des services de sécurité au trafic associé. Chaque mécanisme d IPSec (AH ou ESP) se sert d une SA pour fournir des services de sécurité. Si les deux protections AH et ESP sont appliquées à un trafic, alors deux SA doivent être créées et coordonnées pour effectuer la protection. Une SA est unidirectionnelle. Ainsi, pour protéger une communication bidirectionnelle entre deux systèmes, deux SA doivent être établies Bases de données Pour effectuer le traitement IPSec, une implémentation fait appel à trois bases de données : la base de données de politiques de sécurité (SPD : Security Policy Database), la base de données des associations de sécurité (SAD : Security Association Database), et la base de données d autorisation des pairs (PAD : Peer Authorization Database). La première indique les politiques qui déterminent le traitement à appliquer au trafic (entrant et sortant). En effet, en se fondant sur des champs de l entête IP appelés «sélecteurs», la SPD permet d associer le trafic IP à l une des trois actions : DISCARD, BYPASS ou PROTECT. Le premier choix se rapporte au trafic qui n est pas autorisé à traverser la frontière IPsec. Le deuxième choix est relatif au trafic autorisé à traverser cette frontière sans protection. La troisième action concerne le trafic qui nécessite une protection IPSec. Pour ce trafic, la SPD doit indiquer le mécanisme de sécurité à utiliser (AH ou ESP), le mode (transport ou tunnel), les options de services de sécurité, et les algorithmes cryptographiques à employer. La deuxième base, la SAD, est composée d un certain nombre d entrées où chacune définit les paramètres d une SA. Elle est consultée pour savoir comment traiter chaque paquet reçu ou à émettre. La troisième base, à savoir la PAD, fournit un lien entre la SPD et un protocole de gestion de SA tel que le protocole IKE (Internet Key Exchange). Chaque entrée de cette base correspond à un pair avec lequel l entité communiquera et indique le protocole d authentification employé (IKEv1, IKEv2 ou KINK), la méthode utilisée (certificats ou secrets pré-partagés) et les données d authentification (secret pré-partagé) Fonctionnement La gestion des SA et des clefs cryptographiques peut être manuelle ou automatisée. La gestion manuelle consiste à configurer manuellement chaque système afin de sécuriser les communications avec d autres systèmes. La gestion automatisée, via un protocole automatisé et standardisé, permet l utilisation des dispositifs de protection contre le rejeu, disponibles pour AH et ESP, et s adapte à la création des SA à la demande. Le protocole de gestion automatisé choisi par défaut avec IPSec est IKEv2 [KAU 05]. 31

51 Le traitement du trafic IP, réalisé par une implémentation IPSec, dépend de la nature du tarfic (sortant ou entrant), mais aussi des politiques de sécurité indiquées par la SPD. Figure 2-7 : Fonctionnement du protocole IPSec Trafic sortant : Si le paquet sortant correspond à une SA déjà créée, alors ce paquet est traité comme indiqué dans cette SA. Dans le cas où aucune SA ne correspond à ce paquet, une recherche dans la SPD est effectuée (Figure 2-7). Si le résultat de cette recherche indique un traitement de type DISCARD ou BYPASS, alors le paquet est traité en conséquence. Cependant, si le traitement indiqué par la SPD est PROTECT alors le mécanisme principal de gestion des SA et des clefs (par exemple, IKEv2) est appelé pour créer une SA. Trafic entrant : Pour le trafic adressé à cette entité, s il n est pas protégé avec IPSec, alors une recherche dans la SPD est effectuée afin de déterminer si l action est BYPASS ou DISCARD. S il s agit d un trafic protégé avec IPSec, alors il faut trouver la SA correspondante dans la SAD. Ensuite, le traitement IPSec spécifié par cette SA est appliqué avant de vérifier que le paquet correspond bien à cette SA. Pour le trafic non adressé à cette entité, la SPD est consultée afin de déterminer si l'action est DISCARD ou BYPASS. S il y a une correspondance, alors le paquet est traité comme l indique l entrée. Dans le cas contraire, il est jeté Les mécanismes d IPSec AH [KEN 05b] : utilisé en mode transport ou tunnel, il permet de fournir l intégrité, l authentification de l origine des données et la protection contre le rejeu. Pour assurer la protection, l entête AH se compose de champs tels que l index des paramètres de sécurité (SPI : Security Parameters Index) qui permet d associer le paquet IP à une SA, le numéro d ordre (SN : Sequence Number) ou numéro d ordre prolongé (ESN : Extended Sequence Number) qui assure la protection contre le rejeu et la valeur de contrôle d intégrité (ICV : Integrity Check Value). ESP [KEN 05c] : utilisé en mode transport ou tunnel, peut être employé pour fournir la confidentialité, l authentification de l origine des données, l intégrité et la protection contre le rejeu. Pour protéger les données, l entête ESP est composée d un certain nombre de champs comme le SPI, le numéro d ordre, le champ optionnel ICV ou encore les données utiles (Payload Data) dont la structure dépend du choix de l algorithme et du mode de cryptage. 32

52 Algorithmes cryptographyques Pour assurer l interopérabilité entre les différentes réalisations IPSec, ces dernières doivent implémenter un ou plusieurs algorithmes de sécurité en commun [SCH 05a]. Concernant le mécanisme AH, une implémentation doit supporter les algorithmes HMAC-SHA1-96 et peut implémenter AES- XCBC-MAC-96 et HMAC-MD5-96. Pour le mécanisme ESP, si des algorithmes de cryptage et d intégrité séparés sont utilisés, alors pour l intégrité une entité IPSec doit supporter les algorithmes NULL et HMAC-SHA1-96 et peut implémenter AES-XCBC-MAC-96 et HMAC-MD5-96, et pour le cryptage, elle doit supporter l utilisation des algorithmes NULL et TripleDES-CBC et peut permettre celle de AES- CBC, AES-CTR et DES-CBC. Pour ESP en mode combiné, il n y a aucun algorithme suggéré ou exigé actuellement. Cependant l algorithme AES-CCM peut être d un grand intérêt dans un futur proche. Le protocole IPSec permet de protéger le trafic au niveau IP, tout en étant transparent vis à vis des utilisateurs et des applications. De plus, il peut fonctionner sur n importe quel protocole de transport (TCP ou UDP). Quant à TLS, il intervient au niveau de la couche «Transport» d une manière transparente, mais il est toujours associé au protocole TCP Le protocole TLS Le protocole TLS (Transport Layer Security) version 1.1 [DIE 06] est basé sur le protocole SSL (Secure Sockets Layer) version 3.0 publié par Netscape. L objectif du protocole TLS est de fournir des services de sécurité (confidentialité et intégrité) aux données échangées entre deux applications communicantes. Un avantage du protocole TLS est qu il est transparent vis-à-vis des applications Architecture du protocole TLS Afin de sécuriser une communication de bout en bout, TLS se sert d un protocole de transport fiable, à savoir TCP. Le protocole TLS se compose de deux couches (Figure 2-8) : une couche inférieure formée du protocole d enregistrement TLS et une couche supérieure composée de trois protocoles (protocole de poignée de main, protocole d alerte et protocole de changement de spécification de chiffrement). Le protocole d enregistrement TLS permet de fournir des services de sécurité aux différents protocoles de la couche supérieure, à savoir les trois autres protocoles de TLS et le protocole d application. TLS peut être utilisé avec plusieurs protocoles d application tels que HTTP, LDAP, IMAP, POP3, etc. Mais, il est souvent associé au protocole HTTP afin de sécuriser des interactions de type client/serveur. Figure 2-8 : Couches protocolaires de TLS Afin d être efficace, le protocole TLS vise à réduire le nombre de négociations des paramètres cryptographiques en se fondant sur deux concepts [DIE 06]: 33

53 Connexion : C est une relation entre deux extrémités d une communication. Elle constitue l environnement de fonctionnement du protocole d enregistrement TLS. Une connexion a toujours quatre états : état actuel en lecture, état actuel en écriture, état transitoire en lecture et état transitoire en écriture. On associe à chaque état un certain nombre de paramètres cryptographiques tels que la méthode de compression ou encore l algorithme de chiffrement. Les états actuels peuvent être remplacés par les états transitoires en faisant appel au protocole de changement de spécification de chiffrement. Chaque connexion est associée à une session. Session : C est une association entre un client et un serveur. Elle est créée grâce au protocole de poignée de main. En effet, ce dernier permet de négocier et mettre en place les paramètres cryptographiques d une session. Ces paramètres seront utilisés par la suite dans la sécurisation des échanges. Plusieurs connexions peuvent être instanciées à partir d une même session. Cela permet à TLS d éviter une coûteuse négociation de nouveaux paramètres de sécurité pour chaque connexion Les protocoles de TLS Dans cette section, nous décrivons les deux couches protocolaires composant le protocole TLS. Ainsi, la couche d enregistrement (TLS Record Layer) permet de fournir des services de sécurité. Au dessus, les protocoles de poignée de main (TLS Handshaking Protocols) sont employés pour permettre à des pairs de négocier les paramètres de sécurité (algorithmes et clés), instancier une connexion, s authentifier et reporter les erreurs. Protocole d enregistrement TLS [DIE 06] : Reposant sur TCP, la couche d enregistrement permet de fournir la confidentialité et l intégrité aux protocoles du niveau supérieur. La confidentialité des données transportées est offerte grâce à l utilisation de la cryptographie symétrique pour le chiffrement de ces données (DES, RC4, etc.). Les clés pour ce chiffrement sont produites pour chaque connexion et sont basées sur un secret négocié grâce au protocole de poignée de main. Le protocole d enregistrement TLS peut également être employé sans chiffrement. Quand à l intégrité, elle est assurée pour le transport de messages à l aide d un code MAC. Les fonctions de hachage (SHA, MD5, etc.) sont utilisées pour le calcul du code MAC. Le protocole d enregistrement TLS peut être employé sans calcul du code MAC. Le traitement des donnés au niveau de cette couche comprend plusieurs étapes. Quand la couche d enregistrement reçoit les données des couches plus hautes, elle les fragmente en bloc de taille 2^14 octets. Ces blocs sont compressés (option) en utilisant l algorithme de compression. Ensuite, les données sont protégées en procédant au calcul du code MAC (0, 16 ou 20 octets) et au chiffrement des données. Pour cela, un chiffrement par flot (RC4) ou encore un chiffrement par bloc (RC2, DES, ou AES) peut être employé. Notons que le code MAC comprend un numéro de séquence qui permettra de détecter la suppression, l ajout ou la répétition de messages. Dans l autre sens, les données reçues sont déchiffrées, vérifiées, décompressées, rassemblées, puis transmises aux protocoles de niveau plus haut. Protocole de changement de spécification [DIE 06] : Le rôle de ce protocole est de signaler des transitions dans les stratégies de chiffrement. Il se compose d'un message constitué d un simple octet de valeur 1. Il est utilisé par les deux extrémités d une connexion (client et serveur) pour informer le récepteur que les messages suivants seront protégés sous la spécification de chiffrement (CipherSpec) et les clés nouvellement négociées. Lors de la réception de ce message, la mise à jour de l état actuel, en utilisant 34

54 l état transitoire, est assurée par la couche d enregistrement qui copie l'état transitoire (lecture) dans l'état actuel (lecture). Du coté expéditeur, juste après l envoi de ce message, la couche d enregistrement copie l'état transitoire (écriture) dans l état actuel (écriture). Protocole d alerte [DIE 06] : La gestion d'erreur dans TLS est très simple. Quand une erreur est détectée (unexpected_message, decryption_failed, etc), la partie qui détecte cette erreur envoie un message à l'autre partie. Ces messages informent sur le niveau de l alerte (warning ou fatal) et donnent une description de celle-ci. Les messages avec un niveau «fatal» causent l'arrêt immédiat de la connexion. Dans ce cas, d'autres connexions correspondant à la session peuvent continuer, mais l identificateur de session est invalidé, empêchant la session échouée d'être utilisée pour établir de nouvelles connexions. Protocole de poignée de main [DIE 06] : Le protocole de poignée de main est employé par les deux extrémités d une communication afin de se mettre d accord sur la version du protocole, choisir les algorithmes cryptographiques, s authentifier (optionnel), et utiliser des techniques de chiffrement à clé publique afin de produire des secrets partagés. Les paramètres d une session négociés via ce protocole seront utilisés dans la création des paramètres d une connexion qui seront à leur tour employés par le protocole d enregistrement dans la protection des communications. Afin de réaliser ces tâches, le protocole de poignée de main fait appel à un certain nombre de messages tels que les messages «Hello» ou encore les messages d échange de clés (Figure 2-9). Comme les messages d alerte et les messages de changement de spécification de chiffrement, ces messages sont chiffrés et compressés comme l indique l état actuel de la connexion. Le fonctionnement du protocole de poignée de main peut être divisé en quatre phases : - Phase 1 (établissement des dispositifs de sécurité) : Le client envoie un message ClientHello auquel le serveur répond avec un message ServerHello. Cet échange permet de se mettre d accord sur : la version du protocole, l identificateur de session, la suite de chiffrement, et la méthode de compression. De plus, deux valeurs aléatoires sont produites et échangées qui serviront dans le calcul du secret maître. - Phase 2 (authentification de serveur et échange de clés) : S il doit être authentifié, le serveur envoie son certificat (Certificate). Ensuite, il peut envoyer un message d'échange de clé (ServerKeyExchange). Une fois le serveur authentifié, il peut demander au client son certificat (CertificateRequest). Puis, il envoie un message ServerHelloDone, indiquant la fin de la phase «Hello Messages». - Phase 3 (authentification de client et échange de clés) : Le client envoie son certificat (Certificate) au serveur si ce dernier le lui a demandé. Ensuite, le client envoie son message d'échange de clé (ClientKeyExchange). Si le client a envoyé un certificat avec des capacités de signature, un message de vérification de certificat signé numériquement (CertificateVerify) est envoyé pour vérifier explicitement le certificat. - Phase 4 (Fin) : Le client envoi un message de changement de spécification de chiffrement (ChangeCipherSpec). Ensuite, il copie la spécification de chiffrement transitoire dans la spécification de chiffrement actuelle, avant d envoyer un message Finished avec les nouveaux algorithmes, clé, et secrets. Le serveur répond en envoyant son propre message de changement de spécification de chiffrement (ChangeCipherSpec), transfère la spécification transitoire dans la spécification actuelle, et envoie son message Finished sous la nouvelle spécification de chiffrement. 35

55 Figure 2-9 : Flux de messages échangés lors d une poignée de main TLS Une fois la poignée de main terminée, le client et le serveur peuvent échanger des données de la couche application. Les messages échangés entre applications sont traités par la couche d enregistrement en utilisant l état actuel de la connexion Opérations cryptographiques Afin de protéger les communications, le protocole d enregistrement nécessite la spécification d'une suite d algorithmes, un secret maître, et des valeurs aléatoires (client et serveur). L authentification, le chiffrement, et les algorithmes de calcul du code MAC sont déterminés par la suite cryptographique choisie par le serveur et indiquée dans son message «Hello». L'algorithme de compression est négocié dans les messages «Hello», et les valeurs aléatoires sont échangées également dans les messages «Hello». Ainsi, il ne reste que le calcul du secret maître. Calcul du secret maître : L algorithme utilisé dans le calcul du secret maître à partir du secret pré-maître et des valeurs aléatoires est le même, quelque soit la méthode utilisée dans l échange de clés (RSA ou Diffie-Hellman). Quand RSA est utilisé pour l authentification du serveur et l échange de clés, le secret pré-maître est produit par le client, chiffré avec la clé publique du serveur, et envoyé au serveur. Le serveur utilise sa clé privée pour déchiffrer le secret pré-maître. Les deux parties convertissent alors le secret pré-maître en un secret maître. Quand Diffie-Hellman est utilisé dans l échange de clés, la clé négociée est employée comme secret pré-maître, et est convertie en secret maître. 36

56 HMAC et la fonction pseudo-aléatoire : Le traitement du protocole TLS nécessite un algorithme pour le calcul du code MAC. Dans cette opération, on utilise la construction HMAC qui peut être utilisée avec différents algorithmes de hachage : MD5 et SHA1 (HMAC-MD5 et HMAC-SHA). La fonction pseudo-aléatoire (PRF : Pseudo Random Function) est utilisée dans la génération des clés à partir du secret maitre et des valeurs aléatoires. Exemple d une suite de chiffrement : Une application conforme au protocole TLS doit implémenter un certain nombre de suites cryptographiques. Ceci permet une interopérabilité entre les deux extrémités d une communication. RSA_RC4_128_MD5 est une suite de chiffrement qui indique l utilisation du protocole TLS avec l algorithme RSA dans l opération à clé publique, l algorithme RC4 avec une clé de 128 bits dans le chiffrement symétrique et MD5 comme algorithme de hashage permettant la vérification des enregistrements TLS. Le protocole TLS est l un des protocoles les plus utilisés dans la sécurisation des communications. C est un protocole transparent par rapport aux applications, qui est surtout utilisé dans la sécurisation des services comme le web et l (IMAP, POP). Cependant, TLS repose sur une couche de «Transport» fiable comme TCP. Il ne peut donc pas être utilisé pour sécuriser les trafics de type datagramme. Ces dernières années, un grand nombre de services utilisant le protocole de transport UDP a été développé. Parmi ces services, nous trouvons des services qui se basent sur le modèle client/serveur (streaming audio/vidéo, ToIP, jeux en ligne, etc.) qu on préfère sécuriser au niveau de la couche «Transport». Ainsi, afin de permettre la protection des services basés sur UDP au niveau de la couche «Transport» du modèle TCP/IP, une adaptation de TLS pour le trafic UDP a été spécifiée ; il s agit du protocole DTLS Le protocole DTLS Le protocole DTLS (Datagram Transport Layer Security) [RES 06] se base sur le protocole TLS afin d offrir les mêmes garanties de sécurité aux communications de type client/serveur fondées sur UDP. La philosophie de la conception de DTLS est de construire «TLS sur UDP». Le protocole TLS ne peut pas être utilisé dans la sécurisation d un trafic UDP car les datagrammes peuvent être perdus ou désordonnés et TLS ne possède aucun mécanisme interne qui lui permet de résoudre ce problème de non fiabilité. Ainsi, l objectif de DTLS est de préserver la fiabilité sur laquelle se fonde la sécurité TLS afin de surmonter les problèmes découlant de la non-fiabilité d UDP, tout en opérant un minimum de changement sur TLS. Les problèmes créés par la non-fiabilité sont les suivants : En cas de chiffrement, les enregistrements (paquets) ne sont pas automatiquement décryptés. Si l enregistrement N n est pas reçu, l enregistrement N+1 ne peut pas être décrypté car le contexte cryptographique est chainé entre les enregistrements, La poignée de main de TLS, qui permet de se mettre d accord sur les paramètres de sécurité, suppose que les messages de cette phase sont échangés de manière fiable. Le protocole DTLS a un fonctionnement très semblable à celui de TLS. En effet, DTLS réutilise presque tous les éléments et les mécanismes du protocole TLS, mais il prévoit un certain nombre de changements lui permettant de fonctionner correctement avec le transport basé sur les datagrammes. Le premier changement porte sur l ajout explicite d un numéro de séquence aux enregistrements DTLS afin 37

57 de permettre au récepteur de vérifier correctement le code MAC. Ensuite, un autre champ nommé «epoch number» a été ajouté. Ce nombre, qui est incrémenté à chaque changement de suite de chiffrement, est utilisé pour permettre d utiliser la bonne suite de chiffrement avec le bon enregistrement DTLS. Ainsi, il permet de distinguer les enregistrements ayant le même numéro de séquence mais relatif à des suites de chiffrement différentes. Ensuite, étant donné que la poignée de main ne supporte pas la perte ou le désordre des paquets, DTLS utilise un temporisateur de retransmission pour résoudre le problème de perte de paquet, et attribue un numéro de séquence spécifique à chaque message de la poignée de main afin de pouvoir traiter les messages reçus dans le bon ordre. Puis, vis-à-vis de la très grande taille des messages de poignée de main (jusqu à 2^24 1 octets), les récepteurs de ces messages doivent être capables de réassembler les fragments et d obtenir le message original qui a été fragmenté en plusieurs datagrammes UDP (taille maximale est de 1500 octets). Enfin DTLS offre un service optimal de détection de rejeu de manière optionnelle car la duplication des paquets n est pas toujours malicieuse (erreur de routage). Ainsi, le champ numéro de séquence, ajouté au format d un enregistrement DTLS, permet de se protéger contre le rejeu. Cette protection se fait grâce à un mécanisme de fenêtre de rejeu (taille minimale de 32 et taille préférée de 64) qui est maintenue afin de vérifier le numéro de séquence. Ainsi, les enregistrements qui sont trop vieux pour correspondre à cette fenêtre ou ceux qui sont déjà reçus (duplication) sont tout simplement rejetés La sécurité dans les réseaux d accès Etant donné que les réseaux d accès peuvent implémenter des technologies différentes, la sécurité d un réseau d accès peut être offerte grâce à des mécanismes spécifiques à la technologie implémentée. Aujourd hui, il existe plusieurs standards et mécanismes permettant de sécuriser les réseaux d accès. Cependant, la problématique de sécurité a été abordée de manières différentes suivant le type du réseau d accès [BOU 05]. En effet, pour les réseaux mobiles de deuxième et troisième génération, le principal service de sécurité considéré était l authentification. Quand aux réseaux Wi-Fi, tous les services de sécurité ont été considérés et plusieurs standards de sécurisation ont été développés. Concernant le WiMax qui constitue une technologie émergeante avec un déploiement qui n est pas aussi large que celui des réseaux Wi-Fi, la problématique de sécurité n a pas encore été étudiée en détail. Dans cette section, nous rappelons, dans un premier temps, les mécanismes de sécurité mis en œuvre par les réseaux mobiles de deuxième et troisième génération. Dans un second temps, nous décrivons les différents standards de sécurité élaborés dans le but de sécuriser les réseaux d accès sans fil (Wi-Fi) La sécurité dans les réseaux mobiles La sécurité du GSM La sécurité du GSM [QUI 04] vise à protéger l anonymat (anonymity) et la vie privée (privacy) des utilisateurs durant les communications. Elle a également pour objectif d assurer que les services soient facturés aux clients qui en ont bénéficiés. Ainsi, le principal service de sécurité dans les réseaux GSM est de pouvoir identifier et authentifier les utilisateurs. Pour cela, les réseaux GSM utilisent un système d authentification basé sur une méthode de défi/réponse. D abord, la station de base envoie un défi de 128 bits au téléphone de l utilisateur. Ensuite, 38

58 la carte SIM du téléphone utilise l algorithme d authentification A3 et sa clé d authentification individuelle afin de générer une réponse signée qu elle retourne à la station de base. Enfin, cette dernière peut vérifier si la valeur retournée par le téléphone correspond ou non à la valeur attendue. S il y a correspondance alors le téléphone est authentifié et peut bénéficier des services dont il a droit La sécurité de l UMTS Etant donné que les problèmes de sécurité rencontrés dans l UMTS sont très semblables à ceux considérés par le GSM, la sécurité de l UMTS [BOM 02] a été fondée sur celle du GSM. Ainsi, la sécurité de l UMTS permet de maximiser la compatibilité entre ces deux types de réseaux mobiles. Mais, l UMTS fournit d autres services de sécurité pour les réseaux d accès mobiles de troisième génération. La sécurité d un réseau d accès de type UMTS implique essentiellement la fourniture d un accès sécurisé aux services UMTS pour les utilisateurs et la protection de ce réseau contre les attaques qui peuvent le menacer. Contrairement au GSM, qui nécessite l authentification des utilisateurs auprès de la station de base, l UMTS fait appel à une authentification mutuelle qui implique que l utilisateur mobile et la station de base doivent s authentifier mutuellement afin de se protéger contre les attaques par fausses stations de base. Cette authentification mutuelle utilise la méthode de défi/réponse pour l authentification de l utilisateur et un mécanisme de jeton de sécurité pour l authentification du réseau. De plus, l UMTS offre un nouveau mécanisme pour la protection de l intégrité des messages de signalisation échangés entre l utilisateur mobile et le contrôleur du réseau RNC (Radio Network Controller). Ces messages de signalisation permettent à l utilisateur et au réseau de négocier et de se mettre d accord sur les algorithmes d intégrité et de chiffrement qui permettent de protéger les communications des utilisateurs mobiles La sécurité dans les réseaux Wi-Fi Un réseau d accès sans fil est composé d un point d accès et d un ensemble de terminaux sans fil qui y sont connectés. Les données transmises sur un réseau sans fil circulent en clair et dans toutes les directions. Ainsi, un utilisateur malveillant peut récupérer les informations d accès et se connecter au réseau pour écouter n importe quel trafic circulant dans ce réseau. Pour surmonter ce genre de problème, plusieurs mécanismes de sécurité des réseaux sans fil ont été définis. Dans cette section, nous décrivons les trois mécanismes proposés pour la mise en œuvre de la sécurité dans les réseaux d accès de type Wi-Fi Le WEP (Wired Equivalent Privacy) Le protocole WEP [CUR 06] a été créé afin de satisfaire les besoins des réseaux Wi-Fi en matière de contrôle d accès, d authentification, d intégrité et de confidentialité. Le contrôle d accès, permettant d interdire l accès aux utilisateurs non autorisés, est réalisé grâce à deux fonctions : l authentification qui permet de vérifier les identités des utilisateurs et l autorisation qui permet d accorder les autorisations d accès. Dans les réseaux Wi-Fi, le contrôle d accès est réalisé grâce à : l identifiant du réseau (SSID : Service Set ID) qui doit être connu par tout utilisateur voulant accéder à un réseau Wi-Fi, ou encore la liste de contrôle d accès (ACL : Access Control List) qui permet à un point d accès de n autoriser l accès qu aux terminaux ayant une adresse MAC dans son ACL. L authentification offerte par le WEP peut être réalisée suivant l un des deux modes offerts : le mode «Open System Authentication» ou le mode «Shared Key Authentication». Le mode «Open System 39

59 Authentication» est le mode par défaut qui ne comporte aucune réelle authentification, puisque n importe quel terminal se connectant au réseau Wi-Fi est authentifié. Quant au mode «Shared Key Authentication», il offre un meilleur niveau de sécurité en se fondant sur un partage de clé secrète entre le point d accès et le terminal sans fil. Ce partage est, lui-même, basé sur une méthode de défi/réponse. L intégrité des données est réalisée grâce au calcul d une valeur de checksum ICV (Integrity Check Value) de 32 bits. La valeur ICV est un CRC (Cyclic Redundancy Check) calculé sur l ensemble du bloc de données et ajouté à ce bloc afin d être chiffré avec ces données. La confidentialité des données transmises sur les réseaux Wi-Fi est réalisée grâce à un chiffrement fondé sur l algorithme de chiffrement symétrique par flux RC4 utilisant une clé secrète de 40 ou 104 bits combinée à un vecteur d initialisation de 24 bits. Même si le protocole WEP a été défini afin de pallier aux failles de sécurité des réseaux Wi-Fi, ce protocole présente des faiblesses qui ont fait de lui un protocole non fiable pour gérer la confidentialité, l authentification est l intégrité des données. La faiblesse la plus importante est liée à l algorithme RC4. En effet, la clé utilisée, qui avait une taille de 40 bits et a évolué vers 104 bits avec le standard WEP 2, ne peut toujours pas résister aux attaques par dictionnaire. De plus, la gestion des clés n est pas automatique, mais statique avec une seule clé secrète partagée par tous les terminaux du réseau et le point d accès. Une autre faiblesse du WEP provient de l utilisation du CRC pour le contrôle d intégrité. En effet, un message protégé avec un CRC peut être modifié par un tiers malveillant sans être détecté par le CRC. Le CRC est prévu pour faire de la détection d erreur et non pas pour le contrôle d intégrité qui doit plutôt reposer sur des fonctions de hachage permettant de détecter la moindre modification de données. A tout cela s ajoute la faiblesse de l authentification fondée sur le mécanisme de défi/réponse permettant de vérifier si un terminal connaît bien la clé WEP. En effet, le point d accès envoie en clair un message à un terminal qui le chiffre avec sa clé secrète WEP et le renvoie au point d accès. Ensuite, ce dernier vérifie si le message chiffré correspond bien au message attendu. Ainsi, ce mécanisme permet de récolter des pairs de messages clairs et chiffrés qui facilitent la déduction de la clé secrète. Il existe, à présent, des solutions offrant une meilleure protection; il s agit des technologies WPA et WPA Le WPA (Wi-Fi Protected Access) Le protocole WPA [CUR 06] a été défini afin de sécuriser le Wi-Fi et garder un maximum de compatibilité avec les équipements sans fil existants. Il permet d assurer le contrôle d accès, l authentification, l intégrité et la confidentialité. Le protocole WPA utilise le standard d authentification IEEE 802.1x [IEE 04a] afin de contrôler l accès aux réseaux sans fil. En effet, le 802.1x permet d interdire l accès au réseau pour les utilisateurs non authentifiés. L architecture de cette norme (802.1x) implique trois entités : l utilisateur à authentifier (supplicant), le point d accès au réseau (authenticator) et un serveur d authentification (généralement un serveur RADIUS [RIN 00]). Tant qu il n est pas authentifié, l utilisateur ne peut pas accéder au réseau : seuls les échanges liés au processus d authentification sont relayés vers le serveur d authentification par le point d accès. Ainsi, le point d accès agit comme un simple relais passif durant la phase d authentification, 40

60 mais il laisse passer le trafic des communications une fois la procédure d authentification réalisée avec succès. Il est important de noter que le standard IEEE 802.1x réalise les authentifications en utilisant le protocole EAP (Extensible Authentication Protocol) [BLU 98]. Ce dernier définit quatre classes de messages : requête, réponse, succès et échec. L ordre dans lequel ces messages sont échangés ne dépend que de la méthode d authentification choisie : EAP-TLS, EAP-TTLS (Tunneled TLS), EAP-PEAP (Protected EAP) et LEAP (Lightweight EAP). Notons également qu il existe une autre méthode d authentification qui a été créée pour les réseaux sans fil des particuliers qui ne disposent pas forcément d un serveur RADIUS. Cette méthode s appelle WPA-PSK (Pre-Shared Key) et a le même principe que le WEP sauf qu elle utilise une clé de 256 bits. Pour assurer la confidentialité et l intégrité des données échangées sur un réseau Wi-Fi, le WPA utilise le protocole TKIP (Temporal Key Integrity Protocol). Ce protocole assure le chiffrement des données en utilisant l algorithme de chiffrement RC4 avec une clé de 128 bits. Il protège également l intégrité des données en ajoutant à chaque SDU (Service Data Unit) MAC une signature de 64 bits, appelée MIC (Message Integrity Code). La deuxième génération de la sécurité du Wi-Fi réalisée avec WPA permet d améliorer la sécurité de ce type de réseau. Cependant, le niveau de sécurité n est pas suffisamment robuste parce que WPA se base toujours sur l algorithme RC4. Cette sécurité va énormément évoluer avec la définition de la troisième génération de la sécurité du Wi-Fi, à savoir le WPA Le WPA2 (ou IEEE i) Le standard IEEE i [IEE 04b] se base sur la séparation entre l authentification de l utilisateur et le chiffrement/contrôle d intégrité des messages. De plus, cette norme définit deux architectures pour les réseaux sans fil. D abord, l architecture temporaire TSN (Transition Security Network) qui supporte les architectures antérieures, en particulier le WEP et le WPA. Cette architecture a été définie afin de permettre aux équipements RSN et pré-rsn de coexister, permettant ainsi aux utilisateurs de mettre à jour leurs équipements. Ensuite, la nouvelle architecture pour les réseaux sans fil, appelée RSN (Robust Security Network), utilise : le protocole 802.1x pour l authentification, des mécanismes de distribution de clés, et de nouveaux protocoles pour l intégrité et le chiffrement. A titre d exemple, en plus de TKIP, WPA2 définit l utilisation du protocole CCMP (Counter-mode/Cipher block chaining Message authentication code Protocol) qui utilise l algorithme de chiffrement AES en mode CCM et une signature MIC basée sur CBC-MAC. Dans le cadre de l architecture RSN, le protocole WPA2 introduit la notion d association robuste entre deux éléments d un réseau RSN. Cette association, appelée RSNA (RSN Association), définit un contexte de communication sécurisé qui doit s effectuer en quatre phases : Phase de négociation pendant laquelle les entités se mettent d accord sur les mécanismes de sécurité qu elles vont utiliser ; Phase d authentification au cours de laquelle une authentification est réalisée en utilisant le protocole IEEE i ; Phase de dérivation et de distribution de clés nécessaire à la protection des messages; 41

61 Phase de protection de l intégrité et de la confidentialité en procédant au chiffrement et au calcul du MIC. Il est clair que le protocole WEP ne garantit pas une sécurité suffisante pour les réseaux Wi-Fi. Cependant, le WPA représente une solution de sécurité plus robuste. Cette solution est utilisée, essentiellement, lorsque les équipements ne supportent pas CCMP (c est-à-dire le chiffrement AES supporté par les équipements RSN). Mais, la meilleure solution pour sécuriser les réseaux Wi-Fi reste l utilisation du standard IEEE i avec le protocole CCMP pour offrir l intégrité et la confidentialité La sécurité dans les réseaux NGN Dans le contexte des architectures NGN, le besoin de fournir des services de sécurité est toujours d une grande importance. L architecture des réseaux de nouvelle génération est caractérisée par un découpage spatial où on peut distinguer essentiellement deux parties : le réseau de cœur fondé sur IP et les réseaux d accès implémentant différentes technologies fondées souvent sur des média ouverts. De ce fait, le transport des services sur les réseaux de nouvelle génération peut nécessiter la protection contre les différentes menaces en offrant des services de sécurité comme l authentification, l intégrité, la confidentialité, etc. Etant donné que le réseau de cœur est fondé sur IP, les mécanismes de sécurité classiques comme IPSec, TLS ou DTLS ont toujours leur place dans les architectures NGN. Par ailleurs, les réseaux d accès peuvent offrir des services de sécurité en mettant en place leurs propres mécanismes de sécurité. Ainsi, dans un environnement NGN, la sécurité du transport d un service de bout en bout peut être assurée : grâce à la mise en place d une sécurité de bout en bout en utilisant un seul mécanisme comme IPSec ou TLS/DTLS, ou encore en utilisant différents mécanismes de sécurité configurés en série le long du chemin de transport de données ; par exemple IPSec dans le cœur du réseau et WPA2 au niveau du réseau d accès. Notons que la sécurité peut être assurée de bout en bout grâce à IPSec ou TLS/DTLS malgré l utilisation d un autre mécanisme de sécurité au niveau du réseau d accès comme, par exemple, le protocole WEP, WPA ou WPA2. Dans ce dernier cas de figure, on parle d un empilement de mécanismes de sécurité au niveau du réseau d accès ; par exemple IPSec sur WPA Résumé La sécurité des services offerts dans un environnement NGN peut être assurée en utilisant plusieurs protocoles et mécanismes. Cette sécurité peut être offerte au niveau d une couche du modèle TCP/IP («Application», «Transport», «Réseau», ou même «Liaison de données») ou même au niveau de plusieurs couches à la fois (par exemple TLS sur IPSec). Les protocoles les plus utilisés dans la sécurisation des services sont IPSec et TLS/DTLS parce qu il s agit de protocoles robustes et fiables qui sont transparents vis-à-vis du type du service sécurisé. Malgré la grande similarité entre les services de sécurité offerts par IPSec et TLS/DTLS, IPsec peut être considéré comme une solution universelle. En effet, IPSec peut fonctionner avec n importe quelle application telles que le web, le mail, le transfert de fichier, la téléphonie sur IP et d autres applications client/serveur. Il offre, également, plus de sécurité ; d une part, il permet de sécuriser plus d informations que TLS ou DTLS, d autre part, il utilise des techniques tels que les tunnels qui permettent de garder complètement secrètes des informations telles que l identité de l expéditeur et du récepteur. Notons, également, qu il existe d autres mécanismes permettant 42

62 de protéger les communications au niveau applicatif. Il s agit de mécanismes spécifiques aux applications qui sont intégrés dans l implémentation de ces applications. Garantir un certain niveau de sécurité pour les services offerts par les réseaux NGN constitue l une des principales préoccupations des fournisseurs de services. En plus de la QoS et de la sécurité, la garantie de la mobilité des consommateurs de services fait partie des priorités des architectures NGN. 2.6 La mobilité Comme nous l avons mentionné dans la première partie de ce chapitre, le développement des réseaux sans fil et la diversité des réseaux d accès qui sont actuellement déployés un peu partout, a habitué les différents utilisateurs à la mobilité. L objectif de la mobilité est de permettre à un utilisateur d être connecté de n importe où, avec n importe quel type de terminal. Par définition, un utilisateur mobile est un utilisateur qui est en déplacement, d où la possibilité de changer de réseau d accès. La mobilité des utilisateurs peut être assurée à différents niveaux de la pile protocolaire TCP/IP. Elle peut être fournie au niveau de : la couche application, la couche «Transport», la couche «Réseau» ou encore la couche «Liaison de données». En effet, plusieurs organismes se sont intéressés à la mobilité ; ce qui a permis de définir plusieurs standards et protocoles. Parmi ces standards, nous trouvons le protocole MIP (Mobile IP ou IP mobility) qui représente l un des protocoles les plus connus dans la gestion de la mobilité des utilisateurs. De plus, nous avons le standard IEEE qui propose de gérer la mobilité au niveau des couches basses en accélérant la procédure de changement de réseau. Il existe, également, d autres architectures permettant la gestion de la mobilité à d autres niveaux comme le niveau application (une solution basée sur SIP) ou le niveau «Transport» (Mobile TCP, Mobile UDP, etc.). Dans cette partie, nous rappelons, tout d abord, l architecture du protocole MIP. Ensuite, nous décrivons quelques architectures qui proposent de gérer la mobilité au niveau «Transport» et «Application». Enfin, nous présentons le nouveau standard IEEE qui permet d accélérer efficacement les changements de réseaux en opérant au niveau des couches basses (essentiellement la couche 2 du modèle OSI) Mobilité au niveau «Réseau» La mobilité des utilisateurs peut poser quelques problèmes qui empêchent d assurer la continuité de service. En effet, un terminal qui est connecté à un réseau, doit avoir une adresse IP qui ne dépend que de ce réseau. Ainsi, en changeant de réseau d accès l adresse IP de ce terminal doit changer et cette connexion est donc forcément coupée. Afin de résoudre ce problème un groupe de travail de l IETF a été chargé de proposer une solution pour gérer la mobilité dans les environnements fondés sur IP. La solution proposée par ce groupe de travail est le protocole IP Mobile (MIP : Mobile IP) qui permet aux terminaux mobiles de changer de point d accès à l Internet sans changer d adresse IP. Ainsi la gestion de la mobilité au niveau «Réseau» est basée sur le maintien d une adresse IP permanente. Le protocole IP Mobile a été créé afin de répondre à des besoins bien précis : Un mobile doit être capable de communiquer avec d autres équipements après avoir changé son point d attachement sur l Internet ; 43

63 Un mobile doit être capable de communiquer grâce uniquement à son adresse IP principale, indépendamment de sa localisation sur l Internet ; Un mobile doit pouvoir communiquer avec un autre équipement, sans que celui-ci implémente le protocole Mobile IP Fonctionnement de MIP L objectif du protocole MIP est de rendre joignable à tout moment un nœud mobile. Ce nœud mobile peut changer de point d attachement sur Internet. Ainsi, pour maintenir les communications en cours, l idée est de donner la possibilité à un nœud mobile d utiliser deux adresses IP : une adresse principale qui permet d identifier le mobile de manière unique, quelque soit le réseau auquel il est connecté, et une adresse mobile qui change à chaque point de connexion. Le fonctionnement du protocole IP Mobile implique les acteurs suivants [PER 02] : Le terminal mobile (MN : Mobile Node), celui-ci peut changer de point d attachement ; Le correspondant qui dialogue avec le terminal mobile, il peut être fixe ou mobile ; Un routeur situé dans le réseau du mobile appelé agent mère (HA : Home Agent); Un routeur situé dans le réseau visité par le mobile, appelé agent relais (FA : Foreign Agent), il est utilisé uniquement dans le cas de la mobilité IPv4. Le fonctionnement du protocole IP Mobile est le suivant (Figure 2-10); l agent mère et l agent relais émettent périodiquement des messages d avertissement (Advertisement) sur l adresse de diffusion du réseau où ils se trouvent. Ce mécanisme de découverte d adresse est fondé sur le standard «Router Advertisement» spécifié dans [DEE 91]. Lorsque le mobile reçoit le message d avertissement, il va l analyser afin d identifier le réseau auquel il appartient : son réseau d origine ou un réseau visité. Dans le premier cas, le mobile peut se comporter comme un terminal fixe. Dans l autre cas, le mobile est sur un réseau visité et doit obtenir une adresse temporaire. Cette adresse sera, soit l adresse de l agent relais obtenue à partir de son message d avertissement, soit une adresse attribuée au mobile lui-même grâce, par exemple, à l utilisation du protocole DHCP (Dynamic Host Configuration Protocol) [DRO 97]. Ensuite, le mobile procède à l enregistrement de cette nouvelle adresse auprès de l agent mère. Figure 2-10 : Principe du protocole MIP 44

64 Quand le terminal mobile envoie sa requête vers le correspondant, le champ adresse IP source de l entête du paquet IP transmis ne contient pas l adresse IP courante de ce terminal, mais plutôt l adresse de son agent mère. Ainsi, les paquets de la réponse qui doivent arriver au mobile sont envoyés à destination de l agent mère. Celui-ci va encapsuler ces paquets dans d autres paquets qui auront pour destination l adresse temporaire du mobile. Si l adresse temporaire est celle de l agent relais, celui-ci sera chargé de délivrer les paquets au mobile. Cette solution a l avantage d éviter d allouer une nouvelle adresse IP pour le mobile grâce au rôle de l intermédiaire que joue l agent relais. Dans le cas où l adresse temporaire est celle du mobile lui-même, les paquets sont directement adressés à ce dernier. Cette solution à l inconvénient de nécessiter la réservation d un pool d adresses pour la gestion des mobiles dans un réseau. Dans les deux solutions proposées par le protocole MIP, l agent mère a besoin d encapsuler les paquets interceptés afin de les rediriger vers le nouveau réseau visité par le mobile. On parle de la création d un tunnel entre l agent mère et l agent relais ou le mobile Le protocole MIPv6 Contrairement au protocole Mobile IPv4, le protocole Mobile IPv6 fait parti intégrante du protocole IPv6. L infrastructure ainsi que le fonctionnement du protocole MIPv6 sont très semblables à ceux de MIPv4. Il existe, cependant, de nombreuses différences entre MIPv4 et MIPv6. Dans ce qui suit, nous ne citons que les différences les plus importantes. Le fonctionnement de MIPv4 présente le problème suivant. Un correspondant envoie toujours un paquet à destination du nœud mobile vers l agent mère de ce nœud, et ce dernier le renvoie vers l agent relais. La spécification du protocole MIPv6 permet de pallier à ce problème en se passant de l agent relais. Ainsi, MIPv6 se caractérise par l absence d agent relais. En effet, les paquets IPv6 sont envoyés directement vers le nœud mobile qui possède toujours une adresse locale attribuée d une manière unique et temporaire. Cette adresse permet au nœud mobile de demeurer joignable à tout instant, et peut être attribuée grâce au protocole DHCPv6 [DRO 03] ou en utilisant un mécanisme d auto-configuration d adresses. La deuxième caractéristique qui différencie MIPv6 de MIPv4 est l optimisation du routage qui fait parti intégrante de MIPv6, alors qu elle ne forme qu une extension dans MIPv4. Cette optimisation est réalisée grâce à un système de correspondance d adresses qui permet à un nœud mobile de s enregistrer auprès de ses correspondants. En effet, le correspondant reçoit de l agent mère un message de mise à jour de correspondance qui contient l adresse mobile du nœud mobile. Celle-ci est alors stockée au niveau du correspondant, qui crée ensuite un tunnel directement entre lui et le nœud mobile, évitant ainsi de passer par l agent mère. Au contraire d IPv4, où les paquets doivent être encapsulés, Mobile IPv6 utilise l entête de routage du paquet IPv6, qui est une variation du routage source d IPv4 (source routing), ce qui n est pas possible dans le cas d IPv4 pour des raisons de sécurité et de performance Mobilité au niveau «Transport» Après avoir décrit le fonctionnement du protocole MIP qui permet d offrir la mobilité au niveau IP d une manière transparente par rapport aux couches hautes, nous présentons dans cette partie quelques architectures permettant également d assurer la mobilité d une manière transparente en opérant à un autre niveau : la couche «Transport». 45

65 Le protocole I-TCP (Indirect TCP) Il s agit d un protocole qui propose une solution de mobilité pour les terminaux mobiles. Ce protocole nécessite la présence d une passerelle sur le chemin de transport des données entre le correspondant et le terminal mobile. L architecture de communication permettant la mobilité en utilisant le protocole I-TCP [BAK 95] se base sur la division du chemin de transport en deux parties : la partie entre le correspondant et la passerelle où une connexion TCP est établie et la partie entre la passerelle et le terminal mobile au niveau de laquelle une connexion I-TCP est créée. Ces deux connexions en série permettent d assurer la communication entre le terminal mobile et son correspondant. La partie TCP reste inchangée pendant toute la durée de la communication et n a pas besoin d être consciente de la mobilité du terminal mobile. Dans la partie I-TCP, lorsque le terminal mobile se déplace d un sous-réseau à un autre, une nouvelle connexion entre ce terminal et la passerelle est établie et l ancienne connexion I-TCP est ensuite remplacée par la nouvelle. La couche de «Transport» du terminal mobile doit être modifiée afin de supporter I-TCP, mais les applications bénéficient toujours de la transparence au niveau des deux extrémités de la communication Le protocole M-TCP (Mobile TCP) C est une version améliorée du protocole I-TCP. Le protocole M-TCP [HAA 97] est implémenté au niveau du terminal mobile et fonctionne comme un protocole de la couche liaison permettant de connecter ce terminal à la passerelle via un réseau sans fil. La passerelle permet de maintenir une connexion TCP permanente avec le correspondant et redirige tous les paquets venant de ce correspondant vers le terminal mobile. Cette redirection n est aperçu ni par le correspondant ni par le terminal mobile. L amélioration réalisée avec M-TCP (par rapport à I-TCP) réside dans la diminution de la complexité du fonctionnement au niveau de la partie sans fil de la connexion. Tout comme I-TCP, le protocole M-TCP garantit une certaine transparence vis-à-vis des applications Le protocole M-UDP (Mobile UDP) Il s agit d une implémentation du protocole UDP modifié dans le but de supporter la mobilité des utilisateurs. M-UDP [BRO 96] permet de gérer la mobilité d une manière très semblable à celle adoptée par I-TCP et M-TCP. En effet, cette implémentation (M-UDP) se base sur le même modèle en faisant appel à une passerelle qui permet d assurer une connexion entre le terminal mobile et son correspondant. Cette passerelle permet d assurer une connexion ininterrompue entre les deux extrémités de la communication dans un environnement mobile Mobilité au niveau «Application» Actuellement, il existe de nombreuses études qui ont porté sur le support de la mobilité au niveau applicatif. L une des principales approches pour la gestion de la mobilité à ce niveau consiste à utiliser le protocole SIP. L architecture permettant la gestion de la mobilité au niveau applicatif en utilisant le protocole SIP [SCH 00] décrit comment SIP peut assurer la gestion de la mobilité des terminaux. Elle indique également les situations pour lesquelles l utilisation du protocole MIP est préférée pour la gestion de la mobilité des utilisateurs. Cette architecture, décrite dans [WED 99], propose d assurer la mobilité au niveau applicatif pour les communications de type temps réel en utilisant l agent mère pour effectuer la recherche de 46

66 l emplacement du mobile ou pour permettre à SIP de rediriger les invitations (messages INIVITE) à l adresse mère du terminal mobile. Par ailleurs, dans [DUT 04], les auteurs ont introduit au niveau applicatif des techniques pour accélérer la procédure de changement de réseau pour des services multimédia temps réel (basés sur RTP/UDP) dans un environnement de signalisation SIP. Ces techniques sont basées sur les composantes du standard SIP à savoir les agents et les proxys SIP qui, généralement, participent à créer et à supprimer les sessions multimédia entre les terminaux mobiles Mobilité au niveau «Liaison de données» Dans cette partie, nous détaillons l architecture et le fonctionnement du standard IEEE , parce qu il s agit d une solution permettant d effectuer des changements de réseaux entre de différents types de technologies d accès tout en garantissant la continuité du service. L organisme de standardisation IEEE (IEEE Computer Society) a commencé à travailler sur la norme IEEE appelée également MIH (Media Independant Handover) afin de définir un standard qui permette de répondre aux besoins actuels de mobilité. En effet, l objectif de ce groupe de travail est de définir un standard qui permet de fournir à la couche de liaison une intelligence générique indépendamment des caractéristiques du terminal mobile ou des réseaux d accès. Ceci permettra d optimiser et d accélérer le handover entre les réseaux hétérogènes IEEE 802 et les réseaux de troisième génération qui sont en pleine expansion et de faciliter le handover entre ces réseaux et les réseaux cellulaires. Il existe, également, des travaux autour du MIH [SAL 07] qui proposent d introduire une composante satellitaire dans l architecture du MIH afin de permettre l intégration des réseaux d accès par satellite dans les réseaux entre lesquels ce standard permet de réaliser des handovers. La norme IEEE [IEE 08] spécifie le handover pour les utilisateurs mobiles et stationnaires. Pour les utilisateurs mobiles, les handovers peuvent se produire quand les états de lien sans fil changent en raison du mouvement des utilisateurs. Pour les utilisateurs stationnaires, les handovers deviennent imminents lorsque l environnement des réseaux disponibles change, rendant un réseau plus attrayant qu un autre. Le changement de réseau (handover vertical ou horizontal) est initié par le terminal, tandis que la décision relative à ce changement implique, également, les infrastructures réseau qui disposent d importantes informations sur les réseaux disponibles Architecture du MIH Le réseau global peut inclure des cellules de tailles différentes, comme celles de type IEEE , IEEE , IEEE , 3GPP, et 3GPP2, avec chevauchement de couverture. La norme IEEE permet aux terminaux mobiles de choisir le réseau le mieux adapté et de s y connecter. Le processus de changement de réseau peut être lancé, suite à des rapports de mesures fournis par les couches inférieures du terminal, tels que la qualité du signal, les différences de temps de synchronisation, et les taux d erreur de transmission, etc. La norme [IEE 08] définit un cadre de travail qui permet la continuité de service lors des transitions d un nœud mobile entre technologies hétérogènes de la couche «liaison». Ce cadre se fonde 47

67 sur la présence d une pile protocolaire pour la gestion de la mobilité dans les terminaux et les éléments de réseau qui supportent les handovers (Figure 2-11). Cette pile protocolaire définit un ensemble de fonctions assurées grâce à une entité logique appelée le MIHF (MIH Function) [IEE 08]. La Figure 2-11 montre le placement du MIHF dans la pile protocolaire d un terminal mobile possédant de multiples interfaces. Le MIHF fournit trois types de services (voir section ) qui permettent aux utilisateurs : la découverte et le choix de réseau d accès, le maintien de la continuité de service, la conservation de la durée de vie de la batterie. Découverte et choix du réseau d accès : le choix du réseau est le processus par lequel un nœud mobile choisit un réseau d accès pour établir la connectivité. Ce choix peut se baser sur divers critères tels que la QoS exigée, le coût, les préférences de l utilisateur, ou les politiques de l opérateur réseau. Cette norme définit les informations qui permettent la découverte des réseaux (type, identificateur, disponibilité, qualité, sécurité, etc.) et spécifie les moyens permettant aux utilisateurs d obtenir ces informations afin de permettre un choix efficace du réseau d accès. Continuité de service : La continuité de service est définie comme la continuation du service pendant et après le changement de réseau sans avoir besoin de l intervention de l utilisateur pour rétablir le service. La norme permet de maintenir la continuité de service lors du changement de réseau d accès. Ceci est possible en réduisant les aspects tels que la perte de données et la durée de la perte de connectivité pendant le changement de réseau. Par exemple, lors d un changement de réseau pendant un appel téléphonique, les procédures de handover doivent pouvoir être exécutées de manière à ce que n importe quelle interruption perceptible pour la conversation, soit réduite au maximum. Gestion d énergie : Cette norme permet de réduire au maximum la puissance consommée par les terminaux mobiles dans la découverte des réseaux sans fil (802.11, et réseaux 3GPP) en évitant l activation de multiples radios et/ou le balayage excessif des radios. Figure 2-11 : Architecture du standard IEEE [IEE 08] Les services MIH La norme définit une entité logique appelée le MIHF (MIH Function) [IEE 08] qui permet à travers les trois services qu elle fournit (événement, commande et information) de faciliter les handovers entre les réseaux hétérogènes et d apporter l intelligence nécessaire à l entité qui doit sélectionner le réseau d accès. 48

68 Le service d évènement (MIES) Ce service permet de détecter des changements dans les propriétés des couches inférieures (physique et liaison), et de déclencher les évènements appropriés. Ceci permet de déterminer s il y a besoin d effectuer un handover. Les évènements sont lancés à partir des interfaces et peuvent être classés en deux types : les «MIH Event» qui sont envoyés par le MIHF à destination des couches supérieures, et les «Link Event» qui se propagent des couches inférieures (PHY, MAC) vers le MIHF Le service de commande (MICS) Ce service de commandes met à disposition de l utilisateur un ensemble de commandes qui lui permettent de commander le comportement et les propriétés du lien qui sont appropriées au handover et de commuter entre les liens en cas de besoin. Ces commandes servent à véhiculer des décisions et sont divisées en deux types. Les «MIH Commands» transmises par l utilisateur en direction du MIHF qui les exécute dès la réception. Et les «Link Commands» qui vont du MIHF vers les couches inférieures Le service d information (MIIS) L utilisateur mobile doit avoir une vue d ensemble afin de faciliter le choix du réseau et la gestion de la mobilité dans un milieu où coexistent une multitude de technologies d accès. Le service d information MIIS définit un ensemble d éléments d information et leurs structures afin de faciliter la description des réseaux. Il fournit, également, des mécanismes, de type requête/réponse, qui permettent à un terminal mobile de découvrir et de collecter des informations sur les caractéristiques et les services offerts par le réseau d accès utilisé et les réseaux voisins. Ces informations permettent une prise de décision plus efficace du handover à travers les réseaux hétérogènes. Ainsi, le MIHF permet à travers les trois services fournis (événement, commande et information) de faciliter les handovers entre les réseaux hétérogènes et d apporter l intelligence nécessaire à l entité qui doit sélectionner le réseau d accès. Lors de la sélection du réseau d accès, le MN et le réseau ont besoin d échanger des informations sur les réseaux existants afin de sélectionner le meilleur réseau. Ceci peut entraîner la sélection d un réseau différent du réseau actuel, qui peut nécessiter un handover entre des technologies différentes. Une fois le nouveau réseau choisi et le handover initié, les protocoles de gestion de la mobilité tels que le protocole IP Mobile (MIP : Mobile IP) peuvent être utilisés afin de s occuper des aspects du routage des paquets tels que la mise à jour de l adresse et la livraison des paquets vers le nouveau réseau. Cependant, le protocole définit des évènements déclencheurs de la couche liaison tels que «Link Going Down» et «Link Up» qui peuvent être utilisés pour indiquer le départ et l arrivée des terminaux mobiles sur les réseaux d accès. Ainsi, ces indications peuvent remplacer les protocoles de signalisation de la couche «Réseau» (Mobile IP, SIP, etc.) qui peuvent être utilisés dans le même but, et permettent donc d accélérer le processus du handover Résumé Comme nous l avons mentionné dans la section 2.2.2, l un des défis techniques des réseaux de nouvelle génération est d assurer la mobilité des utilisateurs qui doivent être capables de changer à tout moment de réseau d accès. C est ainsi que la mobilité occupe une place importante dans la majorité des 49

69 projets de recherche actuels traitant des réseaux de nouvelle génération. Cette mobilité peut être assurée à différentes couches du modèle TCP/IP et en utilisant plusieurs protocoles et standards parmi ceux qui ont été proposés. Cependant, le choix du protocole ou standard à utiliser pour la gestion de la mobilité des utilisateurs dépend essentiellement du type de la technologie d accès implémentée et de la nature du service consommé. En revanche, le standard MIH peut constituer une solution bien adaptée aux environnements NGN, car il permet d effectuer des handovers entre réseaux utilisant des technologies de types très variées tout en assurant la continuité des services transportés. 2.7 Conclusion Dans ce chapitre, nous avons commencé par présenter l architecture générale des réseaux de nouvelle génération. Les différentes caractéristiques (nouveaux services, différentes technologies d accès, terminaux mobiles, etc.) de ces réseaux permettent d identifier les besoins à satisfaire pour les services fournis dans de tels environnements. Parmi ces besoins, les plus importants sont la qualité de service, la sécurité et la mobilité. Ainsi, nous avons défini la notion de la qualité de service et les mécanismes et modèles qui permettent d assurer cette qualité. Ensuite, les problèmes de sécurité ainsi que les services qui permettent d y remédier ont été rappelés, avant de décrire les protocoles les plus utilisés dans la sécurisation des communications. Enfin, concernant la mobilité des utilisateurs, nous avons détaillé l architecture de deux protocoles qui permettent de gérer cette mobilité. Cependant, la segmentation de l architecture NGN en plusieurs domaines où chaque domaine est sous l autorité d un opérateur réseau, nécessite la négociation d un accord entre les différents domaines impliqués dans le transport d un service. Cet accord peut porter sur différents aspects tels que la qualité de service ou encore la sécurité et permet d assurer un niveau de service. Dans le chapitre suivant, nous allons définir la notion de niveau de service, et décrire comment se passe la négociation de niveau de service. 50

70 Chapitre 3 La garantie de l offre de service dans les réseaux NGN 3.1 Introduction Comme nous l avons souligné précédemment, de nombreuses solutions ont été proposées par l IETF ou encore dans le cadre de plusieurs projets de recherche (Cadenus, Tequila et Internet2-Qbone, etc.) dans le but de répondre aux besoins de QoS dans les réseaux NGN. Actuellement, les réseaux de nouvelle génération doivent fournir aux différents utilisateurs, connectés via divers réseaux d accès, des services dont les besoins évoluent vers plus de QoS, de sécurité et de mobilité. En effet, ces réseaux offrent de plus en plus de services tels que les services temps réel et les services multimédias qui nécessitent une reconfiguration rapide et fréquente du réseau, ce qui demande une gestion dynamique fondée sur une signalisation pouvant être implicite ou explicite. Dans le premier cas, l utilisateur peut injecter directement son trafic dans le réseau, alors que dans le second cas, un protocole de signalisation doit être utilisé afin d assurer une négociation de service dynamique permettant une allocation des ressources en adéquation avec les besoins du trafic auprès des responsables des réseaux. Plusieurs protocoles ont ainsi été proposés afin de négocier dynamiquement le niveau de service. Parmi ces protocoles, nous pouvons citer SrNP [TEQ 01], COPS-SLS [NGU 04] et DSNP [CHE 02a]. Ces protocoles reposent essentiellement sur deux principes : la définition de paramètres à négocier, et la définition d un mécanisme (ou fonctionnement) de négociation. Dans la suite de ce chapitre, nous commençons par rappeler la définition de la notion de niveau de service avant de détailler les principaux paramètres qui peuvent le caractériser. Ensuite, nous présentons quelques projets qui se rapportent à la négociation de niveau de service. Puis, nous décrivons un ensemble de protocoles de négociation de niveau de service tout en expliquant les particularités de chacun de ces protocoles. Enfin, nous nous intéressons, plus particulièrement, au protocole de négociation, appelé SLNP, qui utilise les services web afin de fournir une certaine interopérabilité aux différents acteurs d une négociation. Nous décrivons l architecture de ce protocole ainsi que son mode de fonctionnement, avant de présenter un exemple d une telle négociation. 51

71 3.2 Niveau de service Définition L architecture des réseaux de nouvelle génération s appuie sur le découpage vertical actuel en plusieurs domaines, où chaque domaine regroupe un ensemble de nœuds qui répondent à une seule et même autorité administrative, qu on peut désigner sous le terme «responsable de domaine» ou encore «gestionnaire de domaine (DM : Domain Manager)». Selon l offre de service, ce responsable de domaine peut être un fournisseur de services (SP : Service Provider) ou encore un fournisseur de réseau (NP : Network Provider). Chaque domaine, sous l autorité d un fournisseur de réseau, offre des services à ses clients qui peuvent être, eux-mêmes, des fournisseurs de services ou de simples particuliers. Un client qui veut bénéficier de ces services doit négocier avec le responsable de domaine un accord concrétisé par un contrat différencié, rédigé en langage "business", appelé SLA (Service Level Agreement). Ce contrat définit le service fourni, les paramètres associés à ce service, les niveaux de service acceptables et les niveaux de service inacceptables, les engagements du fournisseur et du client et les mesures à prendre dans des circonstances spécifiques [DOB 96]. La définition du SLA par l IETF est la suivante [BLA 98] : Un SLA est un contrat de service, entre un client et un fournisseur de service, qui spécifie le service que le client devrait recevoir. Un SLA contient à la fois des paramètres et des conditions techniques et non techniques. Les paramètres techniques constituent la partie négociable du contrat liant le fournisseur et le client, et sont regroupés dans une spécification appelée SLS (Service Level Specification) [GRO 02] qui : est un ensemble de paramètres et leurs valeurs correspondantes permettant de définir le service offert à un trafic par un domaine. Autrement dit, un SLS permet de décrire les caractéristiques d un trafic correspondant à un flux donné et la nature du service offert par l ensemble du réseau à ce flux. Il peut être de différents types ; on peut, en effet, avoir un SLS pour les services de sécurité, un SLS pour les services de mobilité, ou encore un SLS pour les garanties de QoS. Le contrat de service (SLA) entre un client et un fournisseur de services contient des éléments contractuels qui permettent de spécifier le niveau de service demandé ainsi que les mesures à prendre afin de contrôler l efficacité du service fourni. Ce contrat couvre des aspects comme la disponibilité, les performances, les mesures spécifiques à prendre en cas de défaillance ou de disfonctionnement de service et le type de facturation à mettre en œuvre. Nous pouvons distinguer trois types de SLA [MAR 01] : SLA client : c est un contrat de service entre un client final et son fournisseur de services. Les éléments techniques de ce SLA, tels que les paramètres de QoS, permettent de définir la QoS telle que demandée par le client, c est-à-dire la qualité de service de bout en bout ; SLA horizontal : c est un contrat de service entre deux fournisseurs offrant chacun un service de même niveau (par exemple deux domaines IP). Le fournisseur qui demande un service, agit souvent pour le compte de ses clients. Ainsi, dans le cas d un contrat sur la QoS par exemple, il s agit d un contrat sur une QoS d un agrégat d un ensemble de flux ; SLA vertical : c est un contrat de service entre deux fournisseurs de services dont l offre se situe à un niveau différent (par exemple MPLS et WDM). Dans ce cas, également, le contrat de service concerne un agrégat d un ensemble de flux. 52

72 3.2.2 Les paramètres du niveau de service Bien que le groupe de travail DiffServ de l IETF ait défini le SLS comme un ensemble de paramètres techniques, il n a pas précisé ces paramètres. En effet, un niveau de service peut porter sur la qualité de service, la sécurité ou encore la mobilité. Ainsi, les paramètres de SLS n ont pas été standardisés, et l IETF a laissé le soin de définir ces paramètres aux fournisseurs de services. Cependant, de nombreux travaux ont été effectués jusqu à présent dans différents projets de recherche comme Tequila [TEQ 03], COPS- SLS [NGU 04], Eurescom [EUR 01], Internet2-Qbone [BEN 00] ou IPSig [BEN 03]. En se fondant sur ces travaux, nous pouvons lister les paramètres types d un SLS [GOD 03]-[CHE 02a] : L identifiant du SLS (SLS ID) : Chaque SLS peut contenir un identifiant unique qui permet de le reconnaître et de le distinguer des autres SLS. Bien que ce paramètre puisse être considéré comme optionnel, il offre une grande souplesse lorsqu il est introduit dans un SLS. En effet, cet identificateur permet à un client de renégocier un attribut d'un SLS déjà établi. Quand il figure parmi les paramètres d un SLS, le SLS ID est attribué par le fournisseur de services. La portée (Scope) : La portée d un SLS fait référence à la topologie ou la zone géographique dans laquelle le service doit être offert. En effet, il permet de préciser les bords géographiques entre lesquels le niveau de service (exemple : qualité de service ou encore sécurité) sera garanti au flux circulant entre un point d entrée (Ingress) et un point de sortie (Egress). Ainsi, cette portée se présente, généralement, sous la forme d un couple de routeurs (Ingress, Egress) désignant le trafic associé au SLS. Si les points d entrée et de sortie de la portée du SLS négocié appartiennent à un même domaine, on parle, alors, d une négociation intra-domaine. Dans le cas contraire, on parle d une négociation inter-domaines. Bien que la portée permette au réseau de prendre la bonne décision en fonction de sa capacité à satisfaire un niveau de service, il n est pas nécessaire que l abonné à un SLA connaisse la portée de son trafic. L identification de flux (Flow ID) : Un flux peut être défini comme un flot distinguable de paquets de données exigeant le même niveau de service (exemple : la même qualité de service et/ou les même services de sécurité). La spécification de flux ou l identification de trafic permet d identifier les flux qui sont concernés par le SLS en cours de négociation. En effet, un flux est identifié en spécifiant les valeurs d un ou plusieurs paramètres tels que les adresses IP source et destination, les numéros de port source et destination, le protocole de transport, un code DSCP (si applicable), un label MPLS, etc. En se basant sur ces informations, le routeur d entrée (ingress) peut classifier les paquets et les marquer afin que les paquets appartenant à ce flux puissent profiter du niveau de service négocié dans le SLS. Le profil de trafic (Traffic Profile) : la spécification du profil du trafic fournit une description du volume du trafic des flux associés à un SLS. Les flux de trafic pourraient être caractérisés grâce à différents attributs tel que le débit crête, le débit moyen et la taille minimale d un paquet. En se fondant sur ces paramètres spécifiés, les nœuds d entrée (ingress) du réseau vérifient la conformité du trafic pour tous les paquets qui appartiennent au flux spécifié. Seuls les paquets qui sont conformes à la spécification du trafic (trafic «in-profile») bénéficient des garanties du service négocié. Les paquets qui ne sont pas conformes aux paramètres du trafic négociés (trafic «out-of-profile») peuvent être supprimés (dropped), lissés (shaped) ou marqués (marked). Ce test de conformité peut être réalisé en utilisant un 53

73 algorithme de conformité tel que l algorithme «Token Bucket». Le traitement spécifique des paquets non conformes peut également être négocié en tant qu une partie du SLS (traitement d excès). La garantie de performance (Performance Guarantee) : la spécification de la garantie de performance permet de décrire les garanties en matière de qualité de service que les flux identifiés par la spécification de flux et conformes aux spécifications du trafic peuvent avoir au niveau de la zone géographique décrite par la portée. Ces garanties de service (QoS) sont exprimées à l aide de paramètres tels que le délai, la gigue, la perte de paquets et le débit. Ces paramètres peuvent être spécifiés quantitativement ou qualitativement. Un paramètre est dit quantitatif lorsqu une valeur numérique définitive peut lui être attribuée. Un paramètre qualitatif est un paramètre dont la valeur est établie en comparaison avec d autres valeurs et ne peut pas être quantifiée. Le temps de service (Service Schedule) : la spécification du temps de service ou période d activité permet de marquer le début et la fin de la période pendant laquelle le service négocié (qualité de service ou sécurité) sera garantie. Ce paramètre indique quand le service sera disponible (24 heures 7 jours, seulement pendant les week-ends, de 8h à 16h les jours de semaine, etc.). Les services de sécurité (Security Services) : la spécification des services de sécurité permet d identifier les garanties en matière de sécurité que les flux identifiés par la spécification de flux peuvent avoir au niveau de la zone géographique décrite par la portée. Ces services sont principalement la confidentialité, l authenticité (intégrité et authentification) et la protection contre le rejeu. Le niveau de sécurité de chacun de ces services peut être spécifié quantitativement ou qualitativement. Les paramètres que contient un SLS ne dépendent que de la nature du niveau de service exigé par l utilisateur. En effet, un utilisateur peut demander, par exemple, un SLA avec des contraintes de sécurité, de qualité de service ou encore de qualité de service et de sécurité à la fois. De plus la signification d un paramètre dépend da la nature du SLS. Par exemple, lorsqu il s agit d un SLS de QoS, la portée spécifie la zone géographique sur laquelle les garanties en matière de QoS doivent être assurées pour le flux désigné. Par ailleurs, dans le cas d un SLS de sécurité, la portée spécifie la zone géographique sur laquelle les services de sécurité décrits par le SLS doivent être fournis pour le flux identifié. Ainsi, nous pouvons distinguer différentes classes de paramètres : les paramètres présents dans n importe quel type de SLS (l identificateur du SLS, la portée, l identification de flux, le temps de service, etc.), des paramètres relatifs à la QoS (le trafic, la garantie de performances, etc.), des paramètres qui définissent le niveau de sécurité (protocole de sécurité, services de sécurité, etc.) ou encore des paramètres de mobilité (degré de mobilité vitesse, sens de déplacement, etc.). Outre les paramètres techniques présentés ci-dessus qui définissent un SLS, un SLA peut également inclure plusieurs paramètres non techniques comme le prix ou l identifiant du client pour pouvoir l authentifier [DAR 04]. Le prix : Le prix est un paramètre important qu un client a besoin de négocier. Il est important de noter que, comme beaucoup d autres produits, le prix d un service réseau peut fluctuer au fil du temps et peut dépendre des conditions du réseau. Par exemple, sous des conditions de scénario de congestion, le fournisseur de services peut demander un prix très important pour les services premium afin de faire baisser la demande, alors que sous des charges légères, le même service pourrait être offert à un prix très réduit afin de faire augmenter la demande et, par la suite, l utilisation du réseau. 54

74 Les capacités de réseaux et de terminaux : Le SLA pourrait contenir une liste des terminaux (téléphones portables, PDA, ordinateurs portables, ordinateurs, etc.) avec lequel un client est susceptible de se connecter au réseau. Cela peut permettre au réseau d estimer le niveau des ressources que ce client devra probablement négocier. Ceci pourrait permettre au réseau de mieux juger la recevabilité des SLA des autres clients. De même, le SLA peut indiquer la liste des technologies d accès (GPRS, UMTS, Wi-Fi, câble Ethernet, etc.) à la disposition d un client afin d avoir une idée sur les ressources que le client devra probablement réserver Résumé Comme nous l avons mentionné auparavant, ces paramètres ont été spécifiés dans le cadre de nombreux projets de recherche. Dans ce qui suit, nous présentons quelques travaux qui ont porté sur la négociation de niveau de service de bout en bout. 3.3 Négociation de niveau de service Projets de recherche traitant de la négociation Dans cette partie, nous décrivons les plus importants projets de recherche qui se sont intéressés à l offre de service dans les réseaux fondés sur IP. Les principaux apports de ces projets résident dans la définition d architectures qui permettent de garantir un niveau de service en mettant en œuvre des mécanismes de négociation dynamique. Le but principal des ces mécanismes est de permettre l établissement d un accord ou d un consensus sur un niveau de service qui doit être compris par les différentes composantes des architectures proposées Le projet TEQUILA Le projet européen TEQUILA (Traffic Engineering for QUality of service in the Internet at LArge) [TEQ 04] avait pour objectif principal la spécification et le développement d une architecture globale et des techniques associées afin de permettre de fournir une qualité de service de bout en bout dans les réseaux IP fondés sur le modèle de qualité de service DiffServ. Ce projet traitait de l offre de service ainsi que des aspects de la gestion des ressources. Le projet TEQUILA s est concentré sur la définition des services nécessitant une connectivité IP et sur les aspects liés à ces services tels que l approvisionnement en matière de qualité de service. Le projet TEQUILA a pris l initiative de proposer à l IETF un modèle pour la sémantique et les paramètres d un SLS [TEQ 03]. Les paramètres de SLS définis par TEQUILA pour tous les types de services, couvrent : la portée géographique, l identification de flux, la description de trafic, le traitement d excès, le temps de service et les paramètres de performance Le projet AQUILA Le projet de recherche européen AQUILA (Adaptive Resource Control for QoS Using an IPbased Layered Architecture) avait pour but de définir, évaluer et mettre en œuvre une architecture améliorée pour la qualité de service dans l Internet. Il existe un ensemble de points communs entre les approches 55

75 AQUILA [SAL 00] et TEQUILA. La principale différence réside, par contre, dans l introduction de la notion des SLS prédéfinis (fondés sur une définition générique) par le consortium AQUILA. Du point de vue des applications, un SLS supporte un large éventail d applications ayant des comportements de communication similaires et donc les mêmes besoins en matière de qualité de service, tels que le delai, le débit, le taux de perte, etc. Quatre types de SLS prédéfinis ont été spécifiés par AQUILA : «Premium CBR», «Premium VBR», «Premium Multimedia» et «Premium Mission Critical» Le projet EURESCOM Le projet de recherche européen EURESCOM P1008 [EUR 01] avait pour objectif de définir une architecture qui permet la gestion des interconnexions et des services dans des réseaux basés sur IP, tout en respectant la qualité de service. Ce projet s est focalisé sur les services de bout en bout pour lesquels la qualité de service doit être spécifiée. Il spécifie le contenu de composantes d'un modèle de SLS qui sont : l identification, la période de validité, la topologie, la portée, l'identification de flux, le profil de trafic, la qualité de service, le traitement d excès, la fiabilité, la comptabilité (accounting), la surveillance (monitoring). Le projet EURESCOM étend le modèle du SLS proposé par TEQUILA en ajoutant de nouveaux blocs tels que la topologie, la surveillance, la comptabilité et l identification. Ce modèle de SLS est utilisé, non seulement, pour le provisionnement, mais aussi pour la facturation et la partie assurance. Le bloc de monitoring décrit les paramètres de QoS qui doivent être surveillés et signalés (reported). Il indique quels sont ces paramètres (parmi la liste des quatre paramètres de performance) à surveiller et à signaler et avec quelle fréquence cela doit se faire Le projet MESCAL Le projet européen MESCAL (Management of End-to-end Quality of Service Across the Internet at Large) [MES 05] avait pour objectif de définir une architecture pour l offre de services avec des garanties de qualité de service. L architecture proposée par ce projet [MES 03] se compose de cinq groupes fonctionnels. Parmi ces groupes, nous trouvons le groupe «SLS Management» qui s est occupé de la négociation de niveau de service. Cette négociation s appuie sur le modèle Diffserv tout en adoptant une solution en cascade (non centralisée) pour une négociation inter-domaines qui se base sur une extension de BGP, à savoir ibgp. Cette négociation se fonde sur l utilisation de SLS prédéfinis. Ainsi, trois types de SLS prédéfinis ont été proposés dans le cadre de ce projet [MES 04]: Les p-sls entre fournisseurs de services, qui sont les moins dynamiques puisqu ils portent sur des agrégats de flux et sont négociés en amont de l offre de service, Les c-sls entre clients et fournisseurs de services qui sont négociés à la demande et sont ainsi plus dynamiques, Les m-sls qui correspondent à des SLS multicast. Le modèle de QoS qui a été retenu par MESCAL est le modèle DiffServ. Ainsi, après l établissement des contrats de services, les SLS seront associés à des classes de services (QC : QoS Class) grâce au champ DSCP (DiffServ Code Point). Notons que le protocole de négociation adopté par MESCAL est le protocole SrNP du projet TEQUILA [TEQ 01]. Ce protocole s appuie sur une architecture client/serveur 56

76 pour la négociation de SLS entre ces deux entités. Ainsi, deux blocs ont été définis, à savoir le SLS Order Handling et SLS Ordering [MES 04], qui correspondent respectivement au serveur et au client. Par ailleurs, le modèle de SLS adopté est celui présenté par TEQUILA dans le draft [GOD 03] et comporte ainsi les mêmes paramètres que ceux définis dans ce dernier Le projets CADENUS Le projet européen CADENUS (Creation And Deployment of End-User Services in Premium IP Networks) [CAD 03] portait sur la proposition d une architecture ouverte qui permet la création, la configuration et l approvisionnement de services d une manière dynamique, tout en fournissant des garanties de qualité de service. Cette architecture comporte des composants de médiation qui sont au nombre de quatre : le médiateur d accès (AM : Acces Mediator), le médiateur de services (SM : Service Mediator), le médiateur de ressources (RM : Resource Mediator) et le contrôleur de réseau (NC : Network Controller). Le médiateur d accès gère l accès des utilisateurs aux services. Il présente à l utilisateur l ensemble des services disponibles et leurs descriptions, et lui permet de sélectionner, paramétrer et acquérir des services auprès du médiateur de services. Le médiateur de service négocie avec le médiateur de réseau un SLS. Une fois accepté, le SLS est utilisé dans la configuration du réseau par le biais du contrôleur du réseau. Le projet CADENUS avait défini deux types de contrats : Les contrats «Off Line» : qui sont utilisés lors de la souscription aux services. Ces contrats sont divisés en deux catégories : les retail-sla (r-sla) entre clients et fournisseurs et les wholesale-sla (w-sla) entre fournisseurs. Les contrats «On Line» : qui sont utilisés lors de la demande de services avec des garanties de qualité de service. Ces contrat forment ce qu on appelle les instant-sla (i-sla) dont les SLS correspondants (i- SLS) sont négociés entre le médiateur de service et le médiateur de ressources ou encore deux médiateurs de ressources de deux fournisseurs différents. Les i-sls comportent les données nécessaires qui permettent d établir un niveau de service avec des garanties de QoS indépendamment des caractéristiques du réseau, c est-à-dire sans se limiter à un modèle de QoS spécifique. Les attributs des i-sls sont inspirés de ceux définis dans le cadre du projet TEQUILA [TEQ 01]. Dans le cadre d une négociation inter-domaines, un i-sls est décomposé en autant de i-sls que de domaines mis en jeu lors de cette négociation. Synthèse : Les SLS définis dans le cadre de ces travaux, décrivent principalement les garanties de qualité de service que le réseau doit fournir pour un flux ou un ensemble de flux donné. C est sur ce SLS de QoS que porte la négociation dans la plupart (si ce n est pas la totalité) des protocoles de négociation de niveau de service qui ont été proposés jusqu à présent. En effet, nous notons que les travaux ayant considéré des aspects autres que la QoS dans le niveau de service sont très rares. Nous pouvons citer les projets ARCADE [ARC 07]-[YIL 03] et IPSIG [BEN 03] qui ont fait l exception en tentant de proposer des paramètres liés à d autres aspects comme la sécurité ou la QoS. Dans ce qui suit, nous présentons quelques protocoles de négociation de niveau de service. 57

77 3.3.2 Protocoles de négociation Les projets présentés dans la section précédente traitent essentiellement de l offre de service qui ne peut être garantie que suite à l établissement d un accord en utilisant un protocole de négociation de niveau de service. C est ainsi que dans le cadre de ces projets des protocoles de négociation ont été utilisés ou même spécifiés. Dans ce qui suit, nous décrivons un certain nombre de ces protocoles en détaillant quelques uns afin de comprendre leurs fonctionnements, les besoins qu ils doivent satisfaire et comment ils y parviennent Le protocole RNAP Le protocole RNAP (Resource Negotiation and Pricing Protocol) [WAN 99] a été l un des premiers protocoles à avoir été défini et utilisé pour faciliter la négociation dynamique de niveau de service dans les NGI (Next Generation IP networks). Ce protocole peut être considéré comme une extension du protocole de réservation de ressources RSVP (Resource Reservation Protocol). Une des plus importantes caractéristiques qui distingue le protocole RNAP des autres protocoles est que, en plus de la négociation des paramètres du SLS, ce protocole permet la négociation des prix du contrat de service. RSVP peut fonctionner dans des environnements de négociation centralisés mais aussi distribués. De plus, il est caractérisé par l approche à état souple de négociation (soft state) qu il utilise ; ce qui nécessite du client l initiation périodique du processus de signalisation afin d actualiser les services déjà négociés Le protocole COPS-SLS Le protocole COPS (Common Open Policy Service) [DUR 00] a été proposé par l IETF à travers le groupe de travail RAP (Resource Allocation Protocol) afin de permettre la gestion du réseau. Cette gestion se base sur des politiques et implique essentiellement deux entités [YAV 00]: PEP (Policy Enforcement Point) : c est l entité où les politiques vont être appliquées, PDP (Policy Decision Point) : c est l entité qui décide de l affectation des règles de politiques auprès du PEP. La nature de l architecture de la gestion par politique ainsi que la flexibilité du protocole COPS [NGU 03] ont été à l origine de l adaptation de ce protocole à la négociation de SLS. Ainsi, une extension de COPS, à savoir COPS-SLS [NGU 04], a été définie afin de permettre une négociation de SLS horsbande entre un client et un fournisseur de services ou entre deux fournisseurs de services. Cette négociation se base sur l architecture de gestion par politique (SLS-PEP, SLS-PDP), comme le montre la Figure 3-1. La procédure de négociation est réalisée en deux phases : la configuration basée sur le «provisionning» et la négociation fondée sur l «outsourcing». La phase de configuration permet au fournisseur de services d informer le client sur la manière de demander un niveau de service. En effet, pendant cette phase le SLS-PDP configure le SLS-PEP en lui fournissant les paramètres nécessaires pour la négociation. Ensuite, la phase de négociation permet au client de commencer la négociation. En fait, pendant cette phase le SLS-PEP envoie le SLS qu il veut négocier au SLS-PDP. Une négociation COPS-SLS peut être effectuée suivant l un des deux modes spécifiés par ce protocole : prédéfini ou non prédéfini. Dans le cas d une négociation avec le mode «Prédéfini», c est le 58

78 SLS-PDP qui, pendant la phase de configuration, fournit au SLS-PEP les paramètres de SLS acceptés ou un intervalle auquel les paramètres doivent appartenir. Cependant, lorsque le mode de la négociation est «Non Prédéfini», alors aucune contrainte n est exigée sur les valeurs des paramètres du SLS négocié entre le SLS-PEP et le SLS-PDP. Figure 3-1 : Négociation de SLS avec COPS-SLS [NGU 04] Une fois un accord obtenu entre les deux parties, le contrat est établi et les flux des utilisateurs concernés par cet accord peuvent bénéficier du niveau de service négocié Le protocole PPP IPCP Le protocole PPP (Point to Point Protocol) utilise un ensemble de protocoles de contrôle réseau pour l établissement et la configuration de différents protocoles de la couche réseau. Le protocole IPCP (Internet Protocol Control Protocol) est un protocole de contrôle réseau qui s occupe de la configuration des modules IP dans les deux extrémités d un lien PPP [MCG 92]. L option SLS IPCP [DEC 00] représente une extension du protocole IPCP proposée pour assurer la négociation des SLS entre un client et un fournisseur de services. Ceci permet d obtenir des garanties de service sur un lien PPP dans un réseau utilisant Diffserv comme modèle de QoS. Pour assurer la négociation du SLS avec IPCP, quatre types de messages ont été définis Configure-Request, Configure-Ack, Configure-Nack et Configure- Reject. Ces messages sont traités comme des messages IPCP ordinaires. Parmi les paramètres que permet de négocier l option SLS IPCP, nous citons l identification de service, la valeur du DSCP, la conformité du trafic, les caractéristiques du trafic, la portée, la disponibilité du service et le traitement d excès. Ces paramètres sont transportés sous le format TLV (Type, Longueur, Valeur) Le protocole SrNP Le protocole SrNP (Service Negotiation Protocol) [TEQ 01] est un protocole qui a été développé par le consortium TEQUILA [TEQ 04]. Ce projet avait défini une architecture de négociation de services 59

79 décrivant deux procédures d offre de services : la souscription et l invocation. C est en effet dans le cadre de la souscription aux services que le protocole SrNP (Service Negotiation Protocol) a été défini pour la négociation des SLS. La négociation assurée par SrNP peut être réalisée entre un client et un fournisseur ou entre deux fournisseurs de services. Ce protocole se caractérise par sa transparence par rapport au SLS négocié ; il n est spécifique ni à un format de SLS particulier, ni à un contexte de SLS. Il est suffisamment général pour être appliqué pour la négociation de n importe quel document (SLS) qui se présente sous la forme d un ensemble de paires attribut-valeur. Ainsi, les composantes du SLS négocié avec SrNP sont souvent en accord avec le modèle défini par TEQUILA, mais ce dernier peut être étendu à d autres paramètres. L objectif du processus de négociation est de s entendre sur les valeurs des attributs inclus dans le document négocié, plutôt que sur les attributs eux-mêmes. Une négociation SrNP est un échange entre un client SrNP et un serveur SrNP qui permet d établir un accord, de modifier ou résilier un accord déjà établi [TEQ 03]. Ceci est réalisé grâce à un certain nombre de messages qui ont été définis ; les messages propres aux clients (SessionInit, Proposal, LastProposal et AcceptToHold), les messages propres aux serveurs (Revision, LastRevision, AgreedProposal et ProposalOnHold) et les messages communs (Accept et Reject). Un exemple de négociation montrant un échange de messages SrNP est représenté par la Figure 3-2. Figure 3-2 : Exemple de négociation avec SrNP [TEQ 03] En fonction de la pile protocolaire utilisée, les messages SrNP peuvent être transportés grâce à : un codage ASCII, un codage suivant les règles de base (BER : Basic Encoding Rules), c est-à-dire un codage en Type, Longueur, Valeur (TLV : Type Length Value), ou un codage XML (eb-xml MS). Il est, également, possible d encapsuler les messages SrNP dans des protocoles largement déployés comme RSVP (en définissant de nouveaux TLV) et COPS (en spécifiant un nouveau type de client «client-type») Le protocole DSNP DSNP (Dynamic Service Negotiation Protocol) [CHE 02a] est un protocole développé par l équipe ITSUMO (Internet Technologies Supporting Universal Mobile Operation) de TTI (Telcordia Technologies Inc.) et TARI (Toshiba America Research, Inc.). Contrairement à COPS-SLS, SrNP et RNAP qui ne sont que des extensions d autres protocoles réseau existants, DSNP a été développé exclusivement pour la négociation dynamique de niveau de service entre un client et un fournisseur de 60

80 services (intra-domaine) ou entre deux fournisseurs de services (inter-domaines). Par conséquent, il s agit d un protocole léger qui est mieux adapté aux dispositifs sans fil tels que les PDA et les téléphones mobiles [CHE 02b]. Le protocole DSNP repose sur une architecture client/serveur, et utilise les messages suivant lors de la procédure de négociation : SLS_List_Request/Response, SLS_Nego_Request/Response et SLS_Stat_Request/Response. Parmi les paramètres que permet de négocier ce protocole, nous citons le Scope, la Spécification du flux, la Description du trafic, la Garantie de performance et le Temps de service. DSNP se caractérise par son indépendance vis-à-vis de l architecture du réseau et du mode de réservation de ressources. De plus, son architecture permet d offrir un meilleur support pour les clients mobiles. En effet, chaque fois qu un client mobile négocie un niveau de service, le fournisseur de service diffuse le profil de QoS de ce client non seulement au routeur de bord qui dessert le réseau sans fil dans lequel l abonné se trouve actuellement, mais aussi à ceux qui desservent les réseaux sans fil à côté de l emplacement actuel du client mobile. Par conséquent, lorsque ce client se déplace vers l un des réseaux voisins, il continue de bénéficier du niveau de service négocié sans aucune signalisation additionnelle. Un exemple de négociation DSNP où le client mobile MS (Mobile Station) se déplace vers un nouveau réseau est présenté dans la Figure 3-3. Figure 3-3 : Exemple de négociation avec DSNP Ce modèle de fonctionnement défini par DSNP, présente le QGS (QoS Global Server) comme un PDP et le QLN (QoS Local Node) comme un PEP. Ainsi, la négociation a lieu entre le MS (Mobile Station) et le QGS qui va configurer les QLN. 61

81 Le protocole QoS-NSLP QoS-NSLP (QoS NSIS Signaling Layer Protocol) est un protocole pour la signalisation de réservation de QoS dans l Internet [BOS 05]. Il a été proposé par le groupe de travail NSIS [HAN 05] de l IETF. C est une extension de RSVP [BRA 97a] dont le fonctionnement est très similaire à celui de RNAP. Il utilise, également, une approche de négociation de service «soft state». QoS-NSLP ne suppose pas l existence d un système centralisé de gestion de ressources dans chaque domaine, afin de mener à bien le processus de négociation. Ce protocole correspond mieux, ainsi, aux implémentations distribuées Le protocole QoS-GSLP QoS-GSLP (QoS Generic Signaling Layer Protocol) [ANC 05] est un protocole proposé par l ANC (Ambient Networks Consortium) qui fait partie de la suite des protocoles GANS (Generic Ambient Networking Signaling). Il est utilisé pour le contrôle et la négociation bilatérale des besoins de qualité de service dans des environnements mobiles sans fil et fonctionne au dessus de la suite des protocoles NSIS de l IETF. Il se base sur une signalisation hors-bande (signalisation découplée), et utilise les informations sur les schémas de mobilité et de trafic afin d établir des SLS bien à l avance de façon à réduire le temps de mise en place des SLS. Ceci est particulièrement avantageux pour les clients mobiles et les environnements dynamiques Le protocole QoS-SIP Notons qu il existe plusieurs propositions qui ont été faites afin d attacher la signalisation SIP (Session Initiation Protocol) aux mécanismes de gestion de QoS [SAL 02]-[CAM 02]. Une de ces propositions, appelée Q-SIP (QoS-SIP) [SAL 02], propose de s appuyer sur SIP pour déclencher la réservation dynamique de ressources. Cette solution nécessite l extension du protocole SIP [SAL 03] afin de véhiculer les informations relatives à la QoS de bout en bout. L architecture de Q-SIP, implique deux clients SIP, deux proxys SIP et le réseau sous-jacent capable de supporter la QoS (Figure 3-4). Les clients SIP utilisent la signalisation SIP standard, tandis que la signalisation entre les proxys SIP doit être étendue afin de comprendre les paramètres de QoS. Ainsi, les clients sont des clients SIP standard, alors que les proxys SIP sont modifiés pour supporter la QoS. Ces proxys, appelés proxys QSIP (QoS Enabled SIP), contrôlent à la fois l établissement de la session multimédia et la réservation de ressources QoS auprès du réseau sous-jacent à l aide d une signalisation de QoS telle que RSVP, NSIS, COPS, etc. Le principe de fonctionnement de l architecture Q-SIP est décrit dans la Figure 3-4. Quand le client SIP souhaite démarrer une session SIP, il initie la procédure d établissement en envoyant un message INVITE à son proxy QSIP. Ce dernier en extrait quelques informations (média, codecs, ports, etc.) qui permettent de savoir si la session à établir doit comprendre ou non des garanties de QoS. Cependant, aucune réservation de QoS ne peut être faite car, de point de vue de la signalisation SIP, la négociation des paramètres de la communication multimédia n est pas terminée. Au cas où un certain niveau de QoS doit être garanti, le proxy QSIP insère un nouvel entête SIP (QoS-Info), contenant des informations sur la QoS à garantir, dans le message INVITE et le transmet au proxy QSIP distant. Lorsque ce dernier reçoit ce message INVITE, contenant les extensions de QoS, il effectue les traitements relatifs à la demande de garanties de QoS (enregistrement du niveau de QoS nécessaire, etc.) et transmet le message INVITE (sans entête QoS-Info) au client SIP appelé. Le client appelé répond à la requête INVITE en envoyant un 62

82 message OK à son proxy QSIP qui dispose de toutes les informations nécessaires au lancement de la procédure de réservation des ressources pour la communication dans le sens appelé-vers-appelant. Ensuite, le proxy QSIP du client appelé transmet la réponse (OK) au proxy QSIP du client appelant après avoir ajouté les informations de QoS nécessaires. Ces informations sont ajoutées même dans le cas d échec de la réservation de ressources, ce qui permet de laisser au proxy QSIP du client appelant la possibilité d effectuer la réservation de la QoS pour la communication dans le sens appelant-vers-appelé. Quand le proxy QSIP du coté appelant reçoit le message OK, il extrait les informations de QoS, lance la procédure de réservation de ressources et transmet le message OK au client SIP appelant. Ensuite, la session SIP peut être établie avec ou sans support de QoS suivant les résultats des procédures de réservation de ressources lancées au niveau des deux proxys QSIP. Quand la session se termine, toutes les ressources réservées pour la communication doivent être libérées. Ceci se fait suite à la demande des proxys SIP lorsqu ils reçoivent le message BYE émis par un des clients dans la direction de l autre client. Figure 3-4 : Architecture QoS-SIP Discussion L étude des protocoles de négociation nous permet d établir une liste des caractéristiques qu un protocole doit satisfaire pour optimiser sa négociation. Parmi ces caractéristiques, nous pouvons citer [SAR 06] : Satisfaction des besoins de négociation : le protocole doit permettre à un client de demander à son fournisseur de services un niveau de service et à ce fournisseur d accepter ou de rejeter la demande du client. Il doit également permettre la modification et la résiliation d un niveau de service déjà établi. 63

83 Compatibilité avec les architectures de QoS : puisque le transport d un service peut impliquer plusieurs réseaux appartenant à des fournisseurs différents, le protocole de négociation de niveau de service de bout en bout doit être compatible avec la totalité des architectures de QoS standardisées. Réduction des overheads protocolaires : un protocole de négociation doit minimiser les flux de signalisation. En effet, il doit optimiser le nombre de messages envoyés lors d une négociation, mais aussi éviter les renégociations parfois inutiles. En effet, un client mobile qui se déplace vers un nouveau réseau ayant suffisamment de ressources, ne doit pas renégocier le SLS déjà établi pour son service. La signalisation consomme plusieurs ressources comme la bande passante et l énergie, cette dernière étant considérée comme une ressource très précieuse pour les dispositifs mobiles. Transparence vis-à-vis des paramètres du SLS : le but principal d un protocole de négociation est de négocier un SLS. Même si un consensus est établi sur les paramètres qui doivent être négociés dans un SLS, l IETF n a pas encore normalisé le format d un tel SLS. Ainsi, il est très important qu un protocole de négociation ne prédéfinit pas le format de SLS qu il se propose de négocier afin de laisser la possibilité aux utilisateurs (clients et fournisseurs) de choisir les paramètres qu ils veulent négocier (QoS, sécurité et/ou mobilité, etc.). Extension de protocoles existants : un protocole de négociation de niveau de service devrait, de préférence, utiliser des protocoles de signalisation déjà existants. Ceci peut être justifié par le fait que plusieurs protocoles de routage et de gestion réseau sont déjà intégrés et utilisés dans les réseaux d aujourd hui. Ainsi, l ajout d un nouveau protocole pour la négociation de niveau de service peut compliquer l administration des réseaux. D après les caractéristiques des protocoles de négociation dynamique de niveau de service décrits dans la section 3.3.2, ces derniers peuvent être classés en deux catégories. Tout d abord, les protocoles qui forment des extensions à d autres protocoles de signalisation tels que les protocoles QoS-NSLP [BOS 05] et COPS-SLS [NGU 04]. Ensuite, les protocoles qui ont été spécifiés pour la négociation de niveau de service comme le protocole QoS-GSLP [ANC 05] ou encore le protocole DSNP [CHE 02b]. C est à cette catégorie qu appartient le protocole SLNP qui utilise la technologie des services web. En effet, le protocole SLNP a été spécifié afin de permettre la négociation dynamique de niveau de service dans des environnements autonomes. Dans ce qui suit, nous détaillons les principales caractéristiques, l architecture et le fonctionnement de ce protocole avant de présenter un exemple de négociation qu il permet de réaliser. 3.4 Le protocole SLNP La gestion de la QoS dans les réseaux IP, qui a fait l objet de nombreux travaux de recherche, se situait au cœur des préoccupations du projet SWAN (Self aware managent) [SWA 06]. Ce projet, avait pour but d étudier et de proposer des solutions pour la gestion autonome (Self Management) des réseaux IP offrant des garanties de niveau de service. La gestion autonome est un nouveau concept où les éléments autonomes des réseaux sont capables de s autogérer, sans intervention humaine, et de s adapter ainsi aux changements qui peuvent affecter leurs environnements. Dans le cadre de ce projet, le protocole SLNP (Service Level Negotiation Protocol) [MBA 06b] a été spécifié afin de permettre une négociation dynamique de QoS que nécessitent les services transportés sur les réseaux NGN. 64

84 Cette partie sera réservée à la description du protocole de négociation SLNP. Mais avant cela, nous rappelons brièvement l architecture des services web ainsi que les standards sur lesquels se base cette technologie. En effet, le fonctionnement du protocole SLNP est fondé sur l utilisation de la technologie des services web. Par conséquent, le rappel de cette technologie est très utile afin de nous permettre de mieux comprendre le principe de fonctionnement du protocole de négociation (SLNP) ainsi que la composante que doit comprendre une entité pouvant participer à une négociation de QoS via SLNP Les services web Les services web ont été conçus pour standardiser les échanges sur Internet. En effet, ils permettent à une application de trouver automatiquement sur l Internet le service dont elle a besoin et d échanger des données avec ce dernier. La principale caractéristique des services web est l interopérabilité. Cette interopérabilité permet aux applications écrites dans divers langages de programmation (Java, C++, Visual Basic, ) et tournant sur diverses plateformes (UNIX, Windows, ) d utiliser les services web pour échanger des données via Internet. Dans cette section, nous allons présenter l architecture des services web ainsi que les standards sur lesquels se basent ces technologies afin de garantir une interopérabilité entre les entités de négociation Architecture des services web Figure 3-5 : Architecture des services web L architecture des services web implique essentiellement trois entités : le fournisseur de service web, le demandeur et un annuaire (Figure 3-5). Le fournisseur crée un service, puis publie l adresse qui permet d y accéder (URI : Uniform Resource Identifier) dans un annuaire de services web, tel que l annuaire UDDI. Ce dernier rend disponible l interface du service ainsi que ses informations d accès, pour n importe quel demandeur. Ainsi, ce dernier accède à l annuaire UDDI (Universal Description Discovery and Integration) pour effectuer une recherche afin de trouver le service désiré en précisant ses caractéristiques. Enfin, il se connecte au fournisseur du service désiré afin d acquérir la description et le format d appel qui vont lui permettre, ensuite, d invoquer correctement ce service web. 65

85 Les standards des services web Les Services Web se basent sur un ensemble de standards formant une pile protocolaire (Figure 3-6) : XML (extensible Markup Language) [BRA 08], SOAP (Simple Object Access Protocol) [BOX 07], WSDL (Web Service Description Langage) [CHR 01] et UDDI (Universal Description Discovery and Integration) [BEL 02]. Dans cette pile, le protocole HTTP (Hyper Text Transfer Protocol) se trouve au niveau de la couche de transfert des messages. Au dessus de cette couche, le protocole SOAP est utilisé dans la structuration des messages à transmettre. Ensuite, le langage WSDL permet de décrire les services web. Enfin, un processus de découverte des services web, tel que UDDI, peut figurer dans cette pile. Ces protocoles et standards sont basés sur le langage XML. Figure 3-6 : Pile protocolaire des services web [BOO 04] extensible Markup Language (XML) XML permet de définir un langage à travers un vocabulaire et une grammaire associée. Les langages basés sur XML peuvent être utilisés pour décrire toutes sortes de données et de textes tels que les messages SOAP et les descriptions WSDL. Un fichier XML est un document texte qui a une structure hiérarchique en éléments. En effet, un élément peut contenir du texte ou d autres éléments et toutes les données d un document XML sont contenues dans un élément racine. Un document XML est dit bien formé, quand il est conforme à un certain nombre de règles. S il est bien formé et conforme à la grammaire associée, le document XML est alors qualifié de valide. La grammaire d un langage basé sur XML peut être définie, soit en format DTD (Document Type Definition), soit en format XSD (XML Schema Definition) [THO 01]-[BIR 01]. Dans la suite, nous utilisons le format XSD afin de définir de façon structurée le type de contenu, la syntaxe et la sémantique des messages SOAP échangés (cf. section 3.4.3) ainsi que le SLS [CHA 07] négocié (cf. section 3.4.4) Simple Object Access Protocol (SOAP) Le protocole SOAP définit un ensemble de règles pour structurer des messages qui peuvent être utilisés dans de simples transmissions unidirectionnelles, mais il est aussi particulièrement utile pour exécuter des dialogues de type requête/réponse. Un message SOAP est un document XML dont l élément racine <Envelope> contient un élément optionnel <Header> et un élément obligatoire <Body> qui contient les données échangées (Figure 3-7). 66

Négociation de niveau de service dans les environnements ubiquitaires

Négociation de niveau de service dans les environnements ubiquitaires Négociation de niveau de service dans les environnements ubiquitaires Mohamed Aymen Chalouf* - Francine Krief* * Université de Bordeaux, LaBRI, chalouf@labri.fr, krief@labri.fr RESUME. La connectivité

Plus en détail

Convergence. Introduction (1/24) Introduction (2/24) Introduction (4/24) Introduction (3/24)

Convergence. Introduction (1/24) Introduction (2/24) Introduction (4/24) Introduction (3/24) Introduction (1/24) Internet = Interconnexion de réseaux et Services Informatiques (Années 60) Applications Informatiques: Transfert de fichier, Messagerie, News Internet = Interconnexion de réseaux et

Plus en détail

NGN Next Generation Network Réseau de Nouvelle Génération. Dr. Najjar Monia

NGN Next Generation Network Réseau de Nouvelle Génération. Dr. Najjar Monia 2015 NGN Next Generation Network Réseau de Nouvelle Génération Dr. Najjar Monia Les NGN sont basés sur une évolution progressive vers le «tout IP» et sont modélisés en couches indépendantes dialoguant

Plus en détail

M. BOUGUERRA A. CHEF DEPARTEMENT FTTx Algérie Telecom

M. BOUGUERRA A. CHEF DEPARTEMENT FTTx Algérie Telecom M. BOUGUERRA A. CHEF DEPARTEMENT FTTx Algérie Telecom 1 2 Définition : IPTV = (IP) + (TV) IPTV est un acronyme pour le protocole Internet Protocole TV. Il est essentiellement une technologie qui offre

Plus en détail

Programme scientifique Majeure RESEAUX ET SERVICES. Mentions Conception et Architectures des réseaux Sécurité et Cryptographie

Programme scientifique Majeure RESEAUX ET SERVICES. Mentions Conception et Architectures des réseaux Sécurité et Cryptographie É C O L E D I N G É N I E U R D E S T E C H N O L O G I E S D E L I N F O R M A T I O N E T D E L A C O M M U N I C A T I O N Programme scientifique Majeure RESEAUX ET SERVICES Java Mentions Conception

Plus en détail

Description des UE s du M2

Description des UE s du M2 Parcours en deuxième année Unités d Enseignement (UE) ECTS Ingénierie des réseaux haut 4 débit Sécurité des réseaux et 4 télécoms Réseaux mobiles et sans fil 4 Réseaux télécoms et 4 convergence IP Infrastructure

Plus en détail

Téléphonie. sur IP. 2 e édition

Téléphonie. sur IP. 2 e édition Téléphonie sur IP 2 e édition SIP, H.323, MGCP, QoS et sécurité, Asterisk, VoWiFi, offre multiplay des FAI, Skype et autres softphones, architecture IMS Laurent Ouakil Guy Pujolle Table des matières Avant-propos................................................

Plus en détail

Table des matières. 1 Vue d ensemble des réseaux... 5. 2 Transmission des données : comment fonctionnent les réseaux... 23. Introduction...

Table des matières. 1 Vue d ensemble des réseaux... 5. 2 Transmission des données : comment fonctionnent les réseaux... 23. Introduction... Table des matières Introduction 1 Structure du livre 2 Nouveautés par rapport à la 3 e édition 2 Conventions typographiques 3 1 Vue d ensemble des réseaux 5 Qu est-ce qu un réseau? 6 Pourquoi créer un

Plus en détail

2A-SI - Réseaux : Modèles d architecture réseau

2A-SI - Réseaux : Modèles d architecture réseau 2A-SI - Réseaux : Modèles d architecture réseau Stéphane Vialle Stephane.Vialle@supelec.fr http://www.metz.supelec.fr/~vialle 1 Modèles d architecture réseau 1. Caractéristiques des modèles en couche 2.

Plus en détail

Plan. 1. Introduction. 1.1 Notion de réseau. Réseau extrémité. Le cœur du réseau. Les Protocoles de Télécommunications Evolution Internet Cours de DEA

Plan. 1. Introduction. 1.1 Notion de réseau. Réseau extrémité. Le cœur du réseau. Les Protocoles de Télécommunications Evolution Internet Cours de DEA Plan Les Protocoles de Télécommunications Evolution Internet Cours de DEA Isabelle CHRISMENT ichris@loria.fr Introduction Routage dans l Internet IPv6 Communication de groupes et l Internet x sans fils,

Plus en détail

Internet. PC / Réseau

Internet. PC / Réseau Internet PC / Réseau Objectif Cette présentation reprend les notions de base : Objectif, environnement de l Internet Connexion, fournisseurs d accès Services Web, consultation, protocoles Modèle en couches,

Plus en détail

Dr Rim Belhassine-Cherif Directeur de Développement de Produits et Services. r.cherif@ttnet.tn

Dr Rim Belhassine-Cherif Directeur de Développement de Produits et Services. r.cherif@ttnet.tn Expérience VoIP de Tunisie TélécomT Dr Rim Belhassine-Cherif Directeur de Développement de Produits et Services r.cherif@ttnet.tn Regional Seminar on IP Communications Hammamet-Tunisia, 24-25 November

Plus en détail

Editeur de solutions innovantes C 3. Solution globale managée de communication et de téléphonie sur IP

Editeur de solutions innovantes C 3. Solution globale managée de communication et de téléphonie sur IP Editeur de solutions innovantes C 3 Solution globale managée de communication et de téléphonie sur IP Intelligence et fiabilité au coeur du système de communication de l entreprise de manière simple et

Plus en détail

LAN Intégré : accéder

LAN Intégré : accéder LAN Intégré : accéder accédez à votre réseau local sans contrainte de lieu ni de temps La solution WLAN (Wireless Local Area Network) pour réseaux locaux sans fil fonctionne de la même manière que les

Plus en détail

Livre banc. Contrôle de trajet dynamique : la base de votre WAN hybride

Livre banc. Contrôle de trajet dynamique : la base de votre WAN hybride Contrôle de trajet dynamique : la base de votre WAN hybride Le réseau étendu (WAN, wide area network) a connu bien peu d innovations pendant une grande partie de la dernière décennie. Alors que le reste

Plus en détail

RESEAU MULTISERVICES LARGE BANDE DE TECHNOLOGIE IP/MPLS D ALGERIE TELECOM

RESEAU MULTISERVICES LARGE BANDE DE TECHNOLOGIE IP/MPLS D ALGERIE TELECOM RESEAU MULTISERVICES LARGE BANDE DE TECHNOLOGIE IP/MPLS D ALGERIE TELECOM Séminaire régional sur l accès hertzien mobile et fixe pour les applications large bande dans la région des Etats arabes. Co organisé

Plus en détail

Administration réseau Introduction

Administration réseau Introduction Administration réseau Introduction A. Guermouche A. Guermouche Cours 1 : Introduction 1 Plan 1. Introduction Organisation Contenu 2. Quelques Rappels : Internet et le modèle TCP/ Visage de l Internet Le

Plus en détail

Cours CCNA 1. Exercices

Cours CCNA 1. Exercices Cours CCNA 1 TD2 Exercices Exercice 1 : Dressez la liste des 5 périphériques finaux, 6 périphériques intermédiaires et 3 formes de support réseau. Périphériques finaux (hôtes): ordinateur de bureau, ordinateur

Plus en détail

Services réseau. 6.1 Clients, serveurs et leur interaction. 6.1.1 Relation client-serveur

Services réseau. 6.1 Clients, serveurs et leur interaction. 6.1.1 Relation client-serveur Page 1 sur 35 Services réseau 6.1 Clients, serveurs et leur interaction 6.1.1 Relation client-serveur Tous les jours, nous utilisons les services disponibles sur les réseaux et sur Internet pour communiquer

Plus en détail

Séminaire régional sur les coûts et tarifs pour les pays Membres du Groupe régional pour l Afrique (SG3RG-AFR)

Séminaire régional sur les coûts et tarifs pour les pays Membres du Groupe régional pour l Afrique (SG3RG-AFR) Séminaire régional sur les coûts et tarifs pour les pays Membres du Groupe régional pour l Afrique (SG3RG-AFR) Enjeux et Réglementation de la VoIP Abossé AKUE-KPAKPO Telecom Manager Chair SG3RG-AFR +226

Plus en détail

Architectures de communication. «Architecture protocolaire réseau» «protocolaire»

Architectures de communication. «Architecture protocolaire réseau» «protocolaire» Architectures de communication C. Pham Université de Pau et des Pays de l Adour Département Informatique http://www.univ-pau.fr/~cpham Congduc.Pham@univ-pau.fr «Architecture protocolaire réseau» Architecture

Plus en détail

Cours réseaux Modèle OSI

Cours réseaux Modèle OSI Cours réseaux Modèle OSI IUT 1 Université de Lyon Introduction: le modèle OSI Un modèle théorique : le modèle OSI (Open System Interconnection) A quoi ça sert: Nécessité de découper/classifier l ensemble

Plus en détail

Réseaux grande distance

Réseaux grande distance Chapitre 5 Réseaux grande distance 5.1 Définition Les réseaux à grande distance (WAN) reposent sur une infrastructure très étendue, nécessitant des investissements très lourds. Contrairement aux réseaux

Plus en détail

Stella MARC-ZWECKER. Téléinformatique 1. Objectifs du cours. Réseaux et Protocoles - L3 info

Stella MARC-ZWECKER. Téléinformatique 1. Objectifs du cours. Réseaux et Protocoles - L3 info Objectifs du cours Réseaux et Protocoles - L3 info Stella MARC-ZWECKER Maître de conférences Dpt. Informatique ULP stella@dpt-info.u-strasbg.fr Mécanismes de base de la transmission des données dans les

Plus en détail

Conception d un outil d aide au déploiement d un réseau EV-DO dans un concept IMS pour l opérateur CAMTEL

Conception d un outil d aide au déploiement d un réseau EV-DO dans un concept IMS pour l opérateur CAMTEL Conception d un outil d aide au déploiement d un réseau EV-DO dans un concept IMS pour l opérateur CAMTEL L outil à développer devra donner la possibilité de planifier tout d abord un réseau EV-DO Rev

Plus en détail

1.1.3 Qu est-ce qu un réseau convergent?

1.1.3 Qu est-ce qu un réseau convergent? Chapitre 1 Quelle couche du modèle de conception de réseau hiérarchique est le backbone à haut débit de l interréseau, où haute disponibilité et redondance sont vitales? Couche d accès Couche cœur de réseau

Plus en détail

et contrôle de topologie dans les Support de la qualité de service réseaux mobiles ad hoc rabah.meraihi@enst.fr GET / Télécom Paris Rabah Meraihi

et contrôle de topologie dans les Support de la qualité de service réseaux mobiles ad hoc rabah.meraihi@enst.fr GET / Télécom Paris Rabah Meraihi Support de la qualité de service et contrôle de topologie dans les réseaux mobiles ad hoc Rabah Meraihi GET / Télécom Paris rabah.meraihi@enst.fr Rabah Meraihi 1 Plan 1. Introduction et contexte 2. Qualité

Plus en détail

PROGRAMME DETAILLE CERTIFICAT D ENSEIGNEMENT SPECIALISE Accrédité B.A.D.G.E par la Conférence des Grandes Ecoles

PROGRAMME DETAILLE CERTIFICAT D ENSEIGNEMENT SPECIALISE Accrédité B.A.D.G.E par la Conférence des Grandes Ecoles RESEAUX ET SERVICES TELECOM PROGRAMME DETAILLE CERTIFICAT D ENSEIGNEMENT SPECIALISE Accrédité B.A.D.G.E par la Conférence des Grandes Ecoles PROGRAMME TOTAL : 279 h Sur 6 mois ½ environ En Alternance Présentiel,

Plus en détail

La neutralité des réseaux

La neutralité des réseaux 7 ème séminaire de FRATEL Tunis 27-28 avril 2010 La neutralité des réseaux & la gestion de trafic Sihem Trabelsi Chef de Service Unité de dégroupage de la boucle locale Instance Nationale des Télécommunications

Plus en détail

Organisation du parcours M2 IR Les unités d enseignements (UE) affichées dans la partie tronc commun sont toutes obligatoires, ainsi que le stage et

Organisation du parcours M2 IR Les unités d enseignements (UE) affichées dans la partie tronc commun sont toutes obligatoires, ainsi que le stage et Organisation du parcours M2 IR Les unités d enseignements (UE) affichées dans la partie tronc commun sont toutes obligatoires, ainsi que le stage et l'anglais. L'étudiant a le choix entre deux filières

Plus en détail

Les Réseaux Informatiques

Les Réseaux Informatiques Les Réseaux Informatiques Licence Informatique, filière SMI Université Mohammed-V Agdal Faculté des Sciences Rabat, Département Informatique Avenue Ibn Batouta, B.P. 1014 Rabat Professeur Enseignement

Plus en détail

SOMMAIRE Thématique : Réseaux et télécommunications

SOMMAIRE Thématique : Réseaux et télécommunications SOMMAIRE Thématique : Réseaux et télécommunications Rubrique : Réseaux - Télécommunications... 2 1 SOMMAIRE Rubrique : Réseaux - Télécommunications Evolution et perspective des réseaux et télécommunications...

Plus en détail

PLUS AUCUN SOUCI Déploie les Réseaux et Relie les Hommes

PLUS AUCUN SOUCI Déploie les Réseaux et Relie les Hommes PLUS AUCUN SOUCI Déploie les Réseaux et Relie les Hommes 1 Conférence-Débat Les Performances du Réseau Multiservices d Entreprise (Convergence Voix, Vidéo et Données) Modèle d économie Internet 2 Sommaire

Plus en détail

L3 informatique Réseaux : Configuration d une interface réseau

L3 informatique Réseaux : Configuration d une interface réseau L3 informatique Réseaux : Configuration d une interface réseau Sovanna Tan Septembre 2009 Révision septembre 2012 1/23 Sovanna Tan Configuration d une interface réseau Plan 1 Introduction aux réseaux 2

Plus en détail

2. DIFFÉRENTS TYPES DE RÉSEAUX

2. DIFFÉRENTS TYPES DE RÉSEAUX TABLE DES MATIÈRES 1. INTRODUCTION 1 2. GÉNÉRALITÉS 5 1. RÔLES DES RÉSEAUX 5 1.1. Objectifs techniques 5 1.2. Objectifs utilisateurs 6 2. DIFFÉRENTS TYPES DE RÉSEAUX 7 2.1. Les réseaux locaux 7 2.2. Les

Plus en détail

Réseaux Locaux. Objectif du module. Plan du Cours #3. Réseaux Informatiques. Acquérir un... Réseaux Informatiques. Savoir.

Réseaux Locaux. Objectif du module. Plan du Cours #3. Réseaux Informatiques. Acquérir un... Réseaux Informatiques. Savoir. Mise à jour: Mars 2012 Objectif du module Réseaux Informatiques [Archi/Lycée] http://fr.wikipedia.org/ Nicolas Bredèche Maître de Conférences Université Paris-Sud bredeche@lri.fr Acquérir un... Ressources

Plus en détail

Cisco Secure Access Control Server Solution Engine. Introduction. Fiche Technique

Cisco Secure Access Control Server Solution Engine. Introduction. Fiche Technique Fiche Technique Cisco Secure Access Control Server Solution Engine Cisco Secure Access Control Server (ACS) est une solution réseau d identification complète qui offre à l utilisateur une expérience sécurisée

Plus en détail

Les télécommunications contemporaines, systèmes complexes? Philippe Picard, le 14 mai 2011. Page 1

Les télécommunications contemporaines, systèmes complexes? Philippe Picard, le 14 mai 2011. Page 1 Les télécommunications contemporaines, systèmes complexes? Philippe Picard, le 14 mai 2011. Page 1 Une accélération de l histoire 120 ans Révolution numérique Télégraphe Téléphone radio Télévision Internet

Plus en détail

CAS IT-Interceptor. Formation «Certificate of Advanced Studies»

CAS IT-Interceptor. Formation «Certificate of Advanced Studies» CAS IT-Interceptor Formation «Certificate of Advanced Studies» Description détaillée des contenus de la formation. Structure, objectifs et contenu de la formation La formation est structurée en 3 modules

Plus en détail

GLOSSAIRE DE LA TECHNOLOGIE MOBILE

GLOSSAIRE DE LA TECHNOLOGIE MOBILE GLOSSAIRE DE LA TECHNOLOGIE MOBILE PROFITEZ DU RÉSEAU. maintenant. Glossaire Glossaire de la technologie mobile 3G Accès distant Adaptateur Client sans fil ADSL AVVID Carte réseau Convergence GPRS Haut

Plus en détail

Regional Development Forum 2008 Bridging the Standardization Gap in Developing Countries. Accra, Ghana, 26-28 May 2008

Regional Development Forum 2008 Bridging the Standardization Gap in Developing Countries. Accra, Ghana, 26-28 May 2008 Regional Development Forum 2008 Bridging the Standardization Gap in Developing Countries Scénario et Stratégie de migration vers les réseaux NGN-Sonatel USE CASE Modou SALL, Sonatel Union Contexte Sommaire

Plus en détail

1 Généralité sur les services UMTS

1 Généralité sur les services UMTS Sécurité des réseaux mobiles de 3ème génération Constantin Yamkoudougou Ingénieur Réseaux Télécoms & Sécurité, projet PICSI Laboratoire XLIM UMR CNRS 6172 - Limoges 28 janvier 2005 UMTS ou 3G, quels sont

Plus en détail

Les cinq raisons majeures pour déployer SDN (Software-Defined Networks) et NFV (Network Functions Virtualization)

Les cinq raisons majeures pour déployer SDN (Software-Defined Networks) et NFV (Network Functions Virtualization) Les cinq raisons majeures pour déployer SDN (Software-Defined Networks) et NFV (Network Functions Virtualization) Préparé par : Zeus Kerravala Les cinq raisons majeures pour déployer SDN et NFV NetworkWorld,

Plus en détail

Parcours en deuxième année

Parcours en deuxième année Parcours en deuxième année Unités d Enseignement (UE) ECTS Ingénierie des réseaux haut 4 débit Sécurité des réseaux et 4 télécoms Réseaux mobiles et sans fil 4 Réseaux télécoms et 4 convergence IP Infrastructure

Plus en détail

INTERCONNECTION CHALLENGES

INTERCONNECTION CHALLENGES INTERCONNECTION CHALLENGES PLAN Interconnexion: évolution Interaction entre développement de l Internet et interconnexion Marché Internet au Maroc et dans la région INTERCONNEXION TELECOMS: ÉVOLUTION Avant

Plus en détail

Les MPLS (Multiprotocol Label Switching) VPNs (Virtual Private Network) sont de

Les MPLS (Multiprotocol Label Switching) VPNs (Virtual Private Network) sont de Abstract Les MPLS (Multiprotocol Label Switching) VPNs (Virtual Private Network) sont de nouvelles alternatives pour sécuriser et améliorer le WANs (Wide Area Network). De plus en plus ils gagnent du terrain

Plus en détail

Groupe Eyrolles, 2000, 2004, ISBN : 2-212-11330-7

Groupe Eyrolles, 2000, 2004, ISBN : 2-212-11330-7 Groupe Eyrolles, 2000, 2004, ISBN : 2-212-11330-7 Sommaire Cours 1 Introduction aux réseaux 1 Les transferts de paquets... 2 Les réseaux numériques... 4 Le transport des données... 5 Routage et contrôle

Plus en détail

Services Réseaux - Couche Application. TODARO Cédric

Services Réseaux - Couche Application. TODARO Cédric Services Réseaux - Couche Application TODARO Cédric 1 TABLE DES MATIÈRES Table des matières 1 Protocoles de gestion de réseaux 3 1.1 DHCP (port 67/68)....................................... 3 1.2 DNS (port

Plus en détail

BASES DES RESEAUX UNITE DE FORMATION

BASES DES RESEAUX UNITE DE FORMATION MINISTERE DE LA COMMUNAUTE FRANCAISE ADMINISTRATION GENERALE DE L ENSEIGNEMENT ET DE LA RECHERCHE SCIENTIFIQUE ENSEIGNEMENT DE PROMOTION SOCIALE DE REGIME 1 DOSSIER PEDAGOGIQUE BASES DES RESEAUX UNITE

Plus en détail

Plan. Programmation Internet Cours 3. Organismes de standardisation

Plan. Programmation Internet Cours 3. Organismes de standardisation Plan Programmation Internet Cours 3 Kim Nguy ên http://www.lri.fr/~kn 1. Système d exploitation 2. Réseau et Internet 2.1 Principes des réseaux 2.2 TCP/IP 2.3 Adresses, routage, DNS 30 septembre 2013 1

Plus en détail

Plan. Les pare-feux (Firewalls) Chapitre II. Introduction. Notions de base - Modèle de référence OSI : 7 couches. Introduction

Plan. Les pare-feux (Firewalls) Chapitre II. Introduction. Notions de base - Modèle de référence OSI : 7 couches. Introduction Plan Introduction Chapitre II Les pare-feux (Firewalls) Licence Appliquée en STIC L2 - option Sécurité des Réseaux Yacine DJEMAIEL ISET Com Notions de base relatives au réseau Définition d un pare-feu

Plus en détail

28 octobre 2010 INET-Tunis-2010. Atef LOUKIL atef@ati.tn

28 octobre 2010 INET-Tunis-2010. Atef LOUKIL atef@ati.tn IPv6 en Tunisie- État des lieux 28 octobre 2010 INET-Tunis-2010 Atef LOUKIL atef@ati.tn Infrastructure Backbone Multiservices IP/MPLS 50 Gbps bande passante internationale FSI 1 Internet Backbone IP/MPLS

Plus en détail

Les Réseaux Haut Débit. Dr. Tarek Nadour

Les Réseaux Haut Débit. Dr. Tarek Nadour Les Réseaux Haut Débit Dr. Tarek Nadour Les Services à valeurs ajoutées La Voix/Vidéo sur IP Plan Pourquoi la téléphonie sur IP? Evolution de la téléphonie classique vers la ToIP Architecture ToIP: H323

Plus en détail

Les Réseaux : Quelques Notions de base. Cycle de formation Ramage 2 Mars 2011

Les Réseaux : Quelques Notions de base. Cycle de formation Ramage 2 Mars 2011 Les Réseaux : Quelques Notions de base Cycle de formation Ramage 2 Mars 2011 1 Agenda Concepts et introduction aux réseaux Les Réseaux Locaux Internet Le Web Les Réseaux longue distance Exercices pratiques

Plus en détail

Qualité du service et VoiP:

Qualité du service et VoiP: Séminaire régional sur les coûts et tarifs pour les pays membres du Groupe AF Bamako (Mali), 7-9 avril 2003 1 Qualité du service et VoiP: Aperçu général et problèmes duvoip Mark Scanlan Aperçu général

Plus en détail

Réseaux informatiques

Réseaux informatiques Page 1 sur 8 Réseaux informatiques Introduction Matériel Logiciel Internet Introduction Réseau d'ordinateurs: Ensemble de machines connectées par un média leur permettant d'échanger des informations Matériel

Plus en détail

Nicolas Baudru mél : nicolas.baudru@esil.univmed.fr page web : nicolas.baudru.perso.esil.univmed.fr

Nicolas Baudru mél : nicolas.baudru@esil.univmed.fr page web : nicolas.baudru.perso.esil.univmed.fr Année 2010-2011 Réseaux I Conclusion : retour sur l architecture protocolaire Nicolas Baudru mél : nicolas.baudru@esil.univmed.fr page web : nicolas.baudru.perso.esil.univmed.fr 1 Plan 1 Rappels 2 Le dialogue

Plus en détail

Fax sur IP. Panorama

Fax sur IP. Panorama Fax sur IP Panorama Mars 2012 IMECOM Groupe prologue - Z.A. Courtaboeuf II - 12, avenue des Tropiques - B.P. 73-91943 LES ULIS CEDEX - France Phone : + 33 1 69 29 39 39 - Fax : + 33 1 69 28 89 55 - http://www.prologue.fr

Plus en détail

Formation Réseaux : Notions de base

Formation Réseaux : Notions de base Formation x Formation Réseaux : Notions Jean-Philippe André (), p2009 3. Couche Septembre 2007 Que sont les x? Formation x Wikipedia.org : Un est un ensemble de nœuds (ou pôles) reliés entre eux par des

Plus en détail

Une approche descendante

Une approche descendante Internet Une approche descendante P. Bakowski bako@ieee.org Qu'est-ce que l'internet? réseau mondial P. Bakowski 2 Des liens câbles métalliques, fibres optiques, liens radio - débit en bits/s P. Bakowski

Plus en détail

Mise en œuvre et résultats des tests de transfert de la voix sur le Protocole Internet V.o.I.P

Mise en œuvre et résultats des tests de transfert de la voix sur le Protocole Internet V.o.I.P Ministère de la Poste et des Technologies de l Information et des Communications Journée d étude sur la VoIP Mise en œuvre et résultats des tests de transfert de la voix sur le Protocole Internet V.o.I.P

Plus en détail

THÈSE. présentée à TÉLÉCOM PARISTECH. pour obtenir le grade de. DOCTEUR de TÉLÉCOM PARISTECH. Mention Informatique et Réseaux. par.

THÈSE. présentée à TÉLÉCOM PARISTECH. pour obtenir le grade de. DOCTEUR de TÉLÉCOM PARISTECH. Mention Informatique et Réseaux. par. École Doctorale d Informatique, Télécommunications et Électronique de Paris THÈSE présentée à TÉLÉCOM PARISTECH pour obtenir le grade de DOCTEUR de TÉLÉCOM PARISTECH Mention Informatique et Réseaux par

Plus en détail

2009/2010 DESCRIPTIF DES UNITES D ENSEIGNEMENT OPTIONNELLES SPECIALITE RIM

2009/2010 DESCRIPTIF DES UNITES D ENSEIGNEMENT OPTIONNELLES SPECIALITE RIM DESCRIPTIF DES UNITES D ENSEIGNEMENT OPTIONNELLES SPECIALITE RIM Réseaux d infrastructure L évolution du marché des télécommunications conduit à cette dualité : du côté applicatif : il y a une convergence

Plus en détail

DIFF DE BASE. Serendip serendip@via.ecp.fr. Samy samy@via.ecp.fr

DIFF DE BASE. Serendip serendip@via.ecp.fr. Samy samy@via.ecp.fr DIFF DE BASE Serendip serendip@via.ecp.fr Samy samy@via.ecp.fr I. INTRODUCTION AU RÉSEAU RÉSEAU : /ʁE.ZO/ N.M. DÉR., AU MOYEN DU SUFF. -EAU, DE L'A. FR. REIZ, REZ «FILET» (RETS); RÉSEAU A ÉTÉ EN CONCURRENCE

Plus en détail

RTSP - Introduction (1/2)

RTSP - Introduction (1/2) RTSP - Introduction (1/2) Protocol suite: TCP/IP. Type: Application layer protocol. Working group: mmusic, Multiparty Multimedia, Session Control RFC 2326: «RTSP is an application-level protocol for control

Plus en détail

QoS et Multimédia SIR / RTS. Introduction / Architecture des applications multimédia communicantes

QoS et Multimédia SIR / RTS. Introduction / Architecture des applications multimédia communicantes QoS et Multimédia SIR / RTS Introduction / Architecture des applications multimédia communicantes Isabelle Guérin Lassous Isabelle.Guerin-Lassous@ens-lyon.fr http://perso.ens-lyon.fr/isabelle.guerin-lassous

Plus en détail

Groupe Eyrolles, 2001, 2004, ISBN : 2-212-11258-0

Groupe Eyrolles, 2001, 2004, ISBN : 2-212-11258-0 Groupe Eyrolles, 2001, 2004, ISBN : 2-212-11258-0 Table des matières PREMIÈRE PARTIE LES RÉSEAUX LOCAUX CHAPITRE 1 Installer son premier réseau local 3 Le contexte...4 Les choix de base...5 Quel réseau?...

Plus en détail

SEMINAIRES & ATELIERS EN TÉLÉCOMMUNICATIONS RESEAUX

SEMINAIRES & ATELIERS EN TÉLÉCOMMUNICATIONS RESEAUX SEMINAIRES & ATELIERS EN TÉLÉCOMMUNICATIONS & RESEAUX SEMINAIRE ATELIER SUR LA TELEPHONIE ET LA VOIX SUR IP (T-VoIP): DE LA THEORIE A LA PRATIQUE DEPLOIEMENT D UNE PLATEFORME DE VoIP AVEC ASTERIK SOUS

Plus en détail

Réseaux - Cours 3. IP : introduction et adressage. Cyril Pain-Barre. Semestre 1 - version du 13/11/2009. IUT Informatique Aix-en-Provence

Réseaux - Cours 3. IP : introduction et adressage. Cyril Pain-Barre. Semestre 1 - version du 13/11/2009. IUT Informatique Aix-en-Provence Réseaux - Cours 3 IP : introduction et adressage Cyril Pain-Barre IUT Informatique Aix-en-Provence Semestre 1 - version du 13/11/2009 1/32 Cyril Pain-Barre IP : introduction et adressage 1/24 TCP/IP l

Plus en détail

La VoIP & la convergence

La VoIP & la convergence République Algérienne Démocratique D et Populaire Autorité de Régulation R de la Poste et des Télécommunications La VoIP & la convergence Par M me Leila CHERID Département Veille Technologique Direction

Plus en détail

PROGRAMME DETAILLE CERTIFICAT D ENSEIGNEMENT SPECIALISE Accrédité B.A.D.G.E par la Conférence des Grandes Ecoles

PROGRAMME DETAILLE CERTIFICAT D ENSEIGNEMENT SPECIALISE Accrédité B.A.D.G.E par la Conférence des Grandes Ecoles RESEAUX ET SERVICES TELECOM PROGRAMME DETAILLE CERTIFICAT D ENSEIGNEMENT SPECIALISE Accrédité B.A.D.G.E par la Conférence des Grandes Ecoles PROGRAMME TOTAL : 29 h Sur 6 mois ½ environ En Alternance Présentiel,

Plus en détail

GSM UMTS. Voix, Data, Téléphonie, Vidéo, 802.5 MAN IBM -> Token Ring - > FDDI -> FDDI II AT&T -> DQDB (155Mb/s) (Double Queuing Double Bus)

GSM UMTS. Voix, Data, Téléphonie, Vidéo, 802.5 MAN IBM -> Token Ring - > FDDI -> FDDI II AT&T -> DQDB (155Mb/s) (Double Queuing Double Bus) Réseaux Publics Jeanluc.langbois@orange-ftgroup.com Avec Fil X25 -> -> MPLS (MPλS / GMPLS) -> xdsl ->Frame Relay Frame Switching X21 -> RTC RTNM : Réseau Transmission Numérique Multiplexé RTNM + X25 +RTC

Plus en détail

SÛRETÉ DE FONCTIONNEMENT ET ARCHITECTURE GVA SÉMINAIRE ARCHITECTURES AGILES DE SYSTÈMES COMPLEXES BASÉES SUR DDS, LA VÉTRONIQUE EN CAS D EXEMPLE

SÛRETÉ DE FONCTIONNEMENT ET ARCHITECTURE GVA SÉMINAIRE ARCHITECTURES AGILES DE SYSTÈMES COMPLEXES BASÉES SUR DDS, LA VÉTRONIQUE EN CAS D EXEMPLE SÛRETÉ DE FONCTIONNEMENT ET ARCHITECTURE GVA SÉMINAIRE ARCHITECTURES AGILES DE SYSTÈMES COMPLEXES BASÉES SUR DDS, LA VÉTRONIQUE EN CAS D EXEMPLE PLAN Architecture GVA et NGVA SDF dans Architecture GVA

Plus en détail

DOSSIER SOLUTION CA Service Assurance Mai 2010. assurez la qualité et la disponibilité des services fournis à vos clients

DOSSIER SOLUTION CA Service Assurance Mai 2010. assurez la qualité et la disponibilité des services fournis à vos clients DOSSIER SOLUTION CA Service Assurance Mai 2010 assurez la qualité et la disponibilité des services fournis à vos clients est un portefeuille de solutions de gestion matures et intégrées, qui contribue

Plus en détail

1.Introduction - Modèle en couches - OSI TCP/IP

1.Introduction - Modèle en couches - OSI TCP/IP 1.Introduction - Modèle en couches - OSI TCP/IP 1.1 Introduction 1.2 Modèle en couches 1.3 Le modèle OSI 1.4 L architecture TCP/IP 1.1 Introduction Réseau Télécom - Téléinformatique? Réseau : Ensemble

Plus en détail

Une infrastructure de réseau de pointe pour l univers multimédia de demain

Une infrastructure de réseau de pointe pour l univers multimédia de demain Une infrastructure de réseau de pointe pour l univers multimédia de demain Patrice Haldemann, Swisscom Fixnet SA 31 octobre 2006 1 La structure Triple Play: 3 domaines Client Maison Infrastructure de réseau

Plus en détail

INTRODUCTION AUX RÉSEAUX SANS INFRASTRUCTURE DÉDIÉE

INTRODUCTION AUX RÉSEAUX SANS INFRASTRUCTURE DÉDIÉE INTRODUCTION AUX RÉSEAUX SANS INFRASTRUCTURE DÉDIÉE Par Michèle Germain Consultante Edition 2 / Février 2011 QUELS SONT-ILS? La forme élémentaire d un réseau est une dorsale filaire sur laquelle se raccordent

Plus en détail

Solution de téléphonie IP convergente d Allstream

Solution de téléphonie IP convergente d Allstream Solution de téléphonie IP convergente d Allstream Solution de lignes groupées IP Document de présentation technique 1 Table des matières Introduction 1 Lignes d accès classiques : un bref survol 1 Lignes

Plus en détail

Cahier des Clauses Techniques Particulières. Convergence Voix - Données

Cahier des Clauses Techniques Particulières. Convergence Voix - Données Cahier des Clauses Techniques Particulières Convergence Voix - Données SOMMAIRE - Objet du document et du marché - Contexte et périmètre du projet - Configurations existantes et besoins - Services attendus

Plus en détail

Vers l Internet 2... - Synthèse Bibliographique -

Vers l Internet 2... - Synthèse Bibliographique - Vers l Internet 2... - Synthèse Bibliographique - Introduction Vers l Internet 2... I - II - L Internet : historique et état des lieux Les moyens de l évolution III - La conduite du changement I - Internet

Plus en détail

SDN / Open Flow dans le projet de recherche de GEANT (GN3+)

SDN / Open Flow dans le projet de recherche de GEANT (GN3+) SDN / Open Flow dans le projet de recherche de GEANT (GN3+) Xavier Jeannin GIP RENATER 23-25, rue Daviel 75013 PARIS Résumé Dans le cadre du projet GN3+ (avril 2013 Mars 2015), parmi la tâche orientée

Plus en détail

Les réseaux de campus. F. Nolot 2008 1

Les réseaux de campus. F. Nolot 2008 1 Les réseaux de campus F. Nolot 2008 1 Les réseaux de campus Les architectures F. Nolot 2008 2 Les types d'architectures L'architecture physique d'un réseau de campus doit maintenant répondre à certains

Plus en détail

Architecture des réseaux NGN

Architecture des réseaux NGN Séminaire régional r du BDT / UIT Coûts et tarification pour les pays membres du Groupe de tarification pour l Afrique Johannesburg, Afrique du Sud, juin 2005 Architecture des réseaux NGN Oscar González

Plus en détail

Votre Réseau est-il prêt?

Votre Réseau est-il prêt? Adapter les Infrastructures à la Convergence Voix Données Votre Réseau est-il prêt? Conférence IDG Communications Joseph SAOUMA Responsable Offre ToIP Rappel - Définition Voix sur IP (VoIP) Technologie

Plus en détail

Le multitalent R&S CMW500, précurseur en matière de normes les plus récentes. RADIOCOMMUNICATION Bancs de mesure

Le multitalent R&S CMW500, précurseur en matière de normes les plus récentes. RADIOCOMMUNICATION Bancs de mesure Testeur de protocole UMTS LTE pour Avec de nouvelles options, le testeur de radiocommunication large bande R&S CMW500 UMTS évolue vers un testeur de protocole LTE et simule un Radio Access Network LTE

Plus en détail

PROBLEMATIQUES DES OPERATEURS MOBILES

PROBLEMATIQUES DES OPERATEURS MOBILES PROBLEMATIQUES DES OPERATEURS MOBILES p 1 PLAN de la Présentation o Généralités o Les infrastructures «DATA» d un opérateur mobile 2G/3G o Exemple d architecture d un réseau GPRS o Fonctionnement d un

Plus en détail

Conception d'une architecture commutée. Master 2 Professionnel STIC-Informatique 1

Conception d'une architecture commutée. Master 2 Professionnel STIC-Informatique 1 Conception d'une architecture commutée Master 2 Professionnel STIC-Informatique 1 Conception d'une architecture commutée Définition Master 2 Professionnel STIC-Informatique 2 Motivations L'architecture

Plus en détail

Réseaux, 4 e édition Andrew Tanenbaum

Réseaux, 4 e édition Andrew Tanenbaum Réseaux, 4 e édition Andrew Tanenbaum Table des matières détaillée Préface 1. Introduction 1.1 Usage des réseaux d ordinateurs 1.1.1 Applications professionnelles 1.1.2 Applications domestiques 1.1.3 Utilisateurs

Plus en détail

Services de vidéo en ligne

Services de vidéo en ligne Services de vidéo en ligne Dominique PRESENT Dépt S.R.C. - I.U.T. de Marne la Vallée Des services diversifiés Télévision numérique : s appuie sur des standards de format (standards ETSI) utilise plusieurs

Plus en détail

Partagez plus avec Christie Brio

Partagez plus avec Christie Brio Partagez plus avec Christie Brio Plus de productivité. Plus de travail en équipe. Plus de choix Sommaire Christie Brio Enterprise Guide de déploiement Présentation..2 Où installer le boitier sur le réseau..

Plus en détail

Présentation du modèle OSI(Open Systems Interconnection)

Présentation du modèle OSI(Open Systems Interconnection) Présentation du modèle OSI(Open Systems Interconnection) Les couches hautes: Responsables du traitement de l'information relative à la gestion des échanges entre systèmes informatiques. Couches basses:

Plus en détail

Principes de mise en réseau & Manuel d installation réseau pour l imprimante Crystal Printer

Principes de mise en réseau & Manuel d installation réseau pour l imprimante Crystal Printer Principes de mise en réseau & Manuel d installation réseau pour l imprimante Crystal Printer 1. Présentation Ce manuel fournit les connaissances de base sur la mise en place d un réseau sans fil pour que

Plus en détail

Analyse de sécurité des box ADSL

Analyse de sécurité des box ADSL Analyse de sécurité des box ADSL Yann Bachy 1,2,4, Vincent Nicomette 1,2, Eric Alata 1,2, Yves Deswarte 1,3, Mohamed Kaâniche 1,3 et Jean-Christophe Courrège 4 1 prénom.nom@laas.fr 4 prénom.nom@thalesgroup.com

Plus en détail

ACCESSNET -T IP Technique système TETRA d Hytera. www.hytera.de

ACCESSNET -T IP Technique système TETRA d Hytera. www.hytera.de Technique système TETRA d Hytera est la solution complète et performante pour toutes les applications de la téléphonie mobile professionnelle. www.hytera.de Bref aperçu Pour une communication TETRA professionnelle

Plus en détail

Introduction Arc r hi h t i e t c e tur u e r e IMS

Introduction Arc r hi h t i e t c e tur u e r e IMS CHAPITRE II IP MULTIMEDIA SUBSYSTEM (IMS) A.U: 2011/2012 2 PLAN Introduction Architecture IMS Entités fonctionnelles de l IMS Principaux protocoles utilisés en IMS Gestion des identités dans IMS Procédures

Plus en détail

Présentation et portée du cours : CCNA Exploration v4.0

Présentation et portée du cours : CCNA Exploration v4.0 Présentation et portée du cours : CCNA Exploration v4.0 Profil des participants Le cours CCNA Exploration s adresse aux participants du programme Cisco Networking Academy diplômés en ingénierie, mathématiques

Plus en détail

Profil de protection d un pare-feu industriel

Profil de protection d un pare-feu industriel Version 1.0 court-terme GTCSI 13 juillet 2015 Avant-propos Dans toute la suite de ce document, l acronyme ToE (Target of Evaluation) désigne le composant qui est l objet de l évaluation. Les passages en

Plus en détail

Formation SIARS. Principes de base TCP/IP QoS

Formation SIARS. Principes de base TCP/IP QoS Formation SIARS Principes de base TCP/IP QoS Plan La situation actuelle Qu est-ce que la QoS? DiffServ IntServ MPLS Conclusion La situation actuelle La situation actuelle La famille des protocoles TCP/IP

Plus en détail

ITC Corporate Connect

ITC Corporate Connect IT orporate onnect PRÉSENE LOALE PORTÉE GLOBALE IT orporate onnect IT orporate onnect A P E R Ç U D E L E N T R E P R I S E Pendant plus de dix ans, la société IT, et ses antécédents fournit les services

Plus en détail

Annexe A. Énoncé des travaux. Service d accès Internet local (SAIL) pour Services partagés Canada

Annexe A. Énoncé des travaux. Service d accès Internet local (SAIL) pour Services partagés Canada Annexe A Énoncé des travaux Service d accès Internet local (SAIL) pour Services partagés Canada Le 17 juin 2013 Version : D6 TABLE DES MATIÈRES 1 INTRODUCTION... 2 2 EXIGENCES GÉNÉRALES RELATIVES AU SERVICE

Plus en détail