FR2925251A1 - Local and remote tunnel heads connection e.g. secured transfer control protocol/internet protocol connection, controlling method for e.g. digital audio/video and photo equipment, involves tilting local tunnel head in unloading mode - Google Patents

Abstract

The method involves selecting a server device and/or a client device, where the selected device is connected to a sub-network to which a local tunnel head to be unloaded, is connected. The negotiation of a secured connection between the selected device and a remote tunnel head distant from the local tunnel head, is triggered for the selected device. The local tunnel head is tilted in an unloading mode, in case of succeeded negotiation for a given secured connection. The local tunnel head does not execute the encryption/decryption operation for given secured connection in the unloading mode. Independent claims are also included for the following: (1) a computer program product comprising a set of instructions for performing a connection controlling method (2) a computer readable storage medium comprising a set of instructions for performing a connection controlling method (3) a tunnel head comprising a selection unit (4) a remote tunnel head comprising a negotiation unit.

Description

Methods of managing connections in an unload mode of a tunnel end, computer program product, storage means and corresponding tunnel heads. FIELD OF THE INVENTION The field of the invention is that of communication networks. More specifically, the invention relates to a data exchange technique in the context of a mode of unloading an encryption operation on a tunnel traversing a global communication network. The invention applies in particular, but not exclusively, to devices such as, for example, home theater type systems, camcorders, printers, cameras or other digital photo and audio / video equipment for the large public. The democratization of high-speed Internet on the one hand and the emergence of consumer audio-visual equipment with network connectivity on the other hand will create new user behavior. Among these new behaviors, there is little doubt that we will see individuals belonging to groups of people sharing common areas of interest (leisure, family ...) that we could call in permanent liaison. These will establish almost permanent connections with other individuals of the same field of interest in establishing audio and / or video communications and sharing information of any type (audio, video, photo, text ...). The Virtual Private Networks (VPN) technology offers an interesting solution to meet this expectation. Indeed, it makes it possible to communicate transparently in real time, in a secure manner between individuals sharing the same field of interest while using the Internet infrastructure unsafe but cheap. RPVs are frequently used to interconnect two home local area networks (hereinafter called subnetworks or LANs for Local Area Network in English) to create a virtual local area network consisting of the union of the two original LAN networks. There are many technologies for implementing a VPN. These technologies are typically found in carrier network infrastructure equipment and Internet gateways for the general public. These technologies can also be implemented on a computer using specific software, such as openVPN, SoftEther, L2TP, etc. A typical VPN configuration based on a tunneling technique is illustrated in FIG. 1 (and described in detail later). In this example, Tunnel End Points are not integrated into the gateways. The tunnel is established between two tunnelheads, and each packet of data sent to a device connected to the remote LAN is encapsulated by the local tunnel endpoint, then sent to the remote tunnelhead which will unpack it and send it to the remote LAN. The equipment of these LANs is virtually connected to the same LAN. A communication between two devices via the tunnel is called end-to-end communication (end-to-end communication). To transparently communicate and get rid of non-routable addresses, RPVs use a special encapsulation called tunneling which creates what is called a tunnel. This operation consists of encapsulating an A level protocol (embedded protocol) in a B protocol (transport protocol) using a C encapsulation protocol, B being higher than A in a layer model such as the OSI model. (for Open Systems Interconnection) which describes the services offered by each of these layers and their interactions. Moreover, in order to ensure the security and confidentiality of the communications transiting the tunnel using the Internet infrastructure, the security protocols are commonly used. The Transport Layer Security (TLS) protocol, formerly known as Secure Socket Layer (SSL), is an example of a protocol widely used for this purpose. It operates in a client / server mode, providing four security objectives: server authentication, confidentiality of exchanged data (or encrypted session), integrity of exchanged data, and optionally, client authentication with usage. a digital certificate.

A TLS session is initiated by the client and begins with a phase of authentication and negotiation of the algorithm and encryption keys to be used during the session. The encryption of the information to be transmitted by the source and the corresponding decryption by the destination are central elements of the TLS protocol. It should be noted that encryption and decryption are relatively expensive operations in terms of CPU resources, all the more so as the bit rate of the encrypted transmission is high. It should be noted that modern audio / video applications, ie high definition applications, require high data rates as well as low transmission times. 2. TECHNOLOGICAL BACKGROUND Within a local area network, tunnel end-of-pipe equipment is typically responsible for managing multiple encapsulated data streams in tunnels from or to audio / video or processing equipment. data on one or multiple remote networks. During the conventional approach of establishing a secure TLS-type connection between the tunnel endpoints located on their respective networks for each of the active tunnels, the said end-points end up with the load of the CPU resources corresponding to the encryption operations and decryption associated with all the active data streams simultaneously. Thus, said tunnel heads end up processing a large amount of data (this is called a bottleneck), which causes a deterioration in the transmission speed of audio / video data at high speed.

In order to decongest said tunnel heads and to increase the amount of high-speed data capable of being processed by them, a first conventional solution is to increase the computing capacity of said tunnel heads. This solution, however, increases the cost of such equipment and its energy consumption. OBJECTIVES OF THE INVENTION The invention, in at least one embodiment, has the particular objective of overcoming these various disadvantages of the state of the art. More specifically, in at least one embodiment of the invention, an objective is to provide a connection management technique via a tunnel for deferring the encryption / decryption resources related to the management of secure connections of a head of the invention. tunnel on a terminal device to unload the tunnel head. Another objective of at least one embodiment of the invention is to reduce the performance degradation of a terminal equipment incorporating an onboard tunnel end. At least one embodiment of the invention also aims to provide such a technique offering the ability to route an additional number of data streams on a tunnel. More specifically, one goal is to reduce data exchange delays on a tunnel.

A complementary objective of at least one embodiment of the invention is to provide such a technique that is simple to implement and inexpensive. SUMMARY OF THE INVENTION In a particular embodiment of the invention, there is provided a method for managing at least one connection established via a tunnel supported by a main communication network, said tunnel being implemented between first and second tunneling heads respectively connected to first and second subnetworks, each connection permitting data transmission between a client device and a server device via said tunnel, said client device and said server device being connected to one another; first subnet and the second subnet. According to the invention, the method comprises a step of attempting to switch to an unloading mode that is performed by at least one of said first and second tunnel heads, said tunnel head to be unloaded. The step of attempting to failover comprises the following steps: selection of at least one server device and / or at least one client device, said selected device, such that: it is connected to the subnet to which is connected said tunnel end to unload, it is involved in a secure connection encrypted and conveyed by said tunnel, said connection being established or to establish, and it has a sufficient amount of encryption / decryption resources; for each selected device, triggering a negotiation of a secure connection between said selected device and the remote tunnel head of the tunnel head to be unloaded; in the event of successful negotiation for a given secure connection, switching of said tunnel head to be unloaded in an unloading mode, for said given secure connection, the unloading mode being such that said tunnel head to be unloaded does not perform encryption / decryption operation for said given secure connection. The general principle of the invention, on the tunnel head end to be unloaded, therefore consists in performing, for a given connection, an attempt to switch to an unloading mode by selecting a terminal device capable of taking over, in place of this tunnel head to unload, resources related to encryption / decryption operations. Thus, in this particular embodiment, the invention is based on a completely new and inventive approach consisting of delaying the CPU load related to the encryption operations of the tunnel head to be unloaded on a terminal device, when this proves to be the case. possible, in order to unload this tunnel head to unload. In this way, the tunnel head to be unloaded, freeing itself of such resources, is now able to support additional data packets and hence to handle a larger number of high-speed streams. Advantageously, said step of attempting to switch is performed on detection of an event belonging to the group comprising: - openings of a new connection on said tunnel; detecting a limitation of encryption / decryption resources of said tunnel head to be unloaded. The criteria for performing the failover attempt may be based on one or more combined items in this list. In addition, this list is not exhaustive. It should be noted that the resource limitation detection step is based on a comparison with a previously determined CPU threshold.

