La verrue du backbone

La plupart des réseaux d’entreprises sont agencés de la manière suivante:

Bien entendu, il s’agit là d’une représentation très triviale; en réalité, il y a souvent beaucoup plus d’éléments actifs, et aussi d’intelligence surtout dans les datacenters et chez les opérateurs. Il faut aussi bien comprendre que chez un opérateur, il y a toujours plusieurs chemins vers le reste du monde: on ne va certainement pas prendre le risque de mettre tous ses œufs dans le même panier: en cas de rupture de lien avec l’un des fournisseurs, il faut systématiquement basculer vers un autre afin d’avoir une continuité de service.

Suite aux dramatiques événements qui ont frappé notre pays cette année, le gouvernement a exprimé son souhait d’installer des boites noires chez les opérateurs afin d’y détecter des « comportements suspects ». Si tel est le cas, voici comment il devrait logiquement procéder:

L’appareil est placé en coupure entre un firewall et un routeur, de sorte qu’il puisse intercepter tout le trafic entrant et sortant du réseau. Mais en réalité, il devrait rencontrer beaucoup de difficultés à arriver à mettre en place cet équipement à cet endroit.

La raison n’a pas l’air évidente à première vue pour un profane mais l’inconvénient majeur est qu’elle remet totalement en question toute l’architecture du réseau. Comme je l’ai décris, j’ai fait une représentation simplifiée du réseau à travers mes schémas mais dans les faits, un réseau peut vite être très complexe, et demande beaucoup de compétences, de maintenance, de supervision, de tuning, de support et de réflexion.

Sur ce genre de réseau de type backbone, tel quel l’on rencontre dans les datacenters et chez les opérateurs, on y trouve des mécanismes de routage (BGP, EIGRP, OSPF), de gestion de collision (Spanning-tree), de réseau virtuel (VLAN, trunk, VTP), d’agrégation (Etherchannel, LACP), de redondance de liens (HSRP, VRRP), etc. En bref, toute une série de mécanismes intelligents qui ont demandé beaucoup de temps, en réflexion, en analyse et bien sûr en argent.

Le simple fait d’ajouter un équipement sur un simple switch peut parfois engendrer des problèmes considérables sur tout le réseau. (Authentique !) Alors ajouter une verrue à un tel endroit peut être très délicat. Il faut nécessairement faire une étude architecturale avant sa mise en place, tout en espérant que l’état aura bien entendu prévu cette étude.

Parce qu’il faut quand même rappeler de quoi l’on parle: mettre en place un équipement sur lequel il n’y a aucune visibilité et aucun contrôle à un endroit stratégique du réseau, avec un risque potentiel de panne ou de détérioration des performances, le tout piloté par un tiers, peut être même un concurrent tout en donnant un accès à la totalité des données des clients !

J’ai mis volontairement le mot « concurrent » car il est vraisemblable que l’état fasse appel à un prestataire de services pour mettre en place ce genre d’architecture; en conséquence, les risques de rencontrer un concurrent ne sont donc pas à exclure.

Maintenant, j’ai beaucoup de mal à croire qu’une direction accepte la mise en place de ce genre d’architecture: la première erreur pourrait être fatale. Il ne faut tout de même pas oublier que le cœur de métier d’un datacenter ou d’un opérateur est le réseau. Si celui-ci ne fonctionne pas correctement alors les affaires en prendront forcément un coup. La direction peut toujours invoquer le risque business, beaucoup trop fort. Et en plus, il ne s’agit pas ici d’un cas de force majeur, mais bien de prévention; le jeu n’en vaut certainement pas la chandelle.

L’état devra alors se tourner vers un autre moyen.

SPAN, RSPAN et ERSPAN

Ces mots barbares dévoilent en fait la technologie à utiliser pour surveiller massivement un réseau. Comme je l’ai expliqué dans le précédent chapitre, il me semble très difficile d’installer un équipement en coupure pour surveiller le réseau. A la place, il faut plutôt utiliser ce type de topologie:

Maintenant, pour activer une surveillance, on utilise ce que l’on appelle le « port-mirroring »; c’est à dire que tout ce qui va arriver sur les ports de mon switch va être dupliqué vers un port particulier sur lequel on aura branché une de ces fameuses boites noires. Ça, c’est ce que l’on appelle un SPAN, du moins chez Cisco, l’un des principaux équipementiers réseau. Le RSPAN fait la même chose, mais il ne copie pas les données sur un port physique mais dans un VLAN, un réseau virtuel. Le but est donc d’acheminer en Ethernet les informations dans un endroit à proximité, sans doute dans une autre baie ou une autre pièce. Finalement, le ERSPAN transporte les données en IP, c’est à dire que le réceptacle pourra être n’importe quel système sur Internet, comme par exemple, la DSGSI, la NSA, vous même sur votre petite ADSL 20 mégas.

