FR3044195A1 - Procede et dispositif de traitement d'une annonce non legitime d'un bloc d'adresses ip - Google Patents

Abstract

L'invention vise un procédé de traitement, par un dispositif d'un premier réseau de télécommunications, d'une annonce non légitime d'un bloc d'adresses IP émise par un deuxième réseau distinct du premier réseau, ce procédé comprenant, sur détection (E10) de cette annonce non légitime : - une étape de vérification (E20) destinée à déterminer si un traitement automatique de l'annonce non légitime doit être ou non activé ; - le cas échéant, une étape de traitement automatique (E30-E50) de l'annonce non légitime comprenant : ○ une étape de détermination automatique (E40) d'au moins une contre-annonce annonçant un bloc d'adresses IP équivalent ou plus spécifique que le bloc d'adresses IP annoncé dans l'annonce non légitime ; et ○ une étape d'émission automatique (E50) de ladite au moins une contre-annonce vers un réseau pair.

Description

Arrière-plan de l'invention L'invention se rapporte au domaine général des télécommunications.

Elle concerne plus particulièrement le routage dans un réseau de télécommunications constitué d'une multitude de réseaux (ou sous-réseaux) administrés par des acteurs indépendants (ex. entreprises, administrations, opérateurs de télécommunications, fournisseurs d'accès, etc.) et interconnectés entre eux. Un tel réseau de télécommunications est par exemple le réseau public Internet.

De façon connue, le protocole de routage BGP (Border Gateway Protocol) est utilisé par les acteurs du réseau public Internet pour s'interconnecter et échanger entre eux des informations de routage (i.e. des routes) permettant l'acheminement de leur trafic sur le réseau. Ce protocole est décrit notamment dans le document RFC 4271 édité par l'IETF (Internet Engineering Task Force) et intitulé « A Border Gateway Protocol 4 (BGP-4) », janvier 2006.