Advantageously, said step of triggering a negotiation comprises a step of sending a negotiation request to said remote endpoint. Thus, sending a negotiation request to the remote tunnel endpoint makes it possible for the latter to signal a negotiation for the establishment of a secure connection between the selected device and the tunnel head to be unloaded. will be tested. According to an advantageous characteristic, if after a first iteration of said step of attempting to switch, performed by one of said first and second tunnel heads, said tunnel head to be unloaded first iteration, said tunnel head to unload first iteration has switched to said unloading mode for at least one given secure connection, called secure connection of first iteration, involving at least one given selected device, said selected device of first iteration, then in a second iteration of said step of attempting to switch, performed by the other of said first and second tunneling heads: * if said selecting step selects at least one server device and / or at least one client device involved in said first iteration secure connection, then said triggering step of a negotiation includes a step of sending a request e negotiation to said selected first iteration device for said secure connection of first iteration.

Thus, when one of said first and second tunnel heads makes an attempt to switch to the unload mode (tunnel head to be unloaded), and the other one of said first and second tunnel heads has already already switched to the unloading, then sending a negotiation request for triggering a negotiation is no longer sent to the remote tunnel endpoint, but directly to the selected device, aiming to establish a secure end-to-end connection, that is, between the client and the server. Indeed, since the tunnel head has already switched to the unloading mode for a given connection, it can no longer receive the negotiation request, as in the previous case. This connection will therefore, for this particular embodiment of the invention, undergo a transformation to ensure that it is the terminal device remote from the tunnel head to be unloaded which is responsible for receiving the negotiation request. instead of the tunnel head that has previously switched to the unloading mode. Advantageously, said tunnel head to be unloaded, when it operates in the unloading mode for a given secure connection, performs the following steps: - when receiving a message from the remote tunnel head on the tunnel: * decapsulation said message, by removing a first header for conveying said message between the tunnel heads, to obtain a message désencapsulé; * Retransmitting the unencapsulated message on the subnet to which is connected said tunnel head to be unloaded, to the device selected for said given secure connection; when receiving a message from the device selected for said given secure connection: encapsulation of said message by preceding it with a first header serving to convey said message between the tunnel heads, making it possible to obtain a message encapsulated; * retransmitting the encapsulated message on the tunnel, to the remote tunnel endpoint. Indeed, following the switchover in the unloading mode, when receiving messages on the tunnel head to be unloaded, the latter then performs a reconfiguration of the encapsulation means which depends on the origin of the messages for a given secure connection. This particular treatment makes it possible to convey the messages on the tunnel. In a variant, said tunnel head to be unloaded, when it operates in said unloading mode for a given secure connection, performs the following steps: - when receiving a message from the remote tunnel head on the tunnel, said step of retransmission of the message is preceded by the following step: * decryption of a second header belonging to the unencapsulated message, using a specific key previously negotiated with the remote tunnel endpoint when establishing the tunnel, said second header for conveying said message on said first and second subnetworks; when receiving a message from the selected device for said given secure connection, said encapsulation step is preceded by the following step: encrypting a second header of said message, using a specific key previously negotiated with the remote tunnel head when establishing the tunnel, said second header serving to convey said message on said first and second sub-networks.

In another embodiment of the invention, there is provided a method for managing at least one connection established via a tunnel supported by a main communication network, said tunnel being implemented between first and second tunnel heads. connected respectively to first and second subnetworks, each connection permitting data transmission between a client device and a server device via said tunnel, said client device and said server device being connected to the first subnet and the other to the second subnet. According to the invention, the method comprises the following steps, carried out by at least one of said first and second tunnel head, said remote tunnel head, the tunnel head other than the remote tunnel end being called tunnel head to be discharged: negotiating a secure connection with a device selected by said tunnel head to be unloaded; in the case of successful negotiation, for said secure connection, switchover of said remote tunnel endpoint in a security proxy mode (TLS proxy), the security proxy mode being such that said remote remote tunnel endpoint performs encryption operations / decryption for said given secure connection in relation to said selected device. Thus, seen from the remote end of the tunnel end, the principle consists in negotiating a secure connection with a device selected by the remote tunnel endpoint to switch it to a secure proxy mode.

Advantageously, said negotiation step is performed after a step of receiving a negotiation request from said tunnel head to be unloaded.

Advantageously, said remote tunnel head, when it operates in the secure proxy mode for a given secure connection, performs the following steps - when receiving a message from the tunnel head to be unloaded on the tunnel: * decapsulation said message, by removing a first header for conveying said message between the tunnel heads, to obtain a message désencapsulé; * decryption of a payload belonging to the unencapsulated message, using a specific key previously negotiated with the device selected in said negotiation step, to obtain a decrypted message; retransmitting the decrypted message on the subnet to which said remote tunnel endpoint is connected, to a client or server device; when receiving a message from a client or server device: enciphering a payload of said message, by using a specific key previously negotiated with the device selected during said negotiation step, making it possible to obtain an encrypted message; encapsulating said encrypted message by preceding it with a first header for conveying said encrypted message between the tunnel ends, to obtain an encapsulated message; * retransmission of the message encapsulated on the tunnel, to the tunnel head to unload. Alternatively, said remote tunnel head, when operating in the secure proxy mode for a given secure connection, performs the following 25 steps - when receiving a message from the tunnel head to be unloaded on the tunnel said step of retransmitting the decrypted message is preceded by the following step * deciphering a second header belonging to the unencapsulated message, by using a specific key previously negotiated with the tunnel head to be unloaded during the establishment of the tunnel, said second header serving to convey said decrypted message to said first and second sub-networks; when receiving a message from a client or server device, said encapsulation step is preceded by the following step: enciphering a second header of said encrypted message, using a negotiated specific key previously with the tunnel head to be unloaded during the establishment of the tunnel, said second header serving to convey said encrypted message on said first and second sub-networks. In another embodiment, the invention relates to a computer program product downloadable from a communication network and / or recorded on a computer readable medium and / or executable by a processor, said computer program product comprising instructions program code for implementing the aforementioned method (in at least one of the embodiments), when said program is executed on a computer.

