< Routage et Réseaux Actifs >

Transcription

1 UNIVERSITE LIBANAISE (Faculté de Génie) UNIVERSITE SAINT-JOSEPH (Faculté d'ingénierie) Sous l'égide de l'agence Universitaire de la Francophonie AUF Diplôme d'etudes Approfondies Réseaux de télécommunications < Routage et Réseaux Actifs > Par <SAAD Rabih> Encadré par : M. Maroun Chamoun M. Ahmed Serhrouchni Soutenance le 22 décembre 2004 devant le jury composé de MM. Samir Tohmé Président Mohamad Zoaeter Membre Wajdi Najem Membre Imad Mougharbel Membre Nicolas Rouhana Membre Mahmoud Doughan Membre Maroun Chamoun Membre 1

2 Remerciements Je tiens à remercier Mr. Maroun CHAMOUN, le responsable de mon projet, pour son aide, son orientation, ses conseils et surtout son temps précieux, indispensables pour la bonne réalisation de ce projet. 2

3 Table des matières : Sujet Page Projet 5 1-Routage IP Les tables de routage Equipement réseau Fonctionnement d un routeur Protocole de routage Protocole de routage interne Protocole de routage externe Limites du routage IP 25 2-Les Réseaux actifs Introduction Modèle de réseau programmable Avantages des réseaux actifs Sécurité dans les réseaux actifs Les différentes architectures Comparaison Conclusion 41 3-ANTS Introduction NodeOS des réseaux actifs Architecture du NodeOS ANTS "Active Network Transfer System JANOS NET 52 3

4 5-SOAP Generalite Avantage Message SOAP Concept de filtre 58 6-WSE Introduction au WSE Routage avec le WSE WS-Security 61 7-Architecture ASWA Introduction Intérêt des services Web dans la conception des réseaux actifs Architecture ASWA Implémentation de ASWA Implémentation de la sécurité dans ASWA Exemple d une application Active : un pare-feu intelligent Conclusions 80 8-Proposition Introduction Plan de notre proposition Méthode sans routage Comment ça marche? Méthode avec routage Conclusion et perspective 92 9-Reference 93 4

5 Sujet No. 9 Routage et Réseaux Actifs Objectifs : Ce sujet sur les réseaux actifs consiste en l'étude et l'analyse du routage dans les réseaux actifs. Les plateformes : ANTS du MIT, BEES de UTAH,... Ce travail doit déboucher sur une contribution qui consiste à proposer un routage orienté application et qui s'adapte à une architecture de réseaux actifs. Ce sujet permettra de maîtriser la problématique des réseaux actifs et implicitement de mieux cerner les limites des réseaux classiques. La distribution du code notamment réseaux sur des équipements quelconques représente un enjeu capitale pour les fournisseurs de services. Réseaux actifs : motivations Le modèle de référence de l'interconnexion des systèmes ouverts de l'iso a été sans aucun doute le point de départ de l'émergence des réseaux informatiques et de télécommunications actuels. Ce modèle en couches se justifiait car il avait pour objectif la définition d'un cadre pour unifier les différentes architectures et protocoles de communication. Il a permis à une large communauté d'avoir un repère unique et ceci même quand il s'agissait de définir des protocoles propriétaires non standard. Les technologies issues de l'électronique et du traitement de l'information ont depuis évolués en puissance, ce qui se sont traduits entre autres par des capacités de transferts de grands volumes de données. Ceci a également permis d'envisager la mise en œuvre de nouvelles applications communicantes, notamment multimédia. Les besoins de ces diverses applications et donc leur sémantique sont maintenant trop nombreuses et hétérogènes pour envisager un traitement unique et générique. L'idéal serait de concevoir une pile de protocoles de communication spécifique à chaque classe d'application. Les technologies et concepts issus des réseaux actifs sont une première réponse. En effet, les nouvelles architectures de transport et de contrôle des services basées sur les paradigmes des réseaux actifs permettront aux nœuds du réseau (i.e. commutateur, routeur, multiplexeurs, ponts,...) d'effectuer des traitements personnalisés sur les messages qui transitent par ces équipements à l'initiative des applications, des utilisateurs ou de toute tiers personne responsable du contrôle du réseau. Cette approche innovante est motivée d'une part par le besoin de contrôle dynamique et personnalisé des applications et services de communications par l'utilisateur, et d'autre part par l'émergence des technologies de code mobile et de machine virtuelle qui rend possible le déploiement automatisé et rapide de nouveaux services et protocoles de communications. Ainsi dans les réseaux actifs l'ensemble des équipements traversés sont mis à contribution pour la réalisation d'un service quelconque. Une nouvelle problématique est ainsi introduite qu'est celle de distribuer le traitement sur les nœuds traversés, cette problématique bouleverse d'une manière capitale la vision actuelle «de bout en bout».les réseaux actifs doivent jouer un rôle important pour l'ouverture des équipements et ainsi la programmation des réseaux. Le routage : motivations Le routage dans les réseaux classiques est une fonctionnalité majeure dans les réseaux, elle est représente sa fonction principale voir unique. Son rôle est alors d'acheminer les données entre deux ou plusieurs équipements. Dans les réseaux actifs, le routage ne se limite pas à l'acheminement des données mais intègre la distribution du traitement à travers le réseau. Plusieurs plateformes actuellement proposent diverses méthodes pour le routage actif, mais il reste imprégné de la vision classique du réseau. 5

6 1. Routage IP 1 : Les tables de routage 1.1 : Définition Le protocole IP et l'attribution des espaces adresses par un organisme unique permettent de construire un réseau ayant une couverture mondiale. Mais les adresses IP n'indiquent pas directement la direction que doit suivre le paquet. Pour qu'un paquet puisse atteindre sa destination, il doit traverser des routeurs qui l'acheminent. Un routeur est un équipement qui possède plusieurs interfaces. Il contient des tables déterminant l'interface de sortie en fonction de l'adresse de destination des paquets. Une table de routage peut se résumer par trois informations : pour aller vers telle destination, il faut sortir par telle voie, avec tel coût associé : La destination La destination peut être soit un réseau ou un sous réseau IP (c'est-à-dire un ensemble de machines ayant une partie d'adresse commune), soit une machine particulière. Dans le cas d'une machine, l'adresse IP complète est donnée. Pour un réseau IP, les bits réservés à la numérotation des machines sont à 0. De même pour un sous réseau, mais le netmask doit alors être spécifié. Il existe une adresse particulière appelée default qui indique toutes les adresses non spécifiées par les autres entrées de la table. L'adresse default est aussi désignée par l'adresse IP Elle a pour utilité de réduire considérablement la taille des tables de routage : Le chemin Le chemin peut être soit une interface locale à la machine, soit un routeur intermédiaire situé sur le même réseau local. C'est pour cette raison qu'un routeur doit posséder une adresse sur chacun des réseaux auquel il est relié pour être accessible de toutes les stations : Le coût Le coût n'est pas une information de routage, mais servira aux équipements pour effectuer un choix quand deux routes conduisent vers une même destination. Le coût associé à un chemin est aussi appelé métrique. Une métrique peut prendre en compte le nombre de routeurs à traverser pour atteindre la destination souhaitée ou des critères plus complexes comme le débit, le délai, la fiabilité des liaisons, la taille des paquets, : Equipement réseau Dans ses documents, l'iso distingue deux équipements en définissant : ES (End Systems). Ce sont les équipements terminaux comme les stations de travail, les serveurs de fichiers, les imprimantes,... Ils ont une configuration minimale. IS (Intermediate Systems). Ce sont les systèmes intermédiaires qui traitent des données qui ne leurs sont pas directement destinées. Ce sont par exemple les routeurs. Ils connaissent une partie ou la totalité de la topologie du réseau. 6

7 1.3 : Fonctionnement d un routeur dans un réseau Quand un host veut envoyer un paquet vers une destination qui se trouve sur un autre réseau, le host transmet ce paquet vers le routeur en utilisant l adresse mac de l une de ces interfaces. Figure 1. Quand une trame arrive sur une interface d un routeur le paquet IP est décapsuler de la trame après avoir enlever l entête de la trame. Ensuite l entête IP est examiner pour trouver l adresse destination et le subnet mask. Le routeur fait un AND logique entre le subnet et l adresse destination pour enlève la partie host et obtenir l adresse réseau, cette dernière est comparée avec la table de routage pour obtenir une interface de sortie. Figure 2 Le paquet est ensuite encapsulé dans une trame dont l adresse MAC destination est celle du prochain routeur (l adresse IP ne change pas).ce processus est répété à chaque fois que le paquet arrive à un routeur jusqu a l arrivé du paquet à sa destination. 7

8 1.4 : Protocoles de routage Les tables de routages peuvent être configurées manuellement ou à l'aide d'outils d'administration du réseau. L'administrateur réseau introduit son plan de routage directement dans le routeur. Ce type de routage est dit statique. La méthode manuelle est relativement simple à mettre en œuvre et convient aux réseaux qui couvrent de petites étendues, en particulier, si le réseau comporte peu de sous réseaux IP. Par contre les routes statiques s'avèrent inadaptées si : le nombre de réseaux à connecter est important, la topologie du réseau change (ajout de nouveau sous réseau, de nouvelles liaisons,...), les routeurs sont éloignés géographiquement, plusieurs routes existent et la reconfiguration doit être automatique en cas de panne. Il faut que les équipements puissent échanger leurs informations de configurations pour qu ils construisent automatiquement leurs tables de routage et quelles restent à jour. Les routeurs peuvent aussi apprendre automatiquement la topologie du réseau en échangeant des tables de routage. Ce type de routage est dit dynamique. Les protocoles de configuration automatique bootp, DHCP ou ICMP router discovery,... ne doivent pas être confondus avec des protocoles de routage. Il ne permettent pas en cas de panne du routeur choisi de reconfigurer rapidement la station. Systèmes Autonomes L'Internet introduit la notion de système autonome ou AS (Autonomous System). L'ISO définit le concept similaire de Routing Systems. Dans un système autonome, les protocoles de routage sont relativement homogènes. Les systèmes autonomes, s'ils sont gérés par une même autorité administrative, peuvent être regroupés dans des domaines administratifs (Administrative Systems). Cette autorité est responsable de l'administration des adresses, de la facturation des coûts, de la sécurité et de l'organisation des domaines de routage. Il existe deux familles de protocoles de routage : 8

9 les protocoles internes (IGP : Interior Gateway Protocol) pour la gestion des routeurs à l'intérieur d'un domaine. Une de leurs principales caractéristiques est de trouver automatiquement les autres routeurs et de découvrir la topologie du réseau pour déterminer le chemin le plus adapté. Les routeurs, pour construire leurs tables de routage, doivent connaître l'état du réseau. Il faut que chaque équipement diffuse les informations le concernant. Mais la diffusion ne doit pas conduire à des boucles ou à des duplications de message. Il existe deux grandes familles de protocole. Les algorithmes basés sur le Distant Vector où chaque routeur n'a qu'une vision partielle du réseau, et les algorithmes basés sur les Etat des liaisons où chaque routeur construit une vision totale du réseau ; les protocoles extérieurs (EGP : Exterior Gateway Protocol) pour l'échange de données avec les autres domaines autonomes. Dans ce cas la topologie du réseau est connue. Les routeurs se connaissent. La principale difficulté provient de la grande quantité d'information (c'est-à-dire d'adresses de réseaux) à échanger entre les routeurs. Les routeurs peuvent mettre en place plusieurs algorithmes de routage. Une partie importante de leur travail consistera à apprendre les adresses des réseaux à partir d'un protocole de routage (IGP ou EGP) et à rediffuser tout ou partie de l'information vers les équipements adéquats. De la manière dont les routeurs vont traiter les informations va dépendre la route prise par les paquets sur le réseau. Les choix de routes ne sont plus uniquement techniques (par exemple, choix de la plus petite métrique, mais dépendent de plus en plus de critères politiques (par exemple, les trafics entre deux sites commerciaux ne doivent pas transiter par des réseaux subventionnés pour la recherche). 1.5 : Protocoles de routage internes (IGP) : L algorithme du Vecteur de Distance : Description L'algorithme du Vecteur de distance est basé sur l'échange d'informations entre routeurs adjacents. Deux routeurs sont adjacents s'il existe une liaison directe entre eux c'est à-dire s'ils ont un attachement sur le même réseau local. Chaque routeur ne connaît initialement que le coût de ses propres liaisons. Les routeurs diffusent vers les nœuds adjacents leur table de routage constituée de ses différents voisins accessibles et du coût de la liaison. Quand un routeur reçoit une nouvelle table, il effectue l'algorithme de Bellman Ford pour chaque entrée de la table reçue : si l'entrée n'est pas dans la table, il la rajoute ; si le coût de la route proposée par la table plus le coût de la route pour venir est plus petit que celui de la route stockée, la table de routage est modifiée pour prendre en compte cette nouvelle route ; sinon, il n'y a pas de changement. 9

10 La modification d'une entrée dans la table d'un routeur engendre l'émission de la nouvelle table vers tous les routeurs adjacents. Les échanges entre les routeurs continuent jusqu'à ce que l'algorithme converge. Cette diffusion, purement locale des informations de routage, permet d'éviter la formation de boucles sur le réseau. Construire une fois pour toutes les tables de routage n'est pas satisfaisant. L'état du réseau peut évoluer. Des routeurs peuvent tomber en panne ou des liaisons peuvent être coupées. Il faut que les tables de routage prennent en compte ces modifications. Des stations peuvent aussi arriver, il faut qu'elles puissent récupérer rapidement les informations concernant le routage. L'algorithme du Vecteur de distance résout ces problèmes en forçant les routeurs à diffuser périodiquement leurs tables de routage, même si aucune modification n'y a été apportée. Une station qui arrive sur le réseau peut ainsi récupérer la configuration. Un équipement détectera un problème quand il ne recevra pas pendant une période de temps fixée les informations d'un routeur adjacent. Il mettra à l'infini les les entrées correspondant à ce routeur dans sa table de routage et poursuivra l'algorithme du Vecteur de distance. Ce qui peut conduire à un changement total du routage des stations : Problème de convergence Pour aller Passer par Coût R1 Loc.1 1 R2 Loc.2 1 R3 B 2 R4 B 3 Pour aller Passer par Coût R1 A 2 R2 Loc.1 1 R3 Loc.2 1 R4 C 2 Pour aller Passer par Coût R1 B 3 R2 B 2 R3 Loc.1 1 R4 Loc.2 1 Figure 4. Dans l'exemple précédant si le routeur C tombe en panne, l'accès au réseau R4 devient impossible, B le détecte et met le coût pour la route vers R4 à l'infini. Mais le routeur A possède une route ayant un coût de 3 pour aller sur le réseau R4. B accepte cette route et met dans sa table qu'il faut passer par A pour atteindre R4 avec un coût de 4. Comme le coût a changé, la station A recalcule sa route, pour aller en C, il faudra passer par B et le coût sera 5,... Au fur et à mesure des itérations, le coût pour aller en R4 augmente, mais la convergence prend un temps infini. Une première solution consiste à "diminuer" la valeur de l'infini pour réduire le temps de convergence. Par exemple, dans l'algorithme de routage RIP, la valeur 16 indique que la station n'est pas accessible. 10

11 : L'horizon coupé Une solution complémentaire pour accélérer la convergence consiste à interdire à A d'envoyer une entrée de la table à un routeur quand la route passe par le réseau du destinataire. Dans l'exemple figure 1.5.2, A n'émettra pas vers B l'information qu'il peut atteindre R3 ou R4, car les routes passent par le réseau où est connecté B. On appelle cette technique "l'horizon coupé" (en anglais : split horizon). Malgré tout, la technique de l'horizon coupé ne résout pas tous les problèmes de convergence. En effet, elle limite les bouclages directs, mais n'empêche pas qu'une succession de routeurs produise les mêmes effets. Figure 5. Pour résoudre ce problème, il faudrait avoir une connaissance complète du réseau. Or les routeurs implémentant le Distant Vector, ne connaissent que leurs voisins immédiats : La retenue du chemin et les routes empoisonnées Le problème de convergence vient de l'existence d'une boucle dans le réseau. La technique de retenue du chemin va interdire à un routeur de prendre en compte les modifications sur une route qu'il a jugée inaccessible. Une fois la période transitoire passée, si l'un des routeurs de la boucle permettait effectivement de joindre cette destination, l'échange de table du Vecteur de distance permet de la réinsérer dans les tables de routage. 11

12 Figure 6. Si les boucles contiennent trop de routeurs la technique précédente peut s'avérer inefficace. L'algorithme des routes empoisonnées dit que le routeur ne doit pas prendre en considération des annonces où le nombre de routeurs pour atteindre une destination a crû de manière trop importante : RIP (rfc 1058) RIP (Routing Information Protocol) est un algorithme de type Vecteur de distance. Il est utilisé dès l'origine du réseau Internet et actuellement la plupart des vendeurs intègrent RIP à leur catalogue. RIP est conçu pour travailler sur des réseaux de petites tailles. RIP différencie les machines actives, c'est-à-dire les routeurs, qui émettent périodiquement les tables de routage et les machines passives, les stations, qui ne font qu'écouter les messages qui circulent sur le réseau. RIP utilise le protocole UDP pour transporter ses données. Le port 520 est réservé au protocole : Fonctionnement RIPv1 Le protocole RIP est formé par des "requêtes" (une requête est normalement émise par un routeur qui vient de redémarrer, afin d'obtenir de ses voisins la valeur initiale de la table de routage), et des "réponses" qui sont soit transmises réguliers chaque 30 secondes, soit pour transmettre des "mises à jour déclenchées. Le processus RIP, après la réception d'un message de "réponse, mettra à jour sa table de routage. Chaque entrée de la table contiendra au moins les informations suivantes: adresse de la destination, métrique associée à cette adresse, adresse du "prochain routeur, un indicateur de "mise à jour récente, plusieurs temporisations. 12

13 Lors du traitement de la réponse, le routeur en examinera une à une les entrées. Il devra faire des tests de validation, par exemple vérifier que l'adresse destination correspond bien à un des formats "A, "B, ou "C, que le numéro de réseau ne vaut ni 127 (boucle locale) ni 0 (sauf dans le cas de l'adresse par défaut ), que le numéro d'hôte n'est pas le code de "diffusion" et que la métrique n'est pas supérieure à l'infini. On ajoute ensuite 1 à la métrique reçue, sauf si elle est "infinie, afin de prendre en compte la liaison locale. On cherche ensuite si la destination était présente dans la table locale et on effectue les traitements normaux de l'algorithme "vecteur de distance. Nous rappelons qu'en régime stable, c'est à dire quand il n'y a pas de modification des tables de routage, chaque routeur émet périodiquement ses tables. La période est généralement de 30 secondes. En cas de changement dans les tables de routage, l'envoi des nouvelles tables n'est pas instantané. Ceci évite un très grand nombre de messages pendant les périodes d'initialisation ou de reconfiguration. Quand un routeur a émis une table, il doit attendre aléatoirement une durée comprise entre 1 et 5 secondes avant de réemettre une nouvelle table. Un envoi périodique est prioritaire et annule l'envoi de messages de reconfiguration bloqués sur cette attente. Le temps de convergence de l'algorithme est de l'ordre de plusieurs minutes. Un routeur décide qu'une route n'est plus valide quand il n'a pas reçu pendant une période de 180 secondes de tables d'un routeur. L'architecture Internet moderne distingue clairement les "hôtes, qui utilisent l Internet, des "routeurs" qui participent au routage. Les hôtes ne participent pas au routage et à l'acheminement des paquets IP : c'est là le travail des routeurs. En conséquence, les protocoles de routage comme RIP sont l'affaire des routeurs, et les hôtes ne devraient même pas en connaître l existence. Utiliser RIP dans un routeur implique toujours une "configuration" du protocole. Dans sa version la plus simple, le processus RIP doit obtenir une liste des interfaces locales, des adresses associées et des masques de sous réseaux. Mais l'opérateur local a beaucoup de raisons de ne pas vouloir laisser RIP diffuser des messages sur toutes les interfaces pour des raisons variées, par exemple : l envoie des messages toutes les 30 secondes serait un pur gaspillage ; ou bien on peut souhaiter interdire certaines destinations avec lesquelles on ne veut pas communiquer, les informations concernant ces destinations devront être ignorées dans les messages de réponse. Le processus RIP devra passer à la couche IP le résultat de ses calculs et devra obtenir des informations sur l'état des interfaces locales. En l'absence d'informations plus précises, l'absence de messages RIP conduira bien sûr à considérer les routes inaccessibles après un délai de 180 secondes. Mais c'est vraiment très lent, et aussi très imprécis. 13

14 : RIPv2 Cette version de RIP est plus récente puisqu'elle date de Janvier Malgré ses limitations, en particulier l'absence de netmask, RIP est resté un protocole très populaire. Il présente toujours des avantages par rapport à des protocoles plus performants mais aussi plus complexes à mettre en oeuvre. RIP-2 offre plus de fonctionnalités tout en restant entièrement compatible avec les anciennes versions de RIP. RIP-2 permet une authentification des messages de routage. En effet, un site mal intentionné peut modifier les tables de routage des routeurs pour : empêcher le réseau de fonctionner, modifier le chemin que prennent les messages pour pouvoir les écouter. Un paquet RIP-2 authentifié contient OxFFFF dans le champ identification de la famille d'adresse et doit être placé en premier dans le paquet. Le champ route tag contient le type d'authentification et les 4 champs suivants permettent d'avoir 16 octets contenant les paramètres d authentification. Pour l instant, le seul type standardisé est 2. Les paramètres contiennent un mot de passe en clair. Ce type d'authentification peut être facilement cassé : Amélioration apportée par RIP Version 2 Gestion de sous réseaux et super réseaux utilisation de Multicast IP ( ) au lieu de Broadcast IP Suppression de pics de transmission de messages : supprimer les synchronisations involontaires des émissions de messages : introduction de gestion aléatoire du déclenchement des émissions (14 à 45 secondes) : Problèmes résiduels importants Boucles, Métriques non appropriées aux réseaux modernes Pas de chemins multiples : Description de l'algorithme Etat des liaisons : L'algorithme du Distant Vector peut conduire à des boucles qui ralentissent sa convergence. La technique de l'horizon coupé permet d'en supprimer certaines en utilisant la connaissance de proximité qu'a chaque station du réseau Mais elle est rapidement mise en défaut en cachant la boucle derrière un autre routeur. Pour éviter les boucles, il faudrait que chaque routeur ait une vision complète de la topologie du réseau. L'algorithme Etat des liaisons permet d'obtenir cette connaissance.le déroulement de l'algorithme Etat des liaisons est le suivant : chaque routeur identifie ses voisins immédiats, un routeur principal et un de secours sont élus sur chaque réseau, le routeur acquiert la base de données du routeur désigné, chaque routeur construit un message contenant la liste de ses voisins immédiats ainsi que le coût associé à la liaison. Ce message sera appelé LSP pour Link State Packet, ce paquet est transmis à tous les autres routeurs du réseau avec un mécanisme de diffusion qui limite la propagation des messages et évite les boucles, 14