Dans la terminologie BGP, chaque réseau indépendant est appelé un système autonome ou AS (pour « Autonomous System » en anglais), et est identifié par un numéro d'AS unique dans le réseau Internet. Chaque AS gère des blocs d'adresses IP (Internet Protocol) qu'il peut éventuellement diviser en blocs d'adresses IP de plus petites tailles pour ses besoins ou ceux de ses clients. De façon connue, chaque adresse IP administrée par un réseau est constituée de deux groupes de bits : un groupe de bits de poids forts (i.e. les bits les plus à gauche de l'adresse IP) aussi appelé préfixe et correspondant à l'adresse du réseau, et un groupe de bits de poids faibles (i.e. les bits restant de l'adresse IP), correspondant à la partie hôte de l'adresse IP (autrement dit aux interfaces présentes dans le réseau).

Dans la suite de la description, la notation CIDR (Classless Inter-Domain Routing) est adoptée pour représenter les adresses IP et les préfixes des réseaux. Cette notation consiste à ajouter un caractère 7' à une adresse IP, suivi du nombre de bits de poids forts constituant le préfixe du réseau. Ainsi par exemple, pour une adresse IPv4 codée sur 32 bits ou pour une adresse IPv6 codée sur 128 bits, /24 ou /16 indiquent que le préfixe du réseau est constitué de 24 ou de 16 bits.

Cette notation 7x' définit de façon équivalente un masque de réseau, qui permet de distinguer la partie de l'adresse IP utilisée pour le routage des paquets vers le réseau de celle utilisable pour numéroter les hôtes du réseau. Le masque de réseau est constitué généralement, dans sa forme binaire, de 1 suivis de 0. Ainsi /24 définit en notation décimale le masque de réseau 255.255.255.0 ; /16 définit le masque de réseau 255.255.0.0, etc. La notation 91.198.174.2/19 désigne donc l'adresse IP 91.198.174.2 avec le masque de réseau 255.255.224.0, et signifie que les 19 premiers bits de l'adresse IP sont dédiés à l'adresse (préfixe) du réseau administrant cette adresse IP, le reste des bits désignant l'adresse IP de l'hôte à l'intérieur du réseau.

Deux adresses IP appartiennent donc à un même réseau si elles ont en commun les bits du masque de réseau, ou encore le préfixe du réseau. Le masque de réseau, ou de façon équivalente le préfixe du réseau, permet de définir une plage (ou un bloc) d'adresses IP gérées par le réseau. Ainsi, par exemple, le préfixe 2.1.0.0/24 signifie que le bloc d'adresses IPv4 géré par le réseau comprend 2®=256 adresses IP allant de 2.1.0.0 à 2.1.0.255.

Le protocole BGP permet aux AS interconnectés d'échanger les préfixes (c'est-à-dire les blocs d'adresses IP) que chacun d'entre eux administrent et de partager leurs routes pour atteindre une adresse IP. La figure 1 illustre un exemple de plusieurs AS interconnectés par l'intermédiaire du protocole BGP.

Chaque AS peut comprendre un ou plusieurs routeurs internes ainsi qu'un ou plusieurs routeurs de bordure, situés à la frontière de l'AS. Ces routeurs externes propagent (i.e. annoncent de proche en proche), via des annonces conformes au protocole BGP, les informations d'accessibilité à l'AS et collectent les informations d'accessibilité des autres AS. Chaque annonce d'un AS indique à son AS pair (i.e. à son AS voisin), et réciproquement, qu'il sait acheminer le trafic à destination des préfixes listés dans l'annonce. Chaque route annoncée par un AS est constituée d'un préfixe de destination ainsi que d'attributs dont le chemin d'AS (ou « AS path » en anglais).

Ainsi, dans l'exemple de la figure 1, cinq AS sont considérés et interconnectés via le protocole BGP : — le réseau ou AS identifié par le numéro 3215 (aussi désigné par AS 3215), qui annonce via BGP à son AS pair (i.e. voisin), identifié par le numéro d'AS 5511, les préfixes qu'il gère (autrement dit, les blocs d'adresses IP qu'il gère), en précisant être à l'origine de l'annonce. Dans l'exemple de la figure 1, l'AS 5511 est le fournisseur de transit ou transitaire de l'AS 3215, et l'AS 3215 annonce le préfixe 2.1.0.0/16 qui correspond à un bloc d'adresses IPv4 de 21δ=65536 adresses IP ; — le réseau AS 5511 annonce à ses réseaux pairs, identifiés respectivement par les numéros d'AS 6453 et 6461, le préfixe IP 2.1.0.0/16 en précisant que le réseau à l'origine de l'annonce est l'AS 3215 ; — le réseau AS 6453 annonce à ses réseaux pairs, et en particulier au réseau identifié par le numéro d'AS 11260, le préfixe IP 2.1.0.0/16 en précisant que le réseau à l'origine de l'annonce est l'AS 3215 et qu'il est possible de passer par l'AS 5511 et l'AS 6453 pour joindre les adresses associées à ce préfixe ; — le réseau AS 6461 annonce à ses réseaux pairs, et en particulier au réseau AS 11260, le préfixe IP 2.1.0.0/16 en précisant que le réseau à l'origine de l'annonce est l'AS 3215 et qu'il est possible de passer par l'AS 5511 et l'AS 6461 pour joindre les adresses associées à ce préfixe.

Selon cet exemple, le réseau AS 11260 sait ainsi que pour joindre l'adresse IP 2.1.0.1/32 appartenant au bloc d'adresses IP 2.1.0.0/16 annoncé par l'AS 3215, il peut passer soit par l'AS 6453 soit par l'AS 6461, puis par l'AS 5511 et par l'AS 3215 qui est à l'origine de l'annonce. La route ainsi définie représente le chemin d'AS mentionné précédemment, c'est-à-dire, l'ensemble des AS qui seront traversés par un paquet émis par une machine de l'AS 11260 à destination d'adresse IP 2.1.0.1/32.

On peut noter qu'en cas de défaillance de l'AS 6453 (respectivement de l'AS 6461), l'AS 11260 peut basculer sur l'AS 6461 (respectivement sur l'AS 6453) pour acheminer les paquets IP vers le préfixe 2.1.0.0/16. Cette caractéristique du réseau Internet contribue fortement à sa résilience. Des mécanismes de redondance peuvent en outre être envisagés au niveau des routeurs de bordure des AS : plusieurs routeurs d'un AS peuvent annoncer les mêmes routes vers plusieurs routeurs d'un AS pair et réciproquement, pour couvrir les cas communs de pannes simples de routeurs.

Le choix entre les routes proposées respectivement par l'AS 6453 et l'AS 6461 se fait en fonction de la politique de routage définie par l'opérateur de l'AS 11260. Cette politique peut considérer différents critères, comme notamment : — des critères commerciaux négociés (ex. coût au Gbit/s, capacité déployée, qualité du réseau, etc.). L'AS 11260 peut par exemple systématiquement privilégier la route passant par l'AS 6453 et n'utiliser la route passant par l'AS 6461 qu'en secours ; — des critères techniques, et notamment des critères classiquement envisagés avec le protocole BGP tels que : o les annonces correspondant à des préfixes plus spécifiques (autrement dit aux plus petits blocs d'adresses annoncés ou encore aux masques les plus longs) sont prioritaires sur les annonces correspondant à un préfixe moins spécifique (c'est-à-dire à un bloc d'adresses englobant les blocs d'adresses précédemment évoqués). Ainsi pour joindre l'adresse 2.1.3.3/32, la route sera celle annoncée pour le préfixe 2.1.3.0/24 plutôt que celle annoncée pour le préfixe 2.1.0.0/16 moins spécifique. On note que l'annonce la plus spécifique usuellement utilisée sur BGP pour les adresses IPv4 codées sur 32 bits est le /24 (qui correspond à un bloc de 256 adresses) ; o les annonces ayant un chemin d'AS plus court (c'est-à-dire transitant par le moins de réseaux) sont prioritaires sur les annonces ayant un chemin d'AS plus long.

De façon connue, le protocole BGP ne prévoit aucun mécanisme de sécurité fort, tel que par exemple un mécanisme cryptographique de signature, qui permettrait de contrôler les chemins annoncés par les AS. Ceci le rend vulnérable à différents types d'incidents (erreurs de configuration, bugs logiciels, usurpations de préfixes aussi couramment désignées par « hijacking » en anglais, etc.), ce qui nuit à la résilience du réseau Internet.

Un des incidents les plus célèbres d'usurpation de préfixes est celui créé par Pakistan Telecom le 24 février 2008, et rappelé brièvement ici. Avant l'incident, Youtube annonçait le bloc d'adresses IP 208.65.152.0/22. Sur ordre du gouvernement pakistanais, le fournisseur Pakistan Telecom a annoncé de façon non légitime à 18h47, à son transitaire PCCW, un préfixe 208.65.153.0/24 plus spécifique que celui annoncé par YouTube. Comme mentionné précédemment, lorsqu'une table de routage contient un réseau et un sous-réseau plus spécifique (i.e. dont le masque est plus long), les routes correspondant aux préfixes les plus spécifiques l'emportent. Le transitaire n'ayant pas mis en place de filtres sur les annonces de son client Pakistan Telecom, la totalité du trafic à destination de ce préfixe de YouTube a donc été redirigé vers Pakistan Telecom, rendant ainsi YouTube indisponible sur l'ensemble du réseau Internet.

Il a fallu attendre 20h07 pour avoir une réaction de YouTube. YouTube a alors envoyé une contre-annonce (i.e. une annonce concurrente) avec un préfixe en /24, c'est-à-dire équivalent à celui annoncé par Pakistan Telecom, cette contre-annonce déclenchant, conformément aux critères techniques évoqués précédemment, un routage selon le chemin le plus court. Puis YouTube a envoyé deux contre-annonces avec des préfixes en /25, alors privilégiées par rapport à l'annonce erronée en /24 car annonçant des préfixes plus spécifiques que l'annonce erronée. Le transitaire PCCW a commencé à réagir vers 20h50 en allongeant artificiellement les routes vers Pakistan Telecom pour qu'elles ne soient plus sélectionnées, puis en supprimant toutes les routes annoncées par l'opérateur pakistanais. L'incident fut clos vers 21h00.

Autrement dit, il a fallu plus de 2h pour venir à bout de cet incident. Il convient de noter que les solutions actuelles visant à contrer l'impact sur les réseaux de ce type d'incident s'appuient sur une intervention humaine : à partir d'une alerte remontée par exemple par une sonde à un technicien de l'AS victime de l'incident, le technicien identifie l'annonce non légitime en cause puis collecte des informations sur l'AS à l'origine de cette annonce. Le technicien doit par ailleurs identifier les routeurs chargés d'annoncer légitimement le bloc d'adresses usurpé, déterminer une ou plusieurs contre-annonces pour contrer l'annonce non légitime, et se connecter sur les routeurs identifiés pour les configurer afin qu'ils émettent la ou les contre-annonces ainsi déterminées. Une phase d'observation du trafic sur le réseau par le technicien s'ensuit alors pour voir si les contre-annonces émises par les routeurs ont un effet sur l'incident. Si les perturbations liées à l'incident subsistent, du fait de l'inefficacité par exemple des contre-annonces initialement configurées ou d'une erreur de configuration des routeurs commise par le technicien, ce dernier doit déterminer une nouvelle contre-annonce et reconfigurer les routeurs de l'AS victime de l'incident.

Le délai résultant de l'intervention du technicien pour résoudre l'incident peut avoir un impact plus ou moins important sur les clients de l'AS victime de l'incident. Durant ce temps en effet, l'AS peut être rendu en tout ou partie indisponible pour ses clients. Si une telle indisponibilité a souvent des conséquences limitées pour un particulier (gêne), elle peut avoir en revanche des conséquences bien plus importantes pour un professionnel de type entreprise ou service public (ex. service rendu par le professionnel indisponible).

En vue d'améliorer la résilience des connexions BGP et ainsi des interconnexions sur le réseau Internet, l'ANSSI (Agence Nationale de la Sécurité des Systèmes d'information) a publié un guide intitulé « Bonnes pratiques de configuration de BGP », septembre 2013, disponible à l'URL http://www.ssi.aouv.fr/uploads/IMG/pdf/auide configuration BGP.pdf. Ce guide incite notamment la mise en œuvre de mécanismes d'authentification des messages BGP afin de sécuriser les sessions BGP ainsi que de mécanismes de filtrage des annonces BGP afin de limiter l'impact sur le réseau des erreurs de configurations (ex. filtrage sur des préfixes réservés, sur des préfixes attribués à un pair, sur des préfixes trop spécifiques, filtrage des routes par défaut, suppression des numéros d'AS privés, filtrage sur un nombre maximum de préfixes annoncés, ou encore sur le chemin d'AS des routes annoncées par les pairs, etc.).

Ces mécanismes d'authentification et de filtrage constituent un premier niveau de réponse aux incidents dont sont victimes les réseaux utilisant le protocole BGP. Toutefois, ils ne sont pas toujours efficaces et peuvent s'avérer complexes à mettre en œuvre, notamment au niveau des réseaux des transitaires qui sont interconnectés avec de nombreux AS pairs.

Des travaux sont en cours à IlETF visant à normaliser une infrastructure de routage sécurisée RPKI (Resource Public Key Infrastructure) ayant pour objectif de certifier les préfixes annoncés par les AS d'origine.

Cependant cette technologie est aujourd'hui peu déployée car beaucoup trop complexe. Elle nécessite notamment l'introduction de contrats d'interface jusque-là inexistants entre les routeurs BGP et des serveurs de validation RPKI. Par ailleurs, la certification prévue par l'infrastructure RPKI porte uniquement sur l'AS d'origine, et ne permet pas de lutter contre des attaques de type de « l'homme du milieu » aussi plus communément désignées par « Man-In-the-Middle Attacks» selon lesquelles le chemin d'AS est modifié sans pour autant modifié l'AS d'origine.

Le groupe de travail SIDR (Secure Inter-Domain Routing) de IlETF s'intéresse à l'extension du mécanisme RPKI au protocole BGP. Toutefois, son efficacité repose sur une adoption mondiale de RPKI, qui n'est aujourd'hui utilisée que pour 5% des préfixes annoncés.

Il existe donc un besoin d'une solution simple, efficace et rapide à mettre en œuvre permettant de remédier aux insuffisances des solutions envisagées aujourd'hui.

Objet et résumé de l'invention

Pour répondre notamment à ce besoin, l'invention propose un procédé de traitement, par un dispositif d'un premier réseau de télécommunications, d'une annonce non légitime d'un bloc d'adresses IP émise par un deuxième réseau de télécommunications distinct du premier réseau, ce procédé comprenant, sur détection de l'annonce non légitime : — une étape de vérification destinée à déterminer si un traitement automatique de l'annonce non légitime doit être ou non activé ; — le cas échéant, une étape de traitement automatique de l'annonce non légitime comprenant : o une étape de détermination automatique d'au moins une contre-annonce annonçant un bloc d'adresses IP équivalent ou plus spécifique que le bloc d'adresses IP annoncé dans l'annonce non légitime ; et o une étape d'émission automatique de ladite au moins une contre-annonce vers un réseau pair.

Corrélativement, l'invention vise aussi un dispositif d'un premier réseau de télécommunications, configuré pour traiter une annonce non légitime d'un bloc d'adresses IP émise par un deuxième réseau de télécommunications distinct du premier réseau, ce dispositif comprenant : — un module de détection de l'annonce non légitime émise par le deuxième réseau ; — un module de vérification configuré pour déterminer si un traitement automatique de l'annonce non légitime doit être ou non activé ; — un module de traitement automatique de l'annonce non légitime, activé le cas échéant par le module de vérification et comprenant : o un module de détermination automatique d'au moins une contre-annonce annonçant un bloc d'adresses IP équivalent ou plus spécifique que le bloc d'adresses IP annoncé dans l'annonce non légitime ; et o un module d'émission automatique de ladite au moins une contre-annonce vers un réseau pair ; le module de vérification et le module de traitement automatique étant activés par le module de détection sur détection de l'annonce non légitime émise par le deuxième réseau.

Le premier et le deuxième réseaux sont des (sous-)réseaux de télécommunications distincts et indépendants (i.e. administrés par des opérateurs distincts et indépendants). Ces réseaux ne sont pas nécessairement des réseaux pairs, mais appartiennent à un réseau constitué d'une multitude de réseaux tel que par exemple le réseau public Internet.

Par annonce non légitime, on entend une annonce propagée par un réseau ou AS d'un préfixe ou plus généralement d'un bloc d'adresses IP usurpé par l'AS, ce bloc d'adresses étant administré par un autre réseau. Dans un contexte privilégié d'application, l'annonce non légitime et la ou les contre-annonces émises conformément à l'invention peuvent s'appuyer sur la notation CIDR introduite précédemment (et notamment annoncer des préfixes de réseau qui, comme indiqué précédemment, correspondent à une plage d'adresses IP), et être conformes au protocole BGP (Border Gateway Protocol). Toutefois, d'autres notations et d'autres protocoles permettant d'interconnecter différents réseaux et de propager des annonces comme le protocole BGP peuvent être envisagés en variante. L'invention apporte donc une solution pragmatique relativement simple et rapide à mettre en œuvre aux insuffisances de l'état de la technique, cette solution consistant à répondre de façon automatique aux annonces non légitimes qui sont propagées sur un réseau dès que de telles annonces sont détectées (par exemple par des sondes ou autres dispositifs d'alarme présents dans le réseau). Cette réponse automatique s'appuie sur une ou plusieurs contre-annonces annonçant des blocs d'adresses IP équivalents ou plus spécifiques que le bloc d'adresses annoncés dans l'annonce non légitime, afin de concurrencer cette dernière sur le réseau (c'est-à-dire d'entrer en conflit avec elle) voire d'annuler ses effets (notamment dans le cas de contre-annonces plus spécifiques) pour récupérer le trafic détourné par l'annonce non légitime. L'impact des annonces non légitimes sur les réseaux légitimes est ainsi réduit, une action contre ces annonces étant mise en place très rapidement. L'automatisation de l'émission des contre-annonces permet de s'affranchir d'une intervention humaine, qui peut occasionner une certaine latence dans le traitement de l'incident provoqué par l'annonce non légitime, et être en outre potentiellement entachée d'erreur(s). L'invention permet en outre de lutter contre une pratique courante adoptée par des AS tiers malveillants et qui consiste à propager une annonce non légitime, puis à la supprimer après un laps de temps correspondant à une intervention humaine (ex. 30 minutes) permettant de traiter cette annonce non légitime, puis à émettre une nouvelle annonce non légitime portant sur un autre bloc d'adresses IP, etc. Grâce à l'invention, cette dynamique peut être cassée, l'intervention mise en oeuvre contre l'annonce non légitime étant très rapide et empêchant un tel mode de fonctionnement.

Avantageusement, conformément à l'invention, l'automatisation du traitement des annonces non légitimes est encadrée. Plus précisément, une telle automatisation n'est mise en œuvre que si un tel traitement automatique est pertinent et ne vient pas typiquement aggraver la situation du réseau légitime. En effet, le traitement automatique et systématique des annonces non légitimes, dès leur détection, pourrait entraîner un emballement du dispositif du traitement via par exemple l'émission d'un nombre non contrôlé de contre-annonces. Au contraire, dans l'invention, on vérifie préalablement qu'un traitement automatique est approprié avant de déclencher celui-ci.

Une telle étape de vérification comprend par exemple une comparaison par rapport à un seuil prédéterminé d'un nombre d'annonces non légitimes en cours de traitement par le dispositif du premier réseau, un traitement automatique de l'annonce non légitime étant activé si le nombre d'annonces non légitimes en cours de traitement est inférieur au seuil prédéterminé.

Via une telle étape de vérification, il s'agit de garantir qu'un trop grand nombre de contre-annonces ne sont pas émises simultanément sur le premier réseau, ce qui pourrait entraîner des débordements ou des sur-incidents. En effet, chaque annonce non légitime accroît le trafic sur le réseau en raison des contre-annonces émises pour y remédier. En outre, si le premier réseau vient à annoncer trop de routes par rapport au nombre de routes qu'il annonce usuellement, il peut venir à dépasser un seuil configuré le cas échéant au niveau des autres AS et fixant le nombre d'annonces maximal autorisé provenant du premier réseau.

Par ailleurs, lorsque le nombre d'annonces non légitimes en cours de traitement est supérieur ou égal au seuil prédéterminé, un traitement automatique de l'annonce non légitime est activé si (et préférentiellement seulement si) le bloc d'adresses IP annoncé dans l'annonce non légitime est un bloc d'adresses IP identifié comme prioritaire, par exemple parce qu'il est administré par un client professionnel versus un client particulier ou résidentiel, ou par un service public, etc. L'invention permet ainsi un traitement différencié en fonction d'une priorité affectée aux adresses IP concernées par l'annonce non légitime et une intervention dans les plus brefs délais si ces adresses IP sont considérées comme prioritaires.

Le procédé de traitement selon l'invention peut être mis en oeuvre à différents niveaux du réseau. Ainsi, le premier réseau peut être : — le réseau (légitime) gérant le bloc d'adresses IP annoncé dans l'annonce non légitime ; — un réseau d'un opérateur de transit du réseau gérant le bloc d'adresses IP annoncé dans la l'annonce non légitime ; ou — un réseau tiers.

La mise en œuvre de l'invention au niveau d'un réseau transitaire plutôt que dans le réseau légitime administrant le bloc d'adresses IP annoncé dans l'annonce non légitime permet d'accroître l'efficacité et la portée du traitement automatique préconisé par l'invention. En effet, d'une part, le chemin d'AS annoncé dans la contre-annonce est plus court, celle-ci étant générée par le réseau transitaire et non par le réseau légitime impacté.

En outre, un tel réseau de transit peut avoir une portée internationale et être interconnecté à de nombreux pairs ce qui permet en raison de cette position centrale au cours du réseau une propagation plus rapide et plus importante des contre-annonces émises automatiquement conformément à l'invention.

Le réseau transitaire peut également, dans ses contre-annonces, influencer les chemins adoptés par les tiers en raison des régies de priorisation des annonces existantes selon BGP et qui visent à privilégier les chemins les plus courts.

Dans un mode particulier de réalisation, la détection (automatique) de l'annonce non légitime par le dispositif du premier réseau comprend la réception par ce dispositif d'un message d'alerte émis par un dispositif de détection d'annonces non légitimes.

Un tel dispositif de détection est par exemple une sonde telle que déployée aujourd'hui à divers endroits dans les réseaux pour surveiller l'avènement d'annonces non légitimes et alarmer les réseaux victimes de ces annonces.

Dans un mode particulier de réalisation, la détection de l'annonce non légitime par le dispositif du premier réseau comprend : — une étape de réception de l'annonce ; — une étape de comparaison du bloc d'adresses IP annoncé dans l'annonce avec des adresses IP gérées par le premier réseau ; l'annonce étant détectée comme non légitime en cas de recoupement du bloc d'adresses IP annoncé dans l'annonce avec des adresses IP gérées par le premier réseau.

Ce mode de réalisation peut être envisagé par exemple dans le cas où le premier réseau est le réseau (légitime) gérant le bloc d'adresses IP annoncé dans l'annonce non légitime, au niveau d'un routeur de bordure du réseau légitime. Ceci permet d'améliorer encore plus le temps de réaction aux annonces non légitimes.

Dans un autre mode de réalisation, le procédé de traitement comprend en outre une étape d'émission, à destination du deuxième réseau, d'une notification signalant l'annonce non légitime.

Cette notification permet d'avertir le deuxième réseau à l'origine de l'annonce non légitime. Un tel avertissement peut permettre à ce dernier de supprimer rapidement son annonce non légitime dans le cas où celle-ci a été émise notamment suite à une erreur de configuration d'un routeur de bordure du deuxième réseau.

Dans un autre mode de réalisation, le procédé de traitement comprend en outre une étape de suppression de ladite au moins une contre-annonce après avoir détecté une cessation de l'annonce non légitime.

Ce mode de réalisation permet de limiter les contre-annonces émises sur le réseau et le trafic engendré en découlant.

En outre, suite à la suppression de ladite au moins une contre-annonce, le procédé de traitement peut alors comprendre une étape de mise à jour du nombre d'annonces non légitimes en cours de traitement (et plus particulièrement de décrémentation du nombre d'annonces non légitimes en cours de traitement en fonction du nombre de contre-annonces supprimées). Ceci rend possible l'émission rapide de nouvelles contre-annonces le cas échéant en cas de nouvel incident sans risquer d'emballement du réseau. Dans un mode particulier de réalisation, les différentes étapes du procédé traitement sont déterminées par des instructions de programmes d'ordinateurs.

En conséquence, l'invention vise aussi un programme d'ordinateur sur un support d'informations, ce programme étant susceptible d'être mis en oeuvre dans un dispositif de traitement ou plus généralement dans un ordinateur, ce programme comportant des instructions adaptées à la mise en oeuvre des étapes d’un procédé de traitement tel que décrit ci-dessus.

Ce programme peut utiliser n'importe quel langage de programmation, et être sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet, tel que dans une forme partiellement compilée, ou dans n'importe quelle autre forme souhaitable. L'invention vise aussi un support d'informations lisible par un ordinateur, et comportant des instructions d'un programme d'ordinateur tel que mentionné ci-dessus.

Le support d'informations peut être n'importe quelle entité ou dispositif capable de stocker le programme. Par exemple, le support peut comporter un moyen de stockage, tel qu'une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore un moyen d'enregistrement magnétique, par exemple une disquette (floppy dise) ou un disque dur. D'autre part, le support d’informations peut être un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par radio ou par d'autres moyens. Le programme selon l'invention peut être en particulier téléchargé sur un réseau de type Internet.

Alternativement, le support d'informations peut être un circuit intégré dans lequel le programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution du procédé en question.

Selon un autre aspect, l'invention vise un réseau de télécommunications comprenant une pluralité de réseaux indépendants interconnectés (par exemple par l'intermédiaire du protocole BGP ou via un autre protocole, cette pluralité de réseaux comprenant au moins un premier réseau et un deuxième réseau, ledit premier réseau comprenant un dispositif de traitement selon l'invention configuré pour traiter une annonce non légitime d'un bloc d'adresses IP émise par le deuxième réseau.

Dans un mode particulier de réalisation, le réseau comprend au moins un dispositif d'alarme apte à détecter ladite annonce non légitime émise par le deuxième réseau et à envoyer un message d'alerte au dispositif de traitement du premier réseau l'informant de la détection de cette annonce non légitime.

Le réseau bénéficie des mêmes avantages cités précédemment pour le procédé et le dispositif de traitement.

On peut également envisager, dans d'autres modes de réalisation, que le procédé de traitement, le dispositif de traitement et le réseau selon l'invention présentent en combinaison tout ou partie des caractéristiques précitées.

Brève description des dessins D'autres caractéristiques et avantages de la présente invention ressortiront de la description faite ci-dessous, en référence aux dessins annexés qui en illustrent un exemple de réalisation dépourvu de tout caractère limitatif. Sur les figures : — la figure 1, déjà décrite, représente, de façon schématique, des réseaux interconnectés via le protocole BGP ; — la figure 2 représente un réseau de télécommunications conforme à l'invention, dans un premier mode de réalisation ; — la figure 3 illustre l'architecture matérielle d'un routeur de bordure d'un réseau du réseau de télécommunications illustré à la figure 2 ; — la figure 4 représente un dispositif de traitement conforme à l'invention, dans le premier mode de réalisation ; — la figure 5 illustre, sous forme d'ordinogramme, les principales étapes d'un procédé de traitement tel que mis en oeuvre par le dispositif de traitement de la figure 4 ; et — la figure 6 représente un réseau de télécommunications conforme à l'invention, dans un deuxième mode de réalisation.

Description détaillée de l'invention

La figure 2 représente un réseau NW conforme à l'invention, dans un premier mode particulier de réalisation.

Le réseau NW est par exemple ici le réseau public Internet. Il est constitué d'une multitude de réseaux, indépendants et interconnectés. Dans l'exemple de la figure 1, on envisage six réseaux ou systèmes autonomes (AS) référencés respectivement par AS i, i=l,...,6. Cet exemple n'est bien entendu donné qu'à titre illustratif, et d'autres configurations de réseaux peuvent être envisagées.

Les AS 1 à 5 sont identifiés respectivement par les numéros d'AS 3215, 5511, 6453, 6461 et 11260 déjà considérés sur la figure 1. L'AS 6 est un réseau autonome identifié à titre illustratif dans l'exemple par l'identifiant d'AS 666.

Chaque AS comprend un ou plusieurs routeurs de bordure 7 via le(s)quel(s) il peut s'interconnecter avec un ou plusieurs autres AS dits pairs (i.e. avec les routeurs de bordure d'un autre AS), ainsi qu'éventuellement un ou plusieurs routeurs internes. Aucune limitation n'est attachée au nombre de routeurs considérés dans chaque AS. Par souci de simplification, seuls les routeurs de bordure 7 du réseau AS 1 (au nombre de 3) sont illustrés à la figure 2. Pour les autres AS, seules les interconnexions avec les réseaux pairs sont représentées (traits épais continus). Ces interconnexions sont réalisées ici par l'intermédiaire du protocole BGP, utilisé notamment pour permettre à chaque AS d'annoncer transitivement à chacun de ses pairs (i.e. à ses AS voisins) les préfixes (autrement dit, les blocs d'adresses IP) qu'il gère et propager transitivement les annonces qu'il a reçues d'autres AS pairs, de façon connue en soi.

Le réseau NW comprend également, dans le mode de réalisation décrit ici, un ou plusieurs dispositifs d'alarme aptes à détecter des annonces non légitimes propagées sur le réseau NW (aussi appelées phénomènes de hijacking). Ces dispositifs sont par exemple des sondes réparties en plusieurs endroits du réseau NW telles que des sondes Arbor Peakflow SP f http://fr.arbornetworks.eom/visibilite-reseau/visibilite-des-reseaux-pour-fournisseurs/I ou des outils tels que proposés notamment dans les projets RIS et RIPE Atlas (www.ripe.netj. ou encore BGPMon (www.bapmon.net/j. non décrits en détail ici. De façon connue en soi, un tel dispositif ou sonde est configuré avec une liste de blocs d'adresses IP (ou de préfixes) à surveiller ainsi que les numéros des AS légitimes pour annoncer les routes permettant de joindre ces blocs d'adresses. Il reçoit l'ensemble des annonces reçues par le réseau. Pour toute nouvelle annonce reçue, le dispositif ou la sonde vérifie si le bloc d'adresses IP concerné fait partie des blocs d'adresses IP à surveiller ou est un sous-bloc d'un bloc d'adresse IP à surveiller. Le cas échéant, si l'AS d'origine de l'annonce n'est pas l'AS légitime à annoncer ce bloc, une alerte est levée par le dispositif.

On suppose, dans le mode de réalisation décrit ici, que les réseaux autonomes AS 1-5 sont abonnés à ou équipés de ce type d'outils. Plus spécifiquement, on suppose par exemple que le réseau AS 1 est abonné à un service d'alarme proposé par le réseau transitaire AS 2, celui-ci étant équipé d'un dispositif d'alarme 8 alimenté par des informations émanant de sondes réparties dans le réseau NW et tel que décrit ci-dessus.

Dans le mode de réalisation décrit ici, chaque routeur de bordure 7 du réseau AS 1 a l'architecture matérielle d'un ordinateur, telle que représentée schématiquement à la figure 3.

Il comprend notamment un processeur 9, une mémoire morte 10, une mémoire vive 11, une mémoire non volatile 12 et un module de communication 13 comprenant des moyens connus en soi pour communiquer avec les réseaux pairs avec lesquels l'AS 1 est interconnecté via en particulier le protocole BGP. La mémoire morte 10 du routeur de bordure 7 constitue un support d'enregistrement conforme à l'invention, lisible par le processeur 9 et sur lequel est enregistré un programme d'ordinateur PROG (ou logiciel) conforme à l'invention comportant des instructions pour l'exécution des étapes du procédé de traitement conforme à l'invention.

Le programme d'ordinateur PROG définit ici des modules ou composants fonctionnels et logiciels du routeur de bordure 7, aptes à mettre en oeuvre les étapes du procédé de traitement selon l'invention. Ces modules logiciels définissent un dispositif de traitement (logiciel) 14 au sens de l'invention et sont susceptibles d'accéder aux et/ou de commander les ressources matérielles du routeur de bordure 7 (et notamment les ressources matérielles 9-13 citées précédemment). Ils comprennent ici, en référence à la figure 4 : — un module 14A de détection d'annonce non légitime émise par un AS (i.e. réseau) à l'encontre de l'AS 1 ; — un module 14B de vérification configuré pour déterminer si un traitement automatique des annonces non légitimes détectées par le module de détection 14A doit être ou non activé ; — un module 14C de traitement automatique des annonces non légitimes détectées, activé le cas échéant par le module de vérification 14B et comprenant : o un module 14C1 de détermination automatique de contre-annonces à ces annonces non légitimes ; et o un module 14C2 d'émission automatique de ces contre-annonces sur le réseau NW vers les AS pairs de l'AS 1. L'architecture matérielle des routeurs de bordure 7 et les modules logiciels de ces routeurs sont décrits ici en référence à l'AS 1. Toutefois, bien entendu, une architecture identique ou similaire et des modules logiciels identiques ou similaires peuvent être considérés pour les routeurs de bordure des autres AS du réseau NW.

Les fonctions des modules 14A, 14B et 14C sont détaillées ultérieurement en référence aux étapes correspondantes du procédé de traitement selon l'invention, illustrées à la figure 5.

Pour mieux illustrer les principes de l'invention, on considère ici que l'AS 1 administre le préfixe IPv4 2.1.0.0/16 (notation CIDR), et le bloc de 216=65536 adresses IP associées. De façon similaire à ce qui a été décrit précédent en référence à la figure 1, on suppose en préliminaire que : — le réseau AS 1 (aussi désigné par AS 3215) a annoncé via BGP à son AS voisin, le réseau transitaire AS 2 (ou AS 5511), le préfixe 2.1.0.0/16 qu'il gère (bloc d'adresses IP au sens de l'invention) en précisant être à l'origine de l'annonce ; — le réseau AS 2 a annoncé à ses réseaux pairs AS 3 et AS 4 (i.e. AS 6453 et AS 6461), le préfixe IP 2.1.0.0/16 en précisant que le réseau à l'origine de l'annonce est l'AS 1 et qu'il est possible de passer par lui pour joindre les adresses associées à ce préfixe ; — le réseau AS 3 a annoncé à ses réseaux pairs, et en particulier au réseau AS 5 (ou AS 11260) et au réseau AS 6 (ou AS 666), le préfixe IP 2.1.0.0/16 en précisant que le réseau à l'origine de l'annonce est l'AS 1 et qu'il est possible de passer par l'AS 2 et l'AS 3 pour joindre les adresses associées à ce préfixe ; — le réseau AS 4 a annoncé à ses réseaux pairs, et en particulier au réseau AS 5, le bloc préfixe IP 2.1.0.0/16 en précisant que le réseau à l'origine de l'annonce est l'AS 1 et qu'il est possible de passer par l'AS 2 et l'AS 4 pour joindre les adresses associées à ce préfixe.

Selon cet exemple, le réseau AS 5 sait ainsi que pour joindre l'adresse IP 2.1.0.1/32 appartenant au bloc d'adresses IP 2.1.0.0/16 annoncé par l'AS 1, il peut passer soit par l'AS 3 soit par l'AS 4, puis par l'AS 2 puis par l'AS 1 qui est à l'origine de l'annonce. La route ainsi définie représente le chemin d'AS c'est-à-dire l'ensemble des AS qui seront traversés par un paquet émis par une machine de l'AS 5 à destination de l'adresse IP 2.1.0.1/32.

On note que sur la figure 2, seule l'annonce du préfixe IP 2.1.0.0/16 géré par l'AS 1 et sa propagation dans le réseau NW est représentée par souci de simplification. Toutefois bien entendu, d'autres annonces à l'origine desquelles sont les AS 1-6 peuvent se propager dans le réseau. Par ailleurs, dans l'exemple annoncé ici, les blocs d'adresses gérés par les AS sont annoncés sous la forme d'un préfixe conforme à la norme CIDR introduite précédemment. Bien entendu, cette hypothèse n'est pas limitative en soi, et d'autres manières d'annonces un bloc d'adresses IP géré par un AS peuvent être envisagées dans le cadre de l'invention.

Le choix entre les routes proposées respectivement par l'AS 3 et l'AS 4 se fait ici en fonction de la politique de routage définie par l'opérateur de l'AS 5. Cette politique s'appuie ici sur les critères techniques suivants, classiquement considérés lors de l'utilisation du protocole BGP : — les annonces correspondant à des préfixes plus spécifiques (autrement dit aux plus petits blocs d'adresses annoncés ou encore aux masques les plus longs) sont prioritaires sur les annonces correspondant à un préfixe moins spécifique (c'est-à-dire à un bloc d'adresses englobant les blocs d'adresses précédemment évoqués). Ainsi pour joindre l'adresse 2.1.3.3/32, la route sera celle annoncée pour le préfixe 2.1.3.0/24 plutôt que celle annoncée pour le préfixe 2.1.0.0/16 moins spécifique. On note que l'annonce la plus spécifique usuellement utilisée pour les adresses IPv4 codées sur 32 bits est le /24 (qui correspond à un bloc de 256 adresses) ; et — les annonces ayant un chemin d'AS plus court (c'est-à-dire transitant par le moins de réseaux) sont prioritaires sur les annonces ayant un chemin d'AS plus long.

