EP3991392A1

EP3991392A1 - Method for managing communication between terminals in a communication network, and devices and system for implementing the method

Info

Publication number: EP3991392A1
Application number: EP20747451.1A
Authority: EP
Inventors: Mohamed Boucadair; Christian Jacquenet
Original assignee: Orange SA
Current assignee: Orange SA
Priority date: 2019-06-28
Filing date: 2020-06-24
Publication date: 2022-05-04
Also published as: FR3096532A1; US20220272079A1; WO2020260825A1

Abstract

What is proposed is a method for communication, in a network (11a, 12, 11b), between a first terminal (10a) and a second terminal (10b) between which a first encrypted connection for transmitting data is set up, which method comprises, at the first terminal (10a): storing, in association with said first connection, at least one second connection between the first terminal (10a) and the second terminal (10b) via at least one intermediate processing function intended to be applied between the first terminal (10a) and the second terminal (10b) to at least some of said data, called data eligible for the second connection, and a filter characterizing said data eligible for the second connection, said second connection being encrypted between the first terminal and said intermediate processing function, and sending, via said second connection, at least one message intended for said intermediate function transporting data for the second terminal (10b) corresponding to said filter, the first sent message at least comprising information stipulating that said data are for the second terminal (10b).

Description

Title: Method for managing communication between terminals in a communication network, and devices and system for implementing the method Technical field

[0001] The present disclosure relates to a method for managing a communication between a first terminal and a second terminal in a communication network, as well as to devices for implementing this method. It applies in particular to the management of communications using an encrypted connection, such as, for example, communication according to the QUIC protocol.

Prior art

The QUIC protocol described in the draft specification of the Internet Engineering Task Force (IETF) entitled "QUIC: A UDP-Based Multiplexed and Secure Transport" is an example of a transport protocol specified by the Internet community to satisfy the requirements of the Internet. needs of certain applications. The QUIC protocol is based on the UDP protocol (standing for "User Datagram Protocol") rather than on the TCP protocol (standing for "Transmission Control Protocol") because it aims to reduce the latency times generally observed during establishing TCP connections.

[0003] Unlike the TLS ("Transport Layer Security") protocol which is used to secure TCP connections, QUIC not only encrypts payload data, but also connection control information. QUIC information sent in the clear is kept to a minimum (for example, the connection ID). QUIC thus enables end-to-end encrypted connections.

[0004] However, the specification of the QUIC protocol does not envisage a collaboration mechanism between a QUIC terminal (including the applications it supports) and an operator network to offer the user a better quality of experience ( or in English, QoE, for "Quality of Experience"), for example via the implementation in the network of functions offering various services such as anti-virus services, packet inspection, address translations and port, etc. In particular, such cooperation must not induce additional connection establishment delays compared to those of connections which do not involve a network function. [0005] However, the presence of such functions in the network can have an impact on the progress of a QUIC connection.

[0006] Thus, the modifications of addresses or of port numbers executed by a network function such as an address and port translation function (NAPT, Network Address and Port Translation in English) can lead to instability of the QUIC connection because the remote terminal must check with each modification that it is indeed the QUIC terminal which is at the origin of said modification. The QUIC requests used for this verification can be rejected (due to a "rate-limit" policy) or fail because the terminal is not aware of the modifications made to its packets sent over the network.

[0007] In addition, due to the encryption of the messages, a network function placed on the path of a QUIC communication cannot access the data exchanged during this communication.

summary

[0008] The present disclosure improves the situation.

[0009] According to a first aspect, there is proposed a method of communication in a network, between a first terminal and a second terminal between which is established a first encrypted connection for transmitting data, the method comprising at the first terminal: store, in association with said first connection, at least a second connection between the first terminal and the second terminal via at least one intermediate processing function intended to be applied to at least part of said data said to be eligible for the second connection, and a filter characterizing said data eligible for the second connection, said second connection being encrypted between the first terminal and said intermediate processing function, and sending, via said second connection, at least one message intended for said intermediate function carrying data for the second terminal corresponding to said filter , the first message sent at least comprising a e information according to which said data is intended for the second terminal.

[0010] Thus, the proposed method introduces the concept of collaborative connections between two terminals, where a plurality of secondary encrypted connections (second connections within the meaning of the proposed method) is associated with a main encrypted connection established between the two terminals (first connection within the meaning of the proposed method), and can advantageously benefit from the execution of processing functions offered by the network. By virtue of the proposed method, the data exchanged via the plurality of connections established between the two terminals are, from the point of view of the terminals, associated with one and the same connection, namely the main connection.

Depending on the embodiment, the different processing functions can be invoked in cascade (that is to say, the same packet of a collaborative connection will be processed by one or more processing functions also designated here by OF (Offered Function) functions, according to an invocation order typically provided by a terminal) or according to a chronology specific to each context.

[0012] The proposed method makes it possible, by this means, to enhance the operator's network via the introduction of processing functions optimizing the use of the resources mobilized for the establishment and maintenance of encrypted connections between terminals, such as that especially QUIC connections. Said processing functions are not limited to those optimizing the use of network resources, but other types of functions can be requested such as functions of detection and correction of errors (FEC). The network operator thus has the opportunity to improve the level of quality associated with these connections as perceived by users.

[0013] The result is a simplification of the use of QUIC clients on the terminals, thanks to a pragmatic collaboration with the network.

[0014] In addition, it should be noted that the level of security and robustness associated with each main encrypted connection is maintained, the secondary connections themselves being encrypted between each processing function and the terminals, and where appropriate between the processing functions between them when they are invoked in cascade. Also, the consent of the terminals may be required for the invocation of intermediate processing functions in a collaborative communication. In doing so, only trust functions that do not alter the security level of a connection are requested.

The proposed method thus advantageously makes it possible to involve OF functions in a communication between two terminals without inducing additional latency for the exchange of data (0-RTT, "Zero Round Trip Time" in English, that is, that is, the payload data is transmitted as soon as the first packet used for connection establishment is sent) between these two terminals.

[0016] The proposed method leaves the possibility for the terminals to control the selection of these processing functions. It introduces flexibility in the invocation and withdrawal of processing functions; in particular, it makes possible an on-demand invocation of processing functions in the network.

[0017] In addition, the proposed method advantageously provides a mechanism for selecting part of the data of a QUIC connection for which one or more OF functions can be invoked. Likewise, the direction of the traffic to which the processing function or functions should be applied can also be left to the choice of the terminals.

Thus, in one or more embodiments, a packet content inspection function (DPI, Deep Packet Inspection in English) or an anti-virus function can be selectively invoked for certain packets, without being invoked. for all the packets exchanged during a QUIC communication.

In one or more embodiments, a connection can multiplex several channels (also referred to as “streams” in the QUIC protocol), without limitation as to the number of multiplexed channels, as to their nature (unidirectional or bidirectional), or again as to the origin of the establishment of these channels (at the initiative of the client or server). The proposed method thus offers the possibility of selectively choosing the channels of a connection benefiting from such or such processing functions. Also, the same channel may involve different functions during a connection, each being invoked exclusively for part of the data associated with this same channel.

[0020] In one or more embodiments, the proposed method may further comprise: sending data via the first connection to the second terminal, data which does not correspond to said filter.

[0021] In one or more embodiments, the proposed method may further comprise: on receipt of data via said second connection, associating said data with said first connection if the data corresponds to said filter. Note that a terminal can decide to send data via the first connection even if these data are eligible for the second connection. This decision is local to the terminal (for example driven by the application layer).

[0023] In one or more embodiments, said first message further comprises a key intended to be presented by the intermediate function (OF) to the second terminal, and shared between the first terminal and the second terminal.

This embodiment makes it possible to reinforce the security of the proposed mechanism.

[0025] In one or more embodiments, the proposed method may further comprise: informing the second terminal, in at least one message sent via said first connection to the second terminal, of the use of said intermediate processing function for said at least part of said data.

[0026] In one or more embodiments, said at least one message informing the second terminal of the use of said intermediate processing function comprises at least one of: an identifier of said intermediate processing function; a key to be presented by the intermediate function to the second terminal; said filter characterizing the data eligible for said second connection; at least one connection identifier eligible for said second connection; and information on the direction of data transmission via the second connection to which said intermediate processing function is applied.

In one or more embodiments, the use by the first terminal of said second connection to send data to the second terminal is conditioned by the reception by the first terminal of an acknowledgment from the second terminal of the use of said intermediate processing function.

In one or more embodiments, on the second connection, a plurality of intermediate processing functions can be applied to the data eligible for the second connection in a determined order and: said at least one message carrying data for the second terminal is intended for the first intermediate processing function to be applied to said data eligible for the second connection, said first message sent further comprises a first list ordered according to said determined order identifying the functions of said plurality of functions of intermediate processing distinct from the first function, and to be applied to said eligible data.

[0029] In one or more embodiments, said first message sent further comprises a second list ordered according to said determined order of keys intended to be presented by each of the intermediate processing functions identified in the first list to the intermediate processing function next in said first list or, for the last intermediate processing function from the first list to the second terminal, the key intended to be presented to the second terminal being shared between the first terminal and the second terminal.

[0030] In one or more embodiments, the proposed method may further comprise: informing the second terminal via the first connection of a modification affecting G use of said intermediate processing function.

In one or more embodiments, said first connection is established between the first terminal and the second terminal according to the QUIC protocol; at least one said second connection is established according to the TLS protocol between the first terminal and the second terminal via at least one said intermediate function capable of decrypting the data exchanged via said second connection.

According to a second aspect, there is proposed a method of communication in a network, between a first terminal and a second terminal between which is established a first encrypted connection for transmitting data, the method comprising at the second terminal: store, in association with said first connection, an intermediate processing function intended to be applied between the first terminal and the second terminal on at least part of said data, a filter characterizing said at least part of the data and a key shared with the first terminal; receiving at least a first message originating from said intermediate function carrying data sent by the first terminal; checking whether said data matches the stored filter; and in the event of a match: accepting the establishment of a second encrypted connection with the intermediate function and associating said second connection with the first connection; and upon receipt of data via said second connection corresponding to said filter, associating said data with the first connection. [0033] In one or more embodiments, said first message further comprises a key presented by the intermediate processing function to the second terminal, the establishment of the second encrypted connection being accepted if said key received corresponds to a key shared with the first terminal.

In one or more embodiments, the proposed method may further comprise: sending data to the first terminal via said second connection corresponding to said filter in a message intended for the intermediate function.