15 chaque routeur met à jour sa base de données, ce qui lui donne une vision globale du réseau et il peut en déduire ses tables de routage. L'algorithme de calcul de la route est dérivé de celui proposé par Dijkstra. L'algorithme utilise deux structures contenant la destination, le coût et le noeud de sortie. La première structure appelée PATH contient le chemin pour aller d'un routeur à un autre au meilleur coût. La seconde structure appelée TENT contient les tentatives de chemin qui n'ont pas encore montré l'offre d'un meilleur coût. L'algorithme se déroule de la manière suivante pour chaque routeur R. Dans la phase d initialisation, R est placé dans la structure PATH en tant que racine ; pour chaque routeur N contenu dans la structure PATH, examiner les données de la base décrivant l'état des liaisons (c'est à dire initialement les voisins immédiats) de N: pour chaque voisin M de N ajouter le coût de la liaison de la racine jusqu'à N au coût de la liaison de N à M, * si M n'est ni dans la structure PATH ni dans la structure TENT avec un meilleur coût, insérer M avec le coût calculé et la direction N dans TENT, si TENT est vide, l'algorithme est terminé, sinon prendre dans TENT l'entrée qui a le coût minimum, la mettre dans PATH et redérouler l'algorithme au début : OSPF (Open Shortest Path First) (rfc 1247) OSPF est un protocole de type Etat des liaisons destiné à remplacer les protocoles intérieurs propriétaires et RIP. OSPF utilise la fonctionnalité "type de service" offerte par IP - permet d'installer plusieurs routes pour une même destination, selon des critères différents (ex : délai court, débit important). - Si plusieurs routes vers une même destination sont de coûts équivalents, répartit la charge équitablement parmi ces routes. OSPF supporte l'adressage en sous réseaux (subnets); Découpage d'un système autonome en zones - isolement des informations de routage à l'intérieur de ces zones - limitation des informations de routage dans le système autonome. Des liens virtuels peuvent être établis dans la topologie de l'as afin de cacher les connexions physiques d'une partie du réseau. Les liens extérieurs avec d'autres systèmes autonomes (via EGP par exemple) sont pris en compte. Echanges entre routeurs authentifiés (l intégrité des messages). Le problème : dans les systèmes de routage, si le réseau est trop grand - overhead du trafic dans le réseau, - calculs trop longs, - dimensionnement mémoire trop grand 15

16 La solution : routage hiérarchique - découpage du réseau en parties indépendantes (Zones) - reliées par un BackBone (Area BackBone) Figure 7. La fonctionnalité chaque zone constitue un réseau indépendant, ce qui implique : le protocole d'inondation s'arrête aux frontières de la Zone et les routeurs ne calculent que des routes internes à la Zone certains routeurs (area border routers) appartiennent à plusieurs Zones et transmettent les informations récapitulatives des Zones qu'ils relient. OSPF est un protocole "à état des liaisons" dont la conception obéit à la théorie générale de ces protocoles : on y trouve une base de données distribuée, une procédure d inondation, la définition des voisinages, des enregistrements spécifiques pour les routes externes. Les protocoles à état des liaisons sont fondés sur la "distribution d'une carte" : tous les noeuds ont une copie régulièrement mise à jour de la carte du réseau. OSPF permet de : séparer "hôtes" et "routeurs, traiter les réseaux à diffusion tels que Ethernet ou FDDI, traiter les réseaux sans diffusion tels que X.25 ou ATM, découper les grands réseaux en zones : Séparer hôtes et routeurs : OSPF utilise les "sous réseaux" d'ip : comme tous les hôtes connectés au segment Ethernet appartiennent au même sous réseau, il suffit d'annoncer la liaison entre le routeur et ce sous réseau. Dans la terminologie OSPF, cela est une variante des "liaisons entre routeurs" appelée "liaison à un réseau terminal". La liaison vers un 16

17 routeur voisin est identifiée par l'adresse IP de ce voisin ; celle à un réseau terminal est identifiée par ses numéros de réseau et de sous réseau : Réseaux à diffusion : Les réseaux locaux utilisant des techniques de type Ethernet ou anneau à jeton offrent deux caractéristiques de service : une connectivité complète : toute station peut envoyer un paquet vers n'importe quelle autre, la possibilité de diffusion : une station peut envoyer un paquet qui atteindra toutes les autres stations (diffusion globale) ou toutes les stations appartenant à un groupe (transmission multipoint), : Réseaux sans diffusion: Ces réseaux présentent une différence importante par rapport aux réseaux à diffusion : ils fournissent une connectivité complète entre leurs clients, mais ne permettent ni "diffusion globale" ni "transmission multipoint. On les appelle donc dans la documentation OSPF, des "réseaux sans diffusion". OSPF gère de la même manière les réseaux "à diffusion" et "sans diffusion". Les routeurs élisent un "routeur désigné" et un "back up" ; les informations de routage ne seront échangées qu'avec ces deux routeurs. Avoir un routeur désigné n'a pas d'effet sur les routes elles-mêmes : on devra établir des circuits virtuels entre tous les routeurs pour y transmettre les paquets IP La différence principale entre réseaux "à diffusion" et "sans diffusion" est l'absence de transmissions multipoint : tous les paquets d'annonce devront être émis en "point à point. Les paquets "Hello" utilisés pour l'élection contiendront la liste de routeurs du réseau sans diffusion. Figure 8. Quand le routeur désigné "diffuse" une annonce, il doit envoyer une copie individuelle à chacun des autres routeurs ; quand un routeur ordinaire propage une annonce, il en envoie une copie au routeur désigné et une autre au back up. 17

18 : Découpage en zones: La taille de la base de données, la durée des calculs de route et le volume des messages augmentent avec la taille du réseau. Si le réseau est trop gros, tous ces facteurs deviennent excessifs : il faut trop de mémoire, les calculs durent trop longtemps, l'overhead de transmission devient insupportable. La réponse classique à ce problème est le "routage hiérarchique" que nous verrons dans ce qui suit : Routage hiérarchique : Contrairement à RIP, OSPF opère sur une hiérarchie. L'entité la plus large dans l'hiérarchie est le AS (Autonomous System). Un AS est une collection de réseaux sous une administration commune, partageant une stratégie commune de routage. OSPF est un protocole intra AS (interior gateway), bien que il est capable de recevoir des routes de et envoyer des routes à d'autres ASs. Un AS peut être divisé en un certain nombre de zones (areas). Une zone est un groupe de réseaux contigus et d'hôtes reliés.les routeurs avec des interfaces multiples peuvent participer dans des zones multiples.ces routeurs, nommés "routeurs interzones" (area border routers), maintiennent des bases de données topologiques séparés pour chaque zone. Une base de données topologique est essentiellement un schéma global de réseaux en relation avec des routeurs. La base de données topologique contient la collection de LSAs (Link State Advertisements) reçus de tous les routeurs de la même zone. Comme les routeurs de la même zone partagent la même information, ils ont des bases de données topologiques identiques. Une topologie de zone est invisible pour les entités en dehors de la zone. En laissant les zones topologiques séparées, OSPF laisse passer moins de trafic de routage que si les AS n'étaient pas divisés. Le routage intra zone apparaît quand la source et la destination sont dans la même zone ; le routage interzone apparaît quand elles sont dans des zones différentes. Un réseau fédérateur (backbone) OSPF est responsable de la distribution de l'information de routage entre les zones. RIP est un protocole prévu pour fonctionner sur des réseaux locaux à diffusion, OSPF a été conçu dans un cadre plus général où l'on peut trouver des réseaux à diffusion, des réseaux sans diffusion mais à accès multiples (NBMA: Non Broadcast Multiple Access) et des liaisons point à point.les protocoles d'ospf ne visent qu'à l'échange de tables entre routeurs. L'écoute passive par les stations des tables de routage, comme le permettent les algorithmes de type Vecteur de Distance,n'est pas prévue. 18

19 : Les sous protocoles : Le protocole Hello: vérifie que les liaisons sont opérationnelles permet l'élection du routeur désigné ainsi que le routeur back up établit une connexion bilatérale entre 2 routeurs Le protocole d'échange: consiste en l'échange des tables «Etat des liaisons» entre 2 routeurs activé si la connexion bilatérale a réussit initie les premiers échanges Fonctionne en Maître/Esclave Echanges avec acquittements Le protocole d'inondation: Activé lorsque l'état d'une liaison change et que cet état était préalablement enregistré Peut aussi être activé sur demande d'état après connexion bilatérale protocole avec acquittement Pour chaque annonce - si nouvelle valeur : l annonce est réémise sur tous les interfaces - Acquittement vers l'émetteur initial : Avantage des protocoles à état de liaisons La plupart des experts en réseau préfèrent les protocoles à "état des liaisons" aux protocoles à "vecteur de distance. Il y a plusieurs raisons à ceci : convergence rapide sans boucle, possibilités de chemins multiples, métriques précises et couvrant plusieurs besoins, traitement séparé des routes externes. chaque passerelle calcule ses routes indépendamment des autres. En conclusion, les algorithmes à état de liaisons sont mieux adaptés au facteur d'échelle que les algorithmes Vecteur Distance. 19

20 1.6 : Protocoles de routage externes : Le protocole EGP Le protocole EGP (Exterior Gateway Protocol) est l'un des premiers protocoles de routage externe qui ait été utilisé dans l'internet. Le but d'egp n'est pas de trouver les routes ayant la meilleure métrique puisque EGP est construit pour fonctionner sur une architecture fortement hiérarchique comme l'était l'internet à ses débuts. Le réseau Internet a beaucoup évolué depuis et EGP n'est plus adapté à la nouvelle topologie et aux nouveaux besoins. Par contre, dans certaines parties du réseau le protocole peut encore être utilisé, puisqu'il est relativement simple. EGP permet d'annoncer des routes (c'est-à-dire les réseaux) qui sont accessibles. Le routage dans les systèmes autonomes est relativement simple. Une route par défaut permet d'atteindre le réseau d'interconnexion. Par contre, ce dernier doit construire les routes pour atteindre le bon système autonome. Le protocole d'egp se déroule en trois étapes par échange de messages dont le type sera donné dans les paragraphes suivants : la première consiste à se mettre d'accord avec un routeur voisin pour échanger des informations de routage ; la seconde consiste à vérifier périodiquement que le routeur voisin est toujours accessible. Le routeur émettra des messages Hello qui seront acquittés par des messages I-H-U (I Hear You, je vous entends) ; la troisième consiste à échanger les informations de routage, c'est-à-dire la liste des réseaux que le routeur connaît et qu'il peut joindre : Les messages EGP Les messages EGP sont directement encapsulés dans des paquets IP dont le numéro de protocole est 8. Il existe 3 types de message : : Acquisition d un voisin La procédure d'acquisition est très simple. Un routeur qui souhaite échanger des informations de routage avec un autre routeur envoie un message de demande d'acquisition. Le routeur distant retourne une confirmation ou un refus. Ceci dépend de la configuration du routeur puisque la liste des routeurs avec lesquels il est susceptible de dialoguer doit être explicitement donnée par l'administrateur du réseau. Ce type de message peut aussi servir lorsqu'un routeur est arrêté proprement pour avertir les voisins. Le protocole IP n'étant pas fiable si, au bout de 30 secondes, aucune réponse n'est parvenue la requête est reformulée : Accessibilité des routeurs Ces messages sont émis périodiquement pour détecter tout problème qui pourrait exister entre les deux routeurs voisins comme par exemple la rupture d'un lien ou l'arrêt brusque de la machine. Le protocole IP n'étant pas fiable, il ne faut pas qu'un routeur déduise de l'absence de réponse, la panne de l'autre équipement. Une liaison sera dite basse si pendant une période de temps fixe le nombre de message acquittés passe en dessous d'une borne j et haute si au contraire le nombre de paquets acquittés dépasse une borne k. 20

21 : Accessibilité des routes Périodiquement le routeur demande à son voisin de lui fournir la liste des réseaux qu'il sait atteindre. Ce message de type 2 contient le numéro du réseau commun aux deux routeurs. Ce numéro peut être sur 1,2 ou 3 octets suivant que l'adresse est une classe A, B ou C.Le routeur répond en transmettant la liste des réseaux qu'il connaît dans un message EGP dont le champ type vaut : Limitations d'egp : Notions de classes Le format des adresses de réseau est fortement lié à la notion de classe. Ces champs peuvent faire 1,2 ou 3 octets alors qu'avec l'attribution d'adresses sans classes (CIDR), il faudrait pouvoir indiquer au bit près la longueur de l adresse : Distances non significatives Le champ distance ne peut pas être considéré comme une métrique. Il n'est ni interprété, ni modifié par EGP. La valeur mise dans ce champ est propre au système autonome qui fait l'annonce. Sur la figure 9, les systèmes AS1 et AS2 ont une liaison privée qui leur permet de communiquer sans passer par le réseau fédérateur de l'internet. Ce type de liaison est appelé "en coulisse" (backdoor link). L'annonce des réseaux du système AS1 par le routeur 5 se fera avec une métrique plus importante que celle faite par le routeur 1. Quand le réseau Internet recevra des paquets pour un réseau du système autonome AS1, il les dirigera vers le routeur 2. Par contre si en cas de panne le routeur 2 devient inaccessible au routeur 3, seule la route passant (et annoncée) par le routeur 5 sera prise en compte. Figure 9. 21

22 : Hiérarchie sur deux niveaux : Sur la figure 10, si au lieu d'être seulement un système autonome, l'as2 est aussi un réseau fédérateur appartenant à un opérateur privé et le réseau Internet, (un réseau subventionné pour la recherche ). Le système autonome AS1 ne peut plus privilégier une des deux routes. Il va donc annoncer via les routeurs 1 et 2 les mêmes distances.les deux réseaux fédérateurs ne pourront pas distinguer quel est le meilleur chemin pour atteindre le système autonome AS1 puisque tous les deux offriront la même distance. Si l'as2 a des données à transmettre à l'as1, il risquera de les faire transiter par le réseau subventionné. Le risque est même plus grand. Les tables de routage du réseau subventionné peuvent renvoyer l'information vers l'as2. Le paquet n'arrivera jamais à destination : BORDER GATEWAY PROTOCOL (BGP) Figure : Introduction La croissance de l'internet rendit les limitations d'egp inacceptables : beaucoup d'utilisateurs souhaitaient rompre la topologie "en étoile'" qu'egp imposait. Cela conduisit à standardiser le "protocole de gateway frontière BGP", développé par le groupe de travail correspondant de l'ietf. BGP repose sur TCP et utilise le numéro de port 179, support l'adressage "sans classes" (CIDR). BGP est un exterior gateway protocol (EGP), ce qui signifie qu'il performe le routage entre des systèmes autonomes multiples ou domaines et fait l'échange du routage et d'information avec d'autres systèmes BGP. BGP a été développé pour remplacer son prédécesseur, le protocole EGP. Il résout des sérieux problèmes et contribue de plus en plus au développement de l'internet. 22

23 : Le concept des vecteurs de chemins: BGP est un protocole qui permet de mieux prendre en compte la complexité du routage dans le réseau Internet. Comme pour tout protocole de routage, BGP maintient des tables de routage, transmet des 'mises à jour', et des décisions de routage sur les métriques. Il y a beaucoup de différences entre BGP et EGP, mais l'innovation la plus importante de BGP est probablement le concept de "vecteurs de chemins" qui permet la prévention des boucles dans une topologie complexe. Les concepteurs de BGP devaient développer un successeur à EGP qui permet de gérer des topologies arbitraires. C'était un problème difficile. Les protocoles de type "vecteurs de distance" s'accordaient bien avec la conception classique du routage "relais par relais" mais n'offraient pas assez de protection contre les boucles. L'approche "état des liaisons", cependant paraissait irréaliste car on doit diffuser une base de données d'état des liaisons représentant l'internet global. BGP résolue le problème en inventant une nouvelle technologie, dite "des vecteurs de chemins". Dans un protocole à vecteurs de distances classique, toute l'information décrivant une destination est concentrée dans la "métrique". Cela ne suffit pas si on veut détecter rapidement les boucles. D'où l'approche implémentée par BGP: Chaque mise à jour de routage transporte la liste complète des réseaux de transit, ou plus précisément des systèmes autonomes traversés par le chemin.une boucle ne peut survenir que si un AS est listé deux fois, ce qui serait une erreur. L'algorithme de protection contre les boucles est donc très simple. Chaque fois qu'il reçoit l'annonce d'une route, le routeur externe vérifie que son propre AS n'est pas déjà traversé par le chemin. Si c'est le cas, il refusera d'utiliser ce chemin. Sinon, il ajoutera l'identification du domaine local dans la liste avant de propager ce chemin. Cette approche a le gros avantage de ne pas obliger l'ensemble des relais à utiliser la même métrique, ce qui serait problématique étant donné leurs intérêts différents et leur autonomie de décision.ils peuvent au contraire faire n'importe quel choix : il suffit qu'ils consignent précisément le résultat de ce choix dans le "vecteur de chemins" pour qu'on soit sûr d'éviter les boucles. BGP gère les chemins entre les systèmes autonomes. Ces chemins sont décrits par des listes d'attributs, dont les plus importants sont la "liste des AS traversés" et la "liste des réseaux accessibles". Quand plusieurs chemins sont disponibles, l'addition d'attributs supplémentaires permet aux routeurs externes de choisir "le meilleur chemin". 23

24 : comparaison entre EGP et BGP EGP Utilise IP. Best effort. les commandes d'egp doivent être répétées si la réponse ne revient pas dans un certain intervalle : il faut donc gérer une temporisation dans le programme EGP lui-même =>plus complexe a régler. Fragmentation IP => retransmettre les messages complets en cas de pertes EGP peut garder une trace précise des erreurs de transmission, et donc décider de considérer qu'une liaison est "hors service" si trop de "hellos" restent sans réponses. EGP impose que les routeurs transmettent des messages d'accessibilité complets toutes les deux minutes. BGP Utilise TCP. Transfert fiable. Pas besoin d un temporisateur car on u TCP. Pas besoin de fragmenter. TCP ne pourra signaler une erreur que si on essaye d'envoyer des données sur la connexion et si ces données ne sont pas acquittées après un long délai, après plusieu essais de retransmission. BGP demande seulement qu'ont retransmet la fraction de l'information qui a changé. Après une phase initiale pendant laquelle on échange des tables complètes : Trois types de routage pour BGP BGP performe trois types de routage : interautonomous System routing, intra-autonomous System routing, et passthrough autonomous System routing Interautonomous System routing Interautonomous system routing apparaît entre deux ou plusieurs routeurs BGP dans différents systèmes autonomes. Les routeurs voisins dans ces systèmes utilisent BGP pour maintenir une vue consistante de la topologie de l'internet. Les BGP voisins communiquant entre des systèmes autonomes doivent résider sur le même réseau physique : Intra-autonomous system routing Intra-autonomous system routing apparaît entre deux ou plusieurs routeurs BGP localisés dans le même système autonome. Les routeurs voisins dans le même système autonome utilisent BGP pour maintenir une vue consistante de la topologie du système. BGP est aussi utilisé pour déterminer quel routeur servira comme un point de connexion pour des 'external autonomous Systems' spécifiques. Le protocole BGP peut assurer des services de routage 'inter et intraautonomous system' à la fois : Pass-through autonomous system routing Pass-through autonomous system routing apparaît entre deux ou plusieurs routeurs voisins BGP qui s'échangent du trafic le long d'un système autonome qui n'utilise pas BGP. 24

25 Dans un environnement 'pass-through autonomous system', l'origine du trafic BGP n'est pas dans le système autonome, en plus le trafic BGP n'est pas destiné pour un noeud dans le système autonome.bgp doit interagir avec n'importe quel 'intra-autonomous system routing protocol' utilisé pour transporter comme il faut le trafic BGP à travers ce système autonome :Politique de routage Un routeur ne gardera qu une seule route vers une destination. La décision de garder ou de rejeter une annonce de route se fera sur les attributs et sur les paramètres locaux. Ce choix sera propagé vers les autres routeurs. 1.7 : Limite du routage dans l'internet : 1-Le champ adresse de la source du paquet ( ou de système autonome d'origine) ne peut être pris qu'au moment de la construction des tables de routage. Tous les paquets,quelle que soit leur origine, entrant dans un système autonome seront traités de la même manière. 2- Si la capacité d un réseau en terme de bande passante est inférieure à la demande de transmission, le taux de perte augmente rapidement dans un réseau. Une solution pour limiter ce taux de perte est donc de limiter la demande de transmission en instaurant en entrée du réseau un contrôle d'admission. Cette approche est utilisée dans le réseau téléphonique et ATM. Il est relativement difficile de la mettre en œuvre dans l'internet, car celui-ci est structuré en systèmes autonomes bénéficiant d'une autonomie de gestion. L'échange d'information entre systèmes autonomes ne porte que sur des informations de routages. 3- les flux ayant des contraintes du trafic ne sont pas protéges des trafics Best Effort dans les routeurs pour obtenir des garanties de débit, de délai et de taux de perte. Cette approche nécessite de réserver des ressources dans le réseau pour ces flux. 4-difficulter d ajouter des application ou des nouveau services (exemple : signalisation pour assurer la QoS,ou bien un routage multicast fiable ou bien des application de multimédia ) ou un nouveau protocole a un équipement de réseau ou au réseau lui-même sans changer tous les softwares se trouvant sur tous les équipements du réseau=> Le déploiement et le développement de nouveaux services réseau est très lent par rapport a la demande de nouveau application et service. 5-Le routage IP n a pas de l intelligence,tout ce qu il fait est de router vers une de ces interfaces un paquet IP suivant l adresse destination sans regarder se qu il y a dedans ce dernier. 25