En variante, d'autres critères peuvent être considérés, comme alternatives ou en complément de ces critères techniques comme par exemple des critères commerciaux négociés (ex. coût au Gbit/s, capacité déployée, qualité du réseau, etc.). L'AS 5 peut par exemple systématiquement privilégier la route passant par l'AS 3 et n'utiliser la route passant par l'AS 4 qu'en secours.

On suppose maintenant que l'AS 6 est un réseau malveillant cherchant à usurper un bloc d'adresses 2.1.1.0/24 compris dans le bloc d'adresses 2.1.0.0/16 administré par l'AS 1. Plus particulièrement, on suppose ici que l'AS 6 émet selon le protocole BGP une annonce non légitime à destination de ses réseaux pairs (l'AS 3 dans l'exemple illustré à la figure 2) annonçant qu'il gère le préfixe 2.1.1.0/24 et les 2S=256 adresses IP associées (annonce représentée en traits discontinus sur la figure 2).

Conformément au mode de fonctionnement du protocole BGP, cette annonce est propagée par les AS du réseau NW via le protocole BGP de la façon suivante : — le réseau AS 3 annonce à ses AS voisins, à savoir aux réseaux AS 2 et AS 5, le préfixe IP 2.1.1.0/24 en précisant que le réseau à l'origine de cette annonce est l'AS 6 et qu'il est possible de passer par lui pour joindre les adresses associées à ce préfixe ; — le réseau AS 2 annonce à ses réseaux pairs, à savoir aux réseaux AS 2 et AS 4, le préfixe 2.1.1.0/24 en précisant que le réseau à l'origine de cette annonce est l'AS 6 et qu'il est possible de passer par l'AS 3 et par lui pour joindre les adresses associées à ce préfixe ; — le réseau AS 4 annonce à son réseau pair, à savoir le réseau AS 5 ici, le préfixe 2.1.1.0/24 en précisant que le réseau à l'origine de cette annonce est l'AS 6 et qu'il est possible de passer par l'AS 3, par l'AS 4 et par lui pour joindre les adresses associées à ce préfixe. L'annonce du préfixe 2.1.1.0/24 de l'AS 6 étant plus spécifique que l'annonce du préfixe 2.1.0.0/16 de l'AS 1 (65536 adresses IP versus 256), c'est l'annonce de l'AS 6 qui est considérée comme prioritaire par l'AS 5 conformément aux critères techniques évoques précédemment et adoptés par l'AS 5 pour le routage des paquets. Ainsi, les paquets destinés aux adresses appartenant au préfixe 2.1.1.0/24 annoncé par l'AS 6 seront routés prioritairement vers l'AS 6, au détriment de l'AS 1 qui se voit ainsi amputé d'une partie du trafic qui lui est légitimement destiné. Ainsi, les clients du réseau AS 1 utilisant les adresses associées au préfixe 2.1.1.0/24 ne peuvent plus accéder aux services fournis par le réseau AS 1 (ex. navigation Internet, etc.). L'annonce non légitime de l'AS 6 est détectée par le dispositif d'alarme 8 du réseau transitaire AS 2, de façon connue en soi et comme rappelé brièvement précédemment. Le dispositif d'alarme 8 émet alors une alarme à destination de l'AS 1 (et notamment du routeur de bordure 7 via lequel l'AS 2 est interconnecté à l'AS 1) pour le notifier de cette annonce non légitime. L'alarme remontée par le dispositif d'alarme 8 à l'AS 1 comprend par exemple tout ou partie des informations suivantes : — le bloc d'adresses IP avec lequel le dispositif d'alarme 8 est configuré (ou préfixe) et numéro d'AS légitime à annoncer ce bloc ; — des données précisant le point d'observation de l'annonce non légitime (ex. numéros d'AS, identifiant du dispositif d'alarme 8 ou de la (les) sonde(s) sur la(es)quelle(s) il s'appuie, etc.) ; — le contenu de l'annonce BGP non légitime (bloc d'adresses annoncé, chemin d'AS) ; — une action (ex. début ou fin de l'annonce) ; et — un horodatage.

Nous allons maintenant décrire, en référence à la figure 5, comment est traitée cette annonce non légitime par le routeur de bordure 7 conformément à l'invention. La figure 5 illustre les principales étapes du procédé de traitement mises en œuvre par le dispositif de traitement 14 installé sur le routeur de bordure 7 dans un mode particulier de réalisation. L'alarme émise par le dispositif d'alarme 8 est reçue par le routeur 7 via son module de communication 13 et transmise au module de détection 14A du dispositif de traitement 14 (étape E10). La réception de cette alarme par le module de détection 14A constitue une étape de détection d'une annonce non légitime émise par le réseau AS 6 au sens de l'invention.

Le module de détection 14A extrait l'annonce non légitime de l'alarme remontée par le dispositif d'alarme 8 et la transmet au module de vérification 14B pour déterminer si cette annonce doit être traitée de façon automatique par le dispositif de traitement 14 (étape test E20).

Plus particulièrement, dans le mode de réalisation décrit ici, cette vérification consiste dans un premier temps à déterminer si cette annonce non légitime est un cas isolé ou si d'autres occurrences sont en cours de traitement, et le cas échéant, si ce nombre d'occurrences est inférieur à un seuil prédéterminé. A cet effet, le module de vérification 14B compare le nombre d'annonces non légitimes en cours de traitement par le module de traitement automatique 14C (nombre désigné par N) par rapport à un seuil prédéterminé noté THR (étape E21). Par exemple THR = 10.

Si le nombre d'annonces non légitimes N en cours de traitement est inférieur au seuil THR (réponse non à l'étape E21), l'annonce non légitime émise par l'AS 6 est transmise au module 14C de traitement automatique, et le nombre N d'annonces non légitimes en cours de traitement est incrémenté de 1 (étape E30).

Si le nombre N est supérieur ou égal au seuil THR (réponse oui à l'étape E21), le module de vérification 14B vérifie alors si le bloc d'adresses IP visé par l'annonce non légitime est un bloc d'adresses IP identifié comme prioritaire (étape test E22). Les blocs d'adresses IP considérés comme prioritaires peuvent notamment avoir été préalablement définis en fonction de critères déterminés par l'opérateur de l'AS 1 (adresses IP associées à des utilisateurs « premium », à des professionnels, etc.). La liste des blocs d'adresses IP définis comme prioritaires sont par exemple stockés dans la mémoire non volatile 12 du routeur de bordure 7.

Si le bloc d'adresses IP annoncé dans l'annonce non légitime est un bloc d'adresses IP prioritaire (réponse oui à l'étape E22), l'annonce non légitime émise par l'AS 6 est transmise au module 14C de traitement automatique et le nombre N d'annonces non légitimes en cours de traitement est incrémenté de 1 (étape E30).

Sinon (réponse non à l'étape E22), l'annonce non légitime n'est pas traitée (étape E23), afin d'éviter un nombre trop important de contre-annonces émises simultanément par l'AS 1.

Sur réception de l'annonce non légitime, le module de traitement automatique 14C via son module 14C1, détermine automatiquement une ou plusieurs contre-annonces annonçant un bloc d'adresses IP (ou de façon équivalente un préfixe) équivalent ou plus spécifique que le bloc d'adresses IP annoncé dans l'annonce non légitime (étape E40).

Plus précisément, dans le mode de réalisation décrit ici, le module de détermination 14C1 applique l'heuristique suivante : — si le préfixe annoncé dans l'annonce non légitime est inférieur à 24 (24 correspondant à la taille de préfixe maximale autorisée dans les annonces entre réseaux pour des adresses IPv4), le bloc d'adresses IP associé au préfixe annoncé est divisé par 2 (ce qui revient à augmenter de 1 la taille des préfixes, par exemple on passe d'un préfixe de taille 16 à un préfixe de taille 17) et deux contre-annonces sont générées annonçant respectivement les deux sous-blocs d'adresses IP résultant (ou de façon équivalente, les deux préfixes correspondant aux deux sous-blocs d'adresses IP résultant). Ces contre-annonces étant plus spécifiques que l'annonce non légitime, elles seront privilégiées et sont donc destinées à permettre la récupération par l'AS 1 du trafic détourné via l'annonce légitime par l'AS 6 ; — si le préfixe annoncé dans l'annonce non légitime est égal à 24, une contre-annonce annonçant le même préfixe (i.e. le même bloc d'adresses IP, c'est-à-dire un bloc d'adresses IP équivalent au sens de l'invention) est générée. Cette contre-annonce équivalente à l'annonce non légitime va entrer en conflit avec celle-ci.