According to a third aspect, there is proposed a method of processing data transmitted in a network between a first terminal and a second terminal between which is established a first encrypted connection, the method comprising, for a first device configured to put in implements a first function of intermediate processing of data transmitted between the first terminal and the second terminal on a second connection via said first device: receiving from a first device of the network at least a first message intended for the first device, carrying data transmitted by the first terminal to the second terminal, said first network device being the first terminal or a second device configured to implement a second intermediate processing function of said data, the second connection being encrypted between the first device and the first device, said first message comprising: a first ordered list identifying at least a second device of the network to be used by said at least one message to be routed to the second terminal, said at least one second device being the second terminal or at least a third device configured to implement a third intermediate processing function of said data; and a second ordered list comprising at least one key intended to be presented by each device of the first list to the next device in said first list, the key intended to be presented to the second terminal being shared between the first terminal and the second terminal; applying the first intermediate processing function to said data carried in said at least one first message; update the first list and the second list; and send to the next device identified in the first list, said at least one first message integrating the update of the first and second lists, with the data processed by the first intermediate processing function and the key extracted from the second list intended to be presented to the next device, the second connection being encrypted between the first device and the following device.

In one or more embodiments, the proposed method may further comprise: storing for the second connection: a source IP address and a source port number used by the first intermediate device to relay said data from said at least a first message; and a destination IP address and a destination port number corresponding to the next device identified in the first list to which said data of said at least one first message is transmitted; receiving from the first device at least one second message intended for the first device, carrying data sent by the first terminal to the second terminal, in which the first list is absent; applying the first intermediate processing function to said data carried in said at least one second message; send to the stored destination IP address and destination port said at least one second message with the data processed by the first intermediate processing function.

[0037] According to another aspect, there is provided a data communication device, comprising a processor and a memory operably coupled to the processor, wherein the processor is configured to implement one of the embodiments. 'a method proposed in the present description, such as implemented at a first terminal device, at a second terminal device, or at a device configured to implement an intermediate processing function.

According to yet another aspect, there is provided a data communication system, comprising a first terminal, a second terminal, and a device for implementing one or more intermediate processing functions, configured for the implementation. implementation of one of the embodiments of the method proposed in the present description, as implemented at a first terminal device, at a second terminal device, and at a device configured to implement an intermediate processing function, respectively.

Another aspect relates to a computer program, loadable into a memory associated with a processor, and comprising portions of code for the implementation of one of the embodiments of the method proposed in the present description during the execution of said program by the processor. Another aspect relates to a set of data representing, for example by compression or encoding, a computer program as proposed in the present description.

Another aspect relates to a non-transient storage medium for a computer executable program, comprising a set of data representing one or more programs, said one or more programs comprising instructions for, during the execution of said one. or more programs by a computer comprising a processor operably coupled to a memory and to an input / output data communication interface, causing the computer to manage a communication between a first terminal and a second terminal in a communication network according to one of the embodiments of the method proposed in the present description, as implemented at a first terminal device, at a second terminal device, or at a device configured to implement an intermediate processing function.

Brief description of the drawings

Other features and advantages of the present invention will emerge from the following description of non-limiting embodiments, with reference to the accompanying drawings, in which:

Fig. the

[0043] [Fig. 1a] illustrates an example of a communication system in which one or more embodiments of the proposed methods, devices and systems can be implemented.

Fig. lb

[0044] [Fig. lb] illustrates a reference architecture for implementing the method proposed according to one or more embodiments.

Fig. 2a

[0045] [Fig. 2a] illustrates an example of main and secondary connections established between two terminals according to one or more embodiments.

Fig. 2b [0046] [Fig. 2b] illustrates an example of main and secondary connections established between two terminals according to one or more embodiments.

Fig. 2c

[0047] [Fig. 2c] illustrates the correlation of a collaborative connection with the underlying network according to one or more embodiments.

Fig. 3a

[0048] [Fig. 3a] illustrates an example of a collaborative connection table (CCT) according to one or more embodiments.

Fig. 3b

[0049] [Fig. 3b] is a diagram illustrating the method proposed according to one or more embodiments.

Fig. 4a

[0050] [Fig. 4a] illustrates an example of QUIC COCON frame format according to one or more embodiments.

Fig. 4b

[0051] [Fig. 4b] illustrates an example table (TRS) for managing intermediate processing function usage information messages according to one or more embodiments.

Fig. 4c

[0052] [Fig. 4c] illustrates an example of invocation of an intermediate processing function between a first terminal and a second terminal according to one or more embodiments.

Fig. 4d

[0053] [Fig. 4d] illustrates an example of a TRS table managed by a terminal according to one or more embodiments.

Fig. 4th [0054] [Fig. 4e] illustrates an example of invocation of an intermediate processing function between a first terminal and a second terminal according to one or more embodiments.

Fig. 4f

[0055] [Fig. 4f] illustrates an example of invoking a plurality of intermediate processing functions between a first terminal and a second terminal according to one or more embodiments.

Fig. 4g

[0056] [Fig. 4g] illustrates an example of invocation of a plurality of intermediate processing functions between a first terminal and a second terminal according to one or more embodiments.

Fig. 4h

[0057] [Fig. 4h] illustrates an example of a COCON (UPDATE) message format according to one or more embodiments.

Fig. 5a

[0058] [Fig. 5 a] is a diagram illustrating the method proposed according to one or more embodiments.

Fig. 5b

[0059] [Fig. 5b] illustrates an example of a collaborative connection relay table (RCCB) according to one or more embodiments.

Fig. 6a

[0060] [Fig. 6a] is a diagram illustrating the method proposed at the level of the remote terminal according to one or more embodiments.

Fig. 6b

[0061] [Fig. 6b] illustrates an example of a validated relayed stream (TRS) table according to one or more embodiments.

Fig. 6c [0062] [Fig. 6c] is a diagram illustrating an example of a method of processing a new secondary connection to the remote terminal according to one or more embodiments.

Fig. 6d

[0063] [Fig. 6d] illustrates an example of a method of processing a new packet at the remote terminal according to one or more embodiments.

Fig. 7a

[0064] [Fig. 7a] illustrates an example of rejection of an intermediate processing function according to one or more embodiments.

Fig. 7b

[0065] [Fig. 7b] illustrates an example of rejection of an intermediate processing function according to one or more embodiments.

Fig. 7c

[0066] [Fig. 7c] illustrates an example of rejection of an intermediate processing function according to one or more embodiments.

Fig. 7d

[0067] [Fig. 7d] illustrates an example of a successful collaborative connection according to one or more embodiments.

Fig. 7th

[0068] [Fig. 7e] illustrates an example of a successful collaborative connection according to one or more embodiments.

Fig. 7f

[0069] [Fig. 7f] illustrates an example of a successful collaborative connection according to one or more embodiments.

Fig. 8a

[0070] [Fig. 8a] illustrates an example of the architecture of a terminal according to one or more embodiments.

Fig. 8b [0071] [Fig. 8b] illustrates an example of the architecture of a relay according to one or more embodiments.

Description of embodiments

[0072] In the following detailed description of embodiments of the invention, numerous specific details are presented to provide a more complete understanding. Nevertheless, one of ordinary skill in the art can appreciate that embodiments can be practiced without these specific details. In other cases, well-known characteristics are not described in detail to avoid unnecessarily complicating the present description.

The present description refers to functions, units, modules, platforms, and illustrations of diagrams of the methods and devices according to one or more embodiments. Each of the functions, modules, platforms, units and diagrams described can be implemented in hardware, software (including in the form of on-board software ("firmware"), or "middleware"), microcode, or any combination of these last. In the case of implementation in software form, functions, motors, units, modules and / or diagram illustrations can be implemented by computer program instructions or software code, which can be stored or transmitted on a computer readable medium, including a non-transient medium, or a medium loaded in the memory of a generic, specific computer, or of any other apparatus or programmable device for processing data to produce a machine, so that the Computer program instructions or the software code executed on the computer or the programmable data processing device or device, constitute means of implementing these functions.

[0074] The embodiments of a computer readable medium include, but are not limited to, computer storage media and communication media, including any medium facilitating the transfer of a computer program from a location to another. By “computer storage medium (s)” is meant any physical medium that can be accessed by a computer. Examples of computer storage media include, but are not limited to, flash memory disks or components or any other flash memory devices (eg, USB keys, memory sticks, memory sticks, key disks), CD-ROMs or other optical data storage devices, DVDs, magnetic disc data storage devices or other magnetic data storage devices, data memory components, RAM, ROM, EEPROM memories, smart cards, SSD (Solid State Drive) type memories, and any other form a medium usable for transporting or storing or memorizing data or data structures which can be read by a computer processor. The instructions may, depending on the embodiments, include code of any computer programming language or computer program element.

In addition, the terms "in particular", "for example", "example", "typically" are used in the present description to denote examples or illustrations of nonlimiting embodiments, which do not necessarily correspond to preferred or advantageous embodiments over other possible aspects or embodiments.

By "server" is meant in the present description any point of service (virtualized or not) or device operating data processing, one or more databases, and / or data communication functions. For example, and without limitation, the term "server" can refer to a physical processor operably coupled with associated communication, database and data storage functions, or refer to a network, an group, set or complex of processors and associated data storage and networking devices, as well as an operating system and one or more database system (s) and application software supporting the services and functions provided by the server.

The terms "network" and "communication network" as used in the present description refer to one or more data links which can couple or connect devices, possibly virtualized, so as to allow the transport of data. electronic between computer systems and / or modules and / or other electronic devices or equipment. A network can comprise, in whole or in part, the Internet network, one or more local networks (in English “Local Area Networks”, or LAN), one or more networks of the WAN type (in English “Wide Area Networks”), fdaire type connections, wireless type connections, cellular type, or any combination of these different networks. The term "application" as used in the present description denotes any tool which operates and is operated by means of a computer, to provide or perform one or more function (s) or task (s) for a user or another application program. In order to interact with an application and to control it, a user interface (for example a graphical interface, in English, “Graphical User Interface” or GUI) can be provided on the equipment on which the application is implemented.