Cette technologie a l’avantage de ne pas être en coupure et agit passivement, elle est donc sans risque pour l’opérateur. Mais elle a tout de même ses propres limites: elle fonctionne à capacité réduite.

Un switch dispose généralement de 24 ou 48 ports, chacun de ces ports a une vitesse déterminée: 100 mégabits, 1 gigabits, 10 gigabits, etc. Si maintenant, je veux être capable d’accueillir toutes les données d’un port, je dois disposer de la même bande passante, voir même plus. Sinon, je risque la congestion, c’est à dire que je vais perdre des informations. Je détaille un peu plus: un switch n’est rien d’autre qu’une grosse prise multiple intelligente et qui a une spécialité: la commutation. C’est à dire que lorsqu’il reçoit un paquet sur un port, il s’empresse de le commuter sur tous les autres, du moins tous ceux qui sont dans le même VLAN. Pour ce faire, on utilise souvent un processeur spécialisé, un ASIC. En interne, le switch dispose d’un tampon où il va stocker les données juste avant la commutation. Ce tampon se vide à la vitesse de la commutation (1 giga, 10 giga, etc.). Si maintenant, le switch ne dispose pas suffisamment de temps pour vider son tampon, l’information est « droppée », et donc peut être potentiellement perdue.

Le problème de la bande passante

On voit donc bien ici toute la difficulté pour surveiller massivement un réseau: si l’on ne calibre pas suffisamment la capacité d’absorption du trafic d’un équipement tel qu’une de ces fameuses boites noires,  on s’expose à une perte d’information. Maintenant, soyons honnête, il faut quand même relativiser mes affirmations ici. En réalité, dans une infrastructure telle que celle que je vous ai présenté dans le chapitre précédent, un port réseau utilise rarement toute sa bande passante. Cette dernière peut beaucoup fluctuer en fonction de la nature du trafic analysé. Par exemple, des requêtes de type Web ne sont pas très gourmandes en matière de bande passante, contrairement à d’autres: flux, vidéo, FTP, etc.  On peut donc considérer qu’il n’est pas forcément nécessaire d’avoir une boite noire pour surveiller un serveur: on peut facilement en utiliser une seule pour surveiller plusieurs équipements. Néanmoins, il est clair que ce nombre est quand même limité et qu’en conséquence, il faut prévoir un nombre tout de même conséquent de boite noires pour surveiller tout un réseau, surtout si celui-ci comporte des centaines, voir des milliers de serveurs.

Mais attention, dans mon premier exemple, celle où la boite noire intervient en coupure, il est absolument nécessaire d’éviter la congestion sous peine de dégrader significativement les performances du réseau. La boite noire agissant comme un goulet d’étranglement, celle-ci doit donc disposer de la même bande passante que les équipements sur laquelle la boite noire est connectée. Par exemple, si je travaille avec des switch 10 gigabits, la boite noire doit pouvoir supporter du 10 gigabits.

Pour que vous comprenez bien la principale problématique de la surveillance, il faut imaginer que la boite noire est un entonnoir dans lequel on verse de l’eau en continu, mais avec un gros risque que cette eau déborde de l’entonnoir.

L’exemple OVH en guise de conclusion

Je termine ici en vous montrant l’exemple d’OVH qui héberge Pagasa. Le plan du réseau d’OVH est particulièrement intéressant. On y découvre tout son maillage et ses interconnexions avec les autres continents: Etats-Unis et Asie. Mais la chose encore plus intéressante, de mon point de vue est la volumétrie qui y apparaît: les ordres de grandeur sont assez éloquents; par exemple, la bande passante allouée au trafic qui va de France au Royaume-Unis monte à 480 gigabits; celle qui va vers la Belgique, 600 gigabits ! Si je pars sur l’hypothèse qu’une boite noire est capable de gérer du 10 gigabit, rien que pour gérer ces deux monstrueuses connexions, il faudra pas moins de 108 boites noires ! Et je rappelle qu’il ne s’agit là que d’un seul opérateur et qui n’est pas le plus gros. A la question que vous allez certainement me poser sur les moyens à mettre en oeuvre pour surveiller tout cela, je vous répondrais tout bonnement: « C’est très simple, il suffit de construire un autre OVH à côté ».