Spécification de l architecture globale Déliverable 2-13 Janvier 2003

Transcription

1 Spécification de l architecture globale Déliverable 2-13 Janvier 2003 Houda Labiod, Guy Pujolle labiod@enst.fr, Pujolle@lip6.fr Résumé Un des objectifs majeurs des réseaux mobiles multiservices de 4ème génération est d offrir un environnement mobile performant qui permettra à un utilisateur muni de son ordinateur portable (PC, PDA, ) ; équipé de plusieurs interfaces d accès sans fil ; de se déplacer de manière transparente entre plusieurs réseaux gérés par différents fournisseurs. Deux autres éléments clés sont importants à prendre en considération qui sont la sécurité et la qualité de service à offrir aux utilisateurs tout en assurant une optimisation de l utilisation des ressources. Dans le contexte de ce projet qui est celui d une interconnexion de systèmes sans fil multifournisseur et dans le but d atteindre les objectifs cités ci-dessus, nous nous sommes penchés sur la spécification d une architecture globale de maîtrise de qualité de service de bout-enbout et de sécurité. Cette architecture intègre principalement les fonctionnalités de contrôle d accès basé sur RADIUS ainsi que des mécanismes de contrôle de qualité de service basés sur le développement de politiques avec COPS. La qualité de service ainsi que le contrôle d accès sont gérés en grande partie par une carte à puce virtuelle. De nouveaux concepts et protocoles ont été définis et seront détaillés dans ce document. Mots-clés : réseaux 4G, contexte multi-fournisseur, carte SIM-IP, COPS, RADIUS, WiFi, 802.1x

2 1. Introduction Le formidable essor que connaît actuellement les technologies sans fil Wireless Local Area Networks (WLAN) et Wireless Personal Area Networks (WPAN), est certainement un phénomène majeur qui a marqué ces dernières années le domaine de l accès sans fil [1]. Probablement, une convergence de toutes ces technologies avec les réseaux mobiles 2.5G/3G [2,3] entraînera une panoplie de solutions intégrées et la combinaison de plusieurs standards améliorera la connectivité sans couture. Chaque standard sera optimisé et adapté à un environnement donné. Une panoplie de travaux est menée dans le cadre de consortia d industriels et d organismes de normalisation afin de définir des solutions plus robustes en termes de sécurisation, de QoS,.. Parmi ces instances, on peut citer la famille des groupes de travail IEEE 802 (802.11x, , ), ITU-R, et ETSI BRAN. Jusqu à présent, ces travaux n ont pas encore abouti à l approbation de standards; une échéance d achèvement des travaux est annoncée pour le début de l année Dans l attente d un ou de plusieurs standards, des solutions intermédiaires sont adoptées. Plusieurs standards WLANs sont en compétition (IEEE , HomeRF, Hiperlan2) mais aujourd hui un consensus émerge autour des normes IEEE b (WiFi) et IEEE a (WiFi 5) [4]. Plusieurs facteurs clés laissent prévoir une montée en puissance du marché WLAN, parmi lesquels nous pouvons citer : - une maturité progressive des normes (spécialement celles dérivées du WiFi et WiFi 5), - une baisse progressive des prix, - une évolution des débits (11Mbit/s avec WiFi et 54Mbit/s avec a/g), - le retard des systèmes mobiles de 3 ème génération, - un investissement considérable des grands constructeurs dans la fabrication des terminaux, carte et points d accès, - une augmentation du déploiement du multi-équipement à domicile, - une mobilité accrue des utilisateurs. Dans le cadre de la 4 ème génération des systèmes mobiles multiservices, le WLAN occupe une place importante et de ce fait nous nous sommes focalisés, dans un premier temps, sur une étude basée sur la technologie WLAN. Par ailleurs, le boom de l Internet a fait jaillir des applications diverses telles la messagerie électronique, instant messaging et les services web qui peuvent être lancés sur la majorité des périphériques disponibles actuellement (notebooks, PDAs, ordinateurs portables,...). Par conséquent, accéder à ces applications constitue un élément important. Actuellement, la majorité des infrastructures véhicule explicitement le trafic IP. Par conséquent, les futures architectures 4G devront inclure des réseaux hétérogènes ainsi qu un backbone-coeur IP. Par ailleurs, comme l Internet évolue vers des réseaux multiservices, un élément clé est de supporter des services avec une garantie de QoS. Dans le cadre de ce contexte multi-technologies, l utilisateur sera probablement muni de plusieurs terminaux supportant plusieurs interfaces d accès. Il choisira les réseaux d accès selon le service désiré. Néanmoins, établir un contrat fixe avec chaque fournisseur est une solution chère et complexe à gérer. L utilisateur préfèrera plutôt d autres alternatives plus souples telles qu un paiement par service indépendamment du fournisseur lui-même mais dépendant par contre de la qualité de service offerte (bande passante effective, délai, jigue). Les réseaux constituant notre architecture doivent supporter les fonctionnalités élémentaires de support de QoS. En effet, l identification des utilisateurs ainsi que le contrôle d accès constituent des problèmes critiques à résoudre dans un tel contexte de support de QoS. 2

