Les vulnérabilités des grands réseaux de télécommunication

02/04/2013
Auteurs :
Publication REE REE 2013-1
OAI : oai:www.see.asso.fr:1301:2013-1:3914

Résumé

L es systèmes de communication, fixes ou mobiles, sont devenus partie intégrante de la vie des habitants de la planète : en 2012, il y avait, en  service,  six  milliards  d’abonnements  à  un service mobile et un peu plus d’un milliard d’abonnements au service téléphonique fixe. La qualité de ces services est généralement très satisfaisante : elle est, en particulier, caractérisée par leur permanence, 24 heures sur 24, 7 jours sur 7. Dans la très grande majorité des réseaux, celle-ci est très  bien  assurée,  mais  il  arrive  parfois  que  des  clients  se
trouvent privés du service notamment par des incidents. Ces incidents, très peu nombreux, peuvent néanmoins avoir un impact  sur  l’activité  économique  de  la  zone  géographique
dans laquelle ils se produisent et leur rareté accroît encore leur retentissement sur le public.
Les pannes des équipements constituant les réseaux ne pouvant pas malheureusement être évitées, leurs opérateurs, dans la conception des réseaux, et les fournisseurs d’équipements, dans celle des éléments qui les constituent, s’organisent pour réduire voire annuler leur impact sur le service offert. Malgré toutes ces précautions de conception, tous les grands réseaux sont frappés, tôt ou tard mais fort heureusement à des fréquences très réduites, par des interruptions de service. Dans cet article nous examinons tout d’abord quels
sont les risques dont il faut se protéger et comment s’en prémunir. Ensuite nous verrons pourquoi et dans quelle mesure des interruptions significatives de service restent malgré tout
encore possibles.


Les vulnérabilités des grands réseaux de télécommunication

Métriques

20
6
474.6 Ko
 application/pdf
bitcache://973e7c2a2b2d08ac710ea11374420fffe63a073f

Licence

Creative Commons Aucune (Tous droits réservés)
<resource  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                xmlns="http://datacite.org/schema/kernel-4"
                xsi:schemaLocation="http://datacite.org/schema/kernel-4 http://schema.datacite.org/meta/kernel-4/metadata.xsd">
        <identifier identifierType="DOI">10.23723/1301:2013-1/3914</identifier><creators><creator><creatorName>Patrice Collet</creatorName></creator></creators><titles>
            <title>Les vulnérabilités des grands réseaux de télécommunication</title></titles>
        <publisher>SEE</publisher>
        <publicationYear>2013</publicationYear>
        <resourceType resourceTypeGeneral="Text">Text</resourceType><dates>
	    <date dateType="Created">Tue 2 Apr 2013</date>
	    <date dateType="Updated">Thu 26 Jan 2017</date>
            <date dateType="Submitted">Mon 15 Oct 2018</date>
	</dates>
        <alternateIdentifiers>
	    <alternateIdentifier alternateIdentifierType="bitstream">973e7c2a2b2d08ac710ea11374420fffe63a073f</alternateIdentifier>
	</alternateIdentifiers>
        <formats>
	    <format>application/pdf</format>
	</formats>
	<version>28811</version>
        <descriptions>
            <description descriptionType="Abstract">L es systèmes de communication, fixes ou mobiles, sont devenus partie intégrante de la vie des habitants de la planète : en 2012, il y avait, en  service,  six  milliards  d’abonnements  à  un service mobile et un peu plus d’un milliard d’abonnements au service téléphonique fixe. La qualité de ces services est généralement très satisfaisante : elle est, en particulier, caractérisée par leur permanence, 24 heures sur 24, 7 jours sur 7. Dans la très grande majorité des réseaux, celle-ci est très  bien  assurée,  mais  il  arrive  parfois  que  des  clients  se<br />
trouvent privés du service notamment par des incidents. Ces incidents, très peu nombreux, peuvent néanmoins avoir un impact  sur  l’activité  économique  de  la  zone  géographique<br />
dans laquelle ils se produisent et leur rareté accroît encore leur retentissement sur le public.<br />
Les pannes des équipements constituant les réseaux ne pouvant pas malheureusement être évitées, leurs opérateurs, dans la conception des réseaux, et les fournisseurs d’équipements, dans celle des éléments qui les constituent, s’organisent pour réduire voire annuler leur impact sur le service offert. Malgré toutes ces précautions de conception, tous les grands réseaux sont frappés, tôt ou tard mais fort heureusement à des fréquences très réduites, par des interruptions de service. Dans cet article nous examinons tout d’abord quels<br />
sont les risques dont il faut se protéger et comment s’en prémunir. Ensuite nous verrons pourquoi et dans quelle mesure des interruptions significatives de service restent malgré tout<br />
encore possibles.
</description>
        </descriptions>
    </resource>
.