Bien entendu, d'autres heuristiques peuvent être appliquées pour générer une ou plusieurs contre-annonces annonçant un bloc d'adresses équivalent ou plus spécifique que celui annoncé dans l'annonce non légitime et faire stopper l'incident affectant l'AS 1. Ces heuristiques peuvent être formulées sous forme d'arbre de choix pour accélérer son exécution par le module 14C1.

La ou les contre-annonces générées par le module de détermination 14C1 sont transmises au module 14C2 d'émission automatique pour être transmises aux routeurs de bordure 7 pertinents de l'AS 1 et être émises (annoncées) par ceux-ci vers les réseaux pairs de l'AS 1 (étape E50).

Une cartographie de la situation résultant de l'émission automatique par le module 14C2 de la ou les contre-annonces déterminées par le module 14C1 est ensuite réalisée (étape E60). Cette cartographie est destinée à identifier les effets de la ou les contre-annonces ainsi émises, c'est-à-dire à établir quelle annonce parmi l'annonce non légitime et la contre-annonce est privilégiée et où dans le réseau.

Dans le mode de réalisation décrit ici, le module 14C2 émet en outre à destination de l'AS 6, via le module de communication 13 du routeur de bordure 7, une notification lui signalant l'annonce non légitime, ainsi que la situation en résultant telle qu'elle est identifiée au cours de la cartographie établie à l'étape E60.