The term "terminal" is used in the present description to denote any entity, such as a software entity, capable of establishing or receiving communications based on the use of one or more transport protocols, such as as TCP or UDP, and / or any entity capable of functioning as an end point of a communication established according to the modalities of a communication protocol, such as, without limitation, the QUIC, UDP, DTLS or TLS protocols . For a given communication, a terminal that implements a communication protocol can act as a client, a server, or both. Examples of terminals include, without limitation, fixed or mobile terminals, intelligent terminals (in English, "smartphones"), personal computers (in English, "Personal Computer" or "PC"), tablets, Internet network servers, etc. Certain decisions related to the establishment and management of communications can be made by the terminal or by one of the applications embedded in the terminal, and which has the capacity to exploit the QUIC resources. The present description concerns the two cases: that in which the decisions are taken by the terminal, and that in which the decisions are taken by an application embedded in this terminal.

The term "packet", as used in the present description, designates without limitation any data unit capable of being transported or transmitted between two network nodes, two stations, two terminals, or through 'one or more data networks. A “packet” can designate one or more frames, one or more protocol data units (in English, “Protocol Data Unit”, or “PDU”), one or more datagrams, or any other data unit. A packet, for example, may include a group of bits, which may include one or more address fields, one or more control (or signaling) fields, and / or one or more payload fields.

By "function", "intermediate processing function", "intermediate function" or "network function" is meant any packet processing function. such as an address translation (NAT) function, a function intended to improve the quality of service (e.g. a traffic marking and classification function), a firewall function, a service optimization function communications established on the TCP transport protocol (PEP, Performance Enhancing Proxy), MPTCP proxy, etc.

By "QUIC protocol", or in short form "QUIC", is meant any protocol conforming to a version of the specification of the QUIC protocol or of the draft specification, such as the draft specification of the IETF entitled "QUIC : A UDP-Based Multiplexed and Secure Transport ”, or the specification of the“ Quick UDP Internet Connections ”protocol, known as the“ gQUIC ”protocol, including the existing versions of these specifications or draft specifications and their evolutions. More generally, QUIC denotes here any transport protocol encapsulated on another UDP or UDP-lite transport protocol (from the English "Lighweight User Datagram Protocol") but whose primitives and payload are encrypted.

Although the examples of embodiments described below are based on communications established according to the QUIC protocol, those skilled in the art will be able to understand that these examples are not limiting, in that the proposed method can also be implemented. implemented, in other embodiments, using other protocols to establish encrypted communication (DTLS or TLS, for example).

In one or more embodiments, the logic for selecting the connections, packets, and channels (or "streams") QUIC eligible to request at least one intermediate processing function is provided to a terminal in the form of policies. The logic of removing an OF function from a connection is a policy which can be local to the terminal or at the initiative of the operator, for example as part of a scheduled maintenance procedure. These policies can be managed directly by the application based on the resources of a collaborative connection.

It is assumed that one or more paths can be used to exchange data between two terminals. Thus, data associated with different channels can be routed through a single path or through separate paths. No assumption is made as to the support of the functions of establishing QUIC communications via multiple paths by the terminals or as to the existence of these multiple paths. FIG. La illustrates an example of a communication system (10) in which one or more embodiments of the methods and devices proposed can be implemented.

The system (10) comprises a first terminal T1 (10a) which has established a connection with a second terminal T2 (10b) via a first access network (1 la) to which the first terminal is connected, the Internet network (12), and a second access network (11b), to which the second terminal T2 (10b) is connected. By way of non-limiting example, the first and second access networks (11a and 11b) can be local area networks (LAN) in which the terminals T1 and T2 are respectively present. The architecture illustrated in FIG. 1a is not limiting, in particular in that the terminals T1 and T2 can connect to the same access network.

In one or more embodiments, the first terminal T1 and the second terminal T2 can be configured to establish one or more connections according to a communication protocol, such as the QUIC, UDP, DTLS, or TLS protocol, and by example establish a connection according to this protocol and exchange data using this connection. Said configuration may be a default behavior of a terminal (ie no additional explicit configuration is required for the activation of one of said communication protocols).

FIG. Lb illustrates a reference architecture for the implementation of the method proposed according to one or more embodiments.

The system (20) comprises a first terminal T1 (20a) with which a connection according to a communication protocol is established with a second terminal T2 (20b) via a network (21) to which the first terminal T1 (20a) and the second terminal T2 (20b) are connected. The network (21) can be broken down into several subnetworks, such as, for example, those illustrated in FIG.

Again with reference to Figure la, those skilled in the art will understand that the proposed method is not limited as to the number, nature, or location of the intermediate OF functions which can be invoked by a terminal . OF functions can be hosted within the NI network (l ia), N2 (11b), or any other network, including for example the Internet network (12) (typically, data centers (DC, Data Centers) ). Likewise, an OF function can be located (or not) on the default path taken by the communication established between two terminals, but this does not mean that said OF function is systematically requested for all flows. Mechanisms for controlling the invocation of an OF function are described below.

For example, data requiring transcoding, data inspection, protocol adaptation, etc. will be explicitly intended to be processed by an OF function upon decision of at least one terminal involved in a connection.

[0094] For example, a WebRTC connection may involve audio, video, presence, etc. channels. Each of these channels may require separate OF functions, and supported by the network.

An OF function can be inserted from the initialization of the establishment of a communication (for example the establishment of a connection), during the creation of a channel, or later.

As mentioned above, the invention allows the invocation of intermediate processing OF functions by introducing the notion of collaborative connections between two terminals T1 and T2, described in more detail later. In the embodiments in which several connections are established according to a communication protocol between two terminals T1 and T2, for example the QUIC protocol, the first connection established between the two terminals according to the QUIC protocol is hereinafter called: Main Connection ( or in English, “Primary Connection”). This main connection can be made directly between T1 and T2 (i.e. without invoking an OF function as shown in Figure 2a) or via an OF function as shown in Figure 2b. The other connections are called: Secondary Connections.

FIGS. 2a and 2b thus show two terminals T1 (30a) and T2 (30b) between which several connections are established (in the illustrated example of QUIC connections).

Figure 2a shows a main connection (31a), established the first, and two secondary connections (32a and 33a), established between the two terminals T1 (30a) and T2 (30b). The main connection is established without invoking an OF function, while the two secondary connections are each established with invocation of an intermediate function (OF1 and OF2 respectively). Figure 2b shows a main connection (31b), established the first, and two secondary connections (32b and 33b), established between the two terminals T1 (30a) and T2 (30b). The main connection is established with invocation of function OF, as are the two secondary connections which are each established with invocation of a function (OF1 and OF2 respectively).

[0100] In each of the examples illustrated by FIGS. 2a and 2b, the data exchanged via the main connection are conveyed in channels indexed by {a..x}, while the data exchanged via a secondary connection are conveyed in the channels indexed here by {i ... j} or by {s ... t}. Thus, {a..x} is a list of primary channel IDs, while {i ... j} (or {s ... t}) is a list of secondary channels. Data belonging to some of the main channels {a..x} may also be eligible for a secondary connection {i..j}. Therefore, some identifiers of the list {a..x} can be present in the list {i..j}, in which case, the two groups of channels {a..x} and {i ... j} can present a non-zero intersection.

[0101] The data exchanged via separate secondary connections are routed in two channels {i ... j} and {s..t}. The two groups {s..t} and {i ... j} can have a non-zero intersection, if necessary.

[0102] Figure 2c illustrates the correlation of a collaborative connection with the underlying network. As illustrated in figure 2c, the different connections (31c, 32c, 33c), comprising the main connection (31c) and one or more secondary connections (32c, 33c), can be established on the same path between Tl (30a) and T2 (30b).

Examples of the embodiment of the proposed method for managing collaborative connections are described below, in the non-limiting case of connections established according to the QUIC protocol.

A first terminal (for example the terminal T1 of FIGS. La - 2c) establishes an encrypted main connection with a second terminal (for example the remote terminal T2 of FIGS. La - 2c) according to the methods described in the existing QUIC specification.

In one or more embodiments, the first terminal maintains a correspondence table, hereinafter called: Collaborative Connections Table (CCT). FIG. 3 a shows an example of a CCT table structure identifying, for a primary connection (Primary Connection Ref), a secondary collaborative connection (Secondary Connection Refl), and a filter characterizing the data eligible for this secondary collaborative connection. The term filter is understood to mean an indication or a set of indications making it possible to identify the data which are eligible for a secondary connection, that is to say which can be processed by the intermediate function or functions belonging to this secondary connection. It is through such indications to "filter" the data which can take the secondary connection. In the example illustrated in FIG. 3a, this filter is in the form of a list of eligible channels, that is to say that can be used to route the data corresponding to the collaborative connection, and a list of Qualifying login credentials. Security associations (based for example on the use of TLS / DTLS protocols) can be used as examples of reference to a connection. Other reference formats can be used by the different elements involved in the procedure.

[0107] Thus, a CCT table can be generated and kept in memory accessible to the first terminal to indicate a list of channels / connection identifiers eligible for collaborative connections operating as a filter characterizing the data eligible for collaborative connections. Therefore, even if a function is authorized to establish secondary connections, the data relayed by this function for channels or presenting connection identifiers not entered in the CCT table can be identified and possibly rejected by the terminal. The list of channels or the list of connection identifiers are fed by the TRS table (TRUSTED RELAYED STREAMS).

[0108] FIG. 3b is a diagram illustrating the method proposed according to one or more embodiments.

We consider first and second terminals, between which a first encrypted connection is established (50) to transmit data, for example according to the QUIC protocol.

[0110] The first terminal then stores (51), in association with said first connection, at least a second connection between the first terminal and the second terminal via at least one intermediate processing function intended to be applied between the first terminal and the second terminal on at least part of said data said eligible for the second connection, and a filter characterizing said data eligible for the second connection, said second connection being encrypted between the first terminal and said intermediate processing function. Such a filter is for example a connection identifier, a channel identifier or any other template which makes it possible to select by a local terminal (or to determine by a remote terminal) the data eligible for a secondary connection. In the embodiments described below, the connection and channel identifiers are used as examples of filters, and the aforementioned information is stored in a CCT table as described previously.

[0111] The proposed method thus advantageously makes it possible to introduce a second connection between the two terminals between which a first connection is already established, via an intermediate processing function, without however impacting the first connection, and in particular without breaking it. The first and second connections are collaborative in that the first and second terminals handle both connections (first and second connections) as if they were one global connection.

[0112] The storage of this association between the first connection and the second connection makes it possible to associate with the first connection the data which are sent and received on the second connection, and corresponding to the filter defining the data which are eligible for the second connection .

