FR3091097A1 - Procédé d’acquisition d’une chaîne de délégation relative à la résolution d’un identifiant de nom de domaine dans un réseau de communication - Google Patents
Procédé d’acquisition d’une chaîne de délégation relative à la résolution d’un identifiant de nom de domaine dans un réseau de communication Download PDFInfo
- Publication number
- FR3091097A1 FR3091097A1 FR1873343A FR1873343A FR3091097A1 FR 3091097 A1 FR3091097 A1 FR 3091097A1 FR 1873343 A FR1873343 A FR 1873343A FR 1873343 A FR1873343 A FR 1873343A FR 3091097 A1 FR3091097 A1 FR 3091097A1
- Authority
- FR
- France
- Prior art keywords
- domain
- server
- identifier
- chain
- delegation
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Withdrawn
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L61/00—Network arrangements, protocols or services for addressing or naming
- H04L61/45—Network directories; Name-to-address mapping
- H04L61/4505—Network directories; Name-to-address mapping using standardised directories; using standardised directory access protocols
- H04L61/4511—Network directories; Name-to-address mapping using standardised directories; using standardised directory access protocols using domain name system [DNS]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
- H04L63/0272—Virtual private networks
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
- H04L63/0815—Network architectures or network communication protocols for network security for authentication of entities providing single-sign-on or federations
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
- H04L63/0823—Network architectures or network communication protocols for network security for authentication of entities using certificates
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/16—Implementing security features at a particular protocol layer
- H04L63/166—Implementing security features at a particular protocol layer at the transport layer
Abstract
Procédé d’acquisition d’une chaîne de délégation relative à la résolution d’un identifiant de nom de domaine dans un réseau de communication Procédé et dispositif d’acquisition d’un identifiant d’un serveur (22) de données apte à délivrer un contenu à un terminal (100), le procédé étant exécuté par le terminal (100) qui émet à destination d’un serveur (50) de résolution d’une architecture de communication un message de requête d’obtention d’un identifiant du serveur de données (22) dans le deuxième domaine (40). Ce message de requête déclenche la réception, en provenance du serveur (50) de résolution, d’un message d’information comprenant l’identifiant du serveur de données (22) dans un premier domaine (20). Ce message comprend en outre une chaîne de délégation, qui consiste en une suite de redirections depuis le deuxième domaine (40) jusqu’au premier domaine (20). Figure pour l'abrégé : Figure 1
Description
Description
Titre de l'invention : Procédé d’acquisition d’une chaîne de délégation relative à la résolution d’un identifiant de nom de domaine dans un réseau de communication
1. Domaine technique
[0001] L'invention se situe dans les réseaux de communications et vise à mettre en œuvre un procédé permettant de mettre en œuvre une délégation sécurisée d’un deuxième domaine d’une architecture DNS (Domain Name Server) à un premier domaine dans le but qu’un terminal obtienne un identifiant d’un serveur de données du premier domaine apte à délivrer un contenu, l’identifiant étant initialement requis auprès du deuxième domaine.
2. Etat de la technique
[0002] Dans les architectures de communication, les contenus sont le plus souvent distribués aux terminaux à partir de serveurs de données qui ne sont pas nécessairement les serveurs dits d’origine qui disposent initialement des contenus demandés. Par exemple, si un terminal veut accéder aux données de la page http://www.exemple.fr, alors ces données seront probablement transmises par un serveur CDN ou autrement dit d’un serveur cache ayant obtenu les données du serveur d’origine, hébergeant les données de la page citée ci-dessus. Il convient alors de transmettre l’identifiant de ce serveur CDN au client, celui-ci établissant une session avec ce serveur CDN pour effectivement obtenir les données par exemple en établissant une session HTTPS (HyperText Transfer Protocol Secure), par exemple de type HTTP over TLS (Transport Layer Security). Ces types d’architecture permettent notamment de limiter les accès vers le serveur d’origine, de réduire la consommation de bande passante dans les réseaux de communication en rapprochant les serveurs de données des terminaux, et d’améliorer la qualité d’expérience pour les clients souhaitant accéder à ces données.
[0003] Ainsi, un terminal transmettant une requête en vue d’obtenir un identifiant d’un serveur de données vers un serveur DNS (Domain Name Server) d’un domaine d’origine, par exemple CSP.com, est redirigée vers un serveur DNS d’un CDN d’un opérateur d’un réseau de communications ou d’un opérateur de serveurs CDNs par exemple, en charge de gérer des serveurs CDNs aptes à livrer le contenus requis par le terminal. A titre d’exemple, dans le contexte des architectures « Edge Computing » destinées à être mises en œuvre dans les réseaux de cinquième génération (5G), la livraison de contenus par des serveurs proches des terminaux permet de réduire la latence relative à la distribution des contenus et donc d’améliorer la qualité d’expérience des clients et de fiabiliser le service d’accès aux données en distribuant les serveurs dans différents domaines, un domaine représentant un ensemble de ressources d’un réseau de communications administrées par une même entité.
[0004] Dans le cas des architectures CDN, un serveur CDN doit livrer le contenu en utilisant le nom de domaine d’origine afin que le terminal puisse vérifier et s’assurer que le contenu reçu, qui ne provient d’un serveur du domaine d’origine, provient d’un serveur d’un domaine ayant un accord avec le serveur d’origine. Le terminal compare en effet la concordance entre le domaine demandé dans la requête DNS initialement émise et les informations sur le nom de domaine présentes dans un certificat envoyé par le serveur de données du domaine CDN. Cependant, pour que cette comparaison puisse être effectuée, il faut que le domaine d’origine transmette le certificat au serveur domaine CDN ainsi qu’une clé privée associée au domaine d’origine. La transmission de la clé privée pose en effet des problèmes de confidentialité et de sécurité qu’il convient de résoudre. Le terminal obtient ainsi un contenu d’un serveur d’un domaine dont il ne connaît pas le lien avec le domaine d’origine que le terminal a sollicité pour obtenir le contenu. Le document draft-sheffer-acme-star-delegation-01 décrit une solution permettant une seule délégation par un serveur d’origine à un serveur tiers alors que les architectures de réseaux de communication interconnectent le plus souvent un nombre plus important de domaines, ces domaines n’ayant pas nécessairement tous des accords avec le serveur d’origine.
[0005] Un domaine X intervenant par exemple dans la livraison d’un contenu peut en outre avoir des accords avec différents domaines, correspondant à des fournisseurs distincts de services, et peut lui-même solliciter un autre domaine Y plus approprié pour fournir un identifiant de serveur de données. Ainsi la fourniture d’un identifiant d’un serveur de données à un terminal peut faire intervenir un nombre important de domaines successifs sans contrôle à priori du domaine d’origine initialement sollicité par le terminal. Le partage de clés privées entre les différents domaines n’est cependant pas souhaitable pour des raisons de sécurité et des domaines différents peuvent intervenir dans la fourniture de l’identifiant du serveur de données au terminal en fonction du type de données et/ou du créneau horaire voire en fonction des accords entre les différents domaines pour certains services. Selon les techniques antérieures, il n’est en outre pas possible de contrôler la fiabilité du service d’accès aux données par des contrôles à priori, c’est-à-dire avant la connexion du terminal au serveur de données identifié dans la réponse DNS transmise au terminal, ou bien à postériori, c’est-à-dire une fois que le terminal s’est connecté au serveur de données.
[0006] La présente invention a pour objet d’apporter des améliorations par rapport à l’état de la technique.
3. Exposé de l'invention
[0007] L'invention vient améliorer la situation à l'aide d'un procédé d’acquisition d’un identifiant d’un serveur de données apte à délivrer un contenu à un terminal, le procédé étant exécuté par le terminal et comprenant une étape de réception, en provenance d’un serveur de résolution d’une architecture de communication, d’un message d’information comprenant l’identifiant du serveur de données dans un premier domaine, et comprenant en outre une chaîne de délégation, incluant au moins une redirection depuis un deuxième domaine jusqu’au premier domaine, la réception du message d’information étant déclenchée par une étape d’émission à destination du serveur de résolution d’un message de requête d’obtention d’un identifiant du serveur de données dans le deuxième domaine.
[0008] La fourniture d’un contenu à un terminal requiert le plus souvent la contribution de serveurs de noms (Serveurs DNS) de domaines différents qui vont se rediriger successivement une requête DNS vers jusqu’à un serveur de nom d’un domaine en capacité de transmettre un identifiant d’un serveur de données auquel le terminal devra se connecter pour obtenir le contenu. Parmi les serveurs de noms impliqués dans la fourniture de l’identifiant du serveur de données, on peut identifier des serveurs DNS de domaines CDNs d’opérateurs intervenant dans la gestion du réseau de communication et domaines CDNs de fournisseurs de solutions CDN. En connaissant toute la chaîne de délégation, comprenant les délégations successives d’un serveur de nom à un autre serveur de nom, depuis le serveur du domaine d’origine, initialement sollicité par un serveur de résolution que le terminal a sollicité via une requête d’obtention d’un identifiant de serveur de données, jusqu’au serveur de livraison du domaine terminant la chaîne de délégation, le terminal peut s’assurer que le contenu qui sera délivré provient effectivement initialement d’un serveur d’un domaine approuvé de proche en proche dans la chaîne. Le terminal peut en outre s’assurer que le serveur de données est bien autorisé à fournir le contenu, conformément aux informations présentes dans la chaîne de délégation. La chaîne de délégation correspond en effet à une suite de redirections depuis le serveur domaine d’origine, ou deuxième domaine, jusqu‘au domaine dans lequel se trouve effectivement le serveur de données en capacité de livrer le contenu au terminal. Le nombre de redirections et de domaines intermédiaires entre le domaine de début de chaîne, c’est à dire le domaine d’origine, et le domaine de fin de chaîne, c’est-à-dire comprenant le serveur de livraison, n’est pas limité. Un domaine correspond à un ensemble de dispositifs partageant des informations d’annuaires. Il peut s’agir d’un domaine géographique ou d’un domaine logique et chaque domaine peut lui-même comprendre des sous domaines, créant ainsi une organisation hiérarchique des noms de domaines, tel que celui utilisé pour le service DNS. Une redirection entre domaines consiste à transmettre une requête d’obtention d’un identifiant de serveur vers un autre domaine, ces échanges étant effectués entre serveurs de noms.
[0009] Le procédé d’acquisition présente en outre l’avantage de pouvoir informer le terminal sur les différents domaines et donc des acteurs intervenant dans la fourniture du contenu avant même de demander le contenu. Le procédé permet ainsi de pouvoir informer le terminal avant qu’une requête d’obtention du contenu soit effectivement émise. Le terminal détient toutes les informations sur les délégations entre domaines avant de transmettre effectivement une requête d’obtention du contenu et il peut le cas échéant ne pas demander le contenu si une des délégations de la chaîne ne lui convient pas.
[0010] Le procédé d’acquisition peut ainsi être utilisé pour différents protocoles exploitant ensuite la chaîne de délégation reçue par le terminal. Ainsi les protocoles HTTP over TLS ou les services relatifs au Edge Caching, permettant de livrer des contenus au plus près des terminaux, peuvent exploiter le procédé.
[0011] Le procédé d’acquisition dispense en outre de l’envoi d’une clé privée relative à un deuxième domaine à un premier domaine, puisque la chaîne de délégation indique que le deuxième domaine autorise implicitement le serveur de livraison du premier domaine à délivrer le contenu et représente donc une alternative au partage de clé privée qui pose des problèmes de sécurité. L’obtention de l’information sur les délégations successives entre domaines, décrites dans la chaîne de délégation, lors de l’obtention de l’identifiant du serveur de données délivrant le contenu requis, permet en outre de pouvoir exploiter l’information sur la chaîne pour des requêtes successives d’obtention de contenu, possiblement à partir de protocoles de communication distincts. Le procédé peut possiblement être mis en œuvre à partir des échanges relatifs au protocole DNS largement utilisé dans les réseaux de communications.
[0012] Selon un aspect de l'invention, le message de requête du procédé d’acquisition comprend un paramètre de délégation.
[0013] L’envoi d’un paramètre de délégation par le terminal dans le message de requête d’obtention permet de transmettre ou non la chaîne de délégation au terminal, ou bien de différencier les requêtes d’obtention, limitant les échanges nécessaires à la génération de la chaîne et/ou à l’obtention de celle-ci voire permettant une mise en œuvre d’architecture de résolution adaptée à la fourniture d’une chaîne de délégation.
[0014] Selon un autre aspect de l’invention, dans le procédé d’acquisition, la chaîne de délégation comprend une durée de validité de la chaîne.
[0015] Le procédé présente l’intérêt de pouvoir mettre en œuvre la chaîne de délégation pour une durée limitée. Cela permet d’améliorer la sécurité de la délégation en évitant qu’un domaine corrompu puisse par exemple subsister de façon continue dans une chaîne obtenue par un terminal. La durée de validité permet en outre d’obliger le terminal à mettre en œuvre régulièrement, c’est-à-dire lorsque la durée de validité est expirée, le procédé pour obtenir les mises à jour de la chaîne de délégation.
[0016] Selon un autre aspect de l’invention, dans le procédé d’acquisition, la chaîne de dé5 légation comprend une donnée d’authentification de la chaîne.
[0017] La chaîne de délégation comprend avantageusement une donnée de signature de la chaîne, par exemple pour authentifier le domaine redirigeant vers un autre domaine, ainsi que possiblement l’algorithme utilisé pour vérifier la chaîne de délégation, ou toute autre information d’authentification, ajouté par un serveur de la chaîne et permettant au terminal d’authentifier un serveur ajouté dans la chaîne de délégation. Notamment, chaque domaine présent dans la chaîne joint un certificat à la chaîne de délégation générée, le certificat étant possiblement valide pour une durée déterminée.
[0018] Selon un autre aspect de l’invention, dans le procédé d’acquisition, la chaîne de délégation comprend au moins une redirection vers au moins un troisième domaine intermédiaire.
[0019] Le procédé d’acquisition est avantageusement mis en œuvre lorsque l’architecture de communication dans laquelle il est mis en œuvre comprend au moins 3 domaines et qu’au moins deux redirections entre domaines distincts sont comprises dans la chaîne de délégation transmise au terminal. Chaque domaine peut ainsi utiliser les informations de la chaîne pour rediriger une requête d’obtention d’un identifiant vers un autre domaine.
[0020] Selon un autre aspect de l’invention, le procédé d’acquisition comprend en outre une étape d’émission d’un message d’établissement d’une connexion à destination de l’identifiant du serveur de données dans le premier domaine, le message d’établissement comprenant la chaîne de délégation.
[0021] Le terminal peut avantageusement exploiter les informations relatives à la chaîne de délégation pour établir une connexion avec le serveur de livraison en vue d’obtenir le contenu requis. En effet, une fois qu’il a obtenu l’identifiant du serveur de livraison en charge de la fourniture du contenu, il peut directement établir une connexion avec ce serveur pour obtenir le contenu. L’ajout de la chaîne de délégation dans le message d’établissement de connexion permet d’informer le serveur de livraison qu’il a obtenu cette chaîne et qu’il valide possiblement la chaîne de délégation reçue dans le message d’information.
[0022] Selon un autre aspect de l’invention, le procédé d’acquisition comprend en outre une étape de réception d’un message d’acceptation de la connexion en provenance du serveur de données.
[0023] Une étape de réception d’un message d’acceptation de la connexion en provenance du serveur de données permet à celui-ci de valider (ou d’invalider) l’établissement de la connexion ainsi que la chaîne de délégation qui a été transmise dans le message d’établissement de la connexion.
[0024] Selon un autre aspect de l’invention, dans le procédé d’acquisition, le message d’établissement de la connexion comprend en outre une donnée d’identification du deuxième domaine.
[0025] Le terminal ayant initialement demandé un identifiant d’un serveur du deuxième domaine, il peut avantageusement ajouter dans le message d’établissement de la connexion une donnée d’identification du deuxième domaine. Cette information permet au serveur de livraison du premier domaine de faire le lien entre l’établissement de la connexion et la chaîne.
[0026] Selon un autre aspect de l’invention, le procédé d’acquisition comprend en outre une étape de réception en provenance du serveur de données d’un message de communication d’au moins un certificat associé à la chaîne de délégation.
[0027] La communication de certificats associés aux domaines présents dans la chaîne de délégation, et donc intervenant dans la livraison du contenu demandé. La présence du certificat du deuxième domaine permet ensuite au terminal de compléter l’établissement de la session sécurisée avec le serveur de livraison.
[0028] Les différents aspects du procédé d’acquisition qui viennent d'être décrits peuvent être mis en œuvre indépendamment les uns des autres ou en combinaison les uns avec les autres.
[0029] L’invention concerne également un procédé d’association d’une chaîne de délégation à un message d’information comprenant un identifiant d’un serveur de données, apte à délivrer un contenu à un terminal, le procédé étant exécuté par un serveur de résolution d’une architecture de communication et comprenant les étapes suivantes :
- réception, en provenance du terminal, d’un message de requête d’obtention d’un identifiant du serveur de données dans un deuxième domaine,
- détermination d’une chaîne de délégation, comprenant au moins une redirection depuis le deuxième domaine jusqu’à un premier domaine,
- émission d’un message d’information, à destination du terminal, comprenant l’identifiant du serveur de données dans le premier domaine, ledit message d’information comprenant en outre la chaîne de délégation déterminée.
[0030] L’invention concerne également un dispositif d’acquisition d’un identifiant d’un serveur de données apte à délivrer un contenu à un terminal, comprenant :
- un récepteur, apte à recevoir, en provenance d’un serveur de résolution d’une architecture de communication, un message d’information comprenant l’identifiant du serveur de données dans un premier domaine, et comprenant en outre une chaîne de délégation, incluant au moins une redirection depuis un deuxième domaine jusqu’au premier domaine,
- un émetteur, apte à émettre à destination du serveur de résolution un message de requête d’obtention d’un identifiant du serveur de données dans le deuxième domaine et à déclencher la réception du message d’information.
[0031] Ce dispositif, apte à mettre en œuvre dans tous ses modes de réalisation le procédé d’acquisition qui vient d'être décrit, est destiné à être mis en œuvre dans un terminal, tel qu’un terminal mobile (smartphone, tablette...) ou un terminal fixe, tel qu’un ordinateur ou bien encore un équipement d’accès d’un réseau domestique ou professionnel (box).
[0032] L’invention concerne également un dispositif d’association d’une chaîne de délégation à un message d’information comprenant un identifiant d’un serveur de données apte à délivrer un contenu à un terminal, mis en œuvre dans d’une architecture de communication et comprenant:
- un récepteur, apte à recevoir en provenance du terminal un message de requête d’obtention d’un identifiant du serveur de données dans un deuxième domaine,
- un module de détermination, apte à déterminer une chaîne de délégation, comprenant au moins une redirection depuis le deuxième domaine jusqu’à un premier domaine,
- un émetteur, apte à émettre un message d’information à destination du terminal, ledit message comprenant l’identifiant du serveur de données dans le premier domaine, et comprenant en outre la chaîne de délégation déterminée.
[0033] Ce dispositif, apte à mettre en œuvre dans le procédé d’association qui vient d'être décrit, est destiné à être mis en œuvre dans résolveur de noms, par exemple un résolveur DNS, et peut être instancié dans un terminal, fixe ou mobile ou bien dans un équipement d’accès d’un réseau domestique ou professionnel (box) ou bien dans un équipement spécifique d’un réseau d’opérateur.
[0034] L’invention concerne aussi un système d’acquisition d’un identifiant d’un serveur de données comprenant :
- un dispositif d’acquisition d’un identifiant d’un serveur de données, - un dispositif d’association d’une chaîne de délégation.
[0035] L'invention concerne aussi des programmes d'ordinateur comprenant des instructions pour la mise en œuvre des étapes des procédés respectifs d’acquisition et d’association qui viennent d'être décrits, lorsque ces programmes sont exécutés par des processeurs et des supports d’enregistrement lisibles par des dispositifs respectifs d’acquisition et d’association sur lesquels sont enregistrés les programmes d’ordinateur.
[0036] Ces programmes peuvent 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.
[0037] L’invention vise aussi un support d'informations lisible par un ordinateur, et comportant des instructions des programmes d'ordinateur tel que mentionnés ci-dessus.
[0038] Le support d'informations 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 une disquette (floppy disc) ou un disque dur.
[0039] D'autre part, le support d'informations peut être un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par radio ou par d'autres moyens. Les programmes selon l'invention peuvent être en particulier téléchargés sur un réseau de type Internet.
[0040] Alternativement, le support d'informations peut être un circuit intégré dans lequel les programmes sont incorporés, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution des procédés en question.
4. Brève description des dessins
[0041] D'autres avantages et caractéristiques de l'invention apparaîtront plus clairement à la lecture de la description suivante d'un mode de réalisation particulier de l'invention, donné à titre de simple exemple illustratif et non limitatif, et des dessins annexés, parmi lesquels :
[0042] [fig.l] La figure 1 présente une vue simplifiée d’une architecture de communication dans laquelle est mise en œuvre l’invention selon un aspect de l’invention,
[0043] [fig-2] La figure 2 présente l’élaboration d’une chaîne de délégation, comprenant un ensemble de redirections, selon un aspect de l’invention,
[0044] [fig.3] La figure 3 présente un aperçu du procédé d’acquisition d’un identifiant d’un serveur de données selon un mode de réalisation de l'invention,
[0045] [fig-4] La figure 4 présente un exemple de structure d'un dispositif d’acquisition selon un aspect de l'invention,
[0046] [fig.5] La figure 5 présente un exemple de structure d'un dispositif d’association selon un aspect de l'invention.
5. Description des modes de réalisation
[0047] Dans la suite de la description, on présente des modes de réalisation de l'invention dans une infrastructure de communication. Cette infrastructure peut être fixe ou mobile et l’invention peut être destinée à l’acquisition d’un identifiant d’un serveur de données pour des clients d’entreprise ou des clients dits résidentiels ou grand public.
[0048] On se réfère tout d’abord à la figure 1 qui présente une vue simplifiée d’une architecture de communication dans laquelle est mise en œuvre l’invention selon un aspect de l’invention.
[0049] Un terminal 100, qui peut être un terminal fixe ou un terminal mobile, souhaite obtenir un contenu d’un serveur distant en utilisant le protocole HTTPS. Par exemple, le contenu du serveur distant est le suivant : https://www.abc.com. Le terminal 100 transmet donc une requête de résolution du nom https://www.abc.com pour obtenir un identifiant réseau, par exemple une adresse IP (Internet Protocol) de type IPv4 ou IPv6, correspondant à ce nom. Le terminal 100 sollicite donc un serveur 50 de résolution pour obtenir l’identifiant réseau du serveur stockant le contenu. La requête d’obtention de l’identifiant du serveur d’origine envoyée par le terminal 100, selon une alternative, peut comprendre un paramètre de délégation indiquant notamment que le terminal 100 supporte la fonction « délégation » et ordonnant au serveur 50 de résolution de requérir les infos relatives à la délégation. Le serveur 50 de résolution est par exemple un dispositif de type « Résolveur DNS (Domain Name System)». Ce résolveur DNS peut être intégré au terminal 100, ou bien mis en œuvre dans un réseau local auquel est attaché le terminal 100, ou bien encore exploité par un opérateur gérant le réseau d’accès auquel est attaché le terminal 100. Le serveur 50 de résolution, n’ayant pas d’enregistrement associant un identifiant réseau au nom, correspondant dans ce cas à une adresse, initie un procédé de redirection en vue d’établir une chaîne de délégation pour obtenir l’identifiant d’un serveur de données hébergeant le contenu. Il sollicite un serveur 41 de noms, par exemple un serveur DNS, du domaine 40 d’origine abc.com pour obtenir l’identifiant réseau en transmettant un message de requête comprenant le paramètre de délégation reçu du terminal 100. Le serveur 50 de résolution, selon un exemple, peut avoir été redirigé vers le serveur 41 de noms du domaine d’origine après avoir transmis une requête lui permettant d’obtenir un identifiant du serveur 41 de noms à d’autres serveurs, tels que des serveurs dits racine et/ou des serveurs du domaine .corn avant de pouvoir effectivement joindre le serveur 41 de noms.
[0050] Il est considéré dans cette demande que le contenu https://www.abc.com est répliqué dans des serveurs dits locaux permettant aux terminaux d’accéder au contenu répliqué avec une moindre latence et permettant une consommation moindre des ressources de communication. Le serveur 41 détermine un autre domaine 30 vers lequel rediriger le serveur 50 de résolution. Le serveur 41 de noms répond au serveur 50 de résolution en transmettant un message d’instruction indiquant que l’adresse IP d’un serveur stockant le contenu peut être obtenue en transmettant une requête à un serveur 31 de noms du domaine 30. Le message de redirection comprend ainsi une chaîne de délégation indiquant la redirection par le domaine 40 vers le domaine 30.
[0051] A la réception de ce message de redirection, le serveur 50 de résolution émet un message de requête d’obtention de l’identifiant d’un serveur stockant le contenu https://www.abc.com à destination du serveur 31 de noms du domaine 30. Cette requête comprend en outre la chaîne de délégation reçue du serveur 4L Le serveur 31 répond au serveur 50 de résolution en le redirigeant vers le serveur 21 de noms du domaine 20 après avoir modifié la chaîne de délégation avec la nouvelle redirection ajoutée du domaine 30 vers le domaine 20. Cette chaîne modifiée est également transmise au domaine 20.
[0052] Le serveur 50 de résolution sollicite ensuite le serveur 21 de noms, conformément à la redirection obtenue précédemment, en joignant la chaîne modifiée, pour obtenir le contenu https://www.abc.com. Le serveur 21 connaissant l’adresse IP d’un serveur 22 dans le domaine 20, hébergeant le contenu demandé par le terminal 100, il la communique au serveur 50 de résolution dans un message d’instruction comprenant en outre la chaîne de délégation complète depuis le domaine d’origine 40 jusqu’au domaine 20, c’est-à-dire du domaine 40 vers le domaine 30 puis du domaine 30 vers le domaine 20, dans lequel se trouve le serveur 22 de données en capacité de délivrer le contenu au terminal 100.
[0053] Le serveur 50 de résolution transmet ce message d’information au terminal 100 qui obtient alors l’adresse IP du serveur 22 de données vers laquelle transmettre une requête d’obtention du contenu et la chaîne de délégation complète reçue du serveur 50 de résolution. Le terminal 100, selon un exemple, émet ensuite un message d’établissement de connexion, tel qu’un message de type HTTP/TLS (Transport Layer Security) au serveur 22, ce message comprenant la chaîne de délégation reçue. Le serveur 22, en retour, émet un message d’acceptation de la connexion en provenance du serveur 22 de livraison du contenu à destination du terminal 100.
[0054] En relation avec la figure 2, on présente l’élaboration d’une chaîne de délégation, comprenant une suite de redirections, selon un aspect de l’invention.
[0055] Dans cette figure, les trois domaines 20, 30, 40 présentés dans la figure 1 sont également représentés. Il est considéré dans ce mode de réalisation, que les trois domaines 20, 30, 40 correspondent à des réseaux CDN (Content Delivery Networks) mais il pourrait également s’agir de réseaux d’opérateurs ou bien encore d’infrastructures de stockage (cloud) localisés à différents endroits. Le domaine 40 comprend un serveur de données dont un terminal, non représenté sur cette figure, souhaite obtenir l’identifiant pour ensuite requérir des données de ce serveur. L’identifiant du serveur de données du domaine 40 n’est pas transmis au terminal mais une suite de redirections vont s’opérer entre les différents domaines 40, 30, 20 pour qu’un serveur de données, plus proche du terminal et/ou plus performant pour satisfaire la demande du terminal et/ou ayant plus de ressources pour transmettre les données au terminal soit identifié et transmis au terminal. Dans le cas présent, un identifiant d’un serveur de données du domaine CDN 20 sera transmis au terminal. Une suite de redirections du domaine 40 jusqu’au domaine 20 doit être mis en place de façon transparente pour le terminal qui doit pouvoir vérifier et adapter son comportement en fonction des redirections. Selon une alternative, le domaine 40 dit domaine d’origine peut également valider ou non les différentes redirections, par exemple en fonction des accords avec les différents domaines présents dans la chaîne qui comprend les redirections successives. Cette figure 2 présente les redirections d’une chaîne de délégation ainsi que les différentes informations potentiellement présentes dans la chaîne mais ne présente pas les échanges avec un serveur de résolution. La figure 2 présente une vue synthétique d’un procédé de redirection entre domaines, les éléments Dl, D2, D3, D4 ne représentant pas des échanges entre les domaines 40, 30, 20 mais le principe d’élaboration d’une chaîne de délégation à partir des informations de redirections successives.
[0056] Lors de la réception par un serveur de noms du domaine 40 d’une requête pour obtenir l’identifiant (nom, adresse IP...) d’un serveur de données hébergeant un contenu désiré par un terminal, le serveur de noms (DNS) peut indiquer l’identifiant d’un serveur de données (serveur HTTP, serveur LTP (Pile Transfer Protocol)...) du domaine 40 ou bien rediriger le serveur de résolution, mandataire du terminal pour l’obtention de l’identifiant, vers un serveur de noms d’un autre domaine. Cette deuxième option est utilisée par le serveur DNS du domaine 40 qui délègue à un serveur DNS du domaine 30 la fourniture d’un identifiant du serveur de données. Le domaine 40 délègue au domaine 30 la réponse à la requête pour obtenir l’identifiant envoyée par le serveur de résolution. Et le domaine 30 fait de même pour déléguer vers le domaine 20 la réponse à transmettre au serveur de résolution contribuant ainsi à l’élaboration de la chaîne de délégation. Dans la figure 2, Dl comprend des informations de délégations du domaine 40 vers le domaine 30, ces informations étant transmises au serveur de résolution, et D2 comprend des informations de délégation du domaine 30 vers le domaine 20, également transmises au serveur de résolution. La chaîne comprend les informations D4 de délégation complète du domaine 40 vers le domaine 20 incluant les informations Dl et D2 ainsi que possiblement les informations D3 de redirection du domaine 20 vers lui-même. La chaîne de délégation peut ainsi comprendre un nombre important d’informations de délégations successives. La chaîne complète, lorsqu’elle comprend les informations D3 de délégation du domaine 20 vers lui-même permet au serveur de résolution d’identifier la fin de la chaîne de délégation en vue de faciliter les traitements futurs et d’indiquer ainsi que la chaîne est complète. Un serveur de noms d’un domaine indique ainsi un autre domaine que le serveur de résolution doit solliciter, après avoir modifié la chaîne de délégation avec l’ajout d’une redirection vers le domaine que le serveur de résolution doit solliciter.
[0057] Pour obtenir la chaîne complète de délégation, il est nécessaire d’interroger un serveur de noms de tous les domaines impliqués dans la résolution DNS permettant finalement d’obtenir l’identifiant du serveur de données. La chaîne Dl de délégation comprend, selon un exemple, un ensemble d’éléments correspondant à un bloc, tels que:
- Prom : Nom du domaine déléguant - CDN1 40
- To : Nom du domaine délégué - CDN2 30
- Start_time : Heure de démarrage de la délégation (UTC Time)
- Validity : Temps en seconde depuis Start_time
- signature_algorithm : signature hash + algorithme - nom de l’algorithme utilisé pour vérifier la chaîne de délégation. Les valeurs possibles sont définies dans le document IETF RFC 8446 section 4.2.3
- Signature : contient la signature avec un certificat utilisé pour authentifier le nom du domaine présent dans le champ « From » de
[0058] Le champ signature, ajouté selon une alternative, permet de prouver l’authenticité de chaque redirection d’une chaîne de délégation, implicitement en vérifiant le contenu et l’identité du signataire. Il est appliqué de façon itérative quand une nouvelle redirection est ajoutée à une chaîne existante. Chaque nouveau bloc, correspondant à une délégation d’un domaine à un autre, acquitte la précédente délégation et prouve l’authenticité de la nouvelle. La clé privée utilisée pour signer chaque bloc est celle du certificat du domaine qui est en train de déléguer (champ From). Il est à noter que l’information de redirection est composé des informations des champs « from » et « to » d’un bloc.
[0059] Les informations de la chaîne D4 comprennent donc les 2 blocs de données DI et D2 correspondant aux délégations successives du domaine CDN1 40 vers le domaine CDN2 30 puis du domaine CDN2 30 vers le domaine CDN3 20 et possiblement un troisième bloc de données D3 correspondant à une délégation du domaine CDN3 20 vers lui-même.
[0060] Les informations de redirection des blocs, donc les champs « From » et «To» doivent être présentes alors que les autres informations des blocs, relatifs à la durée de délégation et à la sécurité, sont optionnelles. Les chaînes, composées de blocs, sont reçues par les serveurs de noms des domaines, en provenance d’un serveur de résolution, puis modifiées en ajoutant un bloc comprenant une redirection et possiblement une durée de vie de la chaîne ainsi qu’une signature, puis renvoyé au serveur de résolution. Ainsi, le serveur de résolution sollicite un serveur de noms du domaine 40, reçoit en retour un message de redirection comprenant une chaîne de délégation comprenant les informations DI de redirection vers le domaine 30. Le serveur de résolution émet un message d’obtention de l’identifiant du serveur de données, comprenant la chaîne reçue, à un serveur de noms du domaine 30. Ce serveur de noms, n’étant pas dans un domaine comprenant un identifiant du serveur de données, identifie un domaine vers lequel rediriger le serveur de résolution, et modifie la chaîne en ajoutant le bloc de données D2. Il envoie la chaîne (DI + D2) dans un message d’instruction au serveur de résolution. Le serveur de résolution sollicite un serveur de noms du domaine 20. Le domaine 20 comprenant un serveur de données, le serveur de noms modifie la chaîne reçue en ajoutant le bloc D3 et transmet la chaîne modifiée, comprenant les blocs de données Dl, D2, D3 au serveur de résolution.
[0061] On se réfère maintenant à la figure 3 qui présente un aperçu du procédé d’acquisition d’un identifiant d’un serveur de données selon un mode de réalisation de l'invention.
[0062] Lors de l’étape El, le terminal 100 transmet un message de requête d’obtention d’un identifiant d’un serveur de données, représenté ici par une requête DNS, au dispositif 50 qui est de type résolveur DNS. Cette requête DNS est envoyée par le terminal 100 pour connaître l’identité d’un serveur de données dans un domaine donné en capacité de délivrer un contenu requis par le terminal 100. La requête DNS est par exemple de type « DNS Query A cdn.co.com » et le terminal souhaite obtenir une adresse IP correspondant à l’enregistrement de type A (adresse) du nom de domaine cdn.co.com. Selon un exemple, cette requête comprend un paramètre délégation, par exemple une chaîne de délégation vide Delegation (), car aucune délégation n’a eu lieu pour l’instant. Le résolveur DNS 50 peut être dans le terminal 100, dans un réseau local auquel est attaché le terminal 100 ou bien encore dans un réseau géré par un opérateur.
[0063] Le résolveur DNS 50 met en place lors de l’étape El 1 un processus pour déterminer une chaîne de délégation associée à l’acquisition de l’identifiant du serveur de données requis par le terminal 100. Cette détermination est un processus itératif entre le résolveur DNS 50 et les différents serveurs de noms des domaines impliqués dans les redirections comprises dans la chaîne de délégation.
[0064] Le résolveur DNS, suite à la requête émise par le terminal 100 lors de l’étape El, émet un message de requête d’un identifiant d’un serveur de données correspondant à cdn.co.com lors de l’étape E2. Ce message est en fait transmis à un serveur DNS dit d’autorité pour le domaine cdn.co.com. Sachant que l’on a dans cdn.co.com au moins trois domaines, à savoir, les domaines .corn, co.com et cdn.co.com, le résolveur DNS 50 peut solliciter un serveur DNS d’autorité du domaine .corn puis un serveur DNS d’autorité du domaine co.com avant de solliciter un serveur DNS du domaine cdn.co.com. Dans l’exemple de la figure 3, seul l’envoi du message de requête vers un serveur DNS 41 du domaine cdn.co.com est représenté. Lors de l’étape E2, le serveur DNS 41, identifié comme le serveur d’origine car il est le premier serveur DNS sollicité par le résolveur DNS 50 pour obtenir l’identifiant d’un serveur de données. Le résolveur DNS 50 inclut une chaîne de délégation vide, possiblement reçu du terminal 100, dans le message de requête transmis au serveur DNS 41. Le résolveur DNS 50 transmet le message suivant :
DNS query A cdn.co.com Extension: Delegation () [0065] Lors de l’étape E21, le serveur DNS 41 modifie la chaîne de délégation en ajoutant une redirection du domaine cdn.co.com vers le domaine co.cdnl.com. Lors de l’étape E3, le serveur DNS 41, ayant déterminé un domaine vers lequel le résolveur DNS 50 doit être redirigé et après avoir modifié la chaîne en conséquence lors de l’étape E21, envoie un message de redirection au résolveur DNS 50 pour lui indiquer que le contenu peut être obtenu auprès du domaine co.cdnl.com. Il crée ainsi le premier niveau de délégation vers co.cdnl.com et a donc modifié la chaîne de délégation en ajoutant un bloc de données à la chaîne de délégation reçue lors de l’étape E2. Il s’agit de la première occurrence de la chaîne de délégation, cette occurrence correspondant à une redirection du domaine cdn.co.com vers le domaine co.cdnl.com. Cette chaîne peut, selon un exemple, comprendre une durée de validité de la chaîne. Selon un autre exemple, la chaîne peut en outre comprendre une donnée d’authentification de la chaîne, tel qu’un certificat du serveur 41. Le message de redirection est un message de type DNS CNAME (Canonical Name) indiquant au résolveur 51 de solliciter un serveur DNS d’autorité du domaine cdnl.co.com. Le contenu du message de redirection transmis par le serveur 41 au résolveur DNS 50 est le suivant : DNS answer CNAME co.cdnl.com
Extension: Delegation ( from: cdn.co.com, to: co.cdnl.com, )
[0066] Le serveur 41 de noms a ainsi mis en œuvre un procédé de modification de la chaîne de délégation avec une redirection du domaine cdn.co.com vers le domaine co.cdnl.com.
[0067] A la réception du message de redirection, le résolveur DNS 50 émet, lors de l’étape E4, à destination d’un serveur DNS d’autorité 31 du domaine cdnl.co.com un message de requête d’identifiant du domaine indiqué par le serveur DNS 41 dans son message de redirection. Ce message de requête comprend la chaîne de délégation mise à jour par le serveur 41 lors de l’étape E21. Le contenu du message transmis par le serveur de résolution 50 est le suivant :
DNS query A co.cdnl.com
Extension: Delegation ( from: cdn.co.com, to: co.cdnl.com, )
[0068] Déterminant que le serveur DNS 31 dispose d’un enregistrement co.cdn2.com vers lequel le résolveur DNS 50 doit être redirigé pour obtenir un identifiant d’un serveur de données, le serveur DNS 31 modifie lors de l’étape E41 la chaîne de délégation reçue à l’étape E4 avec une redirection de co.cdnl.com vers co.cdn2.com. Le serveur DNS 31 du domaine co.cdnl.com émet un message d’instruction, correspondant à une redirection, vers le résolveur DNS 50, ce message comprenant la chaîne de délégation modifiée avec l’ajout de la redirection du domaine co.cdnl.com vers le domaine co.cdn2.com. La modification de la chaîne lors de l’étape E41, selon un exemple, comprend aussi une étape de validation de la chaîne reçue « from: cdn.co.com to: co.cdnl.com » par exemple en vérifiant l’authenticité d’un certificat ajouté par le serveur 41 du domaine cdn.co.com et une étape de signature de la chaîne modifiée en signant le bloc de données ajouté à la chaîne de délégation avec une clé privée propre au serveur 31. Le contenu du message transmis par le serveur 31 lors de l’étape E5 est le suivant :
DNS answer CNAME co.cdn2.com
Extension: Delegation ( from: cdn.co.com, to: co.cdnl.com, from: co.cdnl.com, to: co.cdn2.com, )
[0069] De façon identique à l’étape E4, le résolveur DNS 50 émet, lors de l’étape E6, un message de requête d’un identifiant d’un serveur de données dans le domaine cdn2.co.com vers un serveur DNS 21 du domaine co.cdn2.com. Le message de requête comprend la chaîne de délégation modifiée par le serveur 31 et le contenu du message est le suivant :
DNS query A co.cdn2.com
Extension: Delegation ( from: cdn.co.com, to: co.cdnl.com, from: co.cdnl.com, to: co.cdn2.com,)
[0070] Le serveur DNS 21 est en capacité d’indiquer un identifiant d’un serveur de données dans le domaine co.cdn2.com au résolveur DNS 50. Lors de l’étape E7, il décide donc d’envoyer un message d’instruction, en l’occurrence un message de réponse DNS comprenant l’adresse IP du serveur 22 de données ainsi que la chaîne de délégation modifiée lors de l’étape E61 avec l’ajout d’une délégation du domaine co.cdn2.com vers lui-même. Le serveur DNS 21 ajoute en effet à la chaîne reçue du résolveur DNS 50 une redirection du domaine co.cdn2.com vers lui-même, indiquant ainsi la fin de chaîne de délégation aux dispositifs exploitant cette chaîne. Le message transmis lors de l’étape E7 par le serveur DNS 21 au résolveur DNS 50 est le suivant :
DNS answer A IP@co.cdn2.com
Extension: Delegation ( from: cdn.co.com, to: co.cdnl.com,, from: co.cdnl.com, to: co.cdn2.com,, from: co.cdn2.com, to: co.cdn2.com)
[0071] Le résolveur DNS 50 connaît lors de la réception du message d’instruction le domaine co.cdn2.com en charge de la livraison du contenu et l’identifiant, dans ce cas l’adresse IP, du serveur 22 du domaine co.cdn2.com en charge de la livraison du contenu.
[0072] Selon une alternative, le résolveur DNS 50 émet, lors de l’étape E8, à destination du serveur DNS 41 du domaine cdn.co.com un message de contrôle comprenant la chaîne de délégation modifiée par le serveur 21. Le message émis par le résolveur DNS 50 est le suivant :
DNS query CNAME cdn.co.com
Extension: Delegation ( from: cdn.co.com, to: co.cdnl.com, from: co.cdnl.com, to: co.cdn2.com, from: co.cdn2.com, to: co.cdn2.com, )
[0073] Selon un exemple, le serveur 41 peut valider ou invalider la chaîne de délégation élaborée. Ainsi, si un domaine de la chaîne n’a pas d’accord avec le domaine cdn.co.com et/ou si un domaine n’est pas sécurisé, alors le serveur DNS 41 peut invalider la chaîne et envoyer lors de l’étape E9 un message d’invalidation de la chaîne, comprenant par exemple un paramètre indiquant que la chaîne de délégation n’est pas valide. A la réception de ce message indiquant que la chaîne de délégation n’est pas valide, le résolveur DNS 50 peut émettre à destination du serveur DNS 41 de noms une nouvelle requête d’obtention de l’identifiant d’un serveur de données dans le domaine cdn.co.com avec le paramètre d’invalidité de la chaîne indiquant ainsi au serveur 41 de noms soit de transmettre une nouvelle redirection soit de transmettre au résolveur 50 de noms un identifiant d’un serveur de noms du domaine cdn.co.com sans redirection. Selon un autre exemple, si le serveur DNS 41 valide la chaîne, il transmet un message de validation au résolveur DNS 50. Ce message de validation, pour indiquer la validation de la chaîne, comprend, selon une alternative, une redirection du domaine cdn.co.com vers le domaine cdn2.co.com. Le message de validation se présente alors sous la forme suivante :
DNS query CNAME cdn.co.com
Extension: Delegation ( from: cdn.co.com, to: co.cdnl.com, from: co.cdnl.com, to: co.cdn2.com, from: co.cdn2.com, to: co.cdn2.com, from: cdn.co.com, to: co.cdn2.com,)
[0074] Le résolveur 50 transmet ensuite au terminal 100 un message d’information comprenant l’identifiant du serveur 22 de données. Il s’agit, selon cet exemple, d’un message DNS comprenant l’adresse IP du serveur 22 de données et comprenant en outre la chaîne de délégation élaborée et possiblement approuvée par le serveur 4L Le message reçu par le terminal 100 lors de l’étape E9 est le suivant :
DNS answer A IP@co.cdn2.com
Extension: Delegation ( from: cdn.co.com, to: co.cdnl.com, from: co.cdnl.com, to: co.cdn2.com, from: co.cdn2.com, to: co.cdn2.com, from: cdn.co.com, to: co.cdn2.com, )
[0075] Le résolveur DNS a ainsi mis en œuvre un procédé de redirection permettant d’établir la chaîne de délégation ayant permis de déterminer et de transmettre au terminal 100 l’identifiant du serveur 22 de livraison de données. La chaîne de délégation, comprend les redirections successives entre domaines. La chaîne transmise au terminal 100, selon un exemple, comprend une durée de validité de la chaîne.
[0076] Le terminal 100, une fois qu’il détient ces informations (adresse IP du serveur 22 de données, redirections et paramètres optionnels de la chaîne de délégation) peut, selon une alternative, établir une connexion avec le serveur 22 de données. Lors de l’étape El 1, le terminal 100, selon un exemple, établit une connexion TLS avec le serveur 22 de données dont l’adresse IP propre au domaine co.cdn2.com, qui a été transmise lors de l’étape E10, en émettant un message TLS Client Hello. L’extension SNI (Server Name Indication) du message TLS client Hello comprend, selon un exemple, le nom de domaine cdn.co.com car il s’agit du domaine initialement sollicité par le terminal 100. Le message TLS Client Hello comprend en outre la chaîne de délégation reçue du résolveur DNS 50, indiquant ainsi au serveur 22 de données que le terminal 100 le sollicite conformément à une chaîne de délégation reçue, et possiblement approuvée par le domaine cdn.co.com, le résolveur DNS 50 et le terminal 100. Le contenu du message TLS Client Hello est le suivant: TLS ClientHello
Extension: Server Name Indication (cdn.co.com) Extension: Delegation ( from: cdn.co.com, to: co.cdnl.com, from: co.cdnl.com, to: co.cdn2.com, from: co.cdn2.com, to: co.cdn2.com, from: cdn.co.com, to: co.cdn2.com)
[0077] Lors de l’étape E12, le serveur de données 22 transmet un message d’acceptation de la connexion au terminal 100. Par exemple, il transmet un message TLS Server Hello au terminal 100.
[0078] Lors de l’étape E13, selon un exemple, le serveur 22 de données envoie un message de communication d’au moins un certificat associé à la chaîne de délégation au terminal 100. Ce message est par exemple un message TLS ServerCertificate contenant un certificat du domaine cdn.co.com et le chemin complet du certificat correspondant aux validations successives des domaines de la chaîne de délégation. Il ajoute un certificat pour co.cdn2.com, et la chaîne de délégation prouvant la délégation. Ainsi, le terminal 10 dispose d’un certificat du domaine co.cdn2.com, une chaîne de délégation indiquant les redirections successives entre domaines et une suite de certificats assurant l’authenticité des domaines de la chaîne. Le terminal peut donc, en toute sécurité, utiliser le certificat du domaine co.cdn2.com pour les échanges suivants entre le terminal 100 et le serveur 22 de données et notamment pour les échanges relatifs aux échanges de clés de chiffrement des données.
[0079] Le message TLS ServerCertificate comprend par exemple les informations suivantes: TLS ServerCertificate
Certificate: cdn.co.com
Certificate: co.cdn2.com
Extension: Delegation ( from: cdn.co.com, to: co.cdnl.com, from: co.cdnl.com, to: co.cdn2.com, from: co.cdn2.com, to: co.cdn2.com, from: cdn.co.com, to: co.cdn2.com, ) [0080] Dans les futurs échanges TLS, le terminal 100 va ainsi pouvoir utiliser le certificat du domaine délégué, co.cdn2.com pour les échanges « TLS Handshake » au lieu du certificat du domaine d’origine cdn.co.com.
[0081] L’invention a ainsi permis de déléguer la fourniture d’un identifiant d’un serveur de données à un terminal, le serveur de données étant dans un domaine distinct du domaine initialement sollicité par le terminal, par des redirections successives entre des domaines intermédiaires. Ces redirections forment une chaîne de délégation élaborée par itération successive entre un serveur de résolution et des serveurs de noms des différents domaines intervenant dans la fourniture. L’invention permet ainsi de mettre en œuvre une délégation dynamique et sécurisée entre domaines sans requérir l’échange de clés privées entre les domaines. L’invention permet en effet que les différents domaines puissent intervenir dans le procédé de redirection par le serveur 50 de résolution sans accords au préalable, chacun des domaines déterminant au fur et à mesure des redirections le domaine suivant de la chaîne et modifiant en conséquence la chaîne de délégation, jusqu’à ce qu’un domaine décide ou soit en capacité de transmettre l’identifiant du serveur de données dans son domaine au serveur 50 de résolution. Le terminal peut ainsi ensuite exploiter les informations de la chaîne et les données d’authentification des informations de la chaîne pour établir une session sécurisée vers le domaine finalement indiqué dans la chaîne.
[0082] Il est à noter que dans la figure 3, les informations présentes dans la chaîne de délégation sont uniquement les redirections entre domaines, mais la chaîne peut comprendre des données complémentaires relatives à la durée de vie de la chaîne, aux données de sécurité relatives à la chaîne, conformément aux informations des blocs de données présentées dans la figure 2.
[0083] En relation avec la figure 4, on présente un exemple de structure d'un dispositif d’acquisition, selon un aspect de l'invention.
[0084] Le dispositif 60 d’acquisition met en œuvre le procédé d’acquisition, dont différents modes de réalisation viennent d'être décrits.
[0085] Un tel dispositif 60 peut être mis en œuvre dans un terminal, tel qu’un terminal mobile (smartphone, tablette...) ou un terminal fixe, tel qu’un ordinateur ou bien encore un équipement d’accès d’un réseau domestique ou professionnel (box).
[0086] Par exemple, le dispositif 60 comprend une unité de traitement 630, équipée par exemple d'un microprocesseur μΡ, et pilotée par un programme d'ordinateur 610, stocké dans une mémoire 620 et mettant en œuvre le procédé de taxation selon l'invention. A l’initialisation, les instructions de code du programme d’ordinateur 610 sont par exemple chargées dans une mémoire RAM, avant d’être exécutées par le processeur de l’unité de traitement 630.
[0087] Un tel dispositif 60 comprend :
- un récepteur 64, apte à recevoir, en provenance d’un serveur de résolution d’une architecture de communication, un message Info d’information comprenant l’identifiant du serveur de données dans un premier domaine, et comprenant en outre une chaîne de délégation, incluant au moins une redirection depuis un deuxième domaine jusqu’au premier domaine,
- un émetteur 63, apte à émettre à destination du serveur de résolution un message de requête d’obtention d’un identifiant du serveur de données dans le deuxième domaine et à déclencher la réception du message d’information.
[0088] En relation avec la figure 5, on présente un exemple de structure d'un dispositif d’association, selon un aspect de l'invention.
[0089] Le dispositif 80 d’association met en œuvre le procédé d’association, dont différents modes de réalisation viennent d'être décrits.
[0090] Un tel dispositif 80 d’association peut être mis en œuvre dans un résolveur de noms, par exemple un résolveur DNS, et peut être instancié dans un terminal, fixe ou mobile ou bien dans un équipement d’accès d’un réseau domestique ou professionnel (box) ou bien dans un équipement spécifique d’un réseau d’opérateur.
[0091] Par exemple, le dispositif 80 comprend une unité de traitement 830, équipée par exemple d'un microprocesseur μΡ, et pilotée par un programme d'ordinateur 810, stocké dans une mémoire 820 et mettant en œuvre le procédé de taxation selon l'invention. A l’initialisation, les instructions de code du programme d’ordinateur 810 sont par exemple chargées dans une mémoire RAM, avant d’être exécutées par le processeur de l’unité de traitement 830.
[0092] Un tel dispositif 80 d’association comprend :
- un récepteur 84, apte à recevoir en provenance du terminal un message de requête d’obtention d’un identifiant du serveur de données dans un deuxième domaine,
- un module 82 de détermination, apte à déterminer une chaîne de délégation, comprenant au moins une redirection depuis le deuxième domaine jusqu’à un premier domaine,
- un émetteur 83, apte à émettre un message d’information à destination du terminal, ledit message comprenant l’identifiant du serveur de données dans le premier domaine, et comprenant en outre la chaîne de délégation déterminée.
Claims (1)
-
Revendications [Revendication 1] Procédé d’acquisition d’un identifiant d’un serveur (22) de données apte à délivrer un contenu à un terminal (100), le procédé étant exécuté par le terminal (100) et comprenant une étape (E10) de réception, en provenance d’un serveur (50) de résolution d’une architecture de communication, d’un message d’information comprenant l’identifiant du serveur (22) de données dans un premier domaine (20), et comprenant en outre une chaîne de délégation, incluant au moins une redirection depuis un deuxième domaine (40) jusqu’au premier domaine (20), la réception du message d’information étant déclenchée par une étape (El) d’émission à destination du serveur (50) de résolution d’un message de requête d’obtention d’un identifiant du serveur (22) de données dans le deuxième domaine (40). [Revendication 2] Procédé d’acquisition, selon la revendication 1, où le message de requête comprend un paramètre de délégation. [Revendication 3] Procédé d’acquisition, selon la revendication 1, où la chaîne de délégation comprend une durée de validité de la chaîne. [Revendication 4] Procédé d’acquisition, selon la revendication 1, où la chaîne de délégation comprend une donnée d’authentification de la chaîne. [Revendication 5] Procédé d’acquisition, selon la revendication 1, où la chaîne de délégation comprend au moins une redirection vers au moins un troisième domaine (30) intermédiaire. [Revendication 6] Procédé d’acquisition, selon la revendication 1, comprenant en outre une étape (Eli) d’émission d’un message d’établissement d’une connexion à destination de l’identifiant du serveur (22) de données dans le premier domaine (20), le message d’établissement comprenant la chaîne de délégation. [Revendication 7] Procédé d’acquisition, selon la revendication 6, comprenant en outre une étape (E12) de réception d’un message d’acceptation de la connexion en provenance du serveur (20) de données. [Revendication 8] Procédé d’acquisition, selon la revendication 6, où le message d’établissement de la connexion comprend en outre une donnée d’identification du deuxième domaine (40). [Revendication 9] Procédé d’acquisition, selon la revendication 6, comprenant en outre une étape (El3) de réception en provenance du serveur (22) de données d’un message de communication d’au moins un certificat associé à la chaîne de délégation. [Revendication 10] Procédé d’association d’une chaîne de délégation à un message d’information comprenant un identifiant d’un serveur (22) de données, apte à délivrer un contenu à un terminal (100), le procédé étant exécuté par un serveur (50) de résolution d’une architecture de communication et comprenant les étapes suivantes: - réception (El), en provenance du terminal (100), d’un message de requête d’obtention d’un identifiant du serveur de données dans un deuxième domaine, - détermination (Eli) d’une chaîne de délégation, comprenant au moins une redirection depuis le deuxième domaine jusqu’à un premier domaine, - émission (E10) d’un message d’information, à destination du terminal, comprenant l’identifiant du serveur de données dans le premier domaine, ledit message d’information comprenant en outre la chaîne de délégation déterminée. [Revendication 11] Dispositif (60) d’acquisition d’un identifiant d’un serveur (22) de données apte à délivrer un contenu à un terminal (100), comprenant: - un récepteur (64), apte à recevoir, en provenance d’un serveur (50) de résolution d’une architecture de communication, un message d’information comprenant l’identifiant du serveur (22) de données dans un premier domaine, et comprenant en outre une chaîne de délégation, incluant au moins une redirection depuis un deuxième domaine (40) jusqu’au premier domaine (20), - un émetteur (63), apte à émettre à destination du serveur de résolution un message de requête d’obtention d’un identifiant du serveur de données dans le deuxième domaine et à déclencher la réception du message d’information. [Revendication 12] Dispositif (80) d’association d’une chaîne de délégation à un message d’information comprenant un identifiant d’un serveur (20) de données apte à délivrer un contenu à un terminal, mis en œuvre dans d’une architecture de communication et comprenant: - un récepteur (84), apte à recevoir en provenance du terminal un message de requête d’obtention d’un identifiant du serveur de données dans un deuxième domaine, - un module (82) de détermination, apte à déterminer une chaîne de délégation, comprenant au moins une redirection depuis le deuxième domaine jusqu’à un premier domaine, - un émetteur (83), apte à émettre un message d’information à des- tination du terminal, ledit message comprenant l’identifiant du serveur de données dans le premier domaine, et comprenant en outre la chaîne de délégation déterminée. [Revendication 13] Système d’acquisition d’un identifiant d’un serveur de données comprenant : - un dispositif (60) d’acquisition d’un identifiant d’un serveur (22) de données selon la revendication 11, - un dispositif (80) d’association d’une chaîne de délégation selon la revendication 12. [Revendication 14] Programme d'ordinateur, caractérisé en ce qu'il comprend des instructions pour la mise en œuvre des étapes du procédé d’acquisition selon l’une des revendications 1 à 9, lorsque ce procédé est exécuté par un processeur. [Revendication 15] Support d’enregistrement lisible par un dispositif d’acquisition conforme à la revendication 11, sur lequel est enregistré le programme selon la revendication 14. 1/4
Priority Applications (5)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR1873343A FR3091097A1 (fr) | 2018-12-19 | 2018-12-19 | Procédé d’acquisition d’une chaîne de délégation relative à la résolution d’un identifiant de nom de domaine dans un réseau de communication |
| CN201980083518.7A CN113196722A (zh) | 2018-12-19 | 2019-12-11 | 获取与解析通信网络中的域名标识符相关的委托链的方法 |
| EP19839392.8A EP3900305A1 (fr) | 2018-12-19 | 2019-12-11 | Procédé d'acquisition d'une chaîne de délégation relative à la résolution d'un identifiant de nom de domaine dans un réseau de communication |
| PCT/FR2019/053027 WO2020128238A1 (fr) | 2018-12-19 | 2019-12-11 | Procédé d'acquisition d'une chaîne de délégation relative à la résolution d'un identifiant de nom de domaine dans un réseau de communication |
| US17/415,269 US11575644B2 (en) | 2018-12-19 | 2019-12-11 | Method for acquiring a delegation chain relating to resolving a domain name identifier in a communication network |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR1873343A FR3091097A1 (fr) | 2018-12-19 | 2018-12-19 | Procédé d’acquisition d’une chaîne de délégation relative à la résolution d’un identifiant de nom de domaine dans un réseau de communication |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| FR3091097A1 true FR3091097A1 (fr) | 2020-06-26 |
Family
ID=67660147
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| FR1873343A Withdrawn FR3091097A1 (fr) | 2018-12-19 | 2018-12-19 | Procédé d’acquisition d’une chaîne de délégation relative à la résolution d’un identifiant de nom de domaine dans un réseau de communication |
Country Status (5)
| Country | Link |
|---|---|
| US (1) | US11575644B2 (fr) |
| EP (1) | EP3900305A1 (fr) |
| CN (1) | CN113196722A (fr) |
| FR (1) | FR3091097A1 (fr) |
| WO (1) | WO2020128238A1 (fr) |
Families Citing this family (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN114422264A (zh) * | 2022-02-23 | 2022-04-29 | 深圳市小满科技有限公司 | 一种用户网站内容的访问方法及相关设备 |
Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20120185370A1 (en) * | 2011-01-14 | 2012-07-19 | Cisco Technology, Inc. | System and method for tracking request accountability in multiple content delivery network environments |
| US8909736B1 (en) * | 2012-07-12 | 2014-12-09 | Juniper Networks, Inc. | Content delivery network referral |
| WO2018115647A1 (fr) * | 2016-12-23 | 2018-06-28 | Orange | Validation de livraison de contenu et de verification d'une delegation de livraison d'un contenu |
| WO2018130796A1 (fr) * | 2017-01-16 | 2018-07-19 | Orange | Procédés et dispositifs de vérification de la validité d'une délégation de diffusion de contenus chiffrés |
Family Cites Families (26)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6976090B2 (en) * | 2000-04-20 | 2005-12-13 | Actona Technologies Ltd. | Differentiated content and application delivery via internet |
| US7562153B2 (en) * | 2000-05-12 | 2009-07-14 | AT&T Intellectual Property II, L. P. | Method and apparatus for content distribution network brokering and peering |
| US20040044791A1 (en) * | 2001-05-22 | 2004-03-04 | Pouzzner Daniel G. | Internationalized domain name system with iterative conversion |
| US20030093523A1 (en) * | 2001-11-15 | 2003-05-15 | Cranor Charles D. | Method for associating clients with domain name servers |
| US7289519B1 (en) * | 2002-05-01 | 2007-10-30 | Cisco Technology, Inc. | Methods and apparatus for processing content requests using domain name service |
| US8184641B2 (en) * | 2005-07-20 | 2012-05-22 | Verizon Business Global Llc | Method and system for providing secure communications between proxy servers in support of interdomain traversal |
| US8713188B2 (en) * | 2007-12-13 | 2014-04-29 | Opendns, Inc. | Per-request control of DNS behavior |
| SG183697A1 (en) * | 2007-08-06 | 2012-09-27 | Monseignat Bernard De | System and method for authentication, data transfer, and protection against phishing |
| WO2012063100A1 (fr) * | 2010-11-08 | 2012-05-18 | Telefonaktiebolaget L M Ericsson (Publ) | Procédé et appareil pour autoriser la redirection de dns dans des systèmes de télécommunication mobile |
| US9220051B2 (en) * | 2010-11-08 | 2015-12-22 | Telefonaktiebolaget L M Ericsson (Publ) | Method and apparatus for enabling DNS redirection in mobile telecommunication systems |
| CA2824203C (fr) * | 2011-01-12 | 2021-03-30 | Level 3 Communications, Llc | Noms de domaine personnalises dans un reseau de distribution de contenu (cdn) |
| ES2425626B1 (es) * | 2011-05-12 | 2014-06-05 | Telefónica, S.A. | Método para la resolución de dns de peticiones de contenido en un servicio cdn |
| US9973590B2 (en) * | 2011-11-26 | 2018-05-15 | Bing Wu | User identity differentiated DNS resolution |
| US20150089338A1 (en) * | 2013-09-25 | 2015-03-26 | Sony Corporation | System and methods for providing a network application proxy agent |
| US10277554B2 (en) * | 2014-03-04 | 2019-04-30 | Cisco Technology, Inc. | Transparent proxy authentication via DNS processing |
| US20170295132A1 (en) * | 2014-08-15 | 2017-10-12 | Interdigital Patent Holdings, Inc. | Edge caching of https content via certificate delegation |
| US20160380975A1 (en) * | 2015-06-24 | 2016-12-29 | Cisco Technology, Inc. | Domain Name Service Redirection for a Content Delivery Network with Security as a Service |
| US9954816B2 (en) * | 2015-11-02 | 2018-04-24 | Nominum, Inc. | Delegation of content delivery to a local service |
| GB2545748B8 (en) * | 2015-12-24 | 2019-09-18 | Num Tech Ltd | Methods, apparatuses, and computer programs for data processing, and hierarchical domain name system zone files |
| US10708226B2 (en) * | 2016-01-29 | 2020-07-07 | Verisign, Inc. | Domain name resolution |
| US10645057B2 (en) * | 2016-06-22 | 2020-05-05 | Cisco Technology, Inc. | Domain name system identification and attribution |
| US10110614B2 (en) * | 2016-07-28 | 2018-10-23 | Verisign, Inc. | Strengthening integrity assurances for DNS data |
| WO2018140794A1 (fr) * | 2017-01-27 | 2018-08-02 | Level 3 Communications, Llc | Système et procédé de nettoyage de dns dans un réseau de télécommunications afin de diminuer des attaques |
| US10979387B2 (en) * | 2018-09-04 | 2021-04-13 | Level 3 Communications, Llc | Systems and methods for utilization of anycast techniques in a DNS architecture |
| US10834114B2 (en) * | 2018-12-13 | 2020-11-10 | At&T Intellectual Property I, L.P. | Multi-tiered server architecture to mitigate malicious traffic |
| FR3091096A1 (fr) * | 2018-12-19 | 2020-06-26 | Orange | Procédé de détermination d’une chaîne de délégation associée à une résolution d’un nom de domaine dans un réseau de communication |
-
2018
- 2018-12-19 FR FR1873343A patent/FR3091097A1/fr not_active Withdrawn
-
2019
- 2019-12-11 WO PCT/FR2019/053027 patent/WO2020128238A1/fr unknown
- 2019-12-11 US US17/415,269 patent/US11575644B2/en active Active
- 2019-12-11 CN CN201980083518.7A patent/CN113196722A/zh active Pending
- 2019-12-11 EP EP19839392.8A patent/EP3900305A1/fr active Pending
Patent Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20120185370A1 (en) * | 2011-01-14 | 2012-07-19 | Cisco Technology, Inc. | System and method for tracking request accountability in multiple content delivery network environments |
| US8909736B1 (en) * | 2012-07-12 | 2014-12-09 | Juniper Networks, Inc. | Content delivery network referral |
| WO2018115647A1 (fr) * | 2016-12-23 | 2018-06-28 | Orange | Validation de livraison de contenu et de verification d'une delegation de livraison d'un contenu |
| WO2018130796A1 (fr) * | 2017-01-16 | 2018-07-19 | Orange | Procédés et dispositifs de vérification de la validité d'une délégation de diffusion de contenus chiffrés |
Non-Patent Citations (2)
| Title |
|---|
| FIEAU F ET AL: "Limited Use of Remote Keys for Interconnected CDNs; draft-cdni-fieau-lurk-https-delegation-00.txt", LIMITED USE OF REMOTE KEYS FOR INTERCONNECTED CDNS; DRAFT-CDNI-FIEAU-LURK-HTTPS-DELEGATION-00.TXT, INTERNET ENGINEERING TASK FORCE, IETF; STANDARDWORKINGDRAFT, INTERNET SOCIETY (ISOC) 4, RUE DES FALAISES CH- 1205 GENEVA, SWITZERLAND, 8 July 2016 (2016-07-08), pages 1 - 17, XP015114144 * |
| TRAMMELL ETH ZURICH B: "RAINS (Another Internet Naming Service) Protocol Specification; draft-trammell-rains-protocol-03.txt", RAINS (ANOTHER INTERNET NAMING SERVICE) PROTOCOL SPECIFICATION; DRAFT-TRAMMELL-RAINS-PROTOCOL-03.TXT; INTERNET-DRAFT: NETWORK WORKING GROUP, INTERNET ENGINEERING TASK FORCE, IETF; STANDARDWORKINGDRAFT, INTERNET SOCIETY (ISOC) 4, RUE DES FALAISES CH-, no. 3, 20 September 2017 (2017-09-20), pages 1 - 51, XP015121907 * |
Also Published As
| Publication number | Publication date |
|---|---|
| US11575644B2 (en) | 2023-02-07 |
| WO2020128238A1 (fr) | 2020-06-25 |
| EP3900305A1 (fr) | 2021-10-27 |
| CN113196722A (zh) | 2021-07-30 |
| US20220029952A1 (en) | 2022-01-27 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| EP2514166B1 (fr) | Accès a un réseau de distribution de contenu numérique | |
| EP1733533B1 (fr) | Procede et systeme de gestion d'autorisation d'acces d'un utilisateur au niveau d'un domaine administratif local lors d'une connexion de l'utilisateur a un reseau ip | |
| EP3568966B1 (fr) | Procédés et dispositifs de délégation de diffusion de contenus chiffrés | |
| EP3568989A1 (fr) | Procédés et dispositifs de vérification de la validité d'une délégation de diffusion de contenus chiffrés | |
| WO2018172707A1 (fr) | Procédé de recommandation d'une pile de communication | |
| EP3560163A1 (fr) | Validation de livraison de contenu et de verification d'une delegation de livraison d'un contenu | |
| WO2020128238A1 (fr) | Procédé d'acquisition d'une chaîne de délégation relative à la résolution d'un identifiant de nom de domaine dans un réseau de communication | |
| EP3900306A1 (fr) | Procédé de détermination d'une chaîne de délégation associée à une résolution d'un nom de domaine dans un réseau de communication | |
| FR2872363A1 (fr) | Procede et systeme de certification de l'identite d'un utilisateur | |
| FR2826812A1 (fr) | Procede et dispositif de securisation des communications dans un systeme informatique | |
| FR3015839A1 (fr) | Procede de ralentissement d'une communication dans un reseau | |
| WO2023083772A1 (fr) | Procédés de contrôle et de transmission, et entités configurées pour mettre en œuvre ces procédés | |
| WO2024083694A1 (fr) | Procédé de traitement d'une requête en résolution d'au moins un identifiant de nommage, dispositif et programme d'ordinateur correspondants | |
| WO2021191536A1 (fr) | Délégation d'une fonction de résolution d'identifiants de nommage | |
| EP4173252A1 (fr) | Procédé de controle d'accès à un contenu mis en oeuvre par un serveur cache | |
| WO2015181484A1 (fr) | Technique d'obtention d'une politique de routage de requêtes émises par un module logiciel s'exécutant sur un dispositif client | |
| WO2007054657A2 (fr) | Procede et dispositif de fourniture d'un identifiant de federation reseau a un fournisseur de service | |
| WO2022096824A1 (fr) | Procede de delegation d'acces a une chaine de blocs | |
| EP2525525B1 (fr) | Procédé, programme d'ordinateur et dispositif de cooptation permettant à un abonné d'un service de partager ce service avec un autre utilisateur | |
| WO2011157928A1 (fr) | Procede et systeme d'acces securise a un serveur http | |
| FR2964524A1 (fr) | Traitement de donnees pour la notification d'un equipement | |
| Wong et al. | Towards Secure Information-centric Naming | |
| EP3643035A1 (fr) | Procédé de contrôle de l'obtention par un terminal d'un fichier de configuration | |
| WO2011023881A1 (fr) | Technique pour evaluer une collaboration entre des noeuds d'un reseau de communication |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PLFP | Fee payment |
Year of fee payment: 2 |
|
| PLSC | Publication of the preliminary search report |
Effective date: 20200626 |
|
| ST | Notification of lapse |
Effective date: 20210806 |