26 2. Les Réseaux actifs 2.1 : Introduction L'acceptation large de l'ip est provenue de sa capacité de fournir l'accès à des bas prix indépendamment des technologies fondamentales de gestion de réseau. Toutefois le développement et le déploiement des nouveaux services de réseau, c.a.d les services qui opèrent sur la couche d'ip, est trop lent, et ne peut égaler les changements rapides des diverses applications qui se développent. Les exemples de tels services sont : la signalisation pour la qualité du service (QoS), du multicast fiable Semblable à l'architecture intelligente de réseau dans le monde de PSTN, l'architecture courante d'internet doit être améliorée afin de tenir compte d'une introduction et d'une programmabilité plus rapides de tels services. La communauté d'internet a réalisé le besoin d un changement, et avait satisfait ces besoins sur une base de problème centrale au lieu de traiter le problème structuralement. Par exemple, diverses approches de différenciation de service ont appliqué l'idée de la gestion de file d'attente active dans les routeurs, ayant pour résultat les algorithmes tels que le RED et les FRED, etc. Les réseaux intelligents ont était introduits comme solution architecturale pour le déploiement rapide et flexible de nouveaux services de réseau. L'idée fondamentale des réseaux actifs est de permettre aux tiers (utilisateurs, opérateurs, et fournisseurs de service) d'injecter des services spécifiques a l'application (sous forme de code) dans les réseaux. Les applications peuvent ainsi utiliser ces services pour obtenir leurs besoins en termes de ressources de réseau et de gestion de réseau. Les réseaux actifs permettent l'injection dynamique du code. Mais cette injection peut seulement être acceptable par des fournisseurs de réseau si elle ne compromet pas l'intégrité, la performance et /ou la sécurité des réseaux. Par conséquent les architectures des réseaux actifs doivent être soigneusement crées pour être a la foi flexible, performant et sécuriser. La programmation, une condition fondamentale des réseaux actifs, signifie qu'un utilisateur peut commander dynamiquement le réseau pour traiter des paquets d'une manière déterminer, plutôt que mode fixe, par exemple, par sélection/implémentation d un algorithme de routage. Les réseaux actifs implémentent des mécanismes de distribution de code et d'exécution de code, de sorte que l'injection du code programmé par des utilisateurs puisse imposer la commande des réseaux. Différentes propositions on étaient présentées pour l architectures des réseaux actifs (Switchware PLANet, ALIEN, ANTS, ) : Composant d un réseau actif Pour réaliser un prototype d architecture de réseaux actifs, la structure des réseaux actuels doit être fondamentalement modifié. La Figure 1 montre les différents composants généralement présents. Trois d entre eux sont remarquables. Premièrement, les paquets différent de leurs cousins des réseaux traditionnels, car ils ne sont plus composes uniquement de données, mais également d un programme qui permet de les traiter. Deuxièmement, il n y a plus de différences entre la périphérie du réseau et son cœur (stations terminales et routeurs), toutes ces infrastructures sont appeles nœuds actifs. Leurs fonctions sont bien plus évolues que celles des routeurs traditionnels, car ils doivent pouvoir interpréter des programmes, être extensibles et bien sur savoir gérer le réseau. Troisièmement, une (ou plusieurs) machine virtuelle doit être présente sur chaque nœuds pour pouvoir exécuter le code contenu dans les paquets. Le langage qu elle interprète doit être pourvu de propriétés particulières, afin d assurer un comportement correct des paquets. Mais, cette contrainte implique l existence d un compromis entre flexibilité et surete dans la sémantique du langage. 26

27 Figure 1 : Les composantes d un réseau actif : Les paquets Les paquets actifs, encore appelés capsules dans certaines architectures, sont différents des paquets de données traditionnels- En effet, ils contiennent du code qui doit être encapsulé d'une manière ou d'une autre. Quelle structure doit on donner au paquet, de manière à y encapsuler le code? Cette question est importante, parce que, pour des raisons de performance, l'encapsulation et la décapsulation doivent se faire très rapidement afin de ne pas saturer les noeuds. En effet, si ce processus est trop long, alors pendant le temps que prends la mise en paquet, les files d'attentes du noeud se remplissent. Parallèlement, la structure du paquet soit spécifier comment se fait la séparation code donnée. En fait, cela dépend du langage choisi pour l'architecture ainsi que du modèle d'exécution. En général, le code est transporté sous forme de syntaxe abstraite, ou directement de byte codes. Parfois, une séparation nette est faite : le code est contenu dans un champ du paquet prévu à cet effet, et les données dans un autre. D'autre fois, le paquet contient un objet sérialisé et englobe son état et donc ses données. D'autre part, pour des raisons de performances, la taille des paquets doit être réduite. En effet, si le code est trop grand, et ne rentre pas dans un paquet IP, des problèmes de fragmentation peuvent apparaître. Cela est très gênant, parce qu'il faut attendre l'arrivée de tous les paquets avant d'opérer à un rassemblement, avant d'évaluer le code. De plus, cela ne correspond plus à la philosophie d'une approche intégrée, dans laquelle chaque paquet est autosuffisant, dans la mesure où il contient son programme et ses données. 27

28 : Les nœuds Les noeuds sont le moteur des réseaux actifs. En particulier, ils doivent assurer deux tâches primordiales, d'une part l'intégrité du système, d'une autre, sa flexibilité. Le chemin d'exécution Tout comme dans les réseaux classiques, les noeuds doivent savoir injecter des paquets, en recevoir, démultiplexer des flux, etc. Dans un premier temps,les couches traditionnelles de bas niveaux (physiques et liaisons) sont utilisées pour des raisons de facilités d'implémentation. Lorsqu'un paquet actif arrive sur un noeud, le système doit être capable de le reconnaître afin de le transmettre au handler approprié. Le rôle de ce handler est d'inspecter le champ Type ID, de manière à vérifier s'il doit être exécuté sur ce noeud ou non. Si c'est le cas, le paquet est passé à l'interpréteur, sinon il est routé classiquement. Le plus souvent, l'évaluation consiste à dé sérialiser le paquet dans une structure de données comprise de la machine virtuelle. Pendant l'interprétation, le code peut faire appel à des services, parfois sauver des états, faire des calculs et évidement re-router le paquet. Le noeud suivant est alors déterminé et le paquet est reconstruit pour être envoyé sur l'interface réseau appropriée. Besoin de services dynamiques Pour assurer une certaine flexibilité, le noeud doit également être capable d'intégrer de nouveaux services qui n'étaient pas prévus initialement. En effet,seule une petite catégorie d'applications à besoin de primitives complexes. Ainsi l'utilisation d'authentification, de cryptographie ou encore de compression de données n'est pas nécessaire à l'ensemble des protocoles. Aussi, intégrer ces primitives dans toutes les machines virtuelles, sur tous les noeuds serait lourd et peu évolutif. Dans un souci de flexibilité, les environnements d'exécutions ne doivent pas être figés. En effet, les besoins des applications de demain n'étant pas connues aujourd'hui, il est fortement probable que, un jour, de nouvelles primitives leurs soient nécessaires. Ainsi, pour ne pas tomber sur les problèmes de manque de souplesse qu'ont les réseaux actuels, les noeuds des réseaux actifs doivent intégrer un système de chargement dynamique de nouveaux services. De plus, l'interpréteur présent sur le noeud doit être en mesure d'identifier les services présents afin de pouvoir y faire appel lorsque le code d'un paquet le demande. 28

29 2.2 : Modèle de réseau programmable Modèle de Computation Modèle Communication de Couche application Couche Transport Couche Reseau Transport Control Gestion Couche Lien Figure 0 : Modèle de réseau programmable Toutes Les applications utilisées dans le monde Internet peuvent être classifiées en trois catégories : Application de transport comme IP, qui permet au paquet de transporter des donnés vers la destination. Application de control comme RSVP, qui contrôle la réservation de ressource pour assurer une qualité de service. Application de gestion des réseaux comme SNMP, qui permet de contrôler les équipements du réseau. D où le modèle des réseaux programmable (Fig. 1), qui incorpore d une part 3 plans, représentant les différentes applications et d une autre part introduise un nouveau modèle de computation qui fourni un support programmable à travers les plans transport, control et gestion, qui permet de programmer les différentes couches (application, transport, réseau et lien) dans ces plans. 2.3 : Avantages des réseaux actifs Diminution du temps de création de nouveau service. Permet à l utilisateur de créer des services adaptés à des applications spécifiques. offrir au centre de recherche une plateforme réseau programmable dynamiquement pour créer des nouveaux services sans perturber le fonctionnement du réseau : Avantage par rapport aux applications Dans ce paragraphe on va présenter comment les réseaux actifs peuvent être utilisés pour améliorer la performance et l efficacité de certaine application. 29

30 : Application de gestion de réseau Les stations de gestion des réseaux traitent les anomalies du réseau en les cherchant dans les données transmises par les équipements réseau. Mais avec le nombre et la complexité des nœuds qui augmente, les stations de gestion se trouvent avec des quantités énormes de données a traité. Et par suite le traitement des anomalies va prendre un certain temps avant d agir, ce qui peut être gênant en cas de congestion. Ce problème est résolu dans le cas des réseaux actifs, car les stations de gestion sont placées au centre du réseau grâce au nœud actif,ce qui diminue le délai de réponse des stations et la bande passante qui était utilisée pour demander périodiquement les informations des équipements du réseau.on pourra aussi injecter des codes spéciales dans des paquets actifs qui peuvent traiter plusieurs problèmes,au moment ou elles se produisent, au niveau des nœuds.autres paquets peuvent surveiller continuellement le réseau pour trouver et traiter des anomalies. En résume l avantage des réseaux actifs pour les applications de gestion: Les anomalies sont reportées rapidement et automatiquement. Les stations de gestion se trouvent au centre du réseau ce qui diminue le délai de réponse des stations et la bande passante utilisée. Les paquets de surveillance peuvent directement détecter et traiter les problèmes du réseau. Les protocoles de gestion peuvent être facilement modifiés par l administrateur grâce à la flexibilité des réseaux actifs : Contrôle de congestion Les applications de contrôle de congestion peuvent être considères comme un cas particulier des applications de gestion de réseau. Actuellement le problème de ces applications est le temps que prend la notification de congestion pour atteindre la source, ce qui augmente la congestion car pendant ce temps la source continu a émettre. Les avantages des réseaux actifs pour le contrôle de congestion sont : Un nœud actif peut surveiller la bande passante disponible et contrôler par suite le flux de donnée à transmettre. le rejet sélectif des paquets doit être plus important pour les paquets moins prioritaires : Le multicast L Internet et les nouvelles générations de réseau doivent prendre en considération le nombre d application multimédia comme audio, vidéo, téléconférence qui nécessitent du multicast. Avec les réseaux actifs plusieurs problèmes du multicast sont résolus comme la transmission énormes d acquittements négatifs en cas d erreur de transmission vers la source. ARM (Active reliable multicast) pour multicast fiable et actif, a était développé par MIT pour résoudre les problème du multicast en utilisant trois stratégies de contrôle d erreur : Le routeur actif se trouvant dans des milieu stratégique du réseau (par exemple : bordure d un réseau) doit mémoriser les données multicast pour pouvoir les retransmettre en cas d erreur.ce qui diminue le trafic et le délai de retransmission. Les acquittements négatifs inutiles doivent être supprimés par le routeur. Dans le cas d un paquet de retransmission,le routeur actif vérifie le registre des acquittements négatives.s il y a une indication du nœud de sortie qui a demandé la retransmission,le paquet est transmis seulement vers ce nœud.si non il est transmis vers tous les nœuds. 30

31 : Caching Une grande partie du trafic Internet provienne des applications Web comme le World Wide Web, ou les informations sont récupérées,par le client, d un serveur se trouvant dans le réseau. La (caching) mémorisation des informations dans des routeurs se trouvant près du client va diminuer le trafic et le temps nécessaire pour recevoir les informations. Avec les réseaux actifs les nœuds intelligents peuvent décider de mémoriser les objets, dont un client tout proche pourra les demander dans le future.les nœuds adjacentes communique entre eux pour ne pas mémoriser les mêmes objets. 2.4 : Sécurité dans les réseaux actifs Les réseaux actifs sont plus flexibles par rapport aux réseaux passifs,ce qui augmente le problème de sécurité. Les paquets actifs contiennent des codes exécutables qui peuvent changer l état d un nœud.les nœuds deviennent des ressources publiques. Par suite la sécurité au niveau computation, ou les codes des paquets sont exécutés, doit être très stricte. Dans le monde actuelle d Internet, le problème de control strict de ressource au niveau d un nœud n est pas nécessaire,car un paquet ne consomme qu une petite mémoire temporelle utilisée pour le stocker. Mais avec les paquets actifs le problème de réservation de ressources et plus important,car un paquet actif peut consommer beaucoup plus les ressources et plus rapidement, ce qui provoque la saturation d un nœud. Dans les réseaux actifs,les paquets actifs peuvent abuser les nœuds actifs,les ressources du réseau et même autres paquets actifs. D une autre part les nœuds actifs peuvent aussi abuser les paquets actifs. Plusieurs problèmes peuvent se produire : Dégâts : un paquet actif peut détruire ou bien changer les ressources ou bien les services d un nœud en les reconfigurant, modifiant ou même les effaçant.un nœud actif peut effacer un paquet actif. Enfin un paquet actif peut attaquer autres paquets actifs. Un paquet actif peut surcharger un service ou les ressources en consommant la capacité CPU du nœud, ce qui sature ce dernier et un nouveau paquet ne pourra plus être exécuté. Un paquet actif peut avoir accès a des informations privées d un nœud.un nœud actif peut modifier le contenue d un paquet. Un utilisateur peut envoyer un grand nombre de paquet actif vers un routeur pour le bloquer en consommant toute sa capacité en ressource. La protection des paquets et des nœuds actifs dans un environnement flexible comme les réseaux actifs est un problème très difficile à résoudre. Voici quelques techniques de protection des nœuds actifs : Authentification des paquets actifs : chaque paquet doit avoir une authentification produite par des algorithmes de signature a clé public. Surveillance et contrôle : un surveillant consulte la politique de sécurité pour déterminer le droit d accès pour chaque paquet. Les deux premières techniques ne garantissent pas que le paquet ne fera pas de dégât après son exécution. Pour cela on a besoin d une technique de limitation de ressource :Les limites peuvent être le temps maximal d exécution permis a un paquet ou bien le nombre maximal de nœud que peut traverser un paquet (avec ses descendant). 31

32 Le créateur d un programme doit accompagne ce dernier avec un certificat (que le programme est correcte) dans le paquet actif. Pour la protection des paquets actifs deux méthodes se présentent : Cryptage : Les paquets actifs sont cryptés avant d être transmises. Les programmes peuvent être exécuté sans être décrypté. Tolérance aux erreurs : cette technique est composée de la : Reproduction : chaque paquet est reproduit à chaque nœud. Persistance : les paquets sont temporellement mémorisés, en cas de panne d un nœud le paquet n est pas perdu. Redirection : Un paquet pourra changer sa route en cas de coupure de lien. La reproduction et la persistance ne sont pas adaptées à la majorité des réseaux car ils consomment beaucoup de mémoire et de bande passante. La redirection et le cryptage consomme de la puissance CPU.La combinaison du cryptage et de la tolérance aux erreurs pourra être une solution au problème de sécurité des paquets actifs : Sécurité du point de vue programmation Nous avons vue le problème de sécurité du point de vue système.mais la sécurité des programme peut résoudre plusieurs problème des réseaux actifs. Par exemple une bonne conception d un programme pour les réseaux actifs peut éliminer le temps nécessaire pour tester le programme avant l exécuter. Le rôle d un langage de programmation est de fournir la sécurité et l intégrité sans que la performance soit compromise.la vitesse d exécution d un paquet dépende du langage de programmation ce qui améliore la performance. Les problèmes, avec leurs solutions, qui peuvent se présenter en cas d utilisation d un langage de programmation mal choisie sont : Le langage C est un faible langage de programmation, du point de vue traitement de la mémoire ; solution : utilisé un langage de programmation fort comme Java. Allocation d une large quantité de mémoire ; solution : maître des limites pour l utilisation de la mémoire. Le temps nécessaire pour tester les programmes diminue les performances ; solution : l utilisation d un langage de programmation simple et robuste et bien construit peut éliminer la nécessité de tester un programme avant son exécution. Le temps nécessaire pour exécuter un programme affecte aussi les performances. 2.5 : Les différentes architectures Dans ce paragraphe on va décrire quelques architectures de réseau actif. Ces architectures sont groupées suivant leur méthode de fonctionnement pour réaliser un réseau actif.trois type d architecture existe : Architecture paquet actif qui contient des codes a exécuté. Architecture nœud actif qui contient les codes exécutables, dans ce cas les paquets contiennent seulement un identificateur de code qui doit être exécuté sur le nœud. La dernière architecture donne un choix à l utilisateur entre les deux premières architectures. 32

33 2.5.1 : Architecture Paquet Actif Dans cette architecture les codes sont transportés par les paquets.les nœuds sont aussi actif,car ils peuvent exécuter les codes actifs,mais ils ne contiennent pas des codes actifs.les codes transporter par les paquets actifs sont soit exécuter sur les donnés se trouvant dans ce dernier soit utiliser pour changer l état ou le comportement d un nœud.différentes architectures existe,comme le Smart packets proposer par BBN technologies,the active IP option proposer par MIT et l architecture M0 proposer par l university of california : Architecture Nœud Actif Dans cette architecture les paquets transportent a la place des codes actifs, des identificateurs ou des références de fonction prédéfinie dans les nœuds actifs.les paquets sont actifs dans le sens quels décident quelles fonctions doit utiliser les nœuds pour traiter leurs données et quels fournissent les paramètres nécessaire pour le fonctionnement de ces fonctions.les nœuds actifs dans cette architecture contiennent les codes.cette architecture résolue le désavantage de l architecture précédente qui était le problème de performance puisque les exigences de sécurité étaient très importantes.plusieurs architectures ont étaient présentées comme : DAN architecture proposer par Washington University et par ETH Zurich, l architecture ANTS proposer par MIT et l architecture An Architecture for Active Networks proposer par Georgia Institute of Technology : L architecture ANTS Un réseau basé sur l architecture ANTS est un group de nœud interconnecté qui utilise des routines ANTS nécessaire pour pouvoir router les capsules. Des nouveaux protocoles peuvent être automatiquement installés sur les nœuds intermédiaires en utilisant la technique des codes mobiles.lors de la conception de cette architecture trois but on était présenté pour rendre le réseau plus flexible : Les nœuds d un réseau doivent supporter simultanément plusieurs protocoles réseau qui pressentent différents services. L architecture doit supporter la construction de nouveaux protocoles par l accord mutuelle entre les équipements réseau intéresser, sans passer par une standarisation. Les utilisateurs ne peuvent pas créer eux même des nouveaux protocoles mais peuvent choisir parmi différents protocoles offerts par un vendeur de software. L architecture doit supporter le déploiement dynamique de nouveaux protocoles, car ce n est pas logique d arrêter une partie du réseau pour faire configurer un nœud pour qu il supporte un nouveau protocole. L architecture ANTS a utilisé trois composantes pour satisfaire ces buts : La capsule : remplace le paquets traditionnel.ces capsules contiennent des références de routine de routage utiliser, par chaque nœud, pour arriver a sa destination. Le routeur a était remplacé par un nœud actif qui exécute les routines demander par les capsules. Un mécanisme de distribution de code assure la transmission automatique et dynamique de routine vers des nœuds qui ont besoin de cette routine : Les protocoles Dans L architecture ANTS, Les routines de routage sont regroupées dans un nœud par des différentes protocoles qui définissent le comportement de ces routines dans tout le réseau.ce regroupement est appliqué en tenant compte de trois niveaux d architecture comme le montre la figure 2. 33

34 La capsule : comme on a déjà dit, elle remplace le paquet traditionnel. Elle contient une référence indiquant la routine de routage a utilisé sur chaque nœud. Le Groupe de code : est une collection de capsule ayant le même type et dont leur routine de routage est transférée en unité par le système de distribution de code. Un protocole est une collection de groupes de code, qui sont traités comme une seule unité de protection dans les nœuds actifs. Les capsules appartenant au même protocole partagent les mêmes informations dans le réseau : Les capsules Figure 2 : Hiérarchie des composants d un protocole Le format d une capsule est présenté dans la figure 3.Chaque capsule contienne un identificateur de protocole et un identificateur particulier de capsules dans ce protocole.le champ entête partager contient un champ commun pour toutes les capsules, le reste de l entête dépende du type de la capsule qui peut changer lors de son passages dans les différentes nœuds du réseau. La partie importante de cette entête est les adresses source et destination et les informations sur les limites de ressource applicable sur les nœuds : les nœuds actifs Figure 3 : Format d une capsule. La difficulté principale dans la conception d un réseau programmable est de permettre aux nœuds d exécuter des programmes prédéfinis par l utilisateur. L approche utilisée par ANTS est d exécutée les protocoles dans un environnement limité en accès aux ressources partager.cette limitation est le rôle des nœuds actifs.durant l exécution, les nœuds actifs sont responsables de l intégrité du réseau et doit traiter toutes les erreurs qui peuvent se présenter. 34

35 Chaque capsule est limitée en ressource par un champ similaire au fonctionnement du champ TTL (Time To Live) dans les paquets IP. Ce champ est décrémenté à chaque passage par un nœud, jusqu à sa destruction lorsque le champ s annule.les routines de routage doivent être exécutées pendant un court temps, et leurs consommations de bande passante et de mémoire est limitée. Un nœud possède ces caractéristiques : Les routines utiliser pour router une capsule sont définies par la source et ne change pas durant son trajet dans le réseau. Les capsules qui appartiennent à un certain protocole ne peuvent pas créer une nouvelle capsule de protocole différent dans le réseau. Par suite un utilisateur ne peut pas changer le traitement d autres capsules. Les nœuds actifs peuvent ne pas exécuter des routines de routage, dans ce cas le nœud peut choisir de router la capsule suivant le routage IP classique s il trouve un manque dans les ressources ou dans la sécurité. Les routines de routage sont limitées en ressources mémoire et bande passante, par un mécanisme similaire au champ TTL dans les paquets IP traditionnels. Les donnés, dont une capsule peut avoir accès dans le réseau, sont déterminées par le protocole a qui elle appartienne : Distribution de code Dans un environnement programmable un mécanisme de distribution de programme vers les différents nœuds est nécessaire pour assurer la flexibilité de ce réseau. Différentes mécanismes se présentent : Un programme peut être transporté avec chaque capsule.cette méthode est compatible avec des petits programmes. D une autre part les programmes sont téléchargés vers les nœuds qui ont besoin de ces programmes sur un canal différent spécifique. cette méthode souffre du manque de rapidité et de décentralisation de déploiement de nouveaux services. L approche utiliser par ANTS, est le transfère de code, sur demande, et de donné sur le même canal. Le déroulement de cette demande est illustré dans la figure 4. Figure 4 : Demande et distribution de code 35