The second connection can thus advantageously invoke one or more intermediate processing functions, respectively intended to be applied between the first terminal and the second terminal on the data eligible for the second connection.

In one or more embodiments, as illustrated in Figures 2a-2c, the second connection comprises several sections (between the first terminal and the intermediate function invoked in this second connection on the one hand, and between the intermediate function and the second terminal on the other hand). For example, this encryption is implemented according to a TLS security association established between the different devices two by two. When several intermediate functions are invoked in cascade between the first terminal and the second terminal, each section is individually encrypted.

Once the association between the first connection and the second connection stored at the first terminal, the first terminal can send (52) via said second connection, at least a first message intended for said intermediate function and carrying data for the second terminal corresponding to said filter, the first message comprising information according to which said data is intended for the second terminal.

Examples of messages sent by the first terminal are given below.

In one or more embodiments, the first terminal can select according to a filter the packets (channels) which must request an OF function, in other words which are eligible for the second connection. The selected packets can be sent using the address that allows access to the intermediate function (OF) as the destination address. The data carried by the packets is encrypted according to the security association (eg TLS) established between the first terminal and the OF function. In addition, in the non-limiting example in which the connections between the two terminals are established according to the QUIC protocol, the data can carry a new QUIC frame called

RELAY (List {Next_FIop_IP address / port}, Shared Token, ...), comprising, in one embodiment, the fields described below:

[0118] List {Next_FIop_IP address / port}: Contains a list of addresses (and port numbers) which will be used by the OF intermediate function (s) invoked in the second connection, for routing the packet to its destination final. In one or more embodiments, this list contains the IP address (and possibly a port number) of the second terminal (remote terminal) if only one OF function is requested in the path taken by the data. If several functions are requested, then said list is an ordered list which comprises, in addition to information making it possible to reach the remote terminal, information descriptive of the intermediate functions OF which must be invoked. The first element of said ordered list points to the next OF function to be invoked while the last element points to the remote terminal.

[0119] “Shared Token”: Indicates a key to present for the next jump. In one or more embodiments, the same key can be used. Alternatively, the message can contain an ordered list of keys: List {Next_Hop_Shared Token}. A key in position "i" will be presented to element "i" of the List {Next_Hop_IP address / port} list. Thus, in one or more embodiments, the message sent by the first terminal may include a second list, ordered according to the ordering of the (first) list of functions, of keys intended to be presented by each of the intermediate processing functions identified in the first list to the next intermediate processing function in said first list or, for the last intermediate processing function from the first list to the second terminal, the key intended to be presented to the second terminal being shared between the first terminal and the second terminal. In one or more embodiments, the keys can only be present for the first data packet sent in a new secondary connection, and can therefore be omitted for the other packets.

[0120] Thus, in one or more embodiments, the first message sent by the first terminal via the second connection may include a key intended to be presented by the intermediate function to the second terminal, and shared between the first terminal and the second. terminal.

[0121] In one or more embodiments, the first terminal may decide to include the RELAY frame only for the first packets sent to an OF function (that is to say in the first messages sent to the OF function ). The remaining eligible packets are sent directly to the OF function (that is, without inserting a RELAY frame) which must process them using a dedicated table (called, RCCB), described below.

[0122] For the other packets, that is to say for the packets which are not eligible for processing by an OF function (in other words for the packets not corresponding to the filter associated with the secondary connection established via this function OF), the data is sent, in the embodiment described here, directly by the first terminal to the second terminal via the first connection (the main connection). Note that if several secondary connections are planned, if data corresponds to a filter of another secondary connection, it will preferably be sent to the second terminal via this other secondary connection.

During the first connection, the first terminal can decide to insert the intermediate processing function OF for all or part of the channels of said connection established with the second terminal, for example for part of the data sent to the user. second terminal. The first terminal can inform the second terminal of G use of the intermediate processing function for part of the data, by sending an information message of use of an OF function sent via the first connection. bound for the second terminal.

The information message for the use of an OF function advantageously makes it possible to inform a remote terminal with which a first encrypted connection is established of the use of an intermediate processing function for all or part of the data transmitted. or exchanged with this remote terminal, possibly indicating to the remote terminal information relating to a data eligibility criterion for the invocation of the function as used by the first terminal (in other words, indicating to it a filter characterizing the data eligible).

[0126] In one or more embodiments, the information message of use of an OF function informing the second terminal of the use of the intermediate processing function may include at least one element from: an identifier of the intermediate processing function; a key to be presented by the intermediate function to the second terminal; the filter characterizing the data eligible for the second connection; at least one connection identifier eligible for the second connection; and information on the direction of data transmission via the second connection to which said intermediate processing function is applied.

[0127] For example, in the non-limiting example in which the first connection between the two terminals is established according to the QUIC protocol, the first terminal can, in one or more embodiments, insert a new QUIC frame, called COCON ( COllaborative CONnection), in a control message or a data message of the first connection (main connection) to the remote terminal.

[0128] FIG. 4a illustrates an example of a QUIC COCON frame format, the fields of which are described below:

A direction indication bit "D": This bit can for example be set to "0" (respectively to "1") if the intermediate processing function is inserted only for the data sent by the first terminal ( having sent the COCON frame to the second terminal), and be set to "1" (respectively to "0") if the function can be used for both directions of the connection. [0130] "Third Party ID": Indicates a (globally) unique identifier identifying an intermediate processing function (OF). In one or more embodiments, this identifier may be a “hash” (obtained using the SHA-256 algorithm, for example) of the “Pre-Shared Key (PSK) identity” information used by the OF function in a TLS “ClientKeyEx change” message. Other structures can be used for this identifier.

[0131] “Shared Token”: A key shared between the intermediate processing function (OF) and the terminal sending the frame.

