FR2925251A1 - Procedes de gestion de connexion dans un mode de dechargement d'une tete de tunnel, produit programme d'ordinateur, moyen de stockage et tetes de tunnel correspondants - Google Patents

Procedes de gestion de connexion dans un mode de dechargement d'une tete de tunnel, produit programme d'ordinateur, moyen de stockage et tetes de tunnel correspondants Download PDF

Info

Publication number
FR2925251A1
FR2925251A1 FR0759865A FR0759865A FR2925251A1 FR 2925251 A1 FR2925251 A1 FR 2925251A1 FR 0759865 A FR0759865 A FR 0759865A FR 0759865 A FR0759865 A FR 0759865A FR 2925251 A1 FR2925251 A1 FR 2925251A1
Authority
FR
France
Prior art keywords
tunnel
message
head
unloaded
connection
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.)
Granted
Application number
FR0759865A
Other languages
English (en)
Other versions
FR2925251B1 (fr
Inventor
Pascal Rousseau
Falk Tannhauser
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Canon Inc
Original Assignee
Canon Inc
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Canon Inc filed Critical Canon Inc
Priority to FR0759865A priority Critical patent/FR2925251B1/fr
Publication of FR2925251A1 publication Critical patent/FR2925251A1/fr
Application granted granted Critical
Publication of FR2925251B1 publication Critical patent/FR2925251B1/fr
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • 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
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/2803—Home automation networks
    • H04L12/283—Processing of data at an internetworking point of a home automation network
    • H04L12/2834—Switching of information between an external network and a home network
    • 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

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Computer Security & Cryptography (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

Procédé de gestion d'au moins une connexion établie via un tunnel supporté par un réseau de communication principal, ledit tunnel étant mis en oeuvre entre des première et seconde têtes de tunnel connectées respectivement à des premier et second sous-réseaux, chaque connexion permettant une transmission de données entre un dispositif client et un dispositif serveur via ledit tunnel, lesdits dispositif client et serveur étant connectés l'un au premier sous-réseau et l'autre au second sous-réseau. Selon l'invention, le procédé comprend une étape de tentative de basculement dans un mode de déchargement, effectuée par au moins une desdites première et seconde têtes de tunnel, dite tête de tunnel à décharger. Elle s'effectue en sélectionnant (802) au moins un dispositif serveur et/ou client, s'il est connecté au sous-réseau auquel est connectée ladite tête de tunnel à décharger, s'il est impliqué dans une connexion sécurisée par chiffrement et véhiculée par ledit tunnel, et s'il possède une quantité suffisante de ressources de chiffrement/déchiffrement. Puis, pour chaque dispositif sélectionné, une étape de déclenchement (803) d'une négociation d'une connexion sécurisée entre ledit dispositif sélectionné et la tête de tunnel distante de la tête de tunnel à décharger est lancée. En cas de négociation réussie, ladite tête de tunnel à décharger bascule (805) dans un mode de déchargement, de manière à ce qu'elle n'effectue pas d'opération de chiffrement/déchiffrement pour la connexion sécurisée donnée.

Description

Procédés de gestion de connexions dans un mode de déchargement d'une tête de tunnel, produit programme d'ordinateur, moyen de stockage et têtes de tunnel correspondants. 1. DOMAINE DE L'INVENTION Le domaine de l'invention est celui des réseaux de communication. Plus précisément, l'invention concerne une technique d'échange de données dans le cadre d'un mode de déchargement d'une opération de chiffrement sur un tunnel traversant un réseau de communication global. L'invention s'applique notamment, mais non exclusivement, à des dispositifs tels que, par exemple, les systèmes de type home cinéma, les caméscopes, les imprimantes, les appareils photo ou tout autre équipement photo et audio/vidéo numérique pour le grand public. La démocratisation d'Internet haut débit d'une part et l'apparition d'équipements audiovisuels grand public possédant une connectivité réseau d'autre part vont créer de nouveaux comportements des utilisateurs. Parmi ces nouveaux comportements, il fait peu de doute que nous verrons apparaître des individus appartenant à des groupes de personnes partageant des domaines d'intérêts communs (loisirs, famille...) que nous pourrions appeler en liaison permanente . Ceux-ci établiront des connections quasi permanentes avec les autres individus d'un même domaine d'intérêt en établissement des communications audio et/ou vidéo et partageant des informations de tout type (audio, vidéo, photo, texte ...). La technologie des Réseaux Privés Virtuels (RPV, ou VPN pour Virtual Private Network en anglais) offre une solution intéressante pour répondre à cette attente. En effet, elle permet de communiquer de manière transparente en temps réel, de manière sécurisée entre des individus partageant un même domaine d'intérêt tout en utilisant l'infrastructure réseau Internet peu sûr mais bon marché. Les RPVs sont fréquemment utilisés pour interconnecter deux réseaux locaux domestiques (appelés ci-après sous-réseaux ou encore réseaux LAN, pour Local Area Network en anglais) afin de créer un réseau local virtuel composé de l'union des deux réseaux LAN originaux. Il existe de nombreuses technologies pour mettre en oeuvre un RPV. On trouve généralement ces technologies dans les équipements d'infrastructure des réseaux des opérateurs et les passerelles Internet pour le grand public. Ces technologies peuvent être également mises en oeuvre sur un ordinateur à l'aide de logiciels spécifiques, comme par exemple, openVPN, SoftEther, L2TP, etc. Une configuration typique de RPV basée sur une technique de tunnellisation est illustrée sur la figure 1 (et décrite en détail par la suite). Dans cet exemple, les têtes de tunnel ( Tunnel End Point en anglais) ne sont pas intégrées aux passerelles. Le tunnel est établi entre deux têtes de tunnel, et chaque paquet de données envoyé à un équipement connecté au réseau LAN distant est encapsulé par la tête de tunnel locale, puis envoyé à la tête de tunnel distante qui va le désencapsuler et l'envoyer sur le réseau LAN distant. Les équipements de ces réseaux LAN sont virtuellement connectés à un même réseau LAN. Une communication entre deux équipements via le tunnel est appelée communication de bout en bout ( end-to-end communication en anglais). Pour communiquer de manière transparente et s'affranchir des adresses non routables, les RPVs utilisent une encapsulation particulière nommée tunnellisation ( tunneling en anglais) qui crée ce que l'on appelle un tunnel. Cette opération consiste à encapsuler un protocole de niveau A (protocole embarqué) dans un protocole de niveau B (protocole de transport) grâce à un protocole d'encapsulation C, B étant de niveau supérieur à A dans un modèle en couche tel le modèle OSI (pour Open Systems Interconnection en anglais) qui décrit les services offerts par chacune de ces couches et leurs interactions. Par ailleurs, afin d'assurer la sécurité et la confidentialité des communications transitant sur le tunnel employant l'infrastructure Internet, les protocoles de sécurisation sont communément utilisés. Le protocole TLS (pour Transport Layer Security en anglais), anciennement nommé SSL (pour Secure Socket Layer en anglais) constitue un exemple de protocole largement utilisé à cette fin. Il fonctionne suivant un mode client/serveur, fournissant quatre objectifs de sécurité : une authentification du serveur, une confidentialité des données échangées (ou session chiffrée), une intégrité des données échangées, et de manière optionnelle, une authentification du client avec l'utilisation d'un certificat numérique.
Une session TLS est établie à l'initiative du client et débute par une phase d'authentification et de négociation de l'algorithme et des clés de chiffrement à utiliser au cours de la session. Le chiffrement par la source des informations à transmettre, ainsi que le déchiffrement correspondant par la destination sont des éléments centraux du protocole TLS. Il est à noter que le chiffrement et le déchiffrement sont des opérations relativement coûteuses en termes de ressources CPU, ceci d'autant plus que le débit de la transmission chiffrée est élevé. Il est à noter que les applications audio/vidéo modernes, c'est-à-dire de haute définition, nécessitent des débits élevés ainsi que des faibles délais de transmission. 2. ARRIÈRE-PLAN TECHNOLOGIQUE Au sein d'un réseau local, un équipement de type tête de tunnel est typiquement responsable de la gestion de plusieurs flux de données encapsulés dans des tunnels, en provenance ou à destination des équipements audio/vidéo ou de traitement de données situés sur un ou multiples réseaux distants. Lors de l'approche classique, consistant à établir une connexion sécurisée de type TLS entre les têtes de tunnel situées sur leurs réseaux respectifs pour chacun des tunnels actifs, lesdites têtes de tunnel se retrouvent avec la charge des ressources CPU correspondant aux opérations de chiffrement et de déchiffrement associées à la totalité des flux de données actifs de manière simultanée. Ainsi, lesdites têtes de tunnel se retrouvent à traiter une quantité importante de données (on parle alors de goulet d'étranglement ), ce qui engendre une détérioration de la vitesse de transmission des données audio/vidéo à haut débit.
Afin de décongestionner lesdites têtes de tunnel et d'augmenter la quantité de données hauts débits capables d'être traitées par celles-ci, une première solution classique consiste à accroître la capacité de calcul desdites têtes de tunnel. Cette solution entraîne cependant une augmentation du coût d'un tel équipement et sa consommation en énergie. 3. OBJECTIFS DE L'INVENTION L'invention, dans au moins un mode de réalisation, a notamment pour objectif de pallier ces différents inconvénients de l'état de la technique. Plus précisément, dans au moins un mode de réalisation de l'invention, un objectif est de fournir une technique de gestion de connexions via un tunnel permettant de reporter les ressources de chiffrement/déchiffrement liées à la gestion de connexions sécurisées d'une tête de tunnel sur un dispositif terminal afin de décharger la tête de tunnel. Un autre objectif d'au moins un mode de réalisation de l'invention est de réduire la dégradation des performances d'un équipement terminal incorporant une tête de tunnel embarquée. Au moins un mode de réalisation de l'invention a également pour objectif de fournir une telle technique offrant la capacité de router un nombre de flux de données supplémentaire sur un tunnel. Plus particulièrement, un objectif est de réduire les délais d'échange de données sur un tunnel.
Un objectif complémentaire d'au moins un mode de réalisation de l'invention est de fournir une telle technique qui soit simple à mettre en oeuvre et peu coûteuse. 4. EXPOSÉ DE L'INVENTION Dans un mode de réalisation particulier de l'invention, il est proposé un procédé de gestion d'au moins une connexion établie via un tunnel supporté par un réseau de communication principal, ledit tunnel étant mis en oeuvre entre des première et seconde têtes de tunnel connectées respectivement à des premier et second sous-réseaux, chaque connexion permettant une transmission de données entre un dispositif client et un dispositif serveur via ledit tunnel, ledit dispositif client et ledit dispositif serveur étant connectés l'un au premier sous-réseau et l'autre au second sous-réseau. Selon l'invention, le procédé comprend une étape de tentative de basculement dans un mode de déchargement qui est effectuée par au moins une desdites première et seconde têtes de tunnel, dite tête de tunnel à décharger. L'étape de tentative de basculement comprend les étapes suivantes : sélection d'au moins un dispositif serveur et/ou au moins un dispositif client, dit dispositif sélectionné, tel que : il est connecté au sous-réseau auquel est connectée ladite tête de tunnel à décharger, il est impliqué dans une connexion sécurisée par chiffrement et véhiculée par ledit tunnel, ladite connexion étant établie ou à établir, et il possède une quantité suffisante de ressources de chiffrement/déchiffrement ; - pour chaque dispositif sélectionné, déclenchement d'une négociation d'une connexion sécurisée entre ledit dispositif sélectionné et la tête de tunnel distante de la tête de tunnel à décharger ; - en cas de négociation réussie pour une connexion sécurisée donnée, basculement de ladite tête de tunnel à décharger dans un mode de déchargement, pour ladite connexion sécurisée donnée, le mode de déchargement étant tel que ladite tête de tunnel à décharger n'effectue pas d'opération de chiffrement/déchiffrement pour ladite connexion sécurisée donnée. Le principe général de l'invention, côté tête de tunnel à décharger, consiste donc à effectuer, pour une connexion donnée, une tentative de basculement dans un mode de déchargement en sélectionnant un dispositif terminal capable de prendre en charge, à la place de cette tête de tunnel à décharger, les ressources liées aux opérations de chiffrement/déchiffrement. Ainsi, dans ce mode de réalisation particulier, l'invention repose sur une approche tout à fait nouvelle et inventive consistant à reporter la charge CPU liée aux opérations de chiffrement de la tête de tunnel à décharger sur un dispositif terminal, lorsque cela s'avère possible, afin de décharger cette tête de tunnel à décharger. De cette façon, la tête de tunnel à décharger, se libérant de telles ressources, est capable dorénavant de prendre en charge des paquets de données supplémentaires et donc de traiter un nombre plus important de flux à haut débit. De façon avantageuse, ladite étape de tentative de basculement est effectuée sur détection d'un évènement appartenant au groupe comprenant : - ouvertures d'une nouvelle connexion sur ledit tunnel ; - détections d'une limitation de ressources de chiffrement/déchiffrement de ladite tête de tunnel à décharger. Les critères d'exécution de la tentative de basculement peuvent être basés sur un ou plusieurs éléments combinés de cette liste. Par ailleurs, cette liste n'est pas exhaustive. Il est à noter que l'étape de détection de limitation de ressources est basée sur une comparaison avec un seuil CPU préalablement déterminé.
Avantageusement, ladite étape de déclenchement d'une négociation comprend une étape d'envoi d'une requête de négociation à ladite tête de tunnel distante. Ainsi, l'envoi d'une requête de négociation à la tête de tunnel distante permet de signaler à celle-ci qu'une négociation pour l'établissement d'une connexion sécurisée, entre le dispositif sélectionné et la tête de tunnel à décharger, va être testée. Selon une caractéristique avantageuse, si après une première itération de ladite étape de tentative de basculement, effectuée par l'une desdites première et seconde têtes de tunnel, dite tête de tunnel à décharger de première itération, ladite tête de tunnel à décharger de première itération a basculé dans ledit mode de déchargement pour au moins une connexion sécurisée donnée, dite connexion sécurisée de première itération, impliquant au moins un dispositif sélectionné donné, dit dispositif sélectionné de première itération, alors dans une seconde itération de ladite étape de tentative de basculement, effectuée par l'autre desdites première et seconde têtes de tunnel : * si ladite étape de sélection sélectionne au moins un dispositif serveur et/ou au moins un dispositif client impliqué dans ladite connexion sécurisée de première itération, * alors ladite étape de déclenchement d'une négociation comprend une étape d'envoi d'une requête de négociation audit dispositif sélectionné de première itération pour ladite connexion sécurisée de première itération.
Ainsi, lorsqu'une desdites première et seconde têtes de tunnel effectue une tentative de basculement dans le mode de déchargement (tête de tunnel à décharger), et que l'autre desdites première et seconde têtes de tunnel a préalablement déjà basculé dans le mode de déchargement, alors l'envoi d'une requête de négociation pour le déclenchement d'une négociation n'est plus envoyé à la tête de tunnel distante, mais directement au dispositif sélectionné, visant à établir une connexion sécurisée de bout en bout, c'est-à-dire entre le client et le serveur. En effet, la tête de tunnel ayant déjà basculé dans le mode de déchargement pour une connexion donnée, ne peut donc plus recevoir la requête de négociation, comme dans le cas précédent. Cette connexion va donc, pour ce mode de réalisation particulier de l'invention, subir une transformation visant à ce que ce soit le dispositif terminal distant de la tête de tunnel à décharger qui se 10 15 20 25 30 charge de recevoir la requête de négociation à la place de la tête de tunnel qui a préalablement basculé dans le mode de déchargement. Avantageusement, ladite tête de tunnel à décharger, quand elle fonctionne dans le mode de déchargement pour une connexion sécurisée donnée, effectue les étapes 5 suivantes : - lors de la réception d'un message de la tête de tunnel distante sur le tunnel : * désencapsulation dudit message, en enlevant un premier en-tête servant à véhiculer ledit message entre les têtes de tunnel, permettant d'obtenir un message désencapsulé ; * retransmission du message désencapsulé sur le sous-réseau auquel est connectée ladite tête de tunnel à décharger, à destination du dispositif sélectionné pour ladite connexion sécurisée donnée ; - lors de la réception d'un message issu du dispositif sélectionné pour ladite connexion sécurisée donnée : * encapsulation dudit message en le précédant d'un premier en-tête servant à véhiculer ledit message entre les têtes de tunnel, permettant d'obtenir un message encapsulé ; * retransmission du message encapsulé sur le tunnel, à destination de la tête de tunnel distante. En effet, suite au basculement dans le mode de déchargement, lors de la réception des messages sur la tête de tunnel à décharger, cette dernière effectue alors une reconfiguration des moyens d'encapsulation qui dépend de la provenance des messages pour une connexion sécurisée donnée. Ce traitement particulier permet de véhiculer les messages sur le tunnel. Dans une variante, ladite tête de tunnel à décharger, quand elle fonctionne dans ledit mode de déchargement pour une connexion sécurisée donnée, effectue les étapes suivantes : - lors de la réception d'un message de la tête de tunnel distante sur le tunnel, ladite étape de retransmission du message est précédée de l'étape suivante : * déchiffrement d'un second en-tête appartenant au message désencapsulé, en utilisant une clé spécifique négociée préalablement avec la tête de tunnel distante lors de l'établissement du tunnel, ledit second en-tête servant à véhiculer ledit message sur lesdits premier et second sous-réseaux ; lors de la réception d'un message issu du dispositif sélectionné pour ladite connexion sécurisée donnée, ladite étape d'encapsulation est précédée de l'étape suivante : * chiffrement d'un second en-tête dudit message, en utilisant une clé spécifique négociée préalablement avec la tête de tunnel distante lors de l'établissement du tunnel, ledit second en-tête servant à véhiculer ledit message sur lesdits premier et second sous-réseaux.
Dans un autre mode de réalisation de l'invention, il est proposé un procédé de gestion d'au moins une connexion établie via un tunnel supporté par un réseau de communication principal, ledit tunnel étant mis en oeuvre entre des première et seconde têtes de tunnel connectées respectivement à des premier et second sous-réseaux, chaque connexion permettant une transmission de données entre un dispositif client et un dispositif serveur via ledit tunnel, ledit dispositif client et ledit dispositif serveur étant connectés l'un au premier sous-réseau et l'autre au second sous-réseau. Selon l'invention, le procédé comprend les étapes suivantes, effectuées par au moins une desdites première et seconde têtes de tunnel, dite tête de tunnel distante, la tête de tunnel autre que la tête de tunnel distante étant appelée tête de tunnel à décharger : - négociation d'une connexion sécurisée avec un dispositif sélectionné par ladite tête de tunnel à décharger ; - en cas de négociation réussie, pour ladite connexion sécurisée, basculement de ladite tête de tunnel distante dans un mode de mandataire de sécurisation ( proxy TLS ), le mode de mandataire de sécurisation étant tel que ladite tête de tunnel distante effectue des opérations de chiffrement/déchiffrement pour ladite connexion sécurisée donnée en relation avec ledit dispositif sélectionné. Ainsi, vu du côté tête de tunnel distante, le principe consiste à effectuer une négociation d'une connexion sécurisée avec un dispositif sélectionné par la tête de tunnel distante permettant de la basculer dans un mode de mandataire de sécurisation.
Avantageusement, ladite étape de négociation est effectuée après une étape d'une réception d'une requête de négociation provenant de ladite tête de tunnel à décharger.
Avantageusement, ladite tête de tunnel distante, quand elle fonctionne dans le mode de mandataire de sécurisation pour une connexion sécurisée donnée, effectue les étapes suivantes - lors de la réception d'un message de la tête de tunnel à décharger sur le tunnel : * désencapsulation dudit message, en enlevant un premier en-tête servant à véhiculer ledit message entre les têtes de tunnel, permettant d'obtenir un message désencapsulé ; * déchiffrement d'une charge utile appartenant au message désencapsulé, en utilisant une clé spécifique négociée préalablement avec le dispositif sélectionné lors de ladite étape de négociation, permettant d'obtenir un message déchiffré ; * retransmission du message déchiffré sur le sous-réseau auquel est connectée ladite tête de tunnel distante, à destination d'un dispositif client ou serveur ; - lors de la réception d'un message issu d'un dispositif client ou serveur : * chiffrement d'une charge utile dudit message, en utilisant une clé spécifique négociée préalablement avec le dispositif sélectionné lors de ladite étape de négociation, permettant d'obtenir un message chiffré ; * encapsulation dudit message chiffré en le précédant d'un premier en-tête servant à véhiculer ledit message chiffré entre les têtes de tunnel, permettant 20 d'obtenir un message encapsulé ; * retransmission du message encapsulé sur le tunnel, à destination de la tête de tunnel à décharger. Dans une variante, ladite tête de tunnel distante, quand elle fonctionne dans le mode de mandataire de sécurisation pour une connexion sécurisée donnée, effectue les 25 étapes suivantes - lors de la réception d'un message de la tête de tunnel à décharger sur le tunnel, ladite étape de retransmission du message déchiffré est précédée de l'étape suivante * déchiffrement d'un second en-tête appartenant au message désencapsulé, en 30 utilisant une clé spécifique négociée préalablement avec la tête de tunnel à décharger lors de l'établissement du tunnel, ledit second en- tête servant à 10 15 véhiculer ledit message déchiffré sur lesdits premier et second sous-réseaux ; - lors de la réception d'un message issu d'un dispositif client ou serveur, ladite étape d'encapsulation est précédée de l'étape suivante : * chiffrement d'un second en-tête dudit message chiffré, en utilisant une clé spécifique négociée préalablement avec la tête de tunnel à décharger lors de l'établissement du tunnel, ledit second en-tête servant à véhiculer ledit message chiffré sur lesdits premier et second sous-réseaux. Dans un autre mode de réalisation, l'invention concerne un produit programme d'ordinateur téléchargeable depuis un réseau de communication et/ou enregistré sur un support lisible par ordinateur et/ou exécutable par un processeur, ledit produit programme d'ordinateur comprenant des instructions de code de programme pour la mise en oeuvre du procédé précité (dans au moins un des modes de réalisation), lorsque ledit programme est exécuté sur un ordinateur.
Dans un autre mode de réalisation, l'invention concerne un moyen de stockage, éventuellement totalement ou partiellement amovible, lisible par un ordinateur, stockant un jeu d'instructions exécutables par ledit ordinateur pour mettre en oeuvre le procédé précité (dans au moins un des modes de réalisation). Dans un autre mode de réalisation, l'invention concerne une tête de tunnel à décharger destinée à la gestion d'au moins une connexion établie via un tunnel supporté par un réseau de communication principal, ledit tunnel étant mis en oeuvre entre des première et seconde têtes de tunnel connectées respectivement à des premier et second sous-réseaux, ladite tête de tunnel à décharger étant l'une desdites première et seconde têtes de tunnel, chaque connexion permettant une transmission de données entre un dispositif client et un dispositif serveur via ledit tunnel, ledit dispositif client et ledit dispositif serveur étant connectés l'un au premier sous-réseau et l'autre au second sous-réseau. Selon l'invention, ladite tête de tunnel à décharger comprend des moyens de tentative de basculement dans un mode de déchargement, lesdits moyens de tentative de basculement comprenant : - des moyens de sélection d'au moins un dispositif serveur et/ou au moins un dispositif client, dit dispositif sélectionné, tel que : il est connecté au sous-réseau auquel est connectée ladite tête de tunnel à décharger, il est impliqué dans une connexion sécurisée par chiffrement et véhiculée par ledit tunnel, ladite connexion étant établie ou à établir, et il possède une quantité suffisante de ressources de chiffrement/déchiffrement ; - des moyens de déclenchement, pour chaque dispositif sélectionné, d'une négociation d'une connexion sécurisée entre ledit dispositif sélectionné et la tête de tunnel distante de la tête de tunnel à décharger ; et - des moyens de basculement, en cas de négociation réussie pour une connexion sécurisée donnée, de ladite tête de tunnel à décharger dans un mode de déchargement, le mode de déchargement étant tel que ladite tête de tunnel à décharger n'effectue pas d'opération de chiffrement/déchiffrement pour ladite connexion sécurisée donnée. De façon avantageuse, la tête de tunnel à décharger comprend des moyens de détection d'un évènement appartenant au groupe comprenant : - ouvertures d'une nouvelle connexion sur ledit tunnel ; - détections d'une limitation de ressources de chiffrement/déchiffrement de ladite tête de tunnel à décharger, et lesdits moyens de tentative de basculement sont activés si lesdits moyens de détection détectent un événement. Selon une caractéristique avantageuse, lesdits moyens de déclenchement d'une négociation comprennent des moyens d'envoi d'une requête de négociation à ladite tête de tunnel distante. Avantageusement, la tête de tunnel à décharger comprend, pour la mise en oeuvre dudit mode de déchargement pour une connexion sécurisée donnée : - des premiers moyens de traitement d'un message de la tête de tunnel distante sur le tunnel, comprenant eux-mêmes : * des moyens de désencapsulation dudit message, en enlevant un premier en-tête servant à véhiculer ledit message entre les têtes de tunnel, permettant d'obtenir un message désencapsulé ; * des moyens de retransmission du message désencapsulé sur le sous-réseau auquel est connectée ladite tête de tunnel à décharger, à destination du dispositif sélectionné pour ladite connexion sécurisée donnée ; - des seconds moyens de traitement d'un message issu du dispositif sélectionné pour ladite connexion sécurisée donnée, comprenant eux-mêmes : * des moyens d'encapsulation dudit message en le précédant d'un premier en-tête servant à véhiculer ledit message entre les têtes de tunnel, permettant d'obtenir un message encapsulé ; * des moyens de retransmission du message encapsulé sur le tunnel, à destination de la tête de tunnel distante. Dans une variante, la tête de tunnel à décharger comprend, pour la mise en oeuvre dudit mode de déchargement pour une connexion sécurisée donnée : -lorsque lesdits premiers moyens de traitement sont activés : * des moyens de déchiffrement d'un second en-tête appartenant au message désencapsulé, en utilisant une clé spécifique négociée préalablement avec la tête de tunnel distante lors de l'établissement du tunnel, ledit second en-tête servant à véhiculer ledit message sur lesdits premier et second sous-réseaux ; - lorsque lesdits seconds moyens de traitement sont activés : * des moyens de chiffrement d'un second en-tête dudit message, en utilisant une clé spécifique négociée préalablement avec la tête de tunnel distante lors de l'établissement du tunnel, ledit second en-tête servant à véhiculer ledit message sur lesdits premier et second sous-réseaux.
Dans un autre mode de réalisation de l'invention, il est proposé une tête de tunnel distante destiné à la gestion d'au moins une connexion établie via un tunnel supporté par un réseau de communication principal, ledit tunnel étant mis en oeuvre entre des première et seconde têtes de tunnel connectées respectivement à des premier et second sous-réseaux, chaque connexion permettant une transmission de données entre un dispositif client et un dispositif serveur via ledit tunnel, ledit dispositif client et ledit dispositif serveur étant connectés l'un au premier sous-réseau et l'autre au second sous-réseau, la tête de tunnel autre que la tête de tunnel distante étant appelée tête de tunnel à décharger. Selon l'invention, ladite tête de tunnel distante comprend : - des moyens de négociation d'une connexion sécurisée avec un dispositif sélectionné par ladite tête de tunnel à décharger ; - des moyens de basculement, en cas de négociation réussie pour ladite connexion sécurisée, de ladite tête de tunnel distante dans un mode de mandataire de sécurisation ( proxy TLS ), le mode de mandataire de sécurisation étant tel que ladite tête de tunnel distante effectue des opérations de chiffrement/déchiffrement pour ladite connexion sécurisée donnée en relation avec ledit dispositif sélectionné. Avantageusement, la tête de tunnel distante comprend des moyens de réception d'une requête de négociation provenant de ladite tête de tunnel à décharger. Lesdits moyens de négociation sont activés sur réception d'une requête de négociation par lesdits moyens de réception. Avantageusement, la tête de tunnel distante comprend, pour la mise en oeuvre dudit mode de mandataire de sécurisation pour une connexion sécurisée donnée : - des premiers moyens de traitement d'un message de la tête de tunnel à décharger sur le tunnel, comprenant eux-mêmes : * des moyens de désencapsulation dudit message, en enlevant un premier en-tête servant à véhiculer ledit message entre les têtes de tunnel, permettant d'obtenir un message désencapsulé ; * des moyens de déchiffrement d'une charge utile appartenant au message désencapsulé, en utilisant une clé spécifique négociée préalablement avec le dispositif sélectionné lors de ladite étape de négociation, permettant d'obtenir un message déchiffré ; * des moyens de retransmission du message déchiffré sur le sous-réseau auquel est connectée ladite tête de tunnel distante, à destination d'un dispositif client ou serveur ; - des seconds moyens de traitement d'un message issu d'un dispositif client ou serveur, comprenant eux-mêmes : * des moyens de chiffrement d'une charge utile dudit message, en utilisant une clé spécifique négociée préalablement avec le dispositif sélectionné lors de ladite étape de négociation, permettant d'obtenir un message chiffré ; 20 25 5 10 15 25 30 * des moyens d'encapsulation dudit message chiffré en le précédant d'un premier en-tête servant à véhiculer ledit message chiffré entre les têtes de tunnel, permettant d'obtenir un message encapsulé ; * des moyens de retransmission du message encapsulé sur le tunnel, à destination de la tête de tunnel à décharger. Dans une variante, la tête de tunnel distante comprend, pour la mise en oeuvre dudit mode de mandataire de sécurisation pour une connexion sécurisée donnée : - lorsque lesdits premiers moyens de traitement sont activés : * des moyens de déchiffrement d'un second en-tête appartenant au message désencapsulé, en utilisant une clé spécifique négociée préalablement avec la tête de tunnel à décharger lors de l'établissement du tunnel, ledit second en-tête servant à véhiculer ledit message déchiffré sur lesdits premier et second sous-réseaux ; - lorsque lesdits seconds moyens de traitement sont activés : * des moyens de chiffrement d'un second en-tête dudit message chiffré, en utilisant une clé spécifique négociée préalablement avec la tête de tunnel à décharger lors de l'établissement du tunnel, ledit second en-tête servant à véhiculer ledit message chiffré sur lesdits premier et second sous-réseaux. 5. LISTE DES FIGURES D'autres caractéristiques et avantages de modes de réalisation de l'invention apparaîtront à la lecture de la description suivante, donnée à titre d'exemple indicatif et non limitatif (tous les modes de réalisation de l'invention ne sont pas limités aux caractéristiques et avantages des modes de réalisation décrits ci-après), et des dessins annexés, dans lesquels : - la figure 1 représente une configuration typique de réseau privé virtuel (RPV) mettant en oeuvre un tunnel ; - la figure 2 présente un exemple de modèle (OSI) en couche classique d'une tête de tunnel dans laquelle peut être mis en oeuvre le procédé selon l'invention ; - la figure 3 présente la structure d'un appareil de communication (type tête de tunnel), selon un mode de réalisation particulier de l'invention ; - la figure 4 présente une séquence simplifiée de messages échangés dans le cadre d'un déchargement d'une tête de tunnel associée à un serveur, selon un mode de réalisation particulier de l'invention ; - la figure 5 présente une séquence simplifiée de messages échangés dans le cadre d'un déchargement d'une tête de tunnel associée à un client, selon un mode de réalisation particulier de l'invention ; - la figure 6 présente une séquence simplifiée de messages échangés dans le cadre d'un déchargement de bout en bout, selon un mode de réalisation particulier de l'invention ; - la figure 7 présente un organigramme d'un algorithme de détection de limitation de ressources, selon un mode de réalisation particulier du procédé selon l'invention ; -la figure 8 présente un organigramme d'un mode de réalisation particulier du procédé de gestion de connexions selon l'invention ; - la figure 9 présente un organigramme d'un algorithme de sélection d'un dispositif terminal, selon un mode de réalisation particulier du procédé selon l'invention ; - la figure 10 présente un organigramme d'un algorithme de négociation pour l'établissement d'une connexion sécurisée, selon un mode de réalisation particulier du procédé selon l'invention ; et - chacune des figures l la, l lb et l le représente un organigramme d'un mode de fonctionnement particulier mis en oeuvre par les têtes de tunnel selon l'invention (la figure lla illustrant le mode tunnel, la figure llb illustrant le mode de déchargement et la f i g u r e l l c illustrant le mode proxy TLS). 25 6. DESCRIPTION DÉTAILLÉE Sur toutes les figures du présent document, les éléments et étapes identiques sont désignés par une même référence numérique. La figure 1 représente une configuration typique de réseau privé virtuel (VPN) dans laquelle peut être mise en oeuvre l'invention. Elle présente un tunnel 100 entre une 30 tête de tunnel locale 101 et une tête de tunnel distante 102, à travers un réseau de communication 107 de type Internet par exemple. Ce tunnel 100 interconnecte deux 10 15 20 sous-réseaux : LAN A 103 et LAN B 104. Chacun des sous-réseaux 113 et 104 comporte un équipement d'accès Internet haut débit (passerelle domestique, ou Home Gateway , pouvant intégrer un pare-feu ( Firewall 105 et 106, des équipements terminaux de type client tels que des PC 109 et 111 ou des dispositifs de restitutions des médias numériques 108 et 112, ainsi que des équipements terminaux de type serveur 110 et 113 permettant le stockage et le partage des media numériques (de type audio, vidéo, photo). Une tête de tunnel peut être intégrée dans un équipement audiovisuel comme un téléviseur numérique. Elle peut aussi être présente dans un équipement de type PC sous la forme d'un programme réalisant les fonctions associées à celle-ci.
Une fois que le tunnel 100 est établi, les équipements 108, 109, et 110, connectés au sous-réseau LAN A 103, sont capables de communiquer avec les équipements 111, 112 et 113, connectés au sous-réseau LAN B 104. Par exemple, le client 108 connecté au sous-réseau LAN A 103 peut communiquer avec le serveur 113 connecté au sous-réseau LAN B 104.
Dans cette figure 1, on a représenté un réseau de communication simple avec un seul tunnel, mais il est bien entendu qu'une même tête de tunnel peut être amenée à gérer une pluralité de tunnels (à destination d'autant de têtes de tunnel distantes) pour interconnecter un premier sous-réseau LAN à plusieurs autres sous-réseaux LAN, ainsi qu'une pluralité de connexions. En outre, dans un souci de simplification, n'ont pas été représentés les équipements d'infrastructure dans le réseau Internet tels que les routeurs Internet. En relation avec la figure 2, on présente maintenant le cheminement d'une trame Ethernet issue d'un des équipements 108, 109, 110, connectés au sous-réseau LAN B 103, et entrant dans le tunnel 100. Pour ce faire, on utilise un modèle en couche décrivant les couches de protocoles nécessaires à la mise en oeuvre de ce tunnel 100. Dans ce modèle ne sont pas représentés les éléments de protocole nécessaire aux fonctions autres que la mise en oeuvre du tunnel. Par exemple, ne sont pas représentés les éléments de protocole associés à une architecture UPnP lorsqu'une tête de tunnel 101 est intégrée dans un équipement UPnP.
La tête de tunnel 101 comporte une interface physique Ethernet 208 qui remet les trames Ethernet issues des équipements 108, 109, 110 à la couche liaison 207 pour routage : vers la couche réseau 206, pour les trames Ethernet à destination de l'équipement comportant la tête de tunnel, ou vers la couche de pont ( bridge en anglais) 209, pour les autres trames Ethernet. La couche de pont 209 réalise les opérations classiques d'un pont Ethernet telles que le filtrage des trames Ethernet et le relais de ces trames vers le ou les port(s) Ethernet de sortie approprié(s). Sur le pont sont attachées une interface Ethernet 207 et au moins une interface virtuelle 210 simulant un contrôleur Ethernet. Une interface virtuelle 210 est créée pour chaque tunnel instancié par l'application 200 à qui elle remet les trames Ethernet qui doivent transiter sur les tunnels respectivement instanciés. D'une manière générale, le protocole d'encapsulation du tunnel représenté par l'application 200 réalise les opérations nécessaires à la mise en oeuvre de chaque tunnel, parmi lesquelles on trouvera notamment la configuration, le filtrage, l'encapsulation c'est-à-dire, la formation d'un paquet tunnel, et l'extraction d'une trame. Les trames reçues de l'interface virtuelle 210, après traitement par l'application 200, sont remises sous la forme d'un paquet à travers une interface applicative ( socket en anglais) 201 à un protocole de transport fiable TCP 203 ou non fiable UDP 205, respectivement sécurisés par les protocoles SSL 202 et DTLS 204. Après traitement par un protocole de transport pour former le paquet tunnel 250, on passe celui-ci à la couche réseau 206. Le datagramme IP ainsi formé avec le paquet tunnel peut maintenant être transmis sur le sous-réseau LAN à travers les couches liaison 207 et physique 208. La réception d'une trame en provenance du tunnel 100 suivra dans la tête de tunnel le cheminement inverse à celui présenté ci-dessus. On présente maintenant, en relation avec la figure 3, la structure schématique d'un dispositif de communication 300, telle qu'une tête de tunnel 101 ou 102 représentée sur la figure 1 mettant en oeuvre la technique de l'invention. Ce dispositif comprend une RAM 302 qui fonctionne comme une mémoire principale, une zone de travail, etc., de l'unité centrale (CPU) 301. L'unité centrale 301 est capable, à la mise sous tension de l'appareil de communication, d'exécuter des instructions à partir de la ROM de programme 303. Après la mise sous tension, l'unité centrale 301 est capable d'exécuter des instructions provenant de la mémoire principale 302 en relation avec une application logicielle après que ces instructions aient été chargées à partir de la ROM de programme 303 ou du disque dur 306 (ou un moyen de stockage amovible tel que par exemple une disquette, un CD- ROM ou un DVD-ROM (non représenté)). Une telle application logicielle, lorsqu'elle est exécutée par l'unité centrale 301, provoque la réalisation de tout ou en partie des étapes des organigrammes illustrés sur les figures 7, 8, 9, 10, 11a, l l b et 11c. On notera que l'invention ne se limite pas à une implantation purement logicielle (comme décrit ci-dessus) mais qu'elle peut aussi être mise en oeuvre sous une forme d'une matérielle ou toute forme mixant une partie matérielle et une partie logicielle.
On présente maintenant, en relation avec la figure 4, une séquence simplifiée de gestion de connexions entre un client 108, un serveur 113 et leurs têtes de tunnel 101 et 102 respectives, lorsqu'une connexion entre le client et le serveur employant le tunnel est modifiée de manière à décharger la tête de tunnel 102 associée au serveur 113 des opérations de chiffrement, suivant le procédé conforme à la présente invention. À l'état initial, il existe une connexion IP entre le client 108 et le serveur 113, non sécurisée au niveau des sous-réseaux respectifs 103 et 104, véhiculée par l'Internet 107 via un tunnel 100 établi entre les deux têtes de tunnel respectives 101 et 102. Les paquets de données 301 échangés entre le serveur 113 et le client 108 et transitant sur les sous-réseaux respectifs 104 et 103 comportent alors un en-tête IP et une charge utile ( payload en anglais). De préférence, l'encapsulation au niveau du tunnel 100 s'effectue de la manière classique décrite dans le document IETF RFC 3931 ("Layer two tunneling protocol ù version 3 (L2TPv3)", J. Lau and ail, March 2005) et la connexion du tunnel entre les têtes de tunnel 101 et 102 est une connexion TCP/IP sécurisée conforme au protocole TLS, conformément au document IETF RFC 4346 ("The Transport Layer Security (TLS) Protocol -Version 1.1", T. Dierks, E. Rescorla, April 2006). Sur le tunnel, chaque paquet de données 301 en provenance du client 108 respectivement du serveur 113 est alors encapsulé par leur tête de tunnel respective dans un paquet de données 302 comportant : - un en-tête de tunnel TH (pour Tunnel Header en anglais) ; plus précisément, il s'agit des en-têtes de la connexion TCP/IP de tunnel entre les têtes de tunnel 101 et 102, ainsi que des champs de signalisation ; - un en-tête TLS (pour Transport Layer Security ); - le paquet de données d'origine 301, correspondant à la charge utile ( payload ), chiffré par la tête de tunnel émettrice conformément au protocole TLS.
Ledit paquet de données 302 est ensuite désencapsulé et déchiffré par la tête de tunnel réceptrice, de manière à restituer le paquet de données 301 d'origine. Ce dernier est ensuite retransmis sur le sous-réseau associé à la tête de tunnel réceptrice, à destination de l'équipement serveur 113 respectivement client 108. Suite à une détection de limitation de ressources (cf. figure 8) ou à une ouverture d'une nouvelle connexion sur le tunnel, la tête de tunnel 102 associée au serveur 113, se lance dans une tentative de basculement dans un mode de déchargement (tel que décrit par la figure 8) en sélectionnant tout d'abord le serveur 113 (cf. figure 9), puis en déclenchant une négociation, à l'aide d'une requête de négociation 404 envoyée à l'autre tête de tunnel 101, visant à sécuriser la connexion entre la tête de tunnel 101 et le serveur 113 (cf. figure 10). En cas de négociation réussie, une connexion sécurisée de type TLS est établie entre la tête de tunnel 101 et le serveur 113 (la tête de tunnel 101, vu du serveur 113, agit effectivement pour le client 108 en tant que proxy TLS). La tête de tunnel 102 met alors en oeuvre un mécanisme de basculement dans un mode de particulier, dit de déchargement, pour lui permettre de se décharger des ressources de chiffrement sur le serveur sélectionné 113. La synchronisation des étapes décrites précédemment, exécutées par les têtes de tunnel 101 et 102, se réalise suite à une simple signalisation entre lesdites têtes de tunnel. À titre d'exemple, chaque tête de tunnel est capable de détecter le basculement 405 entre l'envoi des paquets de données du type 302 vers le type 303 par la tête de tunnel en face. Il est à noter que lorsque la tête de tunnel 101 ou la tête de tunnel 102 gère plusieurs connexions en parallèle, sur le même tunnel ou non et entre les mêmes équipements serveur et client ou non, les modes de fonctionnement de chaque tête de tunnel pour chacune des connexions évolueront indépendamment les uns des autres. Le mode de fonctionnement de déchargement de la tête de tunnel 102 ainsi que le mode proxy TLS de la tête de tunnel 101 sont maintenus jusqu'à la fermeture de la connexion concernée ( message FIN décrit dans le document IETF RFC 793 "TRANSMISSION CONTROL PROTOCOL", September 1981). Dans le mode de déchargement de ladite tête de tunnel, les paquets de données de la connexion en question continuent de transiter dans le format 301 sur le sous-réseau 103 entre le client 108 et la tête de tunnel associée 101. Étant donné qu'une connexion TCP/IP sécurisée TLS a été établie entre la tête de tunnel 101 et le serveur 113, les paquets de données 303 transitant sur le tunnel ainsi que les paquets de données correspondants 304, transitant sur le sous-réseau 104 entre la tête de tunnel 102 et le serveur 113, comportent en conséquence un en-tête TCP/IP, un en-tête TLS et une charge utile chiffrée conformément audit protocole TLS. On notera, en outre, que pour les données transmises du serveur 113 au client 108, le chiffrement est effectué par le serveur 113 et le déchiffrement est effectué par la tête de tunnel 101, et vice-versa pour les données transmises dans le sens opposé. Dans le tunnel, ledit paquet de données 304 est encapsulé dans le paquet 303, avec rajout de l'en-tête de tunnel TH tel que mentionné ci-dessus. De façon optionnelle, chaque tête de tunnel peut appliquer dans le tunnel un chiffrement partiel des paquets 303, couvrant uniquement les en-têtes IP et éventuellement TLS, la charge utile étant déjà chiffrée. Les ressources induites par ce chiffrement au niveau des têtes de tunnel restent négligeables, la taille des en-têtes IP et/ou TLS étant très inférieure à la taille de la charge utile. De façon similaire à la figure 4, on présente, en relation avec la figure 5, séquence simplifiée de gestion de connexions entre un client 108, un serveur 113 et leurs têtes de tunnel 101 et 102 respectives, lorsqu'une connexion entre le client et le serveur employant le tunnel est modifiée de manière à décharger la tête de tunnel 101 associée au client 108 des opérations de chiffrement, suivant le procédé conforme à la présente invention. À l'état initial, il existe une connexion IP entre le client 108 et le serveur 113, non sécurisée au niveau des sous-réseaux respectifs 103 et 104, véhiculée par l'Internet 107 via un tunnel 100 établi entre les deux têtes de tunnel respectives 101 et 102. Le format et le traitement des paquets de données IP 301 et 302 dans cet état de la connexion est identique au cas précédent.
Suite à une détection de limitation de ressources (cf. figure 8), la tête de tunnel 101 associée au client 108, se lance dans une tentative de basculement dans un mode de déchargement (tel que décrit par la figure 8) en sélectionnant tout d'abord le client 108 (cf. figure 9), puis en déclenchant une négociation, à l'aide d'une requête de négociation 504 envoyée à l'autre tête de tunnel 102, visant à sécuriser la connexion entre la tête de tunnel 102 et le client 108 (cf. figure 10). En cas de négociation réussie, une connexion sécurisée de type TLS est établie entre la tête de tunnel 102 et le client 108 (la tête de tunnel 102, vu du client 108, agit effectivement pour le serveur 113 en tant que proxy TLS). La tête de tunnel 101 met alors en oeuvre un mécanisme de basculement dans un mode de particulier, dit de déchargement, pour lui permettre de se décharger des ressources de chiffrement sur le client sélectionné 108. La synchronisation des étapes décrites précédemment, exécutées par les têtes de tunnel 101 et 102, se réalise suite à une simple signalisation telle que décrite ci-dessus. Le mode de déchargement de la tête de tunnel 101 ainsi que le mode proxy TLS de la tête de tunnel 102 sont maintenus jusqu'à la fermeture de la connexion concernée ( message FIN décrit dans le document IETF RFC 793 "TRANSMISSION CONTROL PROTOCOL", September 1981). Dans le mode de déchargement de ladite tête de tunnel, les paquets de données de la connexion en question continuent de transiter dans le format 301 sur le sous-réseau 104 entre le serveur 113 et la tête de tunnel associée 102. Étant donné qu'une connexion TCP/IP sécurisée TLS a été établie entre la tête de tunnel 102 et le client 108, les paquets de données 303 transitant sur le tunnel ainsi que les paquets de données correspondants 304, transitant sur le sous-réseau 103 entre la tête de tunnel 101 et le client 108, comportent en conséquence un en-tête TCP/IP, un en-tête TLS et une charge utile chiffrée conformément audit protocole TLS. On notera, en outre, que pour les données transmises du client 108 au serveur 113, le chiffrement est effectué par le client 108 et le déchiffrement est effectué par la tête de tunnel 102, et vice-versa pour les données transmises dans le sens opposé. Dans le tunnel, ledit paquet de données 304 est encapsulé dans le paquet 303, avec rajout de l'en-tête de tunnel TH.
De façon optionnelle, chaque tête de tunnel peut appliquer dans le tunnel un chiffrement partiel des paquets 303, couvrant uniquement les en-têtes IP et éventuellement TLS, la charge utile étant déjà chiffrée. Les ressources induites par ce chiffrement au niveau des têtes de tunnel restent négligeables, la taille des en-têtes IP et/ou TLS étant très inférieure à la taille de la charge utile. On présente maintenant, en relation avec la figure 6, une séquence simplifiée de messages échangés dans le cadre d'un déchargement de bout en bout selon un mode de réalisation particulier de l'invention. Cette séquence est mise en oeuvre entre un client 108, un serveur 113 et leurs têtes de tunnel 101 et 102 respectives, lorsqu'une connexion entre le client et le serveur employant le tunnel et préalablement transformée de manière à décharger la tête de tunnel 101 associée au client 108 des opérations de chiffrement (tel que décrit dans la figure 5), subit une transformation supplémentaire, visant en outre à décharger la tête de tunnel 102 associée au serveur 113, suivant le procédé conforme à la présente invention. À l'état initial, il existe une connexion IP entre le client 108 et le serveur 113, non sécurisée au niveau du sous-réseau 104 et sécurisée par TLS entre la tête de tunnel 102 et le client 108, comme décrit ci-dessus à l'aide de la figure 5. A un certain instant, la tête de tunnel 102 associée au serveur 113, suite à une détection de limitation de ressources (cf. figure 7) se lance dans une tentative de basculement dans le mode de déchargement (cf. figure 8) en sélectionnant le serveur 113 (cf. figure 9), puis en déclenchant une négociation, à l'aide d'une requête de négociation 604 envoyée au client 108, visant à sécuriser de bout en bout la connexion en cours entre le client 108 et le serveur 113 (cf. figure 10). En cas de négociation réussie, une connexion sécurisée de type TLS est établie serveur 113 et le client 108. La tête de tunnel 102 met en oeuvre à son tour un mécanisme de basculement dans le mode de déchargement (tout comme cela a déjà été le cas préalablement pour la tête de tunnel 101) afin de pouvoir se décharger des ressources de chiffrement sur le serveur sélectionné 113. Par conséquent, des paquets 304 protégés conformément au protocole TLS transitent sur les sous-réseaux 103 et 104. En transitant sur le tunnel, lesdits paquets sont encapsulés dans des paquets 303 tel que décrits ci-dessus. On note que les deux têtes de tunnel 101 et 102 se trouvent alors déchargées de la tâche de chiffrement de la charge utile comprise dans les paquets 303. De façon optionnelle, les têtes de tunnel appliqueront dans le tunnel un chiffrement partiel des paquets 303 tel que décrit ci-dessus. La synchronisation des étapes décrites précédemment, exécutées par les têtes de tunnel 101 et 102, se réalise suite à un protocole de signalisation et un traitement de requêtes entre lesdites têtes de tunnel (cf. figures 12 et 13). Le mode de déchargement des têtes de tunnel 101 et 102 est maintenu jusqu'à la fermeture de la connexion concernée. On présente maintenant, en relation avec la figure 7, un algorithme de détection de limitation de ressources de chiffrement/déchiffrement, selon un mode de réalisation particulier du procédé de l'invention. Cet algorithme vise à détecter une condition de limitation de ressources de calcul, correspondant aux opérations de chiffrement/déchiffrement au niveau d'une tête de tunnel, telle que par exemple la tête de tunnel 101 ou 102. L'étape 701 consiste à tenir compte d'une possible configuration par défaut de la tête de tunnel. Dans un mode particulier de réalisation, chaque tête de tunnel est configurée pour appliquer le mode de déchargement de façon systématique et inconditionnelle. Le traitement se poursuit alors par l'étape 704. Dans le cas contraire, des étapes supplémentaires 702 ou 703 sont exécutées. L'étape 702 concerne la disponibilité des canaux de tunnel ; il est applicable en particulier lorsque le chiffrement et le déchiffrement au niveau du tunnel sont implémentés par un matériel dédié (tels que des matériels de type FPGA, ASIC) et lorsqu'il existe une limitation en terme de canaux de chiffrement/déchiffrement susceptibles d'être traités an parallèle, dû à la conception du matériel. Quant à l'étape 703, elle concerne la disponibilité des ressources CPU de chiffrement/déchiffrement. Les systèmes d'exploitation multitâches habituellement utilisés dans le domaine des logiciels embarqués fournissent fréquemment une fonctionnalité permettant d'estimer le pourcentage d'utilisation des ressources CPU ; l'étape 703 ne sera alors validée que lorsque ce pourcentage est inférieur à un certain seuil, fixe et prédéterminé ou bien variable en fonction du débit du flux de données à véhiculer sur la connexion en question. Dans le cas d'échec d'une des étapes 702 ou 703, le traitement se poursuit par l'étape 704. L'exécution de cette dernière étape permet à ladite connexion d'être marquée comme étant éligible à l'application du procédé de déchargement.
La figure 8 présente un mode de fonctionnement particulier du procédé de gestion de connexions selon l'invention. Plus particulièrement, elle concerne un algorithme permettant d'exécuter une tentative de basculement dans le mode de déchargement d'une tête de tunnel. Le procédé est effectué par la tête de tunnel 101 et/ou 102 lors de l'ouverture d'une nouvelle connexion sur le tunnel ou lors d'une détection de limitation de ressources selon la description relative à la figure 8. Tout d'abord, l'étape 802 de sélection du client ou du serveur est activée (cf. figure 9). Suite à la sélection d'un desdits client ou serveur, l'étape 803 dénommée négociation pour l'établissement d'une connexion sécurisée est mise en place. Cette étape est décrite plus en détail en relation avec la figure 10. L'issue de l'étape 804 dépend de la réussite de ladite négociation. Lors d'une issue positive, l'étape 805 de basculement dans un mode de déchargement est activée (cf. figures 4, 5 et 6 ci-dessus) permettant ainsi de procéder au déchargement de la tête de tunnel en question des ressources de chiffrement ou de déchiffrement.
La figure 9 présente un algorithme de sélection d'un dispositif terminal, selon un mode particulier de réalisation du procédé selon l'invention. Elle décrit un procédé de sélection d'un client ou d'un serveur pour une connexion donnée, exécuté par les têtes de tunnel 101 et/ou 102, de manière à lancer une tentative de basculement dans le mode de déchargement pour une connexion impliquant le serveur ou le client sélectionné. Cette sélection débute par l'étape 901 qui permet d'analyser le trafic transitant par la tête de tunnel 101 (respectivement 102) entre le sous-réseau 103 (respectivement 104) et le tunnel relié à l'autre sous-réseau 104 (respectivement 103). L'étape 902 vise à détecter les messages d'ouverture de connexion TCP (message SYN , décrit dans le document IETF RFC 793 "TRANSMISSION CONTROL PROTOCOL", September 1981) en provenance d'un client situé sur le sous-réseau et rentrant dans le tunnel. À titre d'exemple, la tête de tunnel 101 reçoit un message SYN du client 108 par le sous-réseau 103. Et l'étape 902 vise également à détecter des messages de confirmation d'ouverture de connexion TCP (message SYNACK , décrit dans le document IETF RFC 793 "TRANSMISSION CONTROL PROTOCOL", September 1981) en provenance d'un serveur distant, sortants du tunnel et destinés à un client local. À titre d'exemple, la tête de tunnel 101 reçoit un message SYN-ACK du serveur 113 par le tunnel, destiné au client 108. Lorsque l'étape 902 est réussie, alors l'étape 908 est ensuite exécutée ou, dans le cas contraire, l'étape 903. L'étape 903 vise à détecter les messages de confirmation d'ouverture de connexion TCP en provenance d'un serveur, cette fois-ci, situé sur le sous-réseau et rentrant dans le tunnel (la tête de tunnel 102 reçoit un message SYN-ACK du serveur 113 par le réseau 104 par exemple) ou des messages d'ouverture de connexion TCP (message SYN ) en provenance d'un client distant, sortants du tunnel et destinés à un serveur local (la tête de tunnel 102 reçoit un message SYN du client 108 par le tunnel, destiné au serveur 113, par exemple). Dans l'étape 903 est réussie, alors l'étape 904 est ensuite exécutée ou l'étape 912 dans le cas contraire. Lors de l'étape 904, la tête de tunnel lit dans l'en-tête du message reçu l'adresse IP du serveur impliqué dans l'établissement d'une connexion IP. L'étape 905 consiste à récupérer dans la base de données interne de la tête de tunnel des informations associées audit serveur, en particulier, sa capacité d'accepter des demandes d'établissement de connexions chiffrées de manière à décharger la tête de tunnel conformément à la présente invention. Cette base de données mémorise de préférence les connaissances acquises concernant la quantité de ressources du serveur lors des tentatives passées de basculement dans le mode de déchargement (cf. figure 10, étape 1059). À titre d'exemple, un serveur qui s'est avéré incapable par le passé d'accepter une demande de déchargement par la tête de tunnel sera considérée comme non éligible à l'application du mode de déchargement. Le traitement se poursuit par l'étape 912. Dans le cas contraire, l'étape 907 est exécutée. Elle consiste à marquer le serveur que le basculement dans le mode de déchargement peut avoir lieu (cf. figure 8, étape 803). Les étapes 908, 909, 910 et 911 sont similaires aux étapes 904, 905, 906 et 907 mais concernent la prise de décision sur l'éligibilité d'un client au lieu d'un serveur. Il est à noter qu'un même équipement terminal peut parfois agir en tant que serveur et parfois en tant que client et que la capacité d'accepter une demande de connexion sécurisée peut ne pas être la même dans ces deux cas. Finalement, l'étape 912 consiste à marquer à l'aide de la tête de tunnel, ledit serveur ou client d'un échec de la tentative de basculement dans le mode de déchargement.
On présente maintenant, en relation avec la figure 10, un organigramme d'un algorithme de négociation pour l'établissement d'une connexion sécurisée, selon un mode de réalisation particulier du procédé selon l'invention. Plus précisément, cet organigramme illustre les différentes étapes de négociation, telles qu'elles sont introduites sur les figures 4, 5 et 6, permettant de transformer la connexion TCP/IP en une connexion sécurisée entre une tête de tunnel et un serveur ou un client. En fonction du marquage effectué préalablement (cf. figure 9), l'étape 1051 ou 1055 pourra réussir. Si l'étape 1051 est réussie, la tête de tunnel 101 procède à l'exécution de l'étape 1052, consistant à demander au client 108 de mettre à jour la connexion TCP/IP en cours pour la basculer dans le mode sécurisé. Dans un mode préféré de réalisation de la présente invention, on traite en particulier les connexions HTTP véhiculées au-dessus du protocole TCP/IP. Une méthode de mise à jour d'une connexion HTTP/1.1 non sécurisée vers une connexion sécurisée TLS est décrite dans le document intitulé IETF RFC 2817 ("Upgrading to TLS Within HTTP/1.1", R. Khare, S. Lawrence, May 2000).
Conformément à la section 4 de ce document, intitulée Server Requested Upgrade to HTTP over TLS , et en particulier la section 4.1 Optional Advertisement , la tête de tunnel 101 insère un en-tête Upgrade Header , tel que décrit dans le document IETF RFC 2616 ("Hypertext Transfer Protocol û HTTP/1.1", R. Fielding et al., June 1999), section 14.42, indiquant que le serveur est capable de traiter le protocole de sécurisation TLS, dans une réponse HTTP en provenance du serveur 113 et destinée au client 108. Si le client 108 implémente la fonctionnalité décrite dans le document IETF RFC 2817, il répondra par une requête HTTP spécifiée dans la section 3 du document. Dans le cas contraire, il ignorera la demande de mise à jour insérée par la tête de tunnel 101. Cette réaction du client 108 conditionne l'issue de l'étape 1053. Un succès de cette étape déclenche alors un passage de la tête de tunnel 101 à l'étape 1054, tandis qu'un rejet signifie l'échec de la négociation. Pendant l'étape 1054, en fonction de la capacité du serveur 113 d'accepter une mise à jour d'une connexion non sécurisée vers une connexion sécurisée TLS, dont la tête de tunnel 101 aura préalablement pris connaissance, la tête de tunnel 101 fera suivre la demande de mise à jour de connexion issue du client 108 au serveur 113 par la tête de tunnel 102, ce qui aboutit à une négociation de sécurisation TLS directement entre le client 108 et le serveur 113. Par conséquent, les têtes de tunnel 101 et 102 entrent dans le mode de fonctionnement de bout en bout décrit en relation avec la figure 6. Ou bien la tête de tunnel 101 intercepte la demande de mise à jour de connexion et répond par un HTTP 101 Switching Protocols , comme décrit dans le document IETF RFC 2817, section 3.3 Server Acceptance of Upgrade Request . Le client démarre alors une négociation d'une connexion TLS conformément aux documents IETF RFC 2246 ("The TLS Protocol - Version 1.0", T. Dierks, C. Allen, January 1999) ou IETF RFC 4346 ("The Transport Layer Security (TLS) Protocol - Version 1.1", T. Dierks, E. Rescorla, April 2006), résultant d'un accord sur l'algorithme de chiffrement ainsi qu'un échange de clés de chiffrement, suivi par une sécurisation des échanges liés à la connexion en cours par chiffrement. On considère alors la tentative de déchargement de la tête de tunnel 101 comme réussie. Par conséquent, les têtes de tunnel 101 et 102 entrent dans le mode de fonctionnement décrit en relation avec la figure 5. À l'issue de l'étape 1054, l'étape 1060 est exécutée. Elle consiste à mettre à jour la base de données avec la quantité de ressources du client 108 permettant de réaliser le passage vers une connexion sécurisée, telles que testées lors de l'étape 1053. De plus amples détails concernant l'utilisation de cette base de données sont illustrés à l'étape 909 de la figure 9. Ensuite, la phase de négociation se termine avec succès, ce qui correspond à l'étape 1062.
De façon similaire, le rejet du client 108 à établir une connexion protégée lors de l'étape 1053 enclenche un enregistrement de l'incapacité du client à établir une connexion sécurisée dans la base de données lors de l'étape 1061. Ensuite, la phase de négociation se termine par un échec correspondant à l'étape 1063. Si l'étape 1055 est réussie, la tête de tunnel 102 procède à l'exécution de l'étape 1056 consistant à demander au serveur 113 de mettre à jour la connexion TCP/IP en cours pour la basculer dans le mode sécurisé. Dans le mode préféré de réalisation de la présente invention, on traite en particulier les connexions HTTP véhiculées au-dessus du protocole TCP/IP. Conformément à la section 3 du document IETF RFC 2817, intitulée Client Requested Upgrade to HTTP over TLS , et en particulier la section 3.1 Optional Advertisement , la tête de tunnel 102 insère un en-tête Upgrade Header , indiquant que le client est capable de traiter le protocole de sécurisation TLS, dans une requête HTTP en provenance du client 108 et destinée au serveur 113. Si le serveur 113 implémente la fonctionnalité décrite dans IETF RFC 2817, il répondra par un HTTP 101 Switching Protocols , comme décrit dans le document IETF RFC 2817, section 3.3 Server Acceptance of Upgrade Request . Dans le cas contraire, il ignorera la demande de mise à jour insérée par la tête de tunnel 102. En cas de réception par la tête de tunnel 102 de la réponse HTTP 101 provenant du serveur 113, celle-ci démarre une négociation d'une connexion TLS, conformément aux documents IETF RFC 2246 ou IETF RFC 4346, résultant d'un accord sur l'algorithme de chiffrement ainsi qu'un échange de clés de chiffrement, suivi par une sécurisation des échanges liés à la connexion en cours par chiffrement. On considère alors la tentative de déchargement de la tête de tunnel 102 comme réussie. Par conséquent, les têtes de tunnel 101 et 102 entrent dans le mode de fonctionnement décrit en relation avec la figure 4. À l'issue de l'étape 1056, l'étape 1057 est exécutée. Si le serveur accepte la demande de mise à jour de connexion précédemment décrite, l'étape 1058 est exécutée. Elle consiste à mettre à jour la base de données avec la quantité de ressources du serveur 113 permettant de réaliser le passage vers une connexion sécurisée, telles que testées lors de l'étape 1057. De plus amples détails concernant l'utilisation de cette base de données sont illustrés à l'étape 909 de la figure 9. Ensuite, la phase de négociation se termine avec succès correspondant à l'étape 1062. De façon similaire, le rejet du serveur 113 à établir une connexion protégée lors de l'étape 1056 enclenche un enregistrement de l'incapacité dudit serveur dans ladite base de données lors de l'étape 1059. Ensuite, la phase de négociation se termine par un échec correspondant à l'étape 1063.
Chacune des figures 11a, llb et 11c représente un organigramme d'un mode de fonctionnement appliqué par les têtes de tunnel (la figure 1 la illustrant le mode classique t u n n e l , la figure l l b illustrant le mode de déchargement et la f i g u r e l l c le mode proxy TLS). Elles illustrent chacune un mode de fonctionnement différent appliqué par une tête de tunnel en fonction de la connexion en cours, ainsi que le traitement des messages en fonction de ces modes.
Le mode tunnel 1101 est bien connu de l'homme du métier. De manière classique, lors de la réception par la tête de tunnel d'un message en provenance de la deuxième tête de tunnel sur le tunnel (événement 1102), cette première désencapsule dans un premier temps le paquet de données en retirant l'en-tête (TH) spécifique au protocole encapsulant, typiquement basé sur TCP ou UDP, employé sur le tunnel (étape 1103). Dans un second temps, cette première tête de tunnel déchiffre la charge utile de ce paquet de données en utilisant une clé spécifique négociée préalablement avec la deuxième tête de tunnel lors de l'établissement du tunnel (étape 1104). Puis, elle retransmet dans un troisième temps le paquet de données sur le sous-réseau associé à ladite tête de tunnel, à destination de l'équipement terminal, c'est-à-dire le client 108 pour la tête de tunnel 101 ou le serveur 113 pour la tête de tunnel 102 (étape 1105). Lors de la réception par la tête de tunnel d'un paquet de données issu de l'équipement terminal situé sur le sous-réseau associé (événement 1107), cette première chiffre dans un premier temps ce paquet de données en utilisant une clé spécifique négociée préalablement avec la deuxième tête de tunnel lors de l'établissement du tunnel (étape 1108). Dans un second temps, elle encapsule le paquet de données en le précédant d'un en-tête (TH) spécifique au protocole encapsulant employé sur le tunnel (étape 1109), puis retransmet ce paquet de données sur le tunnel, à destination de la deuxième tête de tunnel dans un troisième temps (étape 1110). Lors de la détection de la fermeture de la connexion en cours (événement 1111), la tête de tunnel libère les ressources associées à la gestion de cette connexion (étape 1112), puis le traitement de la connexion se termine (mode 1113). Dans le mode de déchargement 1201 pour une connexion donnée, une tête de tunnel se comporte de la façon suivante. Lors de la réception par la tête de tunnel d'un paquet de données en provenance de la deuxième tête de tunnel sur le tunnel (événement 1202), cette première désencapsule dans un premier temps le paquet en retirant l'en-tête (TH) servant à véhiculer le trafic entre les têtes de tunnel (étape 1203). Dans un second temps, ladite tête de tunnel déchiffre l'en-tête appartenant au paquet de données désencapsulé en utilisant une clé spécifique négociée préalablement avec la deuxième tête de tunnel lors de l'établissement du tunnel (étape 1204), puis retransmet dans un troisième temps le paquet sur son sous-réseau associé, à destination de l'équipement terminal, c'est-à-dire le client 108 pour la tête de tunnel 101 ou le serveur 113 pour la tête de tunnel 102 (étape 1205). Lors de la réception par la tête de tunnel d'un paquet de données issu de l'équipement terminal situé sur le sous-réseau (événement 1207), cette première chiffre dans un premier temps l'en-tête du paquet reçu en utilisant une clé spécifique négociée préalablement avec la deuxième tête de tunnel lors de l'établissement du tunnel (étape 1208). Dans un deuxième temps, elle encapsule le paquet de données en le précédant d'un en-tête (TH) spécifique au protocole servant à véhiculer le trafic entre les têtes de tunnel (étape 1209), puis dans un troisième temps, retransmet ce message sur le tunnel à destination de la deuxième tête de tunnel (étape 1210). Lors de la détection de la fermeture de la connexion en cours (événement 1211), la tête de tunnel libère les ressources associées à la gestion de cette connexion (étape 1212), puis le traitement de la connexion se termine (mode 1213). Dans le mode proxy TLS 1301 pour une connexion donnée, une tête de tunnel se comporte de la façon suivante. Lors de la réception par la tête de tunnel d'un paquet de données en provenance de la deuxième tête de tunnel sur le tunnel (événement 1302), cette première désencapsule, dans un premier temps, le paquet de données en retirant l'en-tête (TH) servant à véhiculer le trafic entre les têtes de tunnel (étape 1303). Dans un deuxième temps, la tête de tunnel déchiffre l'en-tête appartenant au paquet de données désencapsulé en utilisant la clé spécifique négociée préalablement avec la deuxième tête de tunnel lors de l'établissement du tunnel (étape 1304), puis dans un troisième temps déchiffre la charge utile dudit paquet de données avec la clé TLS obtenu lors de la négociation avec l'équipement terminal situé sur le sous-réseau associé à la deuxième tête de tunnel, c'est-à-dire le client 108 pour la tête de tunnel 102 ou bien le serveur 113 pour la tête de tunnel 101 (étape 1305). Dans un quatrième temps, elle retransmet le message sur son sous-réseau associé, à destination de l'équipement terminal, c'est-à-dire le client 108 pour la tête de tunnel 101 ou bien le serveur 113 pour la tête de tunnel 102 (étape 1306). Lors de la réception par la tête de tunnel d'un paquet de données issu de l'équipement terminal situé sur le sous-réseau (événement 1307), cette première chiffre, dans un premier temps, la charge utile du message reçu avec la clé TLS obtenu lors de la négociation avec l'équipement terminal situé sur le sous-réseau associé à la deuxième tête de tunnel, c'est-à-dire le client 108 pour la TET 102 ou le serveur 113 pour la TET 101 (étape 1308). Dans un deuxième temps, elle chiffre l'en-tête du paquet de données reçu en utilisant une clé spécifique négociée préalablement avec la deuxième tête de tunnel lors de l'établissement du tunnel (étape 1309), puis encapsule dans un troisième temps le paquet de données en le précédant d'un en-tête (TH) spécifique au protocole servant à véhiculer le trafic entre les tête de tunnel (étape 1310). Enfin, dans un quatrième temps, la tête de tunnel retransmet ce paquet de données sur le tunnel, à destination de la deuxième tête de tunnel (étape 1314). Lors de la détection de la fermeture de la connexion en cours (événement 1311), la tête de tunnel libère les ressources associées à la gestion de cette connexion (étape 1312), puis le traitement de la connexion se termine (mode 1313).