36 1 Chaque capsule identifie le type de protocole a qui elle appartienne, cette identification ne peut pas changer dans le réseau. 2 Quand une capsule arrive sur un nœud actif, il cherche par mis tous les protocoles qui se trouvent sur ce dernier pour trouver le code demander. Si ce dernier n existe pas le nœud envoie une demande, du protocole qui manque, vers le noeud voisin et la capsule est mise en état sleep. 3 Quand le voisin reçoit cette demande il répond, s il possède ce protocole, par le code demandé. 4 Apres avoir reçue le code, le nœud réveille la capsule pour continuer sont routage. Si le nœud ne reçoit aucune réponse à sa demande la capsule est détruite : L architecture Nœud et Paquet actif Les paquets actifs peut transporter d une manière efficace les codes, si ces derniers sont relativement simple est limités en ressources. D une autre part les nœuds actifs peuvent fournir des codes, mais ces codes sont prédéfinies dans les nœuds actifs ou sur un nœud dont ont peut les télécharger. Dans l architecture Nœud et Paquet actif l utilisateur peut choisir entre les nœuds ou les paquets actifs suivant la nature de ses applications. Les architectures, SwitchWare architecture proposer par L université de Pennsylvania et NetScript proposer par L université de Columbia,utilisent cette approche d architecture : L architecture SwitchWare SwitchWare utilise une architecture en 3 couches pour avoir un choix entre différentes flexibilités, sécurité et performance. La couche paquet actif, extension active et une infrastructure active sécuriser du routeur. Figure 5 : Architecture SwitchWare 36

37 : Paquets actifs Les Paquets actifs remplacent les traditionnelles paquets réseau avec un programme mobile composer de 2 partie code et donnée. La partie code fournie la fonction de control qui remplace l entête du paquet Ip traditionnelle mais avec plus de flexibilité, car elle peut interagir avec l environnement du routeur d une manière plus complexe. La partie donnée remplace le playload du paquet traditionnel en présentent une structure qui peut être utilisée par le programme : Extensions actives Les extensions actives se trouvent au niveau des nœuds ou des équipements réseau et forme la seconde couche dans notre architecture. Ces extensions peuvent être Dynamiquement télécharger ou bien être une fonction de base d un routeur. Les paquets actifs sont limités, par suite on ne peut pas les utiliser seuls pour implémenter des protocoles ou des fonctionnalité dans le réseau.ce problème de limitation est résolue on les utilisant avec les extensions.par exemple un paquet actif pourra appeler une extension pour pouvoir utiliser le service d authentification, d une autre part les extensions ne sont pas mobile, pour qu ils communiquent entre eux elles utilisent les paquets actifs. Puisque les extensions peuvent être dynamiquement télécharger et peuvent avoir un accès a des fonctions du routeur, par exemple changement de l état d une interface du routeur, elles doivent subir un test de sécurité (authentification) avant d être exécuter : infrastructure active sécuriser du routeur D après les sections antérieures l architecture SwitchWare dépend des langages systèmes pour garantir la sécurité du réseau actif. Comme les paquets actifs arrivent, s exécutent et sortent d un noeud, l'infrastructure est la base solide sur laquelle les paquets actifs et les extensions actives sont construits. Le but de l infrastructure active est le suivant : -Supporter le model orienter langages sur les couches supérieures de l architecture SwitchWare. - Assures un coût minimal. -Maximiser la sécurité : PLANet : Introduction PLANet baser sur Internet. PLANet présente des nombreuses applications, par exemple le transfère fiable et non fiable d un datagrame, comme il peut présenter des protocoles de routage comme RIP et ARP. PLANet est le premier réseau purement actif car : PLANet utilise des paquets actifs qui contiennent des programmes PLAN. Ces paquets joue le rôle de l entête des paquets IP traditionnelles en terme de control de la méthode dont les paquets vont être traités.pour simplifier le routage, un paquet PLAN peut utiliser la méthode passive, les paquets ne seront plus évaluer au niveau des nœuds intermédiaire. 37

38 Les nœuds PLANet peuvent être dynamiquement programmes en téléchargeant des extensions actives écrites en langage OCaml. Les extensions sont utilisées pour programmer des services dont le réseau a besoin pour opérer, par exemple ARP, DNS, Figure 6 : Architecture d un nœud PLANet Traitement d un paquet au niveau d un nœud Après avoir traversé la couche lien, un paquet arrive a l interface entre cette dernière et l extension active, si le programme a arrivé à sa destination d évaluation il passe a l interpréteur PLAN pour être évalué sinon il est simplement routé.pendant l évaluation un programme pourra demander des services.un service par exemple pourra être la transmission d un programme PLAN vers un autre nœud pour être évalué : PLAN (Programming Language for active packets.) PLAN est un langage de programmation pour les paquets actifs. PLAN est très simple car ce dernier doit fonctionner comme l entête du paquet IP traditionnelle et par suite le temps d exécution de ce programme doit être petit. Puisque les programmes PLAN vont être exécutés au niveau d un routeur, ils doivent être robuste et ne contiennent aucune erreur et doivent subir un test pour être sure qu il n y a pas d erreur de programmation. PLAN n a pas besoin d une authentification car ces programmes ne peuvent pas changer l état d un routeur et ils ne sont pas modifiées au niveau des nœud du réseau.plan peut aussi limiter les ressources que peut utiliser un paquet actif, comme il limite au paquet et a ces descendants le nombre maximal de nœuds a traversé. 38

39 : Format des paquets Comme on a déjà dit tous les paquets dans PLANet sont des programmes PLAN, ce qui simplifie la construction d un protocole (service) car on n a pas besoin de définir un nouveau format de paquet. La majorité des paquets PLAN on besoin d être routée et non pas besoin d être évaluée, pour cela les informations de routage sont mises dans une position fixe pour améliorer le routage (voir figure 7). Figure 7 : Format du paquet PLAN : Adressage Les deux premiers champs pressentent le champ evaldest qui indique la destination dans laquelle le programme sera évalué et le champ source qui indique l adresse source en cas d erreur. Actuellement PLANet utilise des adresses de 48 bits former de l adresse IP classique (32 bits) et le numéro de port (16 bits)) pour pouvoir utiliser le réseau UDP/IP comme couche lien : Programme Les Trois derniers champs forme le chunk qui est le programme. Quand un programme arrive à sa destination le code du programme est décapsulé pour trouver et appeler les fonctions avec les valeurs données. Si le code dépasse la taille maximale permise, PLAN peut diviser les codes sur différentes chunk. 39

40 : Les autres champs Le troisième champ Rb représente la limite des ressources, similaire au champ TTL(Time To Live) dans IP.Le champ session donne l identité de l application, similaire au champ protocol dans IP. Le champ flowid donne l identité d un flux d un paquet au niveau d un routeur (utiliser pour la QoS). Pour que le paquet arrive à sa destination pour être évalué il doit être routé, pour cela le champ routfun identifie le nom de la fonction de routage choisie. le champ handler donne le nom du service utiliser par la source pour traiter les erreurs : Routage Pour déterminer le prochain saut d un paquet PLAN, les nœuds intermédiaire évaluent le champ routfun qui détermine le nom du service de routage a utilisé, qui se trouve sur se nœud. Deux cas se présentent : -Les paquets seront évalués sur chaque nœud du réseau pour déterminer le prochain saut.cette méthode présente une flexibilisée importante, mais possède le désavantage d être très chère en coût et en performance. -En implémentant un seul protocole de routage pour tous les nœuds du réseau, les paquets seront routés suivant l adresse destination seulement. cette approche soufre du même problème du routage classique mais elle est légère : Traitement des erreurs Dans l Internet le nombre des erreurs qui peuvent être reportés est fixe, si des nouvelles erreurs doivent être reportées on doit attendre leurs standarisation ce qui peut prendre des années. En PLANet les protocoles de diagnostic comme traceroute et ping sont des programmes PLAN, Des nouveaux protocoles peuvent être crées en les programment avec PLAN. Si un service de reportage d information n existe pas, les extensions actives peuvent le télécharger.les erreurs reporter durant l évaluation d un programme peuvent être traiter directement par ce dernier.les erreurs qui se produisent sur la route sont traitées par la source avec le service décrit par le champ handler. 2.6 : Comparaison Projets Technologie De réseau Type de programmation Utilisé Langage utilisé Technologie De distribution d objet Technologie Code mobile encapsulation Domaine Architecturale Active Services Smart packets Internet Dynamique Tcl/oTcl X Création de service Internet Dynamique Discrète NetScript Internet Dynamique Discrète Sprocket/ Spanner 40 X X Gestion des réseaux NetScript X X Création de service réseau ANTS Internet Dynamique JAVA X X Création de service réseau

41 CANEs Internet Dynamique LIANE X X Création de service SwitchWare Internet Dynamique PLAN et Caml X X Création de service réseau SmartPacket Internet Dynamique JAVA X X Création de service réseau Liquid Software Internet Dynamique JAVA X examiner la technologie code mobile ANN Internet Dynamique Discrète Object Code X Création de service réseau NodeOS Internet X X réseau programmable xbind ATM Statique COBRA X Création de service de télécom DARWIN Internet Quasi-statique X X intégration de gestion des ressources Mobiware Mobile Quasi-statique COBRA/ JAVA X X contrôle de la QoS wireless et mobile Tempest ATM Quasi-statique COBRA X X architecture de gestion Supranet Internet X contrôle de service virtuel 2.7 : Conclusion L architecture paquet actif soufre de problème de performance car les exigences de sécurité sont énormes. Pour diminuer les exigences de sécurité et par suite augmenter la performance, des chercheurs ont proposé de limiter les fonctionalites des programmes transporter par les paquets actifs ce qui diminue la flexibilité de l architecture. L architecture nœud actif possède des bonnes performances car les exigences de sécurité sont moins important.mais dans ce cas la flexibilité de cette architecture est limitée.pour augmenter la flexibilité, DAN et ANTS ont adopte une approche avec laquelle les codes peuvent être téléchargé sur demande, et par suite nouveaux protocoles peuvent être déployés.mais le téléchargement de ces codes peut causer un délai qui dégrade la performance du réseau. La combinaison des deux approches pourra présenter une bonne solution entre flexibilité et performance. 41

42 3. ANTS. 3.1 : Introduction La technique des réseaux actifs et l'idée des capsules a été décrite premièrement par [ Tennenhouse and Wetherall, 1996 ]. La caractéristique importante des capsules est leur taille minime, qui est tolérable par la dimension actuelle de l'espace software, ce qui les rend plus effectives actuellement à la réalisation des services que d'autres techniques. Plusieurs plates-formes existent actuellement pour les réseaux actifs : Smart packet and sprocket Switchware and Plan Active IP Ants. Les besoins de contrôle de ressource, sécurité et la multiplicité des environnements d'exécution actuels ont conduit à la proposition d'une architecture commune pour les réseaux actifs par un groupe de travail sur les réseaux actif financé par DARPA. Cette architecture basée sur 3 couches sera détaillée dans le paragraphe suivant. 3.2 NodeOS des réseaux actifs Figure 1 : Architecture Des nœuds actifs ' L'Active Network Working Groupe ' de DARPA a établit une nouvelle architecture pour le nœud d'un réseau actif dans laquelle on définit un système d'exploitation pour le nœud. Cette architecture définit 3 couches de code. Le plus bas niveau représente le système d'exploitation du nœud, il est responsable du multiplexage des ressources pour les différents types de capsules traversant le nœud. Le second niveau représente l'environnement d'exécution dans lequel les capsules vont êtres exécutés. Il présente ainsi une interface de programmation pour les différentes applications développées par les utilisateurs. Le dernier niveau représente l'application développée sur la plate-forme du deuxième niveau. Cette structure va permettre le support de plusieurs environnements d'exécution sur un même NodeOS et par suite sur un même nœud et assure en même temps le contrôle de ressource dans le cœur commun du NodeOS. 42

43 3.3 : Architecture du NodeOS L'interface NodeOS définit 5 abstractions principales : Domaine Channels Threadpools Memorypools Files Les 4 dernières abstractions révèlent les ressources du nœud : bande passante, cycles Cpu, mémoire volatile et mémoire permanente. La première abstraction ou notion, qui est le domaine encapsule les ressources du nœud suivant les 4 dernières abstractions et les attribues à un type donné de paquets. Un domaine peut contenir ainsi une collection de channels, une memory pool et un threadpool : Domaine Les domaines sont organisés en hiérarchie. Le domaine principal sera alors le NodeOS, les domaines secondaires (fils) seront les environnements d'exécution et les domaines tertiaires seront les applications actives. Cette structure en hiérarchie est indépendante de l'allocation des ressources, c'est à dire les ressources attribuées aux domaines fils ne sont pas comptés des ressources attribuées aux domaines pères. Il faut noter aussi qu'à chaque domaine il est attribué une identité de sécurité ( credential ) qu'il lui associe certains privilèges ou permission à l'accès à certaines méthodes du NodeOS : Channels Les channels représentent l'abstraction de contrôle de ressource prisent par le passage d'un type donné de paquet. Ainsi un channel consomme de threadpool et memorypool attribué au domaine auquel il appartient. On distingue 3 types de channels : Inchannels : pour recevoir les paquets entrant au nœud et délivré à l'environnement d'exécution, Outchannels : pour lancer les paquets sortant du nœud Cut-through channels : pour transmettre les paquets (transit) passant par le nœud et non délivré à aucun environnement d'exécution : threadpool C'est l'abstraction de la capacité de traitement ou d'exécution délivrée par le nœud actif à un domaine donné, plusieurs paramètres sont spécifiés lors de la création d'un threadpool : Nombre maximal de threads Le synchroniseur Le taux de cycle Cpu alloue au pool 43

44 3.3.4 : Memorypools C'est l'abstraction de la zone mémoire associée au nœud. Il faut noter qu'une pile de mémoires peut être associée à plusieurs domaines, cela pour donner à l'environnement d'exécution la possibilité de gestion des ressources mémoires allouées à ses domaines : Files C'est l'abstraction des zones de stockage permanent des données associées à un environnement d'exécution. 3.4: ANTS "Active Network Transfer System : Architecture L'Ants est l'une des premières plates-formes de réseaux actifs, sa première version n'implante pas la notion de NodeOS de DARPA alors que dans sa deuxième version Ants2.0 il y a séparation des fonctions attribuées à un environnement d'exécution et celles au NodeOS ( projet Janos ). Cette nouvelle version a été décrite dans le chapitre réseaux actifs,mais dans cette partie on va décrire les considérations architecturales invariantes qui caractérise cette plate-forme comme le chargement de code, les capsules en groupe et le model de référence des capsules : Chargement du code Le chargement de code se fait par propagation, par le nœud extrémité, lançant une capsule de donnée, passant par les nœuds intermédiaires dont chacun commence à recevoir le protocole (traitant la capsule ) du nœud qui le précède, arrivant au nœud destinataire de la capsule en question. Les protocoles ainsi chargés sont \ sauvegardés dans le cache de ce dernier. Avec ce mécanisme le chargement de code est sensiblement séparé du transfert normal des capsules lancées par les applications pour accomplir le service voulu. Cette séparation a pour but d'apporter de la performance par la réduction du trafic de transfère de code dans les lignes de communication et par le fait que le chargement de code n'est effectué que seulement dans l'ensemble des nœuds du réseau suivant lesquels les capsules y passent : Capsules en groupe Le modèle de déploiement de code adopté par Ants et expliqué dans le paragraphe précédent impose donc un transfert de code d'un nœud à un autre. Avec un compromis entre un déploiement entier de tous les codes d'un protocole et le déploiement spécifique de juste du code qui va être exécuté dans un nœud donné en décomposant le protocole en Code Group. Ces Codes Groups représentent un ensemble de capsules qui seront déployées ensemble dans un nœud donné. Le choix des capsules qui appartiennent au même groupe sera affecter par la relation entre elles et plus précisément si l'une nécessite la génération d'une autre. 44