Il convient de noter que la cartographie de la situation et l'envoi de la notification au réseau non légitime ont une application privilégiée lorsque le préfixe annoncé dans l'annonce non légitime est égal à 24 et qu'un bloc d'adresses IP équivalent est annoncé dans la contre-annonce. Dans ce cas en effet l'annonce non légitime et la contre-annonce entrent en conflit, celles-ci annonçant le même préfixe. Comme rappelé précédemment, dans un tel contexte, sauf autres critères spécifiés, les annonces ayant le chemin d'AS le plus court (c'est-à-dire transitant par le moins de réseaux) sont prioritaires sur les annonces ayant un chemin d'AS plus long. Par conséquent, la contre-annonce émise par le module 14C2 peut ne pas être suffisante pour récupérer l'ensemble du trafic détourné par l'AS 6. La notification envoyée par l'AS 1 à l'AS 6 a pour dessein de susciter une réaction de l'AS 6 et notamment la suppression par celui-ci de son annonce non légitime. Une telle action peut permettre de stopper l'incident, notamment lorsqu'une erreur de configuration est à l'origine de l'annonce non légitime émise par l'AS 6.

Si à l'étape E60, le dispositif 14 détecte la cessation de l'annonce non légitime (réponse oui à l'étape test E70), le module 14C de traitement automatique supprime immédiatement la ou les contre-annonces émises précédemment (étape E80). Ceci permet de limiter le nombre de contre-mesures actives à un instant donné et le trafic en résultant sur le réseau NW. Le compteur N est alors décrémenté de 1.

Sinon, la ou les contre-annonces sont maintenues actives, voire adaptées (par exemple en annonçant un préfixe plus long si cela est possible), tant que l'incident n'est pas clos (réponse non à l'étape test E70).

Ainsi, l'invention, via l'automatisation de la génération et de l'émission de contre-annonces sur détection d'une annonce non légitime, permet de diminuer fortement le délai de traitement de cette annonce non légitime (ramené au délai de propagation des annonces pour permettre la détection de l'annonce non légitime et d'analyse de l'annonce non légitime pour générer automatiquement une contre-annonce), et de supprimer les erreurs humaines. En outre, elle offre la possibilité de maîtriser le trafic émis sur le réseau (annonces/contre-annonces) tout en proposant un traitement différencié entre blocs d'adresses IP prioritaires et blocs d'adresses IP moins prioritaires.

Dans le premier mode de réalisation décrit ici, le routeur de bordure 7, et plus particulièrement le dispositif de traitement 14 installé sur ce routeur de bordure 7, est alerté d'une annonce non légitime par un dispositif d'alarme 8 prévu dans un autre réseau (à savoir le réseau transitaire AS 2). En variante, cette détection peut être réalisée par le routeur de bordure 7 lui-même sur réception de l'annonce dont l'AS 6 est à l'origine (annonce propagée par le réseau transitaire AS 2), par un module chargé de contrôler les annonces reçues par le routeur de bordure 7 ou directement par le module 14A de détection du dispositif de traitement 14.

Ainsi, par exemple, sur réception de l'annonce de l'AS 6, le routeur 7 peut comparer le bloc d'adresses IP ou le préfixe visé par l'annonce reçue de l'AS 6 avec les blocs d'adresses IP ou les préfixes administrés par le réseau AS 1. Si un recoupement est détecté par le routeur 7, alors l'annonce reçue de l'AS 6 est détectée comme non légitime, et transmise au module 14B de vérification du dispositif de traitement 14 pour vérifier si cette annonce non légitime doit être traitée automatiquement par le dispositif de traitement 14. Les étapes E20 à E80 sont ensuite exécutées de façon identique à ce qui a été décrit précédemment.

Dans le mode de réalisation décrit ici, le dispositif de traitement automatique de l'annonce non légitime propagée par l'AS 6 est installé sur un routeur de bordure 7 de l'AS 1.

Dans un deuxième mode de réalisation, le dispositif de traitement est hébergé par un routeur de bordure d'un réseau transitaire (par exemple le réseau AS 2) du réseau AS 1 victime de l'incident.

La figure 6 illustre ce deuxième mode de réalisation. Les entités similaires ou identiques à celles de la figure 2 sont référencées de manière identique sur la figure 6 et ne sont pas décrites de nouveau en détail. Pour mieux distinguer les différences existant avec le premier mode de réalisation, les routeurs de bordure du réseau transitaire et le dispositif de traitement automatique installé sur ces routeurs sont désignés respectivement par 7' et 14'.

Dans le deuxième mode de réalisation, le dispositif de traitement 14' et le procédé de traitement d'une annonce non légitime exécuté par le dispositif de traitement 14' sont identiques au dispositif de traitement 14 illustré à la figure 2 et au procédé de traitement décrit en référence à la figure 5 pour le premier mode de réalisation à l'exception des éléments suivants : — la liste des blocs d'adresses IP prioritaires utilisées par le module 14B' de vérification pour vérifier si un traitement automatique doit être appliqué à l'annonce non légitime est définie par l'opérateur du réseau AS 1 et transmise au réseau transitaire AS 2 pour être stockée par exemple dans une mémoire non volatile 12' du routeur 7' du réseau AS 2 hébergeant le dispositif de traitement 14' ; et — l'heuristique appliquée par le module 14C1' du dispositif de traitement 14' au cours de l'étape E40 est la suivante : o si le préfixe annoncé dans l'annonce non légitime est inférieur à 24, le bloc d'adresses IP associé au préfixe annoncé est divisé par 2 et deux contre-annonces sont générées dans lesquelles le module 14C1 du routeur de bordure 7 de l'AS 2 annonce respectivement les deux sous-blocs d'adresses IP résultant (ou de façon équivalente, les deux préfixes correspondant aux deux sous-blocs d'adresses IP résultant) ; o si le préfixe annoncé dans l'annonce non légitime est égal à 24, une contre-annonce est générée dans laquelle le module 14C1 du routeur de bordure 7 de l'AS 2 annonce le même préfixe (i.e. le même bloc d'adresses IP).

Autrement dit, cette heuristique se distingue de celle appliquée par le module 14C1 du dispositif de traitement 14 dans le premier mode de réalisation en ce que les contre-annonces propagées par le réseau AS 2 annoncent un chemin d'AS plus court que dans le premier mode de réalisation. En effet, le réseau à l'origine de ces contre-annonces est maintenant le réseau AS 2, autrement dit, le chemin d'AS annoncé dans les contre-annonces émises par le module 14C2' du dispositif de traitement 14' comprend uniquement l'identifiant d'AS 5511 correspondant à l'AS 2. Ceci peut permettre avantageusement de récupérer une partie supplémentaire du trafic détourné par l'AS 6 ; — le routeur de bordure 7' est équipé d'un module 15 de gestion du trafic ainsi attiré par l'AS 2 et destiné à l'AS 1 permettant de réinjecter ce traffic vers l'AS 1. Un tel module comprend par exemple des moyens d'établir avec l'AS 1 un tunnel selon le protocole GRE (Generic Routing Encapsulation) connu de l'homme du métier comme étant un protocole de mise en tunnel permettant d'encapsuler des paquets de la couche réseau.

Le réseau transitaire peut également, dans ses contre-annonces, influencer les chemins adoptés par les tiers en raison des règles de priorisation des annonces existantes selon BGP et qui visent à privilégier les chemins les plus courts. En effet, un tel réseau transitaire a généralement une position centrale dans le réseau NW, dans le sens où il peut atteindre un grand nombre d'AS en un minimum de réseaux intermédiaires contrairement à l'AS 6. Le chemin d'AS de l'annonce émise par l'AS 2 peut donc être plus court pour de nombreux AS par rapport au chemin d'AS résultant de l'annonce de l'AS 6.

On peut également en variante envisager l'existence d'un accord (commercial ou via un tiers) entre des AS transitaires selon lequel les annonces émises par une liste prédéterminée de transitaires sont prioritaires par rapport à des annonces portant sur les mêmes blocs d'adresses ou préfixes émises par des tiers.

On peut par ailleurs envisager selon une autre variante que plusieurs réseaux transitaires, à différents endroits du réseau NW, soient équipés de routeurs comprenant des dispositifs de traitement selon l'invention, et que ces multiples réseaux transitaires puissent dialoguer entre eux et avec le réseau transitaire AS 2 selon des règles prédéterminées et de façon sécurisée pour gérer encore plus efficacement les incidents affectant leurs réseaux clients. Une telle liaison sécurisée pourrait permettre au réseau transitaire AS 2 d'informer les autres réseaux transitaires de la contre-annonce émise afin que ces autres réseaux transitaires propagent à leur tour la contre-annonce. Un tunnel sécurisé établi entre le réseau transitaire AS 2 et chacun des réseaux transitaires pourrait être envisagé pour pouvoir rediriger le trafic récupéré par chaque réseau transitaire vers l'AS 1.

Dans un autre mode de réalisation, le dispositif de traitement automatique selon l'invention est hébergé dans un réseau tiers, par exemple dans un réseau proposant aux réseaux formant le réseau NW un service de traitement conformément à l'invention des annonces non légitimes émises à l'encontre de ces réseaux.

Il convient de noter que l'invention a été décrite ici dans un contexte où les réseaux sont interconnectés entre eux via le protocole BGP et annoncent leurs routes via ce protocole. L'invention s'applique également dans d'autres contextes, par exemple dans un contexte de réseau défini par logiciel (ou SDN pour Software Defined Network) dans lequel les réseaux peuvent être interconnectés via d'autres protocoles.

Claims (15)

1. REVENDICATIONS

   1. Procédé de traitement, par un dispositif (14,14') d'un premier réseau de télécommunications (AS 1, AS 2), d'une annonce non légitime d'un bloc d'adresses IP émise par un deuxième réseau de télécommunications (AS 6) distinct du premier réseau, ledit procédé comprenant, sur détection (E10) de ladite annonce non légitime : — une étape de vérification (E20) destinée à déterminer si un traitement automatique de ladite annonce non légitime doit être ou non activé ; — le cas échéant, une étape de traitement automatique (E30-E50) de l'annonce non légitime comprenant : o une étape de détermination automatique (E40) d'au moins une contre-annonce annonçant un bloc d'adresses IP équivalent ou plus spécifique que le bloc d'adresses IP annoncé dans l'annonce non légitime ; et o une étape d'émission automatique (E50) de ladite au moins une contre-annonce vers un réseau pair.
2. 2. Procédé selon la revendication 1 dans lequel l'étape de vérification (E20) comprend une comparaison (E21) par rapport à un seuil prédéterminé (THR) d'un nombre d'annonces (N) non légitimes en cours de traitement par le dispositif du premier réseau, un traitement automatique de l'annonce non légitime étant activé si le nombre d'annonces non légitimes en cours de traitement est inférieur au seuil prédéterminé.
3. 3. Procédé selon la revendication 2 dans lequel lorsque le nombre d'annonces non légitimes en cours de traitement est supérieur ou égal au seuil prédéterminé, un traitement automatique de l'annonce non légitime est activé si le bloc d'adresses IP annoncé dans l'annonce non légitime est un bloc d'adresses IP identifié comme prioritaire (E22).
4. 4. Procédé selon l'une quelconque des revendications 1 à 3 dans lequel le premier réseau est : — le réseau (AS 1) gérant le bloc d'adresses IP annoncé dans l'annonce non légitime ; ou — un réseau (AS 2) d'un opérateur de transit du réseau gérant le bloc d'adresses IP annoncé dans la l'annonce non légitime ; ou — un réseau tiers.
5. 5. Procédé selon l'une quelconque des revendications 1 à 4 dans lequel la détection (E10) de l'annonce non légitime par le dispositif du premier réseau comprend la réception par ce dispositif d'un message d'alerte émis par un dispositif de détection d'annonces non légitimes.
6. 6. Procédé selon l'une quelconque des revendications 1 à 4 dans lequel la détection de l'annonce non légitime par le dispositif du premier réseau comprend : — une étape de réception de l'annonce ; — une étape de comparaison du bloc d'adresses IP annoncé dans l'annonce avec des adresses IP gérées par le premier réseau ; l'annonce étant détectée comme non légitime en cas de recoupement du bloc d'adresses IP annoncé dans l'annonce avec des adresses IP gérées par le premier réseau.
7. 7. Procédé selon l'une quelconques des revendications 1 à 6 comprenant en outre une étape d'émission (E60), à destination du deuxième réseau, d'une notification signalant l'annonce non légitime.
8. 8. Procédé selon l'une quelconque des revendications 1 à 7 comprenant en outre une étape de suppression (E80) de ladite au moins une contre-annonce après avoir détecté (E70) une cessation de l'annonce non légitime.
9. 9. Procédé selon l'une quelconque des revendications 1 à 8 dans lequel ladite annonce non légitime et ladite au moins une contre-annonce sont conformes au protocole BGP (Border Gateway Protocol).
10. 10. Programme d'ordinateur comportant des instructions pour l'exécution des étapes du procédé de traitement selon l'une quelconque des revendications 1 à 9 lorsque ledit programme est exécuté par un ordinateur.
11. 11. Support d'enregistrement lisible par un ordinateur sur lequel est enregistré un programme d'ordinateur selon la revendication 9 comprenant des instructions pour l'exécution des étapes du procédé de traitement selon l'une quelconque des revendications 1 à 9.
12. 12. Dispositif (14,14') d'un premier réseau de télécommunications, configuré pour traiter une annonce non légitime d'un bloc d'adresses IP émise par un deuxième réseau de télécommunications distinct du premier réseau, ledit dispositif comprenant : — un module (14A,14A') de détection de l'annonce non légitime émise par le deuxième réseau ; -- un module (14B,14B') de vérification configuré pour déterminer si un traitement automatique de ladite annonce non légitime doit être ou non activé ; — un module (14C,14C') de traitement automatique de l'annonce non légitime, activé le cas échéant par le module de vérification et comprenant : o un module (14C2,14C1') de détermination automatique d'au moins une contre-annonce annonçant un bloc d'adresses IP équivalent ou plus spécifique que le bloc d'adresses IP annoncé dans l'annonce non légitime ; et o un module (14C2,14C2') d'émission automatique de ladite au moins une contre-annonce vers un réseau pair ; le module de vérification et le module de traitement automatique étant activés par le module de détection sur détection de l'annonce non légitime émise par le deuxième réseau.
13. 13. Réseau de télécommunications (NW) comprenant une pluralité de réseaux indépendants interconnectés (AS1-AS6), ladite pluralité de réseaux comprenant au moins un premier réseau et un deuxième réseau, ledit premier réseau comprenant un dispositif de traitement selon la revendication 12 configuré pour traiter une annonce non légitime d'un bloc d'adresses IP émise par le deuxième réseau.
14. 14. Réseau selon la revendication 13 comprenant au moins dispositif d'alarme (8) apte à détecter ladite annonce non légitime émise par le deuxième réseau et à envoyer un message d'alerte au dispositif de traitement du premier réseau l'informant de la détection de cette annonce non légitime.
15. 15. Réseau selon la revendication 13 ou 14 dans lequel ladite pluralité de réseaux indépendants sont interconnectés par l'intermédiaire du protocole BGP.