Claims (21)

REVENDICATIONS
1. Procédé de gestion d'au moins une connexion établie via un tunnel supporté par un réseau de communication principal, ledit tunnel étant mis en oeuvre entre des première et seconde têtes de tunnel connectées respectivement à des premier et second sous-réseaux, chaque connexion permettant une transmission de données entre un dispositif client et un dispositif serveur via ledit tunnel, ledit dispositif client et ledit dispositif serveur étant connectés l'un au premier sous-réseau et l'autre au second sous-réseau, caractérisé en ce que ledit procédé comprend une étape de tentative de basculement dans un mode de déchargement, effectuée par au moins une desdites première et seconde têtes de tunnel, dite tête de tunnel à décharger, ladite étape de tentative de basculement comprenant les étapes suivantes : - sélection (802) d'au moins un dispositif serveur et/ou au moins un dispositif client, dit dispositif sélectionné, tel que : il est connecté au sous-réseau auquel est connectée ladite tête de tunnel à décharger, il est impliqué dans une connexion sécurisée par chiffrement et véhiculée par ledit tunnel, ladite connexion étant établie ou à établir, et il possède une quantité suffisante de ressources de chiffrement/déchiffrement ; - pour chaque dispositif sélectionné, déclenchement (803) d'une négociation d'une connexion sécurisée entre ledit dispositif sélectionné et la tête de tunnel distante de la tête de tunnel à décharger ; - en cas de négociation réussie pour une connexion sécurisée donnée, basculement (805) de ladite tête de tunnel à décharger dans un mode de déchargement, pour ladite connexion sécurisée donnée, le mode de déchargement étant tel que ladite tête de tunnel à décharger n'effectue pas d'opération de 25 chiffrement/déchiffrement pour ladite connexion sécurisée donnée.
2. Procédé selon la revendication 1, caractérisé en ce que ladite étape de tentative de basculement est effectuée sur détection d'un évènement appartenant au groupe comprenant : - ouvertures d'une nouvelle connexion sur ledit tunnel ; 30 - détections (801) d'une limitation de ressources de chiffrement/déchiffrement de ladite tête de tunnel à décharger. 20
3. Procédé selon l'une quelconque des revendications 1 et 2, caractérisé en ce que ladite étape de déclenchement (803) d'une négociation comprend une étape d'envoi d'une requête de négociation à ladite tête de tunnel distante.
4. Procédé selon la revendication 3, caractérisé en ce que : - si après une première itération de ladite étape de tentative de basculement, effectuée par l'une desdites première et seconde têtes de tunnel, dite tête de tunnel à décharger de première itération, ladite tête de tunnel à décharger de première itération a basculé (805) dans ledit mode de déchargement pour au moins une connexion sécurisée donnée, dite connexion sécurisée de première itération, impliquant au moins un dispositif sélectionné donné, dit dispositif sélectionné de première itération, -alors dans une seconde itération de ladite étape de tentative de basculement, effectuée par l'autre desdites première et seconde têtes de tunnel : * si ladite étape de sélection (802) sélectionne au moins un dispositif serveur et/ou au moins un dispositif client impliqué dans ladite connexion sécurisée de première itération, * alors ladite étape de déclenchement (803) d'une négociation comprend une étape d'envoi d'une requête de négociation audit dispositif sélectionné de première itération pour ladite connexion sécurisée de première itération.
5. Procédé selon l'une quelconque des revendications 1 à 4, caractérisé en ce que ladite tête de tunnel à décharger, quand elle fonctionne dans ledit mode de déchargement pour une connexion sécurisée donnée, effectue les étapes suivantes : - lors de la réception d'un message de la tête de tunnel distante sur le tunnel : * désencapsulation dudit message, en enlevant un premier en-tête (TH) servant à véhiculer ledit message entre les têtes de tunnel, permettant d'obtenir un message désencapsulé ; * retransmission du message désencapsulé sur le sous- réseau auquel est connectée ladite tête de tunnel à décharger, à destination du dispositif sélectionné pour ladite connexion sécurisée donnée ; - lors de la réception d'un message issu du dispositif sélectionné pour ladite connexion sécurisée donnée :* encapsulation dudit message en le précédant d'un premier en-tête (TH) servant à véhiculer ledit message entre les têtes de tunnel, permettant d'obtenir un message encapsulé ; * retransmission du message encapsulé sur le tunnel, à destination de la tête de tunnel distante.
6. Procédé selon la revendication 5, caractérisé en ce que ladite tête de tunnel à décharger, quand elle fonctionne dans ledit mode de déchargement pour une connexion sécurisée donnée, effectue les étapes suivantes : -lors de la réception d'un message de la tête de tunnel distante sur le tunnel, ladite étape de retransmission du message est précédée de l'étape suivante : * déchiffrement d'un second en-tête appartenant au message désencapsulé, en utilisant une clé spécifique négociée préalablement avec la tête de tunnel distante lors de l'établissement du tunnel, ledit second en-tête servant à véhiculer ledit message sur lesdits premier et second sous-réseaux ; - lors de la réception d'un message issu du dispositif sélectionné pour ladite connexion sécurisée donnée, ladite étape d'encapsulation est précédée de l'étape suivante : * chiffrement d'un second en-tête dudit message, en utilisant une clé spécifique négociée préalablement avec la tête de tunnel distante lors de l'établissement du tunnel, ledit second en-tête servant à véhiculer ledit message sur lesdits premier et second sous-réseaux.
7. Procédé de gestion d'au moins une connexion établie via un tunnel supporté par un réseau de communication principal, ledit tunnel étant mis en oeuvre entre des première et seconde têtes de tunnel connectées respectivement à des premier et second 25 sous-réseaux, chaque connexion permettant une transmission de données entre un dispositif client et un dispositif serveur via ledit tunnel, ledit dispositif client et ledit dispositif serveur étant connectés l'un au premier sous-réseau et l'autre au second sous-réseau, caractérisé en ce que ledit procédé comprend les étapes suivantes, effectuées par au moins une desdites première et seconde têtes de tunnel, dite tête de tunnel distante, la 30 tête de tunnel autre que la tête de tunnel distante étant appelée tête de tunnel à décharger : 20- négociation d'une connexion sécurisée avec un dispositif sélectionné par ladite tête de tunnel à décharger ; - en cas de négociation réussie, pour ladite connexion sécurisée, basculement de ladite tête de tunnel distante dans un mode de mandataire de sécurisation ( proxy TLS ), le mode de mandataire de sécurisation étant tel que ladite tête de tunnel distante effectue des opérations de chiffrement/déchiffrement pour ladite connexion sécurisée donnée en relation avec ledit dispositif sélectionné.
8. Procédé selon la revendication 7, caractérisé en ce que ladite étape de négociation est effectuée après une étape d'une réception d'une requête de négociation provenant de ladite tête de tunnel à décharger.
9. Procédé selon l'une quelconque des revendications 7 à 8, caractérisé en ce que ladite tête de tunnel distante, quand elle fonctionne dans le mode de mandataire de sécurisation pour une connexion sécurisée donnée, effectue les étapes suivantes : - lors de la réception d'un message de la tête de tunnel à décharger sur le tunnel : * désencapsulation dudit message, en enlevant un premier en-tête (TH) servant à véhiculer ledit message entre les têtes de tunnel, permettant d'obtenir un message désencapsulé ; * déchiffrement d'une charge utile appartenant au message désencapsulé, en utilisant une clé spécifique négociée préalablement avec le dispositif sélectionné lors de ladite étape de négociation, permettant d'obtenir un message déchiffré ; * retransmission du message déchiffré sur le sous-réseau auquel est connectée ladite tête de tunnel distante, à destination d'un dispositif client ou serveur ; - lors de la réception d'un message issu d'un dispositif client ou serveur : * chiffrement d'une charge utile dudit message, en utilisant une clé spécifique négociée préalablement avec le dispositif sélectionné lors de ladite étape de négociation, permettant d'obtenir un message chiffré ; * encapsulation dudit message chiffré en le précédant d'un premier en-tête (TH) servant à véhiculer ledit message chiffré entre les têtes de tunnel, permettant d'obtenir un message encapsulé ; 20 25 30* retransmission du message encapsulé sur le tunnel, à destination de la tête de tunnel à décharger.
10. Procédé selon la revendication 9, caractérisé en ce que ladite tête de tunnel distante, quand elle fonctionne dans le mode de mandataire de sécurisation pour une connexion sécurisée donnée, effectue les étapes suivantes : - lors de la réception d'un message de la tête de tunnel à décharger sur le tunnel, ladite étape de retransmission du message déchiffré est précédée de l'étape suivante : * déchiffrement d'un second en-tête appartenant au message désencapsulé, en utilisant une clé spécifique négociée préalablement avec la tête de tunnel à décharger lors de l'établissement du tunnel, ledit second en-tête servant à véhiculer ledit message déchiffré sur lesdits premier et second sous-réseaux ; - lors de la réception d'un message issu d'un dispositif client ou serveur, ladite étape d'encapsulation est précédée de l'étape suivante : * chiffrement d'un second en-tête dudit message chiffré, en utilisant une clé spécifique négociée préalablement avec la tête de tunnel à décharger lors de l'établissement du tunnel, ledit second en-tête servant à véhiculer ledit message chiffré sur lesdits premier et second sous-réseaux. 20
11. Produit programme d'ordinateur téléchargeable depuis un réseau de communication et/ou enregistré sur un support lisible par ordinateur et/ou exécutable par un processeur, caractérisé en ce qu'il comprend des instructions de code de programme pour la mise en oeuvre du procédé selon au moins une des revendications 1 à 6 et/ou au moins une des revendications 7 à 10, lorsque ledit programme est exécuté sur un 25 ordinateur.
12. Moyen de stockage, éventuellement totalement ou partiellement amovible, lisible par un ordinateur, stockant un jeu d'instructions exécutables par ledit ordinateur pour mettre en oeuvre le procédé selon au moins une des revendications 1 à 6 et/ou au moins une des revendications 7 à 10. 30
13. Tête de tunnel à décharger permettant la gestion d'au moins une connexion établie via un tunnel supporté par un réseau de communication principal, ledit tunnel 15étant mis en oeuvre entre des première et seconde têtes de tunnel connectées respectivement à des premier et second sous-réseaux, ladite tête de tunnel à décharger étant l'une desdites première et seconde têtes de tunnel, chaque connexion permettant une transmission de données entre un dispositif client et un dispositif serveur via ledit tunnel, ledit dispositif client et ledit dispositif serveur étant connectés l'un au premier sous-réseau et l'autre au second sous-réseau, caractérisée en ce que ladite tête de tunnel à décharger comprend des moyens de tentative de basculement dans un mode de déchargement, lesdits moyens de tentative de basculement comprenant : - des moyens de sélection d'au moins un dispositif serveur et/ou au moins un dispositif client, dit dispositif sélectionné, tel que : il est connecté au sous-réseau auquel est connectée ladite tête de tunnel à décharger, il est impliqué dans une connexion sécurisée par chiffrement et véhiculée par ledit tunnel, ladite connexion étant établie ou à établir, et il possède une quantité suffisante de ressources de chiffrement/déchiffrement ; - des moyens de déclenchement, pour chaque dispositif sélectionné, d'une négociation d'une connexion sécurisée entre ledit dispositif sélectionné et la tête de tunnel distante de la tête de tunnel à décharger ; et - des moyens de basculement, en cas de négociation réussie pour une connexion sécurisée donnée, de ladite tête de tunnel à décharger dans un mode de déchargement, le mode de déchargement étant tel que ladite tête de tunnel à décharger n'effectue pas d'opération de chiffrement/déchiffrement pour ladite connexion sécurisée donnée.
14. Tête de tunnel à décharger selon la revendication 13, caractérisée en ce qu'elle comprend des moyens de détection d'un évènement appartenant au groupe comprenant : 25 - ouvertures d'une nouvelle connexion sur ledit tunnel ; - détections d'une limitation de ressources de chiffrement/déchiffrement de ladite tête de tunnel à décharger ; et en ce que lesdits moyens de tentative de basculement sont activés si lesdits moyens de détection détectent un événement. 15 20
15. Tête de tunnel à décharger selon l'une quelconque des revendications 13 et 14, caractérisée en ce que lesdits moyens de déclenchement d'une négociation comprennent des moyens d'envoi d'une requête de négociation à ladite tête de tunnel distante.
16. Tête de tunnel à décharger selon l'une quelconque des revendications 13 à 15, caractérisée en ce qu'elle comprend, pour la mise en oeuvre dudit mode de déchargement pour une connexion sécurisée donnée : - des premiers moyens de traitement d'un message de la tête de tunnel distante sur le tunnel, comprenant eux-mêmes : * des moyens de désencapsulation dudit message, en enlevant un premier en-tête (TH) servant à véhiculer ledit message entre les têtes de tunnel, permettant d'obtenir un message désencapsulé ; * des moyens de retransmission du message désencapsulé sur le sous-réseau auquel est connectée ladite tête de tunnel à décharger, à destination du dispositif sélectionné pour ladite connexion sécurisée donnée ; - des seconds moyens de traitement d'un message issu du dispositif sélectionné pour ladite connexion sécurisée donnée, comprenant eux-mêmes : * des moyens d'encapsulation dudit message en le précédant d'un premier en-tête (TH) servant à véhiculer ledit message entre les têtes de tunnel, permettant d'obtenir un message encapsulé ; * des moyens de retransmission du message encapsulé sur le tunnel, à destination de la tête de tunnel distante.
17. Tête de tunnel à décharger selon la revendication 16, caractérisée en ce qu'elle comprend, pour la mise en oeuvre dudit mode de déchargement pour une connexion sécurisée donnée : 25 - lorsque lesdits premiers moyens de traitement sont activés : * des moyens de déchiffrement d'un second en-tête appartenant au message désencapsulé, en utilisant une clé spécifique négociée préalablement avec la tête de tunnel distante lors de l'établissement du tunnel, ledit second en-tête servant à véhiculer ledit message sur lesdits premier et second sous-réseaux ; 30 - lorsque lesdits seconds moyens de traitement sont activés : 15 20* des moyens de chiffrement d'un second en-tête dudit message, en utilisant une clé spécifique négociée préalablement avec la tête de tunnel distante lors de l'établissement du tunnel, ledit second en-tête servant à véhiculer ledit message sur lesdits premier et second sous-réseaux.
18. Tête de tunnel distante permettant la gestion d'au moins une connexion établie via un tunnel supporté par un réseau de communication principal, ledit tunnel étant mis en oeuvre entre des première et seconde têtes de tunnel connectées respectivement à des premier et second sous-réseaux, chaque connexion permettant une transmission de données entre un dispositif client et un dispositif serveur via ledit tunnel, ledit dispositif client et ledit dispositif serveur étant connectés l'un au premier sous-réseau et l'autre au second sous-réseau, la tête de tunnel autre que la tête de tunnel distante étant appelée tête de tunnel à décharger, caractérisé en ce que ladite tête de tunnel distante comprend : - des moyens de négociation d'une connexion sécurisée avec un dispositif sélectionné par ladite tête de tunnel à décharger ; - des moyens de basculement, en cas de négociation réussie pour ladite connexion sécurisée, de ladite tête de tunnel distante dans un mode de mandataire de sécurisation ( proxy TLS ), le mode de mandataire de sécurisation étant tel que ladite tête de tunnel distante effectue des opérations de chiffrement/déchiffrement pour ladite connexion sécurisée donnée en relation avec ledit dispositif sélectionné.
19. Tête de tunnel distante selon la revendication 18, caractérisé en ce qu'elle comprend des moyens de réception d'une requête de négociation provenant de ladite tête de tunnel à décharger, et en ce que lesdits moyens de négociation sont activés sur réception d'une requête de négociation par lesdits moyens de réception.
20. Tête de tunnel distante selon l'une quelconque des revendications 18 à 19, caractérisé en ce qu'elle comprend, pour la mise en oeuvre dudit mode de mandataire de sécurisation pour une connexion sécurisée donnée : des premiers moyens de traitement d'un message de la tête de tunnel à décharger sur le tunnel, comprenant eux-mêmes : 5 10 15 20 25 30* des moyens de désencapsulation dudit message, en enlevant un premier en-tête (TH) servant à véhiculer ledit message entre les têtes de tunnel, permettant d'obtenir un message désencapsulé ; * des moyens de déchiffrement d'une charge utile appartenant au message désencapsulé, en utilisant une clé spécifique négociée préalablement avec le dispositif sélectionné lors de ladite étape de négociation, permettant d'obtenir un message déchiffré ; * des moyens de retransmission du message déchiffré sur le sous-réseau auquel est connectée ladite tête de tunnel distante, à destination d'un dispositif client ou serveur ; - des seconds moyens de traitement d'un message issu d'un dispositif client ou serveur, comprenant eux-mêmes : * des moyens de chiffrement d'une charge utile dudit message, en utilisant une clé spécifique négociée préalablement avec le dispositif sélectionné lors de ladite étape de négociation, permettant d'obtenir un message chiffré ; * des moyens d'encapsulation dudit message chiffré en le précédant d'un premier en-tête (TH) servant à véhiculer ledit message chiffré entre les têtes de tunnel, permettant d'obtenir un message encapsulé ; * des moyens de retransmission du message encapsulé sur le tunnel, à destination de la tête de tunnel à décharger.
21. Tête de tunnel distante selon la revendication 20, caractérisé en ce qu'elle comprend, pour la mise en oeuvre dudit mode de mandataire de sécurisation pour une connexion sécurisée donnée : - lorsque lesdits premiers moyens de traitement sont activés : * des moyens de déchiffrement d'un second en-tête appartenant au message désencapsulé, en utilisant une clé spécifique négociée préalablement avec la tête de tunnel à décharger lors de l'établissement du tunnel, ledit second en-tête servant à véhiculer ledit message déchiffré sur lesdits premier et second sous-réseaux ; - lorsque lesdits seconds moyens de traitement sont activés :* des moyens de chiffrement d'un second en-tête dudit message chiffré, en utilisant une clé spécifique négociée préalablement avec la tête de tunnel à décharger lors de l'établissement du tunnel, ledit second en-tête servant à véhiculer ledit message chiffré sur lesdits premier et second sous-réseaux.5
FR0759865A 2007-12-14 2007-12-14 Procedes de gestion de connexion dans un mode de dechargement d'une tete de tunnel, produit programme d'ordinateur, moyen de stockage et tetes de tunnel correspondants Expired - Fee Related FR2925251B1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
FR0759865A FR2925251B1 (fr) 2007-12-14 2007-12-14 Procedes de gestion de connexion dans un mode de dechargement d'une tete de tunnel, produit programme d'ordinateur, moyen de stockage et tetes de tunnel correspondants

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
FR0759865A FR2925251B1 (fr) 2007-12-14 2007-12-14 Procedes de gestion de connexion dans un mode de dechargement d'une tete de tunnel, produit programme d'ordinateur, moyen de stockage et tetes de tunnel correspondants