45 De cette manière si une capsule X va générer une capsule Y (par exemple) dans un nœud N, le Code Group contenant la capsule X va être chargé du nœud précédent et la capsule Y va être générée directement (sans chargement supplémentaire ) puisque cette dernière appartient aussi au Code Group contenant la capsule X et qui est déjà chargée. Si les capsules sont les unités élémentaires de transfert du code exécutables dans le réseau, Les «Code Group» dans Ants seront les unités élémentaires de déploiement du code exécutable dans le réseau. Ce modèle de capsule en group présente un désavantage de redondance, on peut avoir le cas où on a besoin d'une capsule dans plusieurs Code Group et le code de celle ci sera alors chargé plusieurs fois dans le même nœud. Un changement convenable non compliqué dans le code de Ants peut permettre de résoudre ce problème en permettant à différentes capsules de différents codes groups d'avoir différents noms mais faisons référence au même code dans le cache : Capsule par référence Pour faire la séparation des services ce modèle intègre dans l'entête de chaque capsule une référence à son code qui se trouve dans le cache du nœud. Ce mécanisme lie alors la capsule à son code, à la structure de son Code Group et à celle de son protocole et une vérification de cette référence est exécutée par la plate-forme Ants2.0 seulement lors du déploiement du code dans le nœud. Ce modèle de protection adopte la séparation de service au lieu d'utilisateur (mécanisme lourd d'authentification ) et il est exécuté durant le déploiement du code au lieu du " run time ", ce qui le rend acceptable de point de vue sécurité et optimal de point de vue consommation de ressource. Mais ce modèle de protection par service lie la référence d'une capsule à la structure du protocole tout entier ce qui empêche la rénovation ou l'amélioration linéaire puisque le changement d'un bit du code de n'importe qu'elle capsule va affecter toutes les références de toutes les capsules du protocole. 3.5 : JANOS : Introduction Janos est un projet à l'université de Utah sur les systèmes d'exploitations dédiés aux réseaux actifs, ce projet est sponsorisé principalement par DARPA. Figure 2 : Janos 45

46 Janos est composé de 5 logiciels distincts : ANTS JAVA NODEOS (bindings) : interface API au NodeOS MOAB JANOS VM : une nouvelle machine virtuelle JAVA MOAB : le NodeOS OSKIT : Operating Système kit Ce projet définit donc des logiciels distincts partant par la construction d'un operating système spécial aux réseaux actifs (oskit, moab) passant par l'élaboration d'une nouvelle machine virtuelle java (janosvm) et finalement l'évolution de la conception de la plate-forme Ants a une nouvelle version Antsr ou Ants2.0. Ces logiciels sont distincts pour permettre le mixage entre eux et par suite avoir la possibilité (par ex ) de faire fonctionner des environnements d'exécutions (EE) autre que Ants ou même des EEs non-bases sur JAVA, Chose qui est possible puisque Janos suit les spécifications du NodeOS définit par l'active Network Working Group de DARPA. Cette décomposition des logiciels nécessite en même temps une adaptation de point de vue management, contrôle de ressource et sécurité du niveau environnement d'exécution au niveau hardware. Cette adaptation est nécessaire pour éliminer la redondance des taches dans les différents niveaux et par suite optimisé le rapport entre eux : OSKIT L'OSKIT est un ensemble de composants modulaires avec une librairie de code utilisée pour la construction du "kernel" de système d'exploitation OS, serveurs et d'autres fonctionnalités au niveau OS. Le NodeOS MOAB est construit sur ce kit et bénéficie ainsi des composants déjà existant comme "device drivers", freebsd, "networking stack", "threading pool" etc : MOAB Moab implémente les fonctionnalités du NodeOS définit par DARPA tout en différant par quelques aspects dont on va citer quelque uns : - Un seul EE "trusted" : Moab suppose que l'environnement d'exécution est "trusted" car les concepteurs de Janos croient que la ligne entre "trusted" codes et "non trusted" codes se trouve entre l'application active (AA) et l'environnement d'exécution (EE). - Les spécifications du NodeOS de DARPA nécessitent l'implémentation d'un threadpool à chaque domaine, MOAB ne se limite pas au niveau domaine et implémente des threadpools à chaque input channel appartenant'"a un domaine donné.. - Memory management dans MOAB n'est pas au niveau domaine ce qui implique un double intérêt, premièrement flexibilité au niveau supérieur ( Janos VM ) et deuxièmement une non redondance puisque JanosVM nécessite un memory management précis au niveau domaine pour des raisons de sécurité et contrôles de ressource. 46

47 Les spécifications du NodeOS de DARPA définis les unités de ressources comme indépendante du hardware. MOAB au contraire définit les ressources par des unités dépendant du hardware par ex : l'utilisation du CPU est dimensionnée par nombre de cycle processeur par second et l'utilisation de la bande passante est exprimée par byte par second : JanosVM Une nouvelle machine virtuelle apportant plus de sécurité, contrôle de ressource est devenue indispensable pour les réseaux actifs. JanosVM est la partie la plus critique de Janos, c'est là que Janos se protège contre le code "untrusted " des utilisateurs. JanosVM supporte la notion de domaine ainsi que l'habilité d'isolation des applications, chacune dans son propre espace mémoire et son propre garbage collecter. Les applications sont exécutées ainsi comme ci chacune a sa propre machine virtuelle java. Figure 3 : JanosVM : Fonctionnement de la Plateforme ANTS v2 Ants est un environnement d exécution base sur JAVA et ce positionne au-dessus de dans l architecture Janos. JanosVM : LES FLOWS La notion de Domaine définit dans les spécifications du NodeOS de DARPA est symbolisée par Flow dans le code du Janos. La description de l'architecture d'un réseau donné (nombre de nœuds, les applications sur ces nœuds...) est décrite dans un fichier de configuration normalement d'extension.config. Le lancement de la plate-forme Ants2.0 consiste à faire lancer chaque nœud définit dans le fichier.config dans une machine virtuelle java. java edu.utahjanos.nodeos.main ConfigurationManager < nom du fichier.config > <adress du nœud> Dans le code de Ants2.0 on trouve plusieurs instances de la classe Node pour le même nœud définit par l'utilisateur dans le fichier.config. Ants2.0 définit premièrement une instance principale du nœud en question représentée par PrimordiaINode puis a chaque protocole ou application (qui vont être lancer dans des Flow différents ) définit des instances différentes de la classe Node. La classe Node représente ainsi l'interface des protocoles et applications au nœud principal représenté par PrimordiaINode et qui est lance dans le Flow parent Root Flow. Cette interface va limiter l'accès des protocoles et application suivant les permissions associées au paramètre principal de l'interface Node. 47

48 On notera aussi l'association d'un Node cache à chaque instance de la classe Node. Node cache étant une place mémoire utilisée la plupart des fois pour le partage des objets entre plusieurs capsules d'un même protocole ou application. Ces objets sont placés dans Node cache avec un temporisateur T défini par l'utilisateur, si ce temps expire le garbage collector propre au Node cache l'élimine. Figure 3 : Rôle de la classe Nodes La machine virtuelle Java lance donc la méthode Main du NodeOS qui à son tour lance le configuration manager pour lire le fichier.config de l'utilisateur et passer les paramètres lus au PrimordialNode. Toujours dans le Flow principale Root Flow le configuration manager fait appel à la méthode START de PrimordialNode en lui passant les paramètres du fichier.config. PrimordiaInode.start ( apps, exts ) apps : paramètres de l'application associés au nœud ext : extensions associées au (non utilisé actuellement ) Le fonctionnement de PrimordiaINode est schématisé par la figure 4. Sa méthode START initialise le nœud en faisant le suivant : 1 - initialise le transport layer en lançant un thread pour recevoir les UDP sur le port déjà définit par l'utilisateur dans le fichier.config. 2 - ajoute au système package et au sealedpackage (qui contenait les classes du NodeOS et quelques classes de Java ) le package de Ants2.0 Flow.currentflow().addsystempackage( Antspackage[lpc]) Flow.currentflow().addsealedpackage( Antspackage[lpc]) 3 - Lance un thread dans le Root Flow pour le Primordial Messenger, ce dernier étant une queue pour la communication des différents Flows fils avec le Flow parent. 4-charge la politique de sécurité d'un fichier prédéfini nommé policyfile. ants.core.security.referencemonitor.loadpolicy( PolicyFile ) 5 - création et initialisation des tables de routage\\ 48

49 6 - définit et enregistre les 2 builtins protocoles, DLprotocol et Dataprotocol. DLProtocol : responsable du chargement du code des capsules inconnues par le nœud et par suite le chargement d'autres protocoles. Dataprotocol : protocole de base pour l'échange de paquets passifs entre les nœuds. Par ce protocole le réseau actif est un simple réseau traditionnel, les paquets sont juste routés vers ses destinataires. DLProtocol dlp = new DLProtocol ( ) Node.register ( dlp ) DataProtocol dp = new Dataprotocol ( ) Node register ( dp ) 7-lance les applications s'il en existe sur ce nœud. fireupnewappflow ( ) 8-lance le routage dynamique s'il est choisit dans le fichier.config.le routage dynamique pour Ants2.0 est réalisé en lançant l'application routage dynamique qui existe dans le package de Ants2.0. Le lancement de cette application est le même que les autres applications définies par l'utilisateur. FireupNewAppFlow ( dynroutapp ) Figure 4 : Fonctionnement du PrimordialNode 49

50 Apres cette phase transitoire du lancement d'un nœud actif définit dans le fichier.config, ce nœud passe dans le régime permanent de fonctionnement qui comprend la réception, l'évaluation et le routage des capsules reçus ou bien le chargement des CodeGroups et l'activation des capsules inconnues et leur lancement dans des nouveaux Flows : la Communication Entre Les Flow La communication entre les Flows joue un rôle important pour le contrôle de ressource et la terminaison des différents Flows. pour cette raison la communication entre le Flow initial et les différents Flows se fait par des queues de communication. L'envois de message vers PrimordiaINode se fait par une queue gérée par la classe "primordial messenger". - l'envois des messages de primordial Node vers les flows fils (protocoles et applications ) se fait par des queues que primordial Node conserve ses indexes dans des hashtables pour les flows protocoles : private static final hashtable pidtoflowqueue = new hashtable pour les Flows applications : private static final hashtable porttoappqueue = new hashtable les classes gérant ce type de communication sont : CommmQueue.class : la queue de communication CommQueuePusher.class : gère l'introduction de message dans la queue CommQueuePuller.class : gère la lecture des messages de la queue : les messages envoyer vers primordiainode : Trois types de message sont envoyés à travers le "primordial messenger" pour le primordiainode : o INSTALL-PROTOCOL : Ce message cause le lancement de la méthode primordiainode.installprotocol ( pid, name, principal ) qui a son tour lance un Flow fils pour ce protocole et lui associe une queue FIFO pour communiquer avec lui. o ADD-MID: Utilisé pour ajouter une nouvelle capsule à un protocole. o DETACH-APPLICATION : Ce message cause la terminaison d'une application et son interface Node au primordiainode : Messages envoyer vers les Flow des protocoles : Trois types de messages sont envoyés vers les Flows de type protocoles : o LOCAL-PROTOCOL : Ce message est envoyé de PrimordiaINode au Flow du protocole qu'il a déjà crée. Dans le contexte de ce nouveau Flow le message LOCAL-PROTOCOL cause le chargement du protocole et l'activation de ces CodeGroups. 50

51 o NEW-MID : Ce message est envoyé de primordiainode pour ajouter au protocole une nouvelle capsule déjà charge à travers le réseau. Il faut rappeler que dans ce cas là tout le CodeGroup auquel cette capsule appartient est chargé dans le Flow du protocole correspondant. o APP-CAPSULE: Ce message est envoyé de la classe application pour envoyer une capsule dans le réseau : Messages envoyés vers les Flows des applications : Normalement les messages envoyés dans les queues associes au applications sont les paquets envoyés par la méthode delivertoapp de la classe Node associée au Flow application. D'autre part Janos interdit le partage direct des objets en commun entre les différents Flows, pour cela il adopte une technique ou les objets sont copiés par chaque Flow lors de la lecture de ce dernier de la zone mémoire commune entre les Flows. les classes gérant ce type de communication sont : CommSpace.class : la zone mémoire commune CommSpaceElement.class : le format des objets enregistrés dans CommSpace CommSpaceHandIe.class : gère l'écriture et la lecture des CommSpaceElements dans CommSpace. La classe la plus importante utilisant les commspacehandie est la classe unknowmidpackets qui est une zone mémoire temporaire pour la sauvegarde des paquets inconnus arrivant aux nœuds, ce dernier fait le chargement du protocole correspondant pour pouvoir évaluer ces capsules inconnues. Une fois le chargement des CodeGroups du protocole convenable est accomplit les capsules sont retirés de UnknownMidPacket pour être évaluées. 51

52 4..NET Le.Net framework est une infrastructure qui nous permet de créer des applications fortement distribuées sur l'internet pour différents environnements et périphériques ainsi que des applications Windows standards, des composants serveurs, des applications qui tournent sur n'importe quelle périphérique comme par exemple un PC, un périphérique mobile... Le.Net a réussi un des plus grand défi de l'industrie des «softwares» : L'échange de données entre des applications écrites en différents langages de programmation. En effet, il permet l'échange de données entre plusieurs applications en utilisant les services web. Il fournit une infrastructure «Remoting» qui permet aux applications tournant en deux processus différents, sur une ou plusieurs machines d'échanger des données en utilisant le protocole HTTP (Hypertext Transfer Protocol), XML et SOAP (Simple Object Access Protocol). Le.NET Framework est constitué principalement de 2 composants: la librairie de classe et le «common language runtime» du.net Framework. La librairie de classe du.net Framework fournit les types communs à tous les langages du.net. Les Programmeurs peuvent utiliser ces types pour différentes catégories d'applications comme les console applications, Windows et Web Forms, et XML Web services. Le «common language runtime» est constitué de composants qui chargent le «IL code» d'un programme dans le «runtime», compile le «II code» en native code, exécutent et gèrent le code, renforcent la sécurité et la sûreté des types et supportent les «threads» et beaucoup d'autres services utiles. Enfin, le.net est un environnement qui favorise la création d'applications distribuées et qui augmente la productivité des développeurs par la richesse de ces classes. 52

53 5. Simple Object Access Protocol 5.1. Généralités SOAP (Simple Object Access Protocol) est un protocole de transmission de messages. Il définit un ensemble de règles pour structurer des messages qui peuvent être utilisés dans de simples transmissions unidirectionnelles. Il n'est pas lié à un protocole particulier mais à HTTP qui est populaire. Il n'est pas non plus lié à un système d'exploitation ni à un langage de programmation, donc, théoriquement, les clients et serveurs de ces dialogues peuvent tourner sur n'importe quelle plate-forme et être écrits dans n'importe quel langage du moment qu'ils puissent formuler et comprendre des messages SOAP. SOAP serait donc un important composant de base pour développer des applications distribuées qui exploitent des fonctionnalités publiées comme services par des intranets ou internet.- SOAP définit un protocole permettant des appels de procédures à distances s'appuyant principalement sur le protocole HTTP et sur XML, mais aussi SMTP et POP. Il permet ainsi de définir des services WEB. Les paquets de données circulent sous forme de texte structuré au format XML (Extensible Markup Language) Avantages Le principal avantage de SOAP est qu'il repose sur 2 standards XML (pour la structure des messages) et HTTP (pour le transport ) bien qu'il soit utilisable avec d'autres protocoles de transport. Par rapport à tous les autres protocoles, celui-ci présente l'avantage de l'interopérabilité, on est indépendant des plate-forme et des langages de programmation. Le second avantage réside dans le déploiement des applications, principalement dans un contexte multi-sîtes, pour communiquer entre 2 sociétés via Internet, c'est souvent mission impossible d'utiliser autre chose que du HTTP ou du POP/SMTP à cause 53

54 des Firewalls, car pour les autres protocoles il faut les reconfigurer, avec tous les trous de sécurité que cela peut engendrer, et cela implique souvent de longues négociations avec les administrateurs réseaux. SOAP permet de s'affranchir de tout ça Message SOAP Structure SOAP est basé sur les trois concepts suivants: Le concept de l'enveloppe SOAP définit un cadre qui exprime ce qu'il y a dans un message; qui doit s'occuper de ce message et si ce message est facultatif ou obligatoire. Les règles de codage SOAP définissent un mécanisme de mise en série qui peut être utilisé pour l'échange des différents types de données spécifiées par les applications. La représentation SOAP RPC définit une convention utilisée pour représenter les procédures des appels et réponses à distance. En général, les messages SOAP peuvent être transportés dans des messages HTTP. Leur structure est montrée dans la figure 1. Figure 1 :Structure d'un message SOAP. La première partie du message contient un type MIME "text/xml" et l'enveloppe SOAP. Cette enveloppe est un message XML. Elle contient un en-tête 54

55 optionnel et un corps obligatoire. Le corps de l'enveloppe est adressé toujours à la destination finale, alors que les entrées de l'en-tête peuvent s'adresser à des nœuds intermédiaires pour qu'ils ajoutent leurs propres traitements aux paquets. Des attachements,binaires ou autres peuvent être annexés au corps de l'enveloppe. L'utilisateur peut spécifier, lui-même, dans le header, les nœuds qui doivent ajouter leurs traitements au paquet. Comme les headers sont orthogonaux au contenu du message SOAP, ils permettent d'ajouter de l'information au message sans altérer les informations du corps du message ni leur traitement. C'est ainsi que les en-têtes peuvent être utilisées pour ajouter des informations d'authentification auprès d'un certain serveur d'authentification. Cette caractéristique du message SOAP est particulièrement intéressante dans le cas d'une implémentation de réseaux actifs. Au lieu de définir une capsule en langage java par exemple, puis la transformer en langage binaire avant de l'envoyer d'une machine à l'autre, SOAP le fait pour nous avec un atout supplémentaire puisque le contenu du message est écrit dans un langage standard, XML Modèle des messages d'échange SOAP Les messages d'échange SOAP sont unidirectionnels de l'émetteur au récepteur. Indépendamment du protocole qu'utilise SOAP, les messages seront routés suivant des "message path" (chemin de routage) qui permettent le passage par des noeuds intermédiaires jusqu'à la destination. Une application SOAP qui reçoit un message SOAP doit suivre les instructions suivantes avant de laisser passer ce message: Identifier toutes les parties du message SOAP nécessaires à l'exécution du service. Vérifier que toutes les parties obligatoires (mandatory) du message sont présentes pour l'application et les traiter, sinon rejeter ce message. Si la destination finale n'a pas été atteinte, effacer toutes les parties identifiées dans la première instruction avant d'envoyer le message. Des attributs comme "encodingstyle" peuvent être utilisés pour décrire certains aspects du message Relation entre SOAP et XML Tous les messages SOAP sont écrits dans un langage XML. Une application SOAP doit contenir les "namespace" nécessaires pour tous les éléments. De plus, les applications SOAP doivent rejeter les messages qui contiennent des "namespace" incorrects. SOAP définit deux "namespace": un identificateur qui désigne l'enveloppe SOAP et un autre pour le codage SOAP. Il utilise l'attribut local "id" qui dérive de "ID" pour spécifier 55

56 l'identificateur d'un élément de codage et l'attribut local "href" du type "urireference" pour spécifier la référence à cette valeur selon les spécifications du langage XML et de ces schémas L'enveloppe SOAP Un message SOAP est un document XML qui est formé d'une enveloppe, d'un header facultatif, et d'un body nécessaire. L'identificateur "namespace" pour les éléments et attributs définis dans ce paragraphe se trouve dans le site: Un message SOAP contient ce qui suit: - Une "Envelope" qui se trouve au début d'un document XML représentant le message. - Un "Header" qui contient les fonctionnalités ajoutées au message SOAP pour spécifier qui doit s'occuper du message et s'il est obligatoire ou non. - Un "Body" qui contient les informations nécessaires dans un message. SOAP définit un élément dans cette partie pour le rapport d'erreurs. Les règles que doit suivre chaque partie du message SOAP sont les suivantes: 1- Enveloppe: - Nom de l'élément: "Envelope" Cet élément doit être présent dans un message SOAP - Cet élément peut ne pas contenir des déclarations "namespace" ni des attributs. Si ces derniers sont présents, ils doivent avoir des "namespace" qui les définissent. De même, cet élément peut contenir des sous éléments additionnels mais ils doivent avoir des "namespace" et doivent suivre l'élément Body. 2- En-tête: - Nom de l'élément: "Header" - Cet élément peut être présent dans un message SOAP - Cet élément peut contenir un ensemble d'en-tête tel que chacun est considéré comme un sous élément de Header à condition qu'ils soient bien identifiés par des "namespaces". 3- Body: - Nom de l'élément: "Body" - Cet élément doit être présent dans un message SOAP et doit hériter de l'enveloppe SOAP. Il doit suivre directement le Header s'il existe. Cet élément peut contenir un ensemble de Body tel que chacun est considéré comme un sous élément de Body à condition qu'ils soient bien identifiés par des "namespaces". 56

57 L'en-tête SOAP SOAP possède un mécanisme qui permet de prolonger un message sans tenir compte des conventions entre les 2 parties d'une communication. Dans l'en-tête, on trouve des entrées implémentées comme la validation, la gestion des transactions, le paiement Le "Header" est codé comme premier fils de l'enveloppe SOAP dans un document XML. Les régles de codage pour les entrées dans le Header sont les suivantes: - Une entrée doit être identifiée par son nom qui est formé de "namespace". Et les éléments fils doivent être tout de même précédés par un "namespace". - L'encodingStyle peut être utilisé pour indiquer la méthode de codage employée pour les nouvelles entrées du Header. - Les attributs SOAP "mustunderstand" et "actor" peuvent être utilisés pour indiquer que faire avec la nouvelle entrée et de qui elle provient. Les attributs de SOAP déterminent comment le récepteur d'un message SOAP doit s'occuper de ce message. - L'attribut SOAP actor: Un message SOAP émis vers une destination doit sûrement passer par des noeuds intermédiaires. Ces derniers sont des applications qui sont capables de recevoir et d'émettre des messages SOAP. La destination et les noeuds intermédiaires sont identifiés par des URI (namespace). Pas nécessairement, tout le message SOAP est dédié à la destination mais il peut contenir des parties destinées aux noeuds intermédiaires. Celui qui reçoit le header ne doit pas le retransmettre à l'application suivante. L'attribut SOAP actor a pour rôle d'indiquer le récepteur du header. Sa valeur est en URI. Cet attribut doit être présent dans une instance pour être valable. - L'attribut mustunderstand : Cet attribut global est utilisé pour indiquer si le Header est obligatoire ou facultatif pour le récepteur qui va le lire. Sa valeur est soit "1" ou "0". Les éléments qui contiennent 1 comme valeur de cet attribut doivent modifier les sémantiques de leurs parents ou des éléments voisins. Cet attribut doit être présent dans une instance pour être valable Le Body SOAP Ce Body prévoit un simple mécanisme pour l'échange des informations utiles destinées au récepteur. Typiquement, le Body est,utilisé pour la maîtrise des appels RPC et pour rapporter les erreurs. Il est codé comme fils immédiat de l'élément 57

58 "SOAP envelope". Si le header existe, le Body doit le suivre directement. On parle de "body entries" pour designer les éléments fils à l'élément Body et chaque entrée est codée différemment des autres dans un même élément Body. Les règles de codage des éléments du body sont les suivantes: - Une entrée Body doit être identifiée par son nom qui est formé de "namespace". Et les éléments fils doivent être tout de même précédés par un "namespace". - L"encodingStyle" peut être utilisé pour indiquer la méthode de codage employée par les nouvelles entrées du Body. - SOAP définit une entrée Body dite "Fault entry" pour le rapport des erreurs SOAP Fault L'élément SOAP Fault est utilisé pour transporter les erreurs et/ou l'état des informations dans un message SOAP. S'il est présent, il doit apparaître dans le Body une et une seule fois dans un élément Body. Il définit les 4 sous éléments suivants: faultcode Cet élément identifie l'erreur. Il doit être présent dans l'élément SOAP Fault. SOAP définit un ensemble de codes spéciaux pour SOAP Fault. faultstring Cet élément permet de faciliter la lecture de l'erreur. Il nous explique la nature de l'erreur et il doit être présent dans un élément SOAP Fault. faultactor Cet élément précise qui a causé cette erreur. Il est semblable à l'attribut SOAP actor mais à la place d'indiquer la destination de l'entrée du Header il spécifie la source d'erreur. Sa valeur est de type URI identifiant la source. détail Cet élément transporte les informations des erreurs en relation avec l'élément Body. Il doit être présent si le contenu du Body n'a pas été bien reçu SOAP et HTTP: Cette liaison SOAP avec http est avantageuse car elle relie le protocole SOAP qui est simple et flexible à un protocole HTTP qui a un grand nombre de fonctionnalités. SOAP suit naturellement le modèle HTTP de messages de requêtes/réponses qui fournit des paramètres de requête SOAP dans une requête http et des paramètres de réponse SOAP dans une réponse HTTP. En fait, SOAP 1.0 a désigné de façon spécifique HTTP comme son protocole de transport. Quant à SOAP 1.1, il utilise 58

59 toujours le HTTP mais travaille aussi avec d'autres protocoles Concept de Filtre Les filtres outgoing et incoming qui sont construites grâce a «WSE» présentent les fonctionnalités de diagnostique, sécurité, referral et routages. «WSE» nous permet aussi de déployer des filtres sur la sortie et l entrée des messages SOAP définies par l utilisateur appeler custom filters.ces filtres peuvent utiliser n importe quelle information contenue dans le message SOAP pour déterminer comment traiter ce dernier. Plusieurs custom filter peuvent être déployés. 59

60 figure 2 Traitement d un message SOAP. Le paquets SOAP sortant d un service sera traite par les différentes filtres selon l ordre précise dans la figure 2.Ce paquet sera transmis vers le réseau sous forme d un SOAP REQUEST. A l arrivée ce message passe par les même filtres mais dans le sens inverse.de même pour le SOAP RESPONSE qui est la réponse du serveur contenant le service demander par le message SOAP REQUEST. 6. WSE 6.1. Introduction au Web Service Enhancements Le WSE ajoute au.net les fonctions de routage, sécurité et attachment aux services XML et les applications client, créer à l aide de l Asp.Net. En utilisant le WSE pour les services Web XML on peut : Sécuriser les applications tout au long d un domaine. Modifier d une façon transparente, au niveau des nœuds, le chemin que peut prendre un message SOAP pour arriver au service Web. Attacher un fichier avec un message SOAP, durant une communication entre les services Web XML, sans le sérialiser en XML Routage avec le WSE 60

61 WSE peut assurer au client une topologie réseau transparente. Pour cela il faut installer, au niveau d un ordinateur intermédiaire, un routeur WSE. Le client envoie le message SOAP vers le routeur intermédiaire au lieu de le transmettre directement vers le service Web XML. Ensuite le routeur envoie ce message vers le service Web destinataire, qui peut être modifie en utilisant le fichier de configuration du routeur intermédiaire. Figure 1 La Figure 1 nous montre la transmission d un message SOAP vers un routeur WSE,qui a son tour transmet le message vers un autre serveur Web en ce basant sur le contenue de sa table de routage qui se trouve dans le fichier referral cache. Dans notre cas le referral cache nous dit que le message doit être transmise vers le serveur B mais le referral cache pourra être modifié pour transmettre le message vers le serveur C par exemple. Un des avantages de l utilisation d un routeur WSE est q un ordinateur contenant un service Web XML peut être mis off line pour la maintenance sans modification au niveau du code et au niveau de la configuration du client.l administrateur de l ordinateur contenant le service Web doit faire les changement nécessaires pour rediriger les messages SOAP vers un autre ordinateur. Pour cela l administrateur prépare un ordinateur de back up contenant le service Web et qui remplacera le premier, pendant ce temps les messages SOAP sont transmis vers le premier serveur. Ensuite l administrateur prépare un fichier Web.config qui indique au routeur intermédiaire ou se trouve le fichier «referral cache» contenant la table de routage modifier pour indiquer le nouveau URL du serveur back up. Lorsque le premier serveur est mis off line les fichiers Web.config et referral cache sont mis au niveau du routeur, les messages SOAP seront routés vers le nouveau serveur Web WS-Routing 61

62 WS-Routing est un simple protocole de routage des messages SOAP suivant une variété de protocole de transports comme TCP,UDP et http.ws-routing ajoute des fonctionnalités a SOAP en définissant un nouveau path a l entête SOAP. Le tableau suivant nous montre les éléments ajouter au SOAP header et leurs rôles. Element From To Via Fwd Rev Id relatedto action Description La source du message (optionnelle) La destination (obligatoire) Un routeur intermédiaire (optionnelle) La route dans le sens entrant (opt) La route dans le sens inverse (opt) Element d identification unique d un message (obligatoire) Element qui indique la relation avec d autre message (opt) Element qui indique le but du message (obligatoire) Le tableau suivant nous montre les éléments qui retournent dans le header en cas d erreur : Element fault code reason Description Contient l information sur l erreur (obligatoire) Nous rend le numéro de l erreur spécifique (obligatoire) Retourne une phrase qui décrit la cause de l erreur. (oblig) L exemple ci-dessous nous montre une erreur : <fault> <code>710</code> <reason>endpoint not Found</reason> <endpoint> 62

63 </fault> l exemple suivant nous montre un message envoyé par un WS-Routing A vers un destinataire D a travers B et C. <S:Envelope xmlns:s=" <S:Header> <wsrp:path S:actor=" S:mustUnderstand="1" xmlns:wsrp=" <wsrp:action> <wsrp:to> <wsrp:fwd> <wsrp:via> <wsrp:via> </wsrp:fwd> <wsrp:from>mailto:[email protected]</wsrp:from> <wsrp:id> uuid:84b9f5d0-33fb-4a81-b02b-5b760641c1d6 </wsrp:id> </wsrp:path> </S:Header> <S:Body>... </S:Body> </S:Envelope> 6.3. WS-Security WSE utilise les mécanismes définis dans les spécifications WS-Security pour sécuriser les services Web. Un client doit obtenir une référence de sécurité d une source (qui doit avoir la confiance de l expéditeur et du récepteur). Quand un client envoie une requête SOAP, les références de sécurité (Security tokens) sont mises dans le message SOAP. Quand le serveur Web recoie la requête, le WSE vérifie que les références sont authentifie avant d envoyer le message vers le serveur Web et cela sans envoyer une requête vers le client pour vérifier l intégrité du (Security tokens). La signature numérique et le cryptage d un message SOAP peut mieux sécuriser un service Web XML.La signature numérique d un message SOAP sécurise le service Web en permettant a un destinataire de vérifier que le message n a pas été modifie depuis qu il a été signe. Le cryptage d un message nous permet de sécuriser le message d une façon extrême car le message ne pourra être lue qu a l arrive a sa destination (service Web). Le WSE nous fournie 3 méthodes pour sécuriser un message SOAP : Des références de sécurité. 63

64 La signature numérique. la figure 2 nous montre la clé nécessaire à l expéditeur pour signer le message et la clé nécessaire au récepteur pour vérifier l intégrité du message. Pour signer le message SOAP l expéditeur a besoin de la clé prive et pour vérifier la signature le récepteur doit avoir la clé public de l expéditeur. Figure 2 Le cryptage d un message SOAP.La figure 3 nous montre les clés nécessaire a l expéditeur et au récepteur pour crypter et décrypter le message.pour crypter un message SOAP l expéditeur doit avoir la clé public du récepteur qui a son tour doit possède sa clé privée pour décrypte le message. Figure 3 La figure 4 nous montre que seulement le récepteur d un message SOAP crypter peut avoir accès a la partie crypter car il est le seul qui possède la clé privée. 64

65 Figure Signature numérique Le WSE fournit un mécanisme pour signer un message SOAP en utilisant un Username Token ou un certificat X.509 comme on peut utiliser un custom binary security tokens. Quand le message et signer par un Username Token, le client fournit un username et un mot de passe.la signature numérique peut vérifier si le message n a pas été modifie, mais elle ne crypte pas le message ; le message est transmis en texte claire Cryptage Le Web Services Enhancements for Microsoft.NET (WSE) permet au Services Web XML, crée par ASP.Net, et a leurs clients de crypter et décrypter les messages SOAP échanger pour communiquer avec un service Web XML. Les messages SOAP sont transmises en texte clair par défaut se qui permet a n importe qu elle récepteur de lire le message. Mais avec un message SOAP crypter on s assure que seul le récepteur désigne va décrypter le message et va pouvoir le lire. Le WSE supporte le cryptage symétrique et asymétrique. Le cryptage asymétrique permet au client d un service Web de crypter le message en utilisant la clé public d un certificat X.509, D une manière que seul le propriétaire de la clé prive du certificat X.509 peut décrypter le message SOAP.Le cryptage symétrique exige la possession d un secret partage par le service Web et son client. Par suite le client crypte le message SOAP par le secret partage et le service Web décrypte par le même secret. Le WSE crypte la partie <Body > d un message par défaut, mais on peut spécifier la partie d un message SOAP a crypter. 65

66 7. Architecture d'un Réseau Actif à base de Services Web 7.1. Introduction Les avantages des réseaux actifs sont déjà bien identifiés. Ils fournissent un déploiement de services rapide, et une distribution de charge sur le réseau. D une part ils permettent d ouvrir les équipements et permettent la personnalisation du réseau suivant les applications utilisées ; d autre part, ils sont évidemment plus complexes que les réseaux classiques et introduisent plus de problèmes de sécurité à résoudre. Leur implémentation pose plusieurs défis. Leur performance doit être comparable à celle des réseaux existants ainsi qu ils doivent offrir au moins la même sécurité et la même robustesse, ce qui est un grand défi quand le code peut migrer et s exécuter dans un grand réseau hétérogène. Finalement, vue cette hétérogénéité, ils doivent avoir un certain degré d interopérabilité leur permettant de fonctionner comme les réseaux classiques. Les architectures des réseaux actifs sont groupées selon leurs différentes approches. L approche paquets actifs, qui se caractérise par le transport du code actif au niveau des paquets. Les Smart Packets, le projet Active IP, et l architecture M0, en sont des exemples. Dans l approche nœud actif, les paquets ne transportent pas le code, mais une référence à des fonctions prédéfinies qui résident dans les nœuds actifs. ANTS, DAN ainsi que HABA en sont des exemples. L approche paquet actif introduit plus de problèmes de performance, vu que les exigences de sécurité sont énormes. Ce qui n est pas le cas de l approche nœud actif qui offre de meilleures performances. Mais la flexibilité d une telle approche est limitée. Dans un effort pour améliorer cette flexibilité, ANTS, DAN et HABA ont adopté un schéma de déploiement de code à la demande, avec la possibilité de faire un caching de ce code, pour des utilisations ultérieures. Dans ce papier, nous présentons une nouvelle architecture active pour la conception et le déploiement de services réseaux : ASWA, Architecture à base de Services Web Actifs. C est une architecture à base de composantes logicielles réutilisables: les services web. Elle s appuie sur l'infrastructure de communication distribuée offerte par le web, pour un déploiement dynamique et contrôlé du code mobile. ASWA offre une conjonction améliorée des caractéristiques de déploiement spécifiques à ANTS, DAN et HABA, tout en proposant une réponse encourageante à un réseau actif sécurisé et inter-opérable dans un environnement hétérogène. Pour résumer, cette contribution pourrait s identifier principalement sur 4 plans : 66

67 - Sur le plan architectural, ASWA définit le nœud actif en conformité avec le «DARPA Architectural framework for Active Networks», où les fonctionnalités d un nœud actif se répartissent en 3 composantes majeures : Le système d exploitation du nœud, l environnement d exécution, et les Applications Actives. - Sur le plan de l implémentation, ASWA comme son antécédent HABA, est une plateforme à base de composantes. Cette approche offre plus de flexibilité et de modularité au niveau de la manipulation et de la maintenance du code, ainsi qu elle garantit l extensibilité par ajout et déploiement dynamique de nouvelles composantes en vue de modifier dynamiquement les fonctionnalités de n importe quel nœud du réseau. Ainsi l interopérabilité avec ANTS peut être effectuée par simple composition. ASWA s appuie sur l architecture des Services Web pour l aboutissement de ces fins. En effet, un Service Web fournit une infrastructure souple basée sur le protocole SOAP pour la communication entre les composantes distribuées. SOAP est un protocole indépendant du langage de programmation, du système d exploitation et du hardware. En fait, il peut être utilisé pour assurer la communication entre n importe quels éléments supportant TCP/IP via HTTP, SMTP, FTP ou autres (voir Figure 1). - Comme la quasi-totalité des langages informatiques supporte ces protocoles, un service Web développé sous une plate-forme Microsoft.NET pourra être utilisé via le langage Perl, PHP, Python, Delphi, Cobol, ou autres. Donc, l'utilisation de ASWA garantit l'interopérabilité entre langages, systèmes et réseaux hétérogènes. Entête SOAP SOAP XML HTTP SMTP FTP Extensions de l'enveloppe SOAP Message XML Codage des Données Protocole Réseau S é c u r i t é A d m i n i s t r a t i o n Q O S Figure 1: Pile Réseau - Au niveau du déploiement de code, ASWA utilise l approche du nœud actif pour mieux contrôler le chargement de code, vu que cette approche offre des mécanismes de chargement et d exécution de code séparés. - En terme de sécurité, ASWA profite de l'entête de l'enveloppe du protocole SOAP pour insérer des mécanismes de sécurité tel que l'authentification par utilisation de mots de passe ou de la signature numérique. D'autre part ASWA utilise le protocole HTTPS (HTTP over SSL) pour sécuriser le déploiement. Mais comme déjà dit, SOAP consiste à faire circuler du XML via du HTTP sur le port 80, ce qui lui permet de franchir les pare-feu des entreprises sans aucun filtrage. Pour remédier à cette faille, ASWA définit un "schema XML" (voir section 7.6.1) dont l'instanciation permet de définir la liste de contrôle d accès d'un pare-feu personnalisé sous forme d un fichier XML qui sera déployé sur chaque nœud actif. Ce fichier XML permettra alors de surveiller le déploiement des services actifs de nœud en nœud ainsi qu'il permettra de contrôler le traitement des paquets actifs. La suite de cet article est organisée de la façon suivante: Dans la section nous discutons les travaux déjà réalisés dans ce domaine. Dans la section 7.2 nous exposons l'intérêt d'utiliser les services Web dans l'implémentation d un réseau actif. Dans la section 7.3 nous 67

68 décrivons l architecture de ASWA. Dans la section 7.4 nous détaillons l implémentation de ASWA. La section 7.5 présente les besoins des réseaux actifs en terme de sécurité ainsi que l implémentation de la sécurité dans ASWA. La section 7.6 traite l implémentation d'une application active qui consiste à déployer un pare-feu actif. Finalement la section 7.7 présente les conclusions Intérêt des Services Web dans la conception des Réseaux Actifs Une relation étroite existe entre les services middleware et les réseaux actifs. Les réseaux actifs visent d une part à fournir des infrastructures de réseau efficaces et très flexibles. De l autre part les services middleware paraissent capables de mettre en oeuvre de tels systèmes. Malgré cette relation étroite, très peu de plateformes de réseau actif essaient de profiter dans leur conception des structures middleware existantes qui supportent des mécanismes de communication distribuée, des mécanismes de déploiement et de chargement dynamique de services, ainsi que des mécanismes d appel de méthodes distantes et une gestion avancée de la sécurité. D'ailleurs, bien que les architectures de réseaux actifs fournissent un grand degré de flexibilité au niveau application, la plupart sont des systèmes fermés et ne permettent pas l'utilisation des services existants basés sur le modèle client/serveur ou RPC. Elles ne fournissent même aucune interopérabilité avec d'autres architectures de réseaux actifs. En utilisant le protocole SOAP, comme nous le proposons dans cet article, les applications et les architectures à base de services web développées avec n'importe quel langage de programmation et tournant sur un système d'exploitation quelconque, pourront communiquer sans aucune modification. Il suffirait alors pour assurer l'interopérabilité entre les architectures de réseaux actifs à base de services web et d'autres architectures de réseaux actifs, d encapsuler les paquets de ces derniers dans des messages SOAP et de confier leur transport à une couche de communication fondée sur HTTP et TCP/IP. Ceci n'est pas aussi facile pour les plateformes actives actuelles à base de composants middleware qui nécessite pour leur communication des modifications liées au fait que les middlewares existants sont limités dans leurs capacités, difficiles à utiliser et incompatibles les uns avec les autres. 68

69 Il existe d'autres avantages liés à l'utilisation des services Web dans l implémentation des réseaux actifs: 1.Au niveau de l'implémentation: La définition des routines de traitement de paquets comme étant des services web peut simplifier leur mise en œuvre. Ces routines de traitement de paquets peuvent être situés n'importe où, appartenir à n'importe qui, s'exécuter sur n'importe quelle plate-forme, être développées avec tout type d'outils et ne sont liées à aucun langage de programmation. Les applications actives (AA) peuvent utiliser ces services selon leurs besoins et à travers les conventions standards des services Web, elles les découvrent grâce à UDDI qui est l'annuaire des services web, elles peuvent négocier leur utilisation dynamiquement, elles peuvent les choisir et les exécuter en temps réel. 2.Au niveau de la sécurité: Les standards existants permettent de chiffrer les messages qui transitent dans le canal de communication (au moyen de SSL sur HTTP) ou bien de chiffrer le canal lui-même (à l'aide du standard Internet Protocol Security, ou IPSec), ce qui assure la confidentialité des paquets actifs échangés. Mais dans ce cas il s'agit des scénarios "tout ou rien". Les spécifications des services web permettent d'améliorer la sécurité granulaire des systèmes basés sur le protocole SOAP. Elles définissent l'aptitude à échanger des justificatifs d'identification (par exemple, les certificats X.509 ou les tickets Kerberos), de vérifier l'intégrité d'un message et de mettre en vigueur la confidentialité de ce message. D'autre part, un service Web s'exécute comme étant un processus isolé ce qui permet de protéger le réseau et d'éviter l'effondrement de son architecture active si un service s'arrête brusquement. De plus chaque service web est un processus client qui fait accès aux données définies uniquement dans son propre espace d'adressage ce qui permet d assurer la protection de la mémoire. 3.L'extensibilité des réseaux actifs est assurée facilement par les services Web : A partir d un service Web, on peut facilement construire des services ou des applications web dérivés des précédents. En effet, le point crucial des services Web est l'imperméabilité entre les clients et les serveurs qui ignorent tout de l'implémentation, dite privée, des opérations respectives de leurs correspondants et ne se connaissent qu'à travers des descriptions publiques Architecture de ASWA Un nœud actif ASWA est organisé en conformité avec la spécification DARPA. Il définit 3 composantes majeures : une composante système d exploitation (NodeOS), une composante environnement d exécution (EE), et une composante applications actives (AA). Ces composantes interagissent ensemble pour assurer le déploiement et l exécution des Applications Actives. La table suivante décrit la pile des éléments constituant le nœud ASWA ainsi que leur correspondance avec la spécification DARPA. Noeud Actif [23] ASWA AA Services Web applicatifs dynamiques EE Services Web fonctionnels prédéfinis NodeOS Serveur d'application et Serveur Web Dans le but d avoir rapidement un prototype, c est le Serveur d'application et le Serveur Web qui fourniront les fonctionnalités de la composante NodeOS, sachant qu une implémentation qui respecte mieux les spécifications données par devrait être fournie dans 69

