Nouvelles tendances en architecture de réseaux : le projet ANCORS

L'émergence de nouveaux services sur Internet, pourtant fortement désirée par la majorité des acteurs du réseau, est considérablement freinée par les difficultés relatives au déploiement : toute implantation d'un nouveau protocole devient rédhibitoire lorsque l'on raisonne à l'échelle d'Internet, le nombre de machines concernées devenant rapidement trop important.

Même l'administration d'un réseau multi-domaines, qui porte pourtant sur un nombre plus restreint de machines, pose ce genre de problèmes.

Il devient donc évident qu'Internet doit changer dans plusieurs directions. En particulier, de nouveaux mécanismes devront être mis en place pour faciliter

• le redéploiement des ressources réseaux ;
• la réécriture des règles de communication ;
• l'insertion dynamique de nouveaux services.

De nombreux projets de recherche sont en cours, pour permettre de rendre dynamiquement (c'est à dire sans débrancher une partie du réseau pour effectuer des travaux de maintenance) et automatiquement (sans, ou en tout cas avec peu, d'intervention humaine) ces nouveaux services. Par exemple, toute la recherche autour de ce que l'on appelle les Réseaux Actifs (Active Networks) tente de mettre en place ces paradigmes.

Si déjà l'implémentation de ces mécanismes pose de grands problèmes techniques, d'autres aspects, notamment ceux concernant la sécurité, sont encore plus hardus à mettre en place.

• Il est nécéssaire de d'assurer la cohérence des changements dynamiques, et de permettre d'exercer sur eux un certain contrôle (tout le monde ne devra pas avoir la possibilité de modifier le réseau) ;
• L'impact des changements dynamiques devra rester limité sur les performances du réseau, et la stabilité devra être garantie.

Dans ce cadre, le projet ANCORS (Adaptable Network COntrol and Reporting System) poursuit trois buts différents :

1. Améliorer le déploiement des logiciels réseaux. Si des programmes de recherche existent déjà, comme par exemple ANTS, aucun ne permet pour l'instant la mise à jour de composants logiciels opérants au niveau système.
2. Fournir des outils de surveillance et de contrôle du réseau : les outils qui existent déjà n'opèrent qu'à petite échelle, et sont pour l'instant peu adaptatifs (l'administrateur réseau peut difficilement spécifier de nouvelles mesures à effectuer). ANCORS veut permettre l'administration multi-domaines, l'étude du fonctionnement global du réseau ainsi que la détection des dysfonctionnements éventuels.
3. Permettre la simulation des réseaux avec des données réelles, et le test des logiciels réseau en grandeur nature.

L'originalité d'ANCORS est de vouloir attaquer ces trois fronts à la fois.

Les buts d'ANCORS

Revenons plus en détail sur les fonctionnalités qui sont proposées par le projet ANCORS : selon ses auteurs, il y a trois niveaux de services qui peuvent bénéficier d'améliorations.

• Les services de transport de données. Ce n'est pas le but premier d'ANCORS, d'autant que d'autres projets, comme ANTS, étudient déjà ces aspects.
• Les services de contrôle et de surveillance : le but d'ANCORS est de permettre de lire l'état des différents services du réseau, de rendre compte des informations intéressantes, et d'offrir des mécanismes pour changer la configuration "à la volée". Il permettra aussi à un utilisateur de définir de nouveaux services de surveillance, et de les déployer dynamiquement.
  Ceci devrait permettre de faire évoluer la surveillance des réseaux en même temps qu'évolue leur fonctionnement. De plus, les concepteurs d'ANCORS veulent pouvoir inclure des instruments de surveillance dans n'importe quel élément du réseau, ceci de façon à pouvoir équilibrer la charge.