3 Indépendamment du cadre juridique, qui incombe des restrictions selon certains pays, des interrogations demeurent quant aux limitations actuelles de cette technologie. La sécurité constitue particulièrement un problème crucial pour ces réseaux dont le support de transmission diffusant est partagé. En outre, la qualité de service représente un verrou majeur à lever. Actuellement, le marché des hotspots (lieux de passage de grande densité ouverts au public) représente le marché qui suscite le plus d intérêt, il concerne l accès haut débit à des données en des lieux publics de forte densité (aéroport, gare, hôtel, café, bibliothèque, métro, centres commerciaux, centres de conférences, parcs de loisirs, restaurants,..). Une effervescence de hotspots a vu le jour en Europe, on compte plus de 1000 hotspots dont la majorité se trouvent dans les pays nordiques. Concernant la France, très récemment un assouplissement de la réglementation a été annoncé par l ART [5] autorisant l installation de hotspots ouverts au public. Les opérateurs de télécommunications mobiles français perçoivent désormais la technologie WLAN comme une technique d'accès complémentaire de la 3G. Ils sont donc fortement intéressés par mettre en oeuvre des mécanismes efficaces qui gèrent la mobilité des utilisateurs entre les infrastructures sans fil leurs propres réseaux mobiles. Il reste à proposer des solutions pour pallier aux limitations concernant la qualité de service et les questions de sécurité. En se basant sur le contexte ainsi décrit et en mettant un accent sur la technologie WLANs nous décrivons dans ce rapport, de manière détaillée, la spécification de l architecture globale qui offre une solution englobant des mécanismes de sécurisation des réseaux et des procédures d accès aux services avec support de roamingt et de QoS. Ce rapport comprend principalement six sections. La deuxième section décrit le contexte multi-fournisseur des réseaux 4G et souligne les principaux verrous techniques à lever. La section 3 rappelle les objectifs visés par le projet. Quant à la quatrième section, elle donne une description détaillée de notre architecture et les approches proposées pour résoudre les problèmes techniques citées en Section 1. Dans la Section 5, nous décrivons de manière détaillée la solution de contrôle d accès que nous proposons. L architecture de contrôle de la qualité de service est donnée en Section 6. Une synthèse sur l insécurité de WiFi est donnée en annexe I. Une brève présentation de l architecture 802.1x est donnée en annexeii. 2. Description du contexte du projet Nous considérons le cas d une multitude de réseaux gérés par plusieurs autorités. Dans un tel contexte multi-fournisseur, le roaming constitue un problème critique à résoudre. Pour des raisons de performance, nous considérons que la majorité des WLANs est gérée exclusivement par un seul opérateur. Ainsi, un utilisateur peut changer de localisation géographique sans faire appel à un autre opérateur au niveau de la même localisation (sauf certaines exceptions biensûr). Les avantages principaux offerts par un opérateur seraient le débit effectif, la QoS et le nombre de sites où le service est disponible. Par conséquent, une coopération entre les opérateurs WLANs permettra de fournir un accès aux utilisateurs sur une zone géographique plus étendue. En plus d un mécanisme de nommage commun des utilisateurs, les fournisseurs de services impliqués doivent établir différents accords (service level agreement, technologies, prix, ) dans le but d offrir un accès avec roaming depuis ou vers les autres réseaux. Les détails relatifs aux contrats de roaming ne sont pas traités dans le cadre du projet MMQoS et sont généralement négociés entre les différents fournisseurs. Dans la suite, nous résumons les 3

4 principaux problèmes soulevés par ce type d architecture. Principalement, nous distinguons trois problèmes cruciaux à résoudre: contrôle d accès avec mobilité: Chaque fournisseur A doit assurer un accès sécurisé à des utilisateurs potentiellement inconnus par le fournisseur B. - Quel est le schéma de nommage à adopter pour la définition des identités des utilisateurs? - Où sera localisée cette identité et comment peut-elle être protégée contre d éventuelles attaques? - Quelles informations (identité,..) l utilisateur mobile doit-il présenter au réseau visité et comment le fournisseur A peut-il vérifier l exactitude de ces informations des utilisateurs provenant du réseau du fournisseur B? - Une fois authentifié, comment l utilisateur a accès au réseau de service? Comment peut-on offrir l accès au service localisé dans le home network de l utilisateur? QoS: A cause de la bande passante limitée, les environnements wireless sont particulièrement sensibles à la détérioration de service dans le cas d une forte charge du réseau. - Comment peut-on contrôller le trafic de l utilisateur? - Comment un service offert peut-il être garanti aux visiteurs avec certaines contraintes de QoS? - Comment un fournisseur A peut-il prouver à un utilisateur X et à son propre fournisseur B que cet utilisateur utilise réellement les ressources du réseau A? Facturation: L information de facturation dépend du contrat de roaming. - Comment peut-on collecter l information de facturation associée aux utilisateurs itinérants? - Comment peut-on délivrer des preuves de l exactitude de cette information? Généralement, les réseaux mobiles 2.5G et 3G supportent différents niveaux de QoS et des mécanismes de facturation bien définis. L authentification est basée sur l utilisation de la carte SIM subscriber s identity module (SIM in GSM [6], USIM in UMTS [7]) qui stocke les informations et les algorithmes d authentification. Donc, ce type de réseau est adapté pour servir en tant que domaine d autorité dans un contexte multi-fournisseur. Jusqu à présent, les standards WLAN existants ne supportent pas les trois fonctionnalités citées ci-dessus malgré que différents working groups (WG) IEEE sont impliqués dans la recherche de solutions à ces problèmes. Il s agit notamment de : WG 802.1x qui définit des mécanismes de contrôle d accès pour les réseaux 802 networks avec support de roaming, WG e qui traite les aspects relatifs à la QoS, WG i qui propose un standard global pour améliorer la sécurité des réseaux sans fil. Un premier challenge consiste à définir une architecture de réseau à adopter par chaque fournisseur de telle sorte à ce qu elle soit réalisable de manière simple et qui permette de répondre efficacement aux besoins de sécurité et de garantie des exigences de QoS. Cette architecture reprend certains protocoles en cours de normalisation à l IETF et àl IEEE. Un deuxième challenge est de spécifier les protocoles à mettre en place pour gérer l interconnexion des différents réseaux des divers fournisseurs et permettre le roaming des utilisateurs.. 4

5 3. Principaux objectifs 3.1 Description Le principal objectif du projet est d offrir la mobilité des utilisateurs avec support de QoS de bout-en-bout dans un contexte multi-fournisseur de réseaux sans fil hétérogènes avec différentes autorités de management (voir Figure 1). La carte à puce SIM-IP [8], qui est décrite en détail dans le déliverable 1 et résumée dans la Section 4.3, constitue un élément clé de l architecture proposée. Elle est utilisée pour stocker de manière sécurisée l identité de l utilisateur et des éléments nécessaires pour le contrôle d accès au réseau. En particulier, le contrôle de QoS basée sur l utilisation de politiques est appliqué du moment qu il est adapté au contexte de notre projet. Dans la phase préliminaire du projet, nous limitons nos investigations en considérant uniquement les hotspots WiFi. Figure 1. Architecture globale du projet MMQoS Les objectifs du projet sont les suivants. 3.2 Mobilité La mobilité constitue une caractéristique cruciale. Nous définissons la mobilité comme étant la possibilité à un utilisateur de se déplacer à travers les différents réseaux constituant l infrastructure globale sans changer d identité. Les hotspots sont géographiquement espacés. Le maintien de l identité de l utilisateur facilitera donc les opérations de facturation. Par ailleurs, nous supposons que le contexte multi-fournisseur est défini pour une période assez longue. Les procédures telles que les seamless handoffs et les fast handoffs ne feront pas l objet d études dans le cadre du projet mais devront être étudiées de manière approfondie. 3.3 QoS La QoS englobe deux objectifs principaux. Le premier objectif consiste à assurer à l utilisateur que le service a respecté les critères de QoS exigés. Le second objectif consiste à fournir une solution qui permet d offrir la qualité demandée en optimisant l utilisation des ressources selon le profil de l utilisateur. Dans le but d offrir une solution flexible pour la gestion de la QoS, nous proposons d utiliser le standard COPS [9]. Introduire une entité de contrôle de réseau centrale permettra donc d adapter dynamiquement des profils QoS selon 5