Publications (2)

Publication Number Publication Date
FR2925251A1 true FR2925251A1 (fr) 2009-06-19
FR2925251B1 FR2925251B1 (fr) 2011-06-17

Family

ID=39766933

Family Applications (1)

Application Number Title Priority Date Filing Date
FR0759865A Expired - Fee Related FR2925251B1 (fr) 2007-12-14 2007-12-14 Procedes de gestion de connexion dans un mode de dechargement d'une tete de tunnel, produit programme d'ordinateur, moyen de stockage et tetes de tunnel correspondants

Country Status (1)

Country Link
FR (1) FR2925251B1 (fr)

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6182149B1 (en) * 1999-01-11 2001-01-30 3Com Corporation System for managing dynamic processing resources in a network
WO2002088893A2 (fr) * 2001-05-02 2002-11-07 Layer N Networks, Inc. Procede, systeme et appareil de traitement d'informations specifiques a une application

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6182149B1 (en) * 1999-01-11 2001-01-30 3Com Corporation System for managing dynamic processing resources in a network
WO2002088893A2 (fr) * 2001-05-02 2002-11-07 Layer N Networks, Inc. Procede, systeme et appareil de traitement d'informations specifiques a une application

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
S. KHANVILKAR, A. KHOKHAR: "Towards a scalable and flexible architecture for Virtual Private Networks", 2005, SPRINGER-VERLAG, BERLIN HEIDELBERG, XP002497688 *