• Les services d'ingénierie : ils permettront de concevoir et de tester des services avant leur déploiement, à l'aide d'une simulation. Les concepteurs d'ANCORS veulent utiliser des données réelles : par conséquent, il faut que les outils de simulation soient intégrés dans le réseau, et utiliser comme données de simulation les données qu'ils observent.
  D'autre part, il est nécéssaire que ces outils de simulation soient accessibles au plus grand nombre : les opérateurs de réseau, avant d'effectuer des modifications majeures, doivent pouvoir tester l'impact de ces modifications à grande échelle, sans pour autant pouvoir altérer le fonctionnement du réseau. Le déploiement de nouveaux outils de simulation doit donc être dynamique, et accessible à un grand nombre d'entités.
  Pour fournir ces fonctionnalités, les concepteurs d'ANCORS ont décidé d'intégrer la simulation au coeur de la gestion du réseau, afin de pouvoir
  1. réutiliser le logiciel de réseau pour la simulation,
  2. permettre l'utilisation de données réelles pour la simulation,
  3. rapprocher la simulation des données pour réduire la charge de calcul,
  4. réutiliser les fonctionnalités de surveillance et de contrôle du réseau peuvent pour la simulation.

Ces trois types de service forment ce qui est appelé la couche "données". Il existe deux autres couches, la couche "évaluation" et la couche "contrôle".

• La couche "évaluation" est interfacée avec la couche "donnée" par l'intermédiaire des services de surveillance et de contrôle et ne peut accéder aux services d'ingénierie et de transport de données que par cet intermédiaire.
• La couche "évaluation" a deux buts : d'une part elle fournit une analyse heuristique des données qu'elle reçoit de la couche données, et rend compte des comportements anormaux, et d'autre part un algorithme d'apprentissage adaptatif fait une analyse continue des données, ceci afin de faire émerger des comportements "types".
• La couche "contrôle" reçoit ses informations de la couche "évaluation" : elle prend des décisions par rapport à des comportements prédéfinis, et met en place de manière automatique une réponse adaptée : le projet ANCORS s'intéresse aussi à la manière dont on peut d'une façon efficace répondre à un comportement donné du réseau. En cas de doute ou d'incompétence, un administrateur humain est informé.

Nous voyons donc que les buts poursuivis par le projet ANCORS sont divers, et qu'ils recoupent des champs d'activité majeurs pour l'évolution future des réseaux.

ANETD

• D'une part, il permet le déploiement, la configuration et le contrôle de logiciels dans le réseau,
• Il permet de démultiplexer des packets de réseaux actifs à l'attention de plusieurs environnements qui s'exécutent sur un même hôte.

Capacités de déploiement