In another embodiment, the invention relates to a storage medium, possibly completely or partially removable, readable by a computer, storing a set of instructions executable by said computer to implement the aforementioned method (in at least one of the embodiments). In another embodiment, the invention relates to an unloaded tunnel head for the management of at least one connection established via a tunnel supported by a main communication network, said tunnel being implemented between first and second tunnel heads connected respectively to first and second subnetworks, said tunnel head to be discharged being one of said first and second tunneling heads, each connection permitting data transmission between a client device and a server device via said tunnel said client device and said server device being connected to the first subnet and the second subnet. According to the invention, said tunnel head to be unloaded comprises means for attempting to switch to an unloading mode, said means for attempting a switchover comprising: means for selecting at least one server device and / or at least one client device, said selected device, such as: it is connected to the subnet to which is connected said tunnel head to be unloaded, it is involved in a secure connection by encryption and conveyed by said tunnel, said connection being established or to be established, and has a sufficient amount of encryption / decryption resources; triggering means, for each selected device, of a negotiation of a secure connection between said selected device and the remote tunnel head of the tunnel head to be unloaded; and - failover means, in the event of successful negotiation for a given secure connection, of said tunnel head to be unloaded in an unloading mode, the unloading mode being such that said tunnel head to be unloaded does not perform encryption / decryption operation for said given secure connection. Advantageously, the tunnel head to be unloaded comprises means for detecting an event belonging to the group comprising: - openings of a new connection on said tunnel; detecting a limitation of encryption / decryption resources of said tunnel head to be discharged, and said means of attempting to switch over are activated if said detection means detect an event. According to an advantageous characteristic, said means for triggering a negotiation comprise means for sending a negotiation request to said remote tunnel endpoint. Advantageously, the tunnel head to be unloaded comprises, for the implementation of said unloading mode for a given secure connection: first means for processing a message from the remote tunnel endpoint, including themselves: means for de-encapsulating said message, by removing a first header serving to convey said message between the tunnel heads, making it possible to obtain a message that is de-encapsulated; means for retransmitting the unencapsulated message on the sub-network to which said tunnel head to be unloaded is connected, to the device selected for said given secure connection; second means for processing a message from the device selected for said given secure connection, comprising themselves: means for encapsulating said message by preceding it with a first header serving to convey said message between the tunnel heads, to obtain an encapsulated message; means for retransmitting the message encapsulated on the tunnel, to the remote tunnel endpoint. In a variant, the tunnel head to be unloaded comprises, for the implementation of said unloading mode for a given secure connection: when said first processing means are activated: means for decrypting a second header belonging to the unencapsulated message, using a specific key previously negotiated with the remote tunnel endpoint, said second header serving to convey said message on said first and second subnetworks; when said second processing means are activated: means for encrypting a second header of said message, by using a specific key previously negotiated with the remote tunnel head during the establishment of the tunnel, said second head for conveying said message on said first and second sub-networks.

In another embodiment of the invention, a remote tunnel terminal is proposed for managing at least one connection established via a tunnel supported by a main communication network, said tunnel being implemented between first and second links. and second tunnel heads respectively connected to first and second subnetworks, each connection permitting data transmission between a client device and a server device via said tunnel, said client device and said server device being connected to the first sub-network. and the other to the second subnet, the tunnel end other than the remote tunnel end being called the tunnel end to be unloaded. According to the invention, said remote tunnel head comprises: means for negotiating a secure connection with a device selected by said tunnel head to be unloaded; switching means, in the event of successful negotiation for said secure connection, of said remote tunnel endpoint in a secure proxy mode (TLS proxy), the security proxy mode being such that said remote tunnel endpoint performs encryption / decryption operations for said given secure connection in relation to said selected device. Advantageously, the remote tunnel head includes means for receiving a negotiation request from said tunnel head to be unloaded. Said negotiation means are activated on reception of a negotiation request by said reception means. Advantageously, the remote tunnel head includes, for the implementation of said mode of securing proxy for a given secure connection: first means for processing a message of the tunnel head to be unloaded on the tunnel, including them- same: * means for de-encapsulation of said message, by removing a first header used to convey said message between the tunnel heads, to obtain a de-encapsulated message; means for decrypting a payload belonging to the de-encapsulated message, by using a specific key previously negotiated with the device selected during said negotiation step, making it possible to obtain a decrypted message; means for retransmitting the decrypted message on the subnet to which said remote tunnel endpoint is connected to a client or server device; second means for processing a message from a client or server device, comprising themselves: means for encrypting a payload of said message, by using a specific key previously negotiated with the device selected during the said negotiation step, for obtaining an encrypted message; Encapsulation means of enciphering said encrypted message by preceding it with a first header serving to convey said encrypted message between the tunnel ends, making it possible to obtain an encapsulated message; means for retransmitting the message encapsulated on the tunnel, to the tunnel head to be unloaded. In a variant, the remote tunnel head comprises, for implementing said security proxy mode for a given secure connection: when said first processing means are activated: means for decrypting a second header belonging to the unencapsulated message, using a specific key previously negotiated with the tunnel head to be unloaded during the establishment of the tunnel, said second header serving to convey said message decrypted on said first and second sub-networks; when said second processing means are activated: means for encrypting a second header of said encrypted message, by using a specific key previously negotiated with the tunnel head to be unloaded during the establishment of the tunnel, said second header for conveying said encrypted message on said first and second subnetworks. 5. LIST OF FIGURES Other features and advantages of embodiments of the invention will become apparent on reading the following description, given by way of indicative and nonlimiting example (not all the embodiments of the invention are not limited to the features and advantages of the embodiments described hereinafter), and the accompanying drawings, in which: - Figure 1 shows a typical virtual private network (VPN) configuration implementing a tunnel; FIG. 2 shows an exemplary model (OSI) in a conventional layer of a tunnel head in which the method according to the invention can be implemented; FIG. 3 shows the structure of a communication apparatus (tunnel head type), according to a particular embodiment of the invention; FIG. 4 shows a simplified sequence of messages exchanged in the context of an unloading of a tunnel endpoint associated with a server, according to a particular embodiment of the invention; - Figure 5 shows a simplified sequence of messages exchanged in the context of unloading a tunnel head associated with a client, according to a particular embodiment of the invention; FIG. 6 shows a simplified sequence of messages exchanged in the context of end-to-end unloading, according to a particular embodiment of the invention; FIG. 7 presents a flowchart of a resource limitation detection algorithm, according to a particular embodiment of the method according to the invention; FIG. 8 presents a flowchart of a particular embodiment of the connection management method according to the invention; FIG. 9 presents a flowchart of an algorithm for selecting a terminal device, according to a particular embodiment of the method according to the invention; FIG. 10 presents a flowchart of a negotiation algorithm for establishing a secure connection, according to a particular embodiment of the method according to the invention; and each of FIGS. 1a, 1b and 1b represents a flowchart of a particular operating mode implemented by the tunnel heads according to the invention (FIG. 11a illustrating the tunnel mode, FIG. unloading and figurellc illustrating the TLS proxy mode). DETAILED DESCRIPTION In all the figures of this document, the elements and identical steps are designated by the same numerical reference. FIG. 1 represents a typical virtual private network (VPN) configuration in which the invention can be implemented. It presents a tunnel 100 between a local tunnel head 101 and a remote tunnel head 102, through a communication network 107 of the Internet type for example. This tunnel 100 interconnects two subnetworks: LAN A 103 and LAN B 104. Each of the subnetworks 113 and 104 includes broadband Internet access equipment (home gateway, or home gateway) capable of integrating a network. Firewall 105 and 106, client-type terminal equipment such as PCs 109 and 111, or digital media rendering devices 108 and 112, as well as server-type end devices 110 and 113 for storing and sharing data. digital media (audio, video, photo type) A tunnel end can be integrated in audiovisual equipment such as a digital television, or it can be present in PC-type equipment in the form of a program performing the associated functions to this one.

Once the tunnel 100 is established, the devices 108, 109, and 110, connected to the LAN subnet A 103, are capable of communicating with the devices 111, 112 and 113, connected to the LAN sub-network B 104. For example, the client 108 connected to the A 103 LAN subnet can communicate with the server 113 connected to the B LAN subnet 104.

In this FIG. 1, there is shown a simple communication network with only one tunnel, but it is understood that the same tunnel head may be required to manage a plurality of tunnels (to as many remote tunnel endpoints ) to interconnect a first LAN subnet to several other LAN subnets, as well as a plurality of connections. In addition, for the sake of simplification, infrastructure equipment in the Internet network such as Internet routers has not been represented. In relation with FIG. 2, the path of an Ethernet frame originating from one of the devices 108, 109, 110, connected to the subnet B 103 B, and entering the tunnel 100 is now presented. To do this, one uses a layer model describing the protocol layers necessary for the implementation of this tunnel 100. In this model are not represented the protocol elements necessary for the functions other than the implementation of the tunnel. For example, the protocol elements associated with a UPnP architecture are not represented when a tunnel head 101 is integrated in UPnP equipment.