6 l état du réseau. De plus, un échange d informations concernant les profils peut être fait entre les fournisseurs concernés. 3.4 Sécurité Afin d offrir un accès sécurisé aux réseaux pour garantir la QoS basée sur le niveau de service défini par l utilisateur et dans le but d assurer une facturation fiable, des mécanismes d authentification robustes sont indispensables. Bien évidemment, ces mécanismes doivent supporter le roaming. Il est également indispensable d élaborer des schémas de cryptage efficaces sur les liens sans fil. Nous devons inclure aussi l identité de l utilisateur dans les paquets véhiculés dans le but d assurer un accès sécurisé aux services aussi bien dans le réseau home que dans les réseaux visités. 4 La solution proposée Afin d explorer les problèmes fondamentaux et critiques soulevés par les futures architectures de réseaux mobiles, nous proposons de considérer l architecture système 4G décrite par la Figure 2. Cette architecture ouverte supporte une multitude de services multimédias. Elle permet une évolution de ces services. Elle intègre aussi bien les fonctionnalités de base liées à la mobilité (authentification, roaming,..) que de nouvelles procédures de support de QoS. Le but de cette section est de présenter les entités et les protocoles impliqués dans l architecture globale. Elle comprend une description générale de l architecture globale fonctionnelle. Une présentation détaillée de l architecture du réseau du fournisseur de service est donnée. 4.1 Architecture système 4G L architecture globale est vue comme une architecture ouverte qui permet une évolution des caractéristiques des services via la collaboration de diverses entités réseau filaires et sans fil. Globalement, elle est composée par une panoplie de réseaux de service de fournisseur service provider networks (SPNs) interconnectés par un réseau backbone IP. Les hotspots WLANs sont gérés par chacun des fournisseurs. Les tâches de gestion sont exécutées en se basant sur l utilisation de politiques de gestion qui reflètent les exigences du fournisseur et des utilisateurs. Pour ce faire, on fait appel aux entités COPS telles que les s (Policy Decision Point) et les s (Policy Enforcement Point). s sont des Edge routers qui sont connectés via des liens de communication à grande vitesse. 6

7 SPN A SPN B IP backbone SPN C WLAN C SPN D L e g e n d Data traffic Control traffic SPN C Service Provider Network C Figure 2. Architecture système globale 4.2 Architecture du réseau du fournisseur de service (SPN) L architecture proposée consiste en une série d entités qui se situent dans divers plans (voir Figure3). Ces entités communiquent par le biais de protocoles dépendant du plan et de la nature des entités. L architecture fonctionnelle est composée de trois plans: un plan business, un plan management plan et un plan réseau. admin Service model Policy repository Routing policies Accounting Business plane LDAP RADIUS AAA COPS Management plane Network plane Figure3. Plans fonctionnels 7

8 Plan Business : Base de politiques Politiques de routage Modèle de service Accounting Plan Management : Serveur Central AAA Serveur Central COPS Base de données SessionDB Plan réseau: Clients AAA Clients COPS Carte SIM-IP Comme le montre la Figure 4, le système d exploitation operating system (OS) exécute toutes les commandes de l utilisateur. L OS utilise la carte SIM-IP pour accéder à l équipement du terminal (TER), i.e. généralement l adaptateur réseau. Le réseau lui-même est caractérisé par un edge device i.e. un access point (AP), des serveurs responsables des fonctions de management et quelques serveurs optionnels dépendant du fournisseur. Nous proposons que la carte SIM-IP implémente une partie des core services suivants : Accès réseau utilisant 802.1x et RADIUS, QoS basé sur COPS, Accès Service basé sur une identification-ip (information encapsulée dans les paquets envoyés) Chaque fournisseur doit intégrer au minimum les services d accès au réseau et de gestion de QoS présentés dans cette section. La carte SIM-IP fait partie du réseau visité, elle est considérée comme un nœud du réseau. Elle intègre les services réseau locaux et les mécanismes de contrôle; de ce fait elle représente un élément central de l architecture globale. La carte SIM-IP se connecte au réseau (home ou visité). Etant donné la diversité des réseaux d accès, la carte SIM-IP doit supporter les méthodes d accès nécessaires pour chaque technologie. La carte doit être capable de répondre aux challenges envoyés par les edge devices des réseaux visités tels que les points d accès ou les stations de base qui sont les équipements qui contiennent les algorithmes et les éléments nécessaires. Le premier lien i.e. le lien sans fil entre le TER et l AP est protégé par un mécanisme de cryptage ISO/OSI de niveau 2 basé sur les informations stockées dans la carte. La carte SIM- IP peut vérifier l identité de l utilisateur. 8

9 Misc. servers LDAP POLICY REP LDAP XML admin Control Session DB AAA DB RADIUS + EAP Key AAA WEP EAP COPS Service Provider Network TER eap/tls L e g e n d CONF Data traffic Control traffic AP SIM IP OS ID, auth Figure4. Architecture SPN Néanmoins, le contexte WLAN est plus compliqué. Les méthodes d accès ne sont pas aussi bien définies comparées aux réseaux téléphoniques. Pour cela, nous proposons de faire appel aux méthodes proposées actuellement car elles sont plus efficaces. Les procédures de protection décrites dans cette étude sont basées sur la protection de l accès aux ressources réseau contre une utilisation non autorisée. Néanmoins, ces méthodes ne résolvent pas le problème de l identification de l utilisateur pour l accès aux services. En effet, les applications IP existantes ne possèdent pas l information de niveau 2 nécessaire pour pouvoir vérifier l identité de l utilisateur. Nous supposons que les réseaux cœur des réseaux visités sont sécurisés au moyen de protocoles usuels. Plusieurs bases de données sont nécessaires stocker l information de management. Nous distinguons principalement : - Une base de données de politiques policy repository contenant toutes les politiques nécessaires, - Une base de données AAA database (AAA DB) faisant partie de l infrastructure d authentification RADIUS, - Une base de donnée appelée Session Data Base (SessionDB) pour collecter toutes les informations sur les utilisateurs connectés au réseau fournisseur. Comme il est clairement illustré sur la Figure 4, la carte SIM-IP et les protocoles COPS et RADIUS constituent les éléments clés de notre solution globale. 9

