THÈSE DEVANT L UNIVERSITÉ DE RENNES 1. Olivier Paul. Le contrôle d accès dans les réseaux ATM

Transcription

1 N o Ordre : 2483 THÈSE présentée DEVANT L UNIVERSITÉ DE RENNES 1 pour obtenir le grade de : DOCTEUR DE L UNIVERSITÉ DE RENNES 1 Mention : INFORMATIQUE École Doctorale : Mathématique, Informatique, Signal, Électronique et Télécommunications PAR Olivier Paul Équipe d accueil : Composante Universitaire : Département Réseaux et Services Multimédia, ENST de Bretagne Institut de Formation Supérieure en Informatique et Communication TITRE DE LA THÈSE Le contrôle d accès dans les réseaux ATM SOUTENUE LE 27 Février 2001 devant la Commission d Examen COMPOSITION DU JURY M. Daniel Herman Professeur, Université de Rennes 1 Président M. Gerardo Rubino Directeur de Recherche, INRIA Directeur Scientifique M. Fréderic Cuppens Chargé de Recherche HDR, ONERA Rapporteur M. Refik Molva Professeur, Institut Eurecom Rapporteur M. Sylvain Gombault Enseignant Chercheur, ENSTB Examinateur Mme Maryline Laurent Maître de Conférence, INT Examinateur M. Pierre Rolin Professeur, France Telecom R&D Examinateur

2

3 D'ar re am c'har... A ceux qui m aiment...

4

5 Remerciements Je suis reconnaissant à Pierre Rolin et Gérardo Rubino de m avoir accueilli dans le département RSM. Je les remercie pour les conseils judicieux qu ils m ont donné tout au long de ma thèse ainsi que pour la confiance et la liberté qu ils m ont accordé. Mes remerciements vont également à Maryline Laurent et Sylvain Gombault qui m ont efficacement encadré pendant ces trois années. Je les remercie pour tous les efforts par lesquels ils ont contribué à l avancement de mes travaux. Ma gratitude va également à MM. Frédéric Cuppens et Refik Molva qui m ont fait l honneur d être rapporteurs de cette thèse. Je tiens également à remercier M. Daniel Herman d avoir accepté d être membre de mon jury. Cette thèse a été réalisée grâce au soutien financier de la DRET (Direction des Recherches et Etudes Techniques). Je remercie les membres de cet organisme de m avoir offert la possibilité de réaliser ces travaux. Une grande partie de mes travaux n auraient jamais été possibles sans le soutien matériel et intellectuel des membres de la DRET et de France Telecom-RD. Je tiens de ce fait à remercier MM. Yves Lepape, Anthony Lucas, Jean-Jacques Maret, Benoît Martin du CELAR et MM. Christian Duret, Hervé Guesdon, Valery Laspreses, Joël Lattmann, Jacques Le Moal, Jean-Louis Simon de France Telecom-RD. Mes remerciements vont également aux étudiants de l ENST de bretagne et du DESS ISA ayant collaboré par leurs travaux à la réalisation de cette thèse. Je veux aussi remercier toutes les personnes du campus de Rennes qui par leurs conseils, leur bonne humeur et leur gentillesse ont contribué à la réalisation de cette thèse. Une thèse est souvent l aboutissement de nombreuses années d étude. Je voudrais à ce sujet remercier les professeurs qui m ont montré combien le domaine de l informatique et des télécommunications pouvait être riche et intéressant. Je tiens en particulier à remercier Christian Lagache qui m a fait découvrir ce domaine il y a maintenant 15 ans. Je tiens par ailleurs à exprimer ma reconnaissance envers mes amis, qui par leur amitié ont grandement aidé à faire du marathon qu est la thèse une expérience surmontable. Merci en particulier à Leila et Octavio avec qui j ai partagé beaucoup de bons moments durant ces années à Rennes. Merci enfin à ma famille par son soutien constant et sa confiance durant toutes ces années.

6

7 Le contrôle d accès dans les réseaux ATM Cette thèse se place dans le cadre de réseaux assurant des débits élevés et offrant aux utilisateurs la possibilité de différencier le traitement des flux transportés. Ces propriétés, telles qu elles apparaissent dans les réseaux ATM, peuvent poser des problèmes lorsqu elles sont utilisées en combinaison avec des pare-feux. Ces derniers ne sont pas adaptés à la prise en compte de la qualité de service pouvant être négociée par les utilisateurs. D autre part, ils ne sont pas non plus conçus pour traiter des débits importants. Enfin ils sont généralement incapables de prendre en compte les paramètres de contrôle d accès propres aux réseaux ATM. Dans ce document, nous proposons, après un état de l art détaillé, de résoudre ces trois problèmes. Nous répertorions et classifions tout d abord les paramètres de contrôle d accès propres aux réseaux ATM. Nous montrons ensuite comment ces paramètres peuvent être utilisés dans deux nouvelles architectures de contrôle d accès pour les réseaux de type IP sur ATM. Nous montrons que celles-ci sont à même de résoudre les problèmes de débit et de respect de la qualité de service. Pour cela, notre première architecture se base sur un mécanisme de contrôle d accès distribué et non bloquant alors que notre seconde proposition repose sur un nouvel algorithme de classification rapide de flux. Enfin, notre troisième contribution concerne la mise au point de techniques permettant aux architectures distribuées de contrôle d accès de pouvoir être gérées de manière sûre et efficace. Mots Clés: ATM, TCP/IP, Pare-feu, Contrôle d accès, Architecture de gestion, Sécurité des réseaux. Access Control in ATM Networks This thesis considers the introduction of new techniques insuring high throughput and services differentiation for customers in public and private networks. ATM networks are a good example where these techniques have been successfully deployed. However these techniques cannot be used with firewalls for several reasons. Firewalls are not designed to respect quality of service and usually cannot support high throughputs. Moreover, firewalls do not take ATM access control parameters into account. The goal of this thesis is to deal with these three problems. We first provide and classify ATM access control parameters. We then focus on IP over ATM network architectures and show how these parameters can be used in two new access control architectures. These architectures are designed to provide high throughput while respecting the ATM quality of service. The first architecture reaches this goal by using a distributed and asynchronous access control process while our second proposal defines a new flow classification scheme in order to speed up existing access control architectures. Our third contribution develops new techniques allowing distributed access control architectures to be managed securely and efficiently. Keywords: ATM, TCP/IP, Firewall, Access Control, Management Architectures, Network Security.

8

9 Table des Matières Chapitre 1. Introduction... 7 Chapitre 2. Le contrôle d accès réseau et sa gestion Introduction Un classement des mécanismes de contrôle d accès réseau Synchronisme du contrôle d accès Approche non bloquante Approche bloquante Position topologique du contrôle d accès Approche centralisée Approche distribuée Niveau protocolaire du contrôle d accès Niveau Liaison de donnée/réseau Niveau Transport Niveau Applicatif Quelques exemples d architectures existantes Centralisée et bloquante aux niveaux transport et application: le firewall Centralisée et non bloquante au niveau transport: l analyseur de sécurité Distribuée et bloquante aux niveaux transport et application: le firewall distribué Algorithmes utilisés par les mécanismes de contrôle d accès Le problème du classement des flux Solution traditionnelle: Algorithme linéaire Améliorations récentes Utilisation de mémoires caches Parallélisation du processus de classement Utilisation des informations redondantes des politiques de contrôle d accès

10 Le contrôle d accès dans les réseaux ATM - Table des Matières Améliorations algorithmiques Conclusion La gestion du contrôle d accès Approches traditionnelles Interfaces de configuration des outils de contrôle d accès Plate-formes d administration du contrôle d accès Autres propositions Introduction Expression générique d une politique de contrôle d accès Langage formel Langages de bas niveau à base de règles Langage à base de rôles Langage déclaratif de haut niveau Optimisations utilisées pour la distribution de la politique de contrôle d accès Optimisation basée sur les capacités de contrôle d accès Optimisation basée sur la topologie Implémentation des mécanismes de distribution Méthodes centralisées Méthodes distribuées Conclusion L intégrité du contrôle d accès Introduction Intégrité physique des équipements Intégrité logique des équipements Modèles théoriques Système à contrôle d accès discrétionnaire Utilisation de configurations particulières Système à contrôle d accès obligatoire Systèmes d audit Conclusion Intégrité des communications Conclusion...36 Chapitre 3. Le contrôle d accès dans les réseaux ATM La technologie ATM Introduction Modèle de référence ATM Utilisation des réseaux ATM Le firewall Utilisation dans un environnement LANE Utilisation dans un environnement CLIP Utilisation dans un environnement MPOA

11 Le contrôle d accès dans les réseaux ATM - Table des Matières 3. Etude critique de l utilisation du firewall dans un environnement ATM Contrôle d accès et contrat de trafic Introduction Contrat de trafic Classes de service Limites du firewall Conclusion Limites dues à la faible prise en compte du réseau ATM Conclusion Le contrôle d accès dans les réseaux ATM Le contrôle d accès selon l ATM Forum Solutions industrielles Les commutateurs filtrants Firewall ATM Solutions académiques Solution basée sur un circuit d analyse de cellule ATM Solution basée sur le classement des trafics Conclusion Chapitre 4. Paramètres de contrôle d accès Introduction Recherche des paramètres de contrôle d accès de niveau ATM Au niveau cellule Partie contrôle Partie données Plans utilisateur et contrôle Plan de gestion Au niveau trame Au niveau signalisation Caractérisation des utilisations normalisées des réseaux ATM Utilisations Classical IP over ATM LAN émulé MPOA CES VTOA Applications ANS AMS Analyse Couches non applicatives Connexions permanentes

12 Le contrôle d accès dans les réseaux ATM - Table des Matières Connexions dynamiques Couche applicative Classement des paramètres ATM Conclusion...73 Chapitre 5. Mécanismes de contrôle d accès Introduction Contrôle d accès distribué asynchrone par agent Généralités Paramètres de contrôle d accès Mécanismes de gestion des réseaux Niveau ATM Niveau TCP/IP Niveau Application Conclusion Architecture Conclusion Contrôle d accès synchrone centralisé Cartes IFTs Introduction La mémoire Trie Paramètres de contrôle d accès Niveau ATM Niveau TCP/IP Actions Algorithme de classement Algorithme de base Compression de la structure de classement Complexités de l algorithme de classement Architecture Approche générale Module de gestion Module d analyse et de filtrage de la signalisation Module d analyse de niveau cellule Implémentation Tests de l analyseur de signalisation Tests des IFTs Conclusion Conclusion Conclusion

13 Le contrôle d accès dans les réseaux ATM - Table des Matières Chapitre 6. Gestion du contrôle d accès Introduction Définition d un langage générique de contrôle d accès Langage de bas niveau Langage à base de rôle Définition d une architecture de gestion du contrôle d accès Introduction Architecture centralisée Vue générale Architecture de l agent Modèle du réseau Distribution des règles Conclusion Architecture répartie Introduction Architecture Simulations Conclusion Conclusion Intégrité du contrôle d accès par redondance Introduction Principe Simulations Introduction Résultats théoriques Résultats de simulation Conclusion Conclusion Chapitre 7. Conclusion Analyse Travaux futurs Paramètres de contrôle d accès Mécanismes de contrôle d accès Gestion du contrôle d accès Intégrité du contrôle d accès Chapitre 8. Références bibliographiques Chapitre 9. Annexes Annexes du chapitre Abréviations des messages de signalisation

14 Le contrôle d accès dans les réseaux ATM - Table des Matières 1.2. Abréviations des IEs Relations entre IEs et messages de signalisation Annexes du chapitre Informations relevant du modèle ATM Informations relevant du niveau transport Informations applicatives Annexes du chapitre Grammaire des langages proposés Langage de bas niveau Langage à base de rôles Algorithmes utilisés MIR dans le cas de RIP MIR dans le cas de PNNI Liste des figures Liste des tableaux Liste des acronymes

15 CHAPITRE 1 Introduction Dans ce chapitre nous définissons la problématique abordée dans ce document. L apparition dans les dernières années de nouvelles applications et de nouveaux besoins en terme de communication ont engendré le développement de nouvelles architectures de communication. Parmi ces développements on peut citer deux objectifs essentiels. Le premier a consisté à développer des mécanismes permettant d augmenter les débits pouvant être atteints au travers de recherches concernant les capacités de transfert des supports physiques et les capacités de traitement des équipements d interconnexion. Le second objectif a porté sur le développement de mécanismes permettant de différencier le traitement réalisé sur les flux traversant le réseau afin de fournir aux utilisateurs des qualités de service correspondant à leurs besoins. Parmi ces nouvelles architectures de communication, la technologie ATM a retenu l attention des organismes de normalisation de par sa capacité à supporter des débits élevés tout en permettant au réseau d assurer des garanties de qualité de service aux utilisateurs qui en font la demande. Un autre point ayant suscité originellement l intérêt pour les réseaux ATM est leur capacité à dépasser les barrières traditionnelles entre réseaux locaux, réseaux métropolitains et réseaux longue distance en permettant l utilisation de bout en bout d une même technologie. Dans la pratique les réseaux ATM sont aujourd hui majoritairement utilisés dans le cadre de réseaux d opérateurs de télécommunication, de réseaux d interconnexion d entreprise et plus minoritairement dans le cas de réseaux locaux. Les réseaux et les équipements qu ils interconnectent sont souvent soumis à des attaques. En 1997 le CLUSIF (CLUb de la Sécurité Informatique Francais) rendait publique une évaluation concernant les conséquences économiques des incidents et sinistres relatifs aux systèmes informatiques ([Clu97]). Dans cette évaluation le montant des dommages engendrés par des attaques logiques (fraudes, attaques logiques et divulgation d information) portait sur 4490 millions de francs. L augmentation du montant de ces dommages était de l ordre de 90% sur la période Plus récemment un rapport de la GOA (General Accounting Office) évaluant la sécurité des systèmes d information américains ([Gao00]) montrait que sur 24 agences gouvernementales américaines, toutes connaissaient des problèmes sérieux de contrôle d accès en 1999 et Même s il faut garder à l esprit les possibilités de manipulations de certains de ces chiffres ([War00]), ceux-ci suffisent à montrer toute l importance dans le domaine des réseaux des problèmes de sécurité en général et des problèmes de contrôle d accès en particulier. Cette importance du contrôle d accès a d ailleurs bien été comprise par les entreprises. Selon une étude menée par le cabinet américain IDC, le marché des équipements de sécurité est passé entre 1998 et 1999 de 3 à 4 milliards de dollars et devrait atteindre un montant de 11 milliards de dollars en 2003 ([IDC00]). A l intérieur du marché des équipements de sécurité, le marché européen des pare-feux portait selon un rapport de Frost & Sullivan ([Fro00]) sur un montant de 202 millions de dollars en 1999 et devrait atteindre une montant de 2 milliards de dollars en

16 Le contrôle d accès dans les réseaux ATM - Introduction Le pare-feu ou firewall est l un des éléments clef de la sécurité actuelle des réseaux. Le terme firewall est un terme générique qui englobe généralement un ensemble de mécanismes permettant de rendre plusieurs services de sécurité tels que l authentification de l origine des communications, la confidentialité des informations transmises sur le réseau, ou le contrôle d accès réseau. Ces services peuvent varier d un firewall à l autre, cependant le service de contrôle d accès réseau est généralement considéré comme un service de base et est assuré par tous les types de firewalls. Dans ce document nous nous interessons à l interaction entre ce service de contrôle d accès et les évolutions prévues dans les réseaux telles que celles que nous décrivons au début de ce chapitre. Nous faisons l hypothèse que les réseaux du futur assureront d une part des débits de communication plus importants et d autre part qu au moins une partie des utilisateurs exigera de la part du réseau des garanties de qualité de service. Afin de limiter notre champ d investigation, nous nous intéressons au cas des réseaux ATM qui, comme nous l avons mentionné précédemment, sont à même d assurer ces deux contraintes. Nous montrons dans ce document d une part les problèmes posés par l utilisation de mécanismes de contrôle d accès réseau tels que ceux implémentés dans les firewalls lorsqu ils sont utilisés conjointement avec des réseaux ATM. Nous montrons d autre part de quelles manières ces problèmes peuvent être résolus. Bien que nos solutions ne s appliquent qu aux réseaux ATM, elles pourraient être facilement étendues à n importe quel type de réseau à haut débit et à qualité de service puisque ceux-ci sont à même de rencontrer les mêmes types de problèmes. Ce document est organisé de la manière suivante: Le chapitre 2 présente le service de contrôle d accès réseau. Nous fournissons un classement des différentes architectures de contrôle d accès réseau. Nous détaillons par la suite les mécanismes et algorithmes utilisés dans ces architectures. Pour finir, nous décrivons les techniques permettant d assurer la gestion et l intégrité du service de contrôle d accès réseau. Le chapitre 3 présente l application du service de contrôle d accès réseau au cas des réseaux ATM. Nous montrons en quoi les firewalls classiques ne peuvent répondre à notre problématique de débit et de respect de la qualité de service. Nous présentons par ailleurs les solutions actuelles ayant pour but de résoudre cette problématique en faisant leur analyse critique. Le chapitre 4 décrit la première contribution de cette thèse. Celle-ci porte sur la constitution d un répertoire classé des informations pouvant être utilisées pour fournir un service de contrôle d accès dans le cas des réseaux ATM. Ce classement est réalisée grâce à une analyse détaillée des normes définissant le modèle ATM et les informations produites par ce modèle. Le chapitre 5 présente la deuxième contribution de cette thèse. Celle-ci porte sur la définition de deux architectures de contrôle d accès pour les réseaux ATM. Celles-ci sont d une part à même d utiliser les paramètres de contrôle d accès répertoriés dans le chapitre 4 mais sont également à même de fournir un service de contrôle d accès à des débits élevés tout en garantissant un respect de la qualité de service pouvant être demandée par les utilisateurs. Enfin ces architectures éliminent certains des problèmes existant pour les solutions concurrentes actuellement proposées. Nous décrivons dans le chapitre 6 de ce document la troisième contribution de cette thèse. Celle-ci porte sur la définition de deux architectures de gestion automatique du contrôle d accès. Nous montrons par ailleurs comment ces architectures peuvent être étendues afin de fournir à l officier de sécurité en charge d un réseau une certaine confiance vis à vis du service de contrôle d accès. Pour finir, le chapitre 7 conclut ce document en en résumant les apports et en montrant comment ceux-ci peuvent être améliorés ou étendus à d autre types d applications. Le lecteur pourra par ailleurs trouver en annexe de ce document un ensemble d informations complétant ou détaillant les idées présentées dans les sept premiers chapitres de ce document. 8

17 CHAPITRE 2 Le contrôle d accès réseau et sa gestion Dans ce chapitre nous définissons le service de contrôle d accès réseau. Nous fournissons ensuite des critères de classement des architectures de contrôle d accès réseau puis présentons les algorithmes utilisés pour sa mise en oeuvre. Pour finir nous présentons les techniques permettant d assurer sa gestion et son intégrité. 1. Introduction Le contrôle d'accès est défini par l'iso ([7498-2]) par la phrase suivante: «Le service de contrôle d'accès assure une protection contre une utilisation non autorisée de ressources accessibles par une entité ou un groupe d'entités. Ce type de protection peut être appliqué pour différents types d'accès à une ressource ou pour tous les types d'accès.» Dans la pratique cette définition peut avoir un grand nombre d interprétations. D'une manière générale il s'agit d'empêcher ou d'autoriser certaines personnes à effectuer certaines actions qui peuvent être logiques ou physiques. Dans notre cas nous ne nous intéressons pas à un service de contrôle d'accès assurant une protection physique mais uniquement à un service de contrôle d'accès assurant une protection logique. Historiquement c'est au niveau des systèmes d'exploitation que le service de contrôle d'accès a tout d'abord été développé. En fonction du type de service proposé, les systèmes d'exploitation ont été classés [OBook]: Classe C: Contrôle d'accès discrétionnaire (DAC - Discretionary Access Control). Les utilisateurs définissent des listes de contrôle d'accès sur les objets qui leur appartiennent afin d'en permettre le partage. Ceci suppose bien sûr une identification des utilisateurs. Dans la pratique les systèmes classés C sont de loin les plus utilisés. Classe B: Contrôle d'accès obligatoire (MAC - Mandatory Access Control). En plus du contrôle d'accès discrétionnaire défini pour la classe C, les systèmes classés B doivent assurer une protection des données vis à vis des utilisateurs au moyen d'étiquettes. Dans ce type de système les utilisateurs sont représentés par des entités appelées sujets. Les données sont elles appelées objets. Les étiquettes sont associées aux objets et aux sujets afin de les classer. Le classement des données et des sujets permet de garantir certaines propriétés concernant la manipulation des informations. Le service de contrôle d'accès obligatoire est assuré de manière indépendante de la volonté des utilisateurs (d'où son nom «obligatoire»). Comme on le voit la notion d'identification des utilisateurs est très importante afin d'assurer tout service de contrôle d'accès. 9

18 Le contrôle d accès dans les réseaux ATM - Le contrôle d accès réseau et sa gestion L'introduction des fonctions de communications entre des systèmes d'exploitation situés sur des équipements différents et le développement d'applications basées sur des architectures client-serveur ont entraîné des modifications dans la notion de contrôle d'accès. Les architectures client-serveur se basent sur deux éléments, un processus client et un processus serveur. Le client envoie des requêtes au serveur qui lui répond avec le résultat de sa requête. Le problème de ce type d'architecture est que la plupart des clients et des serveurs ne gèrent pas l'identification des utilisateurs. Cette lacune peut se justifier par trois raisons: La plupart de ces services ont été développés dans le cadre de réseaux où la plupart des services à rendre à tous les utilisateurs sont les mêmes. De ce fait il n'est pas nécessaire de gérer l'identification de ceux-ci. L'interconnexion des réseaux de communication a abouti à l'apparition de communications entre des systèmes qui appartiennent à des entités administratives différentes. Dans ce cadre, il est difficile de s'accorder sur une notation exacte permettant l'identification des utilisateurs. L'identification des utilisateurs n'est utile que si l'on peut s'assurer avec une certaine confiance de leur identité. Or les procédures de sécurité en général et d'identification en particulier entraînent des surcoûts financiers et en terme de performance non négligeables qui ont entraîné les développeurs à construire des versions non sécurisées. Afin d'assurer une interopérabilité maximale ces versions ont été choisies par défaut dans la plupart des systèmes d'exploitation. Afin de palier ces carences plusieurs solutions ont été envisagées. La première est le développement et l'utilisation de clients et de serveurs sécurisés permettant l'identification des utilisateurs ([RFC1510], [Sch96]). Une fois l'identification effectuée le contrôle d'accès peut être effectué par le système d'exploitation ou par le serveur et peut être de type DAC ou MAC. Cette solution a l'inconvénient d'exiger la modification des clients et des serveurs. Cette solution nécessite également d'utiliser une notation commune des identités des utilisateurs ainsi que des clients et des serveurs compatibles ce qui n'est pas évident dans le cas de communications entre entités administratives indépendantes. Afin d'éviter ces problèmes, des travaux ont été réalisés afin de fournir un service de contrôle d'accès qui soit indépendant des équipements et des logiciels clients et serveurs. Les équipements de contrôle d accès réseau dont le firewall ([Ran92]) est un exemple, sont l'aboutissement de ces travaux. Le contrôle d'accès est alors réalisé en analysant le contenu des communications et en bloquant ou interrompant celles qui sont en contradiction avec la politique de contrôle d'accès. Ces équipements fournissent un service qui ne se substituent pas à un contrôle d'accès au niveau du système d'exploitation des équipements extrémité. Dans ce chapitre nous décrivons la mise en oeuvre du contrôle d accès réseau, de sa définition à son implémentation. Ce chapitre est donc divisé en quatre sections principales. La première a pour objectif de fournir un classement des mécanismes de contrôle d accès réseau permettant de décrire de manière claire et concise les architectures existantes. La section 3 porte sur une description des techniques utilisées pour l implémentation de ces mécanismes. Nous décrivons ensuite en section 4 les architectures et techniques utilisées pour définir et administrer le service de contrôle d accès réseau. Pour finir, nous montrons en section 5 que le service de contrôle d accès réseau est inutile s il n est pas possible d en garantir l intégrité. Nous décrivons de ce fait les moyens utilisées pour garantir l intégrité des architectures de contrôle d accès réseau. 2. Un classement des mécanismes de contrôle d accès réseau Afin de faciliter la compréhension des architectures que nous ferons dans les chapitres suivants nous proposons dans cette section certains critères permettant de classer les mécanismes de contrôle d accès. Ces critères sont indépendants des algorithmes qui seront utilisés pour effectuer le contrôle d accès à proprement parler. Ce classement se base sur certaines notions : La politique de contrôle d accès réseau est la définition des communications autorisées et interdites dans un réseau et décrit de ce fait le service de contrôle d accès à implémenter dans le réseau. Ce service de contrôle des communications se fait au moyen d une architecture de contrôle d accès. Cette architecture peut uti- 10

19 Le contrôle d accès dans les réseaux ATM - Le contrôle d accès réseau et sa gestion liser plusieurs types de mécanismes. Par la suite nous résumerons le terme de contrôle d accès réseau par contrôle d accès étant donné que seul ce service nous intéresse dans la suite de ce document Synchronisme du contrôle d accès Notre premier paramètre est lié au synchronisme du contrôle d accès, c est à dire au fait que le contrôle d accès soit fait de manière bloquante ou non Approche non bloquante Dans le cas d'une évaluation non bloquante des flux, l analyse des flux se fait sur une copie des flux ou sur une synthèse des informations contenues dans le flux. La copie du flux peut être réalisée à différents niveaux protocolaires. Au niveau physique la réplication des informations se fait soit par une copie des signaux électrique dans le cas d une utilisation de supports métalliques ou par une duplication des signaux lumineux par coupleur optique dans le cas des supports optiques. Au niveau MAC (Medium Access Control) le mécanisme de copie peut se servir des capacités de diffusion des réseaux locaux en faisant systématiquement une copie des trames fournies par le niveau physique quelle que soit leur adresse de destination. Politique de contrôle d accès réseau Figure 1. Approche non bloquante. I.C.A. Fonction de contrôle d accès D.C.A. Informations Contextuelles Contrôleur Copie du flux O.C.A. Flux La figure 1 utilise le formalisme fournit par [Schu97] pour représenter un mécanisme de contrôle d accès non bloquant. Le contrôleur se base sur une copie du flux pour générer les informations de contrôle d accès (I.C.A.). Celles-ci sont utilisées par la fonction de contrôle d accès qui, en fonction de la politique de contrôle d accès et d informations contextuelles, prend une décision de contrôle d accès (D.C.A.). Cette décision de contrôle d accès est utilisée par le contrôleur pour générer une opération de contrôle d accès (O.C.A.). Cette opération peut soit porter sur le flux si le processus de contrôle d accès est suffisamment rapide, soit porter sur les flux appartenant à la communication ayant généré le flux contrôlé afin d interrompre celle-ci. Les avantages relatifs à une évaluation non bloquante sont doubles. D une part une évaluation non bloquante assure l absence d'altération des flux puisque ceux-ci ne sont pas bloqués. Le deuxième avantage est la possibilité de définir le temps processeur qui sera utilisé pour fournir le service de contrôle d accès. Cependant une analyse à posteriori peut engendrer un délai entre le passage du flux et l opération de contrôle d'accès. De ce fait, l'évaluation non bloquante des flux peut poser un problème de sécurité. Un attaquant peut utiliser ce délai pour réaliser des accès non autorisés. Ce problème est particulièrement sensible dans le cas des protocoles non connectés puisque par définition les flux sont indépendants les uns des autres. 11

20 Le contrôle d accès dans les réseaux ATM - Le contrôle d accès réseau et sa gestion Approche bloquante Dans le cas d'une évaluation bloquante des flux (décrite figure 2), l analyse des flux ne se fait plus sur une copie du flux mais sur le flux lui même. Le contrôleur extrait du flux les informations nécessaires à la fonction de contrôle d accès (I.C.A.) et bloque le flux jusqu à ce qu une décision de contrôle d accès (D.C.A.) lui parvienne. Le flux est alors, soit détruit, soit réémis vers sa destination. Politique de contrôle d accès réseau I.C.A. Figure 2. Approche bloquante. Fonction de contrôle d accès D.C.A. Informations Contextuelles Contrôleur Flux Flux Les avantages et inconvénients de cette approche sont duaux de l approche non bloquante. En effet l approche bloquante garantit la sécurité du contrôle d accès puisque le flux est bloqué jusqu à la décision de contrôle d accès mais ce bloquage peut entraîner des modifications dans les caractéristiques du flux Position topologique du contrôle d accès Notre second critère de classement concerne la position topologique des mécanismes de contrôle d accès, c est à dire son placement dans le réseau. Les notions de centralisation et de distribution n ont de sens que vis à vis de la politique de contrôle d accès Approche centralisée Une architecture de contrôle d accès centralisée se base sur la concentration des mécanismes de contrôle d'accès dans un seul équipement et donc dans un seul point de la topologie du réseau. Le point de concentration est défini de telle sorte à pouvoir rendre le service de contrôle d accès défini par la politique de contrôle d accès qui lui est associée. Cet endroit est généralement placé entre un réseau non contrôlable (réseau public par exemple) et le réseau à protéger (réseau local par exemple). Tous les flux sont alors examinés par l architecture de contrôle d accès. La centralisation des mécanismes de contrôle d'accès apporte certains avantages. Le premier est qu un seul équipement a besoin d'être modifié afin de fournir le service de contrôle d accès. Ceci est important car certains équipements internes au réseau à protèger ne peuvent être modifiés ou sécurisés du fait de leur conception. De plus, seul cet équipement a besoin d'être géré et audité. La détection des attaques concernant plusieurs équipements est plus facile puisque tous les flux devant être contrôlés passent par un seul point. Enfin, le service de contrôle d'accès n'a pas d'impact direct sur les performances des services fournis par les équipements du réseau puisqu il est fourni par des mécanismes placés sur un équipement dédié. Une architecture centralisée possède également certains inconvénients. La résistance aux pannes est faible. En effet, si le contrôleur tombe en panne, soit le service n'est plus assuré (approche non bloquante), soit les communications ne sont plus possibles (approche bloquante). Un autre point est qu une architecture cen- 12

21 Le contrôle d accès dans les réseaux ATM - Le contrôle d accès réseau et sa gestion tralisée ne peut contrôler que les flux qui lui sont accessibles, de ce fait, elle n assure généralement pas de contrôle des communications internes au réseau protégé et est également sensible aux changements de topologie (physiques ou logiques) du réseau puisque ceux-ci peuvent rediriger des flux à contrôler hors de sa portée. Il faut également noter que la compromission de l architecture de contrôle d accès met en jeu la totalité du service de contrôle d accès à fournir. Notons également que le service de contrôle d accès dans ce type d architecture repose sur une vision tronquée des flux. Ainsi, [PN98] montre comment il est possible de tromper les outils d analyse de flux lorsque l'analyse des flux est faite de manière centralisée. Les causes de ce problème sont l'utilisation des différences entre les systèmes d'exploitation, entre les piles de protocoles utilisées, de l'architecture du réseau et de certains paramètres tels que le temps. Ces cause peuvent provoquer la non détection d'attaques ou la détection de fausses attaques. Enfin, les architectures centralisées posent des problèmes lorsqu elles sont utilisées en association avec des mécanismes de chiffrement de bout en bout. En effet ceux-ci peuvent cacher les informations utiles en terme de contrôle d accès. Ce problème est particulièrement sensible dans le cas des spécifications de l IETF pour assurer la confidentialité dans le protocole IP ([RFC2401], [Ciz99]) puisque tout le contenu des paquets IP peut être chiffré (en-tête comprise) Approche distribuée L approche distribuée consiste à utiliser un ensemble de mécanismes placés sur des équipements distincts afin de fournir le service de contrôle d accès. Le degré de distribution de l architecture de contrôle d accès se définit comme le rapport entre le nombre d équipements implémentant un mécanisme de contrôle d accès et le nombre d équipements contrôlés. Une architecture totalement distribuée aura un degré de distribution égal à 1 alors qu une architecture totalement centralisée aura un degré de distribution proche de 0. Il peut donc exister toute une palette d architectures distribuées en fonction d un degré de distribution borné par ces deux extrêmes. La distribution des mécanismes de contrôle d'accès présente un certain nombre d'avantages. Elle offre une meilleure résistance aux pannes. En effet, si un équipement implémentant un mécanisme de contrôle d accès tombe en panne, seuls les équipements protégés par cet équipement sont concernés par le problème. De même, la compromission d'un équipement n'affecte pas la sécurité d autres équipements. D autre part, contrairement à une architecture centralisée, il est possible de réaliser un contrôle des communications internes à un réseau. De plus, comme nous l avons dit dans le paragraphe précédent une architecture centralisée possède une vision limitée des flux qu elle contrôle. Des mécanismes de contrôle d accès distribués se basent sur une vision plus réaliste des flux. En effet, les flux peuvent être analysés en fonction de la configuration locale des équipements. L'action de ces flux correspond donc exactement à ce que leur analyse peut révéler. Il n'y a donc pas dans ce cas de problèmes de cohérence entre les données analysées et les données transmises de bout en bout. Enfin, lorsque les mécanismes de contrôle d accès sont placés sur les équipements extrémité, il est possible de faire en sorte que ceux-ci soient exécutés avant les mécanismes de chiffrement ce qui permet d accéder à toutes les informations produites par une communication. Une architecture distribuée possède également certains inconvénients. Le plus important est lié au nombre d équipements qui doivent fournir le service de contrôle d accès. La difficulté de la gestion et de l audit des mécanismes implémentés par ces équipements est d autant plus grande que ce nombre est important. Un autre problème vient du fait que le service de contrôle d'accès étant un service comme un autre, il est possible que les mécanismes l implémentant aient un impact sur les performances des autres services fournis par les équipements du réseau. Enfin, la corrélation des données provenant de plusieurs équipements afin de repérer des attaques concernant plusieurs équipements est difficile à mettre en oeuvre de manière performante. Cette corrélation n'est pas nécessaire dans le cas d'une architecture centralisée Niveau protocolaire du contrôle d accès Le dernier critère caractérisant les mécanismes de contrôle d accès est le niveau protocolaire des informations utilisées. En effet, les notions d objets et de sujets peuvent prendre des valeurs sémantiques différentes 13

22 Le contrôle d accès dans les réseaux ATM - Le contrôle d accès réseau et sa gestion en fonction du niveau protocolaire auquel on se place. De ce fait les mécanismes de contrôle d accès peuvent être classés en fonction des notions de sujets et d objets qu ils utilisent Niveau Liaison de donnée/réseau Aux niveaux liaison et réseau les notions d objets et de sujets sont remplacées par la notion d équipements. La notion d accès par un sujet à un objet se traduit alors par la possibilité pour deux équipements physiquement interconnectés de communiquer. L identification des équipements se faisant à ce niveau au moyen d adresses (par exemple les adresses MAC au niveau liaison dans le cas des réseaux locaux [Smart99] ou les adresses IP dans le cas du réseau Internet [Cisc99]), les fonctions de contrôle d accès se basent sur les adresses présentes dans les flux afin d établir leur décision de contrôle d accès Niveau Transport Au niveau transport la notion d objet et de sujet est remplacée par la notion de serveurs et de clients logiciels. La notion d accès à un objet par un sujet est dans ce contexte la possibilité pour un client et un serveur de communiquer. L identification du client et du serveur se fait en utilisant pour identité une combinaison de l adresse de l équipement et du SAP (Service Access Point) identifiant le serveur dans le cas de l objet et de l adresse de l équipement et du SAP identifiant le client dans le cas du sujet (par exemple les numéros de ports TCP ou UDP dans le cas du réseau Internet [Eagl97]) Niveau Applicatif Le niveau applicatif est le premier à distinguer la notion d objet de celle de sujet. En effet la notion d objet est remplacée par la notion de procédure ou fonction particulière d un serveur alors que la notion de sujet est remplacée par celle d utilisateur. L identification de l utilisateur peut se faire au moyen d un identifiant unique. Celui-ci peut être un nombre ou une chaîne alphanumérique ([RFC1413]). Comme nous l avons dit en section 1, il est parfois difficile de s assurer de l identité d un utilisateur, c est pour cela que les mécanismes de contrôle d accès de niveau applicatif utilisent parfois une notion affaiblie de l identité qui est celle de l adresse de niveau liaison ou réseau ([Tis93], [Tis96]). Cette adresse est sensée représenter un ensemble d identités d utilisateurs. L identification d une fonction particulière d un serveur est réalisée grâce aux données applicatives générées par la communication Conclusion La décision de réaliser le contrôle d'accès à un niveau ou à un autre se fait en fonction du service demandé. La raison principale pour laquelle le contrôle d'accès est parfois uniquement réalisé au niveau transport est que l'outil de contrôle d'accès au niveau application n'existe pas. Ceci peut s'expliquer par le fait qu il n'est pas possible de construire des outils de contrôle d'accès au niveau application pour certains types de serveur en raison de la complexité des protocoles qu'ils utilisent. D autre part les outils de contrôle d'accès pour certains types de serveurs seraient très onéreux à construire. Leur utilité ne justifie pas leur coût de développement (ce problème est accentué dans le cas de l utilisation de protocoles propriétaires). Enfin, le service de contrôle d'accès au niveau application peut introduire des perturbations dans les communications. Certaines communications ne peuvent pas supporter ces perturbations. Il n'est donc pas possible de construire des outils de contrôle d'accès au niveau application qui leur soient adaptés. Comme on peut le constater les mécanismes de contrôle d accès ne respectent pas toujours le principe de séparation des couches préconisé par l ISO dans le modèle OSI. De ce fait des informations de niveau réseau et transport peuvent être utilisées par des mécanismes positionnés au niveau application et des informations de niveau réseau peuvent être utilisées au niveau transport. Il faut par ailleurs noter que le positionnement des mécanismes dans les piles protocolaires n est pas forcément identique au niveau protocolaire du service de contrôle d accès qu ils fournissent. On peut ainsi trouver des mécanismes de contrôle d accès de niveau trans- 14

23 Le contrôle d accès dans les réseaux ATM - Le contrôle d accès réseau et sa gestion port implémentés au niveau liaison de donnée ou des mécanismes de contrôle d accès de niveau transport implémentés au niveau application Quelques exemples d architectures existantes Centralisée et bloquante aux niveaux transport et application: le firewall Le firewall ([Ran92], [Ches94], [Cha95]) englobe sous un nom générique un ensemble de mécanismes. Comme indiqué figure 3, ceux-ci peuvent être implémentés à deux endroits au niveau d un firewall. On peut classer ces mécanismes en deux catégories en fonction du classement donné au paragraphe précédent: Mécanismes de niveau transport Les mécanismes de niveau transport utilisent le contenu des paquets IP. Le firewall est considéré comme le routeur de sortie vers le réseau externe par les équipements du réseau interne. De plus, afin qu aucune communication directe entre les deux réseaux ne soit possible, l équipement est généralement placé en coupure des deux réseaux. Ceci se traduit en pratique par le fait que le firewall soit connecté par une interface physique au réseau interne et par une autre interface physique au réseau externe. De ce fait les paquets IP correspondant à des communications entre les deux réseaux doivent obligatoirement être routés par le firewall. Cette opération de routage se fait à l intérieur du firewall au niveau de la couche IP. D autres techniques peuvent également être utilisées afin de forcer le passage des paquets IP par le firewall comme l utilisation de routeurs configurés au moyen de tables de routage statiques de part et d autre du firewall. Afin de mettre en oeuvre les opérations de contrôle d accès, la couche IP assurant le routage est modifiée. Ces opérations de contrôle d accès consistent à classer les paquets en fonction de leur interface de provenance, de leurs adresses IP source et destination, du type de protocole utilisé, de leurs ports source et destination et des drapeaux TCP [Hes93]. Ce classement est réalisée en fonction de la politique de contrôle d accès. Le résultat du classement peut être de jeter le paquet, de le router normalement ou de le passer à un mécanisme implémenté au niveau application. L implémentation de ces mécanismes peut être réalisée de façon logicielle ou de manière matérielle. Les mécanismes de niveau transport peuvent également être implémentés au niveau application. Ils sont dans ce cas généralement appelés mécanismes de niveau circuit [Kob92]. Cette appellation traduit le fait qu au lieu de traiter des paquets indépendemment les uns des autres, ils conservent un contexte leur permettant de faire le lien entre plusieurs paquets appartenant à une même communication. Ceci leur permet de repérer les paquets n appartenant pas à une communication en cours et de les détruire. Ce mécanisme fonctionne dans le cas des connexions TCP en mémorisant l état de chaque connexion. En ce qui concerne UDP, le filtre contrôle l utilisation de chaque service par la mise en place de timers permettant de décider de manière arbitraire de la fin des communications. Un mécanisme ayant une finalité similaire existe également au niveau transport [Pix99]. Celui-ci appelé filtre à état ou filtre dynamique (Stateful filter ou Dynamic Filter) garde un contexte dans le cas des connexions TCP en conservant l état de chacune d entre elles. Ce mécanisme offre généralement des performances plus importantes que celles d un filtre implémenté au niveau application par le fait qu il est implémenté de manière matérielle ou logicielle en mode noyau. Mécanismes de niveau applicatif Les mécanismes de niveau applicatif sont généralement appelés passerelle ou proxy. On distingue deux types de proxy. Le premier est utilisé dans le cas d applications relativement complexes dont on veut limiter les possibilités d utilisation. En effet, ces applications, de par leur complexité ont un comportement qui est difficile à déterminer. Le démon utilisé pour le transport de la messagerie est un exemple connu de ce type d application. Il a été montré à plusieurs reprises qu il pouvait être utilisé pour prendre le contrôle d un équi- 15

24 Le contrôle d accès dans les réseaux ATM - Le contrôle d accès réseau et sa gestion pement. De ce fait, des versions simplifiées de ces logiciels ([Tis96]) ont été développées. Celles-ci du fait de leur simplicité ont un comportement plus prévisible et sont donc plus sûres. La politique de contrôle d accès n est pas dans ce cas spécifiée par l officier de sécurité mais codée directement dans le logiciel en décrivant les opérations acceptables. Figure 3. Fonctionnement d un firewall. Réseau interne Politiq ue Mécanismes A pplicatifs Niveau Applicatif Politiq ue Mécanismes Transport TCP/IP Driver de carte Réseau externe Couche Phy siq ue Le deuxième type se base sur une politique de contrôle d accès spécifiée soit par l officier de sécurité ([Tis94]) soit par l utilisateur ([Wol93]). Ainsi [Tis94] décrit comment un officier de sécurité peut spécifier le type de service FTP utilisable en fonction de l adresse correspondant à l utilisateur. La palette des comportements spécifiables peut aller du rejet de la connexion à l autorisation totale de celle-ci en passant par la restriction à certaines commandes FTP. [Wol93] décrit un système permettant à un utilisateur de contrôler les actions distantes sur son terminal X au travers de boites de dialogue. Une définition interactive de la politique de contrôle d accès étant plus adaptée dans ce cas. Ces mécanismes comme indiqué figure 3 se placent généralement sur un seul équipement. Celui-ci est placé en entrée du réseau et contrôle les communications entre le réseau interne et le réseau externe. Cependant des configurations plus complexes, combinant plusieurs des mécanismes décrits précédemment et placés dans plusieurs équipements ont également été proposées afin de renforcer la sûreté du service de contrôle d accès. L un des aspects constants du firewall est cependant que ces équipements restent placés à un seul endroit du réseau, entre le réseau interne et le réseau externe (même si l on peut distinguer plusieurs réseaux internes et externes au sein d une seule entreprise, voire d un même site) Centralisée et non bloquante au niveau transport: l analyseur de sécurité L analyseur de sécurité ([Gom94]) a pour objectif la protection du réseau Internet interne au site d une entreprise. Son architecture se base sur un équipement se plaçant entre le réseau à protéger et un réseau externe non sûr. L'approche présentée dans la section précédente considérait que toutes les communications entre un site et l'extérieur étaient dangereuses. Le résultat de cette approche est que les communications sont bloquées à chaque contrôle d'accès. L'approche de type analyseur de sécurité est plus optimiste, elle considère que la majorité des communications sont honnêtes. Ceci permet de ne pas interférer avec les communications, les communications illégales étant arrêtées par la suite. 16

25 Le contrôle d accès dans les réseaux ATM - Le contrôle d accès réseau et sa gestion Figure 4. Fonctionnement de l analyseur de sécurité. Réseau interne Politique Fonction de C.A. Niveau Applicatif Contrôleur Réseau externe 2 TCP/IP 3 Driver de carte Couche Phy siq ue 1 La figure 4 montre comment ce contrôle est réalisé de manière protocolaire. Le flux contrôlé est simplement recopié au niveau MAC afin d'être examiné en utilisant la capacité de la carte réseau à se mettre en mode promiscuous (flux entrant dans l'analyseur - 2). Le flux vers la destination n est lui pas affecté (flux du réseau interne vers le réseau externe - 1). Des échanges ont ensuite lieu entre le module de filtrage au niveau transport et celui au niveau application afin de déterminer si le flux doit être interdit ou pas. En fonction du résultat de ce calcul un flux peut être émis (flux sortant du contrôleur - 3) vers les deux parties par le module de contrôle d'accès au niveau transport afin de couper la connexion si celle-ci n'est pas autorisée. Dans le cas d'une connexion TCP ce flux correspond à un datagramme portant pour chaque partie l adresse de l entité homologue et contenant le bit RST dans l en-tête TCP de telle sorte que chaque partie croit que son entité homologue désire couper la connexion. Ce mécanisme permet à l analyseur de sécurité d être totalement transparent vis à vis des équipements désirant communiquer. L'inconvénient de cette technique est de ne pas pouvoir traiter les flux sans connexion puisque son mode d'action se base justement sur le fait qu'une connexion est préalablement établie Distribuée et bloquante aux niveaux transport et application: le firewall distribué Plusieurs propositions ont été faites afin d implémenter les fonctions de contrôle d accès réalisées par un firewall de manière distribuée ([Xu96], [Nes98], [Bel99]). La proposition la plus complète dans ce domaine est présentée dans [Bel99] par le fait qu elle traite les niveaux application, transport et réseau. [Nes98] traite les niveaux réseau et transport. Enfin [Xu96] traite uniquement du niveau transport. Le firewall distribué a pour objectif de rendre un service de contrôle d accès comparable à celui pouvant être réalisé par un firewall traditionnel mais en plaçant les mécanismes de contrôle d accès sur des équipements extrémité tels que des stations de travail ou des PCs ([Xu96], [Bel99]) ou sur des systèmes intermédiaires comme des routeurs ou des ponts ([Nes98]). Dans chaque cas il s agit de profiter des mécanismes de contrôle d accès implémentés dans les équipements existants et de configurer ceux-ci afin qu ils fournissent un service de contrôle d accès cohérent. Cette possibilité vient de l intégration progressivement réalisée ces dernières années de fonctions de sécurité dans des éléments du réseau. Ces éléments peuvent être des éléments matériels (routeurs, stations de travail) mais également logiciels (navigateurs web, logiciels bureautiques, systèmes d exploitation...). Cependant ces mécanismes de sécurité possèdent généralement des interfaces propres de configuration. Leur gestion peut donc se révéler délicate. Ceci explique pourquoi les propositions de firewalls distribués se basent généralement sur une architecture de gestion automatique du contrôle d accès afin d assurer une configuration cohérente et efficace des mécanismes de contrôle d accès. Nous reviendrons en détail sur ces architectures de gestion en section 4 de ce chapitre. 17

26 Le contrôle d accès dans les réseaux ATM - Le contrôle d accès réseau et sa gestion 3. Algorithmes utilisés par les mécanismes de contrôle d accès Comme on a pu le voir dans la section 2, les fonctions d un contrôleur d accès peuvent généralement se résumer en trois phases. La première est de réassembler les unités de donnée circulant sur le réseau jusqu au niveau où va être réalisé le contrôle d accès. La seconde, réalisée par la fonction de contrôle d accès est de classer l information contenue dans l unité de donnée produite en fonction de règles de classement. Ce classement permet de déterminer une action de contrôle d accès. Pour finir une phase optionelle de fragmentation de l unité de donnée examinée est réalisée afin pouvoir réémmettre l unité de donnée vers sa destination. Des trois phases, l opération de classement est celle qui est généralement considérée comme la plus complexe et constituant le goulet d étranglement dans un mécanisme de contrôle d accès ([Par98]). De ce fait de nombreux travaux ont été entrepris afin d en améliorer les performances Le problème du classement des flux On définit un flux F comme un ensemble de k champs de tailles variables. Le champ i du flux F est noté C(i). Une règle R se définit comme un ensemble d expressions régulières portant sur un ou plusieurs des k champs définissant F. L expression régulière de la règle R portant sur le champ i est appelée R(i). On dit que F correspond à R si quelque soit le champ C(i) de F, C(i) satisfait R(i). Comme plusieurs règles peuvent correspondre à un flux F, on utilise l ordre d expression des règles afin de résoudre les conflits potentiels. Le problème du classement des flux peut être considéré ([Sri98], [Gup99], [Xu00]) comme un problème équivalent au problème classique de calcul géométrique appelé problème de localisation d un point (point location problem). Celui-ci consiste dans un espace à k dimensions à trouver parmi un ensemble de n objets, l objet auquel appartient un point donné. [Ove96] précise les deux bornes en terme de complexités spatiale et temporelle s appliquant à la résolution de ce problème dans le cas général et propose deux solutions permettant de les atteindre. La première offre une complexité temporelle en O(log n) mais possède une complexité spatiale de O(n k ). La seconde possède une complexité spatiale en O(n) mais possède une complexité temporelle en O(log k-1 n). Ces complexités qui peuvent sembler faibles sont à mettre en parallèle du nombre de flux à classer par seconde qui peut aller jusqu à plusieurs millions. De plus la complexité des algorithmes proposés empêche toute implémentation matérielle. On peut donc considérer qu il n y a pas de solution générale satisfaisante au problème du classement de flux. De ce fait les propositions visant à repousser ces limites théoriques se basent sur des hypothèses complémentaires afin d obtenir des performances plus intéressantes dans la pratique. En dehors des problèmes de complexités spatiale et temporelle, d autres paramètres peuvent justifier la recherche de nouvelles solutions. La première est la rapidité avec laquelle il est possible d insérer de nouvelles règles dans la liste des règles décrivant la politique de classement. Cette propriété est importante dans le cas des filtres à état (Stateful Filter) dans lesquels la conservation d un état sur les connexions est généralement implémentée en modifiant dynamiquement la politique de contrôle d accès en fonction des connexions établies. Un second point important est la capacité des algorithmes proposés à être implémentés de manière matérielle pour en accélérer les performances Solution traditionnelle: Algorithme linéaire La solution la plus simple et la plus courante en matière de classement de flux est l algorithme linéaire. Celui-ci consiste à parcourir la liste des règles en cherchant pour chaque règle si celle-ci est satisfaite par le flux analysé. Le parcours s arrête dès qu une règle satisfaisante est trouvée. L action associée à cette règle est ensuite appliquée. La complexité temporelle et spatiale de cette solution est en O(n. d) ce qui est intéressant en ce qui concerne la complexité spatiale mais mauvais en ce qui concerne la complexité temporelle. Elle a cependant pour avantage de permettre une modification facile de la liste des règles. 18

27 Le contrôle d accès dans les réseaux ATM - Le contrôle d accès réseau et sa gestion 3.3. Améliorations récentes Les améliorations en terme de bande passante ayant réalisées ces dernières années ont poussé les constructeurs de matériels réseau et en particulier les constructeurs de routeurs à faire des recherches dans le domaine du classement de paquets. Ces recherches se sont orientées dans trois directions principales. Vis à vis du problème général présenté dans la section 3.1, la première direction consiste à utiliser une connaissance préalable des flux pouvant être classés afin d améliorer les performances des mécanismes de classement. La seconde direction consiste, elle, à utiliser la structure des règles de classement afin de sortir des limites du cas général. Enfin la troisième direction a portée sur la définition d un cas particulier du problème général de classement des paquets afin d obtenir des algorithmes de classement plus performants Utilisation de mémoires caches Le principe de l utilisation de mémoires caches est relativement simple. Il s agit de conserver dans une mémoire extrêmement rapide les règles devant être utilisées afin de classer les flux. La rapidité d accès à la mémoire est généralement due à l utilisation de techniques d adressage particulières. Deux d entre elles sont particulièrement utilisées. La première appelée CAM (Content Adressable Memory) permet un adressage par contenu. De ce fait, elle permet des temps de recherche en O(1) mais leur taille est pour le moment limitée à 1 Moctets ([Mot100]). L inconvénient de cette approche est qu elle ne permet pas une représentation facile et efficace des expressions régulières portant sur les champs. De plus, le prix de ces mémoires est généralement prohibitif. Enfin elles ne permettent pas l analyse simultanée d un grand nombre de champs puisque les largeurs maximale d analyse actuelles sont de l ordre de 255 bits [Sib00]. La seconde utilise des mécanismes de hachage sur le contenu des champs à analyser afin de limiter la taille prise par la liste des règles et à utiliser une mémoire rapide de type SRAM (Static RAM). La complexité temporelle de la recherche est dans le meilleur cas en O(1). Cependant dans les cas les plus mauvais celle-ci peut être en O(n) en fonction de la nature de la fonction de hachage. La taille de ce type de mémoire est limitée actuellement à 4 Moctets ([Mot200]). De ce fait les possibilités d adressage (24 bits) rendent difficile la mise au point de fonctions de hachage dans le cas où un grand nombre de champs doivent être traités. La taille de ces mémoires étant limitée, il n est pas actuellement possible de stocker toutes les règles relatives à une politique de contrôle d accès dans ce type de mémoire. De ce fait, il convient de déterminer une stratégie de choix des règles devant se trouver en mémoire cache. La stratégie la plus couramment utilisée est la suivante. A la réception d un flux F, on utilise la mémoire cache afin de savoir quelle règle appliquer. Si aucune règle n est trouvée, on classe le flux au moyen d un processus logiciel beaucoup plus lent et on insère le résultat de la règle correspondante de manière adéquate dans la mémoire. La technique de remplacement en mémoire est généralement la technique LRU (Last Recently Used). Celle-ci se base sur le niveau de localité temporelle (temporal locality) existant entre plusieurs flux. En effet il a été montré ([Cla94]) qu il existe une forte probabilité que l arrivée d un flux soit suivie de l arrivée d un flux pouvant être classé de la même manière. [New97] indique que les taux de succès des mémoire caches utilisées dans les routeurs et utilisant un mécanisme de remplacement LRU se situent entre 60% et 80%. Ce principe est couramment utilisé dans les routeurs gigabits (Gigabits Routers) pour la construction de Forwarding Engines associé à des architectures à base de commutateurs ([Par98]). [Xu100] utilise une analyse des paquets échangés sur un backbone Internet afin de proposer une technique d amélioration des performances de l algorithme LRU (appelé near LRU) en utilisant la composition des flux pouvant être trouvés sur un lien backbone. Cette technique permet d assurer un taux de succès quasi optimal dans ce cas. Le taux de succès obtenu est alors de 90%. Il suggère également l utilisation de mémoire SLDRAM (Synchronous Link Dynamic RAM) permettant la construction de caches plus grands et à moindre coût. Cependant les estimations pour la construction d un cache pour un routeur fonctionnant à 50 Gbps montrent la nécessité d utiliser un cache de 256Mo pour obtenir ces taux de succès (dans le cas d une analyse por- 19

28 Le contrôle d accès dans les réseaux ATM - Le contrôle d accès réseau et sa gestion tant sur 5 champs des paquets TCP/IP et cela quel que soit le nombre de règles). Cette taille peut être rédhibitoire. D une manière générale l utilisation de mémoires cache présente un certain nombre d inconvénients inhérents. D une part il est facile de constater que par le fait qu il existe deux voies de classement des flux, des circonstances peuvent amener une saturation de la voie lente d analyse par un afflux de flux nécessitant une mise à jour de la mémoire cache. Comme les flux sont traités en séquence, le débit maximal pouvant être atteint par des équipements utilisant ce type de mécanisme peut être limité à celui de la voie lente de classement. Cette limitation peut être facilement être mise à profit par des individus mals intentionnés en produisant des séquences de flux provoquant des mises à jour continues de la mémoire cache ([Lak98]) afin de réaliser des dénis de service Parallélisation du processus de classement La première approche non basée sur l utilisation de cache et visant à améliorer les performances des algorithmes de classement consiste à définir un algorithme de classement dont une partie des opérations soient parallélisables, c est à dire executables de manière simultanées sans interactions. Cette capacité à la parallélisation n a d intérêt que dans la mesure ou l algorithme est executé sur une architecture matérielle spécialisée et non sur un processeur unique de calcul. Dans [Lak98], le principe général consiste à décomposer chaque règle suivant chaque champ en un intervalle. On construit ensuite un tableau de même taille que le nombre de champs et on découpe l'espace en fonction des bornes de chaque intervalle sur chaque dimension. On remplit le tableau en indiquant si la projection de chaque règle vis à vis du champ considéré se trouve dans l'intervalle comme indiqué en figure 5. Figure 5. Projection et construction des tableaux dans le cas de règles à deux dimensions. [00] [10] R0 [11] R1 [10] [00] [00] [01] [11] [01] [00] Le tableau a de ce fait une composition binaire. Afin de classer un paquet on cherche dans chaque dimension l intervalle correspondant à la valeur du paquet. On réalise ensuite un ET logique entre les tableaux provenant de chaque dimension. On détermine enfin la règle concernée en prenant la première règle marquée à 1 dans le tableau (on suppose pour cela que les règles sont classées par ordre de priorité). L intérêt de cette technique est de permettre une évaluation en parallèle de chaque dimension. On a au total un maximum de 2n+1 intervalles par dimensions et la complexité temporelle est de ce fait O(log (2n+1)+1) si l on suppose que l on effectue une recherche par arbre binaire dans chaque dimension. Afin de réduire la taille des tableaux utilisés par la méthode précédente, les auteurs proposent d'utiliser la proximité existant entre deux tableaux représentant deux intervalles pour ne stocker que un tableau initial et les différences entre deux tableaux adjacents. Cette technique permet de passer d'une complexité spatiale en O(n 2 ) à O(n. log n). 20

29 Le contrôle d accès dans les réseaux ATM - Le contrôle d accès réseau et sa gestion Utilisation des informations redondantes des politiques de contrôle d accès De nombreuses solutions ont été proposées pour utiliser la structure des règles de classement pouvant être trouvée dans les politiques de contrôle d accès utilisées dans la pratique afin d accélérer les mécanismes de classement. Bien que ces travaux aient été réalisés dans le cadre des réseaux TCP/IP (car ils utilisent des règles de classement provenant d outils de contrôle d accès pour ce type de réseau), on peut supposer que les résultats obtenus peuvent s appliquer à la n importe quel type de réseau. Figure 6. Exemples de tuples dans le cas de règles dans deux dimensions. Règles R0 = (01*, 111*) R1 = (11*, 101*) R2 = (0*, 1111) R3 = (1*, 111*) R4 = (1*, 0001) R5 = (111*, 0*) Tuples T0[1,3] = {R3} T1[1,4] = {R2, R4} T2[2,3] = {R0, R1} T3[3,1] = {R5} [Sri99] propose d'utiliser la redondance pouvant être trouvée dans les règles de contrôle d accès afin d accélérer la recherche d'une règle correspondant à un paquet. La redondance étudiée est celle de la longueur des préfixes. On appelle préfixe le motif initial d'un champ permettant de le classer de manière unique. On définit un tuple comme un tableau composé des longueurs des préfixes de chaque champ d une règle. Deux règles appartiennent au même tuple si chaque champ a la même longueur de préfixe. La figure 6 montre comment des tuples peuvent être construits à partir de règles dans un espace à deux dimensions. Une étude statistique montre qu'il est possible au moyen de quelques transformations sur les champs ports et protocoles, de définir un nombre restreint de tuples pour une politique. En concaténant les bits significatifs de chaque règle présente dans un tuple on peut construire pour chaque tuple une table de hachage qui donne une règle en fonction du contenu d'un paquet. Une recherche linéaire permet ensuite de trouver le tuple adéquat parmis les règles pouvant être associées à la même clef de hachage. Les auteurs proposent également une méthode d amélioration de la recherche parmi les tuples. A partir d'un tuple T donne on peut définir trois sous ensembles de T. Le premier est l'ensemble des tuples qui sont composés de longueurs de préfixes plus faibles que celles contenues dans T, le second, l'ensemble des tuples qui sont composés de longueurs de préfixes plus fortes que celles contenues dans T et pour finir l'ensemble des tuples ne pouvant être comparés à T. On appelle ces ensembles S,L et N. Un succès de la recherche sur T implique qu il est inutile de chercher si S contient une meilleure solution puisque celui-ci contient des tuples composés de longueurs de préfixe plus faibles. De même si une recherche dans T est un échec il est inutile de chercher une solution dans L puisque celui-ci contient des tuples composés de longueurs de préfixe plus fortes. Ces ensembles peuvent être calculés à l'avance pour chaque tuple T et servir à guider le processus de classement d un flux. La complexité temporelle de la recherche parmi w tuples est de O(w k-1 ), le nombre de tuples étant variable en fonction de la politique de classement. [Gup99] propose également d'utiliser une connaissance du contenu des règles de contrôle d accès afin d améliorer les performances de la recherche d'une règle. L idée de base est d utiliser la redondance pouvant être trouvée au niveau des règles pour construire un codage permettant de représenter les différentes possibilité de chaque champs par un motif de taille minimale. 21

30 Le contrôle d accès dans les réseaux ATM - Le contrôle d accès réseau et sa gestion Figure 7. Méthode de construction des codages minimaux dans le cas de règles à deux dimensions. If A and D then deny 0 00 If B and C then deny 1 01 If A and C then permit 0 01 If B and B then permit Etape 1 Etape 2 Ce processus, décrit en figure 7 est répété pour les combinaisons de code de champs en cherchant les combinaisons permettant la réduction finale la plus importante. L étape finale de ce calcul de codes est atteinte lorsque le code obtenu représente les combinaisons de tous les champs relatives à une règle et permet de désigner celle-ci de manière unique. On peut de cette manière associer à chaque champ, combinaison de champs et finalement règle de classement un code minimal. Ces codes sont utilisés pour construire une structure de classement indexée par les valeurs pouvant être prise par les champs. Le classement d un flux est alors réalisée en calculant de manière séquencielle : le code associé à la valeur de chaque champ du flux, les codes associé à la combinaison des codes ainsi générée à partir du flux et finalement le code associé à la règle devant s appliquer. Les auteurs présentent une méthode de permettant de diminuer la taille de la politique de classement par agrégation de règles. Ils font également apparaître que la méthode de construction des tableaux permet de trouver de nouvelles sources d agrégation. Figure 8. Découpage de l espace de recherche et construction de l arbre de classement associé. 255 R3 R7 (256 * 256, X, 4) Y 128 R1 R4 R2 R6 R1 R2 (64*256, Y, 2) R2 R6 R2 R7 0 R X 255 R4 R5 R2 R3 [Gup00a] propose une méthode appelée HiCuts se basant sur une représentation arborescente des règles construite en découpant chaque dimension de recherche en fonction d heuristiques. La figure 8 donne un exemple de découpage des deux dimensions d un espace de recherche dans le cas de sept règles et décrit la construction de l arbre de classement associé. Chaque niveau de l arbre correspond à une dimension et chaque rectangle à une portion de l espace d analyse dans celle-ci. Plus précisemment, les rectangles arrondis indiquent par un triplet la dimension considérée (X ou Y dans notre cas), la partie de la dimension attribuée aux noeuds fils (64*256 indique l intervalle [64;128] dans la dimension X et [0;256] dans la dimension Y) et le nombre de fils. Les rectangles normaux indiquent les règles restant en conflit en fin d analyse. Les heuristiques choisies permettent de faire un compromis entre la taille de la structure de classement (complexité spatiale de l algorithme de classement) et sa profondeur (complexité temporelle de l algorithme de classement). Le classement d un flux se traduit alors par une traversée de l arbre de sa racine jusqu à une feuille. Cette feuille indique l ensemble des règles de classement devant s appliquer. Une recherche linéaire parmi celles-ci permet par la suite de trouver la règle adéquate. 22

31 Le contrôle d accès dans les réseaux ATM - Le contrôle d accès réseau et sa gestion Améliorations algorithmiques Plus récemment certaines propositions ont été faites afin d améliorer les complexités temporelles et spatiales qui servaient de bornes pour le problème de la localisation d un point dans un ensemble d objets en se servant du fait que les objets utilisés dans le cas d un classement de paquets sont d une taille généralement faible alors que ceux utilisés dans le cas général peuvent être d une dimension grande voire infinie ([Ove96]). De ce fait il devient intéressant d exprimer des complexités non plus en fonction du nombre de règles mais en fonction de la taille maximale de la projection dans une dimension des objets représentant les règles de classement (c est à dire de la taille maximale de l intervalle pouvant être représenté par le champ de la règles correspondant à la dimension considérée). Dans [Fel00], les auteurs proposent une amélioration se basant sur une technique algorithmique permettant de calculer des complexités temporelles, spatiales et de temps d'insertion. L'amélioration proposée par les auteurs utilise une décomposition du problème de classement des paquets en plusieurs problèmes de localisation par intervalle (RL - Range Location). Ils montrent par ailleurs que le problème de RL est équivalent à celui de recherche d'adresse IP (IPL - IP Lookup Problem). Ils se servent à partir de ce moment des meilleurs algorithmes ayant été proposés pour résoudre le problème IPL. La transformation du problème de classement de paquets en plusieurs RL/IPL se fait au moyen d'une structure arborescente appelee FIS Tree (Fat Inverted Segment Tree) qui consiste en une représentation sous forme d arbre d ordre x (avec x égal à 2 ou 3) des intervalles élémentaires formés par les intersections des intervalles représentant la projection des règles dans une dimension. Cette projection est réalisée d une manière analogue à celle utilisée dans [Lak98] et présentée en figure 5. A chaque noeud de l'arbre on associe l'ensemble des règles contenues dans l'intervalle recouvert par un noeud mais non contenus dans le noeud parent. L'arbre est ainsi construit des feuilles vers la racine comme indiqué en figure 9. Figure 9. Construction d un FIS d ordre 2 dans une dimension. R1 R2 R0 {2} {2} {0} {1} On associe également à chaque noeud un pointeur vers un arbre du même type représentant une décomposition similaire des règles associées au noeud, dans la dimension suivante. La recherche se fait en partant des feuilles, en exécutant une RL pour trouver la feuille de départ. On progresse ensuite vers la racine en stockant le pointeur associé à chaque noeud traversé. On refait la même opération au niveau supérieur en utilisant les arbres correspondant aux pointeurs obtenus. La dernière dimension consiste en une seule RL. La complexité spatiale est de O(n. (l. log n. n 1/l ) d-1 ) alors que la complexité temporelle est en O(l d-1. log log w) où w est la valeur maximale des tailles de chaque champ, l la hauteur d'un arbre FIS d'ordre x, n le nombre de règles et d le nombre de champs. Dans [Gup00b], les auteurs proposent deux solutions algorithmiques de classement des paquets. Ces deux solutions ont des coûts intéressants en terme de complexité spatiale, temporelle et de temps de mise à jour. La première appelée Heap on Trie se base sur la décomposition des intervalles formés par les valeurs des champs des règles sous la forme de séries de préfixes maximaux. Par exemple, l intervalle I = [0;10] peut être décom- 23

32 Le contrôle d accès dans les réseaux ATM - Le contrôle d accès réseau et sa gestion posé en trois sous intervalles [0;7], [8;9] et [10;10] correspondant respectivement aux préfixes binaires maximaux 0***, 100* et A chaqu une des d dimensions correspondant à un champ on associe un segment de mémoire Trie. Les noeuds de cette mémoire sont associés à la reconnaissance d un préfixe maximal. On associe à chaque noeud la liste des règles associées au préfixe considéré. On associe également à ces noeuds un pointeur sur un autre segment de mémoire Trie correspondant à la dimension suivante et décomposant les règles de classement associées au noeud dans celle-ci d une manière analogue. Dans la dernière dimension, on associe un pointeur vers un tas stockant les règles par valeur décroissante de priorité. Figure 10. Remplissage d un segment de mémoire trie dans une dimension avec deux intervalles. = I = J = J = I = I I = [0;10] = 0***, 100*, 1010 J = [2,7] = 001*, 01** La figure 10 présente un exemple du contenu d un segment de mémoire trie dans le cas de deux intervalles. La recherche d une règle se fait en parcourant la structure de classement et en stockant l ensemble des pointeurs présents sur le parcours puis en répétant l opération dans chaqu un des segment de mémoire trie pointé et cela jusqu à l avant dernière dimension. La recherche dans la dernière dimension consiste à chercher l élément en haut du tas. La complexité temporelle est en O(w d ), la complexité spatiale en O(n. w d ) et la complexité de mise à jour de O(w d. log n), où w est la taille maximale des champs, d le nombre de dimensions et n le nombre de règles. La seconde proposition, appelée BinarySearchTree on Trie se base sur le remplacement des tas utilisés dans la première proposition par des arbres binaires associés aux noeuds de la mémoire Trie. Cette technique permet de diminuer le coût de mise à jour tout en augmentant la complexité temporelle. Celle-ci est de O(w d. log n), la complexité spatiale de O(n. w d ) et la complexité de mise à jour de O(w d-1. log n ). Pour conclure cette section, il faut noter que les complexités spatiales et temporelles de ces algorithmes peuvent être comparées aux solution précédentes en substituant la taille des champs (w) par une fonction du nombre de règles étant donné que le nombre de règles maximales (n) pouvant être exprimées par d champs de taille w est 2 w.d. De ce fait, on a au pire, w = (log n) / d Conclusion Le tableau 1 propose une comparaison des différentes propositions en matière de classement de flux. Certaines solutions sont difficilement comparables aux autres par le fait qu elles n ont pas été implémentées. Nous limiterons donc notre comparaison aux solutions ayant été implémentées. Tableau 1. Comparaison des techniques de classement. Propriété/Solution Algo. Linéaire CAM SRAM Lakshman & al. Srinivas. & al. Gupta & al. (1) Gupta & al. (2) Complexité recherche O(n.d) O(1) O(1) O(log(2n+1)) / / / moy. Complexité recherche O(n.d) O(1) O(n) O(log(2n+1)) / / / max. Complexité spatiale O(n.d) O(2 n.d ) O(n.d) O(n. log n) / / / 24

33 Le contrôle d accès dans les réseaux ATM - Le contrôle d accès réseau et sa gestion Propriété/Solution Performance crète imp. matérielle Performance crète imp. logicielle Malgré tous les travaux entrepris ces dernières années dans le domaine du classement des flux, peu de solutions ont été réellement implémentées dans des produits commerciaux. D autre part il faut également préciser que la plupart des travaux portant sur le classement de flux ont pour le moment porté sur le classement de paquets IP en fonction des couples adresses et ports source et destination en particulier pour assurer des fonctions comme la différenciation de service dans les routeurs et ont été moins appliquées aux architectures de contrôle d accès. A notre connaissance, seule la solution proposée par [Lak98] a été implémentée. Ceci peut s expliquer par la complexité des structures de donnée proposées. Les architectures basées sur des mécanismes de caches sont elles plus courantes. [Fsa00] est un exemple de l application de ce type d architecture. Dans celle-ci les paquets TCP sont analysés au moyen d un mécanisme de cache dont le contenu est mis à jour à partir de l analyse logicielle du paquet TCP d ouverture de connexion. Les autres paquets sont analysés de manière matérielle. La vitesse pouvant être atteinte par ce mécanisme pour les paquets TCP est de 20 Gb/s. Cependant de telles performances sont souvent atteintes en utilisant une architecture de commutateur associée à plusieurs processeurs de contrôle d accès (un par interface). De telles architectures peuvent se permettre d utiliser des mécanismes de contrôle d accès relativement peu performants tout en fournissant des performances honorables du fait de la distribution des calculs. On peut de ce fait noter que la plupart des architectures de contrôle d accès se basent sur l utilisation de mécanismes de contrôle d accès relativement lents. 4. La gestion du contrôle d accès Les améliorations en terme de sécurité apportées par l utilisation d architectures de contrôle d accès distribuées ont entraîné la multiplication des équipements de contrôle d accès. Celle-ci a été accompagnée au niveau des entreprises, par l interconnexion de sites dépendants d une même entité administrative. Ces deux aspects ont rendu nécessaire l évolution des méthodes traditionnelles de contrôle d accès. Nous décrivons dans ce chapitre ce processus en montrant tout d abord les limites des approches traditionnelles de gestion du contrôle d accès. Nous montrons ensuite les développements les plus récents dans ce domaine Approches traditionnelles Algo. Linéaire CAM SRAM c Interfaces de configuration des outils de contrôle d accès 100 Mp/s a 100 Mp/s a 1 Mp/s 5 Mps 30 Mp/s 6 Mp/s 100 Kp/s b b b c 1 Mp/s c Sensible au dénis de Non Oui Oui Non Non Non Non service Temps d insertion Faible Faible Faible Faible Faible Fort Moyen Temps de calcul préalable Nul Nul Nul Faible Fort Fort Fort a. En se basant sur des mémoires d une latence de 10ns. b. L implémentation n est pas possible. c. L implémentation n a pas été testée. Lakshman & al. Srinivas. & al. Gupta & al. (1) Gupta & al. (2) Comme nous l avons vu en section 2.4, les architectures de contrôle d accès peuvent être constituées d un grand nombre de mécanismes de contrôle d accès. Ces mécanismes étant généralement développés de manière indépendante, il n y a pas de compatibilité entre les services fournis par ces mécanismes ni en ce qui 25

34 Le contrôle d accès dans les réseaux ATM - Le contrôle d accès réseau et sa gestion concerne leurs interfaces de configuration. Les figures 11 et 12 montrent comment une simple règle de contrôle d'accès peut être exprimée au moyen de commandes relativement différentes en fonction de l'équipement auquel elle est destinée (Un routeur Cisco et une station Linux dans notre cas). Dans le cas du routeur on commence par autoriser les demandes de connexion TCP provenant de la station d adresse avec un port source supérieur à 1023 vers le port WWW (port 80) de n importe quelle station. On autorise ensuite les paquets de requêtes correspondant à la connexion établie. On autorise enfin dans le sens du retour les paquets correspondant à des réponses. Il faut noter que les paquets de demande de connexion dans la direction serveur vers client sont naturellement bloqués. Cette propriété est due au fait que la politique de contrôle d accès des routeurs Cisco est de type Tout ce qui n est pas explicitement autorisé est interdit.. Dans le cas de la station linux il n est pas possible de désigner les paquets correspondant à une connexion établie. On est donc amené à interdire les paquets de demande de connexion dans le sens du retour (ligne 2) de manière explicite. Figure 11. Règles de contrôle d'accès pour un routeur Cisco. access-list 101 permit tcp gt 1023 any eq 80 access-list 101 permit tcp gt 1023 any eq 80 established access-list 102 permit tcp any eq gt 1023 established Ces différences rendent la tâche d'administration de l'officier de sécurité plus difficile par le fait qu'elles peuvent provoquer l'introduction d'erreurs pouvant être exploitées par des attaquants dans les fichiers de configuration. De plus l'hétérogénéité oblige l'officier de sécurité à passer un temps important dans l'apprentissage de ces langages, temps qui pourrait être utilisé de manière plus utile d'un point de vue de la sécurité. Figure 12. Règles de contrôle d'accès pour une station Linux utilisant ipfwadmin. ipfwadm -F -a accept -b -P tcp -S : D /0 80 ipfwadm -F -a deny -b -P tcp -S /0 80 -k -D :65535 ipfwadm -F -a accept -b -P tcp -S /0 80 -D :65535 Un deuxième problème posé par une gestion manuelle vient du fait que la configuration des ces mécanismes se fait généralement de manière directe. Ceci signifie que l officier de sécurité doit se déplacer physiquement pour configurer chaque équipement. Cette contrainte pose un problème, même dans le cas d un nombre limité d équipements implémentant des mécanismes de contrôle d accès si ces équipements sont éloignés géographiquement. Pour finir, la multiplication des équipements de contrôle d accès et la mobilité croissante des utilisateurs implique une grande inter-dépendance dans les configurations des mécanismes de contrôle d accès. Il est de ce fait difficile de gérer la complexité des configurations au moyen de méthodes administratives en scindant la tâche d administration des équipements de contrôle d accès en sous tâches pouvant être attribuées à plusieurs individus Plate-formes d administration du contrôle d accès Afin de régler ces problèmes un certain nombre de propositions ont été faites. Elles visent à assurer la gestion des mécanismes de contrôle d accès au travers de plate-formes d administration. Ces plate-formes ne se limitent généralement pas à la gestion du contrôle d accès mais assure également la gestion d autres services (authentification, confidentialité). Par exemple [Sam95] qui résume les résultats du projet européen SAM- SON (Security and Management Services in Open Networks) décrit une architecture de gestion de la sécurité. Cette architecture développe plusieurs idées intéressantes. La première est d'offrir à l'officier de sécurité une interface générique pour la gestion des différents services de sécurité (authentification, contrôle d'accès sur les équipements, audit, gestion des clefs) et des différents mécanismes afin de résoudre le problème d'hétérogénéité. Un autre aspect intéressant est la possibilité d'utiliser plusieurs protocoles de gestion (CMIP et 26

35 Le contrôle d accès dans les réseaux ATM - Le contrôle d accès réseau et sa gestion SNMP) de manière simultanée afin de transporter les informations de configuration jusqu aux équipements de sécurité. [Ma98] est un bon exemple d outil commercial utilisant le même principe et qui l applique à la gestion de firewalls provenant d un même constructeur. Contrairement à SAMSON, il propose l utilisation d un protocole propriétaire afin d assurer le transport sécurisé des informations de configuration. Le problème principal de ces architectures est qu elles sont limitées à la gestion des équipements d un seul constructeur par le fait qu il n y a pas d interface générique entre l outil de gestion et les mécanismes de contrôle d accès. Un autre problème est le fait que ces architectures nécessitent une configuration manuelle des mécanismes. En effet pour chaque mécanisme, l officier de sécurité doit, au travers d une interface graphique, sélectionner l équipement implémentant le mécanisme devant être configuré puis saisir les paramètres de configuration à la main. Ces opérations bien que plus aisées que dans le cas d une configuration totalement manuelle restent pénibles dans le cas où un grand nombre de mécanismes doivent être configurés Autres propositions Introduction Afin de répondre aux problèmes présentés dans la section précédente, deux solutions doivent être apportées. La première consiste en l expression de la politique de contrôle d accès. Cette expression doit être suffisamment générique pour permettre d exprimer les capacités de contrôle d accès de tous les mécanismes pouvant être trouvés sur un réseau. La deuxième porte sur la distribution automatique et la traduction de la politique préalablement définie auprès de ces mécanismes. Cette distribution peut être réalisée à partir d une plate-forme d administration au moyen d un modèle du réseau ou de manière distribuée par les équipements de contrôle d accès Expression générique d une politique de contrôle d accès Langage formel Historiquement, la première approche pour l expression du contrôle d accès a été l utilisation de langages formels. Ainsi [Gu97] propose d exprimer la politique de contrôle d accès P sous la forme d un ensemble de règles. Chaque règle est décrite au moyen d une fonction H ij (p k ) qui à partir d une zone de destination a j, d une zone source a i et d un paquet p k donne une action à appliquer sur le paquet. Cette action peut être soit une interdiction, soit une autorisation. Chaque paquet est décrit par des adresses source et destination, un service et une orientation. Les zones sont décrites au moyen d un ensemble d adresses. [Ft98] propose la représentation de la politique de contrôle d accès P sous la forme de la relation suivante: U C S C U A Où U est l ensemble des utilisateurs, C l ensemble des équipements, S l ensemble des services et A l ensemble des actions. Il faut noter que cette représentation est plus riche que la précédente puisqu elle distingue utilisateurs et équipements. Ceci permet de définir les règles s appliquant aux utilisateurs indépendamment des équipements et vice-versa. D autre part le fait que S ne se limite pas aux communications permet également d exprimer les relations entre utilisateurs et services sur un même équipement. L avantage d une notation formelle est, lorsqu elle est accompagnée d une description formelle du réseau, de pouvoir prouver que la distribution des règles de contrôle d accès respecte bien les propriétés de contrôle d accès exprimée par la politique de contrôle d accès. Elle permet d autre part de dériver de manière automatique une configuration correcte des mécanismes de contrôle à partir de la politique de contrôle d accès et du modèle du réseau. Cependant leur utilisation est parfois difficile par le fait qu elles utilisent des notations éloignées de celles utilisées par les équipements de contrôle d accès. D autre part la preuve de la correction 27

36 Le contrôle d accès dans les réseaux ATM - Le contrôle d accès réseau et sa gestion concernant la distribution d une politique n est intéressante que s il est également possible de prouver la correspondance entre la politique formelle et une traduction compréhensible par les équipements de contrôle d accès. Cette preuve est absente des propositions citées ci-dessus Langages de bas niveau à base de règles La seconde approche ([Hyl98], [Nes98], [Hin99], [Con00]) propose l expression de la politique de contrôle d accès sous la forme d un ensemble de règles. Chaque règle est formée d un ensemble de prédicats et d une action qui doit être appliquée par les mécanismes de contrôle d accès si l ensemble des prédicats est vérifié. Les prédicats portent sur les communications entre équipements. Parmi ces travaux on peut distinguer [Con00] qui présente un début de normalisation par l IETF d un langage permettant la spécification de règles concernant plusieurs services de sécurité. L intérêt des langages à base de règles est de rester proche des langages utilisés pour la configuration des équipements de contrôle d accès. Ceci permet d une part de faciliter leur apprentissage par les officiers de sécurité et d autre part de concevoir des outils de traduction relativement simples et donc fiables. Un des inconvénients est, lorsque le langage n autorise pas le groupage (Hyl98]), la taille et donc la complexité de la politique de contrôle d accès Langage à base de rôles La proposition suivante est d utiliser une modélisation des comportements des équipements du réseau au moyen de rôles ([Ba99]). Ceux-ci permettent de décrire les communications autorisées entre les équipements du réseau. Les communications non prévues par les rôles sont interdites par défaut. Les rôles sont décrits au moyen de trois ensembles (S, E et R). S décrit les services en terme de ports source et destination, E décrit les équipements et R décrit les rôles c est à dire les relations entre équipements et services. L intérêt de l utilisation des rôles est qu ils permettent de réduire fortement la taille de la politique de contrôle d accès. En effet ils évitent une spécification complète des relations d équipement à équipement en autorisant la représentation d ensemble d équipements sous la forme de rôles. On peut cependant remarquer que cette réduction est comparable à celle qui est effectuée au moyen d un langage déclaratif autorisant le groupage d adresses ([Hin99]). Un autre avantage souvent avancé en faveur des rôles est la facilité avec laquelle les politiques peuvent être exprimées. Si cet argument est valable pour des utilisateurs sans connaissances du domaine, il l est moins pour des officiers de sécurité. Pour conclure il faut également ajouter que la traduction entre langages à base de rôles et langages de configuration des équipements de contrôle d accès n est pas aussi facile que celle d un langage de bas niveau. De ce fait une traduction dans une syntaxe intermédiaire de bas niveau est généralement fournie à l officier de sécurité afin qu il puisse vérifier la cohérence de la configuration obtenue ([Ba99]) Langage déclaratif de haut niveau La dernière proposition ([Kon99]) est d étendre les langages de contrôle d accès afin d autoriser la spécification de contraintes concernant d autres services de sécurité que le contrôle d accès (confidentialité, authentification). Les auteurs proposent une approche dans laquelle la politique de sécurité et un modèle du réseau sont décrits sous la forme d objets. La politique de sécurité est déclarée sous la forme d un ensemble de contraintes. Une contrainte est une relation entre des évènements pouvant se produire dans le réseau et des actions devant être réalisées. L un des points forts de ce langage est la possibilité de décrire les interactions entre les équipements du réseau et le gestionnaire de politique en faisant en sorte que des évènements détectés au niveau des équipements du réseau provoquent des actions au niveau du gestionnaire et que ces actions provoquent une reconfiguration des équipements du réseau et cela quel que soit le service. Le langage est cependant particulièrement complexe. 28

37 Le contrôle d accès dans les réseaux ATM - Le contrôle d accès réseau et sa gestion Optimisations utilisées pour la distribution de la politique de contrôle d accès Les propositions concernant la distribution automatique de contrôle d accès se basent sur certaines optimisations afin de limiter le nombre de règles devant être attribuées à chaque mécanisme de contrôle d accès tout en assurant que la politique de contrôle d accès sera bien implémentée. On peut dénombrer deux critères d optimisation Optimisation basée sur les capacités de contrôle d accès La première optimisation ([Ft98]) est aussi la plus simple, elle consiste à s assurer que le mécanisme de contrôle d accès a la capacité d implémenter la règle qui lui est attribuée. Cette règle permet d une part de limiter la diffusion des règles dans le réseau et d autre part de s assurer d une implémentation correcte de la politique de contrôle d accès Optimisation basée sur la topologie Le principe des optimisations basées sur la topologie ([Gu97], [Nes98], [Ft98], [Ba99], [Hin99], [Kon99]) est d utiliser un modèle du réseau pour déterminer les mécanismes devant implémenter une règle. La figure 13 fourni un exemple de l optimisation pouvant être réalisée. Supposons qu à un instant t, les communications entre A et B passent par la série de filtres grisés du fait des protocoles de routage mis en oeuvre dans le réseau. Il devient inutile d implémenter les règles de contrôle d accès relative à la communication entre A et B dans les filtres non grisés puisque ceux-ci ne reçoivent pas d informations relatives à cette communication. Il est donc possible grâce à une connaissance des informations de routage échangées dans le réseau de limiter la distribution des règles de contrôle d accès. Figure 13. Optimisation pour une communication concernant les équipements A et B. Filtre Filtre Filtre A Filtre Filtre Filtre Filtre B Filtre Filtre Filtre Implémentation des mécanismes de distribution Deux méthodes sont aujourd hui proposées pour l implémentation des mécanismes de distribution. La première appelée méthode centralisée se base sur une station d administration ayant une connaissance totale de la politique de sécurité et de la topologie du réseau et décidant de l attribution, de la traduction et de la distribution des règles de la politique de contrôle d accès aux filtres présents dans le réseau à protéger. La seconde approche consiste à laisser les équipements de contrôle d accès décider de leur propre configuration en fonction de leur propre connaissance du réseau et de la politique de contrôle d accès Méthodes centralisées Dans le cadre des méthodes centralisées, l officier de sécurité définit d une part la politique de contrôle d accès et d autre part une représentation du réseau. Cette représentation du réseau inclut généralement la topologie de celui-ci mais peut également décrire ([Nes98]) les capacités de contrôle d accès des équipe- 29

38 Le contrôle d accès dans les réseaux ATM - Le contrôle d accès réseau et sa gestion ments. Cette représentation est utilisée pour réaliser d une part la traduction des règles de contrôle d accès dans une forme compréhensible par les filtres devant être configurés et d autre part la sélection des règles devant être appliquées à chaque équipement. On peut distinguer trois types de modèles de réseaux en fonction des algorithmes de sélection de règles utilisés Méthode utilisant un modèle cylique du réseau [Gu97] utilise un modèle cyclique du réseau dans lequel chaque équipement est représenté par un noeud et chaque lien physique par un arc. Ce modèle est utilisé pour déterminer le positionnement des règles vis à vis des filtres et est construit par l officier de sécurité. L algorithme de positionnement fonctionne de la manière suivante. La première partie consiste à assigner un comportement de filtrage initial à chaque filtre. On définit pour chaque filtre r un comportement de filtrage (filtering posture) F(inb,outb) comme la liste des règles devant être appliquées pour les flux en entrée (inb) et pour les flux en sortie (outb). On considère ensuite chaque chemin C(a i,a j ) permettant d aller de la zone a i à la zone a j en passant par le filtre r. On définit également l ensemble des flux possibles E(a i,a j ) (feasability set) comme l ensemble des flux pouvant atteindre le filtre r par le réseau en suivant C(a i,a j ). Enfin, on définit comme P(a i,a j ), la politique concernant les communications entre a i et a j. On peut alors calculer de manière itérative outb comme outb \ (E(a i,a j )\P(a i,a j )) (où a \ b désigne la différence entre les ensembles a et b). Les règles relatives inb sont, elles, construites afin d empêcher l usurpation d adresse. Une étude de l algorithme proposé montre que celui-ci a pour effet d attribuer toutes les règles de contrôle d accès à tous les filtres à l exception des règles d interdiction. Celles-ci ne sont appliquées à un filtre que s il existe un chemin entre la zone source et la zone destination correspondant à la règle et sur lequel celle-ci n est pas déjà appliquée. Comme aucune information de routage n est prise en compte dans le modèle du réseau, il est possible d obtenir des configurations redondantes vis à vis du protocole de routage. Ces chemins cycliques génèrent des configurations non optimales car les règles de contrôle d'accès peuvent être attribuées à des équipements de contrôle d'accès qui ne sont pas topologiquement sur le chemin emprunté par une communication Méthodes utilisant un modèle acyclique du réseau Afin de résoudre ce problème [Nes98] et [Ba99] proposent l utilisation d un modèle acyclique du réseau. Celui-ci est représenté sous la forme d un arbre dans lequel chaque équipement est représenté par un noeud et chaque lien logique décrivant les configurations de routage des équipements du réseau est représenté par un arc. Cette représentation est construite par l officier de sécurité avant toute utilisation de l algorithme d association. Celui-ci consiste alors pour chaque règle r à déterminer une source (s) et une destination (d). Il est alors possible grâce au modèle du réseau de déterminer un chemin unique entre s et d. La règle r peut de ce fait être attribuée à l ensemble des filtres présents sur ce chemin. L association est optimale vis à vis du routage étant donnée que seuls ces équipement peuvent être traversés par les flux circulant entre s et d. Cet algorithme, extrêmement simple a néanmoins un inconvénient. En effet, dans le cas d une modification de la topologie physique ou logique du réseau, l officier de sécurité est obligé de reconfigurer le modèle représentant le réseau afin d y faire paraître les modifications puis de relancer le processus de distribution des règles. Cette opération est à la fois pénible et dangereuse, d une part parce-que dans le cadre d un réseau où les changements topologiques sont fréquents elle constitue une charge de travail importante pour l officier de sécurité et d autre part parce-que le temps écoulé entre le changement topologique et sa prise en compte par l officier de sécurité peut être utilisé par des attaquants pour déjouer les mécanismes de contrôle d accès Méthodes utilisant un modèle mixte du réseau Ces problèmes ont conduit [Hin99] à proposer un modèle intermédiaire permettant de faire un compromis entre facilité d utilisation et perfromances. Dans celui-ci, les équipements peuvent être représentés plusieurs fois afin de modéliser les changements topologiques possibles. Le modèle du réseau est alors constitué d un arbre dans lequel certains équipements sont répliqués. L algorithme présenté en section est alors 30

39 Le contrôle d accès dans les réseaux ATM - Le contrôle d accès réseau et sa gestion modifié pour chercher tous les chemins menant de la source s à la destination d. L inconvénient de cette approche est de ne pas proposer une configuration optimale des filtres Conclusion Comme nous avons pu le voir, l utilisation de méthodes se basant sur un modèle statique du réseau, oblige l officier de sécurité à faire un choix entre sécurité, facilité d utilisation et optimisation du positionnement des règles de contrôle d accès au niveau des filtres. Cette limite est observée dans [Nes98] et [Kon99] qui proposent la construction d un modèle du réseau de manière dynamique en utilisant des outils de découverte de la topologie du réseau. Cette solution bien qu intéressante par le fait qu elle limite la charge de l officier de sécurité tout en offrant une bonne optimisation n est cependant pas développée dans les deux articles. Cette solution ne règle de plus pas le problème des trous de sécurité Méthodes distribuées Parallèlement aux méthodes de distribution centralisées présentées dans la section précédente, plusieurs méthodes ont été développées afin de réaliser le processus de distribution de manière distribuée. Le principe de ces méthodes est de faire en sorte que les équipements de contrôle d accès utilisent les connaissances qu ils ont du réseau et de leur propres capacités de contrôle d accès afin d adapter la politique de contrôle d accès à leur propre situation. Ainsi [Hyl98] suggère que les règles de contrôle d'accès soient diffusées dans le réseau à la manière des informations de routage. Les auteurs présentent comme exemple un protocole de distribution des règles de contrôle d'accès pour les routeurs filtrants (PFIP - Packet Filter Information Protocol). Le protocole PFIP fonctionne dans un environnement où chaque routeur ou filtre est supposé avoir les mêmes capacités de contrôle d accès. Pour chaque règle de contrôle d accès on maintient dans chaque filtre f, une variable qui est incrémenté à chaque fois que la règle r est appliquée. Lorsque le compteur est incrémenté, on cherche la source s ayant généré le flux c et provoqué l incrémentation du compteur. On cherche ensuite le filtre f ayant précédé f sur le chemin suivi par c. On envoie ensuite r à f de telle sorte que celui-ci l applique. Cette architecture permet donc aux équipements de contrôle d'accès de diffuser les règles de contrôle d accès dans le réseau en suivant le chemin suivi par les connexions qu elles contrôlent. Cependant la méthode d'optimisation de la configuration des équipements vise à optimiser l'utilisation du réseau en limitant le nombre d équipement traversé par les communications et non le processus de contrôle d'accès lui-même. [Ft98] propose l utilisation d agents se plaçant sur les équipements de contrôle d accès et permettant la configuration des mécanismes de contrôle d accès. Ces agents appelés PTU (Policy Transformation Unit) reçoivent en entrée une description du réseau, la politique de contrôle d accès et une description des capacités de contrôle d accès de l équipement sur lequel se place le PTU. Le PTU utilise ces trois informations pour déterminer les règles devant être appliquées à l équipement et pour traduire ces règles en commandes compréhensibles par les mécanismes de contrôle d accès. Cependant les auteurs ne fournissent pas d informations concernant la façon dont ces traduction peuvent être implémentées Conclusion Comme nous avons pu le voir dans ce chapitre les travaux concernant la gestion du contrôle d accès se sont pour le moment axés sur deux sujets principaux. Le premier est la définition du langage le plus approprié, c est à dire d une part le plus ergonomique mais également le plus riche en terme d expression de la politique et de la relation entre évènements se produisant sur le réseau et actions de gestion. Le second est la définition d une architecture de distribution des politiques de contrôle d accès pouvant être exprimées au travers du langage choisi. Pour conclure ce sous chapitre il faut également signaler qu en dehors des travaux portant sur la distribution et l expression de politique de contrôle d accès un certain nombre de travaux sont en cours ou ont été réalisés dans le groupe de travail RAP (Ressource Allocation Protocol) de l IETF afin d assurer le transport de 31

40 Le contrôle d accès dans les réseaux ATM - Le contrôle d accès réseau et sa gestion politiques ([RFC2748]) entre une plate forme d administration appelée PDP (Policy Decision Point) et un point d application de celles-ci appelé PEP (Policy Enforcement Point). On doit cependant s interroger ([Wij99], [Ste99]) sur les apports de ce protocole vis à vis d une solution qui serait basée sur l utilisation d un protocole de gestion classique tel que SNMP. 5. L intégrité du contrôle d accès 5.1. Introduction Nous avons vu dans les chapitres précédents comment le service de contrôle d accès pouvait être rendu dans les réseaux, de sa définition, à sa mise en oeuvre. Nous abordons dans cette section un dernier élément important, celui de l intégrité du service de contrôle d accès, c est à dire sa capacité à résister à des attaques de la part d utilisateurs malveillants du réseau. Les techniques permettant d assurer ce type protection peuvent être classés en trois catégories. La première consiste à s assurer que les équipements ne peuvent pas être modifiés physiquement. Une fois cette protection assurée, il convient de garantir que le fonctionnement logiciel des équipements constituant l architecture de contrôle d accès ne peut pas être modifié. Comme nous l avons vu en section 4.2, les architectures de contrôle d accès peuvent être configurées de manière distante au moyen d architectures de gestion du contrôle d accès. Il convient donc d assurer l intégrité des communications afin qu un utilisateur mal intentionné ne puisse pas modifier la configuration de l architecture de contrôle d accès en modifiant les informations de configuration transmises par le réseau. Il convient pour les mêmes raisons de s assurer que ces informations de configuration sont bien générées par un outil de configuration autorisé Intégrité physique des équipements Parmi les moyens utilisés pour assurer un intégrité physique des équipements, on peut distinguer deux grandes fonctions. La première consiste à s assurer que les équipements ne peuvent pas être modifiés physiquement par leurs utilisateurs directs. On utilise pour cela des moyens de protection physique classiques tels que les portes et murs blindés, systèmes d identification, services de gardiennage, systèmes de détection d effraction, systèmes de vidéo surveillance pour limiter l accès au matériel. Il existe également des systèmes pouvant être combinés au matériel (boîtiers blindés, éléments scellés) assurant un service similaire ([Gar96]). Le second problème consiste à empêcher une modification logique d équipements au moyen de mécanismes physiques. En effet, un des problèmes souvent évoqué dans la mise en oeuvre de solutions de contrôle d accès est que la modification physique des équipements rend inutile tout type de protection logique. Il a de ce fait été proposé des équipements non modifiables afin de garantir une protection logique. Ainsi [Kim94] et [Bell99] proposent d utiliser des supports non réinscriptibles (CD-ROMs, lecteurs de disques configurés en mode lecture seule, cartes à puce, cartes mémoire) afin d assurer la protection de données dont l intégrité est sensible (système d exploitation, bases de données d intégrité,...) Intégrité logique des équipements Modèles théoriques La sécurité logique des équipements se base sur l utilisation de modèles. Dans le cas du service d intégrité, trois modèles ont été proposés [Goll99]. Le plus ancien appelé modèle de Biba a pour but de garantir la fiabilité des informations auquelles les utilisateurs peuvent accéder. Pour cela il définit deux types d éléments logiques, les sujets qui représentent les utilisateurs et ont la capacité d exécuter des actions et les objets qui sont associés à des éléments logiques du système (par exemple des fichiers). Il définit ensuite deux fonctions permettant d associer à chaque objet un 32

41 Le contrôle d accès dans les réseaux ATM - Le contrôle d accès réseau et sa gestion niveau d intégrité et à chaque sujet un niveau d autorisation. L accès en lecture à un objet est possible si le niveau d intégrité de l objet est supérieur ou égal au niveau d autorisation du sujet. De même un sujet ne peut créer ou modifier un objet que si le niveau d intégrité de celui-ci est inférieur ou égal à son niveau d autorisation. Ces deux propriétés garantissent la confiance que les utilisateurs peuvent avoir dans les informations. Le modèle de Biba est généralement associé au modèle de Bell-Lapadula qui a, lui, pour but d assurer la confidentialité des informations par contrôle d accès (le modèle est alors appelé Biba-Bell-Lapadula). Cette approche, lors de sa mise en pratique suppose l utilisation de fonctions de contrôle parfaites. Cette propriété est difficile à garantir. Le modèle de Clark et Wilson, plus récent, préconise une approche différente en définissant un ensemble de conditions assurant l intégrité des données. Ces conditions portent d une part sur les opérations pouvant avoir lieu dans un système d information et d autre part sur la séparation de rôles entre les différents acteurs du système. Les contraintes sur les opérations portent sur le respect d un certain nombre de règles (règles de certification et règles de mise en oeuvre) garantissant que les opérations ne peuvent pas déboucher sur une modification non autorisée des données (Well Formed Transactions). Comme on peut le voir, ce modèle utilise une notion plus large de l intégrité des données qui rejoint par certains points le contrôle d accès. Le dernier modèle, n est pas un modèle d intégrité à proprement parler mais un modèle de contrôle d accès. Celui-ci appelé HRU (Harrison, Ruzzo, Ullman) utilise également la notion d objets et de sujets. Les relations possibles entre sujets et objets sont définies au moyen d une matrice d accès définissant pour chaque couple (sujet, objet) les actions possibles du sujet sur l objet. L intégrité des données est alors garantie par une définition correcte de la matrice de contrôle d accès. Dans la pratique, seuls les modèles HRU et BBLP (Biba-Bell-Lapadula) sont implémentés. Ils ont donné lieu à deux approches différentes du contrôle d accès ([Obook]). La première appelée contrôle d accès discrétionnaire (DAC - Discretionary Access Control) utilise le modèle HRU alors que le second appelé contrôle d accès obligatoire (DAC - Mandatory Access Control) se base sur le modèle BBLP Système à contrôle d accès discrétionnaire La plupart des architectures de contrôle d accès se basent aujourd hui sur l utilisation d un système de type UNIX ou Windows NT. Ces systèmes implémentent généralement le modèle HRU. Afin de faciliter son utilisation les deux systèmes proposent la possibilité de grouper les sujets et les objets. Dans les systèmes de type UNIX ([Nem95]) on associe de ce fait à chaque utilisateur un identificateur (UID - User ID) et un identificateur de groupe (GID - Group ID). La relation entre utilisateurs et objets est réalisée en associant aux objets un GID et un UID. Les types d accès distingués sont la lecture, l écriture et l exécution. Windows NT ([Goll99]) inclut un mécanisme similaire mais distingue des types d accès différents (lecture, écriture, exécution, effacement, changement de droits, changement de propriétaire). Ceux-ci sont spécifiés au moyen de listes de contrôle d accès (ACL - Access Control Lists) attachées à chaque objet Utilisation de configurations particulières Un point commun des deux systèmes présentés précédemment est de définir la notion d administrateur. L administrateur correspond à un utilisateur pour lequel les opérations de contrôle d accès ne sont pas réalisées ([Gar96]). Un des problèmes courant dans les architectures de contrôle d accès est que certaines applications de contrôle d accès nécessitent d être exécutées par l administrateur. Ceci peut poser de graves problèmes de sécurité en particulier si le fonctionnement de l application n est pas sûr. De ce fait des mécanismes ont été développés afin de limiter les possibilités d un utilisateur malveillant d une part d accéder aux équipements de contrôle d accès et d autre part de restreindre ses actions si celui-ci parvenait a prendre le contrôle d une telle application. Afin de limiter l accès aux équipements de contrôle d accès il est généralement préconisé de limiter l accès des utilisateurs à ceux-ci, de limiter les services fournis par les équipements et de retirer les outils 33

42 Le contrôle d accès dans les réseaux ATM - Le contrôle d accès réseau et sa gestion pouvant être utilisés par un utilisateur malveillant ([Gar96], [Che94], [Cha95]). Certains produits ([Gom94], [Ss00], [PN798]) proposent une modification du système d exploitation permettant de ne pas attribuer d adresses IP aux interfaces du firewall de telle sorte que celui-ci ne soit pas accessible par le réseau. D autre part pour remédier au problème de sûreté des services fournis par les équipements de l architecture de contrôle d accès, des commandes (chroot sous les systèmes de type UNIX) ont été développées afin de limiter les actions possibles d un utilisateur malveillant en les confinant à un espace limité du système de fichier Système à contrôle d accès obligatoire [Dal97] suggère d utiliser un système à contrôle d accès obligatoire appelé CMW (Compartmented Mode Workstation) afin de régler le problème posé par les pouvoirs de l administrateur. En effet les systèmes CMW ne possèdent pas la notion d administrateur. Dans ce type de système, les opérations d administration sont décomposées en un ensemble d actions auxquelles sont associées des autorisations. De manière symétrique, le système définit des privilèges permettant l exécution d une action en fonction de l autorisation qui lui est associée. Cette capacité permet d isoler les besoins en terme de privilèges des applications qui devaient être exécutées en mode administrateur sur un système DAC. Le second point intéressant de ce système est sa capacité à implémenter un système de contrôle d accès de type BBLP. Celle-ci est utilisée par les auteurs pour séparer les opérations des utilisateurs extérieurs de celles des utilisateurs internes en créant deux niveaux. Il est ensuite possible au moyen des privilèges d autoriser certains transferts de données entre les deux niveaux. Un tel système a également été utilisé dans plusieurs produits commerciaux (en particulier [Vv98]). Il faut cependant noter que l apport en matière de sécurité apporté par l utilisation d un tel système est contrebalancé par des performances plus faibles Systèmes d audit La sûreté de l architecture de contrôle d accès n étant pas garantie par les systèmes présentés précédemment, il convient de surveiller celui-ci afin de détecter d éventuelles attaques et leur conséquences sur l intégrité du système et du service de contrôle d accès. On peut de ce fait distinguer deux types d applications, celles ayant pour but de détecter des accès non autorisés et d autre part celles vérifiant l intégrité du système. Les applications de détection d accès non autorisés ([Me94]) utilisent souvent sur une approche basée sur des scénarios (les approches comportementales qui utilisent une modélisation du comportement des utilisateurs sont peu efficaces dans le cas des firewalls). Pour cela elles se servent d une part du contenu des fichiers d audit produits par le système d exploitation et les services fournis et d autre part d une description des attaques connues. Ces principes ont été repris afin de détecter des attaques au moyen d analyseurs réseaux ([Vign98]). Les applications de vérification d intégrité telles que ([Hess93], [Kim94]) ont, elles, pour objectif de vérifier l intégrité des fichiers contenus dans le système en associant à chaque fichier une signature stockée dans une base de donnée. L officier de sécurité vérifie par la suite que ceux-ci ne sont pas modifiés ou effacés en utilisant un programme recalculant la signature et vérifiant que celle-ci est la même que celle contenue dans la base de donnée. Il est évidemment essentiel que l intégrité de cette base de donnée soit elle-même assurée Conclusion Comme nous l avons montré dans ce paragraphe, la mise en place de solutions assurant l intégrité passe par la mise en oeuvre d une chaîne de mécanismes, chacun d entre eux permettant d accroître la confiance que l officier de sécurité peut avoir dans les mécanismes de contrôle d accès puisqu il n existe pas de moyen de garantir (au sens mathématique du terme) l intégrité d une architecture. Il faut cependant noter que ces mesures techniques ne sont utiles que dans la mesure où elles sont accompagnées de mesures administratives visant à responsabiliser les utilisateurs du réseau que l on désire protéger. Ces mesures passent par la définition d une politique de sécurité, par la formation des utilisateurs afin qu ils en comprennent l utilité et enfin 34

43 Le contrôle d accès dans les réseaux ATM - Le contrôle d accès réseau et sa gestion par la définition et l application de sanctions en cas de manquement aux règles définies par la politique de sécurité Intégrité des communications L intégrité des communications liées au transport des informations de gestion du contrôle d accès se base sur l utilisation de mécanismes de signature. Ceux-ci permettent également d assurer l authentification des informations transportées. Les mécanismes de signature ([Pa96]) se basent sur l utilisation de fonctions qui, à partir des informations à transporter I et d une clef C, produisent un message M de taille fixe construit de telle sorte que seul le possesseur de C ait été capable de construire M à partir de I. D autre part, les fonctions de signatures assurent également que tout possesseur de C (dans le cas des algorithmes de chiffrement à clefs secrètes) ou d une clef C construite à partir de C (dans le cas des algorithmes de chiffrement à clefs publiques) est capable de vérifier que d une part I n a pas été modifié pendant son transfert et que M a bien été construit à partir de C et de I. Les fonctions de signature sont généralement construites en associant des fonctions de chiffrement (DES, RSA) à des fonctions de calcul d empreinte (MD5, MD4, MD2, SHA). La signature se calcule alors en calculant une empreinte sur les informations à transmettre et en chiffrant celui-ci. Le résultat est ensuite associé au message afin d en assurer l intégrité et l authentification. Si les mécanismes de signature permettent d assurer les services d intégrité et d authentification, ils ne permettent cependant pas d assurer que les informations ne sont transmises qu une seule fois sur le réseau (intégrité du flot de données). Cette propriété est importante car elle assure que des messages utilisés dans le passé ne pourront pas être réémis dans le futur par un utilisateur mal intentionné afin de modifier la configuration des équipements de contrôle d accès. Les mécanismes d intégrité du flot de données sont généralement réalisés en associant un identificateur de message (numéro de séquence dans le cas des communications en mode connecté, estampille temporelle dans le cas des communications en mode non connecté) au message à transmettre et ceci avant sa signature. Cet identificateur de message est utilisé par le récepteur du message afin de vérifier que le message n a pas déjà été reçu dans le passé. Vis à vis des deux protocoles généralement utilisés aujourd hui pour le transport des informations de gestion du contrôle d accès (SNMP et COPS - Common Open Policy Service) deux approches sont préconisées: La première consiste à associer au protocole les mécanismes utilisés pour rendre les services d authentification, d intégrité et d intégrité du flot de données ([RFC2571], [RFC2572], [RFC2572], [RFC2748], [Sta99]). Ainsi dans COPS ([RFC2748]) le service utilise une fonction HMAC (Hash Message Authentication Code) afin d assurer la signature des unités de données transmises et un numéro de séquence afin d assurer l intégrité du flot de données. De manière similaire la version 3 de SNMP ([RFC2572], [RFC2574]) suggère d utiliser une fonction HMAC HMAC-MD5-96 ou HMAC-SHA-96 sur l ensemble du message SNMP afin de calculer la signature de chaque message. HMAC-MD5-96 est une fonction HMAC utilisant la fonction MD5 afin de calculer un résidu sur le résultat d une combinaison des informations à transmettre et d une clef secrète. Le résidu est ensuite tronqué à 96 bits. La fonction HMAC-SHA-96 est similaire mais utilise SHA pour le calcul du résidu. Les spécifications préconisent également d utiliser un numéro de séquence sur 32 bits afin d assurer l intégrité du flot de données. La seconde approche (COPS, [RFC2748]) consiste à utiliser les services de sécurité proposés par un protocole sous-jacent tel que TLS (Transport Layer Security Protocol, [RFC2246]) ou IPSEC (Internet Protocol Security architecture, [RFC2401]). Les services désirés sont fournis dans IPSEC au moyen d en-têtes de sécurité du protocole IP. Les en-têtes du protocole IP en matière de signature ([RFC2402]) ne spécifient pas de fonction de signature mais définissent le format et la portée de la signature réalisée. D autre part comme dans le cas de COPS et SNMP, un numéro de séquence sur 32 bits est utilisé afin d assurer l intégrité du flot de données. Dans le cas de TLS, un protocole (TLS Record Protocol) intercalé entre la couche transport TCP et la couche application est utilisé afin de fournir les services d authentification, d intégrité des données et du 35

44 Le contrôle d accès dans les réseaux ATM - Le contrôle d accès réseau et sa gestion flot de données. La principale différence entre les deux spécifications vient du numéro de séquence, codé sur 64 bits dans le cas de TLS. 6. Conclusion La mise en place d une architecture de contrôle d accès réseau passe la mise en oeuvre de plusieurs phases. La première consiste à concevoir des équipements de contrôle d accès auquels on puisse accorder une confiance justifiée et dont on puisse contrôler les défaillances. On se base pour cela sur la mise en place d équipements physiquement sûr, capables d assurer l intégrité logique des services qu ils assurent et à même de communiquer de manière sûre avec les architectures de gestion chargées de les configurer. La seconde phase passe par la mise en place de l architecture de contrôle d accès elle même. Celle-ci s appuie sur un ensemble de mécanismes qu il est possible de classer en suivant trois critères (synchronisme, position topologique, position protocolaire). Les besoins en terme de bande passante et l apparition de nouveaux services (différenciation de service) ont entrainé une évolution importante des algorithmes de classement de flux utilisés par ces mécanismes. Si ceux-ci ont énormément évolués au cours des dernières années, leur dernières évolutions restent cependant peu implémentées dans les architectures de contrôle d accès actuelles. On peut cependant prévoir leur arrivée dans un futur proche. L évolution des besoins en matière de sécurité, et en particulier le besoin de contrôle des opérations des utilisateurs à l intérieur des réseaux d entreprise ont entrainé la multiplication des équipements de contrôle d accès. La gestion de ces équipements qui se faisait auparavant à la main à de ce fait du évoluer pour diminuer la complexité des opérations de gestion réalisées par l officier de sécurité. Les architectures de gestion du contrôle d accès se basent d une part sur un langage permettant d exprimer une définition générique du service de contrôle d accès et d autre part sur des mécanismes permettant d assurer une distribution et une traduction automatique de la politique de contrôle d accès sur les équipements adéquats. Nous verrons au chapitre 3 comment ces mécanismes sont utilisés dans le cadre du contrôle d accès dans les réseaux ATM. 36

45 CHAPITRE 3 Le contrôle d accès dans les réseaux ATM Dans ce chapitre nous montrons que le firewall tel qu il est concu aujourd hui n est pas adapté pour fournir un service de contrôle d accès dans les réseaux ATM et présentons les différentes propositions ayant pour but de résoudre ce problème. 1. La technologie ATM 1.1. Introduction Les principes du Mode de Transfert Asynchrone (ATM) ont été élaborés au début des années 80 au CNET Lannion ([Rol99], [Kau96]). Cette origine explique en grande partie les objectifs qui avaient guidé son développement : assurer le transport de flux de nature diverses (téléphonie, données, vidéo,...) sur des supports physiques également divers. Ces caractéristiques ont poussé l Union Internationale des Télécommunications (ITU-T) à considérer la technologie ATM comme la base pouvant servir à la normalisation du successeur du Réseau Numérique à Intégration de Service (RNIS). Des travaux de normalisation ont donc démarré dès le début des années 90 au niveau de l ITU-T et se poursuivent aujourd hui. En parallèle des industriels et des opérateurs, jugeant le processus de normalisation en cours à l ITU-T trop lent décidèrent de former un consortium international appelé l ATM-Forum ayant pour but d accélèrer la spécification, l implémentation et la diffusion des produits basés sur la technologie ATM. Bien que l ITU-T et l ATM-Forum soient indépendants, une certaine cohérence a été assurée entre les spécifications édictées par les groupes de travail de ces deux organismes Modèle de référence ATM Comme nous l avons dit précédemment un des objectifs majeurs de la technologie ATM est d assurer la convergence des flux applicatifs et des supports physiques. Ceci explique la structure du modèle ATM normalisé par l ITU-T. Celui-ci comme indiqué en figure 14 est composé de trois couches. La couche AAL (Application Adaptation Layer) a pour but de faire le lien entre les applications et la couche ATM. Comme les applications utilisant le réseau ATM peuvent avoir des requêtes particulières vis à vis du réseau ATM, cinq types de couches AAL ont été définies par l ITU-T, chacune étant dédiée à un type d application spécifique. Afin d assurer ces fonctions d adaptation, chacune de ces couches utilise des PDUs (Protocol Data Unit) particulières. Les AALs les plus utilisées aujourd hui sont l AAL1 qui est dédiée au transport de flux à débit constant et à fortes contraintes temporelles et l AAL5 qui est généralement associée au transport de flux sporadiques sans contraintes de qualité de service. 37

46 Le contrôle d accès dans les réseaux ATM - Le contrôle d accès dans les réseaux ATM La couche ATM est la couche centrale du modèle ATM. Elle se base sur un découpage sous forme de cellules des données générées par les communications. Les communications, orientées connexion, sont établies au moyen d un protocole de signalisation. Les cellules sont composées de deux parties. Une première partie formée de 5 octets assure les fonctions de contrôle liées à la cellule. La seconde, formée de 48 octets contient les données à acheminer. Afin d autoriser un contrôle plus efficace des connexions dans le réseau, deux types de connexions ont été définies. Le premier appelé VC (Virtual Channel) représente une connexion élémentaire. Les VCs peuvent être ensuite multiplexés dans le deuxième type de connexion appelé VP (Virtual Path). Les VPs peuvent eux-mêmes être multiplexés sur le support physique. La distinction des connexions et leur multiplexage se fait au moyen d identificateurs de connexion VCI (Virtual Chanel Identifier) et VPI (Virtual Path Identifer) placés dans l en-tête de la cellule. Ces deux identificateurs vont assurer la commutation de la cellule dans les commutateurs placés entre sa source et sa destination au moyen d une table de commutation construite à l établissement de connexion. La couche la plus basse du modèle est la couche physique. Elle est chargée de faire le lien entre la couche ATM et les différents types de supports physiques en assurant les fonctions d adaptation entre les cellules ATM et les PDUs propres au support physique ainsi que les fonctions de synchronisation au niveau bit qui dépendent du support physique. Trois grand types de support physique sont utilisés aujourd hui. Le support de type plésiochrone (Plesiochronous Digital Hierarchy - PDH), le support synchrone (Synchronous Digital Hierarchy - SDH) et le support cellule. Les principales différences entre ces types de support viennent du type de PDU utilisé, du type de codage et des débits proposés. Figure 14. Modèle ATM. Plan de contrôle Plan de gestion Plan utilisateur Couche Application Couche AAL Couche ATM Couche Physique Le modèle ATM peut par ailleurs être divisé selon trois plans. Le plan utilisateur est chargé du transport des informations fournies par les applications. Le plan de contrôle est chargé de l établissement, du contrôle et de la fermeture des connexions. Ces opérations sont réalisées au moyen de messages de signalisation. Enfin, le plan de gestion fournit les services de supervision, d exploitation et d administration du réseau. La distinction entre les flux produits par ces trois plans se fait au moyen d informations placées dans l en-tête des cellules ATM. Nous fournirons au chapitre 4 une description détaillée de ces flux Utilisation des réseaux ATM Les utilisations des réseaux ATM peuvent être séparées en deux classes. La première appelée utilisation directe correspond à une utilisation des réseaux ATM par des applications ou des protocoles développés pour utiliser le modèle ATM. Deux applications ont ainsi été normalisées. La première appelée ANS (ATM Name System, [ANS10]) assure la traduction entre nom et adresses ATM sur le modèle du DNS (Domain Name System) dans Internet. La seconde nommée AMS (Audiovisual Multimedia Services, [VOD10]) permet la diffusion de flux multimedia à la demande. Plusieurs utilisations ont également été normalisées telles que VTOA 38

47 Le contrôle d accès dans les réseaux ATM - Le contrôle d accès dans les réseaux ATM (Voice and Telephony Over ATM to the Desktop, [VTOA10]) qui assure le transport de flux téléphoniques ou CES (Circuit Emulation Service, [CES20]) qui permet l émulation de circuits de 64 kbits/s. La seconde catégorie d utilisations correspond à une utilisation des réseaux ATM par des protocoles déja existant. Les travaux les plus importants dans ce domaine ont porté sur le transport du protocole IP et de procotoles de réseaux locaux IEEE et IEEE Les trois approches actuellement normalisées afin de réaliser cette adaptation sont l émulation de LAN (LANE, [LANE10], [LANE20]), Classical IP over ATM (CLIP [RFC1755], [RFC2022], [RFC2225], [RFC2684]) et Multi-Protocol Over ATM (MPOA, [MPOA10]). Bien que ces trois spécifications soient relativement différentes, elles ont pour objectif de résoudre deux problèmes qui leur sont communs. Le premier est l adaptation de protocoles (IP et ARP) utilisant habituellement un support ayant une capacité naturelle de diffusion au réseau ATM qui lui ne la possède pas. Cette adaptation se fait en utilisant un serveur de diffusion assurant le relayage des paquets ou trames de diffusion vers l ensemble des équipements du réseau. Le second est le problème de résolution d adresse entre adresses MAC, IP et ATM. Les trois solutions proposent l utilisation de serveurs de résolution d adresses. 2. Le firewall Comme nous l avons dit dans le chapitre 2, le firewall est essentiellement une architecture permettant de fournir un service de contrôle d accès dans le cadre de réseaux TCP/IP. L adaptation du firewall aux environnements ATM avait donc pour but de fournir un service de contrôle d accès dans le cas où ATM est utilisé comme support pour un réseau de type Internet. Ceci signifie que cette architecture ne founit en aucun cas un service de contrôle d accès pour les applications natives ATM ou pour les utilisations n ayant pas pour objectif de transporter le protocole TCP/IP Utilisation dans un environnement LANE On distingue dans l environnement LANE (figure 15) quatre types d équipements. Le premier appelé LAN Emulation Client (LEC) représente un équipement désirant utiliser le protocole LANE pour communiquer avec d autres LECs. Pour cela il passe d abord par une phase de configuration en contactant un serveur appelé LAN Emulation Configuration Server (LECS). Celui-ci associe le LEC à un LAN émulé en lui donnant les adresses des deux serveurs utiles au protocole LANE. Le premier de ceux-ci appelé LAN Emulation Server (LES) a pour mission de réaliser les conversions entre adresses MAC et adresses ATM afin de permettre au LECs de communiquer directement entre eux. Le second appelé Broadcast and Unknown Server (BUS) a pour objectif la diffusion des trames de diffusion et de multicast auprès des membres du LAN émulé. Figure 15. Positionnement d un firewall dans un environnement LANE. BUS LES LAN Emulé 1 LEC LEC C D Firewall/Routeur LAN Emulé 2 BUS LES LEC A LEC B Equipement A Equipement B Bien que l utilisation de IP au dessus du LAN émulé ne soit pas obligatoire, on associe généralement un sous réseau IP à chaque LANE. Dans cet environnement le firewall n a d utilité que pour interconnecter deux LANE. Les communications entre les équipements A et B situés dans deux LANE distincts se font de la manière suivante. La couche IP de l équipement A effectue d abord la résolution d adresse entre l adresse IP 39

48 Le contrôle d accès dans les réseaux ATM - Le contrôle d accès dans les réseaux ATM et l adresse MAC correspondant au LEC C. Ce LEC C, correspond au LEC enregistré dans le LAN émulé 1 du routeur vers le LAN 2. La résolution est réalisée en envoyant une requête ARP en diffusion sur le LAN émulé 1 par l intermédiaire du BUS. Une fois l adresse MAC connue, il effectue la résolution d adresse entre l adresse MAC et l adresse ATM correspondant au LEC C en effectuant une requète auprès du LES. Une connexion ATM est ensuite construite entre le LEC A et le firewall. Lorsque celui-ci reçoit le premier paquet de données, il effectue les opérations de contrôle d accès appropriées au niveau transport et applicatif. Dans le cas où la communication est autorisée, le firewall effectue des opérations de résolution d adresse similaires à celles réalisées dans le LAN emulé 1, dans le LAN émulé 2 afin de connaître l adresse ATM correspondant à l adresse IP de B. Il ouvre ensuite une connexion ATM avec B et transmet les paquets destinés à B. Il faut noter que dans le cas du LAN émulé il n est pas possible de filtrer le trafic à l intérieur d un LAN au moyen d un firewall. En effet comme nous l avons montré dans le chapitre 2, les actions executées par un firewall incluent souvent au moins une phase de routage. Il faudrait donc forcer l envoi des paquets IP au firewall au niveau des équipements du LAN émulé. Cette opération n est pas réalisable de manière simple. De ce fait une telle architecture force souvent l administrateur du réseau à partitionner celui-ci pour en assurer la sécurité Utilisation dans un environnement CLIP Dans le cas de l environnement CLIP (figure 16) le scénario d établissement de connexion n est pas très différent de celui présenté dans le paragraphe précédent. La résolution d adresse entre adresse IP et adresse ATM se fait directement au moyen d un serveur appelé ATMARP Address Resolution Server (AARPS). La diffusion des informations de broadcast et de multicast peut se faire de deux façons. La première, appelée full mesh mode, consiste à gèrer auprès de chaque membre du groupe une connexion ATM multicast vers tous les autre membres du groupe. L ajout et le retrait des membres du groupe se fait alors par l intermédiaire d un serveur de groupe appelé Multicast Address Resolution Server (MARS, [RFC2022], [RFC2226]). La deuxième méthode consiste à utiliser un serveur multicast particulier, appelé Multicast Server (MCS, [RFC2022]), entretenant à la fois une connexion multicast et une connexion unicast avec tous les membres de chaque groupe. La connexion unicast a pour but d assurer l envoie de données au MCS, celui-ci se chargeant de les diffuser aux membres du groupe. Le serveur MARS est dans ce cas chargé de diriger les clients vers le serveur MCS approprié en fonction du groupe auquel ils souhaitent s abonner. Comme dans le cas du LANE, les communications entre deux équipement ne peuvent être contrôlées que lorsque les deux équipements se trouvent sur des réseaux IP distincts. De ce fait, l utilisation d un firewall nécessite le découpage du réseau ATM en sous réseaux IP appelés LIS (Logical IP Subnetwork). Figure 16. Positionnement d un firewall dans un environnement CLIP. MARS AARPS LIS 1 C D LIS 2 MARS AARPS A Firewall B MCS MCS Le processus de contrôle d accès est similaire à celui réalisé dans le cas d un environnement LANE. On pourrait imaginer d associer un firewall au serveur MCS afin de pouvoir contrôler les communications en multicast et en broadcast à l intérieur d un groupe. Cette possibilité est à la fois d une utilité limitée et peu 40

49 Le contrôle d accès dans les réseaux ATM - Le contrôle d accès dans les réseaux ATM facile à mettre en oeuvre techniquement. En effet cet architecture ne permet que de contrôler qu une partie des communications (les communications unicast en sont exclues). De plus les MCS ne sont pas tenus d implémenter une couche IP et peuvent se contenter de traiter les AAL-SDU ([RFC2022]) Utilisation dans un environnement MPOA L objectif principal de MPOA ([MPOA10]) est de permettre à des équipements situés sur un même réseau ATM mais dans des sous réseaux IP différents de communiquer directement sans passer par un routeur. Cet objectif a pour but d une part d éviter l engorgement des routeurs et d autre part de permettre aux applications ayant des requêtes en terme de qualité de service de profiter d une QoS de bout en bout par l utilisation de connexions ATM directes. Figure 17. Positionnement d un firewall dans un environnement MPOA. LES LES BUS ELAN 1 ELAN 3 BUS MPS A ATM MPS C MPC A MPC C Equipement A ELAN 2 Equipement C BUS LES MPS B Architecturalement, MPOA peut être vu comme une extension du LAN émulé. Il reprend donc les éléments du LANE et y ajoute deux nouveaux. Ceux-ci appelés MPC (MPOA Client) et MPS (MPOA Server) ont pour objectif d assurer l établissement de connexions de bout en bout. La figure 17 présente un exemple dans lequel on désire faire communiquer les équipements A et C. Ceux-ci sont rattachés à une client MPC (MPC A et MPC C). La résolution entre adresses IP et adresses ATM se passe en deux phases. Les deux équipements étant sur deux sous réseaux IP différents, la première phase consiste à faire un résolution entre l adresse IP et adresse MAC du routeur par défaut (le MPS A dans notre cas). Une fois cette résolution réalisée, l équipement A émet des paquets IP à destination de l équipement C. Ceux-ci sont routés vers l équipement C par des routeurs situés dans les ELANs 1, 2 et 3 (ce rôle est généralement joué par le MPS). La deuxième phase intervient lorsque le MPC A décide en fonction des flux existants entre les équipements A et C de réaliser une connexion directe entre le MPC A et le MPC C. Pour cela le MPC A va envoyer une requête au serveur MPS afin que celui-ci réalise une traduction de l adresse IP de l équipement C vers l adresse du MPC auprès duquel C est rattaché. Pour cela celui-ci utilise un protocole appelé NHRP (Next Hop Resolution Protocol, [RFC2332]) qui va assurer cette fonction en utilisant le routage classique pour faire parvenir le requète auprès du MPS appartenant au même sous réseau IP que l équipement C. Un processus de résolution d adresse a alors lieu dans l ELAN 3 afin de faire la relation entre adresse IP et adresse ATM du MPC C. Le 41

50 Le contrôle d accès dans les réseaux ATM - Le contrôle d accès dans les réseaux ATM trajet suivi par les paquets entre les équipements A et C dans le premier cas est indiqué en figure 17 par un flèche noire alors que celui emprunté dans le second cas est indiqué par une flèche grise. Dans cette architecture il est relativement difficile de positionner un firewall. En effet, un positionnement sur le MPS sera facilement contourné puisqu il suffit à un attaquant connecté directement au réseau ATM de connaitre l adresse ATM de son destinataire pour pouvoir communiquer avec celui-ci sans passer par le MPS. Un placement sur les MPCs se révèle également délicat puisque ces fonctions peuvent être implémentées dans des équipements qui ne sont pas tenus d avoir une pile protocolaire TCP/IP et sont parfois implémentés dans des ponts. On pourrait cependant imaginer, dans le cas où le MPC serait implémenté dans un routeur, d étendre le mécanisme utilisé pour déterminer la création des connexions directes qui se base sur l adresse IP de destination afin d y introduire des notions de filtrage sur les adresses IP et sur les ports source et destination. Cette possibilité n est cependant pas évoquée par la norme. A ce sujet, [Xu98b] note que l introduction de telles fonctions dans les MPCs pose également des problèmes de coûts. Il faut de plus noter que seuls les équipements directement connectés aux MPCs peuvent être protégés dans ce cas. Des équipements directement connectés au réseau ATM peuvent, dès le moment ou ils connaissent leurs adresses ATM respectives communiquer de manière directe et donc contourner le service de contrôle d accès réalisé par les MPCs. 3. Etude critique de l utilisation du firewall dans un environnement ATM Nous avons vu dans la section précédente que l utilisation d un firewall dans un réseau ATM posait certains problèmes et limitations architecturales. Dans ce chapitre, nous examinons certaines limitations complémentaires Contrôle d accès et contrat de trafic Introduction Les réseaux de type ATM peuvent fournir des garanties en terme de qualité de service en ce qui concerne les connexions ([Rol99], [Kau96]). Certaines des utilisations des réseaux ATM présentées précédemment utilisent cette capacité (LANE et MPOA). La qualité de service est définie au moyen d un contrat appelé contrat de trafic. Afin de comprendre l'influence du placement d'un type de filtre particulier sur un contrat de trafic ATM nous allons examiner les conséquences de chaque type de filtre sur les paramètres des différents contrats de trafic Contrat de trafic Le contrat de trafic peut être décomposé en trois sous-ensembles de paramètres. Le premier sous-ensemble, appelé descripteur de trafic est utilisé par une source pour décrire le comportement des flux qu elle désire soumettre au réseau ATM. Le descripteur de trafic comprend les paramètres suivants: Le débit crête (Peak Cell Rate - PCR). Le débit moyen (Sustainable Cell Rate - SCR). Le débit minimum (Minimum Cell Rate - MCR). La taille maximale des rafales (Maximum Burst Size - MBS). Le second sous-ensemble, appelé paramètre de performance est utilisé par une source pour spécifier les performances qu elle attend de la part du réseau. Les paramètres suivants sont utilisés: Le taux de perte des cellules (Cell Loss Ratio - CLR). Le délai de transfert des cellules (Cell Transit Delay - CTD). La variation du délai de transfert par cellule (Cell Delay Variation - CDV). 42

51 Le contrôle d accès dans les réseaux ATM - Le contrôle d accès dans les réseaux ATM Le dernier sous-ensemble est utilisé par les fonctions de contrôle de trafic afin de décider de la conformité des cellules à leur contrat de trafic. Ce sous-ensemble est composé d un seul paramètre appelé tolérance de variation de délai de transit (Cell Delay Variation Tolerance - CDVT) Classes de service Afin de faciliter l expression des paramètres pouvant être précisés dans un contrat de trafic, cinq classes de service modélisant le comportement de cinq grandes classes d applications ont été définies par l ATM- Forum: Constant Bit Rate (CBR). Cette classe correspond à des applications temps réel ayant des contraintes strictes sur le délai, la variation de délai et les pertes. La voix et la vidéo à débit constant constituent des exemples d applications adaptées à cette classe. Les paramètres pouvant être spécifiés dans cette classe sont donc des paramètres de débit (PCR) mais également des paramètres temporels (CDVT, CDV, CTD) et des paramètres de tolérance aux pertes (CLR). Cette classe émule en quelque sorte une ligne dédiée dont on pourrait spécifier le débit. Variable Bit Rate real-time (VBR-rt). Cette classe correspond à des applications à débit variables et possédant des contraintes temporelles. Elle est bien adaptée aux applications utilisant un codage audio ou vidéo à débit variable. Les paramètres pouvant être spécifiés dans cette classe sont donc des paramètres de débit (SCR), de sporadicité (MBS) mais également des paramètres temporels (CDVT, CDV, CTD) et des paramètres de tolérance aux pertes (CLR). Son intérêt par rapport à la classe CBR est de permettre un multiplexage statistique par le réseau permettant une utilisation plus efficace de celui-ci. Variable Bit Rate non real-time (VBR-nrt). Cette classe possède les mêmes caractéristiques que la classe VBR-rt à l exception du fait qu elle ne fournit aucune garantie en terme de contraintes temporelles. De ce fait, elle est bien adaptée aux applications n ayant pas de besoin de synchronisation temporelle. Les flux produits par les systèmes de réservation sont de bons exemples d applications rentrant dans cette classe. Available Bit Rate (ABR). Contrairement aux classes précédentes qui fournissent des garanties en terme de débit, de respect de contraintes temporelles et de taux de perte, la classe ABR ne fournit elle qu une seule garantie : le taux de perte. Elle est de ce fait bien adaptée aux applications qui peuvent adapter leur débit à l état de congestion du réseau. Les paramètres pouvant être spécifiés dans cette classe sont des paramètres de débit (PCR, MCR) et des paramètres de tolérance aux pertes (CLR). Unspecified Bit Rate (UBR). Cette classe ne fournit aucune garantie aux applications qui l utilisent. Le tableau 2 montre les liens entre types de contrat de trafic et paramètres de contrat de trafic. Tableau 2. Paramètres utilisés dans les classes de trafic. Classe/Paramètres PCR SCR MBS MCR CTD CDV CLR CBR X x x x rt-vbr X X X x x x nrt-vbr X X X x ABR X X UBR X Note: X: paramètre obligatoire, x: paramètre optionnel. Les paramètres des contrats de trafic sont négociés au moment de l'ouverture de connexion. Une fois ces paramètres négociés, le réseau se doit de garantir une qualité de service conforme à ces paramètres. 43

52 Le contrôle d accès dans les réseaux ATM - Le contrôle d accès dans les réseaux ATM Limites du firewall Dans ce paragraphe nous allons analyser paramètre par paramètre les conséquences d'un contrôle d accès. Précisons tout d abord que cette analyse ne concerne que les flux autorisés par la politique de contrôle d accès pouvant être implémentée par un firewall et non les flux interdits auquel il n est pas possible d associer un qualité de service de bout en bout puisqu ils seront bloqués par celui-ci. Afin de fournir le service de contrôle d accès, le firewall réassemble les paquets IP à partir des cellules ATM. Les fonctions de filtrage sont réalisées au moyen des informations de niveau transport. La qualité de service de niveau ATM peut être décidée de part et d'autre du firewall au travers du contrat de traffic exprimé au moment de l ouverture des connexions. Du fait de la difficulté de faire le lien entre un contrat de trafic au niveau ATM et le dimensionnement des mécanismes de qualité de service au niveau transport ([Cha99]), les firewalls actuels ne mettent pas en oeuvre de mécanisme afin d assurer un respect des contrats de trafics passés au niveau ATM. Il est de ce fait impossible d assurer un respect de la qualité de service de bout en bout. Figure 18. Connexions ATM de part et d autre d un firewall. LIS A C D LIS B Firewall A QOS A QOS A B Dans le cas où une même qualité de service est assurée de part et d'autre de l'équipement (figure 18), les paramètres modifiés sont les suivants: CTD: Le réassemblage, le filtrage, le routage et la fragmentation des paquets ainsi que les opérations de filtrage provoquent une augmentation du délai de transit des cellules. CLR: Les opérations internes à l'équipement peuvent introduire des pertes de paquets. Ces pertes peuvent être par exemple dues à des débordement de files au niveau IP. La perte de paquets au niveau du firewall provoque l augmentation du taux de perte de cellules de bout en bout. CDV: La taille des paquets IP n'est pas fixe. Ceci induit que le temps mis pour réassembler un paquet, le filtrer, le router et pour le fragmenter n'est pas fixe. Il peut donc se produire des variations de délai qui sont, entre autre, fonction de la taille des paquets. PCR, SCR, MCR: Le routage et le filtrage des paquets dans ce type d'architecture se fait de manière logicielle. Il est donc possible que la charge de la machine implique des modifications dans le débit crête, le débit moyen et dans le débit minimum. Cependant comme le filtre est sensé être placé entre deux réseaux et que tout le trafic entre ces deux réseaux est sensé passer par lui, il n'y a pas de déséquencement entre les différents flux. Au niveau application les problèmes sont similaires. Cependant, du fait que les informations remontent jusque dans l'espace utilisateur, les altérations peuvent être plus importantes. 44

53 Le contrôle d accès dans les réseaux ATM - Le contrôle d accès dans les réseaux ATM Tableau 3. Modification des paramètres en fonction du niveau de filtrage. Paramètre/Niveau PCR SCR MBS MCR CTD CDV CLR Modification X X X X X X Conclusion Le tableau 3 résume les modifications apportées aux paramètres utilisés dans les contrats de trafic (une modification est indiquée par un X). On peut remarquer que plus le filtrage se produit dans une couche élevée du modèle OSI plus les altérations des paramètres du contrat de trafic sont importantes. Le tableau 4 indique quels types de contrats de trafic sont modifiés par l'introduction du filtrage. Nous nous sommes limités ici aux deux types de contrats pouvant être utilisés dans le cas de CLIP (UBR), de LANE (CBR, rt-vbr, nrtvbr, UBR, ABR) et MPOA (CBR, rt-vbr, nrtvbr, UBR, ABR). Précisons cependant que la possibilité d utiliser un contrat de trafic différent du contrat UBR n est apparue qu à partir de la version 2 de la spécification LANE ([LANE20]). Tableau 4. Modification des contrats de trafic en fonction du niveau de filtrage. Contrat/Niveau Modification CBR X rt-vbr X nrt-vbr X ABR X UBR x Note: X: Modification, x: Modification lorsque des paramètres optionnel sont spécifiés Mesures expérimentales Un certain nombre de constructeurs de firewall «classiques» proposent des produits sensés pouvoir protéger des réseaux TPC/IP utilisant ATM comme couche de niveau liaison de donnée. Cependant les tests effectués dans [Data97] montrent que ces firewalls sont en terme de performance assez loin de pouvoir fournir un service sur un lien de type OC3 (155Mbps). La plupart sont même incapables de traiter des liens de type E3 (45Mbps). Les tests effectués dans [KL98] apportent quelques informations supplémentaires. Ces tests sont effectués dans un environnement ethernet 100Mb/s commuté sur un ensemble de 5 firewalls. Ils peuvent donner une idée des altérations pouvant être occasionneés dans le cas d'une interconnexion ATM. 45

54 Le contrôle d accès dans les réseaux ATM - Le contrôle d accès dans les réseaux ATM Tableau 5. Modification de certains éléments de contrat de trafic par un firewall. Les résultats des tests sont résumés dans le tableau 5. Si on considère l'interconnexion de deux sites au travers d'un réseau public, chaque réseau étant protégé par un firewall, le délai moyen du à la fourniture du service de contrôle d'accès est au minimum de 65ms et en moyenne de 570ms. Ces perturbations sont inacceptables pour le transport de flux ayant des contraintes temporelles (de la téléphonie par exemple). De plus les débits atteints sont nettement inférieurs au débit théorique (en moyenne 57Mb/s contre 100Mb/s). On peut estimer que l'écart serait encore plus important dans le cas d'une interconnexion ATM à 155Mb/s. Le problème principal des firewalls actuels vient de leur architecture. Ils sont en effet pour le moment limités par la vitesse du bus reliant les cartes réseau au microprocesseur. Celui-ci est pour le moment limité à un débit de 132 Mo/s (Débit crète du bus PCI). Ce débit est bien entendu partagé par les différents périphériques connectés au bus. On peut donc évaluer le débit maximum pouvant être atteint par un firewall construit sur une architecture de PC à 33 Mo/s soit 264 Mb/s (ces flux sont bidirectionnels et le firewall utilise deux cartes réseau). De ce fait, même une augmentation significative des performances des processeurs utilisés dans les firewalls ne permettrait pas de traiter les débits pouvant être supportés par les réseaux ATM (jusqu à 10 Gb/s). Il a été proposé de règler le problème de performance en utilisant une technique appelée load balancing qui consiste à partager la charge de filtrage entre différents firewalls afin d augmenter le débit global pouvant être traité par l architecture de contrôle d accès. Cependant cette technique pose plusieurs problèmes: Le débit crète disponible pour une connexion est limité au débit pouvant être fournit par le firewall le plus puissant. Il a été montré ([Ben99]) que le rapport coût/performance de cette technique est loin d être linéaire. Ainsi si une augmentation par 1.7 des performances peut être réalisée au moyen de 2 firewalls, une augmentation par 3.5 des performances de l architecture de contrôle d accès necessite, elle, l utilisation de 6 firewalls. [Ben99] montre également que ce type d architecture possède une fiabilité qui décroit avec le nombre de firewalls utilisés. L auteur note qu une telle technique n est utilisable qu avec la mise en place d un protocole de détection de fautes et de techniques de reconfiguration Limites dues à la faible prise en compte du réseau ATM Comme nous l'avons montré section 2, les méthodes de contrôle d'accès actuellement utilisées dans les firewalls se placent au niveau transport et au niveau applicatif. Ceci nous amène à la constatation que les informations pouvant être fournies par le modèle ATM (informations d adressage, contrats de trafic,...) ne sont jamais prises en compte afin de rendre le service de contrôle d accès. D autre part les applications natives ATM ne possèdent par actuellement de relais applicatifs permettant d assurer leur protection (ANS, AMS) et de garantir la qualité de service qu elles peuvent demander (AMS). Le même problème se pose pour les utilisations natives (CES, VTOA) Conclusion Elément/Valeur Min. Max. Moy. Délai (ms) 32,5 1147,0 285 Débit (Mb/s) 0,6 84,8 57 L utilisation du firewall dans un environnement ATM pose trois types de problèmes. Le premier est lié aux contraintes architecturales. L utilisation d un firewall limite un architecte de réseau à certains types d environnement et implique une structure particulière dans les solutions pouvant être mises en oeuvre. Le 46

55 Le contrôle d accès dans les réseaux ATM - Le contrôle d accès dans les réseaux ATM second type de problème vient du fait que les mécanismes utilisés dans les firewalls ne sont pas à même de gérer la qualité de service pouvant être fournie par le réseau ATM. Ce problème est amplifié par le fait que les mécanismes de contrôle d accès utilisés sont relativement gourmands en ressources et que les firewalls existants n ont pas des performances compatibles avec les débits offerts par les réseaux ATM. Le dernier point faible vient du fait que les firewalls n utilisent pas les informations fournies par le modèle ATM ou par les applications natives pouvant l utiliser afin de réaliser le contrôle d accès. 4. Le contrôle d accès dans les réseaux ATM Ces problèmes ont été assez rapidement repérés et certaines solutions alternatives permettant de les résoudre en partie ont été proposées. On peut au total recenser cinq propositions. Nous avons classé celles-ci en fonction de leur milieu d origine (instances de spécification, milieu industriel et milieu académique) Le contrôle d accès selon l ATM Forum Le service de contrôle d'accès proposé par l'atm-forum ([SEC10]) est compatible dans son esprit avec celui décrit dans les systèmes sécurisés classés A ou B dans le classement de l'orange book [Obook] où chaque objet du système se voit associer un niveau de sensibilité et où chaque sujet (utilisateur, processus) se voit associer un niveau d'autorisation. Ces deux informations peuvent se décomposer en deux paramètres: Un niveau hiérarchique. Un ensemble de domaines, modélisant les thèmes relatifs à l'élément. L'accès d'un sujet à un objet n'est possible que lorsque le niveau du sujet est supérieur à celui de l'objet et qu au moins un des domaines qui lui est associé inclut les domaines de l'objet. La recommandation de l'atmforum suggère d'utiliser des étiquettes afin de coder ces informations. Le format de ces étiquettes, attachées aux demandes de connexion est conforme à la spécification FIPS 188 ([FIPS188]) proposée par le NIST. Le contrôle d'accès en lui-même est effectué au niveau des équipements du réseau ainsi qu'au niveau des systèmes extrémité qui vérifient au moment de l établissement de connexion, que le niveau de sensibilité des données échangées correspond au niveau d'autorisation des connexions ou des interfaces par lesquelles les données sont échangées. Les niveaux d autorisation sont configurés préalablement par l officier de sécurité. Cette solution possède un certain nombre d inconvénients. D une part, chaque connexion ne peut transporter que des informations ayant un même niveau d autorisation. De ce fait l aggrégation de connexion qui consiste à faire partager par plusieurs applications une connexion ATM ne peut plus être utilisée. Celle-ci est cependant importante dans les environnements CLIP, LANE et MPOA afin de limiter l utilisation de la signalisation qui est particulièrement gourmande en ressources. Un autre problème vient du fait que tous les équipements du réseau doivent être modifiés afin de réaliser les opération de classement des données et les opérations de contrôle d accès à proprement parler. Enfin, il semble difficile de réaliser au moyen de cette technique une traduction de service de contrôle d accès traditionel. En effet aucun mécanisme n est prévu pour s assurer de la conformité des informations transmises avec le niveau de sensibilité pouvant être exprimé à l ouverture de connexion. Ces trois limitations expliquent le fait qu il n existe actuellement pas d équipement implémentant cette partie de la spécification ATM Forum Solutions industrielles Les commutateurs filtrants La solution la plus simple commercialisée en terme de contrôle d accès dans les réseaux ATM est le switch filtrant ([Li99], [Cel99]). Afin de comprendre le fonctionnement des produits proposés il nous faut tout d abord présenter le fonctionnement habituel d un commutateur ATM. Dans un commutateur, les informations de signalisation sont généralement utilisées pour réaliser deux fonctions. La premiere est le routage 47

56 Le contrôle d accès dans les réseaux ATM - Le contrôle d accès dans les réseaux ATM des connexions en fonction des adresses sources et destination, la deuxième étant la réservation de ressources selon les informations du contrat de trafic. Dans le cas des produits proposés, une troisième fonction est implémentée permettant de filtrer les demandes de connexion en fonction des adresses ATM source et destination. La politique de contrôle d accès est alors exprimée par la liste des couples d adresses pouvant communiquer. Cette solution, simple n offre cependant pas un niveau de contrôle d accès très important du fait qu un seul paramètre peut être utilisé pour filtrer les demandes de connexions et que le contenu échanges dans les connexions ne peut pas être filtré Firewall ATM Le produit ATLAS de StorageTek Network Systems ([Ko97]) est le seul produit commercial proposant de réaliser le contrôle d'accès au niveau transport. La solution proposée par StorageTek se base sur deux innovations : le filtrage au niveau cellule et l utilisation d un cache pour la politique de contrôle d accès. Le contrôle d'accès ne fonctionne pas de la même façon que dans les firewalls classiques. ATLAS n'effectue pas de réassemblage de trames pour reconstituer les paquets IP. Les cellules sont analysées au niveau ATM ce qui n introduit pas de délai dans leur transfert. Cependant l analyse est limitée à la première cellule de chaque trame AAL5 échangée sur la connexion. Les informations contrôlables sont indiquées en grisé figure 19 dans le cas du protocole CLIP décrit en section 2.2. P indique le protocole, D les drapeaux TCP et TD et UD le début des segments de données TCP et UDP. Comme on peut le voir les informations généralement utilisées afin de fournir un service de contrôle d accès dans les réseaux TCP/IP peuvent être trouvées dans la première cellule ATM. Cependant ce mécanisme possède tout de même un défaut. En effet lorsque des options sont utilisées dans le paquet IP, celles-ci peuvent repousser les informations des paquets TCP ou UDP dans la seconde cellule de la trame AAL5. ATLAS ne peut dans ce cas utiliser que les informations de niveau réseau. C est également le cas lors de l utilisation du protocole IPv6 puisque la taille des adresses peut engendrer le même phénomène. Figure 19. Informations accessibles. Octet CLIP En-tête ATM AA AA Octet CLIP XX 45 Longueur P Octet CLIP Adr IP Src Adr IP Dst Port Src Port Octet CLIP Dst UD D Octet CLIP La deuxième innovation a pour but d'accélérer la recherche sur les paramètres à filtrer. Pour cela le firewall utilise une mémoire cache de type CAM (Content Addressable Memory) qui, comme nous l avons dit en section du chapitre 2, permet de faire des recherches par contenu. Ce type de mémoire permet en fonction du contenu d une cellule de trouver la règle devant être appliquée. Cependant comme la taille de cette mémoire est faible, le contenu de la mémoire doit être géré de manière dynamique. La technique utilisée pour cela est décrite en figure20. 48

57 Le contrôle d accès dans les réseaux ATM - Le contrôle d accès dans les réseaux ATM Figure 20. Shéma de fonctionnement du firewall ATM ATLAS. Dropped Cells Receive Interface Control Processor New Cells New Policies Policy Cache Forwarded Cells Transmit Interface Lorsque des cellules ne correspondant à aucune règle connue atteignent le policy cache, celui-ci les envoie au control processor qui lui renvoie la règle à appliquer si celle-ci existe. Cette règle sera insérée dans le cache et réutilisée par la suite pour les cellules devant être analysées. La première cellule est analysée par le control processor en fonction de la politique et envoyée à l interface de sortie lorsque la communication est autorisée. Lorsque la communication est interdite ou que la règle n existe pas la cellule est rejetée. Cette solution possède un certain nombre de limitations. La première que nous avons déja mentionnée est de limiter l analyse à la première cellule ATM de chaque trame AAL5. Un autre problème vient du fait que les connexions doivent être configurées manuellement. En effet les informations de signalisation ne sont pas utilisées pour associer les règles de contrôle d accès de niveau transport aux connexions ATM ouvertes. Ceci rend l'utilisation de l'équipement dans un environnement à connexions dynamiques relativement difficile. D autre part le filtrage se fait uniquement au niveau transport. Les informations provenant du flux ATM et des couches supérieures (application) ne sont pas utilisées. Il faut également noter que l architecture proposée comme toute les architectures basées sur l utilisation de caches est sensible au dénis de service. En effet comme nous l avons expliqué dans le chapitre 2, un attaquant peut générer un traffic mettant en défaut le cache de manière systématique et diminuant de ce fait les performances de l architecture de contrôle d accès à celles du classificateur logiciel de cellules. Enfin, ce produit fonctionne seulement à 45 Mb/s et 155Mb/s Solutions académiques Solution basée sur un circuit d analyse de cellule ATM [Mc97] propose une architecture basée sur un équipement centralisé. Celle-ci prévoit quatre types de services. Le premier est la vérification de l'identité des participants au moyen des informations contenues dans la signalisation (adresses source et destination). Le second est l analyse des informations de routage PNNI (Private Network to Network Interface). La cohérence des routes transportées est examinée afin de déceler des tentatives de détournement de connexion ou d usurpation d'identités. Cette architecture fournit également une authentification compatible avec celle préconisée par l ATM-Forum ([SEC10]) dans laquelle les deux équipements sont authentifiés de manière indépendante en introduisant un élément d information assurant l authentification dans les messages de signalisation. Il est de ce fait possible d utiliser deux méthodes d authentification différentes de part et d autre de l équipement. Une authentification «légère» est utilisée pour les équipements internes alors qu une authentification «forte» est utilisée pour les équipements externes. Cette authentification se fait dans le flux de données après l'ouverture de connexion. Pour finir il propose un service de filtrage aux niveaux transport en utilisant comme dans le cas de la solution Storagetek le contenu de la première cellule échangée sur la connexion ATM. Cependant dans la pratique, seule la partie concernant l implémentation de la vérification de l identité des participants est décrite. La figure 21 décrit la structure du firewall. Celui-ci est composé de deux parties: Le FIP (Firewall Inline Processor) applique le contrôle d'accès en bloquant ou en laissant passer les cellules relatives à une connexion. Il effectue également la redirection du flux de signalisation vers le FCP (Firewall Control Processor). La communication entre le FIP et le FCP se fait au moyen de trois con- 49

58 Le contrôle d accès dans les réseaux ATM - Le contrôle d accès dans les réseaux ATM nexions ATM permanentes. La première appelée IPVC (Incoming PVC) assure la transmission des cellules de signalisation provenant du port interne du FIP vers le FCP. La seconde appelée OPVC (Outgoing PVC) assure le même rôle mais vis à vis du port externe du FIP. La dernière appelée CPVC assure la configuration du FIP une fois l analyse de la signalisation effectuée. Le FCP utilise les informations d adressage (adresses source et destination) extraites des messages de signalisation échangés entre les réseaux internes et externes par le FIP afin de décider du contrôle d'accès. Une fois cette décision prise, il la transmet au FIP qui l'applique. Figure 21. Structure du firewall. Réseau externe Firewall Inline Processor Réseau interne OPVC CPVC IPVC Firewall Control Processor De manière physique le FIP est réalisé au moyen d'un commutateur ATM auquel est associé un circuit spécialisé FPGA. Le FCP est un ordinateur de type PC relié au FIP au moyen de connexions ATM permanentes. Ce projet présente un certain nombre d idées intéressantes. Cependant peu d informations sont données sur la méthode d implémentation qui pourrait être utilisée pour mettre en oeuvre ces idées. Seule l analyse de la signalisation est partiellement traitée. En particulier aucun détail n est founi sur le fonctionnement du FCP. De plus peu d informations sont disponibles sur son implémentation. Il est donc difficile de critiquer cette solution. On peut cependant noter que le prototype implémenté ne réalise du contrôle d accès que sur les identificateurs de connexion (VPI/VCI) et non sur le contenu des paquets IP. D autre part, le filtrage des connexions n utilise que les adresses ATM. Enfin comme pour la solution storagetek, cette proposition du fait de son utilisation de mécanismes de cache est sensible aux dénis de service Solution basée sur le classement des trafics [Xu98c] ([Xu99a]) propose une architecture centralisée de contrôle d accès se basant sur un seul équipement. Les auteurs préconisent dans [Xu98a] de placer l équipement entre le réseau ATM interne et le réseau public ATM. Dans [Xu98b] et [Xu99c] ils proposent de placer l équipement à l intérieur du réseau et de diriger les connexions ATM vers celui-ci. Pour cela, ils se servent des possibilités fournies par la signalisation ATM à l interface PNNI de spécifier les équipements devant être traversés par une demande d ouverture de connexion. Une partie des fonctionnalités de l'équipement est basée sur la solution proposée par StorageTek. L apport principal de cette proposition est de classer le trafic suivant les opérations de sécurité nécessaires. Quatre classes de contrôle sont définies par les auteurs: 50

59 Le contrôle d accès dans les réseaux ATM - Le contrôle d accès dans les réseaux ATM Classe A: Contrôle d'accès de base. Contrôle sur les informations contenues dans la signalisation (adresses). Ce contrôle est effectué quelque soit le type de trafic (avec ou sans requète de QoS). Si nécessaire, Le contrôleur génère automatiquement des règles de filtrage au niveau des adresses et services IP au moyen d'une correspondance statique entre les adresses IP et ATM. Ces règles de filtrage seront utilisées par les mécanismes traitant les classes B et C. Classe B: Traffic monitoring. L'analyse est faite sur une copie du flux à la manière de l analyseur de sécurité présenté en section du chapitre 2. Cette analyse non bloquante assure le respect de la qualité de service pouvant être négociée. Si le paquet n'est pas autorisé, la réponse est bloquée. L'action de contrôle d'accès se fait donc sur la réponse. Classe C: Packet Filtering. Il consiste à réassembler les en-têtes IP à partir du flux. Durant cette analyse la dernière cellule du paquet, appelée LCH (Last Cell Hostage) est conservée. Normalement l'analyse de l'en-tête IP doit prendre moins de temps que le passage du paquet sur la ligne. Si le paquet est autorisé, la dernière cellule est relachée, sinon elle est remplie avec un code aléatoire pour provoquer une erreur de CRC et un rejet du paquet en extrémité. Les auteurs ne précisent cependant pas comment repèrer cette dernière cellule. Classe D: Proxying. Contrôle d'accès classique par une passerelle applicative ou proxy tel qu il est réalisé dans un firewall classique. Tableau 6. Utilisation des classes de contrôle. Niveau/Application Avec contraintes de QoS Sans contraintes de QoS Application Pas de contrôle d accès Classe D Transport Classe B Classe C ATM Classe A Classe A Ce classement permet selon les auteurs d'isoler le trafic ayant des contraintes en terme de qualité de service du trafic n'en ayant pas afin de ne pas ralentir le premier. La relation entre classes et trafics est décrite dans le tableau 6. Figure 22. Composants physiques du firewall. Réseau sûr Réseau non sûr Firewall Proxy Management Server Station Traffic Monitoring Server L architecture physique de la proposition se base sur celle d un commutateur classique dans lequel la fonction de contrôle d admission des connexions CAC (Connection Admission Control) a été modifiée afin de prendre en compte les règles de sécurité dans le filtrage des appels. Au niveau cellule, un calcul pour réassembler les cellules constituant l'en-tête IP du paquet est réalisé en plus de la fonction de traduction d'en-tête. Ce calcul peut être fait de manière expresse (par un circuit spécialisé comparable à celui utilisé chez StorageTek) lorsque le format du paquet est régulier ou de manière plus 51

60 Le contrôle d accès dans les réseaux ATM - Le contrôle d accès dans les réseaux ATM lente (de manière logicielle) lorsque le format contient des particularités comme par exemple des options. Le reste des opérations est réalisé par des équipements externes connectés directement au switch (Traffic monitoring server, Proxy server, Firewall management station), les flux destinés à ces équipements sont soit des flux recopiés (monitoring server) soit relayés (proxy server). Dans ce dernier cas, deux connexions sont construites (source-serveur proxy),(serveur proxy-destination). La figure 22 montre les composants physiques du firewall. La figure 23 montre les opérations internes. Figure 23. Gestion des cellules dans le firewall ATM. CAC OAM Express & Advanced TCP/IP Check Cells Signaling Cells Filter OAM Cells Filter Enhanced Header Translation User Cells Enhanced VP/VC Database Une forme simplifiée de cette architecture est évaluée dans [Xu99b] où les auteurs annoncent un débit de 2,8 Gb/s mais celle-ci n a pas été implémentée. Le débit fourni par cette évaluation est cependant un débit moyen se basant sur le filtrage de paquets de taille égale à la moyenne des tailles des paquets IP pouvant être trouvés sur une connexion. Le débit minimal pouvant être atteint est obtenu lors du filtrage de paquets IP correspondant à deux cellules est de l ordre de 40Mb/s. Cette solution apporte trois innovations (LCH, Monitoring réactif, classement des trafics) mais possède un certain nombre d'inconvénients: Elle suppose que les trafics possédant des contraintes temps réel ne nécessitent pas de proxy. En effet rien ne distingue le traitement par proxy dans cette solution de celui effectué dans un firewall «classique». Ceci implique que les altérations de la qualité de service décrites en section 3.1 se produiront sur ces flux s'ils sont traités par un proxy. Ceci limite le contrôle d'accès sur les applications utilisant ce type de trafic. La procédure de traffic monitoring ne traite pas les flux demandant de la qualité de service qui fonctionnent en mode non connecté (UDP). En effet il n'est pas possible d'établir un lien entre requête et réponse dans ce cas. Elle utilise comme la proposition storagetek une architecture à base de cache. Elle est de ce fait sensible aux dénis de service. Elle n assure pas de protection contre la fuite d informations. En effet un utilisateur mal intentionné du réseau interne peut se mettre d accord avec un utilisateur externe pour désactiver le contrôle d intégrité des trames AAL5 et de ce fait déjouer le mécanisme de contrôle d accès. Elle est complexe à mettre en oeuvre. 5. Conclusion Dans ce chapitre nous décrivons les problèmes posés par l utilisation d un firewall dans le cas d un réseau ATM et présentons les architectures proposées pour les résoudre. Les problèmes posés par l utilisation d un firewall peuvent se classer dans trois grandes catégories: 52

61 Le contrôle d accès dans les réseaux ATM - Le contrôle d accès dans les réseaux ATM Limitations vis à vis de l architecture du réseau et limitations vis à vis des utilisations possibles du réseau. Problèmes de garantie de la qualité de service qui peut être fournie par le réseau ATM et problèmes de performances afin de soutenir les débits pouvant être fournis par ces réseaux. Limitations vis à vis de la qualité du contrôle d accès pouvant être réalisé du fait du nombre restreint de paramètres pouvant être pris en compte au niveau ATM et au niveau applicatif. Le tableau 7 présente une comparaison entre les différentes propositions en terme de contrôle d accès ATM. On peut relever plusieurs problèmes récurrents. Le premier est la faiblesse voire l absence de paramètres de contrôle d accès de niveau ATM. Nous nous intéressons à ce problème dans le chapitre suivant. Le second problème vient des faibles performances fournies par les solutions actuellement implémentées. Celles-ci sont en effet limitées à 155 Mb/s et cela alors que des couches physiques supportant des débits de 622 Mb/s à 2.4 Gb/s sont spécifiées et utilisées et qu une couche permettant un débit de 10 Gb/s est actuellement en cours de spécification. Enfin une grande partie des solutions actuelles se basent sur une architecture à base de cache afin d améliorer leur performances. Ce type d architecture est sensible au dénis de service. Il convient de ce fait de développer une architecture qui puisse assurer des performances compatibles avec les supports physiques actuels sans être sensibles à ce type d attaques. Nous présentons chapitre 5 et chapitre 6 nos propositions afin de résoudre ces problèmes. Tableau 7. Comparaison des différentes propositions en terme de contrôle d accès ATM. Propriété/Solution Firewall ATM Forum Switch Filtrants Firewall ATM [Mc97] [Xu98a] Contrôle d accès Non Non Faible Non Faible Faible ATM Contrôle d accès Bon Non Non Moyen Faible Moyen Transport Contrôle d accès Moyen Non Non Non Non Moyen Applicatif Contrôle d accès par Non Oui Non Non Non Non étiquette Modification du Fort Non Non Faible Faible Faible CTD Modification du CLR Oui Non Non Oui Oui Oui Modification du Fort Non Non Faible Faible Faible CDV Modification du Fort Non Non Faible Faible Faible PCR, MCR, SCR Débit crète 180 Mb/s / 622 Mb/s 155 Mb/s 155 Mb/s 2.8 Gb/s Implémentation Oui Non Oui Oui Oui Non 53

62 Le contrôle d accès dans les réseaux ATM - Le contrôle d accès dans les réseaux ATM 54

63 CHAPITRE 4 Paramètres de contrôle d accès Dans ce chapitre nous examinons les informations transportées sur les réseaux ATM afin d en extraire celles pouvant être utilisées dans le cas du contrôle d accès. 1. Introduction Comme nous l avons souligné dans le chapitre précédent, les propositions actuelles en terme de contrôle d accès pour les réseaux ATM se contentent au mieux de contrôler les informations d adressage présentes dans la signalisation. Dans ce chapitre, nous faisons une analyse des informations circulant dans les réseaux ATM afin d en extraire les éléments importants en terme de contrôle d accès. Pour cela, notre analyse se décompose en plusieurs étapes. Nous analysons en section 2 de manière systématique les informations générées par le modèle ATM couche par couche et plan par plan. Afin d évaluer l importance de ces informations nous essayons d une part d utiliser les similarités entre les réseaux ATM et les réseaux pour lesquels existent déjà des architectures de contrôle d accès (en particulier les réseaux TCP/IP). Nous essayons d autre part d imaginer les utilisations possibles en terme de contrôle d accès de paramètres ne pouvant être rattachés à des paramètres existant dans les réseaux TCP/IP. Ces deux analyses nous permettent de définir un ensemble de paramètres utiles au contrôle d accès. L utilité d un paramètre de contrôle d accès ne peut se résumer à son applicabilité. En effet il est facile de constater que celle-ci n a de valeur que rattachée à une utilisation réelle. Il est donc nécessaire pour déterminer l utilité d un paramètre de contrôle d accès de chercher à quelle utilisation réelle il peut être affecté. L ampleur du déploiement de l utilisation peut ensuite donner une idée de sa valeur. De ce fait nous analysons dans la section 3 les utilisations normalisées des réseaux ATM, quelle que soit la provenance de ces normes afin d en extraire les paramètres utilisés. Cette analyse nous permet de vérifier quels paramètres peuvent être utilisés dans la pratique et d autre part de déterminer quels paramètres caractérisent une utilisation. Dans la constitution d un outil de contrôle d accès il est souvent nécessaire de faire un choix entre les paramètres de contrôle d accès pouvant être implémentés en fonction de leur utilité. La section 4 s attache à faire une synthèse et un classement des informations fournies par les sections 2 et 3 afin de fournir des profils de contrôle d accès directement implémentables par des outils de contrôle d accès. Ces profils permettent de déterminer la qualité du contrôle d accès de niveau ATM pouvant être réalisé, de manière indépendante des mécanismes utilisés pour fournir le service de contrôle d accès. Pour finir la section 5 conclut ce chapitre en résumant son apport. 55

64 Le contrôle d accès dans les réseaux ATM - Paramètres de contrôle d accès 2. Recherche des paramètres de contrôle d accès de niveau ATM Dans cette partie, nous analysons les informations fournies par le modèle ATM afin d en extraire celles pouvant avoir une utilité pour rendre le service de contrôle d accès. Afin de limiter la longueur de l analyse nous présenterons uniquement les informations ayant une utilité. Le lecteur intéressé par une analyse complète pourra se reporter à [Pa97] Au niveau cellule Partie contrôle Les informations fournies dans cette partie sont tirées des spécifications de l'atm-forum UNI 3.1 [UNI3.1]. Les PDUs utilisés au niveau ATM, appelés cellules, sont d'une longueur de 53 octets. Il peuvent être décomposés en deux parties : Une partie contrôle de 5 octets qui contient des informations assurant le transfert de la cellule. Elle permet également de savoir à quel type de flux la cellule ATM appartient (Gestion/Données utilisateur/contrôle). Une partie données de 48 octets contenant les données provenant de la couche AAL. La figure 24 décrit la partie contrôle: Figure 24. En-tête de cellule ATM à l interface UNI. GFC VPI VCI PT C L P HEC Bits Note: GFC: Generic Flow Control. (Contrôle de flux générique) VPI: Virtual Path Indicator. (Indicateur de conduit virtuel) VCI: Virtual Channel Indicator. (Indicateur de canal virtuel) PT: Payload Type. (Type de charge) CLP: Cell Loss Priority. (Priorité de perte) HEC: Header Error Control. (Champ de contrôle d'en-tête) Information concernant le type de flux Le type de flux est indiqué au moyen d'une combinaison des bits de l'en-tête. Le tableau suivant indique les différents types de flux et les champs utilisés pour les coder : Tableau 8. Codage des différents types de flux. Type/Champ VPI VCI PT Clp Meta-Signaling yyyyyyyy a0 c Broadcast signaling yyyyyyyy aa c 56

65 Le contrôle d accès dans les réseaux ATM - Paramètres de contrôle d accès Notes: yyyyyyyy indique une valeur différente de 0. a indique une valeur quelconque. c indique une valeur qui peut être changée par le réseau. L information fournie par le codage des différents types de flux permet de contrôler l utilisation de ceuxci. Ce contrôle peut se révéler utile dans certains cas: Vis à vis des flux de signalisation (Meta-signaling, Broadcast signaling, Point to point signaling) il peut être intéressant de bloquer l établissement de connexions à certains moments (par exemple en dehors de périodes d activité de l entreprise). Vis à vis des flux de gestion (cellules OAM), il a été montré ([Fau99]) qu il était possible de saturer des équipements d interconnexion en utilisant des cellules de gestion. Ces attaques tirent parti de l implémentation logicielle des fonctions de gestion afin de saturer le processeur central de l équipement. Cette saturation provoque la mise hors service de l équipement pendant la durée de l attaque. Le blocage de ces cellules, lorsqu elles ne supportent pas des fonctions indispensables permet d éviter ce type d attaques. Vis à vis des flux de routage PNNI, il a été montré ([Ben98]) qu il était possible d utiliser ces flux afin d introduire des informations de routage erronées dans le réseau et de cette manière détourner des connexions. Le blocage de ce type de flux au niveau cellule permet de limiter ce risque lorsque l utilisation de PNNI n est pas indispensable. Utilisation des champs VPI/VCI Ces deux champs permettent d'identifier une connexion. Il est possible d utiliser cette information en association avec des informations administratives dans le cas de connexions permanentes ou d informations provenant de la signalisation dans le cas de connexions dynamiques afin de déterminer l utilisation de la connexion associée à ces identificateurs. En fonction de cette connaissance, il est ensuite possible de limiter les connexions à certaines périodes temporelles Partie données Type/Champ VPI VCI PT Clp Point to point signaling yyyyyyyy aa c OAM F4 Segment Flow aaaaaaaa a0 a OAM F4 End to End Flow aaaaaaaa a0 a PNNI RCC aaaaaaaa aaa a ILMI aaa 0 OAM F5 Segment Flow aaaaaaaa aaaaaaaaaaaaaaaa 100 a OAM F5 End to End Flow aaaaaaaa aaaaaaaaaaaaaaaa 101 a FRM Cell aaaaaaaa aaaaaaaaaaaaaaaa 110 a User Cell aaaaaaaa aaaaaaaaaaaaaaaa 00a a User Cell (Congestion) aaaaaaaa aaaaaaaaaaaaaaaa 01a a Unassigned Cell aaa 0 Invalid Cell aaa Plans utilisateur et contrôle Les normes ne spécifient a priori aucune structure pour les données utilisateurs et la signalisation au niveau ATM. On ne peut donc obtenir aucune information permettant de faire du contrôle d accès à ce niveau. 57

66 Le contrôle d accès dans les réseaux ATM - Paramètres de contrôle d accès Plan de gestion Au niveau ATM, les cellules de gestion sont de plusieurs types: flux F4, F5 et ILMI. Flux F4 et F5 Les cellules OAM F4 et F5 contiennent les 5 champs suivants, OAM type (4 bits), function type (4 bits), function specific (45 octets), reserved field (6 bits) et EDC (CRC-10) (10 bits). Le tableau 9 indique comment ces champs servent à coder les différents types de cellules OAM. Tableau 9. Lien entre syntaxe et sémantique des cellules de gestion. Type de cellule/champs OAM Type Function Type Fault management 0001 AIS 0000 RDI 0001 Continuity check 0100 Loopback 1000 Performance management 0010 Forward Monitoring 0000 Backward Monitoring 0001 Monitoring/Reporting 0010 Activation/Deactivation 1000 Performance monitoring 0000 Continuity check 0001 System Management 1111 Security Real Time 0001 Security Non-Real Time 0010 Le type de cellule OAM permet d'affiner le contrôle d accès présenté en section en décidant quelle fonction de gestion doit être autorisée ou interdite Au niveau trame La couche AAL est une couche qui permet l'adaptation du trafic ATM à d'éventuelles applications. Pour cela plusieurs types d'aal ont été définis. Chaque type d'aal correspond à un type d'application particulier et intègre donc des mécanismes propres. Ceci se traduit sur les AAL-PDUs par une structure qui varie suivant le type d'aal auquel ils sont destinés. Cependant les informations indiquant qu'un AAL-PDU est destiné à un type d'aal plutôt qu'à un autre se trouvent dans les informations de signalisation. Utilisation de la structure des AAL-PDUs Lorsque la signalisation n'est pas utilisée afin d'établir des connexions (c'est-à-dire lorsque des connexions permanentes sont utilisées) il peut être intéressant d'utiliser la structure des AAL-PDUs échangés afin de déduire le type d'aal utilisé. Celui-ci peut être utilisé pour contrôler l accès à des applications utilisant une AAL spécifique ou à des équipements équipés d AAL particulières. 58

67 Le contrôle d accès dans les réseaux ATM - Paramètres de contrôle d accès 2.3. Au niveau signalisation La signalisation est située dans le plan de contrôle du modèle ATM et en partie au dessus de celui-ci (dans la couche application). Au niveau ATM la signalisation est repérée par un en-tête particulier (cf. section 2.1). La couche AAL relative à la signalisation peut être subdivisée en 4 sous-couches. Les deux sous-couches inférieures (SAR et CPCS) sont les mêmes que celles de l'aal5. La troisième sous-couche utilise un protocole appelé SSCOP afin d'assurer un service de transport sans perte. La dernière couche appelée SSCF fournit une interface aux applications utilisatrices du protocole. L'entité responsable de la génération des messages de signalisation, appelée entité Q2931 utilise les primitives de services fournies par la couche SSCF afin d'assurer l'établissement, le contrôle et la libération des connexions. La figure 25 résume ces informations: Figure 25. Le plan de contrôle. Entité Q2931 Sous couche AAL/SSCF Sous couche AAL/SSCOP Sous couche AAL/CPCS Sous couche AAL/SAR Modèle ATM Plan de contrôle Couche ATM Couche Physique Les opérations réalisées grâce à la signalisation se font au moyen de messages échangés entre les entités Q2931. Ces messages sont structurés en groupes de données concernant un même sujet appelés éléments d'information (IE - Information Elements). La structure des messages et éléments d information est décrite par les spécifications UNI ([UNI3.1], [UNI4.0]) de l ATM Forum et par les normes ([Q2931], [Q2931add], [Q2932], [Q2933], [Q2951], [Q2959], [Q2961], [Q2962], [Q2963], [Q2971]) de l ITU-T. Dans la suite de cette section nous analysons ces IEs afin d'en extraire l'information pouvant être utile afin de rendre le service de contrôle d'accès. Ces IEs peuvent être situés dans plusieurs messages de signalisation différents. De ce fait nous donnons en annexe de ce document, section 1.3, les relations entre messages de signalisation et éléments d information. Afin de faciliter la compréhension des abbréviations utilisées dans ce chapitre, le lecteur pourra se reporter aux sections 1.1 et 1.2 de l annexe présentant respectivement les abbréviations utilisées pour les messages de signalisation et les IEs. Utilisation des informations d'adressage Les IEs suivants contiennent des informations sur l'identité de l'appelant et de l'appelé: CPN, cpn, CPSA, cpsa ([Q2931]): Adresses (CPN, cpn, octets 6-) et sous-adresses (CPSA, cpsa, octets 6-) de l'appelant et de l'appelé ainsi que les plans d adressage (CPN, cpn,octet 5 et CPSA, cpsa octet 5) utilisés ([AUG10]). CN, CSA ([Q2951]): Adresse (CN, octets 6-), sous-adresse (CSA, octets 6-) de l'appelé et plan d adressage (CN, octet 5 et CSA, octet 5). 59

68 Le contrôle d accès dans les réseaux ATM - Paramètres de contrôle d accès D une manière analogue aux réseaux TCP/IP, les adresses et sous adresses de l'appelant et de l'appelé des réseaux ATM sont des éléments importants en matière de contrôle d accès: Un contrôle d accès basé sur ces paramètres permet d'autoriser ou d'empêcher les communications entre les équipements désirés en filtrant l établissement des demandes de connexion. Un contrôle d accès utilisant ces informations peut être utilisé afin d empêcher les attaques basées sur l usurpation d adresse (address spoofing) pour les connexions entrantes et sortantes en vérifiant d une part que les connexions provenant de l extérieur n ont pas pour origine des équipements utilisant des adresses internes et d autre part en vérifiant que les connexions provenant de l intérieur n ont pas pour origine des équipements utilisant des adresses externes. Si des services tels que le transfert d'appel sont utilisés par l'appelé, on peut utiliser les informations fournies par les IEs CN et CSA qui fournissent l adresse et la sous-adresse correctes de l appelé. LIJCI ([UNI4.0]): Identificateur de connexion point à multipoint (LIJCI, octets 6-9). Cet identificateur, combiné aux informations d adressage contenues dans les IEs CPN, CPSA, permet d identifier un groupe dont la racine est le récepteur du message. Il doit donc être utilisé en association avec les informations contenues dans les IEs CPN et CPSA pour contrôler l accès à un groupe lorsque la procédure de connexion multipoint initiée par les feuilles est supportée (LIJC - Leaf Initiated Join Capability). CSS ([UNI4.0]): Connection Scope Selection (CSS, octet 6). Les adresses anycast (Anycast addresses) peuvent être définies à plusieurs niveaux (local/site/organisation...) de l organisation logique d un réseau (ces niveaux correspondent à ceux pouvant être définis dans PNNI pour la création de la hiérarchie de routage). Une même adresse anycast peut donc désigner plusieurs équipements au sein d un même réseau, chacun d entre eux se situant dans un niveau logique différent. Il est donc important de considérer l'ie CSS lors d'un contrôle d accès sur des adresses anycast afin de déterminer à quel équipement une adresse de ce type se réfère. ER ([Q2971]): Identificateur d'extrémité (ER, octets 6-). Cet identificateur identifie de manière univoque une entité extrémité dans le cadre d une connexion point à multipoint. Son utilité en terme de contrôle d accès se limite au cas d une application stricte de Q2971 (et non de l UNI 4.0). En effet dans ce cas, la spécification de l adresse de destination à l interface UNI est optionnelle. L IE ER étant obligatoire dans tous les messages point à multipoint, il peut alors être utilisé en l absence des IEs CPN et CPSA afin de contrôler l accès à l entité extrémité. Utilisation des informations sur les piles protocolaires utilisées D'autres IEs permettent d'obtenir des informations sur la façon dont ATM est utilisé et sur les couches ou applications qui lui sont adjacentes: BLLI,NLLC ([Q2931]), NBC ([Q2931], [Q931]): Identificateurs de protocoles de couches 1 (BLLI octet 5, NBC octet 5), 2 (BLLI octet 6, NBC octet 6) et 3 (BLLI octet 7, NBC octet 7). Ces informations décrivent le protocole utilisé au dessus du modèle ATM lorsque le réseau ATM est utilisé afin de transporter des protocoles de niveau 1, 2 ou 3 suivant la spécification de l OSI. De ce fait, ces informations peuvent être utilisées pour empêcher l accès depuis ou à un certain type de réseau. Les IEs NLLC et NBC se distinguent de l IE BLLI par le fait qu ils sont destinés à être utilisés lorsque le réseau ATM RNIS-LB est utilisé pour émuler un RNIS-BE. BHLI,NHLC ([Q2931]): Identificateur de protocole de niveau supérieur (BHLI octet 6-13). 60

69 Le contrôle d accès dans les réseaux ATM - Paramètres de contrôle d accès Cette information identifie la couche de niveau supérieur utilisée au dessus du modèle ATM. Dans le cadre des spécifications de l ATM-Forum, cette information désigne le protocole de niveau applicatif utilisé au dessus du modèle ([ANS10], [VOD10]). Elle peut donc être utilisée pour effectuer un contrôle d accès aux applications spécifiées. Cependant le nombre de ces applications est pour le moment réduit. Utilisation d'informations physiques Certains IEs permettent de dériver des informations sur leur auteur: TNS ([Q2931]): Liste des réseaux de transit (TNS octet 6-). Grâce à la liste des réseaux par lesquels la demande de connexion est passée, on peut détecter certaines incohérences entre l'identité de l'appelant et les réseaux traversés. Cependant cette information est optionnelle. Utilisation d'informations caractérisant le trafic Certains IEs permettent d'obtenir des indications sur les services utilisés au moyen des informations décrivant le trafic échangé: AALP ([Q2931]): type d AAL (AALP octet 5). On pourrait penser qu il est intéressant d utiliser le type d'aal pour contrôler l accès à des applications utilisant une AAL spécifique ou à des équipements équipés d AAL particulières. Elle suppose donc de faire le lien soit entre les identificateurs d AAL et des applications, soit entre les identificateurs d AAL et des équipements. La première hypothèse n est pas évidente à mettre en oeuvre car le lien entre application et AAL, bien qu existant implicitement n est pas obligatoire. Dans le deuxième cas on peut constater que la plupart des cartes ATM sur le marché ne proposent aujourd hui que deux types d AAL (AAL1 et AAL5 ou AAL5 uniquement) il est donc difficile de différencier un groupe de machines au moyen de cette information étant donné que la plupart des machine possède au moins une fonction d adaptation AAL5 destinée au traitement de la signalisation. AALP ([Q2931]), ATD ([Q2961], [UNI40]), AATD ([Q2962]), MATD ([Q2962]), ASP ([UNI40]), EQoSP ([UNI40]), AAP ([UNI40]): débit CBR pour AAL1 (AALP octets 7-8). Débit crête ou PCR (ATD, AATD, MATD octets 5,6,7,8), débit soutenu ou SCR (ATD, AATD, MATD octets 9,10,11,12), taille maximale des rafales ou MBS (ATD, AATD, MATD octets 13,14,15,16), débit minimum ABR (ATD octets 19,20), indicateur de best effort (ATD, octet 18), ATD débit initial ABR (ASP, octets 5,6). Variation de délai acceptable ou CDV (EQoSP, octets 6,7,8,9), taux de perte acceptable ou CLR (EQoSP, octets 10,11). LLCP, LLPP ([Q2933], [Q933]): Eléments de description de trafic mais dans le cadre d'une émulation du relai de trame. Lorsque des paramètres de description du contrat de trafic ou de définition de la qualité de service sont exprimés par la signalisation, il est intéressant d utiliser ceux-ci afin de limiter les ressources utilisées dans les équipements d interconnexion par les connexions pouvant être établies. Cette limitation peut se justifier pour deux raisons. D une part il a été montré ([Ben98], [Pa98b]) qu il était possible de réaliser des dénis de service en faisant des demandes de connexion avec des paramètres de qualité de service provoquant des réservations de ressources importantes au niveau des équipements d interconnexion. Ces réservations peuvent empêcher l établissement de nouvelles connexions et perturber les connexions déjà existantes. Ceci peut s expliquer par le fait que, comme nous l avons expliqué au chapitre 3, section 3.1.1, la garantie de qualité de service fournie par le réseau ATM se base sur la réservation de ressources dans les équipements du réseau en fonction des paramètres exprimés dans le contrat de trafic. 61

70 Le contrôle d accès dans les réseaux ATM - Paramètres de contrôle d accès D autre part il peut être intéressant d utiliser cette information en association avec d autres informations (adresses source et destination, application ou service utilisé, informations temporelles) afin de hiérarchiser les capacités de réservations de ressources des utilisateurs du réseau. Utilisation de l information de priorité d appel pi ([Q2959]): priorité de l appel (pi octet 5). La signalisation permet d associer une priorité à une demande de connexion. Celle-ci est utilisée afin de privilégier certaines demandes de connexion dans le cas où les ressources d un élément du réseau ne sont pas suffisantes pour permettre le traitement de toutes les demandes de connexion. L élément du réseau est alors autorisé à interrompre les connexions possédant un niveau de priorité plus faible afin de satisfaire les connexions ayant un niveau de priorité plus élevé. Nous avons montré dans ([Pa98b]) comment un attaquant pouvait utiliser cette possibilité pour réaliser des dénis de service sur les demandes de connexion en cours comme sur les connexions déjà établies en provoquant la rupture ou le rejet de celles-ci Conclusion Le tableau 10 fournit un résumé de cette section en donnant pour chaque paramètre les possibilités d utilisation en terme de sécurité. Nous avons séparé les fonctions de sécurité en cinq grandes classes. A coté des classes bien connues (détection d usurpation d identité, détection de dénis de service, contrôle d accès aux équipements et contrôle d accès aux services) nous définissons une nouvelle classe appelée contrôle d accès au réseau correspondant à la capacité du réseau ATM de garantir une qualité de service aux applications en faisant la demande. Il s agit dans ce cas de contrôler l accès aux ressources du réseau en fonction d une politique prédéfinie. Tableau 10. Classement des paramètres par classe d application. Détection de dénis de service Contrôle d accès aux équipts Contrôle d accès aux services Contrôle d accès au réseau Détection d usurp. Paramètre de contrôle d accès/utilisation d identité Adresse connectée X X Adresse de l appelant X X Adresse de l appelé X X ATD débit initial ABR X X Connection scope selection X Débit CBR pour AAL1 X X Débit crète ou PCR X X Débit minimum ABR X X Débit soutenu ou SCR X X Fonction OAM X Identificateur d'extrémité X X Identificateur de connexion point à multipoint X X Identificateur de protocoles de couche 1 X Identificateur de protocoles de couche 1 X Identificateur de protocoles de couche 2 X Identificateur de protocoles de couche 2 X 62

71 Le contrôle d accès dans les réseaux ATM - Paramètres de contrôle d accès Paramètre de contrôle d accès/utilisation Détection d usurp. d identité Détection de dénis de service Contrôle d accès aux équipts Contrôle d accès aux services Identificateur de protocoles de couche 3 X Identificateur de protocoles de couche 3 X Identificateur de protocoles de couche supérieure X Identificateurs de connexion X X Indicateur de best effort X X Liste des réseaux de transit X Plan d adressage de l adresse connectée X X Plan d adressage de la sous-adresse connectée X X Plan d adressage de la sous-adresse de appelé X X Plan d adressage de la sous-adresse de l appelant X X Plans d adressage de l appelant X X Plans d adressage de l appelé X X Priorité de l appel X Sous adresse connectée X X Sous adresse de l appelant X X Sous adresse de l appelé X X Taille maximale des rafales ou MBS X X Taux de perte acceptable ou CLR X X Type de cellule OAM X Type de flux X X Type d AAL X Type d AAL X Variation de délai acceptable ou CDV X X 3. Caractérisation des utilisations normalisées des réseaux ATM Contrôle d accès au réseau Dans cette partie nous passons en revue les différentes utilisations normalisées du modèle ATM. Nous nous attachons dans cette revue à deux points principaux pour chaque proposition. Le premier est la pile protocolaire utilisée par la proposition. Nous voyons ensuite comment la pile protocolaire se traduit au niveau des informations contenues dans les messages de signalisation. Ces données autorisent d une part la construction de profils de signalisation concernant les utilisations des réseaux ATM par rapport aux IEs que nous avons détaillés dans le chapitre précédent. Ces profils permettent de définir l utilisation correcte des services analysés et permettent donc, dans une optique de contrôle d accès, de repérer les comportements suspects. D autre part ces données nous permettent d extraire les types d informations permettant de caractériser une utilisation vis à vis des autres. 63

72 Le contrôle d accès dans les réseaux ATM - Paramètres de contrôle d accès 3.1. Utilisations Classical IP over ATM Comme nous l avons dit au chapitre 3 section 1.3, CLIP (Classical IP over ATM, [RFC1755], [RFC2022], [RFC2225], [RFC2684]) est constitué d un ensemble de spécifications de l IETF ayant pour but d assurer le transport du protocole IP sur un réseau ATM. Le RFC 2684 décrit les piles protocolaires pouvant être utilisées. Dans tout les cas celles-ci reposent sur l AAL5, cependant les piles protocolaires utilisées au dessus de l AAL5 dépendent de l encapsulation utilisée. En effet le RFC 2684 précise que le mode d encapsulation par défaut est l encapsulation SNAP-LLC. Celle-ci permet à plusieurs protocoles de partager une même connexion ATM, en dirigeant les messages vers le protocole adéquat au moyen d un identificateur de protocole inclus dans les informations d encapsulation. Cependant un mode sans encapsulation appelé NULL-Encapsulation est également autorisé. Dans ce mode chaque connexion est liée à un protocole particulier dont l identité est indiquée à l ouverture de connexion dans la signalisation. Les piles protocolaires possibles sont données en figure 26. Figure 26. Pile protocolaire utilisée par CLIP. IP ATMARP/inATMARP SNAP/LLC Q93B/SSCOP AAL5 ATM PHY Le RFC 1755 décrit les paramètres de signalisation devant être utilisés. Ceux-ci sont repris dans le tableau LAN émulé Tableau 11. Valeur de certains des éléments de signalisation dans le cas de CLIP. IE Elément Valeur AALP AAL Type (AAL Type 5) BLLI (SNAP/LLC encaps.) User Information Layer 2 Protocol BLLI (NULL encaps.) User Information ISO/IEC TR 9577 Layer 3 Protocol ISO/IEC TR 9577 IPI IP ATD Best Effort Indication Oui L émulation de LAN ([LANE10], [LANE20]) est la proposition de l ATM-Forum pour assurer l interconnexion de LANs existants au travers de réseaux ATM. Afin d assurer ce service, l émulation de LAN utilise quatre types d éléments. Un exemple de leur fonctionnement est décrit au chapitre 3 section 1.3. Les piles protocolaires utilisées dans ces éléments se basent sur une couche d émulation de LAN (LANE) située au- 64

73 Le contrôle d accès dans les réseaux ATM - Paramètres de contrôle d accès dessus de l AAL5. Cette couche utilise plusieurs types de connexions (LE Configuration Direct VCC, Control Direct VCC, Control Distribute VCC, Ethernet/IEEE LE Data Direct VCC, IEEE LE Data Direct VCC, Ethernet/IEEE LE Multicast Send VCC/Multicast Forward VCC, IEEE Multicast Send VCC/Multicast Forward VCC) afin de différencier les fonctions utiles pour rendre le service d émulation de LAN. De ce fait il est nécessaire à l ouverture de connexion de spécifier quel type de connexion est utilisé au moyen d une information incluse dans la signalisation. Une des principales différences entre les deux versions de la norme portent sur la capacité de multiplexage. De ce fait une couche SNAP/LLC peut être introduite, dans la version 2 de la norme, entre la couche AAL5 et la couche LANE. Comme dans le cas d IP, elle permet de multiplexer les informations de plusieurs connexions en distinguant leur provenance au moyen d un identificateur de protocole. Les piles protocolaires utilisables sont décrites en figure 27. Figure 27. Pile protocolaire utilisée par LANE. IP SNAP/LLC LANE SNAP/LLC (LANE 2.0) Q93B/ SSCOP AAL5 ATM PHY Les paramètres de signalisation sont décrits dans le tableau 12. Tableau 12. Valeur de certains des éléments de signalisation dans le cas du LANE. IE Elément Valeur AALP AAL Type (AAL Type 5) BLLI (SNAP/ LLC encaps.) BLLI (NULL encaps.) User Information Layer 2 Protocol User Information Layer 3 Protocol ISO/IEC TR 9577 IPI SNAP OUI PID ISO/IEC TR SNAP 00A03E (ATM Forum OUI) 0001 pour LE Configuration Direct VCC, Control Direct VCC et Control Distribute VCC, 0002 pour Ethernet/IEEE LE Data Direct VCC, 0003 pour IEEE LE Data Direct VCC, 0004 pour Ethernet/IEEE LE Multicast Send VCC et Multicast Forward VCC, 0005 pour IEEE Multicast Send VCC et Multicast Forward VCC. ATD Best Effort Indication Oui Forward Peak Cell Rate (CLP=0+1) Libre (ABR) 65

74 Le contrôle d accès dans les réseaux ATM - Paramètres de contrôle d accès IE Elément Valeur MPOA Backward Peak Cell Rate (CLP=0+1) Forward ABR Minimum Cell Rate Backward ABR Minimum Cell Rate Libre (ABR) Libre (ABR) Libre (ABR) Comme nous l avons dit au chapitre 3 section 1.3, MPOA ([MPOA10]) peut être vu comme une extension du service d émulation de LAN afin de permettre des communications inter-elans efficaces, c est-à-dire sans passage par des routeurs. De ce fait les communications intra-elans conservent une encapsulation conforme à celle utilisée dans les ELANs décrites en section Par ailleurs la spécification de MPOA précise que les communications inter-elans utilisent par défaut une encapsulation SNAP/LLC conforme à celle décrite dans la section Elle précise également un format d encapsulation additionnel appelé encapsulation avec étiquette. Celui-ci introduit une étiquette (ou Tag) de 4 octets placée entre l encapsulation SNAP/ LLC et le paquet IP. Cette étiquette correspond à un index permettant de faire rapidement, au niveau des MPCs, la relation entre un paquet IP et sa source et sa destination dans le réseau ATM. Le tableau 13 précise les relations entre type de communication et messages de signalisation utilisés. Tableau 13. Relations entre type de communication et messages de signalisation utilisés. Type de communication Contenu de la signalisation Intra-ELANs section 3.1.2, tableau 12 Inter-ELANs section 3.1.1, tableau 11 La figure 28 décrit la pile protocolaire utilisée au niveau d un MPC (MPOA Client). Figure 28. Pile protocolaire utilisée par MPOA au niveau d un MPC. IP SNAP/LLC MPOA LANE SNAP/LLC Q93B/ SSCOP AAL5 ATM PHY 66

75 Le contrôle d accès dans les réseaux ATM - Paramètres de contrôle d accès CES L ATM-Forum propose une spécification appelée CES (Circuit Emulation Service) permettant d offrir un service d émulation de circuits au dessus d un réseau ATM [CES20]. L objectif de cette spécification est d émuler le comportement des liens DS1, DS3, E1, E3 pouvant être établis dans les réseaux PDH (Plesiochronous Digital Hierarchy) par des connexions ATM configurées de manière appropriée. Ce service permet d assurer le transport des informations générées par les communications entre les équipements utilisant ce type de liens (par exemple les applications d audio ou de visio-conférence) sur un réseau ATM. La conversion est réalisée au moyen d un élément additionnel appelé IWF (InterWorking Functions) placé en coupure entre le réseau ATM et les équipements à interconnecter. La pile protocolaire utilisée au niveau de l élément IWF se base uniquement sur l'aal1 et est décrite en figure 29. Figure 29. Pile protocolaire utilisée par VTOA et CES. IWF AAL1 ATM PHY Les paramètres de signalisation sont décrits dans le tableau VTOA Tableau 14. Valeur de certains des éléments de signalisation dans le cas de CES. IE Elément Valeur AALP AAL Type (AAL Type 1) Subtype (Circuit Transport) CBR rate Structuré: (64 kbit/s) (Nx64 kbit/s, N>1) Non structuré: X kbit/s avec X=1544 pour DS1, X=2048 pour E1, X=6312 pour J2, X=44736 pour DS3 et X=34368 pour E3. Multiplier structuré: N BLLI User Information ISO/IEC TR 9577 Layer 3 Protocol ISO/IEC TR 9577 IPI IPI Organizational Unit Identifier (OUI) 00 A0 3E ATM Forum OUI Protocol Identifier (PID) Service Structuré, DS1/E1/J2 Nx64 Service de base, E1 Nx64 Service avec CAS, DS1 SF Nx64 Service avec CAS, DS1 ESF Nx64 Service avec CAS, 00 0B J2 Nx64 Service avec CAS (CAS - Carrying channel Associated Signaling) L objectif de VTOA (Voice and Telephony Over Atm) [VTOA10] est proche de celui de CES. Il s agit de permettre les communications entre terminaux téléphoniques que ceux-ci se trouvent connectés à une réseau RNIS-LB ou à un réseau RNIS-BE. Comme dans le cas de CES un élément IWF est défini afin de réaliser les opérations de traduction nécessaires afin de permettre les communications entre les deux réseaux. La pile pro- 67

76 Le contrôle d accès dans les réseaux ATM - Paramètres de contrôle d accès tocolaire du plan utilisateur associée à l élément IWF est proche de celle utilisée dans CES décrite en figure 29. Dans VTOA l'aal1 peut être remplacée par une AAL5 (qui est l AAL par défaut). Dans les deux cas, l'encapsulation se fait de manière directe sur l'aal. Du fait de l interaction possible entre des équipements situés d une part dans un réseau RNIS-LB et d autre part dans un réseau RNIS-BE, il a été décidé afin de garantir une compatibilité maximale de désigner le service VTOA au moyen de l IE NBC, propre au réseau RNIS-BE. Les paramètres de signalisation sont décrits dans le tableau Applications ANS Tableau 15. Valeur de certains des éléments de signalisation dans le cas de VTOA. IE Elément Valeur AALP AAL Type (AAL pour la voix/aal1) (AAL Type 5) ATD Fwd PCR CLP (AAL1), (AAL5) Bwd PCR CLP (AAL1), (AAL5) NBC User information layer 1 protocol G711 loi µ, G711 loi A Le service ANS (Atm Name System) défini dans [ANS10] est une extension du service DNS utilisé dans les réseaux IP. Il permet de faire la correspondance entre nom d'équipement et adresse ATM. Cependant, au lieu de fonctionner au dessus de TCP/IP, il fonctionne directement au dessus du modèle ATM. La pile protocolaire utilisée au niveau des équipements d extrémité se base uniquement sur l'aal5 et est décrite en figure 30. Figure 30. Pile protocolaire utilisée par les services ANS et AMS. ANS/AMS AAL5 ATM PHY Les paramètres de signalisation sont décrits dans le tableau 16. Tableau 16. Valeur de certains des éléments de signalisation dans le cas du service ANS. IE Elément Valeur AALP AAL Type (AAL Type 5) ATD Best Effort Indicator Oui BHLI High layer information type Identificateur d application spécifique au vendeur OUI Application ID 00A03E ATM Forum OUI ANS 68

77 Le contrôle d accès dans les réseaux ATM - Paramètres de contrôle d accès AMS L'ATM-Forum a défini dans [VOD10] un service de distribution de flux multimedias de type MPEG-2 (AMS - Audiovisual Multimedia Services) sur ATM. Comme dans le cas du service ANS, le service de distribution de flux MPEG-2 se positionne dans la pile protocolaire directement au dessus d une couche AAL5 tel que représenté en figure 30. Les paramètres de signalisation sont décrits dans le tableau 17. Tableau 17. Valeur de certains des éléments de signalisation dans le cas du service AMS. IE Elément Valeur AALP AAL Type (AAL Type 5) BHLI High layer information type Identificateur d application spécifique au vendeur OUI Application ID 00A03E ATM Forum OUI AMS 3.2. Analyse Dans cette section, nous recherchons les éléments d information permettant de caractériser les utilisations normalisées des réseaux ATM. Cette information nous permet d une part de faciliter le processus de contrôle d accès qui peut être réalisé en niveau de la signalisation et d autre part de savoir facilement quelle utilisation est faite d une connexion ATM. Ce dernier point est particulièrement important si on souhaite réaliser un contrôle d accès sur les données transportées par la connexion. Pour cette recherche, nous examinons couche par couche les informations fournies dans la section précédente Couches non applicatives Connexions permanentes Les services CLIP et LANE version 1.0 autorisent l utilisation de connexions ATM permanentes. Les informations caractérisantes qui sont dans le cas de connexions dynamiques portées par la signalisation sont codées au moyen d une encapsulation SNAP/LLC associée aux données transportées. Le tableau 18 indique les correspondances entre encapsulation SNAP/LLC et type de service utilisé. Tableau 18. Relation entre valeur des champs caractérisants et services. Couche supérieure Champ de contrôle OUI Protocol Identifier IP 0x03 0x x0800 IP (multicast) 0x03 0x00005E 0x0001 ATMARP/inATMARP 0x03 0x x0806 MARS/MCS trame de contrôle 0x03 0x00005E 0x0003 LANE trame de donnée/contrôle (802.3) 0x03 0x00A03E 0x000C LANE trame de donnée/contrôle (802.5) 0x03 0x00A03E 0x000D MPOA trame de donnée (sans Tag) 0x03 0x x0800 MPOA trame de donnée (avec Tag) 0x03 0x x884C MPOA trame de contrôle 0x00 0x00005E 0x

78 Le contrôle d accès dans les réseaux ATM - Paramètres de contrôle d accès Connexions dynamiques Dans le cas de connexions dynamiques, l information caractérisante est déterminée de la manière suivante: Dans le cas d une encapsulation nulle (CLIP, LANE, MPOA) ou lorsque l encapsulation n est pas possible (CES): il s agit des informations transportées dans la signalisation au moyen du champ PID associé aux champs User Information Layer 3 Protocol, ISO/IEC TR 9577 IPI et Organizational Unit Identifier (OUI) de l IE BLLI. Les correspondances entre PID et couches sont décrites dans le tableau 19. Tableau 19. Relation entre valeur des champs caractérisants et services. Couche supérieure User Inf. IPI OUI Protocol Identifier LE Configuration/Control Direct VCC, LE Control x00A03E 0x0001 Distribute VCC LE Ethernet/IEEE802.3 Data direct VCC x00A03E 0x0002 LE IEEE802.5 Data direct VCC x00A03E 0x0003 LE Ethernet/IEEE802.3 Multicast Send/Forward VCC x00A03E 0x0004 LE IEEE802.5 Multicast Send/Forward VCC x00A03E 0x0005 DS1/E1/J2 Nx64 Basic Service x00A03E 0x0006 E1 Nx64 Service avec CAS x00A03E 0x0007 DS1 SF Nx64 Service avec CAS x00A03E 0x0008 DS1 ESF Nx64 Service avec CAS x00A03E 0x0009 J2 Nx64 Service avec CAS x00A03E 0x000B IP / / Dans le cas d une encapsulation SNAP/LLC (CLIP, LANE, MPOA), l information caractérisante est portée dans l encapsulation SNAP/LLC associée aux données d une manière analogue à celle présentée section L indication d encapsulation SNAP/LLC est signalée dans le champs User information layer 2 protocol de l IE BLLI par la valeur Dans le cas de VTOA, l information caractérisante est portée par le champ User information layer 1 protocol de l IE NBC. Le tableau 20 présente les correspondances entre valeurs de ce champ et type de codage VTOA. Tableau 20. Relation entre valeur des champs caractérisants et services. Type de codage VTOA G711 loi µ VTOA G711 loi A Protocol Identifier 0x02 0x Couche applicative L information permettant de caractériser l application utilisée est le champ Application ID associée au champ OUI de l IE BHLI. Les correspondances entre valeurs de ces champs et applications sont indiquées dans le tableau

79 Le contrôle d accès dans les réseaux ATM - Paramètres de contrôle d accès Conclusion Tableau 21. Relation entre valeur des champs caractérisants et applications. Application OUI Application ID ANS 0x00A03E 0x AMS 0x00A03E 0x La figure 31 résume cette section en en présentant une vision synthétique. Dans celle-ci nous donnons les tests devant être réalisés afin d aboutir à une caractérisation de l utilisation normalisée. Les rectangles représentent l état de connaissance atteint au moyen des question placées sous les rectangles. Les ellipses représentent les champs devant être analysés afin de terminer l analyse. Figure 31. Utilisation des informations caractérisantes. Connexions Permanentes Encapsulation SNAP/LLC Oui Protocole de niveau 1 Protocol ID. Utilisations Info. administrative Non indique une connexion permanente Oui Non Avec Encaps. Non applicatif Présence de l IE NBC Non Connexions dynamiques Présence de l IE BHLI Non Oui Protocole de niveau 2 ou 3 Oui IE BHLI User Info. = Sans Encaps. Applicatif OUI, Application ID Encapsulation SNAP/LLC IPI, OUI Protocol ID. 4. Classement des paramètres ATM A partir des analyses réalisées dans les sections précédentes nous pouvons réaliser un classement des champs de contrôle d accès que nous avions déterminés en section 2. Ce classement est basée sur plusieurs paramètres: Sur l utilité générale que l on peut donner au champ vis à vis de l utilisation que nous avions définie en section 2. Sur l optionnalité du champ. Celle-ci est fonction de l optionnalité de l IE dans les messages de signalisation définie en section 2. Sur l utilisation réelle du champ dans les applications spécifiées que nous avons recensées en section 3.1. Sur la valeur caractérisante du champ vis à vis de l analyse que nous avons réalisée en section

80 Le contrôle d accès dans les réseaux ATM - Paramètres de contrôle d accès Le classement des champs de contrôle d accès présente plusieurs intérêts. Le premier est de déterminer dans le cas d une implémentation quels paramètres de contrôle d accès doivent être implémentés prioritairement. En effet comme nous l avons vu en section 2, le nombre de paramètres pouvant être utilisés est important. Une implémentation permettant de fournir un service de contrôle d accès en exploitant tous ces paramètres serait longue à construire. De plus, comme nous l avons montré en section 3, chapitre 2 la performance d un processus de contrôle d accès est fortement liée au nombre de champs à analyser. On peut donc supposer qu une implémentation utilisant un grand nombre de champs serait peu performante. Enfin, du fait de l utilisation de paramètres présentant peu d intérêt, ce type d implémentation serait au mieux légèrement plus intéressant qu une version utilisant une sélection plus restreinte de paramètres. Le second intérêt est que le classement des paramètres nous permet de créer des profils. Ceux-ci fournissent un moyen commode de comparer les architectures de contrôle d accès de manière indépendante de leur implémentation. Afin de réaliser notre classement, nous définissons 5 profils de contrôle d accès. Ceux-ci vont d une absence de contrôle d accès (appelé profil 0) à un contrôle d accès utilisant tous les paramètres disponibles (appelé profil 5). Le profil 1 a été créé afin de permettre le classement des équipements de contrôle d accès existants. Il correspond de ce fait aux capacités de contrôle d accès ATM des équipements décrits en sections 4.2.1, 4.2.2, et du chapitre 3. En dehors des critères présentés ci dessus nous ne donnons pas la façon dont les profils sont formés. En effet suivant la façon dont les critères sont pondérés il est possible d obtenir des profils assez différents. De ce fait les profils que nous présentons ne sont que notre vision subjective de l'utilité des paramètres de contrôle d'accès. Un moyen d améliorer ce classement serait d utiliser une étude des attaques réelles qui permettrait de classer les paramètres plus objectivement. Profil 0 Aucun paramètre de contrôle d accès. Profil 1 Adresse de l appelant, Plan d adressage de l appelant, Adresse de l appelé, Plan d adressage de l appelé. Profil 2 Paramètres du profil 1. Identificateurs de connexion (En-tête des cellules). Identificateur de protocole de couche 1 (NBC), Identificateur de protocole de couche 2, Identificateur de protocole de couche 3, Identificateur de protocole de couche supérieure. Débit crète ou PCR, Indicateur de best effort, Débit minimum ABR. Profil 3 Paramètres du profil 2. Identificateur de connexions point à multipoint, Sous-Adresse de l appelant, Sous-Adresse de l appelé. Débit CBR pour l AAL1, Débit soutenu ou SCR, Taille maximale des rafales ou MBS, Variation de délai acceptable ou CDV, Taux de perte acceptable ou CLR. Priorité de l appel. Profil 4 Paramètres du profil 3. Type de flux. Connection Scope Selection, Identificateur d extrémité, Adresse Connectée, Plan d adressage de l adresse connectée. ATD débit initial. 72

81 Le contrôle d accès dans les réseaux ATM - Paramètres de contrôle d accès Profil 5 Tous les paramètres de contrôle d accès. 5. Conclusion Dans ce chapitre nous avons extrait du modèle ATM les paramètres pouvant servir à fournir un service de contrôle d accès au niveau ATM. Pour cela nous avons tout d abord réalisé une analyse systématique des informations fournies par le modèle ATM pour savoir si elles pouvaient avoir une utilité dans le domaine du contrôle d accès. Nous avons ensuite identifié les informations les plus pertinentes vis à vis des utilisation réelles des réseaux ATM. Pour finir nous avons classé les paramètres de contrôle d accès en fonction de leur utilité et de leur utilisation réelle. Ce classement nous a permis de créer des profils de contrôle d accès permettant de classer les architectures de contrôle d accès ATM. Le tableau 22 fournit un récapitulatif des informations de contrôle d accès fournies par le modèle ATM et par leur classement. Tableau 22. Récapitulatif des paramètres fournis par le modèle ATM. Information Emplacement Profil Adresse connectée (CN, octets 6-) 4 Adresse de l appelant (CPN, octets 6-) 1 Adresse de l appelé (cpn, octets 6-) 1 ATD débit initial ABR (ASP, octets 5,6) 4 Connection scope selection (CSS, octet 6) 4 Débit CBR pour AAL1 (AALP octets 7-8) 3 Débit crète ou PCR (ATD, AATD, MATD octets 5,6,7,8) 2 Débit minimum ABR (ATD octets 19,20) 2 Débit soutenu ou SCR (ATD, AATD, MATD octets 9,10,11,12) 3 Fonction OAM Cellule (Bits 45-48) 5 Identificateur d'extrémité (ER, octets 6-) 4 Identificateur de connexion point à multipoint (LIJCI, octets 6-9) 3 Identificateur de protocoles de couche 1 (NBC, octet 5) 2 Identificateur de protocoles de couche 1 (BLLI, octet 5) 5 Identificateur de protocoles de couche 2 (BLLI, octet 6) 2 Identificateur de protocoles de couche 2 (NBC, octet 6) 5 Identificateur de protocoles de couche 3 (BLLI, octet 7) 2 Identificateur de protocoles de couche 3 (NBC, octet 7) 5 Identificateur de protocoles de couche supérieure (BHLI, octet 6-13) 2 Identificateurs de connexion Cellule (Bits 5-28) 2 Indicateur de best effort (ATD, octet 18) 2 Liste des réseaux de transit (TNS octet 6-) 5 Plan d adressage de l adresse connectée (CN, octet 5) 4 Plan d adressage de la sous-adresse connectée (CSA, octet 5) 5 73

82 Le contrôle d accès dans les réseaux ATM - Paramètres de contrôle d accès Information Emplacement Profil Plan d adressage de la sous-adresse de appelé (cpsa, octet 5) 3 Plan d adressage de la sous-adresse de l appelant (CPSA, octet 5) 3 Plans d adressage de l appelant (CPN, octet 5) 1 Plans d adressage de l appelé (cpn,octet 5) 1 Priorité de l appel (pi octet 5) 3 Sous adresse connectée (CSA, octets 6-) 5 Sous adresse de l appelant (CPSA, octets 6-) 3 Sous adresse de l appelé (cpsa, octets 6-) 3 Taille maximale des rafales ou MBS (ATD, AATD, MATD octets 13,14,15,16) 3 Taux de perte acceptable ou CLR (EQoSP, octets 10,11) 3 Type de cellule OAM Cellule (Bits 41-44) 5 Type de flux Cellule (Bits 5-32) 4 Type d AAL (AALP octet 5) 5 Type d AAL / 5 Variation de délai acceptable ou CDV (EQoSP, octets 6,7,8,9) 3 Un point n a pas été abordé dans ce chapitre, celui des paramètres de contrôle d accès pouvant être extraits des modes d utilisation du réseau ATM que nous avons identifiées en section 3. Il y a plusieurs raisons à cette absence. D une part les paramètres de contrôle d accès qui pourraient être tirés de l analyse des informations échangées par ces modes d utilisation ne permettent qu un raffinement des paramètres de contrôle d accès que nous donnons dans le tableau précédent. On peut donc estimer que leur utilité est moindre par le fait qu il n ont une utilité que dans le cas d une utilisation particulière du réseau. D autre part peu d attaques exploitant des paramètres de ce type ont été mises en évidence (A notre connaissance les seules concernent CLIP et sont présentées dans [Ben98]). De plus il a été montré que la seule solution à ces attaques était soit l utilisation d un service d authentification adéquat soit la configuration statique des équipements. Si l on considère la façon dont les réseaux ATM sont aujourd hui utilisés, une des utilisations la plus courante est le transport de flux Internet au moyen des méthodes que nous avons évoquées en sections 3.1.1, et Il est donc important de spécifier quels paramètres de contrôle d accès peuvent être utilisés dans ce cas. Cependant le problème du contrôle d accès sur les flux Internet a déja été souvent considéré et des ouvrages tels que [Che94] ou [Cha95] décrivent en détail les paramètres à prendre en compte dans ce cas. Nous ne reviendrons donc pas sur ces paramètres bien que ceux-ci aient une grande importance et soient utilisés par la suite dans des architectures de contrôle d accès telles que celles que nous présentons dans le chapitre suivant. 74

83 CHAPITRE 5 Mécanismes de contrôle d accès Dans ce chapitre nous proposons un certain nombre de mécanismes de contrôle d accès permettant de résoudre les problèmes présentés dans le chapitre précédent. Nous montrons également les résultats d implémentation de certains d entre eux. 1. Introduction Dans ce chapitre, nous proposons deux architectures de contrôle d accès permettant de résoudre les problèmes de contrôle d accès résumés en section 5 du chapitre 3. D une part il convient d élaborer une architecture capable de prendre en compte les paramètres de contrôle d accès de niveau ATM que nous avons mis en évidence au chapitre 4. D autre part l architecture doit être à même de fournir le service de contrôle d accès sans altération de la qualité de service négociée au niveau ATM. Enfin cette architecture doit être à même d offrir des performances importantes afin de supporter des débits élevés. Nos deux propositions prennent pour résoudre ces problèmes deux voies différentes. La première, présentée en section 2 est basée sur l utilisation d agents de contrôle d accès disposés sur les équipements du réseau. Elle utilise une approche non bloquante pour résoudre le problème de l impact sur la qualité de service en utilisant les informations provenant des bases de donnée de gestion normalisées. Le second point important de cette première approche est également de fournir un service de contrôle d accès de manière distribuée afin de fournir des performances acceptables. Nous montrons par ailleurs que la façon dont est effectué le contrôle d accès dans notre architecture permet d éviter certaines opérations et par ce fait améliore la performance globale de notre architecture de contrôle d accès. La seconde proposition, présentée en section 3, suit une approche complètement différente en se basant sur le développement d un algorithme de classement conçu de telle sorte que le temps de traitement nécessaire au classement ne dépende pas du nombre de règles de contrôle d accès exprimant la politique de contrôle d accès mais uniquement du nombre de champs à analyser. Cette propriété nous permet de garantir une borne maximale aux modifications concernant la qualité de service pouvant être négociée au niveau ATM. D autre part l implémentation de cet algorithme a été réalisée sur une architecture physique lui assurant d une part des performances intéressantes en terme de débit et d autre part une borne maximale de modification de la qualité de service extrêmement faible. Ces deux propositions résolvent par ailleurs le problème de la faiblesse du contrôle d accès au niveau ATM en utilisant la plupart des paramètres de contrôle d accès décrits au chapitre 4. Pour finir, la section 4 conclut ce chapitre en proposant une comparaison entre les deux approches en faisant ressortir les avantages et inconvénients de chacune. 75

84 Le contrôle d accès dans les réseaux ATM - Mécanismes de contrôle d accès 2. Contrôle d accès distribué asynchrone par agent Dans cette partie nous exposons une architecture de contrôle d accès distribuée et asynchrone où le service de contrôle d accès est rendu par des agents localisés sur les équipements du réseau ([Pa99c], [Pa99d]). Par agent nous entendons dans cette section mais également dans l ensemble de ce document, un élément logiciel capable d une certaine autonomie dans les actions qu il est amener à executer. Nos agents sont donc des éléments logiciels statiques. Afin de montrer les avantages d une telle architecture nous présentons tout d abord les améliorations potentielles vis à vis d une architecture centralisée en terme de performances. Nous décrivons ensuite les paramètres de contrôle d accès utilisables dans notre architecture. Enfin nous décrivons les éléments permettant d utiliser ceux-ci Généralités Dans cette section nous nous proposons de montrer de manière théorique que la distribution du service de contrôle d accès apporte un certain avantage en terme de performances et cela quelle que soit la façon dont le processus de contrôle d accès est implémenté. Pour cela nous essayons de décomposer les opérations réalisées par un processus de contrôle d accès. Dans le cas d un service de contrôle d accès fourni par un équipement centralisé, la capacité de calcul nécessaire pour le contrôleur dépend pour chaque équipement k du réseau: Du nombre de règles (Nbr(j)) nécessaires pour filtrer les services sur chaque équipement j du réseau. Du nombre de paramètres de contrôle d accès (Nbp(j)) définissant ces règles. Si on suppose négligeables les opérations de fragmentation et de réassemblage, la capacité de calcul Pc(k) nécessaire pour réaliser le contrôle d'accès pour un flux vers l équipement k dans le cas de l utilisation d une algorithme de classement linéaire est: n Pc( k) = N br () j Nbp () j j = 1 Pc(k) dépend donc de la politique de contrôle d accès des n équipements du réseau. Il en résulte que le service de contrôle d'accès pour un équipement peut pénaliser celui d'autres équipements. Cette pénalité peut ne pas être proportionnelle pour un équipement au service de contrôle d'accès qu'il demande. Dans le cas d un service de contrôle d accès fourni par une architecture distribuée, la capacité de calcul nécessaire pour rendre le service de contrôle d'accès dépend pour l équipement k: Du nombre de règles (Nbr(k)) nécessaires pour filtrer les services sur l équipement k. Du nombre de paramètres de contrôle d accès (Nbp(k)). La capacité de calcul Pd(k) nécessaire pour réaliser le contrôle d'accès d un flux pour l'équipement k si on utilise le même algorithme de classement est de ce fait égale à: Pd( k) = Nbr( k) Nbp( k) Il est facile de constater que l on a: Pd( k) Pc( k) 76

85 Le contrôle d accès dans les réseaux ATM - Mécanismes de contrôle d accès On peut donc conclure que la capacité de calcul nécessaire pour rendre le service de contrôle d'accès pour un ensemble d'équipements dans le cas d'une analyse distribuée est toujours inférieure ou égale à celle qui serait nécessaire dans le cas d'une analyse centralisée Paramètres de contrôle d accès Mécanismes de gestion des réseaux L'idée d'utiliser des données de gestion afin de rendre des services de sécurité n'est pas nouvelle. L'utilisation la plus courante de ces informations est la fourniture du service de détection d'intrusion. Ainsi [Tib95] présente une utilisation des valeurs fournies par les MIBs spécifiées par l'ietf permettant de repérer des intrusions. [Apo97] propose une adaptation du système de description des objets afin d'y introduire des notions temporelles, celles-ci permettant de rendre des services de détection d intrusion de manière plus facile. [Darpa97] présente l'intégration d'un système de détection d intrusion avec le système de gestion spécifié par l'ietf. Les bases de données des systèmes de gestion ont également été utilisées afin de rendre des services de distribution d'éléments cryptographiques, d'audit [SECM98] et de gestion du contrôle d'accès [Sta97]. Dans cette partie nous nous intéressons aux informations de gestion dans un objectif de contrôle d'accès. Pour cela nous recherchons dans ces informations les données pouvant être utilisées afin de réaliser un contrôle d'accès. Nous considérons les informations qui ont été spécifiées afin de gérer les équipements ATM dans le cas de réseaux privés. Trois organismes ont établi à ce sujet des spécifications qui peuvent s'appliquer à la fois aux réseaux publics et privés. Il est cependant vraisemblable que seules les spécifications édictées par l'atm-forum et l'ietf seront appliquées au cadre des réseaux privés, les spécifications de l'itu s'appliquant, elles, aux réseaux publics. En ce qui concerne la gestion des réseaux privés, les modèles proposés par les deux organismes sont assez proches. Les concepts principaux de ces deux modèles sont les suivants. La station d administration assure l'interface entre les informations de gestion et le gestionnaire du réseau. Pour cela, elle dispose d'une interface permettant de récupérer ou de fixer les informations de gestion auprès des agents. Elle possède aussi généralement un ensemble de logiciels permettant d'analyser les données recueillies. Ces données sont conservées dans une base de donnée propre à la station. L'agent d administration est l'autre élément actif du système de gestion. L'agent d administration gère un ensemble d'objets au travers d'une représentation logique de ceuxci. Cette représentation logique est codée en suivant les recommandations ([RFC1442]) concernant la structure de gestion des informations (SMI - Structure of Management Information) dans une base de donnée de gestion (MIB - Management Information Base). Au travers de cette représentation logique, l'agent peut configurer ou surveiller les équipements qui lui sont rattachés. L'agent peut également fournir des informations à la station d administration de manière asynchrone. Ces deux éléments sont reliés au moyen d'un protocole d'administration. Dans le cadre des réseaux Internet, le protocole utilisé est SNMP (Simple Network Management Protocol). Dans la section suivante, nous montrons comment il est possible de rendre le service de contrôle d accès à divers niveaux protocolaires (ATM, TCP/IP et application) en utilisant les informations pouvant être trouvées dans les bases de données de gestion (MIB). Pour cela nous considérons certains scénarios de contrôle d accès et montrons comment le service de contrôle d accès peut être implémenté au moyen des informations présentes dans les MIBs actuellement spécifiées ou en cours de spécification. Le lecteur intéressé par une analyse approfondie des informations contenues dans les bases de données de gestion pourra se reporter aux annexes présentées en chapitre 9, sections 2.1, 2.2,

86 Le contrôle d accès dans les réseaux ATM - Mécanismes de contrôle d accès Niveau ATM L ATM-MIB a été spécifiée en 1994 par l IETF ([RFC1695]) afin de fournir des informations générales sur les connexions ATM. Comme cette MIB est relativement ancienne, une nouvelle MIB appelée ATM2-MIB est en cours de définition à l IETF ([AToM98]) (ce draft, bien qu étant théoriquement périmé, devrait prochainement être soumis à l IESG). Celle-ci contient des informations additionnelles représentant les évolutions récentes des réseaux ATM. Dans ce premier scénario, notre objectif est d empêcher des utilisateurs externes d utiliser un serveur de vidéo à la demande compatible avec la spécification [VOD10] de l ATM-Forum. Pour cela nous devons identifier les connexions entre le serveur vidéo et le client. Ces connexions sont identifiées au moyen de trois paramètres, l adresse ATM du client, l adresse ATM du serveur et l identificateur de l application de vidéo à la demande. Ces informations peuvent être obtenues au travers de certains objets définis dans la MIB ATM2- MIB ([AToM98]). Les tables atmvcladdrtable et atmaddrvcltable fournissent les correspondances entre adresses source et destination et identificateurs de connexion au travers de la variable atmvcladdraddr. L application de vidéo à la demande peut être identifiée comme nous l avons montré au chapitre 4 au travers d un ensemble de paramètres associés à l élément d information BHLI présent dans les messages de signalisation. La table atmsigdescrparamtable fournit le même ensemble d information pour les connexions établies au travers des variables atmsigdescrparambhlitype et atmsigdescrparambhliinfo. Comme nous l avons vu en section du chapitre 4, les valeurs caractérisant l application de vidéo à la demande sont les suivantes: - 0x04 pour la variable atmsigdescrparambhlitype. - 0x00A03E pour la variable atmsigdescrparambhliinfo. Le lien entre les informations fournies par les deux objets peut se faire en utilisant l identificateur de connexion atmsigdescrparamindex associé à la table atmsigdescrparamtable Niveau TCP/IP Les RFCs 2012 et 2013 ([RFC2012], [RFC2013]) définissent deux MIBs permettant de gérer les communications utilisant les protocoles TCP et UDP. Notre second scénario consiste à montrer comment nous pouvons empêcher des connexions au service telnet de l Internet vers des équipements internes à notre réseau. Comme dans l exemple précédent, nous devons tout d abord identifier les connexions entre le client telnet et son serveur. Ces connexions sont identifiées au moyen de quatre paramètres, les adresses IP du client et du serveur, le port source du client et le port destination du serveur. Bien que le numéro de port du client puisse changer, le numéro de port du serveur est lui fixé à la valeur 23. Ces paramètres peuvent être extraits d objets présents dans la TCP-MIB ([RFC2012]): La table tcpconntable donne les adresses source et destination ainsi que les identificateurs de ports source et destination au travers des variables tcpconnlocaladdress, tcpconnlocalport, tcpconnremaddress et tcpconnremport Niveau Application La quantité d information fournie par les MIBs au niveau application est moins importante que celle fournie par les niveaux inférieurs. Il est cependant possible de trouver certaines informations intéressantes. Notre objectif pour ce dernier exemple est d interdire les connexions distantes d un administrateur vers sa station de travail. Pour cela nous utilisons deux MIBs, RFC1414-MIB ([RFC1414]) et sysapplmib ([RFC2287]) de la manière suivante: 78

87 Le contrôle d accès dans les réseaux ATM - Mécanismes de contrôle d accès La table identtable définie dans la MIB RFC1414-MIB fournit l identificateur de chaque utilisateur (UID - User ID) associé à chaque connexion TCP au travers de la variable identuserid. Les connexions sont identifiées par le quartet adresse source, adresse destination, port source et port destination (tcpconnlocaladdress, tcpconnlocalport, tcpconnremaddress et tcpconnremport). La table sysapplelmtruntable définie dans la MIB sysapplmib donne les processus et l identificateur d utilisateur associés à chaque application exécutée sur la station de travail au travers des variables sysapplelmtrunname, sysapplelmtrunuser et sysapplelmtrunindex. En utilisant ces informations, il est possible de créer un lien entre l application de connexion à distance (telnet identifiée par un port destination égal à 23 par exemple), son utilisateur (l administrateur identifié par un UID égal à 0 dans notre cas) et la connexion TCP qui lui est associée. Les paramètres de la connexion TCP (ports source et destination) sont utilisés pour créer un lien avec le processus. Les autres paramètres (adresses source et destination) sont utilisés pour chercher si la connexion provient d un équipement externe Conclusion Dans cette section, nous avons montré qu il était possible de trouver dans les bases de données de gestion (MIB) des informations utiles pour fournir un service de contrôle d accès. Signalons tout de même que ces informations ne sont pas les seules, présentes sur les équipements réseaux et pouvant être utilisées dans le cadre d un service de contrôle d accès. En effet d autre informations, non spécifiées par les organismes de normalisation peuvent également être trouvées sur ces équipements. Ces informations pourraient être utilisées d une manière analogue à celles que nous avons présentées et sont souvent spécifiées par les constructeurs sous la forme de MIBs propriétaires. Les informations spécifiées au travers des MIBs présentent cependant de nombreux avantages. Le premier est que les équipements vendus aujourd hui spécifient généralement les normes qu ils respectent. Il est donc facile en comparant normes et spécifications des constructeurs de déterminer les informations utiles au contrôle d accès disponibles sur un équipement. Un second avantage est lié au fait que les spécifications des MIBs ne concernent généralement qu un domaine particulier. Il est donc généralement possible de rattacher une MIB à une fonction de contrôle d accès particulière et de construire une bijection entre la possibilité d implémenter une fonction de contrôle d accès et la présence d une MIB particulière. Les spécifications des MIBs permettent également de connaître les formats des éléments pouvant servir à réaliser du contrôle d accès. Ce format est particulièrement intéressant pour la définition d un langage de contrôle d accès tel que celui que nous définissons en section 2 du chapitre 6. Pour finir, les MIBs spécifiées nous permettent de nous appuyer sur des agents de gestion déjà développés pour accéder à ces informations. Comme la structure de ces agents est généralement spécifique au système qu ils contrôlent, leur réutilisation permet de gagner du temps dans la recherche du moyen d accéder aux variables pouvant servir dans le cas d un service de contrôle d accès Architecture Nous avons vu précédemment que les bases de donnée de gestion contiennent certaines informations pouvant être utilisées pour rendre un service de contrôle d accès. Nous présentons dans cette section une architecture permettant d exploiter ces données Vision générale Notre architecture se base sur l utilisation d agents de gestion modifiés afin de rendre un service de contrôle d accès. Comme indiqué en figure 32, ces agents peuvent se placer sur n importe quel type d équipement du réseau, que celui-ci soit intermédiaire ou terminal. 79

88 Le contrôle d accès dans les réseaux ATM - Mécanismes de contrôle d accès Figure 32. Placement des agents de contrôle d accès dans le réseau. Agent Agent Trans. ATM Réseau ATM ATM Réseau AT M Trans. ATM Les agents inter-agissent avec les équipements sur lesquels ils sont placés afin de fournir un service de contrôle d accès. Pour cela ils lisent de manière régulière les valeurs contenues dans les variables décrites en section 2.2. Ils comparent ensuite ces valeurs avec les valeurs autorisées. Ces valeurs autorisées correspondent à la partie de la politique de sécurité fournie par l officier de sécurité et applicable à l agent. Lorsque des valeurs interdites sont détectées, l agent inter-agit avec les piles protocolaires afin d interrompre les opérations correspondantes Architecture des agents La figure 33 décrit la structure générale d un agent de gestion. Celui-ci est composé de plusieurs parties. La première consiste en une ou plusieurs bases de données de gestion (MIB). Celles-ci correspondent à l organisation et la traduction des variables présentes sur le système géré sous la forme et dans le format spécifié par les organismes de normalisation au travers des MIBs normalisées. Ces bases de données sont accédées par un gestionnaire distant au travers d un processus de gestion qui est chargé, en fonction des requêtes du gestionnaire, de sélectionner les variables devant être accédées et d envoyer les résultats de la requête au gestionnaire. Le processus de gestion peut également envoyer des informations de manière asynchrone au gestionnaire lorsque des événements caractérisés vis à vis du contenu de certaines variables se produisent. La détection de ces évènements se fait en lisant de manière périodique le contenu des variables adéquates. Figure 33. Structure d un agent de gestion. Agent de gestion Interface d accès au MIBs Variable 1 Variable 2 MIB-1 Processus de gestion Variable 1 Variable 2 MIB-2 Gestionnaire Interface réelle du système Système Var. 1 Var. 2 Var. 3 Var. 4 La structure interne de notre agent de contrôle d accès décrit en figure 34 reprend partiellement cette architecture. Il conserve les MIBs qu il réorganise en fonction du niveau de contrôle d accès devant être réalisé (ATM, Transport, Application). Nous appellerons par la suite cette organisation, Base de Donnée d Information de Contrôle d Accès (BDCA). La BDCA permet de fournir une interface générique au processus de 80

89 Le contrôle d accès dans les réseaux ATM - Mécanismes de contrôle d accès contrôle d accès quelles que soient les variables réellement présentes au niveau du système réel et d autre part de simplifier ce processus de contrôle d accès. Le processus de contrôle d accès possède une structure dans laquelle est stockée la politique de contrôle d accès. Cette politique, fournie par l officier de sécurité est construite de telle sorte que toutes les variables sur lesquelles portent les conditions décrites dans la politique puissent être comparées aux variables présentes dans la BDCA. Figure 34. Structure d un agent de contrôle d accès. Agent de contrôle d accès Processus de contrôle d accès Politique de contrôle d accès Interface d accès aux descripteurs de communications Variable 1 Variable 2 ATM Variable 1 Transport Variable 1 Application Interface de contrôle Interface d accès aux MIBs Variable 1 Variable 2 MIB-1 Variable 1 Variable 2 MIB-2 Interface réelle du système Système Var. 1 Var. 2 Var. 3 Var. 4 Le processus de contrôle d accès est commandé par le contenu de la politique de contrôle d accès spécifié par l officier de sécurité. Cette politique de contrôle d accès est exprimée au moyen du langage de bas niveau que nous présentons en section 2.1 du chapitre 6. La mise en oeuvre du service de contrôle d accès consiste, pour chaque descripteur de communication à chercher dans la BDCA une règle pouvant s appliquer en utilisant un des algorithmes de classement présenté en section 3, chapitre 2. Une fois cette règle déterminée, l action correspondante est appliquée. Dans le cas où la communication est autorisée aucune action n est effectuée alors que lorsque la communication est interdite, celle-ci est interrompue en utilisant l interface de contrôle. Cette interruption peut se faire de plusieurs façons: Au niveau applicatif, elle peut consister à interrompre le processus responsable de l opération interdite. Ce type d opération peut être utilisé pour fournir un service de contrôle d accès au niveau applicatif. Au niveau transport, il est possible de bloquer les communications à interdire en libérant la connexion correspondante dans le cas des communications orientées connexion (TCP dans notre cas). Au niveau ATM, il est possible de bloquer les communications à interdire en libérant la connexion ATM correspondante dans le cas de l utilisation de connexions dynamiques. Le cas des connexions permanentes peut être traité en déconfigurant dynamiquement les interfaces de niveau transport relatives aux communications. Cette méthode peut être utilisée pour rendre un service de contrôle d accès de niveau ATM mais également pour rendre un service de contrôle d accès de niveau transport dans le cas de communications non connectées (UDP/ICMP). Il est dans ce dernier cas possible de faire le lien entre communications de niveau transport et de niveau ATM en utilisant les informations fournies par la MIB IF-MIB définie dans le RFC 2233 [RFC2233]. Celle-ci définit en effet les correspondances entre interfaces de couches protocolaires différentes. 81

90 Le contrôle d accès dans les réseaux ATM - Mécanismes de contrôle d accès 2.4. Conclusion Vis à vis des problèmes présentés en chapitre 3, l architecture que nous avons présentée dans cette section possède certaines caractéristiques intéressantes: Elle garantit des performances supérieures à celles d une architecture de contrôle d accès centralisée telle que celles que nous présentons en sections 4.2 et 4.3, chapitre 3 par le fait qu elle évite une partie des opérations de filtrage ainsi que les opérations de fragmentation et de réassemblage. Cette amélioration est de plus indépendante de la façon dont le processus de contrôle d accès est implémenté et donc de l algorithme de classement utilisé. La plupart des paramètres de contrôle d accès de niveau ATM que nous avons mis en évidence au chapitre 4 peuvent être utilisés. Le niveau du service de contrôle d accès pouvant être implémenté est donc amélioré vis à vis des solutions concurrentes. Les informations accédées pour fournir le service de contrôle d accès sont examinées de manière non bloquante par nos agents au niveau application. Ceci signifie que comme nous l avons montré en section 2.1.1, chapitre 2, que notre système de contrôle d accès ne peut pas introduire de modification vis à vis de la qualité de service négociée. Un autre avantage de notre système est que les modifications à apporter aux équipements du réseau restent faibles. En effet seul un élément logiciel de niveau applicatif (l agent de contrôle d accès) doit être installé sur chaque équipement du réseau que l on désire voir implémenter le service de contrôle d accès. Cependant notre architecture pose également deux problèmes. Le premier est de déterminer un intervalle adéquat pour la lecture des valeurs décrivant les connexions. En effet, d un côté, un intervalle trop court introduira une surcharge inutile au niveau des systèmes sur lesquels les agents sont placés. D un autre côté, un intervalle trop long pourrait introduire des trous de sécurité par le fait que certaines communications ou certaines opérations pourraient passer inaperçues au yeux du processus de contrôle d accès. Un moyen de résoudre ce problème serait de limiter la détection d un changement à la lecture d une seule variable et d adopter une fréquence de lecture en fonction d un pourcentage (1% par exemple) d occupation du processeur du système protégé tout en fixant une borne limite à la durée pouvant exister entre deux lectures. Il serait par ailleurs intéressant de pouvoir fixer cette durée en fonction de l utilisation du système, c est à dire en fonction de la durée minimale des communications constatées sur le système. Un second problème vient du nombre d agents potentiels. Ces agents doivent être configurés par l officier de sécurité afin de pouvoir rendre le service de contrôle d accès. La configuration de chaque agent étant un cas particulier, il est peu crédible d imaginer une configuration de chaque agent à la main pour les raisons que nous avons détaillées en section 4.1, chapitre 2. C est la raison pour laquelle nous proposons dans le chapitre 6 deux architectures de gestion automatique du contrôle d accès permettant de résoudre ce problème. 3. Contrôle d accès synchrone centralisé Dans cette partie, nous présentons une architecture ([Pa00c], [Pa00d]) basée sur l utilisation d un composant spécialisé appelé IFT (Internet Fast Translator). Les IFTs ([Acc00]) sont des composants qui permettent, en fonction du contenu d une cellule ATM et d une politique de classement, de décider d une action à réaliser. Cependant les IFTs ne spécifient pas un format unique concernant la politique de classement. Il est de ce fait possible en jouant sur la façon dont la politique est exprimée d obtenir des processus de classement ayant des caractéristiques très variables. Les composants IFTs seront utilisés dans notre cas en association avec une architecture physique permettant d adapter le trafic d un réseau ATM à un composant IFT afin que celui-ci réalise son analyse. Nous appellerons par la suite l association de ces deux éléments, cartes IFTs. Dans cette partie notre apport principal n est pas lié aux cartes IFTs mais à la façon dont celles-ci sont configurées. Cette partie est organisée de la manière suivante. Nous présentons tout d abord le composant physique autour 82

91 Le contrôle d accès dans les réseaux ATM - Mécanismes de contrôle d accès duquel va être développée notre architecture : les cartes IFT. Nous montrons ensuite comment ce composant peut s intégrer dans une architecture de contrôle d accès. Pour finir nous donnons les résultats de tests de l implémentation de l architecture Cartes IFTs Introduction Les cartes IFTs (Internet Fast Translator) ont été développeés par France Telecom R&D avec comme principale objectif d effectuer du routage à haut débit ([IFT10]). L analyse des en-têtes se fait au moyen d une mémoire Trie (memory trie) qui a été étendue afin de fournir un moyen d analyse générique permettant d analyser tous les champs d une cellule dans n importe quel ordre. Le comportement de l IFT est dicté par plusieurs facteurs; le contenu de la mémoire trie, une machine à état permettant de conserver l état de l analyse et de lancer l exécution d actions adéquates, un composant physique capable d accélérer ces actions et enfin une capacité de comptage permettant d associer des compteurs à la reconnaissance de figures préétablies. La mémoire trie actuellement utilisée a une taille de 4 Mo La mémoire Trie Le principe de la mémoire trie a été proposé au début des années 60. La mémoire trie est un moyen de stocker et de récupérer des informations. L avantage principal de la mémoire trie vis à vis des autres types de mémoire est de fournir un temps d accès à l information relativement faible, une grande facilité d ajout et d effacement, une capacité à supporter des arguments de taille variable et la possibilité de tirer parti des redondances présentes dans les informations stockées ([Fred60]). Le processus de recherche dans une mémoire trie est basé sur une série d indexations, indirections dans un tableau à deux dimensions. Comme présenté dans le tableau 23, chaque ligne du tableau constitue un registre de 2 k cases où k est la longueur en bit de la tranche analysée (dans notre cas k est égal à 4). Les registres peuvent être situés n importe où dans le tableau à l exception de la première ligne du tableau qui est réservée à l analyse de la première tranche de k bits. Chaque mot mémoire est donc adressé en ligne au moyen d une adresse ou registre et en colonne au moyen du contenu des k premiers bits du champ à analyser. Ce mot mémoire contient un status qui permet d adresser le registre suivant dans l analyse afin de continuer celle-ci (cases présentant un motif RX dans le tableau présenté). Ce type de status est appelé status intermédiaire. Les status permettent également d interrompre l analyse et de renvoyer le résultat de celle-ci lorsque le champ analysé correspond à un motif stocké en mémoire (cases présentant un motif SX dans le tableau présenté). Ce dernier type de status est appelé status final. Tableau 23. Exemple de mémoire Trie. 0x0 0x1 0x2 0x3 0x4 0x5 0x6 0x7 0x8 0x9 0xA 0xB 0xC 0xD 0xE 0xF R0 R1 R2 R4 R1 R4 R2 R2 S2 R3 S1 R3 S3 S3 R4 S4 S5... La figure 35 présente la structure d un status. Comme on peut le voir, celui-ci est composé de cinq parties principales. Les deux premières parties appelées partie de contrôle et compteur ne sont pas utilisées dans notre cas. La troisième partie appelée type d adresse décrit le type de déplacement à réaliser pour atteindre le quartet de données suivant à analyser. Le champ déplacement contient la longueur du déplacement en quartet 83

92 Le contrôle d accès dans les réseaux ATM - Mécanismes de contrôle d accès de bits à réaliser pour atteindre le prochain champ à analyser. Enfin le dernier champ indique dans le cas d un status intermédiaire l adresse du prochain registre. Dans le cas d un status final, celui-ci indique un pointeur donnant le résultat de l analyse. Figure 35. Structure des champs status Contrôle Déplacement Adresse du prochain registre (Status Intermédiaire) Pointeur (Status Final) Type d adresse du prochain quartet 00 en séquence 01 relatif 10 différentiel 11 absolu Compteur Cette structure des quartets nous permet de distinguer deux types de registres. Les registres intermédiaires qui correspondent à l analyse en séquence des tranches de k bits d un champ. Les status permettant d atteindre ces registres correspondent à une longueur de déplacement de un quartet et à une adresse de registre indiquant le registre suivant dans la mémoire trie. Les portiers correspondent au premier registre permettant de commencer l analyse d un champ. Ils sont atteints au moyen d un status intermédiaire dont la longueur de déplacement est différente de un. Le type du déplacement pour atteindre un portier peut ne pas être en séquence. Exemple d analyse Prenons l exemple d un champ contenant le motif 0x1568 à analyser au moyen de la mémoire trie présentée dans le tableau 23. L analyse commence dans le portier R0 par le quartet de bits 0x1 et renvoie pour résultat le registre intermédiaire R1. L analyse en R1 du quartet 0x5 renvoie le registre intermédiaire R2. L analyse du quartet 0x6 en R2 renvoie le registre intermédiaire R3. Finalement l analyse en R3 du quartet 0x8 renvoie un status final. Afin de faciliter la représentation du contenu de la mémoire trie nous utiliserons par la suite une structure sous forme de graphe où les registres sont représentés par les noeuds du graphe et les transitions présentent le contenu des quartets reconnus. La figure 36 présente la traduction du contenu de la mémoire trie présenté en figure 23 sous forme de graphe. Nous appellerons par la suite ce type de représentation graphe d analyse d un champ. Figure 36. Représentation sous forme de graphe du contenu de la mémoire trie. 0x9 R2 0x7 0x5 0x6 R0 R1 0x1 0x3 0xB R4 0x4 S1 0x2 0x8,0xD R3 0xC S4 S2 S3 S5 Une fois programmée, l analyse utilisant la mémoire trie peut être assimilée à une série de processus d analyse, chacun adapté à l analyse d un champ du flux à analyser. L analyse de chaque champ commence 84

93 Le contrôle d accès dans les réseaux ATM - Mécanismes de contrôle d accès par la reconnaissance d un portier et se poursuit par la reconnaissance des valeurs portées par les transitions représentant le graphe d analyse. Il y a donc au minimum autant de graphes d analyse que de champs à analyser. Les status finaux pouvant être atteints au cours de l analyse indiquent le résultat de l analyse. Pour conclure il faut noter que bien que cela ne soit pas indiqué dans le tableau 23 pour des raisons de clarté, les cases mémoire de la mémoire trie peuvent être initialisées avec un status par défaut qui est utilisé lorsqu une séquence non spécifiée par le graphe d analyse est reconnue. Ce status par défaut peut être différent pour chaque portier, c est à dire pour chaque graphe d analyse. La création des structures d analyse se fait généralement en deux temps. Le premier est la création des portiers (c est à dire des noeuds des graphes d analyse) et le second, le chaînage de portiers entre eux (c est à dire la création des arcs du graphe). De ce fait les opérations réalisables par les cartes IFT sur la mémoire trie comprennent des opérations de création et de suppression de portiers, des opérations d écriture, de lecture et de suppression de valeurs et enfin des opérations d écriture, de lecture et de suppression d intervalles de valeurs. En terme de complexité temporelle, les opérations de lecture et d écriture d une valeur dans une mémoire trie nécessitent w/c opérations où w est la taille en bits du champ à analyser et c la taille en bits de chaque tranche à analyser. La complexité spatiale pour le stockage de la valeur d un champ de taille w est elle de (w/c).2 c.ts où ts est la taille d un status. Il faut cependant noter que le stockage de n valeurs du même champ dans la mémoire nécessite une taille mémoire de la même grandeur et cela quel que soit n Paramètres de contrôle d accès Les cartes IFTs, de par leur vocation première ont été développées pour réaliser du routage à haut débit sur ATM. De ce fait, ces cartes ont été conçues pour traiter des paquets IP. Ceci explique pourquoi le traitement des IFT est limité à celui de trames AAL5. Les cartes IFTs ont la capacité d analyser le contenu de la première cellule de chaque trame AAL5. Ceci signifie que tous les champs présents dans cette cellule peuvent être analysés Niveau ATM Le tableau 24 décrit comment les paramètres de contrôle d accès que nous avions mis en évidence au chapitre 4 peuvent être mis en correspondance avec les capacités d analyse des cartes IFTs au niveau de l en-tête d une cellule ATM. Les champs présentés en grisé sont ceux qui pourraient être utilisés dans le cadre de notre architecture de contrôle d accès. Ces champs permettent de réaliser un contrôle d accès sur le type de flux et les identificateurs de connexion. Cependant en raison de la méthode de construction des cartes IFT qui limite les capacités d analyse aux trames AAL5 contenant des paquets IP, toutes les cellules fournies à la mémoire trie pour analyse correspondent à un flux utilisateur. Tableau 24. Capacités d analyse des cartes IFT au niveau ATM. Bits Champ GFC VPI VCI PT C L P HEC Niveau TCP/IP Le tableau 25 décrit quelles informations issues du chapitre 4 peuvent être analysées par les cartes IFT dans le cas des protocoles CLIP (CLIP1), CLIP sans encapsulation SNAP/LLC (CLIP2), émulation de LAN version 2 (LANE) et Multi protocol over ATM sans tag (MPOA). Les champs UD et TD indiquent le début des segments de donnée pour les protocoles UDP et TCP. Ceci signifie que les cartes IFT ont en général accès aux informations de niveau ATM, IP, TCP et UDP et dans certains cas aux informations de niveau application. 85

94 Le contrôle d accès dans les réseaux ATM - Mécanismes de contrôle d accès Tableau 25. Capacités d analyse des cartes IFT au niveau TCP/IP. Il faut cependant noter que les champs optionnels susceptibles de se trouver dans le paquet IP ne sont pas représentés. La présence de ces champs (de longueur variable) peut repousser les informations de niveau TCP ou UDP dans la seconde cellule ATM. Cependant si on exclut les champs optionnels dédiés aux services de confidentialité ou d authentification tels que ceux spécifiés dans IPSEC, ces champs optionnels sont rarement utilisés. Une étude rapide des paquets échangés sur un lien backbone américain à partir de traces récupérées auprès du NLANR (National Laboratory for Applied Network Research) montre que sur paquets considérés, pas un seul n utilisait un champ optionnel. D autre part certains de ces champs optionnels sont fréquemment utilisés par des attaquants et les paquets IP les utilisant sont généralement bloqués par les firewalls. Nous avons donc choisi de bloquer ceux-ci de manière systématique. Il faut également noter que le protocole considéré dans notre cas est IPv4. L utilisation du protocole IPv6 pose un problème analogue à celui posé par l utilisation d options dans l en-tête des paquets. En effet la taille des adresses IPv6 (128 bits) repousse les informations de niveau transport dans une deuxième cellule Actions Octet CLIP1 AA AA CLIP2 En-tête ATM 45 Longueur LANE AA AA A0 3E 00 MPOA AA AA Octet CLIP1 XX 45 Longueur P CLIP2 P Addr IP Src Addr IP LANE XX MPOA 4C 45 Longueur Octet CLIP1 Addr IP Src Addr IP Dst Port Src Port CLIP2 Dst Port Src Port Dst UD LANE 45 Longueur MPOA P Addr IP Src Addr IP Octet CLIP1 Dst UD D CLIP2 D TD LANE P Addr IP Src Addr IP MPOA Dst Port Src Port Dst UD Octet CLIP1 CLIP2 LANE Dst Port Src Port Dst MPOA D Les actions initialement prévues pour les IFTs consistaient à commuter des cellules, c est à dire à modifier des identificateurs de connexion. Le champ pointeur des status est utilisé pour réaliser cette fonction dans le cas des status finaux en indiquant la nouvelle valeur de VC devant être utilisée. Cette nouvelle valeur de VC est copiée dans l en-tête de toutes les cellules appartenant à la trame AAL5 analysée. Cependant du fait du 86

95 Le contrôle d accès dans les réseaux ATM - Mécanismes de contrôle d accès format du champ pointeur, seul le champ VC peut être modifié. Afin de prendre en compte les fonctions de contrôle d accès pouvant être réalisées par la carte, une fonction additionnelle a été ajoutée permettant de rejeter une trame AAL5 complète lorsque le champ pointeur indique une valeur de VC particulière (0x0000 dans notre cas) Algorithme de classement Nous avons vu en section comment était réalisée l analyse d un champ dans une mémoire trie. Nous allons montrer dans cette section comment il est possible d étendre ce mécanisme à l analyse d un ensemble de champs non adjacents. Le format des règles de contrôle d accès que nous désirons implémenter est une reformulation de celui présenté en section 3.1, chapitre 2: On définit un flux F comme un ensemble de k champs de tailles variables. Le champ i du flux F est noté C i. Une règle R se définit comme un triplet composé d un ensemble d intervalles E(R)={[l 1,r 1 ], [l 2,r 2 ],..., [l k,r k ]}, d une action A(R) et d une priorité P(R). On dit que F correspond à R si quelles que soient la règle R, P(R) > P(R ) et quel que soit le champ C i de F, l i <C i <r i où [l i,r i ] E(R). Il faut noter que les deux formulations sont équivalentes puisqu il est possible de traduire n importe quelle expression régulière en une série d intervalles Algorithme de base Notre méthode de classement est difficilement comparable avec les méthodes de classement déja proposées. Elle est proche de [Gup00a] de par le fait qu elle se base sur l utilisation de segments de mémoire trie mais ne reprend pas le principe de découpage en préfixe maximaux utilisé par cette approche. Elle possède également certains point similaires avec celle proposée par [Gup99] par le fait qu elle utilise une technique de compression de la structure de classement tirant parti de la structure des politiques de contrôle d accès. Cependant notre technique, contrairement à cette dernière approche, a l avantage de permettre le calcul de bornes maximales en terme de complexités spatiale et temporelle. Afin d illustrer notre propos et de faciliter la compréhension du lecteur, nous proposons un exemple montrant le comportement de notre algorithme. Celui-ci est composé de trois règles ordonnées (P(R1) > P(R2) > P(R3)) portant sur deux champs: R1 : (1000 < X < 1200) et (100 < Y < 1000) PERMIT R2 : (300 < X < 1400) et (300 < Y < 600) DENY R3 : (500 < X < 900) et (500 < Y < 900) PERMIT Figure 37. Algorithme de construction de la structure de classement. Build_cs( Cs, Father, Rules, Dimension, Levels) { if (Dimension + 1 > DimensionMax) { foreach R Sort(Rules, ByIncreasingPriority) { if (R.action == PERMIT) { Write_range(Cs.val[Father], R.min, R.max, PERMIT); /* C1 */ } if (R.action == DENY) { Write_range(Cs.val[Father], R.min, R.max, DENY); /* C1 */ } } return; } Compute_intervals(Rules, Dimension, Intervals); /* C0 */ Cs.index = Cs.index + 1; Cs.val[Cs.index] = New_gatekeeper(DENY); /* C2 */ Write_range(Cs.val[Father], I.min, I.max, Cs.val[Cs.index]); /* C4 */ Build_cs( Cs, Cs.index, I.rules, Dimension + 1, Levels); /* C5 */ } 87

96 Le contrôle d accès dans les réseaux ATM - Mécanismes de contrôle d accès La structure de classement est constituée d un ensemble de graphes d analyse tels que celui présenté en figure 40, chaînés entre eux afin de représenter les différentes possibilités exprimées par les règles de contrôle d accès. A partir de cette structure de classement, l algorithme de classement consiste à parcourir les graphes d analyse en présentant à la structure de classement les champs à analyser. La progression dans les graphes se fait en suivant les opérations d indexations et indirections de la mémoire trie implémentant les graphes d analyse comme nous l avons expliqué en section Le résultat est un status final indiquant l action à réaliser. Figure 38. Décomposition des règles et création des intervalles. Y5 Y4 R3 Y3 R2 R1 Y2 Y1 X1 X2 X3 X4 X5 La construction de la structure de classement se fait de manière récursive en suivant l algorithme présenté en figure 37. Cet algorithme utilise plusieurs fonctions annexes dont la sémantique est la suivante: Compute_intervals(Rules, Dimension, Intervals): Calcule les intervalles Intervals formés par l ensemble de règles Rules dans la dimension Dimension. Le calcul des intervalles consiste à projeter les intervalles formés par les règles Rules dans la dimension Dimension dans une seule dimension. A chaque nouveau intervalle I on attribue la règle R si la projection de la règle R dans la dimension Dimension est incluse dans I. La figure 38 présente la projection des trois règles de notre exemple dans les deux dimensions utilisées et les intervalles en résultant. Sort(Rules, type): Crée un ensemble ordonné de règles classées suivant l argument type à partir de l ensemble Rules. Write_range(Father, Min, Max, Son): Ecrit l intervalle borné par Min et Max dans le portier Father de la mémoire trie et fait pointer cet intervalle sur le portier Son. New_gatekeeper(Default): Crée un nouveau portier et lui attribue le status par défaut Default. Figure 39. Graphe d analyse au niveau 1. Analyse de X (R1, R2, R3) X1 X2 X3 X4 X5 Analyse de Y (R2) Analyse de Y (R2, R3) Analyse de Y (R2) Analyse de Y (R1, R2) Analyse de Y (R2) 88

97 Le contrôle d accès dans les réseaux ATM - Mécanismes de contrôle d accès Figure 40. Graphe d analyse au niveau 2. Analyse de Y (R2) Analyse de Y (R2, R3) Analyse de Y (R1, R2) R2 R2 R3 R1 DENY DENY PERMIT PERMIT L algorithme fonctionne de la manière suivante. Une fois calculés les intervalles élémentaires (C0), on utilise ceux-ci pour construire le graphe d analyse. Pour cela on considère chaque intervalle et on crée pour celui-ci un portier que l on insère dans la structure de classement Cs (C2). Ce portier est créé avec un status par défaut appelé DENY correspondant à un rejet de la trame. On fait ensuite le lien entre le portier venant d être créé et son portier père en écrivant dans le portier père l intervalle relatif à son fils (C4). On passe ensuite à la dimension suivante, c est à dire au champ suivant afin de poursuivre la construction de la structure de classement avec les règles présentes dans l intervalle considéré (C5). Figure 41. Algorithme de construction de la structure de classement (avec compression). Build_cs( Cs, Father, Rules, Dimension, Levels) { if (Dimension + 1 > DimensionMax) { foreach R Sort(Rules, ByIncreasingPriority) { if (R.action == PERMIT) { Write_range(Cs.val[Father], R.min, R.max, PERMIT); /* C1 */ } if (R.action == DENY) { Write_range(Cs.val[Father], R.min, R.max, DENY); /* C1 */ } } return; } Compute_intervals(Rules, Dimension, Intervals); /* C0 */ foreach I Intervals { Found = False; for (i = 0;i < Levels.index[Dimension + 1]; i = i + 1) { if (Cs.info[Levels.val[Dimension][i]].rules == I.rules) { /* C3.1 */ Found = TRUE; /* C3 */ Where = Levels.val[Dimension][i] ; /* C3.2 */ } } if (Found!= TRUE) { Cs.index = Cs.index + 1; Cs.val[Cs.index] = New_gatekeeper(DENY); /* C2 */ Cs.info[Cs.index] = I; /* C3 */ Levels.val[Dimension][Levels.index[Dimension] = Cs.index; /* C3 */ Levels.index[Dimension] = Levels.index[Dimension] + 1; /* C3 */ Write_range(Cs.val[Father], I.min, I.max, Cs.val[Cs.index]); /* C4 */ Build_cs( Cs, Cs.index, I.rules, Dimension + 1, Levels); /* C5 */ } else { Write_range(Cs.val[Father], I.min, I.max, Cs.val[Where]); /* C3.3 */ } } } 89

98 Le contrôle d accès dans les réseaux ATM - Mécanismes de contrôle d accès Dans le cas où l on a atteint la dernière dimension de l analyse, on attribue au portier père un status désignant l action correspondant aux règles restantes. Afin de privilégier les règles les plus prioritaires on écrit celles-ci en dernier de telle sorte que leur écriture écrase les valeurs des règles non prioritaires (C1). Les parties correspondant aux commentaires C3 sont utilisées plus avant dans ce document et seront expliquées par la suite. Les figures 39 et 40 indiquent le graphe d analyse formé à partir de l exécution de notre algorithme sur les règles données en exemple. La figure 40 ne présente que le traitement des arcs distincts, les arcs similaires n étant pas représentés pour des raisons de clarté. Leur traitement est cependant réalisé au cours de la construction du graphe d analyse Compression de la structure de classement Les figures 39 et 40 montrent que certaines parties du graphe d analyse sont semblables. Ces réplications peuvent créer un graphe de grande taille et empêcher son stockage en mémoire trie. C est pour cela que nous proposons de compresser certaines parties du graphe de telle sorte que les noeuds similaires soient remplacés par un seul noeud au moment de la construction du graphe d analyse. La figure 41 présente l algorithme de construction de la structure de classement en incluant cette fois le processus de compression. Celui-ci noté C3 fonctionne de la manière suivante. Au moment de la création de fils on cherche tout d abord si un intervalle portant sur les mêmes règles de classement a déjà été traité dans la même dimension (C3.1). On cherche également le portier correspondant (C3.2). Pour cela on utilise une structure (Levels) qui stocke tout les portiers par niveau dans la structure de classement (C3). Dans le cas ou un portier existe déjà on crée un lien entre celui-ci et le père courant (C3.3). Dans le cas contraire on suit la procédure normale en créant un nouveau portier. La figure 42 indique le résultat de l utilisation de l algorithme utilisant la compression dans le cas de notre exemple. Comme on peut le voir cette compression permet une réduction importante de la taille de la structure de classement. Figure 42. Compression de la structure de classement. Analyse de X (R1,R2,R3) Analyse de Y (R2, R3) Analyse de Y (R2) Analyse de Y (R1, R2) PERMIT DENY Complexités de l algorithme de classement Il est relativement simple d exprimer les complexités spatiale et temporelle de l algorithme que nous proposons, celles-ci dépendant de la structure de classement dont nous venons de montrer la méthode de construction. La complexité temporelle correspond à la profondeur de la structure de classement. Celle-ci dépend uniquement du nombre de champs utilisés par les règles de contrôle d accès. Si on suppose que la taille des champs est constante et égale à w bits, que l on désire analyser un nombre de k champs et que le motif de reconnaissance de la mémoire trie est de c bits, la complexité temporelle peut s exprimer de la façon suivante: CT = O( w k ) c 90

99 Le contrôle d accès dans les réseaux ATM - Mécanismes de contrôle d accès Ceci est à notre connaissance, la meilleure complexité temporelle jamais proposée pour un algorithme de classement à complexité spatiale non exponentielle. La complexité spatiale dépend elle du nombre de champs, mais également du nombre de règles et est égale à la taille de la structure de classement. Celle-ci comprend au maximum k niveaux formés de N intervalles. La valeur de N est bornée par le nombre maximum d intervalles pouvant être formés à partir des règles correspondant aux intervalles existant dans la dimension précédente. Pour n règles, celui-ci est au plus égal à (2n + 1) i dans la dimension i ([Lak98]). La complexité spatiale peut donc être bornée par: où on suppose que la taille des champs est constante et égale à w bits, que l on désire analyser un nombre de k champs, que le motif de reconnaissance de la mémoire trie est de c bits, que la politique de contrôle d accès est formée de n règles et que ts est la taille d un status. Cette complexité est pessimiste par le fait qu elle ne prend pas en compte la compression réalisée aux différents niveaux de la structure de classement. Nous montrons en section que la taille réelle utilisée pour le stockage de la politique de contrôle d accès est dans la pratique bien inférieure à celle donnée par la complexité spatiale théorique. Ceci s explique par le fait que dans la pratique, N est souvent largement inférieur à (2n + 1) k. Un des inconvénients majeurs de notre algorithme de classement vient du fait que l insertion de nouvelles règles de contrôle d accès ne se fait pas facilement. Il peut en effet être nécessaire de recalculer l ensemble de la structure de classement si l on désire ajouter une nouvelle règle dont un des intervalles rentre en intersection avec l ensemble des intervalles décrits par les règles déjà présentes. Comme ce calcul peut être relativement long (plusieurs minutes), notre algorithme est principalement dédié à des politiques de contrôle d accès statiques. C est la raison pour laquelle nous isolons dans l architecture que nous présentons dans le chapitre suivant la partie dynamique de notre politique concernant les connexions ATM, d une partie statique concernant la politique de contrôle d accès TCP/IP Architecture Approche générale k c w CS = ts ( 2 n+ 1) i c = O2 ( c w --- ts ( 2 n + 1) c k ) i = 1 Comme indiqué en figure 43, notre architecture de contrôle d accès se place comme un pare-feu classique entre un réseau interne à protèger et un réseau externe jugé non sûr. Le contrôleur peut tout aussi bien être la propriété d un opérateur de réseau souhaitant protèger son réseau que d une entreprise souhaitant protèger ses équipements privés. L architecture de notre contrôleur ([Sim00]) est composée de deux parties principales. La première est dédiée à l'analyse de la signalisation ATM. Le résultat de cette analyse est utilisé pour construire dynamiquement une configuration. Celle-ci est utilisée par la seconde partie de notre architecture pour fournir un service de contrôle d'accès basé sur les informations transportées dans les cellules ATM. La seconde partie est capable de récupérer les informations de niveaux ATM et transport afin de décider si une communication doit être autorisée ou interdite. La configuration de l'ensemble se fait au moyen d'un langage unique. Ce langage unique correspond au langage de bas niveau présenté en section 2.1, chapitre 6. 91

100 Le contrôle d accès dans les réseaux ATM - Mécanismes de contrôle d accès Figure 43. Architecture générale de la maquette CARAT. Station SUN Gestionnaire Analyseur de Signalisation PC Solaris Démon Driver IFT ATM ATM IFT IFT Contrôleur Switch ATM Réseau Interne Réseau Externe Module de gestion La politique définie par l'officier de sécurité en utilisant ce langage est utilisée pour configurer les deux parties du contrôleur. Cependant cette politique ne peut pas être utilisée directement par les deux outils de contrôle d'accès. Le gestionnaire est le module qui permet de résoudre ce problème en traduisant la politique de contrôle d'accès en commandes de configuration pour nos deux outils. Le processus de traduction est décrit figure 44. Celui-ci peut être divisé en deux parties. La première est la traduction de la politique en trois configurations statiques: Au niveau de la signalisation ATM, cette configuration comprend une description des communications devant être contrôlées. Chaque communication est décrite par un ensemble d'éléments d'information (IEs) et par une action (Autoriser ou Interdire). Cette configuration est envoyée à l'analyseur de signalisation. Au niveau TCP/IP la configuration comprend une description des paquets devant être contrôlés. Cette partie de la politique est générique ce qui signifie que les règles qui y sont décrites ne sont pas dédiées à une connexion ATM particulière. Au niveau cellule, la configuration comprend une description des cellules qui doivent être contrôlées. Ces cellules sont divisées selon les champs qu'elles peuvent contenir. L'ensemble des valeurs que chaque champ peut prendre est décrit par un graphe. Cette configuration statique est envoyée aux cartes IFT. La seconde partie du processus de configuration a lieu lorsqu'une demande de connexion ATM est reçue par l'analyseur de signalisation. Une fois que le processus de contrôle d'accès a été réalisé, l'analyseur de signalisation envoie au gestionnaire les informations nécessaires pour effectuer la configuration dynamique des cartes IFT. Les informations fournies par l'analyseur de signalisation comprennent: Les identificateurs de connexion Vpi et Vci. Un descripteur de service (Classical IP over ATM ou CLIP, Applications natives ATM). Quand une couche supplémentaire est utilisée au dessus du modèle ATM, l'analyseur de signalisation fournit également l'encapsulation (avec ou sans en-tête SNAP /LLC). La direction de la communication (C est à dire si la communication provient du réseau interne ou du réseau externe). 92

101 Le contrôle d accès dans les réseaux ATM - Mécanismes de contrôle d accès Figure 44. Génération de la politique de contrôle d accès. Information de signalisation Informations dynamiques de niveaux cellule et IP Politique de contrôle d accès sur la signalisation Politique de contrôle d accès générique TCP/IP Politique de contrôle d accès Politique de contrôle d accès dynamique de niveau cellule Politique de contrôle d accès statique de niveau cellule Politique de contrôle d accès de niveau cellule Cet ensemble d'informations est utilisé par le gestionnaire afin de réaliser la configuration des cartes IFT. Il est conservé durant toute la vie de la connexion. A la fermeture de connexion, le gestionnaire reçoit un signal de l'analyseur de signalisation afin de reconfigurer les IFT en effaçant les informations relatives à la connexion. Le gestionnaire détruit ensuite les informations qui y sont associées Module d analyse et de filtrage de la signalisation L'analyseur de signalisation se base sur deux fonctions. La première est la redirection des messages de signalisation provenant des réseaux internes et externes vers un filtre situé dans une station SUN. Le second est la capacité de décomposer les messages de signalisation suivant la spécification UNI 3.1 de l'atm Forum [UNI31] et de transmettre ou de jeter ces messages en fonction de la configuration de contrôle d'accès fournie par le gestionnaire. Afin de rediriger la signalisation, le commutateur ATM doit être reconfiguré afin de rediriger les messages de signalisation vers une station SUN comme le montre la figure 45. Cette configuration peut être réalisée en désactivant le protocole de signalisation sur les interfaces 1, 2, 3 et 6. Un VC permanent doit ensuite être construit entre chaque paire d'interfaces pour chaque canal de signalisation. Ces canaux sont identifiés par un vci égal à 5. Figure 45. Configuration du commutateur ATM pour la signalisation ATM. Station SUN Réseau Interne 1 Switch ATM 6 Réseau Externe Avec la configuration précédente, les messages de signalisation provenant du réseau externe sont dirigés vers l'interface 1 de la station SUN alors que les messages provenant du réseau interne sont dirigés vers 93

102 Le contrôle d accès dans les réseaux ATM - Mécanismes de contrôle d accès l'interface 0. Comme le montre la figure 46, tous les messages de signalisation sont traités par le module Q93B. La fonction de ce module est d'établir, contrôler et fermer les connexions ATM. Les messages de signalisation n'étant normalement pas destinés à la station SUN, il est nécessaire de modifier le module Q93B afin que celui-ci transmette les messages à un filtre de niveau application sans les analyser. Pour différencier le filtrage des messages selon qu'ils viennent de l'extérieur ou de l'intérieur, ceux-ci sont associés à leur interface ATM d'origine. Cette information est fournie au filtre applicatif par le module Q93B. Lorsque des messages de signalisation sont reçus par l'analyseur de signalisation, ceux-ci sont décomposés par le module de décomposition des messages en éléments d'information suivant la spécification UNI 3.1. Les éléments d'information sont ensuite décomposés en informations basiques telles que les adresses, les identificateurs de connexion, la référence d'appel, les descripteurs de qualité de service et les identificateurs de service. L'analyseur cherche ensuite si le message peut être associé à une connexion existante au moyen du type du message et de la référence d'appel. Si la connexion est nouvelle, un descripteur de connexion contenant ces informations est construit. Quand la connexion existe déjà, le descripteur de connexion est mis à jour. Le descripteur de connexion est associé à l'état de la connexion, l'interface d origine et est identifiée par un identificateur de connexion. Le descripteur est ensuite envoyé au filtre. Lorsque le filtre reçoit un descripteur de connexion, il compare les paramètres décrivant la connexion avec l'ensemble des communications décrit par la politique de contrôle d'accès. Si une correspondance est trouvée le filtre applique l'action associée à la communication. Dans le cas contraire, il applique l'action par défaut qui est d'interdire la connexion. Lorsque l'action consiste à interdire la communication, le filtre détruit le descripteur de connexion. Dans le cas contraire, il envoi le descripteur de connexion au module de construction des messages. Lorsque l'analyseur de signalisation reçoit un message CONNECT indiquant que la connexion est établie, un sous-ensemble des paramètres du descripteur de connexion est envoyé au gestionnaire comme indiqué dans la section précédente. Les identificateurs de connexion Vci et Vpi sont obtenus à partir de l'ie Connection Identifier. Les descripteurs de service sont obtenus à partir des IEs Broadband Higher Layer Identifier (BHLI) et Broadband Lower Layer Identifier (BLLI). La direction est fournie par le nom de l'interface associée au descripteur de connexion. Figure 46. Filtrage de la signalisation. Filtre D écom position des m essag es de sig. Construction des m essag es de sig. Espace U tilisateur M odu le Q 93B M odu le S S C O P M odu le S S C O P Interface ATM 0 Interface ATM 1 Station SUN Noyau 94

103 Le contrôle d accès dans les réseaux ATM - Mécanismes de contrôle d accès Lorsque l'analyseur de signalisation reçoit un message RELEASE COMPLETE indiquant que la fermeture de la connexion, il envoie de nouveau le descripteur de connexion au gestionnaire. Les communications entre le gestionnaire et l analyseur de signalisation se font directement étant donné que le gestionnaire et l analyseur de signalisation sont actuellement intégrés dans un même logiciel. Une autre fonctionnalité fournie par le filtre est sa capacité à modifier l'adresse ATM source lorsqu'une communication provient du réseau ATM interne afin de cacher la structure topologique interne du réseau. Cette fonctionnalité est réalisée en changeant l'adresse ATM source par l'adresse de l'interface ATM externe de la station (interface 1). Lorsque le module de construction des messages reçoit un descripteur de connexion, il construit un nouveau message de signalisation à partir des informations contenues dans le descripteur. Le message est ensuite associé à une interface de sortie et envoyé au module Q93B. Lorsque l'état associé à la connexion indique qu'un message RELEASE COMPLETE a été reçu pour libérer la connexion, le module libère les ressources associées au descripteur de connexion Module d analyse de niveau cellule La première partie du processus de contrôle d'accès au niveau cellule consiste à rediriger le trafic provenant des réseaux internes et externes vers les cartes IFT. Cependant dans ce cas la configuration doit préserver la configuration réalisée pour le contrôle de la signalisation. Le commutateur ATM doit donc être configuré afin de créer un canal virtuel pour chaque valeur de vci différente de 5 entre chaque paire d'interfaces (1, 4 et 5, 6) comme indiqué en figure 47. Le canal virtuel actuellement utilisé est de type UBR ce qui signifie qu aucune qualité de service n est garantie dans le commutateur pour les connexions contrôlées. Nous estimons que ce manque de garantie à l intérieur du commutateur ne devrait pas avoir un impact important sur la qualité de service de bout en bout par le fait que la quasi totalité du trafic est commuté entre les ports 6 et 1. Il y a donc peu de cas où une bufferisation due à un blocage est nécessaire. Il serait cependant relativement facile de modifier notre analyseur de signalisation pour qu il réalise une configuration dynamique du commutateur soit au travers de l interface de configuration en mode texte, soit au travers d un protocole de type GSMP (General Switch Management Protocol, [RFC1987]). Cette configuration dynamique permettrait de prendre en compte les paramètres de qualité de service négociés au travers de la signalisation. Les cartes IFT ne permettent que l'analyse de flux unidirectionnels. Ceci signifie que les flux provenant des réseaux interne et externe doivent être séparés. Cette opération est particulièrement simple dans le cas d'une couche physique de type fibre optique monomode utilisée par les cartes puisque les fibres d'émission et de réception sont physiquement séparées. La figure 47 montre comment les fibres de réception et d'émission doivent être connectées entre les cartes et les ports du commutateur. Figure 47. Configuration du commutateur ATM pour le trafic utilisateur. PC Solaris IFT 0 IFT Switch ATM 95

104 Le contrôle d accès dans les réseaux ATM - Mécanismes de contrôle d accès La seconde partie est la configuration des cartes IFT afin qu'elles fournissent le service de contrôle d'accès désiré. Comme nous l'avons dit précédemment, cette configuration est faite par le gestionnaire. Les cartes IFT ont été conçues à l'origine pour être gérées à distance par plusieurs gestionnaires. En conséquence un logiciel implémentant des fonctions de configuration invocables à distance (démon RPC) a été développé par France Telecom R&D afin de sérialiser les requêtes auprès du driver des cartes. Du côté du gestionnaire, une librairie donne accès aux fonctions de configuration. Cette librairie traduit les appels locaux en appels à distance sur le PC Solaris. Les communications entre les deux équipements se font au travers d'un réseau dédié ethernet. Le classement des cellules en fonction de la politique de contrôle d accès fournie par le gestionnaire est un processus en trois phases. Chacune de ces phases correspond à un niveau protocolaire. Encapsulations Le type d encapsulation est géré de manière statique. On crée à l initialisation du processus de configuration de la mémoire trie un portier dans lequel on écrit les différentes encapsulations possibles (CLIP avec encapsulation SNAP/LLC, CLIP sans encapsulation SNAP/LLC, LANE, MPOA) associées au déplacement nécessaire pour atteindre le champ version du paquet IP. Ce déplacement est variable en fonction de l encapsulation utilisée. Les encapsulations non reconnues sont associées à un déplacement permettant d analyser le champ vci (portier VCI0). Niveau TCP/IP Les segments de mémoire trie correspondant à l analyse des protocoles TCP/IP sont construits en utilisant l algorithme de construction de la structure de classement présenté en section 3.2. Celui-ci assure la construction des portiers et leur chaînage. Les champs considérés pour la construction de la structure de classement sont les champs version, longueur de l en-tête IP, adresses IP source et destination, ports sources et destination, drapeaux TCP et les champs type et code ICMP. Le chaînage débouche sur les actions relatives aux règles analysées. En fonction de l action spécifiée par l analyse, la trame peut être traitée suivant les actions spécifiées en section afin de provoquer son rejet ou sa commutation. Afin de réaliser une commutation correcte, il convient de déterminer la valeur de vci utilisée. De ce fait l analyse du champ vci au niveau ATM est réalisée en dernier (portier VCI1). Figure 48. Ordre d analyse des champs. SNAP/LLC TCP/IP TCP/IP Paramètres TCP/IP Acceptation Rejet Encapsulation Autre Vci Dynamiques Vci Statiques ATM (VCI1) (VCI0) Niveau ATM Au niveau ATM, les cellules sont classées en fonction du champ VCI. Pour cela on attribue à la reconnaissance de ce champ deux portiers VCI0 et VCI1 dans la mémoire trie. Initialement, on attribue aux deux les informations concernant les connexions statiques déclarées dans la politique de contrôle d accès en écrivant les valeurs de VCI autorisés dans le portier. Le second portier est mis à jour en fonction des créations et fer- 96

105 Le contrôle d accès dans les réseaux ATM - Mécanismes de contrôle d accès metures de connexion au moyen des informations fournies par l analyseur de signalisation en écrivant et supprimant les valeurs de VCI dans le portier. L ordre d analyse des champs est résumé en figure Implémentation Une implémentation correspondant à l architecture présentée en section précédente a été réalisée ([Gue00]). Celle-ci a permis de tester les différents composants. Ceux-ci ont été testés de manière individuelle afin d évaluer leurs performances propres et de manière simultanée afin de vérifier le bon fonctionnement global de la maquette. Vis à vis de l architecture présentée en figure 43, les éléments présentés sont implémentés au moyen des équipements suivants: un switch Fore ASX 200BX, une station SUN Sparc 5, un PC Solaris Pentium III 600 Mhz et deux stations Linux Pentium III 600 Mhz. Les stations Linux et la station SUN Sparc sont reliées au switch au moyen de liens SDH OC3. Les cartes IFTs placées dans le PC solaris sont elles connectées au switch au moyen de deux liens SDH OC12. Une partie des logiciels développés (en particulier le filtre de signalistion ATM) est disponible de manière publique sur [Pa00f] Tests de l analyseur de signalisation L analyseur a été testé au moyen d un programme générant des simulations de connexions en ouvrant puis refermant des connexions et passant par tous les états intermédiaires. Chaque simulation entraîne de ce fait l échange de 5 messages de signalisation (SETUP, CALL PROCEEDING, CONNECT, CONNECT ACK, RELEASE COMPLETE). Des mesures ont été réalisées sur plusieurs séries de plus de 500 simulations en testant différentes configurations de filtrage allant d une configuration sans filtrage jusqu à une configuration de notre analyseur de signalisation avec 500 règles de filtrage. La partie sans filtrage correspond à une connexion directe des deux machines sans que les communications ne passent ni par le switch ni par l analyseur de signalisation. Le résultat de ces mesures est montré dans le tableau 26. Les résultats montrent tout d abord que l utilisation de notre analyseur a un impact relativement faible sur les délais expérimentés par les simulations de connexion. Ces délais sont compris entre 20 et 45 ms en moyenne, c est à dire entre 4 et 9 ms en moyenne par message de signalisation. Ces valeurs sont très largement acceptables si on les compare avec les délais autorisés par les normes concernant la signalisation ([UNI3.1]) dans lesquels les délais sont de l ordre de quelques secondes à plusieurs dizaines de secondes. On peut par ailleurs noter que le nombre de règles utilisées ne provoque qu une faible augmentation du délai introduit par l analyseur. Tableau 26. Durée d une simulation de connexion en fonction du filtrage réalisé. Nombre de règles Temps moyen Temps maximal Temps minimal Sans filtre 47 ms 198 ms 24 ms ms 192 ms 34 ms ms 177 ms 38 ms ms 275 ms 47 ms Les chiffres donnés dans le tableau 26 montrent que notre analyseur peut traiter entre 18 et 150 messages de signalisation par seconde en fonction de sa configuration. Ces performances peuvent sembler décevantes comparées aux capacités de traitement des commutateurs actuels qui sont généralement capables de traiter plusieurs centaines de messages de signalisation par seconde ([ASX200]). Cependant elles sont à rapporter au matériel utilisé qui est relativement vieux. Les stations SUN actuelles fournissent des performances jusqu à dix fois supérieures à celles de la Sparc 5 que nous utilisons. Des stations plus récentes nous permettraient par ailleurs d utiliser des drivers plus récents assurant de meilleures performances. Enfin dans le cas ou de telles modifications ne suffiraient pas pour permettre l analyse de tout le trafic de signalisation généré par un site, il est possible de partager la charge de l analyse de signalisation entre plusieurs analyseurs connectés au switch 97

106 Le contrôle d accès dans les réseaux ATM - Mécanismes de contrôle d accès et vers lesquels on dirige une partie de la signalisation en fonction de l identificateur de VP auquel elle est associée. La cohérence des informations analysées est dans ce cas garantie par le fait que chaque analyseur traite tous les messages associés à un VP et qu il n y a pas de relation entre les messages émis sur différents VPs. De telles mesures devraient permettre d assurer le traitement de tous les messages de signalisation générés par un site du fait que la bande passante attribuée à ceux-ci est généralement limitée à 1% de la bande passante du lien physique associé ([Q2931]) Tests des IFTs Performances Les performances des cartes IFTs sont limitées par deux facteurs présentés en figure 49. Le premier est le type de connecteur physique liant les cartes IFTs au processus d analyse des cellules. Le type de support physique supporté par ce connecteur est actuellement de type SDH OC12 ce qui limite le débit supporté par le connecteur à 620 Mb/s. Le débit utile offert à la couche ATM est lui inférieur au débit nominal du fait du mode d encapsulation des cellules ATM dans les PDUs utilisées par la couche physique et est égal à 599 Mb/ s ([Rol99]). Figure 49. Processus de fonctionnement des IFTs. Mémoire Trie IFT Flux Connecteur Physique Processus d analyse Connecteur Physique La seconde limite aux performances des cartes IFTs provient de l algorithme de classement présenté en section 3.2. Comme nous l avons précisé, la vitesse de classement de notre algorithme ne dépend que du nombre de champs, de la taille des champs analysés et de la taille du motif reconnu à chaque cycle. Dans notre cas, la taille du motif est de 4 bits. Le nombre de champs est au maximum de 9. De ce fait, comme détaillé dans le tableau 27, la durée maximale d analyse en prenant en compte les différents champs pouvant être analysés, les différents types de sauts entre champs (les sauts entre champs non adjacents appelés dans le tableau sauts relatifs prennent plus de temps que les sauts séquenciels entre champs adjacents) et les pénalités de début et de fin de processus est de 51 cycles. Tableau 27. Calcul du temps maximal d analyse. Champ Taille (bits) Type de saut Nombre de cycles Pénalités d entrée et de sortie 2 Encapsulation 4 Relatif 5 Version 4 Séquenciel 1 Longueur 4 Relatif 5 Adresse Source 32 Séquenciel 8 Adresse Destination 32 Séquenciel 8 Port Source 16 Séquenciel 4 Port Destination 16 Relatif 8 Drapeaux TCP 8 Relatif 6 98

107 Le contrôle d accès dans les réseaux ATM - Mécanismes de contrôle d accès Champ Taille (bits) Type de saut Nombre de cycles VCI 16 / 4 TOTAL 51 Le temps de cycle actuellement proposé par le circuit d analyse des IFTs, basé sur l utilisation de composants FPGA (Field-Programmable Gate Arrays) et d une mémoire de type ZBT (Zero Bus Turnaround) est de 15 ns ([IFT10]). Il est cependant envisagé dans le futur d utiliser des composants permettant un temps de cycle de 12ns. Le tableau 28 indique les temps d analyse, les vitesses de classement et les vitesses de commutation minimales correspondant à ces deux latences en prenant en compte une taille minimale à analyser de la taille d une cellule soit 53 octets. Tableau 28. Capacités de classement en fonction de la latence du circuit d analyse. Latence Circuit Temps d analyse Vitesse min. de classement Débit min. de classement DoS 12 ns 612 ns Mc/s Mb/s >100% 15 ns 765 ns Mc/s Mb/s 99% Dans le cas d une latence du circuit de 12 ns, on peut donc considérer que notre processus de classement n est pas l élément bloquant dans notre architecture de contrôle d accès, celle-ci étant limitée par le débit physique du connecteur. Il en découle que notre processus de classement ne peut provoquer la bufferisation de cellule avant leur classement puisque le processus de classement est plus rapide que l arrivée des cellules. De ce fait le délai maximal introduit par notre processus de classement est égal au temps maximal d analyse, c est à dire 648 ns. Dans le cas d une latence des composants de 15 ns la propriété précédente n est plus vraie puisque le processus de classement peut être plus lent que le rythme d arrivée des cellules. Il est donc intéressant dans ce cas de s intéresser à la capacité de notre architecture à résister aux attaques en dénis de service basées sur la saturation de notre processus de classement. Le tableau 28 indique la partie du trafic devant être générée par des attaquants afin de provoquer un trafic global dépassant les capacités de classement du classificateur (DoS). La partie du trafic généré par les attaquant est supposé présenter les contraintes les plus strictes pour notre outil (un paquet par cellule dans lequel l analyse de tous les champs est nécessaire). La partie du trafic non générée par les attaquants est supposée avoir des caractéristiques normales (c est à dire une taille moyenne de paquet IP de 400 octets). Même si l on prend en compte les possibilités de dénis de service répartis aujourd hui réalisable, la génération d une telle quantité de trafic parait peu réaliste. Comme la vitesse de classement est plus faible que le débit soumis par le connecteur physique, il peut être nécessaire de bufferiser les cellules devant être classées. De ce fait une mémoire de 154 cellules (8192 octets) est utilisée dans l IFT pour stocker les cellules en attente de traitement ([IFT10]). Le délai maximal introduit par le processus de classement est donc de 155 traitements de cellule soit µs. La configuration de notre plate-forme actuelle de test ne nous a pas permis de tester les limites des performances de notre algorithme de classement en terme de complexité temporelle. En effet les stations linux présentées en figure 43 sont connectées au switch au moyen d un lien OC3 à 155 Mb/s. Elles ne peuvent donc à aucun moment fournir au processus de classement un débit que celui-ci pourrait ne pas être capable de supporter. Utilisation mémoire Un point intéressant sur lequel nos tests ont porté est la complexité spatiale atteinte par notre algorithme de classement. Pour cela nous avons testé différentes politiques de contrôle d accès et examiné la place prise par notre structure de classement. Afin de réaliser des politiques de contrôle d accès réalistes nous nous sommes basés sur des exemples de politiques fournis par [Che94] et [Cha95] ainsi que sur la politique de contrôle 99

108 Le contrôle d accès dans les réseaux ATM - Mécanismes de contrôle d accès d accès implémentée par une grand fournisseur d accès internet français. Le tableau 29 fournit les résultats relatifs à ces tests. Le nombre de portiers utilisés dans chaque dimension permet d évaluer la taille totale de la mémoire utilisée en prenant en compte la taille des champs rattachés à chaque dimension. Note 1: Dimension des portiers: 1-Protocole, 2-Adresse source, 3-Adresse destination, 4-Port source TCP, Port source UDP et champ type ICMP, 5-Port destination TCP, 6-Drapeaux TCP, 8-Port destination UDP, 10-ICMP code. Note 2: Conformément à l algorithme, les portiers sont décalés d une dimension vis à vis des champs. Note 3: Les portiers 1 et 2 ne sont pas présentés car le nombre de portiers qui leur est associé est fixe et inférieur à 3. Note 4: Les dimensions 7, 9 et 11 correspondent à des dimensions finales, il ne leur est donc pas associé de portier. Comme on peut le voir la mémoire trie actuellement utilisée (4 Mo) a la capacité de stocker des politiques de contrôle d accès de tailles relativement importantes (plusieurs milliers de règles) Conclusion Tableau 29. Utilisation mémoire. Politique testée Nombre de règles Nombre de portiers Taille mémoire totale [Che94], [Cha95] , 4-10, 5-21, 6-41, 7-0, 8-9, 9-0, 10-6, 21 ko , 4-922, , ,7-0, 8-921, ko 0, 10-63, , , , , 7-0, , 3197 ko 9-0, 10-81, , , , , 7-0-, ko 3440,9-0, , 11-0 Fournisseur d accès Internet , 4-150, 5-73, 6-0, 7-0, 8-39, 9-0, 10-0, 76 ko , , 5-419, 6-456, 7-0, , 1270 ko 9-0, , , , , , 7-0, ko 1640, 9-0, , , , , , 7-0, ko 1640, 9-0, , , , , , 7-0, ko 2400, 9-0, , , , , , 7-0, , 9-0, , ko Dans cette section nous avons démontré au travers de tests la capacité de notre architecture synchrone et centralisée à être implémentée. Nous avons également décrit les performances d une telle architecture. Ces performances assurent d une part que notre architecture a la capacité d assurer le filtrage au niveau cellule à un débit au moins égal à 554 Mb/s et cela en assurant un délai maximal de filtrage de µs. Ces performances sont garanties, quelle que soit la taille et la composition des paquets à analyser, et quelle que soit la composition de la politique de contrôle d accès. Ces propriétés permettent de garantir que notre architecture n est pas sensible aux dénis de service auxquels étaient sensibles les solutions basées sur l utilisation de mémoire cache que nous avons présentées au chapitre 3, sections 4.2 et 4.3 puisque les performances que nous donnons correspondent aux performances minimales. D autre part vis à vis des contraintes de qualité de service, notre architecture assure un délai d analyse d un ordre de grandeur supérieur à celui d un commutateur ATM classique qui assurent généralement un temps de commutation moyen de l ordre d une dizaine de 100

109 Le contrôle d accès dans les réseaux ATM - Mécanismes de contrôle d accès micro-secondes ([ASX200]). Le temps maximal d analyse d une cellule est par ailleurs comparable au délai introduit par le transport de celle-ci sur un lien fibre optique de 20 km (130 µs). Tableau 30. Complexités spatiales et capacités de classement en fonction du nombre de règles et de la largeur des champs de la mémoire trie pour k = 6 et c = 32. n / w [21ko][4.2Mp/s] [168ko][8.4Mp/s] [1.8Mo][12.6Mp/s] [21Mo][16.8Mp/s] [272Mo][22.2Mp/s] 100 [76ko][4.2Mp/s] [608ko][8.4Mp/s] [6.5Mo][12.6Mp/s] [76Mo][16.8Mp/s] [960Mo][22.2Mp/s] 750 [1.4Mo][4.2Mp/s] [11Mo][8.4Mp/s] [123Mo][12.6Mp/s] [1.5Go][16.8Mp/s] [19Go][22.2Mp/s] 5000 [1.3Mo][4.2Mp/s] [11Mo][8.4Mp/s] [110Mo][12.6Mp/s] [1.3Go][16.8Mp/s] [16Go][22.2Mp/s] [6.2Mo][4.2Mp/s] [50Mo][8.4Mp/s] [529Mo][12.6Mp/s] [6.1Go]16.8Mp/s] [78Go][22.2Mp/s] Nous avions montré en section que la complexité temporelle de notre algorithme de classement ne permettait pas en théorie l utilisation de politiques de contrôle d accès de grande taille dans le cas d un classement sur un grand nombre de paramètres. Nous montrons dans cette section au travers d exemples qu il est possible grâce à l utilisation de notre méthode de compression d utiliser notre algorithme de classement dans le cas d un nombre important de paramètres de classement (9) et cela en combinaison avec des politiques de contrôle d accès de taille importante (plusieurs milliers de règles). Le tableau 30 montre la taille nécessaire (en milliers d octets - ko, millions d octets - Mo ou milliards d octets - Go) ainsi que les capacités de classement (en millions de paquets par seconde - Mps) de notre structure de classement en fonction de la largeur des champs d analyse de la mémoire trie (w) et du nombre de règles (n), pour un nombre de champs (d) égal à 6 et une taille de champ (c) égale à 32. La taille nécessaire est calculée à partir des tests effectués en section précédente afin d évaluer le nombre N de portiers utilisés à chaque niveau de la structure de classement. Les capacités de classement sont évaluées à partir de la complexité temporelle donnée en section Le tableau montre en grisé les capacités de classement réalistes de notre structure de classement. Celles-ci varient de 4.2 Mp/s à 16.8 Mp/s suivant le nombre de règles utilisées. La construction d une mémoire trie d une taille correspondant à ces performances pourrait se faire en utilisant un type de mémoire SRAM classique (Static Random Access Memory) à la place de la mémoire de type SRAM ZBT actuellement utilisées. Celui-ci autorise des mémoires de tailles moyennes (plusieurs Mo) à des coûts limités (50 $ par Mo) tout en permettant des temps d accès très faibles (5 ns). L utilisation d un tel mécanisme de classement autorise le classement de paquets à des débits allant de 1344Mb/s (4.2 Mp/s de 40 octets) à 54Gb/s (16.8 Mp/s de 400 octets). Cependant ce type de mémoire est généralement plus complexe à mettre en oeuvre que les mémoires de type ZBT par le fait qu il demande une gestion des cycles inutilisables (dead cycles) entre lectures et écritures en mémoire [Mot98]. Tableau 31. Comparaison des différentes méthodes de classement. Technique Avantages Inconvénients Algorithme Linéaire Complexité spatiale faible. Complexité temporelle élevée. Marche pour n importe quel nombre de champs. CAM Complexité temporelle très faible. Complexité spatiale exponentielle. Marche pour un faible nombre de champs. Hachage et SRAM Complexité temporelle moyenne très faible Complexité spatiale faible. Lakshman & al. Complexité spatiale faible. [Lak98] Complexité temporelle maximale non bornée. Marche pour un faible nombre de champs. Technique matérielle uniquement. Complexité temporelle moyenne. Nombre de règles limité à

110 Le contrôle d accès dans les réseaux ATM - Mécanismes de contrôle d accès Technique Avantages Inconvénients Srinivas. & al. [Sri99] Complexité temporelle très faible. Complexité spatiale très faible. Gupta & al. [Gup99] Complexité temporelle très faible. Complexité spatiale très faible. Gupta & al. [Gup00a] Complexité temporelle très faible. Complexité spatiale très faible. Feldman & al. [Fel00] Complexité spatiale et temporelle moyennes. Gupta & al. [Gup00b] Complexité spatiale et temporelle moyennes Paul & al. Complexité temporelle très faible. Complexités bornées. Le tableau 31 présente une comparaison des différentes méthodes de classement. Dans celui-ci les méthodes dédiées au classement de politique statiques sont présentées en grisé. L avantage de notre approche vis à vis de celles-ci vient du fait que notre algorithme propose des complexités spatiales et temporelles à la fois bornées et utilisables dans la pratique. Par ailleurs notre proposition est l une des seules à avoir été implémentées sur une architecture matérielle Conclusion Complexités non bornées dépendant des politiques utilisées. Complexités non bornées dépendant des politiques utilisées. Complexités non bornées dépendant des politiques utilisées. Complexités spatiale et temporelle moyennes. Complexités spatiale et temporelle moyennes. Complexité spatiale élevée en théorie, moyenne en pratique. Nous avons montré dans cette section comment il était possible de développer un algorithme de classement de flux permettant d assurer un temps faible et borné de classement. Nous avons par ailleurs montré comment il était possible d utiliser la redondance pouvant être trouvée dans les règles de contrôle d accès et qui était traditionnellement utilisée pour améliorer les performances des algorithmes de classement afin de limiter la complexité spatiale de notre algorithme de classement. Nous avons également montré comment un tel algorithme de classement pouvait être utilisé dans une architecture de contrôle d accès pour les réseaux ATM en définissant les éléments permettant sa configuration adéquate. Nous avons par ailleurs montré que cette architecture pouvait être implémentée et avons démontré au travers de tests que celle-ci fournissait des performances permettant de répondre aux problèmes de débit et de respect de la QoS que nous avions présentés en section 3.1, chapitre 3. Nous avons de plus montré que notre architecture n était généralement pas sensible aux problèmes de dénis de service mis en évidence pour les propositions existantes en section 4, chapitre 3. Nous avons enfin montré comment notre algorithme de classement pouvait être utilisé afin de réaliser des opérations de classement à des débits bien plus élevés que ceux actuellement proposés. Le chapitre 3 avait fait apparaître que les solutions actuelles de contrôle d accès pour les réseaux ATM ne prennent en compte qu une partie des paramètres de contrôle d accès pouvant être utilisés. Nous avons montré dans cette section comment un filtre de signalisation utilisant les paramètres additionnels de contrôle d accès définis au chapitre 4 pouvait être implémenté et associé à notre architecture de contrôle d accès au niveau cellule. Nous avons montré au travers de tests que notre outil de filtrage de la signalisation ATM fournissait des performances lui permettant de traiter tous les messages de signalisation produits par un réseau local. Cette architecture n est cependant par exempte de défauts. Le premier est de ne pas pouvoir régler le problème de la prise en compte des options pouvant être spécifiées dans les paquets IP du fait de la nature des cartes IFTs. Nous avons montré en section que ce problème n était généralement pas si important par le fait de l utilisation généralement constatée de ces champs. Cette constatation ne règle cependant pas le problème puisque l utilisation du protocole IPv6 pose le même problème du fait de la taille des adresses utilisées. 102

111 Le contrôle d accès dans les réseaux ATM - Mécanismes de contrôle d accès 4. Conclusion Dans ce chapitre nous avons présenté deux architectures permettant de répondre aux problèmes que nous avions présentés au chapitre 3. Ces problèmes pouvaient être classés en trois catégories. La première concernait les limitations des solutions actuelles vis à vis du contrôle d accès sur la signalisation ATM. Nos deux architectures dépassent ces limitations en permettant la mise en oeuvre de politiques de contrôle d accès portant sur une grande partie des paramètres de contrôle d accès décrits au chapitre 4. La seconde et troisième catégories concernaient la capacité des architectures actuelles à respecter les qualités de service pouvant être négociées au niveau ATM tout en offrant des performances honorables. Nos deux architectures utilisent vis à vis de ces deux problèmes deux approches opposées. La première répond aux limitations des performances par la distribution du contrôle d accès sur un grand nombre d équipements et positionne les fonctions de contrôle d accès de telle sorte que les opérations de contrôle d accès soient réduites vis à vis de ce qu elles seraient dans une solution centralisée. Notre seconde solution se base pour résoudre le même problème sur un algorithme de classement permettant de décider de manière extrêmement rapide de la règle de contrôle d accès à appliquer à une cellule en fonction de son contenu. Vis à vis du problème du respect de la qualité de service, notre première approche se propose d éliminer toute modification de la QoS pouvant être négociée en utilisant un processus de contrôle d accès non bloquant. Notre seconde approche vise à limiter les modifications à des délais extrêmement faibles de l ordre de quelques dizaines de micro-secondes de telle sorte que cette modification passe inaperçue. Pour cela elle se base sur un processus de classement suffisamment rapide pour éviter la bufferisation des cellules à contrôler. La rapidité de l algorithme de classement est garantie par une complexité temporelle faible et bornée. Ces deux architectures de par leurs différences présentent des qualités complémentaires. Ainsi il serait envisageable de faire cohabiter les deux architectures de manière à résoudre les problèmes liés à l analyse d une seule cellule en confiant une partie des fonctions de contrôle d accès à notre solution centralisée alors que les parties touchées par ce problème dans cette architecture seraient, elles, confiées à notre architecture distribuée. Une autre évolution pourrait, elle, consister à utiliser notre algorithme de classement dans notre architecture distribuée afin d en améliorer les performances. En effet la seule différence entre les opérations réalisées dans nos deux architectures concerne l emplacement des informations qui sont comparées aux valeurs décrites par la politique de contrôle d accès. Dans le cadre de notre architecture distribuée, ces valeurs sont localisées dans des MIBs alors que notre architecture centralisée utilise les informations contenues dans les cellules ATM. Nos deux architectures présentent également des qualités complémentaires vis à vis des problèmes pouvant être générés par l utilisation de services de confidentialité ou d authentification tels que ceux préconisés par l IETF dans IPSEC ([RFC2401]) ou par l ATM-FORUM dans la première version de ses spécifications pour la sécurité dans les réseaux ATM ([SEC10]). Dans ces deux propositions, les services de sécurité peuvent être placés à deux endroits différents dans le réseau. Une première approche consiste à placer ces services sur les équipements extrémités. La seconde consiste à placer les services de sécurité en un seul point du réseau en affectant à un seul équipement la tâche d implémenter toutes les fonctions de sécurité. Tableau 32. Architectures de C.A. utilisables en fonction du placement des autres services de sécurité. Service/Emplacement En extrémité En coupure Confidentialité (Distribuée, Non bloquante) (Distribuée, Non bloquante), (Centralisée, Bloquante) Authentification (Distribuée, Non bloquante) (Distribuée, Non bloquante), (Centralisée, Bloquante) Le tableau 32 donne les possibilités de cohabitation entre nos architectures de contrôle d accès et les propositions actuelles en termes de confidentialité et d authentification que celles-ci viennent de l ATM- FORUM ou de l IETF. Ce positionnement est réalisé de telle sorte que le processus de contrôle d accès soit placé avant le processus de chiffrement afin que les paramètres de contrôle d accès puissent être accédés en 103

112 Le contrôle d accès dans les réseaux ATM - Mécanismes de contrôle d accès clair. Comme le montre le tableau 32, au moins une de nos deux propositions est compatible avec chacun des placements possibles des services d authentification et de confidentialité. Pour conclure, le tableau 33 présente les utilisations potentielles de nos architectures de contrôle d accès. Tableau 33. Architectures de C.A. utilisables en fonction du type d application. Architecture/Application Réseau d opérateur Réseau privée d entreprise Distribué, Non bloquante X Centralisée, Bloquante X X Notre architecture distribuée est principalement dédiée à la protection d un réseau privé. Elle peut est déployée dans ce cas en attribuant un agent de contrôle d accès à chaque équipement pouvant être modifié. Il nous semble plus difficile de l utiliser dans le cas d un réseau public. Notre architecture centralisée est, elle, adaptée à la fois à la protection d un réseau privé d entreprise en placant notre outil en entrée de réseau sur le commutateur reliant l entreprise au réseau public mais est également adaptée à la protection des réseaux d opérateur. En effet celui-ci peut désirer protèger son réseau d attaques provenant de ses clients ou des réseaux ou il est lui même interconnecté. Notre outil peut dans ce cas être placé du coté opérateur sur le dernier commutateur reliant le réseau aux abonnés ou aux réseaux partenaires. Au moins deux de ces placements font surgir le problème de gestion des deux architectures de contrôle d accès que nous présentons. Celui-ci est évident dans le cas de notre architecture distribuée de contrôle d accès mais apparait également dans le cas de notre architecture centralisée dans le cas ou celle-ci est multipliée dans un réseau. De ce fait nous traitons le problème de la gestion automatique des équipements de contrôle d accès dans le chapitre suivant. 104

113 CHAPITRE 6 Gestion du contrôle d accès Dans ce chapitre, nous définissons les éléments permettant de réaliser la gestion d une architecture distribuée de contrôle d accès. Nous montrons également comment intégrer la notion d intégrité du service de contrôle d accès dans ce processus de gestion. 1. Introduction Ce chapitre a pour objectif de définir les moyens permettant d assurer la gestion automatique et efficace d une architecture distribuée de contrôle d accès. Comme nous l avons précisé en section 4.2 du chapitre 2, les méthodes de gestion automatique du contrôle d accès se basent sur deux éléments principaux. Le premier est un langage générique de contrôle d accès permettant d exprimer au travers d un seul langage la politique de contrôle d accès s appliquant à un réseau et cela quels que soient les équipements de contrôle d accès utilisés dans le réseau. Un autre objectif de ce langage est d être suffisamment sophistiqué pour permettre à l officier de sécurité d exprimer la politique de contrôle d accès de manière ergonomique. Cette ergonomie est importante pour réduire les risques d erreur au moment de l expression de la politique. Nos propositions vis à vis de cette première étape, expliquées en section 2 vise à répondre à ces deux objectifs en utilisant deux langages. Le deuxième élément est la définition d une architecture de gestion automatique du contrôle d accès. Nous faisons deux propositions dans ce domaine. Ces propositions se basent sur le langage de bas niveau défini en section 2 et sur un certain nombre d optimisations afin de distribuer de manière automatique et efficace les règles de contrôle d accès aux équipements. La principale différence entre ces deux propositions vient de l endroit où se fait la décision d appliquer une règle sur un équipement. Notre première proposition place ce processus de décision dans un gestionnaire centralisé alors que notre seconde approche propose que cette décision soit prise de manière répartie pour chaque règle. Nous décrivons en détail ces deux propositions en section 3. En section 4, nous montrons que l intégrité du service de contrôle d accès fourni par les architectures de contrôle d accès distribuées est plus difficile à assurer que dans le cadre d une architecture de contrôle d accès centralisée. Nous proposons de ce fait une technique permettant d augmenter la confiance qu un officier de sécurité peut avoir dans le service de contrôle d accès fourni par le réseau qu il administre. Celle-ci se base sur une modification des critères d optimisation définis pour nos architectures de gestion automatique du contrôle d accès. Nous montrons au travers de simulations que le coût de l utilisation de cette proposition peut être considéré comme négligeable dans le cas de certains réseaux. Pour finir, la section 5 conclut ce chapitre en résumant ses apports. 105

114 Le contrôle d accès dans les réseaux ATM - Gestion du contrôle d accès 2. Définition d un langage générique de contrôle d accès Dans cette section nous proposons deux languages génériques de contrôle d accès. Le premier, basé sur une proposition de normalisation vise à fournir une interface générique avec tous les éléments du réseau, quel que soit le service de contrôle d accès qu ils fournissent. L avantage d une expression de la politique de contrôle d accès au moyen de ce langage est donc de pouvoir rassembler l ensemble des règles permettant de réaliser le contrôle d accès au sein d une même politique et cela quels que soient les outils sous-jacents. D autre part la syntaxe choisie est suffisamment proche des paramètres de contrôle d accès utilisés par les outils de contrôle d accès pour d une part permettre à l officier de sécurité de savoir quelles opérations vont réellement être réalisées dans son réseau et d autre part faciliter le développement de traducteurs automatiques entre les langages existants et notre premier langage. Le second langage a lui pour objectif de faciliter la tâche de l officier de sécurité. En effet l utilisation de notre premier langage peut se traduire par des politiques de contrôle d accès de grande taille dont il est difficile, pour l officier de sécurité, de contrôler la correction du fait de leur complexité. Notre seconde proposition vise à résoudre ce problème en permettant à l officier de sécurité de déclarer une politique de contrôle d accès de manière ergonomique. Ce langage utilise la notion de rôle pour atteindre cet objectif Langage de bas niveau Notre première proposition afin de permettre l'expression de politiques de contrôle d'accès est appelée Langage de Définition de Politique de Contrôle d'accès (LDPCA). La définition du LDPCA est basée sur le Langage de Description de Politique (PDL) proposé à la fin de l année 1998 au sein du groupe de travail travaillant sur les politiques à l IETF ([Stra98]). Dans notre langage une politique est définie par un ensemble de règles, chaque règle étant elle même constituée d'un ensemble de conditions et d'une action qui est exécutée lorsque l'ensemble des conditions est rempli. L'expression suivante, issue de [Stra98] et exprimée dans le formalisme Backus Naur ou BNF décrit la forme générale d'une règle: Rule ::= IF <Conditions> THEN <Action> Le langage PDL ayant eu pour objectif initial de permettre l expression de tout type de politique, la structure des conditions et actions dans ce langage ne comprend aucun élément relatif à une utilisation dans un domaine particulier. Nous avons donc défini des conditions et actions afin qu il puisse autoriser l expression de règles de contrôle d accès. Toutes les conditions ont la même structure générique reflétant cette modification. Celle-ci est exprimée ci-dessous au moyen du formalisme BNF: Condition ::= <ACCESS CONTROL PARAMETER> <RELATIONAL OPERATOR> <VALUE> En fonction du niveau dans la pile de protocole, plusieurs types de paramètres de contrôle d'accès peuvent être utilisés: Au niveau ATM les paramètres intéressants sont décrits en chapitre 3. Parmi ceux-ci nous avons choisi le type de trafic, les identificateurs de connexion, les informations d'adressage, les descripteurs de QoS et les descripteurs de service. Ces paramètres correspondent au profil 3 décrit chapitre 3 ainsi qu à quelques paramètres complémentaires provenant des profils 4 et 5. Au niveau transport les paramètres que nous avons considérés sont ceux utilisés habituellement afin de réaliser le filtrage des paquets dans les routeurs filtrants (informations d'adressage, ports source et destination,...). Au niveau application nous définissons deux paramètres génériques: l'identificateur de l'utilisateur de l'application ainsi que l'état de l'application. Des informations temporelles ont également été incluses afin de spécifier lorsqu'une règle doit être appliquée. 106

115 Le contrôle d accès dans les réseaux ATM - Gestion du contrôle d accès Les actions ont également une structure générique (notation BNF): Action ::= <ACTION> <ACTION LEVEL> <LOG LEVEL> Celle-ci se décompose en trois parties. La première indique si la communication décrite par les conditions doit être autorisée ou interdite. Le paramètre <ACTION LEVEL> correspond à la couche protocolaire dans laquelle doit être effectuée l'action. La dernière partie décrit l'importance accordée à l'évènement de contrôle d'accès et permet le classement des résultats. Le lecteur intéressé pourra trouver en annexe de ce document (section 3.1.1, chapitre 9), la grammaire complète du langage LDPCA. La figure 50 montre comment notre langage peut être utilisé afin d'exprimer une politique de contrôle d'accès permettant de contrôler l accès à un serveur WWW. Dans cet exemple chaque équipement est identifié par son adresse source et son adresse destination. Le service WWW est identifié par les ports source et destination. La deuxième ligne de commande permet d'interdire les demandes de connexion sur le port lié au client WWW de notre station interne en n autorisant que les paquets ne possédant pas le drapeau SYN. Les numéros précédant les règles sont utilisés pour spécifier leur ordre de priorité. Figure 50. Exemple de politique de contrôle d accès. 12 : IF ( IP SRC ADDRESS = ) AND ( IP DST ADDRESS > ) AND ( SRC PORT > 1023 ) AND ( DST PORT = 80 ) THEN PERMIT TRANSP_CONNECTION LEVEL1. 13 : IF ( IP SRC ADDRESS > ) AND ( IP DST ADDRESS = ) AND (SRC PORT = 80) AND (DST PORT > 1023) AND (TCP FLAG <> SYN) THEN PERMIT TRANSP_CONNECTION LEVEL Langage à base de rôle Notre seconde proposition s inspire de la proposition de langage à base de rôle présentée dans [Ba99] en en reprenant la structure du langage et en le modifiant de telle sorte que les paramètres mis en évidence dans le chapitre 4 puissent être utilisés. Dans ce langage la définition des caractéristiques des connexions, la topologie du réseau et les liens entre ces deux éléments sont exprimés de manière séparée. La raison de cette séparation est due à un constat simple. Les politiques de contrôle d accès exprimées au travers de notre langage de bas niveau sont formées de règles qui contiennent une forte redondance au niveau des informations caractérisant les communications (par exemple, ports source et destination, types de drapeaux au niveau TCP/IP) ou la topologie (adresses). L objectif de ce deuxième langage est d offrir à l officier de sécurité des structures permettant d utiliser cette redondance afin de faciliter l expression de la politique de contrôle d accès. Ceci se traduit par un ajout plus facile de nouveaux services ou de nouveaux équipements. L expression d une politique de contrôle d accès au moyen de notre langage se fait donc en trois étapes. La première consiste à décrire l ensemble des communications acceptables sur le réseau en donnant les informations les caractérisant. Afin de décrire ces communications nous utilisons les paramètres de contrôle d accès utilisés dans notre langage de bas niveau décrit en section précédente. L'expression suivante (exprimée dans le formalisme Backus Naur) décrit la forme générale d'une règle portant sur les descripteurs de communications. crule ::= <CCID> : <COMMUNICATIONS_RELATED_CONDITIONS> La seconde partie consiste à décrire les différents groupes d équipements. Un groupe d équipements consiste en un ensemble d équipements ayant une fonction similaire dans le réseau. Un équipement se décrit au travers des différentes adresses qu il peut avoir dans un réseau. L expression suivante donne la forme de ce type de règle. drule ::= <DCID> : <ADDRESS_RELATED_CONDITIONS> 107

116 Le contrôle d accès dans les réseaux ATM - Gestion du contrôle d accès La dernière partie de notre politique consiste en la définition des rôles, c est à dire la relation entre groupes d équipements et groupes de communications acceptables. De ce fait les règles de ce type font le lien entre les deux autres types de règles au moyen d un opérateur de direction permettant de distinguer le sens valide de chaque descripteur de communication. L expression ci-dessous exprime la forme générale d une règle de définition de rôle. rrule ::= <RCID> : <DCID> <DIR_OPERATOR> <DCID> ::= <CCID> Le lecteur intéressé pourra trouver en annexe de ce document (section 3.1.2, chapitre 9), la grammaire complète du langage à base de rôle. Nous décrivons en figure 51, comment la politique de contrôle d accès exprimée avec notre langage de bas niveau en figure 50 se traduit dans notre langage à base de rôles. Dans celui-ci nous définissons tout d abord les caractéristiques des communications acceptables entre un client WWW et un serveur (WEBCS) et vice-versa (WEBSC). Nous donnons ensuite les groupes correspondant aux notions de serveur et clients web (SERVEURW3 et CLIENTW3). Enfin nous définissons les rôles en établissant le lien entre groupes et communications acceptables. Figure 51. Exemple de politique de contrôle d accès. WEBCS : (SRC_PORT > 1023) AND (DST_PORT = 80) WEBSC : (SRC_PORT = 80) AND (DST_PORT > 1023) AND (TCP_FLAG <> SYN) SERVEURW3 : (IP ADDR = ) CLIENTW3 : (IP ADDR > ) R1 : SERVEURW3 -> CLIENTW3 ::= WEBSC R2 : CLIENTW3 -> SERVEURW3 ::= WEBCS 3. Définition d une architecture de gestion du contrôle d accès 3.1. Introduction Dans cette partie, nous décrivons deux architectures de gestion automatique du contrôle d accès. Vis à vis du classement établie en section du chapitre 2, la première ([Pa99d]) est de type centralisée alors que la seconde ([Pa00a], [Pa00e]) est, elle, distribuée. De manière analogue aux solutions présentées chapitre 2, section 4.2 nous utilisons deux optimisations. Nous utilisons d une part une optimisation basée sur les capacités de contrôle d accès des équipements et d autre part une optimisation basée sur la topologie du réseau. Par ailleurs nous introduisons une optimisation complémentaire basée sur la topologie et le type de règle. En effet, une meilleure connaissance du type de politique de contrôle d'accès permet de donner des propriétés supplémentaires. Par exemple, dans le cas d'une politique de type "Tout ce qui n'est pas explicitement autorisé est interdit", qui est le type de politique le plus répandu, il est possible de ne spécifier les interdictions qu'en un point du chemin qui inter-connecte la source et la destination relatifs à une règle. Ceci se justifie par le fait que dans ce type de politique, chaque règle d'interdiction décrit un sous-ensemble d'un ensemble décrit par une règle d'autorisation. De plus afin d'assurer une répartition équitable des règles et du fait de la structure généralement arborescente des réseaux, il est important que le placement des règles se fasse sur les équipements les plus proches des équipements source et destination décrits par chaque règle. De ce fait, les critères de distribution que nous utilisons sont les suivants: (R1) : Une règle ne peut être attribuée qu'à des modules de contrôle d'accès gérant les objets de contrôle d'accès utilisés par la règle. (R2) : Une règle ne peut être attribuée à un module contenu dans un équipement que si celui-ci est situé sur le chemin entre la source et la destination décrites par la règle. (R3): Si une règle d'interdiction peut être attribuée à des modules situés sur plusieurs équipements en cascade, la règle ne doit être attribuée qu'au module situé sur l'équipement le plus proche des extrémités. 108

117 Le contrôle d accès dans les réseaux ATM - Gestion du contrôle d accès Vis à vis des langages définis en section 2, notre architecture de gestion automatique du contrôle d accès peut se positionner comme indiqué en figure 52. Figure 52. Processus de gestion du contrôle d accès. L officier de sécurité définit la politique globale de contrôle d accès au moyen de notre langage générique de bas niveau. L officier de sécurité définit la politique globale de contrôle d accès au moyen de notre langage à base de rôles. La politique est traduite automatiquement dans notre langage générique de bas niveau L architecture de gestion automatique du contrôle d accès assure la distribution, la traduction et la récupération des résultats associés à la politique de contrôle d accès. Cette section est organisée de la manière suivante. En section 3.2 nous présentons notre proposition d architecture de contrôle d accès centralisée. La section 3.3 présente notre proposition d architecture de contrôle d accès distribuée. Enfin la section 3.4 conclut ce chapitre en comparant nos deux architectures Architecture centralisée Vue générale Notre première proposition en matière de gestion automatique du contrôle d accès ([Pa99d]) est proche des méthodes de gestion automatique centralisées présentées en section chapitre 2. La forme générale de notre architecture de gestion centralisée est décrite en figure 53. Notre architecture contient deux éléments principaux. Le premier est basé sur un agent de gestion modifié. L agent est chargé d interagir avec le service de contrôle d accès auquel il est rattaché afin de configurer celui-ci de manière conforme à la politique de contrôle d accès. Le deuxième élément de notre architecture est le gestionnaire. Celui-ci est chargé de configurer chaque agent au moyen d un ensemble minimal de règles de contrôle d accès. Cet ensemble minimal est construit au moyen de la politique de contrôle d accès et d un modèle du réseau de telle sorte que l ensemble des règles recues par l agent remplisse les règles R1, R2 et R3 définies précédemment. Nous revenons en détail sur la méthode utilisée pour atteindre cet objectif dans la suite de cette section. Le gestionnaire est également chargé de récupérer les résultats du contrôle d accès auprès des agents et d analyser ces résultats afin de repérer des attaques distribuées. Figure 53. Architecture générale. Agent MIB Contrôle d accès Gestionnaire Politique Contrôle d accès Modèle du Réseau Trans. ATM Réseau ATM Transp. ATM 109

118 Le contrôle d accès dans les réseaux ATM - Gestion du contrôle d accès Afin de réaliser ces interactions, le gestionnaire met à jour au niveau de chaque agent une base de donnée de gestion (MIB) contenant la politique de contrôle d accès propre à l agent et les résultats du service de contrôle d accès géré par l agent. Le protocole utilisé pour assurer les communications entre l agent et le gestionnaire doit fournir les services d intégrité, de contrôle d accès, d authentification et de lutte contre le rejeu. De ce fait les protocoles SNMPv2* [Sta99] (Simple Network Management Protocol) ou SNMPv3 [Ba98] qui fournissent tous ces services semblent être de bons candidats. La raison du choix de SNMP vis à vis de COPS provient du fait qu au moment de l élaboration de notre architecture, seul SNMP avait été implémenté. Cependant notre architecture n est en rien liée à SNMP et le couple MIB/SNMP pourrait être remplacé par le couple PIB/COPS qui fournit des services de sécurité analogues Architecture de l agent Afin de spécifier les interactions possibles entre l'agent et l équipement géré, nous avons défini une interface commune. Celle-ci est basée sur un ensemble de fonctions génériques et une description des objets de contrôle d accès disponibles pour l'agent. Par objets on entend aussi bien les paramètres décrivant les communications effectuées sur le système que les actions possibles sur ces communications. Ces objets peuvent être mis en correspondance avec les éléments terminaux du langage de bas niveau décrit en section 2.1. La figure 54 décrit la structure interne d'un agent. Celui-ci est composé de deux parties. Une première partie appelée processus de gestion de la MIB se charge des relations avec le gestionnaire en lui permettant l insertion, la suppression de règles de contrôle d accès et la récupération du résultat de l application des règles. La seconde partie, appelée processus de traduction effectue la traduction de la politique de contrôle d'accès en commandes compréhensibles par l équipement de contrôle d accès. Cette traduction se fait en plusieurs étapes. Le processus de traduction remplit tout d abord une structure générique avec les paramètres de la règle de contrôle d accès et envoie cette structure à la bibliothèque de contrôle d accès au moyen d une fonction générique. Celle-ci effectue la traduction entre les valeurs contenues dans la structure générique et les commandes et valeurs utilisées par le système réel. Cette décomposition du problème permet de limiter la modification nécessaire pour transférer un agent entre deux systèmes, à la modification de la bibliothèque de contrôle d accès. Figure 54. Structure interne d'un agent de gestion du contrôle d accès. Agent de gestion du contrôle d accès MIB de contrôle d accès Règles de contrôle d accès Résultats de contrôle d accès Processus de traduction Interface générique Bibliothèque de contrôle d accès Interface réelle du système de contrôle d accès Système Processus de gestion de la MIB Vers le gestionnaire de contrôle d accès Les résultats de l application des règles de contrôle d accès sont eux transférés dans le sens inverse. Ces résultats sont stockés dans une partie de la MIB gérée par l agent et sont accédés de manière distante par le 110

119 Le contrôle d accès dans les réseaux ATM - Gestion du contrôle d accès gestionnaire. Les deux processus (traduction et gestion) communiquent directement afin de se signaler l arrivée de nouvelles règles ou de nouveaux résultats d application Modèle du réseau Afin d'assurer la distribution des règles de contrôle d'accès décrites au moyen du langage décrit section 2, il est nécessaire de connaitre la configuration du réseau à contrôler. Afin d'exprimer cette configuration nous définissons une méthode d'abstraction du réseau réel. Cette méthode se base sur une décomposition des éléments du réseau selon leur place dans le réseau et leur niveau dans la pile protocolaire. Un exemple d'abstraction au niveau ATM est décrit figure 55. On peut y distinguer deux types d'équipements: Equipements intermédiaires. Ces équipements ont pour particularité d'interconnecter d'autres équipements que ceux-ci soient terminaux ou intermédiaires eux mêmes. Ils sont représentés dans notre schéma par des commutateurs mais pourraient également correspondre à des routeurs ou à des ponts. Equipements terminaux. Ces équipements correspondent aux feuilles de notre arbre. Ils n'interconnectent aucun équipement. Figure 55. Modélisation du réseau au niveau ATM. External Network Switch 0 Switch 1 Term. 1 I1 Switch 2 I4 I3 I2 Switch 3 Group I I5 I6 I7 I8 I10 I9 Term. 3 Term. 4 Term. 5 Term. 2 Group 0 Il peut arriver selon le niveau auquel on se place (ATM, MAC, IP), que les équipements extrémités d'un niveau deviennent équipements intermédiaires au niveau supérieur. Par exemple comme le montre la figure 56 dans le cadre d'un réseau de type IP sur ATM, une station terminale (T2) au niveau ATM peut servir de routeur (R2) au niveau IP. Il est donc nécessaire de construire à chaque niveau un arbre de connectivité. Afin de décrire un modèle du réseau, nous utilisons trois classes d objets différents appelés interface, groupe et équipements (ou Interface, Group et Device): Les interfaces (ou Interface) représentent les points d interconnexion entre deux éléments. Par exemple, figure 55, les interfaces I3 et I4 permettent d interconnecter les switchs 2 et 3. Chaque interface I est associée avec son niveau protocolaire (ATM, MAC ou IP), son type (intermédiaire ou terminale) et son adresse. Pour cela trois fonctions sont définies (I.Level, I.Type et I.Address) et ont été associées à la classe interface pour gérer ces informations. La seconde classe présentée par notre schéma est celle de groupe (ou Group). Un groupe correspond à un ensemble d interfaces inter-connectées. Dans la figure 55 le groupe 1 inter-connecte trois équipements terminaux à un équipement intermédiaire au moyen des interfaces I5, I6, I7, I8, I9 et I10, le groupe 0 interconnecte toutes les interfaces du réseau interne. On associe à chaque groupe son niveau protocolaire, 111

120 Le contrôle d accès dans les réseaux ATM - Gestion du contrôle d accès la liste des interfaces qu il interconnecte et enfin une interface maîtresse. Une interface maîtresse correspond à l interface permettant de sortir du groupe. Ainsi l interface maître du groupe 1 est l interface I4. Trois fonctions (G.level, G.connects, G.master) ont été définies afin de gérer ces informations. Les deux premières classes d objet permettent de décrire notre abstraction du réseau. La dernière classe appelée équipement (ou Device) permet de décrire d une part les interfaces présentes au sein d un équipement physique et d autre part de donner les capacités de contrôle d accès de l équipement. On associe de ce fait à chaque objet équipement la liste des interfaces qu il possède ainsi que la liste des objets de contrôle d accès disponibles au sein de l équipement. On définit deux fonctions (D.maps, D.stores) afin de gérer ces informations. Figure 56. Correspondances inter-couches. R1 R2 IP T4 T3 T5 S3 T2 S2 T1 S1 S0 ATM Distribution des règles Distribution générale Au moyen de l'abstraction que nous avons de notre réseau ainsi que des règles de contrôle d'accès que nous avons définies suivant la grammaire décrite en section 2, nous pouvons distribuer les règles sur les équipements. La méthode de distribution des règles se fait suivant l algorithme décrit en figure 57 qui implémente les assertions R1 et R2 de la section 3.1. Figure 57. Algorithme initial de distribution des règles. Pour tout i {Interface} faire G = {g {Group}/ i g.connects}; D = {d {Device}/ (i0,i1) d.maps, (i0=i i1=i)}; M = {m {Group}/ m.master = i}; N = {k {Interface}/ k m.connects, m M}; Pour tout r {Rule} faire Pour tout d D faire Associate(r,d); Si o objets(r)/ o d.stores alors Dissociate(r,d); (C1) Sinon Si i interface(r) alors Si i.type = «terminal» alors Dissociate(r,d); (C2) Sinon Si j interface(r), j N alors Dissociate(r,d); (C3) FinSi FinSi FinPour FinPour FinPour 112

121 Le contrôle d accès dans les réseaux ATM - Gestion du contrôle d accès Cet algorithme utilise d une part une description de la politique de contrôle d accès ({rule}) et trois ensembles d objets tels que décrits précédemment ({Group}, {Device}, {Interface}). Quatre fonctions externes sont également utilisées. objects(r) fournit la liste des objets nécessaires pour l implémentation de la règle de contrôle d accès r; interface(r) fournit l ensemble des interfaces auxquelles s applique la règle r; Associate(r,d) associe la règle r à l équipement d; enfin Dissociate(r,d) dissocie la règle r de l équipement d. L algorithme implémente les assertions R1 et R2 de la façon suivante: Une règle ne peut être distribuée sur un équipement qui ne contient pas les objets utilisés par la règle (C1). Une règle ne doit pas être distribuée sur un équipement terminal si cette règle ne le concerne pas (C2). Une règle ne doit pas être distribuée sur un équipement intermédiaire si la règle ne s'applique pas à celuici, sauf si cet équipement interconnecte au moins un des équipements concerné par la règle (C3). Première optimisation L algorithme précédent permet d'assurer la cohérence des règles avec les équipements auquels elles s'appliquent. Cependant il ne garantit pas une distribution optimale vis à vis de nos critère R1, R2 et R3. Afin d'assurer cette optimalité nous appliquons la règle R3 définie dans la section 3.1.L algorithme résultant fonctionne de la façon suivante. Si une règle peut être distribuée sur plusieurs équipements en cascade, la règle ne doit être distribuée qu'à l'équipement le plus éloigné de la racine (C4). Cette restriction ne peut s'appliquer qu'aux règles d'interdiction car dans le cas des règles d'autorisation tous les agents correspondant à des équipements traversés par une connexion doivent autoriser celle-ci afin qu'elle puisse être réalisée. Dans le cas des interdictions, la présence de la règle à un seul endroit suffit pour interdire une connexion. Cependant, avec notre optimisation précédente, deux équipements peuvent être à même distance de la racine et donc implémenter les mêmes règles d interdiction. Nous éliminons les règles résiduelles en (C5) en spécifiant qu une seule règle doit être appliquée. Figure 58. Premier algorithme d'optimisation de la distribution. Pour tout r {Rule}/ action(r)= «DENY» faire Pour tout d {Device} faire I = {i {Interface}/ (i0,i1) d.maps,(i0=i i1=i)}; G = {g {Group}/ g.master I}; M = {m {Interface}/ m g.connects, g G}; E = {e {Device}/ (i0,i1) e.maps, e d, (i0 M i1 M)}; Si associated(r,d) alors Si e E/ associated(r,e) alors Dissociate(r,d); (C4) FinPour FinPour Pour tout r {Rule}/ action(r)= «DENY» faire D = { d {Device}/ associated(r,d)}; Soit d D Pour tout e {f D/ f d} Dissociate(e,d); (C5) FinPour L algorithme implémentant cette optimisation, présenté en figure 57, se base sur deux fonctions additionnelles: action(r) donne l action associée à la règle r. associated(r,d) indique si la règle r a déjà été associée avec l équipement d. Gestion de l'usurpation d'adresse et deuxième optimisation Exprimer l'usurpation d'adresse avec le langage que nous avons défini n'est pas évident car nous supposons que les communications fournissent des paramètres valides. Cependant, il est possible de bloquer les 113

122 Le contrôle d accès dans les réseaux ATM - Gestion du contrôle d accès communications faisant une usurpation d'adresse de manière automatique sans ajouter de règles à la politique de contrôle d accès en utilisant l'algorithme présenté figure 59. Cet algorithme se base sur le fait que toutes les communications concernant deux éléments du réseau ne peuvent être établies que si ces communications sont autorisées de manière explicite. Le résultat de l utilisation des algorithmes de distribution présentés précédemment sur cette règle va être de diffuser cette autorisation sur l'arbre d'interconnexion entre les deux équipements ainsi que sur les équipements reliant le sommet de cet arbre à la racine du réseau. Afin d'éviter l'usurpation d'adresse il suffit de supprimer ces dernières règles (C6). Cette suppression fournit également une optimisation de la distribution. Figure 59. Deuxième algorithme d'optimisation de la distribution. Pour tout r {Rule/ action(r)= «PERMIT»} faire G = {g {Group}/ interface(r) g.connects}; Soit h G/ l G, h.connects l.connects; N = {n G/ n h}; M = {o {Interface}/ o = n.master, n N}; D = {d {Device}/ d.maps M}; Pour tout d D faire Si associated(r,d) alors Dissociate(r,d); (C6) FinPour Conclusion Nous avons présenté dans cette section une architecture permettant de gérer de manière automatique des équipements de contrôle d accès. Celle-ci se base d une part sur une description de la politique de contrôle d accès au moyen du langage que nous avons défini en section 2.1 et sur un modèle du réseau. Vis à vis des propositions décrites en section du chapitre 2, notre proposition se différencie par deux aspects. Le premier est l ajout d un critère complémentaire d optimisation du placement des règles de contrôle d accès. Comme nous le montrerons dans la section suivante, ce critère permet de diminuer légèrement le nombre moyen de règles par noeud. D autre part, contrairement aux approches présentées au chapitre 2 qui positionnent le processus de traduction entre langage générique et langage propre aux équipements au niveau du gestionnaire, nous proposons de positionner celui-ci au niveau des agents placés sur les équipements de contrôle d accès. La raison principale de cette différence vient du fait que notre approche vise à configurer des équipements provenant de constructeurs différents dont on ne connaît pas a priori les langages de configuration. Il est de ce fait difficile de définir un gestionnaire générique si celui-ci doit inclure des processus de traduction à priori inconnus. Ce problème n est pas abordé dans les propositions présentées en chapitre 2 puisque celles-ci visent à gérer les équipements provenant d un seul constructeur. De la même façon que les architectures se basant sur un modèle du réseau présentées au chapitre 2, notre architecture est sensible aux modifications de topologie puisque l officier de sécurité doit d une part repérer les modifications de topologie, modifier le modèle du réseau en conséquence et enfin réexecuter l algorithme de distribution de telle sorte que la configuration des équipements soit conforme à la topologie réelle du réseau. Cette activité, comme nous l avons expliqué en section , chapitre 2, peut être d une part une source de travail importante pour l administrateur et d autre part peut provoquer des trous de sécurité temporaires. On pourrait imaginer qu il soit possible dans le cas de certains protocoles de routage de définir des outils permettant de repérer automatiquement les modifications de routage et de signaler celles-ci au gestionnaire afin que celui-ci mette à jour la configuration de contrôle d accès de manière automatique. Cette approche pourrait régler le problème de la charge de travail de l administrateur, cependant elle ne règle pas celui des trous de sécurité temporaires par le fait que la configuration des équipements de contrôle d accès se fait toujours après les changements topologiques. C est la raison pour laquelle nous proposons dans la section suivante un architecture distribuée capable de générer la configuration des équipements de contrôle d accès en ne se basant pas sur un modèle du réseau 114

123 Le contrôle d accès dans les réseaux ATM - Gestion du contrôle d accès mais en utilisant les informations pouvant être fournies par les agents de routage. Cette architecture est par ailleurs capable d assurer que la configuration des équipements de contrôle d accès se fait toujours avant les modifications topologiques, empêchant de ce fait l apparition de trous de sécurité Architecture répartie Introduction D une manière analogue à notre architecture centralisée, notre architecture distribuée ([Pa00a], [Pa00e]) est basée sur l'utilisation d'agents se plaçant sur les équipements fournissant le service de contrôle d'accès. Ces agents interagissent avec les équipements sur lesquels ils sont placés afin de configurer les mécanismes de contrôle d accès de la manière la plus performante possible. L'objectif général de l'application des règles spécifiées par la politique de contrôle d accès au niveau des équipements de contrôle d accès est qu'un nombre minimal de règles de contrôle d accès soit appliquées sur chaque équipement. Pour cela, nous utilisons l ensemble d'assertions défini en section 3.1. La traduction de ces assertions se fait par la prise en compte de plusieurs paramètres : la topologie du réseau qui varie en fonction des informations de routage, les capacités de l'équipement en terme de contrôle d accès, la place de l'équipement dans la topologie du réseau et enfin la configuration des autres équipements de contrôle d'accès. Ces paramètres impliquent des interactions entre les agents de configuration et d'autres éléments du réseau. Certaines de celles-ci, détaillées dans la section sont internes à un équipement : entre l'agent de configuration et l'agent de routage correspondant ainsi qu'entre l'agent de configuration et les mécanismes de contrôle d'accès. Figure 60. Relations entre éléments externes. Agent G.C.A. Equipement réseau Agent de routage Gestionnaire de contrôle d accès Equipement réseau Equipement réseau Agent de routage Agent G.C.A. Agent de routage Agent de routage Equipement réseau Equipement réseau Agent G.C.A. Agent de routage Equipement réseau Liens physiques Informations de C.A. Informations de routage Gestion du C.A. D'autres interactions, détaillées figure 60, sont externes : Entre les agents de gestion du contrôle d accès (Agents G.C.A.) afin d'assurer une configuration efficace. Entre les agents de routage afin d assurer le routage des communications dans le réseau. 115

124 Le contrôle d accès dans les réseaux ATM - Gestion du contrôle d accès Entre les agents G.C.A. et le gestionnaire centralisé de contrôle d'accès. Celui-ci assure la distribution uniforme de toutes les règles de contrôle d accès sur les agents et la récupération des résultats de l'application de celles-ci. Le protocole utilisé entre les agents et le gestionnaire doit assurer l'intégrité, l'authentification, la confidentialité et le contrôle d accès sur les informations transportées. Comme dans le cas de notre architecture centralisée, il est envisageable d utiliser les couples SNMP/MIB ou COPS/PIB pour le transport et le stockage des politiques. Nous décrivons dans les sections suivantes comment les règles que nous avons définies précédemment peuvent être mises en œuvre au moyen de notre architecture. Nous montrons ensuite au travers de simulation d une part comment fonctionne cette architecture distribuée et d autre part quel est l impact des critères que nous avons définis en section 3.1 sur la distribution automatique d une politique de contrôle d accès Architecture Comme on peut le voir figure 61, notre architecture se base sur l'utilisation de modules interagissant entre eux. Le module de contrôle d accès (MCA) Ce module représente les mécanismes de contrôle d accès implémentés par l'équipement sous le contrôle de l'agent de contrôle d'accès. Ce module reçoit les règles de contrôle d accès de la part du module de configuration du contrôle d accès (MCCA). Ces règles sont traduites par le MCA dans les syntaxes réelles des commandes nécessaires à la configuration des mécanismes implémentés. En retour de ces commandes le MCA reçoit des résultats correspondant à l'application des commandes et transmet ces résultats au module de gestion centralisée du contrôle d accès (MGCCA). Le module d'information d'implémentation (MII) Le MII décrit au MCCA les capacités de l'équipement sur lequel se situe l'agent en terme de contrôle d'accès. Pour cela, il possède une table de correspondance entre les paramètres de contrôle d accès possibles et les mécanismes implémentés au niveau du système. La configuration de cette table se fait par l'officier de sécurité de manière manuelle ou de manière automatique par le logiciel d'installation des outils de contrôle d'accès. Lors de modifications dans cette base de donnée, le MCCA est averti par le MII. Le module de gestion centralisée du contrôle d accès (MGCCA) Ce module a pour objectif de faire le lien entre l'agent et le gestionnaire centralisé de contrôle d'accès. Pour cela il gère une base de donnée de gestion (MIB) qui est mise à jour par le gestionnaire. Ce dernier distribue au MGCCA toutes les règles de la politique de sécurité. Le MGCCA avertit le MCCA de ces mises à jour en lui fournissant toutes les règles modifiées. En retour de celles-ci, le MGCCA reçoit les résultats correspondants de la part du MCA. Ces résultats sont stockés de manière incrémentale dans une table de la MIB de telle manière que le gestionnaire puisse les récupérer de manière périodique. Le module d'échange d'informations sur le contrôle d accès (MEICA) Le MEICA a pour objectif de répondre à la question suivante du MCCA : "Existe-t'il un équipement mieux positionné qui applique déjà la règle r?". Afin de répondre à cette question, le MEICA interagit avec les MEICAs des agents voisins au moyen du protocole d'échange d'informations de contrôle d accès (PEICA). Ce protocole permet l'élection d'un agent choisi pour appliquer la règle de contrôle d'accès. Pour cela, le MEICA envoie à chaque changement de configuration les informations suivantes à ses voisins : Identificateur de la règle, Adresse de l'agent appliquant la règle, Distance. Pour chaque règle r, le MEICA compare les informations fournies par ses voisins avec les siennes et en déduit si l'agent qu'il représente se trouve en position optimale pour appliquer la règle. Une position optimale signifie que la valeur minimale des dis- 116

125 Le contrôle d accès dans les réseaux ATM - Gestion du contrôle d accès tances entre la source ou la destination relative à la règle et notre MEICA est la plus faible. Cette distance est donnée par le MIR. Dans le cas de changements de topologie ou dans la configuration des équipements de contrôle d accès provoquant une modification des informations de contrôle d accès, le MEICA avertit le MCCA afin que celui-ci revoit sa configuration. Figure 61. Architecture fonctionnelle d un agent de gestion du contrôle d accès. Agent de Routage Agent de Routage Module d'info. de routage. Module d'info. de routage. Module d'échange d'info. de C.A. Module d'info. d'implémentation Module de config. du C.A. Module de gestion centralisée de C.A. Module d'info. Horaires Module de C. A. Agent de gestion du CA Système réel Le module d'informations de routage (MIR) Le module MIR a un fonctionnement qui peut varier énormément en fonction du protocole de routage qui lui est associé. Cependant les fonctions qu'il remplit sont toujours les mêmes. D'une part il est utilisé par le MCCA afin de savoir si la communication relative à une règle r passe par l'équipement sur lequel est installé l'agent. D'autre part le MIR est chargé de calculer la distance entre l'équipement supportant l'agent et un autre équipement. Enfin lors de modifications de la topologie du réseau, le MIR avertit le MCCA afin que celui-ci prenne en compte cette nouvelle topologie. Dans certains cas tels que ceux décrits ci-dessous il est nécessaire de considérer le fait que les informations de routage se rapportant aux règles peuvent provenir de plusieurs sources différentes. L équipement appartient à des réseaux où le routage se fait à plusieurs niveaux protocolaires (par exemple du type IP sur ATM). L équipement appartient à plusieurs domaines de routage de manière simultanée (OSPFng et RIPv2 permettent en théorie ce type d opération). L équipement utilise un protocole de routage pour chaque réseau auquel il est connecté. Ces protocoles se situent tous au sein d une même couche (par exemple OSPF et BGP). Chaque protocole de routage est associé à une interface réseau particulière. L implémentation de ces cas particuliers se fait généralement au moyen d un agent de routage pour chaque protocole ou instance du protocole de routage. Ceci explique le fait que le MCCA puisse être en relation avec plusieurs MIRs, chacun étant dédié aux informations provenant d un protocole particulier. Dans ce contexte, l officier de sécurité a la responsabilité de définir les associations correctes entre agents de gestion du contrôle d accès et agents de routage. L administrateur réseau a la responsabilité de configurer les équipements de telle sorte que la cohérence des informations de routage entre les différents domaines soit assurée. Nous donnons en annexe (section 3.2, chapitre 9) les algorithmes utilisés dans le cas des protocoles de routage RIP et PNNI. 117

126 Le contrôle d accès dans les réseaux ATM - Gestion du contrôle d accès Le module d'informations horaires (MIH) Le MIH a pour objectif de gérer correctement les relations entre l'application des règles et le temps. Pour cela il reçoit les règles que lui passe le MCA et déclenche l'application et l'arrêt de celles-ci en fonction des indications horaires que celles-ci précisent. Le fait de communiquer avec le MCA permet de faire en sorte de ne pas introduire de délais comme ce serait le cas si la sélection des règles se faisait en liaison avec un module précédent (en effet dans ce cas il faudrait attendre les interactions du MCCA avec les autres modules). Le module de configuration du contrôle d accès (MCCA) Le module MCCA est le module central de notre architecture. Il est averti de l'arrivée de chaque nouvelle règle de contrôle d accès par le MGCCA. Pour chacune de ces règles, il va appliquer les trois assertions définies dans la section précédente. Pour cela, il interagit avec les modules MII, MIR, MEICA. L'algorithme de fonctionnement général de ce module est le suivant. Pour chaque règle reçue, le MCCA vérifie si celle-ci peut être appliquée à l'équipement au moyen du MII (assertion R1). Il vérifie ensuite au moyen du MIR que l'équipement peut se situer sur une des routes décrites par la règle (assertion R2). Si la règle de contrôle d accès est une règle d'interdiction il s'adresse alors au MEICA afin de savoir si un équipement plus proche de la source ou de la destination décrite par la règle l'applique déjà (assertion R3). Les règles n'exprimant pas de notion de source et de destination sont appliquées sans cette vérification. Si toutes ces conditions sont vérifiées, le MCCA passe alors la règle au MCA afin que celui-ci l'implémente Simulations Le simulateur ns [Ns99] est un simulateur à événement discret dédié à la recherche en réseaux. L'implémentation de ns est faite de deux parties. Une première partie en O-Tcl (Object Tcl) implémente des fonctions simples et permet à l'utilisateur de manipuler des objets représentant des équipements réseau de manière simple. La plupart de ces objets sont implémentés en C++ dans la seconde partie du simulateur pour des raisons d'efficacité. Au moyen du simulateur ns, nous avons réalisé une implémentation de l'architecture présentée dans la section précédente. Le lecteur intéressé peut trouver un package complet contenant l'implémentation et plusieurs suites de test sur [Pa99e]. Cette implémentation est relativement compacte. Elle contient deux parties. La première, composée d'une centaine de lignes de C++ est dédiée à la transmission des paquets produits par le PEICA. La seconde partie, composée d'un millier de lignes d'o-tcl implémente les modules décrits dans la section précédente. La raison pour laquelle nous avons codé ces modules en O-Tcl est que nos modules doivent interagir avec les modules de routage et que ces modules étaient disponibles dans la partie O-Tcl du simulateur ns Tests de fonctionnement Dans cette partie nous expliquons comment les règles de contrôle d accès sont distribuées par notre architecture de gestion du contrôle d accès et comment celle-ci réagit au changement de topologie. La topologie utilisée pour ces exemples est très simple. Elle est constituée de deux nœuds terminaux interconnectés au moyen d'un petit réseau maillé. Cette topologie est présentée figure 62. Nous supposons que les nœuds 1 à 4 ont les mêmes capacités de contrôle d'accès. Celles-ci leur permettent de fournir n'importe quel service de contrôle d'accès. Les nœuds 0 et 5 sont des postes clients qui n'ont aucune capacité de contrôle d'accès. 118

127 Le contrôle d accès dans les réseaux ATM - Gestion du contrôle d accès Figure 62. Réseau simple. Afin de tester les changements de topologie, nous configurons notre programme de simulation pour désactiver le lien entre les nœuds 1 et 2 après 1 seconde, nous désactivons ensuite le lien entre 1 et 3 et rétablissons le lien entre 1 et 2 après 1.5 seconde. Cette opération provoque le changement de route entre les nœuds 0 et 5 en la faisant passer d'un côté du réseau à l'autre. Les règles sont envoyées à tous les nœuds 0.5 seconde après le début de la simulation. Nous fournissons trois exemples en fonction d'un classement qui sera expliquée dans la section suivante. Règle spécifiée d'autorisation Le but de la première règle (appelée règle 0) est de permettre les communications d'un client WWW situé sur le nœud 0 vers un serveur WWW situé sur le nœud 5. L'exécution de la simulation donne les résultats suivants : Node 1 configuring rule 0. Node 2 configuring rule 0. Node 4 configuring rule 0. Node 3 configuring rule 0. Node 2 deleting rule 0. Node 2 configuring rule 0. Node 3 deleting rule 0. La conséquence du changement de topologie est évidente, la configuration du contrôle d accès suit le changement de topologie. Le placement des règles reste optimal puisque seuls les routeurs filtrants situés sur le chemin entre la source et la destination sont configurés. Règle spécifiée d'interdiction Le but de la première règle (appelée règle 1) est d'interdire les communications d'un client WWW situé sur le nœud 5 vers un serveur WWW situé sur le nœud 0. L'exécution de la simulation donne les résultats suivants : Node 1 configuring rule 1. Comme nous l'avions dit dans la section précédente, une seule règle d'interdiction suffit à bloquer la communication. C'est la raison pour laquelle seul le nœud 1 est configuré. 119

128 Le contrôle d accès dans les réseaux ATM - Gestion du contrôle d accès Règle non spécifiée Le but de la troisième règle (appelée règle 2) est d'interdire les messages ICMP redirect. L'exécution de la simulation donne les résultats suivants : Node 1 configuring rule 2. Node 2 configuring rule 2. Node 3 configuring rule 2. Node 4 configuring rule 2. Les règles qui ne fournissent pas d'adresses source et destination doivent être attribuées à tous les nœuds fournissant le service de contrôle d'accès. Cependant un officier de sécurité peut limiter leur distribution en enlevant la capacité de contrôle d accès correspondante sur les équipements adéquats Tests de performance Modélisation de la politique de contrôle d'accès. Afin d'obtenir des résultats de simulation satisfaisants, nous utilisons notre simulateur pour représenter une politique réelle de contrôle d'accès. Comme les politiques de contrôle d accès peuvent varier fortement d'un site à un autre, il n'est pas évident de définir une politique " typique " de contrôle d'accès. De plus comme nous l'avons noté en section 2, le langage utilisé pour définir une politique de contrôle d accès peut apporter des modifications importantes à la façon dont la politique sera exprimée. Nous avons donc pris des exemples de politiques provenant de [Ches94] et [Cha95] qui présentent des politiques " typiques " de contrôle d accès pour divers services utilisés dans internet et nous avons ajouté certaines modifications afin de refléter ce que l'on peut trouver dans une configuration réelle. La politique obtenue contient 80 règles. 10 de ces règles sont destinées à prévenir des attaques qui ne sont pas liées à des adresses spécifiques. Ce type de règle peut être par exemple utilisé pour rejeter les paquets IP utilisant le source-routing ou les messages ICMP redirect. 70 règles sont dédiées au contrôle d accès aux services internet (mail, dns, www, news, time, ftp, telnet,...). Ces règles sont toujours liées à des adresses ou à des espaces d'adresse. Afin de modéliser ces règles, nous classons les règles de contrôle d accès suivant deux critères. Le premier est l'action associée à la règle. Celle-ci peut être une interdiction ou une autorisation de la communication. En conséquence nous avons deux classes de règles appelées ALLOW et DENY. Le second correspond au fait que des informations d'adressage soient associées à la règle. Les règles qui fournissent des informations d'adressage sont appelées "spécifiées" alors que les règles qui n'en fournissent pas sont appelées "non spécifiées". Tableau 34. Classement des règles. Type de règle ALLOW DENY Non spécifiée 5 5 Spécifiée Exemple de distribution dans un réseau maillé Cet exemple est basé sur un réseau maillé qui pourrait représenter le réseau privé d'une entreprise. Il est constitué de 39 nœuds. 27 de ces nœuds sont terminaux et représentent des sous réseaux. Ces sous réseaux sont constitués de réseaux locaux interconnectés par un WAN. La topologie globale est décrite en figure

129 Le contrôle d accès dans les réseaux ATM - Gestion du contrôle d accès Figure 63. Réseau Maillé. Les 12 nœuds non terminaux représentent le cœur du réseau. Ces deux classes de nœuds ont des exigences différentes en matière de contrôle d'accès. Les nœuds terminaux sont supposés fournir un service de contrôle d accès pour tous les équipements qu'ils représentent alors que les nœuds non terminaux doivent uniquement être protégés contre des attaques de type "dénis de service". Par conséquent, les nœuds non terminaux implémentent uniquement les règles non spécifiées alors que les nœuds terminaux implémentent toute la politique. L'instanciation de notre politique de contrôle d accès est présentée dans le tableau 35. Comme les règles spécifiées sont dédiées à un réseau à protéger, la politique est composée de 27 ensembles de 70 règles de contrôle d'accès. Les règles non spécifiées sont par contre les mêmes pour tous les routeurs filtrants et sont donc représentées une seule fois. La politique obtenue est composée de 1900 règles. Tableau 35. Classement de l'instanciation des règles. Type de règle ALLOW DENY Total Non spécifiée Spécifié Total Les résultats de nos simulations sont présentés dans le tableau 36. Ces résultats montrent l'efficacité relative de l'utilisation de chaque assertion. L'optimisation la plus intéressante est celle basée sur les informations de routage. L utilisation de l optimisation basée sur les capacités de contrôle d accès des nœuds apportent également un gain intéressant. L'optimisation basée sur le type d'action apporte des améliorations plus faibles. Tableau 36. Efficacité des différents critères. Méthode de distribution Nombre de règles Nombre de règles/ nœud Diminution (%) Brute Basée sur les capacités Basée sur les informations de routage Basée sur les infos de routage et l'action Optimisation complète Les améliorations apportées par nos techniques d'optimisation sont importantes puisque nous parvenons à diviser par 20 le nombre de règles. D'une manière plus générale des simulations complémentaires ([Pa00]) montrent que la complexité des politiques implémentées par chaque routeur filtrant est réduite de O(n.m) avec 121

130 Le contrôle d accès dans les réseaux ATM - Gestion du contrôle d accès une configuration brute à O(n) (où n est le nombre de règles pour protéger un nœud terminal et m le nombre de réseaux à protéger) et cela quelle que soit la taille du réseau. Cependant nos simulations montrent que nos optimisations ne parviennent pas à configurer chaque nœud terminal avec n règles. Ceci s'explique par le fait que chaque règle spécifiée de type "ALLOW" génère la configuration de deux filtres de paquets. Le premier étant celui le plus près de la source et le second celui le plus près de la destination. Ce problème pourrait être réglé par l'agrégation de règles au moment de la définition de la politique de sécurité globale. Des simulations additionnelles ont également permit de montrer que d une part, le type de topologie du réseau avait peu d importance dans l efficacité des critères d optimisation R1, R2 et R3. Ainsi la plus grande différence entre les résultats obtenus pour notre réseau maillé et un réseau ayant une topologie en arbre d ordre 3 ayant le même nombre de noeud est de l ordre de 15%, la différence moyenne étant de 8.7% ([Pa00]) Conclusion Nous avons présenté dans cette section une architecture définie pour distribuer et configurer automatiquement une politique de contrôle d accès dans un réseau comprenant plusieurs équipements de contrôle d accès. Nous avons montré au travers de simulations que notre architecture est capable de configurer ces équipements efficacement. En comparaison avec les approches existantes notre architecture présente plusieurs avantages : Les configurations produites par notre architecture sont d'une efficacité comparable à celle produite par un administrateur expérimenté. Il est possible d éviter les trous de sécurité générés par le délai entre le moment ou le changement topologique est perçu et celui ou les équipements de contrôle d accès sont reconfigurés en subordonnant les opérations de routage à celles de gestion du contrôle d accès. L'officier de sécurité n'a pas à gérer la complexité introduite par la topologie du réseau car la distribution des règles s'adapte automatiquement à celle-ci. La répartition du processus de distribution le rend plus réactif et extensible. L'officier de sécurité peut contrôler l'application des règles au moyen des résultats renvoyés par les agents. Cependant cette approche a l inconvénient que l officier de sécurité ne connaît qu a posteriori si la politique de contrôle d accès a été appliquée ou non. On peut cependant noter que ce problème existe également avec les architectures centralisées en cas de changement de topologie et que dans ce cas l officier de sécurité doit chercher par lui-même quelles règles ont été appliquées et quelles règles sont devenues inutilisées. Un problème plus grave vient du fait que chaque agent doit posséder l intégralité de la politique de contrôle d accès afin de pouvoir changer de configuration sans faire appel au gestionnaire centralisé. Cette contrainte est importante si la taille de la politique est grande ou si le nombre d équipements de contrôle d accès dans le réseau est important. Afin de résoudre ce problème, on pourrait imaginer un système dans lequel la politique serait transportée et stockée de manière compressée. Une telle technique pourrait se révéler très efficace étant donné la redondance pouvant être trouvée dans les règles de contrôle d accès ([Gup99], [Gup00]). Une autre approche pourrait consister à utiliser un langage permettant une description plus concise de la politique de contrôle d accès tel que le langage à base de rôle que nous définissons en section 2.2 et à réaliser la traduction entre celui-ci et notre langage de bas niveau au niveau des agents de gestion du contrôle d accès. On peut alors se demander si ce dernier langage est nécessaire. La réponse est positive et cela pour la raison principale que cette forme d expression est la décomposition maximale pouvant être réalisée à partir de politiques sous des formes plus concises. Chaque règle dans ce langage constitue une entité élémentaire qu il n est pas possible de décomposer à nouveau. Les algorithmes de selection des règles utilisent cette propriété afin de selectionner ou de rejeter une règle. Une expression plus concise obligerai à découper les règles de contrôle d accès et à en former de nouvelles en fonction de l environnement de chaque agent. Ces nouvelles règles impliquent qu il ne serait pas possible d appliquer notre troisième assertion (R3) puisque celui-ci implique une notation commune des règles de contrôle d accès entre agents de contrôle d accès. Une deuxième raison est que cette notation intermédiaire permet d avoir une confiance plus importante dans le service de contrôle 122

131 Le contrôle d accès dans les réseaux ATM - Gestion du contrôle d accès d accès puisque la traduction de ce langage intermédiaire simplifie à la fois le processus de traduction et de séléction des règles. Un autre problème provient du nombre de messages échangés par les agents pour appliquer l assertion R3. Dans le cas de notre exemple comprenant 40 noeuds, l application de l assertion R3 a provoqué l échange de messages pour 270 règles d interdiction spécifiées. Ces messages peuvent surcharger le réseau. Si on suppose que la taille des paquets générés pour chaque message du PEICA est de 64 octets (la taille des informations produites par le PEICA est de l ordre d une dizaine d octets), on peut évaluer la charge moyenne générée par le mécanisme pour chacun des 48 liens du réseau à 80 ko. Cette charge bien que raisonnable pourrait être diminuée de manière importante en groupant les messages du PEICA relatifs à plusieurs règles dans un même paquet IP et en émettant ces paquets de manière périodique. Nous montrons par ailleurs en section 4 que l utilisation de l assertion R3 est d une utilité faible dans le cas de certaines architectures de réseau. Il est donc possible dans ce cas de supprimer les échanges de messages générés par l application de l assertion R3. Un dernier problème lié à notre approche est celle de la mise à jour des règles dans le cas de modifications fréquentes de l environnement des agents. En effet ces changements peuvent, dans le cas de politiques de contrôle d accès de grande taille, demander une puissance de calcul importante puisque les politiques globales peuvent comporter un nombre important de règles. Ce problème peut par exemple survenir lors d oscillations entre plusieurs routes entre deux points du réseau. Afin de résoudre ce problème, plusieurs voies peuvent être suivies. La première pourrait consister à précalculer pour certains évènements fréquents, des profils qu il serait possible d appliquer sans avoir à passer l ensemble des règles en revue. Il serait alors possible de modifier les configurations à un moindre coût. Une autre possibilité pourrait se baser sur le fait que la taille de la politique implémentée par chaque contrôleur est généralement beaucoup plus faible que la politique totale. De ce fait, la suppression des règles n ayant plus de raison d être appliquée peut être réalisée de manière beaucoup moins couteuse que l ajout de nouvelles règles. Une solution pourrait donc être d autoriser une certaine latence dans l ajout des nouvelles règles (ajout à fréquence fixes) sans compromettre la sécurité du réseau. De manière opposée, les suppressions de règles se fairaient de manière expresse dès la découverte d un changement. Cependant cette approche pourrait perturber l utilisation du réseau par ses usagers en bloquant de manière temporaire des communications autorisées Conclusion Dans cette section nous avons présenté deux types d architectures de gestion automatique du contrôle d accès. Bien que nous n ayons pas montré de résultats de distribution concernant notre première proposition, il est clair que ceux-ci ne peuvent pas être fortement différents de ceux générés par notre seconde proposition. En effet, ces deux architectures constituent deux implémentations différentes des trois critères de distribution décrits en section 3.1. Les différences entre nos deux architectures viennent du fait que celles-ci répondent à deux besoins différents. La première permet à l officier de sécurité d avoir une idée précise des règles de contrôle d accès appliquées par les équipements constituant son architecture. Elle est particulièrement bien adaptée aux architectures de réseaux dans lesquelles les changement de routage sont très faibles. A l inverse notre seconde proposition offre à l officier de sécurité la possibilité de ne pas avoir à gérer la complexité introduite par les changements de topologie du réseau qu il administre puisque notre architecture s adapte automatiquement à ceux-ci et, évite par une interaction forte entre le système de gestion du contrôle d accès et le système de routage des trous de sécurité pouvant être observés dans les autres propositions de gestion automatique du contrôle d accès. Elle est donc particulièrement bien adaptée aux architectures de réseaux où ces changement sont fréquents. Cependant elle ne permet à l officier de sécurité qu une vision a posteriori de la configuration des équipements de contrôle d accès. 123

132 Le contrôle d accès dans les réseaux ATM - Gestion du contrôle d accès 4. Intégrité du contrôle d accès par redondance 4.1. Introduction Dans cette section, nous proposons une technique ([Pa00b]) permettant à une officier de sécurité d accroître la confiance qu il peut avoir dans le service de contrôle d accès fourni par l architecture de contrôle d accès qu il a défini. Cette technique, bien que fonctionnant avec n importe quelle architecture de contrôle d accès est particulièrement bien adaptée aux architectures distribuées de contrôle d accès reposant sur l utilisation d une méthode automatique de gestion du contrôle d accès telle que celle que nous avons présenté en section 3. En effet de telles méthodes, associées à des architectures de contrôle d accès telles que celle que nous proposons en section 2, chapitre 5 ou celle proposée par Bellovin ([Bell99], chapitre 2, section 2.4.3), peuvent provoquer l attribution de règles de contrôle d accès à des équipements extrémités. Ces équipements étant accessibles physiquement par leurs utilisateurs, il est difficile d en assurer l intégrité sans recourir à des moyens d intégrité physique tels que ceux décrits en section 5.2, chapitre 2. Or de telles mesures sont relativement onéreuses et ne sont pas toujours totalement efficaces ([And96]) car l utilisateur trouve souvent un moyen de détourner ces défenses. Il est donc également difficile d assurer l intégrité de la politique de contrôle d accès qui peut être mise en oeuvre par ce type d équipement. D autre part la multiplication d équipements de contrôle d accès rend leur contrôle plus difficile que celui d un seul équipement par le fait que ce contrôle nécessite une quantité de travail proportionnelle au nombre d équipements à contrôler. Dans cette section nous définissons une méthode, qui, pour de telles architectures, permet d augmenter la confiance qu un officier de sécurité peut avoir dans le service de contrôle d accès sans avoir recours à un système de protection physique. Cette section est constituée de la manière suivante. Dans un premier temps nous expliquons le principe de notre technique. Nous montrons ensuite, au travers de simulations, l impact de notre technique sur les performances de contrôle d accès d une architecture de contrôle d accès distribuée. Enfin, nous discutons les avantages et inconvénients de notre approche Principe Nous avons vu en section 3 que les architectures de gestion automatique de contrôle d accès se basaient généralement sur trois règles afin de fournir aux équipements une configuration optimale. L une d entre elle, (appelée assertion R3) se base sur le type de règle (règle d interdiction et règle d autorisation) afin d améliorer le positionnement des règles vis à vis d une optimisation uniquement basée sur la topologie du réseau (assertion R2). Nous avons montré en section que cette optimisation apportait une amélioration relativement faible du nombre moyen de règles par noeuds. Le principe de notre méthode d amélioration de l intégrité se base sur cette dernière assertion. Nous prétendons qu une application partielle de cette optimisation implique la duplication de règles d interdiction dans les équipements du réseau et de ce fait permet à l officier de sécurité d augmenter la confiance qu il peut avoir dans le service de contrôle d accès qu il administre en particulier si les équipements implémentant ces règles sont inaccessibles physiquement des usagers du réseau. Cette propriété peut s expliquer pour plusieurs raisons. Nous avons montré précédemment qu assurer l intégrité d un processus de contrôle d accès situé sur un équipement auquel un utilisateur a totalement accès n est pas une opération facile. Par contre l utilisation d outils de contrôle d accès réseau centralisés tels que le firewall ont montré que ces outils, lorsqu ils étaient physiquement protégés et correctement administrés pouvaient être relativement difficiles à attaquer. Si on considère que les usagers d un réseau n ont un accès total qu aux équipements qui sont de leur responsabilité (leur station de travail par exemple) on peut alors qualifier l intégrité du processus de contrôle d accès fourni par ces équipements comme peu sûre alors que l intégrité du processus de contrôle d accès fourni par des équipements physiquement inaccessibles peut être classée comme plus sûre. Or, nos propositions de gestion automatique du contrôle d accès présentées en section 3, comme celles présentées en section 4.2.4, chapitre 2 permettent l attribution de règles de contrôle d accès aux équipements d extrémités. De ce fait ces règles peu- 124

133 Le contrôle d accès dans les réseaux ATM - Gestion du contrôle d accès vent être facilement contournées par les possesseurs de ces équipements. Ce problème est important dans le cas des règles d interdiction puisque celles-ci, contrairement aux règles d autorisation, peuvent n être attribuées qu à un outil de contrôle d accès dans le réseau. Notre proposition consiste donc à provoquer un duplication partielle des règles d interdiction afin d empêcher des utilisateurs malveillants de contourner la politique de contrôle d accès. Cette proposition peut en quelque sorte être vue comme une extension des architectures redondantes de contrôle d accès proposées dans [Che94] et [Cha95] aux architectures de contrôle d accès distribuées. L application de cette proposition ne conduit cependant pas à une architecture de contrôle d accès centralisée car: Le service de contrôle d accès reste distribué puisque chaque équipement de contrôle d accès n implémente qu une partie de la politique de contrôle d accès. De ce fait l amélioration de performance due à la distribution n est pas évitée. Comme nous le montrons en section 4.3, la surcharge maximale (c est à dire le nombre de règles répliquées) due à l application de cette proposition est généralement faible. L optimisation R3 peut être partiellement appliquée afin de diminuer le nombre moyen de règles par noeud. L officier de sécurité peut ainsi faire un compromis entre intégrité et performances Simulations Introduction Le coût généré par l application de cette proposition est fonction de deux facteurs: La proportion de règles d interdiction dans la politique de contrôle d accès. La taille et la forme du réseau. En effet ceux-ci font varier la taille moyenne des chemins empruntés par les communications devant être contrôlées. Afin d évaluer l impact de ces deux paramètres au moyen de simulations nous considérons deux processus de distribution. Le premier est basé sur les assertions R2 et R3 alors que le second utilise uniquement l assertion R2 définie en section 3. Nous pouvons alors en comparant les résultats de distribution calculer la surcharge maximale pouvant être générée par notre méthode d amélioration de l intégrité. Tableau 37. Classement des règles. Type de règle ALLOW DENY Non spécifiée 5 5 Spécifiée Les simulations sont réalisées sur le simulateur ns avec l architecture de distribution décrite en section D une manière analogue à l analyse réalisée dans cette section, nous considérons deux types de politiques de contrôle d accès. Une première, analogue à celle présentée dans le tableau 34 et appelée pol-1 contient un nombre faible de règles d interdiction. Nous considérons également un second type de politique de contrôle d accès contenant un plus grand nombre de règles d interdiction. Celle-ci, appelée pol-2 est détaillée dans le tableau Résultats théoriques Le type de réseau utilisé pour les simulations que nous effectuerons en section est un arbre d ordre 3. Comme nous l avons montré en section 3.3.3, la topologie du réseau n a pas un impact important sur l efficacité de nos critères de simulation. Le choix d un réseau en arbre d ordre 3 s est donc fait afin de faciliter nos calculs. En fonction de cette topologie connue, il nous est possible de calculer l impact de l utilisation de l assertion R3 et de ce fait d évaluer la surcharge maximale pouvant être causée par notre méthode d amélioration de l intégrité. Ce résultat nous permettra par la suite de vérifier la précision de nos simulations. Comme 125

134 Le contrôle d accès dans les réseaux ATM - Gestion du contrôle d accès nous l avons précisé précédemment l impact de l utilisation de l assertion R3 dépend de la taille du réseau et de la composition de politique de contrôle d accès. Le nombre moyen de règles Nr0 produit par notre méthode de distribution lors de l utilisation des assertions R2 et R3 peut s exprimer de la manière suivante: Nr0 = u. n + avgl(n). sa + sd où u est le nombre de règles non spécifiées, sa le nombre de règles d autorisation spécifiées, sd le nombre de règles d interdiction spécifiées et avgl(n) la longueur moyenne entre deux feuilles dans un arbre d ordre 3 composé de n noeuds. Dans le cas de l utilisation unique de l optimisation R2 le nombre moyen de règle Nr1 est le suivant: Nr1 = u. n + avgl(n). (sa + sd) La différence entre Nr0 et Nr1 est liée à la réplication des règles d interdiction spécifiées. En effet dans le dans le premier cas, les règles d interdiction spécifiées ne sont attribuées qu à une seul équipement conformément à R3 alors que dans le deuxième cas, celles-ci sont attribuées à tous les filtres sur le chemin entre la source et la destination spécifiée par la règle. Le gain G engendré par l utilisation de R3 est donc: Résultats de simulation G = Nr1 - Nr0 = sd. (avgl(n) - 1) Afin d évaluer l impact de l utilisation de l assertion R3, nous faisons varier la taille du réseau de 4 à 121 noeuds (4, 13, 40 et 121 noeuds) et simulons la distribution de chaque politique. Nous supposons que chaque noeud est capable d implémenter toutes les fonctions de contrôle d accès (c est à dire que chaque noeud est un équipement de contrôle d accès implémentant une partie de la politique de contrôle d accès). Pour chaque distribution nous comparons les résultats d une distribution utilisant les assertions R2 et R3 avec ceux obtenus dans le cas d une distribution n utilisant que l assertion R2. Figure 64. Efficacité du critère R3 (en nombre de règles) pol-1 th. pol-2 th. pol-1 pr. pol-2 pr. La figure 64 fournit le gain en nombre de règle quand les deux critères d optimisation sont utilisés. Les résultats pour pol-1 sont indiqués avec une ligne pleine alors que ceux concernant la politique pol-2 sont indiqués en pointillés. Ces résultats montrent que, comme cela était prévisible, l efficacité du critère R3 augmente avec la taille du réseau. Cependant le paramètre qui modifie le plus l efficacité du critère R3 est la composition de la politique. Nous avons également représenté en figure 64, les gains théoriques (pol-1 th. et pol-2 th.) calculés au moyen de la formule présentée en section précédente. Ceux-ci sont représentés au moyen d une ligne hachurée et montrent que les résultats théoriques sont très proches de ceux obtenus par nos simulations. Les différences s expliquent par l utilisation d une fonction aléatoire non idéale par nos simulations. 126

135 Le contrôle d accès dans les réseaux ATM - Gestion du contrôle d accès Figure 65. Efficacité relative du critère R3 (en %) R2 (pol-1, pol-2) R3 (pol-1) R3 (pol-2) Lorsqu elle est comparée avec l efficacité de l optimisation apportée par le critère R2 (décrit par une ligne hachurée en figure 65), l efficacité apportée par le critère R3 est relativement faible pour les réseaux importants (moins de 3% pour les deux politiques dans un réseau de 121 noeuds, moins de 1% pour notre politique pol-1). De ce fait la surcharge générée par l utilisation de notre méthode d amélioration de l intégrité peut être considérée comme faible dans le cas de réseaux possédant un grand nombre d équipements de contrôle d accès. Ceci n est pas vrai dans le cas de réseau possédant un petit nombre d équipements de contrôle d accès (surcharge de 19% dans un réseau avec quatre équipements). Avec ce type d architecture, l optimisation R3 présente toujours un intérêt, en particulier si la politique de contrôle d accès contient un grand nombre de règles d interdiction. Une application partielle de l optimisation R3 peut être dans ce cas intéressante Conclusion Dans cette section nous avons proposé une modification des méthodes actuelles de gestion automatique de contrôle d accès afin d y introduire la notion d intégrité. Nous avons montré comment, en modifiant légèrement les architectures de gestion automatique du contrôle d accès présentées en section 3, il était possible d augmenter la confiance que l on pouvait avoir dans le service de contrôle d accès fourni par une architecture distribuée de contrôle d accès. Nous avons également montré au travers de simulations que cette proposition était particulièrement intéressante dans le cas d une politique de contrôle d accès possédant un faible nombre de règles d interdiction et de réseaux composés d un nombre suffisamment grand d équipements de contrôle d accès. La pénalité générée par notre méthode est généralement négligeable dans ce cas. Nous avons de plus donné un moyen de diminuer la pénalité générée par l utilisation de notre approche dans le cas de réseaux comprenant un petit nombre d équipements de contrôle d accès et utilisant une politique constituée d un grand nombre de règles d interdiction. 5. Conclusion Dans ce chapitre nous avons développé les éléments permettant d assurer une gestion automatique, efficace et sûre d une architecture de contrôle d accès. Bien que nos propositions puissent être utilisées dans le cas d architectures centralisées de contrôle d accès, elles sont particulièrement bien adaptées à la gestion d architectures distribuées de contrôle d accès telles que celles présentées en section chapitre 2 ou celle que nous proposons en section 2, chapitre 5. Les raisons de cette adaptation sont multiples. Tout d abord nos propositions permettent d exprimer une politique de contrôle d accès dans un langage qui est à la fois ergonomique et indépendant de ceux utilisés par les équipements de contrôle d accès. Les langages que nous proposons permettent donc de répondre d une part au problème d hétérogénéité des équipements de contrôle d accès et d autre part au problème lié au nombre d équipements devant être gérés. 127

136 Le contrôle d accès dans les réseaux ATM - Gestion du contrôle d accès De plus, nous proposons des architectures de gestion automatique du contrôle d accès qui permettent de distribuer automatiquement la politique de contrôle d accès sur les équipements devant l implémenter. Cette distribution est réalisée de manière efficace, c est à dire en faisant en sorte que chaque équipement implémente le plus petit sous-ensemble de règles possible de la politique de contrôle d accès. Nous avons montré au travers de simulations que nos critères d optimisation permettaient d obtenir des politiques de complexités équivalentes à celles qui seraient obtenues par un officier de sécurité expérimenté. Nous avons par ailleurs montré comment éviter le problème lié à l utilisation d un modèle statique du réseau en créant une interaction entre le système de gestion automatique du contrôle d accès et les agents de routage présents dans le réseau. Enfin nous avons montré comment il était possible de répondre en partie au problème de l intégrité du service de contrôle d accès dans les architectures de contrôle d accès distribuées en créant une réplication partielle de certaines règles de contrôle d accès. Nous avons également montré au travers de simulations que le surcoût engendré par l utilisation de cette proposition pouvait être négligeable dans le cas de réseaux comprenant un grand nombre d équipements de contrôle d accès. Nous avons par ailleurs montré comment il est possible de limiter le surcoût généré par l utilisation de cette mesure dans le cadre d autres réseaux. 128

137 CHAPITRE 7 Conclusions et perspectives Dans ce chapitre nous résumons les apports de cette thèse et montrons comment nos travaux peuvent se prolonger dans le futur. 1. Analyse L évolution actuelle des réseaux qui vise d une part à fournir aux utilisateurs des bandes passantes plus importantes et des possibilités de différenciation vis à vis des flux qu ils désirent transporter va à l encontre des outils de contrôle d accès réseau tels qu ils sont aujourd hui conçus. Cependant dans un même temps, les problèmes de sécurité en général et de contrôle d accès en particulier deviennent de plus en plus sensibles. Les problèmes à résoudre pour faire face à ce dilemme sont de plusieurs ordres. Le premier vient de l apparition de nouveaux paramètres de contrôle d accès dus en partie aux nouvelles capacités du réseau. Les outils traditionnels de contrôle d accès ne sont pour le moment pas en mesure de tirer avantage de ceux-ci afin de donner à l officier de sécurité une plus grande latitude dans l expression de sa politique de contrôle d accès. Nous faisons dans le chapitre 4 une étude exhaustive des paramètres pouvant être utilisés dans le cas des réseaux ATM et classons ceux-ci en fonction de leur utilité. Cette partie de notre travail est difficilement comparable avec d autres travaux étant donné que nous sommes actuellement les seuls à avoir effectué ce type de démarche. Le second problème vient de la capacité des architectures actuelles à supporter des débits élevés. Enfin le dernier point concerne la capacité de celles-ci à assurer le respect des contraintes de qualité de service négociées entre l utilisateur et le réseau. Vis à vis de ces problèmes, nous proposons deux approches. La première approche consiste à faire partager à l ensemble des équipements du réseau ayant des capacités de contrôle d accès la tâche de fournir le service de contrôle d accès. Vis à vis de travaux antérieurs portant sur une distribution du service de contrôle d accès, notre travail présente plusieurs originalités. La première est de proposer l utilisation de tous les équipements du réseau pour fournir un service qui était généralement attribué soit aux équipements extrémités, soit aux équipements réseau. De plus nous intégrons la notion de respect de la qualité de service qui n avait pas été prise en compte par les propositions antérieures en définissant un processus de contrôle d accès non bloquant à même de prendre en compte, en plus des paramètres de contrôle d accès traditionnels, les paramètres de contrôle d accès définis dans le chapitre 4. Enfin l architecture que nous proposons est telle qu elle peut facilement être ajoutée à des équipements déjà existants. On pourrait se demander l utilité de pouvoir réaliser à la fois un contrôle d accès au centre du réseau et sur les systèmes extrémité. Il est selon nous peu probable que le contrôle d accès au centre du réseau disparaisse du jour au lendemain et cela du fait de plusieurs raisons. Il y a d une part une certaine incohérence au 129

138 Le contrôle d accès dans les réseaux ATM - Conclusions et perspectives niveau des solutions totalement distribuées à accorder leur confiance à l utilisateur final par le fait qu elles lui attribuent la capacité de déjouer les mécanismes de sécurité sans trop de difficulté et à proclamer leur capacité à déjouer les attaques de celui-ci puisque les statistiques montrent qu une majorité des attaques sur les réseaux d entreprise proviennent aujourd hui de leurs utilisateurs légitimes. Il semble difficilemment envisageable de concilier ces deux aspects sans attribuer au moins une partie de la politique de contrôle d accès à des équipements dignes de confiance. D autre part une solution totalement distribuée suppose l absence d attaques directes de type dénis de service à la fois sur les équipements du réseau et sur les équipements extrémité. Les évènements récents montrent clairement que cette hypothèse est peu crédible. Finalement Il semble évident que certains équipements seront difficiles, voire impossibles à sécuriser de manière distribuée. On voit mal des imprimantes ou des hubs posséder demain leur propres mécanismes de sécurité. De ce fait notre proposition de placement des services de contrôle d accès sur l ensemble des équipements du réseau en ayant la capacité nous semble réaliste de par le fait qu elle conserve les principaux avantages de la distribution tout en évitant les inconvénients majeurs puisqu elle suppose une confiance limitée dans le service de contrôle d accès rendu par chaque équipement. Notre première proposition présente cependant un inconvénient majeur. La sécurité du service de contrôle d accès n est assurée que si le mécanisme de contrôle d accès est suffisamment rapide pour ne pas manquer d évènements. Ce type de problème est particulièrement sensible dans le cas des équipements réseau puisque ceux-ci sont amenés à traiter plus de communications que les équipements extrémité. La rapidité du mécanisme de contrôle d accès est à la fois liée à la puissance de l équipement implémentant le mécanisme de contrôle d accès, à la fréquence des contrôles et à l algorithme de classement utilisé. Il est donc essentiel d assurer la performance du mécanisme de contrôle d accès. C est pourquoi notre seconde proposition s emploie à développer un algorithme de classement de flux permettant de classer un flux en un temps dépendant uniquement du nombre de champs de classement à considérer. Vis à vis des autres algorithmes de classement actuellement proposés, notre algorithme possède une complexité temporelle indépendante du contenu de la politique de contrôle d accès. Cette complexité temporelle est généralement plus faible que celle atteinte par les autres propositions. Enfin, nous avons montré que la complexité spatiale de notre algorithme est dans la pratique généralement raisonnable. Notre seconde approche consiste à intégrer cet algorithme de classement dans une architecture fournissant un service de contrôle d accès au centre du réseau de manière bloquante. Le respect des contraintes de débit et de qualité de service se fait par l implémentation de notre algorithme sur une architecture matérielle performante appelée IFT. Celle-ci, lorsqu elle est utilisée avec notre algorithme, garantit une borne maximale de modification de la QoS très faible tout en assurant un débit élevé. Vis à vis des autre propositions de contrôle d accès bloquante pour les réseaux ATM, notre proposition se différencie par plusieurs aspects. Le premier est de fournir des performances plus intéressantes que les solutions actuellement implémentées. Un second point tient au fait que notre architecture n est pas sensible comme les propositions antérieures aux dénis de service qui tirent parti de leur méthode de classement des flux. Enfin notre architecture permet de tirer parti des paramètres de contrôle d accès décrits en chapitre 4. L hétérogénéité dans nos propositions d architectures de contrôle d accès et la distribution des mécanismes à travers le réseau pose le problème de leur gestion. Ce problème de gestion peut se décomposer en trois sous-problèmes. Le premier consiste à trouver un moyen générique et ergonomique de définir une politique de contrôle d accès. Nous proposons de ce fait dans le chapitre 6, deux langages permettant de décrire des politiques de contrôle d accès. Le premier généré à partir d une proposition de spécification de l IETF a pour intérêt de fournir une interface de configuration proche de celles qui existent aujourd hui sur les produits du marché. Elle est cependant inadaptée à l expression d une politique de contrôle d accès pour l ensemble d un réseau par le fait qu elle ne permet pas une définition concise des politiques de contrôle d accès de grande taille. C est la raison pour laquelle nous proposons un langage plus élaboré permettant de définir les politiques de contrôle d accès de manière plus concise en utilisant la notion de rôle. Le second sous-problème consiste à définir une architecture de distribution de la politique de contrôle d accès sur les équipements du réseau à protéger. Vis à vis de ce problème, nous proposons deux solutions 130

139 Le contrôle d accès dans les réseaux ATM - Conclusions et perspectives basées sur deux approches différentes. La première consiste à définir de manière centralisée quelles parties de la politique de contrôle d accès doivent être attribuées à chaque équipement en fonction d un modèle du réseau. L apport principal de notre approche est de ne pas limiter la représentation du réseau à un seul niveau protocolaire afin de pouvoir traiter des réseaux où le routage se fait à plusieurs niveaux tels que les réseaux IP sur ATM. Cette architecture possède cependant plusieurs inconvénients par le fait qu elle se base sur un modèle statique du réseau à protéger. Ce problème est d autant plus sensible dans les réseaux de type IP sur ATM de par le fait que les connexions ATM peuvent être construites dynamiquement, ce qui peut engendrer une obsolescence rapide du modèle du réseau. Nous avons montré que l utilisation d un modèle statique entrainait d une part un coût plus important en matière d administration et pouvait conduire à des trous temporaires de sécurité. Il est donc clair qu une telle architecture n a d intérêt que si l on peut s assurer que la topologie du réseau reste relativement statique. Nous proposons de ce fait une seconde architecture de gestion automatique du contrôle d accès où la décision de distribution ne se fait pas de manière centralisée mais sur chaque équipement de contrôle d accès en fonction de l environnement de celui-ci. Cette architecture permet de résoudre les problèmes liés à un modèle statique par le fait qu elle est à même de conditionner les modifications des tables de routage aux opérations de reconfiguration de la politique de contrôle d accès. Nous avons par ailleurs montré qu il était possible dans ce type d architecture d éviter les interactions entre les équipements et l officier de sécurité une fois la politique de contrôle d accès définie. Figure 66. Chemin suivi pour la résolution des problèmes exposés au chapitre 3. Faiblesse des paramètres de C.A. Problèmes de débit Problèmes de respect de la QoS Nouveaux paramètres de C.A. au niveau ATM Architecture Distribuée et non bloquante de C.A. Nouvel Algorithme de classement. Problème de gestion du C.A. Architecture Centralisée et bloquante de C.A. Langages de Description du C.A. Critères de distribution des politiques de C.A. Architectures de gestion du C.A. Problème de l Intégrité du Service de C.A. Enfin le troisième sous-problème porte sur la définition de critères permettant d attribuer aux équipements une portion de la politique de contrôle d accès de telle sorte que d une part la politique de contrôle d accès soit appliquée sur l ensemble du réseau et que d autre part le processus de classement soit aussi performant que possible puisque, comme nous le montrons dans le chapitre 2, les performances de celui-ci dépendent généralement du nombre de règles qu il doit utiliser. Nous montrons comment il est possible de synthétiser les critères de distribution qui avaient jusque-là été proposés et comment ils peuvent être implémentés simul- 131

140 Le contrôle d accès dans les réseaux ATM - Conclusions et perspectives tanément. Nous introduisons par ailleurs un critère complémentaire portant sur le type d action défini pour chaque règle. Nous montrons que ce critère peut apporter une amélioration sensible dans le cas de petites architectures de contrôle d accès en diminuant le nombre moyen de règles de contrôle d accès par noeud. La distribution d une politique de contrôle d accès ne peut avoir d intérêt que dans le cas où il est possible d avoir une certaine certitude que celle-ci va être appliquée. Nous montrons de ce fait dans le chapitre 6 comment il est possible au moyen d une altération des critères de distribution d améliorer la confiance qu un officier de sécurité peut avoir dans le service fournis par son architecture de contrôle d accès. Notre technique se base sur la réplication sur les éléments du réseau des règles de contrôle d accès les plus sensibles. Nous montrons que cette technique possède un coût qui peut être considéré comme négligeable dès le moment où l architecture de contrôle d accès comprend un nombre d équipements suffisamment important. Le coût de cette technique peut par ailleurs être limité en contrôlant la réplication de ce type de règle. Pour finir, le lecteur pourra trouver en figure 66 un résumé du chemin parcouru dans ce document en lui donnant une vision synthétique. Il indique dans des cadres blancs les problèmes à résoudre et dans des cadres grisés les éléments développés pour les résoudre ainsi que les interdépendances entre ces éléments. Parmis ces derniers, les cadres les plus foncés indiquent les éléments ayant donné lieu à une implémentation. 2. Travaux futurs Comme nous l avons montré en section précédente, les apports de notre travail se sont concentrés sur quatre points. Nous montrons dans cette section comment ils pourraient être étendus dans l avenir Paramètres de contrôle d accès Une des extensions la plus facile de notre architecture pourrait consister à trouver de nouveaux paramètres de contrôle d accès. La voie la plus évidente dans ce domaine est de trouver ceux-ci en ne se limitant pas à l analyse du modèle ATM mais en tenant compte des informations générées par les utilisations du modèle ATM. Ces informations permettraient d affiner le contrôle d accès actuellement réalisé. Cependant il faut noter que le nombre de paramètres de contrôle d accès mis à jour par une telle recherche risque d être particulièrement élevé. Il conviendrait donc de classer de nouveau ces paramètres non seulement en fonction de la popularité de l utilisation considérée mais également en fonction de l apport de l utilisation du paramètre du point de vue de la sécurité. Ceci signifie qu une telle étude doit être précédée d une analyse des risques des différentes utilisations, c est à dire de la mise à jour de nouvelles attaques. La seconde voie permettant d étendre les paramètres de contrôle d accès est de considérer de nouveaux usages des réseaux ATM. Dans les dernières années, des utilisations non normalisées par l ATM-Forum telles que MPLS ont fait leur apparition. Ces approches génèrent des informations qu il peut être intéressant de prendre en compte dans les équipements de contrôle d accès. Il conviendrait donc de voir d une part de quelle manière ces nouvelles utilisations interagissent avec le modèle ATM et d autre part quelles informations propres sont générées. Comme dans le cas précédent, les paramètres pouvant être obtenus au moyen de ces analyses doivent être classés. Si on se place à un niveau protocolaire plus élevé, il nous semble que certaines des fonctions de contrôle d accès qui sont aujourd hui réalisées au moyen de passerelles applicatives doivent être analysées afin de formaliser les services de contrôle d accès qu elles assurent réellement. Ces passerelles fournissent généralement un service de contrôle d accès qui n est pas exprimé au moyen d une politique de contrôle d accès mais qui est simplement codé de manière statique dans le logiciel. Une telle formalisation permettra d extraire les paramètres de contrôle d accès utilisés par ces services. Une fois ces paramètres identifiés et classés, ceux-ci pourraient être utilisés dans de nouvelles architectures de contrôle d accès. 132

141 Le contrôle d accès dans les réseaux ATM - Conclusions et perspectives 2.2. Mécanismes de contrôle d accès Les architectures de contrôle d accès que nous proposons peuvent être étendues de plusieurs façons. La plus évidente consiste à prendre en compte les paramètres de contrôle d accès potentiels de la section précédente. L intégration de tels paramètres dans nos deux architectures de contrôle d accès peut se faire de la manière suivante. Dans le cadre de notre architecture distribuée non bloquante, la prise en compte de ces paramètres passe par l étude de nouvelles bases de données de gestion afin d y trouver les paramètres de contrôle d accès adéquats. Nous montrons dans [Pa98c] que dans le cas des utilisations des réseaux ATM, il est possible de trouver la plupart des informations utiles dans des bases de données normalisées. Les paramètres de contrôle d accès concernant les utilisations non normalisées ainsi que les paramètres relevant de niveaux protocolaires supérieurs nécessiteraient cependant des études complémentaires. L IETF semble aujourd hui engagé dans une voie assurant la définition d une base de donnée de gestion particulière pour chaque type d utilisation ou de support du réseau internet. Il est de ce fait probable qu il sera possible de trouver la plupart des paramètres adéquats de contrôle d accès dans ces bases. Une seconde extension de notre architecture distribuée pourrait consister à introduire notre algorithme de classement rapide dans une implémentation de celle-ci. Cette introduction devrait se faire de manière relativement aisée étant donné la proximité des opérations réalisées et des politiques manipulées par les deux techniques. Cet algorithme nous permettrait de limiter le coût de la technique de lecture périodique des variables en diminuant la complexité temporelle du traitement des variables. L utilisation de cette technique permettrait de ce fait d augmenter la sécurité apportée par un mécanisme asynchrone en diminuant les chances pour celui-ci de rater un évènement. Vis à vis de notre architecture centralisée, les évolutions sont multiples. Une campagne de tests dans un environnement réel au sein du réseau ATM de l armée francaise devrait nous permettre tout d abord de valider celle-ci de manière plus approfondie et à des débits plus élevés que ceux pouvant être générés pour le moment dans notre maquette. Ces tests nous permettront par ailleurs d accéder à de nouvelles politiques de contrôle d accès. Vis à vis de l algorithme de classification, nous avons entrepris des études complémentaires utilisant la fréquence d apparition des valeurs des champs afin de précalculer un ordre de parcours des champs avant la construction de la structure de classification. Cet ordre de construction devrait permettre d obtenir une structure de classification d une taille plus faible par le fait que les champs provoquant le plus grand nombre de réplication des arbres d analyse se placeront en fin d analyse. L extension la plus prévisible de notre architecture centralisée consiste à adapter notre architecture aux environnements sans ATM puisque ceux-ci sont également soumis aux problèmes de débits et de respect de la qualité de service. Dans cette perspective, nos partenaires de France Telecom-RD travaillent sur une nouvelle version des cartes IFT dans laquelle l unité d analyse n est plus la cellule ATM mais le paquet IP. Cette nouvelle version permet d une part une largeur d analyse plus importante et d autre part l utilisation de mémoires d un type différent permettant la construction d une mémoire trie plus grande et moins onéreuse. Celle-ci devrait permettre l utilisation d un motif de reconnaissance plus grand, autorisant comme nous l avons montré dans le chapitre 5 des vitesses d analyse plus importantes. La taille de cette mémoire devrait également permettre le stockage de politiques de contrôle d accès de plus grande taille. Nos partenaires travaillent par ailleurs sur une méthode permettant d éviter la réplication des arbres d analyse dans la mémoire trie en conservant au cours de l analyse d un flux l ensemble des règles applicables. Cette technique permettrait de réduire fortement la taille nécessaire au stockage de la structure de classification sans perdre l avantage d une analyse en temps borné. L augmentation de la largeur d analyse devrait faciliter l utilisation de paramètres de contrôle d accès tels que des paramètres applicatifs. Il n est cependant pas évident que notre algorithme qui avait utilisé les redon- 133

142 Le contrôle d accès dans les réseaux ATM - Conclusions et perspectives dances pouvant être trouvées dans les politiques de contrôle d accès pour les réseaux Internet puisse de nouveau tirer parti de celles-ci dans le cas de politiques utilisant de nouveaux paramètres de contrôle d accès. Il est de ce fait indispensable de pouvoir tester notre algorithme dans le cas de politiques de contrôle d accès étendues. Ces tests permettront de juger de la nécessité de la définition d un nouvel algorithme de classement, plus adapté au traitement de règles longues. D une manière plus générale, il nous semble que le problème majeur des architectures distribuées de contrôle d accès actuelles est l absence d état entre les différents filtres pouvant se présenter sur le chemin d une communication. Cette absence d état provoque la répétition d une partie des opérations de contrôle d accès. Une telle répétition atténue le bénéfice que l on aurait pu penser tirer de la répartition du service de contrôle d accès. Il est donc clair que de nouvelles architectures de contrôle d accès, tirant parti de ce constat pourraient de nouveau améliorer les performances d architectures de contrôle d accès distribuées Gestion du contrôle d accès Notre langage de contrôle d accès de bas niveau, bien que provenant d une proposition de normalisation, reste propriétaire de par le fait de ses extensions. Il est de ce fait important de fournir aux utilisateurs de nos architectures de contrôle d accès les moyens de traduire facilement leur politiques de contrôle d accès vers notre langage. Nous avons à ce sujet commencé des développements permettant la traduction automatique de politiques de contrôle d accès destinées aux routeurs les plus répandus vers notre langage de contrôle d accès. Le traducteur aujourd hui disponible concerne les routeurs NSC. Celui-ci devrait être prochainement étendu afin de permettre le traitement de listes de contrôle d accès provenant de routeurs Cisco. Une étape importante afin de valider nos architectures actuelles de gestion du contrôle d accès est leur implémentation et leur test dans un environnement réel afin de pouvoir juger d une manière générale des améliorations apportées par les critères de distribution dans le cas de politiques de contrôle d accès réelles. Une implémentation permettrait également de juger, dans le cadre de notre architecture de gestion distribuée, des possibilités d interactions entre agents de routage et agents de gestion du contrôle d accès. Une telle implémentation devra également montrer comment notre architecture peut tirer parti de protocoles tels que SNMPv2*, SNMPv3, COPS ou du protocole SPP (Security Policy Protocol) en cours de définition au sein du groupe de travail IP Security Policy de l IETF afin de sécuriser les communications entre agents et entre agents et gestionnaire. Une extension de nos architectures de gestion pourrait se baser sur l intégration de méthodes de gestion d autres services de sécurité tels que la confidentialité ou l authentification. Cette intégration se ferait à plusieurs niveaux. Elle nécessite tout d abord la modification des langages actuellement proposés afin d y introduire des éléments permettant à l officier de sécurité d exprimer à la fois des politiques concernant ces nouveaux services mais concernant également leurs interactions. Une alternative à ces modifications pourrait consister à participer à la définition du langage de description de politique de sécurité actuellement en cours de définition à l IETF ([Con00]) étant donné que celui-ci a pour objectif de répondre à certains de ces problèmes. Il est cependant dommage que le langage actuellement proposé ne prévoit pas d interaction entre les services de sécurité, d autres services tels que les services de gestion de la qualité de service. Une autre voie d extension de notre travail pourrait consister à travailler sur des méthodes formelles permettant d une part de prouver l absence d incohérence dans les politiques pouvant être exprimées et d autre part de prouver, à la manière de [Gu00], des propriétés de sécurité à partir d une modélisation du réseau. Une telle extension n est cependant pas évidente car elle demande d une part la traduction des politiques de sécurité sous une forme intermédiaire formelle et d autre part suppose un modèle fixe du réseau. Nous avons vu dans ce document que la politique de contrôle d accès qui était attribuée aux équipements de contrôle d accès pouvait avoir un impact important sur leurs performances. Il est fort probable que la situation soit la même pour d autres services de sécurité. Si l on imagine par exemple les cas où il faut, pour assu- 134

143 Le contrôle d accès dans les réseaux ATM - Conclusions et perspectives rer un service de confidentialité ou d authentification chercher de la manière la plus rapide possible la clef à utiliser, on peut constater que l on aboutit à un problème similaire. Il serait de ce fait logique d utiliser et d étendre les critères que nous utilisons afin d améliorer les performances des équipements de sécurité en limitant la taille de la politique de sécurité associée à chaque équipement. L intégration de nouveaux services à nos architectures de gestion pourrait se faire en intégrant ceux-ci à ceux déjà existant. Enfin, il serait important de s intéresser aux problèmes posés par les interactions entre le contrôle d accès réseau et la mobilité IP des équipements. En effet, les équipements peuvent dans ce cadre changer d adresse IP de manière dynamique au cours de leurs déplacements. Il convient donc dans ce cas de définir d une part un langage qui permette une adaptation dynamique de la politique de contrôle d accès en fonction de l arrivée et du départ de nouveaux équipements. Une traduction efficace de celle-ci pourrait être réalisée dans notre architecture en utilisant la capacité de celle-ci à utiliser les informations horaires pouvant être spécifiées au travers de la politique de contrôle d accès afin de profiter de la nature temporaire des allocations dynamiques d adresses Intégrité du contrôle d accès Notre technique actuelle permettant d améliorer l intégrité du service de contrôle d accès considère que la confiance que l on peut accorder à tous les équipements du réseau est équivalente. Cette supposition est généralement fausse puisque certains équipements sont plus facilement attaquables que d autres. Il serait donc intéressant, afin de limiter la réplication des règles dans le réseau tout en augmentant l intégrité du service de contrôle d accès de manière significative, d essayer d évaluer de manière quantitative la confiance pouvant être accordée aux équipements de contrôle d accès du réseau et de modifier le processus de réplication afin de tenir compte de ce paramètre. Cette technique est bien sûr valide dans le cas du contrôle d accès mais pourrait également être utilisée dans le cas d autres services de sécurité ou de gestion des communications. 135

144 Le contrôle d accès dans les réseaux ATM - Conclusions et perspectives 136

145 CHAPITRE 8 Références bibliographiques [7498-2] ISO, ISO :1989, Information processing systems -- Open Systems Interconnection --Basic Reference Model -- Part 2: Security Architecture, [Abu98] [Acc00] [And96] Joe Abusamra, ATM Net Management: Missing Pieces, Data Communications, Mai M. Accarion, C. Boscher, C. Duret, J. Lattmann, Extensive Packet Header Lookup at Gb/ s Speed for an Application to IP/ATM Multimedia Switch Router, in proc. of the World Telecommunication Congress, Mai Ross Anderson and Markus Kuhn, Tamper Resistance -- A Cautionary Note, in proc. of the 2nd workshop on electronic commerce; Oakland, California, Novembre, 1996 [ANS10] The ATM Forum Technical Committee, ATM Name System Specification Version 1.0, af-saa , Novembre [Apo97] [ASX200] T. Apostolopoulos, V. Daskalou, The role of the Time Parameter in a network security management model, in proc. of the second IEEE symposium on computers and communications, Juillet Marconi Corporation, ASX -200BX, ASX -1000, and ASX Feature Comparison, Octobre [Atg97] The ATM Forum, The ATM Forum Glossary, Mai [Atm97] [AToM98] [AUG10] ATM in Europe: The User Handbook, European Market Awareness Committee, Version 1.0, The ATM Forum, Juillet Faye Li, Michael Noto, Andrew Smith, Kaj Tesink, Definition of Supplemental Managed Objects for ATM Management, Internet Draft version 13, March The ATM Forum Technical Committee, ATM Forum Addressing User Guide Version 1.0, af-ra , Janvier

146 Le contrôle d accès dans les réseaux ATM - Références [Ba98] Dan Backman, Basking in Glory-SNMPv3, Network Computing, Août [Ba99] Y. Bartal, A. Mayer, K. Nissim, A. Wool, Firmato: A Novel Firewall Management Toolkit, in proc. of the 20th IEEE Symposium on Security and Privacy, Oakland, Mai [Bel99] S. Bellovin, Distributed Firewalls, login:, pp , Novembre [Ben98] [Ben99] [Cel99] [CES20] Carsten Benecke, Uwe Ellermann, Securing 'Classical IP over ATM Networks', in proc. of the 7th USENIX Security Symposium, january , San-Antonio, Texas, USA. C. Benecke, A parallel Packet Screen for High Speed Networks, in proc. of the 15th Annual Computer Security Applications Conference, December Celotek Corporation, CellCase622, Security at OC-12c/STM-4 data rates, Products for High-Speed Virtual Private Networking, Data Sheet, Octobre The ATM Forum Technical Committee, Circuit Emulation Service Interoperability Specification Version 2.0, af-vtoa , Janvier [Cha95] B. Chapman, E. Zwicky, Building Internet Firewalls, O Reilly, [Cha99] [Ches94] Tijani Chahed, Caroline Fayet, Gérard Hebuterne, Issues in mapping of QoS between IP and ATM, in proc. of RHDM 99, Brest, Septembre B. Cheswick, S. Bellovin, Firewalls and internet security, repelling the wily hacker, Addison-Wesley publishing company, [Cisc99] Cisco Corporation, Cisco 1600 Series: Next-Generation Internet and Intranet, [Ciz99] Gisèle Cizault, IPv6, théorie et pratique, Éditions O'Reilly, 2e édition, mars [Cla94] K. Claffy, Internet Workload Characterization, Ph.D. Thesis, UC San Diego, Juin [Clu97] [Con00] [Dal97] [Darpa97] Club de la Sécurité Informatique Francais, Evaluation concernant les conséquences économiques des incidents et sinistres relatifs aux systèmes informatiques, Février M. Condell, C. Lynn, J. Zao, Security Policy Specification Language, draft-ietf-ipspspsl-00.txt, Internet Draft, Mars C.I. Dalton, J.F. Griffin, Applying Military Grade security to the Internet, Computer Networks and ISDN Systems, No 29, p , Rome Labs., Architecture Design of a scalable Intrusion Detection System for the Emerging Network Infrastructure, Technical Report, Avril [Eagl97] Raptor Systems, Technical white paper, the Eagle Firewall, [Fau99] [Fel00] [FIPS188] O. Faure, P. Puichaud, Sécurité dans les Réseaux ATM, Rapport de mini projet réseau, ENST de Bretagne, A. Feldmann, S. Muthukrishnan, Tradeoffs for Packet Classification, in proc. of the IEEE INFOCOM 2000 conference, Mars National Institute of Standards and Technology, Standard Security Label for Information Transfer, Federal Information Processing Standards Publication 188, Septembre

147 Le contrôle d accès dans les réseaux ATM - Références [Fred60] Edward Fredkin, Trie Memory, Communications of the ACM, vol 3, p , Septembre [Fro00] Frost & Sullivan, European Internet Systems Security Markets, draft report, [Fsa00] Fore/Marconi Corporation, Firewall Switching Agent, Product Overview, [Ft98] [Gao00] [Gar96] R. Falk, M. Trommer, Integrated Management of Network and Host Based Security Mechanisms, in proc. of the 3rd Australasian Conference on Information Security and Privacy ACISP'98, Brisbane, Australia, Juillet United States General Accounting Office, Report to the Chairman, Subcommittee on Government Management, Information and Technology, Committee on Government Reform, House of Representatives, INFORMATION SECURITY Serious and Widespread Weaknesses Persist at Federal Agencies, Septembre Simon Garfinkel, Gene Spafford, Practical Unix & Internet Security, 2nd edition expanded & updated, O Reilly & Associates Inc., [Goll99] Dieter Gollmann, Computer Security, John Wiley & Sons Inc., [Gom94] [Gu97] [Gu00] [Gue00] [Gup99] [Gup00a] [Gup00b] [H245] [Hes93] [Hin99] S. Gombault, P. Rolin, L. Toutain, Network Security Probe, in proc. of the 2nd ACM Conference on computer and communications security, Joshua D. Guttman, Filtering Postures: Local Enforcement for Global Policies, in proc. of the 18th IEEE Symposium on Security and Privacy, Oakland, CA, Mai Joshua D. Guttman, Amy L. Herzog, F. Javier Thayer, Authentication and Confidentiality via IPsec, in proc. of the 6th European Symposium on Research in Computer Security, Toulouse, France, Octobre Gwenn Guéguen, Réalisation d une maquette de contrôle d accès ATM/IP à haut débit, Rapport de stage DESS ISA, Septembre P. Gupta, N. McKeown, Packet Classification on Multiple Fields, in proc. of the ACM SIGCOMM 99 Conference, Septembre P. Gupta, N. McKeown, Packet Classification using Hierarchical Intelligent Cuttings, IEEE Micro, pp 34-41, Vol. 20, No. 1, Janvier P. Gupta, N McKeown, Dynamic Algorithms with Worst Case Performance for Packet Classification,in proc. of the IFIP NETWORKING 2000 Conference, Mai ITU-T, Audiovisual and multimedia systems, Line transmission of non-telephone signals, Control protocol for multimedia communication, ITU-T recommendation H245, Mars K. Hess, R. Safford, L. Schales, The TAMU security package: An ongoing response to internet intruders, in academic environment, in proc. of the USENIX Security Conference, Susan Hinrichs, Policy-Based Management: Bridging the Gap, in proc. of the 15th Annual Computer Security Applications Conference, Phoenix, Décembre

148 Le contrôle d accès dans les réseaux ATM - Références [Hyl98] [I610] [IDC00] [IEEE96] [Ifp92] [IFT10] [IISP10] [ILMI40] [Kau96] [Kim94] P. Hyland, R. Sandhu, Management of Network Security Application, in proc. of the 21th National Information Systems Security Conference, Octobre ITU-T, Réseau numérique avec intégration des services, principes de maintenance, Principes et fonctions d'exploitation et de maintenance du RNIS à large bande, Recommandation UIT-T I610, Novembre Molly Upton, Is Security Getting Its Fair Share?, IDC IT Forecaster Newsletter, 26 Février Microprocessor and Microcomputer Standards Subcommittee of the IEEE Computer Society, Draft Standard for A High-Speed Memory Interface (SyncLink), Institute of Electrical and Electronics Engineers, Inc, Chapman, Brent D, Network (in)security through ip packet filtering, in proc. of the USE- NIX Security Conference proceedings, Centre National d'etude des Télécommunications - France Telecom, IP Fast Translator, FT.BD/CNET/DSE/SDL/226/CD, Décembre Interim Inter-switch Signaling Protocol (IISP) Specification v1.0, af-pnni , The ATM Forum Technical Committee, Décembre The ATM Forum Technical Committee, Integrated Local Management Interface (ILMI) Specification Version 4.0, af-ilmi , Septembre D. Kaufman, M. Gagnaire, Réseaux haut débit, réseaux ATM, réseaux locaux et réseaux tout optiques, InterEditions, G.H. Kim, E.H. Spafford, The design and Implementation of Tripwire, a file system integrity checker, ACM Conference on Computer and Communication Security, [Ko97] B. Kowalski, Atlas Policy Cache Architecture, White paper, Storagetek Corporation, [Kob92] D. Koblas, M. Koblas, Socks, in proc. of the USENIX Security Conference, [Kon99] [Lak98] [LANE10] [LANE20] Alexander V. Konstantinou, Yechiam Yemini, Sandeep Bhatt, S. Rajagopalan, Managing Security in Dynamic Networks, in proc. of the 19th USENIX System Administration Conference, Seattle, WA USA, Novembre T.V. Lakshman D. Stiliadis, High-speed Policy-based Packet Forwarding using Efficient Multi-dimensional Range Matching, in proc. of the ACM SIGCOMM 98 Conference, Septembre The ATM Forum Technical Committee, LAN Emulation Over ATM Version 1.0, aflane , Janvier The ATM Forum Technical Committee, LAN Emulation Over ATM Version 2 - LUNI Specification, af-lane , Juillet [Li99] LightStream 1010 Multiservice ATM Switch Overview, Cisco Corp., [Ma98] M-wall firewall administrator documentation, Matranet Corporation,

149 Le contrôle d accès dans les réseaux ATM - Références [Mc97] [Me94] [Mot98] J. McHenry, P. Dowd, F. Pellegrino, T. Carrozzi, W. Cocks, An FPGA-Based Coprocessor for ATM Firewalls, in proc. of the IEEE FCCM'97 Conference, Avril Ludovic Me, Audit de sécurité par algorithmes génétiques, Thèse de Doctorat, Université de Rennes 1, Juillet Don Taylor, Benjie Zeller, and Andrea Crocker, ZBT Primer, AN1773, Motorola Semiconductor Technical Data, 11 Avril [Mot100] Motorola Corp., Motorola Semiconductor Products Catalog, MCM69C432: 16kx64 3.3v CAM, Mai [Mot200] [MPOA10] [Ne97] [Nem95] [Nes98] [New97] Motorola Corp., Motorola Semiconductor Products Catalog, MCM69P819: 256kx18 3.3v Pipelined BurstRAM, Mai The ATM Forum Technical Committee, Multi-Protocol Over ATM Version 1.0, afmpoa , Juillet P. Newman, G. Minshall, L. Huston, IP switching and gigabits routers, IEEE Communications Magazine, Janvier Evi Netmeth, Garth Snyder, Scott Seebass, Trent Hein, Unix System Administration Handbook, second edition, Prentice Hall, D. Nessett and P. Humenn, The Multilayer Firewall, in proc. of the NDSS'98 Conference, Mars David Newman, Helen Holzbaur, and Kathleen Bishop, Firewalls: Don't Get Burned, Data Communications, Mars [Ns99] Kevin Fall, Kannan Varadhan, ns Notes and Documents, Septembre [Obook] [Ove96] Computer Security Center, Trusted Computer System Evaluation Criteria, CSC-STD , Department of Defense, 15 Août M.H. Overmars, A.F. van der Stappen, Range Searching and Point Location Among Fat Objects, Journal of Algorithms, pp , [Pa96] Olivier Paul, Etude Bibliographique sur les Firewalls, ENST de Bretagne, Mars [Pa97] [Pa98a] [Pa98b] [Pa98c] [Pa99a] Olivier Paul, Analyse du modèle ATM dans une optique de contrôle d'accès, Rapport technique, ENST de Bretagne, Décembre Olivier Paul, Maryline Laurent, Sylvain Gombault, Manageable parameters to improve access control in ATM networks, in proc. of the 5th Workshop of the HP OpenView University Association, Rennes, France, Avril Olivier Paul, Exemples de dénis de service dans les réseaux ATM, Rapport technique, ENST de Bretagne, Octobre Olivier Paul, Une analyse des MIBs du modèle ATM dans une optique de contrôle d accès, Rapport technique, ENST de Bretagne, Octobre Olivier Paul, Maryline Laurent, An Alternative Access Control Architecture for IP over ATM Networks, in proc. of the 4th IFIP Conference on Communications and Multimedia Security, Leuven, Belgique, Septembre

150 Le contrôle d accès dans les réseaux ATM - Références [Pa99b] [Pa99c] [Pa99d] [Pa99e] [Pa00] [Pa00a] [Pa00b] [Pa00c] [Pa00d] [Pa00e] [Pa00f] [Par98] [Pix99] [PN798] [PNNI10] [PRO10] Olivier Paul, Maryline Laurent, Sylvain Gombault, Une architecture de gestion efficace du contrôle d'accés, dans les actes des 4èmes Journées Doctorales Informatique et Réseaux, Evry, France, Novembre Olivier Paul, Maryline Laurent, Sylvain Gombault, Comment concilier controle d'accés et qualité de service dans les réseaux de type IP sur ATM?, dans les actes du 13ème Congrés De Nouvelles Architectures pour les Communications, Paris, France, Décembre Olivier Paul, Maryline Laurent, Sylvain Gombault, An Asynchronous and Distributed Access Control Architecture for IP over ATM networks, in proc. of the 15th Annual Computer Security Applications Conference, Phoenix, Décembre Olivier Paul, Gestion efficace du contrôle d accès dans les réseaux, Présentation invitée, Séminaire réseaux et systèmes, IRISA, Rennes, France, Janvier 2000 Olivier Paul, Maryline Laurent, Improving Packet Filters Management through Automatic and Dynamic Schemes, in proc. of the 15th IFIP International Conference on Information Security, Beijing, Chine, Août Olivier Paul, Improving Network Access Control Integrity through Redundant Mechanisms, in proc. of the 15th IFIP International Conference on Information Security, Beijing, Chine, Août Olivier Paul, Maryline Laurent, Sylvain Gombault, Access Control and Quality of Service in ATM Networks, 7th Workshop of the HP OpenView University Association, Santorini, Grèce, Juin Olivier Paul, Maryline Laurent, Sylvain Gombault, A Full Bandwidth ATM Firewall, in proc. of the 6th European Symposium on Research in Computer Security, Toulouse, France, Octobre Olivier Paul, Maryline Laurent, Techniques d'amélioration des méthodes de gestion automatique des routeurs filtrants, dans les actes du 8ème Colloque Francophone sur l'ingenierie des Protocoles, Toulouse, France, Octobre Olivier Paul, An ATM Signalling filtering Gateway (ASG), Octobre Craig Partridge & al., A 50-Gb/s IP Router, IEEE/ACM Transactions on Networking, Vol. 6, No. 3, p , Juin Cisco Corporation, Cisco's PIX Firewall Series and Stateful Firewall Security, White Paper, Septembre Unified Access Communications Inc., Unified Access Communications PN7 Technical White Paper, The ATM Forum Technical Committee, Private Network-Network Interface Specification Version 1.0 (PNNI 1.0), af-pnni , Mars Dave Paw, Clint Bishard, Proxy Agent SVC, LTD-CS-PROXY-01.00, The ATM Forum Technical Committee, Mai

151 Le contrôle d accès dans les réseaux ATM - Références [Q850] [Q931] [Q932] [Q933] [Q2610] [Q2931] ITU-T, Système de signalisation d'abonné numérique numéro 1, considération générales, Utilisation de la cause et de la localisation dans le système de signalisation d'abonné numérique numéro 1 et le sous-système utilisateur du RNIS du système de signalisation numéro 7, Recommandation UIT-T Q850, Mars ITU-T, Système de signalisation d'abonné numérique numéro 1, couche réseau, Système de signalisation d'abonné numérique numéro 1, Spécification de la couche 3 de l interface usager-réseau RNIS pour la commande de l appel de base, Recommandation UIT- T Q931, Mars ITU-T, Système de signalisation d'abonné numérique numéro 1, couche réseau, Système de signalisation d'abonné numérique numéro 1, Procédures génériques pour la commande des services complémentaires RNIS, Recommandation UIT-T Q932, Mars ITU-T, Système de signalisation d'abonné numérique numéro 1, couche réseau, Système de signalisation d'abonné numérique numéro 1, Spécification de la signalisation pour la commande et la surveillance de l état des connexions virtuelles commutées et permanentes en mode trame, Recommandation UIT-T Q933, Octobre ITU-T, Aspects communs et interfonctionnement protocoles de couche application pour la signalisation des accès et du réseau, Réseau numérique avec intégration des services à large bande, utilisation de la cause et du lieu dans le sous système utilisateur du RNIS à large bande et dans le système de signalisation d"abonné numérique numéro 2, Recommandation UIT-T Q2610, Février ITU-T, Protocoles de couche application du RNIS-LB pour la signalisation des accès, Réseau numérique avec intégration des services à large bande - Système de signalisation d'abonné numérique numéro 2 - Spécification de la couche 3 de l'interface utilisateurréseau pour la commande de connexion/appel de base, Recommandation UIT-T Q2931, Février [Q2931add] ITU-T, Protocoles de couche application du RNIS-LB pour la signalisation des accès, Réseau numérique avec intégration des services à large bande - Système de signalisation d'abonné numérique numéro 2 - Spécification de la couche 3 de l'interface utilisateurréseau pour la commande de connexion/appel de base, Recommandation UIT-T Q2931 amendement 1, Juin [Q2932] [Q2933] [Q2951] [Q2959] ITU-T, Protocoles de couche application du RNIS-LB pour la signalisation des accès, Système de signalisation d'abonné numérique numéro 2 - Protocole fonctionnel générique: fonction noyau, Recommandation UIT-T Q2932, Juillet ITU-T, Protocoles de couche application du RNIS-LB pour la signalisation des accès, Système de signalisation d'abonné numérique numéro 2 - Spécifications de la signalisation pour le service de relai de trame, Recommandation UIT-T Q2933, Juillet ITU-T, Protocoles de couche application du RNIS-LB pour la signalisation des accès, Description d'étape 3 des services complémentaires d'identification de numéro du RNIS à large bande au moyen du système de signalisation numérique d'abonné numéro 2 - appel de base, Recommandation UIT-T Q2951, Février ITU-T, Protocoles de couche application du RNIS-LB pour la signalisation des accès, Système de signalisation d'abonné numérique numéro 2 - Priorité d'appel, Recommandation UIT-T Q2959, Juillet

152 Le contrôle d accès dans les réseaux ATM - Références [Q2961] [Q2962] [Q2963] [Q2971] [Ran92] ITU-T, Protocoles de couche application du RNIS-LB pour la signalisation des accès, Réseau numérique avec intégration des services à large bande - Système de signalisation d'abonné numérique numéro 2 - Paramètres de trafic complémentaires, Recommandation UIT-T Q2961, Octobre ITU-T, Protocoles de couche application du RNIS-LB pour la signalisation des accès, Système de signalisation d'abonné numérique numéro 2 - Négociation des caractéristiques de connexion durant la phase d'établissement d'appel, Recommandation UIT-T Q2962, Juillet ITU-T, Protocoles de couche application du RNIS-LB pour la signalisation des accès, Modification du débit cellulaire crête par le propriétaire de la connexion, Recommandation UIT-T Q2963, Juillet ITU-T, Protocoles de couche application du RNIS-LB pour la signalisation des accès, Réseau numérique avec intégration des services à large bande - Système de signalisation d'abonné numérique numéro 2 - Spécification de la couche 3 de l'interface utilisateurréseau pour la commande d'appel/de connexion point à multipoint, Recommandation UIT-T Q2971, Octobre M. Ranum, A network firewall, in proc. of the World Conference on System Administration and security, [RFC1413] M. St. Johns, RFC 1413, Identification Protocol, Février [RFC1414] M. St. Johns, M Rose, RFC 1414, Identification MIB, Février 1993 [RFC1442] [RFC1510] [RFC1695] [RFC1755] [RFC1987] [RFC2011] [RFC2012] [RFC2013] [RFC2021] J. Case, K. McCloghrie, M. Rose, S. Waldbusser, RFC 1442, Structure of Management Information for version 2 of the Simple Network Management Protocol (SNMPv2), Avril J. Kohl, C. Neuman, RFC 1510, The Kerberos Network Authentication Service (V5), Septembre M. Ahmed, K. Tesink, RFC 1695, Definition of Managed Objects for ATM Management Version 8.0 using SMIv2, Août M. Perez, F. Liaw, A. Mankin, E. Hoffman, D. Grossman, A. Malis, RFC 1755, ATM Signaling support for IP over ATM, Février P. Newman, W. Edwards, R. Hinden, E. Hoffman, F. Ching Liaw, T. Lyon, G. Minshall, RFC 1987, Ipsilon's General Switch Management Protocol Specification Version 1.1, Août K. McCloghrie, RFC 2011, SNMPv2 Management Information Base for the Internet Protocol using SMIv2, Novembre K. McCloghrie, RFC 2012, SNMPv2 Management Information Base for the Transmission Control Protocol using SMIv2, Novembre K. McCloghrie, RFC 2013, SNMPv2 Management Information Base for the User Datagram Protocol using SMIv2, Novembre S. Waldbusser, RFC2021, Remote Network Monitoring Management Information Base Version 2 using SMIv2, Janvier

153 Le contrôle d accès dans les réseaux ATM - Références [RFC2022] G. Armitage, RFC 2022, Support for multicast over UNI3.0/3.1 (MARS), Novembre [RFC2225] M. Laubach, J. Halpern, RFC 2225, Classical IP and ARP over ATM, Avril [RFC2226] T. Smith, G. Armitage, RFC 2226, IP Broacast over ATM Networks, Octobre [RFC2233] K. McCloghrie, F. Kastenholz, RFC2233, The Interfaces Group MIB using SMIv2, Novembre [RFC2246] C. Allen, RFC 2246, The TLS Protocol Version 1.0, T. Dierks, Janvier [RFC2247] N. Freed, S. Kille, RFC 2247, Network Services Monitoring MIB, Janvier [RFC2287] [RFC2332] [RFC2401] C. Krupczak, J. Saperia, RFC 2287, Definitions of System-Level Managed Objects for Applications, Février J. Luciani, D. Katz, D. Piscitello, B. Cole, N. Doraswamy, RFC 2332, NBMA Next Hop Resolution Protocol (NHRP), Avril S. Kent, R. Atkinson, RFC 2401, Security Architecture for the Internet Protocol, Novembre [RFC2402] S. Kent, R. Atkinson, RFC 2402, IP Authentication Header, Novembre [RFC2571] [RFC2572] D. Harrington, R. Presuhn, B. Wijnen, RFC 2571, An Architecture for Describing SNMP Management Frameworks, Avril J. Case, D. Harrington, R. Presuhn, B. Wijnen, RFC 2572, Message Processing and Dispatching for the Simple Network Management Protocol (SNMP), Avril [RFC2574] U. Blumenthal, B. Wijnen, RFC 2574, User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3), Avril [RFC2578] K. McCloghrie, D. Perkins, J. Schoenwaelder, RFC2578, Structure of Management Information Version 2 (SMIv2), Avril [RFC2601] M. Davison, RFC 2601, ILMI-Based Server Discovery for ATMARP, Juin [RFC2602] M. Davison, RFC 2602, ILMI-Based Server Discovery for MARS, Juin [RFC2684] [RFC2748] [Rol99] [Sam95] D. Grossman, J. Heinanen, RFC 2694, Multiprotocol Encapsulation over ATM Adaptation Layer 5, Septembre D. Durham, J. Boyle, R. Cohen, S. Herzog, R. Rajan, A. Sastry, RFC 2748, The COPS (Common Open Policy Service) Protocol, Janvier Pierre Rolin, Réseaux haut débit, deuxième édition revue et augmentée, Editions Hermès, Michael Steinacker, Samson, Security and Management Services in Open Networks, Final Report, RACE R2058 Project, Janvier [Sch96] Bruce Schneier, Applied Cryptography, Second Edition, Wiley & Sons Inc,

154 Le contrôle d accès dans les réseaux ATM - Références [Schu97] [SEC10] [SECM98] [SEF10] Christoph Schuba, On the modeling, design and implementation of firewall technology, Ph.D. Thesis, Purdue University, Décembre The ATM Forum Technical Committee, ATM Security Specification Version 1.0, afsec , Février The ATM Forum Technical Committee, Network Management, Requirements and Logical MIB: ATM Security Services Phase 1, btd-nm-sec-req-00.04, Avril The ATM Forum Technical Committee, ATM Security Framework 1.0, af-sec , Février [Sib00] Sibercore technologies inc., SiberCAM Ultra-2M product overview, Mai [Sim00] [Smart99] [Sri99] J.L. Simon, P. Rolin, O. Paul, M. Laurent, S. Gombault, Pare-feu très haut débit, Brevet Européen, Soumis, Mars Cabletron Systems, SmartStack Fast Ethernet Hub, ELH100-12/24TX, Firmware Version , Juin V. Srinivasan, S. Suri, G. Varghese, Packet Classification Using Tuple Space Search, in proc. of the ACM SIGCOMM 99 Conference, Septembre [Ss99] SUN Microsystems, Inc, SunScreen Secure Net 3.0 A White Paper, [Sta93] [Sta97] [Sta99] [Ste99] [Stra98] [Tib95] William Stallings, SNMP, SNMPv2 and CMIP, The pratical guide to network management Standards, Addison-Wesley, F. Stamatelopoulos, G. Koutepas, B. Maglaris, System Security Management via SNMP, in proc. of the 4th Workshop of the HP OpenView University Association, Avril William Stallings, SNMP, SNMPv2, SNMPv3 and RMON 1 and 2, Third Edition, Addison-Wesley, 1999 M. L. Stevens, W. J. Weiss, Policy Based Management for IP networks, Bell Labs Technical Journal, p 75-94, Octobre-Novembre John Strassner, Stephen Schleimer, Policy Framework Definition Language, draft-ietfpolicy-framework-pfdl-00.txt, Internet Draft, Internet Engineering Task Force, 17 Novembre K. Tibourtine, Détection d'intrusions dans les réseaux de communication, Thèse de doctorat, Université de Paris Sud, Février [Tis93] Trusted Information Systems, Internet Firewalls, An Overview, [Tis94] Trusted Information Systems, TIS Firewall Tookit Administration Guide, [Tis96] Trusted Information Systems, Firewall Product Functional Summary, [Tou99] [UNI3.1] Laurent Toutain, Réseaux locaux et Internet, des protocoles à l interconnexion, 2éme édition revue et augmentée, Hermès science publications, The ATM Forum Technical Committee, ATM User-Network Interface (UNI) specification, Version 3.1, af-uni , Septembre

155 Le contrôle d accès dans les réseaux ATM - Références [UNI4.0] [Vign98] [VOD10] [VTOA10] [Vv98] [Wij99] [Wol93] [X263] [Xu96] [Xu98a] [Xu98b] [Xu98c] [Xu99a] [Xu99b] [Xu99c] [Xu00] The ATM Forum Technical Committee, ATM User-Network Interface (UNI) Signalling Specification, Version 4.0, af-sig , Juillet Giovanni Vigna and Richard A. Kemmerer, NetSTAT: A Network-based Intrusion Detection Approach, in proc. of the 14th Annual Computer Security Applications Conference, Décembre The ATM Forum Technical Committee, Audiovisual Multimedia Services :Video on Demand Specification 1.0, af-saa , Décembre The ATM Forum Technical Committee, Voice and Telephony Over ATM to the Desktop Specification, af-vtoa , Mars C. Rubin, D. Arnovitz, VirtualVault White Paper, Hewlett-Packard Company, Novembre Bert Wijnen, Position w.r.t. the SNMP vs COPS debate, Discussion on the RAP mailing list, Décembre A. Wolman, G. Treese, X through the firewall, and other application relays, in proc. of the USENIX Security Conference, ITU-T, Réseaux pour données et communication entre systèmes ouverts, Interconnexion des systèmes ouverts - identification des protocoles, Technologies de l'information - identification des protocoles dans la couche réseau, Recommandation ITU-T X263, Novembre Jun Xu and Mukesh Singhal, Logical Firewalls: A Mechanism for Security in Future Environments, Technical report, TR 62, The Ohio State University, 1996 Jun Xu and Mukesh Singhal, Design of A high-performance ATM Firewall, in proc. of the 5th ACM Conference on Computer and Communication Security, San Francisco, CA, Novembre Jun Xu and Mukesh Singhal, A Firewalling Scheme for Securing MPOA-based Corporate Intranets, in proc. of the 3rd IEEE Symposium on High Assurance Systems Engineering, Washington DC, Novembre J. Xu, M. Singhal, Design of a high-performance ATM Firewall, Technical report, TR 13, The Ohio State University, Jun Xu and Mukesh Singhal, Design of a high-performance ATM Firewall, ACM Transaction on Information and System Security, Vol. 2, No. 3, pp , Août Jun Xu and Mukesh Singhal, Design and Evaluation of a high-performance ATM Firewall Switch and Its Applications, IEEE Journal on Selected Areas in Communications, Vol. 17, No. 6, pp , Juin Jun Xu and Mukesh Singhal, A Firewalling Scheme for Securing MPOA-based Enterprise Networks, International Journal of Software Engineering and Knowledge Engineering, Vol. 9, No. 2, pp , Avril J. Xu, M. Singhal, J. Degroat, A Novel Hardware Cache Architecture to Support Layer Four Packet Classification at Memory Access Speeds, in proc. of the IEEE INFOCOM 2000 Conference, Mars

156 Le contrôle d accès dans les réseaux ATM - Références 148

157 CHAPITRE 9 Annexes Ce chapitre contient les annexes des chapitres de 2 à Annexes du chapitre Abréviations des messages de signalisation AA AL AP AR CA CO DP LF LR MA ME MR PA PR RL ST ADD PARTY ACK. ALERTING. ADD PARTY. ADD PARTY REQUEST. CONNECTION AVAILABLE. CONNECT. DROP PARTY. LEAF SETUP FAILURE. LEAF SETUP REQUEST. MODIFY ACKNOWLEDGE. MODIFY REJECT. MODIFY REQUEST. PARTY ALERTING. PROGRESS. RELEASE. SETUP Abréviations des IEs AALP ATM Adaptation Layer Parameters. 149

158 Le contrôle d accès dans les réseaux ATM - Annexes AAP AATD ASP ATD BBC BHLI BLLI BLS BNLS BRI BSC BTR C CI CN cpn CPN cpsa CPSA CS CSA CSS EQoSP ER ES ETD F GIT LIJCI LIJP LLCP LLPP LSN MATD NBC ABR Additional Parameters. Alternative Atm Traffic Descriptor. ABR Setup Parameters. ATM Traffic Descriptor. Broadband Bearer Capability. Broadband High Layer Information. Broadband Low Layer Information. Broadband Locking Shift. Broadband Non-Locking shift. Broadband Repeat Indicator. Broadband Sending Complete. Broadband Type Report. Cause. Connection Identifier. Connected Number. Calling Party Number. Called Party Number. Calling Party Subadress. Called Party Subadress. Call State. Connected Subadress. Connection Scope Selection. Extended QoS Parameters. Endpoint Reference. Endpoint State. End-to-End Transit Delay. Facility. Generic Identifier Transport. Leaf Initiated Join Call Identifier. Leaf Initiated Join Parameters. Link Layer Core Parameters. Link Layer Protocol Parameters. Leaf Sequence Number. Minimum Acceptable Traffic Descriptor. Narrowband Bearer Capability. 150

159 Le contrôle d accès dans les réseaux ATM - Annexes NHLC NI NLLC OAMTD pi PI QoSP RI TNS Narrowband High Layer Information. Notification Indication. Narrowband Low Layer Information. OAM Traffic Descriptor. Priority Information. Progress Indicator. QoS Parameters. Restart Indicator. Transit Network Selection Relations entre IEs et messages de signalisation Les tableaux 38 et 39 décrivent les relations entre IEs et messages de signalisation en fonction de la provenance de la spécification (ITU ou ATM-Forum). Tableau 38. Liens entre messages et IEs dans l'uni4.0. IE/Mess. ST CO AL RL PR AP AA PA AR DP LR LF NBC o o o o C Mm M M M CS PI o o o o o NI Oo Oo Oo Oo o O O O O ETD Oo Oo O O CN O CSA O AALP Oo Oo O O ATD Mm O CI Oo Oo Oo QoSP Mm BHLI O o O BBC Mm BLLI O O O O BLS BNLS BSC Oo O BRI Oo cpn Oo O M cpsa Oo O O CPN Mm M M O CPSA Oo O O O 151

160 Le contrôle d accès dans les réseaux ATM - Annexes IE/Mess. ST CO AL RL PR AP AA PA AR DP LR LF TNS Oo O O O RI NLLC o o NHLC o o o GIT O O O O O O O O O MATD O AATD O ASP O O CSS O AAP O O EQoSP O O LIJCI O M LIJP O LSN O O M M ER O O O M M M M M ES La présence des IEs dans un message n'étant pas toujours obligatoire, nous noterons O les IEs optionnels et M les IEs obligatoires. La présence dans le cas d'une émulation du RNIS bande étroite est indiquée de la même manière mais en minuscules. Les zones grisées concernent les paramètres propres aux connexions point à multipoint. Les abréviations utilisées sont explicitées en section 1.1 et 1.2 de ce chapitre. Tableau 39. Liens entre messages et IEs dans les normes ITU-T. IE/Mess. ST CO AL RL PR MR MA ME CA AP AA PA AR DP BLS BNLS AALP Oo Oo ATD Mm O M O O BBC Mm BHLI O O BLLI O O O O CS CPN Oo M CPSA Oo O cpn Oo O cpsa Oo O C Mm M M CI Oo Oo Oo ETD Oo Oo O O 152

161 Le contrôle d accès dans les réseaux ATM - Annexes IE/Mess. ST CO AL RL PR MR MA ME CA AP AA PA AR DP QoSP BRI RI Mm Oo BSC Oo O TNS Oo O NI Oo Oo Oo Oo o O O O O O O O O OAMTD Oo Oo NBC o o o o NHLC o o o o NLLC o o PI o o o o m F LLCP O O LLPP O O CN O CSA O pi O AATD O MATD O BTR O ER O O O M M M M M ES 2. Annexes du chapitre Informations relevant du modèle ATM Le tableau 40 donne les variables pouvant être utilisées pour fournir le service de contrôle d accès dans le cas d un réseau ATM. Les MIBs utilisées sont spécifiées dans [RFC1695] (ATM-MIB), [AToM98] ([ATM2- MIB) et [ILMI40] (ATM-FORUM-MIB). Tableau 40. Récapitulatif des paramètres fournis par les MIBs du modèle ATM. Information Emplacement MIB Type de flux / / Identificateurs de connexion atmvclvpi, atmvclvci ATM-MIB Type de cellule OAM / / Fonction OAM / / Type d AAL atmvccaaltype ATM-MIB Adresse de l appelant atmvcladdraddr ATM2-MIB Plans d adressage de l appelant atmvcladdrtype ATM2-MIB 153

162 Le contrôle d accès dans les réseaux ATM - Annexes Information Emplacement MIB Sous adresse de l appelant / / Plan d adressage de la sous-adresse de l appelant / / Adresse de l appelé atmvcladdraddr ATM2-MIB Plans d adressage de l appelé atmvcladdrtype ATM2-MIB Sous adresse de l appelé / / Plan d adressage de la sous-adresse de appelé / / Adresse connectée atmvcladdraddr ATM2-MIB Plan d adressage de l adresse connectée atmvcladdrtype ATM2-MIB Sous adresse connectée / / Plan d adressage de la sous-adresse connectée / / Identificateur de connexion point à multipoint / / Connection scope selection atmifregaddrorgscope ATM2-MIB Identificateur d'extrémité / / Identificateur de protocoles de couche 1 / / Identificateur de protocoles de couche 1 / / Identificateur de protocoles de couche 2 atmsigdescrparambllilayer2 ATM2-MIB Identificateur de protocoles de couche 2 atmsigdescrparambllilayer2 ATM2-MIB Identificateur de protocoles de couche 3 atmsigdescrparambllilayer3, atmsigdescrparambllisnapid, atmsigdescrparamblliouipid ATM2-MIB Identificateur de protocoles de couche 3 atmsigdescrparambllilayer3 ATM2-MIB Identificateur de protocoles de couche supérieure atmsigdescrparambhlitype, ATM2-MIB atmsigdescrparambhliinfo Liste des réseaux de transit / / Type d AAL atmvccaaltype ATM-MIB Débit CBR pour AAL1 atmtrafficdescrparam ATM-MIB Débit crète ou PCR atmtrafficdescrparam ATM-MIB Débit soutenu ou SCR atmtrafficdescrparam ATM-MIB Taille maximale des rafales ou MBS atmtrafficdescrparam ATM-MIB Débit minimum ABR atmtrafficdescrparam ATM-MIB Indicateur de best effort atmfvccbesteffortindicator ATM-FORUM-MIB ATD débit initial ABR atmfvccabrtransmiticr ATM-FORUM-MIB Variation de délai acceptable ou CDV atmtrafficdescrparam ATM-MIB Taux de perte acceptable ou CLR atmtrafficdescrparam ATM-MIB Priorité de l appel / / 154

163 Le contrôle d accès dans les réseaux ATM - Annexes 2.2. Informations relevant du niveau transport Le tableau 41 donne les variables pouvant être utilisées pour fournir le service de contrôle d accès dans le cas d un réseau TCP/IP. Les MIBs utilisées sont spécifiées dans [RFC2021] (RMON2-MIB), [RFC2011] ([IP-MIB), [RFC2012] (tcpmib) et [RFC2013] (udpmib). Tableau 41. Récapitulatif des paramètres fournis par les MIBs relatives à TCP/IP. Information Emplacement MIB Type de protocole utilisé almatrixdsentry RMON2-MIB Type de message ICMP icmp IP-MIB Adresse IP Source tcpconnlocaladdress, udplocaladdress tcpmib, udpmib Adresse IP Destination tcpconnremaddress tcpmib Port UDP source udplocalport udpmib Port UDP destination / / Port TCP source tcpconnlocalport tcpmib Port TCP destination tcpconnremport tcpmib Drapeaux TCP tcpconnstate tcpmib 2.3. Informations applicatives Le tableau 42 donne les variables pouvant être utilisées pour fournir un service de contrôle d accès de niveau applicatif. Les MIBs utilisées sont spécifiées dans [RFC1414] (RFC1414-MIB), [RFC2287] (sysapplmib) et [RFC2247] (NETWORK-SERVICES-MIB). Tableau 42. Récapitulatif des paramètres fournis par les MIBs applicatives. Information Emplacement MIB Identificateur de l utilisateur d une connexion identuserid RFC1414-MIB Nom de l application executée sysapplelmtrunname sysapplmib Numéro de processus correspondant sysapplelmtrunindex sysapplmib Identificateur de l utilisateur d un processus sysapplelmtrunuser sysapplmib Temps CPU utilisé par le processus sysapplelmtruncpu sysapplmib Mémoire utilisée par le processus sysapplelmtrunmemory sysapplmib Nombre de fichiers utilisés par le processus sysapplelmtrunnumfiles sysapplmib Nombre de connexions ouvertes par le processus apploutboundassociations NETWORK-SER- VICES-MIB Nombre de connexions recues par le processus applinboundassociations NETWORK-SER- VICES-MIB Adresse de l entité homologue assocremoteapplication NETWORK-SER- VICES-MIB Protocole/Service utilisé assocapplicationprotocol NETWORK-SER- VICES-MIB Durée de la communication assocduration NETWORK-SER- VICES-MIB 155

164 Le contrôle d accès dans les réseaux ATM - Annexes 3. Annexes du chapitre Grammaire des langages proposés Langage de bas niveau <PFDL_Program> ::=[<policy_definition>]+ <policy_definition> ::= INTEGER : [<policy_rule>]+ <policy_rule> ::= IF <policy_condition_and_list> THEN <policy_action_priority_list> <policy_condition_and_list> ::= <policy_condition_statement> [ AND <policy_condition_statement>]* <policy_condition_statement> ::= <policy_condition_expr> NOT <policy_condition_expr> <policy_condition_expr> ::= <atm_layer_statement> <signaling_entity_statement> <transport_layer_statement> <application_layer_statement> <time_category_statement> <atm_layer_statement> ::= <static_connection_statement> <traffic_category_statement> <static_connection_statement> ::= <vpi_statement> <vci_statement> <vpi_statement> ::= VPI <relational_op> <vpi_value> <vci_statement> ::= VCI <relational_op> <vci_value> <vpi_value> ::= INTEGER <vci_value> ::= INTEGER <traffic_category_statement> ::= TRAFFIC <relational_op> <traffic_type_value> <management_function_statement> <traffic_type_value> ::= META SIGNALING` BROADCAST SIGNALING POINT TO POINT SIGNA- LING OAM F4 SEGMENT OAM F4 END TO END ILMI OAM F5 SEGMENT OAM F5 END TO END USER CELL PNNI <management_function_statement> ::= FAULT MANAGEMENT <relational_op> <fm_type_value> PERFORMANCE MANAGEMENT <relational_op> <pm_type_value> ACTIVATION <relational_op> <activation_type_value> <fm_type_value> ::= AIS RDI CONTINUITY LOOPBACK <pm_type_value> ::= FORWARD BACKWARD REPORT <activation_type_value> ::= PERFORMANCE CONTINUITY CHECK <signaling_entity_statement> ::= <atm_addressing_statement> <atm_upper_layers_statement> <atm_qos_statement> <atm_priority_statement> <atm_addressing_statement> ::= <atm_id_statement> <atm_sub_id_statement> <atm_ptmtp_statement> <atm_id_statement> ::= <adress_plan_statement> <address_statement> <address_plan_statement> ::= SRC PLAN <relational_op> <addressing_plan_value> DST PLAN <relational_op> <addressing_plan_value> <address_plan_value> ::= INTEGER 156

165 Le contrôle d accès dans les réseaux ATM - Annexes <address_statement> ::= SRC ADDRESS <relational_op> <atm_address_value> DST ADDRESS <relational_op> <atm_address_value> <atm_address_value> ::= STRING[20] <sub_id_statement> ::= <subaddress_type_statement> <subaddress_statement> <subaddress_type_statement> ::= SRC TYPE <relational_op> <subaddress_type_value> DST TYPE <relational_op> <subaddress_type_value> <subaddress_type_value> ::= INTEGER <subaddress_statement> ::= SRC SUBADDRESS <relational_op> <subaddress_value> DST SUBADDRESS <relational_op> <subaddress_value> <subaddress_value> ::= STRING[20] <atm_ptmtp_statement> ::= <PTMPT ID> <relational_op> <ptmtp_id_value_value> <ptmtp_id_value> ::= INTEGER <upper_layers_statement> ::= <bhli_statement> <blli_statement> <bhli_statement> ::= <bhli_type>, <bhli_id> <bhli_id> <bhli_type> ::= BHLI TYPE <relational_op> <bhli_type_value> <bhli_type_value> ::= INTEGER <bhli_id> ::= BHLI ID <relational_op> <bhli_id_value> <bhli_id_value> ::= STRING[64] <blli_statement> ::= <layer1_statement> <layer2_statement> <layer3_statement> <layer1_statement> ::= <layer1_type_statement> <layer1_type_statement> ::= <LAYER1> <relational_op> <layer1_type_value> <layer1_type_value> ::= INTEGER <layer2_statement> ::= <layer2_type_statement> <layer2_usercoding_statement> <layer2_type_statement> ::= LAYER2 <relational_op> <layer2_type_value> <layer2_type_value> ::= INTEGER <layer2_usercoding_statement> ::= LAYER2 UC <relational_op> <layer2_usercoding_value> <layer2_usercoding_value> ::= INTEGER <layer3_statement> ::= <layer3_type_statement> <layer3_usercoding_statement> <layer3_iso9577_statement> <layer3_oui_statement> <layer3_pid_statement> <layer3_type_statement> ::= LAYER3 <relational_op> <layer3_type_value> <layer3_type_value> ::= INTEGER <layer3_usercoding_statement> ::= LAYER3 UC <relational_op> <layer3_usercoding_value> <layer3_usercoding_value> ::= INTEGER 157

166 Le contrôle d accès dans les réseaux ATM - Annexes <layer3_iso9577_statement> ::= LAYER3 ISO <relational_op> <layer3_iso9577_value> <layer3_iso9577_value> ::= INTEGER <layer3_oui_statement> ::= LAYER3 OUI <relational_op> <layer3_oui_value> <layer3_oui_value> ::= STRING[24] <layer3_pid_statement> ::= LAYER3 PID <relational_op> <layer3_pid_value> <layer3_pid_value> ::= STRING[16] <atm_qos_statement> ::= <aalp1_statement> <atd_statement> <eqosp_statement> <aalp1_statement> ::= <cbr_rate_statement> <cbr_rate_statement> ::= CBR RATE <relational_op> <cbr_rate_value> <cbr_rate_value> ::= INTEGER <atd_statement> ::= <forward_pcr_clp0_statement> <backward_pcr_clp0_statement> <forward_pcr_clp1_statement> <backward_pcr_clp1_statement> <forward_scr_clp0_statement> <backward_scr_clp0_statement> <forward_scr_clp1_statement> <backward_scr_clp1_statement> <forward_mbs_clp0_statement> <backward_mbs_clp0_statement> <forward_mbs_clp1_statement> <backward_mbs_clp1_statement> <forward_abr_mcr_statement> <backward_abr_mcr_statement> <best_effort_statement> <forward_pcr_clp0_statement> ::= FWD PCR CLP0 <relational_op> <forward_pcr_clp0_value> <forward_pcr_clp0_value> ::= INTEGER <backward_pcr_clp0_statement> ::= BWD PCR CLP0 <relational_op> <backward_pcr_clp0_value> <backward_pcr_clp0_value> ::= INTEGER <forward_pcr_clp1_statement> ::= FWD PCR CLP1 <relational_op> <forward_pcr_clp1_value> <forward_pcr_clp1_value> ::= INTEGER <backward_pcr_clp1_statement> ::= BWD PCR CLP1 <relational_op> <backward_pcr_clp1_value> <backward_pcr_clp1_value> ::= INTEGER <forward_scr_clp0_statement> ::= FWD SCR CLP0 <relational_op> <forward_scr_clp0_value> <forward_scr_clp0_value> ::= INTEGER <backward_scr_clp0_statement> ::= BWD SCR CLP0 <relational_op> <backward_scr_clp0_value> <backward_scr_clp0_value> ::= INTEGER <forward_scr_clp1_statement> ::= FWD SCR CLP1 <relational_op> <forward_scr_clp1_value> <forward_scr_clp1_value> ::= INTEGER <backward_scr_clp1_statement> ::= BWD SCR CLP1 <relational_op> <backward_scr_clp1_value> <backward_scr_clp1_value> ::= INTEGER <forward_mbs_clp0_statement> ::= FWD MBS CLP0 <relational_op> <forward_mbs_clp0_value> <forward_mbs_clp0_value> ::= INTEGER 158

167 Le contrôle d accès dans les réseaux ATM - Annexes <backward_mbs_clp0_statement> ::= BWD MBS CLP0 <relational_op> <backward_mbs_clp0_value> <backward_mbs_clp0_value> ::= INTEGER <forward_mbs_clp1_statement> ::= FWD MBS CLP1 <relational_op> <forward_mbs_clp1_value> <forward_mbs_clp1_value> ::= INTEGER <backward_mbs_clp1_statement> ::= BWD MBS CLP1 <relational_op> <backward_mbs_clp1_value> <backward_mbs_clp1_value> ::= INTEGER <forward_abr_mcr_statement> ::= FWD ABR MCR <relational_op> <forward_abr_mcr_value> <forward_abr_mcr_value> ::= INTEGER <backward_abr_mcr_statement> ::= BWD ABR MCR <relational_op> <backward_abr_mcr_value> <backward_abr_mcr_value> ::= INTEGER <best_effort_statement> ::= BEST EFFORT IND <relational_op> <best_effort_value> <best_effort_value> ::= INTEGER <eqosp_statement> ::= <forward_cdv_statement> <backward_cdv_statement> <forward_clr_statement> <backward_clr_statement> <forward_cdv_statement> ::= FWD CDV <relational_op> <forward_cdv_value> <forward_cdv_value> ::= INTEGER <backward_cdv_statement> ::= BWD CDV <relational_op> <backward_cdv_value> <backward_cdv_value> ::= INTEGER <forward_clr_statement> ::= FWD CLR <relational_op> <forward_clr_value> <forward_clr_value> ::= INTEGER <backward_clr_statement> ::= BWD CLR <relational_op> <backward_clr_value> <backward_clr_value> ::= INTEGER <atm_priority_statement> ::= <PRIORITY> <relational_op> <priority_value> <priority_value> ::= INTEGER <transport_layer_statement> ::= <ip_statement> <icmp_statement> <udp_statement> <tcp_statement> <ip_statement> ::= <ip_protocol_statement> <ip_address_statement> <ip_options_statement> <ip_protocol_statement> ::= IP PROTOCOL <relational_op> <ip_protocol_value> <ip_protocol_value> ::= <ip_address_statement> ::= IP SRC ADDR <relational_op> <ip_address> IP DST ADDR <relational_op> <ip_address> <ip_address> ::= <ip_addr_value> 159

168 Le contrôle d accès dans les réseaux ATM - Annexes <ip_addr_value> ::= INTEGER. INTEGER. INTEGER. INTEGER <ip_options_statement> ::= IP OPTION <relational_op> <ip_option_value> <ip_option_value> ::= SEC RR TS LSR SSR <icmp_statement> ::= ICMP TYPE <relational_op> <icmp_type_value> ICMP CODE <relational_op> <icmp_code_value> <icmp_type_value> ::= <icmp_code_value> ::= [0-15] <tcp_statement> ::= <port_statement> <tcp_flag_statement> <tcp_flag_statement> ::= TCP FLAG <relational_op> <tcp_flag_value> <tcp_flag_value> ::= SYN SYNACK RST ACK FIN FINACK <udp_statement> ::= <port_statement> <port_statement> ::= SRC PORT <relational_op> <port_value> DST PORT <relational_op> <port_value> <port_value> ::= INTEGER <application_layer_statement> ::= <application_id_statement> <application_user_statement> <application_state_statement> <application_id_statement> ::= APPLICATION <relational_op> <application_id> <application_id> ::= INTEGER <application_user_statement> ::= USER <relational_op> <application_user_id> <application_user_id> ::= INTEGER <application_state_statement> ::= STATE <relational_op> <state_id> <state_id> ::= INTEGER <address> ::= <ip_address> <atm_address> <mac_address> <mac_address> ::= STRING[12] <time_category_statement> ::= AT <time_value> FROM <time_value> TO <time_value> <time_value> ::= INTEGER : INTEGER : INTEGER <relational_operator> ::= IN NOT IN = <> > >= < =< <policy_action_priority_list> ::= [<policy_action_statement>]+ <policy_action_statement> ::= <policy_action_category> [<apply_spec>] [<seq_num>] <policy_action_category> ::= PERMIT <auth_category> DENY <auth_category> <auth_category> ::= ATM CELL ATM CONNECTION TRANSP CONNECTION APPLICATION Langage à base de rôles <RBPFDL_Program> ::= [<policy_definition>]+ 160

169 Le contrôle d accès dans les réseaux ATM - Annexes <policy_definition> ::= <service_identifier> ':' <service_definition> <topology_identifier> ':' <topology_definition> <role_identifier> ':' <role_definition> <service_identifier> ::= STRING <topology_identifier> ::= STRING <role_identifier> ::= STRING <service_definition> ::= <service_condition_or_list> <service_condition_and_list> <service_condition_or_list> ::= <service_condition_and_list ['OR' <service_condition_and_list>]* <service_condition_and_list> ::= <service_condition_statement> ['AND' <service_condition_statement>]* <service_condition_statement> ::= <service_condition_expr> 'NOT' <service_condition_expr> <service_condition_expr> ::= <atm_layer_statement> <signaling_entity_statement> <transport_layer_statement> <application_layer_statement> <time_category_statement> <atm_layer_statement> ::= <traffic_category_statement> <traffic_category_statement> ::= 'TRAFFIC' <relational_op> <traffic_type_value> <management_function_statement> <traffic_type_value> ::= 'META SIGNALING` 'BROADCAST SIGNALING' 'POINT TO POINT SIGNA- LING' 'OAM F4 SEGMENT' 'OAM F4 END TO END' 'ILMI' 'OAM F5 SEGMENT' 'OAM F5 END TO END' 'USER CELL' 'PNNI' <management_function_statement> ::= 'FAULT MANAGEMENT' <fm_type_statement> 'PERFORMANCE MANAGEMENT' <pm_type_statement> 'ACTIVATION' <activation_type_statement> <fm_type_statement> ::= 'AIS' 'RDI' 'CONTINUITY' 'LOOPBACK' <pm_type_statement> ::= 'FORWARD' 'BACKWARD' 'REPORT' <activation_type_statement> ::= 'PERFORMANCE' 'CONTINUITY CHECK' <signaling_entity_statement> ::= <atm_upper_layers_statement> <atm_qos_statement> <atm_priority_statement> <upper_layers_statement> ::= <bhli_statement> <blli_statement> <bhli_statement> ::= <bhli_type> ',' <bhli_id> <bhli_id> <bhli_type> ::= 'BHLI TYPE' <relational_op> <bhli_type_value> <bhli_type_value> ::= INTEGER <bhli_id> ::= 'BHLI ID' <relational_op> <bhli_id_value> <bhli_id_value> ::= STRING[64] <blli_statement> ::= <layer1_statement> <layer2_statement> <layer3_statement> <layer1_statement> ::= <layer1_type_statement> <layer1_type_statement> ::= <LAYER1> <relational_op> <layer1_type_value> <layer1_type_value> ::= INTEGER 161

170 Le contrôle d accès dans les réseaux ATM - Annexes <layer2_statement> ::= <layer2_type_statement> <layer2_usercoding_statement> <layer2_type_statement> ::= 'LAYER2' <relational_op> <layer2_type_value> <layer2_type_value> ::= INTEGER <layer2_usercoding_statement> ::= 'LAYER2 UC' <relational_op> <layer2_usercoding_value> <layer2_usercoding_value> ::= INTEGER <layer3_statement> ::= <layer3_type_statement> <layer3_usercoding_statement> <layer3_iso9577_statement> <layer3_oui_statement> <layer3_pid_statement> <layer3_type_statement> ::= 'LAYER3' <relational_op> <layer3_type_value> <layer3_type_value> ::= INTEGER <layer3_usercoding_statement> ::= 'LAYER3 UC' <relational_op> <layer3_usercoding_value> <layer3_usercoding_value> ::= INTEGER <layer3_iso9577_statement> ::= 'LAYER3 ISO' <relational_op> <layer3_iso9577_value> <layer3_iso9577_value> ::= INTEGER <layer3_oui_statement> ::= 'LAYER3 OUI' <relational_op> <layer3_oui_value> <layer3_oui_value> ::= STRING[24] <layer3_pid_statement> ::= 'LAYER3 PID' <relational_op> <layer3_pid_value> <layer3_pid_value> ::= STRING[16] <atm_qos_statement> ::= <aalp1_statement> <atd_statement> <eqosp_statement> <aalp1_statement> ::= <cbr_rate_statement> <cbr_rate_statement> ::= CBR RATE <relational_op> <cbr_rate_value> <cbr_rate_value> ::= INTEGER <atd_statement> ::= <forward_pcr_clp0_statement> <backward_pcr_clp0_statement> <forward_pcr_clp1_statement> <backward_pcr_clp1_statement> <forward_scr_clp0_statement> <backward_scr_clp0_statement> <forward_scr_clp1_statement> <backward_scr_clp1_statement> <forward_mbs_clp0_statement> <backward_mbs_clp0_statement> <forward_mbs_clp1_statement> <backward_mbs_clp1_statement> <forward_abr_mcr_statement> <backward_abr_mcr_statement> <best_effort_statement> <forward_pcr_clp0_statement> ::= FWD PCR CLP0 <relational_op> <forward_pcr_clp0_value> <forward_pcr_clp0_value> ::= INTEGER <backward_pcr_clp0_statement> ::= BWD PCR CLP0 <relational_op> <backward_pcr_clp0_value> <backward_pcr_clp0_value> ::= INTEGER <forward_pcr_clp1_statement> ::= FWD PCR CLP1 <relational_op> <forward_pcr_clp1_value> <forward_pcr_clp1_value> ::= INTEGER <backward_pcr_clp1_statement> ::= BWD PCR CLP1 <relational_op> <backward_pcr_clp1_value> 162

171 Le contrôle d accès dans les réseaux ATM - Annexes <backward_pcr_clp1_value> ::= INTEGER <forward_scr_clp0_statement> ::= FWD SCR CLP0 <relational_op> <forward_scr_clp0_value> <forward_scr_clp0_value> ::= INTEGER <backward_scr_clp0_statement> ::= BWD SCR CLP0 <relational_op> <backward_scr_clp0_value> <backward_scr_clp0_value> ::= INTEGER <forward_scr_clp1_statement> ::= FWD SCR CLP1 <relational_op> <forward_scr_clp1_value> <forward_scr_clp1_value> ::= INTEGER <backward_scr_clp1_statement> ::= BWD SCR CLP1 <relational_op> <backward_scr_clp1_value> <backward_scr_clp1_value> ::= INTEGER <forward_mbs_clp0_statement> ::= FWD MBS CLP0 <relational_op> <forward_mbs_clp0_value> <forward_mbs_clp0_value> ::= INTEGER <backward_mbs_clp0_statement> ::= BWD MBS CLP0 <relational_op> <backward_mbs_clp0_value> <backward_mbs_clp0_value> ::= INTEGER <forward_mbs_clp1_statement> ::= FWD MBS CLP1 <relational_op> <forward_mbs_clp1_value> <forward_mbs_clp1_value> ::= INTEGER <backward_mbs_clp1_statement> ::= BWD MBS CLP1 <relational_op> <backward_mbs_clp1_value> <backward_mbs_clp1_value> ::= INTEGER <forward_abr_mcr_statement> ::= FWD ABR MCR <relational_op> <forward_abr_mcr_value> <forward_abr_mcr_value> ::= INTEGER <backward_abr_mcr_statement> ::= BWD ABR MCR <relational_op> <backward_abr_mcr_value> <backward_abr_mcr_value> ::= INTEGER <best_effort_statement> ::= BEST EFFORT IND <relational_op> <best_effort_value> <best_effort_value> ::= INTEGER <eqosp_statement> ::= <forward_cdv_statement> <backward_cdv_statement> <forward_clr_statement> <backward_clr_statement> <forward_cdv_statement> ::= FWD CDV <relational_op> <forward_cdv_value> <forward_cdv_value> ::= INTEGER <backward_cdv_statement> ::= BWD CDV <relational_op> <backward_cdv_value> <backward_cdv_value> ::= INTEGER <forward_clr_statement> ::= FWD CLR <relational_op> <forward_clr_value> <forward_clr_value> ::= INTEGER 163

172 Le contrôle d accès dans les réseaux ATM - Annexes <backward_clr_statement> ::= BWD CLR <relational_op> <backward_clr_value> <backward_clr_value> ::= INTEGER <atm_priority_statement> ::= <PRIORITY> <relational_op> <priority_value> <priority_value> ::= INTEGER <transport_layer_statement> ::= <ip_statement> <icmp_statement> <udp_statement> <tcp_statement> <ip_statement> ::= <ip_protocol_statement> <ip_options_statement> <ip_protocol_statement> ::= 'IP PROTOCOL' <relational_op> <ip_protocol_value> <ip_protocol_value> ::= <ip_options_statement> ::= 'IP OPTION' <relational_op> <ip_option_value> <ip_option_value> ::= 'SEC' 'RR' 'TS' 'LSR' 'SSR' <icmp_statement> ::= 'ICMP TYPE' <relational_op> <icmp_type_value> 'ICMP CODE' <relational_op> <icmp_code_value> <icmp_type_value> ::= <icmp_code_value> ::= [0-15] <tcp_statement> ::= <port_statement> <tcp_flag_statement> <tcp_flag_statement> ::= 'TCP FLAG' <relational_op> <tcp_flag_value> <tcp_flag_value> ::= 'SYN' 'SYNACK' 'RST' 'ACK' 'FIN' 'FINACK' <udp_statement> ::= <port_statement> <port_statement> ::= 'SRC PORT' <relational_op> <port_value> 'DST PORT' <relational_op> <port_value> <port_value> ::= INTEGER <application_layer_statement> ::= <application_id_statement> <application_user_statement> <application_state_statement> <application_id_statement> ::= 'APPLICATION' <relational_op> <application_id> <application_id> ::= INTEGER <application_user_statement> ::= 'USER' <relational_op> <application_user_id> <application_user_id> ::= INTEGER <application_state_statement> ::= 'STATE' <relational_op> <state_id> <state_id> ::= INTEGER <time_category_statement> ::= 'AT' <time_value> 'FROM' <time_value> 'TO' <time_value> <time_value> ::= INTEGER ':' INTEGER ':' INTEGER' <relational_operator> ::= '=' '<>' '>' '>=' '<' '=<' 164

173 Le contrôle d accès dans les réseaux ATM - Annexes <topology_definition> ::= <topology_condition_or_list> <topology_condition_and_list> <topolgy_condition_or_list> ::= <topology_condition_and_list> ['OR' <topology_condition_and_list>]* <topology_condition_and_list> ::= <topology_condition_statement> ['AND' <topology_condition_statement>]* <topology_statement> ::= <static_connection_statement> <atm_addressing_statement> <ip_addressing_statement> <static_connection_statement> ::= <vpi_statement> <vci_statement> <vpi_statement> ::= 'VPI' <relational_op> <vpi_value> <vci_statement> ::= 'VCI' <relational_op> <vci_value> <vpi_value> ::= INTEGER <vci_value> ::= INTEGER <atm_addressing_statement> ::= <atm_id_statement> <atm_sub_id_statement> <atm_ptmtp_statement> <atm_id_statement> ::= <adress_plan_statement> <address_statement> <address_plan_statement> ::= 'ATM PLAN' <relational_op> <addressing_plan_value> <address_plan_value> ::= INTEGER <address_statement> ::= 'ATM ADDR' <relational_op> <atm_address_value> <atm_address_value> ::=STRING[20] <sub_id_statement> ::= <subaddress_type_statement> <subaddress_statement> <subaddress_type_statement> ::= 'ATM TYPE' <relational_op> <subaddress_type_value> <subaddress_type_value> ::= INTEGER <subaddress_statement> ::= 'ATM SUBADDR' <relational_op> <subaddress_value> <subaddress_value> ::= STRING[20] <atm_ptmtp_statement> ::= <PTMPT ID> <relational_op> <ptmtp_id_value_value> <ptmtp_id_value> ::= INTEGER <ip_addressing_statement> ::= 'IP ADDR' <relational_op> <ip_address> <ip_address> ::= <ip_addr_value> <ip_addr_value> ::= INTEGER '.' INTEGER '.' INTEGER '.' INTEGER <role_definition> ::= <topology_identifier> <direction> <topology_identifier> '::=' <service_identifier> <topology_identifier> '::=' <service_identifier> <direction> ::= '->' '<-' '<>' 165

174 Le contrôle d accès dans les réseaux ATM - Annexes 3.2. Algorithmes utilisés MIR dans le cas de RIP Configuration initiale Le fonctionnement de ce module est très dépendant de la façon dont le routage est réalisé dans le réseau. Afin de prouver notre théorie nous prendrons pour exemple le protocole de routage le plus utilisé, à savoir RIP. On suppose que le processus de routage a démarré avant le processus de gestion du contrôle d'accès. Le lecteur intéressé par des informations plus complètes sur RIP pourra se reporter à [Tou99]. Le module MIR contient une table NRoute contenant les dernières tables de routage données par les équipements voisins. Celle-ci a le format suivant: Adresse du voisin (av), Adresse IP (a), Masque de sous réseau (m), Métrique (d). Il contient également une table Route contenant la table de routage et ayant le format suivant: Adresse IP (a), Masque de sous réseau (m), Métrique (d). Fonctionnement ultérieur Réception de comm(rule r) du MCCA. s = source(r); d = destination(r); Si (s = NILL et d = NILL) alors Renvoyer(Yes); Sinon Soit a/appartient(s,route[a].a,route[a].m); Soit b/appartient(d,route[b].a,route[b].m); Soit f = Route[a].d + Route[b].d; Pour tout i/appartient(s,nroute[i].a,nroute[i].m) faire Pour tout j/appartient(d,nroute[j].a,nroute[j].m) faire Soit e = NRoute[i].d + NRoute[j].d; Si e < f Alors Renvoyer(No); Renvoyer(Yes); Réception de distance(address y) du MEICA. Soit i/appartient(y,route[i].a,route[i].m); Renvoyer(Route[i].d); Modification de la table NRoute par l'agent de Routage. res = MCCA.rtopologych(); Modification de la table Route par l'agent de Routage. res = MCCA.rtopologych(); Les algorithmes précédents utilisent une fonction externe Appartient(s,a,m) qui indique si l'adresse ou l'ensemble d'adresses décrit par s est inclus dans le réseau R décrit par l'adresse a et le netmask m et qu'il n'existe pas de réseau R', sous réseau de R décrit par a' et m' tel que Appartient(s,a',m') MIR dans le cas de PNNI Configuration initiale MIR sur RIP assure la configuration du routage en fonction des informations d'adressage uniquement. Dans le cas des réseaux proposant des garanties en terme de qualité de service (comme les réseaux ATM) le routage ne se fait plus uniquement sur les informations de routage mais également en fonction des informations liées à la spécification de la qualité de service des connexions. Le document spécifiant la protocole PNNI [PNNI10] donne en annexe H l'algorithme utilisé pour calculer le chemin le plus court à partir d'un noeud This vers un noeud Dest en fonction d'une catégorie de service C et d'une métrique Q. Cet algo- 166

175 Le contrôle d accès dans les réseaux ATM - Annexes rithme est utilisé pour calculer les DTLs qui servent au routage des demandes de connexion. Nous appellerons par la suite cet algorithme Generate_all_routes(C,Q,Tiebreakers). Cet algorithme remplit deux structures de données: Une table BestCosts[AllNodeCount] qui donne le meilleur coût en fonction de la destination (et de la métrique Q). Une table BestPaths[AllNodeCount,pathcount] qui donne les chemins optimaux vers les destinations. Le routage suivant la spécification PNNI étant hiérarchique, chaque noeud n'a une connaissance complète que des éléments de son groupe. Il n'est donc pas possible de calculer des routes complètes de n'importe quel noeud du réseau vers n'importe quel autre mais uniquement des routes hiérarchiques. Fonctionnement ultérieur Réception de comm(rule r) du MCCA. Add = This; s = source(r); d = destination(r); c = classofservice(r); Si (s = NILL ou d = NILL) alors Renvoyer(Yes); Sinon Pour chaque q appartenant à metrics(r) faire This = s; Generate_all_routes(c,q,t); Soit i/inclus(add, BestPaths[d, i]); si i <> NILL alors This = Add; Renvoyer(Yes); This = Add; Renvoyer(No); Réception de distance(address y) du MEICA. Min = NILL; Pour tout q appartenant à {metrics} faire Pour tout c appartenant à {cos} faire Generate_all_routes(c,q,t); Si Bestcost[y] < Min alors Min = Bestcost[y]; Renvoyer(Min); Réception d'un PTSP (PNNI Topology State Packet) par l'agent de Routage. res = MCCA.rtopologych(); 167

176 Le contrôle d accès dans les réseaux ATM - Annexes 168

177 Liste des figures Figure 1. Approche non bloquante Figure 2. Approche bloquante Figure 3. Fonctionnement d un firewall Figure 4. Fonctionnement de l analyseur de sécurité Figure 5. Projection et construction des tableaux dans le cas de règles à deux dimensions Figure 7. Méthode de construction des codages minimaux dans le cas de règles à deux dimensions Figure 8. Découpage de l espace de recherche et construction de l arbre de classement associé Figure 9. Construction d un FIS d ordre 2 dans une dimension Figure 10. Remplissage d un segment de mémoire trie dans une dimension avec deux intervalles Figure 11. Règles de contrôle d'accès pour un routeur Cisco Figure 12. Règles de contrôle d'accès pour une station Linux utilisant ipfwadmin Figure 13. Optimisation pour une communication concernant les équipements A et B Figure 14. Modèle ATM Figure 15. Positionnement d un firewall dans un environnement LANE Figure 16. Positionnement d un firewall dans un environnement CLIP Figure 17. Positionnement d un firewall dans un environnement MPOA Figure 18. Connexions ATM de part et d autre d un firewall Figure 19. Informations accessibles Figure 20. Shéma de fonctionnement du firewall ATM ATLAS Figure 21. Structure du firewall Figure 22. Composants physiques du firewall Figure 23. Gestion des cellules dans le firewall ATM Figure 24. En-tête de cellule ATM à l interface UNI Figure 25. Le plan de contrôle Figure 26. Pile protocolaire utilisée par CLIP Figure 27. Pile protocolaire utilisée par LANE

178 Le contrôle d accès dans les réseaux ATM - Liste des figures Figure 28. Pile protocolaire utilisée par MPOA au niveau d un MPC...66 Figure 29. Pile protocolaire utilisée par VTOA et CES Figure 30. Pile protocolaire utilisée par les services ANS et AMS Figure 31. Utilisation des informations caractérisantes Figure 32. Placement des agents de contrôle d accès dans le réseau Figure 33. Structure d un agent de gestion...80 Figure 34. Structure d un agent de contrôle d accès Figure 35. Structure des champs status Figure 36. Représentation sous forme de graphe du contenu de la mémoire trie Figure 37. Algorithme de construction de la structure de classement...87 Figure 38. Décomposition des règles et création des intervalles...88 Figure 39. Graphe d analyse au niveau Figure 40. Graphe d analyse au niveau Figure 41. Algorithme de construction de la structure de classement (avec compression)...89 Figure 42. Compression de la structure de classement Figure 43. Architecture générale de la maquette CARAT...92 Figure 44. Génération de la politique de contrôle d accès Figure 45. Configuration du commutateur ATM pour la signalisation ATM...93 Figure 46. Filtrage de la signalisation Figure 47. Configuration du commutateur ATM pour le trafic utilisateur Figure 48. Ordre d analyse des champs Figure 49. Processus de fonctionnement des IFTs...98 Figure 50. Exemple de politique de contrôle d accès Figure 51. Exemple de politique de contrôle d accès Figure 52. Processus de gestion du contrôle d accès Figure 53. Architecture générale Figure 54. Structure interne d'un agent de gestion du contrôle d accès Figure 55. Modélisation du réseau au niveau ATM Figure 56. Correspondances inter-couches Figure 57. Algorithme initial de distribution des règles Figure 58. Premier algorithme d'optimisation de la distribution Figure 59. Deuxième algorithme d'optimisation de la distribution Figure 60. Relations entre éléments externes Figure 61. Architecture fonctionnelle d un agent de gestion du contrôle d accès Figure 62. Réseau simple Figure 63. Réseau Maillé Figure 64. Efficacité du critère R3 (en nombre de règles) Figure 65. Efficacité relative du critère R3 (en %) Figure 66. Chemin suivi pour la résolution des problèmes exposés au chapitre

179 Liste des tableaux Tableau 1. Comparaison des techniques de classement Tableau 2. Paramètres utilisés dans les classes de trafic Tableau 3. Modification des paramètres en fonction du niveau de filtrage Tableau 4. Modification des contrats de trafic en fonction du niveau de filtrage Tableau 5. Modification de certains éléments de contrat de trafic par un firewall Tableau 6. Utilisation des classes de contrôle Tableau 7. Comparaison des différentes propositions en terme de contrôle d accès ATM Tableau 8. Codage des différents types de flux Tableau 9. Lien entre syntaxe et sémantique des cellules de gestion Tableau 10. Classement des paramètres par classe d application Tableau 11. Valeur de certains des éléments de signalisation dans le cas de CLIP Tableau 12. Valeur de certains des éléments de signalisation dans le cas du LANE Tableau 13. Relations entre type de communication et messages de signalisation utilisés Tableau 14. Valeur de certains des éléments de signalisation dans le cas de CES Tableau 15. Valeur de certains des éléments de signalisation dans le cas de VTOA Tableau 16. Valeur de certains des éléments de signalisation dans le cas du service ANS Tableau 17. Valeur de certains des éléments de signalisation dans le cas du service AMS Tableau 18. Relation entre valeur des champs caractérisants et services Tableau 19. Relation entre valeur des champs caractérisants et services Tableau 20. Relation entre valeur des champs caractérisants et services Tableau 21. Relation entre valeur des champs caractérisants et applications Tableau 22. Récapitulatif des paramètres fournis par le modèle ATM Tableau 23. Exemple de mémoire Trie Tableau 24. Capacités d analyse des cartes IFT au niveau ATM...85 Tableau 25. Capacités d analyse des cartes IFT au niveau TCP/IP...86 Tableau 26. Durée d une simulation de connexion en fonction du filtrage réalisé

180 Le contrôle d accès dans les réseaux ATM - Liste des tableaux Tableau 27. Calcul du temps maximal d analyse Tableau 28. Capacités de classement en fonction de la latence du circuit d analyse...99 Tableau 29. Utilisation mémoire Tableau 30. Complexités spatiales et capacités de classement en fonction du nombre de règles et de la largeur des champs de la mémoire trie pour k = 6 et c = Tableau 31. Comparaison des différentes méthodes de classement Tableau 32. Architectures de C.A. utilisables en fonction du placement des autres services de sécurité Tableau 33. Architectures de C.A. utilisables en fonction du type d application Tableau 34. Classement des règles Tableau 35. Classement de l'instanciation des règles Tableau 36. Efficacité des différents critères Tableau 37. Classement des règles Tableau 38. Liens entre messages et IEs dans l'uni Tableau 39. Liens entre messages et IEs dans les normes ITU-T Tableau 40. Récapitulatif des paramètres fournis par les MIBs du modèle ATM Tableau 41. Récapitulatif des paramètres fournis par les MIBs relatives à TCP/IP Tableau 42. Récapitulatif des paramètres fournis par les MIBs applicatives

181 Liste des acronymes AAL AARPS ACL ABR AMS ANS ARP ATM BBLP BDCA BNF BUS CAC CAM CAS CBR CDV CDVT CES A Atm Adaptation Layer. ATMARP Address Resolution Server. Access Control List. Available Bit Rate. Audiovisual Multimedia Services. ATM Name System. Address Resolution Protocol. Asynchronous Transfer Mode. B Biba Bell-Lapadula. Base de Donnée de Control d Accès. Backus Naur Form. Broadcast and Unknown Server. C Connection Admission Control. Content Adressable Memory. Carrying channel Associated Signaling. Constant Bit Rate. Cell Delay Variation. Cell Delay Variation Tolerance. Circuit Emulation Service. CLIP Classical IP over ATM. CLP0 Cell Loss Priority 0. CLP1 Cell Loss Priority 1. CLP0+1 Cell Loss Priority 0+1. CLR Cell Loss Ratio. CMIP Common Management Information Protocol. CMW CompartMented Workstation. COPS Common Open Policy Service. CPCS Common Part Convergence Sublayer. CPVC Control PVC. CRC Cyclic Redundancy Check. CS Convergence Sublayer. CTD Cell Transit Delay. D DAC Discretionary Access Control. DES Data Encryption Standard. DNS Domain Name System. DS-X Digital Signal Level X. DSS-2 Digital Subscriber Signalling System #2. 173

182 Le contrôle d accès dans les réseaux ATM - Liste des acronymes E architecture. E-X EDC ELAN ESF Special Digital Trunk, European. Error Detection Code. Emulated LAN. Extended Super Frame. ISO ITU-T IWF International Standards Organisation. International Telecommunications Union. InterWorking Function. FCP FIP FIS FPGA FTP GID GFC GSMP HEC HMAC HRU ICMP IE IEC IEEE IESG IETF IFT ILMI IP IPI IPL IPSEC F Firewall Control Processor. Firewall Inline Processor. Fat Inverted Segment Tree. Field-Programmable Gate Arrays. File Transfert Protocol. G Group IDentifier. Generic Flow Control. General Switch Management Protocol. H Header Error Control. Hash Message Authentication Code. Harrison Ruzzo Ullman. I Internet Control Message Protocol. Information Elements. International Electrotechnical Commission. Institute of Electrical and Electronics Engineers. Internet Engineering Steering Group. Internet Engineering Task Force. Internet Fast Translator. Integrated Local Management Interface. Internet Protocol. Initial Protocol Identifier. IP Lookup Problem. Internet Protocol Security J-X LAN LANE LCH LDPCA LEC LECS LES LIJC LLC LRU J Japanese standard for electrical PDH transmission. L Local Area Network. LAN Emulation. Last Cell Hostage. Langage de Définition de Politique de Contrôle d Accès. Lan Emulation Client. Lan Emulation Configuration Server. Lan Emulation Server. Leaf Initiated Join Capability. Logical Link Control. Last Recently Used. M MAC Mandatory Access Control. MAC Medium Access Control. MARS Multicast Address Resolution Server. MBS Maximum Burst Size. MCA Module de Contrôle d accès. MCCA Module de Configuration du Contrôle d Accès. MCR Minimum Cell Rate. MCS Multicast Server. MD-X Message Digest number X. MEICA Module d Echange d Information sur le Contrôle d Accès. MGCCA Module de Gestion Centralisée du Contrôle d Accès. MIB Management Information Base. MIH Module d Informations Horaires. 174

183 Le contrôle d accès dans les réseaux ATM - Liste des acronymes MII MIR MPC MPEG MPLS MPOA MPS NLANR NIST NHRP Module d Information d Implémentation. Module d Information de Routage. MPOA Client. Motion Picture Expert Group. Multi Protocol Label Switching. Multi Protocol Over ATM. MPOA Server. N National Laboratory for Applied Network Research. National Institute of Standards and Technology. Next Hop Resolution Protocol. O OAM Operation Administration and Maintenance. OC X Optical Coupler X. OPVC Outgoing PVC. OSI Open System Interconnection. OUI Organizationally Unique Identifier. PC PCR PDH PDL PDP PDU PEICA PEP PFIP PIB PID PNNI PT PTSP PVC P Personal Computer. Peak Cell Rate. Plesiochronous Digital Hierarchy. Policy Definition Language. Policy Decision Point. Protocol Data Unit. Protocol d Echange d Informations de Contrôle d Accès. Policy Enforcement Point. Packet Filter Information Protocol. Policy Information Base. Protocol Identifier. Private Network-Network Interface. Payload Type. PNNI Topology State Packet. Permanent Virtual Circuit. QoS RAP RIP RL RNIS-BE RNIS-LB ROSE RPC RSA RST SAAL SAMSON SAP SAR SCR SDH SF SHA SLDRAM SMI SNAP SNMP Q Quality of Service. R Ressource Allocation Protocol. Routing Information Protocol. Range Location. Réseau Numérique à intégration de Service à Bande Etroite. Réseau Numérique à intégration de Service à Large Bande. Remote Operation Service Element. Remote Procedure Call. Rivest Shamir Aldermann. Reset. S Signaling AAL. Security and Management Services in Open Networks. Service Access Point. Segmentation and Reassembly. Sustainable Cell Rate. Synchronous Digital Hierarchy. Super Frame. Secure Hash Algorithm. Synchronous Link Dynamic Random Access Memory. Structure of Management Information. SubNetwork Access Protocol. Simple Network Management Protocol. SPP Security Policy Protocol. SRAM Static Random Access Memory. SSCOP Service Specific Connection Oriented Protocol. SSCS Service Specific Convergence Sublayer. SVC Switched Virtual Circuit. 175

184 Le contrôle d accès dans les réseaux ATM - Liste des acronymes TCP TD TLS T Transmission Control Protocol. Transit Delay. Transport Layer Security protocol. UBR UDP UID UNI U Unspecified Bit Rate. User Datagram Protocol. User IDentifier. User-Network Interface. VBR rt-vbr nrt-vbr VC VCI VP VPI VTOA V Variable Bit Rate. Real Time VBR. Non Real Time VBR. Virtual Chanel. Virtual Chanel Identifier. Virtual Path. Virtual Path Identifier. Voice and Telephony Over ATM. WAN WWW W Wide Area Network. Word Wide Web. ZBT Z Zero Bus Turnaround. 176

185 VU: VU: Le Directeur de Thèse Le Responsable de l Ecole Doctorale VU pour autorisation de soutenance Rennes, le Le Président de l Université de Rennes 1 Patrick NAVATTE VU après soutenance pour autorisation de publication : Le Président de Jury,

186