70 le cadre d'un travail futur. Pour garder une compatibilité avec les réseaux classiques, les nœuds actifs seront déployés seulement sur quelques points spécifiques du réseau. Ainsi, nous aurons à gérer un réseau formé de 2 plans principaux : un plan actif, et le plan transport. Dans ce papier, nous essayons de contrôler et de sécuriser le déploiement de code en définissant un troisième plan de contrôle actif. Cette architecture en 3 plans, décrite à la Figure 2 réalise ces buts par l introduction de deux nouveaux types de nœuds, les nœuds de contrôle et le nœud d administration. En faisant donc un regroupement des nœuds suivant leurs fonctionnalités nous obtenons : Un plan de contrôle actif. Ce plan regroupe les nœuds de contrôle et un ou plusieurs nœuds d administration. Le nœud d administration est responsable de la configuration et de l administration des nœuds de contrôle, ainsi que de l enregistrement de nouveaux services. Tandis que les nœuds de contrôle sont responsables du contrôle et du déploiement de code. Le nœud d administration agit de même en tant qu autorité de certification, et distribue les certificats aux nœuds de contrôle avec lesquels il a une relation de confiance, pour que ces nœuds puissent signer le code avant de le déployer. Ces nœuds communiquent ensemble pour avoir une vue globale du réseau et des services supportés. Un plan actif : Ce plan regroupe les nœuds actifs. Le NodeOS de ces nœuds offre les primitives de base permettant l accès aux ressources locales du nœud. L EE permet le traitement des données transmises par accès aux champs données et adresses des capsules, ainsi qu en consultant les tables de routage ou en appliquant les fonctions de routage pour router les capsules suivant leur destination. Ces nœuds communiquent avec les nœuds de contrôle. Le plan transport : Ce plan regroupe les nœuds qui transportent les capsules sans aucun traitement. La notion de domaine fut introduite au sein de cette architecture, pour réaliser une meilleure structuration. Chaque domaine regroupe un nœud de contrôle et plusieurs nœuds actifs. Chaque nœud de contrôle est autonome dans son domaine; Il gère et contrôle les nœuds actifs de son domaine. Chaque nœud de contrôle met à jour une table de routage permettant d acheminer un flot de capsule d un service donné dans un domaine ou vers un autre domaine suivant le meilleur chemin associé à ce service. De plus, un nœud de contrôle d un domaine A peut demander au nœud d administration un code de service non présent au niveau de son cache. Le nœud d administration routera alors la requête vers le nœud de contrôle le plus proche d un autre domaine en possession de ce code. Nœud d'administration Plan de Contrôle Nœud de contrôle Nœud Actif = AA EE NodeOS Plan Actif Plan Transport Domaine A Plan Actif Plan Transport Domaine B Réseau Actif Figure 2 : Architecture proposée 70 Réseau Actif Contrôlé 7.4. Implémentation de ASWA Les services Web reposent sur une architecture orientée services ( Service Oriented Architecture ou SOA) où trois entités principales rentrent en jeu, comme le montre la Figure 3:

71 - Des consommateurs de services - Des fournisseurs de services - Des référenceurs de services. Référenceur de services Annuaire UDDI 2- Recherche 3- Référence 1- Enregistrement client Consommateur de service 4- Demande du contrat 5- Envoi du contrat WSDL 6- Appel de service 7- Service sous forme d'un message SOAP Figure 3: Architecture SOA service Fournisseur de service Cette architecture peut parfaitement s'adapter à notre proposition de contrôle du réseau actif. En effet, le serveur d'annuaire UDDI permet d'enregistrer les nouveaux services, il peut donc jouer le rôle d'un nœud d'administration. Un nœud de contrôle ne serait alors qu'un fournisseur de services, tandis qu'un nœud actif serait le consommateur de ces services. Pour implémenter cette architecture notre choix s'est fixé sur la plate-forme.net de Microsoft qui est assez complète en terme de gestion de la sécurité (authentification et autorisation réalisée simplement par traitement de l enveloppe SOAP), bien que nous avions la possibilité d'utiliser indifféremment des API sous Solaris, Linux, ou autres Format du paquet Le format de notre paquet actif est le suivant: E N T E T ProtocolID E Entête commune source destination chemin Ce paquet présente deux parties: - Entête et - Données Entête Spécifique à chaque AA (Dépend du ProtocolID) Figure 4: Format d'un paquet Données La partie entête est divisée en deux: - Une entête commune qui contient: o Le protocolid représentant le type de l'application active associée à ce paquet, o l'adresse source qui n est autre que l adresse du nœud contenant les données ou le service actif à déployer, o l'adresse destination qui doit éventuellement retourner un résultat au nœud source et o le chemin qui définit l ensemble des nœuds à traverser par ce paquet, ceci sous la forme d'un tableau d'adresses IP. - Ainsi qu'une entête spécifique à chaque Application Active. L'utilité de cette partie de l'entête sera vue en détail dans le cas de l'application du pare-feu actif à la section

72 Ce paquet actif sera encapsulé dans la partie <Body> d'un message SOAP qui sera transporté sur le réseau via le protocole http, comme le montre bien la Figure 5. <!-- Entête http --> POST /iroute/iroute.asmx HTTP/1.1 Host: desktob Content-Type: text/xml; charset=utf-8 Content-Length: 10 SOAPACTION: <!-- Enveloppe SOAP définie en XML --> <?xml version="1.0" encoding="utf-8"?> <soap: Envelope xmlns:xsi=" xmlns:xsd=" xmlns:soap=" <soap:header> <!-- Gestion de sécurité et autres --> </soap:header> <!-- champs du paquet actif --> <soap:body> <Fwd xmlns=" <!-- Entête du paquet actif --> <!--Entête commune --> <ProtocolID>ProtocolIDHere</ProtocolID> <source>sourceaddresshere</source> <destination> destinationaddresshere</destination> </soap:body> <path> </path> <string>routeaddress1here</string> <string>routeaddress2here</string> <!-- --> <!--Entête spécifique à chaque AA --> <!-- Données du paquet actif --> <data>datahere</data> </Fwd> </soap:envelope> Figure 5: Format XML du paquet actif encapsulé dans un message SOAP transporté via http 72