17 REE N°1/2013 Introduction L es systèmes de communication, fixes ou mo- biles, sont devenus partie intégrante de la vie des habitants de la planète : en 2012, il y avait, en service, six milliards d’abonnements à un service mobile et un peu plus d’un milliard d’abonnements au service téléphonique fixe. La qualité de ces services est généralement très satisfaisante : elle est, en particulier, ca- ractérisée par leur permanence, 24 heures sur 24, 7 jours sur 7. Dans la très grande majorité des réseaux, celle-ci est très bien assurée, mais il arrive parfois que des clients se trouvent privés du service notamment par des incidents. Ces incidents, très peu nombreux, peuvent néanmoins avoir un impact sur l’activité économique de la zone géographique dans laquelle ils se produisent et leur rareté accroît encore leur retentissement sur le public. Les pannes des équipements constituant les réseaux ne pouvant pas malheureusement être évitées, leurs opérateurs, dans la conception des réseaux, et les fournisseurs d’équipe- ments, dans celle des éléments qui les constituent, s’orga- nisent pour réduire voire annuler leur impact sur le service offert. Malgré toutes ces précautions de conception, tous les grands réseaux sont frappés, tôt ou tard mais fort heureuse- ment à des fréquences très réduites, par des interruptions de service. Dans cet article nous examinons tout d’abord quels sont les risques dont il faut se protéger et comment s’en pré- munir. Ensuite nous verrons pourquoi et dans quelle mesure des interruptions significatives de service restent malgré tout encore possibles. Les grands réseaux et leurs évolutions Avant d’aborder la question des risques auxquels sont soumis les grands réseaux rappelons rapidement comment ils sont constitués et quelles sont les grandes tendances de leur évolution. Constitution générale des réseaux Les grands réseaux couvrent généralement des terri- toires très étendus et offrent une connectivité totale entre les différents clients du réseau (au moins pour les réseaux publics) : tout client quelle que soit sa position géographique doit pouvoir communiquer avec tout autre client. Les réseaux Les vulnérabilités des grands réseaux de télécommunication L'ARTICLE INVITÉ PATRICE COLLET Figure 1 : Organisation générale des grands réseaux. 18 REE N°1/2013 L'ARTICLE INVITÉ sont en général organisés selon deux segments, le segment d’accès qui permet de raccorder les terminaux des clients et de regrouper leurs trafics et le cœur de réseau qui permet de connecter entre eux les différents réseaux d’accès (figure 1). Quels que soient les moyens d’accès au client final, qu’il s’agisse de moyens hertziens, comme dans le cas du service mobile, ou de moyens filaires, le cœur ces réseaux s’appuie, sur une infrastructure fixe composée de : qui utilisent une infrastructure constituée de fibres optiques, de paires de cuivre et, par- fois, de systèmes hertziens : ils interconnectent diverses familles d’équipements situés dans des sites éloignés les uns des autres ; qui assurent l’aiguillage des informa- tions soumises au réseau, voix, données, images, vers leur destinataire, fournissant ainsi une connexité temporaire ou permanente entre deux clients d’un réseau. Les données échangées entre deux clients sont de plus en plus majori- tairement transmises sous forme de paquets IP alors que dans le passé la commutation de circuits était le mode le plus couramment utilisé dans les grands réseaux. Le trans- fert sous forme de paquets IP peut être réalisé, soit comme une suite de datagrammes, soit faire l’objet d’une session temporaire de données, le réseau directement ou indirec- tement associant alors entre eux les paquets d’une même session. Dans le mode session de données, au processus de routage classique des paquets IP est associé un échange de données de commande, c’est-à-dire un système de si- gnalisation, permettant d’établir, rompre ou modifier la ses- sion. Les nœuds d’aiguillage sont des routeurs IP et, dans les grands réseaux, des plates-formes de commande assurent la gestion des sessions de communication de données. qui sont sollicitées par les terminaux des clients et les sollicitent afin d’assurer la mise en place et la rupture des sessions de communication. Leur rôle minimal est celui du routage des flux de signalisation associés à chaque session. Dans beaucoup de cas, elles supervisent les sessions établies et gèrent des données de contexte qui leur sont associées. Ce sont des machines commandées par logiciel : à l’origine il s’agissait de ma- chines très spécifiques mais, au fil des évolutions techno- logiques, elles s’approchent de plus en plus de machines informatiques standard. Pour accomplir leurs tâches, elles doivent avoir accès à des données, notamment celles décri- vant le service auquel un client a souscrit ou bien dans les réseaux mobiles aux données de localisation de l’abonné. Les données de souscription des clients étaient à l’origine, en téléphonie fixe, réparties entre les différentes instances de plates-formes de commande qui avaient naturellement une zone de desserte géographique. Avec l’arrivée du ser- vice mobile, le concept de zone de desserte n’est plus pertinent et les données de souscription et de localisation sont gérées par des machines spécifiques de gestion de données en temps réel auxquelles accèdent les plates- formes de commande. Cette architecture qui présente de nombreux avantages, a été plus récemment reprise dans le Figure 2 : Principes de l’architecture fonctionnelle d’un grand réseau. REE N°1/2013 19 L'ARTICLE INVITÉ service fixe pour la commande de sessions de voix sur IP. La permanence de l’accès à ces données, donc la disponibilité des machines qui les gèrent sont cruciales pour assurer la permanence du service. , qui portent les logiciels spéci- fiques à la fourniture de certains services aux clients. Elles permettent de rendre les plates-formes de commande de réseau aussi indépendantes que possible des services offerts par le réseau dans lequel elles sont installées. Elles peuvent avoir aussi à gérer leur propre contexte de session. Ce sont des machines informatiques qui au minimum inter- agissent avec les terminaux clients et très souvent avec les plates-formes de commande du réseau. Bien que ne faisant pas partie strictement du réseau, il faut souligner le caractère central du système d’information de l’opérateur de réseau pour assurer les fonctions essentielles comme la prise de commande, la livraison du service, la supervision, la gestion et la maintenance du réseau, la factu- ration… A l’origine, beaucoup moins soumis aux contraintes de permanence de service et de fonctionnement en temps réel, il y est aujourd’hui largement astreint : par exemple il ne serait pas compréhensible pour un client commandant ou modifiant un service de communication par le web que sa commande ne soit pas prise en compte en temps réel. La figure 2 donne une esquisse de l’architecture d’un grand réseau : en particulier une structuration en couches fonctionnelles y est proposée. Les tendances d’évolution des réseaux On ne mentionnera ici que les évolutions qui ont un im- pact possible sur l’apparition de défaillances ou sur les effets des défaillances sur la disponibilité des réseaux : dans les éléments constitutifs des réseaux, qu’il s’agisse des plates-formes de commande de réseau, des plates-formes de service ou de gestion, mais également dans les terminaux client et dans les éléments de réseau comme les routeurs eux-mêmes. Le logiciel ap- porte évidemment la souplesse d’évolution dans la vie de ces machines et donc dans les réseaux qu’ils équipent : la contrepartie en sont les risques, en termes de pannes, qu’apportent des défauts résiduels éventuels et des évolu- tions plus ou moins contrôlées. sous forme de paquets IP qui a pour conséquence, dans l’architecture des réseaux, la . Dans le passé, à l’époque de la commutation de circuits, les fonctions de commande de sessions et les fonctions de transfert de données étaient assurées par les mêmes machines. Aujourd’hui, les fonctions de commande inter- agissent avec les fonctions de transport via des protocoles de commande normalisés. La séparation des deux fonc- tions permet aux fonctions de commande de ne pas porter les contraintes qui sont celles des fonctions de transport : ainsi les plates-formes de commande peuvent avoir une localisation géographique indépendante de la topologie du réseau de transport. Elle permet aussi d’adapter au mieux les mesures de protection contre les pannes aux éléments relatifs à chacune des deux fonctions. des éléments disponibles pour la construction des réseaux touche tous les secteurs : aussi bien le domaine de la transmission où le transport optique et le multiplexage en longueur d’onde permettent à une paire de fibres d’atteindre des débits de l’ordre du térabit/s avec des portées de l’ordre du millier de kilomètres [1] que celui des plates-formes de commande pour la téléphonie dont la capacité de traitement permettrait, à l’heure actuelle, de traiter le trafic correspondant à celui de plusieurs millions de clients, capacité à comparer à la capacité des commutateurs téléphoniques des années 1980-1990 qui, au maximum, pouvaient desservir entre 50 000 et 100 000 abonnés. Compte tenu du fait qu’en général le niveau de prix des équi- pements croît moins vite que leur capacité, cette croissance est largement mise à profit dans la conception des réseaux, pour réduire les coûts de production des réseaux. La contre- partie à cet effet économique positif est, évidemment, la croissance de l’impact d’une panne d’un équipement sur le service, en termes, par exemple, de nombre de clients affec- tés par une même panne. contribuent de plus en plus étroite- ment à la fourniture du service : c’est, en particulier, la consé- quence de la généralisation des technologies IP qui repoussent beaucoup de fonctions qui, dans les réseaux traditionnels, étaient assurées au cœur de ceux-ci, à leur périphérie. Les objectifs de qualité de service Offrir un service permanent est un objectif central depuis les débuts des réseaux de communication ouverts au public. Pour un central téléphonique [2] un objectif courant était de ne pas dépasser une durée cumulée d’arrêt (toutes causes cumulées) de deux heures en 40 ans soit trois minutes par an. On trouve souvent dans la littérature pour des équipements de réseau d’opérateurs (dits « carrier grade ») un objectif de taux de disponibilité du service supérieur à 99,999 % (connu souvent sous le nom de « five nines ») : il correspond à une indisponibilité moyenne inférieure à 25,9 s par mois qui équi- vaut à une durée d’interruption cumulée de 5 mn et 37 s par an. Ces chiffres donnent une approche de ce que sont les objectifs de permanence de service que se fixent les opé- rateurs de réseau mais il faut souligner qu’ils correspondent à l’objectif de disponibilité d’une machine donnée dont les pannes privent de service un nombre donné de clients, ici 20 REE N°1/2013 L'ARTICLE INVITÉ un nombre de l’ordre de l’ordre de 50 000 clients. Intuitive- ment, on comprend bien que l’objectif de disponibilité d’un équipement desservant un unique client et celui desservant un million de clients ne peut pas être le même : il devrait être notablement plus élevé dans le deuxième cas. Ainsi, plus l’impact en termes de nombre de clients affectés par la panne d’un équipement donné est élevé, plus l’opérateur doit prendre des mesures pour sécuriser le fonctionnement de cet équipement. Il n’est pas possible évidemment de supprimer toutes les causes de défaillance à la source, on ne peut que se protéger de leurs effets éventuels sur le service offert. Les protections qu’on applique, dans la conception et dans l’exploitation des réseaux et des équipements pour se protéger des effets potentiels des défaillances dépendent évidemment du type d’équipement de réseau et de l’origine de la défaillance envisagée. C’est ce que nous allons examiner dans la suite de l’article. Les origines des dysfonctionnements des réseaux Les origines des dysfonctionnements potentiels des ré- seaux sont multiples. Les plus classiques et les mieux maî- trisées sont les défaillances du matériel électronique ; on en connaît, en général, très bien la statistique d’apparition et on dispose des moyens d’en prévoir les effets sur les systèmes matériels. Nous ne développerons pas plus avant cet aspect. La problématique des anomalies logicielles est beau- coup plus complexe : à leur source on trouve évidemment différents types d’erreurs de conception : par exemple des configurations de l’environnement qui n’ont pas été prises en compte ou bien qui n’ont pas donné lieu à des tests, des anomalies de comportement des autres éléments de réseau dont la prise en compte n’est pas correctement assurée, des problèmes touchant plus profondément aux couches logi- cielles de base, mauvaise gestion de la mémoire, etc. Leur apparition n’est guère prévisible ni leurs effets sur le com- portement des systèmes : une anomalie logicielle peut, en effet, rester cachée pendant des années puis être révélée par une modification de l’environnement dans lequel le système se trouve. Les effets potentiels d’une erreur sont très variés, mais ils peuvent aller jusqu’à l’arrêt complet des traitements par l’entité qui la subit : ils peuvent donc être catastrophiques pour la tenue des objectifs de permanence du service et perturber un réseau dans presque sa totalité, notamment si l’erreur affecte un système qui sert un très grand nombre de clients. Une autre difficulté est propre aux réseaux de télé- communication : les protocoles de commande et de signa- lisation peuvent diffuser l’élément d’environnement qui dé- masque l’erreur logicielle. Les effets s’étendent alors à toutes les machines qui exécutent le même logiciel. On est alors devant une panne qui peut affecter le réseau dans son entier. Les aléas externes aux réseaux sont aussi une source po- tentielle de défaillance. Des travaux agricoles peuvent dans un champ peuvent couper un câble en pleine terre, des tra- vaux de génie civil en zone urbaine menés sans précaution préalable peuvent couper un câble : dans les deux cas il peut s’agir de câbles transportant des volumes de trafic très impor- tants. On assiste de plus en plus à des vols de câbles en cuivre et on a vu dans le passé des coupures intentionnelles de câbles à fibre optique : dans ces deux cas, il peut en résul- ter, si des précautions ne sont pas prises dans la conception même du réseau, une coupure totale des communications vers une zone du territoire plus ou moins étendue. Les aléas météorologiques, comme les inondations ou les tempêtes peuvent également être directement ou indirecte- ment, par le biais de la rupture de l’alimentation électrique, à l’origine de défaillances importantes dans les réseaux. Les pannes de l’alimentation électrique de longue durée peuvent être sources de défaillance pour tous les équipements instal- lés dans un même bâtiment. En général les sites abritant les nœuds de réseau sont équipés de batteries et ou de moyens de secours tels que des groupes électrogènes. Les actions d’exploitation et maintenance menées par les équipes de l’opérateur peuvent également comporter des risques pour le fonctionnement du réseau. Des fausses ma- nœuvres ou le non respect des procédures opérationnelles peuvent dans certaines situations provoquer une défaillance grave du réseau : on évoque souvent l’erreur d’un opérateur consistant, dans une architecture à calculateurs dupliqués, à enlever par erreur une carte supposée défectueuse d’un calculateur sain. Plus généralement le non respect des pro- cédures d’intervention sur les équipements peut également être une source de défaillances. A celles-ci on peut rattacher les opérations de chargement d’une nouvelle version de logi- ciel sur un équipement en service : la conception de certains d’entre eux impose de les mettre hors service pour réaliser l’opération et engendre donc un arrêt du service. Ce n’est acceptable que pour des équipements de faible capacité en trafic ou en desserte de clients et à condition que l’opération soit effectuée en heure de faible trafic. Enfin, le protocole IP est maintenant devenu commun aux données transportées par le client et aux données de com- mande et gestion interne au réseau de l’opérateur : ainsi, si des précautions ne sont pas prises, peut apparaître le risque que des hackers puissent pénétrer dans les couches de com- mande des réseaux voire dans son système d’information et s’y attaquer. Comment limiter la fréquence et l’impact des défaillances ? Il est impossible d’éviter totalement les pannes des dif- férents constituants des réseaux mais un opérateur peut REE N°1/2013 21 L'ARTICLE INVITÉ agir par différents moyens sur leur fréquence et sur l’impact des défaillances. Les plus importants de ces moyens sont la sélection d’équipements ou de systèmes ayant eux-mêmes un haut niveau de disponibilité, la mise en œuvre de redon- dances dans la conception de son réseau et dans la défini- tion et l’application de méthodes d’intervention sur le réseau en fonctionnement. La durée de la panne a évidemment un impact direct sur l’indisponibilité résultant de la défaillance d’un constituant du réseau : les équipements et l’organisa- tion opérationnelle de la maintenance doivent être conçus de façon à limiter le temps de réparation de ce constituant. Choisir des équipements de réseau à haut niveau de disponibilité Lorsqu’un opérateur sélectionne un élément qui doit équi- per son réseau, il doit s’assurer de son indisponibilité prévision- nelle. Deux aspects doivent être pris en compte, l’indisponibili- té prévisionnelle de l’équipement présentée par le fournisseur et l’indisponibilité résultant de l’exploitation de l’équipement. Sur le premier aspect, l’indisponibilité prévisionnelle, telle qu’établie par le fournisseur, ne prend en compte la plupart du temps que les pannes de matériel et s’appuie sur des méthodologies reconnues. Elle est un bon repère pour l’opé- rateur. Par contre, concernant les pannes résultant d’erreurs logicielles, ce n’est que par des tests du système dont il envisage l’installation que l’opérateur peut évaluer la tenue du logiciel qui le pilote. Des opérateurs incluent dans leur processus de choix d’un fournisseur une phase d’évaluation sur plate-forme du système pour approcher sa qualité logi- cielle : c’est évidemment une approche très lourde et limi- tée puisqu’elle nécessite des moyens humains et matériels lourds et porte souvent sur une version du logiciel qui doit faire l’objet d’adaptations avant de pouvoir être mis en place dans le réseau. Mais elle est souvent le seul moyen d’appro- cher l’état de mise au point du logiciel d’un système. Une fois la sélection du produit effectuée, pour s’assurer de son niveau de qualité, la version finale de son logiciel donne lieu à des tests de validation par l’opérateur : il s’agit d’une tâche très lourde qui doit être reprise partiellement ou totalement à chaque livraison d’une nouvelle version du logi- ciel et qui demande des moyens humains et matériels impor- tants à la fois pour concevoir les tests et pour les effectuer. Ces tests sont conduits, en général, dans un environnement simulé sur des appels unitaires, puis en chargeant la machine en trafic. En effet la charge en trafic fait fréquemment ap- paraître des problèmes que les tests unitaires n’avaient pas révélés, car ils peuvent solliciter des mécanismes complexes comme les mécanismes de régulation de trafic qui ne sont pas actifs sur les tests plus élémentaires. Un troisième famille de tests complète la phase de va- lidation, les tests en environnement réel : il s’agit ici d’ef- fectuer des tests d’interopérabilité avec des machines du même type que celles avec lesquelles le système en test va devoir coopérer une fois réalisée l’intégration dans le réseau. L’idéal est de disposer d’un « modèle réduit » du réseau dans lequel le nouveau logiciel ou le nouveau système va devoir fonctionner : cela permet d’éviter tout risque que pourrait faire courir une intégration directe dans le réseau. Ces tests d’interopérabilité permettent de vérifier la compatibilité entre les différents éléments de réseau. Cette rapide description montre aussi les limites de la souplesse apportée par le logi- ciel : le poids du test de nouvelles versions de logiciel d’un système fait qu’on évitera de produire des versions logicielles d’un même système de façon trop fréquente en regroupant périodiquement les évolutions fonctionnelles dans des pa- quets logiciels qu’on appelle versions, releases, ou paliers suivant les systèmes ou les opérateurs. Concernant le deuxième aspect, l’opérateur doit s’assurer que dans la vie normale de l’élément de réseau, des opéra- tions d’exploitation courante ne vont pas introduire une indis- ponibilité additionnelle dont l’importance peut être rédhibi- toire. C’est par exemple le cas de certains systèmes à com- mande logicielle dont on ne peut changer le logiciel à chaud c’est-à-dire sans interruption du trafic. La durée de charge- ment et la fréquence des nouvelles versions augmentent directement l’indisponibilité du système. La durée dépend de la taille du logiciel et du débit qui peut être mis en œuvre pour charger, à distance le plus souvent, la nouvelle version. La fréquence des opérations de mise à niveau du logiciel est plus difficile à estimer car elle dépend, notamment, de la période de vie du système : en début de vie, les évolutions logicielles sont en général beaucoup plus fréquentes qu’en fin de vie. La conception et l’exécution de jeux de tests du logiciel sont une nécessité incontournable à la fois pour le fournis- seur du système logiciel et pour l’acheteur de celui-ci : le premier pour pouvoir assurer du niveau de qualité de son produit, le second pour vérifier que le produit qui lui est livré a atteint le niveau de qualité suffisant pour ne pas affecter la qualité de service de son réseau. Dans les deux cas, il est nécessaire de disposer de jeux de tests assurant une bonne couverture, d’outils de gestion des tests et de moyens d’exé- cution automatique de ceux-ci : en effet la réutilisation des tests de version en version est une nécessité économique même si, pour chaque version, il faut s’assurer de la perti- nence des tests exécutés pour la version précédente. Pour réduire les délais de mise en place d’une nouvelle version de logiciel, il y a intérêt à instaurer une grande transparence entre fournisseur et acheteur sur les jeux de tests exécutés et leurs résultats. Malgré tous les efforts de test faits par les deux acteurs, il n’est jamais possible de garantir qu’il ne demeure pas dans le logiciel testé des erreurs résiduelles : 22 REE N°1/2013 L'ARTICLE INVITÉ simplement on s’assure que leur probabilité d’occurrence est très faible. Mettre en œuvre des redondances La mise en œuvre de redondances est le moyen principal à la disposition des fournisseurs d’équipements et des opé- rateurs pour améliorer la fiabilité des réseaux. Elle consiste à mettre en place plus d’instances de machines ou de sous- ensembles qu’il n’en faudrait strictement pour assurer un trai- tement satisfaisant de la charge appliquée à celles-ci. Dans le principe, une instance saine pouvant se substituer à une instance défaillante, on peut, ce faisant, réduire l’indisponi- bilité du système ou du réseau. Une condition essentielle est que les causes des pannes des différentes instances ne soient pas corrélées : c’est en général le cas pour les pannes matérielles, hors des causes liées à l’environnement. Dans le cas des systèmes à commande logicielle, si l’on voulait assurer une non corrélation parfaite des pannes des diffé- rentes instances, il faudrait assurer qu’elles ne traitent jamais les mêmes tâches au même moment. Avoir des logiciels dif- férents développés indépendamment et implantés sur des matériels différents permet en principe d’assurer une totale non corrélation : il n’y a aucune raison pour qu’une panne logicielle se produise au même instant sur les différentes instances. Cette pratique, très coûteuse et qui pose des pro- blèmes de synchronisation, est réservée aux systèmes à très haute disponibilité comme dans l’aéronautique. Elle n’est pas celle retenue couramment dans les réseaux publics de com- munication. On essaie de l’approcher en répartissant les flux de trafic sur les différentes instances : ainsi, en général à un instant donné, deux instances ne traitent pas les mêmes tâches. C’est une approche qui réduit fortement l’indispo- nibilité mais ne garantit pas totalement l’indépendance des pannes : c’est le cas notamment quand celles-ci n’ont pas leur origine dans le traitement du trafic. Pour que la redondance soit efficace, la partie saine du réseau doit être capable de détecter l’élément défaillant et de provoquer le basculement que le trafic traitait ou était susceptible de traiter l’élément défectueux vers l’élément de réserve. Ces deux fonctions ne sont pas simples à réaliser, notamment si l’on veut éviter que les différents échanges de données qui utilisaient directement ou indirectement l’élé- ment défaillant soient perturbés ou interrompus. La mise en œuvre des redondances est évidemment très différente selon les composants du réseau en cause, arcs de réseau ou nœuds de réseau. Redondance des arcs de transmission Pour sécuriser les arcs du réseau de transmission, il faut disposer de deux chemins physiquement indépendants : pour cela, on recourt en général à des topologies en boucle qui permettent à partir d’un nœud de réseau d’atteindre un autre nœud par deux chemins physiques indépendants. L’in- dépendance des deux demi-boucles est assurée par le fait qu’elles ne passent pas par les mêmes lieux : c’est près de la jonction des éléments de la boucle et dans l’accès aux bâti- ments qu’il faut prendre des précautions pour qu’un coup de pelle mécanique malencontreux n’interrompe jamais simul- tanément les deux demi-boucles. On peut ainsi constituer une redondance qui peut être utilisée en cas de panne. La détection rapide de la rupture d’une demi-boucle est indis- pensable pour provoquer un basculement rapide des flux sur l’autre demi-boucle : les systèmes installés à chaque nœud de l’infrastructure doivent superviser en permanence le fonc- tionnement de la transmission et provoquer le basculement des flux à transmettre. Ils peuvent être des équipements de transmission ou bien des équipements de la couche de transport. Leur panne interrompt le transfert d’information à destination ou en provenance du nœud (figure 3). La péren- nité de l’indépendance des parcours est évidemment à assu- rer au fil des évolutions de l’infrastructure du réseau : des mutations de câbles ou de systèmes peuvent intervenir au fil des évolutions d’un réseau et les processus mis en œuvre doivent faire en sorte qu’elle soit maintenue. Sinon des liens de transmission qu’on supposait sécurisés pourraient être interrompus par une panne simple. Redondance des nœuds d’aiguillage (routeurs, switches, etc) La redondance des nœuds d’aiguillage peut être assurée selon plusieurs approches : qui consiste à en faire un équipement intrinsèquement Figure 3 : Anneau de transmission porté par une boucle de câbles. REE N°1/2013 23 L'ARTICLE INVITÉ fiable en dupliquant à la fois l’entité assurant les fonctions de commande et celle assurant les fonctions de transport du nœud. Les flux de données reçus sont présentés aux deux instances assurant la fonction de transport de sorte que, vu du reste du réseau, on a bien affaire à un nœud unique. C’est une approche qu’on a largement utilisée en commutation téléphonique numérique. - dondant, où l’on introduit à la fois plus de nœuds et donc d’arcs que strictement nécessaire. On peut ainsi construire des plans de transport de diverses topologies dont le ni- veau de redondance peut aller jusqu’à la construction de deux plans de réseaux interconnectés à tous les nœuds, comme le propose la figure 4 qui protège complètement contre la panne totale de nœud ou la panne totale d’un arc. On peut arriver ainsi à des structures très fiables mais la mise en place de deux plans de réseau est coûteuse ; aussi la réserve-t-on aux cœurs de réseaux, les réseaux dits dor- saux par exemple. Les réseaux de transport IP font usage de la redondance des arcs et des nœuds qui peut, parfois, aller jusqu’à la duplication complète. Redondance des plates-formes de commande Plates-formes de commande et plates-formes de service ont vu leur capacité croître au fil des évolutions techniques des réseaux : leur nombre et par voie de conséquence le nombre de sites où elles sont implantées a donc tendance à diminuer. L’impact de l’indisponibilité d’une plate-forme sur le service est donc croissant. Elles constituent souvent ce qu’on appelle en anglais un “single point of failure” (c'est-à- dire un point dont une panne simple interrompt le service). Les plates-formes de commande et, la plupart du temps, les plates-formes de service sont donc protégées par redon- dance. Elles peuvent aussi avoir elles-mêmes une structure redondante : une alternative pourrait être une redondance mise en œuvre au niveau du réseau. La redondance peut être une simple duplication, selon un mode dit 1+1, ou être obtenue en ajoutant aux n instances nécessaires pour traiter le trafic nominal, p instances pour faire face aux pannes : la redondance est dite alors de type n+p. Ces arrangements permettent de faire face à la panne d’une instance, mais si les traitements assurés par la plate- forme sont critiques on cherchera aussi à se protéger contre une panne catastrophique du site qui l’héberge, par exemple un incendie, en disposant de sites de secours équipés d’une plate-forme de secours identique à celle du site affecté. Dans ce cas, la mise en trafic de cette dernière peut impliquer une action de configuration de celle-ci : mais la rareté de ce genre de catastrophe rend cette limitation acceptable. Le basculement du trafic à l’intérieur d’une structure re- dondante pose la question de l’accès aux données par l’ins- tance qui reprend le trafic : il s’agit des données décrivant le service auquel le client a souscrit, des données temporaires associées aux sessions établies et des données relatives à l’état des ressources de transport accessibles à la plate-forme (lorsque ces deux dernières existent). La centralisation des données client dans des dépôts de données temps réel, née dans les réseaux mobiles avec le HLR (Home Location Register ou Enregistreur de localisation nominal), permet de simplifier considérablement l’accès à celles-ci ; cette pratique permet aussi de rendre automatique la configuration d’une instance de secours d’une plate-forme et donc de limiter l’in- disponibilité engendrée par le basculement d’une instance à l’autre. En revanche, elle impose que les machines HLR aient une très bonne disponibilité : la perte d’une machine HLR Figure 4 : Sécurisation par duplication totale des arcs et des noeuds. Elle protège contre une panne simple d'un nœud ou la panne simple d’un arc. 24 REE N°1/2013 L'ARTICLE INVITÉ interrompt tout le trafic en provenance et à destination des mobiles dont les données sont gérées par ce HLR. La conservation des sessions établies en cas de panne est une exigence courante dans les réseaux : elle impose la connaissance des contextes de session en cours dans l’instance défaillante, lorsqu’ils existent, par l’instance qui reprend le trafic. De plus s’il existe des ressources de réseau dont l’état est géré par une plate-forme (ce qui est courant en commutation de circuits), les différentes instances consti- tuant cette plate-forme redondante doivent partager leur état actuel pour pouvoir les utiliser correctement. Ces instances doivent donc informer les autres d’une part de l’état des di- verses sessions qu’elles traitent, d’autre part de l’utilisation que chacune fait des ressources réseau. La maîtrise des délais d’intervention et de réparation Quand une panne se produit, sa réparation doit inter- venir dans les meilleurs délais pour limiter son effet sur la disponibilité du service ; une alarme doit donc être émise pour provoquer une action du personnel de maintenance du réseau. Elle est engendrée, soit par l’équipement fautif, soit par un élément sain qui directement ou indirectement détecte la défaillance. Les alarmes sont classées par niveaux en fonction du type de constituant touché par la panne. A chaque niveau d’alarme est attaché un délai d’intervention. Ainsi priorité sera donnée au traitement des pannes ayant un fort impact sur le service vu du client. Il faut noter que l’impact de la panne sur la qualité de service peut être direct si l’équipement affecté ne comporte pas de redondance ou bien indirect si l’équipement en cause est redondé. Dans ce deuxième cas, il importe, néanmoins, de revenir le plus rapidement possible à la situation nominale où toutes les instances constituant la structure redondante sont opération- nelles. Le délai de réparation doit être aussi très limité : des outils intégrés ou non aux équipements en cause sont néces- saires pour y faciliter la localisation de l’élément défectueux à remplacer par l’opérateur de maintenance. La rigueur opérationnelle La commande logicielle des systèmes de réseau introduit une certaine souplesse mais également des risques si la gestion des versions des logiciels utilisés dans le réseau n’est pas assurée avec rigueur. En général un opérateur s’efforce de n’avoir, à un instant donné, dans son réseau que deux versions de logiciel et de corrections dans chacun des types de machine de réseau qu’il exploite : la version nouvelle en cours de déploiement et la version précédente. La multiplication des versions par des niveaux de corrections multiples augmenterait les efforts de test et compliquerait l’analyse du fonctionnement des machines de réseau. Les interventions d’exploitation et maintenance sur un réseau comportent des risques. L’opérateur de réseau doit s’organiser pour en réduire l’impact possible. Il s’efforce donc d’en limiter le nombre au strict nécessaire et d’en formaliser l’organisation par des modes opératoires précis : l’improvisa- tion dans les interventions porte évidemment de nombreux risques. Chaque intervention et ses modalités doivent faire l’objet d’une décision explicite. Un processus de collecte et de traitement des rapports d’anomalie de fonctionnement est organisé pour confirmer les anomalies signalées et les soumettre on non pour correc- tion au fournisseur. Les corrections sont regroupées en pa- quets de correction. Avant d’être chargées dans le réseau, les paquets de corrections logicielles d’un constituant de celui-ci doivent au préalable avoir subi une série de tests du type de ceux qu’on a vus plus haut : leur chargement dans les ma- chines opérationnelles du réseau est formellement décidé selon un processus bien établi qui définit, en particulier, les conditions dans lesquelles l’opération concrète se déroulera. Protection contre les attaques Les grands réseaux de télécommunications ouverts au public, jusqu’au début des années 1990, ont été fondés sur de la commutation de circuits et sur des mécanismes de signalisation hors bande : en séparant physiquement le transport des données des clients, confinées à l’intérieur du circuit, des échanges de données de commande nécessaires à l’établissement des circuits, ces techniques rendaient quasi impossibles l’accès malveillant aux fonctions de commande du réseau. La généralisation du transport IP et le dévelop- pement du raccordement IP des clients, a complètement changé la donne. Les paquets IP portant les informations de commande et les paquets IP portant les données échan- gées par les clients empruntent partiellement ou totalement le même réseau IP. De plus, dans le cas où des sessions de données doivent être établies, ce qui est le cas pour les échanges de voix, le terminal interagit successivement avec différentes plates-formes de commande du réseau. Des pré- cautions doivent donc être prises pour réduire les risques d’actions malveillantes. Les protections contre les attaques qui sont mises en œuvre sont celles classiquement appliquées dans le monde de l’informatique et de l’IP : - nées de commande du réseau, interactions réseau-SI, … dans différents sous-réseaux virtuels IP (VPN1 ) : elle permet de réduire les risques d’intrusion à partir des accès clients ; notamment des zones dites démilitarisées (DMZ) qui 1 Virtual Private Network. REE N°1/2013 25 L'ARTICLE INVITÉ hébergeront des serveurs qui doivent pouvoir être accédés à partir de l’extérieur et peuvent interagir avec les éléments dont la protection doit être maximale ; permet de masquer la topologie du réseau IP. Ces arrangements de sécurité introduisent des équipe- ments additionnels, commutateurs de niveau 2, pare-feu, NAT2 … qui doivent eux-mêmes être exploités et ne pas intro- duire une indisponibilité additionnelle significative. Les limites de l’approche Les mesures traditionnellement prises dans les grands réseaux, dont nous venons de donner une description som- maire, permettent à ceux-ci d’atteindre un niveau moyen de disponibilité remarquable mais ne permettent pas de garantir un service absolument sans interruption. D’une part, vu d’un client, le service a une certaine probabilité d’être interrompu parce que sa ligne de raccordement est unique ou bien parce que le premier nœud de transport auquel elle est raccordée ne peut avoir de redondance pour des raisons économiques. D’autre part, dans la partie centrale des réseaux, les mesures que nous avons présentées plus haut ont certaines limites. Ce sont ces limites qui, en plus des catastrophes naturelles, sont la plupart du temps à l’origine des grandes perturbations que les réseaux publics ont pu connaître et qui restent heu- reusement très rares. On trouve généralement à leur origine une erreur logicielle résiduelle qui n’a pas été détectée lors des différents types de test que subit le logiciel avant d’être mis dans le réseau. Cette erreur ne correspond pas à une configuration invoquée à l’instant du chargement de la ver- sion et aucune anomalie de fonctionnement n’apparaît. Le système qui porte ce logiciel fonctionne correctement tant que l’environnement dans lequel il se trouve est inchangé. Le facteur déclenchant l’apparition de l’anomalie peut éven- tuellement se manifester au bout d’un temps très variable qui peut aller de quelques heures à quelques années. Les fac- teurs déclenchant peuvent être de très différentes natures : d’être connecté au réseau et qui, par le biais des échanges de signalisation anormaux avec les nœuds existants, invoque une configuration de traitement démasquant la faute logi- cielle résiduelle des nœuds distants du même type et pro- voque par exemple un passage hors ligne d’une machine pourtant redondante : il joue le rôle de révélateur d’une fai- blesse préexistante. Les processus de contamination par la signalisation peut être dévastateur car potentiellement toute machine peut dialoguer avec toute autre : ainsi la nouvelle machine va peu à peu mettre en panne un grand nombre de machines exécutant toutes le même logiciel. Il faut 2 Network Address Translation. noter que cette propagation éventuelle est très rare, car elle résulte de la coïncidence de deux erreurs logicielles, l’une dans le nouvel équipement qui engendre un élément de signalisation erroné et l’autre dans l’équipement préexistant qui traite mal un élément d’information anormal ; - seau distant qui, par suite d’une erreur, diffuse dans tous les nœuds une commande dont l’exécution, en raison d’une er- reur logicielle résiduelle, provoque l’arrêt de tous les nœuds de transport de même type. Si, dans ce cas, le réseau de transport est complètement dupliqué la duplication ne se- rait efficace que si les deux plans n’étaient pas constitués des mêmes machines qui exécutent le même logiciel ; clients : passé un certain seuil, le comportement du logiciel est perturbé. Si les machines de ce type sont très peu nom- breuses et indispensables à la fourniture du service alors la défaillance peut avoir un impact très significatif. Ces situations sont très délicates à traiter car elles appa- raissent comme un orage dans un ciel serein. La conduite de l’analyse de la situation exacte du réseau et des causes pro- bables de la défaillance peut être longue, alors qu’il y a une extrême urgence à remettre le service en marche. Une fois la cause exacte identifiée, le retour en ligne du réseau peut être délicat à gérer car il peut être soumis à une demande en trafic très importante. Une reprise graduelle du trafic est parfois à organiser afin de faciliter le retour en ligne des machines du réseau. Pour faire face à ces difficultés la mise en place à titre préventif d’une organisation en vue de la gestion de crises techniques ne peut qu’être bénéfique : elle permet de gagner du temps en réduisant finalement l’indisponibilité du service. Il est clair que la très grande majorité des situations que nous venons brièvement d’esquisser résultent d’anomalies logicielles. La concentration de certaines fonctions critiques sur un nombre très réduit de machines et la multiplication des machines d’un type donné ayant le même fournisseur et le même logiciel accroît l’impact de ces défaillances. Dans un réseau où toutes les machines d’un type donné exé- cutent le même logiciel, une erreur logicielle, démasquée par un changement de l’environnement par exemple, peut avoir pour conséquence un arrêt total du service. Même si le raisonnement économique peut pousser à centraliser à l’ex- trême certaines fonctions critiques ou à réduire le nombre de fournisseurs et donc de logiciels pour un type d’équipement donné, les opérateurs ne doivent pas pousser cette logique à l’extrême : en ne recourant pas à des machines de trop grande capacité et en faisant assurer une fonction donnée par des machines de fournisseurs différents, ils réduisent, ce fai- sant, l’impact sur le service de ces pannes extrêmement rares. Le déploiement de nouvelles versions logicielles sur un réseau existant, et la mise en place de nouveaux équipe- 26 REE N°1/2013 L'ARTICLE INVITÉ ments connectés au réseau sont, dans la plupart des cas, les catalyseurs déclenchant ces rares mais graves anomalies. Limiter les changements dans les réseaux pourrait être une orientation mais elle s’opposerait aux évolutions des services offerts au client qui sont un élément du jeu de la concur- rence dans les services de télécommunication. Conclusion Les précautions prises dans les grands réseaux de communication pour préve- nir les défaillances permettent d’assu- rer une performance remarquable des réseaux en termes de disponibilité. Les erreurs logicielles résiduelles sont en général responsables des rares grandes pannes des réseaux de communication : les opérateurs mettent en place de nom- breuses mesures de nature à en réduire la fréquence d’apparition sans réduire à l’excès l’agilité fonc- tionnelle qu’offre la commande par logiciel. Cependant leur impact pourrait augmenter, si la croissance de la capacité des éléments de réseau, la centralisation des fonctions et la tendance à la réduction du nombre de fournisseurs pour un type donné d’élément de réseau se poursuivaient encore. Un compromis est donc à trouver entre les avantages éco- nomiques résultant de ces tendances et le risque de faire croître l’impact de pannes de moins en moins fréquentes. Références [1] I. Joindot, « Les réseaux de télécommunica- tions optiques : construction, évolution et perspectives », REE Revue de l'électricité et de l'électronique, n° 11, pp. 30-31, 2012. [2] GRINSEC, La Commutation électronique, vol. 2, Eyrolles, 1980, p. 4. Patrice Collet est ancien élève de l’École Polytechnique et ingénieur des télécommunications. Sa carrière l’a conduit de la recherche et dévelop- pement au CNET qui était alors le centre de recherches de la Direction Générale des Télécommunications à la Direction Générale de France Télécom où il a eu la responsabilité de l’archi- tecture du réseau fixe et son évolution.