INPI-France/Brevets-Francais-2024-Chunked huggingface dataset:
Dans le mode de réalisation décrit ici, le module 3C de fourniture du serveur DNS 3-1 fournit deux autres éléments dans la pluralité d’éléments AD ASTRA-ELTS insérée dans l’option EAO de la réponse REP-DNS, à savoir : un paramètre « AID », dans lequel le module 3C de fourniture du serveur DNS 3-1 renseigne un identifiant du nœud relais 4-1 dont l’adresse figure dans le paramètre « relay-locators », et qu’il a sélectionné pour le nom de domaine « service-s.com » et le serveur destinataire 5. Si plusieurs nœuds relais sont sélectionnés, le paramètre « AID » comprend les identifiants de chacun des nœuds relais sélectionnés. Comme indiqué précédemment, aucune limitation n’est attachée à la forme de l’identifiant en question : il peut s’agir d’un alias, d’un nombre, d’un nom de domaine, d’un condensé (ou « hash » en anglais), etc. ; un paramètre « partial-offload » : si le dispositif client 2 a indiqué dans le paramètre « partial-offload » de l’option EAO de la requête REQ-DNS, le support de la fonction partial-offload, le serveur DNS 3-1 indique dans le paramètre « partial-offload » de l’option EAO de sa réponse REQ-DNS si le nœud relais qu’il a sélectionné (nœud relais 4-1) peut prendre en charge les échanges DNS ultérieurs du dispositif client 2 corrélés à la requête REQ-DNS (c’est-à-dire les « deuxièmes » requêtes au sens de l’invention), autrement dit s’il supporte la fonction partial-offload. Le module 3C de fourniture peut de façon optionnelle ajouter dans le paramètre « partial-offload » une indication supplémentaire identifiant les requêtes DNS concernées par la fonction partial-offload (par exemple, les requêtes portant sur un sous-domaine particulier ou tout autre filtre tel que l’origine des ressources DNS (noms de domaine (par ex. « service.example.com », service (SRV, par ex. "service._tcp.example.com"), etc.) à soumettre au système DNS). A titre illustratif, dans l’exemple envisagé ici d’une requête REQ-DNS portant sur le nom de domaine « service-s.com », le support de la fonction « partial-offload » par le nœud relais 4-1 indique au dispositif client 2 qu’il peut envoyer toutes ses requêtes ultérieures portant sur un sous-domaine « *.service-s.com » vers le nœud relais 4-1. Il convient de noter que le support de la fonction partial-offload par le nœud relais 4-1 n’implique pas nécessairement que les requêtes DNS ultérieures envoyées par le dispositif client 2 soient traitées (c’est-à-dire résolues) directement par le nœud relais 4-1. Celui-ci peut en effet être configuré pour adresser ces requêtes à un autre serveur DNS de confiance capable de les résoudre.
Les différents éléments indiqués par le serveur DNS 3-1 dans les paramètres « relay-locators », « AID » et « partial-offload » constituent comme évoqué précédemment une pluralité d’éléments AD ASTRA-ELTS fournie par le module 3C de fourniture du serveur DNS 3-1 au dispositif client 2. Dans le mode de réalisation décrit ici, cette pluralité d’éléments est fournie dans la réponse REP-DNS à la requête REQ-DNS, dans une option EAO. En variante, tout ou partie de cette pluralité d’éléments peut être fournie dans un ou plusieurs options ou messages distincts de la réponse REP-DNS.
La réponse REP-DNS incluant l’option EAO est ensuite envoyée par le module 3D d’envoi du serveur DNS 3-1 au dispositif client 2 (étape F90).
En référence à la de nouveau, le dispositif client 2, et plus particulièrement son module 2B de réception, reçoit la réponse REP-DNS élaborée par le serveur DNS 3-1 à sa requête REQ-DNS (étape E20).
Le dispositif client 2 extrait de l’option EAO la pluralité d’éléments AD ASTRA-ELTS présents dans la réponse REP-DNS, et plus particulièrement les éléments compris dans les paramètres « relay-locators », « padding », « AID » et « partial-offload » de l’option (étape E30). Pour rappel, l’utilisation d’un transport DNS chiffré pour transmettre ces paramètres garantit avantageusement l’authenticité et l’intégrité des messages véhiculant ces paramètres, et donc incidemment, des paramètres reçus par le dispositif client 2.
L’identifiant AID est enregistré par le module 2B de réception dans un cache local du client DNS CL du dispositif client 2, en association avec la ressource IP correspondante, à savoir ici le nom de domaine « service-s.com ». Si une entrée est déjà présente dans le cache pour cette même ressource, le client DNS CL remplace son contenu par le nouvel AID renseigné dans la réponse REP-DNS. Lors de l’envoi de requêtes DNS ultérieures corrélées à la requête REQ-DNS, le client DNS CL renseigne le paramètre « AID » de l’option EAO de ces requêtes DNS ultérieures avec le contenu courant du cache local.
Si le dispositif client 2 supporte la fonction partial-offload (comme c’est le cas dans l’exemple envisagé ici), le module 2B de réception enregistre également dans le cache local du client DNS CL les informations transmises dans le paramètre « partial-offload », à savoir que tout ou partie des nœuds relais indiqués dans le paramètre « relay-locators » peuvent être utilisés pour des requêtes DNS ultérieures corrélées à la première requête REQ-DNS ainsi que, le cas échéant, les indications supplémentaires fournies par le serveur DNS 3-1 et identifiant les requêtes DNS ultérieures concernées (étape E50). Il convient de noter que dans le mode de réalisation décrit ici, le paramètre « partial-offload » est renseigné par le serveur DNS 3-1 dans l’option EAO de la réponse REQ-DNS uniquement si le dispositif client 2 supporte la fonction partial-offload et l’a notifié au serveur DNS 3-1 en valorisant le paramètre « partial-offload » de la requête REQ-DNS à 1.
L’instruction de brouillage INST comprise dans le paramètre « padding » (instruction de bourrage des messages ici) est transmise par le module 2B de réception à l’application APP du dispositif client 2 à l’origine de la requête REQ-DNS de résolution du nom de domaine « service-s.com », afin qu’elle puisse exécuter (c’est-à-dire appliquer) cette instruction avant d’envoyer des messages destinés au serveur destinataire 5 au nœud relais 4-1 indiqué dans le paramètre « relay-locators » (étape E60). A cet effet, l’application APP comprend un module 2C d’exécution selon l’invention. Il convient de noter que l’ensemble des modules 2A à 2D du dispositif client 2 peuvent être hébergés dans l’application APP.
Comme illustré schématiquement par la , les messages destinés au serveur destinataire 5 contiennent des données utiles DATA échangées par l’application APP avec le serveur destinataire 5 lors de l’accès au service S. Comme évoqué succinctement précédemment, ces données sont chiffrées au moyen d’un premier mécanisme de chiffrement ENC1 selon les besoins du service S offert par le serveur destinataire 5, et consignées dans des paquets de données intérieurs notés I-PKT (« inner packets » en anglais). Chaque paquet de données intérieur I-PKT est destiné au serveur destinataire 5, c’est-à-dire qu’il a comme adresse de destination (contenue dans un entête du paquet IP I-PKT référencé par DEST dans la ), l’adresse IP @IP5 du serveur destinataire 5 et le numéro de port P5 du serveur destinataire 5. Ce numéro de port est par exemple ici un numéro de port défini par défaut (en variante il peut avoir été obtenu lors de la résolution du nom de domaine associé au serveur destinataire 5, de façon connue en soi). Le paquet de données intérieur I-PKT constitue un paquet de données destinées au serveur destinataire au sens de l’invention. L’application APP applique alors, par le biais de son module 2C d’exécution, l’instruction de brouillage INST consignée dans les éléments AD ASTRA-ELTS, à chaque paquet de données intérieur I-PKT contenant des données destinées au serveur destinataire 5 (étape E60). Comme évoqué précédemment et illustré dans la , dans le mode de réalisation décrit ici, l’instruction de brouillage INST est une instruction de bourrage comprenant au moins un motif PATT de bourrage ou une technique de génération d’un tel motif PATT. Il en résulte que l’application APP ajoute des bits ou symboles de bourrage conformément au(x) motif(s) PATT de bourrage indiqué(s) dans l’instruction de bourrage INST ou généré(s) par le module 2C d’exécution en appliquant la technique de génération indiquée dans l’instruction de bourrage INST. L’application APP obtient ainsi un paquet de données B-PKT dit brouillé, constitué du paquet de données intérieur I-PKT complété par les bits ou symboles de bourrage du ou des motifs PATT de bourrage appliqué.
A l’instant T1, illustré en , un autre point de sortie (CE) est sélectionné. La connexion applicative est alors associée à une connexion de référence établie entre le CEk et le concentrateur 23. Les données transitent alors par l’équipement d’accès CEk et le réseau externe Net. #j.
On note qu’en cas de redirection de trafic vers un autre point de sortie, la continuité de la connexion applicative établie entre le terminal H2 et le serveur S peut être préservée par la présence du même concentrateur 23 dans les différentes sous-connexions ou chemins empruntés par les données qui transitent par ce même concentrateur.
Dans un mode de réalisation particulier, la sélection d’un CE parmi plusieurs CE connectés au réseau local tient également compte d’un identifiant associé aux données applicatives échangées entre le terminal et le serveur.
Selon un premier exemple, un tel identifiant est un identifiant d’application, par exemple « app-id ». L’identifiant « app-id » peut notamment être utilisé par un terminal pour l’acheminement de paquets caractéristiques d’applications spécifiques, également appelé données applicatives. A titre d’exemple, les applications ayant les mêmes contraintes de QoE peuvent être identifiées par un même identifiant d’application. Par exemple, une application peut communiquer son identifiant (« app-id ») via une API réseau locale pour indiquer à un processus de routage/acheminement (« routing/forwarding », en anglais) embarqué dans un CE la route « applicative » à utiliser pour acheminer les données de cette application au sein du réseau local. Par exemple, les messages d’annonce de routes contiennent un identifiant d’application qui permet de maintenir dans le réseau local des routes spécifiques par application. Ce faisant, un réseau local peut alors maintenir des routes différenciées par application, et donc, des CE distincts peuvent être choisis pour acheminer le trafic vers une même destination pour une application donnée.
Selon d’autres exemples, d’autres identifiants peuvent être utilisés pour sélectionner une route plutôt qu’une autre : par exemple, un même codage DSCP (« DiffServ Code Point ») peut conduire à sélectionner des routes pour le trafic marqué EF (« Expedited Forwarding ») et d’autres routes pour le trafic marqué AF (« Assured Forwarding »), sans préjuger de la nature de la ou des applications qui bénéficieront de ce traitement différencié. Dans ce cas, un identifiant « dscp-val » peut être associé aux routes annoncées entre CE dans les messages échangés entre eux via un canal dédié.
A titre d’exemple, la illustre la sélection d’un point de sortie (CE1 ou CEk, pour un trafic en provenance du LAN et à destination d’un réseau externe) en fonction de l’application (« app-id ») et des paramètres de QoE observés et échangés entre les CE d’un même site (Site #i). Des routes distinctes sont utilisées pour acheminer le trafic en fonction des contraintes applicatives et des conditions observées par les différents points de sortie (CE) connectés à un même réseau local. Par exemple une première route via l’équipement d’accès CE1 est privilégiée pour les applications identifiées par l’identifiant app-id=1 et une deuxième route via l’équipement d’accès CEk est privilégiée pour les applications identifiées par l’identifiant app-id=2.
On note que dans ce mode de réalisation mettant en œuvre plusieurs CE, afin d’éviter des instructions contradictoires entre différents CE d’un même site (c’est-à-dire connectés au même réseau local), un CE doit informer les autres CE avant de modifier la route.
On a décrit ci-dessus un premier exemple selon lequel le canal dédié peut être de type « point-à-multipoint ».
La illustre un deuxième exemple selon lequel le canal dédié au partage des informations entre CE est un canal « point-à-point ».
Selon cet exemple, au moins un équipement d’accès connecté au réseau local et permettant d’établir une connexion de référence avec le serveur distant S ou le concentrateur 23 transmet à un contrôleur 61 des informations relatives à au moins un des réseaux externes auquel il est connecté. De telles informations peuvent notamment être utilisées pour sélectionner l’un des CE connectés au réseau local pour acheminer des données applicatives entre le terminal et le serveur.
Un exemple d’établissement d’un tel canal point-à-point consiste à établir une connexion (de contrôle) entre un CE et un ou plusieurs contrôleurs exploités par une entreprise par exemple.
Un tel contrôleur 61 (contrôleur SDN par exemple) peut être local à chaque site. De cette façon, il est possible de préserver l’étanchéité des communications entre les différents sites. En effet, les décisions (politiques de routage, redirection de trafic, gestion des CE du site, etc.) prises par un tel contrôleur sont locales au site. De fait, ces décisions n’interfèrent pas avec celles prises par les autres contrôleurs déployés sur les autres sites. Une telle ingénierie permet également de ne pas dépendre de la connectivité entre les sites, ce qui contribue à renforcer la robustesse et la capacité à appliquer les décisions prises par le contrôleur, sans induire de délai supplémentaire ni compromettre la bonne application des décisions, notamment lorsque celles-ci doivent être prises en réaction à de nouvelles conditions de qualité de service ou de QoE observées sur le site considéré.
Alternativement, un seul contrôleur peut être utilisé pour gérer les différents sites où plusieurs CE sont déployés. Dans ce cas, le contrôleur peut associer un CE à son site de déploiement. Cette information peut être configurée dans le contrôleur par un administrateur ou être récupérée depuis chaque CE en utilisant un protocole tel que NETCONF, par exemple.
Quelle que soit l’ingénierie retenue (un contrôleur par site ou un contrôleur pour tous les sites), le contrôleur utilise les informations reçues de la part des différents CE pour décider de la politique locale de sélection des point(s) de sortie au sein du réseau local pour acheminer le trafic vers une destination donnée, pour toutes les destinations ou pour un sous-ensemble de destinations, en tenant compte de plusieurs critères tels que les conditions de qualité de service ou de QoE, la nature du trafic, les différents profils de trafic, les politiques de priorisation de trafic, etc.
Comme décrit précédemment en relation avec la , le contrôleur peut notamment configurer les CE avec des routes spécifiques à un groupe d’applications ayant des contraintes de qualité de service ou de QoE similaires. Par exemple, l’identifiant « app-id » peut être utilisé pour démultiplexer les routes et pourvoir choisir des points de sortie (CE, pour un trafic en provenance du LAN et à destination d’un réseau externe) par application. Le contrôleur peut également être responsable de l’établissement du ou des canaux dédiés au partage des informations entre CE : l’échange des informations entre CE via un tel canal point-à-point peut également impliquer le contrôleur lui-même, car les informations recueillies peuvent servir de données d’entrée pour le calcul des routes (et l’instanciation dynamique de la politique de routage « applicatif » associée) qui transiteront par tel ou tel CE.
A titre d’exemple, on considère une connexion applicative établie entre le terminal H2 et le serveur S. Les figures 7A et 7B illustrent un premier chemin à un instant T0 et un deuxième chemin à un instant T1 entre le terminal H2 et le serveur S.
Ces échanges entre le dispositif et le serveur DNS (désignés dans la suite par « communications DNS » par souci de simplification) sont conventionnellement mis en œuvre en clair, selon un mode appelé Do53 (ou « unencrypted DNS » en anglais). Ce mode non chiffré rend possible, aux entités localisées sur le chemin des communications DNS, l’accès à des informations sensibles, par exemple à des fins de profilage. Do53 présente donc un risque d’atteinte à la vie privée des utilisateurs.
Afin d’améliorer le niveau de confidentialité des communications DNS et restreindre l’accès aux informations sensibles véhiculées par ces communications DNS uniquement à des entités habilitées ou consenties, de nombreux mécanismes ont été spécifiés pour chiffrer les communications DNS. Des exemples de tels mécanismes sont « DNS over DTLS (DoD) », « DNS over TLS (DoT) », « DNS over HTTPS (DoH) », « DNS over QUIC (DoQ) », DNS over CoAP (ou DoC), etc. Toutefois, en dépit de la mise en œuvre de tels mécanismes, une entité localisée dans le chemin de communications DNS peut associer l’adresse de destination de paquets de données émis après un échange DNS avec un serveur ou un service donné en utilisant des techniques dites d’analyse statistique (ou « statistical analysis » en anglais), et obtenir ainsi des informations potentiellement sensibles sur les utilisateurs. Une étude de l’APNIC (pour « Asia Pacific Network Information Centre » en anglais) datant de 2019 s’est en effet intéressée aux informations qu’il est possible de tirer d’un ensemble d’adresses IP contactées par un équipement utilisateur. Cette étude montre notamment que la majorité des sites web ont une empreinte de chargement de page ou PLF (pour « Page Load Fingerprint » en anglais) unique ; il existe donc un risque qu’un site web visité par un utilisateur puisse être identifié à partir des adresses IP ciblées par son équipement utilisateur. Il en résulte une protection limitée de la vie privée des utilisateurs par les mécanismes DNS chiffrés précités.
L’invention vient notamment améliorer la situation précitée en proposant un procédé de traitement d’une première requête de résolution de nom provenant d’un dispositif client, ce procédé étant mis en œuvre par un serveur de résolution de noms et comprenant un envoi au dispositif client d’une réponse à la première requête comprenant au moins une information relative à un serveur dit destinataire résultant d’une résolution de la première requête. Le procédé de traitement est remarquable en ce qu’il comprend en outre un envoi au dispositif client d’une pluralité d’éléments comprenant : au moins une adresse d’au moins un nœud relais sélectionné par le serveur de résolution de noms auquel le dispositif client doit adresser tout ou partie de ses messages contenant des données destinées au serveur destinataire ; et au moins une instruction de brouillage devant être appliquée par le dispositif client auxdits messages avant de les adresser audit au moins un nœud relais.
Corrélativement, l’invention concerne également un serveur de résolution de noms configuré pour envoyer une réponse à une première requête de résolution de nom provenant d’un dispositif client, cette réponse comprenant au moins une information relative à un serveur dit destinataire résultant d’une résolution de la première requête. Le serveur de résolution de noms est remarquable en ce qu’il est en outre configuré pour envoyer au dispositif client une pluralité d’éléments comprenant : au moins une adresse d’au moins un nœud relais sélectionné par le serveur de résolution de noms auquel le dispositif client doit adresser tout ou partie de ses messages contenant des données destinées au serveur destinataire ; et au moins une instruction de brouillage devant être appliquée par le dispositif client auxdits messages avant de les adresser audit au moins un nœud relais.
L’invention vise aussi un procédé de communication mis en œuvre par un dispositif client, comprenant une réception, en provenance d’un serveur de résolution de noms, d’une réponse à une première requête de résolution de nom émise par le dispositif client, cette réponse comprenant au moins une information relative à un serveur dit destinataire résultant d’une résolution de la première requête. Le procédé de communication est remarquable en ce qu’il comprend en outre : une réception d’une pluralité d’éléments, en provenance du serveur de résolution de noms, comprenant : au moins une adresse d’au moins un nœud relais sélectionné par le serveur de résolution de noms auquel le dispositif client doit adresser tout ou partie de ses messages contenant des données destinées au serveur destinataire ; et au moins une instruction de brouillage devant être appliquée par le dispositif client auxdits messages avant de les adresser audit au moins un nœud relais ; et une application de ladite instruction de brouillage auxdits messages.
Corrélativement, l’invention concerne également un dispositif client configuré pour recevoir, en provenance d’un serveur de résolution de noms, une réponse à une première requête de résolution de nom émise par le dispositif client, cette réponse comprenant au moins une information relative à un serveur dit destinataire résultant d’une résolution de la première requête. Le dispositif client est remarquable en ce qu’il est en outre configuré pour : recevoir une pluralité d’éléments, en provenance du serveur de résolution de noms, comprenant : au moins une adresse d’au moins un nœud relais sélectionné par le serveur de résolution de noms auquel le dispositif client doit adresser tout ou partie de ses messages contenant des données destinées au serveur destinataire ; et au moins une instruction de brouillage devant être appliquée par le dispositif client auxdits messages avant de les adresser audit au moins un nœud relais ; et appliquer ladite instruction de brouillage auxdits messages.
Selon un autre aspect encore, l’invention vise aussi un procédé de traitement de messages mis en œuvre par un nœud relais sélectionné par un serveur de résolution de noms pour un dispositif client et un serveur destinataire, ce procédé comprenant : une acquisition d’au moins une information relative à au moins une instruction de brouillage appliquée par le dispositif client à des messages contenant des données destinées au serveur destinataire avant de les adresser au nœud relais ; sur réception d’au moins un message brouillé contenant des données destinées au serveur destinataire et adressé au nœud relais par le dispositif client, une suppression en utilisant ladite au moins une information acquise, du brouillage appliqué par le dispositif client ; et un transfert dudit au moins un message obtenu après suppression du brouillage vers le serveur destinataire.
Corrélativement, l’invention concerne également un nœud relais dans un réseau de communications sélectionné par un serveur de résolution de noms pour un dispositif client et un serveur destinataire, ce nœud relais étant configuré pour : acquérir au moins une information relative à au moins une instruction de brouillage appliquée par le dispositif client à des messages contenant des données destinées au serveur destinataire avant de les adresser au nœud relais ; sur réception d’au moins un message brouillé contenant des données destinées au serveur destinataire et adressé au nœud relais par le dispositif client, supprimer en utilisant ladite au moins une information acquise, le brouillage appliqué par le dispositif client ; et transférer ledit au moins un message obtenu après suppression du brouillage vers le serveur destinataire.