73 Nœud d'administration Le nœud d administration n est autre qu un nœud actif qui accepte l'enregistrement de tous leurs services supportés par les nœuds de contrôle. Ceci est réalisé automatiquement à l'aide d'un service de registre qui fournit des renseignements concernant les différents Services Web disponibles, tels que le nom de la société qui héberge le service, l'url (Universal Resource Locator) du site Web de cette société ainsi que l'emplacement du fichier WSDL grâce auquel il pourra déterminer les détails fonctionnels de ce service Web XML. Ce nœud fonctionne de même en tant qu autorité de certification, dont la clé publique doit être distribuée par face à face à tous les nœuds actifs du réseau voulant recevoir du code authentifié. Ce nœud serait donc d une part responsable de la réception des requêtes d enregistrement provenant des nœuds de contrôle selon la Figure 3, et joue d autre part le rôle d'un relais de requêtes de demande de code entre les différents nœuds de contrôle dans des domaines différents : Quand le nœud d administration reçoit une requête de demande de code d un nœud de contrôle, il détermine l adresse du nœud de contrôle ayant le code du service requis, et route la demande vers ce dernier (Figure 6). Figure 6: Déploiement inter-domaine du code actif Nœud de contrôle Le nœud de contrôle est introduit au niveau de cette architecture pour contrôler la distribution de code dans le réseau. Un nœud de contrôle supporte au niveau de son EE telle que le montre la Figure 7 un service Web de contrôle de déploiement ainsi qu'un service Web de contrôle de routage. Le service de contrôle de déploiement s'occupe du déploiement du code des services web actifs ainsi que du déploiement de fichiers de configuration, en particulier les ACLs (Access Control Lists). Tandis que le service de contrôle de routage est chargé de gérer tous les aspects de routage des requêtes. C'est un service Web dont le rôle est de sauvegarder la topologie de tous les réseaux du domaine auquel il appartient et de répondre aux requêtes des nœuds actifs dans leur recherche d'un "nœud suivant". 73

74 Le nœud de contrôle doit pouvoir gérer plusieurs situations : Déclarer tous les services actifs qu il supporte selon le schéma de la Figure 3. Répondre aux requêtes de demande du code de services actifs provenant d un nœud d administration en envoyant le code correspondant au nœud de contrôle d un autre domaine qui en a besoin. Répondre seulement aux requêtes authentifiées et autorisées provenant des nœuds actifs de son domaine. Le noeud d administration n est autre qu un nœud de contrôle particulier, pouvant supporter les mêmes composantes au niveau de son EE. Dans ce cas le service de contrôle de routage sera chargé de gérer et de sauvegarder la topologie de tous les domaines du réseau. Ainsi le nœud d'administration pourra fonctionner en tant que relais d aiguillage de requêtes de demande de code, ou de demande d exécution inter-domaines de services, grâce à son service de contrôle de déploiement. Application Active Environnement d'exécution Service Web de Contrôle de Routage DB de Routage DB des ACL DB des Services Service Web de Contrôle de Déploiement Gestion D'EE Node OS Threads Blocs mémoire Canaux Exécution Mémoire Communication Fichiers Stockage Figure 7: Architecture d'un Nœud Actif de Contrôle Nœud actif Un nœud actif n'est autre qu'un nœud supportant un ou plusieurs services Web actifs. L'environnement d'exécution d'un nœud actif supporte les trois services Web suivants: 1. Un service Web de traitement de paquets dont le rôle est de recevoir les paquets, et de leur faire subir un certain traitement, qui peut être soit de les livrer à l application active concernée soit simplement de les livrer au service de routage. 2. Un service Web de routage de paquets dont le rôle est de router les paquets vers le nœud suivant après les avoir reçus à partir de la composante de traitement de paquets. Ce routage peut se faire selon plusieurs modes décrits au niveau de la section Un service Web d installation de code ou de fichiers qui permet au nœud actif la réception et l installation dynamique de services actifs sous forme d'applications Actives (AA) ou de nouvelles composantes pour l'environnement d'exécution (EE), ou 74

75 même l installation locale de fichiers de configuration nécessaires au fonctionnement d'une application active (voir section 7.4.6). Application Active Paquet livré à une AA Fichier de Configuration vers une AA Service sous forme d'une AA Environnement d'exécution Service Web de traitement de paquets Service Web de Routage dynamique Service EE à installer Service d installation Paquet reçu Fichiers de configuration Services Node OS Threads Blocs mémoire Canaux Exécution Mémoire Communication Fichiers Stockage Gestion D'EE Figure 8: Architecture d'un nœud actif Fonctionnement du Service de routage dynamique d un nœud actif Le service de routage dynamique présent au niveau du EE d un nœud actif peut fonctionner suivant les modes suivants: Le mode «ROUTAGE INTÉGRÉ» où les requêtes sont routées d un nœud actif au suivant en se basant sur le contenu du champ «chemin» intégré à l entête commune du paquet actif. Le mode «ROUTAGE PROGRESSIF» où chaque nœud actif envoie une requête au nœud de contrôle pour connaître le nœud actif suivant vers lequel il faut router le paquet. Le mode «ROUTAGE SEQUENTIEL» Chaque Nœud actif route le paquet suivant la table de routage se trouvant dans le fichier Referral Cache (WS-ROUTING voir «WSE») C est l application cliente initiatrice de l exécution de l application active qui doit : - fixer le mode de fonctionnement du routage des paquets, - préciser l application active à exécuter sur chaque noeud, - et préciser le nœud de départ et le nœud destination, ce qui permettra de spécifier le chemin tout au long duquel doit s exécuter cette Application Active. 75

76 Routage dans le mode «INTÉGRÉ» Dans ce mode, le premier nœud actif qui reçoit un paquet, demande au nœud de contrôle le chemin complet lui permettant d atteindre sa destination (Figure 9). Un nouveau paquet sera construit. Il contiendra le chemin complet qui sera suivi par le paquet actif jusqu à atteindre le nœud destinataire. Figure 9: Routage intégré Routage dans le mode «PROGRESSIF» Dans ce mode, à la réception d'un paquet, chaque nœud actif envoie au nœud de contrôle, une requête de demande du nœud suivant sur le chemin à suivre (Figure 10). Dans ce cas, le champ «chemin» du paquet construit au niveau de chaque nœud actif contiendra une seule adresse qui est celle du nœud suivant. Figure 10: Routage progressif Nœud de contrôle Un Nœud de contrôle contient un service Web,comme on a déjà mentionne dans 7.5.3, qui présente 2 méthodes : 76

77 «GetFullRoute» qui reçoit un tableau contenant les adresses sources et destinations et rend un tableau contenant les url de tous les nœuds par lesquels doit traverser le paquet. (utiliser avec le mode intégré). «GetRoute»de même mais ici elle rend l url du premier nœud intermédiaire seulement. (utiliser avec le mode progressif) Routage dans le mode «SEQUENTIEL» Dans ce mode, à la réception d'un paquet, chaque nœud actif regarde dans sa table de routage «Referal cache» pour trouvez le chemin suivant lequel doit passer le paquet pour arriver a sa destination, (voir WSE WS-Routing) Type de Routeurs Les Routeur légers :Ils sont formes d un fichier Web.config.Ces routeurs ne font que regarder dans l entête du paquet SOAP pour trouver le nœud suivant. Les Routeurs Referral:Ils sont formes des fichiers Web.config et ReferralCache.Ces Routeurs possède une table de routage qui se trouve dans le referral. Les Routeurs Personnalises:Comme le referral mais ils possèdent en plus un fichier RoutingHandler.cs.Ce dernier peut modifier le traitement d un paquet avant de l envoyer au nœud suivant Fonctionnement du Service d installation de code et de fichiers d un nœud actif La demande de déploiement du code d un service Web actif sur un nœud est initiée par une application cliente à partir de l'interface Web de la Figure 11. L accès à cette interface 77

78 se fait à partir du nœud de contrôle du domaine et est permis à un administrateur après un processus de login. Après l étape de l authentification, l initiation de la demande n est acceptée que si cet administrateur en a bien l autorisation. Dans ce cas une requête SOAP précisant l application active à déployer est envoyée au service d «installation de code» du nœud actif, qui téléchargera le service demandé à partir du nœud de contrôle en possession du code correspondant. Notons que chaque nœud de contrôle possède au niveau de son cache un ensemble de services actifs qui y sont initialement stockés. L administrateur du réseau a la possibilité d ajouter ou de supprimer de façon très simple des Applications Actives au niveau de ce cache. Deploy Web Service Remotely: Remote Site (web service URL) Web Service File Service Name Get Service From Another Control Node Get Service From Local Disk (Current Control Node) Configuration File Get Config. File From Another C ontrol Node Get Config. File From Local Disk (Current Control Node) Deploy Status: Ready Figure 11: Page Web du déploiement dynamique d un service actif Les informations devant être fournies par l administrateur à partir de l'interface Web de la Figure 11 sont les suivantes: L adresse du «service d installation» du nœud actif sur lequel doit se faire le déploiement. L endroit où se trouve le service Web. Il faut distinguer le cas où c'est le nœud de contrôle du même domaine qui est en possession du code, ou bien celui d'un autre domaine. Dans ce dernier cas, la requête doit passer par le nœud d administration selon la Figure 6. Le nom du service Web à installer. Dans le cas où le service demandé se trouve sur un nœud de contrôle d'un autre domaine, c'est l'url absolue du service qui doit être saisie. Dans certains cas, un fichier de configuration associé au service Web est nécessaire à son fonctionnement. Le nom de ce fichier devra être précisé pour être de même téléchargé. Nous donnons le cas de l'installation des fichiers de règles de filtrage et des ACLs utilisés par l'application active pare-feu dont le fonctionnement sera détaillé dans la section 7.6. Une fois les routines de traitement personnalisé injectées sur les nœuds du chemin construit par le service de routage dynamique, les utilisateurs pourront envoyer leurs capsules dans ces nœuds programmables, de la même façon qu avec les réseaux classiques. 78

79 Quand une capsule arrive à un nœud, elle est reçue par la composante NodeOS qui la passe à la composante EE pour la traiter et la router vers le nœud «suivant». Nous avons choisi ce mode de déploiement de code où le mécanisme de chargement et d exécution de code sont séparés, pour pouvoir mieux contrôler le chargement de code, qui peut être restreint dans notre cas à des utilisateurs autorisés suivant une liste de contrôle d accès bien définie au niveau de chaque nœud de contrôle, comme nous le verrons dans la section Implémentation de la sécurité dans ASWA Dans cette section nous discutons les problèmes de sécurité liés à l utilisation d un réseau actif. Comme les réseaux actifs sont beaucoup plus flexibles que les réseaux passifs, le nombre des questions et de problèmes de sécurité qu on devrait se poser et résoudre sont de loin plus nombreux. Les paquets actifs peuvent mal utiliser les nœuds actifs, les ressources réseau ainsi que d autres paquets actifs. De même que les nœuds actifs peuvent mal utiliser les paquets actifs. Les problèmes de sécurité des réseaux actifs sont déjà bien identifiés. Protéger donc les nœuds et les paquets dans un environnement aussi flexible est une tâche difficile mais nécessaire. Le modèle de sécurité de ASWA permettra d assurer les faits de base suivants : Un nœud de contrôle doit s être authentifié par du Face à Face auprès du nœud d administration pour que ce dernier accepte son enregistrement. En conséquence le nœud d administration fournira un certificat à ce nœud de contrôle et mettra à jour la liste des services supportés à partir de la liste des services de ce nœud de contrôle. Le code de chaque application active déployée sera signé en utilisant le certificat délivré par le nœud d administration avant son envoi. Quand un nœud actif reçoit ce code à partir d un nœud de contrôle, il doit vérifier la signature du nœud de contrôle en vue d authentifier la source du code reçu. La vérification de la signature est possible à travers la réception du certificat dans l entête du message SOAP avec le code signé Exemple d une Application Active: Un pare-feu intelligent et distribué Une approche importante des réseaux actifs est de permettre au comportement des périphériques spécialisés du réseau d être altérés par les utilisateurs. L exemple classique peut être le pare-feu intelligent. Les pares- feu effectuent déjà du filtrage basé sur les données d une application lors du traitement de leurs paquets. Plutôt que d être figés, ce filtrage pourrait être contrôlé par les utilisateurs du domaine protégé pour permettre un contrôle fin des services exportés. Pour valider notre plate-forme, nous avons développé un «pare-feu intelligent» sous forme d une application active. Ce service ainsi qu une liste de contrôle d accès doivent être déployés à partir du nœud de contrôle, sur chaque nœud actif du domaine. Si nécessaire, la liste de contrôle d'accès peut être re-déployée sur tous les nœuds actifs du domaine. Un autre scénario consisterait à déployer indépendamment sur chaque nœud actif une liste de contrôle d accès différente personnalisée. 79

80 Une fois le pare-feu actif installé, il pourra être sollicité par le service de routage de l environnement d exécution pour effectuer le filtrage des paquets reçus Définition d un «XML SCHEMA» pour la validation des Listes de Contrôle d'accès Comme déjà expliqué dans le paragraphe précédent, le filtrage des paquets se fait en se basant sur des listes de contrôle d accès (ACLs) déployés sur les différents nœuds actifs. Un «schema XML» permettant de caractériser les règles de filtrage par groupe d utilisateurs a été définie. Une ACL déployée sur un nœud actif ne serait en fait qu un fichier XML validé par ce «schema», il sera dit "instance" de ce «schema». Ce «XML SCHEMA» est organisé de la façon suivante : L élément «aclroot» est l'élément racine du «XML schema». C'est une séquence d éléments «acl». Chaque élément «acl» est associé à un groupe d utilisateurs. Il définit le nom du groupe «usergrp» et les règles de filtrage «usergrpacl» associées à ce dernier. Les règles de filtrage «usergrpacl» définies au niveau de notre schema permettent d'effectuer un filtrage selon: le contenu du paquet («data»), la source de ce paquet, sa destination, le next Hop, le protocole (TCP, IP, UDP, ICMP), le numéro de port, ainsi que selon un timerange qui détermine la plage horaire où le paquet a le droit de traverser le noeud. A chacun des éléments du «usergrpacl» cités ci-dessus est associé un attribut appelé «action» qui peut prendre les valeurs «allow» ou «deny». Cet attribut définit l action à effectuer au cas où le pare-feu trouve une correspondance entre l entête du paquet reçu et le contenu de cet élément: Soit on permet au paquet de passer (allow), soit ce paquet est rejeté (deny). La Figure 12 suivante est un exemple particulier d un fichier XML d une ACL validé par ce «XML schema», dont le format complet est donné en annexe à la section Dans cet exemple, un group nommé "users" a été défini. On voit bien que dans le cas des paquets marqués au niveau de leur entête comme appartenant à ce groupe, les paquets à destination des adresses et devront être rejetés, de même que les paquets UDP, etc. <?xml version="1.0" encoding="utf-8"?> <aclroot xmlns=" <acl> <usergrp>users</usergrp> <usergrpacl> <destination action="deny"> <destinationaddress> <destinationaddress> </destination> <protocol action="deny"> 80

81 <protocolname>udp</protocolname> </protocol> <port action="deny"> <portnum>4</portnum> <portrange> <fromport>20</fromport> <toport>25</toport> </portrange> </port> <port action="allow"> <portnum>5</portnum> <portnum>6</portnum> <portrange> <fromport>26</fromport> <toport>65535</toport> </portrange> </port> <data action="deny"> <containword>maroun</containword> <containword>rima</containword> </data> <time action="allow"> <timerange> <starttime>16:00:00</starttime> <starttime>19:00:00</starttime> <endtime>17:00:00</endtime> </timerange> <timerange> <endtime>23:00:00</endtime> </timerange> </time> <nexthop action="deny"> <nexthopaddress> </nexthop> <source action="deny"> <sourceaddress> <fromaddress> </fromaddress> </acl> <sourcerange> <toaddress> </toaddress> </sourcerange> </source> </usergrpacl> </aclroot> Figure 12: Fichier XML servant comme ACL 81

82 Une interface Web graphique développée pour faciliter la gestion des ACLs (insertion, modification, suppression et consultation) a été créée pour être utilisée par un administrateur du réseau pour la création et la gestion de tels fichiers Déploiement et mise en œuvre du pare-feu actif Nous avions décrit au niveau de la section l'interface Web qui permet de gérer le fonctionnement du Service d installation de code et de fichiers. C'est cette interface Web (Figure 11) qui sera donc utilisée pour déployer le service Web du pare-feu actif et son ACL. Une fois le pare-feu actif installé, il pourra être sollicité par le service de routage de l environnement d exécution pour filtrer les paquets entrants et sortants en se basant sur les règles de filtrage déployées sur ce nœud actif. Pour être reconnu et traité par notre Application Active, un paquet devra avoir la forme suivante : E N T E T ProtocolID E Entête commune source destination chemin Groupe d'utilisateurs Entête Spécifique au pare-feu protocole port Figure 13:Format d'un paquet du pare-feu actif Le message SOAP encapsulant ce paquet est le suivant : POST /iroute/iroute.asmx HTTP/1.1 Host: desktob Content-Type: text/xml; charset=utf-8 Content-Length: 10 SOAPACTION: <!-- Entête http --> Données <!-- Enveloppe SOAP définie en XML --> <?xml version="1.0" encoding="utf-8"?> <soap: Envelope xmlns:xsi=" xmlns:xsd=" xmlns:soap=" <soap:header> <!-- Gestion de sécurité et autres --> </soap:header> <!-- champs du paquet actif --> <soap:body> <Fwd xmlns=" <!-- Entête du paquet actif --> <!--Entête commune --> <ProtocolID>ProtocolIDHere</ProtocolID> <source>sourceaddresshere</source> <destination> destinationaddresshere</destination> <path> <string>routeaddress1here</string> <string>routeaddress2here</string> <!-- --> </path> 82

83 </soap:body> </soap:envelope> <!--Entête spécifique au pare-feu --> <usergroup>usergrouphere</usergroup> <protocol>protocolhere</protocol> <port>porthere</port> <!-- Données du paquet actif --> <data>datahere</data> </Fwd> Figure 14:Format XML du paquet du pare-feu actif Une fois ce paquet reçu par le service de routage, le fichier ACL sera utilisé pour vérifier si ce paquet, provenant d un utilisateur appartenant à un groupe donné, devra être filtré ou routé vers le nœud suivant, et ceci selon les étapes suivantes: La fonction de filtrage effectue l analyse des balises XML de ce fichier ACL présent sur le nœud, à la recherche du groupe auquel appartient l utilisateur. Une fois le groupe trouvé, les autres champs de l entête du paquet spécifique à l'application active du pare-feu, seront comparés un à un avec les éléments de l ACL correspondant (au niveau du tag «UserGrpAcl»). Dans le cas d une correspondance entre un champ de l entête et un élément, il faut agir en fonction de l attribut «action» de cet élément : Si la valeur de l action est «deny», le pare-feu prépare un message SOAP spécifiant la cause du blocage avant de retourner «FALSE» et bloquer le passage du paquet. Si la valeur de l action est «allow», deux cas se présentent en fonction de la donnée «allowdirectly» : o Si elle vaut «TRUE», il faut alors arrêter le filtrage et permettre au paquet de franchir le nœud. o Si elle vaut «FALSE», il faut continuer la comparaison. Pour tester notre pare-feu, une page Web a été développée pour générer des paquets en vue d être traités par cette application active comme le montre la Figure 15: Generate Packet: User Group Data Source Start Target w w 4.dotnetplayground.com/iroute.asmx w w 4.dotnetplayground.com/iroute.asmx Port 0 Protocol Routing Mode Mode 1 (in this mode the first node gets the full route from the main service and sends it with the paquet) Mode 2 (in this mode each node gets it's next hop from the main service) Go Status: Ready Soap Packet between nodes Soap Packet betwen nodes and main routing service Figure 15: Page Web de génération de paquets 83

84 Cette page web permet de générer des paquets SOAP qui seront routés entre les services Web des nœuds actifs sur un chemin défini entre un nœud de départ (le champ «Start») et une destination (le champ «Target»). Le routage des paquets peut être effectué uniquement dans le cas où les pare-feux installés sur les différents nœuds actifs autorisent le passage de ces paquets en fonction de leurs entêtes (le groupe d utilisateurs, le nœud source des données, le port, le protocole et le temps) et de leurs contenus. L utilisateur a le choix entre deux modes de routage (voir section 7.4.5) : Le premier mode ou le mode intégré (cf. section ) dans lequel le nœud de départ demande au nœud de contrôle le chemin complet entre le nœud courant et le nœud destination qui sera intégré dans chaque paquet. Le deuxième mode ou le mode progressif (cf. section ) dans lequel chaque nœud demande au nœud de contrôle le nœud suivant. Un routage avec succès affichera le message suivant : Status: Packet arrived successfuly Dans le cas d échec, une description de la cause du blocage sera affichée : Status: Protocol Access Denied at node Conclusions L utilisation des services Web dans la modélisation du nœud actif (Composante NodeOS, Composante EE et composante AA) ainsi que dans le chargement dynamique du code des Applications Actives qui se fait à partir d une interface Web et à travers des systèmes et des réseaux hétérogènes, donne à cette approche un aspect innovateur. L architecture de ASWA permet aux Applications Actives d être automatiquement déployés aux nœuds du réseau qui en ont besoin en vue de modifier dynamiquement le comportement de ces noeuds. Aucun consensus n est requis au préalable à propos du type et de la définition de l application active à déployer. ASWA offre la transparence et l interopérabilité vis-à-vis de systèmes et de réseaux hétérogènes. Ceci est assuré par la possibilité de choisir n importe quel langage de programmation au niveau du développement du code ainsi que par l utilisation du protocole SOAP comme protocole de communication. L architecture et l implémentation de ASWA permettent d offrir l interopérabilité avec d autres plates-formes en particulier avec ANTS, par simple composition. Ceci fera l objet d un travail futur. Le développement de la plateforme ASWA fut effectué sur Windows XP en tenant compte de la portabilité sur d autres plateformes. La portabilité ainsi que l interopérabilité avec Linux devront être testées. 84

85 8.1. Introduction 8. Proposition ASWA est une plateforme de réseau actif ce qui implique elle possède les mêmes problèmes de sécurité discute dans la partie 2-reseau actif. Pour cela on a constate que les messages SOAP qui circulent entre les nœuds, dans le réseau actif aswa, sont transmis en clair ce qui pose un problème au niveau de la sécurité.grâce a WSE, qui nous permet de sécuriser les paquets SOAP, nous avons propose une solution pour ce problème de sécurité Plan de notre proposition et Secr Paquet SOAP Authentifier et et Secr Paquet SOAP en texte clair Paquet SOAP en texte clair Figure 1 85