10 4.3 La carte SIM-IP Description La carte SIM-IP est une carte SIM java intelligente qui contient une pile IP et supporte des services intégrés comme le montre la Figure 5. Similairement aux cartes SIM GSM/3G, la carte SIM-IP fournit un mécanisme pour l authentification et la facturation. Elle inclut les fonctionnalités IP et peut ainsi compléter les terminaux qui ne supportent pas nativement la pile protocolaire IP. La carte contient un ensemble de données (clés, ), les procédures d authentification, les algorithmes et stocke les données dans des fichiers XML. Elle peut exécuter des applets Java dans un environnement sécurisé. En particulier, elle intègre un serveur WEB et supporte divers protocoles tels que HTTP, LDAP, COPS, EAP, etc. Globalement, elle peut être vue comme un noeud du réseau avec des services intégrés qui offre trois principaux avantages: un service d authentification commun, fiable et extensible, une pile TCP/IP indépendente du terminal associé et opérant comme une machine hôte Internet, l opportunité d inclure des points terminaux de service sur la carte permettra de préconiser de futures solutions intéressantes. Applications Transport IP LLC Host Communication module Data Procedures X.509 CA Cert X.509 own Cert TLS Master Key NSSSK WEP ucast key WEP bcast key IP config SERVICE cfg RSA, MD5 Traffic shaper Security Interface TCP/IP Protocols EAP DHCP COPS SIM CONF TLS Figure 5. Carte SIM-IP La proposition innovante d utiliser la carte SIM-IP est très intéressante car elle permet d offrir un accès réseau sécurisé, la QoS et le support de services réseau sur la carte. Etant donné que nous suggérons dans notre solution d installer les composants réseau sur la carte, chaque carte SIM-IP sera la propriété du fournisseur. Elle est pré-configurée par le fournisseur qui la délivre et elle est vue comme un nœud confiant fiable de son réseau opéré une fois la connexion est bien réussie. Elle permet donc d intervenir et de superviser l accès au réseau. 10

11 Aussi, elle applique une classification du trafic de l utilisateur et exécute les opérations de contrôle. L accès au réseau se déroule en deux phases : - Première phase Dans la première phase, la carte se connecte au réseau du fournisseur en utilisant les informations nécessaires au contrôle d accès qui y sont installées et les algorithmes nécessaires. - Deuxième phase La carte vérifie l identité et les droits de l utilisateur (OS). Dans ce cas, la vérification de l utilisateur (OS) est très simple car elle est établie localement par des algorithmes propriétaires (PIN, password, token, etc.). Il a fallu rajouter la mise en place d une méthode sécurisée pour l accès au réseau de la carte SIM-IP spécialement dans le contexte des WLANs existants Le concept SoC (Service on Card) L architecture fonctionnelle de la carte ainsi que ses capacités IP permettent la prolongation du service du réseau jusqu à la carte. Ceci procure de nouvelles et importantes opportunités. Un fournisseur qui commercialise une carte peut installer un certain nombre de ses composants de contrôle internes tels qu un classificateur de paquets, des filtres, etc, sur la carte elle-même permettant le contrôle du comportement de l utilisateur. D un autre côté, un fournisseur peut intégrer des points d accès aux services sur la carte SIM- IP offrant ainsi à l utilisateur une palette de services disponibles directement sur la carte, indépendamment de la localisation actuelle du point terminal du service associé. Cette palette de services est appelée Services on Card (SoC). A la suite de la phase de connexion, les points d accès aux services localisés sur la carte choisissent dynamiquement le fournisseur du service (réseau home ou réseau visité) dépendant de la disponibilité du service dans le réseau visité courant ou de quelques critères (propriétés du service,.). Globalement, le service d accès au réseau représente déjà un service réseau interne prolongé jusqu à la carte SIM-IP. La carte fonctionne comme un edge device qui appartient à l infrastructure réseau. Les points de contrôle pour la QoS, la mobilité, chiffrement et la signature des paquets appartiennent à la même catégorie. Une autre catégorie contient les services usuels tels que HTTP, SMTP ou SIP. De tels services peuvent être implémentés comme des proxies configurés par défaut pour contacter le home network. Le fournisseur de services qui délivre la carte peut assurer la disponibilité du service dans son réseau et concevant sa carte selon son offre. Dans le cas de la présence de service dans le réseau visité, le proxy SoC peut être reconfiguré dynamiquement par la logique de la carte et utilise le service localement dans le réseau du fournisseur. L avantage de cette approche est la capacité de fournir l accès aux services du home network, une grande disponibilité des services et une transparence complète du service pour l utilisateur. Mais est ce que cette approche est-elle réalisable et raisonnable? Soient P1,,Pn un ensemble de fournisseurs avec leurs ensembles de services associés SS1,,SSn, i.e. pour chaque Pi on définit un SSi := {Service1,, ServiceN}. Dans le cas où tous les ensmbles de services sont équivalents (SS1 = = SSn) l utilisateur peut toujours être sûr de trouver un service dans le réseau visité. Dans le cas où les services sets sont complètement disjoints, les services du réseau visité sont inconnus à la carte et les services home ne sont pas disponibles dans le réseau visité. Cela implique une connexion permanente au réseau home. Sous certaines conditions not even l accès au réseau visité n est pas possible, dans ce cas, on parle de minimal service subsets (MSS) défini comme l intersection des services sets de tous les fournisseurs impliqués. Pour un fonctionnement minimal correct, il 11