The tunnel head 101 comprises an Ethernet physical interface 208 which delivers the Ethernet frames from the equipment 108, 109, 110 to the link layer 207 for routing: to the network layer 206, for the Ethernet frames destined for the equipment comprising the device. tunnel end, or to the bridge layer 209, for the other Ethernet frames. The bridge layer 209 performs the typical operations of an Ethernet bridge such as filtering the Ethernet frames and relaying these frames to the appropriate output Ethernet port (s). On the bridge are attached an Ethernet interface 207 and at least one virtual interface 210 simulating an Ethernet controller. A virtual interface 210 is created for each tunnel instantiated by the application 200 to which it gives the Ethernet frames that must pass on the tunnels respectively instantiated. In general, the encapsulation protocol of the tunnel represented by the application 200 carries out the operations necessary for the implementation of each tunnel, among which we find in particular the configuration, the filtering, the encapsulation that is that is, the formation of a tunnel packet, and the extraction of a frame. The frames received from the virtual interface 210, after processing by the application 200, are delivered in the form of a packet through an application interface (socket in English) 201 to a reliable transport protocol TCP 203 or unreliable UDP 205, respectively secured by the SSL 202 and DTLS 204. After processing by a transport protocol to form the tunnel packet 250, it passes it to the network layer 206. The IP datagram thus formed with the tunnel package can now be transmitted over the LAN subnet through the link layers 207 and physical 208. The reception of a frame from the tunnel 100 will follow in the tunnel head the reverse path to that presented above. With reference to FIG. 3, the schematic structure of a communication device 300, such as a tunnel head 101 or 102 shown in FIG. 1 using the technique of the invention, is now presented. This device comprises a RAM 302 which functions as a main memory, a work area, etc., of the central processing unit (CPU) 301. The central processing unit 301 is capable, when the communication device is powered up. to execute instructions from program ROM 303. After power-on, CPU 301 is able to execute instructions from main memory 302 in connection with a software application after these instructions have been executed. have been loaded from the program ROM 303 or the hard disk 306 (or removable storage means such as for example a floppy disk, a CD-ROM or a DVD-ROM (not shown)). Such a software application, when executed by the CPU 301, causes all or some of the steps of the flowcharts shown in FIGS. 7, 8, 9, 10, 11a, 11b and 11c to be performed. Note that the invention is not limited to a purely software implementation (as described above) but it can also be implemented in a form of a hardware or any form mixing a hardware part and a software part .

FIG. 4 shows a simplified connection management sequence between a client 108, a server 113 and their respective tunnel heads 101 and 102, when a connection between the client and the server employing the tunnel is modified to unload the tunnel head 102 associated with the server 113 encryption operations, according to the method according to the present invention. In the initial state, there is an IP connection between the client 108 and the server 113, unsecured at the respective subnets 103 and 104, conveyed by the Internet 107 via a tunnel 100 established between the two tunnel ends 101 and 102. The data packets 301 exchanged between the server 113 and the client 108 and transiting on the respective subnets 104 and 103 then comprise an IP header and a payload. Preferably, encapsulation at tunnel level 100 is performed in the conventional manner described in IETF RFC 3931 ("Layer two tunneling protocol version 3 (L2TPv3)", J. Lau and All, March 2005) and the Tunnel connection between Tunnel Heads 101 and 102 is a TLS compliant secure TCP / IP connection, in accordance with IETF RFC 4346 ("The Transport Layer Security (TLS) Protocol-Version 1.1", T. Dierks, E. Rescorla, April 2006). On the tunnel, each data packet 301 from client 108 or server 113 respectively is then encapsulated by their respective tunnel head in a data packet 302 comprising: a tunnel header TH (for Tunnel Header) ; more specifically, these are the headers of the tunnel TCP / IP connection between tunnel heads 101 and 102, as well as signaling fields; - a TLS (for Transport Layer Security) header; the original data packet 301, corresponding to the payload, encrypted by the transmitting tunnel head according to the TLS protocol.

Said data packet 302 is then de-encapsulated and decrypted by the receiving tunnel head so as to restore the original data packet 301. The latter is then retransmitted on the subnetwork associated with the receiving tunnel head, destined for the server 113 or customer 108 respectively. Following a resource limitation detection (see FIG. 8) or an opening of a new connection on the tunnel, the tunnel head 102 associated with the server 113, initiates an attempt to switch to an unloading mode (as described in FIG. 8) by first selecting the server 113 (cf. FIG. 9), and then initiating a negotiation, using a negotiation request 404 sent to the other tunnel head 101, aimed at securing the connection between the tunnel head 101 and the server 113 (see FIG. 10). In the case of successful negotiation, a secure connection of the TLS type is established between the tunnel head 101 and the server 113 (the tunnel head 101, seen from the server 113, actually acts for the client 108 as a TLS proxy). The tunnel head 102 then implements a failover mechanism in a particular mode, called unloading mode, to enable it to unload the encryption resources on the selected server 113. The synchronization of the steps previously described, executed by the heads tunnel 101 and 102, is carried out following a simple signaling between said tunnel heads. For example, each tunnel head is capable of detecting the switchover 405 between sending data packets of type 302 to type 303 through the opposite tunnel head. It should be noted that when the tunnel head 101 or the tunnel head 102 manages several connections in parallel, on the same tunnel or not and between the same server and client equipment or not, the operating modes of each tunnel head for each of the connections will evolve independently of each other. The mode of unloading operation of the tunnel head 102 as well as the TLS proxy mode of the tunnel head 101 are maintained until the closure of the connection concerned (FIN message described in the document IETF RFC 793 "TRANSMISSION CONTROL PROTOCOL" , September 1981). In the unloading mode of said tunnel endpoint, the data packets of the connection in question continue to transit in format 301 on subnet 103 between client 108 and the associated tunnel end 101. Since TLS secure TCP / IP connection was established between the tunnel head 101 and the server 113, the data packets 303 passing through the tunnel as well as the corresponding data packets 304, passing over the subnet 104 between the tunnel head 102 and server 113, accordingly comprise a TCP / IP header, a TLS header and an encrypted payload in accordance with said TLS protocol. Note further that for the data transmitted from the server 113 to the client 108, the encryption is performed by the server 113 and the decryption is performed by the tunnel head 101, and vice versa for the data transmitted in the opposite direction . In the tunnel, said data packet 304 is encapsulated in the packet 303, with addition of the TH tunnel header as mentioned above. Optionally, each tunnel head can apply in the tunnel a partial encryption of the packets 303, covering only IP headers and possibly TLS, the payload already being encrypted. The resources induced by this encryption at the level of the tunnel heads remain negligible, the size of the IP and / or TLS headers being much smaller than the size of the payload. In a similar manner to FIG. 4, in connection with FIG. 5, a simplified connection management sequence is presented between a client 108, a server 113 and their respective tunnel heads 101 and 102, when a connection between the client and the server employing the tunnel is modified so as to unload the client-associated tunnel head 101 from the encryption operations, according to the method according to the present invention. In the initial state, there is an IP connection between the client 108 and the server 113, unsecured at the respective subnets 103 and 104, conveyed by the Internet 107 via a tunnel 100 established between the two tunnel ends 101 and 102. The format and processing of the IP data packets 301 and 302 in this state of the connection is identical to the previous case.

