127 Contrôle des réseaux IP fixes et mobiles Thi Mai Trang Nguyen, Guy Pujolle, Nadia Boukhatem, Dominique Gaïti Résumé Nous décrivons dans cet article l architecture générale fondée sur le concept de gestion par politique pour être capable de contrôler un réseau acceptant aussi bien des connexions depuis des terminaux fixes que mobiles. Cette gestion par politique s étend à l interconnexion de tels réseaux. Cette architecture est fondée sur une nouvelle génération de protocoles provenant de la famille (Common Open Service). Plus spécifiquement, le protocole que nous proposons permet de configurer l infrastructure complète d un ensemble de réseaux IP. Ce contrôle s appuie sur la définition d un SLS (Service Level Specification) permettant la définition par un client de sa qualité de service, sa sécurité et sa mobilité. Cette solution repousse tout un ensemble de fonctionnalités dans la machine terminale au lieu de les trouver dans le routeur de bord. Mots-clefs Réseaux IP, Contrôle, Gestion par politiques. I. INTRODUCTION es contrôles à effectuer dans un réseau IP ont été mis dans L 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 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. Thi Mai Trang Nguyen is with LIP6, University of Paris 6 and ENST, 46 rue Barrault, 75013 Paris, France (e-mail: trnguyen@enst.fr) Guy Pujolle is with LIP6, University of Paris 6, 8 rue du Capitaine Scott, 75015 Paris, France (e-mail: Guy.Pujolle@lip6.fr). Nadia Boukhatem is with ENST, 46 rue Barrault, 75013 Paris, France (email: Nadia.Boukhatem@enst.fr) Dominique Gaïti is with LIP6 and University of Technology of Troyes, BP 2060, 11010 Troyes Cedex, France (e-mail: Dominique.Gaiti@utt.fr) 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 cet article. Cet article s intéresse à 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. La section 2 présente les principes de base de cette architecture fondée sur les politiques. La section 3 décrit le protocole de la famille qui a été développé pour gérer directement la demande de service entre l équipement terminal et le réseau. La section 4 introduit l architecture générale et la décentralisation des mécanismes de contrôle. Enfin, la dernière section, introduit l environnement de sécurité qui est développé dans l architecture proposée. II. L ARCHITECTURE DE CONTROLE 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, [1], 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
128 indépendante du type d équipements physiques. Le cœur du modèle d information de l environnement politique, 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 Information Model) et le modèle QDDIM (QoS Device Datapath 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 ( 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 1. Management Tool conversion dans un format adapté, (PIB ( 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 et le protocole LDAP semblent être les solutions les plus admises pour les communications avec un ou un répertoire de politiques. III. LE PROTOCOLE ET L'EXTENSION (Common Open Service) [1] 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 Protocol) de l'ietf pour transporter des politiques dans le contexte de la gestion par politique (-Based Management) [2]. La figure 2 illustre l'utilisation du protocole Nœud réseau Serveur de politiques L Repository Figure 2 - Le protocole dans l'architecture de gestion par politique Figure 1 L architecture de gestion par politique Le ( 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 ( Enforcement Point), leur 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. 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 comprend un en-tête et des objets. Pour introduire une extension du protocole, 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. Selon cette valeur, les objets suivants sont traduits d'une manière appropriée. Par exemple, -RSVP est une
129 extension du protocole avec une valeur "Client-Type = 1". Ses objets transportent des politiques pour le contrôle d'admission des messages RSVP. -PR pour DiffServ est une autre extension du protocole. Ses objets transportent des politiques pour configurer des routeurs DiffServ. -IP-TE est une autre extension du protocole. 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 -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 -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, ). [3] [4] est une extension du protocole 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 2001. 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. 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, 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 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 3 illustre le modèle introduit par. Dans le modèle de, 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. est la première extension du protocole 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 ISP Client Figure 3 - Le modèle de Serveur de politiques ISP 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 nonpré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 et envoie un rapport d'installation au. Si la décision et le rapport sont positifs, le contrat est signé et le client bénéficie du niveau de service négocié. Dans le cas contraire, aucun contrat n'est établi. A n'importe quel moment, le peut envoyer une décision
130 non-sollicitée avec un 'context = configuration' pour reconfigurer la manière de négocier ou avec un 'context = ressource allocation' pour dégrader le niveau de service, si nécessaire. Les informations de SLS échangées entre le et le sont représentées sous la forme d'une structure de données nommée une PIB ( Information Base). Des instances des classes de la PIB sont encapsulées dans des objets ClientSI (Client Specific Information) [1]. Des objets Named ClientSI servent à transporter des informations de configuration. Des objets Signaled ClientSI servent à transporter des informations de négociation. L'utilisation de la PIB pour la représentation de SLS permet de répondre à la diversité des paramètres de négociation souhaités par différents fournisseurs réseaux. peut-être appliqué dans plusieurs cas. Un Intranet peut gérer différents niveaux de qualité de service, fournis par le réseau. Un domaine peut, d'une part, gérer des niveaux de service pour des flux intra-domaine et, d'autre part, négocier avec un autre domaine pour fournir un certain niveau de service aux flux inter-domaines. En résumé, a trois caractéristiques : il utilise les principes de la gestion fondée sur les politiques, il définit deux phases (configuration et négociation) et il utilise la notion de PIB pour représenter des informations de SLS. C'est un protocole flexible permettant la négociation dynamique de SLS aussi bien interdomaines qu'entre un client et un réseau. IV. L ARCHITECTURE GLOBALE L architecture globale a été définie principalement à l IETF au départ puis a été complétée par le 3GPP pour son architecture de réseau et en particulier pour le réseau cœur de la troisième génération de mobiles. Cette architecture est conçue pour un cœur de réseau et non pour les réseaux d accès et en particulier pour les réseaux sans fil ou les réseaux de mobiles. Cette architecture permet de mettre en place la communication en deux temps. Le premier temps correspond à l ouverture d une session de niveau application pour être sûr qu une communication entre les deux entités extrémités peut être mise en place. Une fois cette association effectuée, il faut vérifier que des ressources sont disponibles dans l infrastructure du réseau pour que la communication soit possible. De plus, il faut que la communication puisse se faire avec la qualité de service, la sécurité et la mobilité correspondant au besoin de l application. De façon plus précise, un client souhaitant entreprendre une communication va dans un premier temps envoyer une demande de session de niveau applicatif. Cette demande s effectue par le biais du protocole SIP (Session Initiation Protocol). Cette requête arrive dans le routeur de bord du réseau cœur qui lui-même transmet cette demande au SCD (Service Control Domain). Le SCD accepte ou non la communication et retourne une acceptation ou un refus au routeur de bord qui laisse entrer la requête SIP dans le réseau ou envoie une réponse négative au terminal. Cette première étape correspond donc à la session de niveau application. Une fois cette connexion acceptée, le système doit allouer les ressources nécessaires pour garantir la qualité de service et garantir la sécurité de la communication. Il doit également gérer la mobilité du terminal pour permettre une continuité de la communication lorsque le terminal se déplace, toujours en maintenant la qualité de service et la sécurité. Pour cela une requête RSVP est émise vers le routeur de bord. Cette requête est prise en charge par le routeur de bord qui transforme la requête RSVP en une requête pour l envoyer au RCD (Ressource Control Domain). Après décision du RCD et une réponse positive, la requête RSVP peut entrer dans le réseau et réserver les ressources nécessaires à la réalisation de la communication. Cette solution a comme inconvénient majeur l utilisation de trois protocoles différents qui se succèdent dans le temps. L architecture actuelle, proposée par l IETF et le 3GPP, est décrite à la figure 4. SIP RSVP Service Control Domain (SCD) editor Ressource Control Domain (RCD) Opérateur console repository Figure 4 L architecture classique de contrôle de la communication management tool L objectif de l architecture qui est proposée dans cet article est d unifier l environnement protocolaire en n utilisant qu un seul protocole permettant à la fois la négociation pour mettre en place la session et les ressources nécessaires. Un second objectif est de positionner les instances de contrôle à l entrée du réseau dans le terminal lui-même. L architecture que nous souhaitons promouvoir dans cet article est décrite à la figure 5. Dans cette architecture, le est repoussé dans le terminal qu il soit fixe ou mobile. Les raisons de cette décentralisation vers la périphérie du réseau ont déjà été évoquées à différentes reprises : simplification de la gestion des différentes phases, utilisation d un seul protocole, décentralisation de la puissance, gestion simplifiée de la mobilité, etc. L étape suivante consiste à utiliser le protocole depuis le terminal jusqu au et l utilisation de ce même protocole entre les des domaines administratifs différents jusqu au domaine où réside le terminal distant. De nombreuses extensions ont également été proposées pour gérer la mobilité des terminaux dans ce type de
131 contexte. Pour compléter cette architecture deux points sont encore à prendre en compte, l implantation d un logiciel de contrôle dans le terminal et une sécurisation du et de ces algorithmes de contrôle pour que le client ne puisse pas les modifier. Nous abordons cette préoccupation dans la section suivante. également être développés, comme la carte à puce virtuelle qui associe à la carte à puce un environnement d exécution protégé autour du processeur situé dans le terminal. Smart card editor Human network manager management tool Smart card console repository Figure 6 L architecture de sécurité Figure 5 L architecture unifiée et décentralisée V. SECURITE La solution que nous préconisons est du même type que celle mise en place dans l architecture GSM. Dans cette architecture, une carte à puce permet de stocker de façon sécurisée les informations nécessaires à l authentification du client. Dans notre cas, nous avons également choisi une carte à puce mais avec plus de puissance pour y mettre une grande partie des algorithmiques de contrôle dépendants de l opérateur. En fait, la carte à puce peut être vue comme une extension de l infrastructure opérateur, placée dans le terminal de l utilisateur. Le choix d une carte à puce Java (Java card) avec une puissance d une centaine de MHz et d une capacité de 1 Moctet a été effectué pour permettre le traitement des algorithmes de contrôle. Cette architecture est décrite à la figure 6. La carte à puce sert de coffre-fort pour les algorithmes du et de contrôle (qui sont du type classificateur, droper, meter, etc.). Cette carte à puce permet également d authentifier le client, de chiffrer les paquets transmis et de signer ses paquets de sorte à protéger la communication. L algorithme d authentification utilise un serveur d authentification, un serveur Radius situé dans le SCD [5]. Le protocole, à partit du client situé dans la carte à puce, se charge de la communication entre le client et le serveur d authentification. De plus, la carte porte une clé publique utilisée pour signer régulièrement des paquets. Le véritable problème provient de la puissance de la carte Java qui peut s avérer insuffisante pour le travail qui lui est conféré. Cette insuffisance sera vite résolue par l arrivée de carte encore plus puissante. D autres concepts peuvent VI. CONCLUSION Cet article introduit de nouveaux concepts qui pourraient être à la base de la future génération Internet qui intègre l Internet d aujourd hui et les réseaux de télécommunications. Ces concepts sont fondés sur l introduction d un environnement distribué contrôlé par politique qui prend place sur le terminal de l utilisateur. Nous avons proposé une extension du protocole pour permettre une négociation directe du SLS entre l équipement terminal et le réseau. Ce protocole permet de gérer la qualité de service, la sécurité et la mobilité d une communication partant d un équipement terminal. Cette architecture, se servant de la puissance des équipements terminaux d aujourd hui, peut également trouver sa place sur le routeur de bordure pour permettre de raccorder les terminaux qui ne seraient pas dotés d une carte à puce. REFERENCES [1] J. Boyle, R. Cohen, D. Durham, S. Herzog, R. Raja, A. Sastry, The (Common Open Service) Protocol, RFC 2748, January 2000. [2] Yavatkar, R., Pendarakis, D. and R. Guerin, A Framework for Based Admission Control, RFC 2753, January 2000. [3] T.M.T. Nguyen, N. Boukhatem, Y. Ghamri Doudane, G. Pujolle, - SLS: A Service Level Negotiation Protocol for Internet, IEEE Communication Magazine, May 2002. [4] T.M.T. Nguyen, N. Boukhatem, Y. El Mghazli, N. Charton, L-N. Hamer, G. Pujolle, -PR Usage for SLS negotiation, <draftnguyen-rap-cops-sls-03.txt> Juin 2002. [5] H. Chaouchi, G. Pujolle, H. Afiifi and H. Kim, A Trial towards Unifying Control Protocols: versus RADIUS/DIAMETER, MWCN 2002, Kluwer, Stockholm, September 2002.
132