12 serait raisonnable que le MSS comporte au minimum tous les services indispensables pour les fonctionnalités de management (accès, QoS, etc.). Par ailleurs, pour le support de la QoS, un module spécifique est intégré dans la carte SIM-IP qui est le traffic classifier. Son rôle majeur est de classifier les paquets IP selon le niveau de priorité de la classe de trafic. Des classes de trafic différentes sont définies; chacune d elles possède des propriétés communes concernant divers critères (délai, bande passante,..). A chaque classe est attribué un niveau de priorité. OS SOC Proxy http applet applet applet core CONF EAP/TLS COPS CONF.. os Carte Si, i=1 N Many cases -Si on card - Si available in HN (home network) or in VN (visisted network) HN VN Figure 6. Carte SIM-IP et SoC Implications La carte SIM-IP exige certains changements dans la configuration du système. Tout d abord, les applications sur la machine hôte (OS) doivent être configurées de manière appropriée pour pouvoir utiliser les SoCs. Si un utilisateur utilise un serveur SMTP dans son réseau de fournisseur il peut configurer un serveur sur la carte. Ce serveur fonctionnera comme un SMTP-smarthost relayant le message au serveur SMTP utilisé. Nous devons prévoir un mécanisme de découverte ou de configuration dynamique dans la carte elle même, car après ou durant la phase d authentification la carte doit avoir les informations nécessaires sur les services actuellement disponibles dans le réseau visité. Au minimum, pour chaque SoC il serait raisonnable de reconfigurer les proxies sur la carte. Finalement, les implications sur la sécurité doivent être étudiées sérieusement pendant l installation des éléments réseau sur la carte. Classiquement, les protocoles réseau ne sont pas suffisamment sécurisés et dans le but de prévenir contre les attaques de tels protocoles feront appel à d autres méthodes de protection telles que (IPSec, secure tunneling, etc.) ou une conception réseau appropriée (séparation physique entre le trafic de l utilisateur et celui du fournisseur). Evidemment, nous devons sécuriser le trafic qui est véhiculé sur les liens wireless contre les attaques possibles. 12

13 4.4 Common Open Policy Service protocol (COPS) COPS [9] est un protocole proposé pour permettre l échange de l information de contrôle entre des entités réseau spécifiques. Ces informations sont liées à des politiques. Le standard décrit une architecture centralisée qui comprend un central policy decision point () et un ensemble de policy enforcement points () généralement installés dans les edge devices du réseau. Ce type d architecture permet l installation et le contrôle d une politique de QoS centralisée sur le, l adaptation dynamique en fonction la charge du réseau et le contrôle du trafic au niveau du network edge. Dans la solution que nous proposons, COPS joue un des rôles prépondérants. Néanmoins, dans le contexte des liens de communication sans fil avec des ressources partagées limitées, ceci a une incidence néfaste : le lien entre l équipement terminal et le edge device constitue le maillon faible de la sécurité de l architecture globale. Nous proposons d installer le sur la carte SIM-IP (see Figure 4). Les avantages principaux de cette intégration sont : - appliquer des politiques de QoS dépendant de la charge du lien - contrôler le trafic de l utilisateur à sa source en empêchant l OS (user) d envoyer des paquets incorrects. - optimiser la charge les liens sans fil. Il y a des aspects sécurité qui sont étroitement liés à cette proposition du moment que le protocole COPS est non protégé et nous voulons installer ces entités en différents poins terminaux des liens sans fil. Cependant, comme l information COPS est échangée après terminaison avec succès de la phase de connexion de la carte SIM-IP au réseau visité, les paquets vont traverser la distance séparant la carte du core network sécurisé par des liens crypté (per-user L2-encrypted link). Ce qu il faudra assurer est un mécanisme de cryptage fiable, un autre utilisateur ne peut pas lire les données transmises par l AP ou par la carte même si l utilisateur est connecté au même AP. Ceci est particulièrement possible en utilisant des clés WEP dynamiques (en attendant la disponibilité de WEPv2). Une description détaillée de l architecture de contrôle de la QoS est donnée en Section 6. 5 Architecture d accès au réseau Typiquement, les apects sécurité consituent l élémént clé dans chaque réseau de fournissuer. Dans cette Section, nous donnons les éléments de réponse que nous proposons pour sécuriser l architecture 4G en prenant en compte le roaming global de l utilisateur. 5.1 Sécurisation de la connexion Carte réseau par 802.1x Comme il été mentionné, il est impératif de résoudre le problème de la sécurisation de la connexion entre la carte SIM-IP et le réseau visité dans le contexte des WLANs. Nous proposons d utiliser une architecture basée sur IEEE 802.1x [10] avec EAP/TLS [11] pour le contrôle d accès aux WLANs. Cette solution permettra de pallier à un nombre considérable de failles de sécurité [12] décelées dans le modèle d authentification par clé partagée basée sur WEP (SKA shared key authentication) dans les systèmes WLANs [13]. L architecture en question consiste en un élément central qui est qui est le EAP/TLScapable RADIUS-server et plusieurs RADIUS [14] et 802.1x capable APs. De plus, dans notre proposition, chaque machine hôte est équipée de la carte SIM-IP qui stocke la clé privée de l utilisateur (sous forme de certificat), les certificats des autorités de certification (CA) et les algorithmes nécessaires pour la méthode EAP/TLS (voir Figure 7). La carte SIM-IP et le serveur RADIUS établissent une authentification mutuelle en utilisant TLS [15] véhiculés 13

14 dans des trames EAPOL [10] et négocient un secret TLS master secret [15]. Les deux côtés dériveront les clés de communication appelées Negotiated Shared Session Secret Keys (NSSSK) indépendamment. Le serveur RADIUS envoie cette clé à l AP avec la confirmation de l authentification comme il a été décrit dans [16]. L AP ouvre le port de communication associé, crée les clés WEP dynamiques et les envoie à la carte SIM-IP signés et cryptés par la clé de communication (NSSSK) dans la trame EAPOL-Key [10]. La méthode EAP/TLS est alors enclenchée i.e. la carte SIM-IP installe les clés WEP reçues dans l adaptateur réseau et active la procédure de chiffrement WEP sur le lien. La transmission des données sur le lien sans fil n est possible qu après la confirmation de l identité de la carte. Cette transmission est cryptée en utilisant les clés WEP dynamiques. L AP peut et devrait changer les clés utilisées fréquemment. En attendant l achèvement des travaux sur WEPv2, cette méthode est considérée comme la meilleure procédure à adapter pour protéger nativement la connexion de la carte SIM-IP au réseau du fournisseur dans le contexte du WLAN. Phases 1. Phase: Card conn 2. Phase: Card conf 3. Phase: User auth 4. Phase: QoS 5. Phase: Data Misc. servers LDAP POLICY REP LDAP XML admin COPS Control Session DB AAA DB Key AAA TER eap/tls CONF WEP EAP RADIUS + EAP DHCP, SIRUP SIM IP Service Provider Network L e g e n d OS Data traffic Control traffic AP ID, auth Figure 7 : Architecture d accès sécurisée 5.2 Roaming La carte SIM-IP est responsable de la vérification de l identité et du profil de l utilisateur, du contrôle de trafic et de l accès aux services. Du moment que l utilisateur se connecte toujours via sa carte SIM-IP, il n y a pas de nécessité pour le user roaming dans notre architecture. Après la reconnexion de la carte, l utilisateur peut simplement utiliser les services de la même manière indépendamment du réseau visité. Plus spécialement, nous avons à mettre en place des mécanismes pour le roaming de la carte SIM-IP. Plus précisément, nous distinguons trois aspects liés à ce problème. Roaming et accès au réseau, Roaming et Configuration de la carte SIM-IP, Roaming et accès aux services. Une description de chacune de ces situations est décrite dans les sections suivantes. 14