Also Published As

Publication number Publication date
FR2925251B1 (fr) 2011-06-17

Similar Documents

Publication Publication Date Title
EP3476095B1 (fr) Procédé de communication udp via des chemins multiples entre deux terminaux
US8295306B2 (en) Layer-4 transparent secure transport protocol for end-to-end application protection
US8190879B2 (en) Graceful conversion of a security to a non-security transparent proxy
US20170142100A1 (en) Secure distribution of session credentials from client-side to server-side traffic management devices
FR2919778A1 (fr) Procede de transmission de paquets de donnees dans un tunnel, produit programme d'ordinateur, moyen de stockage et tete de tunnel correspondants
US20110113236A1 (en) Methods, systems, and computer readable media for offloading internet protocol security (ipsec) processing using an ipsec proxy mechanism
EP3476096A1 (fr) Procédé de communication udp via des chemins multiples entre deux terminaux
US8605730B2 (en) System and method for multimedia communication across disparate networks
US11463410B2 (en) Cloud-native VPN service
EP3695571B1 (fr) Dispositif et procédé de transmission de données
FR2929789A1 (fr) Procede de gestion de mecanismes d'amelioration de transmission de flux de donnees sur un tunnel, produit programme d'ordinateur, moyen de stockage et tete de tunnel correspondants
FR3027478A1 (fr) Procede de creation d'un sous flux de paquets de donnees.
EP3643044A1 (fr) Procédé d'activation de traitements appliqués à une session de données
US9143488B2 (en) Real-time encryption of voice and fax over IP
EP3332527B1 (fr) Procédé de transmission d'information entre deux domaines de niveaux de sécurité distincts
EP1432210B1 (fr) Dispositif de contrôle de traitements associés a des flux au sein d'un reseau de communications
EP3506554B1 (fr) Procede de securisation de bout en bout d'une communication
FR2925251A1 (fr) Procedes de gestion de connexion dans un mode de dechargement d'une tete de tunnel, produit programme d'ordinateur, moyen de stockage et tetes de tunnel correspondants
EP4222994A1 (fr) Procedes de configuration d'un equipement utilisateur, de negociation avec une entite du reseau, et de gestion d'une connexion, et dispositifs associes
EP3991392A1 (fr) Procede de gestion d'une communication entre terminaux dans un reseau de communication, et dispositifs et systeme pour la mise en oeuvre du procede
WO2021074412A1 (fr) Procede de connexion d'un noeud de communication, et noeud de communication correspondant
EP1432213B1 (fr) Plate-forme de médiation et réseau de transport de messages
EP1858224A1 (fr) Méthode de mise en place des réseaux privés virtuels et contrôle d'accès distant
EP1708458B1 (fr) Procédé et dispositif d'association d'un dispositif de communication à une passerelle
FR2951045A1 (fr) Procede de gestion de la taille de paquets de donnees d'un flux de donnees, produit programme d'ordinateur, moyen de stockage, et tete de tunnel correspondants.

Legal Events

Date Code Title Description
ST Notification of lapse

Effective date: 20140829