Offre de service dans les réseaux de nouvelle...

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

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

N° d’ordre: 3905

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é

iv

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.

v

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.

vii

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 ......................................................................................................... 1

1.1 Contexte et motivations ........................................................................................................... 1

1.2 Contributions ............................................................................................................................. 2

1.3 Organisation de la thèse ........................................................................................................... 3

Chapitre 2 Les principaux besoins des réseaux NGN ....................................................... 6

2.1 Introduction ............................................................................................................................... 6

2.2 Evolution des réseaux .............................................................................................................. 6

2.2.1 Des réseaux dédiés ............................................................................................................... 6

2.2.2 L’Internet ............................................................................................................................... 7

2.2.3 La convergence des réseaux ................................................................................................ 7

2.2.4 Résumé ................................................................................................................................... 8

2.3 Les réseaux de nouvelle génération ........................................................................................ 8

2.3.1 Définition et principes fondamentaux .............................................................................. 8

2.3.2 Architectures des réseaux NGN ........................................................................................ 8

2.3.3 Caractéristiques des réseaux NGN .................................................................................. 10

2.3.3.1 Des terminaux de plus en plus sophistiqués ........................................................... 10

2.3.3.2 Des réseaux d’accès supportant des débits de plus en plus élevés ...................... 10

2.3.3.3 Des services de types variés ....................................................................................... 11

2.3.4 Résumé ................................................................................................................................. 11

2.4 La qualité de service (QoS : Quality of Service) ................................................................. 11

2.4.1 Définition et mécanismes élémentaires de la QoS ........................................................ 12

2.4.2 La QoS dans les réseaux IP .............................................................................................. 13

2.4.2.1 Le service garanti (IntServ : Integrated Services) ................................................... 13

2.4.2.2 La différenciation de services (DiffServ : Differentiated Services) ...................... 15

2.4.2.3 MPLS (MultiProtocol Label Switching) ................................................................... 18

2.4.3 La QoS dans les réseaux d’accès ...................................................................................... 20

2.4.3.1 Mécanismes de QoS dans les réseaux Wi-Fi ........................................................... 20

viii

2.4.3.2 Mécanismes de QoS dans les réseaux WiMax......................................................... 21

2.4.3.3 Mécanismes de QoS dans les réseaux Satellite ........................................................ 21

2.4.4 La QoS dans les réseaux NGN ........................................................................................ 22

2.4.5 Résumé ................................................................................................................................. 24

2.5 La sécurité ................................................................................................................................ 24

2.5.1 Attaques, services et opérations cryptographiques ....................................................... 25

2.5.1.1 Attaques de sécurité..................................................................................................... 25

2.5.1.2 Services de sécurité ...................................................................................................... 26

2.5.1.3 Notions de cryptographie ........................................................................................... 27

2.5.2 La sécurité dans les réseaux IP ......................................................................................... 30

2.5.2.1 Le protocole IPSec ...................................................................................................... 30

2.5.2.2 Le protocole TLS ......................................................................................................... 33

2.5.2.3 Le protocole DTLS ..................................................................................................... 37

2.5.3 La sécurité dans les réseaux d’accès ................................................................................. 38

2.5.3.1 La sécurité dans les réseaux mobiles ......................................................................... 38

2.5.3.2 La sécurité dans les réseaux Wi-Fi ............................................................................ 39

2.5.4 La sécurité dans les réseaux NGN ................................................................................... 42

2.5.5 Résumé ................................................................................................................................. 42

2.6 La mobilité ............................................................................................................................... 43

2.6.1 Mobilité au niveau « Réseau » ........................................................................................... 43

2.6.1.1 Fonctionnement de MIP ............................................................................................ 44

2.6.1.2 Le protocole MIPv6 .................................................................................................... 45

2.6.2 Mobilité au niveau « Transport » ...................................................................................... 45

2.6.2.1 Le protocole I-TCP (Indirect TCP) .......................................................................... 46

2.6.2.2 Le protocole M-TCP (Mobile TCP) ......................................................................... 46

2.6.2.3 Le protocole M-UDP (Mobile UDP) ....................................................................... 46

2.6.3 Mobilité au niveau « Application » ................................................................................... 46

2.6.4 Mobilité au niveau « Liaison de données » ..................................................................... 47

2.6.4.1 Architecture du MIH .................................................................................................. 47

2.6.4.2 Les services MIH ......................................................................................................... 48

2.6.5 Résumé ................................................................................................................................. 49

2.7 Conclusion ............................................................................................................................... 50

Chapitre 3 La garantie de l’offre de service dans les réseaux NGN .............................. 51

3.1 Introduction ............................................................................................................................. 51

3.2 Niveau de service .................................................................................................................... 52

3.2.1 Définition ............................................................................................................................. 52

3.2.2 Les paramètres du niveau de service ............................................................................... 53

3.2.3 Résumé ................................................................................................................................. 55

3.3 Négociation de niveau de service ......................................................................................... 55

3.3.1 Projets de recherche traitant de la négociation .............................................................. 55

3.3.1.1 Le projet TEQUILA ................................................................................................... 55

3.3.1.2 Le projet AQUILA ...................................................................................................... 55

ix

3.3.1.3 Le projet EURESCOM .............................................................................................. 56

3.3.1.4 Le projet MESCAL ..................................................................................................... 56

3.3.1.5 Le projets CADENUS ................................................................................................ 57

3.3.2 Protocoles de négociation ................................................................................................. 58

3.3.2.1 Le protocole RNAP .................................................................................................... 58

3.3.2.2 Le protocole COPS-SLS ............................................................................................. 58

3.3.2.3 Le protocole PPP IPCP .............................................................................................. 59

3.3.2.4 Le protocole SrNP....................................................................................................... 59

3.3.2.5 Le protocole DSNP..................................................................................................... 60

3.3.2.6 Le protocole QoS-NSLP ............................................................................................ 62

3.3.2.7 Le protocole QoS-GSLP ............................................................................................ 62

3.3.2.8 Le protocole QoS-SIP ................................................................................................ 62

3.3.3 Discussion ........................................................................................................................... 63

3.4 Le protocole SLNP ................................................................................................................. 64

3.4.1 Les services web ................................................................................................................. 65

3.4.1.1 Architecture des services web .................................................................................... 65

3.4.1.2 Les standards des services web .................................................................................. 66

3.4.1.3 Les plateformes de développement des services web ............................................ 68

3.4.2 Principales caractéristiques du protocole SLNP............................................................ 69

3.4.2.1 Satisfaction des besoins de négociation ................................................................... 69

3.4.2.2 Utilisation des services web........................................................................................ 69

3.4.2.3 Une signalisation hors-bande ..................................................................................... 69

3.4.2.4 Indépendance vis-à-vis des modèles de QoS .......................................................... 70

3.4.2.5 Transparence et extensibilité du SLS ........................................................................ 70

3.4.3 Paramètres de QoS négociés avec SLNP ....................................................................... 70

3.4.3.1 Les paramètres obligatoires ........................................................................................ 71

3.4.3.2 Les paramètres optionnels .......................................................................................... 73

3.4.4 Messages de négociation SLNP ....................................................................................... 75

3.4.4.1 Le message Negotiate.................................................................................................. 75

3.4.4.2 Le message Revision ................................................................................................... 76

3.4.4.3 Le message Modify ...................................................................................................... 76

3.4.4.4 Le message Notify ....................................................................................................... 76

3.4.4.5 Le message Release ...................................................................................................... 77

3.4.4.6 Le message Response .................................................................................................. 77

3.4.5 Architecture du protocole SLNP ..................................................................................... 78

3.4.5.1 Terminologie ................................................................................................................ 78

3.4.5.2 Modèle de fonctionnement ........................................................................................ 78

3.4.5.3 Composition d’une entité SLNP ............................................................................... 79

3.4.5.4 Scénario de négociation de QoS avec SLNP........................................................... 81

3.4.6 Résumé ................................................................................................................................. 83

3.5 Conclusion ............................................................................................................................... 84

Chapitre 4 Négociation conjointe de la sécurité et de la QoS via SLNP ...................... 85

x

4.1 Introduction ............................................................................................................................. 85

4.2 Motivations .............................................................................................................................. 86

4.3 Travaux associant la QoS et la sécurité ............................................................................... 88

4.3.1 Négociation de sécurité IPSec tenant compte de la QoS ............................................ 89

4.3.1.1 Négociation de sécurité avec IPSec .......................................................................... 89

4.3.1.2 Intégration de la QoS dans la négociation IPSec.................................................... 90

4.3.2 Association de la sécurité à la QoS dans la gestion par politique ............................... 91

4.3.3 Résumé ................................................................................................................................. 92

4.4 Intégration de la sécurité dans la négociation SLNP ......................................................... 93

4.4.1 Définition des paramètres de sécurité négociés via SLNP .......................................... 93

4.4.1.1 Portée de la sécurité ..................................................................................................... 93

4.4.1.2 Protocole de sécurité ................................................................................................... 94

4.4.1.3 Paramètres de sécurité IPSec ..................................................................................... 94

4.4.1.4 Paramètres de sécurité TLS-DTLS ........................................................................... 97

4.4.2 Définition d’un SLS de QoS et de sécurité .................................................................... 98

4.4.3 Scénarios d’utilisation de SLNP pour offrir la QoS et la sécurité ............................ 100

4.4.3.1 Exemple d’une négociation intra-domaine ............................................................ 100

4.4.3.2 Exemples de négociations inter-domaines ............................................................ 102

4.4.4 Nouveau fonctionnement du protocole SLNP ........................................................... 107

4.4.4.1 Modification de l’application cliente de négociation ............................................ 107

4.4.4.2 Modification du service web de négociation ......................................................... 110

4.4.5 Tests et évaluations des performances .......................................................................... 114

4.4.5.1 Plateforme de tests .................................................................................................... 114

4.4.5.2 Tests du fonctionnement.......................................................................................... 114

4.4.5.3 Evaluation du temps de négociation ...................................................................... 115

4.4.5.4 Evaluation de la taille des messages ........................................................................ 118

4.4.6 Résumé ............................................................................................................................... 118

4.5 Etude de l’impact de la sécurité sur la QoS ...................................................................... 119

4.5.1 Travaux portant sur l’impact de la sécurité sur la QoS .............................................. 120

4.5.1.1 Impact du protocole IPSec sur la QoS................................................................... 120

4.5.1.2 Surcoût des services de sécurité .............................................................................. 121

4.5.1.3 Impact des traitements de sécurité .......................................................................... 122

4.5.2 Tests réalisés ...................................................................................................................... 124


4.5.2.2 Résultats des tests ...................................................................................................... 125

4.5.3 Résumé ............................................................................................................................... 128

4.6 Conclusion ............................................................................................................................. 128

Chapitre 5 Adaptation du protocole SLNP aux réseaux NGN .................................. 130

5.1 Introduction ........................................................................................................................... 130

5.2 Gestion de la QoS et de la sécurité dans une architecture pour les services IPTV .... 131

5.2.1 Architecture pour la fourniture des services IPTV ..................................................... 131

5.2.1.1 Les services IPTV ...................................................................................................... 131

xi

5.2.1.2 L’architecture IPTV................................................................................................... 132

5.2.2 Offre de la QoS et de la sécurité .................................................................................... 134

5.2.2.1 Négociation du niveau de service dans le cœur du réseau .................................. 135

5.2.2.2 Consommation du service dans le réseau d’accès ................................................ 138

5.2.3 Résumé ............................................................................................................................... 142

5.3 Négociation de niveau de service dans les environnements NGN............................... 142

5.3.1 Contexte et motivations .................................................................................................. 142

5.3.2 Profil utilisateur................................................................................................................. 144

5.3.2.1 Profil « CC/PP » pour l’adaptation des flux .......................................................... 144

5.3.2.2 Profil « UED » pour l’adaptation des flux ............................................................. 145

5.3.2.3 Profil pour la négociation de QoS .......................................................................... 145

5.3.3 Définition d’un profil utilisateur pour la négociation SLNP ..................................... 146

5.3.3.1 Préférences de l’utilisateur ........................................................................................ 146

5.3.3.2 Caractéristiques de l’application .............................................................................. 148

5.3.3.3 Caractéristiques du terminal ..................................................................................... 148

5.3.3.4 Caractéristiques des réseaux d’accès ....................................................................... 149

5.3.4 Négociation SLNP basée sur le profil utilisateur ........................................................ 149

5.3.4.1 Couche de négociation .............................................................................................. 150

5.3.4.2 Le point de décision et de mise en correspondance (MNDP) ........................... 151

5.3.4.3 L’entité de négociation (SE) ..................................................................................... 152

5.3.4.4 Le générateur de SLS (SG) ....................................................................................... 153

5.3.5 Fonctionnement de la négociation fondée sur le profil ............................................. 154

5.3.5.1 Les responsables de domaines ................................................................................. 154

5.3.5.2 Le client initial ............................................................................................................ 155

5.3.6 Tests et évaluations de performances ........................................................................... 159


5.3.6.2 Tests du fonctionnement.......................................................................................... 162

5.3.6.3 Evaluation du temps de négociation ...................................................................... 162

5.3.6.4 Evaluation de la taille des messages ........................................................................ 164

5.3.7 Utilisation du protocole SLNP dans un environnement NGN ................................ 164

5.3.8 Résumé ............................................................................................................................... 167

5.4 Conclusion ............................................................................................................................. 167

Chapitre 6 Sécurité de la négociation assurée par le protocole SLNP ....................... 169

6.1 Introduction ........................................................................................................................... 169

6.2 Motivations ............................................................................................................................ 170

6.3 Mécanismes de sécurisation du protocole SLNP ............................................................ 171

6.4 Sécurité du protocole SLNP au niveau « Application » (WSS) ...................................... 173

6.4.1 Implémentation de la spécification WSS ...................................................................... 173

6.4.1.1 Principe de fonctionnement de WSS4J .................................................................. 174

6.4.1.2 Configuration de la sécurité WSS au niveau des entités SLNP .......................... 175

6.4.2 Tests et résultats ............................................................................................................... 178


xii

6.4.2.2 Tests de fonctionnement .......................................................................................... 178

6.4.2.3 Tests d’évaluation des performances en fonction du niveau de sécurité .......... 179

6.4.2.4 Tests d’évaluation des performances en fonction de l’algorithme utilisé ......... 183

6.4.3 Résumé ............................................................................................................................... 183

6.5 Sécurité du protocole SLNP aux niveaux « Transport » (SSL) et « Réseau » (IPSec) 184

6.5.1 Implémentation du protocole SSL/TLS ...................................................................... 184

6.5.2 Implémentation du protocole IPSec ............................................................................. 185

6.5.3 Tests et résultats ............................................................................................................... 186


6.5.3.2 Tests de fonctionnements ........................................................................................ 187

6.5.3.3 Tests d’évaluation des performances en fonction du type de sécurité .............. 188

6.5.4 Fonctionnement de la négociation sécurisée ............................................................... 191

6.6 Conclusion ............................................................................................................................. 193

Chapitre 7 Conclusion et Perspectives ............................................................................ 194

7.1 Principales contributions ..................................................................................................... 194

7.2 Perspectives et nouveaux défis ........................................................................................... 196

Références ................................................................................................................................. 198

Annexes ..................................................................................................................................... 206

Annexe 1 : Outils utilisés dans la mesure de l’impact de la sécurité sur la QoS ....................... 206

Annexe 2 : Les standards de sécurisation des services web au niveau applicatif ...................... 207

Annexe 3 : Exemple d’un message SLNP sécurisé avec WSS ..................................................... 222

Liste des abréviations .............................................................................................................. 226

xiii

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 .................................................................................... 14

Figure 2-3 : Architecture DiffServ ................................................................................................................ 16

Figure 2-4 : Le conditionnement du trafic DiffServ .................................................................................. 17

Figure 2-5 : Fonctionnement MPLS ............................................................................................................. 19

Figure 2-6 : Architecture de QoS dans les réseaux NGN ......................................................................... 23

Figure 2-7 : Fonctionnement du protocole IPSec ...................................................................................... 32

Figure 2-8 : Couches protocolaires de TLS ................................................................................................. 33

Figure 2-9 : Flux de messages échangés lors d’une poignée de main TLS ............................................. 36

Figure 2-10 : Principe du protocole MIP ..................................................................................................... 44

Figure 2-11 : Architecture du standard IEEE 802.21 [IEE 08] ............................................................... 48

Figure 3-1 : Négociation de SLS avec COPS-SLS [NGU 04] .................................................................. 59

Figure 3-2 : Exemple de négociation avec SrNP [TEQ 03] ..................................................................... 60

Figure 3-3 : Exemple de négociation avec DSNP ...................................................................................... 61

Figure 3-4 : Architecture QoS-SIP ............................................................................................................... 63

Figure 3-5 : Architecture des services web .................................................................................................. 65

Figure 3-6 : Pile protocolaire des services web [BOO 04] ........................................................................ 66

Figure 3-7 : Structure d’un message SOAP ................................................................................................. 67

Figure 3-8 : Structure d’un document WSDL [CHR 01] .......................................................................... 67

Figure 3-9 : Une négociation de type hors-bande ...................................................................................... 70

Figure 3-10 : Structure du SLS de QoS ........................................................................................................ 71

Figure 3-11 : Structure de l’élément ‘flowId’ ............................................................................................... 72

Figure 3-12 : Structure de l’élément ‘scope’ ................................................................................................ 72

Figure 3-13 : Structure de l’élément ‘serviceSchedule’............................................................................... 72

Figure 3-14 : Structure de l’élément ‘performanceGuarantee’ ................................................................. 73

Figure 3-15 : Structure de l'élément ‘trafficConformity’ ........................................................................... 74

Figure 3-16 : Structure de l’élément ‘negotiationParameters’ ................................................................... 74

Figure 3-17 : Structure de l’élément ‘reliability’ .......................................................................................... 75

Figure 3-18 : Structure des messages Negotiate, Revision, Release, Modify, Notify............................ 76

Figure 3-19 : Structure du message Response............................................................................................. 77

Figure 3-20 : Fonctionnement général au niveau d’une SE ...................................................................... 79

Figure 3-21 : Schéma de la description WSDL du service web de négociation .................................... 80

Figure 3-22 : Représentation simplifiée d’un message SLNP ................................................................... 82

Figure 3-23 : Exemple de négociation avec SLNP .................................................................................... 83

Figure 4-1 : Exemple de négociations indépendantes de QoS et de sécurité ........................................ 87

Figure 4-2 : Exemple de négociation de paramètres de sécurité avec IPSec ......................................... 89

Figure 4-3 : Exemple d’une négociation de sécurité IPSec en associant la QoS ................................... 90

Figure 4-4 : Structure de l’élément ‘securityScope’ .................................................................................... 93

xiv

Figure 4-5 : Structure de l’élément ‘securityProtocol’ ................................................................................ 94

Figure 4-6 : Structure de l’élément ‘ipsec’ .................................................................................................... 94

Figure 4-7 : Structure de l’élément ‘saLifetime’ .......................................................................................... 95

Figure 4-8 : Structure de l’élément ‘noReplay’ ............................................................................................ 97

Figure 4-9 : Structure de l’élément ‘tls-dtls’ ................................................................................................. 97

Figure 4-10 : Structure d’un SLS de QoS et de sécurité ............................................................................ 98

Figure 4-11 : Structure supposée de l’élément ‘saLifetime’ ...................................................................... 99

Figure 4-12 : Structure réelle de l’élément ‘securityProtocol’ ................................................................... 99

Figure 4-13 : Scénario 1 - négociation intra-domaine ..............................................................................101

Figure 4-14 : SLS négocié dans le scénario 1 ............................................................................................101

Figure 4-15 : MSC du scénario 1 .................................................................................................................102

Figure 4-16 : Scénarios 2 et 3 - négociations inter-domaines .................................................................102





Figure 4-21 : Algorithme de l’établissement d’un SLS (QoS) .................................................................108

Figure 4-22 : Traitements nécessaires à la création du message Negotiate ..........................................109

Figure 4-23 : Algorithme de l’établissement d’un SLS (QoS + Sécurité) .............................................110

Figure 4-24 : Algorithme de l’opération de négociation ..........................................................................111

Figure 4-25 : Traitements nécessaires à la modification du SLS ............................................................112

Figure 4-26 : Plateforme de tests du fonctionnement du protocole SLNP .........................................114

Figure 4-27 : Un message Negotiate visualisé à l’aide de SOAP Monitor ..........................................115

Figure 4-28 : Temps de négociation en fonction du type de négociation (100 essais) .......................117

Figure 4-29 : Taille moyenne du message Negotiate ...............................................................................118

Figure 4-30 : Comparaison du délai de bout en bout entre IPv4 et IPSec [VAN 05] ........................120

Figure 4-31 : Plateforme de tests de l'impact de la sécurité sur la QoS ................................................124

Figure 4-32 : Impact de la sécurité sur la QoS pour un trafic UDP ......................................................127

Figure 4-33 : Impact de la sécurité sur la QoS pour un trafic TCP .......................................................128

Figure 5-1 : Architecture IPTV [DJA 08] ..................................................................................................132

Figure 5-2 : Gestion de l’offre de service IPTV .......................................................................................134

Figure 5-3 : Structure de l’élément ‘securityProtocol’ adaptée au cas de l’IPTV.................................136

Figure 5-4 : La négociation SLNP au sein d’un groupe multicast IPTV ..............................................137

Figure 5-5 : Composition des caractéristiques de l’utilisateur ................................................................139

Figure 5-6 : Composition des caractéristiques du réseau ........................................................................139

Figure 5-7 : Composition des capacités du terminal ................................................................................140

Figure 5-8 : Messages RTSP échangés entre l’AG et le Client ...............................................................141

Figure 5-9 : Négociation SLNP dans les réseaux NGN ..........................................................................143

Figure 5-10 : Composition du profil utilisateur pour la négociation .....................................................146

Figure 5-11 : Vue d’ensemble de la couche de négociation ....................................................................151

Figure 5-12 : Interactions de la composante MNDP ..............................................................................152

Figure 5-13 : Interactions de la composante SE .......................................................................................153

Figure 5-14 : Interactions de la composante SG ......................................................................................153

xv

Figure 5-15 : Fonctionnement de la négociation dans le NGN .............................................................154

Figure 5-16 : Traitements au niveau du client initial ................................................................................155

Figure 5-17 : Algorithme des traitements de la composante MNDP ...................................................159

Figure 5-18 : Plateforme de tests du fonctionnement dans le NGN ....................................................160

Figure 5-19 : Interface graphique pour récupérer les préférences de l’utilisateur ...............................161

Figure 5-20 : Préférences d’un utilisateur privilégiant la sécurité ...........................................................161

Figure 5-21 : Evaluation du temps de négociation (100 essais) .............................................................163

Figure 5-22 : Taille moyenne du message Negotiate ...............................................................................164

Figure 5-23 : Exemple de négociation dans un environnement NGN .................................................166

Figure 6-1 : Les standards de sécurisation des services web ..................................................................172

Figure 6-2 : Exemple d’un fichier de déploiement WSDD ....................................................................174

Figure 6-3 : Exemple de descripteur de déploiement d’une partie cliente ...........................................176

Figure 6-4 : Exemple de fichier de propriétés (crypto-encrypt.properties) ..........................................176

Figure 6-5 : Exemple de descripteur de déploiement d’une partie serveur ..........................................177

Figure 6-6 : Modèle de communication pour les tests de fonctionnement .........................................179

Figure 6-7 : Evaluation du temps de négociation (100 essais) ...............................................................181

Figure 6-8 : Evaluation de la taille des messages ......................................................................................182

Figure 6-9 : Fichier de configuration du serveur Tomcat (server.xml) .................................................185

Figure 6-10 : Extrait du fichier de configuration IPSec (racoon.conf) .................................................186

Figure 6-11 : Plateforme de tests ................................................................................................................187

Figure 6-12 : Visualisation des échanges sécurisés avec IPSec (TCPdump) ........................................188

Figure 6-13 : Exemple d’association de sécurité IPSec ...........................................................................188

Figure 6-14 : Temps de négociation en fonction du type de sécurité ...................................................189

Figure 6-15 : Taille des messages en fonction du type de sécurité ........................................................190

Figure 6-16 : Nouvelle structure de la couche de négociation ...............................................................192

Figure A-1 : Structure d’une signature XML ............................................................................................208

Figure A-2 : Exemple de signature XML ..................................................................................................210

Figure A-3 : Structure d’un chiffrement XML ..........................................................................................211

Figure A-4 : Exemeple de chiffrement d’une partie d’un document XML..........................................212

Figure A-5 : Exemple de chiffrement d’une clé de chiffrement XML .................................................213

Figure A-6 : Emplacement de l’entête WSS dans un message SOAP ...................................................213

Figure A-7 : Exemple de signature d’un message SOAP avec WSS .....................................................215

Figure A-8 : Exemple de chiffrement d’un message SOAP avec WSS ................................................217

xvi

Liste des tableaux

Tableau 3-1 : Modèle graphique du schéma XML ..................................................................................... 71

Tableau 3-2 : Calcul des valeurs offertes des différents attributs de QoS .............................................. 82

Tableau 4-1 : Valeurs possibles des éléments de sécurité ......................................................................... 95

Tableau 4-2 : Probabilité de succès et nombre moyen de passes de négociation ...............................116

Tableau 4-3 : Temps moyen de négociation en fonction du type de négociation ..............................117

Tableau 4-4 : Qualification de la consommation des ressources ...........................................................121

Tableau 4-5 : Impact d’IPSec sur la bande passante (trafic UDP) [DUF 07] ......................................122

Tableau 4-6 : Performances en termes de traitements cryptographiques [KON 03] .........................123

Tableau 4-7 : Politiques de sécurité ............................................................................................................126

Tableau 5-1 : Protocoles et algorithmes de sécurité utilisés pour un flux IPTV .................................136

Tableau 5-2 : Paramètres du profil utilisateur pour la négociation ........................................................147

Tableau 5-3 : Paramètres de QoS pour une application de type VoIP .................................................157

Tableau 5-4 : Paramètres de QoS pour une application de type VoD ..................................................157

Tableau 5-5 : Tableau de mapping pour les services d’intégrité et de confidentialité ........................158

Tableau 5-6 : Temps moyen de négociation .............................................................................................163

Tableau 5-7 : Paramètres du profil utilisateur à la position 1 .................................................................165

Tableau 5-8 : Paramètres du SLS correspondant au profil .....................................................................165

Tableau 6-1 : Les différents scénarios de sécurité WSS ..........................................................................179

Tableau 6-2 : Impact de la sécurité WSS sur les performances du protocole SLNP ..........................181

Tableau 6-3 : Impact sur les performances suivant l’algorithme de chiffrement ................................183

Tableau 6-4 : Impact des différents types de sécurité sur les performances de SLNP ......................189

Tableau A-1 : Quelques types d’erreur définis par WSS .........................................................................218

xvii

À 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.

xviii

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.

xix

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 2010.

• 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 2009.

• 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 2008.

Conférences internationales avec actes et comité de lecture

• Mohamed Aymen Chalouf, F. Krief, “Service Level Negotiation in Ubiquitous Environments”, The 14th IEEE Symposium on Computers and Communications, Proc. ISCC 2009, Sousse, Tunisia, July 2009.

• 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 2009.

• Mohamed Aymen Chalouf, F. Krief, “SSLNP: Secure Service Level Negotiation Protocol”, The 2nd

IEEE Global Information Infrastructure Symposium, Proc. GIIS 2007, Hammamet, Tunisia, June 2009.

• Mohamed Aymen Chalouf, I. Djama, T. Ahmed, F. Krief, “On Tightly Managing End-to-End

QoS and Security for IPTV Service Delivery”, The 5th ACM International Wireless Communications and Mobile Computing Conference, Proc. IWCMC 2009, Leipzig, Germany, June 2009.

• Mohamed Aymen Chalouf, X. Delord, F. Krief, “Introduction of Security in the Service Level

Negotiated with SLNP Protocol”, The 2nd IFIP International Conference on New Technologies, Mobility and Security, Proc. NTMS 2008, Tangier, Morocco, November 2008.

• 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 2008.

xx

• 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 2007.

• 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 2007.

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) : 121 – 128, Hammamet, Tunisie, Novembre 2007.

• 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): 131 - 137, Janvier 2007, Marne-la-Vallée, France. Note : Conférence sponsorisée par IEEE France.

1

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

2

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.

3

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

4

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

5

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.

6

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

2.2.1 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

7

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.

2.2.2 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.

2.2.3 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.

8

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.

2.2.4 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

2.3.1 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é.

2.3.2 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,

9

• 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.

10

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.

2.3.3 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.

2.3.3.1 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.

2.3.3.2 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, 802.11b, 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

11

WiMax (Worldwide Interoperability for Microwave Access) et le LTE (Long Term Evolution) qui

émergent.

2.3.3.3 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).

2.3.4 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

12

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.

2.4.1 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.

13

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.

2.4.2.1 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,

14

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

15

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.

2.4.2.2 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).

16

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 : 101110.

• 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.

17

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, email, 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

18

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.

2.4.2.3 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.

19

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

20

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.

2.4.3 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 802.11), le WiMax (IEEE 802.16) ou encore la technologie

Satellite de type DVB-S2/RCS.

2.4.3.1 Mécanismes de QoS dans les réseaux Wi-Fi

Le réseau WLAN 802.11 (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 802.11 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 802.11 (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 802.11e. 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.

21

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 802.11e, 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.

2.4.3.2 Mécanismes de QoS dans les réseaux WiMax

Le standard de transmission radio 802.16 (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

802.16 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).

2.4.3.3 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

22

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.

2.4.4 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 »

23

• 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é.

24

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).

2.4.5 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 3.3.2. 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

25

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.

2.5.1 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].

2.5.1.1 Attaques de sécurité

2.5.1.1.1 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.

2.5.1.1.2 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.

26

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.

2.5.1.2 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].

2.5.1.2.1 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.

2.5.1.2.2 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.

2.5.1.2.3 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.

2.5.1.2.4 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.

27

2.5.1.2.5 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.

2.5.1.2.6 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 2.5.2. Mais avant

cela, nous rappelons, dans ce qui suit (cf. section 2.5.1.3), quelques notions cryptographiques.

2.5.1.3 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.

2.5.1.3.1 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.

28

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

29

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é.

2.5.1.3.2 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.

30

• 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.

2.5.2 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é.

2.5.2.1 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

31

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.

2.5.2.1.1 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.

2.5.2.1.2 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é).

2.5.2.1.3 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].

32

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é.

2.5.2.1.4 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.

33

2.5.2.1.5 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.

2.5.2.2 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.

2.5.2.2.1 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]:

34

• 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.

2.5.2.2.2 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

35

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.

36

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.

2.5.2.2.3 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.

37

• 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’email (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.

2.5.2.3 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

38

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.

2.5.3 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).

2.5.3.1 La sécurité dans les réseaux mobiles

2.5.3.1.1 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,

39

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.

2.5.3.1.2 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.

2.5.3.2 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.

2.5.3.2.1 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

40

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

WPA2.

2.5.3.2.2 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,

41

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 WPA2.

2.5.3.2.3 Le WPA2 (ou IEEE 802.11i)

Le standard IEEE 802.11i [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 802.11i ;

• Phase de dérivation et de distribution de clés nécessaire à la protection des messages;

42

• 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 802.11i avec le protocole CCMP pour offrir l’intégrité et la confidentialité.

2.5.4 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 WPA2.

2.5.5 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

43

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 802.21 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 802.21 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).

2.6.1 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 ;

44

• 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.

2.6.1.1 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

45

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.

2.6.1.2 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.

2.6.2 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 ».

46

2.6.2.1 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.

2.6.2.2 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.

2.6.2.3 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.

2.6.3 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

47

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.

2.6.4 Mobilité au niveau « Liaison de données »

Dans cette partie, nous détaillons l’architecture et le fonctionnement du standard IEEE 802.21, 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 802.21 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 802.21 [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.

2.6.4.1 Architecture du MIH

Le réseau global peut inclure des cellules de tailles différentes, comme celles de type IEEE 802.15,

IEEE 802.11, IEEE 802.16, 3GPP, et 3GPP2, avec chevauchement de couverture. La norme IEEE

802.21 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 802.21 [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

48

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 2.6.4.2) 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, 802.16 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 802.21 [IEE 08]

2.6.4.2 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.

49

2.6.4.2.1 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.

2.6.4.2.2 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.

2.6.4.2.3 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

802.21 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.

2.6.5 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

50

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.

51

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.

52

3.2 Niveau de service

3.2.1 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.

53

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

54

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.

55

• 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.

3.2.3 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

3.3.1 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.

3.3.1.1 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.

3.3.1.2 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

56

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 ».

3.3.1.3 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.

3.3.1.4 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

57

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.

3.3.1.5 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.

58

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.

3.3.2.1 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.

3.3.2.2 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 hors-

bande 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

59

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é.

3.3.2.3 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).

3.3.2.4 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

60

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 »).

3.3.2.5 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

61

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.

62

3.3.2.6 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.

3.3.2.7 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.

3.3.2.8 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

63

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

3.3.3 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.

64

• 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.

65

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.

3.4.1 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.

3.4.1.1 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.

66

3.4.1.2 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]

3.4.1.2.1 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).

3.4.1.2.2 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).

67

SOAP peut également utiliser l’élément <Fault> afin de signaler des erreurs. Ainsi, nous distinguons trois

types de messages SOAP : Call, Response et Fault. Un message de type Call, permet d’invoquer une

méthode (opération) d’un service web en lui passant les paramètres nécessaires à cet appel. Le résultat de

cette invocation est récupéré grâce à un message de type Response. Quand un problème survient lors d’un

appel, un message de type Fault peut être utilisé afin de caractériser l’erreur.

Figure 3-7 : Structure d’un message SOAP

SOAP n’est pas lié à un mécanisme sous-jacent de transfert de messages mais il est souvent associé à

HTTP. Il n’est pas, non plus, lié à un système d’exploitation, ni à un langage de programmation, donc les

clients et les serveurs des dialogues SOAP peuvent s’exécuter sur n’importe quelle plateforme et peuvent

être écrits dans n’importe quel langage.

3.4.1.2.3 Web Service Description Language (WSDL)

Le langage WSDL permet de décrire un service web et la manière d’y accéder, en incluant des détails

tels que le protocole à utiliser, l’URI, les opérations pouvant être effectuées, les formats des messages

SOAP entrants ou sortants qui sont requis pour dialoguer avec le service ainsi que les exceptions pouvant

être renvoyées.

<definitions>

<types> !--abstract data types </types>

<message> !--message structure </message>

<portType>!--Web Service Interface </portType>

<binding> !--how the service is accessed</binding>

<service> !--who provides the service </service>

</definitions>

Figure 3-8 : Structure d’un document WSDL [CHR 01]

Une description WSDL d’un service web est un document XML (Figure 3-8) dont l’élément racine

<definitions> contient cinq éléments :

• <types> : contient les définitions des types de données utilisées dans les messages envoyés et reçus

par le service web et ceci en utilisant le modèle XML Schema.

68

• <message> : décrit le nom et le type d’un champ à transmettre et qui correspond à un paramètre

d’entrée ou de sortie d’une opération du service.

• <portType> : définit de manière abstraite le service web comme un ensemble d’opérations où chaque

opération est composée d’un message d’entrée, d’un message de sortie et d’un message d’erreur

éventuel. Suivant les messages qui composent une opération, WSDL permet de définir quatre types

d’opérations : Request-Response (réception d’un message et renvoi d’un message), Solicit-Response

(émission d’un message et réception d’un message), One-Way (réception d’un message) et

Notification (émission d’un message).

• <binding> : permet de faire une liaison précise entre les descriptions, effectuées dans les éléments

<message> et <portType>, et le type de protocole utilisé pour véhiculer les données.

• <service> : permet de préciser les informations complémentaires nécessaires pour invoquer le service,

en particulier l’URI qui permet d’y accéder.

Ainsi la description WSDL permet de spécifier le protocole à utiliser ainsi que les opérations à

invoquer. Ceci n’est pas suffisant pour découvrir un service web qui possède une fonctionnalité dont une

application a besoin. Pour savoir où trouver les services web, un mécanisme de découverte, tel que

l’annuaire UDDI, peut être utilisé.

3.4.1.2.4 Universal Description Discovery and Integration (UDDI)

C’est un annuaire d’informations sur les services web qui permet aux fournisseurs d’enregistrer leurs

services et aux applications de rechercher et de localiser sur le réseau les services correspondant à leurs

besoins, de façon normalisée. Les annuaires UDDI sont accessibles grâce au protocole SOAP et

contiennent des informations détaillées, sous un format XML, concernant les services publiés et leurs

emplacements. En effet, un annuaire UDDI est similaire à un répertoire téléphonique où chaque entrée se

compose de trois parties principales : le fournisseur du service, les services web offerts et les liens vers

leurs implémentations. La première partie est l’information la plus générale qui décrit le fournisseur du

service. Elle inclut des noms, des adresses, des contacts et d’autres détails administratifs. La deuxième

partie est la liste des services web disponibles. Ces services peuvent être groupés par domaines

d’application, par régions géographiques, etc. La dernière partie d’une entrée UDDI est un lien vers une

implémentation qui associe l’entrée de service web à l’URI exacte identifiant son emplacement. Elle

spécifie, également, le protocole à utiliser pour accéder au service.

3.4.1.3 Les plateformes de développement des services web

Les services web doivent être déployés sur des serveurs d’applications et doivent implémenter le

protocole SOAP. Ainsi, nous trouvons plusieurs plateformes qui permettent de développer et déployer

des services web telles que : Axis et le serveur Tomcat de Jakarta (deux projets open source d’Apache

Software Foundation), la bibliothèque pour les développeurs de Services Web en Java (JWSDP) de Sun

Microsystems et les serveurs HTTP IIS de Microsoft (avec le framework .NET).

Synthèse : Dans cette section, nous avons rappelé l’architecture des services web et les standards sur

lesquels ils sont basés. Ceci permettra, par la suite, de comprendre le fonctionnement du protocole de

négociation SLNP dans cet environnement. En effet, la négociation SLNP s’effectue en échangeant des

69

messages de négociation qui ne sont autres que des messages SOAP dont la structure est définie en

utilisant des schémas XML. Le SLS sur lequel porte la négociation SLNP forme une partie de ces

messages. Ainsi, la structure de ce SLS est également spécifiée en utilisant un schéma XML. Par ailleurs,

des services web spécifiques pour la négociation sont définis et leur composition est ainsi décrite en

utilisant le langage WSDL.

3.4.2 Principales caractéristiques du protocole SLNP

3.4.2.1 Satisfaction des besoins de négociation

Afin de répondre aux besoins évolutifs des services en matière de QoS, le protocole SLNP permet

aux entités concernées par une offre de service d’établir, modifier ou résilier un SLS. En effet, en utilisant

ce protocole :

• Un client peut initier une procédure de négociation avec un fournisseur de services en définissant le

niveau de service demandé à travers les valeurs des attributs du SLS négocié.

• Un fournisseur de services peut accepter ou rejeter le niveau de service demandé par le client ou

encore proposer une alternative à ce niveau de service.

• Les entités impliquées dans une négociation (le client, le fournisseur de services et les fournisseurs de

réseaux) ont la possibilité de modifier un niveau de service qu’ils ont déjà établi.

• Un client peut résilier un niveau de service déjà établi.

3.4.2.2 Utilisation des services web

La gestion des services dans les réseaux IP peut impliquer des systèmes de gestion utilisant des

technologies différentes dont l’intégration est de plus en plus difficile et coûteuse. Dans cet

environnement hétérogène, le protocole SLNP propose d’utiliser les services web pour remédier au

problème d’intégration des différentes technologies et homogénéiser ainsi les responsables de domaines

qui peuvent être fondés sur des implémentations et des plates-formes différentes. En effet, en permettant

les interactions entre des systèmes hétérogènes, les services web représentent la solution qui permet de

fournir une interopérabilité entre les différents responsables de domaines, pouvant fonctionner sur

différentes plateformes, impliqués dans une offre de service. L’adoption de cette technologie est

également due au fait qu’elle se base sur des protocoles ouverts au format texte qui facilite la

compréhension du fonctionnement des échanges (cf. section 3.4.1.2).

3.4.2.3 Une signalisation hors-bande

Une conséquence directe de l’emploi des services web dans la négociation est le critère « hors-bande »

de cette négociation. En effet, les services web fonctionnent au niveau applicatif de la pile TCP/IP, et

doivent ainsi être implémentés uniquement au niveau des entités de négociation. Par conséquent, les

messages échangés dans le cadre d’une négociation ne suivent pas forcément le même chemin que les

données (Figure 3-9), mais doivent traverser les entités participant à la négociation et qui implémentent

donc le protocole de négociation SLNP. Ainsi, on peut distinguer deux couches indépendantes : la couche

de circulation du flux de négociation et celle de circulation des flux de données.

70

Figure 3-9 : Une négociation de type hors-bande

3.4.2.4 Indépendance vis-à-vis des modèles de QoS

Le protocole SLNP se veut indépendant du modèle de QoS adopté par les différents domaines

participant au transport du service. Cette indépendance à été réalisée en définissant une négociation dans

un environnement réparti où les offres locales de chaque domaine sont exprimées dans les messages

échangés d’une manière comprise par toutes les entités de négociation. En effet, l’offre locale de chacun

des domaines est exprimée d’une manière indépendante de l’architecture de QoS sous-jacente (cf. section

2.4.2). Ainsi, nous avons une négociation de QoS non centralisée où la décision prise concernant un

niveau de QoS est le résultat des offres locales de chaque domaine.

3.4.2.5 Transparence et extensibilité du SLS

L’utilisation des services web dans l’implémentation de SLNP passe par la définition d’un schéma

XML spécifiant la structure d’un SLS. Cette structure a été définie d’une manière générique afin de

permettre aux entités de négociation de comprendre et de supporter plusieurs paramètres de QoS (cf.

section 3.4.3). Cependant, ce SLS reste ouvert et facilement extensible à de nouveaux paramètres autre

que ceux en rapport avec la QoS, et ce grâce à la transparence du schéma XML qui définit ces paramètres,

vis-à-vis du fonctionnement du protocole.

Synthèse : Après avoir cité les principales caractéristiques du protocole SLNP, nous allons, dans ce qui

suit, décrire les paramètres de QoS qui peuvent faire l’objet d’une négociation entre les responsables des

différents domaines impliqués dans une offre de service. Ensuite, nous présentons les différents types de

messages utilisés par ces responsables de domaines afin de se mettre d’accord sur un niveau de QoS. Puis,

nous détaillons le principe général du fonctionnement de la négociation SLNP ainsi que la composition

d’une entité de négociation. Enfin, un exemple illustrant la négociation de QoS avec SLNP est donné.

3.4.3 Paramètres de QoS négociés avec SLNP

Dans cette section, nous présentons les différents attributs qui peuvent être négociés avec le

protocole SLNP. Ces attributs sont inspirés de ceux définis lors de la spécification des protocoles de

négociation décrits dans la section 3.3.2, et sont ainsi fortement liés à la qualité de service. Ce SLS de QoS

a été défini en utilisant un schéma XML auquel n’importe quel SLS négocié avec SLNP doit se conformer

afin de garantir sa compréhension par les différentes entités impliquées dans cette négociation. Dans ce

qui suit, le schéma XML du SLS est détaillé en utilisant une représentation graphique. La légende qui

permet de lire ces représentations est fournie dans le Tableau 3-1.

71

Graphique Schéma XML

Elément XML

Tous [séquence]

Choix

M : occurrence minimale N : occurrence maximale

Tableau 3-1 : Modèle graphique du schéma XML

Le SLS présent dans tous les messages SLNP a été défini d’une manière générique. Ainsi, il possède

une structure hiérarchique qui lui permet de couvrir les paramètres de qualité de service sur lesquels peut

porter une négociation (Figure 3-10). Parmi ces paramètres certains sont optionnels, alors que d’autres

sont obligatoires.

Figure 3-10 : Structure du SLS de QoS

3.4.3.1 Les paramètres obligatoires

3.4.3.1.1 Identificateur du SLS (slsId)

L’élément slsId est un entier proposé souvent par l’entité qui initie la négociation afin d’identifier un

SLS d’une manière unique. Pour assurer cette unicité, cet entier est composé de deux parties. Une

première partie qui est liée à l’adresse IP de l’entité qui initie la négociation et une seconde partie qui

assure son unicité par rapport aux autres SLS négociés par cette entité. Ceci permet d’identifier un SLS

d’une manière unique même au niveau des entités impliquées dans différents processus de négociation.

3.4.3.1.2 Identificateur du trafic (flowId)

L’identificateur de flux est représenté par l’élément flowId dont le schéma XML est donné dans la

Figure 3-11. Cet élément permet d’identifier le flux IP pour lequel la qualité de service sera garantie. Il

peut s’agir d’un micro flux ou d’un agrégat de micro flux, dans les deux cas, c’est un ensemble de

72

datagrammes IP qui ont en commun au moins une des caractéristiques suivantes : une adresse IP source

et/ou une adresse IP destination (sourceIPAddress et destinationIPAddress) qui peut être une adresse IP

v4 ou v6), un ensemble d’adresses ou un préfixe ; un numéro de port source et/ou destination (sourcePort

et destinationPort) ; un identificateur du protocole associé au flux IP (protocolId) ; ou un identificateur

d’un agrégat de flux dans un domaine qui utilise DiffServ comme modèle de QoS (DSCP).

Figure 3-11 : Structure de l’élément ‘flowId’

3.4.3.1.3 Portée (scope)

La portée ou l’élément Scope permet de préciser les frontières entre lesquelles le niveau de service

sera garanti. Il caractérise le flux circulant entre un point d’entrée (ingress) et un point de sortie (egress)

(Figure 3-12). Ces deux points sont exprimés sous forme d’une adresse IP (IPv4Address ou IPv6Address).

Figure 3-12 : Structure de l’élément ‘scope’

3.4.3.1.4 Temps de service (serviceSchedule)

Le temps de service, représenté par l’élément serviceSchedule (Figure 3-13), informe sur la période au

cours de laquelle un niveau de service doit être valable.

Figure 3-13 : Structure de l’élément ‘serviceSchedule’

73

Il peut être immédiat, périodique ou différé. Dans le cas où il est immédiat (immediateSS), le temps

de fin de service (endTime) peut être omis et donc le service sera résilié suite à la demande du client. Il

peut être périodique (periodicSS) et il est alors spécifié par la périodicité (periodicity), le temps de début

(startTime) et le temps de fin (endTime). Enfin, il peut être différé (defferedSS) et servir à faire une

réservation à l’avance des ressources. Dans ce cas, le temps de début doit être précisé alors que celui de la

fin peut être omis. Le temps de début ou de fin est composé de l’heure, du jour, du mois et de l’année.

3.4.3.1.5 Garantie de performance (performanceGuarantee)

Ce paramètre contient les attributs les plus utilisés pour spécifier la QoS d’un flux IP. Ils sont au

nombre de quatre : le délai, la gigue, le taux de perte, et la bande passante. Ces éléments peuvent être

quantitatifs avec des valeurs numériques ou qualitatives, auquel cas des adjectifs variant entre excellent et

mauvais (high, medium et low) sont utilisés. Ainsi, l’élément performanceGuarantee (Figure 3-14)

contient l’élément qualitativePG (cas d’une garantie de performance qualitative) ou l’élément

quantitativePG (cas d’une garantie de performance quantitative). Chacun de ces deux éléments est

composé des quatre éléments spécifiant le niveau de la QoS, à savoir : delay, jitter, packetLossRatio et

throughput. Comme nous l’avons déjà précisé, la décision vis-à-vis d’une demande d’un niveau de QoS de

bout en bout est prise par l’ensemble des entités de négociation mises en jeu (approche distribuée). Pour

cela, nous avons besoin de sauvegarder le résultat de l’ensemble des offres au fur et à mesure que le

processus de négociation avance. Ainsi, chacun des quatre éléments caractérisant la QoS se compose de

deux valeurs : une valeur demandée et une valeur offerte ; la valeur offerte (offered) indique l’offre

intermédiaire résultant des offres des entités précédentes alors que la valeur demandée (requested)

représente la valeur de bout en bout demandée par la première entité de négociation. Pour le paramètre

délai, par exemple, l’offre intermédiaire est spécifiée dans l’élément ‘delayOffred’ et n’est autre que le

cumul des délais qui peuvent être garantis par chaque entité de négociation alors que l’offre de bout en

bout est donnée par l’élément ‘delayRequested’.

Figure 3-14 : Structure de l’élément ‘performanceGuarantee’

3.4.3.2 Les paramètres optionnels

3.4.3.2.1 Profil et conformité du trafic (traficConformity)

74

Ce paramètre représenté par l’élément trafficConformity permet de distinguer le trafic conforme « in-

profile » du trafic non-conforme « out-of-profile » suivant un ensemble d’indicateurs. Le test de

conformité peut être réalisé par le biais d’un algorithme de conformité tel que le Token Bucket, Three

Color Marker, Leaky Bucket, srTCM ou autre. Ainsi, l’élément trafficConformity (Figure 3-15) permet de

choisir un des algorithmes disponibles. Actuellement, SLNP ne spécifie que l’algorithme Token Bucket,

mais l’extensibilité du SLS qu’il définit permet de comprendre d’autres algorithmes. L’élément

tokenBucket se compose des éléments suivants : tokenBucketRate (débit des jetons en j/s),

tokenBucketSize (taille de la file d’attente en octets), peakDataRate (débit crête du trafic en bit/s),

minimumPolicedUnit (taille du plus petit paquet IP accepté en octets) et maximumPacketSize (taille du

plus grand paquet IP accepté en octets).

Figure 3-15 : Structure de l'élément ‘trafficConformity’

3.4.3.2.2 Traitement d’excès (excessTreatement)

Dans le cas où un trafic présente des paquets non conformes aux attributs spécifiés dans le paramètre

de profil et conformité du trafic, ces paquets sont considérés hors-profil et sont soumis au traitement

d’excès spécifié dans ce paramètre. Ce traitement peut consister en l’élimination des paquets hors profil, le

retardement de ces paquets afin de les transmettre au bon moment ou encore la dégradation du niveau de

service de ces paquets. Ainsi, l’élément excessTreatement peut avoir une des trois valeurs correspondant

aux trois types de traitement spécifiés (drop, shape ou mark).

3.4.3.2.3 Paramètres de négociation (negotiationParameters)

Les paramètres de négociation regroupent deux éléments (Figure 3-16) :

Figure 3-16 : Structure de l’élément ‘negotiationParameters’

• Le mode de négociation (negotiationMode) : il peut être non prédéfini ou prédéfini, auquel cas la

négociation porte sur un ensemble de SLS fixés par le fournisseur.

• L’intervalle de renégociation (negotiationInterval) : il sert à indiquer le temps au bout duquel un SLS

négocié peut être renégocié. Il est composé à son tour de deux éléments : nbHeures et

75

nbMinutes indiquant, respectivement, le nombre d’heures et le nombre de minutes avant qu’un SLS

ne soit renégocié.

3.4.3.2.4 Fiabilité (reliability)

La fiabilité permet d’avoir une garantie sur la limitation dans le temps de l’effet d’une panne dans le

réseau sur l’offre de qualité de service. L’élément reliability (Figure 3-17) peut donc se composer de

l’élément meanDownTime et/ou l’élément meanTimeToRepair. L’élément meanDownTime contient le

temps moyen de panne par an en minutes, tandis que l’élément meanTimeToRepair contient le temps

moyen pour le rétablissement d’un niveau de service en secondes.

Figure 3-17 : Structure de l’élément ‘reliability’

L’approche distribuée qu’adopte le protocole SLNP afin d’accomplir un processus de négociation,

fait que les éléments excessTreatement, negotiationInterval, meanDownTime et meanTimeToRepair sont

divisés en deux parties : une pour les valeurs demandées initialement (requested) alors que l’autre sert à

sauvegarder le cumul des offres locales de chaque domaine, tout comme c’est le cas pour les paramètres

de garantie de performance (delay, jitter, packetLossRatio et throughput).

Synthèse : Tous ces éléments (slsId, flowId, scope, serviceSchedule, performanceGuarantee, etc.)

forment donc le SLS de qualité de service pouvant être négocié avec SLNP. Cependant, ce SLS reste

facilement extensible à d’autres paramètres comme les paramètres de sécurité ou encore de mobilité qu’il

suffit d’introduire dans le schéma XML du SLS afin qu’ils deviennent compréhensibles par toutes les

entités qui participent à une négociation SLNP. Cette négociation est fondée sur l’échange de messages

SOAP qui portent les messages de négociation. Dans la section suivante, nous décrivons les messages qui

ont été spécifiés par SLNP [MBA 06a].

3.4.4 Messages de négociation SLNP

Dans le but de satisfaire les besoins de négociation, à savoir l’établissement, la modification et la

résiliation d’un SLS, six messages ont été définis en utilisant les schémas XML.

3.4.4.1 Le message Negotiate

Le message Negotiate est généré par l’entité qui doit initier une négociation (entité initiale). Il est,

ensuite, émis par cette entité en direction de la dernière entité (entité finale) en passant par toutes les

entités impliquées dans la négociation (entités intermédiaires). Ce message est composé essentiellement de

trois éléments (Figure 3-18) : negotiationId, endNegotiation et sls.

• negotiationId : c’est un élément qu’on retrouve dans tous les types de messages. Il sert à faire le lien

entre une requête et les réponses relatives à cette requête et à identifier cet ensemble de messages

(requête et réponses) d’une manière unique. L’unicité de cet identifiant peut être assurée par la même

76

méthode utilisée dans la génération de l’identificateur d’un SLS, à savoir le slsId. Généralement, le

negotiationId est différent du slsId. En effet, une SI peut initier plus d’une négociation en même

temps avec un même SLS. Dès qu’une négociation aboutit, elle annule les autres négociations. La

différence entre ces négociations est le chemin empreinté, et on peut avoir une entité intermédiaire au

niveau de laquelle se croisent deux ou plusieurs de ces négociations. A ce moment là, le negotiationId

est le seul élément qui permet de faire la différence entre ces différentes procédures de négociation.

• end Negotiation : c’est un booléen qu’on retrouve dans tous les messages SLNP sauf dans le message

Response. Quand il est égal à ‘true’, il empêche le vis-à-vis de proposer une alternative et l’oblige à

répondre à la requête (Negotiate, Modify, Notify ou Release) avec un message Response afin de finir

la négociation. D’où, l’interêt de ce champ dans la gestion du temps de la négociation.

• sls : La structure de l’élément sls suit le schéma XML défini dans la section 3.4.3. Le rôle de ce champ

change d’un message à un autre. Par exemple, dans le cas d’un Negotiate, il permet à l’entité initiale de

spécifier les garanties de QoS dont elle a besoin en précisant les attributs et leurs valeurs.

Figure 3-18 : Structure des messages Negotiate, Revision, Release, Modify, Notify

3.4.4.2 Le message Revision

Emis par l’entité finale en direction de l’entité initiale, ce message sert à proposer une alternative au

SLS demandé. Il est composé essentiellement de trois éléments (Figure 3-18) : negotiationId,

endNegotiation et sls. Dans ce message, l’élément sls contient une proposition d’alternatives aux attributs

et valeurs reçues dans la requête (Negotiate ou Modify).

3.4.4.3 Le message Modify

Le message Modify est transmis par l’entité initiale en direction de l’entité finale. Il se compose de

trois éléments (Figure 3-18) : negotiationId, endNegotiation et sls. L’élément sls contient un slsId qui

désigne le SLS que l’entité initiale veut modifier ainsi que les valeurs du nouveau SLS. Le message Modify

sert à demander la modification d’un SLS suite à un changement des besoins de l’entité initiale ou après

réception d’un message Notify de la part d’une autre entité de négociation (intermédiaire ou finale).

3.4.4.4 Le message Notify

Le message Notify peut être émis par n’importe quelle entité intermédiaire ainsi que par l’entité finale.

Il est envoyé directement vers l’entité initiale pour lui demander d’améliorer ou de dégrader l’ancien niveau

de service suite à des problèmes dans le réseau tel que la congestion. Ce message, qui sert à notifier l’entité

initiale des nouvelles disponibilités, se compose de trois éléments : negotiationId, endNegotiation et sls

(Figure 3-18). Le slsId de l’élément sls désigne le SLS concernée par la notification, alors que le champ

endNegotiation est toujours égal à ‘true’, afin d’exiger une réponse de l’entité initiale. Cette dernière peut

répondre positivement à la notification reçue et elle peut donc procéder à la modification du SLS.

77

3.4.4.5 Le message Release

Emis par l’entité initiale en direction de l’entité finale. Ce message est transmis de proche en proche

sur le chemin de la négociation. Le message Release sert à résilier un SLS, et se compose des mêmes

éléments (Figure 3-18) : negotiationId, endNegotiation et sls. L’élément endNegotiation prend toujours la

valeur ‘true’ afin d’obliger le vis-à-vis à répondre immédiatement. Le slsId de l’élément sls de ce message

désigne le SLS auquel l’entité initiale veut mettre fin.

3.4.4.6 Le message Response

Le message Response est différent des autres messages. En effet, il est composé de quatre

champs (Figure 3-19) : negotiationId, resp, reason et sls. Il peut être :

• Emis par l’entité finale en direction de l’entité initiale afin de répondre à une requête Negotiate et

passe donc à travers toutes les entités intermédiaires. Le champ resp désigne la nature de la réponse :

acceptation (Ack) ou rejet (Nack). Dans le cas d’une acceptation, toutes les entités impliquées dans la

négociation doivent enregistrer le SLS. Alors que dans le cas d’une réponse négative, le champ reason

peut être utilisé afin d’indiquer la raison pour laquelle le SLS demandé ne peut pas être accepté.

• Emis par l’entité finale en direction de l’entité initiale pour répondre à une requête Modify. Cette

réponse peut être positive ou négative. Dans le cas d’une réponse positive, toutes les entités doivent

mettre à jour l’enregistrement du SLS.

• Emis par l’entité finale en direction de l’entité initiale afin de répondre à une requête Release. Dans le

cas d’une réponse positive, toutes les entités impliquées dans la négociation doivent supprimer le SLS

concerné.

• Emis de l’entité initiale en direction de l’entité finale afin de répondre à une requête Revision. Cette

réponse peut être positive ou négative et le message Revision peut être précédé par un Negotiate ou

un Modify. Dans le cas d’une réponse positive, toutes les entités impliquées dans la négociation

s’occupent de l’enregistrement ou de la mise à jour du SLS si le contexte est respectivement celui d’un

Negotiate ou d’un Modify.

• Emis par l’entité initiale en direction d’une entité intermédiaire ou finale afin de répondre à son

message Notify. Dans ce cas, le message Response est émis directement vers l’entité concernée. Dans

le cas d’une réponse positive, l’entité initiale peut procéder à la modification du SLS concerné.

Figure 3-19 : Structure du message Response

78

3.4.5 Architecture du protocole SLNP

Dans cette section, nous commençons par définir la terminologie utilisée pour désigner les

différentes entités mises en jeu lors de la négociation d’un SLS avec SLNP. Ensuite, nous décrivons le

fonctionnement de ce protocole, avant de détailler les différentes composantes d’une entité de

négociation. Enfin, un exemple illustrant la négociation de la qualité de service, sera donné.

3.4.5.1 Terminologie

• SE (SLNP Entity) : entité SLNP qui n’est autre qu’une entité réseau supportant le protocole SLNP.

Une SE peut être considérée comme une SI, SF ou SR suivant le rôle qu’elle joue dans un scénario de

négociation.

• SI (SLNP Initiator): entité initiale qui initie une procédure de négociation. Cette procédure de

négociation peut concerner l’établissement d’un nouvel SLS, la modification ou la résiliation d’un SLS

déjà établi.

• SR (SLNP Responder): entité finale qui répond aux différentes requêtes de la SI.

• SF (SLNP Forwarder): entité intermédiaire qui se situe entre la SI et la SR sur le chemin de la

circulation des flux de négociation.

3.4.5.2 Modèle de fonctionnement

Durant une procédure de négociation de SLS, les messages SLNP sont échangés entre la SI et la SR

tout en traversant les éventuelles SF impliquées dans cette négociation. Ces messages sont véhiculés dans

les deux sens : SI vers SR et SR vers SI. Ils sont généralement générés dans les extrémités de la négociation

(SI et SR), mais ils sont traités et modifiés, si nécessaire, au niveau des SF. Le fonctionnement de SLNP

nécessite un mécanisme de routage qui permet à chaque SE de trouver l’adresse de la SE, suivante sur le

chemin de la négociation à partir du domaine de destination des flux, et ce afin de lui transmettre les

messages. Comme l’indique la Figure 3-20, le traitement des messages par une SE est influencé par une

interaction avec la RMF (Resource Management Function) qui représente, d’une façon simplifiée, les

fonctionnalités du composant LAM (Low-level Autonomic Manager) de l’architecture de gestion

autonome définie dans [MBA 06a]. En effet, cette interaction permet de voir s’il y a assez de ressources

disponibles et si la demande a les autorisations nécessaires afin de prendre une décision qui peut être une

réponse (acceptation, rejet ou alternative) ou une transmission de la requête, modifiée si nécessaire, à la SE

suivante. Ceci permet à l’entité qui traite le message d’ajouter son offre locale dans le SLS en modifiant les

parties offertes « offered » de certains paramètres (délai, gigue, bande passante, taux de perte, traitement

d’excès etc.). Ensuite, si les SE arrivent à un accord, elles procèdent alors à l’enregistrement du SLS

négocié et le SLS est ainsi établi. Dans ce cas, la QoS de bout en bout doit être garantie grâce au respect

des offres locales qu’ont fait les différents responsables de domaines (entités de négociation). Ceci se fait

en procédant à la réservation des ressources dans tous les domaines. La réservation des ressources ne

dépend que du modèle de QoS déployé (DiffServ, IntServ, etc.). Un SLS déjà établi peut être modifié suite

à la demande de la SI. Quand cette demande est acceptée par toutes les SE concernées, le SLS est mis à

jour. La résiliation d’un SLS établi ne se fait que suite à la demande de la SI. Cette demande entraîne la

suppression du SLS en question au niveau de toutes les SE concernées. Ce modèle de fonctionnement

général sera détaillé par la suite, une fois les différents messages SLNP présentés.

79

Figure 3-20 : Fonctionnement général au niveau d’une SE

3.4.5.3 Composition d’une entité SLNP

Dans la négociation de niveau de service avec le protocole SLNP, les différentes entités utilisent la

technologie des services Web afin d’être interopérables. Cependant, cette technologie est fondée sur

l’invocation des opérations composant un service web. Une entité initiale doit ainsi contenir une

application cliente qui lui permet d’établir, modifier ou résilier un SLS en invoquant le service web de

l’entité suivante avec le message approprié (Negotiate, Modify ou Release). Elle doit, également, contenir

un service web qui lui permettra de recevoir et répondre aux notifications (Notify) qui peuvent parvenir

des autres entités de négociation afin de l’informer sur d’éventuels changements de disponibilités de

ressources ou le non respect d’un contrat déjà établi. Une entité de négociation intermédiaire ou finale doit

contenir une application cliente qui sert à générer les messages de notification et à invoquer directement le

service web de l’entité initiale. Elle doit également contenir un service web de négociation qui lui permet

de recevoir les différentes requêtes (Negotiate, Modify et Release), de les traiter et de renvoyer une

réponse (Response) ou une alternative (Revision) à l’entité appelante. Le message retourné (Response ou

Revision) peut être produit par l’entité elle-même ou être la retransmission du message retourné par

l’entité suivante sur le chemin de négociation.

En outre, une entité de négociation peut être impliquée dans plusieurs processus de négociation et

jouer des rôles différents. En effet, cette entité peut jouer le rôle d’une SI dans un premier processus et

initier une négociation d’un SLS. Elle peut également jouer le rôle d’une SF ou d’une SR sollicitée par une

autre SE dans un autre processus de négociation avec SLNP. Ainsi, afin d’assurer le bon fonctionnement

du protocole SLNP, une entité de négociation doit être composée d’une application cliente permettant

d’initier tout type de processus de négociation et d’un service web contenant les différentes opérations

permettant de traiter les différentes requêtes de négociation. Dans ce qui suit, nous présentons le service

web de négociation ainsi que l’application cliente de négociation.

3.4.5.3.1 Le service web de négociation

Le service web de négociation, représenté dans la Figure 3-21, est défini comme un ensemble

d’opérations regroupées dans un seul PortType parce qu’elles utilisent toutes le protocole SOAP/HTTP.

Généralement, chacune de ces opérations permet au service web de recevoir une requête bien précise,

d’effectuer un certain nombre de traitements afin de pouvoir répondre convenablement à cette requête.

Afin de répondre aux besoins de la négociation introduits dans la section 3.4.2.1, cinq opérations

différentes ont été distinguées, dont quatre utilisant le mode d’interaction request-response et une de

nature one-way [CHA 07].

80

Figure 3-21 : Schéma de la description WSDL du service web de négociation

• negotiationOperation : cette opération peut être invoquée chez un service web d’une SR ou d’une SF

lors d’une négociation d’un SLS. Elle est de type request-response, avec un message d’entrée de type

Negotiate et un message de sortie pouvant être de type Revision ou Response. Le message de retour

est créé par l’entité elle-même dans le cas d’une SR. Dans le cas d’une SF, ce message n’est autre que

le résultat de l’appel à la negotiationOperation du service web de la SF adjacente suivante sur le

chemin de la négociation.

• modificationOperation : cette opération peut être invoquée chez un service web d’une SR ou d’une SF

lors de la modification d’un SLS. Elle est de type request-response, avec un message d’entrée de type

Modify et un message de sortie pouvant être de type Revision ou Response. Lorsque le SLS à modifier

est reconnu, le message de retour est crée par l’entité elle-même dans le cas d’une SR, et constitue le

résultat de l’appel à l’opération modificationOperation du service web de l’entité adjacente dans le cas

d’une SF. Quand le SLS à modifier n’est pas reconnu par une entité qui reçoit la requête de

modification, un message d’erreur peut être retourné à la SI.

• notificationOperation : cette opération ne peut être invoquée que chez un service web d’une SI et elle

sert à traiter les notifications qui peuvent venir de la SR ainsi que des SF. Elle est de type request-

response, avec un message d’entrée de type Notify et un message de sortie de type Response car un

message de type Notify contient toujours un élément booléen ‘endNegotiation’ égal à ‘true’. Le

message de sortie Response est crée par l’entité SI elle-même afin de répondre directement à l’entité à

l’origine du message d’entrée Notify.

• releaseOperation : cette opération peut être invoquée chez un service web d’une SR ou d’une SF lors

de la résiliation d’un SLS. Elle est de type request-response, avec un message d’entrée de type Release

81

et un message de sortie de type Response. Le message Response peut être créé par l’entité elle-même

(cas d’une SR), ou encore être le résultat de l’appel à la releaseOperation du service web de la SE

adjacente (cas d’une SF). Si le SLS à résilier n’est pas reconnu par une SE, alors un message d’erreur

est envoyé.

• responseOperation : cette opération peut être invoquée chez un service web d’une SR ou d’une SF

lors de l’établissement ou la modification d’un SLS. En effet, elle est appelée quand la SI répond à une

alternative proposée par la SR via un message Revision. C’est la seule opération qui est de type one-

way, avec un message d’entrée de type Response. Dans le cas d’une SF, elle ne fait que transférer le

message Response reçu à la SE suivante sur le chemin de la négociation.

Notons que le format des messages véhiculés lors d’une négociation (Document-Litteral) ainsi que le

protocole utilisé (SOAP/HTTP) sont spécifiés dans le Binding, et que le service web de négociation est

constitué d’un seul port qui sert à définir l’URI du point d’accès au service en associant le binding à une

adresse réelle.

3.4.5.3.2 L’application cliente de négociation

L’application cliente de négociation avec SLNP est implémentée au niveau de chaque SE. Une SE

peut jouer le rôle d’une SI et initier l’établissement, la modification ou la résiliation d’un SLS. Elle peut,

également, jouer le rôle d’une SF ou d’une SR, et initier une notification. Ainsi, l’application cliente

implémentée par une SE doit lui permettre de procéder à [CHA 07]:

• L’établissement d’un SLS : l’application cliente d’une entité initiale peut négocier l’établissement d’un

SLS en prenant en arguments les caractéristiques du SLS à négocier, telles que l’identification du flux,

les paramètres de la garantie de performance, etc. ;

• La modification d’un SLS : l’application cliente d’une entité initiale peut, également, négocier la

modification d’un SLS déjà établi au cas où elle voit ses besoins changer ou lorsqu’elle reçoit une

notification d’une autre entité impliquée dans l’établissement du SLS en cours de validité et y répond

positivement ;

• La résiliation d’un SLS : quand le service prend fin ou lorsque le demandeur de service n’est plus

satisfait du niveau de service offert, l’application cliente de l’entité initiale peut procéder à la résiliation

du SLS déjà établi.

• La notification par rapport à un SLS : lorsqu’une entité intermédiaire ou finale ne peut plus respecter

ses engagements par rapport à une offre de service ou lorsqu’elle devient capable de fournir une

meilleure offre alors elle peut en informer l’entité initiale en lui envoyant directement un message de

type Notify.

3.4.5.4 Scénario de négociation de QoS avec SLNP

Dans cette section, nous présentons un scénario de négociation afin de mieux comprendre la

procédure de négociation avec le protocole SLNP en fournissant le MSC (Message Sequence Chart) [ITU

95] correspondant à ce scénario.

Afin d’être assez générique, nous adoptons la notation suivante : Ai désigne un attribut (ou

paramètre) de QoS qui fait l’objet de la négociation ; Vireq désigne la valeur de bout en bout relative à Ai ;

82

Vioff au niveau d’une entité de négociation reflète le cumul des offres locales des entités de négociation

précédentes relativement à l’attribut Ai. Le calcul des Vioff ne dépend que la nature du paramètre Ai

correspondant. Le détail de ce calcul pour les différents paramètres de QoS est donné dans le Tableau 3-2.

Attribut Formule

Délai D = ∑ (D1, D2, …, Dn)

Gigue G = ∑ (G1, G2, … Gn)

Bande passante BW = Min (BW1, BW2, …, BWn)

Taux de perte PLR = ∏ (PLR1, PLR2, …, PLRn)

Temps de panne moyen MDT = ∑ (MDT1, MDT2, …, MDTn)

Temps de réparation moyen MTTR = Max (MTTR1, MTTR2, …, MTTRn)

Tableau 3-2 : Calcul des valeurs offertes des différents attributs de QoS

Un message SLNP contient un ensemble d’attributs qui permettent de caractériser le niveau de

service (QoS) sur lequel porte la négociation. Dans le MSC fourni, les attributs obligatoires sont présentés

entre parenthèses alors que les attributs optionnels sont mis entre crochets. Ainsi, un message SLNP peut

être représenté d’une façon simplifiée comme le montre la Figure 3-22.

Message SLNP = {(A0, V0req, V0off);……..; (Ai, Vireq, Vioff);

[A0, V0req, V0off];……..; [Aj, Vjreq, Vjoff]}

( ) : obligatoire

[ ] : optionnel

Figure 3-22 : Représentation simplifiée d’un message SLNP

Certains attributs des messages SLNP ne changent pas de valeur lors d’un processus de négociation

(Vkreq=Vkoff), tel est le cas de l’élément ‘negotiationId’ qui permet d’associer les différents messages

échangés lors d’une même négociation. Ainsi, pour simplifier le MSC, il ne sera présenté que les attributs

dont les valeurs changent et au plus deux attributs dont l’un est obligatoire.

Dans le scénario de négociation représenté par le MSC de la Figure 3-23, les entités de négociation

(SE) utilisent les messages de type Negotiate, Revision et Response pour arriver à un accord sur un niveau

de service caractérisé par un ensemble d’attributs (Ai, Aj) et de valeurs (Vireq, Vjreq). L’attribut Aj étant

optionnel, l’entité de négociation intermédiaire (SF) peut ne pas le propager vers la SR lorsqu’elle ne

dispose pas de mécanismes pour le garantir. Le message Negotiate que construit cette entité de

négociation est toujours conforme au schéma XML de ce type de message, puisque l’occurrence de

l’attribut Aj peut être nulle. Le message Negotiate résultant tient compte de l’offre locale de la SF, grâce au

changement effectué sur la valeur offerte pour l’attribut Ai qui devient Vi1off. Le niveau de service

demandé (Vireq) ne pouvant être garanti, l’entité finale (SR) propose une alternative (Vi2off), grâce à un

message de type Revision. L’utilisation de l’élément ‘endNegotiation’ par la SI dans la deuxième passe de

négociation oblige la dernière entité sur le chemin de négociation (SR) à utiliser un message Response

pour accepter ou refuser la demande tout en tenant compte de l’offre des différentes SE mises en jeu lors

de ce processus de négociation. Dans notre exemple, la négociation se termine avec succès et le niveau de

service correspondant est enregistré localement dans chaque SE. Ce niveau de service est identifié d’une

manière unique grâce à l’attribut ‘slsId’, fixé par l’entité qui a initié la négociation.

83

Figure 3-23 : Exemple de négociation avec SLNP

Plus concrètement, le paramètre Ai peut représenter le délai de bout en bout d’une transmission de

données. Pour cet échange, la SI espère établir un niveau de QoS avec un délai de bout en bout inférieur

ou égal à 250 ms. Sur son domaine, la SI peut au mieux garantir un délai de 100 ms. Ainsi, Vireq est égal à

250 alors que Vioff est égal à 100. Le deuxième attribut négocié peut être le traitement d’excès pour lequel

le deuxième domaine (SF) ne peut fournir aucune garantie. Lorsque le message Negotiate arrive à la SF,

elle modifie le champ Vioff en ajoutant le délai produit sur son domaine pour le trafic concerné, qui est égal

à 80 ms ; ce qui fait un total de 180 ms de délai sur les deux premiers domaines. Lorsque la SR ajoute

également son offre locale égale 90 ms, elle s’aperçoit qu’il est impossible de garantir le délai de bout en

bout initialement demandé par la SI (250 ms) car il est inférieur à l’offre totale de l’ensemble du réseau

(100 + 80 + 90 = 270 ms). Dans ce cas, le message retourné par l’entité finale (Revision) lui permet de

proposer une alternative pour le paramètre délai (Vi2off = 270 ms). Lorsque ce message parvient à l’entité

initiale, cette dernière revoit son niveau de QoS demandé à la baisse en demandant un délai (Vi2req) égal à

280 ms cette fois ci. Si les offres locales des différentes entités de négociation (SI, SF et SR) n’ont pas

changé, le délai de bout en bout pouvant être garanti par l’ensemble du réseau (270 ms) répond

parfaitement aux besoins précisés par la SI lors de la seconde passe (délai = 280 ms). La réponse de la SR

est donc positive et le SLS établi est enregistré au niveau des responsables de chaque domaine.

3.4.6 Résumé

La section 3.4 nous a permis de présenter le protocole SLNP et d’expliquer le fonctionnement de la

négociation de QoS permise par ce protocole. Ceci nous permet, dans le chapitre suivant, de décrire

comment nous nous basons sur ce protocole afin de fournir des garanties en termes de QoS et de sécurité,

d’une manière simultanée, pour les flux de données pouvant transiter sur les réseaux NGN.

84

3.5 Conclusion

Dans une première partie de ce chapitre, nous avons rappelé la notion de niveau de service et les

paramètres que peut englober un SLS. Ensuite, nous avons présenté quelques travaux de recherche

portant sur l’offre de niveau de service dans les réseaux de nouvelle génération. Ces travaux ont parfois été

à l’origine de la définition d’un protocole de négociation de niveau de service. En effet, cette négociation

est indispensable afin que tous les domaines impliqués dans une offre de service puissent se mettre

d’accord sur le niveau de ce service. Ainsi, nous avons également présenté quelques protocoles de

négociation afin de comprendre leurs fonctionnements et leurs utilisations dans la garantie de l’offre de

service dans les réseaux de nouvelle génération.

Dans la deuxième partie de ce chapitre, nous nous sommes intéressés à un protocole de négociation

bien particulier ; il s’agit du protocole SLNP (Service Level Negotiation Protocol) qui a été proposé afin

de permettre la négociation de la QoS de bout en bout dans un environnement de gestion autonome. Le

fonctionnement de ce protocole est fondé sur l’utilisation des services web afin de fournir une

interopérabilité entre les différents composants d’un environnement de gestion autonome et d’éviter les

problèmes d’hétérogénéité entre les acteurs de la négociation. Ainsi, nous avons commencé par rappeler la

technologie des services web, avant de présenter les principales caractéristiques de ce protocole qui font

de lui un protocole simple, léger, efficace et facile à mettre en œuvre. Après cela, nous avons décrit les

différents paramètres de QoS compris dans le SLS négocié ainsi que les différents messages utilisés pour

se mettre d’accord sur un niveau de service. Ensuite, nous avons détaillé le modèle de fonctionnement du

protocole SLNP, qui s’appuie sur l’échange des messages de négociation entre les différentes entités, ainsi

que la composition que doit avoir chaque entité de négociation. Enfin, pour illustrer le fonctionnement

d’une négociation SLNP, nous avons donné un exemple concret où trois entités implémentant le

protocole SLNP tentent de se mettre d’accord sur un SLS de QoS.

L’un des atouts majeurs du protocole SLNP est son extensibilité qui lui permet d’être utilisé pour la

négociation de n’importe quel type de paramètre de niveau de service, comme les paramètres de sécurité

ou de mobilité. Cette extensibilité, qui découle de l’utilisation des services web, peut être réalisée en

étendant le schéma XML du SLS de QoS déjà défini à de nouveaux paramètres. Ceci permettra de

comprendre ces nouveaux paramètres par les différentes entités de négociation, mais nécessitera, bien sûr,

l’implémentation des traitements nécessaires à la négociation de ces paramètres. Dans le chapitre suivant,

nous allons étendre la négociation du protocole SLNP aux paramètres de sécurité, afin de permettre aux

différents domaines de garantir, non seulement la QoS, mais aussi la sécurité des services offerts lorsque

cette dernière est nécessaire. Cette extension doit prendre en compte l’influence mutuelle qui résulte d’une

telle association (QoS et sécurité).

85

Chapitre 4

Négociation conjointe de la

sécurité et de la QoS via SLNP

4.1 Introduction

Dans le deuxième chapitre, nous avons identifié les principaux besoins des réseaux de nouvelle

génération, notamment les besoins en termes de QoS, de sécurité et de mobilité. Ensuite, nous avons vu,

au chapitre précédent, comment la notion de niveau de service et le mécanisme de négociation permettent

de répondre à ces besoins en garantissant une offre de service de bout en bout pouvant couvrir les

aspects : QoS, sécurité et /ou mobilité. Cependant, nous pouvons remarquer que la majorité des projets

portant sur la gestion de niveau de service se sont surtout préoccupés de l’aspect QoS de l’offre de service.

Ceci est certainement dû aux besoins 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 le début comme l’un des besoins les

plus importants, mais elle a été négligée dans le niveau de service. Aujourd’hui, avec tous les risques et les

attaques qui peuvent menacer le transport des services sur les réseaux NGN, mais surtout avec le

développement des réseaux sans fil et leurs déploiements à grande échelle, la sécurité doit être prise en

considération dans l’offre de services de bout en bout.

Dans ce chapitre, nous commençons par détailler notre première contribution ; il s’agit de

l’introduction des aspects de sécurité dans le niveau de service négocié avec le protocole SLNP. Nous

avons choisi d’utiliser le protocole SLNP afin de permettre la réalisation d’une négociation simultanée de

QoS et de sécurité, parce que c’est un protocole qui se distingue par sa capacité à offrir l’interopérabilité

aux différentes parties participant à une négociation (cf. section 3.4.2.2). De plus, la négociation de la QoS,

permise par SLNP, est indépendante vis-à-vis des modèles de QoS (cf. section 3.4.2.4) et est facilement

extensible aux aspects de sécurité (cf. section 3.4.2.5). Dans un premier temps, nous introduisons les

motivations de ce travail, c’est-à-dire la nécessité d’associer la sécurité à la QoS dans une négociation de

niveau de service. Ensuite, nous présentons quelques travaux qui ont tenté de considérer la QoS lors de la

négociation de la sécurité ou vice versa. Puis, nous détaillons l’extension de la négociation permise par

SLNP aux paramètres de sécurité. Nous définissons, tout d’abord, les paramètres de sécurité pouvant être

86

négociés avec SLNP, puis nous présentons la modification de la structure du SLS sur lequel porte la

négociation. Les détails du fonctionnement de l’extension de SLNP à la sécurité seront, ensuite, donnés et

les résultats des tests de performances de ce nouveau fonctionnement seront présentés.

Notre deuxième contribution consiste à étudier l’impact des mécanismes de sécurité sur les

paramètres de la QoS. En effet, afin de pouvoir réaliser une négociation conjointe de la QoS et de la

sécurité, l’impact de la sécurité sur la QoS doit être pris en compte lors d’une telle négociation. Pour cela,

une estimation de cet impact doit être effectuée. Ainsi, dans cette seconde partie, nous commençons par

présenter les travaux ayant traité de l’impact de la sécurité sur la QoS. Puis, nous détaillons nos travaux qui

nous ont permis de souligner l’importance de cet impact et d’effectuer des estimations de cet impact.

4.2 Motivations

Les attaques de sécurité identifiées dans la section 2.5.1.1 peuvent menacer sérieusement les services

transportés par les réseaux NGN. Cette menace est d’autant plus importante au niveau de l’accès avec

l’adoption des réseaux sans fil. Actuellement, les réseaux sans fil offrent des débits physiques de plus en

plus grands, mais restent toujours vulnérables aux attaques de sécurité, malgré le développement de

certains protocoles de sécurité spécifiques à ces réseaux, tels que WEP, WPA et WPA2 (cf. section

2.5.3.2). Ainsi, le transport des services sur les réseaux de nouvelle génération nécessite la mise en place

d’une sécurité de bout en bout plus efficace, telle que celle offerte au niveau ‘réseau’ par le protocole

IPSec ou celle fournie au niveau « Transport » par les protocoles TLS ou DTLS. En effet, ces protocoles

de sécurité permettent d’offrir une sécurité de bout en bout avec un niveau de sécurité plus ou moins

important. Ce niveau de sécurité peut être négocié entre les deux extrémités d’une offre de service en

utilisant les mécanismes propres à ces protocoles, c’est-à-dire le protocole IKE lorsque IPSec est utilisé ou

bien le protocole de poignée de main lorsque TLS ou DTLS est employé.

Considérons, ainsi, une offre de service entre les deux utilisateurs Client 1 et Client 2 de la Figure 4-1.

Cette offre nécessite des garanties en matière de QoS mais aussi en matière de sécurité. Supposons que la

QoS de bout en bout est négociée avec un protocole de négociation tel que le protocole SLNP, et que le

niveau de sécurité offert par IPSec est négocié par le protocole IKE (négociation des paramètres des

associations de sécurité). Dans cet exemple, nous nous intéressons à un paramètre de QoS, à savoir le

paramètre délai ainsi qu’à un paramètre de sécurité qui est l’algorithme de chiffrement permettant de

protéger la confidentialité des données échangées entre Client 1 et Client 2. Comme le montre la Figure

4-1, la première étape est constituée d’une négociation SLNP qui peut aboutir à l’établissement d’un SLS

de QoS avec un délai de bout en bout égal à 250 ms. Ce délai répond exactement aux besoins de la

communication entre Client 1 et Client 2. Ensuite, la deuxième étape est l’établissement d’un niveau de

sécurité permettant de protéger la confidentialité de cette communication. En utilisant le protocole IKE,

Client 1 et Client 2 parviennent à se mettre d’accord sur l’utilisation de l’algorithme AES-CBC pour

satisfaire leur besoin en matière de sécurité. Une fois les mécanismes de mise en œuvre de la QoS et de la

sécurité terminés, la communication peut commencer. A ce moment là, les deux extrémités de la

communication peuvent remarquer des anomalies au niveau de la QoS parce que le délai de bout en bout

est supérieur à 250 ms. Ce qui les laisse penser que l’accord établi sur la QoS par l’ensemble du réseau

n’est pas respecté. En réalité, l’accord établi par les différents acteurs de la négociation SLNP sur la QoS

est parfaitement respecté, mais le problème vient des délais supplémentaires introduits par les mécanismes

87

de sécurité IPSec lorsque les opérations de chiffrement et de déchiffrement sont réalisées. Ainsi, le fait de

négocier la QoS et la sécurité d’une manière indépendante et sans tenir compte de l’impact de la sécurité

sur la QoS a, en quelque sorte, faussé la négociation de la QoS. Par conséquent, lorsque la sécurité est

requise, il faut absolument considérer son impact sur la QoS quand cette dernière est négociée avec SLNP.

Figure 4-1 : Exemple de négociations indépendantes de QoS et de sécurité

Pour prendre en compte l’impact de la sécurité sur la QoS lors de la négociation de cette dernière,

nous pouvons, dans un premier temps, négocier les paramètres de sécurité avec les mécanismes offerts par

les protocoles de sécurité dans ce but (le protocole IKE ou le protocole de poignée de main). Les

paramètres de sécurité retenus pour la sécurisation du trafic permettent aux entités de négociation d’avoir

une idée sur l’importance de l’impact sur la QoS (cf. section 4.5), et de pouvoir prendre cet impact en

considération lors de la négociation de la QoS. Cependant, si les mécanismes de négociation propres aux

protocoles de sécurité (IPSec, TLS ou DTLS) sont mis en œuvre afin de se mettre d’accord sur les

paramètres de sécurité, la sécurité est, dans ce cas, automatiquement mise en place une fois les paramètres

de sécurité sélectionnés. Si, dans un deuxième temps, la négociation de la QoS de bout en bout avec SLNP

n’aboutit pas à l’établissement d’un accord sur l’offre de QoS, alors la sécurité déjà mise en place doit être

désinstallée (désactivée) et on a, ainsi, perdu du temps et des ressources inutilement.

Ainsi, la solution est de négocier les paramètres de sécurité avec un protocole de négociation tel que

SLNP. Cette négociation permet aux extrémités d’un échange de choisir un protocole de sécurité parmi

ceux qui peuvent être utilisés et de se mettre d’accord sur les paramètres de sécurité qui seront utilisés par

ce protocole dans la sécurisation de l’échange. Lorsque la sécurité est requise par un service, sa négociation

avec le protocole SLNP constitue une sorte de négociation en amont qui sera suivie par une deuxième

négociation propre au protocole de sécurité permettant de mettre en place les mécanismes de sécurité

(établissement des associations de sécurité en cas d’utilisation de IPSec, et établissement de la session et la

connexion lorsque TLS ou DTLS est utilisé).

88

Si nous voulons négocier la QoS et la sécurité avec SLNP, alors nous avons trois possibilités :

• Négocier la QoS, puis la sécurité : ce cas de figure est à écarter car il ne permet pas de prendre en

compte l’impact de la sécurité sur la QoS.

• Négocier la sécurité, puis la QoS : il est possible de négocier la sécurité avec SLNP, et de suivre cette

négociation par une autre qui va porter, cette fois, sur la QoS tout en tenant compte de l’impact de la

sécurité sur cette QoS. Cependant, il s’avère que ce cas de figure est très coûteux en termes de nombre

de passes de négociation et donc également en termes de consommation de ressources et de temps de

négociation. En effet, si on suppose que les ententes sur les paramètres de sécurité et sur les

paramètres de QoS nécessitent chacune d’elles deux passes de négociation, alors le nombre de passes

nécessaires à la négociation de ces deux aspects est de quatre. Il en est de même pour le temps de

négociation total qui est égal à la somme des temps nécessaires à la négociation de la QoS et de la

sécurité (Équation 4-1).

Tneg (qos, sec) = Tneg (qos) + Tneg (sec)

Équation 4-1 : Temps de négociation total (sécurité, puis QoS)

• Négocier simultanément la QoS et la sécurité : cette solution permet de réduire le nombre de passes

nécessaires à la négociation de ces deux aspects et donc, également, le temps passé dans une

négociation (Équation 4-2). En effet, si on considère l’exemple cité dans le cas précédent, alors la

négociation simultanée de la QoS et de la sécurité nécessiterait uniquement deux passes de

négociation au lieu de quatre et le temps de négociation pourrait être réduit d’une manière importante

pouvant aller jusqu’à 50% dans le meilleur des cas (Équation 4-2). De plus, lorsque l’ensemble du

réseau ne permet pas de satisfaire à la fois les besoins de QoS et de sécurité, il est plus facile et plus

rapide de trouver un compromis entre ces deux aspects dans le cas d’une négociation simultanée que

dans le cas de deux négociations successives.

Tneg (qos, sec) = Max (Tneg (qos), Tneg (sec))

Équation 4-2 : Temps de négociation total (sécurité et QoS)

Par conséquent, l’idéal est d’introduire la sécurité dans le niveau de service négocié avec SLNP afin

de permettre aux entités de négocier correctement un niveau de service de bout en bout couvrant à la fois

la QoS et la sécurité. Dans ce qui suit, nous détaillons les travaux que nous avons réalisés dans le cadre de

cette extension. Mais avant cela, nous réservons la section suivante à la description de quelques travaux qui

ont essayé de considérer conjointement la sécurité et la QoS afin de positionner nos travaux.

4.3 Travaux associant la QoS et la sécurité

Comme nous l’avons déjà mentionné auparavant, la sécurité peut peser lourdement sur la QoS. Dans

certains cas, comme pour les applications temps réel, l’introduction de la sécurité peut même causer une

dégradation complète de la QoS. Ainsi, certains travaux se sont intéressés à la gestion simultanée de ces

deux aspects. Cette section est composée de deux parties. Dans la première partie nous décrivons les

travaux présentés dans [VAN 05] et qui avaient pour objectif de considérer la QoS lors de la négociation

des paramètres de sécurité avec IPSec (IKE) afin de trouver un compromis pour assurer une QoS et une

89

sécurité minimale. Dans la deuxième partie, nous nous intéressons aux travaux décrits dans [DUF 07] qui

visaient à étendre le SLS de QoS défini dans le projet TEQUILA à des paramètres de sécurité afin

d’améliorer la gestion basée sur les politiques pour des services de type ‘multimédia’.

4.3.1 Négociation de sécurité IPSec tenant compte de la QoS

Dans cette partie, nous décrivons une proposition qui consiste à intégrer une négociation de QoS

dans la négociation de sécurité permise par le protocole de sécurité IPSec. Pour ce faire, nous rappelons,

tout d’abord, le mécanisme de négociation des paramètres de sécurité offert par IPSec. Ensuite, nous

décrivons la méthode utilisée afin de permettre la prise en compte de la QoS dans cette négociation.

4.3.1.1 Négociation de sécurité avec IPSec

Lorsqu’un échange de données entre deux entités (deux terminaux, deux passerelles de sécurité ou un

terminal et une passerelle) doit être sécurisé avec le protocole IPSec, il faut négocier les paramètres de

sécurité entre ces deux entités préalablement à la transmission de données. Cette négociation peut être

réalisée avec un mécanisme propre à IPSec qui s’appelle le protocole IKE (Internet Key Exchange) [HAR

98] et permet ainsi à l’émetteur et au récepteur de se mettre d’accord sur les paramètres des associations de

sécurité (SA). Une fois un accord établi, les associations de sécurité sont stockées dans la SAD (Security

Association Database) et seront utilisés, par la suite, dans la sécurisation des données échangées.

Figure 4-2 : Exemple de négociation de paramètres de sécurité avec IPSec

Le protocole IKE utilise le protocole ISAKMP (Internet Security Association and Key Management

Protocol) [MAU 98] pour négocier, établir, modifier et supprimer des associations de sécurité. Ainsi, ce

sont les messages ISAKMP qui permettent de se mettre d’accord sur les paramètres de sécurité. Un

message ISAKMP est constitué d’un entête de longueur fixe, suivi d’un ensemble de blocs où chaque bloc

90

indique le type du bloc suivant. Pour négocier des paramètres de sécurité, un bloc appelé « SA (Security

Association) » est utilisé. Ce bloc est toujours suivi d’un ou plusieurs blocs « Proposal » qui permettent de

faire des propositions (présentés par ordre de préférence) au vis-à-vis. Chaque bloc « Proposal » constitue

une proposition d’un ensemble d’attributs relatifs à une association de sécurité, et est toujours suivi d’un

ou plusieurs blocs « Transform » qui permettent de préciser les attributs choisis pour la SA en question. Le

destinataire d’un message ISAKMP doit répondre par un message identique où il ne conserve que la

proposition retenue. Dans la Figure 4-2, nous fournissons un exemple illustrant la négociation IPSec des

paramètres de sécurité. Dans cet exemple, l’émetteur propose deux ensembles de paramètres « TRANSF

1 » et TRANSF 2 » dans le message ISAKMP envoyé au récepteur. Le récepteur sélectionne l’ensemble

des paramètres proposés dans « TRANSF 1 ». Ce choix peut être expliqué par la préférence du récepteur

pour l’ensemble des paramètres correspondant au niveau de sécurité le plus fort. En effet, la

confidentialité des données est mieux protégée quand on utilise l’algorithme 3DES (Triple DES) que

lorsqu’on emploie l’algorithme DES, et l’authentification est plus robuste avec HMAC-SHA-256, qu’avec

HMAC-SHA-128.

4.3.1.2 Intégration de la QoS dans la négociation IPSec

Lorsqu’on étudie l’impact de la sécurité sur la QoS (cf. section 4.5), nous pouvons voir que cet

impact dépend des algorithmes choisis pour réaliser les opérations de sécurisation des données échangées.

En effet, sans rentrer pour l’instant dans les détails, nous pouvons dire qu’un algorithme complexe aura,

par exemple, un coût plus important en termes de délai de traitements que celui d’un algorithme simple.

Figure 4-3 : Exemple d’une négociation de sécurité IPSec en associant la QoS

Dans les travaux décrits dans [WEI 07], l’auteur a constaté qu’un utilisateur ne choisit pas forcement

un algorithme complexe s’il estime que le degré de sécurité avec un algorithme simple répond

parfaitement à ses besoins en matière de sécurité. En partant de cette constatation, l’auteur a introduit une

notion de QoS lors de la négociation des paramètres de sécurité d’une SA avec IPSec. Ceci a été réalisé en

91

proposant de respecter les contraintes de QoS lors de la sélection des paramètres de sécurité. A titre

d’exemple, si un utilisateur veut sécuriser une application de type temps réel, alors il doit choisir des

paramètres de sécurité dont l’influence ne perturbe pas la QoS de l’application ; par exemple, le délai de

bout en bout ne doit pas dépasser 150 ms et le taux de perte des paquets doit rester inférieur à 1%. Plus

concrètement, l’idée consiste à introduire un champ appelé « QoS » dans l’entête du protocole ISAKMP.

Ainsi, la valeur que peut avoir ce champ peut modifier la négociation classique d’IPSec (ISAKMP). La

Figure 4-3 donne un exemple de la négociation de sécurité avec QoS.

Dans cet exemple, l’émetteur propose deux ensembles de paramètres de sécurité (deux

transformations : TRANSF 1 et TRANSF 2) en ajoutant à l’entête du message ISAKMP un champ

« QoS » dont la valeur est égale à « Video ». Cette indication sur le type de l’application à sécuriser peut

aider le récepteur à choisir la suite de paramètres adéquate. Dans l’exemple considéré (Figure 4-3), le

récepteur sait que s’il choisit les paramètres de sécurité proposés dans TRANSF 2, alors l’impact de la

sécurité peut compromettre la QoS de l’application de type « Video ». Ainsi, il va choisir l’ensemble des

paramètres TRANSF 2, s’il juge que la vidéo est suffisamment protégée par les paramètres correspondant,

ou bien refuser l’exécution de l’application. Ceci permet de réaliser un compromis entre une QoS

minimale et une sécurité minimale, dans la mesure du possible.

Ces travaux nous donnent une idée de l’importance de l’impact de la sécurité sur la QoS, et

confirment notre orientation vers une association entre la sécurité et la QoS dans une négociation de

niveau de service. Cependant, nous pensons que la manière avec laquelle la QoS est prise en compte lors

de la négociation des paramètres de sécurité peut être améliorée. En effet, il n’existe aucune règle précise

permettant de déterminer l’ensemble de paramètres de sécurité le plus convenable. Dans la suite de ce

chapitre (cf. section 4.5.2) nous allons voir comment nous essayons de quantifier l’impact de la sécurité sur

la QoS afin de pouvoir le prendre en compte lors de la négociation de la QoS. Ceci permet d’établir un

accord sur les paramètres de sécurité et de QoS tout en se basant sur des valeurs exactes.

4.3.2 Association de la sécurité à la QoS dans la gestion par politique

Dans cette partie, nous présentons les travaux décrits dans [DUF 05] et [DUF 07] qui avaient pour

objectif d’intégrer des paramètres de sécurité dans le SLS utilisé pour garantir un niveau de service dans un

environnement de gestion par politique.

Dans ces travaux, les paramètres de sécurité définis peuvent être de type « quantitatif » ou bien

encore de type « qualitatif », ce qui permet aux fournisseurs mais aussi aux utilisateurs de négocier un

niveau de sécurité. En effet, les auteurs ont introduit deux niveaux d’interprétation des paramètres de

sécurité : un niveau abstrait, exprimé d’une manière qualitative qui peut être compris par les utilisateurs

non experts, et un niveau précis, exprimé d’une manière quantitative, qui peut être spécifié par les

utilisateurs experts et les fournisseurs. Pour ce faire, un ensemble de paramètres de sécurité pouvant être

interprétés de deux manières ont été définis.

• Les paramètres qualitatifs représentent les services de sécurité qui peuvent être fournis. Ces services

sont au nombre de quatre : la confidentialité, l’intégrité, l’authentification et la protection contre le

rejeu (non-rejeu). Pour les trois premiers services, quatre niveaux de sécurité ont été identifiés :

« high », « medium », « default » et « no ». En ce qui concerne le non-rejeu, deux états uniquement ont

été identifiés : « on » et « off ». Sachant que le niveau d’un service de sécurité dépend essentiellement

92

de l’algorithme utilisé dans l’offre de service, une classification des algorithmes utilisés permet

d’identifier les algorithmes correspondant à chaque niveau. Ceci permet la transcription en un SLS de

sécurité quantitatif afin d’établir un niveau de service.

• Les paramètres quantitatifs de sécurité consistent essentiellement en deux sous-ensembles de

paramètres. Tout d’abord, les paramètres de service de confidentialité qui regroupent : le nom et la

catégorie de l’algorithme sélectionné, la taille du bloc, le mode d’opération, la longueur de la clé et le

nombre de rounds de transformation. Vient ensuite les paramètres des services authentification,

intégrité et non-rejeu qui sont, généralement, manipulés ensemble. Ainsi, ce deuxième sous-ensemble

de paramètres est constitué de : l’algorithme et le type d’authentification, la longueur de la clé, la

fonction de hachage et l’état de la protection contre le rejeu (non-rejeu).

Ces travaux viennent, également, confirmer notre orientation vers une association entre la sécurité et

la QoS dans une négociation de niveau de service. Cependant, nous n’avons pas besoin de définir des

paramètres qualitatifs. En effet, nous allons, dans le chapitre suivant, adapter la négociation SLNP aux

environnements NGN en basant cette négociation sur le profil utilisateur. Ceci facilitera la négociation

pour les utilisateurs non-experts.

Ensuite, lorsque les paramètres de sécurité quantitatifs sont négociés, il est nécessaire de spécifier les

valeurs d’un sous-ensemble de paramètres pour chaque service, comme le nom, la catégorie et le mode

d’opération de l’algorithme ainsi que la taille du bloc et celle de la clé pour le service de confidentialité.

Chacun de ces paramètres peut avoir une valeur parmi un ensemble de valeurs possibles. Or, la

combinaison des valeurs de tout ce sous-ensemble des paramètres peut ne pas correspondre à un

algorithme existant. Ainsi, il nous semble qu’il est préférable de négocier, pour chaque service de sécurité,

l’algorithme complet parmi la liste des algorithmes existants réellement. C’est le cas de la négociation des

algorithmes de sécurité par ISAKMP dans le cadre d’une sécurisation IPSec (Figure 4-2).

Concernant la sécurisation des échanges, les auteurs proposent d’assurer un niveau de sécurité en

utilisant IPSec ou TLS. Il est vrai qu’IPSec peut être considéré comme une solution universelle qui permet

de sécuriser à la fois les trafics basés sur TCP et UDP. Mais, lorsqu’on ne peut pas utiliser IPSec pour

sécuriser une application basée sur UDP, il est, dans ce contexte particulier, impossible de protéger cette

application. Pour pallier à ce problème, nous allons considérer le protocole IPSec pour la sécurisation au

niveau ‘Réseau’ de tout type d’échange, et les protocoles TLS et DTLS pour la protection des

transmissions au niveau « Transport ».

Dans ces travaux, les auteurs ont insisté sur l’importance de l’impact de la sécurité sur la QoS en

essayant d’identifier quel type de service de sécurité (confidentialité, intégrité, non-rejeu, etc.) pourrait

avoir un impact plus ou moins important sur tel type de ressources (CPU, mémoire et bande passante).

Cette classification sera présentée dans la partie que nous réservons à l’étude de l’impact (cf. section 4.5.1),

et sera complétée par les mesures que nous avons réalisées afin de quantifier cet impact (cf. section 4.5.2).

4.3.3 Résumé

Dans cette la section 4.3, nous avons décrit un ensemble de travaux qui ont essayé d’associer la QoS

à la sécurité ou vice versa, tout en situant nos travaux par rapport à ceux déjà réalisés. Dans la section

93

suivante, nous détaillons notre première contribution qui se résume dans l’extension de la négociation du

niveau de service offerte par SLNP aux aspects de sécurité.

4.4 Intégration de la sécurité dans la négociation SLNP

L’intégration des aspects de sécurité dans la négociation du protocole SLNP passe, tout d’abord, par

la définition des paramètres de sécurité pouvant être négociés avec ce protocole. Ces paramètres seront,

ensuite, introduits dans le SLS négocié afin de permettre sa compréhension par les différentes entités de

négociation. Nous donnons, par la suite, un scénario illustrant la négociation conjointe de la QoS et de la

sécurité avec SLNP. Enfin, nous détaillons le nouveau fonctionnement du protocole SLNP qui permet de

considérer les aspects de sécurité dans la négociation sans oublier de prendre en compte l’impact de la

sécurité sur la QoS dans une telle négociation.

4.4.1 Définition des paramètres de sécurité négociés via SLNP

La négociation du niveau de service via SLNP ne prend en compte que la partie QoS (cf. section

3.4.3). Or, nous avons vu, au début de ce chapitre, que la sécurité peut être introduite dans cette

négociation. Les protocoles de mise en œuvre de la sécurité les plus utilisés sont : le protocole IPSec, qui

permet de sécuriser les échanges au niveau de la couche « Réseau », et les protocoles TLS et DTLS, qui

permettent d’introduire de la sécurité au niveau de la couche « Transport ». L’étude de ces protocoles,

réalisée dans la section 2.5.2, nous permet de déterminer les paramètres de sécurité pouvant être négociés

avec SLNP. Ces paramètres seront définis relativement aux protocoles étudiés. Ainsi, la sécurité offerte

suite à une négociation sera fondée sur l’utilisation des protocoles IPsec, TLS et/ou DTLS.

Dans cette section, nous fournissons la structure XML de ces différents paramètres de sécurité en

utilisant la même représentation graphique introduite dans la section 3.4.3.

4.4.1.1 Portée de la sécurité

La portée de la sécurité (securityScope) permet de spécifier les deux extrémités entre lesquelles un

échange de données est sécurisé. Ces deux extrémités constituent deux entités pouvant être représentées

par une adresse IPv4 ou IPv6 (Figure 4-4). Quand la sécurité est assurée par le protocole IPSec, la portée

est constituée des deux pairs entre lesquels une ou deux associations de sécurité sont mises en place, le

nombre d’associations de sécurité mises en place dépend des sens sécurisés (un ou deux sens). Ces pairs

peuvent être deux passerelles de sécurité, deux terminaux ou encore un terminal et une passerelle de

sécurité. Dans le cas où TLS ou DTLS est utilisé afin de sécuriser la transmission des donnés, la portée de

la sécurité fait généralement référence au client et au serveur entre lesquels une session sécurisée est créée.

Figure 4-4 : Structure de l’élément ‘securityScope’

94

4.4.1.2 Protocole de sécurité

Ce paramètre permet de sélectionner un ou plusieurs protocoles de sécurité à mettre en œuvre parmi

les deux types de sécurité disponibles : IPSec et TLS/DTLS. Comme nous pouvons le remarquer sur la

Figure 4-5, chacun des deux éléments « ipsec » et « tls/dtls » composant l’élément ‘securityProtocol’ a une

occurrence minimale égale à 0 et une occurrence maximale égale à l’infini. Ceci implique qu’on peut

utiliser : un seul protocole de sécurité une seule fois, un protocole de sécurité plusieurs fois ou n’importe

quelle empilement de plusieurs sécurités IPSec et TLS/DTLS. Par exemple, on peut empiler deux

sécurités IPSec où la première nous permet de protéger l’intégrité, à l’aide du mécanisme AH, et où la

seconde est utilisée afin de fournir la confidentialité grâce au mécanisme ESP. On peut, également,

sécuriser un trafic UDP au niveau de la couche « Réseau » avec IPSec, mais aussi au niveau supérieur

(couche « Transport ») en utilisant DTLS.

Figure 4-5 : Structure de l’élément ‘securityProtocol’

Pour chacun de ces deux types de sécurité, un ensemble de paramètres doit être négocié afin de

spécifier le niveau de sécurité requis par la transmission. Ces deux ensembles de paramètres sont détaillés

dans les sections suivantes.

4.4.1.3 Paramètres de sécurité IPSec

Nous avons vu au deuxième chapitre, que le protocole IPsec se fonde sur la notion de SA pour

fournir des services de sécurité et qu’une SA est caractérisée, essentiellement, par des paramètres tels que

la durée de vie, le mécanisme, le mode et les algorithmes utilisés pour la confidentialité, l’intégrité et

l’authentification. Ces paramètres, qui déterminent le niveau de sécurité d’un échange de données, nous

ont aidés à déterminer les paramètres d’une sécurité IPsec qui peuvent être négociés via le protocole

SLNP. Ainsi, lorsque le protocole IPSec doit être utilisé, les paramètres qui doivent obligatoirement être

négociés avec SLNP sont (Figure 4-6) : ‘saLifetime’, ‘mode’, ‘mecanism’, confidentiality’ et ‘integrity’. Il

est, également, possible de négocier le paramètre ‘no-reply’.

Figure 4-6 : Structure de l’élément ‘ipsec’

95

4.4.1.3.1 Temps de vie d’une association de sécurité

Le paramètre temps de vie d’une association de sécurité (SA) permet de négocier cette durée entre les

deux extrémités d’une SA. Le temps de vie d’une SA peut être exprimé comme une période ou un nombre

d’octets. Ainsi, l’élément ‘saLifetime’, représentant cette durée de vie, (Figure 4-7) permet de choisir entre

les deux éléments ‘duration’ et ‘nbBytes’. A la fin de ce temps, une SA est terminée et doit être remplacée

par une nouvelle si nous voulons continuer à fournir des services de sécurité.

Figure 4-7 : Structure de l’élément ‘saLifetime’

4.4.1.3.2 Mécanisme

Ce paramètre permet de spécifier le mécanisme IPSec que les entités à l’extrémité de la SA veulent

mettre en œuvre, c’est-à-dire AH ou ESP. Par conséquent, l’élément ‘mecanism’ permet de choisir entre

deux valeurs : ‘ah’ et ‘esp’ (Tableau 4-1). Le choix du mécanisme de sécurité ne dépend que des besoins de

l’initiateur de la négociation en matière de sécurité. En effet, si cette entité a besoin d’un service de

confidentialité, elle ne peut que choisir le mécanisme ESP car le mécanisme AH n’offre que les services

d’intégrité, authentification et protection contre le rejeu, alors qu’ESP peut assurer, également, la

confidentialité des données.

Elément XML Valeurs possibles

ipsec � mecanism ah, esp

ipsec � mode transport, tunnel

ipsec � integrity hmac-sha1-96, aes-xcbc-mac-96, hmac-md5-96, null

ipsec � confidentiality 3des-cbc, aes-cbc, aes-ctr, des-cbc, null

ipsec � noReplay � state on, off

ipsec � noReplay � size 32, 64

tls-dtls � integrity sha1, md5, null

tls-dtls � confidentiality idea, rc2-40, des-40, 3des, fortezza, rc4-40, rc4-128, null

Tableau 4-1 : Valeurs possibles des éléments de sécurité

4.4.1.3.3 Mode d’opération

Le paramètre mode d’opération, représenté par l’élément ‘mode’ (Figure 4-6), permet de choisir l’un

des deux modes possibles, à savoir le mode ‘transport’ ou le mode ‘tunnel’ (Tableau 4-1). Le choix d’un

mode d’opération pour IPsec dépend de ce que nous voulons protéger (les données de protocole de

transport ou la totalité du paquet IP). En effet, l’utilisation du mode tunnel permet de masquer les

adresses IP source et destination afin de protéger la communication contre les attaques d’analyse de trafic.

Cela dépend, également, de la nature des nœuds entre lesquels l’association de sécurité (SA) est établie. En

96

effet, si l’une des deux extrémités de la SA est une passerelle de sécurité, il est fortement recommandé

d’utiliser le mode tunnel.

L’authentification et l’intégrité sont des services inséparables, et sont garantis grâce à un seul et même

algorithme. Par conséquent, ils seront, dans la suite de ce mémoire, désignés conjointement sous le terme

« intégrité ».

4.4.1.3.4 Confidentialité

La confidentialité des données ne peut être assurée qu’avec le mécanisme ESP. Quand elle est

sélectionnée, le niveau de confidentialité dépend de l’algorithme utilisé. Ainsi, ce service, correspondant à

l’élément ‘confidentiality’, peut prendre une des valeurs de la liste des choix des algorithmes pouvant

assurer la confidentialité avec le protocole IPSec (Tableau 4-1). Les algorithmes formant cette liste ont été

identifiés sur la base des algorithmes définis dans [SCH 05a], à savoir « TripleDES-CBC », « AES-CBC »,

« AES-CTR », « DES-CBC » et « NULL ».

4.4.1.3.5 Intégrité

L’intégrité peut être assurée grâce au mécanisme AH ou ESP. Elle peut ne pas figurer parmi les

services de sécurité fournis par une SA. C’est le cas lorsque le mécanisme ESP est utilisé pour fournir

uniquement de la confidentialité. Le niveau de ce service de sécurité ne dépend que de l’algorithme

employé. Ainsi, l’intégrité, correspondant à l’élément ‘integrity’, peut être exprimée par un des algorithmes

figurant dans la liste suivante (Tableau 4-1) : « HMAC-SHA1-96 », « AES-XCBC-MAC-96 », « HMAC-

MD5-96 » et « NULL ». Les algorithmes de cette liste ont, également, été définis sur la base des

algorithmes définis dans [SCH 05a].

Remarque : Ces deux paramètres de sécurité (confidentialité et intégrité) ne peuvent pas être « null » en

même temps car il n’y aurait, dans ce cas, aucune sécurité. Quand le protocole ESP est utilisé pour fournir

la confidentialité et l’intégrité, on considère que des algorithmes séparés sont utilisés. En effet,

actuellement, les algorithmes combinés font encore l’objet de recherche. Cependant, si dans le futur, IPsec

adopte d’un ou de plusieurs de ces algorithmes, il sera possible de les négocier en modifiant une partie du

schéma XML du SLS. Notons, également, que la liste des algorithmes utilisés actuellement, recommandés

dans [SCH 05a], est évolutive car de nouveaux algorithmes peuvent apparaître, ne serait que suite à la

découverte d’une faille dans ceux actuellement utilisés.

4.4.1.3.6 Non-rejeu

C’est une forme d’intégrité qui permet de rejeter les paquets rejoués. Le non-rejeu, correspondant à

l’élément ‘noReply’, est un service de sécurité optionnel. Par conséquent, il s’agit de l’unique paramètre

optionnel parmi les paramètres IPSec négociés avec SLNP. Ce service est assuré par un numéro d’ordre

inséré dans les entêtes AH et ESP. Ce numéro d’ordre peut être une valeur de 32 bits (sn : sequence

number) ou de 64 bits (esn : extended sequence number). Ainsi, l’élément ‘noReplay’ est composé de deux

sous-éléments (Figure 4-8). Le sous-élément ‘state’ qui donne l’état de ce service et qui peut avoir la

valeur ‘on’ lorsque ce service est activé, ou la valeur ‘off’ dans le cas contraire (Tableau 4-1). Lorsqu’il est

activé, le deuxième sous-élément ‘size’, qui est optionnel (occurrence minimale égale à 0), permet de se

mettre d’accord sur la taille du numéro d’ordre en bits qui peut être égale à 32 ou 64 (Tableau 4-1).

97

Figure 4-8 : Structure de l’élément ‘noReplay’

4.4.1.4 Paramètres de sécurité TLS-DTLS

Dans la partie consacrée à la description des protocoles de sécurité (section 2.5.2), nous avons vu que

les protocoles TLS et DTLS ont quasiment le même fonctionnement. En effet, mis à part quelques

mécanismes qui ont été ajoutés à DTLS afin de pallier à la non-fiabilité d’UDP, nous avons vraiment les

mêmes principes, la même architecture et les mêmes mécanismes et algorithmes de sécurité. De plus,

suivant la nature de l’application sécurisée, on utilise ou bien TLS, ou bien DTLS. Par conséquent, les

paramètres de sécurité négociés avec SLNP pour une sécurité au niveau transport seront regroupés dans

un seul et même élément ‘tls-dtls’ (Figure 4-9).

Les protocoles TLS et DTLS se fondent sur les notions de session et de connexion afin d’offrir des

services de sécurité. Ces services de sécurité sont offerts par le protocole d’enregistrement (record

protocol) et couvrent l’intégrité et la confidentialité. Le non-rejeu est un service qui est souvent

automatiquement présent. Par conséquent, une session est caractérisée par une suite de chiffrement

(cipher suite) composée des paramètres de sécurité suivants : un algorithme pour la confidentialité et un

autre pour l’intégrité. Ces paramètres, qui déterminent le niveau de sécurité d’un échange de données entre

un client et un serveur, nous permettent de déterminer les paramètres d’une sécurité TLS-DTLS qui

peuvent être négociés avec le protocole SLNP. Ainsi, lorsque le protocole TLS-DTLS doit être utilisé, les

paramètres qui doivent obligatoirement être négociés avec SLNP sont uniquement : ‘confidentiality’ et

‘integrity’ (Figure 4-9).

Figure 4-9 : Structure de l’élément ‘tls-dtls’

4.4.1.4.1 Integrité

Le service d’intégrité peut être assuré grâce à l’utilisation d’un algorithme parmi ceux figurant dans la

liste des algorithmes pouvant être offerts par TLS-DTLS. Le niveau de l’intégrité dépend uniquement de

l’algorithme utilisé. Par conséquent, l’élément ‘integrity’ correspondant à ce service permet le choix d’un

des algorithmes de la liste suivante : ‘sha1’, ‘md5’ ou ‘null’ (Tableau 4-1).

4.4.1.4.2 Confidentialité

Le service de confidentialité est garanti en utilisant un algorithme de confidentialité parmi ceux

offerts par TLS-DTLS. Le niveau de ce service ne dépend que de l’algorithme employé. Par conséquent,

98

l’élément ‘confidentiality’, correspondant à ce service, permet de choisir parmi l’un des algorithmes de la

liste suivante : ‘idea’, ‘rc2-40’, ‘des-40’, ‘des’, ‘3des’, ‘fortezza’, ‘rc4-40’, ‘rc4-128’ ou ‘null’ (Tableau 4-1).

Synthèse : Dans cette partie, nous avons définis les paramètres de sécurité qui doivent être négociés

avec SLNP lorsqu’un niveau de sécurité est requis pour une transmission donnée. Lors de cette définition,

nous avons fournis les schémas XML (représentations graphiques) des différents éléments correspondant

à ces paramètres. Dans la partie suivante, nous définissons le nouveau schéma XML du SLS négocié avec

SLNP afin de permettre à une telle négociation de couvrir à la fois des aspects de QoS et de sécurité.

4.4.2 Définition d’un SLS de QoS et de sécurité

Le schéma XML d’un SLS de QoS, proposé dans [CHA 07] et décrit dans la section 3.4.3, est un

schéma générique qui comprend tous les paramètres sur lesquels peut porter la négociation de QoS avec

SLNP. Ce schéma décrit la composition de l’élément ‘sls’ et sa structure hiérarchique. En effet, l’élément

‘sls’ est composé d’autres éléments tels que l’élément ‘flowId’ qui sert à identifier le flux concerné par la

négociation, ou encore l’élément ‘serviceSchedule’ qui permet de préciser le temps de service. Dans cette

partie, nous proposons d’étendre le schéma XML du SLS de QoS aux paramètres de sécurité définis dans

la section 4.4.1. Ainsi, dans ce qui suit, nous décrivons les modifications apportées à ce schéma XML afin

de permettre la négociation simultanée de la sécurité et de la QoS.

Figure 4-10 : Structure d’un SLS de QoS et de sécurité

Le SLS de QoS comprend des paramètres qui sont communs à la QoS et à la sécurité, et qui resteront

inchangés. Ces paramètres sont : l’identificateur du SLS (slsId), l’identificateur de flux (flowId), les

paramètres de négociation (negotiationParameters) et la fiabilité (reliability). Dans un premier temps, les

paramètres de QoS, à savoir le scope de la QoS (scope), le temps de service (serviceSchedule), la garantie

de performance (performanceGuarantee), la conformité du trafic (trafficConformity) et le traitement

d’excès (excessTreatement) sont tous regroupés dans un unique paramètre appelé paramètres de QoS

(qosParameters). L’élément ‘qosParameters’ est un élément obligatoire (occurrence minimale et

occurrence maximale égales à 1) parce qu’une négociation de niveau de service avec SLNP doit, au moins,

porter sur la QoS. Dans un second temps, nous ajoutons un élément regroupant tous les paramètres de

sécurité que nous appelons ‘secParameters’ (Figure 4-10). Cet élément est composé de deux sous-

éléments, à savoir le scope de sécurité ‘scope’ ainsi que le protocole de sécurité ‘securityProtocol’ (Figure

4-10). Notons que l’élément ‘scope’ contenu dans l’élément ‘qosParameters’ et celui de l’élément

99

‘secParameters’ peuvent avoir des significations différentes. En effet, d’un point de vue QoS, le point

d’entrée et le point de sortie du scope désignent les deux bouts d’une connexion qui peuvent être par

exemple les deux terminaux communicants. Alors que d’un point de vue sécurité, si on utilise IPSec, alors

les points d’entrée et de sortie désignent les deux extrémités d’une association de sécurité. Celles-ci

pourraient être, par exemple, les passerelles de sécurité derrière lesquelles se trouvent les deux terminaux.

Le deuxième élément permet de sélectionner un ou plusieurs protocoles de sécurité pour lesquels un

ensemble de paramètres sont négociés. Ainsi, l’élément ‘ipsec’ contient les éléments définis auparavant, à

savoir ‘saLifetime’, ‘mecanism’, ‘mode’, ‘integrity’, ‘confidentiality’ et ‘noReplay’, alors que l’élément ‘tls-

dtls’ inclut les éléments ‘integrity’ et ‘confidentiality’.

Afin de permettre une négociation optimisée de la sécurité, nous devons nous conformer au modèle

de négociation détaillé dans le chapitre précédent (section 3.4.5). Ceci implique que tous les paramètres de

sécurité de chacun des deux protocoles (IPSec et TLS-DTLS) doivent être composés de deux valeurs : une

valeur demandée « Requested » et une valeur offerte « Offered ». A titre d’exemple, nous considérons

l’élément ‘saLifetime’ qui représente le paramètre temps de vie d’une SA pour une sécurité IPSec. Pour se

conformer au modèle de négociation, ce paramètre sera constitué de deux éléments ‘saLifetimeRequested’

et ‘saLifetimeOffered’ où chacun de ces deux éléments permet d’exprimer le temps de vie d’une SA sous

forme d’une durée ‘duration’ ou d’un nombre d’octets ‘nbBytes’ (Figure 4-11).

Figure 4-11 : Structure supposée de l’élément ‘saLifetime’

Cette distinction de deux champs au niveau de chaque paramètre de sécurité permet à l’initiateur de la

négociation de demander un certain niveau de sécurité relatif à un protocole de sécurité, et au destinataire

de répondre à cette proposition en acceptant cette demande, en la refusant ou en proposant une

alternative. Or, cette alternative consiste à proposer d’autres valeurs pour les paramètres de sécurité du

même protocole demandé par l’entité initiale. Autrement dit, si l’initiateur demande un niveau de sécurité

impliquant le protocole IPSec, alors le destinataire ne pourra pas proposer une alternative utilisant le

protocole TLS ou DTLS. Par conséquent, pour optimiser la négociation et permettre de proposer une

alternative relative au protocole demandé ou en spécifiant des paramètres pour un autre type de sécurité,

nous remontons la distinction de deux champs (demandé et offert) au niveau de l’élément protocole.

Ainsi, l’élément ‘securityProtocol’ sera composé de deux sous-éléments : ‘securityProtocolRequested’ et

‘securityProtocolOffered’, comme l’indique la Figure 4-12.

Figure 4-12 : Structure réelle de l’élément ‘securityProtocol’

100

Notons que dans le cas d’une demande d’un niveau de sécurité où plusieurs types de sécurité sont

empilés, les deux éléments ‘securityProtocolRequested’ et ‘securityProtocolOffered’ sont composés du

même nombre d’éléments (‘ipsec’ et/ou ‘tls-dtls’). Il faut également noter que dans ce cas bien précis

(empilement de protocoles de sécurité), le i-ème élément de ‘securityProtocolOffered’ représente les

paramètres offerts par rapport au i-ème élément de ‘securityProtocolRequested’ composés des paramètres

initialement demandés.

La nouvelle structure du SLS est décrite par le schéma XML représenté dans la Figure 4-10. Cette

nouvelle forme du SLS va permettre au protocole SLNP d’assurer la négociation conjointe de la QoS et de

la sécurité. Les paramètres de sécurité intégrés au SLS sur lequel porte la négociation étant à présent

définis, nous allons pouvoir définir le nouveau fonctionnement de cette négociation. Pour cela, nous

réservons la section suivante à la description d’un certain nombre de scénarii de négociation. Ceci

permettra de se familiariser avec le fonctionnement général de la nouvelle négociation tout en identifiant

les principales modifications devant être apportées à ce fonctionnement.

4.4.3 Scénarios d’utilisation de SLNP pour offrir la QoS et la sécurité

Un SLS peut être négocié au sein d’un même domaine, nous parlons dans ce cas d’une négociation

intra-domaine, ou encore entre différents domaines et il s’agit alors d’une négociation inter-domaines.

Ainsi, le premier scénario fourni dans cette section illustre une négociation intra-domaine, alors que les

autres exemples montrent le déroulement d’une négociation inter-domaines.

Dans tous ces exemples de négociation conjointe, nous mettons en avant un ensemble de paramètres

de QoS et de sécurité. Par souci de simplification, nous considérons uniquement le paramètre délai pour la

QoS, et les paramètres protocole et algorithme de confidentialité pour la sécurité.

Nous supposons qu’une entité SLNP dispose de toutes les informations concernant la QoS dans son

propre domaine, en particulier le délai de transmission de données produit sur son domaine relativement à

l’offre qu’elle peut faire. Nous supposons, également, qu’elle est en mesure d’obtenir toute information sur

les propriétés de sécurité (protocoles supportés, algorithmes supportés, performances, etc.) de n’importe

quelle entité (terminal, routeur, passerelle de sécurité, etc.) appartenant à ce domaine (algorithmes

supportés, temps des traitements, etc.). Ces informations, stockées dans la RMF (Resource Management

Function) de chaque entité de négociation, permettent à ces entités d’assurer la négociation en échangeant

et en traitant correctement les messages SLNP.

Pour chacun des exemples présentés dans la suite de cette section, nous fournissons une vue

d’ensemble du réseau qui permet de distinguer les différentes entités mises en jeu, ainsi que le MSC

(Message Sequence Chart) correspondant afin d’expliquer clairement le déroulement de la négociation.

4.4.3.1 Exemple d’une négociation intra-domaine

Dans ce premier scénario (Figure 4-13), l’utilisateur « Client 1 » du « LAN1 » négocie un niveau de

service pour sa communication avec l’utilisateur « Client 2 » du « LAN2 ». Il s’agit d’une négociation intra-

domaine car les deux réseaux locaux « LAN1 » et « LAN2 » appartiennent au même domaine « Domaine

1 » dont le responsable est l’entité de négociation « SE ». Le SLS que veut établir le « Client 1» concerne

une communication de type voix sur IP (VoIP : Voice over IP), et est caractérisée par des paramètres de

QoS comme l’identification de flux, la portée de la QoS, la garantie de performance (délai, gigue, taux de

101

perte, bande passante). Ce SLS est également concernée par un niveau de sécurité que demande le « Client

1 », et qui est caractérisé par l’utilisation du protocole DTLS afin de protéger la confidentialité des

données grâce à l’algorithme « 3des » (Figure 4-14).

Figure 4-13 : Scénario 1 - négociation intra-domaine

L’utilisation du protocole DTLS et de l’algorithme « 3des » pour la confidentialité sont bien

évidemment supportés par le terminal du « Client 1 ». Par ailleurs, ce niveau de sécurité (protocole DTLS

et algorithme « 3des ») est également supporté par le « Client 2 » ; ce qui pourra permettre de conclure

rapidement un contrat de niveau de service si l’offre de QoS ne pose pas de problème.

SLS QoS � Garantie de performance � Délai : D = 200 ms

Sécurité � Protocole : P = dtls Sécurité � Dtls � Confidentialité : A = 3des

Figure 4-14 : SLS négocié dans le scénario 1

Pour décrire le déroulement de la négociation de niveau de service entre le « Client 1 » et son

responsable de domaine « SE », nous nous basons sur le MSC fourni dans la Figure 4-15. Sur ce MSC,

ainsi que sur ceux des Figures 4-18 et 4-20, nous pouvons voir que le Client 1 participe directement à la

négociation de niveau de service utilisant SLNP. Cette participation est permise grâce à

l’introduction d’une couche de négociation au niveau des terminaux des utilisateurs (cf. section

5.3.4).

Afin d’établir un niveau de service pour sa communication avec le « Client 2 », le « Client 1 » prépare

sa requête « Negotiate » avec les paramètres négociés et les valeurs correspondant aux niveaux requis pour

la QoS et la sécurité (Figure 4-14). Ensuite, cette requête est envoyée vers le responsable de domaine

« SE ». Cette entité de négociation, va étudier la recevabilité de cette requête en interrogeant la RMF sur le

délai qu’elle peut offrir pour cette communication, mais aussi sur les caractéristiques de sécurité des deux

entités « Client 1 » et « Client 2 ». En effet, en fonction des informations fournies par la RMF, la SE va

regarder, tout d’abord, si le niveau de sécurité demandé par le « Client 1 » peut être offert par le « Client

2 », ce qui est le cas de notre exemple. Ensuite, le délai de bout en bout est calculé sur la base du délai de

circulation des données sur le réseau (120 ms) auquel on ajoute les délais résultant des opérations de

chiffrement et de déchiffrement (8 ms + 8 ms). Ces délais supplémentaires sont estimés par la SE en

fonction du protocole et de l’algorithme utilisé mais aussi en fonction des performances des terminaux des

utilisateurs « Client 1 » et « Client 2». Ainsi, dans cet exemple, le délai de bout en bout requis par la

102

communication peut être largement satisfait (200 > 136) et le niveau de sécurité proposé par « Client 1 »

(tls, 3des) peut également être offert par « Client 2 ». Par conséquent, l’entité de négociation peut accepter

(Response-Ack) le niveau de service demandé par « Client 1 ».

Figure 4-15 : MSC du scénario 1

Une fois l’accord établi, le SLS doit être enregistré au niveau de la SE et les procédures de

configuration de la QoS et de la sécurité doivent être lancées. La QoS est assurée en configurant les

routeurs impliqués dans l’acheminement des paquets relatifs à la communication VoIP entre Client 1 et

Client 2. Tandis que la sécurité est configurée (Figure 4-15) en passant les paramètres de sécurité négociés

afin d’agir sur les suites de chiffrement proposées dans le message « Hello » lors de la poignée de main du

protocole DTLS (cf. Section 2.5.2.3). Notons que si l’on avait un échange d’un autre type (TCP par

exemple) et qu’on devrait sécuriser avec TLS, la procédure de configuration de sécurité serait la même.

Par souci de simplification, nous avons omis le scope de sécurité qui doit absolument figurer dans le

SLS afin de désigner les deux extrémités entre lesquelles la sécurité est offerte, la portée de la sécurité,

dans cet exemple, est : Client1 – Client2.

4.4.3.2 Exemples de négociations inter-domaines

Figure 4-16 : Scénarios 2 et 3 - négociations inter-domaines

103

Les deux exemples de négociation, que nous décrivons ci-dessous, concernent la même situation.

Dans ces deux scénarios (Figure 4-16), l’utilisateur « Client 1 » du « LAN1 » négocie un niveau de service

pour sa communication avec l’utilisateur « Client 3 » du « LAN3 ». Il s’agit de négociations inter-domaines

car les deux réseaux locaux « LAN1 » et « LAN3 » appartiennent à deux domaines différents ; « LAN1 »

appartient au « Domaine 1 » dont le responsable est l’entité de négociation « SI », alors que « LAN2 » se

trouve dans le « Domaine 3 » géré par l’entité « SR ». Ainsi, ces négociations impliquent trois entités (SI,

SF et SR) et couvrent les mêmes paramètres de niveau de service décrits dans le scénario précédant (délai,

protocole de sécurité et algorithme de confidentialité).

4.4.3.2.1 Négociation sans compris entre QoS et sécurité

Dans ce deuxième scénario, le SLS que veut établir le « Client 1» concerne toujours une

communication de VoIP caractérisée par un niveau de QoS qui se résume dans le paramètre délai dont la

valeur de bout en bout doit être égale à « 200 ms » au maximum. Cette communication nécessite

également un niveau de sécurité pouvant être garanti par le biais du protocole IPSec en utilisant

l’algorithme de confidentialité « 3des-cbc » (Figure 4-17).


Sécurité � Protocole : P = ipsec Sécurité � Dtls � Confidentialité : A = 3des-cbc


Le portée de la sécurité, cette fois-ci, est constituée par les passerelles de sécurité SG1 et SG3 derrière

lesquelles se trouvent respectivement les deux clients : Client 1 et Client 3. Ceci est dû au non support du

protocole IPSec par aucun de ces deux clients (Client 1 et Client 3).

Afin d’établir le niveau de service nécessaire à sa communication avec le Client 3, le Client 1 prépare

sa requête « Negotiate » avec les paramètres négociés et les valeurs correspondant aux niveaux requis pour

la QoS et la sécurité (Figure 4-18). Notons que dans cette requête, les champs des valeurs offertes

(« offered ») des paramètres de sécurité (protocole et algorithme) sont initialisés à « null », car le Client 1

n’a aucune idée sur les propriétés de la passerelle de sécurité SG1 derrière laquelle il se trouve. Ensuite,

cette requête est envoyée vers le responsable de son domaine SI. L’entité de négociation SI, va interroger

la RMF sur la QoS de son réseau et sur les paramètres de sécurité de la SG. Les informations fournies par

la RMF de la SI, permettent à cette dernière de mettre à jour les valeurs offertes de tous les paramètres

négociés. Les champs relatifs à l’offre du protocole et de l’algorithme de sécurité ont maintenant les

mêmes valeurs que celles des champs relatifs à la demande, parce que la passerelle SG1 supporte le niveau

de sécurité demandé par le Client 1. Tandis que le délai offert devient égal à 65 ms. Ces 65 ms

représentent la somme du délai de transit sur le réseau du domaine 1 (60 ms) et du délai résultant du

chiffrement des paquets de voix. Une fois traité par la SI, le message Negotiate est transféré vers la SF qui

apporte, également, des modifications relatives au paramètre de QoS, à savoir le délai. En effet, la valeur

offerte de ce délai devient égale à 125 ms, suite à une augmentation de 60 ms représentant le délai de

transit sur le réseau du deuxième domaine (domaine 2) (Figure 4-18). Après cette modification, le message

Negotiate est transmis à l’entité de négociation finale (SF). Après une interaction avec sa RMF, la SR met à

jour le délai offert en ajoutant le délai de transit sur son réseau (60 ms) et celui pouvant être introduit par

les traitements de sécurité (5 ms) ; ce qui fait un délai total de 190 ms, ce qui est inférieur aux 200 ms

104

exigés par le Client 1. En traitant l’offre de sécurité, la SR s’aperçoit que l’algorithme proposé n’est pas

supporté par la passerelle de sécurité SG3. Ainsi, la SR propose une alternative au SLS demandé dans un

message Revision où elle suggère l’utilisation de l’algorithme aes-cbc (Figure 4-18) qui est considéré

comme plus robuste que celui demandé par le Client 1 (3des-cbc). Le message Revision suit le chemin

inverse du message Negotiate jusqu’à ce qu’il arrive au Client 1. Malgré le fait que l’algorithme aes-cbc soit

supporté par la SG1 et que le délai de bout en bout soit inférieur à 200 ms, le Client 1, ne peut pas

accepter l’alternative proposée et doit renégocier le SLS avec les nouveaux paramètres suggérés. Ceci est

dû à la non-fiabilité de l’ancien calcul du délai de bout en bout. En fait, ce calcul était effectué sur la base

d’un certain niveau de sécurité car il tient compte de l’impact de ce niveau de sécurité sur la QoS. En

modifiant le niveau de sécurité, comme par exemple l’algorithme de chiffrement, l’ancien calcul de l’offre

de QoS n’est plus valable et doit être refait. Lors de la deuxième passe de négociation, le délai de bout en

bout nouvellement calculé est égal, cette fois-ci, à 194 ms (Figure 4-18), ce qui est supérieure à celui

calculé lors de la première passe (190 ms). Ceci est normal parce qu’un algorithme plus robuste a

généralement un impact plus important que celui d’un algorithme moins robuste. Le nouveau délai (194

ms) permet toujours de répondre aux besoins de la communication. Par ailleurs, le niveau de sécurité peut,

également, être accepté car les deux extrémités de la portée de sécurité supportent le protocole IPSec et

l’algorithme aes-cbc. Par conséquent, un accord peut être établi en acceptant le SLS demandé (Response-

Ack).


105

Après cette entente sur les paramètres de niveau de service, le SLS doit être enregistré au niveau des

responsables de domaines (SI, SF et SR) et la QoS ainsi que la sécurité doivent être configurées.

Lorsqu’IPSec est utilisé, les valeurs des paramètres de sécurité négociées avec SLNP serviront à mettre en

œuvre le protocole IPsec et à configurer des SA afin de sécuriser le trafic. Ceci se fait en ajoutant une ou

plusieurs entrées dans les SPD pour désigner le trafic à sécuriser et spécifier comment le sécuriser. Lors de

l’envoi du premier paquet voix de ce trafic, les SA seront établies automatiquement grâce à un protocole

de gestion des SA tel que IKE. L’établissement de ces SA fait appel à la négociation ISAKMP (cf. section

4.3.1.1). Cependant cette négociation n’est pas vraiment une négociation, elle sert plutôt à établir les SA

car la négociation en amont, assurée par SLNP, permet de faire effectivement le choix des paramètres de

sécurité. En effet, le message « proposal » d’ISAKMP, envoyé par l’émetteur, ne contient qu’une seule

proposition contenant les paramètres de sécurité déjà négociés avec SLNP. Cette proposition sera

normalement acceptée sans aucun problème par le récepteur.

Même si, dans le scénario fourni ci-dessus, on ne voit aucune intervention de l’entité intermédiaire

(SF) dans la négociation de la sécurité, celle-ci joue un rôle dans cette négociation (sécurité). En effet, une

entité intermédiaire peut intervenir s’il y a un problème lors du transport des paquets IPSec sur son réseau.

Par ailleurs, elle peut avoir à participer à la mise en œuvre de la sécurité en transmettant des politiques de

sécurité aux entités de sécurité dans son réseau (politiques de type BYPASS). Par contre, il est vrai que

dans le cas d’une négociation d’un niveau de sécurité qui sera assuré grâce à TLS ou DTLS, les entités

intermédiaires n’ont aucune raison d’intervenir dans cette négociation.

Notons que, si une sécurité IPSec ne peut être établie à cause du non support de ce protocole ou à

cause de problèmes qui peuvent se poser comme la traversée des NAT (Network Address Translation)

[EGE 94], alors on peut tenter de mettre en place une sécurité à un autre niveau de la pile de

communication (au niveau « Transport » par exemple).

4.4.3.2.2 Négociation avec un compromis entre QoS et sécurité

Dans ce deuxième exemple de négociation inter-domaines, nous considérons toujours l’architecture

du réseau donnée dans la Figure 4-16 ainsi que la même application pour laquelle le Client 1 veut établir

un niveau de service. Ce qui change par rapport au scénario précédent est le SLS négocié donnée dans la

Figure 4-19.


Sécurité � Protocole : P = dtls Sécurité � Dtls � Confidentialité : A = 3des


Etant donné que le temps de transit sur chacun des trois réseaux est toujours égal à 60 ms et que le

temps de chiffrement ou de déchiffrement en utilisant l’algorithme 3des avec le protocole dtls est estimé à

8 ms, le délai de bout en bout calculé lors de la première passe de négociation sera égal à 196 ms, ce qui est

malheureusement supérieur au délai requis par la communication. Ainsi, malgré la possibilité d’utiliser

l’algorithme ‘3des’ avec le protocole ‘dtls’ sur les deux extrémités Client 1 et Client 2, le SLS demandé ne

peut pas être accepté. Par contre, l’entité finale de négociation propose l’utilisation de l’algorithme ‘des’ au

lieu de l’algorithme ‘3des’ dans son message Revision. En fait, la SR sait qu’en dégradant un peu le niveau

106

de sécurité, l’impact de la sécurité sur la QoS sera moins important ; ce qui pourrait permettre d’arriver à

un accord. En effet, ce qui empêche cet accord d’avoir lieu est la valeur estimée du délai de bout en bout

qui est légèrement supérieure à celle demandée dans le SLS (196 ms > 190 ms). Ainsi, en choisissant de

dégrader le niveau de sécurité en demandant l’utilisation de l’algorithme ‘des’ au lieu de ‘3des’, un accord

sur le niveau de service a pu avoir lieu lors de la deuxième passe de négociation. Le Client 1 aurait pu

demander le même niveau de sécurité, et dégrader le niveau de la QoS en demandant un délai supérieur ou

égal à 196 ms. Ceci aurait aboutit, également, à un accord simultané sur les niveaux de QoS et de sécurité.

Par conséquent, nous pouvons noter que dans ce troisième scénario, les niveaux de QoS et de sécurité,

initialement demandés, ne peuvent pas être simultanément garantis par l’ensemble de réseau. Ainsi, un

compromis entre ces deux niveaux doit être trouvé et l’un des deux niveaux (si ce n’est les deux) doit être

suffisamment dégradé afin de permettre l’établissement d’un accord sur le SLS.

Rappelons que si on avait établi un niveau de sécurité avec le mécanisme propre à DTLS, à savoir le

protocole de poignée de main, alors le niveau de sécurité aurait pu être suffisamment élevé pour empêcher

le déroulement normal de la communication, même si la QoS avait été négocié avec SLNP. D’où l’intérêt

de négocier simultanément la QoS et la sécurité avec SLNP afin de prendre en considération l’influence du

niveau de sécurité sur le niveau de la QoS.


107

La négociation de niveau de service assurée par SLNP est une négociation dynamique, ce qui permet

à tout moment de modifier le niveau de service déjà établi. Ceci pourrait être la conséquence de l’évolution

des besoins des utilisateurs ou encore le non-respect d’un contrat établi de la part de l’un des domaines

impliqués dans la négociation.

Pour éviter de trop compliquer les scénarios fournis, nous avons évité de donner des exemples où

l’offre de niveau de service porte sur un empilement de plusieurs types de sécurité. Par contre, nous avons

cherché à identifier différents cas de figure qui nous permettent de couvrir un maximum de possibilités

afin d’identifier le comportement général d’une entité de négociation. Ceci nous permettra, par la suite,

d’établir les algorithmes des traitements au niveau de chaque type d’entité de négociation (SI, SF et SR).

4.4.4 Nouveau fonctionnement du protocole SLNP

Rappelons que la négociation de niveau de service assurée par SLNP se base sur la technologie des

services web afin d’offrir l’interopérabilité entre les différentes entités pouvant faire partie d’une telle

négociation. Cependant, cette technologie est fondée sur l’invocation des opérations composant un service

web. Puisqu’une entité de négociation peut être initiale, intermédiaire ou finale, alors elle doit contenir une

application cliente de négociation et un service web de négociation. Ainsi, implémenter l’extension du

protocole SLNP à la sécurité que nous avons déjà spécifiée revient à apporter les modifications nécessaires

aux composantes d’une entité de négociation, à savoir le service web et l’application cliente. Ceci permet

de prendre en compte les paramètres de sécurité, que nous avons définis dans la section 4.4.1, dans le

processus de négociation de niveau de service.

Dans cette section, nous décrivons les modifications apportées au fonctionnement du protocole

SLNP qui ne prenait initialement en compte que la QoS. Ainsi, nous détaillons, dans un premier temps,

les changements qu’a connu l’application cliente de négociation afin de permettre la négociation conjointe

de la QoS et de la sécurité. Dans un second temps, nous nous intéressons à la structure du service web de

négociation ainsi qu’aux traitements qui y sont inclus.

4.4.4.1 Modification de l’application cliente de négociation

L’application cliente permet à une SI d’établir, modifier ou résilier un SLS en invoquant le service

web de l’entité suivante avec le message approprié (Negotiate, Modify ou Release). Elle permet également

à une SF ou à une SR d’informer une SI sur d’éventuels changements de disponibilités des ressources

(Notify).

Afin de décrire les modifications apportées à l’application cliente de négociation, nous allons

considérer le processus d’établissement d’un niveau de service. Dans ce cas bien précis de négociation,

nous allons commencer par rappeler l’ancien fonctionnement, qui ne permet de couvrir que la négociation

des paramètres de QoS, à travers le diagramme de fonctionnement de la Figure 4-21.

Sur ce diagramme, nous pouvons voir que l’établissement d’un accord sur un niveau de QoS

commence par la constitution d’un message Negotiate qui va servir à invoquer l’opération de négociation

de l’entité suivante sur le chemin de négociation. Suivant, le type du message retourné, suite à cette

invocation, nous distinguons cinq comportements différents. Premièrement, si le niveau de QoS demandé

est accepté par l’ensemble du réseau (message retourné = Response-Ack), alors l’entité initiale procède à

l’enregistrement du SLS et la négociation est terminée. Le deuxième cas de figure est le rejet de la demande

108

de la SI (message retourné = Response-Nack) qui ne nécessite aucun traitement et mène directement à la

fin de la négociation. Il est, également, possible de retourner à la SI un message Revision. Ce message

permet de proposer une alternative au SLS demandé par cette SI. Lorsque la SI reçoit une alternative

qu’elle peut accepter, elle envoie un message Response-Ack après avoir procédé à l’enregistrement du SLS.

Dans le cas où l’alternative proposée ne peut pas être acceptée, la SI doit rejeter cette proposition en

envoyant un message Response-Nack ou bien en procédant à une deuxième passe de négociation.

Figure 4-21 : Algorithme de l’établissement d’un SLS (QoS)

Dans le diagramme de traitements présenté dans la Figure 4-21, nous pouvons voir les différentes

composantes : les actions et les tests. Dans notre implémentation, chacune de ces composantes

correspond à un module implémenté en langage Java. Afin de permettre l’introduction de la sécurité dans

le SLS négocié, nous avons, tout d’abord, commencé par la prise en compte des paramètres de sécurité

dans les traitements de chaque module. A titre d’exemple nous considérons l’action ‘Créer un message

Negotiate’. Dans l’ancienne version de la négociation, qui porte uniquement sur les paramètres de QoS, le

module correspondant à cette action est composé de plusieurs tâches (Figure 4-22-a). En effet, il prend en

arguments les paramètres de QoS qui permettent de désigner le niveau de service demandé. Ensuite, il

interagit avec la RMF afin d’obtenir des informations sur l’offre locale de la SI. A la fin de cette

interaction, ce module dispose de toutes les valeurs nécessaires (demandées et offertes) à la création du

109

SLS. Ainsi, il s’occupe de la constitution du SLS à négocier avant de créer le message Negotiate.

Maintenant, pour permettre la négociation des paramètres de sécurité en plus des paramètres de QoS, il

faut apporter les modifications nécessaires tout en préservant l’ancien fonctionnement lorsque la

négociation porte uniquement sur la QoS. Ainsi, les traitements nécessaires à la négociation des

paramètres de sécurité ont été ajoutés dans ce but. Le nouvel algorithme des traitements nécessaires à la

création du message Negotiate (Figure 4-22-b), permet de déterminer les paramètres relatifs à la sécurité

lorsque celle-ci est requise dans le niveau de service. Il permet, également, d’estimer l’impact de cette

sécurité sur la QoS afin de déterminer les valeurs effectives des paramètres de QoS. L’estimation de

l’impact se fait en fonction des paramètres de sécurité et des performances de l’entité chargée des

traitements de sécurité.

a : Négociation de la QoS b : Négociation conjointe de la QoS et de la sécurité

Figure 4-22 : Traitements nécessaires à la création du message Negotiate

Les adaptations visant à introduire la sécurité couvrent non seulement les traitements inclus dans les

différents modules, mais aussi l’algorithme général des traitements de l’entité initiale (SI). En fait, nous

avons déjà signalé qu’une entité initiale n’a pas le droit d’accepter une alternative qui lui est proposée par le

réseau, dans le cadre d’une négociation conjointe (QoS et sécurité). Dans la section 4.4.3.2, nous avons

expliqué les raisons pour lesquelles une SI ne peut pas accepter une alternative, même si elle la juge

suffisante pour répondre à ses besoins en matière de QoS et de sécurité. Par conséquent l’algorithme sera

modifié afin de ne permettre l’acceptation d’une alternative que dans le cas d’une négociation qui porte

uniquement sur la QoS. Dans le cas contraire, la négociation doit être initiée de nouveau. Afin de

distinguer les modifications apportées à l’algorithme général des traitements, celles-ci sont ajoutées en

pointillés dans la Figure 4-23.

110

Figure 4-23 : Algorithme de l’établissement d’un SLS (QoS + Sécurité)

4.4.4.2 Modification du service web de négociation

Le service web de négociation contient cinq opérations (Figure 3-21) et permet à une entité de

recevoir une demande, de la traiter et de renvoyer une réponse à l’entité appelante. Cette réponse est un

message qui peut être produit par l’entité elle-même ou être la retransmission de la réponse reçue suite à

l’invocation de l’entité suivante.

La structure du service web de négociation reste inchangée afin de répondre aux besoins de

négociation qui sont toujours les mêmes. En revanche, les traitements contenus dans les différentes

opérations composant ce service web doivent être adaptées à la nouvelle structure du SLS négocié. Ceci

permettra de prendre en compte les paramètres de sécurité dans la négociation au niveau des entités

intermédiaires (SF) et finales (SR).

Pour avoir une idée sur les modifications apportées à l’implémentation de SLNP au niveau d’une SF

ou d’une SR, nous allons considérer une des cinq opérations du service web de négociation, à savoir

l’opération de négociation : ‘negotiationOperation’. Cette opération est invoquée lors de l’établissement

111

d’un SLS (cf. section 3.4.5.3). L’appel à cette opération est toujours initié par une entité initiale qui

engendre un appel récursif aux opérations de négociation de toutes les entités impliquées dans une

négociation.

Figure 4-24 : Algorithme de l’opération de négociation

L’algorithme du fonctionnement global de cette opération, représenté dans la Figure 4-24, ne

nécessite aucune modification. En effet, l’ordre dans lequel sont présentés les traitements sur cet

algorithme est conforme à la négociation conjointe de QoS et de sécurité. Afin d’optimiser le

fonctionnement du protocole SLNP, nous avons conçu cet algorithme d’une manière à ce qu’il soit

commun aux entités de types SF et SR. Lorsqu’il s’agit d’une entité intermédiaire (SF), l’élément SLS est

extrait du message reçu (Negotiate). Ensuite, les modifications nécessaires sont apportées à ce SLS avant

de reconstituer le message Negotiate et de le transmettre à l’entité suivante sur le chemin de négociation.

Puis, le message retourné, suite à cette invocation, est transmis à l’entité précédente après avoir enregistré

localement le SLS dans la table réservée à cet effet, au cas où un accord a été établi (Response-Ack). Dans

le cas d’une entité finale (SR), après avoir modifié le SLS reçu en fonction de l’offre locale, une

comparaison entre l’offre et la demande est effectuée afin de décider de la recevabilité de la demande faite

par l’entité initiale (SI). Si cette demande peut être acceptée, alors la SR peut répondre avec un message

Response-Ack après avoir enregistré localement le SLS établi. Dans le cas contraire, cette SR peut

112

proposer une alternative en retournant un message Revision, ou mettre fin à la négociation en refusant la

demande dans la SI, grâce à un message Response-Nack.

Comme nous l’avons déjà précisé, l’algorithme décrivant ce fonctionnement global au niveau d’une

entité intermédiaire ou finale reste inchangé. En revanche, les composantes de cet algorithme c’est-à-dire

les actions et les tests qu’on peut distinguer sur la Figure 4-24 doivent être adaptées afin de prendre en

considération la sécurité dans la négociation.

a : Négociation de la QoS b : Négociation conjointe de la QoS et de la sécurité

Figure 4-25 : Traitements nécessaires à la modification du SLS

A titre d’exemple, nous considérons l’action ‘Apporter les modifications nécessaires au SLS’. Dans

l’ancienne version de la négociation, qui porte uniquement sur les paramètres de QoS, le module

correspondant à cette action est composé de plusieurs tâches (Figure 4-25-a). En effet, il prend en

argument le SLS reçu par l’entité. Ce SLS contient des détails sur le niveau de service demandé

initialement par la SI mais aussi sur l’offre cumulée des domaines précédents. Ainsi, les modifications à

apporter consistent à ajouter l’offre du domaine dont l’entité de négociation est responsable. Afin de

pouvoir ajouter son offre locale par rapport à la QoS, cette entité doit interagir avec sa RMF afin d’obtenir

des informations sur cette offre. Ceci lui permettra de modifier les valeurs ‘offertes’ des paramètres

négociés en ajoutant son offre locale. Ensuite, le SLS est reconstitué et il est prêt pour la suite des

traitements (transfert à l’entité suivante ou décision de recevabilité). Maintenant, pour permettre la

négociation des paramètres de sécurité en plus des paramètres de QoS, il faut apporter les modifications

113

nécessaires tout en préservant l’ancien fonctionnement lorsque la négociation porte uniquement sur la

QoS. Le nouvel algorithme des traitements nécessaires à la modification du SLS (Figure 4-25-b), permet

d’apporter les modifications relatives aux paramètres de sécurité lorsque cette dernière est requise. Il

permet, également, d’estimer l’impact du niveau de sécurité sur la QoS afin de le prendre en compte par la

suite, c’est-à-dire lors de l’ajout de l’offre locale en matière de QoS. L’estimation de l’impact de la sécurité

sur la QoS est effectuée, non seulement sur la base des paramètres de sécurité, mais aussi en fonction des

performances de l’extrémité de sécurité appartenant au domaine en question.

Notons qu’il existe un cas que nous avons déjà identifié et que nous n’avons pas pris en compte dans

l’implémentation actuelle de SLNP. Il s’agit de la situation où la sécurité demandée par la SI pose un

problème au niveau d’un domaine intermédiaire, notamment dans le cas du non support d’IPSec. Dans ce

cas de figure, nous prévoyons de donner la possibilité à cette entité intermédiaire de répondre elle-même à

l’entité initiale avec un message Response-Nack en précisant dans le champ réservé ‘reason’ de ce message

qu’il s’agit d’un rejet prématuré de la demande (la demande n’a pas atteint l’entité finale) à cause du non

support du protocole IPSec. Dans ce cas, l’entité initiale doit utiliser un autre protocole pour la sécurité de

sa communication (TLS ou DTLS) ou changer le chemin de transmission de données, c’est-à-dire passer

par d’autres réseaux intermédiaires qui pourront ne pas poser de problème lors de la négociation.

Stratégies de négociation : Lorsque les scénarios ont été présentés, nous avons vu que, parfois, l’entité

initiale doit faire un compromis entre la QoS et la sécurité. Ce compromis ne dépend que des stratégies

que nous avons implémentées. En effet, ces stratégies consistent à spécifier quels types de paramètres

(QoS ou sécurité) peuvent être dégradés en premier tout en spécifiant un seuil pour chaque type de

paramètres à ne pas dépasser. Ainsi, au début d’une négociation, nous attribuons un couple de

pondération (1,0) afin d’indiquer quel type de paramètres peut être dégradé (pondération = 1). Lorsque

ces paramètres ne peuvent plus être dégradés (atteinte du seuil minimal spécifié pour ces paramètres), la

pondération est automatiquement inversée, ce qui permet de dégrader les paramètres qui n’ont pas été

touchés. Si on atteint le seuil spécifié pour le deuxième type de paramètres sans arriver à un accord sur le

niveau de service alors la SI doit mettre fin à la négociation. Ces stratégies de négociation sont assez

simples mais peuvent être compliquées en rendant par exemple le système de pondération des types de

paramètres à dégrader plus dynamique. Ceci peut être fait en fixant plusieurs seuils pour chaque type de

paramètres afin de permettre de basculer entre ces types, ou encore en basculant d’un type à l’autre en

fonction du rang de la passe de négociation, etc.

Il est très important de souligner l’utilité de ces stratégies dans la résistance à un certain nombre

d’attaques, comme l’attaque par déni de service. Ce type d’attaque consiste à générer une charge volontaire

du réseau afin de provoquer une baisse de la QoS d’un ou plusieurs domaines impliqués dans l’offre de

niveau de service. La baisse de la QoS peut, à son tour, provoquer une renégociation et donc peut

engendrer une diminution du niveau de sécurité. Les stratégies de négociation d’une entité initiale

permettent de fixer un seuil minimal pour le niveau de sécurité, en dessous duquel toute proposition est

rejetée. Ainsi, ce sont ces stratégies qui permettent de pallier à ce type d’attaque.

Synthèse : L’extension du protocole SLNP à nécessité un autre type de modifications. Il s’agit des

modifications apportées aux bases de données associées à chaque entité de négociation. En effet, ces bases

de données permettent, non seulement le stockage des informations de QoS et de sécurité propres au

domaine géré par chaque entité (simulation de la RMF), mais aussi la gestion des SLS (simulation du

114

registre des SLS). Ainsi, les champs nécessaires à la gestion de la sécurité ont été ajoutés dans toutes les

tables des bases de données. Nous avons, également, ajouté un espace dans ces bases qui permet de

stocker les stratégies implémentées par les différentes entités afin de pouvoir les modifier à tout moment

sans avoir à toucher au code.

4.4.5 Tests et évaluations des performances

Une fois l’implémentation de la négociation de niveau de service portant à la fois sur la QoS et la

sécurité réalisée, nous avons procédé à un ensemble de tests afin d’évaluer les performances de la

négociation SLNP.

4.4.5.1 Plateforme de tests

Pour évaluer notre contribution, nous avons utilisé la plateforme d’expérimentation présentée dans la

Figure 4-26. Sur cette plateforme, nous pouvons distinguer trois entités de négociation qui implémentent

toutes le protocole SLNP. Dans chaque implémentation, nous avons choisi d’utiliser le serveur

d’applications TOMCAT d’Apache [TOM 09] sur lequel le service web de négociation de chaque entité

sera déployé. Comme implémentation du protocole SOAP, nous avons opté pour l’implémentation

d’Apache appelée AXIS [AXI 09] qui est facilement déployée sur le serveur TOMCAT. Pour la gestion

des bases de données, nous avons utilisé MySQL [SUN 09a] qui représente un serveur de bases de

données relationnelles SQL (Structured Query Language) robuste et rapide. L’implémentation d’une

application cliente de négociation ainsi que celle des différentes opérations d’un service web de

négociation ont été réalisées dans un langage de programmation orienté objet, à savoir le langage Java

[SUN 09b]. Ce choix n’implique pas que toute entité qui implémente le protocole SLNP doit utiliser la

même plateforme ou encore le même langage de programmation. Bien au contraire, le protocole SLNP

utilise les services web afin de permettre l’interopérabilité entre les différents responsables de domaines

qui veulent négocier un niveau de service de bout en bout.

Figure 4-26 : Plateforme de tests du fonctionnement du protocole SLNP

4.4.5.2 Tests du fonctionnement

L’implémentation Apache de SOAP, à savoir Axis, fournit un outil appelé SOAP Monitor [SOA 09]

qui nous permet de vérifier le bon déroulement de l’appel à un service web. En effet, il s’agit d’une

application qui peut être déployée sur le serveur web d’une entité de négociation et vers laquelle il faut

115

rediriger les flux entrant ainsi que les flux sortant pour ce service web. Cet outil nous permet, également,

de capturer la trace des messages d’entrée et, éventuellement, de sortie des opérations. Nous avons utilisé

cet outil pour tester le nouveau fonctionnement de l’application cliente de la SI ainsi que celui des cinq

opérations du service web de négociation de la SF et de la SR. Les tests des différents processus de

négociation (établissement, modification, notification, résiliation) ont été réalisés avec succès. En effet,

nous invoquons les différentes opérations d’un service web de négociation et nous vérifions, par la suite, si

le message de sortie correspond bien au message auquel on s’attendait et si les paramètres inclus dans ce

message sont conformes à ceux de la réponse attendue. Nous avons également joué en même temps sur

les valeurs déterminant le niveau de service demandé par la SI ainsi que sur les offres locales de la SF et de

la SR afin de tester un maximum de scénarios de négociation. Les tests réalisés nous ont permis de

conclure à la validité de notre implémentation ; notre protocole de négociation conjointe de QoS et de

sécurité fonctionne correctement.

La Figure 4-27 représente une partie de la trace d’un message Negotiate encapsulé dans une

enveloppe SOAP. Ce message, obtenu grâce à l’outil SOAP Monitor, permet à la SI d’initier une

négociation de niveau de service en invoquant l’opération de négociation du service web de négociation de

l’entité suivante sur le chemin de la négociation, à savoir la SF (Figure 4-26).

<?xml version="1.0" encoding="utf-8"?> <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"

xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

<soapenv:Body> <Negotiate xmlns="urn:WSNegotiation3"> <negotiationId xmlns="">2001</negotiationId> <endNegotiation xmlns="">true</endNegotiation> <sls xsi:type="ns1:SlsType" xmlns="" xmlns:ns1="urn:WSNegotiation3"> ... </sls>

</Negotiate> </soapenv:Body> </soapenv:Envelope>

Figure 4-27 : Un message Negotiate visualisé à l’aide de SOAP Monitor

4.4.5.3 Evaluation du temps de négociation

Afin d’évaluer le temps de négociation, nous avons effectué des tests locaux, c’est-à-dire que les trois

entités de la plateforme de tests (SI, SF et SR) ont été déployées sur une même machine. Il s’agit d’un

serveur Dell Precision PWS670 avec un processeur Intel Xeon à 3,2 GHz et une RAM (Random Access

Memory) de 2 Go. Notre but est d’évaluer les performances de la négociation SLNP, indépendamment

des caractéristiques spécifiques d’acheminement (RTT : Round Trip Time) à travers les différents

domaines. Les délais supplémentaires engendrés par la traversée de ces domaines peuvent être ajoutés aux

délais de la procédure de négociation de notre protocole.

Afin de tester les performances du protocole SLNP, nous avons voulu évaluer le temps passé par les

trois entités de la plateforme pour réaliser une négociation. Dans un premier moment, nous évaluons ce

temps pour une négociation de QoS. Tandis que, dans un second moment, nous mesurons ce temps dans

le cas d’une négociation de QoS et de sécurité. Pour cela, nous avons identifié dix niveaux de QoS

116

différents ainsi que cinq niveaux de sécurité répondant à divers besoins. Ainsi le nombre de demandes

possibles que peut effectuer une SI est égal à 10 lorsqu’il s’agit d’une négociation de QoS, alors que ce

nombre s’élève à 50 en cas de négociation conjointe de QoS et de sécurité. En ce qui concerne la SF et de

la SR, nous avons pris soin de les configurer (QoS offerte et sécurité supportée) d’une manière permettant

de conclure à un accord assez souvent.

Type de

négociation

Nombre total de

scénarios

Nombre

d’accords

Nombre moyen

de passes

Temps moyen de

négociation

QoS 10 8 1,7 114,13

QoS + sécurité 50 22 4,48 307,50

Tableau 4-2 : Probabilité de succès et nombre moyen de passes de négociation

La réalisation de ces tests (Tableau 4-2) nous a permis de conclure qu’il est effectivement plus

difficile de conclure un accord sur un niveau de service couvrant à la fois la QoS et la sécurité que de

s’entendre sur un niveau de service ne comprenant que la QoS. En effet, la négociation de la QoS à

conduit à une entente 8 fois sur 10 (% succès = 80 %), alors que la négociation simultanée de QoS et de

sécurité n’a aboutit à un accord que 22 fois sur 50 (% succès = 44 %). Ceci est du au fait qu’il est souvent

très dur de trouver un compromis entre la sécurité et la QoS lors d’une négociation de niveau de service.

En fait, quand la négociation porte uniquement sur la QoS, un accord est trouvé à la suite de la première

ou la deuxième passe de négociation, ou au pire des cas à la suite de la troisième passe (1 cas sur 8). Tandis

que, dans le cas d’une négociation conjointe de QoS et de sécurité, un accord est trouvé, au mieux, lors de

la quatrième passe, et parfois une dizaine de passes de négociation ne permette pas d’arriver à un accord.

Par conséquent, le nombre moyen de passes de négociation pour une négociation conjointe (4,48) est

supérieur à celui calculé pour une négociation de QoS (1,7). Ainsi, le temps moyen de négociation qui est,

généralement, proportionnel au nombre de passes de négociation suit la même logique (Tableau 4-2);

c’est-à-dire qu’il est plus important lorsqu’il s’agit d’une négociation conjointe (307,50 ms) que dans le cas

d’une négociation de QoS (114,13 ms).

Ces mesures permettent de tirer des conclusions importantes en termes de probabilité de succès et en

termes de temps moyen nécessaire à l’établissement d’un accord. Cependant, elles ne permettent pas

d’évaluer le coût ajouté par les traitements nécessaires à la négociation de la sécurité.

Afin d’évaluer le coût de l’introduction des aspects liés à la sécurité dans la négociation de niveau de

service permise par SLNP, nous allons mesurer le temps d’une négociation conjointe pour une seule

passe, afin de le comparer au temps nécessaire à une passe de négociation de QoS (Tableau 4-3). Il faut

préciser que le temps de négociation mesuré pour une seule passe correspond à la durée entre l’instant où

l’application cliente de négociation de la SI commence la construction d’un message de type Negotiate et

l’instant où un message de type Response est reçu par cette entité. Comme dans [MBA 07a], le temps

moyen de négociation est calculé sur la base d’un échantillon de 1000 mesures. Cependant, sur la Figure

4-28, nous ne représentons qu’un échantillon de 100 mesures afin de mieux visualiser le résultat des

mesures que nous avons réalisées.

Notons que les pics périodiques observables sur les courbes des mesures du temps de négociation

(Figure 4-28) s’expliquent par la gestion de la mémoire au niveau de la machine virtuelle Java (le garbage

collector). Ces pics n’ont quasiment pas d’influence sur le temps moyen de négociation, parce qu’ils ne

117

sont pas très fréquents. En effet, les pics que connaissent les mesures du temps de négociation ne

représentent que 6,4 % de la totalité des mesures.

Figure 4-28 : Temps de négociation en fonction du type de négociation (100 essais)

Dans ces conditions, nous obtenons un temps moyen de 60,08 ms pour une passe d’une négociation

de QoS (courbe en rouge sur la Figure 4-28). Ce temps est inférieur à celui que nous avons mesuré

auparavant dans les mêmes conditions [MBA 07a], car l’ancienne implémentation SLNP à été optimisée

en factorisant le code et en supprimant les traitements redondants, et surtout en limitant le nombre

d’interactions avec les bases de données. Cependant, dans le cas d’une négociation portant simultanément

sur la QoS et la sécurité, nous obtenons un temps moyen de 62,61 pour une passe unique (courbe en bleu

sur la Figure 4-28). Ces mesures (Tableau 4-3) nous permettent de conclure qu’en introduisant des aspects

de sécurité dans la négociation SLNP, le temps moyen d’une passe de négociation augmente très

légèrement (4,21 %). Ceci peut s’expliquer par le fait que les traitements de négociation représentent,

généralement, une faible proportion du temps de négociation. Ceci est dû à la lenteur des interactions

entre les services web. Autrement dit, une grande partie de la durée d’une passe de négociation correspond

au temps d’invocation des services web de la SF et de la SR.

Type de négociation Temps moyen de négociation

QoS 60,08 ms

QoS + sécurité 62,61 ms

Tableau 4-3 : Temps moyen de négociation en fonction du type de négociation

Nous avons également procédé à une série de mesures tentant de comparer l’évolution du temps

d’une négociation conjointe en fonction du nombre de passes et en fonction du nombre d’entités

impliquées, avec celle du temps d’une négociation de QoS en fonction de ces mêmes paramètres [MBA

07b]. Les résultats obtenus montrent que ce temps reste toujours proportionnel au nombre de passes, et

au nombre total d’entités de négociation, avec un facteur très légèrement diffèrent. A titre d’exemple, le

118

temps de négociation est proportionnel au nombre d’entités de négociation avec un facteur de 33,8 ms

pour une négociation conjointe, contre un facteur de 31,5 ms pour une négociation de QoS.

Notons qu’il faut absolument désactiver la redirection des messages vers l’application SOAP Monitor

afin de ne pas fausser les mesures du temps de négociation.

4.4.5.4 Evaluation de la taille des messages

Les tests permettant d’évaluer la taille des messages ont été réalisés sur la même plateforme que nous

avons utilisée pour mesurer le temps moyen de négociation (cf. section 4.4.5.1). Afin de mesurer la taille

des messages échangés entre les différentes entités de négociation de la plateforme, nous avons fait appel à

l’outil SOAP Monitor d’Apache qui nous a permis de capturer et stocker ces messages afin de pouvoir,

ensuite, mesurer leurs tailles. Etant donné que tous les types des messages SLNP ont quasiment la même

structure, la taille de ces messages va dépendre essentiellement des paramètres sur lesquels porte la

négociation. Ainsi, nous avons procédé à la mesure de la taille moyenne d’un message de type Negotiate

pour deux types de négociation : la négociation de la QoS uniquement et la négociation conjointe de la

QoS et de la sécurité. Ainsi, pour ces deux types de négociation, nous avons configuré une trentaine de

SLS ayant des compositions différentes où chacune de ces compositions peut correspondre à des besoins

particuliers dans une situation de négociation réelle.

Les résultats des mesures effectuées montrent que la taille moyenne d’un message Negotiate

augmente en introduisant des paramètres de sécurité dans le SLS sur lequel porte la négociation (Figure

4-29). En effet, cette taille passe de 3749 octets à 4894 octets, ce qui représente une augmentation

d’environ un tiers de la taille initiale du message Negotiate (30,54 %). Cette augmentation considérable,

bien évidemment, est due à l’ajout des éléments XML correspondant aux paramètres de sécurité.

Figure 4-29 : Taille moyenne du message Negotiate

4.4.6 Résumé

Dans la section 4.4, nous avons décrit les différentes étapes ayant permis d’intégrer la sécurité dans la

négociation que permettait de réaliser le protocole SLNP. Ces travaux ont été effectués afin de permettre

une négociation conjointe de la QoS et de la sécurité afin de tenir compte de l’impact des mécanismes de

sécurité sur la QoS. Cependant, la considération de cet impact lors d’une négociation nécessite que chaque

entité de négociation dispose d’une estimation de l’influence des mécanismes de sécurité sur les

119

paramètres de QoS. Ainsi, nous étudions, dans la section suivante, cette influence en présentant quelques

travaux qui traitent de cet impact ainsi que nos propres travaux.

4.5 Etude de l’impact de la sécurité sur la QoS

Lorsqu’on sécurise une transmission de données, on introduit un surcoût protocolaire et on ajoute un

certain nombre de traitements [IVR 01]. Le surcoût protocolaire est essentiellement lié aux informations

nécessaires aux mécanismes de sécurité et qui sont ajoutées aux paquets de données, tels que les codes

MAC (Message Authentication Code), les signatures, les certificats, etc. L’introduction de cette sécurité

nécessite, également, un certains temps pour effectuer des traitements supplémentaires liés, cette fois, aux

opérations cryptographiques, telles que les chiffrements, les déchiffrements, les calculs des codes MAC,

etc. Ces opérations sont gourmandes en ressources ; elles consomment de la mémoire, du temps CPU et

de la bande passante. Ainsi, une transmission de données sécurisée peut nécessiter plus de temps et plus

de bande passante qu’une transmission non sécurisée.

Cet impact peut être plus ou moins important selon le(s) mécanisme(s) de sécurité mis en place. A

titre d’exemple, l’utilisation du mécanisme ESP (IPSec), afin d’offrir l’intégrité et la confidentialité, n’a pas

le même impact que l’utilisation du mécanisme AH (IPSec) pour l’intégrité et ESP pour la confidentialité.

En effet, la deuxième configuration permet d’avoir une protection plus robuste en terme d’intégrité ; car la

protection de l’intégrité d’un paquet IP couvre plus de champs lorsqu’on utilise le mécanisme AH que

lorsqu’on utilise le mécanisme ESP. De plus, on peut avoir, parfois, un empilement de deux ou même

trois protocoles de sécurité agissant à différents niveaux de la pile protocolaire TCP/IP. Par exemple, les

données applicatives d’une session sécurisée avec HTTPS peuvent être chiffrées à plusieurs niveaux avec

SSL/TLS, IPSec et WEP [BOR 05]. Ce triple chiffrement peut introduire des surcoûts considérables en

termes de temps de traitement. Par ailleurs, il existe d’autres solutions de sécurité, comme celle proposée

dans [HSC 04] qui peut être très coûteuse, surtout en termes de bande passante. Cette solution, appelée

« ssltunnel », propose de créer une liaison PPP (Point-to-Point Protocol) au dessus d’une connexion de

type SSL/TLS. La liaison PPP (niveau « Liaison ») peut être utilisée avec n’importe quel protocole de

niveau « Réseau », tel que IP, et donc de niveau « Transport » comme UDP, TCP, RTP, etc. Cette solution

permet de créer des tunnels en dessous de SSL/TLS, mais elle nécessite une encapsulation lourde,

complexe et surtout très coûteuse (ex. UDP sur IP encapsulé dans PPP sur SSL/TLS sur TCP sur IP…).

Nous avons déjà vu, dans la section 4.4.3, que l’impact de la sécurité sur la QoS peut avoir des

conséquences importantes sur l’obtention d’un accord et donc sur l’offre de niveau de service comportant

des garanties de QoS et des services de sécurité. D’où l’importance de cet impact qui doit être pris en

compte lors d’une telle offre. Ainsi, nous avons proposé de négocier conjointement la QoS et la sécurité

de bout en bout tout en considérant l’influence des services de sécurité sur les performances de la QoS.

Or cette influence peut dépendre de plusieurs facteurs. Tout d’abord, elle dépend de la couche au niveau

de laquelle la sécurité est introduite. Elle dépend, également, du nombre de services de sécurité offerts et

des niveaux de chacun de ces services, c’est-à-dire l’algorithme mis en jeu pour assurer un service de

sécurité. L’impact de la sécurité sur les paramètres de QoS peut, également, dépendre des performances

de la machine concernée par les traitements de sécurité, tels que la mémoire, le CPU, la charge CPU, etc.

Cela peut dépendre également du nombre de protocoles de sécurité mis en œuvre dans la sécurisation

d’une transmission.

120

Afin de pouvoir prendre en compte cet impact lors d’une négociation conjointe de QoS et de

sécurité, nous devons disposer d’une estimation de cet impact qui va surement dépendre de la situation et

des conditions de la négociation. Cette estimation va, non seulement permettre de négocier correctement

ces deux aspects (QoS et sécurité), mais aussi aider les entités concernées par la négociation dans le choix

des paramètres de sécurité. Par exemple, en cas de protection de la confidentialité des données transmises,

on peut avoir à choisir entre deux algorithmes ayant des performances différentes. Si en termes de temps

de chiffrement, il n’y a quasiment aucune différence, alors on peut privilégier l’utilisation de l’algorithme le

plus robuste. Dans le cas où le temps de chiffrement requis par l’algorithme le plus robuste est plus

important, on peut choisir de demander l’utilisation de l’autre algorithme afin de donner plus de chance à

l’aboutissement de la négociation.

L’évaluation de l’impact de la sécurité sur la QoS a fait l’objet d’un certain nombre de travaux. Ainsi,

dans cette partie, nous décrivons ces travaux afin d’avoir une idée sur la manière avec laquelle la

problématique de l’impact a été traitée. Ensuite, nous proposons de faire nos propres mesures afin d’avoir,

également des estimations de l’impact qui se basent sur des mesures réelles.

4.5.1 Travaux portant sur l’impact de la sécurité sur la QoS

4.5.1.1 Impact du protocole IPSec sur la QoS

Les travaux décrits dans [WEI 07] visent à souligner l’importance de la dégradation de la

performance du réseau lorsque des mesures de sécurité sont prises, et ainsi la réelle difficulté à assurer

conjointement une qualité de service pour des applications de type temps réel. Lors de ces travaux, les

performances du protocole IPSec ont été évaluées et comparées avec celles du protocole IPv4 [POS 81].

Figure 4-30 : Comparaison du délai de bout en bout entre IPv4 et IPSec [VAN 05]

Pour cela, les trafics pouvant circuler sur les réseaux IP ont été classés en deux types : auto-similaire

et non auto-similaire. Ensuite, la dégradation provoquée par IPSec a été étudié suivant le type de trafic.

Pour les trafics non auto-similaires tels que la vidéo CBR (Constant Bit Rate) et la voix, les auteurs

ont comparé la performance du protocole IPSec avec celle du protocole classique IPv4 (sans sécurité). En

effectuant une simulation NS2 (Network Simulator version 2) [FAL 00], ils ont pu établir une

comparaison en termes de délai de bout en bout entre le protocole IPsec et le protocole IPv4 (Figure

121

4-30). Cette comparaison a été effectuée pour des vidéos de basse qualité (64 kb/s), de moyenne qualité

(384 kb/s) et de haute qualité (1536 kb/s).

Ces travaux ont permis de constater que le délai de bout en bout augmente d’au moins un tiers avec

IPSec (par rapport à IPv4), alors qu’en termes de perte de paquets on ne note quasiment pas de différence

(la perte des paquets reste toujours négligeable).

Pour les trafics auto-similaires tels que le Web et la vidéo VBR (Variable Bit Rate), les auteurs ont

constaté que le délai de bout en bout croit considérablement avec le protocole IPSec, et que la perte des

paquets est cette fois considérable lorsqu’IPSec est utilisé.

4.5.1.2 Surcoût des services de sécurité

Dans cette section, nous décrivons les résultats d’un ensemble de travaux réalisés au CISSSR (Center

for Information Systems Security Studies and Research). Ces travaux [SYP 00]-[IVR 01] avaient pour

objectif d’étudier l’impact de la sécurité sur la consommation de certaines ressources, à savoir le CPU, la

mémoire et la bande passante. Pour chacune de ces ressources, deux types de coûts ont été distingués : le

coût d’initialisation et le coût de transmission. Afin de présenter ces résultats, nous fournissons dans le

Tableau 4-4 une qualification de l’impact des services de sécurité sur ces ressources pendant les deux

phases qui ont été distinguées : initialisation et transmission. Nous avons réalisé ce tableau en nous basant

sur les travaux décrits dans [DUF 07].

Services de sécurité CPU Mémoire Bande passante

Confidentialité Initialisation : +++

Transmission : +++

Initialisation : +++

Transmission : +++

Initialisation :

Transmission : +[++]

Authentification, intégrité et

non-répudiation

Initialisation : ++

Transmission : ++

Initialisation : ++

Transmission : ++

Initialisation :

Transmission : ++

Protection contre le rejeu Initialisation : +

Transmission : +

Initialisation : +

Transmission : +

Initialisation :

Transmission : +

Création de tunnel Initialisation :

Transmission : +

Initialisation :

Transmission : +

Initialisation :

Transmission : ++

Tableau 4-4 : Qualification de la consommation des ressources

La confidentialité a un impact très important sur le CPU et la mémoire durant la phase d’initialisation

où les tables spécifiques et le vecteur d’initialisation sont préparés, mais aussi durant la phase de

transmission où les données sont chiffrées et déchiffrées. Concernant la bande passante, elle est

consommée pendant la phase de transmission afin d’envoyer le vecteur d’initialisation mais parfois un

padding d’une taille importante peut être, également, ajouté lorsque IPSec est utilisé (jusqu’à 255 octets).

Nous avons déjà précisé que l’authentification, l’intégrité et la non-répudiation sont des services

inséparables qui sont, généralement, assurés grâce à un algorithme d’authentification associé à une

fonction de hachage. Ces services ont un impact considérable sur le CPU et la mémoire durant les deux

phases de la communication. La bande passante est, également, consommée lors de l’envoi des données

d’authentification.

La protection contre le rejeu est le service qui consomme le moins de ressources. En effet, il a une

légère influence sur le CPU et la mémoire durant la phase d’initialisation, afin d’initialiser le numéro de

122

séquence et, également, durant la phase de transmission afin d’incrémenter et de vérifier ce numéro.

L’envoi de ce numéro consomme, aussi, un peu de bande passante durant la phase de transmission.

La création de tunnel, permis par IPSec, requiert un peu de mémoire et de temps CPU afin de

générer les nouveaux entêtes pendant la phase de transmission. L’ajout de ces nouveaux entêtes à, par

contre, un impact considérable sur la consommation de la bande passante pendant cette phase de

transmission.

Dans [DUF 07], les auteurs ont essayé d’évaluer l’impact d’une sécurité IPSec sur la bande passante

dans le cas d’un trafic UDP. Les résultats des tests effectués sont résumés dans le Tableau 4-5. Sur ce

tableau, le coût de la sécurité IPSec en terme de bande passante durant la phase d’initialisation est exprimé

en octets car il représente les données échangées afin de négocier les paramètres de sécurité, générer les

clés, etc. Par contre, durant la phase de transmission, ce coût est exprimé en octets par paquet afin de

montrer l’importance des données ajoutées à un paquet par les processus de sécurité.

Protocole Bande passante (octets)

Phase d’initialisation

Bande passante (octets/paquet)

Phase de transmission

UDP/IP Non pertinent 1358

AH Authentification et intégrité 1688 1382

ESP

Authentification et intégrité 1712 1382

Confidentialité 1712 1378

Confidentialité, authentification et intégrité

1712 1390

Tableau 4-5 : Impact d’IPSec sur la bande passante (trafic UDP) [DUF 07]

Le Tableau 4-5 montre que la consommation de la bande passante augmente lorsque la sécurité est

introduite. A partir de ce tableau, nous pouvons remarquer que la bande passante consommée durant la

phase d’initialisation ne dépend que du mécanisme IPSec mis en place ; Le mécanisme ESP consomme

1712 octets de bande passante contre 1688 octets consommées par le mécanisme AH. Nous pouvons,

également, noter que la bande passante consommée durant la phase de transfert varie en fonction des

services de sécurité sélectionnés et ceci indépendamment du mécanisme de sécurité mis en place. En effet,

la confidentialité seule (1378 – 1358 = 20 octets/paquet) consomme moins de bande passante que

l’authentification et l’intégrité (1382 – 1358 = 24 octets/paquet). En revanche, l’impact le plus important a

lieu lorsque ces deux types de services (confidentialité avec authentification et intégrité) sont associés l’un

à l’autre (1390 – 1358 = 32 octets/paquet).

Cependant, si nous voulons évaluer l’impact de la sécurité sur des flux correspondants à différents

types d’application, alors le surcoût en termes de bande passante devrait être plutôt évalué en pourcentage

car l’ajout de trente octets à un paquet de vidéo dont la taille maximale est de 1490 octets (entre 50 et 1450

octets de données utiles et 40 octets d’entête RTP/UDP/IP) n’a pas la même incidence que l’ajout de ce

même nombre d’octets (30) à un paquet de voix qui a une taille maximale de 190 octets (entre 20 et 150

octets de données utiles plus 40 octets d’entête RTP/UDP/IP) [CIS 06]

4.5.1.3 Impact des traitements de sécurité

Les traitements de sécurité nécessitent des ressources comme l’espace mémoire et le temps CPU.

C’est le temps mis par une machine afin de réaliser les traitements requis par un niveau de sécurité qui

123

correspond au délai supplémentaire devant être pris en compte lors d’une négociation conjointe de QoS et

de sécurité. Nous avons déjà souligné que le temps requis par des traitements de sécurité devrait dépendre

des performances de la machine qui doit réaliser ces traitements. Dans cette section, nous présentons les

résultats de quelques travaux qui montrent que la capacité des traitements (relatifs à la sécurité) varie en

fonction des performances des machines.

Dans les travaux considérés [KON 03], les auteurs ont utilisé des machines dont le CPU varie du

Pentium II 450 MHz jusqu’au Pentium IV 1.8 GHz. La plus lente de ces machines est dotée d’un CPU

Pentium II cadencé à 450 MHz avec 512 Ko de cache L2. La machine la plus rapide utilise un CPU

Pentium IV 1,8 GHz avec 256 Ko de cache L2, et l’autre machine (performances moyennes) utilise un

processeur Pentium III 850 Mhz avec 256 Ko de cache L2. Le Tableau 4-6 montre les performances de

ces différentes machines en termes de traitements cryptographiques.

System

configuration

AES finalists (block size = key size: 1st row 128-bit, 2nd row

256-bit) encryption/decryption throughput (Mbit/sec)

RSA public key algorithm

signing/verification delay (sec)

Pentium II

450 MHZ

61.5/68.8

99.2/103.2

100.0/91.4

200.0/185.5

133.3/156.1

266.7/312.2

22.4/25.1

45.6/51.4

125.5/123.1

261.2/241.5

0.27/0.01 0.53/0.01 0.86/0.01

Pentium III

850 MHZ

139.1/136.2

200.0/196.9

76.2/71.9

156.1/142.2

95.5/142.2

188.2/284.4

41.8/48.1

83.7/96.2

188.2/182.9

376.5/365.7

0.15/0.01 0.29/0.01 0.46/0.01

Pentium IV

1.8 GHZ

278.3/193.9

387.9/297.7

130.6/106.7

246.2/224.6

160.0/213.3

312.2/426.7

47.4/53.3

94.1/105.8

278.3/304.8

533.3/533.3

0.08/0.01 0.15/0.01 0.24/0.01

Tableau 4-6 : Performances en termes de traitements cryptographiques [KON 03]

Ces traitements concernent le chiffrement symétrique basé sur l’algorithme AES et l’authentification

basée sur l’algorithme RSA. Pour le chiffrement AES, plusieurs types d’algorithmes AES ont été testés

(AES/Rjindael, AES/Mars, AES/RC6, etc.). Pour chacun de ces types, les mesures de performances ont

porté sur l’opération de chiffrement et également sur celle de déchiffrement parce que souvent le temps

nécessaire au chiffrement est différent de celui requis par le déchiffrement. A partir du Tableau 4-6, nous

pouvons noter que, dans le cas où la taille de la clé ainsi que celle d’un bloc sont égales à 128 bits, le

chiffrement avec AES/Rijndael peut atteindre une capacité de traitement ≥ 61,5 Mb/s sur la machine la

plus lente et ≥ 193,9 Mb/s sur la machine la plus rapide. Ce même tableau inclut des mesures de

performances pour le cas d’une clé et d’une taille de bloc toutes les deux égales à 256 bits. Dans ce cas, la

performance de AES/Rijndael augmente pour atteindre une capacité ≥ 99,2 Mb/s sur la machine la plus

lente, et ≥ 297,7 Mb/s sur la plus rapide. Notons que ces mesures montrent que tous les types de

chiffrement AES testés, y compris la norme Rijndael, offrent un débit satisfaisant pour les points d’accès

802.11 : 11 Mb/s (802.11b) ou 54 Mb/s (802.11a et 802.11g). Le Tableau 4-6 montre, également, un

système de cryptographie à clé publique, à savoir RSA, qui peut effectuer de manière efficace

l’authentification et l’échange de clé en moins d’une seconde.

Synthèse : Les travaux que nous avons décrits ci-dessus, montrent que l’impact de la sécurité sur la

QoS dépend de plusieurs facteurs comme le ou les protocoles utilisés, les services de sécurité sélectionnés,

les algorithmes utilisés pour fournir ces services, mais aussi les performances de la machine qui réalise les

traitements de sécurité. Afin de pouvoir prendre en compte l’impact de la sécurité sur la QoS dans la

négociation de SLNP, cet impact doit être traduit en termes de paramètres de QoS négociés, à savoir le

délai, la gigue, le taux de perte et la bande passante. Cet impact doit être, également, évalué en fonction des

124

protocoles et algorithmes de sécurité que considère la négociation assurée par SLNP. Ainsi, dans la section

suivante, nous allons réaliser nos propres mesures de l’impact des types de sécurité considérés par SLNP

sur les paramètres de QoS négociés par ce protocole. Nous essayons, également, de considérer différents

types de trafic, à savoir TCP et UDP.

4.5.2 Tests réalisés


Les tests qui ont permis d’obtenir une estimation de l’impact de la sécurité sur la QoS, ont été

effectués sur une plateforme composée de deux machines ayant les mêmes performances ; il s’agit de deux

machines IBM dotées chacune d’un CPU Pentium IV cadencé à 2.4 GHz et d’une mémoire RAM d’une

capacité de 256 Mb. Chacune de ces deux machines fonctionne sous un système d’exploitation (OS :

Operating System) de type Linux [LIN 09].

Les tests consistent à créer des communications sécurisées entre les deux machines de la plateforme à

travers le réseau filaire qui les lie entre elles (Figure 4-31). Etant donné que les protocoles de sécurité

concernés par ces tests sont les protocoles IPSec, TLS et DTLS, nous avons dû mettre en place ces

protocoles sur les machines composant notre plateforme de tests. Pour le protocole IPSec, nous avons

opté pour l’implémentation Openswan, alors qu’en ce qui concerne le protocole TLS/DTLS, nous avons

choisi l’implémentation OpenSSL.

Figure 4-31 : Plateforme de tests de l'impact de la sécurité sur la QoS

4.5.2.1.1 Implémentation Openswan de IPSec

Le protocole IPSec peut être implémenté essentiellement à deux niveaux différents : le terminal ou le

routeur. Cette implémentation peut être intégrée dans le système d’exploitation du terminal où elle agit au

niveau de la couche « Réseau » (Cas des OS : Red Hat Entreprise Linux et Windows Server 2003).

L’implémentation de IPSec peut être, également, introduite entre la couche « Réseau » et la couche

« Liaison de données » afin d’exploiter des fonctionnalités offertes par l’OS, ce qui est le cas de

l’implémentation Openswan [OSW 09]. Au niveau du routeur, une implémentation IPSec peut être

intégrée dans le software du routeur (cas des routeurs Cisco [CIS 09] par exemple), ou située sur un

terminal connecté sur l’interface physique du routeur.

Pour la réalisation de nos tests, nous avons choisi l’implémentation Openswan. Il s’agit de la première

implémentation IPSec pour l’OS Linux. De plus, cette implémentation est basée sur un code open source

125

très stable, et offre toutes les fonctionnalités nécessaires à la création des VPNs (Virtual Private Network)

pour Linux.

4.5.2.1.2 Implémentation OpenVPN de TLS-DTLS

OpenSSL [OSS 09] est une implémentation open source des protocoles SSL et TLS. Cette

implémentation supporte le protocole DTLS depuis la version 0.9.8. Les librairies sur lesquelles se fonde

cette implémentation peuvent être utilisées par d’autres implémentations comme OpenVPN [OVP 09].

Afin de tester l’impact des protocoles TLS et DTLS sur les paramètres de QoS, nous avons choisi

d’utiliser l’implémentation OpenVPN qui est, également, une implémentation open source et qui

nécessite, également, l’installation de OpenSSL. Cette implémentation offre plusieurs fonctionnalités qui

permettent de réaliser les différentes opérations cryptographiques nécessaires à l’établissement des

communications sécurisées entre un client et un serveur, tel que la création et l’envoi de certificats pour

l’authentification, la signature, le chiffrement, etc.

Après avoir préparé la plateforme de tests et mis en place les implémentations des différents

protocoles de sécurité à tester, nous avons dû choisir les outils qui nous permettent de mesurer les

paramètres de QoS considérés (delai, gigue, taux de perte et bande passante). Les outils auqels nous avons

fait appel pour mesurer l’impact de la sécurité sur la QoS sont décrits dans l’annexe 0. Suivant, le

paramètre sur lequel portent les mesures et en fonction du type de trafic pour lequel ces mesures sont

effectuées (TCP ou UDP, non sécurisé ou sécurisé), nous choisissons d’utiliser tel ou tel outil parmi ceux

présentés ci-dessus.

4.5.2.2 Résultats des tests

En utilisant les différents outils de mesures disponibles, nous avons procédé à un ensemble de tests

ayant pour objectif d’évaluer l’impact des sécurités IPSec et TLS-DTLS sur les différents paramètres de

QoS pour les deux types de transport, à savoir TCP et UDP.

Ils existent plusieurs facteurs qui peuvent causer la dégradation des paramètres de QoS d’une

transmission. Parmi ces facteurs, nous citons la surcharge du réseau et le taux d’utilisation du CPU qui

peuvent avoir, parfois, une influence plus importante que celle des mécanismes de sécurité sur les

performances de la QoS. C’est pourquoi, nous avons essayé de contrôler d’une manière optimale les

conditions expérimentales en permettant seulement l’exécution des applications chargées de la

transmission des données sur les deux systèmes formant notre plateforme de tests. En outre, le réseau

filaire reliant ces deux systèmes a été sur-approvisionné (la bande passante du réseau est plus grande que le

débit des transmissions testées) et il n’y a aucun autre flux circulant sur ce réseau.

Dans la première série de mesures que nous avons effectuées, nous avons essayé d’évaluer l’impact

de la sécurité sur la QoS en fonction de l’algorithme utilisé. Les résultats obtenus ont permis de conclure

que le choix de l’algorithme à utiliser dans l’offre d’un service de sécurité (intégrité ou confidentialité) n’a

quasiment pas d’influence sur les mesures de l’impact.

Compte tenu de ce premier résultat, l’impact de la sécurité sur la QoS ne va dépendre que des

services de sécurité fournis et du protocole utilisé. Ainsi, nous allons procéder à deux types de tests. Le

premier type concerne un trafic UDP et utilise essentiellement les outils Sjitter et Iperf afin d’évaluer et

comparer le délai, la gigue, la bande passante et le taux de perte pour plusieurs politiques de sécurité. Le

126

deuxième type de tests va, quant à lui, porter sur les paramètres caractérisant un trafic TCP, à savoir le

délai et la bande passante, en utilisant les outils Hping et Iperf, toujours pour les mêmes politiques de

sécurité.

Notons qu’à chaque fois que nous configurons un certain niveau de sécurité, nous utilisons l’outil

Wireshark afin de visualiser les données transmises et ainsi vérifier le bon fonctionnement de cette

sécurité. Cependant, lorsque les mesures sont réalisées, cette application (Wireshark) doit être arrêtée parce

qu’elle consomme les ressources de la machine, à savoir la mémoire et le CPU, et pourra donc fausser les

résultats de nos tests.

Pour chaque type de trafic (TCP et UDP), nous mesurons les paramètres de QoS en fonction d’un

certain nombre de politiques de sécurité parmi celles contenues dans le Tableau 4-7. En effet, ce sont les

politiques P0, P1, P2, P3 et P5 qui sont appliquées pour les tests correspondant au trafic UDP, alors que

les politiques P0, P1, P2, P4 et P6 concernent les tests correspondant au trafic TCP.

Politique Caractéristiques

P0 Sans sécurité

P1 IPSec, AH, Intégrité=hmac-sha1-96

P2 IPSec, ESP, Intégrité=hmac-sha1-96, Confidentialité=aes-cbc

P3 DTLS, Intégrité=sha1, Confidentialité=aes

P4 TLS, Intégrité=sha1, Confidentialité=aes

P5 P2 + P3

P6 P2 + P4

Tableau 4-7 : Politiques de sécurité

La Figure 4-32 montre l’impact des services de sécurité sur les mesures du délai, de la gigue et de la

bande passante que nous avons effectuées. On remarque, clairement, que les services de sécurité (intégrité

et confidentialité), offerts grâce à l’utilisation du protocole IPSec et à celle du protocole DTLS,

augmentent le délai de transmission UDP ainsi que la gigue et nécessitent plus de bande passante pour

envoyer la même quantité de données. Nous remarquons, également, que l’impact de la confidentialité

associée à l’intégrité (P2) est toujours plus conséquent que celui de l’intégrité toute seule (P1).

Il faut, également, noter que l’influence de DTLS est très semblable à celle d’IPSec lorsque les

niveaux de sécurité sont comparables (P2 et P3), et que l’impact le plus important est obtenu lorsque les

deux types de sécurité, à savoir IPSec et DTLS, sont empilés pour une même transmission de données.

Dans ce cas, l’impact mesuré sur les paramètres délai, gigue et bande passante est quasiment égal à la

somme des impacts des deux sécurités (IPSec et DTLS) appliquées indépendamment.

En ce qui concerne les mesures du taux de perte, nous avons obtenu un taux de perte toujours égal à

zéro. Ceci est dû à la nature du réseau utilisé sur notre plateforme de tests. Comme nous l’avons déjà

précisé, notre plateforme est composée de deux machines directement reliées entre elles par un câble

réseau avec une capacité largement supérieure à la taille des données générées par les outils de mesures

que nous utilisons.

127

a : Impact sur le délai b : Impact sur la gigue

c : Impact sur la bande passante

Figure 4-32 : Impact de la sécurité sur la QoS pour un trafic UDP

Les paramètres de qualité de service que nous pouvons mesurer pour le trafic de type TCP sont le

délai et la bande passante. En effet, les travaux présentés dans [ZHA 96] ont démontré que, pour la

majorité des applications existantes, l’étude de la bande passante et l’un des trois autres paramètres (délai,

gigue et taux de perte) est suffisante. Ces travaux ont également montré que le délai est plus important que

la gigue et le taux de perte. Par ailleurs, l’étude de taux de perte pour un protocole de transport fiable

comme TCP n’a aucun sens parce que ce protocole assure par lui-même la retransmission des paquets

perdus. Ainsi, nous allons mesurer l’impact de la sécurité sur le délai et la bande passante.

Pour un trafic TCP, la Figure 4-33 montre que l’introduction des mécanismes de sécurité a presque le

même effet sur les paramètres délai et bande passante que celui que nous avons constaté avec le flux UDP.

En effet, le délai connait une augmentation importante lorsque l’intégrité est ajoutée grâce à IPSec (il passe

de 0,34 à 0,62). Ce délai atteint sa plus grande valeur lorsque le flux TCP est sécurisé à la fois au niveau IP

et au niveau « Transport » (0,93). La bande passante, elle aussi, augmente avec l’ajout du mécanisme AH

d’IPSec pour offrir l’intégrité des données. Cette augmentation est due à l’ajout du code MAC aux entêtes

des paquets IP. Nous pouvons, également, noter que la bande passante consommée lors de l’ajout de TLS

et IPSec est supérieure à celle requise lors de l’utilisation d’IPSec ou TLS.

Les mesures qui concernent la bande passante pour les deux types de trafic ont été effectuées en

utilisant l’outil Iperf qui calcule le débit d’envoi de données du niveau applicatif en envoyant une certaine

quantité de données applicatives avec une taille maximale fixe au niveau réseau. Ainsi, le débit donné par

cet outil est un débit qui baisse en ajoutant des mécanismes de sécurité. Nous avons donc du faire les

calculs nécessaires afin d’exprimer l’impact de la sécurité en termes de bande passante nécessaire pour une

même taille de données applicatives. Notons, également, que chacune des mesures présentées ci-dessus

constitue la moyenne d’une centaine d’essais.

128

a : Impact sur le délai b : Impact sur la bande passante

Figure 4-33 : Impact de la sécurité sur la QoS pour un trafic TCP

Il est vrai que ces mesures donnent une idée sur l’impact des mécanismes de sécurité sur la QoS, mais

ne couvrent pas toutes les possibilités de sécurisation. En effet, nous pouvons avoir une sécurité IPSec

offrant uniquement la confidentialité. Nous pouvons, également, avoir à offrir uniquement la

confidentialité mais a deux niveaux de la couche TCP/IP, etc. De plus, dans la réalité, nous n’avons pas

tout le temps des machines consacrées uniquement aux traitements correspondant à la communication

sécurisée. Ainsi, il y a beaucoup d’autres paramètres à prendre en compte dans l’estimation de l’impact et

notre série de mesures peut être encore étendue et complétée par d’autres mesures.

4.5.3 Résumé

La section 4.5 a été réservée à l’étude de l’impact de la sécurité sur la QoS. Nous avons décrit, tout

d’abord, quelques travaux ayant porté sur cet impact. Ensuite, nous avons présenté les travaux que nous

avons réalisés dans le but d’estimer l’influence des mécanismes de sécurité sur les paramètres de QoS. Ces

estimations ont été réalisées, non seulement, pour vérifier l’existence de cet impact, mais aussi pour

pouvoir prendre en compte cet impact dans une négociation de niveau de service avec SLNP. Ainsi, nous

avons proposé d’ajouter au niveau des RMF des entités de négociation une table qui reprend les résultats

des mesures réalisés. Ceci permet à toute entité participant à une négociation conjointe de QoS et de

sécurité d’obtenir une estimation de l’impact à partir de sa RMF afin de pouvoir négocier correctement le

niveau de service requis pour une communication. En effet, quand une entité SLNP met à jour le

paramètre délai en rajoutant la valeur du délai de transit à travers son réseau, elle doit prendre en compte

les délais produits, suite à d’éventuelles opérations cryptographiques, telles que le calcul de code MAC ou

encore le chiffrement et le déchiffrement.

4.6 Conclusion

Les services transportés sur les réseaux de nouvelle génération peuvent avoir besoin de garanties en

matière de QoS et de sécurité. Nous avons vu, dans le deuxième chapitre, que la sécurité de bout en bout

requise par ces services peut être offerte en mettant en œuvre un ou plusieurs protocoles de sécurité. En

se fondant sur les protocoles de sécurité les plus utilisés (IPSec, TLS et DTLS), nous avons essayé

d’étendre la négociation de la QoS, que permet d’accomplir le protocole SLNP, aux paramètres de

sécurité. Ceci permet de négocier conjointement ces deux aspects. L’intérêt de cette négociation conjointe

est de considérer l’impact de la sécurité sur la QoS.

129

Dans une première partie de ce chapitre, nous avons expliqué les raisons pour lesquelles la sécurité

doit être associée à la QoS dans la négociation de niveau de service. Ensuite, nous avons introduit

quelques travaux ayant porté sur cette association. Ces travaux nous ont aidés dans la définition des

paramètres de sécurité qui seront négociés avec le protocole SLNP. Après avoir défini ces paramètres,

nous avons proposé un nouvel SLS permettant aux différents responsables de domaines de garantir une

offre de service couvrant la QoS et la sécurité. Puis, nous avons modifié le fonctionnement de la

négociation de la QoS afin de permettre de répondre aux besoins de négociation simultanée de la QoS et

de la sécurité. Enfin, les performances de cette nouvelle version ont été mesurées et les résultats de ces

mesures ont été présentés et commentés.

Dans la deuxième partie de ce chapitre, nous avons commencé par présenter quelques travaux ayant

traité de l’impact des services de sécurité sur les performances d’une communication. Ensuite, nous avons

proposé de réaliser nos propres tests dans le but d’estimer l’impact de la sécurité négociée avec SLNP sur

la QoS. Ces mesures pourront, ensuite, être exploitées par les différentes entités de négociation SLNP

dans la prise en compte de l’impact de la sécurité sur la QoS lors d’une négociation conjointe. Pour cela,

nous avons commencé par décrire la plateforme de test utilisée avant de définir les politiques de sécurité

testées et les paramètres de QoS pouvant être mesurés, pour chacun des deux types de trafic testés : TCP

et UDP. Enfin, les résultats de ces tests ont été présentés et commentés.

La négociation du protocole SLNP n’a pas prévu de gérer les aspects de mobilité. Cependant,

aujourd’hui, les utilisateurs mobiles sont de plus en plus nombreux et peuvent accéder aux différents

services offerts par les réseaux de nouvelle génération à tout moment et à partir de n’importe quel endroit.

Ainsi, le protocole SLNP doit, également, s’adapter à ce nouveau contexte. C’est donc l’objectif des

travaux qui seront décrits dans le chapitre suivant.

130

Chapitre 5

Adaptation du protocole SLNP

aux réseaux NGN

5.1 Introduction

Nous avons vu dans le deuxième chapitre que les services transportés sur les réseaux de nouvelle

génération nécessitent des garanties en matière de qualité de service et de sécurité. Cependant,

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 (laptop, PDA, smartphone, etc.). Ainsi, dans cet environnement très

dynamique, l’offre de service qui peut être garantie avec la négociation SLNP (QoS et sécurité) doit

prendre en compte la mobilité des utilisateurs en assurant une négociation plus dynamique. Ceci permettra

de mettre à jour le niveau de service d’une communication à chaque fois que l’utilisateur changera de

réseau d’accès ou de type de terminal, etc.

Ce chapitre est divisé en deux grandes parties. La première partie décrit un service NGN particulier, à

savoir le service IPTV. L’architecture IPTV permet de délivrer le flux IPTV aux différents utilisateurs

mobiles connectés grâce à un réseau sans fil, tout en offrant des garanties en matière de QoS et de

sécurité. En effet, dans le cadre de l’architecture IPTV, nous proposons d’adapter le protocole SLNP afin

de pouvoir assurer l’offre de service au niveau du réseau de cœur. Tandis qu’au niveau du réseau d’accès

une adaptation fondée sur un outil du standard MPEG-21, à savoir l’UED (User Environment

Description), est mis en œuvre. Puisque l’UED, tel qu’il a été défini par la norme MPEG-21, ne prend en

compte que les paramètres du profil relatifs à la QoS, nous avons étendu cette description aux paramètres

de sécurité. Ceci permet ainsi de prendre en compte la sécurité dans l’adaptation des flux IPTV délivrés

aux différents utilisateurs mobiles.

Dans la deuxième partie de ce chapitre nous rappelons l’architecture générale des réseaux NGN

permettant d’offrir aux différents utilisateurs une connectivité ubiquitaire, afin de mieux cerner les défis à

relever. Ensuite, nous tirons profit de l’expérience acquise lors de l’extension du profil UED afin de

proposer une négociation de QoS et de sécurité fondée sur l’utilisation du profil utilisateur. Pour cela,

nous introduisons, auparavant, quelques travaux portant sur les profils utilisateurs qui nous ont aidés dans

la définition d’un profil utilisateur sur lequel se fondera la négociation SLNP. Le fonctionnement de cette

131

négociation dans les environnements NGN est ensuite défini. Pour ce nouveau fonctionnement, nous

proposons de fonder la négociation sur ce profil utilisateur, et de coopérer avec le standard IEEE 802.21

afin d’assurer le handover pour des utilisateurs mobiles et de pouvoir considérer l’impact de cette mobilité

dans le niveau de service négocié. L’adaptation de notre implémentation du protocole SLNP à ce nouveau

fonctionnement est, par la suite, réalisée et de nouveaux tests de performances sont effectués. Enfin, nous

donnons 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.

5.2 Gestion de la QoS et de la sécurité dans une architecture pour les

services IPTV

Dans cette section, nous commençons par décrire l’architecture qui permet de délivrer les services

IPTV pour des utilisateurs mobiles connectés via des réseaux sans fil et utilisant des terminaux

hétérogènes. Cette description va nous permettre d’identifier les problèmes que nous pouvons rencontrer

si nous voulons utiliser le protocole SLNP afin de garantir l’offre de ces services. Ensuite, nous allons

décrire la solution que nous proposons afin de pallier à ces problèmes et pouvoir garantir une QoS et une

sécurité de bout en bout pour les services offerts.

5.2.1 Architecture pour la fourniture des services IPTV

Dans cette partie, nous présentons les services IPTV qui sont offerts dans le cadre de l’architecture

que nous considérons. Ensuite, nous décrivons cette architecture en détaillant le fonctionnement de la

fourniture des services IPTV ainsi que toutes les entités mises en œuvre dans le cadre de cette architecture.

5.2.1.1 Les services IPTV

Actuellement, il n’existe pas une définition unique de l’IPTV, mais l’IPTV FG (Focus Group) de

l’ITU-T l’a défini comme suit [ITU 06] : « l’IPTV est défini comme étant des services multimédia,

télévision/vidéo/audio/texte/graphiques/données, délivrés sur un réseau IP contrôlé afin de fournir le

niveau de QoS/QoE, sécurité, interactivité et fiabilité exigé ». Ainsi, les services IPTV englobent

essentiellement les services de transmission audio/vidéo, live ou préenregistrés, sur des infrastructures

fondées sur IP. Parmi ces services, nous citons la VoD, le LoD et l’IPTV multicast.

• VoD (Video on Demand) : la VoD permet aux utilisateurs de demander la réception de vidéos

préenregistrées et stockées sur des serveurs. Elle est fondée sur une architecture client/serveur où le

client utilise un protocole de contrôle de session (RTSP, SIP, MMS, etc.) afin de demander une vidéo

qui est, ensuite, transmise par un serveur. Le mode de transmission spécifique à la VoD est

principalement l’unicast.

• LoD (Live on Demand) : le LoD permet aux utilisateurs de demander de recevoir des flux vidéo live et

non pas des vidéos préenregistrées. Comme la VoD, le LoD se fonde sur une architecture

client/serveur où le client utilise des protocoles de contrôle de session pour demander la transmission

d’un flux live particulier que le serveur se charge de transmettre en unicast. Ce service est caractérisé

par une mauvaise scalabilité due à la duplication du flux live pour chaque récepteur qui est nécessaire à

l’adaptation et à la personnalisation du flux live en fonction de l’environnement de l’utilisateur.

132

• IPTV multicast : ce service permet la transmission de flux live ou de sessions vidéo préprogrammés en

se fondant sur une transmission en mode multicast sur des réseaux IP. Ceci permet un gain

considérable en bande passante comparé au service LoD.

5.2.1.2 L’architecture IPTV

L’architecture IPTV permet d’interconnecter le réseau DVB-T (Digital Video Brodcast - Terrestrial)

[DVB 09] et les réseaux IP/802.11 [IEE 99a]-[IEE 99b]-[IEE 99c] afin de rendre accessible les services

DVB-T pour les différents utilisateurs connectés via les réseaux Wi-Fi 802.11.

Comme le montre la Figure 5-1, cette architecture est composée de trois segments. D’abord le réseau

de broadcast DVB-T à partir duquel le flux TV numérique est récupéré. Ensuite, le cœur du réseau IP sur

lequel transitent les flux IPTV. Enfin, les réseaux d’accès qui permettent de délivrer les flux IPTV aux

différents utilisateurs mobiles. Dans l’architecture considérée, les réseaux d’accès sont limités aux réseaux

de type IEEE 802.11.

Figure 5-1 : Architecture IPTV [DJA 08]

• Le réseau de diffusion (DVB-T) : Le réseau DVB-T (Digital Vidéo Broadcast – Terrestrial) se base sur le

mode de transmission broadcast afin de permettre la diffusion de la TV numérique, tout en

garantissant une utilisation optimisée des ressources hertziennes, comparé à la diffusion analogique,

grâce à la compression numérique des flux TV. Actuellement, le standard DVB-T (Digital Video

Broadcast - Terrestrial) constitue la technologie la plus déployée pour assurer la diffusion de la TV

numérique et qui, dans quelques années, remplacera définitivement la TV analogique. La DVB-T se

base sur MPEG-2 TS (Transport Stream) pour le transport de l’audio, de la vidéo et des données, et

peut exploiter des canaux de différentes largeurs (5MHz, 6MHz, 7MHz ou 8MHz). Elle peut,

également, utiliser divers techniques de codage et de modulation. Ainsi, le débit offert par le réseau

DVB-T peut varier entre 5 Mbit/s et 32 Mbit/s.

• Le fournisseur de contenu (CP) : le fournisseur de contenu (CP : Content Provider) est l’une des deux

entités clés de cette architecture. Cette entité assure l’interconnexion entre le réseau DVB-T et le cœur

du réseau IP. En effet, le fournisseur de contenu se charge de récupérer des flux DVB-T afin de les

retransmettre dans le cœur du réseau en flux IPTV. Pour cela, les services DVB-T sont transformés

en services IPTV qui seront, par la suite, transmis en multicast. En effet, chaque service est

transformé en une session multimédia transmise dans un groupe multicast (utilisation d’une adresse IP

multicast) et tous les flux composant une session sont transmis sur le même port en utilisant UDP.

133

• Le cœur de réseau (IP) : Le cœur de réseau est un réseau IP pouvant utiliser trois modes de

transmission, à savoir l’unicast, le multicast ou le broadcast. Afin d’assurer la scalabilité, le mode de

transmission multicast est utilisé dans cette architecture. Ceci permet de transmettre les flux IPTV du

fournisseur de contenu vers les passerelles d’adaptation. Ceci évite la duplication des flux transmis à

plusieurs passerelles et préserve, par conséquent, la bande passante disponible dans le cœur du réseau.

Ainsi, chaque flux TV représente un groupe multicast et les passerelles doivent s’abonner aux groupes

pour recevoir les flux TV. Par ailleurs, si aucun des clients d’une passerelle ne demande de recevoir un

flux TV, cette dernière peut se désabonner du groupe afin d’éviter la transmission inutile d’un flux TV

dans le réseau. Ceci permet de préserver les ressources qui peuvent être exploitées par d’autres

services IP. La transmission multicast des flux IPTV est principalement fondée sur deux protocoles :

un protocole de gestion des groupes multicast et un protocole de routage multicast. Dans

l’architecture considérée, la gestion de groupe est assurée par le protocole IGMP (Internet Group

Multicast Protocol) [CAI 02] déployé entre la passerelle et son routeur d’accès et entre le fournisseur

de contenu et son routeur d’accès. Tandis que le routage multicast est assuré grâce au protocole PIM-

SM (Protocol Independent Multicast Sparse-Mode) [PUS 06] déployé entre les routeurs.

• La passerelle d’adaptation (AG) : La passerelle d’adaptation (AG : Adaptation Gateway) est la deuxième

entité clé de l’architecture IPTV considérée. Elle est déployée entre le cœur du réseau et un réseau

d’accès afin de fournir des flux IPTV personnalisés aux stations 802.11 hétérogènes et mobiles. Ainsi,

la passerelle d’adaptation s’occupe de la gestion du réseau WLAN 802.11 en intégrant directement un

point d’accès afin de permettre aux clients connectés via ce réseau d’accéder à un service LoD et de

recevoir les flux TV transmis par le fournisseur de contenu. Afin de personnaliser les flux IPTV, la

passerelle d’adaptation doit interagir avec les couches du réseau d’accès ainsi que le terminal récepteur.

Ceci lui permettra de déterminer la configuration qui assure des performances de transmission

optimales. Cette configuration va servir à l’exécution des adaptations qui permettent, principalement,

de garantir un certain niveau de QoS. En effet, la tâche principale d’une AG est d’adapter la

transmission audio/vidéo en fonction du profil de l’utilisateur mobile. Ainsi, cette adaptation se base

principalement sur un des outils proposés dans la partie 7 du standard MPEG-21, à savoir DIA

(Digital Item Adaptation). Il s’agit de l’UED (Usage Environment Description), décrit dans la section

5.3.2.2, qui permet de décrire les préférences de l’utilisateur, les capacités du terminal qu’il utilise et les

caractéristiques du réseau d’accès, par rapport à la QoS des applications multimédia comme l’IPTV.

• Le réseau d’accès (IEEE 802.21) : Le réseau d’accès est un réseau de type IEEE 802.21 offrant une

connexion IP sans fil. Le déploiement de la technologie 802.11 au niveau des réseaux d’accès s’est

accéléré avec l’apparition des nouvelles normes 802.11g/n [IEE 03]-[IEE 07] qui ont augmenté les

débits de transmission à 54 Mbit/s et jusqu’à 540 Mbit/s. Cette augmentation a permis la transmission

des services IP multimédia gourmands en bande passante comme l’IPTV. Le réseau Wi-Fi 802.11

représente le dernier segment de l’architecture IPTV, sur lequel les flux TV sont transmis en unicast

afin de faire face à l’hétérogénéité des récepteurs mobiles qui possèdent des capacités différentes en

termes de codecs, de puissance de calcul, d’affichage, de sortie audio, etc. En effet, si les flux TV

étaient transmis sur les réseaux Wi-Fi 802.11 avec leur format original, certains terminaux ne

pourraient pas décoder ces flux. De plus, le débit fourni par les réseaux 802.11 reste limité et le débit

des flux TV est relativement élevé. Ainsi, la transmission multicast ne peut pas être étendue au réseau

d’accès, et c’est effectivement la passerelle d’adaptation qui s’occupe d’offrir un service LoD en

134

transmettant en unicast des flux TV adaptés aux terminaux. Le déploiement de cette AG dans le

réseau d’accès a plusieurs avantages. Parmi ces avantages, nous citons la limitation du nombre de

récepteurs pris en charge, puisqu’une AG doit exécuter, pour chaque flux TV transmis, des

adaptations qui sont gourmandes en ressources de calcul (CPU, mémoire, etc.). Un autre avantage est

la communication directe entre une AG et le terminal mobile afin de faciliter la récupération des

caractéristiques de ce terminal ainsi que les préférences de l’utilisateur pour exécuter rapidement les

adaptations requises.

5.2.2 Offre de la QoS et de la sécurité

La description de l’architecture IPTV, donnée ci-dessus, présente une discontinuité dans la

transmission de bout en bout des flux LoD sur les réseaux IP. En effet, ces réseaux couvrent deux

segments à savoir le cœur de réseau et le réseau d’accès. Afin d’optimiser la transmission des flux IPTV du

fournisseur de contenu jusqu’aux utilisateurs mobiles, deux types de transmission différents sur chacun

des deux segments IP ont été retenus. Il s’agit d’une transmission multicast dans le cœur de réseau qui

permet d’assurer une grande scalabilité, et d’une transmission unicast sur les réseaux d’accès afin d’assurer

l’adaptation des flux aux capacités des terminaux mobiles ainsi qu’aux préférences des utilisateurs.

Cependant, pour garantir une offre de service de bout en bout incluant à la fois la qualité de service

et la sécurité, nous pouvons, par exemple, utiliser le protocole SLNP afin de négocier un niveau de service

de bout en bout. Mais ceci nécessitera l’établissement d’un SLS pour chaque flux entre le fournisseur de

contenu et l’utilisateur mobile, ce qui implique le passage à une transmission en unicast même sur le

segment cœur du réseau. Par conséquent, un très grand nombre de flux IPTV seront dupliqués en

entrainant la dégradation des performances du cœur de réseau à cause de cette charge supplémentaire

considérable.

Ainsi, nous devons trouver une solution pour parvenir à gérer une QoS et une sécurité de bout en

bout, tout en gardant cette distinction des deux segments où le multicast est employé dans le cœur du

réseau. Ceci permettra de continuer à profiter des avantages de cette approche, à savoir une optimisation

de la transmission, tout en préservant les ressources au niveau du cœur du réseau.

Figure 5-2 : Gestion de l’offre de service IPTV

135

Dans ce qui suit, nous proposons une solution qui répond à ces exigences en préservant la distinction

entre le cœur du réseau et le réseau d’accès. Dans cette solution, les mécanismes de gestion de l’offre de

service diffèrent d’un segment à l’autre, comme le montre la Figure 5-2.

5.2.2.1 Négociation du niveau de service dans le cœur du réseau

Dans le cœur du réseau, nous proposons d’utiliser le protocole SLNP afin de négocier un niveau de

service portant sur la QoS et la sécurité. En effet, le SLS négocié grâce à ce protocole inclut des

paramètres de QoS et de sécurité (cf. section 4.4.) pouvant être négociés entre les différents responsables

des domaines impliqués dans une transmission de flux IPTV.

Les paramètres de QoS négociés avec SLNP permettent de spécifier parfaitement le niveau de la QoS

qui doit être garantie pour une transmission d’un flux IPTV entre un fournisseur de contenu et plusieurs

passerelles d’adaptation. En effet, l’élément ‘scope’ (Figure 3-12) qui se trouve dans l’élément

‘qosParameters’ du ‘sls’ permet de spécifier un point d’entrée qui peut être le fournisseur de contenu et un

point de sortie qui peut représenter les passerelles d’adaptation appartenant à un même groupe de

multicast. Ainsi, l’adresse IP du point d’entrée n’est autre que l’adresse IP du fournisseur de contenu, alors

que celle du point de sortie est l’adresse du groupe concerné. Les autres éléments contenus dans

‘qosParameters’ permettent à une passerelle d’adaptation de spécifier ses besoins en matière de QoS ; à

savoir le délai, la gigue, la bande passante, le taux de perte, le temps de service, le traitement d’excès, etc.

Notons que lorsqu’une passerelle spécifie le niveau de la QoS qu’elle va négocier relativement à la

transmission des flux IPTV au niveau du cœur du réseau, elle doit prendre en compte la QoS de bout en

bout requise par les utilisateurs mobiles ainsi que la QoS qui caractérise la transmission des flux IPTV à

ces utilisateurs au niveau du réseau d’accès. A titre d’exemple, nous considérons une offre de service où le

délai de bout en bout à garantir doit être inférieur ou égal à 250 ms. Si la passerelle d’adaptation sait que

les flux IPTV ne peuvent pas être transmis sur le réseau d’accès en moins de 50 ms, alors elle doit

demander un niveau de service avec un délai qui doit être absolument inférieur ou égal à 200 ms.

En ce qui concerne le niveau de sécurité à négocier, l’élément ‘secParameters’ (Figure 4-10), composé

d’une portée de sécurité (‘scope’) et d’un protocole de sécurité (‘secProtocol’), permet de spécifier les

extrémités du flux sécurisé ainsi que les paramètres de sécurisation de ce flux. De même que la portée de la

QoS, la portée de la sécurité peut avoir comme point d’entrée le fournisseur de contenu, et comme point

de sortie l’ensemble des passerelles d’adaptation formant un groupe multicast. Le deuxième élément des

paramètres de sécurité (‘secParameters’), à savoir l’élément ‘secProtocol’, permet de se mettre d’accord sur

l’utilisation d’un protocole de sécurité et sur les paramètres caractérisant le niveau de sécurité offert par ce

protocole. Etant donné que l’architecture considérée utilise le protocole RTP (Real-time Transport

Protocol) [SCH 03] juste au dessus du protocole UDP pour le transport des flux IPTV au niveau du cœur

du réseau, il existe alors un autre protocole qui pourrait être utilisé dans la sécurisation de ces flux ; il s’agit

du protocole SRTP (Secure Real-time Transport Protocol) [BAU 04]. En effet, ce protocole propose de

sécuriser les flux échangés au niveau RTP en spécifiant ses propres mécanismes et ses propres algorithmes

de cryptographie. Ainsi, nous proposons d’inclure ce protocole de sécurité dans la liste des protocoles

pouvant être négociés avec SLNP. En implémentant le protocole SRTP, les entités impliquées dans le

transport d’un flux IPTV ont plus de choix par rapport à la manière de sécuriser ce flux et plus de chance

d’aboutir à un accord concernant le niveau de sécurité (Tableau 5-1).

136

Protocole de sécurité

Authentification, intégrité et non-répudiation

Confidentialité Protection contre

le rejeu

IPSec-AH HMAC-SHA1-96

AES-XCBC-MAC-96 HMAC-MD5-96

Numéro de séquence

(Optionnel)

IPSec-ESP HMAC-SHA1-96

AES-XCBC-MAC-96 HMAC-MD5-96

3DES-CBC AES-CBC DES-CBC

Numéro de séquence (Optionnel)

DTLS MD5 SHA1

AES, DES, 3DES, RC4-40, RC4-128, IDES,

Fortezza

Numéro de séquence (Automatique)

SRTP HMAC-SHA1 AES-CM AES-f8M

Numéro de séquence (Automatique)

Tableau 5-1 : Protocoles et algorithmes de sécurité utilisés pour un flux IPTV

Le Tableau 5-1 montre les différentes possibilités de sécurisation d’un flux IPTV. En effet, le

protocole IPSec peut être utilisé dans la protection de ce genre de flux puisqu’il permet de sécuriser

n’importe quel type de flux au niveau IP. Le protocole DTLS peut, également, servir dans l’offre de

services de sécurité au flux IPTV car le transport de ce flux est fondé sur le protocole UDP. Par ailleurs,

les entités impliquées dans le transport d’un flux IPTV au niveau du cœur du réseau peuvent faire appel au

protocole SRTP afin d’assurer un certain niveau de sécurité.

Ainsi, nous avons procédé à l’extension du schéma XML afin de couvrir les besoins d’une

négociation visant à assurer une offre de service IPTV. L’élément ‘secProtocol’ du nouveau schéma XML

auquel le SLS négocié doit se conformer est donné dans la Figure 5-3. Cette nouvelle structure (les

éléments ajoutés sont dessinés en pointillées) donnera la possibilité aux entités impliquées dans une

négociation de niveau de service de choisir la sécurité SRTP et de se mettre d’accord sur les algorithmes à

utiliser pour les deux services de sécurité négociables, à savoir l’intégrité et la confidentialité (voir Tableau

5-1).

Figure 5-3 : Structure de l’élément ‘securityProtocol’ adaptée au cas de l’IPTV

Pour préserver le mode de transmission multicast au niveau du cœur du réseau, le fonctionnement

général du protocole a été légèrement modifié afin de s’adapter à cette situation bien particulière. En

utilisant toujours les mêmes messages SLNP, nous avons proposé un nouveau déroulement pour la

procédure de négociation que nous allons présenter à présent. Ce nouveau déroulement ne nécessite

aucune modification dans l’implémentation du protocole SLNP.

Une négociation SLNP peut avoir lieu entre un fournisseur de contenu et un ensemble de passerelles

d’adaptation (AG). Il faut préciser, tout d’abord, que dans un processus de négociation, les AG doivent

appartenir à un seul et même domaine. Dans le cas contraire, on aurait plusieurs négociations SLNP où les

chemins de négociation diffèrent les uns des autres, et donc obligatoirement des groupes multicast

différents. Ainsi, les AG abonnées à un groupe multicast appartiennent à un seul et même domaine.

137

Figure 5-4 : La négociation SLNP au sein d’un groupe multicast IPTV

Lorsqu’un groupe multicast est créé, une négociation SLNP doit avoir lieu entre la première

passerelle (AG1) voulant se joindre à ce groupe et le fournisseur de contenu (CP).

Lorsqu’une deuxième passerelle (AG2) désire se joindre à ce même groupe, elle initie l’établissement

d’un SLS avec le CP. Si le niveau de service demandé par cette AG2 est le même que celui déjà établi entre

le CP et la passerelle AG1, alors cette dernière est incluse dans le SLS déjà établi. Dans le cas contraire,

une alternative lui est proposée par le réseau. Cette alternative correspond au niveau de service établi entre

le CP et la passerelle AG1. Lorsque la SG2 reçoit cette proposition de la part du cœur du réseau, elle peut

l’accepter et pourra donc se joindre au groupe multicast et bénéficier du niveau de service caractérisant ce

groupe, comme elle peut redemander le même niveau de service qu’elle a demandé auparavant. En

recevant la même demande, le responsable du domaine auquel appartient le CP se charge de notifier la

passerelle AG1 avec le SLS demandé par la passerelle AG2. En cas d’acceptation de cette notification, le

138

SLS demandé par la passerelle AG2 est accepté et celui déjà établi avec la passerelle AG1 est modifié.

Dans le cas contraire la demande de la passerelle AG2 est rejetée.

Lorsqu’une nième passerelle AGn (n≥3) veut se joindre à un groupe multicast composé de n-1

passerelles, alors la négociation doit se dérouler quasiment de la même manière que lors de l’ajout de la

SG2 à ce groupe. En effet, ce qui change c’est le fait de notifier les n-1 entités du groupe lorsque la

passerelle AGn insiste en redemandant le niveau de service qu’elle a demandé initialement et qui n’a pas

été accepté. Si toutes ces entités acceptent de passer au nouveau niveau de service demandé par la nouvelle

passerelle, alors on accepte la demande de cette dernière et on procède à la modification de l’ancien niveau

de service. Dans le cas contraire, c’est-à-dire lorsqu’au moins une des AG du groupe refuse la notification,

la demande de la passerelle AGn est rejetée.

Dans le cas où une passerelle d’adaptation ne peut pas trouver un accord avec un groupe multicast

sur un niveau de service, un nouveau groupe multicast pourrait être créé pour répondre aux besoins de

cette passerelle qui sont différents des autres. Par exemple, on peut trouver deux groupes multicast où l’un

nécessite uniquement des garanties en matière de QoS, tandis que l’autre exige un niveau minimal de

sécurité en plus des garanties en matière de QoS.

5.2.2.2 Consommation du service dans le réseau d’accès

Comme il a été décrit dans la section 5.2.1.2, une passerelle d’adaptation est déployée sur la frontière

d’un réseau d’accès de type 802.11. Le rôle de cette passerelle est de transformer le flux IPTV transmis en

multicast dans le cœur du réseau en un service LoD pour les utilisateurs mobiles connectés via des

terminaux hétérogènes. Dans cette section, nous décrivons comment le service LoD est adapté par la

passerelle d’adaptation en fonction du profil de l’utilisateur.

5.2.2.2.1 Composition du profil UED utilisé

L’adaptation d’un flux IPTV au niveau du réseau d’accès est réalisée en se basant sur la description

UED qui couvre les caractéristiques de l’utilisateur à savoir : ses préférences, les capacités de son terminal

et les caractéristiques du réseau d’accès. Cependant, tous les paramètres décrits par l’UED sont reliés

uniquement à la QoS, et aucun paramètre de sécurité n’est considéré. Or, afin d’assurer un certain niveau

de sécurité qui pourrait être requis par un utilisateur, il faut considérer la sécurité lors de la description de

l’environnement de l’utilisateur en utilisant l’UED. Par exemple, une passerelle d’adaptation doit connaître

le protocole et les algorithmes de sécurité supportés par le terminal de l’utilisateur afin de décider du type

de sécurité à mettre en œuvre. Ainsi, pour assurer à la fois la QoS et la sécurité pour les utilisateurs

connectés directement à une passerelle d’adaptation, des paramètres relatifs à la sécurité ont été introduits

dans la description déjà permise par l’UED. Les Figures 5-5, 5-6 et 5-7 montrent les éléments qui

composent le schéma XML représentant un profil UED. Sur ces figures, les paramètres relatifs à la

sécurité que nous avons ajoutés ont été dessinés en pointillés afin de les distinguer des paramètres relatifs

à la QoS.

• Les préférences de l’utilisateur « UserPreferences » (Figure 5-5) : Les préférences de l’utilisateur sont divisés en

deux sections: les préférences par rapport à l’affichage « DisplayPreferences » et les préférences en

matière de sécurité « SecurityPreferences ». Les préférences par rapport à l’affichage contiennent

uniquement le paramètre « ColorPreferences » qui permet à l’utilisateur de choisir de recevoir la vidéo

139

en couleur ou bien en noir et blanc. Quant aux préférences en matière de sécurité, l’utilisateur peut

spécifier si la sécurité doit être activée ou non grâce à l’élément obligatoire « SecurityStatus ». Dans le

cas où la sécurité est requise, l’utilisateur doit spécifier le niveau souhaité pour les deux services de

sécurité à savoir l’intégrité « IntegrityLevel » et la confidentialité « ConfidentialityLevel ».

Figure 5-5 : Composition des caractéristiques de l’utilisateur

• Les caractéristiques du réseau « NetworkCharacteristics » (Figure 5-6) : Les caractéristiques du réseau

comprennent les capacités réseaux « NetworksCapability » et les conditions réseaux

« NetworksCondition ». Les capacités réseaux regroupent les paramètres invariants (statiques) du

réseau tels que le débit maximal « MaxCapacity » (par exemple 11 Mbits/s pour la norme 802.11b et

54 Mbits/s pour la norme 802.11g), le taux d’erreur moyen « ErrorConnection » et la sécurité

« Security » au niveau de la couche liaison qui peut être activée en utilisant un protocole de sécurité

(par exemple WEP, WPA, WPA2). Tandis que les conditions réseaux regroupent les paramètres

variables (dynamiques) du réseau comme le débit disponible « Bandwidth », le taux de perte

« LossRate », la gigue « Jitter », et la puissance du signal « SignalStrength ».

Figure 5-6 : Composition des caractéristiques du réseau

• Les capacités du terminal « TerminalCapabilities » (Figure 5-7) : Les capacités du terminal sont découpées en

quatre classes où les trois premières sont reliées à la QoS, tandis que la dernière décrit les capacités par

rapport à la sécurité. La première classe « CodecCapability » donne les capacités de décodage

audio/video du terminal (le format de codage « codec », le débit « Bitrate » et le nombre d’images par

seconde « FrameRate »). La deuxième classe « DisplayCapability » décrit les capacités d’affichage du

terminal en termes de résolution verticale et horizontale « Resolution ». La troisième classe précise les

capacités de sortie audio du terminal « AudioOutput » composées du nombre de canaux audio

140

« NumChannels » et du taux d’échantillonnage « SamplingFrequency ». Quant à la dernière classe, elle

décrit les capacités du terminal reliées à la sécurité en énumérant les différents protocoles de sécurité

supportés par le terminal (« Ipsec », « Dtls » et/ou « Srtp ») ainsi que les algorithmes pouvant être

utilisés pour fournir les services de sécurité avec chaque protocole (« Integrity », « Confidentiality » et

« NoReply »).

Figure 5-7 : Composition des capacités du terminal

Une fois constitué, l’UED doit être transmis du client vers la passerelle d’adaptation afin de

demander un flux IPTV spécifique. Etant donné que la transmission du flux IPTV se base sur le protocole

RTSP qui ne gère pas l’adaptation des flux, nous verrons dans la partie suivante comment le

fonctionnement de ce protocole a été ajusté afin de permettre la réalisation de l’adaptation du flux ainsi

que la configuration de la sécurité.

5.2.2.2.2 Adaptation du flux IPTV

Dans l’architecture IPTV considérée, on utilise le protocole RTSP (Real Time Streaming Protocol)

[SCH 98] pour assurer la transmission des flux IPTV aux différents utilisateurs. Ce protocole a été défini

spécialement pour assurer le contrôle d’une session de transmission vidéo. En effet, RTSP est un

protocole de signalisation fondé sur des échanges requêtes/réponses en mode texte. Avant d’entamer la

signalisation, le client récupère à partir des annonces du serveur de flux, l’URL RTSP du flux qu’il veut

recevoir. Pour annoncer une session multimédia multicast, le serveur utilise le protocole SAP (Session

Announcement Protocol) [HAN 00]. Ensuite, la signalisation débute lorsque le client transmet une

requête « OPTION » pour demander à l’AG le type de requêtes qu’il supporte. L’AG communique ces

requêtes dans la réponse. Puis, le client demande la description de la session SDP (Session Description

Protocol) [HAN 06] qui comprend des informations concernant les flux audio/vidéo (format, type

d’encapsulation, etc.) et des informations concernant le transport (les adresses et les ports d’émission et de

réception, les protocoles de transport utilisés, etc.). Enfin, le serveur fournit la description SDP du

141

contenu vidéo statique qui sera transmis lorsque le client accepte la réception de ce contenu. Si le client ne

supporte pas la configuration proposée par le serveur dans la description SDP, alors sa demande échoue.

Ainsi, la signalisation permise par le protocole RTSP ne fournit aucun mécanisme permettant au

client d’envoyer son profil, c’est-à-dire la description UED lui concernant. Pour faire face à ce problème,

une première modification concernant le fonctionnement du protocole RTSP [SCH 98] a été proposée

afin de permettre la transmission de la description UED de l’utilisateur. Cette modification est illustrée

dans la Figure 5-8 qui détaille les échanges RTSP effectués entre un client et la passerelle d’adaptation à

laquelle il est connecté. Avec le nouveau fonctionnement, la description SDP n’est plus statique ; elle est,

en fait, générée par l’AG suivant l’adaptation décidée par rapport à chaque nouvelle session. Pour cela, la

description UED est intégrée à la requête « DESCRIBE » transmise par le client vers l’AG. Cette dernière

(AG) spécifie les paramètres de QoS et de sécurité pour la session afin de générer une nouvelle description

SDP de la session. Le nouveau SDP est, ensuite, transmis dans la réponse à la requête « DESCRIBE ». Le

client et l’AG peuvent maintenant s’échanger les requêtes/réponses « SETUP » pour confirmer la

configuration des flux de la session. L’AG transmet les flux audio/vidéo adaptés après réception de la

requête « PLAY ». Le client peut stopper la transmission avec la requête « STOP » et détruire la session

avec la requête « TEARDOWN ».

Figure 5-8 : Messages RTSP échangés entre l’AG et le Client

Au moment où la nouvelle description SDP est reçue par le client, la sécurité décidée par l’AG peut

être configurée avant la création de la session IPTV (par exemple l’établissement de l’association de

sécurité grâce au protocole IKEv2 dans le cas d’une sécurité IPSec, etc.). Cependant, la configuration de la

sécurité à ce moment, peut être inutile, notamment dans le cas où la session n’est pas créée. Ainsi, pour

éviter de procéder à une configuration inutile, cette sécurité n’est configurée qu’après l’échange des

requêtes/réponses « SETUP » confirmant le démarrage d’une session IPTV (Figure 5-8).

142

Cette adaptation est exécutée au début de la session afin de permettre de transcoder les flux IPTV

suivant les paramètres de l’UED. Ceci implique l’établissement d’un contexte du côté de l’AG et du client

(codage/décodage, affichage, sortie audio, sécurité, etc.) représenté par la description SDP. Une fois établi,

ce contexte ne peut pas être changé sans interrompre la transmission des flux IPTV. Par ailleurs, le

changement de ce contexte (n’importe quel paramètre de l’UED) correspond au démarrage d’une nouvelle

session avec une nouvelle description UED.

5.2.3 Résumé

Il existe des architectures permettant de consommer certains services offerts par les réseaux de

nouvelle génération auxquelles la négociation SLNP, que nous avons spécifiée, ne peut pas être appliquée

tel quel afin de garantir un niveau de service de bout en bout. Parmi ces architectures, nous pouvons citer

l’IPTV sur le WiMax [SHE 07], ou encore l’IPTV sur le Wi-Fi [DJA 08] qui est caractérisée par l’utilisation

de deux modes de transport différents sur chacun des deux segments composant cette architecture.

L’architecture IPTV sur le Wi-Fi permet de délivrer des flux TV pour des utilisateurs sans fil connectés via

des réseaux d’accès de type IEEE 802.11. Dans ce cas bien précis, nous avons du proposer une solution

bien adaptée à cette architecture afin de pouvoir gérer la qualité de service et la sécurité de bout en bout

pour le service IPTV. Lors de la proposition de cette solution, nous avons pu étendre la description du

profil utilisateur, permise par l’UED, afin qu’elle permette une consommation du service IPTV pour

laquelle des garanties de QoS et de sécurité peuvent être assurées. Ceci nous a particulièrement aidés à

définir, par la suite, un profil pour la négociation de niveau de service (cf. section 5.3.3). La définition de

ce profil s’inscrit dans le cadre de la proposition d’une approche de négociation fondée sur le profil de

l’utilisateur qui permet d’adapter le protocole SLNP à l’ubiquité caractérisant la consommation des

services dans les réseaux NGN.

5.3 Négociation de niveau de service dans les environnements NGN

5.3.1 Contexte et motivations

Les réseaux NGN proposent d’assurer l’ubiquité ayant pour but de permettre à un utilisateur d’être

connecté au mieux, à tout moment et quelque soit l’endroit où il se trouve à l’Internet. Pour cela, les

différents terminaux mobiles des utilisateurs tels que les ordinateurs portables, les PDA et les smartphones

doivent être équipés d’une multitude d’interfaces de connexion. Ils auront, ainsi, la possibilité de se

connecter de n’importe où, via différentes technologies, en particulier sans fil, grâce au déploiement

attendu des nouvelles évolutions du Wi-Fi et du WiMax. Afin de permettre cette ubiquité, l’architecture

des réseaux de nouvelle génération a été fondée sur un découpage vertical entre les différents domaines

pouvant être impliqués dans le transport d’un service où chaque domaine peut fournir plusieurs types

d’accès aux utilisateurs qui lui sont directement connectés.

Dans cette architecture, rappelée dans la Figure 5-9, chaque utilisateur doit s’adresser à un fournisseur

de service (SP : Service Provider) qui s’occupe de garantir le niveau de service nécessaire à chaque

communication de ce client. Ainsi, lorsque ce SP reçoit une demande concernant une offre de service de la

part de son client, il s’occupe de l’initiation de la négociation de niveau de service entre les différents

143

fournisseurs de réseaux (NP : Network Provider) devant participer au transport du service. Généralement,

on confond le fournisseur de service avec le premier fournisseur de réseau. C’est pour cette raison que

dans la description du protocole SLNP, nous avons utilisé le terme plus général : ‘responsable de

domaine’. Ainsi, dans le fonctionnement SLNP, chaque utilisateur s’adresse au responsable du premier

domaine (SI) qui peut être, en réalité, à la fois le fournisseur de service et le fournisseur du premier réseau.

C’est donc cette entité qui s’occupe toujours d’initier une négociation de niveau de service.

Dans cette section, nous nous intéressons à ce premier domaine qui peut fournir plusieurs types de

réseaux d’accès (AN : Access Network) permettant aux différents clients de se connecter avec leurs divers

terminaux et de changer à tout moment de réseaux d’accès. En effet, le client C1, connecté via le réseau

d’accès AN1-2, a besoin de garanties de QoS et de sécurité qui pourront varier en fonction du réseau

d’accès emprunté. Par ailleurs, ce client peut vouloir changer de réseau d‘accès (AN1-1 ou AN1-3) pour

des raisons de mobilité ou parce qu’un nouveau réseau correspondant mieux à ses besoins devient

accessible. D’où le besoin de pouvoir négocier dynamiquement le niveau de service nécessaire à chaque

communication.

Figure 5-9 : Négociation SLNP dans les réseaux NGN

Le nouveau fonctionnement du protocole SLNP permet de négocier conjointement la QoS et la

sécurité, ce qui pourrait être très utile dans les environnements NGN, notamment avec le large

déploiement des réseaux sans fil. Mais, ce protocole, sous sa version actuelle, ne prend pas en compte la

mobilité des utilisateurs dans sa négociation. Nous n’avons pas non plus prévu de mécanismes pour gérer

la mise à jour d’un niveau de service lorsque le client change de réseau d’accès. De plus, nous avons vu

dans le chapitre précédent que les paramètres du SLS négociés entre les différentes responsables de

domaines sont exprimés quantitativement afin de pouvoir prendre en compte l’impact quantifié de la

sécurité sur la QoS dans cette négociation. Or, lorsqu’un utilisateur non-expert demande à son fournisseur

de service un niveau de service, il lui est très difficile d’exprimer le niveau de sécurité souhaité d’une

manière quantitative.

La solution qui permet de résoudre ces différents problèmes, est de fonder la négociation SLNP sur

un profil utilisateur. En effet, il s’agit de regrouper toutes les informations concernant l’utilisateur et son

environnement de connexion dans un profil qui lui sera associé. Ce profil permettra de déterminer avec

144

précision le SLS nécessaire aux services consommés par cet utilisateur. Et, à chaque fois que l’une des

informations composant ce profil est modifiée, la définition du niveau de service requis est relancée afin

de mettre à jour le SLS établi si nécessaire. Ceci permettra de prendre en compte tout changement qui

peut concerner l’utilisateur ou son environnement de connexion, y compris le changement de réseau

d’accès. Cette solution nous aide également à améliorer, optimiser et surtout automatiser le processus de

négociation de niveau de service assuré par SLNP. En ce qui concerne la collecte des caractéristiques du

réseau d’accès, nous proposons d’utiliser le standard MIH (cf. section 2.6.4) qui nous permettra,

également, de prendre en charge la mobilité des utilisateurs. Ceci est rendu possible grâce à la capacité du

MIH à collecter toutes les informations concernant l’environnement de connexion de l’utilisateur, et à

exécuter, d’une manière accélérée, les handovers dans des environnements hétérogènes.

Dans la section suivante, nous définissons ce qu’est qu’un profil utilisateur avant de donner quelques

exemples de profils utilisateurs et de décrire leurs contextes d’utilisation.

5.3.2 Profil utilisateur

Un profil utilisateur (ou encore modèle utilisateur) est un ensemble de données très diverses qui

concernent un utilisateur. C’est, en effet, une source de connaissance qui peut regrouper des informations

d’identification ainsi que des informations complémentaires sur le contexte de la communication,

permettant une meilleure adaptation à l’environnement de connexion, telles que les préférences de

l’utilisateur, la taille de l’écran, la disponibilité des ressources, etc. Dans ce qui suit, nous donnons quelques

exemples de profil utilisateur proposés dans le cadre de normes ou de travaux de recherche.

5.3.2.1 Profil « CC/PP » pour l’adaptation des flux

Le profil CCPP (Composite Capability/Preference Profiles) [KIS 07] a été défini par les groupes de

travail « CC/PP » et « Ubiquitous Web Application » du W3C dans le but de spécifier un standard

permettant de décrire les capacités du terminal, ainsi que les préférences de l’utilisateur. Ce profil, prévu

pour être utilisé avec HTTP, fait souvent référence à un contexte de transmission, et permet de réaliser

l’adaptation de contenu.

La structure d’un profil CC/PP est caractérisée par une hiérarchie à deux niveaux. Le premier niveau

doit contenir une ou plusieurs composantes, tandis qu’au deuxième niveau, chaque composante possède

un ou plusieurs attributs. Les composantes que peut englober un profil CC/PP sont au nombre de trois :

la plateforme matérielle sur laquelle le logiciel s’exécute (Terminal Hardware), la plateforme logicielle sur

laquelle reposent toutes les applications exécutées (Terminal Software) et l’application (Terminal Browser).

Le profil CC/PP permet de décrire les capacités du terminal et les préférences de l’utilisateur à travers les

différents attributs que peut contenir chaque composante. En effet, chaque composante du profil CC/PP

constitue un sous-arbre dont les branches contiennent les capacités et/ou les préférences associées à ce

composant. Par exemple, la composante « Terminal Hardware » peut contenir des attributs tels que

l’attribut « CPU » et l’attribut « Screen Size », qui permettent de décrire les capacités matérielles du

terminal. Quant à la composante « Terminal Software », elle permet de décrire les capacités logicielles du

terminal utilisé à travers un certain nombre d’attributs comme : « OS Name », « OS Vendor » et « OS

Version ». Enfin, la composante « Terminal Browser » permet de spécifier les caractéristiques de

145

l’application exécutée en utilisant, par exemple, les attributs suivants : « Browser Name », « Browser

Version » et « Html Version ».

5.3.2.2 Profil « UED » pour l’adaptation des flux

La norme MPEG-21 [ISO 04] a été définie par le groupe MPEG dans le but de spécifier une

architecture standardisée pour la livraison et la consommation de contenus multimédia. La partie 7 de

cette norme [ISO 07], appelée DIA (Digital Item Adaptation), définit un ensemble d’outils permettant de

réaliser l’adaptation des flux multimédia. Parmi ces outils, nous trouvons l’UED (Usage Environment

Description) qui fournit des descriptions normalisées de propriétés relatives à l’utilisateur et à son

environnement. Autrement dit, l’UED permet de décrire le profil d’un utilisateur qui couvre quatre

aspects importants pour l’adaptation des flux multimédia. Tout d’abord, les caractéristiques de l’utilisateur

(1) qui comprennent des informations comme le genre de contenu préféré, la langue préférée, le degré de

violence dans les scènes vidéo, le sous-titrage, etc. Viennent, ensuite, les capacités du terminal (2) qui

couvrent : le codage audio/vidéo supporté, la capacité d’affichage vidéo, la capacité de sortie audio, les

caractéristiques de stockage, etc. On retrouve, ensuite, les caractéristiques du réseau (3) qui comportent les

caractéristiques statiques tel que le débit maximal et le taux d’erreurs moyen, ainsi que les paramètres de

performances instantanés comme le délai de transmission, la gigue, le taux de perte et le débit disponible.

Viennent, enfin, les caractéristiques de l’environnement naturel (4) permettant de décrire l’environnement

extérieur de l’utilisateur, par exemple, sa localisation, le degré de bruit audio, le degré de luminosité, etc.

Le profil utilisateur défini par cette norme est assez général. En effet, il couvre quatre types différents

de paramètres qui peuvent être très intéressants dans un contexte de négociation de niveau de service dans

un environnement NGN. Par conséquent, la plupart de ces composantes, à savoir l’utilisateur, le terminal

et le réseau seront considérés dans le profil utilisateur pour la négociation. Mais, les paramètres de chaque

type seront définis sur la base des besoins de négociation et indépendamment du type de service,

contrairement aux paramètres déterminés par MPEG-21 et qui sont orientés « services multimédia ». Par

contre, nous devons définir un nouveau type de paramètres, à savoir les caractéristiques de l’application,

qui permettra de définir les besoins de chaque application, ceci afin de couvrir l’ensemble des besoins

applicatifs.

5.3.2.3 Profil pour la négociation de QoS

Nous trouvons, également, plusieurs travaux qui traitent de la gestion de la QoS en se fondant sur les

besoins de l’application et les caractéristiques de l’utilisateur tels que les travaux décrits dans [JRA 05],

[TEB 08] et [ROY 08]. A titre d’exemple, un profil utilisateur pour la négociation de QoS a été défini dans

le cadre de la spécification d’une interface « intelligente » qui permet d’assister les utilisateurs pour

négocier la QoS nécessaire pour leurs applications [JRA 05]. Dans ce contexte, les paramètres modélisant

un utilisateur ont été classés en trois catégories. Tout d’abord, les caractéristiques de l’utilisateur

contiennent des informations comme le login, la langue, la localisation et le degré d’expertise. Ensuite, les

préférences de l’utilisateur lui permettant d’exprimer ses besoins et ses exigences par rapport aux

différentes tâches effectuées. Enfin, le travail réalisé est caractérisé par le nom et le type de l’application, la

date, l’heure et la durée d’activation, ainsi que les exigences de cette application.

Les paramètres du profil déterminés dans ce contexte couvrent simplement l’utilisateur et le travail

effectué, et permettent de définir la QoS nécessaire à ce travail. Or, le protocole SLNP associe la sécurité à

146

la QoS dans sa négociation. Par conséquent, d’autres aspects doivent être considérés tels que les

préférences de l’utilisateur par rapport à la sécurité, les caractéristiques du réseau d’accès en matière de

QoS et de sécurité, ou encore les capacités du terminal et les protocoles et mécanismes de sécurité qu’il

supporte. Ceci nous amène à définir un profil utilisateur plus généraliste et comprenant plusieurs types de

paramètres (cf. section 5.3.3).

Synthèse : Les exemples que nous venons de décrire pourront nous aider à déterminer les paramètres

qui vont constituer notre profil pour la négociation SLNP. Mais, la définition de ce profil sera

essentiellement basée sur les besoins que nous avons définis ; à savoir permettre de déterminer le SLS à

négocier et faciliter la négociation dans un environnement NGN caractérisé par l’ubiquité et la dynamicité.

5.3.3 Définition d’un profil utilisateur pour la négociation SLNP

Le profil utilisateur sert à stocker des informations concernant l’environnement de la

communication : le terminal, l’application, le réseau d’accès et les préférences de l’utilisateur (Figure 5-10).

Ces informations permettent d’établir un niveau de service, mais aussi de le modifier si nécessaire. Dans

cette partie, seront détaillées les informations que nous avons sélectionnées pour former le profil

utilisateur pour la négociation dans un environnement NGN.

Figure 5-10 : Composition du profil utilisateur pour la négociation

5.3.3.1 Préférences de l’utilisateur

Les préférences de l’utilisateur se divisent en trois catégories : les préférences en matière de QoS, les

préférences pour la sécurité et les préférences par rapport aux réseaux d’accès (Tableau 5-2).

5.3.3.1.1 Préférences par rapport à la QoS

Pour la QoS, les préférences de l’utilisateur sont exprimées en spécifiant le niveau de QoS souhaité.

Ce niveau peut avoir une des trois valeurs suivantes : Bon, Moyen ou Minimal. Si le niveau de QoS

souhaité est Bon ou Moyen, alors les garanties de QoS qui seront négociées avec SLNP vont correspondre

à un niveau de QoS supérieur ou égal à celui que nécessite le bon fonctionnement de l’application ; a

savoir le niveau Minimal. L’utilisateur peut, également, spécifier le codec audio préféré pour les

applications audio, ainsi que le codec vidéo préféré pour les applications vidéo. Ces préférences

147

permettront de faire le choix du codec à utiliser parmi ceux disponibles, lorsqu’il s’agit d’une application

audio ou vidéo.

5.3.3.1.2 Préférences par rapport à la sécurité

En ce qui concerne la sécurité, un utilisateur doit préciser si la sécurisation de son service est

Indispensable, Souhaitée ou Pas-nécessaire. Dans les deux premiers cas, il doit sélectionner les services de

sécurité à fournir parmi les deux services disponibles, à savoir la Confidentialité et l’Intégrité qui regroupe

l’intégrité, l’authentification et la protection contre le rejeu. Lorsque la sécurité est requise, l’utilisateur doit

spécifier le niveau de chaque service de sécurité qu’il a sélectionné. En effet, chacun des deux services de

sécurité (Intégrité et Confidentialité) peut avoir un des trois niveaux possibles : Bon, Moyen ou Minimal.

Si la sécurité est indispensable, alors le niveau de service établi doit respecter les exigences de l’utilisateur.

Si la sécurité est souhaitée, alors le protocole de négociation va, au mieux, établir un niveau de sécurité

correspondant à celui que l’utilisateur a spécifié.

5.3.3.1.3 Préférences par rapport au réseau d’accès

Les préférences de l’utilisateur vis-à-vis des réseaux d’accès peuvent être exprimées en sélectionnant

le critère qui doit être privilégié lors du choix du réseau. Ce critère de choix peut être le coût, la QoS, la

sécurité ou la technologie d’accès. Ensuite, l’utilisateur doit spécifier comment le critère sélectionné peut

être utilisé dans le choix du réseau. Par exemple, si la technologie d’accès constitue le critère sur lequel se

base le choix, l’utilisateur doit classer par ordre de préférence les technologies d’accès qui peuvent

cohabiter dans un environnement NGN. Ainsi, si un réseau d’accès plus prioritaire que celui utilisé est

détecté, alors le handover peut être exécuté et peut avoir pour conséquence la modification du niveau de

service déjà établi.

Catégorie Paramètres

Utilisateur Préférences par rapport à la QoS : niveau souhaité.

Préférences par rapport à la sécurité : degré d’importance, services sélectionnés, niveau souhaité pour chaque service sélectionné.

Préférences par rapport au réseau d’accès : critère de choix.

Application Nom de l’application, type de l’application, sécurité au niveau applicatif (protocole, algorithmes)

Terminal Type du terminal, CPU, mémoire, type d’alimentation, autonomie de la batterie, taille de l’écran, codecs supportés (audio et vidéo), sécurité supportée (protocoles et algorithmes).

Réseau d’accès Identificateur, technologie d’accès, coût, QoS (débit, délai, taux de perte), sécurité au niveau MAC (protocole, algorithmes).

Tableau 5-2 : Paramètres du profil utilisateur pour la négociation

Nous pouvons noter qu’il existe d’autres paramètres qui peuvent être ajoutés aux paramètres

caractérisant un utilisateur. Parmi ces paramètres, nous citons, à titre d’exemple, le Login et le Mot de

passe qui permettent d’identifier un utilisateur auprès de son fournisseur de service, ou encore la Langue

de cet utilisateur qui permet à ce fournisseur de communiquer avec lui (informer sur le résultat de la

négociation ou sur l’impossibilité de continuer d’offrir le même niveau de service, etc.).

Afin de permettre à un utilisateur de communiquer ses préférences à l’entité ou le module qui

s’occupera de la constitution du profil pour la négociation, nous allons concevoir et implémenter une

148

interface graphique (GUI : Graphical User Interface) (cf. section 5.3.6.1). Afin de répondre aux besoins de

la négociation dans les environnements NGN, cette interface permettra de communiquer tous les

préférences définies dans cette section.

5.3.3.2 Caractéristiques de l’application

Les caractéristiques de l’application (Tableau 5-2) sont essentiellement le nom de l’application et le

type de cette application. Ces paramètres vont permettre à la composante responsable de la définition du

SLS à négocier d’avoir une indication sur le niveau de QoS minimal permettant le déroulement normal de

la communication. En effet, celle-ci peut disposer d’un tableau de correspondance entre exigences de QoS

et types d’applications. Par ailleurs, une application peut avoir ses propres mécanismes de sécurité telle

que la sécurité des services web fournie par WSS (Web Service Security) [NAD 06]. Les informations

concernant la sécurité au niveau applicatif doivent par conséquent faire, également, partie des

caractéristiques de l’application.

D’autres paramètres relatifs à l’application exécutée par l’utilisateur peuvent faire partie du profil pour

la négociation. Parmi ces paramètres, nous citons la date et l’heure du lancement de l’application ainsi que

la durée de son exécution. Ces paramètres sont très utiles dans la spécification du paramètre temps de

service du SLS à négocier, lorsqu’il s’agit d’une réservation de ressources à l’avance (temps de service

différé ou périodique). Il est vrai, que le protocole SLNP à prévu de négocier des niveaux de service à

l’avance. Mais ceci n’est pas considéré dans notre travail parce que la négociation est effectuée dans des

environnements très dynamiques où les ressources qui peuvent être très limitées (cas des réseaux sans fil)

n’arrêtent pas de varier. Ainsi, on ne s’intéresse qu’aux services avec un paramètre temps de service de

type immédiat. Par conséquent, ces paramètres (heure, date, durée) ne feront pas partie des

caractéristiques de l’application considérée dans le profil défini pour la négociation.

Les caractéristiques de l’application considérée peuvent être transmises directement par cette

application vers l’entité ou le module qui se chargera de maintenir le profil utilisateur.

5.3.3.3 Caractéristiques du terminal

Parmi les caractéristiques d’un terminal (Tableau 5-2), nous trouvons des paramètres comme la taille

de l’écran et les codecs (audio et vidéo) supportés. Ces paramètres vont aider au choix des codecs à utiliser

mais surtout à déterminer, par la suite, le niveau de QoS nécessaire. De plus, ces caractéristiques couvrent

les performances du terminal comme la capacité du CPU et celle de la mémoire qui vont servir lors de

l’estimation de l’impact des mécanismes de sécurité sur la QoS. Ces caractéristiques contiennent,

également, les protocoles de sécurité et les algorithmes cryptographiques supportés par le terminal, ceci

permettra de déterminer les paramètres de sécurité à négocier (i.e. la composante sécurité du SLS). Un

terminal est également caractérisé par un type d’alimentation comme le secteur ou la batterie. Si la batterie

constitue la seule source d’alimentation alors l’autonomie de cette batterie doit faire parti des paramètres

constituant le profil utilisateur pour la négociation. En effet, ce paramètre (autonomie de la batterie) doit

être surveillé tout au long d’une communication afin de prendre les mesures nécessaires pour assurer une

durée maximale pour cette communication. Par exemple, lorsque le niveau de la charge de la batterie passe

en deçà d’un certain seuil, on peut, dans la mesure du possible, dégrader le niveau de la sécurité ou le

niveau de la qualité de service afin de réduire les opérations effectuées par le terminal.

149

Il existe d’autres paramètres qui peuvent figurer parmi ceux qui caractérisent un terminal. Parmi ces

paramètres nous citons, à titre d’exemple, le type, la marque, le modèle et le système d’exploitation. Ces

paramètres ne seront pas considérés dans le profil utilisateur parce qu’ils n’ont aucun impact sur la

définition du niveau de service à négocier.

Les paramètres relatifs au terminal utilisé par l’utilisateur peuvent être communiqués directement par

le terminal à l’entité ou le module qui maintient le profil utilisateur.

5.3.3.4 Caractéristiques des réseaux d’accès

Un réseau d’accès est généralement caractérisé par un identificateur, une technologie d’accès (PSTN,

ADSL, GPRS, UMTS, Wi-Fi, WiMax, Bluetooth, etc.), un coût, une QoS et une sécurité (Tableau 5-2).

Les paramètres de QoS englobent le débit ou la bande passante, le délai et le taux de perte. Quant à la

sécurité, il s’agit de spécifier si le réseau d’accès est sécurisé ou non, et de préciser le protocole de sécurité

utilisé comme par exemple WEP (Wired Equivalent Privacy), WPA (Wi-Fi Protected Access) ou WPA2

qui permettent de sécuriser les réseaux Wi-Fi. Avec les préférences de l’utilisateur par rapport au réseau

d’accès, ces informations vont permettre, dans un premier temps, la sélection d’un réseau d’accès et, dans

un second temps, les prises de décision concernant le changement de réseau d’accès.

Les informations concernant les réseaux d’accès disponibles peuvent être collectées en utilisant le

protocole MIH [IEE 08] que nous avons décrit dans le deuxième chapitre de ce mémoire. Ainsi, ce

protocole permettra, non seulement de prendre en compte l’impact de la mobilité des utilisateurs sur le

niveau de service, mais participera aussi à la constitution du profil utilisateur sur lequel sera fondée l’offre

de service dans les environnements NGN.

5.3.4 Négociation SLNP basée sur le profil utilisateur

Après avoir défini les paramètres composant un profil utilisateur, nous allons, dans cette section,

spécifier comment le protocole SLNP peut se baser sur ce profil afin de réaliser la négociation de niveau

de service. Pour ce faire, la première question à laquelle nous devons répondre, est : « Où le profil

utilisateur doit-il être maintenu ? ».

Pour répondre à cette question, il faut, tout d’abord, étudier les deux solutions qui peuvent être

envisagées. En effet, le profil utilisateur peut être maintenu au niveau du fournisseur de service ou bien au

niveau du terminal de l’utilisateur.

La première possibilité qui consiste à maintenir le profil utilisateur chez le fournisseur de service (SP)

permet une meilleure visibilité des clients pour les fournisseurs. Or, en optant pour cette solution, les

traitements de mise en correspondance entre le profil de l’utilisateur et le niveau de service nécessaire

vont, également, se faire au niveau de ce SP. Si ce SP n’avait qu’un seul, deux ou même quelques dizaines

de clients, cela pourrait être gérable. Cependant, un SP peut avoir des milliers de clients pour lesquels il

doit garantir des offres de services. Par conséquent, la surcharge totale, induite par les traitements de mise

en correspondance nécessaires à la négociation des niveaux de services pour tous les clients, peut être très

importante et risque même de mettre le SP hors-service.

La deuxième possibilité consiste à collecter et maintenir le profil utilisateur pour la négociation au

niveau du terminal. Par conséquent, les traitements de mise en correspondance entre profil et SLS peuvent

150

être effectués au niveau de ce terminal. Ceci nécessitera la mise en place d’une certaine « intelligence » au

niveau du terminal de l’utilisateur qui permettra, non seulement d’alléger la charge du fournisseur de

service, mais aussi d’automatiser la négociation du niveau de service. Cependant cette solution peut poser

un problème lorsque l’utilisateur change de terminal. Pour résoudre ce problème, on peut, par exemple,

stocker une copie du profil au niveau du fournisseur de service qui sera récupérée par le nouveau terminal

lorsque l’utilisateur change de terminal. Etant donné que le terminal nouvellement utilisé par l’utilisateur

peut avoir des interfaces de connexion différentes de celles de l’ancien terminal, les composantes relatives

au terminal et aux réseaux d’accès doivent, au minimum, être mises à jour. Ainsi, plus de la moitié des

paramètres du profil doivent à nouveau être collectée. Sachant que les quatre types des paramètres

composant le profil pour la négociation peuvent être collectés en même temps, il n’y a aucune perte de

temps lorsqu’un nouveau profil est constitué suite au changement de terminal.

Cette deuxième approche, pour laquelle nous optons, permet, également, de prendre la décision du

changement de réseau d’accès au niveau du terminal lui-même. Ceci se fera grâce à l’utilisation du

protocole MIH (cf. section 2.6.4) qui permet la gestion du handover pour des utilisateurs mobiles tout en

assurant la continuité de service, contrairement au protocole MIP (cf. section 2.6.1) avec lequel il n’y a pas

de continuité de service même si le client est reconnu en même temps par l’ancien et le nouveau

fournisseur de réseau.

Après avoir défini le niveau auquel le profil utilisateur pour la négociation sera maintenu, et justifié ce

choix, nous allons spécifier les différentes composantes qui seront introduites au niveau du terminal afin

de permettre l’automatisation de la négociation.

5.3.4.1 Couche de négociation

La négociation de niveau de service dans un environnement NGN nécessite la participation de

l’utilisateur final dans cette négociation qui sera fondée sur le profil de cet utilisateur. Par conséquent, nous

proposons d’introduire une couche de négociation au sein du terminal de l’utilisateur. En utilisant les

services web, le protocole SLNP opère au niveau applicatif. La couche de négociation se situera donc à ce

niveau. Cette couche est composée de trois parties (Figure 5-11) : le point de décision et de mise en

correspondance (MNDP : Mapping and Negotiation Decision Point), le générateur de SLS (SG : SLS

Generator) et l’entité SLNP (SE : SLNP Entity).

La première composante (MNDP) a essentiellement une triple tâche. C’est, tout d’abord, à ce niveau

que le choix du réseau d’accès est effectué ainsi que les prises de décision de négociation, modification ou

résiliation de SLS. Ces décisions sont prises en fonction des paramètres du profil utilisateur ou des

modifications apportées à ce profil. Ensuite, lorsque le processus de négociation doit être lancé, cette

composante permet de générer les paramètres du SLS à négocier, modifier ou résilier, en fonction des

paramètres du profil pris en entrée. Les paramètres obtenus sont passés, par la suite, au générateur de SLS

(SG) qui crée l’élément SLS sur lequel va porter la négociation. La dernière composante constitue l’entité

de négociation (SE) proprement dite, et comprend l’application cliente et le service web de négociation.

L’application cliente prend le SLS obtenu par la deuxième composante afin de créer le message adéquat

(Negotiate, Modify ou Release) pour lancer le processus correspondant (négociation, modification ou

résiliation) en invoquant le service web de la prochaine entité SLNP sur le chemin de la négociation qui

n’est autre que le responsable du domaine auquel l’utilisateur est connecté.

151

Figure 5-11 : Vue d’ensemble de la couche de négociation

Après avoir décrit le fonctionnement général de la couche de négociation introduite au niveau du

terminal utilisateur, nous allons, dans ce qui suit, détailler le rôle de chacune des trois composantes de

cette couche.

5.3.4.2 Le point de décision et de mise en correspondance (MNDP)

Cette première composante, joue un triple rôle.

• Le premier rôle est de collecter et maintenir à jour le profil de l’utilisateur. Pour parvenir à collecter

toutes les informations qui composent le profil utilisateur que nous avons défini, cette composante

doit communiquer avec le terminal, l’application, les interfaces réseau et l’utilisateur comme le montre

la Figure 5-12. Les communications de cette composante avec le terminal et l’application sont des

communications unidirectionnelles qui permettent au terminal et à l’application de transmettre leurs

caractéristiques vers la composante MNDP. Les communications avec l’utilisateur et les interfaces

réseaux sont, quant à elles, des communications bidirectionnelles (Figure 5-12). La communication

dans le sens utilisateur - MNDP est effectuée par le biais d’une interface graphique qui permet à

l’utilisateur de transmettre ses préférences vers la composante MNDP. La communication dans l’autre

sens peut servir à informer l’utilisateur sur le résultat de la négociation de niveau de service. La

communication avec les interfaces réseaux est assurée grâce au protocole MIH qui permet, dans un

premier temps, aux interfaces réseaux de transmettre les caractéristiques des réseaux détectés vers la

composante MNDP. Le protocole MIH permet également à la composante MNDP de choisir un

réseau d’accès auquel le terminal doit être connecté.

• Le deuxième rôle de cette composante est le choix d’un réseau d’accès auquel le terminal de

l’utilisateur doit être connecté. Cette connexion est nécessaire afin que l’utilisateur puisse

communiquer avec son fournisseur de service et lui transmettre le niveau de service dont il a besoin.

152

Figure 5-12 : Interactions de la composante MNDP

• Le troisième et dernier rôle, qui peut être considéré comme le rôle principal de cette composante, est

la détermination des paramètres du SLS à négocier. Cette étape nécessite, avant tout, une prise de

décision concernant la possibilité d’établir un SLS conformément au profil de l’utilisateur. Autrement

dit, il s’agit de déterminer si on peut définir un SLS qui, d’une part, répond à la fois aux exigences de

l’application et aux préférences de l’utilisateur, et qui, d’autre part, peut être supporté par le terminal et

par le réseau d’accès.

Les tâches effectuées au sein de cette composante permettent ainsi de constituer et de maintenir à

jour un profil utilisateur, et également de connecter le terminal au réseau d’accès correspondant le mieux

au profil de l’utilisateur. Ceci permet de prendre une décision concernant la possibilité d’établir un SLS et

de spécifier les paramètres de ce SLS dans le cas où cette décision est positive. L’algorithme détaillé des

traitements inclus dans cette composante (MNDP) sera fourni dans la partie relative aux détails du

fonctionnement de la nouvelle approche de la négociation SLNP (cf. section 5.3.5).

5.3.4.3 L’entité de négociation (SE)

Une fois que les paramètres de niveau de service à négocier sont déterminés par la composante

MNDP, la négociation du SLS doit être initiée par l’utilisateur. Pour cela, nous avons deux possibilités. La

première consiste à envoyer le SLS au responsable du domaine auquel l’utilisateur est connecté, afin que ce

responsable (SI) puisse initier la négociation. Cependant, cette solution nécessite la mise en place d’un

mécanisme permettant la communication entre l’utilisateur et la SI, parce que celle-ci ne peut pas redéfinir

un nouveau SLS et initier une négociation d’elle même, par exemple, en cas de non aboutissement à un

accord ou en cas de violation d’un accord déjà établi. Ainsi, la solution qui parait la plus adaptée à cette

situation et qui permet d’automatiser la communication entre l’utilisateur et la SI, est de donner la main à

l’utilisateur en équipant son terminal d’une entité de négociation (SE : SLNP Entity).

L’application cliente (CA : Client Application) de cette entité de négociation (SE : SLNP Entity) va

permettre à l’utilisateur d’initier par lui-même ses négociations de niveau de service (établissement,

modification et résiliation). Ceci implique le déploiement d’un registre de SLS (SLS Registry) au niveau du

terminal de l’utilisateur ainsi qu’une implication complète de l’utilisateur dans la négociation (Figure 5-13).

A titre d’exemple, dans le cas où une demande n’est pas acceptée par l’ensemble du réseau, la composante

MNDP se doit d’étudier la recevabilité de l’alternative proposée par ce réseau et de spécifier un autre

niveau de service, si nécessaire, tout en se conformant au profil de l’utilisateur. D’autre part, l’utilisateur à

besoin d’un service web de négociation composé d’une seule opération à savoir l’opération de notification

153

(notificationOperation). Ce qui permettra à l’utilisateur de recevoir les notifications envoyées par les

différents responsables de domaines impliqués dans l’offre de service (SI, SF et SR). Rappelons que ces

notifications étaient envoyées par les entités intermédiaires et l’entité finale vers l’entité initiale. Notons,

que le service web composant l’entité de négociation qui se trouve au niveau de l’utilisateur n’a pas besoin

de comprendre d’autres opérations que celle qui permet de recevoir les notifications, car le terminal d’un

utilisateur ne peut participer à une négociation qu’en tant qu’initiateur.

Figure 5-13 : Interactions de la composante SE

5.3.4.4 Le générateur de SLS (SG)

D’un coté, nous avons la composante MNDP qui a pour objectif de déterminer les paramètres du

SLS à négocier lorsque cette négociation peut avoir lieu. D’un autre coté, nous avons l’entité de

négociation qui prend un SLS afin de constituer le message nécessaire pour initier un processus de

négociation. Par conséquent, nous avons introduit, entre ces deux composantes, un troisième module que

nous appelons générateur de SLS (SG : SLS Generator). Ce module (Figure 5-14) permet de constituer un

élément SLS à partir des paramètres reçus de la part de la MNDP afin de le transmettre à la SE. Ainsi, les

paramètres du SLS doivent parvenir de la MNDP afin de permettre la génération de l’élément SLS sur

lequel portera la négociation.

Figure 5-14 : Interactions de la composante SG

Dans cette partie, nous avons décrit la composition de la couche de négociation que nous avons

introduite au niveau du terminal de l’utilisateur, afin de permettre à ce dernier de négocier par lui-même

l’offre des services qu’il peut consommer. Cette nouvelle approche de la négociation permet au protocole

SLNP de s’adapter aux environnements NGN, mais nécessite l’apport de plusieurs modifications au

154

fonctionnement de ce protocole. Dans ce qui suit (section 5.3.5), nous fournissons les détails du

fonctionnement de la nouvelle approche de la négociation (c’est-à-dire la négociation fondée sur le profil).

5.3.5 Fonctionnement de la négociation fondée sur le profil

5.3.5.1 Les responsables de domaines

En comparant l’ancien fonctionnement du protocole SLNP, décrit dans la section 3.4.5, à celui qui

lui permet de s’adapter à l’ubiquité requise par les environnements NGN, nous pouvons remarquer que les

changements ne touchent que les premiers acteurs de la négociation, à savoir le client et le responsable du

premier domaine. Ainsi, le comportement des SFs et de la SR reste le même (cf. section 4.4.4).

Si on s’intéresse à la SI, alors les changements concernent essentiellement le comportement de cette

entité de négociation. En effet, comme le montre la Figure 5-15, cette SI doit maintenant se comporter

comme une entité intermédiaire (SF). Ceci implique que le service web d’une SI qui servait à recevoir et à

répondre uniquement aux notifications, va maintenant permettre de recevoir, traiter et transférer les

requêtes envoyées par le client (Negotiate, Modify, Release, Response). En outre, l’application cliente qui

servait à initier les différents processus de négociation (établissement, modification et résiliation), va

maintenant servir uniquement à notifier le client afin de l’informer de la violation de l’un de ses contrats

ou des ressources nouvellement disponibles. Par conséquent, le comportement d’une SI est maintenant

identique à celle d’une SF ou d’une SR (cf. section 4.4.4).

Figure 5-15 : Fonctionnement de la négociation dans le NGN

155

Dans ce qui suit, nous nous intéressons au fonctionnement de la négociation au niveau du client

initial. Autrement dit, nous allons décrire la composition et les traitements de la couche de négociation

(Figure 5-11) que nous avons introduit au niveau du terminal de l’utilisateur afin d’automatiser la

négociation et de s’adapter aux besoins de cet utilisateur en termes de mobilité.

5.3.5.2 Le client initial

5.3.5.2.1 La composante ‘SLNP Entity’

Cette composante constitue l’entité de négociation implémentée au niveau du terminal de l’utilisateur

afin de permettre à ce dernier de contrôler ses offres de services par lui-même. Ainsi, elle doit permettre

l’établissement, la modification et la résiliation d’un SLS. Ceci est rendu possible grâce à l’application

cliente et au service web contenus dans cette entité.

L’application cliente de la composante SLNP Entity ressemble beaucoup à celle implémentée

auparavant au niveau d’une SI. Pour mettre en évidence les modifications nécessaires à l’adaptation de

SLNP à l’ubiquité que nécessitent les environnements NGN, nous allons considérer le processus

d’établissement du SLS. L’algorithme général des traitements correspondant à ce processus est identique à

celui de l’application cliente qui se trouvait auparavant au niveau de la SI (voir Figure 4-23). Cependant,

quelques modifications ont été apportées aux traitements composant cet algorithme (actions et tests). A

titre d’exemple, nous considérons l’action ‘Créer un message Negotiate’. Au niveau d’une SI (ancienne

implémentation), cette action inclut la construction du SLS à négocier à partir des paramètres du SLS pris

en argument (Figure 4-22-b). Dans le cas d’une négociation dans un environnement NGN, cette action ne

comprend que la création du message Negotiate en utilisant l’élément SLS qui lui a été fourni par le

générateur de SLS. Dans la nouvelle implémentation (Figure 5-16), réalisée également en langage Java, les

traitements correspondant au test ‘SLS proposé est accepté’ ne se font plus au niveau de l’application

cliente de l’entité de négociation. En fait, ce test à été délégué à la composante MNDP qui peut décider de

la recevabilité du SLS proposé en fonction du profil de l’utilisateur qu’elle maintient.

Figure 5-16 : Traitements au niveau du client initial

Le service web, constituant la deuxième partie de la composante SLNP Entity qui se trouve au niveau

de la couche de négociation d’un terminal utilisateur, est composé d’une seule opération à savoir la

notificationOperation. Dans le nouveau fonctionnement du protocole SLNP, les décisions par rapport

aux notifications sont prises en fonction des paramètres du profil utilisateur. Ainsi, lorsque l’opération de

notification reçoit un message Notify de la part de n’importe quel responsable de domaine, elle va

156

demander au MNDP sa décision par rapport à cette notification. La décision prise par le MNDP est

communiquée à la SE, afin que celle-ci puisse répondre correctement à la notification qu’elle a reçue.

5.3.5.2.2 La composante ‘SLS Generator’

La composante ‘SLS Generator’ a un rôle très simple qui consiste à constituer un élément ‘sls’ à partir

des valeurs des paramètres négociés, qui ont été déjà définies au niveau de la composante MNDP (Figure

5-16). Par conséquent l’implémentation de ce module se résume dans la constitution d’un objet Java à

savoir le ‘sls’. La composition de l’objet ‘sls’ suit la structure du schéma XML du SLS décrite dans la

section 4.4.2.

Notons que le SLS constitué au niveau de la couche de négociation du terminal du client inclut les

valeurs demandées de chaque paramètre sur lequel porte la négociation (delaiRequested, jitterRequested,

securityProtocolRequested, etc.). Au cas où la négociation porte sur la sécurité en plus de la QoS, ce SLS

doit contenir également les valeurs relatives à l’estimation de l’impact de la sécurité sur la QoS. Par

exemple, l’estimation du délai ajouté par les opérations de sécurité au niveau du terminal sert à initialiser le

champ réservé au calcul du délai total de bout en bout à savoir le champ ‘delayOffered’ (cf. section 3.4.5).

Etant donné que le délai de transit des données sur le premier domaine n’est pas connu par le terminal,

c’est la SI qui s’occupera d’ajouter cette information dans le SLS lorsqu’elle sera invoquée par le terminal.

5.3.5.2.3 La composante ‘Mapping and Negotiation Decision Point’

La composante ‘MNDP’ joue un rôle très important dans la nouvelle conception de la négociation de

niveau de service avec SLNP. C’est, en effet, cette composante qui permet, non seulement aux utilisateurs

mobiles de négocier le niveau de service par eux-mêmes, mais aussi d’automatiser cette négociation en la

fondant sur les profils des utilisateurs (Figure 5-16). L’algorithme des traitements réalisés au niveau de la

‘MNDP’ est donné dans la Figure 5-17. Dans ce qui suit, nous détaillons les différents traitements (actions

et tests) qui se font au niveau de cette composante, avant de décrire le fonctionnement général du module

entier.

• Sélection du réseau d’accès : le choix du réseau d’accès se fait en fonction des caractéristiques des réseaux

disponibles (obtenues grâce au protocole MIH) et des préférences de l’utilisateur par rapport aux

réseaux d’accès. En effet, les réseaux disponibles sont classés suivant le critère de choix sélectionné

par l’utilisateur. Ensuite, l’identificateur du réseau correspondant le mieux aux préférences de

l’utilisateur est utilisé afin de se connecter à ce réseau.

• Définition des paramètres de QoS : le nom et le type de l’application ainsi que la taille de l’écran et les

codecs supportés par le terminal permettent de définir la QoS minimale nécessaire pour établir la

communication. Ensuite, en fonction des préférences de l’utilisateur par rapport à la QoS, les

paramètres de QoS à négocier sont définis. En fait, si le niveau de la QoS spécifié par l’utilisateur est

égal à ‘Minimal’, alors la QoS négociée n’est autre que la QoS minimale déjà définie. Dans le cas où le

niveau de QoS spécifié par l’utilisateur est égal à ‘Moyen’ ou ‘Bon’, le niveau de QoS demandé va

correspondre à un niveau supérieur au niveau minimal. La détermination des paramètres de QoS

nécessaires pour une application donnée, est effectuée grâce à une classification des différents types

d’applications (données, audio, vidéo) et leurs besoins correspondants. A titre d’exemple, le Tableau

5-3 [ACC 03] et le Tableau 5-4 [DIM 02] fournissent les différents niveaux de QoS pouvant être

157

négociés pour respectivement une application de type audio (VoIP : Voice over IP) et une autre de

type vidéo (VoD : Video on Demand). Notons que les valeurs des paramètres caractérisant les

niveaux de QoS dépendent des codecs utilisés, de la présence d’une compression, ainsi que d’autres

paramètres. En fait, pour la VoIP, les valeurs fournies (Tableau 5-3) concernent une application qui

utilise un codec PCM (Pulse Coding and Modulation) sans aucune compression, et un canal mono

avec une fréquence d’échantillonnage à 8 KHz et 8 bits par échantillon. Tandis que, pour la VoD, les

valeurs données (Tableau 5-4) sont relatives à une application qui utilise le codec H264 avec une

compression CBR (Constant Bit Rate) à 1 Mb/s. Par ailleurs, le module de ‘Définition des paramètres

de QoS’ permet de définir une valeur booléenne (qos degradable) indiquant si le niveau de QoS

demandé peut être dégradé. Cette valeur booléenne est égale à « vrai » lorsque le niveau de QoS

correspondant aux paramètres de QoS définis est supérieur au niveau minimal requis par l’application.

Paramètre de QoS Minimal Moyen Bon

Délai de bout en bout ≥ 400 ms 150 ms – 400 ms ≤ 150 ms

Gigue ≥ 50 ms 20 ms – 50 ms ≤ 20 ms

Taux de perte ≥ 10-2 10-2 - 10-3 ≤ 10-3

Bande passante 64 Kb/s ≥ 64 Kb/s ≥ 64 Kb/s

Tableau 5-3 : Paramètres de QoS pour une application de type VoIP

Paramètre de QoS Minimal Moyen Bon

Délai de bout en bout ≥ 20 s 10 s – 20 s ≤ 10 s

Gigue ≥ 10 s 3 s – 6 s ≤ 3 s

Taux de perte ≥ 10-1 10-2 – 10-1 ≤ 10-2

Bande passante 1 Mb/s ≥ 1 Mb/s ≥ 1 Mb/s

Tableau 5-4 : Paramètres de QoS pour une application de type VoD

• Décision de sécurité : la décision de sécuriser ou non la communication est prise en fonction des

informations de sécurité sur : les caractéristiques du réseau d’accès, les caractéristiques de l’application

et les préférences de l’utilisateur. En effet, si l’utilisateur demande un certain niveau de sécurité qui ne

peut être satisfait ni par le réseau d’accès ni par l’application elle-même, alors la décision à prendre est

de sécuriser la communication au niveau « Réseau » (IPSec) ou au niveau « Transport » (TLS ou

DTLS). En privilégiant l’utilisation d’IPSec qui influence moins la QoS, la communication est

sécurisée avec IPSec si ce protocole est supporté par le terminal. Dans le cas contraire, la

communication sera sécurisée avec TLS ou DTLS en fonction du type de cette communication, c’est-

à-dire le protocole sur lequel elle est fondée : TCP ou UDP.

• Définition des paramètres de sécurité : lorsque la sécurité doit être négociée, ses paramètres sont définis en

fonction des préférences de l’utilisateur par rapport à la sécurité (les services de sécurité à fournir et le

niveau souhaité pour chaque service) et des caractéristiques du terminal (les algorithmes supportés).

En effet, en fonction des services de sécurité sélectionnés par l’utilisateur et du niveau de chacun de

ces services (Bon, Moyen ou Minimal) souhaité également par l’utilisateur, on peut définir un

ensemble d’algorithmes pouvant être utilisé pour chaque service. Notons que cet ensemble

d’algorithmes dépend également du protocole sélectionné lors de l’étape suivante (i.e. ‘Décision de

158

sécurité’). La mise en correspondance entre le niveau de sécurité souhaité par l’utilisateur et

l’algorithme à utiliser est réalisée grâce à un tableau de mise en correspondance (Tableau 5-5). Une

fois qu’un ensemble d’algorithmes est spécifié pour chaque service de sécurité, on peut choisir un

algorithme dans chaque ensemble. Ce choix est effectué en fonction des algorithmes supportés par le

terminal faisant partie également du profil de l’utilisateur. Les paramètres de sécurité définis sont

transmis avec le booléen « security degradable » qui indique si la sécurité peut être dégradée. Ce

booléen prend la valeur « vrai » si le niveau de sécurité correspondant aux paramètres de sécurité déjà

définis est supérieur au niveau minimal toléré par l’utilisateur.

Protocole Service Niveau

Bon Moyen Minimal

IPSec Intégrité hmac-sha1-96 hmac-md5-96 aes-xcbc-mac-96

Confidentialité aes-cbc, 3des-cbc aes-ctr des-cbc

TLS-DTLS

Intégrité sha1 md5 md5

Confidentialité idea, 3des des-40, rc4-128,

fortezza

des-40, rc4-40, rc2-

40

Tableau 5-5 : Tableau de mapping pour les services d’intégrité et de confidentialité

• Estimation de l’impact : dans le cas où la sécurisation est requise, l’impact des services de sécurité sur la

QoS est calculé en fonction des paramètres de sécurité et des performances du terminal. En effet, les

overheads protocolaires dépendent des protocoles utilisés et des services fournis, alors que les délais

introduits dépendent de ces mêmes facteurs mais aussi des performances du terminal tels que les

capacités de traitement ou s’il contient des composantes matérielles pour effectuer des opérations

cryptographiques, etc. Cette estimation est obtenue grâce à une base de données contenant les

résultats de l’étude de l’impact de la sécurité sur la QoS que nous avons réalisée (cf. section 4.5.2.3).

• Décision de négociation : cette décision dépend de la QoS demandée, de l’impact estimé et de la QoS du

réseau d’accès. La QoS définie auparavant est tout d’abord réajustée en tenant compte de l’impact qui

a été estimé. Ensuite, si la QoS du réseau d’accès est inférieure à la QoS requise par la communication,

alors la négociation ne peut pas être initiée. Par exemple, il est inutile de demander un niveau de

service avec une QoS comportant un délai inférieur au délai moyen sur le réseau d’accès ou si la

communication nécessite une bande passante supérieure à celle garantie par le réseau d’accès. Dans ce

cas, si le niveau de la QoS et/ou le niveau de la sécurité peut être dégradé alors la décision est un

« non temporaire » et une demande de dégradation est envoyée au module « définition des paramètres

de QoS » et/ou « définition des paramètres de sécurité ». La détermination du type de paramètres à

dégrader (QoS, sécurité ou les deux en même temps) ne dépend que des stratégies (cf. section 4.4.4.2)

implémentées par le module MNDP. Ce mécanisme assure une sorte de négociation interne qui

permet d’ajouter une certaine « intelligence » au niveau de la composante MNDP et d’éviter une perte

de temps causée par des passes de négociation inutiles entre l’utilisateur et le reste du réseau. La

demande de dégradation peut être faite une ou plusieurs fois jusqu’à ce qu’il devient possible d’initier

la négociation ou jusqu’à ce que le niveau de service demandé ne peut plus être dégradé. Dans le

dernier cas, si d’autres réseaux sont disponibles, un changement de réseau est dans ce cas, effectué et

la négociation est retentée. Si la négociation est toujours impossible, la décision est alors un « non

159

définitif » et l’utilisateur en est informé. Dans le cas où le processus de négociation peut être lancé, la

décision de négociation est un « oui ».

• Définition des paramètres du SLS : dans le cas où la décision de négociation prise lors de l’étape

précédente est un « oui », la composante MNDP se doit de transmettre les paramètres nécessaires à la

négociation de niveau de service au générateur de SLS.

Figure 5-17 : Algorithme des traitements de la composante MNDP

5.3.6 Tests et évaluations de performances

Une fois l’implémentation de l’adaptation de la négociation SLNP à l’ubiquité des environnements

NGN réalisée, nous avons procédé à un ensemble de tests afin d’évaluer les nouvelles performances de la

négociation.


La plateforme de tests utilisée est présentée dans la Figure 5-18. Elle correspond à un scénario de

négociation impliquant trois domaines différents. Elle inclut donc les trois entités de négociation

160

représentant les responsables des trois domaines (SI, SR et SF), ainsi que la couche de négociation

représentant le terminal de l’utilisateur. Ainsi, nous avons quatre entités de négociation qui implémentent

toutes le protocole SLNP. Sur cette plateforme, les outils utilisés sont les mêmes que ceux ayant servi aux

tests décrits dans la section 4.4.5.1. En effet, les services web sont, également, déployés sur un serveur

TOMCAT et l’implémentation du protocole SOAP utilisée est AXIS. De plus, nous utilisons aussi un

serveur de bases de données MySQL pour simuler les interactions avec les RMF et les registres de SLS,

ainsi que le langage JAVA pour la programmation de tous les traitements (entités de négociation et couche

de négociation).

Figure 5-18 : Plateforme de tests du fonctionnement dans le NGN

En plus de l’application cliente et du service web, l’implémentation du client couvre le générateur de

SLS (SG), le point de décision et de mise en correspondance MNDP ainsi que ses interactions avec

l’utilisateur, l’application, le terminal et le protocole MIH.

5.3.6.1.1 Interactions avec le terminal, l’application et le protocole MIH

Les interactions de la composante MNDP avec l’application, le terminal et le protocole MIH ont été

simulées grâce à une base de données que nous avons appelée UPPD (User Profile Parameters Database).

Cette base contient trois tables correspondant aux paramètres du profil relatifs au terminal utilisé, à

l’application pour laquelle un SLS doit être établi et aux réseaux d’accès disponibles dans la zone où se

trouve l’utilisateur. Dans la table relative aux réseaux d’accès disponibles, nous avons prévu un champ qui

permet d’indiquer si le terminal est connecté à ce réseau ou non. La conception de la négociation de

niveau de service dans des environnements NGN que nous avons spécifiée, est tout à fait réaliste et n’est

pas difficile à implémenter sur des terminaux fixes ou mobiles. Mais cela nécessite, tout d’abord, de

disposer ou de réaliser une implémentation du protocole MIH. Ensuite, on doit disposer d’une sonde qui

permet d’obtenir les capacités d’un terminal et de mesurer ses performances à tout instant. En ce qui

concerne l’application concernée par la négociation, nous pouvons introduire une liste de choix dans

l’interface utilisateur afin que ce dernier puisse renseigner sur cette application.

5.3.6.1.2 Interactions avec l’utilisateur

Les interactions de la composante MNDP avec l’utilisateur doivent permettre à ce dernier d’exprimer

ses préférences (cf. section 5.3.3.1). Pour cela, nous avons implémenté une interface graphique qui permet

161

à un utilisateur de transmettre à la composante MNDP les préférences de l’utilisateur pour les niveaux de

QoS et de sécurité, ainsi que ses préférences pour le réseau d’accès (Figure 5-19).

Figure 5-19 : Interface graphique pour récupérer les préférences de l’utilisateur

Les préférences de l’utilisateur, exprimées grâce à l’interface de la Figure 5-19, correspondent à une

offre de service impliquant uniquement la QoS qui doit avoir un ‘Bon’ niveau. Le réseau d’accès doit être,

également, choisi sur la base de ses caractéristiques en termes de QoS. En effet, parmi les réseaux

disponibles, on doit choisir celui qui a le plus haut niveau de QoS.

Figure 5-20 : Préférences d’un utilisateur privilégiant la sécurité

162

Cette interface permet à un utilisateur d’exprimer ses préférences lorsque le niveau de service doit

inclure la sécurité en plus de la QoS. Par exemple, les préférences, exprimées grâce à l’interface de la

Figure 5-20, correspondent à une sécurité ‘Obligatoire’ avec un ‘Bon’ niveau pour les services Intégrité et

confidentialité. Quant aux préférences de l’utilisateur par rapport au réseau d’accès, nous pouvons voir

(Figure 5-20) que le critère de choix sélectionné par cet utilisateur est la sécurité. Notons que la section

‘Access Network’ de l’interface utilisateur est dynamique en adaptant la deuxième ligne au critère de choix

sélectionné.

5.3.6.2 Tests du fonctionnement

Les tests de fonctionnement de la nouvelle approche de négociation concernent non seulement les

échanges de messages de négociation, mais aussi la procédure de mise en correspondance entre les

paramètres de profil et les paramètres de SLS. Pour les messages échangés, nous utilisons toujours l’outil

SOAP Monitor afin de capturer et visualiser le contenu de ces messages (cf. section 4.4.5.2). Par ailleurs, le

fonctionnement de la procédure de mise en correspondance entre paramètres du profil et paramètres de

SLS a été testé pour plusieurs combinaisons de paramètres de profil correspondant à divers scénarios.

Chaque scénario correspond à une entrée dans la base UPPD associée aux préférences de l’utilisateur

rentrées via l’interface que nous avons conçue.

Etant donné que chaque combinaison entre ces deux types de paramètres (UPPD et préférences)

permet d’obtenir un SLS bien précis, nous avons essayé de prévoir les paramètres du SLS pour chaque

combinaison. Ainsi, les tests concernant la mise en correspondance se résument dans la comparaison entre

les SLS prévus et les SLS réellement obtenus.

Une fois, tous les tests correspondant aux différents scénarios réalisés avec succès, nous avons conclu

à la validité de notre implémentation. Ensuite, nous avons évalué les performances du nouveau

fonctionnement du protocole SLNP.

5.3.6.3 Evaluation du temps de négociation

Afin d’évaluer le temps de négociation et de pouvoir comparer les nouvelles performances aux

anciennes, nous effectuons des tests locaux impliquant trois domaines sur la machine que nous avons

utilisée auparavant. Ceci implique que les quatre entités, à savoir SI, SF, SR et Client, aient été déployées

sur une seule et même machine (serveur Dell Precision PWS670 avec un processeur Intel Xeon à 3,2 GHz

et une RAM de 2 Go).

Les tests réalisés visent à mesurer le temps d’une négociation de niveau de service dans un

environnement NGN impliquant trois domaines et se déroulant en une seule passe. Les résultats de ces

mesures sont comparés à ceux obtenus lors des tests réalisés dans la section 4.5.2.3. Etant donné que le

temps de négociation mesuré lors des anciens tests correspond à la durée entre l’instant où l’application

cliente de négociation de la SI commence la construction d’un message de type Negotiate et l’instant où

un message de type Response est reçu par cette entité, nous allons, cette fois ci, mesurer ce temps entre

l’instant où le client commence le processus de mise en correspondance, c’est-à-dire après avoir fini de

récupérer tous les paramètres du profil, et l’instant où il reçoit le résultat de la négociation. Comme lors

des précédents tests, le temps moyen de négociation est calculé sur la base d’un échantillon de 1000

mesures. Cependant, nous ne représentons qu’un échantillon de 100 mesures afin de mieux visualiser le

résultat des mesures réalisées (Figure 5-21).

163

Figure 5-21 : Evaluation du temps de négociation (100 essais)

Les mesures correspondant à une passe de négociation dans un environnement NGN où trois

domaines sont impliqués dans l’offre de service, permettent d’obtenir un temps moyen égal à 97,42 ms

(courbe en rouge sur Figure 5-21). Cependant, dans le cas d’une négociation classique, c’est-à-dire une

négociation qui implique uniquement les trois responsables de domaines, nous avons obtenu un temps

moyen de 62,61 (courbe en bleue sur la Figure 5-21). Notons que dans ces deux cas de négociation, les

paramètres du SLS sur lesquels porte la négociation sont identiques. En fait, nous avons choisi des

paramètres du profil de manière à ce que les paramètres du SLS obtenu suite à la procédure de mise en

correspondance dans le cas d’une négociation dans un environnement NGN soient identiques à ceux du

SLS utilisé dans les mesures du temps d’une négociation classique.

Ces mesures (Tableau 5-6) nous permettent de déduire qu’en donnant la main à l’utilisateur pour la

négociation d’une offre de service impliquant le même nombre de domaines (ici trois domaines), le temps

moyen d’une passe de négociation augmente d’une manière très importante. En effet, ce temps passe de

62,61 à 97,42 ; ce qui nous fait une augmentation d’environ 55,6 %. Cette augmentation est due,

essentiellement, à l’interaction ajoutée entre le terminal de l’utilisateur et le responsable du domaine

auquel il appartient (50 %). Le deuxième facteur d’augmentation du temps de négociation est la mise en

correspondance entre les paramètres du profil et les paramètres du SLS. Cette augmentation est estimée à

5,6 %. Par conséquent, nous pouvons constater que le temps introduit par les traitements pouvant être

ajoutées est très faible par rapport au temps nécessaire aux interactions entre les services web.

Type de négociation Temps moyen de négociation

Classique 62,61 ms

NGN 97,42 ms

Tableau 5-6 : Temps moyen de négociation

164

Notons que le pourcentage d’augmentation du temps de négociation, causée par l’adaptation aux

environnements NGN, diminue lorsque le nombre total de domaines impliqués dans une offre de service

augmente.

5.3.6.4 Evaluation de la taille des messages

Les tests permettant d’évaluer la taille des messages ont été réalisés sur la même plateforme que celle

utilisée pour mesurer le temps moyen de négociation (cf. section 5.3.6.1). Afin de mesurer la taille des

messages échangés entre les différentes entités de négociation de la plateforme, nous faisons toujours

appel à l’outil SOAP Monitor d’Apache qui permet de capturer et stocker ces messages afin de pouvoir,

ensuite, mesurer leurs tailles.

Contrairement au temps de négociation qui augmente d’une manière très importante lors de

l’adaptation aux environnements NGN, la taille des messages échangés ne connaît quasiment pas de

changement. En effet, pour une négociation d’un SLS donné, la taille des messages circulant entre la SI, la

SF et la SR est strictement la même dans les deux types de négociation (négociation « classique », et

négociation adaptée aux environnements NGN). Ceci est logique puisque, comme nous l’avons déjà dit,

nous avons fait en sorte que le SLS négocié dans les deux cas porte sur les mêmes paramètres. Cependant

si un processus de négociation est initié (Negotiate, Modify ou Release), alors le message envoyé par le

terminal du client vers la SI à une taille légèrement inférieure à celle du même message après la traversée

de la SI. Ceci est dû aux modifications auxquels la SI a procédé afin d’ajouter son offre locale. A titre

d’exemple, la Figure 5-22 illustre cette légère modification dans le cas de la mesure de la taille moyenne

d’un message Negotiate. En effet, les résultats présentés sur cette figure montrent que cette taille passe de

4894 octets à 4805 octets, ce qui représente une diminution d’environ deux pour cent de la taille initiale du

message Negotiate (1,82 %). Cette très faible diminution est, comme nous l’avons déjà précisé, due aux

champs correspondant à l’offre locale du domaine auquel appartient le terminal qui sont initialement

vides.

Figure 5-22 : Taille moyenne du message Negotiate

5.3.7 Utilisation du protocole SLNP dans un environnement NGN

Dans cette section, un exemple d’utilisation du protocole SLNP dans un environnement NGN est

fourni afin d’illustrer la négociation dynamique pour un utilisateur mobile dans un tel environnement.

165

Dans l’exemple de la Figure 5-23, le protocole SLNP sert à négocier un niveau de service pour une

communication entre un utilisateur mobile User1 et un utilisateur fixe User2. La négociation est initiée par

le terminal de User1 et implique ce dernier ainsi que les différents responsables de domaines : SI, SF et SR.

Le SLS à négocier est déterminé au niveau de la couche de négociation du terminal de User1. Plus

précisément, les paramètres du SLS sont définis par la composante MNDP en fonction des composantes

du profil de l’utilisateur User1 (Tableau 5-7).

Paramètres de l’application

Caractéristiques du réseau d’accès

Capacités du terminal Préférences de l’utilisateur

Nom : Skype

Type : ToIP

Sécurité : Non

Pair : User2

Type : 802.11

Débit : 54 Mb/s

Délai : 20 ms

Sécurité : Non

Type : Labtop

Mémoire : 512 Mo

CPU : 1,2 Go

Security : IPSec, TLS, etc.

QoS : Moyen

Sécurité : Désirée

Services de sécurité : Intégrité-Bon

Réseau d’accès : Sécurité - Bon

Tableau 5-7 : Paramètres du profil utilisateur à la position 1

Le niveau de service doit être garanti pour la communication entre User1 et User2. Il s’agit d’une

conversation de téléphonie sur IP (ToIP : Telephony over IP) naturellement non sécurisée. Initialement, le

réseau d’accès disponible AN1-1 est caractérisé par une bande passante maximale de 54 Mbit/s et un délai

moyen de 20 ms, mais il ne fournit aucun service de sécurité. L’utilisateur demande un bon niveau de

QoS, et préfère protéger l’intégrité des paquets de voix échangés au moins au niveau des mediums

ouverts. Sachant que le réseau d’accès AN1-1 auquel User1 est initialement connecté n’est pas sécurisé, le

niveau de service négocié concerne une QoS de bout en bout et inclut également une sécurité entre User1

et User2 (Tableau 5-8).

Identification de trafic

Temps de service

Scope de QoS

Garantie de performance

Scope de sécurité

Protocole de sécurité

IP@User1

IP@User2 Immediate

IP@User1

IP@User2

D = 200 ms

G = 60 ms

P = 0,5 10-2

B = 64 Kb/s

IP@User1

IP@User2

P = ipsec

Mecanism = ah

Mode = transport

A = hmac-sha1-96

Tableau 5-8 : Paramètres du SLS correspondant au profil

Le Tableau 5-8 montre les paramètres du SLS à établir pour la communication entre User1 et User2.

La qualité de service, nécessaire au bon déroulement de la communication, doit être assurée de bout en

bout entre ces deux terminaux. Ce niveau de QoS est représenté par les paramètres suivants : 200 ms de

délai, 60 ms de gigue, = 0,5 10-2 de perte de paquets et un débit de 64 Kb/s. L’intégrité des données

échangées, souhaitée par l’utilisateur, sera assurée grâce au mécanisme AH du protocole IPSec en utilisant

l’algorithme HMAC-MD5-96 supporté par les deux extrémités de la communication.

La Figure 5-23-b représente un MSC (Message Sequence Chart) simplifié qui permet de comprendre

le processus de négociation via SLNP pour cet exemple. Sur ce MSC, nous notons qu’une fois les entités

SLNP mises d’accord sur un niveau de service, la communication peut avoir lieu après la phase de

signalisation SIP.

Au cours du déplacement de l’utilisateur User1, de nouveaux réseaux d’accès peuvent être détectés

par le protocole MIH. Dans cet exemple, un réseau sans fil sécurisé grâce au mécanisme WPA est détecté.

Cette information, transmise par le standard MIH à la couche de négociation du terminal de User1, est

166

reçue par la composante MNDP qui décide, suivant les préférences de l’utilisateur en matière de

technologies d’accès, de basculer sur le réseau sans fil sécurisé récemment détecté. Cet évènement peut

déclencher, en même temps, la modification du niveau de service déjà établi afin de désactiver le niveau de

sécurité assuré par IPSec car le nouveau réseau d’accès répond déjà aux besoins de sécurité exprimés par

l’utilisateur. Dans ce cas, les ressources utilisées dans la garantie de l’offre de sécurité (délai, bande

passante, etc.) peuvent être exploitées afin de proposer à la communication de nouvelles capacités et

d’améliorer sa qualité.

a : Scénario de négociation b : Échanges SLNP

Figure 5-23 : Exemple de négociation dans un environnement NGN

Il est vrai que le protocole MIH se propose de réaliser les changements de réseaux d’accès

(handovers) tout en garantissant la continuité de service. Cependant, lorsque l’offre de ce service nécessite

la mise en place d’un accord sur ce niveau de service, le temps nécessaire à un processus de négociation

SLNP peut constituer un important obstacle à la garantie de la continuité de service. Une des solutions

que nous pouvons proposer pour pallier à ce problème, est la négociation à l’avance. En effet, il s’agit

d’ajouter une certaine « intelligence » au niveau du terminal et du réseau global afin de déterminer les

réseaux d’accès voisinant la zone où se trouve le terminal et dont la probabilité d’utilisation est très

importante. Ensuite, une négociation de niveau de service à l’avance peut être effectuée afin de réserver les

ressources de QoS requise et de mettre en place les mécanismes de sécurité nécessaires, à l’avance. La

procédure de négociation à l’avance avec le protocole SLNP est une solution réaliste qui peut être réalisée

sur la base des paramètres reliés à la mobilité (degré de mobilité, vitesse, sens de déplacement, etc.), qu’on

ajoutera au profil utilisateur, tout en se conformant, par exemple, au modèle de fonctionnement décrit

167

dans [BEN 06]. Etant donné que nous basons notre négociation sur le profil utilisateur, nous devrons

également ajouter des paramètres relatifs à la mobilité de l’utilisateur afin d’automatiser la procédure de

négociation à l’avance. Parmi ces paramètres, il peut y avoir le degré de mobilité de l’utilisateur, sa vitesse,

le sens de déplacement, etc.

5.3.8 Résumé

L’ubiquité est caractérisée par des utilisateurs mobiles devant pouvoir consommer les services offerts

par les réseaux NGN à tout moment et à partir de n’importe quel endroit en utilisant plusieurs types de

terminaux. Dans ce contexte, nous avons proposé de faire participer ces utilisateurs à la négociation de

l’offre de service en équipant leurs terminaux avec une couche de négociation permettant d’automatiser la

négociation de niveau de service de bout en bout tout en assurant le handover grâce au protocole MIH.

5.4 Conclusion

L’association de la sécurité et de la QoS dans une négociation de niveau de service est d’une grande

importance dans un environnement NGN où les utilisateurs mobiles se connectent souvent à des réseaux

sans fil peu sécurisés pour consommer des services nécessitant de bonnes garanties de QoS. Dans ce

chapitre nous avons présenté deux principales contributions reliées à ce contexte.

La première contribution représente un exemple concret de la gestion de la QoS et de la sécurité

pour un service NGN particulier. Il s’agit du service IPTV qui se fonde sur une architecture spéciale

permettant la transmission du service IPTV à des utilisateurs sans fil connectés via des réseaux Wi-Fi de

type 802.11. L’objectif de cette contribution était d’assurer un niveau du service de bout en bout couvrant

la QoS et la sécurité dans une architecture divisée en deux segments où chacun est caractérisé par son

propre mode de transmission. Ainsi, nous avons commencé par présenter les caractéristiques de cette

architecture, ainsi que les différents mécanismes mis en jeu dans la transmission des flux IPTV. Ensuite,

nous avons décrit notre proposition qui permet de gérer la QoS et la sécurité de bout en bout pour une

telle transmission. En effet, sur le premier segment de transmission, à savoir le cœur du réseau, nous

avons spécifié comment le protocole SLNP peut être utilisé pour établir un niveau de service pour tout un

groupe multicast du flux IPTV. Puis, nous avons étendu la description permise par l’UED afin de

permettre, au niveau du réseau d’accès, la consommation d’un service IPTV qui prend en compte, non

seulement la QoS, mais aussi la sécurité requises par l’utilisateur sans fil. Enfin, pour permettre de délivrer

des flux IPTV spécifiques aux besoins de chaque utilisateur, nous avons ajusté le fonctionnement du

protocole de signalisation RTSP utilisé dans la demande des flux par les utilisateurs mobiles.

La deuxième contribution propose une adaptation du protocole SLNP aux environnements NGN.

Cette adaptation permet aux utilisateurs mobiles connectés aux réseaux NGN de négocier d’une manière

automatique et optimisée les garanties requises par le service demandé. L’utilisation de la technologie des

services web a facilité cette adaptation en permettant aux utilisateurs mobiles de négocier dynamiquement

le niveau de service dont ils ont besoin. Ceci à été réalisé en introduisant une couche de négociation au

niveau du terminal de l’utilisateur permettant de fonder le processus de négociation sur le profil de

l’utilisateur. Par ailleurs, nous avons proposé d’utiliser le protocole IEEE 802.21 afin d’assurer la handover

pour les utilisateurs mobiles et de collecter des informations sur les réseaux disponibles. Ainsi, dans la

168

première partie de ce chapitre, nous avons détaillé la composition du profil utilisateur spécifié pour la

négociation SLNP. Ensuite, le fonctionnement d’une négociation fondée sur le profil a été décrit en

détaillant les composantes de la couche de négociation (au niveau d’un terminal) ainsi que les traitements

réalisés dans chacune de ces composantes. Puis, nous avons présenté les résultats des tests de

performances visant à évaluer la solution proposée et à comparer les nouvelles performances aux

anciennes. Les tests ont montré que seules les performances en termes de temps de négociation sont

dégradées à cause de l’interaction ajoutée entre le terminal de l’utilisateur et le responsable du domaine

auquel cet utilisateur est connecté. Cependant, lors de la mesure du temps de négociation les interactions

avec l’application, le terminal, le protocole MIH et l’utilisateur n’ont pas été considérées parce que les trois

premières interactions ont été simulées grâce à une base de données. Ainsi, il serait bon d’évaluer les

performances du protocole SLNP dans des conditions réelles afin de mesurer l’impact de ces différentes

interactions sur le temps de négociation. Enfin, nous avons fourni un exemple complet de négociation de

niveau de service fondée sur le profil de l’utilisateur. Ceci nous a permis de montrer l’utilité d’une telle

approche, tout en identifiant un nouveau besoin, à savoir la garantie de la continuité de service qui peut

être assurée grâce à une négociation à l’avance.

La négociation de niveau de service, permise par le protocole SLNP, utilise les services web afin de

tirer profit de l’interopérabilité de ces technologies. Néanmoins, cette technologie se fonde sur l’échange

de messages SOAP (cf. section 3.4.1.2) qui peuvent être sujets à des attaques malveillantes. Par

conséquent, il est, également, nécessaire d’étudier la sécurisation du flux de négociation SLNP et d’évaluer

les nouvelles performances du protocole de négociation sécurisé.

169

Chapitre 6

Sécurité de la négociation

assurée par le protocole SLNP

6.1 Introduction

Le protocole SLNP est un protocole de signalisation qui permet à un utilisateur de négocier, d’une

manière dynamique, le niveau d’un service avec les responsables des domaines participant au transport de

ce service. Cette négociation, portant à la fois sur la qualité de service et la sécurité (cf. section 4.4), est

fondée sur des échanges de messages SOAP car elle utilise des services web, ceci dans le but de fournir

l’interopérabilité entre les différentes entités impliqués dans une négociation. Cependant, dans le cadre

d’une négociation inter-domaines, plusieurs entités sont impliquées dans une négociation de SLS, et les

messages SOAP échangés entre ces entités 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 l’utilisateur afin de

pouvoir facilement espionner la communication, lorsque l’échange de données débute. Cela peut,

également, viser à remplacer le SLS demandé par un autre SLS qui ne correspond pas aux besoins de

l’utilisateur, dans le but de libérer des ressources qui seront utilisées par le tiers malveillant. Etant donné

que le protocole SLNP peut être utilisé dans des négociations portant sur des services critiques, les entités

de négociation doivent être capables d’établir un accord sur un niveau de service d’une manière sécurisée.

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. Pour cela, cette négociation sera sécurisée

à différents niveaux en utilisant WSS, SSL/TLS et IPSec afin de choisir la solution la plus adaptée. Nous

commençons, tout d’abord, ce chapitre par la présentation des types d’attaques spécifiques aux protocoles

de signalisation qui ont motivé notre démarche de sécurisation du protocole SLNP. Puis, nous identifions

et étudions les protocoles de sécurité qui permettent de faire face aux attaques de sécurité pouvant viser

une négociation SLNP. Après cela, la sécurisation de ce protocole est réalisée en implémentant les

différents protocoles de sécurité identifiés à savoir : IPSec, SSL/TLS et WSS. 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

protocole SLNP et de pouvoir choisir la solution la mieux adaptée. En fonction de ces résultats, nous

proposons, enfin, d’introduire une composante au niveau de la couche de négociation d’un terminal

utilisateur, afin de permettre l’optimisation de la mise en place de la sécurité du protocole SLNP.

170

6.2 Motivations

Malgré l’importance des attaques qui peuvent représenter une source de menaces pour les protocoles

de signalisation, très rares sont les protocoles qui se sont penchés sur cette question. A titre d’exemple,

nous citons le protocole de signalisation NSIS qui a spécifié les problèmes de sécurité qui peuvent être

rencontrés lors d’une signalisation dans un environnement NSIS [TSC 05]. Cette signalisation couvre les

protocoles GIMPS (General Internet Messaging Protocol for Signaling) [SCH 05b], NAT/Firewall NSLP

(A NAT/Firewall NSIS Signaling Layer Protocol) [STI 05], et le protocole de négociation de qualité de

service QoS-NSLP [BOS 05] (cf. section 3.3.2.6). Dans cette section, nous essayons d’identifier les

attaques de sécurité qui peuvent viser une négociation SLNP afin de pouvoir décider des mécanismes de

sécurité à mettre en place pour faire face à ces attaques.

La négociation de niveau de service avec le protocole SLNP peut être considérée comme une

communication entre les différentes entités impliquées dans une négociation. Ainsi, les attaques de

sécurité identifiées dans la section 2.5.1.1 peuvent représenter une source de menace pour la procédure de

négociation assurée par ce protocole SLNP. Dans ce qui suit, nous détaillons quelques scénarios

d’attaques ainsi que des attaques spécifiques au protocole SLNP.

• L’attaque de l’intercepteur : Ce type d’attaque est appelé, également, attaque de « l’homme au milieu »

(MITM : Man In The Middle). Il s’agit d’un scénario d’attaque dans lequel une entité pirate se fait

passer auprès d’une entité (généralement l’entité qui initie une négociation) pour l’entité adjacente et

suivante sur le chemin de négociation. Ainsi, l’entité pirate pourra modifier le contenu des messages

de négociation, monter des attaques par déni de service (DoS : Denial of Service), ou même voler des

services qui sont facturés à l’entité initiale. De plus, l’entité pirate est capable de répondre, elle-même,

aux requêtes SLNP envoyées par l’entité initiale, et envoyer d’autres requêtes au « vrai » vis-à-vis de

l’entité initiale. Ainsi, cette dernière aura l’impression de négocier son niveau de service avec le « vrai »

réseau, alors qu’elle s’adresse effectivement à une entité pirate. L’absence d’une authentification entre

les différentes entités de négociation ainsi que le fait que chaque entité SLNP ignore la topologie du

réseau et utilise un mécanisme de découverte afin de connaître l’adresse de la prochaine entité sur le

chemin de négociation, peuvent faciliter ce genre d’attaque.

• Rejeu des messages SLNP : Ce scénario couvre les cas où un adversaire intercepte et collecte des

messages SLNP pour les rejouer ultérieurement. En rejouant les messages capturés, avec parfois

quelques modifications, un adversaire peut monter des attaques de type MITM, déni de service, et

même vol de service. Dans un autre scénario d’attaque, un adversaire peut viser, tout d’abord, à mettre

hors-service une entité de négociation afin de lui faire perdre les informations d’état (negotiationId,

slsStatus, slsParameters, etc.). Ensuite, il pourra produire des attaques en rediffusant les messages de

négociation interceptés auparavant. Dans ce genre de scénario, l’adversaire profite des difficultés que

peut rencontrer une entité SLNP lorsqu’elle essayera de récupérer les informations d’état perdues.

• Injection ou modification de messages SLNP : Ce type d’attaques représente une menace pour l’intégrité des

messages SLNP, et couvre le réordonnancement, le retardement, la suppression, l’injection et la

troncature de messages de négociation. En effet, en modifiant le contenu des messages SLNP

(essentiellement les paramètres du SLS), un adversaire peut parvenir à provoquer l’établissement d’un

SLS différent de celui qu’à demandé l’entité initiale. Il peut, également, injecter des messages qui visent

171

à demander de très importantes ressources (éventuellement en utilisant l’identité d’un autre

utilisateur). Ainsi, les autres demandes de ressources pourront être rejetées. Cette attaque n’est

réalisable qu’en cas d’absence d’authentification et de protection d’intégrité des messages de

signalisation.

• Inondation : L’inondation consiste à envoyer une grande quantité de messages SLNP dans le seul but de

provoquer le plantage d’une entité SLNP. C’est une forme de déni de service. En effet, une entité

pirate peut inonder une « vraie » entité avec de faux messages de signalisation SLNP afin de la forcer à

effectuer un grand nombre de traitements qui consomment énormément de ressources notamment en

termes d’espace mémoire et de temps CPU. Ce qui pourrait nuire à la « vraie » entité SLNP et la

mettre hors-service.

• Usurpation d’identité : Une entité pirate peut modifier, dans les messages de négociation, la partie qui

permet d’identifier le flux sur lequel porte la négociation. Les identifiants de flux sont essentiellement

les adresses IP, le type du protocole de transport (UDP, TCP), les numéros de ports, etc. La

modification de ces paramètres dans les messages SLNP, permet à l’entité pirate d’exploiter le niveau

de service (QoS et/ou sécurité) réservé par une autre entité, ou encore de priver cette dernière du

niveau de service qu’elle a essayé de réserver.

Les scénarii décrits ci-dessus illustrent plusieurs vulnérabilités du protocole de négociation SLNP face

aux attaques de sécurité les plus menaçantes qui peuvent se produire. Cependant, il ne s’agit pas d’une liste

exhaustive des attaques pouvant avoir lieu, parce qu’il existe d’autres scénarios d’attaques. Par exemple,

lorsque la non-répudiation (cf. section 2.5.1.1) n’est pas assurée, un utilisateur peut nier avoir réservé des

ressources ou encore prétendre qu’il n’avait pas connaissance du prix proposé par le réseau. De même, le

réseau peut prétendre qu’il a reçu des demandes de réservation de la part d’un utilisateur bien particulier

même si ce dernier n’avait rien demandé, etc.

Pour faire face aux attaques que peut produire des entités malveillantes, il faut, tout d’abord,

déterminer les services de sécurité dont une négociation SLNP a vraiment besoin. Ceci permettra de

trouver, par la suite, les mécanismes ou protocoles de sécurité pouvant répondre aux besoins spécifiques

du protocole SLNP en termes de sécurisation des messages échangés lors d’une négociation.

Les services de sécurité qui permettent au protocole SLNP de résister à tout type d’attaque sont les

suivants : la confidentialité, l’authentification, l’intégrité, la non-répudiation et la protection contre le rejeu.

Cependant, le choix des services de sécurité à fournir ne dépend que des attaques contre lesquelles la

négociation doit être protégée.

6.3 Mécanismes de sécurisation du protocole SLNP

La sécurisation du protocole SLNP revient à sécuriser la communication entre les différentes entités

qui doivent participer à une négociation. Cette communication est fondée sur une invocation des services

web de négociation qui s’effectue de proche en proche entre les entités adjacentes sur un chemin de

négociation. Ainsi, pour résister aux attaques d’un tiers malveillant, il faudra sécuriser les invocations de

services web entre chaque couple d’entités SLNP qui doivent directement interagir lors d’une procédure

de négociation.

172

Le niveau dans lequel opère le protocole SLNP, à savoir la couche applicative, nous donne plusieurs

options pour la sécurisation de la négociation assurée par ce protocole. En effet, les échanges entre les

services web peuvent être sécurisés (confidentialité, authentification, intégrité, non-répudiation et/ou

protection contre le rejeu), d’une manière transparente, au niveau de la couche « Transport » grâce au

protocole SSL/TLS, ou encore au niveau « Réseau » en mettant en œuvre le protocole IPSec (Figure 6-1).

Par ailleurs, d’autres standards de sécurité ont été développés spécialement pour protéger les

communications entre les services web. En effet, ces communications peuvent impliquer de multiples

entités où chacune d’elles peut avoir besoin d’accéder à certaines parties du message et où l’accès à

d’autres parties peut lui être interdit. Ce degré de finesse dans la spécification des parties à protéger dans

un message échangé et le choix des entités concernées par ces parties à protéger, ne peut pas être atteint

avec les protocoles SSL/TLS ou IPSec, car ces derniers permettent de sécuriser une communication entre

deux extrémités d’un bout à l’autre.

Figure 6-1 : Les standards de sécurisation des services web

Contrairement aux protocoles IPSec et SSL/TLS qui protègent les données échangées entre les

services web respectivement au niveau « Réseau » et au niveau « Transport », les standards de sécurité

XML, à savoir XML Encryption et XML Signature, permettent de sécuriser les messages XML échangés

entre ce type d’applications (services web) au niveau « Application ». Pour assurer la sécurisation des

messages SOAP (qui ne sont autres que des documents XML) échangés entre les services web (WS : Web

Services), des standards ont été spécifiés. Parmi ces standards, nous trouvons le standard WS Security qui

se base sur XML Signature et XML Encryption dans le but de protéger les messages SOAP. Par ailleurs,

d’autres standards ont été développés autours des services web tels que : WS ReliableMessaging qui

permet d’assurer la fiabilité de la transmission des messages SOAP, WS-Trust et WS-SecureConversation

qui sont utilisés pour définir des environnements de confiance, WS Addressing qui définit les propriétés

d’adressage des messages SOAP, WS Policy qui permet de définir des politiques de sécurité, etc. (Figure

6-1). Notons qu’il existe d’autres standards qui peuvent être utilisés dans le but d’assurer des services de

sécurité pour les échanges entre les services web, mais qui ne sont pas exclusifs aux services web. Parmi

ces standards, nous citons XACML (eXtensible Access Control Markup Language) [MOS 05] et SAML

173

(Security Assertion Markup Language) [CAN 05] qui peuvent assurer le contrôle d’accès en permettant la

définition des politiques nécessaires.

Etant donnée que les protections assurées par les protocoles SSL/TLS et IPSec ont été détaillées

dans la section 2.5.2, une étude des standards de sécurité spécialement conçus pour les services web a été

réalisée. Celle-ci est présentée dans l’annexe 0 afin de ne pas trop charger le contenu de ce chapitre.

Ainsi, le flux de négociation échangé entre les différentes entités SLNP peut être sécurisé de trois

manières différentes ; nous pouvons utiliser IPSec, SSL/TLS ou encore WSS. Pour renforcer la sécurité,

nous pouvons même empiler des mécanismes de sécurité à différents niveaux comme par exemple : TLS

sur IPSec, WSS sur TLS, WSS sur TLS sur IPSec, etc. Dans les deux sections qui suivent, nous nous

penchons sur la mise en œuvre de la sécurité du protocole SLNP ainsi que sur l’étude du coût de cette

sécurité, c’est-à-dire son impact sur les performances de la négociation. En effet, dans la section 6.4 nous

décrivons la mise en œuvre de la sécurité du protocole SLNP au niveau applicatif en implémentant la

spécification WSS. Ensuite, des tests de fonctionnement et d’évaluation des performances de ce type de

sécurité sont réalisés et les résultats de ces tests sont présentés. Dans la section 6.5, nous mettons en

œuvre la sécurité de la négociation aux niveaux « Transport » et « Réseau » tout en évaluant les

performances de ces sécurités afin d’établir une comparaison des performances de la négociation en

fonction des trois types de sécurité que nous avons testés.

6.4 Sécurité du protocole SLNP au niveau « Application » (WSS)

Les services de sécurité que nous voulons offrir au flux de négociation SLNP sont l’intégrité,

l’authentification, la non-répudiation et la confidentialité. Le protocole SLNP utilise les services web afin

d’assurer l’échange de messages de négociation qui ne sont autres que des messages SOAP. Par

conséquent, la sécurité de cette négociation peut être assurée au niveau applicatif grâce à la spécification

WSS qui représente le standard le plus adapté pour répondre aux besoins du protocole de négociation en

termes de sécurité. En effet, comme nous l’avons déjà vu (cf. section 6.3), la spécification WSS permet

d’assurer l’intégrité, l’authentification et la non-répudiation pour les messages SOAP grâce à l’utilisation du

standard XML Signature et des entêtes de sécurité WSS contenant les jetons de sécurité. De la même

manière, la spécification WSS peut assurer la confidentialité des messages SOAP échangés entre les entités

de négociation, en faisant appel au standard XML Encryption et aux jetons de sécurité inclus dans les

entêtes WSS et qui permettent de transmettre les informations nécessaires au chiffrement ou au

déchiffrement de ces messages.

6.4.1 Implémentation de la spécification WSS

L’implémentation du protocole SLNP, que nous avons déjà réalisée, est fondée essentiellement sur :

Tomcat comme serveur d’application, Axis en tant qu’implémentation du protocole SOAP et Java comme

langage de programmation (cf. section 4.4.4). Vu la nature de ces éléments caractérisant l’implémentation

dont nous disposons, le choix de l’implémentation de WSS s’est naturellement porté vers WSS4J (Web

Services Security for Java) [ASF 09]. En effet, WSS4J est une bibliothèque Java permettant d’implémenter

la spécification WSS dans un environnement Tomcat-Axis. Développée par la fondation Apache (comme

Tomcat et Axis), cette bibliothèque permet d’intégrer facilement la sécurité WSS dans un environnement

174

d’échange de messages SOAP fondé sur Axis. Dans cette partie, nous allons décrire le principe de

fonctionnement de WSS4J, avant de détailler la mise en œuvre de WSS4J afin de permettre la sécurisation

du protocole SLNP avec WSS.

6.4.1.1 Principe de fonctionnement de WSS4J

Afin de fournir des services de sécurité aux messages SOAP, des opérations de sécurité doivent être

appliquées à ces messages au niveau des extrémités qui les échangent. Dans le cadre d’une sécurité WSS,

ces opérations peuvent être décrites par l’API WSS4J en utilisant des handlers implémentés en Java.

Ensuite, les appels à ces handlers sont placés dans les descripteurs de déploiement de WSS4J, à savoir les

fichiers WSDD (Web Service Deployment Descriptors) ; dont un exemple est fourni dans la Figure 6-2.

Ces descripteurs de déploiement sont utilisés afin de décrire les mesures de sécurité à appliquer sur chaque

entité. WSS4J utilise, respectivement, les éléments « requestFlow » et « responseFlow » (Figure 6-2) dans

les fichiers de déploiement pour spécifier le sens du flux du message SOAP auquel des traitements de

sécurité doivent être associés. Cette association est réalisée grâce à un élément « handler » qui peut avoir

pour type un des deux principaux types définis par WSS4J : WSDoAllReceiver et WSDoAllSender.

Chaque élément « handler » doit contenir un ou plusieurs paramètres permettant de décrire les opérations

de sécurité devant être effectuées. Les opérations de sécurité sont qualifiées grâce au paramètre ‘action’ de

l’élément « handler ». La valeur de ce paramètre peut être, soit "UsernameToken" pour indiquer l’insertion

d’un jeton de sécurité de type UsernameToken dans l’entête de sécurité WSS (cas de l’exemple de la Figure

6-2), soit "Timestamp" pour indiquer l’insertion d’un Timestamp dans l’entête WSS, soit "Encrypt" pour

spécifier un chiffrement ou soit "Signature" pour indiquer une signature. Ensuite, le paramètre ‘user’

définit le nom d’utilisateur nécessaire pour l’authentification. Puis, on peut trouver le paramètre

‘passwordCallbackClass’ qui spécifie une classe implémentant une méthode pour récupérer le mot de

passe (il s’agit de la classe PWCallback dans le cas de l’exemple de la Figure 6-2). Notons que ce mot de

passe est rattaché au nom d’utilisateur spécifié par le paramètre ‘user’.

<deployment xmlns="…/wsdd/" xmlns:java="…/java"> <transport name="http" pivot="java:org.apache.axis.transport.http.HTTPSender"/> <globalConfiguration > <requestFlow > <handler type="java:org.apache.ws.axis.security.WSDoAllSender" > <parameter name="action" value="UsernameToken"/> <parameter name="user" value="wss1user"/> <parameter name="passwordCallbackClass" value="PWCallback"/> <parameter name="passwordType" value="PasswordDigest"/> </handler> </requestFlow > <responseFlow> <handler type="java:org.apache.ws.axis.security.WSDoAllReceiver"> <parameter name="passwordCallbackClass" value="PWCallback"/> <parameter name="action" value="UsernameToken Timestamp Encrypt"/> <parameter name="decryptionPropFile" value="crypto-encrypt.properties" /> </handler> </responseFlow> </globalConfiguration > </deployment>

Figure 6-2 : Exemple d’un fichier de déploiement WSDD

175

Dans l’exemple de la Figure 6-2, nous avons un service web dont l’accès nécessite (élément

« requestFlow ») une authentification en fournissant un identifiant et un mot de passe haché (type =

"PasswordDigest"). Quant à la réponse retournée par ce service web (élément "responseFlow"), elle

nécessite la validation d’une authentification basée sur un jeton de sécurité de type "UsernameToken"

accompagné d’un "Timestamp". Notons que certaines parties du message retourné sont chiffrées

("Encrypt") et que les éléments permettant le déchiffrement sont contenus dans un fichier nommé

"crypto-encrypt.properties".

Ainsi, pour chaque entité SLNP, il nous faudra utiliser les handlers prévus par WSS4J afin de décrire

dans des fichiers wsdd quelles opérations de sécurité doivent être effectuées et sur quelles parties des

messages SLNP ces opérations doivent porter.

6.4.1.2 Configuration de la sécurité WSS au niveau des entités SLNP

Comme nous pouvons le remarquer à travers la description du fonctionnement de WSS4J,

l’implémentation de la sécurité WSS est transparente par rapport à l’implémentation des entités SLNP

(application cliente et service web de négociation). Ainsi, dans cette section, nous verrons que la mise en

place de cette sécurité n’a aucun impact sur l’implémentation du protocole SLNP que nous avons décrite

dans les chapitres précédents.

Le fonctionnement de la négociation SLNP se base sur une invocation récursive des services web de

négociation permettant, ainsi, une circulation de proche en proche des messages SLNP. Ceci fait qu’une

entité initiale ou finale est concernée par un seul ensemble de propriétés de sécurité associé à l’échange

avec l’entité suivante ou précédente, alors qu’une entité intermédiaire utilise deux ensembles de propriétés

de sécurité ; échanges avec l’entité précédente et l’entité suivante.

6.4.1.2.1 Une entité initiale

Une entité initiale est concernée par une sécurité qui caractérise ses échanges avec la première entité

intermédiaire sur le chemin de négociation. Ainsi, la seule modification à apporter à l’implémentation

d’une entité initiale est de définir un fichier de déploiement qui permet de décrire les opérations de

sécurité devant être effectuées pour ses messages échangés avec la première entité intermédiaire. Ensuite,

ce fichier sera appelé lors de l’invocation du service web de négociation de cette entité intermédiaire. Le

contenu du fichier de déploiement dépend uniquement des services de sécurité désirés. A titre d’exemple,

le fichier de déploiement donné dans la Figure 6-3 montre que lorsque l’entité initiale (correspond à

"wss1user") veut émettre un message vers la première entité intermédiaire (correspond à "wss2user"), elle

doit satisfaire les propriétés de sécurité décrite par l’élément « requestFlow ». Elle doit, ainsi, s’authentifier

en utilisant un UsernameToken et un Timestamp et chiffrer des éléments du message, comme décrit par le

paramètre "action". Le paramètre " encryptionParts" indique que le chiffrement effectué par l’entité

initiale doit porter sur les éléments "UsernameToken", "Timestamp" et "Body". Les propriétés de sécurité

requises pour la réponse sont, quant à elles, décrites par l’élément « responseFlow ». Cette description

indique que la réponse nécessite, également, une authentification fondée sur un "UsernameToken", un

"Timestamp" et un chiffrement.

<deployment xmlns="…wsdd/" xmlns:java="…java"> <transport name="http" pivot="java:org.apache.axis.transport.http.HTTPSender"/> <globalConfiguration >

176

<requestFlow > <handler type="java:org.apache.ws.axis.security.WSDoAllSender" > <parameter name="action" value="UsernameToken Timestamp Encrypt"/> <parameter name="user" value="wss1user"/> <parameter name="passwordCallbackClass" value="PWCallback"/> <parameter name="passwordType" value="PasswordDigest"/> <parameter name="encryptionUser" value="wss2user"/> <parameter name="encryptionPropFile" value="crypto-encrypt.properties" /> <parameter name="encryptionParts" value="{Element}{http://docs.oasisopen.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd} UsernameToken; Body ; {Element} {http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd}Timestamp" /> </handler> </requestFlow > <responseFlow> <handler type="java:org.apache.ws.axis.security.WSDoAllReceiver"> <parameter name="passwordCallbackClass" value="PWCallback"/> <parameter name="action" value="UsernameToken Timestamp Encrypt"/> <parameter name="decryptionPropFile" value="crypto-encrypt.properties" /> </handler> </responseFlow> </globalConfiguration > </deployment>

Figure 6-3 : Exemple de descripteur de déploiement d’une partie cliente

Les éléments requis pour les traitements de sécurité au niveau de l’entité initiale (certificats,

algorithmes, clés, etc.) sont contenus dans le fichier crypto-encrypt.properties. Comme le montre la Figure

6-4, ce fichier peut contenir les paramètres nécessaires pour accéder aux certificats ainsi que la manière de

les localiser et de les extraire des magasins de certificats (localisation de ces magasins de certificats, mots

de passe pour y accéder, certificats à utiliser et bibliothèque java pour la gestion de ces opérations, etc.).

org.apache.ws.security.crypto.provider=org.apache.ws.security.components.crypto.Merlin org.apache.ws.security.crypto.merlin.keystore.type=jks org.apache.ws.security.crypto.merlin.keystore.password=wssecpass org.apache.ws.security.crypto.merlin.keystore.alias=wss1user org.apache.ws.security.crypto.merlin.alias.password=wss1pass org.apache.ws.security.crypto.merlin.file=wssecstore.jks

Figure 6-4 : Exemple de fichier de propriétés (crypto-encrypt.properties)

Une fois la sécurité WSS configurée au niveau de l’entité initiale afin de lui permettre d’envoyer et de

recevoir des messages sécurisés, il nous reste à configurer la même sécurité au niveau des entités

intermédiaires.

6.4.1.2.2 Une entité intermédiaire

Rappelons qu’une entité intermédiaire à une situation particulière dans l’architecture du protocole de

négociation. En effet, ce type d’entité est à la fois fournisseur d’un service web pour l’entité précédente sur

le chemin de négociation (entité initiale ou une autre entité intermédiaire), et client d’un service web fourni

par l’entité suivante (une autre entité intermédiaire ou l’entité finale). Ainsi, sécuriser une négociation

SLNP avec WSS au niveau d’une entité intermédiaire revient à configurer deux sécurités WSS : une avec

l’entité précédente et l’autre avec l’entité suivante.

177

Si nous nous intéressons à la sécurité relative à l’interaction d’une entité intermédiaire avec l’entité

suivante sur le chemin de négociation, alors il s’agit d’un échange dans lequel l’entité intermédiaire

considérée joue le rôle d’une application cliente qui invoque une des opérations contenues dans le service

web de l’entité suivante. Pour cet échange, la procédure de configuration de la sécurité WSS est la même

que celle effectuée au niveau de l’entité initiale pour ses échanges avec la première entité intermédiaire. En

effet, nous devons, également, créer un fichier de déploiement, caractérisant la sécurité entre cette entité

intermédiaire et l’entité qui la suit. Ce fichier sera appelé lors de l’invocation du service web de l’entité

suivante sur le chemin de négociation.

Maintenant, nous nous intéressons à la sécurité des interactions entre une entité intermédiaire et

l’entité qui la précède. Cette sécurité concerne un échange impliquant le service web de négociation de

l’entité intermédiaire considérée. Pour configurer la sécurité des messages en provenance d’une entité

précédente, il suffit d’ajouter au fichier de déploiement de l’implémentation originelle du service web de

l’entité intermédiaire les modifications présentées dans la Figure 6-5. Sur cette figure, nous pouvons

distinguer les deux éléments ajoutés au fichier de déploiement d’origine ; l’élément « requestFlow » et

l’élément « responseFlow ». La partie représentée par l’élément « requestFlow » contient les informations

de sécurité nécessaires aux traitements des messages sécurisés reçus (requêtes), tandis que, la partie

représentée par l’élément « responseFlow » permet de sécuriser les messages retournés en tant que

réponses aux requêtes reçues.

<service name="NegotiationServicePort2Secure" provider="java:RPC" style="document" use="literal"> <requestFlow> <handler type="java:org.apache.ws.axis.security.WSDoAllReceiver"> <parameter name="passwordCallbackClass" value="PWCallback"/> <parameter name="action" value="UsernameToken Timestamp Encrypt"/> <parameter name="decryptionPropFile" value="server_crypto.properties" /> </handler> </requestFlow> <responseFlow > <handler type="java:org.apache.ws.axis.security.WSDoAllSender" > <parameter name="action" value="UsernameToken Timestamp Encrypt"/> <parameter name="user" value="wss2user"/> <parameter name="passwordCallbackClass" value="PWCallback"/> <parameter name="passwordType" value="PasswordDigest"/> <parameter name="encryptionUser" value="wss1user"/> <parameter name="encryptionPropFile" value="server_crypto.properties" /> <parameter name="encryptionParts" value="{Element}{http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd} UsernameToken; {Element}{http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd}Timestamp" /> </handler> </responseFlow > <parameter name="wsdlTargetNamespace" value="urn:WSNegotiation2"/> ...... </service>

Figure 6-5 : Exemple de descripteur de déploiement d’une partie serveur

6.4.1.2.3 Une entité finale

L’entité finale est concernée par une seule sécurité WSS. Cette sécurité est relative à la

communication entre cette entité finale et l’entité précédente qui constitue la dernière entité intermédiaire

178

sur le chemin de la négociation. Dans les échanges de cette communication, l’entité finale joue le rôle de

fournisseur de service. Les opérations contenues dans le service web de négociation fourni par l’entité

finale sont invoquées par l’entité précédente. La configuration de la sécurité WSS entre l’entité finale et

l’entité intermédiaire s’effectue de la même manière que celle de la sécurité entre l’entité intermédiaire et

l’entité initiale. En effet, nous devons, également, ajouter au fichier de déploiement de l’implémentation

originelle du service web de l’entité finale les éléments « requestFlow » et « responseFlow » afin de

caractériser le niveau de sécurité ainsi que les traitements de sécurité nécessaires.

Notons que pour avoir le même niveau de sécurité pour une négociation SLNP de bout en bout,

nous devons prendre soin de fournir les mêmes services de sécurité tout au long du chemin de la

négociation en utilisant toujours les mêmes paramètres de sécurité (certificats, jetons, algorithmes, clés,

etc.).

6.4.2 Tests et résultats

Une fois la sécurité du protocole SLNP en utilisant WSS4J mise en place, nous pouvons réaliser des

tests visant à mesurer les performances du protocole SLNP sécurisé au niveau applicatif afin d’évaluer le

coût de l’introduction de la sécurité WSS. Ainsi, dans cette section, nous commençons par décrire la

plateforme de tests. Ensuite, nous décrivons la procédure qui nous a permis de tester le fonctionnement

de la sécurisation WSS du protocole SLNP. Enfin, nous procédons aux tests permettant d’évaluer l’impact

de cette sécurité sur les performances du protocole de négociation.


Pour tester la sécurité WSS mise en place, nous faisons appel à la plateforme que nous avons utilisée

dans les tests de performances du protocole SLNP (cf. section 4.4.5.1). Cette plateforme (Figure 4-26) est

constituée de trois entités de négociation (SI, SF et SR) implémentant toutes le protocole SLNP. Elle

permet d’effectuer des tests locaux où les trois entités sont déployées sur une même machine (un serveur

Dell Precision PWS670 avec un processeur Intel Xeon à 3,2 GHz et une RAM de 2 Go). Cependant, nous

configurons sur cette plateforme une sécurité WSS au niveau de chacune des trois entités qu’elle

comprend afin de sécuriser les échanges relatifs à la négociation dans les deux sens.

6.4.2.2 Tests de fonctionnement

Afin de vérifier la sécurisation du protocole SLNP avec la spécification WSS, nous procédons à la

visualisation des différents messages échangés au cours d’une négociation. L’application SOAPMonitor,

que nous avons utilisée jusque là dans la capture et la visualisation des messages SLNP échangés entre les

entités de négociation, ne permet pas de visualiser l’intégralité des messages SOAP échangés afin de

vérifier les entêtes de sécurité et le résultat des opérations de sécurité comme le chiffrement et la signature.

Ainsi, pour visualiser les échanges sécurisés entre les trois entités de négociation déployées sur notre

plateforme de tests, nous avons dû avoir recours à l’outil TCPMon (TCP Monitor) [ASF 06] également

fourni par Apache. Pour cela, nous apportons quelques modifications au fonctionnement des invocations

des services web de négociation entre ces entités. En effet, au lieu d’appeler directement le service web de

l’entité suivante en utilisant le port 8080, nous faisons passer ces appels par TCPMon en redirigeant les

requêtes http envoyées par la SI et la SF, respectivement, vers les ports 9090 et 9393 qui sont utilisés par

TCPMon (Figure 6-6).

179

Figure 6-6 : Modèle de communication pour les tests de fonctionnement

Par conséquent, en visualisant les messages circulant entre les trois entités, nous nous assurons du

bon fonctionnement de la sécurité WSS. Par ailleurs, nous fournissons en annexe 0 un exemple de

message SOAP sécurisé avec WSS. Ce message a été capturé lors d’une négociation de niveau de service

via SLNP et comprend des commentaires afin de fournir des explications concernant la majorité des

éléments de ce message. Sur cet exemple, nous retrouvons l’entête de sécurité WSS « Security » qui permet

de décrire les opérations de sécurité mises en œuvre. Cet entête indique l’utilisation d’un élément

"Usernametoken" et d’un élément "Timestamp" qui sont tous deux chiffrés en utilisant l’algorithme

"aes128-cbc" et une clé symétrique ; elle-même chiffrée en utilisant l’algorithme "RSA-1.5" et la clé

publique de la SF. Nous pouvons constater sur cet exemple que le corps du message SOAP est signé afin

de protéger l’intégrité de cette partie du message.

6.4.2.3 Tests d’évaluation des performances en fonction du niveau de sécurité

Après avoir validé le bon fonctionnement du protocole SLNP sécurisé au niveau applicatif en

utilisant WSS, nous nous intéressons à l’évaluation des nouvelles performances de la version sécurisée de

la négociation afin de la comparer à celles de la version non sécurisée. Pour cela, nous identifions quelques

scénarios de sécurité. Chacun de ces scénarios, résumés dans le Tableau 6-1, correspond à un niveau de

sécurité pouvant répondre à de réels besoins en matière de sécurité.

Scénario Caractéristiques de la sécurité WSS

S0 Sans sécurité

S1 Authentification simple (username token et mot de passe)

S2 Authentification forte (username token et timestamp chiffrés)

S3 Authentification forte et intégrité (signature du message)

S4 Authentification forte et confidentialité (chiffrement de message)

S5 Authentification forte, intégrité et confidentialité

Tableau 6-1 : Les différents scénarios de sécurité WSS

• Sans sécurité (S0) : Ce scénario correspond à la version d’origine du protocole SLNP qui n’offre aucun

service de sécurité à la négociation assurée par ce protocole.

180

• Authentification simple (S1) : Il s’agit du scénario correspondant à la sécurité la plus simple que nous

avons testée. Cette sécurité réalise une authentification fondée sur la validation d’un simple couple

d’éléments composé d’un UsernameToken et d’un PasswordDigest.

• Authentification forte (S2) : Ce scénario correspond à une authentification fondée sur la validation du

couple UsernameToken et PasswordDigest, complété d’un Timestamp. Notons que, dans le cas d’une

authentification forte, ces trois éléments sont chiffrés en utilisant un algorithme de chiffrement et une

clé symétrique, elle-même, chiffrée en utilisant l’algorithme RSA-1.5 (le seul algorithme pour

chiffrement de clés supporté par WSS4J) et la clé publique du service web de destination. L’algorithme

utilisé pour chiffrer les trois éléments utilisés dans l’authentification peut être AES_128 (algorithme

utilisé par défaut avec WSS4J), AES_192, AES_256, ou TripleDES.

• Authentification forte et intégrité du corps du message (S3) : Ce scénario de sécurité correspond à une

authentification forte à laquelle on ajoute l’intégrité du corps du message. En effet, le corps du

message est signé à l’aide de la clé privée de l’émetteur. L’algorithme de signature utilisé par défaut

dans une implémentation WSS4J, est l’algorithme SHA1-RSA. Notons qu’avec une implémentation

WSS4J, la signature du corps du message du coté de l’émetteur implique, obligatoirement, la

confirmation de cette signature dans le message de réponse généré par le destinataire.

• Authentification forte et confidentialité du corps du message (S4) : Dans ce scénario, outre le chiffrement des

éléments UsernameToken, PasswordDigest et Timestamp, requis par l’authentification forte, une

autre opération de chiffrement est effectuée. Cette deuxième opération de chiffrement porte sur le

corps du message SOAP et vise à assurer la confidentialité aux messages SLNP échangés. Ce

chiffrement fait appel à l’algorithme utilisé par défaut avec WSS4J, c’est-à-dire l’algorithme AES-128.

• Authentification forte, intégrité et confidentialité du corps du message (S5) : Ce dernier scénario assure une

authentification forte tout en protégeant l’intégrité et la confidentialité du corps des messages SLNP.

Ensuite, nous présentons dans les sections 6.4.2.3.1 et 6.4.2.3.2 les mesures liées aux performances du

protocole de négociation (temps de négociation et taille des messages). Ces mesures nous permettent

d’évaluer l’impact de la sécurité WSS sur les performances du protocole de négociation pour chacun des

scénarios identifiés.

6.4.2.3.1 Evaluation du temps de négociation

Dans cette partie, nous évaluons l’impact de la sécurité assurée par WSS sur les temps de négociation.

Pour éviter de perturber les mesures du temps de négociation, nous désactivons la redirection des

invocations vers TCPMon qui nous a permis de vérifier le bon fonctionnement de la sécurité WSS, et qui

nous permettra, par la suite, de capturer les messages afin d’évaluer leurs tailles. Les mesures du temps de

négociation, effectuées en utilisant la plateforme décrite ci-dessus, concernent chacun des six scénarios

identifiés. Pour chacun de ces scénarios, nous réalisons un échantillon de 1000 mesures afin d’évaluer le

temps moyen de négociation (Tableau 6-2). Cependant, sur la Figure 6-7, nous ne représentons qu’un

échantillon de 100 mesures afin de mieux visualiser le résultat des mesures que nous avons réalisées en

permettant de distinguer plus facilement les différentes courbes de mesures. Le temps de négociation est

toujours mesuré entre le moment où l’application cliente de la SI construit la requête (Negotiate) et le

moment où elle reçoit la réponse (Response ou Revision) pour une seule passe de négociation.

181

Scénario Temps moyen de négociation (ms) Taille moyenne des messages (octets)

S0 62,61 3749

S1 81,62 4427

S2 151,43 7300

S3 204,64 8710

S4 164,16 9235

S5 217,26 10623

Tableau 6-2 : Impact de la sécurité WSS sur les performances du protocole SLNP

Les mesures du temps de négociation montrent que ce temps augmente lorsque la sécurité est fournie

(Figure 6-7 et Tableau 6-2). Ceci est dû aux traitements additionnels effectués par les différentes entités,

telles que l’authentification, le chiffrement, le déchiffrement, le calcul de la signature, la validation de la

signature, etc. En effet, nous constatons qu’une authentification simple (scénario S1) augmente de 30% le

temps moyen de négociation par rapport à une négociation non sécurisée (scénario S0) ; parce qu’elle

nécessite uniquement l’ajout d’un élément UsernameToken dans l’entête de sécurité. L’authentification

forte (scénario S2) augmente, quant à elle, de 180% ce temps car elle nécessite, non seulement, l’ajout des

éléments UsernameToken et Timestamp dans l’entête de sécurité, mais aussi le chiffrement de ces

éléments. Si en plus de l’authentification forte, nous souhaitons assurer la confidentialité du corps du

message (scénario S4), le temps moyen de négociation augmente de manière sensible. En effet, ce qui est

coûteux en termes de temps de traitements, c’est le chiffrement d’une clé en utilisant un algorithme

asymétrique requis par l’authentification forte, alors que le chiffrement et le déchiffrement des éléments

d’entête (UsernameToken et Timestamp) ou du corps du message mettant en œuvre un algorithme à clé

symétrique sont relativement rapides à exécuter. Par contre, il est clair que les opérations de signature du

corps du message et de vérification de signature (requises dans le scénario S3) sont plus coûteuses que les

opérations de chiffrement et de déchiffrement du corps du message (nécessitées dans le scénario S4) en

termes de temps des traitements comme décelées lors de l’évaluation de la sécurité des services web dans

[CHE 07].

Figure 6-7 : Evaluation du temps de négociation (100 essais)

182

6.4.2.3.2 Evaluation de la taille des messages

Pour évaluer l’impact des différents scénarios de sécurité WSS sur la taille des messages SOAP

échangés lors d’une négociation SLNP, nous mesurons la taille des messages de type Negotiate circulant

entre la SI et la SF. Pour cela, nous utilisons l’outil TCP Monitor. Les mesures effectuées montrent que la

taille de ce type de message augmente lors de l’introduction d’une sécurité WSS (Figure 6-8 et Tableau

6-2). Ceci s’explique par l’introduction des entêtes de sécurité dont la taille dépend des services de sécurité

fournis et des mécanismes mis en place. Si nous prenons comme référence la taille d’un message non

sécurisé correspondant au scénario S0, alors l’authentification simple (scénario S1) augmente légèrement la

taille moyenne du message Negotiate (18 %) parce que l’entête de sécurité ajouté ne contient que l’élément

UsernamToken. Toutefois, l’authentification forte (scénario S2) augmente presque deux fois la taille du

message (95%) parce qu’en plus des éléments UsernameToken et Timestamp, l’entête de sécurité

comprend toutes les informations requises pour le chiffrement de ces deux éléments, tels que les

algorithmes et les clés. Les protections de l’intégrité et de la confidentialité du corps du message en plus de

l’authentification forte (respectivement scénario S3 et scénario S4) augmentent plus modérément la taille

du même message Negotiate ; nous mesurons respectivement des augmentations de 132 % et de 146 %

par rapport à la taille de référence (scénario S0). Ceci s’explique par le fait que les tailles des valeurs de la

signature et du résultat du chiffrement ne sont pas aussi importantes que les autres informations

comprises dans les entêtes de sécurité telles que les références aux parties protégées, les algorithmes et les

clés utilisés, etc. Enfin, la taille des messages peut augmenter de 183% lorsqu’en plus d’une

authentification forte, l’intégrité et la confidentialité du corps du message Negotiate sont assurées

(scénario S5).

Figure 6-8 : Evaluation de la taille des messages

L’évaluation du coût de la sécurité WSS sur les performances du protocole SLNP pour les différents

scénarios identifiés nous permet de déduire que ce coût ne dépend que du nombre des services de sécurité

offerts par WSS. Le choix du scénario de sécurité à mettre en place ne peut pas être fondé sur le coût de la

sécurité, car il doit dépendre uniquement des besoins des parties négociantes en matière de sécurité.

Cependant, les entités de négociation peuvent choisir l’algorithme à utiliser pour offrir un service de

sécurité donné. Ainsi, nous essayons de voir si le choix de l’algorithme utilisé pour offrir un service de

sécurité avec WSS peut influencer l’impact de la sécurité sur les performances du protocole SLNP.

183

6.4.2.4 Tests d’évaluation des performances en fonction de l’algorithme utilisé

Afin de vérifier si le choix de l’algorithme utilisé dans l’offre d’un service de sécurité peut influencer

les performances de la négociation, nous allons considérer la confidentialité du corps de message SOAP

qui peut être assurée grâce à un algorithme de chiffrement symétrique. L’implémentation WSS4J de la

spécification WSS offre la possibilité d’utiliser quatre algorithmes différents pour le chiffrement des parties

du corps d’un message SOAP. Ces quatre algorithmes sont : AES-128 (algorithme utilisé par défaut),

AES-192, AES-256 et TripleDES. Ainsi, nous considérons, à titre d’exemple, le scénario S4 permettant

d’offrir l’authentification forte et la confidentialité du corps du message. En se basant sur ce scénario,

nous évaluons les performances de la négociation (temps moyen de négociation et taille moyenne des

messages) en jouant sur l’algorithme de chiffrement utilisé dans l’offre de la confidentialité (Tableau 6-3).

Type de sécurité Temps moyen de

négociation

Taille moyenne

des messages

Authentification forte + Chiffrement (cbc-3des) 170,91 ms 9183 octets

Authentification forte + Chiffrement (cbc-aes-128) 164,16 ms 9235 octets



Tableau 6-3 : Impact sur les performances suivant l’algorithme de chiffrement

6.4.2.4.1 Evaluation du temps moyen de négociation

Pour évaluer le temps de négociation en fonction de l’algorithme utilisé dans le chiffrement, nous

réalisons un ensemble de 1000 tests pour chaque type de sécurité en utilisant toujours la même plateforme.

Les résultats de ces tests, présentées dans le Tableau 6-3, montrent que le temps moyen de négociation est

quasiment le même pour les algorithmes AES-128, AES-192 et AES-256 (entre 164 ms et 165 ms), et qu’il

est très légèrement supérieur dans le cas de l’utilisation de l’algorithme TripleDES (environ 171 ms).

6.4.2.4.2 Evaluation de la taille moyenne des messages

Pour mesurer la taille des messages de type Negotiate échangés entre la SI et la SF, nous utilisons

toujours l’outil SOAP Monitor. Les résultats des mesures de la taille moyenne des messages montrent que

cette taille est la même (égale à 9235 ms) lorsqu’on fait appel à un des algorithmes suivants : AES-128,

AES-192 et AES-256. Ceci est dû au fait que le taille du résultat du chiffrement utilisant l’algorithme AES

ne dépend pas de la longueur des clés utilisées (128, 192 ou 256 bits). En revanche, cette taille varie

légèrement, passant à 9183 octets, lorsque l’algorithme TripleDES est utilisé.

Ainsi, nous pouvons en conclure que le choix de l’algorithme de chiffrement, utilisé dans l’offre de la

confidentialité aux flux de négociation SLNP, influe très peu sur les performances du protocole SLNP.

Par conséquent, le choix de l’algorithme à utiliser n’a, quasiment, pas d’impact sur les performances.

6.4.3 Résumé

Dans la section 6.4, nous avons décrit la procédure qui nous a permis d’implémenter la sécurité du

protocole SLNP au niveau « Application ». Ensuite, l’impact de cette sécurité sur les performances de la

négociation en fonction des services de sécurité offerts a été évalué. Ceci nous a permis de conclure que le

coût de la sécurité dépend en grande partie des ces services. Puis, nous avons évalué le coût de la sécurité

184

en fonction des algorithmes qui peuvent être utilisés dans l’offre d’un service de sécurité. Ces tests

d’évaluation ont permis de conclure que le changement de l’algorithme n’a quasiment pas de conséquences

sur les mesures de performances de la négociation. Nous allons essayer, à présent, de sécuriser la

négociation SLNP aux niveaux « Transport » et « Réseau » afin de pouvoir comparer les trois méthodes de

sécurité (trois niveaux différents) en termes de coût.

6.5 Sécurité du protocole SLNP aux niveaux « Transport » (SSL) et

« Réseau » (IPSec)

Les services de sécurité que nous proposons de fournir au flux de négociation SLNP sont l’intégrité,

l’authentification, la non-répudiation et la confidentialité. Ces services peuvent être assurés par le

protocole SSL/TLS qui permet de sécuriser les flux se fondant sur un protocole de transport fiable au

niveau « Transport » du modèle OSI, ou encore par le protocole IPSec qui peut protéger n’importe quel

type de flux au niveau « Réseau » du modèle OSI. Dans cette section, nous décrivons les implémentations

de SSL et de IPSec que nous avons mises en place afin de pouvoir évaluer les performances du protocole

SLNP lorsqu’il est sécurisé avec ces deux protocoles. Ensuite, nous décrivons les tests qui nous ont permis

de vérifier le bon fonctionnement de ces deux types de sécurité et de mesurer leurs impacts sur les

performances de SLNP. Puis les résultats de ces tests sont présentés et une comparaison entre les trois

types de sécurité (WSS, SSL et IPSec) est établie. Cette comparaison nous permet de choisir le niveau de

sécurité à privilégier lors de la mise en place du protocole sécurisé pour la négociation.

6.5.1 Implémentation du protocole SSL/TLS

Comme nous l’avons vu dans la section 2.5.2.2, le protocole SSL/TLS permet de protéger, d’une

manière transparente, les applications fondées sur le protocole TCP comme le web, le mail (POP, IMAP),

le transfert de fichiers (FTP) ou encore les services web. Ainsi, nous pouvons sécuriser le flux de

négociation échangé entre les entités SLNP en utilisant ce protocole de sécurité. Pour cela, nous

configurons le protocole SSL/TLS au niveau du serveur Tomcat afin de permettre la sécurisation des

requêtes/réponses HTTP.

L’implémentation du protocole SSL/TLS comprend, essentiellement, trois grandes étapes. Lors de la

première étape, il est nécessaire de configurer le(s) serveur(s) Tomcat utilisé(s) par les entités de

négociation afin de supporter le protocole SSL/TLS. En effet, s’il s’agit de tests locaux où les services web

de toutes les entités sont déployés sur un seul serveur d’applications Tomcat, alors il faut modifier la

configuration de ce serveur afin de permettre la sécurisation des échanges impliquant ces services web.

Dans le cas contraire, il s’agit de tests impliquant plusieurs serveurs Tomcat, et il faut donc modifier les

configurations de la totalité de ces serveurs. La modification de la configuration d’un serveur Tomcat

consiste à apporter quelques modifications sur le fichier de configuration (server.xml) comme le montre la

Figure 6-9. Ces modifications ont pour but d’ajouter un connecteur, représenté par l’élément

« Connector », qui permet d’associer SSL à un port donné. Ainsi, les échanges de messages de négociation

peuvent utiliser ce port afin de pouvoir bénéficier du niveau de sécurité qu’il offre. Dans l’exemple de la

Figure 6-9, le connecteur ajouté permet d’associer le protocole de sécurité SSL/TLS au port numéro 8443

qui permet de sécuriser les échanges en utilisant la suite de chiffrement

185

TLS_RSA_WITH_AES_128_CBC_SHA définie à travers l’attribut ‘ciphers’. Le connecteur ajouté

indique, également, deux chemins permettant d’accéder au magasin de certificats du serveur (attribut

‘keystoreFile’) et au magasin de certificats des clients (attribut ‘truststoreFile’). Ce connecteur indique

également les mots de passe permettant d’accéder à ces deux magasins (attributs ‘keystorePass’ et

‘truststorePass’). La deuxième étape consiste à créer des certificats pour toutes les entités de négociation

afin de permettre la réalisation des opérations de cryptographie à clé asymétrique sur lesquelles se fonde le

protocole SSL/TLS. Ensuite, ces certificats sont stockés dans des magasins prévus pour cet effet. La

dernière étape a pour objectif d’assurer que les appels de services web entre les entités de négociation sont

effectués à travers les ports sécurisés. Ainsi, cette étape consiste à apporter des modifications aux

implémentations des différentes entités de négociation ; c’est-à-dire le code Java des applications cliente et

des services web. Il s’agit, en effet, de modifier les adresses URI, permettant à une entité d’invoquer une

autre entité, afin de permettre de passer les appels à travers les ports sécurisés avec SSL/TLS.

…

<Connector port="8443" maxHttpHeaderSize="8192" debug="0"

maxThreads="150" minSpareThreads="25" maxSpareThreads="75"

enableLookups="false" disableUploadTimeout="true"

acceptCount="100" scheme="https" secure="true"

clientAuth="true" sslProtocol="TLS" SSLEngine="on"

keystorePass="tomcatpass" keystoreFile="webapps/axis/…/tomcatstore.jks"

truststorePass="wss1pass" truststoreFile="webapps/axis/…/wsslstore.jks"

ciphers="TLS_RSA_WITH_AES_128_CBC_SHA" />

…

Figure 6-9 : Fichier de configuration du serveur Tomcat (server.xml)

6.5.2 Implémentation du protocole IPSec

Le protocole IPSec permet de sécuriser n’importe quel type de flux au niveau de la couche

« Réseau » du modèle TCP/IP (cf. section 2.5.2.1). Ainsi, nous avons, également, utilisé ce protocole dans

la sécurisation du flux de négociation échangé entre les différentes entités SLNP. Pour cela, nous mettons

en œuvre une implémentation du protocole IPSec qui, comme nous l’avons vu dans la section 4.5.2.1, doit

être intégrée au noyau du système d’exploitation. C’est pourquoi nous ne pourrons pas conserver la

plateforme utilisée auparavant pour les tests de sécurité IPSec. En effet, nous avons besoin que chaque

entité SLNP ait une adresse IP différente, car la mise en place de la sécurité IPSec se base sur la notion

d’association de sécurité, caractérisée par un couple d’adresses IP (cf. section 2.5.2.1). Nous avons donc le

choix entre l’utilisation de différentes machines physiques correspondant chacune à une entité de

négociation, ou l’utilisation du mécanisme des systèmes virtuels. Pour réaliser l’implémentation de la

sécurité IPSec, nous avons opté pour le mécanisme de création de systèmes virtuels. Une fois les systèmes

virtuels, représentant les différentes entités, créés, nous avons installé les paquetages « ipsec-tools » et

« racoon » sur chaque entité de négociation. Le premier est utilisé pour gérer la base des politiques de

sécurité (SPD) et celle des associations de sécurité (SAD), tandis que le second met en œuvre le protocole

de gestion de clés IKE pour établir les SA entre les différentes entités. Chaque interaction entre deux

entités impliquées dans une négociation étant sécurisée dans les deux sens, on fait appel à deux

associations de sécurité (une dans chaque sens). Pour cela, nous avons ajouté des entrées dans les bases de

186

politiques de sécurité afin d’indiquer les flux devant être sécurisés et la manière de les sécuriser. Ensuite,

nous avons créé des fichiers de configuration (racoon.conf) afin de spécifier les paramètres de sécurité

IPSec désirés pour une association de sécurité devant être établie entre deux entités. Pour donner une idée

du contenu d’un fichier de configuration, nous présentons une partie de ce fichier dans la Figure 6-10.

path certificate "/etc/racoon/certs";

…

remote 192.168.1.21 {

exchange_mode main;

certificate_type x509 "wss1cert.pem" "decrypt_wss1key.pem";

verify_cert on;

my_identifier asn1dn;

peers_identifier asn1dn;

proposal {

encryption_algorithm aes;

hash_algorithm sha1;

authentication_method rsasig;

dh_group modp1024;

}

}

…

Figure 6-10 : Extrait du fichier de configuration IPSec (racoon.conf)

Dans le fichier de configuration d’une entité de négociation (Figure 6-10), nous pouvons distinguer

l’adresse d’une autre entité (‘remote 192.168.1.21’) avec laquelle une association de sécurité doit être mise

en place. Nous pouvons, également, trouver d’autres informations sur les propriétés de sécurité comme le

type (‘certificate_type x509’) et la localisation du certificat employé dans l’authentification, la méthode sur

laquelle se fonde cette authentification (‘authentication_method rsasig’), ainsi que les algorithmes utilisés

pour le hachage (‘hash_algorithm sha1’) et le chiffrement (‘encryption_algorithm aes’).

6.5.3 Tests et résultats

Les tests que nous décrivons dans cette partie visent non seulement à évaluer les performances du

protocole SLNP lorsqu’il est sécurisé avec SSL/TLS et IPSec mais aussi à établir une comparaison des

performances de ce protocole en fonction du type de sécurité mis en place. Ainsi, dans cette section, nous

commençons par décrire la plateforme de tests, puis les tests qui nous ont permis de vérifier le bon

fonctionnement des différents types de sécurité mis en place. Enfin, les résultats des tests effectués sont

présentés et expliqués.


La plateforme de tests dont nous avons besoin doit nous permettre d’installer et tester les trois types

de sécurité étudiés (à savoir WSS, SSL/TLS et IPSec) en même temps. C’est pourquoi nous utilisons la

machine qui nous a servi dans tous nos précédents tests, sur laquelle nous créons des systèmes virtuels

représentant les trois entités de négociation (Figure 6-11) pour répondre aux contraintes d’IPSec citées

plus haut (cf. section 6.5.2).

187

Afin de pouvoir créer les trois systèmes virtuels et intégrer une implémentation d’IPSec sur chacun

de ces systèmes virtuels, notre plateforme de tests doit fonctionner sous Linux. En effet, ce système

d’exploitation permet la création de systèmes virtuels grâce aux outils « qemu » et « kqemu » et offre la

possibilité d’implémenter IPSec en utilisant les outils « ipsec-tools » et « racoon ». Une fois les systèmes

virtuels créés et l’implémentation du protocole IPSec mise en place au niveau de chacune des trois entités

de notre plateforme de tests, nous créons un pont de niveau 2 entre chaque couple d’entités SLNP devant

communiquer entre elles. Ces ponts physiques sont créés grâce à l’outil « bridge-utils » également

disponible sur Linux. Ils permettent à chaque système virtuel d’avoir une interface réseau virtuelle. Ainsi,

chacune des trois entités SLNP, installée sur un système virtuel, aura la possibilité de communiquer avec

les autres entités. L’installation d’une entité SLNP sur un système virtuel, nécessite la configuration d’un

serveur d’application Tomcat sur lequel nous déployons le service web de négociation de cette entité ainsi

que la base de données nécessaire à la simulation de la RMF et du registre des SLS (Figure 6-11). Pour les

tests relatifs à la sécurité SSL/TLS, les configurations des serveurs Tomcat des trois entités doivent être

modifiées et les invocations des services web doivent passer via les ports sécurisés (cf. section 6.5.1). Pour

la sécurité WSS, il s’agit de configurer chacune des trois entités comme décrit dans la section 6.4.2.

Figure 6-11 : Plateforme de tests

6.5.3.2 Tests de fonctionnements

6.5.3.2.1 Test de fonctionnement de la sécurité SSL/TLS

Pour pouvoir vérifier le bon fonctionnement de la sécurité SSL/TLS que nous avons mise en place,

nous tacherons de visualiser les échanges entre les trois entités de négociation. Comme nous ne pouvons

utiliser ni TCP Monitor, ni SOAP Monitor pour vérifier la sécurité SSL/TLS, nous avons utilisé le mode

« debug » du serveur Tomcat, ce qui permet de stocker une trace des échanges dans un fichier ayant un

nom sous la forme ‘stdout_yyyymmdd’ qui se trouve dans le dossier des logs du serveur Tomcat ‘logs’.

Ainsi, pour visualiser les échanges, il suffit d’ouvrir ce fichier et d’accéder à son contenu après avoir arrêté

le serveur Tomcat. La consultation des différentes traces des échanges effectués entre les entités de notre

plateforme, nous permet de valider le bon fonctionnement de la sécurisation du protocole SLNP avec

SSL/TLS en vérifiant la conformité du niveau de sécurité perçu avec celui que nous avons mis en place.

188

6.5.3.2.2 Test de fonctionnement de la sécurité IPSec

La vérification du bon fonctionnement de la sécurité IPSec ne peut être effectuée que grâce à l’outil

« TCPdump ». A titre d’exemple, Figure 6-12 représente la description d’une réponse à une requête

transmise par le SF vers la SR. Cette réponse est, ici, retournée par la SR (192.168.1.22) vers la SF

(192.168.1.21), et bénéficie des services de sécurité offerts à la connexion entre ces deux entités. Les

services de sécurité sont offerts grâce au mécanisme ESP du protocole IPsec en mode ‘transport’. Notons

que nous pouvons, également, à tout moment, vérifier les associations de sécurité qui sont établies. Par

exemple, la Figure 6-13 montre le résultat de cette vérification qui confirme la description affichée par

TCPdump. En effet, ce résultat indique qu’une association de sécurité est établie entre la SF (192.168.1.21)

et la SR (192.168.1.22), et spécifie qu’elle utilise le mécanisme ESP du protocole IPSec en mode ‘transport’

pour offrir l’intégrité en utilisant l’algorithme ‘HMAC-SHA1’ et la confidentialité grâce à l’algorithme

‘AES’.

22:25:01.784000 IP (tos 0x0, ttl 64, id 3861, offset 0, flags [none], proto ESP (50), length 120) 192.168.1.22 >

192.168.1.21: ESP(spi=0x002a909f,seq=0x2), length 100

Figure 6-12 : Visualisation des échanges sécurisés avec IPSec (TCPdump)

[root@debian1 racoon]# setkey –D 192.168.1.21 192.168.1.22 esp mode=transport spi=202673949(0x0c148f1d) reqid=0(0x00000000) E: aes-cbc 2ae36032 c299841d af98680c 52d3b768 A: hmac-sha1 2f4e94b4 61ebc0d4 dd8b81ab eccfc407 ba8c2c91 seq=0x00000000 replay=4 flags=0x00000000 state=mature created: Jan 13 18:13:37 2009 current: Jan 13 18:13:43 2009 diff: 6(s) hard: 28800(s) soft: 23040(s) last: Jan 13 18:13:37 2009 hard: 0(s) soft: 0(s) current: 128(bytes) hard: 0(bytes) soft: 0(bytes) allocated: 2 hard: 0 soft: 0 sadb_seq=1 pid=2889 refcnt=0 192.168.1.22 192.168.1.21 esp mode=transport spi=87598874(0x0538a71a) reqid=0(0x00000000) E: aes-cbc 3d076dbf 410a8a60 5669e605 fb56cec6 A: hmac-sha1 cd66873a 70ddc7af b6b2a02c 71418bab 4bd59604 seq=0x00000000 replay=4 flags=0x00000000 state=mature created: Jan 13 18:13:37 2009 current: Jan 13 18:13:43 2009 diff: 6(s) hard: 28800(s) soft: 23040(s) last: Jan 13 18:13:37 2009 hard: 0(s) soft: 0(s) current: 128(bytes) hard: 0(bytes) soft: 0(bytes) allocated: 2 hard: 0 soft: 0 sadb_seq=0 pid=2889 refcnt=0

Figure 6-13 : Exemple d’association de sécurité IPSec

6.5.3.3 Tests d’évaluation des performances en fonction du type de sécurité

Pour évaluer le coût de l’impact de la sécurisation du protocole SLNP avec SSL/TLS et IPsec, nous

mesurons toujours les mêmes paramètres caractérisant les performances du protocole de négociation, à

savoir la taille des messages échangés et le temps de négociation sur une seule passe de négociation. Nous

avons à nouveau réalisé un échantillon de 1000 mesures sur une nouvelle plateforme de tests basée sur des

189

systèmes virtuels. Afin de pouvoir comparer les performances de la négociation en fonction du protocole

de sécurité implémenté, nous effectuons sur cette nouvelle plateforme les mesures de performances pour

les trois types de sécurité que nous avons vus : WSSecurity, SSL/TLS et IPSec.

Afin de comparer les performances de WSS, SSL et IPSec, nous testons les différents protocoles de

sécurité pour quasiment le même niveau de sécurité garantissant l’authentification, l’intégrité et la

confidentialité. Pour cela, nous choisissons des algorithmes et des méthodes très similaires pour chaque

service de sécurité (Tableau 6-4).

Type de sécurité Caractéristiques de sécurité Impact sur les performances

Pas de sécurité Authentification : Nul Intégrité : Nul Confidentialité : Nul

Taille des messages : 4560 octets Temps de négociation : 238 ms

WSS Authentification : certificats Intégrité : SHA1 Confidentialité : AES-128-CBC

Taille des messages: 11846 octets Temps de négociation : 457 ms

SSL Authentification : certificats Intégrité : SHA1 Confidentialité : AES-128-CBC


IPSec (AH + ESP) Authentification : certificats Intégrité : SHA1 Confidentialité : AES-128


Tableau 6-4 : Impact des différents types de sécurité sur les performances de SLNP

6.5.3.3.1 Evaluation du temps moyen de négociation

Figure 6-14 : Temps de négociation en fonction du type de sécurité

Pour chacun de ces quatre scénarios (voir Tableau 6-4), nous réalisons un échantillon de 1000

mesures afin d’évaluer le temps moyen de négociation. Cependant, sur la Figure 6-14, nous ne

représentons qu’un échantillon de 100 mesures afin de mieux visualiser le résultat des mesures réalisées.

Concernant la durée de négociation (Figure 6-14 et Tableau 6-4), nous notons que le temps moyen de

190

négociation calculé pour la sécurité SSL (243 ms) et IPSec (267 ms) est très proche de celui d’une

négociation non sécurisée (238 ms). En fait, l’introduction de la sécurité aux niveaux « Transport » ou

« Réseaux » augmente le temps moyen de négociation par respectivement 2,10 % et 12,18 % ; ce qui est

faible. Toutefois, pour le même niveau de sécurité, le temps moyen de négociation est égal à 457 ms

lorsque la sécurité est assurée grâce à WSS ; ce qui représente une augmentation considérable de 92,02 %.

Ainsi, nous remarquons que les traitements nécessaires dans l’offre de sécurité (chiffrement,

déchiffrement, calcul de la signature, etc.) nécessitent plus de temps quand ils sont exécutés au niveau de

la couche applicative que lorsqu’ils sont effectués au niveau « Transport » ou « Réseau ». Ceci est normal

parce que les traitements effectués au niveau applicatif nécessitent l’exécution de plus de processus et

consomment donc d’avantage de ressources (CPU, mémoire, etc.).

6.5.3.3.2 Evaluation de la taille moyenne des messages

Afin de mesurer et comparer la taille des messages de négociation échangés lors d’une négociation,

nous utilisons l’outil TCPdump permettant de mesurer la taille totale des paquets émis. La Figure 6-15

montre que la taille des paquets échangés en sécurisant avec SSL (4929 octets) et IPSec (5040 octets) est

très proche de celle d’un paquet non sécurisé (4560 octets), et est très inférieure à celle mesurée pour une

sécurité WSS (11846 octets). Ceci peut s’expliquer par le fait que les protocoles IPSec et SSL introduisent

des overheads protocolaires largement inférieurs à ceux introduits par WSS. En effet, IPSec et SSL

nécessitent une phase de négociation, au cours de laquelle les associations de sécurité (IPSec) et les

connexions (SSL) sont établies afin de configurer les paramètres nécessaires aux traitements de sécurité

(algorithmes, clés, etc.). Cependant, ces paramètres sont généralement transmis ou référencés dans les

messages échangés lorsque WSS est utilisé.

Figure 6-15 : Taille des messages en fonction du type de sécurité

A partir des Figures 6-22 et 6-23, nous pouvons constater que le coût de la sécurité IPSec est

légèrement supérieur à celui de la sécurité SSL/TLS. Ceci est dû à l’utilisation des deux mécanismes AH et

ESP pour assurer, respectivement, l’intégrité et la confidentialité dans le cas de la sécurité IPSec.

Cependant, nous aurions pu utiliser uniquement le mécanisme ESP pour assurer ces deux types de service,

mais nous avons opté pour cette configuration, car elle est plus robuste. En effet, l’intégrité offerte par le

mécanisme ESP a une qualité légèrement inférieure, parce qu’elle prend en compte moins de champs de

191

l’entête IP par rapport à celle réalisée en utilisant le mécanisme AH. Bien que recommandée, parce qu’elle

offre une protection plus robuste en termes d’intégrité, l’utilisation simultanée de AH et ESP a un impact

sur les performances de la négociation, plus important que celui qu’on pourrait avoir si on avait utilisé

uniquement le mécanisme ESP pour offrir à la fois l’intégrité et la confidentialité. C’est dans ce contexte

bien précis que nous nous sommes proposé d’étudier l’impact des mécanismes mis en place lors d’une

sécurisation avec IPSec. Pour cela, nous avons mesuré séparément l’impact des mécanismes AH et ESP

sur les performances du protocole de négociation. Les résultats montrent que, pour le même niveau

d’intégrité, les performances sont presque similaires. Par exemple, le temps moyen d’une négociation

sécurisée avec IPSec est égal à 242 ms lorsque AH est utilisé et 254 ms quand ESP est employé.

Notons que, suite à l’utilisation d’une nouvelle plateforme de tests mettant en œuvre plusieurs

systèmes virtuels, nous ne retrouvons pas les mêmes résultats des mesures que ceux que nous avons

obtenus auparavant pour les deux premiers cas (« pas de sécurité » et « sécurité WSS »). A titre d’exemple,

nous considérons le cas d’une négociation non sécurisée se déroulant en une seule passe et impliquant

trois entités : la SI, la SF et la SR. Pour ce scénario, le temps moyen de négociation mesuré est égal à

environ 63 ms dans le cas de tests locaux sur un seul système où tous les services web de négociation sont

déployés sur un seul et même serveur Tomcat. Ce même temps passe à 238 ms lorsqu’il est mesuré grâce à

des tests effectués avec plusieurs systèmes virtuels où chaque service web est déployé sur un serveur

Tomcat propre au système virtuel sur lequel l’entité SLNP correspondante est mise en place.

6.5.4 Fonctionnement de la négociation sécurisée

L’étude de la sécurité du protocole SLNP nous a permis de tirer une très importante conclusion par

rapport à l’impact de la sécurité sur les performances de la négociation. En effet, pour un même niveau de

sécurité, l’impact d’une sécurité offerte au niveau « Application » est beaucoup plus important que celui

d’une sécurité assurée au niveau « Transport » ou « Réseau ». Par conséquent, si nous basons notre choix

sur la performance de la négociation, alors l’utilisation de SSL ou IPSec sera privilégiée pour sécuriser la

négociation. Dans ce cas, l’utilisation de WSS peut être autorisée si les performances de la négociation ne

sont pas prises en considération ou si l’utilisation de SSL ou IPSec est impossible ; lorsque, par exemple,

une ou plusieurs entités n’implémentent pas ces protocoles de sécurité. Or, comme nous l’avons vu dans

la section 2.5.2, la mise en place d’une sécurité IPSec ou SSL nécessite la négociation des paramètres de

sécurité en utilisant, respectivement le protocole IKEv2 ou le protocole de poignée de main. Ceci

implique la dégradation importante des performances de la négociation (durée), à cause des délais

supplémentaires introduits par ces négociations (le protocole IKEv2 ou le protocole de poignée de main).

Par conséquent, nous privilégions l’utilisation de WSS lorsque la sécurité de la négociation SLNP est

requise.

Pour permettre aux entités SLNP de négocier un niveau de service de différentes manières (non

protégée ou protégée), nous choisissons d’équiper chaque entité de négociation de six services web de

négociation correspondant aux six niveaux de sécurité introduits dans la section 6.4.2.3. Etant donné que

chaque service web est distingué par une adresse URI permettant de l’invoquer, le choix d’un niveau de

sécurité est réalisé en invoquant le service web qui correspond au niveau de sécurité souhaité. Maintenant,

pour automatiser la sécurisation de la négociation SLNP, nous introduisons un nouveau module, que nous

appellons NSDP (Negotiation Security Decision Point), au sein de la couche de négociation d’un terminal

192

(Figure 6-16). Ce module a pour objectif de prendre, tout d’abord, une décision par rapport à la sécurité

de la négociation. Tout comme les décisions relatives à la négociation, cette décision dépend des

paramètres du profil utilisateur. Elle dépend, plus précisément, des préférences de l’utilisateur en matière

de sécurité de la négociation, que nous ajoutons au profil de l’utilisateur, et des caractéristiques du réseau

d’accès. En effet, si l’utilisateur exige une sécurité pour les flux de ses négociations qui ne peut pas être

satisfaite par le réseau d’accès, alors la décision à prendre est de sécuriser la signalisation SLNP avec WSS.

Ensuite, si cette sécurité est requise, alors la composante NSDP doit, également, sélectionner le niveau de

sécurité à mettre en place. Le choix du niveau de sécurité se fait en fonction des préférences de l’utilisateur

pour les services de sécurité (l’authentification, l’intégrité et la confidentialité). Puis, la composante NSDP

doit informer l’entité de négociation (SE) de la décision prise et du choix effectué afin que cette dernière

puisse invoquer le service web correspondant au choix effectué. Pour assurer une sécurité homogène de

bout en bout pour la négociation SLNP, les appels récursifs aux services web de négociation doivent

s’effectuer en se conformant au niveau sélectionné par le terminal qui a initié la négociation.

Figure 6-16 : Nouvelle structure de la couche de négociation

Remarque : L’un des principaux avantages de WSS est la granularité qu’il peut offrir. En effet, si nous

avons besoin de sécuriser un message SOAP traversant plusieurs WS en le gardant confidentiel pour

certains de ces WS, mais pas pour d’autres, WSS est la seule solution qui permet de répondre à ce besoin.

Concernant l’implémentation de notre protocole de négociation, nous avons supposé que nous étions

dans un environnement de confiance où toutes les entités de négociation coopèrent afin de se mettre

d’accord sur un niveau de service. Ainsi, la négociation à été conçue de manière à ce que les messages

soient transmis d’une entité vers une autre via des appels récursifs. Dans ce cas de figure, la granularité

qui peut être fournie par WSS ne peut pas être exploitée par le protocole. Cependant, dans un

193

environnement hostile, nous pouvons avoir besoin de garder confidentiel entre les deux extrémités de la

négociation une partie du SLS négocié, à savoir les paramètres de sécurité. En effet, les entités

intermédiaires de négociation n’ont pas besoin d’accéder à ces paramètres puisque la sécurité de la

communication sera établie de bout en bout. Pour cela, la granularité que fournissent les standards de

sécurité WSS devient indispensable. Nous devrons alors revoir l’implémentation du protocole SLNP. En

effet, au lieu d’effectuer des appels récursifs entre les entités adjacentes, les messages de négociation

générés par l’entité initiale partiront directement à destination de l’entité finale, en passant par les entités

intermédiaires.

6.6 Conclusion

Dans le précédent chapitre, nous avons vu comment un utilisateur peut participer à la négociation

d’un SLS pour les services qu’il utilise. Si cet utilisateur est connecté via un réseau d’accès sans fil non

sécurisé, alors il risque de se voir établir un SLS différent de celui qu’il a demandé. En effet, la requête de

négociation envoyée par cet utilisateur peut être interceptée et modifiée par un autre utilisateur ou une

autre entité. Dans ce contexte, il devient très important de considérer les aspects de sécurité du flux de

négociation lui-même.

Dans ce chapitre, nous avons étudié la sécurité du protocole SLNP. Ainsi, la première partie de ce

chapitre a été consacré à l’identification des attaques possibles qui peuvent nuire au bon déroulement

d’une négociation SLNP. Ceci a permis de définir les services de sécurité devant être offerts au flux de

négociation afin de pallier à ces attaques. Les services de sécurité sont l’authentification, l’intégrité, la non-

répudiation et la confidentialité ; ils peuvent être assurés au niveau « Application », au niveau « Transport »

ou encore au niveau « Réseau ». Ainsi, la deuxième partie de ce chapitre a été réservée à la description des

mécanismes pouvant sécuriser le protocole SLNP. Etant donné que les mécanismes assurant la sécurité

aux niveaux « Transport » et « Réseau », à savoir SSL/TLS et IPSec, ont déjà été décrits dans la section

2.5.2, nous n’avons détaillé dans cette deuxième partie que les standards pouvant être utilisés dans la

sécurisation de la négociation au niveau « Applicatif », notamment le standard WSS. Ces protocoles et

standards de sécurité ont, ensuite, été utilisés afin de protéger la négociation de SLS fondée sur

l’utilisation des services web afin d’évaluer l’impact de ces divers types de sécurité sur les performances de

la négociation. En effet, dans un premier temps, nous implémentons la sécurité WSS avant d’évaluer les

performances de la négociation en fonction de plusieurs scénarios de sécurité que nous avons définis. Les

paramètres que nous avons mesurés afin d’évaluer les performances du protocole SLNP sont le temps de

négociation qui donne une idée sur le délai d’établissement d’un SLS et la taille des messages qui fournit

une indication sur la bande passante nécessaire aux flux de négociation. Dans un second temps, nous

avons implémenté les sécurités SSL/TLS et IPSec et nous avons, également, étudié l’impact de ces

sécurités sur les performances du protocole de négociation. Ceci nous a permis d’établir une comparaison

entre les trois différents types de sécurité (WSS, SSL/TLS et IPSec) et de choisir la solution la mieux

adaptée au protocole SLNP.

194

Chapitre 7

Conclusion et Perspectives

Les défis techniques des réseaux de nouvelle génération sont, essentiellement, la convergence des

services (données, voix et vidéo) et la convergence des réseaux (Internet, téléphone et diffusion) autour du

mode paquet. Ainsi, l’architecture de ces réseaux est fondée sur une décomposition spatiale qui distingue

deux types de réseaux, à savoir le réseau de cœur basé sur IP et les réseaux d’accès utilisant de nombreuses

technologies comme le Wi-Fi, le WiMax, l’UMTS, le Satellite, etc. L’utilisation d’IP dans le réseau de cœur

implique le besoin de mettre en place des mécanismes dans le but de gérer la QoS ainsi que la sécurité que

les services peuvent nécessiter. Ces besoins peuvent être garantis en utilisant un protocole de signalisation

qui permet la négociation de niveau de service entre les différents domaines impliqués dans le transport

d’un service.

Dans cette thèse, nous nous sommes basés sur un protocole de signalisation de QoS (le protocole

SLNP) afin de fournir une solution permettant à un client fixe ou mobile de négocier d’une manière

dynamique, automatique et sécurisée, le niveau de service correspondant à ses besoins en matière de QoS

et de sécurité. Dans ce qui suit, nous résumons les principales contributions qui ont été détaillées dans

cette thèse et, enfin, nous introduisons quelques perspectives intéressantes qui peuvent être explorées dans

des travaux futurs.

7.1 Principales contributions

Dans le contexte de la garantie de l’offre de service dans les réseaux de nouvelle génération, notre

objectif était de définir une solution qui permet d’assurer la qualité de service ainsi que la sécurité pour des

clients qui peuvent être fixes ou mobiles. Les principales contributions sont :

• Un protocole de négociation conjointe de la sécurité et de la qualité de service : Cette première

contribution consiste à associer la sécurité à la QoS négociée avec le protocole SLNP. Pour cela, une

étude des protocoles de sécurité a été réalisée afin de déterminer les paramètres de sécurité devant être

introduit dans le niveau de service (SLS : Service Level Specification) négocié via SLNP. Ensuite, le

nouveau fonctionnement de la négociation, portnat sur la sécurité et la QoS, a été spécifié et son

implémentation a été réalisée afin d’évaluer les performances de la nouvelle version du protocole.

• Une étude de l’impact de la sécurité sur la QoS : Afin de pouvoir considérer l’impact de la

sécurité sur la QoS lors d’une négociation de niveau de service, les différents acteurs de cette

195

négociation doivent disposer d’une estimation de cet impact. Ainsi, une étude des travaux traitant de

cette problématique a été réalisée. Cette étude nous a permis d’identifier les différents paramètres de

QoS impactés par la sécurité, ainsi que les différents facteurs qui peuvent influencer l’importance de

cet impact. Ainsi, nous avons réalisé des tests qui ont permis d’évaluer l’impact de différents types de

sécurité (TLS, DTLS, IPSec, TLS sur IPSec, et DTLS sur IPSec) sur les paramètres de QoS (délai,

gigue et bande passante) pour deux types de flux, à savoir TCP et UDP.

• Une garantie de QoS et de sécurité pour un service NGN (IPTV) : L’architecture IPTV permet

un accès universel au service DVB-T à travers les réseaux Wi-Fi pour des terminaux hétérogènes et

mobiles. Cette architecture est découpée essentiellement en deux segments ; le réseau de cœur où les

flux IPTV sont transportés en multicast, et le réseau d’accès ou une adaptation est réalisée grâce à

l’outil UED défini par le standard MPEG-21. Afin de garantir la QoS et la sécurité pour les terminaux

sans fil, nous proposons de gérer ces deux aspects en utilisant deux mécanismes différents mais

complémentaires. En effet, nous avons spécifié une méthode de négociation qui permet au protocole

SLNP de garantir l’offre de service (la QoS et la sécurité) dans le réseau de cœur en assurant la

négociation de niveau de service pour un groupe multicast. Quant à l’offre de service dans le réseau

d’accès, nous avons introduit des paramètres liés à la sécurité dans le profil UED afin de permettre

une adaptation du flux IPTV qui prend en compte, non seulement la QoS, mais aussi la sécurité.

• Une adaptation du protocole SLNP aux environnements NGN : L’architecture de la négociation

SLNP, telle qu’elle a été définie, ne permet ni la participation d’un client à la négociation, ni la gestion

de son éventuelle mobilité. Ainsi, nous avons proposé d’adapter le protocole SLNP aux

environnements NGN en donnant la main au client pour négocier, par lui-même, le niveau de service

qu’il lui faut. Pour cela, nous avons défini un profil utilisateur qui doit être constitué au niveau du

terminal du client. Ensuite, nous avons défini comment ce profil peut être utilisé afin de spécifier le

niveau de service à négocier, et comment le standard MIH peut permettre de prendre en compte la

mobilité du client dans la négociation. Puis, nous avons spécifié la composition de la couche de

négociation qui doit être introduite au niveau du terminal d’un client afin de permettre, non seulement

la participation de ce client à la négociation, mais aussi l’automatisation de la totalité du processus de

négociation. Enfin, l’implémentation de cette nouvelle approche de négociation a été réalisée afin de

pouvoir évaluer les nouvelles performances de la négociation.

• Une négociation de niveau de service sécurisée : La négociation assurée par le protocole SLNP

peut être attaquée par un tiers malveillant dans le but de désactiver la sécurité requise par le service

offert, modifier le niveau de service déjà établi, etc. Pour pallier à ces attaques, nous devons sécuriser

la négociation SLNP, ceci revient à sécuriser les messages SOAP échangés entre les différentes parties

de la négociation. Ainsi, nous avons étudié la sécurité des messages SOAP afin d’identifier les

protocoles et standards de sécurité qui permettent la protection de ces messages. Ensuite, la sécurité

de la négociation a été implémentée en utilisant le standard WSS et les protocoles SSL et IPSec. Ceci

nous a permis de mettre en œuvre la sécurité à trois niveau différents (« Application », « Transport » et

« Réseau ») afin d’évaluer leurs impacts respectifs sur les performances du processus de négociation.

Enfin, nous avons décrit les modifications qu’on peut apporter à l’implémentation du protocole

SLNP, dans le but de faciliter la prise de décision relative à la sécurité de la négociation, et optimiser le

choix du protocole de sécurité à utiliser lorsque la protection de cette négociation est requise.

196

7.2 Perspectives et nouveaux défis

Les travaux exposés dans cette thèse constituent une tentative pour contribuer aux efforts fournis

afin d’assurer une offre de service garantissant à la fois la QoS et la sécurité tout en préservant la mobilité

des utilisateurs. Cependant, ces travaux ne permettent pas de répondre à toutes les problématiques posées

dans le contexte de la garantie de l’offre de service dans les réseaux NGN. Plusieurs perspectives peuvent

être identifiées pour améliorer le fonctionnement et l’implémentation du protocole SLNP. Nous

détaillons, ci-dessous, un certain nombre de ces perspectives.

• Extension des tests d’estimation de l’impact de la sécurité sur la QoS : Les tests réalisés dans le

cadre de l’estimation de l’impact de la sécurité sur la QoS ne couvrent pas toutes les possibilités de

sécurisation. Ainsi, nous pouvons étendre nos mesures afin de couvrir toutes les combinaisons

possibles entre services de sécurités offerts, protocoles de sécurité mis en œuvre et algorithmes

utilisés. Par ailleurs, il faudra, également, réaliser d’autres séries de mesures afin d’évaluer cet impact

en fonction des performances des machines effectuant les traitements de la sécurité (capacité CPU,

capacité mémoire, etc.).

• Évaluation des performances de la gestion de l’offre de service sur la plateforme IPTV : Dans

cette thèse, nous avons réussi à définir un mécanisme permettant d’assurer un niveau du service de

bout couvrant la QoS et la sécurité dans une architecture IPTV divisée en deux segments où chacun

est caractérisé par son propre mode de transmission. Ce mécanisme doit être implémenté sur une

plateforme IPTV réelle afin d’évaluer ses performances effectives, notamment le temps nécessaire à la

mise en place d’un niveau de service de bout en bout.

• Évaluation du protocole de négociation dans des conditions réelles : L’adaptation du protocole

SLNP aux réseaux NGN a été implémentée et testée sur notre plateforme de démonstration. Le

succès de ces tests permet de valider notre approche et de montrer son utilité dans les réseaux NGN.

Cependant, lors de la réalisation de ces tests, les interactions avec l’application, le terminal et le

standard MIH ont été simulées grâce à une base de données. Ainsi, il serait bon d’évaluer les

performances du protocole SLNP dans des conditions réelles afin de mesurer l’impact de ces

différentes interactions sur le temps de négociation.

• Validation formelle de protocole de négociation : Pour tester le bon fonctionnement du protocole

SLNP, nous avons du élaborer un certain nombre de scénarios de tests. Ces scénarios, ne pouvant

être exhaustifs, un début de validation formelle avec les FSM (Finite State Machine) et les MSC

(Message Sequence Chart) a été réalisé. Néanmoins, l’utilisation d’un outil de validation tel que SPIN

(Simple Promela INterpreter) avec son langage de modélisation Promela permettrait de tester d’une façon

formelle un certain nombre de propriétés comme le non blocage, le comportement cyclique pour le

protocole SLNP.

• La scalabilité des entités de négociation : Les tests de performances du protocole SLNP,

présentés dans cette thèse, ont été effectués sur des entités impliquées dans une seule négociation ;

c’est-à-dire qu’à un instant donné, chaque entité de négociation a une seule demande à traiter. Ainsi, il

serait très intéressant, dans le l’avenir, d’évaluer la scalabilité du protocole SLNP.

197

• Optimisation des stratégies de négociation : Les stratégies auxquelles les entités de négociation

font appel sont très simples, et peuvent être améliorées. En effet, nous pouvons définir un ensemble

de stratégies plus élaborées en se fondant sur une étude approfondie des types de stratégies qui

peuvent exister. Ensuite, nous pouvons tester l’ensemble des stratégies définies sur notre plateforme

de démonstration afin d’évaluer leurs impacts sur les performances de la négociation, notamment la

durée. Les résultats de ces tests nous aideront, par la suite, à sélectionner les stratégies qui permettent

d’optimiser le taux d’aboutissement à un accord tout en minimisant la durée que nécessite un

processus de négociation.

• Garantie de la continuité de service pour les utilisateurs mobiles : Dans le cadre de l’adaptation

du protocole de négociation aux environnements NGN, nous avons proposé d’utiliser le standard

MIH. Ce standard se propose de réaliser des handovers horizontaux et verticaux tout en garantissant

la continuité de service. Cependant, lorsque l’offre de ce service nécessite la mise en place d’un accord

sur ce niveau de service, le temps nécessaire à un processus de négociation SLNP peut constituer un

obstacle à la garantie de la continuité de service. Une des solutions que nous pouvons proposer pour

surmonter ce problème, est la négociation à l’avance. En effet, nous pourrons ajouter une certaine

« intelligence » au niveau du terminal du client mobile et du réseau global afin de déterminer les

réseaux d’accès voisinant la zone où se trouve le terminal mobile et dont la probabilité d’utilisation est

très importante. Ensuite une négociation de niveau de service à l’avance peut être effectuée afin de

réserver les ressources de QoS requises et de mettre en place les mécanismes de sécurité nécessaires, à

l’avance. De plus, pour automatiser la procédure de négociation à l’avance, nous pourrons introduire

des paramètres relatifs à la mobilité (degré de mobilité, vitesse, sens de déplacement, etc.) dans le

profil utilisateur sur lequel la négociation a été fondée.

198

Références

[ACC 02] Accellent group, “La qualité de service pour la voix sur IP : Principe et Assurances”, White paper, Accellent Group, 2009.

[ALE 06] J. Alexander, D. Box, L.F. Cabrera, D. Chappel, D. Orchard, J. Shewchuk, “Web Services Transfer”, W3C, 2006.

[ANC 05] Ambient Networks Consortium, “Connecting Ambient Networks – Architecture and Protocol Design (Release 1)”, Delivrable D.3.2, March 2005.

[AND 01] L. Andersson, P. Doolan, N. Feldman, A. Fredette, B. Thomas, “RFC 3036: LDP Specification”, Request for Comments, IETF, January 2001.

[ARC 07] Arcade Project, http:/www-rp.lip6.fr/arcade

[ASF 06] Apache Software Foundation, “The TCP Monitor Tutorial”, The Apache Software Foundation, 2006.

[ASF 09] Apache Software Foundation, “The Apache WSS4J”, The Apache Software Foundation, 2009.

[AWD 01] D. Awduche, L. Berger, D. Gan, T. Li, V. Srinivasan, G. Swallow, “RFC 3209: RSVP-TE - Extensions to RSVP for LSP Tunnels”, Request for Comments, IETF, December 2001.

[AXI 09] Apache Axis, http://ws.apache.org/axis

[BAK 95] A. Bakre and B. R. Badrinath, “I-TCP: indirect TCP for mobile hosts”, IEEE International Conference on Distributed Computing Systems, Vancouver, Canada, pp. 136 143, May 30 - June 2, 1995.

[BAR 08] M. Bartel, J. Boyer, B. Fox, B. Lamacchia, E. Simon, “XML Signature Syntax & Processing (2nd Edition)”, Recommandation W3C, June 2008.

[BAU 04] M. Baugher, D. McGrew, M. Naslund, E. Carrara, K. Norrman, “RFC 3711: The Secure Real-time Transport Protocol (SRTP)”, Request for Comments, IETF, March 2004.

[BEL 02] T. Bellwood, L. Clément, D. Ehnebuske, A. Hately, “Universal Description, Discovery and Integration (UDDI) specification”, Technical report, OASIS Committee, July 2002.

[BEN 00] T. Ben, P. Chimento, “QBone Bandwidth Broker Architecture”, The QBBAC Requirements document Version 0.7, June 2000.

[BEN 03] B. Benmammar, T.M.T. Nguyen, G. Pujolle, V. Yelmaz, “Definition d’un SLA/SLS”, IP-SIG/LIV/1, Livrable Projet RNRT IP-SIG, Décembre 2003.

[BEN 06] B. Benmammar, F. Krief, “Resource Management for End-to-End QoS in a Mobile Environment”, The 2nd IEEE International Conference On Wireless and Mobile Computing, Networking and Communications (WiMob 06), Montréal, Canada, June 2006.

[BER 00] Y. Bernel and al., “RFC 2998: A framework for Integrated Services Operation over DiffServ Networks”, Request for Comments, IETF, November 2000.

[BER 05] T. Berners, R. Fielding, L. Masinter, “RFC 3986 : Uniform Resource Identifiers (URI): Generic Syntax”, Request for Comments, IETF, 2005.

[BIR 01] P.V. Biron, and al., “XML Schema Part 2: Datatypes”, W3C Recommendation, May 2001.

[BLA 98] S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, W. Weiss, “RFC 2475: An Architecture for Differentiated Services”, Request for Comments, IETF, December 1998.

[BLU 98] L. Blunk, J. Vollbrecht, “RFC 2284: PPP Extensible Authentication Protocol (EAP)”, Request for Comments, IETF, March 1998.

[BOU 05] A. Boukerche, “Handbook of Algorithms and Protocols for Wireless and Mobile Networks”, Chapman CRC/Hall Publisher, 2005.

[BOM 02] K. Boman, G. Horn, P. Howard, V. Niemi, “UMTS Security”, IEEE Communication Engineering Journal – Special issue on Telecommunications security, October 2002.

[BOO 04] D. Booth, and al., “Web Services Architecture”, W3C Note, February 2004.

199

[BOR 05] M. Borsc, H. Shinde, “Wireless Security and Privacy”, Proceedings of ICPWC 2005, IEEE International Conference on Personal Wireless Communications, pp: 424 – 428, January 2005.

[BOS 05] S. Bosh, G. Karagiannis, A. McDonald, “NSLP for Quality of Service Signaling”, IETF Draft, draf-ietf-nsis-qos-nslp-06.txt, Work in Progress, February 2005.

[BOX 07] D. Box, and al., “Simple Object Access Protocol (SOAP) 1.2”, W3C Note, April 2007.

[BOY 00] J. Boyle, R. Cohen, D. Durham, S. Herzog, R. Raja, A. Sastry, “RFC 2749: COPS Usage for RSVP”, Request for Comments, IETF, January 2000.

[BRA 08] T. Bray and al., “Extensible Markup Language (XML) 1.0 (Fifth Edition), W3C Recommendation, November 2008.

[BRA 94] R. Braden, D. Clark, S. Shenker, “RFC 1633: Integrated Services in the Internet Architecture: an Overview”, Request for Comments, IETF, June 1994.

[BRA 97] R. Braden, L. Zhang, S. Berson, S. Herzog, S. Jamin, “RFC 2205: Resource ReSerVation Protocol (RSVP) - Version 1 Functional Specification”, Request for Comments, IETF, September 1997.

[BRA 97] R. Braden, L. Zhang, “RFC 2009: Resource ReSerVation Protocol (RSVP) -- Version 1 Message Processing Rules”, Request for Comments, IETF, September 1997.

[BRO 96] K. Brown and S. Singh, “M-UDP: UDP for mobile cellular networks”, Computer Communication Review, vol. 26, no. 5, pp. 60 78, October 1996.

[CAD 03] Cadenus Project, “Creation and Deployment of End-User Services in Premium IP Networks”, July 2003.

[CAM 02] G. Camarillo, W. Marshall, “RFC 3312: Integration of Resource Management and SIP”, Request for Comments, IETF, October 2002.

[CAN 05] S. Cantor, J. Kemp, R. Philpott and E. Maler, “Assertions and Protocols for the OASIS Security Assertion Markup Language (SAML) V2.0”, OASIS Standard, March 2005.

[CHA 07] M.A. Chalouf, N. Mbarek, F. Krief, “Utilisation des Services Web dans la négocation du niveau de service”, 8èmes Journées Doctorales en Informatiques et Réseaux, JDIR’2007, Marne la Vallée, France, Janvier 2007.

[CHE 02] J. C. Chen, A. McAuley, S. Sarangan, and al., “Dynamic Service Negotiation Protocol”, draft-ietf-dsnp-01, December 2002.

[CHE 02] J. C. Chen, and Al., “Dynamic Service Negotiation Protocol (DSNP) and Wireless DiffServ”, Proceeding ICC, New York, NY, pp. 1033-1038, April 2002.

[CHE 07] S. Chen, J. Zic, K. Tang, D. Levy, “Performance Evaluation and Modeling of Web Services Security”, IEEE International Conference on Web Services ICWS’07, Salt Lake City, U.T. 2007

[CHR 01] E. Christensen, and al., “Web Services Description Language (WSDL) 1.1”, W3C Note, March 2001.

[CIS 06] Cisco Systems, “Voice Over IP - Per Call Bandwidth Consumption”, 2006.

[CIS 09] Cisco Systems, “Le premier fournisseur mondial de solutions réseaux pour Internet”, 2009.

[CUR 06] K. Curran, “Wi-Fi Security”, BookSurge Publishing, 2006.

[DAR 04] M. D’Arienzo, A. Pescape, and G. Ventre, “Dynamic Service Management in Heterogeneous Networks”, Journal of Network ans Systems Management Vol. 12, September 2004.

[DEC 00] J. De-Clerc, P. De-Schrijver, and Al., “PPP DiffServ SLA Negotiation”, IETF Draft, March 2000.

[DEE 91] S. Deering, “RFC 1256: ICMP Router Discovery Messages”, Request for Comments, IETF, September 1991.

[DIE 06] T. Dierks, E. Rescola, “RFC 4346: The Transport Layer Security Protocol Version 1.1”, Request for Comments, IETF, April 2006.

[DIM 02] M. Dimitrios, “Network QoS needs of Advanced Internet Applications”, Internet2 QoS Working Group, omputer Science Departement of London, November 2002.

[DJA 08] I. Djama, T. Ahmed, H. Nafaa, R. Boutaba, “Meet In the Middle Cross-Layer Adaptation for Audiovisual Content Delivery” in the IEEE Transactions on Multimedia, Vol. 10, Issue 1, pp. 105-120, January 2008.

[DOB 96] D. Dobler, D.Burt, “Purschasing and Supply Management”, McGraw Hill, 6th Edition, 1996.

200

[DRO 03] R. Droms, J. Bound, B. Volz, T. Lemon, C. Perkinz, M. Carney, “RFC 3315: Dynamic Host Configuration Protcol for IPv6”, Request for Comments, IETF, July 2003.

[DRO 97] R. Droms, “RFC 2131: Dynamic Host Configuration Protcol”, Request for Comments, IETF, March 1997.

[DUF 07] S. Duflos, B. Kervella, V. C. Gay, “Considering Security and Quality of Service in SLS to improve Palicy-based Management of Multimedia Services”, Proceedings of the sixth Internationam Conference on Networking (ICN’07), 2007.

[DUR 00] D. Durham, J. Boyle, R. Cohen and al., “RFC 2748: The COPS Protocol”, Request for Comments, IETF, January 2000.

[DUT 04] A. Dutta, S. Madhani, W. Chen, “Fast-handoff Schemes for Application Layer Mobility Management”, Proceedings of the 16th Annual IEEE International Symposium on Personal Indoor and Mobile Radio Communications (PIMRC), Spain, 2004.

[DVB 09] DVB – Digital Video Broadcasting Web Site http://www.dvb.org

[EGE 94] K. Egevang, P. Francis, “RFC 1631: The IP Network Address Translator (NAT)”, Request for Comments, IETF, May 1994.

[ETS 05] European Telecommunications Standards Institute, ETSI ES 282 001, “Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN); NGN Functional Architecture Release 1”, August 2005.

[EUR 01] Eurescom, “Inter-operator interfaces for ensuring end-to-end IP QoS: Specification of Inter-domain Quality of Service Mnagement Interfaces” rapport de projet Eurescom P1008, Mai 2001.

[FAL 00] K. Fall, K. Varadhan, “The network Simulator ns-2 Manual (formerly ns Notes and Documentation)”, August 2000,

[FEH 99] G. Feher and al., “ Boomerang – A simple Protocol for Resource Reservation in IP Networks”, IEEE Workshop on QoS Support for Real-Time Internet Applications, Vancouver, Canada, June 1999.

[FRE 08] P. Fremantle, S. Patil, “Web Services Reliable Messaging”, Specification OASIS, 2008.

[FRE 08] P. Fremantle, S. Patil, “Web Services Reliable Messaging Policy Assertion (WS-RM Policy)”, Specification OASIS, 2008.

[GOD 01] D. Goderis and Al., “Service Level Specification Semantics, Parameters and Negotiation Requirements”, IETF Internet draft, draft-tequila-sls-01.txt, June 2001.

[GOD 03] D. Goderis, D. Griffin, C. Jacquenet, G. Pavlou, “Attributes of a service level specification template”, draft-tequila-sls-03, October 2003.

[GRO 02] D. Grossman, “RFC 3260: New Terminology and Clarifications for DiffServ”, Request for Comments, IETF, April 2002.

[GUD 06] M. Gudgin, M. Hadley, T. Rogers, U. Yalcinalp, “Web Service Addressing Specification 1.0 – WSDL Binding”, W3C, 2006.

[GUD 06] M. Gudgin, M. Hadley, T. Rogers, U. Yalcinalp, “Web Service Addressing Specification 1.0 – Core”, W3C, 2006.

[GUD 06] M. Gudgin, M. Hadley, T. Rogers, U. Yalcinalp, “Web Service Addressing Specification 1.0 – SOAP Binding”, W3C, 2006.

[HAA 97] Z. J. Haas and P. Agrawal, “Mobile-TCP: an asymmetric transport protocol design for mobile systems”, IEEE ICC, Montreal, Canada, pp. 1054 1058, June 8 - 12, 1997.

[HAN 00] M. Handley, C. Perkins, E. Whelan, “RFC: 2974 Session Announcement Protocol”, Request for Comments, IETF, October 2000.

[HAN 05] R. Hancock, G. Karagiannis, J. Loughney, S. Van den Bosch, “RFC 4080: Next Steps in Signaling (NSIS): Framework”, Request for Comments, IETF, June 2005.

[HAN 06] M. Handley, V. Jacobson, C. Perkins, “RFC 4566: Session Description Protocol (SDP)”, Request for Comments, IETF, July 2006.

[HAR 98] D. Harkins, D. Carrel, “RFC 2409: The Internet Key Exchange (IKE)” Request for Comments, IETF, November 1998.

201

[HEI 99] J. Heinanen, F. Baker, W. Weiss, J. Wroclawski, “RFC 2597: Assured Forwarding PHB Group”, Request for Comments, IETF, June 1999.

[HPI 09] The Hping tool, http://www.hping.org/

[HSC 04] Herve Schauer Consultant, “SSLTunnel” HSC Consultants en sécurité informatique, September 2004.

[IEE 03] IEEE 802.11g, IEEE Standard for Information technology—Specific requirements—Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) specifications—Amendment 4: Further Higher-Speed Physical Layer Extension in the 2.4 GHz Band, 2003.

[IEE 04] IEEE P802.11X, “IEEE Standard 802.1X : IEEE Standard for Local and Metropolitan Area Networks: Port-Based Network Access Control”, LAN MAN Standards Committee of the IEEE Computer Society, November 2004.

[IEE 04] IEEE P802.11i, “IEEE Standard 802.11i : Wireless LAN Medium Access Control and Physical Layer specifications - Medium Access Control Security Enhancements”, LAN MAN Standards Committee of the IEEE Computer Society, June 2004.

[IEE 07] IEEE P802.11n_D3.00, Approved Draft Standard for Information Technology-Telecommunications and information exchange between systems--Local and metropolitan area networks--Specific requirements-- Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) specifications: Amendment 4: Enhancements for Higher Throughput, Sep 2007.

[IEE 08] IEEE P802.21/D10.0, “Draft Standard for Local and Metropolitan Area Networks: Media Independent Handover Services”, LAN MAN Standards Committee of the IEEE Computer Society, April 2008.

[IEE 99] IEEE 802.11, IEEE Standards for Information Technology -- Specific Requirements -- Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications, Edition (ISO/IEC 8802-11: 1999), 1999.

[IEE 99] IEEE 802.11a, (8802-11:1999/Amd 1:2000(E)), IEEE Standard for Information technology—Specific requirements—Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) specifications—Amendment 1: High-speed Physical Layer in the 5 GHz band, 1999.

[IEE 99] IEEE 802.11b Supplement to 802.11-1999, Wireless LAN MAC and PHY specifications: Higher speed Physical Layer (PHY) extension in the 2.4 GHz band, 1999.

[IMA 02] T. Imamura, B. Dillaway, E. Simon, “XML Encryption Syntax and Processing”, Recommandation W3C, Décembre 2002.

[IPE 09] The Iperf tutorial, http://openmaniak.com/fr/iperf.php

[ISO 04] ISO/IEC TR21000-1:2004, “Information technology – Multimedia Framework (MPEG-21) – Part 1: Vision, Technologies and Strategy”, 2004.

[ISO 07] ISO/IEC TR21000-7:2007, “Information technology – Multimedia Framework (MPEG-21) – Part 7: Digital Item Adaptation”, 2007.

[IST 04] Information Society Technologies, “EUQOS: End-to-end Quality of Service support over heterogeneous networks”, 9/1/2004 – 8/31/2007.

[ITU 04] International Telecommunication Union – Telecommunication standardization sector of ITU, ITU-T Recommendation Y.2001, “General Overview of NGN”, December 2004.

[ITU 04] International Telecommunication Union – Telecommunication standardization sector of ITU, ITU-T Recommendation Y.2011, “General Principles and General Reference Model of Next Generation Network”, October 2004

[ITU 04] International Telecommunication Union – Telecommunication standardization sector of ITU, ITU-T Recommendation Y.1291, “An Architectural Framework for support of Quality of Service (QoS) in Packet Networks”, February 2004.

[ITU 06] ITU-T FG IPTV-R-0014, 2nd FG IPTV meeting, Busan, Korea 16-20 October 2006.

[ITU 95] ITU-T, “Algebraic semantics of Message Sequence Charts”, Recommendation Z.120, Annexe B, April 1995.

[ITU 96] International Telecommunication Union – Telecommunication standardization sector of ITU, ITU-T Recommendation P.800, “Methods for Subjective Determination of Transmission Quality”, August 1996.

202

[IVR 01] C. Ivrine, and al., “Security as a Dimension of Quality of Security Service in Active Service Environments”, Proceedings of the Active Middleware Services Workshop, San Francisco, CA, pp 87-93, August 2001.

[JAC 99] V. Jacobson, K. Nichols, K. Poduri, “RFC 2598: An Expedited Forwarding PHB”, Request for Comments, IETF, June1999.

[JRA 05] Z. Jrad, and al., “A user assistant for QoS negotiation in a dynamic environment using agent technology”, Proceedings of WOCN-05, UAE, March 2005.

[KAM 00] G. Kammer, “Digital Signature Standard (DSS)”, 2000.

[KAU 05] C. Kaufman, “RFC 4306: Internet Key Exchange IKEv2 Protocol”, Requet for Comments, IETF, December 2005.

[KEN 05] S. Kent, K. Seo, “RFC 4301: Security Architecture for Internet Protocol”, Requet for Comments, IETF, December 2005.

[KEN 05] S. Kent, “RFC 4302: IP Authentication Header”, Requet for Comments, IETF, December 2005.

[KEN 05] S. Kent, “RFC 4303: IP Encapsulating Security Payload”, Requet for Comments, IETF, December 2005.

[KIS 07] C. Kiss, “Composite Capability/Preference Profiles (CC/PP): Structure and Vocabularies 2.0”, W3C Working Draft, W3C, April 2007. Disponible: http://www.w3.org/TR/CCPP-struct-vocab2/

[KON 03] J. Kong, M. Gerla, B.S. Prabhu, R. Gadh, “Providing Multi-layer Security Support for Wireless Communications across Multiple Trusted Domains”, UCLA Computer Science Technical Report, University of California, Los Angeles, 2003.

[LIN 09] Linux Online, “Linux: A Free Unix-Type Operating System”, 2009.

[MAN 04] E. Mannie, “RFC 3945: Generalized Multi-Protocol Label Switching (GMPLS) Architecture”, Request for Comments, IETF, October 2004.

[MAN 97] A. Mankin, F. Baker, B. Braden, S. Bradner, M. O`Dell, A. Romanow, A. Weinrib, L. Zhang “RFC 2208 : Resource ReSerVation Protocol (RSVP)Version 1 Applicability Statement Some Guidelines on Deployment”, Request for Comments, IETF, September 1997.

[MAU 98] D. Maughan, M. Schertler, M. Schneider, J. Tumer, “RFC 2408: Internet Security Association and Key Management Protocol (ISAKMP)” Request for Comments, IETF, November 1998.

[MAR 01] E. Marylly, O. Martinot, S. Betgé-Brezetz, “Impact on Telecom Research Focus of Business and Industrial Requirements for Service Level Agreement Management” GRES’01, Marrakech, Maroc, December 2001.

[MBA 06] N. Mbarek, F. Krief, “La négociation Du Niveau De Service Dans Une Architecture Autonome”, 7ème Colloque Francophone de Gestion de REseaux et de Services, GRES’2006, pp. 207-222, Bordeaux, France, Mai 2006.

[MBA 06] N. Mbarek, F. Krief, “Service Level Negotiation in Autonomous Systems Management”, International Conference on Autonomic and Autonomous Systems, ICAS’2006, Silicon Valley, IEEE Computer Society Press, pp. 35-41, July 2006.

[MBA 07] N. Mbarek, F. Krief, M.A. Chalouf, “A Negotiation Protocol Using Web Services in a Self-Management Framework”, IEEE International Global Information Infrastructure Symposium, IEEE GIIS’2007, Marrakech, Morocco, July 2007.

[MBA 07] N. Mbarek, F. Krief, M.A. Chalouf, “Enabling Service Level Negotiation in a Self-Management Framework”, IEEE International Conference on Signal Processing and Communication, IEEE ICSPC’07, Dubai, UAE, November 2007.

[MCG 92] G. McGregor, “RFC 1332: The PPP Internet Protocol Control Protocol”, Request for Comments, IETF, May 1992.

[MES 03] Mescal Project, “Specification of business models and a functional architecture for inter-domain QoS delivery”, Livrable D1.1, Mai 2003.

[MES 04] Mescal Project, “Initial specification of protocols and algorithms for inter-domain SLS management and traffic engineering for QoS-based IP service delivery and their test requirements” Livrable D1.2, Janvier 2004.

[MES 05] Mescal Project, “Management of End-to-end Quality of Service Across the Internet at Large”, 2005.

[MOS 05] T. Moses, “eXtensible Access Control Markup Language (XACML) Version 2.0”, OASIS Standard, February 2005.

203

[NAD 06] A. Nadalin, C. Kaler, R. Monzillo, P. Hallam-Baker, “Web Services Security Specification 1.1”, Spécification OASIS, Février 2006.

[NAD 07] A. Nadalin, M. Goodner, M. Gudgin, A. Barbir, H. Granqvist, “Web Services Secure Conversation Specification 1.3”, Specification OASIS, 2008.

[NAD 08] A. Nadalin, M. Goodner, M. Gudgin, A. Barbir, H. Granqvist, “Web Services Security Policy Specification 1.4”, Specification OASIS, 2008.

[NAD 08] A. Nadalin, M. Goodner, M. Gudgin, A. Barbir, H. Granqvist, “Web Services Trust Specification 1.4”, Specification OASIS, 2008.

[NET 09] The Netperf Home page, http://www.netperf.org/netperf/

[NGU 03] T.M.T. Nguyen, N. Boukhatem, G. Pujolle, “COPS-SLS Usage for dynamic Policy-Based QoS Management over Heterogenous IP Networks”, IEEE Network, May - June 2003.

[NGU 04] T. M. T. Nguyen, N. Boukhatem, “Service Level Negotiation and COPS-SLS Protocol”, Annals of Telecommunications, vol.59, No.1-2, January - February 2004.

[NIC 98] K. Nichols, S. Blake, F. Baker, D. Black, “Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers”, Request for Comments, IETF, December 1998.

[OSS 09] The OpenSSL project, http://www.openssl.org/

[OSW 09] The Openswan project, http://openswan.org/

[OVP 09] The OpenVPN project, http://openvpn.net/

[CAI 02] B. Cain, S. Deering, I. Kouvelas, B. Fenner, A. Thyagarajan, “RFC 3376 : Internet Group Management Protocol, Version 3”, Request for Comments, IETF, Oct 2002.

[PAN 02] P. Pan, “Scalable resource reservation signalling in the internet”, Ph. D. Thesis, Colombia University, 2002.

[PAN 98] P. Pan, H. Schulzrinne, “YESSIR - A simple Reservation Mechanism for the Internet”, Int’l Workshop, Network and Operating System Support for Digital Audio and Video (NOSSDAV), Cambridge, England, July 1998.

[PER 02] C. Perkins, “RFC 3344: IP Mobility Support”, Request for Comments, IETF, August 2002.

[POL 03] C.Politis, K. Chew, and R. Tafazolli, “Multilayer Mobility Management for All-IP Networks: Pure SIP vs. Hybrid SIP/Mobile IP”, 57th IEEE Semiannual Vechicular Technology Conference VTC2003, April 2003.

[POS 81] J. Postel, “RFC 791: INTERNET PROTOCOL”, Request for Comments, IETF, September 1981.

[POS 91] J. Postel, “RFC 792: Internet Control Message Protocol (ICMP)” Request for Comments, IETF, September 1981.

[PUS 06] T. Pusateri, “RFC 4602: Protocol Independent Multicast - Sparse Mode (PIM-SM)”, Request for Comments, IETF, August 2006.

[QUI 04] J. Quirke, “Security in the GSM System”, May 2004.

[RES 06] E. Rescola, N. Modadugu, “RFC 4347: Datagram Transport Layer Security”, Request for Comments, IETF, April 2006.

[RIN 00] C. Rigney, S. Willens, A. Rubens, W. Simpson, E. Mannie, “RFC 2865: Remote Authentication Dial In User Service (RADIUS)”, Request for Comments, IETF, June 2000.

[ROS 01] E. Rosen, A. Viswanathan, R. Callon, “RFC 3031: Multiprotocol Label Switching Architecture”, Request for Comments, IETF, January 2001.

[ROY 08] J. C. Royer, R. Willrich, M. Diaz, “User Profile-Based Authorization Policies for Network QoS Services”, Proceedings of the Seventh IEEE International Symposium on Network Computing and Applications, pp.68-75, July 2008.

[SAL 00] S. Salsano, “Definition and usage of SLS in the AQUILA consortium”, IETF Draft, draft-salsano-aquila-sls-00.txt, November 2000.

[SAL 02] S. Salsano, L. Veltri, “QoS Control by means of COPS to support SIP based applications”, IEEE Networks, March-April 2002.

[SAL 03] S. Salsano, L. Veltri, “SIP Extensions for QoS support”, IETF Internet Draft, IETF, April 2003.

204

[SAL 07] M. Salhani, R. Dhaou, A. Beylot, « Terrestrial Wireless Networks and Satellite Systems Convergence », The 25th AIAA International Communications Satellite Systems Conference, The American Institute of Aeronautics and Astronautics, 2007.

[SAR 06] V. Sarangan, J.C. Chen, “Comparative Study of Protocols for Dynamic Service Negotiation in the Next Generation Internet”, IEEE Communications Magazine, pp. 151-156, March 2006.

[SCH 00] H. Schulzrinne and E. Wedlund, “Application-layer mobility using SIP”. SIGMOBILE Mob. Comput. Commun. Rev., vol. 4, pp. 47-57, 2000.

[SCH 03] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson, “RFC 3550: A Transport Protocol for Real-Time Applications (RTP)”, Request for Comments, IETF, July. 2003.

[SCH 05] J. Schiller, “RFC4305: Cryptographic Algorithm Implementation for Encapsulating Security Payload and Authentication Header”, Request for Comments, IETF, December 2005.

[SCH 05] H. Schulzrinne, “GIMPS: General Internet Messaging Protocol for Signaling”, Work in Progress, February 2005.

[SCH 98] H. Schulzrinne, A. Rao, R. Lanphier, “RFC 2326: Real Time Streaming Protocol (RTSP)”, Request for Comments, IETF, April 1998.

[SHE 97] S. Shenker, J. Wroclawski, “RFC 2215: General Characterization Parameters for Integrated Service Network Elements”, September 1997.

[SHE 97] S. Shenker, C. Partridge, R. Guerin “RFC 2212: Specification of Guaranteed Quality of Service”, Request for Comments, IETF, September 1997.

[SHE 07] J. She, F. Hou, P. Ho, L. Xie, “IPTV over WiMax: Key Success Factors, Challenges, and Solutions”, IEEE Communications Magazine, pp. 87-93, August 2007.

[SIN 07] A. Singhald, T. Winograd, K. Scarfone, “Guide to Secure Web Services”, National Institute of Standards and Technology, p.2-12, 2007.

[SJI 09] The Sjitter tool, http://www.nicolargo.com/dev/sjitter

[SOA 09] SOAP Monitor, “Enabling The SOAP Monitor”, Axis documentation, 2009.

[STA 06] W. Stallings, “Network Security Essentials: Applications and Standards” Third Edition, 2006.

[STI 05] M. Stiemerling, “A NAT/Firewall NSIS Signaling Layer Protocol (NSLP)”, Work in Progress, February 2005.

[SUN 09] Sun Microsystems, “MySQL: La base de données open source la plus populaire au monde”, 2009.

[SUN 09] Sun Microsystems, “Java: The source for Java developers”, 2009.

[SWA 06] Projet SWAN, “Self-aWare mAnagemeNt”, Réseau National de Recherche en Télécommunication, 2006.

[SYP 00] E. Sypropoulou, and al., “Calculating Costs for Quality of Security Service”, Proceedings of CSA’00, New Orleans, LA, pp. 334-343, December 2000.

[TEB 08] B. Tebbani, I. Aid, G. Pujolle, “SLA-Based Dynamic Resource Management in Wireless Environment”, AICCSA-08, Networking and Multimedia Track, Qatar, April 2008.

[TEQ 01] Tequila Consortium, “SrNP: Service Negotiation Protocol”, October 2001.

[TEQ 03] Tequila Project, “Final Architecture – Protocol and Algorithm Specification”, Livrable Tequila D 3.4 Part B, October 2003.

[TEQ 04] Tequila Project, “Traffic Engineering for Quality of Service in the Internet, at Large Scale”, 2004.

[TER 99] A. Terzis, L. Wang, J. Owaga, L. Zhang, “A two-tier resource management model for the Internet”, Proceedings of Global Internet 99, December 1999.

[THO 01] H.S. Thompson, and al., “XML Schema Part 1: Structures”, W3C Recommendation, May 2001.

[TOM 09] Apache Tomcat, http://tomcat.apache.org

[TPI 09] The TCPPing tool, http://frameip.com/tcpping/

[TSC 05] H. Tschofenig, D. Kroeselberg, “RFC: 4081 Security Threats for Next Steps in Signaling (NSIS)”, Request for Comments, IETF, June 2005.

[VAN 05] Q. D. Van, A. Wei, B. Geller, G. Dupeyrat, “A Model-Based Analysis of Secure Video Transmission Based on IPSec and IPv4”, ETRI International Journal, Vol. 27, No. 2, pp. 219-222, April 2005.

205

[VED 07] A. Vedamuthu, D. Orchard, F. Hirch, M. Hondo, T. Boubez, “Web Services Policy 1.5 – Framework”, W3C, 2007.

[VED 07] A. Vedamuthu, D. Orchard, F. Hirch, M. Hondo, T. Boubez, “Web Services Policy 1.5 – Attachement”, W3C, 2007.

[WAN 99] X. Wang, H. Schulzrinne, “RNAP: a Resource Negotiation and Pricing Protocol”, Proceeding Int’l Workshop on Network and Operating Systems Support for Digital Audio and Video (NOSSDAV), Basking Ridge, NJ, pp. 77-93, June 1999.

[WED 99] E. Wedlund and H. Schulzrinne, “Mobility support using SIP”, Proceedings of the 2nd ACM international workshop on Wireless mobile multimedia, 1999.

[WEI 07] A. Wei, “Contribution à la Qualité de Service dans les réseaux de Télécommunications”, Dossier Scientifique en vue de l’obtention du Diplôme d’Habilitation à Diriger des Recherches, Institut National Polytechnique de Toulouse, Novembre 2007.

[WIR 09] The Wireshark tool, http://www.wireshark.org/

[WRO 97] Wroclawski, “RFC 2211: Specification of the Controlled-Load Network Element Service”, Request for Comments, IETF, September 1997.

[WWW 09] W3C, “Leading the Web to Its Full Potential…”, World Wide Web Consortium, 2009.

[YAV 00] R. Yavatkar, D. Pendarakis, R. Guerin, “RFC 2753: A Framework for Policy Based Admission Control”, Request for Comments, IETF, 2000.

[YIL 03] V. Yilmaz, and Al., “Gestion et deployment de services de sécurité dans un réseau base sur des politiques”, Proceedings SAR 2003, Nancy, France, Juin 2003.

[ZHA 96] Z. Zhang and J. Crowcroft, “QoS Routing for Supporting Multimedia Applications”, IEEE Journal on Selected Areas in Communications, Vol. 14, No.7, pages 1228-1234, September 1996.

206

Annexes

Annexe 1 : Outils utilisés dans la mesure de l’impact de la sécurité

sur la QoS

Iperf

Iperf [IPE 09] est un outil qui se base sur une architecture de type client/serveur afin de permettre de

réaliser des mesures qui concernent, essentiellement, le débit d’un réseau. Cet outil peut être utilisé afin de

mesurer le débit d’un trafic de type TCP ou UDP. Iperf peut également fournir des informations sur la

gigue et la perte des paquets. Afin de réaliser des tests avec Iperf, nous devons configurer un client qui

génère le trafic afin de l’envoyer vers un serveur qui se charge de le traiter.

Sjitter

Sjitter [SJI 09] constitue un outil de mesures écrit en langage C qui se base, également, sur un modèle

client/serveur. Grâce à une simple ligne de commande, cet outil permet de mesurer à la fois le délai, la

gigue et la bande passante pour un trafic de type UDP.

Hping

Hjping [HPI 09] est un outil basé sur une ligne de commande qui s’inspire de la commande Unix :

Ping. Cependant, Hping est capable, non seulement, d’envoyer des requêtes ICMP echo [POS 91], mais

aussi de supporter les protocoles TCP, UDP, ICMP et RAW-IP. Cet outil permet de mesurer le délai, la

gigue, le taux de perte et la bande passante.

Wireshark

Wireshark [WIR 09] est un outil open source utilisé pour analyser les trafics circulant sur un réseau.

La fonctionnalité de Wireshark est très similaire à celle du Tcpdump avec en plus une interface graphique

et plus d’options de filtrage, etc. Il permet à un utilisateur de visualiser toute sorte de trafics circulant sur le

réseau en mettant l’interface réseau en mode d’écoute.

Remarque : Notons qu’il existe d’autres outils permettant de mesurer les performances d’une

transmission de données tels que Netperf [NET 09] et TCPping [TPI 09], mais les outils présentés nous

permettent de réaliser comme il se doit les mesures que nous souhaitons effectuer.

207

Annexe 2 : Les standards de sécurisation des services web au niveau

applicatif

Les standards, représentés dans la Figure 6-1, permettent d’assurer la sécurité des services web au

niveau applicatif [SIN 07]. Parmi ces standards, nous allons principalement nous focaliser sur ceux qui

permettent de répondre parfaitement aux besoins du protocole SLNP en matière de sécurité. En effet,

nous allons, dans un premier temps, étudier les standards XML Signature et XML Encryption sur lesquels

s’appuient les standards de sécurité des services web afin de protéger les messages SOAP échangés.

Ensuite, nous détaillerons le standards WS Security qui se charge de garantir la sécurité des messages

SOAP. Enfin, nous décrivons brièvement les autres standards de sécurité qui peuvent être impliqués dans

la pile protocolaires des services web à savoir WS Trust, WS SecureConversation, WS Addressing, WS

ReliableMessaging et WS Policy.

La sécurité XML

L’intégrité, l’authentification, la non-répudiation et la confidentialité d’un document XML, échangé

entre deux extrémités, peuvent être assurées grâce aux standards XML Signature et XML Encryption

spécifié par le W3C (World Wide Web Consortium) [WWW 09]. Ces deux standards forment la base sur

laquelle seront fondés les standards de sécurité des services web de plus haut niveau comme WS Security.

Le standard XML Signature

Le standard XML Signature [BAR 08] offre l’intégrité, l’authentification et la non-répudiation aux

données XML en permettant de signer un document XML complet (par exemple un message SOAP) ou

encore une ou plusieurs parties de ce document.

Structure d’une signature XML [BAR 08]

Comme nous pouvons le voir sur la Figure A-1, une signature XML est un document XML qui

contient non seulement la valeur de la signature, mais aussi des informations sur tous les éléments ayant

servi à réaliser cette signature ainsi que des références aux objets signés. Le résultat d’une signature XML

est un document XML constitué d’une racine « Signature » qui contient plusieurs sections où chacune

permet de donner certaines informations sur la signature (Figure A-1). L’élément « Signature » est

constitué essentiellement de trois sections à savoir « SignedInfo », « SignatureValue » et « KeyInfo ».

• La section « SignedInfo » : Cette section permet de fournir les informations nécessaires à la réalisation de

la signature ainsi qu’à la localisation des objets devant être signés (un document XML complet ou bien

une ou plusieurs parties d’un document XML). Elle inclut donc l’algorithme de canonisation avec

l’élément « CanonicalizationMethod » et l’algorithme utilisé dans la signature grâce à l’élément

« SignatureMethod ». La section « SignedInfo » inclus également un ou plusieurs éléments

« Reference » qui permettent de désigner le document ou les parties du document à signer. Un

élément « Reference » spécifie l’algorithme de prétraitement grâce à l’élément « DigestMethod » et la

valeur résultante de ce prétraitement (appelée digest) qui sera incluse dans l’élément « DigestValue ».

Chaque prétraitement spécifié dans un élément « Reference » est appliqué à un objet identifié par

l’attribut URI [BER 05] de cet élément. Enfin, l’élément « Transforms » indique si une ou des

transformations ont été appliquées à l’objet désigné avant son prétraitement ; comme, par exemple, un

encodage en base 64.

208

• La section « SignatureValue » : La section « SignatureValue » contient la valeur de la signature numérique

qui est toujours codée en base 64.

• La section « KeyInfo » : Cette section permet au destinataire de connaître la clé nécessaire pour la

validation de la signature. Elle peut contenir plusieurs éléments tels que l’élément « KeyName » ou

l’élément « KeyValue » qui permet d’identifier la clé utilisée. La section « KeyInfo » peut inclure

d’autres éléments tels que l’élément « RetrievalMethod » utilisé pour transmettre une référence vers un

élément « KeyInfo » stockée à un autre endroit (par exemple un autre document) ou encore l’élément

« SignatureProperties » qui permet de communiquer des informations supplémentaires sur la

génération de la signature (par exemple un marqueur de temps indiquant la date de création de la

signature).

<Signature>  <SignedInfo> <CanonicalizationMethod></CanonicalizationMethod> <SignatureMethod></SignatureMethod> <Reference URI='...'><-- Référence à l’objet signé --> <Transforms/><-- Transformation avant le prétraitement --> <DigestMethod/> <DigestValue/>< !-- Valeur du prétraitement --> </Reference> </SignedInfo> <SignatureValue> </SignatureValue> <KeyInfo> <KeyName/> <KeyValue/> <RetrievalMethod/>< !-- Référence aux informations sur la clé --> <SignatureProperties/>< !-- Informations supplémentaires --> </KeyInfo> </Signature>

Figure A-1 : Structure d’une signature XML

Génération d’une signature XML [BAR 08]

Afin d’effectuer une signature, l’émetteur doit générer un digest pour chaque partie qui doit être

signée et qui est référencée au sein de l’élément « SignedInfo » grâce à un élément « Reference ». Le digest

est calculé sur le résultat de la résolution de l’URI de l’élément « Reference » en utilisant un algorithme

défini dans l’élément « DigestMethod ». La valeur du digest est contenue dans l’élément « DigestValue ».

Toutefois, il est possible qu’une transformation de la partie à signer soit requise avant de calculer le digest.

Dans ce cas, cette transformation, spécifiée par l’élément « Transforms », sera appliquée sur cette partie

avant le calcul du digest. Une fois les digests générés, l’émetteur procède à la canonisation en utilisant

l’algorithme spécifié dans « CanonicalizationMethod ». Ensuite, la signature est calculée sur l’élément

« SignedInfo », grâce à l’algorithme spécifié dans « SignatureMethod », et sera incluse dans l’élément

« SignatureValue ». Notons que le calcul de la signature nécessite également une clé dont des informations

peuvent être transmises par l’émetteur vers le destinataire en utilisant un élément « KeyInfo ». Enfin, le

document XML signé est constitué en incluant les éléments « SignedInfo », « SignatureValue » et l’élément

« KeyInfo » (si requis) dans un élément « Signature ».

Vérification d’une signature XML [BAR 08]

209

Une fois la signature réalisée, le document signé est envoyé vers un destinataire qui doit être en

mesure de valider cette signature. La validation d’une signature s’effectue en deux étapes: la validation de

la référence et la validation de la signature. La validation de la référence consiste à canoniser l’élément

« SignedInfo » en utilisant l’algorithme spécifié dans l’élément « CanonicalizationMethod ». Ensuite,

chaque donnée ou partie référencée par un élément « Reference » de l’élément « SignedInfo » est récupérée

afin de calculer son digest en utilisant l’algorithme spécifié dans l’élément « DigestMethod ». Puis, la valeur

du digest généré est comparée à la valeur contenue dans l’élément « DigestValue » de l’élément

« Reference ». En cas de divergence, la validation échoue avant même de vérifier la signature. En cas de

compatibilité entre les valeurs du digest généré et du digest contenu dans le document reçu, la deuxième

étape de la validation peut commencer. Cette étape correspond à la validation de la signature proprement

dite. D’abord, la forme canonique de l’élément « SigedInfo » est obtenue en utilisant l’algorithme défini

dans l’élément « CanonicalizationMethod ». Puis, la valeur de la signature est calculée grâce à l’algorithme

spécifié dans « SignatureMethod » et à la clé obtenue à partir des informations extraites de l’élément

« KeyInfo ». Enfin, la signature est vérifiée en comparant le résultat du calcul effectué et la valeur de

l’élément « SignatureValue ».

Algorithmes définis pour la signature XML [BAR 08]

Le standard XML Signature propose plusieurs algorithmes pour les différentes opérations effectuées

lors de la réalisation d’une signature XML, à savoir la canonisation, le calcul du digest et le calcul de la

signature. Néanmoins, ce standard recommande l’utilisation de certains algorithmes. Pour la canonisation,

on recommande l’utilisation de l’algorithme ‘REC-xml-c14n-20010315’ pour des raisons de compatibilité.

Tandis qu’on recommande l’emploi de l’algorithme ‘RSAwithSHA1’ pour le calcul de la signature parce

qu’il est considéré comme un algorithme sûr. Pour le calcul du digest, on privilégiera l’algorithme ‘SHA1’

défini par l’URI ‘http://www.w3.org/2000/09/xmldsig#sha1’.

Exemple de signature XML

Dans cette section, nous fournissons un exemple de signature XML d’un document HTML4 (Figure

A-2). Le document signé a pour racine l’élément « Signature » qui contient les éléments « SignedInfo »,

« SignatureValue » et « KeyInfo ». Le premier élément, à savoir l’élément « SignedInfo », représente les

données véritablement signées et contient un élément « Reference » qui fournit des informations sur la

ressource à signer grâce à l’attribut ‘URI’ indiquant la localisation de cette ressource. L’élément

« SignedInfo » contient, également, l’élément « Transforms » qui spécifie la transformation canonique

utilisant l’algorithme ‘REC-xml-c14n-20010315’. Cette transformation est appliquée avant le calcul du

digest assuré par l’algorithme de hachage ‘SHA1’ spécifié dans l’élément « DigestMethod ». Le digest

calculé constitue la valeur de l’élément « DigestValue ». L’élément « CanonicalizationMethod », également

contenu dans l’élément « SignedInfo », fournit l’algorithme utilisé dans la canonisation de l’intégralité de

l’élément « SignedInfo », avant qu’il ne soit signé en utilisant l’algorithme défini par l’attribut ‘Algorithm’

de l’élément « SignatureMethod ». La valeur de la signature sera incluse dans le deuxième élément de la

« Signature » ; c’est-à-dire l’élément ‘SignatureValue’. Le troisième et dernier élément de cette « Signature »

est l’élément « KeyInfo ». Cet élément contient des informations sur la clé utilisée afin de permettre au

destinataire du document HTML4 signé de valider la signature. Dans cet exemple, il s’agit d’une clé DSA

[KAM 00].

<Signature Id="MyFirstSignature" xmlns="http://www.w3.org/2000/09/xmldsig#"> <SignedInfo>

210

<CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/> <SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#dsa-sha1"/> <Reference URI="http://www.w3.org/TR/2000/REC-xhtml1-20000126/"> <Transforms> <Transform Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/> </Transforms> <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/> <DigestValue>j6lwx3rvEPO0vKtMup4NbeVu8nk=</DigestValue> </Reference> </SignedInfo> <SignatureValue>MC0CFFrVLtRlk=...</SignatureValue> <KeyInfo> <KeyValue> <DSAKeyValue><P>...</P><Q>...</Q><G>...</G><Y>...</Y></DSAKeyValue> </KeyValue> </KeyInfo> </Signature>

Figure A-2 : Exemple de signature XML

Le standard XML Encryption

Le standard XML Encryption [IMA 02] offre la confidentialité en permettant de chiffrer des données

XML (document complet, élément ou contenu d’un élément). Le résultat du chiffrement est un document

XML contenant des informations sur le processus de chiffrement et les données chiffrées ou des

références à ces données.

Structure d’un chiffrement XML [IMA 02]

Comme nous pouvons le voir sur la Figure A-3, le résultat d’un chiffrement XML est un document

XML qui contient, non seulement les données chiffrées ou des références à ces données, mais aussi des

informations sur tous les éléments ayant servi à réaliser le chiffrement des données d’origine comme

l’algorithme et la clé. Les données d’origines devant être chiffrées (document XML ou un élément d’un

document XML, etc.) sont remplacées par un élément XML « EncryptedData ». Ainsi, cet élément peut

constituer la racine d’un document XML lorsque le chiffrement porte sur la totalité d’un document XML.

L’élément « EncryptedData » contient plusieurs sections où chacune d’elles permet de donner certaines

informations sur le chiffrement. En effet, cet élément est constitué, essentiellement, de trois sections, à

savoir « EncryptionMethod », « KeyInfo » et « CipherData ».

• La section « EncryptionMethod » : Grâce son attribut ‘Algorithm’, la section « EncryptionMethod » peut

définir l’algorithme ayant permis de réaliser le chiffrement des données d’origine dont le résultat est

représenté par l’élément « CipherData ».

• La section « KeyInfo » : La structure de l’élément « KeyInfo » d’un chiffrement XML doit être conforme

à celle de l’élément « KeyInfo » défini par le standard XML Signature. Cet élément permet de fournir

les informations nécessaires sur la clé utilisée dans le chiffrement des données et qui va servir au

destinataire dans la réalisation du processus inverse, c’est-à-dire le déchiffrement. Notons que le

standard XML Encryption fournit deux extensions à l’élément « KeyInfo », à savoir « EncryptedKey »

et « AgreementMethod ». L’élément « EncryptedKey », utilisé pour transporter une clé chiffrée, est

composé d’un élément « ReferenceList » qui contient des pointeurs vers les données chiffrées

(« DataReference ») et la clé utilisée (« KeyReference »). La seconde extension, représentée par

l’élément « AgreementMethod », permet de fournir une clé secrète partagée.

211

• La section « CipherData » : La section « CipherData » contient le résultat du chiffrement des données

d’origine (c’est-à-dire les données chiffrées et codées en base 64) dans un élément « CipherValue » ou

bien une référence à l’emplacement de ce résultat en utilisant l’élément « CipherReference ».

<EncryptedData>  <EncryptionMethod/>  <KeyInfo>  <EncryptedKey>  <ReferenceList> < !-- Liste des données chiffrées --> <DataReference/> <KeyReference/> </ReferenceList> <CarriedKeyName/>  </EncryptedKey> <AgreementMethod/>  <KeyName/>  <RetrievalMethod/> </KeyInfo> <CipherData>  <CipherValue/> < !-- La valeur du résultat du chiffrement --> <CipherReference URI/>  </CipherData> <EncryptedData/>

Figure A-3 : Structure d’un chiffrement XML

Procédure du chiffrement XML [IMA 02]

Le chiffrement d’une donnée XML (document, élément ou contenu d’un élément) sera représenté

par un élément « EncryptedData ». Ce chiffrement nécessite la sélection d’un algorithme et d’une clé de

chiffrement qui sera représentée par un élément « KeyInfo ». Si cette clé doit être elle-même chiffrée, alors

un élément « EncryptedKey » est construit. Dans le cas contraire, la clé de chiffrement est, soit identifiée

grâce à un nom ou une adresse URI, soit directement incorporée dans la section « KeyInfo ». Une fois

l’élément « KeyInfo » construit, les données à chiffrer sont sérialisées avant de procéder à leur chiffrement

en utilisant l’algorithme et la clé identifiés lors des étapes précédentes. Si la séquence d’octets obtenue,

suite au chiffrement, doit être stockée dans l’élément « CipherData », alors cette séquence est codée en

base 64 et est insérée comme contenu de l’élément « CipherValue ». Dans le cas contraire, l’élément

« CipherReference » est utilisé afin de spécifier l’adresse à laquelle les données chiffrées peuvent être

retrouvées. Ainsi, l’élément « EncryptedData » peut être constitué avec les données chiffrées (ou une

référence à ces données) et les informations sur l’algorithme et la clé utilisés dans le chiffrement et qui

seront nécessaires au déchiffrement par le destinataire.

Procédure de déchiffrement XML [IMA 02]

Le déchiffrement des données XML constitue le processus inverse du chiffrement. En effet, pour

chaque élément « EncryptedData » ou « EncryptedKey », le destinataire doit, tout d’abord, localiser et

obtenir la clé de chiffrement à partir de l’élément « KeyInfo ». Ensuite, il pourra déchiffrer les données

contenues dans l’élément « CipherData » en utilisant l’algorithme décrit par l’attribut ‘Algorithm’ de

l’élément « EncryptionMethod » et la clé obtenue lors de l’étape précédente. Avant cela, le destinataire doit

récupérer la séquence d’octets chiffrés. Ces données sont obtenues en décodant en base 64 la valeur de

l’élément « CipherValue » ou en ramenant les données référencées par l’attribut ‘URI’ de l’élément

« CipherReference ».

212

Algorithmes définis pour le chiffrement XML [IMA 02]

Le standard XML Encryption propose plusieurs algorithmes pour le chiffrement d’une ou plusieurs

parties d’un document XML ou même la totalité de ce type de document. Parmi ces algorithmes, nous

pouvons citer les algorithmes : TripleDES, AES-128, AES-192 ou encore AES-256.

Exemple de chiffrement XML

Dans cette section, nous fournissons un exemple de chiffrement d’une partie d’un document XML

(Figure A-4) en utilisant une clé chiffrée (Figure A-5).

Le résultat du chiffrement de la partie concernée est constitué d’un élément « EncryptedData » dont

la structure est donnée dans la Figure A-4. Les données ont été chiffrées en utilisant l’algorithme AES128-

CBC, spécifié par l’attribut ‘Algorithm’ de l’élément « EncryptedMethod », qui utilise une clé symétrique.

Le résultat du chiffrement est contenu dans l’élément « CipherValue ». Quant aux informations sur la clé,

elles sont incluses dans la section « KeyInfo ». En effet, il s’agit d’une clé chiffrée dont l’emplacement est

indiqué par l’attribut ‘URI’ de l’élément « RetrievalMethod » contenu dans « KeyInfo ». Notons que

l’élément « KeyName », également contenu dans « KeyInfo », offre une méthode alternative permettant de

se procurer la clé nécessaire au déchiffrement de l’élément « CipherData ».

<EncryptedData Id='ED' xmlns='http://www.w3.org/2001/04/xmlenc#'> <EncryptionMethod Algorithm='http://www.w3.org/2001/04/xmlenc#aes128-cbc'/> <KeyInfo xmlns:ds='http://www.w3.org/2000/09/xmldsig#'> <ds:RetrievalMethod URI='#EK' Type="http://www.w3.org/2001/04/xmlenc#EncryptedKey"/> <ds:KeyName>Julie MARTIN</ds:KeyName> </ds:KeyInfo> <CipherData><CipherValue>DEADBEEF</CipherValue></CipherData> </EncryptedData>

Figure A-4 : Exemeple de chiffrement d’une partie d’un document XML

Dans le même document XML contenant le résultat du chiffrement, c’est-à-dire l’élément

« EncryptedData », nous trouvons l’élément « EncryptedKey » (Figure A-5) qui représente la clé chiffrée,

qui a déjà été référencée (#EK) dans l’élément « EncryptedData » grâce à l’attribut ‘URI’ de l’élément

« RetrievalMethod ». Cette clé est donc chiffrée en utilisant l’algorithme RSA (attribut ‘Algorithm’ de

l’élément « EncryptionMethod »). La valeur de l’élément « KeyName » (Marcel Dupont) permet de trouver

la clé nécessaire au déchiffrement de la clé chiffrée ; c’est-à-dire la séquence d’octets contenue dans

l’élément « CipherValue » qui se trouve dans « CipherData ». Cette clé a été sérialisée, chiffrée et codée en

base 64. Notons que l’élément « ReferenceList » contient un ou plusieurs éléments « DataReference »,

chacun ayant pour rôle d’identifier un des objets qui ont été chiffrés en utilisant cette clé. Dans notre

exemple, le seul élément « DataReference » fait référence à l’élément « EncryptedData » (Id=‘ED’) de la

Figure A-4 caractérisé par l’identificateur « ED ». L’élément « CarriedKeyName », quant à lui, permet

d’identifier lisiblement la valeur de la clé chiffrée.

<EncryptedKey Id='EK' xmlns='http://www.w3.org/2001/04/xmlenc#'> <EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5"/> <ds:KeyInfo xmlns:ds='http://www.w3.org/2000/09/xmldsig#'> <ds:KeyName>Marcel DUPOND</ds:KeyName> </ds:KeyInfo> <CipherData><CipherValue>xyzabc</CipherValue></CipherData> <ReferenceList><DataReference URI='#ED'/></ReferenceList> <CarriedKeyName>Julie MARTIN</CarriedKeyName>

213

</EncryptedKey>

Figure A-5 : Exemple de chiffrement d’une clé de chiffrement XML

Ainsi, le standard XML Signature permet d’assurer l’authentification, l’intégrité et la non-répudiation

d’un document XML, tandis que la recommandation XML Encryption permet de protéger la

confidentialité d’un document XML. Dans ce qui suit, nous verrons comment la spécification WS Security

repose sur ces deux standards (XML Signature et XML Encryption) afin de garantir la sécurité

(authentification, intégrité, non-répudiation et confidentialité) des messages SOAP échangés entre les

services web.

La spécification WSS

La spécification WSS (Web Services Security) [NAD 06] constitue le premier standard traitant de la

sécurité des messages SOAP. Ce standard a été spécifié par OASIS (Organization for the Advancement of

Structured Information Standards) afin d’assurer la protection des messages SOAP en utilisant XML

Encryption et XML Signature. Ainsi, WSS ne définit pas les méthodes de signature ou de chiffrement mais

plutôt comment incorporer les informations spécifiques à ces deux standards dans l’entête d’un message

SOAP. En effet, WSS permet de transmettre des informations (clé de signature ou de chiffrement, jeton

de sécurité, etc.) sur la sécurité fournie à un message SOAP dans l’entête de ce dernier. Pour cela, la

spécification WSS définit des entêtes de sécurité qui doivent être incorporées dans l’entête d’un message

SOAP. Ce dernier peut contenir un ou plusieurs entêtes de sécurité où chacun d’entre eux fournit des

informations de sécurité (signature et/ou chiffrement) sur le message SOAP à un destinataire qui peut être

intermédiaire ou final.

Dans cette section, nous commençons par décrire les éléments qui peuvent être transportés dans un

entête WSS. Ensuite, nous décrivons comment WSS spécifie l’utilisation de XML Signature dans la

signature des messages SOAP et l’utilisation de XML Encryption dans le chiffrement de ces messages tout

en illustrant par des exemples.

L’entête de sécurité WSS

Les informations de sécurité WSS véhiculées dans les messages SOAP se trouvent au niveau des

entêtes de ces messages (« Header »). Les informations de sécurité, relatives à un message pour un

destinataire spécifique (intermédiaire ou final), sont regroupées dans un entête de sécurité WSS

« Security », comme le montre la Figure A-6. Dans le cas où un message SOAP est destiné à plusieurs

destinataires, l’entête « Header » de ce message doit contenir plusieurs entêtes de sécurité « Security ».

<?xml version=« »?> <Enveloppe> <Header> <Security></Security> </Header> <Body>.......</Body> </Enveloppe>

Figure A-6 : Emplacement de l’entête WSS dans un message SOAP

Un entête de sécurité WSS sert à véhiculer, principalement, un des trois éléments suivants : un jeton

de sécurité, une référence à un jeton de sécurité ou une référence à une clé.

214

• Les jetons de sécurité : Un jeton de sécurité est un ensemble d’informations liées à une identité qui

peuvent être introduit dans un entête de sécurité WSS « Security ». La spécification WSS définit

comment ce jeton peut être associé à une signature afin d’assurer l’authentification de l’origine d’un

message SOAP. Dans ce contexte, deux types de jeton de sécurité ont été définis, à savoir :

« UsernameToken » et « BinarySecurityToken ». Un jeton de type « UsernameToken » permet

d’identifier un utilisateur en lui associant un nom « Username ». Tandis qu’un jeton de type

« BinarySecurityToken » permet d’associer à un utilisateur un jeton de type ‘Kerberos’ ou de type

‘X509’. Notons que dans le cas où l’on ne souhaite pas divulguer d’informations sur le jeton de

sécurité, on peut chiffrer l’élément représentant ce jeton.

• Les références aux clés et aux jetons de sécurité : Les opérations de signature, validation de signature,

chiffrement et déchiffrement nécessitent l’utilisation d’une clé. Etant donné que l’élément contenant

cette clé peut être situé n’importe où dans un message SOAP ou même hors de ce message, la

spécification WSS définit l’élément « SecurityTokenReference » qui peut être inclus dans l’élément

« KeyInfo » de l’entête WSS (voir exemple de la Figure A-7) afin de référencer les clés ou les jetons

utilisés dans les opérations de sécurité : signature (XML Signature) ou chiffrement (XML Encryption).

Le type de jeton référencé est spécifié grâce à l’attribut ‘TokenType’ de l’élément

« SecurityTokenReference ». Quant aux mécanismes de référencement, WSS en a spécifié plusieurs.

Les deux mécanismes les plus utilisés sont le référencement direct en utilisant une URI (sous-élément

« Reference » de l’élément « SecurityTokenReference ») et le référencement grâce à un identifiant de

clé (sous-élément « KeyIdentifier » de l’élément « SecurityTokenReference »).

La signature des messages SOAP avec WSS

Afin d’assurer l’authentification, l’intégrité et la non-répudiation pour les messages SOAP échangés

entre les services web, la spécification WSS propose d’utiliser le standard XML Signature. En effet, pour

signer un ou plusieurs éléments contenus dans une enveloppe SOAP, l’entête de sécurité WSS

(« Security ») doit contenir une signature conforme à la spécification XML Signature. Ceci revient à ajouter

un élément « Signature » dans l’élément « Security » afin d’indiquer au destinataire du message l’ordre

correct des opérations à effectuer. Pour être efficace, WSS recommande de placer les jetons de sécurité

avant les signatures afin qu’ils soient traités et mémorisés avant qu’ils ne soient appelés pour servir dans les

traitements de signature. En ce qui concerne la signature d’un élément d’un message SOAP, la procédure

est la même que celle spécifiée par le standard XML Singature (cf. annexe 0). Néanmoins, en termes

d’algorithmes, la spécification WSS recommande l’utilisation de l’algorithme ‘Exclusive XML’ (xml-exc-

c14n) pour la canonisation et l’algorithme ‘SOAP Message Normalization’ (soap12-n11n) pour la

transformation.

Pour valider la signature d’un message SOAP, le destinataire procède à la vérification de l’élément

« Signature » contenu dans l’entête de sécurité WSS (élément « Security ») du message reçu. Cette

validation peut échouer dans le cas suivant : lorsque la syntaxe du contenu de l’élément « Security » est non

conforme à la spécification WSS, quand la validation de la « Signature » contenu dans cet élément échoue,

ou lorsque le destinataire rejette le message pour une autre raison comme l’utilisation d’une clé non digne

de confiance. En cas d’échec de la validation, un message d’erreur (cf. annexe 0) peut être retourné à

l’émetteur, tandis que dans le cas de succès, une confirmation peut être envoyée à l’émetteur du message.

La confirmation d’une signature est envoyée lorsqu’elle est souhaitée par l’émetteur du message SOAP.

Cette confirmation est assurée grâce à un mécanisme offert par WSS. En effet, le destinataire d’une

215

requête SOAP peut placer un élément « SignatureConfirmation » dans l’entête de sécurité WSS du

message réponse retourné à l’émetteur de la requête. Cet élément (« SignatureConfirmation ») doit

contenir un attribut ‘Value’ qui a pour valeur le contenu de l’élément « SignatureValue ».

La Figure A-7 représente un exemple de message SOAP pour lequel l’intégrité est assurée grâce à une

signature impliquant le standard WSS. L’entête du message SOAP (« Header ») inclut un élément

« Security » qui contient des informations sur la sécurité appliquée au message. Le corps de ce message est,

quant à lui, identifié par l’attribut ‘Id’ (Id="myBody"). L’entête de sécurité WSS « Security » se compose de

deux éléments principaux: « BinarySecurityToken » qui représente un certificat X509 identifié grâce à un

attribut ‘Id’ (Id="X509Token") et un élément « Signature » qui contient, lui-même, trois sous-éléments. Le

sous-élément « SignedInfo » permet, ainsi, de transmettre les informations ayant contribué à la réalisation

de la signature, comme les algorithmes de canonisation ("xml-exc-c14n"), de calcul de digest (sha1) et de

signature (rsa-sha1). Il indique, également, que la signature porte sur le corps du message (<Reference

URI="#myBody">). L’élément « SignatureValue » porte la valeur de la signature, et enfin l’élément

« KeyInfo » indique la clé utilisée dans la réalisation de cette signature en fournissant une référence à un

jeton de sécurité grâce à l’élément « SecurityTokenReference ».

<?xml version="1.0" encoding="utf-8"?> <Envelope xmlns:S11="..." xmlns:wsse="..." xmlns:wsu="..." xmlns:ds="..."> <Header> <Security> <BinarySecurityToken ValueType="...#X509v3" EncodingType="...#Base64Binary"Id="X509Token">MIIEZzCCA9CgAwIBAgIQEmtJZc0rqrKh5i... </BinarySecurityToken> <Signature> <SignedInfo> <CanonicalizationMethod Algorithm= "http://www.w3.org/2001/10/xml-exc-c14n#"/> <SignatureMethod Algorithm= "http://www.w3.org/2000/09/xmldsig#rsa-sha1"/> <Reference URI="#myBody"> <Transforms> <Transform Algorithm= "http://www.w3.org/2001/10/xml-exc-c14n#"/> </Transforms> <DigestMethod Algorithm= "http://www.w3.org/2000/09/xmldsig#sha1"/> <DigestValue>EULddytSo1...</DigestValue> </Reference> </SignedInfo> <SignatureValue>BL8jdfToEb1l/vXcMZNNjPOV... </SignatureValue> <KeyInfo> <SecurityTokenReference> <Reference URI="#X509Token"/> </SecurityTokenReference> </KeyInfo> </Signature> </Security> </Header> <Body Id="myBody"> <StockSymbol xmlns:tru="http://www.fabrikam123.com/payloads">QQQ </tru:StockSymbol> </Body> </Envelope>

Figure A-7 : Exemple de signature d’un message SOAP avec WSS

Le chiffrement des messages SOAP avec WSS

216

Afin d’assurer la confidentialité des messages SOAP échangés entre les services web, la spécification

WSS propose d’utiliser le standard XML Encryption. En effet, WSS permet le chiffrement des blocs

d’entête d’un message SOAP, du corps de ce message ou encore des parties de ce corps. Pour cela, cette

spécification fait appel à deux principaux éléments : « ReferenceList » et « EncryptedKey » (cf. annexe 0)

qui doivent être inclus dans l’entête de sécurité WSS « Security ». L’élément « ReferenceList » indique les

références aux parties du message qui doivent être chiffrées, alors que l’élément « EncryptedKey » est

utilisé pour transmettre une clé symétrique chiffrée. Notons que l’élément « EncryptedKey », défini par

XML Encryption dans le but de transporter une clé chiffrée, est utilisé dans le cadre d’un chiffrement

WSS avec une légère différence dans l’emplacement de cet élément. En effet, contrairement au

chiffrement spécifié par XML Encryption où l’élément « EncryptedKey » doit être contenu dans un

élément « EncryptedData », WSS recommande fortement de placer cet élément (« EncryptedKey ») dans

l’entête de sécurité WSS (« Security »). Par ailleurs, WSS définit un autre élément, à savoir l’élément

« EncryptedHeader », afin de permettre le chiffrement des blocs d’entête. Le chiffrement d’un entête d’un

message SOAP est réalisé en remplaçant cet entête par un élément « EncryptedHeader » qui contient le

résultat de son chiffrement. Ainsi, l’élément « EncryptedHeader » doit contenir un sous-élément

« EncryptedData » qui constitue le résultat du chiffrement de l’entête. Finalement, la spécification WSS

introduit la notion de marqueur de temps de sécurité grâce à un élément « Timestamp » qui doit être placé

dans l’entête de sécurité WSS. Cet élément permet d’exprimer la date de création et la date d’expiration

d’un paramètre/service de sécurité comme la signature ou le chiffrement.

Un émetteur, désirant protéger la confidentialité d’un message SOAP, peut chiffrer les éléments

« Header » et/ou « Body » de ce message. Les différentes étapes conduisant au chiffrement doivent être

décrites dans un seul bloc d’entête « Security » si le message est destiné à un seul destinataire, et dans

plusieurs blocs d’entêtes « Security » si plusieurs destinataires sont concernés. Le chiffrement consiste à

remplacer tout élément du message SOAP qui doit être chiffré par l’élément « EncryptedData » qui lui

correspond. L’élément « EncryptedData » doit être conforme au standard XML Encryption et référencé

par l’élément « ReferenceList ». Lorsque le chiffrement est effectué en utilisant une clé chiffrée, l’entête de

sécurité WSS doit inclure un élément « EncryptedKey » contenant à son tour un sous-élément

« ReferenceList » qui permet, grâce à l’élément « DataReference », de référencer tous les éléments

« EncryptedData » ayant été chiffrés avec cette clé chiffrée.

Pour déchiffrer un message SOAP contenant des parties chiffrées, il faut identifier les parties devant

être déchiffrées (les éléments « EncryptedData ») ainsi que la clé qui doit être utilisée pour le

déchiffrement de chacune de ces parties. Ensuite, chaque élément chiffré de l’enveloppe SOAP peut être

déchiffré suivant la spécification XML Encryption. En cas d’échec lors du déchiffrement, un message

d’erreur peut être transmis à l’émetteur du message chiffré.

La Figure A-8 représente un exemple de message SOAP pour lequel la confidentialité est fournie

grâce à un chiffrement impliquant le standard WSS. L’entête du message SOAP (« Header ») inclut un

élément « Security » qui indique quelle partie du message est chiffrée. Cette indication est réalisée grâce à

l’élément « ReferenceList » qui contient une référence au corps du message identifié par une URI égale à

« #bodyID ». Ainsi le corps de ce message SOAP est constitué d’un élément « EncryptedData ». Ce

dernier contient non seulement les données chiffrées représentées par l’élément « CipherData », mais aussi

des informations sur la clé utilisée pour le chiffrement de ces données qui sont regroupées dans un

élément « KeyInfo ». Dans cet exemple, les informations concernant la clé de chiffrement se résument en

un nom de clé qui est connu par les deux entités échangeant le message SOAP (élément « KeyName »),

217

l’élément « CipherData » qui contient le résultat du chiffrement dont la valeur est portée par le sous-

élément « CipherValue ».

<Envelope xmlns:S11="..." xmlns:wsse="..." xmlns:wsu="..." xmlns:ds="..." xmlns:xenc="..."> <Header> <Security> <ReferenceList> <DataReference URI="#bodyID"/> </ReferenceList> </Security> </Header> <Body> <EncryptedData Id="bodyID"> <KeyInfo> <KeyName>CN=Hiroshi Maruyama, C=JP</KeyName> </KeyInfo> <CipherData> <CipherValue>gFuyXgH9wIyZMoiB7mxX60HztLaecect77A4KdMsz8...</CipherValue> </CipherData> </EncryptedData> </Body> </Envelope>

Figure A-8 : Exemple de chiffrement d’un message SOAP avec WSS

Association d’une signature et d’un chiffrement

La spécification WSS permet d’offrir à un message SOAP à la fois la confidentialité et l’intégrité.

Pour cela, une signature XML et un chiffrement XML sont associés. Cependant la spécification de l’ordre

dans lequel ces deux opérations ont eu lieu est très importante (signature puis chiffrement, ou bien

chiffrement puis signature). Ceci permettra au destinataire de procéder correctement à la validation de la

signature ainsi qu’au déchiffrement du message. Ainsi, si un émetteur souhaite signer un message avant de

le chiffrer, il est important de placer les éléments chiffrés juste après l’entête de sécurité WSS (« Security »)

et avant la signature. Par contre, si ce même émetteur souhaite signer un message après l’avoir chiffré, la

signature se situera juste après l’entête de sécurité WSS et juste avant l’élément chiffré.

Les messages d’erreur spécifiés par WSS

Lors des échanges de messages SOAP sécurisés à l’aide de WSS, il est possible que des erreurs liées à

cette sécurité surviennent. Dans ce cas, l’extrémité qui a détecté l’erreur peut en informer l’autre extrémité

en retournant un message d’erreur. Ce mécanisme d’information sur l’erreur est un mécanisme propre au

fonctionnement des services web. En effet, si une erreur survient suite à un appel à un service, l’entité

appelante peut recevoir un message d’erreur l’informant sur cette erreur, au lieu de recevoir une réponse à

sa requête. Afin de permettre une information précise sur les erreurs liées à la sécurité WSS, la

spécification WSS a pris le soin de définir un certain nombre d’erreurs auxquelles elle a associé des codes

d’erreur comme le montre le Tableau A-1.

Type d’erreur Code d’erreur

Un jeton de sécurité non supporté UnsupportedSecurityToken

Un algorithme (signature ou chiffrement) non supporté UnsupportedAlgorithm

Une erreur lors du traitement de l’entête de sécurité WSS InvalidSecurity

Un jeton de sécurité non valide InvalidSecurityToken

218

Un jeton de sécurité non authentifié ou non autorisé FailedAuthentication

Signature ou chiffrement non valide FailedCheck

Référence à un jeton de sécurité non valide SecurityTokenUnavailable

Expiration d’un message MessageExpired

Tableau A-1 : Quelques types d’erreur définis par WSS

Ainsi, la spécification WSS permet d’ordonner et de transmettre les informations nécessaires aux

traitements de sécurité notamment les opérations de signature et de chiffrement qui permettent de fournir

l’intégrité, l’authentification, la non-répudiation et la confidentialité aux messages SOAP échangés entre les

services web. Cependant, cette spécification n’offre aucun mécanisme pour la gestion des jetons de

sécurité ou encore la dérivation de clés. Pour cela, d’autres standards ont été spécifiés comme le standard

WS Trust ou encore WS SecureConversation. Dans ce qui suit, nous décrivons brièvement le rôle de ces

standards dans la sécurisation des services web.

Autres spécifications pour la sécurité des services web

La spécification WS Trust

La spécification WS Trust [NAD 08b] permet de gérer l’accès à un service web en utilisant des jetons

de sécurité. En effet, le fonctionnement de WS Trust implique trois entités principales : un demandeur de

service web (WSR : Web Service Requestor), un fournisseur de service web (WSP : Web Service Provider)

et une autorité appelée service de jeton de sécurité (STS : Security Token Service). Le principe de

fonctionnement de WS Trust repose sur un échange de type requête/réponse qui concerne un jeton de

sécurité. En fait, un WSR peut s’adresser à une STS en lui transmettant une requête de type

« RequestSecurityToken » afin de demander la délivrance ou le renouvellement d’un jeton de sécurité.

Dans cette demande, le WSR doit spécifier le service web pour lequel le jeton de sécurité est demandé,

ainsi que la durée de validité de ce jeton (date de création et date d’expiration). En recevant cette demande,

la STS doit retourner une réponse au WSR grâce à un message de type

« RequestSecurityTokenResponse ». Cette réponse peut contenir le jeton de sécurité demandé par le WSR

ou une référence à ce jeton. Elle contient, également, le service web pour lequel ce jeton à été délivré ainsi

que la durée de validité. Ainsi, le WSR pourra interagir avec le WSP et prouver qu’il a tous les pré-requis

nécessaires pour accéder au service web offert par ce dernier. Ceci se fait en associant le jeton de sécurité

valide à l’appel adressé au service web fourni par le WSP.

La spécification WS SecureConversation

La spécification WS SecureConversation [NAD 07] permet l’établissement et le renouvellement d’un

contexte de sécurité qui sera partagé par deux ou plusieurs entités. Cette spécification offre, également, un

mécanisme de dérivation de clés.

WS SecureConversation définit un nouveau modèle d’échange fondé sur la notion de contexte de

sécurité afin d’améliorer la performance générale du mécanisme d’échange de messages SOAP. En effet, la

création d’un contexte de sécurité entre deux entités leur permet d’échanger la totalité de leurs messages

en utilisant les mêmes paramètres de sécurité. Pour cela, la spécification WS SecureConversation introduit

un nouveau type de jeton de sécurité, appelé jeton de contexte de sécurité (Security Context Token), qui

permet de représenter un contexte de sécurité, et contient un secret partagé utilisé pour mettre en œuvre

les propriétés de sécurité désirées comme la signature et le chiffrement des messages SOAP échangés. WS

219

SecureConversation définit plusieurs moyens d’établissement de contextes de sécurité. Le moyen le plus

utilisé consiste à créer un jeton de contexte de sécurité par un service de jeton de sécurité (STS), suite à la

demande de l’initiateur d’un échange de messages SOAP (« RequestSecurityToken »). Ensuite, ce STS peut

retourner une réponse « RequestSecurityTokenResponse » qui inclut un élément

« RequestedSecurityToken » contenant le nouveau jeton de contexte de sécurité ou une référence pointant

sur celui-ci, ainsi qu’un élément « RequestedProofToken » pointant vers le secret partagé correspondant au

contexte retourné. Ainsi, l’initiateur de la demande peut utiliser le jeton de contexte de sécurité pour

sécuriser les messages échangés avec le service web concerné par le contexte créé. Une autre façon

d’établir un jeton de contexte de sécurité est la création de celui-ci par une des deux parties

communicantes. Par exemple, l’initiateur déclenchant l’échange des messages, peut créer, lui-même, un

jeton de contexte de sécurité et l’envoyer aux autres parties. Ce modèle ne fonctionne que si le créateur de

jeton est reconnu comme suffisamment sûr pour créer de nouveaux jetons de contexte de sécurité.

WS-SecureConversation vise à augmenter le niveau de sécurité global des échanges entre les services

web en introduisant un mécanisme de dérivation de clés. La création d’un contexte de sécurité implique

l’établissement d’un secret partagé qui peut être utilisé pour signer ou chiffrer des messages. Cependant,

WS SecureConversation recommande l’utilisation de clés dérivées de ce secret dans la signature ou le

chiffrement des messages échangés dans le même contexte de sécurité. Pour cela, le standard WS

SecureConversation définit l’élément « DerivedKeyToken » qui indique le mécanisme de dérivation de clé

devant être utilisé (en général il s’agit de l’algorithme P_SHA1) ainsi que d’autres propriétés et

informations comme le numéro de la génération de clé qu’il faut utiliser si la taille des clés est fixe, la

longueur de la clé et l’offset, qui permettent de retrouver la clé dans une suite d’octets, etc.

La spécification WS Addressing

Le protocole SOAP ne fournit pas de moyens pour indiquer la destination d’un message, l’adresse à

laquelle une réponse ou une erreur doit être retournée. Ces informations sont transmises par la couche

transport. En effet, l’URI de la requête HTTP transportant la requête SOAP est utilisée comme

destination de celle-ci. La réponse à cette requête utilise, également, HTTP pour spécifier la destination de

cette réponse.

La spécification WS Addressing Core [GUD 06a] désigne de manière unique un service web sur le

réseau par une représentation au format XML de ses points de terminaison et, de ses propriétés. Cette

spécification est complétée par la spécification WS Addressing WSDL Binding et la spécification WS

Addressing SOAP Binding. La spécification WS Addressing WSDL Binding [GUD 06b] permet de gérer

les propriétés définies par WS Addressing Core et de les décrire à travers un document WSDL. Tandis que

la spécification WS Addressing SOAP Binding [GUD 06c] permet de traduire les propriétés des points de

terminaison représentées par WS Addressing Core en messages SOAP.

La recommandation WS Addresssing Core représente l’adresse d’un point de terminaison sous la

forme d’un identificateur IRI (Internationalized Resource Identifiers). Elle permet, également, d’exprimer

les propriétés d’adressage des messages SOAP en spécifiant les adresses des points de terminaison

impliqués dans une ou plusieurs interactions. Pour cela, cette spécification introduit des éléments

spécifiques comme les éléments « To », « From », « ReplyTo », et « FaultTo ». L’élément « To » permet de

déterminer l’adresse de destination sous forme d’IRI. L’élément « From » permet d’indiquer d’adresse

source. Quant aux éléments « ReplyTo » et « FaultTo », ils permettent de spécifier, respectivement,

l’adresse vers laquelle il faut diriger la réponse et celle vers laquelle les erreurs sont envoyées. Les

220

recommandations WS Addressing proposent d’utiliser l’entête des messages SOAP pour transmettre les

informations d’adressage. Ainsi, les éléments spécifiques à cette spécification (« To », « From »,

« ReplyTo », « FaultTo », etc.) sont introduits directement dans l’entête de ces messages.

La spécification WS ReliableMessaging

Un échange de messages SOAP peut être perturbé par la perte ou la duplication de certains messages.

Il peut être, également, perturbé si les messages n’arrivent pas dans le bon ordre. Pour pallier à ce

problème de fiabilité, la spécification WS ReliableMessaging [FRE 08a] a été définie afin de fiabiliser les

échanges entre les services web. Cette spécification propose d’ajouter deux entités logiques au niveau de la

source et de la destination des messages SOAP. L’entité ajoutée au niveau de l’émetteur s’appelle source

de messages fiables (RMS : Reliable Messaging Source), alors que celle ajoutée au niveau du destinataire est

appelée destination de messages fiables (RMD : Reliable Messaging Destination). Ensuite, la spécification

WS ReliableMessaging vise à permettre à la RMS de déterminer la manière dont chaque message SOAP

qu’elle transmet à la RMD doit être reçu. Autrement dit, cette spécification va permettre à la RMD : de

déterminer efficacement quels sont les messages reçus, de filtrer ou non les messages reçus, et de délivrer

à l’application de destination les messages suivant l’ordre selon lequel l’application source les a émis.

Le fonctionnement d’un échange de messages SOAP, dont la fiabilité est offerte grâce à WS

ReliableMessaging, est le suivant. D’abord, une application source (coté émetteur) émet un message pour

une transmission fiable. Ce message est accepté par la RMS qui le transmet une ou plusieurs fois. Lorsque

la RMD (coté destinataire) reçoit le message envoyé par la RMS, elle doit l’acquitter, avant de le délivrer à

l’application destinataire. Ainsi, grâce à ce mécanisme d’acquittement et de réémission, la spécification WS

ReliableMessaging permet d’assurer la fiabilité des échanges de messages SOAP entre les services Web.

La spécification WS Policy

La spécification WS Policy [VED 07a] a été définie afin de permettre à une entité de déterminer ses

besoins en termes d’adressage, de fiabilité et/ou de sécurité pour sa communication avec une autre entité.

En effet, cette spécification permet de définir et d’exprimer les propriétés et les pré-requis que doit avoir

un service web, par exemple, si le message SOAP doit être authentifié ou si une partie du message doit

être signée ou chiffrée, etc. Ces règles ou politiques peuvent être exprimées sous forme d’une ou plusieurs

assertions. En effet, une assertion est une donnée qui représente une préférence individuelle, un impératif,

une fonctionnalité ou toute autre propriété requise pour permettre l’accès aux opérations contenues dans

un service web. Les types d’assertions sont définis par les standards WS Addressing, WS

ReliableMessaging et WS SecurityPolicy pour, respectivement, des assertions sur l’adressage, la fiabilité ou

la sécurité des messages SOAP. Ainsi, en utilisant, par exemple, des assertions fondées sur WS

SecurityPolicy, il est possible de spécifier si un message doit être signé et/ou chiffré, ou si des parties de ce

message doivent être signées et/ou chiffrées, etc.

Quant à la spécification WS Policy, elle définit l’élément « Policy » qui permet de représenter une

politique qui peut être identifiée grâce à un nom (attribut ‘Name’) ou en utilisant un identificateur (attribut

‘Id’). Cette spécification vise à fournir un cadre souple pour la définition des contraintes à respecter au

cours des échanges entre les services web. Ceci est réalisé en définissant deux éléments pouvant être inclus

dans l’élément « Policy », à savoir l’élément « ExactlyOne » et l’élément « All ». L’élément « ExactlyOne »

est utilisé lorsque plusieurs assertions de stratégie sont présentes et qu’une seule est requise. Par contre, on

peut faire appel à l’élément « All » lorsque chaque assertion de stratégie présente dans cet élément doit être

appliquée.

221

Pour connaître les politiques à appliquer, les services web disposent de deux moyens : WS

MetadataExchange et WS PolicyAttachment. La spécification WS MetadataExchange [ALE 06] est utilisée

par les services web pour permettre aux autres entités, désirant interagir avec eux, de connaître les

politiques définies qui sont incluses ou référencées dans les métadonnées retournées par ces services web.

Quant à WS PolicyAttachment [VED 07b], il spécifie comment référencer les stratégies à partir des

définitions WSDL, comment associer des stratégies à des points d’accès ou comment associer des

stratégies avec des enregistrements UDDI.

Ainsi, WS Policy permet de définir des politiques afin de contraindre les services web à échanger des

messages de manière sécurisée et/ou fiable. En effet, pour la sécurité des messages SOAP, WS Policy fait

appel au standard WS SecurityPolicy [NAD 08a] qui fournit un cadre pour la définition des stratégies

relatives à la sécurité conformément à WS Policy. Tandis que, pour représenter les politiques relatives à la

fiabilité des échanges entre les services web, WS Policy utilise la spécification WS-ReliableMessaging

Policy Assertion [FRE 08b] qui permet de définir des assertions correspondant à des politiques

garantissant la fiabilité des échanges SOAP, conformément à WS Policy.

222

Annexe 3 : Exemple d’un message SLNP sécurisé avec WSS

<?xml version="1.0" encoding="UTF-8"?> <Envelope xmlns:soapenv="…" xmlns:xenc="…">

<Header> <Security xmlns:wsse="…" soapenv:mustUnderstand="1">

 <EncryptedKey Id="EncKeyId-12245160">

 <EncryptionMethod Algorithm="… /xmlenc#rsa-1_5"></EncryptionMethod> <KeyInfo xmlns:ds="…/xmldsig#">

 <SecurityTokenReference>

<X509Data> <X509IssuerSerial>

<X509IssuerName>CN=wss2user</X509IssuerName> <X509SerialNumber>1239006779</X509SerialNumber>

</X509IssuerSerial> </X509Data>

</SecurityTokenReference> </KeyInfo>  <CipherData>

<CipherValue> Iu/+HXSy9TYuudVQIOZAP+crXIqaxsgFuyXgH9wIyZMoiB7mxX60HztLaecect77A4KdMszLGezz2NdA87ujQharhyVqbLyY8QSHveSfnUI2Z6+gtB+8CL98ptm2V/j5GeQw6pGC/XgUY3sT3edD63W2hJH1xIYG/xeheQ22

</CipherValue> </CipherData>  <ReferenceList>

<DataReference URI="#EncDataId-21925102"></DataReference> <DataReference URI="#EncDataId-20079748"></DataReference>

</ReferenceList> </EncryptedKey>  <Signature xmlns:ds="…/xmldsig#" Id="Signature-15055830">

<SignedInfo>  <CanonicalizationMethod Algorithm="…/xml-exc-c14n#"></CanonicalizationMethod>  <SignatureMethod Algorithm="…/xmldsig#rsa-sha1"></SignatureMethod>  <Reference URI="#id-33431531">

 <Transforms>

<Transform Algorithm="…/xml-exc-c14n#"></Transform> </Transforms>  <DigestMethod Algorithm="…/xmldsig#sha1"></DigestMethod>  <DigestValue>xCwpyxBsAu0w+f2jXssDS4fc1WY=</DigestValue>

</Reference> </SignedInfo>  <SignatureValue>

YA7J9itDce0wP5L7ZvX+wGGUxfamviv5UtUQxwK2XauVR7Th/zi2euRzoX4JhyFKEybAdOjqwlPo+wBfN+Oir+xYXN2avh8nU3bXWBlwYqNuB26Cj/H36xh3YdwwtEjh8BYtQo/e1uWw3lDnNCkkLEqOoYTsz9q9dkAnH9ttF4k=

</SignatureValue>

223

<KeyInfo Id="KeyId-1696092"> <SecurityTokenReference xmlns:wsu="…" wsu:Id="STRId-2165595">

<X509Data> <X509IssuerSerial>

<X509IssuerName>CN=wss1user</X509IssuerName> <X509SerialNumber>1239006796</X509SerialNumber>

</X509IssuerSerial> </X509Data>

</SecurityTokenReference> </KeyInfo>

</Signature>  <EncryptedData Id="EncDataId-20079748" Type="…/xmlenc#Element">

 <EncryptionMethod Algorithm="…/xmlenc#aes128-cbc"></EncryptionMethod> <KeyInfo xmlns:ds="…/xmldsig#">

<SecurityTokenReference>  <Reference URI="#EncKeyId-12245160"></Reference>

</SecurityTokenReference> </KeyInfo> <CipherData>

<CipherValue> gfRjYkMp0jCyere1a+jnV57kLHwvcF1+p50ON6bFQ1fHxBxkNM1Yvoa+QqXgW3uaAGuT/AR58kXDBdDa1guzlJHvt+Tdz/b6le3MFKeGp742Lool11n0oYjCGF/zWGAtaLR1X+jwgKrpYvoEF9HXYC9xA4n89qCw/oBE9zxcczIS9AjaFUFr5eUuJLft/WDryl/kFEbE3VXAV3JEYBEwdeSK+8VXMG8Xr790au2GG/aeZth9kGH8dO+jEoD2lMjRqcLZjJdjOMg9zdJ4NMVBI8s2EK1/Uby2tpX2ao0JE9uVKa/QZjZjJBiqLWbAT1V1zbTJBfRJ168lYBfGBjfgSu2cF7VcaubLW5/b9aD98A/dzKfe4eUv6JM2YLFIeXb3

</CipherValue> </CipherData>

</EncryptedData>  <EncryptedData Id="…/xmlenc#Element">

 <EncryptionMethod Algorithm="…/xmlenc#aes128-cbc"></EncryptionMethod> <KeyInfo xmlns:ds="…/xmldsig#">

 <SecurityTokenReference>

<Reference URI="#EncKeyId-12245160"></Reference> </SecurityTokenReference>

</KeyInfo> <CipherData>

<CipherValue> F4Am194hGwuwGQBrF3ZGqodlhWlPA8JGFjUXJJVgdmijr4TI8fhflWmLaRRlYWbRM1KddJmBHN5xl8ghX9TzIgNOFFC2iscIbxkFjT+YzoluFsDKgR0V/2MJgp8okgDRqKbDa4r4wjUalz037HzyUE8YaSiRButBcVncmbZitNxtp1EKGMjWz/0yATcunKYLhO3UAtk24G8n9ToqCoa4aZ/Rb0I1oaut1rbP2jjEWI6PX0/eHEO1vAlU8g88B8w1t/vYzHkGWwWm3vj+YTe2NqNTTCJSxh12WHRX6H8FbD2l6BPvlNXNU+/LBanr+ngwhCeiGrMjc4eJncIw0/eUARVhlz6vutoV9ki2fchk9VR6C0vC4VjD9xqCsYLZMDfXtWPF+qhXJ+XD6vF3GtrJ95ycEi8xptpPbIZkKhiJs4nRmOS/MJZzc12mSP/fEkETBBZUbELNiqgg3VBlEiKA99c+zkMYTulR4FGJG/b8sAa2sgvLb79QQuBq+zLljudH1TNqIhA424k6evXaQQ8vimxzDsQjHNa6CdvFb9Oa9gDcX17pyBU1/y/YjS7Wc4MivG1DrrGORxuQEv0jzx+TgrfS8bVHcnFtkPSssSQzGvCibj4vOXiMYTAolND1Fp1lE1Krj3ptAoqBbO/0GO9dFcf/thc2KW7EeAgiwxa9KWVfxPIuR+1/WgVCBIKmlKBzhqWdVLvYQUuB+S4InpZ1cCmIJ5oAfGNuSQTmeU9UA3nAbKR/pEOHvJE7BIjFQo+OtflbSv1nBxmpLJtRKTNJusE9JwouIQ013a/6cS6ncaEpYLluZvdx6HlSZ0zXXEbhQhTiPuNklF8KSoGzhes5Yr97+34V99S3MsuSW/zwlhF32lpGd894ZLz1FXBPYogtvXAw7S/kFsb4KGTMuw+Ff5dw/dTfhQk3PGWJEcDb+I+Uh1oSA1AA2deeTeOIZsb6vvko8EkiHiMvOGQnQf7aisjg3EYuRXR4uvPlA=

</CipherValue> </CipherData>

</EncryptedData>

224

</Security> </Header> <Body xmlns:wsu="…" wsu:Id="id-33431531">

<Negotiate xmlns="urn:WSNegotiation2"> <negotiationId xmlns="…">1</negotiationId> <endNegotiation xmlns="…">true</endNegotiation> <sls xmlns="…">

<slsId>0</slsId> <flowId>

<sourceIPAddress> <IPv4Address>192.162.00.10</IPv4Address>

</sourceIPAddress> <destinationIPAddress>

<IPv4Address>182.182.00.33</IPv4Address> </destinationIPAddress> <sourcePort>8080</sourcePort> <destinationPort>8080</destinationPort> <protocolId>250</protocolId> <DSCP>000100</DSCP>

</flowId> <qosParameters>

<scope> <ingress>

<IPv4Address>192.162.00.10</IPv4Address> </ingress> <egress>

<IPv4Address>182.182.00.33</IPv4Address> </egress>

</scope> <serviceSchedule>

<immediateSS> <endTime>

<year>2006</year> <month>--12--</month> <day>---31</day> <hour>00:00:00.000Z</hour>

</endTime> </immediateSS>

</serviceSchedule> <performanceGuarantee>

<delay> <delayRequested>

<minDelay>100</minDelay> <maxDelay>100</maxDelay>

</delayRequested> <delayOffered>20</delayOffered>

</delay> <jitter>

<jitterRequested> <minJitter>40</minJitter> <maxJitter>40</maxJitter>

</jitterRequested> <jitterOffered>15</jitterOffered>

</jitter> <packetLossRatio>

<packetLossRatioRequested> <minPacketLossRatio>0.1</minPacketLossRatio> <maxPacketLossRatio>0.1</maxPacketLossRatio>

</packetLossRatioRequested> <packetLossRatioOffered>0.1</packetLossRatioOffered>

</packetLossRatio> <throughput>

<throughputRequested>

225

<minThroughput>500</minThroughput> <maxThroughput>500</maxThroughput>

</throughputRequested> <throughputOffered>500</throughputOffered>

</throughput> </performanceGuarantee>

<trafficConformity></trafficConformity> <excessTreatement>

<excessTreatementRequested>DROP</excessTreatementRequested> <excessTreatementOffered>MARK</excessTreatementOffered>

</excessTreatement> </qosParameters> <secParameters></secParameters>

<negotiationParameters> <negotiationMode>NonPredefinedNonConstrained</negotiationMode> <negotiationInterval>

<negotiationIntervalRequested> <nbHour>0</nbHour> <nbMinutes>10</nbMinutes>

</negotiationIntervalRequested> <negotiationIntervalOffered>

<nbHour>0</nbHour> <nbMinutes>1</nbMinutes>

</negotiationIntervalOffered> </negotiationInterval>

</negotiationParameters> <reliability>

<MeanDownTime> <meanDownTimeOffered>10</meanDownTimeOffered> <meanDownTimeRequested>50</meanDownTimeRequested>

</MeanDownTime> <MeanTimeToRepair>

<meanTimeToRepairRequested>100</meanTimeToRepairRequested> <meanTimeToRepairOffered>50</meanTimeToRepairOffered>

</MeanTimeToRepair> </reliability>

</sls> </Negotiate>

</soapenv:Body> </soapenv:Envelope>

226

Liste des abréviations

2G Réseau 2ème Génération 3DES Triple DES 3G Réseau 3ème génération 3GPP 3rd Generation Partnership Project 3GPP2 3rd Generation Partnership Project 2 ACL Access Control List ADSL Asymmetric Digital Subscriber Line AES Advanced Encryption Standard AG Adaptation Gateway AH Authentication Header ANC Ambient Networks Consortium AQUILA Adaptive Resource Control for QoS Using an IPbased Layered Architecture ASCII American Standard Code for Information Interchange ATM Asynchronous Transfer Mode BGP Border Gateway Protocol BoD Bandwidth on Demand CADENUS Creation And Deployment of End-User Services in Premium IP Networks CBC Cipher-Block Chaining CBR Constant Bit Rate CCM Counter with CBC-MAC CCMP Counter-mode/Cipher block chaining Message authentication code Protocol COPS Common Open Policy Service CP Content Provider CPU Central Processing Unit CRC Cyclic Redundancy Check DEA Data Encryption Algorithm DES Data Encryption Standard DHCP Dynamic Host Configuration Protocol DIA Digital Item Adaptation DM Domain Manager DSCP DiffServ Code Point DSNP Dynamic Service Negotiation Protocol DTD Document Type Definition DTLS Datagram Transport Layer Security DVB Digital Video Brodcast DVB-S2 DVB – Satellite Second Generation DVB-T Digital Video Brodcast - Terrestrial DiffServ Differentiated Services DoS Denial of Service EAP Extensible Authentication Protocol ESN Extended Sequence Number ESP Encapsulating Security Payload ETSI European Telecommunications Standards Institute FTP File Transfer Protocol GANS Generic Ambient Networking Signaling GIMPS General Internet Messaging Protocol for Signaling GMPLS Generalized MPLS GPRS General Packet Radio Service

227

GSM Global System for Mobile Communications GUI Graphical User Interface HA Home Agent HMAC keyed-Hash Message Authentication Code HTML Hypertext Markup Language HTTP HyperText Transfer Protocol HTTPS Secured HTTP ICV Integrity Check Value IEEE Institute of Electrical and Electronics Engineers IETF Internet Engineering Task Force IIS Internet Information Services IKE Internet Key Exchange IMAP Internet Message Access Protocol IP Internet Protocol IPSec IP Security Protocol IPSig IP Signaling IPTV Internet Protocol Television IPTV FG Internet Protocol Television Focus Group IRI Internationalized Resource Identifiers ISAKMP Internet Security Association and Key Management Protocol ITSUMO Internet Technologies Supporting Universal Mobile Operation ITU International Telecommunication Union IntServ Integrated services LAN Local Area Network LDAP Lightweight Directory Access Protocol LDP Label Distribution Protocol LEAP Lightweight EAP LoD Live on Demand M-TCP Mobile TCP M-UDP Mobile UDP MAC Media Access Control MD5 Message-Digest algorithm 5 MESCAL Management of End-to-end Quality of Service Across the Internet at Large MIC Message Integrity Code MICS Media Independant Command Service MIES Media Independant Event Service MIH Media Independant Handover MIHF MIH Function MIIS Media Independant Information Service MIP Mobile IP MOS Mean Opinion Score MPEG Moving Picture Experts Group MPEG-2 TS MPEG-2 Transport Stream MPLS MultiProtocol Label Switching MSC Message Sequence Chart NAT Network Address Translation NGN Next Generation Networks NSIS Next Step In Signaling OS Operating System OSI Open Systems Interconnection PAD Peer Authorization Database PDA Personal Digital Assistant PDP Policy Decision Point PEAP Protected EAP PEP Policy Enforcement Point

228

PHB Per Hop Behavior PHB AF Per Hop Behavior Assured Forwarding PHB EF Per Hop Behavior Expedited Forwarding POP Post Office Protocol PPP Point to Point Protocol PSTN Public Switched Telephone Network QSIP QoS Enabled SIP QoE Quality of Experience QoS Quality of Service QoS-GSLP QoS Generic Signaling Layer Protocol QoS-NSLP QoS NSIS Signaling Layer Protocol RAM Random Access Memory RAP Resource Allocation Protocol RIP Routing Information Protocol RMF Resource Management Function RNAP Resource Negotiation and Pricing Protocol RSVP Resource Reservation Protocol RTC Réseau Téléphonique Commuté RTP Real-time Transport Protocol RTT Round Trip Time SAD Security Association Database SAML Security Assertion Markup Language SE SLNP Entity SF SLNP Forwarder SG SLS Generator SG Security Gateway SI SLNP Initiator SIM Subscriber Identity Module SIP Session Initiation Protocol SLA Service Level Agreement SLNP Service Level Negotiation Protocol SLS Service Level Specification SMTP Simple Mail Transfer Protocol SN Sequence Number SOAP Simple Object Access Protocol SP Service Provider SPD Security Policy Database SPI Security Parameters Index SR SLNP Responder SRTP Secure Real-time Transport Protocol SSL Secure Sockets Layer SWAN Self aWare mAagemeNt SrNP Service Negotiation Protocol TCP Transmission Control Protocol TDD Time Division Duplex TDMA Time Division Multiple Access TEQUILA Traffic Engineering for QUality of service in the Internet at LArge TKIP Temporal Key Integrity Protocol TLS Transport Layer Security TLV Type Length Value ToIP Telephony over IP TTLS Tunneled TLS UDDI Universal Description Discovery and Integration UDP User Datagram Protocol UED User Environment Description

229

UMTS Universal Mobile Telecommunications System URI Uniform Resource Identifier VoD Video on Demand VoIP Voice over IP W3C World Wide Web Consortium WEP Wired Equivalent Privacy WLAN Wireless Local Area Network WPA Wi-Fi Protected Access WPA-PSK Wi-Fi Protected Access – Pre-Shared Key WS Web Services WSDD Web Service Deployment Descriptor WSDL Web Service Description Language WSP Web Service Provider WSR Web Service Requestor WSS Web Service Security WSS4J Web Services Security for Java WiFi Wireless Fidelity WiMax Worldwide Interoperability for Microwave Access XACML eXtensible Access Control Markup Language XML eXtensible Markup Language XSD XML Schema Definition YESSIR YEt another Sender Session Internet Reservation xDSL Digital Subscriber Line technologies family

Offre de service dans les réseaux de nouvelle...

Documents

Transcript of Offre de service dans les réseaux de nouvelle...