15 5.2.1 Roaming et accès au réseau Le standard IEEE 802.1x proposé dans le contexte actuel pour renforcer la sécurité de l accès aux réseaux sans fil recommande l utilisation d un serveur RADIUS en tant que serveur d authentification. Pour supporter le roaming en utilisant RADIUS, de mineurs changements doivent être réalisés. La méthode utilisée 802.1x EAP/TLS exige l utilisation d autorités de certification et le déploiement de certificats. Cependant, une infrastructure commune Public Key Infrastructure (PKI) n est pas nécessaire i.e. chaque fournisseur peut simplement installer et maintenir sa propre et indépendante CA. Le déploiement de certificats est donc particulièrement facile, du moment que les certificats doivent être installés sur la carte et cette dernière est délivrée par le fournisseur. En utilisant la fonctionnalité proxying [14] de RADIUS, nous pouvons assurer le roaming de la carte au moyen de 802.1x mis en place localement. La conversation EAP/TLS a lieu entre la carte SIM-IP et le home RADIUS-server en traversant l AP et le foreign RADIUS-server. Le home RADIUS-server délivre la clé de session (NSSSK) au foreign RADIUS server qui la transmet à l AP concerné. Une interconnexion des serveurs RADIUS des différents fournisseurs devra être établie permettant le proxying. Pour des raisons de sécurité, nous proposons d interconnecter les serveurs RADIUS en utilisant le protocole IPSec. Une description détaillée des échanges protocolaires, des considérations de sécurité et des solutions plus optimisées sont données dans l article [17]. user SessionDB information server services SPN1 Secure communication by IPsec Identification IP SPN Roaming et configuration de la carte SIM-IP La procédure globale de connexion se déroule en quatre phases principales: 1. La carte se connecte au réseau visité, négocie les clés WEP et établit un lien crypté en appliquant un chiffrement de niveau 2 (voir description section précédente). 2. La carte lance une requête DHCP et obtient une adresse IP et l adresse IP du serveur SessionDB. La carte se connecte au serveur SessionDB en utilisant la procédure propriétaire SIM-IP Roaming Update Protocol (SIRUP). La SessionDB se connecte au réseau home de la carte, si nécessaire, en utilisant RADIUS et échange des informations de facturation concernant l utilisateur. Au cours de la procédure SIRUP, la carte obtient les informations sur la configuration, les services disponibles et les descripteurs des classes QoS, etc. 3. La carte présente un système à login à l utilisateur lui proposant des informations sur le réseau visité, i.e. un ensemble particulier de services disponibles et les prix. L utilisateur se connecte en utilisant la combinaison login/password. 4. En se basant sur le choix de l utilisateur ou sur les applications lancées; la carte négocie et réserve la QoS. Le protocole SIM-IP Roaming Update Protocol (SIRUP) constitue la partie la plus importante du processus. Ce protocole doit être développé mais comme la carte est déjà équipée de la pile du protocole TLS (méthodes existantes (RSA, MD5, etc.) et http), nous projetons de le baser sur HTTPS (support d applets, intégration de Java dans http). En effet, 15

16 puisque le serveur RADIUS et la méthode EAP/TLS ont déjà négocié une clé TLS master secret, nous pouvons directement passer à la phase suivante du protocole qui encapsule tout le trafic HTTP. Pour cette raison, le serveur RADIUS écrit l information relative à la clé dans la base de données SessionDB juste après une connexion de l utilisateur avec succès. Au cours de la conversation SIRUP TLS, la SessionDB installe le mapping bidirectionnel IPto-user qui extrait les paquets arrivés. Il donne accès à cette information à tous les services réseau enregistrés. En plus de l information sur les calsses QoS disponibles et les services, la carte peut télécharger et installer de nouvelles applets. Elles peuvent être des proxies ou, dans le home network, des updates des core services. La carte utilise l information réseau obtenue dans le but de configurer correctement ses points d accès aux services Roaming et accès aux services Le mécanisme de cryptage de niveau a lieu entre la carte SIM-IP et l AP. Ainsi, après que les paquets arrivent dans la partie IP du réseau du fournisseur, l information sur l identité de l utilisateur est perdue. Donc, comment peut-on identifier l utilisateur afin de lui offrir un accès à des services personnalisés? La seule information qui reste incluse dans le paquet IP est la source IP address elle-même. A cause de la simplicité de l attaque de IP-spoofing, ce mécanisme ne peut pas être utilisé pour l identification de l utilisateur. Moyennant certains changements, cette simple et puissante méthode d identification peut-être réutilisée de manière sécurisée. L information relative à la IP-configuration délivrée à la carte par DHCP est transportée sur le lien crypté (avec cryptage de niveau 2) et ne peut être sniffé par les attaquants. La machine hôte OS réagit avec une requête DHCP sur l événement de l établissement de lien. Ce message sera intercepté et la carte SIM-IP va y répondre, ainsi l OS (user) recevra l information IP nécessaire. A partir de ce moment, tout paquet délivré par l OS sera vérifié par la carte SIM-IP sur l exactitude de l adresse IP source. En supposant que des mécanismes de sécurité sont établis par le fournisseur lui-même au sein de son réseau, le mécanisme de chiffrement de niveau 2 jusqu au edge device et l impossibilité de faire du IP-spoofing par les utilisateurs connectés (grâce au contrôle initié par la carte), aucun paquets avec une fausse adresse IP ne peut entrer dans le réseau. Les serveurs doivent être localisés dans la partie IP du réseau du fournisseur, qui est physiquement ou logiquement (subnetting, firewall or packet filter) protégée contre les accès. Le mapping (identité utilisateur-adresse IP) est effectuée au sein de la SessionDB. Ce mapping peut être facilement obtenu par tous les serveurs. La SessionDB installe les règles appropriées de routage pour les adresse IP source des cartes autorisant ou refusant le trafic Internet. Chaque service demandé par une source IP peut identifier l utilisateur en interrogeant la SessionDB. Pour le roaming, les fournisseurs concernés établissent un tunnel IPSec. Le trafic généré par la carte ayant une adresse IP source destiné à son réseau home doit être routé via ce tunnel IPSec. Donc, le mapping IP-to-user obtenu à partir de la SessionDB du réseau visité peut aussi être utilisé par le réseau home afin d autoriser/bloquer/facturer l accès au service. 6 Architecture globale de contrôle de la qualité de service par politique 6.1 Introduction Les contrôles à effectuer dans un réseau IP ont été mis dans la machine terminale au début de l Internet et continue de l être en grande partie. Par exemple, la fenêtre de contrôle de flux avec son algorithme du «Slow Start and Congestion Avoidance» est gérée dans le protocole TCP de la machine terminale. Pour améliorer ce contrôle, les routeurs du réseau sont devenus 16