[0132] "List Stream IDs": A filter which lists one or more respective identifiers of one or more channels eligible for invocation of the intermediate processing function (OF) identified by the "Third Party ID" field. In one or more embodiments, this field can be defined by including a scenario in which this field contains no channel identifier, to indicate that the function can be invoked for all the channels of a connection (i.e. (that is, all packets in said connection are eligible to invoke the OF function).

[0133] "List Connection ID": A filter which lists one or more connection identifiers eligible for the invocation of the OF intermediate processing function identified by the "Third Party ID" field. In one or more embodiments, this field can be defined by including a case in which this field contains no connection identifier, to indicate that the function can be invoked for all the connection identifiers associated with this connection. . In one or more embodiments, the list of connection identifiers indicated in a function use information message (for example a COCON frame) can be automatically updated by a remote terminal following the migration of identifiers. connection (for example, following the reception of a QUIC NEW_CONNECTION frame).

[0134] In one or more embodiments, if no direction restriction is indicated in the OF function usage information message, the direction of the invocation of the function can be deduced based on the direction of the associated channel. In the case of the QUIC protocol for example, the least significant bits of the “stream ID” indicate the nature of the channel: 0x0 (bidirectional channel established at the initiative of the client), 0x1 (bidirectional channel established at the initiative of the server) , 0x2 (unidirectional channel established at the initiative of the client) and 0x3 (unidirectional channel established at the initiative of the server). [0135] In one or more embodiments, several OF function usage information messages (for example COCON frames) can be sent if the first terminal decides to involve an OF intermediate processing function in different channels. .

[0136] In one or more embodiments, multiple OF function usage information messages (eg, COCON frames) may be sent if the first terminal decides to involve multiple OF intermediate processing functions.

[0137] In one or more embodiments, an OF function use information message (for example a COCON frame) can be sent in any message of a connection, including the first message of the connection. connection establishment.

[0138] In one or more embodiments, an OF intermediate processing function can be embedded in a node located on the default (or not) data path.

In one or more embodiments, the first terminal uses a dedicated TRS table, to record the offers sent (that is to say, the characterization of the (eligible) data which benefit from the invocation of a or several OF functions depending on the information conveyed in the COCON frames and which led to the creation of entries in the TRS table).

[0140] In one or more embodiments, the first terminal can use a table managing the entries corresponding to the COCON frames sent to a remote terminal (to the second terminal) and another table managing the entries corresponding to the COCON frames received from the remote terminal. . As a variant, the same table can be used regardless of the origin of the COCON frames.

[0141] Figure 4b illustrates an example of a table managing the entries corresponding to the intermediate processing function use information messages sent to the second terminal according to one or more embodiments. The messages, which correspond to offers to use the OF function, are associated with a primary connection (called "Primary Connection Ref").

[0142] FIG. 4b shows an example of a TRS (“Primary Connection Ref Out” table structure for the offers sent for the primary connection “Primary Connection Ref”), which contains the following information: [0143] “OF ID”: an identifier of an OF function.

[0144] "Direction": in one or more embodiments, this field indicates a first value indicating a use of the function identified by the unidirectional OF ID field at the initiative of the first terminal, that is to say for data sent by the first terminal, a second value indicating use of the function identified by the unidirectional OF ID field at the initiative of the second terminal, that is to say for data sent by the second terminal, or a third value indicating a use of the function identified by the bidirectional OF ID field, that is to say for data sent by the first terminal or by the second terminal. For example, this field may indicate one of the following values: 0 (Unidirectional at the initiative of the terminal), 1 (Unidirectional at the initiative of the remote terminal), 2 (bidirectional).

[0145] “Token”: A verification key which must be presented (by an OF function) to establish a new secondary connection associated with a primary connection.

[0146] List of "Stream IDs": A filter which lists the channels whose data can be relayed by the function identified in the OF ID field (that is to say the eligible channels). In one or more embodiments, a predetermined value (eg, referred to as "Any") may be used to indicate that the function can be invoked by all channels of a connection.

[0147] List of “Connection IDs”: A filter which lists the connection identifiers whose data is processed by the function identified in the OF ID field (that is to say the connection identifiers eligible). In one or more embodiments, a predetermined value (eg called "Any") can be used to indicate that the function can be invoked for any identifier of a connection.

[0148] “Status”: Indicates whether the proposal to invoke one or more OF functions according to the information conveyed in a COCON frame is confirmed by the remote terminal, or if the proposal is awaiting confirmation from the remote terminal. This field can be limited to a single bit, which will take a first value (for example "1", corresponding to "Confirmed") to indicate a proposal to use a function validated by the second terminal, and a second value (for example "0", corresponding to "Pending") to indicate that the proposed use of the function is awaiting validation by the second terminal. In one or more embodiments, this field can be set to the value of waiting for confirmation (“Pending”) as long as a confirmation message has not been received from the second terminal. The confirmation message is typically an acknowledgment message sent by the second terminal following receipt of the intermediate processing function use information message (for example following receipt of a COCON frame).

[0149] In one or more embodiments, the use by the first terminal of the second connection to send data to the second terminal can be conditioned by the reception by the first terminal of an acknowledgment from the second terminal for G use of the intermediate function. The first terminal can thus be configured not to send the data via a secondary connection where an intermediate function (OF) will be invoked for which the “Status” parameter is set to a value indicating that the second terminal is awaiting confirmation.

[0150] As a variant, the confirmation message is a message called

GLUE (Confirmed, ...) described below. In this case, the terminal can send the first packets via the OF function even if the “Status” parameter is set to “0”. The terminal will notify according to the response from the remote terminal (typically, the terminal will continue to request the OF function if and only if a message

GLUE (Confirmed, ...) has been received.).

[0151] FIG. 4c illustrates an example of invocation of an intermediate processing function (OF1) between a first terminal T1 (60a) and a second terminal T2 (60b).

[0152] With reference to the example illustrated by FIG. 4c (which uses the reference architecture illustrated by FIG. Lb), the terminals T1 (60a) and T2 (60b) are in communication via a network (63) and maintain three channels (62a, 62b, 62c) of data communication using an encrypted connection: The first channel (62a) is a one-way channel from T1 to T2, i.e. only T1 can send data in this channel. The second channel (62b) is a bidirectional channel between T1 and T2. The terminals T1 and T2 can send data in this channel which does not invoke an OF function. The third channel (62c) is a unidirectional channel from T2 to T1. Only T2 can send data in this channel which does not invoke an OF function. [0153] In this example, the data of the various channels (62a, 62b, 62c) are routed via the same path.

The terminal T1 can involve the function OF1 in the first channel (62a), while the data of the other channels are exchanged directly between T1 and T2. To do this, in one or more embodiments, the terminal Tl (60a) inserts a COCON frame (D = 0, OF1, mytoken, streaml id) in a message intended for the terminal T2 (60b): direction of the terminal Tl to terminal T2 (D = 0), OF1 identifier function, “mytoken” key, channel identifier “streaml id” corresponding to the first channel.

[0155] As described above, in one or more embodiments, the terminal T1 (60a) can be configured to manage an offer table for the use of OF functions for the main connection with the terminal T2 (60b). (TRS table), and instantiate an entry in its TRS table relative to the COCON frame transmitted to terminal T2 (60b), as illustrated in FIG. 4d.

[0156] FIG. 4d shows an example of a TRS table managed by the terminal T1, in which information relating to the COCON frame (D = 0, OF1, mytoken, streaml id) sent to the terminal T2 is recorded: identifier of the function (“OF ID”) subject of the use offer (“OF1”), direction of use of the OF1 function (“Direction” field) indicating a unidirectional direction at the initiative of the terminal T1 (value “0” ), verification key (“Token” field filled in with the “myToken” key), list of channels whose data can be relayed by the OF1 function (“List Stream IDs”) indicating an identifier of the first channel (62a) (“ streaml id "), list of connection identifiers whose data are processed by the OF1 function (" List Connection IDs ") indicating that the OF1 function can be used for any connection identifier (" Any ") , and status of the offer to use the OF1 function ("Status") indicating that the offer is pending validation by the remote terminal T2 (60b).

[0157] FIG. 4e illustrates another example of invocation of two intermediate processing functions (OF1 and OF2) between a first terminal T1 (60a) and a second terminal T2 (60b).

[0158] With reference to the example of FIG. 4e (which uses the reference architecture of FIG. Lb), the terminals T1 (60a) and T2 (60b) are in communication via a network (63) and maintain three data communication channels (62a, 62b, 62c) using a encrypted connection: The first channel (62a) is a unidirectional channel from T1 to T2, the second channel (62b) is a bidirectional channel between T1 and T2, and the third channel (62c) is a unidirectional channel from T2 to T1. In this other example, the data of the different channels (62a, 62b, 62c) is also routed via the same path.

Unlike the example of FIG. 4c, FIG. 4e illustrates an example in which a first function OF1 (61a) is invoked for the first two channels (62a and 62b), while a second function OF2 (61b) is invoked for the data of the third channel (62c). To do this, in one or more embodiments, the terminal T1 (60a) can insert a COCON frame (OFl, mytoken, (streaml id, stream2_id}, ...) in a message intended for the terminal T2 (60b) , and the terminal T2 (60b) can insert a COCON frame (OF2, myowntoken, stream3_id, ...) in a message intended for the terminal T1 (60a). In these examples of COCON frame, the direction is not indicated , and the remote terminal will be able to use the direction of the associated channel to deduce the value of the direction bit "D".

[0160] The COCON frame (OFl, mytoken, (streaml id, stream2_id}, ...) may include the following information: OF1 identifier function, "mytoken" key, "streaml id" and "stream2_id" channel identifiers corresponding respectively to the first channel and to the second channel. The COCON frame (OF2, myowntoken, stream3_id, ...) may include the following information: OF2 function identifier, "myowntoken" key, "stream3_id" channel identifier corresponding to the third channel .

[0161] In one or more embodiments, separate OF functions can be invoked depending on the direction of traffic. Typically, a bidirectional channel can involve separate functions by direction of traffic. Referring to the example of Figure 4f (which uses the reference architecture of Figure lb), the terminals T1 (60a) and T2 (60b) are in communication via a network (63) and use a communication channel bidirectional data based on an encrypted connection: As illustrated by FIG. 4f, a bidirectional channel can therefore involve an OF1 function (61a) for the data of the channel sent by the terminal T1 (60a), while the data of the channel sent by the terminal T2 (60b) will be processed by OF2 (61b). To do this, in one or more embodiments, the terminal T1 (60a) can insert a COCON frame (D = 0, OF1, myTltoken, streaml id, ...) in a message intended for the terminal T2 (60b) , and the terminal T2 (60b) can insert a frame COCON (D = 1, OF2, myT2token, streaml id, ...) in a message to the terminal Tl (60a).

[0162] The COCON frame (D = 0, OF1, myTltoken, streaml id, ...) may contain the following information: direction from terminal T1 to terminal T2 (D = 0), identifier function OF1, key " mytoken ”, channel identifier“ streaml id ”corresponding to the channel. The COCON frame (D = 0, OF2, myT2token, streaml id, ...) may include the following information: direction from terminal T2 to terminal T1 (D = 0), OF2 function identifier, "myT2token" key, identifier channel “streaml id” corresponding to the same channel.

[0163] In one or more embodiments, the first message carrying data for the second terminal may be intended for the first intermediate processing function among a plurality of intermediate processing functions to be applied to the data eligible for the second connection. in a specific order. This first message may further include a first ordered list, for example according to the determined order of application of the functions, identifying the functions of the plurality of intermediate processing functions distinct from the first function to be applied to said eligible data.

[0164] These embodiments of the proposed method advantageously make it possible to deal with the scenario in which several intermediate processing functions must be invoked for the same packet of a given connection.

In one or more embodiments in which a plurality of intermediate processing functions must be invoked for the same packet of a given connection, the first terminal can only communicate to the second terminal (remote terminal) the identity of the last OF function to be invoked when routing a packet to the remote terminal. With reference to the example of FIG. 4g (which takes up the reference architecture of FIG. Lb), the terminals T1 (60a) and T2 (60b) are in communication via a network (63) and communicate via three channels ( 62a, 62b, 62c) for data communication over an encrypted connection: The first channel (62a) is a unidirectional channel from T1 to T2, the second channel (62b) is a bidirectional channel between T1 and T2, and the third channel ( 62c) is a unidirectional channel from T2 to T1. In the example of FIG. 4g, the terminal T1 (60a) can insert a frame

COCON (D = l, OF3, mytoken, stream2_id, ...) in a message to the terminal T2 (60b). The COCON frame (D = 1, OF3, mytoken, stream2_id, ...) may include the following information: direction from terminal T1 to terminal T2 (D = 1), OF3 function identifier corresponding to the last function among the following ordinate of functions OF1, OF2, and OF3 (61a, 61b, 61c) to be invoked for the data transmitted on the second channel (62b), key “mytoken”, and channel identifier “stream2_id” corresponding to the second channel.

[0166] In one or more embodiments, the first terminal may be configured to inform the second terminal, via the main connection, of a modification affecting the use of an intermediate processing function.

[0167] For example, in one or more embodiments, the first terminal can be configured to inform the second terminal (remote terminal) of the update of the policy for inserting one or more OF functions by sending an COCON message (UPDATE), the format of which is illustrated in Figure 4h.

[0168] In one or more embodiments, the description of the fields of this frame may be identical to that of the fields of the COCON frame, with the exception of the following fields:

[0169] “List disabled Stream IDs”: Indicates the list of channels for which secondary connections should no longer be accepted. These channel identifiers must be excluded from the filter used to determine which data is eligible for a secondary connection.

[0170] "List disabled Connection IDs": Indicates the list of connection identifiers that should no longer be accepted. These connection identifiers must be excluded from the filter used to determine the data eligible for a secondary connection.

For example, the first terminal can use the COCON frame (UPDATE) to end the invocation of an OF function, to update the list of channels eligible for the service provided by an OF function, and / or to update the list of connection identifiers eligible for the service provided by an OF function.

In one or more embodiments, the main connection may be established between the first terminal and the second terminal according to the QUIC protocol, and one or more secondary connections may be established between the first terminal and the second terminal, each via one or more intermediate functions established according to the TLS protocol.

[0173] FIG. 5a is a diagram illustrating the method proposed according to one or more embodiments, from the point of view of an intermediate function.

[0174] According to one aspect, the proposed method relates to the processing of data transmitted in a network between a first terminal and a second terminal between which is established a first encrypted connection, performed by a first device configured to implement a first function intermediate processing of data transmitted between the first terminal and the second terminal over a second connection via the first device.

[0175] In one or more embodiments, this first device can be configured to receive (70) from a first device of the network at least a first message intended for the first device, carrying data transmitted by the first terminal for the second. terminal, said first network device being the first terminal or a second device configured to implement a second intermediate processing function of said data, the second connection being encrypted between the first device and the first device, said first message comprising: a first ordered list identifying at least a second device of the network to be used by said at least one message to be routed to the second terminal, said at least one second device being the second terminal or at least a third device configured to implement a third intermediate processing function of said data, and a second ordered list e comprising at least one key intended to be presented by each device in the first list to the next device in said first list, the key intended to be presented to the second terminal being shared between the first terminal and the second terminal.

The first device, which is configured for the implementation of the first intermediate processing function, can, on receipt of the first message, apply (71) the first intermediate processing function to the data transported in the first message.

[0177] In one or more embodiments, this first device can also update (72) the first list and the second list received with the first message. [0178] In one or more embodiments, this first device can then send (73), to the next device identified in the first list, the first message incorporating the update of the first and second lists, with the processed data. by the first intermediate processing function and the key extracted from the second list intended to be presented to the following device, the second connection being encrypted between the first device and the following device.

[0179] As discussed above, in the embodiments in which the first connection between the two terminals is established according to the QUIC protocol, the first terminal can insert a QUIC frame of RELAY type as described above, in a control message or a data message from the first connection (main connection) to the first device, in which case the first message received by the first device may be a RELAY frame.

[0180] Thus, in one or more embodiments, upon receipt of a message containing a QUIC frame

RELAY (List {Next_Hop_IP address / port}, Shared Token, ...) by a first device configured for the implementation of an intermediate processing function (OF):

[0181] If several OF functions must be invoked, then the List {Next_Hop_IP address / port} list can include the list of all OF functions to be invoked, except the first function, in addition to the address (and possibly the number port) of the remote terminal. In this case, the message is sent by the first terminal to the first function to be invoked, that is to say to the first device configured to implement the first function to be invoked in the ordered series of functions to be invoked. invoke.

[0182] Thus, for a data packet that has to pass through several intermediate processing functions, the first terminal can send a message to the first function to be implemented for the packet. The first function performs its service for the packet, then determines information to send the packet to the next function to be implemented for the packet.

Each OF intermediate processing function which must be invoked must process each packet eligible for processing performed by the function. [0184] In one or more embodiments, each intermediate processing function which must be invoked can update the List {Next_Hop_IP address / port} list, for example by removing the “Next_Hop_IP address / port” data corresponding to the next intermediate processing function to be invoked from List {Next_Hop_IP address / port}. The packet can then be forwarded to this next function using the “Next Hop IP address / port” data, after instantiating an entry in a RELAYED COLLABORATIVE CONNECTIONS BASE (RCCB) table, as described below. The proposed procedure can be repeated until the packet is received by the last OF function to be invoked. The processing to be performed then corresponds to the case in which a single function must be invoked.

[0185] If only one OF function is to be invoked, then the List {Next_Hop_IP address / port} list contains only the address (and possibly the port number) of the second terminal (remote terminal). The message is sent using the IP address allowing access to the OF function as the destination address of the packet after the execution of the service offered by the OF function.

[0186] In addition, in one or more embodiments, the OF function can include a new QUIC frame called GLUE (Shared_Token, [mylD], ...). In other words, the packet retrieved from the output of the OF function can be encrypted according to a new security association to be established between the OF function and the second terminal. In one or more embodiments, the OF function can on this occasion instantiate an entry in the RCCB table. In addition, the sending of the first packet (first message) can for example be based on the 0-RTT TLS1.3 mechanism, which makes it possible to immediately send the payload.

[0187] In one or more embodiments, a device configured for the implementation of an intermediate processing function can be configured to maintain the RCCB table, in order to handle the scenario in which different external addresses are used. by the function to relay a given connection. This table is used in particular to keep in memory the IP address and the external port number used by the function for this connection.

[0188] FIG. 5b illustrates an example of an RCCB table structure maintained by an OFi function located on the data transmission path between a first terminal T1 and a second terminal T2 between which an encrypted connection is established. The RCCB table illustrated in Figure 5b includes the following fields:

[0189] “Referenced Upstream Connection”: Indicates the reference of the connection to be relayed by the OFi function, the path of the data transmitted between the first terminal T1 and the OFi function being designated by the “Upstream” path. In one or more embodiments, it may be preferred to use TLS / DTLS security associations for this purpose, rather than the {source address, source port, destination address, destination port} quadruplet, for greater reliability.

[0190] “Downstream Connection Reference”: Indicates the reference of the connection as relayed by the OFi function, the data path transmitted between the OFi function and the second terminal T2 being designated by the “Downstream” path. In one or more embodiments, this field may have the same structure and the same semantics as the “Upstream Connection Reference” field described above.

[0191] "Token": This field corresponds to "Shared Token" received in a RELAY frame for an "Upstream" connection. This field is optional.

[0192] "Extemal IP Address": Indicates the IP address used by the OFi function as the source address to relay the packets of the connection.

[0193] “Extemal Port Number”: Indicates the port number used by the OFi function as the source port number to relay the packets of the connection.

[0194] "Next Hop IP Address": Indicates the IP address used by the OFi function as the destination address to relay the packets of the connection. This field is optional; the information can be deduced by using the reference of the "Downstream" connection.

[0195] “Next Hop Port Number”: Indicates the port number used by the OFi function as source address to relay the packets of the connection. This field is optional; the information can be deduced by using the reference of the "Downstream" connection.

[0196] In one or more embodiments, if an “Upstream” connection is associated with several “Downstream” connections, the traffic distribution policy between these various connections is typically local to the OFi function. [0197] In addition, in one or more embodiments, an OF function requested in both directions of a QUIC connection ("Tl to T2" and "T2 to Tl") can maintain entries in its RCCB table which correspond. to each direction.

[0198] In one or more embodiments, any packet intended for an OFi function, but which does not contain a RELAY frame, can be processed according to the instructions of the RCCB table maintained by the OFi function. On receipt of such a packet, the OFi function can consult its RCCB table to retrieve the reference of a "Downstream" connection, if necessary. Once the OFi service has been executed on the packet (for example, transcoding), the packet can be transmitted using the information entered in the RCCB table (source address, source port number, destination address, destination port number). Note that the OFI function service is not executed if no entry is found in the RCCB table.

[0199] In one or more embodiments, the GLUE frame may be used only for a predetermined number of eligible first packets (eg, for the first packet or the first three packets) in a new secondary connection, and can be omitted for other packages.

[0200] FIG. 6a is a diagram illustrating the method proposed according to one or more embodiments, from the point of view of the remote terminal (second terminal).

We consider first and second terminals, between which a first encrypted connection is established (80) for the transmission of data between the first terminal and the second terminal.

In one or more embodiments, the proposed method can comprise, at the second terminal, the storage (81), in association with the first connection, of an intermediate processing function intended to be applied between the first terminal and the second terminal on at least part of the data transmitted between the first terminal and the second terminal, a filter characterizing the at least part of the eligible data, as well as a key shared with the first terminal.

[0203] The second terminal can also receive (82) at least a first message coming from the intermediate processing function, the first message carrying data sent by the first terminal. The processing of this first message received can include a check that the data transported by the first message correspond to the stored filter.

[0205] In the event of a match, the second terminal can accept (83) the establishment of a second encrypted connection with the intermediate processing function and associate the second connection with the first connection. In this way, the second terminal can, on receipt of data via the second connection and corresponding to the filter, associate the data received with the first connection.

As discussed above, in the embodiments in which the first connection between the two terminals is established according to the QUIC protocol, the first terminal can insert a QUIC frame of COCON type as described above, in a control message or a data message from the first connection (main connection) to the remote terminal, in which case the first message received by the second terminal can be a COCON frame, for example according to the format illustrated in FIG. 4a.

[0207] Thus, in one or more embodiments, on receipt of a COCON frame by the second terminal (remote terminal), the latter can update its QUIC connection tables to save a copy of the information contained in the message. . In particular, the terminal can update a TRS table to keep in memory data included in the COCON message.

[0208] FIG. 6b illustrates an example of a TRS table, the structure of which is similar to that described above for the first terminal (concerning the offers made by the first terminal) and illustrated in FIG. 4b, except for the “status” field:

[0209] The TRS table illustrated in FIG. 6b (for the primary connection “Primary Connection Ref”) contains the following information extracted from the COCON message:

[0210] "OF ID": an identifier of an OF function.

[0211] "Direction": in one or more embodiments, this field indicates a first value indicating a use of the function identified by the unidirectional OF ID field at the initiative of the second terminal, that is to say for data sent by the second terminal, a second value indicating use of the function identified by the unidirectional OF ID field at the initiative of the first terminal, that is to say for data sent by the first terminal, or a third value indicating a use of the function identified by the bidirectional OF ID field, that is to say for data sent by the first terminal or through the second terminal. For example, this field may indicate one of the following values: 0 (Unidirectional at the initiative of the terminal), 1 (Unidirectional at the initiative of the remote terminal), 2 (bidirectional).

[0212] "Token": A verification key which must be presented to the second terminal (by an OF function) to establish a new secondary connection.

[0213] List of “Stream IDs”: A filter which lists the channels whose data can be relayed by the function identified in the OF ID field. In one or more embodiments, a predetermined value (eg, referred to as "Any") may be used to indicate that the function can be invoked by all channels of a connection.

[0214] List of "Connection IDs": A filter that lists connection identifiers whose data is subject to processing by the function identified in the OF ID field. In one or more embodiments, a predetermined value (eg called "Any") can be used to indicate that the function can be invoked for any identifier of a connection.

[0215] In one or more embodiments, the second terminal can be configured to retain an OF function only for a given direction. For example, the terminal may override the value of the "D" bit according to local policies. For example, with reference to Figure 4f, if T1 offers an OF1 transcoding function for a bidirectional channel, T2 may decide to use another OF2 transcoding function for the same channel.

[0216] An acknowledgment message of the COCON frame can then be sent to the first terminal.

[0217] As discussed above, in the embodiments in which the first connection between the two terminals is established according to the QUIC protocol, the device or the equipment configured for the implementation of the single function or, in the case where several functions are invoked for the same data packet transmitted between the two terminals, the last function to be implemented for the packet, can insert a GLUE type QUIC frame as described above, in a control message or a data message from the second connection (secondary connection) to the second terminal, in which case the first message received by the second terminal may be a frame GLUE, as described above.

[0218] With reference to FIG. 6c, in one or more embodiments, the second terminal (T2) can be configured to, on reception (90) of a message containing a GLUE frame (), extract the identifier from the connection, the channel identifier, the “Shared Token” key and the function identifier as follows:

[0219] The channel and connection identifier can be extracted according to the methods described in the QUIC specification.

[0220] The "Shared Token" identifier can be extracted (91) from the GLUE frame. By default, the second terminal ignores (92) the GLUE frame received in the event of failure to extract the "Shared Token" identifier.

[0221] The function identifier can be extracted using the GLUE frame (using the "mylD" field) or, alternatively, by applying a hash calculation algorithm (eg SHA-256) from the "Pre-Shared Key (PSK) identity" information used by the OF function in the TLS "ClientKeyExchange" message.

After having extracted this information, the second terminal can be configured to consult (94) the TRS table described above maintained by the second terminal to verify whether the information thus extracted corresponds to an entry in the TRS table. If an entry has been found (95), the second terminal accepts (96) the establishment of the new TLS collaborative connection from the OF function. A pointer to this new connection is then added to the QUIC connections table. Thus, data received using a secondary connection (eg, OF-T2) is associated with the primary connection T1-T2. By default, the second terminal ignores (92) the received GLUE frame if no entry is found in its TRS table.

[0223] In one or more embodiments, the second terminal can be configured to apply this control procedure only for a predetermined number of first packets (eg 3) being processed by the function. OF. In this case, the following packets can be processed according to the instructions in the CCT table, and the GLUE frame can no longer be used. [0224] FIG. 6d illustrates an example of a method of processing a new packet received by the second terminal according to one or more embodiments of the proposed method.

[0225] On receipt (97) of a new packet, the terminal determines (98) whether or not the received packet is associated with a new main connection. In the case where the received packet is associated with a new main connection, it is processed (99) considering a new main connection as described previously. In the event that the received packet is not associated with a new primary connection, the terminal determines (100) whether or not the received packet is associated with a new secondary connection. In the case where the received packet is associated with a new secondary connection, it is processed (101) by considering a new secondary connection as described previously. In the case where the received packet is associated with an existing secondary connection (that is to say, an entry corresponding to this packet has been found in the CCT table), the terminal processes it (102) using the instructions of said CCT table entry, as described above.

[0226] In one or more embodiments, the packets are rejected if no entry is found in the TRS table (for the first N packets, N being a predetermined integer) or if no entry is found in the table. CCT (for other packages).

[0227] Various examples of use cases of the method proposed according to one or more embodiments are provided below, with reference to Figures 7a to 7f.

[0228] Figures 7a to 7c show different examples of rejection of an OF function, for communications, in a communication network, between a first terminal T1 and a second terminal T2 (remote terminal) between which a QUIC connection is established. .

[0229] FIG. 7a illustrates the case where an OF function is the subject of an attempt to insert into a connection (for example for the purpose of data theft), but the connection is rejected by T2 because the key presented in the associated COCON frame does not correspond to any entry in the TRS table maintained by T2.

[0230] Figure 7b illustrates the case where an OF function is the subject of an attempt to insert into a connection (for example for the purpose of data theft), but the connection is rejected by T2 because the identifier of the channel does not correspond to that indicated in the TRS table maintained by T2.

[0231] Figure 7c illustrates the case where an OF function is attempted to be inserted into a connection (for example for the purpose of data theft), but the connection is rejected by T2 because the presented function identifier does not correspond to any entry in the TRS table maintained by T2 for T1.

[0232] Figures 7d to 7f show various examples of successful collaborative connection, for communications, in a communication network, between a first terminal T1 and a second terminal T2 (remote terminal) between which a QUIC connection is established.

[0233] Figure 7d illustrates the example of a successful collaborative connection between T1 and T2. This connection involves a single OF1 function as described in the COCON frame sent by T1 to T2:

COCON (OFl, 485rFIjaKLkalBbjrCJghiD, stream_id = 0x04579) (offer to use the OF1 function for data sent on the identifier channel "0x04579", with sharing of the key "485rFIjaKLkalBbjrCJghiD" with the OF1 function). The connections are relayed according to the instructions entered in the RCCB table.

[0234] On receipt of the COCON frame from the first terminal T1, the second terminal T2 instantiates an entry in its TRS table, as described above, and optionally transmits an acknowledgment of acceptance of the offer to use the OF1 function to the first terminal T1. The first terminal T1 transmits to the OF1 function data (DATA) on which the service of the OF1 function must be performed as well as a RELAY frame (@ T2, 485rFIjaKLkalBbjrCJghiD, ...) indicating the 'T2 address and the key shared with the OF1 function. The OF1 function performs on the data received with the RELAY frame the service corresponding to the OF1 function (for example, it transcodes the data received), instantiates an entry in its RCCB table, and transmits the processed data (DATA) to the second terminal as well than a GLUE frame (485rFIjaKLkalBbjrCJghiD, ...). On reception of the GLUE frame (485rHjaKLkalBbjrCJghiD, ...), the second terminal T2 only associates the two TLS connections after having checked that its TRS table indeed contained an entry corresponding to the OF1 function and to the key received from OF1 ("485rFIjaKLkalBbjrCJghiD"). The second terminal T2 further instantiates an entry in its CCT table, as described above. It then possibly sends a GLUE connection association confirmation frame GLUE (Confirmed, OF1, 0x04579, ...) to the terminal T1. As indicated above, the transmission of the following data between the first terminal and the function OF1 on the one hand, then between the OF1 function and the second terminal T2 on the other hand, may not use RELAY messages and / or GLUE, respectively. On receipt of the data by the OF1 function, the OF1 service is implemented, then the relay instructions for the processed data are obtained by consulting the RCCB table. On receipt of the data processed by the second terminal T2, the data received are associated with two TLS collaborative connections on the basis of the CCT table. If the OF1 function is possibly invoked for both directions of the connection, similar processing is performed by OF1 for the packets received from T2 to T1.

[0235] Figure 7e illustrates another example of successful collaborative connection between first and second terminals T1 and T2 and which involves two functions OF1 and OF2.

The connection between Tl and T2 involves two functions OF1 and OF2 as described in the COCON frame sent by Tl to T2:

COCON (OF2, CJghiD, stream_id = 0x04579) (offer to use the OF2 function for data sent on the identifier channel "0x04579", with sharing of the key "CJghiD" with the OF2 function). The connections are relayed according to the instructions entered in the respective RCCB tables maintained by the devices implementing the functions OF1 and OF2 respectively.

[0237] On receipt of the COCON frame from the first terminal T1, the second terminal T2 instantiates an entry in its TRS table, as described above, and optionally transmits an acknowledgment of acceptance of the offer to use the OF2 function at the first terminal T1. The first terminal T1 transmits to a device for implementing the function OF1 data (DATA) on which the service of the function OF1 must be performed as well as a RELAY frame ({@ OF2, @ T2}, CJghiD, ...) indicating the key shared with the OF1 function. The device implementing the function OF1 performs on the data received with the RELAY frame the service corresponding to the function OF1 (for example, it transcodes the data received), instantiates an entry in its RCCB table, and transmits to a device implementation of the OF2 function the processed data (DATA) as well as a RELAY frame (@ T2, CJghiD, ...) indicating the key shared with the OF2 function (which is, in this example, identical to the key shared with the OF1 function). The device for implementing the OF2 function performs on the data received with the RELAY frame the service corresponding to the OF2 function, instantiates an entry in its RCCB table, and transmits the processed data to the second terminal as well as a GLUE frame ( CJghiD, ...). On receipt of the GLUE frame (CJghiD, ...), the second terminal T2 only associates the two TLS connections after having verified that its TRS table indeed contained an entry corresponding to the function OF2 and to the key received from OF2 (“CJghiD”) for this connection. The second terminal T2 further instantiates an entry in its CCT table, as described above. It then optionally sends a connection association confirmation GLUE frame to the terminal T1 (not shown in the figure). As indicated above, subsequent data transmissions between the first terminal and the OF1 function on the one hand, between the OF1 and OF2 functions, then between the OF2 function and the second terminal T2 on the other hand, may not use RELAY and / or GLUE messages, respectively. On receipt of data by the function OF1 (respectively OF2), the service OF1 (respectively OF2) is implemented for the data received, then the relay instructions for the data processed are obtained by consulting the table RCCB. On receipt of the data processed by the second terminal T2, the data received are associated with two TLS collaborative connections on the basis of the CCT table.

[0238] Figure 7f illustrates another example of a successful collaborative connection between T1 and T2 which involves two functions OF1 and OF2: The function OF1 is involved for the channel data sent by T1 to T2, while the data of the same channel sent by T2 to Tl are processed by OF2. The order of COCOON frames is provided as an example.

[0239] In one or more embodiments, the terminal T2 can inform T1 of the addition of an OF function to a connection. To do this, T2 sends a GLUE frame (Confirmed, OF ID, List {stream_id}, ...) to T1. Tl can use this frame to detect the a priori unauthorized insertion of an OF function. It can signal to T2 the rejection of this secondary connection by sending a COCON (UPDATE) message, as described above.

[0240] Figure 8a illustrates an example of the architecture of a terminal for implementing the proposed method.

[0241] With reference to FIG. 8a, the device 100 comprises a controller 101, operatively coupled to a communication interface 102 and to a memory 103, which controls a communication management module according to a QUIC 104 protocol.

[0242] The communication interface 102 comprises one or more communication units, each configured to send and / or receive data according to one or more several data communication protocols (fdial or wireless), for example of the WLAN, Ethernet, LTE, LTE -A type.

[0243] The controller 101 is configured to drive the communications management module 104 and the communications interface 102 for the implementation of one or more embodiments of the proposed method.

[0244] The communications management module 104 is configured for the implementation of the method proposed by a terminal. In particular, the communications management module 104 can be configured to fulfill the functions and perform the acts described in the present description for the implementation of the method proposed by a terminal (local and / or remote).

[0245] The device 100 can be a computer, a computer network, an electronic component, or another device comprising a processor operably coupled to a memory, as well as, depending on the embodiment chosen, a storage unit. data, and other associated hardware elements such as a network interface and a media drive for reading and writing removable storage media (not shown in the figure). The removable storage medium can be, for example, compact disc (CD), digital video / versatile disc (DVD), flash disc, USB stick, SSD memory, etc. Depending on the embodiment, the memory, the data storage unit or the removable storage medium contains instructions which, when executed by the controller 101, cause this controller 101 to perform or control the module parts of the system. communication management 104 and communication interface 102 of the examples of implementation of the proposed method described in the present description. The controller 101 can be a component implementing a processor or a computing unit for the management of communications according to the proposed method and the control of the units 102 and 104 of the device 100.

[0246] The device 100 can be implemented in software form, in hardware form, such as an application-specific integrated circuit (ASIC), or in the form of a combination of hardware and software elements, such as for example a software program intended for to be loaded and executed on an FPGA (Field Programmable Gâte Array) type component. Likewise, the communications management module 104 can be implemented in software form, in hardware form, such as an ASIC, or in the form of an combination of hardware and software elements, such as for example a software program intended to be loaded and executed on a component of FPGA type.

[0247] FIG. 8b illustrates an example of the architecture of a device configured for the implementation of one or more intermediate processing functions for the implementation of the proposed method.

[0248] With reference to FIG. 8b, the device 200 comprises a controller 201, operably coupled to a communication interface 202 and to a memory 203, which drives a function service module 204.

The communication interface 202 comprises one or more communication units, each configured to send and / or receive data according to one or more data communication protocols (by wire or wireless), for example of the type WLAN, Ethernet, LTE, LTE -A.

[0250] The controller 201 is configured to drive the function service module 204 and the communication interface 202 for the implementation of one or more embodiments of the proposed method.

[0251] The function service module 204 is configured for the implementation of the method proposed by a node implementing a function. In particular, the function service module 204 can be configured to perform the functions and perform the acts described in the present description for the implementation of the method proposed by a node implementing a function.

[0252] The device 200 may be a computer, a computer network, an electronic component, or another device comprising a processor operably coupled to a memory, as well as, depending on the embodiment chosen, a storage unit. data, and other associated hardware elements such as a network interface and a media drive for reading and writing removable storage media (not shown in the figure). The removable storage medium can be, for example, compact disc (CD), digital video / versatile disc (DVD), flash disc, USB stick, SSD memory, etc. Depending on the embodiment, the memory, the data storage unit or the removable storage medium contains instructions which, when executed by the controller 201, cause this controller 201 to perform or control the module parts of the system. 204 function service and interface communication 202 of the examples of implementation of the proposed method described in the present description. The controller 201 can be a component implementing a processor or a computing unit for the management of communications according to the proposed method and the control of the units 202 and 204 of the device 200.

[0253] The device 200 can be implemented in software form, in hardware form, such as an application specific integrated circuit (ASIC), or in the form of a combination of hardware and software elements, such as for example a software program intended for to be loaded and executed on an FPGA (Field Programmable Gâte Array) type component. Likewise, the function service module 204 can be implemented in software form, in hardware form, such as an ASIC, or in the form of a combination of hardware and software elements, such as for example a software program intended to be. loaded and executed on an FPGA type component.

[0254] The implementation of the method proposed according to the embodiments described in the present description advantageously allows: (1) to enhance the operator's network by the introduction of mechanisms optimizing the use of the resources mobilized for the establishment and maintenance of QUIC communications, (2) to promote mechanisms for invoking network functions with explicit consent, (3) for QUIC communications to benefit from network operator support in the form of optimized management resources mobilized by these communications in order to improve the level of quality associated with these communications and as perceived by users, (4) to simplify the use of QUIC customers through pragmatic coordination / collaboration with the operator network, (5) to introduce more flexibility in the invocation and withdrawal of network functions without inducing additional delays for the exchange of data. The level of security and robustness associated with each QUIC communication is also maintained, if not reinforced by the means available to the operator, (6) to promote new practices such as invocation of network functions on demand, (7) to allow Selective network function invocation per channel ("stream").

Industrial application

[0255] Depending on the embodiment chosen, certain acts, actions, events or functions of each of the methods described in this document may be carried out or occur in a different order from that in which they have been described, or can be added, merged or not done or not happen, as the case may be. Further, in some embodiments, certain acts, actions or events are performed or occur concurrently and not sequentially.

[0256] Although described through a number of detailed exemplary embodiments, the proposed control method and the device for implementing an embodiment of the method include various variants, modifications and improvements which will appear in such a way. obvious to those skilled in the art, it being understood that these various variants, modifications and improvements form part of the scope of the invention, as defined by the claims which follow. In addition, different aspects and features described above may be implemented together, or separately, or substituted for each other, and all of the different combinations and sub-combinations of aspects and features are within the scope of invention. Further, some systems and devices described above may not incorporate all of the modules and functions described for the preferred embodiments.

Claims

[Claim 1] Method of communication in a network, between a first terminal and a second terminal between which is established a first encrypted connection for transmitting data, the method comprising at the first terminal:

memorize, in association with said first connection, at least a second connection between the first terminal and the second terminal via at least one intermediate processing function intended to be applied to at least part of said data said to be eligible for the second connection, and a filter characterizing said data eligible for the second connection, said second connection being encrypted between the first terminal and said intermediate processing function,

sending, via said second connection, at least one first message intended for said intermediate function and carrying data for the second terminal corresponding to said filter, the first message comprising information according to which said data is intended for the second terminal.

[Claim 2] A method according to claim 1, comprising sending via the first connection data to the second terminal, data which does not correspond to said filter.

[Claim 3] The method of claim 1 or 2, further comprising upon receiving data via said second connection, associating said data with said first connection if the data matches said filter.

[Claim 4] A method according to any preceding claim wherein said first message further comprises a key to be presented by the intermediate function to the second terminal, and shared between the first terminal and the second terminal.

[Claim 5] Method according to any one of the preceding claims comprising informing the second terminal, in at least one message sent via said first connection to the second terminal, of the use of said intermediate processing function for said at least one. part of said data.

[Claim 6] The method according to claim 5 wherein said at least one message informing the second terminal of G use of said intermediate processing function comprises at least one of: an identifier of said intermediate processing function;

- a key to be presented by the intermediate function to the second terminal;

said filter characterizing the data eligible for said second connection;

- at least one connection identifier eligible for said second connection; and

- a data transmission direction information via the second connection to which said intermediate processing function is applied.

[Claim 7] The method of claim 5 or 6, wherein the use by the first terminal of said second connection to send data to the second terminal is conditioned by the receipt by the first terminal of an acknowledgment from the second terminal of the 'use of said intermediate processing function.

[Claim 8] A method according to any one of the preceding claims wherein on the second connection, a plurality of intermediate processing functions can be applied to the data eligible for the second connection in a determined order and:

- said at least one message transporting data for the second terminal is intended for the first intermediate processing function to be applied to said data eligible for the second connection,

said first message sent further comprises a first list ordered according to said determined order identifying the functions of said plurality of intermediate processing functions distinct from the first function to be applied to said eligible data.

[Claim 9] The method of claim 8 wherein said first message sent further comprises a second list ordered according to said determined order of keys intended to be presented by each of the intermediate processing functions identified in the first list to the intermediate processing function. next in said first list or, for the last intermediate processing function from the first list to the second terminal, the key intended to be presented to the second terminal being shared between the first terminal and the second terminal.

[Claim 10] A method according to any one of the preceding claims comprising informing the second terminal via the first connection of a modification affecting G use of said intermediate processing function.

[Claim 11] A method according to any one of the preceding claims wherein:

- Said first connection is established between the first terminal and the second terminal according to the QUIC protocol;

at least one said second connection is established according to the TLS protocol between the first terminal and the second terminal via at least one said intermediate function capable of decrypting the data exchanged via said second connection.

[Claim 12] A method of communication in a network, between a first terminal and a second terminal between which a first encrypted connection is established for transmitting data, the method comprising at the second terminal:

- storing, in association with said first connection, an intermediate processing function intended to be applied between the first terminal and the second terminal on at least part of said data, a filter characterizing said at least part of the data and a key shared with the first terminal;

- receive at least a first message from said intermediate function transporting data sent by the first terminal;

checking whether said data correspond to the stored filter; and

- in case of correspondence:

accept the establishment of a second encrypted connection with the intermediary function and associate said second connection with the first connection; and

on receipt of data via said second connection corresponding to said filter, associating said data with the first connection.

[Claim 13] A communication method according to claim 12, wherein said first message further comprises a key presented by the intermediate processing function to the second terminal, the establishment of the second encrypted connection being accepted if said received key corresponds to a. key shared with the first terminal.

[Claim 14] A communication method according to claim 12 or 13, comprising sending data to the first terminal via said second connection corresponding to said filter in a message intended for the intermediary function.

[Claim 15] A method of processing data transmitted in a network between a first terminal and a second terminal between which a first encrypted connection is established, the method comprising, for a first device configured to implement a first intermediate processing function of data transmitted between the first terminal and the second terminal over a second connection via said first device:

- receive from a first device of the network at least a first message intended for the first device, carrying data sent by the first terminal to the second terminal, said first device of the network being the first terminal or a second device configured to put in performs a second function of intermediate processing of said data, the second connection being encrypted between the first device and the first device, said first message comprising:

a first ordered list identifying at least a second device of the network to be borrowed by said at least one message to be routed to the second terminal, said at least one second device being the second terminal or at least a third device configured to implement a third function for intermediate processing of said data; and

a second ordered list comprising at least one key intended to be presented by each device of the first list to the next device in said first list, the key intended to be presented to the second terminal being shared between the first terminal and the second terminal;

- applying the first intermediate processing function to said data transported in said at least one first message;

- update the first list and the second list; and

- send to the next device identified in the first list, said at least a first message integrating the update of the first and second lists, with the data processed by the first intermediate processing function and the key extracted from the second list intended to be presented to the next device, the second connection being encrypted between the first device and the next device.

[Claim 16] A treatment method according to claim 15 comprising:

- memorize for the second connection:

a source IP address and a source port number used by the first intermediate device to relay said data from said at least one first message; and a destination IP address and a destination port number corresponding to the next device identified in the first list to which said data of said at least one first message is transmitted; receiving from the first device at least one second message intended for the first intermediate device, carrying data sent by the first terminal to the second terminal, in which the first list is absent;

- applying the first intermediate processing function to said data transported in said at least one second message;

- send to the destination IP address and the destination port stored, said at least one second message with the data processed by the first intermediate processing function.

[Claim 17] A data communications device, comprising a processor and memory operably coupled to the processor, wherein the processor is configured to implement a method according to any of claims 1 to 16.

[Claim 18] A data communication system, comprising a first terminal configured for implementing a method according to any one of claims 1 to 11, a second terminal configured for implementing a method according to any one of claims 12 to 14, and a device configured to carry out a method according to any one of claims 15 to 16.

[Claim 19] A computer program, loadable into a memory associated with a processor, and comprising portions of code for implementing the steps of a method according to any one of claims 1 to 16 during execution of said program by the processor.