des pannes
Les techniques présentées ci-dessus conviennent à des infrastructures dans lesquelles la propagation des défaillances est relativement lente, à des réseaux de petite taille et où les dif- férences de politiques de gestion entre les réseaux ne sont pas prises en compte. En effet, l’utilisation des informations mises à dispositions par les organismes comme les CERT im- pliquent des délais importants et des détections des défaillances non automatisées. Par consé- quent, elles ne permettent pas de lutter efficacement contre les propagations des défaillances
dans les infrastructures de type Internet où les défaillances se propagent très rapidement et où il est impossible de rendre disponibles des informations détaillées sur l’ensemble des ressources matérielles et logicielles du réseau. A titre d’exemple, lors de la diffusion du virus informa- tique NIMDA9 en 2001, une augmentation exponentielle des avertissements BGP avaient été constatée. En deux heures environ, le moniteurrrc00 (moniteur déployé par RIPE NCC10, situé à Amsterdam) enregistre un nombre d’avertissements qui passe de 400 par minute à 200000 par minute. Lors de la panne électrique d’août 2003 aux États-Unis et au Canada, le rapport de l’enquête [63] conduite conjointement par des experts Américains et Canadiens indiquent, parmi les causes du blackout, l’utilisation des données erronées par le centre de coordination MISO (Midwest Independent System Operator) chargé de coordonner 37 centres de contrôle de la région centre-ouest des États-Unis. En effet, le rapport indique que l’utilisation des don- nées non temps réels par ce centre de coordination avait empêché de se rendre compte de la défaillance de la ligne 345kV reliant Stuart et Atlanta de la société Dayton Power and Light.
Ceci a conduit à une estimation fausse de l’état du système et à l’absence d’avertissement à l’opérateur FirstEnergy du risque lié à cette défaillance. Ce manque de communications entre les centres de coordination et les opérateurs a considérablement contribué à la propagation des pannes et à l’écroulement du réseau. Ces exemples de pannes montrent que des outils comme SDX11ou MIT ne sont pas efficaces lorsque la propagation des défaillances est rapide et ne per- met pas la mise en place d’une véritable coordination entre les organismes comme les CERT. Leurs limites sont, entre autres, le manque de synchronisation pour la mise à disposition des informations immédiatement après le début des pannes à cause de l’absence de contrainte tem- porelle sur l’accès aux informations et la mise à jour des bases de données. Ce qui fait que les informations disponibles ne sont pas temps réel ou lorsque ces informations sont disponibles à temps, les opérateurs qui en ont besoin ne sont pas alertés pour qu’ils puissent entreprendre des actions appropriées.
Les techniques basées sur le déploiement des moniteurs ne comportent pas les carences décrites ci-dessus, elles fonctionnent très bien pour un réseau géré par un même opérateur. Mais elles présentent de nombreuses limites dans le contexte des interdépendances à cause du fait qu’elles soient incapables de prendre en compte les différences politiques des différents systèmes autonomes et qu’elles nécessitent de déployer des moniteurs pour chaque entité à superviser de toutes les infrastructures impliquées, ce qui peut être difficile à mettre en œuvre pour des infrastructures qui ont déjà leur propre système de supervision. Pour un réseau de grande taille, les systèmes avec moniteurs comme la technique proposée dans [134] peuvent se révéler trop coûteux car la diffusion des informations par chacun des moniteurs peut en- gendrer un trafic important. Quant à celle exposée dans [58], elle est fondée sur une structure en arbre fixe et permet, donc de réduire le trafic engendré par les moniteurs, mais ne s’adapte pas à la topologie de l’internet et ses changements fréquents. Gossip [141] ne fonctionne pas lorsqu’un grand nombre de composants est défaillant. Durant certaines périodes de congestion, les messages heartbeats peuvent être perdus et il est possible d’avoir des délais importants qui peuvent conduire à une erreur d’interprétation. Enfin, les techniques [37] et [59] sont fondées sur les applications et, par conséquent dépendent fortement de celles-ci. Cette dépendance rend
9http://www.cert.org/advisories/CA-2001-26.html 10http://www.ripe.net/info/ncc/index.html
ces techniques non flexibles et, donc difficilement adaptables à d’autres infrastructures, voire à d’autres réseaux de télécommunications avec de nouvelles applications.
Or, chaque opérateur d’un réseau particulier connecté à l’Internet dispose des moyens tech- niques lui permettant d’assurer la supervision de l’ensemble de son réseau. Ces différents opé- rateurs échangent aussi certaines informations concernant leurs réseaux pour l’acheminement du trafic. C’est le cas des informations sur le routage que certains opérateurs publient sur des sites à accès public fournissant des base de données contenant des informations sur le routage Internet de nombreux réseaux et appelés IRR (Internet Routing Registry) comme RIPE (Réseau IP Européen)12, RADb13et EASYNET14. Ainsi, selon les auteurs de [36], en mai 2001 76, 3%
des 2673 AS enregistrés sur RADb15et 93, 6% des 4492 AS enregistrés sur RIPE publient des
informations relatives aux politiques de routage. Pour la plupart de ces IRR, l’enregistrement pour la publication de ces informations de routage par les opérateurs n’est pas gratuit, chez RADb par exemple le prix varie entre 395 et 495 dollars américain selon que l’opérateur soit à but lucratif ou non.
Par conséquent, il est tout à fait possible qu’un opérateur qui détecte une anomalie dans son réseau puisse avertir ses voisins (réseaux auxquels il est connecté) pour que ces derniers puissent filtrer ce flux par exemple. Le principal défi consiste à définir les règles de cet échange, notamment celles qui concernent le type d’informations échangées, la périodicité et les ac- teurs car il serait difficile, voire impossible que les opérateurs de tous les réseaux de l’Internet échangent des informations entre eux. Toutefois la structure hiérarchique du réseau Internet offre la possibilité de réduire significativement le nombre d’échanges, comme cela se fait avec les échanges BGP. Dans ce contexte, la détection des pannes consiste à concevoir une tech- nique qui permet à chaque opérateur de communiquer l’état de son réseau obtenu à partir de son propre système de supervision à un ou plusieurs collecteurs d’informations issues des dif- férents réseaux impliqués et qui auront une vision générale sur l’ensemble de ces réseaux.
La réutilisation des informations de supervision permet de surmonter l’ensemble des diffi- cultés évoquées ci-dessus, car cette technique ne nécessite pas le déploiement de moniteur pour l’ensemble des entités supervisées des infrastructures impliquées. Ce choix permet, à la fois de réduire le nombre de messages échangés et d’offrir à l’opérateur de chaque réseau de choisir là où sera installé le module qui transmettra les informations au collecteur et de contrôler les informations que ce module doit communiquer au collecteur.