Following a resource limitation detection (see FIG. 8), the tunnel head 101 associated with the client 108, starts an attempt to switch to an unloading mode (as described in FIG. 8) by selecting all the d first client 108 (see Figure 9), then initiating a negotiation, using a negotiation request 504 sent to the other tunnel head 102, to secure the connection between the tunnel head 102 and the client 108 (see FIG. In the case of successful negotiation, a secure connection of the TLS type is established between the tunnel head 102 and the client 108 (the tunnel head 102, seen from the client 108, actually acts for the server 113 as a TLS proxy). The tunnel head 101 then implements a failover mechanism in a particular mode, called unloading, to enable it to unload the encryption resources on the selected client 108. The synchronization of the steps previously described, executed by the heads tunnel 101 and 102, is carried out following a simple signaling as described above. The unloading mode of the tunnel end 101 as well as the TLS proxy mode of the tunnel head 102 are maintained until the closure of the connection concerned (FIN message described in the document IETF RFC 793 "TRANSMISSION CONTROL PROTOCOL", September nineteen eighty one). In the unloading mode of said tunnel endpoint, the data packets of the connection in question continue to transit in format 301 on the subnet 104 between the server 113 and the associated tunnel end 102. TLS secure TCP / IP connection was established between the tunnel head 102 and the client 108, the data packets 303 passing through the tunnel as well as the corresponding data packets 304, transiting on the subnet 103 between the tunnel head 101 and the client 108, accordingly comprise a TCP / IP header, a TLS header and an encrypted payload in accordance with said TLS protocol. Note further that for the data transmitted from the client 108 to the server 113, the encryption is performed by the client 108 and the decryption is performed by the tunnel head 102, and vice versa for the data transmitted in the opposite direction . In the tunnel, said data packet 304 is encapsulated in the packet 303, with addition of the TH tunnel header.

Optionally, each tunnel head can apply in the tunnel a partial encryption of the packets 303, covering only IP headers and possibly TLS, the payload already being encrypted. The resources induced by this encryption at the level of the tunnel heads remain negligible, the size of the IP and / or TLS headers being much smaller than the size of the payload. A simplified sequence of messages exchanged in the context of an end-to-end unloading according to a particular embodiment of the invention is now presented in relation to FIG. This sequence is implemented between a client 108, a server 113 and their respective tunnel heads 101 and 102, when a connection between the client and the server employing the tunnel and previously transformed so as to discharge the associated tunnel head 101 the client 108 encryption operations (as described in Figure 5) undergoes an additional transformation, further to unload the tunnel head 102 associated with the server 113, according to the method according to the present invention. In the initial state, there is an IP connection between the client 108 and the server 113, unsecured at the subnet 104 and secured by TLS between the tunnel head 102 and the client 108, as described above at 5 At a certain moment, the tunnel head 102 associated with the server 113, following a resource limitation detection (see FIG. 7), starts an attempt to switch to the unloading mode (FIG. see Figure 8) by selecting the server 113 (see Figure 9), then triggering a negotiation, using a negotiation request 604 sent to the client 108, to secure the end-to-end connection in progress between the client 108 and the server 113 (see FIG. In the case of successful negotiation, a secure connection of the TLS type is established server 113 and the client 108. The tunnel head 102 in turn implements a tilt mechanism in the unloading mode (as has already been the case previously for the tunnel head 101) in order to be able to discharge encryption resources on the selected server 113. Therefore, packets 304 protected according to the TLS protocol pass over the subnetworks 103 and 104. While passing through the tunnel, said packets are encapsulated in packets 303 as described above. It should be noted that the two tunnel heads 101 and 102 are then discharged from the payload encryption task included in the packets 303. Optionally, the tunnel heads will apply in the tunnel a partial encryption of the packets 303 such that described above. The synchronization of the steps described above, executed by the tunnel heads 101 and 102, is carried out following a signaling protocol and a request processing between said tunnel heads (see FIGS. 12 and 13). The unloading mode of the tunnel heads 101 and 102 is maintained until the closure of the connection concerned. We now present, in connection with Figure 7, an algorithm for detecting limitation of encryption resources / decryption, according to a particular embodiment of the method of the invention. This algorithm aims to detect a computation resource limitation condition, corresponding to encryption / decryption operations at a tunnel head, such as for example the tunnel head 101 or 102. Step 701 is to take into account a possible default configuration of the tunnel head. In a particular embodiment, each tunnel head is configured to apply the unloading mode in a systematic and unconditional manner. The processing then continues with step 704. In the opposite case, additional steps 702 or 703 are executed. Step 702 relates to the availability of tunnel channels; it is applicable in particular when encryption and decryption at the tunnel level are implemented by a dedicated hardware (such as FPGA, ASIC hardware) and when there is a limitation in terms of encryption / decryption channels likely to be treated parallel, due to the design of the material. As for step 703, it concerns the availability of the encryption / decryption CPU resources. Multitasking operating systems commonly used in the field of embedded software frequently provide a functionality to estimate the percentage of CPU resource utilization; step 703 will then be validated only when this percentage is below a certain threshold, fixed and predetermined or variable depending on the flow of the data stream to be conveyed on the connection in question. In the case of failure of one of the steps 702 or 703, the processing continues with the step 704. The execution of this last step allows said connection to be marked as being eligible for the application of the method of unloading.

FIG. 8 shows a particular mode of operation of the connection management method according to the invention. More particularly, it relates to an algorithm for performing an attempt to switch in the unloading mode of a tunnel head. The method is carried out by the tunnel head 101 and / or 102 when opening a new connection on the tunnel or during a resource limitation detection according to the description relating to FIG. 8. First of all, , step 802 of selecting the client or server is activated (see Figure 9). Following the selection of one of said client or server, the step 803 denominated negotiation for the establishment of a secure connection is set up. This step is described in more detail in connection with FIG. 10. The outcome of step 804 depends on the success of said negotiation. During a positive outcome, the step 805 of switching to an unloading mode is activated (see FIGS. 4, 5 and 6 above), thus making it possible to unload the tunnel head in question from the encryption resources. or decryption.

FIG. 9 presents an algorithm for selecting a terminal device, according to a particular embodiment of the method according to the invention. It describes a method of selecting a client or a server for a given connection, executed by the tunnelheads 101 and / or 102, so as to initiate an attempt to switch to the unload mode for a connection involving the server or client selected. This selection starts with step 901 which makes it possible to analyze the traffic passing through the tunnel end 101 (respectively 102) between the sub-network 103 (respectively 104) and the tunnel connected to the other sub-network 104 (respectively 103). Step 902 is to detect TCP connection open messages (SYN message, described in IETF RFC 793 "TRANSMISSION CONTROL PROTOCOL", September 1981) from a client on the subnet and entering the tunnel. For example, tunnel head 101 receives a SYN message from client 108 through subnet 103. And step 902 also aims to detect TCP connection open confirmation messages (SYNACK message, described in FIG. IETF RFC 793 "TRANSMISSION CONTROL PROTOCOL", September 1981) from a remote server, out of the tunnel and destined for a local client. For example, the tunnel head 101 receives a SYN-ACK message from the server 113 through the tunnel, destined for the client 108. When the step 902 is successful, then the step 908 is then executed or, in the case Instead, step 903. Step 903 is to detect TCP connection open confirmation messages from a server, this time, located on the subnet and entering the tunnel (the head). of tunnel 102 receives a SYN-ACK message from server 113 by network 104 for example) or TCP connection opening messages (SYN message) from a remote client, leaving the tunnel and destined for a local server ( the tunnel head 102 receives a message SYN from the client 108 through the tunnel, intended for the server 113, for example). In step 903 is successful, then step 904 is then executed or step 912 otherwise. In step 904, the tunnel head reads in the header of the received message the IP address of the server involved in establishing an IP connection. Step 905 consists in recovering from the internal database of the tunnel head information associated with said server, in particular, its ability to accept encrypted connection establishment requests so as to discharge the tunnel end in accordance with the present invention. This database preferably stores the knowledge acquired regarding the amount of server resources during past failover attempts in the unloading mode (see FIG. 10, step 1059). For example, a server that has previously been unable to accept a request for unloading by the tunnel endpoint will be considered ineligible for unloading. Processing continues with step 912. Otherwise, step 907 is executed. It consists of marking the server that the switchover in the unloading mode can take place (see FIG. 8, step 803). Steps 908, 909, 910, and 911 are similar to steps 904, 905, 906, and 907, but are concerned with making decisions about the eligibility of a client instead of a server. It should be noted that the same terminal equipment may sometimes act as a server and sometimes as a client and that the ability to accept a secure connection request may not be the same in both cases. Finally, the step 912 consists of marking with the aid of the tunnel endpoint, said server or client a failure of the attempt to switch to the unloading mode.

FIG. 10 shows a flowchart of a negotiation algorithm for establishing a secure connection, according to a particular embodiment of the method according to the invention. More specifically, this flowchart illustrates the different negotiation steps, as they are introduced in FIGS. 4, 5 and 6, making it possible to transform the TCP / IP connection into a secure connection between a tunnel end and a server or a client. . Depending on the marking performed previously (see Figure 9), step 1051 or 1055 may succeed. If step 1051 is successful, tunnelhead 101 proceeds to step 1052, requesting client 108 to update the current TCP / IP connection to the secure mode. In a preferred embodiment of the present invention, in particular the HTTP connections conveyed over the TCP / IP protocol are treated. One method of updating an unsecured HTTP / 1.1 connection to a secure TLS connection is described in the document entitled IETF RFC 2817 ("Upgrading to TLS Within HTTP / 1.1", R. Khare, S. Lawrence, May 2000 ).

In accordance with Section 4 of this document, titled Server Requested Upgrade to HTTP over TLS, and in particular Section 4.1 Optional Advertisement, Tunnel Endpoint 101 inserts an Upgrade Header Header, as described in IETF RFC 2616 ( "Hypertext Transfer Protocol - HTTP / 1.1", R. Fielding et al., June 1999), section 14.42, indicating that the server is capable of processing the TLS security protocol, in an HTTP response from server 113 and intended for client 108. If client 108 implements the functionality described in IETF RFC 2817, it will respond with an HTTP request specified in section 3 of the document. Otherwise, it will ignore the update request inserted by the tunnel head 101. This reaction of the client 108 conditions the outcome of step 1053. A success of this step then triggers a passage of the tunnel head 101 at step 1054, while rejection means the failure of the negotiation. During step 1054, depending on the capacity of the server 113 to accept an update of an insecure connection to a secure TLS connection, the tunnel head 101 of which will have been previously informed, the tunnel head 101 will follow the connection update request from the client 108 to the server 113 through the tunnel head 102, which results in a TLS security negotiation directly between the client 108 and the server 113. Therefore, the tunnel headers 101 and 102 enter the end-to-end mode of operation described in connection with FIG. 6. Or the tunnel end 101 intercepts the connection update request and responds with an HTTP 101 Switching Protocols, as described in the document IETF RFC 2817, Section 3.3 Server Acceptance of Upgrade Request. The client then initiates a negotiation of a TLS connection according to IETF RFC 2246 ("The TLS Protocol - Version 1.0", T. Dierks, C. Allen, January 1999) or IETF RFC 4346 ("The Transport Layer Security (TLS Protocol - Version 1.1 ", T. Dierks, E. Rescorla, April 2006), resulting from an agreement on the encryption algorithm and an exchange of encryption keys, followed by securing exchanges linked to the connection in progress by encryption. The attempt to unload the tunnel head 101 is then considered successful. As a result, tunnel heads 101 and 102 enter the operating mode described in connection with FIG. 5. At the end of step 1054, step 1060 is executed. It consists in updating the database with the amount of client resources 108 making it possible to make the transition to a secure connection, as tested at step 1053. Further details concerning the use of this database of data are illustrated in step 909 of Figure 9. Then, the negotiation phase ends successfully, which corresponds to step 1062.

Similarly, the rejection of the client 108 to establish a secure connection at step 1053 triggers a record of the client's inability to establish a secure connection in the database at step 1061. Next, the phase of negotiation ends with a failure corresponding to step 1063. If step 1055 is successful, tunnel end 102 proceeds to step 1056 of requesting server 113 to update the TCP connection. / IP in progress to switch to secure mode. In the preferred embodiment of the present invention, in particular the HTTP connections conveyed over the TCP / IP protocol are treated. In accordance with Section 3 of IETF RFC 2817, Client Requested Upgrade to HTTP over TLS, and in particular section 3.1 Optional Advertisement, Tunnel Endpoint 102 inserts an Upgrade Header header, indicating that the client is capable of handling the TLS security protocol, in an HTTP request from the client 108 and intended for the server 113. If the server 113 implements the functionality described in IETF RFC 2817, it will respond with an HTTP 101 Switching Protocols, as described in the IETF RFC document. 2817, section 3.3 Server Acceptance of Upgrade Request. Otherwise, it will ignore the update request inserted by the tunnel end 102. In the event that the tunnel head 102 receives the HTTP response 101 from the server 113, the latter starts a negotiation of a TLS connection, in accordance with IETF RFC 2246 or IETF RFC 4346, resulting from an agreement on the encryption algorithm and an exchange of encryption keys, followed by securing the exchanges related to the current connection by encryption. The attempt at unloading the tunnel head 102 is then considered successful. Therefore, tunnel heads 101 and 102 enter the operating mode described in connection with FIG. 4. At the end of step 1056, step 1057 is executed. If the server accepts the connection update request previously described, step 1058 is executed. It consists in updating the database with the quantity of resources of the server 113 making it possible to switch to a secure connection, as tested at step 1057. Further details concerning the use of this database data are illustrated in step 909 of FIG. 9. Next, the negotiation phase ends successfully corresponding to step 1062. Similarly, the rejection of server 113 to establish a protected connection in step 1056 initiates a record of the incapacity of said server in said database at step 1059. Then, the negotiation phase ends with a failure corresponding to step 1063.

Each of FIGS. 11a, 11b and 11c represents a flowchart of an operating mode applied by the tunnel heads (FIG. 1 illustrates it in the conventional tunnel mode, FIG. 11b illustrates the unloading mode and FIGS illustrates the TLS proxy mode). . They each illustrate a different mode of operation applied by a tunnel head depending on the current connection, as well as the processing of messages according to these modes.

Tunnel mode 1101 is well known to those skilled in the art. Conventionally, when the tunnel end receives a message from the second tunnel endpoint on the tunnel (event 1102), this first disencapsulates the data packet by first removing the header (TH) specific to the encapsulant protocol, typically based on TCP or UDP, employed on the tunnel (step 1103). In a second step, this first tunnel head deciphers the payload of this data packet by using a specific key previously negotiated with the second tunneling head during the establishment of the tunnel (step 1104). Then, it retransmits in a third time the data packet on the sub-network associated with said tunnel end, destined for the terminal equipment, that is to say the client 108 for the tunnel head 101 or the server 113 for the tunnel head 102 (step 1105). Upon reception by the tunnel end of a data packet from the terminal equipment located on the associated subnet (event 1107), this first digit first of all this data packet using a negotiated specific key previously with the second tunnel end when establishing the tunnel (step 1108). In a second step, it encapsulates the data packet by preceding it with a header (TH) specific to the encapsulant protocol used on the tunnel (step 1109), then retransmits this data packet on the tunnel, destined for the second tunnel head in a third time (step 1110). When the closure of the current connection is detected (event 1111), the tunnel head releases the resources associated with the management of this connection (step 1112), then the connection processing ends (mode 1113). In the unload mode 1201 for a given connection, a tunnel end behaves as follows. Upon reception by the tunnel end of a data packet from the second tunnel endpoint on the tunnel (event 1202), this first disencapsulates the packet by first removing the header (TH). for conveying traffic between the tunnel heads (step 1203). In a second step, said tunnel head decrypts the header belonging to the de-encapsulated data packet by using a specific key previously negotiated with the second tunneling head during the establishment of the tunnel (step 1204), and then retransmits in a third time the packet on its associated subnet, to the terminal equipment, that is to say the client 108 for the tunnel head 101 or the server 113 for the tunnel head 102 (step 1205). Upon reception by the tunnel end of a data packet from the terminal equipment located on the subnet (event 1207), this first digit firstly the header of the received packet using a specific key previously negotiated with the second tunnel head during the establishment of the tunnel (step 1208). In a second step, it encapsulates the data packet by preceding it with a header (TH) specific to the protocol used to convey the traffic between the tunnel heads (step 1209), and then, in a third step, retransmits this message on the tunnel to the second tunnel head (step 1210). When the closure of the current connection is detected (event 1211), the tunnel head releases the resources associated with the management of this connection (step 1212), then the connection processing ends (mode 1213). In TLS 1301 proxy mode for a given connection, a tunnel end behaves as follows. Upon reception by the tunnel end of a data packet from the second tunnel endpoint on the tunnel (event 1302), this first disencapsulates, initially, the data packet by removing the head (TH) for conveying traffic between the tunnel heads (step 1303). In a second step, the tunnel head deciphers the header belonging to the unencapsulated data packet by using the specific key previously negotiated with the second tunneling head during the establishment of the tunnel (step 1304), then in a third time decrypts the payload of said data packet with the TLS key obtained during the negotiation with the terminal equipment located on the subnet associated with the second tunnel head, that is, the client 108 for the head 102 or the server 113 for the tunnel head 101 (step 1305). In a fourth step, it retransmits the message on its associated subnet, to the terminal equipment, that is to say the client 108 for the tunnel head 101 or the server 113 for the tunnel head 102 (step 1306). Upon reception by the tunnel end of a data packet from the terminal equipment located on the subnet (event 1307), this first digit, as a first step, the payload of the message received with the key TLS obtained during the negotiation with the terminal equipment located on the subnet associated with the second tunnel end, ie the client 108 for the TET 102 or the server 113 for the TET 101 (step 1308 ). In a second step, it encrypts the header of the received data packet using a specific key previously negotiated with the second tunnel endpoint during the establishment of the tunnel (step 1309), then encapsulates in a third time the packet of data preceded by a header (TH) specific to the protocol for conveying traffic between the tunnel end (step 1310). Finally, in a fourth step, the tunnel head retransmits this data packet on the tunnel, to the second tunnel end (step 1314). When the closure of the current connection is detected (event 1311), the tunnel head releases the resources associated with the management of this connection (step 1312), then the connection processing ends (mode 1313).

Claims (21)

A method of managing at least one connection established via a tunnel supported by a main communication network, said tunnel being implemented between first and second tunneling heads respectively connected to first and second subnetworks, each connection enabling a data transmission between a client device and a server device via said tunnel, said client device and said server device being connected to one of the first subnet and the other to the second subnet, characterized in that said method comprises a step of attempting to switch to an unloading mode, performed by at least one of said first and second tunnel heads, said tunnel head to be unloaded, said step of attempting to switchover comprising the following steps: - selecting (802) d at least one server device and / or at least one client device, said selected device, such as: it is connected to the sub-server bucket to which is connected said tunnel head to be unloaded, it is involved in a secure connection encrypted and conveyed by said tunnel, said connection being established or to establish, and it has a sufficient amount of encryption / decryption resources; for each selected device, triggering (803) a negotiation of a secure connection between said selected device and the remote tunnel head of the tunnel head to be unloaded; in the case of successful negotiation for a given secure connection, switching (805) of said tunnel head to be unloaded in an unloading mode, for said given secure connection, the unloading mode being such that said tunnel head to be unloaded performs no encryption / decryption operation for said given secure connection. 2. Method according to claim 1, characterized in that said step of attempting to switch is performed on detection of an event belonging to the group comprising: - openings of a new connection on said tunnel; 30 - detections (801) of a limitation of encryption / decryption resources of said tunnel head to be unloaded. 20 3. Method according to any one of claims 1 and 2, characterized in that said triggering step (803) of a negotiation comprises a step of sending a negotiation request to said remote end of the tunnel. 4. Method according to claim 3, characterized in that: - if after a first iteration of said step of attempting to switch, performed by one of said first and second tunnel heads, said tunnel head to unload first iteration, said first iteration head-end toggled (805) in said unloading mode for at least one given secure connection, said first iteration secure connection, involving at least one given selected device, said first iteration selected device, - then in a second iteration of said step of attempting to switch, performed by the other of said first and second tunneling heads: * if said selecting step (802) selects at least one server device and / or at least one client device involved in said secure connection of first iteration, then said triggering step (803) of a negotiation The method includes a step of sending a negotiation request to said selected first iteration device for said secure first iteration connection. 5. Method according to any one of claims 1 to 4, characterized in that said tunnel head to be unloaded, when it operates in said unloading mode for a given secure connection, performs the following steps: - upon receipt of a message from the remote tunnel head on the tunnel: * de-encapsulation of said message, by removing a first header (TH) used to convey said message between the tunnel heads, to obtain a message encapsulated; * Retransmitting the unencapsulated message on the subnet to which is connected said tunnel head to be unloaded, to the selected device for said given secure connection; when receiving a message from the device selected for said given secure connection: encapsulation of said message by preceding it with a first header (TH) serving to convey said message between the tunnel heads, allowing get an encapsulated message; * retransmitting the encapsulated message on the tunnel, to the remote tunnel endpoint. 6. Method according to claim 5, characterized in that said tunnel head to be unloaded, when it operates in said unloading mode for a given secure connection, performs the following steps: when receiving a message from the head remote tunnel tunnel, said step of retransmission of the message is preceded by the following step: decryption of a second header belonging to the message désencapsulé, using a specific key previously negotiated with the remote tunnel end when establishing the tunnel, said second header serving to convey said message on said first and second sub-networks; when receiving a message from the selected device for said given secure connection, said encapsulation step is preceded by the following step: enciphering a second header of said message, using a negotiated specific key previously with the remote tunnel endpoint when establishing the tunnel, said second header serving to convey said message on said first and second sub-networks. 7. A method of managing at least one connection established via a tunnel supported by a main communication network, said tunnel being implemented between first and second tunneling heads respectively connected to first and second subnetworks, each a connection allowing a data transmission between a client device and a server device via said tunnel, said client device and said server device being connected to the first subnet and the second subnet, characterized in that said The method comprises the following steps, performed by at least one of said first and second tunnel endpoints, said remote tunnel head, the tunnel head other than the remote tunnel end being called the tunnel end to be unloaded: a secure connection with a device selected by said tunnel head to be unloaded; in the case of successful negotiation, for said secure connection, switchover of said remote tunnel endpoint in a security proxy mode (TLS proxy), the security proxy mode being such that said remote remote tunnel endpoint performs encryption operations / decryption for said given secure connection in relation to said selected device. 8. Method according to claim 7, characterized in that said negotiation step is performed after a step of receiving a negotiation request from said tunnel head to be unloaded. 9. Method according to any one of claims 7 to 8, characterized in that said remote tunnel head, when it operates in the secure proxy mode for a given secure connection, performs the following steps: - at the reception a message from the tunnel head to be unloaded on the tunnel: * de-encapsulation of said message, by removing a first header (TH) serving to convey said message between the tunnel heads, making it possible to obtain a de-encapsulated message; * decryption of a payload belonging to the unencapsulated message, using a specific key previously negotiated with the device selected in said negotiation step, to obtain a decrypted message; retransmitting the decrypted message on the subnet to which said remote tunnel endpoint is connected, to a client or server device; when receiving a message from a client or server device: enciphering a payload of said message, by using a specific key previously negotiated with the device selected during said negotiation step, making it possible to obtain an encrypted message; encapsulating said encrypted message by preceding it with a first header (TH) serving to convey said encrypted message between the tunnel heads, making it possible to obtain an encapsulated message; Retransmission of the encapsulated message on the tunnel to the tunnel head to be unloaded. 10. Method according to claim 9, characterized in that said remote tunnel endpoint, when it operates in the secure proxy mode for a given secure connection, performs the following steps: - when receiving a message from the tunnel head to be unloaded on the tunnel, said step of retransmission of the decrypted message is preceded by the following step: * decryption of a second header belonging to the unencapsulated message, using a specific key previously negotiated with the tunnel head unloading during tunnel establishment, said second header serving to convey said decrypted message to said first and second sub-networks; when receiving a message from a client or server device, said encapsulation step is preceded by the following step: enciphering a second header of said encrypted message, using a negotiated specific key previously with the tunnel head to be unloaded during the establishment of the tunnel, said second header serving to convey said encrypted message on said first and second sub-networks. 20 11. Computer program product downloadable from a communication network and / or recorded on a computer readable medium and / or executable by a processor, characterized in that it comprises program code instructions for the implementation of the method according to at least one of claims 1 to 6 and / or at least one of claims 7 to 10, when said program is run on a computer. 12. Storage medium, possibly completely or partially removable, readable by a computer, storing a set of instructions executable by said computer to implement the method according to at least one of claims 1 to 6 and / or at least one of the claims 7 to 10. 30 13. Unloaded tunnel head for managing at least one connection established via a tunnel supported by a main communication network, said tunnel being implemented between first and second tunnel heads respectively connected to first and second sub-channels. networks, said tunnel head to be discharged being one of said first and second tunneling heads, each connection permitting data transmission between a client device and a server device via said tunnel, said client device and said server device being connected to each other; one to the first subnetwork and the other to the second subnetwork, characterized in that said tunnel head to be unloaded comprises means for attempting to switch to an unloading mode, said failover attempt means comprising: means for selecting at least one server device and / or at least one client device, said selected device, such as: it is connected to the subnet to which said tunnel head to be unloaded is connected, it is involved in a secure encrypted connection carried by said tunnel, said connection being established or to be established, and it has a sufficient amount of encryption resources / decryption; triggering means, for each selected device, of a negotiation of a secure connection between said selected device and the remote tunnel head of the tunnel head to be unloaded; and - failover means, in the event of successful negotiation for a given secure connection, of said tunnel head to be unloaded in an unloading mode, the unloading mode being such that said tunnel head to be unloaded does not perform encryption / decryption operation for said given secure connection. 14. Tunnel head to be unloaded according to claim 13, characterized in that it comprises means for detecting an event belonging to the group comprising: - openings of a new connection on said tunnel; detecting a limitation of encryption / decryption resources of said tunnel head to be unloaded; and in that said tilt attempt means is activated if said detection means detects an event. 15 20 15. Unloaded tunnel head according to any one of claims 13 and 14, characterized in that said means for triggering a negotiation comprise means for sending a negotiation request to said remote tunnel endpoint. 16. Tunnel head for unloading according to any one of claims 13 to 15, characterized in that it comprises, for the implementation of said unloading mode for a given secure connection: - first processing means of a remote tunnel head message on the tunnel, comprising themselves: means for de-encapsulation of said message, by removing a first header (TH) used to convey said message between the tunnel heads, to obtain a message unencapsulated message; means for retransmitting the unencapsulated message on the sub-network to which said tunnel head to be unloaded is connected, to the device selected for said given secure connection; second means for processing a message from the device selected for said given secure connection, comprising themselves: means for encapsulating said message by preceding it with a first header (TH) serving to convey said message; message between the tunnel ends, to obtain an encapsulated message; means for retransmitting the message encapsulated on the tunnel, to the remote tunnel endpoint. 17. Unloading tunnel head according to claim 16, characterized in that it comprises, for the implementation of said unloading mode for a given secure connection: when said first processing means are activated: decryption of a second header belonging to the de-encapsulated message, using a specific key previously negotiated with the remote tunnel endpoint when establishing the tunnel, said second header serving to convey said message on said first and second sub networks; When said second processing means are activated: means for encrypting a second header of said message, by using a specific key previously negotiated with the remote tunnel endpoint during the establishment of the tunnel; second header for conveying said message on said first and second sub-networks. 18. Remote tunnel head for managing at least one connection established via a tunnel supported by a main communication network, said tunnel being implemented between first and second tunnel heads respectively connected to first and second sub-channels. networks, each connection allowing a data transmission between a client device and a server device via said tunnel, said client device and said server device being connected to one of the first subnetwork and the other to the second subnetwork, the head tunnel other than the remote tunnel head being called the tunnel head to be unloaded, characterized in that said remote tunnel head comprises: means for negotiating a secure connection with a device selected by said tunnel head to be unloaded; switching means, in the event of successful negotiation for said secure connection, of said remote tunnel endpoint in a secure proxy mode (TLS proxy), the security proxy mode being such that said remote tunnel endpoint performs encryption / decryption operations for said given secure connection in relation to said selected device. 19. Remote tunnel head according to claim 18, characterized in that it comprises means for receiving a negotiation request from said tunnel head to be unloaded, and in that said negotiation means are activated on reception of a negotiation request by said receiving means. 20. remote tunnel head according to any one of claims 18 to 19, characterized in that it comprises, for the implementation of said mode of securing proxy for a given secure connection: first processing means of a message of the tunnel head to be unloaded on the tunnel, comprising themselves: means of de-encapsulation of said message, by removing a first header (TH) serving to convey said message between the heads of the tunnel; tunnel, to obtain a message désencapsulé; means for decrypting a payload belonging to the de-encapsulated message, by using a specific key previously negotiated with the device selected during said negotiation step, making it possible to obtain a decrypted message; means for retransmitting the decrypted message on the subnet to which said remote tunnel endpoint is connected to a client or server device; second means for processing a message from a client or server device, comprising themselves: means for encrypting a payload of said message, by using a specific key previously negotiated with the device selected during the said negotiation step, for obtaining an encrypted message; means for encapsulating said encrypted message by preceding it with a first header (TH) serving to convey said encrypted message between the tunnel heads, making it possible to obtain an encapsulated message; means for retransmitting the message encapsulated on the tunnel, to the tunnel head to be unloaded. 21. Remote tunnel head according to claim 20, characterized in that it comprises, for the implementation of said mode of securing proxy for a given secure connection: - when said first processing means are activated: * means of decryption of a second header belonging to the de-encapsulated message, using a specific key previously negotiated with the tunnel head to be unloaded during the establishment of the tunnel, said second header serving to convey said message decrypted on said first and second subnets; when said second processing means are activated: means for encrypting a second header of said encrypted message, by using a specific key previously negotiated with the tunnel head to be unloaded during the establishment of the tunnel, said second header for conveying said encrypted message on said first and second sub-networks.