86 Dans notre proposition on a décide de créer deux serveurs de sécurité, l un crypte le message et s authentifie auprès du serveur de décryptage qui a son tour décrypte et envoie le paquet en texte clair vers le service destinataire.tous cela est fait sans l intervention du client ni du service destinataire. Deux méthodes se présentent : Méthode sans routage. Méthode avec routage Méthode sans routage. Dans cette méthode le paquet est transmis directement vers le serveur de cryptage, ce qui implique le paquet est destine vers le serveur de cryptage. A l arrivée du paquet au serveur de cryptage il crypte le contenue du body grâce au secret partagé avec le serveur de décryptage, s authentifie grâce a un username et un mot de passe qui se trouve dans le header ensuite il envoie se paquet destine vers le serveur de décryptage. A l arrive de ce paquet au serveur de décryptage, ce dernier vérifie l authentification et décrypte ensuite le contenue du body puis envoie un paquet SOAP destine au service destinataire qui contient le body en texte clair. Pour tester notre proposition on a créer un simple service qui rend le texte envoyer par le client dans une phrase «LE TEXT:(.)EST ARRIVE SANS PROBLEME».Notre Client possède une interface graphique (page HTML, voir figure 2) 86

87 Figure 2 On remarque deux Texte Box,le premier qui contient le texte a envoyé par le client et le deuxième contient le texte envoyé par le service destinataire comme réponse. On remarque aussi les informations propre au pare-feu intelligent et dont on peut les modifies pour tester les pare-feu. Pour Voire ce qui ces passer on va détailler les paquets sortante au niveau de chaque nœud,c est le rôle des OUTPUT TRACE qui contiennent les paquets SOAP sortante de même pour les INPUT TRACE mais ici pour les paquets entrante. Comme on a déjà dit, On remarque dans la figure 3 que le paquet envoyé par le client est destine vers et que le body contient le texte «TEST» en clair. On remarque aussi le Filter Header qui contient les informations sur le protocole le numéro de port etc. Nécessaire pour les pare-feu. - <soap:envelope xmlns:soap=" xmlns:xsi=" xmlns:xsd=" <soap:header> - <SecHeader xmlns="

88 Figure 3-paquet SOAP envoyé par le client vers service de cryptage 88

89 - <soap:envelope xmlns:soap=" xmlns:xsi=" xmlns:xsd=" - <soap:header> - <FilterHeader xmlns=" <DestinationMask xmlns="">destmask</destinationmask> <Protocol xmlns="">tcp</protocol> <Port xmlns="">1245</port> <SourceMask xmlns="" /> <From xmlns="">saad COMPUTER</From> <DestinationPort xmlns="">2345</destinationport> </FilterHeader> - <wsrp:path soap:actor=" soap:mustunderstand="1" xmlns:wsrp=" <wsrp:action> <wsrp:to> <wsrp:id>uuid:f27bc5cd-b6ff-43f b6dcb77c0db</wsrp:id> </wsrp:path> - <wsu:timestamp xmlns:wsu=" <wsu:created> t15:08:29z</wsu:created> <wsu:expires> t15:08:35z</wsu:expires> </wsu:timestamp> - <wsse:security soap:mustunderstand="1" xmlns:wsse=" - <wsse:usernametoken xmlns:wsu=" wsu:id="securitytoken-7ee1e27b-f85f-4a8e-acfc "> <wsse:username>saad</wsse:username> <wsse:password Type="wsse:PasswordText">rabih</wsse:Password> <wsse:nonce>nsaowjj4z9ljeqe7uljjca==</wsse:nonce> <wsu:created> t15:08:30z</wsu:created> </wsse:usernametoken> - <xenc:referencelist xmlns:xenc=" <xenc:datareference 5dca0e9e6830" /> URI="#EncryptedContent-e511fe3a bd33-89

90 Figure 4-Header du Paquet SOAP vers le serveur de Décryptage. A la sortie du serveur de cryptage le paquet SOAP est destine vers le serveur de décryptage On remarque aussi le usernametoken ajouter au header qui contient le username et le mot de passe (dans notre exemple on a transmis les usernametoken en texte claire juste pour pouvoir les voire, sachant qu on peut -<soap:body les transmettre hacher pour plus de sécurité.). Pour le Body qui est crypter voir figure-5 xmlns:wsu=" wsu:id="id-af3a03e4-c472-4ab1-aa74-34d14e257174"> - <xenc:encrypteddata Id="EncryptedContent-e511fe3a bd33-5dca0e9e6830" Type=" xmlns:xenc=" <xenc:encryptionmethod Algorithm=" /> - <KeyInfo xmlns=" <KeyName> </KeyName> </KeyInfo> - <xenc:cipherdata> <xenc:ciphervalue>rkw1zrp8fwkugy9+bxmccxxdin9kyueurjxaf9svhmyf9yd +2h0vj7IFx6LynZnF5dnP3HfWPXuTanNIBiujywtGk58f+FkZszIb5iwm+g8=</xenc:Ci phervalue> </xenc:cipherdata> </xenc:encrypteddata> </soap:body> Figure 5-Body crypter du Paquet SOAP vers le serveur de Décryptage. -<soap:envelope xmlns:soap=" xmlns:xsi=" xmlns:xsd=" - <soap:header> - <SecHeader xmlns=" <Sec>true</Sec> </SecHeader> -<wsrp:path soap:actor=" soap:mustunderstand="1" xmlns:wsrp=" <wsrp:action> <wsrp:to> <wsrp:id>uuid:3d2c2b31-9ec b415-5b4c22bf0fea</wsrp:id> </wsrp:path> -<wsu:timestamp xmlns:wsu=" <wsu:created> t15:30:28z</wsu:created> <wsu:expires> t15:35:28z</wsu:expires> </wsu:timestamp> </soap:header> - <soap:body> - <HelloWorld xmlns=" <name>test</name> </HelloWorld> </soap:body> 90

91 Figure 6- Paquet SOAP décrypter et envoyer vers service destinataire Au niveau du serveur de décryptage en remarque dans la figure 6 que le paquet est destine au service destinataire On remarque aussi le body qui contient le texte «TEST» qui est le texte envoyé initialement par le client Comment ça marche? Au niveau du serveur de cryptage : On doit utiliser dans notre service des fonctionnalités qui se trouve dans des classes prédéfinies dans la librairie des classes,pour cela on doit les importer: using Microsoft.Web.Services; using Microsoft.Web.Services.Security; using System.Web.Services.Protocols; using System.Security.Cryptography; using System.Security.Cryptography.Xml; Pour créer la clé partage on doit créer une instance de la classe EncryptionKey qui se trouve sous «Microsoft.Web.Services.Security.EncryptionKey». Pour cela on crée une méthode appeler GetEncryptionKey qui retourne une clé secrète en utilisant l algorithme DES (Triple Data Encryption Standard).Cette méthode est décrit dans la figure 7. private EncryptionKey GetEncryptionKey() { SymmetricAlgorithm algo = new TripleDESCryptoServiceProvider(); //définie une clé secret de 128 bit cette cle doit être le //même au niveau du serveur de décryptage byte[] keybytes = { 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 1, 12, 13, 14, 15, 16 }; 91 //définie le vecteur initiale pour l algorithme byte[] ivbytes = { 1, 2, 3, 4, 5, 6, 7 };

92 Figure 7-methode EncryptionKey Cette méthode renvoie la clé secrète mais pour crypter le message avec cette clé il faut : Cree la clé secret,en appellant la méthode précédente: EncryptionKey key = GetEncryptionKey(); Spécifier que le message SOAP doit être crypté a l aide de la clé précédente EncryptedData enc = new EncryptedData(key); requestcontext.security.elements.add(enc); Spécifier le temps de vie maximale du message SOAP pour diminuer le chance de retransmettre se paquet par un intermédiaire. requestcontext.timestamp.ttl = 60000; Pour ajouter l authentification au message SOAP on doit ajouter un usernametoken Pour cela on doit : Cree une instance de la classe UsernameToken qui spécifie le username, le mot de passe et comment est transmis le mot de passe (texte claire ou hacher) : UsernameToken usertoken = new UsernameToken(username,password2, PasswordOption.SendPlainText); Puis ajouter ce usernametoken au header du message SOAP : 92

93 requestcontext.security.tokens.add(usertoken); Au niveau du serveur de décryptage : En importe Les mêmes classes importées au niveau du serveur de cryptage. A l arrive du paquet SOAP crypter au serveur de décryptage,ce dernier va regarder dans son DecryptionKeyProvider, ce trouvant sous microsoft.web.services.security, qui contient les clés de décryptage.pour cela on va modifier cette classe on créant une instance appeler DecryptionKeyProvider de cette classe qui contient la même clé secrète partagée avec le serveur de cryptage voir figure 9. Mais on doit indiquer au service ou se trouve la nouvelle classe qui contienne les clés pour cela on indique dans le fichier Web.Config,qui contient toutes les configurations nécessaires au service Web pour marcher,le nom du fichier qui contient cette classe dans notre cas «SymCrypt» voir figure 8. <security> <decryptionkeyprovider type="symcrypt.decryptionkeyprovider, SymCrypt" /> <passwordprovider type="symcrypt.passwordprovider,symcrypt" /> / Figure 8-Modification ajouter au fichier Web.Config. public class DecryptionKeyProvider : IDecryptionKeyProvider { public DecryptionKey GetDecryptionKey(string algorithmuri,keyinfo keyinfo) { foreach (KeyInfoClause 93 clause in keyinfo) { if (clause is KeyInfoName )

94 Figure 9-classe DecryptionKeyProvider. De même pour le PasswordProvider qui contient les username et les mots de passe voir figure 10.Pour les configurations ajoutées au fichier Web.config voir figure 8.. public class PasswordProvider : IPasswordProvider { public string GetPassword(UsernameToken username) { if (username == null) throw new ArgumentNullException(); string pass1; if (username.username == ("saad")) { string pass = ("rabih"); return pass;} else return pass1 = ("password"); Figure 10-classe PasswordProvider 94

95 8.4. Méthode avec routage Avec cette méthode, le paquet est destine vers le service destinataire directement mais, grâce a WS-Routing, on ajoute une route «Via (a travers)» qui indique un nœud intermédiaire (le serveur de cryptage).ce dernier prend tout le message SOAP reçu, le crypte est le met dans un autre paquet SOAP destine vers le serveur de décryptage, en ajoutant une nouvelle route intermédiaire. Au niveau du serveur de décryptage, le paquet sera décrypter et envoyer vers le service destinataire. Dans la figure 11 on peut remarquer la destination : « qui représente l adresse du service destinataire.grâce a WS-Routing on a pu ajouter le routeur intermédiaire : « qui représente le serveur de cryptage, en ajoutant au niveau du client un fichier referralcache voir figure 12 qui est, comme on a déjà dit, une table de routage. <soap:envelope xmlns:soap=" xmlns:xsi=" xmlns:xsd=" <soap:header> <SecHeader xmlns=" <Sec>true</Sec> </SecHeader> <FilterHeader xmlns=" <DestinationMask xmlns=""> </destinationmask> <Protocol xmlns="">sec</protocol> <Port xmlns="">2365</port> <SourceMask xmlns="">654</sourcemask> <From xmlns=""> <DestinationPort xmlns="">2365</destinationport> </FilterHeader> <wsrp:path soap:actor=" soap:mustunderstand="1" xmlns:wsrp=" <wsrp:action> <wsrp:to> <wsrp:fwd> <wsrp:via> </wsrp:fwd> <wsrp:id>uuid:913bfa1b-38f b92b-062b9b42fb02</wsrp:id> </wsrp:path> <wsu:timestamp xmlns:wsu=" <wsu:created> t11:15:43z</wsu:created> <wsu:expires> t11:20:43z</wsu:expires> </wsu:timestamp> </soap:header> <soap:body> <HelloWorld xmlns=" <name>test</name> /H ll W ld 95

96 Figure 11-Message envoyer vers service destinataire <r:referrals xmlns:r=" <r:ref> <r:for> </r:for> <r:if /> <r:go> </r:go> <r:exact> <r:via> <r:refid>uuid:bf5a7d9e-7df3-43c6-a25a-1503e695612b</r:refid> / f Figure 12-Fichier referralcache. A l arrive du paquet au niveau du serveur de cryptage, il est route vers le serveur de décryptage si le contenue du paramètre «Protocol» dans le header est «Sec», grâce au fichier RoutingHandler voir figure 13, qui nous permet de modifier le chemin d un message avant d être transmis suivant le contenue du header, sinon il est transmis directement vers le service destinataire. Avant d être transmis vers le réseau le paquet est soumis a des filtres, déjà expliquer, pour cela on a crée un CustuomOutputFilter qui nous permet de crypter le message a la sortie du serveur, de la même manière utiliser dans la méthode sans routage (utilisation d un secret partager etc..), si son header contient le paramètre «Protocol=Sec» voir figure 15 public class RoutingHandler :Microsoft.Web.Services.Routing.RoutingHandler { public RoutingHandler() { } protected override void ProcessRequestMessage(SoapEnvelope message, Microsoft.Web.Services.Routing.Path outgoingpath) { XmlElement soapheader = message.header; XmlNodeList matches = soapheader.getelementsbytagname(customheadername, CustomHeaderUri); XmlElement customheader = matches[0] as XmlElement; string protocol=customheader.selectsinglenode(".//protocol").innertext; if (protocol=="sec") { Via premvia = new Via(new Uri(" outgoingpath.fwd.insert(0, premvia); base ProcessRequestMessage(message, outgoingpath); Figure 13-Partie du Fichier RoutingHandler Comme on a déjà mentionné dans la partie sans routage tous les fichiers ajouter au service Web doivent être mentionner dans le fichier Web.Config voir figure 14 <httphandlers> <add verb="*"path="*.asmx"type="serveurdecrypt.routinghandler,serveurdecrypt"/> </httphandlers> <filters> 96 <output><add type="serveurdecrypt.customoutputfilter,serveurdecrypt"/> </output></filters>

97 Figure 14-Modification ajouter au fichier Web.config public class CustomOutputFilter : SecurityOutputFilter { public CustomOutputFilter() { } public override void ProcessMessage(SoapEnvelope envelope) { if(protocol=="sec") { EncryptionKey key = GetEncryptionKey(); EncryptedData enc = new EncryptedData(key); envelope.context.security.elements.add(enc); envelope Context Timestamp Ttl=6000; Figure 15- Partie du Fichier CustomOutputFilter. A la sortie du serveur de cryptage on voit le message initiale crypter entièrement est mis dans un autre message SOAP destine vers le service destinataire : « mais a travers (via) le serveur de décryptage « voir figure 16. <soap:envelope xmlns:soap=" xmlns:xsi=" xmlns:xsd=" - <soap:header> - <wsu:timestamp xmlns:wsu=" <wsu:created> t11:15:43z</wsu:created> <wsu:expires> t11:20:43z</wsu:expires> <wsu:received Actor=" Delay="553"> T11:15:43Z</wsu:Received> </wsu:timestamp> - <wsrp:path soap:actor=" soap:mustunderstand="1" xmlns:wsrp=" <wsrp:action> <wsrp:to> - <wsrp:fwd> <wsrp:via> </wsrp:fwd> <wsrp:id>uuid:913bfa1b-38f b92b-062b9b42fb02</wsrp:id> </wsrp:path> <wsse:security xmlns:wsse=" <xenc:referencelist xmlns:xenc=" 97 soap:mustunderstand="1" <xenc:datareference URI="#EncryptedContent-643e8b54-35df c6ea1bef6b6" /> </xenc:referencelist> </wsse:security> </soap:header> <soap:body xmlns:wsu=" wsu:id="id-dff50159-

98 Figure 16-Message Sortant crypter au niveau du serveur de cryptage. A la réception du message au niveau du serveur de décryptage le paquet est décrypté puis router suivant l adresse destination (service destinataire) comme le montre la figure 17.On remarque aussi a quel temps le message a passer par les serveurs intermédiaire. <soap:envelope xmlns:soap=" xmlns:xsi=" xmlns:xsd=" <soap:header> <SecHeader xmlns=" <Sec>false</Sec> </SecHeader> <FilterHeader xmlns=" <DestinationMask xmlns=""> </destinationmask> <Protocol xmlns="">tcp</protocol> <Port xmlns="">2365</port> <SourceMask xmlns="">654</sourcemask> <From xmlns=""> <DestinationPort xmlns="">2365</destinationport> </FilterHeader> <wsu:timestamp xmlns:wsu=" <wsu:created> t11:15:32z</wsu:created> <wsu:expires> t11:20:32z</wsu:expires> <wsu:received Actor=" Delay="618"> T11:15:33Z</wsu:Received> <wsu:received Actor=" Delay="899"> T11:15:33Z</wsu:Received> </wsu:timestamp> <wsrp:path soap:actor=" soap:mustunderstand="1" xmlns:wsrp=" <wsrp:action> <wsrp:to> <wsrp:id>uuid:cc45ed72-8a1c-4bc9-a540-82c257805cd7</wsrp:id> </wsrp:path> </soap:header> <soap:body> 98

99 Figure 17- Message décrypter et envoyer vers service destinataire Conclusion et perspective. Dans ce projet j ai ajoute a ASWA un service de sécurité, nécessaire pour une plateforme active. Cette proposition a été conçue pour être facile a déployer, car n importe quel client voulant communiquer d une manière sécuriser avec un service destinataire quelconque peut utiliser ce service de sécurité sans aucun changement du code client ou service destinataire, il suffit d ajouter une table de routage au niveau du client. Mener a fin ce projet, a nécessite, une maîtrise du C# du.net et du WSE, L apprentissage des langages XML et SOAP et une vision élargie des réseaux actifs. J espère développer ma proposition pour pouvoir utiliser les certificats X.509 qui sont plus complexe a traite. 9. Références [1] Réseaux Locaux et Internet,des protocoles a l interconnexion, Laurent Toutain,edition HERMES [2] C# et.net,gerard Leblanc,edition Eyrolles. [3] Rima Kilany et Ahmed Serhrouchni, "Using Distributed Component Model for Active Service Deployment", ISCC [4] Active Networks: Applications, Security, Safety, and Architectures [5] David J. Wetherall and David L. Tennenhouse, The ACTIVE_IP option, In the 7th ACM SIGOPS European Workshop. [6] Andrew T.Campbell, Herman G.De Meer,Michael E.Kounavis, Kazuho Miki, John B.Vicente,Daniel Villela in: A Survey of Programmable Networks. [7] Konstantinos Psounis, Stanford University in : Active Networks :Applications,Security,Safety,and Architectures [8] Satyendra Yadav,Sanjay Bakshi in :The Phoenix Framework: A Practical Architecture for Programmable Networks. [9] D.Scott Alexander,Marianne Shaw, Scott M. Nettles and Jonathan M. Smith CIS Departement, University of Pennsylvania in: Active Bridging [10] J. M. Smith, D. J. Farbert, C. A. Gunter, S. M. Nettles,and D. Scott Alexander in : SwithWare:Towards a 21 st Century Network Infrastructure. [11] Michael Hicks, Jonathan T. Moore, D. Scott Alexander, Carl A. Gunter and Scott M. Nettles Departement of Computer and Information Science University of Pennsylvania in : PLANet : An Active Internetwork. 99

100 [12] D.Scott Alexander, William A. Arbaugh, Michael W. Hicks and Jonathan M. Smith University of Pennsylvania in : The SwithWare active Network Architecture. [13] M. Heissenbuttel, T.Braun in : Ants-Based Routing in Large Scale Mobile Ad-Hoc Networks [14] David L. Tennenhouse, Massachusetts Institute of technology in: A Survey of Active Network Research [15] Active Network Architecture, IEEE Network, Spécial issue on Active and Programmable Networks, Vol. 12, [16] Giuseppe Di Fatta, Salvatore Gaglio, Giuseppe Lo re,marco Ortolani in: Adaptive Routing in Active Networks. [17] E. Amir, S. McCanne and R. H. Katz, 'An Active Service Framework and Its Applications to RealTime Multimédia Transcoding', ACM SIGCOMM 98, Vancouver, Canada, Sept. 98. [18] J. E. Van der Merwe, S. Rooney, I. Leslie, and S. Crosby. Thé Tempest - A Practical Framework for Network Programmability. In IEEE Network, Spécial issue on Active and Programmable Networks, Vol. 12, [19] [20] Dan Decasper and Bernhard Plattner, DAN: Distributed Code Cashing for Active Networks, Proc. IEEE INFOCOM '98, San Francisco, CA, 29 March-2 April [21] J. Biswas, A. A. Lazar.Jean-François Huard, Koonseng Lim, Semir Mahjoub, L-F Pau, M. Suzuki, S.Torstensson, W. Wang, and S. Weinstein, Thé IEEE PI 520 Standards Initiative for Programmable Network Interfaces, in IEEE Communications Magazine, Spécial Issue on Programmable Networks, October [22] David J. Wetherall, John V. Guttag and David L. Tennenhouse, ANTS: A Toolkit for Building and Dynamically Deploying Network Protocols, IEEE OPENARCH 98, San Francisco, CA, April [23] Active Networks Working Group, Architectural Framework for Active Networks, at August [24] Huang H., "Active Networks: An overview" [25] Hypertext Transfer Protocol: [26] Simple Mail Transfer Protocol: [27] Web Services Activity: [28] Simple Object Access Protocol: [29] Extensible Markup Language XML (W3C): [30] XML Schema: [31] WSE help://ms.wse.1033/wse/html/gxcongetting_started.htm. [32] Cook C., Pawlikowski K., Sirisena H., "ComAN: A Multiple-Language Active Network Ar chitecture Enable via Middleware", OpenArch'02, New York, NY, June 2002 [33] Microsoft.NET: [34] [35] Galis A., Plattner B., Moeller E., Laarhuis J., Denazis S., Guo H., Klein C., Serrat J., Karetsos G.T., Todd C., "A Flexible IP Active Network Architecture" In the second International Conference on Active Networks (IWAN), edited by H. Yasuda, Volume IEEE, Springer Press, Tokjo Japan, Octobre 2000 [36] Bossardt M., Stadlery Rolf, "Service Deployment on High Performance Active Network Nodes", TIK Technical Report 122, September 2001 [37] BISWAS J., et al., "The IEEE P1520 Standards Initiative for Programmable Network Interfaces", IEEE Communications Magazine, Special Issue on Programmable Networks, October

101 [38] Rima KILANY, Dany ZEBIANE, Michel RIGUIDEL, Ahmed SERHROUCHNI, A Control Architecture for Active Networks, SoftCom2001, 101