FR3143150A1 - Procédé de gestion d’un ensemble d’adresses IP, procédé de collaboration et dispositifs configurés pour mettre en œuvre ces procédés. - Google Patents

Abstract

Procédé de gestion d’un ensemble d’adresses IP, procédé de collaboration et dispositifs configurés pour mettre en œuvre ces procédés. Le procédé de gestion comprend : une détection d’un comportement suspect associé à une adresse IP d’un premier ensemble d’adresses IP sélectionnée par un premier dispositif (CGN#1) d’un réseau pour traiter au moins un paquet d’un équipement client servi par le premier dispositif ; une exécution d’au moins une action parmi : un ajustement d’au moins un taux de partage d’au moins une adresse IP du premier ensemble appliqué par le premier dispositif ; une demande à au moins un deuxième dispositif (CGN#2) gérant un deuxième ensemble d’adresses IP de délégation d’au moins une adresse IP du deuxième ensemble au premier dispositif pour qu’il puisse sélectionner cette adresse IP déléguée pour traiter au moins un paquet d’au moins un équipement client servi par le premier dispositif. Figure pour l’abrégé : Fig. 2.

Description

Procédé de gestion d’un ensemble d’adresses IP, procédé de collaboration et dispositifs configurés pour mettre en œuvre ces procédés.

L’invention appartient au domaine général des télécommunications.

Elle concerne la gestion d’un service de connectivité, plus particulièrement en cas d’attaques informatiques dans un réseau de télécommunications, telles que par exemple des attaques par déni de service (ou DDoS pour « Distributed Denial of Service » en anglais).

De façon connue en soi, une attaque DDoS est une tentative de rendre des ressources (par exemple des ressources de calcul ou des ressources réseau) indisponibles pour leurs utilisateurs. De telles attaques peuvent être massives et de nature à compromettre plusieurs centaines de milliers d’équipements clients (par exemple des terminaux), qui peuvent à leur tour être utilisés comme relais pour amplifier le pouvoir de nuisance des attaques. Ces attaques sont de plus en plus fréquentes et intenses ; leur ampleur en termes de durée mais aussi d’étendue et de propagation rend difficile la tâche du ou des services DPS (pour « DDoS Protection Service » en anglais) déployés dans le réseau pour détecter et mitiger de telles attaques (par exemple via une mise en quarantaine des ressources ciblées par les attaques, de filtrage du trafic associé à une attaque, etc.).

En outre, la mise en place d’actions de mitigation au sein d’un réseau est particulièrement problématique en présence de dispositifs de translation d’adresses aussi appelés NAT (pour « Network Address Translation » en anglais) opérateurs (ou encore CGN pour « Carrier Grade NAT » en anglais, ou LSN pour « Large Scale NAT » en anglais).

Un NAT opérateur est un dispositif mettant en œuvre une fonction de translation (aussi appelée traduction) d’adresses IP (et le cas échéant, de numéros de port) dans un réseau d’opérateur. Plusieurs types de NAT opérateur ont été spécifiés par l’IETF (pour « Internet Engineering Task Force » en anglais) et déployés par les opérateurs (par exemple NAT44, NAT64, DS-Lite, NPTv6, etc.). Par exemple, dans une architecture dite de double NAT, la fonction NAT d’un CGN vient s’ajouter à la fonction NAT embarquée dans l’équipement client d’accès au réseau (par exemple dans un CPE pour « Customer Premises Equipment » en anglais). Les architectures réseaux reposant sur l’exploitation de CGN permettent notamment de mettre en place un mécanisme de partage d’adresses IP, offrant par exemple une solution de continuité de service dans un contexte de pénurie d’adresses IPv4.

Par exemple, une adresse dite « interne » (par exemple une adresse privée dans le cas d’une ingénierie double NAT) est affectée en lieu et place d’une autre adresse, dite « externe » (par exemple une adresse globale IPv4 dans le cas d’un ingénierie double NAT, notamment) à l’interface de raccordement de l’équipement d’accès (par exemple un CPE) du client au réseau. La translation de l’adresse interne affectée à l’interface de raccordement de l’équipement d’accès en une adresse externe est effectuée par le NAT opérateur (CGN). La illustre, sur un exemple, les différentes translations d’adresses effectuées respectivement par un équipement d’accès CPE1 et par un NAT opérateur CGN2 sur des paquets de données IP émis par un terminal H3, connecté par exemple à un réseau d’entreprise ou un réseau domestique, et destiné à un équipement distant S4.

Ainsi, dans l’exemple de la , un paquet P de données IP ayant pour adresse IP source 10.2.25.5 et un numéro de port source 12345 est émis par le terminal H, et reçu par l’équipement d’accès CPE1. On suppose ici que l’adresse IP privée 192.168.1.56 et le numéro de port 16587 sont affectés à l’interface WAN (pour « Wide Area Network » en anglais) de l’équipement d’accès CPE1 dans le cas d’une ingénierie double NAT. La fonction NAT de l’équipement d’accès CPE1 remplace alors dans l’entête du paquet P de données IP reçu du terminal H3, le couple (10.2.25.5,12345) par le couple (192.168.1.56,16587). Il peut également procéder à d’autres modifications, comme par exemple l’exécution d’un code de redondance cyclique (CRC, plus couramment désigné par « checksum » en anglais) ou l’application d’une fonction de type ALG (pour « Application Level Gateway » en anglais). Puis l’équipement d’accès CPE1 envoie le paquet P’ de données IP dont au moins le champ adresse source a été modifié après exécution de la fonction NAT vers un NAT opérateur CGN2. Sur réception du paquet P’ de données IP, le NAT opérateur CGN2 sélectionne une adresse IP externe (par exemple une adresse IPv4 publique) et un numéro de port externe (par exemple un numéro de port public) pour le traitement du paquet P’, par exemple le couple (1.2.3.4, 45875), et associe dans une base d’informations, par exemple une base BIB (pour « Binding Information Base ») le couple (1.2.3.4, 45875) au couple (192.168.1.56, 16587) ainsi que le protocole de transport utilisé (non mentionné dans la par souci de simplification). Puis le NAT opérateur CGN2 remplace dans l’entête du paquet P’ de données IP, l’adresse IP interne 192.168.1.56 et le numéro de port interne 16587, par l’adresse IP externe 1.2.3.4 et le numéro de port externe 45875 respectivement. Le paquet P’’ de données IP ainsi obtenu est ensuite transféré par le NAT opérateur CGN2 vers sa destination (l’équipement distant S4 de la figure).

On note que la pénurie d’adresses IPv4 est un problème également rencontré dans les réseaux mobiles, en raison de la limitation de l’espace d’adressage privé (18 millions d’adresses disponibles au total). En effet, les ingénieries actuelles de réseaux mobiles ont tendance à affecter quasiment systématiquement une adresse IPv4 privée à chaque terminal mobile. Les opérateurs qui mettent en œuvre de telles ingénieries doivent donc également mettre en place des mécanismes de partage d’adresses IPv4 privées reposant sur des NAT opérateur (CGN) déployés typiquement au niveau de l’interface Gi (sGi ou N6 selon la release 3GPP considérée) permettant de raccorder un réseau d’accès mobile au réseau de données (par exemple, Internet). En outre, des mécanismes de conversion de type NAT64 peuvent également être déployés dans les réseaux des opérateurs qui ont défini une stratégie de migration vers IPv6, protocole dont l’espace d’adressage est présenté comme la solution durable à la pénurie d’adresses IPv4. Un tel mécanisme de translation d’adresses NAT64 permet avantageusement à un nœud dit IPv6-only supportant uniquement le protocole IPv6 de communiquer avec un nœud dit IPv4-only supportant uniquement le protocole IPv4, en convertissant les paquets de données IPv6 reçus du nœud IPv6-only en des paquets IPv4 avant de les transmettre au nœud IPv4-only.

Le document RFC 6269 publié par l’IETF liste un ensemble de problèmes inhérents aux solutions de partage d’adresses. Typiquement, dans un contexte de mitigation d’attaques, la mise en quarantaine d’une adresse IP associée à une attaque DDoS impacte tous les équipements clients partageant cette adresse. La mise en place d’actions de mitigation dans un réseau ou par un serveur distant risque ainsi d’impacter la qualité de service perçue par tous les équipements clients qui partagent une même adresse IP, voire rendre le service indisponible pour certains.

L’invention permet notamment d’améliorer l’efficacité des politiques de mitigation d’attaques dans des environnements réseaux où des fonctions qui agrègent plusieurs connexions en utilisant des adresses susceptibles d’être partagées (par exemple des fonctions CGN ou proxy) sont déployées, en proposant un procédé de gestion, par un premier dispositif localisé dans un réseau, d’un premier ensemble d’adresses IP, ce procédé comprenant :

• une étape de détection d’un comportement suspect associé à une adresse IP du premier ensemble sélectionnée par le premier dispositif pour traiter au moins un paquet de données d’un équipement client servi par le premier dispositif ;
• suite à ladite détection, une étape d’exécution d’au moins une action parmi :
  • un ajustement d’au moins un taux de partage d’au moins une adresse IP du premier ensemble appliqué par le premier dispositif ; et
  • une demande, adressée à au moins un deuxième dispositif gérant un deuxième ensemble d’adresses IP, de délégation d’au moins une adresse IP du deuxième ensemble au premier dispositif pour que le premier dispositif puisse sélectionner ladite au moins une adresse IP déléguée pour traiter au moins un paquet de données d’au moins un équipement client servi par le premier dispositif.

Corrélativement, l’invention concerne également un dispositif, dit premier dispositif, localisé dans un réseau, ce premier dispositif gérant un premier ensemble d’adresses IP et comprenant :

• un module de détection, configuré pour détecter un comportement suspect associé à une adresse IP dudit premier ensemble sélectionnée par le premier dispositif pour traiter au moins un paquet de données d’un équipement client servi par le premier dispositif ;
• un module d’exécution, configuré pour exécuter suite à ladite détection, au moins une action parmi :
  • un ajustement d’au moins un taux de partage d’au moins une adresse IP du premier ensemble appliqué par le premier dispositif ; et
  • une demande, adressée à au moins un deuxième dispositif gérant un deuxième ensemble d’adresses IP, de délégation d’au moins une adresse IP du deuxième ensemble au premier dispositif pour que le premier dispositif puisse sélectionner ladite au moins une adresse IP déléguée pour traiter au moins un paquet de données d’au moins un équipement client servi par le premier dispositif.

Les premier et deuxième dispositifs peuvent être typiquement des NAT opérateur (ou CGN ou encore LSN) tels que décrits précédemment, configurés pour gérer des pools d’adresses IP distincts (ensembles d’adresses au sens de l’invention) susceptibles d’être partagées entre plusieurs équipements clients connectés à un réseau. Les deux dispositifs peuvent être colocalisés ou être embarqués dans des équipements distincts, être déployés dans le réseau de façon distribuée ou centralisée, le réseau pouvant comprendre plusieurs niveaux de NAT opérateur se succédant. Les adresses IP d’un même pool peuvent être des adresses IPv4 et/ou des adresses IPv6, contiguës ou non. L’invention s’applique à tout type de NAT opérateur (par exemple, NAT44, NAT64, DS-lite, NPTv6 (c’est-à-dire mettant en œuvre une traduction de préfixes réseau IPv6 en d’autres préfixes IPv6), etc.). Par ailleurs, aucune hypothèse n’est faite quant à la nature des équipements clients susceptibles de partager une même adresse IP : il peut s’agir de terminaux, d’équipements d’accès au réseau d’un opérateur tels qu’un CPE, etc.

L’invention peut également s’appliquer dans d’autres contextes, et notamment à d’autres dispositifs gérant une pluralité d’adresses IP susceptibles d’être partagées entre plusieurs équipements clients, comme par exemple à des dispositifs mettant en œuvre une fonction proxy utilisant ses propres adresses IP pour relayer des paquets de données reçus. De tels dispositifs sont par exemple décrits dans les sections 5, 6 et 7 du document RFC 7620 publié par l’IETF et intitulé « Scenarios with Host Identification Complications », août 2015. En outre, l’invention s’applique également lorsque les adresses IP gérées par les premier et/ou deuxième dispositifs sont allouées à un instant donné à des équipements clients uniques, c’est-à-dire à des adresses IP qui ne sont pas partagées entre plusieurs équipements clients.

Les adresses IP gérées par les premier et deuxième dispositifs, ainsi que les adresses IP déléguées, sont utilisées par lesdits dispositifs pour traiter des paquets de données d’équipements clients. Par « paquet d’un équipement client », on entend un paquet (ou de façon équivalente un message) contenant des données émises par cet équipement client et destinées à une entité destinataire, ou à l’inverse, émises par une entité source et destinées à l’équipement client. Il convient de noter qu’au sens de l’invention, le paquet en question peut être reçu par le premier dispositif directement de l’équipement client ou transiter via un ou plusieurs équipements intermédiaires (par exemple via un ou plusieurs NAT opérateur lorsque plusieurs niveaux de NAT opérateur sont déployés en cascade dans le réseau) avant d’être reçu par le premier dispositif.

Ainsi, l’invention propose, pour répondre efficacement à la détection d’un comportement suspect associé à une adresse IP (par exemple activité suspecte émise avec cette adresse comme adresse source) dans un réseau dans lequel les adresses IP sont susceptibles d’être partagées entre plusieurs équipements clients, de mettre en place deux types d’actions (de façon alternative ou combinée), à savoir :

• modifier un ou plusieurs taux de partage d’adresses appliqués par le dispositif (premier dispositif au sens de l’invention) gérant l’adresse IP au comportement suspect : typiquement, le premier dispositif peut réduire le taux de partage appliqué à l’adresse IP au comportement suspect et augmenter celui des autres adresses IP qu’il gère afin d’être en mesure d’attribuer ces autres adresses IP aux équipements clients qu’il sert (actuels et futurs) ;
• bénéficier de l’assistance d’un autre dispositif (deuxième dispositif au sens de l’invention), et notamment lui demander de lui déléguer une ou plusieurs adresses IP « saines » afin qu’il puisse les utiliser pour traiter les paquets des équipements clients qui lui sont rattachés. De la sorte, on étendde factoavec de nouvelles adresses IP l’ensemble « nominal » des adresses IP (premier ensemble au sens de l’invention) qui est affecté au premier dispositif.

Ces actions ont pour but d’assurer au premier dispositif, la disponibilité d’adresses IP « saines » (c’est-à-dire non réputées pour avoir été utilisées à des fins frauduleuses et qui ne sont donc pas a priori visées en tant que cibles ou utilisées par la source d’une attaque) pour qu’il soit en mesure de traiter les paquets d’équipements clients qui lui parviennent, et ce, en dépit du comportement malveillant associé à l’une des adresses IP actives que le premier dispositif (CGN, par exemple) gère. Ces actions peuvent, dans un mode de réalisation particulier, avoir un effet pendant une période de temps limitée, par exemple tant que le comportement suspect associé à l’adresse IP en question subsiste.

Grâce à l’exécution de telles actions, l’impact des attaques informatiques sur le fonctionnement du ou des services souscrits par les utilisateurs des équipements clients qui éventuellement partagent une même adresse IP, est réduit. Il convient de noter que le partage d’adresses IP est souvent réalisé dans le réseau à l’insu des utilisateurs. Par exemple, comme évoqué précédemment, il peut être mis en place par un opérateur d’un réseau pour pallier la pénurie d’adresses IPv4. L’invention permet de faire en sorte que ce partage d’adresses IP reste transparent pour les utilisateurs et n’impacte pas la qualité de service expérimentée par ces derniers. L’opérateur peut en effet grâce à l’invention garantir une continuité de service aux utilisateurs tout en assurant l’efficacité des actions de mitigation mises en œuvre pour répondre à un comportement suspect détecté dans le réseau. Ces actions de mitigation consistent par exemple à mettre en quarantaine une adresse IP associée à un comportement suspect, une telle mise en quarantaine pouvant consister à isoler le trafic entrant à destination de cette adresse IP, et/ou à rejeter des connexions émises avec cette adresse, et/ou à rediriger le trafic caractéristique des connexions émises avec cette adresse vers un module d’inspection de trafic, et/ou à retirer cette adresse IP du pool d’adresses IP pouvant être utilisées pour traiter les paquets d’un équipement client, etc.

Ainsi, comme il apparaît au vu de ce qui précède, l’invention repose sur le premier dispositif déclenchant une action en réponse à un comportement suspect associé à une adresse IP partagée, mais également, lorsque cette action comprend une demande de délégation d’adresses IP, sur le deuxième dispositif collaborant avec le premier dispositif en répondant favorablement à sa demande.

L’invention concerne donc également, selon un autre aspect, un procédé de collaboration avec un premier dispositif localisé dans un réseau et gérant un premier ensemble d’adresses IP comprenant une adresse IP associée à un comportement suspect, ledit procédé étant destiné à être mis en œuvre par un deuxième dispositif gérant un deuxième ensemble d’adresses IP et comprenant :

• une étape de réception, en provenance du premier dispositif, d’une demande de délégation d’au moins une adresse IP du deuxième ensemble au premier dispositif pour que le premier dispositif puisse sélectionner ladite au moins une adresse IP déléguée pour traiter au moins un paquet de données d’au moins un équipement client servi par le premier dispositif ; et
• une étape d’envoi au premier dispositif d’une liste comprenant au moins une adresse IP du deuxième ensemble déléguée par ledit deuxième dispositif au premier dispositif.

Corrélativement, l’invention vise aussi un dispositif, dit deuxième dispositif, localisé dans un réseau, ledit deuxième dispositif gérant un deuxième ensemble d’adresses IP et comprenant :

• un module de réception, configuré pour recevoir, en provenance d’un premier dispositif gérant un premier ensemble d’adresses IP comprenant une adresse IP associée à un comportement suspect, une demande de délégation d’au moins une adresse IP du deuxième ensemble au premier dispositif pour que le premier dispositif puisse sélectionner ladite au moins une adresse IP déléguée pour traiter au moins un paquet de données d’au moins un équipement client servi par le premier dispositif ; et
• un module d’envoi, configuré pour envoyer au premier dispositif, une liste comprenant au moins une adresse IP du deuxième ensemble déléguée par ledit deuxième dispositif au premier dispositif.

Les avantages du procédé de collaboration et du deuxième dispositif sont similaires à ceux décrits précédemment pour le procédé de gestion et le premier dispositif.

Les comportements suspects associés à des adresses IP pouvant déclencher l’exécution d’un ajustement d’un taux de partage d’adresses IP ou d’une demande de délégation conformément à l’invention peuvent être de différentes natures ; par exemple le comportement suspect détecté peut résulter de l’appartenance de l’adresse IP à une liste bloquée (ou « block-list » en anglais), ou le fait qu’elle soit associée à un niveau de réputation faible, etc. Ces comportements suspects peuvent être détectés directement (c’est-à-dire localement) par le premier dispositif, ou par d’autres entités, chargées alors de notifier le premier dispositif.

Ainsi, dans un mode particulier de réalisation, l’étape de détection peut comprendre la réception d’une notification émise par une fonction de détection d’attaques (embarquée par exemple dans un système ou centre de mitigation d’attaques aussi désigné par AMS pour « Attack Mitigation System » en anglais) ou d’une notification émise par un système de réputation d’adresses IP.

Une telle notification peut être émise par exemple via un canal DOTS (pour « DDoS Open Threat Signaling » en anglais) établi entre le premier dispositif et la fonction de détection d’attaques ou le système de réputation d’adresses IP précités. De façon connue en soi, DOTS est une architecture client/serveur, spécifiée par l’IETF, qui a pour objectif de fournir un mécanisme de signalisation de détection de trafic suspect voire d’attaque avérée de sorte à mettre en œuvre le plus rapidement possible des actions de mitigation appropriées. Ainsi, la mise en œuvre de l’invention peut s’appuyer notamment sur l’implémentation par le premier dispositif du mécanisme décrit dans le document RFC 9244 de l’IETF intitulé « Distributed Denial-of-Service Open Threat Signaling (DOTS) Telemetry », juin 2022, pour recevoir des notifications concernant des attaques dont une adresse IP appartenant au premier ensemble est la cible. Pour les attaques dont la source est une adresse IP du premier ensemble, on peut envisager de spécifier une extension de ce mécanisme de signalisation DOTS consistant à définir une nouvelle option « Uri-Query » appelée par exemple « source-address », valorisée avec l’adresse IP en question, comme détaillé davantage ultérieurement.

Bien entendu, ceci n’est qu’un exemple illustratif d’implémentation de l’invention, et d’autres mécanismes de notification du premier dispositif peuvent être envisagés.

Comme évoqué précédemment, l’invention s’applique dans différents contextes.

Ainsi, dans un mode de réalisation particulier, on peut envisager que le premier dispositif soit configuré avec une liste de deuxièmes dispositifs selon l’invention avec lesquels il peut envisager de collaborer et plus particulièrement, auxquels il peut envoyer une demande de délégation d’adresses IP.

Dans un autre mode de réalisation, le procédé de gestion peut comprendre une étape de découverte dudit au moins un deuxième dispositif.

Une telle découverte dynamique des dispositifs susceptibles de lui déléguer des adresses IP peut être mise en œuvre par le premier dispositif par exemple en utilisant un protocole de routage dynamique tel que OSPF (pour « Open Shortest Path First » en anglais), ou en interrogeant une fonction réseau de type NRF (pour « Network Repository Function » en anglais) dans un réseau 5G.

Dans un mode particulier de réalisation, le procédé de gestion peut comprendre en outre une étape d’établissement avec ledit au moins un deuxième dispositif d’au moins un canal de communication, par exemple un canal de communication chiffré. Ce canal de communication peut être établi de sorte à être utilisé de façon unidirectionnelle par le premier dispositif pour envoyer une demande de délégation au deuxième dispositif, ou de façon bidirectionnelle, chacun des premier et deuxième dispositifs pouvant indifféremment exploiter ce canal pour envoyer une demande de délégation.

Le canal de communication établi entre le premier dispositif et un dit deuxième dispositif peut être notamment un canal de communication chiffré reposant par exemple sur le protocole QUIC, et éventuellement le cas échéant, sur la définition d’un nouveau paramètre de transport permettant au premier dispositif et au deuxième dispositif de s’informer sur leur support respectif du mécanisme proposé par l’invention (et en particulier de la délégation d’adresses IP).

Le protocole QUIC permet avantageusement d’établir un canal de communication chiffré donc sécurisé entre les deux dispositifs ; conformément au protocole QUIC, non seulement les données utiles échangées par les premier et deuxième dispositifs sont chiffrées mais également la plupart des données de contrôle, ce qui apporte une protection supplémentaire contre d’éventuelles attaques. Il s’agit toutefois d’un simple exemple d’implémentation de l’invention, et d’autres mécanismes peuvent être envisagés. Par exemple, le canal de communication peut s’appuyer sur un tunnel GRE (pour « Generic Routing Encapsulation » en anglais) ou IPsec (pour « IP security » en anglais), ou reposer sur le protocole IP-in-IP. Il convient de noter que l’établissement d’un canal de communication chiffré permet avantageusement de renforcer la sécurité du mécanisme proposé, notamment si un dispositif (ou nœud) du réseau est compromis. Il est toutefois possible de s’affranchir d’un tel chiffrement si on considère que tous les dispositifs du réseau sont de confiance.

L’étape de découverte et/ou l’étape d’établissement d’un canal de communication avec un deuxième dispositif peu(ven)t être mise(s) en œuvre avant ou après l’étape de détection. En d’autres termes, ces étapes peuvent être déclenchées par la détection d’un comportement suspect associé à une adresse IP, de sorte à réduire notamment les ressources monopolisées pour la mise en œuvre de l’invention, ou être réalisées préalablement, indépendamment de toute détection d’un comportement suspect associé à une adresse IP gérée par le premier dispositif, de sorte à réduire le temps de réaction du premier dispositif face à un comportement suspect associé à une adresse IP qu’il gère.

L’établissement d’un canal de communication entre le premier dispositif et un deuxième dispositif permet aux dispositifs d’échanger diverses informations, utiles à leur collaboration.

Ainsi, dans un mode particulier de réalisation, la demande de délégation adressée par le premier dispositif peut comprendre un nombre et/ou un type d’adresses IP déléguées souhaités par le premier dispositif.

Dans un autre mode de réalisation, le procédé de gestion comprend en outre une étape de réception par le premier dispositif, en réponse à une dite demande de délégation adressée par le premier dispositif à un dit deuxième dispositif, au moins un élément parmi :

• une liste comprenant au moins une adresse IP déléguée par ce deuxième dispositif au premier dispositif ;
• une durée pendant laquelle ladite liste est déléguée au premier dispositif ;
• une information représentative d’un volume maximum de trafic, associé à l’usage d’une adresse IP déléguée par ledit au moins un deuxième dispositif au premier dispositif et pouvant être géré par le deuxième dispositif.

Ces diverses informations permettent de rendre la collaboration entre les deux dispositifs plus efficace, et mieux adaptée aux besoins du premier dispositif et/ou aux capacités du deuxième dispositif. Elles ne sont pas limitatives en soi, et d’autres informations peuvent être échangées entre les dispositifs.

L’information représentative du volume maximum de trafic transmise par le deuxième dispositif peut être exploitée par le premier dispositif pour utiliser de façon optimisée les adresses IP qui lui sont déléguées et répartir au mieux le trafic transitant par lui.

Par exemple, dans un mode particulier de réalisation, le procédé de gestion comprend une étape de sélection d’au moins deux adresses IP déléguées par desdits deuxièmes dispositifs distincts pour traiter des paquets d’au moins deux équipements clients distincts servis par le premier dispositif.

Ainsi, dans ce mode de réalisation, le premier dispositif peut répartir tout ou partie du trafic transitant par lui et rattaché à des équipements clients distincts entre plusieurs adresses IP déléguées par desdits deuxièmes dispositifs distincts. Ce mode de réalisation a une application privilégiée lorsque par exemple l’un desdits deuxièmes dispositifs n’est pas en mesure de traiter tout le trafic en question. Le premier dispositif peut alors faire appel à d’autres dispositifs pour traiter l’excédent de trafic par rapport au volume de trafic maximum indiqué par ledit deuxième dispositif en capacité insuffisante.

Dans un mode particulier de réalisation, le procédé de gestion comprend en outre :

• une étape de réception, depuis une adresse IP source interne, d’un premier paquet de données comprenant des données destinées à une entité destinataire ;
• une étape de remplacement de cette adresse IP source interne par une dite adresse IP déléguée par un dit deuxième dispositif au premier dispositif et sélectionnée par le premier dispositif pour traiter le premier paquet de données ; et
• une étape de transmission des données avec l’adresse IP déléguée audit deuxième dispositif, via un canal de communication établi avec lui, pour que lesdites données soient acheminées vers l’entité destinataire.

De façon similaire, dans un mode particulier de réalisation, le procédé de gestion peut en outre comprendre :

• une étape de réception, via un canal de communication avec un dit deuxième dispositif, d’un deuxième paquet de données émis par une entité émettrice et comprenant des données destinées à une adresse IP du deuxième ensemble d’adresses IP géré par le deuxième dispositif ; et
• si ladite adresse IP est déléguée au premier dispositif par le deuxième dispositif et sélectionnée par le premier dispositif pour traiter des paquets de données d’un équipement client servi par le premier dispositif, une étape de transmission desdites données vers une adresse IP interne allouée audit équipement client.

Corrélativement, dans un mode particulier de réalisation, le procédé de collaboration comprend en outre :

• une étape de réception, via un canal de communication établi avec le premier dispositif, d’un premier paquet de données comprenant des données destinées à une entité destinataire et émis avec une adresse IP source appartenant au deuxième ensemble d’adresses IP géré par le deuxième dispositif ; et
• si ladite adresse IP source est une dite adresse IP déléguée par le deuxième dispositif au premier dispositif, une étape de transmission desdites données vers l’entité destinataire sans modifier ladite adresse IP source desdites données.

Par ailleurs, dans un autre mode de réalisation, le procédé de collaboration peut également comprendre :

• une étape de réception d’un deuxième paquet de données comprenant des données émises par une entité émettrice et destinées à une adresse IP destinataire appartenant au deuxième ensemble d’adresses IP géré par le deuxième dispositif ; et
• si ladite adresse IP est une dite adresse IP déléguée par le deuxième dispositif au premier dispositif, une étape de transmission desdites données au premier dispositif via le canal de communication établi avec ledit premier dispositif sans modifier ladite adresse IP destinataire desdites données.

Ces modes de réalisation du procédé de gestion et du procédé de collaboration ont une application privilégiée lorsque les premier et deuxième dispositif en question sont des NAT opérateur. Dans ces modes de réalisation, les paquets de données émis par ou à destination de l’équipement client (désignés par paquets de données de l’équipement client) auxquels le premier dispositif attribue une adresse IP déléguée par un dit deuxième dispositif transitent via un canal de communication (éventuellement sécurisé) établi entre le premier et le deuxième dispositif. Il convient de noter que lorsque les paquets de données associés à une adresse IP déléguée par le deuxième dispositif au premier dispositif parviennent au deuxième dispositif, celui-ci n’effectue aucune modification de l’adresse IP déléguée en question (pas de translation d’adresses), dès lors qu’il s’agit d’une adresse appartenant au pool d’adresses qu’il gère. Autrement dit, il désactive la fonction de translation d’adresses qu’il applique habituellement sur les paquets qui transitent par lui.

Avantageusement, ces modes de réalisation ne requièrent pas de modification des politiques de routage mises en place dans le réseau, ni des politiques d’acheminement du trafic transitant par les premier et deuxième dispositifs. En effet, ces modes de réalisation ne nécessitent pas de synchronisation des tables de routage des équipements du réseau liée à la délégation d’adresses IP, et par conséquent, permettent de s’affranchir de l’impact des temps de convergence associés à la synchronisation des tables de routage maintenues par les équipements du réseau. La mise en œuvre de l’invention n’impacte donc pas la stabilité des routes installées dans le réseau. Une fois la délégation d’adresses IP acceptée par le deuxième dispositif, les adresses IP déléguées peuvent être utilisées sans délai par le premier dispositif pour traiter les paquets émis par ou à destination des équipements clients qui lui parviennent.

Dans un autre mode de réalisation, on peut envisager de modifier les tables de routage pour faire en sorte que les paquets de données associés à une adresse IP déléguée par un dit deuxième dispositif au premier dispositif soient directement acheminés vers le premier dispositif sans transiter par le deuxième dispositif. Dans cet autre mode de réalisation, les canaux de communication établis le cas échéant entre les premier et deuxième(s) dispositifs ne sont utilisés que pour les besoins de contrôle (par exemple pour une demande de délégation d’adresses) ou pour l’acheminement de données pendant la durée nécessaire à la convergence du routage.

Dans un mode particulier de réalisation, les procédés de gestion et de collaboration sont mis en œuvre par un ordinateur.

L’invention vise également un programme d’ordinateur sur un support d’enregistrement, ce programme étant susceptible d’être mis en œuvre dans un ordinateur ou plus généralement dans un premier dispositif conforme à l’invention et comportant des instructions adaptées à la mise en œuvre d’un procédé de gestion tel que décrit ci-dessus.

L’invention vise également un programme d’ordinateur sur un support d’enregistrement, ce programme étant susceptible d’être mis en œuvre dans un ordinateur ou plus généralement dans un deuxième dispositif conforme à l’invention et comportant des instructions adaptées à la mise en œuvre d’un procédé de collaboration tel que décrit ci-dessus.

Chacun de ces programmes 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'information ou un support d’enregistrement lisibles par un ordinateur, et comportant des instructions d’un programme d'ordinateur tel que mentionné ci-dessus.

Le support d'information ou d’enregistrement peut être n'importe quelle entité ou dispositif capable de stocker les programmes. 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 un disque dur, ou une mémoire flash.

D'autre part, le support d'information ou d’enregistrement peut être un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par lien radio, par lien optique sans fil 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'information ou d’enregistrement peut être un circuit intégré dans lequel un programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution des procédés de gestion et de collaboration selon l’invention.

Selon un autre aspect encore, l’invention vise également un système au moins un premier dispositif selon l’invention et au moins un deuxième dispositif selon l’invention, configuré pour traiter au moins une demande de délégation d’adresses IP reçue d’un dit premier dispositif.

Le système bénéficie des mêmes avantages cités précédemment que les premier et deuxième dispositifs.

On peut également envisager, dans d'autres modes de réalisation, que les procédés de gestion et de collaboration, les premier et deuxième dispositifs et le système selon l’invention présentent en combinaison tout ou partie des caractéristiques précitées.

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 , déjà décrite, représente des translations d’adresses effectuées par un équipement d’accès à un réseau embarquant une fonction NAT et un NAT opérateur (CGN) déployé dans le réseau ;

la représente un système conforme à l’invention dans son environnement, dans un mode particulier de réalisation ;

la représente un exemple d’architecture matérielle d’un ordinateur hébergeant un premier dispositif et/ou un deuxième dispositif du système de la ;

la représente les modules fonctionnels d’un premier dispositif et d’un deuxième dispositif du système de la , conformes à l’invention, dans un mode particulier de réalisation ;

la représente les principales étapes d’un procédé de gestion selon l’invention telles qu’elles sont mises en œuvre par un premier dispositif du système de la ;

la représente les principales étapes mises en œuvre par le premier dispositif de la , lorsqu’en réponse à un comportement suspect associé à une adresse IP qu’il gère, il exécute une action consistant à adresser une demande de délégation d’au moins une adresse IP à un deuxième dispositif du système de la ;

la représente les principales étapes mises en œuvre par un deuxième dispositif du système de la , sollicité par le premier dispositif dudit système pour lui déléguer des adresses IP ;

la représente, par un exemple illustratif, les traitements réalisés dans le contexte de l’invention par les premier et deuxième dispositif du système de la sur des messages d’équipements clients servis par le premier dispositif ;

la représente un exemple de système conforme à l’invention servant un équipement client de type CPE ;

la illustre un réseau comprenant plusieurs niveaux de NAT opérateur, chaque niveau de NAT opérateur incluant un système conforme à l’invention.

Description de modes de réalisation de l’invention

La représente, dans son environnement, un système 1 conforme à l’invention, dans un mode particulier de réalisation dans lequel il se trouve dans un réseau 2 de communications géré par un opérateur OP2. Aucune hypothèse n’est faite quant à la nature du réseau 2, qui peut être fixe ou mobile.

Le réseau 2 comprend une pluralité de NAT opérateur ou CGN (ou de façon équivalente, une pluralité d’instances de NAT opérateur ou de CGN), déployés sur des équipements distincts, et référencés CGN#1, CGN#2,…, CGN#M, où M désigne un nombre entier supérieur à 1. Chaque NAT opérateur CGN#n, n=1,…,M dispose d’au moins une adresse IP externe (par exemple publique) notée @IP-CGN#n qui lui a été allouée par l’opérateur OP2.

Dans le mode de réalisation décrit ici, on suppose que le réseau 2 est configuré pour utiliser le protocole IPv4 et que chaque NAT opérateur CGN#n, n=1,…,M est de type NAT44, tel que décrit dans le document RFC 3032 édité par l’IETF et intitulé « Traditional IP Network Address Translator (Traditional NAT) », janvier 2001. Chaque NAT opérateur CGN#n, n=1,…,M, est configuré avec un ensemble (ou pool) d’adresses IPv4 externes (par exemple publiques) dédié et distinct, noté POOL#n, qu’il gère et peut utiliser pour traiter les paquets de données qu’il reçoit, ces paquets comprenant des données émises par ou destinées à des équipements clients du réseau 2.

Les adresses IPv4 d’un ensemble d’adresses POOL#n peuvent être contiguës (par exemple 1.2.3.0/24) ou non (par exemple 1.2.3.4/32 et 11.25.25.36/32). On suppose que des routes sont annoncées dans et en dehors du réseau 2 pour que le trafic destiné à une adresse IP d’un ensemble POOL#n soit reçu par le NAT opérateur CGN#n auquel est affecté cet ensemble d’adresses. Par souci de simplification, on fait l’hypothèse, dans le mode de réalisation décrit ici, que le réseau 2 implémente un seul niveau de NAT opérateur, c’est-à-dire que les paquets des équipements clients du réseau 2 ne sont traités, au sens de la translation d’adresses, que par un seul NAT opérateur parmi les NAT opérateur CGN#n, n=1,…,M.

Les adresses IPv4 de chaque ensemble POOL#n affecté à un NAT opérateur CGN#n peuvent être, dans le mode de réalisation décrit ici, partagées entre plusieurs équipements clients servis par le NAT opérateur CGN#n. Par « équipement client servi par un NAT opérateur » (ou de façon équivalente ici, « équipement client rattaché à ou géré par un NAT opérateur »), on entend que le NAT opérateur est en charge du traitement des paquets de données de cet équipement client (c’est-à-dire comportant des données émises ou destinées à cet équipement client), et notamment de la translation des adresses IP véhiculées dans ces paquets, c’est-à-dire la translation d’une adresse dite « interne » en une adresse dite « externe » (ou inversement selon le sens de communication considéré).

On note qu’un équipement client n’a pas nécessairement la connaissance du NAT opérateur désigné pour le servir. De même, le NAT opérateur CGN#n n’a pas nécessairement la connaissance explicite de l’équipement client auquel se rapporte un paquet qu’il doit traiter et qui est transporté en utilisant une adresse IP interne (l’information concernant l’équipement client peut toutefois être connue si un mécanisme tel que décrit par exemple dans le document RFC 7785, intitulé « Recommendations for Prefix Binding in the Context of Softwire Dual-Stack Lite », février 2016, est mis en œuvre par le NAT opérateur). Il exploite l’adresse IP « interne » utilisée pour transporter ce paquet jusqu’à lui pour la traduire en une adresse IP « externe » de l’ensemble POOL#n. Quel que soit le mode de fonctionnement du NAT opérateur CGN#n, il n’en demeure pas moins qu’il en résulte que le NAT opérateur CGN#n peut sélectionner, pour traiter les paquets de plusieurs équipements clients distincts, une même adresse IPv4 externe parmi les adresses IPv4 externes de l’ensemble POOL#n qu’il gère.

Dans la suite de la description, par souci de simplification, on omet parfois les notions « d’adresse interne/externe » pour qualifier les adresses IP considérées, sauf s’il y a lieu de distinguer ces adresses. En effet, ces notions sont relatives et définies par rapport au NAT opérateur considéré : au niveau d’un NAT opérateur donné, une adresse IP interne véhiculée par un paquet émis par un équipement client est translatée en une adresse IP externe (et vice versa, selon le sens de communication considéré). Toutefois, lorsque deux niveaux de NAT opérateur sont envisagés, un NAT opérateur du premier niveau procède à une translation d’une adresse interne telle qu’elle figure dans l’entête d’un paquet émis par un équipement client en une adresse externe, mais cette adresse externe est considérée comme une adresse interne du point de vue d’un NAT opérateur du deuxième niveau.

Aucune hypothèse n’est faite quant à la nature des équipements clients auxquels s’applique l’invention. Il peut s’agir de terminaux (par exemple des smartphones, des tablettes, des ordinateurs), d’équipements d’accès d’un réseau LAN (pour « Local Area Network » en anglais) au réseau 2 (par exemple des CPE auxquels sont connectés des terminaux), etc. A titre illustratif, dans le mode de réalisation illustré par la , les équipements clients servis par les NAT opérateur CGN#n, n=1,…,M sont des terminaux.

Les critères de sélection et d’utilisation d’une adresse IP (alors dite « active ») d’un ensemble POOL#n sont spécifiques à chaque NAT opérateur ; chaque NAT opérateur décide localement (typiquement conformément à sa configuration) de la façon dont les adresses IP actives de l’ensemble qui lui a été affecté sont gérées. Par exemple, un NAT opérateur CGN#n, n=1,…,M, peut décider du nombre d’adresses IP à utiliser parmi celles de l’ensemble d’adresses POOL#n qu’il gère en fonction du ou des taux de partage avec le(s)quel(s) il a été le cas échéant configuré et du nombre d’équipements clients actifs (c’est-à-dire ayant une connexion active, représentée dans une base ou une table BIB maintenue par le NAT opérateur CGN#n, telle qu’évoquée précédemment) qu’il sert. Un même taux de partage (noté ici « 1:x » pour indiquer qu’une même adresse IP peut être partagée entre x équipements clients, ou plus généralement qu’une même adresse IP externe peut être partagée entre x adresses IP internes compte tenu de la remarque précédente) peut être appliqué par le NAT opérateur CGN#n à chaque adresse IP (externe) destinée à être partagée. En variante, on peut envisager d’appliquer des taux de partage différents en fonction des adresses IP ou selon d’autres critères (par exemple des considérations géographiques). On peut également envisager de partager seulement certaines adresses IP, etc.

Les critères de rattachement d’un groupe d’équipements clients à un NAT opérateur CGN#n donné sont connus de l’homme du métier et ne sont pas détaillés ici ; ils relèvent du savoir-faire de l’exploitant des NAT opérateur CGN#n, n=1,…,M, à savoir ici de l’opérateur OP2 du réseau 2. Il en est de même pour ce qui concerne la manière dont les NAT opérateurs CGN#n, n=1,…,M, sont placés sur les chemins empruntés par les communications établies par les équipements clients qu’ils servent.

Les hypothèses évoquées précédemment ne sont pas limitatives en soi. L’invention peut également s’appliquer dans d’autres contextes, et notamment à des adresses IPv6, à d’autres types de NAT opérateur (par exemple NAT64, DS-Lite, NPTv6), les NAT opérateur du réseau 2 pouvant être tous d’un même type ou de types différents, colocalisés ou déployés sur des équipements matériels distincts, ou encore virtualisés et hébergés dans des infrastructures de type cloud. En outre, les NAT opérateur peuvent être déployés de façon distribuée dans le réseau 2 (avec des (instances de) NAT opérateur déployé(e)s au plus près des équipements clients) ou de façon centralisée. On peut également envisager plusieurs niveaux de NAT opérateur, c’est-à-dire qu’un paquet d’un équipement client du réseau 2 peut faire l’objet de translations d’adresses successives réalisées par des NAT opérateur déployés sur plusieurs niveaux au sein du réseau 2.

Par souci de simplification ici, on suppose que l’ensemble des NAT opérateur CGN#n, n=1,…,M déployés dans le réseau 2 appartiennent au système 1, et que chaque NAT opérateur CGN#n, n=1,…,M, embarque divers modules configurés pour mettre en œuvre, selon le contexte dans lequel se trouve le NAT opérateur CGN#n, un procédé de gestion ou un procédé de collaboration selon l’invention. Autrement dit, chaque NAT opérateur CGN#n, n=1,…,M embarque les modules fonctionnels d’un premier dispositif D1 selon l’invention, susceptible de détecter un comportement suspect associé à une adresse IP qu’il gère, et les modules fonctionnels d’un deuxième dispositif D2 selon l’invention, susceptible de collaborer avec un autre NAT opérateur du système 1 (sur la , par souci de simplification, les dispositifs D1 et D2 n’ont été représentés que pour le NAT opérateur CGN#1) ; en fonction du contexte, le NAT opérateur CGN#n active les modules fonctionnels de l’un ou l’autre des dispositifs D1 et D2 qu’il embarque. Dans le mode de réalisation décrit ici, un même NAT opérateur CGN#n du système 1 peut donc tantôt être un premier dispositif conforme à l’invention, tantôt un deuxième dispositif conforme à l’invention.

Bien entendu, cette hypothèse n’est pas limitative en soi et on peut envisager d’autres configurations pour le système 1. Par exemple, le système 1 peut n’intégrer qu’un sous-ensemble des NAT opérateur du réseau 2, et les NAT opérateur concernés peuvent embarquer uniquement les modules fonctionnels d’un premier dispositif D1 selon l’invention ou uniquement les modules fonctionnels d’un deuxième dispositif D2 selon l’invention, étant entendu que parmi les NAT opérateur du système 1, se trouvent au moins un premier dispositif D1 et au moins un deuxième dispositif D2 conformes à l’invention.

Par ailleurs, chaque NAT opérateur CGN#n, n=1,…,M, du système 1 dispose d’un canal de communication (par exemple ici un canal DOTS) établi avec au moins une fonction (ou un système) de détection d’attaques, connue en soi et non décrite en détail ici. Les NAT opérateur CGN#n, n=1,…,M du système 1 peuvent solliciter une ou plusieurs fonctions de détection d’attaques distinctes via les canaux DOTS ainsi établis. Dans l’exemple de la , on s’intéresse aux attaques de type DDoS, et la ou les fonctions de détection d’attaques avec lesquelles les NAT opérateur CGN#n, n=1,…,M, établissent des canaux DOTS sont des centres de mitigation DDoS ou DMS. Bien entendu, l’invention s’applique à d’autres types d’attaques informatiques et à d’autres fonctions/systèmes de détection d’attaques (par exemple plus généralement à des centres AMS).

Chaque canal DOTS ainsi établi permet à chaque NAT opérateur CGN#n, n=1,…,M, de recevoir des centres DMS des informations concernant les attaques DDoS dont la source ou la destination est une adresse de l’ensemble POOL#n d’adresses IP qu’il gère. Plus particulièrement :

• pour recevoir via un tel canal DOTS des notifications d’un centre DMS concernant des attaques dont la cible est une adresse IP de l’ensemble POOL#n, le NAT opérateur CGN#n est configuré pour utiliser ici un mécanisme de souscription auprès du centre DMS tel que celui décrit dans le document RFC 9244 cité précédemment, notamment au point 8.1.1 ;
• pour recevoir via un tel canal DOTS des notifications d’un centre DMS concernant des attaques dont la source est une adresse IP de l’ensemble POOL#n, une nouvelle extension au mécanisme décrit dans le document RFC 9244 peut être spécifiée. La nouvelle extension proposée consiste à définir une nouvelle option « Uri-Query», appelée par exemple « source-address », permettant au NAT opérateur CGN#n d’indiquer dans une requête adressée au centre DMS, les adresses de l’ensemble POOL#n pour lesquelles il souhaite être notifié. La Table 1 illustre un exemple d’une telle requête incluant la nouvelle option « source-address » renseignée avec l’adresse IP « 1.2.3.4 ».

Header: GET (Code=0.01) Uri-Path: ".well-known" Uri-Path: "dots" Uri-Path: "tm" Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" Uri-Query: "source-address=1.2.3.4" Observe: 0

Les notifications envoyées par un centre DMS au NAT opérateur CGN#n peuvent être générées par le centre DMS suite à une détection locale ou suite à la réception par le centre DMS d’une notification en provenance d’autres entités (par exemple d’un autre centre DMS).

Dans le mode de réalisation décrit ici, un canal DOTS est également établi entre chaque NAT opérateur CGN#n, n=1,…,M du système 1 et un système de réputation REP_SYS. Ce canal DOTS est établi par exemple ici en utilisant une requête de configuration caractéristique du protocole RESTCONF. Cette requête comprend un filtre de souscription conditionnant les notifications envoyées par le système de réputation REP_SYS au NAT opérateur CGN#n. Le filtre de souscription désigne par exemple tout ou partie des adresses IP de l’ensemble POOL#n géré par le NAT opérateur CGN#n.

De façon connue, un tel système de réputation REP_SYS est adapté à évaluer un niveau de réputation d’une adresse IP, ce niveau de réputation reflétant le degré de confiance qu’on peut avoir en cette adresse IP. Il est établi en collectant des données spécifiques auprès de différentes entités (par exemple un routeur du réseau), comme par exemple le volume de trafic suspect associé à l’adresse IP, son appartenance éventuelle à une liste bloquée ou « block-list », son implication éventuelle dans des attaques informatiques, etc. Plus le niveau de réputation d’une adresse IP est élevé, plus son comportement est considéré comme sûr. A l’inverse, un niveau de réputation faible (typiquement inférieur à un certain seuil) traduit un risque élevé de comportement malveillant associé à l’utilisation de l’adresse IP (et donc du trafic émis avec une telle adresse comme adresse source). Le canal DOTS établi entre un NAT opérateur CGN#n et le système de réputation REP_SYS permet ainsi au NAT opérateur CGN#n d’obtenir les niveaux de réputation déterminés par le système de réputation REP_SYS pour les adresses IP de l’ensemble POOL#n que le NAT opérateur CGN#n gère.

Il convient de noter que les centres DMS et le système de réputation peuvent être exploités par une même entité administrative (par exemple par l’opérateur OP2 gérant les NAT opérateur CGN#n, n=1,…,M) ou par des entités administratives distinctes. En outre, aucune hypothèse n’est faite quant à la localisation de ces systèmes. Notamment, un même équipement matériel peut embarquer le système REP_SYS de réputation et un centre DMS.

Dans le mode de réalisation décrit ici, les NAT opérateur CGN#n, n=1,…,M sont hébergés par des équipements ayant l’architecture matérielle d’un ordinateur 3 telle que représentée sur la .

Chaque ordinateur 3 comprend un processeur PROC, une mémoire vive MEM, une mémoire morte ROM, une mémoire non volatile NVM, et des moyens COM de communications, permettant aux NAT opérateur CGN#n, n=1,…,M, de communiquer notamment avec d’autres entités du réseau 2 (et plus particulièrement de communiquer entre eux), avec les centres DMS et le système de réputation REP_SYS, ainsi qu’avec les équipements clients qu’ils servent. De tels moyens de communication sont connus en soi et ne sont pas décrits en détail ici.

La mémoire non volatile NVM de l’ordinateur 3 constitue un support d’enregistrement conforme à l’invention, lisible par le processeur PROC et sur lequel sont enregistrés ici des programmes d’ordinateur PROG1 et PROG2 conformes à l’invention.

Plus spécifiquement, le programme d’ordinateur PROG1 comporte des instructions définissant les principales étapes d’un procédé de gestion selon l’invention. Il définit des modules fonctionnels d’un premier dispositif D1 selon l’invention, et incidemment, dans le mode de réalisation décrit ici, de chaque NAT opérateur CGN#n, n=1,…,M. Ces modules fonctionnels s’appuient ou commandent les éléments PROC, MEM, ROM, NVM, et COM de l’ordinateur 3 cités précédemment, et comprennent ici, pour chaque NAT opérateur CGN#n, comme illustré par la :

• un module 4 de détection, configuré pour détecter un comportement suspect associé à une adresse IP active de l’ensemble POOL#n géré par le NAT opérateur CGN#n, sélectionnée par celui-ci pour traiter au moins un paquet d’un équipement client servi par le NAT opérateur CGN#n ; et
• un module 5 d’exécution, configuré pour exécuter au moins une action en réaction au comportement suspect détecté par le module 4 de détection. Plus particulièrement, dans le mode de réalisation décrit ici, le module EXEC d’exécution est configuré pour choisir la ou les actions à exécuter parmi un ensemble donné ACT d’actions, comprenant au moins les actions suivantes :
  • une action ACT1 consistant à retirer l’adresse IP associée à un comportement suspect de l’ensemble POOL#n d’adresses IP pouvant être sélectionnées par le NAT opérateur CGN#n pour traiter les paquets des équipements clients qu’il sert (ce retrait pouvant concerner seulement les connexions susceptibles d’être établies dans le futur par un équipement client, mais également les connexions en cours (autrement dit actives, telles que représentées dans la table BIB maintenue par CGN#n)) ;
  • une action ACT2 consistant à ajuster au moins un taux de partage d’au moins une adresse IP de l’ensemble POOL#n ; et
  • une action ACT3 consistant à demander une délégation d’adresses IP à au moins un autre NAT opérateur CGN#j du système 1, avec j≠n. Par délégation, on entend ici que le NAT opérateur CGN#j accepte d’attribuer une ou plusieurs adresses IP de son ensemble POOL#j au NAT opérateur CGN#n pour que ce dernier puisse la ou les utiliser pour traiter des paquets d’équipements clients qui lui sont rattachés.

Le choix de l’action ou des actions exécutées par le module 5 d’exécution peut dépendre du contexte (par exemple de la nature du comportement malveillant détecté, du nombre de connexions actives traitées par le NAT opérateur CGN#n, du taux de partage effectif des adresses IP de l’ensemble POOL#n qu’il gère, de la gravité de l’attaque, etc.). Dans le mode de réalisation décrit ici, le module 5 est configuré pour choisir, en réponse à un comportement suspect associé à une adresse IP, au moins une action parmi l’action ACT2 d’ajustement d’au moins un taux de partage et l’action ACT3 de demande de délégation. Bien entendu, d’autres actions peuvent être sélectionnées par le module 5 en plus de l’une de ces deux actions, et d’autres actions peuvent être considérées dans l’ensemble ACT pris en compte par le module 5 d’exécution.

Le programme PROG1 définit également ici trois autres modules du NAT opérateur CGN#n en tant que premier dispositif D1 conforme à l’invention, à savoir :

• un module 6 de découverte, configuré pour découvrir les NAT opérateur du système 1 susceptibles de collaborer avec le NAT opérateur CGN#n et en particulier de lui déléguer des adresses IP ;
• un module 7 d’établissement, configuré pour établir des canaux de communication avec tout ou partie des NAT opérateur ainsi découverts ; et
• un module 8 de transmission/réception de transmission de données. Ce module 8 est notamment configuré pour transmettre et/ou recevoir des données via les canaux de communication établis par le module 7 d’établissement et pour transmettre et/ou recevoir des paquets de données des équipements clients servis par le NAT opérateur CGN#n.

Les modules 4 à 8 sont décrits plus en détail ultérieurement en référence aux étapes du procédé de gestion selon l’invention.

Le programme d’ordinateur PROG2 stocké dans la mémoire non volatile NVM de l’ordinateur 3 comporte des instructions définissant les principales étapes d’un procédé de collaboration selon l’invention. Il définit des modules fonctionnels d’un deuxième dispositif D2 conforme à l’invention, et incidemment, dans le mode de réalisation décrit ici, de chaque NAT opérateur CGN#n, n=1,…,M. Ces modules fonctionnels s’appuient ou commandent les éléments PROC, MEM, ROM, NVM, et COM de l’ordinateur 3 cités précédemment, et comprennent ici, pour chaque NAT opérateur CGN#n, comme illustré sur la :

• un module 9 de réception, configuré pour recevoir en provenance d’un autre NAT opérateur CGN#k du système 1, avec k≠n, une demande de délégation d’au moins une adresse IP de l’ensemble POOL#n d’adresses IP géré par le NAT opérateur CGN#n ; et
• un module 10 d’envoi, configuré pour envoyer au NAT opérateur CGN#k, une liste comprenant au moins une adresse IP de l’ensemble POOL#n que le NAT opérateur CGN#n accepte de lui déléguer.

Le programme PROG2 définit également ici un module 11 de transmission/réception de données.

Les modules 9 à 11 du NAT opérateur CGN#n sont décrits plus en détail ultérieurement en référence aux étapes du procédé de collaboration selon l’invention.

Il convient de noter qu’outre les modules 4 à 11 qui viennent d’être évoqués, chaque NAT opérateur CGN#n dispose également d’un module 12 de gestion de l’ensemble POOL#n d’adresses IP qui lui est affecté et d’un module 13 de translation d’adresses. Bien entendu, d’autres fonctions que la translation d’adresses peuvent être mises en œuvre par le NAT opérateur CGN#n (par exemple une fonction ALG, etc.), toutefois ces fonctions ne sont pas considérées ici par souci de simplification.

Le module 12 de gestion est notamment en charge de sélectionner une adresse IP dite externe parmi l’ensemble POOL#n (complété éventuellement par les adresses IP qui lui sont le cas échéant déléguées) pour traiter chaque paquet d’un équipement client qu’il reçoit portant une adresse IP dite interne, et de respecter le ou les taux de partage d’adresses IP avec le(s)quel(s) il a été configuré. L’adresse IP externe sélectionnée pour traiter un paquet d’un équipement client est mémorisée par le module 12 de gestion en association avec l’adresse IP interne, dans la table BIB maintenue par le NAT opérateur CGN#n, et stockée ici dans la mémoire non volatile NVM du NAT opérateur CGN#n. Comme mentionné précédemment, le module 12 de gestion peut associer une même adresse IP externe de l’ensemble POOL#n à plusieurs adresses IP internes distinctes, conformément à un taux de partage avec lequel il a été configuré le cas échéant préalablement.

Le module 13 de translation d’adresses est configuré pour traiter les paquets d’équipements clients reçus par le NAT opérateur CGN#n, et translater le cas échéant les adresses IP de ces paquets conformément aux informations mémorisées dans la table BIB. La structure de la table BIB, son alimentation et sa maintenance, ainsi que le traitement des paquets des équipements clients servis par le NAT opérateur CGN#n conformément aux informations consignées dans la table BIB sont connus en soi et ne sont pas repris davantage ici.

Lorsqu’une même adresse IP externe est partagée entre plusieurs équipements clients, plusieurs entrées dans la table BIB associent cette adresse IP externe à plusieurs adresses IP internes distinctes. Afin de permettre au module 13 de translation d’associer la bonne adresse IP interne à un paquet de données qu’il reçoit, différentes techniques peuvent être envisagées de façon connue en soi. Par exemple, la différenciation peut se faire sur la base d’un état maintenu par le NAT opérateur CGN#n dans une table locale (un numéro de port associé à l’adresse IP interne dans la table BIB, un identifiant de l’équipement client, un protocole de transport, etc.), ou en mettant en œuvre un algorithme prévu à cet effet (par exemple pour un NAT opérateur de type NPTv6), etc.

Nous allons maintenant décrire, en référence à la , les principales étapes d’un procédé de gestion selon l’invention telles qu’elles sont mises en œuvre par chaque NAT opérateur CGN#n du système 1 lorsqu’il agit en tant que premier dispositif D1 selon l’invention, c’est-à-dire lorsqu’il détecte un comportement malveillant associé à une adresse IP qu’il gère.

Dans le mode de réalisation décrit ici, chaque NAT opérateur CGN#n, n=1,…,M du système 1 procède préalablement à la découverte, via son module 6 de découverte, des autres NAT opérateur CGN#j, avec j=1,…,M et j≠n, du système 1 (étape E10). A cet effet, le module 6 de découverte peut utiliser un protocole de routage dynamique tel que le protocole OSPF, ou dans le contexte d’un réseau 2 de type 5G, interroger la fonction NRF du réseau 2, etc.

Puis, chaque NAT opérateur CGN#n, n=1,..,M du système 1 établit, par l’intermédiaire de son module 7 d’établissement, un canal de communication avec chacun des NAT opérateur découverts lors de l’étape E10 de découverte (étape E20). Ces canaux de communication sont appelés dans la suite de la description canaux COGITARE (pour « COllaborative cGns for advanced Ip network repuTAtion safeguaRd/softEnings » en anglais). Ils peuvent être établis de sorte à être utilisés de façon unidirectionnelle (seul le NAT opérateur à l’origine de l’établissement du canal peut utiliser le canal pour envoyer une demande de délégation comme décrit ultérieurement) ou de façon bidirectionnelle (chaque NAT opérateur à un extrémité du canal peut envoyer une demande de délégation à l’autre NAT opérateur).

Dans le mode de réalisation décrit ici, ces canaux COGITARE sont chiffrés et reposent sur le protocole QUIC, décrit notamment dans le document RFC 9000 de l’IETF intitulé « QUIC: A UDP-Based Multiplexed and Secure Transport », mai 2021. En variante, les canaux COGITARE peuvent reposer sur un autre protocole que QUIC, par exemple sur le protocole IP-in-IP permettant d’encapsuler des paquets IP dans d’autres paquets IP moyennant l’établissement de tunnels (ou « tunneling » en anglais). Ces canaux peuvent ne pas être chiffrés, si les NAT opérateur sont considérés comme des entités de confiance, par exemple.

Pour mettre en œuvre l’invention dans le contexte du protocole QUIC, un nouveau paramètre de transport est défini, appelé par exemple « delegate_resources_enable ». Ce paramètre est valorisé ici à 1 par un NAT opérateur lorsque celui-ci est configuré pour mettre en œuvre un procédé de collaboration selon l’invention, c’est-à-dire qu’il est apte à déléguer des adresses IP du pool d’adresses qu’il gère à un autre NAT opérateur du système 1. On note que cette aptitude ne présume pas de la disponibilité effective d’adresses IP à déléguer au niveau du NAT opérateur en question, mais seulement de sa capacité, dans l’hypothèse où de telles adresses IP seraient disponibles dans le pool d’adresses qu’il gère, à déléguer de telles adresses IP, c’est-à-dire de sa capacité à mettre en œuvre le procédé de collaboration selon l’invention et à agir en tant que deuxième dispositif selon l’invention. Ainsi, on suppose ici que lorsqu’un NAT opérateur CGN#n initialise l’établissement d’un canal COGITARE avec un autre NAT opérateur CGN#j, j≠n, il insère dans la trame QUIC qu’il envoie le paramètre « delegate_resources_enable » valorisé à 1. Il convient de noter que ce paramètre peut être utilisé de manière additionnelle par un NAT opérateur pour signaler à un autre NAT opérateur qu’en plus d’être configuré pour mettre en œuvre un procédé de collaboration selon l’invention, il est également configuré pour mettre en œuvre un procédé de gestion selon l’invention, c’est-à-dire qu’il peut être amené à solliciter l’autre NAT opérateur pour qu’il lui délègue des adresses IP. Cette information additionnelle peut être transmise à des fins informatives, et être exploitée par l’autre NAT opérateur pour effectuer un contrôle le cas échéant s’il reçoit une demande de délégation de ce NAT opérateur (par exemple pour déterminer si cette demande de délégation est cohérente avec ce que lui avait annoncé le NAT opérateur).

Si le NAT opérateur CGN#j avec lequel le NAT opérateur CGN#n tente d’établir un canal COGITARE n’est pas apte à collaborer avec un autre NAT opérateur du système 1 et à lui déléguer au moins une adresse IP, il répond par une trame QUIC dans laquelle le paramètre « delegate_resources_enable » est valorisé à 0, ou par une trame QUIC ne contenant pas ce paramètre. Le cas échéant, la procédure d’établissement d’un canal COGITARE est prématurément clôturée, et aucun canal COGITARE n’est établi.

A l’inverse, si le NAT opérateur CGN#j avec lequel le NAT opérateur CGN#n tente d’établir un canal COGITARE est apte à déléguer une ou plusieurs des adresses IP qu’il gère, il répond par une trame QUIC dans laquelle le paramètre « delegate_resources_enable » est valorisé à 1, et le canal COGITARE est établi selon les principes définis par le protocole QUIC.

Le NAT opérateur CGN#n mémorise ici dans une table CAPA stockée dans la mémoire non volatile NVM, pour chaque NAT opérateur CGN#j sollicité par le NAT opérateur CGN#n pour l’établissement d’un canal COGITARE, son aptitude ou non à déléguer des adresses IP. Ceci revient à mémoriser dans la table CAPA la valeur du paramètre « delegate_resources_enable » retournée ou déduite de la trame QUIC envoyée par le NAT opérateur CGN#j en réponse à la demande d’établissement d’un canal COGITARE du NAT opérateur CGN#n. Le NAT opérateur CGN#n peut en outre mémoriser dans la table CAPA d’autres informations relatives à chaque NAT opérateur CGN#j sollicité, comme par exemple une ou plusieurs adresses IP permettant de le joindre.

Bien entendu, les valeurs 1 et 0 proposées pour valoriser le paramètre « delegate_resources_enable » ne sont données qu’à titre illustratif et ne sont pas limitatives en soi, d’autres valeurs pouvant être envisagées pour indiquer si un NAT opérateur est apte ou non à déléguer des adresses IP à un autre NAT opérateur. Par ailleurs, le paramètre « delegate_ressources_enable », quelle que soit sa valeur, peut être échangé entre les NAT opérateur à tout moment (lors de la tentative d’établissement du canal COGITARE comme décrit précédemment, ou ultérieurement, une fois le canal établi).

Nous supposons maintenant que l’un des NAT opérateur du système 1, par exemple le NAT opérateur CGN#1 à titre illustratif, détecte par l’intermédiaire de son module 4 de détection un comportement suspect associé à une adresse IP de l’ensemble POOL#1 d’adresses IP qu’il gère (réponse oui à l’étape test E30). Par « comportement suspect », on entend ici que le comportement associé à l’adresse IP en question, notée dans la suite bad@IP, n’est pas normal et laisse présager que l’adresse IP est utilisée à des fins malveillantes (par exemple elle est associée à activité suspecte) ou ciblée par une attaque.

La détection d’un tel comportement suspect peut être réalisée par divers moyens.

Par exemple, le module 4 de détection du NAT opérateur CGN#1 peut recevoir une notification du système de réputation REP_SYS lui indiquant un niveau de réputation de l’adresse bad@IP inférieur à un seuil déterminé, avec lequel CGN#1 a été préalablement configuré et en deçà duquel le comportement associé à l’utilisation de l’adresse IP est considéré comme malveillant ou tout du moins suspect.

Selon un autre exemple, le module 4 de détection peut recevoir une notification d’une fonction de détection d’attaques d’un centre DMS (ou plus généralement d’un centre AMS) lui indiquant que l’adresse bad@IP appartient à une liste noire d’adresses IP considérées comme étant associées à des actions malveillantes ou que l’adresse bad@IP a été identifiée comme une cible ou utilisée comme l’origine d’une attaque.

Il convient de noter que dans les notifications du système REP_SYS ou du centre DMS peuvent viser un nom de domaine, auquel cas le module 4 de détection est configuré pour procéder à la résolution de ce nom de domaine en vue d’obtenir l’adresse bad@IP correspondante.

Selon un autre exemple encore, le module 4 de détection peut intégrer une fonction de détection d’attaques et déterminer lui-même localement que l’adresse bad@IP est associée à un comportement suspect.

Ces exemples ne sont donnés qu’à titre illustratif et ne sont pas limitatifs de l’invention.

Suite à cette détection, CGN#1 vérifie ici que l’adresse bad@IP appartient bien à l’ensemble POOL#1 d’adresses IP qui lui a été affecté (ce qui est le cas ici) (étape E40). Le cas échéant, il active son module 5 d’exécution pour exécuter au moins une action en réponse à cette détection. On note que l’étape E40 de vérification est optionnelle (si elle n’est pas mise en œuvre, le module 5 d’exécution est activé sur détection par le module 4 du comportement suspect associé à l’adresse bad@IP).

L’action ou les actions alors exécutées par le module 5 d’exécution peuvent être sélectionnées par celui-ci en fonction du contexte. Comme mentionné précédemment, dans le premier mode de réalisation décrit ici, le module 5 d’exécution choisit d’exécuter au moins une action parmi l’ensemble ACT d’actions comprenant :

• l’action ACT1 consistant à retirer l’adresse bad@IP des adresses IP de l’ensemble POOL#1 pouvant être sélectionnées par CGN#1 pour traiter les paquets des équipements clients qu’il sert (désignées plus simplement dans la suite par « adresses IP actives »). Il convient de noter que ce retrait peut concerner uniquement les connexions futures susceptibles d’être établies par des équipements clients (typiquement les paquets concernant d’autres équipements clients que ceux déjà servis par CGN#1 au moment du retrait), et/ou également les connexions actives (c’est-à-dire en cours). Le choix de l’une ou l’autre des stratégies peut résulter d’une politique de l’opérateur OP2, différer en fonction du contexte (par exemple de la localisation de la source de l’attaque), etc. Par exemple, le maintien de l’adresse bad@IP pour traiter les paquets caractéristiques de connexions actives peut être justifié lorsque la source d’une attaque est interne au réseau 2, et/ou pour éviter de devoir migrer tous les équipements clients servis avec l’adresse bad@IP par CGN#1 ;
• l’action ACT2 consistant à ajuster au moins un taux de partage d’au moins une adresse IP de l’ensemble POOL#1 ; par exemple, au moins un taux de partage peut être augmenté si le NAT opérateur CGN#1 ne dispose plus d’adresses IP pour pouvoir servir les équipements clients qui lui sont rattachés (par exemple pour passer de 1:10 à 1 :20 ou de 1:2 à 1:5). Cet ajustement dynamique d’au moins un taux de partage permet avantageusement de compenser le comportement malveillant associé à l’adresse bad@IP, et en particulier, son retrait le cas échéant des adresses IP actives si l’action ACT1 est également exécutée. On note qu’un tel ajustement dynamique peut porter de façon globale sur les taux de partage de toutes les adresses IP du pool POOL#1 (à l’exception du taux de partage de l’adresse bad@IP, qui peut au contraire être réduit voire inutilisé en cas de retrait), ou être appliqué de façon différenciée à seulement une partie des adresses IP du pool POOL#1. En outre, un taux de partage peut être ajusté à plusieurs reprises si besoin (par exemple si plusieurs notifications signalant le comportement suspect de plusieurs adresses IP distinctes sont reçues par le module 4 de détection) ; et
• l’action ACT3 consistant en une demande de délégation d’adresses IP adressée à au moins un autre NAT opérateur CGN#j du système 1, avec j≠1. L’action ACT3 peut notamment être sélectionnée par le module 5 d’exécution lorsque les taux de partage des adresses IP actives de l’ensemble POOL#1 (distinctes de l’adresse bad@IP associée à un comportement suspect) ont atteint une valeur maximale, définie par exemple par l’opérateur OP2, rendant alors impossible la sélection l’action ACT2. Ceci n’est toutefois qu’un exemple illustratif, et l’action ACT3 peut être sélectionnée par le module 5 d’exécution dans d’autres contextes.

Dans le mode de réalisation décrit ici, le module 5 d’exécution est configuré pour choisir, en réponse au comportement suspect de l’adresse bad@IP, au moins l’une des actions ACT2 ou ACT3, puis pour exécuter la ou les actions ainsi choisies (étape E50). Il peut par ailleurs, en complément de l’action ACT2 et/ou ACT3, exécuter également l’action ACT1. Bien entendu, l’invention ne se limite pas aux actions précitées et d’autres actions peuvent être envisagées et exécutées en variante par le NAT opérateur CGN#1 comme par exemple, mettre à jour un ensemble du système REP_SYS de réputation, marquer les paquets utilisant l’adresse bad@IP pour faciliter la reconnaissance et la classification du trafic de sorte que des puits de trafic puissent être mis en place dynamiquement dans le réseau 2, etc.

Par ailleurs, il convient de noter que la ou les actions sélectionnées par le module 5 d’exécution peuvent être exécutées par ce dernier durant une période de temps limitée. Par exemple, le module 5 d’exécution peut, conformément à l’action ACT1, retirer l’adresse bad@IP de la liste des adresses IP pouvant être sélectionnées pour traiter les messages des équipements clients qu’il sert pendant une durée donnée désignée ici par PAUSE_TIMER. Si à l’issue de la durée PAUSE_TIMER, le module 4 de détection ne détecte plus de comportement suspect associé à l’adresse bad@IP (par exemple, il ne reçoit aucune nouvelle notification d’un système DMS ou d’un système REP_SYS portant sur cette adresse IP), dans ce cas il peut réactiver l’adresse bad@IP, autrement dit la réintégrer parmi les adresses IP de l’ensemble POOL#1 pouvant être sélectionnées pour traiter des messages parvenant à CGN#1.

Nous allons maintenant décrire plus en détail, en référence auxfigures 6 et 7, le déroulement de l’étape E50 lorsque l’action ACT3 (demande de délégation d’adresses IP à un autre NAT opérateur) est sélectionnée par le module 5 d’exécution. La illustre les étapes mises en œuvre par le NAT opérateur CGN#1 à l’origine de la demande de délégation, tandis que la illustre les étapes mises en œuvre par un NAT opérateur du système 1 recevant et acceptant cette demande de délégation (c’est-à-dire agissant en tant que deuxième dispositif au sens de l’invention). Les étapes illustrées par la correspondent à celles d’un procédé de collaboration selon l’invention. Il va de soi que bien qu’étant décrites sur la base d’un exemple illustratif, les étapes représentées dans les figures 5 à 7 s’appliquent à tous les NAT opérateur du système 1 en fonction du rôle joué par chacun d’entre eux (premier ou deuxième dispositif selon l’invention).

Dans le mode de réalisation envisagé ici, comme décrit précédemment, des canaux COGITARE ont été établis, préalablement lors de l’étape E20, par CGN#1 avec les NAT opérateurs du système 1 découverts lors de l’étape E10. Par ailleurs, lors de l’établissement de ces canaux COGITARE, CGN#1 a été informé par les NAT opérateur avec lesquels il a établi ces canaux, de leur aptitude ou non à déléguer des adresses IP à d’autres NAT opérateur du système 1. Cette information est stockée dans la table CAPA de CGN#1. Ainsi, suite à la sélection de l’action ACT3, le module 5 d’exécution de CGN#1 consulte la table CAPA et détermine à quel(s) NAT opérateur du système 1 il peut adresser sa demande de délégation d’adresses IP (il s’agit des NAT opérateur aptes à mettre en œuvre l’invention et donc susceptibles de déléguer des adresses IP, autrement dit dans l’exemple envisagé ici, ceux ayant indiqué un paramètre « delegate_resources_enable » valorisé à 1) (étape E50-1).

On note qu’en variante les étapes de découverte E10 et d’établissement E20 des canaux COGITARE peuvent être implémentées par le NAT opérateur CGN#1 après l’étape E30 de détection d’un comportement suspect associé à l’adresse bad@IP, par exemple après que le module 5 d’exécution a décidé d’exécuter l’action ACT3.

Le module 5 d’exécution de CGN#1 demande à au moins un des NAT opérateur identifiés lors de l’étape E50-1, de lui déléguer au moins une adresse IP parmi l’ensemble POOL d’adresses IP qu’il gère (étape E50-2). On note que le module 5 d’exécution peut adresser cette demande de délégation à tous les NAT opérateur identifiés lors de l’étape E50-1 ou seulement à une partie d’entre eux (il peut par exemple en choisir un aléatoirement, ou selon un critère déterminé, etc.). Par souci de simplification, on suppose ici que CGN#1 adresse sa demande de délégation à un unique NAT opérateur du système 1, à savoir au NAT opérateur CGN#2 (deuxième dispositif au sens de l’invention).

Dans le mode de réalisation envisagé ici de canaux COGITARE reposant sur le protocole QUIC, le module 5 d’exécution de CGN#1 demande une délégation d’adresses IP à CGN#2 en lui envoyant une trame QUIC, spécifiée pour les besoins de l’invention et appelée par exemple ici IP_RESOURCE_DELEGATE. Cette trame est envoyée par CGN#1 à CGN#2 via le canal COGITARE établi entre eux. Elle peut être vide (et donc ne contenir aucun paramètre), ou en variante contenir un ou plusieurs paramètres précisant la demande de CGN#1, comme par exemple un paramètre nommé ici « requested-size » indiquant une préférence concernant la taille de l’espace des adresses IP à déléguer, ou de façon équivalente un paramètre nommé ici « requested-nb » indiquant un nombre d’adresses déléguées souhaitées, un paramètre nommé ici « requested-af » indiquant le type d’adresses IP déléguées souhaitées (par exemple valorisé à 0 pour des adresses IPv4 et à 1 pour des adresses IPv6, l’absence de ce paramètre pouvant être considérée comme équivalent à une valorisation du paramètre à 0, c’est-à-dire comme désignant des adresses IPv4), etc.

Ainsi, à titre illustratif, une trame IP_RESOURCE_DELEGATE comprenant un paramètre « requested-size » valorisé à 32 (bits) et ne contenant pas de paramètre « requested-af » indique une demande de délégation d’une unique adresse IPv4 (le paramètre « requested-size » combiné à l’absence de paramètre « requested-af » indique en effet un nombre d’adresses IP déléguées souhaitées). Bien entendu, d’autres paramètres peuvent être inclus dans la demande de délégation IP_RESOURCE_DELEGATE, tels que par exemple, une durée de délégation souhaitée, etc.

En référence à la , la trame IP_RESOURCE_DELEGATE est reçue par CGN#2, par son module 9 de réception, via le canal COGITARE établi avec CGN#1 (étape F10).

Si CGN#2 accepte la demande de délégation de CGN#1 (réponse oui à l’étape test F20), il établit une liste « address-list » d’adresses IP comprenant au moins une adresse IP disponible, sélectionnée dans l’ensemble POOL#2 que CGN#2 gère et qu’il est prêt à déléguer à CGN#1 (étape F40). Il convient de noter que les adresses IP déléguées à CGN#1 sont destinées à être utilisées par celui-ci pour traiter des messages d’équipements clients qui lui sont rattachés ; elles ne doivent donc pas être utilisées pour traiter des messages échangés dans le cadre de connexions actives d’équipements clients servis par CGN#2, ni pour de futures connexions. En dehors de l’absence de trafic associé aux adresses IP de la liste « address-list », CGN#2 peut envisager d’autres critères pour sélectionner les adresses de l’ensemble POOL#2 qu’il accepte de déléguer à CGN#1 : il peut par exemple les sélectionner de façon aléatoire parmi les adresses non utilisées (c’est-à-dire qui ne sont pas actives) de l’ensemble POOL#2, ou sélectionner celles qui n’appartiennent pas à une « block-list », etc. CGN#2 peut en outre, pour établir la liste « address-list », tenir compte des préférences de CGN#1 indiquées le cas échéant dans sa demande de délégation (cf. paramètres « requested-size », « requested-nb », « requested-af », etc.). En variante, CGN#2 peut être configuré pour ignorer, lorsqu’il établit la liste « address-list », les préférences indiquées par CGN#1.

Dans le mode de réalisation décrit ici, comme détaillé davantage ultérieurement, après avoir délégué une adresse IP de l’ensemble POOL#2 à CGN#1, CGN#2 continue d’être impliqué dans la gestion du trafic destiné à ou émis en utilisant cette adresse IP. Plus particulièrement, il est configuré pour encapsuler, via son module 11 de transmission/réception, dans le canal COGITARE établi avec CGN#1, tous les paquets qu’il reçoit à destination de cette adresse IP déléguée pour les transmettre à CGN#1, et à l’inverse, désencapsuler les paquets utilisant cette adresse IP déléguée qu’il reçoit via le canal COGITARE établi avec CGN#1 pour les transmettre à leurs destinataires respectifs. Lors de ces opérations, CGN#2 est configuré pour ne pas effectuer de translation de l’adresse IP déléguée (contrairement à ce qu’il fait avec les adresses IP de l’ensemble POOL#2 dont l’usage lui est réservé, c’est-à-dire qui ne sont déléguées à aucun autre NAT opérateur). Ce mode de réalisation permet avantageusement d’éviter une mise à jour des tables de routage dans le réseau 2, puisque CGN#2 continue de gérer le trafic associé aux adresses IP qu’il délègue à d’autres NAT opérateur du système 1.

Une fois la liste « address-list » établie, CGN#2 mémorise dans une table nommée ici DELEG stockée par exemple dans sa mémoire non volatile NVM, les adresses IP de la liste « address-list » déléguées à CGN#1 en association avec un identifiant de CGN#1, par exemple son adresse IP @IP-CGN#1.

CGN#2 envoie ensuite, par le biais de son module 10 d’envoi et via le canal COGITARE établi avec CGN#1, une réponse favorable à la demande de délégation de CGN#1 incluant la liste « address-list » ainsi établie (étape F50). Dans le mode de réalisation décrit ici d’un canal COGITARE reposant sur le protocole QUIC, la réponse de CGN#2 est une trame IP_RESOURCE_DELEGATE incluant la liste « address-list ». Cette réponse peut inclure par ailleurs d’autres informations, comme par exemple un paramètre nommé ici « validity » indiquant la durée pendant laquelle les adresses IP de la liste « address-list » est déléguée à CGN#1, un paramètre nommé ici « rate-limit » représentatif du volume maximum de trafic associé à l’usage d’une adresse IP déléguée de la liste « address-list » que CGN#2 peut gérer (compte tenu du fait qu’il reste impliqué dans la gestion de ce trafic comme indiqué précédemment), etc.

La réponse IP_RESOURCE_DELEGATE de CGN#2 est reçue par CGN#1, et transmise à son module 5 d’exécution (étape E50-3). Le module 5 d’exécution enregistre alors dans une table CGN_PEERS, stockée par exemple dans la mémoire non volatile NVM, la ou les offres de délégation reçues des NAT opérateur au(x)quel(s) il a envoyé une demande de délégation à l’étape E50-2, autrement dit, dans l’exemple illustratif envisagé ici de CGN#2 (étape E50-4). Plus particulièrement, dans le mode de réalisation décrit ici, le module 5 d’exécution de CGN#1 mémorise dans la table CGN_PEERS, pour chaque NAT opérateur lui ayant délégué des adresses IP (c’est-à-dire dans l’exemple envisagé, pour CGN#2) :

• un identifiant du NAT opérateur (c’est-à-dire dans l’exemple envisagé, un identifiant de CGN#2) ;
• la liste des adresses déléguées par le NAT opérateur (c’est-à-dire dans l’exemple envisagé, la liste « address-list ») ;
• la durée de validité de la délégation d’adresses par le NAT opérateur (c’est-à-dire dans l’exemple envisagé, la durée indiquée par CGN#2 dans le paramètre « validity ») ; et
• le volume maximum de trafic associé aux adresses déléguées par le NAT opérateur pouvant être géré par celui-ci (c’est-à-dire dans l’exemple envisagé, le volume indiqué par CGN#2 dans le paramètre « rate-limit »).

Par souci de simplification ici, on suppose une même valeur de durée de validité et de volume maximum pour l’ensemble des adresses IP de la liste « address-list ». Toutefois, cette hypothèse n’est pas limitative en soi et on peut envisager des valeurs qui diffèrent en fonction des adresses IP déléguées.

Dès lors, CGN#1 est en mesure d’utiliser les adresses IP déléguées répertoriées dans la table CGN_PEERS en plus des adresses IP de l’ensemble POOL#1 (sauf celles retirées le cas échéant lors de l’exécution de l’action ACT1) pour traiter les paquets des équipements clients qu’il reçoit (étape E50-5). Ainsi, grâce à l’invention, on étendde factol’ensemble POOL#1 dont le CGN#1 bénéficie pour traiter les paquets qui lui parviennent.

Si les adresses IP déléguées à CGN#1 sont associées à une durée de validité limitée, alors CGN#1 est configuré localement pour utiliser ces adresses IP déléguées uniquement pendant une période de temps inférieure ou égale à cette durée de validité. Si CGN#1 a besoin d’utiliser une adresse IP déléguée au-delà de la durée de validité spécifiée par CGN#2, alors CGN#1 peut être configuré pour demander à CGN#2 une extension de cette durée de validité ou pour demander à un autre NAT opérateur du système 1 la délégation d’autres adresses IP et restituer le cas échéant la ou les adresses IP déléguée dont la durée de validité a expiré à CGN#2. On note que CGN#1 peut restituer une adresse IP déléguée par CGN#2 avant l’expiration de sa durée de validité, par exemple en envoyant une trame QUIC à CGN#2 introduite pour les besoins de l’invention appelée par exemple RELEASE_RESOURCES et incluant l’adresse IP déléguée en question.

Si aucune durée de validité n’est spécifiée, l’utilisation par CGN#1 d’une adresse IP déléguée peut être limitée à une période de temps définie par défaut (par exemple 24 heures), ou tant que CGN#1 a besoin de l’adresse IP déléguée en question (par exemple tant que le module 4 de détection associe un comportement malhonnête à l’adresse bad@IP), ou encore tant que CGN#1 n’est pas notifié de cesser cette utilisation (par exemple par CGN#2 ou par l’opérateur OP2 du réseau 2), etc.

Par ailleurs, comme mentionné précédemment, dans le mode de réalisation décrit ici, le trafic associé à une adresse IP déléguée à CGN#1 par CGN#2 continue de transiter par CGN#2 via le canal COGITARE établi entre les deux NAT opérateur. Il en résulte que CGN#1 est configuré pour envoyer à CGN#2, via son module 8 de transmission/réception, tous les paquets qu’il traite et pour lesquels il a sélectionné une adresse IP déléguée par CGN#2.

En outre, si un volume maximum de trafic pouvant être géré par CGN#2 a été indiqué à CGN#1 (typiquement via le paramètre « rate-limit »), CGN#1 est configuré préférentiellement pour respecter ce volume maximum, par exemple il peut être configuré pour distribuer le trafic associé à des équipements clients distincts sur plusieurs canaux COGITARE, et donc sélectionner pour ces équipements clients distincts des adresses IP déléguées par des NAT opérateur distincts du système 1. CGN#2 peut en outre être configuré pour écrêter le trafic associé aux adresses IP déléguées à CGN#1 au-delà du volume maximum indiqué, si ce volume maximum n’est pas respecté par CGN#1.

La illustre par un exemple ce qui vient d’être décrit, et plus particulièrement comment CGN#1 et CGN#2 traitent les paquets associés à une adresse IP déléguée par CGN#2 à CGN#1. Par souci de simplification, seuls les NAT opérateur CGN#1 et CGN#2 du système 1 sont représentés par la .

On suppose avec cette figure qu’après exécution de l’action ACT3, CGN#1 reçoit un paquet M1 d’un équipement client 14 auquel sont alloués une adresse IPv4 interne notée @IP14 et un numéro de port P14, par exemple @IP14=10.2.25.5 et P14=12345. Le paquet M1 véhicule des données émises par l’équipement client 14 et destinées à une entité destinataire, par exemple ici un serveur 15 identifié par une adresse IPv4 destinataire notée @IP15 et un numéro de port destinataire noté P15 ; par exemple @IP15=1.2.3.4, P15=9856.

Le paquet M1 émis par l’équipement client 14 est reçu par CGN#1 ; il est donc reçu par CGN#1 et l’entête du paquet contient l’adresse IP source et le numéro de port internes @IP14 et P14.

Sur réception du paquet M1, CGN#1 via son module 12 de gestion consulte la table BIB stockée dans sa mémoire non volatile NVM et détermine si une entrée correspondant au couple (@IP14,P14) existe déjà dans la table.

Si aucune entrée correspondante n’existe dans la table BIB, le module 12 de gestion sélectionne une adresse IP externe et, dans l’exemple envisagé ici, un numéro de port externe, notés respectivement @IP14ext et P14ext, pour traiter le paquet M1 en provenance de l’équipement client 14 (on note toutefois que le numéro de port P14 n’est pas nécessairement modifié par le module 12 de gestion). L’adresse IP @IP14ext est sélectionnée ici parmi les adresses IP déléguées par CGN#2 répertoriées dans la table CGN_PEERS. Une nouvelle entrée est alors créée par le module 12 de gestion dans la table BIB associant le couple (@IP14, P14) au couple (@IP14ext, P14ext). Par souci de simplification ici, on suppose que l’adresse @IP14ext est associée dans la table BIB uniquement à l’adresse IP interne @IP14.

Si une entrée qui correspond à ce paquet existe dans la table BIB, le module 12 de gestion extrait l’adresse IP et le numéro de port externes (@IP14ext, P14ext) renseignés pour cette entrée dans la table BIB.

Dans la suite, on considère à titre illustratif @IP14ext=25.25.65.2 et P14ext=4859.

CGN#1 translate ensuite l’adresse IP @IP14 et le numéro de port P14 internes du paquet M1 en l’adresse IP @IP14ext et le numéro de port P14ext externes (c’est-à-dire qu’il remplace dans l’entête du paquet @IP14 et P14 par @IP14ext et P14ext respectivement), résultant en un paquet modifié M1’. Il convient de noter que comme évoqué précédemment, d’autres modifications peuvent être apportées par CGN#1 au paquet M1. Toutefois par souci de simplification ici, de telles modifications ne sont pas décrites davantage ici.

Puis, dans le mode de réalisation décrit ici, il encapsule le paquet M1’ dans un paquet QUIC M2 (aussi couramment désigné par trame QUIC M2) ayant pour adresse IP source, l’adresse IP @IP-CGN#1 externe de CGN#1, par exemple @IP-CGN#1=11.12.13.14. Le numéro de port utilisé, noté P1, peut être un numéro de port choisi aléatoirement lors de l’établissement du canal COGITARE avec CGN#2, comme décrit par exemple dans le document RFC 6056 intitulé « Recommendations for Transport-Protocol Port Randomization », janvier 2011. Il convient de noter que dans l’exemple envisagé ici d’un canal de communication QUIC établi entre CGN#1 et CGN#2, c’est l’identifiant CID de la connexion établie entre les deux NAT opérateur qui est utilisé par ces derniers, et le numéro de port utilisé importe peu.

Comme l’adresse IP externe @IP14ext sélectionnée par CGN#1 pour traiter le paquet M1 est une adresse IP déléguée par CGN#2, CGN#1 transmet par l’intermédiaire de son module 8 de transmission/réception la trame M2 à CGN#2 via le canal COGITARE établi entre les deux NAT opérateur, pour que les données véhiculées par le paquet M1’ (ou de façon équivalente par le paquet M1) soient acheminées par CGN#2 vers leur destinataire, c’est-à-dire vers le serveur S. La trame M2 a donc dans son entête comme adresse IP destinataire, l’adresse IP externe @IP-CGN#2 du CGN#2.

Sur réception de la trame M2, CGN#2 vérifie, à l’aide de sa table DELEG, si l’adresse IP source (c’est-à-dire ici l’adresse @IP-CGN#1) correspond à une adresse IP de son ensemble POOL#2 déléguée à CGN#1, la trame M2 étant reçue via le canal COGITARE établi avec CGN#1.

Si ce n’est pas le cas (par exemple pas d’entrée dans la table DELEG correspondant à l’adresse IP source @IP-CGN#1 de la trame M2), CGN#2 supprime la trame M2.

Si c’est le cas, CGN#2 désencapsule le paquet M1’ de la trame M2 puis transmet le paquet M1’ vers son destinataire, c’est-à-dire vers le serveur S, sans effectuer de translation d’adresses sur le paquet M1’. Le paquet M1’ transmis vers le serveur S a donc, dans son entête :

• comme adresse IP et numéro de port sources : l’adresse IP externe @IP14ext=25.25.65.2 déléguée par CGN#2 à CGN#1 et le numéro de port externe P14ext=4859 ; et
• comme adresse IP et numéro de port destinataires : l’adresse IP @IP15=1.2.3.4 et le numéro de port @P15=9856.

On suppose maintenant que le serveur S répond à l’équipement client 14 en lui envoyant un paquet M3 contenant des données. Le paquet M3 est émis par le serveur S avec l’adresse IP source @IP15=1.2.3.4 et le numéro de port source @P15=9856. Les données sont destinées à l’équipement client 14 et donc à l’adresse IP externe @IP14ext=25.25.65.2 déléguée par CGN#2 à CGN#1 et au numéro de port externe P14ext=4859.

Le paquet M3 étant destiné à une adresse IP de l’ensemble POOL#2 géré par le CGN#2, il est, dans le mode de réalisation décrit ici, envoyé vers CGN#2.

Sur réception du paquet M3, CGN#2 vérifie si l’adresse IP destinataire du paquet M3 est une adresse IP de l’ensemble POOL#2 d’adresses IP qu’il gère et déléguée à un autre NAT opérateur du système 1. Il utilise à cet effet sa table DELEG.

S’il ne trouve aucune entrée correspondante pour @IP14ext dans la table DELEG, mais qu’il s’agit bien d’une adresse IP appartenant à l’ensemble POOL#2, CGN#2 traite le paquet M3 selon une procédure NAT44 conventionnelle, et translate l’adresse IP externe @IP14ext et le numéro de port externe P14ext en une adresse IP interne et un numéro de port interne si une entrée est active localement dans sa table BIB.

Si une entrée de la table DELEG est trouvée par CGN#2, alors il encapsule dans le mode de réalisation décrit ici le paquet M3 dans une trame QUIC M4 (paquet au sens de l’invention) sans modifier l’adresse IP destinataire (c’est-à-dire l’adresse @IP14ext) du paquet M3 encapsulé dans la trame M4, et donc incidemment sans modifier les données que le paquet M3 contient. Il transmet ensuite par l’intermédiaire de son module 11 de transmission/réception la trame M4 à CGN#1, via le canal COGITARE établi entre les deux NAT opérateur. La trame M4 contient le paquet M3 (en particulier les données émises par le serveur S et destinées à l’équipement client 14), et a dans son entête comme adresse IP source, l’adresse IP @IP-CGN#2 du CGN#2, et comme adresse IP destinataire, l’adresse IP @IP-CGN#1 du CGN#1. Par souci de simplification, on omet ici les numéros de port utilisés entre CGN#1 et CGN#2, pour les raisons évoquées précédemment.

Sur réception de la trame M4, CGN#1 vérifie que l’adresse IP source @IP-CGN#2 de la trame M4 correspond à une entrée de sa table CGN_PEERS. Si ce n’est pas le cas, la trame M4 est supprimée.

Si l’adresse IP source @IP-CGN#2 de la trame M4 correspond à une entrée de la table CGN_PEERS, CGN#1 extrait le paquet M3 de la trame M4. Puis il vérifie dans sa table BIB si une entrée correspondant à l’adresse IP destinataire du paquet M3 (c’est-à-dire ici à l’adresse IP externe @IP14ext) existe.

Si aucune entrée n’existe dans la table BIB pour cette adresse IP, CGN#1 supprime le paquet M3.

Si une entrée existe (c’est-à-dire que cette adresse IP a été précédemment sélectionnée par CGN#1 pour traiter les messages d’un équipement client ou qu’une entrée dans la table BIB a été explicitement créée en utilisant une interface dédiée), il remplace dans le paquet M3 l’adresse @IP14ext et le numéro de port P14ext destinataires par l’adresse IP et le numéro de port internes qui leur sont associés dans la table BIB, en l’occurrence ici par l’adresse IP interne @IP14 et par le numéro de port interne P14 de l’équipement client 14.

Puis le paquet M3 ainsi modifié désigné dans la suite par M3’ est transmis à l’équipement client 14 par CGN#1.

Il convient de noter que ce qui vient d’être décrit pour des canaux COGITARE reposant sur le protocole QUIC peut être appliqué à l’identique à des canaux COGITARE reposant sur un autre protocole, dès lors que l’encapsulation des paquets M1’ et M3 est réalisée dans des messages conformes à cet autre protocole. Par exemple pour le protocole IP-in-IP, il convient d’encapsuler les paquets M1’ et M3 dans des paquets IP au lieu de les encapsuler dans des trames QUIC.

Dans l’exemple de la , les équipements clients du réseau 2 sont des terminaux communiquant directement avec les NAT opérateur du système 1. Comme évoqué précédemment, on peut envisager d’appliquer l’invention à d’autres types d’équipements clients du réseau 2 et notamment à des équipements d’accès au réseau 2 tels que des CPE reliant par exemple des terminaux connectés à un réseau local (LAN) au réseau 2. Dans ce cas, l’invention est appliquée de façon identique à ce qui vient d’être décrit pour un équipement client de type terminal au niveau d’un CPE. Toutefois, comme évoqué précédemment, il existe une étape de translation d’adresses supplémentaire au niveau du CPE, connue en soi.

La illustre cette étape supplémentaire. Plus précisément, l’équipement client 14 de la est maintenant un CPE (au lieu d’un terminal tel qu’indiqué dans la ), utilisé comme équipement d’accès au réseau 2 par un terminal 16 connecté à un LAN. L’invention est appliquée par les CGN#1 et CGN#2 de façon identique à ce qui a été décrit en référence à la pour le terminal 14. Dans la , le paquet M1 résulte toutefois d’une modification par le CPE 14 d’un paquet M1_0 émis par le terminal 16 contenant des données destinées au serveur S, ce paquet M1_0 ayant pour adresse IP et numéro de port sources, une adresse IP et un numéro de port internes notées respectivement @IP16 et P16, alloués par le CPE 14 au terminal 16. La modification effectuée par le CPE 14 sur le paquet M1_0, résultant en le paquet M1, consiste à remplacer dans l’entête du paquet M1_0 l’adresse IP @IP16 et le numéro de port P16 internes par l’adresse IP @IP14 et le numéro de port P14 alloués au CPE 14. La modification inverse est appliquée par le CPE 14 au paquet M3’ résultant en un paquet M3’’ alors envoyé au terminal 16.

Tout ce qui vient d’être décrit en référence aux figures 2 à 9 pour les NAT opérateur CGN#1 et CGN#2 peut s’appliquer de façon similaire ou identique aux autres NAT opérateur du système 1. En outre, le NAT opérateur CGN#1 peut obtenir des adresses IP déléguées par plusieurs NAT opérateur du système 1. Ce qui vient d’être décrit pour CGN#2 s’applique alors de façon similaire ou identique aux différents NAT opérateur délégant des adresses IP à CGN#1.

Dans le mode de réalisation décrit en référence aux figures 2 à 9, le système 1 est configuré de sorte que lorsqu’un NAT opérateur CGN#j du système 1 délègue une ou plusieurs adresses IP à un NAT opérateur CGN#k, avec k≠j, CGN#j continue de recevoir le trafic associé à ces adresses IP déléguées. En d’autres termes, les tables de routage maintenues par les routeurs du réseau 2 ne sont pas modifiées, ce qui permet à CGN#k d’utiliser sans délai les adresses IP qui lui ont été déléguées, et ce de façon transparente pour les équipements clients qu’il sert. Dans un autre mode de réalisation, on peut envisager que suite à la délégation d’adresses IP par CGN#j à CGN#k, les tables de routage soient modifiées de sorte que le trafic associé à ces adresses IP déléguées (entrant et sortant) soit acheminé directement vers CGN#j (sans transiter par le canal COGITARE établi entre CGN#j et CGN#k), le temps de la délégation.

Dans le mode de réalisation décrit en référence aux figures 2 à 9, on a fait l’hypothèse qu’un unique niveau de NAT opérateur est déployé dans le réseau. L’invention s’applique toutefois également dans un contexte où plusieurs niveaux (ou étages) de NAT opérateur sont déployés dans le réseau 2 (induisant plusieurs translations d’adresses successives appliquées aux messages transitant par le réseau). Dans un tel contexte, la délégation d’adresses IP est réalisée conformément à l’invention, de façon identique à ce qui vient d’être décrit, entre NAT opérateur appartenant à un même niveau.

La illustre un exemple de réseau 2’ comprenant deux niveaux de NAT opérateurs LEV1 et LEV2, le niveau LEV1 comprenant I NAT opérateur CGN1#m, m=1,..,I, formant un système 1-1 conforme à l’invention et le niveau LEV2 comprenant J NAT opérateur CGN2#k, k=1,…,J, formant un système 1-2 conforme à l’invention, I et J désignant des entiers supérieurs à 1. Dans chaque niveau LEVi, i=1,2, chaque NAT opérateur du système 1-i comprend les modules fonctionnels 4 à 13 précédemment décrits et est susceptible d’agir, selon le contexte, comme un premier dispositif ou un deuxième dispositif selon l’invention. Les procédés de gestion et de collaboration selon l’invention qui viennent d’être décrits en référence aux NAT opérateurs CGN#n, n=1,…,M, des figures 2 à 9 s’appliquent donc de façon similaire ou identique au sein de chaque niveau LEVi et plus particulièrement de chaque système 1-i conforme à l’invention, i=1,2, entre les NAT opérateurs de ce système. Autrement dit, chaque NAT opérateur CGNi#p du système 1-i déployé au niveau LEVi est susceptible de demander une délégation d’adresses IP ou de déléguer une ou plusieurs adresses IP à un ou plusieurs NAT opérateur CGNi#t, avec t≠p, appartenant au même système 1-i et donc au même niveau LEVi que lui. Des canaux COGITARE (représentés par des doubles flèches dans la ) peuvent ainsi être établis entre NAT opérateur d’un même niveau.

La illustre différentes situations expérimentées par les systèmes 1-1 et 1-2 dans le réseau 2’.

Plus précisément, la figure 10a illustre l’état du réseau 2’ et des systèmes 1-1 et 1-2 dans un état normal (conditions nominales). Chaque NAT opérateur au sein d’un système 1-i, i=1,2 gère un ensemble d’adresses IP distinctes et utilisent les adresses qu’il gère pour traiter les paquets des équipements clients qu’il sert (CPE ou terminaux dans l’exemple de la ). Chaque paquet d’un équipement client (émis ou destiné à ce dernier) transite successivement dans le réseau 2’ par deux NAT opérateur appartenant respectivement au niveau LEV1 et au niveau LEV2. Chaque NAT opérateur sélectionne pour traiter ce paquet une adresse IP dans l’espace POOL d’adresses IP qui lui a été affecté. Ainsi à titre illustratif dans la figure 10a, un message associé à un terminal 17 transite par le NAT opérateur CGN1#1 dans le système 1-1 et par le NAT opérateur CGN2#2 dans le système 1-2.

La figure 10b illustre une situation dans laquelle le module 4 de détection d’un CGN1#m du système 1-1, par exemple CGN1#1, détecte un comportement malveillant associé à une adresse qu’il gère et envoie via son module 5 d’exécution, en réponse à ce comportement malveillant, une demande de délégation d’au moins une adresse IP à un autre NAT opérateur du système 1-1, par exemple à CGN1#2. Dans l’exemple de la figure 10b, suite à la délégation d’au moins une adresse IP par CGN1#2 à CGN1#1, CGN1#1 sélectionne une des adresses IP déléguées par CGN1#2 pour traiter les paquets associés au terminal 17. Ces messages, lorsqu’ils contiennent des données émises par le terminal 17 et destinées à un serveur 18, transitent par CGN1#1 qui remplace leur adresse IP interne par une adresse IP déléguée par CGN1#2 (ou inversement), puis les envoie via le canal COGITARE à CGN1#2 pour qu’ils soient envoyés vers le serveur 18. Conformément aux règles de routage établies dans le réseau 2, les paquets sont transmis par CGN1#2 à un NAT opérateur du système 1-2 déployé au niveau LEV2 (CGN1#2 n’effectuant alors aucune translation d’adresses pour les paquets en question), par exemple à CGN2#2, en charge d’appliquer aux paquets reçus de CGN1#2 une nouvelle étape de translation d’adresses avant qu’ils ne soient acheminés jusqu’au serveur 18. Les paquets émis par le serveur 18 contenant des données destinées au terminal 17 suivent le chemin inverse : ils transitent par CGN2#2 qui effectue une translation d’adresses, puis sont envoyés par CGN2#2 à CGN1#2 qui les transmet à son tour, dans le canal COGITARE, à CGN1#1 sans effectuer de translation d’adresses. CGN1#1, après avoir remplacé l’adresse IP externe déléguée utilisée pour les paquets par une adresse IP interne allouée au terminal 17, envoie ces paquets au terminal 17.

La figure 10c illustre une situation dans laquelle, dans chaque système 1-i déployé à chaque niveau LEVi, un comportement malveillant associé à une adresse IP gérée par un NAT opérateur du système 1-i est détecté, déclenchant une demande de délégation d’adresses IP et une délégation d’adresses IP à chaque niveau. Dans l’exemple illustré par la figure 10c, un comportement malveillant associé à une adresse IP gérée par le NAT opérateur CGN1#I du système 1-1 et un comportement malveillant associé à une adresse IP gérée par le NAT opérateur CGN2#2 du système 1-2 sont détectés, résultant en une délégation d’adresses IP par CGN1#1 à CGN1#I et en une délégation d’adresses IP par CGN2#J à CGN2#2.

Bien entendu, l’invention ne se limite pas à deux niveaux de NAT opérateur déployés dans le réseau, un nombre plus important de niveaux de NAT peut être envisagé, l’invention s’appliquant de la même façon que ce qui a été décrit précédemment en référence aux figures 2 à 9 indépendamment à chaque niveau.

Enfin, l’invention a été décrite en référence à des NAT opérateur. Toutefois, l’invention peut s’appliquer à d’autres dispositifs gérant une pluralité d’adresses IP susceptibles d’être partagées entre plusieurs équipements clients, comme par exemple à des dispositifs mettant en œuvre une fonction proxy utilisant ses propres adresses IP pour relayer des messages reçus. De tels dispositifs sont par exemple décrits dans les sections 5, 6 et 7 du document RFC 7620 évoqué précédemment. L’invention s’applique aussi lorsque les adresses IP gérées par les premier et/ou deuxième dispositifs ne sont pas partagées entre plusieurs équipements clients.

Claims (18)

1. Procédé de gestion, par un premier dispositif (CGN#1 ; CGN1#1 ; CGN1#I, CGN2#2) localisé dans un réseau (2,2’), d’un premier ensemble d’adresses IP, ledit procédé comprenant :

   • une étape (E30) de détection d’un comportement suspect associé à une adresse IP (bad@IP) dudit premier ensemble sélectionnée par le premier dispositif pour traiter au moins un paquet de données d’un équipement client (14,17) servi par le premier dispositif ;
   • une étape (E50) d’exécution, suite à ladite détection, d’au moins une action parmi :
     • un ajustement (ACT2) d’au moins un taux de partage d’au moins une adresse IP du premier ensemble appliqué par le premier dispositif ;
     • une demande (ACT3), adressée à au moins un deuxième dispositif (CGN#2 ; CGN1#2 ; CGN1#1, CGN2#J) gérant un deuxième ensemble d’adresses IP, de délégation d’au moins une adresse IP du deuxième ensemble au premier dispositif pour que le premier dispositif puisse sélectionner ladite au moins une adresse IP déléguée pour traiter au moins un paquet de données d’au moins un équipement client servi par le premier dispositif.
2. Procédé de gestion selon la revendication 1 dans lequel l’étape (E30) de détection comprend la réception d’une notification d’une fonction de détection d’attaques (DMS) ou d’un système (REP_SYS) de réputation d’adresses IP.
3. Procédé de gestion selon la revendication 1 ou 2 comprenant en outre une étape (E10) de découverte dudit au moins un deuxième dispositif.
4. Procédé de gestion selon l’une quelconque des revendications 1 à 3 comprenant en outre une étape (E20) d’établissement avec ledit au moins un deuxième dispositif d’au moins un canal de communication.
5. Procédé de gestion selon la revendication 4 dans lequel ledit au moins un canal de communication est un canal de communication chiffré reposant sur le protocole QUIC.
6. Procédé de gestion selon l’une des revendications 1 à 5 dans lequel ladite demande de délégation comprend un nombre et/ou un type d’adresses IP déléguées souhaités.
7. Procédé de gestion selon l’une des revendications 1 à 6 comprenant en outre une étape (E50-3) de réception, en réponse à une dite demande de délégation adressée par le premier dispositif à un dit deuxième dispositif, au moins un élément parmi :

   • une liste comprenant au moins une adresse IP déléguée par ce deuxième dispositif au premier dispositif ;
   • une durée pendant laquelle ladite liste est déléguée au premier dispositif ;
   • une information représentative d’un volume maximum de trafic associé à l’usage d’une adresse IP déléguée par ledit deuxième dispositif au premier dispositif pouvant être géré par le deuxième dispositif.
8. Procédé de gestion selon l’une quelconque des revendications 1 à 7 comprenant en outre :

   • une étape de réception, depuis une adresse IP source interne (@IP14), d’un premier paquet de données (M1) comprenant des données destinées à une entité destinataire (15) ;
   • une étape de remplacement de ladite adresse IP source interne (@IP14) par une dite adresse IP déléguée (@IP14ext) par un dit deuxième dispositif (CGN#2) au premier dispositif (CGN#1) et sélectionnée par le premier dispositif pour traiter ledit premier paquet de données (M1) ; et
   • une étape de transmission desdites données (M1’) avec ladite adresse IP déléguée (@IP14ext) audit deuxième dispositif (CGN#2), via un canal de communication établi avec lui, pour que lesdites données soient acheminées vers l’entité destinataire (15).
9. Procédé de gestion selon l’une quelconque des revendications 1 à 8 comprenant en outre :

   • une étape de réception, via un canal de communication établi avec un dit deuxième dispositif (CGN#2), d’un deuxième paquet de données (M3) émis par une entité émettrice (15) et comprenant des données destinées à une adresse IP (@IP14ext) du deuxième ensemble d’adresses IP géré par le deuxième dispositif (CGN#2) ;
   • si ladite adresse IP (@IP14ext) est déléguée au premier dispositif (CGN#1) par le deuxième dispositif et sélectionnée par le premier dispositif pour traiter des paquets de données d’un équipement client (14) servi par le premier dispositif, une étape de transmission desdites données vers une adresse IP interne (@IP14) allouée audit équipement client.
10. Procédé de gestion selon l’une quelconque des revendications 1 à 9 comprenant une étape de sélection d’au moins deux adresses IP déléguées par desdits deuxièmes dispositifs distincts pour traiter des paquets de données d’au moins deux équipements clients distincts
11. Procédé de gestion selon la revendication 3 ou 4 dans lequel l’étape (E10) de découverte et/ou l’étape (E20) d’établissement dudit canal de communication est mise en œuvre avant l’étape (E30) de détection.
12. Procédé de collaboration avec un premier dispositif (CGN#1 ; CGN1#2 ; CGN1#I, CGN2#2) localisé dans un réseau (2) et gérant un premier ensemble d’adresses IP comprenant une adresse IP (bad@IP) associée à un comportement suspect, ledit procédé étant destiné à être mis en œuvre par un deuxième dispositif (CGN#2 ; CGN1#2 ; CGN1#1, CGN2#J) gérant un deuxième ensemble d’adresses IP et comprenant :

    • une étape (F10) de réception, en provenance du premier dispositif, d’une demande de délégation d’au moins une adresse IP du deuxième ensemble au premier dispositif pour que le premier dispositif puisse sélectionner ladite au moins une adresse IP déléguée pour traiter au moins un paquet de données d’au moins un équipement client servi par le premier dispositif ; et
    • une étape (F50) d’envoi au premier dispositif d’une liste comprenant au moins une adresse IP du deuxième ensemble déléguée par ledit deuxième dispositif au premier dispositif.
13. Procédé de collaboration selon la revendication 12 comprenant en outre :

    • une étape de réception, via un canal de communication établi avec le premier dispositif, d’un premier paquets de données (M2) comprenant des données destinées à une entité destinataire (15) et émis avec une adresse IP source (@IP14ext) appartenant au deuxième ensemble d’adresses IP géré par le deuxième dispositif (CGN#2) ;
    • si ladite adresse IP source (@IP14ext) est une dite adresse IP déléguée par le deuxième dispositif au premier dispositif, une étape de transmission desdites données vers l’entité destinataire (15) sans modifier ladite adresse IP source (@IP14ext) desdites données.
14. Procédé de collaboration selon la revendication 12 ou 13 comprenant en outre :

    • une étape de réception d’un deuxième paquet de données (M3) comprenant des données émises par une entité émettrice (15) et destinées à une adresse IP destinataire (@IP14ext) appartenant au deuxième ensemble d’adresses IP géré par le deuxième dispositif (CGN#2) ;
    • si ladite adresse IP (@IP14ext) est une dite adresse IP déléguée par le deuxième dispositif au premier dispositif, une étape de transmission desdites données au premier dispositif via un canal de communication établi avec ledit premier dispositif sans modifier ladite adresse IP destinataire (@IP14ext) desdites données.
15. Programme d’ordinateur (PROG1, PROG2) comportant des instructions pour la mise en œuvre d’un procédé de gestion ou d’un procédé de collaboration selon l’une quelconque des revendications 1 à 14 lorsque ledit programme est exécuté par un ordinateur (3).
16. Dispositif, dit premier dispositif (CGN#1), localisé dans un réseau (2), ledit premier dispositif gérant un premier ensemble d’adresses IP et comprenant :

    • un module (4) de détection, configuré pour détecter un comportement suspect associé à une adresse IP dudit premier ensemble sélectionnée par le premier dispositif pour traiter au moins un paquet de données d’un équipement client servi par le premier dispositif ;
    • un module (5) d’exécution configuré pour exécuter, suite à ladite détection, au moins une action parmi :
      • un ajustement d’au moins un taux de partage d’au moins une adresse IP du premier ensemble appliqué par le premier dispositif ;
      • une demande, adressée à au moins un deuxième dispositif gérant un deuxième ensemble d’adresses IP, de délégation d’au moins une adresse IP du deuxième ensemble au premier dispositif pour que le premier dispositif puisse sélectionner ladite au moins une adresse IP déléguée pour traiter au moins un paquet de données d’au moins un équipement client servi par le premier dispositif.
17. Dispositif, dit deuxième dispositif (CGN#2), localisé dans un réseau (2), ledit deuxième dispositif gérant un deuxième ensemble d’adresses IP et comprenant :

    • un module (9) de réception, configuré pour recevoir, en provenance d’un premier dispositif gérant un premier ensemble d’adresses IP comprenant une adresse IP associée à un comportement suspect, une demande de délégation d’au moins une adresse IP du deuxième ensemble au premier dispositif pour que le premier dispositif puisse sélectionner ladite au moins une adresse IP déléguée pour traiter au moins un paquet de données d’au moins un équipement client servi par le premier dispositif ; et
    • un module (10) d’envoi, configuré pour envoyer au premier dispositif, une liste comprenant au moins une adresse IP du deuxième ensemble déléguée par ledit deuxième dispositif au premier dispositif.
18. Système (1, 1-1, 1-2) comprenant :

    • au moins un premier dispositif (CGN#1, CGN1#1, CGN1#I, CGN2#2) selon la revendication 16 ; et
    • au moins un deuxième dispositif (CGN#2, CGN1#2, CGN1#1, CGN2#J) selon la revendication 17, configuré pour traiter au moins une demande de délégation d’adresses IP reçue d’un dit premier dispositif.