17 plus complexes et intègrent des éléments de configuration du routeur, par exemple la prise en charge d une politique de gestion de la qualité de service comme DiffServ. L inconvénient de cette solution provient d une chaîne protocolaire qui se divise en deux parties : une partie allant de la machine terminale au routeur de bord et une partie allant du routeur de bord au serveur ou à l utilisateur distant. Une des difficultés provient de la sécurisation de la liaison entre l équipement terminal et le routeur de bord. En effet, les décisions de sécurité décidées par le réseau ne peuvent que démarrer du routeur de bord. De plus, le routeur de bord se retrouve à devoir gérer une quantité importante de flux et à mémoriser toutes leurs caractéristiques. De plus, lorsqu un client est mobile, son routeur de raccordement change et donc nécessite une nouvelle négociation avec l utilisateur pour s adapter à sa demande. Nous pensons que le contrôle des futurs grands réseaux qui allieront à la fois des terminaux fixes et des terminaux mobiles demande une forte intelligence dans le terminal de l utilisateur, d autant plus que ce terminal est de plus en plus puissant et permet donc la décentralisation de la puissance nécessaire au contrôle des flux dans le terminal. La décentralisation vers l équipement terminal permet également de mieux prendre en compte les demandes de l utilisateur. Bien évidemment cette décentralisation demande une sécurité plus importante de la partie du terminal qui contrôle les accès au réseau. En effet, ne faut pas que le client puisse modifier la valeur des paramètres déterminés par le serveur de politique. Il faudra donc sécuriser une partie du terminal, cette partie pouvant être vue comme une extension de l opérateur dans le terminal, comme la carte à puce qui se trouve dans un combiné GSM (Global System for Mobile communication). Nous y reviendrons plus longuement dans la suite de ce rapport. Nous nous intéressons ici à définir une nouvelle architecture qui utilise un environnement contrôlé par politique et qui repousse les fonctions de contrôle dans le terminal de l utilisateur, qu il soit fixe ou mobile 6.2 L architecture de contrôle par politique Les politiques peuvent être définies comme un ensemble de règles capables de gérer et de contrôler l accès aux ressources d un réseau. L apparition de ce concept de gestion par politique provient du besoin de simplifier la configuration des routeurs par un mécanisme automatique. De nombreux domaines s intéressent à cette gestion par politique dont le plus avancé concerne la qualité de service (QoS) mais également la sécurité et la gestion de la mobilité. Un nouveau protocole de signalisation a été introduit, COPS [9], définissant un nouvel ensemble architectural. Pour généraliser cette approche, un groupe de travail a été formé à l IETF (Internet Engineering Task Force) pour spécifier le modèle d information et parfaire l architecture générale. Le but du modèle d information est de définir un modèle général qui puisse s adapter aux différents domaines de la gestion et du contrôle dans les réseaux, et ceci de façon totalement indépendante du type d équipements physiques. Le cœur du modèle d information de l environnement politique, Policy Core Information Model (PCIM), est une extension du modèle CIM (Common Information Model) du DMTF (Distributed Management Task Force). Le réseau est vu comme une machine à états où les politiques sont là pour contrôler les changements d état. Il faut dans cet environnement être capable d identifier et de modéliser les états en cours et de définir les transitions possibles à partir des règles définissant les politiques [2]. Ce modèle définit les rôles, les priorités et les ordres d exécution, mais il reste dans une forme abstraite en ce qui concerne les objets. Les travaux en cours concernant la QoS définissent deux niveaux d extension : le modèle QPIM (QoS Policy Information Model) et le modèle QDDIM (QoS Device Datapath 17

18 Information Model). Le premier intègre des notions spécifiques à la QoS, pour être capable de créer des représentations formelles de politiques abstraites, tel que : «si le protocole est de type http et si sa destination appartient au groupe des utilisateurs «executives» alors donner la valeur IPP 7 dans l en-tête du paquet». Dans ce but, le modèle définit des actions de politiques (Policy Actions) comme l'acceptation de réservation de ressource dans RSVP (Resource reservation Protocol), le provisionning de politiques dans les routeurs ou la configuration d'un PHB (Per Hop Behaviour), et un modèle de trafic, pour spécifier la gestion d une demande ou l arrivée d un flot. Le modèle QDDIM est utilisé avec le premier modèle pour définir des actions à entreprendre sur les équipements, c est-à-dire sur leur configuration. Le modèle QPIM définit donc des actions précises à réaliser sur les paquets. L architecture définit un modèle centralisé pour la gestion, le stockage des politiques, la prise de décision, et la distribution des paramètres de configuration aux routeurs. Cette architecture est décrite à la figure 8. Policy Management Tool Policy Repository Figure 8 L architecture de gestion par politique Le (Policy Decision Point) est responsable de la prise de décision à sa propre initiative ou en réagissant à une requête provenant d un élément du réseau. Le doit déterminer la configuration à mettre en place et les ressources à y affecter pour satisfaire la demande. Ses principales fonctions concernent la détermination des règles de politique à appliquer aux différents (Policy Enforcement Point), leur conversion dans un format adapté, (PIB (Policy Information Base), MIB (Management Information Base) ou autre solution), et la garantie de leur bonne distribution. Un est une entité logique qui applique les décisions provenant des politiques choisies. Un correspond à des ressources offrant différents types de services, ressources qui sont configurées pour exécuter les politiques décidées par le. Les fonctions principales d un consistent à relier les représentations externes (PIB, MIB, etc.) à la configuration interne des équipements de réseau et de maintenir une compatibilité entre les politiques appliquées. Quand le se trouve sur un élément d extrémité du réseau (un routeur d accès), il est également responsable de faire remonter les requêtes vers le. Le modèle d architecture ne requiert aucun protocole de communication spécifique ou méthode d accès à un serveur de stockage de politiques. Cependant, le protocole COPS et le protocole LDAP semblent être les solutions les plus admises pour les communications avec un ou un répertoire de politiques. 6.3 Le protocole COPS et l'extension COPS-SLS COPS (Common Open Policy Service) [9] est un protocole de type requête/réponse simple fondé sur le protocole TCP. Il a été proposé par le groupe RAP (Resource Allocation 18