Un administrateur, en agissant à distance sur un démon ANETD, peut demander le chargement d'un nouveau service : ceci se fait en deux temps. Dans un premier temps, L'administrateur indique à ANETD une URL ou il va trouver le service à télécharger ; Cette URL est modifiée par ANETD en fonction de l'hôte sur lequel il tourne, par l'ajout d'un suffixe correspondant au type de système d'exploitation ; dans un second temps, soit ANETD crée un nouveau processus par fork, soit il crée un nouveau thread (selon le désir de l'administrateur) et la nouvelle entité créée va cherche sur Internet le service en question à l'aide d'une requête HTTP 'GET'. Malgré le nombre élevé de démons qui peuvent éventuellement fonctionner en même temps, ils se comportent, vu de l'extérieur, comme s'il n'y en avait qu'un seul.

Dans l'implémentation actuelle d'ANETD, trois sortes d'applications sont supportées : les exécutables en langage machine, les applications JAVA, et les exécutables ANCORS.

Le fonctionnement pour les exécutables en langage machine et pour les applications JAVA est très simple : après le téléchargement, elles sont exécutées ; l'administrateur a alors deux possibilités pour les configurer, soit en uploadant des fichiers de configuration, soit en fournissant une ligne de commande.

D'autre part, ANETD implémente des fonctionnalités qui ne sont pas forcément présentes dans le système sur lequel tourne le démon, pour pouvoir faciliter la programmation des services ANCORS indépendamment du type de système d'exploitation. Ces fonctionnalités sont :

1. Le multithreading non préemptif ;
2. l'émulation LAN multicast ;
3. la synchronisation à une horloge globale.

Les exécutables ANCORS prennent la forme de librairies chargées dynamiquement à la demande de l'administrateur. Ces librairies possèdent toutes un point d'entrée : une fonction init_model, qui sert à ANETD pour démarrer le service de manière automatique.

En plus de la fonction init_model, un exécutable ANCORS peut contenir plusieurs procédures appelables à distance. L'administrateur peut y accéder en envoyant une commande 'CONF' à ANETD, qui transforme cette commande en RPC à un service chargé. Voici la liste des commandes que peut exécuter ANETD :

• LOAD : permet de demander à ANETD de télécharger un service. Les diverses options permettent de spécifier l'endroit où le démon doit aller chercher les exécutables, et le type d'exécutable dont il s'agit, ainsi que les arguments de la ligne de commande.
• QUERY : permet de demander à ANETD quels sont les services actuellement exécutés sur l'hôte.
• KILL : permet de tuer un service.
• GET : permet de rapatrier un fichier de l'hôte sur lequel tourne ANETD.
• PUT : permet de charger un fichier sur l'hôte sur lequel tourne ANETD.
• CONF : permet de faire des RPC.

Le démultiplexage des paquets ANEP

Les paquets ANEP permettent de modifier les logiciels réseaux présent sur une machine, et de reconfigurer de manière sûre le réseau. (Le projet ANTS étudie ces idées plus en détail).

ANETD écoute sur un port UDP (par exemple le port des réseaux actif, 3322), et accepte des commandes selon deux approches différentes :

• L'approche discrète : un administrateur modifie, maintient, ou charge du logiciel réseau par des commandes explicites, du type 'load', 'get', etc.
• L'approche intégrée : si un des paquets est destiné à un des services téléchargés par ANETD, le paquet est dirigé vers ce service. Ceci est très utile, par exemple lorsque plusieurs services écoutent sur un même port, comme c'est pour l'instant le cas dans l'architecture actuelle des réseaux actifs.

ANETD et la sécurité

Tout le monde ne peut pas envoyer des commandes à ANETD. En fait, ANETD utilise un procédé cryptographique à clef publique dont les clefs ont une longueur de 512 bits, et permet de recevoir des commandes ne provenant que d'un certain nombre de sites (identifiés par leur IP) dont la liste est dans le fichier hosts.allow, et de recevoir du code ne provenant que d'un ensemble restreint de serveurs http référencés dans web.allow.

Ainsi, lorsque une commande arrive à ANETD, il regarde si l'origine de la commande appartient bien à la liste des hôtes autorisés dans hosts.allow, puis vérifie la signature à l'aide de la clef publique stockée dans ce même fichier. Le fonctionnement pour le téléchargement de logiciels est identique.

Applications déjà réalisées avec ANETD

Les chercheurs du projet ANCORS ont déjà réalisé deux applications, décrites dans le second rapport d'étape.

D'une part, ils ont créé un exécutable ANCORS qui simule un noyau Unix : c'est une modification de noyau Linux auquel on a enlevé toutes les parties dépendantes du système, ainsi que les interfaces avec l'utilisateur, et que l'on peut faire fonctionner en mode user. Le système de fichiers a été détruit, et les procédures de configuration nécessaires, comme ifconfig ou route ont été incluses à l'intérieur du noyau simulé. L'odonnancement a été remplacé en utilisant le système de multi-threading non-préemptifs offert par ANETD.

Ce service émulant un noyau unix a permis de simuler le comportement réseau d'un véritable noyau Linux. Comme l'API Linux est toujours disponible, on peut simuler une grande variété de conditions de charge (en particulier grâce à l'aptitude d'ANETD de créer de nouveaux threads). Il est possible soit d'utiliser des modèles anaytiques, soit d'utiliser des applications réelles.

Cet outil a permis de tester et comparer deux méthodes de synchronisation, une dérivée de la théorie du temps virtuel de Lamport, l'autre dérivé d'un algorithme de Chandy et Misra.

D'autre part, les chercheurs du projet ANCORS ont aussi développé un prototype de module de détection d'intrusion. Ce module peut être déployé et configuré dynamiquement dans n'importe quel élément du réseau possédant un démon ANETD : il est basé sur un outil de recherche en détection d'intrusion appelé EMERALD (Event Monitoring Enabling Responses to Anomalous Live Disturbances).

Ce module de détection d'intrustion est composé de filtres d'événements, qui analysent un grand nombre de données opérationnelles, telles que les données d'audit, les fichiers de rapport d'activité de la couche application, et le trafic réseau. Le module contient un programme d'analyse, constitué d'un système expert analysant les signatures, et d'un système de détection des anomalies statistiques.

Documents de référence

• ANCORS, premier rapport d'étape
• ANCORS, second rapport d'étape
• Anetd, Active NETwork Daemon