19 Protocol) de l'ietf pour transporter des politiques dans le contexte de la gestion par politique (Policy-Based Management) [18]. La figure 9 illustre l'utilisation du protocole COPS Nœud réseau COPS Serveur de politiques L Figure 9 - Le protocole COPS dans l'architecture de gestion par politique Ce protocole ne définit que des messages très génériques assurant le passage des politiques entre le et le. L'utilisation réelle du protocole est définie dans ses extensions. COPS est un protocole flexible dans le sens où il peut être appliqué à plusieurs domaines de politiques (comme les politiques de «provisioning» de la QoS, les politiques d'authentification d'accès au réseau, etc.). Chaque message COPS comprend un en-tête et des objets. Pour introduire une extension du protocole COPS, il suffit de définir les objets appropriés et une valeur de Client-Type. Cette dernière est indiquée dans le champ Client- Type de l'en-tête du message COPS. Selon cette valeur, les objets suivants sont traduits d'une manière appropriée. Par exemple, COPS-RSVP est une extension du protocole COPS avec une valeur "Client-Type = 1". Ses objets transportent des politiques pour le contrôle d'admission des messages RSVP. COPS-PR pour DiffServ est une autre extension du protocole COPS. Ses objets transportent des politiques pour configurer des routeurs DiffServ. COPS-IP-TE est une autre extension du protocole COPS. Ses objets transportent des politiques pour l ingénierie du trafic. Les valeurs du Client-Type de ces deux dernières extensions ne sont pas encore attribuées. Il existe deux modèles de contrôle de politique : le modèle Outsourcing et le modèle Provisioning. Dans le modèle Outsourcing (par exemple COPS-RSVP), quand la requête de demande de ressources arrive au (un message RSVP arrive à un routeur RSVP), le envoie une requête au pour réclamer la configuration à mettre en place pour traiter cette demande. La politique sera appliquée pour configurer le routeur une fois la politique acceptée par l utilisateur. Dans le modèle Provisioning (cas de COPS-PR pour DiffServ), le demande au les politiques à appliquer lors de sa mise en route. Quand la requête d ouverture arrive au (c est-à-dire un paquet DiffServ arrive à un routeur DiffServ), le n'envoie pas de requête vers le mais applique les politiques correspondantes déjà installées (mettre le paquet dans la file BE (Best-Effort), changer la valeur du champ DSCP, ). COPS-SLS [19] [20] est une extension du protocole COPS pour la gestion des SLS (Service Level Specification). Cette extension a été proposée par le LIP6 et l'enst à la 51ème réunion de l'ietf à Londres en août Ce protocole a pour but de négocier des politiques entre un et un pour établir un niveau de service d'un flux de données. De plus, la négociation de SLS entre domaines administratifs peut également être effectuée avec COPS-SLS. Un SLS est un ensemble de paramètres et leur valeur qui définissent le service offert à un flux de données. Pour négocier un niveau de service avec un fournisseur d accès réseaux, le client envoie le SLS souhaité à son ISP (Internet Service Provider). L'ISP peut accepter, 19

20 rejeter le SLS ou proposer un autre niveau de service au client. Lorsqu un accord a pu être obtenu entre les deux parties, le contrat est signé et les données de l'utilisateur peuvent traverser l'isp en bénéficiant du niveau de service négocié. L'intérêt de ce protocole concerne la négociation du SLS qui est automatisée : le client peut facilement entrer en contact avec son ISP et gérer son SLS. D autre part, l'isp peut utiliser ses ressources réseaux plus efficacement et il peut facilement négocier un niveau de service avec d'autres ISP pour réaliser des communications inter-domaines. L'idée de COPS-SLS est d'appliquer la technologie de gestion par politique pour la gestion des niveaux de service dans un domaine. L'ISP crée des politiques de négociation de SLS du domaine. Ces politiques reflètent la stratégie de négociation de l'isp et permettent au de savoir comment répondre à une demande de SLS. La figure 10 illustre le modèle introduit par COPS-SLS. Dans le modèle de COPS-SLS, le représente le fournisseur réseaux et le représente le client. Le est une entité logique qui négocie avec le fournisseur réseau un niveau de service pour lui-même ou au nom d'autres entités. C'est pourquoi, le client peut être un équipement terminal, une passerelle d'un réseau local ou juste une entité représentant un ISP. COPS-SLS est la première extension du protocole COPS qui se propose de mettre le dans un équipement terminal. Dans les extensions proposées auparavant, le est mis dans les routeurs du réseau (routeurs de bord, routeurs de cœur ). Dans le contexte d une négociation de SLS, mettre le dans l équipement terminal permet d introduire la meilleure politique correspondant à chaque type de client ou même à chaque client. Équipement terminal connecté par modem Passerelle du réseau local COPS-SLS COPS-SLS COPS-SLS Serveur de politiques ISP Client ISP Figure 10 - Le modèle de COPS-SLS COPS-SLS comprend deux phases : la phase de configuration et la phase de négociation. La phase de configuration détermine la manière de négocier. La phase de négociation s'occupe de l'échange des informations nécessaires à la définition d un SLS entre le et le, pour établir un contrat. La phase de négociation est paramétrée et configurable par la phase de configuration. Par exemple, la phase de configuration peut vérifier dans le les classes PIB utilisables dans la négociation. Elle peut aussi spécifier que la négociation sera fondée sur des SLS prédéfinis ou non-prédéfinis. Normalement, le client passe d'abord par la phase de configuration. Le utilise le modèle Provisioning pour installer dans le des politiques concernant la manière de négocier le SLS. Après avoir installé cette configuration, le peut commencer la phase de négociation et envoie au son SLS souhaité. Le répond par le message DEC pour accepter ou rejeter la requête ou proposer un autre SLS au client. Le client installe la décision 20